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

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

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

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

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

判 決

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

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

同 高 石 秀 樹

同 奥 村 直 樹

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

同 鈴 木 信 彦

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

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

同 多 田 宏 文

主 文

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

日にした審決のうち、「特許第７１３４３０１号の請求項１、２に係る発

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

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

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

事 実 及 び 理 由

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

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

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

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

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

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

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

5 ことを特徴とするホスト端末。ウ 甲１公報の記載及び弁論の全趣旨によれば、甲１発明ｂの内容は、本件審決の認定のとおりであり、本件発明６と甲１発明ｂとを対比すると、本件発明６と甲１発明ｂとの間には、相違点１－６－２が存在することが認められるものの、相違点１－６－１は、本件発明６の要旨認定において除外された「タブレット端末からなる管理端末の管理表示部で表示される」との構成に係るものであるから、相違点とは認められない。⑵ 相違点１－６－２に係る容易想到性相違点１－６－２は、本件発明１に係る相違点１－１－３と実質的に同じであり、前記２⑶のとおり、相違点１－６－２に係る本件発明６の構成とすることは、当業者が容易に想到し得たものである。⑶ 小括以上によれば、本件発明６は、甲１発明ｂに基づいて当業者が容易に発明をすることができたものであり、本件審決の判断に誤りはない。

４ 取消事由２（甲１４発明に基づく本件発明１及び２の進歩性欠如の判断の誤り）について⑴ 甲１４発明ａの内容、本件発明１と甲１４発明ａとの対比ア 事案にかんがみ、取消事由２についても検討するに、甲１４公報の記載及び弁論の全趣旨によれば、甲１４発明ａの内容は、本件審決の認定のとおりと認められる。本件発明１及び甲１４発明の要旨に係る原告の主張は、特許請求の範囲の記載に基づくものとはいえず、採用できない。イ（ア）そして、本件発明１と甲１４発明ａとを対比すると、本件審決の認定する相違点２－１－１、２－１－２、２－１－３が存在することが認められる。（イ）本件審決は、甲１４発明ａにおいて、本件発明１の「ユーザ情報」に相当するのは、携帯端末で設定されているタクシーチケットの利用者の

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

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

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

５ 結論そうすると、本件審決には、原告の主張する取消事由１及び２が存在するこ

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

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

裁判長裁判官

森 冨 義 明

裁判官

菊 池 絵 理

裁判官

頼 晋 一

(別紙)

特許公報省略

56~77

（別紙）

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