他社特許の相談が知財部に来たときに、過去の鑑定書・社内見解・回避設計の検討記録を探し、似た相談でどう判断したかを根拠付きで返す

処理の起点を決める

取り込みと相談で、起点が2つあります。

取り込みは、知財部が案件の台帳で相談の終了を登録したことを起点にします。 結論が出るまでの記録は取り込みません。検討の途中のメモに書かれた仮の見立てが、過去の判断として検索に出るのを防ぐためです。 終了の登録を検知できない台帳なら、毎晩、終了日で絞った一覧を取りに行きます。

過去の約1,200件は、別に一括で取り込みます。 台帳から特許番号と結論が引けない古い記録は、知財部が1件ずつメタデータを付けてから入れます。 付けられないものは、結論を unknown にして入れ、画面にそう出します。

相談の側は、受付フォームの送信を起点にします。 対象の特許番号が書かれていない相談は、同じ特許の検索ができないので、受付の担当者が番号を確かめてから動かします。

入力データを集める

質を決めるのは、案件の台帳のファミリーの列です。 分割出願や外国出願の番号がファミリーとしてまとまっていないと、同じ発明の過去の判断が「似た判断」の側に落ち、重みを取り違えます。

回避設計の検討記録には、採用されたかどうかを必ず持たせます。 検討しただけで採用しなかった案が、「この特許は回避設計で解決した」という記録に見えてしまうためです。

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

取り込みでは、案件の台帳から JSONL を作ります。 1文書につき1行で、structData に台帳の項目、acl_info に読める人とグループを入れます。

{"id": "IP-2021-0143-op01",
 "structData": {"case_id": "IP-2021-0143", "doc_type": "external_opinion",
   "target_patent": "JP7XXXXXX", "family_id": "FAM-0388",
   "competitor": "C社", "product_line": "PL-03",
   "conclusion": "non_infringement", "design_around_adopted": "none",
   "closed_on": "2021-11-30"},
 "content": {"mimeType": "application/pdf",
   "uri": "gs://ip-archive/IP-2021-0143/opinion_01.pdf"},
 "acl_info": {"readers": [{"principals": [
   {"group_id": "[email protected]"},
   {"user_id": "[email protected]"}]}]}}

doc_type は external_opinion（鑑定書）／internal_view（社内見解）／design_around（回避設計）／claim_chart（対比表）の4つ、conclusion は non_infringement ／ invalidity ／ license ／ design_changed ／ unknown です。family_id・doc_type・conclusion・closed_on は、スキーマで索引可能にします。 絞り込みに使う項目は、索引可能にしておく必要があります。

閲覧者は、人ではなくグループで付けます。 ドキュメントでは、1つの文書に付けられる閲覧者は3,000までとされています。知財部のグループと、製品群ごとの開発の責任者のグループに分け、異動はグループの側で直します。

相談のときの同じ特許の検索は、ファミリーの番号で絞ります。

family_id: ANY("FAM-0388") AND NOT conclusion: ANY("unknown")

似た構成要件の検索には、絞り込みをかけません。 問い合わせの文には、受付フォームの「気になっている請求項」の文をそのまま入れます。特許番号を文に入れると、番号の一致が強く効いて、似た判断が出にくくなります。

AIへ渡す前に整形する

1. メタデータの点検 … 台帳とファイルの対応を取り、ファイルの無い行と行の無いファイルを一覧にして、取り込みを止めます
2. ファミリーの付け直し … 同じ発明の分割出願・外国出願の番号を1つの family_id にまとめます。台帳に無いものは、知財部が公報を見て付けます
3. 閲覧者の点検 … acl_info に知財部のグループが入っていない文書が無いかを見ます。入っていない文書は、知財部からも検索できなくなります
4. 解析の設定 … レイアウトパーサーを使い、段落・表・リスト・見出しを検出させます。対比表の行（構成要件と自社の構成の組）が表として取れることが要です
5. 分割の設定 … 分割の大きさは100〜500トークン（既定500）です。見出しを各部分に付ける設定（includeAncestorHeadings）を有効にします
6. 古いスキャンの扱い … 紙で受け取った古い鑑定書はOCRのパーサーで読みます。PDFの最初の500ページまでしか読まれません

5番目は、データストアを作る前に決めます。 ドキュメントでは、文書の分割はデータストアを作った後で有効にも無効にもできないとされています。アクセス制御も同じで、作り直すと1,200件の取り込みとメタデータの点検をやり直すことになります。

includeAncestorHeadings が効くのは、鑑定書が「構成要件Aについて」「構成要件Bについて」と見出しで分けて書かれているからです。 見出しが無い断片は、どの構成要件の話か分からないまま引用されます。 既定は無効なので、明示して有効にします。

AIに処理させる

させるのは、過去の記録から当時の結論と、その結論を支えた記載を引用付きで並べることだけです。

2行目が、いちばん起きやすい失敗です。 同じ特許について「非侵害」と結論した鑑定書が見つかると、AIは「本件も同様に非侵害と考えられます」と書きたくなります。当時と今回で製品の構成が1か所違えば、結論は変わりえます。 だから、当時の前提（製品の世代と請求項の版）を必ず並べさせます。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次の指示を入れます。同じ特許の検索と似た判断の検索で、【検索の種類】だけを変えます。

あなたは製造業の知財部で、他社特許の相談を受けた担当者を手伝います。
回答を読むのは知財部の担当者で、引用された記録の原文を開いて確かめてから
今回の検討を始めます。

【検索の種類】{same_family | similar_elements}

【答え方】
1. 案件ごとに、案件番号、対象の特許番号、終了日、結論の区分を最初に書いてください。
2. 結論を支えた議論を、どの構成要件について、どういう理由で、という形で書いてください。
3. 回避設計の記録があれば、採用された変更と、採用されなかった案を分けて書いてください。
4. 当時の前提として、製品の世代と、検討した請求項の版（訂正の前か後か）が
   記録に書かれていれば、書いてください。書かれていなければ「記載なし」と書いてください。
5. 【検索の種類】が similar_elements のときは、各案件の最初に
   「別の特許についての判断です」と書いてください。

【厳守事項】
- 検索結果の記録に書かれていることだけで答えてください。
  特許法の一般的な知識や、記録に無い判例で補わないでください。
- 今回の相談の製品が特許に当たるか、当たらないかを書かないでください。
  「本件も同様に」「今回も非侵害と考えられる」のような文を書かないでください。
- 別の特許についての判断を、今回の特許の判断として書かないでください。
- 鑑定書と社内見解で結論が違うときは、両方をそのまま並べてください。
  どちらが正しいかを書かないでください。
- 根拠になる記録が見つからないときは、答えを作らないでください。

「本件も同様に」を名指しで禁じているのは、要約の最後の一文に出やすいからです。 禁じるのが判断だけだと、まとめの文として「同様の結論が見込まれます」と書きます。相談した開発部門にその文が転送されれば、知財部の回答として読まれます。

5番目の定型の一文は、画面で上下に分けるだけでは足りないからです。 一覧の一部が切り出されてメールに貼られると、上下の区別は消え、文の頭の一文だけが残ります。

出力形式を固定する

中継プログラムは、2つの answer メソッドの応答を、次の形にまとめて画面に渡します。

{
  "consult_id": "",
  "target_patent": "",
  "family_id": "",
  "same_family": {
    "status": "answered | skipped | none",
    "skipped_reasons": [],
    "answer_text": "",
    "cases": [
      { "case_id": "", "closed_on": "", "conclusion": "",
        "patent_status_changed": false, "change_note": "" }
    ],
    "citations": [ { "doc_id": "", "doc_type": "", "snippet": "", "uri": "" } ]
  },
  "similar_elements": {
    "status": "answered | skipped | none",
    "answer_text": "",
    "citations": []
  },
  "support_score": 0
}

1つ目の理由は、same_family と similar_elements を別の欄にできることです。 画面でもログでも、確実に引けた判断と、手がかりとしての判断が混ざりません。

2つ目は、patent_status_changed で当時からの変化を示せることです。 中継プログラムが監視の台帳を引き、当時の終了日より後に訂正や審判、権利の消滅があれば true にして、change_note に台帳の記載を写します。請求項が訂正されていれば、当時の対比表はそのままでは使えません。

3つ目は、status で「無かった」と「答えなかった」を分けられることです。 none は検索で1件も当たらなかったもの、skipped は当たったが答えを返さなかったものです。後者は、記録を人が開けば使えることがあります。

システムへ連携する

answer メソッドは、相談した開発部門の人ではなく、知財部の担当者の身元で呼びます。 アクセス制御は呼んだ人の身元で効くので、開発部門の人の身元で呼ぶと、その人に見せてよい記録だけで回答が作られます。 回答を開発部門に返すのは知財部の担当者です。

根拠の弱い回答は返させません。 groundingSpec の filteringLevel を FILTERING_LEVEL_HIGH にすると、基準に届かない回答は返らず、answerSkippedReasons に LOW_GROUNDED_CONTENT が入ります。その場合も、検索の段階で当たった記録の一覧は画面に出します。

検索の段階で返す件数は、既定の10件のままで始めます。 answer メソッドの検索の段階の件数は既定が10、上限が25です。同じ特許の検索は絞り込みが効いているので10件で足り、似た判断の検索で件数を増やすと、関係の薄い案件まで要約に混ざります。 検索結果は文書の単位ではなく、分割した部分の単位（searchResultMode の CHUNKS）で返させます。鑑定書のどの構成要件の段落を根拠にしたかを、引用で示すためです。

続けて聞くときは、セッションを使います。 answer メソッドは前の問い合わせのセッションの番号を受け取り、「その案件で、回避設計は採用されたか」のような続きの質問に答えられます。

人が確認する

1. 同じ特許の判断を先に読む … same_family の引用元を開き、結論と争点の構成要件を確かめます
2. 当時の前提を今回と比べる … 製品の世代、請求項の版、patent_status_changed を見て、当時の結論の前提が今回も成り立つかを検討します
3. 似た判断は手がかりとして読む … similar_elements は、構成要件の議論の組み立て方の参考にします
4. 当時の担当者に確かめる … 経緯が記録に無いものは、当時の担当者に聞きます
5. 回答を書く … 今回の検討の結論は、知財部が自分の言葉で書きます

目標は、36件をならして1件35分です。 同じ特許の判断の確認に15分、似た判断の確認に10分、前提の比較と担当者への確認に10分を見ています。35分を大きく超える月は、unknown の記録が多く当たっているか、ファミリーの付け方に漏れがあります。

例外に対処する

上から3行目が、いちばん大事な例外です。 同じ特許の判断が無いときに、似た判断で欄を埋めると、初めての特許なのに「過去に検討済み」と読まれます。

記録を残す

• 相談の番号、特許番号、ファミリーの番号、受け付けた日時
• 2つの answer メソッドの要求（絞り込みの式、preamble の版）と応答の全文
• 支持スコアと、スキップの理由
• 監視の台帳から写した状態の変化
• 知財担当が開いた引用元と、今回の検討で参照した過去の案件
• 取り込んだ記録の番号、メタデータ、acl_info の内容と取り込んだ日時

5つ目は、次の取り込みのメタデータになります。 今回の検討でどの過去の案件を参照したかを残せば、同じ特許の次の相談で、判断のつながりをたどれます。