JP2018185693A - ライドシェア管理装置、ライドシェア管理方法、およびプログラム - Google Patents

Abstract

【課題】利便性を向上させることができるライドシェア管理装置、ライドシェア管理方法、およびプログラムを提供すること。
【解決手段】利用者の端末装置と通信する通信部と、少なくとも乗車希望地点と乗車希望時刻とを含む乗車条件が定義された、利用者の乗車リクエストを取得する取得部と、前記乗車リクエストに含まれる乗車条件に基づいて、配車可能な車両を検索し、車両の運行スケジュールを決定する運行管理部と、前記運行管理部による検索の結果を参照し、前記乗車希望時刻から第１所定時間が経過する時刻までに前記車両が前記乗車希望地点に到達しない場合、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信する施設案内部と、を備えるライドシェア管理装置。
【選択図】図１

Description

本発明は、ライドシェア管理装置、ライドシェア管理方法、およびプログラムに関する。

従来、複数の利用者が同一の共同車両を利用するための車両共同利用支援装置の発明が開示されている（特許文献１参照）。この装置は、利用者情報、及び道路情報を記憶するデータベース記憶部と、受信した各利用者携帯端末からの出発地指定情報及び到着地指定情報、並びにデータベース記憶部に記憶された道路情報、及び車両現在位置取得部からの現在位置情報に基づいて、出発地指定情報で示される出発地から到着地指定情報で示される到着地まで共同車両が走行する走行経路を推定する推定処理部と、推定した利用者ごとの走行経路に基づいて、複数の利用者が共同車両に乗車する相乗りの対象となる複数の利用者を検索し、相乗りを実施するときの待機地点までに共同車両が到達するときの到達しやすさ、及び待機しやすさに基づいて待機地点を複数選定すると共に、選定した複数の待機地点について優先順位付けをする選定処理部とを備える。

特開２００３−６２９４号公報

従来の技術において、利用者の希望する乗車時刻に乗車できない場合、待ち時間が発生することになるが、従来の技術では、待ち時間の過ごし方について考慮がなされておらず、利用者にとっての利便性が十分でなかった。

本発明は、このような事情を考慮してなされたものであり、利便性を向上させることができるライドシェア管理装置、ライドシェア管理方法、およびプログラムを提供することを目的の一つとする。

（１）：利用者の端末装置と通信する通信部と、少なくとも乗車希望地点と乗車希望時刻とを含む乗車条件が定義された、利用者の乗車リクエストを取得する取得部と、前記乗車リクエストに含まれる乗車条件に基づいて、配車可能な車両を検索し、車両の運行スケジュールを決定する運行管理部と、前記運行管理部による検索の結果を参照し、前記乗車希望時刻から第１所定時間が経過する時刻までに前記車両が前記乗車希望地点に到達しない場合、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信する施設案内部と、を備えるライドシェア管理装置である。

（２）：（１）において、前記施設案内部は、前記乗車希望時刻から前記第１所定時間が経過する時刻までに車両が前記乗車希望地点に到達せず、且つ前記乗車希望時刻から前記第１所定時間よりも長い第２所定時間が経過する時刻までに車両が前記乗車希望地点に到達する場合に、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信するものである。

（３）：（２）において、前記運行管理部は、前記乗車希望時刻から前記第２所定時間が経過する時刻までに前記乗車希望地点に到達可能な車両が発見されなかった場合、代替交通手段に関する情報を、前記通信部を用いて前記利用者の端末装置に送信するものである。

（４）：（１）から（３）のいずれかにおいて、前記運行管理部は、前記施設案内部により情報が送信された施設の利用に前記利用者が同意する旨の情報を、前記通信部が前記利用者の端末装置から受信した場合、前記車両の運行スケジュールを、前記施設において前記利用者を乗車させる運行スケジュールに変更するものである。

（５）：（１）から（４）のうちいずれかにおいて、前記施設の管理者が使用する施設端末に対して、前記利用者の端末装置に当該施設の情報を送信した回数に応じた報酬を要求する情報を送信するリワード要求部を更に備えるものである。

（６）：（１）から（５）のうちいずれかにおいて、前記施設の管理者が使用する施設端末に対して、前記利用者の端末装置から、前記利用者が当該施設を利用することに同意する旨の情報が得られた回数に応じた報酬を要求する情報を送信するリワード要求部を更に備えるものである。

（７）：（１）から（６）のうちいずれかにおいて、前記施設の管理者が使用する施設端末に対して、前記利用者が施設において支払を行った回数または支払金額に応じた報酬を要求する情報を送信するリワード要求部を更に備えるものである。

（８）：（１）から（７）のうちいずれかにおいて、前記車両は、自動運転車両であるものである。

（９）：利用者の端末装置と通信する通信部を備える装置が、少なくとも乗車希望地点と乗車希望時刻とを含む乗車条件が定義された、利用者の乗車リクエストを取得し、前記乗車リクエストに含まれる乗車条件に基づいて、配車可能な車両を検索し、車両の運行スケジュールを決定し、前記検索の結果を参照し、前記乗車希望時刻から第１所定時間が経過する時刻までに前記車両が前記乗車希望地点に到達しない場合、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信する、ライドシェア管理方法である。

（１０）：利用者の端末装置と通信する通信部を備える装置のコンピュータに、少なくとも乗車希望地点と乗車希望時刻とを含む乗車条件が定義された、利用者の乗車リクエストを取得させ、前記乗車リクエストに含まれる乗車条件に基づいて、配車可能な車両を検索し、車両の運行スケジュールを決定させ、前記検索の結果を参照させ、前記乗車希望時刻から第１所定時間が経過する時刻までに前記車両が前記乗車希望地点に到達しない場合、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信させる、プログラムである。

（１）、（９）、（１０）によれば、利用者が車両の待ち時間を有意義に使うことができるため、利便性を向上させることができる。

（２）によれば、長期の待ち時間が生じる場合には情報提供を控えることで、適度なサービスを提供することができる。

（３）によれば、長期の待ち時間が生じる場合には代替交通手段を勧めることで、より現実的なサービスを提供することができる。

（４）によれば、利用者が施設から出た後に、スムーズに乗車することができる。

（５）〜（８）によれば、スムーズなシステム運営を実現することができる。

ライドシェア管理装置３００を含むライドシェアシステム１の構成図である。 車両２００の構成図である。 自動運転の処理過程について説明するための図である。 乗車条件情報３８４の内容の一例を示す図である。 地図情報３８６に含まれる施設情報の内容の一例を示す図である。 運行スケジュール情報３８８の内容の一例を示す図である。 ライドシェア管理装置３００により実行される処理の流れの一例を示すフローチャートである。 ライドシェア管理装置３００により実行される処理の流れの一例を示すフローチャートである。 端末装置１００において表示される画面ＩＭ１の一例を示す図である。 画面ＩＭ２の一例を示す図である。 画面ＩＭ３の一例を示す図である。 画面ＩＭ４の一例を示す図である。 画面ＩＭ５の一例を示す図である。 リワード用集計情報３９２の内容の一例を示す図である。

以下、図面を参照し、本発明のライドシェア管理装置、ライドシェア管理方法、およびプログラムの実施形態について説明する。ライドシェア管理装置は、複数の利用者によって一つ以上の車両を共同で利用すること（ライドシェア）を支援するための装置である。ライドシェアに利用される車両は、例えば、基本的には運転操作を必要としない自動運転車両である。以下、自動運転車両がライドシェアに用いられるものとして説明するが、手動運転車両が用いられても構わない。

ライドシェア管理装置は、利用者の端末装置から通信によって乗車リクエストを取得すると、その乗車リクエストにおいて定義された乗車条件に合致する車両（配車可能な車両）を検索する。通信には、データ通信と、音声通信すなわち電話との双方が含まれてよい。

更に、ライドシェア管理装置は、乗車条件に合致する車両が発見されない場合、待ち時間の過ごし方について案内情報を利用者に提供する。これによって、利用者にとっての利便性を向上させることができる。

［全体構成］
図１は、ライドシェア管理装置３００を含むライドシェアシステム１の構成図である。ライドシェアシステム１は、一以上の利用者Ｕにより使用される一以上の端末装置１００と、一以上の車両２００と、ライドシェア管理装置３００と、一以上の施設端末４００とを備える。これらの構成要素は、ネットワークＮＷを介して互いに通信可能である。ネットワークＮＷは、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、公衆回線、プロバイダ装置、専用回線、無線基地局などを含む。なお、「利用者Ｕにより使用される」とは、ネットカフェの端末装置など、不特定多数によって使用され得る端末装置が、利用者Ｕにより一時的に使用されることを含んでよい。

［端末装置］
端末装置１００は、例えば、スマートフォンやタブレット端末、パーソナルコンピュータなどである。端末装置１００では、ライドシェアシステムを利用するためのアプリケーションプログラム、或いはブラウザなどが起動し、以下に説明するサービスをサポートする。以下の説明では端末装置１００がスマートフォンであり、アプリケーションプログラム（ライドシェアアプリ）が起動していることを前提とする。ライドシェアアプリは、利用者Ｕの操作に応じてライドシェア管理装置３００と通信し、利用者Ｕのリクエストをライドシェア管理装置３００に送信したり、ライドシェア管理装置３００から受信した情報に基づくプッシュ通知を行ったりする。

［車両］
車両２００は、例えば、複数の利用者Ｕが乗車可能な四輪以上の車輪を有する車両であるが、自動二輪車その他の車両であっても構わない。図２は、車両２００の構成図である。車両２００は、例えば、外界監視ユニット２１０と、通信装置２２０と、ナビゲーション装置２３０と、推奨車線決定装置２４０と、自動運転制御ユニット２５０と、駆動力出力装置２６０と、ブレーキ装置２６２と、ステアリング装置２６４とを備える。

外界監視ユニット２１０は、例えば、カメラやレーダ、ＬＩＤＡＲ（Light Detection and Ranging）、これらの出力に基づいてセンサフュージョン処理を行う物体認識装置などを含む。外界監視ユニット２１０は、車両２００の周辺に存在する物体の種類（特に、車両、歩行者、および自転車）を推定し、その位置や速度の情報と共に自動運転制御ユニット２５０に出力する。

通信装置２２０は、例えば、ネットワークＮＷに接続したり、他車両や歩行者の端末装置などと直接的に通信したりするための無線通信モジュールである。通信装置２２０は、Ｗｉ−Ｆｉ、ＤＳＲＣ（Dedicated Short Range Communications）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の通信規格に基づいて無線通信を行う。通信装置２２０として、用途に応じた複数のものが用意されてもよい。

ナビゲーション装置２３０は、例えば、ＨＭＩ（Human machine Interface）２３２と、ＧＮＳＳ（Global Navigation Satellite System）受信機２３４と、ナビ制御装置２３６とを備える。ＨＭＩ２３２は、例えば、タッチパネル式ディスプレイ装置やスピーカ、マイクなどを含む。ＧＮＳＳ受信機２３４は、ＧＮＳＳ衛星（例えばＧＰＳ衛星）から到来する電波に基づいて自機の位置（車両２００の位置）を測位する。ナビ制御装置２３６は、例えば、ＣＰＵ（Central Processing Unit）や各種記憶装置を備え、ナビゲーション装置２３０全体を制御する。記憶装置には、地図情報（ナビ地図）が格納されている。ナビ地図は、ノードとリンクで道路を表現した地図である。ナビ制御装置２３６は、ＧＮＳＳ受信機２３４によって測位された車両２００の位置から、ＨＭＩ２３２を用いて指定された目的地までの経路を、ナビ地図を参照して決定する。また、ナビ制御装置２３６は、車両２００の位置と目的地とを、通信装置２２０を用いてナビゲーションサーバ（不図示）に送信し、ナビゲーションサーバから返信された経路を取得してもよい。また、本実施例の場合、目的地までの経路は、ライドシェア管理装置３００によって指定される場合もある。なお、経路には、利用者を乗車または降車させるために停止する地点および到達目標時刻の情報が含まれてよい。ナビ制御装置２３６は、上記いずれかの方法で決定した経路の情報を推奨車線決定装置２４０に出力する。

推奨車線決定装置２４０は、例えば、ＭＰＵ（Micro Processing Unit）と各種記憶装置を備える。記憶装置には、ナビ地図よりも詳細な高精度地図情報が格納されている。高精度地図情報には、例えば、車線ごとの道路幅や勾配、曲率、信号の位置などの情報が含まれている。推奨車線決定装置２４０は、ナビゲーション装置２３０から入力された経路に沿って走行するために好ましい推奨車線を決定し、自動運転制御ユニット２５０に出力する。

自動運転制御ユニット２５０は、ＣＰＵやＭＰＵなどの一以上のプロセッサと各種記憶装置を備える。自動運転制御ユニット２５０は、推奨車線決定装置２４０により決定された推奨車線を走行することを原則として、外界監視ユニット２１０から位置や速度が入力された物体との接触を避けるように、車両２００を自動的に走行させる。自動運転制御ユニット２５０は、例えば、各種イベントを順次実行する。イベントには、一定速度で同じ走行車線を走行する定速走行イベント、前走車両に追従する追従走行イベント、車線変更イベント、合流イベント、分岐イベント、緊急停止イベント、料金所を通過するための料金所イベント、自動運転を終了して手動運転に切り替えるためのハンドオーバイベントなどがある。また、これらのイベントの実行中に、車両２００の周辺状況（周辺車両や歩行者の存在、道路工事による車線狭窄など）に基づいて、回避のための行動が計画される場合もある。

自動運転制御ユニット２５０は、車両２００が将来走行する目標軌道を生成する。目標軌道は、例えば、速度要素を含んでいる。例えば、目標軌道は、自車両Ｍの到達すべき地点（軌道点）を順に並べたものとして表現される。軌道点は、所定の走行距離ごとの自車両Ｍの到達すべき地点であり、それとは別に、所定のサンプリング時間（例えば０コンマ数［ｓｅｃ］程度）ごとの目標速度および目標加速度が、目標軌道の一部として生成される。また、軌道点は、所定のサンプリング時間ごとの、そのサンプリング時刻における自車両Ｍの到達すべき位置であってもよい。この場合、目標速度や目標加速度の情報は軌道点の間隔で表現される。

図３は、自動運転の処理過程について説明するための図である。まず、上図に示すように、ナビゲーション装置２３０によって経路が決定される。この経路は、例えば車線の区別が付けられていない大まかな経路である。次に、中図に示すように、推奨車線決定装置２４０が、経路に沿って走行しやすい推奨車線を決定する。そして、下図に示すように、自動運転制御ユニット２５０が、障害物の回避などを行いながら、なるべく推奨車線に沿って走行するための軌道点を生成し、軌道点（および付随する速度プロファイル）に沿って走行するように、駆動力出力装置２６０、ブレーキ装置２６２、ステアリング装置２６４のうち一部または全部を制御する。なお、このような役割分担はあくまで一例であり、例えば自動運転制御ユニット２５０が一元的に処理を行ってもよい。

駆動力出力装置２６０は、車両が走行するための走行駆動力（トルク）を駆動輪に出力する。駆動力出力装置２６０は、例えば、内燃機関、電動機、および変速機などの組み合わせと、これらを制御するパワーＥＣＵとを備える。パワーＥＣＵは、自動運転制御ユニット２５０から入力される情報、或いは不図示の運転操作子から入力される情報に従って、上記の構成を制御する。

ブレーキ装置２６２は、例えば、ブレーキキャリパーと、ブレーキキャリパーに油圧を伝達するシリンダと、シリンダに油圧を発生させる電動モータと、ブレーキＥＣＵとを備える。ブレーキＥＣＵは、自動運転制御ユニット２５０から入力される情報、或いは運転操作子から入力される情報に従って電動モータを制御し、制動操作に応じたブレーキトルクが各車輪に出力されるようにする。ブレーキ装置２６２は、運転操作子に含まれるブレーキペダルの操作によって発生させた油圧を、マスターシリンダを介してシリンダに伝達する機構をバックアップとして備えてよい。なお、ブレーキ装置２６２は、上記説明した構成に限らず、自動運転制御ユニット２５０から入力される情報に従ってアクチュエータを制御して、マスターシリンダの油圧をシリンダに伝達する電子制御式油圧ブレーキ装置であってもよい。

ステアリング装置２６４は、例えば、ステアリングＥＣＵと、電動モータとを備える。電動モータは、例えば、ラックアンドピニオン機構に力を作用させて転舵輪の向きを変更する。ステアリングＥＣＵは、自動運転制御ユニット２５０から入力される情報、或いは運転操作子から入力される情報に従って、電動モータを駆動し、転舵輪の向きを変更させる。

［ライドシェア管理装置］
図１に戻り、ライドシェア管理装置３００は、例えば、通信部３１０と、取得部３２０と、運行管理部３３０と、施設案内部３４０と、リワード要求部３５０と、記憶部３８０とを備える。

通信部３１０は、例えば、ネットワークＮＷに接続するためのネットワークカードである。また、記憶部３８０は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）などにより実現される。通信部３１０は、ネットワークＮＷを介して端末装置１００や車両２００と通信する。

取得部３２０、運行管理部３３０、施設案内部３４０、およびリワード要求部３５０は、例えば、ＣＰＵなどのプロセッサが記憶部３８０に格納されたプログラム（ソフトウェア）を実行することで実現される。また、これらの機能部のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアによって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。

取得部３２０は、通信部３１０およびネットワークＮＷを介して、利用者の端末装置１００から発せられた乗車リクエストを取得し、乗車リクエストに含まれる乗車条件を、乗車条件情報３８４として記憶部３８０に登録する。なお、利用者情報３８２は、サービス申込者Ａ、サービス利用者Ｕ、サービス提供者Ｓの個人情報などを含む。

図４は、乗車条件情報３８４の内容の一例を示す図である。図示するように、乗車条件情報３８４は、予め登録された利用者の識別情報である利用者ＩＤに対し、乗車希望地点、目的地、乗車希望時刻、配車決定済であるか否かを示す配車フラグ（例えば１が配車決定済、０が配車未決定を示す）などが対応付けられた情報である。配車フラグ以外の情報は、端末装置１００のライドシェアアプリが利用者の入力を受け付けることで内容が決定され、乗車リクエストとしてライドシェア管理装置３００に送信される。以下、乗車条件情報３８４における一つの利用者ＩＤに対応付けられた一連の情報をレコードと称する場合がある。

運行管理部３３０は、乗車条件情報３８４と、地図情報３８６と、運行スケジュール情報３８８とを参照し、配車可能な車両２００を検索する。地図情報３８６は、ノードやリンクの情報に加えて、各種の施設の概要を示す施設情報が含まれている（車両２００のナビ地図や高精度地図にも、そのような情報が含まれてもよい）。図５は、地図情報３８６に含まれる施設情報の内容の一例を示す図である。施設情報は、例えば、施設の識別情報である施設ＩＤに対して、位置、施設内容、席数、空席情報などが対応付けられた情報である。この施設とは、例えば、ライドシェアシステム１の運営者と提携している施設であり、カフェなどの座席がある施設であると好適である。また、施設には、ライドシェアシステム１の利用者専用の席が設けてあったり、ライドシェアシステム１の利用者向けの割引サービスがなされていると好適である。席数や空席情報は、施設の端末である施設端末４００から、ライドシェア管理装置３００に随時送信される。

例えば、運行管理部３３０は、乗車条件情報３８４に含まれる各レコードの中から、時間帯と、乗車希望地点から目的地までの走行区間が近いものを粗くグループ化し、更に、一台の車両２００で運ぶことの可能な一以上の利用者に対応する一以上のレコードを抽出し、運行スケジュール情報３８８の一部として記憶部３８０に登録する。

図６は、運行スケジュール情報３８８の内容の一例を示す図である。図示するように、運行スケジュール情報３８８は、ライドシェア管理装置３００が管理する車両２００の識別情報である車両ＩＤに対し、出発地、経由地、および到達地のそれぞれの座標と、車両２００の想定到着時刻、並びに各経由地において乗車する利用者の利用者ＩＤおよび降車する利用者の利用者ＩＤが対応付けられた情報である。出発地や到達地は、通常、車庫などである。運行スケジュール情報３８８には、未だ運行スケジュールが決定されない「空き車両」の情報も併せて登録される。この場合、空き車両に対しては、出発地の座標のみが登録される。運行管理部３３０は、前述したように複数の利用者からの乗車リクエストをまとめて一台の車両２００の運行スケジュールを決定してもよいし、既に決定されている運行スケジュールを検索し、別の利用者の乗車リクエストを盛り込む形で運行スケジュールを変更してもよい。すなわち、運行管理部３３０は、配車可能な車両２００を検索する際に、運行スケジュールが未だ決定されていない車両２００を検索してもよいし、既に決定された車両２００の運行スケジュールの中から、利用者の乗車リクエストを盛り込むことが可能なものを検索してもよい。運行管理部３３０は、所定のタイミングで、運行スケジュール情報３８８に基づく経路（経由地）と想定通過時刻の情報を、車両２００に送信する。なお、運行管理部３３０は、車両２００が手動運転車両である場合、その車両２００の運転者の端末装置または車載端末装置へ乗車リクエストの変更要求を通知する。

運行スケジュールを決定する際に、運行管理部３３０は、乗車希望時刻までには乗車希望地点に到達できないが、乗車希望時刻から最大遅延時間ＴＤ２（第２の所定時間の一例）までの間に乗車希望地点に到達できる場合、その利用者を乗車させるものと決定する。一方、乗車希望時刻から最大遅延時間ＴＤ２を超える時刻でなければ車両２００が乗車希望地点に到達できない場合、交通機関ダイヤ情報３９０を参照し、代替交通機関に関する情報を利用者の端末装置１００に送信する。具体的には、運行管理部３３０は、乗車希望位置と目的地とのそれぞれに近い駅やバス停留所などを地図情報３８６から抽出し、それらを結ぶ最短の移動手段を、交通機関ダイヤ情報３９０を参照して取得する。

施設案内部３４０は、運行管理部３３０による検索結果（より具体的には運行スケジュール情報３８８）を参照し、乗車希望時刻までには乗車希望地点に到達できないが、乗車希望時刻から施設案内基準時間ＴＤ１（第１の所定時間の一例）が経過し、且つ最大遅延時間ＴＤ２を超えない時刻までの間に乗車希望地点に到達できるケースが存在するか否かを判定する。施設案内部３４０は、そのようなケースが存在する場合、該当する利用者の利用可能な施設に関する情報を、利用者の端末装置１００に送信する。なお、「到達できない（到達しない）場合」とは、車両２００の検索時において、乗車希望時刻から第１所定時間が経過する時刻までに乗車希望地点に到達可能な車両が存在しなかった場合と、予約した車両２００が交通状況等により遅延し、乗車希望時刻から第１所定時間が経過する時刻までに乗車希望地点に到達する可能性が低下した場合とが含まれる。すなわち、施設案内部３４０は、車両２００の検索時だけでなく、車両２００の運行が開始した後も、車両２００の遅れに応じて動的に、該当する利用者の利用可能な施設に関する情報を、利用者の端末装置１００に送信してよい。

これに対して、利用者の端末装置１００から、施設の利用について同意する旨の情報が返信された場合、施設案内部３４０は、運行管理部３３０に通知して、当該利用者の乗車希望地点を施設の位置に変更させる。このとき、運行管理部３３０は、運行スケジュール情報３８８における当該利用者の乗車希望時刻を想定到着時刻に合わせて修正してよい。以上の処理によって、利用者は、施設で待ち時間を過ごした後、スムーズに車両２００に乗車することができる。

［処理フロー・場面例］
図７および図８は、ライドシェア管理装置３００により実行される処理の流れの一例を示すフローチャートである。まず、ライドシェア管理装置３００は、端末装置１００から乗車リクエストを受信したか否かを判定する（ステップＳ１００）。端末装置１００から乗車リクエストを受信すると、ライドシェア管理装置３００は、乗車リクエストに含まれる乗車条件を乗車条件情報３８４に追加する（ステップＳ１０２）。

次に、ライドシェア管理装置３００は、運行スケジュール決定タイミングが到来したか否かを判定する（ステップＳ１０４）。運行スケジュール決定タイミングが到来していない場合、ステップＳ１００に処理が戻される。運行スケジュール決定タイミングは任意に定めることができるが、例えば、ライドシェアシステム１の営業時間中において、所定時間（例えば１０分程度）おきに到来するなどと定められる。

運行スケジュール決定タイミングが到来すると、ライドシェア管理装置３００は、乗車条件情報３８４から配車フラグが０のレコードを抽出する（ステップＳ１０６）。次に、ライドシェア管理装置３００は、配車可能な車両２００を検索し、検索結果に基づいて運行スケジュール情報３８８を更新する（ステップＳ１０８）。

次に、ライドシェア管理装置３００は、今回対象となった利用者（ステップＳ１０６で抽出されたレコードに対応する利用者）の中から一人の利用者を選択する（ステップＳ１１０）。そして、ライドシェア管理装置３００は、乗車条件情報３８４および運行スケジュール情報３８８を参照し、当該利用者に対して配車した車両２００の想定到着時刻ＴＡから乗車希望時刻を差し引いた差分が、最大遅延時間ＴＤ２を超えるか否かを判定する（ステップＳ１１２）。差分が最大遅延時間ＴＤ２を超える場合、ライドシェア管理装置３００は、代替交通機関の情報を、当該利用者の端末装置１００に送信する（ステップＳ１１４）。この場合、例えば、当該利用者の乗車リクエストはキャンセル扱いとされ、自動的に或いは利用者の同意を得て、乗車条件情報３８４から削除される。

差分が最大遅延時間ＴＤ２を超えない場合、ライドシェア管理装置３００は、差分が施設案内基準時間ＴＤ１を超え、且つ最大遅延時間ＴＤ２を超えない時間であるか否かを判定する（ステップＳ１１６）。

差分が施設案内基準時間ＴＤ１未満である場合、ライドシェア管理装置３００は、想定到着時刻ＴＡから乗車希望時刻を差し引いた差分が、利用者にとって許容できる範囲内であると判断し、配車完了通知を当該利用者の端末装置１００に送信する（ステップＳ１１８）。この場合、乗車条件情報３８４における当該利用者の配車フラグの項目が１に変更される。

一方、差分が施設案内基準時間ＴＤ１以上、且つ最大遅延時間ＴＤ２未満である場合、（図８に進み）、ライドシェア管理装置３００は、遅延到着通知を端末装置１００に送信する（ステップＳ１２４）。遅延到着通知には、想定到着時刻などの情報が含まれている。

これを受けて、端末装置１００のライドシェアアプリは、利用者による車両利用の同意を得るための画面ＩＭ１を表示する。図９は、端末装置１００において表示される画面ＩＭ１の一例を示す図である。図示するように、画面ＩＭ１には、乗車希望時刻よりも遅い想定到着時刻に到着可能な車両２００が存在する旨の情報が表示され、更に、車両利用について同意するか否かを指示するためのＹＥＳボタンとＮＯボタンが設定されている。利用者によっていずれかのボタンが操作されると、端末装置１００のライドシェアアプリは、操作内容を示す情報をライドシェア管理装置３００に送信する。

図８に戻り、ライドシェア管理装置３００は、端末装置１００から受信した内容に基づいて、利用者による車両利用の同意が得られたか否かを判定する（ステップＳ１２６）。ライドシェア管理装置３００は、端末装置１００においてＹＥＳボタンが操作された場合に同意が得られたと判定し、ＮＯボタンが操作された場合に同意が得られなかったと判定する。利用者による車両利用の同意が得られなかったと判定した場合、図７のステップＳ１２０に処理が戻される。この場合、当該利用者に対する配車はスキップされ、例えば次回の処理ルーチンにおいて再度、配車可能か否かが判定される。

利用者による車両利用の同意が得られたと判定した場合、ライドシェア管理装置３００は、利用者が利用可能な施設の情報を検索する（ステップＳ１２８）。ライドシェア管理装置３００は、乗車希望地点から所定距離以内に存在し、予め地図情報３８６の一部として登録された施設を抽出する。「利用可能な施設」とは、上記のように抽出された施設を指すものであってもよいし、更に、空席が確保可能な施設に限定されてもよい。なお、ライドシェア管理装置３００は、この所定距離を、乗車希望時刻と想定到着時刻との差分が大きいほど、大きく設定してよい。ライドシェア管理装置３００は、検索の結果として得られた施設の情報を端末装置１００に送信する（ステップＳ１３０）。なお、この情報送信は、配車完了通知を兼ねている。

これを受けて、端末装置１００のライドシェアアプリは、利用者による施設利用の同意を得るための画面ＩＭ２を表示する。図１０は、画面ＩＭ２の一例を示す図である。図示するように、画面ＩＭ２では、車両２００の予約（配車）が完了した旨の情報が表示され、更に、地図上に利用可能な施設の位置を示すアイコン（Ｓ１、Ｓ２）が表示されている。このアイコンに対応付けて、席数や空席の情報が表示されてもよい。いずれかのアイコンが操作されると、端末装置１００のライドシェアアプリは、施設利用の同意を得るための画面ＩＭ３を表示する。図１１は、画面ＩＭ３の一例を示す図である。図示するように、画面ＩＭ３では、地図上に操作されたアイコン（Ｓ１）がハイライト表示され、更に、施設利用について同意するか否かを指示するためのＹＥＳボタンとＮＯボタンが設定されている。利用者によっていずれかのボタンが操作されると、端末装置１００のライドシェアアプリは、操作内容を示す情報をライドシェア管理装置３００に送信する。

図８に戻り、ライドシェア管理装置３００は、端末装置１００から受信した内容に基づいて、利用者による施設利用の同意が得られたか否かを判定する（ステップＳ１３２）。ライドシェア管理装置３００は、端末装置１００においてＹＥＳボタンが操作された場合に同意が得られたと判定し、ＮＯボタンが操作された場合に同意が得られなかったと判定する。利用者による施設利用の同意が得られなかったと判定した場合、図７のステップＳ１２０に処理が戻される。この場合、乗車条件情報３８４における当該利用者の配車フラグの項目が１に変更される。当該利用者は、最大遅延時間ＴＤ２未満の待ち時間で、当初の乗車希望地点から車両２００に乗車することになる。

利用者による施設利用の同意が得られたと判定した場合、ライドシェア管理装置３００は、該当する施設の予約を行い、予約が完了した場合、予約完了通知を端末装置１００に送信する（ステップＳ１３４）。なお、施設の予約は、施設端末４００にアクセスすることで自動的に行われてもよいし、施設の情報を表示部に表示し、オペレータが電話をかける形で行われてもよい。

これを受けて、端末装置１００のライドシェアアプリは、利用者による乗車希望地点変更の同意を得るための画面ＩＭ４を表示する。図１２は、画面ＩＭ４の一例を示す図である。図示するように、画面ＩＭ４では、施設が店舗である場合、店舗の予約が完了した旨の情報が表示され、更に、乗車希望地点（図では「ライドポイント」）を店舗の前に変更することについて同意するか否かを指示するためのＹＥＳボタンとＮＯボタンが設定されている。利用者によっていずれかのボタンが操作されると、端末装置１００のライドシェアアプリは、操作内容を示す情報をライドシェア管理装置３００に送信する。

図８に戻り、ライドシェア管理装置３００は、端末装置１００から受信した内容に基づいて、利用者による乗車希望地点の変更に同意が得られたか否かを判定する（ステップＳ１３６）。乗車希望地点の変更に同意が得られなかったと判定した場合、図７のステップＳ１２０に処理が戻される。この場合、乗車条件情報３８４における当該利用者の配車フラグの項目が１に変更される。当該利用者は、施設を利用した後、当初の乗車希望地点に移動してから車両２００に乗車することになる。

利用者による乗車希望地点の変更に同意が得られたと判定した場合、ライドシェア管理装置３００は、運行スケジュール情報３８８における当該利用者の乗車希望地点を施設の位置に変更して運行スケジュール情報３８８を更新し、変更完了通知を端末装置１００に送信する（ステップＳ１３８）。この場合、乗車条件情報３８４における当該利用者の配車フラグの項目が１に変更される。

これを受けて、端末装置１００のライドシェアアプリは、乗車希望地点を変更した旨を示す画面ＩＭ５を表示する。図１３は、画面ＩＭ５の一例を示す図である。図示するように、画面ＩＭ５には、ステップＳ１３４で予約した施設の電子クーポン画像ＣＰが含まれてよい。

図７に戻り、ステップＳ１１４、Ｓ１１８、またはＳ１３８の処理の後、或いは、ステップＳ１２６、Ｓ１３２、またはＳ１３６で否定的な判定を得た場合、ライドシェア管理装置３００は、全ての利用者を選択し終えたか否かを判定する（ステップＳ１２０）。全ての利用者を選択し終えていない場合、ステップＳ１１０に処理が戻される。全ての利用者を選択し終えた場合、ライドシェア管理装置３００は、今回の処理で追加または更新された運行スケジュールを車両２００に送信する（ステップＳ１２２）。これによって、図７および図８に示すフローチャートの１ルーチンの処理が終了する。

なお、前述したように、施設案内部３４０は、車両２００の検索時だけでなく、車両２００の運行が開始した後も、車両２００の遅れに応じて動的に、該当する利用者の利用可能な施設に関する情報を、利用者の端末装置１００に送信してよい。従って、図７のフローチャートにおけるステップＳ１１２以降の処理は、車両２００が運行を開始した後も定期的に実行され、遅れが生じるのに応じて施設の案内を行ったり、代替交通機関の情報を送信したりする処理が行われてよい。

［リワード］
以下、ライドシェアシステム１におけるリワード制度について説明する。ライドシェア管理装置３００によって施設の情報が提供され、或いは施設利用の合意が得られた場合、施設の管理者は、ライドシェアシステム１の運営者に対してリワード（報酬）を支払う。また、利用者が施設において支払いを行った場合、施設の管理者は、ライドシェアシステム１の運営者に対してリワードを支払う。

ライドシェアシステム１の運営者と施設の管理者との間では、送客関係が成立しているため、このようなリワード制度が制定されることで、スムーズなシステム運営が実現される。リワード要求部３５０は、施設の管理者に対するリワードの額（量）を決定する。

図１４は、リワード用集計情報３９２の内容の一例を示す図である。図示するように、リワード用集計情報３９２は、図５と同様の施設ＩＤに対して、情報提供回数、立ち寄り合意回数、支払発生回数、支払金額総計などの情報が対応付けられた情報である。情報提供回数とは、当該施設について、図８のステップＳ１３０の情報送信を行った回数である。立ち寄り合意回数とは、当該施設について、図８のステップＳ１３２において肯定的な判定が得られた回数である。なお、情報提供回数は、一回の情報送信において複数の施設に対してカウントされる場合があるが、立ち寄り合意回数は、一つの施設に対してカウントされる。

支払発生回数とは、ライドシェア管理装置３００の制御による予約がなされて施設を利用した利用者が支払を行った回数であり、支払金額総計は、その支払い金額の総計である。これらの情報は、例えば、施設端末４００からライドシェア管理装置３００に送信される。リワード要求部３５０は、ライドシェア管理装置３００の処理に応じて、或いは、施設端末４００から受信した情報に基づいて、リワード用集計情報３９２を更新する。

そして、リワード要求部３５０は、情報提供回数、立ち寄り合意回数、支払発生回数、支払金額総計のうち一部または全部に基づいて、施設の管理者に対するリワードの額を決定する。リワード要求部３５０は、例えば、決定したリワードの額を掲載した電子請求書を生成し、施設端末４００に送信する。これによって、スムーズなシステム運営が実現される。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、ライドシェア管理装置３００は、車両２００に搭載されてもよい。

また、車両２００が手動運転車両である場合、通信部３１０は、ネットワークＮＷを介して車両２００の運転者の端末装置と通信してよい。

１ ライドシェアシステム
１００ 端末装置
２００ 車両
３００ ライドシェア管理装置
３１０ 通信部
３２０ 取得部
３３０ 運行管理部
３４０ 施設案内部
３５０ リワード要求部
３８０ 記憶部
Ｕ 利用者

Claims (10)

1. 利用者の端末装置と通信する通信部と、
   少なくとも乗車希望地点と乗車希望時刻とを含む乗車条件が定義された、利用者の乗車リクエストを取得する取得部と、
   前記乗車リクエストに含まれる乗車条件に基づいて、配車可能な車両を検索し、車両の運行スケジュールを決定する運行管理部と、
   前記運行管理部による検索の結果を参照し、前記乗車希望時刻から第１所定時間が経過する時刻までに前記車両が前記乗車希望地点に到達しない場合、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信する施設案内部と、
   を備えるライドシェア管理装置。
2. 前記施設案内部は、前記乗車希望時刻から前記第１所定時間が経過する時刻までに車両が前記乗車希望地点に到達せず、且つ前記乗車希望時刻から前記第１所定時間よりも長い第２所定時間が経過する時刻までに車両が前記乗車希望地点に到達する場合に、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信する、
   請求項１記載のライドシェア管理装置。
3. 前記運行管理部は、前記乗車希望時刻から前記第２所定時間が経過する時刻までに前記乗車希望地点に到達可能な車両が発見されなかった場合、代替交通手段に関する情報を、前記通信部を用いて前記利用者の端末装置に送信する、
   請求項２記載のライドシェア管理装置。
4. 前記運行管理部は、前記施設案内部により情報が送信された施設の利用に前記利用者が同意する旨の情報を、前記通信部が前記利用者の端末装置から受信した場合、前記車両の運行スケジュールを、前記施設において前記利用者を乗車させる運行スケジュールに変更する、
   請求項１から３のうちいずれか１項記載のライドシェア管理装置。
5. 前記施設の管理者が使用する施設端末に対して、前記利用者の端末装置に当該施設の情報を送信した回数に応じた報酬を要求する情報を送信するリワード要求部を更に備える、
   請求項１から４のうちいずれか１項記載のライドシェア管理装置。
6. 前記施設の管理者が使用する施設端末に対して、前記利用者の端末装置から、前記利用者が当該施設を利用することに同意する旨の情報が得られた回数に応じた報酬を要求する情報を送信するリワード要求部を更に備える、
   請求項１から５のうちいずれか１項記載のライドシェア管理装置。
7. 前記施設の管理者が使用する施設端末に対して、前記利用者が施設において支払を行った回数または支払金額に応じた報酬を要求する情報を送信するリワード要求部を更に備える、
   請求項１から６のうちいずれか１項記載のライドシェア管理装置。
8. 前記車両は、自動運転車両である、
   請求項１から７のうちいずれか１項記載のライドシェア管理装置。
9. 利用者の端末装置と通信する通信部を備える装置が、
   少なくとも乗車希望地点と乗車希望時刻とを含む乗車条件が定義された、利用者の乗車リクエストを取得し、
   前記乗車リクエストに含まれる乗車条件に基づいて、配車可能な車両を検索し、車両の運行スケジュールを決定し、
   前記検索の結果を参照し、前記乗車希望時刻から第１所定時間が経過する時刻までに前記車両が前記乗車希望地点に到達しない場合、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信する、
   ライドシェア管理方法。
10. 利用者の端末装置と通信する通信部を備える装置のコンピュータに、
    少なくとも乗車希望地点と乗車希望時刻とを含む乗車条件が定義された、利用者の乗車リクエストを取得させ、
    前記乗車リクエストに含まれる乗車条件に基づいて、配車可能な車両を検索し、車両の運行スケジュールを決定させ、
    前記検索の結果を参照させ、前記乗車希望時刻から第１所定時間が経過する時刻までに前記車両が前記乗車希望地点に到達しない場合、前記利用者の利用可能な施設に関する情報を、前記通信部を用いて前記利用者の端末装置に送信させる、
    プログラム。

Images