JP4084901B2

JP4084901B2 - 情報提供システム

Info

Publication number: JP4084901B2
Application number: JP5865399A
Authority: JP
Inventors: 君吉待井; 和義古賀; 松尾　　茂; 吉高新
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1999-03-05
Filing date: 1999-03-05
Publication date: 2008-04-30
Anticipated expiration: 2019-03-05
Also published as: JP2000258172A

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークにアクセスする情報端末及び情報を提供するサーバシステムに係り、特に家庭内、自動車等の移動体内、または歩行中などさまざまな場所でインターネットの情報をアクセスすることを可能とする情報端末と、前記端末のそれぞれの使用場所に最適な形態で情報を提供するサーバとを備える情報提供システムに関する。
【０００２】
【従来の技術】
特開平１０−１０５０５３号公報、特開平７−２６２４９４号公報には、ネットワーク型の地図情報提供システムが開示されている（第１、第２の従来技術）。上記第１の従来技術では、所定のエリア単位で地図情報を受信し、自車がエリアから外れる前に次のエリアの地図情報を受信する。次のエリアの地図情報を受信した後、その前に使用していた地図データを消去する。上記第２の従来技術では、センターに経路情報を記憶し、端末から送信された現在位置情報および目的地位置情報に基づいて、端末の現在地近傍の主要な情報を端末に送信する。
【０００３】
また、特開平１０−１２２８８５号公報には、ナビゲーション装置が開示されている（第３の従来技術）。この第３の従来技術では、ルート入力用のコンピュータからナビゲーションシステム本体に対して走行ルートを入力する。ナビゲーションシステムは、分岐点に近づいたときに、その走行ルートと現在地に基づいて分岐方向を求める。
【０００４】
また、特開平７−３３２９９３号公報にもナビゲーション装置が開示されている（第４の従来技術）。この第４の従来技術では、推奨ルート途中にある交差点、形状の複雑な交差点などを検出する手段を備えている。
【０００５】
【発明が解決しようとする課題】
しかしながら、上記第１の従来技術においては、地図の切れ目に近づいたときに次のエリアの地図全体をダウンロードするので、端末側のメモリが足りなくなった場合に対処できないと考えられる。本従来技術では、使い終えた地図を消去する例も開示されてはいるが、次のエリアの地図データをダウンロードする前ではないので、メモリ不足の対策とはなり得ない。また、地図の切れ目に近づいてからダウンロードするので、例えばダウンロードする地点がトンネル内のように通信できない場所などでダウンロードできなかった場合に、ユーザは地図を参照することができない。また、道なりに進めばよい場合など、地図が必ずしも必要でない場合でも地図をダウンロードすることになり、通信料金が高くなると考えられる。
【０００６】
上記第２の従来技術では、端末の位置情報に基づいて、端末の現在地近傍の地図をサーバからダウンロードするので、第１の従来技術と同様、ダウンロードする時点で通信不良があった場合にダウンロードできず、地図を参照することができなくなる。また、端末側のメモリが足りない場合の対処について記述が無く、端末のメモリ不足に対応できないと考えられる。
【０００７】
上記第３、第４の従来技術では、端末が持っている地図データベースのデータを用いることから、道路の増設や閉鎖など地図の更新に対応できない。特に第４の従来技術では、重要地点はあくまでも地図の拡大表示に使用されるだけであり、重要地点において道路増設などの変更があった場合にはユーザに混乱をもたらしてしまう。また、地図データベースを格納するための外部記憶装置が必要になり、システムが高額になったり、パッケージが大きくなったりする。
【０００８】
本発明は上記の各問題点を鑑みてなされたもので、サーバからの地図情報提供サービスをより効率的、低価格で実施することを可能とする、サーバと車両に搭載される端末とを備える情報提供システムを提供することを目的とする。
【０００９】
また、本発明の他の目的は、サーバと端末との通信の負担が大きくなることを防ぐ手段を提供することにある。
【００１０】
また、本発明の他の目的は、情報提供システムにおいて、サーバからダウンロードするタイミングを最適化することが可能な手段を提供することにある。
【００１１】
【課題を解決するための手段】
上記目的を達成するために本発明は、車両に搭載され目的地までの経路誘導を行う端末器と、該端末器へ経路誘導に用いる地図データを少なくとも含む情報を提供するサーバ装置とを備える情報提供システムにおいて、前記端末器および前記サーバ装置のうちいずれか一方に、前記地図データを少なくとも含む情報を前記サーバ装置から前記端末器へ送信すべきタイミングを決定する情報提供タイミング決定手段を備えることを特徴とする。
【００１２】
ここで、前記情報提供タイミング決定手段は、例えば、自車の位置を利用して、予め設定された位置に自車が到達した場合、前記地図データを少なくとも含む情報を前記サーバ装置から前記端末器へダウンロードするタイミングを決定する。また、前記情報提供タイミング決定手段は、前記端末器のその時点での利用可能な資源情報、および、目的地までの誘導経路に関する情報のうち、少なくとも一方を用いて、前記地図データを少なくとも含む情報を送信すべきタイミングを決定すること構成としてもよい。
【００１３】
また、上記目的を達成するために本発明は、情報提供システムにおいて、前記サーバ装置および前記端末器のうちいずれか一方に、該端末器のその時点での資源情報を取得して、該資源情報に応じて前記地図データを少なくとも含む情報の情報量を計算する手段を有し、前記サーバ装置は、前記算出された情報量に応じて、前記端末器に送信すべき情報を生成することを特徴とする。
【００１４】
【発明の実施の形態】
本発明の実施の形態について、以下、図面を参照しながら述べる。
【００１５】
図１３は、本実施形態における情報提供システムの全体構成例を示したものである。本実施形態のシステムにおいては、インターネット網１３０１に、サーバ１３０２とプロバイダ１３０４が接続されている。端末器１３０６は、自車１３０５に備えられ、ＧＰＳ衛星１３０７からの信号を受信して現在地を検出する機能を備えている。サーバ１３０２は、端末器１３０６からの要求に応じて、地図データを提供する。端末器１３０６は、携帯電話で電話網１３０３を経由し、プロバイダ１３０４に接続してインターネット網１３０１にアクセスし、例えば、端末器１３０６の位置に応じてサーバ１３０２から地図をダウンロードする。
【００１６】
本実施形態における端末器１３０６の構成例を図１に示す。
【００１７】
端末器１３０６は、例えば図１に示すように、メモリ部１０１、ＧＰＳ部１０２、位置判定部１０３、入力装置１０４、処理装置１０５、表示制御装置１０６、地図表示判定装置１０７、外部記憶装置１０８、通信装置１０９、および、音声出力装置１１０を備えている。
【００１８】
端末器１３０６は、通信装置１０９を通じてサーバ１３０２からデータを受け取る。受け取ったデータは、メモリ部１０１や外部記憶装置１０８に格納され、後に利用される。
【００１９】
ＧＰＳ部１０２は、自車１３０５の位置を把握するためのものであり、自車１３０５の位置の緯度、経度を計測する。位置判定装置１０３は、ＧＰＳ部１０２が計測した緯度・経度情報を基に、自分がどの道路のどの辺りにいるのかを計算する。すなわち、地図情報と緯度・経度情報とをマッピングする。
【００２０】
地図表示判定装置１０７は、現在位置が地図をダウンロードすべき地点かどうかを判定するものである。
【００２１】
表示制御装置１０６は、自動車にすでに備え付けられている表示装置に表示データを送るものである。なお、本実施形態では端末器に表示装置を含んでいないが、表示装置も含む構成としてももちろん構わない。
【００２２】
入力装置１０４は、目的地等を入力するのに用いられる。入力装置１０４としては、リモコンが一般的に用いられる。但し、リモコンだけでなく、手書き入力用のタブレットであってもよい。音声出力装置１１０は、端末器１３０６またはサーバ１３０２からのメッセージを音声出力する。
【００２３】
次に、図２を用いて、端末器１３０６とサーバ１３０２の処理プロセスを説明する。
【００２４】
本処理プロセスでは最初、端末器１３０６のＧＰＳ部１０２が自車１３０５の位置を測定する（ステップ２０１）。次に、ユーザが端末器１３０６を操作して目的地を設定し、目的地はメモリ１０１または外部記憶装置１０８に保持される（ステップ２０２）。
【００２５】
ここで、目的地を端末器１３０６で保持するのは、経路途中で車のエンジンを切って再スタートしたときに、ユーザが目的地を再入力する手間を省くためである。エンジンを切って端末器１３０６の電源が切れるたびに目的地を設定するのは、ユーザにとって負担になる。また、本来の経路を外れてしまったときに経路を再計算するときにも、その度に目的地を設定するのは負担になる。目的地が保持されていれば、経路途中であることがわかり、保持されていなければ経路の途中ではなく、新たに目的地を設定する。
【００２６】
次に、通信装置１０９を用いて自車１３０５の位置と目的地とを、サーバ１３０２に送信する（ステップ２０３）。尚、ここで通信装置１０９として携帯電話を想定している。このとき、端末器１３０６は電話をサーバ１３０２に自動的にかけ、送信が終わると自動的に電話を切る機能を有するものとする。
【００２７】
サーバ１３０２は自車１３０５の位置と目的地を受信し、目的地までの経路を計算する（ステップ２０９）。尚、自車１３０５の位置と目的地は緯度・経度をサーバ１３０２に送信するか、または地名を送信してサーバ１３０２で緯度・経度に変換する。
【００２８】
次に、端末器１３０６が地図を表示すべき位置（以下、地図表示位置と呼ぶ）を計算する（ステップ２１０）。地図表示位置としては、例えば車が曲がるべき交差点を抽出する。ただし、交差点であっても、道なりにまっすくでよい場合は、地図をダウンロードしなくてもよいので、この場合は地図表示位置としない。また、交差点だけでなく、高速道路で降りるべきインターチェンジも地図表示位置としてもよい。また、同じ道路名でない道路に進入する地点も、地図表示位置になる。あるいは、既存のナビゲーションシステムにおいて、曲がるべき交差点を認識する手法を用いて、地図表示位置の求める構成としてもよい。
【００２９】
経路を計算し、地図表示位置を計算した後、サーバ１３０２はそれらを端末器１３０６に送信する（ステップ２１１）。
【００３０】
端末器１３０６はそれらを受信し、メモリ部１０１に格納する（ステップ２０４）。受信した経路情報は、自車１３０５の位置が経路から外れていないかどうかの確認に使われる。ここまでで、準備が完了する。
【００３１】
車が走行している場合、ＧＰＳ部１０２は常に自車１３０５の位置を測定し（ステップ２０５）、自車１３０５の位置に応じて処理を実行する。サーバ１３０２から受信した地図表示位置と自車１３０５の位置とを比較し、地図表示位置か、地図の拡大表示地点か、目的地か、その他かを判定する。経路外にあると判定された場合には、ステップ２０３へ処理を戻す。
【００３２】
地図表示位置周辺であれば、通信装置１０９を通じて、地図表示位置周辺の地図データをサーバ１３０２から受信する。具体的には、地図表示位置に近づいたら、自動的にサーバ１３０２に電話をかけて地図データ要求をサーバ１３０２へ送る（ステップ２１３）。サーバ１３０２では、該要求に該当する地図を検索し（ステップ２１４）、さらに要求されている地図の種類を判定し（ステップ２１５）、デフォルトの場合には予め設定されたデフォルト縮尺の地図を送信し（ステップ２１６）、拡大の場合には拡大地図を送信する（ステップ２１７）。
【００３３】
端末器１３０６では、サーバ１３０２から送られてきた地図データを受信し、受信が終わったら自動的に電話を切る。このとき、サーバ１３０２は携帯電話の電話番号によって、どのユーザからデータを受信したか判定してもよい。受信したデータは、表示制御装置１０６を通じて、表示装置（図示しない）に表示される（ステップ２０６）。さらに自車１３０５の位置が地図表示位置に近づくと、地図をさらに拡大表示する（ステップ２０７）。
【００３４】
この機能に関しては、前記地図データがベクトルデータであれば、端末器１３０６で拡大することが可能である。一方、前記地図データがイメージデータであれば、端末器１３０６で拡大することは不可能であるから、拡大された地図データをサーバ１３０２に要求する。
【００３５】
目的地に到達した場合には、全部の処理が終了する。そのとき、端末器１３０６に保持されていた経路情報、目的地は消去される（ステップ２１２）。
【００３６】
また、その他の場所であれば、表示装置の表示を消去する（ステップ２０８）。すなわち、地図表示位置や目的地から離れていれば、何も表示する必要が無い。但し、表示を消去するだけでなく、自車１３０５の位置の近くにあるランドマークに関連する情報を表示してもよい。
【００３７】
また、地図表示位置に来ても、必ずしも地図をダウンロードする必要はない。例えば、地図表示位置の手前に来たら、端末器１３０６がユーザに対して、地図をダウンロードする旨を伝える。その方法は、例えば図１６に示すように、ウィンドウ１６０１を表示する。それと同時に「次のエリアの地図をダウンロードします」といった音声を流してもよい。これに対して、ユーザが何もしなければ、端末器１３０６は地図のダウンロードを開始する。ユーザが入力装置１０４から何らかの方法でキャンセルの意志を伝えれば、ダウンロードしない。入力装置１０４としては、リモコンなどが使用可能である。
【００３８】
尚、上述した処理は端末器１３０６の電源が入っている間に実行されるものである。例えば、経路の途中で休憩した場合などで車のエンジンを切ったときには、端末器１３０６の電源も切れることが考えられる。そこで、エンジンを再スタートさせたときは、目的地が端末器１３０６内に保持されているかどうかを確認する。保持されていれば、目的地に到達していないということであるから、ステップ２０５から再開する。目的地が保持されていなければ、ステップ２０１から開始する。
【００３９】
図３は、本実施形態における表示の遷移例を表したものである。
【００４０】
画面３０１は、道なりにまっすぐ進んでいるときの表示例である。ここでは何も表示してないが、自車１３０５の位置の近くにあるランドマークに関連する情報を表示するようにしてもよい。ランドマークとしては、例えばレストラン等が挙げられる。レストランから発せられている情報、例えばメニューや値段を受信して表示装置に表示してもよい。
【００４１】
地図表示位置に近づいた場合の画面が画面３０２である。地図表示位置に近づいたかどうかは、自車１３０５の位置と地図表示位置との距離が一定以内になったかどうかで判定できる。これはＧＰＳ部１０２で測定した自車位置３０４と、地図表示位置３０５との距離を計算するだけで求めることができる。本画像例では、さらに、矢印３０６によって、車が進むべき方向を示す。画面３０２の場合では、地図表示位置３０５から左折するように示している。
【００４２】
さらに、地図表示位置３０５により近づいたら、画面３０３のように交差点付近がさらに拡大表示される。画面３０３でも、自車位置３０４、矢印３０６を表示している。この拡大表示の場合も、端末器１３０６がベクトルデータを受信した場合は端末器１３０６で拡大することが可能である。一方、イメージデータを受信した場合は、拡大された地図をサーバ１３０２からダウンロードする。
【００４３】
拡大表示された後、曲がるべき交差点を曲がったら、地図の表示を終了し、画面表示を消去する。そして、そのまま道なりに進んでいる間は、何も表示しないかあるいはランドマークに関する情報を表示する。または、図１１に示すようにその付近の概略地図を表示してもよい。これは、上記と同様である。
【００４４】
ランドマークに近づいたときにそれに関する情報を表示するには、端末器１３０６がランドマークの所在地を予め知っておく必要があるので、予めサーバ１３０２から受信する必要がある。そして、自車位置を常に計測して、ランドマークに近づいたかどうかを判断する必要がある。
【００４５】
図４は、サーバ１３０２の構成例を示したものである。
【００４６】
本例のサーバ１３０２は、通信装置４０１、入力受付部４０２、検索エンジン４０３、会員情報データベース４０４、地図データベース４０５、経路計算部４０６、イメージ展開部４０７、地図表示位置決定部４０８、ＨＴＭＬ変換部４０９、課金制御部４１０、イメージ／ベクトル判定部４１１、および、間引き判定部４１２を備えている。
【００４７】
本例のサーバ１３０２において、端末器１３０６からの要求はすべて通信装置４０１を通して受信する。受信したデータは、入力受付部４０２にて、どんなデータを受信したのかを判定する。
【００４８】
会員情報を受信した場合には、当該会員が、サーバ１３０２にアクセス可能な会員かどうかを判定する。アクセス不可能な会員ならば、以後のサービスを提供しないように端末器１３０６に通知する。または、イメージ地図データだけの提供にとどめるようにする。
【００４９】
会員情報は課金制御部４１０に送られ、課金制御部４１０は、会員情報ＤＢ４０４の会員情報を参照して、どの会員に課金するかを判定し、その会員のＩＤを端末器１３０６内部に保存する。
【００５０】
端末ユーザから自車１３０５の位置と目的地とに関するデータが送信されてきた場合にも、ユーザ情報の場合と同様、データはサーバ１３０２の通信装置４０１を通じて入力受付部４０２に送られる。自車１３０５の位置と目的地は、緯度・経度で表されている。目的地は緯度・経度でなく、目的地周辺の市外局番や郵便番号であってもよいが、その場合、入力受付部４０２等の所定の個所でそれらのデータを緯度・経度に変換する。
【００５１】
入力受付部４０２は自車１３０５の位置と目的地の緯度・経度データを検索エンジン４０３に渡し、検索エンジン４０３は地図ＤＢ４０５から地図データを検索し、目的とする地図データが含まれているメッシュの格納アドレスに対応する地図ＤＢ４０５中のインデックス（Index）を返してもらう。地図ＤＢ４０５は、一般に使われている地図データベースでよい。但し、ベクトル地図データを保持していることが望ましい。
【００５２】
インデックスがわかった後、当該インデックスは経路計算部４０６に送られ、自車１３０５の位置から目的地までの経路を計算する。経路を計算した後、その経路データは地図表示位置決定部４０８に送られ、端末器１３０６が地図をダウンロードする位置を決定する。
【００５３】
また、送信すべき地図種の判定を行うイメージ／ベクトル判定部４１１が、アクセスしているユーザが会員かどうかによってイメージ地図を提供するかベクトル地図を提供するかを判定する。会員であれば、ベクトル地図データを提供し、会員でなければイメージ地図データを提供する。ベクトル地図を提供すると、端末器１３０６で自由に拡大・縮小等ができるので、提供された地図とは異なる縮尺の地図が欲しくなっても、その度にサーバ１３０２からダウンロードする必要はなくなり、通信の負担が減る。
【００５４】
会員であれば検索エンジン４０３からインデックスを受け取り、さらに経路計算部４０６から経路情報を受け取り、経路情報と地図ＤＢ４０５のベクトル地図データを通信装置４０１に送る。通信装置４０１はそれらのデータを端末器１３０６に送信する。会員でなければ、イメージ／ベクトル判定部４１１は、地図ＤＢ４０５のインデックスと経路データをイメージ展開部４０７に送り、イメージ展開部４０７がイメージデータを生成する。当該イメージデータは、地図データの上に、経路を重ねて表示したものである。イメージ展開部４０７で作成されたイメージデータは、HTML変換部４０９でＨＴＭＬデータに変換される。このＨＴＭＬデータは通信装置４０１を通じて端末器１３０６に送信される。
【００５５】
端末器１３０６にデータを送信すると、課金制御部４１０は、どの会員にいくら課金するかを計算する。例えば、イメージ地図データを提供する場合は無償、ベクトル地図データを提供する場合は有償といった課金も可能である。
【００５６】
イメージ地図データの場合、受け取った端末器１３０６では、拡大・縮小等の機能があっても、あまり有効でない。したがって、例えば図３の画面３０２から画面３０３に切り替えるような場合、イメージ地図を２枚ダウンロードして表示することになり、通信の負担が増えるので、通信料金も増える。そこで、イメージ地図データを提供してもらう場合は、通信料金だけの負担となるようにし、サービス料金を徴収しない構成としてもよい。
【００５７】
ベクトル地図データの場合、一度ダウンロードすれば拡大・縮小は自由にできるので、例えば画面３０２から画面３０３に切り替えるような場合、地図をダウンロードし直す必要はなく、通信料金の負担も少なくなる。また、立体的な表示を可能とするための情報も含む地図データを利用するようにすれば、地図の３次元表示なども可能になり、地図を見やすく表示することが可能になる。したがって、ベクトル地図データの恩恵に浴するユーザからは、サービス料金を徴収するようにしてもよい。
【００５８】
地図の３次元表示には、既存のいわゆる「バードビュー」と呼ばれる技術を用いてよい。この技術は、２次元情報を斜め上から見ているような感覚で表示するものであり、既存のカーナビゲーションシステムで実用化されている。これは、サーバ１３０２から受信した地図データに対しても応用可能である。
【００５９】
図８に、課金制御部３１０で保持している課金情報の一例を示す。
【００６０】
課金情報としては会員ＩＤ８０１、データ量８０２、地図種８０３、アクセス日時８０４を保持している。このような課金情報は所定の締め日にまとめて集計されて課金額が決定され、ユーザが契約している金融機関に送られ、ユーザの口座から自動的に料金が引き落とされて支払われる。
【００６１】
端末器１３０６からサーバ１３０２に送信されるデータとしては、会員情報、自車位置、目的地などがある。これらのデータを送信するためのプロトコルを図５に示す。図５（ａ）は端末器１３０６からサーバ１３０２に、自車位置と目的地を送信するためのものである。この場合、コマンド５０１、会員ＩＤ５０２、自車位置５０３、目的地５０４、端末情報５０５を一つのパケットにして送信する。図５（ｂ）は、端末器１３０６からサーバ１３０２に、地図データを要求するためのものである。この場合、コマンド５０１、会員ＩＤ５０２、目的地５０４、縮尺５０６、端末情報５０５を一つのパケットにして送信する。
【００６２】
どちらのプロトコルでも、先頭にコマンドをつける。コマンドの種類は、経路計算要求、地図情報要求がある。コマンドの識別子としては、１バイトの文字コードを用いてよい。また、会員ＩＤ５０２は、サーバ１３０２に何らかのデータを送信する場合には必ずつける。あるいは、会員ＩＤ５０２をつけず、携帯電話の番号を会員ＩＤとして代用してもよい。
【００６３】
コマンドが経路計算要求であれば、経路計算要求コマンド、会員ＩＤ５０２、自車位置５０３、目的地５０４、端末情報５０５を一つのパケットにしてサーバ１３０２に送信する。会員ＩＤ５０２は、サーバ１３０２からベクトル地図データを提供してもらえる会員のＩＤである。もし会員でなければ、会員ＩＤ５０２は負の数など、ＩＤとして使われない数値とする。自車位置５０３と目的地５０４は、緯度・経度とする。
【００６４】
コマンドが地図情報要求であれば、コマンド５０１、会員ＩＤ５０２、目的地５０４、縮尺５０６を一つのパケットにしてサーバ１３０２に送信する。会員ＩＤ５０２と目的地５０４は、上記の通りである。縮尺５０６は、地図の縦幅・横幅の長さをメートル単位で表したものである。サーバ１３０２は受け取ったパケットの先頭についているコマンドに応じて、上記の処理を実行する。
【００６５】
会員ＩＤ５０２は、図６に示すような画面を用いて、端末器１３０６の立ち上げ時に１回だけ入力する。会員ＩＤ５０２の入力には、画面下方に表示されているテンキー６０６を用いる。入力された数字は、ＩＤフィールド６０１に表示され、ＯＫボタン６０２を押すと、メモリ１０１に記憶される。Ｃｌｅａｒボタン６０２を押すと、ＩＤフィールド６０１の表示がクリアされる。終了ボタン６０４を押すと、端末器１３０６に記憶された会員ＩＤを消去する。ＢＳボタン６０５は、いわゆるバックスペースであり、ＩＤフィールド６０１に表示された文字を右端から１文字ずつ消去する。
【００６６】
また、会員ＩＤを入力せずにＯＫボタン６０２を押すと、会員ＩＤには任意の負の数が設定され、メモリ１０１に記憶される。あるいは、会員ＩＤ５０２を入力せず、通信装置１０９として用いている携帯電話の電話番号を会員ＩＤとして代用してもよい。
【００６７】
会員情報ＤＢ４０４の構成例を、図１２に示す。会員情報ＤＢ４０４には、名前１２０１、会員ＩＤ１２０２、携帯電話番号１２０３、金融機関名１２０４、連絡先１２０５が含まれている。
【００６８】
会員ＩＤ１２０２は、システムを使う前に予めサービスセンタから発行してもらう。携帯電話番号１２０３は、通信装置１０９として用いる携帯電話の番号である。この携帯電話番号は、会員ＩＤを発行せず、会員ＩＤの代わりとして用いる場合には、会員ＤＢ４０４に登録しておく必要があるが、会員ＩＤを発行する場合は必ずしも必要でない。金融機関名１２０４は、ユーザが契約している金融機関の名前で、サービス料金を引き落とすための金融機関である。但し、サービス料金を引き落としにせず、ユーザからの振り込みにする場合には必要でない。連絡先１２０５は、ユーザの住所と有線電話番号であり、サービス料金の請求書や領収書を送付する住所である。
【００６９】
目的地は、図７に示す画面を用いて入力する。それには、地名だけでなく、目的地の電話番号の市外局番や郵便番号を入力してもよい。電話番号は電話番号フィールド７０１に、郵便番号は郵便番号フィールド７０２に入力する。地名は地名フィールド７０３に入力する。すべてを入力する必要はなく、どれか一つを入力するだけでよい。電話番号と郵便番号の入力には、テンキー７０９を用いる。地名の入力にはひらがなキー７０８を用いる。１文字入力するたびに候補の地名が表示され、そこから選択することが可能である。
【００７０】
次に、端末器１３０６のメモリ等の資源が足りない場合の処理について述べる。本実施形態では、端末器１３０６のメモリが足りない場合、サーバ１３０２は地図データを間引きして端末器１３０６に送信するものとする。
【００７１】
端末器１３０６は、サーバ１３０２に地図データ要求するとき、端末器１３０６の資源に関する情報を一緒に送信する。資源に特に問題ない場合は資源に関する情報は何も送信しないが、資源が足りない場合は、端末器１３０６のメモリ容量をつけたパケットを送信する。このパケットは、これまでに述べたように、入力受付部３０２にて処理される。
【００７２】
また、サーバ１３０２の間引き判定部３１２は、端末器１３０６から受け取ったメモリ容量を参照し、間引きが必要ならば、端末器１３０６に送信する地図データを間引きしてから通信装置３０１にデータを送る。これによって、メモリの少ない端末でも、すべてのデータを受けられないまでも、それなりのサービスを受けることが可能になる。
【００７３】
間引きに付いては、ベクトル地図データの場合、主要道路だけを送信することにし、他の細い道路を省いたデータを送信する。イメージ地図データの場合は、解像度を落とした画像を送信する。
【００７４】
また、地図データだけでなく、地図データと共に送られるその外の情報、例えば経路誘導に係わる情報についても、その誤誘導が起こらないと考えられる程度にデータ量を削減して送信する構成としてもよい。
【００７５】
ベクトルデータ、イメージデータのどちらを送信するかを判定するフローの一例を図９に示す。図９では、ユーザが会員かどうかも考慮したフローを示している。
【００７６】
サーバ１３０２はデータを受け取ると（ステップ９０１）、会員ＩＤを調べ（ステップ９０２）、会員かどうかを判定する。会員ならば、端末情報を調べ（ステップ９０３）、メモリが足りていれば地図ＤＢ４０５のベクトル地図データそのまま端末器１３０６に送信する（ステップ９０５）。メモリが不足していれば、地図ＤＢ４０５のベクトル地図データを間引きしたものを端末器１３０６に送信する（ステップ９０６）。
【００７７】
もし会員でなければ、端末情報を調べ（ステップ９０４）、メモリが足りていれば、地図ＤＢ４０５の地図データからデフォルトの解像度でイメージデータを生成し、端末器１３０６に送信する（ステップ９０７）。メモリが不足していれば、デフォルトよりも解像度を下げてイメージデータを生成し、端末器１３０６に送信する（ステップ９０８）。
【００７８】
上述した実施形態では、データが必要になったらその都度サーバ１３０２に接続してデータを受信するものであった。しかし、その都度データをもらうのではなく、自車１３０５の位置と目的地をサーバ１３０２に送信した後で、データを一括して受信する構成としてもよい。以下に、本発明を適用した情報提供システムの他の実施形態について説明する。
【００７９】
本実施形態のシステムは、以下に詳細説明する処理フローを除き、上記実施形態のシステムと基本的には同様な構成を備えるものとする。図１０は、データを一括して受信する本実施形態のシステムのフローを示したものである。
【００８０】
本処理では最初、ＧＰＳ部１０２が自車１３０５の位置を測定した後（ステップ１００１）、目的地を設定して端末器１３０６に保存する（ステップ１００２）。次に携帯電話等をかけることで、自車１３０５の位置と目的地とをサーバ１３０２に送信する（ステップ１００３）。
【００８１】
サーバ１３０２はこれらのデータを受信後、目的地までの経路を計算し（ステップ１０１１）、地図表示位置を計算する（ステップ１０１２）。本実施形態では以下の処理が、上記実施形態と異なる。
【００８２】
次に、目的地までの地図を検索し、地図表示位置付近以外の地図は間引き（ステップ１０１３）、自車１３０５の位置周辺の地図、経路データ、地図表示位置、目的地までの地図を端末器１３０６に送信する（ステップ１０１４）。
【００８３】
端末器１３０６ではこれらのデータを受信後、メモリ１０１にデータを格納する（ステップ１００４）。このときに送信する地図データは、道なりにまっすぐのところはその道の情報だけを送信し、曲がるべき交差点付近に関しては詳細な情報を送信する。
【００８４】
例えば、日立から東京のある目的地に向かう場合、まず常磐自動車道または国道６号を通るので、常磐自動車道または国道６号の情報だけを端末器１３０６に送信し、その他の部分は送信しない。そして、常磐自動車道を降りたり、国道６号を外れたとき、端末器１３０６からサーバ１３０２に目的地までの経路計算と目的地までの地図を要求し、サーバ１３０２から端末器１３０６に送信する。
【００８５】
尚、目的地はこれまでに述べたのと同様、端末器１３０６の立ち上げ時にユーザが入力し、目的地に到着するまでは端末器１３０６で保持しているものとする。
【００８６】
サーバ１３０２からデータを受け取った後、ＧＰＳ部１０２で自車１３０５の位置を測定しながら、自車１３０５の位置に応じた処理を実行する（ステップ１００５）。
【００８７】
地図表示位置に近づいたら、受け取った地図データを基に地図表示位置付近を表示する（ステップ１００６）。さらに近づいたら、さらに拡大表示する（ステップ１００７）。但し、サーバ１３０２からベクトル地図データを受信している場合に限って、この処理が可能である。あるいは、端末器１３０６のメモリが少ない場合は、最初に通るべき道路の情報だけを受信して地図表示位置付近の詳細データを受信せず、地図表示位置に近づいたら、これまでに通ってきた経路の地図データを消去して、地図表示位置付近（例えば、地図表示位置から半径１〜５ｋｍ）の詳細データを受信するようにしてもよい。
【００８８】
ここで、地図表示位置付近における経路は、サーバ１３０２で計算してもよく、会員であれば経路情報をサーバ１３０２から受信し、会員でなければ地図上に経路を示したイメージ地図を受信する。あるいは、会員であれば地図表示位置付近のベクトル地図データを受信し、該ベクトル地図データに基づいて端末器１３０６で経路計算をしてもよい。
【００８９】
また、道なりにまっすぐでよい場合は、何も表示しなくてもよいし、その付近のランドマークに関する情報を表示したり、最初にダウンロードした地図情報を表示してもよい。
【００９０】
図１１は、経路途中の大まかな地図を表示する例を示したものである。画面１１０１には、国道１１０２、学校１１０３、郵便局１１０４、自車位置１１０５が表示されており、その他の情報は表示されていない。道なりにまっすぐでよい場合は、この程度の表示であってもユーザに対する援助になる。
【００９１】
また、道なりにまっすぐでよい場合、ユーザは次に曲がるべき場所までどれくらいかわからなくなって不安を感じることも考えられる。そのような場合でも、何らかのランドマークを表示すれば、自分がどこにいるかという目安にすることができる。これらの情報は、経路が決まったときにダウンロードした情報であってもよいし、ユーザが自分の居場所を確認したくなったときにサーバ１３０２から受け取ってもよい。
【００９２】
上記図１０の処理フローにおいて、目的地に到着したら、端末器１３０６に記憶されている経路情報、会員ＩＤ、地図情報を消去し（ステップ１００９）、すべての処理を終了する。
【００９３】
上記図１０に示す実施形態では予め間引きしたデータを送るものとしたが、データを間引きする代わりに、あらかじめベクトルデータに優先順位を付けておき、該優先順位および当該端末器のその時点での残りメモリ容量に応じてデータを送る構成としてもよい。以下にその構成例について説明する。
【００９４】
例えば、端末器１３０６のメモリ容量が少ない場合は、高速道路や国道などの主要道路データのみを送信し、メモリ容量に余裕があれば詳細な道路データを送信する。すなわち、例えば図１７に示すように、高速道路や国道などの主要道路の優先順位を高くし、その他の道路の優先順位を低く設定しておく。
【００９５】
このような構成によれば、端末器１３０６のメモリが足りない場合は、目的地までの大まかな経路を高速道路や国道などで表示させ、他の詳細な道路は表示しないようにすることが可能となる。
【００９６】
優先順位を決めるパラメータとしては、例えば、道路の種類（例えば高速＞国道＞県道＞その他）、自車位置からの距離（自車位置に近いほど優先順位が高い）、経路からの距離（経路周辺の優先度が高い）の３種類がある。
【００９７】
サーバ１３０２は、地図データに含まれる各情報に付いてこれらのパラメータの値を判定し、どのデータを端末器１３０６に送信すべきかを決める。具体的には、上記した優先順位を決めるのは、間引き判定部４１２で行う。
【００９８】
間引き判定部４１２には、ダウンロードの優先順位を各パラメータを定義した優先順位定義表（例えば道路の優先順位については図１７）をあらかじめ持たせておく。次に、間引き判定部４１２は、経路計算結果を受け取り、優先順位定義表と照らし合わせて、ダウンロードする優先順位を決定する。
【００９９】
なお、パラメータが複数ある場合に、具体的にどのパラメータを優先させるか、どのような組み合わせで行うかについては、その時の状況に応じて間引き判定部４１２で決定するものとする。
【０１００】
例えば、日立市から東京までの経路をダウンロードする場合は、サーバ１３０２は東京までの常磐自動車道のデータを先に用意する。そのデータ量が端末側の許容範囲を超えていなければ、東京までの国道６号のデータを用意する。さらに端末側のメモリに余裕があればその他の道路情報も用意する。その後、サーバ１３０２は端末器１３０６に道路情報を送信する。
【０１０１】
なお、同じ道路の道路データであれば、自車位置に近いほど、優先順位は高くする。例えば、同じ常磐自動車道であっても、日立市内のデータの優先順位が高くなり、日立市から遠ざかるほど優先順位は低くなる。
【０１０２】
目的地までの全経路を一度にダウンロードできない場合は、車が通過した場所の地図データを端末から消去してメモリの空き領域を作り、ダウンロードできなかったデータをダウンロードする。
【０１０３】
上述したダウンロードする地図データの優先順位の付け方について、他の例を説明する。
【０１０４】
本例では、自車位置周辺だけの詳細地図をダウンロードして、目的地までの地図はダウンロードしないものとする。その場合の優先順位は、必ずしも上記のように主要道路が高いとは限らず、ダウンロードする範囲に応じて、優先順位を動的に設定してもよい。
【０１０５】
例えば、上記と同じく日立市から東京までの経路をダウンロードする場合、サーバ１３０２は常磐自動車道の最寄りのインターチェンジまでの経路データを用意する。そのデータ量が端末のメモリ空き容量よりも小さければ、東京までの常磐自動車道データを用意し、さらにメモリ容量に余裕があれば国道６号のデータも用意する。
【０１０６】
データの用意が終わったところで、サーバ１３０２は端末器１３０６にデータを送信する。常磐自動車道データと国道６号データは、上記したように自車位置に近いところほど優先順位を高くする。あるいは、経路となる道路と主要道路をダウンロードさせることにしてもよい。すなわち、高速道路や国道などの主要道路の優先順位は、経路となる道路の次に高くする。
【０１０７】
図１４は、日立から東京までの経路の例である。この図を参照しながら、送信する道路情報の優先順位に付いてさらに述べる。尚、ここでは、会員ユーザが端末器１３０６を用いていると想定し、ベクトル地図データが送信される場合である。
【０１０８】
本図では始点１４０１から終点１４０２までの経路が経路１４０３で表されている。詳細は図示しないが、常磐自動車道が経路となった場合を想定している。サーバ１３０２は、経路計算を終えた後、経路が含まれる地図メッシュ１４０４〜１４１０から、送信すべき道路を選び出す。
【０１０９】
まず、経路だけを始点から終点まで送信しようとする場合、始点１４０１に近いメッシュ１４０４内にある経路を抜き出す。経路データの容量を調べ、端末器１３０６から送信されてきたメモリ容量よりも小さければ、メッシュ１４０５の経路を抜き出す。以下、端末器１３０６のメモリ容量を超えない範囲で、メッシュ１４１０までの経路を抜き出していく。抜き出した合計の容量が端末器１３０６のメモリ容量を超える前に処理を終了し、経路データを送信する。処理の終了のタイミングに関しては、例えば送信されてきたメモリ容量の８０％等をしきい値として設定してよい。
【０１１０】
メッシュ１４１０まで経路を抜き出し、端末器１３０６のメモリ容量に余裕があれば、メッシュ１４０４からメッシュ１４１０まで順に国道を抜き出していく。それでもまだメモリ容量に余裕があれば、その他の道路も抜き出していく。処理の終了のタイミングは上記のように、端末器１３０６のメモリ容量の８０％等としてよい。
【０１１１】
経路データを優先して抜き出す例を、図１５に示す。
【０１１２】
図１５（ａ）は、サーバ１３０２に格納してある地図データの例である。この地図データには、郵便局１５０１、警察署１５０２、県庁１５０３、学校１５０４が含まれている。
【０１１３】
サーバ１３０２が経路計算した結果、図１５（ｂ）の経路１５０５のようになったとする。このとき、端末器１３０６に送信するデータは、図１５（ｃ）に示すデータとなる。すなわち、郵便局１５０１、警察署１５０２、学校１５０４、経路１５０５である。県庁１５０３は、経路１５０５上に無いデータであるので、送信しない。
【０１１４】
また、上記のように経路データを最優先して抜き出していくのではなく、始点１４０１に近いところから抜き出していく方法もある。
【０１１５】
まず、メッシュ１４０１の経路データを抜き出した後、経路に近い道路のデータを抜き出す。例えば、経路に交差している道路データを抜き出す。また、交差点の名前等も抜き出しておくと、送信した後にユーザにとって都合がよい。高速道路など、交差点のない道路が経路である場合には、経路データだけが抜き出されることになるが、１本道を道なりに進めばよいので、経路データ以外がなくてもほとんど問題はない。
【０１１６】
端末器１３０６のメモリ容量に余裕があれば、次にメッシュ１４０２について同様の処理を実施する。そして、端末器１３０６のメモリ容量に余裕があればメッシュ１４０３以降についても同様に実施し、例えばメモリ容量の８０％を超えたら処理を終了し、端末器１３０６に送信する。
【０１１７】
出発前に端末器１３０６がデータをダウンロードするには、以上の処理でよいが、出発前にすべてのデータをダウンロードできるとは限らない。ダウンロードできなかったデータに関しては、経路途中でダウンロードしなければならない。その時には上記したように、車がそれまでに通ってきた経路のデータを端末器１３０６から消去して、新たなデータをサーバ１３０２から受信する必要がある。経路の途中にいるときは、その途中時点での自車位置を始点１４０１に見立てて、前述した処理を実施すればよい。
【０１１８】
また、サーバ１３０２は、端末器１３０６のメモリ容量だけでなく、端末器１３０６における他の種類の資源情報を利用して、地図データの提供方法を調整する構成としてもよい。例えば、端末器１３０６の資源情報として、上記したメモリ容量の他に、通信レート、ディスプレイの種類等を端末情報としてサーバ１３０２へ送り、サーバ１３０２側では、これらの資源情報を直接的あるいは間接的に利用して、地図データを送るタイミングを決定する。
【０１１９】
その一例として、端末器１３０６への送信時間を考慮して地図データを送る場合について説明する。すなわち、ある時間内に送信できるだけのデータを用意し、端末器１３０６に送信しようとするものである。
【０１２０】
例えば、通信レートが９６００ｂｐｓであり、データ受信までの時間を３０秒とすると、この時間内に送信できるデータ量は３６KBである。そこで、３６KB分だけの地図データを用意し、端末器１３０６に送信する。データを用意する際は、上記の優先順位にしたがうものとする。
【０１２１】
一方、端末器１３０６は、地図が必要になる少なくとも３０秒前にサーバ１３０２に地図を要求する。これについては、自車の速さと通信レートから、地図が必要になる地点まで何メートルの地点で要求するかを計算すればよい。
【０１２２】
例えば、降りるインターチェンジに差し掛かるときに地図を受信し終えたい場合を考える。当該インターチェンジに差し掛かるまでの時間を自車速度から計算すると同時に、端末器１３０６のメモリ空き容量を調べる。
【０１２３】
また、通信レートがわかっていれば、自車速度、メモリ容量、通信レートの３つのパラメータから地図要求のタイミングを計算できる。例えば自車速度１００ｋｍ／ｈ、メモリ空き容量８０KB、通信レート９６００ｂｐｓとすると、８０KBのデータを受信する時間は約６６．７秒であるから、インターチェンジの１．８５ｋｍ手前でデータ受信を開始すればよい。実際はメモリ空き容量のすべてを使う必要はなく、受信するデータ量は８０KBより小さくてもよいので、この距離はもう少し短くてもよい。
【０１２４】
以上では、端末器１３０６は必要に応じてサーバ１３０２に接続する場合を想定していた。接続時間に応じて通信料金が課されると想定すれば、必要に応じてサーバ１３０２に接続する方が通信料金は安くなる。しかし、通信量に応じて通信料金が課されると想定すれば、必ずしも接続を切る必要がないので、上記と異なるサービスが可能である。
【０１２５】
すなわち、上記では端末器１３０６が経路情報をダウンロードし、ダウンロード地点の判定も端末器１３０６で実施していた。しかし、経路情報、ダウンロード地点をサーバ１３０２に残しておき、端末器１３０６から、自車位置情報、車速、端末情報を一定時間間隔でサーバ１３０２に送信し、サーバ１３０２側で地図をダウンロードするかどうかを判定する構成としてもよい。または、一定時間間隔ではなく、一定距離ごとに現在地自車位置情報、車速、端末情報をサーバ１３０２に送信する構成としてもよい。あるいはサーバ１３０２側で、予め定めた条件に基づいて地図データをダウンロードする位置を適宜決定する構成としてもよい。
【０１２６】
このようにサーバ１３０２側でダウンロードするタイミングを調整する構成によれば、車が経路を外れた場合にサーバ１３０２が端末器１３０６に対して警告を出したり、トンネル等の安定した通信が不可能あるいは困難な状況が予想される場所でのダウンロードを避けることができるため、より効率的で信頼性の高い情報提供サービスを実現することができる。
【０１２７】
なお、上記各実施形態では説明を簡単にするために、１つのサーバ１３０２に対して１つの端末器１３０６がある場合について説明したが、本発明はこれに限定されるものではなく、１つのサーバ１３０２が複数の端末器（複数の自動車）を個別に管理しつつ、要求された情報の提供を行う構成としてもよい。例えば、図１３にも示すように、サーバ１３０２をインターネット上のサーバで構成し、複数の端末器に対応できる構成としてもよい。
【０１２８】
また、上記各実施形態では端末器からサーバに電話をかけて地図のダウンロードを行う構成について説明したが、その代わりに、サーバから端末器に電話をかけて地図を送信する構成としてもよい。例えば、サーバで経路計算をした際、地図表示位置（地図ダウンロード位置）だけでなく、各地図表示位置の通過予想時刻も計算する。さらに、サーバはその通過予想時刻に近づいたら、端末器に電話をかけ、その時刻に通過する地図表示位置周辺の地図データを送信する。
【０１２９】
【発明の効果】
本発明の情報提供システムによれば、常に最新の道路情報が得られ、かつ、ユーザの金銭的負担を小さくするために、ネットワーク上のサーバから、必要なときだけ地図をダウンロードできる手段を提供することができる。
【０１３０】
また、本発明の情報提供システムによれば、地図データなどの情報の提供を受ける端末器のメモリ資源が少ないときでも、ナビゲーションにとって必要最小限の地図データの提供サービスを受けることが可能となる。
【図面の簡単な説明】
【図１】本発明による端末器の構成例を示すブロック図である。
【図２】本発明による端末器とサーバの処理の一例を示す流れ図である。
【図３】本発明による処理で生成される表示画面例を示す説明図である。
【図４】本発明によるサーバの構成例を示すブロック図である。
【図５】図５（ａ）：端末器からサーバに送信するためのプロトコルの一例を示す説明図である。
図５（ｂ）：端末器からサーバに送信するためのプロトコルの一例を示す説明図である。
【図６】ユーザIDを入力するための画面例を示す説明図である。
【図７】目的地を入力するための画面例を示す説明図である。
【図８】会員に対する課金情報を示す説明図である。
【図９】ベクトルデータまたはイメージデータを送信するまでの処理例を示すフローチャートである。
【図１０】本発明による端末器とサーバの処理の一例であって、地図データを一括して送信する場合のフローチャートである。
【図１１】主要部分の地図表示例を示す説明図である。
【図１２】会員情報ＤＢに格納されている情報の一例を示す説明図である。
【図１３】本発明による情報提供システムの全体構成例を示す説明図である。
【図１４】地図メッシュと経路情報の例を示す説明図である。
【図１５】図１５（ａ）：サーバに格納してある地図データの例を示す説明図である。
図１５（ｂ）：地図データと経路情報の表示例を示す説明図である。
図１５（ｃ）：端末器へ送信するデータの例を示す説明図である。
【図１６】地図ダウンロード前の画面例を示す説明図である。
【図１７】優先順位の定義表の一例を示す説明図である。
【符号の説明】
１０１メモリ
１０２ GPS
１０３位置判定装置
１０４入力装置
１０５処理装置
１０６表示制御装置
１０７地図表示判定装置
１０８外部記憶装置
１０９通信装置
１１０音声出力装置。

Claims

車両に搭載され目的地までの経路誘導を行う端末器と、該端末器へ経路誘導に用いる地図データを少なくとも含む情報を提供するサーバ装置とを備える情報提供システムにおいて、
前記サーバ装置および前記端末器のうちいずれか一方に、該端末器のその時点での資源情報を取得して、該資源情報に応じて前記地図データを少なくとも含む情報の情報量を計算する手段を有し、
前記サーバ装置は、前記算出された情報量に応じて、前記端末器に送信すべき情報を生成し、
前記サーバ装置は、前記端末器が送信した現在位置と目的地から、目的地までの誘導経路に関する経路情報を生成する手段と、前記経路情報について前記端末器から前記サーバ装置へ取得を要求する地点を前記誘導経路上で決定する情報提供タイミング決定手段と、を備え、
前記経路情報を生成する手段では、前記経路情報を構成する地図データに含まれるべき各地図要素データについて優先順位を付与し、当該優先順位にしたがって、各時点で送信すべき経路情報を生成すること
を特徴とする情報提供システム。
請求項１に記載の情報提供システムにおいて、
前記優先順位では、誘導経路として用いる道路を最高順位とすること
を特徴とする情報提供システム。
請求項２に記載の情報提供システムにおいて、
前記優先順位では、主要道路、および、前記誘導経路として用いる道路の周辺に存在する道路のうちいずれかを、第２の優先順位とすること
を特徴とする情報提供システム。
請求項３に記載の情報提供システムにおいて、
前記主要道路とは、高速道路および国道のうちいずれかであること
を特徴とする情報提供システム。
車両に搭載され目的地までの経路誘導を行う端末器と、該端末器へ経路誘導に用いる地図データを少なくとも含む情報を提供するサーバ装置とを備える情報提供システムにおいて、
前記サーバ装置は、
前記車両の経路を計算する経路計算手段と、
前記計算された経路において、地図データを送信すべき位置を決定する地図データ送信位置決定手段と、
前記決定された地図データ送信位置を、自車が通過する時刻を予想する通過時刻予想手段とを備え、
前記情報提供タイミング決定手段は、前記サーバ装置に配置されるものであって、前記予想された通過時刻に対応して定められた時刻に、地図データを送信するよう前記送信タイミングを決定すること
を特徴とする情報提供システム。