JP3596805B2

JP3596805B2 - 情報端末装置および経路案内方法

Info

Publication number: JP3596805B2
Application number: JP21579799A
Authority: JP
Inventors: 康博井原; 祥弘鈴木; 信之中野; 久哉福田
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 1999-07-29
Filing date: 1999-07-29
Publication date: 2004-12-02
Anticipated expiration: 2019-07-29
Also published as: US6336073B1; JP2001041759A

Description

【０００１】
【発明の属する技術分野】
本発明は、情報端末装置に関し、より特定的には、現在地や目的地、特定の地点などの周辺の地図を表示し、観光情報やレストラン・ホテルなどの地点情報（いわゆるＰＯＩ情報）を情報サーバーから検索し、そこまでの道のりや距離、交通状況、所用時間などの情報を使用者に提供するものであり、さらに通信機能により膨大かつ最新の情報を利用することが可能な情報端末装置に関するものである。
【０００２】
【従来の技術】
従来の情報端末装置の一例が、「特開平９−２２９６９４号」公報に開示されている。図１８には、情報端末装置の一例としてのナビゲーションシステム１８０１と、補充データ提供システム１８０２とが通信可能に接続された、ナビゲーションデータ補充システム１８００が示されている。
【０００３】
ナビゲーションシステム１８０１において、記憶媒体１８０３としては、ＣＤ−ＲＯＭ等が用いられる。記憶媒体１８０３は、道路地図データおよび観光情報を記憶する。入力検出部１８０４により検出されたユーザーの操作は、制御部１８０７で認識される。ユーザー操作は、表示部１８０５上に提示されたメニューの選択などである。この選択結果を受けて、制御部１８０７は、記憶媒体１８０３にアクセスして、道路地図データおよび観光情報を取得し、表示部１８０５に表示する。
【０００４】
また、ナビゲーションシステム１８０１が、通信を介して、補充データ提供システム１８０２から補充データを取得し表示する場合を説明する。この場合、まず、制御部１８０７は、表示内容記憶部１８０６に格納された表示中の画面内容を基に、要求すべき補充データを確定する。送信部１８０９は、補充データ提供システム１８０２に対して、確定した補充データを要求するための制御データとして、データ要求を送信する。データ要求を送信した後、補充データ提供システム１８０２が送信した補充データを受信部１８１１が受信し、補充データ格納部１８１０が記憶する。次に、画像生成部１８０８において、あらかじめ用意された雛形に補充データを埋め込み、表示画面を作成する。最後に、表示画面が表示部１８０５によって表示される。
【０００５】
一方、補充データ提供システム１８０２は、ナビゲーションシステム１８０１からのデータ要求を受信部１８１２で取得して、データ検索部１８１５で検索する。検索結果はデータ変換部１８１２で通信に適した形式にデータ変換され、送信部１８１４によりナビゲーションシステム１８０１に送られる。また、補充データ提供システム１８０２はネットワーク接続部１８１７により、外部ネットワーク１８１９に接続して得た情報をデータ作成部１８１８に送り、データ作成部１８１８ではサービスデータとして必要なデータを作成する。作成されたデータはデータ格納部１８１６により格納され、データ検索部１８１５を介して補充データとしてナビゲーションシステム１８０１に提供される。
このような構成により、ナビゲーションシステム１８０１は最新かつ詳細な情報を補充データ提供システム１８０２から取得していた。
【０００６】
また、従来の情報端末装置の他の例としての、通信機能付きカーナビゲーション装置が、「特開平１０−１０３９７７号」公報に開示されている。この公報のカーナビゲーション装置は、現在地に近いＩＳＰ（インターネットサービスプロバイダ）のアクセスポイントを、当該カーナビゲーション装置の内部に記憶されたデータから検索する。カーナビゲーション装置は、現在地周辺の施設などの詳細情報を、当該施設のホームページ（ウェブサイト）を表示することで利用者に提供するものである。より具体的には、この公報に開示された発明は、パソコン上では一般的なＷＷＷ（ＷｏｒｌｄＷｉｄｅＷｅｂ）ブラウザ機能がカーナビゲーション装置に搭載されたものである。かかるカーナビゲーション装置には、ホームページのＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）と、その所有者の所在地とが対応づけて記憶される。このようにすることで、地図上の任意の周辺詳細情報をＷＷＷブラウザで表示することができる。これによって、カーナビゲーションシステムを利用して最新かつ詳細な情報を取得できるようにしていた。
【０００７】
【発明が解決しようとする課題】
以上の各公報に開示された情報端末装置は、通信機能によって最新かつ詳細な情報を取得することができる。しかしながら、各情報端末装置には、以下に述べるような問題点がある。なお、「特開平９−２２９６９４号」公報では、ナビゲーションシステム１８０１が情報端末装置に相当し、「特開平１０−１０３９７７号」公報ではカーナビゲーション装置が情報端末装置に相当する。
【０００８】
まず、「特開平９−２２９６９４号」公報のナビゲーションデータ補充システム１８００では、情報端末装置（ナビゲーションシステム１８０１）と情報サーバー（補充データ提供システム１８０２）とが独自の通信プロトコルで接続されている点が問題点であった。具体的には、補充データ提供システム１８０２は、その名の通り、あらかじめ決められた内容の情報を、情報端末装置に補充し、更新するものである。特に、レストラン情報の表示例では、情報端末装置から情報画面番号を指定して補充データの送信を要求するなど、情報端末装置と情報サーバーが深く連携しすぎている。
従って、新しい情報表示機能を付加して新しいサービスを提供する場合には、情報端末装置および情報サーバーの両者を更新する必要がある。また、情報端末装置を発売する毎に、対応する情報サーバーを設置する必要が発生し、さらには、古い情報端末装置へのサービスも簡単には打ち切れないため、事業コストが嵩むという問題点も生じてしまう。
【０００９】
一方、「特開平１０−１０３９７７号」公報の情報端末装置は、標準的な通信プロトコルを実装し、さらにＷＷＷブラウザを搭載することで、世界中の膨大な情報にアクセスすることができる。しかし、情報端末装置は、単にＷＷＷ上のホームページを表示し、当該ホームページの所有者の位置を地図上に対応させるだけである。したがって、道案内等のナビゲーション機能に適した形式で情報を使用者に提供できないという問題点があった。
【００１０】
それ故に、本発明の目的は、標準的な通信プロトコルにより、ナビゲーション機能に適した形式で、各種情報の提供を受けることができる情報端末装置を提供することである。
【００１１】
【課題を解決するための手段および発明の効果】
第１の発明は、所定のプロトコルで通信が行われるネットワーク内の複数の情報サービスセンタにアクセス可能であって、かつ移動可能な情報端末装置であって、各情報サービスセンタは、提供可能な情報の属性および内容を表すタグ形式で、当該情報を通信プロトコルに従って送信可能に構成されており、出発地から目的地までの経路を示す経路情報、および当該経路の案内するために、各重要地点を簡素に特定するＩＤ情報を含む案内情報を取得する第１の取得部と、第１の取得部が取得した経路情報および／または案内情報に基づく第１の地図データを用いて、出発地から目的地までの経路を案内する経路案内部と、必要に応じて、前記ＩＤ情報を用いて、各情報サービスセンタに、地点情報の検索を要求する要求部と、要求部による要求に応じて、経路案内部が案内する経路上の各重要地点を詳細に示すタグ形式の地点情報を、各情報サービスセンタから取得する第２の取得部とを備える。ここで、経路案内部は、第２の取得部が取得した地点情報を、第１の地図データと同時に提示して、経路上の各重要地点を明確にする。
【００１２】
従来技術で説明したように、情報端末装置と各情報サービスセンタとが独自の通信プロトコルによりデータ通信を行うと、情報端末装置は、特定の事業者からしか情報提供を受けることができない。
そこで、第１の発明によれば、情報端末装置と各情報サービスセンタとは、通信ネットワークの標準的な通信プロトコルに従ってデータ通信するので、本情報端末装置は、通信ネットワーク内の各情報サービスセンタと通信できるので、ユーザの情報選択の幅が広がる。また、情報端末装置と各情報サービスセンタとがやりとりする情報の形式は統一されているので、タグ形式により情報を提供するという条件さえ満たせば、各情報サービスセンタは、自由な情報提供サービスを展開することができる。これによって、例えば、新しいサービスを情報端末装置に自由に提供する場合であっても、情報端末装置に新機能を追加する必要が無くなるので、事業コストが嵩まない。
さらに、タグ形式を採用することにより、地図データと地点情報との親和性を容易に向上することができる。これによって、複数の情報を同時にユーザに提示できるようになるため、ユーザの好みに応じた柔軟な経路案内機能を実現できる。
また、第１の発明によれば、要求部は、必要に応じて地点情報を取得する。そのため、処理能力が高い情報端末装置は地点情報を取得することができ、処理能力が低い情報端末装置は地点情報を取得しない等、地点情報の取得に関し、柔軟な情報端末装置を提供することができる。
【００１３】
第２の発明は第１の発明に従属しており、ＩＤ情報は、電話番号、住所、郵便番号のいずれかであって、各情報サービスセンタは、キーワードとして受け取った電話番号、住所、郵便番号を、経度座標および緯度座標に変換する。第２の取得部は、各重要な地点の経度座標および緯度座標を含む地点情報を取得する。
【００１４】
第３の発明は第１の発明に従属しており、ＩＤ情報は、経度座標および緯度座標の組み合わせであって、各情報サービスセンタは、キーワードとして受け取った経度座標および緯度座標の組み合わせを、電話番号、住所および／または郵便番号に変換する。ここで、第２の取得部は、各重要な地点の電話番号、住所および／または郵便番号を含む地点情報を取得する。
【００１５】
第２および第３の発明によれば、情報サービスセンタは、情報端末装置からの要求に応じて、各種の変換機能を当該情報端末装置に提供することができるので、より多様な情報サービスを提供することができる。
【００１６】
第４の発明は第１の発明に従属しており、地点情報は、第１の地図データとは異なる縮尺を有する第２の地図データを含んでおり、経路案内部は、第１の地図データと、第２の取得部が取得した第２の地図データとを同時に提示する。
第５の発明は第４の発明に従属しており、第２の地図データは、重要地点周辺を拡大した地図データである。
第６の発明は第４の発明に従属しており、第２の地図データは、重要地点周辺を３次元で表す地図データである。
第７の発明は第１の発明に従属しており、地点情報は、重要な地点である建物または地下街を詳細に示す第２の地図データであって、経路案内部は、第１の地図データと、第２の取得部が取得した第２の地図データとを同時に提示する。
【００１７】
第８の発明は第４の発明に従属しており、経路案内部は、第２の取得部が複数の第２の地図データを受け取った場合に、データサイズが最大の第２の地図データを、第１の地図データと同時に提示する。
第９の発明は第４の発明に従属しており、経路案内部は、第２の取得部が複数の第２の地図データを受け取った場合に、データサイズが最小の第２の地図データを、第１の地図データと同時に提示する。
第１０の発明は第４の発明に従属しており、経路案内部は、第２の取得部が複数の第２の地図データを受け取った場合に、最も新しい第２の地図データを、第１の地図データと同時に提示する。
【００１８】
第４〜第１０の発明によれば、経路案内部は、各発明で述べた優先度に基づいて、第２の地図データを第１の地図データ同時に表示することができるので、よりユーザの好みに合わせた形で分かりやすく経路案内することができる。
【００１９】
第１１の発明は第１の発明に従属しており、ユーザの関心が高い地点に関連するキーワードに基づいて、複数の情報サービスセンタに、当該関心が高い地点に関連する情報の検索を要求する要求部と、要求部による要求の後に、複数の情報サービスセンタの検索結果を取得する第３の取得部と、第３の取得部が取得した検索結果をユーザに提示する提示部とを含む。ここで、経路案内部は、提示部が提示した検索結果のいずれかの地点を、目的地として経路を案内する。
【００２０】
第１１の発明によれば、情報端末装置は、各情報サービスセンタからの検索結果により、目的地の候補地を提示することができるので、ユーザは、多くの候補地から目的地を選択することができる。
【００２１】
第１２の発明は第１１の発明に従属しており、提示部は、第３の取得部が複数の検索結果を受け取った場合に、データサイズが大きい検索結果を優先的に提示する。
第１３の発明は第１１の発明に従属しており、提示部は、第３の取得部が複数の検索結果を受け取った場合に、データサイズが小さい検索結果を優先的に提示する。
第１４の発明は第１１の発明に従属しており、提示部は、第３の取得部が複数の検索結果を受け取った場合に、更新日時が新しい検索結果を優先的に提示する。
【００２２】
第１２〜第１４の発明によれば、情報端末装置は、各発明で述べた優先度に従って、目的地の候補地をユーザに提示する。これによって、ユーザは、自分の好みに応じて、多くの候補地から目的地を簡単に選択することができる。
【００２３】
第１５の発明は第１の発明に従属しており、地点情報は、重要地点を簡素に特定する第１の情報と、当該重要地点を詳細に示す特定する第２の情報とを含んでおり、第１の情報は、重要地点の名称および電話番号のタグを少なくとも含む。
【００２４】
第１５の発明によれば、地点情報には、重要地点を簡素に特定する第１の情報が少なくとも含まれる。したがって、地点情報の情報形式は分離しやすいものになる。これによって、処理能力が乏しい情報端末装置は、第１の情報のみをユーザに提示し、それが十分な情報端末装置は、地点情報に含まれる他の情報をユーザに提示することができる。
【００２５】
第１６の発明は第１の発明に従属しており、経路情報は、進行すべき道路の名称、分岐点となる交差点の名称、分岐点間の距離および分岐点での曲折方向のタグを少なくとも含む。
第１６の発明によれば、経路情報には、上述のタグにより経路を簡素に特定することができる。したがって、経路情報の情報形式は分離しやすいものになる。これによって、処理能力が乏しい情報端末装置は、簡素な経路情報に基づいて経路案内することができ、それが十分な情報端末装置は、経路情報に含まれる他の情報に基づいて経路案内することができるようになる。
【００２６】
第１７の発明は第１の発明に従属しており、全国の交差点には、一意な交差点番号が予め付されており、経路情報は、交差点番号を特定するタグを少なくとも含む。
第１７の発明によれば、交差点番号を特定するタグを含むことにより、より簡単な形式で、経路上の交差点を特定することができる。
【００２７】
第１８の発明は第１６の発明に従属しており、案内情報は、経路情報にタグ形式で記述された分岐点、ならびに当該分岐点の目印となる地点の名称および電話番号の情報を少なくとも含む。
第１８の発明によれば、案内情報は、分岐点の目印となる地点の名称および電話番号を少なくとも含むので、案内情報の情報形式は分離しやすいものになる。
【００２８】
第１９の発明は、所定のプロトコルで通信が行われるネットワーク内の複数の情報サービスセンタにアクセス可能であって、かつ移動可能な情報端末装置に用いられる経路案内方法であって、各情報サービスセンタは、提供可能な情報の属性および内容を表すタグ形式で、当該情報を通信プロトコルに従って送信可能に構成されており、出発地から目的地までの経路を示す経路情報、および当該経路の案内するために、各重要地点を簡素に特定するＩＤ情報を含む案内情報を取得する第１のステップと、第１のステップで取得された経路情報および／または案内情報に基づく第１の地図データを用いて、出発地から目的地までの経路を案内する第２のステップと、必要に応じて、ＩＤ情報を用いて、各情報センタに、地点情報の検索を要求する第３のステップと、第３のステップによる要求に応じて、第２のステップで案内される経路上の各重要地点を詳細に示すタグ形式の地点情報を、各情報サービスセンタから取得する第４のステップとを備える。ここで、第２のステップは、第４のステップで取得された地点情報を、第１の地図データと同時に提示して、経路上の各重要地点を明確にする。
【００２９】
第１９の発明によれば、第１の発明と同様に、情報提供サービスの事業コストが嵩まず、ユーザの好みに応じた柔軟な経路案内機能を実現できる。
【００３０】
【発明の実施の形態】
まず、本実施形態で使用される文言を定義する。「ＰＯＩ」とは、ＰｏｉｎｔＯｆＩｎｔｅｒｅｓｔの頭字語であって、以下に詳説する情報端末装置１００のユーザが関心（興味）を持っている地点（観光地、ホテル、レストラン、会社等）を意味する。また、「ＰＯＩ情報」とは、ＰＯＩに関連する情報を意味する。
【００３１】
次に、本発明の各実施形態に係る情報端末装置１００の通信環境について、図１を参照して説明する。情報端末装置１００は、ＩＳＰ（ＩｎｔｅｒｎｅｔＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ）２００を通じて、インターネット４００内の複数の情報サービスセンタ３１０〜３７０にアクセスすることができる。
【００３２】
情報端末装置１００は、車載またはユーザの携帯により、移動可能に構成される。ＩＳＰ２００は、インターネット４００への接続サービスを加入者（ユーザ）に提供する。ＩＳＰ２００の典型的なサービスは、電子メールの送受信やホームページの閲覧である。また、ＩＳＰ２００の事業者は、アクセスポイント２１０を所定の場所に設置し、管理する。
加入者（ユーザ）は、自身の情報端末装置１００を操作して、アクセスポイント２１０を通じて、ＩＳＰ２００にアクセスする。ＩＳＰ２００へのアクセスには、通常、携帯電話またはＰＨＳ（ＰｅｒｓｏｎａｌＨａｎｄｙｐｈｏｎｅＳｙｓｔｅｍ）等が用いられる。アクセスが成功すると、情報端末装置１００は、上述のサービスをＩＳＰ２００から受けることができる。ところで、情報端末装置１００とＩＳＰ２００との通信プロトコルは、一般的に、ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−ＰｏｉｎｔＰｒｏｔｏｃｏｌ）である。ＰＰＰによれば、インターネット標準のＴＣＰ／ＩＰパケットのやりとりが可能になる。そのため、情報端末装置１００は、ＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）を指定すれば、ＩＳＰ２００を経由して、インターネット４００内の各情報サービスセンタ３１０〜３７０にアクセスすることができる。
【００３３】
各情報サービスセンタ３１０〜３７０は、情報端末装置１００の要求に応答して、各種情報の提供を行う。本実施形態では、説明を具体化するために、各情報サービスセンタ３１０〜３７０は、以下の情報を提供すると仮定する。情報サービスセンタ３１０および３２０は、情報端末装置１００から受け取ったキーワードを基に情報を検索して、その検索結果を情報端末装置１００に送信する。また、情報サービスセンタ３３０が提供するのは、移動可能な情報端末装置１００を道案内するために必要な経路情報および案内情報である。また、情報サービスセンタ３４０が提供するのは、ＰＯＩ周辺を詳細に表す平面的な地図データである。情報サービスセンタ３５０および３６０が提供するのは、ＰＯＩ情報である。情報サービスセンタ３７０が提供するのは、ＰＯＩ周辺を詳細に示す３次元の地図データである。
ここで注意を要するのは、提供される各種情報またはデータの形式は、互いに同じタグ形式である。また、通信プロトコルがＰＰＰであるから、タグ形式の各種情報またはデータは、各情報サービスセンタ３１０〜３７０により、ＴＣＰ／ＩＰパケットに収容される。かかるＴＣＰ／ＩＰパケットにより、各種情報（またはデータ）が、情報端末装置１００に送信される。
【００３４】
各情報サービスセンタ３１０〜３７０と情報端末装置１００とが通信を行っている最中、ＩＳＰ２００は、ＴＣＰ／ＩＰパケットを中継しているだけである。つまり、ＩＳＰ２００は、ＰＰＰに従う処理以外に、特別な処理を行わない。そのため、情報端末装置１００のユーザは、各情報サービスセンタ３１０〜３７０に直接接続しているように感じる。したがって、情報端末装置１００のユーザは、ＵＲＬを切り替えるだけで、情報サービスセンタ３１０等から、情報またはデータの提供を受けることができる状態になる。この時必要となるＵＲＬは、情報端末装置１００が予め記憶している場合もあれば、ＩＳＰ２００が情報端末装置１００に提供する場合もある。しかし、キーワード検索によりユーザにＵＲＬを教えるサーチエンジンを利用して、各情報サービスセンタ３１０〜３７０のＵＲＬを得ることがより一般的である。
【００３５】
次に、図２を参照して、情報端末装置１００の詳細なブロック構成を説明する。図２において、情報端末装置１００は、入力部１０１と、現在地検出部１０２と、記憶部１０３と、演算処理部１０４と、解析部１０５と、情報受信部１０６と、提示情報作成部１０７と、情報提示部１０８と、検索要求部１０９とを備える。
入力部１０１は、ユーザの操作を検出して、演算処理部１０４に通知する。現在地検出部１０２は、移動可能な情報端末装置１００の現在地を検出して、演算処理部１０４に通知する。現在地の検出方法は、ＧＰＳ（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ）、自律航法、ＰＨＳ、セルラー電話およびＧＰＳの併用など、どのような方法でも構わない。記憶部１０３は、地図データ等、ナビゲーションに必要なデータを記憶する。さらに、必要に応じて、記憶部１０３はＰＯＩ情報も記憶する。
【００３６】
情報受信部１０６は、ＩＳＰ２００を通じて、各情報サービスセンタ３１０〜３７０から送信されてくる情報（またはデータ）を取得する。ＰＰＰの場合、情報端末装置１００と各情報サービスセンタ３１０等とは双方向通信する。しかし、情報受信部１０６は、放送系のメディア（例えば、ＦＭ多重放送、衛星ディジタル放送、または地上波ディジタル放送）から、各情報サービスセンタ３１０等から情報（またはデータ）を得ることもできる。放送系の場合、基本的に、ダウンリンク（各情報サービスセンタ３１０等から情報端末装置１００への通信経路）しか無い。そのため、各種情報がチャンネル毎に放送され、さらに各チャンネル毎にさまざまな情報が繰り返し放送されていれば、情報端末装置１００は、チャンネル上に繰り返し放送される情報の中から、必要な情報を選択受信すれば良い。また、低速度の通信経路（アップリンク）を通じて情報を要求して、応答を高速度の放送（ダウンリンク）で得るようなシステムを利用しても構わない。以上のようにして取得された情報（またはデータ）は、解析部１０５に送られる。
【００３７】
解析部１０５は、情報受信部１０６から受け取った情報に対して所定の解析処理を実行する。その解析結果は演算処理部１０４に渡される。なお、解析処理については、後述するので、ここではその説明を省略する。
演算処理部１０４は、入力部１０１が検出したユーザの操作、現在地検出部１０２が検出した現在地、記憶部１０３に記憶された情報（またはデータ）、および解析部１０５の解析結果に基づいて、本願特有の道案内に必要な処理を行う。演算処理部１０４の処理結果は提示情報作成部１０７に出力される。提示情報作成部１０７は、受け取った処理結果を、情報提示部１０８の情報提示に適した形式に整える。情報提示部１０８は、受け取った情報をユーザに提示する。情報の提示は、主として、ディスプレイへの表示と、スピーカからの音声出力とを併用して行われる。もちろん、情報の提示に、ディスプレイ表示および音声出力のいずれか一方のみを利用することも可能である。
また、情報要求部１０９は、演算処理部１０４が道案内処理を行う際に必要な情報を、各情報サービスセンタ３１０〜３７０に要求する。
【００３８】
次に、本情報端末装置１００に特有な経路案内処理を、図３〜図６のフローチャートを参照して説明する。以下には、情報端末装置１００のユーザが、目的地周辺まで自動車で移動して、最終的には徒歩で目的地に到達する場面を想定する。また、以下の説明を簡素化するため、周知事項であるＰＰＰに基づく処理の説明と、ＩＳＰ２００およびアクセスポイント２１０の動作説明とを省略することを注釈しておく。
【００３９】
図３において、情報端末装置１００は、まず、道案内に必要な目的地を選択する（ステップＳ２０１）。ステップＳ２０１の詳細な処理手順は、図４に示される。まず、入力部１０１には、ユーザがこれから向かう目的地（つまりＰＯＩ）のキーワードが入力される（ステップＳ３０１）。演算処理部１０４は、入力部１０１から得たキーワードに合致するＰＯＩ情報を、記憶部１０３の中から探す。さらに、演算処理部１０４は、情報要求部１０９を通じて、情報サービスセンタ３１０にＰＯＩの検索キーワードを送信する。これによって、情報要求部１０９は、情報サービスセンタ３１０にＰＯＩ情報の検索を要求する（ステップＳ３０２）。なお、演算処理部１０４は、複数の情報サービスセンタ３１０および３２０に検索キーワードを送ってもよい。さらに、情報サービスセンタ３１０に送られた検索キーワードが、他の情報サービスセンタ３２０に送られても良い。情報サービスセンタ３１０および／または３２０は、キーワードを基にＰＯＩ情報を検索して、その検索結果を情報端末装置１００に送信する。
【００４０】
情報サービスセンタ３１０等の検索結果は、情報受信部１０６により受信された後（ステップＳ３０３）、解析部１０５に渡される。現時点では、受け取ったものがどのような情報であるか分からないので、解析部１０５は、当該受け取った検索結果の属性および内容を解析して、演算処理部１０４に渡す。これによって、演算処理部１０４は、情報サービスセンタ３１０等からの検索結果を取得する。また、上述したように、演算処理部１０４は、同じキーワードで記憶部１０３内の情報を検索している場合があるので、当該記憶部１０３からも検索結果を取得している場合がある。
【００４１】
ここで、図７は、情報サービスセンタ３１０等からの検索結果の情報形式を示している。図７の情報形式は、説明を簡略化しているが、基本的にはＳＧＭＬ（ＳｔａｎｄａｒｄＧｅｎｅｒａｌｉｚｅｄＭａｒｋｕｐＬａｎｇｕａｇｅ）やＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）と同じである。また、記憶部１０３からの検索結果は、タグ形式を用いても良いし、タグ解析が終了した後の形式を用いても良い。図２の構成では、タグ解析終了後の形式を用いた場合を示している。
【００４２】
まず、図７（ａ）は、「ＩＤ型」と呼ばれる情報形式の定義している。図７（ａ）において、ｄｅｆ［ＩＤ］はＩＤ型の定義を示す。＜ＩＤｎａｍｅ＞および＜／ＩＤｎａｍｅ＞は、ＰＯＩ情報の名称を特定するためのタグである。＜ｓｉｚｅ＞および＜／ｓｉｚｅ＞は、ＰＯＩ情報のデータサイズを特定するためのタグである。＜ｕｐｄａｔｅ＞および＜／ｕｐｄａｔｅ＞は、ＰＯＩ情報の更新日を特定するタグである。
タグは、上記から明らかなように、特定の文字列を＜＞または＜／＞で囲んだものである。＜＞は開始タグを示し、＜／＞は終了タグを示す。開始タグと終了タグとの間には、データとなる文字列が記述される。図７（ａ）のＩＤ型は、具体的には以下のようになる。
【００４３】
ｄｅｆ［ＩＤ］
＜ＩＤｎａｍｅ＞○○商事＜／ＩＤｎａｍｅ＞
＜ｓｉｚｅ＞２０６バイト＜／ｓｉｚｅ＞
＜ｕｐｄａｔｅ＞１９９９年１月２８日＜／ｕｐｄａｔｅ＞
【００４４】
上記ＩＤ型の例によれば、ＰＯＩの名称は、＜ＩＤｎａｍｅ＞および＜／ＩＤｎａｍｅ＞のタグの間に記載された○○商事である。○○商事のＰＯＩ情報のデータサイズは２０６バイトである。○○商事のＰＯＩ情報の更新日は１９９９年１月２８日である。
【００４５】
また、図７（ｂ）は、本実施形態の１つの特徴である、ＰＯＩ情報用に特化した「ＰＯＩ−ＩＤ型」を定義している。ＰＯＩ−ＩＤ型は、図７（ａ）のＩＤ型の一種であるが、図７（ｂ）を参照すると、電話番号のタグを含む点で相違することが分かる。より詳しく説明すると、図７（ｂ）において、ｄｅｆ［ＰＯＩ−ＩＤ］はＰＯＩ−ＩＤ型の定義を示す。＜ｐｈｏｎｅ＞および＜／ｐｈｏｎｅ＞は、ＰＯＩの電話番号を特定するタグである。なお、＜ＩＤｎａｍｅ＞および＜／ＩＤｎａｍｅ＞、＜ｓｉｚｅ＞および＜／ｓｉｚｅ＞、ならびに＜ｕｐｄａｔｅ＞および＜／ｕｐｄａｔｅ＞は、上述した通りである。図７（ｂ）のＰＯＩ−ＩＤ型は、具体的には以下のようになる。
【００４６】
ｄｅｆ［ＰＯＩ−ＩＤ］
＜ＩＤｎａｍｅ＞○○商事＜／ＩＤｎａｍｅ＞
＜ｓｉｚｅ＞２０６バイト＜／ｓｉｚｅ＞
＜ｕｐｄａｔｅ＞１９９９年１月２８日＜／ｕｐｄａｔｅ＞
＜ｐｈｏｎｅ＞０３−３３３３−００００＜／ｐｈｏｎｅ＞
【００４７】
上記ＰＯＩ−ＩＤ型の例によれば、ＰＯＩの電話番号は、＜ｐｈｏｎｅ＞および＜／ｐｈｏｎｅ＞のタグの間に記載された０３−３３３３−００００であることが分かる。
【００４８】
また、図７（ｃ）は、「ＰＯＳ型」（Ｐｏｓｉｔｉｏｎ型）と呼ばれる情報形式の定義している。ＰＯＳ型は、ＰＯＩに関連する位置（典型的には所在地）の座標情報を特定するための情報形式である。図７（ｃ）において、＜ｌｏｎｇｉｔｕｄｅ＞および＜／ｌｏｎｇｉｔｕｄｅ＞は、ＰＯＩに関連する位置の経度を特定するためのタグである。＜ｌａｔｉｔｕｄｅ＞および＜／ｌａｔｉｔｕｄｅ＞は、ＰＯＩに関連する位置の緯度を特定するためのタグである。図７（ｃ）のＰＯＳ型は、具体的には以下のようになる。
【００４９】
ｄｅｆ［ＰＯＳ］
＜ｌｏｎｇｉｔｕｄｅ＞東経１３５度３５分３５秒３５＜／ｌｏｎｇｉｔｕｄｅ＞
＜ｌａｔｉｔｕｄｅ＞北緯４１度４１分４１秒４１＜／ｌａｔｉｔｕｄｅ＞
【００５０】
上記ＰＯＳ型の例によれば、ＰＯＩの経度情報は、＜ｌｏｎｇｉｔｕｄｅ＞および＜／ｌｏｎｇｉｔｕｄｅ＞のタグの間に記載された東経１３５度３５分３５秒３５であり、その緯度情報は、＜ｌａｔｉｔｕｄｅ＞および＜／ｌａｔｉｔｕｄｅ＞のタグの間に記載された北緯４１度４１分４１秒４１であることが分かる。
【００５１】
さらに、図７（ｄ）は、「ＰＯＩ型」と呼ばれる情報形式の定義している。ＰＯＩ型は、ＰＯＩ情報の属性および内容を詳細に特定するための情報形式である。図７（ｄ）において、ｄｅｆ［ＰＯＩ］は、この情報形式がＰＯＩ型を定義していることを示す。［ＰＯＩ−ＩＤ］は、図７（ｂ）に示すＰＯＩ−ＩＤ型の情報形式（タグ形式）である。つまり、ＰＯＩ型の先頭部分には、ＰＯＩの名称と電話番号とが少なくとも設定される。＜ｋｉｎｄ＞および＜／ｋｉｎｄ＞は、ＰＯＩの種別を特定するタグである。ＰＯＩの種別には、レストラン、ホテル、観光地等がある。＜ｚｉｐ＞および＜／ｚｉｐ＞は、ＰＯＩの所在地の郵便番号を特定するタグである。＜ａｄｄｒｅｓｓ＞および＜／ａｄｄｒｅｓｓ＞は、ＰＯＩの所在地を示すタグである。＜ｕｒｌ＞および＜／ｕｒｌ＞は、ＰＯＩに関する情報を記載したインターネットのホームページのＵＲＬが記載される。このページから、さらに様々な情報にアクセスすることが可能である。＜ｓｅｒｖｉｃｅ＞および＜／ｓｅｒｖｉｃｅ＞は、ＰＯＩのサービス内容を特定するタグである。サービス内容とは、特売情報や格安ランチ等の情報である。つまり、ＰＯＩの店主等が特に宣伝したいサービスの内容がこのタグの間に記述される。同様に、＜ｗｏｒｋｔｉｍｅ＞および＜／ｗｏｒｋｔｉｍｅ＞は、営業日や営業時間を示すタグである。＜ｂｏｄｙｉｎｆｏ＞および＜／ｂｏｄｙｉｎｆｏ＞は、以下に続くコンテンツ情報の形式（種類）を特定するタグである。より具体的には、＜ｂｏｄｙｉｎｆｏ＞および＜／ｂｏｄｙｉｎｆｏ＞のタグの間には、テキスト、イメージ、オーディオ、ビデオ、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）等と記載される。＜ｂｏｄｙ＞および＜／ｂｏｄｙ＞は、ＰＯＩのコンテンツ情報を特定するためのタグである。＜ｂｏｄｙ＞および＜／ｂｏｄｙ＞のタグの間には、テキストデータ、イメージデータ、オーディオデータ、ビデオデータ、ＭＴＭＬで記述されたデータ等、コンテンツ情報の実体が配置される。
【００５２】
演算処理部１０４は、以上の情報形式を有する検索結果を受け取る。ところで、ステップＳ２０１では、単に目的地が選択されればよい。そのため、情報提示部１０８は、目的地の選択に必要最低限な情報のみを提示すればよい。そこで、記憶部１０３情報サービスセンタ３１０等は、現時点では、［ＰＯＩ−ＩＤ］のみからなる検索結果を情報端末装置１００に送信すればよい。
【００５３】
ところで、本実施形態では、複数箇所（記憶部１０３や情報サービスセンタ３１０および３２０）で検索が実行される場合があるので、演算処理部１０４は、同じ［ＰＯＩ−ＩＤ］を有する検索結果を取得する場合がある。演算処理部１０４は、検索結果の［ＰＯＩ−ＩＤ］が重複していると（ステップＳ３０４）、ステップＳ３０５に進む。ここで、重複する検索結果を探す際、演算処理部１０４は、［ＰＯＩ−ＩＤ］に記述されたＩＤ−ｎａｍｅおよびｐｈｏｎｅに直目する。演算処理部１０４は、ＩＤ−ｎａｍｅおよびｐｈｏｎｅが同じ場合に、［ＰＯＩ−ＩＤ］同士が同じであると判断する。一方、ステップＳ３０４において、検索結果の［ＰＯＩ−ＩＤ］が互いに重複しない場合には、演算処理部１０４は、ステップＳ３０５を実行することなく、取得した検索結果を提示情報作成部１０７に渡す。
【００５４】
まず、ステップＳ３０５では、［ＰＯＩ−ＩＤ］が重複する検索結果が処理対象として選択される。次に、演算処理部１０４は、選択されている検索結果に対して、優先順位を付ける（ステップＳ３０５）。本実施形態では、優先順位の付け方には、以下の３つの方法がある。第１の方法は、演算処理部１０４が、選択されている検索結果の＜ｓｉｚｅ＞に着目して、データ量の大きいものを優先する方法である。この場合、演算処理部１０４はＰＯＩの情報の詳細度を重視していることになる。第２の方法は、演算処理部１０４が、選択中の＜ｓｉｚｅ＞に着目して、データ量の小さいものを優先する方法である。この場合、演算処理部１０４は、ＰＯＩ情報を取得する際に必要となる通信コストや通信時間の低減を重視していることとなる。第３の方法は、＜ｕｐｄａｔｅ＞に着目して、更新日時が新しいものを優先する方法である。この場合、演算処理部１０４は、ＰＯＩ情報の鮮度を重視していることとなる。以上の第１〜第３の方法は、ユーザの好みに応じて、予め情報端末装置１００に設定されている。
以上のようにして優先順位が付けられると、演算処理部１０４は、取得した全ての検索結果と、重複する検索結果の優先順位とを提示情報作成部１０７に渡す。
【００５５】
提示情報作成部１０７は、優先順位を参照しつつ、受け取った検索結果を情報提示部１０８が情報提示するのに適切な形式に整える。言うまでもないが、提示情報部１０７は、ステップＳ３０５が実行されなかった場合には、優先順位を受け取らないので、受け取った検索結果の形式を単純に整える。情報提示部１０８は、提示情報作成部１０７により形式が整えられた検索結果をユーザに提示する（ステップＳ３０６）。これによって、情報提示部１０８は、ユーザがこれから向かう目的地（ＰＯＩ）の候補地を提示する。
ここで、図８は、情報提示部１０８の情報提示の例を示している。本例では、○○商事の検索結果が２つあったために、図８（ａ）では優先された方を上に重ねて表示しており、図８（ｂ）では優先順に丸付き数字１、丸付き数字２の番号を振り、各情報を選択するためのボタンを小さく表示している。このような表示により、ユーザはＰＯＩ情報の検索結果を優先順で知ることができる。
【００５６】
ユーザは、入力部１０１を操作して、情報提示部１０８が提示する候補地（ＰＯＩ）の中から、いずれかを選択する。選択されたＰＯＩは目的地として設定される（ステップＳ３０７）。このように、現時点では目的地を選択するだけであるから、詳細なＰＯＩ情報（図７（ｄ）参照）は不要である。そのため、記憶部１０３または情報サービスセンタ３１０等は、ステップＳ３０２の要求に応答して、［ＰＯＩ−ＩＤ］（図７（ｂ）参照）のみを検索して送信することが好ましい。これによって、インターネット４００等の通信トラフィックを減らしたり、演算処理部１０４の処理付加を減らしたりすることができる。
【００５７】
また、ユーザは、目的地のより詳細なＰＯＩ情報を得たい場合がある。この場合、ユーザは、入力部１０１を操作して、必要な［ＰＯＩ−ＩＤ｝を特定する。この操作に応答して、演算処理部１０４は、情報要求部１０９を通じて、ユーザにより特定された［ＰＯＩ−ＩＤ］を、その送信元の情報サービスセンタ３１０または３２０に送信することで、ＰＯＩ型の形式（図７（ｄ）参照）で記述された詳細なＰＯＩ情報を、現時点でも簡単に得ることができる。また、［ＰＯＩ−ＩＤ］には、電話番号が記述される。例えば、表示能力に制限がある携帯電話を情報端末装置１００として使用する場合であっても、［ＰＯＩ−ＩＤ］の取得により、電話番号を得ることができる。そのため、ユーザは、電話をかければ、詳細なＰＯＩ情報を得ることができる。
【００５８】
目的地が設定されると（図３；ステップＳ２０１）、情報端末装置１００の現在地から目的地までの経路を探索する処理が実行される（ステップＳ２０２）。この経路探索処理の詳細な処理手順を、図５を参照して説明する。まず、演算処理部１０４は、情報要求部１０９を通じて、選択された［ＰＯＩ−ＩＤ］（目的地）と、現在地検出部１０２により検出される現在地とを情報サービスセンタ３３０に送って、現在地を出発地として、目的地までの経路の算出を要求する（ステップＳ４０１）。情報サービスセンタ３３０は、送られてきた現在地と目的地の位置を基に、要求された経路を計算する。この計算手法はどんな方法でも構わないが、一般的にはダイクストラ法を改良したものやＡスター法が使用される。さらに、情報サービスセンタ３３０は、経路の計算結果に従って情報端末装置１００を案内するために必要となる案内情報を作成する。情報サービスセンタ３３０は、１組みの経路情報と案内情報とを、情報端末装置１００に送信する。
【００５９】
演算処理部１０４は、経路情報および案内情報を、情報受信部１０６および解析部１０５を通じて受け取る（ステップＳ４０２）。
なお、現在地から目的地までの経路計算は、通常のカーナビゲーションシステムと同様に、情報端末装置１００で行うことも可能である。しかし、本実施形態のように、情報サービスセンタ３３０で計算する場合には、情報端末装置１００で計算する場合に比べて、計算能力の高いコンピュータを使用できる上、計算に使用する地図データのすべてをコンピュータのメインメモリに記憶できるため、極めて高速に経路を計算できる。
【００６０】
次に、経路情報と案内情報とを、図９を参照して詳細に説明する。図９（ａ）は、経路情報を示すｒｏｕｔｅ型の定義であり、各タグは以下の意味を持つ。
［ＩＤ］は、図７（ａ）のＩＤ型と同様の形式であって、今回算出された経路を特定するためのＩＤ情報である。［ＩＤ］には、経路の名称、データサイズおよび更新日（作成日）が記載される。
＜ｒｏａｄｎａｍｅ＞および＜／ｒｏａｄｎａｍｅ＞は、通行すべき道路の名称を特定するタグである。両タグの間に、通行すべき道路の名称が記述される。
＜ｃｒｏｓｓｎａｍｅ＞および＜／ｃｒｏｓｓｎａｍｅ＞は、曲がるべき交差点としての交差点名を特定するためのタグである。両タグの間には、交差点の名称が記載される。
さらに、図９（ａ）には、いくつかの［ＰＯＳ］が示されている。各［ＰＯＳ］は図７（ｃ）で説明した通りのものである。図９（ａ）において、［ＰＯＳ］の直ぐ右にある（）で囲んだ部分は、何の位置を記載したかを示すコメントである。＜ｃｒｏｓｓｎａｍｅ＞および＜／ｃｒｏｓｓｎａｍｅ＞の直ぐ下に記載された［ＰＯＳ］は、交差点の位置を経度情報および緯度情報により特定する。
以上の基本的な経路情報（経路の計算結果）に加えて、＜ｄｉｓｔｔｏｎｅｘｔ＞＜／ｄｉｓｔｔｏｎｅｘｔ＞のタグにより分岐点間の距離、さらに、＜ｄｉｒｅｃｔｉｏｎ＞＜／ｄｉｒｅｃｔｉｏｎ＞のタグにより曲折方向が記載される。道路および交差点の名称、分岐点間の距離ならびに曲折方向は、一つのセットであり、分岐の回数分だけ繰り返して記載される。なお、道路名称が存在しない場合には、当該道路の端点となる交差点からの角度など、道路を特定できる情報が記載される。
【００６１】
さらに、経路情報には、ＰＯＳ型の情報形式により、出発地位置、目的地位置、経由地位置が、経路の計算に使用された情報として記載される。出発地と目的地はそれぞれ一つずつしかないが、経由地はいくらでも設定できるので、必要な個数だけ並ぶ。
＜ｐａｒａｍｅｔｅｒ＞＜／ｐａｒａｍｅｔｅｒ＞のタグの間には、探索パラメータが記載される。探索パラメータは、経路計算に使用者の好みを反映させるものであり、自動車からの利用であれば、有料道路やフェリー使用の有無などを設定する。歩行者の場合にも、歩く距離の上限を設定したり、所用時間や料金の設定がある。例えば、急ぐ場合には、最寄りのタクシー乗り場までの道のりを案内する。
【００６２】
ここで、図１０（ａ）は、経路情報の一例である。図示したように、各タグの間に具体的な道路名称や交差点名称、分岐点間の距離、進行方向が記述される。この例では、探索計算のパラメータとして乗用車向けの最短時間を設定している。最短時間の経路とは、現在の交通状況を考慮して使用者が最も短時間で目的地に到着できる経路を意味する。他には最短距離の経路などがあり、歩行者や自転車ではこちらが一般的である。なお、この例では［ＰＯＳ］には、位置情報の数値が具体的に記述されていないが、実際には、コメントで示された場所（交差点位置、出発地位置、目的地位置、経由地位置）の位置情報が記述される。
【００６３】
また、図９（ｂ）は案内情報を表現するためのｇｕｉｄａｎｃｅ型の情報形式例である。
［ＩＤ］は、これまでと同様の形式であって、当該［ＩＤ］には、案内情報を識別するための名称と、データサイズと、更新日とが記載される。案内情報の名称は、経路の名称と関連づけて、対応する経路が分かるようにする方が良い。例えば、経路名称が「経路：渋谷−新橋」であれば、「案内：渋谷−新橋」などとする。
＜ｃｒｏｓｓｎｏ＞および＜／ｃｒｏｓｓｎｏ＞は、交差点番号を記述するためのタグである。両タグの間には、交差点番号が記載される。交差点番号は、案内すべき分岐点となる交差点を特定するための番号であり、上述した経路情報（図９（ａ）参照）に記載された交差点の並びの番号を記載する。これによって、その交差点の位置や名称等を特定することができる。例えば、図１０の場合、同図（ａ）に記述された１番目の交差点である「三宅坂」を、同図（ｂ）の一行目に記述された＜ｃｒｏｓｓｎｏ＞１＜／ｃｒｏｓｓｎｏ＞が指し示すことになる。２番目以降の交差点についても、同様に交差点番号により特定される。また、全国で一意に割り当てられた交差点番号を、＜ｃｒｏｓｓｎｏ＞および＜／ｃｒｏｓｓｎｏ＞の間に記述しても良い。この場合には、交差点の詳細情報は交差点番号から一意に決めることができる。そのため、交差点番号と、この番号により特定される交差点の位置等の情報を記載したテーブルを用いることで、当該交差点の情報を容易に検索することができる。さらに、かかるテーブルを持つことにより、図９（ａ）に示すような交差点名称や交差点位置を経路情報に持たずに、交差点番号のみを経路情報に持たせることができるので、経路情報を単純化することもできる。以上のように、全国で一意な交差点番号を、＜ｃｒｏｓｓｎｏ＞および＜／ｃｒｏｓｓｎｏ＞の間に記述するメリットは大きい。
【００６４】
＜ｉｎｒｏａｄ＞および＜／ｉｎｒｏａｄ＞のタグは、双方の間に道路の名称が記述されることにより、上記交差点番号により特定される交差点に進入する道路の名称を特定する同様に、＜ｏｕｔｒｏａｄ＞および＜／ｏｕｔｒｏａｄ＞のタグは、双方の間に記述された道路名称により、上記交差点からの脱出する道路の名称を特定する。なお、進入道路および脱出道路に名前がない場合には、経路情報と同じようにして、各道路を特定する。
次の＜ｐｏｉｉｄ＞および＜／ｐｏｉｉｄ＞のタグの間には、典型的には、上記交差点において、経路案内の目印になるような場所の名称と、その場所の電話番号とが記述される。ここで、図７（ｄ）に示す情報形式のＰＯＩ情報にも、その場所の名称と電話番号が記述されている。そのため、情報端末装置１００は、案内情報（ｇｕｉｄａｎｃｅ型）に記述された名称と電話番号をキーワードと検索要求して、情報サービスセンタ３１０等から、交差点の目印に関連するＰＯＩ情報を取得することができる。これによって、後述するように、情報端末装置１００は、曲がるべき交差点や進むべき方向をユーザに分かりやすく提示することができる。
【００６５】
ここで、図１０（ｂ）は、案内情報の一例である。図示した例では、図１０（ａ）に示される経路上の２つの分岐点について記載されている。まず、案内情報には、図１０（ａ）の経路上の、１番目の交差点の情報が記載されている。この１番目の交差点は、図１０（ａ）から三宅坂であることが分かる。また、三宅坂交差点へは青山通りから入り、次に内堀通りを東向きに進むことが分かる。この分岐点でのランドマークとなるＰＯＩは２つあり、一つは電話番号が０３-３３３３-９９９９である△会館であり、もうひとつは桜田濠であることが分かる。一つ目のＰＯＩの詳細な情報は電話番号から検索することができる。実際の案内については後に説明する。
次の分岐点は交通規制地図のｘｘｘｘ番の交差点であり、これは全国の交差点を一意に決定できる交差点番号であるものと仮定し、これによって、交差点が特定できるものとする。以降のタグについては三宅坂での説明と同様であるため、説明を省略する。
【００６６】
ステップＳ２０２では、上述した経路結果と案内情報を取得することで、情報端末装置１００は、経路案内に必要な最小限の情報を得たことになる。この時点で、演算処理部１０４は、分岐点の交差点位置同士をつなぐ道路を、記憶部１０３が持つ地図データから検索するか、道路名称と交差点名称を基に、当該地図データの中から、対応する道路を選出して、情報提示部１０８を通じて、今回得られた経路の概要を、図１１のようにユーザに提示することも可能である。
【００６７】
ステップＳ２０２の経路探索処理が終了すると、演算処理部１０４は、取得した経路情報および案内情報を基に、ユーザを目的地まで経路案内する処理を実行する（ステップＳ２０３）。この経路案内処理の詳細な処理手順を、図６を参照して説明する。まず、演算処理部１０４は、現在地検出部１０２により検出される情報端末装置１００の現在地を得る（ステップＳ５０１）。なお、現在位置の取得は、利用者が入力部１０１を操作して、現在地を直接情報端末装置１００に入力しても良いし、情報端末装置１００の位置を、いずれかの情報サービスセンタで検出して、当該情報端末装置１００に送信しても構わない。ステップＳ５０１の処理により、演算処理部１０４は、情報端末装置１００の現在位置を経路に合わせた形で、情報提示部１０８を通じてユーザに提示する。
【００６８】
さらに、演算処理部１０４は、取得した現在地を基に、情報端末装置１００が目的地周辺に到達したか否かを判断する（ステップＳ５０２）。目的地周辺に到達していれば、演算処理部１０４はステップＳ５０７に遷移する。ステップＳ５０７の処理は後述する。
一方、目的地周辺に到達していなければ、演算処理部１０４はステップＳ５０４に遷移する。演算処理部１０４は、次の分岐点と、現在地との間の距離を計算し、この計算結果を基に案内のタイミングか否かを判定する（ステップＳ５０３）。案内のタイミングでない場合には、演算処理部１０４は、情報端末装置１００が次の分岐点に接近しておらず、ユーザは道なりに進めば良いため、使用者を案内情報を提供する必要はない。そのため、演算処理部１０４は、ステップＳ５０４以降の処理を行わずに、ステップＳ５０１に戻り、ステップＳ５０１以降の経路案内処理を繰り返す。
【００６９】
一方、ステップＳ５０３において案内タイミングと判断されれば、情報端末装置１００が次の分岐点に接近しているので、演算処理部１０４は、ステップＳ５０４を実行する。このステップＳ５０４以降の処理を、詳細に説明する。以下には、図１０（ｂ）の案内情報の二つ目の分岐点の場合について説明する。まず、情報端末装置１００は、案内情報に記述された内容を、ユーザに提示する（ステップＳ５０４）。これによって、ユーザは、交通規制地図ｘｘｘｘで特定される交差点に接近していることが分かる。図１０（ｂ）の案内情報によると、情報端末装置１００は、桜田通りから侵入して、虎ノ門交差点（交差点番号が交通規制地図ｘｘｘｘの交差点）を通過して外堀通りから脱出する必要がある。しかしながら、現在接近している交差点の目印（ＰＯＩ）については、○×商店の名称とその電話番号しか分からない。
そこで、演算処理部１０４は、当該名称および当該電話番号とをキーワードとして、情報要求部１０９を通じて情報サービスセンタ３００に送信して、当該ＰＯＩの検索を要求する（ステップＳ５０５）。この時、演算処理部１０４は、図１２（ａ）に示すような、電話番号をキーワードとして含む検索要求を、詳細なＰＯＩ情報用の情報サービスセンタ３５０または３６０への制御データとして送信する。この検索要求に応答して、情報サービスセンタ３５０または３６０は、キーワード検索を行う。なお、情報サービスセンタ３５０または３６０の検索処理は単純なデータベース検索であるため、ここでは説明を省略する。情報サービスセンタ３５０等は、キーワードに該当する詳細なＰＯＩ情報をデータベース内に見つけると、図７（ｄ）に示す情報形式で、検索結果を情報端末装置１００に送信する。
【００７０】
情報サービスセンタ３５０等からの検索結果は、情報受信部１０６により取得された後（ステップＳ５０５）、解析部１０５に渡される。解析部１０５は、検索結果を解析して、演算処理部１０４に渡す。これによって、演算処理部１０４は検索結果を得る。演算処理部１０４は、情報サービスセンタ３５０等を検索結果をまとめて、提示情報作成部１０７に出力する。検索結果は、提示情報作成部１０７により、情報提示部１０８が提示可能な形式に整えられる。情報提示部１０８は、提示情報作成部１０７から受け取った検索結果をユーザに提示する（ステップＳ５０６）。図１２（ｂ）は、検索結果の一例であり、○×商会の詳細なＰＯＩ情報を示している。この検索結果は、図７（ｄ）の形式に基づいているので、各項目の詳細な説明を省略する。
【００７１】
図１２（ｂ）において、＜ａｄｄｒｅｓｓ＞と＜ｂｏｄｙ＞のタグの中にある"・"は省略を意味している。＜ｂｏｄｙ＞の両タグの間には、ＨＴＭＬ形式のファイルが記述される。より具体的には、テキスト、イメージ、オーディオおよびビデオ等を含むコンテンツが記述される。
なお、以上の説明は、電話番号をキーワードとして、ＰＯＩ情報の取得を行う場合について説明したが、同様の仕組みで、名称から電話番号を検索したり、住所←→座標、電話番号←→座標、郵便番号←→座標などの変換を、情報サービスセンタ３５０または３６０に要求することができる。
【００７２】
このように、本実施形態では、タグを用いて、詳細なＰＯＩ情報が記載される。特に、＜ｌｏｎｇｉｔｕｄｅ＞および＜ｌａｔｉｔｕｄｅ＞タグの組み合わせ、または＜ａｄｄｒｅｓｓ＞タグにより、ＰＯＩの位置を簡単に特定できる。そのため、ＰＯＩ情報と地図データとの親和性を向上することができ、演算処理部１０４は、地図データ上にＰＯＩの詳細なデータ（例えば、イメージデータ）を簡単に重ね合わせて、分岐点の目印を地図データと同時に使用者に提供することができる。例えば、図１３に示すように、ＰＯＩ（例えば、○×商会）の写真を分岐点の近く表示して、分岐点を分かりやすくすることができる。
【００７３】
また、分岐点をさらに分かりやすく表示するためには、局所的に詳細な地図データを表示することも有効である。この場合には、情報端末装置１００は、図１４に示すＭＡＰ型の形式で地図データを情報サービスセンタ３４０から取得する。ＭＡＰ型の［ＩＤ］には、他のＩＤと同様に、地図データを識別するための名称と、データサイズと、更新日時とが記載される。
地図データには、地図をイメージとして表現するビットマップ地図と、道路をベクトルとして表現したベクトル地図とが存在する。＜ｔｙｐｅ＞および＜／ｔｙｐｅ＞のタグの間には、地図タイプが記載される。地図タイプには、対象となる地図データがビットマップ地図かベクトル地図であるかが記載される。
＜ｆｕｎｃｔｉｏｎ＞および＜／ｆｕｎｃｔｉｏｎ＞の間には、地図の用途が記載される。地図の用途には、対象となる地図データがどのような用途に使えるかが記載される。地図の用途としては、表示、位置計算、経路計算、経路案内などがある。
【００７４】
さらに、＜ｍａｋｅｒ＞および＜／ｍａｋｅｒ＞、ならびに＜ｆｏｒｍａｔ＞および＜／ｆｏｒｍａｔ＞の間には、地図データのメーカならびにフォーマットの種類が記載される。これらの２つの情報を、ＭＡＰ型の形式の記載事項とすることで、地図データを扱うソフトウェアとの対応を取ることができる。
＜ｄｉｓｐｓｉｚｅ＞および＜／ｄｉｓｐｓｉｚｅ＞の間には、表示地図の大きさが記載される。表示地図のサイズには、情報提示部１０８が対象となる地図データを表示する時の大きさが記載される。
［ＰＯＳ］を用いて、ディスプレイ（情報提示部１０８の一例）に表示すべき地図データの左上と右下との座標が記載される。これによって、ディスプレイに表示される地図データの範囲が決定される。さらに、地図の範囲から自動的に、地図データの詳細度を決定することができる。例えば、地図の範囲が１ｋｍ四方であれば拡大率の大きな縮尺を選択し、地図の範囲が１０ｋｍ四方の時には拡大率のやや小さな縮尺を選択する。
地図データの実体は通常バイナリデータであるので、＜ｂｏｄｙ＞タグに囲んで記載する。
【００７５】
このようにタグ付けすることにより、演算処理部１０４は、地図データ用の複数の情報サービスセンタから同じ範囲の地図データを取得した場合に、ステップＳ３０５で優先度を付けた場合と同様にして、今回提示すべき地図データを選択する。つまり、
・＜ｓｉｚｅ＞に着目し、サイズの大きい方を優先する
・＜ｓｉｚｅ＞に着目し、サイズの小さい方を優先する
・＜ｕｐｄａｔｅ＞に着目し、情報の更新日時の新しい方を優先する
といった基準に基づいて、今回提示される地図データが選択される。
【００７６】
最もデータサイズが大きいものを今回提示すべきものとして選ぶ場合には、データの詳細度を優先していることになる。また、最もデータサイズの小さいものを選ぶ時には、情報端末装置１００の処理負担を軽くすることを優先していることになる。特に、同じ範囲の地図データであっても、地図データのフォーマットによって、各地図データのサイズは互いに異なる場合がある。この場合には常にサイズの小さい方を選択することで、情報端末装置１００の処理負担を軽減することができる。また、更新日時の新しい地図データを選択する場合には、鮮度が高い地図データを優先していることとなる。
【００７７】
この方式で局所的に詳細な地図データを情報サービスセンタ３４０から取り込むことができるため、図１５（ａ）および（ｂ）に示すような案内表示を実現することができる。図１５（ａ）および（ｂ）は、分岐点となる交差点近傍の詳細な地図データ（俯瞰図）を、ある情報サービスセンタ３４０から取得して、画面左半分に表示している。この詳細な地図データは、同図では丸付き数字２を付した矢印にて指し示されているものである。画面の右半分の地図データは、記憶部１０３に記憶している場合が多いが、元々は地図データの更新のため情報サービスセンタ３３０から取得したものであるとする。この地図データは、同図では丸付き数字１を付した矢印にて指し示されている。この右半分の地図データはベクトル地図であり、通常のカーナビゲーションシステムのように、地図表示、位置検出、経路探索、経路案内に利用できる。ベクトル地図であり、その地図の内容がそれほど詳細ではないことから、当該地図データのサイズは小さい。そのため、記憶容量に制約のある情報端末装置１００の記憶部１０３に、ベクトル地図を記憶することは容易である。
【００７８】
一方、図１５（ａ）および（ｂ）の左半分の地図はビットマップ地図であり、当該ビットマップ地図は非常に詳細な情報を持つため、そのデータサイズが大きい。また、詳細な情報は頻繁に更新する必要がある。これらのことから、頻繁に構成されかつ巨大なデータを情報端末装置１００が内部に持つことは好ましくない。そのため、上述した情報サービスセンタ３４０との通信により、分かりにくい分岐点などの詳細情報を必要な時に得ることができる。これによって、情報端末装置１００で詳細な地図データを記憶する必要がなくなる上、常に最新の情報を利用できるようになる。このような詳細情報の利用方法は分岐点だけでなく、現在地や目的地の周辺においても同様に適用できる。
【００７９】
さらに、より詳細なＰＯＩについてはＰＯＩ専用の情報サービスセンタ３６０、ＰＯＩの三次元データを専門とする情報サービスセンター３７０からデータを取得する。より詳細なＰＯＩのデータは、図１５（ａ）では、同図では丸付き数字３を付した矢印で示されている。また、図１５（ｂ）に示す三次元データは、同図では丸付き数字４を付した矢印にて指し示されている。
【００８０】
これらの４つの情報サービスセンタ３４０〜３７０から取得した情報により、図１５（ａ）および（ｂ）の例ような分かりやすい案内画面を表示することができる。
以上がステップＳ５０４〜Ｓ５０７で行われる経路の案内情報出力の処理の流れであり、案内タイミングが経過すると、情報端末装置１００が分岐点を通過したとして、演算処理部１０４はステップＳ５０１に戻り、以上の処理を繰り返す。
【００８１】
さて、情報端末装置１００は、地図データに基づいて経路を案内しながら、目的地に向かって進む。そして、ステップＳ５０２で目的地周辺に到達したと判断された場合には、目的地周辺に達した旨を示す案内情報を提示する（ステップＳ５０８）。ここでは、目的地情報を出力するのであるが、本実施例では目的地周辺までは自動車で移動し、そこからは徒歩で目的地に到達する場合を想定している。具体的には、目的地周辺の駐車場で車を降り、情報端末装置を携帯して歩いて目的地である○○商事を訪問すると想定する。この場合には、演算処理部１０４は、目的地情報（詳細なＰＯＩ情報）として、建物内のテナント配置情報を、情報サービスセンタ３６０に要求する（ステップＳ５０９）。そのため、演算処理部１０４は、○○商事の位置情報をイメージデータを取得することができる（ステップＳ５１０）。これによって、演算処理部１０４は、図１６に示すような建物内での位置をユーザに提示することができ（ステップＳ５１１）、使用者は容易に目的地に到着することができる。なお、目的地情報としては、建物の内部のイメージデータだけでなく、地下街の地図データ等であっても、同様にユーザにとって分かりやすい経路案内を実現することができる。
以上の処理で本情報端末装置１００の主要機能である経路案内を終了する。
【００８２】
以上説明したように、第１の実施形態によれば、情報端末装置１００と各情報サービスセンタ３１０等とは、インターネット４００で標準的に使用されるＰＰＰに従って情報をやりとりする。このように情報端末装置１００と各情報サービスセンタ３１０等とは、独自の通信プロトコルにより通信を行わないので、情報サービスセンタを簡単に増設することができる。逆に言えば、簡単に情報サービスセンタを閉鎖することもできる。そのため、情報サービスのための事業コストが嵩まない。さらに、通信プロトコルが独自規格であれば、情報端末装置１００は、特定の事業者からしか情報提供を受けることができない。しかし、本情報端末装置１００は、通信ネットワーク（インターネット４００）で標準的に使用される通信プロトコルでデータを通信するので、ユーザの情報選択の幅が広がる。
【００８３】
また、情報端末装置１００と情報サービスセンタ３１０等とは、タグ形式で表現された各種情報がやりとりされる。このタグ形式で表された情報には、経路案内に使用される各種情報の構造と内容とが示される。そのため、インターネット４００内の膨大な情報サービスセンタ３１０等から、ＰＯＩ情報等、経路案内に必要な情報をユーザの好みに合わせて的確に得ることができる。さらに、タグ形式により、地図データとＰＯＩ情報との親和性を容易に向上することができる。これによって、複数の情報を同時にユーザに提示できるようになるため、ユーザの好みに応じた柔軟な経路案内機能を実現できる。
【００８４】
なお、以上の実施形態は、図６のステップＳ５０３の案内タイミングを、情報端末装置１００が案内情報に記述された交差点に接近したタイミングとして説明した。しかし、案内タイミングは、例えば、観光ポイントに接近したタイミング等、ユーザが関心の高い地点に関連するタイミングであれば、どのようなタイミングでも良い。
【００８５】
また、本実施形態では、図１６を参照して建物内部の情報を表示する場合を例に採り上げて説明したが、地下街等、ユーザが関心の高い地点の詳細なデータであれば、どのような地点に関するデータであっても良い。
【００８６】
（実施の形態２）
次に、第２の実施形態について説明する。第２の実施形態に係る情報端末装置１００のブロック構成は、図２に示す第１の実施形態のそれと同様である。そのため、図２を本実施形態でも援用する。ただし、本情報端末装置１００は、携帯電話のように、小さい表示器を持つと想定する。つまり、情報提示部１０８の能力に制限がある。本実施形態では、たとえ情報提示部１０８の能力に制限がある場合であっても、第１の実施形態と同様に、ユーザの好みに応じた柔軟な経路案内機能を実現するものである。
【００８７】
本情報端末装置１００の具体的な処理手順もまた、図３〜図６に示すフローチャートの通りである。ただし、情報提示部１０８の能力に制限があるため、下記の点で相違する。
まず、第１の相違点は、図４のステップＳ３０６において、ＰＯＩ情報（検索結果）の提示の仕方が異なることである。携帯電話のように表示器の小さな情報端末装置１００では、文字と記号との表示が主であり、表示可能な情報量も大きく制限される。したがって、詳細なＰＯＩ情報をそのまま表示しても、情報端末装置１００の使い勝手が悪くなる。そこで、情報端末装置１００は、ＰＯＩ−ＩＤ（図７（ｄ）参照）のみを利用して、情報提示部１０８を通じて、図１７（ａ）のような一覧表示画面を表示する。ユーザが詳細なＰＯＩ情報を知りたい場合には、ＰＯＩ−ＩＤに含まれる電話番号に電話をかけて尋ねることができる。つまり、図７（ｄ）のＰＯＩ型の詳細な情報は一切不要であるため、余分な通信をする必要がなく、通信コストおよび時間を節約できる上、情報端末装置１００の記憶容量も少なくて済む。
【００８８】
第２の相違点は、図５のステップＳ４０２で取得された経路情報の提示の仕方（図１１等を参照）が大きく異なる点である。つまり、本情報端末装置１００はイメージの表示には適さないので、経路情報を、図１７（ｂ）に例示するように、ユーザに提示する。同図の例では、情報提示部１０８は、道路名称と分岐点となる交差点名称、そこでの曲折方向を文字および記号により提示する。この提示内容によれば、青山通りを三宅坂まで進み、右折して内堀通りを進む。次に桜田門で右折して桜田通りに進み、虎ノ門を左折して外堀通りを進むと目的地の新橋に到着できる。なお、情報サービスセンタ３３０から取得した経路情報は、図９（ａ）の情報形式を有しており、第１の実施形態と同様である。
【００８９】
第３の相違点は、図６のステップＳ５０４またはＳ５０８における案内情報もまた、文字および記号により提示される点で異なる。図１７（ｃ）は、図１７（ｂ）に示される経路の３番目の分岐点に対応する、案内情報の提示の仕方を示している。ここでは、情報端末装置１００は、図１０（ａ）の経路情報および（ｂ）の案内情報のみから、提示すべき情報を作成している。ここでも、ランドマークとなる○×商店の詳細情報は取得する必要がない。なお、図１７（ｃ）の右下の▼は次の案内情報が存在することを意味しており、文字画面を下にスクロールできることを使用者に伝えるための記号である。
さらに、ステップＳ５０５〜Ｓ５０８およびＳ５０９〜Ｓ５１１は、実行されず、典型的にはイメージデータ等で表現される詳細なＰＯＩ情報を取得しない方が好ましい。もちろん、詳細なＰＯＩ情報が文字および記号などのように小さいデータで表される場合には、これを取得しても構わない。
【００９０】
このように、本情報端末装置１００の経路案内処理の流れは、第１の実施形態のそれと全く同じであり、さらに、情報サービスセンタ３１０等から取得する情報の形式も同じでありながら、能力に制限がある情報端末装置１００でも経路案内を実現することができる。また、この場合には、必要最小限の情報のみを情報サービスセンタ３１０等から取得すれば良いので、低コストで経路案内処理を実現することができる。
【００９１】
以上説明したように、第２の実施形態によれば、経路案内に必要な情報の構造と内容とをタグ形式で表現することにより、各情報端末装置１００の性能を意識することなく、情報サービスセンタ３１０等は各種情報を提供することができる。つまり、情報端末装置１００の情報提示部１０８が高い場合と低い場合とで、異なる情報を提供する必要がなくなる。
【図面の簡単な説明】
【図１】本発明の第１および第２の実施形態に係る情報端末装置１００の通信環境を示している。
【図２】図１の情報端末装置１００の詳細なブロック構成を示している。
【図３】図１の情報端末装置１００の処理の概要を示すフローチャートである。
【図４】図３の目的地選択処理の詳細な処理手順を示すフローチャートである。
【図５】図３の経路探索処理の詳細な処理手順を示すフローチャートである。
【図６】図３の経路案内処理の詳細な処理手順を示すフローチャートである。
【図７】各実施形態の情報端末装置１００および情報サービスセンタ３１０等がそれぞれ取り扱うＩＤ型、ＰＯＩ−ＩＤ型、ＰＯＳ型およびＰＯＩ型の定義を示している。
【図８】図４のステップＳ３０４における検索結果の提示例を示している。
【図９】各実施形態の情報端末装置１００および情報サービスセンタ３１０等がそれぞれ取り扱うｒｏｕｔｅ型およびｇｕｉｄａｎｃｅ型の定義を示している。
【図１０】図９に示すｒｏｕｔｅ型およびｇｕｉｄａｎｃｅ型の具体例を示している。
【図１１】図５のステップＳ４０２の後に情報提示部１０８により提示される経路の例を示している。
【図１２】図６のステップＳ５０５で情報要求部１０９が送信する検索要求と、ステップＳ５０６で演算処理部１０４が取得する検索結果との一例を示している。
【図１３】図６のステップＳ５０７において提示される情報の一例を示している。
【図１４】各実施形態の情報端末装置１００および情報サービスセンタ３１０等がそれぞれ取り扱うＭＡＰ型の定義を示している。
【図１５】第１の実施形態により実現できる特徴的な経路案内の表示を示している。
【図１６】第１の実施形態に係る情報端末装置１００の情報提示部１０８が、目的地である○○商事の所在地を表示している様子を示している。
【図１７】第２の実施形態に係る情報端末装置１００が提示する経路案内を示している。
【図１８】「特開平９−２２９６９４号」公報に開示された従来の情報端末装置およびその通信環境を示している。
【符号の説明】
１０１…入力部
１０２…現在地検出部
１０３…記憶部
１０４…演算処理部
１０５…解析部
１０６…情報取得部
１０７…提示情報作成部
１０８…情報提示部
１０９…情報要求部

Claims

所定のプロトコルで通信が行われるネットワーク内の複数の情報サービスセンタにアクセス可能であって、かつ移動可能な情報端末装置であって、
各情報サービスセンタは、提供可能な情報の属性および内容を表すタグ形式で、当該情報を通信プロトコルに従って送信可能に構成されており、
出発地から目的地までの経路を示す経路情報、および当該経路の案内するために、各重要地点を簡素に特定するＩＤ情報を含む案内情報を取得する第１の取得部と、
第１の取得部が取得した経路情報および／または案内情報に基づく第１の地図データを用いて、出発地から目的地までの経路を案内する経路案内部と、
必要に応じて、前記ＩＤ情報を用いて、各情報サービスセンタに、地点情報の検索を要求する要求部と、
要求部による要求に応じて、経路案内部が案内する経路上の各重要地点を詳細に示すタグ形式の地点情報を、各情報サービスセンタから取得する第２の取得部とを備え、
経路案内部は、第２の取得部が取得した地点情報を、第１の地図データと同時に提示して、経路上の各重要地点を明確にする、情報端末装置。
ＩＤ情報は、電話番号、住所、郵便番号のいずれかであって、
各情報サービスセンタは、キーワードとして受け取った電話番号、住所、郵便番号を、経度座標および緯度座標に変換し、
第２の取得部は、各重要な地点の経度座標および緯度座標を含む地点情報を取得する、請求項１に記載の情報端末装置。
ＩＤ情報は、経度座標および緯度座標の組み合わせであって、
各情報サービスセンタは、キーワードとして受け取った経度座標および緯度座標の組み合わせを、電話番号、住所および／または郵便番号に変換し、
第２の取得部は、各重要な地点の電話番号、住所および／または郵便番号を含む地点情報を取得する、請求項１に記載の情報端末装置。
地点情報は、第１の地図データとは異なる縮尺を有する第２の地図データを含んでおり、
経路案内部は、第１の地図データと、第２の取得部が取得した第２の地図データとを同時に提示する、請求項１に記載の情報端末装置。
第２の地図データは、重要地点周辺を拡大した地図データである、請求項４に記載の情報端末装置。
第２の地図データは、重要地点周辺を３次元で表す地図データである、請求項４に記載の情報端末装置。
地点情報は、重要な地点である建物または地下街を詳細に示す第２の地図データであって、
経路案内部は、第１の地図データと、第２の取得部が取得した第２の地図データとを同時に提示する、請求項１に記載の情報端末装置。
経路案内部は、第２の取得部が複数の第２の地図データを受け取った場合に、データサイズが最大の第２の地図データを、第１の地図データと同時に提示する、請求項４に記載の情報端末装置。
経路案内部は、第２の取得部が複数の第２の地図データを受け取った場合に、データサイズが最小の第２の地図データを、第１の地図データと同時に提示する、請求項４に記載の情報端末装置。
経路案内部は、第２の取得部が複数の第２の地図データを受け取った場合に、最も新しい第２の地図データを、第１の地図データと同時に提示する、請求項４に記載の情報端末装置。
ユーザの関心が高い地点に関連するキーワードに基づいて、複数の情報サービスセンタに、当該関心が高い地点に関連する情報の検索を要求する要求部と、
要求部による要求の後に、複数の情報サービスセンタの検索結果を取得する第３の取得部と、
第３の取得部が取得した検索結果をユーザに提示する提示部とを含み、
経路案内部は、提示部が提示した検索結果のいずれかの地点を、目的地として経路を案内する、請求項１に記載の情報端末装置。
提示部は、第３の取得部が複数の検索結果を受け取った場合に、データサイズが大きい検索結果を優先的に提示する、請求項１１に記載の情報端末装置。
提示部は、第３の取得部が複数の検索結果を受け取った場合に、データサイズが小さい検索結果を優先的に提示する、請求項１１に記載の情報端末装置。
提示部は、第３の取得部が複数の検索結果を受け取った場合に、更新日時が新しい検索結果を優先的に提示する、請求項１１に記載の情報端末装置。
地点情報は、重要地点を簡素に特定する第１の情報と、当該重要地点を詳細に示す特定する第２の情報とを含んでおり、
第１の情報は、重要地点の名称および電話番号のタグを少なくとも含む、請求項１に記載の情報端末装置。
経路情報は、進行すべき道路の名称、分岐点となる交差点の名称、分岐点間の距離および分岐点での曲折方向のタグを少なくとも含む、請求項１に記載の情報端末装置。
全国の交差点には、一意な交差点番号が予め付されており、
経路情報は、交差点番号を特定するタグを少なくとも含む、請求項１に記載の情報端末装置。
案内情報は、経路情報にタグ形式で記述された分岐点、ならびに当該分岐点の目印となる地点の名称および電話番号の情報を少なくとも含む、請求項１６に記載の情報端末装置。
所定のプロトコルで通信が行われるネットワーク内の複数の情報サービスセンタにアクセス可能であって、かつ移動可能な情報端末装置に用いられる経路案内方法であって、
各情報サービスセンタは、提供可能な情報の属性および内容を表すタグ形式で、当該情報を通信プロトコルに従って送信可能に構成されており、
出発地から目的地までの経路を示す経路情報、および当該経路の案内するために、各重要地点を簡素に特定するＩＤ情報を含む案内情報を取得する第１のステップと、
第１のステップで取得された経路情報および／または案内情報に基づく第１の地図データを用いて、出発地から目的地までの経路を案内する第２のステップと、
必要に応じて、前記ＩＤ情報を用いて、各情報サービスセンタに、地点情報の検索を要求する第３のステップと、
第３のステップによる要求に応じて、第２のステップで案内される経路上の各重要地点を詳細に示すタグ形式の地点情報を、各情報サービスセンタから取得する第４のステップとを備え、
第２のステップは、第４のステップで取得された地点情報を、第１の地図データと同時に提示して、経路上の各重要地点を明確にする、経路案内方法。