What should an invention disclosure for a software feature include?
A plain checklist for writing up a software feature before drafting: the problem, how it works, alternatives, prior work, dates, and who contributed.
Publisher: patentagents.ai
Short answer
A useful invention disclosure for a software feature covers the problem, how the feature works step by step, the variations considered, what it builds on, the dates of any outside exposure, and who contributed each idea. It is written so that a capable engineer outside the team could rebuild the feature from it.
What is an invention disclosure?
In this post, an invention disclosure is an internal write-up of a software feature, kept as source material for whoever drafts the patent application. Its job is to carry what the inventors know to that person, so the drafter does not have to guess or spend days interviewing them.
The code and the design doc record what the system does. A disclosure also records why it was built that way, what else was tried, and when things happened.
How are the problem and the solution described?
The problem takes two or three sentences: what was slow, broken, or impossible before. The solution follows as a sequence that says what comes in, what each component does to it, and what comes out. Each component is named once, and the name stays the same throughout.
A worked example with realistic values helps. "A request arrives with a token, the service checks it against a cache, and on a miss it calls the identity store" tells a reader far more than "the system validates requests efficiently."
How much technical detail does a disclosure hold?
The specification of a patent application is governed by 35 U.S.C. 112(a). That subsection calls for a "written description of the invention, and of the manner and process of making and using it," in terms that "enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same." It also says the specification "shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention."
That statute applies to the specification, not to an internal write-up. A disclosure can still borrow the spirit of it with one question: could a capable engineer who has never seen the code build a working version from this document? Where the answer is no, the gap might be data structures, interfaces, key parameters, or the order of operations. Links to files or commits can accompany the write-up as references for the drafter.
The write-up describes the version the inventors consider best, even if it is not the one currently deployed. Credentials, keys, and customer data do not belong in it.
Which alternatives belong in a disclosure?
Other ways the same idea could work belong here: a different data store, a different model, a different trigger, a batch version of a streaming design. A shipped system is one way to build the idea, and the alternatives show others.
Approaches that were tried and dropped belong here too, with the reason. A design that failed for a specific technical reason helps explain why the one that was kept looks the way it does.
What did the feature build on, and what is different?
This section names the libraries, standards, papers, and earlier systems the feature builds on, including the inventors' own earlier work. It then states, in the author's own words, what the author believes is different. Specific statements work best. "Caches results by input hash instead of by user" is useful. "Faster and smarter" is not.
The section records the author's view and does not try to establish novelty. A plain statement of what is believed new, and what is borrowed, gives anyone who later searches or assesses the idea an honest starting point.
Which dates does a disclosure record?
The dates cover when the idea took shape, the first prototype or commit, and every time the feature was exposed outside the team. Exposures include a public repository, a conference talk, a published post, a demo to outside users, a pilot, and any offer to sell or sale.
Section 102(a)(1) of title 35 provides that a person is entitled to a patent unless "the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention." That list is why the exposure dates above are worth recording.
Section 102(b)(1) provides that a disclosure made one year or less before that date is not prior art under 102(a)(1) if the inventor, a joint inventor, or someone who obtained the subject matter from either of them made it, or if one of those people had already publicly disclosed the same subject matter.
Whether a given event falls within these provisions depends on its facts. A record of what happened and when, with a link or a dated screenshot where one exists, is what that assessment starts from.
Who counts as an inventor, and what is recorded?
Section 100(f) of title 35 defines "inventor" as "the individual or, if a joint invention, the individuals collectively who invented or discovered the subject matter of the invention." Section 116(a) adds that "Inventors may apply for a patent jointly even though (1) they did not physically work together or at the same time, (2) each did not make the same type or amount of contribution, or (3) each did not make a contribution to the subject matter of every claim of the patent."
For each idea, the write-up can note who proposed it and who built it, with dates where known. Those notes are information relevant to the inventor definitions in sections 100(f) and (g) and to the joint-application provision in section 116(a). None of those provisions refers to job title.
What does a complete set of inputs look like?
A complete set holds the write-up, the diagrams, and the code context, with anything undecided marked as an open point. PatentAgents.ai can read that set and start an editable claim draft and specification draft, and export either as a Word .docx.
Disclosure write-up flow
- 1Describe the problem and the solution
- 2Add a worked example and technical detail
- 3List alternatives and prior work
- 4Record dates and contributors
Sources
Tradeoffs and limits
- A fuller write-up takes more time to produce and gives the drafter more to work from.
- Recording every outside exposure can feel like extra bookkeeping on a project. The record is an internal document kept for whoever prepares the application.
- Listing alternatives that were never built makes the document longer. It keeps the shipped version from being the only embodiment on record.