米国意匠特許でアプリ画面・GUIを守る最新実務と知財収益化戦略

株式会社IPリッチのライセンス担当です。SaaSプラットフォームやスマートフォンアプリを開発・提供する企業において、「自社の優れた画面デザインやGUI（グラフィカル・ユーザー・インターフェース）を米国市場でどのように守るべきか」「ソフトウェア上の一時的な画像として、意匠特許の対象外とされてしまうのではないか」といったお悩みを抱えるケースがあります。機能面での差別化が難しくなる中、直感的で洗練されたUI/UXは、ユーザーに選ばれるための重要な競争要素です。本記事では、SaaSやアプリの画面デザインを米国意匠特許で守るための最新の法的枠組みと実務上の留意点について解説します。特に、2026年3月に米国特許商標庁（USPTO）が公表した補足ガイダンスを踏まえ、意匠特許の対象となる条件や、それを事業の強みに変える具体的なライセンス戦略について理解できる内容となっています。

優れたUI/UXは、他社との差別化を図る武器であり、適切に権利化することで「知財収益化」の源泉となる可能性があります。弊社が運営する知財マッチングプラットフォーム「PatentRevenue」では、自社で保有しているものの事業展開の中で十分に活用しきれていない特許や意匠権を、それを必要とする企業へライセンスし、新たな収益の柱とするためのサポートを行っています。プラットフォームへの登録や案件の閲覧はすべて無料でご利用いただけます。知財を活用した多角的なビジネス展開やライセンス収入の獲得にご関心のある方は、ぜひご登録をご検討ください。

結論：米国意匠特許でアプリ画面・GUIは保護を目指せる

結論から申し上げますと、米国の意匠特許制度において、SaaSやアプリの画面デザイン、GUI、および各種アイコンは、適切に開示・請求されることを条件として保護対象となり得ます。従来からコンピュータ画面等に表示されるGUIやアイコンは意匠特許の対象となり得ましたが、「製造物品（article of manufacture）」との関係をどのように図面、タイトル、クレームで示すかが重要な実務上の論点となっていました。

USPTOは2026年3月13日から、コンピュータ生成インターフェースやアイコンについて補足ガイダンスを適用しています。このガイダンスでは、タイトルとクレームが対象となる製造物品を適切に特定している場合、従来求められていたコンピュータやディスプレイパネル等を図面上に実線または破線で描くことを必須としない取扱いが示されました。また、「GUI for display panel」「projected interface for a computer」「virtual reality interface for a computer」などの表現によって、製造物品との関係を示すことができるとされています。もっとも、このガイダンスは実体法そのものを変更するものではなく、新規性、非自明性、記載要件、装飾性など他の特許要件を満たす必要があることに変わりはありません。

米国意匠特許に関する基本知識と特有の要件

米国の特許制度では、発明の機能や構造を主として保護する「実用特許」と、物品の装飾的な外観を保護する「意匠特許」が区別されています。アプリの裏側で動くデータ処理アルゴリズムやシステムアーキテクチャについては実用特許が検討対象となり得る一方、ユーザーの目に触れる画面のレイアウト、アイコンの造形、変化する画像として表現される視覚的な表示態様などは、意匠特許による保護を検討できる領域です。ただし、操作方法や機能そのものを意匠特許が直接独占するわけではありません。

米国意匠特許の根拠となるのは、米国特許法第171条です。同条は、「製造物品のための新規かつ独創的で装飾的な意匠」を対象としています。ここで重要なのが「製造物品」という要件です。抽象的な画像や絵そのものを単独で請求するのではなく、そのデザインが製造物品のための意匠であることが適切に開示・請求されている必要があります。

ソフトウェアのUIについても、技術の発展に伴ってUSPTOの審査実務は変化してきました。2023年の補足ガイダンスではGUIやコンピュータ生成アイコンについて、ディスプレイ等との関係を示すことが重視されていました。2026年の補足ガイダンスでは、この取扱いがさらに柔軟化され、一定の場合にはディスプレイ等の輪郭を図面に描かなくても、タイトルとクレーム等から製造物品との関係を適切に示せることが明確化されています。

また、米国意匠特許には実用特許とは異なる特有のルールがあります。出願実務における重要な注意点の一つは、意匠発明について米国の仮出願を利用できないことです。実用特許では仮出願を利用して早期の出願日を確保する場合がありますが、意匠発明について仮出願を行うことはできません。

また、米国法には発明者由来の一定の開示について1年間のグレースピリオドがありますが、あらゆる第三者開示から保護される制度ではなく、外国での権利取得に影響する可能性もあります。このため、SaaSやアプリのUIを保護する場合には、公開前の出願を基本として検討することが安全です。なお、2015年5月13日以降に出願された米国意匠特許の存続期間は、原則として特許付与日から15年間です。

2026年3月施行のUSPTO補足ガイダンスがもたらす制度の進化

2026年3月13日に発効した補足ガイダンスは、GUIやデジタルアイコンの権利化を目指す企業にとって重要な実務上の変更をもたらしました。背景には、投影画像、ホログラム、VR（仮想現実）、AR（拡張現実）など、従来のディスプレイだけでは捉えきれない新しいインターフェースが増えていることがあります。USPTOは、これらをprojections, holograms, virtual and augmented realityの頭文字から「PHVAR」と表現しています。

第一の大きな変更点は、図面における「ディスプレイパネル」の描画要件の緩和です。従来のMPEPでは、コンピュータ生成インターフェースやアイコンについて、製造物品との関係を示すためにコンピュータやディスプレイパネル等を実線または破線で図面に描くことが求められていました。2026年のガイダンスでは、タイトルとクレームが製造物品を適切に特定している場合、この描画を必須としない取扱いが示されました。これにより、特定のデバイス外形を図面に含めずにインターフェースの外観を示す余地が広がっています。

第二の変更点は、タイトルやクレームにおける言語表現の明確化です。ガイダンスは、「icon for display screen」「GUI for display panel」「projected interface for a computer」「virtual reality interface for a computer」などの表現が、製造物品のための意匠であることを示す例として認められるとしています。したがって、特定のスマートフォン本体等の外形を図面に描かなくても、タイトル、クレーム、明細書、図面を通じて製造物品との関係を適切に開示することが可能です。

第三に、投影画像、ホログラム、VR・ARなどPHVAR領域のデザインについても保護可能性が明確化されました。USPTOは、インターフェースやアイコンの外観がそれを生成するコンピュータ等から空間的に分離していても、そのインターフェース等がコンピュータ、コンピュータディスプレイまたはコンピュータシステムのためのものであり、適切に開示・請求されていれば意匠特許の対象となり得るとしています。スマートグラスや空間コンピューティングなど、従来型ディスプレイ以外の環境で表示されるUIについても、条件を満たせば保護を検討できる範囲が広がったといえます。

SaaS・アプリ事業者のための米国意匠出願の実務

実際の米国出願実務において、SaaSやアプリの事業者が押さえておくべきポイントは多岐にわたります。出願を成功させ、かつ事業上意味のある権利を取得するためには、図面の作成方法、特に「実線」と「破線」の使い分けが重要です。

米国意匠実務では、原則としてクレームする意匠部分を実線で示し、環境や権利を求めない部分などを破線によって示す方法が用いられます。破線は、意匠が使用される環境を示したり、部分的な意匠のクレーム範囲を画定したりするために利用されます。2026年のガイダンスによって一定の場合にはディスプレイの輪郭を描く必要がなくなりましたが、画面内の特定のウィジェットや独自のアイコンだけを保護したい場合には、実線と破線をどのように使うかが依然として重要です。

例えば、SaaSの顧客管理ダッシュボードにおいて、独自のデータ可視化ウィジェットを開発したとします。画面全体をクレーム対象としてしまえば、周辺のナビゲーションバーやメニューなども含めた全体の外観が権利範囲を判断する際の要素となります。競争力の源泉となるグラフィック部分だけを実線で示し、それ以外の環境部分を適切に破線で示すことで、権利範囲を不要に周辺レイアウトへ限定しない出願設計を検討できます。

もっとも、出願後に自由に実線と破線を変更できるわけではありません。意匠特許では図面がクレーム内容を示す極めて重要な要素であり、当初の開示に裏付けのない内容を補正によって追加することは新規事項として認められません。そのため、どこまでをクレーム対象とし、どこを環境として示すかは出願前に慎重に検討する必要があります。

また、国際的な事業展開を見据える場合、ヘーグ協定に基づく国際意匠出願も有力な選択肢です。ヘーグ制度では、一つの国際出願を通じて複数の締約国・地域を指定できます。米国も加盟しているため、米国と他の主要市場で同時期に意匠保護を検討する企業にとって手続上のメリットがあります。ただし、権利の成立や実体的な保護要件は各指定国・地域の法令に従うため、事業展開国と各国の制度を踏まえて直接出願との使い分けを検討する必要があります。

UI・GUIデザインの技術ライセンス契約における重要条項

権利化された優れたUIデザインは、単に自社のアプリを模倣から守るための防具にとどまらず、他社へライセンスを供与することで収益を生み出す資産となる可能性があります。米国においてGUIの意匠特許を対象としたライセンス契約を締結する際、実務上特に確認すべき条項について解説します。

第一に、独占的ライセンスと非独占的ライセンスを含む許諾範囲の定義です。SaaSのGUIライセンスでは、業界や適用分野を限定してライセンスする方法も考えられます。例えば、自社が開発したデータ可視化ダッシュボードの意匠特許を医療分野では特定企業に独占的に許諾し、金融分野では別の企業に許諾するといったfield-of-useの設計です。自社事業との競合関係や既存ライセンスとの整合性を確認しながら契約範囲を設計することが重要です。

第二に「ロイヤルティ」の算出方式です。SaaSやアプリの場合、ダウンロード数、月間アクティブユーザー数、対象UIが実装された有料プランの売上など、事業モデルに即した指標を利用することが考えられます。特にSaaSでは複数の料金プランが存在することが多いため、どの商品、サービス、プラン、地域、顧客がロイヤルティ計算の対象となるのかを明確に定義しておく必要があります。

第三に、交渉段階におけるNDA（秘密保持契約）です。米国には発明者由来の一定の開示について1年間のグレースピリオドがありますが、すべての公開リスクを解消するものではなく、米国外での意匠権取得にも影響する可能性があります。リリース前の新しいアプリ画面やプロトタイプをライセンス候補先に開示する場合には、秘密保持義務や目的外使用禁止を契約で定めておくことが実務上重要です。

第四に、ライセンス交渉における視覚的な対比資料の活用です。自社の意匠特許の図面と、相手方のアプリ画面や採用予定のデザインを並べ、全体的な外観、主要な視覚的特徴、先行意匠との差異などを比較できる資料を用意することで、権利範囲について具体的な議論ができます。ただし、実用特許のように構成要件を一つずつ機械的に対応させるだけでは不十分であり、意匠特許の侵害判断では先行意匠を踏まえた全体的な視覚的印象が重要になります。

第五に「監査条項」の設定です。アプリのダウンロード数やSaaSのユーザー登録数、売上データはライセンシー側で管理される場合が多いため、ロイヤルティ計算の根拠となるデータをどのように確認できるかを契約で定めておくことが重要です。一定の条件のもとで独立した会計専門家等による確認を可能とする監査条項は、ライセンス収益を適切に管理する手段となります。

意匠特許の侵害リスク評価と損害賠償のメカニズム

万が一、自社のアプリ画面が米国市場で模倣された場合、あるいは他社から侵害警告を受けた場合のリスク評価と損害賠償の仕組みを理解しておくことは、法務・知財担当者にとって重要です。

米国意匠特許の侵害判断の基礎となっているのが、1872年のGorham Co. v. White事件で示された「通常観察者（ordinary observer）」の考え方です。その後、Federal Circuitは2008年のEgyptian Goddess v. Swisa判決において、従来併用されていた「point of novelty」テストを独立したテストとして用いることを否定し、通常観察者テストを中心とする判断枠組みを示しました。特に類似性が接近している事案では、通常観察者が先行意匠を認識した状態で、クレームされた意匠と被疑侵害意匠の全体的な視覚的印象をどのように受け取るかが重要になります。

したがって、アプリの機能や操作感が似ているだけで意匠特許侵害になるわけではありません。一方、個々の細かな違いが存在するから直ちに非侵害になるとも限りません。意匠特許の図面でクレームされた外観、先行意匠との距離、被疑侵害デザインとの全体的な視覚的印象を総合的に検討する必要があります。

さらに、米国意匠特許には米国特許法第289条という特徴的な救済規定があります。同条は、意匠特許を侵害するデザインを製造物品に適用して販売等を行った者について、一定の場合にその「article of manufacture」に係る総利益を権利者が回収できる旨を定めています。この制度は通常の損害賠償とは異なる重要な救済手段ですが、最終製品全体の利益が常に返還対象となるわけではありません。

この点について重要なのがSamsung Electronics Co. v. Apple Inc.事件です。米国連邦最高裁判所は2016年、複数の構成部分からなる製品の場合、第289条上の「article of manufacture」は消費者に販売される最終製品全体に限定されず、その構成部分となる場合もあると判示しました。一方、最高裁はSamsung事件において、問題となった各意匠特許についてスマートフォン全体と個別の構成部分のどちらが「article of manufacture」に当たるのかを決定せず、その具体的な判断基準も示していません。

このため、SaaSやアプリのGUIに関する意匠特許についても、「GUIが実装されたソフトウェア部分」や「画面」が当然に第289条上のarticle of manufactureとなり、そのサービス全体のサブスクリプション利益が返還されると考えることはできません。どの対象がarticle of manufactureとなるのか、その対象から生じた総利益をどのように算定するのかは、個別の製品・サービス構成や証拠に基づいて検討する必要があります。もっとも、権利範囲と侵害対象を整理し、事業への経済的影響を把握しておくことは、訴訟だけでなくライセンス交渉においても重要です。

優れたUI/UXを起点とした知財収益化の戦略

ここまで見てきたように、2026年のUSPTO補足ガイダンスによって、米国におけるGUI・アイコンの意匠出願では、図面やタイトル、クレームに関する審査上の柔軟性が高まり、投影画像やVR・ARを含む新しいデジタルデザインについても保護可能性が明確化されました。一方、新規性、非自明性、装飾性、記載要件など、意匠特許としての基本的な要件が緩和されたわけではありません。

知財収益化を検討する場合、まず自社サービスの中でユーザーから高く評価され、競争力に結びついているインターフェースを特定するところから始めます。例えば、スワイプ操作に伴って特徴的に変化する表示デザイン、複雑な財務データを直感的に表示するクラウド会計ソフトのグラフ可視化UI、あるいはECサイトにおける特徴的なチェックアウト画面の表示デザインなどは、意匠としての保護可能性を検討する対象となり得ます。

これらについて米国意匠特許としてポートフォリオを構築し、自社コア事業の防衛に利用するとともに、競合関係にならない分野へのライセンスを検討することもできます。例えば、自社が開発した空間コンピューティング向けの特徴的な3Dオブジェクト管理UIについて、自社事業では独占的に利用しつつ、別の用途や業界について第三者へのライセンスを検討するという考え方です。

ただし、優れたUIが存在するからといって、そのまま広い意匠特許が成立したり、直ちに高額なライセンス収益を得られたりするわけではありません。権利化する外観の範囲、先行意匠との差異、第三者が実際に利用する可能性、回避設計の容易さ、市場規模などを踏まえ、出願費用と事業上の価値を比較して判断する必要があります。

UIデザインを事業価値につなげるために

デジタル経済において、SaaSやアプリの洗練された画面デザインは、サービスの競争力を構成する重要な要素です。2026年のUSPTO補足ガイダンスによって、コンピュータ生成インターフェースやアイコンについて製造物品との関係をどのように開示・請求するかが明確化され、従来型ディスプレイに限らない投影画像やVR・ARのインターフェースについても保護を検討しやすくなりました。ただし、これは意匠特許の基本的な法的要件を撤廃するものではなく、適切なタイトル、クレーム、図面その他の開示によって権利範囲を設計する必要があります。

企業が取るべき次の行動として、まずは自社が現在開発を進めている、あるいは既に市場に投入しているソフトウェアのUI/UXの中に、他社に容易に模倣されたくない特徴的な画面デザインが存在しないか、法務・知財部門と開発・デザイン部門が連携して棚卸しを行うことが考えられます。その上で、米国をはじめとする主要市場での意匠出願を検討し、取得した権利を防衛だけでなく、ビジネス上の交渉材料やアライアンス、ライセンス収益につなげられるかを検討することが重要です。

もし、自社で取得したものの十分に活用できていない特許や意匠権、あるいは他社へのライセンスを通じて新たな事業価値を創出できる可能性のある知財がございましたら、「PatentRevenue」の活用をご検討ください。休眠している知財アセットを、それを必要とするパートナーと結びつけることで、UIデザインを含む知財が新たな収益機会につながる可能性があります。自社の独創的なデザインを適切な権利で保護すると同時に、事業価値につなげる視点を持つことが重要です。

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