JP6333433B1 - 情報処理装置、車両探索方法及びプログラム - Google Patents

Abstract

【課題】所望の目的地への移動を行う車両探索に係る演算負荷を低減する。【解決手段】情報処理装置は、車両への乗車を希望する希望者の乗車予定地と対応付けられた対応道路を特定し、特定した対応道路に基づき、希望者の乗車申込を行う車両を探索する探索道路を決定する。また、決定した探索道路に存在する車両のうちから、乗車申込を行う車両を探索する。装置は、特定した対応道路の種別に応じて、探索道路を異ならせる【選択図】図７

Description

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

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

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

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

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

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

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

前述の目的を達成するために、本発明の情報処理装置は、車両への乗車を希望する希望者の乗車予定地の情報を取得する取得手段と、乗車予定地と対応付けられた対応道路を特定する特定手段と、特定手段により特定された対応道路に基づき、希望者の乗車申込を行う車両を探索する探索道路を決定する制御手段と、制御手段により決定された探索道路に存在する車両のうちから、乗車申込を行う車両を探索する探索手段と、を有し、制御手段は、特定手段により特定された対応道路の種別に応じて、探索道路を異ならせることを特徴とする。

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

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

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

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

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

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

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

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

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

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

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

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

運転者情報は、例えば図５（ａ）に示されるように、運転者情報を識別する運転者ＩＤ５０１に関連付けて、運転者であるユーザにつきユーザＤＢ１０４に登録されているユーザＩＤ５０２、該ユーザの使用する運転者端末２００において取得された位置情報の履歴を時系列で示す端末位置履歴５０３、及び現在の車両が存在する道路の種別を示す走行道路種別５０４を管理するものであってよい。走行道路種別５０４は、後述の第１種別道路と第２種別道路のいずれに車両が存在するか、さらにはいずれの方向に進行する車線に存在するかを管理するものであってよい。また、同乗者情報５０５には、同乗者の有無、同乗者への通知の可否、同乗者による運転者端末２００の代理応答の可否等が含まれる。ここでの同乗者は、相乗りによって同乗した者ではなく、例えば、運転者であるユーザの家族が同乗している場合のように、出発時或いは運転者モードでのサービスアプリを起動した時点で同乗している者としてもよい。

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

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

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

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

特定部１０８は、希望者端末３００から受信した乗車希望について、希望者の乗車予定地に対応する道路（対応道路）の種別を特定する。道路の種別とは、一般車両の通行可否や法定交通ルール等に基づいて定められるものであってよく、本実施形態の相乗りシステムでは道路の種別として、少なくとも一般車両の通行が認められている道路につき、第１種別道路（一般道路）及び第２種別道路（有料道路）を含むものとする。第１種別道路と第２種別道路とは、例えば通行に係る料金の支払要否において分別されるものであり、第１種別道路が料金の支払いが不要である一方で、第２種別道路は料金の支払いが要求されるものであってよい。また第１種別道路と第２種別道路とは、例えば規定されている制限速度により分別されるものであり、第１種別道路は最高速度が時速６０ｋｍ以下に設定される一方で、第２種別道路は最高速度が時速６０ｋｍを超える値に設定されるものであってよい。あるいは、例えば第１種別道路には最低速度が規定されない一方で、第２種別道路には最低速度が規定されているものとして分別されるものであってよい。道路に係る種別は、例えば管理メモリ１０３に記憶される地図情報において、道路ごとあるいは道路の区間や車線ごとに種別が定義されて管理されるものであってよい。

また本実施形態では簡単のため、乗車予定地が定まることで、該乗車予定地がある対応道路が一意に特定可能であるものとして説明する。ここで、便宜上、対応道路とは「乗車予定地がある道路」として言及するが、より詳しくは、乗車予定地に存在する道路、乗車予定地に隣接する道路、乗車予定地から時間的または地理的に最も近い道路、乗車予定地において利用可能な道路等、所定のルールに基づいて特定される、乗車予定地に関連付けられた道路であってよい。乗車予定地の測定精度にも依るが、例えば、乗車予定地が一般道路に隣接する歩道である場合には、対応道路は該歩道に隣接する一般道路となり、乗車予定地がパーキングエリア（ＰＡ）やサービスエリア（ＳＡ）である場合には、対応道路は該ＰＡまたはＳＡにアクセス可能な高速道路となる等であってよい。なお、道路によっては対面通行、一方通行があるため、対応道路の特定時には、該道路について進行方向の属性を付すものとしてもよい。進行方向は、乗車予定地から目的地に向かう方向であってもよいし、乗車予定地に対応する道路が対面通行でなければ、該道路に応じて定められるものであってもよい。

決定部１０９は、希望者端末３００から受信した乗車希望につき、乗車申込を行う車両（運転者端末２００）を探索する道路（探索道路）の決定を行う。本実施形態では、決定部１０９が、特定部１０８により特定された対応道路の情報に基づき探索道路を決定することで、乗車希望について行われる探索処理での対象の限定が実現される。対応道路に応じて決定される探索道路については後述する。

探索部１１０は、決定部１０９により決定された探索道路に存在する車両を対象として、乗車希望に係る乗車申込を行う車両を探索する探索処理を実行する。

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

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

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

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

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

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

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

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

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

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

運転者端末２００から運転者モードとなったことを示す情報を受信すると、管理制御部１０１は、ユーザＩＤに関連付けてユーザＤＢ１０４に登録されているユーザ情報を取得し、運転者に係る運転者情報を運転者ＤＢ１０５に登録する。具体的には管理制御部１０１は、新たな運転者ＩＤ５０１を発行し、取得したユーザ情報に基づきユーザＩＤ５０２を関連付けて運転者情報を生成し、運転者ＤＢ１０５に登録する。このとき、運転手端末２００から受信した同乗者の有無等の情報を同乗者情報５０５として登録する。同乗者に関する情報が運転手端末２００から送信されない場合には、デフォルトとして同乗者無しの情報を登録する。なお、運転者情報は、運転者端末２００における運転者モードの解除、または相乗り運転の終了、目的地への到達を受けて、運転者ＤＢ１０５から削除されてもよい。

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

また受信した運転者端末２００の位置情報に基づき、該当の車両が現在存在する道路種別の特定がなされ、運転者情報の走行道路種別５０４の情報は随時更新される。本実施形態では走行道路種別５０４は、簡易的に現在車両が第１種別道路と第２種別道路のいずれに存在するかを示す情報で構成されるものとして説明する。

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

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

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

希望者情報の登録に応じて決定部１０９は、乗車希望に対応する乗車申込を端末に送信する車両の探索に係る探索道路を設定する。本実施形態の相乗りシステムでは、乗車申込の運転者端末２００への送信が乗車予定地に到達し得る車両に対してなされるよう、当該車両の存在率が高いと推測される探索道路に限定して探索処理を実行する。本実施形態では簡単のため、探索道路は、乗車予定地に所定の時間以内に到達し得る地理的範囲（探索領域）に含まれる、対応道路と同一の種別の道路であるものとして説明する。

これは、例えば乗車予定地の対応道路が一般道路のような第１種別道路であるケースにおいて、高速道路のような第２種別道路を走行中の車両は、乗車予定地に接近していたとしても、「相乗り運転」との前提を考慮すると、希望者のピックアップのためだけに別の種別である第１種別道路に進路を変更する可能性が低いことに依る。また同様に、例えば乗車予定地の対応道路が第２種別道路であるケースにおいても、第１種別道路を走行中の車両が、乗車予定地に接近していたとしても希望者のピックアップのためだけに第２種別道路に進路を変更する可能性が低いことにも依る。特に第１種別道路と第２種別道路との間での車両の移動（進入）は、インターチェンジ（ＩＣ）、料金所等の所定の分岐地点を介する必要があり、このような分岐地点を利用して別種別の道路に進入し、乗車予定地に到達しようとする車両は、各々の道路を走行している車両数に比較して、相対的に低いと考えられる。

従って、本実施形態の相乗りシステムでは、乗車予定地に基づく所定の探索領域に存在していたとしても、このように乗車予定地に到達し得ないと考えられる車両に係る運転者端末２００に対して乗車申込を行い、かえって運転者に煩わしさを与えぬよう、探索処理の対象とする道路を対応道路と同種別の道路に制限する。

なお、探索領域は、乗車予定地を中心として定められる円形あるいは中空円形の領域（例えば所定の時間以内に到達可能な距離を最遠の半径とする、乗車申込を承諾する操作を行った後に乗車予定地に到達可能な距離を近傍の半径とする）であってもよいし、目的地を考慮して定められるものであってもよい。例えば乗車予定地と目的地との距離が所定距離よりも短く、運転者が当初計画していた経路からの変更が許容範囲（運転者のドライブ終了予定時刻の変化度合い等）となるようなケースにおいては、探索領域は同様に乗車予定地を中心として定められる上述のような円形領域であってもよい。一方、例えば乗車予定地と目的地との距離が所定距離よりも長く、運転者が当初計画していた経路からの変更が許容範囲を超えるようなケースにおいては、目的地方向に進行し得る車両により限定して探索できるよう、円形領域のうちの一部（例えば乗車予定地の全周ではなく、目的地と反対方向の所定の角度範囲）に探索領域を限定してもよいし、乗車予定地から目的地と反対方向に偏心させる、該方向に延ばした楕円形領域とする等の調整を行うものであってよい。これは「相乗り運転」との前提を考慮すると、例えば目的地方面から乗車予定地の方向に進行している車両が、転回（Ｕターン）して再度目的地の方向に進行することは想定しづらい等、乗車予定地からみて特定の方向に存在している車両を探索の対象とすること、あるいは、このような車両に係る運転者端末２００に乗車申込を送信することは、相乗り乗車が成立する見込みも低く、現実的でないことに依る。

また対応道路が第２種別道路である場合、特に高速道路のＰＡ等、所定の進行方向に走行中の車両のみが進入可能な地点に乗車予定地が設定されるケースにおいては、図６に示されるように、探索領域に含まれる第２種別道路のうち、該進行方向に係る車線であって、かつ該進行方向において乗車予定地６０１に到達し得る範囲（ハッチング領域）に探索道路６０２をさらに限定してもよい。即ち、対応道路の進行方向において、既に乗車予定地を通過した車両や反対車線を走行している車両に希望者が乗車できる可能性は低いため、本実施形態の相乗りシステムでは、これらの車両を探索処理の対象から除外すべく、対応道路の進行方向において乗車予定地よりも後方に存在する道路（乗車予定地にこれから至る道路）を探索道路とするよう、限定を行う。本実施形態では簡単のため、希望者は、このような限定した方向に進行する車両のみが到達可能な地点を乗車予定地として設定する場合には、該方向に進行した先に目的地が存在するものとして説明する。

また上述したように第１種別道路と第２種別道路とで制限速度が異なるケースにおいては、対応道路がいずれの種別であるかに応じて、探索領域を変更するものであってもよい。即ち、所定の時間以内に乗車予定地に到達可能な車両を探索するとの観点で考えれば、車両の走行速度に応じて探索領域が設定されることが好ましく、例えば第１種別道路よりも最高速度が高く設定される第２種別道路が対応道路である場合には、第１種別道路が対応道路である場合に比べて広い範囲の探索領域が設定されるものであってもよい。また道路について定められた制限速度に限らず、例えば現在走行中の車両の平均走行速度や走行車両数等を考慮し、探索領域の大きさは調整されるものであってもよい。

また、本実施形態では簡単のため、乗車予定地が希望者端末３００の現在位置である態様について説明するが、例えば、希望者の乗車予定時刻、及び希望者が乗車予定地に到着する到着予定時刻の少なくともいずれかまでの時間が所定の時間以上ある場合、探索領域は該時間的な隔たりを考慮して調整されるものであってよい。即ち、このように実際の相乗り運転の実施まで時間的隔たりがある態様においては、探索処理の実行時点において、乗車予定地に到達し得る車両が存在し得る地理的範囲も当然拡がる。また逆に、乗車予定地には到達し得るが、例えば通過してしまい、乗車予定時刻には既に乗車予定地から離れてしまっている可能性もある。故に、希望者端末３００の現在位置を乗車予定地としない、あるいは乗車予定時刻等を設定して乗車希望が行われた場合には、希望者が乗車可能な状態となる時刻に応じて、探索領域は設定されるものであってよい。

決定部１０９による探索道路の決定がなされた後、探索部１１０は、運転者ＤＢ１０５に管理されている運転者情報に基づき、該探索道路に存在する車両に係る運転者情報を抽出し、このうちから乗車要求を行う運転者端末２００の探索を行う。より詳しくは、探索部１１０は、管理されている運転者情報のうち、走行道路種別５０４が対応道路と同一の種別を示し、かつ端末位置履歴５０３の最新の位置情報が探索道路内に含まれる運転者情報を抽出する。そして探索部１１０は、抽出した運転者情報に係る車両の移動履歴（端末位置履歴５０３）に基づいて、例えば乗車予定地あるいは目的地に到達し得るかを推定する処理を含んでよい探索処理を行うことにより、乗車申込を行う運転者端末２００を決定する。なお、本実施形態の相乗りシステムでは、運転者情報の走行道路種別５０４が第１種別道路と第２種別道路のいずれを示すかは、乗車予定地と同様に運転者端末２００の現在位置の情報から一意に特定される道路に基づき随時更新されるものであってもよいし、例えばＥＴＣ等による通行料の支払い情報を参照することに依り判別するものであってもよい。

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

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

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

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

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

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

Ｓ７０２で、特定部１０８は管理制御部１０１の制御の下、新たに登録された希望者情報の乗車希望情報５１４に基づき、乗車予定地に係る対応道路の種別を特定し、該希望者情報の対応道路種別５１５を更新する。また例えば対応道路が対面通行の道路である場合、特定部１０８は乗車予定地及び目的地の情報に基づき、該道路についての進行方向の属性を対応道路種別５１５に付すものであってもよい。

Ｓ７０３で、決定部１０９は、新たに登録した希望者情報の乗車希望情報５１４及び対応道路種別５１５に基づき、後述の探索処理の対象となる探索道路の決定を行う。決定される探索道路は、例えば図８（ａ）に示されるように乗車予定地８０１のある対応道路８０２が第１種別道路である場合には、図８（ｂ）にハッチングを付して示されるように、探索領域８１１中の第１種別道路に決定される。また例えば図８（ａ）に示されるように乗車予定地８０３のある対応道路８０４が第２種別道路である場合には、図８（ｃ）にハッチングを付して示されるように、探索領域８１１よりも広く設定される探索領域８２１中の第２種別道路に決定される。

Ｓ７０４で、探索部１１０は、設定された探索道路に基づき、乗車申込の送信先とする運転者端末２００の探索に係る探索処理を行う。探索処理は、単に探索道路に存在する車両に係る運転者端末２００を探索対象として抽出する処理だけではなく、希望者により定められた条件に合致するか、目的地に到達し得るか、車両の空席数が乗車希望の人数以上であるか等、その他の条件に係る判断を含み、乗車申込の送信先を探索するものとする。

また本実施形態の探索処理では、上述したように設定された探索道路に存在する運転者端末２００のうち、乗車目的地に到達すると推定される車両に係る運転者端末２００を、端末位置履歴５０３より特定される進行方向に基づいて抽出し、探索対象とするものとして説明する。換言すれば、本実施形態の探索処理では、乗車予定地から離れる方向に移動中の車両は乗車予定地に到達し得ないと推定されるため、探索対象から除外される。

この他、例えば対応道路が第２種別道路である場合には、乗車申込を行う車両がＳＡやＰＡに存在する状態、あるいはこれらに所定の時間内に到達可能である状態以外では停車が困難であるため、乗車申込を行ったとしても運転者がこれに対応することは難しいと推測される。そこで、運転者情報の同乗者情報５０５を参照し、第２種別道路に存在する車両のうち運転者のみが乗車している（同乗者が存在しない）車両は、探索対象から除外するよう、探索部１１０は制御してもよい。一方、同乗者情報５０５により、同乗者が存在すると判定され、同乗者への通知が可能であるか、或いは、同乗者による運転者端末２００の代理応答が可能に設定されている場合、第２種別道路に存在する該車両であっても探索対象から除外しなくてよい。また、同乗者がいた場合でも、通知不可、或いは、代理応答不可となっている場合は探索対象から除外する。

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

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

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

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

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

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

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

［変形例１］
上述した実施形態では簡単のため、乗車予定地に基づき定まる探索領域中の、対応道路と同一種別の道路を探索道路として決定する態様について説明したが、本発明の実施はこれに限られるものではない。

例えば、上述したように第１種別道路と第２種別道路との往来を可能ならしめる分岐が探索領域、あるいは探索領域周囲に存在する場合、該分岐を介して対応道路と同一種別の道路に進行する車両を考慮すべく、条件を付して異なる種別の道路を探索道路に含めるようにしてもよい。より詳しくは、図９（ａ）に示されるように、乗車予定地９０１のある対応道路９０２が第１種別道路であり、第２種別道路である道路９０３からの車両の進入が可能な分岐９０４が、乗車予定地９０１に基づき設定される探索範囲９０５に含まれる場合、図９（ｂ）にハッチングで示されるように、探索道路には探索範囲９０５内の第１種別道路だけでなく道路９０３を含めるようにしてもよい。このとき、道路９０３を走行する車両の全てが分岐９０４を介して第１種別道路に進入するとは限られないため、道路９０３のうちの減速車線（あるいは減速車線に隣接する走行車線）のみを探索道路としてもよい。反対に、追い越し車線を除外した車線を探索道路としてもよい。

あるいは、道路９０３を特定の車線に限定せずに探索道路として決定し、探索処理において、道路９０３に存在する車両について、減速率、走行車線の位置、減速車線側への車線変更を検出することで、分岐９０４を介して第１種別道路に進入すると推定される車両について、より詳細な判断に基づき、乗車申込の送信有無を決定するものとしてもよい。また車両に設定されている運転経路計画を取得可能な態様においては、これを参照し、分岐９０４を介して第１種別道路に進入するか否かの推定を行うものとしてもよい。この他、運転者が過去に採用した運転経路の履歴情報に基づき、該分岐９０４を介して第１種別道路に進入するか否かの推定を行うものとしてもよい。なお、このような推定は複合的に行われるものであってよく、少なくともいずれかを用いて推定を行うものであれば、分岐９０４が存在するケースにおいても、探索処理の対象を絞り込むことができる。

また、図９の例では、第２種別道路から分岐を介して第１種別道路に進入する車両も考慮するよう探索道路を決定する態様について説明したが、対応道路が第２種別道路である場合にも同様であることは言うまでもない。即ち、対応道路が第２種別道路である場合であっても、探索範囲に同様の分岐が存在する場合には、第１種別道路から分岐を介して第２種別道路に進入する車両を考慮すべく、例えばＩＣに向かうための第１種別道路や車線を探索道路として決定するものであってもよい。

［変形例２］
上述した実施形態では、乗車予定地が定められれば対応道路が一意に特定されるものとして説明したが、本発明の実施はこれに限られるものではない。

例えば、高架上に第２種別道路である高速道路が存在し、該高架下には第１種別道路である一般道路が存在するような場合、乗車予定地の地理的位置には異なる種別の道路が混在していることになる。換言すれば、乗車予定地の地理的位置において、高架、フェンス、分離帯等によって、物理的に道路間を車両が移動できない状態で第１種別道路及び第２種別道路が存在することがあり得る。このような場合、利用者が想定している乗車予定地について対応道路の種別の特定が適切になされなければ、乗車申込が適切な運転者端末２００に対して送信されず、結果、好適な相乗り運転が実現されない。

従って、乗車予定地に複数の種別の道路が対応付けられ得る態様においては、特定部１０８は、ユーザがいずれの種別の道路について乗車希望を行ったかを判別し、対応道路を特定する必要がある。これは、例えば希望者端末３００において乗車希望の操作がなされる際に、サービスアプリにおいて現在位置周辺の風景の撮影を要件付け、撮影により得られた画像と共に乗車希望の情報の送信を行い、特定部１０８が該画像を解析することで、いずれの種別の道路が対応道路であるかを特定可能に構成することにより実現されてもよい。あるいは、例えば高速道路等では人物の通行が許可されない区間等が存在するため、乗車予定地にある複数種別の道路のうちのいずれか一方において人物の通行が許可されていない場合には、特定部１０８は対応道路として他方を特定するものであってもよい。あるいは、乗車希望に係る操作が行われるまでに希望者端末３００において計測された行動履歴（乗車予定地付近において第２種別道路に到達し得ない移動を行っている、ＳＡ内の店舗を利用した等）に基づき、対応道路の種別を特定する構成であってもよい。

また、運転者端末２００に係る車両の存在する位置においても、同様に道路間を車両が移動できない状態で第１種別道路及び第２種別道路が存在する場合、運転者情報の走行道路種別５０４は該車両の走行速度、渋滞状況に応じて更新されるものであってよい。

［変形例３］
上述した実施形態及び変形例では、探索領域に含まれる対応道路と同一種別の道路は、探索道路として決定するものとして説明したが、本発明の実施はこれに限られるものではない。例えば探索領域に含まれる同一種別の道路であったとしても、進入禁止等の法規制や交通状況、あるいは探索領域中に対応道路に進行可能な経路が存在しないような道路（探索領域中において、道路間での車両の往来が不可能あるいは困難な同一種別の道路）については、探索道路に含めないよう制御するものであってもよい。

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

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

Claims (24)

1. 車両への乗車を希望する希望者の乗車予定地の情報を取得する取得手段と、
   前記乗車予定地と対応付けられた対応道路を特定する特定手段と、
   前記特定手段により特定された前記対応道路に基づき、前記希望者の乗車申込を行う車両を探索する探索道路を決定する制御を行う制御手段と、
   前記制御手段により決定された前記探索道路に存在する車両のうちから、前記乗車申込を行う車両を探索する探索手段と、を有し、
   前記制御手段は、前記特定手段により特定された前記対応道路の種別に応じて、前記探索道路を異ならせる制御を行うことを特徴とする情報処理装置。
2. 前記特定手段により特定される前記対応道路には、第１の種別の道路と、該第１の種別とは異なる第２の種別の道路とが含まれ、
   前記制御手段は、前記対応道路と同一種別の道路を前記探索道路として決定することを特徴とする請求項１に記載の情報処理装置。
3. 前記制御手段は、前記対応道路と異なる種別の道路を前記探索道路から除外することを特徴とする請求項２に記載の情報処理装置。
4. 前記探索手段による探索には、前記乗車予定地に基づいて探索領域が設定され、
   前記制御手段は、前記異なる種別の道路であっても、前記探索領域中において前記同一種別の道路に進入可能な分岐を有する場合には、該道路を前記探索道路に含めることを特徴とする請求項３に記載の情報処理装置。
5. 前記進入可能な分岐を有する道路に存在する車両のうちから、該分岐を介して前記乗車予定地に到達する車両を推定する推定手段をさらに有し、
   前記探索手段は、前記推定手段により前記乗車予定地に到達すると推定された車両を、探索対象とすることを特徴とする請求項４に記載の情報処理装置。
6. 前記推定手段は、前記進入可能な分岐を有する道路に存在する車両の、移動速度、走行中の車線位置、設定されている運転経路計画、及び過去の運転履歴の少なくともいずれかに基づき、該車両が前記分岐を介して前記乗車予定地に到達するか否かを推定することを特徴とする請求項５に記載の情報処理装置。
7. 前記探索手段による探索は、前記乗車予定地に基づいて探索領域が設定されるものであり、
   前記制御手段は、前記対応道路が前記第１の種別の道路である場合に、前記探索領域に含まれる前記第１の種別の道路を、前記探索道路として決定することを特徴とする請求項２乃至６のいずれか１項に記載の情報処理装置。
8. 前記制御手段は、前記対応道路が前記第２の種別の道路である場合に、前記探索領域に含まれる前記第２の種別の道路のうち、前記対応道路につき定められた進行方向において前記乗車予定地よりも後方に存在する前記第２の種別の道路を、前記探索道路として決定することを特徴とする請求項７に記載の情報処理装置。
9. 前記探索領域は、前記対応道路が前記第１の種別の道路である場合と前記第２の種別の道路である場合とで異なって設定されることを特徴とする請求項７または８に記載の情報処理装置。
10. 前記取得手段はさらに、前記乗車予定地における乗車を希望する乗車予定時刻を取得し、
    前記探索領域は、前記取得手段により取得された乗車予定時刻に応じて設定されることを特徴とする請求項７乃至９のいずれか１項に記載の情報処理装置。
11. 前記第２の種別の道路は、規定されている最高速度が高い点、または最低速度が規定されている点で前記第１の種別の道路と異なることを特徴とする請求項２乃至１０のいずれか１項に記載の情報処理装置。
12. 前記情報処理装置は、走行中の車両の移動速度に応じて、該車両が前記第１の種別の道路と前記第２の種別の道路のいずれに存在しているかを管理する第１の管理手段をさらに有することを特徴とする請求項１１に記載の情報処理装置。
13. 前記第２の種別の道路は、通行料金の支払いが要件とされている点で前記第１の種別の道路と異なることを特徴とする請求項２乃至１２のいずれか１項に記載の情報処理装置。
14. 前記情報処理装置は、走行中の車両の通行料金の支払記録に応じて、該車両が前記第１の種別の道路と前記第２の種別の道路のいずれに存在しているかを管理する第２の管理手段をさらに有することを特徴とする請求項１３に記載の情報処理装置。
15. 前記特定手段は、前記乗車予定地に係る地理的位置において、道路間を車両が移動できない状態で前記第１の種別の道路と前記第２の種別の道路とが存在する場合、前記希望者が現在前記第１の種別の道路と前記第２の種別の道路のいずれに存在するかに応じて、前記対応道路を特定することを特徴とする請求項２乃至１４のいずれか１項に記載の情報処理装置。
16. 前記取得手段は、前記希望者の使用する端末において撮像された画像をさらに取得し、
    前記特定手段は、前記撮像された画像に基づいて、前記希望者が現在前記第１の種別の道路と前記第２の種別の道路のいずれに存在するかを判断することを特徴とする請求項１５に記載の情報処理装置。
17. 前記特定手段は、前記乗車予定地の前記第２の種別の道路において人物の通行が許可されているか否かに基づいて、前記希望者が現在前記第１の種別の道路と前記第２の種別の道路のいずれに存在するかを判断することを特徴とする請求項１５または１６に記載の情報処理装置。
18. 前記取得手段は、前記希望者の使用する端末について計測された行動履歴の情報をさらに取得し、
    前記特定手段は、前記行動履歴の情報に基づいて、前記希望者が現在前記第１の種別の道路と前記第２の種別の道路のいずれに存在するかを判断することを特徴とする請求項１５乃至１７のいずれか１項に記載の情報処理装置。
19. 前記探索手段は、前記対応道路が前記第２の種別の道路である場合に、同乗者の存在しない車両を探索対象から除外することを特徴とする請求項２乃至１８のいずれか１項に記載の情報処理装置。
20. 前記探索手段は、前記乗車予定地から離れる方向に移動中の車両を探索対象から除外することを特徴とする請求項２乃至１９のいずれか１項に記載の情報処理装置。
21. 前記取得手段は、前記希望者の目的地の情報をさらに取得し、
    前記情報処理装置は、前記探索手段による探索の結果、前記目的地に到達すると推定される車両に係る通信端末に対し、前記希望者の乗車に係る要求を送信する送信手段をさらに有することを特徴とする請求項１乃至２０のいずれか１項に記載の情報処理装置。
22. 前記取得手段は、前記希望者の目的地の情報をさらに取得し、
    前記制御手段は、前記特定手段により特定された前記対応道路、及び前記乗車予定地から前記目的地に向かう進行方向に基づき、前記探索道路を決定することを特徴とする請求項１乃至２１のいずれか１項に記載の情報処理装置。
23. 車両への乗車を希望する希望者の乗車予定地の情報を取得する取得工程と、
    前記乗車予定地と対応付けられた対応道路を特定する特定工程と、
    前記特定工程において特定された前記対応道路に基づき、乗車申込を行う車両を探索する探索道路を決定する制御を行う制御工程と、
    前記制御工程において決定された前記探索道路に存在する車両のうちから、前記乗車申込を行う車両を探索する探索工程と、を有し、
    前記制御工程において、特定された前記対応道路の種別に応じて、前記探索道路を異ならせる制御が実行されることを特徴とする車両探索方法。
24. コンピュータを、請求項１乃至２２のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。

Images