invention-structuring

发明构思结构化

在每个审查者名额开始前，遵循 可选审查者： 通过规范的辅助解析器，使用 reviewer_route.py 依次解析调用 → .aris/reviewer.json → Claude Code 默认设置（Codex MCP），并保留此 名额的层级、新上下文、源文件／图像输入和确定性门控条件。 下方的 Codex 示例／固定配置仅适用于 backend=codex；其他路由使用各自的首次调用／回复约定。保存路由和实际返回的身份； 不可用的选择记为 REVIEW_UNAVAILABLE。根据实际的系列／完成状态／范围对接受情况进行分类。将调用中的审查者／模型／effort 覆盖设置 传递给包含审查者的子任务。生成工作进程保持不变。

根据以下内容，将发明构思整理成正式披露文件：$ARGUMENTS

改编自 /research-refine 中的细化模式，用于专利发明分解。

常量

• REVIEWER_MODEL = gpt-6-astra — 用于验证发明分解的外部审查者
• MAX_REFINEMENT_ROUNDS = 3 — 结构化迭代的最大轮数

输入

1. 来自 $ARGUMENTS 的发明描述
2. 如存在，使用 patent/INVENTION_BRIEF.md
3. patent/PRIOR_ART_REPORT.md — 现有技术概况
4. patent/NOVELTY_ASSESSMENT.md — 新颖性分析

共享参考资料

加载 ../shared-references/patent-writing-principles.md，了解问题—解决方案—优势框架以及可主张的主题指南。

工作流

步骤 1：问题—解决方案—优势框架

使用通用专利框架构建发明：

技术问题（要解决的技术问题）：

• 根据 NOVELTY_ASSESSMENT.md 中确定的现有技术缺陷推导得出
• 必须是具体的技术问题（而非商业或社会问题）
• 陈述格式：“要解决的技术问题是，在给定[具体技术约束]的情况下，如何实现[具体技术目标]。”

技术方案（技术方案）：

• 发明的具体技术贡献
• 聚焦于机制，而非结果
• 描述的详细程度须与预期权利要求范围相符
• 指明哪些特征是已知的，哪些是创新的

优势（有益效果）：

• 相对于现有技术，可测量或量化的改进
• 必须由创新特征带来，而非仅仅源于良好的工程设计
• 如已知，列出具体技术效果（例如，“将处理时间缩短 40%”）

步骤 2：发明分解

将发明分为三个层次：

核心发明构思（核心发明构思）：

• 使发明具备可专利性的最小特征集合
• 对应独立权利要求的范围
• 测试：移除该特征后，发明将不再具备新颖性

支撑性特征（支撑性特征）：

• 使发明在实践中运行良好的特征
• 这些特征将作为从属权利要求的内容
• 它们会缩小范围，但能增加实用价值

可选特征（可选特征）：

• 实现细节、优选参数、备选方案
• 这些内容将作为实施例材料
• 它们支持对权利要求作更宽泛的解释

步骤 3：可主张主题的识别

针对核心发明构思，确定要起草哪些类别的权利要求：

类别	适用性	内容
方法／过程	发明涉及步骤时	流程、算法、工作流
系统／设备	发明涉及组件时	硬件结构、模块、连接关系
产品	发明是物理设备时	形状、结构、组成
计算机可读介质	软件发明（美国）	存储的指令、非暂态介质
产品制备方法限定产品	难以定义结构时	根据制造方式定义的产品

第 4 步：绘图计划

规划需要哪些图来支持相关主张和说明书：

图	类型	展示内容	支持的权利要求要素
图 1	框图	系统架构	系统权利要求的组成部分
图 2	流程图	方法步骤	方法权利要求的步骤
图 3	时序图	组件之间的交互	具体实现细节

如果用户已提供附图，请在此处引用。如果缺少附图，请注明需要哪些附图。

第 5 步：依赖关系映射

映射功能依赖关系，以规划权利要求层级：

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

第 6 步：跨模型验证

使用高强度推理，通过 mcp__codex__codex 调用 REVIEWER_MODEL：

请先确定此审阅者槽位；以下是 backend=codex 示例。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are a patent attorney reviewing an invention disclosure.
    Evaluate the structuring choices:

    INVENTION: [Problem-Solution-Advantage summary]
    DECOMPOSITION: [Core/Supporting/Optional features]
    CLAIM PLAN: [intended claim categories and hierarchy]

    Please 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?

第 7 步：输出

编写 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]

关键规则

• 问题必须源自现有技术的缺陷，而非商业需求。
• 解决方案必须描述技术机制，而不能只描述结果。
• 核心发明构思必须是获得专利所需的最少特征集合。
• 支持性特征应各自具有独立价值——即使移除其他支持性特征，每项特征仍应带来有意义的技术效益。
• 切勿虚构与实际发明或用户提供的材料不符的实施例。
• 如果选定的审阅者不可用，请记录 REVIEW_UNAVAILABLE；仅以明确标注为未经审阅的草稿继续，不得切换提供方。