JP5011074B2 - 地図データ更新方法、地図データ更新プログラムおよびカーナビゲーション装置 - Google Patents

Description

本発明は、カーナビゲーション装置の地図データを更新する地図データ更新方法および地図データ更新プログラム、ならびに、その地図データ更新方法を適用したカーナビゲーション装置に関する。

カーナビゲーション装置（以下、「カーナビ装置」という）は、車両の現在位置と誘導経路とを、その現在位置近傍の道路地図に重ね合わせて表示し、ドライバによる走行経路の選択を支援する。従って、カーナビ装置が有する地図データは、できる限り現実の状態を忠実に表した最新のものであるのが望ましい。ところで、現実は、新しい道路、施設、建物などが日々建設され、また、廃棄されている。従って、カーナビ装置において地図データは、適宜、更新されなければならない。

一般に、カーナビ装置で用いられる地図データは、日本全国をカバーし、道路データだけでなく、様々な施設や建物の情報を含んでいるために、そのデータ量は数Ｇバイトに達する。そのため、特に、通信ネットワークを介して更新する場合には、地図データの全部を更新するのに相当の時間を要する。

従来、地図データの更新時間を削減する方法として、しばしば、差分更新法が用いられている。差分更新法では、新地図データと旧地図データとを比較し、その相違データである差分データを更新データとすることによって更新データ量を削減し、その結果として、更新時間を短縮する。

また、差分更新法に併せて部分更新法も用いられている。部分更新法では、日本全国の地図データすべてを一度に更新するのでなく、更新対象の地図データを、ユーザがよく利用するエリアやデータ種別の地図データなどに絞り込むことによって、更新データ量を削減する。例えば、特許文献１や特許文献２には、車両の走行履歴を記憶装置に蓄積し、その蓄積された走行履歴に基づき、更新対象のエリアやデータ種別を絞り込み、更新データ量を削減する部分更新法の例が開示されている。
特開２０００−１２１３７１号公報 特開２００６−２７５７７８号公報

特許文献１や特許文献２などに開示されている地図データの部分更新法においては、更新対象とする地図データを、過去の走行履歴に基づき単純に絞り込んでいるだけである。従って、それにより絞り込まれた更新対象の地図データは、走行中の車両の現在位置や目的地、あるいは、そのときユーザが求めようとしているデータ種別に、必ずしも適合したものであるとは限らない。例えば、車両が走行履歴にないエリアの道路を走行するような場合には、そのときすぐに必要となる地図データが更新されなかったり、逆に、すぐには必要でない地図データが更新されたりすることになる。

すなわち、特許文献１や特許文献２などに開示されている従来の地図データの部分更新法は、走行中の車両のカーナビ装置がそのときすぐに必要となる地図データを過不足なく更新することはできない、という問題を含んでいる。

以上の従来技術の問題点に鑑み、本発明の目的は、走行中の車両の現在位置や目的地、あるいは、そのときユーザが求めようとしているデータの種別に応じて必要な地図データを、過不足なく更新することが可能な地図データ更新方法、地図データ更新プログラムおよびカーナビゲーション装置を提供することにある。

前記目的を達成するために、本発明のカーナビゲーション装置には、その処理装置が実行中のアプリケーションにより利用されている地図データのエリアおよび種別に基づき、将来利用されるエリアおよび種別の地図データを予測する地図データ利用予測手段が設けられ、さらには、地図センタから配信される更新データのメタデータを取得するメタデータ取得手段が設けられている。

すなわち、地図データ利用予測手段を設けたことにより、カーナビゲーション装置は、その処理装置が実行中のアプリケーション、つまり、ユーザがそのとき利用しているナビゲーションの機能によって利用されている地図データのエリアおよび種別を知ることができ、さらには、その後引き続いて利用されるエリアおよび種別の地図データを予測することができる。従って、カーナビゲーション装置は、ユーザがそのとき利用しているナビゲーション機能、その機能に付随する目的地や誘導経路などに応じて、その後引き続いて必要となると予測される地図データの更新データを、過不足なく取得することができるようになる。

また、更新データのメタデータ取得手段を設けたことにより、カーナビゲーション装置は、地図データの更新データの本体を取得するに先立ち、そのメタデータを取得することができる。従って、カーナビゲーション装置は、更新データ本体の取得に先立ち、地図センタにおける更新データの整備状況を把握することができる。すなわち、カーナビゲーション装置は、前記地図データ利用予測手段によりデータ利用を予測したとき、地図センタにおける更新済のデータを見極めることができるので、利用することが予測された地図データの更新執行の「要」または「不要」を判断することができる。そして、その結果として、カーナビゲーション装置は、更新データの不要な取得を回避することができる。

本発明によれば、カーナビゲーション装置は、走行中の車両の現在位置、目的地、誘導経路、そのときユーザが求めようとしているデータの種別などに応じて必要となる地図データを、過不足なく更新することが可能になる。

以下、図面を参照して本発明の実施形態について詳しく説明する。

図１は、本発明の実施形態に係るカーナビゲーションシステムの構成の例を示した図である。図１に示すように、本実施形態に係るカーナビゲーションシステム１は、道路を走行する車両７に搭載され、ユーザにより設定された目的地までの誘導経路を表示装置２２に表示するカーナビ装置２と、マスタ地図ＤＢ（Database）３０１を保持し、そのマスタ地図ＤＢ３０１に保管されている最新の地図データをカーナビ装置２に提供する地図センタ３と、によって構成される。

図１において、カーナビ装置２は、その主要構成要素として、ナビ処理装置２０を備える。ここで、ナビ処理装置２０は、図示しないＣＰＵ（Central Processing Unit）と、メモリやハードディスク装置などの記憶装置と、を含んで構成されたコンピュータから成る。また、カーナビ装置２は、ナビ処理装置２０に対する情報の入出力装置として機能するＧＰＳ（Global Positioning System）受信機２１、表示装置２２、通信装置２３、メディアドライブ２４などを備える。

ここで、ＧＰＳ（Global Positioning System）受信機２１は、ＧＰＳ衛星からの電波を受信して、そのＧＰＳ受信機２１が位置する位置情報（緯度、経度などの情報）を取得する。また、表示装置２２は、ＬＣＤ（Liquid Crystal Display）などによって構成され、ナビ処理装置２０が出力する地図や誘導経路などを表示する。また、通信装置２３は、携帯電話機などによって構成され、携帯電話通信網の基地局５および携帯電話通信網やインターネットなどの通信ネットワーク４を介して、地図センタ３の通信装置３１との間で所定のデータ通信を行う。また、メディアドライブ２４は、ブリッジメディア６（ブリッジメディアとは、ＤＶＤ（Digital Versatile Disk）、ＵＳＢ（Universal Serial Bus）メモリなど、携帯型情報記憶メディアの総称）から、そのブリッジメディア６に記録されている地図データなどを読み取る。

また、ナビ処理装置２０は、その機能ブロックとして、ナビ処理部２００、地図データ管理部２１０などを含んで構成される。ナビ処理部２００は、カーナビ装置２の一般的な機能を実現するために、地図描画処理、経路探索処理、ロケータ処理、経路誘導処理、交通データ処理、ＰＯＩ（Point of Interest）探索処理などを実行する。また、地図データ管理部２１０は、地図データＤＢ２２０を記憶装置に保持するとともに、そのアクセス管理および更新管理を実行する。この地図データ管理部２１０のさらに詳細な構成および動作については、別途、図を参照して詳しく説明する。

前記したように、ナビ処理装置２０は、ＣＰＵと記憶装置とを備えたコンピュータである。従って、ナビ処理装置２０を構成する機能ブロック（次に図２で示す機能ブロックも含む）は、そのＣＰＵが記憶装置に記憶された所定のプログラムを実行することによって実現される。

一方、地図センタ３は、その主要構成要素として、地図センタ処理装置３０を備える。ここで、地図センタ処理装置３０は、図示しないＣＰＵと、メモリやハードディスク装置などの記憶装置と、を含んで構成されたコンピュータから成る。また、地図センタ３は、地図センタ処理装置３０に対する情報の入出力装置として機能する通信装置３１とメディアドライブ３２とを含んで構成される。

ここで、通信装置３１は、通信ネットワーク４に接続する通信インタフェース装置などによって構成され、携帯電話通信網やインターネットなどの通信ネットワーク４および携帯電話通信網の基地局５を介して、カーナビ装置２の通信装置２３との間で所定のデータ通信を行う。また、メディアドライブ３２は、地図センタ処理装置３０から出力される地図データなどをブリッジメディア６に記録する。

また、地図センタ処理装置３０は、その機能ブロックとして、地図ＤＢ管理部３００、地図データ配信部３１０などを含んで構成される。地図ＤＢ管理部３００は、マスタ地図ＤＢ３０１を含んで構成され、そのマスタ地図ＤＢ３０１を構成する個々の地図データを保守・管理する。また、地図データ配信部３１０は、ナビ処理装置２０からの要求に応じて、地図データＤＢ２２０を最新の地図データに更新するための更新データを、ナビ処理装置２０へ配信する。

また、地図センタ処理装置３０は、ＣＰＵと記憶装置とを備えたコンピュータである。従って、地図センタ処理装置３０を構成する機能ブロック（次に図２で示す機能ブロックも含む）は、そのＣＰＵが記憶装置に記憶された所定のプログラムを実行することによって実現される。

なお、図１において、基地局５とカーナビ装置２の通信装置２３との間の無線通信方式は、通常、携帯電話の通信方式が用いられるが、それに限定される必要はなく、ＩＥＥＥ８０２．１１規格の無線ＬＡＮ（Local Area Network）、ＩＥＥＥ８０２．１６規格のＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、専用狭域通信（ＤＳＲＣ：Dedicated Short Range Communication）などに基づくものであってもよい。

さらに、基地局５とカーナビ装置２の通信装置２３との間の通信は、双方向通信でなく、地上波ディジタル放送や衛星ラジオ放送などの放送電波を利用した一方向通信（放送）であってもよい。ただし、本実施形態の以下の説明においては、地図センタ３からカーナビ装置２への更新地図データの提供は、特に断らない限り、携帯電話などの通信方式を利用した双方通信によって行われるものとする。

図２は、本実施形態に係るナビ処理装置２０および地図センタ処理装置３０の詳細な機能ブロックの構成の例を示した図である。図２では、図１の構成要素のうち、ナビ処理装置２０および地図センタ処理装置３０以外の構成要素を省略し、ナビ処理装置２０および地図センタ処理装置３０について、その内部の機能ブロックの構成を詳細に示している。

まず、図２を参照して、地図センタ３の地図センタ処理装置３０を構成する機能ブロックについて説明する。

地図ＤＢ管理部３００は、マスタ地図ＤＢ３０１、更新データ生成部３０２などを含んで構成される。更新データ生成部３０２は、マスタ地図ＤＢ３０１に新しいバージョンの地図データが登録されたとき、古いバージョンの地図データをその新しいバージョンの地図データに更新するための更新データを生成し、生成した更新データを更新データＤＢ３１１に登録する。また、更新データ生成部３０２は、更新データの生成に併せて、その更新データの要約データである更新メタデータを生成し、生成した更新メタデータを更新メタデータＤＢ３１２に登録する。

なお、本実施形態では、更新データ生成部３０２は、更新データを、古いバージョンの地図データに対する新しいバージョンの地図データの差分データとして生成するものとする。ただし、更新データは、差分データでなくてもよい。

ここで、更新データを構成する差分データは、例えば、更新対象となる道路１本ごと、ＰＯＩ１件ごとなど、地図データの更新操作対象の単位ごとに生成され、その生成された単位の差分データを少なくとも１つ以上含んだデータの集合体である。このとき、更新操作対象となる各単位の差分データは、それを地図更新に適用した場合でも、更新後の地図データに矛盾を生じさせないようなひとかたまりの更新操作データとして生成される。

なお、以上のような差分データにより更新される地図データの形状や広さは、マスタ地図ＤＢ３０１に登録されている地図データの区画単位と一致するとは限らない。また、１つの更新データは、道路データ、ＰＯＩデータなど種別が異なるデータを含んでもよい。従って、差分データによる更新データは、一般的には、複数区画の複数種別の地図データを更新対象とする。また、一方では、単一区画の単一種別の地図データに対し、相互に独立した複数の更新データが生成されてもよい。

次に、地図データ配信部３１０は、更新データＤＢ３１１、更新メタデータＤＢ３１２、更新データ配信部３１３、更新メタデータ配信部３１４などを含んで構成される。更新データ配信部３１３は、ナビ処理装置２０からの要求に応じて、その要求で指示されるエリアおよびデータ種別の地図データの更新データをナビ処理装置２０へ配信する。また、更新メタデータ配信部３１４は、ナビ処理装置２０からの要求に応じて、その要求で指示されるエリアおよびデータ種別の地図データの更新メタデータをナビ処理装置２０へ配信する。

続いて、図３を参照して、本実施形態における地図データおよびその更新データの構成について説明しておく。図３は、本実施形態に係る地図データの構成の例を示した図で、（ａ）は、マスタ地図ＤＢ３０１の構成の例、（ｂ）は、更新データの構成の例である。

図３（ａ）に示すように、マスタ地図ＤＢ３０１は、道路データ、背景データ、ＰＯＩデータ、交通データなど複数のデータ種別の地図データにより構成される。ここで、道路データは、道路の位置、形状、接続関係などを表したデータであり、背景データは、その道路の背景となる地物（山、川、公園、建物など）の位置や名称などを表したデータである。また、ＰＯＩデータは、公共施設、娯楽施設、商業店舗などの位置やその付属情報などを表したデータである。また、交通データは、２つの交差点間を結ぶ道路など所定の区間の道路（しばしば、リンクと呼ばれる）のリンク旅行時間、混雑度などを表したデータである。

これらの各データ種別の地図データは、さらに、所定のエリア（例えば、都道府県などの行政区画、所定の大きさの方形の区画（以下、メッシュという）など）ごとのデータに分割される。そして、そのエリアによって分割されたそれぞれの地図データが登録単位となって、マスタ地図ＤＢ３０１に登録される。このとき、マスタ地図ＤＢ３０１に登録される地図データには、その地図データが更新されたときのバージョン番号が付される。

なお、マスタ地図ＤＢ３０１に登録された地図データは、所定の期間、例えば、５年間は削除されない。そのため、マスタ地図ＤＢ３０１には、最新バージョンの地図データだけでなく、５年以内など所定の期間内の過去のバージョンの地図データが混在することになる。

また、データ種別には、そのデータ種別に属する下位のデータ種別（以下、サブ種別という）が設定されていてもよい。例えば、ＰＯＩデータには、サブ種別として、いわゆるカテゴリがある。カテゴリは、ＰＯＩを公共施設、飲食店、スーパー、コンビニなどに分類したものである。また、交通データでは、平日の交通データ、土日の交通データなどのサブ種別を想定することができる。

従って、マスタ地図ＤＢ３０１から登録された地図データの１つを抽出するときには、データ種別とエリアとバージョンとを指定する。その場合、サブデータ種別が設定されているときには、そのサブデータ種別をも指定する。なお、本明細書では、紛れることがない場合には、以下、この登録単位の地図データを、単に、地図データと呼んでいる。

次に、図３（ｂ）に示すように、更新データは、更新データヘッダと更新データボディとにより構成される。ここで、更新データボディは、古いバージョンの地図データを最新バージョンの地図データに更新するための差分データなどにより構成される。また、更新データヘッダは、バージョン番号、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤなどを含んで構成される。

すなわち、更新データボディは、マスタ地図ＤＢ３０１に登録された地図データのそれぞれに対応するように生成される。また、更新データヘッダは、更新データボディの更新対象となる地図データを特定するためのデータ、すなわち、バージョン番号、エリアＩＤ、データ種別ＩＤなどを含んで（必要な場合には、サブ種別ＩＤも含む）構成される。このような更新データヘッダは、更新データボディの内容を簡潔に示したデータでもあるので、本明細書では、更新データヘッダを更新メタデータと呼ぶ。

なお、前記したように、更新データが差分データにより構成される場合には、その差分データが複数区画の複数種別の地図データを更新対象とする場合がある。そこで、差分データが複数区画（複数メッシュ）に渡る地図データを更新対象とする場合には、更新データヘッダのエリアＩＤのフィールドには、その複数区画のエリアＩＤを列記する。また、差分データが複数種別の地図データを更新対象とする場合には、更新データヘッダのデータ種別ＩＤのフィールドには、その複数種別のデータ種別ＩＤを列記する。

以上のように構成された更新データは、更新データ生成部３０２により生成され、更新データＤＢ３１１に登録される。そのとき、それぞれの更新データに対して、適宜、更新データＩＤが付される。なお、その更新データＩＤは、更新データを更新データＤＢ３１１に登録するときのその更新データの名称と考えてもよい。

また、図２において、更新メタデータＤＢ３１２は、更新データの更新データヘッダ部分を登録したデータベースであるが、更新データが更新データヘッダを含んでいるので、更新メタデータＤＢ３１２は、更新データＤＢ３１１の一部を構成するとみなしても差し支えない。ただし、本明細書では、説明の便宜上、更新データＤＢ３１１と更新メタデータＤＢ３１２とは、それぞれ独立して設けられるものとする。その場合、更新メタデータＤＢ３１２において、個々の更新メタデータを識別するときには、その更新メタデータに対応する更新データと同じ更新データＩＤによって識別するものとする。

なお、更新メタデータ配信部３１４は、更新メタデータを配信するときには、以上に説明した更新メタデータ、すなわち、更新データヘッダからなるデータをカーナビ装置２へ配信する。

再び、図２を参照して、カーナビ装置２のナビ処理装置２０を構成する機能ブロックについて説明する。

ナビ処理部２００は、地図描画処理部２０１、経路探索処理部２０２、ロケータ処理部２０３、経路誘導処理部２０４、交通データ処理部２０５、ＰＯＩ探索処理部２０６などを含んで構成される。これらの機能ブロックは、カーナビ装置２の一般的な機能を実現するためのよく知られた機能ブロックであるので、その詳細な説明を省略する。

地図データ管理部２１０は、更新メタデータ取得部２１１、更新データ取得部２１２、地図データ更新処理部２１３、地図データアクセス管理部２１４、地図データ利用状況監視部２１５、地図データ利用予測部２１６、更新対象選択部２１７などの処理機能ブロックと、地図データＤＢ２２０、更新メタデータ記憶部２２１、更新データ記憶部２２２、取得済データ表２２３、地図データ利用状況表２２４、地図データ利用予測表２２５、更新対象選択表２２６などの記憶機能ブロックとを含んで構成される。

更新メタデータ取得部２１１は、例えば、所定の時間が経過するごとに、または、車両７が所定の距離を走行するごとに、地図センタ処理装置３０に対し、更新メタデータの配信を求め、それに応じて地図センタ処理装置３０から配信される更新メタデータを取得する。また、更新メタデータ取得部２１１は、その取得した更新メタデータを更新メタデータ記憶部２２１に格納するとともに、その更新データＩＤなどを取得済データ表２２３に登録する。

更新データ取得部２１２は、地図データ更新処理部２１３の制御の下に、地図センタ処理装置３０に対し、更新データの配信を求め、それに応じて地図センタ処理装置３０から配信される更新データを取得する。また、更新データ取得部２１２は、その取得した更新データを更新データ記憶部２２２に格納するとともに、その更新データＩＤなどを取得済データ表２２３に登録する。

地図データ更新処理部２１３は、更新対象選択表２２６によって更新指示が行われている地図データＤＢ２２０の地図データを更新する。地図データ更新処理部２１３は、その更新に際して、更新対象の地図データの更新データが、更新データ記憶部２２２にある場合には、その更新データにより更新し、更新データ記憶部２２２にない場合には、更新データ取得部２１２に当該更新データの取得を指示し、その指示により取得された更新データによって更新する。

地図データアクセス管理部２１４は、ナビ処理部２００が地図データＤＢ２２０をアクセスするのを支援するとともに、地図データＤＢ２２０を管理する。すなわち、地図データアクセス管理部２１４は、ナビ処理部２００のアプリケーションプログラムによる地図データＤＢ２２０のアクセスを支援する、いわゆる、データベース管理ミドルウエアによって構成されている。

なお、ここでいうアプリケーションプログラムとは、ナビ処理部２００に含まれる地図描画処理部２０１、経路探索処理部２０２、ロケータ処理部２０３、経路誘導処理部２０４、交通データ処理部２０５、ＰＯＩ探索処理部２０６などの機能ブロックを実現するためのプログラムである。本明細書では、アプリケーションプログラムを、アプリケーション、または、アプリと略称する。

地図データ利用状況監視部２１５は、地図データアクセス管理部２１４の動作を監視することにより、どのアプリがどの地図データを利用（つまり、アクセス）しているかを地図データ利用状況表２２４に記録する。

地図データ利用予測部２１６は、地図データ利用状況表２２４により、どのようなアプリがどのような地図データを利用しているかを知ることができるので、そのアプリの地図データの利用状況に基づき、近い将来利用される地図データを予測する。例えば、目的地までの誘導経路が求められ、地図描画アプリが動作しているような場合には、地図データ利用予測部２１６は、その地図描画アプリが、近い将来、その誘導経路に沿ったエリアの地図データを利用するであろうと、予測をすることができる。すなわち、地図データ利用予測部２１６は、このようにして近い将来利用される地図データを予測し、その予測した地図データを識別するデータ（エリアＩＤ、データ種別ＩＤおよびサブ種別ＩＤ）を地図データ予測表２２５に記録する。

更新対象選択部２１７は、地図データ予測表２２５を参照して、多くのアプリにより、より頻度高く利用されることが予測される地図データを選択し、その選択した地図データを更新対象の地図データとして、その地図データの識別データ（エリアＩＤ、データ種別ＩＤおよびサブ種別ＩＤ）を更新対象選択表２２６に記録する。

以上に説明した地図データ管理部２１０の構成およびその動作によれば、地図データＤＢ２２０の地図データは、近い将来ナビ処理部２００により利用されると予測される地図データについては、最新のバージョンの地図データに更新されることになる。逆に、近い将来ナビ処理部２００により利用されないと予測される地図データについては、地図データの更新が行われることはない。従って、地図データの更新は、ナビ処理部２００の動作状況に応じて、過不足なく行われることになる。

続いて、地図データ管理部２１０における各機能ブロックの詳細な動作を、図４〜図７の処理フロー図、および、図８〜図１１の表の構成図を参照しつつ説明する。

図４は、カーナビゲーションシステム１における更新メタデータ配信処理および更新メタデータ取得処理の処理フローの例を示した図で、（ａ）は、地図センタ処理装置３０における更新メタデータ配信スレッドの処理フローの例、（ｂ）は、ナビ処理装置２０における更新メタデータ取得スレッドの処理フローの例である。

更新メタデータ取得スレッドは、ナビ処理装置２０の更新メタデータ取得部２１１の処理に対応し、その更新メタデータ取得スレッドの実行は、ナビ処理装置２０の動作開始とともに開始され、ナビ処理装置２０が動作している間中、継続される。同様に、更新メタデータ配信スレッドは、地図センタ処理装置３０の更新メタデータ配信部３１４の処理に対応し、その更新メタデータ配信スレッドの実行は、地図センタ処理装置３０の動作開始とともに開始され、地図センタ処理装置３０が動作している間中、継続される。

図４に示すように、ナビ処理装置２０のＣＰＵは、所定の更新メタデータ取得条件が満足されたか否かを判定し（ステップＳ０１）、その更新メタデータ取得条件が満足された場合には（ステップＳ０１でＹｅｓ）、更新メタデータ取得処理を実行し（ステップＳ０２）、その更新メタデータ取得条件が満足されない場合には（ステップＳ０１でＮｏ）、ステップＳ０１の判定を繰り返し実行する。

ここで、更新メタデータ取得条件とは、次の５つの条件を想定する。（１）電源が投入されたときなど、ナビ処理装置２０が動作開始したとき、（２）更新メタデータ取得処理を実行後、所定の時間が経過したとき、（３）更新メタデータ取得処理を実行後、車両７が所定の距離を走行したとき、（４）地図センタ３の地図センタ処理装置３０から更新メタデータ取得指示データを受信したとき、（５）ユーザにより、更新メタデータ取得指示データが入力されたとき。

すなわち、これらの５つの条件のうち、いずれか１つが満足されたとき、ナビ処理装置２０のＣＰＵは、更新メタデータ取得処理（ステップＳ０２）を実行する。

ナビ処理装置２０のＣＰＵは、更新メタデータ取得処理（ステップＳ０２）において、まず、更新メタデータ要求に地図データのデータ種別、エリアおよびバージョンを設定する（ステップＳ２１）。このとき、更新メタデータ要求には、複数の地図データのデータ種別、エリアおよびバージョンが設定されてもよい。なお、この場合、データ種別にサブ種別があるときには、サブ種別も設定する（煩雑なので、以下、この「なお書き」は省略する）。

なお、このときエリアは、例えば、次のような条件で設定する。（１）自車位置が含まれるエリアおよびその近隣のエリア、（２）目的地および目的地までの誘導経路が含まれるエリアおよびその近隣のエリア、（３）地図表示中のエリアおよびその近隣のエリア、（４）ＰＯＩ検索処理で検索対象としたエリアなど。なお、更新メタデータのデータ量は小さいので、ここでいう近隣のエリアとしては、数県域にまたがる広い地域を設定してもよい。

また、データ種別は、そのとき動作しているナビ処理部２００のアプリに応じて、適宜選択するようにして設定してもよいが、アプリの動作状況の如何に関わらず、全種別を選択するように設定してもよい。また、このとき設定されるバージョンは、地図データＤＢ２２０に登録されている地図データのバージョンである。

次に、ナビ処理装置２０のＣＰＵは、地図データのデータ種別、エリアおよびバージョンが設定された更新メタデータ要求を、地図センタ処理装置３０へ送信する（ステップＳ２２）。

一方、地図センタ処理装置３０のＣＰＵ（図示せず）は、更新メタデータ配信スレッドの処理で、ナビ処理装置２０から更新メタデータ要求が送信されるのを待っている。すなわち、そのＣＰＵは、更新メタデータ要求を受信したか否かを判定し（ステップＳ３１）、更新メタデータ要求を受信しない場合には（ステップＳ３１でＮｏ）、その判定を繰り返し実行し、また、更新メタデータ要求を受信した場合には（ステップＳ３１でＹｅｓ）、その更新メタデータ要求に含まれるデータ種別、エリアおよびバージョンに対応する更新メタデータを更新メタデータＤＢ３１２から抽出する（ステップＳ３２）。

次に、地図センタ処理装置３０のＣＰＵは、その抽出した更新メタデータをナビ処理装置２０へ配信し（ステップＳ３３）、更新メタデータ要求の受信判定のステップ（ステップＳ３１）へ戻る。

これに対し、ナビ処理装置２０のＣＰＵは、地図センタ処理装置３０から更新メタデータが送信されるのを待っている。すなわち、そのＣＰＵは、更新メタデータを受信したか否かを判定し（ステップＳ２３）、更新メタデータを受信しない場合には（ステップＳ２３でＮｏ）、その判定を繰り返し実行し、また、更新メタデータを受信した場合には（ステップＳ２３でＹｅｓ）、その受信した更新メタデータを更新メタデータ記憶部２２１に格納する（ステップＳ２４）。

次に、ナビ処理装置２０のＣＰＵは、その受信した更新メタデータのエントリ、つまり、更新データＩＤを取得済データ表２２３に登録し（ステップＳ２５）、その処理をステップＳ０１へ戻す。

以上の処理により、ナビ処理装置２０は、更新データのボディデータに先立って、更新メタデータを取得することができる。なお、更新メタデータの配信および取得の処理は、図４の処理フローに限定される必要はなく、所定の地域に含まれるエリアの全種別の更新地図データを、例えば、地上ディジタル放送などを用いて、地図センタ３からカーナビ装置２へ放送するようなものであってもよい。

図８は、取得済データ表２２３の構成の例を示した図である。取得済データ表２２３のレコードは、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、バージョン、更新データＩＤ、ボディデータ取得状況の各フィールドを含んで構成されている。すなわち、取得済データ表２２３は、更新メタデータが取得され、更新メタデータ記憶部２２１に格納済であることを表し、また、そのボディデータ取得状況フィールドの“１”は、更新データボディが取得され、更新データ記憶部２２２に格納済であることを表している。

なお、更新メタデータ記憶部２２１において、個々の更新メタデータは、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、バージョンのデータを含んでおり、更新データＩＤにより識別可能であるので、取得済データ表２２３は、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、バージョンの各フィールドを含まないとしてもよい。

図５は、ナビ処理装置２０における地図更新管理メインスレッドの処理フローの例を示した図である。このスレッドでは、ナビ処理装置２０のＣＰＵは、地図データＤＢ２２０の地図データの利用状況を監視しつつ、その後の利用状況を予測し、その予測を含めた利用状況に基づき、その地図データを更新する。以下、その処理フローの説明を、表の説明を差し挟みつつ行う。

ナビ処理装置２０のＣＰＵ（図５の説明では、以下、単に、ＣＰＵという）は、地図データアクセス管理部２１４の処理として、地図データＤＢ２２０における地図データの利用状況を監視し、地図データ利用状況表２２４を作成する（ステップＳ１１）。

図９は、地図データ利用状況表２２４の構成の例を示した図である。図９に示すように、地図データ利用状況表２２４のレコードは、アプリＩＤ、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、バージョン、得点の各フィールドを含んで構成されている。

ここで、アプリＩＤは、地図データを利用しているアプリの識別データであり、この場合のアプリとは、ナビ処理部２００のいずれかの機能ブロックを実現するためのプログラムである。また、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、サブ種別ＩＤは、地図データＤＢ２２０における個別の地図データを識別するデータであり、バージョンは、その地図データに付されたバージョン番号である。また、得点は、その地図データ利用の重要度を示す値であり、あらかじめアプリごとに定められているものとする。

すなわち、ＣＰＵは、ステップＳ１１においては、地図データアクセス管理部２１４が地図データＤＢ２２０の地図データのアクセスマクロなどを実行したことを検出することにより、現在、どのアプリがどの地図データを利用しているかという地図データ利用状況の一覧表、つまり、地図データ利用状況表２２４を作成するのである。なお、ステップＳ１１の詳細な処理の内容については、別途、図６を用いて説明する。

図５の説明に戻る。ステップＳ１１に引き続いて、ＣＰＵは、地図データ利用予測部２１６の処理として、そのとき地図データを利用中のアプリについて、そのアプリのその後の地図データの利用予定を予測し、地図データ利用予測表２２５を作成する（ステップＳ１２）。

地図データ利用の予測については、後記するところによるが、例えば、経路誘導処理（誘導アプリ）が実行されているような場合には、目的地および目的地までの誘導経路を含む地図データは、その後高い確率で利用されることが予測される。同様にして、それぞれのアプリについて、近い将来に利用される地図データを予測する。

そこで、ＣＰＵは、そのとき動作中の各アプリについて、そのアプリに応じた地図データのデータ種別とエリアとを予測し、図９の地図データ利用状況表２２４と同様の地図データ利用予測中間表（図２に図示せず）を作成する。なお、地図データ利用状況表２２４と地図データ利用予測中間表との違いは、地図データ利用状況表２２４がナビ処理装置２０における現況のデータを表しているのに対し、地図データ利用予測中間表のデータは予測したデータであることである。そして、ＣＰＵは、地図データ利用状況表２２４と地図データ利用予測中間表とを統合して地図データ利用予測表２２５を作成する。

図１０は、地図データ利用予測表２２５の構成の例を示した図である。図１０に示すように、地図データ利用予測表２２５のレコードは、地図データ利用状況表２２４のレコードと同様に、アプリＩＤ、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、バージョン、得点の各フィールドを含んで構成されている。ただし、地図データ利用予測表２２５の場合には、アプリＩＤのフィールドには、複数のアプリＩＤを入れることができる。

すなわち、地図データ利用予測表２２５のレコードは、地図データ利用状況表２２４および地図データ利用予測中間表のレコードを地図データの識別データ（エリアＩＤ、データ種別ＩＤおよびサブ種別ＩＤ）でソートし、地図データの同じ識別データのレコードを１つのレコードに統合したものである。そのソートした複数のレコードを統合するに際しては、地図データの同じ識別データに対し、アプリＩＤフィールド内容が異なるレコードがあった場合には、地図データ利用予測表２２５のレコードのアプリＩＤのフィールドには、その異なるアプリＩＤをすべて列記する。また、地図データ利用予測表２２５の得点フィールドには、地図データの同じ識別データに対しソートされたレコードの得点フィールドの値をすべて加算した値が入れられる。

つまり、地図データ利用予測表２２５は、エリアＩＤ、データ種別ＩＤおよびサブ種別ＩＤで識別される地図データが、現在および近い将来、どのアプリでどの程度の頻度（得点）で利用されるかを示した表であるといえる

再び、図５の説明に戻る。ステップＳ１２に引き続いて、ＣＰＵは、更新対象選択部２１７の処理として、地図データ利用予測表２２５と取得済データ表２２３とに基づき、更新対象選択表２２６を作成する（ステップＳ１３）。すなわち、ＣＰＵは、地図データ利用予測表２２５と取得済データ表２２３とを参照して、利用頻度の大きい地図データで、最新バージョンに更新されていない地図データを選択するための更新対象選択表２２６を作成する。

図１１は、更新対象選択表２２６の構成の例を示した図である。図１１に示すように、更新対象選択表２２６のレコードは、エリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、バージョン、得点、メタデータ取得状況、更新データＩＤ、ボディデータ取得状況、更新データ取得要求、更新執行要求の各フィールドを含んで構成されている。

ここで、前半のエリアＩＤ、データ種別ＩＤ、サブ種別ＩＤ、バージョンのフィールドは、地図データ利用予測表２２５から得られるデータであり、地図データ利用予測表２２５のレコードで得点のフィールドが所定の値以上のものを取り出したものである。また、後半のメタデータ取得状況、更新データＩＤ、ボディデータ取得状況、更新データ取得要求、更新執行要求のフィールドは、地図データ利用予測表２２５のデータに取得済データ表２２３のデータを付加および加味したデータである。

これらのフィールドの中で、更新執行要求のフィールドは、地図データＤＢ２２０に登録されている地図データの更新を求めるフラグが格納され、そのフラグは、更新メタデータが取得されていない場合（メタデータ取得状況が“０”）、または、更新メタデータが取得され、その取得済の更新メタデータのバージョン（取得済データ表２２３のバージョン）が地図データＤＢ２２０に登録されている地図データのバージョン（更新対象選択表のバージョン）よりも新しい場合、更新執行“要”となる。

再び、図５の説明に戻る。ステップＳ１３に引き続いて、ＣＰＵは、地図データ更新処理部２１３の処理として、以下のステップを実行する。すなわち、ＣＰＵは、更新対象選択表２２６の更新執行要求フィールドを参照して、更新執行“要”の地図データがあるか否かを判定する（ステップＳ１４）。更新執行“要”の地図データがなかった場合には（ステップＳ１４でＮｏ）、ＣＰＵは、その処理をステップＳ１１へ戻す。また、更新執行“要”の地図データがあった場合には（ステップＳ１４でＹｅｓ）、ＣＰＵは、更新対象選択表２２６の更新データ取得要求フィールドを参照して、更新データ取得が必要か否かを判定する（ステップＳ１５）。

その判定の結果、更新データ取得が必要であった場合には（ステップＳ１５でＹｅｓ）、ＣＰＵは、更新データ取得部２１２の処理として、地図センタ処理装置３０から更新データの配信（ステップＳ０４）を受け、更新データ取得処理を実行する（ステップＳ１６）。なお、更新データ取得処理で取得した更新データは、更新データ記憶部２２２に格納される。また、更新データ取得処理の詳細については、別途、図７を用いて説明する。

一方、更新データ取得が必要でなかった場合には（ステップＳ１５でＮｏ）、ＣＰＵは、更新データ取得処理（ステップＳ１６）をスキップした上で、更新データ記憶部２２２に格納されている更新データを用いて、地図データＤＢ２２０の地図データを更新する（ステップＳ１７）。

次に、ＣＰＵは、ステップＳ１７で更新した更新データとその更新データに対応する更新メタデータとを、更新データ記憶部２２２と更新メタデータ記憶部２２１とから削除し（ステップＳ１８）、さらに、その更新データと更新メタデータとの登録を取得済データ表２２３から削除する（ステップＳ１９）。

図６は、カーナビゲーションシステム１における更新データ配信処理および更新データ取得処理の処理フローの例を示した図で、（ａ）は、地図センタ処理装置３０における更新データ配信スレッドの処理フローの例（ｂ）は、ナビ処理装置２０における地図更新管理メインスレッド中の更新データ取得処理（ステップＳ１６）の詳細な処理フローの例である。

ナビ処理装置２０のＣＰＵは、更新データ取得処理を開始すると、更新対象選択表２２６を参照して、更新データＩＤが既知であるか否かを判定する（ステップＳ４１）。なお、更新メタデータが取得されている場合、更新データＩＤは既知である。

そこで、ナビ処理装置２０のＣＰＵは、更新データＩＤが既知でない場合（ステップＳ４１でＮｏ）、更新データ要求に、更新対象の地図データのデータ種別、エリア、バージョンを設定する（ステップＳ４２）。ここで、データ種別にサブ種別がある場合には、サブ種別も設定する。一方、ナビ処理装置２０のＣＰＵは、更新データＩＤが既知である場合（ステップＳ４１でＹｅｓ）、更新データ要求に、更新対象の地図データの更新データＩＤを設定する（ステップＳ４３）。

次に、ナビ処理装置２０のＣＰＵは、以上のようにして設定した更新データ要求を地図センタ処理装置３０へ送信する（ステップＳ４４）。

これに対し、地図センタ処理装置３０のＣＰＵは、更新データ配信スレッドの処理で、ナビ処理装置２０から更新データ要求が送信されるのを待っている。すなわち、そのＣＰＵは、更新データ要求を受信したか否かを判定し（ステップＳ５１）、更新データ要求を受信しない場合には（ステップＳ５１でＮｏ）、その判定を繰り返し実行し、また、更新データ要求を受信した場合には（ステップＳ５１でＹｅｓ）、その更新データ要求に含まれる更新データＩＤ、または、データ種別、エリアおよびバージョンの組に対応する更新データを更新データＤＢ３１１から抽出する（ステップＳ５２）。

次に、地図センタ処理装置３０のＣＰＵは、以上のようにして抽出した更新データをナビ処理装置２０へ配信し（ステップＳ５３）、更新データ要求の受信判定のステップ（ステップＳ５１）へ戻る。

これに対し、ナビ処理装置２０のＣＰＵは、地図センタ処理装置３０から更新データが送信されるのを待っている。すなわち、そのＣＰＵは、更新データを受信したか否かを判定し（ステップＳ４５）、更新データを受信しない場合には（ステップＳ４５でＮｏ）、その判定を繰り返し実行し、また、更新データを受信した場合には（ステップＳ４５でＹｅｓ）、その受信した更新データを更新データ記憶部２２２に格納する（ステップＳ４６）。

次に、ナビ処理装置２０のＣＰＵは、その受信した更新データのエントリを取得済データ表２２３に登録し（ステップＳ４７）、更新データ取得処理を終了する。なお、更新データのエントリを取得済データ表２２３に登録するとは、ここでは、取得済データ表２２３のボディデータ取得状況のフィールドを“１”にすることを意味する。

図７は、地図データ利用状況表２２４の作成処理（ステップＳ１１）の詳細な処理フローの例を示した図である。図６に示すように、地図データ利用状況表２２４の作成処理は、（ａ）地図データ利用登録処理のスレッドと、（ｂ）地図データ利用登録削除処理のスレッドと、により構成される。

ＣＰＵは、（ａ）地図データ利用登録処理では、地図データアクセス管理部２１４による地図データＤＢ２２０への参照要求があるか否かを監視し（ステップＳ６１）、参照要求があったときには（ステップＳ６１でＹｅｓ）、その参照要求したアプリのアプリＩＤを取得し（ステップＳ６２）、併せて、その参照された地図データのデータ種別ＩＤ、（あれば、サブ種別ＩＤも含む）、エリアＩＤを取得する（ステップＳ６３）。そして、ＣＰＵは、取得したデータ種別ＩＤ、（あれば、サブ種別ＩＤも含む）、エリアＩＤをアプリＩＤに対応付けて、地図データ利用状況表２２４に登録する（ステップＳ６４）。

また、ＣＰＵは、（ｂ）地図データ利用登録削除処理では、地図データアクセス管理部２１４による地図データのメモリ開放要求があるか否かを監視し（ステップＳ７１）、その開放要求された地図データのデータ種別ＩＤ、（あれば、サブ種別ＩＤも含む）、エリアＩＤを取得し（ステップＳ７２）、併せて、その開放要求を発行したアプリのアプリＩＤを取得する（ステップＳ７３）。そして、ＣＰＵは、その開放要求を発行したアプリでの当該地図データの利用登録を、地図データ利用状況表２２４から削除する（ステップＳ７４）。なお、利用登録の削除は、メモリの開放要求後すぐに行うのではなく、所定の時間（例えば、１分など）経過後、行うようにしてもよい。

以上のように、地図データは、地図データＤＢ２２０への参照要求があったときに、ＲＡＭなどの高速メモリ（以下、キャッシュメモリという）上にロードされ、そのキャッシュメモリの開放要求があるまで、そのキャッシュメモリ上に保持される。ただし、複数のアプリにより多重に参照要求されたときには、そのすべてのアプリから開放要求を受けるまで、キャッシュメモリ上に保持される。従って、地図データ利用状況表２２４は、キャッシュメモリに保持されている地図データとその地図データの参照要求を発行したアプリの一覧といえる。

図１２は、ナビ処理装置のアプリが利用中の地図の範囲の例を示した図で、（ａ）は、描画アプリが利用中の地図の範囲の例、（ｂ）は、誘導アプリが利用中の地図の範囲の例を示した図である。

図１２（ａ）において、方眼の１区画は、地図データの単位となるメッシュを示し、例えば、１０ｋｍ四方のエリアであるとする。そして、そのメッシュには、横方向および縦方向にそれぞれ０〜ｆの数（１６進数）によって識別されるアドレスが付されているものとする。こととき、自車は、黒三角の位置（アドレス“５３”のメッシュ）、目的地は、旗マークの位置（アドレス“ｃｄ”のメッシュ）に位置し、自車位置から目的地まで実曲線のような誘導経路が求められているとする。なお、これらの前提は、図１２（ｂ）、図１３において同じ。

ナビ処理装置２０がユーザの求め（ユーザが入力するデータ）に応じて、自車位置を含む太線部分の地図を画面表示するときには、地図描画処理部２０１（描画アプリ）は、地図データアクセス管理部２１４に対し、通常、その画面表示部分よりやや広い部分の地図データの参照要求を発行する。すなわち、描画アプリは、図１２（ａ）斜線部のメッシュについて、地図データの参照要求を発行する。従って、その斜線部のメッシュの地図データは、キャッシュメモリにロードされるとともに、地図データ利用状況表２２４に利用登録される。

また、経路誘導処理部２０４（誘導アプリ）は、誘導経路を含むメッシュ（図１２（ｂ）の斜線部）について、地図データの参照要求を発行する。従って、その斜線部のメッシュの地図データは、キャッシュメモリにロードされるとともに、地図データ利用状況表２２４に利用登録される。同様に、経路探索処理部２０２（探索アプリ）、ロケータ処理部２０３（ロケータアプリ）、交通データ処理部２０５（交通データアプリ）、ＰＯＩ探索処理部２０６（ＰＩＯアプリ）についても、それぞれ、適宜、必要な地図データの参照要求を発行するので、参照要求された地図データは、キャッシュメモリにロードされるとともに、地図データ利用状況表２２４に利用登録される。

図１３は、ナビ処理装置のアプリが利用予定の地図の範囲の例を示した図で、（ａ）は、誘導経路が求められているとき、描画アプリが利用予定の地図の範囲の例、（ｂ）は、誘導経路が求められていないとき、描画アプリが利用予定の地図の範囲の例である。

図１３（ａ）に示すように、目的地までの誘導経路が求められている場合には、描画アプリが、近い将来、その誘導経路を含むメッシュおよびその近隣のメッシュの地図データを利用すると、容易に予測できる。そこで、誘導経路を含むメッシュおよびその近隣のメッシュの地図データを描画アプリの利用予測地図データとする。これに対し、誘導経路が求められていない場合には、図１３（ｂ）に示すように、自車進行方向の前方に位置するメッシュの地図データを、描画アプリの利用予測地図データとする。

同様に、他のアプリにおいても、目的地までの誘導経路が求められている場合には、その誘導経路を含むメッシュおよびその近隣のメッシュの地図データを利用予測地図データとし、誘導経路が求められていない場合には、自車進行方向の前方に位置するメッシュの地図データを利用予測地図データとすることができる。

その場合、例えば、探索アプリでは、利用予定地図データとして自車位置から目的地に至る経路の幅広いエリアの地図データを選択してもよく、また、誘導アプリなどでは、誘導経路が求められていない場合には、利用予定地図データは、不明（存在しない）などとしてもよい。

以上のようにしてアプリごとに利用予定が定められた地図データは、地図データ利用予測中間表（図示省略）に登録され、その後、地図データ利用状況表２２４と併せて、地図データ利用予測表２２６に統合される。

以上、本実施形態によれば、ナビ処理装置２０は、地図データ利用状況監視部２１５の処理により、どのアプリによりどの地図データが利用されているかを把握し、さらに、地図データ利用予測部２１６の処理により、近い将来どの地図データが必要になるかを予測することができる。従って、ナビ処理装置２０は、地図データの更新をするに際し、近い将来必要となる地図データについてのみ更新し、当面必要でない地図データについては更新しないようにすることができる。つまり、ナビ処理装置２０にとって、過不足のない更新が可能となる。

また、ナビ処理装置２０は、更新メタデータ取得部２１１の処理によって、更新データを取得するのに先行して、更新メタデータを取得しているので、そのメタデータの内容に基づき、取得済の更新データを改めて取得することを回避することができるので、地図データの更新を必要最小な場合に限定することができるようになる。

本発明の実施形態に係るカーナビゲーションシステムの構成の例を示した図。 本実施形態に係るナビ処理装置および地図センタ処理装置の詳細な機能ブロックの構成の例を示した図。 本実施形態に係る地図データの構成の例を示した図。 カーナビゲーションシステムにおける更新メタデータ配信処理および更新メタデータ取得処理の処理フローの例を示した図。 ナビ処理装置における地図更新管理メインスレッドの処理フローの例を示した図。 カーナビゲーションシステムおける更新データ配信処理および更新データ取得処理の処理フローの例を示した図。 図データ利用状況表の作成処理の詳細な処理フローの例を示した図。 取得済データ表の構成の例を示した図。 地図データ利用状況表の構成の例を示した図。 地図データ利用予測表の構成の例を示した図。 更新対象選択表の構成の例を示した図。 ナビ処理装置のアプリが利用中の地図の範囲の例を示した図。 ナビ処理装置のアプリが利用予定の地図の範囲の例を示した図。

符号の説明

１ カーナビゲーションシステム
２ カーナビ装置
３ 地図センタ
４ 通信ネットワーク
５ 基地局
６ ブリッジメディア
７ 車両
２０ ナビ処理装置
２１ ＧＰＳ受信機
２２ 表示装置
２３ 通信装置
２４ メディアドライブ
３０ 地図センタ処理装置
３１ 通信装置
３２ メディアドライブ
２００ ナビ処理部
２０１ 地図描画処理部
２０２ 経路探索処理部
２０３ ロケータ処理部
２０４ 経路誘導処理部
２０５ 交通データ処理部
２０６ ＰＯＩ探索処理部
２１０ 地図データ管理部
２１１ 更新メタデータ取得部
２１２ 更新データ取得部
２１３ 地図データ更新処理部
２１４ 地図データアクセス管理部
２１５ 地図データ利用状況監視部
２１６ 地図データ利用予測部
２１７ 更新対象選択部
２２０ 地図データＤＢ
２２１ 更新メタデータ記憶部
２２２ 更新データ記憶部
３００ 地図ＤＢ管理部
３０１ マスタ地図ＤＢ
３０２ 更新データ生成部
３１０ 地図データ配信部
３１１ 更新データＤＢ
３１２ 更新メタデータＤＢ
３１３ 更新データ配信部
３１４ 更新メタデータ配信部

Claims (6)

1. 各道路の識別情報、位置情報およびその接続関係情報を含んでなるエリアごとの道路データと、各施設の名称、位置情報および付属情報を含んでなるエリアごとの施設データと、各道路の旅行時間および渋滞情報を含んでなるエリアごとの交通データと、をデータ種別として識別して含む地図データにより構成されたカーナビゲーション用の地図を保持した記憶手段と、
   マスタ地図を保管した地図センタから配信される前記地図を更新する更新データを用いて、前記記憶手段に保持した地図を前記エリアおよび前記データ種別ごとに更新する地図管理装置と、
   カーナビゲーションのアプリケーションを実行するナビゲーション処理装置と、
   を含んで構成されたカーナビゲーション装置における地図データ更新方法であって、
   前記地図管理装置が、
   前記地図センタから配信される更新データの内容を要約したデータである、前記更新データの識別情報と、前記更新データに含まれる地図データのエリア、データ種別およびバージョンを示す情報と、を含んでなるメタデータを取得するとともに、前記取得したメタデータに対応付けて前記更新データの取得状況を表す情報である取得済データ表を作成するメタデータ取得ステップと、
   前記ナビゲーション処理装置で実行中のアプリケーションにより利用されている地図データのエリアおよびデータ種別の利用状況の監視結果に基づき、将来利用予定のエリアおよびデータ種別の地図データを予測する地図データ利用予測ステップと、
   前記地図データ利用予測ステップで予測したエリアおよびデータ種別の地図データの中から利用頻度が高いと予測されるエリアおよびデータ種別の地図データ選択し、さらに、その選択した地図データと、前記取得済データ表で取得済でないことが表されている地図データとに基づき、更新対象の地図データを選択する更新対象選択ステップと、
   前記更新対象選択ステップで選択した更新対象の地図データについて、その更新データの配信を前記地図センタに求め、その求めに応じて前記地図センタから配信される更新データを取得するとともに、前記取得済データ表において前記取得した更新データのメタデータに対応付けられた更新データの取得状況の情報を取得済にする更新データ取得ステップと、
   前記取得した更新データを用いて、前記記憶手段に保持した地図を更新する地図データ更新ステップと、
   を実行すること
   を特徴とする地図データ更新方法。
2. 前記地図管理装置は、
   前記処理装置の動作を開始したとき、前記メタデータを最後に取得してから所定の時間が経過したとき、前記メタデータを最後に取得してから車両が所定の距離を走行したとき、前記地図センタから配信された所定のメタデータ取得指示データを受信したとき、および、所定のメタデータ取得指示データの入力を受け付けたとき、のうちの少なくとも１つの条件に適合したときに、前記メタデータ取得ステップを実行すること
   を特徴とする請求項２に記載の地図データ更新方法。
3. 各道路の識別情報、位置情報およびその接続関係情報を含んでなるエリアごとの道路データと、各施設の名称、位置情報および付属情報を含んでなるエリアごとの施設データと、各道路の旅行時間および渋滞情報を含んでなるエリアごとの交通データと、をデータ種別として識別して含む地図データにより構成されたカーナビゲーション用の地図を保持した記憶手段と、
   マスタ地図を保管した地図センタから配信される前記地図を更新する更新データを用いて、前記記憶手段に保持した地図を前記エリアおよび前記データ種別ごとに更新する地図管理装置と、
   カーナビゲーションのアプリケーションを実行するナビゲーション処理装置と、
   を含んで構成されたカーナビゲーション装置における地図データ更新プログラムであって、
   前記地図管理装置に、
   前記地図センタから配信される更新データの内容を要約したデータである、前記更新データの識別情報と、前記更新データに含まれる地図データのエリア、データ種別およびバージョンを示す情報と、を含んでなるメタデータを取得するとともに、前記取得したメタデータに対応付けて前記更新データの取得状況を表す情報である取得済データ表を作成するメタデータ取得ステップと、
   前記ナビゲーション処理装置で実行中のアプリケーションにより利用されている地図データのエリアおよびデータ種別の利用状況の監視結果に基づき、将来利用予定のエリアおよびデータ種別の地図データを予測する地図データ利用予測ステップと、
   前記地図データ利用予測ステップで予測したエリアおよびデータ種別の地図データの中から利用頻度が高いと予測されるエリアおよびデータ種別の地図データ選択し、さらに、その選択した地図データと、前記取得済データ表で取得済でないことが表されている地図データとに基づき、更新対象の地図データを選択する更新対象選択ステップと、
   前記更新対象選択ステップで選択した更新対象の地図データについて、その更新データの配信を前記地図センタに求め、その求めに応じて前記地図センタから配信される更新データを取得するとともに、前記取得済データ表において前記取得した更新データのメタデータに対応付けられた更新データの取得状況の情報を取得済にする更新データ取得ステップと、
   前記取得した更新データを用いて、前記記憶手段に保持した地図を更新する地図データ更新ステップと、
   を実行させるための地図データ更新プログラム。
4. 前記地図管理装置に、
   前記処理装置の動作を開始したとき、前記メタデータを最後に取得してから所定の時間が経過したとき、前記メタデータを最後に取得してから車両が所定の距離を走行したとき、前記地図センタから配信された所定のメタデータ取得指示データを受信したとき、および、所定のメタデータ取得指示データの入力を受け付けたとき、のうちの少なくとも１つの条件に適合したときに、前記メタデータ取得ステップを実行させること
   を特徴とする請求項３に記載の地図データ更新プログラム。
5. 各道路の識別情報、位置情報およびその接続関係情報を含んでなるエリアごとの道路データと、各施設の名称、位置情報および付属情報を含んでなるエリアごとの施設データと、各道路の旅行時間および渋滞情報を含んでなるエリアごとの交通データと、をデータ種別として識別して含む地図データにより構成されたカーナビゲーション用の地図を保持した記憶手段と、
   マスタ地図を保管した地図センタから配信される前記地図を更新する更新データを用いて、前記記憶手段に保持した地図を前記エリアおよび前記データ種別ごとに更新する地図管理装置と、
   カーナビゲーションのアプリケーションを実行するナビゲーション処理装置と、
   を含んで構成されたカーナビゲーション装置であって、
   前記地図管理装置が、
   前記地図センタから配信される更新データの内容を要約したデータである、前記更新データの識別情報と、前記更新データに含まれる地図データのエリア、データ種別およびバージョンを示す情報と、を含んでなるメタデータを取得するとともに、前記取得したメタデータに対応付けて前記更新データの取得状況を表す情報である取得済データ表を作成するメタデータ取得手段と、
   前記ナビゲーション処理装置で実行中のアプリケーションにより利用されている地図データのエリアおよびデータ種別の利用状況の監視結果に基づき、将来利用予定のエリアおよびデータ種別の地図データを予測する地図データ利用予測手段と、
   前記地図データ利用予測手段で予測したエリアおよびデータ種別の地図データの中から利用頻度が高いと予測されるエリアおよびデータ種別の地図データ選択し、さらに、その選択した地図データと、前記取得済データ表で取得済でないことが表されている地図データとに基づき、更新対象の地図データを選択する更新対象選択手段と、
   前記更新対象選択手段で選択した更新対象の地図データについて、その更新データの配信を前記地図センタに求め、その求めに応じて前記地図センタから配信される更新データを取得するとともに、前記取得済データ表において前記取得した更新データのメタデータに対応付けられた更新データの取得状況の情報を取得済にする更新データ取得手段と、
   前記取得した更新データを用いて、前記記憶手段に保持した地図を更新する地図データ更新手段と、
   を備えたこと
   を特徴とするカーナビゲーション装置。
6. 前記地図管理装置は、
   前記処理装置の動作を開始したとき、前記メタデータを最後に取得してから所定の時間が経過したとき、前記メタデータを最後に取得してから車両が所定の距離を走行したとき、前記地図センタから配信された所定のメタデータ取得指示データを受信したとき、および、所定のメタデータ取得指示データの入力を受け付けたとき、のうちの少なくとも１つの条件に適合したときに、前記メタデータ取得手段により、前記メタデータを取得し、前記取得済データ表を作成すること
   を特徴とする請求項５に記載のカーナビゲーション装置。

Images