英文の特許証・登録証を読み取り、登録番号・登録日・権利者・存続期間を権利台帳に転記して、台帳との食い違いと年金の納付期限を拾う

処理の起点を決める

毎日決まった時刻に、受付フォルダの新しいファイルを処理します。 特許証は登録の後に届くもので、届いたその時間に台帳へ載せる急ぎはありません。次の年金の期限は、早いものでも数か月先だからです。1日1回にすれば、事務担当は朝に前日の分をまとめて確かめられます。

保存するのは事務担当で、ファイル名の先頭に案件番号を付けます。 案件番号が無いファイルは、照合の相手を決められないので処理しません。現地代理人のメールには、特許証のほかに請求書や報告レターが添付されることが多く、どれが特許証かは人が選んで保存します。

処理は小さな Python のプログラムです。受付フォルダの一覧を取り、処理済みの印が無いファイルを1件ずつ読み、成功したものだけを処理済みフォルダへ移します。 受付フォルダに残っている数が、そのまま未処理の数になります。

3日続けて受付フォルダに残ったファイルは、担当に知らせます。 読み取りに失敗し続けるファイルが、誰にも気づかれずに残るのを防ぐためです。特許証は届いてから台帳に載るまでの間、年金の期限がどこにも無い状態なので、残ったままにしないことが大事です。

入力データを集める

質を決めるのは、年金の規則表です。 規則表が古ければ、正しく読み取っても期限は誤ります。各行に確かめた日付を持たせ、1年以上確かめていない行は計算に使わず印を付けます。

権利の種類も必ず台帳から取ります。 USPTO の案内では、意匠や植物の特許には維持年金が要らないとされています。特許と意匠を取り違えると、要らない期限が台帳に載るか、要る期限が載りません。

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

読み取りは AnalyzeDocument に FeatureTypes として FORMS と QUERIES を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。 同期の処理は1ページずつなので、Python でPDFの書誌事項のページだけを画像にして送ります。 米国の特許なら表紙の1ページ、証書の形の国なら1〜2ページです。

質問は、何の日付かを特定して聞きます。 公式の手引きは、日付が複数ある文書では「What is the date?」のような曖昧な聞き方を避け、具体的に聞くことを勧めています。

国ごとに見出しの言葉が違うので、質問の文言は国ごとに持ちます。 手引きが勧めるとおり、その国の特許証の見出しの言葉（「Date of Patent」「Date of Grant」など）を使うほうが答えが安定します。

質問の答えは、キーと値の結果とも照らします。 両方が同じ値を返したときだけ「読めた」とし、違えば ambiguous にします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFとパスワード付きのPDFは扱えません
2. ページの切り出し … 書誌事項のページだけを画像にします。同期の処理は10MBまでなので、解像度を上げすぎないようにします
3. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。米国の特許の表紙は文字が小さいので、300 DPIで画像にします
4. 言語の確認 … 英語以外の文が多ければ質問を外し、キーと値と全文だけで読みます
5. 国の確認 … ファイル名の案件番号から台帳の国を引き、質問の文言と規則表の行を国で選びます

3番目を軽く見ないでください。 小さな文字で読めないだけの出願番号は、「書かれていない」と区別がつきません。

AIに処理させる

させるのは、番号と日付を「何の番号・日付か」と組にして、原文のまま取り出すことだけです。

日付は、書かれた文字列と、年・月・日に分けた値の両方を返させます。 「12/03/2026」のように日と月の順が決められない書き方なら、分けた値を空にして ambiguous にします。 国の書き方の慣習から推して決めさせません。

権利者は、配列で全員を返させます。 共同出願で権利者が複数いる特許証は珍しくなく、1人目だけを写すと、台帳の共有者の欄との食い違いが見えなくなります。 住所も綴りのまま写させ、どのクライアントに当たるかは対応表でプログラムが決めます。

存続期間に関わる記載は、原文を写すだけにします。 米国の特許の存続期間は、MPEP（米国の審査便覧）の説明では、米国での出願日から20年で、特許庁の遅れによる調整や延長で変わることがあり、ターミナルディスクレーマーの日付が特許の表紙に印刷されていた例も書かれています。こうした記載があるかどうかを台帳に載せ、満了日の計算は弁理士が確かめます。

1行目がいちばん起きやすい失敗です。 登録日と国名を渡すと、AIは頼まなくても「次の年金は○年○月○日」と書き足します。その計算が正しいかは、規則表を見ない限り分かりません。

指示内容を固定する

あなたは特許事務所の外国出願の管理の担当として、英文の特許証・登録証を読み、
権利台帳に登録するための項目を取り出します。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 登録番号と登録（発行）の日
2. 出願番号と出願の日
3. 優先日と優先権の基礎の番号、関連する出願
4. 権利者（特許権者・譲受人）の名称と住所
5. 発明の名称
6. 存続期間に関わる記載（期間の調整・延長・ディスクレーマーなど）

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- not_found .. その項目が書かれていない
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 日付は、date_text に書かれた文字列をそのまま写し、
  year / month / day に分けた値を入れてください。
  日と月の順が決められない書き方なら、分けた値を空にして ambiguous にしてください。
- 日付には、それが何の日付かを date_type に必ず付けてください。
  見出しの文字から決められなければ ambiguous にしてください。
- 年金の期限や存続期間の満了日を計算しないでください。
- 番号は書かれたとおりに写してください。記号や空白を足したり消したりしないでください。
- 権利者の名称は綴りのまま写してください。依頼人の社名に直さないでください。
- 存続期間に関わる記載は、原文を写すだけにしてください。
- 権利を維持すべきかは書かないでください。
- 英語以外の文が含まれていれば、language_note にその旨を書いてください。

【読み取り結果】{textract_result}
【国】{country}
【権利の種類（台帳の値）】{right_type}

「日と月の順が決められなければ空にする」は、書かないと必ず破られます。 AIは国の慣習から推して日付を確定させます。推した日付が誤っていても、台帳の上では正しい日付と見分けがつきません。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に json_schema）で形を守らせます。

{
  "patent_no": "",
  "dates": [
    { "date_type": "grant | filing | priority | publication | other",
      "date_text": "", "year": "", "month": "", "day": "",
      "status": "ok | not_found | unreadable | ambiguous", "evidence": "" }
  ],
  "application_no": { "value": "", "status": "" },
  "owners": [ { "name_text": "", "address_text": "" } ],
  "title_text": "",
  "term_notes": [ { "original": "", "note_ja": "" } ],
  "language_note": ""
}

1つ目の理由は、日付の種類と値が組になっていることです。 プログラムは date_type が grant か filing かで規則表の起点を選び、起点に使った日付と規則表の行を、期限と一緒に台帳の登録案に載せます。

規則表の行は、たとえば次のように持ちます。値は公式の案内で確かめたものだけを入れます。

表の値をプログラムに直接書かないのが、この設計の要です。 規則が変わったときに直すのは表の1行で、プログラムと生成AIの指示は変えずに済みます。

2つ目は、照合の結果を別の層に置けることです。

システムへ連携する

権利台帳へは、人が確定するまで書き込みません。 年金の期限は、台帳に載った瞬間から督促や納付の段取りの起点になるからです。

AnalyzeDocument の HumanLoopConfig（Amazon Augmented AI による人の確認）は使いません。公式の説明で、2026年7月から保守のみの扱いになり、新規の利用者は受け付けていないとされています。 人の確認は、自社の一覧で行います。

人が確認する

1. needs_human を先に見る … 日と月の順が決められなかった日付と、読めなかった番号です。画像を開いて値を確定します
2. 起点の日付を見る … 期限の計算に使った日付が、規則表の起点（登録日か出願日か）と合っているかを見ます
3. mismatch を弁理士に回す … 弁理士が、台帳を直すか、現地代理人に訂正を確かめるかを決めます
4. 確定して登録する … 確定したものだけが台帳に載ります

2番目を省かないでください。 期限の計算はプログラムが行いますが、起点に使う日付を選んだのはAIの date_type です。 種類の付け間違いは、計算が正しいほど気づきにくくなります。

目標は、80件をならして1件3分です。 match だけの特許証は起点の日付を見て終わり、権利者名が食い違う特許証は弁理士に回す文を整えるので数分かかります。

例外に対処する

上から2行目までが大半を占めます。 どれも画像の問題で、現地代理人に電子の特許証の写しを頼む取り決めが効きます。

記録を残す

• 元の特許証のPDFと、保存した日時
• AWS Textract の結果のJSON全文
• Claude API の出力（dates、owners、term_notes）
• 期限の計算に使った起点の日付と、規則表の行とその確認日
• 照合の結果と、人が値を直した記録
• 確定した登録内容と、確定した人・日時

4つ目を残すのは、規則表が後から直ることがあるためです。 規則表を直したとき、どの権利の期限を計算し直せばよいかが、この記録から分かります。