(57)【要約】      （修正有）【課題】ナビゲーション装置において使用するための更新タイミングが改善された地図データを生成する。【解決手段】エンドユーザは、地図誤りに対する訂正を直接装置上に入力できる。装置は、訂正の外部処理なしで訂正を使用できる。従って、エンドユーザは、単にウェブリンクを介して誤りを地図メーカに報告して、その地図メーカが誤りを検証し、地図を更新し且つ更新データをエンドユーザに供給することを待つ必要がない。それが完了するのにかかる周期は、数ヶ月及び時には数年である。ナビゲーション装置は、訂正を迅速に使用できる。エンドユーザは、他のエンドユーザと訂正を共有でき、また訂正を集約し、検査し且つ配信する共有リモートサーバとも訂正を共有できる。【選択図】図２
2014055962.tif 000002
【特許請求の範囲】
【請求項１】
地図データを変更する方法であって、
少なくとも１つの地図変更をメモリに格納するステップと；
前記少なくとも１つの地図変更を第１の地図と組み合わせ、第２の地図を作成するステップと；
前記第２の地図をナビゲーション装置にロードするステップとを有することを特徴とする方法。
【請求項２】
更に、前記ナビゲーション装置によってルートを計画するステップと；
前記少なくとも１つの地図変更が前記ルートに沿った変更であるか否かを判定するステップとを含むことを特徴とする請求項１記載の方法。
【請求項３】
前記少なくとも１つの地図変更が前記ルートに沿った変更である場合、前記ルートを前記ナビゲーション装置に格納することを特徴とする請求項２記載の方法。
【請求項４】
更に、前記第２の地図によって前記ナビゲーション装置を動作させるステップ；
前記第１の地図及び前記第２の地図をナビゲーション装置に格納するステップを含むことを特徴とする請求項３記載の方法。
【請求項５】
更に、前記地図変更の数を手動操作により制限するステップを含むことを特徴とする請求項１記載の方法。
【請求項６】
前記地図変更はコミュニティカテゴリを含むことを特徴とする請求項５記載の方法。
【請求項７】
前記地図変更は情報源カテゴリを含むことを特徴とする請求項５記載の方法。
【請求項８】
前記地図変更は場所カテゴリを含むことを特徴とする請求項５記載の方法。
【請求項９】
前記地図変更は妥当性カテゴリを含むことを特徴とする請求項５記載の方法。
【請求項１０】
前記地図変更は重要度カテゴリを含むことを特徴とする請求項５記載の方法。
【請求項１１】
前記地図変更はＰＯＩカテゴリを含むことを特徴とする請求項５記載の方法。
【請求項１２】
前記地図変更は言語カテゴリを含むことを特徴とする請求項５記載の方法。
【請求項１３】
前記地図変更は地図供給元カテゴリを含むことを特徴とする請求項５記載の方法。
【請求項１４】
前記動作させるステップは、前記第１の地図によってルート計画を実行するステップを更に含むことを特徴とする請求項１記載の方法。
【請求項１５】
更に、前記ルートが少なくとも１つの変更を含むという指示を生成するステップを含むことを特徴とする請求項１４記載の方法。
【請求項１６】
前記指示は、音声指標、画像指標及び触覚指標のうち少なくとも１つを含むことを特徴とする請求項１５記載の方法。
【請求項１７】
前記動作させるステップは、目的地までのルートを計算するステップを更に含むことを特徴とする請求項１記載の方法。
【請求項１８】
前記動作させるステップは、前記第１の地図をレンダリングするステップを更に含むことを特徴とする請求項１記載の方法。
【請求項１９】
前記動作させるステップは、ルートに基づく音声指示を生成することを更に含むことを特徴とする請求項１４記載の方法。
【請求項２０】
更に、テキストによって前記第１の地図に印を付けるステップを含むことを特徴とする請求項１記載の方法。
【請求項２１】
更に、前記テキストを視覚表示するステップを含むことを特徴とする請求項２０記載の方法。
【請求項２２】
更に、前記テキストを可聴表現するステップを含むことを特徴とする請求項２０記載の方法。
【請求項２３】
更に、前記地図変更をリモート装置へ送信するステップを含むことを特徴とする請求項１記載の方法。
【請求項２４】
更に、前記地図変更を編集するステップを含むことを特徴とする請求項１記載の方法。
【請求項２５】
更に、前記地図変更を削除するステップを含むことを特徴とする請求項１記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ナビゲーション装置において使用するための改善された地図データを生成する方法に関する。ナビゲーション装置は、ＧＰＳを使用する電子パーソナルナビゲーション装置を含む。
【背景技術】
【０００２】
TomTom International BVのGOTMのようなＧＰＳを使用するパーソナルナビゲーション装置等の電子ナビゲーション装置のための地図データは、Tele Atlas NV等の地図専門メーカから得られる。特に、この地図データは、一般にＧＰＳシステムからの場所データを使用するルートガイダンスアルゴリズムにより使用されるように設計される。例えば、道路は線、すなわちベクトル（例えば、道路の始点、終点、方向であり、道路全体は、各々が始点／終点方向パラメータにより一意に規定される数百の区間から構成される）として記述される。地図は、そのような道路ベクトルの集合であり、データは、各ベクトル（制限速度；移動方向等）、地点情報（point of interest;ＰＯＩ）、道路名、公園の境界や川の境界等の他の地理的特徴と関連付けられ、それらは全てベクトルに関して規定される。全ての地図の特徴（例えば、道路ベクトル、ＰＯＩ等）は、一般にＧＰＳ座標系に対応するか又は関連する座標系で規定され、ＧＰＳシステムを介して判定される装置の位置を地図に示される関連道路に配置することを可能にし、目的地までの最適なルートの計画を可能にする。
【０００３】
この地図データベースを構築するために、Tele Atlasは、英国の道路のOrdnance Survey等の種々の情報源からの基本的な道路情報から開始する。更にTele Atlasは、道路を走る車両専用の大きなチーム、並びに他の地図及び空中写真を調査する担当者を有し、自身のデータを更新及び調査する。このデータがTele Atlas地図データベースの中核を構成する。この地図データベースは、地理参照データにより継続的に向上されている。これは、１年に４回調査され、TomTomのような装置製造業者に公表される。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
莫大な量の情報源がそれらの地図の更新及び検証に使用されているにも関わらず、ある地理的領域に対するデータは１年以上古い可能性がある。
【０００５】
上述の継続した改善に加え、エンドユーザは、Tele Atlasのウェブサイトを使用してTele Atlasに地図の誤りを直接報告できる。このように、TomTomのような装置製造業者は、ユーザから地図誤りレポートを入手及び転送する。一般に、これらの誤りレポートは単にフリーテキスト形式であるため、誤りが実際に意味すること及びそれらが関連する正確な場所について解決するのに相当な労力が費やされる必要がある。実際の誤りとして確認されると、適切な訂正が検査され、今後の地図のリリースに含まれる。最終的に訂正は、最初に通知されてから１年以上後でエンドユーザの装置において見つけられるか又は全く見つけられない場合もある。
【０００６】
ＧＰＳ衛星ナビゲーション装置を使用して計画され且つ行なわれた行程の「トレース」を格納することは周知である（例えば、ALK Technologies of Princeton, USAにより提供される「GPS track submission」機能性を参照）。このトレースは、ジオコードデータを使用して車両がとった完全なルートのレコードである。ユーザはこのトレースデータを装置のメーカに送出でき、そのデータは地図データベースの正確度及び完全性を向上するために使用される。例えば、道路又は曲がり角の厳密な位置は装置により使用される地図上で正確に入手されない可能性がある。その道路又は曲がり角を利用するユーザに対する軌跡群により更に正確な位置が判定され、装置のメーカによる今後の地図のリリースは訂正を取り入れられる。
【０００７】
多くの場合に「wikimaps」と呼ばれる共同マッピングプロジェクトを参照してもよい。しかし、wikimapsは、ここで規定するような「地図データ」を生成しない。すなわち、目的地までの道路システム上のルートを計画するためのルートガイダンスアルゴリズムに適した地図データを生成しない。
【課題を解決するための手段】
【０００８】
本発明は、ナビゲーション装置において使用するための改善された地図データを生成する方法である。この方法は：
ａ）電子ナビゲーション装置上にルートガイダンスアルゴリズムに適した地図データを表示するステップと；
ｂ）装置のエンドユーザが地図誤りに対する訂正を装置上に直接入力するステップと；
ｃ）装置が訂正の外部処理なしで訂正を使用できるステップとを有する。
【０００９】
従って、エンドユーザは、ウェブリンクを介して誤りを地図メーカに報告して、その地図メーカが誤りを検証し、地図を更新し且つ更新データを供給することを待つように制約される必要はなくなる。それが完了するのにかかる周期は、数ヶ月及び時には数年である。ナビゲーション装置は、地図メーカによる検査等の外部処理なしで訂正を使用できる。装置による訂正の使用は、相対的な用語では「迅速に」である。用語「迅速」は、瞬時として解釈されるべきではないが、訂正が入力された直後を単純に意味する。ユーザが訂正を使用すべきかを検証するステップ、装置の電源を入れ且つその後電源を切るステップ等の仲介ステップが存在してもよい。
【００１０】
一実現例において、ユーザが自身の装置に格納された地図データに対して修正を行なうことを可能にするナビゲーション装置が存在する。ナビゲーション装置は、TomTom International BVのGOシリーズの装置等のルートガイダンス機能を有するポータブルスタンドアロンＧＰＳナビゲーション装置であってもよく、あるいは移動電話又はＰＤＡ等の任意の他の種類のポータブル情報装置であってもよい。しかし、同様に、ナビゲーション装置は、車両に組み込まれた装置であってもよく、あるいはナビゲーションソフトウェア（この用語は、実際には動的ルートガイダンスを配信しないがユーザが存在する場所を単純にマッピングするマッピングソフトウェアを含む。またナビゲーションソフトウェアは、クライアント装置上でローカルに実行可能であるか、あるいはクライアント装置から離れたサーバ上で実行可能である）を実行する固定デスクトップＰＣ（ラップトップを含む）等の演算装置であってもよい。ＰＣは、ルートガイダンス機能を有するポータブルナビゲーション装置とドッキングして、ポータブルナビゲーション装置に訂正を転送できる。
【００１１】
そのようなナビゲーション装置の一般的な特徴は以下の通りである。
・ユーザがデジタルに格納された地図に対する訂正を作成することを可能にするユーザインタフェース。
・ユーザがルート計算に地図訂正を含むか又はルート計算から地図訂正を除外することを可能にするユーザインタフェース。
・ユーザがデジタル地図上で訂正された地図データを見れるようにするユーザインタフェース。
・訂正された地図データを、音響、または、テキスト等の可視マーキングと共に表示するユーザインタフェース。
・ユーザが１つ以上の交通手段（transportation types）と地図訂正を関連付けることを可能にする訂正カテゴリの集合。
・例えばコンテンツ集約サービスを介して地図訂正を他のユーザと共有する能力。共有された地図は、ダウンロードされるとすぐに使用可能である（例えば、ルート計画アルゴリズム又は地図表示エンジンにより）。
【００１２】
本発明の第２の面は、自動地図訂正提案方法である。この方法において、ナビゲーション装置は、運転者の挙動に関連する統計データを収集及び解析し、一般にある特定の閾値基準が満たされる場合に地図訂正をユーザに提案する。例えば装置が計画した道路をユーザが曲がらなかった場合、それは、実際の道路には「進入禁止」の標識があるが装置に格納された地図が最新にされていないためである場合がある。装置は、「申し訳ございません。地図が間違っていましたか？」等のメッセージを自動的に表示でき、「はい」及び「いいえ」のボタンがメッセージにより表示される。ユーザが「はい」を押下した場合、装置は、ユーザが装置に格納された地図に対して訂正を作成することを可能にするユーザインタフェースを表示してもよい。ユーザは、「進入禁止」道路としてその道路に印をつけることにより地図を訂正できる。ナビゲーション装置上で実行するルート計画アルゴリズムは、即座にその訂正を利用可能である。
【００１３】
第３の面は、地図訂正解析方法である。この方法において、システムは以下のうち１つ以上を使用して地図訂正を解析する：
・訂正の「妥当性」を得るためのユーザの訂正の解析及び集約；
・単一のユーザからの訂正の「信頼性」を得るためのそのユーザにより供給される訂正の解析；
・「禁止された」用語（例えば、道路名における補足）を除去するための全ての文字列データのキーワード解析；
・地図訂正が同一領域の他の地図（他の供給元からの地図及び同一供給元からの地図の更に新しいバージョンの双方）に適用されるべきであるかを決定するための訂正の解析。
【図面の簡単な説明】
【００１４】
【図１Ａ】、
【図１Ｂ】ナビゲーション装置により表示されるメイン誤り報告画面を示す図である。
【図２】ユーザが入手及び報告したい誤りの種類を規定することを可能にする画面を示す図である。
【図３】本発明を実現するナビゲーション装置のスクリーンショットを示す図であり、スクリーンショットは、計画地図のビュー及びディスプレイの下部に沿うステータスバーを示す。
【図４】３Ｄビューを実現するナビゲーション装置のスクリーンショットを示す図である。
【図５】ナビゲーションメニューを示すナビゲーション装置のスクリーンショットを示す図である。
【図６Ａ】、
【図６Ｂ】ナビゲーション装置を示す透視図である。
【図７】ナビゲーション装置のシステムアーキテクチャを示す概略図である。
【図８】ナビゲーション装置の構成要素を示すブロック図である。
【図９】図８のナビゲーション装置の電気サブアセンブリを示す図である。
【発明を実施するための形態】
【００１５】
Map ShareTMと呼ばれる一実現例を参照して、本発明を説明する。Map Shareにより、ユーザはTomTom International B.V.のGOパーソナルナビゲーション装置を使用して地図の誤りを修正し且つ共有及び報告できる。ユーザは、訂正（又は地図修正）をナビゲーション装置に入力する。地図修正は、装置にローカルに適用され、道路、ＰＯＩ等をルーティング及び表示する際に装置により使用される地図データを補足する。地図修正は、即座に利用可能である。地図修正は、多くの方法により装置によってTomTomサーバに報告される。装置は、一体型の通信機能（例えば、データをサーバに送出できる無線セルラシステム）を有してもよく、狭域無線リンクを介して移動電話にデータを送出して、移動電話がそのデータをサーバに送出してもよく、サーバと通信でき且つインターネットに接続されたＰＣとドッキングできてもよく、あるいは装置自体がインターネットに接続されたＰＣであってもよい。サーバは、全てのユーザからの全ての訂正を集約し、訂正を検査し、その訂正を他のユーザに配信し、１つ以上の地図メーカと訂正を共有する。
【００１６】
完全に実行された場合、そのフィードバックは、TomTom製品の地図データを更新する主な機構として地図メーカ更新データを置換できる。
【００１７】
Map Shareの一実現例の範囲は、ユーザが以下のことを行なえる装置上の使用し易いツールを提供することである：
・地図上の道路をブロック及びブロック解除する
・地図上の道路の交通の方向を修正する
・地図上の道路名を追加及び修正する
・地図上の道路の制限速度を修正する
【００１８】
従って、訂正は、ルーティング計算アルゴリズムの動作方法に直接影響を及ぼす。すなわち、訂正は、目的地までのルートを計算する時に使用される。更にMap Shareにより、ユーザは以下のことが可能である：
・安全カメラの場所を地図に追加する
・他のユーザと地図訂正を共有する
・他のユーザから地図訂正をダウンロードする
・大きな誤りに対する地図誤りレポートを作成する
【００１９】
装置上の訂正に加え、上記訂正の種類全てに対する同一の訂正の特徴は、例えば訂正を格納するために装置に接続できるデスクトップコンピュータアプリケーションを使用して利用可能にできる。
【００２０】
装置上の特徴に加え、ウェブを使用する既存のTomTom地図誤り報告ツールに対して改善が可能である：
・地図誤り報告は、TomTomサポートウェブサイト内で更に容易に見つけられる
・地図誤り報告ツールは、TomTom Homeアプリケーションに追加される
・ユーザは、報告した地図誤りに関するフィードバックを受信する
・TomTomは、TeleAtlas等の地図供給元に誤りを送出する前にそれら誤りを事前に優先順位付けできる
【００２１】
上述したように、Map Share実現例の重要な特徴は以下の通りである：
・装置上で地図訂正、誤り報告等を行なうこと
・ある特定の訂正を迅速に有効にすること（例えば、ユーザ規定の基準を満足する訂正）
・ユーザが他のユーザと訂正を交換できること
【００２２】
GOナビゲーション装置において、これは、装置が図１Ａに示すようなメニュー項目「Make changes to the map」を表示することにより実現される。この項目を選択した結果を以下に説明する。まず説明する別のメニュー項目が２つ存在する。
【００２３】
第１に、メニュー項目「Exchange Changes」により、ユーザはユーザ自身の変更のアップロードを開始でき、且つ他のユーザによる変更を装置にダウンロードできる。アップロードは、Ｂｌｕｅｔｏｏｔｈネットワークを介してGO装置にリンクするＧＰＲＳ無線リンクを有する移動電話を介して行なわれるか、又は、GO装置がドッキングされるインターネット接続ＰＣを介して行なわれる。
【００２４】
第２に、メニュー項目「Preferences About changes」は、有効にする変更を判定する。この項目を選択することにより、装置は、有効にする適用可能な変更の種類を示すためのユーザに対するチェックボックスを含むメニュー画面を表示できる：
有効にすべき変更：
[x]自身の変更
[x]最近の変更
[ ]去年の変更／他の地図に行なわれた変更
[x]２度以上報告された場合のみ
[x]信頼できる情報源からの変更のみ
２，６３５個の利用可能な変更のうち１，３６５個が有効です。
【００２５】
ユーザが「Make changes to map」アイコンに触れることによりそのアイコンを選択する場合、ユーザは地図を変更するためのINSTANT-EFFECT（迅速に有効にする）オプション及び誤りのREPORT（報告）オプション（自己動作の対象として含まれない場合）を提供するサブメニューに移る。図１Ｂに示すように、これらは以下を含む：
・Add/change street name：ユーザがこれを選択した場合、例えば装置は、地図により現在表示されている（又は装置が通常のナビゲーションモードである場合に表示される）道路名のリストを表示できる。ユーザは、名前を変更する道路を選択し、画面上のキーボードを介して新しい名前を入力できる。
・Block Street：ユーザがこれを選択した場合、例えば装置は、地図により現在表示されている（又は装置が通常のナビゲーションモードである場合に表示される）道路名のリストを表示できる。ユーザは、ブロックする道路を選択できる。
・Change traffic direction（不図示）：ユーザがこれを選択した場合、例えば装置は、地図により現在表示されている（又は装置が通常のナビゲーションモードである場合に表示される）道路名のリストを交通の方向と共に表示できる。ユーザは、交通の方向を変更する道路を選択できる。
・Change speed limit：ユーザがこれを選択した場合、例えば装置は、地図により現在表示されている（又は装置が通常のナビゲーションモードである場合に表示される）道路名のリストを適用可能な制限速度と共に表示できる。ユーザは、道路制限を変更する道路を選択し、メニューから適切な新しい制限速度を選択できる。
・Un-block street：ユーザがこれを選択した場合、例えば装置は、地図により現在表示されている（又は装置が通常のナビゲーションモードである場合に表示される）ブロックされた道路名のリストを表示できる。ユーザは、ブロック解除する道路を選択できる。
【００２６】
更に、以下に対するグラフィカルオプションを含む更に深いサブメニューに到達するために「Edit/delete POI」アイコンを選択できる：
ＰＯＩ名の変更
ＰＯＩの移動
ＰＯＩのカテゴリへの追加
ＰＯＩの削除
ＰＯＩの再分類
いずれの場合においても、例えば装置は、地図により現在表示されている（又は装置が通常のナビゲーションモードである場合に表示される）ＰＯＩ名のリストを表示できる。ユーザは、関連するＰＯＩを選択し、そのＰＯＩを編集又は削除できる。一般にそれらのＰＯＩは、地図メーカにより供給されたＰＯＩであるが、ユーザによりダウンロードされたＰＯＩ（例えば、スピードカメラ）を含むことができる。
【００２７】
更なるメニュー項目は、「Report other error」である。これにより、苦情、欠落した道路等を報告できる。一般的な機能は、ユーザが場所を選択することを可能にし、一般的な問題のリストから選択し、ユーザがフリーテキストコメントを追加することを可能にする。
【００２８】
＜他の特徴＞
・ユーザは、自身の地図に対して「個人専用」の修正を作成でき且つ集約のためにTomTomに送出される「共有」の修正を作成できる。
・各地図修正は個別に格納される。
・全ての地図修正は、ＯＴＡ配信のために高圧縮可能である。
・全ての地図修正は安全性が高く（そのため、形式を手動で逆行分析することは不可能である）、競合会社が自身の地図を訂正するためにTomTom装置上で行なわれた修正を使用できないことを保証する。
・修正は、地図に依存しない形式で格納される。
・地図修正は、地図のアップグレード中に保存される。
・地図修正は、種々のメーカの地図に適用可能である。
・地図修正に関連した領域が地図データの新しいリリースにおいて変更されている場合、その修正は自動的に除去される（この例において、地図誤りは地図供給元により修正されていると仮定するため）。
・地図修正は、ユーザの地図データを永続的に修正しない。
・ユーザは、使用する変更の種類を選択できる（例えば、「use only my changes（自分の変更のみを使用する）」又は「use my changes and those from TomTom（自分の変更及びTomTomによる変更を使用する）」。
・TomTomは、リリースされた各地図バージョンに対する地図修正データベースを保持する（尚、新しい地図を有するユーザは、古い地図に関して報告された修正を受信できるが、古い地図のユーザは新しい地図に関して報告された修正を受信できない）。
・TomTomは、地図修正及びレポートが収集され且つ他のユーザと共有されるように集約システムを作成する。
・TomTomは、地図修正及びレポートの妥当性又は信頼性が評価されるように「信頼」システムを作成する。定期的に適切な誤りを報告するユーザは「信頼」されるようになり、それらのユーザの修正は、妥当性検査の必要なく全てのユーザに提供される。これらのユーザは、他のユーザにより提出された修正を検査することを要求されてもよい。
・TomTomは、ユーザにより送出された修正を承認する（それらが検査された後）。
【００２９】
図２は、本発明を実現するナビゲーション装置において展開される中核のソフトウェアモジュールを概略的に示す。ディスプレイ２１は、ユーザが従来の方法で目的地の住所を入力するタッチスクリーンディスプレイである。その入力された住所データは、ＵＩモジュール２２により処理され、ナビゲーション／ルート計画モジュール２３に送出される。ＧＰＳモジュール２４からのＧＰＳ出力を使用するルート計画モジュール２３は、装置が有する（又はTele Atlas等の地図メーカから供給される）暗号化圧縮地図データの地図データを使用してルートを計画する。本発明は、以下のように実現される。すなわち、ユーザは、タッチスクリーン対話を使用し、図１Ａ及び図１Ｂに例示するような大きなグラフィカルアイコンに触れて、必要に応じて地図訂正をディスプレイ２１に入力する。ＵＩモジュール２２は、地図修正を入手し、それを地図修正記憶装置２６に送出する。地図修正は、地図修正記憶装置２６に入るとすぐに、ルート計画モジュール２３及びＵＩモジュール２２に対して使用可能にされる。地図修正が運転している現在のルートであってもその再計画を必要とする場合、再計画は自動的に行なわれる（ユーザがそのオプションを設定している場合）。例えば、装置は、ユーザが道路を曲がることを要求するルートを計画している場合がある。曲がり角に近付いた時、ユーザはその道路が最近「進入禁止」の道路にされたことに気がつく。ユーザは適切な地図訂正を入力でき、新しいルートは進入禁止の道路を考慮して迅速に計画され、適切なルートガイダンスが与えられる。同様に、ユーザが別の目的地までの完全に新しいルートを計画した場合、その新しいルートは地図修正を考慮に入れる。地図修正が地図の見え方に影響を及ぼす（例えば、道路名を変更したり、スピードカメラ等の新しいＰＯＩを表示する）場合、新しい外観は即座に存在する。訂正の自動的な使用は必須ではない。ユーザの中には、地図訂正を除外してルート計算等を行なうことを好むユーザもいるだろう。
【００３０】
付録１において、本発明を実現できる一般的な装置について説明する。付録２は、Map Shareに対する高レベルな要件である。
【００３１】
＜付録１＞
本発明は、GOと呼ばれるTomTom B.V.の統合ナビゲーション装置において実現可能である。GOは、Navigator（又はNavcore）と呼ばれるナビゲーションソフトウェアを展開し、内部ＧＰＳ受信機を有する。Navigatorソフトウェアは、Compaq iPaq等のタッチスクリーンの（すなわち、スタイラスで制御される）ＰｏｃｋｅｔＰＣ搭載ＰＤＡ装置上で実行してもよい。このソフトウェアは、ＰＤＡがＧＰＳ受信機と結合された時にＧＰＳを使用するナビゲーションシステムを提供する。組み合わされたＰＤＡ及びＧＰＳ受信機システムは、車載ナビゲーションシステムとして使用されるように設計される。
【００３２】
本発明は、一体型ＧＰＳ受信機／コンピュータ／ディスプレイを有する装置、あるいは乗り物以外による使用（例えば、歩行者）又は自動車以外の乗り物（例えば、航空機）に対して設計された装置等のナビゲーション装置の任意の他の構成で実現されてもよい。ナビゲーション装置は、任意の種類の位置検知技術を実行してもよく、ＧＰＳに限定されない。従って、ナビゲーション装置は、欧州のガリレオシステム等の他の種類のＧＮＳＳ（グローバルナビゲーションサテライトシステム）を使用して実現される。同様に、ナビゲーション装置は、衛星を使用する位置／速度システムに限定されず、地上ビーコン又は装置が地理的な場所を判定することを可能にする任意の他の種類のシステムを使用して展開される。
【００３３】
ＰＤＡ上で実行する場合、Navigatorソフトウェアは、図３に示す通常のナビゲーションモード画面を表示するナビゲーション装置となる。このビューは、テキスト、記号、音声ガイダンス及び動画地図の組合せを使用して運転指示を提供する。重要なユーザインタフェース要素は、２Ｄ地図１が画面の殆どを占有することである。地図は、ユーザの自動車が動く方向が常に「上姿勢」になるように回転された自動車及びその周囲を示す。ステータスバー２は、画面の下１／４にわたってもよい。装置自体が従来のＧＰＳ位置探索及びその姿勢（移動する方向から推測される）を使用して判定するように、装置の現在の場所は矢印３により示される。装置により計算されたルート（メモリ素子の地図データベースに格納された地図データに適用されるメモリ素子に格納されたルート計算アルゴリズムを使用して）は、移動方向を示す矢印と重ね合わされた陰影をつけた経路４で示される。陰影をつけた経路４において、全ての主な動作（例えば、角、交差点、ロータリー等を曲がる）は、経路４に重なる矢印５により概略的に示される。ステータスバー２は、左側に次の動作（ここでは、右折）を示す記号６を更に含む。ステータスバー２は、装置により計算されたルート全体のデータベース（すなわち、選択されるルートを規定する全ての道路及び関連する動作のリスト）から抽出される次の動作までの距離（すなわち、右折−ここでは距離は２２０メートル）を更に示す。ステータスバー２は、現在の道路名８、到着までの推定時間９（ここでは、２分４０秒）、実際の推定到着時間１０（１１：３６ａｍ）及び目的地までの距離１１（１．４Ｋｍ）を更に示す。ＧＰＳ信号強度は、移動電話と同様の信号強度指標１２で示される。図４に示すように、３Ｄ地図のビューも可能である。
【００３４】
ユーザが画面１３に触れる場合、ナビゲーション画面のメインメニュー（不図示）が表示される。このメニューから、Navigatorアプリケーション内の他の中核のナビゲーション機能は開始又は制御される。非常に容易に呼び出される（例えば、地図の表示からメニュー画面まで１ステップである）メニュー画面から中核のナビゲーション機能を選択することを可能にすることにより、ユーザ対話が非常に簡単化されて高速且つ容易になる。
【００３５】
ユーザにより触れられる必要のあるタッチゾーンの領域は、スタイラスを使用する殆どのタッチスクリーンシステムより非常に大きい。この領域は、特定の精度なしで１本の指で確実に選択されるのに十分な大きさになるように、すなわち、車両を制御している時に運転者に対する現実の状況を模倣するように設計される。運転者は、小さな制御アイコンを含む非常に詳細な画面を見る時間は殆どなく、またそれらの小さな制御アイコンの１つを正確に押下する時間は更に少ない。従って、所定のソフトキー（又は画面１３の中央にあるような隠しソフトキー）と関連付けられた非常に大きなタッチスクリーン領域を使用することは、この実現例の熟慮された設計特徴である。他のスタイラスを使用するアプリケーションとは異なり、この設計特徴は、実際に運転中に運転者により必要とされる可能性が高い中核の機能を選択するために、Navigatorにわたり一貫して展開される。従って、ユーザが画面上のアイコン（例えば、制御アイコン又は目的地の住所等を入力するための仮想キーボードのキー）を選択する選択肢を与えられる場合は常に、それらのアイコン／キーの設計は単純さが維持され、関連するタッチスクリーンゾーンは、各アイコン／キーが明確に指で選択されるようなサイズに拡張される。実際には、関連するタッチスクリーンゾーンは、少なくとも約０．７ｃｍ2であり、一般に正方形のゾーンである。通常のナビゲーションモードにおいて、装置は地図を表示する。画面の中央（又は別の実現例においては画面の任意の部分）に近接して地図（すなわち、タッチセンシティブディスプレイ）を１度（又は異なる実現例においては２度）触れることにより、別のルートを計算するオプション及び道路の次の区間を回避するようにルートを再計算するオプション（障害物又は大渋滞に直面した場合に有用である）、あるいは特定の一覧表示された道路を回避するようにルートを再計算するオプション等の種々のナビゲーション機能に対応する大きなアイコンを含むナビゲーションメニュー（図５を参照）を直接（すなわち、次の下のレベル）又は間接的（すなわち、２つ以上下のレベル）に呼び出す。
【００３６】
装置の実際の物理的な構造は、メモリアーキテクチャ（以下のシステムアーキテクチャの節を参照）に関して従来の組込み装置と根本的に異なる。高レベルにおいては、その構造は同様である。すなわち、メモリはルート計算アルゴリズム、地図データベース及びユーザインタフェースソフトウェアを格納する。マイクロプロセッサは、ユーザ入力（例えば、装置のタッチスクリーンを使用して、出発地の住所及び目的地の住所、並びに全ての他の制御入力を入力する）を解釈及び処理し、ルート計算アルゴリズムを展開して最適なルートを計算する。「最適」は、最短時間又は最短距離、あるいは他のユーザに関係する要素等の基準を参照してもよい。
【００３７】
更に詳細には、ユーザは、通常の方法で、仮想キーボードを使用してＰＤＡ上で実行するNavigatorソフトウェアに出発位置及び要求する目的地を入力する。ユーザは、移動ルートを計算する方法を選択する。ルートを非常に迅速に計算するがルートが最短ではない可能性のある「高速」モード；全ての可能なルートを調べて最短のルートを見つけるが計算時間がより長くなる「フル」モード等の種々のモードが提供される。例えば、特に美しい眺めとしてマーク付けされた殆どのＰＯＩ（地点情報）を通過するか又は子供が興味を持つ可能性のある殆どのＰＯＩを通過する景色のよいルート、あるいは分岐点が最も少ないルートをユーザが規定する等、他のオプションが可能である。
【００３８】
道路自体は、ＰＤＡ上で実行するNavigatorの一部である（又はNavigatorによりアクセスされる）地図データベースにおいて線、すなわちベクトル（例えば、道路の始点、終点、方向であり、道路全体は、各々が始点／終点方向パラメータにより一意に規定される数百の区間から構成される）として記述される。地図は、そのような道路ベクトル、地点情報（ＰＯＩ）、道路名、公園の境界や川の境界等の他の地理的特徴の集合であり、それらは全てベクトルに関して規定される。全ての地図の特徴（例えば、道路ベクトル、ＰＯＩ等）は、ＧＰＳ座標系に対応するか又は関連する座標系で規定され、ＧＰＳシステムを介して判定される装置の位置を地図に示される関連道路に配置することを可能にする。
【００３９】
ルート計算は、Navigatorソフトウェアの一部である複雑なアルゴリズムを使用する。アルゴリズムは、多くの潜在的な種々のルートを採点するために適用される。Navigatorソフトウェアは、フルモードスキャン、景色のよいルート、美術館／博物館を通過及びスピードカメラなし等のユーザが規定した基準（又は装置のデフォルト）に対してそれらのルートを評価する。規定された基準に最も適合するルートは、ＰＤＡのプロセッサにより計算され、ベクトルのシーケンス、道路名及びベクトルの終点で行なわれる動作（例えば、１００ｍ先で左折してｘ通りへなど、ルートの各道路に沿った所定の距離に対応する）としてＲＡＭのデータベースに格納される。
【００４０】
図６Ａ及び図６Ｂは、ナビゲーション装置の実際の実現例を示す透視図である。ナビゲーション装置は、ディスプレイ、内部ＧＰＳ受信機、マイクロプロセッサ、電源及びメモリシステムを含むユニットである。装置は、大きな吸着カップを使用して自動車のダッシュボードに固定されるアーム上に位置する。
【００４１】
＜システムアーキテクチャ＞
大容量のマスクＲＯＭ又はフラッシュ装置から所定の位置にある全てのＯＳ及びアプリケーションコードを実行する従来の組込み装置と異なり、本発明の一実現例は新しいメモリアーキテクチャを使用する。図７は、装置を概略的に示す。一般に５１で示される装置は、マイクロプロセッサ５６、電源５７、ディスプレイ／関連ドライバ５８等の従来の要素を含む。更に、装置はＳＤカードリーダ５３を含み、ＳＤカード５２は所定の位置に差し込まれて示される。装置５１は、内部ＤＲＡＭ５４及びＸＩＰフラッシュ５５を有する。
【００４２】
従って、装置は３つの異なる形態のメモリを使用する：
１．小容量の内部ＸＩＰ（eXecute In Place）フラッシュＲＯＭ５５。これは、ＰＣのＢＩＯＳ ＲＯＭに類似し、自社開発のブートローダであるE2エミュレーション（ＵＩＤ及び製造データに対する）及びスプラッシュスクリーンビットマップのみを含む。これは、サイズが２５６ＫＢであると推定され、低速８ビット幅ＳＲＡＭインタフェース上に存在する。
２．メインシステムＲＡＭ（又はＤＲＡＭ）メモリ５４。これは、ＰＣのメインメモリ（ＲＡＭ）に類似する。このメモリにおいて、全ての主なコードはこのメモリから実行され、ビデオＲＡＭ及び作業領域をＯＳ及びアプリケーションに提供する。尚、永続的なユーザデータはメインシステムＲＡＭに格納されない（ＰＣのように）。すなわち、「ＲＡＭドライブ」が存在しない。このＲＡＭは、３２ビット１００ＭＨｚ同期高速バスに排他的に接続される。
３．ＰＣのハードディスクに類似する不揮発性記憶装置。これは、取り外し可能なＮＡＮＤフラッシュＳＤカード５２として実現される。これらの装置はＸＩＰをサポートしない。全てのＯＳ、アプリケーション、設定ファイル及び地図データは、ＳＤカードに永続的に格納される。
【００４３】
起動する際、自社開発のブートローダ５５は、供給されたＳＤカード５２を挿入するようにユーザに指示する。これが行なわれると、装置は、特別なシステムファイルをＳＤカード５２からＲＡＭ５４にコピーする。このファイルは、オペレーティングシステム及びナビゲーションアプリケーションを含む。これが完了すると、アプリケーションに制御が移る。アプリケーションは開始し、ＳＤカード５２の地図等の不揮発性データにアクセスする。
【００４４】
その後装置の電源が切られると、ＲＡＭ５４のコンテンツは保存されるため、この起動手順は、最初に装置が使用される時にのみ実行される。
【００４５】
＜GO製品の仕様＞
＜概要＞
GOは、スタンドアロン完全一体型パーソナルナビゲーション装置である。これは、車両に対するいずれの接続とも無関係に動作する。
【００４６】
＜対象の市場＞
GOは、一般パーソナルナビゲーション市場に対処することを意図する。特に、GOは「アーリーアダプター」市場を越えてパーソナルナビゲーションの市場を拡張するように設計される。従って、これは完全なスタンドアロン解決策であり、ＰＣ、ＰＤＡ又はインターネット接続へのアクセスを必要としない。完全性及び使用の容易さが重視される。
【００４７】
GOは、完全なパーソナルナビゲーション解決策であるが、主に車両での使用を意図する。主な対象市場は、仕事又は娯楽で車両を運転する任意のユーザである。
【００４８】
この市場にうまく対処するために、GOは以下のトップレベルの要件を満たす必要がある：
１．受け入れ可能な価格−製品の機能と費用との適切な妥協点。
２．容易さ−GOの設置及び動作は簡単で直観的であり、全ての主な機能は製品マニュアルの助けなしでＰＣを理解しない平均的なユーザにより行なわれるべきである。
３．融通性−全ての地図データ及び動作プログラムは、プラグインメモリカードに供給される。装置は、種々の地域を範囲に含むように容易に拡張可能である。
４．信頼性−車載ナビゲーションシステムは安全で重要な要素と考えられていないが、ユーザはGOに依存するようになる。GOは、全ての関連する自動車環境標準に準拠して設計される。更に、短いＧＰＳ有効範囲の停止に対して耐性がある。
【００４９】
＜チャネル＞
・消費者電子機器小売店
・自動車付属品販売店
・専門的な自動車付属品取り付け工場
【００５０】
＜製品の概要＞
GOは、車載パーソナルナビゲーション装置である。これは器具として、すなわち汎用機能ではなく専用機能向けに設計される。GOは、消費者販売後自動車市場向けに設計される。専門の取り付けキットがオプションで供給されるが、GOはエンドユーザによる使用及び設置が容易である。
【００５１】
主な特徴は以下の通りである：
・標準的な商品PocketPC 2002の構成要素に基づく
・横向きに装着された標準的なPocketPC 3.5” 1/4VGA transflective TFT LCDディスプレイ
・ＲＯＭレスソフトブートメモリアーキテクチャ
・高度に統合されたＡＲＭ９ ２００ＭＨｚＣＰＵ
・アプリケーション及び地図データ記憶のためのＳＤカードメモリスロット
・一体型ＧＰＳ受信機／アンテナ
・簡単な推測航法のための２軸一体型加速度計
・ユニットを基準にドッキングコネクタを介して行なわれる電源、オーディオ、デバッグ及び外部ＧＰＳアンテナ接続
・ＧＵＩレイヤを有さない組込みＬｉｎｕｘＯＳ、アプリケーションは自身のＵＩを提供する
・指で使用するように最適化された非常に単純なタッチスクリーンＵＩ
・音声指示のための高品質一体型スピーカ
・少なくとも５時間の継続動作を提供する内部リチウムイオン蓄電池
【００５２】
＜オペレーティングシステム＞
GOは、組込みＬｉｎｕｘをカスタマイズしたバージョンを使用する。これは、フラッシュメモリに常駐するカスタムブートローダプログラムによりＳＤカードからロードされる。
【００５３】
＜ハードボタン＞
GOは、１つのハードボタンである電源ボタンのみを有する。これは、GOの電源のＯＮ又はＯＦＦのために１度押下される。ＵＩは、全ての他の動作がペンを使用するＵＩを介して容易にアクセス可能なように設計される。
隠しハードリセットボタンが更に存在する。
【００５４】
＜アーキテクチャ＞
GOアーキテクチャは、移動演算装置用の高度に統合されたシングルチッププロセッサに基づく。この装置は、業界標準ＡＲＭ９２０Ｔプロセッサから約２００ＭＩＰの性能を発揮する。装置は、ＧＰＳベースバンドを除く全ての必要な周辺装置を更に含む。これらの周辺装置には、ＤＲＡＭコントローラ、タイマ／カウンタ、ＵＡＲＴ、ＳＤインタフェース及びＬＣＤコントローラが含まれる。
【００５５】
このアーキテクチャの主な要素は以下の通りである：
・２００ＭＨｚで実行するマイクロプロセッサ。
・低電力自己リフレッシュを含む３２ＭＢ又は６４ＭＢの高速同期ＤＲＡＭ（ＳＤＲＡＭ）。３２ビット幅１００ＭＨｚバス上に２つの装置として構成される。
・ＯＳ（ＲＡＭドライブを有さない）を含む全ての不揮発性記憶装置のためのＳＤカードインタフェース。
・２５６ＫＢのＮＯＲフラッシュに格納されたネイティブ（ベアメタル）ブートローダ。このフラッシュ装置は、一意の製品ＩＤ及び製造データ等の保護データを格納するために書き込み禁止にされたブートセクタを含む。
・ドッキングコネクタに接続されたデバッグＵＡＲＴ（ＲＳ２３２ ３Ｖレベル）。
・ＰＣ接続性に対するＵＳＢクライアント
・一体型ＧＰＳ受信機
・２軸一体型加速度計
・ＰＤＡ及び移動電話接続性に対するオプションの一体型Ｂｌｕｅｔｏｏｔｈトランシーバ
・Ｉ2Ｓコーデック及び増幅器を介する高品質オーディオ
図８は、GOを示すブロック図である。
【００５６】
＜電源管理＞
GOは、２２００ｍＡＨの一体型リチウムイオン蓄電池により電力を供給される。この電池は充電され、装置は、外部に供給される＋５Ｖの電源から電力を供給される（電池が電荷を含まない場合であっても）。この外部＋５Ｖ電源は、ドッキングコネクタ又はＤＣジャックソケットを介して供給される。
【００５７】
この＋５Ｖの供給は、車両の主な電源レール又は外部の電源アダプタから生成される。装置は、単一のボタンにより電源のＯＮ及びＯＦＦが行なわれる。装置が電源ＯＦＦにされた場合、電源を投入されたGOが電源を切られた箇所から再開するように、ＤＲＡＭコンテンツは自己リフレッシュのＲＡＭを配置することにより保存される。ドッキングコネクタを介して入手可能な起動信号が更に存在し、これは、車両のイグニッションがＯＮにされた時にGOの電源を自動的に投入するために使用される。
小さな隠しリセットスイッチが更に存在する。
【００５８】
＜システムメモリアーキテクチャ＞
大容量のマスクＲＯＭ又はフラッシュ装置から所定の位置にある全てのＯＳ及びアプリケーションコードを実行する従来の組込み装置と異なり、GOはＰＣに非常に近い新しいメモリアーキテクチャに基づく。
【００５９】
これは、３つのメモリ形態から構成される：
４．小容量のＸＩＰ（eXecute In Place）フラッシュＲＯＭ。これは、ＰＣのＢＩＯＳ ＲＯＭに類似し、自社開発のブートローダであるE2エミュレーション（ＵＩＤ及び製造データに対する）及びスプラッシュスクリーンビットマップのみを含む。これは、サイズが２５６ＫＢであると推定され、低速８ビット幅ＳＲＡＭインタフェース上に存在する。
５．メインシステムメモリであり、これは、ＰＣのメインメモリ（ＲＡＭ）に類似する。このメモリにおいて、全ての主なコードはこのメモリから実行され、ビデオＲＡＭ及び作業領域をＯＳ及びアプリケーションに提供する。尚、永続的なユーザデータはメインシステムＲＡＭに格納されない（ＰＣのように）。すなわち、「ＲＡＭドライブ」が存在しない。このＲＡＭは、３２ビット１００ＭＨｚ同期高速バスに排他的に接続される。GOは、３２ＭＢ（１６ビット幅）、６４ＭＢ３２ビット幅及び１２８ＭＢ（３２ビット幅）のメモリ構成を可能にする１６ビット幅２５６／５１２ＭビットＳＤＲＡＭに対する２つのサイトを含む。
６．不揮発性記憶装置であり、ＰＣのハードディスクに類似する。これは、取り外し可能なＮＡＮＤフラッシュＳＤカードとして実現される。これらの装置はＸＩＰをサポートしない。全てのＯＳ、アプリケーション、設定ファイル及び地図データは、ＳＤカードに永続的に格納される。
【００６０】
＜オーディオ＞
直径５２ｍｍのスピーカは、適切な品質の音声指示を提供するためにGOに収納される。これは、内部増幅器及びオーディオコーデックにより駆動される。オーディオライン出力端子は、ドッキングコネクタに存在する。
【００６１】
＜ＳＤメモリスロット＞
GOは、１つの標準ＳＤカードソケットを含む。これらは、システムソフトウェアをロードするために使用され、また地図データにアクセスするために使用される。
【００６２】
＜ディスプレイ＞
GOは、transflective 3.5” TFTバックライト付きディスプレイを使用する。これは、PocketPC ＰＤＡにより使用されるような「標準」1/4VGAディスプレイである。これは、タッチパネル及び高輝度のＣＣＦＬバックライトを更に含む。
【００６３】
＜電源＞
＜電源−ＡＣアダプタソケット＞
４．７５Ｖ〜５．２５Ｖ（５．００Ｖ＋／−５％）＠２Ａ
＜電源−ドッキングコネクタ＞
４．７５Ｖ〜５．２５Ｖ（５．００Ｖ＋／−５％）＠２Ａ
＜変形例＞
以下のGOの変形例をアセンブルし且つテストすることが可能である。
【００６４】
＜標準（Ｂｌｕｅｔｏｏｔｈデポピュレート、３２ＭＢのＲＡＭ）＞
標準的な変形例において、Ｂｌｕｅｔｏｏｔｈ機能はポピュレートされず、３２ＭＢのＲＡＭが取り付けられる。
【００６５】
＜Ｂｌｕｅｔｏｏｔｈオプション（今後の変形例）＞
ＢＯＭコストを最小限にするために標準の変形例にはＢｌｕｅｔｏｏｔｈがポピュレートされていないが、製品設計はＢｌｕｅｔｏｏｔｈを含むべきである。設計は、Ｂｌｕｅｔｏｏｔｈ機能の動作中に全ての他の機能（ＧＰＳ ＲＦ性能を含む）が劣化することなく動作することを保証するべきである。
【００６６】
＜６４ＭＢのＲＡＭのオプション（今後の変形例）＞
製品設計は、３２ＭＢのＲＡＭの代わりに６４ＭＢのＲＡＭが取り付け可能であることを保証するべきである。
【００６７】
＜サブアセンブリ＞
GOは、図９に示す以下の電気サブアセンブリから構成される。
【００６８】
＜ＲＦケーブル＞
ＲＦケーブルは、外部ＧＰＳアンテナ（ＲＦドッキングコネクタを介してGOに接続する）からＧＰＳモジュールが位置するＲＦ ＰＣＢにＲＦ信号を供給する。
【００６９】
＜外部コネクタ＞
＜ドッキングコネクタ＞
２つのドッキングコネクタは、外部ドッキングステーションへのインタフェースを提供する。
2014055962.tif 000003
2014055962.tif 000004
【００７０】
＜ＲＦドッキングコネクタ＞
ＲＦドッキングコネクタにより、ドッキングステーションを介した外部アクティブＧＰＳアンテナの接続が可能になる。
【００７１】
＜ＡＣアダプタソケット＞
ＡＣアダプタソケットにより、電力が低コストＡＣアダプタ又はＣＬＡ（シガーライターアダプタ）から供給可能になる。
【００７２】
＜ＵＳＢコネクタ＞
ＵＳＢコネクタにより、標準ミニＵＳＢケーブルによるＰＣへの接続が可能になる。
【００７３】
＜ＳＤカードソケット＞
高振動アプリケーションに適したハードロッキングＳＤカードソケットは、ＳＤＩＯ、ＳＤメモリ及びＭＭＣカードをサポートする。
【００７４】
（GOはＳＤＩＯに対してハードウェアサポートを提供するが、ソフトウェアサポートは製品導入時に利用可能ではない。）
＜プロセッサ＞
プロセッサは、約２００ＭＨｚで動作するＡＲＭ９２０Ｔ ＳＯＣ（システムオンチップ）である。
【００７５】
＜ＲＡＭ＞
GOは、以下の仕様に従ってＲＡＭを取り付けられる：
2014055962.tif 000005
【００７６】
＜フラッシュメモリ＞
GOは、最低２５６ＫＢの１６ビット幅フラッシュメモリを取り付けられ、以下を含む：
・ＳＤカードからＯＳのロードを可能にするためのブートローダコード
・工場で設定される読み出し専用保護製造パラメータ（例えば、製造データ）及び一意のＩＤ（Ｅ２ＰＲＯＭエミュレーション）
・ユーザ固有の設定（Ｅ２ＰＲＯＭエミュレーション）
【００７７】
以下の装置は、価格及び可用性に依存して使用される。
【００７８】
＜ＧＰＳ内部アンテナ＞
ＧＰＳ内部アンテナは、ＲＦ ＰＣＢに直接取り付けられる。
【００７９】
＜ＧＰＳ外部（アクティブ）アンテナ切り替え＞
外部アンテナがＲＦドッキングコネクタを介して接続される場合、ＧＰＳアンテナソースは自動的に外部アンテナに切り替えられる。
【００８０】
＜加速度計＞
固体加速度計は、プロセッサに直接接続され、速度及び方向の変化に関する情報を提供する。
【００８１】
＜補助機能＞
＜イグニッションの同期＞
＜イグニッションの起動＞
ドッキングステーションIGNITION信号における立ち上がりエッジは、ユニットを起動する。IGNITION信号は、１２Ｖ又は２４Ｖの車両バッテリに接続されてもよい。
【００８２】
＜イグニッションの状態の監視＞
ドッキングステーションIGNITION信号の状態が検出されてＧＰＩＯピンに供給されることにより、ソフトウェアは、イグニッション信号が低下した時にユニットの電源を切ることができる。
【００８３】
＜標準周辺装置＞
以下の周辺装置は、標準としてGOに含まれる。
・単純なドッキングシュー。これは、GOを搭載し、ＤＣジャックを介する充電を可能にする。他の接続性は単純なドックに含まれない。
・ＤＣジャックソケット又は単純なドッキングシューを介してＧＯに接続するシガーライター電源ケーブル。
・ＰＣ接続性に対するミニＵＳＢケーブル。
・ＤＣジャックソケットに接続するためのユニバーサル電源アダプタ。
【００８４】
＜オプションの周辺装置＞
GOの起動時又は起動後、以下のオプションの周辺装置が利用可能である。
・アクティブアンテナキット。これは、ＧＰＳアクティブアンテナ及びＧＰＳ ＲＦコネクタ及びケーブルを取り付けられたドッキングシューを含む。自身の設置のために、外部アンテナが必要とされた場合。
・専門的な車両ドッキングキット。専門的な設置による取り付けの場合のみ。これは、車両インタフェースボックスを介して車両電源、オーディオシステム及びアクティブアンテナに直接接続することを可能にする。
【００８５】
＜付録２＞
＜Map Shareの高レベルな要件（０．４０）＞
＜概要＞
TomTomは、消費者が利用可能な最も正確な地図データを提供している。現在、地図の更新は、TomTomの地図供給元により行なわれ、TomTomは、ある地図における誤りを報告ツールを介してTele Atlasにフィードバックできる。地図の誤りが修正されるまでに何回かの地図改訂を行なう可能性があり、またTomTom誤りレポートの結果として行なわれる全ての修正が競合他社と共有されるため、この状況は理想とは程遠い。TomTomが地図の更新を時系列に提供するために、地図誤り報告／訂正の新しいシステムが必要とされる。これらの改善は、Map Shareプロジェクトを介して配布される。
【００８６】
１．１  範囲
本明細書において、Map Shareプロジェクトの高レベルな要件について説明する。
【００８７】
２  高レベルな要件
本節において、Map Shareの高レベルな要件について説明する。
２．１  ユーザ要件
本節において、Map Shareに対するユーザ要件について説明する。
２．１．１  地図訂正
いくつかの地図の誤りは、ユーザにより迅速に訂正される。本節において、地図訂正に関するユーザ要件について説明する。
２．１．１．１  装置上での地図訂正
ユーザは、自身のNavCore装置上で地図の訂正を行なえる。
２．１．１．２  TomTom Home地図訂正
ユーザは、TomTom HomeアプリケーションのNavigator制御内で地図の訂正を行なえる。
【００８８】
２．１．２  地図訂正の種類
本節において、行なうことができる地図訂正の種類に関するユーザ要件を説明する。
２．１．２．１  安全カメラの追加
ユーザは、安全カメラの場所を地図上に追加できる。
尚、このように安全カメラを報告することは既に可能であるが、実現例は、報告する処理を簡単にし、他の地図訂正と整合性をとり、ユーザが報告した安全カメラを迅速に見えるように調整される必要がある。
２．１．２．２  道路のブロック
ユーザは、地図上の道路をブロックできる。
２．１．２．３  道路のブロック解除
ユーザは、地図上の道路をブロック解除できる。
２．１．２．４  交通の方向の修正
ユーザは、地図上の道路の交通の方向のプロパティを修正できる。特に、ユーザは以下を行なえる：
・両面通行道路を一方通行道路（いずれかの方向）に変更する
・一方通行道路を両面通行道路に変更する
・一方通行道路の方向を他方の方向に変更する
２．１．２．５  道路の追加
ユーザは、地図上に道路（１つ以上のノードから構成される）を追加できる。
２．１．２．６  道路の接続
ユーザは、地図上の２点を接続し、この新しいリンクを新しい道路として規定できる。
２．１．２．７  道路名の追加
ユーザは、地図上の名前を付けられていない道路に道路名を追加できる。
２．１．２．８  道路名の修正
ユーザは、地図上の道路名を修正できる。
２．１．２．９  制限速度の修正
ユーザは、地図上の道路の最高速度を修正できる。
【００８９】
２．１．３  装置上の訂正の可用性
地図訂正がNavCore装置上に存在すると、ユーザはそれらの訂正を利用できるようになる。本節において、装置上の訂正の可用性に関するユーザ要件について説明する。
２．１．３．１  個人専用の訂正の可用性
ユーザは、個人専用の訂正が記録されるとすぐにそれらの訂正を使用できる。
２．１．３．２  公開訂正の可用性
ユーザは、公開訂正が装置にダウンロードされるとすぐにそれらの訂正を使用できる。
【００９０】
２．１．４．  地図訂正の使用
いくつかの地図の訂正が他のTomTom所有者により行なわれると、ユーザは、ルートを計算する際に使用する訂正を選択できる。本節において、ユーザの装置上の地図訂正の使用に関するユーザ要件について説明する。
２．１．４．１  安全カメラの警告
ユーザは、個人専用の及び／又は公開して報告された安全カメラに対する警告を受信するかを選択できる。
２．１．４．２  個人専用の地図訂正の使用
ユーザは、訂正を含むルートを計画する時は常に個人専用の地図訂正を使用又は無視できる。
２．１．４．３  公開地図訂正の使用
ユーザは、訂正を含むルートを計画する時は常に公開地図訂正を使用又は無視できる。
２．１．４．４  自動的な地図訂正の使用
ユーザは、１つ以上のカテゴリの個人専用及び／又は公開訂正がルート計算に自動的に含まれるように装置を構成できる。ユーザは、訂正を使用していることを通知される。
２．１．４．５  ルートの再計算
ユーザは、地図訂正を含むか又は除外するようにルートを再計算できる。
２．１．４．６  地図訂正の除去
ユーザは、地図訂正を装置から除去できる。
【００９１】
２．１．５  地図誤り報告
いくつかの地図の誤りは、装置上で訂正を行なうには複雑すぎるか又は規模が大きすぎる。それらの誤りは、TomTom（又は地図供給元）が訂正動作を行なえるように、TomTomに報告される必要がある。本節において、地図誤り報告に関するユーザ要件について説明する。
２．１．５．１  装置上での地図誤り報告
ユーザは、自身の装置上で地図誤りレポートを作成し、それらのレポートをTomTom PLUSサーバにアップロードできる。
【００９２】
尚、ユーザは運転中に地図誤りレポートを作成できない。
【００９３】
また、装置上で誤りレポートを作成する場合に事前定義済みの誤りの種類のリストをユーザに提供することは受け入れ可能である。
２．１．５．２  TomTom Home地図誤り報告
ユーザは、TomTom HomeのNavigator制御内で地図誤りレポートを作成し、それらをTomTom PLUSサーバにアップロードできる。
【００９４】
尚、ユーザは、地図誤りレポートを作成するためにTomTom消費者として登録する必要はない。
２．１．５．３  装置上の誤りレポートのTomTom Homeへのインポート
ユーザは、自身の装置上で取り込んだ地図誤りレポートをTomTom Homeアプリケーションにインポートできる。ユーザは、それらのレポートを編集し、TomTom PLUSサーバにアップロードできる。
２．１．５．４  地図誤りレポートのフィードバック
ユーザは、地図誤りレポートに関するフィードバックを提供される。
【００９５】
２．１．６  自動的な地図誤りの識別
ある状況において、TomTom装置は、製品の用途に基づいてユーザに訂正を提案できる。本節において、地図誤りの自動識別に関するユーザ要件について説明する。
２．１．６．１  自動的な道路のブロックの提案
ユーザは、ルート計画内で複数回にわたり回避することを選択した道路をブロックするように入力指示される。
２．１．６．２  自動的な道路作成の提案
ユーザは、道路として印のつけられていない地図領域を複数回にわたり運転した場合、地図上に道路を追加するように入力指示される。
２．１．６．３  自動的な道路名付加の提案
ユーザは、名前の付けられていない道路に対するルートを複数回にわたり計画した場合、地図上のそのような道路に名前を追加するように入力指示される。
２．１．６．４  自動的な制限速度修正の提案
ユーザは、地図データに記述される速度と非常に異なる速度で複数回にわたり道路を運転した場合、その道路の制限速度を修正するように入力指示される。
【００９６】
２．１．７  地図訂正の共有
Map Shareのユーザは、他のTomTom所有者と訂正を共有したいだろう。本節において、他のTomTom所有者と地図訂正を共有するユーザの能力に関するユーザ要件について説明する。
２．１．７．１  個人専用の地図訂正
ユーザは、個人的に使用するためだけに訂正を作成できる。これらの訂正は、TomTom PLUSサーバに送出されない。
２．１．７．２  公開地図訂正
ユーザは、他のTomTom所有者と共有される訂正を作成できる。これらの訂正は、TomTom PLUSサーバにアップロードされ、他のMap Shareユーザに対して利用可能にされる。
２．１．７．３  公開地図訂正のコミュニティ分類
ユーザは、適用可能なユーザコミュニティに従って公開地図訂正を分類できる。以下のコミュニティのカテゴリが利用可能となる：
・全てのユーザ
・全ての自動車運転者
・大型トラックの運転者
・オートバイの運転者
・速度制限した車両の運転者
・歩行者
・自転車
なお、他の言語や領域に従ったカテゴリの如く、他のコミュニティカテゴリも可能である。
２．１．７．４  信頼ユーザ状態
ユーザは、アップロードした地図訂正の個数及び品質に基づいて「信頼ユーザ」状態を取得できる。
２．１．７．５  地図修正情報
ユーザは、使用している地図データの新しいバージョンにおいて訂正された地図訂正を報告しようとしたかが通知される。ユーザは、更新された地図の購入方法が更に通知される。
【００９７】
２．１．８  地図訂正の検索
公開地図訂正を使用するために、ユーザはTomTom PLUSサーバからそれらの訂正を検索する必要がある。本節において、地図訂正検索に関するユーザ要件について説明する。
２．１．８．１  公開地図訂正の検索
ユーザは、公開地図訂正をTomTom PLUSサーバから自身の装置及びTomTom Homeアプリケーションにダウンロードできる。
２．１．８．２  公開地図訂正コミュニティカテゴリの検索
ユーザは、１つ以上のコミュニティカテゴリから公開地図訂正をダウンロードできる。
【００９８】
尚、公開訂正コミュニティカテゴリは、第２．１．７．３節において規定される。
２．１．８．３  公開地図訂正情報源カテゴリの検索
ユーザは、１つ以上のコミュニティ情報源カテゴリから公開地図訂正をダウンロードできる。
【００９９】
尚、公開訂正情報源カテゴリは、第２．２．１．５節において規定される。
２．１．８．４  公開地図訂正供給元カテゴリの検索
ユーザは、１つ以上の地図供給元情報源カテゴリから公開地図訂正をダウンロードできる。供給元カテゴリは、各TomTom地図供給元に対して提供される。
２．１．８．５  公開地図訂正場所カテゴリの検索
ユーザは、１つ以上の場所カテゴリから公開地図訂正をダウンロードできる。
尚、以下のカテゴリが利用可能である：
・全ての地図
・装置上の全ての地図
・装置上の現在ロードされている地図
【０１００】
２．２  技術的な制約
Map Share内のいくつかの特徴は、ユーザ要件に対処し且つTomTomの利益を保護するために特定の方法で実現される必要がある。本節において、Map ShareのV1の範囲に対する全ての周知の技術的制約について説明する。
２．２．１  公開地図訂正の管理
ユーザが公開地図訂正に関して情報を得た上で決定することを可能にするために、Map Shareはそれらの訂正を管理する必要がある。本節において、地図訂正の分類に関する制約について説明する。
２．２．１．１  地図訂正の集約
TomTomは、TomTom PLUSサーバに送出された全ての公開地図訂正を集約する。
２．２．１．２  地図訂正の解析
公開地図訂正は、それらの情報源、適用可能性及び信頼性を評価するために解析される。
２．２．１．３  地図訂正の配信
TomTomは、要求に応じて全ての公開地図訂正をMap Shareユーザに配信する。
２．２．１．４  地図訂正の除去
TomTomは、ユーザに供給された各地図に対して各地図訂正の適用可能性を評価する。地図訂正が所定の地図に対して適用可能でないことが分かった場合、その地図訂正は、集約された地図訂正から除去され、その地図のユーザには配信されない。
【０１０１】
２．２．１．５  地図訂正情報源カテゴリ
TomTom PLUSサーバ上に保持される地図訂正は、ユーザがその訂正の情報源の相対的な信頼性を通知されるように、情報源により分類される。
２．２．１．５．１  TomTomの承認
TomTomは特定の地図訂正を承認でき、それらの地図訂正は特定のカテゴリにおいてユーザに示される。
２．２．１．５．２  単一ユーザのレポート
単一のユーザにより報告された地図訂正は、特定のカテゴリにおいて他のユーザに示される。
２．２．１．５．３  複数ユーザのレポート
２人以上のユーザにより報告された地図訂正は、特定のカテゴリにおいて他のユーザに示される。特に、以下のカテゴリが示される：
・２〜５人のユーザのレポート
・６人以上のユーザのレポート
２．２．１．５．４  信頼ユーザのレポート
信頼ユーザにより報告された地図訂正は、特定のカテゴリにおいて他のユーザに示される。
２．２．１．５．５  コミュニティの承認
Map Shareユーザは、他のTomTom所有者により行なわれた地図訂正を承認でき、それらの承認の証拠はユーザに示される。
【０１０２】
２．２．２  データ形式
Map Shareから競争力のある利点を取得（又は維持）するために、地図訂正データが構造化された再利用可能な安全な方法で保持されることが不可欠である。本節において、セキュリティに関する制約について説明する。
２．２．２．１  一意の識別
各地図訂正は、一意に識別される。
２．２．２．２  タイムスタンプ
装置上に取り込まれた各地図訂正は、それが入力及び／又は報告された時間をタイムスタンプされる。
２．２．２．３  モジュール性
各地図訂正は、その訂正が全ての他の地図訂正とは無関係に地図に適用されることを可能にする形式で格納される（すなわち、NavCoreは、訂正が地図に適用され且つユーザに示されるべきであるかを訂正毎に決定できる）。
２．２．２．４  非永続的な修正
地図訂正は、ユーザの地図データに対して永続的な修正を行なわない。
２．２．２．５  データの圧縮
地図訂正は高圧縮可能であり、無線ネットワークを介する高速で安価な配信を可能にする。
２．２．２．６  データの暗号化
地図訂正は、データ形式が逆行分析されないように高度に暗号化される。
２．２．２．７  データの妥当性
地図訂正は、地図アップグレード処理においても保持されるように格納される。
２．２．２．８  今後の地図バージョンの互換性
旧バージョンの地図上で行なわれた訂正が最新バージョンに適用されるように、地図訂正は今後の地図バージョンと互換性がある。
２．２．２．９  旧地図バージョンの非互換性
地図訂正は、旧地図バージョンとの互換性がない。現在の地図バージョン上で行なわれた地図訂正を旧地図バージョンに適用できない。
２．２．２．１０  地図供給元の独立性
地図訂正が種々の供給元からの地図に適用されるように、地図訂正は地図供給元に依存しない。
２．２．２．１１  Tele Atlas ＡＰＩの互換性
TomTomが適切にフォーマットされたレポートを要望に応じてTele Atlasに送出できるように、地図訂正は、Tele Atlas地図報告ＡＰＩと互換性のある形式で格納される。
【０１０３】
２．２．３  装置上での地図訂正処理
地図訂正がユーザの装置上で適切に処理されることを保証するために、ある特定の規則が適用される必要がある。本節において、装置上での地図訂正処理に関する制約について説明する。
２．２．３．１  自動的な地図訂正の除外
旧地図バージョン上で作成された地図訂正は調査され、それらの訂正がユーザの装置上の現在ロードされている地図に適用可能であるかを確認する。適用不可能な地図訂正は、ルート計算内で使用されない。
【０１０４】
２．２．４  地図誤りレポートの管理
更に効果的に地図誤りレポートを管理するために、TomTomは誤りレポートを集約し且つ優先順位付けする方法を実現する必要がある。本節において、地図誤りレポート管理に関する制約について説明する。
２．２．４．１  地図誤りレポートの形式
全ての地図誤りレポートは、Tele Atlas地図誤り報告ＡＰＩと互換性のある形式で作成される。
２．２．４．２  地図誤りレポートの集約
TomTomは、ユーザ装置、TomTom Home及びTomTomウェブサイトからの全ての地図誤りレポートを集約する。
２．２．４．３  地図誤りレポートの優先順位付け
TomTomは、全ての地図誤りレポートを評価し、最も重大な誤りが明らかに強調表示されるようにそれらのレポートに優先順位を割り当てる。誤りレポートがTomTom地図供給元に提出された時に、優先順位はそれらの地図供給元に通信される。
２．２．４．４  Tele Atlas ＡＰＩの互換性
地図誤りレポートは、TomTomが適切にフォーマットされたレポートを要望に応じてTele Atlasに送出できるように、Tele Atlas地図報告ＡＰＩと互換性のある形式で格納される。
【０１０５】
除外
本節において、Map ShareのV1の範囲から除外された高レベルな要件について記述する。
２．３  ユーザ要件
本節において、Map Shareに対する除外されたユーザ要件について記述する。
２．３．１  地図訂正の種類
本節において、Map ShareのV1の範囲から除外された地図訂正の種類について記述する。
２．３．１．１  都市名／場所名の修正
ユーザは、地図上の都市名（及び他の場所名）を修正できる。
２．３．１．２  交通手段に対する道路のブロック
ユーザは、１つ以上の交通手段に対して道路へのアクセスをブロックできる。特にユーザは、以下の交通手段に対してアクセスをブロックできる：
・全ての自動車
・歩行者
・大型トラック
・自転車
２．３．１．３  交通手段に対する道路のブロック解除
ユーザは、１つ以上の交通手段に対して道路へのアクセスのブロックを解除できる。特にユーザは、以下の交通手段に対してアクセスのブロックを解除できる：
・全ての自動車
・歩行者
・大型トラック
・自転車
２．３．１．４  道路の種別の修正
ユーザは、地図上の道路の「種別」を修正できる。
尚、道路種別は、道路のプロパティを規定するために使用され、ルート計算内で使用される。
２．３．１．５  右左折制限の追加
ユーザは、地図上の道路に右左折制限を追加できる。
２．３．１．６  右左折制限の除去
ユーザは、地図上の道路に適用された右左折制限を除去できる。
２．３．１．７  番地の追加
ユーザは、地図上の道路に番地（単一の番号又は範囲）を追加できる。
２．３．１．８  番地の修正
ユーザは、地図上の道路に適用された番地（単一の番号又は範囲）の場所を修正できる。
２．３．１．９  平均速度の修正
ユーザは、地図上の道路の平均速度を修正できる。
２．３．１．１０  道路への通行料の追加
ユーザは、有料道路として地図上の道路に印をつけることができる。
２．３．１．１１  道路からの通行料の除去
ユーザは、地図上の道路から通行料の存在を除去できる。
２．３．１．１２  標識の追加
ユーザは、地図上の道路に標識の情報を追加できる。
２．３．１．１３  標識の修正
ユーザは、地図上の道路と関連付けられた標識の情報のプロパティを修正できる。
２．３．１．１４  標識の除去
ユーザは、地図上の道路と関連付けられた標識の情報を除去できる。
２．３．１．１５  ＰＯＩの場所の修正
ユーザは、地図上のＰＯＩの場所を修正できる。
２．３．１．１６  ＰＯＩ名の修正
ユーザは、地図上のＰＯＩ名を修正できる。
２．３．１．１７  ＰＯＩカテゴリの修正
ユーザは、地図上のＰＯＩのカテゴリを修正できる。
２．３．１．１８  ＰＯＩの除去
ユーザは、地図からＰＯＩを除去できる。
２．３．１．１９  高速道路の出口番号の修正
ユーザは、地図上の高速道路の出口番号を修正できる。
２．３．１．２０  郵便番号の修正
ユーザは、地図上の道路と関連付けられた郵便番号を修正できる。
２．３．１．２１  道路高さ制限の追加
ユーザは、地図上の道路に道路高さ制限を追加できる。
２．３．１．２２  道路幅制限の追加
ユーザは、地図上の道路に道路幅制限を追加できる。
２．３．１．２３  道路重量制限の追加
ユーザは、地図上の道路に道路重量制限を追加できる。
【０１０６】
２．３．２  地図誤り報告
いくつかの地図誤りは、装置上で訂正を行なうには複雑すぎるか又は規模が大きすぎる。それらの誤りは、TomTom（又は地図供給元）が訂正動作を行なえるように、TomTomに報告される必要がある。本節において、地図誤り報告に関するユーザ要件について説明する。
２．３．２．１  TomTomウェブサイト地図誤り報告
ユーザは、TomTomサポートウェブサイト内で地図誤りレポートを作成でき、TomTom PLUSサーバにそれらのレポートをアップロードできる。
・ユーザは、地図誤りレポートを作成するためにTomTom顧客として登録することを必要とすべきではない。
・グラフィカルユーザインタフェースは、地図誤りの場所を容易に選択できるように利用可能にされるべきである。
・フィードバックは、レポートの状態に関してユーザに与えられるべきである。
【０１０７】
２．４  技術的な制約
Map Share内のいくつかの特徴は、ユーザの要件に対処し且つTomTomの利益を保護するために特定の方法で実現される必要がある。本節において、Map ShareのV1の範囲から除去された全ての周知の技術的制約について説明する。
２．４．１  地図誤り報告
本節において、Map ShareのV1の範囲から除去された地図誤り報告に関する全ての周知の技術的制約について説明する。
２．４．１．１  Tele Atlasへの地図誤り報告
TomTomは、Tele Atlas地図誤り報告ＡＰＩを実現し、それをTele Atlasへの全てのレポートの報告機構として使用する。
【図１Ａ】
2014055962.tif 000006
【図１Ｂ】
2014055962.tif 000007
【図２】
2014055962.tif 000008
【図３】
2014055962.tif 000009
【図４】
2014055962.tif 000010
【図５】
2014055962.tif 000011
【図６Ａ】
2014055962.tif 000012
【図６Ｂ】
2014055962.tif 000013
【図７】
2014055962.tif 000014
【図８】
2014055962.tif 000015
【図９】
2014055962.tif 000016
【手続補正書】
【提出日】平成25年11月14日(2013.11.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ナビゲーションデバイス内の、複数の道路のベクトル及び該ベクトルに関連づけられたデータで構成される第１の地図の形式の地図データを変更する方法であって、
前記第１の地図を用いて前記ナビゲーションデバイスのルート計画モジュールで目的地へのルートを計算するステップと、
前記計算されたルートに沿って移動中に、サーバから少なくとも１つの地図変更をダウンロードし、当該少なくとも１つの地図変更を前記ナビゲーションデバイスのメモリに格納するステップと、ここで、前記少なくとも１つの地図変更は１以上の他のナビゲーションデバイスがユーザ入力に応じて作成し、アップロードした地図変更レポートに基づいて作成されたものである；
前記ナビゲーションデバイスにおける前記少なくとも１つの地図変更を適用して、前記第１の地図を補足して第２の地図を、前記第１の地図及び前記少なくとも１つの地図変更から作成するステップと、
前記第２の地図をナビゲーション装置にロードし、前記第２の地図を前記ルート計画モジュールにて利用できるようにするステップと、
前記少なくとも１つの地図変更が前記ルートに沿っているか否かを判定するステップとを有し、
前記少なくとも１つの地図変更が前記ルートに沿っていることを表わす判定がなされた場合、前記ルート計画モジュールは自動的に、又はユーザ入力に応じて、前記目的地までのルートを前記第２の地図を用いて再計算することを特徴とする方法。
【請求項２】
前記地図変更は、コミュニティカテゴリ、情報源カテゴリ、場所カテゴリ、妥当性カテゴリ、重要度カテゴリ、ＰＯＩカテゴリ、言語カテゴリ、地図供給元カテゴリのいずれかを含むことを特徴とする請求項１記載の方法。
【請求項３】
更に、前記ルートが少なくとも１つの変更を含むという指示を生成するステップを含み、当該指示には音声指標、画像指標及び触覚指標のうち少なくとも１つを含むことを特徴とする請求項１又は２に記載の方法。
【請求項４】
更に、テキストによって前記第１の地図に印を付けるステップを含むことを特徴とする請求項１記載の方法。
【請求項５】
更に、前記テキストを視覚表示するステップを含むことを特徴とする請求項４記載の方法。
【請求項６】
更に、前記テキストを可聴表現するステップを含むことを特徴とする請求項４記載の方法。
【請求項７】
更に、前記地図変更をリモート装置へ送信するステップを含むことを特徴とする請求項１記載の方法。
【請求項８】
更に、前記地図変更を編集するステップを含むことを特徴とする請求項１記載の方法。    
【請求項９】
複数の道路のベクトル及び該ベクトルに関連づけられたデータで構成される第１の地図の形式の地図データを有すると共に、ユーザの入力に応じて地図変更レポートを作成する手段並びに作成した地図変更をサーバにアップロードする手段を有するナビゲーションデバイスであって、
前記第１の地図を用いて前記ナビゲーションデバイスのルート計画モジュールで目的地へのルートを計算する手段と、
前記サーバから少なくとも１つの地図変更をダウンロードする工程と、ここで前記少なくとも１つの地図変更は１以上の他のナビゲーションデバイスから前記サーバにアップロードされた地図変更レポートに基づいて作成されたものである；
前記ルートに沿って移動中に前記少なくとも１つの地図変更を前記ナビゲーションデバイスのメモリに格納する手段と、
前記ナビゲーションデバイスにおける前記少なくとも１つの地図変更を適用して、前記第１の地図を補足し、前記第１の地図及び前記少なくとも１つの地図変更から第２の地図を作成する手段と、
前記第２の地図をナビゲーション装置にロードし、前記第２の地図を前記ルート計画モジュールにて利用できるようにする手段と、
前記少なくとも１つの地図変更が前記ルートに沿っているか否かを判定する手段とを有し、
前記少なくとも１つの地図変更が前記ルートに沿っていることを表わす判定がなされた場合、前記ルート計画モジュールは自動的に、又はユーザ入力に応じて、前記目的地までのルートを前記第２の地図を用いて再計算する
ことを特徴とするナビゲーションデバイス。
【請求項１０】
複数の道路のベクトル及び該ベクトルに関連づけられたデータで構成される第１の地図の形式の地図データを有すると共に、ユーザの入力に応じて地図変更レポートを作成する手段並びに作成した地図変更をサーバにアップロードする手段を有するナビゲーションデバイス内のプロセッサに読み込ませ実行させるコンピュータプログラムであって、
前記プロセッサを、
前記第１の地図を用いて前記ナビゲーションデバイスのルート計画モジュールで目的地へのルートを計算する手段、
前記サーバから少なくとも１つの地図変更をダウンロードする手段、ここで前記少なくとも１つの地図変更は１以上の他のナビゲーションデバイスから前記サーバにアップロードされた地図変更レポートに基づいて作成されたものである；
前記ルートに沿って移動中に前記少なくとも１つの地図変更を前記ナビゲーションデバイスのメモリに格納する手段、
前記ナビゲーションデバイスにおける前記少なくとも１つの地図変更を適用して、前記第１の地図を補足し、前記第１の地図及び前記少なくとも１つの地図変更から第２の地図を作成する手段、
前記第２の地図をナビゲーション装置にロードし、前記第２の地図を前記ルート計画モジュールにて利用できるようにする手段、
前記少なくとも１つの地図変更が前記ルートに沿っているか否かを判定する手段として機能させ、
前記少なくとも１つの地図変更が前記ルートに沿っていることを表わす判定がなされた場合、前記ルート計画モジュールは自動的に、又はユーザ入力に応じて、前記目的地までのルートを前記第２の地図を用いて再計算する
ことを特徴とするコンピュータプログラム。
【外国語明細書】
2014055962000001.pdf