patent-pipeline

特許パイプライン：発明から出願まで

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

次に基づいて、特許出願書類一式を作成します：$ARGUMENTS

概要

このスキルは、先行技術調査から管轄区域の書式に準拠した出願書類まで、特許作成のライフサイクル全体を統括します。サブスキルを特許専用のパイプラインとして連鎖させます：

/prior-art-search → /patent-novelty-check → /invention-structuring → /claims-drafting → /specification-writing → /patent-review → /jurisdiction-format
     (search)           (verify)              (structure)             (claims)            (description)          (examiner)         (compile)
                                                                                              ├── /figure-description
                                                                                              └── /embodiment-description

これは並行ブランチであり、直線的な研究パイプラインの一部ではありません。 /idea-discovery で検証済みのアイデアを作成した後、ユーザーは次のいずれかを選択できます：

• /experiment-bridge → /auto-review-loop → /paper-writing に進む（出版トラック）
• /grant-proposal に進む（資金調達トラック）
• /patent-pipeline に進む（特許トラック）<-- このスキル

                    ┌→ /experiment-bridge → /auto-review-loop → /paper-writing  (publish track)
/idea-discovery ────┤
                    ├→ /grant-proposal → [get funded] → ...  (funding track)
                    └→ /patent-pipeline → [file patent]       (patent track)

特許は、成果を発表すること（学術的貢献）ではなく、発明を保護すること（法的範囲）を目的とします。このスキルでは、先行技術分析、請求項の階層設計、実施可能性を裏付ける明細書の作成、実施形態の説明、管轄区域固有の書式設定など、特許作成に固有の要件に対応します。

定数

• JURISDICTION = CN — 対象の特許管轄区域です。選択肢：CN（CNIPA）、US（USPTO）、EP（EPO）、ALL（3つすべてを生成）。引数で上書きできます（例：/patent-pipeline "invention — US"）。
• PATENT_TYPE = invention — invention（発明特許、保護期間20年）または utility_model（実用新案、CN のみ、保護期間10年、装置の請求項のみ）。引数で上書きできます。
• REVIEWER_MODEL = gpt-6-astra — 審査官スタイルのレビューに Codex MCP 経由で使用するモデルです。
• MAX_REVIEW_ROUNDS = 2 — レビューと修正のサイクルの最大回数です。
• AUTO_PROCEED = false — 各チェックポイントで、必ずユーザーの明示的な確認を待ちます。特許出願には各段階で発明者の判断が必要です。ユーザーが自律モードを明示的に要求した場合のみ true に設定してください。
• LANGUAGE = auto — 出力言語です。管轄区域に基づいて自動検出されます：CN->中国語、US->英語、EP->英語。必要に応じて明示的に上書きできます。
• OUTPUT_DIR = patent/ — 生成した特許ファイルのディレクトリです。
• OUTPUT_FORMAT = markdown — 草案の形式です。レビューには markdown、出願可能な形式には docx を使用します。

引数でデフォルトを上書きします：/patent-pipeline "invention — US, utility model" または /patent-pipeline "invention — ALL, language: Chinese"。

特許の種類に関する仕様

発明特許

項目	詳細
保護期間	出願日から20年
対象事項	方法、システム、製品、組成物、プロセス
審査	実体審査が必要
進歩性	高い（進歩性を有する必要があります）
期間	登録まで2～4年（CN）；2～3年（US）；3～5年（EP）
請求項	方法、システム、製品の請求項が認められます

実用新案 — CN のみ

項目	詳細
保護期間	出願日から10年
対象事項	製品の形状、構造、またはそれらの組み合わせのみ
審査	方式審査のみ（実体審査なし）
進歩性	発明特許より低い
期間	登録まで6～8か月
請求項	装置／機器の請求項のみ。方法の請求項は不可。
制限	CN 管轄区域のみ

状態の永続化（コンパクトな復旧）

特許の起草は長時間に及ぶ作業であり、コンテキストの圧縮が発生する場合があります。各フェーズの終了後に、状態を patent/PATENT_STATE.json に保存してください。

{
  "phase": 3,
  "jurisdiction": "CN",
  "patent_type": "invention",
  "language": "Chinese",
  "codex_thread_id": "019cfcf4-...",
  "invention_title": "...",
  "claims_count": 15,
  "status": "in_progress",
  "timestamp": "2026-04-10T15:00:00"
}

各フェーズの終了時にこのファイルを書き込んでください。 呼び出し時に、このファイルを確認してください。

• ファイルが存在しない場合、または status: "completed" の場合 -> 新規に開始
• status: "in_progress" かつ24時間以内の場合 -> 保存されたフェーズから再開（コンテキストを復元するため、出力ファイルを読み込む）
• 24時間より古い場合 -> 新規に開始（古い状態）

完了時に、"status": "completed" を設定してください。

ワークフロー

フェーズ 0：入力の解析とコンテキストの収集

$ARGUMENTS を解析して、次の情報を抽出します。

1. 発明の説明 — 構造化された形式（INVENTION_BRIEF.md を参照）、図を含む会話形式、または IDEA_REPORT.md の出力の場合があります
2. 管轄 — キーワードから判定します（例：「CN」または「中国」-> CN、「US」または「USPTO」-> US、「EP」または「EPO」-> EP、「ALL」）
3. 特許の種類 — キーワードから判定します（例：「utility model」または「実用新案」-> utility_model、デフォルト -> invention）
4. 上書き設定 — 言語、出力形式、レビュー回数

次に、プロジェクトディレクトリからコンテキストを収集します。

1. INVENTION_BRIEF.md が存在する場合は読み込む（ユーザーがテンプレートに記入済み）
2. IDEA_REPORT.md が存在する場合は読み込む（/idea-discovery によるもの。調査結果から発明を抽出できます）
3. refine-logs/FINAL_PROPOSAL.md が存在する場合は読み込む
4. NARRATIVE_REPORT.md が存在する場合は読み込む（特許化できる可能性のある調査結果）
5. プロジェクトディレクトリ内で、ユーザーが提供した図（PNG、JPG、SVG、PDF）を検索する
6. patent/PATENT_STATE.json を確認する（以前の中断された実行から再開）

コンテキストが不十分な場合：

• 発明の説明がまったくない -> 発明の説明を記述するか、INVENTION_BRIEF.md に記入するようユーザーに提案する
• IDEA_REPORT.md がある -> 調査内容から特許化可能な要素を抽出する
• 図がある -> 発明の概要でそれらを参照する
• 図がない -> 図が必要であることを伝え、必要な図面を計画する

入力が会話形式の場合（構造化された概要ではない場合）、説明を発明の概要の形式に整理し、後続フェーズで使用するために patent/INVENTION_BRIEF.md に書き込みます。

フェーズ 1：先行技術調査と新規性評価

1.1 先行技術調査

/prior-art-search を呼び出します。

/prior-art-search "patent/INVENTION_BRIEF.md"

関連する先行技術を特許データベース（Google Patents、Espacenet）および学術文献から検索します。

1.2 新規性の確認

/patent-novelty-check を呼び出します。

/patent-novelty-check "patent/INVENTION_BRIEF.md"

ステップ1.1で見つかった先行技術に照らして、新規性と非自明性を評価します。

🚦チェックポイント： 先行技術の状況と新規性評価を提示します。

Prior art search complete:
- [X] patent references found
- [Y] non-patent literature references found
- Closest prior art: [reference] -- [why it's closest]
- Novelty assessment: [PATENTABLE / PATENTABLE WITH AMENDMENTS / NOT PATENTABLE]
- Key risk areas: [list]

Ready to proceed with invention structuring?

⛔ ここで停止し、ユーザーの応答を待ってください。 AUTO_PROCEED=true でない限り、自動的に先へ進まないでください。

選択肢：

• 「go」 と返信 -> フェーズ 2 に進む
• 調整内容 を返信 -> 発明の範囲を調整し、新規性を再確認する
• 「stop」 と返信 -> 進捗を patent/DRAFT_NOTES.md に保存する

状態：phase: 1 を含む PATENT_STATE.json を書き込みます。

フェーズ 2：発明の構造化と請求項の設計

2.1 発明の構造化

/invention-structuring を呼び出します。

/invention-structuring "patent/INVENTION_BRIEF.md"

発明を、中核となる発明の概念、補助的な特徴、および任意の特徴に分解します。patent/INVENTION_DISCLOSURE.md を作成します。

2.2 請求項の起草

/claims-drafting を呼び出します。

/claims-drafting "patent/INVENTION_DISCLOSURE.md"

特許の最も重要な部分である、請求項の階層を起草します。patent/CLAIMS.md を作成します。

🚦チェックポイント： 発明の構造と請求項を提示します。

Invention structured:
- Core inventive concept: [summary]
- Claim categories: [method, system, etc.]
- Claims drafted: [X] independent + [Y] dependent = [Z] total
- Independent claim 1 (broadest): [first 50 words of claim 1]
- Examiner review score: [X]/10

The claims define the legal scope of protection. Please review before proceeding to specification.

⛔ ここで停止し、ユーザーの応答を待ってください。 AUTO_PROCEED=true でない限り、自動的に先へ進まないでください。

選択肢：

• 「go」 と返信 -> フェーズ 3 に進む
• 調整内容 を返信（例：「請求項1の範囲を広げる」「従属請求項を増やす」） -> 請求項を修正する
• 「stop」 と返信 -> 進捗を保存する

状態：phase: 2 を含む PATENT_STATE.json を書き込みます。

フェーズ 3：明細書の作成

/specification-writing を実行します：

/specification-writing "patent/CLAIMS.md"

明細書全体をセクションごとに作成します。詳細な説明のために、内部で /figure-description（ユーザー提供の図がある場合）と /embodiment-description を実行します。specification-writing スキルは、サブスキルとして図の処理と実施形態の記述を行います。

🚦 チェックポイント： 明細書の概要を提示します：

Specification written:
- Title: [title]
- Sections: Technical Field, Background, Summary, Drawings Description, Detailed Description, Abstract
- Embodiments: [X]
- Reference numerals: [Y] components mapped
- Abstract length: [Z] words (limit: [jurisdiction limit])
- Claim support: [all elements covered / X elements missing]

Ready to proceed to review?

⛔ ここで必ず停止し、ユーザーの応答を待ってください。

状態：phase: 3 を指定して PATENT_STATE.json を書き込みます。

フェーズ 4：特許レビュー

/patent-review を実行します：

/patent-review "patent/"

GPT-6-Astra xhigh による審査官形式のレビューを 2 ラウンド実行します。審査官は、明確性、記載要件、実施可能要件、新規性、非自明性、クレームの範囲を評価します。

状態：phase: 4 とレビューのスコアを指定して PATENT_STATE.json を書き込みます。

フェーズ 5：管轄区域に応じた書式設定と出力

/jurisdiction-format を実行します：

/jurisdiction-format "patent/"

これは出願書類を対象の管轄区域の書式にまとめます。

最終成果物

出力	場所	説明
CN：权利要求书	patent/output/CN/	CNIPA 形式のクレーム
CN：说明书	patent/output/CN/	CNIPA 形式の明細書
CN：说明书摘要	patent/output/CN/	要約（CN）
US：クレーム	patent/output/US/	USPTO 形式のクレーム
US：明細書	patent/output/US/	USPTO 形式の明細書
US：要約	patent/output/US/	要約（US）
EP：クレーム	patent/output/EP/	EPO 形式のクレーム
EP：説明	patent/output/EP/	EPO 形式の説明
EP：要約	patent/output/EP/	要約（EP）

最終レポート

## Patent Pipeline Complete

### Application Summary
- Title: [invention title]
- Jurisdiction: [CN/US/EP/ALL]
- Patent Type: [Invention / Utility Model]
- Language: [Chinese/English]
- Total Claims: [X] independent + [Y] dependent

### Pipeline Scores
| Phase | Score |
|-------|-------|
| Prior Art Search | [completeness assessment] |
| Novelty Assessment | [PATENTABLE/PATENTABLE WITH AMENDMENTS/NOT PATENTABLE] |
| Examiner Review Round 1 | [X]/10 |
| Examiner Review Round 2 | [Y]/10 |
| Final | [Z]/10 |

### Output Files
[Table of all generated files with paths]

### Next Steps
- [ ] Have a patent attorney review the application
- [ ] Conduct professional prior art search (this tool's search is preliminary)
- [ ] Prepare formal drawings (if user figures need professional rendering)
- [ ] File with the patent office
- [ ] For utility model (CN): formal examination typically takes 6-8 months
- [ ] For invention patent: substantive examination may take 2-4 years

状態：phase: 5, status: "completed" を指定して PATENT_STATE.json を書き込みます。

主なルール

• 先行技術の文献、特許番号、引用を決して捏造しないでください。
• クレームは明細書による裏付けが必要です（記載要件）。
• 各管轄区域には厳格な書式要件があります。書式を混在させないでください。
• 実用新案（实用新型）は CN の管轄区域にのみ適用され、装置／機器のクレームのみを対象とします。
• AUTO_PROCEED の既定値は false です。特許出願では各フェーズで人によるレビューが必要です。サブスキルもこのフラグを引き継ぎます。AUTO_PROCEED=false の場合、サブスキルも結果を提示し、それぞれの内部チェックポイントで停止して待機します。
• 特許パイプラインが作成するのは弁護士によるレビュー用の草案であり、最終的な出願書類ではありません。
• 大容量ファイルの処理：Write 操作が失敗した場合は、Bash の cat <<'EOF' ヒアドキュメントで再試行してください。
• 明細書に実験結果や実証評価を決して含めないでください。
• 用語の一貫性は必須です。同じ概念には全体を通じて同じ用語を使用してください。
• 選択したレビュアーが利用できない場合は、REVIEW_UNAVAILABLE を記録してください。レビューを受けていないことを明示すれば、プロバイダーを切り替えずに草案パイプラインを続行できます。

他のワークフローとの組み合わせ

特許パイプラインは、複数の開始地点から開始できます：

User describes invention directly ──→ /patent-pipeline

/idea-discovery produces IDEA_REPORT.md ──→ /patent-pipeline (extract patentable aspects)

/research-refine produces FINAL_PROPOSAL.md ──→ /patent-pipeline (from refined research idea)

/auto-review-loop produces strong results ──→ /patent-pipeline (patent the method)

謝辞

ARIS（Auto-claude-code-research-in-sleep）のスキルアーキテクチャを基盤としています。特許作成の原則は、MPEP（US）、CN 特許審査指南（CN）、EPO 審査ガイドライン（EP）を参考にしています。