令和７年１２月２２日判決言渡同日原本受領裁判所書記官令和６年（ワ）第７０５５号損害賠償請求事件口頭弁論終結日令和７年１０月１０日判決 原告Ａ （以下「原告Ａ」という。） 原告ベスト交通株式会社 （以下「原告会社」という。） 代表者代表取締役 原告ら訴訟代理人弁護士岩崎博之同澤田昌孝同福田俊介同中森真史同谷垣友同佐藤和樹同清原直己訴訟代理人弁理士板谷康夫 被告ＤｉＤｉモビリティジャパン株式会社 代表者代表取締役 訴訟代理人弁護士松田誠司同大出萌同高橋宗鷹同遠藤祥史訴訟復代理人弁護士土居大起 主文 １ 原告らの請求をいずれも棄却する。 ２ 訴訟費用は原告らの負担とする。 事実及び理由 第１ 請求 １ 被告は、原告会社に対し、３億２６１９万９４２６円及びこれに対する令和６年７月２５日から支払済みまで年３パーセントの割合による金員を支払え。 ２ 被告は、原告Ａに対し、２１６８万０３２８円及びこれに対する令和６年７月２５日から支払済みまで年３パーセントの割合による金員を支払え。 第２ 事案の概要 １ 本判決で用いる呼称（略語） (1) 本件特許（権）：特許第６５４６５６２号に係る特許（権） (2) 本件明細書：本件特許権に係る明細書及び図面。本件明細書の内容は、別紙特許公報記載のとおり。なお、本件明細書中の段落は【（４桁の数字）】として示す。 (3) 本件発明：本件特許の特許請求の範囲請求項１の発明 (4) 被告アプリ：「ＤｉＤｉ」との名称のス 紙 特許公報記載のとおり。なお、本件明細書中の段落は【（４桁の数字）】として示す。 (3) 本件発明：本件特許の特許請求の範囲請求項１の発明(4) 被告アプリ：「ＤｉＤｉ」との名称のスマートフォン向けタクシー配車アプリケーション (5) 被告製品：被告アプリを用いたタクシー配車管理システム(6) 第１要件（等）：最高裁平成６年（オ）第１０８３号同１０年２月２４日第三小法廷判決・民集５２巻１号１１３頁において判示された、均等侵害が成立するための各要件（第１要件：非本質的部分、第２要件：置換可能性、第３要件：置換容易性、第４要件：容易推考性、第５要件：意識的除外） (7) 乙１９発明：特開２０１３－１３４６４１号公報（乙１９。平成２５年７月 ８日公開）に記載の発明(8) 乙２４発明：国際公開第２０１５／０３８１４７号（乙２４。平成２７年３月１９日公開）に記載の発明(9) 乙２５発明：特開２００４－１１０７５８号公報（乙２５。平成１６年４月８日公開）に記載の発明 ２ 原告らの請求（訴訟物）原告会社が、令和５年１１月２１日まで本件特許権を有していたこと、原告Ａが、同日、本件特許権を原告会社から譲り受けたこと、被告が遅くとも令和４年４月から被告製品を使用しており、これが本件特許権を侵害するものであることを前提とする、 (1) 原告会社の被告に対する、不法行為（民法７０９条）に基づく３億２６１９万９４２６円の損害賠償請求(2) 原告Ａの被告に対する、不法行為（民法７０９条）に基づく２１６８万０３２８円の損害賠償請求(3) (1)及び(2)に対する不法行為の後日である令和６年７月２５日から支払済 みまで民法所定の年３パーセントの割合による遅延損害金の各請求 く２１６８万０３２８円の損害賠償請求(3) (1)及び(2)に対する不法行為の後日である令和６年７月２５日から支払済 みまで民法所定の年３パーセントの割合による遅延損害金の各請求 ３ 前提事実（証拠については枝番を含む）(1) 当事者ア原告Ａは、本件特許権を有している。 イ原告会社は、一般乗用旅客自動車の運送事業等を目的とする株式会社であ る。原告会社は、保有していた本件特許権を、令和５年１１月２１日、原告Ａに譲渡した（甲６、７）。 ウ被告は、旅客自動車運送事業とそれに関するサービス、インターネットを利用したソフトウェアの開発、これに関するシステム並びにサービスの運用、保守、管理及び販売等を目的とする株式会社である。 (2) 本件特許権の書誌的事項（甲３） 本件特許権の書誌的事項は、次のとおりである。 ア特許番号：特許第６５４６５６２号イ出願日：平成２８年５月９日ウ登録日：令和元年６月２８日エ発明の名称：タクシー配車管理システム、タクシー配車管理装置、及び、 タクシー配車管理プログラム(3) 本件発明の構成要件の分説本件発明の構成要件は、以下のとおり分説される。 Ａ ネットワークにそれぞれ接続可能な、ユーザ端末と、タクシー移動端末と、アプリ管理サーバと、タクシー事業者端末と、を備え、 Ｂ 前記ユーザ端末は、ユーザ操作によりその端末にインストールしたアプリを起動し、ネットワークを介してアプリ管理サーバにアクセスし、タクシー迎車依頼地情報とタクシー選択範囲情報を送信し、Ｃ 前記アプリ管理サーバからのタクシー情報を確認可能とし、前記タクシー情報の中からユーザが希望するタクシーを指定した配車確認要求を前記タ クシー移動端末、前記アプリ管理 範囲情報を送信し、Ｃ 前記アプリ管理サーバからのタクシー情報を確認可能とし、前記タクシー情報の中からユーザが希望するタクシーを指定した配車確認要求を前記タ クシー移動端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知し、Ｄ 前記タクシー移動端末からの迎車可否情報を確認可能とし、Ｅ ユーザがタクシーへ乗車完了したとき乗車完了情報を前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知し、 Ｆ 前記タクシー移動端末は、その端末にインストールしたアプリを起動し、ネットワークを介して前記アプリ管理サーバにアクセスし、かつＧＰＳ機能を用いてポーリングによる位置情報を取得し、その位置情報を前記アプリ管理サーバに送信し、Ｇ 前記ユーザ端末からの前記配車確認要求に応答して前記迎車可否情報を 前記ユーザ端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有 し得るように通知し、Ｈ 前記アプリ管理サーバは、前記ユーザ端末から送信されたユーザ情報を登録するユーザ情報データベースと、前記タクシー移動端末から送信されたポーリング情報を受信して登録する移動端末情報データベースと、前記ユーザ端末からの前記配車確認要求、前記乗車完了情報、及び前記タクシー移動端 末からの前記迎車可否情報を登録する結果情報データベースとを備え、Ｉ 前記ユーザ端末から前記タクシー迎車依頼地情報と前記タクシー選択範囲情報を受信したとき、前記移動端末情報データベースを確認してユーザ希望の範囲に存在する前記タクシー情報を前記ユーザ端末に通知し、Ｊ 前記タクシー移動端末から迎車可の情報を受信したとき、ユーザの前記タ クシー迎車依頼地情報を前記タクシー移動端末に通知し、Ｋ 前記タクシー事業 記タクシー情報を前記ユーザ端末に通知し、Ｊ 前記タクシー移動端末から迎車可の情報を受信したとき、ユーザの前記タ クシー迎車依頼地情報を前記タクシー移動端末に通知し、Ｋ 前記タクシー事業者端末は、前記ユーザ端末からの前記配車確認要求、前記乗車完了情報、及び前記タクシー移動端末からの前記迎車可否情報を登録する結果情報データベースを備える、Ｌ タクシー配車管理システム。 (4) 被告製品の構成等被告製品の構成には争いがあり、当事者の主張は、別紙「被告製品の構成」の「原告らの主張」欄及び「被告の主張」欄各記載のとおりである（なお、「ユーザ（ー）アプリ」とあるのは被告アプリを、「ＤｉＤｉサーバ」とあるのはアプリ管理サーバを指す。）。 また、被告アプリの概要に関して、原告らは、別紙「被告アプリ説明図」のとおり主張している（ただし、原告らは、被告アプリの仕様は本訴請求期間以後の令和６年９月に変更されたとしている。）。これに対し、被告は、少なくとも①画面、②画面、③Ａ画面の遷移については争っていないが、それぞれ以下アないしウのように説明し、③画面についての原告らの説明（③Ａ画面、③Ｂ 画面は同じ画面で時間経過により迎車地から近いところに所在する車両が変 化することを表していること）を否認している。 ア ①画面ユーザが目的地を入力することにより、ユーザの現在地からユーザが入力した目的地まで運送するという配車依頼の内容を定め、ユーザの現在地及び目的地を表示する画面に遷移する。 イ ②画面ユーザが「すべての会社」を選択することにより、ユーザの現在地からユーザが入力した目的地まで運送するという配車依頼を定め、タクシー会社の指定が可能な画面に遷移する。 ウ ③Ａ画面 面ユーザが「すべての会社」を選択することにより、ユーザの現在地からユーザが入力した目的地まで運送するという配車依頼を定め、タクシー会社の指定が可能な画面に遷移する。 ウ ③Ａ画面 タクシー会社の指定が可能な画面において、被告サーバが過去の情報等から距離範囲を設定し、当該距離範囲内でユーザによる配車依頼を受け付けることができる車両の数が多い順に、上からタクシー会社のアイコンと会社名が表示される。 (5) 充足につき争いのない構成要件及び原告らが非充足を争わない構成要件 被告製品が、構成要件Ａ、Ｆ、Ｈ、Ｊ及びＬを充足することは争いがない。 他方、原告らは、被告製品が構成要件Ｅの構成を備えないこと（文言侵害が成立しないこと）を争わない。 (6) 均等侵害検討の前提となる相違点後記均等侵害の主張に関しては、本件発明と被告製品に次のような相違点が 存するとした場合のものである（ただし、相違点の把握は原告らの主張によるものであり、被告はかかる相違点の把握自体の相当性も争っている。）。 ア 「タクシー選択範囲情報」（構成要件Ｂ、Ｉ）が現在地からの距離的範囲をいうと解される場合に、これを「目的地や時間的範囲」に置換した構成（以下「均等の相違点１」という。） イ 「タクシー情報」（構成要件Ｃ、Ｉ）及び「ユーザが希望するタクシー」（構 成要件Ｃ）がいずれも「特定のタクシー車両」に係るものをいうと解される場合に、これらを「タクシー会社」に係るものに置換した構成（以下「均等の相違点２」という。）ウ 「ユーザ端末」が「乗車完了情報をアプリ管理サーバ及びタクシー事業者端末に共有し得るように通知」する構成（構成要件Ｅ）及び「ユーザ端末か らの」「乗車完了情報」「を登録する結果情報デ 。）ウ 「ユーザ端末」が「乗車完了情報をアプリ管理サーバ及びタクシー事業者端末に共有し得るように通知」する構成（構成要件Ｅ）及び「ユーザ端末か らの」「乗車完了情報」「を登録する結果情報データベース」との構成（構成要件Ｋ）において、「ユーザ端末」を「タクシー移動端末」に置換した構成（以下「均等の相違点３」という。）エ 「タクシー事業者端末」が「結果情報データベースを備える」との構成（構成要件Ｋ）において、タクシー事業者端末からネットワーク経由で結果情報 データベースにアクセスできるものと置換した構成（以下「均等の相違点４」という。）(7) 被告の行為被告は、令和４年４月から、被告アプリを製造、販売及び使用している。ただし、被告は、被告製品に関して、被告が本件発明の「実施」（特許法２条３項 柱書き、１号）の主体であることは争っている。 ４ 争点（実施主体について）(1) 被告製品に関して、被告は本件発明の実施主体に当たるか（争点１）（文言侵害について） (2) 被告製品が次の構成要件を充足するか（争点２）ア被告製品が構成要件Ｂを充足するか（争点２－１）イ被告製品が構成要件Ｃを充足するか（争点２－２）ウ被告製品が構成要件Ｄを充足するか（争点２－３）エ被告製品が構成要件Ｇを充足するか（争点２－４） オ被告製品が構成要件Ｉを充足するか（争点２－５） カ被告製品が構成要件Ｋを充足するか（争点２－６）（均等侵害について）(3) 均等侵害が成立するか（争点３）ア均等の相違点１について均等侵害が成立するか（争点３－１）イ均等の相違点２について均等侵害が成立するか（争点３－２） ウ均等の相違点３について均等侵害が成立するか（争点３－ 点３）ア均等の相違点１について均等侵害が成立するか（争点３－１）イ均等の相違点２について均等侵害が成立するか（争点３－２） ウ均等の相違点３について均等侵害が成立するか（争点３－３）エ均等の相違点４について均等侵害が成立するか（争点３－４）（無効理由について）(4) 本件特許に、次の無効理由があるか（争点４）ア明確性要件違反（争点４－１） イサポート要件違反（争点４－２）ウ実施可能要件違反（争点４－３）エ補正要件違反（争点４－４）オ乙１９発明を主引用例とする進歩性欠如（争点４－５）カ乙２４発明を主引用例とする新規性・進歩性欠如（争点４－６） キ乙２５発明を主引用例とする進歩性欠如（争点４－７）（損害）(5) 原告らの被った損害額（争点５）第３ 争点に関する当事者の主張 １ 争点１（被告製品に関して、被告は本件発明の実施主体に当たるか）について 【原告らの主張】被告は、タクシー配車管理システムを開発・運営し、ユーザが利用するアプリケーション、タクシー運転手が利用するアプリケーションを提供することで、本件発明の構成要件を含むシステム全体を第三者に利用可能な状態にしている。これは、特許法２条３項１号の「プログラム等である場合には、電気通信回線を通 じた提供を含む」という「譲渡等」に該当する。 また、被告は、提供するタクシー配車管理システムである被告製品を通じて、ユーザからの配車依頼を受け付け、タクシー運転手に配車指示を行い、その対価として手数料を得るなどの事業活動を行っている。この事業活動は、本件発明の技術的特徴を利用することで実現されており、被告自身が本件発明を「使用」（特許法２条３項１号）して利益を上げているといえ 対価として手数料を得るなどの事業活動を行っている。この事業活動は、本件発明の技術的特徴を利用することで実現されており、被告自身が本件発明を「使用」（特許法２条３項１号）して利益を上げているといえる。 さらに、被告は、自社が提供する被告アプリを通じてユーザにタクシー迎車依頼地情報やタクシー選択範囲情報を送信させ、また、タクシー運転手にＧＰＳ機能を用いた位置情報をアプリ管理サーバに送信させるなど、本件発明の構成要件の一部をユーザやタクシー事業者の行為によって実現させているところ、これらの行為は、被告が設計・提供するシステムによって誘引され、被告の管理・支配 の下で行われている。被告は、システム全体を構築し、ユーザやタクシー事業者の行為を意図的に利用することで、本件発明を実現しているといえる。このことにつき、ユーザやタクシー事業者との間の直接的な相互認識がなければ被告による侵害が成立しないとはいえない。 以上のとおり、被告は、本件発明の技術的範囲に属する被告製品（タクシー配 車管理システム）を自ら提供・運営し、その事業活動において本件発明を利用しており、本件発明の実施主体であることは明らかである。 【被告の主張】原告らは、被告が、令和４年４月から被告製品を製造、販売及び使用していると抽象的に指摘するのみで、実施行為の内容を十分に特定していない。 その点を措くとしても、被告の行為は、本件発明の実施行為に当たらない。すなわち、本件発明は、ユーザの行為（ユーザ操作によりその端末にインストールしたアプリを起動し、ネットワークを介してアプリ管理サーバにアクセスし、タクシー迎車依頼地情報とタクシー選択範囲情報を送信する行為）を構成の一つとして有する物の発明であると解されるし、タクシー事業者の行為（ポーリ 動し、ネットワークを介してアプリ管理サーバにアクセスし、タクシー迎車依頼地情報とタクシー選択範囲情報を送信する行為）を構成の一つとして有する物の発明であると解されるし、タクシー事業者の行為（ポーリングに より取得した位置情報をアプリ管理サーバに送信する行為）も構成の一つとして 有している。このように、被告製品が本件発明を実施しているといえるためには、被告のみならず、被告アプリを操作しているユーザ及びタクシー事業者という複数主体の行為が必要であり、被告の行為のみを捉えて本件発明を「実施」していると評価することはできない。原告らが主張するように、被告による被告製品の利用のみを捉えて「使用」に該当するとはいえないし、本件発明に係るタクシー 配車管理システムは「プログラム等」には該当しないから、被告による被告製品の提供・運営も「譲渡等」に該当しない。 また、複数の主体の行為について特許権侵害が認められるためには、各行為の間に連鎖又は相互連携の関係が認められ、行為全体を合わせると発明の効果を実現できる可能性があること、及び、各主体がいかなる行為をするかについて、相 互に認識していることを要するところ、少なくとも、被告とユーザとの間、及び被告とタクシー事業者との間で、互いの行為を相互に認識しているという事実はなく、被告を本件発明の実施主体と評価することはできない。さらに、複数主体の関与が前提とされた物の発明について、当該物を支配管理している者の行為は、本件発明の「実施」に該当する可能性があるものの、原告らは、被告が被告製品 を支配管理していることについて、十分な主張を行っていない。 したがって、被告製品に関して、被告は本件発明の実施主体に当たらない。 ２ 争点２－１（被告製品が構成要件Ｂを充足するか） 品 を支配管理していることについて、十分な主張を行っていない。 したがって、被告製品に関して、被告は本件発明の実施主体に当たらない。 ２ 争点２－１（被告製品が構成要件Ｂを充足するか）について【原告らの主張】構成要件Ｂの「タクシー選択範囲情報」とは、ユーザに配車することが可能な タクシー車両を一定の範囲で区別する情報であるところ、距離的情報のみに限定されるものではなく、本件明細書の【００１８】は、「タクシー選択範囲情報」が取り得る具体的な表示方法の一つの実施例を示したものにすぎない。むしろ、本件特許の特許請求の範囲請求項２において、「タクシー選択範囲情報」が特に「距離範囲」として特定されていることからすれば、請求項１における「タクシー選 択範囲情報」は、必ずしも距離範囲に限定されるものではなく、それよりも広い 概念、すなわち、時間的範囲をも当然に含む概念であることを強く示唆していると解釈する方が、請求項全体の整合性の観点からも自然である。さらに、目的地情報についても、タクシー配車に本来必須ではないにもかかわらず先行してユーザがこれを入力することは、実質的に「目的地エリアで営業するタクシー」という特定の範囲に存在するタクシーに絞って配車依頼を行うための情報、すなわち 「タクシー選択範囲情報」を送信していることになる。 そして、被告製品は、ユーザ端末から、タクシー迎車依頼地情報である現在地情報のほか、時間的基準（「今すぐ出発」又は指定時刻に現在地に到着可能）及び地理的基準（目的地情報に基づく営業区域）の少なくとも一方、あるいは双方に基づく「タクシー選択範囲情報」をアプリ管理サーバに送信しているものである ことは明らかであり、構成要件Ｂを充足する。 【被告の主張】クレー 営業区域）の少なくとも一方、あるいは双方に基づく「タクシー選択範囲情報」をアプリ管理サーバに送信しているものである ことは明らかであり、構成要件Ｂを充足する。 【被告の主張】クレームの規定文言や本件明細書の記載（「タクシー選択範囲情報として、現在地より半径５００ｍ以内、８００ｍ以内、１２００ｍ以内、１５００ｍ以内の表示がされる。」などの記載）等を参酌すれば、「タクシー選択範囲情報」とは、 ユーザの現在地を中心として配車選択可能なタクシーの所在に係る距離的範囲を示す情報であると解される。 他方、被告製品においては、ユーザ端末からアプリ管理サーバに対して、配車可能なタクシーの距離的範囲を示す情報が送信されることはない。 したがって、被告製品は構成要件Ｂを充足しない。 ３ 争点２－２（被告製品が構成要件Ｃを充足するか）について【原告らの主張】本件明細書の【００１９】には、「…図２（ｃ）に示すような複数候補が表示される。画面に表示される候補のタクシー情報には、選択タクシー会社、…を含ませることができる。ユーザはこれら情報を参考にして的確にタクシー配車依頼を 行うことができる。」と記載され、さらに、【００２０】には、「ユーザは、ユーザ 端末の画面に表示された受信情報結果を見て、気に入ったタクシーが有れば、それを選択する。」と記載され、図２（ｃ）には、複数のタクシー会社が示されている。このように、構成要件Ｃの「タクシー情報」には、選択タクシー会社（タクシー事業者）も含まれ、ユーザにより選択される「（ユーザが希望する）タクシー」がタクシー事業者であってもよいことが示されている。そうすると、構成要 件Ｃの「タクシー情報」及びユーザが希望する「タクシー」との文言の意味は、特定のタ 択される「（ユーザが希望する）タクシー」がタクシー事業者であってもよいことが示されている。そうすると、構成要 件Ｃの「タクシー情報」及びユーザが希望する「タクシー」との文言の意味は、特定のタクシー車両に限定されるものではないし、クレーム全体を通覧しても、そのような限定がされているとはいえない。加盟事業者間及びアプリ運営主体と加盟事業者間の公平性・透明性の確保という本件発明の目的効果に照らしても、ユーザによりタクシー事業者（タクシー会社）が指定されれば、特定のタクシー 車両を指定することまでは課題解決に必須のものではない。仮に、「タクシー」の用語につき「タクシー会社」を含む概念との解釈が困難であったとしても、構成要件Ｃにおける「ユーザが希望するタクシー」とは、「ユーザが希望する特定のタクシー会社の任意のタクシー車両」とは解釈できる。 そして、別紙「被告製品の構成」の構成要件Ｃに係る「原告らの主張」欄記載 のとおり、被告製品においては、「タクシー情報」として会社単位での情報がユーザ端末に表示され、ユーザがその情報から希望したタクシー会社を指定すれば、（同会社の任意のタクシー車両の）配車依頼がアプリ管理サーバに送信されるのであり、「配車確認要求を前記タクシー移動端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知」されることになる。 したがって、被告製品は、構成要件Ｃを充足する。 【被告の主張】構成要件Ｃの「タクシー」との文言は、広辞苑の定義、クレーム全体において「タクシー」と「タクシー事業者」が書き分けられていること、本件明細書の各記載（ユーザの選択の対象は特定のタクシー車両を念頭に置いていること）等か らすれば、特定のタクシー車両を指すと解釈するのが自然である。 ー事業者」が書き分けられていること、本件明細書の各記載（ユーザの選択の対象は特定のタクシー車両を念頭に置いていること）等か らすれば、特定のタクシー車両を指すと解釈するのが自然である。 また、「タクシー情報」との文言は、上記の「タクシー」の解釈のほか、本件明細書【００２８】（「情報結果とは、ユーザ希望の範囲に存在するタクシー情報であり、この情報には、タクシー事業者名、料金、車種等が含まれる。」）等の記載に照らすと、ユーザが希望した範囲に存在する配車依頼可能なタクシー車両の情報を指すと解釈すべきである。 これに対し、被告製品においては、ユーザ端末からは個別のタクシー車両の情報が確認可能となることはなく、また、個別のタクシーの中からユーザが希望する個別車両を指定した配車確認要求がされることもない。そもそも、ユーザが個別車両を指定するわけではなく、アプリ管理サーバがＡＩマッチング機能に基づき配車車両を選定している。 したがって、被告製品は、「前記タクシー情報の中からユーザが希望するタクシーを指定した配車確認要求を…通知し」との構成要件Ｃを充足しない。 ４ 争点２－３（被告製品が構成要件Ｄを充足するか）について【原告らの主張】本件発明のような、複数の端末（ユーザ端末、タクシー移動端末、アプリ管理 サーバ、タクシー事業者端末）がネットワークを介して連携するシステムにおいては、端末間の情報伝達が仲介機能であるアプリ管理サーバを経由することは、技術的に極めて一般的かつ合理的な構成である。そうすると、構成要件Ｄにおける「前記タクシー移動端末からの」という文言は、必ずしもユーザ端末がタクシー移動端末と直接通信して情報を受信することまでを要求するものではなく、 「迎車可否情報」の出 すると、構成要件Ｄにおける「前記タクシー移動端末からの」という文言は、必ずしもユーザ端末がタクシー移動端末と直接通信して情報を受信することまでを要求するものではなく、 「迎車可否情報」の出所または起点がタクシー移動端末であることを特定するものと解釈するのが相当である。また、被告は、迎車否の情報はアプリ管理サーバに送信されない旨主張するが、被告自身の発行物である「ドライバーアプリ操作マニュアル」（甲３２）の記載内容に照らせば、ドライバーが「注文拒否」ボタンを操作するか、注文に対して一定時間応答しないことによって「迎車否」の意思 表示を行い、その情報がアプリ管理サーバに通知される機能が存在する。そして、 最終的に指定したタクシー会社からの迎車車両を確定できなかった場合には、ユーザ端末にその通知がされるため（甲３３）、迎車否の情報はユーザ端末に通知されているといえる。したがって、被告製品は、構成要件Ｄを充足する。 【被告の主張】構成要件Ｄは、「前記タクシー移動端末からの迎車可否情報を確認可能とし、」 と規定しているところ、被告製品では、ユーザが確認可能となる迎車可の情報はアプリ管理サーバから送信され、タクシー移動端末から送信されるわけではないため、対応する機能がない。 したがって、被告製品は、構成要件Ｄを充足しない。 ５ 争点２－４（被告製品が構成要件Ｇを充足するか）について 【原告らの主張】被告製品においては、配車依頼（配車確認要求）を受信したドライバーにより配車承諾がされ、アプリ管理サーバに配車承諾が送信される。 被告は、タクシー移動端末に対する配車確認要求はユーザ端末からではなくアプリ管理サーバから送信されるものであるし、タクシー移動端末は、迎車可の情 報をアプリ ーバに配車承諾が送信される。 被告は、タクシー移動端末に対する配車確認要求はユーザ端末からではなくアプリ管理サーバから送信されるものであるし、タクシー移動端末は、迎車可の情 報をアプリ管理サーバに送信するにすぎない旨主張する。しかし、前記４で構成要件Ｄに関して主張したとおり、各通信がサーバを経由するのはアプリケーションを使用したシステムという性質において当然のことであるから、タクシー移動端末への配車確認要求がユーザ端末から発せられたものであれば足りるし、また、タクシー移動端末からの迎車可否情報（迎車否の情報も含まれる。）が最終的に ユーザ端末やタクシー事業者端末にも共有されていれば足りる。 したがって、被告製品は、構成要件Ｇを充足する。 【被告の主張】構成要件Ｇでは、「ユーザ端末からの前記配車確認要求に応答して前記迎車可否情報を前記ユーザ端末、前記アプリ管理サーバ及び前記タクシー事業者端末に 共有し得るように通知し、」と規定されている。しかしながら、被告製品では、 「ユーザ端末から」ではなく、「アプリ管理サーバから」迎車可否確認が送信されており、加えて、タクシー移動端末は迎車可の情報をアプリ管理サーバに送信するが、迎車可否情報をユーザ端末及びタクシー事業者端末に共有し得るように通知するわけではない。 したがって、被告製品は、構成要件Ｇを充足しない。 ６ 争点２－５（被告製品が構成要件Ｉを充足するか）について【原告らの主張】被告製品においては、ユーザ端末から「前記タクシー迎車依頼地情報と前記タクシー選択範囲情報」を受信したとき、当該情報を踏まえてアプリ管理サーバは、移動端末情報データベースを確認して、ユーザ希望の範囲（上記各情報から決め られる範囲）に存在する 依頼地情報と前記タクシー選択範囲情報」を受信したとき、当該情報を踏まえてアプリ管理サーバは、移動端末情報データベースを確認して、ユーザ希望の範囲（上記各情報から決め られる範囲）に存在する車両のタクシー会社名をユーザ端末に通知する。前記のとおり、「タクシー情報」とは、タクシー会社を含むものであるから、上記のことが「前記移動端末データベースを確認してユーザ希望の範囲に存在する前記タクシー情報を前記ユーザ端末に通知し」に該当する。 したがって、被告製品は、構成要件Ｉを充足する。 【被告の主張】前記のとおり、被告製品においては、ユーザ端末からアプリ管理サーバに対して、配車可能なタクシーの距離的範囲を示す情報が送信されることはないため、アプリ管理サーバは、「タクシー選択範囲情報を受信」しない。また、アプリ管理サーバは、「移動端末情報データベースを確認してユーザ希望の範囲に存在する 前記タクシー情報を前記ユーザ端末に通知」することもない。 したがって、被告製品は、構成要件Ｉを充足しない。 ７ 争点２－６（被告製品が構成要件Ｋを充足するか）について【原告らの主張】被告製品では、タクシー事業者端末の管理画面において、会社情報、実績一覧、 車両位置情報、経営管理、サービス管理等の各画面を確認できるところ（甲２１）、 構成要件Ｋの「配車確認要求」、「乗車完了情報」及び「迎車可否情報」については、それぞれ上記管理画面の「注文情報一覧画面」、「車両位置情報画面」及び「実績一覧画面」・「車両位置情報画面」において確認することができる。なお、迎車可のみならず迎車否の情報も含まれることは、前記４のとおりである。 したがって、被告製品は、構成要件Ｋを充足する。 【被告の主張】被 画面」において確認することができる。なお、迎車可のみならず迎車否の情報も含まれることは、前記４のとおりである。 したがって、被告製品は、構成要件Ｋを充足する。 【被告の主張】被告製品では、タクシー事業者端末は、アプリ管理サーバから、一定期間ごとにタクシー移動端末ごとのタクシー配車履歴情報を受信するのみで、「前記ユーザ端末からの前記配車確認要求、前記乗車完了情報」を受信するわけではない。 また、タクシー移動端末から受信するのは、「迎車可否情報」ではなく、「迎車可 情報」のみである。 したがって、被告製品は、構成要件Ｋを充足しない。 ８ 争点３－１（均等の相違点１について均等侵害が成立するか）について【原告らの主張】(1) 均等の相違点１の内容 均等の相違点１は、ユーザが配車可能なタクシーの候補群を絞り込むために用いる「タクシー選択範囲情報」の種類が「距離的範囲」であるか、「目的地や時間的範囲」であるかという違いである。 (2) 第１要件構成要件Ｂが担う役割は、発明の核心的目的である「ユーザによる選択・意 思決定」が行われる前段階において、その対象となる候補群（配車可能なタクシー）を適切な範囲に絞り込むことにある。発明の核心は、あくまでその後の「ユーザによる選択」とその「結果の共有」による公平性・透明性の確保である。候補群を絞り込むための具体的な基準が「距離」であれ、「目的地」や「時間」であれ、それはユーザが選択を行うための「前提」を設定する手段に過ぎ ない。 また、構成要件Ｉが担う役割は、ユーザ端末から送信された「タクシー迎車依頼地情報」と「タクシー選択範囲情報」に基づき、アプリ管理サーバが移動端末情報データベースを確認することにあるところ、この また、構成要件Ｉが担う役割は、ユーザ端末から送信された「タクシー迎車依頼地情報」と「タクシー選択範囲情報」に基づき、アプリ管理サーバが移動端末情報データベースを確認することにあるところ、この「タクシー選択範囲情報」の種類が「距離的範囲」であるか、「目的地や時間的範囲」であるかの違いについても、上記と同様である。 そうすると、均等の相違点１は、本件発明の核心的目的である「ユーザの意思決定を基盤とした配車プロセスの公平性・透明性の確保」とは直接関連しない、非本質的な部分であることは明らかである。 (3) 第２要件「タクシー選択範囲情報」につき、「距離的範囲」を「目的地や時間的範囲」 に置き換えても、アプリ管理サーバがユーザの希望に基づき配車候補を適切な範囲に絞り込むという同一の機能を果たし、その後のユーザ選択を通じて本件発明全体の目的である公平性・透明性の確保という同一の作用効果が得られるから、置換可能である。 (4) 第３要件 タクシー配車システムの開発において、配車候補を絞り込む手段として、単純な「距離」だけでなく、事業上の制約である「目的地（営業区域）」やユーザの利便性に直結する「時間」といった要素を用いることは、対象製品等の製造等の時点において、当業者であれば容易に想到し得た設計上の選択肢であるから、前記相違点についての置換は、当業者にとって容易に想到できる。 【被告の主張】原告らが主張する均等の相違点１は、「タクシー選択範囲情報」を「ユーザに配車することが可能なタクシー車両を一定の範囲で区別する情報」と解釈することを前提にしたものであるところ、かかる解釈は、「一定の範囲」という抽象的かつ不明確なクレーム解釈を採用している点、距離的範囲以外にいかなる情報が「一 一定の範囲で区別する情報」と解釈することを前提にしたものであるところ、かかる解釈は、「一定の範囲」という抽象的かつ不明確なクレーム解釈を採用している点、距離的範囲以外にいかなる情報が「一 定の範囲」を構成するのかにつきクレームや明細書上の根拠を示していない点に おいて不合理である。 したがって、上記相違点は、そもそもこれを本件発明と被告製品との相違点として把握すること自体が不合理であり、本質的部分であるか否かを検討するまでもなく、均等侵害の成否を論じる前提を欠く。 ９ 争点３－２（均等の相違点２について均等侵害が成立するか）について 【原告らの主張】(1) 均等の相違点２の内容均等の相違点２は、アプリ管理サーバがユーザ端末に通知するタクシー情報が「タクシー車両」に係るものか、「タクシー会社」に係るものかという違いと、ユーザが特定の「タクシー車両」を指定するか、特定の「タクシー会社」 を指定するかという違いである。 (2) 第１要件本件発明の本質は、ユーザの意思決定を配車プロセスに組み込むことで、アプリ運営主体の恣意的な操作を排除し、プラットフォーム全体の公平性・透明性を担保する点にある。そして、ユーザが「タクシー会社」を選択可能であれ ば、アプリ運営主体が特定の事業者やその保有車両を不当に優先・排除するといった恣意的な運用を効果的に防止できるから、事業者間の公平な競争を促し、運営の透明性を確保するという本件発明が解決しようとした核心的な課題は達成される。上記選択に先立ち、アプリ管理サーバがユーザ端末に通知するタクシー情報についても同様である。 そうすると、均等の相違点２は、本件発明の本質的部分には当たらない。 (3) 第２要件ユーザ端末への通知対象及 理サーバがユーザ端末に通知するタクシー情報についても同様である。 そうすると、均等の相違点２は、本件発明の本質的部分には当たらない。 (3) 第２要件ユーザ端末への通知対象及びユーザの選択対象が「タクシー車両」から「タクシー会社」に置き換わったとしても、ユーザの意思決定を反映させ、恣意性を排除して公平性・透明性を確保するという本件発明の目的を達成し、同一の 作用効果を奏するため、置換可能である。 (4) 第３要件タクシー配車システムを設計する当業者にとって、ユーザに提示する選択肢の単位を「個々の車両」とするか、「タクシー会社」とするかは、基本的な設計上の選択肢の一つである。本件発明の目的である「ユーザの意思を反映させ、恣意性を排除する」という観点からも、ユーザに「個々の車両」ではなく「タ クシー会社」を選択させることは、その目的を達成するために当業者において直接的かつ容易に想到し得る手段である。 【被告の主張】被告製品においては、ユーザがタクシー車両を指定した配車確認要求をすることができず、アプリ管理サーバが独自のロジックにより配車するタクシー車両を 決定しているところ、配車管理装置側ではなく、ユーザがタクシー車両を指定した配車確認要求を通知するという点、その前提として、アプリ管理サーバがユーザ端末にタクシー車両の情報を通知するという点は、本件発明の本質的部分であるから、本件発明と被告製品とはかかる本質的部分において相違し、第１要件を充足しない。 また、ユーザが特定のタクシー車両ではなく、特定のタクシー事業者を選択して配車を依頼するとの構成とすることは、「ユーザが最終的に配車決定する」ことにより「情報の公平性・透明性を保ち、配車アプリ使用に対する費用請 が特定のタクシー車両ではなく、特定のタクシー事業者を選択して配車を依頼するとの構成とすることは、「ユーザが最終的に配車決定する」ことにより「情報の公平性・透明性を保ち、配車アプリ使用に対する費用請求を適切に行える」という本件発明の作用効果が阻害されるし、当業者においてこれを採用する動機付けを欠くものでもあるから、第２要件及び第３要件を充足しない。 さらに、被告製品における上記構成は、本件発明の特許出願手続において、特許請求の範囲から意識的に除外されたか、少なくとも外形的にそのように解されるような行動がとられたものであるから、第５要件を充足しない。 １０ 争点３－３（均等の相違点３について均等侵害が成立するか）について【原告らの主張】 (1) 均等の相違点３の内容 均等の相違点３は、乗車完了情報の通知主体が「ユーザ端末」か、「タクシー移動端末」かという違いである。 (2) 第１要件「乗車完了情報」の通知の核心的な目的は、「ユーザが実際に乗車した」という事実をシステム上で正確に記録し、その情報をアプリ管理サーバおよびタク シー事業者端末で共有することにある。この情報の共有により、正確な利用実績の把握、適切な料金計算、そして事業者間の透明な情報基盤が確保され、発明全体の目的である公平性・透明性に貢献する。この核心的な目的を達成する上で、通知を行う主体がユーザ自身（ユーザ端末経由）であるか、乗務員（タクシー移動端末経由）であるかは、本質的な差異ではない。 (3) 第２要件前記のとおり、実車完了通知の発信主体を置換しても、同一の作用効果を奏することができる。 (4) 第３要件実車完了通知の発信主体を置換することは、対象製品等の製造等の時点にお いて、当業者 とおり、実車完了通知の発信主体を置換しても、同一の作用効果を奏することができる。 (4) 第３要件実車完了通知の発信主体を置換することは、対象製品等の製造等の時点にお いて、当業者であれば技術的に極めて容易に想到し得た設計上の選択肢である。 【被告の主張】乗車完了の通知主体がユーザ端末であることは、アプリ運営主体と加盟事業者とが同じ情報を取得するという点において、本件発明の本質的部分というべきであるから、本件発明と被告製品とはかかる本質的部分において相違し、第１要件 を充足しない。 また、ユーザ端末ではなくタクシー移動端末が乗車完了情報をアプリ管理サーバに送信するとの構成とすることは、「アプリ運営主体と加盟事業者とが同じ情報を取得する」ことにより「情報の公平性・透明性を保ち、配車アプリ使用に対する費用請求を適切に行える」という本件発明の作用効果が阻害されるし、当業 者においてこれを採用する動機付けを欠くものでもあるから、第２要件及び第３ 要件を充足しない。 さらに、被告製品における上記構成は、本件発明の特許出願手続において、特許請求の範囲から意識的に除外されたか、少なくとも外形的にそのように解されるような行動がとられたものであるから、第５要件を充足しない。 １１ 争点３－４（均等の相違点４について均等侵害が成立するか）について 【原告らの主張】(1) 均等の相違点４の内容均等の相違点４は、タクシー事業者が配車結果情報を把握・確認するための結果情報データベースが、事業者端末自体に物理的に「備え」られているか、あるいはサーバ上に存在し事業者端末からネットワーク経由で「アクセス・確 認できる」状態にあるかという違いである。 (2) 第１要件構成要件Ｋ 端末自体に物理的に「備え」られているか、あるいはサーバ上に存在し事業者端末からネットワーク経由で「アクセス・確 認できる」状態にあるかという違いである。 (2) 第１要件構成要件Ｋの核心的な機能は、本件発明全体の目的である公平性・透明性の確保のため、タクシー事業者が、自社に関連する配車確認要求、迎車可否情報、乗車完了情報といった３種の情報を、アプリ運営主体と同等に把握・確認でき る手段を提供することにある。これを達成する上で、結果情報データベースが物理的にどこに存在するか（事業者端末内部か、サーバ上か）は、本質的な差異ではない。 (3) 第２要件結果情報データベースが存在する場所を置換しても同一の作用効果を奏す ることができることは、前記で述べたとおりである。 (4) 第３要件タクシー事業者端末が結果情報データベースを物理的に「備える」構成に代えて、被告製品の製造等の当時、既に技術常識となっていたＷＥＢアプリケーション／クラウド型のアーキテクチャを採用し、サーバ上のデータベースにネ ットワーク経由でアクセスして情報を確認する構成とすることは、当業者にと って容易に想到可能である。 【被告の主張】被告の主張（本件発明と被告製品との相違点）は、被告製品は、①タクシー事業者端末は、アプリ管理サーバから、一定期間ごとにタクシー移動端末ごとのタクシー配車履歴情報を受信するのみで、ユーザ端末からの配車確認要求及び乗車 完了情報を受信するわけではない点、②迎車可の情報を受信するのはアプリ管理サーバからである点、③タクシー事業者端末が受信する情報も「迎車可否情報」ではなく「迎車可の情報」のみである点、において本件発明と相違するというものであり、原告らの主張する相違点がかかる アプリ管理サーバからである点、③タクシー事業者端末が受信する情報も「迎車可否情報」ではなく「迎車可の情報」のみである点、において本件発明と相違するというものであり、原告らの主張する相違点がかかる主張にどのように応答したものなのか不明である。したがって、そもそも原告らの主張の趣旨が不明であるし、前提 となるクレーム解釈も根拠がない不合理なものであるため、本質的部分であるか否かを検討するまでもなく、均等侵害の成否を論じる前提を欠く。 １２ 争点４（本件特許に次の無効理由があるか）及び争点５（原告らの被った損害額）について後記のとおり、当裁判所は上記各争点について判断しないので、その主張の骨 子を別紙「争点４に関する被告の主張の概要」及び別紙「争点５に関する原告らの主張」のとおり摘示することとする。 第４ 判断 １ 判断の大要等前提事実記載のとおり、被告製品の具体的構成については争いがあるが、原告 らの主張する被告製品の構成を前提としても、被告製品は、少なくとも、本件発明の構成要件Ｃ（争点２－２）、Ｇ（争点２－４）、Ｉ（争点２－５）及びＫ（争点２－６）を充足せず、加えて、少なくとも均等の相違点２については均等侵害が成立しないから（争点３－２）、その余の争点につき判断するまでもなく、原告らの請求はいずれも理由がないものと判断する。 ２ 本件発明について (1) 本件明細書には、次の記載がある。 ア従来技術【０００２】従来から、タクシー配車管理システムとしては、タクシーの移動無線局と無線で通話する無線基地局を用いたシステムと、ネットワークを利用した配車アプリケーションによるシステムと、がある。（中略）配車ア プリケーションによるシステムにあっては、一つのタクシー事業者 局と無線で通話する無線基地局を用いたシステムと、ネットワークを利用した配車アプリケーションによるシステムと、がある。（中略）配車ア プリケーションによるシステムにあっては、一つのタクシー事業者対象のシステムと、複数のタクシー会社の中から任意にタクシー会社を選択できる複数のタクシー事業者対象のシステムとがある。前者では、（中略）タクシー選択肢が少なく、ユーザの希望を満足し得るように迅速かつ能率良くタクシーを配車することは困難であった。後者では、一つのシステム上で複数のタク シー会社が稼働するものではなく、アプリケーション起動時にいずれかのタクシー会社を選択するものとなっているので、結局は一社の中での選択となり、前者と同様な問題があった。また、一つのシステム上で複数のタクシー会社が加盟し稼働するアプリケーションとするには、アプリ設計が複雑となり高価となり、結果的にそのシステムへの加盟費用が高額になり、実働でき ていない。 【０００３】配車アプリケーションによるシステムにあって、特許文献１に示されるように、タクシーの配車可否の状態に応じて配車対象のタクシーを柔軟に選出することができるようにした配車管理システムがある。（後略）イ発明が解決しようとする課題 【０００５】上記の特許文献１（注：特開２０１５−２０４００５号公報。 乙２）に示されるシステムにあって、タクシー事業は国土交通省の事業許可を受けている事業者でなければならないことから、アプリケーションの運営主体となる配車管理装置の運営者はタクシー事業許可を得ている必要があり、このアプリケーションを自らの事業者以外のタクシー事業者に使用させ るには、その事業者に対し、アプリケーション使用料の請求を明確にする義 務がある。それを実現でき る必要があり、このアプリケーションを自らの事業者以外のタクシー事業者に使用させ るには、その事業者に対し、アプリケーション使用料の請求を明確にする義 務がある。それを実現できるものにはなっていないことから、このシステムは複数の事業者向けではなく、単体の事業者向けのものである。（後略）【０００６】上記特許文献１のシステムを、一つのアプリケーション上で複数の事業者が稼働するものとしたなら、次の問題がある。（ａ）配車管理装置からユーザ端末に複数の候補車両情報を提供するものの、ユーザの意思で 複数の車両を指定し、その情報を配車管理装置に送信すると、その指定された車両の中から配車管理装置が配車の可能可否確認を行い、その結果で配車車両を決定する。そのため、実質、車両を決定するのはユーザではなく配車管理装置側となり、公平性に難がある。（ｂ）費用請求を受益者負担にすると、アプリ運営主体となる配車管理装置には全ての情報が経由するが、その 他の加盟事業者には運営内容の明確な情報がなく、当該加盟事業者は営業車両の業務日報等からアプリ利用回数やアブリを使用した売上等を把握する必要がある。つまり、アプリ運営主体と加盟事業者とが同じ情報を取得していないため、運営情報の透明性がなく、適切な費用請求が困難である。以上より、上記システムはアプリ運営主体単体の事業者向けのものであって、複 数のタクシー事業者が加盟することが困難なものであった。 【０００７】本発明は、上記問題を解消するものであり、アプリ運営主体が単体で、ネットワークに接続された同一のアプリケーション上で複数の事業者が稼働するものとしながらも、アプリ設計を簡素化できコスト低減が図れ、従って、アプリ使用者として別のタクシー事業者が安価に加盟でき、さ ら クに接続された同一のアプリケーション上で複数の事業者が稼働するものとしながらも、アプリ設計を簡素化できコスト低減が図れ、従って、アプリ使用者として別のタクシー事業者が安価に加盟でき、さ らにまた、ユーザの決定情報が車両端末、タクシー事業者端末及びアプリ運営主体の端末に届き、アプリ運営主体と加盟事業者とが同じ情報を取得して、情報の公平性・透明性を保ち、適切な費用請求が可能となる、タクシー配車管理システム、タクシー配車管理装置、及びタクシー配車管理プログラムを提供することを目的とする。 ウ解決手段 【０００８】（本件特許の各請求項の記載とほぼ同一である。）のとおりである。 エ発明の効果【００１１】本発明によれば、一のアプリケーション上で複数の事業者が稼働するものとしながらも、アプリ設計を簡素化できコスト低減が可能とな る。このため、タクシー事業者の加盟のための費用を安くでき、多数のタクシー事業者の加盟促進が期待され、ユーザは多数のタクシーの中から配車選択が可能となる。また、アプリ運営主体と加盟事業者とが同じ情報を取得するようにし、しかもユーザが最終的に配車決定するようにしているので、情報の公平性・透明性を保ち、配車アプリ使用に対する費用請求を適切に行え る。 (2) 上記本件明細書の記載によると、本件発明の特徴は、従来技術にみられるタクシーの配車管理システムにおいて、ユーザーではなく配車管理装置が車両を決定することで公平性に問題が生じること、及び複数のタクシー事業者が参加するシステムにおいて、情報の非対称性があり、適切な費用請求が困難であっ たことを課題として、その解決手段として、一定の範囲にあるタクシーの中からユーザーが配車を決定すること及びその情報が車両端末、タクシ において、情報の非対称性があり、適切な費用請求が困難であっ たことを課題として、その解決手段として、一定の範囲にあるタクシーの中からユーザーが配車を決定すること及びその情報が車両端末、タクシー事業者端末及びアプリ運営主体の端末に届き、アプリ運営主体と加盟事業者が同じ情報を取得することで透明性を保ち、適切な費用請求を可能としたものと認められる。 ３ 争点２－２（被告製品が構成要件Ｃを充足するか）及び争点３－２（均等の相違点２について均等侵害が成立するか）について(1) 構成要件Ｃの文言解釈に係る原告らの主張本件発明において、構成要件Ｃは、ユーザ端末が、「前記アプリ管理サーバからのタクシー情報を確認可能とし、前記タクシー情報の中からユーザが希望す るタクシーを指定した配車確認要求を前記タクシー移動端末、前記アプリ管理 サーバ及び前記タクシー事業者端末に共有し得るように通知」する構成を備えるものである。この構成は、構成要件Ｉの「ユーザ希望の範囲に存在する前記タクシー情報を前記ユーザ端末に通知」することを前提としている。 原告らは、構成要件Ｃの「タクシー情報」には「タクシー会社」も含まれ、「ユーザが希望するタクシー」はタクシー会社（タクシー事業者）であっても よい旨主張する。また、「ユーザが希望するタクシー」は、少なくとも「ユーザが希望する特定のタクシー会社の任意のタクシー車両」とは解釈できる旨主張する。 (2) 検討本件発明は、構成要件Ｆにおいて「タクシー移動端末」を、構成要件Ｋにお いて「タクシー事業者端末」をそれぞれ構成要素としており、タクシー移動端末は、個々の車両に備えられるもの、タクシー事業者端末は、個々の車両を統括・管理する拠点に備えられるものであるから、構成要 いて「タクシー事業者端末」をそれぞれ構成要素としており、タクシー移動端末は、個々の車両に備えられるもの、タクシー事業者端末は、個々の車両を統括・管理する拠点に備えられるものであるから、構成要件上、「タクシー」と、「タクシー事業者」は区別されている。 本件明細書上もこれらの区別を前提としており、「タクシー」が個々の車両 ではなく、タクシー会社ないしタクシー事業者であると理解する根拠となる記載は存在しない。 そして、配車管理装置ではなくユーザーが配車するタクシーを決定することにより公平性を保つとの本件発明の前記特徴も考慮すると、構成要件Ｃの「タクシー（情報）」とは、個々の車両（の情報）をいうものと解され、本件発明に おける「ユーザが希望するタクシーを指定した配車確認要求」とは、構成要件Ｃの個々のタクシーの情報を前提として、ユーザーが選択した特定のタクシーの配車を依頼する旨の要求を指すものと解される。 (3) 被告製品について被告製品においては、前提事実記載のとおり、被告アプリの③Ａ画面におい てユーザ端末に示されるものは「タクシー会社を指定する」画面であって、個々 の車両の情報が示されるものではないし、ユーザーが選択するのは特定の車両ではないから、「ユーザが希望するタクシーを指定した配車確認要求」も備えない（なお、構成要件Ｃのうち、配車確認要求を「前記タクシー移動端末…及び前記タクシー事業者端末に共有し得るように通知し」の構成を被告製品が備えていることについては、主張はそもそも欠落している。）。 したがって、被告製品は、構成要件Ｃを充足しない。 (4) 原告らの主張について（クレーム解釈）原告らは、本件明細書の【００１９】には、「…図２（ｃ）に示すような複数候補が ）。 したがって、被告製品は、構成要件Ｃを充足しない。 (4) 原告らの主張について（クレーム解釈）原告らは、本件明細書の【００１９】には、「…図２（ｃ）に示すような複数候補が表示される。画面に表示される候補のタクシー情報には、選択タクシー会社、…を含ませることができる。ユーザはこれら情報を参考にして的確にタ クシー配車依頼を行うことができる。」と記載され、さらに、【００２０】には、「ユーザは、ユーザ端末の画面に表示された受信情報結果を見て、気に入ったタクシーがあれば、それを選択する。」と記載され、図２（ｃ）には、複数のタクシー会社が示されていることからすると、構成要件Ｃの「タクシー情報」には、選択タクシー会社（タクシー事業者）も含まれ、ユーザにより選択される 「（ユーザが希望する）タクシー」がタクシー事業者であってもよいことが示されている旨主張する。 しかし、本件明細書上、「タクシー」とは個々の車両をいうものと解されることは前記のとおりであるし、【００１９】の記載は、「画面に表示される候補のタクシー情報には、選択タクシー会社、料金体系、車種、宣伝文等を含ませる ことができる。」というものであり、「料金体系、車種」との記載もあることからすると、「タクシー情報」とは、飽くまで個々の車両の情報であって（同一のタクシー会社であっても、車種等によって料金体系が異なることがあるのは当業者にとって明らかである。）、その情報に「タクシー会社」等の情報を含ませることができるにすぎないものと当業者は理解するというべきである。また、 原告らが指摘する図２（ｃ）も、個々の車両の情報の一つとしてタクシー会社 が記載されているにすぎず、原告らの主張の根拠とはなり得ない。なお、原告らは、「ユーザが である。また、 原告らが指摘する図２（ｃ）も、個々の車両の情報の一つとしてタクシー会社 が記載されているにすぎず、原告らの主張の根拠とはなり得ない。なお、原告らは、「ユーザが希望するタクシー」は、少なくとも「ユーザが希望する特定のタクシー会社の任意のタクシー車両」とは解釈できる旨主張するが、ユーザーにより特定の車両が選択されているものではないことに変わりはないし、そもそも「タクシー情報」はタクシー会社の情報のみで足りるものではないことは 前記のとおりであるから、いずれにしても原告らの主張は成り立たない。 したがって、原告ら主張のクレーム解釈は取り得ない。 (5) 原告らの主張について（均等侵害）原告らは、構成要件Ｃの「タクシー」を「タクシー会社」に置換した構成について均等侵害を主張する（争点３－２）。 しかし、前記の本件発明の課題及びその解決手段からすると、配車管理装置が、ユーザーの希望する条件に適合する車両を提示し、最終的にユーザーが配車要求する車両を決定し、その決定に配車管理装置が関与せず、かつ当該決定に係る情報のやり取りをアプリ運営主体とタクシー事業者とで共有することにより、ユーザーとアプリ運営主体、アプリ運営主体とタクシー事業者間の公 平性及び情報の透明性を確保することは、本件発明の本質的な特徴である。そうすると、ユーザーが具体的な配車候補車両ではなく、タクシー会社のみを定め、その後は配車管理装置において、配車する車両を決定するとのプロセスを経ることは、まさに前記の本質的な特徴にそぐわないこととなる。 したがって、原告らの置換に係る主張は、本件発明の本質的部分に関するも のというべきであって、均等の第１要件を満たさない。 さらに、ユーザーが「タクシー会社」 そぐわないこととなる。 したがって、原告らの置換に係る主張は、本件発明の本質的部分に関するも のというべきであって、均等の第１要件を満たさない。 さらに、ユーザーが「タクシー会社」のみを選択するとした場合、選択対象となり得る同社の複数の車両のうち、アプリ運営主体においていずれの車両を選択し、配車決定すべきかについては一概に決められるものではないし、そもそも、アプリ運営主体がかかる決定に関与することにより、本件発明の目的で ある前記の公平性・透明性の確保が損なわれることは前記のとおりであるから、 当業者にとって原告ら主張の置換が可能かつ容易であるとは認められない。そうすると、均等の第２要件及び第３要件も満たさない。 (6) 小括以上の次第で、争点２－２及び争点３－２に関する原告らの主張は、理由がない。 ４ 争点２－４（被告製品が構成要件Ｇを充足するか）について構成要件Ｇは、タクシー移動端末が、構成要件Ｃの「配車確認要求」に「応答して前記迎車可否情報を前記ユーザ端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知」する構成である。 そして、構成要件Ｃの「配車確認要求」は、ユーザーが選択した特定のタクシ ーの配車を依頼する旨の要求をいうと解されるところ、被告製品がこれに相当する構成を備えないことは前記のとおりであるから、上記配車確認要求を前提とする構成要件Ｇもまた充足しない。 したがって、被告製品は、構成要件Ｇを充足しない。 ５ 争点２－５（被告製品が構成要件Ｉを充足するか）について 構成要件Ｉにおける「タクシー情報」については、前記のとおり、個々の車両の情報と解釈されるところ、被告製品は、この情報をユーザ端末に通知していないから、 成要件Ｉを充足するか）について 構成要件Ｉにおける「タクシー情報」については、前記のとおり、個々の車両の情報と解釈されるところ、被告製品は、この情報をユーザ端末に通知していないから、構成要件Ｉも充足しない。 ６ 争点２－６（被告製品が構成要件Ｋを充足するか）について構成要件Ｋは、タクシー事業者端末に、ユーザ端末からの「配車確認要求」を 登録する「結果情報データベース」が備えられることを定めている。 この点、被告製品は、ユーザ端末からの「配車確認要求」を備えていないことは、前記のとおりであるから、タクシー事業者端末に、これを登録する「結果情報データベース」が備えられることもない。 したがって、被告製品は、構成要件Ｋも充足しない。 第５ 結論 以上の次第で、原告らの請求はいずれも理由がない。 大阪地方裁判所第２６民事部 裁判長裁判官 松阿彌隆 裁判官 島田美喜子 裁判官 阿波野右起 （別紙）争点４に関する被告の主張の概要 １ 明確性要件違反（争点４－１）について(1) 構成要件Ｂ「タクシー選択範囲情報」について原告らは、構成要件Ｂの「タクシー選択範囲情報」とは、「ユーザに配車す ることが可能なタクシー車両を一定の範囲で区別する情報」を指すと主張する。 しかしながら、かかる原告ら主張の定義を前提とした場合、「一定の範 要件Ｂの「タクシー選択範囲情報」とは、「ユーザに配車す ることが可能なタクシー車両を一定の範囲で区別する情報」を指すと主張する。 しかしながら、かかる原告ら主張の定義を前提とした場合、「一定の範囲」という文言は抽象的であり、どのような範囲を指しているのか、また、いかなる情報に基づいて原告らの主張する一定の範囲が判断されるのか、距離的範囲以外にいかなる情報が「一定の範囲」を構成するのか、クレームからは読み取れ ないことはもちろん、これらを基礎づける明細書上の記載も一切ない。 また、本件明細書における「タクシー選択範囲情報」の説明としては、【００１８】、【００２５】、【００２６】、【００２８】、【００２９】及び【００３１】等において記載されているものの、これらの各段落には、ユーザが現在地を中心とした半径５００ｍ以内、８００ｍ以内、１２００ｍ以内、１５０ ０ｍ以内等の距離的範囲から希望する範囲を選択して、当該範囲内に所在する特定のタクシー車両について配車決定を行う態様のみが開示されており、（距離的範囲には限られない）「一定の範囲」の外延は全くもって不明である。 したがって、原告らの主張を前提とすると、上記特許請求の範囲の記載は、第三者に不測の不利益を及ぼすほど不明確であり、明確性要件に違反する。 (2) 構成要件Ｃ「タクシー」について特許請求の範囲において、通常同一の単語は同一の意味を有し、さもなければ当該特許請求の範囲は不明確であるといわざるを得ない。しかしながら、原告らは、構成要件Ｅにおける「タクシー」の文言は、「特定のタクシー車両」を指すと解釈することを認めている一方で、同じ請求項１の中の文言である構 成要件Ｃの「タクシー」の文言は、「タクシー会社」を含むとする解釈と、「特 定の 、「特定のタクシー車両」を指すと解釈することを認めている一方で、同じ請求項１の中の文言である構 成要件Ｃの「タクシー」の文言は、「タクシー会社」を含むとする解釈と、「特 定のタクシー会社の任意のタクシー車両」とする解釈があり得るとして、不明確な文言であることを認めている。 したがって、原告らの主張を前提とすると、構成要件Ｃの特許請求の範囲の記載は、第三者に不測の不利益を及ぼすほど不明確であり、明確性要件に違反する。 (3) 構成要件Ｃ「タクシー情報」について原告らは、構成要件Ｃにおける「タクシー情報」とは、特定のタクシー車両やタクシー会社を含むものであるが、これらに限られないし、また、本件明細書の記載からすると、「タクシー情報」とは、タクシー会社のみの場合も含んでいることは明らかである旨主張する。 しかしながら、仮に「タクシー情報」を原告らの主張どおりに解した場合、「タクシー情報」がタクシー車両の情報であるのか、タクシー会社の情報であるのか不明確である上、本件明細書には「タクシー情報」がタクシー会社のみの情報であってもよいとする記載はないのであって、いかなる情報が確認可能となれば構成要件Ｃを満たすのか、その内容が不明である。すなわち、本件明 細書の【００１９】の記載からすれば、「タクシー情報」がタクシー会社のみの情報の場合は想定されておらず、むしろ、「的確にタクシー配車依頼を行う」と記載されていることからすれば、タクシー会社情報は参考情報の一つとして、様々な情報を踏まえて、ユーザがタクシー車両の配車依頼を行うものである。 したがって、原告らの主張を前提とすると、上記特許請求の範囲の記載は、 第三者に不測の不利益を及ぼすほど不明確であり、明確性要件に違反する。 ザがタクシー車両の配車依頼を行うものである。 したがって、原告らの主張を前提とすると、上記特許請求の範囲の記載は、 第三者に不測の不利益を及ぼすほど不明確であり、明確性要件に違反する。 ２ サポート要件違反（争点４－２）について(1) 構成要件Ｂ「タクシー選択範囲情報」について前記のとおり、原告らは、構成要件Ｂの「タクシー選択範囲情報」とは、「ユーザに配車することが可能なタクシー車両を一定の範囲で区別する情報」を指 すと主張する。しかしながら、本件明細書には、「タクシー選択範囲情報」と してユーザが距離範囲に係る情報以外にいかなる情報によって配車可能なタクシー車両を区別することができるかについては何ら記載も示唆もされていない。 本件明細書によれば、本件特許の課題の一つは、「実質、車両を決定するのはユーザではなく配車管理装置側となり、公平性に難がある」（【０００６】） という点にあり、その解決手段としてユーザが特定のタクシー車両を選択できるように構成され、効果として「ユーザが最終的に配車決定するようにしている」ことが記載されている（【００１１】）。このように、ユーザが特定の車両を選択して配車決定を行うことが本件特許の特徴であるが、本件明細書では、ユーザによる配車決定のプロセスとしてユーザが距離的範囲によって配車可 能な車両を区別することについてしか記載も示唆もされていない。 したがって、当業者において、発明の詳細な説明の記載から、ユーザが距離範囲に係る情報以外の情報によって配車可能なタクシー車両を区別する方法を認識することはできず、本件特許は、サポート要件に違反する。 (2) 構成要件Ｃ「タクシー」について 前記のとおり、原告らは、構成要件Ｃの「タクシー」の文言は、「タクシー会社」 する方法を認識することはできず、本件特許は、サポート要件に違反する。 (2) 構成要件Ｃ「タクシー」について 前記のとおり、原告らは、構成要件Ｃの「タクシー」の文言は、「タクシー会社」を含むとする解釈と、「特定のタクシー会社の任意のタクシー車両」とする解釈があり得る旨主張する。しかしながら、そもそも、ユーザが「タクシー」を指定するという本件特許の文脈において、「特定のタクシー会社の任意のタクシー車両」という解釈は実質的に「タクシー会社」を意味するにほかな らない。いずれにしても、本件明細書には、「タクシー」に「タクシー会社」が含まれるという解釈について記載されておらず、また、本件特許は正にユーザが特定の車両を指定して配車決定を行うことが特徴なのであって、原告らが主張するいずれの解釈による構成も、記載も示唆もされていない。 すなわち、そもそも特許請求の範囲の記載において、特定の車両を指す場合 には「タクシー」、タクシー会社（タクシー事業運営主体）を指す場合には「タ クシー事業者」と明確に書き分けられているし、本件明細書においても、「タクシー事業者」がタクシー事業運営主体の意味で使用されており、「タクシー」という文言がタクシー事業運営主体を含む文言であることは想定されていない。また、前記のとおり、ユーザが特定の車両を選択して配車決定を行うことが本件特許の特徴であるが、本件明細書では、ユーザがタクシー会社あるいは 特定のタクシー会社の任意の車両を指定するということについては記載も示唆もない。 したがって、当業者において、発明の詳細な説明の記載から、ユーザがタクシー会社あるいは特定のタクシー会社の任意の車両を指定するという構成によって本件特許の課題を解決できることは認識できず、本件 したがって、当業者において、発明の詳細な説明の記載から、ユーザがタクシー会社あるいは特定のタクシー会社の任意の車両を指定するという構成によって本件特許の課題を解決できることは認識できず、本件特許は、サポート 要件に違反する。 (3) 構成要件Ｃ「タクシー情報」について前記のとおり、原告らは、構成要件Ｃにおける「タクシー情報」とは、特定のタクシー車両やタクシー会社を含むものであるが、これらに限られないし、また、本件明細書の記載からすると、「タクシー情報」とは、タクシー会社の みの場合も含んでいることは明らかである旨主張する。 しかしながら、本件明細書における「タクシー」は特定の車両を指す語であるから、「タクシー情報」はタクシー車両の情報を指すと解するのが自然である。さらに、【００１９】の記載からすれば、「タクシー情報」がタクシー会社のみの情報の場合は想定されておらず、むしろ、「的確にタクシー配車依頼 を行う」との記載からすれば、タクシー会社情報は参考情報の一つとして、様々な情報を踏まえて、ユーザがタクシー車両の配車依頼を行うという説明が記載されているといえる。当該記載からすれば、タクシー会社の情報は、候補の車両の中からユーザが特定の車両を選ぶ際に参考とする情報の一つであるとしか読めない。ユーザが特定の車両を選択して配車決定を行うことが本件特許の 特徴であることから、ユーザが特定の車両を選ぶ際にいかなる情報を通知する かは発明の特徴となるが、原告らの主張する構成は本件明細書に記載も示唆もない。 したがって、当業者において、発明の詳細な説明の記載から、タクシー情報としてタクシー会社のみの情報を通知するという構成によって本件特許の課題を解決できることは認識できず、本件特許は、 唆もない。 したがって、当業者において、発明の詳細な説明の記載から、タクシー情報としてタクシー会社のみの情報を通知するという構成によって本件特許の課題を解決できることは認識できず、本件特許は、サポート要件に違反する。 ３ 実施可能要件違反（争点４－３）について(1) 構成要件Ｂ「タクシー選択範囲情報」について前記のとおり、原告らは、構成要件Ｂの「タクシー選択範囲情報」とは、「ユーザに配車することが可能なタクシー車両を一定の範囲で区別する情報」を指すと主張する。 仮に、原告らの主張を前提とすると、「タクシー選択範囲情報」とは、「ユーザの現在地を中心として配車選択可能なタクシーの所在に係る距離的範囲を示す情報」に限定されず、あくまで「距離的範囲を示す情報」は「一定の範囲で区別する情報」に含まれる一例となる。しかしながら、本件明細書には、ユーザが現在地を中心とした半径５００ｍ以内、８００ｍ以内、１２００ｍ以 内、１５００ｍ以内等の距離的範囲から希望する範囲を選択して、当該範囲内に所在する特定のタクシー車両について配車決定を行う態様のみが開示されている。かかる実施形態のみから、ユーザによる配車決定のプロセスとしてユーザが距離的範囲以外の情報によって配車可能な車両を区別する方法は不明確であり、過度の試行錯誤を要する。 したがって、本件明細書の記載は、当業者が当該発明に係る物を具体的に生産し、使用することができる程度に記載されているといえず、実施可能要件に違反する。 (2) 構成要件Ｃ「タクシー」について前記のとおり、原告らは、構成要件Ｃの「タクシー」の文言は、「タクシー 会社」を含むとする解釈と、「特定のタクシー会社の任意のタクシー車両」と する解釈があり得る旨主張する。 しか のとおり、原告らは、構成要件Ｃの「タクシー」の文言は、「タクシー 会社」を含むとする解釈と、「特定のタクシー会社の任意のタクシー車両」と する解釈があり得る旨主張する。 しかしながら、本件特許の課題の一つは、「実質、車両を決定するのはユーザではなく配車管理装置側となり、公平性に難がある」（【０００６】）という点にあり、その解決手段としてユーザが特定のタクシー車両を選択できるように構成され、効果として「ユーザが最終的に配車決定するようにしている」 ことが記載されている（【００１１】）。仮に、【００１８】ないし【００２１】、【００２５】、【００２６】及び【００３４】に開示された実施形態について、原告らの上記主張を前提として、「タクシー」の記載に「タクシー会社」が含まれる、あるいは「特定のタクシー会社の任意のタクシー車両」と解釈したとすれば、これらの実施形態において最終的な特定の車両をユーザが選 択することについての記載がなくなり、どのように「実質、車両を決定するのはユーザではなく配車管理装置側となり、公平性に難がある」という課題を解決するのか、「ユーザが最終的に配車決定するようにしている」という効果が得られるのかについての記載が全くなくなるといわざるを得ず、過度の試行錯誤を要する。 したがって、本件明細書の記載は、当業者が当該発明に係る物を具体的に生産し、使用することができる程度に記載されているといえず、実施可能要件に違反する。 (3) 構成要件Ｃ「タクシー情報」について前記のとおり、原告らは、構成要件Ｃにおける「タクシー情報」とは、特定 のタクシー車両やタクシー会社を含むものであるが、これらに限られないし、また、本件明細書の記載からすると、「タクシー情報」とは、タクシー会社のみの場合 件Ｃにおける「タクシー情報」とは、特定 のタクシー車両やタクシー会社を含むものであるが、これらに限られないし、また、本件明細書の記載からすると、「タクシー情報」とは、タクシー会社のみの場合も含んでいる旨主張する。 しかしながら、原告らの上記主張を前提として、ユーザが確認可能であるのがタクシー会社のみの情報であると解釈したとすれば、前記のとおり、本件明 細書で開示された実施形態において最終的な特定の車両をユーザがいかなる 方法で選択するのかについての記載がなくなり、どのように「実質、車両を決定するのはユーザではなく配車管理装置側となり、公平性に難がある」という課題を解決するのか、「ユーザが最終的に配車決定するようにしている」という効果が得られるのかについての記載が全くなくなるといわざるを得ず、過度の試行錯誤を要する。 したがって、本件特許明細書の記載は、当業者が当該発明に係る物を具体的に生産し、使用することができる程度に記載されているといえず、実施可能要件に違反する。 ４ 補正要件違反（争点４－４）について本件特許は、平成３０年１２月１４日付けの手続補正書において、構成要件Ｃ、 Ｅ、Ｇの「同報送信し」が「共有し得るように通知し」と補正されている。 しかしながら、「同報通信」の用語としての意義や、明細書及び図面の記載からすると、本件明細書における「同報送信」の技術的意義は、送信元の端末から、複数の送信先に対して、所定の情報をそれぞれ一斉に送信することであると解される。一方、「共有し得るように通知し」との文言は、上記「同報送信」のよう に、送信元から複数の送信先に対してそれぞれ情報を送信する態様に限られず、送信元から一方の送信先にのみ情報を送信し、その後、一方の送信先から他方の送信先に情 の文言は、上記「同報送信」のよう に、送信元から複数の送信先に対してそれぞれ情報を送信する態様に限られず、送信元から一方の送信先にのみ情報を送信し、その後、一方の送信先から他方の送信先に情報を送信する態様を含むものであると解される。つまり、所定の経由先を中継して、情報が通知される態様を含むものであると解される。 これに対し、本件明細書には、「配車確認要求」、「乗車完了情報」、及び、 「迎車可否情報」について、同報送信すること、つまり、送信元から複数の送信先に対してそれぞれ一斉に送信することのみが記載されており、所定の経由先を中継して、情報が送信されることは全く記載されていない。 そうすると、原告らが平成３０年１２月１４日付けの手続補正書においてした補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項 を超える態様を含むものであることから、補正要件に違反する。 ５ 乙１９発明を主引用例とする進歩性欠如（争点４－５）について(1) 乙１９発明乙１９には、次の乙１９発明が開示されている（構成Ａ等の呼称の内容は、争点４－５の範囲内のものである。）。 ア構成Ａ：ネットワーク５にそれぞれ接続可能な、顧客側端末２と、タクシ ー車両側端末３と、制御サーバ１０と、タクシー会社サーバ４と、を備え、イ構成Ｂ’：顧客側端末２は、ユーザ操作によりその端末にインストールした空車タクシー呼び寄せ用アプリ２０を起動し、ネットワーク５を介して制御サーバ１０にアクセスし、現在位置情報とタクシー属性情報(U12)を送信し、 ウ構成Ｃ：制御サーバ１０からのタクシー情報(C1)を確認可能とし、タクシー情報(C1)の中から顧客が希望するタクシーを指定した車両指定呼出要求（U1）をタクシー車両側 2)を送信し、 ウ構成Ｃ：制御サーバ１０からのタクシー情報(C1)を確認可能とし、タクシー情報(C1)の中から顧客が希望するタクシーを指定した車両指定呼出要求（U1）をタクシー車両側端末３、制御サーバ１０、タクシー会社サーバ４に共有し得るように通知し、エ構成Ｄ：タクシー車両側端末３からの呼出承諾信号を確認可能とし、 オ構成Ｆ：タクシー車両側端末３は、その端末にインストールしたタクシー待ち客捕捉用アプリ３０を起動し、ネットワーク５を介して制御サーバ１０にアクセスし、かつＧＰＳ機能を用いてポーリングによる車両位置情報を取得し、その車両位置情報を制御サーバ１０に送信し、カ構成Ｇ：顧客側端末２からの車両指定呼出要求（U1）に応答して呼出承諾 信号を顧客側端末２、制御サーバ１０及びタクシー会社サーバ４に共有し得るように通知し、キ構成Ｇ－２’：顧客がタクシーへ乗車完了したとき乗車実績情報（T22）を制御サーバ１０及びタクシー会社サーバ４に共有し得るように通知し、ク構成Ｈ’：制御サーバ１０は、顧客側端末２から送信された顧客の行動履 歴等を示す情報を登録するデータベース１１を備え、タクシー車両側端末３ から発信される車両の現在位置情報を受信し、顧客側端末２からの車両指定呼出要求（U1）及びタクシー車両側端末３からの呼出承諾信号を受信し、ケ構成Ｉ’：顧客側端末２から現在位置情報とタクシー属性情報(U12)を受信したとき、データベース１１を確認して、顧客の現在位置から所定範囲内に位置する空車タクシーを対象として、タクシー情報（C1）を要求元顧客側 端末２に送信し、コ構成Ｊ：タクシー車両側端末３から呼出承諾信号を受信したとき、顧客の現在位置情報をタクシー車両側端末３に通知し 車タクシーを対象として、タクシー情報（C1）を要求元顧客側 端末２に送信し、コ構成Ｊ：タクシー車両側端末３から呼出承諾信号を受信したとき、顧客の現在位置情報をタクシー車両側端末３に通知し、サ構成Ｋ：タクシー会社サーバ４は、顧客側端末２からの車両指定呼出要求（U1）及びタクシー車両側端末３からの呼出承諾信号を受信する、 シ構成Ｌ：タクシー車両の呼び寄せシステム。 (2) 本件発明と乙１９発明との対比本件発明と乙１９発明は、構成Ａ、Ｃ、Ｄ、Ｆ、Ｇ、Ｊ、Ｋ、Ｌにおいて一致する一方で、以下の点において相違する。 ア相違点１：「顧客側が配車要求時に送信する情報」について、本件発明で は「タクシーの迎車位置とタクシー移動端末との距離範囲に係るタクシー選択範囲情報」を送信するが、乙１９発明では「タクシーの車種や運賃、運転手の性別等に係るタクシーの属性情報」を送信する点。 イ相違点２：「顧客がタクシーに乗車したときに送信する乗車完了に係る情報」について、本件発明では「ユーザ端末が乗車完了情報をアプリ管理サー バ及びタクシー事業者端末に通知」するが、乙１９発明では、「タクシー車両側端末３が顧客の乗車場所、乗車日時、降車場所、降車日時等の乗車実績情報（T22）を制御サーバ１０及びタクシー会社サーバ４に送信」する点。 (3) 容易想到性ア相違点１について 乙２０（特開２００２－１３３５８８号公報、平成１４年５月１０日公開） には、利用者が所有する携帯端末２が、タクシーの配車要求を送信する際に、複数の検索距離の範囲を検索条件としてタクシー配車サーバに送信することが記載されている。また、乙２１（国際公開第０３／０５０７３６号、平成１５年６月１９日公開）には、タクシー７の乗客であるユーザ 、複数の検索距離の範囲を検索条件としてタクシー配車サーバに送信することが記載されている。また、乙２１（国際公開第０３／０５０７３６号、平成１５年６月１９日公開）には、タクシー７の乗客であるユーザが取引依頼を送信する際に、半径１キロメートルといったタクシーの検索距離範囲に係 る情報を取引仲介装置２に送信することが記載されている。そして、乙２０の記載事項は、タクシーの配車運用システムに係る技術であり、乙２１の記載事項は、ユーザとタクシーとの取引仲介システムに係る技術であることから、本件発明及び乙１９発明と技術分野を同一とする。 そうすると、乙２０や乙２１の記載事項を乙１９発明に適用して、顧客側 端末２が空車タクシー呼び寄せ用アプリを起動したときに、顧客の現在位置情報に係る情報に加えて、タクシーの検索距離範囲に係る情報を制御サーバ１０に送信することは、その発明の属する技術の分野における通常の知識を有する者が容易に推考し得るものである。 イ相違点２について 乙２２（特開２００７－５８３４５号公報、平成１９年３月８日公開）には、ユーザがタクシーに乗車したときに、ユーザが有する携帯電話２０が乗車完了の旨の信号を経路通知装置１０に送信することが記載されている。また、乙２３（特開２０１５－２０４００５号公報、平成２７年１１月１６日公開）には、ユーザの無線携帯端末１０１が乗車完了通知をタクシー配車登 録管理サーバ１０５に送信することが記載されている。そして、乙２２の記載事項は、タクシーの配車に係る経路を通知するシステムに係る技術であり、乙２３の記載事項は、タクシーの配車管理システムに係る技術である。そうすると、乙２２や乙２３の記載事項を乙１９発明に適用して、顧客がタクシーに乗車したときに、乗車完了に係る情報を顧客側端末 であり、乙２３の記載事項は、タクシーの配車管理システムに係る技術である。そうすると、乙２２や乙２３の記載事項を乙１９発明に適用して、顧客がタクシーに乗車したときに、乗車完了に係る情報を顧客側端末２が制御サーバ１０ に送信することは、その発明の属する技術の分野における通常の知識を有す る者が容易に推考し得るものである。 そして、仮に、本件特許が前記４の補正要件を満たすことを前提とすると、通知の態様は当業者において適宜調整可能なものであるから、上記のことから、ユーザ端末が乗車完了に係る情報をアプリ管理サーバに通知することも、その発明の属する技術の分野における通常の知識を有する者が容易に推考 し得るものである。 (4) 小括以上のとおり、相違点１及び２はいずれも当業者が容易に推考し得るものであり、また、本件発明により得られる作用効果も、乙１９発明及び乙２０ないし乙２３の各記載事項から予測し得る範囲内のものであり、格別な作用効果を 奏するものとはいえない。 したがって、本件特許は、乙１９発明及び乙２０ないし乙２３の各記載事項に基づいて、当業者が特許出願前に容易に発明をすることができたものであるから、進歩性を欠く。 ６ 乙２４発明を主引用例とする新規性・進歩性欠如（争点４－６）について (1) 乙２４発明乙２４には、次の乙２４発明が開示されている（構成Ａ等の呼称の内容は、争点４－６の範囲内のものである。）。 ア構成Ａ：ネットワーク110にそれぞれ接続可能な、ユーザデバイス108と、タクシーデバイス106と、タクシー配車サーバ102と、タクシーサービスサー バ104と、を備え、イ構成Ｂ’’ ：ユーザデバイス108は、ユーザによる操作により、迎車場所やリクエストの日時をタクシー配車 106と、タクシー配車サーバ102と、タクシーサービスサー バ104と、を備え、イ構成Ｂ’’ ：ユーザデバイス108は、ユーザによる操作により、迎車場所やリクエストの日時をタクシー配車サーバ402に送信(438)し、ウ構成Ｃ：タクシー配車サーバ202からの登録タクシーに関する情報を表示し(226)、提案されたタクシーのうちユーザが選択したタクシー情報をタク シー配車サーバ402に送信するとともに、タクシー配車サーバ402が選択され たタクシー情報をタクシーサービス、個別のタクシー端末に共有することでスケジュール設定し、エ構成Ｄ：タクシー406のデバイスからのタクシー空車情報を確認可能し、オ構成Ｅ ：ユーザがタクシーへ乗車完了したとき、タクシー車内にユーザがいることを確認する情報をタクシー配車サーバ602に送信し、 カ構成Ｆ：タクシーデバイス106は、ＧＰＳデバイスにて取得した位置情報を、ネットワーク110を介して、タクシー配車サーバ602に送信し、キ構成Ｇ：ユーザデバイス408からの要求に応じて、タクシーの空車情報を、タクシー配車サーバ402およびタクシーサービス会社404を介して通知し、ク構成Ｈ：タクシー配車サーバ102は、ユーザデバイスから送信されたユー ザプロファイルを登録し、タクシー内の移動装置から送信された位置情報を受信して登録し、ユーザデバイスから過去に送信された配車確認要求、乗車完了情報、及び、タクシー車内装置からの過去に送信された空車情報を登録し、ケ構成Ｉ：ユーザデバイス402からタクシー迎車リクエストを受信したとき、 タクシーの空車情報等を参照して、１台以上の推奨タクシーのリストをユーザデバイス402に提供し、コ構成Ｊ：ユーザに選択 Ｉ：ユーザデバイス402からタクシー迎車リクエストを受信したとき、 タクシーの空車情報等を参照して、１台以上の推奨タクシーのリストをユーザデバイス402に提供し、コ構成Ｊ：ユーザに選択されたタクシーをスケジュールし、サ構成Ｋ：タクシー配車サービスサーバ104は、ネットワーク110を介して、タクシー配車サーバ102、ユーザデバイス108、及び、タクシーデバイス106に 接続されるシ構成Ｌ：システム100。 (2) 本件発明と乙２４発明との対比本件発明と乙２４発明は、構成Ａ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌにおいて一致する一方で、以下の点において相違する。なお、本件発明の構 成要件Ｂ「タクシー選択範囲情報」を「ユーザに配車することが可能なタクシ ー車両を一定の範囲で区別する情報」とし、内容を限定しない原告らの主張を前提とすれば、以下の点は相違点ではなくなる。 相違点：「顧客側が配車要求時に送信する情報」について、本件発明では「タクシーの迎車位置とタクシー移動端末との距離範囲に係るタクシー選択範囲情報」を送信するが、乙２４発明では「迎車場所やリクエストの日時」を送信 する点。 (3) 容易想到性前記の乙２０の記載事項は、タクシーの配車運用システムに係る技術であり、乙２１の記載事項は、ユーザとタクシーとの取引仲介システムに係る技術であることから、本件発明及び乙２４発明と技術分野を同一とする。 そうすると、乙２０や乙２１の記載事項を乙２４発明に適用して、ユーザデバイス108が、迎車場所やリクエストの日時に加えて、タクシーの検索距離範囲に係る情報をタクシー配車サーバ102に送信することは、その発明の属する技術の分野における通常の知識を有する者が容易に推考し得るものである。 迎車場所やリクエストの日時に加えて、タクシーの検索距離範囲に係る情報をタクシー配車サーバ102に送信することは、その発明の属する技術の分野における通常の知識を有する者が容易に推考し得るものである。 (4) 小括 以上のとおり、相違点は当業者が容易に推考し得るものであり、また、本件発明により得られる作用効果も、乙２４発明並びに乙２０及び乙２１の各記載事項から予測し得る範囲内のものであり、格別な作用効果を奏するものとはいえない。あるいは、原告らの主張を前提とすれば、本件発明と乙２４発明に相違点はない。 したがって、本件特許は、乙２４発明並びに乙２０及び乙２１の各記載事項に基づいて、当業者が特許出願前に容易に発明をすることができたものであるか、又は、乙２４に開示されており、特許出願前に公然知られた発明であるから、進歩性又は新規性を欠く。 ７ 乙２５発明を主引用例とする進歩性欠如（争点４－７）について (1) 乙２５発明 乙２５には、次の乙２５発明が開示されている（構成Ａ等の呼称の内容は、争点４－７の範囲内のものである。）。 ア構成Ａ：通信網１０２ａ～ｃにそれぞれ接続可能な、顧客端末１０５と、タクシー端末１０４と、タクシー配車センター１０１と、タクシー会社のホストコンピュータ１０３と、を備え、 イ構成Ｂ’’’：顧客端末１０５は、顧客の操作により、通信網１０２ａ～ｃを介してタクシー配車センター１０１にアクセスし、ＧＰＳによって特定した自端末の位置情報を送信し、ウ構成Ｃ：タクシー配車センター１０１からのタクシーの位置情報を確認可能とし、タクシーの位置情報の中から顧客が希望するタクシーを選択したこ とを示すタクシー選択情報を、第３通信網１０２ｃを介して、タクシー端末１０４、タク １０１からのタクシーの位置情報を確認可能とし、タクシーの位置情報の中から顧客が希望するタクシーを選択したこ とを示すタクシー選択情報を、第３通信網１０２ｃを介して、タクシー端末１０４、タクシー配車センター１０１及びタクシー会社のホストコンピュータ１０３に共有し得るように送信し、エ構成Ｄ：タクシー端末１０４からの配車了解信号を確認可能とし、オ構成Ｆ：タクシー端末１０４は、通信網１０２を介してタクシー配車セン ター１０１にアクセスし、かつＧＰＳ受信機によって得られた位置情報をタクシー配車センター１０１に送信し、カ構成Ｇ：顧客端末１０５からの配車要求信号に応答して配車了解信号を、第３通信網１０２ｃを介して、タクシー端末１０４、タクシー配車センター１０１及びタクシー会社のホストコンピュータ１０３に共有し得るように 送信し、キ構成Ｈ：タクシー配車センター１０１は、顧客端末１０５から送信された顧客の位置情報を受信し、タクシー端末１０４から送信されたタクシーの位置情報を受信してタクシー位置情報データベース２０３に登録し、顧客端末１０５からの配車要求信号、タクシー端末１０４からの配車了解信号を受信 し、 ク構成Ｉ：顧客端末１０５から位置情報を受信したとき、タクシー位置情報データベース２０３を確認して顧客の近くに存在するタクシーの地図情報を顧客端末１０５に送信し、ケ構成Ｊ：タクシー端末１０４から配車了解信号を受信したとき、顧客の位置情報をタクシー端末１０４に送信し、 コ構成Ｋ：タクシー会社のホストコンピュータ１０３は、第３通信網１０２ｃを介して、タクシー端末１０４、タクシー配車センター１０１及び顧客端末１０５と接続される、サ構成Ｌ：タクシー配車システム。 (2 シー会社のホストコンピュータ１０３は、第３通信網１０２ｃを介して、タクシー端末１０４、タクシー配車センター１０１及び顧客端末１０５と接続される、サ構成Ｌ：タクシー配車システム。 (2) 本件発明と乙２５発明との対比 本件発明と乙２５発明は、構成Ａ、Ｃ、Ｄ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌにおいて一致する一方で、以下の点において相違する。 ア相違点１：「顧客側が配車要求時に送信する情報」について、本件発明では「タクシーの迎車位置とタクシー移動端末との距離範囲に係るタクシー選択範囲情報」を送信するが、乙２５発明では「ＧＰＳによって特定した自端 末の位置情報」を送信する点。 イ相違点２：「顧客がタクシーに乗車したときに送信する乗車完了に係る情報」について、本件発明では「ユーザ端末が乗車完了情報をアプリ管理サーバ及びタクシー事業者端末に通知」するが、乙２５発明では、顧客が乗車完了した際に送信する情報について記載されていない点。 (3) 容易想到性ア相違点１について前記の乙２０の記載事項は、タクシーの配車運用システムに係る技術であり、乙２１の記載事項は、ユーザとタクシーとの取引仲介システムに係る技術であることから、本件発明及び乙２５発明と技術分野を同一とする。 そうすると、乙２０や乙２１の記載事項を乙２５発明に適用して、顧客側 端末２が空車タクシー呼び寄せ用アプリを起動したときに、顧客の現在位置情報に係る情報に加えて、タクシーの検索距離範囲に係る情報を制御サーバ１０に送信することは、その発明の属する技術の分野における通常の知識を有する者が容易に推考し得るものである。 イ相違点２について 前記の乙２２の記載事項は、タクシーの配車に係る経路を通知するシステムに係る技術で の発明の属する技術の分野における通常の知識を有する者が容易に推考し得るものである。 イ相違点２について 前記の乙２２の記載事項は、タクシーの配車に係る経路を通知するシステムに係る技術であり、乙２３の記載事項は、タクシーの配車管理システムに係る技術である。 そうすると、乙２２や乙２３の記載事項を乙２５発明に適用して、顧客がタクシーに乗車したときに、乗車完了に係る情報を顧客側端末２が制御サー バ１０に送信することは、その発明の属する技術の分野における通常の知識を有する者が容易に推考し得るものである。 そして、仮に、本件特許が前記４の補正要件を満たすことを前提とすると、通知の態様は当業者において適宜調整可能なものであるため、上記のことから、ユーザ端末が乗車完了に係る情報をアプリ管理サーバに通知することも、 その発明の属する技術の分野における通常の知識を有する者が容易に推考し得るものである。 (4) 小括以上のとおり、相違点１及び２はいずれも当業者が容易に推考し得るものであり、また、本件発明により得られる作用効果も、乙２５発明及び乙２０ない し乙２３の各記載事項から予測し得る範囲内のものであり、格別な作用効果を奏するものとはいえない。 したがって、本件特許は、乙２５発明及び乙２０ないし乙２３の各記載事項に基づいて、当業者が特許出願前に容易に発明をすることができたものであるから、進歩性を欠く。 以上 （別紙）争点５に関する原告らの主張 １ 被告による本件特許権の実施被告は、遅くとも令和４年４月から令和５年１２月末までの間、被告製品を使用していた。 ２ 被告製品を使用することによる被告の売上額被告の令和５年３月度決算の売上高は２０億１１００億円である。 被告の事 も令和４年４月から令和５年１２月末までの間、被告製品を使用していた。 ２ 被告製品を使用することによる被告の売上額被告の令和５年３月度決算の売上高は２０億１１００億円である。 被告の事業は、専ら被告製品に関するものであるが、他事業の売上を考慮して１０パーセントを減額すると、被告製品を使用することによる被告の年間売上額は１８億０９９０万円となる。 ３ 特許法１０２条３項に基づき算定される損害額(1) 原告会社の損害額本件発明の効果等に照らせば、その実施手数料は、被告の売上額の１０パーセントを下回ることはないから、原告らの年間損害額は１億８０９９万円である。 そうすると、令和４年４月から、原告会社が本件特許権を保有していた令和５年１１月２１日までの損害額は、２億９７１９万９４２６円（１億８０９９万円＋１億８０９９万円×２３５日／３６６日）となる（１円未満四捨五入、以下同じ。）。 (2) 原告Ａの損害額 令和５年１１月２２日から同年１２月３１日までの損害額は、１９７８万０３２８円（１億８０９９万円×４０日／３６６日）となる。 ４ 弁護士費用被告に対し、上記の損害の賠償を求めるために必要な弁護士費用は、原告会社につき２９００万円、原告Ａにつき１９０万円を下らない。 ５ 合計 よって、原告会社は３億２６１９万９４２６円の、原告Ａは２１６８万０３２８円の損害賠償を、被告に対してそれぞれ求める。 以上
▼ クリックして全文を表示