Answers · Invention & Disclosures
How do we capture patentable inventions from agile software teams?
Updated June 2026
The short answer
Attach invention capture to ceremonies the teams already run instead of asking developers to file disclosures on their own time. In practice that means a short invention check inside the sprint retrospective, a flag in the definition of done, an IP gate before any public release, and a facilitated harvesting session each quarter or release cycle, which surfaces documented disclosures in volume.
Agile development is genuinely hostile to traditional disclosure programs. Inventions emerge incrementally across sprints with no single aha moment, and continuous shipping can publicly disclose an invention before anyone realizes it was one.
Why agile shreds inventions
Four forces work against capture. Inventions arrive in fragments: the novel mechanism is spread across five tickets, three contributors, and two sprints, so no individual ever experiences having invented something. Velocity pressure means anything that smells like paperwork loses to the sprint goal. Engineering modesty runs deep in software culture, where a genuinely novel synchronization scheme gets described as just a refactor. And many developers carry an inherited skepticism that software is patentable at all, so they never raise their hand.
The fifth force is the clock. Shipping code, publishing a blog post, presenting at a conference, and open-sourcing a component can all count as public disclosure. In the US, an inventor's own disclosure generally opens a 12 month grace period for filing; many other jurisdictions offer no grace period at all. Whether a specific release started a clock is a question for your patent counsel. The operational lesson is simpler: catch inventions before they ship, because afterward your options may already be narrower.
Capture points that fit the cadence
Work with the ceremonies, not against them. Add one question to the definition of done: did this work solve a problem in a way a competitor would struggle to copy? A yes costs the developer one checkbox and creates a lead. Add a 15 to 30 minute invention review to a monthly or per-sprint retrospective, walking the recent hard problems. Treat architecture decision records as disclosure seeds, since a good ADR already contains the problem, the chosen mechanism, and the rejected alternatives, which is most of a disclosure's skeleton.
Then add the two heavier pieces. A pre-release IP gate puts one review step in front of launches, conference talks, and open-source releases, which is where unprotected inventions actually escape. And a facilitated harvesting session each quarter or release sweeps up everything the lightweight hooks missed: our ipScan sessions surface disclosures in volume, and the format suits software teams because the engineers only have to talk.
What software teams undercount as inventions
The patentable material in software is usually a technical solution to a technical problem: infrastructure and scaling mechanisms, performance techniques, data structures and storage layouts, synchronization and consistency schemes, ML pipeline and training innovations, compression, routing, scheduling. Product features and business logic rarely qualify; the machinery underneath them often does.
Whether any specific invention is patentable under current subject-matter law is your patent counsel's judgment, and US software patentability has real constraints. The team's job is capture, not legal screening: flag the technical solutions, document them while the contributors still remember the mechanism, and let counsel triage. A disclosure that becomes a trade secret or a defensive publication instead of a filing still did its job.
Related questions
Are software patents worth pursuing after Alice?
Subject-matter law has tightened, and counsel should screen candidates against it, but software-implemented inventions are granted in volume every year. Capture is cheap and preserves the option; deciding not to file is best made disclosure by disclosure with counsel, not as a blanket policy.
Will this slow our sprints down?
The standing hooks cost minutes: one checkbox in the definition of done and a short block in a retro. The facilitated session is a few hours per engineer per quarter, and it is the piece an outside team can run for you.
How should we handle open source releases?
Route them through the pre-release IP gate. Releasing code can start disclosure clocks and create prior art against your own later filings, so review happens before publication, not after. The gate also catches inventions worth filing ahead of the release.
Who should own invention capture in an agile org?
Give each team one named owner for the capture hooks, usually the engineering manager or tech lead, and route what they flag to the IP counsel or review committee for decisions. Capture fails when it is everyone's job and succeeds when it is someone's.
Sweep a release cycle and see what surfaces
One facilitated session with your platform team, timed before the next release, shows what your sprints have been shipping unprotected. The discovery call is free.
Talk with Our TeamRelated
ipCapital Group is a consultancy, not a law firm, and nothing on this page is legal advice. Dollar figures on this page are typical market ranges for professional IP services, drawn from published sources and industry experience across a variety of providers. They are not an ipCG quote or rate card; every ipCG engagement is individually scoped and priced. See how our pricing works.