ビジネスの主戦場がパッケージソフトからSaaS（Software as a Service）へと移行して久しい現在、多くのスタートアップがサブスクリプションモデルによる事業拡大を目指しています。しかし、SaaSはその技術的特性上、「特許の取り方が非常に難しく、失敗しやすい」ということは意外と知られていません。
「画期的なアルゴリズムを開発したのに、特許侵害で競合を訴えられなかった」
「サーバーを海外に移されただけで、特許権が効かなくなった」
このような事態を防ぐためには、SaaS特有のアーキテクチャである「サーバー」と「クライアント」の関係性を法的にどう定義するか、高度な戦略が求められます。
特に、2025年（令和7年）3月のドワンゴ対FC2事件・最高裁判決により、SaaSの特許実務は劇的な転換点を迎えました。この判決を知らずに古い知識のまま出願するのは、あまりに危険です。
本記事では、IT・ソフトウェア分野に強い弁理士の視点から、SaaSビジネスにおける特許戦略の核心、そして最新判例を踏まえた「勝てる権利化」のノウハウを徹底解説します。
従来の製造業の特許（例えば「エンジン」や「椅子」）は、その物が一つ存在すれば完結していました。しかし、SaaSを含む「ネットワーク型システム」の発明は、物理的に離れた複数の要素が連携して初めて機能します。
ここで最大の問題となるのが、特許法における「多主体（マルチアクター）の壁」です。
特許権侵害を成立させるためには、原則として「一つの主体（競合他社）」が「特許請求の範囲（クレーム）に記載されたすべての構成要件」を実施している必要があります。
もし、あなたが「サーバーとクライアント端末からなるチャットシステム」として、何も考えずにシステム全体を特許にしてしまった場合、どうなるでしょうか？
・サーバーを管理しているのは「競合他社（SaaSベンダー）」です。
・クライアント端末を操作しているのは「一般ユーザー（顧客）」です。
この場合、競合他社は「私はクライアント端末を操作していません（ユーザーが勝手にやっています）。システム全体のうち半分しか実施していないので、特許侵害ではありません」と反論し、侵害が成立しないリスクがあります。
これを防ぐには、発明を適切に切り分け、誰が何を実施しているかを明確にした「クレーム設計」が必須となります。
SaaSの特許において最も重要なのは、「発明をどの視点で切り取るか」です。同じ技術であっても、以下の3つのカテゴリーで重層的に権利化することで、逃げ場のない強力な特許網を構築できます。
SaaSベンダー（競合他社）を直接叩くための権利です。発明の構成要素を「サーバーが行う処理」のみに限定して記述します。
・悪い例（多主体）：
「ユーザーが端末からリクエストを送信し、サーバーがそれを受信して処理し、結果をユーザー端末に表示させるシステム。」
（※「表示させる」というユーザー側の動作が含まれてしまっています）
・良い例（シングル主体）：
「端末からのリクエストを受信する受信部と、当該リクエストに基づき処理を行う制御部と、表示用データを前記端末に送信する送信部とを備えるサーバー装置。」
このように主語を「サーバー」に統一すれば、ユーザーが何をしていても、競合他社がそのサーバーを稼働させた時点で侵害（生産・使用等）を問うことができます。SaaS特許においては、これが最も基本かつ強力な権利となります。
専用アプリや、ブラウザ上で動作するJavaScriptの処理に特徴がある場合に有効です。
ここでは、「プログラム」そのものを権利化します。
Apple StoreやGoogle Playでアプリを配信している競合他社を排除したい場合、「サーバーの特許」だけではプラットフォーマーへの説明が難しく、削除対応が遅れることがあります。しかし、「アプリの特許」を持っていれば、配信されているアプリ自体が侵害品であるとシンプルに主張でき、ストアからの削除要請（テイクダウン）をスムーズに進められます。
かつては「多主体侵害のリスクがある」として敬遠されがちだった「システム全体（サーバー＋端末）」のクレームですが、後述する最新判決により、その重要性が再評価されています。
特に、サーバーとクライアントが密接に連携し、その相互作用（プロトコルや通信シーケンス）にこそ発明の本質がある場合、システムクレームは非常に有効です。
SaaSビジネスで長年最大の懸念事項だったのが、「サーバーの海外設置（クロスボーダー）」問題です。
日本の特許権は「属地主義」といって、日本国内でしか効力を持ちません。そのため、「AWSのリージョンを米国にしているから、日本の特許権は及ばない」という「特許逃れ」がまかり通る恐れがありました。
この論点に完全な決着をつけたのが、2025年3月3日に下された「ドワンゴ対FC2事件」の最高裁判決です。
最高裁は、サーバーが国外にあっても、以下の要素を総合考慮し、システムを作り出す行為が「実質的に日本国内で行われたと評価できる」場合は、日本の特許権侵害（生産）に当たると判断しました。
譲渡等の行為の態様： 日本国内のユーザー向けにサービスが提供されているか（日本語表示、日本円決済など）。
効果の発生場所： そのシステム利用による効果が日本国内で発現しているか（国内ユーザーが利用できているか）。
この画期的な判決により、SaaS事業者は「サーバーを海外に逃がす」という単純な回避策が通用しなくなりました。
逆に言えば、日本でしっかり特許を取得しておけば、海外サーバーを用いた模倣サービスに対しても、差止や損害賠償を請求できることが最高裁レベルで確定したのです。
この判決以降、あえて「サーバーと端末を含むシステム」として特許を取得し、「日本国内のユーザー（端末）を含んでいるのだから、国内での実施である」と主張する戦略が、極めて有効な選択肢となっています。
どれほど素晴らしい特許を取っても、競合他社のサービスがその特許を使っていることを立証できなければ（バレなければ）意味がありません。これを「侵害発見性（Detectability）」と言います。
SaaSのバックエンド処理（AIのアルゴリズムや高速計算ロジック）はブラックボックスです。サーバーの中でどのような計算が行われているか、外部からは見えません。
そのため、私はクライアント企業のSaaS特許を担当する際、必ず以下の視点を盛り込みます。
内部ロジックそのものではなく、「特定の入力に対して、どのような出力が返ってくるか」という因果関係を含めてクレームを構成します。
× 内部処理のみのクレーム：
「データＡに対し、アルゴリズムＸを用いて係数計算を行い、メモリＢに格納する処理。」
（※外部からは絶対に見えないため、侵害の証拠が掴めない）
○ 入出力に着目したクレーム：
「端末からデータＡを受信したことに応答して、特定のパラメータを含むデータＢを生成し、これを端末へ返信する処理。」
このように書いておけば、競合他社のAPIを叩いてレスポンス（JSONデータ等）を確認するだけで、「ほら、このパラメータが返ってきている。特許侵害だ」と証拠を突きつけることができます。
「強い特許」とは、技術的に高度なだけでなく、「侵害を見つけやすい特許」のことです。
SaaSビジネスはスピードが命です。開発フェーズに合わせて、適切なタイミングで特許出願を行う必要があります。
ここが最大の勝負所です。
特許には「新規性」が必要です。ベータ版であっても、一度世の中に公開してしまえば、原則として特許は取れなくなります（新規性の喪失）。
必ず、「プレスリリース」や「LP公開」の前に出願を完了させてください。この段階では、詳細なコードよりも「ビジネスモデル×技術」の基本概念を押さえます。
ユーザーが増え、機能追加が進む時期です。ここでは「他社との差別化要因」となる具体的なUI/UXや、データ構造、API仕様の権利化を進めます。
特に、将来的なIPO（新規上場）やM&Aを見据えた場合、特許ポートフォリオは企業の評価額（バリュエーション）を大きく押し上げる資産となります。投資家や買収企業は、技術そのものだけでなく、「その技術を独占できる権利」にお金を払うからです。
SaaSビジネスの特許は、以下の3つの要素を深く理解していないと、穴だらけの権利になってしまいます。
ネットワーク技術（HTTP、API、WebSocket、クラウドインフラ）
最新の法的ロジック（ドワンゴ最高裁判決、多主体実施、間接侵害）
ビジネスモデル（マネタイズポイント、競合の参入経路）
単に「エンジニアから聞いた仕様を文章にする」だけでは、SaaSの特許は守れません。
エンジニアと対等に技術用語で会話ができ、サーバー・クライアント間の見えない処理を「権利」という形に可視化できる専門家のサポートが不可欠です。
当事務所では、SaaS/クラウドビジネスに特化した特許支援を行っています。
「自社のサービスが特許になるかわからない」「競合にマネされないか不安だ」という方は、開発が完了してしまう前にお早めにご相談ください。
SaaSの技術は、コードを書いた瞬間から資産になります。その資産を「独占権」に変えるのが、私たちの仕事です。
#SaaS #特許戦略 #ソフトウェア特許 #ビジネスモデル特許 #スタートアップ #弁理士 #サーバークライアントシステム #ドワンゴ判決 #クロスボーダー #API #UIUX #侵害立証 #知財戦略 #クラウドサービス #特許出願 #IT特許