At a company, most of the work around patents isn’t writing them. It’s reading them.
When you develop new equipment or a new product, the first thing you have to check is that you’re not stepping on anyone else’s patents. You agree with the department in charge on how far to look, patents in that technology area get pulled, and that list comes down to the working teams. Our job is to read the summaries one by one and sort “this needs a look” from “this doesn’t.” Only what’s left goes on to detailed review — the work of taking someone else’s claims apart line by line and holding them up against our product. This is the next installment of the work I wrote about in № 005.
This time, the patent team did a first pass on the contents and sent us a list. We were grateful, but just in case, we decided to double-check. For that, the list we’d been given wasn’t enough. I registered for API access with KIPRIS and WIPS, two Korean patent databases, pulled the raw data, and built a database myself. The first step was getting to a state where all of our company’s patents and our competitors’ patents were loaded and could be held up against each other at any time. Two days went by like that before the review had even started.
This is where the path split. Put the patents in a table and read them one at a time, and it’s simply hundreds of items’ worth of labor. Instead, I connected them as a graph. Which patent cites which, which elements recur where, where our company’s rights and our competitors’ rights overlap and where the gaps are. Things that were invisible in a table became visible in a graph.
On top of that, I added TRIZ. It’s an old methodology built by taking apart countless patents and concluding that “inventions ultimately resolve contradictions in only a handful of ways.” It was originally a tool for making new inventions, but it also works as a ruler for classifying which contradictions existing patents resolved, and how. When the graph shows an empty spot, TRIZ suggests a direction for filling it. At that point, I had no idea what this would lead to.
Then came the main work. We marked each item as “needs a look” or “doesn’t.” We had AI mark them first, had people on the team mark them separately, and compared the two. But here we changed one thing about the order, and that became the heart of this installment. People took a second look at what AI had thrown out as “doesn’t need a look” and at what it had left as “unclear.” Then another person checked those items once more.
Why the thrown-out side, of all things? Because that’s how the rule for judging infringement is shaped. If someone else’s patent claim lists four things, A, B, C, and D, our product has to have all four to infringe. If even one is missing, it isn’t infringement, in principle (there’s a separate exception where the missing one is recognized as effectively the same thing). This is called the all-elements rule.
Turn it around and it’s a little frightening. It means that misreading just one of the four flips the entire conclusion. If a single wrongly discarded item is mixed into the “doesn’t need a look” pile, that one item can come back years later as a warning letter. No matter how many times you recheck the side you passed, that item won’t turn up there. So we concentrated people’s time not on what passed, but on what was cut.
We concentrated on rechecking what AI threw away. Not what it passed.
- Getting the data
- Raw data collected via API, database built · tools do it all
- Extraction · noise removal
- AI-led · where it pays off the most
- First pass: needed or not
- AI rough cut + people re-verify what was cut
- Claim charts
- AI drafts only · people make the call
- Infringement calls · response
- People only · the place of patent attorneys and legal
- Finding new patents
- The graph and TRIZ point out the gaps
That much was what we had set out to do. But with the graph and TRIZ in place, the review wasn’t the only thing that got done. The empty spots were right there in plain sight, and nearly ten new patent proposals came out of them. The patent team agreed, and with existing staff pitching in, we were able to write, in one go, the volume the team had been asking for. The map we made to avoid infringement ended up showing us where to stake our own claims.
Afterward, I tried summing it all up in one line, and it left me feeling a little strange. The API does the searching. The database does the organizing. AI makes the first-pass call, and people recheck what AI threw away. New ideas come from the gaps in the graph, and AI even drafts the patent applications. Not that we file them as is, of course.
So what, then, is the patent team’s role?
I’m not saying it disappears. There wasn’t a single stage of this work that ran without the patent team. Setting the scope of verification, keeping only what was valid, making the final call — that was all them. But where the center of gravity of that role is shifting seems fairly clear. Away from finding, organizing, and writing, and toward deciding what to look at, and designing how much of it to turn into patent rights.
This probably isn’t only about patents. I think work that’s essentially reviewing or examining is, by and large, shifting from the same place, in the same way. I sit in that seat myself, so it’s hard to write about it as if it were someone else’s story.
My job wasn’t to have the judging done for me. It was to decide which pile people’s time should go to. A single wrongly discarded item comes back years later as a warning letter, and no amount of rechecking what passed will turn it up — so I bet that time on the rejected pile.
One last thing. The patent texts themselves are public data, so you can pull as many as you like through an API. The problem is what comes after. Most review lists that show what we’re looking at, and why, are confidential. The moment you upload that list to an outside model, a whole different problem begins. The judging should be done with a model running locally, and that’s what I did.
A researcher on a team that takes technology into mass production. Working where a handful of people weather a flood of requirements, I’m trying to set AI up not as a search tool but as hands and feet. I write more about what didn’t work than what did, and more about process than conclusions.