I had the pleasure of taking part in the FICPI 23rd Open Forum in Budapest in a session entitled Automate or Stagnate: How to Transform Your Legal Practice Step by Step.

The panel was moderated by Vikrant Rana (SS Rana & Co) and brought together three quite different perspectives. Luna Zhang spoke from the point of view of Kangxin Partners, a large Chinese IP firm with a substantial internal IT capability. Johan Örtenblad represented Noréns Patentbyrå, a Swedish firm of around 20 professionals.

And then there was me, representing Cantab IP, which is very much at the other end of the scale.

That made for quite an interesting discussion. On the panel we had firms of different sizes, with very different approaches to technology, all facing essentially the same issue: how do you get rid of repetitive work without losing control of the quality and accuracy that are crucial in our profession?

Why Automate in the First Place?

For Cantab IP, automation was never really a separate “digital transformation” project.

When I started the firm in 2007, I made a conscious decision that I wanted to keep it small. That meant we would not have the luxury of large numbers of typists, paralegals, records staff or administrative support.

So if something could sensibly be automated, there was a fairly strong incentive to automate it.

Over time, that has become part of the way the firm works. Our systems have developed around a central database, with information being reused across documents, correspondence and filing processes rather than being repeatedly copied and retyped.

One of the advantages of being small is that if something annoys me, I can usually decide fairly quickly to try to fix it. There is no committee and no IT department to negotiate with. In practice, that is not much of a disadvantage for me because I enjoy tinkering, fixing things and working out how systems operate.

Start With the Annoying Stuff

The session incorporated a number of audience surveys. One of the questions asked the audience how much of their daily work they thought could be automated with today’s technology. The responses were spread out, but a large proportion thought that either some tasks, or about half their work, could potentially be automated.

That was interesting, but the actual percentage is not so crucial to me. The more useful question is: what are you doing repeatedly that you would really rather not be doing?

My rule of thumb is that if I find myself doing the same thing more than once, I start asking whether some part of it can be automated.

That does not necessarily mean building a grand system. The solution might be a simple script that renames files. It might be a more involved integration that attaches the correct documents to a reporting email. Or it might simply be a better way of moving data from one place to another.

The best candidates for automation tend to be tasks which are repetitive, rules-based and have a reasonably predictable outcome. Those are usually sensible places to start, particularly where part of the process can be automated without losing control over the result.

Demos of Real-World Automations

Rather than simply talking about automation, we showed a few demonstrations.

I demoed one of our IPOS filing automations. The system takes data and documents from the case file, opens the appropriate filing form on the IPOs website, fills in the required information, uploads the documents and takes the filing through to the review stage. The final review and decision to submit are made by the attorney.

That last feature is crucial. I am not particularly interested in automation for the sake of removing humans from the loop. Rather, my aim is to remove the boring, mechanical parts of the process while keeping human judgement where it is needed.

The filing automation is built in Ruby, with a command-line interface and Keyboard Maestro and macOS providing the graphical interface. It was built when IPOS withdrew its batch-filing service, which had allowed data and documents to be packaged together and uploaded for filing.

The slightly cumbersome part is that, in the absence of an official API, the automation has to interact with the web interface. This means that if the IPOS website changes, the automation will have to be updated.

An audience member raised exactly that point. My view is that the better long-term solution is for patent offices to provide proper APIs so that users can interact with their systems in an official and stable way. I suggested that this is something FICPI and other professional bodies might usefully encourage IP offices to provide.

I also showed a second demo of directly importing bibliographic data from WIPO Patentscope into our database. Instead of locating a PCT application and manually copying applicant names, inventors, priority data and other details into a new case file, we can retrieve the information from WIPO through a paid subscription and create the case file directly from that data.

That saves time, but more importantly it avoids creating another opportunity for copying errors. It also reduces tedious work, interruptions and the mental effort spent on routine tasks, leaving more attention for work that actually requires judgement.

Buy it or Build it?

Johan’s perspective was particularly interesting because he enjoys software development, but has deliberately decided that his firm should not try to build and maintain everything itself.

He described the frustrations of working with a system, Patrawin, which has grown over many years around what is, in effect, an electronic version of a paper-file model. Tasks such as downloading files, renaming them, dating them and moving information around can consume a surprising amount of time without adding much value for the client.

Johan’s point is that automation has a cost in itself. Somebody has to build it, test it, maintain it and fix it when something changes. Just because you can automate something yourself does not necessarily mean that you should.

For a small script that may be trivial. For an entire practice management system, it is a rather different proposition. In that situation, adopting an existing system may make more sense than taking on the burden of building and maintaining one yourself.

Automation is Not the Same as Artificial Intelligence

This was probably the distinction I was most keen to make during the session.

A traditional automation is usually deterministic. If I give it the same inputs and the same rules, I would expect the same result to come out every time. Generative AI, on the other hand, is inherently probabilistic. If you ask the same question twice, you may well get different answers.

When deciding what you are comfortable automating, that difference needs to be borne in mind.

I find myself increasingly using tools such as Codex to help me write, debug and modify software. In my view, this is an extremely useful application of AI. However, there is a clear difference between asking AI to perform or automate a task and using AI to help build a tool which then performs a clearly defined task deterministically.

I am much more comfortable with the second approach where the result can be tested against a known expected outcome, so that I know what should happen and can detect when something has gone wrong.

People are Part of the System

A particularly good audience intervention raised another concern: if we rely too heavily on AI and automation, do we risk losing skills?

I think that is a legitimate concern. Resistance to automation is not always simply resistance to change. People may reasonably wonder whether a new tool will actually make their work better, whether they can trust it or whether they are slowly giving up skills they ought to retain.

Luna described how Kangxin involved staff in designing its systems, which helped people see that automation was intended to address genuine problems rather than simply replace them. Over time, staff could see improvements in efficiency and could also see that people were not simply losing their jobs as a result.

There is also a very practical reason to involve the people doing the work: they usually know where the pain points are. A paralegal who performs the same task 30 times a week may have a much better idea of what should be automated than somebody sitting several layers above them.

It is therefore important to involve users from the outset. They can identify the repetitive work worth automating, help shape the solution and tell you very quickly whether it actually improves the way they work.

What is the Return?

We also talked about return on investment during the session. I do not think this should be measured simply by revenue.

There is, of course, the obvious benefit of hours saved. But there is also error reduction, staff satisfaction, capacity and the ability to take on work without adding unnecessary administrative effort.

Luna reported significant efficiency improvements from automation at Kangxin. Johan made the point that in a smaller firm a very practical measure may simply be whether the attorneys, paralegals and clients actually prefer working with the new system.

For me, there is another cost which is difficult to quantify: concentration. A task that takes only a minute may still be expensive if it interrupts more valuable work ten times a day.

So the return from automation is often broader than a line in a financial calculation. It includes time, accuracy, capacity and the ability to preserve attention for work that actually requires professional judgement.

Using Automation to Direct Attention

Towards the end of the session, Vikrant mentioned an interesting tool developed internally at his firm. He called it SentiMeter.

Their system analyses incoming emails and gives an indication of sentiment, for example whether a message is neutral, positive or potentially negative and requiring attention. Instead of treating every incoming email in the same way, the firm can use the analysis to identify communications which may deserve a closer look.

I really liked that example because it showed how automation can move beyond simply saving keystrokes and start helping people decide where to direct their attention.

So When Should you Start Thinking About Automation?

Vikrant asked me when somebody thinking about automation should begin. My answer was that the best time was yesterday. If you missed yesterday, today will do.

The important thing is not to try to craft a grand automation strategy or wait for the perfect piece of software to be developed. Just start with a repetitive task and ask a simple question: why is a person still doing this?

That approach has shaped the way we have worked at Cantab IP since 2007. The tools will keep changing, particularly as AI makes it much easier to build software. What remains useful is the habit of looking closely at a process, understanding how it works and asking whether there is a better way to do it.

For patent attorneys, this way of thinking should feel rather familiar. Curiosity, technical understanding and a tendency to tinker with how things work are already part of the job. Automation is, in many ways, just another application of the same instinct.

So the next time you find yourself doing the same tedious task for the second time, stop and ask whether you really need to do it a third time.

← Back to Blog