他社から届いた特許・商標の警告書について、自社製品の資料と社内の検討メモから回答書の下書きと確かめるべき論点を作り、知財と法務の担当の判断に回す

処理の起点を決める

起点は2つあります。 1つ目は、警告書が案件のフォルダの「受領した警告書」に保存されたことです。ここで動くのは要点の取り出しと回答期限の仮登録だけです。 2つ目は、知財の担当が権利の内容と対象の品番を確定させ、案件のフォルダの「確定した権利」に保存したことです。対比表と論点と回答書の下書きは、2つ目を起点に作ります。

2段に分けるのは、期限を先に押さえるためです。 権利の内容を確かめるのに数日かかることがあっても、回答期限の候補は警告書を保存したその日に受付簿に載ります。

取引先から転送された警告は、同じフォルダに「転送元の取引先」を書いて保存します。 転送の型は、取引先への回答と、権利者への回答の2通が要ることがあるので、受付簿で別の種類として扱います。

入力データを集める

質を決めるのは、権利の内容をどの時点で取ったかです。 権利の状態は、知財の担当が特許情報の検索で確かめた日と一緒に保存します。特許請求の範囲は、警告書が引いている公報の請求項と、確かめた日の請求項の両方を保存します。 両者が違えば、それ自体が論点になります。

社内の検討メモは、日付を落とさないことが大事です。 先行技術調査やクリアランスの記録は、いつ、何を見て、何を判断したかが書かれていて初めて論点の材料になります。 発売前の確認記録は、後で述べる先使用の論点の材料になります。

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

警告書の本文は、PDFから文字を取り出します。 書留で届いた紙は、複合機で文字の付いたPDFにしてから保存します。メールで届いたものは、本文と添付の両方を1つの文書として保存します。

製品の資料は、品番だけでなく版で引きます。 警告書が指摘している時期に売っていた版と、今の版で作りが違うことがあります。対比表は版ごとに作り、版の違いを論点に入れます。

検討メモは、権利の番号で当たるものを先に、技術分野で当たるものを後に並べます。 同じ権利を以前に調べていた記録があれば、それが最も強い材料です。

AIへ渡す前に整形する

1. 警告書の種類を分ける … 特許・実用新案と商標で、対比の仕方が違います。商標は商標と指定商品・役務、特許は請求項の構成要件で比べます
2. 請求項を構成要件に分ける … 知財の担当が分けたものがあればそれを使い、無ければAIの下書きを担当が直します
3. 資料を段落に切り出す … 仕様書とカタログを段落ごとに切り、文書名・版・頁・段落の番号を付けます
4. 引用の照合のために原文を残す … 切り出した段落の原文を、照合用にそのまま保存します
5. 発売日と警告書の日付を並べる … 製品の発売日、検討メモの日付、権利の出願日を時系列に並べます
6. 長い資料を絞る … 取扱説明書のように長いものは、構成要件の語で当たる段落だけを渡します
7. 個人の名前を落とす … 検討メモの担当者名は、照合に要らないので役職名に置き換えます

5番目の時系列は、AIにではなくプログラムで作ります。 日付は資料のメタデータから取り、どれが先かをモデルに推させません。 時系列は、先使用と有効性の論点を拾う材料になります。

AIに処理させる

させるのは、警告書と権利と自社の資料を照らして、判断の材料を決まった形の下書きにすることです。 侵害かどうか、権利が有効かどうかの結論はさせません。

論点の観点は、法律が定める枠に沿って決めておきます。

特許法第104条の3は、特許が特許無効審判により無効にされるべきものと認められるときは、特許権者は相手方に対しその権利を行使することができないとしています。第79条は、特許出願の際現に日本国内でその発明の実施である事業をしている者又はその準備をしている者が、通常実施権を有するとしています。AIにさせるのは、これらの枠ごとに社内の資料から材料を拾うことまでで、当てはまるかどうかは書かせません。

3行目がいちばん起きやすい失敗です。 「当該部材は樹脂製である」という構成要件に対し、仕様書に材質の記載が無いと、モデルは同じ型の一般的な作りから「樹脂製と考えられる」と書きます。この1行は、相手の主張を裏付ける材料にも、否定する材料にもなりえます。 資料に無ければ「資料で確かめられない」とし、設計の担当への質問に回します。

指示内容を固定する

あなたは製造業の知財部で、他社から届いた警告書を検討する担当を手伝う立場です。
判断はしません。判断の材料を、決まった形の下書きにします。

【入力】
警告書：{warning_letter}
確定した権利の内容：{claims}（構成要件に分けたもの。確かめた日付き）
対象の品番と版：{product}
製品の資料（段落番号付き）：{product_docs}
社内の検討メモ（日付付き）：{memos}
時系列：{timeline}

【作るもの】
1. 対比表：構成要件ごとに、製品の資料の該当する段落を引用してください。
   status は次から選んでください。
   - described ........ 資料にその構成に当たる記載がある
   - not_described .... 資料を読んでもその構成に当たる記載が無い
   - unclear .......... 記載はあるが、構成要件に当たるか言葉だけでは決まらない
2. 論点の一覧：決められた観点ごとに、資料から拾える材料と、確かめる先を書いてください。
3. 初回の回答書の下書き：受領したこと、検討していること、
   対象製品の特定と権利の根拠についての照会を書いてください。

【厳守事項】
- 引用は資料の文を一字一句そのまま写してください。要約して引用にしないでください。
- 資料に記載が無い構成は not_described とし、製品の一般的な作りから推して埋めないでください。
- 侵害する・しない、権利が有効・無効の結論を書かないでください。
  「可能性が高い」「考えにくい」のような見立ても書かないでください。
- 回答書の下書きに、侵害を認める文、侵害を否定して言い切る文、
  販売の停止・支払い・ライセンスの受け入れを約束する文を入れないでください。
- 日付の前後は、渡した時系列だけを使ってください。日付を推さないでください。
- 警告書に回答期限の記載があれば、書かれた文のまま写してください。日付の計算はしません。

「見立ても書かない」まで書くのは、結論を禁じただけでは見立てに逃げるからです。 「侵害しないと書くな」とだけ指示すると、「侵害の可能性は低いと考えられる」と書きます。 見立ては結論と同じように読まれ、下書きを読んだ担当の判断を先に決めてしまいます。

回答期限の日付を計算させないのは、到達の日の扱いが案件ごとに違うからです。 「本書面到達後2週間以内」の到達の日を、書留の受領日とするかメールの受信日とするかは、知財の担当が決めます。期限の計算はプログラムが受付簿の到達の日から行い、候補として知らせます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。 すべての項目を必須にし、オブジェクトには additionalProperties: false を付けます。公式のページでは、スキーマのオブジェクトのプロパティは最大100、入れ子は最大5段とされているので、表を深く入れ子にせず、配列を並べる形にします。

{
  "case_id": "",
  "letter": { "sender": "", "agent": "", "right_type": "patent | utility | trademark",
              "right_no": "", "target_products_text": "", "demands": [""],
              "deadline_text": "", "cited_claims_text": "" },
  "comparison": [ { "element_id": "A", "element_text": "",
                    "status": "described | not_described | unclear",
                    "quotes": [ { "doc": "", "version": "", "page": "", "para": "", "text": "" } ],
                    "question_to_design": "" } ],
  "issues": [ { "viewpoint": "right_status | literal | validity | prior_use | tm_limit | demands | notice_to_customers",
                "materials": [ { "doc": "", "date": "", "text": "" } ],
                "check_with": "", "note": "" } ],
  "reply_draft": "",
  "not_used_docs": [""]
}

1つ目の理由は、quotes をプログラムで照らせることです。 Azure Functions は quotes の text が、指定された文書・版・段落の原文に一字一句含まれるかを照らします。含まれなければその行に印を付け、知財の担当が最初に見る行にします。

2つ目は、status で設計の担当への質問を機械的に集められることです。 not_described と unclear の行の question_to_design を集め、事業部の設計の担当に1通の問い合わせとして送ります。 1行ずつ電話で聞いていた往復が、1回になります。

3つ目は、issues の観点を決めた語に固定できることです。 観点が7つの語のどれかに決まっているので、どの観点の材料が空かが一目で分かります。 先使用の材料が空なら、発売前の記録を探し直す合図です。

システムへ連携する

相手方や取引先へは、何も送りません。 回答書は下書きとして案件のフォルダに置くだけで、送付は法務の決裁の後に人が行います。 設計の担当への問い合わせも下書きまでにし、知財の担当が中身を見てから送ります。

受付簿の回答期限は「候補」として入れます。 知財の担当が到達の日を確かめて確定させるまで、期限の欄は候補の印付きで表示します。 確定した期限の1週間前と3日前に、担当と法務に知らせます。

人が確認する

この構成の出力は、すべて人が確かめてから使います。

1. 知財の担当が要点と期限を確かめる … 警告書の原文と要点を見比べ、到達の日を決めて期限を確定させます
2. 知財の担当が対比表を原文と照らす … 照合で印の付いた行から見ます。described の行も、引用の段落を開いて構成要件に当たるかを読みます
3. 知財の担当が論点に足し引きする … 材料の空いた観点を探し直し、要らない観点に理由を書きます
4. 法務の担当と社外の弁理士・弁護士が方針を決める … 対比表と論点を材料に、回答の方針を決めます
5. 法務の担当が回答書を仕上げ、決裁に回す … 下書きを方針に合わせて直します

2番目で described の行も読むのは、言葉が合っていても意味がずれることがあるからです。 構成要件の「弾性部材」と仕様書の「弾性体」は同じものかもしれず、違うものかもしれません。その判断が対比表の要で、AIに任せない部分です。

目標は、1件あたり240分です。 対比表を原文と照らすのに120分、論点の足し引きに45分、要点と期限の確認に15分、回答書の仕上げに60分を見込みます。

例外に対処する

5行目の「印の多い出力は作り直す」は、運用の最初に決めておきます。 引用の半分以上に印が付いた出力は、資料の切り出しか入力の絞り方に問題があり、直すより作り直すほうが早いです。

記録を残す

• 警告書の原本、到達の日、受付簿の記録
• 知財の担当が確定させた権利の内容と、確かめた日
• AIに渡した入力（資料の文書名・版・段落の番号）と、AIの出力の全文
• 引用の照合の結果と、担当が直した箇所
• 法務と社外の専門家が決めた方針と、送った回答書
• 使ったモデルのデプロイ名と、指示文の版

3つ目で「渡した資料の版」を残すのは、後で訴訟になったときに、当時の検討の基になった資料を示すためです。 どの版の仕様書で対比したかが残っていないと、検討の経緯を説明できません。