商標の審査経過を監視するプロダクトの作り方：ステータス変更から検証可能な対応事項まで

商標監視でもっとも危険なプロダクト上の落とし穴は、「新しいステータス」をそのまま「3日以内に支払いが必要です」と言い換えてしまうことです。実際の案件記録には、出願番号、登録番号、書類、手続きの履歴、維持手続きのマイルストーン、公式の通知が含まれます。一方で、公開されている出願情報は、第三者が公式に見せかけた勧誘や詐欺的な通知を送るためにたびたび利用されています。監視プロダクトはまずユーザーが公式記録を確認できるようにし、そのうえで変更内容を弁護士や権限のある権利者に回して判断を仰ぐべきです。

r/TRADEMARKの不審なSMSに関するスレッド（https://www.reddit.com/r/TRADEMARK/comments/1v9amfu/received_this_text_suspecting_scam/）では、出願人がステータスのアラートを受け取り、コメント欄ではTSDRを直接確認するよう助言されていました。フォーラムの返信は、法的判断や公式な連絡方法に関する規則の代わりにはなりません。ただし、明確なユーザー要件が浮かび上がります。アラートは速いだけでなく、どの公式案件記録と書類に対応しているかを証明できなければなりません。

主キーはブランド名ではなく案件記録

同じ文字列でも、複数の出願人、商品・役務の区分、法域、出願段階に該当することがあります。類似するブランド名だけを監視対象にすると、無関係な記録が大量に混ざります。自社の案件を監視する場合は、法域と出願番号または登録番号の組み合わせを安定したキーとして使ってください。商標の文字列、権利者名、区分は属性であり、一意の識別子ではありません。

USPTOのステータスと書類に関するガイド（https://www.uspto.gov/trademarks/apply/check-status-view-documents）では、ステータスの確認、書類の閲覧とダウンロード、維持手続き情報の確認にTrademark Status and Document Retrieval（TSDR）を使うよう推奨しています。同ページには、新しい書類が提出日当日にすぐ表示されない場合があるとも記載されています。そのため、監視プロダクトは、直近で確認に成功した時刻を記録し、「今日は表示されなかった」ことを「庁が何も受け付けていない」と解釈しないようにする必要があります。

各スナップショットには、少なくとも出願番号、現在のステータス文言、ステータスの日付、案件記録の所在、主要な当事者、商品・役務、書類一覧、次回の維持手続き情報、ソースURLを保存します。標準化されたフィールドを使うと絞り込みが簡単になりますが、プロダクト側の言い換えによって法的な意味が変わらないよう、元のステータスと書類への参照は必ず保持してください。

ステータス変更と新規書類という2つのイベントストリーム

拒絶理由通知（office action）は、ステータスや処理ノードが変わる前に書類として先に現れることがあります。逆に、実質的な新規書類がないままステータス文言だけが変わることもあります。毎日1つのステータス文字列だけを比較していると、本当に読むべき資料を見落とします。

イベントモデルでは、status_changed、document_added、party_changed、maintenance_window_changed、source_unavailableを個別に記録します。書類についても、書類の種類、発送日または作成日、ダウンロード状況、生成した要約のバージョンを保持します。要約はトリアージの補助にすぎず、ユーザーが公式の原文を開けるようにしておく必要があります。

繰り返しダウンロードする場合は、出願番号と公式書類の識別子を組み合わせて冪等性を確保します。書類の到着が遅れた場合や目録が改訂された場合は、過去の通知を上書きせずにバージョンを追加します。ソースの障害（404）、レート制限、解析エラーが発生した場合は、「新たな進捗なし」を生成するのではなく、障害による中断として扱うべきです。

USPTOの商標バルクデータのページ（https://www.uspto.gov/trademarks/apply/check-status-view-documents/trademark-bulk-data）では、TSDR APIによって案件のステータス、書類、画像にプログラムからアクセスでき、利用にはAPIキーが必要だと説明されています。USPTOはオープンデータポータルとバルクデータも提供しています。どのインターフェースを使うかは、規模、適時性、ライセンス、必要なフィールドに基づいて判断すべきです。人間向けのページを高頻度でスクレイピングして、安定したAPIのように見せかけるべきではありません。

アクションアイテムの期日には人による確認が必要

システムは公式のフィールドや書類から期日の候補を抽出できますが、それが最終的な法定期限だと自動的に保証することはできません。期日は送達方法、延長、祝日、手続きの段階、その後の書類によって変わる可能性があります。信頼できる設計では、機械抽出した期日を候補として扱い、元の記載箇所と根拠となるルールを表示したうえで、弁護士または期限管理担当者による確認を必須にします。

確定したアクションアイテムには、担当者、事前リマインダー、必要な資料、外部の代理人、完了の証跡を含めます。期日が変わったときに、既存タスクの期日を通知なく変更してはいけません。変更前の値、変更後の値、変更の根拠、再確認が必要かどうかを表示する必要があります。完了を記録する際は、単にチェックを入れるだけでなく、提出書類、受領証、または担当者のメモへのリンクを含めます。

維持手続きのマイルストーンも同様です。USPTOの商標保護のヒント（https://www.uspto.gov/trademarks/protect/ten-things-you-can-do-protect-your-trademark-application-or-registration）では、TSDRで情報と期限を確認し、不審な連絡を受けた場合は公式記録やサポート窓口に立ち返るよう勧めています。プロダクトは見落としを減らすことはできますが、手続き上の義務の判断において権利者や専門家の代わりにはなれません。

類似する新規出願：検討候補の提示のみ

ブランドオーナーは、類似する文字列、発音が似た綴り、図形の説明、関連する商品・役務を監視したい場合があります。ここでの一致結果は、自社案件のステータスとはまったく別物です。関連する可能性のある出願を拾い上げたものであり、侵害の判断や異議申立ての推奨ではありません。

最初のバージョンでは、ユーザーが文字列のバリエーション、区分の範囲、市場、除外ワードを定義でき、出願人、出願日、商品・役務、ステータス、公式案件記録を表示します。類似度スコアは文字列、区分、出願人の各フィールドに分解できる必要があり、スコア92を「92%侵害に該当」のように表現してはいけません。図形商標や複雑な商品・役務の記述では、特に専門家の判断が必要です。

ユーザーがさらに評価すると決めた場合、プロダクトは「弁護士にレビューを依頼」タスクを作成し、その時点で表示されていた記録のスナップショットを保存します。出願人への通知を自動送信したり、警告書を自動生成したりしてはいけません。外部へのアクションには現実の法的・評判上の影響が伴うため、権限のある担当者が行うべきです。

公式ソースでの検証が中心となる操作

すべてのリマインダーには、公式ドメイン、出願番号、今回の確認時刻、該当する案件記録への直接リンクを表示します。メールに緊急の支払いボタンを設けてはいけません。手数料、代理人の変更、出願手続きが関わる場合は、保存済みの公式チャネルまたは法務チャネルを通じて、ユーザー自身で確認するよう促してください。

このプロダクトは、公開されているものの機微な連絡先情報も扱います。監視に必要なフィールドのみを収集し、出願人の住所、メールアドレス、電話番号を不要なマーケティングシステムにコピーしないようにします。ブランド戦略の担当者が個人の連絡先をすべて閲覧する必要があるとは限らず、データのエクスポートには監査ログを残すべきです。

商標の変化を競合のページ、採用、製品リリースと組み合わせる場合は、当サイトの競合インテリジェンスプロダクトの方法論（https://everyinfra.com/blog/competitive-intelligence-data-product）を参照してください。種類の異なるエビデンスは、それぞれ独立した情報として扱う必要があります。ある区分の商標を出願したというだけで、競合が製品をローンチした、資金調達した、市場に参入したと推論することはできません。

MVPはまず自社案件に絞る

初版では、チームが既存のUSPTOの出願番号をまとめてインポートし、日次チェック、ステータスと書類の差分、アクションアイテム候補の確認、担当者の割り当て、公式リンクまでを完結できるようにします。類似出願の監視、複数法域の集約、書類の意味解析は後回しにします。

受け入れテストでは、過去の案件履歴をリプレイして、新しい書類によってリマインダーが1回だけ生成されるか、書類より遅れて反映されるステータス変更が正しく関連付けられるか、ソースが一時的に利用できないときに誤って「変更なし」と判定しないか、候補の期日が確認を経てから正式なカレンダーに登録されるかを確認します。あわせて不審な通知をシミュレートし、ユーザーがプロダクト内から公式記録に戻って確認できることも検証します。

本記事はデータプロダクトの設計の考え方を紹介するものであり、商標や法律に関する助言ではありません。また、EveryInfraが商標監視サービスをリリースしたことを示すものでもありません。商標案件管理プロダクトの信頼性は、弁護士の書面らしく見えることではなく、すべてのステータス、書類、アクションアイテムが公式のエビデンスにリンクし、実際の判断を資格と権限を持つ人に委ねることから生まれます。