JP2014535052A - 境界地理的領域を用いたナビゲーションのための方法及びシステム - Google Patents

Abstract

ソフトウェアコアを含むナビゲーションシステムは、標準及びユーザが定義した独立変数による分散を分析することにより、ユーザが所望する従属変数に対して、二次元において明確に最適化するために境界地理的領域（ＢＧＲｓ）及びノードペアを用いる。本発明は、ノードペアデータを記憶し、厳格に収束したナビゲーションソリューションを生成するために、誤差関数、フィードバック及びＡＮＯＶＡ／ＭＡＮＯＶＡを用いられることができる。【選択図】図１

Description

本発明は、ハンドヘルドナビゲーション、車載ナビゲーション、サーバベースのナビゲーション、及び携帯電話のアプリケーションに関連するナビゲーションを含むナビゲーションルート演算及びガイダンスの分野に関する。

ナビゲーションシステムは、特定の必要とされる基本構成を含み、入力／出力装置、プロセッシングユニットと、ナビゲーション演算コア、通常、道及びポインツ・オブ・インタレスト（Ｐｏｉｎｔｓ ｏｆ Ｉｎｔｅｒｅｓｔ （“ＰＯＩｓ”））を含む地理的データベース、位置を決定するためのグローバルポジショニングシステムチップセット等を含む。自動車システムについては、追加で方向及び速度情報を提供するジャイロスコピックチップが存在する。現在のシステムによる非常に大きな欠点が存在する。ナビゲーションシステムは、高額なハードウェア及びソフトウェアを必要とするＯＥＭによって自動車に搭載され、これは、搭載される車に先んじて廃れてくる。また、オンボードの地理的データベースは、ハードドライブのような記憶媒体を必要とし、これは、相対的に、他の電子部品よりも欠陥がある傾向にあり、データベースは、周期的に更新されなければならない。

サーバベースのナビゲーションシステムは、ガイダンスアルゴリズムが、中央処理ユニット又はサーバに常駐するものである。エンドユーザは、携帯電話、コンピュータ、携帯ナビゲーションデバイス、組み込み自動車システム及びモバイルデータ端末（ＭＤＴ）を含む様々なデバイスを用いてナビゲーションの目的地を入力する。エンドユーザの要求は、携帯電話ネットワーク、衛星ネットワーク、Ｗｉ−Ｆｉネットワークのような、又は無線及び有線接続の両方を含む混成ネットワークを介して、無線でサーバへ送られる。無線リンクは、多数の周囲の状況（例えば、トンネル、主要な都市の中心部のコンクリートキャニオン、住人のいない地域、及び大量の無線使用の回数）で遮断されうる。システムがどのように構成されるかに応じて、送信される必要のあるデータ量は、無線リソースを圧迫する。携帯電話及びパーソナルナビゲーションも同様に制限される。

任意の地理的領域では、ナビゲーションデータベース情報自体のためのソースが少量しか存在しない。ナビゲーションデータベースは、道路の座標及び名称を提供すると共に、各道路の道のタイプ（例えば、住宅地、商業地、ハイウェイ、インターステイト等）を提供する。頻繁に、等データベースは、ポインツ・オブ・インタレスト（Ｐｏｉｎｔｓ ｏｆ Ｉｎｔｅｒｅｓｔ （“ＰＯＩｓ”））も含んでおり、これは、ローカルビジネス、市民又は歴史的に重要な場所、学校、教会、及び公的に頻繁に出入りする他の場所である。米国では、米国勢調査局は、Ｔｏｐｏｌｏｇｉｃａｌｌｙ Ｉｎｔｅｇｒａｔｅｄ Ｇｅｏｇｒａｐｈｉｃ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｒｅｆｅｒｅｎｃｉｎｇ ｓｙｓｔｅｍ ｄａｔａ （“ＴＩＧＥＲ ｄａｔａ”）を提供している。ＴＩＧＥＲデータは、米国のナビゲーション可能な道路の完全なセットを含まず、ＰＯＩも提供しません。ＰＯＩ及びナビゲーション可能な道路のほぼ完全なセットを提供するナビゲーションデータベースの複数の商業プロバイダが存在します。米国での２つの最大手は、Ｎａｖｔｅｑ（登録商標）及びＴｅｌｅ Ａｔｌａｓ（登録商標）です。文章が明確に正反対でない限り、本願でのＰＯＩの使用は、ポイント・オブ・インタレストの特定の、別々の集合ではなく、ポイント・オブ・インタレストの一般的な概念を意味している。大韓民国及び日本国では、ナビゲーションデータベースは、政府によって統制されている。他の管轄権は、政府所有のものからナビゲーションデータベースを提供するプライベートなサービスにまで及ぶ。Ａｐｐｌｅ及びＧｏｏｇｌｅを含む別のナビゲーション及びナビゲーションデータベースの競業者は、急速に市場に参入してきている。また、クラウドソーシングのイノベーションは、マップデータベースに衝撃を与えている。例えば、ＭａｐＢｏｘは、ＯｐｅｎＳｔｒｅｅｔＭａｐと呼ばれるオープンソースコラボレーション型のマップデータベースで動作する。通常、この点では、ほとんど全ての自動車及び携帯電話のナビゲーションは、１つのソースからのナビゲーションソフトウェア及び別のソースからの補足的なナビゲーションデータベースに依存している。ほとんどの場合、単一のエンティティは、完全なソリューションとしてナビゲーションコンポーネントをバンドルし、販売する。

その制限にもかかわらず、直近の２０年間は、ナビゲーション向けの高度な電子機器の拡散がみられている。２０年前、多くの自動車は、非常に少量しか電子部品を有しておらず、携帯電話又はモバイルフォンは、初期段階であった。今日、自動車及び無線電子機器の革新は、ナビゲーションユビキタスベースのグローバルポジショニングを行っている。しかし、消費者のためのオプションの拡散は、未だ、最適化された全体のソリューションを提示していない。多くのナビゲーションソリューションは、１０年以上前のコンピュータによるコアに依存している。

全ての現在のナビゲーションアルゴリズムは、一次元の最適化に依存している。全ての道路は、長さ及び形状を変化するベクトルによって表される。根本的に、現在の方法が道路を表す２つの手法が存在する。第１には、全てのベクトルは、直線ベクトルである。曲線は、複数の直線セグメントに分解される。第２には、曲線及びスプラインの一形態又は別形態は、道路の自然な湾曲を再現するために用いられる。

ルートを探索するために、現在のアルゴリズムは、一次元にピースワイズ最適化する。多くの個々のアルゴリズムは、片側デシジョンツリー、両側デシジョンツリー、ゲートを有する片側デシジョンツリー、ゲートを有する両側デシジョンツリー、バケット及びリーキーバケットを含む、一次元のピースワイズナビゲーション最適化を行うために存在するが、これに限定されない。複数のルートセグメントは、現在地又は現在地及び目的地の両方のいずれかから形成される。ルートは、処理中に互いに比較され、単一又は複数の拒絶基準は、発散解を破棄するために確立される。最終的に、単一のルートは、中間地点（現在地と目的地の両方から形成するピースワイズソリューションの場合）又は目的地（目的地から形成するピースワイズソリューションの場合）のいずれかと交わる現在地と目的地との間に形成される。不思議なことに、プロセスが、解を真のピースワイズ最適化する場合、アルゴリズムが現在地又は目的地で開始するかどうかを目的とした計算には不適切である。多くのアルゴリズムでは、計算は、現在地及び目的地が逆の場合に、片側デシジョンでの異なるルートを選択する。いくつかのアルゴリズムは、両方のルートを計算し、より効率的な又は最適化されたルートをエンドユーザへ表示することにより、このことを補正する。

プロセスは、道路の重み付け（ｒｏａｄ ｗｅｉｇｈｔｉｎｇ）によって促進される。本質的に、インターステイト及び他のハイウェイは、主要な地上の大通りよりも高く重み付けされる。主要な地上道路は、住宅地の道路よりも高く重み付けされる舗装された周辺道路よりも高く重み付けされる。重み付けは、現在地と目的地とのルートを選択するために、ピースワイズ、一次元最適化を組み合わせる。残念ながら、このような重み付けは、頻繁に“インターステイトバイアス”となる。ナビゲーションシステムの多くのユーザは、現在地と目的地との直線経路から大きく迂回する場合であっても、システムが、インターステイト又はハイウェイを好む傾向にあることに気付いている。

今日の技術について取り上げるための主な特徴は、ピースワイズ最適化及び重み付けを用いてルートを生成することである。現在のプロセッサ及びアルゴリズムが、明確な局所的な解を容易に可能にするにもかかわらず、相対的にローカルな地域であっても、これは明確な解を生成しない。ピースワイズ最適化及び重み付けは、インターステイト又はハイウェイでの移動に対するバイアスを生成する。このような旧式のコンピュータによるコアは、今日のナビゲーションシステムの性能に実質的に影響を与えるレガシーアーティファクトを生成する。これらのコアは、第１世代のＲＴＯＳプロセッサのような遅いプロセッサのために書かれている。これらのコアは、現在扱われうるもの（例えば、ペタバイトシステム）よりもデータの容量がかなり小さいと仮定する。これらのコアは、無線データ伝送が、現在可能であるものよりも実質的に速度が遅くなることを仮定する。

これは、企業が、過去２０年間に亘ってそれらのソフトウェアを更新していないと言っているわけではない。その意味するところは、コアソフトウェアのピースが、初めに書かれたとき、多くの制限は、委託又は委託でないもののいずれかにより本質的に内蔵されており、最新式ものへの更新を困難にしている。また、それらのソフトウェアに再度直面したとき、それらが、レガシーコードを含む知識ベースから始まっているため、多くのソフトウェアチームは、何ができるのかについての公表されない（しばしば意識されない）先入観を有する。

旧式のナビゲーションのコアによって生じるレガシーアーティファクトは、正確でない到着予定時間（ｅｓｔｉｍａｔｅｄ−ｔｉｍｅ−ｏｆ−ａｒｒｉｖａｌ （“ＥＴＡ”））計算、学習の欠如、通常のナビゲーションに使用される同一のソフトウェアによる複数の自動車／複数の目的地の問題を扱うことができない、複数の自動車／複数の目的地の問題のための解を最適化できない、ユーザが、算出されたルートからほぼ到達したときに、合理的に評価することができない、及びデバイス間（例えば、車載ユニットと携帯電話）で行ったり来たりするナビゲーションを通過することができないことを含む。

多くのナビゲーションシステムは、１０％又はそれ以下のＥＴＡ、８０−９０％の時間を提供することができる。多くの消費者は、（１）消費者は、到着時間の推定としてのみでＥＴＡ情報に依存していない、（２）ＥＴＡ情報は、別のソースからのものよりは優れた情報である、及び／又は（３）エンドユーザは、利用可能なシステム性能レベルへの期待を常態化している、ために満足している。しかし、誤差が、厳格に許容できないユーザのカテゴリも存在する。例えば、商業自動車ドライバー、商業自動車オペレーター、厳しい期限にある人々、及び混雑した（現在の技術が期待するよりも満足に機能しない）地域に住む人々等である。

十分でないＥＴＡは、意義のある判断を学習するために現在のナビゲーションができないことに部分的に関連する。例えば、多くの人々は、月曜日の朝（祝日を除く）のロスアンゼルスのインターステイト４０５は、午前８：００に混雑することを知っている。現在のナビゲーションコアは、これを行うことができない。同様に、大都市デトロイトのＩ−６９６、シカゴのＩ−９０／９４、ボストンのＩ−９５、及び主要都市の多くの他のインターステイトは、日常的に混雑している。これらの道路のラッシュアワー時の運行速度は、平均で、６０ｍ．ｐ．ｈ．から１０ｍ．ｐ．ｈの間で変化する。変化の多くは、特定の時間、日及び条件が、金曜日の午後及び雨のような特に悪いこと等が十分に予測可能である。残念ながら、現在のナビゲーションソリューションは、推測的にこの状況を見積もることができない。

現在のシステムは、“動的なナビゲーション”を有するこの課題を取り除くことを試みている。動的なナビゲーションは、通常、混雑がある場合、ユーザに再度ルートを探索するために、“リアルタイム”交通データを用いて、ユーザに追加のコストを要求する。現実的に言えば、動的なナビゲーションについての動的は存在しない。多くの“リアルタイム”交通レポートは、２０分又はそれ以上の遅れを有し、単一のソースからもたらされる。独占分野で性能を向上させるための動機付けがほとんどないことにより、動的なナビゲーションナビゲーションに与えられる交通データは、退化していっている。また、交通混雑に向かうルートを日常的に開始することは、ナビゲーションシステムの重み付け機能が、リアルタイム交通メッセージシステムからの使用可能なイベントを算出するときに、再度ルート探索されるのみであり、エンドユーザの時間、お金及び安定を浪費する大きな問題を生成する。

多くの人々は、彼らの家及び職場の近傍の好ましいルートを学習している。これらの好ましいルートは、ユーザに迅速及び／又はより便利なルートを提示する。ユーザが、連続的に好ましいルートを否認する場合、現在のナビゲーションコアは、意義のある手法でデータを組み込むことができない。

好ましいルートを“学習”することによってこの不正確さを取り除くことを試みているといういくつかのソリューションが市場に存在する。しかし、これらのシステムが機能する手法では、ユーザは、点Ａと点Ｂとの間を進まなければならない。繰り返しにより、システムは、ユーザに点Ａと点Ｂとの間を案内するための好ましいサブルートを学習する。しかし、システムは、エンドユーザに有益な手法でこの情報を一般化することができない。多くのユーザは、そのルートを３、４回取った後に、取るべきルートを伝えるシステムにおいて疑いのある値であると気付く。ユーザが望んでいることは、交通制御デバイスの回避、ビジネスパーク、ショッピングセンター及び住宅地のサブディヴィジョンへ入る又は出る特定の経路のような情報を取り、ユニットによって行われる全ての他のルートガイダンスへ情報を一般化するための手法である。

商業的に利用可能なナビゲーションソフトウェアコアは、合理的な再探索する人々が来た場合、全て問題を有する。多くのシステムでは、算出されたルートからの逸脱は、システムに解を再計算させ、これは、実質的にユーザを、初めに算出されたルートへ戻してしまう。これらの再計算は、通常、同じ道に引き返す、ジグザグに進む又はユーザを直ぐに元のルートへ戻す必要がある。提案されたルートからの少しの逸脱のために、シームレスに、ユーザを初めに提案したルートへ合理的な距離で再度導くことができる策が存在しない。

現在のナビゲーションシステムは、また、相互運用性が欠如している。エンドユーザは、彼らの車に１つ、彼らのラップトップに１つ、及び彼らの携帯電話に１つのシステムを有している。しかし、いくつかを除いて、少量のデータしか互いに伝えられない。また、携帯電話でナビゲーションを開始し、自動車に乗車し、携帯電話で算出されたナビゲーションを自動車のナビゲーションシステムで提供することができない。

多くのナビゲーションシステムと同様に、これは、ユーザインターフェイスを有する入出力装置、ジオロケーションのための方法（例えば、ＧＰＳアンテナ及びチップセット）、サーバベースのナビゲーションデータベース、エンドユーザプロセッサ及びメモリ、エンドユーザとサーバとを通信するための無線方法、及びナビゲーションソフトウェアコアを含む。

多くのシステムと同様に、ユーザは、ＰＯＩ、住所又はメモリを用いて目的地を入力する。出発点は、他の点が特定されない限り、ユーザの現在位置であると推定される。ユーザは、最短時間、最短距離、ユーザが定義したコスト関数（例えば、最小の燃料）、又は除外項目（例えば、インターステイトを使用しない又は有料道路を使用しない）を特定する。出発点から目的地を得るために、本発明は、ナビゲーション解を算出する。

地球の表面上又は地球の表面の一部を示す抽象化に、ユーザがナビゲーションデバイスの補助を求める任意の局部的な地域における境界地理的領域（ｂｏｕｎｄｅｄ ｇｅｏｇｒａｐｈｉｃ ｒｅｇｉｏｎｓ （“ＢＧＲｓ”））を生成ることが可能である。各ＢＧＲ内に複数の道路及びポイント・オブ・インタレスト（ｐｏｉｎｔｓ ｏｆ ｉｎｔｅｒｅｓｔ （“ＰＯＩｓ”））が存在する。ＢＧＲの周辺では、ＢＧＲの境界と道路との交差を表すノードが存在する。

ＢＧＲ内をナビゲートする時、以下の４つの可能性のみが存在する：（１）ユーザは、１つのノードでＢＧＲに入り、別のノードを通じて出る；（２）ユーザは、ＢＧＲ内のトリップを生じ、ノードを通じてＢＧＲを出る；（３）ユーザは、ノードを通じてＢＧＲに入り、目的地は、ＢＧＲ内に存在する；又は（４）出発点及び目的地の両方は、ＢＧＲ内に存在する。２番目の場合、出発点は、算出の目的のためのノードとして扱われる。３番目の場合、目的地は、算出の目的のためのノードとして扱われる。４番目の場合、出発点及び目的地の両方は、算出の目的のためのノードとして扱われる。したがって、各ＢＧＲでは、有限個のノードペアを識別することができ、ＢＧＲを横断するための取り得る解のセットの総数を提示する。また、ＢＧＲは、素早く、明確な解が、ノードペア毎に可能であるような大きさである。

本発明は、エンドユーザのためのいくつかのユーザが定義した従属変数を最適化する：（１）時間；（２）距離；（３）燃料；（４）コスト；又は（５）他の商業的に価値のある、ユーザが定義した従属変数。本発明は、各ノードペアに対する値を提供するために使用されうる推定関数を生成することによりこれを行う。推定関数は、各ノードペアに対する値を生成するために、ナビゲーションデータベースからの道路のタイプに基づいて、重み付け係数と共に履歴データを使用する。

ナビゲーションソフトウェアコアは、有限個のＢＧＲを識別し、これは、解を算出するための出発点と目的地との十分な地理的近接である。各ＢＧＲについての各ノードペアに対する値を求めることにより、明確に最適解を解くことが可能になる。明確な解が可能であるのに十分小さいＢＧＲを生成することにより、このシステム及び方法は、ルーティングのための二次元最適化を可能にする。

解がノードペアに対して算出されると、解は、ノードペアルックアップテーブル（Ｎｏｄｅ Ｐａｉｒ Ｌｏｏｋ−Ｕｐ Ｔａｂｌｅ （“ＮＰＬＵＴ”））にセーブされる。ＮＰＬＵＴは、ＢＧＲによってソートされ、任意の与えられた時間で、最も局部的な解のみが処理ユニットに提示され、速度及び効率が向上する。ユニットは、実際の性能を、各ノードペアに対して算出された値と比較することができる。誤差関数を用いて、ユニットは、ノードペアに対して記憶された解を調整することができる。さらに、ＮＰＬＵＴは、変数及び属性（デジタルイベント又はフラグ）データの両方を記憶することができ、対象の従属変数の数に応じて、全ての要因に関するＡＮＯＶＡ又はＭＡＮＯＶＡ算出を可能にする。ＮＰＬＵＴは、時刻、曜日、日付、ドライバー、ドライバーの年齢、ドライバーが運転を学んだ場所（ボストンのドライバーは常に早く運転する）、空間的なイベントの発生（例えば、近隣でフットボールの試合がある）、工事、降水量、温度等の要因を含みうるが、これに限定されない。

ＮＰＬＵＴ内に各ＢＧＲ及びノードペアは、独自の指示子又は名称を有する。多くのナンバーリングスキームは、両方とも可能である。ＢＧＲは、順次ナンバーリングスキーム、カージナルナンバーリングスキーム、英数字ナンバーリングスキーム（重要度有り又は無し）、又はＢＧＲの緯度及び経度に基づく識別スキームにより順序付けられることができる。内部のナンバーリングスキームは、データベース及びコンピュータの効率に集中されるべきである。ＢＧＲ順序付けスキームのための用いられる値は、エンドユーザに提示される必要はない。ＢＧＲのナンバーリング又は順序付けをエンドユーザに提示することが有益なイベントでは、指示子の参照が容易な（例えば、１、２、３等）エンドユーザＢＧＲを示すために変形が生成されうる。これは、輸送用の自動車のような特定の自動車隊の用途にとって有益であり、ここで、現在、ゾーンは、自動車及び順序を分配するために用いられる。

各ＢＧＲの各ノードに対して、独自の指示子を割り当てることが必要である。ノードペア指示子は、両方のノードに対して独自の指示子になるとともに、関連するＢＧＲに対する指示子になる。ノードペアを完全に記述するために、ＢＧＲ及びノードペアの両方を識別する必要がある。ノードペア指示子のノード部分は、システムと交換可能である。実世界では、各ノードは、ＢＧＲの境界を通過するときに道路上の点を示す。したがって、ノードペア指示子は、２つの位置を与え、これは、同一の道路又は異なる道路のいずれかで、特定のＢＧＲの境界上の両方である。

ＮＰＬＵＴでは、各ノードペアの参照は、各従属変数（例えば、時間、距離、燃料消費、表面道路ナビゲーション等）に対する値を有する。各ナビゲーションでのノードペアを横断することにより、実際の値は、測定又は推定される。実際の値は、ドライバーの年齢、ドライバーの性別、ドライバーの職業、自動車のタイプ、自動車の年数、時刻、曜日、日付、天気等のような旅に関連する独立変数と共にＮＰＬＵＴに記憶される。各ナビゲーションの後、中間ＡＮＯＶＡ及びＭＡＮＯＶＡ値（つまり、合計値、二乗和等）は、記憶され、ノートペアトリップと関連付けられる。このように、特定のユーザがナビゲートするとき、各ノードペアに対する調整された値は、提示されることができる。

各ノードペアに対して与えられた値を調整するために用いられるフィードバックは、簡素な最小二乗誤差算出、直近のイベントをより重く扱う誤差関数、又は他の一般的に使用される制御システム誤差補正方法でありうる。真の予測トラフィックは、対象の従属変数を正確に識別子、対象の独立変数をキャプチャすることにすぎない。データ及び数学が許す限り、システムが同じくらいの精度でトラフィックを予測することを行う。

ＢＧＲ、ノードペア及び独立変数は、サーバベースのナビゲーションにより、現在使用できない手法で使用されることができる。例えば、天気がシカゴの交通に影響を与えることが開始する場合、通常、与えられた時間内にデトロイトに達する。簡素な補助的な処理は、システムに付属されることができ、これは、独立変数に基づいて、シカゴの天気とデトロイトの天気との待ち時間、及び例えば、シカゴからの天気の時間依存可能性が、デトロイトの交通に影響を与える天気になることを推定する。システムは、差し迫った天気又は他の予測可能な将来のイベントに基づいて将来の旅のためのＥＴＡを生成することができる。将来の旅のためのＥＴＡは、データの収集がより確かなものになるように周期的に更新されることができる。

１３個の関連する図面が存在する。
図１は、システム通信の透視図である。 図２は、別の実施形態のシステム通信の透視図である。 図３は、別の実施形態のシステム通信の透視図である。 図４は、別の実施形態のシステム通信の透視図である。 図５は、別の実施形態のシステム通信の透視図である。 図６は、別の実施形態のシステム通信の透視図である。 図７は、本願の新規なシステムにより実施されるハイレベルなソフトウェア方法のためのフローチャートを示す。 図８は、常駐サーバにおける仮想的なテッセレーション（ｔｅｓｓｅｌｌａｔｉｏｎ）を通じてＢＧＲを生成するためのフローチャートを示す。 図９は、常駐サーバにおいてＢＧＲを生成する別の方法を示す。 図１０は、常駐サーバでのカスタマーセットアップを素早く行うためのフローチャートを示す。 図１１は、ＢＧＲ及びノードペアを用いたサーバベースのナビゲーション方法のフローチャートを示す。 図１２は、ハンドヘルド又はリモート電子デバイスソフトウェアプロセスのためのフローチャートを示す。 図１３は、モザイク式（ｔｅｓｓｅｌｌａｔｅｄ）キューブに刻み込まれる地球を示す。

以下の説明は、発明者に現在好ましい実施形態を示す。この説明は、本発明を限定するものではなく、その動作の一般原理を示すためのものである。実施例は、添付の図面によって図示される。

図７は、システムと関連付けられたソフトウェア方法のためのハイレベルなフローチャートを示す。いくつかの動作は、動作のセットアップでのみおこなわれ、初めの９９の開始、２６のマップデータベースのロード、６３のサブルーチンを通じてＢＧＲを生成、及び５６のシステムイニシャライズである。マップデータベース２６は、マップデータベースベンダーから購入される、又はクラウドソースのマップデータベースが使用されうる。システム初期化は、ＮＰＬＵＴを形成すること、利用可能なデータを有するＮＰＬＵＴを追加すること、ユーザデータベースを生成すること、利用可能なデータを有するユーザデータベースを追加すること、及び同様のタスクのような管理上のルーチンを含む。システムが５６で初期化され、ＢＧＲは、ＢＧＲサブ６２により生成され、システムは、５５でナビゲーション入力を取ることができる。

図１３は、モザイク状のキューブ３０２に刻み込まれる地球３０１を示す。コンピュータ上で、仮想的な地球３０１は、対象となる地理的な陸塊が中心となるまで回転又は傾けられる。ほとんど全ての状況下で、地球３０１が、偏球であったとしても、対象の地理的領域は、刻み込まれるキューブ３０２の面とほぼ平行となる。キューブ３０２でのテッセレーションの大きさを適切に選択することにより、地球３０１に投影されるＢＧＲのサイズに影響を与えることができる。地球３０１でのパターンは、技術的にテッセレーションではなく、全てのＢＧＲは、同一形状及びサイズとはならないため、この方法は、バーチャルテッセレーション（Ｖｉｒｔｕａｌ Ｔｅｓｓｅｌｌａｔｉｏｎ）と呼ばれる。

図８は、バーチャルテッセレーションを用いたＢＧＲを生成する方法を示す。初めに、システムは、キューブ４４に地球を描く。４５において、キューブ面の中心は、対象の地理的領域において中心に置かれる。４６において、キューブの面についてのテッセレーションサイズの開始が選択される。標準的な表面積（Ｓｔａｎｄａｒｄ Ｓｕｒｆａｃｅ Ａｒｅａ （“ＳＳＡ”））は、ＢＧＲの対象となる表面積である。約１平方ｋｍのＢＧＲのＳＳＡが理想的とみなされる。次に、６４において、ＳＳＡの変化の限界が設定される。この数値は、小さい値（１０％未満）であるべきである全てのＢＧＲは、困惑するデータ（変化の分析時に非直交な独立した変数）の可能性を最小限にするために、ＳＳＡに非常に近い表面積を有するべきである。必要であれば、４７において、描いたキューブのテッセレーション正方形の大きさが変化する。これは、コンピュータ的により困難であるが、ＳＳＡの変動を最小化する（最も内側のピースが正方形であり、各進んだ層は、さらに高いアスペクト比を有する四角形である）。キューブテッセレーションは、初期のＢＧＲを生成するために地球４８に投影される。全てのＢＧＲのＳＳＡは、４９において、評価される。５０において、ＳＳＡ分析がＯＫである場合、ＢＧＲは、５３において記憶され、５９においてＢＧＲ処理が終了する。５０において、ＳＳＡ分析がＯＫではない場合、全てのＢＧＲは、５１において、消去される。次に、システムは、５２において、開始するテッセレーションサイズを調整し、外側レイヤーテッセレーション比（テッセレーションされたキューブ面の外側レイヤーが、どのくらい早くさらに高いアスペクト比の四角形になるか）は、６３において、調整され、６４において、ＳＳＡ変化限界を調整する。そして、全体の処理は、４７で再び開始される。

図９は、ＢＧＲを生成するための別の実施形態のフローチャートを示す。５８において、処理は、６５において、対象の地理的領域の重心を探すことにより、開始される。単一のＢＧＲは、６６において、少なくとも４つの側面を有し、ＳＳＡと等しい表面積で形成される。ＳＳＡ変化限界は、６４において、設定される。ＢＧＲのレイヤーは、既存のＢＧＲの周りに生成され、ＢＧＲの新たなレイヤーは、６７において、その外周が最小化される。レイヤーのためのＳＳＡは、４９において、分析される。ＳＳＡ分析がＯＫである限り、ＢＧＲの追加のレイヤーが加えられる。５０において、ＳＳＡがＯＫではない場合、ちょうど最後のレイヤーのためのＳＳＡは、６９において、分析される。７０において、最後のレイヤーが、対象の地理的領域の境界と重複するＢＧＲを含み、それが許容できないＳＳＡの唯一の原因である場合、ＢＧＲは、７１において、記憶される。７０において、エッジの地形ではない場合、ＢＧＲの最後のレイヤーは、５１において消去される。許可できる最大外周は、６８において、以前の反復から１０％増加し、ＢＧＲの新たなレイヤーは、６７において、生成される。処理は、７２において、対象の全体地理的領域が、ＢＧＲで覆われるまで継続する。

図７では、６２において、ＢＧＲルーチンが発生されると、６１において、フリートセットアップ（図１０）を発生する。図１０では、各消費者又は自動車隊は、８０において、フリートセットアップで登録される。これは、８１での自動車、８６でのドライバー及び９１でのサービス提供についての情報を有するデータベースを追加することを含む。８１での速い自動車について収集されたデータは、８２での自動車の数、８３での自動車のタイプ（燃料タイプを含む）、８４での自動車のマイル距離、及び８５での他のユーザが定義した自動車データ（独立変数又は属性データ）を含む。ドライバーについて収集されたデータは、８７での名前、８８でのドライバー番号又は識別子、８９での雇用タイプ（会社員、独立請負業者、オーナー／オペレーター等）、及び９０での他のユーザが定義したドライバーデータ（独立変数又は属性データ）を含む。フリートサービスについて収集されたデータは、９２での消費者のタイプ、９３でのサービス標準、９４でのサービスエリア、及び９５での他のユーザが定義したドライバーデータ（独立変数又は属性データ）を含む。データベースは、また、９６でのユーザが定義した給油所も可能にする。データの全てが定義されると、９７において、データベースにロードされ、ルーチンは９８で終了する。

図７からは、３２において、エンドユーザナビ入力要求は、無線手段を通じて受信される。図１は、無線通信及びジオロケーションの実施形態を示し、これは、ナビゲーションにとって必要である。エンドユーザは、自動車２０１にあり、これは、内蔵又は搭載された、リモート電子デバイス（“ＲＥＤ”）を有する。自動車２０１は、ＧＰＳチップセット、ジャイロ及び／又は衛星受信機を通じてジオロケートする。複数の衛星２００は、自動車２０１のＧＰＳ受信機へＧＰＳ信号を提供する。自動車２０１は、無線ネットワーク２０２を用いて、その位置を中央サーバ２０３へ通信することができる。無線ネットワーク２０２は、携帯電話ネットワーク、無線周波数ネットワーク、又は他の無線手段であってもよい。送信は、無線インターネット接続（図示せず）を介してサーバへ要求をダウンロード及びアップロードするＷｉＦｉネットワークのような混合した手段のネットワークに亘ってなされうる。

図２は、通信及びジオロケーションシステムのための別の実施形態を示す。図２では、自動車２０１は、携帯電話、ＭＤＴ又はＲＥＤ２０４に置き換えられる。携帯電話、ＭＤＴ又はＲＥＤ２０４は、衛星ネットワーク２００を通じてジオロケートする。携帯電話、ＭＤＴ又はＲＥＤ２０４は、無線ネットワーク２０２を通じて、サーバ２０３と通信する。

図３は、図２の通信及びジオロケーションシステムのための別の実施形態を示す。このシステムでは、無線ネットワーク２０２は、サーバによるジオロケーション及び通信の両方のために用いられる。携帯電話、ＭＤＴ又はＲＥＤ２０４は、その現在位置を識別するために、複数の携帯電話塔又はアンテナを使用することができる。このデータは、ナビゲーション要求と共に、リモートサーバ２０３へ送信されうる。

図４は、図２の通信及びジオロケーションシステムのための別の実施形態を示す。このシステムでは、衛星２００は、ジオロケーション及び通信の両方のために用いられる。ＧＰＳ衛星が、現在、通信のためのマルチタスクではないが、将来的には、ジオロケーション情報及び通信の両方が、同一の衛星２００によって行われることが考えられる。しかし、このシステムは、現在の衛星のトレンドに基づいて設計されており、衛星２００の１つのセットは、ジオロケーション情報を提供し、別の衛星２００は、リモートサーバ２０３への通信のために用いられる。

図５は、図１の通信及びジオロケーションシステムのための別の実施形態を示す。このシステムでは、無線ネットワーク２０２は、サーバによるジオロケーション及び通信の両方のために用いられる。自動車２０１は、その現在位置を識別するために、複数の携帯電話塔又はアンテナを使用することができる。このデータは、ナビゲーション要求と共に、リモートサーバ２０３へ送信されうる。

図６は、図１の通信及びジオロケーションシステムのための別の実施形態を示す。このシステムでは、衛星２００は、ジオロケーション及び通信の両方のために用いられる。衛星２００の１つのセットは、ジオロケーション情報を提供し、別の衛星２００は、リモートサーバ２０３への通信のために用いられる。

図７では、エンドユーザナビ要求３２は、図１から図６の通信及びゲオロケーションシステムの１つを通じて通信される。自動車２０１又は携帯電話、ＭＤＴ又はＲＥＤ２０４のいずれかであっても、ユーザは、一般的には、ユーザアプリケーションと呼ばれるユーザソフトウェアを通じてシステムとやりとりする。図１２では、１０１において、ユーザアプリケーションは、ユーザが１０２で登録されたことを確実することにより開始する。１０２において、ユーザが登録された場合、１２８において、目的地の入力が発生する。ユーザは、１２７及び１２８において、順番を特定する又はシステムに旅を順序付けることを可能にする複数の目的地を追加することができる。１２７において入力が完了すると、データは、１２９において、図１−６に示される手段を通じてリモートサーバへ送信される。この時点では、リモートサーバ２０３を、１２８での目的地入力で与えられたナビゲーションルートを生成するブラックボックスとして扱う。リモートサーバ２０３は、１２９において、エンドユーザにより受信されるルートを送信する。予め決定された間隔で、１０１でのエンドユーザのアプリケーションは、１３０において、１２６でのその位置の送信により、リモートサーバ２０３のピング（ｐｉｎｇ）を行う。リモートサーバ２０３は、ユーザの進捗を、リモートサーバが、ユーザの進捗であると予測したものと比較する。目的地へ向かう過程が、許容できる基準外である場合、リモートサーバ２０３は、１０１でのユーザのアプリケーションへ１２５での再ルート信号を送信する。エンドユーザのユニットは、再ルートをエンドユーザに通知する一方で、リモートサーバ２０３は、別のルートを提供する。新たなルートは、１０１でのエンドユーザのアプリケーションにより受信される。最終的には、再ルートしたかどうかに関わらず、エンドユーザは、１２４において、目的地に到着する。目的地に到着した後に、１０１でのエンドユーザのアプリケーションは、リモートサーバが、旅の完全な履歴を有するように、リモートサーバ２０３へ最後のピングを送信する。

１０１でのエンドユーザのアプリケーションが開始したとき、ユーザが登録されていない場合には、ユニットは、１０３でのアカウントを有効にすることにより登録されることができる。１０３でのアカウントを有効にすること後に、ユーザは、１０４でピング頻度を選択し、１０６でナビゲーションの優先度を選択し、１０５でナビゲーションの除外を選択する。ユーザは、彼ら自身又は彼らの自動車に関する独立変数を完了させなければならない。１０７において、ドライバー情報は、１０８での運転年数、１０９での運転記録、１１０での年間運転距離、１１１での年齢、１１２での配偶者の有無、１１３での住所１１４での運転するためのユーザ学習、１１５でのユーザの職業、１１６でのユーザの性別、及び１１７での他の会社又はグループが定義したデータを含む。１１８での自動車情報は、１１９での自動車の所有者、１２０での製造メーカ及びモデル、１２１でのモデル年度、及び１２２での自動車の走行距離を含む。質問に回答するそれらの精度が、どの程度システムがナビゲートできるのかということに直接関連しているとユーザが気付くため、独立変数データは、非常に高い質であるべきである。

図７は、３２において、６０でのガイダンスがエンドユーザ入力の後に生じることを示す。図１１では、６０でのガイダンスは、１でのナビ最適化要因を選択することにより開始する。ＢＧＲが生成されると、本発明が解を生成することが可能になる。図１１は、単一の自動車ナビゲーション解を示す。ユーザは、１において、最適化要因又は従属変数、つまり、時間、距離、燃料、費用又はユーザが定義した従属変数を選択することにより開始する。次に、ユーザは、必要に応じて、２において、インターステイト、有料道路、橋又は他の潜在的なルートのような考慮事項から特定の解を排除する。ユーザは、３において、入力装置を用いて一又はそれ以上の目的地を入力する。１つ以上の目的地を入力する場合、ユーザは、６において、目的地を１０での自動又は５での手動の順序で選択することができる。５での手動の順序を選択した場合、１０での自動目的地順序付けモジュールは、手動入力を保留する。順序が付けられると、出発点及び次の目的地は、９において、識別される。７の開始時に単一の目的地しか存在しない場合、ナビゲーションコアは、９での出発点及び目的地の識別に直接移動する。

出発点及び目的地を算出するために、本発明は、出発点及び目的地間で直線的に存在し、それらをアクティブとして指定するＢＧＲを識別する。これらのＢＧＲは、Ｇｅｎ１と呼ばれる。出発点を含むＢＧＲでは、出発点は、１２での単独入口ノードに指定される。９における現在の目的地を含むＢＧＲでは、現在の目的地は、単独出口ノードとして指定される。全ての他のＢＧＲでは、ノードペアは、１１での両側でＢＧＲを有するこれらのノードを選択するのみにより、生成される。ナビゲーションコアは、１６において、全てのアクティブなＢＧＲのためのノードペアリストを生成する。マルチプロセッサシステムでは、ナビゲーションコアは、２０での考慮下での全てのノードペアに対する一時的なＢＧＲアレイを同時に生成し、１７での考慮下での任意のノードペアに対して解が存在するのか確かめるために、１４でのＮＰＬＵＴを調査する。ノードペアの解がＮＰＬＵＴに存在する場合、２０において、一時的なＢＧＲアレイに配置される。ノードペアの解がＮＰＬＵＴに存在しない場合、各道路の分類に対して重み付け関数を用いて、本発明は、１９において、各ＢＧＲの各ノードペアに対する従属変数演算を行い、各潜在的な解に対するルート情報をキャプチャする。本発明は、２１において、潜在的な解のセットから除外項目を削除する。ＢＧＲの制限されたセットのみが、初期の演算に用いられるため、各ＢＧＲの全てのノードが、潜在的な入口及び／又は出口であるとは限らない。対象のノードから生成されたデータは、一時的なデータベースフォーマット又は２０において素早くアクセス可能な任意の他のデータハンドリングフォーマットでアレイに記憶されうる。この一時的なデータは、ハードドライブのキャッシュストレージ、又は任意の他のタイプの適切なメモリ素子に記憶されうる。マルチコアプロセッサ環境では、各ＢＧＲが、独立に演算されうるため、このような演算は、迅速に行われる。

本発明は、出発点から目的地への初期の最小の解を探索し、出発点と目的地との間に直線的に存在するＢＧＲを通じてのみ移動することにより初期のトライアルルートを生成する。初期ルート演算のための境界条件として、１つのＢＧＲの出口ノードは、隣接するＢＧＲの入口ノードである。取り得る解のマトリックスを生成することにより、本発明は、明確な解を生じる。

初期トライアルルートが識別されると、ソリューションエンジンは、Ｇｅｎ１及び１８，２３でのＢＧＲに隣接する全てのＢＧＲを追加し、上記の処理を主に繰り返す。新たなＢＧＲは、Ｇｅｎ２と呼ばれる。Ｇｅｎ１ＢＧＲは、ここで、演算の全てのノードを使用する。全てのノードが、それらに関連付けられた隣接するＢＧＲを有するとは限らないため、Ｇｅｎ２ＢＧＲは、ノードの減少されたセットを使用する。

Ｇｅｎ ２のトライアルルートを演算するために、Ｇｅｎ１の演算で算出された潜在的な解は、それらが、２０での一時的なアレイで見いだされるため、除外される。本発明は、また、１つのＢＧＲの出口ノードが、隣接するＢＧＲの入口ノードである境界条件を適用する。（Ｇｅｎ１の解を除外した）取り得るユニークな解のマトリックスを生成することにより、本発明は、Ｇｅｎ２のトライアルルート２２において、明確な解を生じる。

処理は、２３，１８でのＧｅｎ２と同様に、Ｇｅｎ３のために繰り返される。Ｇｅｎ２ＢＧＲに隣接する全てのＢＧＲは、演算に加えられる。全ての以前に考慮されたトライアル解は、潜在的な解のセットから除外される。Ｇｅｎ３のトライアルルートに対する明確な解は、算出される。

最適解をＧｅｎ Ａと呼ぶ。出口基準は、Ｃの生成が完了するように選択され、ここで、Ｃ＝Ａ＋Ｂであり、Ｃは、生成の総数であり、Ａは、最適な生成であり、Ｂは、最適解の後に算出された所望の発散解の数である。例えば、Ｇｅｎ１のトライアルルートが、Ｇｅｎ ２又はＧｅｎ ３のトライアルルートに好ましく、演算を停止する場合、好ましいルートとしてＧｅｎ１のトライアルルートをユーザに提示し、Ｃ＝３， Ａ＝１及びＢ＝２である。

実際には、Ｂは、２３での出発点と目的地との距離に関連する。また、Ｂの選択は、簡素な誤差フィードバック機能を通じて最適化されることができ、ここで、誤差は、距離に関連する。Ｂの上限は、最大速度限界によって設定される。すなわち、処理は、現在利用可能な解ではなく従属変数へのより好ましい解を提示するために、自動車が、最大許容速度限界の周辺を超えたときに、終了する。

Claims (13)

1. ナビゲーションガイダンスの方法及びシステムであって、目的地を入力し、ガイダンス又はルートを受信する手段を有するエンドユーザデバイスと、道路及び追加でＰＯＩを含むマップデータベースと、を最低限含み、グローバルポジショニングシステムのような自動車の位置を決定するための装置及び方法と、サーバ又はメモリ及び処理素子の他の集合体と、前記エンドユーザデバイスと前記サーバとを通信する手段と、前記サーバに常駐するナビゲーションソフトウェアコアと、を備え、前記ナビゲーションソフトウェアコアは、境界地理的領域（ＢＧＲｓ）を生成し、潜在的な解の一部である各ＢＧＲのためのノードペアを識別し、ユーザにより提供される従属変数及び解のデータベースの本質的な部分である独立変数に基づいてナビゲーション解を最適化する機能を有する、方法及びシステム。
2. 各ノードペアのための明確な解を、初めに、部分的に又は完全にロードするノードペアルックアップテーブル（ＮＰＬＵＴ）データベースをさらに含む請求項１に記載の発明。
3. ソフトウェアは、前記ＮＰＬＵＴデータベースに記憶された従属変数値を補正するために、誤差関数演算器及びフィードバックルーチンを含む請求項２に記載の発明。
4. 時間、距離、燃料消費量、費用及びユーザが定義した従属変数のような従属変数と共に、前記従属変数に対する各ノードペア解のための各エンドユーザの実際の値は、エンドユーザが目的地に着くまでの間又は目的地についた後、ＮＰＬＵＴに送られて記憶される、請求項２に記載の発明。
5. 前記ＮＰＬＵＴの各従属ノードペアに対する関連する独立変数要因は、時刻、日付、曜日、温度、工事、降水量、ドライバーの年齢、ドライバーの職業、ドライバーの性別、自動車のタイプ、自動車の年数、自動車の走行距離、及び将来のナビゲーション時により正確な推定を与えるために、前記ＮＰＬＵＴに記憶される従属変数のＡＮＯＶＡ及びＭＡＮＯＶＡ演算を生成するために用いられることができる特別なイベントのような変数及び属性の両方をキャプチャ及び記憶されるが、これに限定されない、請求項２に記載の発明。
6. 前記ＮＰＬＵＴデータベースは、必要なＡＮＯＶＡ又はＭＡＮＯＶＡ合計値及び以前のナビゲーション反復からの成果物のみを記憶し、合計値及び成果物が算出された、内在するデータを削除することにより圧縮される請求項５に記載の発明。
7. 前記ＢＧＲは、モザイク式（ｔｅｓｓｅｌｌａｔｅｄ）キューブ又は区分されたキューブに地球を刻み込み、前記地球の表面に前記キューブからのテッセレーション又は区分を投影することによる仮想テッセレーションにより生成される請求項１に記載の発明。
8. 前記キューブのテッセレーションパターンは、正方形及び四角形で構成され、その面積は、前記四角形が前記キューブの面の中心とは異なるように地理的に減少し、そのアスペクト比は、前記キューブの面の中心からの距離が増加する、請求項７に記載の発明。
9. 各ノードペアの解は、マルチプロセッサ構成における異なるプロセッサを用いて算出される請求項１に記載の発明。
10. 前記ナビゲーションソフトウェアコアは、解が十分に発散するまで、又は出発点から目的地への線に直交する最後のＢＧＲレイヤーが、自動車が、現在の最良解によって定義される時間での最大公示速度限界で移動しうる距離を超えるまで、より多くのＢＧＲを用いてルートを反復算出する請求項１に記載の発明。
11. エンドユーザのデバイスメモリは、アクティブなＢＧＲからの詳細のみを記憶する請求項１に記載の発明。
12. 前記サーバとの通信は、自動車、携帯電話、携帯データ端末又はリモート電子デバイスへの無線又は衛星接続を介して行われる請求項１に記載の発明。
13. 前記サーバは、ノードペアに関連付けられた可変又は属性データのいずれかとしてＮＰＬＵＴに含むためのＮＨＴＳＡ交通センサ情報、警察のレポート、ローカル交通レポート及び工事レポートを含む他のデータソースからのデータを収集するが、これに限定されない、請求項１に記載の発明。

Images