Invention Disclosure Procedure: A Step-by-Step Guide
Most engineering teams have no procedure for capturing inventions. The gap is not filing. It is recognizing what to file.
Engineers solve novel problems every week. They build workarounds for industry limitations, design new architectures, and create algorithms that didn't exist before. Almost none of it gets documented as an invention, because there is no process that tells them when or how.
This page provides a repeatable, seven-step procedure for recognizing, documenting, and routing inventions from engineering work into the disclosure pipeline. It is designed for engineers and engineering managers who want a standard operating procedure their team can follow.
This page is informational only and not legal advice. Consult a patent attorney for your specific situation.
When This Procedure Applies
Not every piece of engineering work needs an invention disclosure. This procedure applies when any of the following triggers are present:
Novel algorithm
You wrote a new algorithm or a significant variation on an existing one to solve a specific problem.
Unique data structure
You designed a data structure that organizes, indexes, or accesses data in a way you haven't seen done before.
New system architecture
You created an architecture that connects components in a non-obvious way to achieve a specific result.
Industry workaround
You solved a problem that others in the industry work around rather than fix, or that existing tools handle poorly.
Performance breakthrough
You achieved a measurable performance improvement that others in the field have not, using a distinct approach.
The 7-Step Procedure
Follow these steps in order. Each builds on the previous one.
Recognize the invention
Ask yourself: did I solve a problem differently than the obvious approach? If you tried the standard solution and it didn't work, or you skipped it entirely because you saw a better way, that divergence is the signal. The invention is not the code. It is the decision to solve the problem a different way, and the method you used to do it.
Document it immediately
Record the following while it is fresh: the date, all contributors, the problem you were solving, the approach you took, and why your approach is different from the obvious alternative. Delay is the enemy of disclosure. Details fade, contributors move on, and public releases can start the clock on filing deadlines. A rough document today is worth more than a polished one next quarter.
Identify the inventive concept
Separate the concept from the code. The inventive concept is not your Python function or your Go package. It is the method, system, or process that your code implements. Ask: if someone rewrote this in a completely different language and framework, what would stay the same? That invariant is the inventive concept.
Do a preliminary landscape review
Search patents (Google Patents, USPTO), academic papers, and existing products. Document what you find, including results that are close but not identical. Record your search terms, the databases you checked, and the closest results.
Two cautions. This is a landscape review, not a patentability opinion, and it is not a substitute for a search your counsel directs. And do not let it stop you from finishing Step 5. Engineers routinely find something superficially similar, conclude the idea is taken, and abandon a disclosure that a practitioner would have viewed differently. Write down what you found and keep going. If the review surfaces something close, flag it for counsel rather than deciding yourself, since material information can carry disclosure obligations later in prosecution.
Write the disclosure
Write at three levels of detail. First, a one-sentence summary of what the invention does and why it matters. Second, a one-paragraph description that covers the problem, the approach, and the key technical differentiator. Third, a full technical write-up with architecture, data flow, algorithms, and measured results. Each level serves a different audience: the summary for triage, the paragraph for review, the write-up for filing.
Get internal review
Two reviews are needed. A technical lead confirms that the description is accurate, complete, and captures the actual inventive step (not just the implementation). Then, if your organization has IP counsel, they assess whether the concept may be worth pursuing. The technical review ensures correctness. The legal review assesses opportunity. Both are necessary before deciding to file or archive.
Route the disclosure
The last step is a routing decision, not a yes-or-no on filing. There are more than two outcomes: file a patent application, hold it as a trade secret, publish defensively so nobody else can patent it, open-source it deliberately, combine it with a related disclosure, or park it pending more technical data. Record which route you chose and why. The reasoning is what makes the decision reviewable a year later.
If filing, work with a patent attorney on a provisional. A provisional can support an earlier effective filing date for the subject matter it adequately describes, which is the part teams underestimate: a thin filing that omits the architecture, the alternatives, and the technical effects may provide little useful support when you convert within twelve months. Counsel decides whether the description is sufficient.
If not filing, archive in a structured, searchable format under a documented retention and re-review policy rather than keeping everything forever. Retention has costs too, including discovery exposure and trade-secret risk. Under first-inventor-to-file, private records are useful for chronology, contribution, and ownership questions, but they do not preserve rights the way many engineers assume.
Common Mistakes
These are the patterns that cause engineering teams to lose inventions or file weaker disclosures than they should.
Waiting until the product ships
By the time a product launches, the details of what was novel are buried under months of iteration. Worse, a public launch can start the one-year clock for filing in the U.S. and may immediately bar filing in other jurisdictions. Document inventions when they happen, not when the product ships.
Describing the code instead of the method
A disclosure that reads like API documentation is too narrow. It ties the invention to a specific implementation. Describe the method, the system, the process. If someone could achieve the same result with different code, your disclosure should cover their approach too.
Skipping the landscape review entirely
Without any landscape review you do not know where the invention sits, so the disclosure may miss the differentiator that actually matters. The review does not need to be exhaustive and it is not a patentability call. It needs to happen and it needs to be written down.
One person doing it alone
A single engineer writing a disclosure in isolation misses contributions from collaborators, skips the technical review that catches errors, and often underestimates (or overestimates) what is actually novel. Invention disclosure is a team activity, even when the core insight came from one person.
Tools and Templates
You do not need specialized tools to follow this procedure, but the right tools can accelerate Steps 3 and 4 significantly.
Concept Scanner
For Steps 3 and 4, the Concept Scanner can help identify the inventive concept in your codebase and surface prior art considerations. It analyzes source code to find technical concepts that may be distinctive. Not a patent scanner: a patent attorney determines what is worth filing.
Disclosure framework
For Step 5, see the three-level disclosure framework. It provides the structure for writing at the one-sentence, one-paragraph, and full write-up levels, organized around the problem your invention solves rather than the code that implements it.
Frequently Asked Questions
How long does this procedure take?
Steps 1 through 3 can be done in under an hour if you document immediately after the inventive work. Step 4 (landscape review) typically takes a few hours. Step 5 (writing the disclosure) takes one to four hours depending on complexity. Steps 6 and 7 depend on your organization's review cycle. End to end, the inventor's time is roughly one working day.
Who should own this procedure within an engineering team?
An engineering manager or technical lead is the natural owner. They see the work across the team, can recognize when the triggers apply, and can schedule the review step. The inventor writes the disclosure, but the process owner makes sure the procedure runs.
What if we do not have IP counsel?
Follow Steps 1 through 5 anyway. A well-written disclosure is valuable with or without immediate legal review. When you are ready to engage a patent attorney, you will hand them a structured document instead of a verbal explanation. That saves time and money on both sides.
Can this procedure work for open-source projects?
Yes, with an important caveat: public disclosure of the invention (including publishing it in an open-source repository) can start filing deadlines and may limit your options in some jurisdictions. If you plan to file, document the invention and consult counsel before making the code public. The procedure itself is the same.
What is the difference between an invention disclosure and a patent application?
An invention disclosure is an internal technical document written by the inventor. A patent application is a legal document drafted by a patent attorney. The disclosure is the input; the application is the output. This procedure covers the disclosure side. A patent attorney handles the application.
Disclaimer. This page is informational only and not legal advice. It does not constitute legal services or create an attorney-client relationship with Obviously Not. Consult a qualified patent attorney for your specific situation. Intellectual-property protection can be time-sensitive: public disclosure, product release, or open-source publication may affect available rights.