JP7356822B2 - 遅延交渉の要否判断方法、遅延交渉の要否判断装置、及び遅延交渉の要否判断システム - Google Patents

Description

本発明は、遅延交渉の要否判断方法、遅延交渉の要否判断装置、及び遅延交渉の要否判断システムに関する。

従来より、タクシー運用を効率化する発明が知られている（特許文献１）。特許文献１に記載された発明では、タクシーが顧客（以下、第１ユーザと称する）を乗せて賃走しているときに、別の顧客（以下、第２ユーザと称する）の配車要求を受けた場合、第１ユーザの降車位置を第２ユーザの乗車場所に近付けるためのネゴシエーションが行われる。ネゴシエーションの一例として、第１ユーザに対して、タクシー料金の引き下げが提示される。

特開２０１３－１８２５９７号公報

タクシー運用の効率（タクシーに限定されず、自家用車などを含むいわゆるライドシェアリングの効率）を考えた場合、特許文献１に記載された発明では、運用を効率化できるものの、必ず交渉が発生してしまう。このような交渉は、ゆっくり乗車したい第１ユーザにとっては煩わしく、一方、第２ユーザにとっては、予約を即座に確定できず煩わしい場合がある。

本発明は、上記問題に鑑みて成されたものであり、その目的は、不要な交渉を省略できる遅延交渉の要否判断方法、遅延交渉の要否判断装置、及び遅延交渉の要否判断システムを提供することである。

本発明の一態様に係る要否判断方法は、車両が、目的地に到着する第１経路を走行した場合の目的地までの第１移動時間を算出し、車両が、経由地を経由して目的地に到着する第２経路を走行した場合の目的地までの第２移動時間を算出し、第２移動時間から第１移動時間を減算した遅れ時間に基づいて、第１ユーザ及び第２ユーザと通知する必要があるか否かを判断する。

本発明によれば、不要な交渉を省略できる。

図１は、本発明の実施形態に係るシステムの全体概略図である。 図２は、本発明の実施形態に係るコンピュータ、タクシー、及び端末装置の機能ブロック図である。 図３は、本発明の実施形態に係る経由地を経由しない経路を説明する図である。 図４は、本発明の実施形態に係る経由地を経由する経路を説明する図である。 図５は、本発明の実施形態に係るユーザのインセンティブ特性を説明する図である。 図６は、本発明の実施形態に係る他のユーザのインセンティブ特性を説明する図である。 図７は、本発明の実施形態に係る交渉の要否の判断方法の一例を説明する図である。 図８は、本発明の実施形態に係る交渉の要否の判断方法の他の例を説明する図である。 図９は、本発明の実施形態に係る交渉の要否の判断方法のさらに他の例を説明する図である。 図１０は、本発明の実施形態に係るコンピュータの一動作例を説明するフローチャートである。 図１１は、本発明の実施形態に係るコンピュータの一動作例を説明するフローチャートである。 図１２は、本発明の実施形態に係る経由地を経由する経路の他の例を説明する図である。 図１３は、本発明の実施形態に係る経由地を経由する経路のさらに他の例を説明する図である。

以下、本発明の実施形態について、図面を参照して説明する。図面の記載において同一部分には同一符号を付して説明を省略する。

（システムの構成例）
図１～２を参照して、本実施形態に係るシステム１０の構成例を説明する。本実施形態に係るシステム１０は、タクシーの配車に用いられ、特に、ユーザＸ（第１ユーザ）から目的地においてタクシーに乗車又はタクシーから降車するリクエストを受け付けた後に、ユーザＹ（第２ユーザ）からユーザＸの目的地とは異なる経由地においてタクシーに乗車又はタクシーから降車するリクエストを受け付けた場合において、タクシーが目的地まで移動する時間の遅れに関し、ユーザＸ及びユーザＹと交渉（遅延交渉）する必要があるか否かの判断に用いられる。ただし、本発明は、タクシーに限定されず、車両全般に適用可能である。例えば、本発明は、自家用車にも適用可能である。

本実施形態において、目的地とは、ユーザＸが希望する乗車場所、もしくは、ユーザＸが希望する降車場所を意味する。また、本実施形態において、経由地とは、目的地とは異なる場所であって、ユーザＹが希望する乗車場所、もしくは、ユーザＹが希望する降車場所を意味する。

図１に示すように、システム１０は、コンピュータ２０と、通信ネットワーク３０と、タクシー４０～４２と、ユーザＸと、ユーザＸが保持する端末装置６０と、ユーザＹと、ユーザＹが保持する端末装置６１とを含む。なお、図１において、タクシーは３台存在するが、これに限定されない。システム１０は、４台以上のタクシーを含んでもよい。また、図１において、ユーザは二人であるが、図示しない多数のユーザが存在する。図示しない多数のユーザも、ユーザＸ及びユーザＹと同様に端末装置を所持する。

コンピュータ２０は、通信ネットワーク３０を介してタクシー４０～４２及び端末装置６０～６１と通信する。コンピュータ２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１と、メモリ２２と、通信Ｉ／Ｆ２３と、ストレージ２４とを備え、これらの構成要素が図示しないバスなどを介して電気的に接続されている。コンピュータ２０の設置場所は特に限定されないが、例えばコンピュータ２０はタクシー４０～４２を運用する会社に設置される。

ＣＰＵ２１は、ストレージ２４などに記憶されている様々なプログラムをメモリ２２に読み込んで、プログラムに含まれる各種の命令を実行する。メモリ２２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの記憶媒体である。ストレージ２４は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶媒体である。なお、以下で説明するコンピュータ２０の機能を含むシステム１０の一部（または全部）は、通信ネットワーク３０上に配置されたアプリケーション（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）など）によって提供されてもよい。また、コンピュータ２０は、サーバであってもよい。

通信Ｉ／Ｆ２３は、ネットワークアダプタなどのハードウェア、各種の通信用ソフトウェア、及びこれらの組み合わせとして実装され、通信ネットワーク３０などを介した有線または無線の通信を実現できるように構成されている。

通信ネットワーク３０は、無線または有線の何れかの方式、あるいは両方の方式によって構成されてもよく、通信ネットワーク３０には、インターネットが含まれてもよい。本実施形態では、コンピュータ２０、タクシー４０～４２、及び端末装置６０～６１は、無線通信方式によって通信ネットワーク３０と接続する。

本実施形態において、タクシー４０～４２は、運転者が存在しない自動運転車両として説明する。したがって、タクシー４０～４２は、ロボットタクシーまたは無人タクシーと表現されてもよい。ただし、タクシー４０～４２は、自動運転車両に限定されず、自動運転機能を有しない通常のタクシーであってもよい。あるいは、タクシー４０～４２は、自動運転と手動運転とを切り替えることが可能なタクシーであってもよい。

ユーザＸは、端末装置６０を用いてタクシーをリクエスト（予約）する。端末装置６０には、タクシーの予約に用いられる配車アプリケーション（以下単に配車アプリと称する）がインストールされており、ユーザＸは、配車アプリを使ってタクシーをリクエストする。ユーザＹも同様に、端末装置６１を用いてタクシーをリクエストする。このようなタクシーのリクエストを、以下では配車要求と称する場合がある。

次に、図２を参照して、コンピュータ２０、タクシー４０、端末装置６０の詳細について説明する。なお、図２において、タクシー４１～４２、及び端末装置６１は省略するが、タクシー４１～４２はタクシー４０と同様の構成を有し、端末装置６１は端末装置６０と同様の構成を有する。

端末装置６０は、通信Ｉ／Ｆ６０１と配車アプリ６０２を備える。通信Ｉ／Ｆ６０１は、通信Ｉ／Ｆ２３と同様の構成を備えており、通信ネットワーク３０を介してコンピュータ２０と通信する。端末装置６０は、例えば、スマートフォン、タブレット端末、ウェアラブル端末などである。なお、端末装置６０は、デスクトップパソコンなどの据え置き型の汎用コンピュータであってもよい。

配車アプリ６０２は、上述したようにタクシーのリクエストに用いられる。配車アプリ６０２は、ユーザＸがタクシーをリクエストする際のユーザインタフェースとして機能する。配車アプリ６０２は、端末装置６０に設けられたＣＰＵが、端末装置６０に設けられたストレージから、専用のアプリケーションプログラムを読み出して実行することで実現する。ユーザＸがタクシーをリクエストする際、ユーザＸは希望する乗車場所、希望する乗車時間、希望する降車場所を配車アプリ６０２に入力し、タクシーをリクエストする。配車アプリ６０２（端末装置６０）は、ユーザＸの入力に従って、コンピュータ２０に配車要求を送信する。また、端末装置６０は、配車要求に対してコンピュータ２０から返信される信号に含まれる各種情報（配車要求受領、到着予定時刻、走行予定経路など）を、端末装置６０が備えるディスプレイ上に表示する。ただし、配車アプリ６０２の実現方法は、これに限定されない。例えば、端末装置６０が、配車アプリ６０２の機能を提供するサーバにアクセスして機能提供を受け、サーバから送信される機能の実行結果をブラウザに表示するようにしてもよい。

コンピュータ２０のＣＰＵ２１は、図２のブロック図に示すように、複数の機能の一例として、配車受付部２１１と、割当部２１２と、移動時間算出部２１３と、遅れ時間算出部２１４と、交渉要否判断部２１５とを備える。コンピュータ２０のストレージ２４には、図２のブロック図に示すように、設定データベース２４１及び顧客データベース２４２が格納されている。

配車受付部２１１は、ユーザＸからのリクエストを、端末装置６０を介して受け付ける。また、配車受付部２１１は、ユーザＸからのリクエストを受け付けた旨、乗車場所への到着予定時刻、乗車場所への走行予定経路など端末装置６０に通知する機能を有する。また、配車受付部２１１は、ユーザＹからのリクエストを、端末装置６１を介して受け付ける。

割当部２１２は、受け付けたリクエストに基づいて、複数のタクシー４０～４２の中から適切なタクシーを割り当てる。例えば、割当部２１２は、効率化のために、複数のタクシー４０～４２の中から、ユーザＸが希望する乗車場所に最も近い空車のタクシー４０を割り当てることができる。なお、各タクシー４０～４２には、ＧＰＳ受信機が設置されており、タクシー４０～４２の位置情報は、任意のタイミングでコンピュータ２０に送信されるものとする。割当部２１２は、タクシー４０の現在地からユーザＸが希望する乗車場所までの経路を設定し、設定した経路に沿ってユーザＸが希望する乗車場所まで走行するようにタクシー４０に対して指令を送る。

タクシー４０は、通信Ｉ／Ｆ４０１と車両ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）４０２を備える。通信Ｉ／Ｆ４０１は、通信Ｉ／Ｆ２３及び通信Ｉ／Ｆ６０１と同様の構成を備えており、通信ネットワーク３０を介してコンピュータ２０と通信する。車両ＥＣＵ４０２は、タクシー４０を制御するためのコンピュータである。車両ＥＣＵ４０２は、システム１０からの指令に基づいて各種のアクチュエータ（ブレーキアクチュエータ、アクセルアクチュエータ、ステアリングアクチュエータなど）を制御する。

移動時間算出部２１３は、タクシー４０が、タクシー４０の現在地からユーザＸが希望する乗車場所に到着するまでに要する移動時間を算出する。移動時間算出部２１３は、タクシー４０の現在地からユーザＸが希望する乗車場所までの距離を、平均車速で除算することによって移動時間を算出する。

遅れ時間算出部２１４は、タクシー４０が、経由地を経由してユーザＸが希望する乗車場所に到着する場合の、遅れ時間を算出する。本実施形態では、配車受付部２１１がユーザＸのリクエストを受け付けた後、ユーザＹのリクエストを受け付けた場合を想定する。ユーザＹが希望する乗車場所と、タクシー４０の現在地とが近い場合、ユーザＹを乗車させるタクシーとして、タクシー４０が効率的と判断される場合がある。このような場合、タクシー４０はユーザＹを乗車させるために、ユーザＸが希望する乗車場所に向かう経路を変更し、ユーザＹが希望する乗車場所に向かう。タクシー４０はユーザＹを乗車させた後に、ユーザＸが希望する乗車場所に向かう。このようにタクシー４０が経由地を経由してユーザＸが希望する乗車場所に向かう場合、ユーザＸが希望する乗車場所に到着する時間が遅れることになる。遅れ時間算出部２１４は、このような遅れ時間を、移動時間算出部２１３によって算出された移動時間を用いて算出する。移動時間算出部２１３は、タクシー４０が経由地を経由せずにユーザＸが希望する乗車場所に到着する経路を走行した場合の乗車場所までの第１移動時間を算出する。次に、移動時間算出部２１３は、経由地を経由して乗車場所に到着する経路を走行した場合の乗車場所までの第２移動時間を算出する。遅れ時間算出部２１４は、第２移動時間から第１移動時間を減算することによって、遅れ時間を算出する。なお、ユーザＹを乗車させるための経路の変更は、割当部２１２によって実行される。

交渉要否判断部２１５は、遅れ時間算出部２１４によって算出された遅れ時間に基づいて、ユーザＸ及びユーザＹと交渉が必要か否かを判断する。ここで交渉が必要な理由を説明する。まず最初に、遅れ時間算出部２１４によって算出された遅れ時間は、ユーザＸにとって不利益である。なぜなら、ユーザＸはタクシー４０を先に予約したにもかかわらず、タクシー４０に乗車する時間が遅れてしまうからである。このようなユーザＸの不利益を解消する方策の一例として、ユーザＹがユーザＸに報酬を支払うことが考えられる。報酬とは、例えば、現金である。すなわち、この方策は、ユーザＹがユーザＸに報酬を支払うことによって、ユーザＸの乗車時間の遅れを許容してもらう、という方策である。この方策を用いる場合、コンピュータ２０がユーザＸ及びユーザＹに対し、交渉することが必要となる。なお、ここでいう「交渉する」は、「通知する」に言い換えられてもよい。交渉の一例として、ユーザＸに対しては、乗車時間の遅れを許容する報酬はいくらか、と交渉することが考えられる。一方、ユーザＹに対しては、いち早く乗車するためにいくらまで報酬を出せるか、と交渉することが考えられる。両者の報酬が一致する、あるいは所定範囲に収まる場合、ユーザＹはいち早く乗車することが可能になる。一方、両者の報酬が一致しない、あるいは所定範囲に収まらない場合、ユーザＹはタクシー４０に乗車することができず、他のタクシーを探すことになる。

ここで、このような交渉は、主にユーザＸにとって煩わしい場合がある。そもそもユーザＸはタクシー４０を先に予約しているにもかかわらず、ユーザＹの、いわば割り込みリクエストによっていちいちコンピュータ２０から交渉されると、ユーザＸは煩わしさを感じる場合がある。一方、ユーザＹにとっても、いち早く乗車したいにもかかわらず、いちいちコンピュータ２０から交渉されると、予約を即座に確定できず煩わしさを感じる場合がある。急いでいるユーザＸであれば、少しの遅れも許容しない可能性がある。一方、あまり急いでいないユーザＸであれば、ある程度の遅れは許容する可能性がある。急いでいるユーザＹであれば、報酬を多目に払う可能性がある。一方、あまり急いでいないユーザＹであれば、払う報酬は少なくなる可能性がある。ユーザＸ及びユーザＹの属性、急ぎ度合い、予定などによっては、交渉自体、不要となる場合が有り得る。そこで、本実施形態において、交渉要否判断部２１５は、ユーザＸ及びユーザＹのインセンティブ特性を推定し、推定したインセンティブ特性に基づいて、ユーザＸ及びユーザＹと交渉が必要か否かを判断する。インセンティブ特性とは、ユーザＸ及びユーザＹの属性、急ぎ度合い、予定などを用いて推定される特性であり、一例として、設定データベース２４１及び顧客データベース２４２のどちらか一方に格納されているデータに基づいて推定される。なお、交渉の要否を判断する際に、必ずしもユーザＸ及びユーザＹの、両方のインセンティブ特性は必要ではない。ユーザＸのインセンティブ特性のみで、交渉の要否を判断することも可能である。

なお、報酬について、本実施形態では現金として説明するが、これに限定されない。例えば、報酬は、各事業者が展開しているポイントサービスに係るポイントでもよく、仮想通貨でもよく、電子マネーでもよい。

次に、図３～４を参照して、本実施形態における走行シーンについて説明する。

まず最初に図３を参照して、ユーザＹのリクエストがない場合、つまりユーザＸのリクエストのみ存在する場合について説明する。

図３に示す乗車場所７０は、ユーザＸが希望する乗車場所を示す。ユーザＸが乗車場所７０を指定してリクエストした場合、割当部２１２は、複数のタクシー４０～４２の中から、乗車場所７０に最も近い空車のタクシーを割り当てる。上述したように、本実施形態において、割り当てられるタクシーは、タクシー４０である。割当部２１２は、タクシー４０の現在地から乗車場所７０までの経路９０（第１経路）を設定する。経路９０は、例えば、タクシー４０の現在地から乗車場所７０まで最も早く到達可能な経路である。遅れ時間算出部２１４は、タクシー４０が経路９０を走行した場合における乗車場所７０までの第１移動時間を算出する。

次に図４を参照して、ユーザＸのリクエストを受け付けた後に、ユーザＹのリクエストを受け付けた場合について説明する。図４に示すシーンは、図３に示すシーンにおいて、ユーザＸのリクエストを受け付け、タクシー４０が乗車場所７０に向かっている途中でユーザＹのリクエストを受け付けた場合のシーンである。

図４に示す乗車場所７１は、ユーザＹが希望する乗車場所を示す。配車受付部２１１がユーザＸのリクエストを受け付けた後に、ユーザＹのリクエストを受け付けた場合、割当部２１２は、乗車場所７１と、タクシー４０の現在地とが近い場合、ユーザＹを乗車させるタクシーとして、タクシー４０が効率的と判断し、タクシー４０を割り当てる。そして、割当部２１２は、図４に示すように乗車場所７１を経由して乗車場所７０に到達する経路９１（第２経路）を設定する。経路９１は、例えば、タクシー４０の現在地から乗車場所７１を経由して乗車場所７０まで最も早く到達可能な経路である。遅れ時間算出部２１４は、タクシー４０が経路９１を走行した場合における乗車場所７０までの第２移動時間を算出する。

ここで、図４に示す経路９１は、図３に示す経路９０と比較して、経由地（乗車場所７１）を経由する分、乗車場所７０に到着する時間が遅れてしまう。このような遅れ時間は、第２移動時間から第１移動時間を減算することによって算出される。上述したように、遅れ時間はユーザＸにとって不利益であり、このようなユーザＸの不利益を解消する方策の一例として、ユーザＹがユーザＸに報酬を支払うことが考えられる。この方策を用いる場合、ユーザＸ及びユーザＹに対し、交渉することが必要となる。しかしながら、常に交渉が必要とは限らない。そこで、交渉要否判断部２１５は、ユーザＸ及びユーザＹのインセンティブ特性を推定し、推定したインセンティブ特性に基づいて、ユーザＸ及びユーザＹと交渉が必要か否かを判断する。ここで、図５～図６を参照して、ユーザＸ及びユーザＹのインセンティブ特性の一例を説明する。まず、図５を参照して、ユーザＸのインセンティブ特性の一例を説明する。

図５は、ユーザＸのインセンティブ特性の一例を示すグラフであり、縦軸はユーザＹからユーザＸへ支払われる報酬（金額）を示し、横軸は遅れ時間算出部２１４により算出された遅れ時間を示す。図５の縦軸に平行なラインＡは、コンピュータ２０がユーザＸと交渉せずに、ユーザＸが許容すると判断できる遅れ時間の上限値（上限時間）を示す。換言すれば、ラインＡは、金額の多寡に関係なく無条件で、ユーザＸが許容すると判断できる遅れ時間の上限値を示す。本実施形態では、ラインＡが示す時間を、５分として説明する。つまり、コンピュータ２０は、遅れ時間が５分より短いならば、ユーザＸは遅れ時間を許容すると推定する。図５の縦軸に平行なラインＢは、コンピュータ２０がユーザＸと交渉せずに、ユーザＸが許容しないと判断できる遅れ時間の下限値（下限時間）を示す。換言すれば、ラインＢは、金額の多寡に関係なく無条件で、ユーザＸが許容しないと判断できる遅れ時間の下限値を示す。本実施形態では、ラインＢが示す時間を、１０分として説明する。つまり、コンピュータ２０は、遅れ時間が１０分より長いならば、ユーザＸは遅れ時間を許容しないと推定する。なお、本実施形態において、遅れ時間の下限値は、遅れ時間の上限値より長い。

遅れ時間算出部２１４によって算出された遅れ時間が４分である場合、交渉要否判断部２１５は、図５に示すユーザＸのインセンティブ特性に基づいて、ユーザＸは遅れ時間を許容すると推定する。この場合、交渉要否判断部２１５は、ユーザＸ及びユーザＹとの交渉は、不要と判断する。理由は、ユーザＹが支払う金額の多寡にかかわらず、ユーザＸは遅れ時間を許容すると推定されているからである。この場合、タクシー４０は、図４に示す経路９１に沿って走行することになり、ユーザＹはタクシー４０に乗車することができる。

一方、遅れ時間算出部２１４によって算出された遅れ時間が１１分である場合、交渉要否判断部２１５は、ユーザＸのインセンティブ特性に基づいて、ユーザＸは遅れ時間を許容しないと推定する。この場合、交渉要否判断部２１５は、ユーザＸ及びユーザＹとの交渉は、不要と判断する。理由は、ユーザＹが支払う金額の多寡にかかわらず、ユーザＸは遅れ時間を許容しないと推定されているからである。この場合、タクシー４０は、図３に示す経路９０に沿って走行することになり、ユーザＹはタクシー４０に乗車することはできない。

図５に示すラインＣは、金額に応じて、ユーザＸであれば遅れ時間を許容すると推定される遅れ時間を示す。より詳しくは、ラインＣは、ユーザＸが許容する遅れ時間の閾値と、ユーザＹから受け取る金額との関係を示す。遅れ時間算出部２１４によって算出された遅れ時間が、ラインＡ（上限時間）～ラインＢ（下限時間）までの時間である場合、つまり、遅れ時間が５分～１０分である場合、ユーザＹからユーザＸへ支払われる報酬（金額）が、ラインＣ上の遅れ時間に対応する金額以上であれば、ユーザＸは遅れ時間を許容すると推定される。換言すれば、ラインＣは、ユーザＸが遅れ時間を許容すると推定される金額の下限値（第２下限値）である。

図５に示すラインＤは、金額に応じて、ユーザＸであれば遅れ時間を許容しないと推定される遅れ時間を示す。より詳しくは、ラインＤは、ユーザＸが許容しない遅れ時間の閾値と、ユーザＹから受け取る金額との関係を示す。遅れ時間が５分～１０分である場合、ラインＤに示す金額以下であれば、ユーザＸは遅れ時間を許容しないと推定される。換言すれば、ラインＤは、ユーザＸが遅れ時間を許容しないと推定される金額の上限値（第２上限値）である。なお、本実施形態において、ラインＤが示す金額は、ラインＣが示す金額より小さい。ラインＡ～Ｄによって、３つの領域Ｒ１～Ｒ３が形成される。領域Ｒ１は、ユーザＸであれば遅れ時間を許容すると推定される領域である。領域Ｒ２は、ユーザＸが遅れ時間を許容するか否か、推定できない領域である。領域Ｒ３は、ユーザＸであれば遅れ時間を許容しないと推定される領域である。

ラインＡ～Ｄの推定方法は、ユーザＸの属性、急ぎ度合い、予定などが用いられる。属性とは、性別（男性なのか女性なのか）、職業（社会人なのか学生なのか）、年齢、年収などである。例えば、ユーザＸが社会人であれば、学生より時間に対してシビアであると考えられるため、推定されるラインＡ及びラインＢは、遅れ時間が短くなる方向へずれる。例えば、ラインＡは３分、ラインＢは８分として推定される。また、時間に対してシビアであるほど、遅れ時間を許容するための金額は増えると考えられるため、ラインＣ及びラインＤの傾斜角は大きくなると推定される。

一方、ユーザＸが学生であれば、社会人よりは時間に対して寛容であると考えられるため、推定されるラインＡ及びラインＢは、遅れ時間が長くなる方向へずれる。例えば、ラインＡは７分、ラインＢは１２分として推定される。また、時間に対して寛容であるほど、遅れ時間を許容するための金額は減ると考えられるため、ラインＣ及びラインＤの傾斜角は小さくなると推定される。

また、社会人という属性が同じであったとしても、年収が多いほど、時間に対してシビアであると考えられるため、推定されるラインＡ及びラインＢは、さらに遅れ時間が短くなる方向へずれる。例えば、ラインＡは２分、ラインＢは７分として推定される。また、年収が多いほど、ラインＣ及びラインＤの傾斜角はさらに大きくなると推定される。

このようなユーザＸの属性は、会員登録時に入力されて、顧客データベース２４２に格納されている。交渉要否判断部２１５は顧客データベース２４２を参照して、ユーザＸのインセンティブ特性を推定することができる。

また、交渉要否判断部２１５は、クラウド上に格納されているユーザＸの予定表にアクセスし、ユーザＸの予定表に基づいてインセンティブ特性の一例であるラインＡ～Ｄを推定してもよい。例えば、ユーザＸの予定として、１５時から会議が決まっていれば、現在の時刻に照らして、ラインＢを推定することが可能となる。交渉要否判断部２１５は、１５時の会議に間に合うためには降車場所に１４時５０分に到着することが求められる、と判断し、１４時５０分という時刻から逆算して、ラインＢを推定しうる。ユーザＹを乗車させない場合、つまり、図３に示す経路９０に沿って走行した場合、１４時４０分に降車場所に到着すると仮定すると、１０分がラインＢとして推定される。つまり、経由地を経由しても、１４時５０分に降車場所に到着するならば、ユーザＸは１０分までの遅れを許容すると推定される。換言すれば、１０分を超えて遅れる場合、ユーザＸは遅れを許容しないと推定される。また、１４時４５分に降車場所に到着できれば、会議が始まる１５時まで余裕があるため、５分がラインＡとして推定される。

また、交渉要否判断部２１５は、ユーザＸの降車場所の属性に基づいてラインＡ～Ｄを推定してもよい。ユーザＸの降車場所がスーパーマーケットであれば、到着時間は厳密でなくてよい可能性があるため、推定されるラインＡ及びラインＢは右側にずれる。あるいは、ユーザＸの降車場所がレストランであれば、ユーザＸはレストランを予約している可能性が高いため、到着時間は厳守である可能性が高い。そこで、ラインＡ及びラインＢは左側にずれると推定される。同様に、ユーザＸの降車場所が映画館であれば、上映時間は決まっているため、到着時間は厳守である可能性が高い。そこで、ラインＡ及びラインＢは左側にずれると推定される。

このような降車場所の属性は、設定データベース２４１に格納されている。交渉要否判断部２１５は設定データベース２４１を参照して、ユーザＸのインセンティブ特性を推定することができる。

また、ユーザＸがタクシーをリクエストする際に、許容する遅れ時間の上限値（ラインＡが示す時間）及び許容しない遅れ時間の下限値（ラインＢが示す時間）を入力してもらい、交渉要否判断部２１５はその入力値を用いてラインＡ及びラインＢを推定してもよい。あるいは、ラインＡ及びラインＢは、ユーザＸがタクシーをリクエストする際に入力した降車場所の到着希望時刻から推定されてもよい。あるいは、交渉要否判断部２１５は、顧客データベース２４２に格納されている、ユーザＸの過去の履歴に基づいて、ラインＡ～Ｄを推定してもよい。ユーザＸの過去の履歴とは、ユーザＸが過去に許容した遅れ時間、許容しなかった遅れ時間、遅れ時間に対し要求した金額、実際に受け取った金額などである。また、ユーザＸがタクシーをリクエストする際に、遅れ時間に対して許容する金額を入力してもらい、交渉要否判断部２１５はその入力値を用いてラインＣ及びラインＤを推定してもよい。

上述したように、遅れ時間算出部２１４によって算出された遅れ時間が、ラインＡ（上限時間）よりも短い、又はラインＢ（下限時間）よりも長い場合、交渉要否判断部２１５は、ユーザＸのインセンティブ特性のみで交渉が不要と判断する。一方、時間算出部２１４によって算出された遅れ時間が、ラインＡ（上限時間）以上、且つラインＢ（下限時間）以下である場合、交渉要否判断部２１５は、ユーザＸのインセンティブ特性のみでは交渉が必要か否か判断しない。このような場合、交渉要否判断部２１５はユーザＹのインセンティブ特性もさらに考慮して、交渉が必要か否か判断する。

図６を参照して、ユーザＹのインセンティブ特性の一例を説明する。図６に示すラインＥは、コンピュータ２０がユーザＹと交渉せずに、ユーザＹがタクシーに乗車するためにユーザＸに対して支払うと推定される金額の上限値（第１上限値）を示す。図６に示すラインＦは、ユーザＹがユーザＸに対して支払わないと推定される金額の下限値（第１下限値）を示す。第１上限値は、いち早く乗車するためならばユーザＹは支払うと推定される金額の上限値である。第１下限値は、いち早く乗車したいとはいえ、ユーザＹは支払わないと推定される金額の下限値である。なお、第１下限値は、第１上限値より大きい。ラインＥ～Ｆによって、３つの領域Ｒ４～Ｒ６が形成される。領域Ｒ４は、ユーザＹは支払うと推定される金額の領域である。領域Ｒ２は、ユーザＹが支払うか否か、推定できない金額の領域である。領域Ｒ３は、ユーザＹは支払わないと推定される金額の領域である。

ラインＥ～Ｆの推定方法は、ラインＡ～Ｄの推定方法と同様に、ユーザＹの属性、急ぎ度合い、予定などが用いられる。例えば、ユーザＹが社会人であれば、多くの金額を払ってでもいち早く乗車したいと考えられるため、推定されるラインＥ～Ｆは、金額が大きくなる方向へずれる。一方、ユーザＹが学生であれば、あまり金額を払いたくないと考えられるため、推定されるラインＥ～Ｆは、金額が小さくなる方向へずれる。このようなユーザＹの属性は、会員登録時に入力されて、顧客データベース２４２に格納されているため、交渉要否判断部２１５は顧客データベース２４２を参照すればよい。また、交渉要否判断部２１５はクラウド上に格納されているユーザＹの予定表にアクセスし、ユーザＹの予定表に基づいてラインＥ～Ｆを推定してもよい。

あるいは、ラインＥ～Ｆは、ユーザＹが置かれている状況に基づいて推定されてもよい。例えば、ユーザＹが居る場所が炎天下であったり、大雪であったりする場合、ユーザＹは多くの金額を払ってでもいち早く乗車したいと考えられるため、推定されるラインＥ～Ｆは、金額が大きくなる方向へずれる。あるいは、交渉要否判断部２１５は、顧客データベース２４２に格納されている、ユーザＹの過去の履歴に基づいて、ラインＥ～Ｆを推定してもよい。ユーザＹの過去の履歴とは、ユーザＹが実際に支払った金額である。なお、ユーザＹがタクシーをリクエストする際に、ラインＥ～Ｆに係る金額を入力してもらい、交渉要否判断部２１５はその入力値を用いてラインＥ～Ｆを推定してもよい。

次に、図７～図９を参照して、ユーザＸ及びユーザＹのインセンティブ特性を用いた、図５に示すラインＡ～Ｂまでの遅れ時間における、交渉が必要か否かの判断方法の一例を説明する。図７～図９に示すラインＣ～Ｄは、図５に示すラインＡとラインＢとの間のラインＣ～Ｄを意味する。また、図７～図９に示す領域Ｒ１～Ｒ３は、図５に示すラインＡとラインＢとの間の領域Ｒ１～Ｒ３を意味する。図７～図９に示すラインＥ～Ｆは、図６に示すラインＥ～Ｆを意味する。また、図７～図９に示す領域Ｒ４～Ｒ６は、図６に示す領域Ｒ４～Ｒ６を意味する。なお、図７～図９の説明において、ラインＡ～Ｂまでの遅れ時間を、単に遅れ時間と称する。

まず、図７を参照して、交渉が不要と判断される場合について説明する。図７において、ラインＤが示す金額を１００円、ラインＣが示す金額を２００円、ラインＥが示す金額を３００円、ラインＦが示す金額を４００円として説明する。図７において、領域Ｒ３は、ユーザＸは１００円以下の金額ならば遅れ時間を許容しないと推定される領域を意味する。また、領域Ｒ１は、ユーザＸは２００円以上の金額ならば遅れ時間を許容すると推定される領域を意味する。また、領域Ｒ２は、１００円より大きく２００円より小さい金額ならばユーザＸが遅れ時間を許容するか否か、推定できない領域を意味する。一方、領域Ｒ４は、いち早く乗車するためならばユーザＹは３００円までなら支払うと推定される領域を意味する。また、領域Ｒ６は、いち早く乗車したいとはいえ、ユーザＹは４００円以上は支払わないと推定される領域を意味する。また、領域Ｒ５は、３００円より大きく４００円より小さい金額についてはユーザＹが支払うか否か、推定できない領域を意味する。

図７において、ラインＥ（３００円）は、ラインＣ（２００円）以上である。つまり、ユーザＸが遅れ時間を許容すると推定される金額（２００円）より、ユーザＹが支払うと推定される金額（３００円）のほうが大きい。この場合、交渉要否判断部２１５は、交渉は不要と判断する。交渉要否判断部２１５は、ユーザＹがユーザＸに支払う金額について、２００円～３００円の間で決定する。２００円～３００円の間であれば、どのような金額でもよいが、ユーザＹの利便性を考慮するならば２００円がよい。配車受付部２１１は、交渉要否判断部２１５によって決定された金額をユーザＸ及びユーザＹに通知する。

次に、図８を参照して、交渉が不要と判断される場合について説明する。図８において、ラインＥが示す金額を１００円、ラインＦが示す金額を２００円、ラインＤが示す金額を３００円、ラインＣが示す金額を４００円として説明する。図７において、領域Ｒ３は、ユーザＸは３００円以下の金額ならば遅れ時間を許容しないと推定される領域を意味する。また、領域Ｒ１は、ユーザＸは４００円以上の金額ならば遅れ時間を許容すると推定される領域を意味する。また、領域Ｒ２は、４００円より大きく３００円より小さい金額ならばユーザＸが遅れ時間を許容するか否か、推定できない領域を意味する。一方、領域Ｒ４は、いち早く乗車するためならばユーザＹは１００円までなら支払うと推定される領域を意味する。また、領域Ｒ６は、いち早く乗車したいとはいえ、ユーザＹは２００円以上は支払わないと推定される領域を意味する。また、領域Ｒ５は、１００円より大きく２００円より小さい金額についてはユーザＹが支払うか否か、推定できない領域を意味する。

図８において、ラインＤ（３００円）は、ラインＦ（２００円）より大きい。つまり、ユーザＸが遅れ時間を許容しないと推定される金額（３００円）は、ユーザＹが支払うと推定される金額（２００円）より大きい。この場合、交渉要否判断部２１５は、交渉は不要と判断する。割当部２１２は、タクシー４０とは別のタクシーをユーザＹに割り当てる。

次に、図９を参照して、交渉が必要と判断される場合について説明する。図９において、ラインＤが示す金額を１００円、ラインＥが示す金額を２００円、ラインＣが示す金額を３００円、ラインＦが示す金額を４００円として説明する。図７において、領域Ｒ３は、ユーザＸは１００円以下の金額ならば遅れ時間を許容しないと推定される領域を意味する。また、領域Ｒ１は、ユーザＸは３００円以上の金額ならば遅れ時間を許容すると推定される領域を意味する。また、領域Ｒ２は、１００円より大きく３００円より小さい金額ならばユーザＸが遅れ時間を許容するか否か、推定できない領域を意味する。一方、領域Ｒ４は、いち早く乗車するためならばユーザＹは２００円までなら支払うと推定される領域を意味する。また、領域Ｒ６は、いち早く乗車したいとはいえ、ユーザＹは４００円以上は支払わないと推定される領域を意味する。また、領域Ｒ５は、２００円より大きく４００円より小さい金額についてはユーザＹが支払うか否か、推定できない領域を意味する。

図９において、１００円より大きく４００円より小さい金額ならば、ユーザＸ及びユーザＹの双方が納得する可能性がある。そこで、交渉要否判断部２１５は、ユーザＸ及びユーザＹと交渉する必要がある判断する。なお、交渉方法の詳細について省略する。

次に、図１０～１１のフローチャートを参照して、コンピュータ２０（要否判断装置）の一動作例を説明する。

ステップＳ１０１において、配車受付部２１１は、ユーザＸからのリクエスト（第１リクエスト）を、端末装置６０を介して受け付ける。処理はステップＳ１０３に進み、割当部２１２は、ステップＳ１０１で受け付けたリクエストに基づいて、複数のタクシー４０～４２の中から適切なタクシーを割り当てる。割当部２１２は、効率化のために、複数のタクシー４０～４２の中から、ユーザＸが希望する乗車場所７０に最も近い空車のタクシー４０を割り当てる（図３参照）。割当部２１２は、タクシー４０の現在地から乗車場所７０までの経路９０を設定し、設定した経路９０に沿って乗車場所７０まで走行するようにタクシー４０に対して指令を送る。タクシー４０は割当部２１２からの指令に基づいて各種のアクチュエータを制御して乗車場所７０に向かう。

処理はステップＳ１０５に進み、移動時間算出部２１３は、タクシー４０が、経路９０に沿って乗車場所７０に到着するまでに要する第１移動時間を算出する。処理は、ステップＳ１０７に進み、配車受付部２１１は、ユーザＸのリクエストを受け付けた後に、ユーザＹのリクエスト（第２リクエスト）を受け付ける。処理はステップＳ１０９に進み、割当部２１２は、ユーザＹが希望する乗車場所７１と、タクシー４０の現在地とが近い場合、ユーザＹを乗車させるタクシーとして、タクシー４０が効率的と判断し、タクシー４０を割り当てる（図４参照）。割当部２１２は、乗車場所７１を経由して乗車場所７０に到達する経路９１を設定する。

処理はステップＳ１１１に進み、移動時間算出部２１３は、タクシー４０が、経路９１の沿って乗車場所７０に到着するまでに要する第２移動時間を算出する。処理はステップＳ１１３に進み、遅れ時間算出部２１４は、第２移動時間から第１移動時間を減算することによって、遅れ時間Ｔを算出する。遅れ時間ＴはユーザＸにとって不利益であり、このようなユーザＸの不利益を解消する方策の一例として、ユーザＹがユーザＸに報酬を支払うことが考えられる。この方策を用いる場合、ユーザＸ及びユーザＹに対し、交渉することが必要となる。しかしながら、常に交渉が必要とは限らない。そこで、処理はステップＳ１１５に進み、交渉要否判断部２１５は、ユーザＸのインセンティブ特性を推定し（図５参照）、推定したインセンティブ特性に基づいて、交渉が必要か否かを判断する。

処理はステップＳ１１７に進み、遅れ時間Ｔがインセンティブ特性のラインＡが示す時間（上限時間）より短い場合（ステップＳ１１７でＹｅｓ）、交渉要否判断部２１５は、交渉は不要と判断する（ステップＳ１２９）。この場合、タクシー４０は、経路９１に沿って走行することになり、ユーザＹはタクシー４０に乗車することができる。一方、遅れ時間Ｔがインセンティブ特性のラインＡが示す時間以上である場合（ステップＳ１１７でＮｏ）、処理はステップＳ１１９に進む。ステップＳ１１９において、遅れ時間Ｔがインセンティブ特性のラインＢが示す時間（下限時間）より長い場合（ステップＳ１１９でＹｅｓ）、交渉要否判断部２１５は、交渉は不要と判断する（ステップＳ１２９）。この場合、タクシー４０は、経路９０に沿って走行することになり、ユーザＹはタクシー４０に乗車することはできない。遅れ時間Ｔがインセンティブ特性のラインＢが示す時間以下である場合（ステップＳ１１９でＮｏ）、処理はステップＳ１２１に進む。

ステップＳ１２１において、交渉要否判断部２１５は、ユーザＹのインセンティブ特性を推定し（図６参照）、推定したユーザＸ及びユーザＹのインセンティブ特性に基づいて、交渉が必要か否かを判断する（ステップＳ１２３）。図７に示すようにラインＥが示す金額（第１上限値）がラインＣに示す金額（第２下限値）以上である場合（ステップＳ１２５でＹｅｓ）、交渉要否判断部２１５は、交渉は不要と判断する（ステップＳ１２９）。この場合、タクシー４０は、経路９１に沿って走行することになり、ユーザＹはタクシー４０に乗車することができる。一方、ステップＳ１２５でＮｏである場合、処理はステップＳ１２７に進む。図８に示すようにラインＤに示す金額（第２上限値）がラインＦに示す金額（第１下限値）より大きい場合（ステップＳ１２７でＹｅｓ）、交渉要否判断部２１５は、交渉は不要と判断する（ステップＳ１２９）。この場合、タクシー４０は、経路９０に沿って走行することになり、ユーザＹはタクシー４０に乗車することはできない。ステップＳ１２７でＮｏである場合、交渉要否判断部２１５は、交渉が必要と判断する（ステップＳ１３１）。

（作用効果）
以上説明したように、本実施形態によれば、以下の作用効果が得られる。

配車受付部２１１が、ユーザＸの端末装置６０からリクエストを受け付けた後に、ユーザＹの端末装置６１からリクエストを受け付けた場合、移動時間算出部２１３は、タクシー４０が、経路９０に沿って乗車場所７０に到着するまでに要する第１移動時間を算出する。また、移動時間算出部２１３は、タクシー４０が、経路９１に沿って乗車場所７０に到着するまでに要する第２移動時間を算出する。遅れ時間算出部２１４は、第２移動時間から第１移動時間を減算することによって、遅れ時間を算出する。交渉要否判断部２１５は、遅れ時間算出部２１４によって算出された遅れ時間に基づいて、ユーザＸ及びユーザＹと交渉が必要か否かを判断する。これにより、交渉要否判断部２１５は、不要な交渉を省略できる。

また、交渉要否判断部２１５は、ユーザＸと交渉せずにユーザＸが許容すると判断できる遅れ時間の上限値として上限時間を推定する。そして、交渉要否判断部２１５は、遅れ時間が、上限時間より短い場合は、交渉は不要と判断する。これにより、交渉要否判断部２１５は、不要な交渉を省略できる。なお、上限時間とは例えば図５のラインＡが示す時間である。このような上限時間は、ユーザＸの属性、急ぎ度合い、予定などを用いて推定される。

また、交渉要否判断部２１５は、ユーザＸと交渉せずにユーザＸが許容しないと判断できる遅れ時間の下限値として、上限時間より長い下限時間を推定する。そして、交渉要否判断部２１５は、遅れ時間が、下限時間より長い場合は、交渉は不要と判断する。これにより、交渉要否判断部２１５は、不要な交渉を省略できる。なお、下限時間とは例えば図５のラインＢが示す時間である。このような下限時間も上限時間と同様に、ユーザＸの属性、急ぎ度合い、予定などを用いて推定される。

また、遅れ時間が、上限時間以上、かつ、下限時間以下である場合、交渉要否判断部２１５は、ユーザＹと交渉せずにユーザＹがユーザＸに対して支払う報酬の第１上限値と、ユーザＹと交渉せずにユーザＹがユーザＸに対して支払わない報酬の第１下限値とを推定し、かつ、ユーザＸと交渉せずにユーザＸが遅れ時間を許容すると判断できる、ユーザＹから受け取る報酬の第２下限値と、ユーザＸと交渉せずにユーザＸが許容しないと判断できる、ユーザＹから受け取る報酬の第２上限値とを推定する。そして、交渉要否判断部２１５は、第１上限値が、第２下限値以上である場合、交渉は不要と判断する。これにより、交渉要否判断部２１５は、不要な交渉を省略できる。第１上限値及び第１下限値は、ユーザＹの属性、急ぎ度合い、予定などを用いて推定される。第２上限値及び第２下限値は、ユーザＸの属性、急ぎ度合い、予定などを用いて推定される。

また、第２上限値が、第１下限値より大きい場合、交渉要否判断部２１５は交渉は不要と判断する。これにより、交渉要否判断部２１５は、不要な交渉を省略できる。

上述の実施形態に記載される各機能は、１または複数の処理回路により実装され得る。処理回路は、電気回路を含む処理装置等のプログラムされた処理装置を含む。処理回路は、また、記載された機能を実行するようにアレンジされた特定用途向け集積回路（ＡＳＩＣ）や回路部品等の装置を含む。

上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

図４に示す例において、ユーザＹの降車場所によっては、ユーザＸはユーザＹと相乗りになる場合と相乗りにならない場合がある。例えば、図１２に示すように、ユーザＹの降車場所８０が、ユーザＸの乗車場所７０より手前である場合、相乗りは発生しない。図示は省略するが、ユーザＹの降車場所８０が、ユーザＸの乗車場所７０より遠い場合、相乗りが発生する。

また、上述の実施形態では、タクシー４０がユーザＸの乗車場所７０に向かう例を説明したが、本発明はすでにユーザＸがタクシー４０に乗車しており、ユーザＸの降車場所に向かう途中でユーザＹのリクエストを受けた場合にも適用できる。例えば、図１３に示すように、ユーザＸがタクシー４０に乗車しており、ユーザＸの降車場所８１に向かう途中でユーザＹのリクエストを受けた場合、ユーザＸが降車場所８１での到着時間の遅れを許容できるならば、タクシー４０はユーザＹの乗車場所７１を経由して降車場所８１に向かうことになる。図１３に示す例の遅れ時間は、タクシー４０が乗車場所７１を経由して降車場所８１に到着する経路を走行した場合の移動時間から、タクシー４０が乗車場所７１を経由せずに降車場所８１に到着する経路を走行した場合の移動時間を減算すればよい。

なお、上述した実施形態では、後からリクエストしたユーザＹが先にリクエストしたユーザＸに報酬を支払うと説明したが、これに限定されない。例えば、ユーザＹはタクシーの配車サービスを提供するサービサーに報酬を支払ってもよい。あるいは、ユーザＹは、ユーザＸ及びサービサーの双方に所定の割合で報酬を支払ってもよい。

１０ システム
２０ コンピュータ
２２ メモリ
２３、４０１、６０１ 通信Ｉ／Ｆ
２４ ストレージ
３０ 通信ネットワーク
４０～４２ タクシー
６０～６１ 端末装置
２１１ 配車受付部
２１２ 割当部
２１３ 移動時間算出部
２１４ 時間算出部
２１５ 交渉要否判断部
２４１ 設定データベース
２４２ 顧客データベース
６０２ 配車アプリ
４０２ 車両ＥＣＵ

Claims (4)

1. 第１ユーザの装置から目的地において車両に乗車又は前記車両から降車する第１リクエストをサーバが受け付けた後に、第２ユーザの装置から前記目的地とは異なる経由地において前記車両に乗車又は前記車両から降車する第２リクエストを前記サーバが受け付けた場合において、前記第１ユーザ及び前記第２ユーザと、前記車両が前記目的地まで移動する時間の遅れについて、通知する必要があるか否かを、前記サーバが判断する遅延交渉の要否判断方法であって、
   前記サーバは、
   前記車両が、前記目的地に到着する第１経路を走行した場合の前記目的地までの第１移動時間を算出し、
   前記車両が、前記経由地を経由して前記目的地に到着する第２経路を走行した場合の前記目的地までの第２移動時間を算出し、
   前記第２移動時間から前記第１移動時間を減算した遅れ時間に基づいて、前記第１ユーザ及び前記第２ユーザと通知する必要があるか否かを判断し、
   前記第１ユーザと交渉せずに前記第１ユーザが許容すると判断できる前記遅れ時間の上限値として上限時間を推定し、
   前記遅れ時間が、前記上限時間より短い場合は、前記交渉は不要と判断し、
   前記第１ユーザと交渉せずに前記第１ユーザが許容しないと判断できる前記遅れ時間の下限値として、前記上限時間より長い下限時間を推定し、
   前記遅れ時間が、前記下限時間より長い場合は、前記交渉は不要と判断し、
   前記遅れ時間が、前記上限時間以上、かつ、前記下限時間以下である場合、前記第２ユーザと交渉せずに前記第２ユーザが前記第１ユーザに対して支払う報酬の第１上限値と、前記第２ユーザと交渉せずに前記第２ユーザが前記第１ユーザに対して支払わない報酬の第１下限値とを推定し、かつ、前記第１ユーザと交渉せずに前記第１ユーザが前記遅れ時間を許容すると判断できる、前記第２ユーザから受け取る報酬の第２下限値と、前記第１ユーザと交渉せずに前記第１ユーザが許容しないと判断できる、前記第２ユーザから受け取る報酬の第２上限値とを推定し、
   前記第１上限値が、前記第２下限値以上である場合、前記交渉は不要と判断することを特徴とする遅延交渉の要否判断方法。
2. 前記サーバは、前記第２上限値が、前記第１下限値より大きい場合、前記交渉は不要と判断することを特徴とする請求項１に記載の遅延交渉の要否判断方法。
3. 第１ユーザの装置から目的地において車両に乗車又は前記車両から降車する第１リクエストを受け付けた後に、第２ユーザの装置から前記目的地とは異なる経由地において前記車両に乗車又は前記車両から降車する第２リクエストを受け付けた場合において、前記第１ユーザ及び前記第２ユーザと、前記車両が前記目的地まで移動する時間の遅れについて、通知する必要があるか否かを判断する遅延交渉の要否判断装置であって、
   コンピュータを備え、
   前記コンピュータは、
   前記車両が、前記目的地に到着する第１経路を走行した場合の前記目的地までの第１移動時間を算出し、
   前記車両が、前記経由地を経由して前記目的地に到着する第２経路を走行した場合の前記目的地までの第２移動時間を算出し、
   前記第２移動時間から前記第１移動時間を減算した遅れ時間に基づいて、前記第１ユーザ及び前記第２ユーザと通知する必要があるか否かを判断し、
   前記第１ユーザと交渉せずに前記第１ユーザが許容すると判断できる前記遅れ時間の上限値として上限時間を推定し、
   前記遅れ時間が、前記上限時間より短い場合は、前記交渉は不要と判断し、
   前記第１ユーザと交渉せずに前記第１ユーザが許容しないと判断できる前記遅れ時間の下限値として、前記上限時間より長い下限時間を推定し、
   前記遅れ時間が、前記下限時間より長い場合は、前記交渉は不要と判断し、
   前記遅れ時間が、前記上限時間以上、かつ、前記下限時間以下である場合、前記第２ユーザと交渉せずに前記第２ユーザが前記第１ユーザに対して支払う報酬の第１上限値と、前記第２ユーザと交渉せずに前記第２ユーザが前記第１ユーザに対して支払わない報酬の第１下限値とを推定し、かつ、前記第１ユーザと交渉せずに前記第１ユーザが前記遅れ時間を許容すると判断できる、前記第２ユーザから受け取る報酬の第２下限値と、前記第１ユーザと交渉せずに前記第１ユーザが許容しないと判断できる、前記第２ユーザから受け取る報酬の第２上限値とを推定し、
   前記第１上限値が、前記第２下限値以上である場合、前記交渉は不要と判断することを特徴とする遅延交渉の要否判断装置。
4. 第１ユーザの装置と、
   第２ユーザの装置と、
   車両に搭載されたコンピュータと、
   サーバと、を含み、
   前記サーバは、前記第１ユーザの装置、前記第２ユーザの装置、及び前記車両に搭載されたコンピュータと通信し、
   前記第１ユーザの装置から目的地において前記車両に乗車又は前記車両から降車する第１リクエストを前記サーバが受け付けた後に、前記第２ユーザの装置から前記目的地とは異なる経由地において前記車両に乗車又は前記車両から降車する第２リクエストを前記サーバが受け付けた場合において、前記第１ユーザ及び前記第２ユーザと、前記車両が前記目的地まで移動する時間の遅れについて、通知する必要があるか否かを判断する遅延交渉の要否判断システムであって、
   前記サーバは、
   前記車両が、前記目的地に到着する第１経路を走行した場合の前記目的地までの第１移動時間を算出し、
   前記車両が、前記経由地を経由して前記目的地に到着する第２経路を走行した場合の前記目的地までの第２移動時間を算出し、
   前記第２移動時間から前記第１移動時間を減算した遅れ時間に基づいて、前記第１ユーザ及び前記第２ユーザと通知する必要があるか否かを判断し、
   前記第１ユーザと交渉せずに前記第１ユーザが許容すると判断できる前記遅れ時間の上限値として上限時間を推定し、
   前記遅れ時間が、前記上限時間より短い場合は、前記交渉は不要と判断し、
   前記第１ユーザと交渉せずに前記第１ユーザが許容しないと判断できる前記遅れ時間の下限値として、前記上限時間より長い下限時間を推定し、
   前記遅れ時間が、前記下限時間より長い場合は、前記交渉は不要と判断し、
   前記遅れ時間が、前記上限時間以上、かつ、前記下限時間以下である場合、前記第２ユーザと交渉せずに前記第２ユーザが前記第１ユーザに対して支払う報酬の第１上限値と、前記第２ユーザと交渉せずに前記第２ユーザが前記第１ユーザに対して支払わない報酬の第１下限値とを推定し、かつ、前記第１ユーザと交渉せずに前記第１ユーザが前記遅れ時間を許容すると判断できる、前記第２ユーザから受け取る報酬の第２下限値と、前記第１ユーザと交渉せずに前記第１ユーザが許容しないと判断できる、前記第２ユーザから受け取る報酬の第２上限値とを推定し、
   前記第１上限値が、前記第２下限値以上である場合、前記交渉は不要と判断することを特徴とする遅延交渉の要否判断システム。

Images