claims-drafting

クレーム作成：特許の中核スキル

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

以下に基づいて特許クレームを作成します：$ARGUMENTS

これは特許パイプラインで最も重要なスキルです。クレームが法的な保護範囲を定めます。明細書、図面、要約など、ほかのすべてはクレームを裏付け、その実施を可能にするために存在します。

定数

• REVIEWER_MODEL = gpt-6-astra — クレームの品質を審査する外部審査官
• MAX_CLAIM_REVISION_ROUNDS = 3 — 最大修正回数
• CLAIM_STYLE = "auto" — US（ジェプソン形式またはオープン形式）、EP（二部形式が必須）、CN（二部形式）、auto（管轄から判定）
• MIN_INDEPENDENT_CLAIMS = 2 — 通常は方法＋システムです。実用新案の場合：装置／デバイスのみで、方法クレームは不可です。
• MAX_TOTAL_CLAIMS = 20 — 実務上の上限（USPTOでは基本料金に20件が含まれます）
• PATENT_TYPE = "invention" — invention（発明特許）または utility_model（実用新案、装置クレームのみ）

入力

1. patent/INVENTION_DISCLOSURE.md — 中核／補助／任意の特徴を含む、構造化された発明開示書
2. patent/PRIOR_ART_REPORT.md — 回避すべき先行技術
3. patent/NOVELTY_ASSESSMENT.md — 推奨される補正案を含む新規性の分析
4. 発明開示書または $ARGUMENTS に記載された対象管轄

共通参照資料

クレーム作成の原則、先行詞の根拠に関する規則、よくある落とし穴については、../shared-references/patent-writing-principles.md を読み込んでください。 CN のクレーム形式（その特徴は）については、../shared-references/patent-format-cn.md を読み込んでください。 US のクレーム形式（含む、ミーンズ・プラス・ファンクション）については、../shared-references/patent-format-us.md を読み込んでください。 EP の二部形式（特徴とする）については、../shared-references/patent-format-ep.md を読み込んでください。

ワークフロー

ステップ 1：クレーム形式と特許種別の決定

特許種別と管轄に基づいて決定します。

PATENT_TYPE = utility_model（実用新案）の場合：

• 管轄は CN のみ
• 装置／デバイスのクレームのみ — 方法クレームおよびプロダクト・バイ・プロセス・クレームは不可
• MIN_INDEPENDENT_CLAIMS = 1（装置クレームが1件あれば十分です）
• クレーム形式：「1. [対象]であって、[構成要素の説明]を含むことを特徴とする。」

対象管轄に基づいて決定します。

管轄	クレーム形式	特徴を示す表現	前文の形式
CN	二部形式	その特徴は	一種の...方法／装置であって、次を含む：
US	オープン形式（推奨）	含む	以下を含む...方法：
EP	二部形式（必須）	特徴とする	[既知の構成]を含む...方法であって、[発明上の構成]を特徴とする
ALL	CN + US + EP の草案を作成	上記すべて	上記すべて

ステップ 2：独立請求項の作成

重要 — 請求項の番号付け（CN 形式）：

• 請求項には、欠番のない連続した番号 1、2、3、... を付けます
• 最終的な番号付けでは、独立請求項と従属請求項を交互に配置します
• 独立請求項と従属請求項を分けてまとめないでください
• 正しい例：請求項 1（独立、製品）、請求項 2（請求項 1 に従属）、請求項 3（請求項 1 に従属）、請求項 4（独立、方法）、請求項 5（請求項 4 に従属）...
• 誤った例：請求項 1（独立）、請求項 5（独立）、請求項 8（独立）を先に並べ、その後に請求項 2、3、4、6、7、9、10 を従属項として記載する

重要 — 請求項に実証的な内容を含めない：

• 請求項では、構造的特徴または方法のステップのみを記載します
• 信号特性、検出原理、測定結果を含めないでください
• 誤り：「产生负脉冲信号」／「谐振频率下降」— これらは特徴ではなく結果です
• 正しい例：「所述开口谐振环的开口处形成用于检测通过流体中颗粒物的间隙传感区域」

INVENTION_DISCLOSURE.md で特定された各請求項カテゴリーについて：

方法の請求項（最も広い範囲）：

1. カテゴリーと目的を特定する前文から始めます
2. 発明の中核となる特徴（「Core Inventive Concept」セクションから）を列挙します
3. 文脈を示すのに十分な既知の特徴を含めます（ただし、必要以上に含めないでください）
4. オープン形式の移行句（「comprising」／「包括」）を使用します
5. 各構成要素は、セミコロンで区切るか、別の行に記載します
6. 管轄区域固有の形式を適用します：
   • CN：前段部分 + 「其特征在于」 + 特徴部分
   • US：前文 + 「comprising:」 + 構成要素
   • EP：前文 + 既知の特徴 + 「characterised in that」 + 発明の特徴

システム／装置の請求項：

1. 方法の請求項を構造的な形式に置き換えます
2. 各方法のステップを「〜するよう構成されたモジュール」または「〜のためのコンポーネント」に置き換えます
3. 既知の特徴と発明の特徴の階層は、方法の請求項と同じにします

各独立請求項の品質チェック：

• 単一の文（US／EP）または適切に構成された文（CN）
• 先行詞の根拠：「a」は初出時に、「the」は以降に各構成要素に使用する
• 定義のない相対的な表現がない
• 達成すべき結果による限定がない
• 移行句が適切である（オープン形式を推奨）
• 前文に不要な限定を持ち込んでいない
• 各構成要素が特許性に必要である
• 先行技術に照らして、請求項の範囲が正当化できる最大限の広さである

ステップ 3：従属請求項の作成

各独立請求項について、次の条件を満たす従属請求項を 5～10 項作成します。

1. 発明の中核となる特徴を限定する：具体的な実施形態、パラメーター、範囲
2. 好ましい実施形態を対象とする：明細書の詳細な説明に記載された特徴
3. 代替的な立場を用意する：独立請求項が拒絶された場合、より限定されたこれらの請求項が認められる可能性があります
4. 代替案を対象とする：同じ発明の成果を実現するさまざまな方法

従属請求項の形式：

• CN：「根据权利要求X所述的[主题]，其特征在于，所述[特征]具体为...」
• US：「The [method/system] of claim X, wherein the [element] comprises [limitation].」
• EP：「The [method/system] according to claim X, characterised in that [limitation].」

従属請求項のルール：

• それぞれに、少なくとも 1 つの意味のある限定を加える必要があります
• 番号で先行する請求項を引用する必要があります
• 親請求項を単に繰り返してはなりません
• 累積的にしないでください（各請求項は、代替的な立場として独立して有用である必要があります）
• 複数従属請求項（US：引用は「or」のみで、「and」は不可）

ステップ 4：請求項と明細書の対応付け

実施可能要件を確認するため、予備的な対応表を作成します。

請求項の構成要素	明細書に記載が必要	符号
[element 1]	Yes/No	[numeral]
[element 2]	Yes/No	[numeral]

いずれかの構成要素について明細書による裏付けがない場合は、明細書の要件に追加します。

ステップ 5：複数モデルによる審査官レビュー

xhigh reasoning を使用して、mcp__codex__codex 経由で REVIEWER_MODEL を呼び出します。

まずこのレビュースロットを解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are a senior patent examiner at the [USPTO/CNIPA/EPO].
    Review the following patent claims for quality and patentability.

    CLAIMS: [all claims]

    PRIOR ART: [prior art references from PRIOR_ART_REPORT.md]

    INVENTION: [summary from INVENTION_DISCLOSURE.md]

    Analyze each claim for:
    1. Clarity (35 USC 112(b) / Art 84 EPC): Are terms definite?
    2. Written description support: Does the spec support all claim scope?
    3. Anticipation (102/Art 54): Would any single reference anticipate?
    4. Obviousness (103/Art 56): Would any combination render obvious?
    5. Claim scope: Are independent claims broad enough to be valuable?
    6. Dependent claims: Do they provide meaningful fallback positions?
    7. Antecedent basis: Any issues with "a"/"the" usage?
    8. Indefinite terms: Any functional/result language issues?

    For each issue found, provide:
    - The specific claim number and element
    - The problem (cite statute/rule)
    - A suggested fix

    Provide an overall PATENTABILITY SCORE: 1-10.

ステップ 6：修正ループ

審査担当者のレビューで問題が指摘された場合：

1. すべての重大な問題（先取り、明白性、不明確性）に対処します
2. 主要な問題（範囲が狭すぎる、裏付けの不足、弱い代替案）に対処します
3. 軽微な問題（先行詞の根拠、書式）を検討します
4. 2回目の審査のために審査担当者へ再提出します（threadId とともに mcp__codex__codex を使用します）
5. MAX_CLAIM_REVISION_ROUNDS 回を上限として繰り返します

ステップ 7：出力

patent/CLAIMS.md を作成します：

## Patent Claims

### Independent Claims

#### Claim 1 — Method
[formatted claim text]

#### Claim X — System/Apparatus
[formatted claim text]

### Dependent Claims

#### Claim 2 (depends on 1)
[formatted claim text]

#### Claim 3 (depends on 1)
[formatted claim text]
...

### Claims Summary Table

| Claim | Type | Depends On | Key Limitation | Prior Art Avoidance |
|-------|------|-----------|----------------|---------------------|
| 1 | Method | — | [core inventive features] | [what makes it novel over prior art] |
| 2 | Method | 1 | [narrowing] | [additional distinguishing] |
| X | System | — | [mirrors claim 1] | [same as claim 1] |
...

### Examiner Review Summary
[Key findings and how they were addressed]

重要なルール

• 請求項は特許の中で最も重要な部分です。それ以外のすべては請求項を裏付けるものです。
• まず独立請求項を作成し、次に従属請求項を作成します。
• 独立請求項は、先行技術に対して防御可能な最も広い範囲とします。広すぎても狭すぎてもいけません。
• 各従属請求項は、代替案として単独でも有用なものにします。
• 先行詞の根拠は必須です。「a processor」を最初に使用し、その後は「the processor」を使用します。
• 「consisting of」（閉鎖型）を使用する特別な理由がない限り、「comprising」（開放型）を使用します。
• 請求項に結果達成を目的とする表現（「高い精度を達成するように構成された」など）を決して含めないでください。
• 請求項の文言を決して捏造しないでください。すべての要素は実際の発明に由来する必要があります。
• すべての管轄区域向けに作成する場合は、CN、US、EP 向けに個別の請求項セットを作成します。
• 選択したレビュアーを利用できない場合は、REVIEW_UNAVAILABLE を記録します。プロバイダーを切り替えず、未レビューの草案であることを明示したうえでのみ続行します。