(57)【要約】【課題】車両の運転者との間で当該車両への乗車予約が成立している第１のユーザによって使用される無線通信端末の電池残量不足により、運転者と第１のユーザとの合流に関して発生が予想されるトラブルを回避する。【解決手段】車両の運転者との間に車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、乗車予約における運転者と第１のユーザとの合流予定に関する処理を実行する制御部、を備える情報処理装置である。合流予定に関する処理には、乗車予約のキャンセル、合流予定地点の変更等がある。【選択図】図５
2019220002.tif 000002
【特許請求の範囲】
【請求項１】
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を行うことを実行する制御部、
を備える情報処理装置。
【請求項２】
前記制御部は、
前記第１の無線通信端末との通信が第１の時間長以上継続して途絶することを検出することで、前記電池残量不足による通信途絶の可能性を検出することと、
前記合流予定に関する処理として、前記乗車予約のキャンセルと、
を実行する、
請求項１に記載の情報処理装置。
【請求項３】
前記制御部は、
前記第１の無線通信端末との通信が第１の時間長以上継続して途絶することを検出することで、前記電池残量不足による通信途絶の可能性を検出することと、
前記合流予定に関する処理として、前記合流予定の合流予定地点を前記第１のユーザの所在地となる可能性のある所定の地点に変更することと、
を実行する、
請求項１に記載の情報処理装置。
【請求項４】
前記制御部は、前記第１の時間長よりも短い第２の時間長以上継続して前記第１の無線通信端末との通信の途絶を検出した場合に、前記合流予定の合流予定地点を前記第１のユーザの所在地となる可能性のある所定の地点に変更することを実行する、
請求項２に記載の情報処理装置。
【請求項５】
前記制御部は、
前記第１の無線通信端末の電池残量が第１の閾値未満であることを検出することで、前記電池残量不足による通信途絶の可能性を検出することと、
前記合流予定に関する処理として、前記合流予定の合流予定地点を、前記第１の無線通信端末が電池残量不足によって動作停止する前に前記第１のユーザと前記運転者とが合流可能な所定の地点に変更し、少なくとも前記運転者によって用いられる無線通信端末に変更後の合流予定地点を通知することと、
を実行する、
請求項１に記載の情報処理装置。
【請求項６】
前記制御部は、
前記第１の無線通信端末の電池残量が第２の閾値未満であることを検出する場合に、前記第１の無線通信端末に、前記合流予定に関する処理の選択肢を送信することと、
前記第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、前記選択肢の中から前記第１のユーザによって選択された処理を実行することと、
をさらに実行する請求項１から４のいずれか一項に記載の情報処理装置。
【請求項７】
前記制御部は、
前記第１の無線通信端末の電池残量が第１の閾値未満であることを検出することで、前記電池残量不足による通信途絶の可能性を検出することと、
前記第１の無線通信端末の電池残量が第１の閾値未満であり、前記車両への乗車期間が前記第１のユーザと重複し、前記運転者との合流順が前記第１のユーザよりも先である、
第２のユーザが存在する場合には、前記第１のユーザの方が先になるように前記合流順を変更する、
請求項１から６のいずれか一項に記載の情報処理装置。
【請求項８】
前記制御部は、前記合流予定地点の変更によって、前記車両の走行距離又は／及び走行時間に前記変更前からの増加分が発生する場合には、前記増加分に応じて前記運転者に所定のインセンティブを付与する、
請求項３から５のいずれか一項に記載の情報処理装置。
【請求項９】
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を行うことを実行する制御部、
を備える情報処理システム。
【請求項１０】
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出し、
前記第１の無線通信端末について電池残量不足による通信途絶の可能性を検出した場合に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を行うことを実行する、
情報処理方法。
【請求項１１】
コンピュータに、
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を実行させる、
ための情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム、情報処理方法、及び、情報処理プログラムに関する。
【背景技術】
【０００２】
特許文献１には、ユーザ予約端末が配車予約を行う配車情報提供システムが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２０７０７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、車両の運転者との間で当該車両への乗車予約が成立している第１のユーザによって使用される無線通信端末の電池残量不足により、運転者と第１のユーザとの合流に関して発生が予想されるトラブルを回避することができる情報処理装置、情報処理システム、情報処理方法、及び、情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
本発明の態様の一つは、
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を実行する制御部、
を備える情報処理装置である。
【０００６】
また、本発明の他の態様の一つは、
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を実行する制御部、
を備える情報処理システムである。
【０００７】
また、本発明の他の態様の一つは、
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出し、
前記第１の無線通信端末について電池残量不足による通信途絶の可能性を検出した場合に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を実行する、
情報処理方法である。
【０００８】
また、本発明の他の態様の一つは、
コンピュータに、
車両の運転者との間に前記車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合
に、前記乗車予約における前記運転者と前記第１のユーザとの合流予定に関する処理を実行させる、
ための情報処理プログラムである。
【発明の効果】
【０００９】
本発明によれば、車両の運転者との間で当該車両への乗車予約が成立している第１のユーザによって使用される無線通信端末の電池残量不足により、運転者と第１のユーザとの合流に関して発生が予想されるトラブルを回避することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、第１実施形態に係るライドシェアサービス提供システムのシステム構成の一例を示す図である。
【図２】図２は、車載装置、ユーザ端末、センタサーバの各ハードウェア構成の一例を示す図である。
【図３】図３は、センタサーバの機能構成の一例を示す図である。
【図４】図４は、予約情報テーブルの一例である。
【図５】図５は、第１実施形態に係るセンタサーバの合流支援処理のフローチャートの一例である。
【図６】図６は、第２実施形態に係るセンタサーバの合流支援処理のフローチャートの一例である。
【図７】図７は、第３実施形態に係るセンタサーバの合流支援処理のフローチャートの一例である。
【図８】図８は、第４実施形態に係るセンタサーバの合流支援処理のフローチャートの一例である。
【図９】図９は、第５実施形態に係るセンタサーバの合流支援処理のフローチャートの一例である。
【図１０】図１０は、第６実施形態に係るセンタサーバの合流支援処理２のフローチャートの一例である。
【発明を実施するための形態】
【００１１】
以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００１２】
本発明の態様の一つは、車両の運転者との間に車両への乗車予約が成立している第１のユーザによって用いられる第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、乗車予約における運転者と第１のユーザとの合流予定に関する処理を実行する制御部を備える情報処理装置である。
【００１３】
車両への乗車予約において、運転者と第１のユーザとが合流する際には、例えば、第１のユーザは第１の無線通信端末を用いて運転者と連絡を取り合うことが考えられる。例えば、運転者と第１のユーザとが見知らぬ者同士である場合には、両者が合流するために、第１の無線通信端末を用いて連絡を取り合うことが重要となる。しかしながら、第１のユーザの第１の無線通信端末は、電池を電源としているため、電池残量が不足すると動作停止してしまい、この場合、第１のユーザは運転者と連絡を取る手段がなくなってしまうことが多い。これによって、第１のユーザと運転者とが合流できないといったトラブルや、合流予定地点までの運転者の移動が無駄になるといったトラブルが発生する可能性がある。
【００１４】
本発明の態様の一つによれば、情報処理装置は、第１の無線通信端末の電池残量不足による通信途絶の可能性を検出する場合に、運転者と第１のユーザとの合流予定に関する処
理を行うことを実行する。これによって、乗車予約の運転者と第１のユーザとの合流に関して発生するトラブルを回避することができる。
【００１５】
また、本発明の態様の一つでは、制御部は、第１の無線通信端末との通信が第１の時間長以上継続して途絶することを検出することで、電池残量不足による通信途絶の可能性を検出することと、合流予定に関する処理として、乗車予約のキャンセルと、を実行するようにしてもよい。これによって、例えば、第１のユーザと運転者とが合流できない場合に、合流予定地点までの運転者の移動が無駄になるというトラブルを回避し、運転者にかかる負担を軽減することができる。この場合に運転者にかかる負担には、例えば、車両による移動にかかるガソリン代、時間、労力等がある。
【００１６】
また、本発明の態様の一つでは、制御部は、第１の無線通信端末との通信が第１の時間長以上継続して途絶することを検出することで、電池残量不足による通信途絶の可能性を検出することと、合流予定に関する処理として、合流予定の合流予定地点を所定の地点に変更することと、を実行するようにしてもよい。合流予定地点の変更先は、例えば、第１のユーザの所在地となる可能性のある所定の地点である。より具体的には、合流予定地点の変更先は、第１の無線通信端末から最後に受信した位置情報が示す地点、第１の無線通信端末から所定の周期で受信した位置情報から推測される所定時間後の第１の無線通信端末の位置等である。これによって、例えば、第１の無線通信端末が電池残量不足によって動作停止した場合でも、運転者が第１のユーザの所在地となる可能性のある所定の地点に向かうので、第１のユーザと運転者とが合流する可能性を向上させることができる。
【００１７】
また、本発明の態様の一つでは、制御部は、第１の時間長よりも短い第２の時間長以上継続して第１の無線通信端末との通信の途絶を検出した場合に、合流予定の合流予定地点を第１のユーザの所在地となる可能性のある所定の地点に変更することを実行し、その後、第１の無線通信端末との通信が途絶したまま第１の時間長が経過すると、乗車予約をキャンセルするようにしてもよい。これによって、例えば、第１の無線通信端末との通信が一旦中断してもまた復帰する場合に、乗車予約がキャンセルされることを抑制することができる。第１の無線通信端末との通信が一旦中断してもまた復帰する場合には、例えば、第１の無線通信端末の電池残量がなくなってもすぐに第１のユーザによって充電が行われ、第１の無線通信端末の動作が再開される場合、第１の無線通信端末が通信圏外に移動し、その後、通信圏内に移動した場合、等がある。また、例えば、第１の無線通信端末との通信が途絶してから第２の時間長以上第１の時間長未満の間に、合流予定時刻となり、運転者が第１のユーザの所在地となる可能性のある所定の地点に移動することで、第１のユーザと運転者とが合流する可能性を向上させることができる。
【００１８】
また、本発明の態様の一つでは、制御部は、第１の無線通信端末の電池残量が第１の閾値未満であることを検出することで、電池残量不足による通信途絶の可能性を検出することと、合流予定に関する処理として、合流予定の合流予定地点を、第１の無線通信端末が電池残量不足によって動作停止する前に第１のユーザと運転者とが合流可能な所定の地点に変更し、運転者によって用いられる無線通信端末に変更後の合流予定地点を通知することと、を実行するようにしてもよい。これによって、第１の無線通信端末が動作している間に運転者と第１のユーザとが合流する可能性が高めることができる。
【００１９】
また、本発明の態様の一つでは、制御部は、第１の無線通信端末の電池残量が第２の閾値未満であることを検出する場合に、第１の無線通信端末に、合流予定に関する処理の選択肢を送信することと、第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する場合に、選択肢の中から第１のユーザによって選択された処理を実行することと、をさらに実行するようにしてもよい。第１の無線通信端末の電池残量の第２の閾値は、例えば、第１の閾値以下の値である。第１のユーザに、合流予定に関する処理につい
て選択してもらうことによって、例えば、第１の無線通信端末が電池残量不足による動作停止状態になった場合に、システム側がどのような対応を行うのかを第１のユーザが認識することができ、運転者との合流に関するトラブルの発生をより抑制することができる。
【００２０】
また、本発明の態様の一つでは、制御部は、第１の無線通信端末の電池残量が第１の閾値未満であることを検出することで、電池残量不足による通信途絶の可能性を検出することと、第１の無線通信端末の電池残量が第１の閾値未満であり、車両への乗車期間が第１のユーザと重複し、運転者との合流順が第１のユーザよりも先である、第２のユーザが存在する場合には、第１のユーザ方が先になるように合流順を変更するようにしてもよい。これによって、第２のユーザが存在する場合でも、第１の無線通信端末の電池残量が少なくなると第１のユーザの運転者との合流順が優先されるので、第１の無線通信端末が電池残量不足によって動作停止する前に、第１のユーザは運転者と合流できる可能性が高くなる。
【００２１】
また、本発明の態様の一つでは、制御部は、合流予定地点の変更によって、車両の走行距離又は／及び走行時間に変更前からの増加分が発生する場合には、増加分に応じて運転者に所定のインセンティブを付与するようにしてもよい。これによって、合流予定地点の変更又は合流順の変更によって生じる走行距離又は／及び走行時間の増加による運転者への負担の増加に対して救済措置を取ることができる。
【００２２】
＜第１実施形態＞
図１は、第１実施形態に係るライドシェアサービス提供システム１のシステム構成の一例を示す図である。ライドシェアサービス提供システム１は、車両への同乗を希望する運転者と、車両への乗車を希望する乗車希望者とを、例えば、両者の目的地及び移動希望時期等に基づいて、結び付け、乗車希望者には移動手段を、運転者にはインセンティブを提供するサービスを提供するシステムである。車両への同乗を希望する運転者と車両への乗車を希望する乗車希望者とを互いの条件が満たされるように結び付けることを、以下、マッチング、と称する。
【００２３】
ライドシェアサービス提供システム１は、複数の運転者によって運転される車両１０、複数の乗車希望者のユーザ端末２００、センタサーバ３００を含む。ただし、図１では、車両１０とユーザ端末２００とは、それぞれ、１台ずつ抽出されて表示されている。車両１０は車載装置１００を搭載している。
【００２４】
ユーザ端末２００は、第１実施形態では、無線通信及び携帯可能なコンピュータである。具体的には、ユーザ端末２００は、例えば、スマートフォン、タブレット端末、携帯電話端末、ノート型のＰＣ（Personal Computer）である。車載装置１００は、無線通信可
能で且つ車載可能なコンピュータである。具体的には、例えば、車載装置１００は、車載専用のデータ通信装置、カーナビゲーションシステム、スマートフォン、タブレット端末等である。ただし、第１実施形態では、車載装置１００は、データ通信装置であることを想定する。
【００２５】
車載装置１００、ユーザ端末２００、センタサーバ３００は、ネットワークＮ１に接続している。ネットワークＮ１は、例えば、インターネット等の公衆通信網である。車載装置１００及びユーザ端末２００は、ネットワークＮ１を通じて、センタサーバ３００と通信可能である。センタサーバ３００は、「情報処理装置」の一例である。車載装置１００及びユーザ端末２００は、「無線通信端末」の一例である。
【００２６】
乗車希望者のユーザ端末２００には、例えば、ライドシェアサービスを享受するためのアプリケーションがインストールされている。乗車希望者は、例えば、ユーザ端末２００
上で当該アプリケーションを起動させ、当該アプリケーションを操作することで、乗車希望者に関する情報や乗車要求をセンタサーバ３００に送信する。乗車要求とともに、例えば、乗車場所、降車場所、移動希望時期等も送信される。
【００２７】
車載装置１００にも、例えば、ライドシェアサービスを享受するためのアプリケーションがインストールされている。運転者は、車載装置１００上で当該アプリケーションを起動させ、当該アプリケーションを操作することで、運転者や車両１０に関する情報をセンタサーバ３００に送信する。
【００２８】
センタサーバ３００は、例えば、ライドシェアサービスに登録する車載装置１００、ユーザ端末２００からの情報の登録を受け付ける。センタサーバ３００には、例えば、乗車希望者及び運転者に関する識別情報等が登録されている。
【００２９】
センタサーバ３００は、乗車希望者のユーザ端末２００からライドシェアによる車両１０への乗車の予約を要求する乗車予約要求を受信する。センタサーバ３００は、乗車予約要求を受信すると、当該乗車希望者と運転者とのマッチングを行う。マッチングの方法は、周知の技術のいずれが用いられてもよい。例えば、センタサーバ３００は、乗車希望者の乗車場所と降車場所の少なくともいずれか一方を移動予定経路に含み、且つ、当該移動予定経路による移動予定時期が乗車希望者の移動希望時期を含む運転者の中から、乗車希望者のマッチング相手を選択する。
【００３０】
センタサーバ３００は、マッチングが完了すると、マッチングされた運転者に紐づけられている車載装置１００へ乗車予約要求を送信する。乗車予約要求とともに、乗車希望者との合流予定地点及び合流予定時刻、乗車希望者の降車希望場所、乗車希望者に関する情報等も車載装置１００へ送信される。合流予定地点、合流予定時刻等は、例えば、センタサーバ３００によって、算出される。車載装置１００から乗車予約要求に対するＯＫ応答が返ってくると、センタサーバ３００は、乗車希望者のユーザ端末２００からの乗車予約要求に対する予約成立を判定し、乗車予約成立通知をユーザ端末２００へ送信する。
【００３１】
例えば、乗車予約の合流時刻から所定時間前の時刻になると、車載装置１００とユーザ端末２００とは、それぞれ、所定の周期で、センタサーバ３００への位置情報の送信を開始する。センタサーバ３００は、例えば、車載装置１００とユーザ端末２００とから受信される位置情報に基づいて、車載装置１００とユーザ端末２００との位置を監視する。センタサーバ３００は、例えば、車載装置１００とユーザ端末２００とが合流予定地点から所定の範囲内に進入したことを検出すると、車載装置１００とユーザ端末２００とに互いの接近通知を送信することで、運転者と乗車希望者との合流を支援する。
【００３２】
しかしながら、例えば、乗車希望者のユーザ端末２００はいわゆるモバイル機器であることが多く、電池を動力源としている場合が多い。そのため、例えば、運転者との合流予定の直前にユーザ端末２００の電池残量不足による動作停止が発生する可能性がある。運転者との合流予定の直前にユーザ端末２００が動作停止状態になってしまうと、センタサーバ３００からの合流支援を受けることができなかったり、運転者との連絡手段がなくなってしまったりして、乗車希望者と運転者とが合流ができなくなる可能性が高くなる。
【００３３】
例えば、ユーザ端末２００のバッテリ切れが原因で乗車希望者と運転者とが合流できない場合、運転者は合流予定時刻に合流予定地点に到着するように移動しても当該移動が無駄になり、運転者にかかる時間的、労力的、コスト的な負担が多くなってしまう。なお、車載装置１００がスマートフォン等のモバイル端末である場合にも、同様の問題が発生する可能性がある。
【００３４】
第１実施形態では、ユーザ端末２００は、所定の周期で、位置情報とともに電池残量に関する情報をセンタサーバ３００に送信する。センタサーバ３００は、例えば、ユーザ端末２００からの電池残量に関する情報を監視し、ユーザ端末２００の電池残量不足による通信途絶を検出する。センタサーバ３００は、ユーザ端末２００の電池残量不足による通信途絶を検出した場合には、乗車希望者と運転者との間の乗車予約をキャンセルする。これによって、運転者は合流予定地点に移動しなくてよくなり、運転者にかかる負担を軽減することができる。
【００３５】
図２は、車載装置１００、ユーザ端末２００、センタサーバ３００の各ハードウェア構成の一例を示す図である。センタサーバ３００は、例えば、汎用又は専用のコンピュータである。センタサーバ３００は、ハードウェア構成要素として、プロセッサ３０１、主記憶部３０２、補助記憶部３０３、通信部３０４を備える。これらは、互いにバスによって接続される。
【００３６】
プロセッサ３０１は、例えば、ＣＰＵ（Central Processing Unit）である。プロセッ
サ３０１は、主記憶部３０２に実行可能に展開されたコンピュータプログラムを実行し、センタサーバ３００としての処理を実行する。なお、センタサーバ３００が備えるプロセッサ３０１は、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また、単一のソケットで接続される単一のＣＰＵがマルチコア構成を有していても良い。また、センタサーバ３００としての少なくとも一部の処理は、ＣＰＵ以外のプロセッサ、例えば、Digital Signal Processor（ＤＳＰ）、Graphics Processing Unit（ＧＰＵ）等の専用プロセッサで行われても良い。また、センタサーバ３００としての少なくとも一部の処理は、集積回路（ＩＣ）、その他のディジタル回路、アナログ回路で行われてもよい。プロセッサ３０１は、「情報処理装置」の「制御部」の一例である。
【００３７】
主記憶部３０２は、プロセッサ３０１が実行するコンピュータプログラム、プロセッサ３０１が処理するデータ等を格納する。主記憶部３０２は、例えば、Dynamic Random Access Memory（ＤＲＡＭ）、Static Random Access Memory（ＳＲＡＭ）、Read Only Memory（ＲＯＭ）等である。補助記憶部３０３は、不揮発性の記憶装置であり、例えば、ハー
ドディスクドライブ、Solid State Drive（ＳＳＤ）等である。補助記憶部３０３には、
主記憶部３０２に展開される前のコンピュータプログラム、各種データ等が保持されている。補助記憶部３０３に記憶されているプログラムには、例えば、ＯＳ（Operation System）、ライドシェア制御プログラム等がある。ライドシェア制御プログラムは、ライドシェアサービス提供システム１におけるセンタサーバ３００の処理をコンピュータに実行させるためのプログラムである。
【００３８】
通信部３０４は、例えば、ＬＡＮ（local Area Network）を介して、ネットワークＮ１に接続し、ネットワークＮ１を通じて、車載装置１００、ユーザ端末２００等と通信する。
【００３９】
なお、センタサーバ３００のハードウェア構成は、図２に示されるものに限定されない。センタサーバ３００は、例えば、可搬記録媒体に記録されたプログラムを読み込み、主記憶部３０２に展開し、実行することができる。可搬記録媒体には、例えば、ＵＳＢ（Universal Serial Bus）メモリ、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、Ｂｌｕ−ｒａｙ（登録商標）ディスクのようなディスク記録媒体である。
【００４０】
次に、ユーザ端末２００は、例えば、スマートフォン、携帯電話端末、タブレット端末、個人情報端末、ウェアラブルコンピュータ（スマートウォッチ等）等の小型のコンピュータである。ユーザ端末２００は、ＰＣであってもよい。図２では、ユーザ端末２００はスマートフォンであることを想定して説明される。
【００４１】
ユーザ端末２００は、プロセッサ２０１、主記憶部２０２、補助記憶部２０３、表示部２０４、入力部２０５、通信部２０６、位置情報センサ２０７を有する。プロセッサ２０１、主記憶部２０２、補助記憶部２０３については、センタサーバ３００のプロセッサ３０１、主記憶部３０２、補助記憶部３０３の説明と同様であるため、説明は省略される。ただし、ユーザ端末２００の補助記憶部２０３には、ライドシェアサービスを享受するためのアプリケーションプログラムが記憶されている。
【００４２】
表示部２０４は、例えば、ＬＣＤ（Liquid Crystal Display）、ＥＬ（Electroluminescence）パネル等である。入力部２０５は、タッチパネル、押しボタン等を含む。更に、
入力部２０５は、映像や画像の入力を可能にするカメラを含む。また、入力部２０５は、マイクロフォンのような音声の入力部を含むことができる。
【００４３】
通信部２０６は、例えば、ＷｉＦｉ等の私設ネットワークや、３Ｇ、ＬＴＥ、ＬＴＥ−Ａｄｖａｎｃｅｄ、５Ｇ等のキャリア網に採用されている通信方式に対応する通信部である。通信部２０６は、例えば、ＷｉＦｉネットワークやキャリア網等のアクセス網を介してネットワークＮ１に接続し、センタサーバ３００等と通信を行う。
【００４４】
位置情報センサ２０７は、所定の周期で、ユーザ端末２００の位置情報を取得する。位置情報センサ２０７は、例えば、Global Positioning System（ＧＰＳ）受信部、ＷｉＦ
ｉ通信部等である。なお、ユーザ端末２００のハードウェア構成は、図２に示されるものに限定されない。
【００４５】
次に、車載装置１００は、プロセッサ１０１、主記憶部１０２、補助記憶部１０３、通信部１０５、位置情報センサ１０６を含む。プロセッサ１０１、主記憶部１０２、補助記憶部１０３、通信部１０５、位置情報センサ１０６の説明は、それぞれ、プロセッサ３０１、主記憶部３０２、補助記憶部３０３、通信部２０６、位置情報センサ２０７の説明と同様であるため省略される。ただし、車載装置１００の補助記憶部１０３には、ライドシェアサービスを享受するためのアプリケーションプログラムが記憶されている。
【００４６】
なお、ネットワークＮ１は、例えば、インターネット等の世界規模の公衆通信網でありＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークＮ１は、携帯電話等の電話通信網、ＷｉＦｉ等の無線通信網を含んでもよい。
【００４７】
図３は、センタサーバ３００の機能構成の一例を示す図である。センタサーバ３００は、機能構成要素として、予約処理部３１、マッチング処理部３２、端末通信部３３、運転者情報データベース（ＤＢ）３４、乗車希望者情報ＤＢ  ３５、予約情報ＤＢ  ３６を備える。これらの機能構成要素は、例えば、センタサーバ３００のプロセッサ３０１が、補助記憶部３０３に記憶される、ライドシェア制御プログラムを実行することによって達成される機能構成要素である。ただし、各機能構成素のいずれか、またはその処理の一部がハードウェア回路により実行されてもよい。
【００４８】
端末通信部３３は、車載装置１００及びユーザ端末２００とのインタフェースである。端末通信部３３は、通信部３０４を通じて、車載装置１００及びユーザ端末２００とのデータの送受信を行う。具体的には、例えば、端末通信部３３は、ユーザ端末２００から乗車予約要求を受信し、予約処理部３１に出力する。例えば、端末通信部３３は、車載装置１００から位置情報を、ユーザ端末２００から位置情報と電力残量に関する情報とを受信し、予約処理部３１に出力する。電力残量に関する情報は、例えば、満充電状態における電力量に対する現在の蓄電力量のパーセンテージ、現在の蓄電力量、等である。
【００４９】
予約処理部３１は、乗車予約に関する制御を行う。具体的には、予約処理部３１は、端末通信部３３を通じて、ユーザ端末２００から乗車予約要求を受信する。ユーザ端末２００からは、乗車予約要求とともに、乗車希望場所、降車希望場所、移動希望時期が受信される。
【００５０】
予約処理部３１は、ユーザ端末２００から乗車予約要求を受信した場合には、マッチング処理部３２に、マッチングを依頼する。予約処理部３１は、マッチング処理部３２から、例えば、ユーザ端末２００に対応する乗車希望者についてマッチングされた運転者の情報と、合流予定地点及び合流予定時刻の入力を受ける。予約処理部３１は、ユーザ端末２００に対応する乗車希望者についてマッチングされた運転者に対応する車載装置１００へ、端末通信部３３を通じて、乗車予約要求を送信する。乗車予約要求とともに、乗車予約情報も送信される。乗車予約情報は、例えば、合流予定地点及び合流予定時刻、乗車希望者の降車希望場所及び到着希望時刻、乗車希望者の情報等を含む。乗車予約情報に含まれる乗車希望者の情報には、例えば、乗車希望者のユーザＩＤ、属性等が含まれる。
【００５１】
予約処理部３１は、端末通信部３３を通じて、車載装置１００から乗車予約要求に対するＯＫ応答を受信した場合には、当該乗車予約の成立を判定し、乗車予約情報を予約情報ＤＢ  ３６に登録する。
【００５２】
また、予約処理部３１は、端末通信部３３を通じて、乗車予約要求の送信元のユーザ端末２００へ、乗車予約成立通知を送信する。乗車予約成立通知とともに、例えば、合流予定地点、合流予定時刻、運転者の情報も送信される。運転者の情報には、例えば、運転者のユーザＩＤ、属性、車両１０の情報等も含まれている。
【００５３】
予約処理部３１は、例えば、乗車予約の合流予定時刻から所定時間前の時刻なると、合流支援処理を開始する。合流支援処理は、乗車予約が成立している運転者と乗車希望者との合流を支援するための処理である。合流支援処理が開始される時刻は、例えば、乗車予約の合流予定時刻から１０分前、１５分前、３０分前等の時刻である。合流支援処理の開始タイミングは、例えば、ライドシェアサービス提供システム１の管理者、乗車希望者、運転者のいずれかによって設定されてもよい。合流支援処理は、具体的には、以下の通りである。
【００５４】
予約処理部３１は、乗車予約が成立している運転者と乗車希望者とのそれぞれが用いる、車載装置１００及びユーザ端末２００からそれぞれの位置情報を所定の周期で受信し、両者の位置情報を把握する。例えば、予約処理部３１は、車載装置１００及びユーザ端末２００それぞれの位置情報を、所定時間又は所定個数、主記憶部３０２にバッファする。予約処理部３１は、例えば、乗車希望者のユーザ端末２００と運転者の車載装置１００とが合流予定地点から所定の範囲内に進入したことを検出すると、両者に接近通知を送信する。
【００５５】
さらに、予約処理部３１は、ユーザ端末２００から電池残量に関する情報を所定の周期で受信する。例えば、予約処理部３１は、ユーザ端末２００の電池残量に関する情報を、所定時間又は所定個数、主記憶部３０２にバッファする。
【００５６】
予約処理部３１は、第１実施形態では、ユーザ端末２００の電池残量不足による通信の途絶の可能性を検出すると、当該ユーザ端末２００の乗車希望者と運転者との乗車予約をキャンセルし、運転者の車載装置１００へ乗車予約のキャンセルを通知する。ユーザ端末２００の電池残量不足による通信の途絶の可能性は、第１実施形態では、例えば、バッテリ切れ判定条件１が満たされることによって検出される。バッテリ切れ判定条件１は、例
えば、時間長Ｔ１以上経過してもユーザ端末２００から位置情報及び／又は電池残量に関する情報が受信されないこと、又は、時間長Ｔ１以上ユーザ端末２００とのセッションが切断することである。時間長Ｔ１は、例えば、数分〜１時間の範囲内で設定される。ただし、これに限定されない。また、バッテリ切れ判定条件１は、上記内容のいずれかと、受信された最新の電池残量が所定の閾値未満であること、との両方が満たされることであってもよい。
【００５７】
マッチング処理部３２は、予約処理部３１からの依頼に応じて、乗車予約要求の送信元のユーザ端末２００に対応する乗車希望者と運転者とのマッチングを行う。マッチング処理部３２のマッチング方法は、周知の技術のいずれであってもよく、特定の方法に限定されない。例えば、マッチング処理部３２は、後述の運転者情報ＤＢ  ３４の中から、移動予定時期が乗車予約要求の移動希望時期を含み、目的地又は経由地とその付近に乗車希望者の乗車希望場所及び降車希望場所を含む移動予定を有する運転者を抽出する。マッチング処理部３２は、抽出された運転者の中から、例えば、ランダムに、又は、評価値、属性等に基づいて、乗車希望者のマッチング相手を選択する。
【００５８】
また、マッチング処理部３２は、例えば、乗車希望者の乗車希望場所及び降車希望場所、運転者の目的地及び経由地に基づいて、合流予定地点を決定する。また、マッチング処理部３２は、乗車希望者の移動希望時期と運転者の移動予定時期とに基づいて、合流予定時刻を決定する。合流予定地点、合流予定時刻の決定方法は、周知の技術のいずれであってもよく、特定の方法に限定されない。マッチング処理部３２は、選択した運転者の情報、合流予定地点、合流予定時刻等を予約処理部３１に出力する。
【００５９】
運転者情報ＤＢ  ３４、乗車希望者情報ＤＢ  ３５、予約情報ＤＢ  ３６は、それぞれ、例えば、プロセッサ３０１によって実行されるデータベース管理システム（Database Management System、ＤＢＭＳ）のプログラムが、補助記憶部３０３に記憶されるデータを管理することで構築される。運転者情報ＤＢ  ３４、乗車希望者情報ＤＢ  ３５、予約情報ＤＢ  ３６は、例えば、リレーショナルデータベースである。
【００６０】
運転者情報ＤＢ  ３４には、運転者に関する情報が含まれている。運転者に関する情報には、例えば、運転者のユーザＩＤ、車載装置ＩＤ、運転者の属性情報、運転者の連絡先の情報、車両ＩＤ、車両の外観情報、車両の最大乗車可能人数、及び、運転者の移動予定に関する情報が含まれている。運転者の属性には、例えば、性別、年齢、居住地域等の情報が含まれている。車両の外観情報には、例えば、車種、車両の色、ナンバー等の情報が含まれている。運転者の移動予定に関する情報には、移動予定時期、出発地、目的地、経由地等の情報が含まれている。
【００６１】
運転者情報ＤＢ  ３４に格納されている情報は、例えば、車載装置１００等を通じて、運転者によって登録された情報である。運転者情報ＤＢ  ３４に格納されている運転者に関する情報は、例えば、マッチング処理部３２によって、マッチングの際に用いられる。また、例えば、乗車希望者のマッチング相手として選択された運転者の情報は、運転者情報ＤＢ  ３４から読み出され、マッチング処理部３２から予約処理部３１に通知され、乗車予約成立通知とともにユーザ端末２００に通知される。乗車予約成立通知とともにユーザ端末２００に通知される、乗車希望者のマッチング相手として選択された運転者の情報は、例えば、運転者情報ＤＢ  ３４に保持されている当該運転者に関する情報全てであってもよいし、一部であってもよい。
【００６２】
乗車希望者情報ＤＢ  ３５には、乗車希望者に関する情報が含まれている。運転者に関する情報には、例えば、乗車希望者のユーザＩＤ、ユーザ端末２００のＩＤ、乗車希望者の属性情報、乗車希望者の連絡先の情報が含まれている。乗車希望者の属性には、例えば
、性別、年齢、居住地域等の情報が含まれている。
【００６３】
乗車希望者情報ＤＢ  ３５に格納されている情報は、例えば、ユーザ端末２００等を通じて、乗車希望者によって登録された情報である。乗車希望者情報ＤＢ  ３５に格納されている乗車希望者に関する情報は、例えば、マッチング処理部３２によって、マッチングの際に用いられる。また、例えば、乗車希望者の情報は、乗車希望者情報ＤＢ  ３５から読み出され、マッチング処理部３２から予約処理部３１に通知され、乗車予約要求とともに車載装置１００に通知される。乗車予約要求とともに車載装置１００に通知される、乗車希望者の情報は、例えば、乗車希望者情報ＤＢ  ３４に保持されている当該乗車希望者に関する情報全てであってもよいし、一部であってもよい。
【００６４】
図４は、予約情報テーブルの一例である。予約情報テーブルは、予約情報ＤＢ  ３６に保持されているテーブルである。予約情報テーブルは、乗車予約に関する情報を保持するテーブルである。
【００６５】
図４に示される予約情報テーブルは、運転者ＩＤ、乗車希望者ＩＤ、車両番号、合流予定地点、合流予定時刻、乗車希望者の降車希望場所、乗車希望者の到着希望時刻、同乗者有無のフィールドを有する。運転者ＩＤフィールドには、運転者を識別するＩＤが入力される。乗車希望者ＩＤフィールドには、乗車希望者を識別するＩＤが入力される。車両番号フィールドには、車両１０を識別するための識別情報が入力される。
【００６６】
合流予定地点フィールドには、マッチング処理部３２によって決定された合流予定地点の情報が入力される。合流予定地点フィールドには、例えば、合流予定地点の情報として、経度及び緯度、住所、ランドマークの名称等のいずれが入力されてもよい。合流予定時刻フィールドには、マッチング処理部３２によって決定された合流予定時刻が入力される。
【００６７】
乗車希望者の降車希望場所及び到着希望時刻フィールドに格納される情報は、乗車希望者のユーザ端末２００からの乗車予約要求とともに受信される降車希望場所、移動予定時期に基づいて入力される。
【００６８】
同乗者有無フィールドには、同乗者の有無を示す情報が入力される。同乗者の有無を示す情報は、例えば、フラグ、「有」又は「無」、同乗者である乗車希望者ＩＤ等である。同乗者は、例えば、乗車予約情報において、運転者、乗車予定時期（合流予定時刻から到着希望時間までの期間）の一部又は全部とが重複する乗車希望者同士のことである。同業者有無フィールドに格納される情報は、例えば、新規登録の乗車予約情報と運転者、乗車予定期間の一部又は全部とが重複する乗車予約情報の有無が判定され、重複する乗車予約情報が存在する場合に、当該新規登録の乗車予約情報と、重複する乗車予約情報と、において登録又は更新される。
【００６９】
図４に示される例の一つ目のエントリでは、運転者Ｓ００１が運転する車両１０に、乗車希望者Ｃ００１が、８：００に地点ｆで合流し、運転者Ｓ００１は、目的地ｇに向かって車両１０を移動させることが示される。
【００７０】
図４に示される２つ目と３つ目とのエントリでは、運転者Ｓ００１と、合流予定時刻から到着希望時刻までの乗車予定期間とが重複しており、乗車希望者Ｃ００２とＣ００３とは、同乗者同士であることが示される。
【００７１】
図４に示される例の２つ目と３つ目のエントリでは、運転者Ｓ００２が運転する車両１０に、乗車希望者Ｃ００２が、８：３０に地点ｈで合流し、運転者Ｓ００２は、地点ｉに
向かって車両１０を移動させ、８：４５に地点ｉで乗車希望者Ｃ００３を更に同乗させることが示される。また、運転者Ｓ００２は、乗車希望者Ｃ００３の目的地ｊに向かって車両１０を移動させ、地点ｊで乗車希望者Ｃ００３を降車させた後、乗車希望者Ｃ００２の目的地ｅに向かって車両１０を移動させることが示される。
【００７２】
なお、センタサーバ３００の各機能構成素のいずれか、またはその処理の一部は、ネットワークＮ１に接続される他のコンピュータにより実行されてもよい。例えば、予約処理部３１とマッチング処理部３２との処理は、別々のコンピュータにより実行されてもよい。
【００７３】
＜処理の流れ＞
図５は、第１実施形態に係るセンタサーバ３００の合流支援処理のフローチャートの一例である。図５に示される処理は、例えば、予約情報ＤＢ  ３６に保持される乗車予約情報それぞれについて、所定の周期で繰り返し実行される。図５に示される処理の実行主体は、例えば、センタサーバ３００のプロセッサ３０１であるが、便宜上、図５では、機能構成要素を主体として説明する。図５以降のフローチャートについても同様である。以下、図５以降の合流支援処理のフローチャートにおいて、特に断りのない限り、乗車希望者、運転者、ユーザ端末２００、車載装置１００と称する場合には、処理対象の乗車予約情報に該当する乗車希望者、運転者、ユーザ端末２００、車載装置１００であることとする。図５以降の合流支援処理のフローチャートの処理の対象の乗車予約情報の乗車希望者、当該乗車希望者のユーザ端末２００は、それぞれ、「第１のユーザ」、「第１の無線通信端末」の一例である。図５以降の合流支援処理のフローチャートの処理の対象の乗車予約情報の運転者、当該運転者の車両１０は、それぞれ、「運転者」、「車両」の一例である。
【００７４】
ＯＰ１０１では、予約処理部３１は、対象の乗車予約情報について、合流予定時刻から所定時間前の時刻になったか否かを判定する。合流予定時刻から所定時間前の時刻になった場合には（ＯＰ１０１：ＹＥＳ）、処理がＯＰ１０２に進む。合流予定時刻から所定時間前の時刻にまだなっていない場合には（ＯＰ１０１：ＮＯ）、図５に示される処理が終了し、所定の周期後に図５に示される処理が再度開始される。
【００７５】
ＯＰ１０２では、予約処理部３１は、バッテリ切れ判定条件１が満たされるか否かを判定する。バッテリ切れ判定条件１は、例えば、（Ａ）ユーザ端末２００から位置情報及び／又は電池残量に関する情報が最後に受信されてから時間長Ｔ１以上経過したこと、（Ｂ）時間長Ｔ１以上ユーザ端末２００とのセッションが切断すること、（Ｃ）（Ａ）又は（Ｂ）のいずれかが満たされ、且つ、受信された最新の電池残量が所定の閾値未満であること、のうちのいずれかである。
【００７６】
バッテリ切れ判定条件１が満たされる場合には（ＯＰ１０２：ＹＥＳ）、処理がＯＰ１０３に進む。バッテリ切れ判定条件１が満たされていない場合には（ＯＰ１０２：ＮＯ）、処理がＯＰ１０５に進む。ＯＰ１０２の肯定判定は、「第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する」、「前記第１の無線通信端末との通信が第１の時間長以上継続して途絶することを検出すること」の一例である。時間長Ｔ１は、「第１の時間長」の一例である。
【００７７】
ＯＰ１０３では、バッテリ切れ判定条件１が満たされているので、予約処理部３１は、対象の乗車予約をキャンセルする。ＯＰ１０３の処理は、「合流予定に関する処理」の一例である。
【００７８】
ＯＰ１０４では、予約処理部３１は、運転者の車載装置１００に、乗車予約のキャンセ
ルの通知を送信する。乗車予約のキャンセルの通知とともに、該当する乗車予約情報も送信される。なお、乗車予約がキャンセルされると、例えば、該当する乗車予約情報は、予約情報テーブルにおいてキャンセルされたことを示す情報が付与される。その後、対象の乗車予約情報について、図５に示される処理が終了し、以降、対象の乗車予約情報について図５に示される処理は実行されない。
【００７９】
なお、その後、キャンセルされた乗車予約情報に該当する乗車希望者のユーザ端末２００との通信が再開された場合には、予約処理部３１は、当該ユーザ端末２００に乗車予約がキャンセルされたことを通知するようにしてもよい。
【００８０】
ＯＰ１０５では、バッテリ切れ判定条件１が満たされていないので、予約処理部３１は、運転者の車載装置１００と乗車希望者のユーザ端末２００とが合流予定地点から所定距離内に存在しているか否かを判定する。ＯＰ１０５の判定は、車載装置１００及びユーザ端末２００の位置情報に基づいて行われる。
【００８１】
運転者の車載装置１００及び乗車希望者のユーザ端末２００がともに合流予定地点から所定距離内に存在していることが検出された場合には（ＯＰ１０５：ＹＥＳ）、処理がＯＰ１０６に進む。運転者の車載装置１００及び乗車希望者のユーザ端末２００がともに合流予定地点から所定距離内に存在していることが検出されていない場合には（ＯＰ１０５：ＮＯ）、処理がＯＰ１０７に進む。
【００８２】
ＯＰ１０６では、予約処理部３１は、端末通信部３３を通じて、運転者の車載装置１００及び乗車希望者のユーザ端末２００へ、接近通知を送信する。その後、処理がＯＰ１０７に進む。
【００８３】
ＯＰ１０７では、予約処理部３１は、端末通信部３３を通じて、少なくとも運転者の車載装置１００又は乗車希望者のユーザ端末２００のいずれか一方から合流完了通知を受信したか否かを判定する。少なくとも運転者の車載装置１００又は乗車希望者のユーザ端末２００のいずれか一方から合流完了通知が受信された場合には（ＯＰ１０７：ＹＥＳ）、対象の乗車予約情報について、図５に示される処理が終了し、以後、当該対象の乗車予約情報については図５の処理は行われない。運転者の車載装置１００又は乗車希望者のユーザ端末２００のいずれからも合流完了通知が受信されていない場合には（ＯＰ１０７：ＮＯ）、処理がＯＰ１０８に進む。
【００８４】
ＯＰ１０８では、予約処理部３１は、合流予定時刻＋αの時刻を過ぎたか否かを判定する。なお、合流予定時刻＋αの時刻を過ぎた場合には（ＯＰ１０８：ＹＥＳ）、処理がＯＰ１０９に進み、ＯＰ１０９において予約処理部３１は、対象の乗車予約をキャンセルする。このとき、予約処理部３１は、運転者の車載装置１００に乗車予約のキャンセルを通知してもよい。その後、図５に示される処理が終了する。
【００８５】
合流予定時刻＋αの時刻にまだ達していない場合には（ＯＰ１０８：ＮＯ）、処理がＯＰ１０２に進む。なお、図５に示される合流支援処理は一例であって、センタサーバ３００の合流支援処理は図５に示される処理に限定されない。
【００８６】
＜第１実施形態の作用効果＞
図５に示される例では、例えば、合流予定時刻から所定時間前の時刻ｔ１から合流予定時刻＋αから時間長Ｔ１前の時刻ｔ２までの間に、乗車希望者のユーザ端末２００が電池残量不足により動作停止した場合には（ＯＰ１０２：ＹＥＳ）、乗車予約がキャンセルされる（ＯＰ１０３）。また、例えば、時刻ｔ２から合流予定時刻＋αまでの間に、乗車希望者のユーザ端末２００が電池残量不足により動作停止した場合には、バッテリ切れ判定
条件１が満たされないものの（ＯＰ１０２：ＮＯ）、乗車希望者と運転者とが合流できないまま合流予定時刻＋αになると（ＯＰ１０８：ＹＥＳ）、乗車予約がキャンセルされる（ＯＰ１０９）。
【００８７】
また、例えば、時刻ｔ１以降に、ユーザ端末２００との通信が電波環境等の理由で途絶した場合でも、時間長Ｔ１以内に通信が復帰する場合には、バッテリ切れ判定条件１が満たされず（ＯＰ１０２：ＮＯ）、ユーザ端末２００との通信が途絶したからといってすぐに乗車予約はキャンセルされない。
【００８８】
第１実施形態では、センタサーバ３００は、乗車予約の合流予定時刻から所定時間前の時刻以降に、当該乗車予約のユーザ端末２００の電池残量不足による通信途絶の可能性が検出されると、当該乗車予約をキャンセルする。これによって、当該乗車予約の運転者は、合流予定地点に向かわずに済み、無駄な移動を行わなくてよくなり、運転者にかかる負担を軽減することができる。また、乗車希望者は、ユーザ端末２００の電池残量不足による動作停止が発生した場合には、乗車予約は自動的にキャンセルされるので、乗車予約のキャンセルにかかる処理の手間を省くことができ、さらに、乗車予約の相手の運転者との合流に関して余計な心配をせずにすむ。これによって、乗車予約の合流にかかるトラブルを回避することができる。
【００８９】
＜第２実施形態＞
第２実施形態では、センタサーバ３００は、合流支援処理として、乗車予約の合流予定時刻から所定時間前の時刻以降に、当該乗車予約のユーザ端末２００の電池残量不足による通信途絶の可能性が検出された場合には、合流予定地点の変更を行う。乗車希望者は車両による移動を希望しているので、ユーザ端末２００のバッテリ切れが発生した場合でも、乗車予約の履行を希望することが多い。したがって、第２実施形態では、ユーザ端末２００の電池残量不足による動作停止が発生した場合でも、乗車予約の運転者と乗車希望者とが合流できるように支援を行う。なお、第２実施形態において、第１実施形態と重複する説明は省略される。第２実施形態では、ライドシェアサービス提供システム１のシステム構成、車載装置１００、ユーザ端末２００、センタサーバ３００のハードウェア構成、センタサーバ３００の機能構成は、第１実施形態と同様である。
【００９０】
図６は、第２実施形態に係るセンタサーバ３００の合流支援処理のフローチャートの一例である。第２実施形態では、センタサーバ３００の予約処理部３１は、図６に示される合流支援処理を行う。図６に示される処理は、例えば、予約情報ＤＢ  ３６に保持される乗車予約情報それぞれについて、所定の周期で繰り返し実行される。
【００９１】
ＯＰ２０１では、予約処理部３１は、対象の乗車予約情報について、合流予定時刻から所定時間前の時刻になったか否かを判定する。合流予定時刻から所定時間前の時刻になった場合には（ＯＰ２０１：ＹＥＳ）、処理がＯＰ２０２に進む。合流予定時刻から所定時間前の時刻にまだなっていない場合には（ＯＰ２０１：ＮＯ）、図６に示される処理が終了し、所定の周期後に図６に示される処理が再度開始される。
【００９２】
ＯＰ２０２では、予約処理部３１は、バッテリ切れ判定条件１が満たされるか否かを判定する。バッテリ切れ判定条件１が満たされる場合には（ＯＰ２０２：ＹＥＳ）、処理がＯＰ２０３に進む。バッテリ切れ判定条件１が満たされていない場合には（ＯＰ２０２：ＮＯ）、その後、図５のＯＰ１０５〜ＯＰ１０９と同様の処理が行われる。ただし、ＯＰ１０８において否定判定された場合には、処理がＯＰ２０２に進む。ＯＰ２０２の肯定判定は、「第１の無線通信端末について電池残量不足による通信途絶の可能性を検出する」こと、「第１の無線通信端末との通信が第１の時間長以上継続して途絶することを検出すること」の一例である。
【００９３】
ＯＰ２０３では、予約処理部３１は、対象の乗車予約情報の合流予定地点を変更する。変更後の合流予定地点は、例えば、予めユーザ端末２００の電池残量不足による動作停止の際の合流地点候補として乗車希望者によって指定された地点、ユーザ端末２００から最後に受信された位置情報が示す地点、ユーザ端末２００の位置情報の履歴から推測される合流予定時刻における乗車希望者の位置、変更前と同じ合流予定地点のうちのいずれかに決定される。
【００９４】
上記の地点のいずれが変更後の合流予定地点に決定されるかは、例えば、乗車予約要求の受付時の乗車希望者との事前の合意内容によって決まる。また、例えば、乗車予約要求の受付時の乗車希望者との事前の合意がない場合には、ユーザ端末２００から最後に受信された位置情報が示す地点、ユーザ端末２００の位置情報の履歴から推測される合流予定時刻における乗車希望者の位置、変更前と同じ合流予定地点のうちのいずれかに決定される。なお、予約処理部３１は、変更後の合流予定地点に応じて、合流予定時刻も変更してもよい。ＯＰ２０３の処理は、「合流予定に関する処理」、「合流予定の合流予定地点を前記第１のユーザの所在地となる可能性のある所定の地点に変更すること」の一例である。
【００９５】
ＯＰ２０４では、予約処理部３１は、対象の乗車予約情報の運転者の車載装置１００へ、端末通信部３３を通じて、合流予定地点の変更と、ＯＰ２０３で決定された合流予定地点とを通知する。
【００９６】
ＯＰ２０５では、予約処理部３１は、端末通信部３３を通じて、運転者の車載装置１００から合流完了通知を受信したか否かを判定する。車載装置１００から合流完了通知が受信された場合には（ＯＰ２０５：ＹＥＳ）、処理がＯＰ２０６に進む。車載装置１００から合流完了通知が受信されていない場合には（ＯＰ２０５：ＮＯ）、処理がＯＰ２０７に進む。
【００９７】
ＯＰ２０６では、予約処理部３１は、合流予定地点を変更したことによって、変更前の合流予定地点までの移動と、変更前の合流予定地点から降車希望場所までの移動とについて、運転者の車両１０の走行距離及び／又は走行時間が増加するか否かを判定する。運転者の車両１０の走行距離及び／又は走行時間の算出は、周知の技術のいずれが用いられてもよい。
【００９８】
運転者の車両１０の走行距離及び／又は走行時間に増加分がある場合には（ＯＰ２０６：ＹＥＳ）、処理がＯＰ２０９に進み、ＯＰ２０９では、予約処理部３１は、走行距離及び／又は走行時間の増加分に応じたインセンティブを運転者に付与する。運転者に付与されるインセンティブは、例えば、ライドシェアサービス提供システム１において、当該運転者が乗車希望者としてサービスを受ける場合に使用可能なポイント、クーポン等である。ただし、これに限定されない。その後、対象の乗車予約情報について図６に示される処理が終了し、以降、当該乗車予約情報について図６に示される処理は実行されない。
【００９９】
運転者の車両１０の走行距離及び／又は走行時間に増加分がない場合には（ＯＰ２０６：ＮＯ）、対象の乗車予約情報について図６に示される処理が終了し、以降、当該乗車予約情報について図６に示される処理は実行されない。
【０１００】
ＯＰ２０７では、予約処理部３１は、合流予定時刻＋αの時刻が過ぎたか否かを判定する。合流予定時刻＋αの時刻が経過した場合には（ＯＰ２０７：ＹＥＳ）、処理がＯＰ２０８に進み、ＯＰ２０８では、予約処理部３１は、対象の乗車予約をキャンセルする。その後、ＯＰ２０９において、対象の乗車予約は履行されなかったものの、運転者の車両１
０による移動は発生したため、予約処理部３１は、運転者に所定のインセンティブを付与する。その後、図６に示される処理が終了し、以降、当該乗車予約情報について図６に示される処理は実行されない。合流予定時刻＋αの時刻になっていない場合には（ＯＰ２０７：ＮＯ）、処理がＯＰ２０５に進む。ＯＰ２０９の処理は、「前記増加分に応じて前記運転者に所定のインセンティブを付与する」ことの一例である。
【０１０１】
なお、図６に示される合流支援処理は一例であって、センタサーバ３００の合流支援処理は図６に示される処理に限定されない。
【０１０２】
＜第２実施形態の作用効果＞
第２実施形態では、センタサーバ３００は、乗車予約の合流予定時刻から所定時間前の時刻以降に、当該乗車予約のユーザ端末２００の電池残量不足による通信途絶の可能性が検出されると、当該乗車予約の合流予定地点を変更する。変更後の合流予定地点は、乗車希望者の所在地である可能性の高い地点に決定される。例えば、乗車希望者の所在地である可能性の高い地点は、通信途絶が検出される直前に受信されたユーザ端末２００の位置情報が示す地点、ユーザ端末２００の位置情報から推測される合流予定時刻における乗車希望者位置等である。これによって、乗車予約の運転者と乗車希望者とが合流できる可能性を高くすることができ、ユーザ端末２００のバッテリ切れ等によって乗車予約の運転者と合流できないというトラブルを回避することができる。
【０１０３】
また、第２実施形態では、乗車予約の合流予定地点が変更されたことによって、運転者の車両１０の走行距離及び／又は走行時間が増加する場合には、運転者に対して所定のインセンティブが与えられる。これによって、車両１０の走行距離及び／又は走行時間の増加に対する運転者の不満を軽減したり、ライドシェアサービスに車両１０の運転を提供することへのモチベーションの低減を抑制したりすることができる。
【０１０４】
＜第３実施形態＞
第３実施形態では、センタサーバ３００は、合流支援処理として、乗車予約の合流予定時刻から所定時間前の時刻以降に、当該乗車予約のユーザ端末２００の電池残量が所定の閾値未満であることを検出した場合には、合流予定地点の変更を行い、ユーザ端末２００に変更後の合流予定地点を通知する。これによって、乗車希望者のユーザ端末２００が電池残量不足による動作停止になる前に、運転者と乗車希望者とが合流できる可能性を向上させる。なお、第３実施形態においても、第１実施形態及び第２実施形態と重複する説明は省略される。
【０１０５】
図７は、第３実施形態に係るセンタサーバ３００の合流支援処理のフローチャートの一例である。第３実施形態では、センタサーバ３００の予約処理部３１は、図７に示される合流支援処理を行う。図７に示される処理は、例えば、予約情報ＤＢ  ３６に保持される乗車予約情報それぞれについて、所定の周期で繰り返し実行される。図６に示されるセンタサーバ３００の合流支援処理のフローチャートと同様の処理には、同じ符号が付されている。
【０１０６】
予約処理部３１は、対象の乗車予約情報について、合流予定時刻から所定時間前の時刻になると（ＯＰ２０１：ＹＥＳ）、ＯＰ３０２の処理を行う。
【０１０７】
ＯＰ３０２では、予約処理部３１は、乗車希望者のユーザ端末２００の電池残量が所定の閾値未満であるか否かを判定する。閾値は、例えば、所定時間内にユーザ端末２００が電池残量不足で動作停止することが予想される値に設定される。より具体的には、例えば、閾値は、電池残量が満充電状態の電力量の数％〜１０％の範囲で設定される。
【０１０８】
乗車希望者のユーザ端末２００の電池残量が所定の閾値未満である場合には（ＯＰ３０２：ＹＥＳ）、処理がＯＰ３０３に進む。乗車希望者のユーザ端末２００の電池残量が所定の閾値以上である場合には（ＯＰ３０２：ＮＯ）、その後、図５のＯＰ１０５〜ＯＰ１０９と同様の処理が行われる。ただし、ＯＰ１０８において否定判定された場合には、処理はＯＰ３０２に進む。ＯＰ３０２の肯定判定は、「電池残量不足による通信途絶の可能性を検出する」こと、「前記第１の無線通信端末の電池残量が第１の閾値未満であることを検出すること」の一例である。所定の閾値は、「第１の閾値」の一例である。
【０１０９】
ＯＰ３０３では、予約処理部３１は、対象の乗車予約情報の合流予定地点を変更する。変更後の合流予定地点は、例えば、ユーザ端末２００及び車載装置１００の位置情報、現在時刻等に基づいて、ユーザ端末２００がバッテリ切れする前に乗車希望者と運転者とが合流できるように決定される。例えば、予約処理部３１は、変更後の合流予定地点を、ユーザ端末２００の最新の位置情報が示す地点に決定する。また、例えば、合流予定時刻までにユーザ端末２００が電池残量不足により動作停止することが予想され、且つ、ユーザ端末２００と運転者の車載装置１００との距離が、ユーザ端末２００の動作停止までの残り時間内で車両１０が移動できる距離よりも長い場合には、予約処理部３１は、ユーザ端末２００の現在位置から車載装置１００の現在位置の方向に所定距離離れた地点を変更後の合流予定地点に決定する。なお、変更後の合流予定地点の決定方法は、これらに限定されない。なお、予約処理部３１は、変更後の合流予定地点に応じて、合流予定時刻も変更してもよい。ＯＰ３０３の処理は、「合流予定に関する処理」、「前記合流予定の合流予定地点を、前記第１の無線通信端末が電池残量不足によって動作停止する前に前記第１のユーザと前記運転者とが合流可能な所定の地点に変更」することの一例である。
【０１１０】
ＯＰ３０４では、予約処理部３１は、対象の乗車予約情報の運転者の車載装置１００と乗車希望者のユーザ端末２００とへ、端末通信部３３を通じて、合流予定地点の変更と、ＯＰ３０３で決定された合流予定地点とを通知する。ＯＰ３０４の処理は、「少なくとも前記運転者によって用いられる無線通信端末に変更後の合流予定地点を通知すること」の一例である。
【０１１１】
以降、図６に示されるセンタサーバ３００の合流支援処理のフローチャートと同様に、例えば、運転者の車載装置１００から合流完了通知を受信すると（ＯＰ２０５：ＹＥＳ）、運転者の車両１０の走行距離及び／又は走行時間の増加分について、運転者にインセンティブが与えられる（ＯＰ２０６：ＹＥＳ、ＯＰ２０９）。例えば、運転者の車載装置１００から合流完了通知を受信しないまま合流予定時刻＋αの時刻が経過すると（ＯＰ２０５：ＮＯ、ＯＰ２０７：ＹＥＳ）、対象の乗車予約がキャンセルされる（ＯＰ２０８）。
【０１１２】
なお、図７に示される合流支援処理は一例であって、センタサーバ３００の合流支援処理は図７に示される処理に限定されない。
【０１１３】
＜第３実施形態の作用効果＞
第３実施形態では、センタサーバ３００は、乗車予約の合流予定時刻から所定時間前の時刻以降に、当該乗車予約のユーザ端末２００の電池残量が所定の閾値よりも少ないことを検出すると、当該乗車予約の合流予定地点を変更する。変更後の合流予定地点は、例えば、ユーザ端末２００の電池残量不足による動作停止までに、乗車希望者と運転者とが合流できるような地点に設定される。これによって、乗車予約の運転者と乗車希望者とが、ユーザ端末２００が動作している間に合流できる可能性を高くすることができ、ユーザ端末２００のバッテリ切れ等によって乗車予約の運転者と合流できないというトラブルを回避することができる。
【０１１４】
＜第４実施形態＞
第４実施形態では、センタサーバ３００は、合流支援処理として、乗車希望者のユーザ端末２００の電池残量不足による通信途絶の状態に応じて、段階的に処理を行う。具体的には、センタサーバ３００は、時間長Ｔ２（Ｔ１＞Ｔ２）以上継続してユーザ端末２００との通信が途絶したことを検出した場合には、合流予定地点の変更を行う。その後、ユーザ端末２００との通信が途絶したまま時間長Ｔ１以上が経過すると、センタサーバ３００は乗車予約のキャンセルを行う。時間長Ｔ２は、例えば、１分〜１０分の範囲で設定される。ただし、これに限られない。これによって、意図せず乗車予約がキャンセルされることを抑制しつつ、運転者と乗車希望者とが合流できる可能性を向上させる。なお、第４実施形態においても、第１〜３実施形態と重複する説明は省略される。
【０１１５】
図８は、第４実施形態に係るセンタサーバ３００の合流支援処理のフローチャートの一例である。第４実施形態では、センタサーバ３００の予約処理部３１は、図８に示される合流支援処理を行う。図８に示される処理は、例えば、予約情報ＤＢ  ３６に保持される乗車予約情報それぞれについて、所定の周期で繰り返し実行される。
【０１１６】
ＯＰ４０１では、予約処理部３１は、対象の乗車予約情報について、合流予定時刻から所定時間前の時刻になったか否かを判定する。合流予定時刻から所定時間前の時刻になった場合には（ＯＰ４０１：ＹＥＳ）、処理がＯＰ４０２に進む。合流予定時刻から所定時間前の時刻にまだなっていない場合には（ＯＰ４０１：ＮＯ）、図８に示される処理が終了する。
【０１１７】
ＯＰ４０２では、予約処理部３１は、バッテリ切れ判定条件２が満たされるか否かを判定する。バッテリ切れ判定条件２は、乗車希望者のユーザ端末２００の電池残量不足による通信の途絶の可能性を判定するための条件である。バッテリ切れ判定条件２は、例えば、時間長Ｔ２以上継続してユーザ端末２００から位置情報及び／又は電池残量に関する情報が受信されないこと、又は、時間長Ｔ２以上継続してユーザ端末２００とのセッションが切断することである。
【０１１８】
バッテリ切れ判定条件２が満たされる場合には（ＯＰ４０２：ＹＥＳ）、処理がＯＰ４０３に進む。バッテリ切れ判定条件２が満たされていない場合には（ＯＰ４０２：ＮＯ）、その後、図５のＯＰ１０５〜ＯＰ１０９と同様の処理が行われる。ただし、ＯＰ１０８において否定判定された場合には、処理はＯＰ４０２に進む。ＯＰ４０２の肯定判定は、「前記第１の時間長よりも短い第２の時間長以上継続して前記第１の無線通信端末との通信の途絶を検出」することの一例である。時間長Ｔ２は、「第２の時間長」の一例である。
【０１１９】
ＯＰ４０３では、予約処理部３１は、対象の乗車予約情報の合流予定地点を変更する。変更後の合流予定地点は、例えば、予めユーザ端末２００のバッテリ切れの際の合流地点候補として乗車希望者によって指定された地点、バッテリ切れ判定条件２が満たされることが判定された直前に、ユーザ端末２００から最後に受信された位置情報が示す地点、ユーザ端末２００の位置情報の履歴から推測される合流予定時刻における乗車希望者の位置、変更前と同じ合流予定地点のうちのいずれかに決定される。ＯＰ４０３の処理は、「前記合流予定の合流予定地点を前記第１のユーザの所在地となる可能性のある所定の地点に変更すること」の一例である。
【０１２０】
ＯＰ４０４では、予約処理部３１は、端末通信部３３を通じて、対象の乗車予約情報の運転者の車載装置１００へ、合流予定地点の変更と、ＯＰ４０３で決定された合流予定地点とを通知する。
【０１２１】
ＯＰ４０５では、予約処理部３１は、乗車希望者のユーザ端末２００との通信が復帰し
たか否かを判定する。例えば、予約処理部３１は、ユーザ端末２００から位置情報又は／及び電池残量に関する情報を所定の周期で受信したこと、又はユーザ端末２００との通信セッションが回復されたことによって当該判定を行う。乗車希望者のユーザ端末２００との通信が復帰した場合には（ＯＰ４０５：ＹＥＳ）、その後、図５のＯＰ１０５〜ＯＰ１０９と同様の処理が行われる。ただし、ＯＰ１０８において否定判定された場合には、処理はＯＰ４０２に進む。乗車希望者のユーザ端末２００との通信が復帰していない場合には（ＯＰ４０５：ＮＯ）、処理がＯＰ４０６に進む。
【０１２２】
ＯＰ４０６では、予約処理部３１は、バッテリ切れ判定条件１が満たされるか否かを判定する。バッテリ切れ判定条件１が満たされる場合には（ＯＰ４０６：ＹＥＳ）、処理がＯＰ４０８に進み、ＯＰ４０８では、予約処理部３１は、乗車予約をキャンセルする。その後、対象の乗車予約情報について図８に示される処理が終了し、以降、当該乗車予約情報について図８に示される処理は行われない。バッテリ切れ判定条件１が満たされていない場合には（ＯＰ４０６：ＮＯ）、処理がＯＰ４０７に進む。
【０１２３】
ＯＰ４０７では、予約処理部３１は、合流予定時刻＋αの時刻が経過したか否かを判定する。合流予定時刻＋αの時刻が経過した場合には（ＯＰ４０７：ＹＥＳ）、処理がＯＰ４０８に進み、ＯＰ４０８では、予約処理部３１は、乗車予約をキャンセルする。その後、対象の乗車予約情報について図８に示される処理が終了し、以降、当該乗車予約情報について図８に示される処理は行われない。合流予定時刻＋αの時刻が経過していない場合には（ＯＰ４０７：ＮＯ）、処理がＯＰ４０５に進む。
【０１２４】
ＯＰ４０９では、ＯＰ１０５からＯＰ１０９の処理の終了が、合流完了通知の受信によるものであるか否かを判定する。ＯＰ１０５からＯＰ１０９の処理の終了が、合流完了通知の受信によるものである場合には（ＯＰ４０９：ＹＥＳ）、処理がＯＰ４１０に進む。ＯＰ１０５からＯＰ１０９の処理の終了が、合流完了通知の受信によるものでない場合には（ＯＰ４１０：ＮＯ）、対象の乗車予約情報について図８に示される処理が終了し、以降、当該乗車予約情報について図８に示される処理は行われない。
【０１２５】
ＯＰ４１０では、予約処理部３１は、当初予定から運転者の車両１０の走行距離及び／又は走行時間が増加するか否かを判定する。運転者の車両１０の走行距離及び／又は走行時間に増加分がある場合には（ＯＰ４１０：ＹＥＳ）、処理がＯＰ４１１に進み、ＯＰ４１１では、予約処理部３１は、走行距離及び／又は走行時間の増加分に応じたインセンティブを運転者に付与する。その後、対象の乗車予約情報について図８に示される処理が終了し、以降、当該乗車予約情報について図８に示される処理は行われない。
【０１２６】
運転者の車両１０の走行距離及び／又は走行時間に増加分がない場合には（ＯＰ４１０：ＮＯ）、対象の乗車予約情報について図８に示される処理が終了し、以降、当該乗車予約情報について図８に示される処理は行われない。なお、図８に示される合流支援処理は一例であって、センタサーバ３００の合流支援処理は図８に示される処理に限定されない。
【０１２７】
＜第４実施形態の作用効果＞
図８に示される例において、合流予定時刻から所定時間前の時刻を時刻ｔ１とする。合流予定時刻＋αから時間長Ｔ１前の時刻を時刻ｔ２とする。図８に示される例では、例えば、時刻ｔ１から時刻ｔ２までの間に、乗車希望者のユーザ端末２００が電池残量不足により動作停止し、それが時間長Ｔ２以上継続する場合には（ＯＰ４０２：ＹＥＳ）、合流予定地点が変更される（ＯＰ４０３）。
【０１２８】
第４実施形態では、センタサーバ３００は、ユーザ端末２００の電池残量不足による通
信途絶が時間長Ｔ２以上継続した場合に合流予定地点を変更し、その後時間長Ｔ１以上継続した場合には乗車予約をキャンセルする。これによって、例えば、ユーザ端末２００との通信が途絶してから時間長Ｔ２以上時間長Ｔ１未満の間に、合流予定時刻となり、運転者が乗車希望者の所在地となる可能性のある所定の地点に移動することで、乗車希望者と運転者とが合流する可能性を向上させることができる。また、ユーザ端末２００の復帰が見込めない場合には、乗車予約がキャンセルされるので、運転者の負担を軽減することができる。
【０１２９】
なお、時間長Ｔ１及び時間長Ｔ２は、固定値であってもよいし、合流予定時刻までの残り時間に応じて可変に設定されてもよい。
【０１３０】
＜第５実施形態＞
第５実施形態では、センタサーバ３００は、合流支援処理において、乗車予約の合流予定時刻から所定時間前の時刻以降に、当該乗車予約のユーザ端末２００の電池残量が所定の閾値未満であることを検出した場合には、ユーザ端末２００へ、電池残量不足による動作停止時の合流予定地点について乗車希望者に対して問合せを行う。
【０１３１】
図９は、第５実施形態に係るセンタサーバ３００の合流支援処理のフローチャートの一例である。第５実施形態では、センタサーバ３００の予約処理部３１は、図９に示される合流支援処理を行う。図９に示される処理は、例えば、予約情報ＤＢ  ３６に保持される乗車予約情報それぞれについて、所定の周期で繰り返し実行される。
【０１３２】
ＯＰ５０１では、予約処理部３１は、対象の乗車予約情報について、合流予定時刻から所定時間前の時刻になったか否かを判定する。合流予定時刻から所定時間前の時刻になった場合には（ＯＰ５０１：ＹＥＳ）、処理がＯＰ５０２に進む。合流予定時刻から所定時間前の時刻にまだなっていない場合には（ＯＰ５０１：ＮＯ）、図９に示される処理が終了する。
【０１３３】
ＯＰ５０２では、予約処理部３１は、乗車希望者のユーザ端末２００の電池残量が所定の閾値未満であるか否かを判定する。閾値は、例えば、所定時間内にユーザ端末２００がバッテリ切れで動作停止することが予想される値に設定される。より具体的には、例えば、閾値は、電池残量が満充電状態の電力量の数％〜１０％の範囲で設定される。また、ＯＰ５０２において用いられる電池残量の閾値は、例えば、図７のＯＰ３０２において用いられる電池残量の閾値と同じ値であってもよいし、より大きい値であってもよい。
【０１３４】
乗車希望者のユーザ端末２００の電池残量が所定の閾値未満である場合には（ＯＰ５０２：ＹＥＳ）、処理がＯＰ５０３に進む。乗車希望者のユーザ端末２００の電池残量が所定の閾値以上である場合には（ＯＰ５０２：ＮＯ）、その後、図５のＯＰ１０５〜ＯＰ１０９と同様の処理が行われる。ただし、ＯＰ１０８において否定判定された場合には、処理はＯＰ５０２に進む。ＯＰ５０２の肯定判定は、「前記第１の無線通信端末の電池残量が第２の閾値未満であることを検出すること」の一例である。所定の閾値は、「第２の閾値」の一例である。
【０１３５】
ＯＰ５０３では、予約処理部３１は、端末通信部３３を通じて、乗車希望者のユーザ端末２００へ、電池残量不足による動作停止時の対応について問い合わせる。当該問合せとともに、ユーザ端末２００へは電池残量不足による動作停止時の対応の選択肢も送信される。電池残量不足による動作停止時の対応の選択肢には、例えば、乗車予約のキャンセル（第１実施形態）、合流予定地点の変更（第２実施形態又は第４実施形態）、合流予定地点を変更しない、等があり、以下の説明では上記内容の選択肢がユーザ端末２００へ送信されることを前提とする。ただし、これに限られない。ＯＰ５０３の処理は、「前記第１
の無線通信端末に、前記合流予定に関する処理の選択肢を送信すること」の一例である。
【０１３６】
ＯＰ５０４では、予約処理部３１は、ユーザ端末２００からの応答とともに、乗車予約のキャンセルを示す選択結果が受信されたか否かを判定する。乗車予約のキャンセルを示す選択結果が受信された場合には（ＯＰ５０４：ＹＥＳ）、処理が図５のＯＰ１０２に進み、以降、図５において説明された処理が実行される。乗車予約のキャンセルを示す選択結果が受信されていない場合には（ＯＰ５０４：ＮＯ）、処理がＯＰ５０５に進む。
【０１３７】
ＯＰ５０５では、予約処理部３１は、ユーザ端末２００からの応答とともに、合流予定地点の変更を示す選択結果が受信されたか否かを判定する。合流予定地点の変更を示す選択結果が受信された場合には（ＯＰ５０５：ＹＥＳ）、処理が図６のＯＰ２０２、図８のＯＰ４０２のいずれか一方に進み、以降、図６又は図８において説明された処理が実行される。どちらに進むかは、例えば、実施の形態による。合流予定地点の変更を示す選択結果が受信されていない場合（ＯＰ５０５：ＮＯ）、すなわち、合流予定地点を変更しないことを示す選択結果受信されている場合には、処理がＯＰ５０６に進む。
【０１３８】
合流予定地点を変更しないことが選択された場合には、例えば、ユーザ端末２００が電池残量不足により動作停止しても、合流地点の変更も乗車予約のキャンセルもない。そのため、少なくとも車載装置１００から合流完了通知が受信されないまま（ＯＰ５０６：ＮＯ）、合流予定時刻＋αの時刻が経過した場合には（ＯＰ５０７：ＹＥＳ）、予約処理部３１は、乗車予約をキャンセルする（ＯＰ５０８）。
【０１３９】
＜第５実施形態の作用効果＞
第５実施形態では、センタサーバ３００は、ユーザ端末２００の電池残量が少なくなった場合には、電池残量不足による動作停止に対する対応をユーザ端末２００へ問い合わせる。これによって、乗車希望者は、例えば、ユーザ端末２００が電池残量不足によって動作停止した場合に、センタサーバ３００側でどのような対応がとられるのかを認識することができる。したがって、例えば、ユーザ端末２００が電池残量不足によって動作停止した場合でも、乗車希望者と運転者とが合流できる可能性が向上する。
【０１４０】
＜第６実施形態＞
第６実施形態では、センタサーバ３００は、１台の車両１０について、乗車予約の乗車期間が重複している複数の乗車希望者のユーザ端末２００のうち、電池残量が所定の閾値未満であるユーザ端末２００が存在するか否かを判定する。センタサーバ３００は、電池残量が所定の閾値未満であるユーザ端末２００が存在する場合には、当該ユーザ端末２００が動作している間に乗車希望者と車両１０の運転者とが合流できるように、合流順を変更する。第６実施形態では、第１実施形態〜第５実施形態と重複する説明は省略される。
【０１４１】
電池残量の少ないユーザ端末２００の乗車希望者を優先的に運転者と合流させるように合流順を変更する、上記の処理を、合流支援処理２と称する。また、乗車予約の乗車期間が重複している乗車希望者同士を同乗者と称する。
【０１４２】
第６実施形態では、センタサーバ３００は、例えば、合流支援処理２のみを実行してもよいし、第１実施形態から第５実施形態における合流支援処理のいずれかと並行して実行してもよい。
【０１４３】
図１０は、第６実施形態に係るセンタサーバ３００の合流支援処理２のフローチャートの一例である。図１０に示される処理は、例えば、予約情報ＤＢ  ３６に保持される乗車予約情報それぞれについて、所定の周期で繰り返し実行される。
【０１４４】
ＯＰ６０１では、予約処理部３１は、対象の乗車予約情報について、合流予定時刻から所定時間前の時刻になったか否かを判定する。合流予定時刻から所定時間前の時刻になった場合には（ＯＰ６０１：ＹＥＳ）、処理がＯＰ６０２に進む。対象の乗車予約情報の合流予定時刻から所定時間前の時刻にまだなっていない場合には（ＯＰ６０１：ＮＯ）、図１０に示される処理が終了する。
【０１４５】
ＯＰ６０２では、予約処理部３１は、対象の乗車予約情報の乗車希望者に対して、同乗者が存在するか否かを判定する。例えば、同乗者が存在するか否かの判定は、予約情報ＤＢ  ３６において、対象の乗車予約情報に同乗者有無フィールドの値に基づいて行われる。同乗者が存在する場合には（ＯＰ６０２：ＹＥＳ）、処理がＯＰ６０３に進む。同乗者が存在しない場合には（ＯＰ６０２：ＮＯ）、対象の乗車予約情報について図１０に示される処理が終了する。
【０１４６】
ＯＰ６０３では、予約処理部３１は、対象の乗車予約情報の同乗者のユーザ端末２００から電池残量に関する情報を取得する。対象の乗車予約情報の同乗者は、例えば、対象の乗車予約情報と運転者ＩＤが一致し、且つ、合流予定時刻が対象の乗車予約情報の合流予定時刻から所定時間内である乗車予約情報の乗車希望者である。所定時間は、例えば、対象の乗車予約情報の到着予定時刻を過ぎない範囲で、数分から１時間程度の範囲で設定される。ただし、ＯＰ６０３において同乗者として抽出されるユーザ端末２００は、これに限定されない。例えば、対象の乗車予約情報と運転者ＩＤが一致し、且つ、乗車期間が重複する乗車予約情報の乗車希望者のユーザ端末２００であってもよい。乗車期間は、例えば、合流予定時刻から到着希望時間までの期間である。
【０１４７】
ユーザ端末２００の電池残量に関する情報は、例えば、ユーザ端末２００に問合せ要求を送信することで取得される。なお、対象の乗車予約情報の乗車希望者のユーザ端末２００からは、例えば、合流予定時刻から所定時間前の時刻になることで、位置情報と電池残量に関する情報との所定の周期でのセンタサーバ３００への送信が開始されている。
【０１４８】
ＯＰ６０４では、予約処理部３１は、乗車希望者及び同乗者のユーザ端末２００のうち、電池残量が所定の閾値未満であるユーザ端末２００が存在するか否かを判定する。電池残量が所定の閾値未満である同乗者のユーザ端末２００が存在する場合には（ＯＰ６０４：ＹＥＳ）、処理がＯＰ６０５に進む。電池残量が所定の閾値未満である同乗者のユーザ端末２００が存在しない場合には（ＯＰ６０４：ＮＯ）、処理がＯＰ６０８に進む。電池残量が所定の閾値未満であるユーザ端末２００、当該ユーザ端末２００の乗車希望者又は同乗者は、それぞれ、「第１の無線通信端末」、「第１のユーザ」の一例である。また、電池残量が所定の閾値未満でないユーザ端末２００の乗車希望者又は同乗者は、「第２のユーザ」の一例である。
【０１４９】
ＯＰ６０５では、予約処理部３１は、電池残量が少ないユーザ端末２００の乗車希望者又は同乗者と運転者との合流を優先するように、合流順を変更する。合流順の変更方法は、如何様であってもよい。例えば、電池残量が少ないユーザ端末２００の乗車希望者又は同乗者の合流順番を一番目にし、他は繰り下げるように変更されてもよい。例えば、最も移動距離が短くなるように、且つ、電池残量が少ないユーザ端末２００の乗車希望者又は同乗者の合流順番が現在よりも早くなるように、合流順を変更してもよい。ＯＰ６０５の処理は、「前記第１のユーザの方が先になるように前記合流順を変更する」ことの一例である。
【０１５０】
ＯＰ６０６では、予約処理部３１は、対象の乗車予約情報の、運転者の車載装置１００と、乗車希望者及び同乗者のユーザ端末２００とに、合流順の変更を通知する。なお、合流順とともに合流予定時刻が変更となる場合には、合流予定時刻も通知される。
【０１５１】
ＯＰ６０７では、予約処理部３１は、対象の乗車予約情報の合流予定時刻が変更になったか否かを判定する。なお、ＯＰ６０５の合流順の変更によって対象の乗車予約情報の合流予定時刻が変更になる場合には、当初の合流予定時刻よりも遅い時刻に変更されることになる。そのため、対象の乗車予約情報の合流予定時刻が変更になった場合には（ＯＰ６０７：ＹＥＳ）、図１０に示される処理が終了し、新たな合流予定時刻よりも所定時間前の時刻なると、対象の乗車予約情報について再度図１０に示される処理が開始される。対象の乗車予約情報の合流予定時刻が変更になっていない場合には（ＯＰ６０７：ＮＯ）、処理がＯＰ６０８に進む。
【０１５２】
ＯＰ６０８では、予約処理部３１は、対象の乗車予約情報について、少なくとも運転者の車載装置１００から合流完了通知を受信したか否かを判定する。合流完了通知が受信された場合には（ＯＰ６０８：ＹＥＳ）、対象の乗車予約情報について図１０に示される処理が終了し、以降は対象の乗車予約情報については図１０の処理は行われない。合流完了通知が受信されていない場合には（ＯＰ６０８：ＮＯ）、処理がＯＰ６０４に進む。なお、合流順の変更によって、車両１０の走行距離及び／又は走行時間に増加分が発生した場合には、当該増加分に応じて運転者にインセンティブが与えられてもよい。
【０１５３】
＜第６実施形態の作用効果＞
第６実施形態では、１台の車両１０に対して乗車期間が重複する乗車希望者が複数存在する場合には、電池残量が少ないユーザ端末２００の乗車希望者が優先的に合流するように合流順が変更される。これによって、例えば、合流予定時刻よりも早い時点で電池残量が少なくなってしまった場合でも、運転者と合流できる可能性が向上する。
【０１５４】
＜その他の実施形態＞
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
【０１５５】
第１実施形態及び変形例では、運転者が利用する端末は車載装置１００として説明されたが、これに限定されず、運転者が利用する端末はスマートフォン、タブレット端末等のユーザ端末２００のような無線通信端末であってもよい。
【０１５６】
また、第１〜５実施形態では、乗車希望者のユーザ端末２００の電池残量不足について説明されたが、運転者の車載装置１００の電池残量不足についても同様の処理を適用することができる。ただし、運転者の車載装置１００の電池残量不足による走行距離又は／及び時間の増加については、運転者にインセンティブは付与されない。
【０１５７】
なお、第１実施形態〜第６実施形態のいずれにおいても、図５〜図１０に示される合流支援処理は、対象の乗車予約情報の合流予定時刻から所定時間前の時刻になることを契機に開始されるが、これに限定されない。第１実施形態〜第６実施形態のいずれにおいても、合流支援処理は、例えば、乗車予約情報が登録されたことを契機に開始されてもよい。
【０１５８】
本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
【０１５９】
また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。
【０１６０】
本発明は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤディスク、ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。
【符号の説明】
【０１６１】
１        ：ライドシェアサービス提供システム
１０      ：車両
３１      ：予約処理部
３２      ：マッチング処理部
３３      ：端末通信部
１００    ：車載装置
３００    ：センタサーバ
３０１    ：プロセッサ
３０２    ：主記憶部
３０３    ：補助記憶部
３０４    ：通信部
【図１】
2019220002.tif 000003
【図２】
2019220002.tif 000004
【図３】
2019220002.tif 000005
【図４】
2019220002.tif 000006
【図５】
2019220002.tif 000007
【図６】
2019220002.tif 000008
【図７】
2019220002.tif 000009
【図８】
2019220002.tif 000010
【図９】
2019220002.tif 000011
【図１０】
2019220002.tif 000012