Why We Built SILO Ourselves for Patent Document Management

Buying a document system would have been faster. Here is why we are building our own patent document infrastructure instead, and why the deciding factor was not features, but where a client’s data lives. 

Pick any active patent matter and ask a plain question: where does it live? The answer is usually a list. The specification sits in one place, the prosecution history in another, the inventor’s original disclosure somewhere in an email thread, the prior art on a shared drive, the interview notes in a folder only one person knows how to find. Every firm runs some version of this. Most stopped noticing years ago. 

The cost of that is not really about time, and this series has been clear that speed is not our story. The cost is that no general-purpose document system understands what any of those files actually is. To a standard system, a file wrapper is a folder of PDFs. To a patent attorney it is a living record: a priority date that governs everything downstream, deadlines that do not move, an examiner with a history, a family of related applications that rise and fall together, and a prosecution record that quietly decides which arguments are still available and which were given away three office actions ago. 

SILO is the part of SLW Labs built to close that gap. For readers meeting it here, SLW Labs is the firm’s in-house innovation platform, and SILO is its document layer: intelligent document infrastructure designed around the way patent matters actually behave, so the other Labs tools have something underneath them that knows what a matter is. It is in advanced development rather than production today, which is the honest status, and we would rather say that plainly than oversell it. What matters for this article is the choice underneath it. The interesting decision was never what to build. It was whether to build at all. 

We looked hard at not building this. For a while the plan was to buy. Off-the-shelf document systems are mature, and standing one up would have been faster and cheaper than the road we took. Two things stopped us. 

The first was the problem above. A system that treats a patent matter as a generic folder cannot be taught prosecution after the fact. The understanding has to live in the foundation, in how the thing is built, not painted on afterward. 

The same gap shows up earlier than filing. When an inventor’s disclosure arrives, the useful question is rarely only what is in this document. It is what has this client shown us before, what is already on file, and what did we argue in a neighboring matter that we now have to live with. A folder cannot answer any of that. A system that understands the client’s portfolio can at least raise the question, which is most of the battle. 

The second reason was the question that turned out to matter most: where does the client’s data live, and who can reach it? A patent portfolio is among the most sensitive things a company owns. Handing those documents to an outside platform the firm does not control, and cannot fully answer for, was a line we were not willing to cross. Client confidentiality here is meant to be architectural, a property of the system itself, not a paragraph in an engagement letter. 

Clients are the reason this is not abstract. More of them now arrive with the kind of security questionnaire once reserved for software vendors: who can access our matters, where is the data stored, how long is the data stored, what happens when an employee leaves, can you produce an access log. A firm that has handed its document layer to an outside platform is often quoting someone else’s answers. A firm that built its own can answer for itself, which is increasingly what serious in-house teams expect. 

Here is where it bites in practice. File a continuation and it inherits the patents entire history: the priority claim, the prior art of record, the estoppel built up over years of argument. A document system that knows none of that is not neutral. It is a liability, because it lets a matter be handled as though it started yesterday. The infrastructure either carries that history or it does not, and most infrastructure does not. 

Building our own is the harder road, and we will say so. We own the maintenance, the roadmap, and the mistakes. What we get back is control over exactly where a client’s documents sit and who can see them, which for patent work is not a close call. The requirement that settled it came straight from a client security review. They asked whether we could produce, on demand, a complete log of who had accessed their matters and when, going back years. With an outside platform, the honest answer would have been that we would need to ask our vendor. That was not an answer we were willing to give. Building our own means the log is ours, the answer is ours, and we can stand behind both.

Building in-house does not mean writing every line alone. SLW Labs runs as a small core team plus a development partner working under the firm’s direction, with attorneys and technologists shaping what gets built. What stays in-house is the part that counts: the firm sets the requirements, owns the governance, and decides where the data lives. That is the line between building a thing and renting one.

“The honest version is that we could have bought something and been finished months ago. What stopped us was a boring question that turned out to be the whole thing. If a client asked us to draw the exact picture of where their documents live and who can reach them, could we draw it and be proud of the answer? With the options in front of us, we could not. So we are building the one where we can.” – Nathan Elder, Principal, SLW 

That is the why. The next article, with Tom Ernster, takes up the harder and more interesting part: what it means for document infrastructure to understand a patent matter, rather than simply hold it.

Learn more about SLW Labs.