令和６年１２月１２日判決言渡同日原本領収裁判所書記官令和５年（ワ）第７０４２５号特許権侵害差止等請求事件口頭弁論終結日令和６年９月３０日判決 原告 Ｓ．ＲＩＤＥ株式会社同訴訟代理人弁護士 𠮷田和彦同奥村直樹同岸 慶憲同訴訟代理人弁理士工藤嘉晃 同補佐人弁理士林 陽和被告 ＧＯ株式会社同訴訟代理人弁護士大野浩之同多田宏文 主文 １ 原告の請求をいずれも棄却する。 ２ 訴訟費用は原告の負担とする。 事実及び理由 第１ 請求 １ 被告は、別紙被告プログラム目録記載のプログラムを作成し、使用し、譲渡 等（譲渡、貸渡し、電気通信回線を通じた提供をいう。）し、譲渡等の申出をしてはならない。 ２ 被告は、別紙被告プログラム目録記載のプログラムを抹消せよ。 第２ 事案の概要原告は、別紙特許権目録記載の特許（以下「本件特許」といい、本件特許に 係る特許権を「本件特許権」という。また、本件特許の願書に添付された明細 書を「本件明細書」といい、本件明細書及び図面を併せて「本件明細書等」という。）を保有している。 本件は、原告が、別紙被告プログラム目録記載のプログラム（以下「被告プログラム」という。）を作成、使用、譲渡等する被告に対し、当該作成等の行為が本件特許権の侵害を構成するとして、特許法１００条１項に基づき被告プ ログラムの製造販売行為等の差止めを求めるとともに、同条２項 」という。）を作成、使用、譲渡等する被告に対し、当該作成等の行為が本件特許権の侵害を構成するとして、特許法１００条１項に基づき被告プ ログラムの製造販売行為等の差止めを求めるとともに、同条２項に基づき被告プログラムの廃棄を求める事案である。 １ 前提事実（当事者間に争いのない事実並びに後掲各証拠〔枝番の記載は特に付記する場合を除き省略する。〕及び弁論の全趣旨により容易に認められる事実をいう。） ⑴ 当事者原告は、一般乗用旅客自動車運送事業者等に向けた配車ソフトウェア・システムの企画、開発、設計、製造、販売、賃貸及び運営等を行う株式会社である（弁論の全趣旨）。 被告は、インターネットを利用したサービス、システム及びアプリケーシ ョン企画、開発、運用、導入に関するコンサルティング及び保守サービス業務等を目的とする株式会社である。 ⑵ 原告の特許権（甲１、２）原告は、本件特許権を有している。 ⑶ 本件特許に係る特許請求の範囲（甲２） 本件特許の特許請求の範囲の請求項８の記載は、次のとおりである（以下、請求項８に記載された発明を「本件発明」という。）。 コンピュータに、所定のアプリケーションを記憶し、前記アプリケーションで提供されるサービスに関する情報を管理し、 他の装置から受信した前記サービスを登録するためのデータを取得し、 取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録し、登録された前記サービスに関する情報を生成し、前記アプリケーションによりコマンドが処理されることで生成される前記サービスに関する情報の表示を制御する ステップを含む処理を実行させるためのプログラム。 ⑷ 本件発明の構成要件本件発明を構成要件に分説すると、 りコマンドが処理されることで生成される前記サービスに関する情報の表示を制御する ステップを含む処理を実行させるためのプログラム。 ⑷ 本件発明の構成要件本件発明を構成要件に分説すると、次のとおりである。 Ａ：コンピュータに、所定のアプリケーションを記憶し、Ｂ：前記アプリケーションで提供されるサービスに関する情報を管理し、 Ｃ：他の装置から受信した前記サービスを登録するためのデータを取得し、Ｄ：取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録し、Ｅ：登録された前記サービスに関する情報を生成し、Ｆ：前記アプリケーションによりコマンドが処理されることで生成される前 記サービスに関する情報の表示を制御するＧ：ステップを含む処理を実行させるためのプログラム。 ⑸ 被告の行為及び被告プログラムの構成（甲３、４、弁論の全趣旨）被告は、被告プログラムを作成し、電気通信を通じた提供をしており、被告プログラムは、本件発明の構成要件Ａを充足する。 ⑹ 先行文献本件特許の出願日より前に、以下の刊行物が存在した。 ア平成２１年（２００９年）１月２４日に販売開始されたＦＯＭＡ端末docomoＰＲＩＭＥseriesＦ－０３Ａの取扱説明書（乙１。以下「乙１文献」といい、これに記載された発明のうち、ｉＤアプリに関するものを「乙１ －１発明」、モバイルＳｕｉｃａ登録用ｉアプリに関するものを「乙１－ ２発明」、マクドナルドトクするアプリに関するものを「乙１－３発明」、おサイフケータイに関するものを「乙１－４発明」という。上記「docomoＰＲＩＭＥseriesＦ－０３Ａ」につき乙２参照）イ発明の名称「電子マネーシステム、および、サービス提供用サーバ」に関する特開 ケータイに関するものを「乙１－４発明」という。上記「docomoＰＲＩＭＥseriesＦ－０３Ａ」につき乙２参照）イ発明の名称「電子マネーシステム、および、サービス提供用サーバ」に関する特開２００７－１７９２５８号（乙７。以下「乙７公報」といい、 これに記載された発明を「乙７発明」という。）ウ発明の名称「電子決済システム、電子決済サーバ、移動体通信端末、並びに電子決済方法」に関する特開２００８－２９３４９１号（乙８。以下「乙８公報」といい、これに記載された発明を「乙８発明」という。）エ発明の名称「デジタル音楽コンテンツを携帯無線コンピューティング装 置にダウンロードし且つ使用することを可能にする方法」に関する特表２００９－５３６４８２号（乙９。以下「乙９公報」といい、これに記載された発明を「乙９発明」という。） ２ 争点なお、原告は、訂正の再抗弁を主張していたものの、令和６年５月２３日付 けで訂正審判請求を取り下げたため、訂正後の発明に係る主張は全て撤回した（第３回弁論準備手続調書参照）。 ⑴ 構成要件充足性（争点１）ア 「前記アプリケーションで提供されるサービス」（構成要件Ｂ）の充足性（争点１－１） イ 「前記サービスを登録」（構成要件Ｃ）、「前記サービスを登録」（構成要件Ｄ）、「前記サービスに関する情報を生成」（構成要件Ｅ）、「生成される前記サービス」（構成要件Ｆ）、「ステップを含む」（構成要件Ｇ）の充足性（争点１－２）ウ 「前記サービスを登録するためのデータ」（構成要件Ｃ）の充足性（争 点１－３） エ 「前記アプリケーションの処理により」（構成要件Ｄ）の充足性（争点１－４）オ 「前記サービスに関する情報」（構成要件Ｅ、Ｆ）の充足性（争点１－５）⑵ （争 点１－３） エ 「前記アプリケーションの処理により」（構成要件Ｄ）の充足性（争点１－４）オ 「前記サービスに関する情報」（構成要件Ｅ、Ｆ）の充足性（争点１－５）⑵ 無効理由の有無（争点２） ア乙１文献に基づく無効理由（争点２－１）乙１－１発明に基づく新規性、進歩性の有無（争点２－１－１）乙１－２発明に基づく新規性、進歩性の有無（争点２－１－２）乙１－３発明に基づく新規性、進歩性の有無（争点２－１－３）乙１－４発明に基づく新規性、進歩性の有無（争点２－１－４） イ公然実施の有無（争点２－２）ウ乙７発明を主引例とする新規性、進歩性の有無（争点２－３）エ乙８発明を主引例とする新規性、進歩性の有無（争点２－４）オ乙９発明を主引例とする新規性、進歩性の有無（争点２－５）カサポート要件違反の有無（争点２－６） 第３ 争点に対する当事者の主張 １ 争点１－１（「前記アプリケーションで提供されるサービス」〔構成要件Ｂ〕の充足性）について（原告の主張）⑴ 被告プログラムの構成 被告プログラムは、別紙「被告プログラム説明書（原告の主張）」記載の１⑴Ｂ'又は２⑴Ｂ''の構成を有する。 ⑵ 「前記アプリケーションで提供されるサービス」（構成要件Ｂ）の充足性被告プログラムは「アプリケーション」に相当し、被告プログラムにおいてＧｏＰａｙに登録され、ユーザの用に供される支払サービスであるｄ払い は「サービス」に相当する。したがって、被告プログラムは、構成要件Ｂの 「前記アプリケーションで提供されるサービス」を充足する。 これに対し、被告は、本件発明における「サービス」とは、アプリケーションに含まれるサービスを意味する旨主張する。しかし 成要件Ｂの 「前記アプリケーションで提供されるサービス」を充足する。 これに対し、被告は、本件発明における「サービス」とは、アプリケーションに含まれるサービスを意味する旨主張する。しかしながら、本件発明の特許請求の範囲の文言上、「提供されるサービス」と記載され、「サービス」の提供主体と「アプリケーション」の提供主体とが法的に同一でなければな らないという限定はない。また、本件明細書等（【００３０】）の記載によると、各サービスが様々な主体によって提供されるものであることは、当業者のみならず一般人にとっても技術常識に属する事項である。以上によると、本件発明における「前記アプリケーションで提供されるサービス」とは、アプリケーションと各サービスが異なる法的主体によって提供される場合も当 然に含まれるものである。 （被告の主張） ⑴ 「前記アプリケーションで提供されるサービス」の意義本件明細書（【００１４】）の記載によれば、本件発明における「サービス」とは、アプリケーションに含まれるサービスを意味すると解するべきで ある。 これに対し、原告は、アプリケーションとサービスが異なる法的主体によって提供される場合も含まれる旨主張する。しかしながら、本件明細書（【００１７】）の記載によれば、本件発明は、「ＵＩＣＣなどの所定の情報を管理する装置内の情報を、その情報を閲覧するためのビューワで正確に閲覧で きるようにする」ことを、解決すべき必須の課題としている。上記のような課題が発生するには、上記の「サービス」はアプリケーションに含まれることが必要というべきである。 ⑵ 被告プログラムが構成要件を充足しないことｄ払いは、株式会社ＮＴＴドコモ（以下「訴外ドコモ」という。）が独自 に提供する支払サービスであ ションに含まれることが必要というべきである。 ⑵ 被告プログラムが構成要件を充足しないことｄ払いは、株式会社ＮＴＴドコモ（以下「訴外ドコモ」という。）が独自 に提供する支払サービスであり、被告プログラムに連携されて初めて利用可 能になるものである。そのため、被告プログラムが提供するサービスではないし、被告プログラムに含まれるサービスでもない。したがって、被告プログラムは、構成要件Ｂの「前記アプリケーションで提供されるサービス」を充足しない。なお、これは、原告が並列的に主張する携帯電話の機種変更時の態様（別紙「被告プログラム説明書（原告の主張）」記載２⑴参照）であ っても同様である。 ２ 争点１－２（「前記サービスを登録」〔構成要件Ｃ〕、「前記サービスを登録」〔構成要件Ｄ〕、「前記サービスに関する情報を生成」〔構成要件Ｅ〕、「生成される前記サービス」〔構成要件Ｆ〕、「ステップを含む」〔構成要件Ｇ〕の充足性）について （原告の主張）被告プログラムは、別紙「被告プログラム説明書（原告の主張）」記載１⑴Ｃ'ないしＧ'又は２⑴Ｃ''ないしＧ''の構成を有する。 別紙「被告プログラム説明書（原告の主張）」記載の写真１２のとおり、被告プログラムにおいては、ｄ払いが「支払い方法一覧」に記され、ｄ払いの提 供が実現可能となっているから、ｄ払いが「登録」されているといえる。したがって、これを前提とした本件発明の構成要件ＣないしＧを充足する。 （被告の主張）本件明細書等（【００８９】ないし【００９１】、【０２４１】ないし【０２４５】、【０２４８】、【０２５１】ないし【０２５４】、【０２５７】、 【０２５８】、【０３０２】、【０３０３】、【０３２０】ないし【０３２３】）の記載を踏まえると、本件発明につい いし【０２４５】、【０２４８】、【０２５１】ないし【０２５４】、【０２５７】、 【０２５８】、【０３０２】、【０３０３】、【０３２０】ないし【０３２３】）の記載を踏まえると、本件発明については、（ⅰ）アプリケーションの処理によりサービスの登録を行い、（ⅱ）続いてアプリケーションによりコマンドが処理されることで生成されるサービスに関する情報であるサービス名を生成し、（ⅲ）当該サービスに関する情報であるサービス名の表示を制御すること が記載されている。これらの記載を考慮すると、①他の装置から受信した「前 記サービスを登録」（構成要件Ｃ）するためのデータを取得し、②取得された前記データに基づき、前記アプリケーションの処理により「前記サービスを登録」（構成要件Ｄ）し、③登録された「前記サービスに関する情報を生成」（構成要件Ｅ）し、④前記アプリケーションによりコマンドが処理されることで「生成される前記サービス」（構成要件Ｆ）に関する情報の表示を制御するという 一連の「ステップを含む処理」（構成要件Ｇ）が解釈される必要がある。 しかしながら、被告プログラムにおいては、ｄ払いが被告プログラムに連携されるだけであり、サービスを登録した上で、当該サービスに関する情報を生成するようなことは行っていない。したがって、上記の一連の処理は行われておらず、被告プログラムは構成要件ＣないしＧを充足しない。 ３ 争点１－３（「前記サービスを登録するためのデータ」〔構成要件Ｃ〕の充足性）について（原告の主張）⑴ 被告プログラムの構成被告プログラムは、別紙「被告プログラム説明書（原告の主張）」記載の １⑴Ｃ'又は２⑴Ｃ''の構成を有する。 ⑵ 「前記サービスを登録するためのデータ」（構成要件Ｃ）の充足性被告プログラ 被告プログラムは、別紙「被告プログラム説明書（原告の主張）」記載の １⑴Ｃ'又は２⑴Ｃ''の構成を有する。 ⑵ 「前記サービスを登録するためのデータ」（構成要件Ｃ）の充足性被告プログラムにおいて、ｄ払い用サーバから受信したｄ払いを登録するためのデータ（セキュリティコード又は承諾番号若しくは両者）は、「他の装置から受信した前記サービスを登録するためのデータ」に相当する。した がって、被告プログラムは、構成要件Ｃを充足する。 これに対し、被告は、機種変更時の態様（前記２⑴Ｃ''の構成）について、「他の装置から受信」しているのは被告プログラムを登録するためのデータであり、ｄ払いを登録するためのデータではない旨主張する。しかしながら、原告は、機種変更前のスマートフォンにおいて、上記のデータを取得する構 成（別紙「被告プログラム説明書（原告の主張）」記載２⑵の写真７、８及 び１１参照）を被告プログラムの構成（２⑴Ｃ''）として特定するものであるから、被告の上記主張は当たらない。 （被告の主張）原告は、別紙「被告プログラム説明書（原告の主張）」記載２⑴において、スマートフォンの機種変更を行ったときに被告プログラムのデータを引き継 いで登録する際の構成を示しているが、このような態様において、被告プログラムが他の装置から受信しているのは、被告プログラムを登録するためのデータにすぎず、原告が「サービス」に相当すると主張するｄ払いを登録するためのデータではない。よって、上記の構成では、構成要件Ｃを充足しない。 ４ 争点１－４（「前記アプリケーションの処理により」〔構成要件Ｄ〕の充足性）について（原告の主張）⑴ 被告プログラムの構成被告プログラムは、別紙「被告プログラム説明書（原告の主張）」記載 ４ 争点１－４（「前記アプリケーションの処理により」〔構成要件Ｄ〕の充足性）について（原告の主張）⑴ 被告プログラムの構成被告プログラムは、別紙「被告プログラム説明書（原告の主張）」記載の １⑴Ｄ'又は２⑴Ｄ''の構成を有する。 ⑵ 「前記アプリケーションの処理により」（構成要件Ｄ）の充足性前記３のとおり、被告プログラムにおいて、ｄ払い用サーバから受信したｄ払いを登録するためのデータ（セキュリティコード又は承諾番号若しくは両者）は、「取得された前記データ」（構成要件Ｄ）に相当する。また、被 告プログラムは、上記データに基づいてｄ払いを登録するための処理を実行するから、「前記アプリケーションの処理により」（構成要件Ｄ）を充足する。したがって、被告プログラムは構成要件Ｄを充足する。 これに対し、被告は、被告プログラムにおいては、被告プログラムの処理によってセキュリティコードが入力されるわけではないから、「前記アプリ ケーションの処理により」を充足しない旨主張する。しかしながら、本件発 明の特許請求の範囲は、ユーザによる操作の有無について限定を課していないから、仮にユーザの操作が介在したとしても「取得された前記データに基づき・・・前記サービスを登録」する以上、構成要件Ｄを充足する。 また、被告は、承諾番号はｄ払いを登録するために必要な情報ではない旨主張する。しかしながら、被告プログラムにおいては、別紙「被告プログラ ム説明書（原告の主張）」記載１⑵の写真１１のとおり、ユーザの操作を経ることなく「承諾番号」が自動的に入力され、ユーザによる「次へ」ボタンの押下を待つことなく、自動的に次の画面に遷移される。また、被告プログラムにおいては、承諾番号がなければｄ払いを利用できず、そもそも登録もできない 号」が自動的に入力され、ユーザによる「次へ」ボタンの押下を待つことなく、自動的に次の画面に遷移される。また、被告プログラムにおいては、承諾番号がなければｄ払いを利用できず、そもそも登録もできない（別紙「被告プログラム説明書（原告の主張）」記載１⑵の写真１ ０ないし１２参照）。したがって、被告の上記主張は誤りである。 さらに、被告は、機種変更時の態様（別紙「被告プログラム説明書（原告の主張）」記載２⑴Ｄ''）について、被告プログラムを登録するための処理を述べるものであり、ｄ払いを登録するための処理が述べられているものではない旨主張するが、前記３のとおり、反論は当たらない。 （被告の主張）⑴ 被告プログラムにおいては、別紙「被告プログラム説明書（原告の主張）」記載１⑵の写真６ないし１１のとおり、ユーザの操作によってセキュリティコードが入力されている。また、承諾番号についても、その発行に際してｓｐモードパスワードの入力というユーザの操作を要する（同記載写真１０）。 そうすると、セキュリティコードも承諾番号もユーザの操作を要するから、被告プログラムの処理によって入力されるものではない。 また、セキュリティコードの受信から入力までのやりとり（２段階認証）及びｓｐモードパスワードの入力から承諾番号の取得までのやりとりは、ユーザと訴外ドコモのシステムとの間で直接行われており、被告プログラムを 利用した処理によって行われているものではない。 以上のとおり、被告プログラムは、「前記アプリケーションの処理により」（構成要件Ｄ）を充足しない。 なお、原告は、承諾番号が「前記データ」（構成要件Ｄ）に相当する旨主張するが、承諾番号は承諾されたことを示す情報であり、ｄ払いを登録するために必要な情報ではない。 成要件Ｄ）を充足しない。 なお、原告は、承諾番号が「前記データ」（構成要件Ｄ）に相当する旨主張するが、承諾番号は承諾されたことを示す情報であり、ｄ払いを登録するために必要な情報ではない。 これに対し、原告は、本件発明の特許請求の範囲は、ユーザによる操作の有無について限定を課しているわけではないなどと主張するが、本件明細書等には、ユーザの操作が介入することをもって「前記アプリケーションの処理により前記サービスを登録する」ことは全く示されていないし、むしろ、本件明細書（【００７９】）の記載を踏まえると、ユーザが登録データを入 力することは想定されていない。 ⑵ 前記３のとおり、原告は、別紙「被告プログラム説明書（原告の主張）」記載２⑴において、スマートフォンの機種変更を行ったときに被告プログラムのデータを引き継いで登録する際の構成を示しているが、このような態様において、被告プログラムが他の装置から受信しているのは、被告プログラ ムを登録するためのデータにすぎず、ｄ払いを登録するためのデータではない。したがって、上記の構成では、構成要件Ｄを充足しない。 ５ 争点１－５（「前記サービスに関する情報」〔構成要件Ｅ、Ｆ〕の充足性）について（原告の主張） 被告プログラムは、別紙「被告プログラム説明書（原告の主張）」記載の１⑴Ｅ'及びＦ'又は２⑴Ｅ''及びＦ''の各構成を有する。これらは、本件発明の構成要件Ｅ，Ｆを充足する。 （被告の主張）出願人により審査時に提出された意見書（乙１１）を踏まえると、「サービ スに関する情報」（構成要件Ｅ及びＦ）とは、アプリケーションによりコマン ドが処理されることで生成されるものを意味すると解釈すべきである。 被告プログラムにおいては、前記４⑴のとおり、セキュ に関する情報」（構成要件Ｅ及びＦ）とは、アプリケーションによりコマン ドが処理されることで生成されるものを意味すると解釈すべきである。 被告プログラムにおいては、前記４⑴のとおり、セキュリティコードの受信から入力までのやり取り（２段階認証）及びｓｐモードパスワードの入力から承諾番号の取得までのやり取りは、ユーザと訴外ドコモのシステムとの間で直接行われており、被告プログラムがコマンドを処理することで情報が生成され るものではない（乙１３）。よって、被告プログラムは、構成要件Ｅ及びＦを充足しない。 これに対し、原告は、各画面遷移が、被告プログラムにおけるコマンド処理によって実現されている旨主張するが、ｄ払いに関する情報が、被告プログラムによりコマンドが処理されることで生成されるという点については、主張立 証がなく、本件明細書等の記載を踏まえても採用できない。 ６ 争点２－１－１（乙１－１発明に基づく新規性、進歩性の有無）について（被告の主張）⑴ 主位的主張ア引用発明について 乙１文献には、乙１－１発明に関して、次の構成が記載されている。 ａ１１：携帯電話に、「ｉアプリ」を記憶し、ｂ１１：「ｉアプリ」で提供される「ｉＤアプリ」における「カードアプリ」に関する情報を管理し、ｃ１１：サーバからダウンロードした「カードアプリ」を登録するための データを取得し、ｄ１１：取得されたデータに基づき、「カードアプリ」を登録し、ｅ１１：登録された「カードアプリ」に関する情報を生成し、ｆ１１：「i アプリ」によりコマンドが処理されることで生成される「カードアプリ」に関する情報の表示を制御する ｇ１１：ステップを含む処理を実行させるためのプログラム。 イ新規性の欠如 アプリ」によりコマンドが処理されることで生成される「カードアプリ」に関する情報の表示を制御する ｇ１１：ステップを含む処理を実行させるためのプログラム。 イ新規性の欠如本件発明の構成は、乙１－１発明の構成と同一であるから、本件発明は新規性を欠く。 ⑵ 予備的主張ア主引例について ｉアプリという名称の特定のアプリケーションは存在しないという原告の主張を前提としても、乙１文献によれば、乙１－１発明に関して、次の構成が記載されている。 ａ１１’：携帯電話に、「ｉＤアプリ」を記憶し、ｂ１１’：「ｉＤアプリ」を用いて提供されるカードでの支払サービスに 関する情報を管理し、ｃ１１’：サーバからダウンロードしたカードでの支払サービスを登録するためのデータを取得し、ｄ１１’：取得されたデータに基づき、カードでの支払サービスを登録し、ｅ１１’：登録されたカードでの支払サービスに関する情報を生成する、 プログラム。 イ進歩性の欠如平成２０年（２００８年）４月１５日にリリースされたｉＤアプリに関する報道発表資料（乙３の２。以下「乙３報道資料」という。）によれば、ｉＤアプリが、ｉＤアプリによる支払サービスに関する情報の表示を制御 することが記載されている。また、表示される情報が「コマンドで処理されることで生成される」（構成要件Ｆ）ことは、周知技術（乙１２の１及び２）である。以上によれば、乙１－１発明から出発して、次のｆ１１’及びｇ１１’を備えた構成に至ることは容易である。したがって、本件発明は、乙１－１発明に対して進歩性を有しない。 ｆ１１’：「ｉＤアプリ」によりコマンドが処理されることで生成される カードでの支払サービスの表示を制御し、ｇ１１’：ステッ 件発明は、乙１－１発明に対して進歩性を有しない。 ｆ１１’：「ｉＤアプリ」によりコマンドが処理されることで生成される カードでの支払サービスの表示を制御し、ｇ１１’：ステップを含む処理を実行させるためのプログラム（原告の主張）⑴ 主位的主張についてア引用発明について ｉアプリとは、ｉモード対応携帯電話用アプリケーションのうちｉモードサイトにおいて提供される各アプリケーションを便宜上総称した名称にすぎず、ｉアプリという名称の特定のアプリケーションが存在するわけではない。したがって、被告主張の構成はその前提を誤っている。 乙１文献によると、ｉＤアプリとカードアプリは別個のアプリケーショ ンであり、カードアプリがサーバからダウンロードされる旨の構成は記載されているが、「他の装置から受信したカードアプリを登録するためのデータ」を取得するための構成は記載されていない。また、乙１文献には、構成ｅ１１ないしｇ１１に相当する構成は記載されていない。 以上を踏まえると、乙１－１発明の構成は、次のとおり認定されるべき である。 ａ１１：携帯電話に「ｉＤアプリ」をダウンロードするｂ１１ ：アプリケーション「ｉＤアプリ」及び「カードアプリ」に関する情報をそれぞれ別個のプログラムで管理するｃ１１：サーバから「カードアプリ」をダウンロードする ｄ１１：「カードアプリ」をダウンロードするｅ１１：（なし）ｆ１１：（なし）ｇ１１：（なし）イ対比 以上によると、本件発明と乙１－１発明とは、少なくとも以下の点にお いて相違する。 相違点１－１－１本件発明は、「アプリケーションで提供されるサービスに関する情報を管理」（構成要件Ｂ）するものであるのに対し、乙１－ とは、少なくとも以下の点にお いて相違する。 相違点１－１－１本件発明は、「アプリケーションで提供されるサービスに関する情報を管理」（構成要件Ｂ）するものであるのに対し、乙１－１発明におけるカードアプリは「アプリケーションで提供されるサービス」には該当 しない点相違点１－１－２本件発明は、「他の装置から受信した前記サービスを登録するためのデータを取得」（構成要件Ｃ）するのに対し、乙１－１発明ではｉＤアプリとカードアプリをダウンロードするに際して「他の装置から受信し た前記サービスを登録するためのデータを取得」する構成を備えない点相違点１－１－３本件発明は、「取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録」（構成要件Ｄ）するのに対し、乙１－１発明においてはこれに相当する構成がなく、カードアプリをダウ ンロードするものである上、カードアプリは本件発明における「サービス」に相当するものではない点相違点１－１－４乙１－１発明には、構成要件ＥないしＧに相当する構成がない点ウ相違点について 本件発明と乙１－１発明との間には、上記のように実質的な相違点が存するから、新規性を欠く旨の被告の主張には理由がない。また、これらの相違点に係る主張立証はなく、進歩性を欠く旨の被告の主張にも理由がない。なお、本件発明の構成要件Ｆは、本件発明の課題の解決に密接した構成であり、乙１－１発明がこのような構成を欠く上、このような構成を採 用できたことを動機付けるような開示や示唆も存在しない以上、進歩性を 欠く旨の被告の主張は、そもそも成り立たない。 ⑵ 予備的主張についてア時機に後れた主張であること被告の予備的主張は、主引例自体 付けるような開示や示唆も存在しない以上、進歩性を 欠く旨の被告の主張は、そもそも成り立たない。 ⑵ 予備的主張についてア時機に後れた主張であること被告の予備的主張は、主引例自体を変更した上、副引例として乙１２の１及び２を持ち出して当初とは異なる無効主張を展開している。このよう な主張は、時機に後れたものとして却下されるべきである。 イ主引例について被告主張の構成は否認ないし争う。 なお、被告は、「ｉＤ設定アプリ」、「ｉＤアプリ」及び「カードアプリ」という別個のアプリケーションを単一のプログラムであるかのように 主張するが、これらは別個のアプリケーションである。また、乙１文献を見ても、被告主張のような構成は記載されていない。 ７ 争点２－１－２（乙１－２発明に基づく新規性、進歩性の有無）について（被告の主張）⑴ 主位的主張 ア引用発明について乙１文献には、乙１－２発明に関して、次の構成が記載されている。 ａ１２：携帯電話に、「i アプリ」を記憶し、ｂ１２：「i アプリ」で提供される「モバイル Ｓｕｉｃａ」を利用したサービスに関する情報を管理し、 ｃ１２：サーバからダウンロードした「モバイル Ｓｕｉｃａ」を登録するためのデータを取得し、ｄ１２：取得されたデータに基づき、「モバイル Ｓｕｉｃａ」を登録し、ｅ１２：登録された「モバイル Ｓｕｉｃａ」に関する情報を生成し、ｆ１２：「i アプリ」によりコマンドが処理されることで生成される「モ バイル Ｓｕｉｃａ」に関する情報の表示を制御する ｇ１２：ステップを含む処理を実行させるためのプログラム。 イ新規性の欠如本件発明の構成は、乙１－２発明の構成と同一であるから、本件発明は新規性を欠く。 ⑵ 報の表示を制御する ｇ１２：ステップを含む処理を実行させるためのプログラム。 イ新規性の欠如本件発明の構成は、乙１－２発明の構成と同一であるから、本件発明は新規性を欠く。 ⑵ 予備的主張 ア主引例についてｉアプリという名称の特定のアプリケーションが存在しないという原告の主張を前提としても、乙１文献によれば、乙１－２発明に関して、次の構成が記載されている。 ａ１２’：携帯電話に、「モバイルＳｕｉｃａアプリ」を記憶し、 ｂ１２’：「モバイルＳｕｉｃａアプリ」で提供されるサービスに関する情報を管理し、ｃ１２’：サーバからダウンロードした「モバイルＳｕｉｃａアプリ」によって提供されるサービスを登録するためのデータを取得し、ｄ１２’：取得された前記データに基づき、「モバイルＳｕｉｃａアプリ」 によって提供されるサービスを登録し、ｅ１２’：登録されたサービスに関する情報を生成する、プログラム。 イ進歩性の欠如平成１８年（２００６年）１月３０日付けのケータイＷａｔｃｈホームページの記事（乙４。以下「乙４記事」という。）によれば、モバイルＳ ｕｉｃａアプリが、モバイルＳｕｉｃａアプリによって提供されるサービスに関する情報の表示を制御することが記載されている。また、表示される情報が「コマンドで処理されることで生成される」（構成要件Ｆ）ことは、周知技術（乙１２の１及び２）である。以上によれば、乙１－２発明から出発して、次のｆ１２’及びｇ１２’を備えた構成に至ることは容易 である。したがって、本件発明は、乙１－２発明に対して進歩性を有しな い。 ｆ１２’：「モバイルＳｕｉｃａアプリ」によりコマンドが処理されることで生成されるサービスに関する情報の表示を制御するｇ がって、本件発明は、乙１－２発明に対して進歩性を有しな い。 ｆ１２’：「モバイルＳｕｉｃａアプリ」によりコマンドが処理されることで生成されるサービスに関する情報の表示を制御するｇ１２’：ステップを含む処理を実行させるためのプログラム（原告の主張） ⑴ 主位的主張についてア引用発明について前記６⑴アのとおり、ｉアプリという名称の特定のアプリケーションが存在するわけではないから、被告主張の構成はその前提を誤っている。 乙１文献及び乙４記事によると、乙１文献に記載のある「モバイルＳｕ ｉｃａ登録用ｉアプリ」は、おサイフケータイ対応サービスである「モバイルＳｕｉｃａ」アプリを利用する前に必要な初期設定を行うためのアプリであり、「モバイルＳｕｉｃａ登録用ｉアプリ」で初期設定を行った後に、画面の指示に従って、ＪＲ東日本サイトから乙４記事に記載のある「モバイルＳｕｉｃａ」アプリをダウンロードすることになるから、「モバイ ルＳｕｉｃａ登録用ｉアプリ」と「モバイルＳｕｉｃａ」は別個のアプリである。 また、乙１文献には、サーバから「モバイルＳｕｉｃａ登録用ｉアプリ」がダウンロードされる旨の記載はあるが、他の装置から受信した「モバイルＳｕｉｃａ登録用ｉアプリ」を登録するためのデータを取得する構成、 「モバイルＳｕｉｃａ」アプリが何らかの「取得されたデータに基づき」、「登録」されていることを示す構成、「登録されたモバイルＳｕｉｃａに関する情報を生成」する旨の構成、ｉアプリによりコマンドが処理されることで生成される「モバイルＳｕｉｃａ」に関する情報の表示を制御する構成の記載は存在しない。 以上を踏まえると、乙１－２発明の構成は、次のとおり認定されるべき である。 ａ１２：携帯電話に れる「モバイルＳｕｉｃａ」に関する情報の表示を制御する構成の記載は存在しない。 以上を踏まえると、乙１－２発明の構成は、次のとおり認定されるべき である。 ａ１２：携帯電話に「モバイルＳｕｉｃａ登録用ｉアプリ」をダウンロードするｂ１２：アプリケーション「モバイルＳｕｉｃａ登録用ｉアプリ」に関する情報を管理する ｃ１２：サーバから「モバイルＳｕｉｃａアプリ」をダウンロードするｄ１２：サーバから「モバイルＳｕｉｃａアプリ」をダウンロードするｅ１２：（なし）ｆ１２：（モバイルＳｕｉｃａアプリが）「モバイルＳｕｉｃａアプリ」に関する情報の表示を制御する ｇ１２：「モバイルＳｕｉｃａ登録用ｉアプリ」及び「モバイルＳｕｉｃａアプリ」イ対比以上によると、本件発明と乙１－２発明とは、少なくとも以下の点において相違する。 相違点１－２－１本件発明は、「アプリケーションで提供されるサービスに関する情報を管理」（構成要件Ｂ）するものであるのに対し、乙１－２発明には「アプリケーションで提供されるサービス」についての開示が存在しない点相違点１－２－２ 本件発明は、「他の装置から受信した前記サービスを登録するためのデータを取得」（構成要件Ｃ）するのに対し、乙１－２発明には「アプリケーションで提供されるサービス」についての開示が存在しないことに加え、そのような「サービス」を「登録するための」、「他の装置から受信したデータを取得（する）」構成が存在しない点 相違点１－２－３ 本件発明は、「取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録」（構成要件Ｄ）するのに対し、乙１－２発明には、「取得された前記データ」が開示されてい 本件発明は、「取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録」（構成要件Ｄ）するのに対し、乙１－２発明には、「取得された前記データ」が開示されていないことに加え、「アプリケーションの処理により・・・サービスを登録」に係る構成も開示されていない点 相違点１－２－４本件発明は、「登録された前記サービスに関する情報を生成」（構成要件Ｅ）するのに対し、乙１－２発明において、モバイルＳｕｉｃａアプリは本件発明における「サービス」に相当するものではないことに加え、上記構成要件に相当する構成が開示されていない点 相違点１－２－５本件発明は、「アプリケーションによりコマンドが処理されることで生成される前記サービスに関する情報の表示を制御」（構成要件Ｆ）するのに対し、乙１－２発明には、前記相違点１－２－１に加え、仮に被告の主張に従ってモバイルＳｕｉｃａ登録用ｉアプリを「アプリケーシ ョン」と仮定しても、モバイルＳｕｉｃａ登録用ｉアプリの「コマンド処理」によってモバイルＳｕｉｃａアプリの「情報の表示」が「制御」されることは何ら開示されていない点ウ相違点について本件発明と乙１－２発明との間には、上記のように実質的な相違点が存 するから、新規性を欠く旨の被告の主張には理由がない。また、これらの相違点に係る主張立証はなく、進歩性を欠く旨の被告の主張にも理由がない。なお、本件発明の構成要件Ｆは、本件発明の課題の解決に密接した構成であり、乙１－２発明がこのような構成を欠く上、このような構成を採用できたことを動機付けるような開示や示唆も存在しない以上、進歩性を 欠く旨の被告の主張は、そもそも成り立たない。 ⑵ 予備的主張についてア時機に後れ 上、このような構成を採用できたことを動機付けるような開示や示唆も存在しない以上、進歩性を 欠く旨の被告の主張は、そもそも成り立たない。 ⑵ 予備的主張についてア時機に後れた主張であること前記６⑵アのとおり。 イ主引例について被告主張の構成は否認ないし争う。 乙１－２ 発明におけるモバイルＳｕｉｃａアプリが、本件発明の「アプリケーション」に相当するという構成をとったとしても、乙１－２発明ではアプリケーション（モバイルＳｕｉｃａアプリ）とサービスとがあらかじめ一体になっているため、乙１文献において、モバイルＳｕｉｃａアプリが、他の装置から受信した「サービスを登録するためのデータを取得」 する構成（ｃ１２’）、「サービスを登録」するという構成（ｄ１２’）、「登録されたサービスに関する情報を生成する」という構成（ｅ１２’）は開示されていない。 以上によると、乙１－２発明の構成は、本件発明と大きく異なる構成を備えるものにすぎない。 ８ 争点２－１－３（乙１－３発明に基づく新規性、進歩性の有無）について（被告の主張）⑴ 主位的主張ア引用発明について乙１文献には、乙１－３発明に関して、次の構成が記載されている。 ａ１３：携帯電話に、「i アプリ」の「マクドナルドトクするアプリ」を記憶し、ｂ１３：「マクドナルドトクするアプリ」で提供される「かざすクーポン」に関する情報を管理し、ｃ１３：サーバからダウンロードした「かざすクーポン」を登録するため のデータを取得し、 ｄ１３：取得されたデータに基づき、「マクドナルドトクするアプリ」の処理により「かざすクーポン」を登録し、ｅ１３：登録された「かざすクーポン」に関する情報を生成し、ｆ１３：「マク ｄ１３：取得されたデータに基づき、「マクドナルドトクするアプリ」の処理により「かざすクーポン」を登録し、ｅ１３：登録された「かざすクーポン」に関する情報を生成し、ｆ１３：「マクドナルドトクするアプリ」によりコマンドが処理されることで生成される「かざすクーポン」に関する情報の表示を制御する（乙 ５ではクーポンを選択するための画面が示されている。）ｇ１３：ステップを含む処理を実行させるためのプログラム。 イ新規性の欠如本件発明の構成は、乙１－３発明の構成と同一であるから、本件発明は新規性を欠く。 ⑵ 予備的主張ア主引例についてｉアプリという名称の特定のアプリケーションが存在しないという原告の主張を前提としても、乙１文献によれば、乙１－３発明に関して、次の構成が記載されている。 ａ１３'：携帯電話に、「マクドナルドトクするアプリ」を記憶し、ｂ１３'：「マクドナルドトクするアプリ」で提供される「かざすクーポン」を用いた支払サービスに関する情報を管理し、ｃ１３'：サーバからダウンロードした「かざすクーポン」を用いた支払サービスを登録するためのデータを取得し、 ｄ１３'：取得されたデータに基づき、「マクドナルドトクするアプリ」の処理により「かざすクーポン」を登録し、ｅ１３'：登録された「かざすクーポン」を用いた支払サービスに関する情報を生成し、ｆ１３''：「かざすクーポン」を用いた支払サービスに関する情報の表示 を制御する ｇ１３’：ステップを含む処理を実行させるためのプログラム。 イ進歩性の欠如平成２１年（２００９年）８月２０日付けの報道発表資料（乙５。以下「乙５報道資料」とう。）によれば、マクドナルドトクするアプリが、かざすクーポンを 実行させるためのプログラム。 イ進歩性の欠如平成２１年（２００９年）８月２０日付けの報道発表資料（乙５。以下「乙５報道資料」とう。）によれば、マクドナルドトクするアプリが、かざすクーポンを用いた支払サービスに関する情報の表示を制御することが 記載されている。また、表示される情報が「コマンドが処理されることで生成される」（構成要件Ｆ）ことは、周知技術（乙１２の１及び２）である。また、かざすクーポンを用いた支払サービスに関する情報が対象となることから、コマンドがかざすクーポンを提供するマクドナルドトクするアプリによって実行されることも格別困難なことではない。以上によれば、 乙１－３発明から出発して、次のｆ１３'を備えた構成に至ることは容易である。したがって、本件発明は、乙１－３発明に対して進歩性を有しない。 ｆ１３'：「マクドナルドトクするアプリ」によりコマンドが処理されることで生成される「かざすクーポン」を用いた支払サービスに関する情報の表示を制御する （原告の主張）⑴ 主位的主張についてア引用発明について前記６⑴アのとおり、ｉアプリという名称の特定のアプリケーションが存在するわけではないから、被告主張の構成はその前提を誤っている。 また、被告の主張は、アプリで提供されるサービスとしての「かざすクーポン」サービス機能と、かざすクーポンサービス機能で提供されるクーポンそのもののデータ（例えばポテトＭ５０円割引など）としての割引きクーポンのデータを混同するものである。 すなわち、乙１－３発明においては、アプリ自体に当初から「かざすク ーポン」サービス機能が含まれており、サーバから配信されるクーポンデ ータは、本件発明における「サービス」に該当しない。そして、「アプリケーシ ては、アプリ自体に当初から「かざすク ーポン」サービス機能が含まれており、サーバから配信されるクーポンデ ータは、本件発明における「サービス」に該当しない。そして、「アプリケーションで提供されるサービス」に対応する構成を、「かざすクーポン」サービス機能ととらえると、乙１－３発明は、クーポンデータを受信するにすぎず、かざすクーポンサービスを登録するためのデータを取得するわけではない。 以上を踏まえると、乙１－３発明の構成は、次のとおり認定されるべきである。 ａ１３：携帯電話に、「マクドナルドトクするアプリ」をダウンロードするｂ１３ ：「マクドナルドトクするアプリ」で提供される「かざすクーポン」 サービスに関する情報を管理するｃ１３：サーバから「かざすクーポン」サービス用割引クーポンのデータをダウンロードするｄ１３：「マクドナルドトクするアプリ」の「かざすクーポン」サービスで提供される割引クーポンのデータをダウンロードする ｅ１３：ダウンロードされた「かざすクーポン」サービスで提供される割引クーポンのデータに関する情報を生成するｆ１３ ：「かざすクーポン」サービスの割引クーポンに関するデータの表示を制御するｇ１３：マクドナルドトクするアプリ イ対比本件発明と乙１－３発明とは、少なくとも以下の点において相違する。 相違点１－３－１本件発明は、「サービス」そのものを「登録するためのデータ」（構成要件Ｃ）を取得するものであるのに対し、乙１－３発明は、「サービ ス」に相当する「かざすクーポン」サービスそのものを登録するための データを取得するという構成を有しない点相違点１－３－２乙１－３発明には、本件発明の構成要件Ｄに相当する構成の開示が 」に相当する「かざすクーポン」サービスそのものを登録するための データを取得するという構成を有しない点相違点１－３－２乙１－３発明には、本件発明の構成要件Ｄに相当する構成の開示が存在しない点相違点１－２－３ 本件発明は、「登録された前記サービスに関する情報を生成」（構成要件Ｅ）するものであるのに対し、乙１－３発明は、かざすクーポンサービスで提供される割引クーポンのデータに関する情報を生成するにとどまる点相違点１－２－４ 乙１－３発明では、本件発明の構成要件Ｆに相当する構成の開示が明らかでない点ウ相違点について本件発明と乙１－３発明との間には、上記のように実質的な相違点が存するから、新規性を欠く旨の被告の主張には理由がない。また、これらの 相違点に係る主張立証はなく、進歩性を欠く旨の被告の主張にも理由がない。なお、本件発明の構成要件Ｆは、本件発明の課題の解決に密接した構成であり、乙１－３発明がこのような構成を欠く上、このような構成を採用できたことを動機付けるような開示や示唆も存在しない以上、進歩性を欠く旨の被告の主張は、そもそも成り立たない。 ⑵ 予備的主張についてア時機に後れた主張であること前記６⑵アのとおり。 イ主引例について乙１－３発明の構成について、前記⑴アのとおり、かざすクーポンサー ビス機能とクーポンデータは異なるものであり、かつ、クーポンデータは 本件発明における「アプリケーションで提供されるサービス」には当たらない。また、かざすクーポンサービス機能自体はあらかじめアプリに備わっている。したがって、乙１－３発明は、クーポンデータが「サービス」に相当することを前提とした、構成ｂ１３’ないしｆ１３’の構成を備えない。 かざすクーポンサービス機能自体はあらかじめアプリに備わっている。したがって、乙１－３発明は、クーポンデータが「サービス」に相当することを前提とした、構成ｂ１３’ないしｆ１３’の構成を備えない。 ９ 争点２－１－４（乙１－４発明に基づく新規性、進歩性の有無）について（被告の主張）⑴ 主位的主張ア引用発明について乙１文献には、乙１－４発明に関して、機種変更時等にドコモショップ の店頭などに設置されている専用の機器を用いておサイフケータイのＩＣカード内データを取替え先のおサイフケータイに移し替えるとき（ｉＣお引っこしサービス。乙６）の態様として、次の構成が記載されている。 ａ１４：携帯電話に、「i アプリ」の「おサイフケータイ」を記憶し、ｂ１４：「おサイフケータイ」で提供される電子マネーに関する情報を管 理し、ｃ１４：ドコモショップの店頭などに設置されている専用の機器から受信した「おサイフケータイ」のＩＣカード内データを登録するためのデータを取得し、ｄ１４：取得されたデータに基づき、「おサイフケータイ」のＩＣカード 内データを登録し、ｅ１４：登録された「おサイフケータイ」に関する情報を生成し、ｆ１４：i アプリよりコマンドが処理されることで生成され「おサイフケータイ」に関する情報の表示を制御するｇ１４：ステップを含む処理を実行させるためのプログラム。 イ新規性の欠如 本件発明の構成は、乙１－４発明の構成と同一であるから、本件発明は新規性を欠く。 ⑵ 予備的主張ア主引例についてｉアプリという名称の特定のアプリケーションは存在しないし、「おサ イフケータイ」は非接触型の少額決済サービスの総称にすぎず、アプリとしては「おサイフケータイ対応ｉアプ ア主引例についてｉアプリという名称の特定のアプリケーションは存在しないし、「おサ イフケータイ」は非接触型の少額決済サービスの総称にすぎず、アプリとしては「おサイフケータイ対応ｉアプリ」が存在するにすぎないという原告の主張を前提としても、乙１文献には、乙１－４発明に関して、次の構成が記載されている。 ａ１４’：携帯電話に、「おサイフケータイ対応i アプリ」を記憶し、 ｂ１４’：「おサイフケータイ対応i アプリ」で提供されるサービスに関する情報を管理し、ｃ１４’：ドコモショップの店頭などに設置されている専用の機器から受信した「おサイフケータイ対応i アプリ」で提供されるサービスを登録するためのデータを取得し、 ｄ１４’：取得されたデータに基づき、「おサイフケータイ対応i アプリ」により当該「おサイフケータイ対応i アプリ」で提供されるサービスを登録し、ｅ１４’：登録された「おサイフケータイ対応i アプリ」で提供されるサービスに関する情報を生成する、プログラム。 イ進歩性の欠如ｉＤアプリ、モバイルＳｕｉｃａアプリ及びマクドナルドトクするアプリは、いずれもおサイフケータイ対応ｉアプリであり、乙１－４発明の上記態様に対して、乙３報道資料、乙４記事及び乙５報道資料を組み合わせることができる。また、表示される情報が「コマンドで処理されることで 生成される」（構成要件Ｆ）ことは、周知技術（乙１２の１及び２）であ る。以上によれば、乙１－４発明から出発して、次のｆ１４’及びｇ１４’を備えた構成に至ることは容易である。したがって、本件発明は、乙１－４発明に対して進歩性を有しない。 ｆ１４’：「iＤアプリ」によりコマンドが処理されることで生成されるカードでの支払サービスの表示を制 えた構成に至ることは容易である。したがって、本件発明は、乙１－４発明に対して進歩性を有しない。 ｆ１４’：「iＤアプリ」によりコマンドが処理されることで生成されるカードでの支払サービスの表示を制御し、 ：「モバイルＳｕｉｃａアプリ」によりコマンドが処理されることで生成されるサービスに関する情報の表示を制御し、：「マクドナルドトクするアプリ」によりコマンドが処理されることで生成される「かざすクーポン」を用いた支払サービスに関する情報の表示を制御する、 ｇ１４’：ステップを含む処理を実行させるためのプログラム。 （原告の主張）⑴ 主位的主張についてア引用発明について乙１－４発明は、本件明細書において従来技術として紹介されている技 術と全く同一の技術であるから、本件発明が乙１－４発明に対して進歩性を有することは明らかである。 前記６⑴アのとおり、ｉアプリという名称の特定のアプリケーションが存在するわけではないから、被告主張の構成はその前提を誤っている。 乙１文献によれば、「おサイフケータイ」とは、非接触型ＩＣカードを 搭載した携帯電話や、携帯電話に埋め込まれたＦｅｌｉＣａチップ（ＩＣチップ）を用いた非接触型の少額決済サービスの総称であり、「おサイフケータイ」という特定のアプリケーションが存在するわけではない。また、「おサイフケータイ対応ｉアプリ」が「おサイフケータイ」で提供される電子マネーに関する情報を管理する構成が、具体的に何を意味するかも特 定されていない。加えて、乙１－４発明において、「おサイフケータイ対 応ｉアプリ」が被告主張のａ１４ないしｆ１４の処理のすべてを実行するわけではない（ドコモショップの専用機が行っている処理がある）。 以上を踏まえると、乙１－４発明の構成 サイフケータイ対 応ｉアプリ」が被告主張のａ１４ないしｆ１４の処理のすべてを実行するわけではない（ドコモショップの専用機が行っている処理がある）。 以上を踏まえると、乙１－４発明の構成は次のとおり認定されるべきである。 ａ１４：携帯電話に、「おサイフケータイ対応ｉアプリ」をダウンロード するｂ１４：「おサイフケータイ対応ｉアプリ」で提供される電子マネーに関するデータを管理するｃ１４：ドコモショップの店頭などに設置されている専用の機器から受信した旧機種の「おサイフケータイ対応ｉアプリ」のＩＣカード内に記録 されたデータを新機種に引き継ぐためのデータを取得するｄ１４：前記新機種に引き継ぐためのデータに基づき、「おサイフケータイ対応ｉアプリ」のＩＣカード内データを新機種に引き継ぐｅ１４：登録された「おサイフケータイ対応ｉアプリ」に関するＩＣカード内データを新機種で生成する ｆ１４：（なし）ｇ１４：「おサイフケータイ対応ｉアプリ」イ対比以上によると、本件発明と乙１－４発明とは、少なくとも以下の点において相違する。 相違点１－４－１乙１－４発明において、おサイフケータイ対応ｉアプリで提供されるのは電子マネーに関するデータであって、「アプリケーションで提供されるサービス」（構成要件Ｂ）ではない点相違点１－４－２ 乙１－４発明においては、単なるデータ（例えば電子マネーの残高等） を携帯端末の旧機種から新機種への移行させる手続が開示されているのみであって、「サービスを登録するためのデータを取得」（構成要件Ｃ）する構成が存しない点相違点１－４－３本件発明は、「アプリケーションの処理により、前記サービスを登録」 （構成要件Ｄ）するものであ サービスを登録するためのデータを取得」（構成要件Ｃ）する構成が存しない点相違点１－４－３本件発明は、「アプリケーションの処理により、前記サービスを登録」 （構成要件Ｄ）するものであるのに対して、乙１－４発明にはこのような開示がない点相違点１－４－４本件発明は、「前記サービスに関する情報を生成」（構成要件Ｅ）するのに対し、乙１－４発明ではＩＣカード内のデータを生成するにすぎ ない点相違点１－４－５本件発明は、「アプリケーションによりコマンドが処理されることで生成される前記サービスに関する情報の表示を制御」（構成要件Ｆ）するのに対し、乙１－４発明は、このような構成についての開示が存在し ない点ウ相違点について本件発明と乙１－４発明との間には、上記のような実質的な相違点が存するから、新規性を欠く旨の被告の主張には理由がない。また、これらの相違点に係る主張立証はなく、進歩性を欠く旨の被告の主張にも理由がな い。なお、本件発明の構成要件Ｆは、本件発明の課題の解決に密接した構成であり、乙１－４発明がこのような構成を欠く上、このような構成を採用できたことを動機付けるような開示や示唆も存在しない以上、進歩性を欠く旨の被告の主張は、そもそも成り立たない。 ⑵ 予備的主張について ア時機に後れた主張であること 被告の予備的主張は、主引例を変更するに等しい。また、乙１－４発明において、本件発明の「サービス」に対応する構成を新たに主張し直しており、攻撃防御の対象が大幅に変更されている。このような主張は、時機に後れたものとして却下されるべきである。 イ主引例について 被告主張の構成は否認ないし争う。 乙１－４発明は、単なるデータを新機種へ移行することを明らか れている。このような主張は、時機に後れたものとして却下されるべきである。 イ主引例について 被告主張の構成は否認ないし争う。 乙１－４発明は、単なるデータを新機種へ移行することを明らかにするにすぎないから、このような発明に基づいて本件発明の進歩性を否定することはできない。 すなわち、前記⑴のとおり、そもそも、おサイフケータイ自体は、本件 発明における「アプリケーション」に相当せず、「おサイフケータイ対応ｉアプリ」もアプリの総称であって、特定の単一のアプリケーションとして存在するわけではない。それにもかかわらず、被告は、「『おサイフケータイ対応ｉアプリ』で提供されるサービス」（ｂ１４’、 ｅ１４’）に相当する構成や「サービスに関する情報」（ｂ１４’、 ｅ１４’）を具体的に 特定しない。 また、乙１－４発明において、店頭に設置されている専用の機器から受信されるのは、単なるデータ移行のためのデータ（例えば、旧機種の「おサイフケータイ対応ｉアプリ」のＩＣカード内のデータ〔例えば、ＩＣカードの残額やマクドナルドトクするアプリにおけるクーポンのデータ〕） であって、「サービスを登録するためのデータ」（ｃ１４’）ではないし、これを前提としたｄ１４’に相当する構成の開示もない。 １０ 争点２－２（公然実施の有無）について（被告の主張）携帯電話（Ｆ－０３Ａ）に関して公然実施されていた内容は、前記６ないし ９において示したとおりである。Ｆ－０３Ａは、平成２１年（２００９年）１ 月２４日に販売開始された携帯電話であることから（乙２）、本件発明は、公然実施された携帯電話（Ｆ－０３Ａ）に対して新規性を有さない。したがって、本件発明は、無効とされるべきものである。 （原告の主張）否認ないし争う。 電話であることから（乙２）、本件発明は、公然実施された携帯電話（Ｆ－０３Ａ）に対して新規性を有さない。したがって、本件発明は、無効とされるべきものである。 （原告の主張）否認ないし争う。 １１ 争点２－３（乙７発明を主引例とする新規性、進歩性の有無）について（被告の主張）以下に述べるとおり、本件発明は、乙７公報（主引例）に記載された発明（乙７発明）と同一又はこれに基づいて本件特許の出願前に当業者が容易に発明をすることができたものであるから、特許法２９条１項３号又同条２項により無 効とされるべきものである。 ⑴ 主引例乙７公報には、次の発明（乙７発明）が記載されている。 ａ３：携帯電話に、電子マネーアプリを記憶し、ｂ３：電子マネーアプリで提供される電子マネー利用サービスに関する情報 を管理し、ｃ３：サーバからダウンロードした電子マネー利用サービスを登録するためのデータを取得し、ｄ３：取得されたデータに基づき、電子マネー利用サービスを登録し、ｅ３：登録された電子マネー利用サービスに関する情報を生成し、 ｆ３：電子マネーアプリによりコマンドが処理されることで生成される電子マネー利用サービスに関する情報の表示を制御するｇ３：ステップを含む処理を実行させるためのプログラム。 ⑵ 対比本件発明と乙７発明を対比すると、乙７発明の「携帯電話」及び「電子マ ネーアプリ」（ａ３）は、それぞれ本件発明の「コンピュータ」及び「所定 のアプリケーション」（構成要件Ａ）に相当する。 乙７発明の「電子マネーアプリで提供される電子マネー利用サービス」（ｂ３）は、本件発明の「前記アプリケーションで提供されるサービス」（構成要件Ｂ）に相当する。 乙７発明では、電子マネーアプリをサーバからダ の「電子マネーアプリで提供される電子マネー利用サービス」（ｂ３）は、本件発明の「前記アプリケーションで提供されるサービス」（構成要件Ｂ）に相当する。 乙７発明では、電子マネーアプリをサーバからダウンロードすることで、 電子マネー利用サービスを携帯電話に登録し、当該電子マネー利用サービスに関する情報が携帯電話で表示される発明が開示されていることから、構成要件Ｃ、Ｅ，Ｆ及びＧに相当する構成を有している。 乙７発明では、上記のとおり、ユーザの操作を利用して電子マネーアプリのダウンロードを行っていることから、「前記アプリケーションの処理によ り」という点を除き、構成要件Ｄに相当する構成を有している。なお、原告の充足論での主張を前提とするならば、ユーザの操作を利用して電子マネーアプリをダウンロードする構成は、「前記アプリケーションの処理により」という点も含め、構成要件Ｄに相当する構成である。 ⑶ 一致点・相違点 上記のとおり、乙７発明と本件発明とは、原告の充足論での主張を前提とすれば、全ての構成要件が一致する。 そうでないとしても、本件発明が「前記アプリケーションの処理により」という構成を有するのに対して、乙７発明がこの構成を有さないという点についての相違点を除き、すべての構成要件が一致する。 ⑷ 相違点の容易想到性上記相違点があるとしても、微差にすぎないから、乙７発明に対して進歩性を有さない。したがって、本件発明は、無効とされるべきものである。 （原告の主張）⑴ 主引例について ア被告の主張に対する認否 否認ないし争う。 ａ３については、積極的に争うものではないが、乙７公報によれば、後記イのとおり認定するのが相当である。 ｂ３については、乙７公報において開示されているのは電子 認否 否認ないし争う。 ａ３については、積極的に争うものではないが、乙７公報によれば、後記イのとおり認定するのが相当である。 ｂ３については、乙７公報において開示されているのは電子マネーサービスであり、電子マネー利用サービスの構成の開示はない。 ｃ３については、乙７発明において、サーバからダウンロードしたデータは電子マネーアプリそれ自体を携帯電話にインストールするためのデータであり、当該ダウンロードデータとは別の電子マネー利用サービスを登録するためのデータを取得する構成の開示は存在しない。 イ乙７発明の構成について 以上によれば、乙７発明は、次のとおり認定するのが相当である。 ａ３：携帯電話に、電子マネーアプリをダウンロードするｂ３：電子マネーアプリで提供される電子マネーサービスに関する情報を管理するｃ３：電子マネーアプリをダウンロードする ｄ３：電子マネーシステムに携帯端末情報を登録するｅ３：（なし）ｆ３：（電子マネーアプリが）サービスに関する情報の表示を制御するｇ３：上記処理を実行させるウェブブラウザと電子マネーアプリ⑵ 対比 本件発明と乙７発明を対比すると、以下の相違点があり、その余は一致する。 ア相違点７－１本件発明は、「他の装置から受信した前記サービスを登録するためのデータを取得」（構成要件Ｃ）するのに対し、乙７発明は、電子マネーサー ビスを登録するためのデータを取得することについての開示がなく、他の 装置からそのようなデータを受信することについての開示もない点イ相違点７－２本件発明は、「取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録」（構成要件Ｄ）するものであるのに対し、乙７発明は、電 とについての開示もない点イ相違点７－２本件発明は、「取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録」（構成要件Ｄ）するものであるのに対し、乙７発明は、電子マネーアプリの処理により登録が行われるか否かの 開示が存在せず、かつ、携帯電話にサービスを登録する構成ではない点ウ相違点７－３本件発明は、「（プログラムが）登録された前記サービスに関する情報を生成」（構成要件Ｅ）するのに対して、乙７発明にはこれに相当する構成の開示が存在しない点 エ相違点７－４本件発明は、「前記アプリケーションによりコマンドが処理されることで生成される前記サービスに関する情報の表示を制御する」（構成要件Ｆ）のに対し、乙７発明は、サービスに関する情報の制御が「アプリケーションによりコマンドが処理されることで生成される」ものであるかが不明な 点⑶ 相違点についての検討本件発明と乙７発明との間には、上記のように実質的な相違点が存するから、新規性を欠く旨の被告の主張には理由がない。また、これらの相違点に係る主張立証はなく、進歩性を欠く旨の被告の主張にも理由がない。なお、 本件発明の構成要件Ｆに関する構成は、本件発明の課題の解決に密接した構成であり、乙７発明がこのような構成を欠く上、このような構成を採用できたことを動機付けるような開示や示唆も存在しない以上、進歩性を欠く旨の被告の主張は、そもそも成り立たない。 １２ 争点２－４（乙８発明を主引例とする新規性、進歩性の有無）について （被告の主張） 以下に述べるとおり、本件発明は、乙８公報（主引例）に記載された発明（乙８発明）と同一又はこれに基づいて本件特許の出願前に当業者が容易に発明をすることができたものであるから 告の主張） 以下に述べるとおり、本件発明は、乙８公報（主引例）に記載された発明（乙８発明）と同一又はこれに基づいて本件特許の出願前に当業者が容易に発明をすることができたものであるから、特許法２９条１項３号又は同条２項により無効とされるべきものである。 ⑴ 主引例 乙８公報には、次の発明（乙８発明）が記載されている。 ａ４：移動体通信端末２０に、ｉアプリを記憶し、ｂ４：ｉアプリで提供される電子化契約書を含むサービス（乙１及び乙３の１ないし乙６で示されるサービスも含む。）に関する情報を管理し、ｃ４：電子決済サーバ１０から受信した前記サービスを登録するためのデー タを取得し、ｄ４：取得された前記データに基づき、前記サービスを登録し、ｅ４：登録された前記サービスに関する情報を生成し、ｆ４：前記アプリケーションによりコマンドが処理されることで生成される前記サービスに関する情報の表示を制御する ｇ４：ステップを含む処理を実行させるためのプログラム。 【乙８公報の図１４】 ⑵ 対比i アプリは様々なサービスを提供するところ、ｉアプリ及びｉアプリで提供される複数のサービス内容については、乙１及び乙３の１ないし乙６で示したとおりである。このことも考慮して、乙８発明を本件発明と対比すると、 乙８発明の「移動体通信端末２０」及び「i アプリ」（ａ４）は、それぞれ本件発明の「コンピュータ」及び「所定のアプリケーション」（構成要件Ａ）に相当する。 乙８発明の「ｉアプリで提供される電子化契約書を含むサービス（乙１及び乙３の１ないし乙６で示されるサービスも含む。）」（ｂ４）は、本件発 明の「前記アプリケーションで提供されるサービス」（構成要件Ｂ 明の「ｉアプリで提供される電子化契約書を含むサービス（乙１及び乙３の１ないし乙６で示されるサービスも含む。）」（ｂ４）は、本件発 明の「前記アプリケーションで提供されるサービス」（構成要件Ｂ）に相当する。 乙８発明は、ユーザの操作を利用してｉアプリのダウンロードを行っていることから、構成要件Ｄのように「前記アプリケーションの処理により前記サービスを登録」するものではない。しかしながら、原告は、充足論において、ユーザが適宜の操作をする態様であっても上記構成要件Ｄを充足すると主張しており、このような原告の主張を前提とすると、乙８発明のようにユ ーザの操作も利用してｉアプリをダウンロードする構成は、構成要件Ｄに対応するものである。 ⑶ 一致点及び相違点上記のとおり、乙８発明と本件発明とは、原告の充足論での主張を前提とすれば、すべての構成要件が一致するから、本件発明は、乙８発明に対して 新規性を有さない。 そうでないとしても、本件発明が「前記アプリケーションの処理により」という構成を有するのに対して、乙８発明がこの構成を有さないという点についての相違点を除き、すべての構成要件が一致する。 ⑷ 相違点の容易想到性 上記相違点があるとしても、微差にすぎないから、本件発明は、乙８発明及び周知技術（乙１、乙３の１ないし乙６）に対して進歩性を有さない。したがって、本件発明は、無効とされるべきものである（原告の主張）⑴ 主引例について ア被告の主張に対する認否否認ないし争う。 ａ４については、被告は「ｉアプリを記憶し」と認定するが、前記６⑴アのとおり、ｉアプリという名称の特定のアプリケーションが存在するわけではない。乙８公報の【０１０５】の開示を踏まえると、乙８発明の構 成ａ４ 被告は「ｉアプリを記憶し」と認定するが、前記６⑴アのとおり、ｉアプリという名称の特定のアプリケーションが存在するわけではない。乙８公報の【０１０５】の開示を踏まえると、乙８発明の構 成ａ４は、後記イのとおり認定されるべきである。 ｂ４については、被告は「ｉアプリで提供される電子化契約書を含むサービス（乙１及び乙３の１ないし乙６で示されるサービスも含む。）に関する情報を管理し」と認定するが、上記のとおり、「ｉアプリ」は特定のアプリケーションではなく、その実態がない以上、何をもって「提供」とするのか不明であるし、乙８公報には、単に電子化契約書７１３をダウン ロードする構成が開示されているにすぎない。また、乙１及び乙３の１ないし乙６は、乙８公報に開示されておらず、これを引用発明の認定に取り込むことは不適切である。 ｃ４については、被告は「電子決済サーバ１０から受信した前記サービスを登録するためのデータを取得し」と認定するが、乙８発明において何 が「前記サービスを登録するためのデータ」（構成要件Ｃ）に相当するかは不明であるし、これに相当する「データ」の具体的な開示も存在しない。 そもそも、乙８公報の【０１０５】、図１４のＳ１０２の記載を踏まえると、乙８発明においては、アプリのデータと電子化契約書７１３のデータ自体とは別個のものであって、これらが電子決済サーバから同時に送信さ れているものである。したがって、上記アプリのデータは、電子化契約書７１３を「登録するためのデータ」に相当しない。また、上記のとおり、乙８発明の認定に当たり、乙１及び乙３の１ないし乙６の内容を取り込むことは不適切である。 ｄ４については、被告は「取得された前記データに基づき、前記サービ スを登録し」と認定するが、単に本件発明のク の認定に当たり、乙１及び乙３の１ないし乙６の内容を取り込むことは不適切である。 ｄ４については、被告は「取得された前記データに基づき、前記サービ スを登録し」と認定するが、単に本件発明のクレーム文言を引き写したものにすぎず、「前記データ」や「登録」が乙８発明において具体的に何を意味するか全く特定していない。そうすると、乙８公報の【０１０５】の開示を踏まえると、構成ｄ４は、後記イのとおり認定されるべきである。 ｅ４、ｆ４については、乙８公報には、本件発明の構成要件Ｅ、Ｆに相 当する具体的な構成の開示がない。 イ乙８発明の構成について以上によれば、乙８発明は、次のとおり認定するのが相当である。 ａ４：移動体通信端末２０に、移動体通信端末２０用ソフトウェアをダウンロードするｂ４：電子化契約書７１３に関する情報を管理する ｃ４：電子決済サーバ１０から電子化契約書７１３をダウンロードするｄ４：電子化契約書７１３をダウンロードするｅ４：（なし）ｆ４：（なし）ｇ４：移動体通信端末２０用ソフトウェア ⑵ 対比本件発明と乙８発明を対比すると、以下の相違点があり、その余は一致する。 ア相違点８－１本件発明は、「前記アプリケーションで提供されるサービスに関する情 報を管理」（構成要件Ｂ）するのに対し、乙８発明においては、電子化契約書７１３は単なるデータであり、アプリケーションで提供されるサービスには相当しない点イ相違点８－２本件発明は、「他の装置から受信した前記サービスを登録するためのデ ータを取得」（構成要件Ｃ）するのに対し、乙８発明には当該構成の開示が存在しない点ウ相違点８－３本件発明は、「取得された前記データに基づき、前記アプリケーション 登録するためのデ ータを取得」（構成要件Ｃ）するのに対し、乙８発明には当該構成の開示が存在しない点ウ相違点８－３本件発明は、「取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録」（構成要件Ｄ）するのに対し、乙８発 明には当該構成の開示が存在しない点 エ相違点８－４本件発明は、「登録された前記サービスに関する情報を生成」（構成要件Ｅ）するのに対し、乙８発明はそのような構成を備えない点オ相違点８－５本件発明は、「前記アプリケーションによりコマンドが処理されること で生成される前記サービスに関する情報の表示を制御する」（構成要件Ｆ）のに対し、乙８発明は、このような構成を備えない点⑶ 相違点についての検討本件発明と乙８発明との間には、上記のように実質的な相違点が存するから、新規性を欠く旨の被告の主張には理由がない。また、これらの相違点に 係る主張立証はなく、進歩性を欠く旨の被告の主張にも理由がない。なお、本件発明の構成要件Ｆに関する構成は、本件発明の課題の解決に密接した構成であり、乙８発明がこのような構成を欠く上、このような構成を採用できたことを動機付けるような開示や示唆も存在しない以上、進歩性を欠く旨の被告の主張は、そもそも成り立たない。 １３ 争点２－５（乙９発明を主引例とする新規性、進歩性の有無）について（被告の主張）以下に述べるとおり、本件発明は、乙９公報（主引例）に記載された発明（乙９発明）と同一又はこれに基づいて本件特許の出願前に当業者が容易に発明をすることができたものであるから、特許法２９条１項３号又は同条２項により 無効とされるべきものである。 ⑴ 主引例乙９公報には、次の発明（乙９発明）が記載され 出願前に当業者が容易に発明をすることができたものであるから、特許法２９条１項３号又は同条２項により 無効とされるべきものである。 ⑴ 主引例乙９公報には、次の発明（乙９発明）が記載されている。 ａ５：携帯無線コンピューティング装置に、音楽に関するソフトウェアアプリケーションを記憶し、 ｂ５：前記音楽に関するソフトウェアアプリケーションで提供される音楽コ ンテンツの提供サービスに関する情報を管理し、ｃ５：リモートサーバからダウンロードした音楽コンテンツの提供サービスを登録するためのデータを取得し、ｄ５：取得された前記データに基づき、前記音楽に関するソフトウェアアプリケーションの処理により音楽コンテンツを登録し、 ｅ５：登録された音楽コンテンツに関する情報を生成し、ｆ５：前記アプリケーションによりコマンドが処理されることで生成される音楽コンテンツのプレイリストに関する情報の表示を制御するｇ５：ステップを含む処理を実行させるためのプログラム。 ⑵ 対比 上記のとおり、本件発明は、乙９発明に対して新規性を有さず、仮に乙９発明に対して相違点があるとしても微差にすぎないことから、乙９発明に対して進歩性を有さない。したがって、本件発明は、無効とされるべきものである。 （原告の主張） ⑴ 主引例についてア被告の主張に対する認否否認ないし争う。 ａ５については、積極的に争うものではないが、乙９公報によれば、後記イのとおり認定するのが相当である。 ｂ５については、被告は「前記音楽に関するソフトウェアアプリケーションで提供される音楽コンテンツの提供サービスに関する情報を管理し」と認定するが、乙９公報において開示されているのは、ＭｕｓｉｃＳｔａｔｉｏｎアプリケーション 記音楽に関するソフトウェアアプリケーションで提供される音楽コンテンツの提供サービスに関する情報を管理し」と認定するが、乙９公報において開示されているのは、ＭｕｓｉｃＳｔａｔｉｏｎアプリケーションと同アプリケーションでユーザが聴くことのできる音楽コンテンツ（データ）を提供するものであって、上記アプリで提 供される「サービス」についての開示は存在しない。 ｃ５については、被告は「リモートサーバからダウンロードした音楽コンテンツの提供サービスを登録するためのデータを取得し」と認定するが、上記のとおり、乙９公報において、アプリケーションで提供される「音楽コンテンツの提供サービス」に関する開示は存在しない。また、乙９公報において、「音楽コンテンツの提供サービスを登録するためのデータ」が 具体的に何を意味するのかの特定もない。 ｄ５については、被告は「取得された前記データに基づき、前記音楽に関するソフトウェアアプリケーションの処理により音楽コンテンツを登録し」と認定するが、上記のとおり、乙９公報において、アプリケーションで提供される「音楽コンテンツの提供サービス」に関する情報を取得する 構成の開示は存在しないし、「音楽に関するソフトウェアアプリケーションの処理により」音楽コンテンツを登録する旨の構成の開示も存在しない。 ｅ５については、被告は「（プログラムが）登録された音楽コンテンツに関する情報を生成し」と認定するが、乙９発明において「登録された音楽コンテンツに関する情報」が何を意味するのかの特定がない。また、乙 ９公報をみても、音楽に関するソフトウェアアプリケーションＭｕｓｉｃＳｔａｔｉｏｎが、登録された音楽コンテンツに関する情報を生成する旨の開示はない。 ｆ５については、被告は「前記アプリケーションに ９公報をみても、音楽に関するソフトウェアアプリケーションＭｕｓｉｃＳｔａｔｉｏｎが、登録された音楽コンテンツに関する情報を生成する旨の開示はない。 ｆ５については、被告は「前記アプリケーションによりコマンドが処理されることで生成される音楽コンテンツのプレイリストに関する情報の表 示を制御する」と認定するが、乙９公報には音楽に関するソフトウェアアプリケーションによりコマンドが処理されること自体の開示は存在しない。 イ乙９発明の構成について以上によれば、乙９発明は、次のとおり認定するのが相当である。 ａ５ ：携帯無線コンピューティング装置に、音楽に関するソフトウェアア プリケーション（ＭｕｓｉｃＳｔａｔｉｏｎ）をダウンロードする ｂ５：前記音楽に関するソフトウェアアプリケーション（ＭｕｓｉｃＳｔａｔｉｏｎ）で提供される音楽コンテンツに関する情報を管理するｃ５ ：（アプリケーション〔ＭｕｓｉｃＳｔａｔｉｏｎ〕が）リモートサーバから音楽コンテンツをダウンロードするｄ５ ：音楽コンテンツをダウンロードする ｅ５ ：（なし）ｆ５ ：音楽コンテンツのプレイリストに関する情報の表示を制御するｇ５ ：アプリケーションＭｕｓｉｃＳｔａｔｉｏｎ⑵ 対比本件発明と乙９発明を対比すると、以下の相違点があり、その余は一致す る。 ア相違点９－１本件発明は、「アプリケーションで提供されるサービスに関する情報を管理」（構成要件Ｂ）するのに対して、乙９発明で提供されるのは、データとしての音楽コンテンツである点 イ相違点９－２本件発明は、「他の装置から受信した前記サービスを登録するためのデータを取得」（構成要件Ｃ）するのに対し、乙９発明には当該構成の開示が存在しない点ウ相違点 る点 イ相違点９－２本件発明は、「他の装置から受信した前記サービスを登録するためのデータを取得」（構成要件Ｃ）するのに対し、乙９発明には当該構成の開示が存在しない点ウ相違点９－３ 本件発明は、「取得された前記データに基づき、前記アプリケーションの処理により前記サービスを登録」（構成要件Ｄ）するのに対し、乙９発明においては、「アプリケーション（ＭｕｓｉｃＳｔａｔｉｏｎ）により音楽コンテンツをダウンロードする」ものの、これが「取得された前記データに基づ（く）」ものか明らかではない点 エ相違点９－４ 本件発明は、「登録された前記サービスに関する情報を生成」（構成要件Ｅ）するのに対し、乙９発明は、このような構成を備えるか明らかではない点オ相違点９－５本件発明は、「前記アプリケーションによりコマンドが処理されること で生成される前記サービスに関する情報の表示を制御する」（構成要件Ｆ）のに対し、乙９発明は「生成される音楽コンテンツのプレイリストに関する情報の表示を制御する」ものの、これが「アプリケーションによりコマンドが処理されることで」生成されるものか明らかではない点⑶ 相違点についての検討 本件発明と乙９発明との間には、上記のように実質的な相違点が存するから、新規性を欠く旨の被告の主張には理由がない。また、これらの相違点に係る主張立証はなく、進歩性を欠く旨の被告の主張にも理由がない。なお、本件発明の構成要件Ｆに関する構成は、本件発明の課題の解決に密接した構成であり、乙９発明がこのような構成を欠く上、このような構成を採用でき たことを動機付けるような開示や示唆も存在しない以上、進歩性を欠く旨の被告の主張は、そもそも成り立たない。 １４ 争点２－６ あり、乙９発明がこのような構成を欠く上、このような構成を採用でき たことを動機付けるような開示や示唆も存在しない以上、進歩性を欠く旨の被告の主張は、そもそも成り立たない。 １４ 争点２－６（サポート要件違反の有無）について（被告の主張）⑴ 本件発明は、「アプリケーション」に含まれる「サービス」を表示するた めのものであり、上記「サービス」は、アプリケーションに含まれるものであることを前提としている。他方で、被告プログラムにおいて、ｄ払いは、被告プログラムと連携することで利用可能となるサービスであり、被告プログラムに含まれるサービスではない。仮に、本件発明が、ｄ払いというサービスを被告プログラムに連携させることで利用可能とする態様を、その技術 的範囲に含むというのであれば、本件発明が解決しようとする課題（所定の 情報を管理する装置内の情報を、その情報を閲覧するためのビューワで正確に閲覧できる）とは全く関係のない態様にまで権利範囲を拡張することになるから、本件発明は「当業者が当該発明の課題を解決できると認識できる範囲」を超えて拡張されることになる。 また、本件明細書等には、「アプリケーション」には含まれていないが、 「アプリケーション」と連携されることで利用されるサービスを想定した記載は存在しない。そのため、仮に、本件発明が、ｄ払いというサービスを被告プログラムに連携させることで利用可能とする態様を、その技術的範囲に含むというのであれば、発明の詳細な説明に記載されていない発明にまで、本件発明の技術的範囲を拡張することになる。 したがって、本件発明はサポート要件に違反する。 ⑵ 本件明細書【００７９】では「リーダライタ２０２からＣＬＦ２２４を経由して、ＵＩＣＣ２２２にサービス登録データ４３ 拡張することになる。 したがって、本件発明はサポート要件に違反する。 ⑵ 本件明細書【００７９】では「リーダライタ２０２からＣＬＦ２２４を経由して、ＵＩＣＣ２２２にサービス登録データ４３１を渡すことが出来る。」ことが示されており、ユーザが「セキュリティコード」等を入力すること等は全く想定されていない。しかしながら、原告は、前記４のとおり、被告プ ログラムにおいては、ｄ払いを登録するためにユーザの操作を要する態様となっているにもかかわらず、本件発明の構成要件Ｄを充足すると主張する。 このような解釈は、「前記アプリケーションの処理により前記サービスを登録する」という用語を不当に拡張解釈するものであって、「特許請求の範囲に記載された発明が、発明の詳細な説明に記載された発明」にまで技術的範 囲を拡張するものである。 したがって、この点においても、本件発明はサポート要件に違反する。 （原告の主張）⑴ 否認ないし争う。 ⑵ 被告は、本件発明における「アプリケーション」と「サービス」の提供主 体が一致していなければならないことを前提に、本件発明がサポート要件に 違反する旨主張する。しかしながら、本件発明が想定するサービスは、クレジット会社が主体となって提供するクレジットサービスや、例えばＪＲ等の交通各社が主体となって提供するトランスポート系のサービスを含んでおり、本件発明は、これらのサービスと連携するために必要なデータを他の装置から取得してサービスを登録し、アプリケーションでサービスを提供する ことを実現するものである。このような技術思想は、本件明細書【００３０】等の開示からも裏付けられるところである。特に、提供主体が異なるサービスでは、データ構成が様々であるため、サービス提供主体ごとに異なる方法に ものである。このような技術思想は、本件明細書【００３０】等の開示からも裏付けられるところである。特に、提供主体が異なるサービスでは、データ構成が様々であるため、サービス提供主体ごとに異なる方法によってアプリケーションに登録されると正しく表示できないという課題が存在したところ、本件明細書の開示に従って、既存のインフラを用いてサ ービスの登録を行うことで正しく表示ができる点に本件発明の意義が存在する。そうすると、上記のような本件発明の技術的意義に鑑みても、被告プログラムが、被告とは別の主体である訴外ドコモが主体として提供するｄ払いサービスと連携し、被告プログラム上でｄ払いサービスが提供できることは、本件明細書において、本件発明が解決しようとする課題として実質的に 開示されているところであり、サポート要件違反には当たらない。 ⑶ 被告は、「前記アプリケーションの処理により前記サービスを登録する」という用語について、ユーザの操作を要する態様を含むような解釈はサポート要件に違反する旨主張するが、前記４のとおり、本件発明は、ユーザによる情報入力を排除するものではなく、被告の主張には理由がない。 第４ 当裁判所の判断 １ 本件発明の内容証拠（甲２）によれば、本件明細書等には、次のとおりの記載があることが認められる。 ⑴ 背景技術 「携帯電話機が普及し、携帯電話機でさまざまなサービスが提供されている。図１Ａを参照するに、携帯電話機１１には、チップ１２が組み込まれており、このチップ１ ２に、サービス１３－１やサービス１３－２が書き込まれている。 また、サービス１３－１をユーザに提供する際の処理は、アプリケーション１４－１が行い、サービ ス１３－２をユーザに提供する際の処理は、アプリ ３－１やサービス１３－２が書き込まれている。 また、サービス１３－１をユーザに提供する際の処理は、アプリケーション１４－１が行い、サービ ス１３－２をユーザに提供する際の処理は、アプリケーション１４－２が行うように構成されている。」（【０００２】）「アプリケーションは、携帯電 話機上のソフトウェアに書き込まれる一連の実行可能なモジュールであり、チップ上に書き込まれるサービスとは異なる。携帯電話機には、非特許文献１に示すＭＩＤＰ２．０仕様に準拠した製品であればアプリケーション管理ソフト（ＡＭＳ: ApplicationManagementSoftware）が、非特許文献２に示すＭＩＤＰ１．０仕様に準拠した製品であれば同様の機能を持つＪＡＭ（Java （登録商標） ApplicationManager）が搭載されており、携帯電話に搭載されるアプリケーションの管理を行っている。ここでの管理とは、アプリケーションのダウンロード、インストール、削除といった一連の状態遷移を保持していることを指す。」（【０００３】）「アプリケーション管理ソフト１５は、まず、アプリケーション１４－１ が携帯電話機にインストールされた事を管理し、さらにアプリケーションが【図１Ａ、Ｂ】 サービス１３－１をチップ内に生成した際には、その情報も関連付けて管理する。同様にアプリケーション１４－２がインストールされた後にサービス１３－２をチップ内に生成した場合、その情報について関連付けを行う。例えば、アプリケーション管理ソフト１５は、アプリケーション１４－２を削除する場合、関連付けられているサービス１３－２を事前に削除する処理を 必要とする。」（【０００４】）「ここで図１Ｂに示すように、ユーザが携帯電話機１１から ５は、アプリケーション１４－２を削除する場合、関連付けられているサービス１３－２を事前に削除する処理を 必要とする。」（【０００４】）「ここで図１Ｂに示すように、ユーザが携帯電話機１１から携帯電話機３１に変えるときを考える。例えば、携帯電話機３１を購入する際、その購入した店で、携帯電話機１１から携帯電話機３１へのデータの移行のサービスが行われる。携帯電話機１１のチップ１２に記憶されているサービス１３－ １やサービス１３－２（以下、個々にサービス１３－１，１３－２を区別する必要がない場合、単にサービス１３と記述する。他も同様の記述とする）は、携帯電話機３１のチップ３２に移行される。また、アプリケーション管理ソフト１５の情報も、アプリケーション管理ソフト３３に移行される。しかしながら、チップ１２で管理されていない携帯電話機上のアプリケーショ ン１４は、携帯電話機３１に移行されない。」（【０００５】）「携帯電話機３１のアプリケーション管理ソフト３３は、チップ３２に記憶されているサービス１３があるが、それに対応するアプリケーション１４がないと、ユーザにサービス１３に対応するアプリケーション１４をダウンロードするように指示するメッセージを携帯電話機３１のディスプレイ上に 表示させる。ユーザが、そのメッセージに対する処理として、アプリケーション１４をダウンロードすることで、新しい携帯電話機３１でも、サービス１３を利用できる状態となる。」（【０００６】）⑵ 発明が解決しようとする課題「上記したように、現状、チップ１２でサービス１３が管理され、アプリ ケーション管理ソフト１５（３３）でアプリケーション１４との対応付けな どが行われているが、サービス１３をＵＩＣＣ（UniversalIntegr サービス１３が管理され、アプリ ケーション管理ソフト１５（３３）でアプリケーション１４との対応付けな どが行われているが、サービス１３をＵＩＣＣ（UniversalIntegratedCircuitCard)に記憶して管理することが考えられる。図２Ａに示すように、携帯電話機１１のＵＩＣＣ５１にサービス１３が記憶さ れている状態のとき、携帯電話機１１からＵＩＣＣ５１が外され、別の携帯電話機３１に、そのＵＩＣＣ５１が装着されると、携帯電話機３１でサービス１３が利用できるようになることが好ましい。」（【０００８】） 「この場合、ＵＩＣＣ５１に記憶されているサービス１３などは、差し込まれた携帯電話機３１側に移行されることになるが、アプリケーション管理ソフト１５の情報は、アプリケーション管理ソフト３３には移行されない。 その結果、アプリケーション管理ソフト１５で行われていた処理を、アプリケーション管理ソフト３３で行うことができず、結果として、ＵＩＣＣ５１ に記憶されているサービス１３が利用できない可能性がある。」（【０００９】）「そこで、図２Ｂに示すように、携帯電話機１１に、ビューワ（Viewer）７１を設けることが考えられる。このビューワ７１は、各携帯電話機が備え、ＵＩＣＣ５１が管理しているサービスな どを閲覧できるように構成される。例えば、携帯電話機１１に装着されていたＵＩＣＣ５１が外されて、携帯電話機３１に装着された場合、携帯電話機３１もビューワ７１を備えているため、そのビューワ７１ により、ＵＩＣＣ５１で管理されているサービスを閲覧することができる。」【図２Ａ】【図２Ｂ】 （【００１０】）「…アプリケーション１０３は、例えば、クレジットカードの により、ＵＩＣＣ５１で管理されているサービスを閲覧することができる。」【図２Ａ】【図２Ｂ】 （【００１０】）「…アプリケーション１０３は、例えば、クレジットカードの機能を実現するサービスを提供する ためのアプリケーションである。アプリケーション１０４は、例えば、交通機関に乗り降りするときの料金の支払いなどのときに用いられるトランスポート系のサービスを提供するためのアプリケーションである。」（【００１２】） 「アプリケーション１０５は、総合サービスを提供するためのアプリケーションであり、サービス１０６－１、サービス１０６－２、サービス１０６－３を提供する。例えば、サービス１０６－１は、クレジットの機能を実現するサービスであり、サービス１０６－２は、トランスポート系のサービスを提供するサービスであり、サービス１０６－３は、クーポンを提供するサ ービスである。」（【００１４】）「…アプリケーション１０５は、サービス１０６－１乃至１０６－３を提供するが、ビューワ７１は、ＵＩＣＣ内のアプリケーションマネージャ１０２上に登録されているアプリケーション１０３乃至１０５しか認識できず、アプリケーション１０５が提供するサービス１０６－１乃至１０６－３まで も認識して、その情報をユーザに提示することができない。」（【００１６】）「本発明は、このような状況に鑑みてなされたものであり、例えば、ＵＩＣＣなどの所定の情報を管理する装置内の情報を、その情報を閲覧するためのビューワで正確に閲覧できるようにし、かつそのための更新を既存のインフラを用いて行えるようにするものである。」（【００１７】） ⑶ 発明を実施するための形態【図３】 「［システムについて］図５は、本発 、かつそのための更新を既存のインフラを用いて行えるようにするものである。」（【００１７】） ⑶ 発明を実施するための形態【図３】 「［システムについて］図５は、本発明が適用されるシステムの一実施の形態の構成を示す図である。図５に示したシステムは、携帯電話機２０１とリーダライタ２０２から構成される。携帯電話 機２０１とリーダライタ２０２は、非接触により通信を行う。ここでは携帯電話機２０１として説明を続けるが、リーダライタ２０２と通信を行い、何らかのデータを保持するＩＣカードなどにも本発明を適用することができる。」（【００２６】） 「［携帯電話機２０１の構成について］図６は、携帯電話機２０１の内部構成を示す図である。携帯電話機２０１は、ホスト２２１、ＵＩＣＣ（UniversalIntegratedCircuitCard)２２２を含み、ホスト２２１とＵＩＣＣ２２２は、ＵＡＲＴ（UniversalAsynchronousReceiverTransmitter）２２３でデータの授受を行えるよう に接続されている。また、携帯電話機２０１とリーダライタ２０２との非接触な通信を制御するＣＬＦ（ContactlessFrontend）２２４も、携帯電話機２０１は含む構成とされている。」【００２７】「また例えば、第３アプリケーション２５６は、総合サービスを提供するためのアプリケーションである。後述するように、第３アプリケーション２ ５６は、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。図６には図示していないが、図１４を参照して後述するように、ＵＩＣＣ２２２にサービスが追加 ポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。図６には図示していないが、図１４を参照して後述するように、ＵＩＣＣ２２２にサービスが追加で登録されることがあり、ＵＩＣＣ２２２は、登録されたサービスを記憶し、管理する機能も有する。各 アプリケーションは、アプリケーションマネージャ２５２によって、管理さ【図５】 れるものであるが、同じ実行環境で管理される事に限定されない。一例として、アプリケーションマネージャ２５２がＪａｖａＣａｒｄＴＭを搭載し、１つのアプリケーションがソフトウェアにより実現されていても、他のアプリケーションが、ＲＯＭの工場出荷時に書き込まれている場合や、別チップとして提供される場合もあり得る。」（【００３０】） 「…図６に示したように、ＵＩＣＣ２２２で、第１アプリケーション２５４、第２アプリケーション２５５、および第３アプリケーション２５６が管理されている とき、ビューワ２４１による処理が実行されると、例えば、図１２に示すような画面がユーザに提供される。画面とは、例えば、携帯電話機２０１のディスプレイ ４０１に表示される画面のことである。」（【００７４】）「図１２に示すようにビューワ２４１は、アプリケーションマネージャ２５２が認識した第１アプリケーション２５４、第２アプリケーシ ョン２５５、第３アプリケーション２５６を認識する。そしてビューワ２４１は、第１アプリケーション２５４が提供するサービスの名称である＂第１サービス＂、第２アプリケーション２５５が提供するサービスの名称である＂第２サービス＂、および第３アプリケーション２５６が提供する サービスの名称である＂第３サービス＂を、ディスプレイ る＂第１サービス＂、第２アプリケーション２５５が提供するサービスの名称である＂第２サービス＂、および第３アプリケーション２５６が提供する サービスの名称である＂第３サービス＂を、ディスプレイ４０１に表示させ【図１２】【図６】 る。」（【００７５】）「第３アプリケーション２５６は、総合サービスであり、図１３に示すように複数のサービスを提供できる。すなわち、図１３に示した例では、第３アプリケーション２５６は、第３－ １サービス２５７、第３－２サービス２５８、および第３－３サービス２５９を提供できるように構成されている。」（【００７６】）「このように、第３アプリケーション２５６が、第３－１サービス２５７、第３－２サービス２５８、および第３－３サービス２５９を提供できる場合 であっても、ビューワ２４１は、アプリケーションマネージャ２５２上に登録されている第１アプリケーション２５４、第２アプリケーション２５５、第３アプリケーション２５６しか認識できず、第３－１サービス２５７、第３－２サービス２５８、および第３－３サービス２５９までも認識して、その情報をユーザに提示することができない。」（【００７７】） 「これは、レジストリ２５３で、登録されているサービスの情報が管理されているからである。ここで、アプリケーションやサービスの登録について説明する。」（【００７８】）「図１４に示すように、ＵＩＣＣ２２２に第３－１サービス２５７が登録されていない状態（登録されていないことを示すために、図１４おいては、 点線で示す。またアプリケーションなどは図示していない）のときに、第３－１サービス２５７を登録する際、ＵＩＣＣ２２２の外部から、サービスを登録するためのデータ４３１が送信される。サービスを登録 点線で示す。またアプリケーションなどは図示していない）のときに、第３－１サービス２５７を登録する際、ＵＩＣＣ２２２の外部から、サービスを登録するためのデータ４３１が送信される。サービスを登録するためのデータは、サービス登録データとする。このサービス登録データ４３１は、第３－１サービス２５７を登録するためのものである。このようなサービス登録 データ４３１によるサービスの登録は、現状でも行われているインフラを用【図１３】 いて行うことができる。図１４を使って説明すると、リーダライタ２０２からＣＬＦ２２４を経由して、ＵＩＣＣ２２２にサービス登録データ４３１を渡すことが出来る。または、ホスト２２１からＵＡＲＴを経由して、ＵＩＣＣ２２２にデータを渡すことも可能である。」（【００７９】）「しかしながら、サービス登録データ４３１で第３－１サービス２５７を 登録しても、アプリケーションマネージャ２５２のレジストリ２５３には、第３－１サービス２５７の情報は登録されない。そのため、そのようなサービスが登録されたことが認識できない。よって、レジストリ２５３で管理されている情報を更新するために、サービス種別や名前を登録するための処理が行われる必要がある。」（【００８０】） 「例えば、サービス種別・名前コマンド４３２をアプリケーションマネージャ２５２に対して送信し、アプリケーションマネージャ２５２での管理情報（レジストリ２５３内の情報）を更新する必要がある。この場合、第３アプリケーション２５６には、第３－１サービス２５７が含まれること（新た【図１４】 に登録されたこと）を、サービス種別・名前コマンド４３２でアプリケーションマネージャ２５２のレジストリ２５３に登録する必要がある。」（【００８１】）「既 れること（新た【図１４】 に登録されたこと）を、サービス種別・名前コマンド４３２でアプリケーションマネージャ２５２のレジストリ２５３に登録する必要がある。」（【００８１】）「既存のインフラをできる限り生かしつつも、ビューワ２４１で、個々のサービスが閲覧できるようにするためには、上記したように、サービス登録デ ータ４３１とサービス種別・名称コマンド４３２をそれぞれ送信してサービス名を登録することが考えられる。…」（【００８３】）「図７乃至１１を参照して説明したように、第１アプリケーション２５４、第２アプリケーション２５５、第３アプリケーション２５６のそれぞれは、複数の通信路によりアクセス可能である。第３アプリケーション２５６は、 通信路３５１乃至３５４（図９）があるため、例えば、通信路３５１で、第３－１サービス２５７を登録し、通信路３５２で、レジストリ２５３の情報を更新することができる。」（【００８４】）「このようなことを可能にするためには、リーダライタ２０２が、携帯電話機２０１に対して登録や更新の処理を実行するとき、どの通信路を用いて 登録を行い、どの通信路を用いて更新を行うかを判断し、その判断に基づき、適切なコマンド、例えば、選択した通信路に適合したプロトコルのパケットでのコマンドを生成する必要がある。」（【００８５】）「［リーダライタの構成について］そこで、リーダライタ２０２は、図１５ に示すような機能を有する構成とされる。 すなわち、リーダライタ２０２は、通信制御部５０１、通信方式決定部５０２、サービス登録部５０３、および更新処理部５０４を備える。通信制御部５０１は、所定の アプリケーション（例えば、第３アプリケ【図１５】 ーション２５６）と、アプリケ 定部５０２、サービス登録部５０３、および更新処理部５０４を備える。通信制御部５０１は、所定の アプリケーション（例えば、第３アプリケ【図１５】 ーション２５６）と、アプリケーションで提供されるサービス（例えば、第３－１サービス２５７）を管理するアプリケーションマネージャ２５２を備えるＵＩＣＣ２２２との非接触な通信を制御する。」（【００８６】）「通信方式決定部５０２は、ＵＩＣＣ２２２に対して所定のサービスの登録を行うときの通信方式と、レジストリ２５３に対する更新を行うときの通 信方式をそれぞれ決定する処理を行う。」（【００８７】）「サービス登録部５０３は、通信方式決定部５０２により決定された通信方式で、ＵＩＣＣ２２２に所定のサービスを登録するためのコマンドの生成などを実行する。更新処理部５０４は、通信方式決定部５０２により決定された通信方式で、ＵＩＣＣ２２２のレジストリ２５３で管理されている情報 を更新するためのコマンドの生成などを実行する。」（【００８８】） ２ 争点１－１（「前記アプリケーションで提供されるサービス」〔構成要件Ｂ〕の充足性）について⑴ 「前記アプリケーションで提供されるサービス」の意義本件発明の構成要件Ｂは、「前記アプリケーションで提供されるサービス に関する情報を管理し」と規定しているところ、本件発明の構成要件は、その他に「アプリケーション」と「サービス」の内容及び関係を規定するものではない。そして、本件明細書等は、「アプリケーション」と「サービス」の内容及び関係につき、「アプリケーション１０３は、例えば、クレジットカードの機能を実現するサービスを提供するためのアプリケーションであ る。」（【００１２】）、「アプリケーション１０５は、総合サービスを提供する 「アプリケーション１０３は、例えば、クレジットカードの機能を実現するサービスを提供するためのアプリケーションであ る。」（【００１２】）、「アプリケーション１０５は、総合サービスを提供するためのアプリケーションであり、サービス１０６－１、サービス１０６－２、サービス１０６－３を提供する。例えば、サービス１０６－１は、クレジットの機能を実現するサービスであり、サービス１０６－２は、トランスポート系のサービスを提供するサービスであり、サービス１０６－３は、 クーポンを提供するサービスである。」（【００１４】）、「第３アプリケ ーション２５６は、総合サービスを提供するためのアプリケーションである。 後述するように、第３アプリケーション２５６は、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。」（【００３０】）と記載されていることが認められる。 本件発明の構成要件の上記規定及び本件明細書等の上記記載によれば、構成要件Ｂにいう「アプリケーション」は、複数のサービスを提供するものであり、構成要件Ｂにいう「前記アプリケーションで提供されるサービス」は、機能を実現するものである以上、アプリケーション自体がクレジット機能、クーポン機能その他の機能そのものを提供するものに限られると解するのが 相当である。 ⑵ 被告プログラムの充足性前記前提事実に加え、証拠（甲５ないし１０、１４）及び弁論の全趣旨によれば、被告プログラムは、ＧｏＰａｙというタクシー料金の決済機能を備えており、ＧｏＰａｙは、ｄ払いと連携することによって初めてｄ払いを利 用することができるようになること、他方、ｄ払いは、訴外ドコモが提供する決済機 ＧｏＰａｙというタクシー料金の決済機能を備えており、ＧｏＰａｙは、ｄ払いと連携することによって初めてｄ払いを利 用することができるようになること、他方、ｄ払いは、訴外ドコモが提供する決済機能であり、タクシーを利用した際にその利用したタクシー料金に限り利用することができるにとどまり、これ以外の場面では決済手段として使用することができないこと、以上の事実が認められる。 上記認定事実によれば、被告プログラムにおけるｄ払いは、タクシー料金 の個別の支払ごとにその都度利用されるにとどまるものであるから、被告プログラム自体がｄ払いという決済機能そのものを提供するものとはいえない。 したがって、被告プログラムは、本件発明の構成要件Ｂにいう「前記アプリケーションで提供されるサービス」を充足するものとはいえない。 ⑶ 原告の主張に対する判断 原告は、本件発明の特許請求の範囲の文言上「提供するサービス」という 記載にはなっていないから、「サービス」の提供主体と「アプリケーション」の提供主体とが法的に同一主体でなければならないという限定はなく、本件明細書等【００３０】の記載によれば、各サービスが様々な主体によって提供されるものであることは、当業者のみならず一般人にとっても技術常識に属する事項であるから、アプリケーションと各サービスが異なる法的主体に よって提供される場合も当然に含まれるものである旨主張する。 しかしながら、本件発明の構成要件は、「アプリケーション」と「サービス」の内容及び関係を一義的に規定するものではないから、本件明細書等を参酌しない限り、その関係等が明らかにならないことは、上記において説示したとおりである。そして、本件明細書等のうち、「アプリケーション」と 「サービス」の内容及び関係につき記載 本件明細書等を参酌しない限り、その関係等が明らかにならないことは、上記において説示したとおりである。そして、本件明細書等のうち、「アプリケーション」と 「サービス」の内容及び関係につき記載した部分（【００１２】、【００１４】、【００３０】）を参酌すれば、「アプリケーション」は、総合サービスを提供するものであり、構成要件Ｂにいう「前記アプリケーションで提供されるサービス」は、アプリケーション自体がクレジット機能、クーポン機能その他の機能そのものを提供するものに限られると解するのが相当である から、タクシー料金の個別の支払ごとにその都度利用されるｄ払いを含むものではないと解するのが相当である。 したがって、サービスの提供主体の同一性についていう原告の上記主張は、充足性の判断を左右するものとはいえず、採用することができない。 ３ 充足論に関するその余の争点（争点１－２ないし争点１－５）について 前記２のとおり、本件発明にいう「サービス」とは、アプリケーションで「提供」される機能をいうところ、被告プログラムは、ｄ払いを「提供」するものとはいえない。したがって、原告の主張は、上記において説示したところを踏まえると、いずれも採用することができない。 ４ 争点２－１－３（乙１－３発明に基づく新規性、進歩性の有無）について 前記２及び３のとおり、被告プログラムは、本件発明の構成要件を充足しな いから、本件発明の技術的範囲に属するものとはいえず、その余の争点を判断するまでもなく、原告の請求は理由がないことになる。もっとも、本件の事案に鑑み、本件の中核的争点の一つである争点２－１－３に限り、念のため、以下簡潔に判断を示しておくこととする。 ⑴ 乙１文献及び乙５報道資料には、以下の記載等が存在する。 ア も、本件の事案に鑑み、本件の中核的争点の一つである争点２－１－３に限り、念のため、以下簡潔に判断を示しておくこととする。 ⑴ 乙１文献及び乙５報道資料には、以下の記載等が存在する。 ア乙１文献「マクドナルドの新商品など、おすすめ情報をいち早くチェックできたり、マクドナルドで使える割引クーポン『かざすクーポン』をダウンロードして使ったりすることができます。」「『かざすクーポン』のご利用は、『トクするケータイサイト』への会 員登録後、アプリからお好みのクーポンを選択・設定し、マクドナルドの店頭に設置されている読み取り機にかざしてご利用ください。」イ乙５報道資料「『かざすクーポン』とは、マクドナルドがドコモ、ＴｈｅＪＶと協力して、２００８年５月から外食産業初のサービスとして展開している携帯 電話向けアプリケーション『トクするアプリ』を活用したクーポンです。」「利用方法：『トクするアプリ』を立ち上げると、サーバーから配信されてくる『かざすクーポン』を受け取ることができます。配信された『かざすクーポン』の中から購入したいクーポンと数量を選択しておサイフケ ータイをレジ横のリーダーライターにかざすだけで、オーダーがレジに反映される仕組みです。」⑵ 乙１－３発明の内容前記⑴の記載に加え、証拠（乙１、５）及び弁論の全趣旨によれば、乙１－３発明は、ｉモード対応携帯電話に、ｉモードサイトからダウンロードし て使用するｉアプリの一つであるマクドナルドトクするアプリに関するものであること、同アプリにおいては、メニュー画面において、「スタンプサービス」、「サポートサービス」のほか「クーポンを選ぶ」、「選んだクーポン」という選択画面が表示されており、「クーポンを選ぶ」を選択すると、サーバから最新のク は、メニュー画面において、「スタンプサービス」、「サポートサービス」のほか「クーポンを選ぶ」、「選んだクーポン」という選択画面が表示されており、「クーポンを選ぶ」を選択すると、サーバから最新のクーポン（かざすクーポン）がダウンロードされること、 その中から利用したいクーポンを選択し、利用クーポンを決定した場合には、マクドナルドの店頭に設置されている読み取り機に、上記携帯電話に表示されている当該クーポンをかざして、これを利用することができることが認められる。 以上を踏まえると、乙１文献及び乙５報道資料には、乙１－３発明の構成 として、次の各構成が開示されていると認めるのが相当である。 ａ１３''：携帯電話に、「マクドナルドトクするアプリ」を記憶し、ｂ１３''：「マクドナルドトクするアプリ」で提供される各種クーポンを選択・設定することができる割引サービス（かざすクーポンサービス）に関する情報を管理し、 ｃ１３''：サーバからダウンロードした上記各種クーポンを登録するためのデータを取得し、ｄ１３''：上記データに基づき、「マクドナルドトクするアプリ」の処理により上記各種クーポンを登録し、ｅ１３''：上記各種クーポンに関する情報を生成し、 ｆ１３'''：上記各種クーポンに関する情報の表示を制御する ｇ１３’：ステップを含む処理を実行させるためのプログラム。 ⑶ 対比ア本件発明と乙１－３発明を対比すると、本件発明の「コンピュータ」、「所定のアプリケーション」が、乙１－３発明における「携帯電話」及び「マクドナルドトクするアプリ」に相当することは、当事者間に争いがい ない。 また、本件発明の特許請求の範囲及び本件明細書等（【００１４】）の記載によれば、本件発明の「前記アプリケーシ 」及び「マクドナルドトクするアプリ」に相当することは、当事者間に争いがい ない。 また、本件発明の特許請求の範囲及び本件明細書等（【００１４】）の記載によれば、本件発明の「前記アプリケーションで提供されるサービス」には、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスが含まれると解するのが相当である。 これを乙１－３発明についてみると、前記⑴及び⑵のとおり、乙１－３発明において、マクドナルドトクするアプリは、各種クーポンを選択・設定できる割引サービスを提供する機能を有することが認められ、このような機能は、本件発明における「サービス」と同一の構成であると解するのが相当である。そうすると、本件発明における「前記アプリケーションで 提供されるサービス」とは、マクドナルドトクするアプリにおいて、各種クーポンを選択・設定できる割引サービス（かざすクーポンサービス機能）に相当するものといえる。 これに対し、原告は、乙１－３発明における「かざすクーポン」サービス機能が本件発明における「アプリケーションで提供されるサービス」に 相当する場合には、マクドナルドトクするアプリ自体に当初から「かざすクーポン」サービス機能が含まれているから、他の装置から「かざすクーポン」サービス機能を登録するためのデータを取得するものとはいえない旨主張する。 そこで検討するに、本件明細書（【００１９】、【００２０】、【００ ２１】、【００７９】等）の記載によっても、本件発明における「登録」 （構成要件Ｃ、Ｄ、Ｅ）を明確に定義する記載は認められず、技術常識及び弁論の全趣旨を踏まえても、上記にいう「登録」は、アプリケーションがサービスの提供を実現可能にするという意味として理解するのが相当 （構成要件Ｃ、Ｄ、Ｅ）を明確に定義する記載は認められず、技術常識及び弁論の全趣旨を踏まえても、上記にいう「登録」は、アプリケーションがサービスの提供を実現可能にするという意味として理解するのが相当である（同旨をいうものとして原告技術説明会資料２６頁）。 これを乙１－３発明についてみると、上記において説示したとおり、乙 １－３発明のマクドナルドトクするアプリが、本件発明にいう「アプリケーション」に相当し、乙１－３発明の「かざすクーポン」サービス機能が、本件発明にいう「アプリケーションで提供されるサービス」に相当するところ、サーバから配信される各種クーポンデータは、「かざすクーポン」サービス機能の提供を実現可能にするためのデータであるから、サーバか ら配信される各種クーポンデータは、「前記サービスを登録するためのデータ」（構成要件Ｃ）に相当するものと認めるのが相当である。 したがって、原告の主張は、採用することができない。 イ以上によれば、本件発明と乙１－３発明には、以下の相違点が存在し、その余は一致するものと認められる。 （相違点１－３－１）本件発明は、「前記アプリケーションによりコマンドが処理されることで」、「前記サービスに関する情報」が「生成される」ものである（構成要件Ｆ）のに対し、乙１－３発明では、このような構成がないこと。 ⑷ 相違点１－３－１の容易想到性 前記⑴に加え、証拠（乙１、５）及び弁論の全趣旨によれば、乙１－３発明におけるクーポンを選択・設定するという画面の表示について、「コマンドが処理されることで生成される」旨の開示はないものの、乙１－３発明によれば、かざすクーポンで選択・設定された「クーポン」は、携帯電話の画面に表示されるのであるから、当該表示データは、アプリの利用者がクーポ されることで生成される」旨の開示はないものの、乙１－３発明によれば、かざすクーポンで選択・設定された「クーポン」は、携帯電話の画面に表示されるのであるから、当該表示データは、アプリの利用者がクーポ ンを選択する操作に基づき生成されていると認めるのが相当である。 そうすると、乙１－３発明に接した当業者は、乙１－３発明に「コマンドが処理されることで生成される」という記載がないとしても、上記操作をコマンドに置き換えて上記画面を表示させる構成を容易に想到することができるといえる。 したがって、乙１－３発明に接した当業者が乙１－３発明から出発して相 違点１－３－１の構成に至ることは、容易であるといえる。 ⑸ 小括以上によれば、本件発明は、乙１－３発明に基づき進歩性を欠くものといえる。 なお、原告は、乙１－３発明に関する無効主張のうち、予備的主張につい ては時機に後れた主張であって却下されるべきである旨主張するが、これにより訴訟の完結を遅延させるものとはいえず、上記主張は採用の限りではない。 ５ その他その他に、原告の主張及び提出証拠を改めて検討しても、原告は、本件発明 にいう「アプリケーション」と「サービス」の内容及び関係を正解するものとはいえず、この点を中核的争点として実施された技術説明会（専門委員３名参加）の結果を踏まえても、原告の主張は、いずれも採用することができない。 第５ 結論よって、原告の請求はいずれも理由がないからこれらを棄却することとして、 主文のとおり判決する。 東京地方裁判所民事第４０部 裁判長裁判官 中島基至 裁判官 地方裁判所民事第４０部 裁判長裁判官 中島基至 裁判官 武富可南 裁判官 坂本達也 （別紙）被告プログラム目録 「ＧＯ タクシーが呼べるアプリ旧ＭＯＶ×ＪａｐａｎＴａｘｉ」以上 （別紙）特許権目録⑴ 発明の名称情報処理装置、情報処理方法、並びにプログラム⑵ 出願番号特願２０１５－２３８２４０号⑶ 出願日平成２７年（２０１５年）１２月７日 ⑷ 原出願日平成２２年（２０１０年）６月２８日⑸ 登録日平成２９年（２０１７年）４月２１日⑹ 特許番号特許第６１２８４０２号以上 （別紙）被告プログラム説明書（原告の主張） １ 被告プログラムの構成⑴ 機種変更が行われていないときの被告プログラムの構成Ａ’：被告プログラムは、ユーザのスマートフォンに、アプリである被告プロ グラムを記憶させる処理を実行する。 Ｂ’：被告プログラムは、前記被告プログラムで提供される、ＧＯＰａｙに登録される支払サービス（ｄ払い）に関する情報を管理する処理を実行させる、Ｃ’：被告プログラムは、ｄ払い用サーバから受信した前記ｄ払いサービスを登録するためのデータ（セキュリティコード及び／又は承諾番号）を取得す る処理を実行させるＤ’：被告プログラムは、取得された前記セキュリティコード及び／又は承諾番号に基づき、前記被告プログラムの処理により前記ｄ払い ュリティコード及び／又は承諾番号）を取得す る処理を実行させるＤ’：被告プログラムは、取得された前記セキュリティコード及び／又は承諾番号に基づき、前記被告プログラムの処理により前記ｄ払いサービスを登録する処理を実行させるＥ’：被告プログラムは、登録された前記サービス（ｄ払い）に関する情報を 生成する処理を実行させるＦ’：被告プログラムは、前記アプリケーション（被告プログラム）によりコマンドが処理されることで生成される前記サービス（ｄ払い）に関する情報の表示を制御する（なお、被告プログラムは、コンピュータプログラムである以上、別紙被告プ ログラム説明書に記載した各画面遷移が、被告プログラムにおけるコマンド処理によって実現されていることは当然である。）Ｇ’：被告プログラムは、Ａ’ないしＦ’のステップを含む処理を実行させるためのプログラムである。 ⑵ 被告プログラムの説明（甲３、４）被告プログラムは、ＧｏｏｇｌｅＰｌａｙやＡｐｐＳｔｏｒｅ等で配信される、いわゆる、「アプリ」であり、被告プログラムをインストールしたユーザの情報端末装置（スマートフォン）に対して、以下の動作を実行させるものである。 【甲３、AppStoreにおける被告プログラムの画面】 【甲４、ＧｏｏｇｌｅＰｌａｙにおける被告プログラムの画面】 ユーザが、ＧｏｏｇｌｅＰｌａｙやＡｐｐＳｔｏｒｅ等から上記被告プログラムをスマートフォンにダウンロードすると、被告プログラム（ＧＯアプリ）がユーザのスマートフォンに記憶される。 【写真１：スマートフォンホーム画面にＧＯアプリが追加された様子（赤丸は強調）】 にダウンロードすると、被告プログラム（ＧＯアプリ）がユーザのスマートフォンに記憶される。 【写真１：スマートフォンホーム画面にＧＯアプリが追加された様子（赤丸は強調）】 被告プログラム（ＧＯアプリ）では「ＧＯＰａｙ」と呼ばれるサービスを利用することが可能であり、ユーザはタクシー乗車の支払決済手段として、クレジットカード及び／又は「d 払い」（ネットショッピングや街の店で利用できる決済サービスであり、ＮＴＴドコモの携帯回線を保有するユーザであれば、支払いを月々の携帯電話料金と合算できる。）を登録することが可能である。 【甲５、被告ウェブサイトより】 被告プログラムにおいて、ユーザがタクシー料金の決済手段としてｄ払いを 利用できるようにするためには、「ＧＯ」アプリとユーザのｄアカウントとを連携する必要がある（甲６ないし８）ところ、「ＧＯ」アプリでの「ｄ払い」登録が未了の場合における、「ＧＯ」アプリにおけるｄアカウント連携方法は次の①～⑨で示されるとおりである。 ①「ＧＯ」アプリのトップ画面右下の「ＧＯＰａｙ」アイコンから、ユーザが 「支払い方法」、「変更」を押すと、「支払い方法一覧」画面へと遷移する。 この場面において、ユーザは、さらに、「＋支払い方法を追加」を選択する（写真２～４）。 【写真２：被告ウェブサイト（甲５）より。アプリトップ画面に「GOPay」が表示】 【写真３：「支払い方法」「変更」が表示される（個人情報はマスキング）】 【写真４：「支払い方法一覧」画面（個人情報はマスキング）】 ② 「支払い方法を追加」画面に進み、「d 払い」を登録する（写真５） 【写真５：「支払い方法を追加 【写真４：「支払い方法一覧」画面（個人情報はマスキング）】 ② 「支払い方法を追加」画面に進み、「d 払い」を登録する（写真５） 【写真５：「支払い方法を追加」画面】 ③「d 払い連携前のご確認」と題するページに遷移するので「同意する」を選択する（写真６） 【写真６：「ｄ払い連携前のご確認」画面】 ④「ｄ払いの利用承諾」と題する画面に遷移し、NTTDoCoMo からセキュリティコードが送付されてくる（写真７及び８）。 【写真７：「ｄ払いの利用承諾」画面（個人情報はマスキング）】 【写真８：セキュリティコードの送付（個人情報はマスキング）】 ⑤送付されてきたセキュリティコードを入力し、「ログイン」ボタンを押す（写真９） 【写真９：セキュリティコードの入力及びログイン（個人情報はマスキング）】 ⑥ 上記⑤の「d 払いの利用承諾」画面における「ログイン」押下後に遷移した「ｄ払いの利用承諾」画面において、決済情報としてNTTDoCoMo のsp モードパスワードを入力すると、「承諾完了」の表示とともに、「承諾番号」が表示される（写真１０及び１１）。 【写真１０：ｓｐモードパスワード入力画面】 【写真１１：「ｄ払いの利用承諾」画面（承諾完了）】 ⑦ 上記⑥（写真１１）で「次へ」ボタンをクリックすると、GOPay の「支払い方法一覧」画面に「ｄ払い」が追加される（写真１２）。 【写真１２：「支払い方法一覧」画面（ｄ払い登録）】 ⑧ 上記⑦「支払い方法一覧」（写真１２）において「ｄ払い」をクリックすると、「ｄ が追加される（写真１２）。 【写真１２：「支払い方法一覧」画面（ｄ払い登録）】 ⑧ 上記⑦「支払い方法一覧」（写真１２）において「ｄ払い」をクリックすると、「ｄポイントキャンペーン」、「ｄアカウント」、「連携済み」として「ｄアカウントの連携が完了しました」との表示がなされる（写真１３） 【写真１３：「ｄポイントキャンペーン」「ｄアカウント」「連携済み」画面】 ⑨ 上記完了後、ＧＯアプリトップページにおいて「メニュー」を押した後、「支払い方法」を押すと、クレジットカード及びｄ払いからなる支払い方法が一覧される（写真１４～１６）。 【写真１４：アプリトップページにおいて「メニュー」を選択】 【写真１５：「メニュー」画面において「支払い方法」を選択】 【写真１６：「支払い方法一覧」画面】 ２ ユーザにおいてスマートフォンの機種変更が行われた場合における被告プログラムの構成（甲９，１０）⑴ 被告プログラムの構成Ａ’’：被告プログラムは、ユーザのスマートフォン（機種変更前）に、アプリである被告プログラムを記憶させる処理を実行する（甲９、写真１等）。 Ｂ’’：被告プログラムは、機種変更前のユーザのスマートフォンにおいて、前記被告プログラムで提供される、ＧＯＰａｙに登録される支払サービス（ｄ払い）に関する情報を管理する処理を実行させる（甲９、写真１２や１６等）Ｃ’’：被告プログラムは、機種変更前のユーザのスマートフォンにおいて、ｄ払い用サーバから受信した前記ｄ払いサービスを登録するためのデータ（セキ ュリティコード及び／又は承諾番号）を取得する処理を実行させる（甲９、写真７、８及び１１等） ートフォンにおいて、ｄ払い用サーバから受信した前記ｄ払いサービスを登録するためのデータ（セキ ュリティコード及び／又は承諾番号）を取得する処理を実行させる（甲９、写真７、８及び１１等）Ｄ’’：被告プログラムは、機種変更前のユーザのスマートフォンにおいて、取得された前記セキュリティコード及び／又は承諾番号に基づき、前記被告プログラムの処理により前記ｄ払いサービスを登録する処理を実行させる（甲９、 写真１２、１３及び１６等）Ｅ’’：被告プログラムは、機種変更前のユーザのスマートフォンにおいて、登録された前記サービス（ｄ払い）に関する情報を生成する処理を実行させるＦ’’：被告プログラムは、機種変更後のユーザのスマートフォンにおいて、前記アプリケーション（被告プログラム）によりコマンドが処理されることで生 成される前記サービス（ｄ払い）に関する情報の表示を制御する（甲１０、写真１１参照）（なお、被告プログラムは、コンピュータプログラムである以上、別紙被告プログラム説明書に記載した各画面遷移が、被告プログラムにおけるコマンド処理によって実現されていることは当然である。） Ｇ’’：被告プログラムは、Ａ’’～Ｆ’’のステップを含む処理を実行させるためのプ ログラムである。 ⑵ 被告プログラムの説明スマートフォンの機種変更を行った場合に、機種変更前の端末及び機種変更後の端末それぞれにおける被告プログラムの支払い方法一覧の表示は、以下のとおりである（なお、個人情報については、一部マスキング・モザイク化して いる）。 機種変更前の端末におけるＧＯ社アプリの支払い方法一覧 【写真１：機種変更前端末におけるＧＯ社アプリ支払い方法一覧画面】 ② 機種変更後 化して いる）。 機種変更前の端末におけるＧＯ社アプリの支払い方法一覧 【写真１：機種変更前端末におけるＧＯ社アプリ支払い方法一覧画面】 ② 機種変更後の端末においてＧＯ社アプリをインストールする 【写真２：機種変更後端末におけるＧＯ社アプリインストールの様子】 ➂ 以下の操作によって従前の機種変更前のスマートフォンにおけるＧＯ社アプリのデータが引き継がれる 【写真３：機種変更前のスマートフォンにおいてアカウントを保持する者が機種変更後の スマートフォンに対してアカウントログイン情報を入力する画面】 【写真４：機種変更後端末のＧＯ社アプリに対してＧＯ社アプリアカウントのログイン情報を入力する様子】 【写真５：ＧＯ社アプリのアカウント情報に登録された電話番号宛に認証コードが送付される】 【写真６：写真５に続き認証コードが送付されてきた画面】 【写真７：送付されてきた認証コードを入力する】 【写真８：認証コードの入力によって認証する】 【写真９：「ご登録ありがとうございます」という画面が表示される】 【写真１０：機種変更前端末のＧＯ社アプリで登録されていたアカウント情報が機種変更後端末のＧＯ社アプリで復活している】 ④ 機種変更後の端末においてＧＯ社アプリの支払い方法一覧を確認すると機種変更前の端末において登録されていた支払い方法（写真１１左）と同じ支払い方法が表示される（写真１１右） 【写真１１：機種変更後端末のＧＯ社アプリで「支払い方法一覧」を確認すると、機種変 更前端末のＧＯ社アプリで ていた支払い方法（写真１１左）と同じ支払い方法が表示される（写真１１右） 【写真１１：機種変更後端末のＧＯ社アプリで「支払い方法一覧」を確認すると、機種変 更前端末のＧＯ社アプリで登録されていた「支払い方法一覧」と同一の支払い方法が登録されている】 ⑤ 機種変更前の端末のＧＯ社アプリからはログアウトされる。 【写真１２：機種変更前端末のＧＯ社アプリからログアウトされた様子】以上
▼ クリックして全文を表示