Invention Structuring

Invention Structuring

Structure the invention into a formal disclosure based on: $ARGUMENTS

Adapted from the refinement pattern in /research-refine for patent invention decomposition.

Constants

• No external reviewer model — invention decomposition validation is self-review (Claude re-reads its own decomposition fresh and challenges it; see Step 6 and auto-review-loop's "Self-Review Backend (No Second Model)" for the full rationale).
• MAX_REFINEMENT_ROUNDS = 3 — Maximum structuring iterations

Inputs

1. Invention description from $ARGUMENTS
2. patent/INVENTION_BRIEF.md if exists
3. patent/PRIOR_ART_REPORT.md — prior art landscape
4. patent/NOVELTY_ASSESSMENT.md — novelty analysis

Shared References

Load ../shared-references/patent-writing-principles.md for the Problem-Solution-Advantage framework and claimable subject matter guidelines.

Workflow

Step 1: Problem-Solution-Advantage Framework

Structure the invention using the universal patent framework:

Technical Problem (要解决的技术问题):

• Derived from prior art deficiencies identified in NOVELTY_ASSESSMENT.md
• Must be a specific, technical problem (not a commercial or social problem)
• Statement format: "The technical problem to be solved is how to [specific technical objective] given [specific technical constraint]."

Technical Solution (技术方案):

• The invention's specific technical contribution
• Focus on the mechanism, not the result
• Must be described at a level that matches the intended claim scope
• Identify which features are known vs. inventive

Advantages (有益效果):

• Measurable or quantifiable improvements over prior art
• Must result from the inventive features, not just good engineering
• Include specific technical effects if known (e.g., "reduces processing time by 40%")

Step 2: Invention Decomposition

Break the invention into three layers:

Core Inventive Concept (核心发明构思):

• The minimal set of features that make the invention patentable
• This maps to the independent claim scope
• Test: if you remove this feature, the invention is no longer novel

Supporting Features (支撑性特征):

• Features that make the invention work well in practice
• These become dependent claim material
• They narrow the scope but add practical value

Optional Features (可选特征):

• Implementation details, preferred parameters, alternatives
• These become embodiment material
• They support broader claim interpretation

Step 3: Claimable Subject Matter Identification

For the core inventive concept, determine what categories of claims to draft:

Step 4: Drawing Plan

Plan what figures are needed to support the claims and specification:

If user has provided figures, reference them here. If figures are missing, note what is needed.

Step 5: Dependency Mapping

Map feature dependencies to plan the claim hierarchy:

Independent Claim 1 (method, broadest scope)
├── Core inventive feature A
├── Core inventive feature B
└── Known feature C (for context)

Dependent Claim 2 → narrows feature A with specific implementation
Dependent Claim 3 → narrows feature B with specific parameters
Dependent Claim 4 → depends on 2, adds optional feature D
Dependent Claim 5 → alternative implementation of feature A

Step 6: Self-Review Validation

No second model is available, so this validation is performed by Claude re-reading the Problem-Solution-Advantage summary, the feature decomposition, and the claim plan fresh from the Step 1-5 output (not from memory of writing it), adopting a patent attorney's skeptical perspective. Assess:

1. Is the Problem-Solution-Advantage framework correctly applied?
2. Is the core inventive concept correctly identified? Are there features that should be core but are listed as supporting (or vice versa)?
3. Are the planned claim categories sufficient to protect the invention?
4. Is the drawing plan adequate for enablement?
5. Are there any claimable aspects being missed?

Actively argue against the structuring choices rather than confirming them, and flag any decomposition decision you cannot evaluate impartially because you just made it. This follows auto-review-loop's "Self-Review Backend (No Second Model)" discipline — a real check, but with no independence guarantee against blind spots a genuinely different model would catch.

Step 7: Output

Write patent/INVENTION_DISCLOSURE.md:

## Invention Disclosure

### Title
[invention title]

### Technical Problem
[formal problem statement]

### Technical Solution
[formal solution description]

### Advantages
[measurable advantages]

### Feature Decomposition

#### Core Inventive Concept
[features that define independent claim scope]

#### Supporting Features
[features for dependent claims]

#### Optional Features
[features for embodiments]

### Claimable Subject Matter
[method, system, product, medium claims planned]

### Drawing Plan
[figures needed, what each shows]

### Dependency Map
[claim hierarchy plan]

### Inventor Information
[names, contributions]

### Target Jurisdiction
[CN/US/EP/ALL]

Key Rules

• The Problem must come from prior art deficiencies, not from commercial needs.
• The Solution must describe the technical mechanism, not just the result.
• The core inventive concept must be the minimum set of features for patentability.
• Supporting features should be independently valuable -- each should provide a meaningful technical benefit even if other supporting features are removed.
• Never invent embodiments that do not correspond to the actual invention or user-provided materials.
• The validation in Step 6 is self-review, not independent review -- note this in the output rather than implying an external reviewer was consulted.