(57)【要約】  本明細書において「仮想データベースシステム」（ＶＤＢ）と呼ばれる仮想地図データを提供するシステム及び方法。ＶＤＢは、エンドユーザに供給するために、多くの場合は種々の供給元から取得される地図データを一貫して統合できるようにすると同時に、ある特定のデータ供給元を最適にサポートできるエンティティがそのデータに対する制御を保持することを保証できる。一実施形態によると、ＶＤＢ環境により、第三者データプロバイダは、自身の第三者ファイルを基本地図又は参照ファイルに関連付けることができ、それによってデジタル地図特徴と他の第三者データプロバイダとの間の動的な関係の作成が可能になる。統合は、必要に応じて又はオンデマンドで、種々の供給元から最新情報を受信し、リンクを作成し且つ仮想地図を構成することにより、動的に又はリアルタイムで実行されてもよい。情報が地図プロバイダと種々の第三者との間でリンクされるため、情報の項目又は項目間のリンクが参照ファイル又は第三者ファイルの１つのいずれかで更新される場合は必ず、その更新された情報は、第三者のソフトウェアアプリケーションで更に使用するために全ての第三者に伝搬される。
2009536372.tif 000002
【特許請求の範囲】
【請求項１】
仮想データベース形式のデジタル地図データを提供するシステムであって、
地図の領域を範囲に含み、且つ前記地図内の特徴の場所コードを含む電子地図データと、
前記地図の領域内に地理的に配置された前記特徴の一部又は全部の追加特徴情報を定義する第三者データを前記システム内に受信できるようにするインタフェースと、
前記電子地図データ内の場所コードと前記第三者データ内の対応する特徴情報とをリンクし、前記リンクされた情報を仮想データベースとして提供する統合データベースとを備えることを特徴とするシステム。
【請求項２】
前記仮想データベースは電子地図データであり、地図表示を生成するために使用され、前記地図表示は前記第三者データにより提供される前記特徴情報を含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記場所参照は、地図上の特定の各場所に一意に割り当てられる汎用的位置参照であることを特徴とする請求項１に記載のシステム。
【請求項４】
前記第三者データは、第三者により別個に保守され、実行時又は前記仮想データベースの作成要求時に前記電子地図データと組み合わされることを特徴とする請求項１に記載のシステム。
【請求項５】
前記システムは前記第三者データを含むことを特徴とする請求項１に記載のシステム。
【請求項６】
前記システムは、ネットワーク又は他の接続を介して外部の第三者供給元から前記第三者データを受信することを特徴とする請求項１に記載のシステム。
【請求項７】
前記ネットワーク又は他の接続はインターネットであることを特徴とする請求項６に記載のシステム。
【請求項８】
前記システムは、情報を複数の第三者から同時に受信することを特徴とする請求項１に記載のシステム。
【請求項９】
前記仮想データベースは、第三者からのリアルタイムデータの受信時又はユーザからの要求時に前記システムにより動的に作成されることを特徴とする請求項１に記載のシステム。
【請求項１０】
前記仮想データベースは、他のデータ供給元から独立して、前記電子地図データ又は前記第三者データの一部又は全部に対する更新により自動的に更新されることを特徴とする請求項１に記載のシステム。
【請求項１１】
仮想データベース形式のデジタル地図データを提供する方法であって、
地図の領域を範囲に含み、且つ前記地図内の特徴の場所コードを含む電子地図データを提供するステップと、
前記地図の領域内に地理的に配置された前記特徴の一部又は全部の追加特徴情報を定義する第三者データを受信するステップと、
前記電子地図データ内の場所コードと前記第三者データ内の対応する特徴情報とをリンクする統合データベースを、前記リンクされた情報を仮想データベースとして提示するために使用するステップとを有することを特徴とする方法。
【請求項１２】
前記仮想データベースは電子地図データであり、地図表示を生成するために使用され、前記地図表示は前記第三者データにより提供される前記特徴情報を含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記場所参照は、地図上の特定の各場所に一意に割り当てられる汎用的位置参照であることを特徴とする請求項１１に記載の方法。
【請求項１４】
前記第三者データは、第三者により別個に保守され、実行時又は前記仮想データベースの作成要求時に前記電子地図データと組み合わされることを特徴とする請求項１１に記載の方法。
【請求項１５】
前記システムは前記第三者データを含むことを特徴とする請求項１１に記載の方法。
【請求項１６】
前記システムは、ネットワーク又は他の接続を介して外部の第三者供給元から前記第三者データを受信することを特徴とする請求項１１に記載の方法。
【請求項１７】
前記ネットワーク又は他の接続はインターネットであることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記システムは、情報を複数の第三者から同時に受信することを特徴とする請求項１１に記載の方法。
【請求項１９】
前記仮想データベースは、第三者からのリアルタイムデータの受信時又はユーザからの要求時に前記システムにより動的に作成されることを特徴とする請求項１１に記載の方法。
【請求項２０】
前記仮想データベースは、他のデータ供給元から独立して、前記電子地図データ又は前記第三者データの一部又は全部に対する更新により自動的に更新されることを特徴とする請求項１１記載の方法。
【請求項２１】
命令が格納されたコンピュータ可読媒体であって、前記命令は実行される場合に、
地図の領域を範囲に含み、且つ前記地図内の特徴の場所コードを含む電子地図データを提供するステップと、
前記地図の領域内に地理的に配置された前記特徴の一部又は全部の追加特徴情報を定義する第三者データを受信するステップと、
前記電子地図データ内の場所コードと前記第三者データ内の対応する特徴情報とをリンクする統合データベースを、前記リンクされた情報を仮想データベースとして提示するために使用するステップとをコンピュータに実行させるコンピュータ可読媒体。
【請求項２２】
仮想データベース形式のデジタル地図データを提供するシステムであって、
地図の領域を範囲に含むデータと、前記地図内のオブジェクトの場所コードとを含む参照データベースと、
前記地図内に出現可能なオブジェクトの属性データを含む１つ以上の第三者データベースと、
前記参照データベース及び前記１つ以上の第三者データベースからのリンクされた情報を含むデータをエンドユーザに提供する仮想データベースであって、前記参照データベース内の前記オブジェクトと前記１つ以上の第三者データベース内の前記オブジェクトとの間の情報及び関係を判定するために前記ユーザが問い合わせを行なうことを可能にする仮想データベースとを備えることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００６年５月２日出願の米国仮出願第６０／７９７１３０の優先権を主張して２００７年５月１日に出願した米国出願第１１／７４２９３７号の優先権を主張するものであり、その出願を引用することによってその内容をここに合体する。
【０００２】
本発明は、デジタル地図を提供するシステムに関し、特に、仮想データベース技術を使用してデジタル地図情報を提供するシステム及び方法に関する。
【背景技術】
【０００３】
デジタル地理データ又はデジタル地図データの使用は、現代社会において普及している。一般に「電子地図」又は「デジタル地図」と呼ばれる地図データは、多種多様な用途に既に使用されている。典型的な用途は旅行業界においてであり、デジタル地図は、旅行目的地、行楽地施設及び代替ルートを調べるために使用される。多くの場合、インターネットを使用する会社対消費者（Ｂ２Ｃ）会社は、劇場、店舗、レストラン及び他の営利事業に顧客を誘導するためにデジタル地図を使用する。デジタル地図は、例えば、配達運転者のルートを計算するため、あるいは緊急呼出しへの応答時に救急隊又は医療隊が向かう方向を提供するため等、産業環境において使用されることも多い。
【０００４】
デジタル地図プロバイダは、紙ベースの地図を単にデジタル化する処理から次第に切り替わり、現在では、最新のアプリケーションをサポートするために、所在地住所、交通ネットワーク、水域、公園用地選挙区、国勢データ、人口学的情報、営利事業及び娯楽施設等のトピックを含む益々多様なデータを収集及び編成するものとして考えられるのが適切である。同時に、この地図データの種々の使用も、車載運転補助、ＰＤＡ及び携帯電話を使用するナビゲーション、並びに地方に焦点を当てたニュース、メディア及び職業別電話帳情報サービス等の用途を含むように拡大した。実用性が増すにつれて、これらのソフトウェアアプリケーションの多くは、より有用な最終製品を提供するために、基本となる地図データを他の場所関連情報供給元と組み合わせる必要があることが明らかになった。
【０００５】
いくつかの会社は、単一の地図データベースのコンテンツをより豊富にしようと独自に試みた。しかし、デジタル地図会社にとって、ありとあらゆる注目場所の属性を含むこれらに関する大量の情報を継続的に収集及び保守することは、効率的ではなく又望ましくない。その代わりデジタル地図会社は、理想的には、最も得意なこと、すなわち正確なデジタル地図の作成に集中できるべきである。地図事業のこの面に集中し且つ自身のデジタル地図データを他の組織のデジタル地図データと高度に統合することにより、全ての関係者は、自身のデータ製品及びそれらを使用するアプリケーションの価値を高めることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
地図データ統合の典型的な手法は、「オーバーレイ地図」を作成することである。オーバーレイ地図において、１つのデジタル地図は基本地図として使用され、別の供給元（又は複数の供給元）からの追加情報はその基本地図の上に重ねられ、より複雑な地図の少なくとも錯視を与える。これは、インターネットを使用する多くの地図情報システムにおいて使用される手法である。例えば、ある会社がオンラインレストラン探索ユーティリティを提供したい場合、それらは第１の地図Ａ（これは、街路、公園及び他のそのような場所を示す典型的な地図であってもよい）を提供できる。その後それらは、レストランの情報及びレビューを含む第２の地図Ｂを地図Ａに重ねることができる。レストラン地図に対するユーザ要求に応答して、会社は、一致するレストランが地図上でフラグとして示されるように、地図Ｂの一部又は全部を重ねられた地図Ａの一部又は全部を表示できる。この処理は、情報を非常に豊富に含む地図という印象を与えるために、多くの地図を互いに重ね合わせるように拡張される。しかし、この技術の問題は、それが非常に単純であるため有用性が制限されることである。地図を重ねる処理は、単一の統合地図の錯視を与えるにすぎず、地図項目自体は種々の地図間で関連付けられない。そのため、オーバーレイ地図は単純な視覚的印象の提供に限定される。オーバーレイ地図は、１つの地図項目から次の地図項目にジャンプするために必要な関係情報を含まないため、ユーザが更に探索するためには使用されない。更に、重ね合わせにおいて、地図項目間の関係が基本的に無視されるため、精度に関して問題が生じる場合がある。すなわち、単純に特徴（features）は最終画像内に適切に並ばない場合がある。この種類の地図の商業的用途は、一般に、Yahoo、Citysearch、Google、並びに他のオンラインディレクトリ及び情報サービスのユーザに周知の地図表示の提供に限定される。
【０００７】
地図情報の正確な統合に関する更なる問題は、種々のデータセット間の一貫性を維持することである。単一のアプリケーションが種々のデータ収集努力により集められた情報を使用する場合、一貫性を失う危険が常に存在する。この危険は、データが組織内のリソースから収集される場合であっても存在するが、データが他の第三者から収集される場合は高まる。１つの手法は、全ての所望の情報を共通のリポジトリ又はデータベースに維持又は格納することである。しかし、益々大量のデータが追加されるにつれて、データベースが非常に複雑且つ煩雑になるため、性能要件及び保守要件は不適格になる場合がある。データの所有権もより複雑になり、第三者の多くは、自身の特定のデータに対する完全な制御及び所有権を保持することを好み、自身のデータを共通データベースに占有されたくないだろう。多くの場合、第三者は、自身の特定のデータの精度及び新鮮度を最も維持できるエンティティでもある。元のデータ供給元から頻繁な更新データをもはや受信しないモノリシックデータベースにデータが統合された場合、この精度は失われる可能性がある。精度及び整合性に関するこれらの考察は、地理空間データの問題を考慮する場合に次第に行われるようになってきた。これは、この問題に対処することが社会学的に考えることを更に必要とし、すなわち、最も高品質のデータは、それに既得権利を有するものにより生成されると考える必要があるためである。例えば、顧客を引き寄せようとするホテルチェーンは、正確な方向を顧客に提供することが極めて重要であると考え、実際、彼らの事業はこの機能性に依存する。いくつかのベンダにとって、対話型局所地図は最も重要な広告源の１つだろう。また、局所知識は、近隣情報又は地域社会情報等の局所情報を表す場合に最適な知識であると考えられる。これらの各例において、独自のデータ供給元を生成する第三者は、単一のデータベースを運営する中央集中的な地図データ会社より、局所重視データ又は局所集中データの作成及び更新に適すると位置付けられてもよい。
【０００８】
集中格納式又はモノリシック式地図データベースには欠点があるが、会社が種々のデータ供給元からの情報の所望の統合をエンドユーザに提供する場合、このデータの何らかの形態の中央調整が依然として行われる必要がある。中央調整は、データ収集努力が標準化され且つ包括的であることを保証する。これは、ソフトウェアアプリケーションが使用できる広い地理領域にわたって一貫した魅力的な体裁を有する高品質製品を製造する場合に重要な要素である。経験上、ある特定のデータモデル又はスキーマの自由度が高いほど又は融通性が大きいほど、データをそのスキーマへインポートすることが容易になる。その反対に、スキーマの融通性が小さいほど、データのインポートは困難になり、情報がインポート処理中に失われる可能性が高くなる。これは、特定の世界観が強要される場合に発生する問題である。秩序を提供するためには任意の共通データ構造が必要とされるが、地図が表す世界は自己矛盾を含む場合があり、多くの異なる観点から見ることができる。理想的には、デジタル地図は、アプリケーションの機能要件を満たすため及び美しい体裁を生成するために、スキーマ内に十分な秩序を課す必要がある。これ以上に融通性のないスキーマを課すことは、弊害をもたらす。
【０００９】
デジタル地図作成の別の重要な要素は品質制御である。自動化されたデータ収集及び処理アルゴリズムは、人間が対抗できない高速且つ論理的に一貫した態様で情報を操作できる。しかし、ある特定の種類のデータ問題の識別及び補正において、人間の知能に代わるコンピュータ化された代用品は存在しない。また、人間のオペレータは、デジタル地図が複製しようとする世界の適切な表現であるか否かをより適切に判定できる。従って、任意のマッピング環境において、データの視覚化に最適なツールを有することは、品質の面で重要である。上述のように、第三者は、これらの必要な品質制御検査及び補正を実行するのに最適な立場にいるだろう。
【００１０】
個別に見た場合、これらの観察の多くが相反する考察、特に、種々のデータ供給元を統合するデジタル地図製品を作成したいという欲求と同時に、異なるエンティティがそれらの種々のデータ供給元に対する制御を保持できるようにすることを提案していることに読者は気付くだろう。最適な設計は、これらの考察を適切に均衡を取る必要がある。特に、設計は、一貫性及び融通性のある統合手段を考慮すると同時に、任意のデータ供給元に対する制御がそのデータの品質及び精度を保証するのに最適なエンティティに維持されるようにする必要がある。多くの場合、これは、最終地図製品全体に対する制御をデジタル地図プロバイダ会社と１つ以上の第三者会社との間で共有することを意味する。別の重要な点は、エンドユーザのアプリケーションにおいて有用にするために、任意の第三者アプリケーションデータ又は外部から供給されたアプリケーションデータは、例えばデジタル地図において使用される道路ネットワークと一致するか又はそれと整列し、単一の単純な共通インタフェースを介してアクセス可能であり、標準的な方法での（例えば、識別子、座標ウィンドウ、住所、オブジェクトの種類又は分類、及び／又は別のオブジェクトに対する関係による）照会が可能である必要がある。現在に至るまで、これらの利点を提供する利用可能なシステムは存在しない。
【課題を解決するための手段】
【００１１】
概要
本明細書において開示されるように、デジタル地図情報を提供するシステム及び方法を説明する。「仮想データベースシステム」（ＶＤＢ）は、エンドユーザに供給するために、多くの場合は種々の供給元から取得される地図データの一貫した統合を可能にすると同時に、ある特定のデータ供給元を最適にサポートできるエンティティがそのデータに対する制御を保持することを保証するという明らかに相反する考えの均衡を取るものである。特にＶＤＢにより、デジタル地図プロバイダと１つ以上の第三者との間又は複数の第三者間での最終地図製品全体に搭載される各構成要素に対する制御及び所有権の共有（又は、場合によっては制御及び所有権の委譲）が可能になる。一実施形態によると、ＶＤＢ環境により、第三者データプロバイダは、自身のデータ又は「第三者ファイル」をデジタル地図プロバイダの「基本地図」又は「参照ファイル」に容易に関連付けるか又はジオコードすることが可能になり、それによりデジタル地図特徴と他の第三者データプロバイダとの間の動的な関係の作成が可能になる。また、ＶＤＢは、複数のベンダから取得されシームレスに統合されたデータを単一の機構を介して購入及び検索し、その後そのデータをエンドユーザに提供するために、アプリケーションプロバイダによりアクセスされてもよい。本明細書において開示されるように、参照ファイルは、地理データを格納するために使用される地理空間データベース、データ構造、文書又はデジタル地図であってもよい。同様に、第三者ファイルは、地理データを格納するために使用される地理空間データベース、データ構造、文書又はデジタル地図であってもよい。ある特定の実施形態において、統合は、必要に応じて又はオンデマンドで、種々の供給元から最新情報を受信し、リンクを作成し且つ仮想地図を構成することにより、動的に又はリアルタイムで実行される。更なる利点は、情報が地図プロバイダと種々の第三者との間でリンクされるため、情報の項目又は項目間のリンクが参照ファイル又は第三者ファイルの１つのいずれかで更新される場合は必ず、その更新された情報が第三者自身のソフトウェアアプリケーションで更に使用するために全ての第三者に伝搬される点である。そのため、各関係者は、自身のデータセットに対する制御を維持するが、更新又は補正された情報を他の各関係者から自動的に受信することを選択した場合はそのように受信することができ、その後、自身のデータセットを独自に更新するように選択できる。このように、全員が、更新された情報を自動的に共有できることから利益を得る。
【発明を実施するための最良の形態】
【００１２】
本明細書において開示されるように、デジタル地図情報を提供するシステム及び方法を説明する。「仮想データベースシステム」（ＶＤＢ）は、エンドユーザに供給するために、多くの場合は種々の供給元から取得される地図データの一貫した統合を可能にすると同時に、ある特定のデータ供給元を最適にサポートできるエンティティがそのデータに対する制御を保持することを保証するという明らかに相反する考えの均衡を取るものである。特にＶＤＢにより、デジタル地図プロバイダと１つ以上の第三者との間又は複数の第三者間での最終地図製品全体に搭載される各構成要素に対する制御及び所有権の共有（又は、場合によっては制御及び所有権の委譲）が可能になる。一実施形態によると、ＶＤＢ環境により、第三者データプロバイダは、自身のデータ又は「第三者ファイル」をデジタル地図プロバイダの「基本地図」又は「参照ファイル」に容易に関連付けるか、ジオコードするか又は配置することが可能になり、それによりデジタル地図特徴と他の第三者データプロバイダとの間の動的な関係の作成が可能になる。また、ＶＤＢは、複数のベンダから取得されシームレスに統合されたデータを単一の機構を介して購入及び検索し、その後そのデータをエンドユーザに提供するために、アプリケーションプロバイダによりアクセスされてもよい。本明細書において開示されるように、参照ファイルは、地理データを格納するために使用される地理空間データベース、データ構造、文書又はデジタル地図であってもよい。同様に、第三者ファイルは、地理データを格納するために使用される地理空間データベース、データ構造、文書又はデジタル地図であってもよい。ある特定の実施形態において、統合は、必要に応じて又はオンデマンドで、種々の供給元から最新情報を受信し、リンクを作成し且つ仮想地図を構成することにより、動的に又はリアルタイムで実行される。更なる利点は、情報が地図プロバイダと種々の第三者との間でリンクされるため、情報の項目又は項目間のリンクが参照ファイル又は第三者ファイルの１つのいずれかで更新される場合は必ず、その更新された情報が第三者自身のソフトウェアアプリケーションで更に使用するために全ての第三者に伝搬される点である。そのため、各関係者は、自身のデータセットに対する制御を維持するが、更新又は補正された情報を他の各関係者から自動的に受信することを選択した場合はそのように受信することができ、その後、自身のデータセットを独自に更新するように選択できる。このように、全員が更新された情報を自動的に共有できることから利益を得る。
【００１３】
実施例に応じて、仮想データベースシステムにより、多くの供給元からの地図情報又は第三者ファイルをリアルタイムで高度に組み合わせ、その後、ユーザの要求に応答してユーザに提示することが可能になる。このように、地図情報は、要求の受信及び応答時にのみ検索、リンク及び統合されるため、提供された情報は可能な限り最新であることが保証される。他の実施例において、仮想データベースシステムにより、製品構築時に、すなわち、ある特定の地図を使用するソフトウェア製品が顧客に出荷するために構築される時に、多くの供給元からの地図情報を高度に組み合わせることが可能になる。ＶＤＢは、最新情報が構築時に製品に統合されることを保証する。更に他の実施例において、仮想データベースシステムは、他のシステムが更に使用するために、複数の供給元から供給された地図情報を他のシステムに自動通信するために使用される。
【００１４】
地図を形成するために使用される情報が仮想的に格納されるため、すなわち要求に応答して動的に作成されるため、この情報は単一のデータベース構造内に中央配置される必要がない。しかし、いくつかの実施例において、特にシステムが同一の地図データに対する多くの後続の要求に応答している場合、後で使用するために、この仮想地図をキャッシュ内に位置付けるか又は格納することが望ましいだろう。
【００１５】
仮想地図を作成することにより、種々の情報、すなわち第三者ファイルが異なる商業エンティティにより供給及び維持され且つ互いから独立して変更又は更新されることが可能になる。実際には、エンドユーザの観点から見ると、ユーザは、重要な全情報を含む単一の地図を認識する。データプロバイダの観点から見ると、システムにより、単一の均一な製品を提供するために、複数のエンティティにより所有及び制御される情報の共有が可能になる。
【００１６】
一実施形態によると、仮想データベースシステムは、デジタル地図データプロバイダ（例えば、本明細書の説明において「デジタル地図プロバイダ」と総称されるTele Atlas又は別の商業マッピング会社）のデジタル基本地図製品と、１つ以上の第三者（例えば、旅行関連情報、近隣情報、局所情報、職業別電話帳情報、ディレクトリ情報又は同様の情報を専門とするYahoo、Google、Citysearch、Expedia、Travelocity又はZagat等の会社）の製品とを組み合わせる場合に特に役立つ。ＶＤＢを用いる手法を使用することにより、デジタル地図プロバイダにより提供されるデジタル基本地図又は参照ファイル情報は、ある特定の製品の構築中に又は仮想デジタル地図の作成時にリアルタイムで、種々の第三者からのデータと組み合わされる。より正確にするために、第三者データプロバイダは、基本地図又は参照ファイルと一貫する自身のデータファイルをジオコードできる。例えば第三者データプロバイダは、一致する緯度／経度情報を使用してもよく、第三者ファイル内のＵＬＲＣを用いて参照ファイル内の住所をマッピングしてもよく、又はオブジェクトコード及び場所コードの組合せを使用してもよい。また、第三者データプロバイダは、基本地図又は参照ファイルと空間的に位置合わせされた特徴を地理的に符号化するか又は基本地図内の地理的場所に関連付けることにより、これらの特徴を位置付けられる。
【００１７】
いくつかの実施形態によると、更に仮想データベースシステムにより、第三者データプロバイダは、固有の識別子を使用して自身のデータを基本地図又は参照ファイル内の特徴にリンクできる。統合が動的に又はアプリケーションの構築要求時に実行されるため、１つのデータ供給元が変更される場合（例えばZagatのデータベース内のレストランレビューが変更される場合）は常に、情報はユーザの要求時に仮想地図に動的に埋め込まれる。
【００１８】
いくつかの実施形態によると、参照ファイルと種々の第三者データ供給元との間のリンクは、汎用的位置情報参照オブジェクト（ＵＬＲＯ）により提供される。以下に更に詳細に説明するように、ＵＬＲＯは、選択された場所を識別するように設計される固定識別コードを含む。この場合、場所は１つ以上の地理項目に関連付けられる。ＵＬＲＯは、デジタル基本地図又は参照ファイルと第三者データファイルとの間の方向転換可能なリンク又は接続を確立するために採用される。この場合、参照ファイルは、ファイル所有者の地理データを固定記憶するために使用される地理空間ファイルである。第三者ファイルは、第三者の地理データを固定記憶するために使用される地理空間ファイルである。ＵＬＲＯの使用に関する更なる情報は、２００５年１１月１０日に出願され且つ本明細書において引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１１／２７１，４３６号公報「A METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS」において説明されている。ＵＬＲＯ又は同様の汎用的オブジェクトを使用する実施形態において、ＵＬＲＯは、地図プロバイダの参照ファイルと種々の第三者ファイルとの間のリンクを提供する技術の一例であると考えられてもよい。その場合、ＶＤＢは、仮想地図を生成する際にそのようなリンクを利用する技術であると考えられてもよい。
【００１９】
仮想データベースシステムの目的は、第三者地図データ供給者に関連するデータ処理能力の少なくとも３つの面、すなわち、デジタル地図データプロバイダ及びその第三者パートナーがデータを共有できる一方で自身のデータに対する制御を依然として保持することにより、自身の製品サイクルに従って個別のデータベースの更新を継続できるような動的統合、統合処理中にデータの矛盾を検出し且つコアデジタル地図データと第三者のデータとの間の近接リンクを保証するのに最適なエンティティに制御を委譲することによる地図品質の向上、並びに複数の供給元からのデータを一貫してまとめる共通フレームワークを可能にすることによる共有の簡易化の３つの面を向上することを含む。
【００２０】
本手法の更なる利点は、第三者データプロバイダが、基本地図において使用される正確な緯度座標及び経度座標を使用して情報を符号化する必要がないことである。その代わり第三者データプロバイダは、他の第三者を利用し且つ他の第三者に情報を提供できる。例えば、ある第三者は、地図内のレストラン又は駐車場等の地図特徴に関する情報を提供してもよい。別の第三者は、特定のレストランの営業時間等、それらの地図特徴の属性に関する情報を提供してもよい。別の第三者は、ある特定のレストランをそのレストランに最も近い駐車場に関連付けるリンクを提供してもよい。対応する情報は、最終仮想地図において全てリンクされ、デジタル地図プロバイダの観点ではなく第三者の観点からの地図を提示してもよい。更に、仮想データベースの作成中、特徴及び基本地図内にまだ存在しない特徴の影（shadows）は、任意の数の第三者への種々のリンクを使用して地図上に反映される。
【００２１】
上述の利点及び他の利点は、本明細書に含まれる説明から明らかとなるだろう。
【００２２】
《用語の説明》
以下の節は、本明細書の説明において使用される用語の一部を定義する。
【００２３】
［デジタル地図プロバイダ］  デジタル地図プロバイダイは、参照ファイル又はデジタル基本地図を開発、保守及び提供するか、あるいは参照ファイル又はデジタル基本地図を含むデータを供給する商業、政府又は他の種類のエンティティ又は会社である。いくつかの例において、デジタル地図プロバイダは第三者ファイルプロバイダとしても機能する。商業デジタル地図プロバイダの例は、Tele Atlas及び他のマッピング会社を含む。
【００２４】
［第三者］  第三者、第三者データ供給者又は第三者データ供給元は、通常はデジタル地図プロバイダから分離され、参照ファイル又はデジタル基本地図と共に使用するための第三者データ又はコンテンツを提供する商業コンテンツプロバイダ、政府コンテンツプロバイダ又は他の種類のエンティティである。第三者がデジタル地図プロバイダと共に共同データ提供動作に参加する場合、双方は第三者パートナーであると考えられてもよい。
【００２５】
［参照ファイル］  参照ファイルは、文書所有者の地理データを固定記憶するために使用される地理空間データベース、データ構造、文書又はデジタル地図である。参照ファイルは、通常、ある特定のアプリケーションに対してより適切な他の形式に変換される。データが当然更新可能であるため、本明細書において使用される用語「固定」は、静的であることを意図しない。その代わり、この用語は、参照ファイル内のデータが要求に応答して仮想地図内に動的に作成されるデータより「固定的に」記憶されることを示す。一実施形態によると、１つの参照ファイルデータベースのみが存在する。この場合、他の各データ供給元又は各地理データベースは第三者ファイルであると考えられる。しかし、他の実施形態において、任意のデータファイル又はデータ供給元が参照ファイルとして機能でき、その他のデータファイルを第三者ファイルとして扱うため、これらは説明のための表記にすぎない。本明細書中で使用されるように、参照ファイルが通常はデジタル地図プロバイダによりデジタル地図として提供及び販売されることを示すため、参照ファイルは「デジタル基本地図」と呼ばれる場合もある。
【００２６】
［第三者ファイル］  第三者ファイルも、文書所有者の地理データを固定記憶するために使用される地理空間データベース、データ構造、文書又はデジタル地図であるが、第三者ファイル内のデータが参照ファイルと共に使用するために第三者により供給される点が異なる。上述のように、他の実施形態において、任意のデータファイル又はデータ供給元が第三者ファイルとして機能でき、その他のデータファイルを参照ファイルとして扱うため、これらの用語は説明のための単なる表記を意図する。
【００２７】
［仮想データベース／仮想データベースシステム］  仮想データベースは、複数のデータベースに分散されたデータを単一のデータベースに属するかのように扱う手段である。その場合、仮想データベースを提供するシステムは当然、仮想データベースシステム（ＶＤＢ）と呼ばれる。用語「仮想データベース」及び「仮想データベースシステム」は、仮想データベースを形成するために参照ファイル及び１つ以上の第三者ファイルの双方の中のオブジェクト及び特徴がリンクされる仮想データベース又は仮想地図を作成するシステム、手段又は技術を示す点で若干類似する。ＵＬＲＯ又は同様の汎用的オブジェクトを利用するこれらの実施形態において、ＵＬＲＯは、地図プロバイダの参照ファイルと種々の第三者ファイルとの間のリンクを提供する技術の一例であると考えられてもよい。その場合、ＶＤＢは、仮想地図を生成する際にそのようなリンクを利用する技術であると考えられてもよい。
【００２８】
［仮想地図］  仮想地図は暫定データベースであり、又はいくつかの例においてはＶＤＢの出力である。概念上、仮想地図は上述の仮想データベースと同一であり、すなわち、複数の地図供給元に分散されたデータを単一の地図に属するかのように扱う手段である。用語「仮想地図」は、用語「仮想データベース」より実世界的な意味を有し、本質的には複雑なデジタル地図である。更に、仮想地図が実行時に多くの別個の供給元から動的に作成されるため、仮想地図はより融通性があり且つ更新が容易であり、そのため地図データの単なる要約より有用である。
【００２９】
［統合データベース］  いくつかの実施形態によると、本明細書において、統合データベースは相互参照（ＸＲＥＦ）データベースとも呼ばれる。これは、参照ファイルと１つ以上の第三者に属する第三者ファイル又は第三者データとを統合するデータベース又はデータ構造である。いくつかの実施形態において、統合データベースは、物理媒体に格納される実際のデータベース構造である。他の実施形態において、統合データベースは、参照ファイル及び第三者ファイルをリンクする動的に作成されるデータ構造である。
【００３０】
［アプリケーションデータベース］  いくつかの実施形態によると、アプリケーションデータベースは、仮想地図データを種々の関係者からエンドユーザに配布する媒体である。特定の実施例に応じて、アプリケーションデータベースは、従来のデータベース形式、ウェブページ、又はデータ提示の他の任意の手段を含む種々の異なる形態を取ることができる。
【００３１】
［ＵＬＲＯ］  汎用的位置情報記録オブジェクト（ＵＬＲＯ）を利用する実施形態において、ＵＬＲＯは、固定識別コード及び参照ファイル又は第三者ファイル内のある特定の場所を一意に識別するように設計された十分な情報を含む。その場合、場所は１つ以上の地理項目に関連付けられる。ＵＬＲＯは、データベース形式の広範な範囲に対して参照ファイルと第三者ファイルとの間に方向転換可能なリンクを確立するために採用される。同様に、ＵＬＲＯは、２つ以上の第三者ファイル間に方向転換可能なリンクを確立するために採用される。いくつかの実施形態において、ＵＬＲＯは、単一の地図特徴、地図の線特徴のセグメント又は関連する地図特徴の集合のいずれかの場所を参照できる。いくつかの実施形態において、ＵＬＲＯは、参照したオブジェクトに関する場所情報を符号化してもよく、又は単に割り当てられた番号であってもよい。地図は複数の特徴を含むことができ、各特徴は、同一の場所及び同一のＵＬＲＯを共有する。ＵＬＲＯは、一度廃棄されると再利用されない。ＵＬＲＯ又は同様の汎用的オブジェクトを使用する実施形態において、ＵＬＲＯは、地図プロバイダの参照ファイルと種々の第三者ファイルとの間のリンクを提供する技術の一例であると考えられてもよい。その場合、ＶＤＢは、仮想地図を生成する際にそのようなリンクを利用する技術であると考えられてもよい。ＵＬＲＯの使用に関する更なる情報は、２００５年１１月１０日に出願され且つ本願に引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１１／２７１，４３６号公報「A METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS」において説明されている。
【００３２】
［地図］  本明細書中で使用されるように、用語「地図」は、地理空間データベース、デジタル地図又はそれに含まれる地図データを示すために使用される総称である。
【００３３】
［地図オブジェクト］  地図オブジェクトは、地図項目、あるいはより適切には地理空間データベース又は地図内にインスタンス化されたデータオブジェクトである。
【００３４】
［特徴／地理的特徴］  本明細書において単に「特徴」とも呼ばれる地理的特徴は、実世界からの実際のオブジェクトの理想化された地図表現であり、その地図表現に対して有用である。特徴は、次元を有することができ幾何学的表現を有することが多いが、これを必ずしも有するわけではない。特徴は、境界又は交差のように実世界において実際に可視でなくてもよいが、可視でない場合であっても地図モデルにおいて表現される。特徴は種類及びクラスを有し、これらによって、システムは１つの特徴を別の特徴から区別することができる一方で、同様の特徴間の類似性が保存される。
【００３５】
［特徴の次元］  多くの場合、地図モデルにおいて、特徴は完全な「実世界」における複雑さより単純に表現される。実世界における複雑さは、ある特定の機能を実行するために実世界のいくつかの顕著な面を取り入れようとするモデルに対しては、利点ではなく欠点である。従って、特徴の次元は、実世界の現実ではなく、表現が描画したものを反映する。一実施形態によると、特徴が分割される５つの次元は、点特徴、線特徴、領域特徴、ボリューム特徴及び複雑な特徴を含む。点として表現される実世界の特徴は、点特徴として周知である。例えば、地図モデルにおいて表現される場合、レストラン（実世界においては、複雑な形状を有するボリュームオブジェクトであるが）は、利便上、点特徴として表現される。例えば、２つ以上の道路要素が互いに交差する接合点も同様である。線特徴は、線形セグメント又は単純な湾曲セグメントとして表現される（そのため、点特徴間又は中間形状点間にわたる範囲を有する）。道路、境界、線路及び河川は、線特徴のいくつかの例である。実世界において、これらのオブジェクトは剃刀の縁のように細くないが、地図モデルにおいて、これらは理想化された中心線として表現され、実際の幅は無視される。湖、公園及び行政地域は領域特徴の例である。建物等のボリューム特徴（大部分の地図モデルには存在しない）は、実世界に類似するように接続された領域特徴の構造として表現されるが、はるかに詳細ではない場合が多い。最後に、複雑な特徴は「原子的」に定義されない特徴である。
【００３６】
［特徴の種類及び特徴のクラス］  特徴の種類及びクラスは、異なる特徴の区別を可能にする特徴のサブカテゴリである。道路、河川、線路、都市、郡、山頂、バス停留所、交差点、橋、レストラン、ホテル、休憩施設等は、特徴の種類のいくつかの例にすぎない。大部分の商業地図モデルにおいて、数千の異なる特徴の種類が存在するだろう。例えばＩＳＯ−ＧＤＦ（地理データファイル）地図形式は、特に、周知の特徴の種類の全てを列挙しようとする１つの標準形式である。ＧＤＦ形式の完全な詳細は、本願に引用されその内容がここに合体される、ＩＳＯ仕様書「ISO 14825: Intelligent Transport Systems - Geographic Data Files(GDF) Overall Data Specification」に説明されている。特徴のある特定の種類に変形が存在してもよい。例えば世界には、高速道路、主要道路、非主要道路、農道、生活道路、侵入路、未舗装道路及び家畜用道路等の異なるクラスの道路が存在する。これらは全て特徴の種類「道路」であるが、これらは種々の分類において異なる。従って、特徴のクラスは特徴の種類の下位にある。
【００３７】
［特徴のジオメトリ］  コンピュータ地図モデルにおいて、特徴は、特徴の形状の幾何学的表現を有する場合が多い。例えば、点特徴は単一ノードによる表現である。線特徴は、一連の形状点を通過してもよい線形セグメント、すなわちエッジにより表現される場合が多い。領域特徴は、各々が境界を描くエッジから構成される面の集合により表現される。領域特徴は分離されてもよく、又は内部に穴を有してもよい。ボリューム特徴はボリュームジオメトリにより表現され、空洞を含んでもよい。
【００３８】
［トポロジ］  トポロジは、特徴のジオメトリ（形状）が任意の変化を経ても維持される特徴間の連結関係を取り出す手段として使用される一組の数学的性質である。ある次元のジオメトリは、より低い次元のジオメトリにより境界を規定される。例えば、ボリュームは領域により境界を規定され、領域は線形セグメントにより境界を規定され、線形ジオメトリは点により境界を規定される。その反対に、複数の点は線形ジオメトリにより共に境界を規定され、複数の線形境界は領域により共に境界を規定され、複数の領域はボリュームにより共に境界を規定される。トポロジは、特徴自体に関してもよく、又はその形状を取り出すジオメトリに関してもよい。
【００３９】
［単純な特徴］  点特徴、線特徴、領域特徴及びボリューム特徴は、幾何学的形状を割り当てることにより直接モデル化されるため、単純な特徴と呼ばれる。
【００４０】
［複雑な特徴］  単純な特徴に対して、複雑な特徴は、他の特徴（単純又は複雑）により間接的に定義されるか、あるいは幾何学的描画により直接定義される。例えば、カリフォルニア州は、形状点を用いて境界を引くこと（この場合、これは単純な領域特徴になる）によってではなく、その郡の合計として表現可能である（この場合、郡は単純な特徴であってもよく、又は複雑な特徴であってもよい）。複雑な特徴として描画されたカリフォルニア州は単一の特徴であり、他の特徴を参照することにより複雑な方法で定義される。各々が交通の各方向を向く２つの道路要素から構成される道路は、複雑な特徴の別の一般的な例である。２つの複雑な道路が交わる場合、複雑な特徴、すなわち複雑な交差点が宣言される。多くの場合、交差点は、単純な道路要素が互いに交差する４つの接合点であると考えることができる。
【００４１】
［複数の特徴］  上述の単純な特徴及び複雑な特徴の双方は、単一の特徴の例である。しかし、いくつかの特徴を同時に考慮することにより複数の特徴を作成することが有用な場合がある。例えば、サンフランシスコの全レストランの集合又はカリフォルニアの全ての郡の集合は、複数の特徴の例として用いられる。尚、複数の特徴（例えば、カリフォルニアの全ての郡）は、カリフォルニア州という単一の複雑な特徴とは異なる概念である（しかし、本例において、これらは同一の幾何学的場所を有する）。
【００４２】
［特徴のサブセット］  単一の特徴の一部分、サブセット又は一部を識別することが便利な場合がある。場合によっては、そのような一部は当然特徴であるが、他の例において、そのような一部は、それ自体は実際の特徴ではない単なる断片である。特徴のサブセットの例は、カリフォルニア州という特徴の単一の郡、２つの交差点間の区画の一部のみにわたる道路要素のセグメント又は３０階建ての建物の４〜１７階を含む。
【００４３】
［属性］  特徴、複数の特徴及び特徴のサブセットは属性を有することができる。属性は大きなカタログで提供され、実世界の商業コンピュータ地図モデルにおいては、特徴に適用される数千の異なる属性が存在してもよい。属性の種類により、異なる属性がカタログから取り出される。制限速度、長さ、交通の流れの方向及びレストランの営業時間は、そのような属性のいくつかの例にすぎない。
【００４４】
［関係］  関係は、任意の有意義な相互接続に「参加する」２つ以上の特徴を含む。例えば道路要素は、任意の接合点において複数の道路要素に分かれてもよく、従って、それらの全ての特徴は互いに「分岐」関係にある（各特徴は異なる役割を果たす）。関係も大きなカタログで提供され、属性と同様に、実際の商業デジタル地図モデルにおいて数百のそのような関係が可能である。多くの関係が実世界の活動をモデル化することにより開発されるため、全ての関係が幾何学的なわけではない。例えば、ある特定の駐車場に駐車できるレストランは、２つの特徴間の１つの種類の商業関係を表す。
【００４５】
［地理項目］  本説明において、用語「地理項目」はＩＳＯ規格の用語ではない。本明細書において、地理項目は、特徴、複数の特徴、特徴のサブセット又は属性であると定義される。
【００４６】
［場所］  場所は、特徴が実世界において存在する所として定義され、特徴自体とは異なる概念である。例えば、特徴はある特定のレストランであってもよいが、その場所は、任意の緯度／経度（lat/long）座標対、任意の同様の測地参照システムからの座標、又は人間可読住所（例えば、「322 Battery Street in San Francisco」）として特定される。場所は、特徴又は場所に関連付けられる他の地理項目と混同されるべきではない。
【００４７】
［特徴の階層］  多くの場合、特徴は構造の階層を形成する。例えば、国は州から構成されるか又はそれらから成ってもよく、州は郡等から構成されてもよい。同様に、車道は、区画に面する多くの道路要素から成る。「The Stanford University campus area」を含む複雑な領域の道路、公園及び建物は、より大きな特徴の一部である。特徴の階層は、特徴間の関係の特別な例であり、明示的に取り出されて表現されてもされなくてもよい。
【００４８】
［地点情報（point of interest）］  地点情報（ＰＯＩ）は特別な種類の点特徴である。特にＰＯＩは、レストラン、ホテル又は美術館等の他のより特定の種類を含むことができる特徴の種類である。
【００４９】
［関係リンク］  いくつかの実施形態によると、関係リンクは、データオブジェクト間の関係を定義するテーブルにおける入力である。ＵＬＲＯを利用する実施形態において、関係リンクは、２つのＵＬＲＯを関連付けるか、又はＵＬＲＯとＵＬＲＯを含まない第三者データ（例えば、ファイル名又はＵＲＬ）とを関連付ける。全ての実施形態が関係リンクを使用するわけではない。
【００５０】
［マーカ］  いくつかの実施形態によると、個別の地図特徴、地図の線特徴のセグメント又は関連する地図特徴の集合を関連付けるため、マーカ（又は「場所マーカ」）が使用される。これらの特徴は、デジタル地図データプロバイダ又は第三者ベンダにより保守されるデータベースのいずれに配置されてもよいが、デジタル地図データプロバイダはマーカを保守する。いくつかの実施形態において、関係情報はＵＬＲＯに格納されず、この場合、マーカは適切である。しかし、殆どの場合、マーカは必要ないか又は望ましくない。全ての実施形態がマーカを使用するわけではない。
【００５１】
［オブジェクトマーカ］  オブジェクトマーカは特定の種類のマーカであり、上述のように、ある特定の実施形態においてオプションの特徴として使用されてもよい。いくつかの実施形態によると、オブジェクトマーカは、場所マーカとデータオブジェクトとを関連付ける参照である。データオブジェクトは、デジタル地図データプロバイダにより保守される参照ファイル又はデータベースのいずれに配置されてもよく、あるいは第三者により保守される第三者ファイルに配置されてもよい。全ての実施形態がオブジェクトマーカを使用するわけではない。
【００５２】
［関連マーカ］  関連マーカは特定の種類のマーカであり、上述のように、ある特定の実施形態においてオプションの特徴として使用されてもよい。関連マーカ（又は「関係マーカ」）は、データオブジェクト間の関係である。全ての実施形態が関連マーカを使用するわけではない。
【００５３】
［メタデータレジストリ］  いくつかの実施形態によると、メタデータレジストリが使用される。ＵＬＲＯを利用する実施形態において、メタデータレジストリは、第三者データプロバイダ、それらのデータコンテンツ、有効範囲又は品質の格付けを識別し、それらに割り当てられたＵＬＲＯの適用可能範囲を識別するレジストリである。全ての実施形態がメタデータレジストリを使用するわけではない。
【００５４】
《仮想データベース環境》
概要を説明すると、本発明の一実施形態は、仮想データベースシステム又は仮想データベース環境を提供する。仮想データベース環境により、空間情報をリアルタイムで「結合」できる。この処理は、従来のデータベース環境において使用される処理と同様である。従来のデータベース環境において、１組のデータベーステーブルは、データベーステーブルが結合されなければ多くのテーブルに広がる可能性のあるユーザからの要求に一括応答するために結合される。本処理は、背景の節で上述した従来の重ね合わせる種類の地図組み合わせとは実質的に異なる。オーバーレイ地図は関係情報を含まないが、仮想データベース環境は、組み合わされるか又は結合された地図内の点、場所、領域、建物又は商業的特性を含む全項目とそれらの項目に関連付けられる他の任意の情報とをリンクする手段を提供する。エンドユーザに対して、その結果得られる仮想データベース又は仮想地図は、従来のオーバーレイ地図と同様に見える場合がある。しかし、オーバーレイ地図とは異なり、仮想データベースを用いる手法を使用する場合、ユーザは、１つの地図項目をクリックすることにより他の任意のリンクされた地図項目に到達できる。実際、１つの地図項目に関連する全情報は、リンク機構を介して入手可能である。従来の重ね合わせ技術と比較して更なる利点は、オーバーレイ地図は不正確である可能性のある地理情報に完全に依存するが、仮想データベースを用いる手法はそのように制限されない点である。
【００５５】
仮想データベースシステムにおいては、いくつかの情報が参照ファイルから検索されていてもよい一方、他の情報が第三者ファイルから検索されていてもよいため、この技術によって、異なる商業エンティティにより所有、制御及び保守されるデータ間をリンクできる。仮想データベース環境において使用されてもよいリンク機構の種類の一例は、２００２年７月３１日に出願され且つ本願に引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１０／２０９，７５０号公報「SYSTEM AND METHOD FOR ASSOCIATING TEXT AND GRAPHICAL VIEWS OF MAPINFORMATION」において説明されている。この特許出願において説明されるように、地図項目は意味関係によりリンクされ、それによって、１つの地図項目の属性は別の地図項目の属性にリンクされる。しかし、その場合のリンクは、大部分が単一地図内の地図項目間である。仮想データベース環境において複数の地図又は複数のデータ供給元の間で使用可能なリンク機構の種類の一例は、２００５年１１月１０日に出願され且つ本願に引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１１／２７１，４３６号公報「A METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS」において説明されている。
【００５６】
仮想データベースの有用性は、上述のレストランの適用例で考察されてもよい。ある会社がオンラインレストラン探索ユーティリティを提供したい場合、仮想データベースを用いる手法を使用して、街路、公園及び他のそのような場所を示す典型的な地理地図であってもよい第１のデータ供給元又は第１の地図Ａへのリンクを提供できる。それらは、レストラン情報及びレビュー等を含む第２のデータ供給元又は第２の地図Ｂへのリンクを更に提供できる。レストラン地図に対するユーザ要求に応答して、地図を単に重ね合わせる代わりに、会社は、従来のようにレストランが地図上でフラグとして示されるように、地図Ｂのデータにリンクされた地図Ａを検索及び表示する。しかし、仮想データベースを使用すると、地図Ｂにより提供されるそのレストランに関連付けられる情報の任意の要素は地図Ａの要素に完全にリンクされる。従って、仮想データベースは、ユーザ要求に応答する少なくとも一時的な期間において、全地図項目がリンクされる複雑な地図構造を作成するための異なる地図データセットの仮想リンクである。地図の重ね合わせ処理と同様に、仮想データベース処理は、情報を豊富に含む地図という印象をエンドユーザに与えるため、多くの地図の情報を相互に提示できる。しかし、地図の重ね合わせは単なる錯視となる。地図の重ね合わせ処理とは異なり、仮想データベースを用いる手法を使用すると、リンクされた後続の各データセットは、その地図項目により集合内の他の地図項目に更にリンクされる。更に、地図Ａ等の１つのデータセットが１つのエンティティ、すなわちデジタル地図プロバイダからリアルタイムで受信される一方、地図Ｂ等の別のデータセットが異なるエンティティ、すなわち第三者からリアルタイムで受信されるため、仮想データベースにより、各データ供給元に対する責任及びその制御をその特定のデータの所有者に維持することができる。
【００５７】
図１は、本発明の一実施形態に係る仮想データベース環境を示す図である。図１に示すように、仮想データベース環境２は、仮想データベース３、参照ファイル４及び１つ以上の第三者ファイル６を含む。上述のように、参照ファイルは、参照ファイル又はデジタル基本地図を開発、保守及び提供する商業、政府又は他のエンティティ又は会社であるデジタル地図プロバイダ８により提供される。第三者ファイルは、第三者商業エンティティ又は他のエンティティ１２により提供される。通常、エンティティ１２はデジタル地図プロバイダから分離され、自身のファイル内の特定のデータに対する制御を保持する。参照ファイル及び第三者ファイルは、地理空間データベース、データ構造、文書又はデジタル地図であってもよい。しかし、他の実施形態において、任意のデータファイル又はデータ供給元が参照ファイルとして機能でき、その他のデータファイルを第三者ファイルとして扱うため、これらは説明のための表記にすぎない。仮想データベースは、参照ファイル及び第三者ファイルに分散されたデータを単一のデータベースに属するデータセットのように扱う手段である。従って、このように仮想データベースを提供する任意のシステムは、当然、仮想データベースシステムと呼ばれる。
【００５８】
ＵＬＲＯ又は同様の汎用的オブジェクトを使用する実施形態において、ＵＬＲＯは、地図プロバイダの参照ファイルと種々の第三者ファイルとの間のリンクを提供する技術の一例であると考えられてもよい。その場合、ＶＤＢは、仮想地図を生成する際にそのようなリンクを利用する技術であると考えられてもよい。一実施形態によると、参照ファイルは、データベース内の項目毎に任意の識別情報を含む地理空間情報又は地図情報のデータベースを含む。この識別情報は、項目の名称、緯度及び経度であってもよい。ＵＬＲＯ又は同様の汎用的オブジェクトを使用する実施形態において、ＵＬＲＯは、項目のＵＬＲＣを特定することにより、その項目の識別情報を含むことができる。
【００５９】
一実施形態によると、各参照ファイルは、項目毎に任意の識別情報を含む地理空間情報又は地図情報のデータベースを更に含む。この識別情報は、同様に、名称、緯度及び経度又はＵＬＲＯであってもよい。仮想データベースは、ユーザ要求１５に応答して作成されるか、又はアプリケーションの構築時であればアプリケーションの構築要求に応答して作成される。ユーザ要求に対する応答は、実際の表示可能な地図、任意の地図関連情報、ウェブパケット（ＸＭＬメッセージ等）、ＡＰＩ機能の呼出し又は別の形態の応答１８であってもよい。
【００６０】
一実施形態によると、仮想データベースの作成中、「ゴースト」オブジェクト又は影が参照ファイル内の項目に対応してメモリ内に作成される。その後、必要に応じて、これらのオブジェクトは参照ファイル内の対応する項目にリンクされ、要求に応答する前に第三者データと共に読み込まれる。メモリ内のオブジェクト毎に種々のファイルから情報を検索するために使用される情報は、その項目の共通の名称、経度、緯度、ＵＬＲＯ又は他の情報である。全ての実施形態がゴーストオブジェクトを使用するわけではない。
【００６１】
仮想データベース又は仮想地図がユーザからの要求に応答して生成されるため、一実施形態によると、仮想データベースの寿命は、そのユーザセッションの寿命の間持続してもよい。セッションの終了後、仮想データベースは削除されてもよい。後続の要求により、システムは仮想データベースの新しいコピーを作成する。しかし、いくつかの実施例において、特に、仮想地図が同一の地図データに対する多くの後続の要求に応答するために使用される場合、仮想地図をキャッシュに位置付けるか又はより長期間格納することが望ましいだろう。
【００６２】
デジタル地図プロバイダ及び第三者が共通のファイル形式を共有する場合、２つのデータセットの統合は、本質的に１対１のタスクである。しかし、本発明の目的が種々のデータセットに対する制御の分離を可能にすることであるため、デジタル地図プロバイダ及び第三者が共通のファイル形式を共有しない可能性が高い。第三者ファイル内の情報にアクセスするため、第三者プロバイダは、共通データの検索及びリンクを可能にするインタフェースを提供する必要がある。あるいは、デジタル地図プロバイダは、第三者が使用するためのインタフェースを提供できる。
【００６３】
ＵＬＲＯ又は同様の汎用的オブジェクトを使用する実施形態において、システムが既存のＵＬＲＯを有さない第三者データを受信する場合、システムは項目に新しいＵＬＲＯを割り当てられる。
【００６４】
図２及び図３は、エンドユーザの観点から見て、従来の第三者地図統合の解決策と比較して仮想データベースシステムが有する利点を示す。図２に示すように、従来の統合の解決策を使用する場合、ユーザ２０は、複数のデジタル地図プロバイダ２２及び第三者データプロバイダ２４、２６及び２８の各々に対して、複数の要求／応答３０を作成する必要がある。本明細書において参照されるように、「ユーザ」は、実際の人間であってもよく、あるいはソフトウェアプログラム、コンピュータシステム又は地図に基づく情報を要求する他のものであってもよい。いくつかの例において、自動処理又はレイヤは複数の要求及び応答をまとめて（重ね合わせ処理を使用して）、エンドユーザに対して単一のデータセットに見えるようにする。しかし、データは、第三者データプロバイダから依然として個別に受信される。そのため、上述のように、データの一致及び完全な統合に関する問題が発生する。図３に示すように、仮想データベース環境が使用される場合、ユーザ４０は、単一の要求５０を作成し且つ単一の応答５４を受信するだけでよい。仮想データベース環境は、複数のデジタル地図プロバイダ４２及び第三者データプロバイダ４４、４６、４８の各々からのデータを仮想データベース３に統合する処理を行う。一実施形態によると、仮想データベースを読み込み且つユーザ要求に動的に応答するために、デジタル地図プロバイダからの参照ファイルデータ４は、第三者データプロバイダからの第三者ファイルデータ５６、５８、６０にリアルタイムでリンクされる（５２）。
【００６５】
尚、図３は、ユーザ要求が受信され、その後第三者供給元への適切なリンクが作成され、その結果得られる情報のセットが仮想データベースを作成するために使用される処理を示すが、他の実施形態において、データの統合が異なる方法で実行されてもよいことは明らかだろう。例えば、いくつかの実施形態によると、第１のユーザクエリを受信した時点で、リンクの予備セットが第三者データの最初のセットに対して作成される。ユーザがより詳細な要求を行う場合、そのより詳細な要求を満足するために、追加の供給元が追加のデータ及び追加のリンクと共に含まれてもよい。他の実施形態によると、第三者データの「同盟」が作成され、例えば第三者Ａのデータ供給元が仮想データベースを作成するために使用される場合、第三者Ｂのデータ供給元も同様に使用される。タイミング及びリンクの範囲に関する他の実施形態及び実施例は、当業者には明らかだろう。
【００６６】
図４は、異なるエンティティが仮想データベース環境内で対話する方法を示す。図４に示すように、複数のユーザ４０、４１、４３は、１つ以上のデジタル地図プロバイダ４２及び第三者データプロバイダ４４、４６、４８と共に、仮想データベース環境２を介して地図関連データを共有する。上述のように、「ユーザ」は、実際の人間であってもよく、あるいはソフトウェアプログラム、コンピュータシステム又は地図に基づく情報を要求する他のものであってもよい。更に、他の実施形態において、任意のデータファイル又はデータ供給元が参照ファイルとして機能でき、その他のデータファイルを第三者ファイルとして扱うため、図４で使用される表記は説明のための表記にすぎない。
【００６７】
図５及び図６は、本発明の一実施形態に係る仮想データベース環境により使用される処理を示すフローチャートである。図５に示すように、ステップ６１において、システムにより、ユーザ又は別のシステムは地図情報を要求できる。あるいは、処理はアプリケーションの構築要求により開始されてもよい。この要求に基づいて、ステップ６２において、システムは、項目及び場所コード、例えば名称、緯度、経度又はＵＬＲＯを含む参照ファイルにアクセスする。ステップ６３において、システムは、地図内の場所毎に場所識別子（ＵＬＲＯ等）を識別又は作成する。図５に示す実施形態によると、ＵＬＲＯは、ある特定の場所に関連付けられる任意の情報を使用して実行時に作成される。以下の図６に示すような他の実施形態によると、ＵＬＲＯは必ずしも実行時に作成される必要がなく、その代わり参照ファイル内に既に定義されている。ＵＬＲＯの作成に関する更なる情報は、２００５年１１月１０日に出願され且つ本願に引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１１／２７１，４３６号公報「A METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS」において説明されている。ステップ６４において、システムは、要求に完全に応答するために必要な追加の第三者ファイル又は第三者情報の供給元を判定し、ステップ６５において、第三者データをシステムに取り込む。ステップ６６において、参照ファイル及び第三者ファイル内の項目情報は、ＵＬＲＯ又は他の識別子等の共通の識別情報を使用してリンクされる。ステップ６７において、完全にリンクされたデータセットは、仮想データベースを作成するために使用され、ステップ６８において、最初の要求に応答するために使用される。
【００６８】
図６は、本発明の一実施形態に係る仮想データベース環境により使用される処理を示すフローチャートである。本実施形態において、場所識別子又はＵＬＲＯは、参照ファイル又は第三者ファイル内の場所の一部又は全部に既に割り当てられている。図６に示すように、ステップ７１において、このシステムにより、ユーザ又は別のシステムは地図情報を要求できる。ステップ７２において、システムは、項目及び場所コード、例えば名称、緯度、経度又はＵＬＲＯを含む参照ファイルにアクセスする。ステップ７３において、システムは、地図内の場所毎に既存の場所識別子（ＵＬＲＯ等）を参照又は識別する。ステップ７４において、システムは、要求に完全に応答するために必要な追加の第三者ファイル又は第三者情報の供給元を判定し、ステップ７５において、第三者データをシステムに取り込む。ステップ７６において、参照ファイル及び第三者ファイル内の項目情報は、ＵＬＲＯ又は他の識別子等の共通の識別情報を使用してリンクされる。ステップ７７において、データは仮想データベースを作成するために使用され、ステップ７８において、システムは最初の要求に応答する。
【００６９】
仮想データベースを作成する際に含まれる必要のある参照ファイル及び第三者供給元又は第三者ファイルの判定は、例えば、各第三者供給元を中央又はレジストリに登録し、その後仮想データベースを作成する際にそれらの登録された第三者ファイルを含む等の多くの方法で実行可能である。あるいは、第三者供給元は、そこに含まれるデータの種類に基づいて登録可能であり、ある特定の種類のデータを返送する必要のある要求が受信された場合、そのデータの種類に一致するデータ供給元にだけアクセスすればよい。他の手段は、仮想データベースに含むためのデータファイルを第三者データ供給元に通知（advertise）させることにより、第三者供給元の動的な登録を可能にすることを含むことができる
。参照ファイルへの第三者供給元の登録を可能にする追加の実施形態は、当業者には明らかだろう。
【００７０】
一実施形態によると、複数のデータ供給元をリンクする処理をより適切に補助するため、仮想データベース環境は外来オブジェクトを利用できる。外来オブジェクトは、第三者データとして提供される地図オブジェクトであると考えられてもよい。すなわち、外来オブジェクトは、参照ファイルに対して外来である。これらの外来オブジェクトは、外来属性及び外来関係を含む。外来関係は、参照ファイル内のオブジェクトと第三者オブジェクトの１つとの間に存在してもよく、又は２つの第三者オブジェクト間に存在してもよい。これらのオブジェクトを参照ファイルにインポートしてローカルにする代わりに、仮想データベース環境は、それらを外来オブジェクトのままにしておく。仮想地図が後に作成される場合、ポインタ又は同様のポインタ機構がマッピングを実行するために使用される。実施例に応じて、種々のマッピングが実行されてもよい。
【００７１】
第１の種類のマッピングにおいて、参照ファイルは、地図項目のインスタンスを含まない。この場合、結合動作は、地図項目の別の供給元を認識し、項目の属性、並びにその全ての隣接項目及び参照ファイル内に既に存在する全ての隣接項目に対する関係と共に、その項目の「影」を仮想データベース内に作成できる（いくつかの例において、影を地図上に更に表示する）。
【００７２】
第２の種類のマッピングにおいて、システムにより、参照ファイルが知らない任意の属性を有する外来オブジェクトが存在するが、その外来オブジェクトの任意のインスタンスが既に存在することを認識できる。この場合、結合動作は、オブジェクト自体をインポートするのではなく、参照ファイル内にまだ存在しない属性をインポートする。これは、オブジェクトではなく属性のインポートであると考えられてもよい。
【００７３】
第３の種類のマッピングは、１つの外来オブジェクトと別の外来オブジェクトとの間の関係を含んでもよい。結合動作中、仮想データベースは、参照ファイル内に既に存在するオブジェクトの他の任意のインスタンスにそれらの関係を追加できる。
【００７４】
マッピングのこれらの例は最も一般的に使用される例であるが、他の種類のマッピングが使用されてもよいことは明らかだろう。また、複数の供給元を含む環境において、用語「外来」が参照ファイルとして選択されるデータ供給元に大きく依存するため（その場合、他の全てのデータベースが「外来」になる）、用語「外来オブジェクト」が表記にすぎないことは明らかだろう。上述のように、いくつかの状況において、データ供給元の多くは参照ファイルとして機能できる。そのため、用語「外来オブジェクト」は、特定の実施例の説明においてのみ意味を有する。
【００７５】
一実施形態によると、地図項目間の関係は、ポインタにより保守されるのではなく、汎用的位置情報参照オブジェクト（ＵＬＲＯ）により保守される。上述のように、ＵＬＲＯは、２００５年１１月１０日に出願され且つ本願に引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１１／２７１，４３６号公報「A METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS」においてより詳細に説明されている。多くの地図は同一の電子形式ではないため、別個の地図からのオブジェクトをリンクするために、システムは通常、任意の形態の変換を実行する必要がある。しかし、これは計算コストの高い動作である。ＵＬＲＯを使用することにより、高速且つ効率的な変換が可能になる。仮想データベースのこの特定の実施形態は、例えば、第１の関係者Ａが地図オブジェクトを識別子Ｘとして識別し、同一のオブジェクトが第２の関係者Ｂによって識別子Ｙとして理解されるような場合に有用である。関係者が自身の地図オブジェクトの識別方法を任意の時点で独自に変更してもよいため、異なるデータセットにわたって固定ポインタを保守することは困難である。ＵＬＲＯが使用される場合、参照ファイル内の全ての地図オブジェクトがこれらのコードを受け取る一方、外来地図内の全ての地図オブジェクトもコードを受け取る。仮想データベースの作成中、システムは、種々のオブジェクト間の一致を検出するためにコードを比較するだけでよい。
【００７６】
以下に説明する種々の例において、ポインタの使用及び汎用的位置情報参照の使用の双方は、地図オブジェクト間のリンクを提供するものとして説明されている。他の実施例がこれらの技術のうちの一方、双方又は他方を使用してもよいことは明らかだろう。仮想データベース技術は十分な融通性を有するため、異なるデータセット間のマッピングの他の形態が利用可能である。
【００７７】
《ＶＤＢアーキテクチャ》
一実施形態によると、システムは、２つ以上のデータベース（又はより適切には、データ集合又はデータ供給元）を含み、これらは仮想データベース環境を共に構成する。これらのデータベースは、統合データベース及びアプリケーションデータベースを含む。統合データベースは、デジタル地図データプロバイダの参照ファイルと第三者データ供給元との間に存在する従来のデータベースであってもよく、マッピング、ポインタ、ＵＬＲＯ又は同様の機構の組み合わせを使用して、参照ファイルと第三者データとを統合する。その場合、アプリケーションデータベースは、このデータを種々の関係者からエンドユーザに配布する媒体である。そのため、アプリケーションデータベースはＶＤＢの使用可能な面を表す。特定の実施例に応じて、アプリケーションデータベースは種々の異なる形態をとってもよく、その一部は従来のデータベースに類似してもよい。あるいは、アプリケーションデータベースは、従来のデータベース形式とは異なるデータ形式、例えばウェブページ又は他のそのようなデータ提示手段を使用してもよい。
【００７８】
図７は、本発明の一実施形態に係る仮想データベース環境又は仮想データベースシステム２を示す図である。図７に示すように、システムは、ユーザインタフェース８６及びデータ出力インタフェース８８と共に仮想データベース３を含む。ユーザインタフェース８６及びデータ出力インタフェース８８は、単一のインタフェースに組み合わされてもよい。システムは、複数の種々のデータ供給元と通信する手段８５を更に含む。一実施形態によると、システムはデータ供給元に対するインタフェース８４を含む。この場合、インタフェース８４は、デジタル地図プロバイダの参照ファイル又は各第三者データ供給元へのリンクを含む。ユーザ要求に応答して又は地図データを別のシステムに通信するため、データ供給元の集合が選択され、それらの地図データセットは、統合データベース８０を作成するために参照ファイルの地図データセットにリンクされる。統合データベースを読み込むため、種々の地図データ内の各地図オブジェクトは、ポインタによって又はいくつかの実施形態においてはＵＬＲＯ識別子によって、他の地図オブジェクトにリンクされる。一実施形態によると、１つのデータ供給元は、固有オブジェクトを有する参照ファイルであると考えられ、その他のデータ供給元は、外来オブジェクトを有する第三者データベースであると考えられる。第三者データとして提供される地図オブジェクトは、「外来オブジェクト」であると考えられてもよく、外来属性及び外来関係を含んでもよい。地図オブジェクトは「部分的に外来」であってもよく、その場合、いくつかの属性は参照ファイルと共通であり、いくつかの属性は外来である。統合データベースの読み込み中、これらの外来属性及び外来関係は、参照ファイル内のオブジェクトと第三者オブジェクトとの間でマッピングされる。従って、仮想データベース環境は、メモリ内に仮想地図構造８９を作成するための異なる地図データセットの仮想リンクである。この環境において、全地図項目はリンクされ、情報を豊富に含む地図という印象をユーザに与える。従来の地図の重ね合わせ処理とは異なり、仮想データベースを用いる手法を使用する場合、システムに取り込まれる後続の各データセットは、その地図項目により集合内に既に存在する他の地図項目の一部又は全部にリンクされるため、この地図はまさに完全に動作可能な対話型デジタル地図である。
【００７９】
図７に更に示すように、仮想データベース環境は、統合データベース８０及びアプリケーションデータベース８２を含む。一実施形態によると、統合データベースは、単一の従来のデータベース又は同様のデータ構造であってもよい。一方、アプリケーションデータベースは、このデータの全てをエンドユーザに配布する媒体である。
【００８０】
尚、上述の構成要素は仮想データベースシステムを構成するが、これは、種々の構成要素が任意の１つのプラットフォーム又は任意の１つの場所に格納されることを必ずしも意味しない。実際、いくつかの構成要素、特に参照ファイル及び第三者データベースは、遠隔場所に格納され且つ遠隔場所からアクセスされる場合が多い。更に、図７に示すシステムはアプリケーションデータベースを含むが、他の実施形態は、ウェブインタフェース、ウェブパケット（ＸＭＬメセージ）、ＡＰＩ機能呼出し又はデータ通信の他の任意の形態等の異なるデータ配布手段を利用してもよい。
【００８１】
図８は、本発明の一実施形態に係る仮想データベース環境を使用する処理を示すフローチャートである。図８に示すように、処理は、場所の集合を表す参照ファイルにアクセスするステップ９０を含む。ステップ９１において、システムは、必要な第三者情報の追加の供給元を判定し、第三者データ又は第三者ファイルをシステムに取り込む。ステップ９２において、システムは、統合データベースの場所コード及び他の位置情報を使用して、参照ファイル内の情報と第三者データとを一致させる。ステップ９３において、このリンクされたデータセットは、仮想データベースを作成するためにアプリケーションデータベースと共に使用される。ステップ９４において、仮想地図データは要求する相手に提供される。ステップ９５において、仮想データベースからの更新されたリンク及び情報は、関係者が後で使用するために、参照ファイル及び第三者の双方に提供される。この場合も上述したように、図８は、システムが参照ファイルにアクセスし、第三者供給元への適切なリンクを作成し、その結果得られる情報セットを使用して仮想データベースを作成する処理を示すが、他の実施形態において、データの統合が異なる方法で実行されてもよいことは明らかだろう。例えば、いくつかの実施形態によると、参照ファイル又は第三者データに最初にアクセスした時点で、リンクの予備集合が第三者データの最初の集合に対して作成されてもよい。より詳細な情報が必要な場合、そのより詳細な要求を満たすために、追加の供給元が追加のデータ及び追加のリンクと共に含まれる。
【００８２】
《オプションのＶＤＢ拡張》
仮想データベース環境の一実施形態を上述した。実施例に応じて、仮想データベースは異なる方法で実現されてもよく、地図形式情報、オブジェクト参照、マーカ、メタデータ、アクセスレジストリ、並びに第三者データ、リリース更新、ジオコーディングサービス、アプリケーションプロバイダ、アドレスポイント更新処理及び第三者データからマーカへのマッピングに対する複数のアプリケーションプログラムインタフェース（ＡＰＩ）を含む種々のオプションの構成要素を含んでもよい。これらの構成要素及びインタフェースの各々を以下に更に詳細に説明する。全ての実施形態がこれらの特徴を使用又は必要とするわけではない。
【００８３】
・第三者データＡＰＩ
一実施形態によると、仮想データベースは第三者データＡＰＩを含む。第三者データＡＰＩにより、第三者データプロバイダはデータを仮想データベース環境に通信できる。特に、第三者データＡＰＩにより、外来オブジェクトを仮想データベースにインポートできる。固有の識別子等のいくつかの情報は、適切な相互参照を実現するために各データプロバイダにより必要とされる。第三者がデジタル地図データプロバイダのジオコーディングサービスを必要とする場合、十分な住所情報が更に提供される必要がある。ジオコードが必要ない場合、オブジェクトの緯度及び経度（lat/long）情報が住所情報と共に供給される必要がある。第三者識別子をジオコード又は位置決めするために必要な最小限の詳細のみが仮想データベースに格納される必要がある。その場所に存在するオブジェクト又は情報の実際の詳細は、外部に格納され続け且つ第三者により制御され続ける。いくつかの実施形態によると、システムは、発明者Hans Ulrich Ottoによる２００６年１１月１１日に出願された同時係属ＰＣＴ出願第ＰＣＴ２００６／０００５５２号「ARRANGEMENT FOR AND METHOD OF TWO DIMENSIONAL AND THREE DIMENSIONALPRECISION LOCATION AND ORIENTATION DETERMINATION」、２００６年１１月３日に出願された同時係属ＰＣＴ出願第ＰＣＴ／ＮＬ２００６／０５０２６４号「METHOD AND APPARATUS FOR DETECTION AND POSITION DETERMINATION OFPLANAR OBJECTS IN IMAGES」、及び２００６年１０月３０日に出願された同時係属ＰＣＴ出願第ＰＣＴ／ＮＬ２００６／０５０２６９号「METHOD AND APPARATUS FOR DETECTING OBJECTS FROM TERRESTRIAL BASEDMOBILE MAPPING DATA」において説明されているオフセットポインタアドレス指定技術を更に利用できる。これら出願は、本願に引用され、それらの内容がここに合体される。
【００８４】
・第三者データ共有シナリオ
図９は、本発明の実施形態に従って、第三者データが仮想データベースにおいて追加コンテンツと様々な信頼度で統合される方法を示す図である。図９に示すように、特定の実施形態に応じて、種々のデータ供給元及びデータベースは以下を含むことができる：
【００８５】
参照ファイルデータベース（ＴＡ ＢＤ）：  これは、地理参照サービス、並びにアドレスポイント検索及び作成サービスを提供する。
【００８６】
相互参照データベース（ＸＲＥＦ）：  コンテンツ供給者に対して、ＸＲＥＦは、潜在的なアプリケーション開発者に対してコンテンツを説明すること及びコンテンツ供給者のオブジェクトと参照ファイルとの間のリンク（地理参照）をある期間にわたって保守することの２つの目的を果たす。
【００８７】
コンテンツ供給者クエリデータベース（ＣＳＱ）：  このデータベースは、ＰＯＩの名称、種類及びサブタイプ、キーワード、住所、マーカ及びアドレスポイントＩＤ、住所等、基本的な位置情報サービス（ＬＢＳ）クエリを完了し且つＰＯＩが地図上に表示されるために十分な結果を返送するために基本的に必要なものを全て含む。このデータベースは、特に指定されたデータホスト又はコンテンツプロバイダ自身のサイトにおいてホストされてもよい。
【００８８】
コンテンツ供給者供給元データベース（ＣＳＳ）：  このデータベースは、地理参照される前にコンテンツプロバイダがＶＤＢに提供しなければならない元のデータを含む。これは、電話番号、連絡先、ウェブページ、電子メールアドレス、ファックス、テキスト記述等のＣＳＱでは入手できない（ＣＳＳ及びＣＳＱがＣＳＳＱとしてマージされない限り。以下を参照）多くの固有のコンテンツを含む。
【００８９】
異なるサイトに存在するデータベースへのアクセスは、ＳＯＡＰ又は別のプロトコルを使用するウェブサービスを介して行われる。ある特定の使用をサポートするための標準ウェブサービス定義が、データベースのクラス毎にあってもよい。これによりシステムは、以下を含む多くのインタフェースをサポートできる。
【００９０】
ＴＡ２Ｈ（「Tele Atlas to Host」）：  デジタル地図プロバイダ（例えばTeleAtlas）により第三者コンテンツのホストに対して利用可能にされるサービス。ホストは、自身をデータプロバイダとして登録し、自身のデータ供給元を説明し、自身のコンテンツを他のＶＤＢ参加者と共有するためのルールを定義することができる。ホストは、自身のコンテンツのサブセットを提出することにより、新しいＸＲＥＦマーカ、アドレスポイント及び他の場所参照に対する要求を提出できる。
【００９１】
Ｈ２ＴＡ（「Host to Tele Atlas」）：  第三者コンテンツのホストによりデジタル地図プロバイダ、例えばTele Atlasに対して利用可能にされるサービス。地図プロバイダは、更新データ（例えば、新しい又は移動されたアドレスポイント）のリストをコンテンツプロバイダに「押し出す」ことができる。
【００９２】
ＴＡ２ＡＤ（「Tele Atlas to Application Developer」）：  地図プロバイダによりアプリケーション開発者に対して利用可能にされるサービス。アプリケーション開発者は、コンテンツネットワークに登録し、要求に適したコンテンツ供給者に関するメタデータを探索できる。アプリケーション開発者は、ある特定のコンテンツプロバイダのサービスに対して料金を支払うことができる。
【００９３】
Ｈ２ＡＤ（「Host to Application Developer」）：  第三者コンテンツのホストによりアプリケーション開発者に対して利用可能にされるサービス。
【００９４】
コンテンツ供給者が２つのデータベース、すなわち第三者のサイトにおいてホストされる基本地図にリンクされるＬＢＳクエリをサポートするデータベースと、ＩＤにより利用可能なコンテンツ供給者自身のサイトにおける元のスキーマを使用する元のデータベースとを有する場合、これらは以下のウェブサービスと通信してもよい：ＣＳ２Ｈ（「Content Supplier to Host」）及びＨ２ＣＳ−（「Host to Content Supplier」）。
【００９５】
図９Ａは、標準的なＣＳＱデータベースを使用して基本コンテンツを共有し、元のデータベースにおける詳細なコンテンツがコンテンツプロバイダにより入手可能にされる環境を示す。コンテンツ供給者は、ＩＤにより単純なウェブサービスをクエリオブジェクトに供給し且つＣＳＱに更新データを提供する必要がある。これは、固有データベースを変更したくない高度に動的なデータプロバイダに対して適切な解決策である。
【００９６】
図９Ｂは、拡張スキーマを用いて（供給者からの追加コンテンツを含むために）、データがアプリケーション開発者に対してＣＳＳＱデータベースを介して入手可能にされる環境を示す。更新データは、単純なウェブサービスを介してコンテンツ供給者により入手可能にされる。これは、エンドユーザのクエリをサポートしない固有データベースを有するコンテンツプロバイダの比較的動的なデータに対して適切な解決策である。
【００９７】
図９Ｃは、拡張された標準スキーマ（供給者からの追加コンテンツを含むために拡張された）において、データがアプリケーション開発者に対してＣＳＳＱデータベースを介して利用可能にされる環境を示す。これは、高度に動的ではないデータに対して有効な解決策である。
【００９８】
図９Ｄは、コンテンツ供給者が、ウェブサービスをサポートし且つそれらに合わせて同調される限り任意の形式で、自身のデータベースを使用して、自身のデータをホストする環境を示す。これは、自身の動的コンテンツを保護する技術的に高度なコンテンツ供給者に対する適切な解決策である。
【００９９】
図９Ｅは、複数のＣＳＱからのコンテンツを単一のウェブサービスから入手可能にする累算器環境を示す。場合によって、複数のプロバイダのコンテンツを単一のデータベースに累積することは性能面で有用である。いくつかのアプリケーション開発者は、あるレベルのサービスを保証するためにこれを行う。複数の賛同プロバイダからのコンテンツは単一のＣＳＱに累積され、図９Ｅに示すように、Ｈ２ＡＤインタフェースを介して利用可能にされる。これは、州政府等の分散された機関から同様のコンテンツを累積する場合に特に有用である。この場合、累積ＣＳＱは広い有効範囲を提供できる。
【０１００】
・地図形式の変換
多くの第三者データ供給元は、異なる地図形式及び互換性のない地図形式を使用する。これを解決するために、ある形態のマッピング情報は仮想データベース（ＶＤＢ）環境において提供され、アドレスポイント、交通メッセージチャネル（ＴＭＣ）場所コード及びジオコーディングサービス等の情報を変換する。固定の地図形式が使用されない場合、代わりにポインタ、ＵＬＲＯ及び他の形態のリンクが使用されてもよい。一実施形態によると、参照ファイルは、アドレスポイントとデジタル地図において固定場所参照として機能するＴＭＣ場所コードとを含む。この場合、これらの参照は、第三者データをデジタル地図にリンクし且つ再位置決めするために使用される。例えば、ある特定の地図オブジェクトのエッジが移動された場合、そのエッジに関連するアドレスポイントは同様に移動する。この自動再位置決めは、参照ファイルの改定に応答して第三者データを再度ジオコードする必要を最小限にする。
【０１０１】
・アドレスポイント
一実施形態によると、アドレスポイントが提供される。典型的な参照ファイル又は基本地図において、住所を有する全ての場所が地図内に実際の点を有するわけではない。例えば、各所在地住所「1 Battery Street」及び「2Battery Street」は、それ自体の個別の地図上の点を有さなくてもよく、その代わりにより一般的な範囲「1 to 10 Battery Street」に含まれてもよい。一実施形態によると、これらの地図上の各場所は、それ自体の個別のアドレスポイントを付与される。アドレスポイントの利点は、使用が容易であり、地図内の任意の特定の場所を参照する際の動作速度がより速いことを含む。欠点は、地図上の多くの場所にアドレスポイントが付与される場合は対応するデータベースが非常に大きくなるため、注意しなければならないことである。
【０１０２】
・高度な統合データベース
一実施形態によると、統合データベースは、以下の追加機能を提供する：（１）第三者データオブジェクトをオンラインで中央に登録する（登録に必要なデータのみが中央に格納される必要があり、大部分のデータは第三者のサイトに維持される）；（２）（いくつかの実施形態において）再位置決めのために、参照ファイル内に固定場所マーカを提供又は作成する；（３）所在地住所情報等の情報の変化及び不一致を記録し、これらの変化を興味のある関係者に報告する；（４）種々の第三者データ供給元に関する任意の関連メタデータ、それらが含むコンテンツ及びそれらにアクセスし且つそれらを表示する方法を格納する；（５）アプリケーション開発者が、参照ファイルと第三者データ供給元との間の関係（２者関係、１対多関係及び多対多関係を含む）及び異なる第三者データ供給元間の関係を作成できるようにする；（６）地理空間的に関連するオブジェクトに対する自動関係構築サービスを提供する。一実施形態によると、統合データベースは、アドレスポイント、ＴＭＣ場所及び他の位置情報を含む地図識別子をデジタル地図プロバイダから受け取り、この位置情報を第三者データにリンクする。マッピングは、第三者データプロバイダが使用するためにそれらに返送される。所有権が主張される全ての第三者データを各データプロバイダの供給元に維持する一方、アプリケーション開発者は、種々のＡＰＩを利用して地図プロバイダからデジタル地図データを検索し、それを第三者データにマージして最終製品を作成できる。統合データベースが参照ファイルと第三者データベースとの間に存在するため、システムにより、第三者データ供給者は、自身のリリース予定に従ってデータベースを更新でき；第三者は、場所マーカ（以下に更に詳細に説明する）が自動的に参照ファイルの一部になることなく、場所マーカに対する要求を提出でき；第三者データ供給元内のデータ又は情報の品質がそれらの第三者の責任に留まるため、データオブジェクトに対する所有権及び責任は明確にされ；デジタル地図プロバイダ自身が保守責任を有するもの以外により参照ファイルが煩雑になることは回避され；種々のデータベース及びデータ供給元の開発を並行して且つ互いから非常に独立して行うことが可能になる。
【０１０３】
・オブジェクト参照
一実施形態によると、任意の既存のアドレスポイント、場所コード及び他の位置参照は、第三者データを参照ファイル上の地理的場所にリンクする機構を提供するために、ポインタ又はＵＬＲＯ情報から抽出可能である。第三者データが参照ファイルにジオコードされる場合、対応するアドレスポイントを配置するためにマッチングが実行される。ジオコード又は提供された場所に住所識別子（アドレスポイント等）が存在しない場合、一時的な住所識別子又はアドレスポイントが作成される。これは、例えば「220 Battery Street」等のある特定の建物の住所から開始するために、参照ファイル内に存在しなかった住所に特徴を追加するのに有用である。
【０１０４】
・マーカ
一実施形態によると、種々のマーカが統合データベースにおいて提供される。マーカは、仮想データベース環境に参加する種々のデータベース又はデータ供給元のうちの１つの単一エンティティを参照するレコードである。マーカにより、デジタル参照ファイル及び第三者データベースにおける変化の追跡は容易になり、定期的な再統合はより確実且つ効率的になる。一実施形態によると、場所マーカ、オブジェクトマーカ及び関係マーカを含む種々のマーカが使用可能である。
【０１０５】
・メタデータ
一実施形態によると、メタデータ情報はアドレスポイント及びマーカと共に格納可能である。メタデータは、外部の第三者データ供給元に関する情報を格納し、仮想データベースとアプリケーションプロバイダ及びデータ再販業者とのシームレスなデータ統合を補助する。メタデータは、データ供給元、接続情報、コンテンツ／スキーマ、有効範囲及びデータ品質等の情報、オブジェクトの種類及びクラス、並びにレストランの場所及びその場所に最も近い駐車場等のデータ特定関係情報を含んでもよい。仮想データベース環境の全ての実施形態がメタデータを利用するわけではない。
【０１０６】
・アクセスレジストリ
データプロバイダは、自身のデータの継続的な商業的価値を確保するために、データの適切な保護を必要とする場合がある。一実施形態によると、アクセスレジストリは、顧客又は第三者がデータを閲覧してもよいという制約及びそのデータと他の第三者データプロバイダとの間に存在することが許可されてもよい関係に関する制約を作成することにより、このレベルのセキュリティを維持するために提供される。
【０１０７】
・リリース更新ＡＰＩ
一実施形態によると、リリース更新ＡＰＩは、参照ファイルが新規リリースのサイクルで容易に更新される（データ更新を参照ファイルに押し出す「押し出し」処理又は仮想データベースシステムが更新データを参照ファイルに引き入れることができる「引き入れ」処理のいずれかを使用して）ようにするために提供される。リリース更新ＡＰＩを使用して、参照ファイルは、地図の完全な再リリース又は段階的なリリース処理を介して更新されてもよい。
【０１０８】
・ジオコーディングサービスＡＰＩ
一実施形態によると、ジオコーディングサービスは、住所のクリーンアップ／正規化を実行するため、並びに任意の自動化及び／又は半自動化された手段で住所をプロバイダのデジタル地図上にジオコードするために提供される。
【０１０９】
・アプリケーションプロバイダＡＰＩ
一実施形態によると、アプリケーションプロバイダＡＰＩは、第三者アプリケーション開発者が仮想データベースにアクセスし且つ全ての第三者データと統合されたプロバイダの地図（参照ファイル）をシームレスに閲覧できるようにするために提供される。
【０１１０】
・アドレスポイント更新処理ＡＰＩ
一実施形態によると、アドレスポイント更新処理ＡＰＩは、第三者が参照ファイルに追加される追加アドレスポイントを要求できるようにするために含まれる。
【０１１１】
・第三者データ／マーカマッピングＡＰＩ
一実施形態によると、第三者データ／マーカマッピングＡＰＩは、自身のデータがマッピングされたマーカ及び／又はジオコードの結果を第三者データプロバイダが取得できるようにするために提供される。
【０１１２】
《ＵＬＲＯを用いる仮想データベース環境》
上述のように、一実施形態によると、システムは、地図特徴に対する汎用的位置情報参照オブジェクト（ＵＬＲＯ）と呼ばれる固定マーカを利用できる。図１０は、本発明の別の実施形態に係る仮想データベース環境又は仮想データベースシステムを示す図である。本実施形態によると、仮想データベース環境はＵＬＲＯを使用する。図１０に示すように、仮想データベース環境２は、参照ファイルデータ４及び第三者データ６を含む。これらは互いにリンクされ、仮想データベース３を形成する。本実施形態によると、参照ファイルは、地理的場所１０３に関連付けられたＵＬＲＣ１００を含み、第三者ファイルは、地理的場所に関連付けられたデータ項目１０５に関連付けられたＵＬＲＣ１０２を含む。２００５年１１月１０日に出願され且つ本願に引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１１／２７１，４３６号公報「A METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS」において更に詳細に説明されているように、ＵＬＲＯは、選択された場所を識別するように設計される固定識別コードを含む。その場合、場所は１つ以上の地理項目に関連付けられてもよい。ＵＬＲＯは、参照ファイルと第三者ファイルとの間の方向転換可能なリンク又は接続を確立するために採用される。一実施形態によると、ＵＬＲＯ１０４、１０６はＵＬＲＯリポジトリ９８に格納される。ＵＬＲＯリポジトリ９８は、参照ファイルデータの一部であってもなくてもよい。ＵＬＲＯは以下の８つの主な構成要素を含み、その一部又は全部は特定の実施例に応じて利用されてもよい：１）名称情報のセット；２）座標の上位セット；３）場所に一意に対応する汎用的位置情報参照コード（ＵＬＲＣ）；４）参照ファイルポインタを含む参照ファイルポインタフィールド；５）１つ以上の第三者ファイルポインタを含む第三者ファイルポインタフィールド；６）参照ファイルバックポインタを含む参照ファイルバックポインタフィールド；７）１つ以上の第三者ファイルバックポインタを含む第三者ファイルバックポインタフィールド；及び８）メタデータフィールド。
【０１１３】
《デジタル地図プロバイダ及び第三者の役割》
上述のように、ＶＤＢを用いる手法の背景にある基本原理は、デジタル地図プロバイダが、自身のデジタル地図と複数の第三者データプロバイダに属するデータとの間の高信頼リンクを顧客に提供できるようにすることである。リンク処理の有用な副効果は、デジタル地図データプロバイダ及びその第三者パートナーの双方に属するデータの品質を向上するためのフィードバックを提供することである。第三者データと参照ファイルとの間のリンクが１度作成されると、それは無期限に維持可能である。これらのリンクの永続性が明らかであるため、後続のデータリリース間で第三者データを統合することがより容易になる。
【０１１４】
・第三者データの識別
第三者データオブジェクトは、その第三者データとデジタル地図プロバイダデータとの間の関係又は２つ以上の第三者データ供給元間の関係を取得するのに必要な情報を含む。これらのオブジェクトの内容の大部分は一般化された方法で扱われるが、ホストするエンティティに関わらず、仮想データベースは、関係を作成及び保守するために特に必要な情報に精通する必要がある。関係の最も重要なカテゴリは、第三者データオブジェクトのインスタンスと地図特徴のインスタンスとの間であり、本明細書において「リンク」と呼ばれる。リンクは、第三者地図特徴を交通要素に対して配置し、第三者データを交通要素のセグメントに結び付け、第三者データを地図特徴全体に結び付け、且つ地図特徴間の関係を記述するために使用される。
【０１１５】
・リンクするために使用される第三者データの内容の識別
一実施形態によると、第三者データ供給元は、ＶＤＢ管理者がそれらのデータへの必要なリンクを作成できるようにするために、十分な情報を提供する必要がある。その後、この情報は、１つの形態又は別の形態のデータベーステーブルに符号化される。提供されてもよい情報のいくつかの種類は以下を含む：（１）第三者データオブジェクトを参照ファイルの交通ネットワークに対して配置するために使用されるリンク；（２）交通ネットワークのセグメントを参照し、動的な第三者属性又は他の記述的情報にリンクされる交通要素のセグメントを特定するリンク；（３）第三者データオブジェクトを地図特徴に結び付けるリンク。これは、特徴の一部ではなく特徴全体に対する参照であるため、前述のカテゴリとは異なる；及び（４）地図特徴間のリンク。これによりＶＤＢ管理者は、第三者データ供給元からの地図特徴間の関係を統合できる。
【０１１６】
《ＶＤＢ第三者リンク処理》
上述のように、一実施形態によると、参照ファイル内の情報及び第三者データは、仮想データベースを形成するためにリアルタイムでリンクされる。図１１〜図１８は、本発明の一実施形態に従って、仮想データベースを作成及び使用する方法の種々のステップを示す。特に、図１１において、固定識別子は最初にデジタル地図データプロバイダの参照ファイル内の特徴に割り当てられる。
【０１１７】
図１２において、場所情報（住所又は座標等）は、適用可能な場合は任意の第三者オブジェクト記述子、ＩＤ又はリンクの種類と共に、第三者のデータベース又はデータ供給元から参照ファイル内にあるか又はそれに関連付けられる一時テーブルにコピー又は送信される。
【０１１８】
図１３において、システムは、自動化ツール（ジオコーディング、データベースクエリ）の組み合わせ及び必要な場合は手動操作を使用して、参照ファイルへのリンクを作成する。
【０１１９】
図１４において、前のステップで作成されたリンクは、第三者に配布又は通信される。この時点において、第三者ソフトウェア製品又はユーザインタフェースは、仮想地図をエンドユーザに提供する等の種々の異なる方法でリンクを利用するように構築される。
【０１２０】
上述のステップは動的に、すなわち、ユーザ又は別のシステムからの仮想地図又は地図情報へのアクセス要求時にリアルタイムで実行可能である。いくつかの実施形態において、デジタル地図プロバイダは仮想地図自体を作成できる。リンクが第三者に配布されるため、第三者も仮想地図を作成できる。上述のように、仮想地図の作成は、任意の予備情報が最初の要求に応答して返送され且つ後続の情報がより詳細な要求に応答して返送される断片的な処理であってもよい。
【０１２１】
図１５において、システムは定常状態にあり、この状態において、関係者は各々のデータセットを保守できる。デジタル地図データプロバイダは、自身のデータセット、すなわち参照ファイル内の地図特徴の任意の変更、削除及び作成によるリンクにおける変化を記録する責任を有する。同様に、第三者は、自身のデータセット（すなわち第三者データファイル）内のデータオブジェクトの削除又は再位置決めによるリンクにおける変化を記録する責任を有する。
【０１２２】
図１６において、例えば、情報が第三者ファイル内で変化し且つ第三者が場所及び使用不能になったリンクの更新リストをデジタル地図データプロバイダに配布する場合、システムは再同期化を許可する。
【０１２３】
図１７において、システムは修復を許可する。不要なリンクは参照ファイルから除去される。新しいリンク及びいずれかのデータベース内での任意の変更により使用不能になったリンクは再生成される。
【０１２４】
図１８において、システムは、任意の更新されたリンク及び他の情報を第三者に再配布する。これにより、仮想データベースがユーザ要求に応答して読み込まれる場合に複数のデータ供給元からの地図データに一貫性があることが保証される。この場合も、この時点において、新しいリンクを利用するソフトウェア製品、ユーザインタフェース又は機能ＡＰＩが構築可能である。特に、第三者も更新された情報を受信するため、第三者は、この更新された情報を自身のソフトウェア製品において使用できるという利益を有する。
【０１２５】
図１９〜図２６は、ＵＬＲＯが使用される本発明の別の実施形態に従って、仮想データベースを作成及び使用する方法の種々のステップを示す。図１９〜図２６の動作は、図１１〜図１８の動作とそれぞれ非常に類似する。本実施形態における相違点は、標準地図形式、ポインタマッピング又は他の任意の形態のマッピングの代わりに、ＵＬＲＯがリンク作成のための基礎を形成するために使用されることである。更に、ＵＬＲＯはＵＬＲＯリポジトリに格納される。図１９〜図２６において、ＵＬＲＯリポジトリをデジタル地図プロバイダと共に示すが、これは地図プロバイダ又は第三者から独立した場所を含むシステム内の任意の場所に配置可能である。ＵＬＲＯリポジトリは、必要に応じてＵＬＲＯ内のリンクを自動的に更新することにより、それらを保守する。大部分の他の面において、ステップは同一である。すなわち図１９は、システムが、本実施形態においてはＵＬＲＯの形態である固定識別子をデジタル地図データプロバイダの地図（参照ファイル）内の特徴に割り当て且つ保守することを示す。図２０において、システムは、適用可能な場合は第三者オブジェクト記述子、ＩＤ及びリンクの種類と共に、場所情報（住所又は座標等）を第三者のデータベースからＵＬＲＯ内の対応するＵＬＲＯフィールドにコピーする。図２１において、システムは、自動化ツール（ジオコーディング、データベースクエリ）の組み合わせ及び必要な場合は手動操作を使用して、参照ファイルへのリンクを作成する。本実施形態において、ＵＬＲＯは、必要な場合に第三者地図オブジェクトに割り当てられ、参照ファイル内の同一オブジェクトと同様の識別子（ＵＬＲＯの実施例においてはＵＬＲＣである）を第三者地図オブジェクトに付与する。ＵＬＲＯは、２００５年１１月１０日に出願され且つ本願に引用されその内容がここに合体される、発明者Gil Fuchsによる同時係属米国特許出願第１１／２７１，４３６号公報「A METHOD AND SYSTEM FOR CREATING UNIVERSAL LOCATION REFERENCINGOBJECTS」において更に詳細に説明されている。図２２において、前のステップで作成されたか又はＵＬＲＯポインタフィールドにコピーされたリンクは第三者に配布される。この時点において、ソフトウェア製品又はユーザインタフェースは、種々の異なる方法でリンクを利用して構築される。上述の実施形態と同様に、上述のステップは動的に、すなわち、ユーザ又は別のシステムからの仮想地図又は地図情報へのアクセス要求時にリアルタイムで実行可能である。いくつかの実施形態において、デジタル地図プロバイダは仮想地図自体を作成できる。あるいは、リンクが第三者に配布されるため、第三者も仮想地図を作成できる。図２３において、システムは、異なるデータセットに対して責任を有する関係者によるその特定のデータセットの保守を許可する。デジタル地図データプロバイダは、地図特徴の任意の変更、削除及び作成によるリンクにおける変化を記録する責任を有する。第三者は、自身の（第三者）データにおけるデータオブジェクトの削除又は再位置決めによるリンクにおける変化を記録する責任を有する。仮想データベースが生成される場合には新しい属性に到達するために同一リンクが使用されるため、地図内の特徴の属性の変更等の��三者データにおける単純な変化は、リンク自体への変更を必要としなくてもよい。図２４において、システムは再同期化を許可し、第三者は、場所及び使用不能になったリンクの更新リストをデジタル地図データプロバイダに配布する。図２５において、システムは修復を許可し、不要なリンクは参照ファイルから除去される。図２６において、システムは更新されたリンクを第三者に再配布する。しかし、ＵＬＲＯが動的な特徴であり、地図プロバイダ又は第三者から独立して存在できるため、更に、ＵＬＲＯリポジトリが必要に応じてＵＬＲＯ内のリンクを自動的に更新することによりそれらを保守するため、大部分の実施形態によると、図２４〜図２６に示す後半のステップは不要である。最後に、同様に上述したように、第三者も更新された情報を受信するため、第三者は、この更新された情報を自身のソフトウェア製品において使用できるという利益を有する。この時点で、ソフトウェア製品又はユーザインタフェースは、新しいリンクを利用して構築される。
【０１２６】
上述した全ての例において、リンク更新処理は、参照ファイルと単一の第三者ファイルとの間で行われるものとして示された。しかし、他の実施形態において、リンクの更新は逆方向で行われもよく、すなわち、第三者ファイルにおける更新から開始して参照ファイルを更新してもよいことは明らかだろう。更に、上述の例は、参照ファイルと単一の第三者ファイルとの間のリンク更新処理を示したが、リンクの更新は、参照ファイルと多くの第三者ファイルとの間又は１つの第三者ファイルと別の第三者ファイルとの間であってもよいことは明らかだろう。上述のように、他の実施形態において、任意のデータファイル又はデータ供給元が第三者ファイルとして機能でき、その他のデータファイルを参照ファイルとして扱うため、これらの名称は説明のための表記にすぎないことを意図する。
【０１２７】
《ＶＤＢの使用例》
図２７及び図２８は、地図情報をエンドユーザに提供するために、実際の状況で使用されてもよいＶＤＢシステムの一実施形態を示す図である。図２７に示すように、地図プロバイダ（例えばTele Atlas）は、参照ファイル又はデジタル地図データの同等のセットを提供する。本例においては１つだけ示す第三者データ供給者は、地点情報（ＰＯＩ）のセットに関する情報を提供する。本明細書において使用されるように、用語「地点情報」は、必ずしも点だけではなく、線特徴、領域特徴、複雑な特徴及び他の地図特徴を示すためにも同様に使用される。新しいＰＯＩは地図プロバイダに通信され、最終的に参照ファイルに組み込まれる。エンドユーザからの要求に応答して、地図プロバイダからの情報（参照ファイル）は第三者からの情報と統合され、アプリケーションベンダのアプリケーションを介してエンドユーザに配布される。
【０１２８】
図２８に示すように、仮想データベース環境により、参照ファイルの地図は第三者の地点情報（ＰＯＩ）から独立して更新される。第三者データプロバイダは、自身のデータベースを自身の必要性に従って更新し、地図プロバイダから新しい又は更新したＰＯＩ毎にマーカを取得する。ＰＯＩサーバは、ＰＯＩ更新データをアプリケーションサーバに通信する役割を果たす。この場合、アプリケーションサーバは、統合サーバ及びエンドユーザに対する配布媒体の双方として機能する。ユーザ要求に応答して、アプリケーションサーバは、適切に更新され且つ統合された情報を提供する。特定の実施形態に応じて、更新は、エンドユーザとの間の押し出し又は引き入れ４７４のいずれであってもよい。この更新技術を使用して、ＰＯＩ及び関連付けられるコンテンツは、ある特定のユーザ要求に応答して選択される前に、高度に探索及び検査される。第三者アプリケーションは、アプリケーションが作成される時点でＰＯＩ供給元から入手可能な最新のＰＯＩデータを含む媒体と共に出荷される。
【０１２９】
本発明の上記説明は、例示及び説明のために与えられた。これは、全ての実施形態を含むこと又は本発明を開示される形態に限定することを意図しない。多くの変更及び変形は当業者には明らかだろう。
【０１３０】
コンピュータ分野の当業者には明らかなように、本発明は、本開示の教示に従ってプログラムされた従来の汎用又は専用デジタルコンピュータ又はマイクロプロセッサを使用して良好に実現されてもよい。ソフトウェア分野の当業者には明らかなように、適切なソフトウェア符号化は、本開示の教示に基づいて、熟練したプログラマにより容易に用意される。また、当業者には容易に明らかとなるように、本発明は、特定用途向け集積回路を用意するか又は従来の構成要素回路の適切なネットワークを相互接続することにより実行されてもよい。
【０１３１】
本発明は、本発明の任意の処理を実行するようにコンピュータをプログラムするために使用可能な命令が格納された記憶媒体であるコンピュータプログラム製品を含む。記憶媒体は、フロッピディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ及び光磁気ディスクを含む任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ素子、磁気カード又は光カード、ナノシステム（分子記憶ＩＣを含む）、あるいは命令及び／又はデータを格納するのに適した任意の種類の媒体又は素子を含むことができるが、これらに限定されない。
【０１３２】
任意のコンピュータ可読媒体に格納される場合、本発明は、汎用／専用コンピュータ又はマイクロプロセッサのハードウェアの双方を制御し且つコンピュータ又はマイクロプロセッサが本発明の結果を利用して人間のユーザ又は他の機構と対話できるようにするソフトウェアを含む。そのようなソフトウェアは、デバイスドライバ、オペレーティングシステム及びユーザアプリケーションを含んでもよいが、それらに限定されない。最終的に、そのようなコンピュータ可読媒体は、上述のように本発明を実行するソフトウェアを更に含む。
【０１３３】
メディアストリームの取り込み及び註釈、重要な記録すべきイベントの時系列の形成、静止フレームとメディアストリーム内の点又はそのセグメントとのリンク、任意のスライド変化の認識、メディアストリームの少なくとも一部を記述するメタデータの形成及び分配、並びに本発明の処理に従った結果の通信を含むがそれらに限定されない本発明の教示を実現するソフトウェアモジュールは、汎用／専用コンピュータ又はマイクロプロセッサのプログラミング（ソフトウェア）に含まれる。
【０１３４】
本発明の上記説明は、例示及び説明のために与えられた。実施形態は、本発明の原理及びその実際の用途を最適に説明し、それによって他の当業者が、種々の実施形態に対して及び考えられる特定の使用に適した種々の変更を用いて本発明を理解できるようにするために選択及び説明された。本発明の範囲は、以下の請求の範囲及びその均等物により定義されることが意図される。
【図面の簡単な説明】
【０１３５】
【図１】本発明の一実施形態に係る仮想データベース環境を示す図である。
【図２】従来の方法に従って複数の地図データベースを統合する手段を示す図である。
【図３】本発明の一実施形態に係る仮想データベースシステムを使用して複数の地図データベースを統合する手段を示す図である。
【図４】本発明の一実施形態に係る仮想データベースシステム又は仮想データベース環境を使用する異なる関係者間の対話を示す図である。
【図５】本発明の一実施形態に係る仮想データベースシステムを使用する方法であって、仮想データベースを作成する際に最初に場所識別子が作成される方法を示すフローチャートである。
【図６】本発明の一実施形態に係る仮想データベースシステムを使用する方法であって、仮想データベースを作成する際に既存の場所識別子が使用される方法を示すフローチャートである。
【図７】本発明の一実施形態に係る仮想データベースシステムのアーキテクチャを示す図である。
【図８】本発明の一実施形態に係る仮想データベースを使用する一般的な方法のステップを含むフローチャートである。
【図９Ａ】、
【図９Ｂ】、
【図９Ｃ】、
【図９Ｄ】、
【図９Ｅ】本発明の実施形態に従って、第三者データが仮想データベースにおいて追加コンテンツと様々な信頼度で統合される方法を示す図である。
【図１０】本発明の一実施形態に係るＵＬＲＯを使用する仮想データベースを示す図である。
【図１１】本発明の一実施形態に係る仮想データベースを使用する一般的な方法のステップを示す図である。
【図１２】本発明の一実施形態に係る仮想データベースを使用する一般的な方法の更なるステップを示す図である。
【図１３】本発明の一実施形態に係る仮想データベースを使用する一般的な方法の更なるステップを示す図である。
【図１４】本発明の一実施形態に係る仮想データベースを使用する一般的な方法の更なるステップを示す図である。
【図１５】本発明の一実施形態に係る仮想データベースを使用する一般的な方法の更なるステップを示す図である。
【図１６】本発明の一実施形態に係る仮想データベースを使用する一般的な方法の更なるステップを示す図である。
【図１７】本発明の一実施形態に係る仮想データベースを使用する一般的な方法の更なるステップを示す図である。
【図１８】本発明の一実施形態に係る仮想データベースを使用する一般的な方法の更なるステップを示す図である。
【図１９】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法のステップを示す図である。
【図２０】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法の更なるステップを示す図である。
【図２１】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法の更なるステップを示す図である。
【図２２】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法の更なるステップを示す図である。
【図２３】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法の更なるステップを示す図である。
【図２４】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法の更なるステップを示す図である。
【図２５】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法の更なるステップを示す図である。
【図２６】本発明の一実施形態に係るＵＬＲＯを用いる仮想データベースを使用する方法の更なるステップを示す図である。
【図２７】ＶＤＢシステムの適用例を示す図である。
【図２８】ＶＤＢシステムの別の適用例を示す図である。
【図１】
2009536372.tif 000003
【図２】
2009536372.tif 000004
【図３】
2009536372.tif 000005
【図４】
2009536372.tif 000006
【図５】
2009536372.tif 000007
【図６】
2009536372.tif 000008
【図７】
2009536372.tif 000009
【図８】
2009536372.tif 000010
【図９Ａ】
2009536372.tif 000011
【図９Ｂ】
2009536372.tif 000012
【図９Ｃ】
2009536372.tif 000013
【図９Ｄ】
2009536372.tif 000014
【図９Ｅ】
2009536372.tif 000015
【図１０】
2009536372.tif 000016
【図１１】
2009536372.tif 000017
【図１２】
2009536372.tif 000018
【図１３】
2009536372.tif 000019
【図１４】
2009536372.tif 000020
【図１５】
2009536372.tif 000021
【図１６】
2009536372.tif 000022
【図１７】
2009536372.tif 000023
【図１８】
2009536372.tif 000024
【図１９】
2009536372.tif 000025
【図２０】
2009536372.tif 000026
【図２１】
2009536372.tif 000027
【図２２】
2009536372.tif 000028
【図２３】
2009536372.tif 000029
【図２４】
2009536372.tif 000030
【図２５】
2009536372.tif 000031
【図２６】
2009536372.tif 000032
【図２７】
2009536372.tif 000033
【図２８】
2009536372.tif 000034
【国際調査報告】
2009536372.tif 000035