要約

  • 個人提案であるAPM草案の第05版は、米国で出願中とされる二件の特許出願とRAND条件になり得るライセンス方針をIPR節に記した。これは草案中の主張であり、BTW Mediaによる権利の有効性や帰属の認定ではない。
  • 注記はDatatrackerの正式なIPR開示を権威ある記録とする。しかし2026年9月13日の調査時点で、草案名を指定した公式APIの関係レコードはゼロだった。別識別子、提出中の案件、反映遅延まで否定する結果ではない。
  • Daniel Kadeは、固定した技術版と更新可能な正式開示を結ぶ「二記録型の実装権利台帳」を提案する。これは編集上の提案で、IETFの要件ではない。

実装者が保存すべきものは一枚のコピーではない

第05版の本文を保存すれば、その時点の著者の説明は残る。新設された「IPR Considerations」は、記載技術の一部が米国で係属中の二件の特許出願により保護されている、または保護され得ると述べ、所有者としてSanctum SecOps LLC、発明者としてBrian Vicenteを挙げる。

さらに、別途の書面契約により、非独占かつ世界的なライセンスを合理的・非差別的な条件で提供する用意があり、合理的な料金やロイヤルティーを含み得るとする。ただし対象を「Necessary Patent Claims」に絞り、任意機能、独自拡張、非準拠実装、無関係な製品、ホスト型コントロールプレーン、マネージドサービス、営業秘密、文書範囲外のクレームを除外する。相互主義、防御的停止、救済条項もあり得る。草案の公開だけで特許ライセンスが付与されるわけではない。

ここから権利の実体を断定してはならない。出願番号は注記に公開されず、BTW Mediaは出願の有無、所有権、有効性、範囲、必須性、侵害、執行可能性を独自に判定していない。正確な報道は「第05版がそう記した」にとどまる。

問題は、その注記自身がIETF Datatrackerに提出されるIPR開示を「controlling and authoritative」としている点だ。調査締切時に、当該文書名で絞った公式iprdocrel APIはHTTP 200を返したものの、total_countは0、オブジェクト一覧は空だった。

これは関係データベースの一時点の観測でしかない。別の文書識別子に紐付く開示、提出処理中の記録、Datatrackerの反映遅れを排除しない。また、誰かが手続に違反したという結論でもない。

BCP 79は更新可能な経路を用意している

IETFのIPRプロセス案内と提出手順は、正式な開示経路を示す。BCP 79であるRFC 8179は、IPR情報とライセンス宣言の提出、更新、撤回を扱い、信頼や宣言の扱いに関する規定も置く。同時に、具体的なIPR情報やライセンス条件をRFCやIETF Contributionの本文に置かず、オンラインの開示ページを参照する考え方を示している。

したがって、草案のIPR節と正式開示は競合するコピーではない。前者は版に固定された著者の発言、後者は提出者の権限や識別子、ライセンス宣言の変化を追う制度上の記録である。第05版の段落だけを社内表に転記すると、後日更新される側の履歴を失う。

正式開示が現れても、IETFが特許を認定したことにはならない。IETFは主張された権利の有効性や範囲を判断せず、提示条件がRANDを満たすかも決めない。逆に、現在のゼロ件をBCP 79違反の証拠にすることもできない。適用関係や提出時期の判断には、観測できたデータを超える事実が要る。

技術の具体性と制度上の地位は別々に測る

Datatrackerの文書ページでは、第05版の登録時刻は2026年9月13日05:37:48 UTCである。履歴とAPIレコードは、有効な個人Internet-Draftで、streamも担当Area Directorもなく、Datatracker上の正式な想定RFCステータスもないことを示す。本文の「Intended status: Standards Track」は著者の希望であり、ワーキンググループ採択、IESG承認、RFC化を意味しない。ランニングヘッダーが「Network Working Group」から「Web Authorization Protocol」へ変わったことも、採択の証拠にはならない。

APMの仕組みは、特権リクエストごとにクライアント証明書またはDPoPに結び付く鍵、アクセストークン、完全性を保護した端末姿勢を照合する。判断は全面許可、スコープ縮小、メソッド制限、全面拒否のいずれかになり得る。姿勢悪化をどの結果へ写像するかは実装依存である。スコープ縮小は追加の執行であって、元のトークンを書き換えたり失効させたりしない。

OAuth mTLS、DPoP、Rich Authorization Requests、認可サーバー発行者識別は周辺機構を提供するRFCである。しかし、その地位はAPMへ移らず、特定実装と特許クレームの関係も答えない。

第05版は、実験的なGo実装が法務担当への引き渡し完了まで非公開であるとの注記も残す。提案中のauthorization_detailsタイプは未割当だ。開発状況を知る手掛かりではあるが、相互運用や登録完了の証拠ではない。

二つの履歴を上書きせず結ぶ

Daniel Kadeが提案する二記録型の実装権利台帳では、まず技術レコードに文書名、版、時刻、本文・XMLのハッシュ、プロセス上の地位、関連節、対象機構、実装状態を固定する。権利レコードにはDatatracker開示ID、提出者と権限、特許・出願番号または非公開状態、記載上の権利者、ライセンス約束、除外、相互主義、防御的停止、更新、撤回を保持する。

両者をつなぐ行には、影響し得る技術節、代替方式、法務レビュー、社内責任者、試作・調達・採用の判断、確信度、未解決事項、再審査の条件を置く。「未接続」は「権利なし」とは別の正式な状態でなければならない。後日の更新で、過去の判断根拠を消してもいけない。

Heng LuのPolicy Mirrorは、公開された証拠と判断主体を同じ欄に押し込めない考え方を示す。Minimum Initial Specificationは共通部分を小さくし、将来の判断を各現場に残す。Why BTW Media Existsが加えるのは報道上の節度だ。変化は伝えるが、空白を確定判定に変えない。

出典

  1. APM Datatracker文書ページ
  2. APM文書履歴
  3. APM Datatracker APIレコード
  4. APM第05版
  5. APM第04版
  6. APM第04版から第05版への差分
  7. APMのDatatracker IPR関係照会
  8. IETF知的財産プロセス
  9. IETF IPR開示手順
  10. RFC 8179：IETF技術の知的財産権
  11. RFC 8705：OAuth 2.0 Mutual-TLS
  12. RFC 9449：OAuth 2.0 DPoP
  13. RFC 9396：OAuth 2.0 Rich Authorization Requests
  14. RFC 9470：OAuth認可サーバー発行者識別
  15. APM第05版XMLソース
  16. The Policy Mirror
  17. Minimum Initial Specification
  18. Why BTW Media Exists