Uspto Office Actions

@pipeworx/uspto-office-actions

USPTOの特許審査履歴 — オフィスアクションの全文、審査官／出願人による引用（AI/MLで抽出された「拡張引用」メタデータを含む）、請求項単位の拒絶データ（35 U.S.C. 101/102/103/112）、および特許出願の請願に対する長官の最終決定。

Pipeworx の一部です — AI エージェントを1837以上の稼働中データソースに接続するMCPゲートウェイです。これは独立した非公式の連携機能であり、上流プロバイダーとの提携、同社による承認、または同社による公開はありません。

ツール

• search_office_actions(application_number | patent_number, limit) — 出願に関するオフィスアクション。アクション種別、発送日、審査官の従業員番号、技術分野、日付の新しい順。
• get_office_action_text(document_id | (application_number + mail_date)) — 1件のオフィスアクションの全文、その長さ、および切り詰められているかどうかを示すフラグ。
• get_office_action_rejections(application_number, limit) — 請求項単位の拒絶データ。まず101/102/103/112／二重特許の拒絶レコードの集計件数、次に各レコードの詳細を返します。
• get_office_action_citations(application_number, limit) — オフィスアクションで引用された文献、引用者（審査官または出願人）、およびUSPTOが該当する引用について提供している場合は、AI/MLで抽出された拡張引用フィールド（カテゴリコード、請求項／段落の該当箇所のマッピング）。
• search_petition_decisions(query | application_number, decided_after, decided_before, limit, offset) — 長官／請願局による最終決定。決定種別、決定日、請願種別、決定を行った部門。

認証

プラットフォームキー（PLATFORM_USPTO_KEY）。_apiKey でBYOキーを指定できます。無料キーは https://data.uspto.gov/myodp で取得できます。2026-10現在、USPTOでは新規または更新されたODPアカウントに対し、ID.meによる本人確認と4つのプロフィール項目の入力が必要です。これらを完了していないアカウントのBYOキーは、形式が正しくても拒否されます。

データソース

• USPTO、Open Data Portal — Office Action Text Retrievalデータセット（パブリックドメイン、CC0マーク）。1200万件台の出願番号シリーズから始まる公開済みオフィスアクションを収録。
• USPTO、Open Data Portal — Office Action Citationsデータセット。
• USPTO、Open Data Portal — Office Action Rejectionデータセット。
• USPTO、Open Data Portal — Enriched Citation（AI/ML抽出）データセット。
• USPTO、Open Data Portal — Final Petition Decisionsデータセット。

発行者名とデータセット名のみを記載し、ルートは記載しないでください。正確なエンドポイントはsrc/index.tsにあります。

注意事項

• 従来の developer.uspto.gov Office Action API は廃止されています（すべて data.uspto.gov/home に 301 リダイレクトされることを、2026-10-18 に確認）。このパックでは、api.uspto.gov 上の現在利用可能な代替 API を呼び出します。
• 実際のリクエスト形式を特定するまでに、実環境での調査を FIVE 回重ねました（fleet #3305、2026-10-18 — cluster-c による調査、次に Antonio、続いてこのパック独自の追加調査、最後に再び Antonio）。単に未試行なのではなく、3 種類の形式が誤りだと判明しています。再試行しないでください。（1）単純な GET /office-actions リソースは存在します（キーなしでは 401、不正なキーでは 403 "Forbidden"）。しかし、試したすべてのクエリ形式（q／size のみ、または従来の criteria／rows を加えた形式）は "missing path or query params" で拒否されます。実際の仕様は依然不明で、このパックでは呼び出しません。（2）GET <route>/search と GET <route>/<applicationNumber> は、稼働中の上流サービスに直接問い合わせて、どちらも誤りだと確認済みです。どのキーを使っても、AWS のルーティングレベルで「そのリソースは存在しない」ことを示す応答 403 "Missing Authentication Token" が返ります。どちらのサブパスも存在しません。（3）このパックが実際に呼び出す形式：POST /api/v1/patent/oa/<dataset>/<version>/records に、フォーム形式でエンコードした criteria（Lucene）／start／rows を送信します。これは、オープンソースの patent-dev/uspto-odp Go クライアントに含まれている OpenAPI 仕様で確認できる、元のデータセットルートです。以前、これらに対する不正なキーでの調査が、このパック独自の不正なパスを使った対照テストと同じステータスコード（403）を返したため、誤って利用不能と判断していました。このサブツリーで実際に判別できるのは本文です。{"message":"Forbidden"} は「実在するルートだがキーが不正」、{"message":"Missing Authentication Token"} は「そのリソースは存在しない」を意味します。以前は、本文が異なる 2 種類の 403 を同一のステータスコードとして混同していました。キーなしで実環境に問い合わせたところ、4 つすべてのデータセット／バージョンの組み合わせで "Forbidden" が返ることを確認しました。各エントリの正確なデータセット／バージョン表と、対応する swagger ファイルについては src/index.ts の OA_DATASETS を参照してください。Enriched citations の第一候補では、実環境で推測した oa_enriched_citations v1／v2 ではなく、swagger ファイルに記載されたデータセット名そのもの（enriched_cited_reference_metadata、v3）を使い、フォールバックも残しています。それでもまだ誤っている場合、すべてのツールで include_raw: true を指定できます。これにより通常の解析／エラーハンドリングを省略し、上流からの HTTP ステータスと本文の先頭 500 文字をそのまま返します。そのため、コード変更と再デプロイをせずに、実環境での調査を通じて次の間違いを自己診断できます。
• レスポンスのエンベロープは、標準的な Solr 形式（{response:{numFound,docs:[...]}}）です。オープンソースの patent-dev/uspto-odp Go クライアントに含まれる実際のレスポンス例で確認済みです。認識できない形式の場合は、何も返さず空の結果にするのではなく、本文を含む upstream_parse: ... エラーを明示的にスローします。
• Final Petition Decisions は完全に確認済みで、推測に基づくものではありません。ルート（/api/v1/petition/decisions/search、POST、JSON {q, pagination:{offset,limit}, filters:[{name,value}]}）とレスポンス形式（{count, petitionDecisionDataBag:[...]}）は、同じ Go クライアントに含まれる実際のレスポンス例と一致しています。また、このパック独自の調査で、ルートが実環境に存在することも確認済みです（401 Unauthorized）。
• USPTO が null 日付を表すセンチネル値は "0001-01-01T00:00:00" です。このパックの出力では、どこでも null として扱います（登録されていない出願には grant_date がなく、紀元 1 年の日付にはなりません）。
• obsoleteDocumentIdentifier（USPTO 独自の、妙に保持されているフィールド名）は、呼び出し元には document_id として公開されます。これは文書ごとに安定したキーであり、実際には廃止されたデータではありません。
• このパックの構築中、ローカル／開発環境からアクセス可能な fleet 保持の認証情報はありませんでした（プラットフォームキーは、デプロイ済みゲートウェイのシークレットストアにのみ保存されています）。そのため、以下のデプロイ前スモークテストでは api.uspto.gov への実際のネットワーク呼び出しを行い、リクエスト／レスポンスのコードが正常に実行されることを確認しますが、確認できるのは認証拒否の経路のみで、実際のペイロードは取得できません。最初の実データによる検証は、デプロイ後に認証済みで行う実環境プローブとなります。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します：

{
  "mcpServers": {
    "uspto-office-actions": {
      "url": "https://gateway.pipeworx.io/uspto-office-actions/mcp"
    }
  }
}

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/uspto-office-actions/mcp の tools/list は、上記の表にあるツールに加えて、共有 Pipeworx メタツール（ask_pipeworx、 discover_tools、search_within、remember／recall など、ゲートウェイ全体で利用できるツール群）も返します。そのため、表示されるツール数はこの表より多くなります。単一パックのエンドポイントには現在、このパック独自のツールとともに、共有ツールがおよそ30個含まれています。接続の initialize 応答には正確なスコープが記載されており、その日の状況を確認する際の確かな情報源となります。

これは意図的な仕様であり、偶然の多重化ではありません。メタツールを使うことで、このパックが対応していない質問にも、カタログ全体を対象にルーティングする ask_pipeworx を介して回答でき、MCP サーバーをもう1つ追加する必要がありません。現在、メタツールを含めずにパックのエンドポイントをマウントする方法はありません。追加のスキーマにかかるコンテキストコストがルーティングの利点を上回る場合は、複数のパックエンドポイントに接続するのではなく、フルゲートウェイに一度だけ接続してください。

または、Pipeworx のフルゲートウェイに接続すると、このパックだけでなく、すべてのパックのツールが一覧に直接表示されます：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も、同じゲートウェイと同じ1837以上のデータソースに接続します。違いは、どのパックのツールが一覧に直接表示されるかだけです。どちらからでも、ask_pipeworx を使ってすべてのツールにアクセスできます。

MCP クライアントがない場合：HTTP 経由で呼び出す

curl -X POST https://gateway.pipeworx.io/v1/tools/search_office_actions \
  -H 'Content-Type: application/json' \
  -d '{"application_number":"17248024","limit":5}'

最初の呼び出しにアカウントは不要です。任意のツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/search_office_actions を実行します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージはローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントもゲートウェイへの往復通信も不要です：

{
  "mcpServers": {
    "uspto-office-actions": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-uspto-office-actions"]
    }
  }
}

または、直接実行して起動を確認します：

npx -y @pipeworx/mcp-uspto-office-actions

stdin/stdout 経由で MCP を使用し、initialize／tools/list／tools/call に応答します。対象はこのパックのツールのみで、上記のゲートウェイ接続が追加する共有メタツールは含まれません。同じソース、同じツールで、ask_pipeworx によるルーティングはありません。

ask_pipeworx の使用

ツールを直接呼び出す代わりに、自然な英語で質問できます。これは上記のパックエンドポイントでも、フルゲートウェイでも利用できます：

ask_pipeworx({ question: "your question about Uspto Office Actions data" })

ゲートウェイが適切なツールを選択し、引数を自動的に設定します。

詳細

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT