JP7291522B2 - 乗車予約利用者支援装置及び乗車予約利用者支援方法 - Google Patents

Description

本発明は、乗車予約利用者支援装置及び乗車予約利用者支援方法に関する。

利用者が乗り合いバスの利用を予約する乗車予約システムにおいて、乗り合いバスが乗車予定地に到着したときに、利用者が時間通りに間に合わない場合であっても、可能な限り待機していることが利用者の利便性の観点から望ましい。

しかし、利用者が乗車予定地に間に合わない場合にまで待機を行うと、乗り合いバスの運行計画に遅延が生じるおそれが高くなるため、好ましくない。そこで、一定条件の下で、乗車予約を取り消すことが考えられる。

例えば、一般交通と、乗車予約が可能なオンデマンド交通とを組み合わせて、目的地まで行く場合、一般交通の遅延情報に基づき、予約したオンデマンド交通の経路部分の出発地点への到着日時を再計算し、再計算の結果、予約したオンデマンド交通に間に合わない場合、予約システムに対して、当該予約の取り消しを行なわせることが提案されている（特許文献１等参照）。

特開２０１４－１０８１８号公報

しかしながら、予約した乗り合いバスの乗車予定地まで利用者が徒歩で向かう場合、特許文献１に記載されたような一般交通の遅延情報を利用した技術は適用できない。

本発明は係る点に鑑みてなされたものであり、利用者の利便性を高め、かつ、車両運行計画への影響を抑制できる乗車予約利用者支援装置及び乗車予約利用者支援方法を提供することを目的とする。

本発明の一態様の乗車予約利用者支援装置は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部と、前記端末の位置情報を取得する位置情報取得部と、前記位置情報が示す地点から乗車予定地
までに前記利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する経路外れ判定部と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる通知提供部と、を具備し、前記通知は、前記車両が前記乗車予定地に到着する車両到着予想時刻を含むことを特徴とする。

本発明の一態様の乗車予約利用者支援方法は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する工程と、前記端末の位置情報を取得する工程と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する工程と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する工程と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる工程と、を具備し、前記通知は、前記車両が前記乗車予定地に到着する車両到着予想時刻を含むことを特徴とする。

本発明によれば、利用者の利便性を高め、かつ、車両運行計画への影響を抑制できる。

第１の実施の形態に係る乗車予約利用者支援装置を適用した乗り合いバス予約システム全体を示す模式図である。 第１の実施の形態に係る車両管理サーバの予約管理部を示す機能ブロック図である。 第１の実施の形態に係る端末を示す機能ブロック図である。 第１の実施の形態に係るバスを示す機能ブロック図である。 第１の実施の形態に係る乗り合いバス予約システムにおける処理及びデータのやり取りを示すシーケンス図である。 第１の実施の形態に係る乗り合いバス予約システムにおける利用者支援処理の各処理を示すフローチャート図である。 第１の実施の形態に係る乗り合いバス予約システムにおける通知提供処理の各処理を示すフローチャート図である。 第１の実施の形態に係る乗り合いバス予約システムにおいて端末に提供される通知を含む画面例を示す模式図である。 第１の実施の形態に係る乗り合いバス予約システムにおける利用者支援の具体例を示す説明図である。 第１の実施の形態に係る乗り合いバス予約システムにおける利用者支援の具体例を示す説明図である。 第１の実施の形態に係るサーバ及び端末のハードウェア構成の一例を示す図である。 第２の実施の形態に係る車両管理サーバの予約管理部を示す機能ブロック図である。 第２の実施の形態に係る乗り合いバス予約システムにおける利用者支援処理の一部を示すフローチャート図である。 第２の実施の形態に係る乗り合いバス予約システムにおける通知提供処理の一部を示すフローチャート図である。 第３の実施の形態に係る乗り合いバス予約システムにおける利用者支援処理の一部を示すフローチャート図である。

以下、本発明の実施の形態について添付図面を参照して詳細に説明する。なお、以下においては、本発明に係る乗車予約利用者支援装置及びその方法を、定時運行を行う無人運転乗り合いバスに適用した例について説明するが、適用対象はこれに限定されることなく変更可能である。例えば、本発明に係る乗車予約利用者支援装置を、利用者の依頼に応じて配車され、利用者及びその同伴者に限り乗車することを前提とした、タクシーのような無人運転車両に適用してもよい。また、車両のタイプは特に限定されることなく、四輪車、二輪車・三輪車等の鞍乗型車両のどちらのタイプの車両であってもよい。また、無人運転車両は、搭乗員が乗っていても構わない。さらに、車両が、運転手により運転される手動運転車両、及び、運転支援装置が搭載された車両であってもよい。

（本発明の概要）
定期運行される無人運転バスの乗車予約システムにおいて、利用者が乗車予定地に向っていない場合、一定条件の下で、乗車予約を取り消すことが、定期運行性の確保の観点から、有効であると考えられる。

そこで、利用者の現在位置と乗車予定地との相対関係に基づいて乗車予約を取り消すことが考えられる。例えば、利用者が乗車予定地から離れていること、又は、利用者が乗車予定地と異なる方向に向かっていることなどを条件として、乗車予約を取り消すことが可能である。しかし、これらの場合、利用者が乗車予定地に向う経路に建物があったり、道路工事が行われている等の障害があったり、一時的に乗車予定地から離れていく場合、又は、一時的に異なる方向に向かう場合にも、予約が取り消されてしまい、利用者の利便性が著しく損なわれるという不都合が生じる。

このような事態を回避するために、利用者が車両に対して待機を行うことを要求することが考えられる。利用者からの要求があった場合にのみ車両が待機すればよく、利用者の利便性が高くなる。しかし、要求を行うかどうかは利用者の自主性に委ねられるため、実効性が懸念される。特に、利用者が高齢者の場合、このような懸念が高くなる。

そこで、本発明者らは、鋭意検討を重ねた結果、利用者の端末の移動経路が、利用者の乗車予定地までの所定の径路から外れている場合、適切な通知を行い、利用者の意志を確認し、それに沿った対処を行うことが、利用者の利便性及び車両運行計画への影響抑制に寄与することを見出し、本発明を完成した。

すなわち、本実施の形態に係る乗車予約利用者支援装置は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部と、前記端末の位置情報を取得する位置情報取得部と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する経路外れ判定部と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる通知提供部と、を具備する。

また、本実施の形態に係る乗車予約利用者支援方法は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する工程と、前記端末の位置情報を取得する工程と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する工程と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する工程と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる工程と、を具備する。

＜第１の実施の形態＞
以下、本発明の第１の実施の形態に係る乗車予約利用者支援装置を適用した乗り合いバス運行システムについて、図１～図１１を参照して、詳細に説明する。

（システム全体）
図１は、第１の実施の形態に係る乗車予約利用者支援装置を適用した乗り合いバス予約システム全体を示す模式図である。図１に示す乗り合いバス予約システム１は、クラウド２に配置された車両管理サーバ３を備えている。車両管理サーバ３には、ネットワークの一例である移動体通信網４を介して、端末５及びバス６が通信可能に接続されている。また、車両管理サーバ３には、インターネット（不図示）を介して、管制用端末７が接続されている。管制用端末７は、移動体通信網４を介して、バス６と通信可能に接続されている。端末５及びバス６は、ＧＮＳＳ衛星８からＧＮＳＳ信号を受信可能に構成されている。なお、図１では、端末５及びバス６は、便宜上、１つずつ示しているが、複数存在していてもよい。

（車両管理サーバ）
車両管理サーバ３は、予約管理部３１、運行管理部３２及び経路探索部３３の各機能を備えている。予約管理部３１は、本発明に係る乗車予約利用者支援装置の一例である。利用者への支援の詳細について後述する。また、予約管理部３１は、利用者からの乗車予約を受け付けて乗車予約情報（後述）を作成し、運行管理部３２に提供するように構成されている。

運行管理部３２は、バス６を、運行計画に従って、運行経路を予定時刻に従って走らせると共に、バス６の運行状況及び車内状況を把握し、管制用端末７にそれらを出力させるように構成されている。また、運行管理部３２は、バス６にバス停に停車し、利用者を乗せて、発車するまでの一連の動作（以下、「迎車動作」と記載する）を実行させる。

経路探索部３３は、予約管理部３１からの情報に基づいて、地図データを参照し、端末５の現在位置からバス停までの利用者が利用すると予想される予想経路を探索するよう構成されている。また、経路探索部３３は、端末５及びバス６の現在位置からバス停への到着予想定時刻を算出するよう構成されている。経路探索部３３は、一般的なカーナビゲーション装置及び経路探索サービスのための経路探索サーバが備えている構成と同様であればよい。
（予約管理部）
図２は、第１の実施の形態に係る車両管理サーバ３の予約管理部を示す機能ブロック図である。予約管理部３１は、その機能として、予約情報取得部３０１、位置情報取得部３０２、経路情報取得部３０３、経路外れ判定部３０４、通知提供部３０５、到着時刻取得部３０６、待機指示処理部３０７、予約調整部３０８及び乗車予約作成部３０９を備えている。

予約情報取得部３０１は、記憶部３４に記憶された乗車予約データベース（ＤＢ）３４１を参照し、端末５の利用者が行った乗車予約情報を取得するよう構成されている。乗車予約情報は、少なくとも、利用者の端末５及び利用者が車両に乗車するバス停を特定できる識別情報を含んでいる。識別情報の形式等は特に限定されない。バス停は、本発明の乗車予定地の一例である。

位置情報取得部３０２は、通信部３５を制御し、端末５及びバス６から現在位置情報を受信するよう構成されている。

経路情報取得部３０３は、端末５の現在位置情報及びバス停の位置情報を経路探索部３３に入力し、その応答として、現在位置情報が示す地点からバス停まで利用者が利用すると予想される予想経路を示す経路情報を取得するよう構成されている。ここで、バス停の位置情報は、例えば、緯度経度で表されるが特に限定されない。バス停の位置情報は、乗車予約情報に含まれるバス停を特定できる識別情報に基づいて、運行管理部３２（図１参照）が管理し、記憶部３４に記憶されているバス停データベース３４２を参照することにより取得できるが、特に限定されない。

経路外れ判定部３０４は、端末５の位置情報及び経路情報に基づいて端末５が予想経路から外れているか否かを判定する処理（以下、「経路外れ判定処理」と記載する）を行うよう構成されている。経路外れ判定処理の詳細については後述する。

通知提供部３０５は、端末５に利用者への通知を提供させる処理（以下、「通知提供処理」と記載する）を行うよう構成されている。具体的には、通知提供部３０５は、通信部３５を制御し、端末５へ所望の通知を行うよう指示する信号（以下、「通知指示信号」と記載する）を送信する。通知指示信号には、例えば、通知内容を特定するための識別情報及び利用者及びバス６の到着予想時刻が含まれるが、特に限定されない。通知提供処理の詳細については後述する。

到着時刻取得部３０６は、端末５又はバス６の現在位置情報及びバス停の位置情報を経路探索部３３に入力し、その応答として、端末５又はバス６がバス停に到着すると予想される時刻（以下、「到着予想時刻」と記載する）を取得するように構成されている。

待機指示処理部３０７は、端末５から通信部３５により受信した待機要求信号（後述）に応じて、バス６に対し、バス停での待機を行うことを指示する信号（以下、「待機指示信号」と記載する）を送信するよう構成されている。また、待機指示処理部３０７は、バス６に対し、バス停での待機を解除することを指示する信号（以下、「待機解除信号」と記載する）を送信するように構成されている。

予約調整部３０８は、端末５からの待機要求信号に応じて、待機指示処理部３０７がバス６への待機指示信号の送信を行い、待機解除信号を送信していない状態（以下、「待機継続状態」と記載する）において、バス６がバス停に到着後所定時間経過後に、利用者による乗車予約を取り消す処理（以下、「予約キャンセル処理」と記載する）を行うように構成されている。

乗車予約作成部３０９は、端末５と通信部３５を介して通信し、乗車予約を受け付け、乗車予約情報を作成し、乗車予約データベース３４１に登録する処理を行うように構成されている。乗車予約を受け付けるための乗車予約作成部３０９と端末５とのデータのやり取りや各種処理は、一般的な交通機関の予約システムと同様であり、説明を省略する。

上述のような予約管理部３１の各機能は、後述するように車両管理サーバ３を実現するためのコンピュータ装置１０００（図１１参照）のプロセッサ１００１がプログラムを実行し、通信部３５を制御して信号等を送受信し、又は、記憶部３４に対しデータ等を書き込み及び読み出しすることにより実現することができる。

（端末）
図３は、第１の実施の形態に係る端末５を示す機能ブロック図である。図３に示すように、端末５は、演算部５１により実現される機能として、乗車予約処理部５０１、通知出力部５０２、現在位置出力部５０３、待機要求処理部５０４及び操作受付部５０５を備えている。

乗車予約処理部５０１は、車両管理サーバ３の乗車予約作成部３０９（図２参照）と、通信部５２により移動体通信網４（図１参照）を介して通信し、乗車予約を行うように構成されている。乗車予約を行うための乗車予約作成部３０９とのデータのやり取りや各種処理は、一般的な交通機関の予約システムと同様であり、説明を省略する。

通知出力部５０２は、通知提供部３０５（図２参照）からの通知指示信号に応じて、出力部５３を制御し、利用者への通知を行うように構成されている。通知は、例えば、出力部５３の一例である表示部に通知内容を表示することにより行われるが特に限定されない。例えば、通知内容を出力部５３の一例であるスピーカーから音声出力してもよい。通知内容は、記憶部５４に記憶された通知データ５４１に基づいてもよいし、通知指示信号に含められ、又は、付随して通知提供部３０５から受信した情報（例えば、到着予想時刻）に基づいていてもよい。

現在位置出力部５０３は、ＧＮＳＳ受信部５５によりＧＮＳＳ衛星８（図１参照）からＧＮＳＳ信号を受信して現在位置情報を取得し、現在位置情報を、通信部５２を制御し、車両管理サーバ３の位置情報取得部３０２へ送信する処理を行うように構成されている。

待機要求処理部５０４は、利用者による操作に応じ、車両管理サーバ３の待機指示処理部３０７（図２参照）に対し、通信部５２を介して、バス６への待機指示を要求する信号（以下、「待機要求信号」と記載する）を送信するように構成されている。利用者による操作は、入力部５６を介して行われ、操作受付部５０５により受け付けられ、待機要求処理部５０４に伝えられるように構成されている。

上述のような端末５の各機能は、後述するように端末５を実現するためのコンピュータ装置１０００（図１１参照）のプロセッサ１００１がプログラムを実行し、通信部５２を制御して信号等を送受信し、又は、記憶部５４に対しデータ等を書き込み及び読み出しすることにより実現することができる。

特に、端末５が、スマートフォン又はタブレットに代表されるように、オペレーションシステム（ＯＳ）上で実行されるアプリケーションプログラムにより、様々な機能を実現できる場合、図３を参照して説明した各機能の一部又は全部は、アプリケーションプログラムにより実現されてもよい。

（バス）
図４は、第１の実施の形態に係るバス６を示す機能ブロック図である。なお、バス６が当然に備えている構成（例えば、車輪、シート、ヘッドライト）や任意に備えている構成（空調装置等）については、本実施の形態の説明に必要なものだけを示し、省略している。

図４に示すように、バス６は、演算部６１が実現する機能として、自動運転制御部６０１、ドア開閉制御部６０２、現在位置出力部６０３、駆動制御部６０４、制動制御部６０５、操舵制御部６０６、会話制御部６０７及び運行状況通知部６０８を備えている。

自動運転制御部６０１は、車両管理サーバ３の運行管理部３２から、通信部６２により移動体通信網４（図１参照）を介して通信を行い、運行計画に関する情報を取得し、運行計画に沿った運行経路を無人で自動走行し、乗車予約がなされたバス停で迎車動作を実行するように構成されている。

まず、自動運転制御部６０１は、記憶部６３に記憶された地図データ（不図示）を参照し、運行計画で指定された運行経路を走行する。

自動運転制御部６０１は、無人自動走行に際し、駆動制御部６０４に、電動モータ等の駆動部６４を制御させ、バス６の加減速を行わせる。また、自動運転制御部６０１は、制動制御部６０５に、ブレーキ等の制動部６５を制御させ、バス６の制動及び停止を行わせる。さらに、自動運転制御部６０１は、操舵制御部６０６に、ステアリングモータ等の操舵部６６を制御させ、バス６の右左折等を行わせる。

より具体的には、自動運転制御部６０１は、センサ６７の一つである前方カメラからの検知信号に従って、前方車両との距離を把握し、車間を維持するように、駆動部６４及び制動部６５の制御を実行する。ここで、前方カメラの他、前方センサ（ミリ波レーダ、ＬＩＤＡＲ等）を用いてもよい。

また、自動運転制御部６０１は、センサ６７の一つである前方カメラからの検知信号に基づいて、障害物を検知したとき、制動部６５を制御し、バス６を停止する制御を実行し、又は、操舵部６６を制御し、バス６を方向転換し、障害物を回避する制御を実行する。

このように自動運転制御部６０１は、例えば、ＳＡＥ Ｉｎｔｅｒｎａｔｉｏｎａｌにより定義された自動運転レベル４又は５に相当する自動運転を行うことができるように構成されるが、特に限定されるものではない。

また、自動運転制御部６０１は、バス停において利用者を乗車させるときは、操舵部６６を制御して、バス停近くの路肩にバス６を寄せ、次いで、制動部６５を制御し、バス６を停車させる。その後、自動運転制御部６０１は、ドア開閉制御部６０２に、ドア開閉駆動部７０を制御させ、ドアを開き、利用者を乗車させる。このようなバス停に停車する一連の動作を、以下、バス停停車動作と記載する。

また、自動運転制御部６０１は、センサ６７の一つであるドアセンサにより、ドアが閉っていること、及び、センサ６７の一つであるシートベルト装着センサにより、利用者が着座し、シートベルトを装着したことを確認（以下、「安全確認」と記載する）し、利用者の安全を確保した後、バス６を発車させる。このようなバス６がバス停から発車する一連の動作を、以下、バス停発車動作と記載する。バス停発車動作の中で行われる安全確認の結果は、自動運転制御部６０１が、通信部６２を制御し、運行管理部３２（図１参照）に送信される。運行管理部３２は、安全確認の結果を、記憶部３４（図２参照）に記録し、また、管制用端末７へ出力し、管制担当者に通知する。

現在位置出力部６０３は、ＧＮＳＳ受信部６８によりＧＮＳＳ衛星８（図１参照）からＧＮＳＳ信号を受信して現在位置情報を取得し、現在位置情報を、通信部６２を制御し、車両管理サーバ３の位置情報取得部３０２へ送信する処理を行うように構成されている。

会話制御部６０７は、通信部６２を制御し、移動体通信網４（図１）を介して、管制用端末７と通信を行い、管制担当者による利用者との会話を実現するように構成されている。バス６において、入力部６９の一つであるマイクにより利用者の音声を受け付けると共に、出力部７１の一つであるスピーカーから管制担当者の音声を出力する。音声に代えて、または音声に加えて、ディスプレイでのテキスト表示を行ってもよい。

運行状況通知部６０８は、自動運転制御部６０１からの情報、ドアセンサ、シートベルト装着センサなどにより、バス停での停車、利用者の乗車、バス停からの発車などの運行状況通知を作成し、通信部６２を制御して、移動体通信網４（図１参照）を介して、予約管理部３１及び運行管理部３２に運行状況通知を送信するように構成されている。

上述のようなバス６の各機能は、ＥＣＵ（Electronic Control Unit）及び／又は車載コンピュータにより実現することができる。例えば、車載コンピュータの構成は、基本的には、後述するように端末５を実現するためのコンピュータ装置１０００（図１１参照）と同等である。したがって、プロセッサ１００１がプログラムを実行し、通信部６２を制御して信号等を送受信し、又は、記憶部６３に対しデータ等を書き込み及び読み出しすることにより、バス６の各機能を実現することができる。また、ＥＣＵのように、マイクロコントローラ（マイコン）により、バス６の各機能が実現されていてもよい。

（オンデマンド交通）
第１の実施の形態では、定期運行を行う乗り合いバスにおいて乗車予約があったバス停にバス６が停車する場合を例に挙げて説明する。本発明が適用される交通機関の他の態様としては、オンデマンド交通（デマンド型交通ともいう）を挙げることができる。オンデマンド交通には、例えば、以下のタイプが含まれるが、特に限定されるものではない。本発明の主題は、乗車予約があったバス停に利用者が現れない場合の対処であり、車両の運行形式に依存しない。

（１）定路線型
一般的な路線バスのように一定の経路を巡回し、バス停に停止するが、車両予約があった場合のみ運行する。
（２）自由経路ドアツードア型
運行エリアは決まっているものの、一般的なタクシー事業のように運行経路を定めず、需要に応じ、乗降場所の指定も行わない。この場合、乗車予定地は、利用者が指定する任意の地点であってよく、例えば、自宅であってもよい。
（３）迂回経路・エリアデマンド型
定路線型を基本とし、予約があった場合に予め定められた迂回経路やエリアへ運行する。
（４）自由経路ミーティングポイント型
運行経路は定めず、予約があったバス停間を結ぶ最短経路を運行する。

しかしながら、本実施の形態は、オンデマンド交通に限定されるものではなく、タクシー等の予約配車にも適用することができる。

（乗車予約からバス発車までの処理）
図５は、第１の実施の形態に係る乗り合いバス予約システム１における処理及びデータのやり取りを示すシーケンス図である。図５に示すように、まず、端末５から車両管理サーバ３の予約管理部３１に対し、乗車予約が行われる（Ｓ１）。このとき、予約管理部３１は、端末５から、例えば、利用者、利用者の端末５、利用日、利用経路、乗車バス停及び降車バス停に関する情報を受け取る。

予約管理部３１は、端末５から受け取った情報に基づいて、乗車予約情報を作成する（Ｓ２）。乗車予約情報は、例えば、利用者を識別する利用者ＩＤ、利用者の端末５を識別する端末ＩＤ、利用日、利用経路を識別する利用経路ＩＤ、乗車バス停を識別する乗車バス停ＩＤ及び降車バス停を識別する降車バスＩＤや、利用者の乗車区間に応じて予め定められる運賃を識別する運賃ＩＤを含む。予約管理部３１は、作成した乗車予約情報を乗車予約データベース３４１（図２参照）に登録する。

次に、予約管理部３１は、乗車予約情報に従って、乗車バス停での停車を行う旨の要求（以下、「バス停停車要求」と記載する）を、運行管理部３２に送信する（Ｓ３）。バス停停車要求には、利用日及び利用経路ＩＤ及び乗車バス停ＩＤが含まれる。

運行管理部３２は、バス停停車要求に応じて、バス停での停車を行う旨の指示（以下、「バス停停車指示」と記載する）を、バス６に送信する。より具体的には、運行管理部３２は、バス停停車要求に含まれる利用日及び利用経路ＩＤに基づいて、記憶部３４（図２参照）に記憶された運行計画データベース３４３を検索して乗車するバス６を特定し、特定されたバス６に対してバス停停車指示を送信する。バス停停車指示には、例えば、乗車予定地のバス停を識別するバス停ＩＤが含まれる。

バス６が、運行に出発すると、定期的に、現在位置情報を予約管理部３１の位置情報取得部３０２（図２参照）に送信する（Ｓ５）。図５では、便宜上、１回分だけ示している。

予約管理部３１の到着時刻取得部３０６は、位置情報取得部３０２が取得したバス６の現在位置情報を経路探索部３３（図２参照）に入力し、バス６のバス停への到着予想時刻（以下、「バス到着予想時刻」と記載する）を取得する（Ｓ６）。バス到着予想時刻は、本発明の車両到着予想時刻の一例である。次いで、通知提供部３０５が、バス６の到着予想時刻が現在時刻から所定の時間（例えば、１０分）以内になったか否かに基づいて、利用者支援処理（Ｓ８）を開始するか否かの判定を行う（Ｓ７）。なお、現在時刻は、例えば、時計部（リアルタイムクロック回路等）３６（図２参照）から取得できる。利用者支援処理（Ｓ８）の詳細については、後述する。

その後、バス６がバス停に到着すると、自動運転制御部６０１（図４参照）は、バス停停車動作を行い、バス停に停車する（Ｓ９）。次いで、運行状況通知部６０８は、バス６がバス停に停車したことを示す通知（以下、「停車確認通知」と記載する）を、予約管理部３１へ送信する（Ｓ１０）。

その後、自動運転制御部６０１は、バス停発車動作を行い、バス停から発車する（Ｓ１１）。次いで、運行状況通知部６０８は、バス６がバス停を発車したことを示す通知（以下、「発車確認通知」と記載する）を、予約管理部３１へ送信する（Ｓ１２）。

（利用者支援処理）
図６は、第１の実施の形態に係る乗り合いバス予約システム１における利用者支援処理の各処理を示すフローチャート図である。図６に示すように、予約管理部３１（図２参照）において、まず、位置情報取得部３０２が、乗車予約データベース３４１から乗車予約情報を取得する（Ｓ１０１）。

次いで、位置情報取得部３０２が、乗車予約情報に基づいて、バス６に乗車予約した利用者の端末５に対し、現在位置情報を要求し、取得する（Ｓ１０２）。

次に、位置情報取得部３０２が、現在位置情報を取得できたか否か判定する（Ｓ１０３）。Ｓ１０３における判定がＮｏであれば、処理を終了し、Ｙｅｓであれば、経路情報取得部３０３が、端末５の現在位置情報に基づいて、端末５の現在位置情報が示す地点からバス停までに利用者が用いると予想される予想経路を示す経路情報を取得する（Ｓ１０４）。予想経路の詳細については、後述する。

（経路外れ判定処理）
その後、経路外れ判定部３０４が、Ｓ１０４で取得した経路情報と、端末５から取得する最新の現在位置情報に基づいて、端末５が予想経路から外れているか否かを判定する経路判定処理を行う（Ｓ１０５）。

本実施の形態において、経路外れ判定処理には、一般的なカーナビゲーション装置で行われている経路再検索（リルート）の要否の判定と同じ手法を用いることができる。例えば、端末５から取得した現在位置情報が示す地点を地図上にプロットする。プロットされた複数の地点が示す移動経路と、予想経路とを対比し、経路再検索を行うか否か判定することができる。

経路外れ判定処理（Ｓ１０５）が終了後、その結果に基づいて、利用者が予想経路から外れているか否かを判定する（Ｓ１０６）。Ｓ１０６における判定がＹｅｓであれば、通知提供処理（Ｓ１０７）に進む。

Ｓ１０６における判定がＮｏであれば、到着時刻取得部３０６が、位置情報取得部３０２が端末５から取得した最新の現在位置情報を、経路探索部３３に入力し、その応答として、端末５、すなわち、利用者がバス停に到着すると予想される到着予想時刻（以下、「利用者到着予想時刻」と記載する）を取得する（Ｓ１０８）。そして、通知提供部３０５は、利用者到着予想時刻（Ａ）がバス到着予想時刻（Ｂ）よりも早い（Ａ＜Ｂ）か否かに基づいて、利用者が間に合うか否かを判定する（Ｓ１０９）。Ｓ１０９における判定がＮｏであれば、利用者が間に合わないため、通知提供処理（Ｓ１０７）に進む。一方、Ｓ１０９における判定がＹｅｓであれば、Ｓ１０９における判定がＹｅｓであれば、利用者が間に合うため、通知提供処理（Ｓ１０７）には進まず、Ｓ１１０に進む。

通知提供部３０５は、利用者がバス停に到着したか否かを判定する（Ｓ１１０）。利用者がバス停に到着したか否かの判定は、図７に示すＳ２０７（後述）と同様である。Ｓ１１０における判定がＹｅｓであれば、処理を終了し、Ｎｏであれば、Ｓ１０５に戻る。

（通知提供処理）
図７は、第１の実施の形態に係る乗り合いバス予約システム１における通知提供処理の各処理を示すフローチャート図である。通知提供処理（図６中、Ｓ１０７）においては、図７に示すように、まず、通知提供部３０５が、端末５に対し、バス到着予想時刻の通知を指示する通知指示信号を送信する（Ｓ２０１）。次に、通知提供部３０５は、端末５に対し、車両の待機要否の確認を行う通知（以下、「待機要求確認通知」と記載する）を行うことを指示する通知指示信号を送信する（Ｓ２０２）。バス到着予想通知（Ｓ２０１）と待機要求確認通知（Ｓ２０２）との順番は限定されず、逆であってもよい。

その後、通知提供部３０５は、待機要求確認通知（Ｓ２０２）を実行後所定の時間ｔ１が経過したか否かを判定する（Ｓ２０３）。Ｓ２０３における判定がＮｏであれば、判定を繰り返す。Ｓ２０３における判定がＹｅｓであれば、通知提供部３０５は、端末５から待機要求信号を受信したか否かを判定する（Ｓ２０４）。Ｓ２０４における判定がＮｏであれば、通知提供処理を終了する。その後、図６に示す利用者支援処理が終了する。

Ｓ２０４における判定がＹｅｓであれば、待機指示処理部３０７がバス６へ待機指示信号を送信する（Ｓ２０５）。次いで、通知提供部３０５は、バス６の運行状況通知部６０８から停車確認通知（図５中、Ｓ１０）を受信したか否かに基づき、バス６がバス停に停車したか否か判定する（Ｓ２０６）。Ｓ２０６における判定がＮｏであれば、Ｓ２０６に戻る。したがって、Ｓ２０６は、バスが停車するまで繰り返えされる。一方、Ｓ２０６における判定がＹｅｓであれば、通知提供部３０５は、バス６がバス停に到着したことを示す通知（以下、「バス到着通知」と記載する）を行うことを指示する通知指示信号を送信する（Ｓ２１２）。

次いで、通知提供部３０５は、利用者がバス停に到着したか否かを判定する（Ｓ２０７）。利用者がバス停に到着したか否かは、例えば、端末５の最新の現在位置情報が示す地点がバス停から所定の範囲内であるか否かに基づいて判断することができるが、特に限定されない。Ｓ２０７における判定がＹｅｓであれば、Ｓ２１１（後述）に進む。

Ｓ２０７における判定がＮｏであれば、予約調整部３０８は、バス６から停車確認通知（図５中、Ｓ１０）を受信後、所定の時間ｔ２が経過したか否かを判定する（Ｓ２０８）。Ｓ２０８における判定がＮｏであれば、Ｓ２０７に戻る。Ｓ２０８における判定がＹｅｓであれば、予約調整部３０８は、乗車予約を取り消す（Ｓ２０９）。乗車予約が取り消された場合、通知提供部３０５は、端末５に対し、乗車予約を再び行う再予約を促す通知を指示する通知指示信号を送信する（Ｓ２１０）。その後、待機指示処理部３０７がバス６へ待機解除信号を送信（Ｓ２１１）し、通知提供処理を終了する。その後、図６に示す利用者支援処理が終了する。

（画面例）
図８は、第１の実施の形態に係る乗り合いバス予約システム１において端末５に提供される通知を含む画面例を示す模式図である。図８Ａは、バス到着予想時刻と、待機の要否の確認の両方を含む画面例である。図８Ａに示す画面８１は、図７に示すＳ２０１及びＳ２０２での通知指示信号に応じて、端末５の通知出力部５０２（図３参照）が、出力部５３の一例である表示部に表示させる。図８Ａに示すように、画面８１は、現在時刻８２、バス到着予想時刻８３、待機指示ボタン８４、及び、キャンセルボタン８５を含む。待機指示ボタン８４は、利用者の、待機が必要であるとの意志に基づき、利用者による操作を受け付けるためのユーザーインターフェイスである。例えば、表示部がタッチパネルディスプレイである場合、待機指示ボタン８４に対応するタッチパネルに指などを触れることにより、利用者の操作を受け付けることができる。操作受付部５０５により待機指示ボタン８４に対する操作が受け付けられると、待機要求処理部５０４が車両管理サーバ３の待機指示処理部３０７（図１、２参照）へ待機要求信号を送信し、端末５からの待機要求が行われる。

また、操作受付部５０５によりキャンセルボタン８５に対する操作が受け付けられた場合、乗車予約処理部５０１が予約調整部３０８に予約キャンセル要求信号を送信する。

図８Ａに示す画面８１では、バス到着予想時刻８３は、時刻で形式されているが、バス到着予想時刻と現在時刻との差、すなわち残り時間で表示してもよい。

図８Ｂは、利用者による再予約を促す画面例である。図８Ｂに示す画面８６は、図７に示すＳ２１０での通知指示信号に応じて、端末５の通知出力部５０２（図３参照）が表示部に表示させる。図８Ｂに示すように、画面８６は、乗車予約の取り消しを利用者に知らせるキャンセル通知８７を含む。

また、画面８６は、ＯＫボタン８８及び次回予約ボタン８９を含む。次回予約ボタン８９は、利用者により、再予約を行うとの意志に基づき、利用者による操作を受け付けるためのユーザーインターフェイスである。次回予約ボタン８９に対する操作が操作受付部５０５により受け付けられると、乗車予約処理部５０１による乗車予約が行われる。ＯＫボタン８８に対する操作が操作受付部５０５により受け付けられると、端末５での今回の乗車予約に対する一連の処理が終了する。

（具体例）
図９、１０は、第１の実施の形態に係る乗り合いバス予約システム１における利用者支援の具体例を示す説明図である。

以下の具体例では、車両管理サーバ３の経路探索部３３（図１参照）は、端末５の現在位置情報が示す地点とバス停との最短経路を予想経路とする。

図９は、利用者９１がバス停９２までに利用すると予想される予想経路が一つである場合を示す。予想経路に沿って利用者９１が移動していった場合、バス停９２から距離的にはいったん遠ざかり、かつ、その移動方向もバス停９２とには向っていない。このような場合であっても、第１の実施の形態に係る利用者支援処理では、予想経路から利用者が外れていないので、乗車予約は取り消されることがない。

予想経路が複数あってもよい。図１０は、利用者９１がバス停９２までに利用すると予想される予想経路が、最短経路とその次に短い経路（以下、「次点経路」と記載する）の２つである場合を示す。この例では、最短経路を利用者９１が利用した場合、到着予想時刻は現在時刻から５分後であり、次点経路を利用した場合、到着予想時刻は現在時刻から１０分後である。また、バス６のバス到着予想時刻は現在時刻から５分後である。したがって、利用者９１が最短経路を利用した場合にはバス到着予想時刻までにバス停９２に到着できる。一方、利用者９１が次点経路を利用した場合にはバス到着予想時刻までにバス停９２に間に合わない。この場合、バス６が到着したときに端末５（図１参照）にバス到着通知（図７に示すＳ１１１）が行われる。

図１０に示す例において、バス６のバス到着予想時刻が１０分後以上である場合、最短経路及び次点経路のいずれであっても、利用者はバス到着予想時刻までにバス停９２に到着できる。このため、利用者は最短経路及び次点経路のいずれの経路を選択しても、間に合う。しかし、バス到着予想時刻が５分後である場合は、利用者の選択肢は、最短経路しかない。そこで、図１０に示す分岐点が経路上に存在するとき、通知提供部３０５（図２参照）は、バス到着予想時刻と最短経路及び次点経路をそれぞれ利用したときの利用者の到着予想時刻とを比較する。そして、最短経路及び次点経路のいずれを利用しても利用者が間に合うと判定した場合には、通知提供部３０５は、分岐点において、その旨の通知を端末５で行なわせることが好ましい。

このように、予想経路は一つには限定されない。また、最短経路は予想経路の一例に過ぎず、他の基準に基づいて選択された経路を予想経路として用いることができる。

（ハードウェア構成）
なお、上記実施の形態の説明に用いた機能ブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線又は無線で接続し、これら複数の装置により実現されてもよい。

図１１は、第１の実施の形態に係るサーバ及び端末のハードウェア構成の一例を示す図である。車両管理サーバ３、端末５及びバス６の車載コンピュータなどを構成するコンピュータ装置１０００は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、センサ１００７、内部バス１００８などを含むコンピュータ装置１０００として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。ハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

例えば、プロセッサ１００１は１つだけ図示されているが、複数のプロセッサがあってもよい。また、処理は、１のプロセッサで実行されてもよいし、処理が同時に、逐次に、又はその他の手法で、１以上のプロセッサで実行されてもよい。

車両管理サーバ３、端末５、バス６などにおける各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信や、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュールやデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。

メモリ１００２は、記憶部３４、５４、６３（図２、３、４参照）の一例であり、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ROM）、ＥＥＰＲＯＭ（Electrically EPROM）、ＲＡＭ（Random Access Memory）、その他の適切な記憶媒体の少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明に係る乗車予約利用者支援装置を実現するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、記憶部３４、５４、６３（図２、３、４参照）の一例であり、コンピュータ読み取り可能な記録媒体であり、例えば、フレキシブルディスク、フロッピー（登録商標）ディスク、光磁気ディスク（例えば、コンパクトディスク（ＣＤ－ＲＯＭ（Compact Disc ROM）など）、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク）、リムーバブルディスク、ハードディスクドライブ、スマートカード、フラッシュメモリデバイス（例えば、カード、スティック、キードライブ）、磁気ストライプ、データベース、サーバ、その他の適切な記憶媒体の少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。

通信装置１００４は、通信部３５、５２、６２（図２、３、４参照）の一例であり、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。

入力装置１００５は、入力部５６、６９（図２、３、４参照）の一例であり、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウスなど）である。出力装置１００６は、出力部５３、７１（図２、３、４参照）の一例であり、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカーなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１やメモリ１００２などの各装置は、情報を通信するための内部バス１００８で接続される。

また、車両管理サーバ３、端末５及びバス６の車載コンピュータなどは、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

また、第１の実施の形態において、クラウド２（図１参照）と管制用端末７との間の通信に用いられるネットワークは、インターネット、モバイルネットワーク、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などの様々なネットワークを含む。なお、ネットワークは、無線、有線又はこれらの組み合わせで構成されてもよい。例えば、無線通信方式としては、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮ（例えば、ＩＥＥＥ８０２．１１規格に準拠）、ＬＴＥ（Long Term Evolution）、又はその他の無線通信方式を利用することができる。

また、移動体通信網４（図１参照）は、例えば、ＬＴＥ又はその他の無線通信方式を利用することができる。

以上説明したように、第１の実施の形態によれば、利用者がバス停に予想経路を用いて移動していない場合であっても、利用者の意志を確認し、それに沿った対処を行い、利便性を高めると共に、バス６の運行計画への影響を抑制できる。

例えば、利用者がバス停に到着していない場合に、バス到着予定時刻及びバス到着を通知することにより、利用者は、早い段階に次の便への予約の変更や乗り遅れないように移動を早めるなどの対処を行うことでき、かつ、バス６の定時運行性を確保できるようになる。

また、利用者がバス停に到着していない場合に、利用者にバス６の待機の要否を確認することにより、バス６の待機時間を最小化しつつ利用者がバス６に乗り遅れるのを防ぐことができる。

また、予約が自動的に取り消されることを利用者が確認でき、かつ、次回の予約をすぐに行うことができるので、利用者の便宜性を維持しつつ、バス６の定時運行性を確保できるようになる。

＜第２の実施の形態＞
次に、第２の実施の形態について、第１の実施の形態との相違を中心に説明する。以下の説明において、第１の実施の形態と同様の構成については、同一の符号を用い、説明を省略する。

図１２は、第２の実施の形態に係る車両管理サーバ３の予約管理部を示す機能ブロック図である。図１２に示す予約管理部３１は、記憶部３４が利用者データベース３４４及び補正係数表３４５を記憶している点で、第１の実施の形態と異なる。

利用者データベース３４４には、利用者ごとに利用者のバス停までの移動に関する属性情報が登録されている。属性情報は、例えば、年齢、妊娠の有無、身体障害者認定の有無、車いすの利用の有無、ベビーカーの利用の有無が含まれるが特に限定されない。

補正係数表３４５は、属性情報に基づいて所定時間α及びβを補正する補正係数Ｃを定めたものである。表１にその一例を示す。

第１の実施の形態では、通知提供部３０５は、図６に示すフローチャートのＳ１０９において、利用者到着予想時刻（Ａ）がバス到着予想時刻（Ｂ）よりも早い（Ａ＜Ｂ）か否かに基づいて、利用者が間に合うか否かを判定している。第２の実施形態では、利用者の実情に合わせてバス到着予想時刻を調整する。

図１３は、第２の実施の形態に係る乗り合いバス予約システム１における利用者支援処理の一部を示すフローチャート図である。図１３に示すように、Ｓ１０９’において、通知提供部３０５は、Ａ＜Ｂ＋（α×Ｃ）を満たすか否かを判定し、満たさない場合（Ｓ１０９’における判定がＮｏ）に通知提供処理（Ｓ１０７）を行わせる。

すなわち、利用者が利用者到着予想時刻の通りに到着できない場合を考慮し、バス到着予想時刻Ｂに所定時間αを加えている。所定時間αは例えば１０分のように任意に定めることができる。さらに、通知提供部３０５は、利用者の属性情報に基づいて、補正係数表３４５で定められた補正係数Ｃを取得し、これを用いて所定時間αを補正している。

これにより、バス到着予想時刻（Ｂ）よりも所定時間αの分だけ利用者が予想より遅くなると想定し、通知提供処理（Ｓ１０７）を行わせることができると共に、所定時間αには利用者の属性情報に応じた補正が行われる。この結果、利用者が高齢であったり、車いすを利用していたり、というような実情に合わせ、通知提供処理（Ｓ１０７）を行うか否か判定できるので、利用者の利便性をより向上できる。

また、第１の実施の形態では、図７に示す通知提供処理において、予約調整部３０８は、バス６から停車確認通知を受信後、所定の時間ｔ２が経過した場合に乗車予約を取り消す（Ｓ２０８、Ｓ２０９）。ここでの判定には、運行計画で定められたバス発車予定時刻は考慮に入っていない。

図１４は、第２の実施の形態に係る乗り合いバス予約システム１における通知提供処理の一部を示すフローチャート図である。図１４に示すように、Ｓ２０８’において、予約調整部３０８は、現在時刻Ｔｃ、発車予定時刻Ｔｄ、所定時間β、及び、補正係数Ｃとしたとき、Ｔｃ＞Ｔｄ＋（β×Ｃ）を満たすか否かを判定する。そして、満たされる場合に乗車予約の取り消し（Ｓ２０９）を行い、その後、待機指示処理部３０７が、待機解除送信（図７中、Ｓ２１１）を行う。

すなわち、発車予定時刻Ｔｄに所定時間βを加えることにより、発車予定時刻Ｔｄになったらすぐに乗車予約が取り消し（Ｓ２０９）されることがないように調整を行っている。所定時間βは例えば１０分のように任意に定めることができる。さらに、予約調整部３０８は、利用者の属性情報に基づいて、補正係数表３４５で定められた補正係数Ｃを取得し、それを用いて所定時間βを補正している。

これにより、発車予定時刻（Ｔｄ）から少なくとも所定時間β×補正係数Ｃの分だけ経過した後、乗車予約の取り消し（Ｓ２０９）が行われ、待機指示が解除（Ｓ２１１）されて、バス６がバス停から発車できるようになる。このため、発車予定時刻（Ｔｄ）からの発車遅延を必要最低限に抑えられると共に、所定時間βには利用者の属性情報に応じた補正が行われる。この結果、利用者が高齢であったり、車いすを利用していたり、というような実情に合わせ、通知提供処理（Ｓ１０７）を行うか否か判定できるので、利用者の利便性をより向上でき、且つ、バス６の定時運行性を高めることができる。

また、第２の実施の形態では、経路外れ（図６中、Ｓ１０６における判定がＹｅｓ）があった場合、及び、利用者がバス６の到着までに間に合わない場合（Ｓ１０９における判定がＮｏ）には、バス６の待機が発車予定時刻（Ｔｄ）から所定時間β×補正係数Ｃの分まで行われる。したがって、利用者の実情に合わせ、バス６の待機時間が調整されるので、利用者の便利性をより向上できる。

ここで、所定時間βは、バス６の、利用者がバス停に到着するまでの待ち時間に相当する。そこで、式（１）に示すように、所定時間βの積算値、すなわち累積時間が、１回の運行サイクル（始発バス停から終着バス停まで）で上限時間γ未満になるように調整することが好ましい。

これにより、利用者による待機要求が長く継続した場合であっても、運行サイクルにおける運行管理と車両制御を調節することで遅れを取り戻すことができるため、バス６の定時運行性を確保することができる。

第２の実施の形態では、所定時間α、βを利用者の属性情報に従って補正しているが、他の情報（例えば、バス６の運行経路の交通混雑状況）を加えて補正してもよい。

以上説明したように、第２の実施の形態によれば、第１の実施の形態と同様の効果を奏すると共に、利用者の属性に応じて必要な利用者支援を行うことで、利用者の利便性をより一層高め、かつ、バス６の運行計画への影響を抑制できる。

また、第２の実施の形態によれば、利用者の年齢などに合わせ、バス６の待機時間を延長できると共に、上限時間γ内で調整することにより、バス６の運行計画への影響を最小化できる。

＜第３の実施の形態＞
次に、第３の実施の形態について、第１、第２の実施の形態との相違を中心に説明する。以下の説明において、第１、第２の実施の形態と同様の構成については、同一の符号を用い、説明を省略する。

第１、第２の実施の形態では、図６のＳ１０３で端末５（図１参照）の現在位置情報を取得できなかった場合に、利用者支援処理を終了しているが、第３の実施の形態では、このような場合にも可能な限り、利用者の支援を行う点で相違する。

図１５は、第３の実施の形態に係る乗り合いバス予約システム１における利用者支援処理の一部を示すフローチャート図である。Ｓ１０３で端末５の現在位置情報を取得できないと判定した場合、通知提供部３０５は、バス６の運行状況通知部６０８から停車確認通知（図５中、Ｓ１０）を受信したか否かに基づき、バス６がバス停に停車したか否か判定する（Ｓ３０１）。Ｓ３０１における判定がＮｏであれば、Ｓ３０１に戻る。したがって、Ｓ３０１は、バスが停車するまで繰り返えされる。

次いで、通知提供部３０５は、バス到着通知を行うことを指示する通知指示信号を送信する（Ｓ３０２）。その後、予約調整部３０８は、図１４に示すＳ２０８’と同様に、Ｔｃ＞Ｔｄ＋（β×Ｃ）を満たすか否かを判定する（Ｓ３０３）。そして、満たされる場合に乗車予約の取り消し（Ｓ３０４）を行い、その後、待機指示処理部３０７が、待機解除送信（Ｓ３０５）を行い、処理を終了する。ここで、乗車予約の取り消し（Ｓ３０４）及び待機解除送信（Ｓ３０５）は、図７中のＳ２０９及びＳ２１１と同様の処理である。なお、乗車予約の取り消し（Ｓ３０４）が行われた後、通知提供部３０５は、端末５に対し、乗車予約を再び行う再予約を促す通知を指示する通知指示信号を送信してもよい（図７中のＳ２１０参照）。

これにより、端末５から現在位置情報取得できず、利用者の位置が検出できない場合、待機指示がどこから送信されているのか確認できない、又は、バス停に到着している可能性があるため、待機指示は行わずにバス到着通知のみを行うことができる。また、端末５から現在位置情報を取得できない場合であっても、バス６による待機が行われる。また、発車予定時刻（Ｔｄ）から少なくとも所定時間β×補正係数Ｃの分だけ経過した後、乗車予約の取り消し（Ｓ２０９）が行われ、待機指示が解除（Ｓ２１１）されて、バス６がバス停から発車できるようになる。

なお、端末５（図１参照）から現在位置情報を取得できない場合には、以下のような状況が含まれる。
（１）端末５と車両管理サーバ３との間のネットワーク回線（移動体通信網４等）が安定していない。
（２）端末５がＧＰＳ衛星８からＧＰＳ信号を受信できない。
（３）端末５の電源が切られている、又は、端末５が電波の届かないところにある。
（４）端末５の現在位置情報が示す地点の誤差範囲が、所定の範囲（例えば、２００ｍ）以上である。
（５）端末５の現在位置情報が示す地点が安定していない（例えば、所定時間内に１００ｍ以上の移動を繰り返す）。

例えば、（１）のようにネットワーク回線が安定していない状況であっても、その後、ネットワーク回線が安定し、通信が復帰したときに通知が行われるようにすることが好ましい。例えば、本実施の形態において、図６を参照して説明したように、通知提供部３０５は、バス６から停車確認通知（図５中、Ｓ１０）を受信したか否かを判定（Ｓ１１０）し、判定がＹｅｓであれば、通知提供部３０５は、バス到着通知を行うことを指示する通知指示信号を送信する（Ｓ１１１）。これにより、通信が復帰したときに、利用者はバス６がバス停に到着したことを知ることができるので、利用者の利便性がより向上する。

このように、端末５から現在位置情報を取得できない場合であっても、それを理由にただちに乗車予約を取り消し、また、バス６を必要以上に待機させるという不都合な事態が発生するのを回避できる。

以上説明したように、第３の実施の形態によれば、第１、第２の実施の形態と同様の効果を奏すると共に、端末５が通信できない状況であっても利用者の利便性を高め、かつ、バス６の運行計画への影響を最小限に抑制できる。

例えば、位置情報取得部３０２（図２参照）により端末５の現在位置情報を取得できない場合、待機指示処理部３０７がバス６に待機指示信号を送信することにより、端末５が通信できない場合でもバス６を待機させることができる。

また、予約調整部３０８が、利用者の属性情報に基づいて、所定時間βを補正係数Ｃで補正することにより、利用者の実情に合わせて待機時間を確保しながら、必要以上に待機が延長されることを抑制できる。

また、本実施の形態及び変形例を説明したが、本発明の他の実施の形態として、上記実施の形態及び変形例を全体的又は部分的に組み合わせたものでもよい。

また、本発明の実施の形態は上記の実施の形態に限定されるものではなく、本発明の技術的思想の趣旨を逸脱しない範囲において様々に変更、置換、変形されてもよい。更には、技術の進歩又は派生する別技術によって、本発明の技術的思想を別の仕方で実現することができれば、その方法を用いて実施されてもよい。従って、特許請求の範囲は、本発明の技術的思想の範囲内に含まれ得る全ての実施形態をカバーしている。

例えば、上記実施の形態においては、乗車予約利用者支援装置を、クラウド２（図１参照）に配置された車両管理サーバ３の一部（予約管理部３１）により実現しているが、例えば、バス６に搭載されるカーナビゲーション装置等のような車載装置、利用者が利用するスマートフォン等の移動体通信装置、オンプレミスに配置されたサーバ、管制担当者が利用するパーソナルコンピュータのような情報処理装置により実現してもよい。

また、上記実施の形態においては、車両管理サーバ３が、予約管理部３１、運行管理部３２及び経路探索部３３の機能をすべて実現しているが、それぞれの機能を別々のサーバで実現し、それらが連動して、車両管理サーバ３と同等の機能を実現することも、本発明の実施の形態の一つである。

以上説明したように、本発明は、利用者の利便性を高め、かつ、車両運行計画の遅延を防止できるという効果を有し、特に、自動運転乗り合いバスに有用である。

１ 乗り合いバス予約システム
３ 車両管理サーバ
５ 端末
６ バス
７ 管制用端末
８ ＧＮＳＳ衛星
３１ 予約管理部
３２ 運行管理部
３３ 経路探索部
３４、５４、６３ 記憶部
３５、５２、６２ 通信部
５１、６１ 演算部
５３、７１ 出力部
５５、６８ ＧＮＳＳ受信部
５６、６９ 入力部
６４ 駆動部
６５ 制動部
６６ 操舵部
６７ センサ
７０ ドア開閉駆動部
３０１ 予約情報取得部
３０２ 位置情報取得部
３０３ 経路情報取得部
３０４ 経路外れ判定部
３０５ 通知提供部
３０６ 到着時刻取得部
３０７ 待機指示処理部
３０８ 予約調整部
３０９ 乗車予約作成部
５０１ 乗車予約処理部
５０２ 通知出力部
５０３、６０３ 現在位置出力部
５０４ 待機要求処理部
５０５ 操作受付部
６０１ 自動運転制御部
６０２ ドア開閉制御部
６０４ 駆動制御部
６０５ 制動制御部
６０６ 操舵制御部
６０７ 会話制御部
６０８ 運行状況通知部

Claims (11)

1. 少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部と、
   前記端末の位置情報を取得する位置情報取得部と、
   前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部と、
   前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する経路外れ判定部と、
   前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる通知提供部と、
   を具備し、
   前記通知は、前記車両が前記乗車予定地に到着する車両到着予想時刻を含むことを特徴とする乗車予約利用者支援装置。
2. 前記予想経路は、前記地点から前記乗車予定地までの最短経路を含むことを特徴とする請求項１に記載の乗車予約利用者支援装置。
3. 前記通知は、前記利用者に前記車両の待機要否の確認を含むことを特徴とする請求項１又は請求項２に記載の乗車予約利用者支援装置。
4. 前記位置情報取得部が取得した、前記位置情報に基づいて前記利用者が前記乗車予定地に到着する利用者到着予想時刻を取得する到着時刻取得部をさらに具備し、
   前記経路外れ判定部は、前記利用者到着予想時刻が、前記車両が前記乗車予定地に到着する車両到着予想時刻よりも遅い場合、前記端末に前記利用者への前記通知を提供させることを特徴とする請求項１から請求項３のいずれかに記載の乗車予約利用者支援装置。
5. 前記車両が待機している状態において、前記車両の前記乗車予定地からの発車予定時刻から所定時間が経過した後に、前記利用者による乗車予約を取り消す予約調整部をさらに具備することを特徴とする請求項１から請求項４のいずれかに記載の乗車予約利用者支援装置。
6. 前記予約調整部は、前記利用者の属性情報に基づいて前記所定時間を調整することを特徴とする請求項５に記載の乗車予約利用者支援装置。
7. 前記予約調整部は、前記所定時間の累積時間が１回の運行サイクル内で上限時間未満になるように前記所定時間を調整することを特徴とする請求項５又は請求項６に記載の乗車予約利用者支援装置。
8. 前記乗車予約の取り消しがあった場合に、前記通知は、前記利用者に前記乗車予約の取り消しを知らせると共に再予約を促す内容を含むことを特徴とする請求項５から請求項７のいずれかに記載の乗車予約利用者支援装置。
9. 前記位置情報取得部により前記端末の前記位置情報を取得できない場合、前記車両に待機を指示する待機指示処理部をさらに具備する請求項５から請求項８のいずれかに記載の乗車予約利用者支援装置。
10. 前記位置情報取得部により前記端末の前記位置情報を取得できない場合、前記通知提供部は、前記車両が乗車予約地に到着したこと示す通知を前記端末に提供することを特徴とする請求項５から請求項９のいずれかに記載の乗車予約利用者支援装置。
11. 少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する工程と、
    前記端末の位置情報を取得する工程と、
    前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する工程と、
    前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する工程と、
    前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる工程と、
    を具備し、
    前記通知は、前記車両が前記乗車予定地に到着する車両到着予想時刻又は前記車両到着予想時刻までの残り時間を含むことを特徴とする乗車予約利用者支援方法。

Images