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

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