JP2023027694A - 配車装置および配車システム - Google Patents

Abstract

【課題】ユーザおよびタクシーの双方にとって無駄の少ない配車を実現すること。【解決手段】実施形態に係る配車装置は、推定部と、マッチング部と、決定部とを備える。推定部は、ユーザの希望する乗車地点に対するユーザおよびタクシーそれぞれの到着時刻を推定する。マッチング部は、推定部による推定結果をマッチングし、推定結果の差異が小さくなるように配車内容を調整するマッチング処理を実行する。決定部は、マッチング処理の結果に基づいて配車内容を決定する。【選択図】図３

Description

開示の実施形態は、配車装置および配車システムに関する。

従来、たとえばユーザが利用する配車アプリ等を通じて、ユーザの希望に最も適うタクシーを選出し、配車する配車サービスが知られている。

また、このような配車サービスにおいて、タクシーが到着するまでの待ち時間がユーザの想定よりも長くなってしまうことを抑制するために、配車候補となるタクシーの待ち時間を予測し、待ち時間が所定の範囲を超えないタクシーのみ配車する技術も提案されている（たとえば、特許文献１参照）。

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

しかしながら、従来技術は、ユーザおよびタクシーの双方にとって無駄の少ない配車を実現するうえで、さらなる改善の余地がある。

たとえば、ユーザの待ち時間を考慮した配車を行ったとしても、ユーザがイベント開催中のイベント施設などにいる場合、かかる施設の混雑度によってはユーザが予定乗車地点に到着するまでに時間がかかってしまい、タクシーの方に無駄な待ち時間が発生するおそれがある。

一方で、やはりユーザの待ち時間を考慮した配車を行ったとしても、イベント施設などの周辺では渋滞が起こりやすいためにその影響でタクシーが遅れてしまい、ユーザの方に無駄な待ち時間が発生するおそれがある。

実施形態の一態様は、上記に鑑みてなされたものであって、ユーザおよびタクシーの双方にとって無駄の少ない配車を実現することができる配車装置および配車システムを提供することを目的とする。

実施形態の一態様に係る配車装置は、推定部と、マッチング部と、決定部とを備える。前記推定部は、ユーザの希望する乗車地点に対する前記ユーザおよびタクシーそれぞれの到着時刻を推定する。前記マッチング部は、前記推定部による推定結果をマッチングし、前記推定結果の差異が小さくなるように配車内容を調整するマッチング処理を実行する。前記決定部は、前記マッチング処理の結果に基づいて配車内容を決定する。

実施形態の一態様によれば、ユーザおよびタクシーの双方にとって無駄の少ない配車を実現することができる。

図１は、実施形態に係る配車方法の概要説明図である。 図２は、実施形態に係る配車システムの構成例を示す図である。 図３は、実施形態に係るサーバ装置の構成例を示すブロック図である。 図４は、施設情報の一例を示す図である。 図５は、渋滞情報の一例を示す図である。 図６は、ユーザ情報の一例を示す図である。 図７は、車両情報の一例を示す図である。 図８は、周辺情報の一例を示す図である。 図９は、配車依頼時のアプリ画面例を示す図（その１）である。 図１０は、配車依頼時のアプリ画面例を示す図（その２）である。 図１１は、配車依頼時のアプリ画面例を示す図（その３）である。 図１２は、配車依頼時のアプリ画面例を示す図（その４）である。 図１３は、推定処理およびマッチング処理の概要説明図である。 図１４は、推定結果通知の表示例を示す図（その１）である。 図１５は、推定結果通知の表示例を示す図（その２）である。 図１６は、推定結果通知の表示例を示す図（その３）である。 図１７は、配車内容の調整時のアプリ画面例を示す図（その１）である。 図１８は、配車内容の調整時のアプリ画面例を示す図（その２）である。 図１９は、配車内容の決定時のアプリ画面例を示す図である。 図２０は、実施形態に係るサーバ装置が実行する処理手順を示すフローチャートである。

以下、添付図面を参照して、本願の開示する配車装置および配車システムの実施形態を詳細に説明する。なお、以下に示す実施形態によりこの発明が限定されるものではない。

まず、実施形態に係る配車方法の概要について、図１を用いて説明する。図１は、実施形態に係る配車方法の概要説明図である。

既存技術の配車システムは、ユーザおよびタクシーの双方にとって無駄の少ない配車を実現するうえで、さらなる改善の余地がある。

たとえば、ユーザの待ち時間を考慮した配車を行ったとしても、ユーザがイベント施設などにいる場合、かかる施設の混雑度によってはユーザが予定乗車地点に到着するまでに時間がかかってしまい、タクシーの方に無駄な待ち時間が発生するおそれがある。

一方で、やはりユーザの待ち時間を考慮した配車を行ったとしても、イベント施設などの周辺では渋滞が起こりやすいためにその影響でタクシーが遅れてしまい、その場合にはユーザの方に無駄な待ち時間が発生するおそれがある。

そこで、実施形態に係る配車方法では、ユーザの希望する乗車地点に対するユーザおよびタクシーそれぞれの到着時刻を推定し、推定した推定結果をマッチングし、推定結果の差異が小さくなるように配車内容を調整するマッチング処理を実行し、マッチング処理の結果に基づいて配車内容を決定することとした。

具体的には、図１に示すように、実施形態に係る配車方法では、ユーザＵが自身の利用するユーザ端末１０を用い、タクシー配車用のアプリを介して、少なくとも希望乗車地点を指定する。なお、本実施形態では、ユーザＵは、イベント開催中のスタジアム等のイベント施設１０００の内部あるいはその周辺にいるものとする。

ユーザＵが指定した希望乗車地点を含む配車依頼は、インターネットや携帯電話回線網等であるネットワークＮを介してサーバ装置１００へ送信される。ここで、配車依頼は、さらにユーザＵの現在位置を含む。

一方、タクシーＴに搭載された車載装置３０は、常時（比較的短い所定時間間隔で）サーバ装置１００に対し、ネットワークＮを介してタクシーＴの現在位置を送信している。

そして、ユーザＵからの配車依頼を受け付けたサーバ装置１００は、配車候補となるタクシーＴを選択したうえで、希望乗車地点に対するユーザＵおよびタクシーＴそれぞれの到着時刻を推定する（ステップＳ１）。このとき、サーバ装置１００は、たとえばイベント施設１０００の混雑度や、道路の渋滞状況等を加味することができる。

そして、サーバ装置１００は、推定した推定結果をマッチングし、差異があれば差異が小さくなるように配車内容を調整するマッチング処理を実行する（ステップＳ２）。サーバ装置１００は、推定結果をタクシーＴに対し通知し、たとえばタクシーＴの方がユーザＵよりも早く到着しそうであれば、待機等によりタクシーＴに時間的な調整を行わせる。なお、待機地点は、イベント施設１０００の近くでは混雑が予想され、他の車両および他のタクシーの通行や乗車の妨げとなるので、このような障害が起こらないイベント施設１０００から少し離れた場所が好適で、タクシーＴの時間的な調整としてこの好ましい待機位置情報も提供することが好ましい。

また、たとえばタクシーＴの方が渋滞等でユーザＵよりも遅く到着しそうであれば、乗車地点の変更等を行わせる。たとえば、サーバ装置１００は、当初の希望乗車地点とは異なるが、少なくともユーザＵ側の待ち時間を減らせるランデブーポイントとも言える他の乗車地点を予定乗車地点とする場所的な調整を行う。

なお、このとき、希望乗車地点からの場所的な調整を行ってもらうユーザＵに対しては、希望乗車地点に対する調整後の乗車地点までの移動距離の差といった調整量に応じて、クーポン等のインセンティブを付与することとしてもよい。

そして、サーバ装置１００は、ステップＳ２での調整結果に基づいて配車内容を決定し（ステップＳ３）、決定された配車内容に含まれる予定乗車地点をユーザＵおよびタクシーＴのそれぞれに対し通知する。

なお、ステップＳ３での配車内容の決定後、時々刻々と変化するイベント施設１０００の混雑度や道路の渋滞状況等に応じて、適宜ステップＳ２，Ｓ３を繰り返してもよい。

また、ユーザＵの配車依頼からステップＳ３までの具体的な動作例については、図１０～図１９を用いた説明で後述する。

このように、実施形態に係る配車方法では、ユーザＵの希望する乗車地点に対するユーザＵおよびタクシーＴそれぞれの到着時刻を推定し、推定した推定結果をマッチングし、推定結果の差異が小さくなるように配車内容を調整するマッチング処理を実行し、マッチング処理の結果に基づいて配車内容を決定することとした。

したがって、実施形態に係る配車方法によれば、ユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することができる。以下、実施形態に係る配車方法を適用した配車システム１の構成例について、より具体的に説明する。

図２は、実施形態に係る配車システム１の構成例を示す図である。図２に示すように、配車システム１は、１以上のユーザ端末１０と、１以上の車載装置３０と、サーバ装置１００と、施設情報提供システム２００と、交通情報提供システム３００とを含む。

また、図２に示すように、ユーザ端末１０と、車載装置３０と、サーバ装置１００と、施設情報提供システム２００と、交通情報提供システム３００とは、前述のネットワークＮによって相互に接続され、ネットワークＮを介して相互にデータを送受信可能に設けられる。

ユーザ端末１０は、ユーザＵが携帯し利用する端末装置であり、配車システム１に係るアプリが動作するプラットフォームを有する。ユーザ端末１０は、たとえば、スマートフォンなどの携帯電話機や、タブレット端末等である。ユーザ端末１０は、他にも、ＰＣ（Personal Computer）や、ＰＤＡ（Personal Digital Assistant）や、腕時計型、メガネ型のウェアラブル装置等であってもよい。

車載装置３０は、タクシーＴに搭載されるコンピュータであり、配車システム１に係るタクシーＴ側の端末装置として動作し、配車システム１に係る各種の情報処理を実行する。

サーバ装置１００は、たとえばクラウドサーバとして実現され、ネットワークＮを介し、車載装置３０、施設情報提供システム２００、交通情報提供システム３００から常時配車システム１に係る各種の情報を収集する。また、サーバ装置１００は、ユーザＵから前述の配車依頼を受け付けた場合に、収集した各種の情報に基づいて上述のステップＳ１～ステップＳ３の各処理を実行する。

施設情報提供システム２００は、公益法人や一般事業者等が運営する上述したイベント施設１０００等を含む各種施設に関する施設情報を提供するシステムである。施設情報は、当該施設の混雑度等を含む。交通情報提供システム３００は、公益法人や一般事業者等が運営する交通情報を提供するシステムである。交通情報は、渋滞情報等を含む。

次に、図３は、実施形態に係るサーバ装置１００の構成例を示すブロック図である。なお、図３では、実施形態の特徴を説明するために必要な構成要素のみを表しており、一般的な構成要素についての記載を省略している。

換言すれば、図３に図示される各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。例えば、各ブロックの分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することが可能である。

また、図３を用いた説明では、既に説明済みの構成要素については、説明を簡略するか、省略する場合がある。

図３に示すように、実施形態に係るサーバ装置１００は、通信部１０１と、記憶部１０２と、制御部１０３とを備える。

通信部１０１は、たとえば、ＮＩＣ（Network Interface Card）等によって実現される。通信部１０１は、上述したネットワークＮと有線または無線で接続され、ネットワークＮを介して、ユーザ端末１０や車載装置３０との間で情報の送受信を行う。

記憶部１０２は、たとえば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１０２は、図３の例では、収集情報ＤＢ（Data Base）１０２ａと、周辺情報１０２ｂとを記憶する。

収集情報ＤＢ１０２ａは、後述する収集部１０３ａによって収集される各種情報のデータベースである。収集情報ＤＢ１０２ａは、施設情報と、渋滞情報と、ユーザ情報と、車両情報と、履歴情報とを含む。周辺情報１０２ｂは、施設情報に含まれる各種施設の周辺に関する情報である。

ここで、収集情報ＤＢ１０２ａに含まれる施設情報、渋滞情報、ユーザ情報、車両情報、および、周辺情報１０２ｂそれぞれの一例について説明する。図４は、施設情報の一例を示す図である。また、図５は、渋滞情報の一例を示す図である。また、図６は、ユーザ情報の一例を示す図である。また、図７は、車両情報の一例を示す図である。また、図８は、周辺情報１０２ｂの一例を示す図である。

図４に示すように、施設情報は、施設情報提供システム２００から提供される各種施設の現況に関する情報であり、たとえば、「時刻」と、「施設名称」と、「開催中イベント」と、「入場者数」と、「混雑度」とを含む。図４に「１ｈ後の予測混雑度」として示すように、混雑度の予測値を含んでもよい。サーバ装置１００は、前述したユーザＵの到着時刻を推定する際、かかる施設情報を用いる。

また、図５に示すように、渋滞情報は、交通情報提供システム３００から提供される渋滞に関する情報であり、たとえば、「時刻」と、「渋滞区域」と、「原因」と、「渋滞度」とを含む。図５に「１ｈ後の予測渋滞度」として示すように、渋滞度の予測値を含んでもよい。サーバ装置１００は、前述したタクシーＴの到着時刻を推定する際、かかる渋滞情報を用いる。

また、図６に示すように、ユーザ情報は、後述する受付部１０３ｂによって配車依頼が受け付けられたユーザＵに関する情報であり、たとえば、「受付ＩＤ」と、「ユーザＩＤ」と、「受付時位置」と、「現在位置」と、「予定乗車地点」とを含む。また、図６に示すように、「目的地」をさらに含んでもよい。「目的地」は、配車依頼時にオプション的に指定可能である。

また、図７に示すように、車両情報は、各タクシーＴに関する情報であり、「車両ＩＤ」と、「表示車両番号」と、「現在位置」と、「状態」と、「受付ＩＤ」とを含む。「受付ＩＤ」は、ユーザ情報の「受付ＩＤ」と紐付いている。サーバ装置１００は、ユーザＵからの配車依頼を受け付けた場合に、かかる車両情報を参照し、たとえばユーザＵの希望乗車地点に最も近い空車のタクシーＴを配車候補として選択する。

なお、収集情報ＤＢ１０２ａの履歴情報は図示を略するが、過去の配車履歴に関する情報であり、過去の配車時における各種情報を含む。前述の到着時刻の推定にかかる履歴情報を利用することにより、推定精度の向上を図ることができる。

また、図８に示すように、周辺情報１０２ｂは、上述した施設情報に含まれる各施設の周辺に関する情報であり、たとえば、「乗車地点候補」と、「周辺店舗」と、「提携クーポン」と、「乗車割引率」とを含む。

「乗車地点候補」は、該当の施設周辺において適当な乗車地点の候補となりうる各地点である。「周辺店舗」は、乗車地点候補ごとの周辺に存在する店舗である。「提携クーポン」は、ユーザＵが乗車地点候補を選択した場合に、インセンティブとして付与される当該候補の周辺店舗の提携クーポンである。

ユーザＵが選択した乗車地点候補の周辺店舗をタクシーＴの待ちの間にユーザＵが利用することで、ユーザＵが利するだけでなく、提携する周辺店舗の集客にも貢献することができる。

「乗車割引率」は、乗車地点候補に提携クーポンがない場合や、ユーザＵにとって乗車地点候補までの移動距離が長い場合などにインセンティブとして付与する運賃の割引率である。

図３の説明に戻る。制御部１０３は、コントローラ（controller）であり、たとえば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、記憶部１０２に記憶されている図示略の各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１０３は、たとえば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現することができる。

制御部１０３は、収集部１０３ａと、受付部１０３ｂと、選択部１０３ｃと、推定部１０３ｄと、マッチング部１０３ｅと、決定部１０３ｆとを有し、以下に説明する情報処理の機能や作用を実現または実行する。

収集部１０３ａは、通信部１０１を介し、前述の収集情報ＤＢ１０２ａに含まれる各種情報を常時収集する。

受付部１０３ｂは、通信部１０１を介し、ユーザＵから配車依頼を受け付け、選択部１０３ｃへ通知する。また、受付部１０３ｂは、受け付けた配車依頼に該当するユーザＵに関する情報をユーザ情報へ登録し、以降、かかるユーザＵに関するユーザ情報を収集部１０３ａに収集させる。

選択部１０３ｃは、配車依頼に応じた配車候補となるタクシーＴを収集情報ＤＢ１０２ａの車両情報から選択する。

ここで、説明を分かりやすくするため、配車依頼時のアプリ画面例について図９～図１２を用いて説明する。図９～図１２は、配車依頼時のアプリ画面例を示す図（その１）～（その４）である。

図９に示すように、たとえば配車依頼時のアプリ画面には、ユーザＵの現在位置の周辺の地図画面が表示される。かかる地図画面上には、たとえば希望乗車地点としてユーザＵが選択可能な乗車地点候補（ここでは、地点Ａ１，Ａ２，Ａ３）が表示される。また、かかる乗車地点候補の選択リストが併せて表示される。

かかる選択リストからユーザＵが希望する乗車地点から選択し、たとえば図中の「依頼」ボタンをタップ操作することで、ユーザＵが選択した希望乗車地点、ユーザＵの現在位置およびユーザＩＤを含む配車依頼がサーバ装置１００へ送信される。

なお、図１０に示すように、ユーザＵが地図画面上の各地点をタップ操作することで、各地点の詳細情報、たとえば前述の周辺情報１０２ｂに含まれるインセンティブに関する情報や、かかるインセンティブに関し、提携クーポンが使用できる店舗でタクシーＴを待ち合わせる場合の滞在推奨時間等を表示してもよい。

また、図１１に示すように、配車依頼時には、ユーザＵはオプション的に希望する乗車時刻を指定することができる。ユーザＵは、たとえば乗車前に買い物等で周辺に滞在したい時間等をここで指定することができる。後述する推定部１０３ｄは、かかる希望する乗車時刻が指定された場合、当該時刻をユーザＵの到着時刻として推定する。

また、図１２に示すように、配車依頼時には、ユーザＵはオプション的に乗車後の目的地を指定することができる。かかる目的地が指定されることにより、乗車地点候補を目的地に応じて調整可能とすることができる。かかる例については、図１８を用いた説明で後述する。

図３の説明に戻る。推定部１０３ｄは、収集情報ＤＢ１０２ａに含まれる各種情報を用いつつ、希望乗車地点に対するユーザＵおよび配車候補となったタクシーＴそれぞれの到着時刻を推定する。マッチング部１０３ｅは、推定部１０３ｄの推定結果をマッチングし、差異がある場合に、差異が小さくなるように配車内容を調整する。

ここで、説明を分かりやすくするため、推定部１０３ｄおよびマッチング部１０３ｅの処理内容について図１３～図１８を用いて説明する。

図１３は、推定処理およびマッチング処理の概要説明図である。また、図１４～図１６は、推定結果通知の表示例を示す図（その１）～（その３）である。また、図１７および図１８は、配車内容の調整時のアプリ画面例を示す図（その１）および（その２）である。

図１３に示すように、推定部１０３ｄは、ユーザＵおよびタクシーＴのそれぞれにつき、希望乗車地点に対する到着時刻を推定する。そして、マッチング部１０３ｅは、推定されたそれぞれの到着時刻をマッチングし、差異があれば、かかる差異が小さくなるように配車内容を調整する。

なお、図中には実線と破線で分けているように、かかる配車内容の調整は、基本的にはタクシーＴ側で調整されるように行われる。ユーザＵの希望を極力優先する方がサービスとしては好ましいためである。ただし、前述のランデブーポイントへ乗車地点を変更した方がユーザＵにとって好ましい場合等は、ユーザＵ側でも調整が行われる。

まず、調整のためにタクシーＴへ推定結果を通知する場合の例を示す。たとえば、推定されたタクシーＴの到着時刻の方がユーザＵよりも早いものとする。かかる場合、マッチング部１０３ｅは、たとえば車載装置３０の表示部３１に対し、図１４に示すように、自車両の方が早く到着しそうなため、待機等で時間調整を行うように通知する。なお、このとき、待機による時間調整は、イベント施設１０００からは離れた場所、すなわち渋滞の影響等を受けにくい場所等で行われることが好ましい。

一方で、たとえば、推定されたタクシーＴの到着時刻の方がユーザＵよりも遅いものとする。かかる場合、マッチング部１０３ｅは、たとえば表示部３１に対し、図１５に示すように、自車両の方が遅れて到着しそうなため、サービスの質の観点から他車両へ配車を振り替える旨を通知する。

なお、かかる場合、選択部１０３ｃが、新たに配車候補となるタクシーＴを選択し、推定部１０３ｄおよびマッチング部１０３ｅが、新たな配車候補であるタクシーＴについて推定処理およびマッチング処理を行うこととなる。

また、同じくタクシーＴの到着時刻の方がユーザＵよりも遅い場合で、乗車地点の調整により対処できそうな場合は、マッチング部１０３ｅは、たとえば表示部３１に対し、図１６に示すように、自車両の方が遅れて到着しそうなため、ユーザＵに別の乗車地点を提案する旨を通知する。

ここで、たとえばタクシーＴのドライバが「ＯＫ」ボタンを操作すれば、マッチング部１０３ｅは、図１７に示すように、ユーザ端末１０のアプリ画面に対し、希望乗車地点付近が渋滞のため、他の乗車地点を推奨する旨を通知する。併せて、ランデブーポイントとなる他の乗車地点の選択リストを表示する。

このとき、マッチング部１０３ｅは、たとえば残りの地点Ａ２，Ａ３のそれぞれにつき、収集情報ＤＢ１０２ａの各種情報に基づいて最新の推定到着時刻をシミュレーション計算する。そして、図１７に示すように、たとえば双方にとってロス時間が少なく、早く乗車できる方（ここでは、地点Ａ２）が上位となるように選択リストを表示する（図中の＊印参照）。

これにより、ユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することが可能となる。なお、ロス時間が少ない方ではなく、たとえば周辺店舗の提携クーポンの有無等で他の乗車地点の推奨度を決めてもよい。なお、そもそも間に合うタクシーＴが存在しない場合も、図１６および図１７に示したのと同様の処理となり、この場合は、たとえば最も早く到着する時間と乗車位置の提案となる。

また、図１６および図１７の変形例として、タクシーＴの遅れに対して乗車地点の変更ではなく、乗車時刻の変更を喚起するべく提携クーポン等により周辺店舗の利用を提案するようにしてもよい。この場合、たとえば図１７の各地点における周辺店舗と各店舗に滞在した場合のインセンティブの内容、滞在推奨時間（図１０参照）等を表示するとよい。

また、ユーザＵが前述した目的地を指定している場合には、図１８に示すように、目的地方向から適した地点（ここでは、地点Ａ３）の方が上位となるように選択リストを表示するようにしてもよい（図中の＊印参照）。

これにより、無駄な転回や迂回を減らすなど、やはりユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することが可能となる。

また、図１７および図１８を用いて説明した方法以外にも、マッチング部１０３ｅは、ユーザＵの到着時刻とタクシーＴの到着時刻がほぼ同一となる任意の乗車地点を算出し、当該乗車地点をユーザＵに対し推奨するようにしてもよい。

これにより、ユーザＵの到着時刻とタクシーＴの到着時刻がほぼ同一となる最適な乗車地点に基づいて、人混みや渋滞の影響を避けつつ、迅速なタクシーＴによる移動が可能となる。すなわち、ユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することが可能となる。

図３の説明に戻る。決定部１０３ｆは、マッチング部１０３ｅによるマッチング処理の結果に基づき、配車内容を決定し、ユーザＵおよびタクシーＴへ通知する。図１９は、配車内容の決定時のアプリ画面例を示す図である。

図１９に示すように、決定部１０３ｆは、マッチング処理の結果、たとえば予定乗車地点（ここでは、地点Ａ３）と、タクシーＴの予定到着時刻と、タクシーＴの表示車両番号とをユーザ端末１０のアプリ画面上に表示する。

なお、配車内容の決定後も、決定部１０３ｆは、時々刻々と変化するイベント施設１０００の混雑度や道路の渋滞状況等に応じた推定部１０３ｄの推定結果およびマッチング部１０３ｅのマッチング処理結果に基づいて適宜、配車内容を更新してもよい。

次に、実施形態に係るサーバ装置１００が実行する処理手順について、図２０を用いて説明する。図２０は、実施形態に係るサーバ装置１００が実行する処理手順を示すフローチャートである。

図２０に示すように、まず収集部１０３ａが、収集情報ＤＢ１０２ａに含まれる各種情報を常時収集する（ステップＳ１０１）。そして、受付部１０３ｂは、ユーザＵからの配車依頼を受け付ける（ステップＳ１０２）。

そして、選択部１０３ｃが、配車依頼に応じて、配車候補となるタクシーＴを選択する（ステップＳ１０３）。そして、推定部１０３ｄが、ユーザＵの希望乗車地点に対するユーザＵおよびタクシーＴの到着時刻を推定する（ステップＳ１０４）。

そして、マッチング部１０３ｅが、推定部１０３ｄによる推定結果をマッチングする（ステップＳ１０５）。そして、ほぼ差異がないか否かを判定する（ステップＳ１０６）。

ほぼ差異がない場合（ステップＳ１０６，Ｙｅｓ）、決定部１０３ｆが配車内容を決定し（ステップＳ１０８）、処理を終了する。差異がある場合（ステップＳ１０６，Ｎｏ）、マッチング部１０３ｅは、差異が小さくなるように配車内容を調整し（ステップＳ１０７）、ステップＳ１０４からの処理を繰り返す。なお、ステップＳ１０７には、クーポンの配布等の各種提案内容も含まれる。また、ステップＳ１０６には、タクシーＴのドライバおよびユーザＵの同意（主に待ち時間であるが、クーポン等も含めた乗車条件の合致）等も含まれる。

また、配車候補となるタクシーＴを変更する場合は、ステップＳ１０３からの処理を繰り返してもよい。

また、ステップＳ１０８の実行後、施設情報の混雑度や、道路の渋滞状況の変化により、たとえば推定部１０３ｄの推定結果が大きく変化するような場合には、ユーザＵが乗車するまで、ステップＳ１０４からの処理を適宜繰り返してもよい。

上述してきたように、実施形態に係るサーバ装置１００（「配車装置」の一例に相当）は、推定部１０３ｄと、マッチング１０３ｅ部と、決定部１０３ｆとを備える。推定部１０３ｄは、ユーザＵの希望する乗車地点に対するユーザＵおよびタクシーＴそれぞれの到着時刻を推定する。マッチング部１０３ｅは、推定部１０３ｄによる推定結果をマッチングし、推定結果の差異が小さくなるように配車内容を調整するマッチング処理を実行する。決定部１０３ｆは、マッチング処理の結果に基づいて配車内容を決定する。

したがって、実施形態に係るサーバ装置１００によれば、ユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することができる。

また、マッチング部１０３ｅは、上記推定結果の差異が小さくなるようにタクシーＴの到着時刻を調整する。

したがって、実施形態に係るサーバ装置１００によれば、時間的な調整よってユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することが可能となるとともに、極力ユーザＵの希望が優先されるように配車サービスを提供することができる。

また、マッチング部１０３ｅは、タクシーＴの到着時刻がユーザＵの到着時刻よりも早いと推定される場合に、タクシーＴを適切な待機位置で待機させることによってタクシーＴの到着時刻を調整する。

したがって、実施形態に係るサーバ装置１００によれば、たとえばタクシーＴを渋滞の影響を受けにくい場所に待機させつつ、極力ユーザＵの希望が優先されるように配車サービスを提供することができる。

また、マッチング部１０３ｅは、タクシーＴの到着時刻がユーザＵの到着時刻よりも遅いと推定される場合に、配車するタクシーＴを変更することによってタクシーＴの到着時刻を調整する。

したがって、実施形態に係るサーバ装置１００によれば、配車候補となるタクシーＴを変更することによって、極力ユーザＵの希望が優先されるように配車サービスを提供することができる。

また、マッチング部１０３ｅは、上記推定結果の差異が小さくなるように上記乗車地点を調整する。

したがって、実施形態に係るサーバ装置１００によれば、場所的な調整よってユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することが可能となる。

また、マッチング部１０３ｅは、ユーザＵの到着時刻とタクシーＴの到着時刻がほぼ同一となる乗車地点を算出し、当該乗車地点をユーザＵに対し推奨する。

したがって、実施形態に係るサーバ装置１００によれば、希望乗車地点とは異なるが、ユーザＵの到着時刻とタクシーＴの到着時刻がほぼ同一となる上記乗車地点を算出することによって、ユーザＵおよびタクシーＴの双方にとって無駄の少ない配車を実現することができる。

また、マッチング部１０３ｅは、上記乗車地点を調整した場合に、かかる乗車地点の調整量に応じてユーザＵに対しインセンティブを付与する。

したがって、実施形態に係るサーバ装置１００によれば、ユーザＵの希望からの調整量、言わばズレ量に応じて、かかるズレ量を補うインセンティブを付与することで、配車サービスに対する満足度の確保を図ることができる。

また、マッチング部１０３ｅは、ユーザＵに対しかかるユーザＵの到着時刻の変更を喚起するインセンティブを提案する。

したがって、実施形態に係るサーバ装置１００によれば、たとえばタクシーＴが遅れそうな場合に、周辺店舗で使用できる提携クーポンを使いながら当該店舗でユーザＵにタクシーＴの待ち合わせを行わせることで、配車サービスに対する満足度の確保を図ることができる。

さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。

１ 配車システム
１０ ユーザ端末
３０ 車載装置
３１ 表示部
１００ サーバ装置
１０１ 通信部
１０２ 記憶部
１０２ｂ 周辺情報
１０３ 制御部
１０３ａ 収集部
１０３ｂ 受付部
１０３ｃ 選択部
１０３ｄ 推定部
１０３ｅ マッチング部
１０３ｆ 決定部
２００ 施設情報提供システム
３００ 交通情報提供システム
１０００ イベント施設
Ｔ タクシー
Ｕ ユーザ

Claims (9)

1. ユーザの希望する乗車地点に対する前記ユーザおよびタクシーそれぞれの到着時刻を推定する推定部と、
   前記推定部による推定結果をマッチングし、前記推定結果の差異が小さくなるように配車内容を調整するマッチング処理を実行するマッチング部と、
   前記マッチング処理の結果に基づいて配車内容を決定する決定部と
   を備えることを特徴とする配車装置。
2. 前記マッチング部は、
   前記推定結果の差異が小さくなるように前記タクシーの到着時刻を調整する
   ことを特徴とする請求項１に記載の配車装置。
3. 前記マッチング部は、
   前記タクシーの到着時刻が前記ユーザの到着時刻よりも早いと推定される場合に、前記タクシーを待機させることによって前記タクシーの到着時刻を調整する
   ことを特徴とする請求項２に記載の配車装置。
4. 前記マッチング部は、
   前記タクシーの到着時刻が前記ユーザの到着時刻よりも遅いと推定される場合に、配車するタクシーを変更することによってタクシーの到着時刻を調整する
   ことを特徴とする請求項２または３に記載の配車装置。
5. 前記マッチング部は、
   前記推定結果の差異が小さくなるように前記乗車地点を調整する
   ことを特徴とする請求項１～４のいずれか一つに記載の配車装置。
6. 前記マッチング部は、
   前記ユーザの到着時刻と前記タクシーの到着時刻がほぼ同一となる乗車地点を算出し、当該乗車地点を前記ユーザに対し推奨する
   ことを特徴とする請求項５に記載の配車装置。
7. 前記マッチング部は、
   前記乗車地点を調整した場合に、該乗車地点の調整量に応じて前記ユーザに対しインセンティブを付与する
   ことを特徴とする請求項５または６に記載の配車装置。
8. 前記マッチング部は、
   前記ユーザに対し該ユーザの到着時刻の変更を喚起するインセンティブを提案する
   ことを特徴とする請求項１に記載の配車装置。
9. 請求項１～８のいずれか一つに記載の配車装置と、
   前記ユーザの希望する前記乗車地点を含む配車依頼および前記ユーザの現在位置を前記配車装置に対し送信する端末装置と、
   前記タクシーに搭載され、前記タクシーの現在位置を前記配車装置に対し送信する車載装置と
   を備えることを特徴とする配車システム。

Images