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