How to Write a Patent Disclosure: The Three-Level Framework

Most developers describe what they built. Patent attorneys need to know what problem it solves.

That gap is the single biggest reason patent disclosures go through multiple rounds of revision, produce narrower claims than they should, and cost more than they need to. The fix is structural: start with the problem, then describe your invention at three levels of specificity.

This article gives you a practical template. Each section maps directly to how patent attorneys draft claims, from the broadest independent claims to the narrowest dependent claims. Write your disclosure this way and you give your attorney the raw material for maximum claim coverage on the first pass.

Last updated: February 2026. This page is informational only and not legal advice. Consult a patent attorney for your specific situation.

The Disconnect

Developers and patent attorneys think about inventions in fundamentally different ways. Understanding the gap is the first step to closing it.

What developers write

"I built a caching layer using Redis that stores bcrypt-hashed session tokens with a 24-hour TTL, bound to session IDs via HMAC-SHA256."

Narrow claims tied to specific technologies

What attorneys need

"Authentication requires a database round-trip on every request. Under load, auth queries consume 40% of database capacity. We eliminated this by caching verification results bound to session tokens."

Broad claims covering the inventive concept

Why it matters

Implementation-first disclosures anchor the attorney to specific technologies. They can only draft claims as broad as the disclosure supports. Problem-first disclosures give the attorney room to draft at multiple levels.

Your disclosure quality determines your claim breadth

The pattern: Developers default to describing HOW they built something. Attorneys need to understand WHY it matters and WHAT problem it solves. The three-level framework bridges this gap.

The Three Levels

Patent claims exist on a ladder of abstraction. At the top: the broadest independent claims capturing the core concept. At the bottom: narrow dependent claims tied to your specific implementation. A strong patent needs claims at every level. Your disclosure must provide material for all three.

1

Core Concept

Broadest Claims

The fundamental problem and insight. Described without implementation details. If a competitor could solve the same problem differently and still infringe, this level captures it.

Example: "Automated classification of heterogeneous patient populations for personalized treatment"

2

General Technique

Medium Claims

The approach abstracted from implementation. Describes the method, components, and data flow without naming specific technologies, libraries, or languages.

Example: "Ensemble learning applied to subtype identification across multiple diagnostic markers"

3

Specific Implementation

Narrowest Claims

The actual code, algorithm, data structure, and architecture. Includes concrete parameters, measured results, and technology choices. Hardest to invalidate, but easiest to design around.

Example: "Random Forest with 1000 decision trees trained on 47 clinical features using GINI impurity"

Why all three: Level 1 captures the most territory but is most vulnerable to prior art. Level 3 is hardest to invalidate but easiest to design around. Level 2 provides the critical middle ground. A single IPR petition has page limits. Multiple claim levels force challengers to fight on multiple fronts.

Problem-Solution-Benefit at Each Level

At each level, structure your description as Problem, Solution, Benefit. This mirrors how patent attorneys frame inventions and maps directly to claim language.

Level 1 Core Concept

Element	What to Write	Quality Check
Problem	What fundamental technical limitation exists today?	Specific enough to be testable. "Slow authentication" fails. "Requires a database round-trip per request, adding 10ms under load" works.
Solution	What is the conceptual approach? No implementation details.	Multiple implementations could satisfy this description. If only YOUR code fits, it is too narrow.
Benefit	What measurable advantage results?	Quantifiable or at least observable. Not "faster" but "eliminates database dependency for active sessions."

Level 2 General Technique

Element	What to Write	Quality Check
Problem	What specific technical challenge does this technique address?	Narrower than Level 1, but not tied to any particular technology stack.
Solution	How does the approach work at a method level?	Describes steps or components without naming specific libraries, languages, or frameworks.
Benefit	What improvement over prior approaches?	Comparative. "Eliminates X that prior approach Y required."

Level 3 Specific Implementation

Element	What to Write	Quality Check
Problem	What engineering constraint drove this implementation?	Can reference specific technologies, scale requirements, or performance targets.
Solution	What exactly was built?	Code references, architecture diagrams, data structures, algorithm specifics.
Benefit	What are the measured results?	Benchmarks, test results, production metrics. Before/after comparisons are strongest.

Worked Example: Authentication Caching

Here is the same invention described at all three levels. Notice how each level adds specificity while the problem-first structure stays consistent.

Level 1: Core Concept

Problem: Each API request validates credentials against the primary database. Under load (10K+ concurrent users), authentication queries consume 40% of database capacity. P99 latency for auth-required endpoints reaches 180ms.

Solution: Bind authentication verification to a session-scoped cache with cryptographic integrity. Eliminate repeated database verification for unchanged credentials.

Benefit: Eliminates database dependency for authentication of active sessions. Authentication verification becomes independent of database capacity.

Level 2: General Technique

Problem: Verification-to-change ratio for authentication state is approximately 10,000:1. Credentials change rarely (password updates, token revocations) but are verified on every request.

Solution: On initial authentication, compute verification result and store in memory with session binding. On subsequent requests, validate session binding using cryptographic hash comparison. On credential change, invalidate all cached results for the affected identity. On cache miss, fall back to database verification.

Benefit: Reduces database authentication queries by approximately 99.99% for active sessions. Only the first request and credential change events require database access.

Level 3: Specific Implementation

Problem: PostgreSQL connection pool saturates at 8K concurrent users. Redis cluster available with sub-millisecond reads. Need cryptographic binding that survives cache node failover.

Solution: Redis cluster (3 nodes) for session cache. bcrypt for credential hashing. HMAC-SHA256 for session binding computed as HMAC(credential_hash, session_id + timestamp). Cache TTL 24 hours, binding refresh every 15 minutes.

Benefit: P99 auth latency reduced from 180ms to 2ms. Database auth queries reduced by 99.97%. Auth-related database load dropped from 40% to 0.01% of capacity.

Notice the progression: Level 1 never mentions Redis, bcrypt, or PostgreSQL. A competitor using Memcached and Argon2 would still infringe a claim based on Level 1. Level 3 is specific enough to prove the invention works but narrow enough that changing any technology escapes infringement. Your attorney needs all three to draft a resilient patent.

The Abstraction Test

If your description mentions specific libraries, frameworks, or products, you are writing at Level 3. For Levels 1 and 2, abstract up. Here is how common software terms translate:

Implementation Detail (Level 3)	Abstracted Language (Level 1-2)
calls bcrypt.compare()	applies cryptographic one-way function
stores in PostgreSQL	persists to durable storage
uses Redis for caching	maintains transient state in memory store
sends HTTP POST request	transmits data via network protocol
parses JSON response	deserializes structured data format
uses React for the frontend	renders interactive user interface
deploys on Kubernetes	executes in container orchestration environment

The test: If your description could only apply to YOUR implementation, it is too narrow for Levels 1 and 2. If a competitor could implement it differently and still infringe, you have the right level of abstraction.

The Template

Use this structure for your next disclosure. Each section maps to a specific part of the patent application.

1

The Problem

What technical domain is this in? How is the problem solved today? What specific limitation do current approaches have? What is the practical consequence?

Maps to: Background section, frames claim scope

2

The Core Insight (Level 1)

What did you realize? How does your insight translate to a solution (without naming technologies)? How does it differ from what exists?

Maps to: Summary, broadest independent claims

3

The Technique (Level 2)

What are the method steps? What logical components are involved (by function, not product name)? How does data flow? Where does the system make decisions?

Maps to: Detailed description, key dependent claims

4

The Implementation (Level 3)

What specific technologies are used? What is the exact algorithm? What data structures and parameters? What are the measured results?

Maps to: Detailed description, narrowest dependent claims

5

Alternatives and Variations

What other ways could the core insight be implemented? What approaches were tried and abandoned? How could this be applied to adjacent problems?

Maps to: Additional embodiments, broadens written description support

6

Prior Art Awareness

What existing patents, papers, or products address similar problems? For each known reference, what is the key distinction?

Maps to: Background section, non-obviousness arguments

Key principle: Sections 2, 3, and 4 describe the same invention at three levels of specificity. Your attorney uses these to draft graduated claims from broad to narrow. Section 5 (alternatives) broadens the written description support, which is critical for continuation applications.

Why This Structure Works

The three-level approach is not just a writing preference. It directly addresses the legal requirements that determine whether your patent survives prosecution and enforcement.

4.2

Average office actions per patent

AIPLA Economic Survey

$1,900-$4,500

Cost per office action response

BlueIron IP

70%

Applications amended after first office action

PatentPC 2024

Each office action is a round of revision between you, your attorney, and the USPTO examiner. Better initial disclosures mean fewer office actions, lower costs, and faster grants.

The Legal Foundation

35 USC 112(a) requires three things from your patent application. The three-level disclosure satisfies all of them:

Written Description

Must show you possessed the invention at the time of filing. Multi-level disclosure provides description at every claim level. You cannot add new material after filing.

Enablement

Must disclose enough detail for a skilled person to make and use the invention. Level 3 (implementation) provides the concrete anchor. Alternatives in Section 5 extend the scope.

Best Mode

Must disclose the best way to carry out the invention. Level 3 naturally captures this: your actual architecture, parameters, and measured results.

The Problem Can Carry the Patent

In Mintz v. Dietz & Watson (Fed. Cir. 2012), the court held that if either the problem or the solution is non-obvious, the invention is patentable. Both do not need to be non-obvious. How you articulate the problem you recognized can be the difference between an obvious and non-obvious invention.

This is why problem-first matters. Even if your technical solution feels straightforward, the problem you identified may not be. Articulating why the problem was hard to see (not just hard to solve) can be the foundation for a strong patent.

Your Disclosure Is the Ceiling

Continuation applications allow you to file additional patents from the same original specification. But a continuation cannot add new material. The original disclosure is the ceiling for all future claims. A multi-level disclosure written today supports broad claims, narrow claims, and everything in between, for every continuation you file over the next 20 years.

Common Mistakes

Four failure modes that weaken disclosures. Each one limits what your attorney can do with the material.

Too Specific

Only describing the implementation. "We use Redis with a 24-hour TTL." The attorney can only draft claims around Redis and 24-hour TTLs. A competitor using Memcached with 12-hour TTLs escapes infringement.

Too Vague

Describing at such a high level it sounds like an abstract idea. "A system for organizing data" is not patentable. The Alice/Mayo test requires a concrete technical improvement. Level 1 should be abstract but anchored to a specific technical problem.

Missing the Novelty

Focusing on how it works rather than what is new. The novel part may not be the algorithm itself but how it is applied or what problem it solves. Attorneys need you to highlight what distinguishes this from what exists.

Skipping the Problem

Starting with "I built X" instead of "the problem was Y." This anchors the entire disclosure to the narrowest level. The attorney has no material for broad claims and must schedule follow-up calls to extract the problem context.

Five Questions to Level Up Your Disclosure

Before you write, ask yourself these questions. Each one moves your thinking from implementation to concept.

1

"What problem does this solve?"

Moves from code to purpose. Forces Level 1 thinking. If you cannot articulate the problem without mentioning your technology stack, keep working on it.

2

"What are the current approaches and why do they fall short?"

Establishes prior art context. Supports non-obviousness arguments. The gap between existing solutions and your approach is where the patent lives.

3

"If someone tried to design around this, how would they do it?"

Identifies the true core of the invention. Reveals what to protect versus what is just implementation detail. Your answer defines the boundary between Level 1 and Level 3.

4

"What would change if you rewrote this in a different language?"

Separates concept from implementation. Anything that changes is Level 3. Anything that stays the same is Level 1 or Level 2.

5

"What surprised you while building this?"

Often reveals the non-obvious problem recognition that makes a patent strong. The unexpected insight, the counterintuitive discovery, the assumption that turned out to be wrong.

Frequently Asked Questions

Do I need to write all three levels for every disclosure?

Yes. Each level serves a different legal purpose. Level 1 supports your broadest claims. Level 3 provides your narrowest fallback. If you skip Level 1, your attorney can only draft narrow claims. If you skip Level 3, you may fail the enablement requirement under 35 USC 112. A complete disclosure at all three levels takes more time upfront but reduces the back-and-forth that typically adds weeks and thousands of dollars to the prosecution process.

What if I am not sure what is novel about my invention?

Start with Question 3: "If someone tried to design around this, how would they do it?" The aspects that are hardest to work around are likely the most novel. You can also describe what surprised you during development. The unexpected insights often point to non-obvious elements that are strong candidates for patent claims. Your attorney can help refine the novelty assessment, but giving them a starting point saves significant time.

Should I include actual code in my disclosure?

Include code references (file paths, line numbers) at Level 3 for provenance, but do not paste entire code blocks. Your attorney needs to understand the algorithm, not read the implementation. Pseudocode and flow diagrams are more useful than source code because they naturally abstract to Level 2. Block diagrams, sequence diagrams, and data flow charts can replace pages of dense text and are easier for both attorneys and patent examiners to follow.

How long should a disclosure be?

Quality matters more than length. A well-structured 2-3 page disclosure using this template is more useful than a 20-page document that only describes the implementation. The template's six sections force you to cover the right material at the right level of abstraction. If Section 1 (the problem) and Section 2 (the core insight) are each a solid paragraph, you are on track. Section 4 (implementation) can be longer if the technical detail warrants it.

Can I use this template for provisional patent applications?

Yes. A provisional patent application (PPA) must disclose the invention in enough detail to support future claims. The three-level structure is particularly valuable for PPAs because the provisional specification becomes the ceiling for everything you can claim in the later non-provisional filing and any continuations. Writing at all three levels from the start gives you maximum flexibility for the full application.