拒絶理由への応答を、過去の中間処理の記録から似た事例を引いて組み立てる

処理の起点を決める

担当者が拒絶理由の内容を検索の窓口へ入力したときを起点にします。

自動で走らせないでください。 拒絶理由通知が届くたびに自動で検索すると、担当者が中身を読む前に結果が出ます。まず通知を自分で読むことが、この業務の出発点です。

入力の形は2通り用意してください。

2つ目を必ず用意してください。 1件の拒絶理由に論点が複数あることが普通です。論点ごとに探したいという要求が、実務では強くあります。

もう1つの起点として、応答の提出後があります。 提出した応答と、その後の結果（登録／拒絶査定）を記録へ足します。この蓄積がないと、検索の対象が増えません。

結果が確定するのは数か月後です。 提出時に記録を作り、結果が出た時点で更新する二段構えにしてください。結果の欄が空のままの記録が残ると、参考にできません。

入力データを集める

データの取得方法を決める

論点の分類が、この構成の質を決めます。 「進歩性」だけでは粗すぎます。次の粒度で分けてください。

小区分まで分けることが重要です。 「進歩性」で引くと900件中600件が当たります。「2文献の組み合わせ」で絞れば、60件程度に落ちます。

この分類は、過去の記録に後から付けることになります。 900件すべてに人が付けるのは現実的ではありません。生成AIに下書きさせて、人が確かめる形にしてください。1件あたり1分程度で済みます。

「その後の結果」は、必ず取り込んでください。 次の形で持ちます。

「対応の種類」と「結果」の組み合わせが、この構成でもっとも価値のある情報です。 「2文献の組み合わせによる進歩性の拒絶に、意見書のみで争って登録になった事例が過去に4件ある」と分かれば、方針の判断が変わります。

意見書・手続補正書： PDFのままでは検索できません。文字が埋め込まれたPDFであることを確かめてください。 古い案件はスキャン画像のことがあります。

引用文献の情報： 文献番号だけでも役に立ちます。同じ文献が繰り返し引かれることがあるためです。 「この文献が引かれたときは過去にこう応答した」という引き方ができます。

AIへ渡す前に整形する

1. 文書の種類の判別 … 拒絶理由通知／意見書／手続補正書／方針メモを分けます
2. 案件との紐づけ … 出願番号で紐づけます。ファイル名に出願番号が入っていない文書があるため、本文からも拾います
3. 論点の分類の付与 … 拒絶理由通知の本文から、小区分を判定します。生成AIの下書きを人が確かめます
4. 請求項ごとの分解 … 1つの通知で請求項ごとに理由が違うことがあります。論点は請求項の単位で持ちます
5. 結果の紐づけ … 知財管理システムから、査定の結果を取り込みます
6. 公開状況の確認 … 未公開の出願は、閲覧できる範囲を限定します
7. 索引への取り込み … 属性（論点の小区分、技術分野、結果）を付けて索引にします

4の請求項ごとの分解が、精度を大きく左右します。 「請求項1は進歩性、請求項5は記載要件」という通知を1件として扱うと、検索の当たりが濁ります。

6の公開状況は、知財の用途では必須の設計です。 出願から1年6か月を経ていない案件は公開されていません。全社に開放する構成にしないでください。 検索基盤のアクセス制御で、知財部の中でも見られる範囲を分けられます。

AIに処理させる

2つの工程に分けます。

（1）検索基盤にさせること

（2）Gemini API にさせること

応答の文案は書かせません。 「このように補正してください」「意見書には次のように書いてください」といった出力を禁じてください。

特許性の判断もさせません。 「この補正で進歩性が認められる可能性が高い」といった記述を出させないでください。審査官の判断を予測することは、この構成の範囲外です。

過去の事例の評価もさせません。 「この応答は適切でした」といった判断は不要です。結果（登録／拒絶査定）という事実を示せば足ります。

指示内容を固定する

役割と禁止事項は system_instruction に書きます。

【system_instruction】
あなたは知財部で中間処理の検討を支援する担当者です。
今回届いた拒絶理由について、過去の似た事例を探して並べることが役割です。

【厳守事項】
- 応答の文案を書かないでください。
  「このように補正してください」「意見書には次のように書いてください」
  と書かないでください。
  補正の内容と意見書の論理は、担当者と代理人が組み立てます。
- 特許性を判断しないでください。
  「進歩性が認められる可能性が高い」「この補正では拒絶が維持される」
  と書かないでください。
  **審査官の判断を予測することは役割ではありません。**
- 過去の応答の良し悪しを評価しないでください。
  「この応答は適切でした」「もっと早く補正すべきでした」と書かないでください。
  結果（登録／拒絶査定）という事実を示すだけにしてください。
- 検索の結果に含まれていない事例を作らないでください。
  該当が見つからない場合は「該当する事例が見つかりません」と返してください。
- 事例ごとに、必ず出願番号と、元の文書の該当箇所を示してください。
  示せない事例は出さないでください。
- 「似ている点」と「違う点」を必ず両方書いてください。
  似ている点だけを書くと、当てはまらない事例が採用されます。
- 技術分野が違う事例を排除しないでください。
  論点が同じなら、技術分野が違っても参考になります。
  ただし、違うことは明記してください。
- その案件の結果（登録／拒絶査定／取下げ）を必ず併記してください。
  結果が未確定の場合は「係属中」と書いてください。
- 並べ替えは、論点の一致の度合いで行ってください。
  結果が良かった事例を上に並べないでください。
  **うまくいった事例だけを見せると、判断が偏ります。**

論点の読み取りの指示は次のようになります。

下の拒絶理由通知について、論点を請求項ごとに抜き出してください。

【厳守事項】
- 論点は、下の「論点の分類」の小区分から選んでください。
  分類にない論点が出た場合は「その他」とし、内容を書いてください。
- 請求項ごとに分けてください。1つの通知に複数の論点があります。
- 引用文献の数と、組み合わせの構造（単一／2文献／文献＋周知技術）を書いてください。
- 通知に書かれていない理由を推測で補わないでください。
- 拒絶の当否について意見を書かないでください。

【拒絶理由通知】
{office_action_text}

【論点の分類（大区分 / 小区分）】
{issue_taxonomy}

【この案件の属性（技術分野 / 出願年 / 応答の回数）】
{case_attributes}

「うまくいった事例だけを見せない」の指示が、この構成で特に重要です。 登録になった事例だけを上に並べると、「意見書だけで争って通った」事例が目立ち、それが常道のように見えます。 実際には同じ方針で拒絶査定になった事例のほうが多いかもしれません。両方を並べてこそ、判断の材料になります。

「違う点を必ず書く」の指示も外せません。 似た事例に見えても、引用文献の数が違う、補正の余地が違う、という差があります。似ている点だけを示されると、当てはまらない事例を採用してしまいます。

「技術分野が違う事例を排除しない」の指示には理由があります。 記載要件の拒絶は、技術分野を問わず似た構造になります。分野で絞ると、有用な事例を落とします。

出力形式を固定する

{
  "query_id": "",
  "input_type": "full_notice | issue_only",
  "detected_issues": [
    {
      "claim_numbers": [],
      "major_category": "",
      "minor_category": "",
      "cited_documents_count": 0,
      "combination_type": "single | two_docs | doc_plus_common | none",
      "summary_of_objection": ""
    }
  ],
  "precedents": [
    {
      "application_number": "",
      "filing_year": "",
      "technical_field": "",
      "matched_issue": "",
      "similar_points": [],
      "different_points": [],
      "response_type": "amendment | argument | both | divisional",
      "amendment_summary": "",
      "outcome": "granted | rejected | withdrawn | pending",
      "response_round": 0,
      "source": { "document": "", "location": "" },
      "similarity": "high | medium | low"
    }
  ],
  "no_match_reason": "",
  "counts": { "granted": 0, "rejected": 0, "withdrawn": 0, "pending": 0 }
}

Gemini API で構造化した出力を得るには、response_format にオブジェクト型を指定して mime_type を application/json にし、schema にスキーマを渡します。 対応するのは JSON Schema の一部で、string / number / integer / boolean / object / array / null の型と、title / description、オブジェクトの properties / required / additionalProperties、文字列の enum / format、数値の enum / minimum / maximum、配列の items / prefixItems / minItems / maxItems が使えます。

すべての JSON Schema の機能に対応するわけではありません。 また、非常に大きなスキーマや深くネストしたスキーマは受け付けられないことがあります。 上のスキーマ程度の深さであれば収まりますが、項目を増やすときは確かめてください。

similar_points と different_points を両方持たせていることが、この構成の核です。 片方だけでは、当てはまるかを判断できません。

counts が、実は最も見られる部分になります。 「同じ論点で過去12件、うち登録8件・拒絶査定3件・取下げ1件」という数字が、方針の判断に直接効きます。

similarity は3段階にしてください。 5段階にすると、中間の区別が曖昧になります。

source に文書名と該当箇所を持つことは必須です。 担当者は必ず元の応答書を読みます。どこを見ればよいかが分からないと、結局全文を読むことになります。

システムへ連携する

検索の結果を一覧として出すだけで、他のシステムへの書き込みは行いません。

知財管理システムへ書き戻さないでください。 案件の管理情報に、検索の結果が混ざると、後から何が正式な記録か分からなくなります。

特許事務所へ自動で送らないでください。 方針は担当者が決めて伝えます。検索の結果をそのまま送ると、事務所がそれを前提に案を作ります。

記録への追加は、応答の提出後に人が行ってください。 提出した応答と方針のメモを、索引の対象へ足します。結果が出た時点で、結果の欄を更新します。

この更新を運用に組み込むことが、この構成を続ける条件です。 更新されなければ、索引は古いまま止まります。査定の通知を受けたときに結果を入れる、という手順を定めてください。

人が確認する

担当者が、事例を読んで判断します。

確認を速くするための設計が効きます。

• counts を一覧の先頭に置く
• 元の応答書の該当箇所へ直接開けるリンクを付ける
• outcome を色で分ける
• 同じ引用文献が引かれた事例に印を付ける
• 過去に自分が担当した案件に印を付ける

4つ目が実務では効きます。 同じ引用文献が繰り返し引かれることがあります。その文献に対する過去の反論は、そのまま使えることがあります。

outcome が rejected の事例を必ず読んでください。 通らなかった応答から学べることのほうが多くあります。登録になった事例だけを見ると、その方針が常に有効だと誤解します。

最終的な方針は担当者が決めます。 過去に12件中8件が登録になった方針でも、今回の案件で有効とは限りません。発明の内容と、事業上の重要度を踏まえた判断が要ります。

例外に対処する

「外国出願の中間処理を混ぜない」は、必ず守ってください。 米国の非自明性と日本の進歩性は、判断の枠組みが違います。混ぜて検索すると、当てはまらない事例が上位に出ます。

記録を残す

この記録は、論点の分類と検索の精度を育てる材料になります。

• 検索の入力（貼り付けた通知、書いた論点）
• 読み取った論点の分類
• 返した事例と、その similarity
• 担当者が実際に採用した事例
• 採用しなかった事例と、その理由
• 今回決めた方針と、その後の結果

「担当者が実際に採用した事例」を必ず記録してください。 上位に出した事例が使われているかが、検索の精度を測る指標です。3位以下の事例ばかり採用されるなら、並べ替えに問題があります。

「採用しなかった理由」も記録してください。 「技術分野が違いすぎる」「補正の余地が違う」といった理由が集まれば、different_points に書かせるべき観点が分かります。

中間処理の記録には、未公開の出願の内容が含まれます。 公開前の発明の内容は、新規性を失わせないための管理が要ります。外部のAIサービスへ渡す範囲を、知財部として決めてください。

検索基盤のアクセス制御を必ず設定してください。 IAM による制御と、データソース単位のアクセス制御に対応しているため、出願前の案件を見られる人を限定できます。

保存期間は、知財の記録の保存方針に合わせてください。 中間処理の記録は、将来の権利行使や無効審判で参照されることがあります。