IP managers in in-house patent departments often ask me:
“How do I get the inventors to write better invention disclosures for software-based inventions?”
The answer is simple: In the end, it’s all about convincing the patent examiner that you created a non-obvious solution to a technical problem.
But the devil is in the details.
The tricky thing is that you can’t add additional technical details anymore after the patent application has been filed at the patent office. The technical solution – as it was explained in the patent application – is fixed then.
You may bring up additional arguments in the discussion with the patent examiner, but you can’t add any technical substance. This means that patent prosecution is generally a front-loaded process, and the invention disclosure must be carefully worded!
Here are some tipps I tell the inventors I work with:
Don’t try to write a patent
First and foremost: When drafting an invention disclosure document, don’t try to write a patent, even if you’ve read lots of patents.
Patents use very special wording with a strange mix of technical and legal language (with terms like “embodiment”, many “and/or” combinations and “may’s”.). So as a developer, don’t try to be a patent attorney.
Just use plain technical language. Refrain from mimicing any legalese you might have seen. Also, don’t use internal slang that is well-established only within your company. Stick to the technical terminology commonly accepted in your field instead.
Don’t try to turn the virtual into something physical
Especially concerncing software inventions, don’t try to make it sound physical or tangible if it isn’t.
If the invention is about an algorithm, just explain how it works on a functional level. What’s the input? What’s the output? What does it do and how does it do it?
Don’t try to disguise the algorithm in something machine-like. Don’t say “interface module” or “encoding engine”, but just say that the data is encoded using a certain algorithm. If the invention is about the function, then focus on that.
But if it is about a hardware-based invention at the intersection of the software and the hardware, you have to explain the hardware part of it as well, obviously.
Write an elevator pitch
After you’ve drafted the entire invention disclosure, take a step back and imagine you’d have to explain it to someone on an elevator ride. In one minute, in just a couple of sentences.
As the “story” in a patent always has the same structure, don’t re-invent the wheel. Stick to this trusted structure:
- Which field you are talking about (e.g. industrial robots)?
- What is the industry standard until now and which are the problems you encountered in the known solutions?
- What is the principle underneath your solution to solve these problems?
Try to carve out a very high-level, mostly functional explanation of the invention. This inventive gist, its concept or underlying principle, should cover all the specific facets of how it is (or can be) implemented in practice.
Here’s a template for an invention elevator pitch:
In the field of …, it is common to …. But the problem is that …. The invention solves this by….
The inventive principle
Besides the overall context in the elevator pitch, the perfect invention disclosure also needs to clearly convey some more aspects of the invention principle:
- Which technical problems are solved by the innovation?
- How does the invention solve these problems on a conceptual layer?
- Why is this better than the known approaches?
- Why is the solution uncommon or surprising?
The concrete realization(s)
In the invention disclosure the concrete realization needs to be disclosed, too:
- How can the invention be put into practice?
- How is it – e.g. in a prototype – put into practice?
- Possible workarounds: How could it be put into practice?
With respect to the latter point, you maybe didn’t build it that way or maybe it’s not even feasible today, given the technology we have, but ask your self how would possible workarounds look like in maybe 10 years? Remember that a patent has a maximum lifetime of 20 years.
The answers to these questions are important for the patent attorney to understand both the conceptual difference over the prior art (to obtain the optimum scope of protection) and the specific technical realization (to meet the disclosure standard).
One complete walkthrough
As a patent attorney I love to have one complete walkthrough of the preferred realization of the invention with concrete data, specific examples for inputs, outputs and intermediate results.
What are the technical use cases?
For example, if the invention is about robotics, industrial automation, smart factories or cloud computing – these things are rather technical and won’t create any fundamental problems during patent prosecution.
But if the invention is more on the theoretical or non-technical side, the stage for the patent prosecution procedure must be prepared carefully and the patent application must explain why it is technical.
So any conceivable technical applications and use cases should be put into the invention disclosure. The technical considerations about the hardware have to be captured as well. That’s one way to make AI technical, for instance, irrespective of a particular use case.
The invention hierarchy
The concrete technical realization is important and based on the recurring question: How do you put your invention into practice?
But we do not aim at a patent for a specific implementation only, as the patent would be too easy to work around.
What the invention disclosure needs to make clear is the invention hierarchy: On top is the conceptual idea, and at the bottom is the specific technical realization. The important part is to connect these two layers by a series of well-defined intermediate layers that can later serve as fallback positions.
This is because we usually start the patent examination procedure before the patent office with a patent claims that defines the broadest possible scope we think we can get. Then I as the patent attorney negotiate with the patent examiner whether the invention meets the patentability criteria on this level of abstraction.
For example, if the examiner finds prior art which already anticipates the major aspects of the broad concept, we have to narrow down the target scope of the monopoly to work around this prior art (so that the invention is novel and non-obvious).
And here we need step-by-step fallback positions to allow us to limit our desired scope in a controlled manner without immediately falling down to the concrete realization at the bottom of the pyramid.
So keep in mind this short checklist of the aspects that should be stated clearly in the invention disclosure:
- What are the known features you are using which are necessary for the invention to work?
- Which of the unique features are absolutely necessary for the invention to work?
- Which of the unique features are optional, nice-to-have add-on features which bring certain advantages, but are not absolutely necessary?
You can find more tips and tricks in this 12-minute snippet from an in-house inventor training:
What’s up next?
Learn more tips and tricks for great digital patents on my “Resources for in-house patent managers” page.