令和5(ワ)70502特許権侵害差止等請求事件

令和８年７月１５日判決言渡 同日原本領収 裁判所書記官

令和５年（ワ）第７０５０２号 特許権侵害差止等請求事件

口頭弁論終結日 令和８年４月２１日

判 決

原 告 Ｓ．ＲＩＤＥ株式会社

同訴訟代理人弁護士 𠮷 田 和 彦

奥 村 直 樹

同訴訟代理人弁理士 工 藤 嘉 晃

同訴訟復代理人弁護士 日 野 英 一 郎

小 栗 久 典

髙 野 芳 徳

梶 井 啓 順

後 藤 直 之

同補佐人弁理士 林 陽 和

被 告 Ｇ Ｏ 株 式 会 社

同訴訟代理人弁護士 大 野 浩 之

多 田 宏 文

主 文

１ 原告の請求をいずれも棄却する。

２ 訴訟費用は原告の負担とする。

事 実 及 び 理 由

第１ 請求

１ 被告は、別紙被告プログラム目録記載のプログラムを作成し、使用し、譲渡等（譲渡、貸渡し、電気通信回線を通じた提供をいう。）し、譲渡等の申出をしてはならない。２ 被告は、別紙被告プログラム目録記載のプログラムを抹消せよ。

5 第２ 事案の概要１ 事案の要旨本件は、発明の名称を「情報処理装置および方法、並びにプログラム」とする特許（特許第５５２７０４５号。以下「本件特許」という。）に係る特許権（以下「本件特許権」という。）を有する原告が、別紙被告プログラム目録記載のプログラム（以下「被告プログラム」という。）は本件特許の請求項９に記載された発明（以下「本件発明」という。）の技術的範囲に属し、被告による被告プログラムの作成、使用、譲渡、貸渡し、電気通信回路を通じた提供が本件特許権を侵害すると主張して、被告に対し、特許法１００条１項に基づき、被告プログラムの作成等の差止めを求めるとともに、同条２項に基づき、被告プログラムの抹消を求める事案である。２ 前提事実（当事者間に争いのない事実並びに後掲各証拠及び弁論の全趣旨により容易に認定できる事実）

⑴ 当事者ア 原告は、一般乗用旅客自動車運送事業者等に向けた配車ソフトウェア・システムの企画、開発、設計、製造、販売、賃貸及び運営等を目的とする株式会社である。イ 被告は、インターネットを利用したサービス、システム及びアプリケーション企画、開発、運用、導入に関するコンサルティング及び保守サービス業務等を目的とする株式会社である。

⑵ 本件特許権（甲１、２）ア 原告は、以下の本件特許権を有している（本件特許出願の願書に添付された明細書及び図面を「本件明細書」といい、本件明細書の発明の詳細な説明中の段落番号を【０００１】などと記載する。）。特許番号 特許第５５２７０４５号発明の名称 情報処理装置および方法、並びにプログラム

5 出願日 平成２２年６月２８日出願番号 特願２０１０－１４５７３５登録日 平成２６年４月２５日イ 本件特許の特許請求の範囲の請求項９の記載は以下のとおりである。所定のアプリケーションを記憶する記憶手段と、前記アプリケーションで提供されるサービスに関する情報を管理する管理手段とを少なくとも備える情報処理装置に、他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、登録された前記サービスに関する情報を前記他の装置から供給されるデータに基づき生成し、生成された前記情報で、前記管理手段に管理されている前記情報を更新するステップを含む処理を実行させるコンピュータが読み取り可能なプログラム。ウ 本件発明を構成要件に分説すると、次のとおりとなる（以下、分説した構成要件を、その符号に従い「構成要件Ａ」などという。）。Ａ 所定のアプリケーションを記憶する記憶手段と、前記アプリケーションで提供されるサービスに関する情報を管理する管理手段とを少なくとも備える情報処理装置に、他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、Ｂ 登録された前記サービスに関する情報を前記他の装置から供給されるデータに基づき生成し、Ｃ 生成された前記情報で、前記管理手段に管理されている前記情報を更

5 新するＤ ステップを含む処理を実行させるコンピュータが読み取り可能なプログラム。

⑶ 被告の行為被告は、被告プログラムを作成し、電気通信を通じた提供をしている。（甲３、４）

⑷ 先行文献及び先行製品本件特許の出願日前に販売された製品、頒布された刊行物等として、以下のものが存在した。ア 平成２１年１月２４日に販売開始されたＦＯＭＡ端末 docomo ＰＲＩＭＥseries Ｆ－０３Ａ（乙９）の取扱説明書（乙８。以下「乙８文献」といい、これに記載された発明のうち、ｉＤアプリに関するものを「乙８－１発明」、モバイルＳｕｉｃａ登録用ｉアプリに関するものを「乙８－２発明」、マクドナルドトクするアプリに関するものを「乙８－３発明」、おサイフケータイに関するものを「乙８－４発明」という。）イ ケータイＷａｔｃｈ編集部が公開した「ケータイ新機能チェック」という題名の記事（乙１１。平成１８年１月３０日公開。以下「乙１１文献」といい、乙１１文献に記載された発明を「乙１１発明」という。）ウ 平成２１年１月２４日に販売開始された携帯電話であるＦＯＭＡ端末docomo ＰＲＩＭＥseries Ｆ－０３Ａ（乙９。以下「乙９製品」といい、乙９製品によって公然実施された発明を「乙９発明」という。）エ 公開特許公報（特開２００７－１７９２５８公報。乙１４。平成１９年７月１２日公開。以下「乙１４公報」といい、乙１４公報に記載された発明を「乙１４発明」という。）オ 公開特許公報（特開２００８－２９３４９１公報。乙１５。平成２０年１２月４日公開。以下「乙１５公報」といい、乙１５公報に記載された発

5 明を「乙１５発明」という。）カ 公表特許公報（特表２００９－５３６４８２公報。乙１６。平成２１年１０月８日公表。以下「乙１６公報」といい、乙１６公報に記載された発明を「乙１６発明」という。）３ 争点

⑴ 被告プログラムが本件発明の技術的範囲に属するか（争点１）ア 構成要件Ａの充足性（争点１－１）イ 構成要件ＡないしＤの充足性（争点１－２）

⑵ 無効の抗弁の成否（争点２）ア 乙８－１発明を前提とする新規性・進歩性欠如（争点２－１）イ 乙８－３発明に基づく新規性・進歩性欠如（争点２－２）ウ 乙８－４発明に基づく新規性・進歩性欠如（争点２－３）エ 乙１１発明に基づく新規性・進歩性欠如（争点２－４）オ 乙９発明に基づく新規性・進歩性欠如（争点２－５）カ 乙１４発明に基づく新規性・進歩性欠如（争点２－６）キ 乙１５発明に基づく新規性・進歩性欠如（争点２－７）ク 乙１６発明に基づく新規性・進歩性欠如（争点２－８）ケ サポート要件違反（争点２－９）なお、被告は、乙８－２発明に基づく新規性・進歩性欠如も無効事由として主張していたが、本件第２回弁論準備手続期日において、主引例を乙８－２発明から乙１１発明に変更した。また、原告は、訂正の再抗弁を提出していたが、本件第４回弁論準備手続期日において、訂正後の発明に係る主張を全て撤回した。４ 争点に関する当事者の主張

⑴ 争点１－１（構成要件Ａの充足性）について（原告の主張）

5 ア 被告プログラムは、以下の構成を有している。(ｱ) 態様１（支払方法としてクレジットカードが登録されている状態から「ｄ払い」を支払方法に登録する態様と支払方法をクレジットカード払いからｄ払いに変更する態様）Ａ’被告プログラム（ＧＯアプリ）は、被告プログラム（ＧＯアプリ）を記憶する記憶手段（メモリ）と、前記被告プログラムで提供される配車サービスへの支払サービス（クレジットカード払い及びｄ払いサービスを含む）に関する情報を管理する管理手段とを備えるユーザのスマートフォンに、ｄ払いサーバから、前記ｄ払いサービスを登録するためのデータを受信した場合、そのデータに基づき、前記被告プログラム（ＧＯアプリ）の処理により前記ｄ払いサービスを登録する。Ｂ’被告プログラム（ＧＯアプリ）は、登録された前記ｄ払いサービスに関する情報を前記ｄ払いサーバから供給されるデータに基づき生成する。Ｃ’被告プログラムは、生成された前記情報で、前記管理手段に管理されている前記情報を更新する（支払方法一覧から「ｄ払い」を選択する、又は、支払方法の情報をクレジットカードからｄ払いにする）。Ｄ’被告プログラムは、Ａ’～Ｃ’のステップを含む処理を実行させるコンピュータ（スマートフォン）が読み取り可能なプログラムである。(ｲ) 態様２（既に支払方法としてｄ払いが登録されている状態からｄ払いを削除する態様）Ａ’’被告プログラム（ＧＯアプリ）は、被告プログラム（ＧＯアプリ）を記憶する記憶手段（メモリ）と、前記被告プログラムで提供される配車サービスへの支払サービス（ｄ払いサービスを含む）に関する情報を管理する管理手段とを備えるユーザのスマートフォンに、ｄ払いサーバから、前記ｄ払いサービスを登録するためのデータを受信した

5 場合、そのデータに基づき、前記被告プログラム（ＧＯアプリ）の処理により前記ｄ払いサービスを登録する。Ｂ’’被告プログラム（ＧＯアプリ）は、登録された前記ｄ払いサービスに関する情報を前記ｄ払いサーバから供給されるデータに基づき生成する。Ｃ’’被告プログラム（ＧＯアプリ）は、生成された前記「ｄ払い」サービスに関する情報で、前記管理手段に管理されているｄ払いサービスに関する情報を削除する。Ｄ’’被告プログラムは、Ａ’’～Ｃ’’のステップを含む処理を実行させるコンピュータ（スマートフォン）が読み取り可能なプログラムである。イ 「前記アプリケーションで提供されるサービス」について【００３６】や【００８５】では、本件発明の実施例としてサービスが登録されていない状態のアプリケーションに追加でサービスが登録される場合が開示されている。このように、本件発明における「サービス」は、アプリケーションに当初から備わっているサービスに限られないことは本件明細書の記載から明らかであり、アプリケーションに当初は登録されていなくても、その後、アプリケーションの処理により追加で登録されるようなサービスも当然に技術的範囲に属することが前提とされている。また、【００３６】の「クレジットの機能を実現するサービス」の記載からも明らかなとおり、アプリケーションに登録されたサービスを提供する際、第三者であるサービスプロバイダーサーバと連携することは当然の前提とされており、そのような連携が行われるサービスであることをもって、「前記アプリケーションで提供されるサービス」の充足性は左右されるものではない。そのため、「サービス」に被告プログラムのＡ’及び Ａ’’における「ｄ

5 払いサービス」が含まれることから、被告プログラムは「前記アプリケーションで提供されるサービス」を充足する。ウ 「サービスに関する情報を管理する管理手段」について「情報を管理する管理手段」は、情報を管理するための管理手段を意味するものであり、「サービスに関する情報」がいまだ管理されていない段階であっても、「サービスに関する情報」が登録された後にそのような情報を管理することができるのであれば「管理手段」に相当する。そして、上記アのとおり、被告プログラムにおけるＡ’及び Ａ’’は、ｄ払いサービスを含む支払サービスに関する情報を管理する管理手段を備えていることから、「サービスに関する情報を管理する管理手段」を充足する。エ 「前記アプリケーションの処理により前記サービスを登録し」について上記アのとおり、被告プログラムにおけるＡ’及び Ａ’’は、その処理により、ｄ払いサービスを登録していることから、「前記アプリケーションの処理により前記サービスを登録し」を充足する。オ よって、被告プログラムは、構成要件Ａを充足する。（被告の主張）ア 「前記アプリケーションで提供されるサービス」について【０００２】ないし【００１７】の記載からすれば、本件発明は、携帯電話の機種変更の際の話として、変更後の携帯電話のビューアがアプリケーションマネージャ上に登録されているアプリケーションしか認識することができず、アプリケーションが提供する個々のサービスまでも認識して、その情報をユーザに提示することができないという課題に対し、ＵＩＣＣなどの所定の情報を管理する装置内の情報を、その情報を閲覧するためのビューワで正確に閲覧できるようにしたものであると記載されていることからして、「サービス」は、アプリケーションを移行する際に、そのアプリ

5 ケーションに備わっているサービス、つまり、アプリケーションで当然に備わっているサービスであることが必要である。そして、ｄ払いサービスは、株式会社ＮＴＴドコモ（以下「ＮＴＴドコモ」という）が提供する支払サービスであり、被告プログラムで提供されるサービスではないし、クレジットカード払いもクレジットカード会社が提供する支払サービスであり、被告プログラムで提供されるサービスではない。よって、被告プログラムは「前記アプリケーションで提供されるサービス」を充足しない。イ 「サービスに関する情報を管理する管理手段」について本件発明の記載からすれば、「所定のアプリケーションを記憶する記憶手段と、前記アプリケーションで提供されるサービスに関する情報を管理する管理手段とを少なくとも備える情報処理装置」が既に存在し、当該情報処理装置に対して、「他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録」することが必要になる。被告プログラムにおいては、「ｄ払い」を登録する前に「ｄ払い」を既に管理する情報処理装置が存在しないことから、「ｄ払い」を追加する態様、支払方法の情報を「クレジットカード」から「ｄ払い」にする態様、及び「ｄ払い」を削除する態様のいずれにおいても、構成要件Ａを充足しない。ウ 「前記アプリケーションの処理により前記サービスを登録し」について被告プログラムにおいて、ｄ払いサービスを登録する場合には、セキュリティコードの受信から入力までのやり取り（２段階認証）及びＮＴＴ ＤｏＣｏＭｏのｓｐモードパスワードの入力から「承諾番号」の取得までのやり取りは、ＮＴＴドコモのシステムとの間で直接行われており、ＧＯアプリの処理によって行われているわけではない。

5 また、上記の登録に当たっては、ユーザが適宜操作を行うことで、「セキュリティコード」を取得して入力し、さらにｓｐモードパスワードを入力する態様となっており、被告プログラムの処理によって「セキュリティコード」が入力され、「支払サービス（ｄ払い）」が登録されていない。よって、被告プログラムは「前記アプリケーションの処理により前記サービスを登録し」を充足しない。エ 以上によれば、被告プログラムは、構成要件Ａを充足しない。

⑵ 争点１－２（構成要件ＡないしＤの充足性）について（原告の主張）ア 上記⑴（原告の主張）アのとおり、被告プログラムは、態様１では、Ａ’ないしＤ’を、態様２ではＡ’’ないしＤ’’の構成を有しており、構成要件ＡないしＤを充足する。イ 被告は、構成要件ＡないしＤについて、サービスの「登録」、「生成」、「更新」の各ステップは一連のステップであり、他の動作が入ってはならないと主張する。しかしながら、本件発明は、「登録」、「生成」、「更新」の各ステップ自体は規定しているものの、これらの各ステップ間に別のステップやユーザ操作が介在するか否かは特段限定しておらず、ユーザ操作は技術的範囲の属否とは関係がない。（被告の主張）構成要件Ａで「情報処理装置に、他の装置から、サービスを登録するためのデータを受信した場合」と記載され、構成要件Ｄで「ステップを含む処理を実行させるコンピュータが読み取り可能なプログラム。」が要件とされていることから、情報処理装置に、他の装置から、サービスを登録するためのデータを受信した場合に、①そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、②登録された前記サービスに関する情報を

5 前記他の装置から供給されるデータに基づき生成し、③生成された前記情報で、前記管理手段に管理されている前記情報を更新すること（一連のステップ）をプログラムが実行する必要がある。原告の主張する被告プログラムの態様１及び態様２はいずれも、サービスを登録する場面（①）と、サービスに関する情報を生成し、更新する場面（②及び③）が分断されており、上記①ないし③の一連のステップを実行する態様となっていない。そのため、被告プログラムは構成要件ＡないしＤを充足しない。

⑶ 争点２（無効の抗弁の成否）について別紙争点２についての当事者の主張のとおり。

第３ 当裁判所の判断

１ 本件明細書の記載事項

本件明細書には、以下の記載がある（図面は別紙図面目録を参照）。

⑴ 技術分野

【０００１】本発明は情報処理装置および方法、並びにプログラムに関し、特に、複数の通信プロトコルに対応するチップやカードなどで管理されているデータを更新する際などに用いて好適な情報処理装置および方法、並びにプログラムに関する。

⑵ 背景技術

【０００２】携帯電話機が普及し、携帯電話機でさまざまなサービスが提供されている。図１Ａを参照するに、携帯電話機１１には、チップ１２が組み込まれており、このチップ１２に、サービス１３－１やサービス１３－２が書き込まれている。また、サービス１３－１をユーザに提供する際の処理は、アプリケーション１４－１が行い、サービス１３－２をユーザに提供する際の処理は、ア

5 プリケーション１４－２が行うように構成されている。

【０００３】アプリケーションは、携帯電話機上のソフトウェアに書き込まれる一連の実行可能なモジュールであり、チップ上に書き込まれるサービスとは異なる。携帯電話機には、非特許文献１に示すＭＩＤＰ ２．０仕様に準拠した製品であればアプリケーション管理ソフト（AMS:Application Management Software）が、非特許文献２に示すＭＩＤＰ １．０仕様に準拠した製品であれば同様の機能を持つＪＡＭ（Java（登録商標） Application Manager）が搭載されており、携帯電話に搭載されるアプリケーションの管理を行っている。ここでの管理とは、アプリケーションのダウンロード、インストール、削除といった一連の状態遷移を保持していることを指す。【０００４】アプリケーション管理ソフト１５は、まず、アプリケーション１４－１が携帯電話機にインストールされた事を管理し、さらにアプリケーションがサービス１３－１をチップ内に生成した際には、その情報も関連付けて管理する。同様にアプリケーション１４－２がインストールされた後にサービス１３－２をチップ内に生成した場合、その情報について関連付けを行う。例えば、アプリケーション管理ソフト１５は、アプリケーション１４－２を削除する場合、関連付けられているサービス１３－２を事前に削除する処理を必要とする。【０００５】ここで図１Ｂに示すように、ユーザが携帯電話機１１から携帯電話機３１に変えるときを考える。例えば、携帯電話機３１を購入する際、その購入した店で、携帯電話機１１から携帯電話機３１へのデータの移行のサービスが行われる。携帯電話機１１のチップ１２に記憶されているサービス１３－１やサービス１３－２（以下、個々にサービス１３－１，１３－２を区別する

5 必要がない場合、単にサービス１３と記述する。他も同様の記述とする）は、

携帯電話機３１のチップ３２に移行される。また、アプリケーション管理ソフト１５の情報も、アプリケーション管理ソフト３３に移行される。しかしながら、チップ１２で管理されていない携帯電話機上のアプリケーション１４は、携帯電話機３１に移行されない。【０００６】携帯電話機３１のアプリケーション管理ソフト３３は、チップ３２に記憶されているサービス１３があるが、それに対応するアプリケーション１４がないと、ユーザにサービス１３に対応するアプリケーション１４をダウンロードするように指示するメッセージを携帯電話機３１のディスプレイ上に表示させる。ユーザが、そのメッセージに対する処理として、アプリケーション１４をダウンロードすることで、新しい携帯電話機３１でも、サービス１３を利用できる状態となる。

⑶ 先行技術文献

【０００７】【非特許文献１】Mobile Information Device Profile FOR Java TM 2 MicroEdition(JSR118)【 非 特 許 文 献 ２ 】 Mobile Information Device Profile (JSR-37) JCPSpecification Java 2 Platform, Micro Edition, 1.0a

⑷ 発明が解決しようとする課題

【０００８】上記したように、現状、チップ１２でサービス１３が管理され、アプリケーション管理ソフト１５（３３）でアプリケーション１４との対応付けなどが行われているが、サービス１３をＵＩＣＣ（Universal Integrated CircuitCard)に記憶して管理することが考えられる。図２Ａに示すように、携帯電話機１１のＵＩＣＣ５１にサービス１３が記憶されている状態のとき、携帯電

5 話機１１からＵＩＣＣ５１が外され、別の携帯電話機３１に、そのＵＩＣＣ

５１が装着されると、携帯電話機３１でサービス１３が利用できるようになることが好ましい。【０００９】この場合、ＵＩＣＣ５１に記憶されているサービス１３などは、差し込まれた携帯電話機３１側に移行されることになるが、アプリケーション管理ソフト１５の情報は、アプリケーション管理ソフト３３には移行されない。その結果、アプリケーション管理ソフト１５で行われていた処理を、アプリケーション管理ソフト３３で行うことができず、結果として、ＵＩＣＣ５１に記憶されているサービス１３が利用できない可能性がある。【００１０】そこで、図２Ｂに示すように、携帯電話機１１に、ビューワ（Viewer）７１を設けることが考えられる。このビューワ７１は、各携帯電話機が備え、ＵＩＣＣ５１が管理しているサービスなどを閲覧できるように構成される。例えば、携帯電話機１１に装着されていたＵＩＣＣ５１が外されて、携帯電話機３１に装着された場合、携帯電話機３１もビューワ７１を備えているため、そのビューワ７１により、ＵＩＣＣ５１で管理されているサービスを閲覧することができる。【００１２】ＵＩＣＣ５１は、例えば、図３に示すような構成とされている。ＵＩＣＣハードウェア１０１の上に、ＵＩＣＣ内のアプリケーションマネージャ１０２があり、この上に、アプリケーション１０３、アプリケーション１０４、アプリケーション１０５が管理されている。アプリケーション１０３は、例えば、クレジットカードの機能を実現するサービスを提供するためのアプリケーションである。アプリケーション１０４は、例えば、交通機関に乗り降りするときの料金の支払いなどのときに用いられるトランスポート系のサー

5 ビスを提供するためのアプリケーションである。

【００１４】アプリケーション１０５は、総合サービスを提供するためのアプリケーションであり、サービス１０６－１、サービス１０６－２、サービス１０６－３を提供する。例えば、サービス１０６－１は、クレジットの機能を実現するサービスであり、サービス１０６－２は、トランスポート系のサービスを提供するサービスであり、サービス１０６－３は、クーポンを提供するサービスである。【００１５】このようなアプリケーションが登録されているときに、ビューワ７１により、ＵＩＣＣ５１で管理されているアプリケーションの閲覧が行われると、例えば、図４に示したような表示が行われる。ビューワ７１は、アプリケーション１０３、アプリケーション１０４、アプリケーション１０５を認識するため、アプリケーション１０３が提供するサービスのサービス名である“サービス１０３”、アプリケーション１０４が提供するサービスのサービス名である“サービス１０４”という名称をユーザに提供する。そして、アプリケーション１０５が提供するサービスは、複数あるが、アプリケーション１０５の総称である“サービス１０５”という名称が、ユーザに提供される。【００１６】このように、アプリケーション１０５は、サービス１０６－１乃至１０６－３を提供するが、ビューワ７１は、ＵＩＣＣ内のアプリケーションマネージャ１０２上に登録されているアプリケーション１０３乃至１０５しか認識できず、アプリケーション１０５が提供するサービス１０６－１乃至１０６－３までも認識して、その情報をユーザに提示することができない。【００１７】本発明は、このような状況に鑑みてなされたものであり、例えば、ＵＩＣ

5 Ｃなどの所定の情報を管理する装置内の情報を、その情報を閲覧するための

ビューワで正確に閲覧できるようにし、かつそのための更新を既存のインフラを用いて行えるようにするものである。

⑸ 課題を解決するための手段

【００２７】本発明の一側面の情報処理装置および方法、並びにプログラムにおいては、記憶されているアプリケーションで提供されるサービスに関する情報が管理され、他の装置から、サービスを登録するためのデータが受信された場合、そのデータに基づき、アプリケーションの処理によりサービスが登録され、登録されたサービスに関する情報が、他の装置から供給されるデータに基づき生成され、生成された情報で、管理されている情報が更新される。

⑹ 発明の効果

【００２９】本発明の一側面によれば、情報を管理している装置内の情報を、既存のインフラを用いて更新することができる。

⑺ 発明を実施するための形態

【００３２】［システムについて］図５は、本発明が適用されるシステムの一実施の形態の構成を示す図である。図５に示したシステムは、携帯電話機２０１とリーダライタ２０２から構成される。携帯電話機２０１とリーダライタ２０２は、非接触により通信を行う。ここでは携帯電話機２０１として説明を続けるが、リーダライタ２０２と通信を行い、何らかのデータを保持するＩＣカードなどにも本発明を適用することができる。【００３３】［携帯電話機２０１の構成について］

5 図６は、携帯電話機２０１の内部構成を示す図である。携帯電話機２０１

は、ホスト２２１、ＵＩＣＣ（Universal Integrated Circuit Card)２２２を含 み 、 ホ ス ト ２ ２ １ と Ｕ Ｉ Ｃ Ｃ ２ ２ ２ は 、 Ｕ Ａ Ｒ Ｔ （ UniversalAsynchronous Receiver Transmitter）２２３でデータの授受を行えるように接続されている。また、携帯電話機２０１とリーダライタ２０２との非接触な通信を制御するＣＬＦ（Contactless Frontend）２２４も、携帯電話機２０１は含む構成とされている。【００３５】ＵＩＣＣ２２２は、ＵＩＣＣハードウェア２５１、アプリケーションマネージャ２５２、レジストリ２５３を備える。またＵＩＣＣ２２２は、ここでは、第１アプリケーション２５４、第２アプリケーション２５５、および第３アプリケーション２５６を記憶し、管理するとする。第１アプリケーション２５４は、例えば、携帯電話機２０１でクレジットカードの機能を実現するサービスを提供するためのアプリケーションである。また例えば、第２アプリケーション２５５は、交通機関に乗り降りするときの料金の支払いなどのときに用いられるトランスポート系のサービスを携帯電話機２０１で提供するためのアプリケーションである。【００３６】また例えば、第３アプリケーション２５６は、総合サービスを提供するためのアプリケーションである。後述するように、第３アプリケーション２５６は、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。図６には図示していないが、図１４を参照して後述するように、ＵＩＣＣ２２２にサービスが追加で登録されることがあり、ＵＩＣＣ２２２は、登録されたサービスを記憶し、管理する機能も有する。各アプリケーションは、アプリケーションマネージャ２５２によって、管理される

5 ものであるが、同じ実行環境で管理される事に限定されない。一例として、

アプリケーションマネージャ２５２がＪａｖａＣａｒｄＴＭを搭載し、１つのアプリケーションがソフトウェアにより実現されていても、他のアプリケーションが、ＲＯＭの工場出荷時に書き込まれている場合や、別チップとして提供される場合もあり得る。【００３８】また、アプリケーションマネージャ２５２は、ＣＬＦ２２４を介して供給されたコマンドを解釈し、その解釈に基づき、アプリケーションにデータを供給したり、アプリケーションからのデータを、ＣＬＦ２２４に供給したりする処理を実行する。レジストリ２５３は、アプリケーションが提供するサービスの名称やサービス種別といったサービスに関する情報を管理する。【００８０】ここで、再度図６を参照する。図６に示したように、ＵＩＣＣ２２２で、

第１アプリケーション２５４、第２アプリケーション２５５、および第３ア

プリケーション２５６が管理されているとき、ビューワ２４１による処理が実行されると、例えば、図１２に示すような画面がユーザに提供される。画面とは、例えば、携帯電話機２０１のディスプレイ４０１に表示される画面のことである。【００８１】図１２に示すようにビューワ２４１は、アプリケーションマネージャ２５２が認識した第１アプリケーション２５４、第２アプリケーション２５５、

第３アプリケーション２５６を認識する。そしてビューワ２４１は、第１ア

プリケーション２５４が提供するサービスの名称である“第１サービス”、第２アプリケーション２５５が提供するサービスの名称である“第２サービス”、および第３アプリケーション２５６が提供するサービスの名称である“第３サービス”を、ディスプレイ４０１に表示させる。

5 【００８２】

第３アプリケーション２５６は、総合サービスであり、図１３に示すよう

に複数のサービスを提供できる。すなわち、図１３に示した例では、第３アプリケーション２５６は、第３－１サービス２５７、第３－２サービス２５８、および第３－３サービス２５９を提供できるように構成されている。【００８３】このように、第３アプリケーション２５６が、第３－１サービス２５７、

第３－２サービス２５８、および第３－３サービス２５９を提供できる場合

であっても、ビューワ２４１は、アプリケーションマネージャ２５２上に登録されている第１アプリケーション２５４、第２アプリケーション２５５、

第３アプリケーション２５６しか認識できず、第３－１サービス２５７、第

３－２サービス２５８、および第３－３サービス２５９までも認識して、その情報をユーザに提示することができない。【００８４】これは、レジストリ２５３で、登録されているサービスの情報が管理されているからである。ここで、アプリケーションやサービスの登録について説明する。【００８５】図１４に示すように、ＵＩＣＣ２２２に第３－１サービス２５７が登録されていない状態（登録されていないことを示すために、図１４においては、点線で示す。またアプリケーションなどは図示していない）のときに、第３－１サービス２５７を登録する際、ＵＩＣＣ２２２の外部から、サービスを登録するためのデータ４３１が送信される。サービスを登録するためのデータは、サービス登録データとする。このサービス登録データ４３１は、第３－１サービス２５７を登録するためのものである。このようなサービス登録データ４３１によるサービスの登録は、現状でも行われているインフラを用

5 いて行うことができる。図１４を使って説明すると、リーダライタ２０２か

らＣＬＦ２２４を経由して、ＵＩＣＣ２２２にサービス登録データ４３１を渡すことが出来る。または、ホスト２２１からＵＡＲＴを経由して、ＵＩＣＣ２２２にデータを渡すことも可能である。【００８６】しかしながら、サービス登録データ４３１で第３－１サービス２５７を登録しても、アプリケーションマネージャ２５２のレジストリ２５３には、第３－１サービス２５７の情報は登録されない。そのため、そのようなサービスが登録されたことが認識できない。よって、レジストリ２５３で管理されている情報を更新するために、サービス種別や名前を登録するための処理が行われる必要がある。【００８７】例えば、サービス種別・名前コマンド４３２をアプリケーションマネージャ２５２に対して送信し、アプリケーションマネージャ２５２での管理情報（レジストリ２５３内の情報）を更新する必要がある。この場合、第３アプリケーション２５６には、第３－１サービス２５７が含まれること（新たに登録されたこと）を、サービス種別・名前コマンド４３２でアプリケーションマネージャ２５２のレジストリ２５３に登録する必要がある。【００８９】既存のインフラをできる限り生かしつつも、ビューワ２４１で、個々のサービスが閲覧できるようにするためには、上記したように、サービス登録データ４３１とサービス種別・名称コマンド４３２をそれぞれ送信してサービス名を登録することが考えられる。ここでは、第３アプリケーション２５６が複数のサービスを含んでいるとして説明したが、第１アプリケーション２５４や第２アプリケーション２５５が複数のサービスを含んでいるような場合でも、同様のことが言える。

5 【００９０】

図７乃至１１を参照して説明したように、第１アプリケーション２５４、

第２アプリケーション２５５、第３アプリケーション２５６のそれぞれは、

複数の通信路によりアクセス可能である。第３アプリケーション２５６は、通信路３５１乃至３５４（図９）があるため、例えば、通信路３５１で、第３－１サービス２５７を登録し、通信路３５２で、レジストリ２５３の情報を更新することができる。【００９１】このようなことを可能にするためには、リーダライタ２０２が、携帯電話機２０１に対して登録や更新の処理を実行するとき、どの通信路を用いて登録を行い、どの通信路を用いて更新を行うかを判断し、その判断に基づき、適切なコマンド、例えば、選択した通信路に適合したプロトコルのパケットでのコマンドを生成する必要がある。【００９２】［リーダライタの構成について］そこで、リーダライタ２０２は、図１５に示すような機能を有する構成とされる。すなわち、リーダライタ２０２は、通信制御部５０１、通信方式決定部５０２、サービス登録部５０３、および更新処理部５０４を備える。通信制御部５０１は、所定のアプリケーション（例えば、第３アプリケーション２５６）と、アプリケーションで提供されるサービス（例えば、第３－１サービス２５７）を管理するアプリケーションマネージャ２５２を備えるＵＩＣＣ２２２との非接触な通信を制御する。【００９３】通信方式決定部５０２は、ＵＩＣＣ２２２に対して所定のサービスの登録を行うときの通信方式と、レジストリ２５３に対する更新を行うときの通信方式をそれぞれ決定する処理を行う。

5 【００９４】

サービス登録部５０３は、通信方式決定部５０２により決定された通信方式で、ＵＩＣＣ２２２に所定のサービスを登録するためのコマンドの生成などを実行する。更新処理部５０４は、通信方式決定部５０２により決定された通信方式で、ＵＩＣＣ２２２のレジストリ２５３で管理されている情報を更新するためのコマンドの生成などを実行する。【０３４４】［効果について］このように、ＵＩＣＣ２２２に、例えば、第３アプリケーション２５６で提供されるサービスが単独で登録されていても、異なる携帯電話機２０１で共通して用いられるビューワ２４１から、個々のサービスの存在を確認できるようになる。このような確認が行えるようになることで、上記したように、ユーザ側に個々のサービスの存在を認識させるための画面を提示することが可能となる。【０３４５】またその表示は、例えば、図３４に示したように、他のアプリケーションで提供されるサービスと同列のサービスとしてユーザに参照させることができる表示とすることができる。また、新たなサービスであっても、既に登録されているサービスと同列のサービスとして表示することが可能となる。または、図３３に示したように、所定のアプリケーションで提供されるサービスは、そのアプリケーションと関連付けられた、階層的な表示とすることも可能となる。【０３４６】また、サービスの存在確認が行えるようになれば、必要時に対向のアプリケーションの追加を行うことが可能となる。すなわち、サービスとアプリケーションの関係性に自由度を持たせることが可能となる。

5 【０３４７】

またサービスの登録やサービス名の登録は、既存のインフラをできる限り生かして行うことができる。よって、ＵＩＣＣ２２２でサービスを管理するようにシステムが移行しても、移行後に係るコストを低減させることが可能となる。さらに、インフラを生かすことができることで、大幅な変更を伴わないでシステムの移行などが実行できるようになるため、ユーザにとっても、開発者側にとっても、システム移行にともなう混乱を生じさせるようなことを防ぐことが可能となる。

２ 争点１－１（構成要件Ａの充足性）について

⑴ 「前記アプリケーションで提供されるサービス」の意義

ア 構成要件Ａは、「所定のアプリケーションを記憶する記憶手段と、前記アプリケーションで提供されるサービスに関する情報を管理する管理手段とを少なくとも備える情報処理装置に、他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、」と規定しているところ、本件発明の構成要件において、これ以外に「アプリケーション」と「サービス」の関係等についての記載はない。そして、本件明細書には、「アプリケーション」と「サービス」の関係に関する記載として、「ＵＩＣＣハードウェア１０１の上に、ＵＩＣＣ内のアプリケーションマネージャ１０２があり、この上に、アプリケーション１０３、アプリケーション１０４、アプリケーション１０５が管理されている。アプリケーション１０３は、例えば、クレジットカードの機能を実現するサービスを提供するためのアプリケーションである。アプリケーション１０４は、例えば、交通機関に乗り降りするときの料金の支払いなどのときに用いられるトランスポート系のサービスを提供するためのアプリケーションである。」（【００１２】）、「アプリケーション１０５は、総合サー

5 ビスを提供するためのアプリケーションであり、サービス１０６－１、サ

ービス１０６－２、サービス１０６－３を提供する。例えば、サービス１０６－１は、クレジットの機能を実現するサービスであり、サービス１０６－２は、トランスポート系のサービスを提供するサービスであり、サービス１０６－３は、クーポンを提供するサービスである。」（【００１４】）、「また例えば、第３アプリケーション２５６は、総合サービスを提供するためのアプリケーションである。後述するように、第３アプリケーション２５６は、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。」（【００３６】）、「サービスの存在確認が行えるようになれば、必要時に対向のアプリケーションの追加を行うことが可能となる。」（【０３４６】）との記載があることが認められ、これらの記載は、アプリケーションがサービスとされる機能を提供するものであり、他のサービスを利用する場合には当該サービスに対応するアプリケーションの追加が必要であることを示すものであると理解することができる。そうすると、構成要件Ａにおいて「前記アプリケーションで提供されるサービス」とあるのも、アプリケーション自体がサービスとされる機能そのものを提供する場合を指すものであると解するのが相当である。イ これに対し、原告は、本件発明における「サービス」は、アプリケーションに当初から備わっているサービスに限られないことは本件明細書の【００３６】や【００８５】の記載から明らかであり、アプリケーションに当初は登録されていなくても、その後、アプリケーションの処理により追加で登録されるようなサービスも当然に技術的範囲に属することが前提とされ、当該サービスを提供する際、第三者であるサービスプロバイダーサーバと連携することは当然の前提とされているのであるから、そのような連携が行われるサービスであることをもって「前記アプリケーションで

5 提供されるサービス」の充足性は左右されない旨主張する。

しかしながら、【００３６】や【００８５】には、ＵＩＣＣにサービスが追加で登録され得ることが記載されているにすぎず、アプリケーションとサービスの関係を定めるものではないことからすれば、これらの本件明細書の記載をもって、構成要件Ａの「前記アプリケーションで提供されるサービス」について、実際のサービスは第三者のサービスプロバイダーサーバと連携して、当該サーバにより提供されるものを含むものであると解釈すべきであるとはいえず、原告の上記主張は採用することができない。

⑵ 被告プログラムの充足性

証拠（甲５ないし１０、２８）及び弁論の全趣旨によれば、被告プログラムは、ＧＯ Ｐａｙと呼ばれるタクシー料金の決済機能を有しているところ、ＧＯ Ｐａｙは、ｄ払いと連携することによりｄ払いを利用することが可能となるものの、ｄ払いはＮＴＴドコモが提供する決済機能であって、ＧＯＰａｙは個々のタクシー料金の決済手段として連携したｄ払いを利用するものであると認められる。そうすると、ｄ払いは、被告プログラムが備えるアプリケーションであるＧＯ Ｐａｙ自体がサービスとして提供するものであるとはいえないことから、被告プログラムは構成要件Ａの「前記アプリケーションで提供されるサービス」を充足しない。

３ 小括

以上によれば、被告プログラムは構成要件Ａを充足しないから、その余の点について検討するまでもなく、被告プログラムが本件発明の技術的範囲に属し、被告による被告プログラムの作成等が本件特許権を侵害すると認めることはできない。

第４ 結論

よって、原告の請求はいずれも理由がないから棄却することとして、主文の

5 とおり判決する。

東京地方裁判所民事第２９部裁判長裁判官澁 谷 勝 海裁判官本 井 修 平裁判官浅 川 浩 輝（別紙）被告プログラム目録「ＧＯ タクシーが呼べるアプリ 旧ＭＯＶ×ＪａｐａｎＴａｘｉ」以上（別紙）争点２についての当事者の主張

１ 争点２－１（乙８－１発明を前提とする新規性・進歩性欠如）について

5

（被告の主張）

⑴ 乙８－１発明の構成

乙８文献には、乙８－１発明に関し、次の構成が記載されている。ａ１１：「ｉＤアプリ」を記憶し、「ｉＤアプリ」を用いて提供されるカードでの支払いサービスに関する情報を管理する携帯電話に、サーバから、「ｉＤアプリ」を用いて提供されるカードでの支払いサービスを登録するためのデータを受信し、（カードアプリのデータを用いつつ）取得されたデータに基づき、カードでの支払いサービスを登録し、ｂ１１：登録された「ｉＤアプリ」を用いて提供されるカードでの支払いサービスに関する情報を、サーバからダウンロードしたデータに基づいて生成し、ｃ１１：生成された「ｉＤアプリ」を用いて提供されるカードでの支払いサービスに関する情報で、管理される情報を更新する、ｄ１１：ステップを含む処理を実行させるためのプログラム。

⑵ 新規性・進歩性の欠如

本件発明の構成は、乙８－１発明の構成と同一であるから、本件発明は新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

（原告の主張）

⑴ 乙８－１発明について

乙８－１発明に係る「ｉＤアプリ」と「カードアプリ」とは別個のアプリである。すなわち、乙８－１発明は、「ｉＤアプリ」及び「カードアプリ」という二つのアプリケーションによる処理を開示したものであり、「ｉＤアプリ」という単一のアプリケーションによる処理を開示したものではない。したがって、乙８－１発明は、単一の「所定のアプリケーション」による処理を規定した本件発明とは全く異なるものである。

5 その結果、乙８－１発明には、本件発明における「サービスを登録」や「ア

プリケーションの処理により…サービスを登録」といった構成に対応した開示が存在せず、乙８－１発明における「カードアプリ」はあくまで「アプリケーション」であって、本件発明における「アプリケーションで提供されるサービス」にも相当しない。

⑵ 本件発明と乙８－１発明の相違点

上記⑴を踏まえ、本件発明と乙８－１発明とを対比すると、少なくとも、以下の点において相違する。

① 本件発明は「アプリケーションで提供されるサービスに関する情報を管

理する」ものであるのに対して、乙８－１発明ではアプリケーションでサービスが提供される構成は開示されていない点

② 本件発明では「アプリケーションの処理により…サービスを登録」する

ものであるのに対して、乙８－１発明では、サービスが登録されず、それゆえ、「アプリケーションの処理により…サービスを登録」する構成が存在しない点

③ 本件発明は、「登録された前記サービスに関する情報」を特定するもので

あるのに対して、乙８－１発明ではこれに相当する構成の開示が存在しない点

④ 本件発明は、「生成された前記（サービスに関する）情報」で「管理手段

に管理されている前記（サービスに関する）情報を更新」（構成要件Ｃ）することを必要とするのに対して、乙８－１発明ではこれに相当する構成の開示が存在しない点

⑶ 新規性・進歩性を有すること

上記⑵のとおり、本件発明と乙８－１発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえして

5 おらず、これら各相違点に係る構成が周知技術や設計事項であったことを示

す証拠も提出していないし、まして、組合せの容易性についても何ら主張立証がない。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

２ 争点２－２（乙８－３発明に基づく新規性・進歩性欠如）について

（被告の主張）

⑴ 乙８－３発明の構成

乙８文献には、乙８－３発明に関し、次の構成が記載されている。ａ１３：「マクドナルド トクするアプリ」を記憶し、「マクドナルド トクするアプリ」で提供される「かざすクーポン」を用いた支払サービスに関する情報を管理する携帯電話に、サーバからダウンロードした「かざすクーポン」を用いた支払サービスを登録するためのデータを受信し、そのデータに基づき、「マクドナルド トクするアプリ」の処理により「かざすクーポン」を用いた支払サービスを登録し、ｂ１３：登録された「かざすクーポン」を用いた支払サービスに関する情報を、サーバからダウンロードしたデータに基づいて生成し、ｃ１３：生成された「かざすクーポン」を用いた支払サービスに関する情報で、管理される情報を更新する、ｄ１３：ステップを含む処理を実行させるためのプログラム。

⑵ 新規性・進歩性の欠如

本件発明の構成は、乙８－３発明の構成と同一であるから、本件発明は新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

（原告の主張）

⑴ 乙８－３発明について

乙８－３発明は、アプリケーションとしての「マクドナルド トクするアプリ」

5 とサービスとしての「かざすクーポン」機能が一体となっており、「アプリケー

ション」とは別個に「サービス」は存在しない。すなわち、乙８－３発明に関しては、①「マクドナルド トクするアプリ」というアプリケーションで提供される機能としての「かざすクーポン」サービス機能、②「かざすクーポン」サービスにおいて提供されるクーポンそのもののデータとしての割引クーポンのデータが存在するところ、

（被告の主張）

は、これら①及び②の両者を混同するものであり、乙８－３発明において、ダウンロードされているのはクーポンのデータそのもの（上記②） であって、「サービスを登録するためのデータ」ではない

⑵ 本件発明と乙８－３発明の相違点

上記⑴を踏まえ、本件発明と乙８－３発明とを対比すると、少なくとも、以下の点において相違する。

① 本件発明においては、「サービスを登録するためのデータを受信した場合

…サービスを登録」することが必要であるのに対し、乙８－３発明においては、アプリケーションである「マクドナルド トクするアプリ」が「サービス」である「『かざすクーポン』サービス機能」に先行して記憶される構成が存在しない点

② 本件発明は「アプリケーションの処理により…サービスを登録」するも

のであるのに対して、乙８－３発明では、アプリケーションとサービスが当初から一体になっており、サービスは「登録」されず、「アプリケーションの処理により…サービスを登録」する構成が存在しない点

③ 本件発明は、「サービスを登録するためのデータを受信」することを必要

とするのに対して、乙８－３発明ではクーポンのデータそのものは受信するものの、「『かざすクーポン』サービス機能」を登録するためのデータを受信することはない点

④ 本件発明は、「登録された前記サービスに関する情報」を特定するのに対

5 して、乙８－３発明ではこれに相当する構成の開示が存在しない点

⑤ 本件発明は、「生成された前記（サービスに関する）情報」で「管理手段

に管理されている前記（サービスに関する）情報を更新」（構成要件Ｃ）することを必要とするのに対して、乙８－３発明ではこれに相当する構成の開示が存在しない点

⑶ 新規性・進歩性を有すること

上記⑵のとおり、本件発明と乙８－３発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえしておらず、これら各相違点に係る構成が周知技術や設計事項であったことを示す証拠も提出していないし、まして、組合せの容易性についても何ら主張立証がない。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

３ 争点２－３（乙８－４発明に基づく新規性・進歩性欠如）について

（被告の主張）

⑴ 乙８－４発明の構成

乙８文献には、乙８－４発明に関し、次の構成が記載されている。ａ１４：「おサイフケータイ対応ｉアプリ」を記憶し、「おサイフケータイ対応ｉアプリ」で提供されるサービスに関する情報を管理する携帯電話に、ドコモショップの店頭などに設置されている専用の機器から受信した「おサイフケータイ対応ｉアプリ」で提供されるサービスを登録するためのデータを受信し、そのデータに基づき当該「おサイフケータイ対応ｉアプリ」で提供されるサービスを登録し、ｂ１４：登録された「おサイフケータイ対応ｉアプリ」で提供されるサービスに関する情報を、前記専用の機器から供給されるデータに基づいて生成し、

5 ｃ１４：生成された前記サービスに関する情報で、管理される情報を更新す

る、ｄ１４：ステップを含む処理を実行させるためのプログラム。

⑵ 新規性・進歩性の欠如

本件発明の構成は、乙８－４発明の構成と同一であるから、本件発明は新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

（原告の主張）

⑴ 乙８－４発明について

乙８－４発明に係る「おサイフケータイ対応ｉアプリ」は、様々なアプリの分類・総称にすぎず、「おサイフケータイ対応ｉアプリ」という名称のアプリが実体として存在するわけではない。また、個別のアプリ（「ｉＤアプリ」「モバイルＳｕｉｃａアプリ」「マクドナルド トクするアプリ」）についても、乙８－４発明で行われていることは、単にデータを新機種へと引き継ぐことであって、「ドコモショップの店頭などに設置されている専用の機器から」「サービスを登録するためのデータ」が受信されているわけではない。すなわち、乙８－４発明において、引継ぎを行う新機種ではアプリケーションがダウンロードされる際に当該アプリケーションが提供するサービス自体も含まれているから、別途、「サービスを登録するためのデータ」が受信されることもあり得ない。

⑵ 本件発明と乙８－４発明の相違点

上記⑴を踏まえ、本件発明と乙８－４発明とを対比すると、少なくとも、以下の点において相違する。

① 本件発明においては、「サービスを登録するためのデータを受信した場合

…サービスを登録」することが必要であるのに対し、乙８－４発明におい

5 ては、アプリケーションである「おサイフケータイ対応ｉアプリ」がサー

ビスに先行して記憶される構成が存在しない点

② 本件発明は「アプリケーションの処理により…サービスを登録」するも

のであるのに対して、乙８－４発明では、アプリケーションとサービスとは当初から一体化しており、「アプリケーションの処理により…サービスを登録」する構成が存在しない点

③ 本件発明は、「登録された前記サービスに関する情報」を特定するのに対

して、乙８－４発明ではこれに相当する構成の開示が存在しない点

④ 本件発明は、「生成された前記（サービスに関する）情報」で「管理手段

に管理されている前記（サービスに関する）情報を更新」（構成要件Ｃ）することを必要とするのに対して、乙８－４発明ではこれに相当する構成の開示が存在しない点

⑶ 新規性・進歩性を有すること

上記⑵のとおり、本件発明と乙８－４発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえしておらず、これら各相違点に係る構成が周知技術や設計事項であったことを示す証拠も提出していないし、まして、組合せの容易性についても何ら主張立証がない。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

４ 争点２－４（乙１１発明に基づく新規性・進歩性欠如）について

⑴ 乙１１発明の構成

乙１１文献には、乙１１発明に関し、次の構成が記載されている。ａ７：「モバイルＳｕｉｃａアプリ」を記憶するための記憶手段と、「モバイルＳｕｉｃａアプリ」で提供される「Ｓｕｉｃａ利用状況確認」、「ＳＦ（電子マネー）」、「定期券購入・変更・払戻」、「Ｓｕｉｃａグリーン

5 券購入・払戻」等のサービスに関する情報を管理するための管理手段

とを備える携帯電話に、サーバ等の他の装置から、「Ｓｕｉｃａ利用状況確認」、「ＳＦ（電子マネー）」、「定期券購入・変更・払戻」、「Ｓｕｉｃａグリーン券購入・払戻」等のサービスを登録するためのデータを受信した場合、そのデータに基づき、当該サービスを登録し、ｂ７：登録された「Ｓｕｉｃａ利用状況確認」、「ＳＦ（電子マネー）」、「定期券購入・変更・払戻」、「Ｓｕｉｃａグリーン券購入・払戻」等のサービスに関する新しい情報を、サーバ等の他の装置から供給されるデータに基づいて生成し、ｃ７：生成された前記サービスに関する新しい情報で、「Ｓｕｉｃａ利用状況確認」、「ＳＦ（電子マネー）」、「定期券購入・変更・払戻」、「Ｓｕｉｃａグリーン券購入・払戻」に関する情報を更新する（例えばＳｕｉｃａの利用履歴、チャージの残高、定期券の購入、Ｓｕｉｃａグリーン券の購入に関する情報を更新する）、ｄ７：ステップを含む処理を実行させるためのプログラム。

⑵ 新規性・進歩性の欠如

本件発明の構成は、乙１１発明の構成と同一であるから、本件発明は新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

⑶ 時機に後れた攻撃防御方法ではないこと

乙１１発明に基づく新規性・進歩性欠如の主張は、原告が撤回した訂正に基づいて行われたものであり、時機に後れた攻撃防御方法ではない。

（原告の主張）

⑴ 時機に後れた攻撃防御方法であること

被告は、

（原告の主張）

にかかわらず、乙１１発明に基づく無効理由を早期に提出できたはずであり、乙１１文献を検討しても特段被告がこれを早期に提出す

5 ることができなかった理由は見当たらない。仮にこれを審理するということに

なると、訴訟の完結を遅延させることは明らかであるから、乙１１発明に基づく無効理由は時機に後れたものとして却下されるべきである。

⑵ 乙１１発明について

乙１１発明は、「モバイルＳｕｉｃａアプリ」という単一のアプリケーションに、ダウンロード当初から「Ｓｕｉｃａ利用状況確認」「ＳＦ（電子マネー）」及び「定期券購入・変更・払戻」というＳｕｉｃａに関するサービスが含まれたものであって、アプリケーションとサービスは予め一体となっている。それゆえ、少なくとも、公然実施発明である、モバイルＳｕｉｃａアプリについては、「サーバ等の他の装置から、「Ｓｕｉｃａ利用状況確認」、「ＳＦ（電子マネー）」、「定期券購入・変更・払戻」、「Ｓｕｉｃａグリーン券購入・払戻」等のサービスを登録するためのデータを受信した場合、そのデータに基づき、当該サービスを登録し、」という構成を全く備えない点で相違するし、モバイルＳｕｉｃａアプリは、アプリがダウンロードされた当初からアプリケーションにサービスが備わったもの（アプリサービス一体型）であり、本件発明の特徴の一つである「サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録」に係る構成要件に相当する構成を備えない点でも相違する。

⑶ 新規性・進歩性を有すること

上記⑵のとおり、本件発明と乙１１発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえしておらず、これら各相違点に係る構成が周知技術や設計事項であったことを示す証拠も提出していないし、まして、組み合わせの容易性についても何ら主張立証がない。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

5 ５ 争点２－５（乙９発明に基づく新規性・進歩性欠如）について

（被告の主張）

乙９発明は、乙８－１、３及び４並びに乙１１発明の公然実施品に係る発明である。そのため、上記１ないし４のとおり、本件発明は、乙９発明として公然実施された発明であるから新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

（原告の主張）

否認ないし争う。上記１ないし４のとおり、本件発明と乙９発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえしておらず、これら各相違点に係る構成が周知技術や設計事項であったことを示す証拠も提出していないし、まして、組み合わせの容易性についても何ら主張立証がない。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

６ 争点２－６（乙１４発明に基づく新規性・進歩性欠如）について

⑴ 乙１４発明の構成

乙１４公報には、乙１４発明に関し、次の構成が記載されている。ａ３：電子マネーアプリを記憶し、電子マネーアプリで提供される電子マネーサービスに関する情報を管理する携帯端末に、サーバからダウンロードした電子マネーサービスを登録するためのデータを受信し、そのデータに基づき、電子マネーサービスを登録し、ｂ３：登録された電子マネーサービスに関する情報を、サーバから供給されるデータに基づいて生成し、ｃ３：生成された電子マネーサービスに関する情報で、管理される情報を更

5 新する、

ｄ３：ステップを含む処理を実行させるためのプログラム。

⑵ 新規性・進歩性の欠如

本件発明の構成は、乙１４発明の構成と同一であるから、本件発明は新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

（原告の主張）

⑴ 乙１４発明について

乙１４発明は、電子マネーアプリ１１１が携帯端末にダウンロードされた当初から、「アプリケーション」としての「電子マネーアプリ１１１」と、「サービス」としての「電子マネーサービス」とが一体化した発明であって、それぞれが別個に存在するものではない。そのため、乙１４発明において、「アプリケーションの処理により」「登録」される「サービス」が存在しない以上、乙１４発明は、「登録された前記サービスに関する情報を……生成」することを必要とする構成要件Ｂや、「生成された前記（登録されたサービスに関する）情報で、前記管理手段に管理されている前記情報を更新する」構成要件Ｃに相当するステップも存在し得ない。

⑵ 本件発明と乙１４発明の相違点

上記⑴を踏まえ、本件発明と乙１４発明とを対比すると、少なくとも、以下の点において相違する。

① 本件発明においては、「サービスを登録するためのデータを受信した場合

…サービスを登録」することが必要であるのに対し、乙１４発明においては、アプリケーションである「マネーアプリ」が「電子マネーサービス」に先行して記憶される構成が存在しない点

② 本件発明は「アプリケーションの処理により…サービスを登録」するも

のであるのに対して、乙１４発明は、アプリケーションとサービスとは当

5 初から一体化しており、「アプリケーションの処理により…サービスを登録」

する構成が存在しない点

③ 本件発明は、「登録された前記サービスに関する情報」を特定するのに対

して、乙１４発明ではこれに相当する構成の開示が存在しない点

④ 本件発明は、「生成された前記サービスに関する情報」で「管理手段に管

理されている前記（サービスに関する）情報を更新」（構成要件Ｃ）することを必要とするのに対して、乙１４発明のモバイルバンキングは本件発明における「サービス」に該当せず、それゆえ、モバイルバンキングの選択は、サービスに関する情報の生成にもサービスに関する情報の「更新」にも該当しない点

⑶ 新規性・進歩性を有すること

上記⑵のとおり、本件発明と乙１４発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえしておらず、これら各相違点に係る構成が周知技術や設計事項であったことを示す証拠も提出していないし、まして、組合せの容易性についても何ら主張立証がない。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

７ 争点２－７（乙１５発明に基づく新規性・進歩性欠如）について

（被告の主張）

⑴ 乙１５発明の構成

乙１５公報には、乙１５発明に関し、次の構成が記載されている。ａ４：電子決済システム１によるサービスを受けるための移動体通信端末２０用ソフトウェア（以下「電子決済用アプリ」という。）を記憶し、電子決済用アプリで提供される支払・決済サービス、振替サービス及び電子契約申請サービスに関する情報を管理する移動体通信端末２０に、

5 サーバから支払・決済サービス、振替サービス及び電子契約申請サー

ビスを登録するためのデータを受信し、そのデータに基づき、電子決済用アプリの処理により前記サービスを登録し、ｂ４：登録された前記サービスに関する情報を、サーバから供給されるデータに基づいて生成し、ｃ４：生成された前記サービスに関する情報で、管理される情報を更新する、ｄ４：ステップを含む処理を実行させるためのプログラム。

⑵ 新規性・進歩性の欠如

本件発明の構成は、乙１５発明の構成と同一であるから、本件発明は新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

（原告の主張）

⑴ 乙１５発明について

乙１５発明は、アプリケーション（「移動体通信端末２０用ソフトウェア」）及びサービス（「支払」）が一体となった発明であり、本件発明のように「サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録」する構成は存在しない。そのため、乙１５発明は、本件発明のような「他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録」という処理を実行するものではないし、「サービスに関する情報」が「生成」（構成要件Ｂ）されることもなく、「生成された前記（サービスに関する）情報で、前記管理手段に管理されている前記情報を更新する」（構成要件Ｃ参照）に相当する構成も存在しない。

⑵ 本件発明と乙１５発明の相違点

上記⑴を踏まえ、本件発明と乙１５発明とを対比すると、少なくとも、以下の点において相違する。

5 ① 本件発明においては、「サービスを登録するためのデータを受信した場合

…サービスを登録」することが必要であるのに対し、乙１５発明においては、アプリケーションである「電子決済用アプリ」が「サービス」に先行して記憶される構成が存在しない点

② 本件発明は「アプリケーションの処理により…サービスを登録」するも

のであるのに対して、乙１５発明では、アプリケーションとサービスが当初から一体になっており、サービスは登録されず、「アプリケーションの処理により…サービスを登録」する構成が存在しない点

③ 本件発明は、「登録された前記サービスに関する情報」を特定するのに対

して、乙１５発明ではこれに相当する構成の開示が存在しない点

④ 本件発明は、「生成された前記（サービスに関する）情報」で「管理手段

に管理されている前記（サービスに関する）情報を更新」（構成要件Ｃ）することを必要とするのに対して、乙１５発明ではこれに相当する構成の開示が存在しない点

⑶ 新規性・進歩性を有すること

上記⑵のとおり、本件発明と乙１５発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえしておらず、これら各相違点に係る構成が周知技術や設計事項であったことを示す証拠も提出していないし、まして、組合せの容易性についても何ら主張立証がない。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

８ 争点２－８（乙１６発明に基づく新規性・進歩性欠如）について

（被告の主張）

⑴ 乙１６発明の構成

乙１６公報には、乙１６発明に関し、次の構成が記載されている。

5 ａ４：音楽に関するソフトウェアアプリケーションを記憶し、前記音楽に関

するソフトウェアアプリケーションで提供される音楽コンテンツの提供サービスに関する情報を管理する携帯無線コンピューティング装置に、リモートサーバから音楽コンテンツの提供サービスを登録するためのデータを受信し、そのデータに基づき、前記音楽に関するソフトウェアアプリケーションの処理により前記サービスを登録し、ｂ４：登録された音楽コンテンツの提供サービスに関する情報を、リモートサーバから供給されるデータに基づいて生成し、ｃ４：生成された音楽コンテンツの提供サービスに関する情報で、管理される情報を更新する、ｄ４：ステップを含む処理を実行させるためのプログラム。

⑵ 新規性・進歩性の欠如

本件発明の構成は、乙１６発明の構成と同一であるから、本件発明は新規性を欠く。仮に相違点があるとしても些細なものであり、本件発明は進歩性を有しない。

（原告の主張）

⑴ 乙１６発明について

乙１６発明は、アプリケーションＭｕｓｉｃＳｔａｔｉｏｎ及び音楽の再生機能等の「サービス」が当初から一体となったソフトウェアであり、本件発明のように「サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録（する）」という構成をそもそも備えない。また、乙１６発明でダウンロードされることになるのは、「音楽コンテンツ」という音楽データそのものであって、本件発明のように「サービスを登録するためのデータ」が受信されるわけではない。

⑵ 本件発明と乙１６発明の相違点

5 上記⑴を踏まえ、本件発明と乙１６発明とを対比すると、少なくとも、以下

の点において相違する。

① 本件発明においては、「サービスを登録するためのデータを受信した場合

…サービスを登録」することが必要であるのに対し、乙１６発明においては、アプリケーションである「ＭｕｓｉｃＳｔａｔｉｏｎ」が「サービス」である「音楽コンテンツの提供サービス」に先行して記憶される構成が存在しない点

② 本件発明は「アプリケーションの処理により…サービスを登録」するも

のであるのに対して、乙１６発明では、アプリケーションとサービスが当初から一体になっており、サービスは「登録」されず、「アプリケーションの処理により…サービスを登録」する構成が存在しない点

③ 本件発明は、「サービスを登録するためのデータを受信」することを必要

とするのに対して、乙１６発明では音楽コンテンツデータそのものは受信するものの、「音楽コンテンツの提供サービスを登録するためのデータ」を受信することはない点

④ 本件発明は、「登録された前記サービスに関する情報」を特定するのに対

して、乙１６発明ではこれに相当する構成の開示が存在しない点

⑤ 本件発明は、「生成された前記（サービスに関する）情報」で「管理手段

に管理されている前記（サービスに関する）情報を更新」（構成要件Ｃ）することを必要とするのに対して、乙１６発明ではこれに相当する構成の開示が存在しない点

⑶ 新規性・進歩性を有すること

上記⑵のとおり、本件発明と乙１６発明との間には、実質的相違点が存在することから新規性を欠く旨の

（被告の主張）

には理由がない。また、被告は、上記各相違点を開示した副引例を証拠として提出さえしておらず、これら各相違点に係る構成が周知技術や設計事項であったことを示す証

5 拠も提出していないし、まして、組合せの容易性についても何ら主張立証がな

い。そうすると、各相違点の内容に具体的に入り込むまでもなく、被告による進歩性違反の主張には理由がない。

９ 争点２－９（サポート要件違反）について

（被告の主張）

⑴ 本件明細書【００１７】で「本発明は、このような状況に鑑みてなされたも

のであり、例えば、ＵＩＣＣなどの所定の情報を管理する装置内の情報を、その情報を閲覧するためのビューワで正確に閲覧できるようにし、かつそのための更新を既存のインフラを用いて行えるようにするものである。」と記載されていることからして、「その情報を閲覧するためのビューワで正確に閲覧できる」ことは解決すべき必須の課題である。これに対し、原告は本件発明において、「ビューワ」は関係がないと主張しており、

（原告の主張）

を前提とすると、本件発明は当業者が当該発明の課題を解決することができると認識可能な範囲のものとなっておらず、サポート要件に違反する。

⑵ 本件発明の「サービス」は、アプリケーションに含まれるサービスを意味し

ているところ、仮に原告が主張するように、本件発明が「支払サービス（クレジットカード払い及びｄ払いサービスを含む）」をＧＯアプリに連携させることで利用可能とする態様を、その技術的範囲に含むというのであれば、発明の詳細な説明に記載されていない発明にまで、本件発明の技術的範囲を拡張することになる。また、「所定の情報を管理する装置内の情報を、その情報を閲覧するためのビューワで正確に閲覧できる」という本件発明が解決しようとする課題とは全く関係のない態様にまで権利範囲を拡張することになる。そのため、本件発明はサポート要件に違反する。

⑶ 本件明細書【００８５】で「リーダライタ２０２からＣＬＦ２２４を経由し

て、ＵＩＣＣ２２２にサービス登録データ４３１を渡すことが出来る。」ことが

5 示されており、ユーザが「セキュリティコード」等を入力すること等は全く想

定されていない。これに対し、原告は、「同意する」という選択を行った後で送られてくる「セキュリティコード」をユーザが入力してログインし、さらにＮＴＴ ＤｏＣｏＭｏのｓｐモードパスワードを入力することが必要となっており、ユーザが適宜操作を行うことで、「セキュリティコード」を取得しかつ入力し、さらにｓｐモードパスワードを入力する態様となっているにもかかわらず、本件発明の構成要件Ａを充足すると主張し、また、既に登録されているサービスに対して、ユーザの操作を用いて支払方法の情報を変更する態様や支払方法の情報を削除する態様についても、構成要件Ｃを充足すると主張する。このような原告の解釈は、ユーザの操作を介入するとは解釈することができない「前記アプリケーションの処理により前記サービスを登録する」や、「生成された前記情報で、前記管理手段に管理されている前記情報を更新する」という用語を不当に拡張して解釈するものであって、「特許請求の範囲に記載された発明が、発明の詳細な説明に記載された発明」にまで技術的範囲を拡張するものである。そのため、本件発明はサポート要件に違反する。

⑷ 本件発明の解決すべき課題の記載、本件明細書【００３８】において「サー

ビスに関する情報」として「アプリケーションが提供するサービスの名称やサービス種別といったサービスに関する情報」と記載され、サービス名やサービス種別以外に「サービスに関する情報」が示されていないことからして、構成要件Ｂの「前記サービスに関する情報」及び構成要件Ｃの「生成された前記情報」は、アプリケーションに含まれるサービスを認識することができる情報である必要があり、本件明細書で示されるように「サービス名やサービス種別」である必要があり、それ以上に拡張することができるものではない。そのため、構成要件Ｂの「前記サービスに関する情報」及び構成要件Ｃの

5 「生成された前記情報」が限定されていない本件発明はサポート要件に違反す

る。

⑸ 構成要件Ａ及びＢではサービスに関する情報を管理する管理手段を備える情

報処理装置が、他の装置から、当該同じサービスを登録するためのデータを受信した場合、そのデータに基づき、当該同じサービスを登録することが要件となっている。本件明細書【００８０】ないし【００９１】、【００３６】、【０３０８】及び図３２では、サービスに関する情報を管理する管理手段を備える情報処理装置が、他の装置から、当該同じサービスを登録するためのデータを受信した場合、そのデータに基づき、当該同じサービスを登録することは全く記載されていないことから、構成要件Ａ及びＢの「前記サービス」はサポートされていない。

（原告の主張）

⑴ 本件発明は、【００１７】に開示されるとおり、「生成された…情報で、前記

管理手段に管理されている前記情報を更新する」ことを、その技術的特徴と捉えて特許としたものであり、被告が主張するような「ビューワ」を課題解決のために必須とするものではない。そして、当業者は、本件発明によって、本件明細書に記載された「更新を既存のインフラを用いて行えるようにする」という課題解決を認識することができるのであるから、特許請求の範囲はサポートされている。

⑵ 本件発明において、アプリケーションにサービスが「登録」された上で、こ

れをユーザに「提供」するに当たっては、例えばクレジットカードサービスのクレジットサーバの場合を考えても明らかなとおり、第三者（サービスプロバイダー） との「連携」が当然必要となる。本件明細書はこのような場合を当然に想定しているものであり、

（被告の主張）

は誤りである。

⑶ 本件明細書は、「前記アプリケーションの処理により前記サービスを登録する」

処理が行われる契機がユーザの操作であるのか、あるいは、プログラムの動作

5 によるものであるかを限定したものではないから、「想定されて」いるかどうか

を問題とする

（被告の主張）

に理由はない。

⑷ 本件明細書【００３８】では、「レジストリ２５３は、アプリケーションが提

供するサービスの名称やサービス種別といったサービスに関する情報を管理する。」として、「サービスに関する情報」を「サービス名」や「サービス種別」に限定しないことを明確にしている。そもそも、特許明細書に記載される例は、あくまで発明の実施例であり、特許発明の技術的範囲がこれに限定されるわけではなく、技術的範囲は原則として特許請求の範囲に基づき定められるものであって、

（被告の主張）

は、典型的な実施例限定解釈であることからしても誤りである。

⑸ 構成要件Ａの前段に特定される「サービス」は、情報処理装置の管理手段が

持つ機能の説明をするために特定されているのであり、情報処理装置の管理手段がかかる機能を客観的に有するか、という観点で、対比される構成であり、構成要件Ａの後段における「他の装置から、前記サービスを登録するためのデータを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、」との特定は、具体的なサービスを登録する処理について規定されているものであり、構成要件Ａの後段の「サービス」は、具体的なサービスと対比されるべきものであることが理解できる。そのため、当業者であれば、本件発明において特定された技術的内容から、構成要件Ａの後段における具体的な「サービス」が、構成要件Ａの前段における情報処理装置の管理手段が持つ機能を説明するための「サービス」と一致する必要はないことを理解することができる。そして、構成要件Ｂにおいて特定される「サービス」も、具体的な「サービス」に関する情報を生成する処理について規定されているものであるから、構成要件Ａの前段における「サービス」と一致する必要はないことを理解することができる。以上（別紙）図面目録図１図２図３図４図５図６図９図１２図１３図１４図１５図３３図３４以上