顧客の使い方まで特許侵害になる？米国のInduced Infringementでマニュアル・サポートが問題になる場面

株式会社IPリッチのライセンス担当です。米国向けに製品やソフトウェアを販売していると、自社が直接すべての工程を実施していなくても、顧客の使い方によっては米国特許のクレームを満たすことがあります。そのとき問題になるのが、製品マニュアル、FAQ、サンプルコード、導入支援、営業資料などが、顧客による侵害行為を積極的に促したとしてInduced Infringement（誘引侵害）の根拠にされないかという点です。

知財を収益化する側から見れば、競合企業が自ら直接侵害していなくても、顧客に特定の実施方法を勧めているならライセンス交渉の対象になり得ます。反対に製品提供側では、販売資料やサポート運用が思わぬ侵害リスクを高めることがあります。株式会社IPリッチが運営するPatentRevenueは、日本国内特許を無料で登録し、売却・ライセンス募集につなげるサービスです。米国特許そのものは登録対象ではありませんが、海外事業を含む知財戦略では、直接侵害だけでなく顧客行動を介した侵害リスクも評価しておく必要があります。

米国特許法35 U.S.C. §271(b)は、特許侵害を「actively induces」した者を侵害者として責任を負わせる規定です。ただし、顧客が特許に触れる使い方をしただけで、製品メーカーやSaaS提供者が自動的に誘引侵害になるわけではありません。基本的には、顧客側に直接侵害が存在することに加え、被疑侵害者が侵害を認識し、侵害を促す積極的な行為をしたかが重要になります。

2026年6月の米国最高裁Hikma Pharmaceuticals USA Inc. v. Amarin Pharma, Inc.判決は、この「積極的に促したか」という点を改めて明確にしました。単に第三者が資料を侵害の指示として読める可能性があるというだけでは足りず、被告自身が侵害使用を積極的に勧めたと合理的に主張できるかが中心になります。製品マニュアルやウェブサイトの一文だけで機械的に結論を出すのではなく、情報の文脈、対象、内容をまとめて見る必要があります。

Induced Infringementは「顧客が侵害した」だけでは成立しない

まず区別したいのは、直接侵害と誘引侵害です。

35 U.S.C. §271(a)は、米国内で、権限なく特許発明を製造、使用、販売の申出、販売、輸入する行為などを直接侵害として定めています。これに対し§271(b)は、他者による侵害を積極的に誘引した者の責任を定めています。

典型例は、メーカーが装置を販売し、その装置自体は特許クレームの全要素を満たさないものの、顧客がマニュアルどおりに設定・運用すると特許方法クレームを実施するような場面です。SaaSでも、提供会社はサーバー側の一部処理だけを担い、顧客が特定の入力や設定を行ったときにクレーム全体が実施される設計があります。

ここで重要なのは、誘引侵害は独立した抽象的責任ではなく、原則として誰かの直接侵害を前提にすることです。顧客の利用方法がクレームを満たさなければ、説明書に積極的な表現があっても、誘引侵害の土台がありません。

したがってFTOや侵害分析では、最初に「自社製品の構造」だけを見るのではなく、「顧客が実際にどのように使うか」までクレームに当てはめる必要があります。特に方法クレームでは、利用フロー、設定手順、ユーザー操作、API呼出し、サーバー処理の順序などを具体化することが重要です。

必要なのは侵害を促す意図と知識であり、一般的な販売だけでは足りない

米国最高裁はGlobal-Tech Appliances, Inc. v. SEB S.A.で、§271(b)の誘引侵害について、誘引された行為が特許侵害を構成することを知っていることが必要だと示しました。また、実際の知識だけでなく、一定の条件を満たすwillful blindnessが知識要件を満たし得るとしました。

そのため、企業がある特許の存在を知った後も、顧客にその特許を満たす利用方法を積極的に勧め続ける場合は、リスクが高まります。一方で「特許を知っていた」という事実だけで責任が確定するわけではありません。侵害する利用を促す積極的な行為が問題になります。

この区別は実務上非常に重要です。汎用品や多用途ソフトウェアを販売していて、顧客が多くの合法的な方法で利用できる場合、単なる販売行為と、特定の侵害方法を狙って教える行為は分けて評価すべきです。

社内で特許警告を受けた場合も、「特許を知ったからすぐ販売停止」ではなく、クレーム解釈、対象機能、顧客の使用態様、資料の内容を確認します。同時に、営業・技術サポートがどのような利用方法を勧めているかを把握しないまま放置すると、後で積極的誘引の証拠として争われる可能性があります。

2026年のHikma判決が示した「読める」だけでは足りないという線引き

Hikma Pharmaceuticals USA Inc. v. Amarin Pharma, Inc.では、ジェネリック医薬品メーカーHikmaのラベル、ウェブサイト、プレスリリース等が、Amarinの特許された用途を医師に促したかが問題になりました。

米国最高裁は2026年6月、Federal Circuitの判断を覆し、Amarinの主張では誘引侵害を十分に述べていないと判断しました。最高裁が強調したのは、「医師がある記載を侵害への指示と読むことができるか」ではなく、「Hikmaが侵害使用を積極的に奨励したと合理的に主張できるか」という点です。

この判決は医薬品の特殊な規制文脈を含みますが、製品マニュアルやサポート資料を扱う企業にも示唆があります。文章の一部だけを抜き出して「この表現があるから誘引」と決めるのではなく、何を対象に、誰に向け、どの利用を促しているのかという文脈が重要です。

たとえば、製品紹介ページで機能の一般的な性能を説明することと、特許クレームの各工程をたどる具体的な利用手順を示し、その実施を顧客へ推奨することでは、リスク評価が異なります。

同様に、サポート担当者が顧客から「この設定でできますか」と聞かれ、単に技術仕様を答える場合と、侵害する組合せを理解したうえで具体的に設定を指示する場合も、同じではありません。個別事案では資料全体と事実関係を精査する必要があります。

マニュアルは「機能説明」より「具体的な実施手順」が重要になる

企業が最初に点検しやすいのは製品マニュアルです。

マニュアルに、クレームの各ステップと対応する操作が順番どおり記載され、「この設定を行ってください」と具体的に勧めている場合、顧客の直接侵害を裏付ける資料であると同時に、提供者による誘引の証拠としても主張される可能性があります。

一方で、マニュアルが複数の利用方法を中立的に説明し、そのうち一つを顧客が独自に選んだという事情なら、分析は異なります。重要なのは、単に製品にその能力があるかではなく、提供者が何を推奨したかです。

実務では、FTO調査で問題になったクレームについて、製品機能だけでなく、公開マニュアル、オンラインヘルプ、FAQ、チュートリアル、動画、サンプル構成などを横断して確認すると効果的です。

特に販売後にマニュアルが更新されている場合は、バージョンごとに内容を残しておく必要があります。訴訟では「いつ、どの表現で、どの利用を促していたか」が問題になるため、現在のページだけ見ても過去のリスクを評価できないことがあります。

サンプルコードや設定テンプレートは実際の利用方法へ近い

ソフトウェアやクラウドサービスでは、マニュアル以上にサンプルコードや設定テンプレートが重要になることがあります。

顧客がコピーして利用する前提のサンプルコードが、特許方法クレームのステップをそのまま実行する場合、単なる抽象的説明よりも、実施を具体的に促す性格が強くなり得ます。

APIドキュメントでも同様です。個々のAPI自体が非侵害でも、「API Aを呼び出した後にBを実行し、Cの結果をDへ送る」というチュートリアルがクレームの流れに対応する場合があります。

このため、エンジニア向けのDeveloper Portalを法務レビューの対象外にしないことが重要です。営業資料より技術資料の方が、顧客が実際にどう使うかを詳細に示していることがあります。

新機能公開時には、製品仕様のFTO確認と同時に、公開予定のチュートリアルやサンプルコードも確認する運用にすると、誘引侵害リスクを早く把握できます。

営業・導入支援・カスタマーサクセスの記録も無視できない

誘引侵害の分析は公開資料だけで終わりません。

BtoB製品では、営業担当者が顧客の課題を聞き、個別の利用方法を提案することがあります。導入支援チームが設定を代行し、カスタマーサクセス担当が利用率向上のため特定機能の組合せを提案することもあります。

こうしたやり取りが、特許を満たす利用方法を顧客に具体的に勧める内容なら、後に争点となる可能性があります。

逆に、企業側が侵害回避設計を行い、サポート担当にも「この構成は提供しない」「この設定は推奨しない」と明確に共有している場合は、実際の運用と資料が整合しているか確認できます。

重要なのは、法務部門だけが特許リスクを知り、顧客対応部門が従来どおり侵害利用を勧め続ける状態を避けることです。特許警告を受けた後は、対象特許と製品機能の分析結果を、必要な範囲で営業・サポートへ反映する必要があります。

「非侵害用途がある」だけで誘引リスクが消えるわけではない

製品に多くの非侵害用途がある場合、企業は「他の使い方もできるから問題ない」と考えがちです。

確かに、複数用途があることは重要な事情です。しかし§271(b)で焦点になるのは、企業が侵害する特定用途を積極的に促したかです。非侵害用途があるとしても、侵害用途を狙って具体的に勧めているなら、それだけで安全とは言えません。

一方、寄与侵害を定める§271(c)では、特に作られた部品か、実質的な非侵害用途を持つ汎用品かといった論点が条文上重要です。誘引侵害と寄与侵害は要件が異なるため、「汎用品だから§271(b)も問題ない」と混同しないことが必要です。

製品が多用途である場合は、利用用途を分類し、どの用途をマーケティング上の主目的としているか、どの用途をサポート資料で強く推奨しているかを確認します。

FTOでは製品クレームチャートと顧客利用チャートを分ける

誘引侵害を見落とさないためには、通常の製品クレームチャートだけでなく、顧客利用を前提にしたチャートを作ると整理しやすくなります。

まず、自社が単独で実施している要素を特定します。次に、顧客が行う要素を特定します。そのうえで、顧客側の行為が誰の管理下で、どの資料やサポートによって行われているかを確認します。

方法クレームでは、すべてのステップが一主体によって行われるのか、複数主体に分かれるのかも別の侵害論点になります。誘引侵害の検討だけで済ませず、直接侵害の成立構造を最初に確認することが重要です。

また、米国外の顧客行為については、米国特許の属地主義との関係を確認する必要があります。「世界中の利用が同じように米国特許侵害になる」と考えるのは適切ではありません。米国内の製造、使用、販売等と、国外での行為を区別して分析します。

特許を知った後は、文書の一斉削除ではなく運用を整える

特許警告状を受けた企業がやってはいけないのは、慌てて関連資料を削除し、過去の記録を失わせることです。

まず、関係資料を適切に保存し、法務・知財担当と外部専門家の指示のもとで事実を把握します。そのうえで、今後のマニュアル、FAQ、サンプルコード、営業提案、サポート回答を見直します。

見直しの目的は、「特許に触れないよう何も説明しない」ことではありません。侵害分析の結果に基づき、危険な利用方法を推奨しないようにしつつ、顧客が必要とする合法的な利用方法は明確に案内することです。

また、設計変更で非侵害構成へ移せる場合は、製品だけでなくドキュメントも同時に更新します。製品は変更したのに古いマニュアルが残り、顧客へ旧方式を勧め続けている状態は避けるべきです。

ライセンス交渉では顧客資料が「実施の証拠」になり得る

権利者側から見れば、被疑侵害企業の公開資料は、ライセンス候補を評価する重要な情報です。

製品仕様書だけではクレーム充足を判断しにくい場合でも、導入ガイドやFAQに顧客利用の具体的な流れが書かれていることがあります。動画デモやサンプルコードから、実際に推奨されている方法が分かる場合もあります。

ただし、公開資料を見つけたからといって即座に「誘引侵害が確定した」と扱うべきではありません。顧客による直接侵害、被疑侵害者の知識、積極的誘引の各要素を分けて確認します。

ライセンス交渉でクレームチャートを作る際も、「製品が要素を備える」という記載と、「顧客がこの操作を行う」「企業がこの操作を推奨している」という記載を分けると、議論が整理しやすくなります。

実務では「誰が、何を、どう勧めているか」を棚卸しする

米国のInduced Infringementを管理するうえで、最初に確認すべきなのは、製品名や特許番号だけではありません。

まず、顧客がどのような使い方をすると対象クレームを満たす可能性があるかを具体化します。次に、その使い方を自社がどの資料や場面で推奨しているかを確認します。マニュアル、FAQ、チュートリアル、サンプルコード、営業資料、導入支援、カスタマーサクセス、個別メールまで対象になり得ます。

そのうえで、特許の存在をいつ知ったか、知った後にどのような分析と対応をしたかを記録します。リスクがある場合は、設計変更、資料修正、サポート方針の変更、ライセンス交渉などを比較します。

2026年のHikma判決が示したように、第三者が文章を侵害指示として読む可能性があるだけで、直ちに積極的誘引が成立するわけではありません。しかし企業側が侵害用途を狙って具体的に促している事実があれば、問題は大きくなります。

FTOの対象を製品仕様だけに限定せず、「顧客に何をさせているか」まで確認することが、米国向け事業の実務的なリスク管理になります。知財を収益化する側でも、相手企業の顧客向け資料を読み解くことで、直接侵害だけでは見えないライセンス機会を発見できる可能性があります。

（この記事はAIを用いて作成しています。）