(57)【要約】【課題】  マルチモーダル経路の監視処理のための処理負荷を適切に分散する。【解決手段】  本発明は、携帯端末と通信する経路探索装置を備える経路探索システムに関する。前記経路探索装置は、ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、受信した前記探索要求に応じて、徒歩ルート、非公共ルート及び公共ルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部と、を有する。前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含める。【選択図】      図１
2018096810.tif 000002
【特許請求の範囲】
【請求項１】
携帯端末と通信する経路探索装置を備える経路探索システムであって、
前記経路探索装置は、
ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、
受信した前記探索要求に応じて、下記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部と、を有しており、
前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含める経路探索システム。
徒歩ルート：ユーザが徒歩により移動するルート
非公共ルート：ユーザが非公共車両を利用して移動するルート
公共ルート：ユーザが公共交通機関を利用して移動するルート
【請求項２】
前記携帯端末は、前記徒歩ルートの通行スケジュールに基づいて、自機が前記徒歩ルートを予定通りに移動しているか否かを監視する請求項１に記載の経路探索システム。
【請求項３】
前記携帯端末は、監視結果が否定的である場合に、前記探索処理を再実行させるためのリルート要求を前記経路探索装置に送信する請求項２に記載の経路探索システム。
【請求項４】
前記非公共車両に搭載された車載端末を更に備え、
前記車載端末には、自車両が通行する前記非公共ルートの通行スケジュールと、自車両の識別情報が予め通知されており、
前記車載端末は、前記非公共ルートの通行スケジュールに基づいて、自車両が前記非公共ルートを予定通りに移動しているか否かを監視する請求項１〜請求項３のいずれか１項に記載の経路探索システム。
【請求項５】
前記車載端末は、監視結果が否定的である場合に、前記探索処理を再実行させるためのリルート要求を前記経路探索装置に送信する請求項４に記載の経路探索システム。
【請求項６】
前記制御部は、前記公共ルートの通行スケジュールに基づいて、前記公共交通機関が前記公共ルートを予定通りに移動しているか否かを監視する請求項１〜請求項５のいずれか１項に記載の経路探索システム。
【請求項７】
前記制御部は、監視結果が否定的である場合に、当該公共交通機関の識別情報に対応するすべての前記ユーザの識別情報について、前記探索処理を再実行する請求項６に記載の経路探索システム。
【請求項８】
前記ユーザが前記公共ルートを予定通りに移動しているか否かの監視については、前記経路探索装置により実行され、
前記ユーザが前記公共ルート以外の前記ルートを予定通りに移動しているか否かの監視については、前記携帯端末又は前記非公共車両の車載端末により実行される請求項１〜請求項６のいずれか１項に記載の経路探索システム。
【請求項９】
前記制御部は、前記携帯端末又は前記車載端末からのリルート要求を前記通信部が受信した場合に、前記リルート要求に含まれる前記ユーザの識別情報又は前記移動手段の識別情報に対応する前記ユーザの識別情報について、前記探索処理を再実行する処理であるリルートを実行する請求項８に記載の経路探索システム。
【請求項１０】
前記制御部は、前記車載端末から前記非公共ルートの終点通過時刻を経過してもリルート要求がなく、かつ、当該非公共ルートの完了通知がない場合に、当該非公共ルートを予定通りに通過したか否かの確認要求を前記携帯端末に送信する請求項８又は請求項９に記載の経路探索システム。
【請求項１１】
携帯端末と通信する経路探索装置であって、
ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、
受信した前記探索要求に応じて、下記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部と、を有しており、
前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含める経路探索装置。
徒歩ルート：ユーザが徒歩により移動するルート
非公共ルート：ユーザが非公共車両を利用して移動するルート
公共ルート：ユーザが公共交通機関を利用して移動するルート
【請求項１２】
携帯端末と通信する経路探索装置が実行する経路探索方法であって、
ユーザの識別情報を含む探索要求を前記携帯端末から受信するステップと、
受信した前記探索要求に応じて、下記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記ユーザの前記携帯端末に送信するステップと、
前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含めるステップと、を含む経路探索方法。
徒歩ルート：ユーザが徒歩により移動するルート
非公共ルート：ユーザが非公共車両を利用して移動するルート
公共ルート：ユーザが公共交通機関を利用して移動するルート
【請求項１３】
コンピュータを携帯端末と通信する経路探索装置として機能させるためのコンピュータプログラムであって、前記コンピュータを、
ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、
受信した前記探索要求に応じて、下記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部、として機能させ、
前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含めるコンピュータプログラム。
徒歩ルート：ユーザが徒歩により移動するルート
非公共ルート：ユーザが非公共車両を利用して移動するルート
公共ルート：ユーザが公共交通機関を利用して移動するルート
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチモーダル経路をユーザに提供する経路探索システム、経路探索装置、経路探索方法、及びコンピュータプログラムに関する。
【背景技術】
【０００２】
特許文献１には、移動手段が異なる複数のルートから構成されるマルチモーダル経路（移動予定経路）を、ユーザの移動端末に提供する経路探索システムが記載されている。
特許文献１の経路探索システムでは、サーバコンピュータよりなる経路探索装置が、移動予定経路を移動端末が予定通りに通行できるか否かを監視し、予定通りに通行できない事情が生じた場合に、最初に指定された探索条件にて新たな移動予定経路を算出し、新たな移動予定経路を移動端末に送信するようになっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−１７７３９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来の経路探索システムでは、移動端末が移動予定経路を予定通りに通行できるか否かの監視処理を、経路探索装置が一括して実行する。従って、監視対象である移動予定経路の数（ユーザ数）が多くなるほど、移動予定経路の監視処理に多大な処理負荷が必要になるという問題がある。
本発明は、かかる従来の問題点に鑑み、マルチモーダル経路の監視処理のための処理負荷を適切に分散できる経路探索システム等を提供することを目的とする。
【課題を解決するための手段】
【０００５】
（１）  本発明の一態様に係る経路探索システムは、携帯端末と通信する経路探索装置を備える経路探索システムであって、前記経路探索装置は、ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、受信した前記探索要求に応じて、下記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部と、を有しており、前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含める。
【０００６】
徒歩ルート：ユーザが徒歩により移動するルート
非公共ルート：ユーザが非公共車両を利用して移動するルート
公共ルート：ユーザが公共交通機関を利用して移動するルート
【０００７】
（１１）  本発明の一態様に係る経路探索装置は、携帯端末と通信する経路探索装置であって、ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、受信した前記探索要求に応じて、上記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部と、を有しており、前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含める。
【０００８】
（１２）  本発明の一態様に係る経路探索方法は、携帯端末と通信する経路探索装置が実行する経路探索方法であって、ユーザの識別情報を含む探索要求を前記携帯端末から受信するステップと、受信した前記探索要求に応じて、上記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記ユーザの前記携帯端末に送信するステップと、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記携帯端末の識別情報と対応付けた当該ユーザの識別情報と、を含めるステップと、を含む。
【０００９】
（１３）  本発明の一態様に係るコンピュータプログラムは、コンピュータを携帯端末と通信する経路探索装置として機能させるためのコンピュータプログラムであって、前記コンピュータを、ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、受信した前記探索要求に応じて、上記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部、として機能させ、前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含める。
【発明の効果】
【００１０】
本発明によれば、マルチモーダル経路の監視処理のための処理負荷を適切に分散することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係る経路探索システムの全体構成図である。
【図２】携帯端末と管理装置との間の通信手順の一例を示すシーケンス図である。
【図３】徒歩ルートでのリルート判定処理の一例を示すフローチャートである。
【図４】非公共ルートでのリルート判定処理の一例を示すフローチャートである。
【図５】ユーザＩＤごとのリルート判定処理の一例を示すフローチャートである。
【図６】公共ＩＤごとのリルート判定処理の一例を示すフローチャートである。
【図７】ルート情報Ａに含まれるルートのイメージ図である。
【図８】別のルート情報Ｂに含まれるルートのイメージ図である。
【発明を実施するための形態】
【００１２】
＜本発明の実施形態の概要＞
以下、本発明の実施形態の概要を列記して説明する。
（１）  本実施形態の経路探索システムは、携帯端末と通信する経路探索装置を備える経路探索システムであって、前記経路探索装置は、ユーザの識別情報を含む探索要求を前記携帯端末から受信し、前記探索要求に対応する探索結果を前記ユーザの前記携帯端末に送信する通信部と、受信した前記探索要求に応じて、下記のルートの少なくとも１つを含むマルチモーダル経路の探索処理を実行し、その探索結果である前記マルチモーダル経路を前記通信部に送信させる制御部と、を有する。
【００１３】
また、前記制御部は、前記マルチモーダル経路のデータ内容に、前記ルートの通行スケジュールと、前記ルートの通行に用いる移動手段の識別情報であって、前記ユーザの識別情報と対応付けた当該移動手段の識別情報と、を含める。
徒歩ルート：ユーザが徒歩により移動するルート
非公共ルート：ユーザが非公共車両を利用して移動するルート
公共ルート：ユーザが公共交通機関を利用して移動するルート
【００１４】
本実施形態の経路探索システムによれば、制御部が、マルチモーダル経路のデータ内容に、ルートの通行スケジュールと、ルートの通行に用いる移動手段の識別情報であって、ユーザの識別情報と対応付けられた当該移動手段の識別情報とを含める。
このため、ユーザが各ルートを予定通りに移動しているか否かの監視処理を、携帯端末などのローカル端末に実行させることができ、マルチモーダル経路の監視処理のための処理負荷を適切に分散できる。従って、経路探索装置の処理負荷を軽減できる。
【００１５】
（２）  本実施形態の経路探索システムにおいて、前記携帯端末は、前記徒歩ルートの通行スケジュールに基づいて、自機が前記徒歩ルートを予定通りに移動しているか否かを監視すればよい。
その理由は、徒歩ルートにおいて経路探索装置と通信する通信端末は携帯端末のみであるから、徒歩ルートの監視処理を携帯端末に実行させることが好ましいからである。
【００１６】
（３）  本実施形態の経路探索システムにおいて、前記携帯端末は、監視結果が否定的である場合に、前記探索処理を再実行させるためのリルート要求を前記経路探索装置に送信することが好ましい。
このようにすれば、ユーザが徒歩ルートを予定通りに移動できなかった場合でも、経路探索装置が新たに生成した次のマルチモーダル経路を携帯端末が受信することができ、今後に有効な経路情報をユーザに提供することができる。
【００１７】
（４）  本実施形態の経路探索システムにおいて、前記非公共車両に搭載された車載端末を更に備え、前記車載端末には、自車両が通行する前記非公共ルートの通行スケジュールと、自車両の識別情報が予め通知されている場合には、前記車載端末は、前記非公共ルートの通行スケジュールに基づいて、自車両が前記非公共ルートを予定通りに移動しているか否かを監視すればよい。
その理由は、非公共ルートの監視処理を車載端末が実行すれば、その監視処理を携帯端末が実行する必要がなくなり、携帯端末の充電残量の低下を抑制できるからである。
【００１８】
（５）  本実施形態の経路探索システムにおいて、前記車載端末は、監視結果が否定的である場合に、前記探索処理を再実行させるためのリルート要求を前記経路探索装置に送信することが好ましい。
このようにすれば、ユーザが非公共ルートを予定通りに移動できなかった場合でも、経路探索装置が新たに生成した次のマルチモーダル経路を携帯端末が受信することができ、今後に有効な経路情報をユーザに提供することができる。
【００１９】
（６）  本実施形態の経路探索システムにおいて、前記制御部は、前記公共ルートの通行スケジュールに基づいて、前記公共交通機関が前記公共ルートを予定通りに移動しているか否かを監視することが好ましい。
その理由は、公共交通機関には複数のユーザが搭乗する可能性があるので、１つの公共ルートを監視すれば、当該公共ルートを利用する複数のユーザについてリルートの必要性を判断できるからである。
【００２０】
（７）  従って、前記制御部は、監視結果が否定的である場合に、当該公共交通機関の識別情報に対応するすべての前記携帯端末の識別情報について、前記探索処理を再実行することが好ましい。
【００２１】
（８）  本実施形態の経路探索システムにおいて、前記ユーザが前記公共ルートを予定通りに移動しているか否かの監視については、前記経路探索装置により実行され、前記ユーザが前記公共ルート以外の前記ルートを予定通りに移動しているか否かの監視については、前記携帯端末又は前記非公共車両の車載端末により実行されることが好ましい。
このようにすれば、マルチモーダル経路に含まれるルートの監視主体を適切に分担させることができる。
【００２２】
（９）  本実施形態の経路探索システムにおいて、前記制御部は、前記携帯端末又は前記車載端末からのリルート要求を前記通信部が受信した場合に、前記リルート要求に含まれる前記ユーザの識別情報又は前記移動手段の識別情報に対応する前記ユーザの識別情報について、前記探索処理を再実行する処理であるリルートを実行することが好ましい。
このようにすれば、経路探索装置が監視主体ではない徒歩ルート又は非公共ルートおいて、ユーザが予定通りに移動できない事態が発生した場合でも、経路探索装置がリルートを実行できるようになる。
【００２３】
（１０）  本実施形態の経路探索システムにおいて、前記制御部は、前記車載端末から前記非公共ルートの終点通過時刻を経過してもリルート要求がなく、かつ、当該非公共ルートの完了通知がない場合に、当該非公共ルートを予定通りに通過したか否かの確認要求を前記携帯端末に送信することが好ましい。
このようにすれば、一時的な通信不良などにより車載端末が経路探索装置と通信できなかった場合でも、ユーザが非公共ルートを予定通りに通過したかの監視処理を、携帯端末に実行させることができる。
【００２４】
（１１）  本実施形態の経路探索装置は、上述の（１）〜（１０）に記載の経路探索システムを構成する経路探索装置に関する。
従って、本実施形態の経路探索装置は、上述の（１）〜（１０）に記載の経路探索システムと同様の作用効果を奏する。
【００２５】
（１２）  本実施形態の経路探索方法は、上述の（１）〜（１０）に記載の経路探索システムを構成する経路探索装置が実行する経路探索方法に関する。
従って、本実施形態の経路探索装置は、上述の（１）〜（１０）に記載の経路探索システムと同様の作用効果を奏する。
【００２６】
（１３）  本実施形態のコンピュータプログラムは、上述の（１）〜（１０）に記載の経路探索システムを構成する経路探索装置としてコンピュータを機能させるコンピュータプログラムに関する。
従って、本実施形態のコンピュータプログラムは、上述の（１）〜（１０）に記載の経路探索システムと同様の作用効果を奏する。
【００２７】
＜本発明の実施形態の詳細＞
以下、図面を参照して、本発明の実施形態の詳細を説明する。なお、以下に記載する実施形態の少なくとも一部を任意に組み合わせてもよい。
【００２８】
〔経路探索システムの全体構成〕
図１は、本発明の実施形態に係る経路探索システムの全体構成図である。
図１に示すように、本実施形態の経路探索システムは、交通管制センターなどに設置された、経路探索機能を有する管理装置（経路探索装置）１と、複数の携帯端末２と、複数の車載端末３とを備える。管理装置１と携帯端末２及び車載端末３は、インターネットなどよりなる公衆通信網４を経由して通信可能である。
【００２９】
本実施形態の管理装置１は、登録会員（ユーザ）が所有する携帯端末２のユーザＩＤを予め記憶している。ユーザＩＤは、ＭＡＣアドレスなどのハードウェアに一意な物理アドレスを利用してもよいし、管理装置１が独自に定義した識別値を用いてもよい。例えば、管理装置１は、本システム利用登録申請をユーザから受けた時に、当該ユーザに固有のＩＤを割り当て記憶することができる。
管理装置１は、携帯端末２から受信した探索要求に応じて、その携帯端末２に対応するユーザＩＤに対して、ユーザ自身の車両や公共交通機関などの複数の移動手段を組み合わせた場合の最適な経路を探索し、その探索結果を携帯端末２に返信する、経路情報の提供サービスを実行可能である。
【００３０】
本明細書において「車両」とは、自動車、原動機付き自転車、軽車両及びトロリーバスなどのことをいう。「公共車両」とは、路線バス、電車などの複数人の乗り合わせが予定された公共性の高い車両のことをいう。「公共交通機関」とは、公共車両に加えて、航空機及び客船などの、車両以外の公共性の高い移動手段を加えたものをいう。
「非公共車両」とは、ユーザが所有する車両（以下、「自車両」という。）などの公共性がない車両、及び、タクシー、レンタカー、乗り合いタクシーなどの、移動先を当該車両の搭乗者自らが指定し得るような公共性が低い車両のことをいう。ユーザ以外の個人が所有し、当該個人が第三車への利用を認めた車両を含んでもよい。
【００３１】
携帯端末２は、管理装置１と通信可能なユーザが携帯する端末装置である。携帯端末２は、管理装置１から受信した探索結果を利用するためのアプリケーションがインストールされた、例えばスマートフォン、タブレット端末、ノートパソコンなどよりなる。
車載端末３は、管理装置１と通信可能な非公共車両に搭載された端末装置である。車載端末３は、管理装置１から受信した探索結果を利用するためのアプリケーションがインストールされた、例えばカーナビゲーション装置よりなる。
【００３２】
管理装置１は、公衆通信網４を介して交通機関の予約管理サーバ５と通信可能である。管理装置１は、予約管理サーバ５に対して、ユーザが利用する交通機関の搭乗予約（例えば、タクシーの配車予約、電子チケットの手配など）を実行することができる。
管理装置１は、公衆通信網４を介して交通機関の運行管理サーバ６と通信可能である。管理装置１は、運行管理サーバ６との通信により、タクシーなどの交通機関及び公共交通機関の現状の運行スケジュールを取得することができる、
【００３３】
管理装置１は、公衆通信網４を介して気象情報を提供する気象サーバ７と通信可能である。管理装置１は、気象サーバ７との通信により、所定地域における現時点及びそれ以降の気象情報を取得することができる、
管理装置１は、公衆通信網４を介してイベント情報を提供する催事サーバ８と通信可能である。管理装置１は、催事サーバ８との通信により、所定地域で開催される現時点及びそれ以降のイベント情報を取得することができる。
【００３４】
管理装置１は、ＦＭ多重放送で配信されるＶＩＣＳ（「ＶＩＣＳ」は登録商標である。）情報を道路交通情報センター（図示せず）から取得することができる。
管理装置１は、電話回線などの専用通信線を介して、所定の管轄エリアに含まれる交通信号制御機９と通信可能に接続されている。管理装置１は、管轄エリアに属する交差点の交通信号機について、交通状況に応じた信号制御パラメータ（スプリット、サイクル長及びオフセットなど）を変更する交通感応制御などを実行可能である。
【００３５】
〔管理装置の内部構成〕
管理装置１は、サーバコンピュータよりなる。図１に示すように、管理装置１は、通信部１１、記憶部１２、及び制御部１３を備える。
通信部１１は、公衆通信網４との有線通信に必要となる、増幅回路、周波数変換回路、変調及び復調回路などを有する通信機よりなる。通信部１１は、交通信号制御機９との専用通信線を介した通信にも対応している。
【００３６】
記憶部１２は、磁気記憶媒体又はフラッシュメモリなどの不揮発性記憶媒体よりなる。制御部１３は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリなどを備えたマイクロコンピュータよりなる。
制御部１３は、記憶部１２に記録されたコンピュータプログラムをＣＰＵが読み出して実行することにより、各種の処理・機能を実現する。制御部１３が実行する処理には、例えば、マルチモーダル経路の探索処理、タクシーや公共交通機関の手配処理などがある。
【００３７】
記憶部１２は、交通情報データベース、地図データベース、運行データベースなどを備える。交通情報データベースは、道路リンクごとに、当該道路の現在の混雑度合いの情報を含むデータである。
制御部１３は、道路交通情報センターから受信するＶＩＣＳ情報などに基づいて、交通情報データベースに蓄積する交通情報（渋滞情報など）を逐次更新する。
【００３８】
地図データベースには、道路データと施設データが含まれる。道路データには、リンクの位置情報と種別情報、ノードの位置情報と種別情報、及び、ノードとリンクの接続関係などの、道路構成に関するデータが含まれる。
施設データには、施設ごとの施設情報が含まれる。施設情報には、施設の名称、位置情報、土地地番、施設の種類などのデータが含まれる。施設の種類には、例えば、官公庁、公園、学校、駐車場、コンビニエンスストア、レストラン、及び公共交通機関の乗降場所（例えば、駅、バス停、空港、船着き場）などが含まれる。
【００３９】
運行データベースには、公共交通機関（例えば、電車、バス、飛行機、船舶など）の定常的な運行状態を示す運行スケジュールが含まれる。運行スケジュールには、公共交通機関の路線ごとに、当該路線の名称のデータや、当該路線において運行される各便の乗降施設における到着時刻及び出発時刻のデータが含まれる。
制御部１３は、所定時間（例えば１分）ごとに運行管理サーバ６にアクセスし、運行スケジュールの変更や遅延時間などを逐次更新する。
【００４０】
マルチモーダル経路の探索処理とは、記憶部１２に含まれるデータベースに蓄積された各種のデータを用いて、ユーザにとって最適なマルチモーダル経路の候補を少なくとも１つ算出する処理のことをいう。
マルチモーダル経路とは、利用する移動手段が異なる複数のルートの組み合わせを許容する経路のことである。本実施形態では、次の各ルートがマルチモーダル経路の構成要素となり得る。
【００４１】
１）徒歩ルート：ユーザが徒歩により移動するルートである。自転車などの車載端末３を有しない移動手段を利用する場合も、徒歩ルートに含まれる。
２）非公共ルート：ユーザが非公共車両（自車両、タクシー、レンタカー、乗り合いタクシーなど）を利用して移動するルートのことである。
３）公共ルート：ユーザが公共車両などの公共交通機関（路線バス、電車、航空機、客船など）を利用して移動するルートのことである。
【００４２】
マルチモーダル経路の探索処理は、例えば、地図データベースに含まれる道路リンク（徒歩ルート又は非公共ルートの構成単位）と、運行データベースに含まれる路線（公共ルートの構成単位）とを構成リンクとして、例えばダイクストラ法などにより、複数の候補経路のコストを比較することにより、所定のコストが最も低い経路を最適な経路とするアルゴリズムを採用する。
【００４３】
所定のコストには、区間の長さ（移動距離）、所要時間、料金（区間を通行する際の料金。例えば、電車の運賃）のうちいずれか１つを採用することができる。これら３つの量から算出される所定のパラメータ（例えばｋ１×長さ＋ｋ２×所要時間＋ｋ３×料金、ただし、ｋ１〜ｋ３は重み）を、コストとして採用してもよい。
かかる探索処理による算出される最適な経路は、すべてが非公共ルートになる場合もあるし、徒歩ルート、非公共ルート及び公共ルートを含む経路になる場合もある。
【００４４】
〔携帯端末の内部構成〕
図１に示すように、携帯端末２は、無線通信部２１、位置検出部２２、表示部２３、操作部２４、記憶部２５、及び制御部２６を備える。
無線通信部２１は、公衆通信網４に繋がる基地局（図示せず）との無線通信に必要となる、増幅回路、周波数変換回路、変調及び復調回路などを有する無線通信機よりなる。
【００４５】
位置検出部２２は、携帯端末２の現在位置を特定して制御部２６に出力する装置であって、例えば、ＧＰＳ受信機よりなる。
表示部２３は、ユーザに文字及び画像などを表示するディスプレイ装置よりなる。操作部２４は、ユーザの操作入力（例えば、目的地の設定どの操作入力）を受け付け、受け付けた操作に応じた信号を制御部２６に出力する入力装置よりなる。
【００４６】
記憶部２５は、磁気記憶媒体又はフラッシュメモリなどの不揮発性記憶媒体よりなる。制御部２６は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリなどを備えたマイクロコンピュータよりなる。
制御部２６は、記憶部２５に記録されたコンピュータプログラムをＣＰＵが読み出して実行することにより、各種の処理・機能を実現する。制御部２６が実行する処理には、例えば、探索要求及びリルート要求の送信処理、徒歩ルートの監視処理などがある。
【００４７】
〔車載端末の内部構成〕
図１に示すように、車載端末３は、無線通信部３１、位置検出部３２、表示部３３、操作部３４、記憶部３５、及び制御部３６を備える。
無線通信部３１は、公衆通信網４に繋がる基地局（図示せず）との無線通信に必要となる、増幅回路、周波数変換回路、変調及び復調回路などを有する無線通信機よりなる。
【００４８】
位置検出部３２は、携帯端末２の現在位置を特定して制御部３６に出力する装置であって、例えば、ＧＰＳ受信機、車速センサ、ジャイロセンサを組み合わせた装置よりなる。
表示部３３は、ユーザに文字及び画像などを表示するディスプレイ装置よりなる。操作部３４は、ユーザの操作入力（例えば、目的地設定などの操作入力）を受け付け、受け付けた操作に応じた信号を制御部３６に出力する入力装置よりなる。
【００４９】
記憶部３５は、磁気記憶媒体又はフラッシュメモリなどの不揮発性記憶媒体よりなる。制御部３６は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリなどを備えたマイクロコンピュータよりなる。
制御部３６は、記憶部３５に記録されたコンピュータプログラムをＣＰＵが読み出して実行することにより、各種の処理・機能を実現する。制御部３６が実行する処理には、例えば、リルート要求の送信処理、非公共ルートの監視処理などがある。
【００５０】
〔出発前の通信シーケンス〕
図２は、ユーザの出発前に行われる携帯端末と管理装置との間の通信手順の一例を示すシーケンス図である。
以下の説明では、動作主体を「管理装置１」及び「携帯端末２」とするが、実際に処理を実行するのは、管理装置１の制御部１３及び携帯端末２の制御部２６である。
【００５１】
図２に示すように、ユーザの携帯端末２が探索要求を管理装置１宛てに送信すると、その探索要求を管理装置１が受信する（ステップＳＴ１）。
最初のリクエストである探索要求には、ユーザＩＤ、出発地と目的地の位置情報、時刻情報（出発時刻及び到着時刻）などが含まれる。探索要求にはさらにユーザの嗜好情報を含んでもよい。嗜好情報には、旅行時間、乗り継ぎ回数、運賃、快適さ、自己所有車両や公共交通機関の利用優先など、ユーザが何を優先的に好むかを表す情報が含まれる。管理装置１は、ユーザの嗜好情報に応じて探索処理のコストを設定することができる。
【００５２】
次に、管理装置１は、探索要求に含まれる位置情報、時刻情報及び嗜好情報を入力情報として、マルチモーダル経路の探索処理を実行する（ステップＳＴ２）。
この場合、管理装置１は、探索結果として少なくとも１つのマルチモーダル経路を生成し、生成したマルチモーダル経路を携帯端末２に送信する（ステップＳＴ３）。
【００５３】
図２の右側には、管理装置１の探索処理により生成されるマルチモーダル経路の一例として、ルート情報Ａのデータ内容が例示されている。
図示の通り、ルート情報Ａには、探索要求の送信元である携帯端末２のユーザＩＤの値（ここではユーザＩＤ＝ｘとする。）が対応付けられている。ルート情報Ａには、複数のルートａ１〜ａ５が含まれる。図示していないが、各ルートａ１〜ａ５は、各ルートの始点及び終点を位置的に指定する情報を含む。道路リンク及びノードや運行路線などのデータが含まれていてもよい。
【００５４】
ルート情報Ａには、ルートａ１〜ａ５の所定の通過予定地点（図２の例では、ルートの始点及び終点）を適時に通過するための通行スケジュールと、ルートａ１〜ａ５の通行に利用する移動手段の識別情報（以下、「交通ＩＤ」ともいう。）が含まれる。
すなわち、管理装置１の制御部１３は、ルート情報Ａのデータ内容として、各ルートａ１〜ａ５の通行スケジュールと、ユーザＩＤ（＝ｘ）と対応付けられた交通ＩＤであって、ルートａ１〜ａ５の通行に用いる交通ＩＤとを付加している。
【００５５】
図２の例では、ルートａ１〜ａ５の通行スケジュールは、ルートａ１〜ａ５の始点通過時点と終点通過時点よりなる。もっとも、ルートａ１〜ａ５の中間地点（例えば、ルートａ２の途中にある交差点などの所定ポイント）の通過予定時刻が含まれていてもよい。
管理装置１の制御部１３が付加する交通ＩＤは、本実施形態では非公共ＩＤと公共ＩＤに分類される。非公共ＩＤには、タクシーＩＤ及び自車両ＩＤなどが含まれる。公共ＩＤには、電車ＩＤ、バスＩＤ、飛行機ＩＤ及び船舶ＩＤなどが含まれる。ただし、各移動手段に固有であればＩＤの付与体系で非公共と公共を分類する必要はなく、各移動手段固有のＩＤ以外の情報で非公共や公共、移動手段の種類を区別できるようにしてもよい。
【００５６】
図２のルート情報Ａの場合、ルートａ１の通行スケジュールは、始点通過時刻が１２：２０であり終点通過時刻が１２：３０である。
ルートａ１の交通ＩＤは、Ｎｕｌｌ（なし）である。この場合、交通ＩＤが定義されていないので、ルートａ１が徒歩ルートであることを表す。
【００５７】
ルートａ２の通行スケジュールは、始点通過時刻が１２：３０であり終点通過時刻が１２：５０である。
ルートａ２の交通ＩＤは、所定のタクシーＩＤの識別値（＝ｔ２）である。この場合、交通ＩＤがタクシーＩＤであるから、ルートａ２が非公共ルートであることを表す。
【００５８】
ルートａ３の通行スケジュール（定常的な運行スケジュール）は、始点通過時刻が１２：５６であり終点通過時刻が１３：４２である。
ルートａ３の交通ＩＤは、所定の電車ＩＤの識別値（＝ｄ３）である。この場合、交通ＩＤが電車ＩＤであるから、ルートａ３が公共ルートであることを表す。
【００５９】
ルートａ４の通行スケジュールは、始点通過時刻が１３：５０であり終点通過時刻が１４：０５である。
ルートａ４の交通ＩＤは、所定のタクシーＩＤの識別値（＝ｔ４）である。この場合、交通ＩＤがタクシーＩＤであるから、ルートａ４が非公共ルートであることを表す。
【００６０】
ルートａ５の通行スケジュール（定常的な運行スケジュール）は、始点通過時刻が１５：２０であり終点通過時刻が１９：２０である。
ルートａ４の交通ＩＤは、所定の飛行機ＩＤの識別値（＝ｐ５）である。この場合、交通ＩＤが飛行機ＩＤであるから、ルートａ５が公共ルートであることを表す。
以上から明らかな通り、図２に例示するルート情報Ａは、出発地から目的地の順に、次のルートａ１〜ａ５の組み合わせにより構成されている。
【００６１】
１）徒歩ルートであるルートａ１
２）タクシーを利用する非公共ルートであるルートａ２
３）電車を利用する公共ルートであるルートａ３
４）タクシーを利用する非公共ルートであるルートａ４
５）飛行機を利用する公共ルートであるルートａ５
【００６２】
携帯端末２は、管理装置１から受信した少なくとも１つのマルチモーダル経路よりなるルート情報を自機の表示部２３に表示し（ステップＳＴ４）、ユーザによるルート情報の選択入力を受け付ける。
ユーザが操作部２４にてルート情報を選択すると、携帯端末２は、入力された選択結果を管理装置１に送信する（ステップＳＴ５）。選択結果を受信した管理装置１は、選択応答を携帯端末２に送信する（ステップＳＴ６）。
【００６３】
選択応答を受信した携帯端末２は、選択されたルート情報（ここでは、図２のルート情報Ａとする。）に基づくルート案内を開始する（ステップＳＴ７）。
具体的には、携帯端末２は、ルート情報Ａに含まれる各ルートａ１〜ａ５を含む地図情報を表示部２３に表示させる。ルート案内には、音声を伴っていてもよい。
選択応答を送信した管理装置１は、ルート情報Ａを構成するルートａ１〜ａ５をユーザが利用する場合に必要となる、各種の手配処理を実行する（ステップＳＴ８）。
【００６４】
具体的には、管理装置１は、ルートａ２の始点通過時刻の前に当該始点にタクシーが配車されるように、タクシー会社の予約管理サーバ５に発注メッセージを送信する。
この発注メッセージには、ルート情報ＡのユーザＩＤ（＝ｘ）、ルートａ２の通行スケジュール（例えば始点位置、終点位置、始点出発時刻、終点到着時刻）、及び、ルートａ２に割り当てたタクシーＩＤ（＝ｔ２）が含まれる。予約管理サーバ５は、管理装置１から提供されたそれら情報を、配車予定のタクシーの車載端末３に提供する。これらに加えて、ルートａ２の始点から終点に至る車両移動経路と移動スケジュールを含んでもよい。それらを含まず、車両移動経路と移動スケジュールはタクシー側（車載端末３等）で設定するようにしてもよい。
【００６５】
管理装置１は、ルートａ４の始点通過時刻の前に当該始点にタクシーが配車されるように、タクシー会社の予約管理サーバ５に発注メッセージを送信する。
この発注メッセージには、ルート情報ＡのユーザＩＤ（＝ｘ）、ルートａ４の通行スケジュール、及び、ルートａ４に割り当てたタクシーＩＤ（＝ｔ４）が含まれる。予約管理サーバ５は、管理装置１から提供されたそれらの情報を、配車予定のタクシーの車載端末３に提供する。これらに加えて、ルートａ４の始点から終点に至る車両移動経路と移動スケジュールを含んでもよい。それらを含まず、車両移動経路と移動スケジュールはタクシー側（車載端末３等）で設定するようにしてもよい。
【００６６】
管理装置１は、ルートａ５の始点通過時刻に離陸する航空便のチケットの予約メッセージを、ルートａ５の始点に位置する空港を利用する航空便を提供可能な航空会社の予約管理サーバ５に送信する。
ルートａ２の移動手段の交通ＩＤが自車両ＩＤの場合には、管理装置１は、ルート情報ＡのユーザＩＤ（＝ｘ）、ルートａ２の通行スケジュール、及び、ルートａ２に割り当てた自車両ＩＤを、自車両の車載端末３に送信する。ルートａ４の場合も同様である。
【００６７】
〔徒歩ルートでのリルート判定処理〕
図３は、徒歩ルートでのリルート判定処理の一例を示すフローチャートである。
以下の説明では、動作主体を「携帯端末２」とするが、実際に処理を実行するのは、携帯端末２の制御部２６である。ここで、「リルート」とは、既に得られたマルチモーダル経路（最初でも２番目でもよい。）に従って移動中である所定のユーザＩＤ（＝ｘ）の携帯端末２について、マルチモーダル経路の探索処理を再実行することをいう。
【００６８】
図３に示すように、携帯端末２は、現時点で保持するルート情報Ａに徒歩ルートａ１が含まれるか否かを判定する（ステップＳＴ１１）。
上記の判定結果が否定的である場合には、携帯端末２は処理を終了する。上記の判定結果が肯定的である場合には、携帯端末２は、徒歩ルートの監視処理を実行する（ステップＳＴ１２）。
【００６９】
「監視処理」とは、ルート情報Ａに含まれる通行スケジュールに基づいて、通過予定地点及びこれに対応する通過予定時刻（予定値）と、実際の通過地点及び通過時刻（実際値）との乖離を算出及び評価する処理のことをいう。
従って、徒歩ルートの監視処理では、携帯端末２は、徒歩ルートであるルートａ１の通過予定地点及び通過予定時刻（予定値）と、実際の通過地点及び通過時刻（実際値）との乖離を算出する。また、携帯端末２は、算出した予定値と実際値との乖離が大きいか否かを判定する（ステップＳＴ１３）。
【００７０】
例えば、携帯端末２は、現在時刻が１２：３０であり、現在位置とルートａ１の終点（通過予定地点）との距離が所定距離（例えば３００ｍ）以上である場合には、予定値と実際値との乖離が大きいと判定する。
同様に、携帯端末２は、現在位置がルートａ１の終点（通過予定地点）であり、現在時刻とルートａ１の終点の通過予定時刻（＝１２：３０）との時間差が所定時間（例えば５分）以上である場合には、予定値と実際値との乖離が大きいと判定する。
【００７１】
上記の判定結果が肯定的である場合には、携帯端末２が徒歩ルートを予定通りに移動していないと判断できるので、携帯端末２は、リルート要求を管理装置１に送信する（ステップＳＴ１４）。携帯端末２は、自機のユーザＩＤ（＝ｘ）と現在位置をリルート要求に含める。この現在位置は、管理装置１がリルートを実行する場合の出発地となる。
上記の判定結果が否定的である場合には、携帯端末２は、リルート要求を管理装置１に送信せず、現状のルート情報Ａを維持する（ステップＳＴ１５）。
【００７２】
〔非公共ルートでのリルート判定処理〕
図４は、非公共ルートでのリルート判定処理の一例を示すフローチャートである。
以下の説明では、動作主体を「車載端末３」とするが、実際に処理を実行するのは、車載端末３の制御部３６である。
車載端末３は、管理装置１から車両移動経路及び時刻自体が指定されている時には、当該指定に沿って運転手を案内するか自動運転により車両を走行させる。管理装置１から通行スケジュールのみを受けている時は、自ら車両移動経路及び時刻を設定し当該設定に沿って運転手を案内するか自動運転により車両を走行させる。
【００７３】
想定以上に渋滞が発生したり運転手の運転が経路を外れることによって例えば対象ルートに指定された終点位置に予定時刻に到着できなかったりする場合には、リルートが行われる。指定された始点位置に予定時刻に車両が到着できない場合には、車載装置３から管理装置１等にその情報が送信され、管理装置１又は携帯端末２などでリルートを行うことができる。
【００７４】
図４に示すように、車載端末３は、管理装置１から通知された所定のユーザＩＤ（＝ｘ）のユーザが乗車したか否かを判定する（ステップＳＴ２１）。
この判定は、例えば、非公共車両の運転者による、車載端末３に対する搭乗確認の操作入力が合ったか否かによって行われる。非公共車両の運転者（例えばタクシーの運転手）は、管理装置１から通知されたユーザＩＤ（＝ｘ）と、ユーザの携帯端末２が提示するユーザＩＤが一致すれば、搭乗確認の操作入力を行う。
【００７５】
携帯端末２と車載端末３が、ＷｉＦｉ通信などによって直接的な通信が可能な場合には、ユーザＩＤを照合する上記の搭乗確認を、両端末２，３の直接通信によって行うことにしてもよい。
上記の判定結果が否定的である場合には、車載端末３は処理を終了する。上記の判定結果が肯定的である場合には、車載端末３は、乗車確認を管理装置１に送信したあと（ステップＳＴ２２）、非公共ルートの監視処理を実行する（ステップＳＴ２３）。
【００７６】
前述の通り、「監視処理」とは、ルート情報Ａに含まれる通行スケジュールに基づいて、通過予定地点及びこれに対応する通過予定時刻（予定値）と、実際の通過地点及び通過時刻（実際値）との乖離を算出及び評価する処理のことをいう。
従って、非公共ルートの監視処理では、車載端末３は、非公共ルートであるルートａ２，ａ４の通過予定地点及び通過予定時刻（予定値）と、実際の通過地点及び通過時刻（実際値）との乖離を算出する。また、車載端末３は、算出した予定値と実際値との乖離が大きいか否かを判定する（ステップＳＴ２４）。
【００７７】
例えば、ルートａ２には、中間の通過予定地点である所定の交差点Ｊ２の位置情報と、通過予定地点に対応する通過予定時刻（＝１２：４０）が含まれるものとする。
この場合、車載端末３は、現在時刻が１２：４０であり、現在位置と交差点Ｊ２の位置との距離が所定距離（例えば１０００ｍ）以上である場合には、予定値と実際値との乖離が大きいと判定する。
同様に、携帯端末２は、現在位置が交差点Ｊ２の位置であり、現在時刻と交差点Ｊ２の通過予定時刻（＝１２：４０）との時間差が所定時間（例えば５分）以上である場合には、予定値と実際値との乖離が大きいと判定する。
【００７８】
上記の判定結果が肯定的である場合には、車載端末３が非公共ルートを予定通りに移動していないと判断できるので、車載端末３は、リルート要求を管理装置１に送信する（ステップＳＴ２５）。車載端末３は、自機の非公共（ＩＤ＝ｔ２又はｔ４）と現在位置をリルート要求に含める。この現在位置は、管理装置１がリルートを実行する場合の出発地となる。
上記の判定結果が否定的である場合には、車載端末３は、リルート要求を管理装置１に送信せず、現状のルート情報Ａを維持する（ステップＳＴ２６）。
【００７９】
なお、上記の判定結果が肯定的であり、ある通過予定地点に予定時刻に車両が到着できない場合でも、その先での交通状況の回復や車載装置３による移動経路設定の変更等により、最終的に終点位置へ予定時刻に車両が到着すると判断できる時は、リルート要求を管理装置１に送信しなくてもよい。
管理装置１へのリルート要求は、管理装置１から指定された通行スケジュールの通りに運行ができないと判断された場合に行えばよい。
【００８０】
〔公共交通機関への乗車等の確認〕
本実施形態の経路探索システムでは、路線バス、電車、航空機などの公共交通機関の移動手段が、管理装置１と通信可能な通信端末を備えていない。
そこで、携帯端末２の制御部１３は、公共交通機関を利用するルートａ３，ａ４の始点に適時に到着した場合には、自機のユーザＩＤ（＝ｘ）を含む乗車確認を管理装置１に送信することが好ましい。
【００８１】
このようにすれば、公共交通機関の移動手段が管理装置１と通信できなくても、管理装置１は、所定のユーザＩＤ（＝ｘ）を含む乗車確認の受信により、当該ユーザＩＤの携帯端末２を有するユーザが、マルチモーダル経路によって指定した通りの公共交通機関に無事に搭乗できたことを察知することができる。
【００８２】
なお、携帯端末２が乗車（及び／又は降車）確認を送信するトリガーとしては、例えば、次の条件のうちの少なくとも１つが成立することが考えられる。
条件１：自機の現在位置が通行スケジュールの始点と一致し、自機の現在時刻が通行スケジュールの始点通過時刻と一致すること（一致の判定は所定誤差を許容する。）。
条件２：携帯端末２の操作部３４に対して、ユーザによる乗車又は降車確認の操作入力を受け付けたこと。
条件３：所定のゲート（例えば電車の改札口など）の通過が検知されたこと。
【００８３】
〔管理装置によるユーザＩＤごとのリルート判定処理〕
図５は、管理装置１によるユーザＩＤごとのリルート判定処理の一例を示すフローチャートである。
以下の説明では、動作主体を「管理装置１」とするが、実際に処理を実行するのは、管理装置１の制御部１３である。
【００８４】
図５に示すように、管理装置１は、所定のユーザＩＤ（＝ｘ）の携帯端末２よりリルート要求を受信したか否かを判定する（ステップＳＴ３１）。
ステップＳ３１の判定結果が肯定的である場合には、管理装置１は、当該ユーザＩＤ（＝ｘ）についてリルートを実行し、その探索結果を同じユーザＩＤ（＝ｘ）の携帯端末２に送信する（ステップＳＴ３５）。この場合のリルートは、リルート要求に含まれる携帯端末２の現在位置を出発地として行われる、マルチモーダル経路の探索処理である。
【００８５】
ステップＳ３１の判定結果が否定的である場合には、管理装置１は、更に、所定のユーザＩＤ（＝ｘ）に対応する非公共ＩＤ（＝ｔ２又はｔ４）の車載端末３よりリルート要求を受信したか否かを判定する（ステップＳＴ３２）。
ステップＳ３２の判定結果が肯定的である場合には、管理装置１は、当該ユーザＩＤ（＝ｘ）についてリルートを実行し、その探索結果を同じユーザＩＤ（＝ｘ）の携帯端末に送信する（ステップＳＴ３５）。この場合のリルートは、リルート要求に含まれる車載端末３の現在位置を出発地として行われる、マルチモーダル経路の探索処理である。
【００８６】
ステップＳ３２の判定結果が否定的である場合には、管理装置１は、更に、ユーザＩＤ（＝ｘ）のルート情報Ａの現時点以降のルートに事情変更があるか否かを判定する（ステップＳＴ３３）。
事情変更とは、例えば、大渋滞、大きな気象変動及びイベント開催の発生などにより、道路通行が急に不能となったり、予定されていた公共交通機関の運行が停止したりする場合などのことをいう。
【００８７】
ステップＳ３３の判定結果が肯定的である場合には、管理装置１は、当該ユーザＩＤ（＝ｘ）についてリルートを実行し、その探索結果を同じユーザＩＤ（＝ｘ）の携帯端末に送信する（ステップＳＴ３５）。
ステップＳ３３の判定結果が否定的である場合には、管理装置１は、当該ユーザＩＤ（＝ｘ）についてリルートを実行せず、当該ユーザＩＤ（＝ｘ）のルート情報Ａを維持する（ステップＳＴ３４）。
【００８８】
〔管理装置による公共ＩＤごとのリルート判定処理〕
図６は、管理装置１による公共ＩＤごとのリルート判定処理の一例を示すフローチャートである。
以下の説明では、動作主体を「管理装置１」とするが、実際に処理を実行するのは、管理装置１の制御部１３である。
【００８９】
図６に示すように、管理装置１は、１つの公共ＩＤ（ここでは、図２に例示する電車ＩＤ＝ｄ３と仮定する。）に対して、複数のユーザＩＤ（＝ｘｉ（ｉ＝１，２……））が対応付けられているか否かを判定する（ステップＳＴ４１）。
１つの電車ＩＤ（＝ｄ３）に複数のユーザＩＤ（＝ｘｉ）が対応する場合は、当該電車ＩＤ（＝ｄ３）の公共ルートを含むマルチモーダル経路に従ってそれぞれ移動中の複数のユーザが乗車していることを意味する。
【００９０】
上記の判定結果が否定的である場合には、管理装置１は処理を終了する。上記の判定結果が肯定的である場合には、管理装置１は、公共ルートの監視処理を実行する（ステップＳＴ４２）。
【００９１】
前述の通り、「監視処理」とは、ルート情報Ａに含まれる通行スケジュールに基づいて、通過予定地点及びこれに対応する通過予定時刻（予定値）と、実際の通過地点及び通過時刻（実際値）との乖離を算出及び評価する処理のことをいう。
もっとも、公共交通機関を利用する公共ルートの場合には、定常時の運行スケジュールが定まっているので、現時点の運行スケジュールが定常通りであるか否かを判定すれば、予定値と実際値との乖離を評価することができる。
【００９２】
そこで、公共ルートの監視処理では、管理装置１は、電車ＩＤ（＝ｄ３）のルートａ３に対応する運行スケジュールの状況を運行管理サーバ６に問い合わせ、運行状況の変化が大きいか否かを判定する（ステップＳＴ４３）。
管理装置１は本実施形態において、例えば事故の発生により電車ＩＤ（＝ｄ３）の運行スケジュールの遅延が所定時間（例えば１５分）以上である場合は、運行状況の変化が大きいと判定する。
【００９３】
上記の判定結果が肯定的である場合には、管理装置１は、電車ＩＤ（＝ｄ３）に対応する複数のユーザＩＤ（＝ｘｉ）についてリルートを実行し、その探索結果を各ユーザＩＤ（＝ｘｉ）の携帯端末２に送信する（ステップＳＴ４４）。
この場合、管理装置１は、ユーザを判定時点での直近駅で降車させて他の路線の電車を含む他の移動手段に変更するようなリルートを行う。当該直近駅に例えばタクシーを配車することができる。対象ユーザが多くタクシーが当該駅に集中するため渋滞の発生が予想されるような場合、管理装置１は、その渋滞を緩和するような信号制御を行うように指示することができる。
【００９４】
なお、判定結果が肯定的であっても目的地に予定時刻に到着すると判断した時、管理装置１はリルートを実行しなくてよい。この判断はユーザＩＤごとに行うことができる。同じ電車に搭乗しているユーザでも、その電車より後のルートに余裕のあるユーザについてはリルートを行う必要がない場合がある。
上記の判定結果が否定的である場合には、管理装置１は、電車ＩＤ（＝ｄ３）に対応する複数のユーザＩＤ（＝ｘｉ）についてリルートを実行せず、当該ユーザＩＤ（＝ｘｉ）の現状のルート情報を維持する（ステップＳＴ４５）。
【００９５】
〔ルート情報のイメージ図〕
図７は、ルート情報Ａに含まれるルートａ１〜ａ５のイメージ図である。
ルート情報Ａは、例えば、ユーザの自宅を出発地とし他府県の空港を目的地として、管理装置１が算出したマルチモーダル経路の例である。図７のルート情報Ａは、図２のルート情報Ａと同様であり、出発地から順に５つのルートａ１〜ａ５を含む。
【００９６】
具体的には、ルートａ１は、徒歩ルートであり、ルートａ２は、タクシーを利用する非公共ルートであり、ルートａ３は、電車を利用する公共ルートである。
ルートａ４は、乗り合いタクシーを利用する非公共ルートであり、ルートａ５は、飛行機を利用する公共ルートである。ルートａ５の終点は目的地の空港である。
【００９７】
図８は、別のルート情報Ｂに含まれるルートｂ１〜ｂ５のイメージ図である。
ルート情報Ｂは、例えば、出張先の取引会社を出発地とし他府県の自宅を目的地として、管理装置１が算出したマルチモーダル経路の例である。図８のルート情報Ｂは、出発地から順に５つのルートｂ１〜ｂ５を含む。
【００９８】
具体的には、ルートｂ１は、徒歩ルートであり、ルートｂ２は、バスを利用する公共ルートであり、ルートａ３は、電車を利用する公共ルートである。
ルートｂ４は、乗り合いタクシーを利用する非公共ルートであり、ルートｂ５は、徒歩ルートである。
【００９９】
図８のルート情報Ｂでは、前述のようにルートｂ３の電車の運行に大きな遅延が発生したため、管理装置１が、その電車ＩＤに搭乗する複数のユーザＩＤについてリルートを実行した場合を想定している。
従って、ルートｂ３よりも後のルートｂ４及びルートｂ５は、管理装置１がリルートによって算出したマルチモーダル経路である。
【０１００】
前述の通り、本実施形態の管理装置１は、管轄エリアに属する交差点の交通信号機について交通感応制御を実行可能である。
そこで、ルートｂ４で利用する乗り合いタクシーが、ルートｂ４の途中の交差点を青信号で通過し易くなる信号制御パラメータを採用するなどの交通信号制御を実行することが好ましい。このようにすれば、電車を利用するルートｂ３で発生した遅延をなるべく解消できるようになる。
【０１０１】
〔本実施形態の効果〕
本実施形態の経路探索システムによれば、管理装置（経路探索装置）１の制御部１３が、マルチモーダル経路のデータ内容に、ルートａ１〜ａ５の通行スケジュールと、ルートａ１〜ａ５の通行に用いる移動手段の識別情報（＝交通ＩＤ）であって、ユーザＩＤと対応付けられた交通ＩＤとを含める（図２参照）。
このため、ユーザが各ルートａ１〜ａ５を予定通りに移動しているか否かの監視処理を、携帯端末２などのローカル端末に実行させることができ、マルチモーダル経路の監視処理のための処理負荷を適切に分散できる。
【０１０２】
例えば、本実施形態の経路探索システムでは、携帯端末２が、徒歩ルートａ１の通行スケジュールに基づいて、自機が徒歩ルートａ１を予定通りに移動しているか否かを監視し（図３のステップＳＴ１２，ＳＴ１３）、監視結果が否定的である場合に、探索処理を再実行させるためのリルート要求を管理装置１に送信する（図３のステップＳＴ１４）。
このため、ユーザが徒歩ルートａ１を予定通りに移動できなかった場合でも、管理装置１が新たに生成した次のマルチモーダル経路を携帯端末２が受信することができ、今後に有効な経路情報をユーザに提供することができる。
【０１０３】
本実施形態の経路探索システムでは、車載端末３が、非公共ルートａ２，ａ４の通行スケジュールに基づいて、自車両が非公共ルートの予定通りに移動しているか否かを監視し（図４のステップＳＴ２３，ＳＴ２４）、監視結果が否定的である場合に、前記探索処理を再実行させるためのリルート要求を管理装置１に送信する。
このため、ユーザが非公共ルートａ２，ａ４を予定通りに移動できなかった場合でも、管理装置１新たに生成した次のマルチモーダル経路を携帯端末が受信することができ、今後に有効な経路情報をユーザに提供することができる。
【０１０４】
本実施形態の経路探索システムでは、管理装置１の制御部１３は、公共ルートａ３，ａ５の通行スケジュールに基づいて、公共交通機関が公共ルートａ３，ａ５を予定通りに移動しているか否かを監視し（図６のＳＴ４２，ＳＴ４３）、監視結果が否定的である場合に、当該公共交通機関の交通ＩＤに対応するすべてのユーザＩＤについて、探索処理を再実行する（図６のＳＴ４４）。
【０１０５】
このため、１つの公共ルートの監視結果に基づいて、複数のユーザＩＤの携帯端末２のためのリルートを実行できるようになる。
従って、同じ公共ルートを利用する複数のユーザＩＤの携帯端末２が、当該公共ルートの監視処理を実行する場合に比べて、システム全体としての処理負荷を低減することができる。
【０１０６】
本実施形態の経路探索システムによれば、携帯端末２の探索要求に応じて管理装置１がマルチモーダル経路を探索し、その探索結果を受信した携帯端末２がユーザにマルチモーダル経路を表示する。
従って、ユーザは、マルチモーダル経路を最大限に利用し、自身のニーズに最も適した経路で目的地まで移動することができる。
【０１０７】
本実施形態の経路探索システムによれば、ユーザの都合により経路変更の必要性が生じたり、公共交通機関の運行状況が変化したりすると、管理装置１のリルートにより新たなマルチモーダル経路が生成され、生成されたマルチモーダル経路がユーザに提供される。このため、ユーザは、移動途中の事情変更に柔軟に対応することができる。
【０１０８】
本実施形態の経路探索システムによれば、管理装置１は、多数のユーザのために生成したマルチモーダル経路を集約することにより、交通機関の資源の最適化及び社会の消費エネルギーの最適化を図ることができる。
マルチモーダル経路のトレース（監視）をローカルの電子機器に任せることで、管理装置１の処理負担を軽減することができる。
【０１０９】
特に、ユーザが利用している公共交通機関を利用する場合、管理装置１は、当該公共交通機関を利用するユーザＩＤを纏めて管理し、公共交通機関の運行状況をトレースするだけでよい。従って、管理装置１の処理量や情報通信資源の軽減を図ることができる。
【０１１０】
〔第１の変形例〕
上述の実施形態では、携帯端末２の識別情報（以下、「携帯ＩＤ」という。）をユーザＩＤとして利用し、ユーザＩＤと携帯ＩＤと区別していないが、管理装置１は、固有のユーザＩＤとこれに対応付けた携帯ＩＤの双方を管理対象としてもよい。
すなわち、管理装置１は、例えば、ユーザが管理装置１のホームページに入力するなどにより特定した固有のユーザＩＤ（＝ｘｉ（ｉ＝１，２……））に対して、入力時に定めた別の固有の携帯ＩＤ（＝ｙｊ（ｊ＝１，２……））を対応付けて管理してもよい。
【０１１１】
この場合、管理装置１は、携帯ＩＤ＝ｙ１を含む探索要求を受信した場合、これに対応するユーザＩＤ＝ｘ１の探索要求であると見なし、当該ユーザＩＤ＝ｘ１のユーザのためのマルチモーダル経路の探索処理を実行すればよい。
また、徒歩ルートでは、ユーザＩＤ（＝ｘ１）のユーザとともに移動するのは、携帯ＩＤ（＝ｙ１）の携帯端末２のみであるから、携帯端末２を徒歩ルートａ１における移動手段と見なし、携帯ＩＤ（＝ｙ１）を交通ＩＤに組み込むことにしてもよい。
【０１１２】
ところで、携帯ＩＤをユーザＩＤとして利用する上述の実施形態の場合には、各ルートａ１〜ａ５の監視処理の主体は、次のようになる。
１）公共ルートａ３，ａ５の監視処理は、管理装置１が行う。
２）公共ルートａ３，ａ５以外のルートａ１，ａ２，ａ４の監視処理は、ユーザＩＤ（＝ｘ１）の携帯端末２、或いは、ユーザＩＤ（＝ｘ１）に対応付けられた交通ＩＤ（タクシーＩＤ（＝ｔ２）又はタクシーＩＤ（＝ｔ４））の車載端末３が行う。
【０１１３】
また、ユーザＩＤに対応付けて携帯ＩＤを定義する当該変形例の場合、ルートの監視処理の主体は、次のようになる。
１）公共ルートａ３，ａ５の監視処理は、管理装置１が行う。
２）公共ルートａ３，ａ５以外のルートａ１，ａ２，ａ４の監視処理は、ユーザＩＤ（＝ｘ１）に対応付けられた交通ＩＤ（携帯ＩＤ（＝ｙ１）、タクシーＩＤ（＝ｔ２）又はタクシーＩＤ（＝ｔ４））の携帯端末２又は車載端末３が行う。
【０１１４】
上記の通り、いずれにしても、公共ルートａ３，ａ５の監視処理については、管理装置１により実行され、それ以外のルートａ１，ａ２，ａ４の監視処理については、ルートａ１，ａ２，ａ４の交通ＩＤより定義された移動手段である、携帯端末２又は車載端末３などのローカル端末により実行される。
【０１１５】
なお、上記のローカル端末からリルート要求を受けた場合には、管理装置１は、リルート要求に含まれるユーザＩＤ、或いは、リルート要求に含まれる交通ＩＤ（携帯ＩＤ（＝ｙ１）、タクシーＩＤ（＝ｔ２）又はタクシーＩＤ（＝ｔ４））に対応するユーザＩＤについて、リルートを実行する。
【０１１６】
〔第２の変形例〕
上述の実施形態（第１の変形例を含む。）において、車載端末３は、自機に割り当てられたルートをスケジュール通りに通行できた場合には、ルートの完了通知を管理装置１に送信することにしてもよい。
この場合、管理装置１は、所定の交通ＩＤの車載端末３から、当該交通ＩＤに割り当てたルートの終点通過時刻を経過してもリルート要求がなく、かつ、当該ルートの完了通知がない場合、当該ルートを予定通りに通過したか否かの確認要求を携帯端末２に送信することが好ましい。
【０１１７】
かかる確認要求を受信した携帯端末２は、自機の現在位置及び時刻に基づいて、車載端末３に割り当てられたルートを予定通りに通行したか否かを判定し、その判定結果を管理装置１に送信すればよい。
このようにすれば、一時的な通信不良などにより車載端末３が管理装置１と通信できなかった場合でも、ユーザが非公共ルートを予定通りに通過したかの監視処理を、携帯端末２に実行させることができる。
【０１１８】
〔その他の変形例〕
今回開示した実施形態（変形例を含む。）はすべての点で例示であって制限的なものではない。本発明の権利範囲は、上述の実施形態に限定されるものではなく、特許請求の範囲に記載された構成と均等の範囲内でのすべての変更が含まれる。
上述の実施形態において、通行スケジュールと移動手段の識別情報（＝交通ＩＤ）の対応付けは、すべてのルートａ１〜ａ５ではなく、少なくとも１つのルートについて行うことにしてもよい。
【０１１９】
上述の実施形態において、管理装置１は、多数のユーザＩＤの探索要求に含まれるＯＤ情報を集約し、集約したＯＤ情報を交通信号制御などの交通管制に利用することにしてもよい。
上述の実施形態において、管理装置１は、多数のユーザＩＤの探索要求に含まれるＯＤ情報を利用して、所定の公共交通機関の混雑状況を予測することにしてもよい。さらに、その混雑状況をユーザから探索要求を受けた時に提供するようにしてもよい。
【０１２０】
例えば、同じ電車ＩＤに紐付けられたユーザＩＤの数と、予め定められた当該電車の乗車人数とから「乗車率」を計算し、移動経路の表示時にその乗車率も表示する。その乗車率を参考に、ユーザは、目的地への到着時刻が遅くなっても電車での混雑を避けたり、あくまで目的地へ予定時刻に到着することを望んだり等の選択を行うことができる。
【０１２１】
上述の実施形態では、ルートを徒歩ルート、公共ルート、非公共ルートの３つに分類したが、非公共ルートをさらに複数種類に分け、そのルートの種類によって優先度やルート計算などの条件を変化させるようにしてもよい。
【符号の説明】
【０１２２】
１  管理装置（経路探索装置）
２  携帯端末
３  車載端末
４  公衆通信網
５  予約管理サーバ
６  運行管理サーバ
７  気象サーバ
８  催事サーバ
９  交通信号制御機
１１  通信部
１２  記憶部
１３  制御部
２１  無線通信部
２２  位置検出部
２３  表示部
２４  操作部
２５  記憶部
２６  制御部
３１  無線通信部
３２  位置検出部
３３  表示部
３４  操作部
３５  記憶部
３６  制御部
【図１】
2018096810.tif 000003
【図２】
2018096810.tif 000004
【図３】
2018096810.tif 000005
【図４】
2018096810.tif 000006
【図５】
2018096810.tif 000007
【図６】
2018096810.tif 000008
【図７】
2018096810.tif 000009
【図８】
2018096810.tif 000010