invention-structuring

発明の構成

各レビュースロットの前に、レビュー担当者の選択に従います。 呼び出し → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP）の順に解決し、 正規のヘルパーリゾルバーを通じて reviewer_route.py を使用します。その際、この スロットのティア、新しいコンテキスト、ソース／画像の入力、決定論的なゲートを維持します。 以下の Codex の例／固定設定は backend=codex の場合にのみ適用されます。他のルートでは、 それぞれの初回呼び出し／返信の契約が適用されます。ルートと、実際に返された ID を保存します。 選択したものを利用できない場合は REVIEW_UNAVAILABLE とします。実際のファミリー／完了状況／範囲に基づいて 受け入れを分類します。呼び出し元によるレビュー担当者／モデル／推論レベルのオーバーライドを、 レビュー担当者を含む子プロセスに引き継ぎます。生成ワーカーに変更はありません。

$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つの層に分解します。

発明の中核的な概念（核心发明构思）：

• 発明を特許可能にする最小限の特徴の集合
• 独立請求項の範囲に対応します
• 確認方法：この特徴を取り除くと、発明は新規性を失うか

補助的な特徴（支撑性特征）：

• 発明を実際にうまく機能させる特徴
• 従属請求項の内容になります
• 範囲を狭めますが、実用的な価値を加えます

任意の特徴（可选特征）：

• 実装の詳細、好ましいパラメーター、代替案
• 実施形態の内容になります
• より広い請求項の解釈を支えます

ステップ 3：請求項の対象となる主題の特定

発明の中核的な概念について、どの種類の請求項を作成するかを判断します。

カテゴリ	適用条件	内容
方法／プロセス	発明にステップが含まれる場合	プロセスフロー、アルゴリズム、ワークフロー
システム／装置	発明に構成要素が含まれる場合	ハードウェア構造、モジュール、接続
製品	発明が物理的な装置である場合	形状、構造、組成
コンピューター可読媒体	ソフトウェア発明の場合（米国）	保存された命令、非一時的媒体
プロダクト・バイ・プロセス	構造の定義が困難な場合	製造方法によって定義される製品

ステップ 4：図面計画

主張と仕様を裏付けるために必要な図を計画します。

図	種類	内容	裏付ける請求項の要素
FIG. 1	ブロック図	システムアーキテクチャ	システム請求項の構成要素
FIG. 2	フローチャート	方法の手順	方法請求項の手順
FIG. 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 を xhigh の推論で呼び出します。

まずこのレビュアースロットを解決してください。以下は 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 と記録してください。プロバイダーを切り替えず、レビューされていない草案であることを明示して作業を続けてください。