令和7(ネ)10078損害賠償請求控訴事件

令和８年５月２７日判決言渡
令和７年（ネ）第１００７８号 損害賠償請求控訴事件
（原審・大阪地方裁判所令和６年（ワ）第６２１６号）
口頭弁論終結日 令和８年３月９日
5 判 決
当事者の表示 別紙当事者目録記載のとおり
主 文
１ 本件各控訴をいずれも棄却する。
２ 控訴費用は、控訴人らの負担とする。
10 事 実 及 び 理 由
本判決において用いる主な略語は、次のとおりである（原判決で定義している略
語を含む。）。
原告Ａ 控訴人Ｘ
原告会社 控訴人ベスト交通株式会社
15 被告 被控訴人ＧＯ株式会社
本件特許 発明の名称を「タクシー配車管理システム、タクシー配車管理装
置、及び、タクシー配車管理プログラム」とする特許第６５４６
５６２号に係る特許
本件特許権 本件特許に係る特許権
20 本件明細書 本件特許の願書に添付された明細書及び図面。【】は本件明細書
の段落番号を、【図】は本件明細書の図面番号を示す。
本件発明 本件特許の特許請求の範囲の請求項１に係る発明。本件特許の特
許請求の範囲を「請求項１」などと表記する。
被告アプリ 「ＧＯ」との名称のスマートフォン向けタクシー配車アプリケー
25 ション
被告製品 被告アプリを用いてタクシーの配車等の処理を行う、原判決別紙
「被告製品の構成」記載の構成を備えるシステム
ＧＯＡＰＩコアサービス 被告製品において、被告アプリからの通信を一次受
けし、様々な内部サービスと連携してタクシーの配車や運賃の決
済の処理を行うサービス
5 ＧＯＡＰＩサーバ 被告製品において、ＧＯＡＰＩコアサービスを含む様々な
内部サービスを提供するサーバ群
配車マッチングサービス ユーザの指定した乗車位置情報と配車条件、車両動
態から周辺車両を探索し、どのユーザにどの車両を配車するかの
マッチング処理を行うサービス
10 第１ 控訴の趣旨
１ 原判決を取り消す。
２ 被告は、原告会社に対し、２５億８９００万１３６８円及びこれに対する令
和６年７月１１日から支払済みまで年３％の割合による金員を支払え。
３ 被告は、原告Ａに対し、１億９４２９万１３８２円及びこれに対する令和６
15 年７月１１日から支払済みまで年３％の割合による金員を支払え。
第２ 事案の概要
１⑴ 本件は、本件特許権の特許権者である原告らが、被告製品は本件発明の技
術的範囲に属し、被告による被告製品の使用は本件特許権を侵害するなどと
主張して、被告に対し、民法７０９条に基づき、原告会社につき、２５億８
20 ９００万１３６８円（実施手数料相当額２３億８９００万１３６８円、弁護
士費用２億円）及びこれに対する令和６年７月１１日（訴状送達日の翌日）
から、原告Ａにつき、１億９４２９万１３８２円（実施手数料相当額１億７
７２９万１３８２円、弁護士費用１７００万円）及びこれに対する同日から
各支払済みまで民法所定の年３％の割合による遅延損害金の支払を求める事
25 案である。
⑵ 原審は、被告製品は、少なくとも、本件発明の構成要件の一部を充足せず、
その一部につき均等侵害は成立しないとして、原告らの請求をいずれも棄却
し、原告らは、これを不服として本件各控訴を提起した。
２ 前提事実、争点、争点に関する当事者の主張は、次のとおり補正ないし補充
し、第３のとおり当審における当事者の追加主張を加えるほかは、原判決「事
5 実及び理由」欄の「第２ 事案の概要」の３及び４（原判決３頁１４行目から
６頁１９行目まで）並びに「第３ 争点に関する当事者の主張」の１から１３
まで（同頁２１行目から１７頁２行目まで）に記載のとおりであるから、これ
を引用する。
⑴ 原判決７頁４行目を次のとおり改める。
10 「 そして、「タクシー選択範囲情報」は、配車可能なタクシーを絞り込
むための情報であることや、請求項２において「タクシー選択範囲情報は…
距離範囲であって」と「タクシー選択範囲情報」の意義を殊更限定している
ことからすると、請求項１（本件発明）の「タクシー選択範囲情報」には、
距離的範囲を設定する情報のほか、タクシーの到着時間という時間的範囲を
15 設定する情報も含まれるというべきであり、そう解することが、ユーザの意
思決定に基づく配車を実現することによりタクシー事業者間の実質的な公平
性を確保し、配車プロセスに係る情報を共有することにより、その透明性を
担保するという本件特許の目的や、ユーザに対してそのニーズに合致した適
切な選択肢を提示するという本件発明の核心的構成にも沿う。本件明細書に
20 は「タクシー選択範囲情報として、現在地より半径５００ｍ以内、８００ｍ
以内、１２００ｍ以内、１５００ｍ以内の表示がされる」と記載されている
が（【００１８】）、これは実施例の一つにすぎず、上記の記載に続き「半
径範囲が拡大すれば呼べるタクシー車両の数が増え、選択肢は増える」と記
載されていることからも（【００１８】）、「タクシー選択範囲情報」には、
25 ユーザの選択肢を実質的に増やすための情報が含まれるというべきである。
被告製品において、ユーザが「今すぐ呼ぶ」ボタンを選択し、又は「ＡＩ
予約」ボタンを選択して具体的な時刻を指定することが、タクシーの到着時
間という時間的範囲を設定する情報を送信することに相当するのは前記のと
おりであり、したがって、被告製品は構成要件Ｂ２を充足する。」
⑵ 原判決７頁７行目の「記載によると、タクシー選択範囲情報とは」を「記
5 載に加え、請求項２において「タクシー選択範囲情報は…距離範囲であって」
と特定されていることからすると、「タクシー選択範囲情報」とは、「距離
的範囲を設定する情報」、すなわち」に改める。
⑶ 原判決７頁１１行目を次のとおり改める。
「 そうすると、被告製品において、ユーザがユーザ端末の「今すぐ呼ぶ」
10 ボタンを選択し、又は「ＡＩ予約」ボタンを選択して具体的な時刻を指定す
ることは、「タクシー選択範囲情報」を送信することに相当せず、被告製品
は構成要件Ｂ２を充足しない。」
⑷ 原判決７頁１８行目の「構成に関し、」の次に「① 本件特許の特許請求
の範囲及び本件明細書の各記載において、「物理的な車両」の意味を有する
15 「タクシー車両」と、「輸送サービス」の意味を有する「タクシー」とは厳
密に区別されていること、② 技術分野における「タクシー」の通常の意味
（広義）は、「輸送サービス」であること、③ 本件特許の目的を実現する
には、ユーザ端末に通知される「タクシー情報」により、ユーザが配車を決
定し得るものである必要性があること、④ 構成要件Ｄ３において、ユーザ
20 端末からタクシー迎車依頼地情報とタクシー選択範囲情報を受信したアプリ
管理サーバが、移動端末情報データベースを確認してユーザ希望の範囲に存
在する「タクシー情報」を作成しユーザ端末に通知する構成が開示されてい
ることからすると、「タクシー情報」の意義は、上位概念である「輸送（車
両又は会社）サービス項目一覧情報」と解釈され、」を加える。
25 ⑸ 原判決７頁２５行目の「共有すること」については、構成③にあるとおり」
を「共有し得るように通知し」について、本件発明の本質に照らすと、「配
車確認要求」の意義は、ユーザが特定の輸送サービスを利用する意思を有す
る旨の確定情報と、「共有し得るように通知し」の意義は、複数の者がアク
セスにより情報を確認することができるよう知らせることとそれぞれ解釈す
べきであり、構成要件Ｂ４は、同一の情報を複数の者に送信すること、すな
5 わち「同報送信」する構成を特定するものではない（このことは、原告らが、
特許出願手続において、本件発明の技術的範囲を不当に限定することなく、
その本質を明瞭にするために、請求項１及び２の「同報送信し」を「共有し
得るように通知し」に補正したことからも明らかである。）。そして、構成
③のとおり」に、８頁２行目の「タクシーを指定した」から３行目末尾まで
10 を「タクシー事業者は、自身の端末から管理サーバにアクセスすることによ
り、ユーザの配車確認要求を確認し得る状態にしているといえる。」にそれ
ぞれ改める。
⑹ 原判決８頁１１行目の「送信されるが、」の次に「上記のとおり、ユーザ
が個別のタクシー車両を指定することはできず、」を加える。
15 ⑺ 原判決８頁１４行目末尾を改行の上、次のとおり加える。
「 原告らは、「タクシー情報」の意義は「輸送（車両又は会社）サービ
ス項目一覧情報」と解釈すべき旨の主張をするが、本件特許の特許請求の範
囲及び本件明細書において、「タクシー」と「タクシー事業」は区別して記
載されている上、ユーザが最終的に配車決定することにより、配車の公平性
20 を確保し、アプリ運営主体とタクシー事業者が同じ情報を取得することによ
り、情報の公平性及び透明性を保つという本件発明の本質に照らすと、「タ
クシー情報」の意義は、個別のタクシー車両に係る情報と解釈すべきである。
また、原告らは、「共有し得るように通知し」の意義は複数の者がアクセ
スにより情報を確認することができるよう知らせることである旨の主張もす
25 るが、本件発明において、ユーザ端末からの配車確認要求、乗車完了情報の
通知先、「タクシー移動端末」からの迎車可能情報の通知先が具体的に特定
されていることからすると（構成要件Ｂ４、構成要件Ｂ６、構成要件Ｃ３）、
「共有し得るように通知し」の意義は、上記各端末が他の端末等と直接通信
し、配車確認要求等の情報を送信すること、すなわち「同報送信」（【００
２１】）することと解釈すべきである。」
5 ⑻ 原判決８頁２５行目を次のとおり改める。
「 構成要件Ｂ５の「タクシー移動端末からの迎車可否情報を確認可能と
し」とは、タクシー移動端末に起因する情報の内容をユーザが認識し得る状
態にあることをいい、上記情報が管理サーバに送信され同サーバからユーザ
端末に送信されることにより、ユーザが実質的にタクシー移動端末の情報を
10 認識し得る場合も含まれる。
被告製品では、乗務員の操作により配車承諾がされた場合、この情報が乗
務員アプリからＧＯＡＰＩコアサービスに送信され、配車が成立すると、ユ
ーザ端末の被告アプリの画面に「車両が手配できました」との表示がされ、
ユーザはこの表示を通じて、乗務員アプリ、すなわちタクシー移動端末の情
15 報を認識し得るのであり、乗務員の操作により配車承諾がされなかった場合
でも、この情報が乗務員アプリからＧＯＡＰＩコアサービスに送信され、ユ
ーザ端末に配車に関する最終的な結果が通知されるのであるから、ユーザは、
実質的に乗務員アプリからの迎車可否情報を認識し得るものといえる。
したがって、被告製品は構成要件Ｂ５を充足する。」
20 ⑼ 原判決９頁２行目の「結果であり」から３行目末尾までを「結果である。
ユーザ端末の「車両が手配できました」との表示は、最終的に配車が成立し
たことを通知するものであり、乗務員アプリから送信された配車承諾の情報
ではないし、被告製品では、配車の決定はＧＯＡＰＩコアサービスにより行
うため、乗務員の操作により配車承諾がされ、あるいは承諾がされなかった
25 という情報は、内部サービスの一つである配車マッチングサービスを提供す
るサーバに送信されるのみで、ユーザ端末には通知されず、ユーザにおいて、
乗務員アプリからの迎車可否情報を確認し得ない。」に改める。
⑽ 原判決９頁４行目の「少なくとも」から５行目の「情報であるところ」ま
でを「ユーザ端末からの配車確認要求に応答して、タクシー移動端末からユ
ーザ端末等に通知される結果、確認可能となる情報であるところ」に改める。
5 ⑾ 原判決９頁１２行目から１４行目までを次のとおり改める。
「 「アプリ管理サーバ」は、本件特許の目的を実現するために必要な各
機能を統括し、有機的に連携し協調して動作する集合体であるところ、被告
製品のＧＯＡＰＩサーバは一体として「アプリ管理サーバ」の機能を発揮し、
乗務員アプリから送信された位置情報は、被告製品のＧＯＡＰＩサーバの構
10 成要素（動態連携サーバ）に送信され、システム全体で利用されるのである
から、構成要件Ｃ２を実質的に充足する。」
⑿ 原判決９頁２５行目から１０頁２行目までを次のとおり改める。
「 被告製品において、ユーザが、タクシー会社等ないし車両タイプ等を
指定して「タクシーを呼ぶ」ボタンを押す行為は、ユーザ端末からの「配車
15 確認要求」に相当するところ、これに対応して、乗務員アプリから、乗務員
の操作により配車承諾がされ、あるいは配車承諾がされなかったこと、すな
わち「迎車可否情報」が、ユーザ端末、管理サーバ及び乗務員アプリにサー
バを介して実質的に「共有し得るように通知」されるのであるから、被告製
品は、構成要件Ｃ３を充足する。」
20 ⒀ 原判決１１頁１０行目の「被告製品は」を「前記のとおり、「タクシー情
報」の意義は「輸送（車両又は会社）サービス項目一覧情報」であるところ、
被告製品は」に改める。
⒁ 原判決１１頁２３行目の「また、」の次に「前記のとおり、「タクシー情
報」の意義は個別のタクシー車両に係る情報であるところ、」を加える。
25 ⒂ 原判決１２頁５行目の「表示されるから」を「表示されるのであるから、
アプリ管理サーバにおいて配車確定の処理を行うとしても、乗務員アプリか
らの「迎車可の情報」が契機となり、その結果として、乗務員アプリに確定
した「タクシー迎車依頼地情報」が通知されるといえるのであって」に改め
る。
⒃ 原判決１２頁８行目の「すなわち、」の次に「被告製品において、乗務員
5 アプリに乗車地の情報が表示される直接の契機は、ＧＯＡＰＩサーバが配車
確定の処理を行うことであり、」を加える。
⒄ 原判決１２頁２０行目末尾を改行の上、次のとおり加える。
「 被告は、被告製品に「配車確認要求」、「乗車完了情報」及び「迎車
可否情報」は存在せず、これらを登録するデータベースも備えない、被告製
10 品では、ブラウザ上で運行管理機能等に係る情報の管理画面を閲覧すること
ができるのみである旨の主張をする。
しかしながら、被告製品に「配車確認要求」、「乗車完了情報」及び「迎
車可否情報」が存在することは、前記のとおりであるし（被告は、本件特許
の目的を実現するのに必要不可欠な情報である「配車依頼数」や「無応答数」
15 が「結果情報データベース」に蓄積され、事業者向けアプリから閲覧可能で
あることを自認している。）、本件明細書には「タクシー事業者端末…から、
アプリ管理サーバ…への接続要求を行い、接続後、配車アプリについてＷｅ
ｂ要求によりデータベースをダウンロードする。これにより、タクシー事業
者端末…は稼働可能となる。」と記載されていること（【００３５】）から
20 すると、構成要件Ｅ２の「結果情報データベースを備える」には、相手方の
受動的な受信を待つこと（プッシュ型送信）による情報取得のみならず、相
手方が能動的に情報を取得できる環境を構築し、その所在を明らかにするこ
と（プル型通知）による情報取得も含まれるというべきである。」
⒅ 原判決１２頁２３行目の「被告は」を「被告製品に「配車確認要求」、
25 「乗車完了情報」及び「迎車可否情報」は存在せず、これらを登録するデー
タベースを備えるものではない。被告は、」に、１３頁２行目の「閲覧対象
ではない」を「閲覧対象ではなく、タクシー事業者にも共有されていない」
にそれぞれ改める。
⒆ 原判決１３頁８行目の「本件発明の」を「本件発明と被告製品とでは、
「タクシー選択範囲情報」につき、本件明細書に「距離的範囲」が例示され
5 ているか（本件発明）、あるいは「今すぐ呼ぶ」、「ＡＩ予約」との「時間
的範囲」が示されているか（被告製品）との点で相違するとしても、本件発
明の」に、１５行目の「本件発明と」を「アプリ運営主体の恣意性を排除し
て公平性、透明性を確保するという本件発明と」に、１９行目の「当業者に
とって容易である」を「当業者が、被告製品の製造の時点において、極めて
10 容易に想到し得たものである」にそれぞれ改める。
⒇ 原判決１３頁２１行目末尾に「本件発明と被告製品とは、被告製品では
「今すぐ呼ぶ」か「ＡＩ予約」かという「時間的範囲」が示され、また、被
告製品はユーザ端末から管理サーバに「タクシー選択範囲情報」を送信する
構成を備えない部分が相違するところ、アプリ管理サーバから現実的に配車
15 候補となる車両を「タクシー情報」としてユーザ端末に通知することは、本
件発明の本質的部分であるから、「タクシー選択範囲情報」を送信する構成
を備えないことは、本件発明の本質的部分にわたる相違であり、均等侵害の
第１要件を充足しない。」を加える。
(21) 原判決１５頁１９行目末尾に「「乗車完了情報」をユーザ端末から通知す
20 るか、乗務員端末から通知するかは、単なる設計事項にすぎず、本件発明の
作用効果に影響を及ぼすものではないのであって、本件発明の本質的部分に
わたる相違とはいえない。」を加える。
(22) 原判決１５頁２６行目末尾に「ユーザ端末から「乗車完了情報」を通知す
ることは、配車決定をしたユーザの意思が実現されたことを通知するもので
25 あるから、これは本件発明の本質的部分である。」を加える。
(23) 原判決１６頁１２行目の「本件発明の効果等に鑑みれば」を「本件特許は、
タクシー事業者間の実質的な公平性の確保という社会的、法的要請を技術的
に解決するもので、その貢献度は極めて大きいことに照らすと」に改める。
第３ 当審における当事者の追加主張
１ 「タクシー事業者端末」（構成要件Ｅ１）について（文言侵害の成否）
5 （原告らの主張）
本件明細書には、「タクシー事業者端末」は「タクシー事業者の管理下に置
かれるコンピュータである」と明記されているのであり（【００１７】）、被
告が端末を提供していないとしても、タクシー事業者が自身の端末からシステ
ムにアクセスすることにより「結果情報」を確認し得るのであれば、構成要件
10 Ｅ１の「タクシー事業者端末」を充足するというべきである。そして、被告の
提供する「管理画面の閲覧サービス」は、タクシー事業者が自身の端末からア
クセスし、配車関連情報を確認するためのものであり、タクシー事業者端末が
果たすべき機能を実質的に実現しているのであるから、被告製品は、構成要件
Ｅ１を充足する。
15 （被告の主張）
否認ないし争う。被告製品において、タクシー事業者向けの端末は提供して
いない。
２ 「乗車完了情報」（構成要件Ｄ２）について（均等侵害の成否）
（原告らの主張）
20 ⑴ 「乗車完了情報」がユーザ端末から送信される構成は、本件発明の本質的
部分ではなく、均等侵害の第１要件を充足する。
⑵ 「乗車完了情報」をユーザ端末から送信する構成を、乗務員アプリ（乗務
員端末）から送信する構成に置き換えても、本件発明の作用効果は同一であ
るから、均等侵害の第２要件を充足し、上記のように置き換えることは、当
25 業者において極めて容易に想到することができたから、均等侵害の第３要件
を充足する。
⑶ 被告製品の構成は、本件特許の出願時における公知技術から推考できたも
のでないから、均等侵害の第４要件を充足し、本件特許の出願手続において、
特許請求の範囲から意識的に除外されたものに当たるなどの特段の事情は存
在しないから、均等侵害の第５要件を充足する。
5 （被告の主張）
否認ないし争う。ユーザ端末から「乗車完了情報」を通知することは、配車
決定をしたユーザの意思が実現されたことを通知するものであるから、これは、
本件発明の本質的部分である。
３ 「タクシー選択範囲情報」（構成要件Ｄ３）について（均等侵害の成否）
10 （原告らの主張）
⑴ 「タクシー選択範囲情報」が、「距離的範囲を設定する情報」か、あるい
は「時間的範囲を設定する情報」かは、本件発明の本質的部分ではなく、均
等侵害の第１要件を充足する。
⑵ 「タクシー選択範囲情報」を「距離的範囲を設定する情報」から「時間的
15 範囲を設定する情報」に置き換えても、本件発明の作用効果は同一であるか
ら、均等侵害の第２要件を充足し、上記のように置き換えることは、当業者
において極めて容易に想到することができたから、均等侵害の第３要件を充
足する。
⑶ 被告製品の構成は、本件特許の出願時における公知技術から推考できたも
20 のでないから、均等侵害の第４要件を充足し、本件特許の出願手続において、
特許請求の範囲から意識的に除外されたものに当たるなどの特段の事情は存
在しないから、均等侵害の第５要件を充足する。
（被告の主張）
否認ないし争う。
25 ４ 「結果情報データベースを備える」（構成要件Ｅ２）について（均等侵害の
成否）
（原告らの主張）
⑴ 「結果情報データベース」の物理的な所在が、タクシー事業者端末か、あ
るいは被告の管理する中央サーバかは、本件発明の本質的部分ではなく、均
等侵害の第１要件を充足する。
5 ⑵ 「結果情報データベース」の物理的な所在を、タクシー事業者端末から被
告の管理する中央サーバに置き換えても、本件発明の作用効果は同一である
から、均等侵害の第２要件を充足し、上記のように置き換えることは、当業
者において極めて容易に想到することができたから、均等侵害の第３要件を
充足する。
10 ⑶ 被告製品の構成は、本件特許の出願時における公知技術から推考できたも
のでないから、均等侵害の第４要件を充足し、本件特許の出願手続において、
特許請求の範囲から意識的に除外されたものに当たるなどの特段の事情は存
在しないから、均等侵害の第５要件を充足する。
（被告の主張）
15 否認ないし争う。本件発明と被告製品の相違点は、① 被告製品は「タクシ
ー事業者端末」を備えるものではないこと、② 仮に被告製品の「事業者向け
アプリ」が「タクシー事業者端末」に相当するとしても、配車依頼の情報は閲
覧対象ではなく、いずれにせよ「配車確認要求」を登録する「結果情報データ
ベース」を備えないことである。そして、「ユーザの決定情報が車両端末、タ
20 クシー事業者端末及びアプリ運営主体の端末に届き、アプリ運営主体と加盟事
業者とが同じ情報を取得して、情報の公平性・透明性を保ち、適切な費用請求
が可能となる」（【０００７】）という本件特許の目的に照らすと、タクシー
事業者端末に、ユーザの決定情報である「配車確認要求」を登録する「結果情
報データベース」を備えることは不可欠の構成であり、本件発明の本質的部分
25 である。
第４ 当裁判所の判断
１ 当裁判所も、原告らの請求に理由はなく、本件各控訴はいずれも棄却すべき
ものと判断する。その理由は、次のとおり補正ないし補充し、２のとおり、当
審における当事者の追加主張に対する判断を付加するほかは、原判決の「事実
及び理由」欄の「第４ 判断」の２から６まで（原判決１７頁１０行目から２
5 ６頁４行目まで）に記載のとおりであるから、これを引用する。
⑴ 原判決１７頁１１行目の「本件明細書には、次の記載がある。」を「本件
明細書の記載は原判決別紙「特許公報」のとおりであり、これには次の記載
がある。」に改める。
⑵ 原判決１９頁２３行目の「タクシーの配車管理システムにおいて、」の次
10 に「タクシーの選択肢が少なく、ユーザの希望を満足し得るように迅速かつ
能率良くタクシーを配車することが困難であったこと、」を加える。
⑶ 原判決２０頁１９行目から２３行目までを次のとおり改める。
「 原告らは、① 構成要件Ｂ２の「タクシー選択範囲情報」は、距離的
範囲を設定する情報に限定されるものではなく、タクシーの到着時間という
15 時間的範囲を設定する情報も含まれる、② 構成要件Ｂ３の「タクシー情報」
の意義は「輸送（車両又は会社）サービス項目一覧情報」である旨の主張を
する。」
⑷ 原判決２０頁２５目から２１頁１７行目までを次のとおり改める。
「ア 「タクシー選択範囲情報」（構成要件Ｂ２、Ｄ３）及び「タクシー情報」
20 （構成要件Ｂ３、Ｂ４、Ｄ３）の意義
「タクシー」は、「営業用自動車」（乙１１、１９）、「自動車運送事
業」（甲３０、３１、４４、４５）等の意味を有する多義的な語であり、
特許請求の範囲の記載のみから「タクシー選択範囲情報」及び「タクシー
情報」の意義が一義的に定まるものではないものの、本件明細書に、「ユ
25 ーザ端末…の配車アプリが起動されると、その端末画面には、…配車アプ
リの表示に続いて、タクシー選択範囲情報として、現在地より半径５００
ｍ以内、８００ｍ以内、１２００ｍ以内、１５００ｍ以内の表示がされる。
半径範囲が拡大すれば呼べるタクシー車両の数が増え、選択肢は増える。」
（【００１８】）、「ユーザ端末…操作により、いずれかの範囲を選択す
ると、…アプリ管理サーバ…は常時登録保有している移動端末情報の中か
5 ら自動で選択範囲内の配車可能なタクシーを全て選択し、タクシー情報結
果をユーザ端末…に通知する。」（【００１９】）と、配車手順につき
「ユーザ端末…から依頼地入力と範囲５００ｍでのタクシー選出依頼を行
う…。…上記の選出依頼に応答して、アプリ管理サーバ…のシステム制御
機…は、移動端末情報データベース…に車両の位置情報確認要求をし、そ
10 の結果を貰い、情報結果…をユーザ端末…に通知する…。情報結果とは、
ユーザ希望の範囲に存在するタクシー情報であり、この情報には、タクシ
ー事業者名、料金、車種等が含まれる。」（【００２８】）、「ユーザ端
末…から依頼地入力と範囲８００ｍでのタクシー選出依頼を行う…。する
と、…アプリ管理サーバ…は情報結果（車両１、２、４、５）をユーザ端
15 末…に通知する。」（【００２９】）、「迎車否を受信したユーザは、ユ
ーザ端末…から依頼地入力と範囲１０００ｍでのタクシー選出依頼を行う。
すると、…アプリ管理サーバ…は情報結果（車両１、２、３、４、５、６）
をユーザ端末…に通知する。」（【００３１】）と記載され、さらに、配
車アプリによる配車依頼時のユーザ端末の画面に、ユーザが選択した距離
20 範囲内に存在するタクシー車両の情報が表示される構成（【図２】）も示
されていて、現在地（タクシー迎車依頼地）からの半径範囲が拡大するほ
ど、配車可能なタクシー車両の数が増え、ユーザの選択肢が増えることが
技術的思想として開示されていることを考慮すると、「タクシー選択範囲
情報」の意義は、ユーザがタクシー車両を選択するための「タクシー迎車
25 依頼地からの距離的範囲を設定する情報」と、また「タクシー情報」の意
義は、「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシ
ー車両の情報」と解釈するのが相当である。
原告らは、本件明細書の「現在地より半径５００ｍ以内」等の記載は実
施例の一つにすぎず、「タクシー選択範囲情報」には時間的範囲を設定す
る情報も含まれると解することが、本件特許の目的や本件発明の核心的構
5 成に沿う、構成要件Ｄ３において、ユーザ端末からタクシー迎車依頼地情
報とタクシー選択範囲情報を受信したアプリ管理サーバが、移動端末情報
データベースを確認してユーザ希望の範囲に存在する「タクシー情報」を
作成しユーザ端末に通知する構成が開示されていることなどからすると、
「タクシー情報」の意義は、上位概念である「輸送（車両又は会社）サー
10 ビス項目一覧情報」と解釈すべきである旨の主張をするが、前記のとおり、
本件明細書の記載を考慮すると、「タクシー選択範囲情報」の意義は「タ
クシー迎車依頼地からの距離的範囲を設定する情報」と、「タクシー情報」
の意義は「ユーザが選択した距離範囲内に存在する配車可能な全てのタク
シー車両の情報」とそれぞれ解釈するのが相当であり、原告らの主張は採
15 用できない。
イ 「配車確認要求」（構成要件Ｂ４、Ｃ３、Ｄ２、Ｅ２）の意義
構成要件Ｂ４において、「配車確認要求」は「タクシー情報の中からユ
ーザが希望するタクシーを指定した」ものであることが特定されている。
そして、前記のとおり、「タクシー情報」は「ユーザが選択した距離範囲
20 内に存在する配車可能な全てのタクシー車両の情報」と解釈するのが相当
であることに加え、本件明細書に、「ユーザは、ユーザ端末…の画面に表
示された受信情報結果を見て、気に入ったタクシーがあれば、それを選択
すると、…その情報すなわち、配車確認要求は、アプリ管理サーバ…、該
当するタクシー移動端末…、及びタクシー事業者端末…に同報送信され
25 る。」（【００２０】）と記載され、配車手順につき「いま、ユーザが車
両２を気に入ったとして、それを指定した配車確認要求をユーザ端末…よ
り送信する…。この配車確認要求は、車両２のタクシー移動端末…、アプ
リ管理サーバ…及びタクシー事業者端末…に同報送信される。ここで、車
両２の乗務員が何らかの都合で、迎車否を送信したとする…。この情報は、
ユーザ端末…、アプリ管理サーバ…及びタクシー事業者端末…に同報送信
5 される。」（【００３０】）などと記載されていることを考慮すると、
「配車確認要求」の意義は「ユーザが選択した選択範囲内に存在する全て
のタクシー車両を示す情報の中から、ユーザの希望するタクシー車両を指
定して行う迎車の可否の確認要求」と解釈するのが相当である。
原告らは、本件特許の目的を実現するためには、ユーザがそのニーズ
10 （距離的範囲、時間的範囲）に合致した的確な「配車確認要求」を行う必
要性があることからすると、「配車確認要求」の意義は「ユーザによる特
定の輸送サービスを利用する旨の確定情報」と解釈すべきである旨の主張
をする。
しかしながら、原告らの主張は、「タクシー選択範囲情報」には時間的
15 範囲を設定する情報も含まれる、「タクシー情報」の意義は「輸送（車両
又は会社）サービス項目一覧情報」であるとの解釈を前提とするものであ
るところ、かかる解釈を採用できないことは、前記のとおりであるから、
その前提において失当である。
ウ 「共有し得るように通知し」（構成要件Ｂ４、Ｂ６、Ｃ３）の意義
20 構成要件Ｂ４は、ユーザ端末から配車確認要求をタクシー移動端末、ア
プリ管理サーバ及びタクシー事業者端末に「共有し得るように通知」する
構成を、構成要件Ｂ６は、ユーザ端末から乗車完了情報をアプリ管理サー
バ及びタクシー事業者端末に「共有し得るように通知」する構成を、構成
要件Ｃ３は、タクシー移動端末から迎車可否情報をユーザ端末、アプリ管
25 理サーバ及びタクシー移動端末に「共有し得るように通知」する構成をそ
れぞれ特定する。
また、本件明細書には、「ユーザは、ユーザ端末…の画面に表示された
受信情報結果を見て、気に入ったタクシーがあれば、それを選択すると、
…その情報すなわち、配車確認要求は、アプリ管理サーバ…、該当するタ
クシー移動端末…、及びタクシー事業者端末…に同報送信される。」
5 （【００２０】）、「ユーザの位置に当該タクシーが到着し、ユーザがそ
のタクシーに乗車したとき、ユーザ端末…から乗車完了情報をアプリ管理
サーバ…及びタクシー事業者端末…に通知、つまり、同報送信する。」
（【００２１】）、「ユーザはユーザ端末…にて希望するタクシーを指定
し、配車依頼の情報を送信する。この情報は、タクシー移動端末…等、ア
10 プリ管理サーバ…及びタクシー事業者端末…に同報送信される…。」、
「該当のタクシー移動端末のタクシー乗務員はナビゲーションシステムを
利用しユーザ端末…の依頼地へ進行する。タクシーがユーザの依頼地に到
着し、ユーザが乗車したなら、ユーザはユーザ端末…により乗車完了情報
を送信する。この情報は、アプリ管理サーバ…及びタクシー事業者端末…
15 に同報送信される…。」（【００２５】）と記載され、配車手順につき
「いま、ユーザが車両２を気に入ったとして、それを指定した配車確認要
求をユーザ端末…より送信する…。この配車確認要求は、車両２のタクシ
ー移動端末…、アプリ管理サーバ…及びタクシー事業者端末…に同報送信
される。ここで、車両２の乗務員が何らかの都合で、迎車否を送信したと
20 する…。この情報は、ユーザ端末…、アプリ管理サーバ…及びタクシー事
業者端末…に同報送信される。」（【００３０】）、「いま、ユーザが車
両６を気に入ったとして、それを指定した配車確認要求をユーザ端末…よ
り送信する。この配車確認要求は、車両６のタクシー移動端末…、アプリ
管理サーバ…及びタクシー事業者端末…に同報送信される。ここで、車両
25 ６の乗務員が迎車可を送信したなら、配車決定となり、その情報はユーザ
端末…、アプリ管理サーバ…及びタクシー事業者端末…に自動的に同報送
信される。それを受けたアプリ管理サーバ…は、ユーザ情報データベース
…を参照してユーザ位置情報を車両６のタクシー移動端末…に自動送信す
る…。」（【００３２】）、「ユーザは、タクシーに乗車したとき、ユー
ザ端末…より乗車完了の情報をアプリ管理サーバ…及びタクシー事業者端
5 末…に同報送信する…。」（【００３３】）などと記載されていて、同一
の情報が複数の送信先に「同報送信」する構成が開示されている。
そして、「同報送信」とは「同じ内容の知らせを複数の相手に送ること」
の意味を有すること（乙１３）に加え、本件明細書の上記の各記載を考慮
すると、「共有し得るように通知し」の意義は「複数の送信先に同じ内容
10 の情報を送信して通知すること」と解釈するのが相当である。
原告らは、本件発明の本質に照らすと、「共有し得るように通知し」の
意義は、複数の者がアクセスにより情報を確認することができるよう知ら
せることと解釈すべき旨の主張をする。
しかしながら、構成要件Ｂ４、Ｂ６、Ｃ３において、ユーザ端末（構成
15 要件Ｂ４、Ｂ６）ないしタクシー移動端末（構成要件Ｃ３）から同じ情報
を複数の送信先に「共有し得るように通知」する構成が特定され、本件明
細書においても、同一の情報が複数の送信先に「同報送信」される構成が
開示されていることは前記のとおりであって、原告らの主張を採用するの
は困難である。
20 原告らは、特許出願手続において、本件発明の技術的範囲を不当に限定
することなく、その本質を明瞭にするために請求項１及び２の「同報送信
し」を「共有し得るように通知し」に補正した旨の主張もするが、これに
より前記判断は左右されない。」
⑸ 原判決２１頁１９行目から２２頁１５行目までを次のとおり改める。
25 「 前記のとおり、構成要件Ｂ２の「タクシー選択範囲情報」の意義は、
「タクシー迎車依頼地からの距離的範囲を設定する情報」と解釈するのが相
当であるところ、被告製品は、原判決別紙「被告製品の構成」記載のとおり、
ユーザがユーザ端末の初期画面に存在する「今すぐ呼ぶ」ボタン又は「ＡＩ
予約」ボタンを選択することにより、ユーザの乗車日時をＧＯＡＰＩコアサ
ービスに送信する構成であり、「タクシー迎車依頼地からの距離的範囲を設
5 定する情報」を送信する構成ではないことから、そもそも構成要件Ｂ２を充
足しない。
また、前記のとおり、構成要件Ｂ３、Ｂ４の「タクシー情報」の意義は
「ユーザが選択した距離的範囲内に存在する配車可能な全てのタクシー車両
の情報」と、構成要件Ｂ４の「配車確認要求」の意義は「ユーザが選択した
10 選択範囲内に存在する全てのタクシー車両を示す情報の中から、ユーザの希
望するタクシー車両を指定して行う迎車の可否の確認要求」と、構成要件Ｂ
４の「共有し得るように通知し」の意義は「複数の送信先に同じ内容の情報
を送信して通知すること」とそれぞれ解釈するのが相当であるところ、被告
製品は、原判決別紙「被告製品の構成」記載のとおり、① ユーザ端末から
15 被告製品のシステムに登録されたタクシー会社等及び車両タイプの選択肢を
確認可能とし、ユーザが指定した条件での配車依頼がＧＯＡＰＩコアサービ
スに送信される構成（構成③）、② 配車依頼を受信したＧＯＡＰＩコアサ
ービスは、配車マッチングサービスに配車マッチングを依頼し、●省略●
（構成④）であり、ユーザが選択した距離的範囲内に存在する配車可能な全
20 てのタクシー車両の情報、すなわちタクシー情報を確認可能とする構成でも、
タクシー情報の中からユーザの希望するタクシー車両を指定して行う迎車の
可否の確認要求、すなわち配車確認要求を複数の送信先に送信して通知する
構成でもないことから、構成要件Ｂ３、Ｂ４を充足しない。」
⑹ 原判決２２頁１６行目の「⑸」を「⑷」に、２３頁１０行目の「⑹」を
25 「⑸」にそれぞれ改める。
⑺ 原判決２２頁２３行目から２３頁９行目までを次のとおり改める。
「 また、本件発明は、従来の「複数のタクシー会社の中から任意にタク
シー会社を選択できる複数のタクシー事業者対象のシステム」では、「一つ
のシステム上で複数のタクシー会社が稼働するものではなく、…結局は一社
の中での選択となり」、「タクシー選択肢が少なく、ユーザの希望を満足し
5 得るように迅速かつ能率良くタクシーを配車することは困難であった」
（【０００２】）こと、また、従来技術では、ユーザの意思で複数の車両を
指定し、その情報を配車管理装置に送信すると、その指定された車両の中か
ら配車管理装置が配車の可能可否確認を行い、その結果で配車車両を決定す
るため、実質、車両を決定するのはユーザではなく配車管理装置側となり、
10 公平性に難があること（【０００６】）から、ユーザ端末から、アプリ管理
サーバにタクシー迎車依頼地情報と「タクシー選択範囲情報」を送信し（構
成要件Ｂ２）、アプリ管理サーバからの「タクシー情報」を確認可能とし
（構成要件Ｂ３）、「タクシー情報」の中からユーザが希望するタクシーを
指定した「配車確認要求」をタクシー移動端末、アプリ管理サーバ及びタク
15 シー事業者端末に共有し得るように通知し（構成要件Ｂ４）、タクシー移動
端末からの迎車可否情報を確認可能（構成要件Ｂ５）とする構成を採用する
ことにより、タクシー車両の選択肢を増やすとともに、「ユーザ端末…つま
りユーザが常に情報の送受信の中心にいて、ユーザの意思で配車を決定する
ことができる」（【００３４】）ようにしたのであり、そうすると、ユーザ
20 端末から、「ユーザが選択した距離範囲内に存在する配車可能な全てのタク
シー車両の情報」である「タクシー情報」を確認可能とし、「タクシー情報」
の中からユーザが希望するタクシーを指定した「配車確認要求」をタクシー
移動端末、アプリ管理サーバ及びタクシー事業者端末に「共有し得るように
通知」する構成は、従来技術に見られない本件発明の本質的部分というべき
25 である。
したがって、① ユーザ端末から被告製品のシステムに登録されたタクシ
ー会社等及び車両タイプの選択肢を確認可能とし、ユーザが指定した条件で
の配車依頼がＧＯＡＰＩコアサービスに送信される構成（構成③）、② 配
車依頼を受信したＧＯＡＰＩコアサービスは、配車マッチングサービスに配
車マッチングを依頼し、●省略●（構成④）である被告製品は、本件発明の
5 本質的部分において相違するというべきであるから、均等侵害の第１要件を
充足しない。」
⑻ 原判決２３頁１３行目から２４頁３行目までを次のとおり改める。
「 構成要件Ｃ３は、ユーザ端末からの「配車確認要求」に応答して「迎
車可否情報」をユーザ端末、アプリ管理サーバ及びタクシー事業者端末に
10 「共有し得るように通知」する構成を特定するところ、「配車確認要求」の
意義は「ユーザが選択した選択範囲内に存在する全てのタクシー車両を示す
情報の中から、ユーザの希望するタクシー車両を指定して行う迎車の可否の
確認要求」と、「共有し得るように通知し」の意義は「複数の送信先に同じ
内容の情報を送信して通知すること」とそれぞれ解釈するのが相当であるこ
15 と、被告製品が、「配車確認要求」に応答して「迎車可否情報」を「共有し
得るように通知」する構成を備えないことは、前記のとおりであるから、
「迎車可否情報」の意義にかかわらず、被告製品は、構成要件Ｃ３を充足し
ない。」
⑼ 原判決２４頁９行目から１４行目までを次のとおり改める。
20 「 そして、構成要件Ｂ４の「配車確認要求」の意義は「ユーザが選択し
た選択範囲内に存在する全てのタクシー車両を示す情報の中から、ユーザの
希望するタクシー車両を指定して行う迎車の可否の確認要求」と解釈するの
が相当であるところ、被告製品は「配車確認要求」に相当する構成を備える
ものではなく、したがって、「配車確認要求」に応答する「迎車可否情報」
25 に相当する構成を備えるものでないことは、前記のとおりであるから、被告
製品が、ユーザ端末からの「配車確認要求」や、タクシー移動端末からの
「迎車可否情報」を登録する「結果情報データベース」を備えているとはい
えない。」
⑽ 原判決２５頁２行目から５行目までを次のとおり改める。
「 前記のとおり、被告製品は、「配車確認要求」に相当する構成や、
5 「配車確認要求」に応答する「迎車可否情報」に相当する構成を備えるもの
でなく、したがって、これらの情報を登録する「結果情報データベース」を
備えているとはいえない。」
⑾ 原判決２６頁３行目末尾を改行の上、次のとおり加える。
「 原告らは、構成要件Ｅ２の「結果情報データベースを備える」には、プ
10 ッシュ型送信による情報取得のみならず、プル型通知による情報取得も含ま
れる旨の主張もするが、採用できない。」
２ 当審における当事者の追加主張に対する判断
⑴ 「タクシー事業者端末」（構成要件Ｅ１）について（文言侵害の成否）
被告製品は、●省略●（構成⑪）、●省略●（構成⑫）であるから、構成
15 要件Ｅ１を充足する。被告は、被告製品において、タクシー事業者向けの端
末は提供していない旨の主張をするが、被告製品が上記構成であることに照
らすと、採用できない。
⑵ 「乗車完了情報」（構成要件Ｄ２）について（均等侵害の成否）
原告らは、「乗車完了情報」がユーザ端末から送信される構成は、本件発
20 明の本質的部分ではなく、構成要件Ｄ２について均等侵害が成立する旨の主
張をする。
しかしながら、構成要件Ｄ２の構成中、被告製品と異なる部分は「乗車完
了情報」の送信主体にとどまるものではない。被告製品が、「配車確認要求」
に相当する構成や、「配車確認要求」に応答する「迎車可否情報」に相当す
25 る構成、そして、これらの情報を登録する「結果情報データベースとを備え」
る構成を備えるものでないことは、前記のとおりであって、いずれにせよ、
構成要件Ｄ２につき均等侵害は成立しない。
⑶ 「タクシー選択範囲情報」（構成要件Ｄ３）について（均等侵害の成否）
原告らは、「タクシー選択範囲情報」が「距離的範囲を設定する情報」
か、「時間的範囲を設定する情報」かは、本件発明の本質的部分ではなく、
5 「タクシー選択範囲情報」を「距離的範囲を設定する情報」から「時間的範
囲を設定する情報」に置き換えても、本件発明の作用効果は同一である上、
上記のように置き換えることは、当業者において極めて容易に想到すること
ができた旨の主張をする。
しかしながら、前記のとおり、「タクシー選択範囲情報」が「距離的範囲
10 を設定する情報」であることは、本件発明の本質的部分というべきであるか
ら、被告製品は、均等侵害の第１要件を充足せず、構成要件Ｄ３について均
等侵害は成立しない。
⑷ 「結果情報データベースを備えている」（構成要件Ｅ２）について（均等
侵害の成否）
15 原告らは、構成要件Ｅ２の「結果情報データベース」の物理的な所在が、
タクシー事業者端末か、被告の管理する中央サーバかは、本件発明の本質的
部分ではなく、その物理的な所在を、タクシー事業者端末から被告の管理す
る中央サーバに置き換えても、本件発明の作用効果は同一である上、上記の
ように置き換えることは、当業者において極めて容易に想到することができ
20 た旨の主張をする。
しかしながら、構成要件Ｅ２の構成中、被告製品が、「配車確認要求」に
相当する構成や、「配車確認要求」に応答する「迎車可否情報」に相当する
構成、そして、これらの情報を登録する「結果情報データベースを備える」
構成を備えるものでないことは、前記のとおりであって、「結果情報データ
25 ベース」の物理的な所在にかかわらず、構成要件Ｅ２につき均等侵害は成立
しない。
第５ 結論
以上によれば、被告製品は、少なくとも、構成要件Ｂ３、Ｂ４、Ｃ３、Ｄ２、
Ｄ３及びＥ２を充足せず、加えて、構成要件Ｂ３、Ｂ４、Ｄ２、Ｄ３及びＥ２
について均等侵害も成立しないから、その余の点について検討するまでもなく、
5 原告らの請求はいずれも理由がない。
よって、原判決は相当であるから、本件各控訴をいずれも棄却することとして、
主文のとおり判決する。
知的財産高等裁判所第２部
裁判長裁判官
森 冨 義 明

裁判官
菊 池 絵 理

裁判官
頼 晋 一

（別紙）
当事者目録
控 訴 人 Ｘ
控 訴 人 ベ ス ト 交 通 株 式 会 社
上記両名訴訟代理人弁護士 岩 﨑 博 之
同 澤 田 昌 孝
10 同 福 田 俊 介
同 中 森 真 史
同 谷 垣 友
同 佐 藤 和 樹
同 髙 木 良 輔
15 同訴訟代理人弁理士 板 谷 康 夫
被 控 訴 人 Ｇ Ｏ 株 式 会 社
同訴訟代理人弁護士 杉 村 光 嗣
20 同 岡 本 岳
同 田 邉 実
同 深 津 拓 寛
同 時 井 真
同 髙 橋 恵 美
25 同 奥 結 美 子
同補佐人弁理士 齋 藤 恭 一
同 橋 本 大 佑
以上