令和7(行ケ)10105等審決取消請求事件

令和８年９月３０日判決言渡

令和７年（行ケ）第１０１０５号 審決取消請求事件（以下「第１事件」という。）

令和７年（行ケ）第１０１０７号 審決取消請求事件（以下「第２事件」という。）

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

判 決

第１事件原告兼第２事件被告 Ｓ．ＲＩＤＥ株式会社

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

同 高 石 秀 樹

同 奥 村 直 樹

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

同 鈴 木 信 彦

第１事件被告兼第２事件原告 Ｇ Ｏ 株 式 会 社

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

同 多 田 宏 文

主 文

１ 特許庁が無効２０２３－８０００５１号事件について令和７年９月１９

日にした審決のうち、「特許第６８９２６５６号の請求項１、３、６、１

１に係る発明についての本件審判請求は成り立たない。」との部分を取り

消す。

２ 第１事件被告兼第２事件原告の請求を棄却する。

３ 訴訟費用は第１事件被告兼第２事件原告の負担とする。

事 実 及 び 理 由

（注）本判決で用いる略語の定義は、別に定めるほか、次のとおりである。なお、本文中の【】は特許公報等の段落番号を、【図】はその図面番号を示す。原告 ：第１事件原告兼第２事件被告Ｓ．ＲＩＤＥ株式会社被告 ：第１事件被告兼第２事件原告ＧＯ株式会社

5 本件審決 ：特許庁が無効２０２３－８０００５１号事件について令和７年９月１９日にした審決本件特許 ：被告を特許権者とし、発明の名称を「精算システム、ホスト端末、精算方法、プログラム及び車両」とする特許第６８９２６５６号に係る特許本件各発明：本件特許の請求項１、３、６～１１に係る発明の総称。各請求項に係る発明は、請求項の番号に対応して「本件発明１」の要領で表記する。本件明細書：本件特許に係る明細書及び図面（乙２）当初明細書等：本件特許の出願に係る願書に最初に添付した明細書、特許請求の範囲及び図面（乙６）甲１公報 ：韓国公開特許第１０－２０１０－０１２９５３１号公報（甲１）甲１発明 ：甲１公報に記載された発明甲４１公報：特開２００４－３４１９２０号公報（甲４１）甲４１発明：甲４１公報に記載された発明甲１１公報：特開２００６－１５５４３０号公報（甲１１）甲１１記載技術：甲１１公報に記載された技術

第１ 請求

１ 第１事件主文第１項同旨２ 第２事件本件審決のうち、「特許第６８９２６５６号の請求項７～１０に係る発明についての特許を無効とする。」との部分を取り消す。

第２ 事案の概要

第１事件は、本件特許の特許無効審判請求（以下「本件審判請求」という。）

に係る、本件特許の特許請求の範囲を被告の請求するとおりに訂正することを認

5 め、本件各発明の一部についての特許を無効とし、その余の発明についての本件審判請求を不成立とする本件審決について、原告が、本件審決のうち本件審判請求を不成立とする部分を取り消すことを求める事案であり、第２事件は、本件審決について、被告が、本件審決のうち本件各発明の一部についての特許を無効とする部分を取り消すことを求める事案である。争点は、本件審決の進歩性、補正要件、サポート要件及び明確性要件に係る各判断の当否である。１ 特許庁における手続の経緯等（当事者間に争いがない。）

⑴ 被告は、令和２年１月９日、発明の名称を「精算システム、ホスト端末、精算方法、プログラム及び車両」とする発明について、本願の特許出願（特願２０２０－１８３０号）をした。本願は、平成２９年５月２６日（以下「原出願日」という。）を出願日とする特許出願（特願２０１７－１０４３６３号）の一部を分割して、新たな特許出願としたものである。

⑵ 被告は、令和３年２月１６日、本願の特許請求の範囲の全文を変更することを内容とする手続補正書（乙７）を提出し（以下、これによる補正を「本件補正」という。）、同年６月１日、本件特許に係る特許権の設定登録を受けた（請求項の数：１３）。

⑶ 原告は、令和５年８月４日、本件特許の請求項１、３、６～１１に係る特許につき、無効審判を請求し（本件審判請求）、特許庁は、これを無効２０２３－８０００５１号事件として審理した。

⑷ 被告は、令和５年１２月１日、本件特許の請求項３～６について訂正を請求した（以下、これを「本件訂正請求」という。乙１５）。

⑸ 特許庁は、令和７年９月１９日、「特許第６８９２６５６号の特許請求の範囲を令和５年１２月１日提出の訂正請求書に添付した訂正特許請求の範囲のとおり、訂正後の請求項〔３～６〕について訂正することを認める。」、

5 「特許第６８９２６５６号の請求項１、３、６、１１に係る発明についての本件審判請求は成り立たない。」、「特許第６８９２６５６号の請求項７～１０に係る発明についての特許を無効とする。」との本件審決をし、その謄本は、令和７年１０月１４日、原告及び被告にそれぞれ送達された。

⑹ 原告は、令和７年１１月１０日（第１事件）、被告は、同月１２日（第２事件）、当庁に対し、それぞれ本件審決の一部取消しを求める訴えを提起した。２ 本件各発明の内容等

⑴ 本件特許の特許請求の範囲の請求項１、３、６～１１の記載（本件訂正後のもの）は、次のとおりである（分説は本件審決による。）。（請求項１）１Ａ 管理表示部を有する管理端末であって、運送サービスを提供する前又は提供中のユーザの操作によって、管理表示部で取引を特定するための情報を表示する管理端末と、１Ｂ 前記取引を特定するための情報を読み取るユーザ端末からユーザ情報を取得し、また運賃情報を運賃測定手段から取得するホスト端末と、を備え、１Ｃ 管理表示部に表示された取引を特定するための情報がユーザ端末で読み取られ、当該ユーザ端末によって当該取引を特定するための情報及びユーザ情報がホスト端末に送信されることで、運送サービスを提供する前又は提供中に、ホスト端末はユーザ端末から取引を特定するための情報及びユーザ情報を取得し、１Ｄ ホスト端末は、前記運送サービスに対する運賃情報が確定した後で、取引を特定するための情報及び運賃情報を受信し、１Ｅ ホスト端末は、運賃情報が確定した後で取得した取引を特定するための情報とユーザ端末から取得した取引を特定するための情報とを用

5 いて、ユーザ情報と運賃情報とを関連付ける１Ｆ ことを特徴とする精算システム。（請求項３）３Ａ 管理端末は後部座席に乗車したユーザが操作可能な位置に設置され、３Ｂ 管理表示部は取引を特定するための情報をＱＲコードとして表示し、３Ｃ ホスト端末は、ＱＲコードを読み取ったユーザ端末から取引を特定するための情報を取得する３Ｆ ことを特徴とする請求項１又は２のいずれかに記載の精算システム。（請求項６）６Ａ ユーザ端末から行先が入力可能となる６Ｆ ことを特徴とする請求項１乃至５のいずれか１項に記載の精算システム。（請求項７）７Ａ 運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される取引を特定するための情報と、ユーザ情報を、運送サービスを提供する前又は提供中にユーザ端末から受信するホスト受信部を備え、７Ｂ ホスト受信部は、前記運送サービスに対する運賃情報が確定した後で、取引を特定するための情報及び運賃情報を受信し、７Ｃ 運賃情報が確定した後で取得した取引を特定するための情報とユーザ端末から取得した取引を特定するための情報とを用いて、ユーザ情報と運賃情報とを関連付けるホスト制御部を備える７Ｄ ことを特徴とするホスト端末。（請求項８）８Ａ ホスト端末は、ユーザ端末から取得した位置情報又はユーザ端末から入力されたピックアップ希望位置情報に基づき、管理端末に配車指

5 示を出力する８Ｄ ことを特徴とする請求項７に記載のホスト端末。（請求項９）９Ａ 決済に関する情報を記憶するホスト記憶部を備え、９Ｂ ユーザ端末からの要求に応じて、過去の利用履歴を出力する９Ｄ ことを特徴とする請求項７又は８に記載のホスト端末。（請求項１０）１０Ａ ユーザによって入力されたメールアドレスに対して、運賃に関する領収書を送信する１０Ｄ ことを特徴とする請求項７乃至９のいずれか１項に記載のホスト端末。（請求項１１）１１Ａ ユーザ端末から入力された行先に関する指定場所を記憶するホスト記憶部を備える１１Ｄ ことを特徴とする請求項７乃至１０のいずれか１項に記載のホスト端末。

⑵ 本件明細書本件明細書の記載は、別紙「特許公報」のとおりである。３ 本件審決の理由の要旨本件審決の理由のうち、審決取消事由に係る判断の要旨は、次のとおりである。

⑴ 甲１発明に基づく進歩性欠如についてア 甲１公報には、次の２つの発明（以下、順に「甲１発明ａ」、「甲１発明ｂ」という。）が記載されている。（甲１発明ａ）ブルートゥース通信を支援する使用者移動通信端末、ブルートゥース

5 ダイヤルアッププロファイルを通じて使用者移動通信端末を通信中継機として活用してタクシー利用情報をコールセンターに伝達するタクシー端末、タクシー利用情報を受信するコールセンターサーバを含むタクシー運行システムであって、使用者移動通信端末と加入タクシーに装置されたタクシー端末とコールセンターサーバが無線網を通じて相互連結され、これと別途に使用者移動通信端末とタクシー端末はブルートゥース通信で相互連結され、タクシー端末は、使用者がコールセンターに加入した加入タクシーに乗車しブルートゥース通信が許容された使用者移動通信端末が該当領域に進入するようになると、使用者移動通信端末をブルートゥース通信として認識し、ブルートゥース通信を通じてペアリングされた使用者移動通信端末を中継機として活用して、タクシー端末に既に格納されたタクシーの車両番号及びタクシー端末固有番号とともに使用者の乗車時点及び乗車位置を含むタクシー利用情報をコールセンターサーバに伝達し、タクシー利用情報が使用者移動通信端末で中継されてコールセンターサーバに伝達されると、タクシー利用情報に使用者移動通信端末の電話番号データが追加されて、タクシー利用情報ログとしてコールセンターサーバに格納され、タクシー端末は、メーター器に接続され、タクシー端末は、目的地に到着後、タクシー運転者が携帯電話小額決済要請ボタンを押すと、タクシー端末固有番号とメーター器から取得した料金情報を無線通信網を通じてコールセンターサーバに直接伝送し、コールセンターサーバは、タクシー端末から料金情報及びタクシー端末固有番号を受信し、すでに格納されているタクシー利用情報ログのうち、タクシー端末から受信されたタクシー端末固有番号とマッチされるタクシー端末固有番号を含むタクシー利用情報ログを選択し、その後、

5 コールセンターサーバは、抽出された上記使用者移動通信端末の電話番号を用いてタクシー料金の決済を要請するタクシー運行システム。（甲１発明ｂ）ブルートゥース通信を支援する使用者移動通信端末、ブルートゥースダイヤルアッププロファイルを通じて使用者移動通信端末を通信中継機として活用してタクシー利用情報をコールセンターに伝達するタクシー端末、タクシー利用情報を受信するコールセンターサーバを含むタクシー運行システムにおけるコールセンターサーバであって、使用者移動通信端末と加入タクシーに装置されたタクシー端末とコールセンターサーバが無線網を通じて相互連結され、これと別途に使用者移動通信端末とタクシー端末はブルートゥース通信で相互連結され、タクシー端末は、使用者がコールセンターに加入した加入タクシーに乗車しブルートゥース通信が許容された使用者移動通信端末が該当領域に進入するようになると、使用者移動通信端末をブルートゥース通信として認識し、ブルートゥース通信を通じてペアリングされた使用者移動通信端末を中継機として活用して、タクシー端末に既に格納されたタクシーの車両番号及びタクシー端末固有番号とともに使用者の乗車時点及び乗車位置を含むタクシー利用情報をコールセンターサーバに伝達し、タクシー利用情報が使用者移動通信端末で中継されてコールセンターサーバに伝達されると、タクシー利用情報に使用者移動通信端末の電話番号データが追加されて、タクシー利用情報ログとしてコールセンターサーバに格納され、タクシー端末は、メーター器に接続され、タクシー端末は、目的地に到着後、タクシー運転者が携帯電話小額決済要請ボタンを押すと、タクシー端末固有番号とメーター器から取得し

5 た料金番号を無線通信網を通じてコールセンターサーバに直接伝送し、コールセンターサーバは、タクシー端末から料金情報及びタクシー端末固有番号を受信し、すでに格納されているタクシー利用情報ログのうち、タクシー端末から受信されたタクシー端末固有番号とマッチされるタクシー端末固有番号を含むタクシー利用情報ログを選択し、該当電話番号を用いてタクシー料金の決済を要請する決済情報処理部を有するコールセンターサーバ。イ（ア）本件発明１と甲１発明ａとを対比すると、次の相違点がある。（相違点１－１－１）本件発明１の管理端末は、「管理表示部」を有し、取引を特定するための情報を出力するにあたって「運送サービスを提供する前又は提供中のユーザの操作によって、管理表示部で取引を特定するための情報を表示する」のに対し、甲１発明ａのタクシー端末（管理端末）は、「管理表示部」を有するものでなく、取引を特定するための情報を出力するにあたってブルートゥース通信を通じてペアリングされた使用者移動通信端末を中継機として活用してコールセンターサーバ（ホスト端末）に送信するのであって「運送サービスを提供する前又は提供中のユーザの操作によって、管理表示部で取引を特定するための情報を表示する」ものでない点。（相違点１－１－２）本件発明１の「ホスト端末」に送信される「取引を特定するための情報」は、「管理表示部に表示された」ものが「当該ユーザ端末」で「読み取られ」、かつ、「当該ユーザ端末によって」送信されたものであるのに対し、甲１発明ａのコールセンターサーバ（ホスト端末）に送信される「タクシー利用情報」（取引を特定するための情報）は、ブルートゥース通信を通じてペアリングされた使用者移動通信端末を

5 中継機として活用してタクシー端末（管理端末）が送信するものであってユーザ端末が送信するものではなく、さらに、管理表示部に表示されたものが当該ユーザ端末で読み取られたものではない点。（相違点１－１－３）本件発明１のホスト端末は、「ユーザ端末」によって「ホスト端末に送信され」た「ユーザ情報」を「運送サービスを提供する前又は提供中」に取得するのに対し、甲１発明ａのコールセンターサーバ（ホスト端末）は、使用者移動通信端末（ユーザ端末）によってコールセンターサーバ（ホスト端末）に送信された使用者移動通信端末の電話番号データ（ユーザ情報）を運送サービスを提供する前又は提供中に取得しているか否か明示されていない点。（イ）甲１発明ａは、周知慣用技術である「ブルートゥース通信を用いて情報を得る方法」（以下「周知慣用技術Ｂ」という。）の利用を前提とし、ブルートゥース通信を通じてペアリングされた使用者移動通信端末を「中継機」として活用して、ユーザであるタクシーの乗客による管理端末の操作を要することなく、取引を特定するための情報をコールセンターサーバ（ホスト端末）に送信するものであるのに対し、本件発明１は、運転サービスを提供する前又は提供中のユーザの操作によって、管理端末の管理表示部で取引を特定するための情報を表示し、管理端末は、ユーザの操作に応じて取引を特定するための情報を表示するのであって、ユーザは管理端末の管理表示部に表示された取引を特定するための情報を取得可能な場所にいたとしても、この表示のみをもって、ユーザ端末は取引を特定するための情報を取得するものではなく、取引を特定するための情報を読み取らない限り、取引を特定するための情報をホスト端末に送信するともいえない。このことを踏まえると、甲１発明ａを主引用発明として相違点１－１

5 －１、１－１－２の構成に至るためには、甲１発明ａが、周知慣用技術Ｂの利用を前提として初めて可能となる使用者通信端末（ユーザ端末）が有する「中継機」の機能を用いることによって利用者の操作の介在を不要としているものを、この機能を用いることができない周知技術（タブレット端末等にＱＲコード等の二次元情報をユーザ操作により表示してこれを読み取ることによって情報を得る方法。以下「周知技術Ａ」という。）を用いて敢えてタクシー運転手と使用者の双方の操作を介在させるものへと変更する必要がある。甲１発明ａにおいては、使用者通信端末（ユーザ端末）を「中継機」として用いることができない通信技術は利用できず、使用者通信端末（ユーザ端末）がタクシー端末（管理端末）から情報を得る方法を周知慣用技術Ｂから周知技術Ａに単に置換するのでは、相違点１－１－１、１－１－２の構成に至らない。また、本件発明１の管理端末が第１の管理端末と第２の管理端末からなるものを含むと解しても、甲１公報には、タクシー端末を運転手が操作可能な端末と使用者が操作可能な端末とに分ける技術的思想は記載されていないことから、甲１発明ａを主引用発明として情報を得る方法を周知慣用技術Ｂから周知技術Ａに置換したものが相違点１－１－１、１－１－２の構成を想到するものとはいえない。（ウ）甲１１記載技術は、発行された二次元コードである取引コードとこれを読み取ったユーザ端末から受信した取引コードとの照合を用いてタクシーの料金の決済を行うものであり、この取引コードは、タクシー料金が確定した段階での、タクシー運転手が使用する端末による取引コードの発行の依頼によって発行されるものであるのに対し、甲１発明ａにおける「タクシー利用情報」は、甲１１記載技術の取引コードに対応する情報ではないから、甲１発明ａと甲１１記載技術を組み合わせることは

5 できない。また、甲１１記載技術の「取引コード」が、甲１発明ａの「タクシー端末固有番号とメーター器から取得した料金情報」に対応する情報であるとして、甲１発明ａと甲１１記載技術を組み合わせることは可能であるものの、この組合せでは、携帯電話小額決済ボタンを押した後の料金情報の送信の際に併せて「ユーザ情報」となる使用者移動通信端末の電話番号がコールセンターサーバに送信されることになるのであり、相違点１－１－１、１－１－２の構成を想到しない。さらに、本件発明１の管理端末が第１の管理端末と第２の管理端末からなるものを含むと解しても、前記（イ）のとおり、甲１発明ａと甲１１記載技術とを組み合わせることによって、相違点１－１－１、１－１－２の構成を当業者が想到するとはいえない。（エ）本件明細書（【００６３】）には、ユーザに「分かりやすい作業」を行わせるという、ユーザインターフェースにおける工夫により、サービスの利用頻度を高めることが期待できるとの作用効果が明示されているところ、甲１発明ａは、ユーザに「分かりやすい作業」を行わせるという観点を持つものではなく、ユーザにおける作業がないことによる効果を念頭においたものであるから、ユーザに「分かりやすい作業」を行わせるように変更することは動機付けられず、むしろ阻害される。（オ）甲１発明ａのタクシー端末は、「携帯電話小額決済要請ボタン」を備え、これをタクシー運転者が押すと、確定した料金情報に相当するメーター器から取得した料金情報をコールセンターサーバに伝送することを踏まえると、タクシー端末は、ユーザが操作できないものであるとともに、タクシー運転手が操作可能な位置に配置される必要があるから、これをユーザが操作可能なものとするように変更したり、タクシー運転手が操作できない位置のものに変更したりすることは動機付けられず、む

5 しろ阻害される。（カ）甲１公報の記載を踏まえると、甲１発明ａは、タクシー端末が、ペアリングされた乗客の使用者移動通信端末を中継機として活用するに当たり、ダイヤルアップに際して、当該使用者移動通信端末の電話番号データがコールセンターに通知され、これがタクシー利用情報ログとして格納されることを前提としているといえるから、相違点１－１－３の構成とすることは、当業者が容易に想到し得たものである。また、甲１公報の記載を踏まえると、甲１発明ａにおいて、コールセンターサーバ（ホスト端末）が、使用者移動通信端末（ユーザ端末）によってコールセンターサーバ（ホスト端末）に送信された使用者移動通信端末の電話番号データ（ユーザ情報）を、運送サービスを提供する前又は提供中に取得するように構成することは、当業者が適宜なし得たことである。（キ）よって、本件発明１は、甲１発明ａ及び周知技術並びに甲１１記載技術に基づいて、当業者が容易に発明をすることができたものではない。ウ 本件発明３及び６は、いずれも本件発明１を引用するものであるから、上記イのとおり、甲１発明ａ及び周知技術並びに甲１１記載技術に基づいて、当業者が容易に発明をすることができたものではない。エ（ア）本件発明７と甲１発明ｂとを対比すると、次の相違点がある。（相違点１－７－１）本件発明７の「ホスト端末」（の「ホスト受信部」）が受信する「取引を特定するための情報」は、「運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される」ものであるのに対し、甲１発明ｂのコールセンターサーバ（ホスト端末）が受信する「タクシー利用情報」（取引を特定するための情報）は、「管理表示部」がないタクシー端末（管理端末）がブルートゥース通

5 信を通じてペアリングされた使用者移動通信端末を中継機として活用して送信するものであって、管理端末の管理表示部で表示されるものではない点。（相違点１－７－２）本件発明７のホスト端末は、「ユーザ情報」を「運送サービスを提供する前又は提供中にユーザ端末から」受信するのに対し、甲１発明ｂのホスト端末（コールセンターサーバ）は、ホスト端末に送信された使用者移動通信端末の電話番号データ（ユーザ情報）を運送サービスを提供する前又は提供中に使用者移動通信端末（ユーザ端末）から受信するか否か明示されていない点。（イ）二つ以上の装置を組み合わせてなる全体装置の発明に対し、組み合わされる各発明（サブコンビネーション発明）においては、ある装置の発明を記載した請求項中に記載された「他の装置」に関する事項が、当該「他の装置」のみを特定する事項であって、当該請求項に係る発明の構造、機能等を何ら特定してない場合は、「他の装置」に関する事項は、当該請求項に係る発明を特定するために意味を有しないことになるから、これを除外して当該請求項に係る発明の要旨を認定すべきである。そして、本件明細書（【００５０】）の記載を参酌すると、相違点１－７－１に係る「取引を特定するための情報」（構成要件７Ａ）が「運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される」ものであるか否かは、「取引を特定するための情報」の性質や特性を特定するものでも、ホスト端末が情報を受信するための方法（行為又は動作）を特定するものでもないから、本件発明７を特定するために意味を有しない。相違点１－７－１は、文言上の差異であって、実質的な相違点ではない。また、相違点１－７－２は、実質的に相違点１－１－３と同じである

5 から、甲１発明ｂに基づいて、当業者が適宜なし得たものである。（ウ）よって、本件発明７は、甲１発明ｂに基づいて、当業者が容易に発明をすることができたものである。オ（ア）本件発明８は、本件発明７を引用するものであり、甲１発明と対比すると、相違点１－７－１、１－７－２のほか、次の相違点がある。（相違点１－８）本件発明８は、「ホスト端末は、ユーザ端末から取得した位置情報又はユーザ端末から入力されたピックアップ希望位置情報に基づき、管理端末に配車指示を出力する」との構成を有しているのに対し、甲１発明ｂは、そのような構成を有していない点。（イ）相違点１－７－１、１－７－２については、上記エ（イ）のとおりである。相違点１－８については、甲１発明ｂに、周知技術（配車アプリにおいて、ユーザが配車希望位置の情報をスマートフォンに入力し、システム管理者側で当該場所に配車を行うこと）を適用することで、相違点１－８の構成とすることは、当業者が容易に想到し得たものであるし、相違点１－８の構成により奏する効果も、当業者が予測し得る範囲内のものである。（ウ）よって、本件発明８は、甲１発明ｂ及び周知技術に基づいて、当業者が容易に発明をすることができたものである。カ（ア）本件発明９は、本件発明７又は８を引用するものであり、甲１発明と対比すると、相違点１－７－１、１－７－２、１－８のほか、次の相違点がある。（相違点１－９）本件発明９は、「ユーザ端末からの要求に応じて、過去の利用履歴を出力する」との構成を有しているのに対し、甲１発明ｂは、そのよう

5 な構成を有していない点。（イ）相違点１－７－１、１－７－２については、前記エ（イ）のとおり、相違点１－８については、前記オ（イ）のとおりである。相違点１－９については、甲１発明ｂに、周知技術（配車アプリにおいて、ユーザ端末からの要求に応じて、過去の利用履歴を出力すること）を適用することは、設計事項又は単なる寄せ集めにすぎず、これにより、相違点１－９の構成とすることは、当業者が容易に想到し得たものである。（ウ）よって、本件発明９は、甲１発明ｂ及び周知技術に基づいて、当業者が容易に発明をすることができたものである。キ（ア）本件発明１０は、本件発明７～９のいずれか１項を引用するものであり、甲１発明と対比すると、相違点１－７－１、１－７－２、１－８、１－９のほか、次の相違点がある。（相違点１－１０）本件発明１０は、「ユーザによって入力されたメールアドレスに対して、運賃に関する領収書を送信する」との構成を有しているのに対し、甲１発明ｂは、そのような構成を有していない点。（イ）相違点１－７－１、１－７－２については、前記エ（イ）のとおり、相違点１－８については、前記オ（イ）のとおり、相違点１－９については、前記カ（イ）のとおりである。商品の購入又はサービスの提供に対する料金の支払に対して、顧客の要請により領収書を発行することは商慣行にすぎないこと、ユーザのメールアドレスに対して領収書を送付することは周知技術であることからすると、甲１発明ｂにおいて、相違点１－１０の構成とすることは、単なる周知技術の付加、寄せ集めにすぎず、当業者が容易に想到し得たものである。

5 （ウ）よって、本件発明１０は、甲１発明ｂ及び周知技術に基づいて、当業者が容易に発明をすることができたものである。ク（ア）本件発明１１は、本件発明７～１０のいずれか１項を引用するものであり、甲１発明ｂと対比すると、相違点１－７－１、１－７－２、１－８、１－９、１－１０のほか、次の相違点がある。（相違点１－１１）本件発明１１は、「ユーザ端末から入力された行先に関する指定場所を記憶するホスト記憶部を備える」との構成を有しているのに対し、甲１発明ｂは、そのような構成を有していない点。（イ）相違点１－７－１、１－７－２については、前記エ（イ）のとおり、相違点１－８については、前記オ（イ）のとおり、相違点１－９については、前記カ（イ）のとおり、相違点１－１０については、前記キ（イ）のとおりである。甲１発明ｂにおいて、ユーザ端末から行先を入力するようなことは全く想定されていない。本件発明１１の「指定場所」は、指定場所（行先）までの案内がナビゲーションシステム４０で行われることを可能にするとの効果を奏する点から見ても、単なる周知技術ということはできず、甲１発明ｂに周知技術を組み合わせる動機付けはない。そうすると、相違点１－１１の構成とすることは、当業者であっても容易に想到できない。（ウ）よって、本件発明１１は、甲１発明ｂ及び周知技術に基づいて、当業者が容易に発明をすることができたものではない。

⑵ 甲４１発明に基づく進歩性欠如についてア 甲４１公報には、次の２つの発明（以下、順に「甲４１発明ａ」、「甲４１発明ｂ」という。）が記載されている。（甲４１発明ａ）

5 タクシーチケット決済端末２を具備するタクシー車両１と、タクシーチケット決済端末２及び携帯端末３と携帯電話網４を経由して接続されるチケットセンタ５とからなるタクシーチケット決済システムであって、携帯端末３とチケットセンタ５は、携帯電話網４を介して電子メールのやり取りを行うことが可能であり、タクシーチケット決済端末２は、無線部２１と制御部２２と記憶部２３と操作部２４と表示部２５とタクシーメータインタフェース２６とプリンタインタフェース２７とを備え、無線部２１は、携帯電話網４に接続し、該携帯電話網４を介してチケットセンタ５との間でデータを送受信し、表示部２５には、制御部２２から表示データが入力され、タクシーメータインタフェース２６は、タクシーメータから出力される運賃データ等を受信し、記憶部２３は、タクシーチケット決済端末２が具備されているタクシー車両１の識別が可能な車両番号を保存し、チケットセンタ５は、通信部５１と供給部５２と利用許可部５３と決済管理部５４とデータベース５５とを備え、通信部５１は、携帯電話網４の中継局に有線で接続し、該携帯電話網４を介してタクシーチケット決済端末２との間でデータを送受信し、利用許可部５３は、携帯端末３からの電子メールによるタクシーチケットの利用許可要求により、当該タクシーチケットに専用の利用許可情報を生成し、この利用許可情報を電子メールで返信し、データベース５５は、管理情報ファイル１０１、決済金額ファイル１０２を記憶し、管理情報ファイル１０１には、登録されたタクシーチケットを特定する情報であるチケット番号が記録されるとともに、このチケット番号に

5 対応付けられた、当該タクシーチケットの使用状況、利用許可情報としての管理番号、及び有効期限、並びに利用されるタクシー車両１の車両番号が記録され、決済金額ファイル１０２には、チケット番号に対応付けられた、利用されたタクシー車両１の車両番号、決済金額、及び決済日時が記録され、チケットセンタ５によるタクシーチケットの供給動作として、タクシーチケットの供給依頼者が、携帯端末３により電子メールでチケット供給依頼をチケットセンタ５へ送信し、チケットセンタ５は、新規のタクシーチケットの登録を行うために、新たにチケット番号を発行して管理情報ファイル１０１へ記録し、供給依頼元の携帯端末３が受信し保存している電子メールには、供給されたタクシーチケットのチケット番号が記載され、この電子メールのことをチケット番号送信メールと称し、チケット番号送信メールは、供給依頼元の携帯端末３から他の端末に転送することができ、これにより、供給依頼者は、供給されたタクシーチケットを他者に譲渡することが可能であり、供給依頼者は、パーソナルコンピュータ等の固定端末を使用して、チケット供給依頼を行い、タクシーチケットの供給を受けることも可能であり、チケットセンタ５による供給済みのタクシーチケットの利用許可動作として、タクシーチケットの利用者は、タクシーを利用する際に、チケット番号送信メールが保存されている携帯端末３を持参し、利用者は、タクシーに乗車後、当該タクシー車両１の車両番号を乗務員に聞く等して取得し、その車両番号を携帯端末３に入力して、保存されているチケット番号送信メールに記載し、このチケット番号送信メールをチケットセンタ

5 ５へ返信することにより、当該タクシーチケットの利用許可要求を行い、チケットセンタ５は、チケット番号送信メールの返信メールを受信すると、利用許可要求がなされたと判断し、管理情報ファイル１０１を参照し、該返信メールに記載されているチケット番号が、管理情報ファイル１０１に登録されているか否かを判断し、判断の結果、登録されている場合には、該当する使用状況が未使用であるときに、当該タクシーチケットの有効期限を管理情報ファイル１０１に設定し、チケットセンタ５は、タクシーチケットの管理番号を乱数発生により生成し、生成した管理番号及び当該タクシーチケットの有効期限を電子メールで送信し、当該タクシーチケットの利用を許可し、該利用許可したタクシーチケットの管理番号及び利用許可要求時に通知された車両番号を管理情報ファイル１０１に記録するとともに、該当する使用状況を使用中に設定し、チケットセンタ５による利用許可済みのタクシーチケットの決済動作として、タクシーチケットの利用者は、タクシーの利用代金を支払う際に、利用許可メールに記載されている管理番号を乗務員に通知し、乗務員は、利用者から通知された管理番号をタクシーチケット決済端末２に入力し、タクシーチケット決済端末２は、タクシーメータから運賃情報を受信して管理番号と運賃を表示部２５に表示させ、乗務員は、該表示により利用者から運賃の承諾を取ると、操作部２４の送信キーを押下し、タクシーチケット決済端末２は、この送信キーの押下により、入力された管理番号、記憶部２３に保存されている車両番号、及び運賃からなる決済金額をチケットセンタ５へ送信し、決済依頼を行い、チケットセンタ５は、該決済依頼を受け取り、受信した管理番号が管

5 理情報ファイル１０１に登録されており、且つ該当する使用状況が使用中である場合に、当該タクシーチケットが有効であると判断し、受信した車両番号と、管理情報ファイル１０１に登録されている該当車両番号とを照合した結果、一致した場合に、当該タクシーチケットが正当なものであると判断して、当該タクシーチケットの決済を許可し、決済を許可したタクシーチケットのチケット番号、利用されたタクシー車両１の車両番号、決済金額、及び決済日時を決済金額ファイル１０２に登録し、チケットセンタ５は、管理情報ファイル１０１の該当する使用状況を使用済（無効情報）に設定し、当該タクシーチケットを無効化し、タクシーチケットを利用する者、例えば法人毎に、上記したチケット番号を体系的に付与すれば、タクシーチケットの利用者毎にその利用状況を管理することができるタクシーチケット決済システム。（甲４１発明ｂ）タクシーチケット決済端末２を具備するタクシー車両１と、タクシーチケット決済端末２及び携帯端末３と携帯電話網４を経由して接続されるチケットセンタ５とからなるタクシーチケット決済システムにおけるチケットセンタ５であって、携帯端末３とチケットセンタ５は、携帯電話網４を介して電子メールのやり取りを行うことが可能であり、タクシーチケット決済端末２は、無線部２１と制御部２２と記憶部２３と操作部２４と表示部２５とタクシーメータインタフェース２６とプリンタインタフェース２７とを備え、無線部２１は、携帯電話網４に接続し、該携帯電話網４を介してチケットセンタ５との間でデータを送受信し、表示部２５には、制御部２２から表示データが入力され、

5 タクシーメータインタフェース２６は、タクシーメータから出力される運賃データ等を受信し、記憶部２３は、タクシーチケット決済端末２が具備されているタクシー車両１の識別が可能な車両番号を保存し、チケットセンタ５は、通信部５１と供給部５２と利用許可部５３と決済管理部５４とデータベース５５とを備え、通信部５１は、携帯電話網４の中継局に有線で接続し、該携帯電話網４を介してタクシーチケット決済端末２との間でデータを送受信し、利用許可部５３は、携帯端末３からの電子メールによるタクシーチケットの利用許可要求により、当該タクシーチケットに専用の利用許可情報を生成し、この利用許可情報を電子メールで返信し、データベース５５は、管理情報ファイル１０１、決済金額ファイル１０２を記憶し、管理情報ファイル１０１には、登録されたタクシーチケットを特定する情報であるチケット番号が記録されるとともに、このチケット番号に対応付けられた、当該タクシーチケットの使用状況、利用許可情報としての管理番号、及び有効期限、並びに利用されるタクシー車両１の車両番号が記録され、決済金額ファイル１０２には、チケット番号に対応付けられた、利用されたタクシー車両１の車両番号、決済金額、及び決済日時が記録され、チケットセンタ５によるタクシーチケットの供給動作として、タクシーチケットの供給依頼者が、携帯端末３により電子メールでチケット供給依頼をチケットセンタ５へ送信し、チケットセンタ５は、新規のタクシーチケットの登録を行うために、新たにチケット番号を発行して管理情報ファイル１０１へ記録し、供給依頼元の携帯端末３が受信し保存している電子メールには、供給

5 されたタクシーチケットのチケット番号が記載され、この電子メールのことをチケット番号送信メールと称し、チケット番号送信メールは、供給依頼元の携帯端末３から他の端末に転送することができ、これにより、供給依頼者は、供給されたタクシーチケットを他者に譲渡することが可能であり、供給依頼者は、パーソナルコンピュータ等の固定端末を使用して、チケット供給依頼を行い、タクシーチケットの供給を受けることも可能であり、チケットセンタ５による供給済みのタクシーチケットの利用許可動作として、タクシーチケットの利用者は、タクシーを利用する際に、チケット番号送信メールが保存されている携帯端末３を持参し、利用者は、タクシーに乗車後、当該タクシー車両１の車両番号を乗務員に聞く等して取得し、その車両番号を携帯端末３に入力して、保存されているチケット番号送信メールに記載し、このチケット番号送信メールをチケットセンタ５へ返信することにより、当該タクシーチケットの利用許可要求を行い、チケットセンタ５は、チケット番号送信メールの返信メールを受信すると、利用許可要求がなされたと判断し、管理情報ファイル１０１を参照し、該返信メールに記載されているチケット番号が、管理情報ファイル１０１に登録されているか否かを判断し、判断の結果、登録されている場合には、該当する使用状況が未使用であるときに、当該タクシーチケットの有効期限を管理情報ファイル１０１に設定し、チケットセンタ５は、タクシーチケットの管理番号を乱数発生により生成し、生成した管理番号及び当該タクシーチケットの有効期限を電子メールで送信し、当該タクシーチケットの利用を許可し、該利用許可したタクシーチケットの管理番号及び利用許可要求時に通知された車両番

5 号を管理情報ファイル１０１に記録するとともに、該当する使用状況を使用中に設定し、チケットセンタ５による利用許可済みのタクシーチケットの決済動作として、タクシーチケットの利用者は、タクシーの利用代金を支払う際に、利用許可メールに記載されている管理番号を乗務員に通知し、乗務員は、利用者から通知された管理番号をタクシーチケット決済端末２に入力し、タクシーチケット決済端末２は、タクシーメータから運賃情報を受信して管理番号と運賃を表示部２５に表示させ、乗務員は、該表示により利用者から運賃の承諾を取ると、操作部２４の送信キーを押下し、タクシーチケット決済端末２は、この送信キーの押下により、入力された管理番号、記憶部２３に保存されている車両番号、及び運賃からなる決済金額をチケットセンタ５へ送信し、決済依頼を行い、チケットセンタ５は、該決済依頼を受け取り、受信した管理番号が管理情報ファイル１０１に登録されており、且つ該当する使用状況が使用中である場合に、当該タクシーチケットが有効であると判断し、受信した車両番号と、管理情報ファイル１０１に登録されている該当車両番号とを照合した結果、一致した場合に、当該タクシーチケットが正当なものであると判断して、当該タクシーチケットの決済を許可し、決済を許可したタクシーチケットのチケット番号、利用されたタクシー車両１の車両番号、決済金額、及び決済日時を決済金額ファイル１０２に登録し、チケットセンタ５は、管理情報ファイル１０１の該当する使用状況を使用済（無効情報）に設定し、当該タクシーチケットを無効化し、タクシーチケットを利用する者、例えば法人毎に、上記したチケット番号を体系的に付与すれば、タクシーチケットの利用者毎にその利用状

5 況を管理することができるチケットセンタ５。イ（ア）本件発明１と甲４１発明ａとを対比すると、次の相違点がある。（相違点２－１－１）管理端末の管理表示部での取引を特定するための情報の表示について、本件発明１では、「運送サービスを提供する前又は提供中のユーザの操作によって」表示するのに対し、甲４１発明ａでは、乗務員がタクシーチケットの利用者から通知された管理番号をタクシーチケット決済端末２（管理端末）に入力して表示するのであって、「運送サービスを提供する前又は提供中のユーザの操作によって」表示するのではない点。（相違点２－１－２）「ホスト端末」が「ユーザ情報」を取得する際の取得元である「ユーザ端末」について、本件発明１では、「管理表示部に表示された取引を特定するための情報を読み取る」ものであるのに対し、甲４１発明ａの「取引を特定するための情報」のうち「管理番号」は携帯端末３（ユーザ端末）によって読み取られるものでなく、「タクシー車両１の車両番号」は「乗務員に聞く等して取得」したものを「携帯端末３に入力」するのであり、いずれについても「管理表示部に表示された取引を特定するための情報を読み取る」ものではない点。（相違点２－１－３）ホスト端末においてユーザ端末から取得される「取引を特定するための情報」について、本件発明１では、「運送サービスを提供する前又は提供中に」「管理表示部に表示された」ものが「ユーザ端末で読み取られ」て「当該ユーザ端末によって」「送信され」て取得されるのに対し、甲４１発明ａでは、「管理番号」は携帯端末３（ユーザ端末）

5 によって読み取られるものでなく、「タクシー車両１の車両番号」は「乗務員に聞く等して取得」したものを「携帯端末３に入力」するのであり、いずれの取引を特定するための情報も、「運送サービスを提供する前又は提供中に」「管理表示部に表示された」ものが「ユーザ端末で読み取られ」て「当該ユーザ端末によって」「送信され」て取得されるものではない点。（相違点２－１－４）ホスト端末が行う運賃情報が確定した後で取得した取引を特定するための情報とユーザ端末から取得した取引を特定するための情報とを用いた処理は、本件発明１では、「ユーザ情報と運賃情報とを関連付ける」処理であるのに対し、甲４１発明ａでは、決済依頼として送信された管理番号（取引を特定するための情報）がチケットセンタ５（ホスト端末）が生成して管理情報ファイル１０１に記録した管理番号（取引を特定するための情報）と同じである場合に、決済を許可したタクシーチケットのチケット番号を決済日時及び決済金額とともに決済金額ファイル１０２に登録する処理であって、チケット番号が記載されたチケット番号送信メールが保存され、タクシーチケットの利用者が持参した携帯端末３のメールアドレスをユーザ情報として運賃情報と関連付ける処理ではない点。（イ）相違点２－１－１、２－１－２、２－１－３について、甲４１発明ａのタクシーチケット決済端末２（管理端末）は、利用者がこれを操作することができないことを前提としたものであること、また、甲４１発明ａの構成を、運送サービスを提供する前又は提供中にユーザ端末が読み取った車両番号をホスト端末に送信するように変更することを想定しても、決済に当たってユーザが乗務員に伝えた情報を乗務員がタクシーチケット決済端末２に入力し、運賃とともに表示し、ユーザの承諾を得る

5 といったユーザと乗務員との間のやり取りは、本件発明１の「読み取る」に相当しないことを踏まえると、甲４１発明ａにおける「取引を特定するための情報」である車両番号や管理番号について、運送サービスを提供する前又は提供中にタクシーチケット決済端末２にこれらのいずれかを表示したものをユーザ端末が読み取ってホスト端末に送信するように変更することはできないから、このような変更は動機付けられず、むしろ阻害される。相違点２－１－４について、甲４１公報は、チケット番号送信メールが他の端末に転送可能であることで他者に譲渡可能なタクシーチケットを実現するという前提を明示している。これを踏まえると、甲４１発明ａの決済金額ファイル１０２への登録処理の「ユーザ情報と運賃情報とを関連付ける処理」への変更は動機付けられず、むしろ阻害される。（ウ）よって、本件発明１は、甲４１発明ａ及び周知技術に基づいて、当業者が容易に発明できたものではない。ウ 本件発明３及び６は、いずれも本件発明１を引用するものであるから、本件発明３及び６と甲４１発明ａとの間には、少なくとも相違点２－１－１、２－１－２、２－１－３、２－１－４が存在し、これらの相違点は、当業者が容易に想到できたものではないから、甲４１発明ａ及び周知技術に基づいて、当業者が容易に発明できたものではない。エ（ア）本件発明７と甲４１発明ｂとを対比すると、次の相違点がある。（相違点２－７－１）管理端末の管理表示部での取引を特定するための情報の表示について、本件発明７では、「運送サービスを提供する前又は提供中のユーザの操作によって」表示するのに対し、甲４１発明ｂでは、乗務員が利用者から通知された管理番号をタクシーチケット決済端末２（管理端末）

5 に入力して表示するのであって、「運送サービスを提供する前又は提供中のユーザの操作によって」表示するのではない点。（相違点２－７－２）ホスト端末が行う運賃情報が確定した後で取得した取引を特定するための情報とユーザ端末から取得した取引を特定するための情報とを用いた処理は、本件発明７では、「ユーザ情報と運賃情報とを関連付ける」処理であるのに対し、甲４１発明ｂでは、決済依頼として送信された管理番号（取引を特定するための情報）がチケットセンタ５（ホスト端末）が生成して管理情報ファイル１０１に記録した管理番号（取引を特定するための情報）と同じである場合に、決済を許可したタクシーチケットのチケット番号を決済日時及び決済金額とともに決済金額ファイルに登録する処理であって、チケット番号が記載されたチケット番号送信メールが保存され、タクシーチケットの利用者が持参した携帯端末３のメールドレスをユーザ情報として運賃情報と連付ける処理ではない点。（イ）相違点２－７－１については、前記⑴エ（イ）のとおり、文言上の差異であって、実質的な相違点ではない。相違点２－７－２は、実質的に相違点２－１－４と同じであり、前記イ（イ）のとおり、甲４１公報が、チケット番号送信メールが他の端末に転送可能であることで他者に譲渡可能なタクシーチケットを実現するという前提を明示していることを踏まえると、甲４１発明ｂの決済金額ファイルへの登録処理の「ユーザ情報と運賃情報とを関連付ける処理」への変更は動機付けられず、むしろ阻害される。（ウ）よって、本件発明７は、甲４１発明ｂ及び周知技術に基づいて、当業者が容易に発明できたものではない。オ 本件発明８～１１については、いずれも本件発明７を引用するものであ

5 るから、本件発明８～１１と甲４１発明ｂとの間には、少なくとも相違点２－７－２が存在し、これは当業者が容易に想到できたものではない。または、本件発明１１と甲４１発明ｂとを対比すると、本件発明１１は、「ユーザ端末から入力された行先に関する指定場所を記憶するホスト記憶部を備える」との構成を有しているのに対し、甲４１発明ｂは、そのような構成を有していない点でも相違するが、前記⑴ク（イ）のとおり、これも当業者が容易に想到できたものではない。よって、本件発明８～１１は、甲４１発明ｂ及び周知技術に基づいて、当業者が容易に発明できたものではない。

⑶ 新規事項の追加について本件各発明において、「取引を特定するための情報」は、管理表示部で表示され、ユーザ端末で読み取られ、ユーザ端末によってホスト端末に送信されること、また、ホスト端末は、運送サービスに対する運賃情報が確定した後で、取引を特定するための情報を受信し、「運賃情報が確定した後で取得した取引を特定するための情報」と「ユーザ端末から取得した取引を特定するための情報」とを用いて、「ユーザ情報と運賃情報とを関連付ける」ことが特定されている。そして、当初明細書等には、「取引を特定するための情報」に関連する「取引情報」は「営業番号等の個別取引番号、車両無線番号、乗車日時、乗車場所、会社ＩＤ等の会社識別情報等」 を含んでもよいことが記載され（【００３８】）、また、ホスト端末１００が、ユーザ端末２００及び管理端末１０から受信した「取引情報」の「一部又は全部」を「キー情報」として、「ユーザ情報」と「運賃情報」とを紐付けることが記載されているのであり（【００４８】【００４９】【００７４】【００７５】）、本件各発明の「取引を特定するための情報」が、当初明細書等の「取引情報」に含有される情報（営業番号等の個別取引番号、車両無線番号、乗車日時、乗車場所、

5 会社ＩＤ等の会社識別情報等）に対応することは明らかである。そうすると、本件補正は、新たな技術事項を導入するものに該当せず、新規事項を追加するものではない。

⑷ サポート要件について本件各発明の「取引を特定するための情報」は、上記⑶のとおり、「取引情報」のうち「ユーザ情報と運賃情報とを関連付ける」ことができる情報であって、これにより、本件明細書に記載された課題（【０００２】【０００３】【０００５】）を解決できることは明らかである。本件各発明の「取引を特定するための情報」は、本件明細書に記載されたものであって、上記課題を解決することができることから、サポート要件を充足する。

⑸ 明確性要件について本件各発明において、「取引を特定するための情報」は、管理表示部で表示され、ユーザ端末で読み取られ、ユーザ端末によってホスト端末に送信されること、また、ホスト端末は、運送サービスに対する運賃情報が確定した後で、取引を特定するための情報を受信し、「運賃情報が確定した後で取得した取引を特定するための情報」と「ユーザ端末から取得した取引を特定するための情報」とを用いて、「ユーザ情報と運賃情報とを関連付ける」ことが特定されているから、その技術的な意味は明確であり、また、「取引を特定するための情報」が、本件明細書の「取引情報」に含有される情報（営業番号等の個別取引番号、車両無線番号、乗車日時、乗車場所、会社ＩＤ等の会社識別情報等）に対応することは明らかであるから、本件各発明は明確である。４ 審決取消事由

⑴ 原告主張の審決取消事由ア 取消事由１（甲１発明に基づく進歩性欠如の判断の誤り）

5 （ア）取消事由１－１甲１発明に基づく本件発明１、３及び６の進歩性欠如の判断の誤り（イ）取消事由１－２甲１発明に基づく本件発明１１の進歩性欠如の判断の誤りイ 取消事由２（甲４１発明に基づく進歩性欠如の判断の誤り）（ア）取消事由２－１甲４１発明に基づく本件発明１、３及び６の進歩性欠如の判断の誤り（イ）取消事由２－２甲４１発明に基づく本件発明７～１１の進歩性欠如の判断の誤りウ 取消事由３新規事項追加についての判断の誤りエ 取消事由４サポート要件についての判断の誤りオ 取消事由５明確性要件についての判断の誤り

⑵ 被告主張の審決取消事由取消事由６（甲１発明に基づく進歩性欠如の判断の誤り）ア 取消事由６－１甲１発明に基づく本件発明７の進歩性欠如の判断の誤りイ 取消事由６－２甲１発明に基づく本件発明８の進歩性欠如の判断の誤りウ 取消事由６－３甲１発明に基づく本件発明９の進歩性欠如の判断の誤りエ 取消事由６－４甲１発明に基づく本件発明１０の進歩性欠如の判断の誤り

第３ 当事者の主張

5 １ 取消事由１－１（甲１発明に基づく本件発明１、３及び６の進歩性欠如の判

断の誤り）について

（原告の主張）

⑴ 本件発明１と甲１発明の対比

本件発明１は、① 料金確定前（「運送サービスを提供する前又は提供中」）に「取引を特定するための情報」及び「ユーザ情報」が「ユーザ端末」を通して「送信」され「ホスト端末」（サーバ）によって取得され、厳密には、ユーザ端末が管理端末の管理表示部から「取引を特定するための情報」を読み取り（第１ルート・ステップ１）、そのように読み取ったユーザ端末から「取引を特定するための情報」と「ユーザ情報」（ユーザ端末自体が保有する電話番号等の情報）が「ホスト端末」によって取得される（第１ルート・ステップ２）、その上で、② 「運送サービス」の「運賃情報が確定した後」、当該確定した「運賃情報」と「取引を特定するための情報」を「ホスト端末」（サーバ）が「受信」する （第２ルート）、これにより、③「ホスト端末」が、上記第１ルートと第２ルート経由でそれぞれ取得した「取引を特定するための情報」を用いることにより、「ユーザ情報と運賃情報とを関連付け」、誰に対していくらの運賃を請求すればよいか確定できる（関連付けステップ）構成である。これに対し、甲１発明は、①’運送サービス提供中に、タクシー端末２００からブルートゥース通信によって使用者移動通信端末（１００）にタクシー利用情報（タクシー端末固有番号を含む。）が送られる（第１ルート・ステップ１）、②’ 使用者移動通信端末（１００）でこれに電話番号が追加されてコールセンターサーバ３００に送信される（第１ルート・ステップ２）、③’料金情報確定後に、タクシー端末２００から、コールセンターサーバ３００に、タクシー端末固有番号及び料金情報が送信される（第２ルート）、④’サーバでの関連付けに相当する構成として、上記①’、②’及び

5 ③’の後、サーバが、タクシー端末固有番号を用いて、料金情報に関する使

用者移動通信端末の電話番号を抽出する（関連付けステップ）構成であるから、本件発明１と甲１発明とを対比すると、その相違点は、本件発明１では、「運送サービスを提供する前又は提供中のユーザの（管理端末に対する）操作によって、管理表示部で取引を特定するための情報を表示」し、これを「ユーザ端末」が「読み取る」のに対し、甲１発明では、ユーザがユーザ端末でタクシー安心サービスのコンテンツが使用可能なようにすることでペアリング設定操作をすることによって、ブルートゥース通信によりタクシー端末２００から「タクシーの車両番号及びタクシー端末固有番号とともに使用者の乗車地点及び乗車位置を含むタクシー利用情報」を取得している点のみである。したがって、本件審決の本件発明１と甲１発明との相違点に係る認定判断には誤りがある。

⑵ 相違点に係る容易想到性

ア（ア）近距離無線通信を行うための方法を、「ブルートゥース通信を用いて情報を得る方法」（周知慣用技術Ｂ。以下「ブルートゥース通信方式」ということがある。）から「タブレット端末等にＱＲコード等の二次元情報をユーザ操作により表示させて、これを読み取ることによって情報を得る方法」（周知技術Ａ。以下「ＱＲコード方式」ということがある。）へ変更すること（又は両方式を併用すること）は、原出願日当時の技術常識であるし、前部座席（運転手席）に設置されるタクシー端末とは別途に、又は、これに加えて、後部座席に、広告等を表示するためのタブレット端末等を設置することは、原出願日当時の技術常識であったことからすると、甲１発明における情報取得方式として、ＱＲコード方式を採用することは、当業者にとって、単なる設計変更事項にすぎず、動機付けの有無を問題にするまでもない。

5 仮に、甲１発明において、ブルートゥース通信方式をＱＲコード方式

に置換することに阻害要因があったとしても、機器間の近距離通信を行う場合、特に決済に関わるときは、安全性、支払の確実性の観点から、通信手段を複数確保することは、原出願日当時の技術常識であるから、ブルートゥース通信方式とＱＲコード方式の双方を併用することに対する阻害要因とはならない。（イ）本件審決は、甲１発明ａは使用者移動通信端末（ユーザ端末）を「中継機」として活用して情報を送信していない、また、甲１発明ａが使用者移動通信端末（ユーザ端末）の有する「中継機」の機能を用いることによって、利用者の操作の介在を不要としているものを、この機能を用いることができない周知技術Ａを用いて敢えてタクシー運転手とユーザの双方の操作を介在させるものへと変更する必要があるとするが、相違点に係る認定判断の誤りを措くとしても、① ブルートゥース通信方式では、ペアリング（接続）が行われない場合があるという周知の技術的課題があり、このような課題を認識した当業者は、通信の確実性を確保するために、ブルートゥース通信方式に置換、又は併用して、周知技術Ａの適用を考えるのが自然であること、② 甲１発明において、「取引を特定するための情報」に相当する車両情報を出力するに当たっては、事前に、ユーザによる「タクシー安心サービス」の設定という手動操作が必要であり、完全に自動でタクシー料金の携帯電話小額決済サービスが実現されるわけでないこと、③ ブルートゥース通信を行う際には、ユーザが意図せずに第三者の端末と無断で接続されることを防止するため、接続される端末のうち少なくとも一方のユーザの承認を経てペアリングが行われるのが一般的であり、原出願日において、ユーザの操作を全く介在させることなく、当然にタクシー端末と乗客端末との間でペアリング及び通信が行われていたと当業者が理解するわけではないことを

5 踏まえると、甲１発明に周知技術Ａを適用する強い動機付けがある一方、

阻害要因は存在しない。イ（ア）本件審決は、甲１発明ａにおける「タクシー利用情報」は、甲１１記載技術の「取引コード」に対応する情報ではないから、甲１発明ａと甲１１記載技術を組み合わせることはできないとする。しかしながら、情報の「送信方法」を置換できるか否か検討するに当たり、当該「情報」が同一であることまで求める理由はないし、甲１１公報（【００３９】【００８３】【００８４】）の記載によれば、甲１１記載技術における「取引コード」は、販売者決済情報のみならず販売者識別情報をも含むものであるから、甲１発明ａにおける「タクシー利用情報」、すなわち「取引を特定するための情報」は、甲１１記載技術の「取引コード」に対応する情報でないとする本件審決は、その前提において誤りがある。本件審決は、甲１１記載技術の「取引コード」が、甲１発明ａの「タクシー端末固有番号とメーター器から取得した料金情報」に対応する情報であるとして、甲１発明ａと甲１１記載技術を組み合わせることは可能であるものの、この組合せでは、携帯電話小額決済ボタンを押した後の料金情報の送信の際に併せて「ユーザ情報」となる使用者移動通信端末の電話番号がコールセンターサーバに送信されることになって、相違点１－１－１、１－１－２の構成を想到しないともするが、甲１１発明は、「取引を特定するための情報」をユーザ端末が取得するための手段としてタブレット端末等にＱＲコード等の情報を表示し、これをユーザ端末で読み取る構成であるから、第１ルート・ステップ１の情報取得方式として、甲１発明の方式に代えて甲１１記載技術を採用することにつき、阻害要因は存在せず、当業者は容易に想到し得た。

5 （イ）本件審決は、甲１発明ａにおいて、ユーザに「分かりやすい作業」を

行わせるように変更することは動機付けられず、むしろ阻害されるとするが、甲１発明においても「タクシー安心サービスの設定」という簡易なユーザ操作が必要であり、「分かりやすい作業」を行う点で本件発明１と変わりはないし、甲１公報（【００２１】）の記載によれば、「タクシー小額決済サービス」に関し、運転手及び乗客の「単純操作」が介在することは当然の前提とされているのであるから、阻害要因は存在しない。（ウ）本件審決は、甲１発明ａのタクシー端末をユーザが操作可能なものとするように変更したり、タクシー運転手が操作できない位置のものに変更したりすることは動機付けられず、むしろ阻害されるとする。しかしながら、少なくとも、ブルートゥース通信方式とＱＲコード方式の双方を併用する場合には、タクシー端末の設置位置等は阻害要因となり得ず、むしろ、ＱＲコード方式を併用する強い動機が存在するというべきであるし、既に常識的存在となっていたタクシーの後部座席のタブレット端末等を活用して、タクシー利用情報をユーザ端末に送信することや、同じく周知であったＱＲコード方式を用いることは、当業者が当然に考え付いたことにすぎず、阻害要因は存在しない。ウ 以上によれば、本件発明１は、甲１発明並びに周知技術及び甲１１記載技術に基づいて、当業者が容易に発明できたものであるから、本件審決の判断には誤りがあり、本件発明１を引用する本件発明３及び６について、本件発明１と同じ理由により、当業者が容易に発明できたものではないとする本件審決の判断にも誤りがある。

（被告の主張）

⑴ 本件発明１と甲１発明の対比

本件審決の本件発明１と甲１発明の相違点に係る認定判断に誤りはない。

5 ⑵ 相違点１－１－１、１－１－２、１－１－３に係る容易想到性

ア（ア）甲１発明は、ブルートゥース通信によってタクシー端末と乗客の使用者移動通信端末とが自動接続される構成であり、甲１公報（【０００７】）において、「タクシー端末または乗客の移動通信端末を特に操作しなくても自動でタクシーの車両情報及び乗客の乗車情報が移動通信無線網を通じて確保されて乗客の安全を図ることができる」ことが、発明が解決しようとする課題として開示されている。また、甲１発明では、タクシー端末とブルートゥース通信で接続されている使用者移動通信端末を、タクシー端末の中継機として利用することが想定されていて、タクシー端末と使用者移動通信端末がペアリングにより通信接続され続けることが前提となっている。甲１発明のブルートゥース通信方式に代えてＱＲコード方式を用いた場合、タクシー端末と使用者移動通信端末とが自動接続されず、ＱＲコードを読み取るための操作が必要となることや、使用者移動通信端末を、タクシー端末の中継機として利用することができないことを踏まえると、甲１発明のブルートゥース通信方式に代えてＱＲコード方式を用いる動機付けはなく、かかる態様を当業者が想定するはずはない。また、上記の事情を踏まえると、甲１発明のブルートゥース通信方式に代えてＱＲコード方式を用いることは、甲１発明の目的に反するものであるから、阻害要因があるというべきである。（イ）甲１発明は、タクシー端末と使用者移動通信端末を備えるのみで、本件発明１の管理端末に対応する端末を備えるものではない。仮に甲１発明のタクシー端末を本件発明１の管理端末として利用するとしても、甲１発明のタクシー端末がＱＲコードを表示できるような表示部を備えているか不明である。また、タクシー端末は、前部座席に設置されタクシーの運転手が操作するものであるから、この場合、① 前部座席に設置

5 された管理端末（タブレット端末等）に、取引を特定するための情報と

してＱＲコードを表示させ、② ユーザが前部座席に設置されたタブレット端末等を操作して当該端末に表示されているＱＲコードをユーザ端末で読み取る必要があるところ、後部座席のユーザが前部座席の管理端末を操作し、これに表示されているＱＲコードを読み取るのは困難である。そもそも、上記のステップを経て、相違点に係る本件発明１の構成に想到することは、いわゆる「容易の容易」に該当し、格別の努力を要するものであるから、当業者にとって容易であったとはいえない。イ（ア）原告は、甲１発明において、ブルートゥース通信方式をＱＲコード方式に置換することに阻害要因があったとしても、ブルートゥース通信方式とＱＲコード方式の双方を併用することに対する阻害要因とはならない旨の主張をするが、甲１公報に、ＱＲコード方式を用いることについての記載は存在しないこと、仮に甲１１記載技術を併用するとしても、甲１１公報は、料金確定後にＱＲコード決済を行う態様を開示するのであり、甲１発明と甲１１記載技術を組み合わせたとしても、料金確定後にＱＲコード決済を行う態様を並列で用いることになるにすぎないことからすると、

（原告の主張）

は失当である。（イ）原告は、ブルートゥース通信方式にはペアリングが行われない場合があるという技術的課題がある旨の主張をするが、かかる技術的課題があったとしても、料金確定後にＱＲコード決済を行う態様を並列で用いるにすぎないことから、相違点１－１－１、１－１－２に係る本件発明１の構成に想到することはない。また、原告は、ブルートゥース通信方式においてペアリングが行われ、ユーザによる操作が不要である点について縷々主張するが、ペアリングは飽くまで前準備として実施されるものであるし、そもそも、原告の主張は、ユーザの「ユーザ端末」に対する操作に係るもので、ユー

5 ザの「管理端末」に対する操作に係るものではなく失当である。

さらに、原告は、本件訴訟において新たに提出した証拠（甲１２２～１２６）に基づき、後部座席にタブレット端末等を設置することは、原出願日当時の技術常識であった旨の主張をするが、これは、本件審判請求の手続において争点となっていた無効原因を立証するための周知技術を裏付ける範囲を超えるもので許されない。仮にそうでないとしても、甲１公報に、後部座席にタブレット端末等を配置することについての記載や示唆はなく、甲１発明のタクシー端末により実現されている機能のうち「タクシー利用情報伝送部」のみを分離すること自体、阻害要因が存在するというべきである。

２ 取消事由１－２（甲１発明に基づく本件発明１１の進歩性欠如の判断の誤り）

について

（原告の主張）

⑴ 本件審決が、特許請求の範囲に記載されていないのに、「本件発明１１の

『指定場所』は指定場所までの案内がナビゲーションシステム４０で行われることを可能にする」ことを考慮して発明の要旨を認定し、これを前提として、「甲１発明ｂにおいて、ユーザ端末から行先を入力するようなことは全く想定されていない」とするのは誤りである。また、配車アプリのサーバでユーザの希望する行先を登録することは、原出願日当時、当業者にとって当然の技術常識、周知技術にすぎない。

⑵ したがって、相違点１－１１の構成とすることは、当業者であっても容易

に想到できないとする本件審決の判断には誤りがある。

（被告の主張）

本件発明１１のように「ユーザ端末から入力された行先に関する指定場所を記憶」させるのであれば、その時点で、配車されるタクシーが決定され、コールセンターにおいて、使用者移動通信端末の情報を取得できることから、甲１

5 発明の請求項１に記載された「ブルートゥース通信を通じて上記使用者移動通

信端末を識別し、ブルートゥースダイヤルアッププロファイルを通じて上記使用者移動通信端末を通信中継機として活用してタクシーの車両情報及び乗車情報を含むタクシー利用情報を上記コールセンターに伝達する」構成を採用する必要がないこととなるのであって、甲１発明において、相違点１－１１に係る本件発明１１の構成を採用する動機付けはない。また、甲１発明では、行先が決定されたユーザのユーザ端末とコールセンターが事前に通信することが前提とされていないから、甲１発明に周知技術等を組み合わせて、相違点１－１１に係る本件発明１１の構成に到達することには動機付けがなく、むしろ阻害される。

３ 取消事由２－１（甲４１発明に基づく本件発明１、３、６の進歩性欠如の判

断の誤り）について

（原告の主張）

⑴ 本件発明１と甲４１発明の対比

本件発明１は、前記１⑴のとおりの構成であり、これに対し、甲４１発明は、①’’乗客がタクシーに乗車後、運賃が確定する前（運送サービス提供中）にタクシー車両１の乗務員から聞く等の方法によって利用者が車両番号を取得する（第１ルート・ステップ１）、②’’利用者がこれを携帯端末３に入力してチケット番号送信メールとして利用許可要求（チケット番号、車両番号）がチケットセンタ５へ送信されている（第１ルート・ステップ２）、

③’’運賃確定後に、タクシーチケット決済端末から、チケットセンタ５に、

決済依頼（管理番号、車両番号、決済金額を含む）が送信される（第２ルート）、④’’サーバでの関連付けに相当する構成として、①’’、②’’及び③’’の後、チケットセンタ５の決済管理部５４は、管理番号及び車両番号を用いて、当該タクシーチケットの決済を許可する（関連付けステップ）構成であるから、本件発明１と甲４１発明とを対比すると、その相違点は、

5 本件発明１では、「（ユーザの操作により）管理表示部で取引を特定するた

めの情報を表示する管理端末」から「ユーザ端末」が「取引を特定するための情報を読み取る」のに対し、甲４１発明では、タクシー料金確定前に、タクシー側から「取引を特定するための情報」に相当する情報（車両番号）を「ユーザ端末」をもつユーザが乗務員から「聞く等」の方法によって取得する構成を備えるという、情報取得の手段の点のみである。したがって、本件審決の本件発明１と甲４１発明との相違点に係る認定判断には誤りがある。

⑵ 相違点に係る容易想到性

ア 本件審決は、相違点２－１－１、２－１－２、２－１－３に係る本件発明１の構成に変更することは動機付けられず、むしろ阻害されるとするが、相違点に係る認定判断の誤りを措くとしても、これは、甲４１発明の構成に、周知技術にすぎないＱＲコード方式を加え、又は併用できることを看過するものである。タクシーの後部座席に広告表示、決済等の目的で、タブレット端末等を設置することは、原出願日当時の技術常識にすぎず、甲４１発明において、タクシー内に設置されたタブレット端末等にＱＲコードを表示させ、ユーザが情報を読み取る構成（ＱＲコード方式）にすることは、当業者であれば当然に試みたことである。入力ミスの防止や時間の短縮という当然の技術的要請に基づき、手動による入力作業（手動方式）を、携帯端末を利用したＱＲコード方式に代えること、あるいは、手動方式に加え、ＱＲコード方式を併用することは、原出願日前に当然に行われていたことであり、甲４１公報（【００４４】）が、「利用者は、タクシーに乗車後、当該タクシー車両１の車両番号を乗務員に聞く等して取得する。」として、「乗務員に聞く」以外の手段によって、利用者が車両番号を取得することを開示していることや、公知文献である甲１１公報（【００７２】）に、「購入者の使

5 用する携帯端末は、第１実施形態と同様に二次元コードを読み取る機能

を有するものや、送受信部３１ｂと情報の送受信を行うことにより取引コードを取得する機能を有するもの等である。あるいは、手入力により取得コードを取得するものでも良い。」と記載されていることを踏まえると、甲４１発明の情報取得に係る構成をＱＲコード方式に置換することについて、当業者には強い動機付けが存在したというべきである。イ 本件審決は、本件発明１の「ユーザ情報」は、実際の乗客を一意に特定できる情報（甲４１発明ａにおける「携帯端末３のメールアドレス」）であり、甲４１発明ａの「タクシーチケット番号」のような「決済手段情報」はこれに相当しないことを前提に、本件発明１と甲４１発明ａとの間には相違点２－１－４が存在するとするものと解されるが、その前提において誤りである。仮にそうであるとしても、甲４１公報（【００４７】【００４８】）は、チケットセンタ５がメールアドレス先に返信できる構成を開示しているところ、タクシー料金の決済に関するログを残すため、甲４１公報の【図５】、【図６】で示されるテーブルに、チケットセンタ５に保存された携帯端末３のメールアドレスを含めることは、当業者が適宜選択し得る設計事項にすぎない。したがって、車両番号及び管理番号により、ユーザ情報であるメールアドレスと運賃情報（決済金額）を関連付けることは、甲４１公報に基づき、当業者が容易に想到できたことである。ウ 以上によれば、本件発明１は、甲４１発明及び周知技術に基づいて、当業者が容易に発明できたものであるから、本件審決の判断には誤りがあり、本件発明１を引用する本件発明３及び６について、本件発明１と同じ理由により、当業者が容易に発明をすることができたものではないとする本件審決の判断にも誤りがある。5

（被告の主張）

⑴ 本件発明１と甲４１発明の対比

本件審決の本件発明１と甲４１発明の相違点に係る認定判断に誤りはない。

⑵ 相違点２－１－１、２－１－２、２－１－３、２－１－４に係る容易想到

性ア 本件発明１に到達するためには、単にＱＲコードを用いるのみでは足りず、ユーザの操作により管理表示部でＱＲコードを表示させる必要がある。そもそも、甲４１発明に先行技術を組み合わせた態様に、更に変更を加えて本件発明１の進歩性を否定することは、「容易の容易」によって進歩性を否定するもので許されない。また、これを措くとしても、①甲４１発明の表示部は、タクシーチケットに関連する管理番号と運賃を表示させるための端末であり、ユーザの操作によって車両番号を表示させることは想定されていないこと、② 仮に車両番号を表示させるとしても、甲４１発明の携帯端末がＱＲコードを読み取る機能を有するかどうか不明であること、③ 甲４１公報（【００４９】）は「乗務員は、利用者から通知された管理番号をタクシーチケット決済端末２に入力する」構成を開示するのであり、タクシーチケット決済端末の表示部を用いてＱＲコードを表示させるとしても、利用者がタクシーチケット決済端末を操作することにならないこと、④ タクシーチケット決済端末は前部座席に設置されているのであり、後部座席にいる利用者がＱＲコードを読み取るのは困難であること、⑤ タクシーチケットの僅かな利用者のために、高価な端末を導入しＱＲコードを表示させるのは、コスト的に見合わないことを踏まえると、相違点２－１－１、２－１－２、２－１－３、２－１－４に係る本件発明１の構成に想到する動機付けはないし、むしろ阻害される。イ 原告は、ＱＲコード方式を併用することは、原出願日当時の技術常識で

5 ある旨の主張をするが、タクシーチケットを用いた場合は、料金確定後の

ＱＲコード方式による決済と異なり、タクシーチケットの発行を依頼した者が支払を行い、タクシーの利用者は支払を行わないことからすると、当業者は、甲４１発明と、ＱＲコード方式による決済を全く別の場面での利用態様と捉えることになるのであり、ＱＲコード方式を併用するとしても、相違点に係る本件発明１の構成に想到する動機付けはない。また、原告は、本件訴訟において新たに提出した証拠（甲１２２～１２６）に基づき、タクシーの後部座席に、広告表示、決済等の目的で、タブレット端末等を設置することは、原出願日当時の技術常識にすぎない旨の主張をするが、これは、本件審判請求の手続において争点となっていた無効原因を立証するための周知技術を裏付ける範囲を超えるもので許されないし、仮にそうでないとしても、甲４１公報に、ＱＲコード方式を採用することについての記載や示唆はなく、いずれにせよ、当業者において相違点に係る構成に想到できない。

４ 取消事由２－２（甲４１発明に基づく本件発明７～１１の進歩性欠如の判断

について

（原告の主張）

前記３

（原告の主張）

⑵イのとおり。

（被告の主張）

⑴ 本件発明７

本件発明７と甲４１発明ｂとを対比すると、相違点２－７－１（本件審決は、相違点２－７－１を実質的な相違点でないとするが、かかる判断が誤りであることは、後述するとおりである。）のほか、次の相違点が存在する。（相違点２－７－３）ホスト端末においてユーザ端末から取得される「取引を特定するための情報」について、本件発明７では、「管理表示部で表示され」たものが「ユー

5 ザ端末」から受信されるのに対し、甲４１発明ｂの「取引を特定するための

情報」のうち「管理番号」は、利用者から乗務員に通知され、タクシーチケット決済端末２からチケットセンタ５に送信されるものであり、「管理表示部で表示され」た「管理番号」が携帯端末３（ユーザ端末）を介して受信されるものでなく、「タクシー車両１の車両番号」は「乗務員に聞く等して取得」したものを「携帯端末３に入力」するものであり、「管理表示部に表示された取引を特定するための情報」ではない点。

⑵ 本件発明１１

甲４１発明は、タクシーチケット決済システムに関する発明であり、タクシーチケットの発行依頼者とタクシーの利用者が異なることから、タクシーを利用した者が次回以降も甲４１発明のタクシーチケット決済システムを利用する可能性が高いとはいえない。そうすると、本件発明１１の「ユーザ端末から入力された行先に関する指定場所を記憶する」構成を採用する動機付けは、より一層低いというべきである。

５ 取消事由３（新規事項追加についての判断の誤り）について

（原告の主張）

当初明細書等は「取引を特定するための情報」の意義等を開示するものではないから、本件補正は新規事項を追加するものというべきである。当初明細書等（【００３８】）には、「取引情報」は、取引を特定できる、運賃情報及びユーザ情報以外のあらゆる情報（車両情報、営業情報、営業番号等の個別取引番号、車両無線番号、乗車日時、乗車場所、会社ＩＤ等の会社識別情報等）を含んでいるとの記載があるものの、「取引を特定するための情報」の意義は、「当該情報自体によって取引が特定される情報」と解釈するのが自然であり、上記情報のみでは具体的に取引がされないから、上記の記載は「取引を特定するための情報」の意義を開示するものではない。また、仮に「取引を特定するための情報」に「ユーザ情報」が含まれるので

5 あれば、当初明細書等（【００３８】）の、取引情報は「運賃情報及びユーザ

情報以外」のあらゆる情報を含んでいるとの記載を踏まえると、「ユーザ情報」が含まれる「取引を特定するための情報」をクレームアップすることは、当業者が明細書又は図面の記載によって導くことのできない技術的事項を追加するものにほかならない。

（被告の主張）

本件明細書（【００３０】【００３６】【００４５】【００８２】等）において、「取引を特定するための情報」として「ユーザ情報」を用いることが開示されていること、「取引を特定するための情報」は、「取引情報」や「取引識別情報」の上位概念であることからすると、本件補正は新たな技術的事項が導入するものではなく、本件審決の新規事項の追加に係る判断に誤りはない。

６ 取消事由４（サポート要件についての判断の誤り）について

（原告の主張）

前記５

（原告の主張）

のとおり、本件各発明の「取引を特定するための情報」は、本件明細書に記載されていないから、サポート要件を充足しない。本件審決のサポート要件に係る判断には誤りがある 。

（被告の主張）

前記５

（被告の主張）

のとおり。

７ 取消事由５（明確性要件についての判断の誤り）について

（原告の主張）

仮に、本件各発明の「取引を特定するための情報」が「ユーザ情報と運賃情報とを関連付ける」情報であるとしても、具体的に「取引情報に含有される情報（営業番号等の個別取引番号、車両無線番号、乗車日時、乗車場所、会社ＩＤ等の会社識別情報等）」のうち、どの情報が「ユーザ情報と運賃情報とを関連付ける」ことが可能な情報であるか、当業者は特定できない。本件審決の明確性要件に係る判断には誤りがある。5

（被告の主張）

「取引を特定するための情報」とは、「取引を特定するため」に用いられる「情報」であり、その外縁は極めて明確であって、本件審決の明確性要件に係る判断に誤りはない。

８ 取消事由６－１（甲１発明に基づく本件発明７の進歩性欠如の判断の誤り）

について

（被告の主張）

本件審決は、相違点１－７－１を実質的な相違点ではないとするが、① 本件発明７においては、「運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される取引を特定するための情報と、ユーザ情報を、運送サービスを提供する前又は提供中にユーザ端末から受信する」態様に限定し、その他の手法で受信される情報を除外していること、② 本件特許の特許権者である被告が、自ら「運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される取引を特定するための情報と、ユーザ情報を、運送サービスを提供する前又は提供中にユーザ端末から受信する」態様に限定する旨の主張をしていることを考慮すると、相違点１－７－１は実質的にも相違点であるというべきである。

（原告の主張）

（被告の主張）

は、相違点１－７－１の構成が、本件発明７の「ホスト端末」を、形状、構造、構成要素、組成、作用、機能、性質、特性、行為又は動作、用途等の観点から、どのように特定しているのか明らかにするものではなく、失当である。

９ 取消事由６－２（甲１発明に基づく本件発明８の進歩性欠如の判断の誤り）

について

（被告の主張）

本件発明８は「ホスト端末は、ユーザ端末から取得した位置情報又はユーザ

5 端末から入力されたピックアップ希望位置情報に基づき、管理端末に配車指示

を出力する」構成であるところ、① 甲１公報（【００６２】）には、「加入タクシー(20)のリアルタイム位置情報」について記載されるのみで、ユーザ端末から取得した位置情報又はユーザ端末から入力された位置情報についての記載はないこと、② 甲１公報に、「ユーザ端末から取得した位置情報又はユーザ端末から入力されたピックアップ希望位置情報に基づき、管理端末に配車指示を出力する」構成を採用することについての記載、示唆はないことからすると、甲１発明ｂに周知技術を適用して相違点１－８の構成とすることは、当業者が容易に想到し得たとする本件審決の判断には誤りがある。

（原告の主張）

甲１公報に明示の記載がないとしても、相違点１－８に係る本件発明８の構成は、当業者にとって周知の技術にすぎないから、甲１発明ｂに周知技術を適用して相違点１－８の構成とすることは、当業者が容易に想到し得たとする本件審決の判断に誤りはない。

１０ 取消事由６－３（甲１発明に基づく本件発明９の進歩性欠如の判断の誤り）

について

（被告の主張）

本件審決は、甲１発明ｂの「タクシー利用者情報ログ」は、本件発明９の「決済に関する情報」に相当し、本件発明９と甲 1 発明ｂとでは「決済に関する情報を記憶するホスト記憶部を備えるホスト端末。」という点で一致するとするが、甲１発明ｂの「タクシー利用情報ログ」は、甲１公報の【図６】で示されるタクシーの利用に関する情報（固有情報、車両情報、乗車時間、乗車位置、使用者番号）であって、本件発明９の「決済に関する情報」に相当するものではない。また、本件発明９は「決済に関する情報を記憶するホスト記憶部を備え、ユーザ端末からの要求に応じて、過去の利用履歴を出力する」構成であるところ、

5 甲１公報に、かかる構成を採用することについての記載、示唆はない。

そうすると、甲１発明ｂに周知技術を適用して相違点１－９の構成とすることは、当業者が容易に想到し得たとする本件審決の判断には誤りがある。

（原告の主張）

本件発明９は、「ホスト端末」の「ホスト記憶部」が「決済に関する情報」を記憶し、その中から「ユーザ端末からの要求」に応じて「過去の利用履歴」を出力する構成である。本件発明９の「決済に関する情報」が「過去の利用履歴」を含むものであることは、請求項９の記載や、本件明細書（【００４７】）及び甲１公報（【００６７】【００８８】）の記載から明らかであって、甲１発明ｂの「タクシー利用者情報ログ」は、本件発明９の「決済に関する情報」に相当し、本件発明９と甲 1 発明ｂとでは「決済に関する情報を記憶するホスト記憶部を備えるホスト端末。」という点で一致するとする本件審決の判断に誤りはない。また、配車アプリにおいて「ユーザ端末からの要求に応じて、過去の利用履歴を出力する」ことは、周知技術にすぎず、ユーザの利便性という要請にかんがみても、当業者がかかる構成を採用しない理由はない。甲１発明ｂに周知技術を適用して相違点１－９の構成とすることは、周知技術の寄せ集めの域を出ないものであって、本件審決の判断に誤りはない。

１１ 取消事由６－４（甲１発明に基づく本件発明１０の進歩性欠如の判断の誤

り）について

（被告の主張）

本件発明１０は「ユーザによって入力されたメールアドレスに対して、運賃に関する領収書を送信する」構成であるところ、甲１公報に、運賃に関する領収書を発行することについての記載はなく、「ユーザによって入力されたメールアドレスに対して、運賃に関する領収書を送信する」構成を採用することについての記載、示唆もない。

5 そうすると、甲１発明ｂにおいて、相違点１－１０の構成とすることは、当

業者が容易に想到し得たとする本件審決の判断には誤りがある。

（原告の主張）

本件審決の甲１発明に基づく本件発明１０の進歩性欠如に係る判断に誤りはない。

第４ 当裁判所の判断

１ 本件各発明の内容本件明細書の記載は、別紙「特許公報」のとおりであり、本件各発明について、次のとおりの記載がある。

⑴ 技術分野本発明は、運賃情報を精算するための精算システム、ホスト端末、精算方法、プログラム及び車両に関する。（【０００１】）

⑵ 背景技術ユーザがタクシーを利用する場合、一般には、ユーザがタクシーで目的地に到着した後で、運賃をユーザがタクシーの運転手に支払う。運賃の支払い方法には現金の他に、電子マネーやクレジットカード等による支払も行われるが、現金以外で支払おうとした場合には、決済処理に時間がかかることがある。（【０００２】）特に電子マネーやクレジットカード等で決済する機器が迅速に稼働されない場合や、運転手がこれらの機器の利用方法になれていない場合には、決済処理を行うためにかなりの時間がかかってしまうことがあり、急いでいるユーザ等は電子マネーやクレジットカード等による支払いを敬遠することがある。（【０００３】）

⑶ 発明が解決しようとする課題以上のような背景を鑑み、本発明は、運送サービスを受けたユーザが迅速に運賃の支払いを完了させることができる精算システム、ホスト端末、精算

5 方法、プログラム及び車両を提供する。（【０００５】）

⑷ 課題を解決するための手段ア 本発明による精算システムは、運送サービスに関する取引情報を出力する管理端末と、前記取引情報を取得したユーザ端末からユーザ情報及び前記取引情報を取得し、前記ユーザ情報と紐づけ可能な運賃情報を運賃測定手段から取得するホスト端末と、を備えてもよい。（【０００６】）イ 本発明による精算システムにおいて、前記管理端末は、前記取引情報を表示する管理表示部を有し、前記ホスト端末は、前記管理表示部に表示された前記取引情報を読み取った前記ユーザ端末から前記取引情報を取得してもよい。（【０００８】）ウ 本発明による精算システムにおいて、前記管理表示部は前記取引情報をＱＲコードとして表示し、前記ホスト端末は、前記ＱＲコードを読み取った前記ユーザ端末から前記取引情報を取得してもよい。（【０００９】）エ 本発明による精算システムにおいて、前記管理端末は、前記運送サービスを提供する前又は提供中に前記取引情報を出力してもよい。（【００１０】）オ 本発明による精算システムにおいて、前記ホスト端末は、前記運送サービスを提供する前又は提供中に前記ユーザ端末から前記取引情報及び前記ユーザ情報を取得してもよい。（【００１１】）カ 本発明によるホスト端末は、ユーザ端末で取得された、管理端末から出力された運送サービスに関

5 する取引情報及びユーザ情報を記憶するホスト記憶部と、運賃測定手段で測定された運賃情報を前記ユーザ情報と紐づけて前記ホスト記憶部で記憶させるホスト制御部と、を備えてもよい。（【００１６】）

⑸ 発明の効果本発明の一態様によれば、到着地に着くまでの間に取引情報及びユーザ情報を取得し、到着地に着くことで判明する運賃情報を既に取得しているユーザ情報と紐づけることができる。このため、運送サービスを受けたユーザが迅速に運賃の支払いを完了させることができ、従前のように電子マネーやクレジットカード等で決済する機器が迅速に稼働されない場合や運転手がこれらの機器の利用方法になれていない場合に、決済処理を行うためにかなりの時間がかかってしまうということもない。（【００２４】）

２ 取消事由１－１（甲１発明に基づく本件発明１、３及び６の進歩性欠如の判断の誤り）について⑴ 甲１発明ａの内容、本件発明１と甲１発明ａとの対比甲１公報の記載及び弁論の全趣旨によれば、甲１発明ａの内容は、本件審決の認定するとおりであり、本件発明１と甲１発明ａとを対比すると、本件発明１と甲１発明ａとの間には、相違点１－１－１、１－１－２、１－１－３が存在することが認められる。本件発明１及び甲１発明の要旨並びに本件発明１と甲１発明との相違点に係る原告の主張は、特許請求の範囲の記載に基づくものとはいえず、いずれも採用できない。⑵ 相違点１－１－１、１－１－２に係る容易想到性ア そこで、相違点１－１－１、１－１－２に係る容易想到性について検討するに、証拠（甲２～１１）及び弁論の全趣旨によれば、ユーザの操作により、タブレット端末等にＱＲコード等の二次元情報を表示させ、これを読み取ることによって情報を得る構成（ＱＲコード方式。周知技術Ａ）は、

5 原出願日当時の周知技術であったことが認められる。また、原出願日前に出願公開された公開特許公報において、ＱＲコード方式に代えてブルートゥース通信方式等を用いる構成や、ＱＲコード方式とブルートゥース通信方式等を組み合わせる構成が開示されていることに加え（甲２【０１３２】、甲３【００４１】、甲４【００４１】、甲５【００６６】、甲６【００６７】、甲７【００２８】、甲８【０１２１】、甲９【００１２】、甲１０【００３８】）、平成１８年６月１５日に出願公開された甲１１公報（【００８３】【００８４】【００８５】【図１２】）において、別紙「甲１１公報（抜粋）」のとおり、タクシーの利用者の携帯端末によって、タクシー運転手の携帯端末に表示される取引コード（ＱＲコード）が取得され、当該取引コードが情報管理サーバに送信される実施形態（甲１１記載技術）が開示されていることに照らすと、原出願日当時、ＱＲコード方式をブルートゥース通信方式に置換可能であることや、両方式の双方を併用可能であることも、当業者に周知であったと認められる。さらに、ブルートゥース通信方式にはペアリングが行われない場合があるという技術的課題があるところ（甲７７、８４）、甲１１公報（【００８３】【００８４】【００８５】【図１２】）の記載や、平成２８年５月２０日付けの「スマホで利用できる新しい電子決済システム「Origami Pay」が正式スタート」と題するウェブサイトの記事（甲５５）の「Origami Pay は…Bluetooth LE ベースの近距離通信技術「iBeacon」を活用したモバイル端末向けの電子決済サービス。」、「iBeacon による読み取りがうまく行かなかった場合などを想定して、スマホのカメラでＱＲコードをスキャニングする方法なども用意している。」との記載に照らすと、ペアリングが行われない場合に備えて、ＱＲコード方式をも用意することは、原出願日当時の技術常識であったと認められ（被告は、

5 本件審判請求の手続において、甲５５号証に基づく主張は実質的に審判請求書における周知技術とは異なる副引用例となる技術を主張するものであるとして請求の理由の補正が許可されなかったのであるから、本件訴訟において上記記事の内容を考慮すべきでない旨の主張をするが、これを「審判請求書における周知技術とは異なる副引用例となる技術」を主張するものということはできない。）、甲１公報に接した当業者は、タクシー端末（管理端末）が有するタクシー利用情報（取引を特定するための情報）を使用者移動通信端末（ユーザ端末）を利用してチケットセンタ（ホスト端末）に送信することにつき、ペアリングが行われない場合に備えて、ＱＲコード方式をも用意すべきであることを理解するものといえる。そうすると、甲１発明ａと甲１１記載技術は、タクシー料金精算システムに係るもので、その技術分野を同じくするとともに、タクシーの端末が有する取引に係る情報をユーザの端末を利用してサーバに送信するという点でその機能を同じくすることをも踏まえると、甲１発明ａに、原出願日当時の技術常識を踏まえて設計変更等を行いつつ、甲１１記載技術を適用する動機付けがあるというべきである。以上によれば、甲１発明ａに甲１１記載技術及び周知技術Ａを適用して、相違点１－１－１、１－１－２に係る本件発明１の構成とすることは、当業者が容易に想到し得たものというべきである。イ 被告は、甲１発明のブルートゥース通信方式に代えてＱＲコード方式を用いることは、甲１発明の目的に反する旨の主張をするが、甲１公報に「また、タクシー端末と移動通信端末の簡単な操作でタクシー料金を携帯電話小額決済で安全に支払うことができるタクシー運行システム及び方法を提示することにもう一つの目的がある。」（【０００８】）、「使用者移動通信端末…にタクシー安心サービスのコンテンツを設定する時点は、

5 好ましくは使用者の乗車前になされてもよいが、乗車後に設定しても問題ない。」（【００７４】）と記載されていることを踏まえると、当業者は、甲１発明において、簡単な操作をユーザに行わせることを許容していると理解するのであり、甲１発明のブルートゥース通信方式に代えてＱＲコード方式を用いることが、甲１発明の目的に反するとまでいうことはできない。また、被告は、① 甲１発明は本件発明１の管理端末に対応する端末を備えるものではない、② 仮に甲１発明のタクシー端末を本件発明１の管理端末として利用するとしても、甲１発明のタクシー端末がＱＲコードを表示できるような表示部を備えているか不明である、③ 後部座席のユーザが前部座席の管理端末を操作し、これに表示されているＱＲコードを読み取るのは困難である、④ 相違点に係る本件発明１の構成に想到することは、「容易の容易」に該当する旨の主張をするが、証拠（甲５１、９９、１０３、１０４、１２４）及び弁論の全趣旨によれば、前部座席に設置されるタクシー端末とは別途に、又は、これに加えて、後部座席に、広告等を表示するためのタブレット端末等を設置することは、原出願日当時の技術常識であったと認められ（被告は、原告が、本件訴訟において新たに提出した証拠に基づき、後部座席にタブレット端末等を設置することが原出願日当時の技術常識であった旨の主張をすることは許されないというが、上記証拠は、当業者が甲１発明ａに周知技術Ａ及び甲１１記載技術を組み合わせることを容易に想到し得たものであることを裏付けるもので、原告の主張は、本件審判請求の手続において争点となっていた無効原因を立証するための周知技術を裏付ける範囲を超えるものではない。）、相違点に係る本件発明１の構成に想到することは、格別の努力を要するものでないから、被告の主張は採用できない。

5 被告は、甲１１公報は、料金確定後にＱＲコード決済を行う態様を開示するのであり、甲１発明と甲１１記載技術を組み合わせたとしても、料金確定後にＱＲコード決済を行う態様を並列に用いることになるにすぎない旨の主張もするが、甲１１公報の料金確定後にＱＲコード方式により情報を送信する構成を、原出願日当時の技術常識を踏まえて設計変更等を行いつつ、甲１発明ａの料金確定前の情報の伝達について、ブルートゥース通信方式により情報を送信する構成と併用するように適用することは、当業者が容易に想到し得たものというべきである。⑶ 相違点１－１－３に係る容易想到性甲１公報の記載（【００２２】【００８３】）を踏まえると、相違点１－１－３に係る本件発明１の構成とすることは、当業者が容易に想到し得たものであるとする本件審決の判断に誤りはない。⑷ 小括以上によれば、本件発明１、並びに、これを引用する本件発明３及び６について、甲１発明ａ並びに周知技術及び甲１１記載技術に基づいて、当業者が容易に発明することができたものでないとする本件審決の判断には誤りがある。

３ 取消事由６－１（甲１発明に基づく本件発明７の進歩性欠如の判断の誤り）について⑴ 甲１発明ｂの内容、本件発明７と甲１発明ｂとの対比ア 本件発明７は、管理端末、ユーザ端末、ホスト端末という二つ以上の装置を組み合わせてなる全体装置（本件発明１の精算システム）に組み合わされる各装置（ホスト端末）の発明（サブコンビネーション発明）である。そして、サブコンビネーション発明においては、特許請求の範囲の請求項中に記載された「他の装置」に関する事項が、形状、構造、構成要素、組成、作用、機能、性質、特性、行為又は動作、用途等の観点から当該請求

5 項に係る発明の特定にどのような意味を有するかを把握して当該発明の要旨を認定する必要があるところ、「他の装置」に関する事項が当該「他の装置」のみを特定する事項であって、当該請求項に係る発明の構造、機能等を何ら特定してない場合は、「他の装置」に関する事項は、当該請求項に係る発明を特定するために意味を有しないことになるから、これを除外して当該請求項に係る発明の要旨を認定するのが相当である。イ これを本件について見るに、請求項７に記載された「運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される取引を特定するための情報」（構成要件７Ａ）との事項は、「管理端末」の構造、機能等（取引を特定するための情報が運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示されること）を特定するものの、これによって「ホスト端末」が受信する「取引を特定するための情報」の性質や特性が変わるわけでなく、上記事項は、「取引を特定するための情報」の性質や特性を特定するものでも、「ホスト端末」の構造や機能、動作を特定するものでもない。そうすると、請求項７に記載された「運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される取引を特定するための情報」との事項は、「管理端末」のみを特定する事項であって、サブコンビネーション発明である本件発明７の「ホスト端末」の構造、機能等を特定するための意味を有しないことから、次のとおり、上記事項を除外して、本件発明７の要旨を認定すべきである。（本件発明７の要旨）取引を特定するための情報とユーザ情報を、運送サービスを提供する前又は提供中にユーザ端末から受信するホスト受信部を備え、ホスト受信部は、前記運送サービスに対する運賃情報が確定した後で、取引を特定するための情報及び運賃情報を受信し、

5 運賃情報が確定した後で取得した取引を特定するための情報とユーザ端末から取得した取引を特定するための情報とを用いて、ユーザ情報と運賃情報とを関連付けるホスト制御部を備えることを特徴とするホスト端末。ウ 甲１公報の記載及び弁論の全趣旨によれば、甲１発明ｂの内容は、本件審決の認定のとおりであり、本件発明７と甲１発明ｂとを対比すると、本件発明７と甲１発明ｂとの間には、相違点１－７－２が存在することが認められるものの、相違点１－７－１は、本件発明７の要旨認定において除外された「運送サービスを提供する前又は提供中のユーザの操作によって管理端末の管理表示部で表示される」との構成に係るものであるから、相違点とは認められない。⑵ 相違点１－７－２に係る容易想到性相違点１－７－２は、本件発明１に係る相違点１－１－３と実質的に同じであり、前記２⑶のとおり、相違点１－７－２に係る本件発明７の構成とすることは、当業者が容易に想到し得たものである。⑶ 小括以上によれば、本件発明７は、甲１発明ｂに基づいて当業者が容易に発明をすることができたものであり、本件審決の判断に誤りはない。

４ 取消事由６－２（甲１発明に基づく本件発明８の進歩性欠如の判断の誤り）について⑴ 本件発明８と甲１発明ｂとの対比本件発明８と甲１発明ｂとを対比すると、本件発明８と甲１発明ｂの間には、相違点１－７－２に加えて、相違点１－８が存在することが認められる。⑵ 相違点１－８に係る容易想到性証拠（甲１７～１９、甲２４～２８）及び弁論の全趣旨によれば、配車アプリにおいて、ユーザが配車希望位置の情報をスマートフォンに入力し、シ

5 ステム管理者側で当該場所に配車を行うことは、原出願日当時、周知技術であったと認められ、甲１公報に明示の記載がないとしても、甲１発明ｂに周知技術を適用して相違点１－８に係る本件発明８の構成とすることは、当業者が容易に想到し得たと認められる。⑶ 小括以上によれば、本件発明８は、甲１発明ｂ及び周知技術に基づいて当業者が容易に発明をすることができたものであり、本件審決の判断に誤りはない。

５ 取消事由６－３（甲１発明に基づく本件発明９の進歩性欠如の判断の誤り）について⑴ 本件発明９と甲１発明ｂとの対比本件発明９と甲１発明ｂとを対比すると、本件発明９と甲１発明ｂの間には、相違点１－７－２、１－８に加えて、相違点１－９が存在することが認められる。被告は、甲１発明ｂの「タクシー利用情報ログ」は、本件発明９の「決済に関する情報」に相当するものではなく、本件審決が、本件発明９と甲１発明ｂとでは「決済に関する情報を記憶するホスト記憶部を備えるホスト端末。」という点で一致するとするのは誤りである旨の主張をする。しかしながら、本件発明９は「決済に関する情報を記憶するホスト記憶部を備え（構成要件９Ａ）、ユーザ端末からの要求に応じて、過去の利用履歴を出力する（構成要件９Ｂ）」構成であり、本件明細書の「決済に関する情報はホスト記憶部…で記憶され、ユーザ端末…から適宜読み出すことができるようになってもよい。このような態様を採用した場合には、ユーザは過去の利用履歴を容易に確認することができる点で有益である。」（【００４７】）との記載や、甲１公報の「タクシー利用情報を図６のようにタクシー端末固有番号、車両番号、乗車時間、乗車位置、及び使用者移動通信端末の電話番号データをタクシー利用情報ログ…として格納部…に格納する。」

5 （【００６３】）、「格納部…に格納されたタクシー利用情報ログのうち、タクシー端末…から受信された上記タクシー端末固有番号とマッチされるタクシー端末固有番号を含むタクシー利用情報ログ…を選択して該当タクシー利用情報ログ…に含まれた使用者移動通信端末の電話番号データを抽出し、該当電話番号にタクシー料金を携帯電話小額決済サーバ…に決済要請する。」（【００６７】）との記載を考慮すると、本件発明９の「決済に関する情報」は、甲１発明ｂの「タクシー利用情報」を含むものであり、そうすると、甲１発明ｂの「タクシー利用情報ログ」、すなわち「過去の利用履歴」は、本件発明９の「決済に関する情報」に相当するというべきである。⑵ 相違点１－９に係る容易想到性証拠（甲２３、２９、甲３１～３３）及び弁論の全趣旨によれば、配車アプリにおいて、ユーザ端末からの要求に応じて、過去の利用履歴を出力することは、原出願日当時、周知技術であったと認められ、甲１公報に明示の記載がないとしても、本件発明ｂに周知技術を適用して相違点１－９に係る本件発明９の構成とすることは、当業者が容易に想到し得たと認められる。⑶ 小括そうすると、本件発明９は、甲１発明ｂ及び周知技術に基づいて当業者が容易に発明をすることができたものであり、本件審決の判断に誤りはない。

６ 取消事由６－４（甲１発明に基づく本件発明１０の進歩性欠如の判断の誤り）について⑴ 本件発明１０と甲１発明ｂとの対比本件発明１０と甲１発明ｂとを対比すると、本件発明１０と甲１発明ｂの間には、相違点１－７－２、１－８、１－９に加えて、相違点１－１０が存在することが認められる。⑵ 相違点１－１０に係る容易想到性商品の購入又はサービスの提供に対する料金の支払に対して、顧客の要請

5 により領収書を発行することは、広く行われてきた商慣行である。また、証拠（甲１１、１８～２１、３４～３８）及び弁論の全趣旨によれば、ユーザのメールアドレスに対して領収書を送付することは、原出願日当時、周知技術であったと認められる。そうすると、甲１公報に明示の記載がないとしても、本件発明ｂに周知技術を適用して相違点１－１０に係る構成とすることは、当業者が容易に想到し得たというべきである。⑶ 小括本件発明１０は、甲１発明ｂ及び周知技術に基づいて当業者が容易に発明をすることができたものであり、本件審決の判断に誤りはない。

７ 取消事由１－２（甲１発明に基づく本件発明１１の進歩性欠如の判断の誤り）について⑴ 本件発明１１と甲１発明ｂとの対比本件発明１１と甲１発明ｂとを対比すると、本件発明１１と甲１発明ｂの間には、相違点１－７－２、１－８、１－９、１－１０に加えて、相違点１－１１が存在することが認められる。⑵ 相違点１－１１に係る容易想到性そこで、相違点１－１１に係る容易想到性について検討するに、証拠（甲１６～２４）及び弁論の全趣旨によれば、配車アプリにおいて、ユーザ端末から行先を入力する構成は、原出願日当時、周知技術であったと認められる。本件審決は、本件発明１１の「指定場所」が「指定場所までの案内がナビゲーションシステム４０で行われることを可能にする」との効果を奏する点から見ても、上記構成を単なる周知技術ということはできないとするが、甲１１公報の記載を考慮しても、本件発明１１の「指定場所」が上記効果を奏すると見ることはできない。甲１発明ｂと上記周知技術が技術分野を同じくすることを考慮すると、甲

5 １発明ｂに上記周知技術を適用して相違点１－１１に係る構成とすることは、当業者の通常の創作能力の発揮にすぎないものといえ、動機付けの存否にかかわらず、当業者が容易に想到し得たというべきである。⑶ 小括したがって、本件発明１１は、甲１発明ｂ及び周知技術に基づいて当業者が容易に発明をすることができたものであり、本件審決の判断には誤りがある。

８ 取消事由２－１（甲４１発明に基づく本件発明１、３、６の進歩性欠如の判断の誤り）について⑴ 甲４１発明ａの内容、本件発明１と甲４１発明ａとの対比ア 事案にかんがみ、取消事由２－１についても検討するに、甲４１公報の記載及び弁論の全趣旨によれば、甲４１発明ａの内容は、本件審決の認定のとおりと認められる。本件発明１及び甲４１発明の要旨に係る原告の主張は、特許請求の範囲の記載に基づくものとはいえず、採用できない。イ（ア）そして、本件発明１と甲４１発明ａとを対比すると、本件審決の認定する相違点２－１－２を含め、次のとおりの相違点が存在することが認められる。（相違点２－１）本件発明１では、管理表示部を有する管理端末であって、運送サービスを提供する前又は提供中のユーザの操作によって、管理表示部で取引を特定するための情報を表示する管理端末と、前記取引を特定するための情報を読み取るユーザ端末からユーザ情報を取得するホスト端末と、を備え、管理表示部に表示された取引を特定するための情報がユーザ端末で読み取られて、ホスト端末に送信されるのに対し、甲４１発明ａでは、チケットセンタ５を備え、利用者は、タクシーに乗車後、当該タクシー車両１の車両番号（取引を特定するための情報）

5 を乗務員に聞く等して取得し、その車両番号を携帯端末３に入力して、保存されているチケット番号送信メールに記載し、このチケット番号送信メールをチケットセンタ５へ返信するのであって、「管理表示部に表示された取引を特定するための情報を読み取る」ものではない点。（イ）本件審決は、甲４１発明ａの「車両番号」は、利用者が、タクシーに乗車後、その車両番号を携帯端末に入力しチケット番号送信メールに記載したものをチケットセンタに返信した時点では、「取引を特定するための情報」として機能せず、この時点における「車両番号」は、本件発明１の「取引を特定するための情報」に相当しないことを前提に、本件発明１と甲４１発明ａとの間には相違点２－１－１が存在するとするが、請求項１の記載に加え、本件明細書（【００３８】）に「取引情報は、車両情報及び営業情報を含んでもよい。」、「本願における「取引情報」は取引を特定できる、運賃情報及びユーザ情報以外のあらゆる情報を含んでいる。」との記載があることをも考慮すると、甲４１発明ａの「車両番号」は、時点を問わず「取引を特定するための情報」に相当するというべきであり、本件審決の認定判断はその前提において誤りがある。また、本件審決は、本件発明１と甲４１発明ａとの間には相違点２－１－３が存在するとするが、甲４１発明ａにおいては、利用者が、タクシーに乗車後、チケット番号送信メールをチケットセンタに返信した時点で、すなわち「運送サービスを提供する前又は提供中」に、「取引を特定するための情報」に相当する「車両番号」が送信されることを考慮すると、相違点２－１－３のうち、「甲４１発明ａでは、取引を特定するための情報が『運送サービスを提供する前又は提供中』に送信されるものではない点」を相違点ということはできない。さらに、本件審決は、甲４１発明ａにおいて、本件発明１の「ユーザ情報」に相当するのは、チケット番号送信メールが携帯端末で設定さ

5 れているタクシーチケットの利用者のメールアドレスであり、「タクシーチケットのチケット番号」は、これに相当しないことを前提に、本件発明１と甲４１発明ａとの間には相違点２－１－４が存在するとする。しかしながら、本件明細書（【００４２】）の「ホスト端末…にユーザ端末…から予め入力されて記憶されるユーザ情報は、ユーザ識別番号又はユーザ識別記号等のユーザ識別情報、ユーザの氏名、電話番号、メールアドレス、性別、年齢等の個人識別情報と、クレジットカードのカード番号、有効期限、デビットカードのカード番号、引き落とし口座情報等の決済手段情報とを含んでもよい。取引情報を読み取ったユーザ端末…から送信されるユーザ情報はユーザ識別情報だけを含み、ユーザ識別情報を用いて、取引情報とホスト端末…に記憶されているユーザ情報に含まれるその他の情報とが紐づけられてもよい。」との記載を考慮すると、本件発明１の「ユーザ情報」は「決済手段情報」を含むものといえ、タクシーチケットを利用する乗客の「決済手段情報」である「タクシーチケットのチケット番号」は、「ユーザ情報」に相当するというべきであるから、本件審決の認定判断はその前提において誤りがある。そうすると、甲４１発明ａの「決済依頼として送信された管理番号がチケットセンタ５が生成して管理情報ファイル１０１に記録した管理番号と同じである場合に、決済を許可したタクシーチケットのチケット番号を決済日時及び決済金額とともに決済金額ファイル１０２に登録する処理」は、本件発明１の「ユーザ情報」に相当する「タクシーチケットのチケット番号」と運賃情報（決済金額）とを関連付ける構成であるから、本件審決の認定する相違点２－１－４を相違点ということはできない。

5 ⑵ 相違点２－１に係る容易想到性ア 前記のとおり、タクシーの前部座席に設置されるタクシー端末とは別途に、又は、これに加えて、後部座席に、広告等を表示するためのタブレット端末等を配置することは、原出願日当時の技術常識であったと認められる。また、証拠（甲８８～９１、甲１３２）及び弁論の全趣旨によれば、手動で行われていた電話番号、メールアドレス等の情報の入力作業を、入力ミスの防止、時間短縮という当然の要請に基づき、携帯端末を利用したＱＲコード方式等の自動読み取り方式に代え、又は、これを併用することは、原出願日当時の技術常識であったと認められる。そうすると、甲４１発明ａに、原出願日当時の技術常識を踏まえて設計変更等を行いつつ、周知技術Ａを適用して、甲４１発明ａの利用客が乗務員に聞く等して取得し携帯端末に入力する構成を、タブレット端末にＱＲコード等の二次元情報をユーザ操作により表示してこれを読み取る構成とする動機付けがあったと認められ、甲４１発明ａに周知技術Ａを適用して相違点２－１に係る本件発明１の構成とすることは、当業者が容易に想到し得たというべきである。イ 被告は、甲４１発明に先行技術を組み合わせた態様に更に変更を加えて本件発明１の進歩性を否定することは「容易の容易」によって進歩性を否定するもので許されない旨の主張をするが、本件においては、甲４１発明ａに、原出願日当時の技術常識を踏まえて設計変更等を行いつつ、周知技術Ａを適用することは、当業者が容易に想到し得たものであるとするのであり、「容易の容易」に該当するわけではない。また、被告は、① 甲４１発明ａの表示部は、ユーザの操作によって車両番号を表示させることは想定されていないこと、② 仮に車両番号を表示させるとしても、甲４１発明ａの携帯端末がＱＲコードを読み取

5 る機能を有するか不明である上、ユーザ（利用者）がタクシーチケット決済端末を操作することにならないこと、③ 後部座席にいるユーザが前部座席に設置されているタクシーチケット決済端末の表示部に表示されるＱＲコードを読み取るのは困難であることを踏まえると、相違点に係る本件発明１の構成に想到する動機付けはなく、むしろ阻害要因が存在する旨の主張をする。しかしながら、甲４１発明ａに、原出願日当時の技術常識を踏まえて設計変更等を行いつつ、周知技術Ａを適用して、甲４１発明ａの利用客が乗務員に聞く等して取得し携帯端末に入力する構成を、タブレット端末にＱＲコード等の二次元情報をユーザ操作により表示してこれを読み取る構成とする動機付けがあったことは、前記アのとおりであり、阻害要因が存在するとも認められないことから、被告の主張は採用できない。被告は、タクシーチケットの僅かな利用者のために高価な端末を導入してＱＲコードを表示させる構成とするのはコスト的に見合わない旨の主張もするが、前部座席に設置されるタクシー端末とは別途に、又は、これに加えて、後部座席に、広告等を表示するためのタブレット端末等を設置することは、原出願日当時の技術常識であったことからすると、被告の主張は採用できない。⑶ 以上によれば、本件発明１、並びに、これを引用する本件発明３及び６について、甲４１発明ａに基づいて当業者が容易に発明をすることができたものではないとする本件審決の判断には誤りがある（被告は、甲４１発明ａにおいて本件発明６の「ユーザ端末から行先が入力可能」とする態様を採用するのは困難である旨の主張もするが、本件審決は、この点について判断を示すものでないから、本判決においても判断を示さないこととする。）。

９ 結論そうすると、本件審決には、原告の主張する審決取消事由のうち１－１、１

5 －２、２－１が存在することから、その余の点について判断するまでもなく、原告の請求には理由があり、被告の主張する審決取消事由は、いずれも認められないから、被告の請求は理由がない。よって、主文のとおり判決する。

知的財産高等裁判所第２部

裁判長裁判官

森 冨 義 明

裁判官

菊 池 絵 理

裁判官

頼 晋 一

(別紙)

特許公報省略

68~89

（別紙）

甲１１公報（抜粋）【発明の詳細な説明】5 【技術分野】【０００１】本発明は、二者間での金品の授受に伴う支払いを支援する情報管理装置、情報管理システム…に関する。【０００２】従来、インターネット等のネットワーク上において、クレジットカードやプリペイド型の電子マネー等を利用したオンライン決済が行われている（…）。利用者は、オンラインショップの商品販売ページを閲覧して商品を選択し、決済方法を選択してオンライン決済を行う。このとき、利用者は、オンラインショップの決済ページにて、クレジットカード番号、有効期限や商品配達先の住所等の必要事項を入力し、オンラインショップへ送信する。一方、オンラインショップは、利用者から商品購入の申し込みがあった旨をクレジットカード発行会社等へ連絡し、決済承認が得られた後、指定された住所へ商品の発送を行う。【０００３】しかしながら、このようなオンライン決済では、利用者は商品購入の度にクレジットカード番号や住所等の個人情報を入力しなければならず、セキュリティ上、好ましくない。ネットワークを通してこれらの重要なデータを送信する際の第三者による盗聴についてはＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）による暗号化通信技術（…）により防ぐことが可能であるが、オンラインショップからのデータの流出や、この流出したデータの悪用等を防ぐことはできない。【発明が解決しようとする課題】【０００８】非特許文献２や特許文献１に記載のようにネットワーク上の個人情報のやり取りを暗号化通信技術により行っても、オンラインショップからのデータの流出や、流出したデータの悪用等を防ぐことは不可能である。また、特許文献２、３に記載の技術では、オンライ5 ンショップにクレジットカード番号を知らせることはないが、その代わりに特許文献２では購入する商品およびその個数の情報からなる購入情報と利用者毎に異なる利用者識別子とを知らせ、特許文献３では商品の正式発注データと信託管理コードとを知らせている。【０００９】特許文献２、３に記載の技術では、クレジットカード番号をオンラインショップに直接知らせないので、クレジットカード番号の流出や悪用等は起こりにくいものの、このクレジットカード番号に代えて個人を特定する利用者識別子や信託管理コードをオンラインショップに知らせているので、完全に起こらないとは言えない。また、その個人が何を購入したかという情報がオンラインショップに知られてしまうという問題がある。【００１０】そこで、本発明においては、オンラインショップなどの販売者等の支払いを受ける者とその購買者等の支払者との二者間での金品の授受を行う場合に、支払者から支払いを受ける者に対して一切の個人情報を知らせることなく支払いを行うことを可能にすることを目的とする。【発明の効果】【００２８】…支払者から支払受取者に対して一切の個人情報を知らせることなく簡単に支払いを行うことが可能となり、個人情報の流出や悪用等を防止することが可能となる。【００３１】…誤って支払いを行うことを防止することができるとともに、本人の身に覚えのない支払いが行われることを防止することが可能となる。【００３３】…副装置から支払受取者装置へ個人情報が流れることはあり得ず、個人情報の流出や悪用等を完全に防止することができる。5 【発明を実施するための最良の形態】【００７１】図１２は販売店に設置された固定端末の例を示している。図１２に示す固定端末３１には、ＰＣ３０ａと同様の表示画面３１ａと、購入者の携帯端末と情報の送受信を行う送受信部３１ｂとを備える。送受信部３１ｂは、購入者の携帯端末との間で、無線や赤外線等を用いて送受信を行うものである。【００７２】購入者の使用する携帯端末は、第１実施形態と同様に二次元コードを読み取る機能を有するものや、送受信部３１ｂと情報の送受信を行うことにより取引コードを取得する機能を有するもの等である。あるいは、手入力により取得コードを取得するものでも良い。【００８３】（実施の形態８）本発明の第８実施形態は、第１実施形態における取引コードを表示するＰＣ３０ａを携帯端末とし、購入者の携帯電話装置３０ｂ等の携帯端末との間で電子マネーのやり取りを行う例である。【００８４】例えば、タクシー料金のやり取りを行う料金精算システムの場合、タクシーの運転手（タクシーサービス提供者）が取引コードを表示する携帯端末やタクシーに固定した固定端末等の端末を使用し、タクシーの利用者がこの取引コードを入力する携帯端末を使用するタクシー料金精算システムとする。タクシーの運転手は、タクシーの料金が確定した段階で、携帯端末により販売管理サーバ２０へ取引コードの発行を依頼する。販売管理サーバ２０は、この要求に基づき、取引コードの発行を情報管理サーバ１０へ依頼し、取引コード発行手段１１１により発行された取引コードをタクシー運転手の携帯端末へ提供する。【００８５】タクシーの利用者は、自分自身の携帯端末によりこのタクシー運転手の携帯端末から取引コード等を取得する。以後の処理は前述と同様である。これにより、タクシーの利用者は、タクシーの運転手側に対して一切の個人情報を提供することなく、タクシーの料金の決済を行うことが可能である。…【図３】【図１２】以 上