トップ :: G 物理学 :: G01 測定;試験




【発明の名称】 情報提供システム
【発明者】 【氏名】葛貫 壮四郎

【氏名】松尾 茂

【氏名】待井 君吉

【氏名】新 吉高

【氏名】安部 圭子

【氏名】横田 登志美
【要約】 【課題】端末側から目的地の地図情報を通信コストが安く、検索時間が短く、かつ、地名の入力がしやすい地図情報提供システムを提供する。

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