Document Infrastructure that Knows Patent Prosecution

Document Infrastructure that Knows Patent Prosecution

A generic system sees a folder of files. A patent matter is not a folder. This is what changes when the infrastructure understands the difference.

Open a patent matter in a standard enterprise document system and here is what it sees: a folder, some PDFs, a handful of Word files, dates that mean nothing to it. Open the same matter in front of a patent attorney and it is a different object entirely. There is a priority date that governs everything downstream. There is a file wrapper whose contents limit the arguments still on the table. There is an examiner with tendencies. There is a family of continuations and divisionals that move together, so a choice made in one can bind the rest.

SILO’s design premise is that the infrastructure should see the second version, not the first. That sounds obvious. It is not how most document systems work, because most were built to hold anything for anyone, and a system built to hold everything tends to understand nothing in particular.

SILO is the document layer inside SLW Labs, the firm’s in-house innovation platform, and it is in active development. Where the other Labs tools do work on top of a matter, drafting, review, training, SILO is the thing underneath that knows what the matter is. This piece is deliberately structural. It is about what the infrastructure understands, not a catalogue of features.

It helps to be precise about the division of labor. ARTY drafts and reviews. SimProf trains. SILO does not try to do their jobs. Its job is to be the ground they stand on: the place where a matter is defined once, correctly, so the tools above it work from the same understanding rather than each keeping a partial copy of its own.

Start with the unit. In SILO the patent matter is a first-class object, not a folder that happens to contain patent files. A matter carries its own identity: the application it represents, the priority date it claims, the deadlines attached to it, the related matters it is bound to, and the wall that separates it from every other client’s work. Those are not labels added on top. They are the structure.

Contrast that with the default. In a general system the closest thing to a matter is a folder someone named well, and the closest thing to a deadline is a date typed into a field that triggers nothing. Knowledge lives in the people, which works until the person is on vacation, or has left, or simply never knew this application shares a priority claim with three others. Infrastructure that models the matter does not forget those things when a person does.

That structure is what lets the system respect the things a careful attorney respects without being reminded. A continuation stays connected to its parent. An IDS reflects what is of record in a related matter. A statement made to overcome a rejection remains part of the history that follows the family forward. Infrastructure that models those relationships can hold the line on them. Infrastructure that sees only folders cannot, and the gap tends to show up at the worst possible moment.

Take the most ordinary example in a firm this size, the conflict wall. When a matter genuinely knows which client it belongs to, keeping that client’s work invisible to a team on an adverse matter stops being a rule people have to remember and becomes something the system does on its own. The same holds for an IDS. If the infrastructure knows a reference surfaced in a related application, the duty to consider it no longer rides entirely on one attorney recalling a case they touched eighteen months ago.

“People assume the hard part of something like this is storage. Storage is the easy part, and it has been for years. The hard part is that the system has to respect the same boundaries a careful attorney does. This matter is not that matter. This client cannot see that client. This document belongs to a record that has a history, and the history matters. We are building those boundaries in at the foundation, because the alternative is trusting that everyone remembers them every single time, and that is not a plan.” -Tom Ernster, Director of Information Technologies

This is why the article is structural rather than a feature tour. Features are easy to add and easy to demo. What is hard, and what matters, is whether the foundation understands the domain, because everything built on top either inherits that understanding or inherits its absence. A clever feature standing on a foundation that treats a patent family as five unrelated folders is a clever feature that will eventually get something wrong.

The payoff is quiet, which is the point. When the infrastructure understands the matter, the conflict wall is not a manual checklist someone hopes was followed. The link between related cases is not a note in one attorney’s head. The history travels with the file.

Here is of difference this is built to make. Client instructions have a way of living wherever they land, which usually means one attorney’s inbox. If in-house counsel sent a preference about claim scope in a message about one application, the attorney answering a rejection in a sibling case might never learn it existed. When correspondence is captured to the matter the moment it arrives, as we are building SILO to do, that instruction becomes part of the record rather than an inbox. The attorney drafting the next response starts from guidance they never personally received, and so do the drafting tools working under that attorney’s review. Nothing gets smarter. The matter simply stops losing what it is told.

None of this is visible to a client on a good day, and that is how infrastructure is supposed to work. It earns its keep on the bad day. In the next article, Anup Suresh takes up the part clients ask about first: how trust and governance are engineered into every tool in the Labs stack, SILO included.

Learn more about SLW Labs.