Software Invention Disclosure Example: A Completed Walkthrough

This is a fictional worked example. The invention, the team, the commits and the dates are invented to show what a complete software disclosure looks like. It is not a real matter, not a filed application, and not legal advice. Use it as a shape to fill in, not as a template to copy.

An invention disclosure is not a patent application, a claim set, or a legal conclusion. It is the technical record that lets inventors, business leaders, and patent counsel understand what was built, why it differs from the ordinary approach, who contributed, what evidence exists, and what filing or secrecy decisions are time-sensitive.

The completed example below is fictional. It describes an uncertainty-guided selective cache invalidation system for a software platform. The example is intentionally detailed enough to show what a strong disclosure looks like, but it does not suggest that the concept is patentable, new, non-obvious, eligible, or owned by any particular party.

Use this with the [Invention Disclosure Procedure](/invention-disclosure-procedure), [Invention Disclosure Form](/invention-disclosure-form), and [Idea Disclosure Template](/idea-disclosure-template).

What Makes This a Useful Example

A weak disclosure says:

We improved caching with AI.

A useful disclosure explains:

The technical failure in the conventional system.
The mechanism that changes system behavior.
The inputs, state, transformations, and outputs.
What is necessary and what is optional.
Alternative architectures.
Measured technical effects.
Failure and recovery behavior.
Relevant code and design evidence.
The people who conceived particular parts.
Public-release and commercial dates.

The goal is not to use legal words. The goal is to preserve technical truth before memory, staff, code, and product architecture move on.

Part One: The Ten-Minute Invention Flag

Working title

Uncertainty-guided selective invalidation of cached model outputs

What problem did the team encounter?

The platform cached model-generated classifications for uploaded documents. The original system used a fixed time-to-live value. Short time-to-live values caused repeated model inference, high GPU demand, and unstable latency during traffic spikes. Long values served stale results after the underlying model, customer policy, or document representation changed.

Global invalidation solved staleness but created a thundering-herd problem because every affected document was recomputed at once.

What did the team do differently?

The team created a controller that estimates uncertainty for each cached result and invalidates only the entries likely to have become unreliable. The controller combines model-version distance, input-representation drift, customer-policy changes, age, prior disagreement, and access frequency. It schedules recomputation according to uncertainty and available compute capacity rather than invalidating the whole cache.

Why was this not an ordinary configuration change?

Existing cache tools handled time, access frequency, and explicit key deletion. They did not evaluate whether a cached model result remained technically trustworthy after a model or representation change, nor did they coordinate selective recomputation with predicted GPU capacity.

Where is the evidence?

Architecture decision record: ADR-041-selective-model-cache.md
Pull request: PR #8842
Controller: services/cache/reliability_controller.py
Drift estimator: ml/monitoring/representation_drift.py
Load test report: benchmarks/cache_refresh_2026-05-17.ipynb
Incident report: INC-2261-global-invalidation.md

Who contributed?

Maya Chen: conceived entry-specific reliability scoring and the model-version-distance input.
Rafael Ortiz: conceived capacity-aware refresh scheduling and the hysteresis rule.
Priya Singh: conceived customer-policy dependency tracking and designed the first working combination.
Coding assistant: generated boilerplate tests and suggested alternative variable names; no independent conception is attributed to the tool.

Is anything scheduled to become public?

Public technical blog planned for September 12, 2026.
Open-source SDK release planned for September 19, 2026.
Customer demo scheduled for August 27, 2026 under the existing pilot agreement.

Why does the business care?

The mechanism reduced GPU recomputation while preserving freshness, and it supports the platform's ability to update models without a large latency event. Two enterprise customers have asked how the platform maintains result freshness across model updates.

Part Two: The One-Sentence Disclosure

The system assigns each cached model output an evolving reliability state derived from model-version distance, representation drift, policy dependencies, age, and prior disagreement, then selectively invalidates and capacity-schedules only entries whose predicted unreliability crosses a controlled threshold.

This sentence is not a claim. It is a compact technical explanation that identifies:

The maintained state.
The inputs to that state.
The selective decision.
The threshold behavior.
The capacity-aware action.

Part Three: The One-Paragraph Disclosure

The platform stores model-generated results so repeated requests do not require new inference. Instead of assigning every result a fixed expiration time, the platform maintains a reliability state for each cache entry. The state changes when the serving model changes, the document's representation drifts, a customer policy dependency changes, prior models disagree, or the entry ages. A controller identifies entries whose predicted reliability falls below a threshold, but it does not immediately delete all of them. It places selected entries in a refresh queue ordered by unreliability, expected request demand, and available inference capacity. Hysteresis prevents repeated invalidation near the threshold, and a fallback time-to-live rule applies when the reliability inputs are unavailable. The approach reduces unnecessary recomputation and avoids simultaneous global refresh while maintaining fresher model outputs.

Part Four: Full Technical Disclosure

1. Technical field

The system concerns cache management for computed outputs, particularly model-generated classifications, embeddings, summaries, scores, or decisions that may become unreliable when a model, input representation, policy, or related dependency changes.

2. Background and technical problem

The platform receives documents and returns model-generated classifications. Producing a classification requires several technical operations:

Preprocessing the document.
Constructing a representation.
Selecting and invoking a model.
Applying a customer-specific policy.
Storing the result and related metadata.

A cache avoids repeating these operations. The initial implementation used a fixed expiration interval. That design produced two conflicting failures.

Short expiration

Frequent repeated inference.
Higher GPU utilization.
Increased queue depth.
Higher tail latency.
Greater cost.

Long expiration

Results could remain after a material model update.
A representation-pipeline change could make the old output unreliable.
A customer policy change could make a technically correct old output unusable.
Global invalidation created a sudden recomputation surge.

The team tried three conventional responses:

Attempt	Result
Fixed shorter time-to-live	Improved freshness but raised GPU usage and latency
Version-keyed global cache	Prevented cross-version reuse but caused mass cold starts
Background refresh by age	Smoothed some load but refreshed many entries that were still reliable

The technical problem was therefore not merely "keep the cache fresh." It was:

How can the platform determine which computed outputs have become unreliable after technical dependencies change, and restore them without creating a synchronized recomputation event?

3. System overview

Document request
      |
      v
Cache lookup ----------------------------+
      |                                   |
      | hit                               | miss
      v                                   v
Cached output + metadata            Inference pipeline
      |                                   |
      v                                   v
Reliability-state evaluator <------ New output + metadata
      |
      +------ reliable -----------------> Serve cached output
      |
      +------ uncertain ----------------> Refresh scheduler
                                              |
                                   +----------+----------+
                                   |                     |
                              capacity ready       capacity constrained
                                   |                     |
                                   v                     v
                            recompute now          queue by priority
                                   |                     |
                                   +----------+----------+
                                              |
                                              v
                                        replace entry

4. Data maintained for each cache entry

The current implementation stores:

Cache key.
Output value.
Model identifier and model-family identifier.
Model embedding or version signature.
Input representation signature.
Policy dependency identifiers.
Creation and last-validation times.
Request frequency estimate.
Prior disagreement score.
Last reliability score.
Refresh state.
Failure count.

Not every implementation requires every field. The disclosure should distinguish the current embodiment from the broader mechanism.

5. Reliability-state calculation

For a cache entry e, the controller computes a reliability value from one or more signals:

model_distance(e): difference between the model that produced the entry and the currently preferred model.
representation_drift(e): difference between the old and current input-representation pipelines.
policy_change(e): whether a dependency used to interpret the result changed.
age(e): time since generation or verification.
disagreement(e): historical disagreement among available models or checks.
demand(e): predicted request frequency.
failure_history(e): past inability to recompute or validate the entry.

An illustrative implementation is:

risk = (
    w_model * model_distance(entry)
    + w_repr * representation_drift(entry)
    + w_policy * policy_change(entry)
    + w_age * normalized_age(entry)
    + w_disagreement * entry.disagreement_score
)

if risk >= invalidate_threshold:
    enqueue_refresh(entry, priority=refresh_priority(risk, entry.demand))
elif risk <= retain_threshold:
    retain(entry)
else:
    preserve_previous_state(entry)  # hysteresis region

The weights and equations are examples, not mandatory limitations. Other implementations may use:

Rules.
Lookup tables.
Bayesian estimates.
Learned classifiers.
Graph propagation.
Confidence intervals.
Multiple threshold classes.

6. Selective invalidation and refresh

The controller does not necessarily delete the entry immediately. It can assign one of several states:

Valid.
Valid but due for background verification.
Serve with reduced confidence.
Refresh before next use.
Refresh immediately.
Temporarily unavailable.
Fallback to a different model or rule.

The refresh scheduler considers:

Reliability risk.
Expected request demand.
Inference cost.
Available GPU or CPU capacity.
Customer service level.
Dependency group.
Deadline.
Whether a compatible result already exists.

This separates the determination that an entry is unreliable from the decision of when and how to restore it.

7. Hysteresis and oscillation control

Without hysteresis, small fluctuations near one threshold caused entries to alternate between valid and invalid states. The implemented controller uses separate thresholds:

invalidate_threshold
retain_threshold

The gap prevents repeated state changes. Alternative implementations may use:

Minimum dwell time.
Exponential smoothing.
Debouncing.
Confidence bands.
State-transition limits.

8. Fallback operation

If drift metrics or policy dependencies are unavailable, the system applies one or more fallbacks:

Fixed time-to-live.
Model-version-key invalidation.
Conservative refresh of high-demand entries.
Serving the old result with a warning or confidence reduction.
Routing to a lower-cost verification model.

The fallback prevents the reliability controller itself from becoming a single point of failure.

9. Alternative architectures

The same mechanism may be implemented in different ways:

Centralized controller

One service evaluates reliability and manages refresh queues for all tenants.

Distributed controller

Each serving node evaluates entries using locally replicated dependency state.

Event-driven controller

Model, policy, or representation updates emit events that identify potentially affected entries.

Graph-based dependency tracking

Entries are linked to models, policies, feature versions, and upstream data through a dependency graph. A change propagates only to reachable entries.

On-read evaluation

The platform evaluates reliability only when an entry is requested.

Hybrid evaluation

High-demand entries are evaluated continuously; low-demand entries are evaluated on read.

Client-side or edge operation

A device maintains reliability for locally cached model outputs and refreshes according to network, battery, and compute constraints.

10. Required and optional features

Feature	Current assessment
Entry-specific reliability state	Central to the current concept
Reliability based on changing technical dependencies	Central to the current concept
Selective action rather than unconditional global invalidation	Central to the current concept
Capacity-aware refresh scheduling	Important embodiment; counsel should assess whether it is part of the broadest supported combination
Hysteresis	Valuable dependent or fallback feature
Learned risk model	Optional implementation
GPU-specific scheduling	Optional implementation
Customer policy dependency	Important commercial embodiment but not necessary for every use

This table is not a claim chart. It records the team's present understanding so counsel can test the proposed abstraction against the disclosure and prior art.

11. Technical effects and evidence

The benchmark compared fixed expiration, global invalidation, age-based background refresh, and selective reliability-based refresh over a seven-day replay.

Measure	Fixed TTL	Global invalidation	Selective reliability refresh
GPU inference requests	1.00x baseline	1.42x during update window	0.64x baseline
P95 response latency during model update	840 ms	2,430 ms	910 ms
Stale-result test failures	3.8%	0.4%	0.6%
Peak refresh queue	18,200	91,400	12,700

These numbers are fictional for this example. A real disclosure should attach the test definition, data source, code version, and limitations.

12. Failure modes

Known risks include:

A drift signal fails to detect a meaningful change.
An overly sensitive signal causes unnecessary refresh.
The scheduler starves low-demand entries.
Dependency metadata becomes inconsistent.
An unavailable model prevents refresh.
Tenant-specific policy changes are applied to the wrong dependency group.
A learned risk estimator itself drifts.

Mitigations include conservative fallbacks, periodic full verification, dependency checksums, queue aging, customer-specific isolation, and audit logs.

13. Evidence map

Technical fact	Evidence
Fixed TTL caused repeated inference	`benchmarks/cache_refresh_2026-05-17.ipynb`, cells 12-24
Global invalidation caused queue spike	`INC-2261-global-invalidation.md`, timeline 14:03-14:19
Entry reliability state	`reliability_controller.py`, functions `score_entry` and `transition_state`
Capacity-aware scheduling	`refresh_scheduler.py`, class `CapacityWindowScheduler`
Hysteresis	`ADR-041`, section 4; tests `test_hysteresis_band.py`
Policy dependencies	schema migration `20260502_policy_dependency.sql`
Contributor discussion	design meeting notes dated April 18 and April 22, 2026

14. Contributor map

Inventorship is claim-specific and must be decided by counsel. The team should preserve facts rather than assign legal status itself.

Contributor	Recorded conceptual contribution	Implementation contribution
Maya Chen	Entry-specific reliability state; model-distance signal	Initial evaluator prototype
Rafael Ortiz	Capacity-aware refresh queue; hysteresis	Scheduler implementation
Priya Singh	Policy-dependency relation; combined architecture	Integration and failure handling
Elena Park	Benchmark methodology	Test harness and analysis
AI coding assistant	Suggested boilerplate tests and refactoring	Generated draft test cases under human direction

Questions for counsel:

Which concepts appear in the proposed claims?
Who conceived each claimed combination?
Did any contributor merely implement another person's complete conception?
Did the AI interaction generate any technical feature that a human later selected or materially developed?
Are assignments in place for every possible inventor?

Only natural persons can be named as inventors under current USPTO guidance. The ordinary conception analysis applies even when AI tools were used.

15. Ownership and external obligations

The real disclosure should answer:

Were all contributors employees or contractors when the work was conceived?
Are present assignments and further-assurances obligations in place?
Was any pre-employment code reused?
Did a customer fund or specify the work?
Was university, government, or open-source material involved?
Do third-party licenses affect distribution or patent rights?

For this fictional example, all three core contributors were employees and signed counsel-approved invention-assignment agreements before the work began. The benchmark dataset contains customer-derived documents under a data-processing agreement; no customer document should be included in a patent filing without separate review.

16. Publication and commercial history

Event	Date	Access or confidentiality
Internal prototype	April 11, 2026	Private repository
First customer pilot use	May 23, 2026	Pilot agreement; counsel to review sale/use implications
Customer architecture demo	June 4, 2026	NDA in place
Planned public blog	September 12, 2026	Public
Planned SDK release	September 19, 2026	Public open-source repository

The team should preserve the actual agreements, invitations, recordings, repository visibility history, and release artifacts. An NDA label does not answer every public-use or on-sale question.

17. Business relevance

The feature matters because it:

Reduces inference cost.
Prevents update-related latency spikes.
Supports faster model releases.
Improves enterprise confidence in result freshness.
Is difficult for customers to observe internally but may be inferable from update behavior and performance.
Could be used beyond document classification in recommendation, search, risk scoring, edge inference, and other cached computed outputs.

18. Possible protection routes

The disclosure supports a business and legal discussion, not a predetermined patent filing.

Route	Questions
Patent filing	Is the supported mechanism patentable and commercially claimable? Can competitor use be detected?
Trade secret	Can the mechanism remain secret in a server-side implementation? Are reasonable secrecy controls sustainable?
Open source	Would ecosystem adoption create more value? What patent grant does the chosen license include?
Defensive publication	Would publication help prevent later claims by others, and is loss of exclusivity acceptable?
Hold and gather data	Are additional benchmarks or alternatives needed before deciding?

19. Questions for patent counsel

Which technical combinations are actually supported by the disclosure?
What additional alternatives should be documented before filing?
Does the current description identify a technical improvement rather than only a desired result?
What prior art should be reviewed?
What are the earliest possible public-use, sale, or publication dates?
Which foreign markets matter?
Who are the inventors for the claim concepts counsel may pursue?
Does an adequately prepared provisional make sense before the planned blog and SDK release?
Should any operational details remain confidential rather than be included in a filing?
How could claims be oriented toward an observable actor or control point?

Why This Disclosure Is Stronger Than a Feature Summary

This example gives counsel several things a feature ticket usually does not:

A reason the technical problem mattered.
Evidence that conventional approaches failed.
The operative mechanism.
Alternatives and fallbacks.
Required versus optional features.
Technical effects.
Contributor-specific facts.
Dates and publication risk.
Code-level evidence.
Business and detectability context.

It also avoids legal overreach. The engineers do not declare the concept novel, non-obvious, eligible, infringed, or owned. They provide the facts needed for those analyses.

A Reusable Completion Checklist

Before sending a software disclosure to counsel, confirm that it includes:

[ ] A concrete technical problem.
[ ] The conventional approach and its limitation.
[ ] A step-by-step mechanism.
[ ] A system or data-flow diagram.
[ ] Current implementation details.
[ ] Alternative architectures and substitutions.
[ ] Required versus optional features.
[ ] Failure modes and recovery.
[ ] Measured or expected technical effects.
[ ] Relevant code, commits, tickets, and tests.
[ ] Contributor-specific conception facts.
[ ] AI-tool involvement, if relevant.
[ ] Ownership and external-obligation questions.
[ ] Earliest public, commercial, pilot, or demo events.
[ ] Planned release dates.
[ ] Business importance and detectability.

Frequently Asked Questions

Should the disclosure contain claim language?

Not necessarily. Inventors should first describe the technical mechanism accurately. Practitioner-directed candidate claim language may be useful later, but premature legal phrasing can hide missing technical detail.

Does every contributor listed become an inventor?

No. Inventorship depends on the subject matter ultimately claimed and who conceived it. The contributor record preserves evidence for counsel; it does not make the legal determination.

Should source code be pasted into the form?

Usually not in bulk. Cite the files, commits, functions, tests, and diagrams that support important facts. Include concise pseudocode or excerpts where they clarify the mechanism. Preserve access to the underlying repository.

Is a benchmark required?

No, but measured technical effects can improve understanding, support technical-improvement explanations, and help the business evaluate value. Clearly distinguish measured data from estimates.

What if the product changed after the disclosure?

Update the record. Classify later changes as already disclosed, ambiguous, or genuinely new. A continuation cannot later add new matter that the original application never described.

Related Resources

[Invention Disclosure Procedure](/invention-disclosure-procedure)
[Invention Disclosure Form](/invention-disclosure-form)
[Idea Disclosure Template](/idea-disclosure-template)
[Provisional Patent Strategy](/provisional-patent-strategy)
[Patent vs. Trade Secret for Software Algorithms](/patent-vs-trade-secret-software)
[How to Find Inventions in a Codebase](/find-inventions-in-codebase)

Primary Sources

Educational example only. It is fictional, is not legal advice, and does not determine patentability, inventorship, ownership, priority, disclosure consequences, or filing strategy for any real matter.

Back to the invention disclosure procedure