令和８年（ネ）第１０００７号損害賠償請求控訴事件
（原審・大阪地方裁判所令和６年（ワ）第７０５５号）
口頭弁論終結日令和８年４月２０日
判決
控訴人Ｘ
控訴人ベスト交通株式会社
上記両名訴訟代理人弁護士澤田昌孝
同訴訟代理人弁理士板谷康夫
被控訴
人ＤｉＤｉモビリティジャパン
株式会社
同訴訟代理人弁護士松田誠司
同高橋宗鷹
同大出萌
同遠藤祥史
同土居大起
主文
１ 本件各控訴をいずれも棄却する。
２ 控訴費用は、控訴人らの負担とする。
事実及び理由
本判決において用いる略語の定義は、別に定めるほか、原判決の例による。
第１ 控訴の趣旨
１ 原判決を取り消す。
２ 被控訴人ＤｉＤｉモビリティジャパン株式会社（以下「被告」という。）は、控訴人ベスト交通株式会社（以下「原告会社」という。）に対し、３億２６１９万９４２６円及びこれに対する令和６年７月２５日から支払済みまで年３％の割合による金員を支払え。
３ 被告は、控訴人Ｘ（以下「原告Ａ」という。）に対し、２１６８万０３２８円及びこれに対する令和６年７月２５日から支払済みまで年３％の割合による金員を支払え。
第２ 事案の概要
１⑴本件は、本件特許権の特許権者である原告らが、被告製品は本件発明の技術的範囲に属し、被告による被告製品の使用は本件特許権を侵害するなどと主張して、被告に対し、民法７０９条に基づき、原告会社につき、３億２６１９万９４２６円（実施手数料相当額２億９７１９万９４２６円、弁護士費用２９００万円）及びこれに対する令和６年７月２５日（訴状送達日の翌日）から、原告Ａにつき、２１６８万０３２８円（実施手数料相当額１９７８万０３２８円、弁護士費用１９０万円）及びこれに対する同日から各支払済みまで同法所定の年３％の割合による遅延損害金の支払を求める事案である。⑵原審は、被告製品は、少なくとも、本件発明の構成要件の一部を充足せず、その一部につき均等侵害は成立しないとして、原告らの請求をいずれも棄却し、原告らは、これを不服として本件各控訴を提起した。
２ 前提事実、争点、争点に関する当事者の主張は、次のとおり補正ないし補充するほかは、原判決「事実及び理由」欄の「第２事案の概要」の３及び４（原判決３頁１７行目から８頁１８行目まで）並びに「第３争点に関する当事者の主張」の１から１２まで（同頁２０行目から２２頁１７行目まで）に記載のとおりであるから、これを引用する。
⑴原判決１０頁２３行目の「むしろ、」の次に「本件明細書に「半径範囲が拡大すれば…選択肢は増える」（【００１８】）と記載され、ユーザの選択肢を充実させるという本件発明の本来の意図が示されていることに照らすと、時間的範囲等の情報も、ユーザの選択肢を増やし、ユーザによる実質的かつ公平なタクシーの選択を可能にするための情報として「タクシー選択範囲情報」に含まれると解釈するのが合理的である。また、」を加え、１１頁８行目の「時間的基準」から９行目の「（目的地情報に基づく営業区域）の」までを「ユーザが「今すぐ出発」ボタンを押し、あるいは具体的な出発希望時刻を指定することにより、また、ユーザが事前に目的地情報を入力することにより、時間的基準（タクシーが迎車依頼地に到着するまでに要する時間の範囲を設定する情報）及び地理的基準（目的地情報に基づく営業区域に係る情報）の」に改める。
⑵原判決１１頁１５行目の「参酌すれば」を「参酌し、併せて、①「タクシー選択範囲情報」は、ユーザ主導の配車決定プロセスにおいて、候補車両を地理的に絞り込むための入力情報として位置付けられるものであり、本件明細書には距離的範囲以外の情報による配車決定プロセスは一切記載されていないこと、②移動端末情報データベースには、ポーリングにより取得されたタクシーの位置情報が登録されるのであり（構成要件Ｆ、Ｈ）、アプリ管理サーバが「タクシー選択範囲情報を受信したとき、…移動端末情報データベースを確認してユーザ希望の範囲に存在する…タクシー情報を…ユーザ端末に通知し」との構成（構成要件Ｉ）は、ユーザ希望の範囲に存在するタクシーの抽出が、「タクシー迎車依頼地情報」とタクシーの「位置情報」との距離的対比によって行われることを前提とするものであることをも考慮すると」に改める。
⑶原判決１２頁２１行目末尾を改行の上、次のとおり加える。
「被告は、被告製品ではアプリ管理サーバがＡＩマッチング機能に基づき配車車両を選定している旨の主張をするが、被告製品にＡＩマッチング機能が付加されていたとしても、ユーザが「タクシー事業者（タクシー会社）」を指定したことに変わりはない。上記のマッチング処理は、「タクシー情報」をユーザ端末に通知し（構成要件Ｉ）、ユーザが希望する「タクシー事業者（タクシー会社）」を指定した後に、「タクシー迎車依頼地情報」及びタクシーの「位置情報」を参照して行われるにすぎず、アプリ管理サーバがＡＩマッチング機能に基づき配車車両を選定していることにより、被告製品が構成要件Ｃを充足することが否定されるものではない。
被告は、本件訴訟の係属中に、被告アプリの「タクシー会社表示機能」及び「ユーザによるタクシー会社選択機能」を削除しているのであり、これは、被告において、被告製品が構成要件Ｃを充足することを認識していた証左というべきである。」
⑷原判決１３頁１行目から２行目にかけての「本件明細書」の次に「【００１９】（「画面に表示される候補のタクシー情報には、選択タクシー会社、料金体系、車種、宣伝文等を含ませることができる。」）、」を加え、３行目から４行目にかけての「記載に照らすと」を「記載に加え、本件発明において、ユーザが配車される特定の車両を決定することは、その本質的かつ必須の構成要件であり、本件明細書にも、本件発明の効果として、「…ユーザが最終的に配車決定するようにしている…」（【００１１】）と記載されていることに照らすと」に改める。
⑸原判決１３頁２２行目の「また、」を「そして、被告製品では、配車が決定した場合、ユーザ端末に、車両番号、車種、乗務員姓、車両位置情報、予想到着時刻が表示され、ユーザの希望した配車が完了したこと、すなわち「迎車可否情報」が示されるのであるから、被告製品は、構成要件Ｄを充足する。」に改める。
⑹原判決１４頁６行目の「と規定しているところ」を「との構成を特定するのであるから、かかる構成は、ユーザ端末がタクシー移動端末から迎車可否情報を直接受信し、確認可能とすることを示すものと解すべきである。しかるに」に改める。
⑺原判決１４頁２２行目を次のとおり改める。
「以上のとおり、被告製品は、実質的にユーザ端末からの配車確認要求を起点として、タクシー移動端末がこれに応答し、その結果である「迎車可否情報」を、アプリ管理サーバを介して、ユーザ端末及びタクシー事業者端末から確認可能な状態にし、「共有し得るように通知」するのであるから、構成要件Ｇを充足する。」
⑻原判決１７頁２２行目の「原告らが」を「そもそも、原告らは、①本件発明が「前記タクシー移動端末からの迎車可否情報を確認可能とし、」との構成（構成要件Ｄ）を備えるのに対し、被告製品はこれに対応する機能を備えない点、②本件発明が「前記ユーザ端末からの前記配車確認要求に応答して前記迎車可否情報を前記ユーザ端末、前記アプリ管理サーバ及び前記事業者端末に共有し得るように通知し、」との構成（構成要件Ｇ）を備えるのに対し、被告製品はこれを備えない点について、均等侵害の成立を主張するものではないし、これを措くとしても、原告らが」に改める。
第３ 当裁判所の判断
１ 当裁判所も、原告らの請求に理由はなく、本件各控訴はいずれも棄却すべきものと判断する。その理由は、次のとおり補正ないし補充するほかは、原判決の「事実及び理由」欄の「第４判断」の２から６まで（原判決２２頁２６行目から２９頁２５行目まで）に記載のとおりであるから、これを引用する。⑴原判決２３頁１行目の「本件明細書には、次の記載がある。」を「本件明細書の記載は原判決別紙「特許公報」のとおりであり、これには次の記載がある。」に改める。
⑵原判決２５頁１２行目から１３行目にかけての「タクシーの配車管理システムにおいて、」の次に「タクシーの選択肢が少なく、ユーザの希望を満足し得るように迅速かつ能率良くタクシーを配車することが困難であったこと、」を加える。
⑶原判決２６頁１０行目から２３行目までを次のとおり改める。「ア「タクシー情報」の意義
「タクシー」は、「貸切の営業用自動車」（乙３）、「一般乗用旅客自動車運送事業」（甲３５～３８、甲５５、５６）等の意味を有する多義的な語であり、特許請求の範囲の記載のみから「タクシー情報」の意義が一義的に定まるものではないものの、本件明細書に、「ユーザ端末…の配車アプリが起動されると、その端末画面には、…配車アプリの表示に続いて、タクシー選択範囲情報として、現在地より半径５００ｍ以内、８００ｍ以内、１２００ｍ以内、１５００ｍ以内の表示がされる。半径範囲が拡大すれば呼べるタクシー車両の数が増え、選択肢は増える。」（【００１８】）、「ユーザ端末…操作により、いずれかの範囲を選択すると、…アプリ管理サーバ…は常時登録保有している移動端末情報の中から自動で選択範囲内の配車可能なタクシーを全て選択し、タクシー情報結果をユーザ端末…に通知する。」（【００１９】）と、配車手順につき「ユーザ端末…から依頼地入力と範囲５００ｍでのタクシー選出依頼を行う…。…上記の選出依頼に応答して、アプリ管理サーバ…のシステム制御機…は、移動端末情報データベース…に車両の位置情報確認要求をし、その結果を貰い、情報結果…をユーザ端末…に通知する…。情報結果とは、ユーザ希望の範囲に存在するタクシー情報であり、この情報には、タクシー事業者名、料金、車種等が含まれる。」（【００２８】）、「ユーザ端末…から依頼地入力と範囲８００ｍでのタクシー選出依頼を行う…。すると、…アプリ管理サーバ…は情報結果（車両１、２、４、５）をユーザ端末…に通知する。」（【００２９】）、「迎車否を受信したユーザは、ユーザ端末…から依頼地入力と範囲１０００ｍでのタクシー選出依頼を行う。すると、…アプリ管理サーバ…は情報結果（車両１、２、３、４、５、６）をユーザ端末…に通知する。」（【００３１】）と記載され、さらに、配車アプリによる配車依頼時のユーザ端末の画面に、ユーザが選択した距離範囲内に存在するタクシー車両の情報が表示される構成も示されていて（本件明細書【図２】）、現在地（タクシー迎車依頼地）からの半径範囲が拡大するほど、配車可能なタクシー車両の数が増え、ユーザの選択肢が増えることが技術的思想として開示されていることを考慮すると、「タクシー選択範囲情報」の意義は、ユーザがタクシー車両を選択するための「タクシー迎車依頼地からの距離的範囲を設定する情報」であり、「タクシー情報」の意義は、「タクシー選択範囲情報」に基づき「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシー車両の情報」と解釈するのが相当である。
イ 「配車確認要求」の意義
構成要件Ｃにおいて、「配車確認要求」は「タクシー情報の中からユーザが希望するタクシーを指定した」ものであることが特定されている。そして、前記のとおり、「タクシー情報」は「タクシー選択範囲情報」に基づき「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシー車両の情報」と解釈するのが相当であることに加え、本件明細書に「ユーザは、ユーザ端末…の画面に表示された受信情報結果を見て、気に入ったタクシーがあれば、それを選択すると、…その情報すなわち、配車確認要求は、アプリ管理サーバ…、該当するタクシー移動端末…、及びタクシー事業者端末…に同報送信される。」（【００２０】）と記載され、配車手順につき「いま、ユーザが車両２を気に入ったとして、それを指定した配車確認要求をユーザ端末…より送信する…。この配車確認要求は、車両２のタクシー移動端末…、アプリ管理サーバ…及びタクシー事業者端末…に同報送信される。ここで、車両２の乗務員が何らかの都合で、迎車否を送信したとする…。この情報は、ユーザ端末…、アプリ管理サーバ…及びタクシー事業者端末…に同報送信される。」（【００３０】）などと記載されていることを考慮すると、「配車確認要求」の意義は、「ユーザが選択した距離範囲内に存在する全てのタクシー車両を示す情報の中から、ユーザの希望するタクシー車両を指定して行う迎車の可否の確認要求」と解釈するのが相当である。」
⑷原判決２６頁２５行目から２７頁６行目までを次のとおり改める。「前記のとおり、構成要件Ｃの「タクシー情報」の意義は、「タクシー選択範囲情報」に基づき「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシー車両の情報」と、「配車確認要求」の意義は、「ユーザが選択した距離範囲内に存在する全てのタクシー車両を示す情報の中から、ユーザの希望するタクシー車両を指定して行う迎車の可否の確認要求」とそれぞれ解釈するのが相当であるところ、被告製品は、原判決「事実及び理由」欄の「第２事案の概要」の３⑷に記載のとおり、ユーザが、被告アプリの③Ａ画面に表示された複数の「タクシー会社」の中から、その希望する「タクシー会社」を指定する構成であり、「タクシー情報」、すなわち「タクシー選択範囲情報」に基づき「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシー車両の情報」を確認可能とする構成でも、「配車確認要求」、すなわち「ユーザが選択した距離範囲内に存在する全てのタクシー車両を示す情報の中から、ユーザの希望するタクシー車両を指定して行う迎車の可否の確認要求」をタクシー移動端末、アプリ管理サーバ及びタクシー事業者端末に共有し得るように通知する構成でもないことから、被告製品の備えるＡＩマッチング機能によるマッチング処理の実施形態や、被告が被告アプリの「タクシー会社表示機能」及び「ユーザによるタクシー会社選択機能」を削除した経緯につき認定判断するまでもなく、構成要件Ｃを充足しない。」⑸原判決２７頁１８行目の「しかし」から１９行目の「前記のとおりであるし」までを「しかしながら、本件明細書の記載及び図面を考慮すると、構成要件Ｃの「タクシー情報」の意義は、「タクシー選択範囲情報」に基づき「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシー車両の情報」と解釈されることは、前記のとおりであるし」に改める。⑹原判決２８頁１１行目から２１行目までを次のとおり改める。「しかしながら、本件発明は、従来の「複数のタクシー会社の中から任意にタクシー会社を選択できる複数のタクシー事業者対象のシステム」では、「一つのシステム上で複数のタクシー会社が稼働するものではなく、…結局は一社の中での選択となり」、「タクシー選択肢が少なく、ユーザの希望を満足し得るように迅速かつ能率良くタクシーを配車することは困難であった」（【０００２】）こと、また、従来技術では、ユーザの意思で複数の車両を指定し、その情報を配車管理装置に送信すると、その指定された車両の中から配車管理装置が配車の可能可否確認を行い、その結果で配車車両を決定するため、実質、車両を決定するのはユーザではなく配車管理装置側となり、公平性に難があること（【０００６】）から、ユーザ端末から、アプリ管理サーバにタクシー迎車依頼地情報と「タクシー選択範囲情報」を送信し（構成要件Ｂ）、アプリ管理サーバからの「タクシー情報」を確認可能とし（構成要件Ｃ）、「タクシー情報」の中からユーザが希望するタクシーを指定した「配車確認要求」をタクシー移動端末、アプリ管理サーバ及びタクシー事業者端末に共有し得るように通知し（構成要件Ｃ）、タクシー移動端末からの迎車可否情報を確認可能（構成要件Ｄ）とする構成を採用することにより、タクシー車両の選択肢を増やすとともに、「…ユーザ端末…つまりユーザが常に情報の送受信の中心にいて、ユーザの意思で配車を決定することができ」（【００３４】）、タクシー事業者間の「情報の公平性・透明性を保」つこと（【００１１】）ができるようにしたのであり、そうすると、ユーザ端末から、「タクシー選択範囲情報」に基づき「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシー車両の情報」である「タクシー情報」を確認可能とし、「タクシー情報」の中からユーザが希望するタクシーを指定した「配車確認要求」をタクシー移動端末、アプリ管理サーバ及びタクシー事業者端末に「共有し得るように通知」する構成は、従来技術に見られない本件発明の本質的部分というべきである。
したがって、ユーザが、被告アプリの③Ａ画面に表示された複数の「タクシー会社」の中から、その希望する「タクシー会社」を指定する構成である被告製品は、本件発明の本質的部分において相違するというべきであるから、均等侵害の第１要件を充足しない。」
⑺原判決２９頁１０行目の「構成要件Ｃの「配車確認要求」は」から１１行目の「解されるところ」までを「前記のとおり、構成要件Ｃの「配車確認要求」の意義は、「ユーザが選択した距離範囲内に存在する全てのタクシー車両を示す情報の中から、ユーザの希望するタクシー車両を指定して行う迎車の可否の確認要求」と解釈するのが相当であるところ」に改める。⑻原判決２９頁１６行目から１７行目にかけての「個々の車両の情報と」を「「タクシー選択範囲情報」に基づき「ユーザが選択した距離範囲内に存在する配車可能な全てのタクシー車両の情報」と」に改める。
第４ 結論
以上によれば、被告製品は、少なくとも、構成要件Ｃ、Ｇ、Ｉ、Ｋを充足せず、加えて、均等の相違点２について均等侵害も成立しないから、その余の点について判断するまでもなく、原告らの請求はいずれも理由がない。よって、原判決は相当であるから、本件各控訴をいずれも棄却することとして、主文のとおり判決する。
知的財産高等裁判所第２部
裁判長裁判官
森冨義明
裁判官
菊池絵理
裁判官
天野研司
出典：裁判所ウェブサイト「裁判例検索」（https://www.courts.go.jp/hanrei/96759/detail8/index.html）。本文は同サイト掲載の判決書PDFからTaiLexi AIがテキスト化・整形したもの（正確な文言は原本PDFを参照）。判示事項・裁判要旨・参照法条は裁判所の公表どおり。