ソフトウェア特許におけるクレームの種類

ソフトウェア関連発明を特許出願する際、どの種類のクレームを書くかは、その後の権利行使や収益化に直結する重要な論点となる。

とりわけ「システムクレーム」「プログラムクレーム」「方法クレーム」は、同一の発明内容であっても、権利の及ぶ範囲や侵害主張のしやすさ、実施料算定の考え方に大きな違いが生じる。

本記事では、ソフトウェア特許において典型的に用いられるこれら3種類のクレームについて、それぞれの特徴と利点・留意点を整理する。

システムクレーム

システムクレーム(装置クレーム)は、ソフトウェアを含む装置全体を特定するクレームであり、完成品としての装置に対して侵害主張が可能となる。

最大の利点は、侵害対象を「装置全体」として捉えられる点にある。

プログラムクレームと比較すると、対象製品における特許発明の占める部分、いわゆるパテンテッドポーションを大きく評価しやすく、その結果、ライセンス料や損害賠償額を高く主張できる余地が生じる。

また、プログラムがハードウェアに実装されている場合であっても、システムクレームであれば問題なくカバーできる。

さらに、プログラム搭載装置の「使用者」に対して権利行使を行いたい場合にも、システムクレームは有効な選択肢となる。

このように、製品ビジネスを前提とする場合や、装置メーカー・ユーザー双方への権利行使を視野に入れる場合には、システムクレームは非常に強力な武器となる。

プログラムクレーム

プログラムクレームは、コンピュータプログラムそれ自体を発明の対象として特定するクレームである。

このクレームの強みは、カバー範囲の広さにある。

CDやDVDなどの記録媒体による配布、ソフトウェアのダウンロード、サーバーからの配信、さらにはスタンドアローン型のソフトウェアまで、様々な流通形態を一括して捉えることができる。

原則として、プログラムクレームがあれば、記録媒体クレームを別途設ける必要はないと考えられる。

ただし、国ごとの制度差には注意が必要である。

例えば米国では、いわゆる「プログラムクレーム」は認められておらず、代替として記録媒体クレーム(computer-readable medium claim)に置き換える必要がある。

その際、単に記録媒体という記載だけだと一時的な伝搬信号それ自体(transitory propagating signals per se)であると解釈され、米国特許法第101条の規定により拒絶される可能性があるため、クレームでは「非一時的な有形の記録媒体(non-transitory tangible medium)」と規定する必要がある。

また、欧州特許出願では、原則として1つのカテゴリー(物、方法、使用)について1つの独立クレームしか認められない。

ここで、物のカテゴリーには装置、システム、プログラムが含まれるので、プログラムの独立クレームを規定した場合は装置クレームやシステムクレームの独立クレームを規定することができない。

欧州の審査ガイドラインにはコンピュータプログラムそれ自体は特許可能な発明から除外されるが、更なる技術的効果が得られるコンピュータプログラムは特許可能な発明であると規定されている。

つまり、プログラムのクレームについては特許可能な発明から除外される可能性もあるということなので、安全を取るなら装置クレームと方法クレームの2つの独立クレームを選択するのが良い。

なお、中国では従来、プログラムクレームは認められていなかったが、改正された「専利審査指南」が2024年1月20日から施行され、コンピュータプログラム製品を対象とする請求項が認められるようになった。

方法クレーム

方法クレームは、発明の「実行行為」そのものを特定するクレームである。複数のデバイスにまたがって処理が行われる場合であっても、一連の方法としてクレームできる点は特徴的である。

一方で、方法クレームによる権利行使には難しさも多い。

ソフトウェア関連発明では、実施行為が個人的使用に留まるケースが少なくない。

また、実施者が多数存在する場合、それぞれが「業として」実施していることを立証する必要があり、実務上の負担は大きい。

その割に、侵害に対する対価として得られる収入は限定的になりがちである。

そして、方法でしかカバーできない発明は殆ど存在しないと考えられる。

このような事情から、一般論としてはクレーム作成の優先度は低く位置づけられることが多い。

もっとも、例外もある。

サービス事業者による発明の実施が明確に想定される場合には、サービスに用いられるサーバー装置をクレームするよりも、そのサービス内容に対応する方法クレームの方が、サービス収益を基礎として実施料を算定しやすい場合がある。

このようなケースでは、戦略的に方法クレームを用意しておく意義は大きい。

おわりに

ソフトウェア特許におけるクレーム設計は、単なる権利取得の問題に留まらず、その後のビジネスモデルや権利行使戦略と密接に結びついている。

システムクレーム、プログラムクレーム、方法クレームにはそれぞれ明確な役割と強みがあり、どれか一つが常に正解というわけではない。

想定される実施形態、侵害主体、収益源を踏まえた上で、複数のクレームタイプを適切に組み合わせることが、ソフトウェア特許の価値を最大化する鍵となる。

一般的には、システムクレーム≒プログラムクレーム>方法クレームの優先度となると考えられるが、プログラムがインストールされた装置を販売する可能性が低ければ、システムクレームの優先度は多少下がるかと思われる。

関連記事