mcpField
P
patent

patent

github.com/alirezarezvani生産性28.9k361 回インストール2 日前に更新
リポジトリ

patent について

patent は、特許の新規性、実施自由、競争状況、買収デューデリジェンス、訴訟向け先行技術を調べるスキルです。目的に応じて検索戦略と DOCX レポートを変え、法的助言ではなく技術的な判断材料を提示します。

主な機能

  1. 01目的別の5つの検索経路
  2. 02複数ソースの特許検索
  3. 03請求項の関連性評価
  4. 04特許ファミリーの重複排除
  5. 05監査ログ付き DOCX レポート

活用シーン

  1. 01出願前の先行技術調査
  2. 02各法域の有効特許の確認
  3. 03出願人と技術動向の分析
  4. 04対象ポートフォリオや特許の調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/alirezarezvani/claude-skills --skill patent

インストール後、Claude Code で/patentを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
cpc_classification_canon.md
legal_disclaimer_discipline.md
sub_use_case_routing.md
scripts/
citation_tracker.py
family_resolver.py
sub_use_case_router.py

詳細

Patent — 先行技術+ランドスケープインテリジェンス

移植性: web_fetch(Google Patents、Espacenet、USPTO)、WebSearch(関連する学術文献)、docx パッケージを含む Node.js が必要です。引用グラフのシグナルには、オプションで Lens.org API キーを使用できます。Claude Code CLI ではネイティブに動作します。Web ツール+Code Execution+BYOK Lens.org を備えた Claude.ai でも、このワークフローを利用できます。

対象外: 商標、著作権、営業秘密。これらは受付時に明示されます。別のスキルを使用するか、有資格の弁護士に相談してください。

法的免責事項: このスキルが提供するのは検索シグナルであり、法的助言ではありません。判断は技術的な評価です。出願やライセンスに関する判断の前に、必ず弁理士に相談してください。

汎用的でない位置づけ — 差別化要因

このスキルは先行技術+ランドスケープインテリジェンスです。何でも詰め込む箱になることを拒みます。 検索を開始する前に、グリル形式の受付を通じて、毎回5つのサブユースケースのいずれかを確定します。選択されたサブユースケースによって、検索戦略、ランキングのヒューリスティクス、DOCX で重視する内容がすべて決まります。

サブユースケース検索戦略DOCX で重視する内容
新規性調査絞り込み+請求項テキストを重視。出願日以前かどうかは無関係最も近い先行技術+請求項の差別化
実施自由調査網羅性を重視+有効な特許のみ。管轄区域で絞り込みFTO に関する注意点+請求項ごとのリスク
競合ランドスケープ網羅性+出願人の集計+CPC の傾向出願人マップ+投資の注目分野
買収デューデリジェンス特定の権利者+ポートフォリオの範囲+権利移転履歴ポートフォリオ表+権利者の確認
訴訟向け先行技術調査特定の対象特許+優先日以前の関連技術関連性順に並べた無効化候補

基本方針については、references/sub_use_case_routing.md を参照してください。

エージェントの整合性ルール(Research-Pack 規約)

PR #657 の監査に基づき、原文どおりに固定されています。

  • 実行規律。 検索呼び出しは順番に実行します。レート制限は1秒あたり1クエリです。 次の呼び出しに進む前に、応答を受信したことを確認してください。
  • 情報源の規律。 このセッションでツール呼び出しによって返された特許のみを引用します。トレーニングデータに基づく知識には [Not from search — reference information] とラベルを付け、件数から除外します。
  • 3種類の件数を追跡。 送信したクエリ数/受信した特許数(表示件数)/引用した特許数。監査ログに表示します。
  • 再試行ポリシー。 失敗した場合 → 3秒待機 → 1回再試行 → ログに記録します。ツール全体で3回連続して失敗した場合は、処理を停止し、ユーザーに通知して、不足している内容を説明します。
  • プラン階層の検出。 Lens.org の無料プランは月1000クエリです。Google Patents は認証不要ですが、IP ごとにレート制限があります。上限を検出し、ユーザーに提示してください。

フェーズ1:グリル形式の受付(回答を迫る6つの質問を1問ずつ)

Q1(最初の質問)— 発明の説明

発明を2~3文で説明してください。どのような機能があり、何が新しいのでしょうか?

質問の理由: コンセプトとキーワードの抽出は、正確な説明に完全に依存します。曖昧な説明(「ヘルスケア向けAI」「より優れたウィジェット」など)は受け付けず、発明の機能と既存のアプローチとの違いを具体的に説明するよう、ユーザーに求めてください。

曖昧な説明は受け付けません。 回答が一般的すぎる場合は、もう一度だけ尋ねます。「既存のシステムにはない、どのような機能がありますか?」その後、留保事項を DOCX に記載したうえで確定します。

Q2(Q1に応じた質問)— サブユースケースの確定

この検索の目的は何ですか?1つ選んでください。

  1. 新規性調査(出願できるほど新規性があるか)
  2. 実施自由調査(製品を出荷したら訴えられるか)
  3. 競合ランドスケープ(この分野にはほかに誰がいるか)
  4. 買収デューデリジェンス(買収対象は本当にXを所有しているか)
  5. 訴訟向け先行技術の調査(特定の特許を無効にする)

質問の理由: それぞれの経路で、根本的に異なる検索戦略を使用します。どれかを選択していただくまで、検索の開始はお断りします。

必ず1つ選ぶ形式です。ユーザーが「すべて」と答えた場合は、主な目的を選ぶよう求めてください。副次的な目的については、追加の検索として実施できます。

Q3(Q2 ∈ {FTO, landscape, diligence} の場合のみ質問)— 対象法域

重要な法域はどこですか?該当するものをすべて選んでください:US / EP / CN / JP / KR / PCT / worldwide。

質問の理由: FTO は販売する地域でのみ重要です。ランドスケープは地域によって大きく異なります。デューデリジェンスでは、対象企業が事業を展開するすべての法域を確認する必要があります。

新規性の場合はスキップします(優先日は法域を越えて適用されるため)。また、訴訟の場合もスキップします(法域は対象特許によって決まるため)。

Q4(Q1 に依存)— 既知の先行技術

これに近い先行技術をすでに見たことがありますか?特許番号または論文を挙げてください。

質問の理由: 先行技術を1件でも把握していれば、それに隣接する文献を検索できるため、何もない状態から始めるより、はるかに精度が上がります。把握していなくても問題ありません。その旨を確認してください。

手がかりとなる情報です。「なし」という回答も受け付けますが、非公式な形でも関連する研究を見たことがないか、ユーザーに確認してください。

Q5(Q2 に依存)— リスク許容度

この検索でのリスク許容度は、厳格(近い文献が1件でもあれば、この方針を断念する)ですか、それともシグナル収集(全体像を把握したい)ですか?

質問の理由: 厳格モードでは積極的に順位付けし、判断の根拠となるレベルの文献を提示します。シグナル収集モードでは、網羅性と可視化を優先します。

新規性と FTO では質問します。純粋なランドスケープの場合は、定義上常にシグナル収集となるためスキップします。

Q6(Q2 ∈ {novelty, FTO} の場合のみ質問)— 弁護士への相談状況

弁理士に相談しましたか?このスキルが提供するのは検索シグナルであり、法的助言ではありません。これは技術評価のみを目的とするものだと理解していることを確認してください。

質問の理由: 新規性と FTO には法的な影響があります。このスキルの判断はシグナルとしてのものであり、法的見解を得るには、資格を持つ専門家への相談が必要です。

DOCX の免責事項フッターを表示するトリガーです。 法的リスクが比較的低いため、ランドスケープとデューデリジェンスではスキップします。

停止条件: Q6 の後(または依存関係によるスキップが適用された場合はそれ以前)に、内容を確定してフェーズ 2 を開始します。フェーズ 2 の開始後に、インテークを再開してはいけません。

フェーズ 2:検索戦略の選択

インテークの回答から決定します。scripts/sub_use_case_router.py を使用してください:

python scripts/sub_use_case_router.py \
  --sub-use-case novelty \
  --jurisdictions "" \
  --risk strict \
  --known-art "US10000000B2"

返される内容:検索計画(5~8 件の検索クエリ)+順位付けのヒューリスティック+DOCX の強調フラグ。

フェーズ 3:複数ソースの検索(逐次実行)

ソースの優先順位
  1. Google Patents(https://patents.google.com)— 主力ソース。認証不要で、幅広い情報を網羅
  2. Espacenet(https://worldwide.espacenet.com)— 世界規模の情報を網羅。米国以外の先行技術に強い
  3. USPTO PPS(https://ppubs.uspto.gov)— 米国の詳細な検索
  4. Lens.org(https://www.lens.org)— 引用グラフ。BYOK API キーが必要
サブユースケースごとの検索パターン

新規性:

  • 発明固有の用語を使った絞り込み検索を3件(Google Patents)
  • 類義語を使った広範な概念検索を2件(Google Patents + Espacenet)
  • 初期検索結果から分類を特定できた場合、CPC クラスで絞り込んだ検索を1件

FTO:

  • 法域で絞り込み:有効な特許のみ(失効または放棄済みのものを除く)
  • 日付で絞り込み:優先日 < 今日
  • 各検索結果について、有効な請求項のテキストを抽出

競合ランドスケープ:

  • 技術分野を広く対象とした検索
  • CPC クラスの特定 → そのクラスで出願件数の多い出願人を集計
  • 上位5社の各社について、年別の過去10年間の出願動向

買収デューデリジェンス:

  • 特定の権利者を対象とした検索(対象企業 + 子会社 + 氏名が判明している発明者)
  • 権利移転の連鎖を確認(USPTO の権利移転記録)
  • 重複排除のため、特許ファミリーを解決

訴訟に関連する先行技術:

  • 対象特許の入力が必要(番号)
  • 優先日を抽出
  • 優先日前の文献を、同じ CPC クラスから検索
  • 隣接する請求項の文言を検索
逐次実行のルール

すべてのソースを合わせて毎秒1件。scripts/citation_tracker.py でタイムスタンプを用いて間隔を強制し、追跡します。

Phase 4: クレーム抽出+関連性スコアリング

最も近い先行技術の各ヒットについて:

  • 独立クレーム1を取得します(最も広いクレームであり、新規性欠如/自明性の主な根拠となります)。
  • 主要な従属クレームを取得します(発明的なステップを追加するクレームです)。
  • 発明の説明に照らして関連性をスコアリングします(クレーム文言とQ1の用語の重複度)。

スコア順に並べます。サブユースケースごとに判定を示します(新規性については NOVEL / POTENTIALLY NOVEL / NOT NOVEL、FTOについては管轄ごとに CLEAR / FLAGGED / HIGH RISK)。

Phase 5: 引用グラフ+ファミリー解決

引用グラフ(Lens.org BYOK)

ユーザーがLens.org APIキーを提供した場合:

  • 基礎となる特許の特定(被引用数がしきい値を超えるもの。通常は50件以上)
  • 直近の高被引用シグナル(現在の活動状況の指標として、過去24か月間の引用を確認)
  • 対象特許からの後方引用(訴訟での先行技術)または最も近い先行技術からの前方引用(新規性)

Lens.orgキーがない場合:スキップして監査ログに記録し、Google Patentsでの手動引用調査を推奨します。

ファミリー解決

同じ発明が複数の管轄(US、EP、JP、CN)で出願されることがよくあります。ファミリーIDまたは優先権番号でグループ化し、二重計上を防ぎます。scripts/family_resolver.pyを使用します。

python scripts/family_resolver.py --hits-file hits.json
# Returns: deduplicated family list + family-member jurisdictions

CPC/IPC分類の考慮

重要: キーワード検索だけでは、隣接分野の先行技術を見落とします。初回検索後、上位5件のヒットからCPC/IPC分類を抽出し、分類を限定したクエリを1つ実行してください。これにより、キーワード検索では見つからない先行技術を一貫して発見できます。

分類体系については、references/cpc_classification_canon.mdを参照してください。

Phase 6: DOCXの生成(8セクション)

サブユースケースに応じて重点を調整します。Node.jsとdocxライブラリを使用します。

  1. エグゼクティブサマリー+判定 — サブユースケースのバナー+1行の判定(NOVEL / FLAGGEDなど)+主要な調査結果3~4件+法的免責事項のフッター
  2. 最も近い先行技術 — 関連度順に特許を5~10件掲載します。各ヒットについて、リンク付きタイトル+権利者+出願日/優先日+独立クレーム1の本文(斜体)+関連性スコア+関連性の根拠(1~2文)
  3. 特許ランドスケープ — 上位出願人の表(件数上位10件)+10年間の出願傾向の説明+CPC分類の分布表。ランドスケープとデューデリジェンスのみで使用し、それ以外では簡略化します。
  4. 引用グラフのシグナル — 基礎となる特許(Lensが利用可能な場合)+直近の高被引用活動。Lensを利用できない場合は「手動調査を推奨」と記載し、表は省略します。
  5. 地理的カバレッジ — 上位10件のヒットについて管轄ごとの出願を示します。FTO、ランドスケープ、デューデリジェンスのみで使用し、新規性と訴訟では省略します。
  6. FTOの警告(FTOのみ)— 侵害リスクがある有効な特許。各警告について、リンク付き特許+管轄+関連クレーム+リスクレベル(HIGH/MEDIUM/LOW)+軽減策の注記を記載します。
  7. 戦略+推奨事項 — サブユースケースに応じて内容を調整します:
    • 新規性 → クレームの差別化に関する提案
    • FTO → 設計回避のヒント+管轄戦略
    • ランドスケープ → 注視すべき企業のリスト
    • デューデリジェンス → ポートフォリオのレッドフラグ
    • 訴訟 → 無効化候補を順位付けして提示
    • 出願/ライセンスに関する判断では、特許弁護士への相談を必ず推奨します。
  8. 監査ログ — 検索の表(番号、クエリ、情報源、結果、ステータス)、件数(送信/表示/引用)、ツールの制約(プランの注記)、失敗したステップ、弁護士への相談に関するリマインダー
スタイル

本文はArial 12pt、見出しはネイビー(#1a3a5c)、表のヘッダーはライトブルー(#e8f0f8)、FTO警告は赤いコールアウトにします。ExternalHyperlinkのパターン:

  • Google Patents:https://patents.google.com/patent/[number]
  • Espacenet:https://worldwide.espacenet.com/patent/...
  • USPTO:https://patents.uspto.gov/patent/...

日付の扱い

該当するたびに、次の日付を区別します。

  • 出願日 — 出願が最初に提出された日
  • 優先日 — 優先権を主張する最も早い日(出願日より前であることがよくあります)
  • 公開日 — 出願が公開された日(通常、優先日から18か月後)
  • 登録日 — 特許が登録された日(公開日より後)

サブユースケースごとに、法的に関連する日付を提示します。

  • 新規性 → 優先日(発明の想定出願日との比較)
  • FTO → 登録日とステータス(有効か失効か)
  • ランドスケープ → 公開日(公知となった日)
  • デューデリジェンス → 登録日と譲渡日
  • 訴訟 → 対象特許の優先日(先行技術の基準日を定めます)

フェーズ 7:納品

  • 保存先:<output-dir>/patent_<invention-slug>_<sub-use-case>_<YYYY-MM-DD>.docx
  • チャットでの要約:ファイルパス + サブユースケース + 判定 + 監査件数 + プラン階層
  • 検証:python3 -c "import zipfile,sys; zipfile.ZipFile(sys.argv[1]).testzip()" <docx> で ZIP の整合性を確認します(出力がなければ正常です)。その後、必須セクションが含まれていることを確認します。
  • リマインダー:「出願/ライセンス許諾の前に、特許弁護士に相談してください」

ツール

スクリプト役割
scripts/citation_tracker.py~/.patent_sessions/<session>.json に記録する、複数ソースを用いた3件数監査(Google Patents + Espacenet + USPTO + Lens.org)
scripts/family_resolver.pyファミリー ID/優先権番号を使って、各法域の同一発明に関する出願をグループ化します
scripts/sub_use_case_router.pyインテークの回答から検索戦略を決定論的に選択します

参考資料

エラー処理

失敗動作
ユーザーがサブユースケースの確定を拒否する続行を拒否します。例を示して Q2 を再度尋ねます。
発明の説明が一般的すぎる回答を受け付けません。「既存のシステムにない、どのような機能がありますか?」と尋ねて Q1 を再度提示します。
Google Patents によるレート制限3秒待ってから1回再試行します。そのクエリでは Espacenet に切り替えます。監査ログに記録します。
Lens.org のキーがない引用ネットワークのセクションを省略し、DOCX に「手動レビューを推奨」と記載します。
クレーム文の抽出に失敗要約で代用し、関連性の根拠に「要約のみ」と明記します。
ファミリーの解決が不完全監査ログに記録します。同一発明の重複が含まれる場合があるため、手動での重複排除を提案します。
すべての検索結果が3件未満「ニッチな先行技術、または実際の空白領域のいずれか」と明示し、決して捏造しません。
ツールの失敗が3回連続する停止してユーザーに通知し、不足しているものを説明します。
DOCX の生成に失敗ユーザーの作業が失われないよう、代替として生データを JSON で保存します。
対象特許番号が無効(訴訟)検索前に形式を検証し、ユーザーに確認を求めます。

拒否すべきアンチパターン

  • ユーザーがサブユースケースを確定する前に検索を開始する(「特許関連の支援」という漠然とした依頼では進めない)
  • インテークの質問を1つずつではなく、まとめて提示する
  • 曖昧な発明の説明(「医療向け AI」など)を受け入れる
  • CPC/IPC 分類で追加調査せず、キーワードだけで検索する
  • ファミリーメンバーを別々の検索結果として扱う(重複排除が必須)
  • 出願日、優先日、公開日を混同する
  • サブユースケースに法的な影響があるのに、免責事項を省略する
  • クレーム文の証拠なしに判定を報告する
  • キーがないのに Lens.org の引用データを捏造する
  • 弁護士によるレビューが必要であることに触れずに設計回避策を提案する
  • 監査ログを省略する

バージョン: 1.0.0 ソース仕様: megaprompts/11-patent-megaprompt.md(メンテナー限定のドラフト仕様 — gitignore 対象のため、公開リポジトリにはありません) ビルドパターン: パス B(直接変換)。Research-pack の兄弟版で、サブユースケースのルーティングを変えたものです。

コメント