通信システムおよび移動端末
【課題】車、公共交通機関等の移動手段を組み合わせ、また時々刻々変化する運行状態（道路の渋滞、公共交通機関の遅れなど）を考慮した最適ルートの探索において、センターへの問い合わせを必要最低限にすることで、効率的なマルチモーダルルート探索のセンター運用を可能とする。
【解決手段】移動端末に、あらかじめ公共交通機関の定常運行状態の運行スケジュールを記録しておき、移動端末側で公共交通機関以外（例えば、徒歩、車両）を使ったルートと公共交通機関を使ったルートを最適なルート中の区間の候補とするルート探索を行う（ステップ１２０）。そして、そのルート探索において、公共交通機関を使ったほうが良いという結果になった場合（ステップ１３０）に、センターに現在の運行状況を踏まえたマルチモーダル探索の依頼をかけ（ステップ１４０）、センターから受信したセンタールートを案内用のルートとして記録する（ステップ１６０）。
【解決手段】移動端末に、あらかじめ公共交通機関の定常運行状態の運行スケジュールを記録しておき、移動端末側で公共交通機関以外（例えば、徒歩、車両）を使ったルートと公共交通機関を使ったルートを最適なルート中の区間の候補とするルート探索を行う（ステップ１２０）。そして、そのルート探索において、公共交通機関を使ったほうが良いという結果になった場合（ステップ１３０）に、センターに現在の運行状況を踏まえたマルチモーダル探索の依頼をかけ（ステップ１４０）、センターから受信したセンタールートを案内用のルートとして記録する（ステップ１６０）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムおよび移動端末に関するものである。
【背景技術】
【０００２】
徒歩、車、公共交通機関（例えば列車、バス）等の移動手段を組み合わせ、また時々刻々変化する運行状態（道路の渋滞、公共交通機関の遅れなど）を考慮した最適ルートの探索を実施するためには、全ての情報を理想的に揃えやすいセンターで、各移動端末からの問い合わせに応じてルート探索計算を行う技術が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−２９６０７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、そうした実現方法をとる場合には、問い合わせを行う端末の増加に伴い、センター側の負荷が集中するという問題がある。また、逐次問い合わせするために、通信コストがその都度かかるという問題もある。
【０００５】
本発明は上記問題点に鑑み、車、公共交通機関等の移動手段を組み合わせ、また時々刻々変化する運行状態（道路の渋滞、公共交通機関の遅れなど）を考慮した最適ルートの探索において、センターへの問い合わせを必要最低限にすることで、効率的なマルチモーダルルート探索のセンター運用を可能とすることを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するための請求項１に記載の発明は、移動端末（１）と、前記移動端末（１）と通信可能なセンター（２）とを備えた通信システムであって、前記移動端末（１）は、道路構成および公共交通機関の乗降施設の位置を含む端末側地図データベース（１５ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）とを記憶する端末側記憶部（１５）、および、端末側制御部（１６）を備え、前記センター（２）は、道路構成および前記公共交通機関の乗降施設の位置を含むセンター側地図データベース（２２ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールおよび定常運行状態の運行スケジュールに対する現在の運行変化状況を含む現状公共交通機関データベース（２２ｃ）とを記憶する前記センター側記憶部（２２）、および、センター側制御部（２３）を備え、前記端末側制御部（１６）は、前記センター（２）を利用せず、前記端末側地図データベース（１５ｂ）および前記定常公共交通機関運行データベース（１５ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なローカルルートを算出するローカルマルチモーダルルート探索手段（１２０）と、前記ローカルマルチモーダルルート探索手段（１２０）によって算出された前記ローカルルートが公共交通機関を利用しているか否かを判定する判定手段（１３０）と、前記判定手段（１３０）が利用していないと判定したことに基づいて、前記ローカルルートを経路案内用のルートとして記録するローカルルート記録手段（１３５）と、前記判定手段（１３０）が利用していると判定したことに基づいて、前記現在地と前記目的地を含んだマルチモーダルルート探索要求を前記センター（２）に送信するセンターマルチモーダルリクエスト手段（１４０）と、を備え、前記センター側制御部（２３）は、前記センターマルチモーダルリクエスト手段（１４０）によって前記移動端末（１）から送信された前記マルチモーダルルート探索要求を受信するマルチモーダルルート探索要求受信手段（２３ｃ）と、前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適なセンタールートを算出するセンターマルチモーダルルート探索手段（２３ｄ）と、前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記センタールートを前記移動端末（１）に送信するマルチモーダルルート配信手段（２３ｅ）と、を備え、更に前記端末側制御部（１６）は、前記センターマルチモーダルリクエスト手段（１４０）が送信した前記マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記センタールートを受信したことに基づいて、前記センタールートを経路案内用のルートとして記録するセンタールート記録手段（１６０）を備えたことを特徴とする通信システムである。
【０００７】
このように、移動端末１に、あらかじめ公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）を備えておき、移動端末（１）側で公共交通機関以外（例えば、徒歩、車両）を使ったルートと公共交通機関を使ったルートを最適なルート中の区間の候補とするルート探索を行う。そして、そのルート探索において、公共交通機関を使ったほうが良いという結果になった場合に、センターに現在の運行状況を踏まえたマルチモーダル探索の依頼をかけるようにする。
【０００８】
公共交通機関を使ったルートの比較において、公共交通機関の実際の運行状態を踏まえたルートは、定常の運行状態と同じ、もしくは定常状態より悪化することしか通常はありえないため、定常状態で公共交通機関を使ったルートが算出される場合でしか、実際の運行状態を踏まえたルート算出で公共交通機関を使ったルートとなることがあり得ないと考えることができるため、上記のような実現方法を取ることで、不必要にセンター（２）に問い合わせることなく、マルチモーダル探索の実現が可能となる。
【０００９】
また、請求項２に記載の発明は、請求項１に記載の通信システムにおいて、更に前記端末側制御部（１６）は、前記ローカルルートおよび前記センタールートのうち、経路案内用のルートとするルート上に１つまたは複数の再探索ポイントを設定する再探索ポイント設定手段（１６５、１７０）を備え、更に前記端末側制御部（１６）は、前記経路案内用のルートを案内しているときに、前記移動端末（１）が前記再探索ポイントのいずれかに対して前記経路案内用のルートに沿って基準距離以内の手前に接近したか否かを判定し、接近したと判定したことに基づいて、現在地と前記目的地を含んだ再探索ポイント用マルチモーダルルート探索要求を前記センター（２）に送信する再探索ポイント用センターマルチモーダルリクエスト手段（３４０）を備え、前記センター側制御部（２３）の前記マルチモーダルルート探索要求受信手段（２３ｃ）は更に、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）によって前記移動端末（１）から送信された前記再探索ポイント用マルチモーダルルート探索要求を受信し、前記センターマルチモーダルルート探索手段（２３ｄ）は更に、前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記再探索ポイント用マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記再探索ポイント用マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適な再探索ポイント用センタールートを算出し、前記マルチモーダルルート配信手段（２３ｅ）は更に、前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記再探索ポイント用センタールートを前記移動端末（１）に送信し、更に前記端末側制御部（１６）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（１４０）が送信した前記再探索ポイント用マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記再探索ポイント用センタールートを受信したことに基づいて、前記再探索ポイント用センタールートを経路案内用のルートとして使用するセンタールート使用手段（３６０、３６２〜３６８）を備えたことを特徴とする。
【００１０】
このように、端末側制御部（１６）は、再探索ポイントを設定して記録しておき、移動端末（１）の移動中は、移動端末（１）がその再探索ポイントへの接近を検出した場合を選んで、センター（２）に再探索ポイント用マルチモーダルルート探索要求を行うことで、公共交通機関の最新の運行状況に基づいて作成された再探索ポイント用センタールートを経路案内用ルートとすることができる。
【００１１】
このようになっていることで、一旦経路案内用のルートを決定し、そのルートで案内を行い、その案内に従って移動端末（１）が移動しているときも、センター（２）にマルチモーダルルート探索要求を送信することで、公共交通機関の運行状況の変化に応じて柔軟に経路案内用のルートを変更することができる。また、移動端末（１）が再探索ポイントへの接近を検出した場合を選んで、センター（２）にマルチモーダルルート探索要求を行うので、無駄に多数回センター（２）に問い合わせしてしまう可能性を抑えることができる。
【００１２】
また、請求項３に記載の発明は、請求項２に記載の通信システムにおいて、 前記センターマルチモーダルルート探索手段（２３ｄ）は、算出した前記センタールート上に１つまたは複数の再探索ポイントを設定し、前記マルチモーダルルート配信手段（２３ｅ）は、前記センターマルチモーダルルート探索手段（２３ｄ）が設定した前記１つまたは複数の再探索ポイントを、前記移動端末（１）に送信し、前記再探索ポイント設定手段（１６５、１７０）は、前記マルチモーダルルート配信手段（２３ｅ）によって送信された前記再探索ポイントを、前記経路案内用のルート上の再探索ポイントとして設定することを特徴とする。
【００１３】
このように、端末側制御部（１６）は、センタールートと共に再探索ポイントを受信し、移動端末（１）の移動中は、移動端末（１）がその再探索ポイントへの接近を検出した場合にのみ、センター（２）に再探索ポイント用マルチモーダルルート探索要求を行うことで、公共交通機関の最新の運行状況に基づいて作成された再探索ポイント用センタールートを経路案内用ルートとすることができる。
【００１４】
このようになっていることで、一旦経路案内用のルートを決定し、そのルートで案内を行い、その案内に従って移動端末（１）が移動しているときも、センター（２）にマルチモーダルルート探索要求を送信することで、公共交通機関の運行状況の変化に応じて柔軟に経路案内用のルートを変更することができる。また、移動端末（１）が再探索ポイントへの接近を検出した場合を選んで、センター（２）にマルチモーダルルート探索要求を行うので、無駄に多数回センター（２）に問い合わせしてしまう可能性を抑えることができる。
【００１５】
また、請求項４に記載の発明は、請求項２または３に記載の通信システムにおいて、前記センタールート使用手段（３６０、３６２〜３６８）は、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを、前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する時間および前記経路案内用のルートを現在位置から目的地まで移動するのに要する時間と、前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する料金および前記経路案内用のルートを現在位置から目的地まで移動するのに要する料金と、ユーザの選択操作と、のうちいずれか１つまたは複数に基づいて判定し、有利であると判定した場合に、前記再探索ポイント用センタールートを新たな経路案内用のルートとして使用し、有利でないと判定した場合に、前記経路案内用のルートをそのまま経路案内用のルートとして使用することを特徴とする。
【００１６】
このように、センター（２）で算出された再探索ポイント用センタールートと経路案内用のルートのうちどちらが有利かを判定し、有利な方を経路案内用のルートとして使用することで、より適切な経路案内を行うことができる。
【００１７】
また、請求項５に記載の発明は、請求項４に記載の通信システムにおいて、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）は、前記再探索ポイント用マルチモーダルルート探索要求に前記経路案内用のルートを含め、前記マルチモーダルルート配信手段（２３ｅ）は、前記再探索ポイント用マルチモーダルルート探索要求に含まれる前記経路案内用のルートと、前記現状公共交通機関データベース（２２ｃ）に基づいて、少なくとも当該経路案内用ルートの各区間の現状の移動所要時間に関する不利情報を取得し、その取得した不利情報を前記再探索ポイント用センタールートと共に前記移動端末（１）に送信し、前記センタールート使用手段（３６２〜３６８）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）が送信した前記不利情報を利用して前記経路案内用のルートの各区間の移動所要時間を再計算し、再計算した移動所要時間を用いて、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを判定することを特徴とする。
【００１８】
このように、移動端末（１）で算出した経路案内用のルート自体の移動所要時間も、センター（２）の現状公共交通機関データベース（２２ｃ）に基づいて再計算することで、より適切な経路案内用のルートと再探索ポイント用センタールートの有利性の比較判定を行うことができる。
【００１９】
また、請求項６に記載のように、請求項１に記載の発明の特徴は、移動端末の発明としても捉えることができる。
【００２０】
なお、上記および特許請求の範囲における括弧内の符号は、特許請求の範囲に記載された用語と後述の実施形態に記載される当該用語を例示する具体物等との対応関係を示すものである。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係る通信システムの構成を示すブロック図である。
【図２】移動端末１およびセンター２の機能構成を示すブロック図である。
【図３】マルチモーダルルート探索コントロール処理１６ｅの処理内容を示すフローチャートである。
【図４】本発明の第２実施形態におけるマルチモーダルルート探索コントロール処理１６ｅの処理内容を示すフローチャートである。
【図５】第２実施形態において端末側制御部が実行する移動時処理のフローチャートである。
【図６】第３実施形態において、端末側制御部が移動時処理においてセンタールートを受信した後に実行する処理のフローチャートである。
【発明を実施するための形態】
【００２２】
（第１実施形態）
以下、本発明の第１実施形態について説明する。図１に、本実施形態に係る通信システムの構成を示し、図２に、この通信システムの機能構成を示す。この通信システムは、移動端末１と、センター２とを備えており、移動端末１とセンター２は通信網３（例えば、インターネット等の広域通信ネットワーク）を介して通信できるようになっている。
【００２３】
移動端末１は、ユーザの移動と共に移動可能な通信端末であり、車両に搭載されていてもよいし、ユーザが携帯するようになっていてもよい。センター２は、移動端末１とは離れた位置（例えば、建物内）に設置されるようになっている。
【００２４】
この移動端末１は、無線通信部１１、位置検出部１２、表示部１３、操作部１４、端末側記憶部１５、および端末側制御部１６を備えている。
【００２５】
無線通信部１１は、通信網３と無線接続し、通信網３を介してセンター２等と通信するための増幅、周波数変換、変調、復調等を行う周知の回路である。以下、端末側制御部１６が移動端末１の外部の装置と通信を行う場合は、この無線通信部１１を用いて通信を行うものとする。
【００２６】
位置検出部１２は、移動端末１の現在位置を特定して端末側制御部１６に出力するための装置である。例えば、移動端末１が車両に搭載されるナビゲーション装置ならば、位置検出部１２としては、車速センサ、ＧＰＳ受信機、ジャイロセンサ等であってもよい。また、移動端末１がユーザに携帯されるものならば、位置検出部１２はＧＰＳ受信機であってもよい。
【００２７】
表示部１３は、ユーザに文字および画像の一方または両方を表示する装置である。操作部１４は、ユーザの入力操作（例えば、目的地入力操作）を受け付け、受け付けた操作に応じた信号を端末側制御部１６に出力する。
【００２８】
端末側記憶部１５は、図２に示すように、磁気記憶媒体、フラッシュメモリ等の不揮発性記憶媒体であり、交通情報データベース１５ａ、端末側地図データベース１５ｂ、定常公共交通機関運行データベース１５ｃ等を記憶して有している。
【００２９】
交通情報データベース１５ａは、道路毎に、当該道路の現在の混雑度の情報を含むデータである。この交通情報データベース１５ａは、後述する交通情報取得処理１６ａによって逐次更新される。
【００３０】
端末側地図データベース１５ｂは、道路データおよび施設データを含むデータである。道路データは、リンクの位置情報、種別情報、ノードの位置情報、種別情報、および、ノードとリンクとの接続関係のデータ等（すなわち、道路構成のデータ）を含んでいる。施設データは、施設毎のレコードを複数有しており、各レコードは、対象とする施設の名称情報、所在位置情報、土地地番情報、施設種類情報等を示すデータを有している。施設としては、学校、公園、コンビニエンスストア、レストラン、および、共交通機関（例えば、列車、バス、飛行機、船等）の乗降施設（例えば、駅、バス停、空港、船着き場等）がある。
【００３１】
定常公共交通機関運行データベース１５ｃは、公共交通機関（例えば、列車、バス、飛行機、船等）の定常運行状態の運行スケジュールを含むデータである。例えば、定常公共交通機関運行データベース１５ｃは、公共交通機関の路線毎に、当該路線の名称のデータ、および、当該路線において運行される各便の各乗降施設における到着時刻および出発時刻（または到着時刻および出発時刻のうちいずれか１つ）のデータを含むデータである。
【００３２】
制御部１６は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等を備えたマイクロコンピュータであり、ＣＰＵがＲＯＭまたはフラッシュメモリに記録されたプログラムを実行することで、各種処理を実現する。
【００３３】
端末側制御部１６が実行する処理としては、図２に示すように、交通情報取得処理１６ａ、ローカルマルチモーダルルート探索処理１６ｂ、センターマルチモーダルリクエスト処理１６ｃ、センターマルチモーダルルート受信処理１６ｄ、マルチモーダルルート探索コントロール処理１６ｅ等がある。
【００３４】
交通情報取得処理１６ａは、道路の現在の混雑度の情報（交通情報）を移動端末１の外部の装置（例えば、ＶＩＣＳ送信機等の交通情報送装置）から受信し、受信した道路の現在の混雑度の情報を交通情報データベース１５ａに上書き記録する処理である。端末側制御部１６は、この交通情報取得処理１６ａを、繰り返し定期的に（例えば１分に１回）実行するようになっている。
【００３５】
ローカルマルチモーダルルート探索処理１６ｂは、センター２のセンターマルチモーダルルート探索処理２３ｄ（後述する）を利用せず、交通情報データベース１５ａ、端末側地図データベース１５ｂ、定常公共交通機関運行データベース１５ｃを用いて、徒歩で移動するルート、車両を用いて移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なルートを算出する処理である。このローカルマルチモーダルルート探索処理１６ｂで算出された最適なルートを、ローカルルートという。
【００３６】
ローカルマルチモーダルルート探索処理１６ｂにおいては、端末側地図データベース１５ｂ中の道路のリンク（徒歩でまたは車両を用いて移動する区間に相当する）と、定常公共交通機関運行データベース１５ｃ中の１つの路線において隣り合っている乗降施設間の区間（公共交通機関を用いて移動する区間に相当する）から複数の区間を選択し、それら選択した区間を繋げた経路を、最適なルートとする。選択する区間を決定するアルゴリズムとしては、例えばダイクストラ法、Ａアルゴリズム等、複数のルートのコストを比較して、最もコストが低いルートを最適なルートとするアルゴリズムを採用する。ルートのコストには、そのルートを構成する各区間コストは、総和も含まれている。各区間のコストは、その区間の長さ（すなわち移動距離）、移動所要時間、料金（その区間を通行する際に課される料金であり、例えば、電車料金）のうちいずれか１つを採用してもよいし、これら３つの量から算出される値（例えばｋ１×長さ＋ｋ２×移動所要時間＋ｋ３×料金、ただし、ｋ１、ｋ２、ｋ３は所定の定数）を採用してもよいであってもよい。
【００３７】
このようなローカルマルチモーダルルート探索処理１６ｂによって算出されるローカルルートは、現在地、目的地に応じて、すべてが車で移動するルートになる場合もあれば、車で移動するルート、電車で移動するルートを組み合わせたルートになる場合もあれば、車で移動するルート、電車で移動するルート、徒歩のルートを組み合わせたルートになる場合もある。
【００３８】
センターマルチモーダルリクエスト処理１６ｃは、徒歩で移動するルート、車両を用いて移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適な組み合わせ（センタールート）を算出するよう、センター２に対して、当該現在地と当該目的地を含んだマルチモーダルルート探索要求を送信する処理である。
【００３９】
センターマルチモーダルルート受信処理１６ｄは、センターマルチモーダルリクエスト処理１６ｃによって送信したマルチモーダルルート探索要求の応答として、センター２が算出した最適なルートを受信する処理である。
【００４０】
マルチモーダルルート探索コントロール処理１６ｅは、ローカルマルチモーダルルート探索処理１６ｂ、センターマルチモーダルリクエスト処理１６ｃ、センターマルチモーダルルート受信処理１６ｄを制御する処理である。このマルチモーダルルート探索コントロール処理１６ｅの詳細な処理内容については後述する。
【００４１】
センター２は、図１に示すように、通信部２１、センター側記憶部２２、センター側制御部２３等を備えている。通信部２１は、通信網３を介して移動端末１等と通信するための増幅、周波数変換、変調、復調等を行う周知の回路である。以下、センター側制御部２３がセンター２の外部の装置と通信を行う場合は、この通信部２１を用いて通信を行うものとする。
【００４２】
センター側記憶部２２は、図２に示すように、交通情報データベース２２ａ、センター側地図データベース２２ｂ、現状公共交通機関データベース２２ｃ等を記憶して有している。
【００４３】
交通情報データベース２２ａは、道路毎に、当該道路の現在の混雑度の情報を含むデータである。この交通情報データベース２２ａは、後述する交通情報蓄積処理２３ａによって逐次更新される。
【００４４】
センター側地図データベース２２ｂは、移動端末１の端末側地図データベース１５ｂと同様の道路データおよび施設データを含むデータである。したがって、センター側地図データベース２２ｂは、端末側地図データベース１５ｂと同様、道路構成および公共交通機関の乗降施設（駅、バス停、駐車場、船着き場等）の位置を記憶する。
【００４５】
現状公共交通機関データベース２２ｃは、公共交通機関の定常運行状態の運行スケジュールのデータ、および、当該定常運行状態の運行スケジュールに対する現在の運行変化状況（例えば、変化なし、１５分遅れ、運休等）のデータ（以下、運行変化状況データという）を含むデータである。公共交通機関の定常運行状態の運行スケジュールのデータは、移動端末１の定常公共交通機関運行データベース１５ｃと同じものでよい。
【００４６】
運行変化状況データとしては、例えば、対象とする公共交通機関の路線の便を指定するデータと、その便においてどの乗降施設でどの程度の時間の遅れが発生しているかを示すデータであってもよい。また、運行変化状況データは、対象とする公共交通機関の路線の便を指定するデータと、その便が運行中止となっていることを示すデータを含んでいてもよい。この運行変化状況データは、後述する公共交通機関運行状況取得処理２３ｂによって逐次更新される。
【００４７】
センター側制御部２３は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等を備えたマイクロコンピュータであり、ＣＰＵがＲＯＭまたはフラッシュメモリに記録されたプログラムを実行することで、各種処理を実現する。
【００４８】
センター側制御部２３が実行する処理としては、図２に示すように、交通情報蓄積処理２３ａ、公共交通機関運行状況取得処理２３ｂ、マルチモーダルルート探索要求受信処理２３ｃ、センターマルチモーダルルート探索処理２３ｄ、マルチモーダルルート配信処理２３ｅ等がある。
【００４９】
交通情報蓄積処理２３ａは、道路の現在の混雑度の情報（交通情報）をセンター２の外部の装置（例えば、ＦＭ−ＶＩＣＳ送信機等の交通情報送装置）から受信し、受信した道路の現在の混雑度の情報を交通情報蓄積処理２３ａに上書き記録する処理である。センター側制御部２３は、この交通情報蓄積処理２３ａを、繰り返し定期的に（例えば１分に１回）実行するようになっている。
【００５０】
公共交通機関運行状況取得処理２３ｂは、現在の運行変化状況データをセンター２の外部のリアルタイム公共交通機関運行情報源（例えば、公共交通機関の運用団体毎に設けられた複数の運行変化状況データサーバであって、当該運用団体が運用する公共交通機関についての最新の運行変化状況データを逐次送信する運行変化状況データサーバ）から受信し、受信した変化状況データサーバを公共交通機関運行状況取得処理２３ｂに記録する処理である。センター側制御部２３は、この公共交通機関運行状況取得処理２３ｂを、繰り返し定期的に（例えば１分に１回）実行するようになっている。なお、受信してから所定時間（例えば１時間）以上経過した運行変化状況データについては削除してもよいし、しなくてもよい。
【００５１】
マルチモーダルルート探索要求受信処理２３ｃは、上述の端末側制御部１６のセンターマルチモーダルリクエスト処理１６ｃによって移動端末１から送信されたマルチモーダルルート探索要求を受信する処理である。
【００５２】
センターマルチモーダルルート探索処理２３ｄは、マルチモーダルルート探索要求受信処理２３ｃがマルチモーダルルート探索要求を受信したことに基づいて、交通情報データベース２２ａ、センター側地図データベース２２ｂ、現状公共交通機関データベース２２ｃを用いて、徒歩で移動するルート、車両を用いて移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、当該マルチモーダルルート探索要求中の現在地から目的地までの最適なルートを算出する処理である。このようにして算出されたルートを、センタールートという。
【００５３】
センターマルチモーダルルート探索処理２３ｄの具体的なアルゴリズムは、交通情報データベース１５ａ、端末側地図ＤＢ１５ｂ、定常公共交通機関運行ＤＢに代えて、交通情報データベース２２ａ、センター側地図データベース２２ｂ、現状公共交通機関データベース２２ｃを用いることを除いては、ローカルマルチモーダルルート探索処理１６ｂと同じである。
【００５４】
このようなセンターマルチモーダルルート探索処理２３ｄによって算出されるセンタールートも、ローカルルートと同様、現在地、目的地に応じて、すべてが車で移動するルートになる場合もあれば、車で移動するルート、電車で移動するルートを組み合わせたルートになる場合もあれば、車で移動するルート、電車で移動するルート、徒歩のルートを組み合わせたルートになる場合もある。
【００５５】
マルチモーダルルート配信処理２３ｅは、センターマルチモーダルルート探索処理２３ｄが算出したセンタールートをマルチモーダルルート探索要求の送信元の移動端末１に送信する処理である。
【００５６】
次に、本実施形態の通信システムの具体的な作動について説明する。まず、移動端末１のユーザが操作部１４を操作して目的地を入力したとする。すると端末側制御部１６は、マルチモーダルルート探索コントロール処理１６ｅの実行を開始する。図３に、このマルチモーダルルート探索コントロール処理１６ｅのフローチャートを示す。
【００５７】
マルチモーダルルート探索コントロール処理１６ｅにおいて端末側制御部１６は、まずステップ１１０で、入力された目的地を取得し、さらに、位置検出部１２からの信号に基づいて移動端末１の現在地を取得する。なお、ユーザが目的地に加えて経由地も操作部１４に入力していれば、その経由地も取得する。
【００５８】
続いてステップ１２０では、ローカルマルチモーダルルート探索処理１６ｂ呼び出して実行することで、ステップ１１０で取得した現在地から目的地までの（経由地を取得していればその経由地を通る）最適なローカルルートを算出する。
【００５９】
このように算出されたローカルルートは、センター２のセンターマルチモーダルルート探索処理２３ｄを利用せず、交通情報データベース１５ａ、端末側地図データベース１５ｂ、および定常公共交通機関運行データベース１５ｃを用いて、徒歩で移動するルート、車両で走行するルート、および公共交通機関を利用して移動するルート等を最適なルート中の区間の候補とした、現在地から目的地までの（経由地を取得していればその経由地を通る）最適なルートである。
【００６０】
続いてステップ１３０では、算出されたローカルルートが公共交通機関を利用している（すなわち、公共交通機関を利用するルートを含んでいる）か否かを判定し、利用していないと判定した場合、続いてステップ１３５に進み、利用していると判定した場合、続いてステップ１４０に進む。
【００６１】
ステップ１３５では、ステップ１２０で算出したローカルルートを経路案内用のルートとして記録し、マルチモーダルルート探索コントロール処理１６ｅを終了する。そしてその後、経路案内用のルートとして記録した当該ローカルルートに沿った周知の経路案内を行う。
【００６２】
ステップ１４０では、センターマルチモーダルリクエスト処理１６ｃを呼び出して実行することで、当該現在地と当該目的地（および、経由地を取得していればその経由地）を含んだマルチモーダルルート探索要求をセンター２に送信する。続いてステップ１５０では、センター２からマルチモーダルルート探索要求の応答を受信するまで待つ。
【００６３】
するとセンター２では、センター側制御部２３が、マルチモーダルルート探索要求受信処理２３ｃを実行して、上記ステップ１４０によって移動端末１から送信されたマルチモーダルルート探索要求を受信する。
【００６４】
更にセンター側制御部２３は、マルチモーダルルート探索要求受信処理２３ｃによりマルチモーダルルート探索要求を受信したことに基づいて、センターマルチモーダルルート探索処理２３ｄを実行し、交通情報データベース２２ａ、センター側地図データベース２２ｂ、および現状公共交通機関データベース２２ｃ（定常運行状態の運行スケジュールのデータおよび運行変化状況データ）を用いて、徒歩で移動するルート、車両で移動するルート、および公共交通機関を利用して移動するルート等を最適なルート中の区間の候補として、マルチモーダルルート探索要求中の当該現在地から当該目的地までの（経由地を受信していればその経由地を通る）最適なセンタールートを算出する。このようにして算出されたセンタールートは、運行変化状況データを用いて算出しているため、移動端末１において算出したローカルルートに比べて、現状の公共交通機関の運行状況をより正確に反映していると考えられる。更にセンター側制御部２３は、センターマルチモーダルルート探索処理２３ｄによって算出したセンタールートを、マルチモーダルルート探索要求の送信元の移動端末１に送信する。
【００６５】
このように、センター２は、マルチモーダルルート探索要求を受信したことに基づいて、交通情報データベース２２ａ、センター側地図データベース２２ｂ、および現状公共交通機関データベース２２ｃを用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、マルチモーダルルート探索要求中の現在地から目的地までの最適なセンタールートを算出し、算出したセンタールートを移動端末１に送信する。送信するセンタールートは、センタールートを構成する各区間の経路（例えば、各区間のリンクＩＤのリスト）、各区間の移動手段、各区間の移動所要時間、各区間の料金等が含まれたデータである。
【００６６】
すると端末側制御部１６では、センターマルチモーダルルート受信処理１６ｄによって、上記マルチモーダルルート探索要求の応答としてセンター２が算出して送信したセンタールートを受信する。すると図３のステップ１５０では、上記マルチモーダルルート探索要求の応答としてセンタールートを受信したと判定し、ステップ１６０に進む。
【００６７】
ステップ１６０では、受信したセンタールートを経路案内用のルートとして記録し、マルチモーダルルート探索コントロール処理１６ｅを終了する。そしてその後、経路案内用のルートとして記録した当該センタールートに沿った周知の経路案内を行う。
【００６８】
このように、移動端末１に、あらかじめ公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース１５ｃを備えておき、移動端末１側で公共交通機関以外（例えば、徒歩、車両）を使ったルートと公共交通機関を使ったルートを最適なルート中の区間の候補とするルート探索を行う。そして、そのルート探索において、公共交通機関を使ったほうが良いという結果になった場合に、センターに現在の運行状況を踏まえたマルチモーダル探索の依頼をかけるようにする。
【００６９】
公共交通機関を使ったルートの比較において、公共交通機関の実際の運行状態を踏まえたルートは、定常の運行状態と同じ、もしくは定常状態より悪化することしか通常はありえないため、定常状態で公共交通機関を使ったルートが算出される場合でしか、実際の運行状態を踏まえたルート算出で公共交通機関を使ったルートとなることがあり得ないと考えることができるため、上記のような実現方法を取ることで、不必要にセンター２に問い合わせることなく、マルチモーダル探索の実現が可能となる。
【００７０】
（第２実施形態）
次に、本発明の第２実施形態について説明する。本実施形態は、第１実施形態の通信システムに対して、以下に示すような端末側制御部１６およびセンター側制御部２３の処理を追加するものである。
【００７１】
まず、本実施形態におけるマルチモーダルルート探索コントロール処理１６ｅの処理内容は、図３に代えて、図４のようになる。図３と図４の処理内容は、ステップ１１０〜１６０までは同じである。しかし、図４の処理では、ステップ１３５に続いてステップ１６５を実行し、ステップ１６０に続いてステップ１７０を実行する。
【００７２】
ステップ１６５では、経路案内に使用する経路案内用ルートとされたローカルルート上で１つまたは複数の再探索ポイントを設定して、それをローカルルートに関連付けてＲＡＭまたはフラッシュメモリに記録する。
【００７３】
再探索ポイントのそれぞれは、ステップ１３５で決定および保存したローカルルート（案内に使用するルート）上の一点であり、そのローカルルートの算出の際に他のルートへの岐路となったポイントである。より具体的には、端末側制御部１６は、ステップ１２０のローカルルートの算出時に、既に説明した通り、他のルートのコストも算出する。そして端末側制御部１６は、ステップ１３５を実行してローカルルートを経路案内に使用する経路案内用ルートとした後は、ステップ１６５で、上記他のルートのうち、ローカルルート上の一点から分岐し、かつローカルルート上の他の点に合流するルート（分岐合流ルートという）をすべて抽出する。
【００７４】
そして、抽出した分岐合流ルートのそれぞれについて、増加コストを算出する。ある分岐合流ルートの増加コストの計算方法は、以下の通りである。まず、当該分岐合流ルートがローカルルートから分岐する点を分岐点Ａとし、当該分岐合流ルートがローカルルートに合流する点を合流点Ｂとし、分岐点Ａから合流点Ｂまでのローカルルート上の経路のコストＣ１を算出する。更に、分岐点Ａから合流点Ｂまでの当該分岐合流ルート上の経路のコストＣ２を算出する。そして、コストＣ１に対するコストＣ２の増加分を、当該分岐合流ルートの増加コストとする。
【００７５】
そして、抽出した分岐合流ルートから、増加コストが所定の閾値よりも小さいものを選び出し、選び出した分岐合流ルートにおける分岐点Ａ（岐路ポイント）を、再探索ポイントとして設定する。
【００７６】
あるいは、移動端末１がセンター２にマルチモーダルルート探索要求を送信する必要が特にあるのは、公共交通機関を使う可能性があるケースなので、抽出した分岐合流ルートから、増加コストが所定の閾値よりも小さいものを選び出した後、更に選び出した分岐合流ルートのうち、公共交通機関を使って移動する区間を含む分岐合流ルートを選び出し、選び出した分岐合流ルートにおける分岐点Ａ（岐路ポイント）を、再探索ポイントとして設定するようになっていてもよい。このようにすることで、更にセンター２へマルチモーダルルート探索要求を送信する回数を減らすことができる。ステップ１６５の後、図４の処理が終了する。
【００７７】
このようにして選ばれる再探索ポイントとしては、例えば、ローカルルートと分岐合流ルートのどちらに進んでもほぼ同じ距離移動後、再び合流する道路の分岐点、どちらのルートに進んでも、ほぼ同じ時間で、再び同じ駅に到着する乗換駅、そのまま自動車でローカルルートを進んでも、電車に乗り換えて分岐合流ルートを進んでも、ほぼ同じ時間経過後、次の乗換候補となる駅に到着する可能性のある乗換駅が考えられる。
【００７８】
また、センター側制御部２３も、センターマルチモーダルルート探索処理２３ｄにおいて、既に説明した通りの方法でセンタールートを算出するが、本実施形態では、その後、算出したセンタールート上で１つまたは複数の再探索ポイントを設定して、センタールートに関連付けてＲＡＭまたはフラッシュメモリに記録する。再探索ポイントの設定方法は、端末側制御部１６における具体的なローカルルート上の再探索ポイントの設定方法と同じである。
【００７９】
また、マルチモーダルルート配信処理２３ｅは、センタールートを移動端末１に送信する際、センタールートの再探索ポイントの位置の情報も、共に移動端末１に送信する。そして端末側制御部１６は、ステップ１５０で、センタールートと共に再探索ポイントの位置の情報を受信し、ステップ１６０で、当該センタールートを経路案内用のルートとして保存した後、ステップ１７０で、当該再探索ポイントの位置を、当該センタールートの再探索ポイントに設定すると共に、ＲＡＭ等の記憶媒体に記録する。このように、端末側制御部１６は、センタールートについても再探索ポイントをセンター２から受信することで設定可能となっている。ステップ１７０の後、図４の処理が終了する。
【００８０】
また、移動端末１が移動中であり、端末側制御部１６が上記ローカルルートまたはセンタールートを経路案内用のルートとして案内しているときに、図５に示す移動時処理を実行する。
【００８１】
この移動時処理において端末側制御部１６は、移動端末１が目的地に到着したか否かの判定（ステップ３１０）と、移動端末１が上記記録された当該経路案内用ルートの再探索ポイントのいずれかに対して経路案内用のルートに沿って基準距離（固定値でもよいし、移動端末１の移動速度等に応じて変化してもよい）以内の手前に接近したか否かの判定（ステップ３２０）とを、その２つの判定のどちらかの判定結果が肯定判定（ＹＥＳ）となるまで繰り返す。
【００８２】
上記のステップ３１０、３２０の繰り返しにおいて、ステップ３１０で移動端末１が目的地に到着したと判定した場合は、移動時処理を終了する。
【００８３】
また、ステップ３１０、３２０の繰り返しにおいて、ステップ３２０で移動端末１が再探索ポイントのいずれかに対して経路案内用のルートに沿って所定距離以内の手前に接近したと判定した場合、続いてステップ３３０で、再度現在地および目的地（およびあれば経由地）を取得する。具体的には、現在の経路案内用のルートの目的地を引き続き目的地とし、移動端末１の現在位置を取得し、現在の経路案内用のルートに経由地が設定されていれば、移動端末１の現在位置以降の経由地も引き続き経由地とする。
【００８４】
続いてステップ３４０では、図３のステップ１４０と同様、センターマルチモーダルリクエスト処理１６ｃを呼び出して実行することで、当該現在地と当該目的地（および、経由地を取得していればその経由地）を含んだマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）をセンター２に送信する。続いてステップ３５０では、センター２からマルチモーダルルート探索要求の応答を受信するまで待つ。
【００８５】
するとセンター２では、センター側制御部２３が、マルチモーダルルート探索要求受信処理２３ｃを実行して、上記ステップ３４０によって移動端末１から送信されたマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）を受信する。
【００８６】
更にセンター側制御部２３は、マルチモーダルルート探索要求受信処理２３ｃにより当該マルチモーダルルート探索要求を受信したことに基づいて、センターマルチモーダルルート探索処理２３ｄを実行し、交通情報データベース２２ａ、センター側地図データベース２２ｂ、および現状公共交通機関データベース２２ｃ（定常運行状態の運行スケジュールのデータおよび運行変化状況データ）を用いて、徒歩で移動するルート、車両で移動するルート、および公共交通機関を利用して移動するルート等を最適なルート中の区間の候補として、マルチモーダルルート探索要求中の当該現在地から当該目的地までの（経由地を受信していればその経由地を通る）最適なセンタールート（再探索ポイント用センタールートに相当する）を算出する。このようにして算出されたセンタールートは、運行変化状況データを用いて算出しているため、移動端末１において算出したローカルルートに比べて、現状の公共交通機関の運行状況をより正確に反映していると考えられる。また、このようにして算出されたセンタールート（再探索ポイント用センタールート）は、図３のステップ１５０で端末側制御部１６が受信したセンタールートよりも遅いタイミングで算出されているので、より最新の公共交通機関の運行状況を反映している。
【００８７】
更にセンター側制御部２３は、センターマルチモーダルルート探索処理２３ｄによって算出したセンタールート上の再探索ポイントを既に説明したものと同じ方法で設定し、当該センタールートおよび再探索ポイントを、マルチモーダルルート探索要求の送信元の移動端末１に送信する。
【００８８】
すると端末側制御部１６では、センターマルチモーダルルート受信処理１６ｄによって、上記マルチモーダルルート探索要求の応答としてセンター２が算出して送信したセンタールート（再探索ポイント用センタールートに相当する）およびセンタールート上の再探索ポイントを受信する。すると図５のステップ３５０では、上記マルチモーダルルート探索要求の応答としてセンタールートを受信したと判定し、ステップ３６０に進む。
【００８９】
ステップ３６０では、受信したセンタールートを新たな経路案内用のルートとして記録することで、それまでの経路案内用ルートに代えて、この新たな経路案内用のルートで案内を開始する。
【００９０】
更にステップ３７０では、受信した再探索ポイントの位置を、経路案内用ルートとして用いるセンタールートの再探索ポイントに設定すると共に、ＲＡＭ等の記憶媒体に記録し、その後、再度ステップ３１０に処理を戻す。
【００９１】
以上説明した通り、移動端末１の端末側制御部１６は、ローカルルートまたはセンタールートを経路案内用ルートとする際（図４のステップ１３５、１６０）に、ルート選択の際に岐路となった１つまたは複数の地点を再探索ポイントとし、それらを経路案内用ルートと共記録しておく（１６５、１７０）。
【００９２】
また、センター制御部２３は、センターマルチモーダルルート探索処理２３ｄにおいて、算出したセンタールート上に１つまたは複数の再探索ポイントを設定し、マルチモーダルルート配信処理２３ｅにおいて、それら複数の再探索ポイントを、センタールート（再探索ポイント用センタールートに相当する）と共に移動端末１に送信し、端末側制御部１６は、その再探索ポイントを受信してセンタールートの再探索ポイントに設定し、記録する。
【００９３】
そして、端末側制御部１６は、経路案内用のルートの案内に従って移動端末１が移動中である間は、移動端末１がその再探索ポイントへの接近を検出した場合に、再びセンター２にマルチモーダルルート探索要求を行うことで、公共交通機関の最新の運行状況に基づいて作成されたセンタールートを経路案内用のルートとすることができる。
【００９４】
例えば、移動端末１で当初は、ある分岐点Ａまでは車両で走行し、分岐点Ａから合流点Ｂの間は電車に乗り換えて移動するようなセンタールートが経路案内用ルートとして採用されていたとする。ここで、分岐点Ａから合流点Ｂまでは、車両で移動することもでき、車両で行っても電車で行っても同時刻に合流点Ｂに合流できるが、電車のほうが安いという理由で、電車を用いるセンタールートが算出されたとする。
【００９５】
ところが、実際に分岐点Ａ（再探索ポイント）に接近した際に、移動端末１がセンター２へマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）を送信すると、当該電車が遅延しており、その過結果、分岐点Ａからも車両を用いた方が合流点Ｂへの到着が早くなり、その結果、センター２からは車両でそのまま合流点Ｂへ向かう新たなセンタールート（再探索ポイント用センタールートに相当する）を送信する。そして移動端末１では、この新たなセンタールートに従って、早く合流点Ｂに到達することができる。
【００９６】
このようになっていることで、一旦経路案内用のルートを決定し、そのルートで案内を行い、その案内に従って移動端末１が移動しているときも、センター２にマルチモーダルルート探索要求を送信することで、公共交通機関の運行状況の変化に応じて柔軟に経路案内用のルートを変更することができる。また、移動端末１が再探索ポイントへの接近を検出した場合に、センター２にマルチモーダルルート探索要求を行うので、無駄に多数回センター２に問い合わせしてしまう可能性を抑えることができる。
【００９７】
（第３実施形態）
次に、本発明の第３実施形態について説明する。本実施形態が第２実施形態と異なる点は３つある。
【００９８】
まず第１に、本実施形態の端末側制御部１６は、図５のステップ３４０でセンター２に送信するマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）に、更に、現在の経路案内用のルート（ローカルルートの場合もあればセンタールートの場合もある）のデータ（各区間の経路、各区間の移動手段、各区間の移動所要時間、各区間の料金等）を含める。
【００９９】
第２に、センター側制御部２３は、マルチモーダルルート配信処理２３ｅの実行において、図５のステップ３４０で移動端末１から送信されたマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）を受信したことに基づいて算出したセンタールート（再探索ポイント用センタールートに相当する）を移動端末１に送信すると共に、移動端末１から受信したマルチモーダルルート探索要求に含まれる上記経路案内用のルートの不利情報を取得して移動端末１に送信する。
【０１００】
この不利情報とは、上記経路案内用のルートについて算出された各区間の移動所要時間に対する、現状公共交通機関データベース２２ｃの現在の情報に基づいて特定される上記経路案内用のルートの各区間の移動所要時間の増加量（すなわち、遅延時間）を示す情報を含むと共に、上記経路案内用のルートの各区間の料金の情報も含む。
【０１０１】
したがって、マルチモーダルルート配信処理２３ｅにおいてセンター側制御部２３は、移動端末１から受信した再探索ポイント用マルチモーダルルート探索要求に含まれる経路案内用のルートの各区間の移動所要時間を、現在の現状公共交通機関データベース２２ｃ（特に、運行変化状況データ）に基づいて算出し、算出した移動所要時間に基づいて、上記遅延時間を算出し、算出した遅延時間を不利情報に含めるようになっていればよい。
【０１０２】
例えば、不利情報には、経路案内用のルート上の公共交通機関を利用する区間のすべてについて、当該区間の移動所要時間の情報を含めてもよい。
【０１０３】
また、不利情報には、経路案内用のルート上の特定の区間における電車ダイヤの乱れによる定常運行に対する遅延時間の情報が含まれていてもよい。このような情報としては、例えば、経路案内用のルートに含まれる電車移動の区間において、利用する予定の便が１５分遅れて各駅に到着するという情報がある。
【０１０４】
また、経路案内用のルートは電車移動する区間を含んでおり、センターマルチモーダルルート探索処理２３ｄによって今回算出された新たなセンタールート（再探索ポイント用センタールートに相当する）は、その区間の代わりに車両で移動する区間を含んでいる場合に、その経路案内用のルート上の当該電車移動区間の移動所要時間を不利情報に含めてもよい。
【０１０５】
また、経路案内用のルートにおける各区間の所要料金について、端末側制御部１６のローカルマルチモーダルルート探索処理１６ｂで算出した所要料金とセンター側制御部２３のセンターマルチモーダルルート探索処理２３ｄで算出した所要料金との差（例えば、料金に変化はないという情報）を不利情報に含めてもよい。
【０１０６】
第３に、端末側制御部１６が図５の移動時処理においてセンタールートを受信した後のステップ３６０、３７０の処理内容が、本実施形態では図６に示すような処理内容に変更されている。
【０１０７】
具体的には、図５のステップ３５０で、直前に送信したマルチモーダルルート探索要求の応答としてセンタールート（および不利情報）を受信したと判定した場合、続いて図６のステップ３６１に進む。
【０１０８】
ステップ３６１では、直前に受信したセンタールート（再探索ポイント用センタールートに相当する）と経路案内用ルートを比較する。この比較は、双方のルートの乖離が大きいかどうかを判断するために行う処理である。具体的には、当該センタールートの各区間の経路、移動手段（徒歩か、車両、列車等）および移動所要時間を比較する。
【０１０９】
続いてステップ３６２では、ステップ３６１の比較結果を利用して、当該センタールートと当該経路案内用ルートの乖離が大きいか否かを、所定の基準に従って判定する。
【０１１０】
所定の基準としては、例えば、（１）センタールートと経路案内用ルートの各区間の経路、移動手段、および移動所要時間が完全に同じである場合、および、（２）センタールートと経路案内用ルートの各区間の経路および移動手段は完全に一致するが、移動所要時間は少なくとも一部が異なっている場合、という２つの場合は、当該センタールートと当該経路案内用ルートの乖離が大きくないと判定する。そして、センタールート各区間の経路および移動手段のすくなくともいずれかは経路案内用ルートと一致しない場合（当然所要時間や料金も変化している）には、当該センタールートと当該経路案内用ルートの乖離が大きいと判定する。
【０１１１】
乖離が大きいと判定した場合は、続いてステップ３６３および３６４を実行した上でステップ３６５に処理を進める。乖離が大きくないと判定した場合は、直ちにステップ３６５に処理を進める。
【０１１２】
ステップ３６３では、センター２から受信した不利情報を利用して経路案内用ルートの再計算を行う。ただしこの再計算においては、当初の経路案内用ルートの各区間の経路および移動手段は変更せず、単に当該経路案内用ルートの各区間の移動所要時間および料金の再計算を行う。このような再計算により、例えば、「経路案内用ルートの区間αを電車移動すると、センター２からの不利情報によれば、センタールートよりも３０分遅れ、料金は同一となる。したがってルート全体では、センタールートよりも３０分の遅延で、料金は同一に維持される」等が明らかになる。
【０１１３】
続いてステップ３６４では、ステップ３６３の算出結果を利用して、ステップ３６１と同様の方法で、センタールートと経路案内用ルートを比較する。この比較により、例えば、「センタールートを採用すると、経路案内用ルートを採用するより１０分早く目的地に到着する（ただし、どのみち当初の経路案内用ルートの所要時間計算結果より２０分遅い）が、必要な料金は１０００円高くなる」ということが明らかになる。
【０１１４】
ステップ３６５では、センタールートの方が経路案内用ルートよりも有利か否かを判定する。この判定基準としては、例えば、センタールートを現在位置から目的地まで移動するのに要する時間ＴＣと、経路案内用ルートを現在位置から目的地まで移動するのに要する時間ＴＬのうち、時間ＴＣの方が小さければセンタールートの方が有利であると判定し、そうでなければ経路案内用ルートの方が有利であると判定するという基準を採用してもよい。
【０１１５】
あるいは、この判定基準としては、例えば、センタールートを現在位置から目的地まで移動するのに要する料金ＣＣと、経路案内用ルートを現在位置から目的地まで移動するのに要する料金ＣＬのうち、料金ＣＣの方が小さければセンタールートの方が有利であると判定し、そうでなければ経路案内用ルートの方が有利であると判定するという基準を採用してもよい。
【０１１６】
あるいは、ｆ（Ｔ、Ｃ）を値Ｔの単調増加関数であり、かつ値Ｃの単調増加関数であるとする。このような関数としては例えばＣ＋Ｔがある。そして、ｆ（ＴＣ、ＣＣ）、ｆ（ＴＬ、ＣＬ）のうち、ｆ（ＴＣ、ＣＣ）の方が小さければセンタールートの方が有利であると判定し、そうでなければ経路案内用ルートの方が有利であると判定するという基準を採用してもよい。
【０１１７】
なお、あらかじめ移動端末１のユーザが操作部１４を操作して有利性の判断基準を設定入力し、端末側制御部１６は、入力された判断基準をフラッシュメモリ等に登録し、登録した判断基準に基づいて、センタールートと経路案内用ルートのどちらが有利かを判定するようになっていてもよい。
【０１１８】
例えば、端末制御部１６は、表示部１３に、有利性の判断基準として、「料金優先」、「時間優先」等の複数種類の選択肢を提示し、ユーザは、操作部１４を操作して、それら複数種類の選択肢のいずれか１つを選択する入力を行えるようになっていてもよい。
【０１１９】
この場合、ユーザが「料金優先」を選択する入力を行った場合、端末制御部１６は、ステップ３６５において、経路案内用ルートとセンタールートで、料金は経路案内用ルートの方が少なく済むが、時間はセンタールートの方が少なく済むような場合、経路案内用ルートの方が有利であると判定する。また、ユーザが「時間優先」を選択する入力を行った場合、端末制御部１６は、同様の場合で、センタールートの方が有利であると判定する。このように、ユーザが有利性の判定基準を入力することで、ユーザの価値観に応じたルート選択が可能となる。
【０１２０】
あるいは、ステップ３６５では、表示部１３に画像または文字でステップ３６１（ステップ３６４を実行した場合はステップ３６４）の比較結果（経路の違い、移動手段の違い、移動所要時間の違い、料金の違い等）を表示部１３に表示させるか、あるいは、図示しないスピーカを用いて音声で報知し、その比較結果に基づいてユーザにどちらが有利か判断させるようにしてもよい。この場合、ユーザは、経路案内用ルートとセンタールートのどちらがより有利であるかの判断結果を操作部１４を用いて入力し、端末側制御部１６は、入力された判断結果に従って、どちらが有利かを判定する。
【０１２１】
また、上述のようにあらかじめ移動端末１のユーザが操作部１４を操作して有利性の判断基準を設定入力した場合であっても、その後の、上述のような操作部１４を用いたユーザの選択に従って、登録した判断基準を随時変化させる学習処理を行うようになっていてもよい。例えば、端末側制御部１６は、ステップ３６５で、登録した判断基準に基づいてセンタールートと経路案内用ルートのいずれか一方をより有利なルートとして暫定的に選択し、その暫定的な選択結果をユーザに（音声または映像で）報知すると共に、この選択でよいか否かを問い合わせるメッセージも報知するようになっていてもよい。そして、ユーザが操作部１４を用いてこの選択でよい旨を入力した場合は、暫定的な選択結果通りに選択を確定し、ユーザが操作部１４を用いてこの選択はよくない旨を入力した場合は、暫定的な選択結果とは反対の選択を確定する。そして、経路案内用ルートかセンタールートかの確定した選択結果を蓄積していき、選択結果の蓄積数が所定数（例えば１０個）を超え、かつ、どちらかのルートを選択した選択結果が所定比率（例えば８０％）以上である場合は、その所定比率以上選択されたルートを薦めるメッセージを、上述の、この選択でよいか否かを問い合わせるメッセージと共にユーザに報知するようになっていてもよい。具体的には、「あなたの過去の判断から推測すると、センターのルートの方がお薦めですが、この選択でよいですか？」というメッセージを報知してもよい。
【０１２２】
ステップ３６５でセンタールートの方が有利であると判定した場合、続いてステップ３６６に進み、当該センタールートを新たな経路案内用のルートとして記録することで、それまでの経路案内用ルートに代えて、この新たな経路案内用のルートで案内を開始する。
【０１２３】
ステップ３６５で、センタールートの方が有利でない（経路案内用ルートの方が有利である）と判定した場合、続いてステップ３６７に進み、現在の経路案内用ルートをそのまま使用し続ける。ただし、ステップ３６３を実行している場合は、料金および所要時間の表示を、ステップ３６３の計算結果に従って修正する。
【０１２４】
ステップ３６６、３６７に続いては、ステップ３６８で、新たな経路案内用ルートに対して、図４のステップ１６５、１７０、または図５のステップ３７０と同様の方法で、当該経路案内用ルート上の１つまたは複数の再探索ポイントの位置を決定して、経路案内用ルートに関連付けてＲＡＭまたはフラッシュメモリに記録する。
【０１２５】
ステップ３６８の後は、図５のステップ３１０に処理を戻す。そして、移動端末１でその再探索ポイントの接近を検出した場合にだけ、再びセンター２に最新の運行状態でのマルチモーダル探索の問い合わせを行うこととする。上記のような実現方法を取ることで、不必要にセンター２に問い合わせすることなく、マルチモーダルルートによる移動の実現が可能となる。
【０１２６】
また、ステップ３６５、３６６、３６７のように、センター２で算出されたセンタールート（再探索ポイント用センタールート）と、現在の経路案内用ルートのうちどちらが有利かを判定し、有利な方を経路案内用のルートとして使用することで、より適切な経路案内を行うことができる。
【０１２７】
なお、上記各実施形態では、端末側制御部１６が、図３のステップ１２０を実行することでローカルマルチモーダルルート探索手段の一例として機能し、ステップ１３０を実行することで判定手段の一例として機能し、ステップ１３５を実行することでローカルルート記録手段の一例として機能し、ステップ１４０を実行することでセンターマルチモーダルリクエスト手段の一例として機能し、ステップ１６０を実行することでセンタールート記録手段の一例として機能し、ステップ１６５、１７０を実行することで再探索ポイント設定手段（１６５、１７０）の一例として機能し、ステップ３４０を実行することで再探索ポイント用センターマルチモーダルリクエスト手段の一例として機能し、ステップ３６０またはステップ３６２〜３６８を実行することでセンタールート使用手段の一例として機能する。
【０１２８】
また、センター側制御部２３が、マルチモーダルルート探索要求受信処理２３ｃを実行することでマルチモーダルルート探索要求受信手段の一例として機能し、センターマルチモーダルルート探索処理２３ｄを実行することでセンターマルチモーダルルート探索手段の一例として機能し、マルチモーダルルート配信処理２３ｅを実行することでマルチモーダルルート配信手段の一例として機能する。
【０１２９】
（他の実施形態）
以上、本発明の実施形態について説明したが、本発明の範囲は、上記実施形態のみに限定されるものではなく、本発明の各発明特定事項の機能を実現し得る種々の形態を包含するものである。
【０１３０】
例えば、公共交通機関を利用せずに移動するルートとしては、徒歩で移動するルート、車両を用いて移動するルートを挙げているが、公共交通機関を利用せずに移動するルートとしては、車で移動するルートのみを採用してもよいし、徒歩で移動するルートのみを採用してもよい。
【０１３１】
また、上記第１実施形態の図３のステップ１４０で、端末側制御部１６がマルチモーダルルート探索要求をセンター２に送信しているが、このマルチモーダルルート探索要求に、直前のステップ１２０で算出したローカルルートの各区間の経路のデータを含めるようになっていてもよい。その場合、このマルチモーダルルート探索要求を受信したセンター側制御部２３は、センタールートを算出した際、受信したローカルルートと算出したセンタールートが同じ経路であるか否かを判定し、同じでなければ第１実施形態と同様にセンタールートを移動端末１に送信し、同じであれば、センタールートの代わりに、ローカルルートをそのまま使用してよい旨を示すデータを移動端末１に送信するようになっていてもよい。このようにすることで、不必要な場合にまで移動端末１にセンタールートの実体を送信する必要がなくなる。なお、端末側制御部１６は、センタールートのデータではなく、ローカルルートをそのまま使用してよい旨を示すデータを受信した場合は、ステップ１３５に進み、ステップ１２０で算出したローカルルートを経路案内用のルートとして記録するようになっていてもよい。
【０１３２】
また、第２実施形態では、経路案内用のルートの案内に従って移動端末１の移動中は、移動端末１が再探索ポイントへの接近を検出した場合に、再びセンター２にマルチモーダルルート探索要求を行うようになっているが、移動端末１の移動中は、移動端末１が再探索ポイントへの接近を検出した場合以外の場合（例えば、ユーザが操作部１４に対して再探索の操作を行った場合等）にも、再びセンター２にマルチモーダルルート探索要求を行うようになっていてもよい。
【０１３３】
つまり、経路案内用のルートの案内に従って移動端末１の移動中は、少なくとも、移動端末１が再探索ポイントへの接近を検出した場合を選択して、再びセンター２にマルチモーダルルート探索要求を行うようになっていれば足りる。このようにすることの意義は、無駄に多くマルチモーダルルート探索要求を行う可能性を低減することにあるので、他の有利な場合にマルチモーダルルート探索要求を行うことまでを排除するものではない。
【０１３４】
また、上記第３実施形態では、不利情報は、経路案内用ルートについて移動端末１で算出された各区間の移動所要時間に対する、現状公共交通機関データベース２２ｃの情報に基づいて特定される上記経路案内用ルートの各区間の移動所要時間の増加量（すなわち、遅延時間）そのものを示す情報を含んでいるが、不利情報は、かならずしもこのような情報に限らず、このような遅延時間の情報が移動端末１で算出できるようにするための情報であればよい。したがって、経路案内用ルートについて算出された各区間の移動所要時間は、移動端末１が既に取得していることに鑑みれば、不利情報に含めるのは、現状公共交通機関データベース２２ｃの情報に基づいて特定される上記経路案内用ルートの各区間の移動所要時間の情報であってもよい。
【０１３５】
また、上記実施形態において、センター２は、１台の装置として記載されているが、センター２は、互いに通信を行うことで協働してセンター２の機能を実現する複数台の装置によって構成されていてもよい。
【０１３６】
また、上記の実施形態において、端末側制御部１６、センター側制御部２３がプログラムを実行することで実現している各機能は、それらの機能を有するハードウェア（例えば回路構成をプログラムすることが可能なＦＰＧＡ）を用いて実現するようになっていてもよい。
【符号の説明】
【０１３７】
１ 移動端末
２ センター
１５ 端末側記憶部
１５ｂ 端末側地図データベース
１５ｃ 定常公共交通機関運行データベース
１６ 端末側制御部
１６ｂ ローカルマルチモーダルルート探索処理
１６ｃ センターマルチモーダルリクエスト処理
１６ｄ センターマルチモーダルルート受信処理
１６ｅ マルチモーダルルート探索コントロール処理
２２ センター側記憶部
２２ｂ センター側地図データベース
２２ｃ 現状公共交通機関データベース
２３ センター側制御部
２３ｂ 公共交通機関運行状況取得処理
２３ｃ マルチモーダルルート探索要求受信処理
２３ｄ センターマルチモーダルルート探索処理
２３ｅ マルチモーダルルート配信処理
【技術分野】
【０００１】
本発明は、通信システムおよび移動端末に関するものである。
【背景技術】
【０００２】
徒歩、車、公共交通機関（例えば列車、バス）等の移動手段を組み合わせ、また時々刻々変化する運行状態（道路の渋滞、公共交通機関の遅れなど）を考慮した最適ルートの探索を実施するためには、全ての情報を理想的に揃えやすいセンターで、各移動端末からの問い合わせに応じてルート探索計算を行う技術が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−２９６０７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、そうした実現方法をとる場合には、問い合わせを行う端末の増加に伴い、センター側の負荷が集中するという問題がある。また、逐次問い合わせするために、通信コストがその都度かかるという問題もある。
【０００５】
本発明は上記問題点に鑑み、車、公共交通機関等の移動手段を組み合わせ、また時々刻々変化する運行状態（道路の渋滞、公共交通機関の遅れなど）を考慮した最適ルートの探索において、センターへの問い合わせを必要最低限にすることで、効率的なマルチモーダルルート探索のセンター運用を可能とすることを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するための請求項１に記載の発明は、移動端末（１）と、前記移動端末（１）と通信可能なセンター（２）とを備えた通信システムであって、前記移動端末（１）は、道路構成および公共交通機関の乗降施設の位置を含む端末側地図データベース（１５ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）とを記憶する端末側記憶部（１５）、および、端末側制御部（１６）を備え、前記センター（２）は、道路構成および前記公共交通機関の乗降施設の位置を含むセンター側地図データベース（２２ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールおよび定常運行状態の運行スケジュールに対する現在の運行変化状況を含む現状公共交通機関データベース（２２ｃ）とを記憶する前記センター側記憶部（２２）、および、センター側制御部（２３）を備え、前記端末側制御部（１６）は、前記センター（２）を利用せず、前記端末側地図データベース（１５ｂ）および前記定常公共交通機関運行データベース（１５ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なローカルルートを算出するローカルマルチモーダルルート探索手段（１２０）と、前記ローカルマルチモーダルルート探索手段（１２０）によって算出された前記ローカルルートが公共交通機関を利用しているか否かを判定する判定手段（１３０）と、前記判定手段（１３０）が利用していないと判定したことに基づいて、前記ローカルルートを経路案内用のルートとして記録するローカルルート記録手段（１３５）と、前記判定手段（１３０）が利用していると判定したことに基づいて、前記現在地と前記目的地を含んだマルチモーダルルート探索要求を前記センター（２）に送信するセンターマルチモーダルリクエスト手段（１４０）と、を備え、前記センター側制御部（２３）は、前記センターマルチモーダルリクエスト手段（１４０）によって前記移動端末（１）から送信された前記マルチモーダルルート探索要求を受信するマルチモーダルルート探索要求受信手段（２３ｃ）と、前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適なセンタールートを算出するセンターマルチモーダルルート探索手段（２３ｄ）と、前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記センタールートを前記移動端末（１）に送信するマルチモーダルルート配信手段（２３ｅ）と、を備え、更に前記端末側制御部（１６）は、前記センターマルチモーダルリクエスト手段（１４０）が送信した前記マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記センタールートを受信したことに基づいて、前記センタールートを経路案内用のルートとして記録するセンタールート記録手段（１６０）を備えたことを特徴とする通信システムである。
【０００７】
このように、移動端末１に、あらかじめ公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）を備えておき、移動端末（１）側で公共交通機関以外（例えば、徒歩、車両）を使ったルートと公共交通機関を使ったルートを最適なルート中の区間の候補とするルート探索を行う。そして、そのルート探索において、公共交通機関を使ったほうが良いという結果になった場合に、センターに現在の運行状況を踏まえたマルチモーダル探索の依頼をかけるようにする。
【０００８】
公共交通機関を使ったルートの比較において、公共交通機関の実際の運行状態を踏まえたルートは、定常の運行状態と同じ、もしくは定常状態より悪化することしか通常はありえないため、定常状態で公共交通機関を使ったルートが算出される場合でしか、実際の運行状態を踏まえたルート算出で公共交通機関を使ったルートとなることがあり得ないと考えることができるため、上記のような実現方法を取ることで、不必要にセンター（２）に問い合わせることなく、マルチモーダル探索の実現が可能となる。
【０００９】
また、請求項２に記載の発明は、請求項１に記載の通信システムにおいて、更に前記端末側制御部（１６）は、前記ローカルルートおよび前記センタールートのうち、経路案内用のルートとするルート上に１つまたは複数の再探索ポイントを設定する再探索ポイント設定手段（１６５、１７０）を備え、更に前記端末側制御部（１６）は、前記経路案内用のルートを案内しているときに、前記移動端末（１）が前記再探索ポイントのいずれかに対して前記経路案内用のルートに沿って基準距離以内の手前に接近したか否かを判定し、接近したと判定したことに基づいて、現在地と前記目的地を含んだ再探索ポイント用マルチモーダルルート探索要求を前記センター（２）に送信する再探索ポイント用センターマルチモーダルリクエスト手段（３４０）を備え、前記センター側制御部（２３）の前記マルチモーダルルート探索要求受信手段（２３ｃ）は更に、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）によって前記移動端末（１）から送信された前記再探索ポイント用マルチモーダルルート探索要求を受信し、前記センターマルチモーダルルート探索手段（２３ｄ）は更に、前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記再探索ポイント用マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記再探索ポイント用マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適な再探索ポイント用センタールートを算出し、前記マルチモーダルルート配信手段（２３ｅ）は更に、前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記再探索ポイント用センタールートを前記移動端末（１）に送信し、更に前記端末側制御部（１６）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（１４０）が送信した前記再探索ポイント用マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記再探索ポイント用センタールートを受信したことに基づいて、前記再探索ポイント用センタールートを経路案内用のルートとして使用するセンタールート使用手段（３６０、３６２〜３６８）を備えたことを特徴とする。
【００１０】
このように、端末側制御部（１６）は、再探索ポイントを設定して記録しておき、移動端末（１）の移動中は、移動端末（１）がその再探索ポイントへの接近を検出した場合を選んで、センター（２）に再探索ポイント用マルチモーダルルート探索要求を行うことで、公共交通機関の最新の運行状況に基づいて作成された再探索ポイント用センタールートを経路案内用ルートとすることができる。
【００１１】
このようになっていることで、一旦経路案内用のルートを決定し、そのルートで案内を行い、その案内に従って移動端末（１）が移動しているときも、センター（２）にマルチモーダルルート探索要求を送信することで、公共交通機関の運行状況の変化に応じて柔軟に経路案内用のルートを変更することができる。また、移動端末（１）が再探索ポイントへの接近を検出した場合を選んで、センター（２）にマルチモーダルルート探索要求を行うので、無駄に多数回センター（２）に問い合わせしてしまう可能性を抑えることができる。
【００１２】
また、請求項３に記載の発明は、請求項２に記載の通信システムにおいて、 前記センターマルチモーダルルート探索手段（２３ｄ）は、算出した前記センタールート上に１つまたは複数の再探索ポイントを設定し、前記マルチモーダルルート配信手段（２３ｅ）は、前記センターマルチモーダルルート探索手段（２３ｄ）が設定した前記１つまたは複数の再探索ポイントを、前記移動端末（１）に送信し、前記再探索ポイント設定手段（１６５、１７０）は、前記マルチモーダルルート配信手段（２３ｅ）によって送信された前記再探索ポイントを、前記経路案内用のルート上の再探索ポイントとして設定することを特徴とする。
【００１３】
このように、端末側制御部（１６）は、センタールートと共に再探索ポイントを受信し、移動端末（１）の移動中は、移動端末（１）がその再探索ポイントへの接近を検出した場合にのみ、センター（２）に再探索ポイント用マルチモーダルルート探索要求を行うことで、公共交通機関の最新の運行状況に基づいて作成された再探索ポイント用センタールートを経路案内用ルートとすることができる。
【００１４】
このようになっていることで、一旦経路案内用のルートを決定し、そのルートで案内を行い、その案内に従って移動端末（１）が移動しているときも、センター（２）にマルチモーダルルート探索要求を送信することで、公共交通機関の運行状況の変化に応じて柔軟に経路案内用のルートを変更することができる。また、移動端末（１）が再探索ポイントへの接近を検出した場合を選んで、センター（２）にマルチモーダルルート探索要求を行うので、無駄に多数回センター（２）に問い合わせしてしまう可能性を抑えることができる。
【００１５】
また、請求項４に記載の発明は、請求項２または３に記載の通信システムにおいて、前記センタールート使用手段（３６０、３６２〜３６８）は、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを、前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する時間および前記経路案内用のルートを現在位置から目的地まで移動するのに要する時間と、前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する料金および前記経路案内用のルートを現在位置から目的地まで移動するのに要する料金と、ユーザの選択操作と、のうちいずれか１つまたは複数に基づいて判定し、有利であると判定した場合に、前記再探索ポイント用センタールートを新たな経路案内用のルートとして使用し、有利でないと判定した場合に、前記経路案内用のルートをそのまま経路案内用のルートとして使用することを特徴とする。
【００１６】
このように、センター（２）で算出された再探索ポイント用センタールートと経路案内用のルートのうちどちらが有利かを判定し、有利な方を経路案内用のルートとして使用することで、より適切な経路案内を行うことができる。
【００１７】
また、請求項５に記載の発明は、請求項４に記載の通信システムにおいて、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）は、前記再探索ポイント用マルチモーダルルート探索要求に前記経路案内用のルートを含め、前記マルチモーダルルート配信手段（２３ｅ）は、前記再探索ポイント用マルチモーダルルート探索要求に含まれる前記経路案内用のルートと、前記現状公共交通機関データベース（２２ｃ）に基づいて、少なくとも当該経路案内用ルートの各区間の現状の移動所要時間に関する不利情報を取得し、その取得した不利情報を前記再探索ポイント用センタールートと共に前記移動端末（１）に送信し、前記センタールート使用手段（３６２〜３６８）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）が送信した前記不利情報を利用して前記経路案内用のルートの各区間の移動所要時間を再計算し、再計算した移動所要時間を用いて、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを判定することを特徴とする。
【００１８】
このように、移動端末（１）で算出した経路案内用のルート自体の移動所要時間も、センター（２）の現状公共交通機関データベース（２２ｃ）に基づいて再計算することで、より適切な経路案内用のルートと再探索ポイント用センタールートの有利性の比較判定を行うことができる。
【００１９】
また、請求項６に記載のように、請求項１に記載の発明の特徴は、移動端末の発明としても捉えることができる。
【００２０】
なお、上記および特許請求の範囲における括弧内の符号は、特許請求の範囲に記載された用語と後述の実施形態に記載される当該用語を例示する具体物等との対応関係を示すものである。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係る通信システムの構成を示すブロック図である。
【図２】移動端末１およびセンター２の機能構成を示すブロック図である。
【図３】マルチモーダルルート探索コントロール処理１６ｅの処理内容を示すフローチャートである。
【図４】本発明の第２実施形態におけるマルチモーダルルート探索コントロール処理１６ｅの処理内容を示すフローチャートである。
【図５】第２実施形態において端末側制御部が実行する移動時処理のフローチャートである。
【図６】第３実施形態において、端末側制御部が移動時処理においてセンタールートを受信した後に実行する処理のフローチャートである。
【発明を実施するための形態】
【００２２】
（第１実施形態）
以下、本発明の第１実施形態について説明する。図１に、本実施形態に係る通信システムの構成を示し、図２に、この通信システムの機能構成を示す。この通信システムは、移動端末１と、センター２とを備えており、移動端末１とセンター２は通信網３（例えば、インターネット等の広域通信ネットワーク）を介して通信できるようになっている。
【００２３】
移動端末１は、ユーザの移動と共に移動可能な通信端末であり、車両に搭載されていてもよいし、ユーザが携帯するようになっていてもよい。センター２は、移動端末１とは離れた位置（例えば、建物内）に設置されるようになっている。
【００２４】
この移動端末１は、無線通信部１１、位置検出部１２、表示部１３、操作部１４、端末側記憶部１５、および端末側制御部１６を備えている。
【００２５】
無線通信部１１は、通信網３と無線接続し、通信網３を介してセンター２等と通信するための増幅、周波数変換、変調、復調等を行う周知の回路である。以下、端末側制御部１６が移動端末１の外部の装置と通信を行う場合は、この無線通信部１１を用いて通信を行うものとする。
【００２６】
位置検出部１２は、移動端末１の現在位置を特定して端末側制御部１６に出力するための装置である。例えば、移動端末１が車両に搭載されるナビゲーション装置ならば、位置検出部１２としては、車速センサ、ＧＰＳ受信機、ジャイロセンサ等であってもよい。また、移動端末１がユーザに携帯されるものならば、位置検出部１２はＧＰＳ受信機であってもよい。
【００２７】
表示部１３は、ユーザに文字および画像の一方または両方を表示する装置である。操作部１４は、ユーザの入力操作（例えば、目的地入力操作）を受け付け、受け付けた操作に応じた信号を端末側制御部１６に出力する。
【００２８】
端末側記憶部１５は、図２に示すように、磁気記憶媒体、フラッシュメモリ等の不揮発性記憶媒体であり、交通情報データベース１５ａ、端末側地図データベース１５ｂ、定常公共交通機関運行データベース１５ｃ等を記憶して有している。
【００２９】
交通情報データベース１５ａは、道路毎に、当該道路の現在の混雑度の情報を含むデータである。この交通情報データベース１５ａは、後述する交通情報取得処理１６ａによって逐次更新される。
【００３０】
端末側地図データベース１５ｂは、道路データおよび施設データを含むデータである。道路データは、リンクの位置情報、種別情報、ノードの位置情報、種別情報、および、ノードとリンクとの接続関係のデータ等（すなわち、道路構成のデータ）を含んでいる。施設データは、施設毎のレコードを複数有しており、各レコードは、対象とする施設の名称情報、所在位置情報、土地地番情報、施設種類情報等を示すデータを有している。施設としては、学校、公園、コンビニエンスストア、レストラン、および、共交通機関（例えば、列車、バス、飛行機、船等）の乗降施設（例えば、駅、バス停、空港、船着き場等）がある。
【００３１】
定常公共交通機関運行データベース１５ｃは、公共交通機関（例えば、列車、バス、飛行機、船等）の定常運行状態の運行スケジュールを含むデータである。例えば、定常公共交通機関運行データベース１５ｃは、公共交通機関の路線毎に、当該路線の名称のデータ、および、当該路線において運行される各便の各乗降施設における到着時刻および出発時刻（または到着時刻および出発時刻のうちいずれか１つ）のデータを含むデータである。
【００３２】
制御部１６は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等を備えたマイクロコンピュータであり、ＣＰＵがＲＯＭまたはフラッシュメモリに記録されたプログラムを実行することで、各種処理を実現する。
【００３３】
端末側制御部１６が実行する処理としては、図２に示すように、交通情報取得処理１６ａ、ローカルマルチモーダルルート探索処理１６ｂ、センターマルチモーダルリクエスト処理１６ｃ、センターマルチモーダルルート受信処理１６ｄ、マルチモーダルルート探索コントロール処理１６ｅ等がある。
【００３４】
交通情報取得処理１６ａは、道路の現在の混雑度の情報（交通情報）を移動端末１の外部の装置（例えば、ＶＩＣＳ送信機等の交通情報送装置）から受信し、受信した道路の現在の混雑度の情報を交通情報データベース１５ａに上書き記録する処理である。端末側制御部１６は、この交通情報取得処理１６ａを、繰り返し定期的に（例えば１分に１回）実行するようになっている。
【００３５】
ローカルマルチモーダルルート探索処理１６ｂは、センター２のセンターマルチモーダルルート探索処理２３ｄ（後述する）を利用せず、交通情報データベース１５ａ、端末側地図データベース１５ｂ、定常公共交通機関運行データベース１５ｃを用いて、徒歩で移動するルート、車両を用いて移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なルートを算出する処理である。このローカルマルチモーダルルート探索処理１６ｂで算出された最適なルートを、ローカルルートという。
【００３６】
ローカルマルチモーダルルート探索処理１６ｂにおいては、端末側地図データベース１５ｂ中の道路のリンク（徒歩でまたは車両を用いて移動する区間に相当する）と、定常公共交通機関運行データベース１５ｃ中の１つの路線において隣り合っている乗降施設間の区間（公共交通機関を用いて移動する区間に相当する）から複数の区間を選択し、それら選択した区間を繋げた経路を、最適なルートとする。選択する区間を決定するアルゴリズムとしては、例えばダイクストラ法、Ａアルゴリズム等、複数のルートのコストを比較して、最もコストが低いルートを最適なルートとするアルゴリズムを採用する。ルートのコストには、そのルートを構成する各区間コストは、総和も含まれている。各区間のコストは、その区間の長さ（すなわち移動距離）、移動所要時間、料金（その区間を通行する際に課される料金であり、例えば、電車料金）のうちいずれか１つを採用してもよいし、これら３つの量から算出される値（例えばｋ１×長さ＋ｋ２×移動所要時間＋ｋ３×料金、ただし、ｋ１、ｋ２、ｋ３は所定の定数）を採用してもよいであってもよい。
【００３７】
このようなローカルマルチモーダルルート探索処理１６ｂによって算出されるローカルルートは、現在地、目的地に応じて、すべてが車で移動するルートになる場合もあれば、車で移動するルート、電車で移動するルートを組み合わせたルートになる場合もあれば、車で移動するルート、電車で移動するルート、徒歩のルートを組み合わせたルートになる場合もある。
【００３８】
センターマルチモーダルリクエスト処理１６ｃは、徒歩で移動するルート、車両を用いて移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適な組み合わせ（センタールート）を算出するよう、センター２に対して、当該現在地と当該目的地を含んだマルチモーダルルート探索要求を送信する処理である。
【００３９】
センターマルチモーダルルート受信処理１６ｄは、センターマルチモーダルリクエスト処理１６ｃによって送信したマルチモーダルルート探索要求の応答として、センター２が算出した最適なルートを受信する処理である。
【００４０】
マルチモーダルルート探索コントロール処理１６ｅは、ローカルマルチモーダルルート探索処理１６ｂ、センターマルチモーダルリクエスト処理１６ｃ、センターマルチモーダルルート受信処理１６ｄを制御する処理である。このマルチモーダルルート探索コントロール処理１６ｅの詳細な処理内容については後述する。
【００４１】
センター２は、図１に示すように、通信部２１、センター側記憶部２２、センター側制御部２３等を備えている。通信部２１は、通信網３を介して移動端末１等と通信するための増幅、周波数変換、変調、復調等を行う周知の回路である。以下、センター側制御部２３がセンター２の外部の装置と通信を行う場合は、この通信部２１を用いて通信を行うものとする。
【００４２】
センター側記憶部２２は、図２に示すように、交通情報データベース２２ａ、センター側地図データベース２２ｂ、現状公共交通機関データベース２２ｃ等を記憶して有している。
【００４３】
交通情報データベース２２ａは、道路毎に、当該道路の現在の混雑度の情報を含むデータである。この交通情報データベース２２ａは、後述する交通情報蓄積処理２３ａによって逐次更新される。
【００４４】
センター側地図データベース２２ｂは、移動端末１の端末側地図データベース１５ｂと同様の道路データおよび施設データを含むデータである。したがって、センター側地図データベース２２ｂは、端末側地図データベース１５ｂと同様、道路構成および公共交通機関の乗降施設（駅、バス停、駐車場、船着き場等）の位置を記憶する。
【００４５】
現状公共交通機関データベース２２ｃは、公共交通機関の定常運行状態の運行スケジュールのデータ、および、当該定常運行状態の運行スケジュールに対する現在の運行変化状況（例えば、変化なし、１５分遅れ、運休等）のデータ（以下、運行変化状況データという）を含むデータである。公共交通機関の定常運行状態の運行スケジュールのデータは、移動端末１の定常公共交通機関運行データベース１５ｃと同じものでよい。
【００４６】
運行変化状況データとしては、例えば、対象とする公共交通機関の路線の便を指定するデータと、その便においてどの乗降施設でどの程度の時間の遅れが発生しているかを示すデータであってもよい。また、運行変化状況データは、対象とする公共交通機関の路線の便を指定するデータと、その便が運行中止となっていることを示すデータを含んでいてもよい。この運行変化状況データは、後述する公共交通機関運行状況取得処理２３ｂによって逐次更新される。
【００４７】
センター側制御部２３は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等を備えたマイクロコンピュータであり、ＣＰＵがＲＯＭまたはフラッシュメモリに記録されたプログラムを実行することで、各種処理を実現する。
【００４８】
センター側制御部２３が実行する処理としては、図２に示すように、交通情報蓄積処理２３ａ、公共交通機関運行状況取得処理２３ｂ、マルチモーダルルート探索要求受信処理２３ｃ、センターマルチモーダルルート探索処理２３ｄ、マルチモーダルルート配信処理２３ｅ等がある。
【００４９】
交通情報蓄積処理２３ａは、道路の現在の混雑度の情報（交通情報）をセンター２の外部の装置（例えば、ＦＭ−ＶＩＣＳ送信機等の交通情報送装置）から受信し、受信した道路の現在の混雑度の情報を交通情報蓄積処理２３ａに上書き記録する処理である。センター側制御部２３は、この交通情報蓄積処理２３ａを、繰り返し定期的に（例えば１分に１回）実行するようになっている。
【００５０】
公共交通機関運行状況取得処理２３ｂは、現在の運行変化状況データをセンター２の外部のリアルタイム公共交通機関運行情報源（例えば、公共交通機関の運用団体毎に設けられた複数の運行変化状況データサーバであって、当該運用団体が運用する公共交通機関についての最新の運行変化状況データを逐次送信する運行変化状況データサーバ）から受信し、受信した変化状況データサーバを公共交通機関運行状況取得処理２３ｂに記録する処理である。センター側制御部２３は、この公共交通機関運行状況取得処理２３ｂを、繰り返し定期的に（例えば１分に１回）実行するようになっている。なお、受信してから所定時間（例えば１時間）以上経過した運行変化状況データについては削除してもよいし、しなくてもよい。
【００５１】
マルチモーダルルート探索要求受信処理２３ｃは、上述の端末側制御部１６のセンターマルチモーダルリクエスト処理１６ｃによって移動端末１から送信されたマルチモーダルルート探索要求を受信する処理である。
【００５２】
センターマルチモーダルルート探索処理２３ｄは、マルチモーダルルート探索要求受信処理２３ｃがマルチモーダルルート探索要求を受信したことに基づいて、交通情報データベース２２ａ、センター側地図データベース２２ｂ、現状公共交通機関データベース２２ｃを用いて、徒歩で移動するルート、車両を用いて移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、当該マルチモーダルルート探索要求中の現在地から目的地までの最適なルートを算出する処理である。このようにして算出されたルートを、センタールートという。
【００５３】
センターマルチモーダルルート探索処理２３ｄの具体的なアルゴリズムは、交通情報データベース１５ａ、端末側地図ＤＢ１５ｂ、定常公共交通機関運行ＤＢに代えて、交通情報データベース２２ａ、センター側地図データベース２２ｂ、現状公共交通機関データベース２２ｃを用いることを除いては、ローカルマルチモーダルルート探索処理１６ｂと同じである。
【００５４】
このようなセンターマルチモーダルルート探索処理２３ｄによって算出されるセンタールートも、ローカルルートと同様、現在地、目的地に応じて、すべてが車で移動するルートになる場合もあれば、車で移動するルート、電車で移動するルートを組み合わせたルートになる場合もあれば、車で移動するルート、電車で移動するルート、徒歩のルートを組み合わせたルートになる場合もある。
【００５５】
マルチモーダルルート配信処理２３ｅは、センターマルチモーダルルート探索処理２３ｄが算出したセンタールートをマルチモーダルルート探索要求の送信元の移動端末１に送信する処理である。
【００５６】
次に、本実施形態の通信システムの具体的な作動について説明する。まず、移動端末１のユーザが操作部１４を操作して目的地を入力したとする。すると端末側制御部１６は、マルチモーダルルート探索コントロール処理１６ｅの実行を開始する。図３に、このマルチモーダルルート探索コントロール処理１６ｅのフローチャートを示す。
【００５７】
マルチモーダルルート探索コントロール処理１６ｅにおいて端末側制御部１６は、まずステップ１１０で、入力された目的地を取得し、さらに、位置検出部１２からの信号に基づいて移動端末１の現在地を取得する。なお、ユーザが目的地に加えて経由地も操作部１４に入力していれば、その経由地も取得する。
【００５８】
続いてステップ１２０では、ローカルマルチモーダルルート探索処理１６ｂ呼び出して実行することで、ステップ１１０で取得した現在地から目的地までの（経由地を取得していればその経由地を通る）最適なローカルルートを算出する。
【００５９】
このように算出されたローカルルートは、センター２のセンターマルチモーダルルート探索処理２３ｄを利用せず、交通情報データベース１５ａ、端末側地図データベース１５ｂ、および定常公共交通機関運行データベース１５ｃを用いて、徒歩で移動するルート、車両で走行するルート、および公共交通機関を利用して移動するルート等を最適なルート中の区間の候補とした、現在地から目的地までの（経由地を取得していればその経由地を通る）最適なルートである。
【００６０】
続いてステップ１３０では、算出されたローカルルートが公共交通機関を利用している（すなわち、公共交通機関を利用するルートを含んでいる）か否かを判定し、利用していないと判定した場合、続いてステップ１３５に進み、利用していると判定した場合、続いてステップ１４０に進む。
【００６１】
ステップ１３５では、ステップ１２０で算出したローカルルートを経路案内用のルートとして記録し、マルチモーダルルート探索コントロール処理１６ｅを終了する。そしてその後、経路案内用のルートとして記録した当該ローカルルートに沿った周知の経路案内を行う。
【００６２】
ステップ１４０では、センターマルチモーダルリクエスト処理１６ｃを呼び出して実行することで、当該現在地と当該目的地（および、経由地を取得していればその経由地）を含んだマルチモーダルルート探索要求をセンター２に送信する。続いてステップ１５０では、センター２からマルチモーダルルート探索要求の応答を受信するまで待つ。
【００６３】
するとセンター２では、センター側制御部２３が、マルチモーダルルート探索要求受信処理２３ｃを実行して、上記ステップ１４０によって移動端末１から送信されたマルチモーダルルート探索要求を受信する。
【００６４】
更にセンター側制御部２３は、マルチモーダルルート探索要求受信処理２３ｃによりマルチモーダルルート探索要求を受信したことに基づいて、センターマルチモーダルルート探索処理２３ｄを実行し、交通情報データベース２２ａ、センター側地図データベース２２ｂ、および現状公共交通機関データベース２２ｃ（定常運行状態の運行スケジュールのデータおよび運行変化状況データ）を用いて、徒歩で移動するルート、車両で移動するルート、および公共交通機関を利用して移動するルート等を最適なルート中の区間の候補として、マルチモーダルルート探索要求中の当該現在地から当該目的地までの（経由地を受信していればその経由地を通る）最適なセンタールートを算出する。このようにして算出されたセンタールートは、運行変化状況データを用いて算出しているため、移動端末１において算出したローカルルートに比べて、現状の公共交通機関の運行状況をより正確に反映していると考えられる。更にセンター側制御部２３は、センターマルチモーダルルート探索処理２３ｄによって算出したセンタールートを、マルチモーダルルート探索要求の送信元の移動端末１に送信する。
【００６５】
このように、センター２は、マルチモーダルルート探索要求を受信したことに基づいて、交通情報データベース２２ａ、センター側地図データベース２２ｂ、および現状公共交通機関データベース２２ｃを用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、マルチモーダルルート探索要求中の現在地から目的地までの最適なセンタールートを算出し、算出したセンタールートを移動端末１に送信する。送信するセンタールートは、センタールートを構成する各区間の経路（例えば、各区間のリンクＩＤのリスト）、各区間の移動手段、各区間の移動所要時間、各区間の料金等が含まれたデータである。
【００６６】
すると端末側制御部１６では、センターマルチモーダルルート受信処理１６ｄによって、上記マルチモーダルルート探索要求の応答としてセンター２が算出して送信したセンタールートを受信する。すると図３のステップ１５０では、上記マルチモーダルルート探索要求の応答としてセンタールートを受信したと判定し、ステップ１６０に進む。
【００６７】
ステップ１６０では、受信したセンタールートを経路案内用のルートとして記録し、マルチモーダルルート探索コントロール処理１６ｅを終了する。そしてその後、経路案内用のルートとして記録した当該センタールートに沿った周知の経路案内を行う。
【００６８】
このように、移動端末１に、あらかじめ公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース１５ｃを備えておき、移動端末１側で公共交通機関以外（例えば、徒歩、車両）を使ったルートと公共交通機関を使ったルートを最適なルート中の区間の候補とするルート探索を行う。そして、そのルート探索において、公共交通機関を使ったほうが良いという結果になった場合に、センターに現在の運行状況を踏まえたマルチモーダル探索の依頼をかけるようにする。
【００６９】
公共交通機関を使ったルートの比較において、公共交通機関の実際の運行状態を踏まえたルートは、定常の運行状態と同じ、もしくは定常状態より悪化することしか通常はありえないため、定常状態で公共交通機関を使ったルートが算出される場合でしか、実際の運行状態を踏まえたルート算出で公共交通機関を使ったルートとなることがあり得ないと考えることができるため、上記のような実現方法を取ることで、不必要にセンター２に問い合わせることなく、マルチモーダル探索の実現が可能となる。
【００７０】
（第２実施形態）
次に、本発明の第２実施形態について説明する。本実施形態は、第１実施形態の通信システムに対して、以下に示すような端末側制御部１６およびセンター側制御部２３の処理を追加するものである。
【００７１】
まず、本実施形態におけるマルチモーダルルート探索コントロール処理１６ｅの処理内容は、図３に代えて、図４のようになる。図３と図４の処理内容は、ステップ１１０〜１６０までは同じである。しかし、図４の処理では、ステップ１３５に続いてステップ１６５を実行し、ステップ１６０に続いてステップ１７０を実行する。
【００７２】
ステップ１６５では、経路案内に使用する経路案内用ルートとされたローカルルート上で１つまたは複数の再探索ポイントを設定して、それをローカルルートに関連付けてＲＡＭまたはフラッシュメモリに記録する。
【００７３】
再探索ポイントのそれぞれは、ステップ１３５で決定および保存したローカルルート（案内に使用するルート）上の一点であり、そのローカルルートの算出の際に他のルートへの岐路となったポイントである。より具体的には、端末側制御部１６は、ステップ１２０のローカルルートの算出時に、既に説明した通り、他のルートのコストも算出する。そして端末側制御部１６は、ステップ１３５を実行してローカルルートを経路案内に使用する経路案内用ルートとした後は、ステップ１６５で、上記他のルートのうち、ローカルルート上の一点から分岐し、かつローカルルート上の他の点に合流するルート（分岐合流ルートという）をすべて抽出する。
【００７４】
そして、抽出した分岐合流ルートのそれぞれについて、増加コストを算出する。ある分岐合流ルートの増加コストの計算方法は、以下の通りである。まず、当該分岐合流ルートがローカルルートから分岐する点を分岐点Ａとし、当該分岐合流ルートがローカルルートに合流する点を合流点Ｂとし、分岐点Ａから合流点Ｂまでのローカルルート上の経路のコストＣ１を算出する。更に、分岐点Ａから合流点Ｂまでの当該分岐合流ルート上の経路のコストＣ２を算出する。そして、コストＣ１に対するコストＣ２の増加分を、当該分岐合流ルートの増加コストとする。
【００７５】
そして、抽出した分岐合流ルートから、増加コストが所定の閾値よりも小さいものを選び出し、選び出した分岐合流ルートにおける分岐点Ａ（岐路ポイント）を、再探索ポイントとして設定する。
【００７６】
あるいは、移動端末１がセンター２にマルチモーダルルート探索要求を送信する必要が特にあるのは、公共交通機関を使う可能性があるケースなので、抽出した分岐合流ルートから、増加コストが所定の閾値よりも小さいものを選び出した後、更に選び出した分岐合流ルートのうち、公共交通機関を使って移動する区間を含む分岐合流ルートを選び出し、選び出した分岐合流ルートにおける分岐点Ａ（岐路ポイント）を、再探索ポイントとして設定するようになっていてもよい。このようにすることで、更にセンター２へマルチモーダルルート探索要求を送信する回数を減らすことができる。ステップ１６５の後、図４の処理が終了する。
【００７７】
このようにして選ばれる再探索ポイントとしては、例えば、ローカルルートと分岐合流ルートのどちらに進んでもほぼ同じ距離移動後、再び合流する道路の分岐点、どちらのルートに進んでも、ほぼ同じ時間で、再び同じ駅に到着する乗換駅、そのまま自動車でローカルルートを進んでも、電車に乗り換えて分岐合流ルートを進んでも、ほぼ同じ時間経過後、次の乗換候補となる駅に到着する可能性のある乗換駅が考えられる。
【００７８】
また、センター側制御部２３も、センターマルチモーダルルート探索処理２３ｄにおいて、既に説明した通りの方法でセンタールートを算出するが、本実施形態では、その後、算出したセンタールート上で１つまたは複数の再探索ポイントを設定して、センタールートに関連付けてＲＡＭまたはフラッシュメモリに記録する。再探索ポイントの設定方法は、端末側制御部１６における具体的なローカルルート上の再探索ポイントの設定方法と同じである。
【００７９】
また、マルチモーダルルート配信処理２３ｅは、センタールートを移動端末１に送信する際、センタールートの再探索ポイントの位置の情報も、共に移動端末１に送信する。そして端末側制御部１６は、ステップ１５０で、センタールートと共に再探索ポイントの位置の情報を受信し、ステップ１６０で、当該センタールートを経路案内用のルートとして保存した後、ステップ１７０で、当該再探索ポイントの位置を、当該センタールートの再探索ポイントに設定すると共に、ＲＡＭ等の記憶媒体に記録する。このように、端末側制御部１６は、センタールートについても再探索ポイントをセンター２から受信することで設定可能となっている。ステップ１７０の後、図４の処理が終了する。
【００８０】
また、移動端末１が移動中であり、端末側制御部１６が上記ローカルルートまたはセンタールートを経路案内用のルートとして案内しているときに、図５に示す移動時処理を実行する。
【００８１】
この移動時処理において端末側制御部１６は、移動端末１が目的地に到着したか否かの判定（ステップ３１０）と、移動端末１が上記記録された当該経路案内用ルートの再探索ポイントのいずれかに対して経路案内用のルートに沿って基準距離（固定値でもよいし、移動端末１の移動速度等に応じて変化してもよい）以内の手前に接近したか否かの判定（ステップ３２０）とを、その２つの判定のどちらかの判定結果が肯定判定（ＹＥＳ）となるまで繰り返す。
【００８２】
上記のステップ３１０、３２０の繰り返しにおいて、ステップ３１０で移動端末１が目的地に到着したと判定した場合は、移動時処理を終了する。
【００８３】
また、ステップ３１０、３２０の繰り返しにおいて、ステップ３２０で移動端末１が再探索ポイントのいずれかに対して経路案内用のルートに沿って所定距離以内の手前に接近したと判定した場合、続いてステップ３３０で、再度現在地および目的地（およびあれば経由地）を取得する。具体的には、現在の経路案内用のルートの目的地を引き続き目的地とし、移動端末１の現在位置を取得し、現在の経路案内用のルートに経由地が設定されていれば、移動端末１の現在位置以降の経由地も引き続き経由地とする。
【００８４】
続いてステップ３４０では、図３のステップ１４０と同様、センターマルチモーダルリクエスト処理１６ｃを呼び出して実行することで、当該現在地と当該目的地（および、経由地を取得していればその経由地）を含んだマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）をセンター２に送信する。続いてステップ３５０では、センター２からマルチモーダルルート探索要求の応答を受信するまで待つ。
【００８５】
するとセンター２では、センター側制御部２３が、マルチモーダルルート探索要求受信処理２３ｃを実行して、上記ステップ３４０によって移動端末１から送信されたマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）を受信する。
【００８６】
更にセンター側制御部２３は、マルチモーダルルート探索要求受信処理２３ｃにより当該マルチモーダルルート探索要求を受信したことに基づいて、センターマルチモーダルルート探索処理２３ｄを実行し、交通情報データベース２２ａ、センター側地図データベース２２ｂ、および現状公共交通機関データベース２２ｃ（定常運行状態の運行スケジュールのデータおよび運行変化状況データ）を用いて、徒歩で移動するルート、車両で移動するルート、および公共交通機関を利用して移動するルート等を最適なルート中の区間の候補として、マルチモーダルルート探索要求中の当該現在地から当該目的地までの（経由地を受信していればその経由地を通る）最適なセンタールート（再探索ポイント用センタールートに相当する）を算出する。このようにして算出されたセンタールートは、運行変化状況データを用いて算出しているため、移動端末１において算出したローカルルートに比べて、現状の公共交通機関の運行状況をより正確に反映していると考えられる。また、このようにして算出されたセンタールート（再探索ポイント用センタールート）は、図３のステップ１５０で端末側制御部１６が受信したセンタールートよりも遅いタイミングで算出されているので、より最新の公共交通機関の運行状況を反映している。
【００８７】
更にセンター側制御部２３は、センターマルチモーダルルート探索処理２３ｄによって算出したセンタールート上の再探索ポイントを既に説明したものと同じ方法で設定し、当該センタールートおよび再探索ポイントを、マルチモーダルルート探索要求の送信元の移動端末１に送信する。
【００８８】
すると端末側制御部１６では、センターマルチモーダルルート受信処理１６ｄによって、上記マルチモーダルルート探索要求の応答としてセンター２が算出して送信したセンタールート（再探索ポイント用センタールートに相当する）およびセンタールート上の再探索ポイントを受信する。すると図５のステップ３５０では、上記マルチモーダルルート探索要求の応答としてセンタールートを受信したと判定し、ステップ３６０に進む。
【００８９】
ステップ３６０では、受信したセンタールートを新たな経路案内用のルートとして記録することで、それまでの経路案内用ルートに代えて、この新たな経路案内用のルートで案内を開始する。
【００９０】
更にステップ３７０では、受信した再探索ポイントの位置を、経路案内用ルートとして用いるセンタールートの再探索ポイントに設定すると共に、ＲＡＭ等の記憶媒体に記録し、その後、再度ステップ３１０に処理を戻す。
【００９１】
以上説明した通り、移動端末１の端末側制御部１６は、ローカルルートまたはセンタールートを経路案内用ルートとする際（図４のステップ１３５、１６０）に、ルート選択の際に岐路となった１つまたは複数の地点を再探索ポイントとし、それらを経路案内用ルートと共記録しておく（１６５、１７０）。
【００９２】
また、センター制御部２３は、センターマルチモーダルルート探索処理２３ｄにおいて、算出したセンタールート上に１つまたは複数の再探索ポイントを設定し、マルチモーダルルート配信処理２３ｅにおいて、それら複数の再探索ポイントを、センタールート（再探索ポイント用センタールートに相当する）と共に移動端末１に送信し、端末側制御部１６は、その再探索ポイントを受信してセンタールートの再探索ポイントに設定し、記録する。
【００９３】
そして、端末側制御部１６は、経路案内用のルートの案内に従って移動端末１が移動中である間は、移動端末１がその再探索ポイントへの接近を検出した場合に、再びセンター２にマルチモーダルルート探索要求を行うことで、公共交通機関の最新の運行状況に基づいて作成されたセンタールートを経路案内用のルートとすることができる。
【００９４】
例えば、移動端末１で当初は、ある分岐点Ａまでは車両で走行し、分岐点Ａから合流点Ｂの間は電車に乗り換えて移動するようなセンタールートが経路案内用ルートとして採用されていたとする。ここで、分岐点Ａから合流点Ｂまでは、車両で移動することもでき、車両で行っても電車で行っても同時刻に合流点Ｂに合流できるが、電車のほうが安いという理由で、電車を用いるセンタールートが算出されたとする。
【００９５】
ところが、実際に分岐点Ａ（再探索ポイント）に接近した際に、移動端末１がセンター２へマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）を送信すると、当該電車が遅延しており、その過結果、分岐点Ａからも車両を用いた方が合流点Ｂへの到着が早くなり、その結果、センター２からは車両でそのまま合流点Ｂへ向かう新たなセンタールート（再探索ポイント用センタールートに相当する）を送信する。そして移動端末１では、この新たなセンタールートに従って、早く合流点Ｂに到達することができる。
【００９６】
このようになっていることで、一旦経路案内用のルートを決定し、そのルートで案内を行い、その案内に従って移動端末１が移動しているときも、センター２にマルチモーダルルート探索要求を送信することで、公共交通機関の運行状況の変化に応じて柔軟に経路案内用のルートを変更することができる。また、移動端末１が再探索ポイントへの接近を検出した場合に、センター２にマルチモーダルルート探索要求を行うので、無駄に多数回センター２に問い合わせしてしまう可能性を抑えることができる。
【００９７】
（第３実施形態）
次に、本発明の第３実施形態について説明する。本実施形態が第２実施形態と異なる点は３つある。
【００９８】
まず第１に、本実施形態の端末側制御部１６は、図５のステップ３４０でセンター２に送信するマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）に、更に、現在の経路案内用のルート（ローカルルートの場合もあればセンタールートの場合もある）のデータ（各区間の経路、各区間の移動手段、各区間の移動所要時間、各区間の料金等）を含める。
【００９９】
第２に、センター側制御部２３は、マルチモーダルルート配信処理２３ｅの実行において、図５のステップ３４０で移動端末１から送信されたマルチモーダルルート探索要求（再探索ポイント用マルチモーダルルート探索要求に相当する）を受信したことに基づいて算出したセンタールート（再探索ポイント用センタールートに相当する）を移動端末１に送信すると共に、移動端末１から受信したマルチモーダルルート探索要求に含まれる上記経路案内用のルートの不利情報を取得して移動端末１に送信する。
【０１００】
この不利情報とは、上記経路案内用のルートについて算出された各区間の移動所要時間に対する、現状公共交通機関データベース２２ｃの現在の情報に基づいて特定される上記経路案内用のルートの各区間の移動所要時間の増加量（すなわち、遅延時間）を示す情報を含むと共に、上記経路案内用のルートの各区間の料金の情報も含む。
【０１０１】
したがって、マルチモーダルルート配信処理２３ｅにおいてセンター側制御部２３は、移動端末１から受信した再探索ポイント用マルチモーダルルート探索要求に含まれる経路案内用のルートの各区間の移動所要時間を、現在の現状公共交通機関データベース２２ｃ（特に、運行変化状況データ）に基づいて算出し、算出した移動所要時間に基づいて、上記遅延時間を算出し、算出した遅延時間を不利情報に含めるようになっていればよい。
【０１０２】
例えば、不利情報には、経路案内用のルート上の公共交通機関を利用する区間のすべてについて、当該区間の移動所要時間の情報を含めてもよい。
【０１０３】
また、不利情報には、経路案内用のルート上の特定の区間における電車ダイヤの乱れによる定常運行に対する遅延時間の情報が含まれていてもよい。このような情報としては、例えば、経路案内用のルートに含まれる電車移動の区間において、利用する予定の便が１５分遅れて各駅に到着するという情報がある。
【０１０４】
また、経路案内用のルートは電車移動する区間を含んでおり、センターマルチモーダルルート探索処理２３ｄによって今回算出された新たなセンタールート（再探索ポイント用センタールートに相当する）は、その区間の代わりに車両で移動する区間を含んでいる場合に、その経路案内用のルート上の当該電車移動区間の移動所要時間を不利情報に含めてもよい。
【０１０５】
また、経路案内用のルートにおける各区間の所要料金について、端末側制御部１６のローカルマルチモーダルルート探索処理１６ｂで算出した所要料金とセンター側制御部２３のセンターマルチモーダルルート探索処理２３ｄで算出した所要料金との差（例えば、料金に変化はないという情報）を不利情報に含めてもよい。
【０１０６】
第３に、端末側制御部１６が図５の移動時処理においてセンタールートを受信した後のステップ３６０、３７０の処理内容が、本実施形態では図６に示すような処理内容に変更されている。
【０１０７】
具体的には、図５のステップ３５０で、直前に送信したマルチモーダルルート探索要求の応答としてセンタールート（および不利情報）を受信したと判定した場合、続いて図６のステップ３６１に進む。
【０１０８】
ステップ３６１では、直前に受信したセンタールート（再探索ポイント用センタールートに相当する）と経路案内用ルートを比較する。この比較は、双方のルートの乖離が大きいかどうかを判断するために行う処理である。具体的には、当該センタールートの各区間の経路、移動手段（徒歩か、車両、列車等）および移動所要時間を比較する。
【０１０９】
続いてステップ３６２では、ステップ３６１の比較結果を利用して、当該センタールートと当該経路案内用ルートの乖離が大きいか否かを、所定の基準に従って判定する。
【０１１０】
所定の基準としては、例えば、（１）センタールートと経路案内用ルートの各区間の経路、移動手段、および移動所要時間が完全に同じである場合、および、（２）センタールートと経路案内用ルートの各区間の経路および移動手段は完全に一致するが、移動所要時間は少なくとも一部が異なっている場合、という２つの場合は、当該センタールートと当該経路案内用ルートの乖離が大きくないと判定する。そして、センタールート各区間の経路および移動手段のすくなくともいずれかは経路案内用ルートと一致しない場合（当然所要時間や料金も変化している）には、当該センタールートと当該経路案内用ルートの乖離が大きいと判定する。
【０１１１】
乖離が大きいと判定した場合は、続いてステップ３６３および３６４を実行した上でステップ３６５に処理を進める。乖離が大きくないと判定した場合は、直ちにステップ３６５に処理を進める。
【０１１２】
ステップ３６３では、センター２から受信した不利情報を利用して経路案内用ルートの再計算を行う。ただしこの再計算においては、当初の経路案内用ルートの各区間の経路および移動手段は変更せず、単に当該経路案内用ルートの各区間の移動所要時間および料金の再計算を行う。このような再計算により、例えば、「経路案内用ルートの区間αを電車移動すると、センター２からの不利情報によれば、センタールートよりも３０分遅れ、料金は同一となる。したがってルート全体では、センタールートよりも３０分の遅延で、料金は同一に維持される」等が明らかになる。
【０１１３】
続いてステップ３６４では、ステップ３６３の算出結果を利用して、ステップ３６１と同様の方法で、センタールートと経路案内用ルートを比較する。この比較により、例えば、「センタールートを採用すると、経路案内用ルートを採用するより１０分早く目的地に到着する（ただし、どのみち当初の経路案内用ルートの所要時間計算結果より２０分遅い）が、必要な料金は１０００円高くなる」ということが明らかになる。
【０１１４】
ステップ３６５では、センタールートの方が経路案内用ルートよりも有利か否かを判定する。この判定基準としては、例えば、センタールートを現在位置から目的地まで移動するのに要する時間ＴＣと、経路案内用ルートを現在位置から目的地まで移動するのに要する時間ＴＬのうち、時間ＴＣの方が小さければセンタールートの方が有利であると判定し、そうでなければ経路案内用ルートの方が有利であると判定するという基準を採用してもよい。
【０１１５】
あるいは、この判定基準としては、例えば、センタールートを現在位置から目的地まで移動するのに要する料金ＣＣと、経路案内用ルートを現在位置から目的地まで移動するのに要する料金ＣＬのうち、料金ＣＣの方が小さければセンタールートの方が有利であると判定し、そうでなければ経路案内用ルートの方が有利であると判定するという基準を採用してもよい。
【０１１６】
あるいは、ｆ（Ｔ、Ｃ）を値Ｔの単調増加関数であり、かつ値Ｃの単調増加関数であるとする。このような関数としては例えばＣ＋Ｔがある。そして、ｆ（ＴＣ、ＣＣ）、ｆ（ＴＬ、ＣＬ）のうち、ｆ（ＴＣ、ＣＣ）の方が小さければセンタールートの方が有利であると判定し、そうでなければ経路案内用ルートの方が有利であると判定するという基準を採用してもよい。
【０１１７】
なお、あらかじめ移動端末１のユーザが操作部１４を操作して有利性の判断基準を設定入力し、端末側制御部１６は、入力された判断基準をフラッシュメモリ等に登録し、登録した判断基準に基づいて、センタールートと経路案内用ルートのどちらが有利かを判定するようになっていてもよい。
【０１１８】
例えば、端末制御部１６は、表示部１３に、有利性の判断基準として、「料金優先」、「時間優先」等の複数種類の選択肢を提示し、ユーザは、操作部１４を操作して、それら複数種類の選択肢のいずれか１つを選択する入力を行えるようになっていてもよい。
【０１１９】
この場合、ユーザが「料金優先」を選択する入力を行った場合、端末制御部１６は、ステップ３６５において、経路案内用ルートとセンタールートで、料金は経路案内用ルートの方が少なく済むが、時間はセンタールートの方が少なく済むような場合、経路案内用ルートの方が有利であると判定する。また、ユーザが「時間優先」を選択する入力を行った場合、端末制御部１６は、同様の場合で、センタールートの方が有利であると判定する。このように、ユーザが有利性の判定基準を入力することで、ユーザの価値観に応じたルート選択が可能となる。
【０１２０】
あるいは、ステップ３６５では、表示部１３に画像または文字でステップ３６１（ステップ３６４を実行した場合はステップ３６４）の比較結果（経路の違い、移動手段の違い、移動所要時間の違い、料金の違い等）を表示部１３に表示させるか、あるいは、図示しないスピーカを用いて音声で報知し、その比較結果に基づいてユーザにどちらが有利か判断させるようにしてもよい。この場合、ユーザは、経路案内用ルートとセンタールートのどちらがより有利であるかの判断結果を操作部１４を用いて入力し、端末側制御部１６は、入力された判断結果に従って、どちらが有利かを判定する。
【０１２１】
また、上述のようにあらかじめ移動端末１のユーザが操作部１４を操作して有利性の判断基準を設定入力した場合であっても、その後の、上述のような操作部１４を用いたユーザの選択に従って、登録した判断基準を随時変化させる学習処理を行うようになっていてもよい。例えば、端末側制御部１６は、ステップ３６５で、登録した判断基準に基づいてセンタールートと経路案内用ルートのいずれか一方をより有利なルートとして暫定的に選択し、その暫定的な選択結果をユーザに（音声または映像で）報知すると共に、この選択でよいか否かを問い合わせるメッセージも報知するようになっていてもよい。そして、ユーザが操作部１４を用いてこの選択でよい旨を入力した場合は、暫定的な選択結果通りに選択を確定し、ユーザが操作部１４を用いてこの選択はよくない旨を入力した場合は、暫定的な選択結果とは反対の選択を確定する。そして、経路案内用ルートかセンタールートかの確定した選択結果を蓄積していき、選択結果の蓄積数が所定数（例えば１０個）を超え、かつ、どちらかのルートを選択した選択結果が所定比率（例えば８０％）以上である場合は、その所定比率以上選択されたルートを薦めるメッセージを、上述の、この選択でよいか否かを問い合わせるメッセージと共にユーザに報知するようになっていてもよい。具体的には、「あなたの過去の判断から推測すると、センターのルートの方がお薦めですが、この選択でよいですか？」というメッセージを報知してもよい。
【０１２２】
ステップ３６５でセンタールートの方が有利であると判定した場合、続いてステップ３６６に進み、当該センタールートを新たな経路案内用のルートとして記録することで、それまでの経路案内用ルートに代えて、この新たな経路案内用のルートで案内を開始する。
【０１２３】
ステップ３６５で、センタールートの方が有利でない（経路案内用ルートの方が有利である）と判定した場合、続いてステップ３６７に進み、現在の経路案内用ルートをそのまま使用し続ける。ただし、ステップ３６３を実行している場合は、料金および所要時間の表示を、ステップ３６３の計算結果に従って修正する。
【０１２４】
ステップ３６６、３６７に続いては、ステップ３６８で、新たな経路案内用ルートに対して、図４のステップ１６５、１７０、または図５のステップ３７０と同様の方法で、当該経路案内用ルート上の１つまたは複数の再探索ポイントの位置を決定して、経路案内用ルートに関連付けてＲＡＭまたはフラッシュメモリに記録する。
【０１２５】
ステップ３６８の後は、図５のステップ３１０に処理を戻す。そして、移動端末１でその再探索ポイントの接近を検出した場合にだけ、再びセンター２に最新の運行状態でのマルチモーダル探索の問い合わせを行うこととする。上記のような実現方法を取ることで、不必要にセンター２に問い合わせすることなく、マルチモーダルルートによる移動の実現が可能となる。
【０１２６】
また、ステップ３６５、３６６、３６７のように、センター２で算出されたセンタールート（再探索ポイント用センタールート）と、現在の経路案内用ルートのうちどちらが有利かを判定し、有利な方を経路案内用のルートとして使用することで、より適切な経路案内を行うことができる。
【０１２７】
なお、上記各実施形態では、端末側制御部１６が、図３のステップ１２０を実行することでローカルマルチモーダルルート探索手段の一例として機能し、ステップ１３０を実行することで判定手段の一例として機能し、ステップ１３５を実行することでローカルルート記録手段の一例として機能し、ステップ１４０を実行することでセンターマルチモーダルリクエスト手段の一例として機能し、ステップ１６０を実行することでセンタールート記録手段の一例として機能し、ステップ１６５、１７０を実行することで再探索ポイント設定手段（１６５、１７０）の一例として機能し、ステップ３４０を実行することで再探索ポイント用センターマルチモーダルリクエスト手段の一例として機能し、ステップ３６０またはステップ３６２〜３６８を実行することでセンタールート使用手段の一例として機能する。
【０１２８】
また、センター側制御部２３が、マルチモーダルルート探索要求受信処理２３ｃを実行することでマルチモーダルルート探索要求受信手段の一例として機能し、センターマルチモーダルルート探索処理２３ｄを実行することでセンターマルチモーダルルート探索手段の一例として機能し、マルチモーダルルート配信処理２３ｅを実行することでマルチモーダルルート配信手段の一例として機能する。
【０１２９】
（他の実施形態）
以上、本発明の実施形態について説明したが、本発明の範囲は、上記実施形態のみに限定されるものではなく、本発明の各発明特定事項の機能を実現し得る種々の形態を包含するものである。
【０１３０】
例えば、公共交通機関を利用せずに移動するルートとしては、徒歩で移動するルート、車両を用いて移動するルートを挙げているが、公共交通機関を利用せずに移動するルートとしては、車で移動するルートのみを採用してもよいし、徒歩で移動するルートのみを採用してもよい。
【０１３１】
また、上記第１実施形態の図３のステップ１４０で、端末側制御部１６がマルチモーダルルート探索要求をセンター２に送信しているが、このマルチモーダルルート探索要求に、直前のステップ１２０で算出したローカルルートの各区間の経路のデータを含めるようになっていてもよい。その場合、このマルチモーダルルート探索要求を受信したセンター側制御部２３は、センタールートを算出した際、受信したローカルルートと算出したセンタールートが同じ経路であるか否かを判定し、同じでなければ第１実施形態と同様にセンタールートを移動端末１に送信し、同じであれば、センタールートの代わりに、ローカルルートをそのまま使用してよい旨を示すデータを移動端末１に送信するようになっていてもよい。このようにすることで、不必要な場合にまで移動端末１にセンタールートの実体を送信する必要がなくなる。なお、端末側制御部１６は、センタールートのデータではなく、ローカルルートをそのまま使用してよい旨を示すデータを受信した場合は、ステップ１３５に進み、ステップ１２０で算出したローカルルートを経路案内用のルートとして記録するようになっていてもよい。
【０１３２】
また、第２実施形態では、経路案内用のルートの案内に従って移動端末１の移動中は、移動端末１が再探索ポイントへの接近を検出した場合に、再びセンター２にマルチモーダルルート探索要求を行うようになっているが、移動端末１の移動中は、移動端末１が再探索ポイントへの接近を検出した場合以外の場合（例えば、ユーザが操作部１４に対して再探索の操作を行った場合等）にも、再びセンター２にマルチモーダルルート探索要求を行うようになっていてもよい。
【０１３３】
つまり、経路案内用のルートの案内に従って移動端末１の移動中は、少なくとも、移動端末１が再探索ポイントへの接近を検出した場合を選択して、再びセンター２にマルチモーダルルート探索要求を行うようになっていれば足りる。このようにすることの意義は、無駄に多くマルチモーダルルート探索要求を行う可能性を低減することにあるので、他の有利な場合にマルチモーダルルート探索要求を行うことまでを排除するものではない。
【０１３４】
また、上記第３実施形態では、不利情報は、経路案内用ルートについて移動端末１で算出された各区間の移動所要時間に対する、現状公共交通機関データベース２２ｃの情報に基づいて特定される上記経路案内用ルートの各区間の移動所要時間の増加量（すなわち、遅延時間）そのものを示す情報を含んでいるが、不利情報は、かならずしもこのような情報に限らず、このような遅延時間の情報が移動端末１で算出できるようにするための情報であればよい。したがって、経路案内用ルートについて算出された各区間の移動所要時間は、移動端末１が既に取得していることに鑑みれば、不利情報に含めるのは、現状公共交通機関データベース２２ｃの情報に基づいて特定される上記経路案内用ルートの各区間の移動所要時間の情報であってもよい。
【０１３５】
また、上記実施形態において、センター２は、１台の装置として記載されているが、センター２は、互いに通信を行うことで協働してセンター２の機能を実現する複数台の装置によって構成されていてもよい。
【０１３６】
また、上記の実施形態において、端末側制御部１６、センター側制御部２３がプログラムを実行することで実現している各機能は、それらの機能を有するハードウェア（例えば回路構成をプログラムすることが可能なＦＰＧＡ）を用いて実現するようになっていてもよい。
【符号の説明】
【０１３７】
１ 移動端末
２ センター
１５ 端末側記憶部
１５ｂ 端末側地図データベース
１５ｃ 定常公共交通機関運行データベース
１６ 端末側制御部
１６ｂ ローカルマルチモーダルルート探索処理
１６ｃ センターマルチモーダルリクエスト処理
１６ｄ センターマルチモーダルルート受信処理
１６ｅ マルチモーダルルート探索コントロール処理
２２ センター側記憶部
２２ｂ センター側地図データベース
２２ｃ 現状公共交通機関データベース
２３ センター側制御部
２３ｂ 公共交通機関運行状況取得処理
２３ｃ マルチモーダルルート探索要求受信処理
２３ｄ センターマルチモーダルルート探索処理
２３ｅ マルチモーダルルート配信処理
【特許請求の範囲】
【請求項１】
移動端末（１）と、前記移動端末（１）と通信可能なセンター（２）とを備えた通信システムであって、
前記移動端末（１）は、道路構成および公共交通機関の乗降施設の位置を含む端末側地図データベース（１５ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）とを記憶する端末側記憶部（１５）、および、端末側制御部（１６）を備え、
前記センター（２）は、道路構成および前記公共交通機関の乗降施設の位置を含むセンター側地図データベース（２２ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールおよび定常運行状態の運行スケジュールに対する現在の運行変化状況を含む現状公共交通機関データベース（２２ｃ）とを記憶する前記センター側記憶部（２２）、および、センター側制御部（２３）を備え、
前記端末側制御部（１６）は、
前記センター（２）を利用せず、前記端末側地図データベース（１５ｂ）および前記定常公共交通機関運行データベース（１５ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なローカルルートを算出するローカルマルチモーダルルート探索手段（１２０）と、
前記ローカルマルチモーダルルート探索手段（１２０）によって算出された前記ローカルルートが公共交通機関を利用しているか否かを判定する判定手段（１３０）と、
前記判定手段（１３０）が利用していないと判定したことに基づいて、前記ローカルルートを経路案内用のルートとして記録するローカルルート記録手段（１３５）と、
前記判定手段（１３０）が利用していると判定したことに基づいて、前記現在地と前記目的地を含んだマルチモーダルルート探索要求を前記センター（２）に送信するセンターマルチモーダルリクエスト手段（１４０）と、を備え、
前記センター側制御部（２３）は、
前記センターマルチモーダルリクエスト手段（１４０）によって前記移動端末（１）から送信された前記マルチモーダルルート探索要求を受信するマルチモーダルルート探索要求受信手段（２３ｃ）と、
前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適なセンタールートを算出するセンターマルチモーダルルート探索手段（２３ｄ）と、
前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記センタールートを前記移動端末（１）に送信するマルチモーダルルート配信手段（２３ｅ）と、を備え、
更に前記端末側制御部（１６）は、前記センターマルチモーダルリクエスト手段（１４０）が送信した前記マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記センタールートを受信したことに基づいて、前記センタールートを経路案内用のルートとして記録するセンタールート記録手段（１６０）を備えたことを特徴とする通信システム。
【請求項２】
更に前記端末側制御部（１６）は、前記ローカルルートおよび前記センタールートのうち経路案内用のルートとするルート上に、１つまたは複数の再探索ポイントを設定する再探索ポイント設定手段（１６５、１７０）を備え、
更に前記端末側制御部（１６）は、前記経路案内用のルートを案内しているときに、前記移動端末（１）が前記再探索ポイントのいずれかに対して前記経路案内用のルートに沿って基準距離以内の手前に接近したか否かを判定し、接近したと判定したことに基づいて、現在地と前記目的地を含んだ再探索ポイント用マルチモーダルルート探索要求を前記センター（２）に送信する再探索ポイント用センターマルチモーダルリクエスト手段（３４０）を備え、
前記センター側制御部（２３）の前記マルチモーダルルート探索要求受信手段（２３ｃ）は更に、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）によって前記移動端末（１）から送信された前記再探索ポイント用マルチモーダルルート探索要求を受信し、
前記センターマルチモーダルルート探索手段（２３ｄ）は更に、前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記再探索ポイント用マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記再探索ポイント用マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適な再探索ポイント用センタールートを算出し、
前記マルチモーダルルート配信手段（２３ｅ）は更に、前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記再探索ポイント用センタールートを前記移動端末（１）に送信し、
更に前記端末側制御部（１６）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（１４０）が送信した前記再探索ポイント用マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記再探索ポイント用センタールートを受信したことに基づいて、前記再探索ポイント用センタールートを経路案内用のルートとして使用するセンタールート使用手段（３６０、３６２〜３６８）を備えたことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記センターマルチモーダルルート探索手段（２３ｄ）は、算出した前記センタールート上に１つまたは複数の再探索ポイントを設定し、
前記マルチモーダルルート配信手段（２３ｅ）は、前記センターマルチモーダルルート探索手段（２３ｄ）が設定した前記１つまたは複数の再探索ポイントを、前記移動端末（１）に送信し、
前記再探索ポイント設定手段（１６５、１７０）は、前記マルチモーダルルート配信手段（２３ｅ）によって送信された前記再探索ポイントを、前記経路案内用のルート上の再探索ポイントとして設定することを特徴とする請求項２に記載の通信システム。
【請求項４】
前記センタールート使用手段（３６０、３６２〜３６８）は、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを、
前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する時間および前記経路案内用のルートを現在位置から目的地まで移動するのに要する時間と、
前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する料金および前記経路案内用のルートを現在位置から目的地まで移動するのに要する料金と、
ユーザの選択操作と、
のうちいずれか１つまたは複数に基づいて判定し、有利であると判定した場合に、前記再探索ポイント用センタールートを新たな経路案内用のルートとして使用し、有利でないと判定した場合に、前記経路案内用のルートをそのまま経路案内用のルートとして使用することを特徴とする請求項２または３に記載の通信システム。
【請求項５】
前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）は、前記再探索ポイント用マルチモーダルルート探索要求に前記経路案内用のルートを含め、
前記マルチモーダルルート配信手段（２３ｅ）は、前記再探索ポイント用マルチモーダルルート探索要求に含まれる前記経路案内用のルートと、前記現状公共交通機関データベース（２２ｃ）に基づいて、少なくとも当該経路案内用ルートの各区間の現状の移動所要時間に関する不利情報を取得し、その取得した不利情報を前記再探索ポイント用センタールートと共に前記移動端末（１）に送信し、
前記センタールート使用手段（３６２〜３６８）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）が送信した前記不利情報を利用して前記経路案内用のルートの各区間の移動所要時間を再計算し、再計算した移動所要時間を用いて、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを判定することを特徴とする請求項４に記載の通信システム。
【請求項６】
道路構成および公共交通機関の乗降施設の位置を含むセンター側地図データベース（２２ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールおよび定常運行状態の運行スケジュールに対する現在の運行変化状況を含む現状公共交通機関データベース（２２ｃ）を記憶するセンター（２）、と通信可能な移動端末であって、
道路構成および前記公共交通機関の乗降施設の位置を含む端末側地図データベース（１５ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）とを記憶する端末側記憶部（１５）、および、端末側制御部（１６）を備え、
前記端末側制御部（１６）は、
前記センター（２）を利用せず、前記端末側地図データベース（１５ｂ）および前記定常公共交通機関運行データベース（１５ｃ）を用いて、公共交通機関を利用せずに移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なローカルルートを算出するローカルマルチモーダルルート探索手段（１２０）と、
前記ローカルマルチモーダルルート探索手段（１２０）によって算出された前記ローカルルートが公共交通機関を利用しているか否かを判定する判定手段（１３０）と、
前記判定手段（１３０）が利用していないと判定したことに基づいて、前記ローカルルートを経路案内用のルートとして記録するローカルルート記録手段（１３５）と、
前記判定手段（１３０）が利用していると判定したことに基づいて、前記現在地と前記目的地を含んだマルチモーダルルート探索要求を前記センター（２）に送信するセンターマルチモーダルリクエスト手段（１４０）と、
前記センター（２）が、マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適なセンタールートを算出し、算出した前記センタールートを当該移動端末に送信したとき、前記センタールートを受信したことに基づいて、前記センタールートを経路案内用のルートとして記録するセンタールート記録手段（１６０）と、を備えた移動端末。
【請求項１】
移動端末（１）と、前記移動端末（１）と通信可能なセンター（２）とを備えた通信システムであって、
前記移動端末（１）は、道路構成および公共交通機関の乗降施設の位置を含む端末側地図データベース（１５ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）とを記憶する端末側記憶部（１５）、および、端末側制御部（１６）を備え、
前記センター（２）は、道路構成および前記公共交通機関の乗降施設の位置を含むセンター側地図データベース（２２ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールおよび定常運行状態の運行スケジュールに対する現在の運行変化状況を含む現状公共交通機関データベース（２２ｃ）とを記憶する前記センター側記憶部（２２）、および、センター側制御部（２３）を備え、
前記端末側制御部（１６）は、
前記センター（２）を利用せず、前記端末側地図データベース（１５ｂ）および前記定常公共交通機関運行データベース（１５ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なローカルルートを算出するローカルマルチモーダルルート探索手段（１２０）と、
前記ローカルマルチモーダルルート探索手段（１２０）によって算出された前記ローカルルートが公共交通機関を利用しているか否かを判定する判定手段（１３０）と、
前記判定手段（１３０）が利用していないと判定したことに基づいて、前記ローカルルートを経路案内用のルートとして記録するローカルルート記録手段（１３５）と、
前記判定手段（１３０）が利用していると判定したことに基づいて、前記現在地と前記目的地を含んだマルチモーダルルート探索要求を前記センター（２）に送信するセンターマルチモーダルリクエスト手段（１４０）と、を備え、
前記センター側制御部（２３）は、
前記センターマルチモーダルリクエスト手段（１４０）によって前記移動端末（１）から送信された前記マルチモーダルルート探索要求を受信するマルチモーダルルート探索要求受信手段（２３ｃ）と、
前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適なセンタールートを算出するセンターマルチモーダルルート探索手段（２３ｄ）と、
前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記センタールートを前記移動端末（１）に送信するマルチモーダルルート配信手段（２３ｅ）と、を備え、
更に前記端末側制御部（１６）は、前記センターマルチモーダルリクエスト手段（１４０）が送信した前記マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記センタールートを受信したことに基づいて、前記センタールートを経路案内用のルートとして記録するセンタールート記録手段（１６０）を備えたことを特徴とする通信システム。
【請求項２】
更に前記端末側制御部（１６）は、前記ローカルルートおよび前記センタールートのうち経路案内用のルートとするルート上に、１つまたは複数の再探索ポイントを設定する再探索ポイント設定手段（１６５、１７０）を備え、
更に前記端末側制御部（１６）は、前記経路案内用のルートを案内しているときに、前記移動端末（１）が前記再探索ポイントのいずれかに対して前記経路案内用のルートに沿って基準距離以内の手前に接近したか否かを判定し、接近したと判定したことに基づいて、現在地と前記目的地を含んだ再探索ポイント用マルチモーダルルート探索要求を前記センター（２）に送信する再探索ポイント用センターマルチモーダルリクエスト手段（３４０）を備え、
前記センター側制御部（２３）の前記マルチモーダルルート探索要求受信手段（２３ｃ）は更に、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）によって前記移動端末（１）から送信された前記再探索ポイント用マルチモーダルルート探索要求を受信し、
前記センターマルチモーダルルート探索手段（２３ｄ）は更に、前記マルチモーダルルート探索要求受信手段（２３ｃ）が前記再探索ポイント用マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記再探索ポイント用マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適な再探索ポイント用センタールートを算出し、
前記マルチモーダルルート配信手段（２３ｅ）は更に、前記センターマルチモーダルルート探索手段（２３ｄ）が算出した前記再探索ポイント用センタールートを前記移動端末（１）に送信し、
更に前記端末側制御部（１６）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（１４０）が送信した前記再探索ポイント用マルチモーダルルート探索要求の応答として、前記マルチモーダルルート配信手段（２３ｅ）が送信した前記再探索ポイント用センタールートを受信したことに基づいて、前記再探索ポイント用センタールートを経路案内用のルートとして使用するセンタールート使用手段（３６０、３６２〜３６８）を備えたことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記センターマルチモーダルルート探索手段（２３ｄ）は、算出した前記センタールート上に１つまたは複数の再探索ポイントを設定し、
前記マルチモーダルルート配信手段（２３ｅ）は、前記センターマルチモーダルルート探索手段（２３ｄ）が設定した前記１つまたは複数の再探索ポイントを、前記移動端末（１）に送信し、
前記再探索ポイント設定手段（１６５、１７０）は、前記マルチモーダルルート配信手段（２３ｅ）によって送信された前記再探索ポイントを、前記経路案内用のルート上の再探索ポイントとして設定することを特徴とする請求項２に記載の通信システム。
【請求項４】
前記センタールート使用手段（３６０、３６２〜３６８）は、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを、
前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する時間および前記経路案内用のルートを現在位置から目的地まで移動するのに要する時間と、
前記再探索ポイント用センタールートを現在位置から目的地まで移動するのに要する料金および前記経路案内用のルートを現在位置から目的地まで移動するのに要する料金と、
ユーザの選択操作と、
のうちいずれか１つまたは複数に基づいて判定し、有利であると判定した場合に、前記再探索ポイント用センタールートを新たな経路案内用のルートとして使用し、有利でないと判定した場合に、前記経路案内用のルートをそのまま経路案内用のルートとして使用することを特徴とする請求項２または３に記載の通信システム。
【請求項５】
前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）は、前記再探索ポイント用マルチモーダルルート探索要求に前記経路案内用のルートを含め、
前記マルチモーダルルート配信手段（２３ｅ）は、前記再探索ポイント用マルチモーダルルート探索要求に含まれる前記経路案内用のルートと、前記現状公共交通機関データベース（２２ｃ）に基づいて、少なくとも当該経路案内用ルートの各区間の現状の移動所要時間に関する不利情報を取得し、その取得した不利情報を前記再探索ポイント用センタールートと共に前記移動端末（１）に送信し、
前記センタールート使用手段（３６２〜３６８）は、前記再探索ポイント用センターマルチモーダルリクエスト手段（３４０）が送信した前記不利情報を利用して前記経路案内用のルートの各区間の移動所要時間を再計算し、再計算した移動所要時間を用いて、前記再探索ポイント用センタールートの方が前記経路案内用のルートよりも有利か否かを判定することを特徴とする請求項４に記載の通信システム。
【請求項６】
道路構成および公共交通機関の乗降施設の位置を含むセンター側地図データベース（２２ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールおよび定常運行状態の運行スケジュールに対する現在の運行変化状況を含む現状公共交通機関データベース（２２ｃ）を記憶するセンター（２）、と通信可能な移動端末であって、
道路構成および前記公共交通機関の乗降施設の位置を含む端末側地図データベース（１５ｂ）と、前記公共交通機関の定常運行状態の運行スケジュールを含む定常公共交通機関運行データベース（１５ｃ）とを記憶する端末側記憶部（１５）、および、端末側制御部（１６）を備え、
前記端末側制御部（１６）は、
前記センター（２）を利用せず、前記端末側地図データベース（１５ｂ）および前記定常公共交通機関運行データベース（１５ｃ）を用いて、公共交通機関を利用せずに移動するルート、および公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、現在地から目的地までの最適なローカルルートを算出するローカルマルチモーダルルート探索手段（１２０）と、
前記ローカルマルチモーダルルート探索手段（１２０）によって算出された前記ローカルルートが公共交通機関を利用しているか否かを判定する判定手段（１３０）と、
前記判定手段（１３０）が利用していないと判定したことに基づいて、前記ローカルルートを経路案内用のルートとして記録するローカルルート記録手段（１３５）と、
前記判定手段（１３０）が利用していると判定したことに基づいて、前記現在地と前記目的地を含んだマルチモーダルルート探索要求を前記センター（２）に送信するセンターマルチモーダルリクエスト手段（１４０）と、
前記センター（２）が、マルチモーダルルート探索要求を受信したことに基づいて、前記センター側地図データベース（２２ｂ）および前記現状公共交通機関データベース（２２ｃ）を用いて、公共交通機関を利用せずに移動するルートおよび公共交通機関を利用して移動するルートを最適なルート中の区間の候補として、前記マルチモーダルルート探索要求中の前記現在地から前記目的地までの最適なセンタールートを算出し、算出した前記センタールートを当該移動端末に送信したとき、前記センタールートを受信したことに基づいて、前記センタールートを経路案内用のルートとして記録するセンタールート記録手段（１６０）と、を備えた移動端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−７８１１２（Ｐ２０１２−７８１１２Ａ）
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願番号】特願２０１０−２２０９５２（Ｐ２０１０−２２０９５２）
【出願日】平成２２年９月３０日（２０１０．９．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＶＩＣＳ
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願日】平成２２年９月３０日（２０１０．９．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＶＩＣＳ
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
[ Back to top ]