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