JP2018073299A - 情報処理装置、探索領域設定方法及びプログラム - Google Patents

Abstract

【課題】所望の目的地への移動を行う車両探索に係る演算負荷を低減する。【解決手段】情報処理装置は、車両への乗車を希望する希望者につき、乗車予定地と目的地の情報を取得し、該情報に基づいて決定した乗車予定地から目的地への移動に係る進行方向に基づき、希望者の乗車申込を行う車両を探索する探索領域を設定する。また装置は、乗車予定地から進行方向の反対方向に、乗車予定地から離間して存在する所定の範囲の領域を、探索領域として設定する。【選択図】図７

Description

本発明は、情報処理装置、探索領域設定方法及びプログラムに関するものであり、特に所望の目的地までの移動に利用可能な車両を探索する技術に関する。

近年、目的地が同一のユーザ等、運転者が運転する自動車に同乗して目的地まで移動する、所謂相乗り相手を募集するサービスが提供されている。このようなサービスは、ガソリン代や有料道路の利用料金等、移動経費の一部を同乗したユーザから徴収できるよう構成されており、運転者にとっては単独で移動する場合よりも移動経費を削減できる、また同乗するユーザにとっては利便性の高い交通手段を安価に利用できるといった利点がある。

例えば公共の交通機関が少ない地域等では、このような募集に基づく相乗り運転の利用価値は高いと考えられるが、従来上記のようなサービスでは、運転者が移動日時、目的地、空席数等の情報を入力し、これにつき同乗を希望するユーザを募り、事前（出発前）に利用ユーザを確定しておく必要があり、突発的に発生した利用希望に対し、動的に対応する仕組みがなかった。

一方、一般乗用旅客自動車運送事業（所謂タクシー業）では、利用要求がなされた際に、利用者が所望する乗車地までタクシーを配車するサービスが提供されている。特許文献１には、このようなタクシーの配車を好適に行わせるよう、配車要求を行った利用者端末の位置を中心とする所定半径内の範囲に存在するタクシーの端末に対し、配車要求を送信して出力させるシステムが開示されている。

特開２０１２−０８３９３３号公報

しかしながら、特許文献１の配車システムのように、移動する車両の位置情報を継続的に取得し、かつ利用者の全周囲の領域に存在する全ての車両につき、配車が可能であるか探索させることは、システム提供側（サーバ側）の演算負荷を過大にさせ得る。

また、「利用者」の希望する目的地までの移動を前提としているタクシーとは異なり、相乗り運転は、各「運転者」の目的地に移動する車両に利用者が同乗する形で実現されるものであり、運転者にとってメリットのない同乗要求を送信することは好ましくない。即ち、特許文献１の配車システムのような探索方式は、好適な結果を得られる可能性が低い車両に対しても要求を送信することになるため、通信帯域の占有の観点でも相乗り運転とは相性が悪かった。

本発明は、上述の問題点に鑑みてなされたものであり、所望の目的地への移動を行う車両探索に係る演算負荷を低減する情報処理装置、探索領域設定方法及びプログラムを提供することを目的とする。

前述の目的を達成するために、本発明の情報処理装置は、車両への乗車を希望する希望者につき、乗車予定地と目的地の情報を取得する取得手段と、取得手段により取得された情報に基づき、乗車予定地から目的地への移動に係る進行方向を決定する決定手段と、決定手段により決定された進行方向に基づき、希望者の乗車申込を行う車両を探索する探索領域を設定する設定手段と、を有し、設定手段は、乗車予定地から進行方向の反対方向に、乗車予定地から離間して存在する所定の領域を、探索領域として設定することを特徴とする。

このような構成により本発明によれば、所望の目的地への移動を行う車両探索に係る演算負荷を低減することが可能となる。

本発明の実施形態及び変形例に係る相乗りシステムのシステム構成を例示した図 本発明の実施形態及び変形例に係る管理サーバ１００の機能構成を例示したブロック図 本発明の実施形態及び変形例に係る運転者端末２００の機能構成を例示したブロック図 本発明の実施形態及び変形例に係る希望者端末３００の機能構成を例示したブロック図 本発明の実施形態及び変形例に係る相乗りシステムで用いられる各種データのデータ構成を例示した図 本発明の実施形態及び変形例に係る探索領域を説明するための図 本発明の実施形態１に係る、管理サーバ１００において実行される提供処理を例示したフローチャート 本発明の実施形態２に係る提供処理を例示したフローチャート 本発明の実施形態２に係る、道路条件を踏まえた探索領域の調整を説明するための図 本発明の実施形態３に係る進行方向の決定を説明するための図 本発明の実施形態３に係る提供処理を例示したフローチャート

［実施形態］
以下、本発明の例示的な実施形態について、図面を参照して詳細に説明する。なお、以下に説明する一実施形態は、情報処理装置の一例としての、希望者の使用する端末から受信した乗車希望について、現在走行中の車両を運転する運転者への相乗り（または同乗）運転の申込、申込承諾に基づく予約確定、及び実施された相乗り運転の管理を行う管理サーバに、本発明を適用した例を説明する。しかし、本発明は、受信した乗車要求について、乗車させる車両を探索する探索領域を設定することが可能な任意の機器に適用可能である。また、本明細書において、「運転者」とは、車両を運転しているユーザを指し、「希望者」とは、運転者の運転する車両に乗ることを希望するユーザであって、運転を行わず同乗するユーザを指すものとして説明する。

《相乗りシステムの構成》
図１は、本発明の実施形態に係る相乗りシステムのシステム構成を示したシステム図である。

図示されるように、本実施形態では管理サーバ１００と運転者端末２００及び希望者端末３００とは、ネットワーク４００を介して接続され、情報の送受信が可能に構成される。後述するように、本実施形態では管理サーバ１００が、サービス登録ユーザに係るユーザ情報の管理、（相乗り運転を受け入れ可能な状態で）車両移動中であるユーザ（運転者）の管理、乗車希望を行ったユーザ（希望者）の管理、実施された相乗り運転の管理、乗車希望に基づく車両探索及び乗車申込の機能を集約して行うものとして説明するが、本発明の実施はこれに限られるものではない。このような機能の一部は、管理サーバ１００と通信可能に構成された他の装置により実現されるよう分離され、管理サーバ１００は該他の装置と協働して動作する態様であってもよい。

また本実施形態では簡単のため、運転者端末２００及び希望者端末３００には、相乗りシステムにより提供される、相乗り運転に係るサービスを利用するための所定のアプリケーション（サービスアプリ）が格納されているものとする。サービス利用中において運転者端末２００及び希望者端末３００では、フォアグラウンドまたはバックグラウンドにて該サービスアプリが起動されることで、管理サーバ１００との通信が可能なように構成されているものとして説明する。しかしながら、本発明の実施はこれに限られるものではなく、サービス利用に係る各端末での動作は、ブラウジングアプリケーションを介してサイトアクセスすることで行われる等、どのような手法により実現されるものであってもよい。

また本実施形態では、サービスアプリは選択式の運転者モードと同乗者モードの２つのモードを有しており、いずれのモードが選択されるかによって、該サービスアプリを起動している端末のユーザが運転者と希望者（または同乗者）のいずれであるかを判別可能に構成されているものとする。即ち、運転者モードが起動された端末は運転者端末２００として扱われ、該端末を使用するユーザが、現在車両移動中である運転者として管理される。また同乗者モードが起動された端末は希望者端末３００として扱われ、該端末を使用するユーザが、運転者の運転する車両への乗車希望の送信が可能な、また申込後に（承諾されれば）同乗が可能な希望者として管理される。

〈管理サーバ１００の構成〉
図２は、本発明の実施形態に係る管理サーバ１００の機能構成を示したブロック図である。なお、各装置の機能構成の説明において同様の機能を実現する構成については、管理サーバ１００、運転者端末２００、希望者端末３００のいずれの構成であるかを判別可能とするため、各々「管理」、「運転」、「希望」の接頭文字を付して識別するものとして以下説明する。また本実施形態の管理サーバ１００では、図２に実線で示される構成（道路情報ＤＢ１２０以外の構成）を有するものとして説明する。

管理制御部１０１は、例えばＣＰＵ等であり、管理サーバ１００が有する各ブロックの動作を制御する。具体的には管理制御部１０１は、管理記録媒体１０２に記録されている各ブロックの動作プログラムやサービス提供に係る種々の処理のプログラムを読み出し、管理メモリ１０３に展開して実行することにより各ブロックの動作を制御する。

管理記録媒体１０２は、例えば不揮発性メモリやＨＤＤ等の、格納された情報を恒久的に保持する記録装置である。管理記録媒体１０２は、上記プログラムだけでなく、管理サーバ１００が有する各ブロックの動作において必要となるパラメータ等の情報を記録する。また管理メモリ１０３は、例えば揮発性メモリ等の、格納された情報を簡易にアクセス可能な状態で、一時的に保持する記憶装置である。管理メモリ１０３は、プログラムの展開領域としてだけでなく、各ブロックの動作において出力された中間データ等を一時的に保持する格納領域として用いられる。

ユーザＤＢ１０４は、本実施形態の相乗りシステムが提供する相乗り運転に係るサービスに、運転者、希望者を問わず登録されているユーザ（登録ユーザ）の各種情報（ユーザ情報）を管理するデータベースである。ユーザ情報は、例えば登録ユーザを識別するユーザＩＤに関連付けて、氏名、年齢、住所、趣味、運転免許の有無、車両所有の有無、車種等の個人情報に加え、サービス利用に用いられる（車両移動に係り携行されている）端末の情報及び該端末との通信に必要な端末特定のための情報等を含むものであってよい。

運転者ＤＢ１０５は、運転者としてサービス利用しているユーザの各種情報を管理するデータベースである。運転者ＤＢ１０５は、上述したように、サービス利用に係り、使用する端末において運転者モードでサービスアプリが起動された場合に、該端末（運転者端末２００）のユーザの各種の情報を運転者情報として追加し、管理する。

運転者情報は、例えば図５（ａ）に示されるように、運転者情報を識別する運転者ＩＤ５０１に関連付けて、運転者であるユーザにつきユーザＤＢ１０４に登録されているユーザＩＤ５０２、及び該ユーザの使用する運転者端末２００において取得された位置情報の履歴を時系列で示す端末位置履歴５０３を管理するものであってよい。

希望者ＤＢ１０６は、希望者あるいは同乗者としてサービス利用しているユーザの各種情報を管理するデータベースである。希望者ＤＢ１０６は、使用する端末において同乗者モードでサービスアプリが起動され、乗車希望に係る情報を該端末（希望者端末３００）から受信した場合に、該端末のユーザの各種の情報を希望者情報として追加し、管理する。

希望者情報は、例えば図５（ｂ）に示されるように、希望者情報を識別する希望者ＩＤ５１１に関連付けて、希望者であるユーザにつきユーザＤＢ１０４に登録されているユーザＩＤ５１２、該ユーザの使用する希望者端末３００において取得された位置情報の履歴を時系列で示す端末位置履歴５１３、今回の相乗り運転に係る希望者の乗車予定地及びその乗車予定時刻と目的地とを示す乗車希望情報５１４、及び該希望者の乗車希望に係る同乗が成立したか否かを示す成立済フラグ５１５を管理するものであってよい。

相乗りＤＢ１０７は、希望者により行われた乗車希望に基づく相乗り運転について各種情報（ドライブ情報）を管理するデータベースである。より詳しくは相乗りＤＢ１０７は、希望者の乗車希望に基づく相乗り運転（希望者が同乗する期間に係るドライブ）が成立した場合、あるいは運転者により乗車申込が承諾されて相乗り運転の実施が予約された場合に、該相乗り運転に係るドライブ情報を登録し、管理する。ドライブ情報は、例えば図５（ｃ）に示されるように、ドライブ情報を識別するためのドライブＩＤ５２１に関連付けて、運転者に係る運転者情報５２２、希望者に係る希望者情報５２３、実際に同乗した期間に走行した経路の情報を示す運転経路５２４、及びドライブが完了したか否かを示す（例えば論理型の）完了フラグ５２５を管理するものであってよい。

ここで、運転者情報５２２は、運転者のユーザＩＤ５３１に関連付けて、運転者が使用する運転者端末２００から取得された位置情報の履歴を示す端末位置履歴５３２を管理するよう構成されていてよい。対して希望者情報５２３は、希望者（同乗の申込が承諾されたユーザ）のユーザＩＤ５４１に関連付けて、希望者が使用する希望者端末３００から取得された位置情報の履歴を示す端末位置履歴５４２に加え、実際に該希望者が、運転者の運転する車両に乗車した位置や時刻等を示す乗車情報５４３、及び同様に降車した位置や時刻等を示す降車情報５４４を管理するよう構成されていてよい。なお、運転経路５２４は、基本的には運転者端末２００に係る端末位置履歴５３２に基づいて決定されるものであってよく、相乗り運転に係る希望者の負担費用（有料高速道路の利用料金やガソリン代等の実費）の確定に用いられる情報である。

決定部１０８は、希望者端末３００から受信した乗車希望につき、乗車申込を行う車両（運転者端末２００）の探索に使用する、「進行方向」の決定を行う。本実施形態の「進行方向」の定義については後述するが、本発明に係る「進行方向」とは乗車申込を行う車両の探索にあたり設定される指標であり、厳密に車両の進行する方向や希望者が進行する方向を限定する目的で定義されるものではない。

設定部１０９は、乗車申込を行う車両の探索を行う、地理的な探索領域を設定する。設定部１０９よる探索領域の設定は、後述するように決定部１０８により決定された進行方向と乗車予定地とに基づき行われる。

管理通信部１１０は、管理サーバ１００が有する通信インタフェースである。管理通信部１１０は、ネットワーク４００を介して他の装置（運転者端末２００及び希望者端末３００、場合によっては分離された機能を実現する外部装置）と接続し、所定のプロトコルに従った通信方式で、機器間のデータの送受信を行う。

本実施形態ではハードウェアとして管理サーバ１００が備える各ブロックにおいて処理が実現されるものとして説明するが、本発明の実施はこれに限らず、各ブロックの処理は該各ブロックと同様の処理を行うプログラムで実現されてもよい。

〈運転者端末２００及び希望者端末３００の構成〉
以下、運転者端末２００及び希望者端末３００の機能構成につき、図３及び図４のブロック図を用いて説明する。本実施形態では、運転者端末２００及び希望者端末３００が有する基本的な構成は同様であるものとして説明するが、本発明の実施において、運転者端末２００及び希望者端末３００の構成はこれに限られるものではない。

運転制御部２０１及び希望制御部３０１は、例えばＣＰＵであり、各々運転者端末２００または希望者端末３００が有する各ブロックの動作を制御する。具体的には運転制御部２０１及び希望制御部３０１は、各々の端末が有する運転記録媒体２０２または希望記録媒体３０２に記録されている各ブロックの動作プログラムや、相乗りシステムにより提供されるサービスを利用するために必要となる（サービスアプリを含む）アプリケーションプログラム等を読み出し、それぞれ運転メモリ２０３または希望メモリ３０３に展開して実行することにより、各端末上において各ブロックの動作制御を行う。なお、サービスを利用するために必要となるサービスアプリの動作については、後述する。

運転記録媒体２０２及び希望記録媒体３０２は、例えば不揮発性メモリやＨＤＤ等の、格納された情報を恒久的に保持する記録装置である。運転記録媒体２０２及び希望記録媒体３０２は、上記プログラムだけでなく、各ブロックの動作において必要となるパラメータ等の情報を各々記録する。また運転メモリ２０３及び希望メモリ３０３は、例えば揮発性メモリ等の、格納された情報を簡易にアクセス可能な状態で一時的に保持する記憶装置である。運転メモリ２０３及び希望メモリ３０３は、プログラムの展開領域としてだけでなく、各ブロックの動作において出力された中間データ等を一時的に保持する格納領域として用いられる。

運転位置取得部２０４及び希望位置取得部３０４は、ＧＰＳ利用等の所定の方式で、各端末の位置情報を取得する。本実施形態の相乗りシステムでは、運転者端末２００及び希望者端末３００においてサービスアプリが実行されている、あるいはバックグラウンド動作している間、所定の時間間隔で位置情報を取得し、該位置情報を管理サーバ１００に送信する動作が行われる。より詳しくは、運転者端末２００においてサービスアプリが運転者モードで実行されている間、また希望者端末３００においてサービスアプリが同乗者モードで実行され、かつ乗車希望に係る情報入力がなされた後、運転位置取得部２０４及び希望位置取得部３０４のそれぞれは端末の位置情報を取得するよう制御される。

運転操作入力部２０５及び希望操作入力部３０５は、ボタンやタッチパネル等、各端末が備える操作入力に係るユーザインタフェースである。運転操作入力部２０５及び希望操作入力部３０５は、該ユーザインタフェースに対して操作がなされたことを検出すると、該操作の内容を解析し、操作入力結果として運転制御部２０１または希望制御部３０１にそれぞれ伝達する。操作入力結果は、例えば端末のオペレーションプログラムやサービスアプリで定められたいずれかの入力イベントと判断されるものであってよい。

運転通信部２０６及び希望通信部３０６は、それぞれ運転者端末２００または希望者端末３００が有する通信インタフェースである。本実施形態の相乗りシステムでは、運転者端末２００及び希望者端末３００は、相乗り運転に係るサービスの利用にあたり、管理サーバ１００との通信を行うことが必須となるため、通信インタフェースは不可欠な構成である。運転通信部２０６及び希望通信部３０６は、ネットワーク４００を介して他の装置（管理サーバ１００、場合によってはネットワーク４００を介さず互いの端末間で、あるいはその他の並行利用すべきサービスを提供する外部装置）と接続し、所定のプロトコルに従った通信方式で、機器間のデータの送受信を行う。

《サービス概要》
ここで、本実施形態の相乗りシステムで提供されるサービスの概要につき、それぞれの利用段階にて該システムで行われる動作の概要を説明する。

〈運転者端末の受け入れ状態への遷移〉
上述したように端末においてサービスアプリが運転者モードで起動されると、あるいは起動されたサービスアプリにおいて運転者モードが選択されると、端末は運転者端末２００として機能する。本実施形態では簡単のため、運転者モードでサービスアプリが動作している状態は、運転者端末２００を使用する運転者により、自己の運転する車両（もしくは自己が乗車する車両）への希望者の同乗を受け入れ可能であるとの意思表示がなされているものとして取り扱う。運転者モードでのサービスアプリの動作が開始すると、運転制御部２０１は、アプリケーションプログラムに基づき、例えば運転者モードとなったことを示す情報をユーザＩＤに関連付け、運転通信部２０６を介して管理サーバ１００に送信する。

運転者端末２００から運転者モードとなったことを示す情報を受信すると、管理制御部１０１は、ユーザＩＤに関連付けてユーザＤＢ１０４に登録されているユーザ情報を取得し、運転者に係る運転者情報を運転者ＤＢ１０５に登録する。具体的には管理制御部１０１は、新たな運転者ＩＤ５０１を発行し、取得したユーザ情報に基づきユーザＩＤ５０２を関連付けて運転者情報を生成し、運転者ＤＢ１０５に登録する。なお、運転者情報は、運転者端末２００における運転者モードの解除、または相乗り運転の終了を受けて、運転者ＤＢ１０５から削除されるものとする。

またサービスアプリが運転者モードで動作している間、運転位置取得部２０４は運転制御部２０１の制御の下、所定の時間間隔で運転者端末２００の位置（測位）情報を取得し、例えばユーザＩＤに関連付けて管理サーバ１００に送信する。送信された運転者端末２００の位置情報は、ユーザＩＤを含めて運転者ＤＢ１０５に登録された運転者情報の端末位置履歴５０３に随時タイムスタンプとともに追加され、管理される。このようにすることで、相乗り運転に係るサービスにおいて、同乗を受け入れ可能な車両とその位置情報とが、システムにおいて把握可能な状態となる。

〈乗車希望〜乗車申込〉
同乗を受け入れ可能な車両への乗車希望は、端末においてサービスアプリが同乗者モードで動作している状態（端末が希望者端末３００として機能している状態）で可能となる。乗車希望を行う場合、希望者はサービスアプリにおいて例えば乗車予定地、乗車予定時刻及び目的地の情報を入力する。なお、本実施形態では簡単のため、希望者が現在存在する位置にて、今から目的地に向かう車両につき、乗車希望を行うユースケースについて説明する。つまり、現在位置にてこれから乗車したいとのユースケースにおいては、希望者は乗車希望にあたり乗車予定時刻や特定の乗車予定地の詳細を入力する必要はなく、例えば目的地のみ入力すれば、簡易的に乗車希望の操作を行うことで希望位置取得部３０４により現在の位置情報が取得され、必要な情報が揃う。希望制御部３０１は、乗車予定地（現在位置）と目的地の情報を希望者のユーザＩＤに関連付け、乗車希望の情報として希望通信部３０６を介して管理サーバ１００に送信する。

希望者端末３００から乗車希望の情報を受信すると、管理制御部１０１は、ユーザＩＤに関連付けてユーザＤＢ１０４に登録されているユーザ情報を取得し、希望者に係る希望者情報を希望者ＤＢ１０６に登録する。具体的には管理制御部１０１は、新たな希望者ＩＤ５１１を発行し、取得したユーザ情報と受信した乗車希望の情報とに基づくユーザＩＤ５１２及び乗車希望情報５１４を関連付けて希望者情報を生成し、希望者ＤＢ１０６に登録する。このとき希望者情報の成立済フラグ５１５は、初期値の偽（ｆａｌｓｅ：乗車の受け入れがなされていない状態）に設定されるものとする。

また運転者モードと同様、乗車希望に係る入力がなされてから、希望位置取得部３０４は希望制御部３０１の制御の下、所定の時間間隔で希望者端末３００の位置情報を取得し、例えばユーザＩＤに関連付けて管理サーバ１００に送信する。送信された希望者端末３００の位置情報は、ユーザＩＤを含めて希望者ＤＢ１０６に登録された希望者情報の端末位置履歴５１３に随時タイムスタンプと共に追加され、管理される。なお、本実施形態では、希望者が車両に乗車したことを確認するため、あるいは希望者が乗車予定地と異なる位置に存在する（乗車予定地に向かっている、または乗車予定地から移動した）場合も考慮するため、同乗者モードにおいてもサービスアプリは定期的な位置情報の取得を行い、その履歴が希望者情報にて管理されるものとして説明するが、本発明の実施はこれに限られるものではない。例えば、希望者端末３００に係る端末位置履歴５１３の管理は、希望者が車両に乗車したことが確定した後に、希望位置取得部３０４により行われた位置情報について行われるものであってよい。

希望者情報の登録に応じて設定部１０９は、乗車希望に対応する乗車申込を端末に送信する車両を探索する探索領域を設定する。本実施形態の相乗りシステムでは、乗車申込の運転者端末２００への送信が、目的地に到達し得る車両に対してなされるよう、まず到達し得る車両の存在率が高いと推測される領域に探索領域が限定される。そして、該探索領域につき、さらに、到達する可能性の高い車両の探索が行われ、最終的に乗車申込を行う車両が確定する。上述したように、乗車予定地の全周囲に存在する車両について到達する可能性の高い車両の探索を行うことは、探索の対象となる車両を膨大にし得るため、同時に複数の乗車希望がなされることも想定される本実施形態のような相乗りシステムでは好適でない。また「相乗り運転」との前提を考慮すると、例えば目的地方面から乗車予定地の方向に進行している車両が、転回（Ｕターン）して再度目的地の方向に進行することは想定しづらい等、乗車予定地からみて特定の方向に存在している車両を探索の対象とすること、あるいは、このような車両に係る運転者端末２００に乗車申込を送信することは、相乗り乗車が成立する見込みも低く、現実的でない。故に、本実施形態の相乗りシステムでは、決定部１０８は、乗車予定地から目的地に向かう方向を進行方向として決定し、設定部１０９は、乗車予定地からみて該決定された進行方向の反対方向に、乗車予定地から離間して存在する領域を探索領域として設定する。

本実施形態に係る探索領域６００は、図６（ａ）に示されるように、乗車予定地６０１を中心とする２種類の半径（距離）の同心円６０３及び６０４と、進行方向６０２の反対方向に延びる直線６０７と所定の角度（θ）をなすよう乗車予定地から規定される２種類の直線６０５及び６０６で規定される領域として設定される。即ち、本実施形態で設定される探索領域は、乗車予定地を中心として、進行方向に基づく所定の半径及び角度の範囲で規定される、乗車予定地から離間された領域である。

近方の同心円６０３の半径ｒ₁は、例えば乗車申込を運転者端末２００に送信し、その後運転者が該申込に対する受け入れの可否を選択した後、（承諾の場合に）実際に乗車予定地に到達することが可能な距離に設定されることが好ましく、予め定数として設けられるものであってよい。また、例えば乗車予定時刻が設定される場合や、希望者が乗車目的地に（徒歩等で）到着する到着予定時刻の少なくともいずれかに基づき、半径ｒ₁は変更されるものであってもよい。即ち、処理や応答操作さらには車両の移動に要する必要な時間経過も考慮して、探索領域を離間させる距離（近方の同心円６０３に係る半径ｒ₁）は調整されるものであってよい。

また遠方の同心円６０４の半径ｒ₂は、例えば半径ｒ₁との相対関係が定められるものであってよく、領域が広大になりすぎないよう、ｒ₂−ｒ₁の値は固定値であってもよい。また、角度範囲を規定する直線６０５及び６０６に係る角度θも、決定された進行方向の負の方向を中心として同様の基準で設定されるものであってよいし、例えば近方の同心円が乗車予定地から遠離しても探索領域の面積が一定の範囲内に収まるように、半径ｒ₁に反比例して（ｒ₁が短いほどθが大きく、ｒ₁が長いほどθが小さく）定められるものであってもよい。

本実施形態ではこのように、乗車予定地から目的地に向かう方向を進行方向として定め、乗車予定地付近を通過し、目的地方面に進行するであろう車両の存在確率が高いと推定される探索領域を定めるものとして説明するが、本発明の実施はこれに限られるものではない。探索領域の定め方は、探索及び乗車申込に係る処理につき、進行方向に基づく相乗り運転の成立可能性を考慮しつつ、演算対象や演算量の低減を好適に実現するものであれば、形状や規定ルール等を変形してもよいことは言うまでもない。

設定部１０９による探索領域の設定がなされた後、管理制御部１０１は、運転者ＤＢ１０５に管理されている運転者情報に基づき、該探索領域に存在する車両に係る運転者情報を抽出し、このうちから乗車要求を行う運転者端末２００の探索を行う。より詳しくは、管理制御部１０１は、管理されている運転者情報のうち、端末位置履歴５０３の最新の位置情報が探索領域内に含まれる運転者情報を抽出する。そして管理制御部１０１は、抽出した運転者情報に係る車両の移動履歴（端末位置履歴５０３）について、例えば進行方向に進行しているか否かを判断する処理を含む探索処理を行うにより、乗車申込を行う運転者端末２００を決定する。進行方向に進行しているか否かは、厳密に進行方向に進行している車両の移動履歴を探索するのではなく、例えば移動履歴を車両の速度ベクトルに変換した場合に、進行方向に係る速度成分の割合が閾値を超える場合に、進行方向に進行していると判断する等であってよい。

このように探索領域についての探索に基づき乗車申込を行う運転者端末２００を決定すると、管理制御部１０１は、決定した運転者端末２００に対して、希望者の乗車希望に係る乗車申込に係る情報を、管理通信部１１０を介して送信する。乗車申込に係る情報は、運転者端末２００において希望者の乗車予定地及び目的地を提示し、同乗を承諾するか否かを運転者に選択させる動作を、サービスアプリにて実行させるものであってよい。

〈乗車承諾〜相乗り運転管理〉
乗車申込を行った運転者端末２００において申込が承諾されると、運転制御部２０１は承諾を示す情報を管理サーバ１００に返送する。管理制御部１０１は、該情報を受信すると、該当の希望者情報の成立済フラグ５１５を真（Ｔｒｕｅ）に更新し、乗車予約状態とする。また管理制御部１０１は、承諾により相乗り運転の実施が確定した運転者と希望者につき、対応する運転者情報及び希望者情報に基づいてドライブ情報を生成し、相乗りＤＢ１０７に登録する。ドライブ情報の希望者情報５２３に含まれる乗車情報５４３及び降車情報５４４は、例えばドライブ情報に係る端末位置履歴５３２と端末位置履歴５４２の一致度を算出することで、同一の車両に乗車して移動中であるか否かが判断され、当該移動の開始時、終了時にそれぞれ入力されればよい。

なお、本実施形態では管理制御部１０１が、運転者に係る端末位置履歴５３２と希望者に係る端末位置履歴５４２との一致度をもって相乗りしているかの判断を行うものとして説明するが、本発明の実施はこれに限られるものではない。即ち、同乗しているか否か、あるいは乗車したか降車したかは、必ずしも位置情報の推移で判断する手法に限られず、例えば車両に搭載された所定のビーコンや運転者端末２００から定期的に発生される信号を、希望者端末３００において所定回数受信した、あるいは所定期間内に受信していることをもって、管理制御部１０１が同乗していると判断する等、どのような手法が用いられてもよいことは言うまでもない。

また、乗車申し込みが承諾された場合には、管理制御部１０１は対象の希望者端末３００に対し、同乗の承諾がなされたこと、及び運転者、車種及びカラー、車両の現在位置等の乗車する車両に係る種々の情報を通知すればよい。

《提供処理》
上述のような構成をもつ本実施形態の管理サーバ１００で実行される、１つの乗車希望に基づき車両探索、乗車申込、及び相乗り運転の予約を行う、相乗りシステムに係るサービス提供を実現する提供処理について、図７のフローチャートを用いて具体的な処理を説明する。該フローチャートに対応する処理は、管理制御部１０１が、例えば管理記録媒体１０２に記憶されている対応する処理プログラムを読み出し、管理メモリ１０３に展開して実行することにより実現することができる。なお、本提供処理は、例えば希望者端末３００から乗車希望に係る情報を受信した際に開始されるものとして説明する。

Ｓ７０１で、管理制御部１０１は、受信した乗車希望に係る情報に基づき、希望者ＤＢ１０６に新たな希望者情報を登録する。

Ｓ７０２で、決定部１０８は管理制御部１０１の制御の下、新たに登録された希望者情報の乗車希望情報５１４に基づき、探索の基準となる進行方向を決定する。上述したように、本実施形態では決定部１０８は、乗車予定地から目的地に向かう方向を進行方向として決定する。

Ｓ７０３で、設定部１０９は、新たに登録した希望者情報の乗車希望情報５１４及び決定された進行方向に基づき、図６（ａ）のような探索領域６００を設定する。

Ｓ７０４で、管理制御部１０１は、設定された探索領域に基づき、乗車申込の送信先とする運転者端末２００の探索に係る探索処理を行う。本実施形態の探索処理では、上述したように設定された探索領域内に存在する運転者端末２００のうち、進行方向に進行している端末位置履歴５０３を示す運転者端末２００を探索するものとして説明する。

Ｓ７０５で、管理制御部１０１は、探索結果に基づき該当の運転者端末２００に対して乗車申込の送信を行う。

Ｓ７０６で、管理制御部１０１は、乗車申込の承諾がなされたことを示す情報（承諾情報）を受信したか否かを判断する。本実施形態の相乗りシステムでは簡単のため、最初に受信した承諾情報の送信元である運転者端末２００に係る車両を、希望者の乗車する車両として決定するものとして説明するが、例えば希望者による最終確認の工程を設ける等、これに限られるものではない。管理制御部１０１は、承諾情報を受信したと判断した場合は処理をＳ７０７に移す。また管理制御部１０１は、承諾情報を受信していない場合は本ステップの処理を繰り返し、受信していない期間が所定のタイムアウト時間に至った場合には処理をＳ７０３に戻し、新たな探索領域の設定を行う。

探索領域は例えば、１つの乗車希望につき最初にＳ７０３の処理が行われる際には、乗車予定地を中心とする予め定められた半径範囲及び角度範囲の領域が設定され、２回目以降に行われる際には、該半径及び角度の少なくともいずれかの範囲を拡張する等により探索対象となる端末数が増加するよう設定されるものであってよい。この場合、同一の運転者端末２００に対して乗車申込を送信する回数に上限（例えば１回）を設け、探索領域の拡大に伴う、探索対象の運転者端末２００の数の増加率を低減するように構成してもよい。

また乗車申込を送信する端末数に下限を設け、設定した探索領域につき送信端末数の条件が満たされない場合には、乗車申込の送信せずに探索領域を拡張して再設定し、拡張後の探索領域について改めて探索処理を行って送信先とする運転者端末２００を決定するものとしてもよい。このように構成することで、好適な結果が得られない（乗車申込を送信したとしても乗車申込が承諾されない、あるいは承諾される確率が低い（受信する運転者端末２００の絶対数に基づく））乗車申込の送信により通信帯域を占有してしまう状況の発生を低減し、より相乗り運転の成立確度が高い状況にて、乗車申込の送信を行うことが可能となる。

なお、探索領域の再設定を含む乗車申込の送信（対象とする運転者端末２００への一斉送信、即ちＳ７０５の実行）には、回数に制限が設けられるものであってよい。この場合、制限回数の乗車申込の送信に対する承諾情報の受信が得られないのであれば、管理制御部１０１は希望の条件を満たす車両が見つからなかった旨の情報を該当の希望者端末３００に送信し、サービスアプリにて通知させる構成としてよい。

Ｓ７０７で、管理制御部１０１は、受信した承諾情報に基づきドライブ情報を生成し、相乗りＤＢ１０７に登録し、端末位置履歴に係る該情報の更新を開始する。また管理制御部１０１は、Ｓ７０１で登録した希望者情報の成立済フラグ５１５を更新する。さらに管理制御部１０１は、乗車希望に係る相乗り運転が承諾されたことを示す情報を該当の希望者端末３００に送信し、例えばサービスアプリにて乗車に係る詳細（運転者の情報、車種、カラー等）を通知させる。

以上説明したように、本実施形態の相乗りシステムでは、なされた乗車希望に対して乗車申込を行う対象を、承諾がなされる可能性が高い領域に存在する車両の運転者端末に制限することができるため、探索処理や乗車申込送信に係る処理負荷を低減しつつ、好適なサービス提供が可能となる。なお、本実施形態では相乗り運転に係り、乗車申込を行う対象を限定する態様について説明したが、本発明が例えば配車サービス等、希望者を乗車させる車両を探索する他の態様についても利用可能であることは言うまでもない。

［変形例］
上述した実施形態１では、設定した探索領域に存在する車両のうち、移動履歴に基づいて進行方向に進行していると推定される車両に係る運転者端末２００に対し、乗車申込を行うものとして説明したが、本発明の実施はこれに限られるものではない。

例えば、相乗りシステムとして、実施されるドライブについて、事前に運転者によって行き先や運転経路計画の設定がなされ、該経路計画の情報を含んで運転者情報が構成される場合、より乗車申込の承諾がなされやすい運転者端末２００に限定して、乗車申込の送信を行うよう構成することができる。より詳しくは、提供処理のＳ７０４において探索処理を行う際に、現在の車両位置から設定された行き先に至るまでに採り得る運転経路、あるいは事前に設定されている運転経路計画にて通過する地点に乗車予定地が含まれるか否かを基準に、管理制御部１０１は乗車申込の送信先とする運転者端末２００を探索してもよい。あるいは、乗車予定地を通過する経路を採用した場合の、事前に設定されている運転経路計画からの変更度合いが、運転者が許容すると定めた範囲（例えば総走行距離、ドライブ行き先への到着予想時刻や、予想燃料消費量等）に納まるか否かを基準に、管理制御部１０１は乗車申込の送信先とする運転者端末２００を探索してもよい。また乗車予定地のみに限らず、さらに希望者の目的地も含めて乗車申込が承諾されるか否かを推定し、乗車申込の送信先とする運転者端末２００を決定するものとしてもよい。

このように構成することで、移動履歴に基づいて推定された車両の進行方向を基準に探索処理を行う場合よりも（特に進行方向特定に係る）演算量を低減し、かつ乗車申込が承諾されやすい運転者端末２００に対して、乗車申込の送信を行うことができる。またＳ７０２で決定した進行方向に基づく探索領域に限定して探索処理を行うため、運転者が設定したドライブに係る行き先や出発地のみに基づいて探索を行う場合に比べ、より効率的に、乗車申込が承諾され得る運転者端末２００を特定することができる。

［実施形態２］
上述した実施形態１及び変形例では、図６（ａ）に示したような、進行方向に基づいて定まる所定の領域を探索領域として設定する態様、また承諾情報が受信されない場合にはさらに拡張した領域を探索領域として設定する態様について説明した。

ところで、例えば幹線道路のような交通量の多い道路が探索領域に含まれる場合、探索処理において処理対象となる運転者端末２００は増大し得る。一方で、図６（ｂ）に示されるように、乗車予定地がこのような道路６１３上ではなく、該道路６１３と交差する（特には交通量が比較的少ない）道路６１４上にある場合には、探索領域６１０に含まれる車両のうち、乗車予定地６１１にまで至る車両が占める割合は低くなり得る。例えば、交通量の異なる道路が交差する交差点では、交通量の多い道路から右左折して交通量の少ない道路に進入する車両数は、交通量の多い道路を進行し続ける車両数と、交通量の少ない道路から右左折して交通量の多い道路に進入する車両数との合計に比べて少ない。故に、探索領域に含まれる車両数が多くとも乗車予定地に至る車両数は少なく、探索処理に係る演算量に見合った成果（相乗り運転成立）が得られない可能性があった。

本実施形態ではこのような態様を考慮し、設定した探索領域をさらに該領域内の道路条件に応じて調整することで、管理サーバ１００における演算負荷を低減しつつ、相乗り運転を効率的に実現させる態様について説明する。なお、本実施形態に係る管理サーバ１００は、実施形態１の機能構成に加え、各道路についての情報（道路情報）を管理する道路情報ＤＢ１２０を有する。道路情報ＤＢ１２０において管理される道路情報は、例えば各道路について統計的に得られた交通量や、該道路を用いる経路について統計的に得られた交通量を含むものであってよい。

《提供処理》
以下、本実施形態の提供処理について、図８のフローチャートを用いて具体的な処理を説明する。なお、本実施形態の提供処理において実施形態１の提供処理と同様の処理を行うステップについては同一の参照番号を付し、以下では本実施形態に係り特徴的な処理を行うステップについて主に説明する。また以下では簡単のため、乗車予定地を通り、決定された進行方向に係り乗車予定地から前後に延びて探索領域を貫通する道路を、探索領域の調整の基準（基準道路）として用いるものとして説明する。しかしながら本発明の実施はこれに限られるものではなく、基準道路は、探索領域内を通り乗車予定地に至る道路であればどのような基準で設定されるものであってもよい。好適には基準道路は、交差点における右左折を含まず、探索領域内から進行方向に延び、乗車予定地に至る道路として設定されるものであってよい。

Ｓ７０３において探索領域が設定された後、管理制御部１０１はＳ８０１で、探索領域に含まれる道路のうち、基準道路として設定する道路を選択する。基準道路は、上述したように予め定められた条件に基づき選定されるものであってよい。図６（ｂ）の例では道路６１４が、車両が進行方向に進行した場合に乗車予定地６１１に至る道路であるため、基準道路として選択される。管理制御部１０１は、選択した基準道路の情報を管理メモリ１０３に格納し、処理をＳ８０２に移す。

Ｓ８０２で、管理制御部１０１は、探索領域に含まれる道路のうちの設定した基準道路と交差する道路（交差道路）について、該道路に存在する車両に係る運転者端末２００を探索処理の対象とするか否かを判断する。該判断は、道路情報ＤＢ１２０において管理される道路情報に基づいて行われる。本実施形態では管理制御部１０１は、交差道路の統計的な交通量が、予め定められた閾値を超えて基準道路の統計的な交通量よりも多い場合に、該交差道路に存在する車両に係る運転者端末２００を処理対象から除外するものとして判断する。これは、基準道路と比べて相対的に交通量が多い交差道路は、走行している車両が該交差道路から右左折して基準道路に進入する可能性が低いと考えられることに依る。即ち、該交差道路を走行する車両に係る運転者端末２００を探索処理の対象とした場合、該当の運転者端末２００では乗車申込が承諾されない可能性が高く、探索処理の演算量に見合った成果が得られないと推定されるため、本実施形態の管理サーバ１００では該交差道路を探索処理の対象から除外する。

Ｓ８０３で、設定部１０９は、Ｓ８０２における判断結果に基づき探索領域の調整を行う。具体的には設定部１０９は、Ｓ８０２において探索処理の対象としないと判断した交差道路のうち、乗車予定地に最も近い交差道路を特定し、該交差道路を含まない範囲に探索領域を調整する。例えば、図６（ｂ）において道路６１４が基準道路として設定され、道路６１３が探索処理の対象としないと判断された、最も乗車予定地に近い交差道路である場合、設定部１０９は先に決定した探索領域６１０を、図６（ｃ）に示される探索領域６２０のように変更する。図６（ｃ）の例では探索領域６２０は、道路６１３を除外するよう、乗車予定地から該道路６１３までの距離ｒ₃を半径とする同心円が探索領域６２０の遠方の境界となるよう、探索領域６１０の定義を調整することで設定される。

そして調整された探索領域に基づき、管理制御部１０１はＳ７０４で探索処理を行う。このように、探索領域内の道路条件に応じて動的に探索範囲を調整することで、本実施形態の相乗りシステムによれば、探索処理に係る演算量及び乗車申込の送信に係る通信帯域占有を好適に低減することができる。

なお、本実施形態では単に交差する道路間での統計的な交通量の差に応じて、探索領域の調整を行う態様について説明したが、本発明の実施はこれに限られるものではない。探索領域の調整は、交通量の差に応じて行われるものでなく、基準道路に進入する経路を採る車両の割合が閾値を下回る交差道路を除外するよう行われるものであってよい。

例えば、図６（ｂ）の道路６１３を走行する車両における、交差点にて右左折して道路６１４に進入し、さらに進行方向６１２に進行する経路をとる車両の数や割合（統計に基づく）が、道路情報として管理される場合、管理制御部１０１は該割合の情報に基づき、道路６１３を探索処理の対象とするか否かを判断するものであってもよい。即ち、例えば図９（ａ）に示されるように、道路６１３を走行する車両のうち、矢印９０１の方向（以下、北とする）に進行し、交差点９０５にて右折して道路６１４に進入する車両の割合９０２と、矢印９０３の方向（南）に進行し、交差点９０５にて左折して道路６１４に進入する車両の割合９０４との総計が所定の割合を占めるのであれば、該道路６１３を処理対象とすることで、将来的に道路６１４を進行方向に進行し得る車両をより多く含めて探索処理を行うことができる。

なお、このように右左折して道路６１４に進入する車両の割合を考慮する場合、道路６１３の両方向の車線を走行する車両における、道路６１４に進入し得る車両の割合によって、道路６１３を探索処理の対象とするか否かを判断する必要はない。即ち、道路６１３の各方向の車線について道路６１４に進入し得る車両の統計情報が保持されており、道路６１３を探索処理の対象とするか否かは、交差点９０５の以北、以南の各々について等、地理的条件も考慮してなされるものであってよい。

また、交差道路から基準道路に進入する交通量を考慮して、該交差道路を探索処理の対象とすると判断された場合、図６（ｄ）に示されるよう、設定部１０９は該交差道路６１３の、探索領域に含まれていなかった範囲６３１（図のハッチング領域）を探索領域６１０に含める（探索領域６３０とする）よう調整を行ってもよい。例えば幹線道路等の交通量が比較的多い道路では、制限速度も大きく、車両の平均移動速度も大きいと推定できる。故に、探索領域においてこのような交通量の多い道路に存在する車両は、他の道路に存在する車両よりも短い時間で乗車予定地に到達し得る。このため、探索領域内の他の道路に存在する車両と同条件の時間内に乗車予定地に到達する車両を探索するのであれば、該交通量の多い道路の、探索領域に含まれない範囲に存在する車両も対象とするよう、設定部１０９は調整を行ってもよい。

本実施形態では交差道路を探索処理の対象としないと判断した場合に、該交差道路を含まない範囲に探索領域を調整するものとして説明したが、本発明の実施はこれに限られるものではない。即ち、例えば図９（ｂ）に示されるように、交差点９０５の以西から道路６１４を進行方向に進行する車両における、交差点９０５を直進する車両（右左折して道路６１３に進入しない車両）の割合９１１が所定の割合を占めるのであれば、道路６１３を処理対象外とする場合であっても、交差点の以西の領域９１２は探索領域から除外しないよう調整（領域９１２と領域９１３が探索領域）が行われてもよい。換言すれば、設定した探索領域について、特定の交差道路６１３のみを処理対象から除外（マスク）するよう、調整は行われてもよい。このような態様は、例えば交差道路が交差点にて高架上を通過する道路である場合等にも有用である。なお、交差道路が高架上及び高架下の双方に道路を有する場合、交差道路を探索処理の対象とする場合であっても、移動履歴より導かれる移動速度が閾値を超える運転者端末２００については、高架上の道路を走行中の車両であるとして、乗車申込の送信先から除外するよう構成すればよい。

また一度設定された探索領域について、交通量が閾値を超える該探索領域外の道路を含むような探索領域の調整がなされる態様は、これに限られる必要はない。例えば、希望者の乗車予定時刻、及び希望者が乗車予定地に到着する到着予定時刻の少なくともいずれかまでの時間が所定の時間以上ある場合、乗車予定地に至り得る車両に係る運転者端末２００を探索領域につき探索する処理は、実際の相乗り運転の実施まで時間的隔たりがあるため、乗車申込が承諾され得る運転者端末２００を好適に抽出できない可能性がある。即ち、変形例のような運転者が車両の行き先や経路等の設定がなされない態様では、提供処理の実施と相乗り運転の開始との時間の隔たりが大きいほど、乗車申込が承諾され得る運転者端末２００を好適に特定できない可能性がある。一方で、このような時間的隔たりは、演算量増大による多少の遅延を許容することができるため、探索処理の対象は多少増加したとしても影響は低いと考えられる。例えば図９（ｃ）に示されるように、一度設定した探索領域９２０に近接して存在する、閾値以上の交通量を有する（交通量の多い）道路９２１を走行中の車両は、平均移動速度が高く、許容できる時間内に探索領域９２０に進入し得ると考えられる。このため、上述した図６（ｄ）の例と同様に、道路９２１の一部の範囲９２２（図のハッチング領域）を探索領域９２０に含めるよう設定部１０９は調整を行ってもよい（図の太線で示される領域９２３が調整後の探索領域）。

なお、道路の交通量は、時間帯、天候に応じて変化するものであるため、これを考慮し、探索領域の調整を行うものとしてもよい。従って、各道路の統計的な交通量は、時間的条件、気象的条件、及び地理的条件（交差点との位置関係）の少なくともいずれかに対応付けて管理されるものであってよく、管理制御部１０１は該当する条件の統計的な交通量の情報を参酌し、道路を探索処理の対象とするか否かの判断を行うものであってよい。

［実施形態３］
上述した実施形態１及び２、変形例では、乗車予定地から目的地に向かう方向を進行方向として決定し、該進行方向に基づき探索領域の設定を行うものとして説明したが、進行方向の決定はこれに限られるものではない。

乗車予定地から目的地に向かう方向を進行方向として決定する態様は、例えば乗車予定地が幹線道路のような交通量が比較的多い道路脇である場合、乗車予定地から目的地までが比較的近距離である場合等に有効である。一方で、任意の車両が乗車予定地から目的地に向けて走行する際に採用する経路は、乗車予定地から、必ずしも目的地の方向に移動するわけではない。即ち、特に乗車予定地から目的地までが比較的遠距離であるケース等、図１０（ａ）に示されるように乗車予定地１００１と目的地１００２とを結ぶ道路が存在しない、あるいは乗車予定地１００１と目的地１００２とを略直線的に結ぶ経路が走行し難い（道幅が狭い、右左折回数が多い等）場合、乗車予定地から目的地を結ぶ方向の経路は運転者に敬遠されがちである。

故に、一般的な運転技能を有する運転者は、例えば図１０（ａ）示されるような、乗車予定地１００１から道路１００３を走行して交差点１００４に至り、交差点１００４を左折して道路１００５に進入し、交差点１００６まで道路１００５を走行した後、交差点１００６を左折して道路１００７に進入し、交差点１００８まで道路１００７を走行した後、交差点１００８を右折して道路１００９に進入し、目的地１００２に至る経路を採用し得る。ここで、道路１００５及び道路１００７は、統計的な交通量が閾値よりも多く、車線数や道幅、あるいは制限速度の観点で走行し易い道路である。

本実施形態では、このような運転者が採り得る経路を考慮して進行方向を定めることで、より相乗り運転の成立可能性を高める手法について説明する。なお、本実施形態の管理サーバ１００の構成は、例えば実施形態２と同様に、道路情報ＤＢ１２０を有するものとする。

《提供処理》
以下、本実施形態の管理サーバ１００で実行される提供処理について、図１１のフローチャートを用いて具体的な処理を説明する。なお、本実施形態の提供処理において実施形態１の提供処理と同様の処理を行うステップについては同一の参照番号を付し、以下では本実施形態に係り特徴的な処理を行うステップについて主に説明する。

Ｓ７０１において新たな希望者情報を登録すると、管理制御部１０１はＳ１１０１で、該希望者情報の乗車希望情報５１４に基づき、乗車予定地から目的地に至るために採用され得る１つの経路を、基準経路として定める。基準経路は、上述したように運転し易さの観点で定められるものであってよく、交通量が閾値を超える幹線道路をなるべく含む等、既存の手法を用いて定められるものであってよい。

Ｓ１１０２で、管理制御部１０１は、基準経路に基づいて希望者に係る相乗り運転において車両が走行し得る領域（走行領域）を特定する。本実施形態では図１０（ｂ）に例示されるような、地図上に予め定めたグリッドによって、地図上を所定の大きさの領域に分離しており、管理制御部１０１はこのうち、基準経路（乗車予定地１００１→道路１００３→交差点１００４→道路１００５→交差点１００６→道路１００７→交差点１００８→道路１００９→目的地１００２）が含まれる領域を特定する。即ち、図１０（ｂ）の例では、管理制御部１０１は領域１０１１〜１０１９を走行領域として特定する。特定した走行領域は、乗車予定地からの基準経路での進行順に対応付けられて、例えば管理メモリ１０３に格納されるものとする。

Ｓ１１０３で、決定部１０８は、Ｓ１１０２において特定した走行領域のうちの、まだ進行方向の決定に用いられていない走行領域を、基準経路での進行順に従って対象走行領域として選択する。

Ｓ１１０４で、決定部１０８は、対象走行領域内に含まれる基準経路中の道路に基づき、探索の基準となる進行方向を決定する。即ち、例えば領域１０１３が対象走行領域として選択された場合、決定部１０８は図１０（ｃ）に示されるように、乗車予定地から該領域内に含まれる基準経路中の道路１０２１（道路１００５の一部）に向かう方向を、進行方向として決定する。乗車予定地から道路１０２１に向かう方向を決定するために必要となる（ハッチングで示される）道路１０２１上の点は、例えば図１０（ｃ）のように領域１０１３における道路１０２１の中点１０２２であってもよいし、該領域における道路１０２１のいずれかの端点やその他の基準で定められる点であってもよい。

また、図１０（ｂ）に示される領域１０１２のように、基準経路中の複数の道路が対象走行領域内に含まれる場合、このうち交通量の多い方の道路に向かうよう、進行方向は決定されるものとしてもよい。このように進行方向をすることで、基準経路を利用し得る車両がより多く対象に含まれる探索領域を設定することができる。また、例えば領域１０１５のように、該領域内に含まれる基準経路中の複数の道路（道路１００５及び１００７）が、いずれも多いと判断する閾値を上回る交通量を示す（幹線道路等である）場合、より目的地に到達すると推定される、進行順において後である道路１００７を、進行方向の決定基準としてもよい。あるいは、これらの道路に至った場合に、目的地方向に進行する車両の割合が高い道路を、進行方向の決定基準としてもよい。

進行方向が決定された後、設定部１０９は該進行方向に基づきＳ７０３で探索領域の設定を行う。なお、本実施形態の提供処理では、１つの進行方向について複数のサイズの探索領域を設定して繰り返し探索処理を行うよう構成せず、管理制御部１０１はＳ７０６において承諾情報を受信していない機関が所定のタイムアウト時間に至った場合には処理をＳ１１０３に戻し、進行順において次となる走行領域を対象走行領域に選択し、進行方向を順次変更するよう処理を行うものとする。

以上説明したように、本実施形態の提供処理によれば、乗車予定地から目的地まで至り得る車両の移動経路を推定し、該推定に基づいて進行方向を順次定めて探索領域の設定及び探索処理の実行を制御することができる。このような態様によれば、例えば乗車予定地と目的地とが遠離しており、乗車予定地から目的地に向かう方向に基づき探索領域を設定した場合に、該方向に進行する車両が少なく、相乗り運転の成立可能性が低くなり得るようなケースであっても、好適に目的地に到達し得る車両（に係る運転者端末２００）を探索することができる。

また基準経路を定め、進行順に対象走行領域を設定して行うことで、乗車予定地の近辺にいる車両が走行する可能性の高い、交通量の多い道路について進行方向を順次定めて探索処理を行うことができるため、例えば相乗り運転の乗継も許容する希望者については、より早く希望者が乗車できる車両を案内することができる。即ち、目的地には到達せずとも、基準経路の途中まで移動できるのであれば、再度その降車地点から別の車両を探索した場合に、同様の基準経路（降車地点より先）を走行する車両を発見できる可能性は高いと推定される。結果、希望者の希望する相乗り運転を、より好適に提供することが可能となる。

なお、本実施形態では、対象走行領域内に含まれる基準経路中の道路について、乗車予定地からの進行方向を定めるものとして説明したが、本発明の実施はこれに限られるものではない。例えば、上述したように相乗り運転の乗継を許容する希望者については、基準経路に基づき設定された走行領域に至ることができれば、基準経路を進行し得るさらに別の車両に該走行領域から乗り継げる可能性は高くなると想定されるため、進行方向の決定基準となる道路は、対象走行領域内の最も交通量の多い道路として設定してもよい。また例えば、進行方向の決定の基準とする道路は、統計的な交通量が、交通量が多いと判断する所定の閾値を上回る道路に限定することで、進行方向の決定回数を低減させ、相乗り運転の成立確率がより高いと考えられる進行方向についてのみ、探索処理が行われるようにしてもよい。

［その他の実施形態］
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。また本発明に係る情報処理装置は、１以上のコンピュータを該情報処理装置として機能させるプログラムによっても実現可能である。該プログラムは、コンピュータが読み取り可能な記録媒体に記録されることにより、あるいは電気通信回線を通じて、提供／配布することができる。

１００：管理サーバ、１０１：管理制御部、１０２：管理記録媒体、１０３：管理メモリ、１０４：ユーザＤＢ、１０５：運転者ＤＢ、１０６：希望者ＤＢ、１０７：相乗りＤＢ、１０８：決定部、１０９：設定部、１１０：管理通信部、１２０：道路情報ＤＢ

Claims (20)

1. 車両への乗車を希望する希望者につき、乗車予定地と目的地の情報を取得する取得手段と、
   前記取得手段により取得された情報に基づき、前記乗車予定地から前記目的地への移動に係る進行方向を決定する決定手段と、
   前記決定手段により決定された前記進行方向に基づき、前記希望者の乗車申込を行う車両を探索する探索領域を設定する設定手段と、を有し、
   前記設定手段は、前記乗車予定地から前記進行方向の反対方向に、前記乗車予定地から離間して存在する所定の領域を、前記探索領域として設定する
   ことを特徴とする情報処理装置。
2. 前記設定手段により設定された前記探索領域内の道路条件に応じて、前記探索領域を調整する調整手段をさらに有することを特徴とする請求項１に記載の情報処理装置。
3. 前記調整手段は、前記探索領域内に含まれる道路または該道路を用いる経路につき、統計的な交通量が所定の条件を満たすか否かに応じて、前記探索領域を調整することを特徴とする請求項２に記載の情報処理装置。
4. 前記調整手段は、前記探索領域内に含まれる所定の条件の道路を用いる経路の統計的な交通量が閾値を下回る場合に、該所定の条件の道路を除外した範囲に前記探索領域を調整することを特徴とする請求項３に記載の情報処理装置。
5. 前記調整手段は、前記探索領域内に含まれる前記進行方向と交差する道路から前記進行方向に向かう道路に進入する統計的な交通量が閾値を上回る場合に、前記交差する道路のうちの前記探索領域に含まれない範囲も含めるよう、前記探索領域を調整することを特徴とする請求項３または４に記載の情報処理装置。
6. 前記統計的な交通量は、時間的条件、気象的条件、及び地理的条件の少なくともいずれかに対応付けられて予め記憶されていることを特徴とする請求項３乃至５のいずれか１項に記載の情報処理装置。
7. 前記取得手段は、前記希望者が前記乗車予定地での乗車を希望する乗車予定時刻、及び前記希望者が前記乗車予定地に到着する到着予定時刻の少なくともいずれかをさらに取得し、
   前記設定手段は、前記取得手段により取得された前記乗車予定時刻及び前記到着予定時刻の少なくともいずれかと前記進行方向とに基づき、前記探索領域を設定することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記設定手段は、前記乗車予定時刻及び前記到着予定時刻の少なくともいずれかに応じて、前記探索領域を前記乗車予定地から離間させる距離を決定することを特徴とする請求項７に記載の情報処理装置。
9. 前記設定手段は、前記乗車予定時刻及び前記到着予定時刻の少なくともいずれかまでの時間が閾値を上回る場合に、前記所定の領域外の、閾値を上回る統計的な交通量を有する道路を含めて前記探索領域を設定することを特徴とする請求項７または８に記載の情報処理装置。
10. 前記決定手段は、前記乗車予定地から前記目的地に向かう方向を前記進行方向として決定することを特徴とする請求項１乃至９のいずれか１項に記載の情報処理装置。
11. 前記決定手段は、前記目的地に関連付けられた所定の道路に前記乗車予定地から向かう方向を、前記進行方向として決定することを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理装置。
12. 前記所定の道路は、前記乗車予定地から前記目的地への移動経路として選択される道路であることを特徴とする請求項１１に記載の情報処理装置。
13. 前記所定の道路は、前記移動経路に選択される道路のうちの、統計的な交通量が閾値を上回る道路であることを特徴とする請求項１２に記載の情報処理装置。
14. 前記設定手段は、設定した前記探索領域に基づき行われた車両の探索結果に応じて、複数回の前記探索領域の設定を行うものであり、
    前記決定手段は、前記乗車予定地から前記目的地への移動経路に基づいて設定した、所定の大きさを有する複数の地理領域のそれぞれを順次選択し、選択した地理領域に含まれる前記所定の道路に前記乗車予定地から向かう方向を前記進行方向として決定し、
    前記設定手段は、前記決定手段により順次決定された前記進行方向に基づき、複数の前記探索領域を順次設定することを特徴とする請求項１１乃至１３のいずれか１項に記載の情報処理装置。
15. 前記設定手段により設定された前記探索領域につき、前記目的地に到達すると推定される車両を探索する探索手段と、
    前記探索手段による探索の結果、前記目的地に到達すると推定される車両に係る通信端末に対し、前記希望者の乗車に係る要求を送信する送信手段と、をさらに有することを特徴とする請求項１乃至１４のいずれか１項に記載の情報処理装置。
16. 前記設定手段は、前記探索手段による探索の結果、前記目的地に到達すると推定される車両の数が所定数を下回る場合に、前記探索領域を再設定することを特徴とする請求項１５に記載の情報処理装置。
17. 前記所定の領域は、前記乗車予定地を中心として、所定の半径及び角度の範囲で規定される領域であり、
    前記設定手段は、前記目的地に到達すると推定される車両の数が所定数を下回る場合に、前記所定の領域の半径及び角度の少なくともいずれかの範囲を変更することで、前記探索領域を拡大して再設定することを特徴とする請求項１６に記載の情報処理装置。
18. 前記探索手段は、前記探索領域に存在する車両の各々につき予め登録された運転経路計画に基づき、前記目的地に到達すると推定される車両を探索することを特徴とする請求項１５乃至１７のいずれか１項に記載の情報処理装置。
19. 車両への乗車を希望する希望者につき、乗車予定地と目的地の情報を取得する取得工程と、
    前記取得工程において取得された情報に基づき、前記乗車予定地から前記目的地への移動に係る進行方向を決定する決定工程と、
    前記決定工程において決定された前記進行方向に基づき、前記希望者の乗車申込を行う車両を探索する探索領域を設定する設定工程と、を有し、
    前記設定工程において、前記乗車予定地から前記進行方向の反対方向に、前記乗車予定地から離間して存在する所定の領域が、前記探索領域として設定される
    ことを特徴とする探索領域設定方法。
20. コンピュータを、請求項１乃至１８のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。

Images