(58)【調査した分野】(Int.Cl.,DB名)
前記推定手段は、前記進入可能な分岐を有する道路に存在する車両の、移動速度、走行中の車線位置、設定されている運転経路計画、及び過去の運転履歴の少なくともいずれかに基づき、該車両が前記分岐を介して前記乗車予定地に到達するか否かを推定することを特徴とする請求項5に記載の情報処理装置。
前記制御手段は、前記対応道路が前記第2の種別の道路である場合に、前記探索領域に含まれる前記第2の種別の道路のうち、前記対応道路につき定められた進行方向において前記乗車予定地よりも後方に存在する前記第2の種別の道路を、前記探索道路として決定することを特徴とする請求項7に記載の情報処理装置。
前記探索領域は、前記対応道路が前記第1の種別の道路である場合と前記第2の種別の道路である場合とで異なって設定されることを特徴とする請求項7または8に記載の情報処理装置。
前記第2の種別の道路は、規定されている最高速度が高い点、または最低速度が規定されている点で前記第1の種別の道路と異なることを特徴とする請求項2乃至10のいずれか1項に記載の情報処理装置。
前記情報処理装置は、走行中の車両の移動速度に応じて、該車両が前記第1の種別の道路と前記第2の種別の道路のいずれに存在しているかを管理する第1の管理手段をさらに有することを特徴とする請求項11に記載の情報処理装置。
前記第2の種別の道路は、通行料金の支払いが要件とされている点で前記第1の種別の道路と異なることを特徴とする請求項2乃至12のいずれか1項に記載の情報処理装置。
前記情報処理装置は、走行中の車両の通行料金の支払記録に応じて、該車両が前記第1の種別の道路と前記第2の種別の道路のいずれに存在しているかを管理する第2の管理手段をさらに有することを特徴とする請求項13に記載の情報処理装置。
前記特定手段は、前記乗車予定地に係る地理的位置において、道路間を車両が移動できない状態で前記第1の種別の道路と前記第2の種別の道路とが存在する場合、前記希望者が現在前記第1の種別の道路と前記第2の種別の道路のいずれに存在するかに応じて、前記対応道路を特定することを特徴とする請求項2乃至14のいずれか1項に記載の情報処理装置。
前記特定手段は、前記乗車予定地の前記第2の種別の道路において人物の通行が許可されているか否かに基づいて、前記希望者が現在前記第1の種別の道路と前記第2の種別の道路のいずれに存在するかを判断することを特徴とする請求項15または16に記載の情報処理装置。
前記探索手段は、前記対応道路が前記第2の種別の道路である場合に、同乗者の存在しない車両を探索対象から除外することを特徴とする請求項2乃至18のいずれか1項に記載の情報処理装置。
【発明を実施するための形態】
【0011】
[実施形態]
以下、本発明の例示的な実施形態について、図面を参照して詳細に説明する。なお、以下に説明する一実施形態は、情報処理装置の一例としての、希望者の使用する端末から受信した乗車希望について、現在走行中の車両を運転する運転者への相乗り(または同乗)運転の申込、申込承諾に基づく予約確定、及び実施された相乗り運転の管理を行う管理サーバに、本発明を適用した例を説明する。しかし、本発明は、受信した乗車要求について、乗車させる車両を探索する探索道路を決定することが可能な任意の機器に適用可能である。また、本明細書において、「運転者」とは、車両を運転している、または所定の時間内に車両の運転を予定しているユーザを指し、「希望者」とは、運転者の運転する車両に乗ることを希望するユーザであって、運転を行わず同乗するユーザを指すものとして説明する。
【0012】
《相乗りシステムの構成》
図1は、本発明の実施形態に係る相乗りシステムのシステム構成を示したシステム図である。
【0013】
図示されるように、本実施形態では管理サーバ100と運転者端末200及び希望者端末300とは、ネットワーク400を介して接続され、情報の送受信が可能に構成される。後述するように、本実施形態では管理サーバ100が、サービス登録ユーザに係るユーザ情報の管理、(相乗り運転を受け入れ可能な状態で)車両移動中である、または車両移動を予定しているユーザ(運転者)の管理、乗車希望を行ったユーザ(希望者)の管理、実施された相乗り運転の管理、乗車希望に基づく車両探索及び乗車申込の機能を集約して行うものとして説明するが、本発明の実施はこれに限られるものではない。このような機能の一部は、管理サーバ100と通信可能に構成された他の装置により実現されるよう分離され、管理サーバ100は該他の装置と協働して動作する態様であってもよい。
【0014】
また本実施形態では簡単のため、運転者端末200及び希望者端末300には、相乗りシステムにより提供される、相乗り運転に係るサービスを利用するための所定のアプリケーション(サービスアプリ)が格納されているものとする。サービス利用中において運転者端末200及び希望者端末300では、フォアグラウンドまたはバックグラウンドにて該サービスアプリが起動されることで、管理サーバ100との通信が可能なように構成されているものとして説明する。しかしながら、本発明の実施はこれに限られるものではなく、サービス利用に係る各端末での動作は、ブラウジングアプリケーションを介してサイトアクセスすることで行われる等、どのような手法により実現されるものであってもよい。
【0015】
また本実施形態では、サービスアプリは選択式の運転者モードと同乗者モードの2つのモードを有しており、いずれのモードが選択されるかによって、該サービスアプリを起動している端末のユーザが運転者と希望者(または同乗者)のいずれであるかを判別可能に構成されているものとする。即ち、運転者モードでサービスアプリが起動された端末は運転者端末200として扱われ、該端末を使用するユーザが、現在車両移動中である運転者として管理される。また同乗者モードでサービスアプリが起動された端末は希望者端末300として扱われ、該端末を使用するユーザが、運転者の運転する車両への乗車希望の送信が可能な、また申込後に(承諾されれば)同乗が可能な希望者として管理される。
【0016】
〈管理サーバ100の構成〉
図2は、本発明の実施形態に係る管理サーバ100の機能構成を示したブロック図である。なお、各装置の機能構成の説明において同様の機能を実現する構成については、管理サーバ100、運転者端末200、希望者端末300のいずれの構成であるかを判別可能とするため、各々「管理」、「運転」、「希望」の接頭文字を付して識別するものとして以下説明する。また本実施形態の管理サーバ100では、
図2に実線で示される構成(道路情報DB120以外の構成)を有するものとして説明する。
【0017】
管理制御部101は、例えばCPU等であり、管理サーバ100が有する各ブロックの動作を制御する。具体的には管理制御部101は、管理記録媒体102に記録されている各ブロックの動作プログラムやサービス提供に係る種々の処理のプログラムを読み出し、管理メモリ103に展開して実行することにより各ブロックの動作を制御する。
【0018】
管理記録媒体102は、例えば不揮発性メモリやHDD等の、格納された情報を恒久的に保持する記録装置である。管理記録媒体102は、上記プログラムだけでなく、管理サーバ100が有する各ブロックの動作において必要となるパラメータ等の情報を記録する。また管理メモリ103は、例えば揮発性メモリ等の、格納された情報を簡易にアクセス可能な状態で、一時的に保持する記憶装置である。管理メモリ103は、プログラムの展開領域としてだけでなく、各ブロックの動作において出力された中間データ等を一時的に保持する格納領域として用いられる。
【0019】
ユーザDB104は、本実施形態の相乗りシステムが提供する相乗り運転に係るサービスに、運転者、希望者を問わず登録されているユーザ(登録ユーザ)の各種情報(ユーザ情報)を管理するデータベースである。ユーザ情報は、例えば登録ユーザを識別するユーザIDに関連付けて、氏名、年齢、住所、趣味、運転免許の有無、車両所有の有無、車種等の個人情報に加え、サービス利用に用いられる(車両移動に係り携行されている)端末の情報及び該端末との通信に必要な端末特定のための情報等を含むものであってよい。
【0020】
運転者DB105は、運転者としてサービス利用しているユーザの各種情報を管理するデータベースである。運転者DB105は、上述したように、サービス利用に係り、使用する端末において運転者モードでサービスアプリが起動された場合に、該端末(運転者端末200)のユーザの各種の情報を運転者情報として追加し、管理する。
【0021】
運転者情報は、例えば
図5(a)に示されるように、運転者情報を識別する運転者ID501に関連付けて、運転者であるユーザにつきユーザDB104に登録されているユーザID502、該ユーザの使用する運転者端末200において取得された位置情報の履歴を時系列で示す端末位置履歴503、及び現在の車両が存在する道路の種別を示す走行道路種別504を管理するものであってよい。走行道路種別504は、後述の第1種別道路と第2種別道路のいずれに車両が存在するか、さらにはいずれの方向に進行する車線に存在するかを管理するものであってよい。また、同乗者情報505には、同乗者の有無、同乗者への通知の可否、同乗者による運転者端末200の代理応答の可否等が含まれる。ここでの同乗者は、相乗りによって同乗した者ではなく、例えば、運転者であるユーザの家族が同乗している場合のように、出発時或いは運転者モードでのサービスアプリを起動した時点で同乗している者としてもよい。
【0022】
希望者DB106は、希望者あるいは同乗者としてサービス利用しているユーザの各種情報を管理するデータベースである。希望者DB106は、使用する端末において同乗者モードでサービスアプリが起動され、乗車希望に係る情報を該端末(希望者端末300)から受信した場合に、該端末のユーザの各種の情報を希望者情報として追加し、管理する。
【0023】
希望者情報は、例えば
図5(b)に示されるように、希望者情報を識別する希望者ID511に関連付けて、希望者であるユーザにつきユーザDB104に登録されているユーザID512、該ユーザの使用する希望者端末300において取得された位置情報の履歴を時系列で示す端末位置履歴513、今回の相乗り運転に係る希望者の乗車予定地及びその乗車予定時刻と目的地とを示す乗車希望情報514、乗車予定地に対応する道路の種別を示す対応道路種別515、及び該希望者の乗車希望に係る同乗が成立したか否かを示す成立済フラグ516を管理するものであってよい。
【0024】
相乗りDB107は、希望者により行われた乗車希望に基づく相乗り運転について各種情報(ドライブ情報)を管理するデータベースである。より詳しくは相乗りDB107は、希望者の乗車希望に基づく相乗り運転(希望者が同乗する期間に係るドライブ)が成立した場合、あるいは運転者により乗車申込が承諾されて相乗り運転の実施が予約された場合に、該相乗り運転に係るドライブ情報を登録し、管理する。ドライブ情報は、例えば
図5(c)に示されるように、ドライブ情報を識別するためのドライブID521に関連付けて、運転者に係る運転者情報522、希望者に係る希望者情報523、実際に同乗した期間に走行した経路の情報を示す運転経路524、及びドライブが完了したか否かを示す(例えば論理型の)完了フラグ525を管理するものであってよい。
【0025】
ここで、運転者情報522は、運転者のユーザID531に関連付けて、運転者が使用する運転者端末200から取得された位置情報の履歴を示す端末位置履歴532を管理するよう構成されていてよい。対して希望者情報523は、希望者(同乗の申込が承諾されたユーザ)のユーザID541に関連付けて、希望者が使用する希望者端末300から取得された位置情報の履歴を示す端末位置履歴542に加え、実際に該希望者が、運転者の運転する車両に乗車した位置や時刻等を示す乗車情報543、及び同様に降車した位置や時刻等を示す降車情報544を管理するよう構成されていてよい。なお、運転経路524は、基本的には運転者端末200に係る端末位置履歴532に基づいて決定されるものであってよく、相乗り運転に係る希望者の負担費用(有料高速道路の利用料金やガソリン代等の実費)の確定に用いられる情報である。
【0026】
特定部108は、希望者端末300から受信した乗車希望について、希望者の乗車予定地に対応する道路(対応道路)の種別を特定する。道路の種別とは、一般車両の通行可否や法定交通ルール等に基づいて定められるものであってよく、本実施形態の相乗りシステムでは道路の種別として、少なくとも一般車両の通行が認められている道路につき、第1種別道路(一般道路)及び第2種別道路(有料道路)を含むものとする。第1種別道路と第2種別道路とは、例えば通行に係る料金の支払要否において分別されるものであり、第1種別道路が料金の支払いが不要である一方で、第2種別道路は料金の支払いが要求されるものであってよい。また第1種別道路と第2種別道路とは、例えば規定されている制限速度により分別されるものであり、第1種別道路は最高速度が時速60km以下に設定される一方で、第2種別道路は最高速度が時速60kmを超える値に設定されるものであってよい。あるいは、例えば第1種別道路には最低速度が規定されない一方で、第2種別道路には最低速度が規定されているものとして分別されるものであってよい。道路に係る種別は、例えば管理メモリ103に記憶される地図情報において、道路ごとあるいは道路の区間や車線ごとに種別が定義されて管理されるものであってよい。
【0027】
また本実施形態では簡単のため、乗車予定地が定まることで、該乗車予定地がある対応道路が一意に特定可能であるものとして説明する。ここで、便宜上、対応道路とは「乗車予定地がある道路」として言及するが、より詳しくは、乗車予定地に存在する道路、乗車予定地に隣接する道路、乗車予定地から時間的または地理的に最も近い道路、乗車予定地において利用可能な道路等、所定のルールに基づいて特定される、乗車予定地に関連付けられた道路であってよい。乗車予定地の測定精度にも依るが、例えば、乗車予定地が一般道路に隣接する歩道である場合には、対応道路は該歩道に隣接する一般道路となり、乗車予定地がパーキングエリア(PA)やサービスエリア(SA)である場合には、対応道路は該PAまたはSAにアクセス可能な高速道路となる等であってよい。なお、道路によっては対面通行、一方通行があるため、対応道路の特定時には、該道路について進行方向の属性を付すものとしてもよい。進行方向は、乗車予定地から目的地に向かう方向であってもよいし、乗車予定地に対応する道路が対面通行でなければ、該道路に応じて定められるものであってもよい。
【0028】
決定部109は、希望者端末300から受信した乗車希望につき、乗車申込を行う車両(運転者端末200)を探索する道路(探索道路)の決定を行う。本実施形態では、決定部109が、特定部108により特定された対応道路の情報に基づき探索道路を決定することで、乗車希望について行われる探索処理での対象の限定が実現される。対応道路に応じて決定される探索道路については後述する。
【0029】
探索部110は、決定部109により決定された探索道路に存在する車両を対象として、乗車希望に係る乗車申込を行う車両を探索する探索処理を実行する。
【0030】
管理通信部111は、管理サーバ100が有する通信インタフェースである。管理通信部111は、ネットワーク400を介して他の装置(運転者端末200及び希望者端末300、場合によっては分離された機能を実現する外部装置)と接続し、所定のプロトコルに従った通信方式で、機器間のデータの送受信を行う。
【0031】
本実施形態ではハードウェアとして管理サーバ100が備える各ブロックにおいて処理が実現されるものとして説明するが、本発明の実施はこれに限らず、各ブロックの処理は該各ブロックと同様の処理を行うプログラムで実現されてもよい。
【0032】
〈運転者端末200及び希望者端末300の構成〉
以下、運転者端末200及び希望者端末300の機能構成につき、
図3及び
図4のブロック図を用いて説明する。本実施形態では、運転者端末200及び希望者端末300が有する基本的な構成は同様であるものとして説明するが、本発明の実施において、運転者端末200及び希望者端末300の構成はこれに限られるものではない。
【0033】
運転制御部201及び希望制御部301は、例えばCPUであり、各々運転者端末200または希望者端末300が有する各ブロックの動作を制御する。具体的には運転制御部201及び希望制御部301は、各々の端末が有する運転記録媒体202または希望記録媒体302に記録されている各ブロックの動作プログラムや、相乗りシステムにより提供されるサービスを利用するために必要となる(サービスアプリを含む)アプリケーションプログラム等を読み出し、それぞれ運転メモリ203または希望メモリ303に展開して実行することにより、各端末上において各ブロックの動作制御を行う。なお、サービスを利用するために必要となるサービスアプリの動作については、後述する。
【0034】
運転記録媒体202及び希望記録媒体302は、例えば不揮発性メモリやHDD等の、格納された情報を恒久的に保持する記録装置である。運転記録媒体202及び希望記録媒体302は、上記プログラムだけでなく、各ブロックの動作において必要となるパラメータ等の情報を各々記録する。また運転メモリ203及び希望メモリ303は、例えば揮発性メモリ等の、格納された情報を簡易にアクセス可能な状態で一時的に保持する記憶装置である。運転メモリ203及び希望メモリ303は、プログラムの展開領域としてだけでなく、各ブロックの動作において出力された中間データ等を一時的に保持する格納領域として用いられる。
【0035】
運転位置取得部204及び希望位置取得部304は、GPS利用等の所定の方式で、各端末の位置情報を取得する。本実施形態の相乗りシステムでは、運転者端末200及び希望者端末300においてサービスアプリが実行されている、あるいはバックグラウンド動作している間、所定の時間間隔で位置情報を取得し、該位置情報を管理サーバ100に送信する動作が行われる。より詳しくは、運転者端末200においてサービスアプリが運転者モードで実行されている間、また希望者端末300においてサービスアプリが同乗者モードで実行され、かつ乗車希望に係る情報入力がなされた後、運転位置取得部204及び希望位置取得部304のそれぞれは端末の位置情報を取得するよう制御される。
【0036】
運転操作入力部205及び希望操作入力部305は、ボタンやタッチパネル等、各端末が備える操作入力に係るユーザインタフェースである。運転操作入力部205及び希望操作入力部305は、該ユーザインタフェースに対して操作がなされたことを検出すると、該操作の内容を解析し、操作入力結果として運転制御部201または希望制御部301にそれぞれ伝達する。操作入力結果は、例えば端末のオペレーションプログラムやサービスアプリで定められたいずれかの入力イベントと判断されるものであってよい。
【0037】
運転通信部206及び希望通信部306は、それぞれ運転者端末200または希望者端末300が有する通信インタフェースである。本実施形態の相乗りシステムでは、運転者端末200及び希望者端末300は、相乗り運転に係るサービスの利用にあたり、管理サーバ100との通信を行うことが必須となるため、通信インタフェースは不可欠な構成である。運転通信部206及び希望通信部306は、ネットワーク400を介して他の装置(管理サーバ100、場合によってはネットワーク400を介さず互いの端末間で、あるいはその他の並行利用すべきサービスを提供する外部装置)と接続し、所定のプロトコルに従った通信方式で、機器間のデータの送受信を行う。
【0038】
《サービス概要》
ここで、本実施形態の相乗りシステムで提供されるサービスの概要につき、それぞれの利用段階にて該システムで行われる動作の概要を説明する。
【0039】
〈運転者端末の受け入れ状態への遷移〉
上述したように端末においてサービスアプリが運転者モードで起動されると、あるいは起動されたサービスアプリにおいて運転者モードが選択されると、端末は運転者端末200として機能する。本実施形態では簡単のため、運転者モードでサービスアプリが動作している状態は、運転者端末200を使用する運転者により、自己の運転する車両(もしくは自己が乗車する車両)への希望者の同乗を受け入れ可能であるとの意思表示がなされているものとして取り扱う。運転者モードでのサービスアプリの動作が開始すると、運転制御部201は、アプリケーションプログラムに基づき、例えば運転者モードとなったことを示す情報をユーザIDに関連付け、運転通信部206を介して管理サーバ100に送信する。なお、ユーザは、同乗者情報505として登録される、同乗者の有無、同乗者への通知の可否、同乗者による運転者端末200の代理応答の可否についてサービスアプリで設定することができ、設定されたこれらの情報があわせて管理サーバ100に送信される。
【0040】
運転者端末200から運転者モードとなったことを示す情報を受信すると、管理制御部101は、ユーザIDに関連付けてユーザDB104に登録されているユーザ情報を取得し、運転者に係る運転者情報を運転者DB105に登録する。具体的には管理制御部101は、新たな運転者ID501を発行し、取得したユーザ情報に基づきユーザID502を関連付けて運転者情報を生成し、運転者DB105に登録する。このとき、運転手端末200から受信した同乗者の有無等の情報を同乗者情報505として登録する。同乗者に関する情報が運転手端末200から送信されない場合には、デフォルトとして同乗者無しの情報を登録する。なお、運転者情報は、運転者端末200における運転者モードの解除、または相乗り運転の終了、目的地への到達を受けて、運転者DB105から削除されてもよい。
【0041】
またサービスアプリが運転者モードで動作している間、運転位置取得部204は運転制御部201の制御の下、所定の時間間隔で運転者端末200の位置(測位)情報を取得し、例えばユーザIDに関連付けて管理サーバ100に送信する。送信された運転者端末200の位置情報は、ユーザIDを含めて運転者DB105に登録された運転者情報の端末位置履歴503に随時タイムスタンプとともに追加され、管理される。このようにすることで、相乗り運転に係るサービスにおいて、同乗を受け入れ可能な車両とその位置情報とが、システムにおいて把握可能な状態となる。
【0042】
また受信した運転者端末200の位置情報に基づき、該当の車両が現在存在する道路種別の特定がなされ、運転者情報の走行道路種別504の情報は随時更新される。本実施形態では走行道路種別504は、簡易的に現在車両が第1種別道路と第2種別道路のいずれに存在するかを示す情報で構成されるものとして説明する。
【0043】
〈乗車希望〜乗車申込〉
同乗を受け入れ可能な車両への乗車希望は、端末においてサービスアプリが同乗者モードで動作している状態(端末が希望者端末300として機能している状態)で可能となる。乗車希望を行う場合、希望者はサービスアプリにおいて例えば乗車予定地、乗車予定時刻及び目的地の情報を入力する。なお、本実施形態では簡単のため、希望者が現在存在する位置にて、乗車希望を行うユースケースについて説明する。つまり、現在位置にてこれから乗車したいとのユースケースにおいては、希望者は乗車希望にあたり乗車予定時刻や特定の乗車予定地の詳細を入力する必要はなく、例えば目的地のみ入力すれば、簡易的に乗車希望の操作を行うことで希望位置取得部304により現在の位置情報が取得され、必要な情報が揃う。希望制御部301は、乗車予定地(現在位置)と目的地の情報を希望者のユーザIDに関連付け、乗車希望の情報として希望通信部306を介して管理サーバ100に送信する。
【0044】
希望者端末300から乗車希望の情報を受信すると、管理制御部101は、ユーザIDに関連付けてユーザDB104に登録されているユーザ情報を取得し、希望者に係る希望者情報を希望者DB106に登録する。具体的には管理制御部101は、新たな希望者ID511を発行し、取得したユーザ情報と受信した乗車希望の情報とに基づくユーザID512及び乗車希望情報514を関連付けて希望者情報を生成し、希望者DB106に登録する。また特定部108は、乗車希望の情報に含まれる乗車予定地の情報に基づいて対応道路の種別を特定し、管理制御部101は、希望者情報の対応道路種別515として、該特定された対応道路の種別を含めて管理する。このとき希望者情報の成立済フラグ516は、初期値の偽(false:乗車の受け入れがなされていない状態)に設定されるものとする。
【0045】
また運転者モードと同様、乗車希望に係る入力がなされてから、希望位置取得部304は希望制御部301の制御の下、所定の時間間隔で希望者端末300の位置情報を取得し、例えばユーザIDに関連付けて管理サーバ100に送信する。送信された希望者端末300の位置情報は、ユーザIDを含めて希望者DB106に登録された希望者情報の端末位置履歴513に随時タイムスタンプと共に追加され、管理される。なお、本実施形態では、希望者が車両に乗車したことを確認するため、あるいは希望者が乗車予定地と異なる位置に存在する(乗車予定地に向かっている、または乗車予定地から移動した)場合も考慮するため、同乗者モードにおいてもサービスアプリは定期的な位置情報の取得を行い、その履歴が希望者情報にて管理されるものとして説明するが、本発明の実施はこれに限られるものではない。例えば、希望者端末300に係る端末位置履歴513の管理は、希望者が車両に乗車したことが確定した後に、希望位置取得部304により行われた位置情報について行われるものであってよい。
【0046】
希望者情報の登録に応じて決定部109は、乗車希望に対応する乗車申込を端末に送信する車両の探索に係る探索道路を設定する。本実施形態の相乗りシステムでは、乗車申込の運転者端末200への送信が乗車予定地に到達し得る車両に対してなされるよう、当該車両の存在率が高いと推測される探索道路に限定して探索処理を実行する。本実施形態では簡単のため、探索道路は、乗車予定地に所定の時間以内に到達し得る地理的範囲(探索領域)に含まれる、対応道路と同一の種別の道路であるものとして説明する。
【0047】
これは、例えば乗車予定地の対応道路が一般道路のような第1種別道路であるケースにおいて、高速道路のような第2種別道路を走行中の車両は、乗車予定地に接近していたとしても、「相乗り運転」との前提を考慮すると、希望者のピックアップのためだけに別の種別である第1種別道路に進路を変更する可能性が低いことに依る。また同様に、例えば乗車予定地の対応道路が第2種別道路であるケースにおいても、第1種別道路を走行中の車両が、乗車予定地に接近していたとしても希望者のピックアップのためだけに第2種別道路に進路を変更する可能性が低いことにも依る。特に第1種別道路と第2種別道路との間での車両の移動(進入)は、インターチェンジ(IC)、料金所等の所定の分岐地点を介する必要があり、このような分岐地点を利用して別種別の道路に進入し、乗車予定地に到達しようとする車両は、各々の道路を走行している車両数に比較して、相対的に低いと考えられる。
【0048】
従って、本実施形態の相乗りシステムでは、乗車予定地に基づく所定の探索領域に存在していたとしても、このように乗車予定地に到達し得ないと考えられる車両に係る運転者端末200に対して乗車申込を行い、かえって運転者に煩わしさを与えぬよう、探索処理の対象とする道路を対応道路と同種別の道路に制限する。
【0049】
なお、探索領域は、乗車予定地を中心として定められる円形あるいは中空円形の領域(例えば所定の時間以内に到達可能な距離を最遠の半径とする、乗車申込を承諾する操作を行った後に乗車予定地に到達可能な距離を近傍の半径とする)であってもよいし、目的地を考慮して定められるものであってもよい。例えば乗車予定地と目的地との距離が所定距離よりも短く、運転者が当初計画していた経路からの変更が許容範囲(運転者のドライブ終了予定時刻の変化度合い等)となるようなケースにおいては、探索領域は同様に乗車予定地を中心として定められる上述のような円形領域であってもよい。一方、例えば乗車予定地と目的地との距離が所定距離よりも長く、運転者が当初計画していた経路からの変更が許容範囲を超えるようなケースにおいては、目的地方向に進行し得る車両により限定して探索できるよう、円形領域のうちの一部(例えば乗車予定地の全周ではなく、目的地と反対方向の所定の角度範囲)に探索領域を限定してもよいし、乗車予定地から目的地と反対方向に偏心させる、該方向に延ばした楕円形領域とする等の調整を行うものであってよい。これは「相乗り運転」との前提を考慮すると、例えば目的地方面から乗車予定地の方向に進行している車両が、転回(Uターン)して再度目的地の方向に進行することは想定しづらい等、乗車予定地からみて特定の方向に存在している車両を探索の対象とすること、あるいは、このような車両に係る運転者端末200に乗車申込を送信することは、相乗り乗車が成立する見込みも低く、現実的でないことに依る。
【0050】
また対応道路が第2種別道路である場合、特に高速道路のPA等、所定の進行方向に走行中の車両のみが進入可能な地点に乗車予定地が設定されるケースにおいては、
図6に示されるように、探索領域に含まれる第2種別道路のうち、該進行方向に係る車線であって、かつ該進行方向において乗車予定地601に到達し得る範囲(ハッチング領域)に探索道路602をさらに限定してもよい。即ち、対応道路の進行方向において、既に乗車予定地を通過した車両や反対車線を走行している車両に希望者が乗車できる可能性は低いため、本実施形態の相乗りシステムでは、これらの車両を探索処理の対象から除外すべく、対応道路の進行方向において乗車予定地よりも後方に存在する道路(乗車予定地にこれから至る道路)を探索道路とするよう、限定を行う。本実施形態では簡単のため、希望者は、このような限定した方向に進行する車両のみが到達可能な地点を乗車予定地として設定する場合には、該方向に進行した先に目的地が存在するものとして説明する。
【0051】
また上述したように第1種別道路と第2種別道路とで制限速度が異なるケースにおいては、対応道路がいずれの種別であるかに応じて、探索領域を変更するものであってもよい。即ち、所定の時間以内に乗車予定地に到達可能な車両を探索するとの観点で考えれば、車両の走行速度に応じて探索領域が設定されることが好ましく、例えば第1種別道路よりも最高速度が高く設定される第2種別道路が対応道路である場合には、第1種別道路が対応道路である場合に比べて広い範囲の探索領域が設定されるものであってもよい。また道路について定められた制限速度に限らず、例えば現在走行中の車両の平均走行速度や走行車両数等を考慮し、探索領域の大きさは調整されるものであってもよい。
【0052】
また、本実施形態では簡単のため、乗車予定地が希望者端末300の現在位置である態様について説明するが、例えば、希望者の乗車予定時刻、及び希望者が乗車予定地に到着する到着予定時刻の少なくともいずれかまでの時間が所定の時間以上ある場合、探索領域は該時間的な隔たりを考慮して調整されるものであってよい。即ち、このように実際の相乗り運転の実施まで時間的隔たりがある態様においては、探索処理の実行時点において、乗車予定地に到達し得る車両が存在し得る地理的範囲も当然拡がる。また逆に、乗車予定地には到達し得るが、例えば通過してしまい、乗車予定時刻には既に乗車予定地から離れてしまっている可能性もある。故に、希望者端末300の現在位置を乗車予定地としない、あるいは乗車予定時刻等を設定して乗車希望が行われた場合には、希望者が乗車可能な状態となる時刻に応じて、探索領域は設定されるものであってよい。
【0053】
決定部109による探索道路の決定がなされた後、探索部110は、運転者DB105に管理されている運転者情報に基づき、該探索道路に存在する車両に係る運転者情報を抽出し、このうちから乗車要求を行う運転者端末200の探索を行う。より詳しくは、探索部110は、管理されている運転者情報のうち、走行道路種別504が対応道路と同一の種別を示し、かつ端末位置履歴503の最新の位置情報が探索道路内に含まれる運転者情報を抽出する。そして探索部110は、抽出した運転者情報に係る車両の移動履歴(端末位置履歴503)に基づいて、例えば乗車予定地あるいは目的地に到達し得るかを推定する処理を含んでよい探索処理を行うことにより、乗車申込を行う運転者端末200を決定する。なお、本実施形態の相乗りシステムでは、運転者情報の走行道路種別504が第1種別道路と第2種別道路のいずれを示すかは、乗車予定地と同様に運転者端末200の現在位置の情報から一意に特定される道路に基づき随時更新されるものであってもよいし、例えばETC等による通行料の支払い情報を参照することに依り判別するものであってもよい。
【0054】
このように探索道路についての探索に基づき乗車申込を行う運転者端末200を決定すると、管理制御部101は、決定された運転者端末200に対して、希望者の乗車希望に係る乗車申込に係る情報を、管理通信部111を介して送信する。乗車申込に係る情報は、運転者端末200において希望者の乗車予定地及び目的地を提示し、同乗を承諾するか否かを運転者に選択させる動作を、サービスアプリにて実行させるものであってよい。
【0055】
〈乗車承諾〜相乗り運転管理〉
乗車申込を行った運転者端末200において申込が承諾されると、運転制御部201は承諾を示す情報を管理サーバ100に返送する。管理制御部101は、該情報を受信すると、該当の希望者情報の成立済フラグ516を真(True)に更新し、乗車予約状態とする。また管理制御部101は、承諾により相乗り運転の実施が確定した運転者と希望者につき、対応する運転者情報及び希望者情報に基づいてドライブ情報を生成し、相乗りDB107に登録する。ドライブ情報の希望者情報523に含まれる乗車情報543及び降車情報544は、例えばドライブ情報に係る端末位置履歴532と端末位置履歴542の一致度を算出することで、同一の車両に乗車して移動中であるか否かが判断され、当該移動の開始時、終了時にそれぞれ入力されればよい。
【0056】
なお、本実施形態では管理制御部101が、運転者に係る端末位置履歴532と希望者に係る端末位置履歴542との一致度をもって相乗りしているかの判断を行うものとして説明するが、本発明の実施はこれに限られるものではない。即ち、同乗しているか否か、あるいは乗車したか降車したかは、必ずしも位置情報の推移で判断する手法に限られず、例えば車両に搭載された所定のビーコンや運転者端末200から定期的に発生される信号を、希望者端末300において所定回数受信した、あるいは所定期間内に受信していることをもって、管理制御部101が同乗していると判断する等、どのような手法が用いられてもよいことは言うまでもない。
【0057】
また、乗車申し込みが承諾された場合には、管理制御部101は対象の希望者端末300に対し、同乗の承諾がなされたこと、及び運転者、車種及びカラー、車両の現在位置等の乗車する車両に係る種々の情報を通知すればよい。
【0058】
《提供処理》
上述のような構成をもつ本実施形態の管理サーバ100で実行される、1つの乗車希望に基づき車両探索、乗車申込、及び相乗り運転の予約を行う、相乗りシステムに係るサービス提供を実現する提供処理について、
図7のフローチャートを用いて具体的な処理を説明する。該フローチャートに対応する処理は、管理制御部101が、例えば管理記録媒体102に記憶されている対応する処理プログラムを読み出し、管理メモリ103に展開して実行することにより実現することができる。なお、本提供処理は、例えば希望者端末300から乗車希望に係る情報を受信した際に開始されるものとして説明する。
【0059】
S701で、管理制御部101は、受信した乗車希望に係る情報に基づき、希望者DB106に新たな希望者情報を登録する。
【0060】
S702で、特定部108は管理制御部101の制御の下、新たに登録された希望者情報の乗車希望情報514に基づき、乗車予定地に係る対応道路の種別を特定し、該希望者情報の対応道路種別515を更新する。また例えば対応道路が対面通行の道路である場合、特定部108は乗車予定地及び目的地の情報に基づき、該道路についての進行方向の属性を対応道路種別515に付すものであってもよい。
【0061】
S703で、決定部109は、新たに登録した希望者情報の乗車希望情報514及び対応道路種別515に基づき、後述の探索処理の対象となる探索道路の決定を行う。決定される探索道路は、例えば
図8(a)に示されるように乗車予定地801のある対応道路802が第1種別道路である場合には、
図8(b)にハッチングを付して示されるように、探索領域811中の第1種別道路に決定される。また例えば
図8(a)に示されるように乗車予定地803のある対応道路804が第2種別道路である場合には、
図8(c)にハッチングを付して示されるように、探索領域811よりも広く設定される探索領域821中の第2種別道路に決定される。
【0062】
S704で、探索部110は、設定された探索道路に基づき、乗車申込の送信先とする運転者端末200の探索に係る探索処理を行う。探索処理は、単に探索道路に存在する車両に係る運転者端末200を探索対象として抽出する処理だけではなく、希望者により定められた条件に合致するか、目的地に到達し得るか、車両の空席数が乗車希望の人数以上であるか等、その他の条件に係る判断を含み、乗車申込の送信先を探索するものとする。
【0063】
また本実施形態の探索処理では、上述したように設定された探索道路に存在する運転者端末200のうち、乗車目的地に到達すると推定される車両に係る運転者端末200を、端末位置履歴503より特定される進行方向に基づいて抽出し、探索対象とするものとして説明する。換言すれば、本実施形態の探索処理では、乗車予定地から離れる方向に移動中の車両は乗車予定地に到達し得ないと推定されるため、探索対象から除外される。
【0064】
この他、例えば対応道路が第2種別道路である場合には、乗車申込を行う車両がSAやPAに存在する状態、あるいはこれらに所定の時間内に到達可能である状態以外では停車が困難であるため、乗車申込を行ったとしても運転者がこれに対応することは難しいと推測される。そこで、運転者情報の同乗者情報505を参照し、第2種別道路に存在する車両のうち運転者のみが乗車している(同乗者が存在しない)車両は、探索対象から除外するよう、探索部110は制御してもよい。一方、同乗者情報505により、同乗者が存在すると判定され、同乗者への通知が可能であるか、或いは、同乗者による運転者端末200の代理応答が可能に設定されている場合、第2種別道路に存在する該車両であっても探索対象から除外しなくてよい。また、同乗者がいた場合でも、通知不可、或いは、代理応答不可となっている場合は探索対象から除外する。
【0065】
S705で、管理制御部101は、探索結果に基づき該当の運転者端末200に対して乗車申込の送信を行う。
【0066】
S706で、管理制御部101は、乗車申込の承諾がなされたことを示す情報(承諾情報)を受信したか否かを判断する。本実施形態の相乗りシステムでは簡単のため、最初に受信した承諾情報の送信元である運転者端末200に係る車両を、希望者の乗車する車両として決定するものとして説明するが、例えば希望者による最終確認の工程を設ける等、これに限られるものではない。管理制御部101は、承諾情報を受信したと判断した場合は処理をS707に移す。また管理制御部101は、承諾情報を受信していない場合は本ステップの処理を繰り返し、受信していない期間が所定のタイムアウト時間に至った場合には処理をS703に戻し、新たな探索道路の設定を行う。
【0067】
探索道路は例えば、1つの乗車希望につき最初にS703の処理が行われる際には、乗車予定地を中心とする予め定められた半径範囲や角度範囲に設定された探索領域について決定され、2回目以降に行われる際には、該半径及び角度の少なくともいずれかの範囲を拡張する等により探索道路とする道路を増やし、探索対象となる端末数が増加するよう設定されるものであってよい。この場合、同一の運転者端末200に対して乗車申込を送信する回数に上限(例えば1回)を設け、探索道路の増加に伴う、探索対象の運転者端末200の数の増加率を低減するように構成してもよい。
【0068】
また乗車申込を送信する端末数に下限を設け、設定した探索道路につき送信端末数の条件が満たされない場合には、乗車申込の送信せずに探索領域を拡張して探索道路を再設定し、再設定した探索道路について改めて探索処理を行って送信先とする運転者端末200を決定するものとしてもよい。このように構成することで、好適な結果が得られない(乗車申込を送信したとしても乗車申込が承諾されない、あるいは承諾される確率が低い(受信する運転者端末200の絶対数に基づく))乗車申込の送信により通信帯域を占有してしまう状況の発生を低減し、より相乗り運転の成立確度が高い状況にて、乗車申込の送信を行うことが可能となる。
【0069】
なお、探索道路の再設定を含む乗車申込の送信(対象とする運転者端末200への一斉送信、即ちS705の実行)には、回数に制限が設けられるものであってよい。この場合、制限回数の乗車申込の送信に対する承諾情報の受信が得られないのであれば、管理制御部101は希望の条件を満たす車両が見つからなかった旨の情報を該当の希望者端末300に送信し、サービスアプリにて通知させる構成としてよい。
【0070】
S707で、管理制御部101は、受信した承諾情報に基づきドライブ情報を生成し、相乗りDB107に登録し、端末位置履歴に係る該情報の更新を開始する。また管理制御部101は、S701で登録した希望者情報の成立済フラグ515を更新する。さらに管理制御部101は、乗車希望に係る相乗り運転が承諾されたことを示す情報を該当の希望者端末300に送信し、例えばサービスアプリにて乗車に係る詳細(運転者の情報、車種、カラー等)を通知させる。
【0071】
以上説明したように、本実施形態の相乗りシステムでは、なされた乗車希望に対して乗車申込を行う対象を、乗車予定地への到達可能性が高い道路に存在する車両の運転者端末に制限することができるため、探索処理や乗車申込送信に係る処理負荷を低減しつつ、好適なサービス提供が可能となる。なお、本実施形態では相乗り運転に係り、乗車申込を行う対象を限定する態様について説明したが、本発明が例えば配車サービス等、希望者を乗車させる車両を探索する他の態様についても利用可能であることは言うまでもない。
【0072】
[変形例1]
上述した実施形態では簡単のため、乗車予定地に基づき定まる探索領域中の、対応道路と同一種別の道路を探索道路として決定する態様について説明したが、本発明の実施はこれに限られるものではない。
【0073】
例えば、上述したように第1種別道路と第2種別道路との往来を可能ならしめる分岐が探索領域、あるいは探索領域周囲に存在する場合、該分岐を介して対応道路と同一種別の道路に進行する車両を考慮すべく、条件を付して異なる種別の道路を探索道路に含めるようにしてもよい。より詳しくは、
図9(a)に示されるように、乗車予定地901のある対応道路902が第1種別道路であり、第2種別道路である道路903からの車両の進入が可能な分岐904が、乗車予定地901に基づき設定される探索範囲905に含まれる場合、
図9(b)にハッチングで示されるように、探索道路には探索範囲905内の第1種別道路だけでなく道路903を含めるようにしてもよい。このとき、道路903を走行する車両の全てが分岐904を介して第1種別道路に進入するとは限られないため、道路903のうちの減速車線(あるいは減速車線に隣接する走行車線)のみを探索道路としてもよい。反対に、追い越し車線を除外した車線を探索道路としてもよい。
【0074】
あるいは、道路903を特定の車線に限定せずに探索道路として決定し、探索処理において、道路903に存在する車両について、減速率、走行車線の位置、減速車線側への車線変更を検出することで、分岐904を介して第1種別道路に進入すると推定される車両について、より詳細な判断に基づき、乗車申込の送信有無を決定するものとしてもよい。また車両に設定されている運転経路計画を取得可能な態様においては、これを参照し、分岐904を介して第1種別道路に進入するか否かの推定を行うものとしてもよい。この他、運転者が過去に採用した運転経路の履歴情報に基づき、該分岐904を介して第1種別道路に進入するか否かの推定を行うものとしてもよい。なお、このような推定は複合的に行われるものであってよく、少なくともいずれかを用いて推定を行うものであれば、分岐904が存在するケースにおいても、探索処理の対象を絞り込むことができる。
【0075】
また、
図9の例では、第2種別道路から分岐を介して第1種別道路に進入する車両も考慮するよう探索道路を決定する態様について説明したが、対応道路が第2種別道路である場合にも同様であることは言うまでもない。即ち、対応道路が第2種別道路である場合であっても、探索範囲に同様の分岐が存在する場合には、第1種別道路から分岐を介して第2種別道路に進入する車両を考慮すべく、例えばICに向かうための第1種別道路や車線を探索道路として決定するものであってもよい。
【0076】
[変形例2]
上述した実施形態では、乗車予定地が定められれば対応道路が一意に特定されるものとして説明したが、本発明の実施はこれに限られるものではない。
【0077】
例えば、高架上に第2種別道路である高速道路が存在し、該高架下には第1種別道路である一般道路が存在するような場合、乗車予定地の地理的位置には異なる種別の道路が混在していることになる。換言すれば、乗車予定地の地理的位置において、高架、フェンス、分離帯等によって、物理的に道路間を車両が移動できない状態で第1種別道路及び第2種別道路が存在することがあり得る。このような場合、利用者が想定している乗車予定地について対応道路の種別の特定が適切になされなければ、乗車申込が適切な運転者端末200に対して送信されず、結果、好適な相乗り運転が実現されない。
【0078】
従って、乗車予定地に複数の種別の道路が対応付けられ得る態様においては、特定部108は、ユーザがいずれの種別の道路について乗車希望を行ったかを判別し、対応道路を特定する必要がある。これは、例えば希望者端末300において乗車希望の操作がなされる際に、サービスアプリにおいて現在位置周辺の風景の撮影を要件付け、撮影により得られた画像と共に乗車希望の情報の送信を行い、特定部108が該画像を解析することで、いずれの種別の道路が対応道路であるかを特定可能に構成することにより実現されてもよい。あるいは、例えば高速道路等では人物の通行が許可されない区間等が存在するため、乗車予定地にある複数種別の道路のうちのいずれか一方において人物の通行が許可されていない場合には、特定部108は対応道路として他方を特定するものであってもよい。あるいは、乗車希望に係る操作が行われるまでに希望者端末300において計測された行動履歴(乗車予定地付近において第2種別道路に到達し得ない移動を行っている、SA内の店舗を利用した等)に基づき、対応道路の種別を特定する構成であってもよい。
【0079】
また、運転者端末200に係る車両の存在する位置においても、同様に道路間を車両が移動できない状態で第1種別道路及び第2種別道路が存在する場合、運転者情報の走行道路種別504は該車両の走行速度、渋滞状況に応じて更新されるものであってよい。
【0080】
[変形例3]
上述した実施形態及び変形例では、探索領域に含まれる対応道路と同一種別の道路は、探索道路として決定するものとして説明したが、本発明の実施はこれに限られるものではない。例えば探索領域に含まれる同一種別の道路であったとしても、進入禁止等の法規制や交通状況、あるいは探索領域中に対応道路に進行可能な経路が存在しないような道路(探索領域中において、道路間での車両の往来が不可能あるいは困難な同一種別の道路)については、探索道路に含めないよう制御するものであってもよい。
【0081】
[その他の実施形態]
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。また本発明に係る情報処理装置は、1以上のコンピュータを該情報処理装置として機能させるプログラムによっても実現可能である。該プログラムは、コンピュータが読み取り可能な記録媒体に記録されることにより、あるいは電気通信回線を通じて、提供/配布することができる。
【解決手段】情報処理装置は、車両への乗車を希望する希望者の乗車予定地と対応付けられた対応道路を特定し、特定した対応道路に基づき、希望者の乗車申込を行う車両を探索する探索道路を決定する。また、決定した探索道路に存在する車両のうちから、乗車申込を行う車両を探索する。装置は、特定した対応道路の種別に応じて、探索道路を異ならせる