1. 事案の概要（事実経過・請求内容）
原告（Ｓ．ＲＩＤＥ株式会社）は、発明の名称を「情報処理装置および方法、並びにプログラム」とする特許権（特許第5527045号。以下「本件特許権」、請求項9に係る発明を「本件発明」という）を有する特許権者である。
原告は、被告（ＧＯ株式会社）が提供するスマートフォン向けタクシー配車アプリケーション「GO タクシーが呼べるアプリ」（以下「被告プログラム」）が本件発明の技術的範囲（構成要件A〜D）に属し、被告による被告プログラムの作成・使用・譲渡等の行為が本件特許権を侵害していると主張した。
これに基づき、原告は被告に対し、特許法100条1項に基づく被告プログラムの作成・使用・譲渡等の差止め、および同条2項に基づく被告プログラムの抹消を求めて本訴を提起した。
2. 判決の主文
１ 原告の請求をいずれも棄却する。
２ 訴訟費用は原告の負担とする。
3. 主な争点
- 争点1：被告プログラムの本件発明の技術的範囲への属否（侵害論）
- 争点1-1（構成要件Aの充足性）：被告プログラムにおける「ｄ払い」決済機能の登録・連携が、構成要件Aの「前記アプリケーションで提供されるサービス」および「前記アプリケーションの処理により前記サービスを登録し」等に該当するか。
- 争点1-2（構成要件AないしDの充足性）：登録・生成・更新の各ステップが一連の処理として実行されているといえるか。
- 争点2：本件特許の無効の抗弁の成否（特許法104条の3）
- 乙8文献、乙11文献、乙9製品、乙14公報、乙15公報、乙16公報に基づく新規性・進歩性欠如、およびサポート要件違反（特許法36条6項1号）。
4. 裁判所の判断ロジック（判示の要旨）
裁判所は、被告プログラムが構成要件Aを充足しないと判断し、その余の争点（争点1-2、争点2の無効の抗弁）について判断することなく、原告の請求を棄却した。判断ロジックは以下のとおりである。
(1) 構成要件Aにおける「前記アプリケーションで提供されるサービス」のクレーム解釈
本件発明の特許請求の範囲の記載上、「アプリケーション」と「サービス」の関係について直接的な定義付けはない。しかし、本件明細書の発明の詳細な説明（【0012】、【0014】、【0036】、【0346】等）を参酌すると、アプリケーション自体がサービスとされる機能を提供するものであり、他のサービスを利用する場合には当該サービスに対応するアプリケーションの追加が必要である旨が記載されている。
したがって、構成要件Aにおける「前記アプリケーションで提供されるサービス」とは、「アプリケーション自体がサービスとされる機能そのものを提供する場合」を指すと解するのが相当である。
（※原告は、第三者サーバと連携するサービスも含まれると主張したが、明細書中の追加登録に関する記載はアプリケーションとサービス自体の関係を拡張するものではないとして排斥された。）
(2) 被告プログラムの構成要件A非充足（当てはめ）
被告プログラムの決済機能（GO Pay）において「ｄ払い」を利用する態様は、株式会社NTTドコモが提供する決済機能と連携してこれを決済手段として利用しているにすぎない。
したがって、「ｄ払い」は被告プログラムが備えるアプリケーション（GO Pay）自体がサービスとして提供するものとは認められず、構成要件Aの「前記アプリケーションで提供されるサービス」を充足しない。
5. 実務上・判例上の法的なポイント
- 外部API/サードパーティ決済連携機能における構成要件充足性の判断：
現代のアプリケーションにおいて一般的である「第三者サービス（外部決済事業者等）とのAPI連携・機能統合」について、特許請求の範囲の「アプリケーションで提供されるサービス」という文言に包含されるかどうかが争点となった事案である。裁判所は、明細書の開示内容（UICCやカード内マネージャの背景技術・課題解決構造）を厳格に参酌し、「アプリケーション自身が機能を提供しているか」と「外部のサービスを連携・利用しているにすぎないか」を明確に区別して非充足と判断した。 - クレーム解釈における発明の詳細な説明の参酌（特許法70条2項）：
出願時の技術的背景（ガラケー時代のUICC/チップ内での複数サービス管理等）に基づいて記載された明細書をベースに、後発のスマートフォン向け配車・決済連携サービスへ権利行使を試みた事例である。本判決は、クレーム文言が抽象的であっても、明細書の実質的な開示範囲（当業者が認識し得る技術的思想）を超えて権利範囲を第三者連携機能全般へと拡張解釈することを認めない実務的傾向を再確認させるものである。
0 件のコメント:
コメントを投稿