令和７年９月２５日判決言渡同日原本受領裁判所書記官令和６年（ワ）第６２１６号損害賠償請求事件口頭弁論終結日令和７年７月１４日判決 原告 Ａ （以下「原告Ａ」という。） 原告 ベスト交通株式会社 （以下「原告会社」という。） 代表者代表取締役 訴訟代理人弁護士岩崎博之 同 澤田昌孝 同 福田俊介 同 中森真史 同 谷垣友 同 佐藤和樹 同 清原直己 訴訟代理人弁理士板谷康夫 被告 ＧＯ株式会社 代表者代表取締役 訴訟代理人弁護士杉村光嗣 同 岡本岳 同 深津拓寛 同 田邉実 同 草留夕雅 同 奥結美子 同 時井真 補佐人弁理士齋藤恭一 主文 １ 原告らの請求をいずれも棄却する。 ２ 訴訟費用は原告らの負担とする。 事実及び理由 第１ 請求 １ 被告は、原告会社に対し、２５億８９００万１３６８円及びこれに対する令和６年７月１１日から支払済みまで年３パーセントの割合による金員を支払え。 ２ 被告は、原告Ａに対し、１億９４２９万１３８２円及びこれに対する令和６年７月１１日から支払済みまで年３パーセントの割合による金員を支払え。 第２ 事案の概要 １ 本判決における呼称 (1) 本件特許（ に対し、１億９４２９万１３８２円及びこれに対する令和６年７月１１日から支払済みまで年３パーセントの割合による金員を支払え。 第２ 事案の概要 １ 本判決における呼称 (1) 本件特許（権）：特許第６５４６５６２号に係る特許（権）(2) 本件明細書：本件特許権にかかる明細書及び図面。本件明細書の内容は、別紙特許公報記載のとおり。なお、本件明細書中の段落は【（４桁の数字）】として示す。 (3) 本件発明：本件特許の特許請求の範囲請求項１の発明 (4) 被告アプリ：「ＧＯ」との名称のスマートフォン向けタクシー配車アプリケーション(5) 被告製品：被告アプリを用いてタクシー配車を行う別紙「被告製品の構成」記載の構成を備えるシステム(6) 第１要件（等）：最高裁平成６年（オ）第１０８３号同１０年２月２４日第 三小法廷判決・民集５２巻１号１１３頁において判示された、均等侵害が成立 するための各要件（第１要件：非本質的部分、第２要件：置換可能性、第３要件：置換容易性、第４要件：容易推考性、第５要件：意識的除外） ２ 原告の請求（訴訟物）原告会社が、令和５年１１月２１日まで本件特許権を有していたこと、原告Ａが、同日、本件特許権を原告会社から譲り受けたこと、被告が遅くとも令和４年 ６月から被告製品を使用しており、これが同特許権を侵害するものであることを前提とする、(1) 原告会社の被告に対する、不法行為（民法７０９条）に基づく２５億８９００万１３６８円の損害賠償請求(2) 原告Ａの被告に対する、不法行為（民法７０９条）に基づく１億９４２９万 １３８２円の損害賠償請求(3) (1)及び(2)に対する不法行為の後日である令和６年７月１１日から支払済みまで民法所定の年３パーセントの割合による （民法７０９条）に基づく１億９４２９万 １３８２円の損害賠償請求(3) (1)及び(2)に対する不法行為の後日である令和６年７月１１日から支払済みまで民法所定の年３パーセントの割合による遅延損害金の請求 ３ 前提事実（証拠については枝番を含む。以下同じ）(1) 当事者 ア原告Ａは、本件特許権を有している。 イ原告会社は、一般乗用旅客自動車の運送事業等を目的とする株式会社である。原告会社は、保有していた本件特許権を、令和５年１１月２１日、原告Ａに譲渡した（甲６、７）。 ウ被告は、インターネットを利用したサービス、システム及びアプリケーシ ョン企画、開発、運用、導入に関するコンサルティング及び保守サービス業務、車載システムの企画、開発、販売、導入に関するコンサルティング及び保守サービス業務等を目的とする株式会社である。 (2) 本件特許権の書誌的事項（甲３）本件特許権の書誌的事項は、次のとおりである。 ア特許番号：特許第６５４６５６２号 イ出願日：平成２８年５月９日ウ登録日：令和元年６月２８日エ発明の名称：タクシー配車管理システム、タクシー配車管理装置、及び、タクシー配車管理プログラム(3) 本件発明の構成要件の分説 本件発明の構成要件は、以下のとおり分説される。 Ａ ネットワークにそれぞれ接続可能な、ユーザ端末と、タクシー移動端末と、アプリ管理サーバと、タクシー事業者端末と、を備え、Ｂ１ 前記ユーザ端末は、Ｂ２ ユーザ操作によりその端末にインストールしたアプリを起動し、ネット ワークを介してアプリ管理サーバにアクセスし、タクシー迎車依頼地情報とタクシー選択範囲情報を送信し、Ｂ３ 前記アプリ管理サーバからのタクシー情報を確認可能とし、Ｂ プリを起動し、ネット ワークを介してアプリ管理サーバにアクセスし、タクシー迎車依頼地情報とタクシー選択範囲情報を送信し、Ｂ３ 前記アプリ管理サーバからのタクシー情報を確認可能とし、Ｂ４ 前記タクシー情報の中からユーザが希望するタクシーを指定した配車確認要求を前記タクシー移動端末、前記アプリ管理サーバ及び前記タクシー 事業者端末に共有し得るように通知し、Ｂ５ 前記タクシー移動端末からの迎車可否情報を確認可能とし、Ｂ６ ユーザがタクシーへ乗車完了したとき乗車完了情報を前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知し、Ｃ１ 前記タクシー移動端末は、 Ｃ２ その端末にインストールしたアプリを起動し、ネットワークを介して前記アプリ管理サーバにアクセスし、かつＧＰＳ機能を用いてポーリングによる位置情報を取得し、その位置情報を前記アプリ管理サーバに送信し、Ｃ３ 前記ユーザ端末からの前記配車確認要求に応答して前記迎車可否情報を前記ユーザ端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共 有し得るように通知し、 Ｄ１ 前記アプリ管理サーバは、Ｄ２ 前記ユーザ端末から送信されたユーザ情報を登録するユーザ情報データベースと、前記タクシー移動端末から送信されたポーリング情報を受信して登録する移動端末情報データベースと、前記ユーザ端末からの前記配車確認要求、前記乗車完了情報、及び前記タクシー移動端末からの前記迎車可否 情報を登録する結果情報データベースとを備え、Ｄ３ 前記ユーザ端末から前記タクシー迎車依頼地情報と前記タクシー選択範囲情報を受信したとき、前記移動端末情報データベースを確認してユーザ希望の範囲に存在する前記タクシー情報を前記ユーザ端末に通知し、Ｄ４ 前 ザ端末から前記タクシー迎車依頼地情報と前記タクシー選択範囲情報を受信したとき、前記移動端末情報データベースを確認してユーザ希望の範囲に存在する前記タクシー情報を前記ユーザ端末に通知し、Ｄ４ 前記タクシー移動端末から迎車可の情報を受信したとき、ユーザの前記 タクシー迎車依頼地情報を前記タクシー移動端末に通知し、Ｅ１ 前記タクシー事業者端末は、Ｅ２ 前記ユーザ端末からの前記配車確認要求、前記乗車完了情報、及び前記タクシー移動端末からの前記迎車可否情報を登録する結果情報データベースを備える、 Ｆ タクシー配車管理システム。 (4) 被告製品の構成被告製品は、別紙「被告製品の構成」に記載の構成を備えている（なお、各構成をその冒頭の番号で「構成①」などという。）。 (5) 原告らが非充足を争わない構成要件 原告らは、被告製品が構成要件Ｂ６の構成を備えないことを争わない。 ４ 争点（文言侵害について）(1) 被告製品が構成要件Ｂ２を充足するか（争点１）(2) 被告製品が構成要件Ｂ３及びＢ４を充足するか（争点２） (3) 被告製品が構成要件Ｂ５を充足するか（争点３） (4) 被告製品が構成要件Ｃ２を充足するか（争点４）(5) 被告製品が構成要件Ｃ３を充足するか（争点５）(6) 被告製品が構成要件Ｄ２を充足するか（争点６）(7) 被告製品が構成要件Ｄ３を充足するか（争点７）(8) 被告製品が構成要件Ｄ４を充足するか（争点８） (9) 被告製品が構成要件Ｅ２を充足するか（争点９）（均等侵害について）(10) 「タクシー選択範囲情報」（構成要件Ｂ２）が現在地からの距離的範囲をいうものと解される場合に、これを「タクシー到着までの時間的情報」に置換した構成について、均等 （均等侵害について）(10) 「タクシー選択範囲情報」（構成要件Ｂ２）が現在地からの距離的範囲をいうものと解される場合に、これを「タクシー到着までの時間的情報」に置換した構成について、均等侵害が成立するか（争点１０） (11) 「タクシー」（構成要件Ｂ４のもの）を「タクシー会社及び車種などの条件」に、「タクシー情報」（構成要件Ｂ３、Ｂ４のもの）を「タクシー会社及び車種などの条件の情報」に置換した構成について、均等侵害が成立するか（争点１１）(12) 「ユーザ端末」が、「「乗車完了情報をアプリ管理サーバ及びタクシー事業 者端末に共有し得るように通知」する構成（構成要件Ｂ６）において、「ユーザ端末」を「タクシー移動端末」に置換した構成について、均等侵害が成立するか（争点１２）(13) 原告らの被った損害額（争点１３）第３ 争点に関する当事者の主張 １ 争点１（被告製品が構成要件Ｂ２を充足するか）について【原告らの主張】被告アプリがインストールされたユーザ端末において、アプリを起動すると、初期画面が表示され、画面左下に「今すぐ呼ぶ」ボタンまたはその右横に「ＡＩ予約」ボタンが配置されている。 このように、「今すぐ呼ぶ」又は「ＡＩ予約」のボタンを選択すること、及び ＡＩ予約において具体的な時刻を指定することは、ユーザの意思で管理サーバに対し、ユーザが乗車する車両を決定するための範囲（指定時刻に到着可能な範囲に存在する車両）、つまり「タクシー選択範囲情報」を送信しているといえる。 したがって、被告製品は構成要件Ｂ２を充足する。 【被告の主張】 本件明細書（【００１８】【００１９】【００２５】【００２８】【図２】【図６】）の記載によると、タクシー選択範囲情報とは、ユーザ端末を起 、被告製品は構成要件Ｂ２を充足する。 【被告の主張】 本件明細書（【００１８】【００１９】【００２５】【００２８】【図２】【図６】）の記載によると、タクシー選択範囲情報とは、ユーザ端末を起点とした所定半径の範囲で選択される範囲情報をいうものと解される。しかし、被告製品では、ユーザが被告アプリをインストールしたスマートフォン等を操作してこのような地理的範囲を限定することはない。 したがって、被告製品は構成要件Ｂ２を充足しない。 また、被告アプリでは、到着時刻を指定した予約が可能であるが、「タクシー選択範囲情報」が「タクシーが依頼地への到着に要する時間的範囲を設定する情報」を意味するというのは本件明細書に基づくものではない。 ２ 争点２（被告製品が構成要件Ｂ３、Ｂ４を充足するか）について 【原告らの主張】構成要件Ｂ４の、「タクシー情報の中からユーザが希望するタクシーを指定」する構成に関し、被告製品において「タクシー情報」はタクシー会社情報、車両タイプ等の情報がこれに相当する。構成③にあるとおり、ユーザは、「条件を選ぶ画面」において、「会社を選ぶ」からタクシー会社等を、「車両タイプを選ぶ」 から「スライドドア車両」等を選択し、「この会社を選ぶ」又は「決定する」ボタンを押すことで、タクシー会社と車両タイプ等を決定することができ、「ユーザが希望するタクシーを指定」するといえる。 「タクシーを指定した配車確認要求を（ユーザ端末から）タクシー移動端末及びタクシー事業者端末に共有すること」については、構成③にあるとおり、条件 を選ぶ画面において、条件を決定し、構成②の画面に戻り、「タクシーを呼ぶ」 ボタンを押すと、条件を選ぶ画面でユーザが指定した条件での配車依頼がＧＯＡＰＩコアサービスに送信されるか 件 を選ぶ画面において、条件を決定し、構成②の画面に戻り、「タクシーを呼ぶ」 ボタンを押すと、条件を選ぶ画面でユーザが指定した条件での配車依頼がＧＯＡＰＩコアサービスに送信されるから、タクシーを指定した配車確認要求を（ユーザ端末から）管理サーバに共有しているといえる。 したがって、被告製品は、構成要件Ｂ３、Ｂ４を充足する。 【被告の主張】 本件明細書（【００２８】）によれば、アプリ管理サーバがユーザ端末に送信する結果情報は車両１及び４つまり個別のタクシー車両の情報であることが明らかである。被告製品は、システム側でマッチングを行うものであり、ユーザがタクシーを指定することはできない。そのため、被告製品では、ユーザ端末から送信される「タクシーを指定した配車確認要求」は存在しない。 被告製品では、被告アプリを通じて配車依頼が送信されるが、送信された配車依頼が乗務員端末に共有されることはない。また、構成⑪のとおり、当該配車依頼は事業者向けアプリにおける閲覧対象ではなく、事業者向けアプリにも送信されない。 ３ 争点３（被告製品が構成要件Ｂ５を充足するか）について 【原告らの主張】被告製品において「ＧＯＡＰＩサーバが配車を確定した結果」が表示されるが、これは、タクシー端末がサーバからの配車承諾の依頼に対して了解（迎車可と）したことが前提となっているから、タクシー移動端末からの「迎車可否情報」といえる。 また、被告製品においては、配車が決定した場合には、ユーザアプリの画面に、「車両が手配できました」と表示され（構成⑥）、これは、ユーザが希望した配車が完了したこと（迎車が可能であること）を示すものであり、「迎車可否情報」に該当する。 したがって、被告製品は、構成要件Ｂ５を充足する。 表示され（構成⑥）、これは、ユーザが希望した配車が完了したこと（迎車が可能であること）を示すものであり、「迎車可否情報」に該当する。 したがって、被告製品は、構成要件Ｂ５を充足する。 【被告の主張】 被告製品においてユーザが確認できるのは、ＧＯＡＰＩサーバが配車を確定した結果であり、タクシー側で了解した又は拒否した情報をユーザ側で確認することはできない。 構成要件Ｂ５における「迎車可否情報」は少なくとも「前記タクシー移動端末から」発せられた情報であるところ、被告製品においては、乗務員アプリで配車 承諾した情報はＧＯＡＰＩサーバに送信されるのみであり、ユーザ端末でこれを確認することはできない。つまり、原告らの主張する上記画面の表示は「前記タクシー移動端末から」発せられた情報ではない。 したがって、被告製品は、構成要件Ｂ５を充足しない。 ４ 争点４（被告製品が構成要件Ｃ２を充足するか）について 【原告らの主張】動態連携サーバを含むすべてを含めたものが本件発明でいう管理サーバであり、分散したサーバ（車両動態収集、配信サービス）に乗務員端末の位置情報が送信されていれば、構成要件Ｃ２を充足する。 【被告の主張】 被告製品において、乗務員端末からＧＯＡＰＩサーバに乗務員端末の位置情報を送信することはない。被告製品では、位置情報を含むタクシーの動態情報はＧＯＡＰＩサーバとは別の動態連携サーバで収集している。 動態連携サーバで収集した動態情報は、配車マッチングサービス、到着時間予測（ＥＴＡ）サービス等の内部サービスに利用される（乙２の３ページ）が、Ｇ ＯＡＰＩサーバが乗務員端末からタクシーの位置情報を取得することはない。 したがって、被告製品は構成要件Ｃ２を充足しない。 ５ 争点５（被告製品 サービスに利用される（乙２の３ページ）が、Ｇ ＯＡＰＩサーバが乗務員端末からタクシーの位置情報を取得することはない。 したがって、被告製品は構成要件Ｃ２を充足しない。 ５ 争点５（被告製品が構成要件Ｃ３を充足するか）について【原告らの主張】ＧＯＡＰＩコアサービスから乗務員端末への配車確認依頼は、ユーザからＧＯ ＡＰＩサービスに対する配車依頼が起点となり、ユーザが配車依頼で指定した条 件に基づいてＧＯＡＰＩサービスがマッチング処理を経て配車承諾依頼を行い、乗務員端末はそれに応答している。 【被告の主張】被告製品では、「タクシーを指定した配車確認要求」は存在せず、また、ユーザの発した配車依頼が乗務員端末に共有されることもないので、乗務員端末がユ ーザの発した配車確認要求に応答することはない。また、乗務員端末では、ＧＯＡＰＩサーバから発せられる配車承諾依頼に応答することができるが、応答した情報はＧＯＡＰＩサーバに送信されるのみであり、乗務員端末からユーザのスマートフォン又はタクシー会社の管理画面に当該情報が共有されることはない。 被告製品では、乗務員アプリから発せられる配車承諾の情報はＧＯＡＰＩサー バに送信されるのみであり、被告アプリ及び事業者向けアプリに同時かつ直接に送信されるものではない。 ６ 争点６（被告製品が構成要件Ｄ２を充足するか）について【原告らの主張】ＧＯＡＰＩコアサービスだけでなく被告アプリを使用した配車システムを構 成する全てのサーバを一つのシステムとして構築している以上、これらすべてを含めたものが構成要件Ｄ１のアプリ管理サーバである。 「タクシーアプリ『ＧＯ』配車関連アーキテクチャ」（乙２）によれば、被告アプリは位置情報や配車条件をＧＯＡＰＩコアサービスに提供し これらすべてを含めたものが構成要件Ｄ１のアプリ管理サーバである。 「タクシーアプリ『ＧＯ』配車関連アーキテクチャ」（乙２）によれば、被告アプリは位置情報や配車条件をＧＯＡＰＩコアサービスに提供しており（ユーザ情報データベース）、タクシー移動端末からの動態情報は「車両動態収集、配信 サービス」に送られ（移動端末情報データベース）、ユーザアプリからの配車依頼や乗務員アプリからの配車承諾や配車状態情報は、ＧＯＡＰＩコアサービスに送信されており（結果情報データベース）、各データベースを備えているといえ、構成要件Ｄ２を充足している。 【被告の主張】 被告製品には、これらのデータベースを全て備えるサーバは存在しない。 ＧＯＡＰＩサーバは乗務員端末からタクシーの位置情報を取得することはない。また、ＧＯＡＰＩサーバは少なくともタクシーの動態情報を登録するデータベースを有しない。そのため、ＧＯＡＰＩサーバには、移動端末情報データベースは存在しない。さらに、ＧＯＡＰＩサーバは、ユーザからの配車依頼、乗務員端末から発せられた了解及びユーザの乗車が完了した旨の情報を蓄積しない。そ のため、ＧＯＡＰＩサーバには構成要件Ｄ２の結果情報データベースは存在しない。 ７ 争点７（被告製品が構成要件Ｄ３を充足するか）について【原告らの主張】被告製品は、ユーザ端末から乗車地を入力・確認することで「タクシー迎車依 頼地情報」を、構成①－１及び①－２記載のとおり、「今すぐ呼ぶ」又は「ＡＩ予約」のボタンを選択すること及びＡＩ予約において具体的な時刻を指定することで、ユーザが乗車する車両を決定するための範囲である「タクシー選択範囲情報」を、それぞれアプリ管理サーバに送信し、それによりアプリ管理サーバから、被告アプリの「条件を選ぶ画 体的な時刻を指定することで、ユーザが乗車する車両を決定するための範囲である「タクシー選択範囲情報」を、それぞれアプリ管理サーバに送信し、それによりアプリ管理サーバから、被告アプリの「条件を選ぶ画面」に、被告製品に登録されたタクシー会社等の選 択肢が表示される（構成③）。 したがって、構成要件Ｄ３を充足する。 【被告の主張】前記１の【被告の主張】のとおり、ユーザ希望の範囲とは、地理的なタクシー選択範囲情報を意味すると解されるが、被告製品ではユーザ端末からそのような タクシー選択範囲情報を送信しない。そのため、ＧＯＡＰＩサーバがタクシー選択範囲情報を受信することはない。 また、被告アプリにはマッチングの結果配車が確定した場合に配車確定情報が通知されるのみであり、ユーザが配車確定前に個々のタクシーの情報を確認することはできない。つまり、ＧＯＡＰＩサーバが被告アプリを介してユーザのスマ ートフォン等にユーザ希望の範囲に存在するタクシー情報を通知することはな い。 ８ 争点８（被告製品が構成要件Ｄ４を充足するか）について【原告らの主張】構成⑥にあるとおり、乗務員端末の配車承諾により、タクシーアプリの画面に乗車地情報が表示されるから、被告製品は、構成要件Ｄ４を充足する。 【被告の主張】乗務員端末から配車承諾依頼に対する了解の情報を受信することは、必要条件であっても十分条件ではない。すなわち、乗務員端末から了解の情報を受信したことを契機として乗務員端末に乗車地の情報を表示するものではない。被告製品では、システム側でマッチング処理を行い配車の最適化を図るものであるので、 乗務員端末側で了解しても必ずしも配車が確定するとは限らない。この点、本件特許発明ではユーザの希望をタクシー側で受け入れれば システム側でマッチング処理を行い配車の最適化を図るものであるので、 乗務員端末側で了解しても必ずしも配車が確定するとは限らない。この点、本件特許発明ではユーザの希望をタクシー側で受け入れれば配車が成立することと大きく相違する。 ９ 争点９（被告製品が構成要件Ｅ２を充足するか）について【原告らの主張】 事業者向けアプリ（ＷＥＢアプリ）は、リアルタイム運行管理機能、配車履歴機能、経理機能、マスタ管理機能（乗務員マスタ、車両マスタ、乗務員端末マスタ）を備えており、ユーザから発信される配車確認要求、タクシー移動端末が送信する迎車可否情報、実車完了時にタクシー移動端末から送信される実車完了情報について、タクシー事業者端末に共有されている。 したがって、構成要件Ｅ２を充足する。 【被告の主張】被告はタクシー会社向けに、ブラウザ上で閲覧できる管理画面の閲覧サービスを提供しているのみであり、タクシー会社向けにデータベースを備える端末を提供していない（乙６）。したがって、被告製品にはタクシー事業者端末が存在し ない。 さらに、被告が提供する管理画面の閲覧サービスにおいて、少なくとも被告アプリから発せられた配車依頼の情報は閲覧対象ではない（乙６、構成⑪）。 １０ 争点１０（「タクシー選択範囲情報」（構成要件Ｂ２）が現在地からの距離的範囲をいうものと解される場合に、これを「タクシー到着までの時間的情報」に置換した構成について、均等侵害が成立するか）について 【原告らの主張】(1) 第１要件本件発明の作用効果である配車の公平性を確保するためには、「タクシー選択範囲情報」は、ユーザに配車することが可能な車両を、ユーザの選択によって一定の範囲で区別するためのものであれば足りる。そうすると、車両を限 作用効果である配車の公平性を確保するためには、「タクシー選択範囲情報」は、ユーザに配車することが可能な車両を、ユーザの選択によって一定の範囲で区別するためのものであれば足りる。そうすると、車両を限定 するために用いられる情報が地理的情報であるか到着時刻であるかといった相違は、本件発明の本質的部分にはあたらない。 (2) 第２要件車両を限定するために地理的情報ではなく到着時刻を用いても、配車の公平性は確保され、本件発明と同一の作用効果が得られるので、置換することが可 能である。 (3) 第３要件タクシーを選択するための情報として地理的情報を用いる代わりに到着時刻を用いる構成とすることは、当業者にとって容易である。 【被告の主張】 否認し争う。 １１ 争点１１（「タクシー」（構成要件Ｂ４のもの）を「タクシー会社及び車種などの条件」に、「タクシー情報」（構成要件Ｂ３、Ｂ４のもの）を「タクシー会社及び車種などの条件の情報」に置換した構成について、均等侵害が成立するか）について 【原告らの主張】 (1) 第１要件ユーザがタクシーを選択することができるようにする、という本件発明の本質的部分において、ユーザが重視するのは、タクシー会社その他の条件であり、個々のタクシーを選択することまでは重要ではない。本件発明において実現しようとする配車の公平性、透明性は、タクシー事業者間又はタクシー事業者と アプリ運営会社間で確保されるべきものであり、個別のタクシー間で実現されるものではない。そのため、タクシー会社の範囲で選択ができれば、配車の公平性が確保できる。よって、上記相違点は、本件発明の本質的部分には当たらない。 (2) 第２要件 「タクシー」を「タクシー会社」に置換したとしても、 ー会社の範囲で選択ができれば、配車の公平性が確保できる。よって、上記相違点は、本件発明の本質的部分には当たらない。 (2) 第２要件 「タクシー」を「タクシー会社」に置換したとしても、これを満たすタクシー車両が複数選択され、それらの車両に配車確認要求が通知された後、適宜の１台が選択される結果、ユーザの選択に応じた配車が実現できることとなる。 よって、本件発明の作用効果が変わらない。 (3) 第３要件 個別のタクシーを指定する構成から、一定の条件でタクシーを選択する構成に置換することは、個別のタクシーに関する情報にタクシー会社情報も既に含まれていることなどに鑑みれば、当業者にとって容易である。 【被告の主張】(1) 第１要件 本件発明の本質的部分にはユーザが配車車両を指定することが含まれるところ、被告製品では、ユーザは、条件設定まではできても個々のタクシーを選択することはできない。一方、被告製品では、ユーザが関与できないユーザとタクシーのマッチングをＧＯＡＰＩコアサーバ側で行っており、本件発明の本質的部分に真っ向から反する設計となっている。 よって、個々のタクシーを選択することが可能な構成を備えていないとの相 違点は、本件発明の本質的部分に関するものである。 (2) 第２要件本件発明の目的ないし作用効果は、システム側で配車を決定することを廃し、ユーザが最終的に配車決定をすることで配車の公平性を実現することにある。 そのため、ユーザが車両決定をしない結果、システム側で配車を決定すること ができる被告製品の構成では、本件発明と同一の作用効果を奏することができない。 (3) 第３要件異なる構成を採用した結果、第２要件を充足しない場合、論理必然的に第３要件を充足し得ない。 ができる被告製品の構成では、本件発明と同一の作用効果を奏することができない。 (3) 第３要件異なる構成を採用した結果、第２要件を充足しない場合、論理必然的に第３要件を充足し得ない。 １２ 争点１２（「ユーザ端末」が、「乗車完了情報をアプリ管理サーバ及びタクシー事業者端末に共有し得るように通知」する構成（構成要件Ｂ６）において、「ユーザ端末」を「タクシー移動端末」に置換した構成について、均等侵害が成立するか）について【原告らの主張】 (1) 第１要件実車完了通知の目的は、未実車事故の防止であり、ユーザ端末から通知されてもタクシー移動端末から通知されても、配車の公平性と情報の透明性には何ら関係がない。 (2) 第２要件 (1)のとおり、実車完了通知の発信主体を置換しても、同一の作用効果を奏することができる。 (3) 第３要件実車完了通知の発信主体を置換することは、当業者にとって容易である。 【被告の主張】 否認し争う。 １３ 争点１３（原告らの被った損害額）について【原告らの主張】(1) 被告による本件特許権の実施被告は、遅くとも令和４年６月から令和５年１２月末までの間、被告製品を使用していた。 (2) 被告製品を使用することによる被告の売上額被告の令和５年５月度決算の売上予想収支は１８０億円である。 被告の事業は、専ら被告製品に関するものであるが、他事業の売上を考慮し、１０パーセントを減額すると、被告は、令和４年６月から令和６年５月までの２年間（７３１日）で、被告製品を使用することで３２４億円の売上を得た。 (3) 実施料率本件発明の効果等に鑑みれば、その実施手数料は、売上の１０パーセントを下回ることはない。 (4) 特許法１０２ 日）で、被告製品を使用することで３２４億円の売上を得た。 (3) 実施料率本件発明の効果等に鑑みれば、その実施手数料は、売上の１０パーセントを下回ることはない。 (4) 特許法１０２条３項に基づき算定される損害額令和４年６月から令和６年５月までの７３１日分の損害額は、(2)の３２４ 億円に(3)の１０パーセントを乗じた３２億４０００万円となる。 この金額を、(1)の期間中、原告会社が本件特許権を保有していた期間（５３９日）と原告Ａが本件特許権を保有していた期間（４０日間）で案分すると、原告会社の損害は２３億８９００万１３６８円、原告個人の損害は１億７７２９万１３８２円となる。 (5) 弁護士費用被告に対し、上記の損害の賠償を求めるために必要かつ相当な弁護士費用は、原告会社につき２億円、原告Ａにつき１７００万円を各下回らない。 (6) 合計よって、原告会社は２５億８９００万１３６８円の、原告Ａは１億９４２９ 万１３８２円の損害賠償を、被告に対し求める。 【被告の主張】争う。 第４ 判断 １ 判断の大要当裁判所は、被告製品は、少なくとも、本件発明の構成要件Ｂ３及びＢ４（争 点２）、Ｃ３（争点５）、Ｄ２（争点６）、Ｄ３（争点７）及びＥ２（争点９）を充足せず、加えて少なくともＢ３及びＢ４については均等侵害が成立せず（争点１１）、原告らの損害額「（争点１３）について判断するまでもなく、原告らの請求はいずれも理由がないものと判断する。 ２ 本件発明について (1) 本件明細書には、次の記載がある。 ア従来技術【０００２】従来から、タクシー配車管理システムとしては、タクシーの移動無線局と無線で通話する無線基地局を用いたシステムと、ネットワークを利用した配車アプ 書には、次の記載がある。 ア従来技術【０００２】従来から、タクシー配車管理システムとしては、タクシーの移動無線局と無線で通話する無線基地局を用いたシステムと、ネットワークを利用した配車アプリケーションによるシステムと、がある。（中略）配車 アプリケーションによるシステムにあっては、一つのタクシー事業者対象のシステムと、複数のタクシー会社の中から任意にタクシー会社を選択できる複数のタクシー事業者対象のシステムとがある。前者では、（中略）タクシー選択肢が少なく、ユーザの希望を満足し得るように迅速かつ能率良くタクシーを配車することは困難であった。後者では、一つのシステム上で複数の タクシー会社が稼働するものではなく、アプリケーション起動時にいずれかのタクシー会社を選択するものとなっているので、結局は一社の中での選択となり、前者と同様な問題があった。また、一つのシステム上で複数のタクシー会社が加盟し稼働するアプリケーションとするには、アプリ設計が複雑となり高価となり、結果的にそのシステムへの加盟費用が高額になり、実働 できていない。 【０００３】配車アプリケーションによるシステムにあって、特許文献１に示されるように、タクシーの配車可否の状態に応じて配車対象のタクシーを柔軟に選出することができるようにした配車管理システムがある。（後略）イ発明が解決しようとする課題【０００５】上記の特許文献１（注：特開２０１５−２０４００５号公報。 乙１７）に示されるシステムにあって、タクシー事業は国土交通省の事業許可を受けている事業者でなければならないことから、アプリケーションの運営主体となる配車管理装置の運営者はタクシー事業許可を得ている必要があり、このアプリケーションを自らの事業者以外のタクシー事業者に使 を受けている事業者でなければならないことから、アプリケーションの運営主体となる配車管理装置の運営者はタクシー事業許可を得ている必要があり、このアプリケーションを自らの事業者以外のタクシー事業者に使用させるには、その事業者に対し、アプリケーション使用料の請求を明確にする 義務がある。それを実現できるものにはなっていないことから、このシステムは複数の事業者向けではなく、単体の事業者向けのものである。（後略）【０００６】上記特許文献１のシステムを、一つのアプリケーション上で複数の事業者が稼働するものとしたなら、次の問題がある。（ａ）配車管理装置からユーザ端末に複数の候補車両情報を提供するものの、ユーザの意思 で複数の車両を指定し、その情報を配車管理装置に送信すると、その指定された車両の中から配車管理装置が配車の可能可否確認を行い、その結果で配車車両を決定する。そのため、実質、車両を決定するのはユーザではなく配車管理装置側となり、公平性に難がある。（ｂ）費用請求を受益者負担にすると、アプリ運営主体となる配車管理装置には全ての情報が経由するが、そ の他の加盟事業者には運営内容の明確な情報がなく、当該加盟事業者は営業車両の業務日報等からアプリ利用回数やアブリを使用した売上等を把握する必要がある。つまり、アプリ運営主体と加盟事業者とが同じ情報を取得していないため、運営情報の透明性がなく、適切な費用請求が困難である。以上より、上記システムはアプリ運営主体単体の事業者向けのものであって、 複数のタクシー事業者が加盟することが困難なものであった。 【０００７】 本発明は、上記問題を解消するものであり、アプリ運営主体が単体で、ネットワークに接続された同一のアプリケーション上で複数の事業者が稼働するものとしながらも、 のであった。 【０００７】 本発明は、上記問題を解消するものであり、アプリ運営主体が単体で、ネットワークに接続された同一のアプリケーション上で複数の事業者が稼働するものとしながらも、アプリ設計を簡素化できコスト低減が図れ、従って、アプリ使用者として別のタクシー事業者が安価に加盟でき、さらにまた、ユーザの決定情報が車両端末、タクシー事業者端末及びアプリ 運営主体の端末に届き、アプリ運営主体と加盟事業者とが同じ情報を取得して、情報の公平性・透明性を保ち、適切な費用請求が可能となる、タクシー配車管理システム、タクシー配車管理装置、及びタクシー配車管理プログラムを提供することを目的とする。 ウ解決手段 【０００８】（本件特許の各請求項の記載とほぼ同一である。）のとおりである。 エ発明の効果【００１１】本発明によれば、一のアプリケーション上で複数の事業者が稼働するものとしながらも、アプリ設計を簡素化できコスト低減が可能とな る。このため、タクシー事業者の加盟のための費用を安くでき、多数のタクシー事業者の加盟促進が期待され、ユーザは多数のタクシーの中から配車選択が可能となる。また、アプリ運営主体と加盟事業者とが同じ情報を取得するようにし、しかもユーザが最終的に配車決定するようにしているので、情報の公平性・透明性を保ち、配車アプリ使用に対する費用請求を適切に行え る。 (2) 上記本件明細書の記載によると、本件発明の特徴は、従来技術にみられるタクシーの配車管理システムにおいて、ユーザーではなく配車管理装置が車両を決定することで公平性に問題が生じること及び複数のタクシー事業者が参加するシステムにおいて、情報の非対称性があり、適切な費用請求が困難であ ったことを課題として、その解決手段として、 が車両を決定することで公平性に問題が生じること及び複数のタクシー事業者が参加するシステムにおいて、情報の非対称性があり、適切な費用請求が困難であ ったことを課題として、その解決手段として、一定の範囲にあるタクシーの中 からユーザーが配車を決定すること及びその情報が車両端末、タクシー事業者端末及びアプリ運営主体の端末に届き、アプリ運営主体と加盟事業者が同じ情報を取得することで透明性を保ち、適切な費用請求を可能としたものと認められる。 ３ 争点２（被告製品が構成要件Ｂ３及びＢ４を充足するか）及び争点１１（「タ クシー」（構成要件Ｂ４のもの）を「タクシー会社及び車種などの条件」に、「タクシー情報」（構成要件Ｂ３、Ｂ４のもの）を「タクシー会社及び車種などの条件の情報」に置換した構成について、均等侵害が成立するか）について(1) 構成要件Ｂ２、Ｂ３の文言解釈に係る原告の主張本件発明において、構成要件Ｂ３は、ユーザ端末が、「前記アプリ管理サー バからのタクシー情報を確認可能と」する構成を、構成要件Ｂ４は、ユーザ端末が「前記タクシー情報の中からユーザが希望するタクシーを指定した配車確認要求を前記タクシー移動端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知」する構成を備えるものである。この構成は、構成要件Ｂ２において、ユーザ端末が「アプリ管理サーバ」に「タクシー迎車 依頼地情報とタクシー選択範囲情報を送信」し、構成要件Ｄ３の「ユーザ希望の範囲に存在する前記タクシー情報を前記ユーザ端末に通知」することを前提としている。 原告らは、構成要件Ｂ２の「タクシー選択範囲情報」中の「選択範囲」とは「指定時刻に到着可能な範囲」を含み、この「選択範囲」に係る情報が送信さ れ、構成要件Ｂ３の「 ることを前提としている。 原告らは、構成要件Ｂ２の「タクシー選択範囲情報」中の「選択範囲」とは「指定時刻に到着可能な範囲」を含み、この「選択範囲」に係る情報が送信さ れ、構成要件Ｂ３の「タクシー情報」とは、「タクシー会社等、車両タイプ、こだわり条件等の条件によって限定されたタクシー」であってもよい旨主張する。 (2) 検討本件発明は、構成要件Ｃ１において「タクシー移動端末」を、構成要件Ｅ１ において「タクシー事業者端末」をそれぞれ構成要素としており、タクシー移 動端末は、個々の車両に備えられるもの、タクシー事業者端末は、個々の車両を統括・管理する拠点に備えられるものであるから、構成要件上、「タクシー」と、「タクシー事業者」は区別されている。 本件明細書上もこれらの区別を前提としており、「タクシー」が個々の車両ではなく、例えば一のタクシー事業者に属するなどの、一定の属性を備えた車 両集団であると理解する根拠となる記載は存在しない。 また、仮に原告が主張するように、構成要件Ｂ２の「タクシー選択範囲情報」は、（本件明細書に示された）距離的範囲に限られないと解すると、原告が主張する、個々の車両から上位概念化された（ただし、何らかの条件によって一定程度抽出された）車両集団としての「タクシー情報」と「タクシー選択範囲 情報」の区別が困難となる。 そして、前記の配車管理システムではなくユーザーが配車するタクシーを決定することにより公平性を保つとの本件発明の特徴も考慮すると、構成要件Ｂ３、Ｂ４の「タクシー（情報）」とは、個々の車両（の情報）をいうものと解され、本件発明における「配車確認要求」とは、構成要件Ｂ３の個々のタクシ ーの情報を前提として、ユーザーが選択した特定のタクシーの配車を依頼する旨の要 とは、個々の車両（の情報）をいうものと解され、本件発明における「配車確認要求」とは、構成要件Ｂ３の個々のタクシ ーの情報を前提として、ユーザーが選択した特定のタクシーの配車を依頼する旨の要求を指すものと解される。 (3) 被告製品について被告製品は、構成③に至る前に「タクシー選択範囲情報」が送信されたことを前提とすると、構成③においてユーザ端末に示されるものは、「条件を選ぶ 画面」であって、個々の車両の情報が示されるものではないから、被告製品は構成要件Ｂ３を充足しない。 また、被告製品において、ユーザーが選択した特定のタクシーの配車を依頼する旨を要求するとの構成は存しないから、被告製品は、構成要件Ｂ４の「配車確認要求」も備えない。 したがって、被告製品は、構成要件Ｂ４も充足しない。 (4) 原告らの主張について（クレーム解釈）原告ら主張の、構成要件③における「条件を選ぶ画面」に示される情報が「タクシー情報」に該当すると理解した場合（これは、争点１１の原告の主張である、「タクシー」（構成要件Ｂ４のもの）を「タクシー会社及び車種などの条件」に、「タクシー情報」（構成要件Ｂ３、Ｂ４のもの）を「タクシー会社及 び車種などの条件の情報」に置換した構成について均等侵害を主張するものにも相当する。）を検討する。 この場合において、「条件を選ぶ画面」に示されるタクシーの属性の情報が、構成要件Ｂ２における「タクシー選択範囲情報」に含まれるとの条件を満たしている（構成要件Ｂ３）ことの立証はない。加えて、被告アプリのユーザーが 「条件を選ぶ画面」で指定した個々の情報が「ユーザが希望するタクシーを指定した配車確認要求」ということになるが、被告製品において、このような情報が「タクシー移動端末」「タクシー のユーザーが 「条件を選ぶ画面」で指定した個々の情報が「ユーザが希望するタクシーを指定した配車確認要求」ということになるが、被告製品において、このような情報が「タクシー移動端末」「タクシー事業者端末」に共有し得るように通知される「（構成要件Ｂ４）との構成が存在するとも認められない。したがって、原告ら主張のクレーム解釈は取り得ない。 (5) 原告らの主張について（均等侵害）原告らの主張は、「タクシー」（構成要件Ｂ４のもの）を「タクシー会社及び車種などの条件」に、「タクシー情報」（構成要件Ｂ３、Ｂ４のもの）を「タクシー会社及び車種などの条件の情報」に置換した構成について均等侵害を主張するもの「（争点１１）にも相当する。しかし、このような置換構成であって も依然として構成要件Ｂ３及びＢ４を充足することの立証を欠いていることは前記のとおりである。 また、前記の本件発明の課題及びその解決手段からすると、配車管理装置が、ユーザーの希望する条件に適合する車両を提示し、最終的にユーザが配車要求する車両を決定し、その決定に配車管理装置が関与せず、かつ当該決定に係る 情報のやり取りをアプリ運営主体とタクシー事業者とで共有することにより、 ユーザーとアプリ運営主体、アプリ運営主体とタクシー事業者間の公平を確保することは、本件発明の本質的な特徴である。そうすると、ユーザーが具体的な配車候補車両ではなく、抽象的な配車の条件のみを定め、その後は配車管理装置において、配車する車両を決定するとのプロセスを経ることは、まさに前記の本質的な特徴にそぐわないこととなる。このことは、配車の条件を定める ことで、複数車両を候補車両として限定したとみる余地があるとしても同様である。 したがって、原告の置換に係る主張は、本件発明の 質的な特徴にそぐわないこととなる。このことは、配車の条件を定める ことで、複数車両を候補車両として限定したとみる余地があるとしても同様である。 したがって、原告の置換に係る主張は、本件発明の本質的部分に関するものというべきであって、均等の第１要件を満たさない。 (6) 小括 以上の次第で、争点２及び争点１１に関する原告の主張は、理由がない。 ４ 争点５（被告製品が構成要件Ｃ３を充足するか）について構成要件Ｃ３は、タクシー移動端末が、構成要件Ｂ４の「配車確認要求」に「応答して前記迎車可否情報を前記ユーザ端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知」する構成である。 そして、構成要件Ｂ４の「配車確認要求」は、ユーザーが選択した特定のタクシーの配車を依頼する旨の要求をいうと解されるところ、被告製品がこれに相当する構成を備えないことは前述のとおりであるから、配車確認要求を前提とする構成要件Ｃ３もまた充足しない。 この点を措いても、被告製品においては、構成⑤及び構成⑥のとおり、乗務員 アプリによる配車承諾の操作は、ＧＯＡＰＩコアサービスにのみ通知され、配車承諾がされなかった場合も、都度ユーザ端末にそれが通知されることはなく、最終的に車両が見つからなかった場合のみ、配車依頼がキャンセルされる（被告アプリの構造上、被告アプリにおいて、この意味における迎車「否」の情報が、ユーザーに通知されるものと解される。）ものである。 そうすると、被告製品は、タクシー移動端末が、「迎車可否情報」（とりわけ、 「否」の情報）を、「ユーザ端末」に共有し得るように通知する構成を備えないこととなる。 したがって、被告製品は、構成要件Ｃ３を充足しない。 ５ 争点６（被告製品が構成要件Ｄ２を わけ、 「否」の情報）を、「ユーザ端末」に共有し得るように通知する構成を備えないこととなる。 したがって、被告製品は、構成要件Ｃ３を充足しない。 ５ 争点６（被告製品が構成要件Ｄ２を充足するか）について及び争点７（被告製品が構成要件Ｄ３を充足するか）について (1) 構成要件Ｄ２は、アプリ管理サーバが、構成要件Ｂ４の「配車確認要求」及び構成要件Ｃ３の「迎車可否情報」を登録する結果情報データベースを備えることを定める。 そして、構成要件Ｂ４の「配車確認要求」は、ユーザーが選択した特定のタクシーの配車を依頼する旨の要求をいうと解されるところ、被告製品がこれに 相当する構成を備えないことは前述のとおりであり、また、被告製品は、「迎車可否情報」に係る構成も、ユーザ端末からの「乗車完了情報」に係る構成も備えないから、これらを登録する「結果情報データベース」も存しないこととなる。 この点を措いても、前記の本件発明の採用する課題及び解決手段からすると、 本「結果情報データベース」は、アプリ運営主体と加盟事業者とで、同一の情報を保有することが想定されているところ、被告製品においては、構成⑪のとおり、少なくとも被告アプリから発せられた配車依頼の情報は閲覧対象ではなく、配車確認要求がタクシー事業者に共有されているとは認められないから、やはり構成要件Ｄ２を充足しない。 (2) 構成要件Ｄ３における「タクシー情報」については、前記のとおり解釈されるところ、被告製品は、この情報をユーザ端末に送信していないから、構成要件Ｄ３も充足しない。 ６ 争点９（被告製品が構成要件Ｅ２を充足するか）について(1) 構成要件Ｅ２は、タクシー事業者端末に、ユーザ端末からの「配車確認要 求」及び「乗車完了情報」並びにタクシー も充足しない。 ６ 争点９（被告製品が構成要件Ｅ２を充足するか）について(1) 構成要件Ｅ２は、タクシー事業者端末に、ユーザ端末からの「配車確認要 求」及び「乗車完了情報」並びにタクシー移動端末からの「迎車可否情報」を 登録する「結果情報データベース」が備えられることを定めている。 この点、被告製品は、ユーザ端末からの「配車確認要求」及び「乗車完了情報」並びにタクシー移動端末からの「迎車可否情報」を備えていないことは、前記のとおりであるから、タクシー事業者端末に、これらを登録する「結果情報データベース」が備えられることもない。 (2) この点を措いても、構成⑪及び⑫並びに証拠（乙１６）によれば、被告製品では、タクシー事業者は、タクシーが配車中であるかといった運行情報や、過去の配車状況等のデータを、全て、ブラウザ上に表示される管理画面を利用して、被告が管理するサーバにアクセスして取得しており、タクシー事業者の端末に情報が蓄積していくようなデータベースは備え付けられていないことが 認められる。 この点、本件発明は、その透明性を確保するという課題解決のため、ユーザ端末からの「配車確認要求」及び「乗車完了情報」並びにタクシー移動端末からの「迎車可否情報」は、アプリ管理サーバ及びタクシー事業者端末に共有し得るように通知されることとなっている（【０００８】）。すなわち、タクシ ー事業者端末が備えるデータベースは、タクシー事業者が何らかの操作をすることで情報が登録されるのではなく、各情報が通知される都度、自動的に登録されるものとなっている（構成要件Ｂ４、Ｂ６、Ｃ３）。 そうすると、当業者は、本件明細書の記載からは、構成要件Ｅ２が定めるタクシー事業者端末が備える「結果情報データベース」とは、アプリ管理サーバ されるものとなっている（構成要件Ｂ４、Ｂ６、Ｃ３）。 そうすると、当業者は、本件明細書の記載からは、構成要件Ｅ２が定めるタクシー事業者端末が備える「結果情報データベース」とは、アプリ管理サーバ に備えられる結果情報データベースと同一の情報を、アプリ運営主体とは別の主体であるタクシー事業者が保有するためのものであり、登録すべき情報がアプリ管理サーバに通知されるのと同時的かつ自動的に通知され、登録されていくものであると解し、タクシー事業者側で何らかの操作をすることで、アプリ管理サーバが有する情報を参照することができるにとどまるようなものは含 まないものと理解するものと認められる。 そうすると、被告製品は、構成要件Ｅ２で定められる、アプリ運営主体と同一の情報をタクシー事業者端末にも登録するような「結果情報データベース」を備えていない。 (3) 以上から、被告製品は、構成要件Ｅ２も充足しない。 ７ 時機に後れた攻撃防御方法に関する判断 (1) 前提原告らは、令和７年５月１３日午前１１時の本件弁論準備手続期日の前日午後９時頃、原告第４準備書面及び甲２０号証ないし２６号証（以下「本件攻撃防御方法」という。）を提出した。これに対し、被告は、期日において、本件攻撃防御方法は、時機に後れた攻撃防御方法であるとして却下を求めた。 当裁判所は、提出後期日までの間に本件攻撃防御方法の内容の精査が困難であったことから、同期日においては陳述等を許さず、本件攻撃防御方法の扱いを検討することとしたが、この間、原告らが新たに理由を付して審理の再開を求めるなどしたため、同年７月１４日午前１１時１５分の口頭弁論期日において、弁論終結に当たり、被告の申立てにつき判決において判断を示すこととし、 原告らは、原告第４準備書 を付して審理の再開を求めるなどしたため、同年７月１４日午前１１時１５分の口頭弁論期日において、弁論終結に当たり、被告の申立てにつき判決において判断を示すこととし、 原告らは、原告第４準備書面のとおり陳述し、当裁判所は甲２０号証ないし２６号証を取り調べた。 (2) 本件攻撃防御方法前後の審理状況ア本件は、令和６年６月２２日に提起された後、弁論準備手続に付されたが、争点整理の前提となる被告製品の特定と構成要件の対比に関する原告らの 主張が不十分であったことから、被告製品の構成の特定につき、当裁判所がこれを提案するなどして、別紙「「被告製品の構成」のとおり原告らにおいても異議のないものとした。 イ原告らは、令和７年１月３０日午後１時３０分の本件弁論準備手続期日において、別紙「「被告製品の構成」の記載を前提として、各構成要件の充足性 についての準備書面を３月１０日までに提出することを約し、文言侵害の具 体的主張、均等侵害の主張については相違点や置換構成を特定した上での具体的主張を含む充足論の最終の主張整理の期限を同年３月１７日午前１０時３０分に指定された次回期日とすることに異議はない旨を述べた。 ウ令和７年３月１７日午前１０時３０分の本件弁論準備手続期日において、原告らは、同月１２日付け原告第３準備書面を陳述し、被告は次回期日「（同 年５月２日）までにこれを前提として反論することとした（上記経緯から、これにより侵害論に関する双方の主張が尽くされる見込みであった。）。 エ令和７年５月１３日午前１１時の本件弁論準備手続期日において、被告は、被告第２準備書面及び被告第３準備書面を陳述した。この期日において、原告らは、本件攻撃防御方法の提出が同期日になった理由について合理的な説 明はできないと述 弁論準備手続期日において、被告は、被告第２準備書面及び被告第３準備書面を陳述した。この期日において、原告らは、本件攻撃防御方法の提出が同期日になった理由について合理的な説 明はできないと述べた。 当裁判所は、審理経過にかんがみ、次回期日において本件攻撃防御方法を前提とせずに審理方針（いわゆる心証開示）を示すこととし、令和７年７月３日午前１１時の本件弁論準備手続期日で、被告製品は本件特許の技術的範囲に属しないことを前提に、弁論を終結する方針を示した。 オ原告らは、令和７年５月２５日、当裁判所に、原告代理人澤田昌孝が、同年２月上旬に体調を崩したため、本件に関する詳細な打合せができなかったことなどを理由に審理の再開を求める上申書を提出した。 (3) 本件攻撃防御方法の概要原告第４準備書面は、構成要件Ｂ２、Ｂ３、Ｂ４及びＢ６の文言充足に関す る主張（配車の公平性や透明性に関し、令和７年４月２３日に報道された公正取引委員会の見解を踏まえた主張のほか、道路運送車両法に関する主張等の新規主張を含む。）並びに構成要件Ｂ２、Ｂ３、Ｂ４及びＢ６に関する均等侵害に関する主張に加え、新たに、構成要件Ｄ３、Ｅ２に関する均等侵害の主張を追加するとの内容であった。 また、提出された書証は、上記公正取引委員会の見解等に関するもの（甲２ ０、２１）、道路運送法、道路運送車両法に関するもの（甲２３ないし２５）等であった。 (4) 検討上記のとおり、本件攻撃防御方法は、自らの主張の期限（なお、本訴提起前からの事前交渉（甲８ないし１６）も踏まえると、その準備期間は十分にあっ たと認められる。）を十分に認識しつつ、争点整理の完了間際（少なくとも相手方当事者がその合理的期待を有していた状況）において、均等侵害を主張する し１６）も踏まえると、その準備期間は十分にあっ たと認められる。）を十分に認識しつつ、争点整理の完了間際（少なくとも相手方当事者がその合理的期待を有していた状況）において、均等侵害を主張する部分を追加するほか、文言充足に関する主張、証拠も追加するものであって、これらを審理することは、更に争点整理に時間を要することとなり、訴訟の完結を遅延させるものと認められる。 また、原告らは、当該期日においては提出時期に係る合理的な説明はできないと述べたものである上、その主張に係る公正取引委員会の見解の前提となる事業環境や道路運送車両法等に関する事情は（なお、本件の争点との関係でどのような意味を有するのかは必ずしも判然としない。）、タクシー事業を行う原告会社やその代表者である原告Ａの立場からすれば、本件訴訟の係属当初か ら当然に知り又は知り得る立場にあったものであって、争点整理中の適時の提出に何ら支障はなかったことからすれば、原告代理人のうちの一人が体調不良であったかにかかわらず、原告らは、故意又は重過失により本件攻撃防御方法の提出を遅延したと認められる。 したがって、被告の申立ては理由があり、本件攻撃防御方法は、時機に後れ た攻撃防御方法（民訴法１５７条１項）として却下する。 第５ 結論よって、原告らの請求は全部理由がないから、いずれも棄却することとし、訴訟費用の負担について民訴法６１条を適用して、主文のとおり判決する。 大阪地方裁判所第２６民事部 裁判長裁判官 松「阿「彌隆 裁判官 松「阿「彌隆 裁判官 阿「波「野右起 裁判官 西尾太一 （別紙）被告製品の構成【被告アプリによる配車依頼まで】① 被告アプリがインストールされたユーザ端末において、アプリケーションを起動すると、ＧＯＡＰＩコアサービスに位置情報が送信され、周辺の空車のタクシーが地 図上に表示されるとともに乗車までの予測時間が表示され、乗車地、目的地を確認、入力する欄、②の画面に遷移する「次へすすむ」ボタン（バージョンにより、被告アプリに表示されるボタンの表記、当該ボタンの機能が本構成と異なる場合がある。以下各ボタンについて同じ）等が配された初期画面が表示される。 ①－１ 初期画面左下には、「今すぐ呼ぶ」ボタン及び「ＡＩ予約」ボタンが存在し、 初期画面においては「今すぐ呼ぶ」ボタンが選択された状態になっており、その状態で「次へすすむ」ボタンを押すと②画面に遷移する。 ①－２ 初期画面左下の「ＡＩ予約」ボタンを押すと、「ＡＩ予約」の画面が表示され、「新しく予約する」「次へすすむ」のボタンを順に押すと、画面が遷移し、乗車日時及び台数を指定する画面となる。指定後「次へすすむ」ボタンを押すと、②記載 の条件を確認・変更する画面に遷移する。 ② 配車依頼につき条件を確認、変更するかどうかを判別する「条件を確認・変更」ボタンが表示される。 「「条件を確認・ すむ」ボタンを押すと、②記載 の条件を確認・変更する画面に遷移する。 ② 配車依頼につき条件を確認、変更するかどうかを判別する「条件を確認・変更」ボタンが表示される。 「「条件を確認・変更」ボタンを押さないで「タクシーを呼ぶ」ボタンを押すと、配車依頼がＧＯＡＰＩコアサービスに送信される。 ③ 「「条件を確認・変更」を選択すると、タクシー会社又はタクシー無線グループ（タクシー会社、個人タクシー等によって構成される組合をいい、以下タクシー会社と併せて「タクシー会社等」という）、車両タイプ、こだわり条件（優良乗務員限定等）等の条件を指定する画面（以下「条件を選ぶ画面」という）に遷移する。条件を選ぶ画面では、被告製品のシステムに登録されたタクシー会社等の選択肢が表示される。 ユーザは、「会社を選ぶ」からタクシー会社等を、「車両タイプを選ぶ」から「ス ライドドア車両」等を選択し、「この会社を選ぶ」又は「決定する」ボタンを押すことで、タクシー会社等又は車両タイプを決定することができる。 これらの条件を決定すると、②の画面に戻り、「タクシーを呼ぶ」ボタンを押すと、条件を選ぶ画面でユーザが指定した条件での配車依頼がＧＯＡＰＩコアサービスに送信される。 【配車依頼から乗車完了までの処理】④－１ 配車依頼は、ＧＯＡＰＩコアサービスに送信され、同コアサービスは、配車マッチングサービスに配車マッチングを依頼する。 ④－２ ●●以下省略 以上省略●●⑤ ●●以下省略 以上省略●●⑥ 配車が成立すると、被告アプリの画面に、「車両が手配できました」と表示され、配車が成立した車両に係る乗務員アプリの画面に乗車地の情報が表示 配車が成立すると、被告アプリの画面に、「車両が手配できました」と表示され、配車が成立した車両に係る乗務員アプリの画面に乗車地の情報が表示される。 被告アプリは定期的に配車情報を取得して、空車、迎車などの配車の状態を監視し、配車の状態ないし、乗務員アプリがGOAPIコアサービスに送信した到着の情報を表示する。ユーザが当該車両に乗車すると、乗務員アプリが操作され、乗車状態であることが乗務員アプリからGOAPIコアサービスに送信される。 【乗務員アプリ】 【事業者向けアプリ】
▼ クリックして全文を表示