(57)【要約】  ユニバーサル位置参照オブジェクト（ＵＬＲＯ）を生成し、かつ／または、ユニバーサル位置参照オブジェクト（ＵＬＲＯ）を、電子地図を含む電子ファイルに使用する方法およびシステム。ＵＬＲＯは、参照ファイルとサードパーティ・ファイルとの間に横断可能なリンクを確立する。一実施形態により、ＵＬＲＯは、名称情報セット、座標上位セット、参照ファイル・ポインタを含む参照ファイル・ポインタ・フィールド、１つまたは複数のサードパーティ・ファイル・ポインタを含むサードパーティ・ファイル・ポインタ・フィールド、参照ファイル・バックポインタを含む参照ファイル・バックポインタ・フィールド、１つまたは複数のサードパーティ・ファイル・バックポインタを含むサードパーティ・ファイル・バックポインタ・フィールド、およびメタデータ・フィールドを含め、いくつかの随意のコンポーネントとともに、その位置に一意的に対応するユニバーサル位置参照コードを含む。ＵＬＲＯにより、異なる地図においてフィーチャー（地物、feature）が同等であることを認識でき、また、多種多様な地図フォーマットに対して横断可能に連結して、複数の地図を動的に組み合わせるか、あるいはリンクさせて、１つの仮想地図を形成することが容易となる。【選択図】  図１
2009520992.tif 000002
【特許請求の範囲】
【請求項１】
ユニバーサル位置参照オブジェクトを利用して、位置に対する地理アイテム情報を提供するシステムであって、
位置に関連づけられた地理アイテムを含む地理アイテム情報を含む参照ファイルとのインターフェースと、
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含むサードパーティ・ファイルとのインターフェースと、
（ａ）前記位置を一意的に識別するユニバーサル位置参照コード、（ｂ）前記位置に対する識別情報、（ｃ）前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含むユニバーサル位置参照オブジェクトと、
特定位置に対する情報の要求に応答して、前記特定位置に対して、ユニバーサル位置参照オブジェクトを取得し、前記リンクを横断し、前記サードパーティ・ファイル内の前記追加の地理アイテム情報を、前記参照ファイル内の前記地理アイテム情報に関連づけ、さらに、その結果得られた情報を、前記要求への応答として提供するロジックと、
を含むシステム。
【請求項２】
前記位置が実世界における物理的位置であり、また、前記地理アイテム情報が、前記物理的位置に関連づけられているフィーチャー（地物、feature）情報である請求項１に記載のシステム。
【請求項３】
前記物理的位置が、前記実世界における物理的位置を一意的に識別する一意的なユニバーサル位置参照コードを持っている請求項２に記載のシステム。
【請求項４】
前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクの一部が、前記ユニバーサル位置参照オブジェクトで参照されるサイド・ファイル内に形成されている請求項１に記載のシステム。
【請求項５】
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含む複数のサードパーティ・ファイルとのインターフェースを含み、また、前記ユニバーサル位置参照オブジェクトが、前記複数のサードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含む請求項１に記載のシステム。
【請求項６】
前記位置が電子地図中の位置として表され、また、前記地理アイテム情報が、前記位置に対して前記電子地図上にフィーチャーを表示するために使用される請求項１に記載のシステム。
【請求項７】
ユニバーサル位置参照オブジェクトを利用して、位置に対する地理アイテム情報を提供する方法であって、
位置に関連づけられた地理アイテムを含め、地理アイテム情報を含む参照ファイルにアクセスするステップと、
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含むサードパーティ・ファイルにアクセスするステップと、そして
特定位置に対する情報の要求に応答して、
前記特定位置に対して、（ａ）前記位置を一意的に識別するユニバーサル位置参照コード、（ｂ）前記位置に対する識別情報、（ｃ）前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含むユニバーサル位置参照オブジェクトを取得するステップと、
前記リンクを横断して、前記サードパーティ・ファイル内の前記追加の地理アイテム情報を、前記参照ファイル内の前記地理アイテム情報に関連づけるステップと、
その結果得られた情報を、前記要求への応答として提供するステップと、
を含む方法。
【請求項８】
前記位置が実世界における物理的位置であり、また、前記地理アイテム情報が、前記物理的位置に関連づけられているフィーチャー情報である請求項７に記載の方法。
【請求項９】
前記物理的位置が、前記実世界における物理的位置を一意的に識別する一意的なユニバーサル位置参照コードを持っている請求項８に記載の方法。
【請求項１０】
前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクの一部が、前記ユニバーサル位置参照オブジェクトで参照されるサイド・ファイル内に形成されている請求項７に記載の方法。
【請求項１１】
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含む複数のサードパーティ・ファイルにアクセスするステップをさらに含み、また、前記ユニバーサル位置参照オブジェクトが、前記複数のサードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含む請求項７に記載の方法。
【請求項１２】
前記位置が電子地図中の位置として表され、また、前記地理アイテム情報が、前記位置に対して前記電子地図上にフィーチャーを表示するために使用される請求項７に記載の方法。
【請求項１３】
前記要求が、前記電子地図、および前記位置に対する任意の関連フィーチャーを生成するために、利用者から受け取られる請求項７に記載の方法。
【請求項１４】
前記要求が、位置関連情報を取り込むために、システムまたは別のプロセスから受け取られる請求項７に記載の方法。
【請求項１５】
前記位置、または前記位置に関連づけられた前記地理アイテムに対して、ユニバーサル位置参照オブジェクトがまだない場合には、ユニバーサル位置参照オブジェクトを生成するステップをさらに含む請求項７に記載の方法。
【請求項１６】
複数のユニバーサル位置参照オブジェクトを取得するステップを含み、また、前記複数のユニバーサル位置参照オブジェクトの少なくとも一部が、ユニバーサル位置参照オブジェクト・リンクによりリンクされて、前記ユニバーサル位置参照オブジェクト間の関係をもたらす請求項７に記載の方法。
【請求項１７】
前記ユニバーサル位置参照オブジェクト・リンクが、前記ユニバーサル位置参照オブジェクト間の階層関係をもたらす階層リンクである請求項１６に記載の方法。
【請求項１８】
複数のユニバーサル位置参照オブジェクトを取得するステップを含み、また、位置に関連づけられた前記地理アイテムが今度は、前記複数のユニバーサル位置参照オブジェクトから選択された一群のユニバーサル位置参照オブジェクトにリンクされる請求項７に記載の方法。
【請求項１９】
前記ユニバーサル位置参照オブジェクトに含まれる前記位置に対する識別情報（ｂ）が、前記位置に対する名称、座標、またはリンク情報をどれでも含む請求項７に記載の方法。
【請求項２０】
前記位置に対する名称、座標、またはリンク情報を、前記ユニバーサル位置参照オブジェクトにおいて、いつでも追加できるか、更新できるか、あるいは削除できる請求項１９に記載の方法。
【請求項２１】
参照ファイルにも、また１つまたは複数のサードパーティ・ファイルにも入っている位置に対応する名称情報を決定するステップと、
前記位置に対応する座標上位セットを決定するステップと、
前記位置に一意的に対応するユニバーサル位置参照コードを割り当てるステップと、
前記参照ファイル内の前記位置を指定する参照ファイル・ポインタを生成するステップと、
前記サードパーティ・ファイルの１つに入っている前記位置をそれぞれが一意的に指定する１つまたは複数のサードパーティ・ファイル・ポインタを生成するステップと、
前記名称情報、前記座標上位セット、前記ユニバーサル位置参照コード、前記参照ファイル・ポインタ、および、前記サードパーティ・ファイル・ポインタを組み合わせて、ＵＬＲＯを生成するステップであって、前記ＵＬＲＯがさらに、前記参照ファイルから後方に前記ＵＬＲＯをさす参照ファイル・バックポインタと、前記サードパーティ・ファイルの１つから後方に前記ＵＬＲＯを一意的にさす１つまたは複数のサードパーティ・ファイル・バックポインタとを含むようなステップと、
のうちどのステップも実行することを含む請求項１９に記載の方法。
【請求項２２】
前記座標上位セットが複数（ｋ個）の座標セットを含む（ここで、ｋは、前記位置のジオメトリを表すのに必要な座標セットの数である）請求項２１に記載の方法。
【請求項２３】
ユニバーサル位置参照オブジェクトを利用して、前記位置に対する地理アイテム情報の提供を可能にするデータ構造であって、
位置に関連づけられた地理アイテムを含め、地理アイテム情報を含む参照ファイルをさすポインタと、
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含むサードパーティ・ファイルをさすポインタと、
（ａ）前記位置を一意的に識別するユニバーサル位置参照コード、（ｂ）前記位置に対する識別情報、（ｃ）前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含むユニバーサル位置参照オブジェクトと、
を含み、
前記参照ファイルをさすポインタ、前記サードパーティ・ファイルをさすポインタ、および前記ユニバーサル位置参照オブジェクトを組み合わせることにより、特定位置に対して、ユニバーサル位置参照オブジェクトを取り込むことができ、また、前記リンクを横断して、前記サードパーティ・ファイル内の前記追加の地理アイテム情報を、前記参照ファイル内の前記地理アイテム情報に関連づけるようなデータ構造。
【請求項２４】
前記位置が実世界における物理的位置であり、また、前記地理アイテム情報が、前記物理的位置に関連づけられているフィーチャー情報である請求項２３に記載のデータ構造。
【請求項２５】
前記物理的位置が、前記実世界における物理的位置を一意的に識別する一意的なユニバーサル位置参照コードを持っている請求項２４に記載のデータ構造。
【請求項２６】
前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクの一部が、前記ユニバーサル位置参照オブジェクトで参照されるサイド・ファイル内に形成されている請求項２３に記載のデータ構造。
【請求項２７】
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含む複数のサードパーティ・ファイルをさすポインタを含み、また、前記ユニバーサル位置参照オブジェクトが、前記複数のサードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含む請求項２３に記載のデータ構造。
【請求項２８】
前記位置が電子地図中の位置として表され、また、前記地理アイテム情報が、前記位置に対して前記電子地図上にフィーチャーを表示するために使用される請求項２３に記載のデータ構造。
【請求項２９】
ユニバーサル位置参照オブジェクトを利用して、前記位置に対する地理アイテム情報の提供を可能にするデータ構造を生成する方法であって、
位置に関連づけられた地理アイテムを含め、地理アイテム情報を含む参照ファイルをさすポインタを前記データ構造に格納するステップと、
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含むサードパーティ・ファイルをさすポインタを前記データ構造に格納するステップと、
（ａ）前記位置を一意的に識別するユニバーサル位置参照コード、（ｂ）前記位置に対する識別情報、（ｃ）前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含むユニバーサル位置参照オブジェクトを前記データ構造に格納するステップと、
を含み、
前記参照ファイルをさすポインタ、前記サードパーティ・ファイルをさすポインタ、および前記ユニバーサル位置参照オブジェクトを組み合わせることにより、特定位置に対して、ユニバーサル位置参照オブジェクトを取り込むことができ、また、前記リンクを横断して、前記サードパーティ・ファイル内の前記追加の地理アイテム情報を、前記参照ファイル内の前記地理アイテム情報に関連づけるような方法。
【請求項３０】
前記位置が実世界における物理的位置であり、また、前記地理アイテム情報が、前記物理的位置に関連づけられているフィーチャー情報である請求項２９に記載のデータ構造を生成する方法。
【請求項３１】
前記物理的位置が、前記実世界における物理的位置を一意的に識別する一意的なユニバーサル位置参照コードを持っている請求項３０に記載のデータ構造を生成する方法。
【請求項３２】
前記サードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクの一部が、前記ユニバーサル位置参照オブジェクトで参照されるサイド・ファイル内に形成されている請求項２９に記載のデータ構造を生成する方法。
【請求項３３】
前記位置に関連づけられるかもしれない追加の地理アイテム情報を含む複数のサードパーティ・ファイルをさすポインタを含み、また、前記ユニバーサル位置参照オブジェクトが、前記複数のサードパーティ・ファイル内の前記追加の地理アイテム情報とのリンクを含む請求項２９に記載のデータ構造を生成する方法。
【請求項３４】
前記位置が電子地図中の位置として表され、また、前記地理アイテム情報が、前記位置に対して前記電子地図上にフィーチャーを表示するために使用される請求項２９に記載のデータ構造を生成する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子地図、電子文書、電子データベースに関し、具体的に言えば、このような電子地図、電子文書、電子データベースに使用するユニバーサル位置参照オブジェクト（universal location referencing object）を作成する方法およびシステムに関する。
【０００２】
（優先権の主張）
２００５年１１月１０日に出願されたＧｉｌ  Ｆｕｃｈｓ氏による「Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｃｒｅａｔｉｎｇ  Ｕｎｉｖｅｒｓａｌ  Ｌｏｃａｔｉｏｎ  Ｒｅｆｅｒｅｎｃｉｎｇ  Ｏｂｊｅｃｔｓ（ユニバーサル位置参照オブジェクトを生成する方法およびシステム）」と称する米国特許出願第１１／２７１，４３６号（Ａｔｔｙ．Ｄｏｃｋｅｔ  Ｎｏ．ＴＥＬＡ−０７７４７ＵＳ０）。
【背景技術】
【０００３】
歴史的に見ると、文書は、紙、または他の修正できない非対話形の媒体上に印刷されたために、利用者が、その情報や、例えばデータポイント間の関係をいっさい修正できなかった。さらに、新たな情報が現われたときでも、文書を更新できなかったし、また、その「データベース」の概念（この語の最新の意味において）は存在すらせず、そのことから、文書を更新するという考えは起こりそうもなかった。
【０００４】
コンピュータ時代よりも前には、地図に修正の必要があるときはいつでも、本質的に、２つの依頼形式があった。すなわち、１）地図の紙コピー（１つまたは複数）に手による訂正を加えるか、あるいは、２）オリジナルに訂正を施して、地図を印刷し直すことであった。手による訂正は、時間集約的なものであり、特に複数の修正の場合、当然のこととして、この地図の他の残りのコピーはどれも更新しない。この地図を印刷し直すという第２の選択は費用がかかり、さらに、頻繁な修正に応じる実際的でないやり方でもある。
【０００５】
今の時代では、要望通りに更新でき、また、選択された範囲およびタイプの操作者入力に応答して、操作者で要求される出力を生み出すことのできるデータベース、文書、およびデジタル、電子フォーマットの地図が、主として紙の地図に取って代わっている。常用されている多くの電子文書や電子データベースは、今日、地理的位置（１つまたは複数）に関連した情報を含む。実際は、或る形式の地理関連情報をできる限り頻繁に取り入れる電子文書の類または電子データベースの類を思いつくことは容易ではない。
【０００６】
本発明のいくつかの実施形態と関連がある電子データベースの例は、一般に「電子地図」または「デジタル地図」と呼ばれている「地理空間データベース（ｇｅｏｓｐａｔｉａｌ  ｄａｔａｂａｓｅｓ）」である。今日、地図は、或る特定の時間に記録される補正できないデータセットの静的な紙描写として、それらの何百年も経た地位を優に越えて進化している。わかりやすくするために、以下の説明の大部分は、電子地図をさしている。ただし、作られたポイントは、地図以外の地理的情報が入っている、電子文書や電子データベースにも適用される。
【０００７】
伝統的な紙ベースの地図に優るデジタル地図の恩恵の１つは、デジタル地図固有の柔軟性と、デジタル地図が多量のデータを表現できる能力である。紙の地図は、それらの物理的なフォーマットの制約条件内で、紙の地図が表現できる情報量や情報タイプが必然的に制限される。紙の地図はまた、更新が困難でもある。
【０００８】
デジタル地図は、以上の問題を蒙らない。以前のデジタル地図は、単に、この紙製品をスキャンしたものであるように思われたかもしれないが、今日の最新のデジタル地図は、はるかに効果的である。情報が地図に含まれ、また、この情報は、操作者の希望により、表示されたり、あるいは、表示されないこともある。
【０００９】
今日のデジタル地図（これも、電子地図として知られている）は、関心のある所望の地理的フィーチャー（geographic features）の積極的な操作者選択に加えて、この地図に含まれるデータポイントを定期的に修正することが可能である。関心のある地図に具体的に関連するタイプの新たな情報が発生すると、その地図全体をすぐ更新して、位置のすべて、あるいはほんのわずかなサブセット（一部）の変更または訂正を反映する。
【００１０】
デジタル地図は、いくつかのタイプの操作者入力に応答でき、また、操作者により補正可能な一連の出力を提供できることがある。現在の電子地図は、地図を見るときのスケールを選択するオプションを操作者に与える。これは、「ズームイン」機能および／または「ズームアウト」機能を用いて行われることが多い。このような特徴は、重要であって、かつ役に立つが、実際には、特定の地図に入っているコンテンツを変更しないで、この地図を、別の詳細度にて、また別の地理的焦点（focus）を用いて表現する。
【００１１】
電子地図の代表的な用途は、旅行業界であり、旅行業界では、デジタル地図を使用して、旅行ルートをすばやく、かつ自動的に図表で表し、また、目的地を捜し出す。デジタル地図は、特に一般的に日常、自動車に使用されており、デジタル地図と共同して、ＧＰＳ（全地球測位システム）および他の位置決定装置を使用して、車の位置を自動的に追跡して、その位置を地図上に表示し、例えば、運転者を特定の目的地に導く。
【００１２】
デジタル地図はまた、商業環境において、例えば、配達を行おうとするときに、配達運転者が取る最適ルートを計算するのに使用されるか、あるいは、緊急呼出しに応じようとするときに、救急・医療乗務員がたどる正確な方向を与えるために使用されることが多い。電子地図業界はまた、地図を軍事用途に使用するために、何年間も軍部に提供してきた。デジタル地図は、地上ベース、海運、航空の目的を含む業界のあらゆる面に使用される。人々が、ＰＤＡ（携帯用情報端末）やスマートフォンなどの携帯用のハンドヘルド電子装置（中に格納された電子地図といっしょに提供することがますます増えている）に慣れ親しむにつれて、この電子地図またはデジタル地図の業界が成長して、社会の事実上すべての面に浸透してきた。
【００１３】
現在入手できるいくつかのデジタル地図は、文字住所と、地図上の文字住所の位置とをリンクできるようにしている。例えば、操作者が、市街住所を、Ｙａｈｏｏ！  Ｍａｐｓソフトウェア・アプリケーション、ＭａｐＱｕｅｓｔ、もしくは、それらに類するインターネット・マッピング・ウェブサイトに入力する場合には、その出力は、その周囲エリアが描かれている地図上において、その特定住所の位置を示している。本質的には、関心のある住所を取り囲む領域の地図は、その選択地点の周りに構築される。この地図は、有益な情報のオーバーレイ（overlays）（重ね合わせ）を含むことがある。例えば、サンフランシスコの市街地図は、サンフランシスコの鉄道系統の地図で覆われ、さらに、その地図が、サンフランシスコのレストランや駐車施設を表すアイコンで覆われる。
【００１４】
しかしながら、これらの様々なオーバーレイは、「地図レベルのオーバーレイ」であって、これは、これらのオーバーレイが、それらの座標に基づいて互いに揃えられることを意味している。このオーバーレイ中の異なる地点間、あるいは、一方のオーバーレイ中の一地点と他方のオーバーレイ中の一地点との間では、一般に、いかなる相互作用機能（interactivity）も利用できない。このような座標オーバーレイ（coordinate overlay）により、エンドユーザーには単一の地図のように思えるものが得られるとは言え、それは、完全に統合された１つのインテリジェント・デジタル地図のように動的な働きをすることができない。ある意味では、或るレイヤでの実体（entities）は、他の任意のレイヤでの実体については何も知らず、それゆえ、これらの実体間の有益なリンク（連係）に関係があるさらなるデータ処理をサポートできない。さらに、このようなオーバーレイ・マップ（overlay map）は、異なる地図および異なる空間データファイルのスケール、フォーマット、座標系により許される場合にのみ、可能である。このようなオーバーレイ・マップは、１つまたは複数の文書中の情報が地図の形式で示されない場合には、実行できない。
【００１５】
例えば、レストランの情報は、レストラン名と住所の文字リストの形式を取ることがある。このような場合、伝統的な方法を使用して、このレストランのデータを、この例の鉄道および市街データとシームレスに一体化する容易な方法はない。過去のソリューションは、市街地図中にあるその住所を見つけ、かつ一組のアイコンを生成して、オーバーレイとして表示することで、そのレストランの座標を単に見出した。これにより、単純な住所リンケージが可能になるとは言え、さらに高度なリンケージは不可能であった。
【００１６】
別法として、さらに豊富な一組のリンケージが可能となることもあるが、ただし、同一の単一統合地図ファイル内にすべての情報が含まれている場合に限られる。これは、空間知識（spatial knowledge）の全体を単一の電子地図に組み入れるために、単一の地図販売業者にますます持ちこたえられなくなる負担をかける。しかしながら、ほとんどの場合に、この地図販売業者は、必要なすべての情報を入手しさえせず、したがって、地図販売業者に誠心誠意があるにもかかわらず、完全に統合された地図を作成することがますます困難になってくる。
【００１７】
最後に、伝統的な方法により、或るレイヤ上の実体の配置のいかなる変更も、他のレイヤ中の実体と自動的に総合調整できず、それにより、これらのレイヤをすべて統合しておくときに、多くの余分の作業が必要となる。
【発明の開示】
【課題を解決するための手段】
【００１８】
インターネット、一般に情報時代の進行とともに、統合インテリジェント電子地図中で互いにリンクされるかもしれない空間コンポーネントを持つデータがますます多く利用できるようになっている。伝統的な方法の欠点として、この階層化手法は、上記のインテリジェント・リンケージを扱わず、それゆえ、利用できるようになる空間コンテンツがいっぱいあることを問い合わせる能力を制限することになる。さらに、座標関連のデータを同期化させておくときに手間がかかるために、このような伝統的な手法は、維持および更新できるデータの全体量を制限する。さらに、地図利用者に関心があって、かつデジタル的に利用できる空間関連の情報の急増があれば、このような情報の全体集合（entire uiverse）を作り出して、維持することは、地図関連の企業にとって、経済的にも、またロジスチックにも実行できない。本発明が取り組むことを目的とするものは、従来技術の上記および他の制限である。
【００１９】
一般的に述べると、本発明は、電子文書、電子データベース、電子地図（これらは、本明細書では、一まとめにして「電子空間データファイル」（electronic spatial data files）と呼ばれている）と共同して用いられるユニバーサル位置参照オブジェクト（universal location referencing objects）（ＵＬＲＯ）を生成する方法およびシステムを提示する。或る種類の電子空間データファイルに関して本明細書に述べられる事実上すべてのものを、妥当性が失われることなく、別の種類の電子空間データファイルに適用することもできる。ただ１つの論理空間データファイルが区分されることがある。したがって、或る論理電子空間データファイルは、地理的定義を持つか、あるいは持たない１つまたは複数の物理ファイルを含むことがある。
【００２０】
伝統的な方法に関して上述の制限に取り組むために、「仮想地図」（virtual maps）を作成するシステムを案出することが望ましい。仮想地図は、１つまたは複数のデータベースに入っている情報を動的に結びつけて、その情報を、シームレスに、かつリアルタイムで操作者に提示することのできるデジタル地図として、ここに定義される。一般に、最新の電子地図は、或る電子地図またはデータベース中の関心地点（points of interest）を、第２の電子地図または別のデータベース中の関心地点とリンクさせて、或る地図中のオブジェクトと、第２の地図またはデータベース中のオブジェクトとの関係を用いて、仮想地図を作成することはできない。
【００２１】
本発明の目的は、地理的位置、その地理的位置に関連づけられた名称、およびその地理的位置用の永久識別子を含む、位置の目立った情報を取り込むＵＬＲＯオブジェクトを生成することである。
【００２２】
本発明のさらに他の目的は、ＵＬＲＯを生成して、空間的に定めることのできるデータベースのアイテム、あるいは、そのようなアイテムに関連するデータを地図データベースとリンクできるようにし、それにより、動的にリンクされるコンテンツがさらに豊富にあるシームレスの電子データベースへの利用者アクセスを仮想データベース（Virtual Database）（ＶＤＢ）が提供できるようにすることである。
【００２３】
本発明のさらに他の目的は、ＵＬＲＯを生成して、空間的に定義できるデータベースのアイテム、あるいは、そのようなアイテムに関連するデータを地図データベースとリンクできるようにし、それにより、編集され、かつパッケージされるか、あるいは、組込み型ナビゲーション・システムなどのオフライン製品に用いる媒体（例えば、ＣＤまたはＤＶＤ）上に格納されることになっている所望のすべてのコンテンツを、利用者が選択できるようにすることである。
【００２４】
本発明のさらに他の目的は、フォーマットの異なるものでも、膨大な量の分散データの初期登録またはリンクを容易ならしめ、また、正方向（forward）ポインタと逆方向（reverse）ポインタの両ポインタとリンクされると、利用者の要求を満たすのに適した情報でカスタマイズされたインテリジェントマップの高速で、かつ効率的な作成を容易ならしめるＵＬＲＯ構造体を構築することである。
【００２５】
本発明のさらに他の目的は、これらの多くの関係を格納するのに必要な記憶空間を最小限に抑えて、同一位置の地理アイテムを一まとめにし、このような記憶空間要件を、一般にＮ！（Ｎ階乗、ここで、Ｎは、関連情報を含む分散されたリンクの数である）に比例したサイズから、Ｎに比例した係数に変え、また、同様に、探索速度も向上させて、その探索速度を、Ｎ２（Ｎの二乗）に比例したものから、定数値Ｃに比例したものに変えることである。
【００２６】
本発明のさらに他の目的は、地図およびサードパーティ・データベースを別々に維持できるようにし、それにより、これらの大きなデータベースのコンテンツを最新にしておく際に必要な作業を減らすことである。
【００２７】
本発明のさらに他の目的は速度と効率を上げ、これにより独立のまたはサードパーティの情報源から情報を取得可能にし、また、動的に編集可能にして、新たな情報が利用可能になるにつれて容易に更新、探索できるようにすることである。
【００２８】
本発明のさらに他の目的は、ＵＬＲＯの階層的構築を可能にし、また、ＵＬＲＯを一様なやり方で互いに関係づける手段を提供することである。
【発明が解決しようとする課題】
【００２９】
ここに述べられるように、ＵＬＲＯの一実施形態は、選択位置を識別することを目的とする永久識別コード（permanent identification code）を含む。さらに、位置は、１つまたは複数の地理アイテムに関連づけられることがある。ＵＬＲＯを使用すれば、広範囲のデータベース・フォーマットに対して、参照ファイル（file-of-reference）とサードパーティ・ファイル（third-party-files）との間に横断可能なリンクまたは連結（connections）を確立することができる。参照ファイルは、ファイル所有者の地理データの永久記憶に使用される地理空間ファイルである。サードパーティ・ファイルは、サードパーティの地理データの永久記憶に使用される地理空間ファイルである。参照ファイルまたはサードパーティ・ファイルは、そのフォーマットがたまたまどんなものであれ、一般に、いくつかの用途に対してもっと適切であるかもしれない他のフォーマットに変換できる。本発明の様々な実施形態により、この技法は、参照地図と、サードパーティ地図およびサードパーティ空間データファイルの１つまたは複数との間に、横断可能なリンクを確立するために使用されることもある。
【００３０】
さらにここに述べられるように、一実施形態により、ＵＬＲＯは、２つ以上の異なるファイル内にあって、かつ共通の位置に関連づけられた地理アイテムをさす。いつもではないが、しばしば、これらのファイルの１つが参照データベースとなる。それにより、これら２つのファイルの間には横断可能なリンクが効果的に生み出される。ＵＬＲＯは、一組（Ｎ個）の文書のそれぞれの間に横断可能なリンクを生み出すのに必要な連結の数を大幅に減らす。伝統的な手法を用いると、Ｎ！（Ｎ階乗）程度のポインタの総数に対して、それぞれの文書は、別のそれぞれの文書をさす必要があり、逆にそれぞれの文書は、別のそれぞれの文書にさされることになる。本発明は、必要なポインタの総数を２×Ｎ程度の数まで減らすスター構成を可能にする。多数の文書では、すなわちＮの値が大きい場合に、これは、連結の数を数桁分少なくする。さらに、（ａ）これらの連結の総数がずっと少なくなり、また、（ｂ）ＵＬＲＯの技法が、これらのファイルへの直接のポインタ・アクセス（pointered access）の方を選んで、多数のファイルにわたって複数の発見（multi-discovery）を行う必要をなくすから、その結果、関連地図データを取り込む能力は、伝統的な手法を用いる場合よりもＵＬＲＯを用いる方がさらに速くなる。
【００３１】
さらにここに述べられるように、一実施形態により、ＵＬＲＯは、位置に関連づけられた選択地理アイテムに対応する。一実施形態により、ＵＬＲＯは、特定の実施に応じて一部または全部を利用できる以下の８つの主要コンポーネント、すなわち、１）名称情報セット、２）座標上位セット（座標スーパーセット、super-set of coordinates）、３）その位置に一意的に対応するユニバーサル位置参照コード（ＵＬＲＣ）、４）参照ファイル・ポインタを含む参照ファイル・ポインタ・フィールド、５）１つまたは複数のサードパーティ・ファイル・ポインタを含むサードパーティ・ファイル・ポインタ・フィールド、６）参照ファイル・バックポインタを含む参照ファイル・バックポインタ・フィールド、７）１つまたは複数のサードパーティ・ファイル・バックポインタを含むサードパーティ・ファイル・バックポインタ・フィールド、８）メタデータ・フィールド（metadata field）を含む。
【００３２】
一実施形態により、参照ファイル・ポインタ・フィールドとサードパーティ・ファイル・ポインタ・フィールドはそれぞれ、ＵＬＲＯに入っている。バックポインタ・フィールドは両方とも、それぞれのファイルに入っている。参照ファイル、サードパーティ・ファイル、ＵＬＲＯは、互いに遠く離れて位置づけられることもある。第８のコンポーネントは、ＵＬＲＯに関連するメタデータを含むメタデータ・フィールドである。一実施形態により、ＵＬＲＯ中の唯一の必須フィールドがＵＬＲＣである。この名称情報セットと、この座標セットが、両方とも空白でないことも必須であるが、ただし、特定のＵＬＲＯに対しては、どちらか一方が空白であることもある。
【００３３】
レストラン情報と文字記入項目（text entries）が入っている地図の上記例を用いて、ＵＬＲＯ手法を利用すると、この情報が、地図の形式で、あるいは別の形式で含まれているかどうかに関係なく、追加の属性を統合して、利用者に提示することができる。例えば、このレストラン情報が、レストラン名の文字一覧表である場合には、これを鉄道地図および市街地図と組み合わせれば、このレストラン情報が地図フォーマットであった場合と同じくらい容易に、かつ効果的に仮想マップを作成することができる。ＵＬＲＯの使用によって、エンドユーザー向けアプリケーションの操作者が、仮想地図から空間関連のデータを得ることがさらに容易となる。仮想地図は、本発明を利用して、参照ファイル内の情報を、様々なサードパーティ情報源の１つまたは複数に含まれる情報と有効に、かつアクセス可能に組み合わせることができる。例えば、このＵＬＲＯ技法はまた、動的なランタイム方式で仮想地図を作成するために、Ｇｉｌ  Ｆｕｃｈｓ氏、Ｅｔｔｉｅ  Ｅｔｔｉｎｇｅｒ氏、Ａｌｌｅｎ  Ｂｒｏｗｎ氏、Ｅｒｉｃ  Ｃｒｏｗｅ氏らの発明者による同時係属出願「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＶＩＲＴＵＡＬ  ＤＡＴＡＢＡＳＥ  ＳＴＯＲＡＧＥ  ＡＮＤ  ＰＲＯＶＩＤＩＮＧ  ＯＦ  ＤＩＧＩＴＡＬ  ＭＡＰ  ＩＮＦＯＲＭＡＴＩＯＮ（デジタル地図情報を仮想データベースに蓄積して、提供するシステムおよび方法）」（Ａｔｔｏｒｎｅｙ  Ｄｏｃｋｅｔ  Ｎｏ．ＴＥＬＡ−０７７４８ＵＳ０）にさらに詳しく記載されている仮想地図データベース技法とともに、使用されることがある。この同時係属出願は、２００６年５月５日に出願された特許出願第６０／７９７，１３０号であり、参照によって本明細書に組み入れられている。このようなシステムでは、利用者は、例えば、「Ｇｅａｒｙ  Ｔｈｅａｔｅｒ付近のイタリア料理店を教えてください。また、料理店ごとに、駐車が認められる駐車場を教えてください。」といった質問に答えることができる。
【００３４】
本発明の上記および他の目的、利点、恩恵は、添付の詳細な説明および図面から明らかになろう。
【発明を実施するための最良の形態】
【００３５】
一般的に述べると、本発明は、電子文書、電子データベース、電子地図（これらは、ここでは、一まとめにして「電子空間データファイル（ｅｌｅｃｔｒｏｎｉｃ  ｓｐａｔｉａｌ  ｄａｔａ  ｆｉｌｅｓ）」と呼ぶ）と共同して用いられるユニバーサル位置参照オブジェクト（ＵＬＲＯ）を生成する方法およびシステムを提示する。或る種類の電子空間データファイルに関してここで述べられる事実上すべてのものを、適用性が失われることなく、別の種類の電子空間データファイルに適用することもできる。ただ１つの論理空間データファイルが区分されることがある。したがって、或る論理電子空間データファイルは、地理的定義を持つか、あるいは持たない１つまたは複数の物理ファイルを含むことがある。
【００３６】
本明細書の全体にわたって、以下の用語が使用される。
・「フィーチャー（Ｆｅａｔｕｒｅ）」。地理的フィーチャー（ここでは、単に「フィーチャー」と呼ぶ）は、実世界から実際のオブジェクトを理想化して地図で表したものであり、これは、その地図表現に役立つものである。フィーチャーは、ディメンション（次元）（dimension）を持っており、いつもではないが、たいてい地理的表現を持っている。フィーチャーは、実世界において実際は目に見えないかもしれない（例えば、国境または交差点）が、それでも、地図モデルには表現できる。フィーチャーは、タイプとクラスを持っており、それらをいっしょにすると、このシステムは、フィーチャーを互いに区別することができ、同時に、よく似ているフィーチャー間の類似点も保つことができる。
・「フィーチャーのディメンション（Ｄｉｍｅｎｓｉｏｎ  ｏｆ  Ｆｅａｔｕｒｅ）」。フィーチャーは、それらの完全な「実世界」の複雑さで表現されるよりも単純なやり方で地図モデルに表現されることが多い。しばしば、このような実世界の複雑さは、まさに実世界の少数の目立った面を取り込んで、或る特定の機能を果たそうとしているモデルの強みというよりもむしろ混乱のもとである。したがって、フィーチャーのディメンションは、実世界の真実を反映しないで、その表現が表しているものを反映する。
フィーチャーが分けられる５つのディメンションには、点フィーチャー、線フィーチャー、面（area）フィーチャー、立体（volume）フィーチャー、複合（complex）フィーチャーがある。点として表される実世界のフィーチャーは、点フィーチャーとして知られている。例えば、レストラン（それが、実世界において複合形状を持つ立体オブジェクトであっても）は、地図モデルに表されるときには、便宜的に点フィーチャーとして表される。例えば、２つ以上の道路要素が互いに交差する合流点がそうである。線フィーチャーは、直線または単純曲線状のセグメントとして表される（したがって、点フィーチャー間あるいは中間形状点間に延びている広がりを持っている）。線フィーチャーのいくつかの例として、道路、国境、川がある。もちろん、これらの実世界のオブジェクトは、かみそりの刃のように薄くはないが、ただし、地図モデルでは、これらのオブジェクトは、その実際の幅を無視する理想化された中心線として表される。面フィーチャーの例として、湖、公園、行政区域がある。建物などの立体フィーチャー（ほとんどの地図モデルにはない）は、この実世界に似るやり方で（ただし、さらに大まかに行われることがたびたびあるが）、連結した面フィーチャーの構築物として表される。最後に、複合フィーチャーは、「原子的に（ａｔｏｍｉｃａｌｌｙ）」定義されないフィーチャーである（この語は、以下でさらに詳しく述べられる）。
・「フィーチャーのタイプとフィーチャーのクラス（Ｔｙｐｅ  ｏｆ  Ｆｅａｔｕｒｅ  ａｎｄ  Ｃｌａｓｓ  ｏｆ  Ｆｅａｔｕｒｅ）」。タイプとクラスは、それらを区別できるようにするフィーチャーの下位区分である。フィーチャーのタイプのほんのわずかな例として、道路、川、鉄道線路、市、郡、山頂、バス停、交差点、橋、レストラン、ホテル、休憩所がある。ほとんどの商用地図モデルでは、何千もの異なるフィーチャー・タイプがあることもある。ＩＳＯ−ＧＤＦ（地理データファイル（Geographic Data File））マップ・フォーマットは、周知のフィーチャー・タイプのコーパス（集成）（corpus）をとりわけ列挙しようとする１つの標準フォーマットである。このＧＤＦフォーマットの全詳細は、参照によって本明細書に組み入れられているＩＳＯ仕様「ＩＳＯ１４８２５：Ｉｎｔｅｌｌｉｇｅｎｔ  Ｔｒａｎｓｐｏｒｔ  Ｓｙｓｔｅｍｓ  −  Ｇｅｏｇｒａｐｈｉｃ  Ｄａｔａ  Ｆｉｌｅｓ（ＧＤＦ）  Ｏｖｅｒａｌｌ  Ｄａｔａ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（インテリジェント・トランスポート・システム、地理データファイル（ＧＤＦ）総合データ仕様）」に記載されている。
フィーチャーの特定タイプ内では、変形もあることがある。例えば、世界には、異なるクラスの道路がある。例えば、ハイウェイ、主道路、従道路、地方道、住宅道路、高速道路出入り道路、無舗装道路、ゴート・トレイルがある。これらの道路は、このフィーチャー・タイプの「道路」のすべてであるが、これらは、様々な分類の点で異なっている。それゆえ、フィーチャー・クラスは、このフィーチャー・タイプに属している。
・「フィーチャーのジオメトリ（Ｇｅｏｍｅｔｒｙ  ｏｆ  Ｆｅａｔｕｒｅ）」。コンピュータ地図モデルでは、フィーチャーは、そのフィーチャーの形状の幾何学的表現を持つことが多い。点フィーチャー（Point features）は、ただ１つのノード（node）で表されるものである。線フィーチャー（Line features）は、一連の形状点を通るかもしれない直線のセグメント（辺）で表されることが多い。面フィーチャー（Area features）は、それぞれがその境界線を描写する辺から成っている面の集まりで表されることがある。面フィーチャーは、切り離されるか、あるいは、中に穴を持つことさえある。立体フィーチャー（Volume features）は、空洞を含むかもしれない立体形状で表される。
・「トポロジー（Ｔｏｐｏｌｏｇｙ）」は、このフィーチャーのジオメトリ（形状）が何らかの変化を受けるかもしれないときでも、引き続き正しいフィーチャー間の連結関係を取り込む手段として使用される一組の数学的性質である。或るディメンションのジオメトリは、それよりも小さいディメンションのジオメトリに接している。立体は面に接している。面は直線のセグメントに接しており、また、直線のジオメトリは点に接している。逆に、点は直線のジオメトリと相互に接している。直線の境界は面と相互に接している。最後に、面は立体と相互に接している。トポロジーは、これらのフィーチャー自体の一面であるか、あるいは、フィーチャーの形状を取り込むジオメトリの一面であるかもしれない。
・「単純フィーチャー（Ｓｉｍｐｌｅ  Ｆｅａｔｕｒｅ）」。点フィーチャー、線フィーチャー、面フィーチャー、立体フィーチャーは、それらのフィーチャーに地理的形状を割り当てることで直接にモデル化されるから、それらのフィーチャーは単純フィーチャーである。
・「複合フィーチャー（Ｃｏｍｐｌｅｘ  Ｆｅａｔｕｒｅ）」。逆に言えば、複合フィーチャーは、直接の地理的表現によるだけでなく、他のフィーチャー（単純または複合）によっても、間接的に定められることがある。例えば、カリフォルニア州は、その境界線を形状点と照らし合わせること（これにより、カリフォルニア州が単純な面フィーチャーになるであろう）によらずに、その郡（それら自体、単純フィーチャーまたは複合フィーチャーであるかもしれない）の総体として表される。複合フィーチャーとして表現されるカリフォルニア州は、他のフィーチャーを参照することで、複合的に定められる単一フィーチャーである。複合フィーチャーの別の一般的な例として、２つの道路要素（それぞれの通行方向に１つ）から成る道路がある。２つの複合道路が交わるときに、複合フィーチャーは、すなわち複合交差点と公表される。しばしば、交差点は、これらの単純道路要素が互いに交差する４つの合流点と見なされることもある。
・「複数のフィーチャー（Ｐｌｕｒａｌｉｔｙ  ｏｆ  Ｆｅａｔｕｒｅｓ）」。単一フィーチャーの例として、上述の単純フィーチャーと複合フィーチャーの両方がある。しかしながら、同時にいくつかのフィーチャーについて考えること、よって、複数のフィーチャーを生み出すことがときには有用である。例えば、サンフランシスコにあるレンストランのすべての集まり、あるいは、カリフォルニアにある郡のすべての集まりは、複数のフィーチャーの例として役立つ。この複数のフィーチャー（例えば、カリフォルニアにあるすべての郡）は、カリフォルニア州の単一の複合フィーチャーとは異なる概念である（ただし、この例では、複数の特徴は、実際に同一の幾何学的フットプリント（足跡）（footprint）を持っている）ことに留意する。
・「フィーチャーのサブセット（Ｓｕｂ−Ｓｅｔ  ｏｆ  Ｆｅａｔｕｒｅ）」。単一フィーチャーの一部（portion）、サブセット（sub-set）、または部分（part）を識別することがときには有用である。時折、このような部分は、独自のフィーチャーであることもあるが、ただし、他の時には、このような部分は、単なる断片（fragments）である。これらの断片はそれら自体、実際のフィーチャーとはならないであろう。フィーチャーのサブセットの例として、「カリフォルニア州」フィーチャーのただ１つの郡、２つの交差点間のブロックのほんの一部分にわたる道路要素のセグメント、あるいは、３０階建てビルの４階〜１７階がある。
・「属性（Ａｔｔｒｉｂｕｔｅ）」。フィーチャー、多数のフィーチャー、フィーチャーのサブセットは、属性を持つことがある。属性は、大量のカタログに与えられる。また、実世界の商用コンピュータ地図モデルにおいて、フィーチャーに適用される何千もの異なる属性があることがある。その属性タイプは、このカタログから異なる属性を取り込むものである。このような属性のほんのわずかな例として、車の制限速度、交通フロー（traffic flow）の長さ、方向及びレストランの開店時間がある。
・「関係（Ｒｅｌａｔｉｏｎｓｈｉｐ）」。関係は、意味のある何らかの相互連結に「関与する」（participating）２つ以上のフィーチャーから成っている。例えば、道路要素は、或る合流点にていくつかの道路要素に分かれるかもしれない。よって、これらのフィーチャーのすべては、互いに「分岐点」（fork）の関係にある（それぞれのフィーチャーは、異なる役割を果たす）。関係も、大量のカタログに与えられている。また、属性と同様に、実際の商用デジタル地図モデルでは、何百ものこのような関係が可能である。多くのものが、実世界の活動をモデル化することで作られるから、すべての関係が幾何学的であるとは限らない。例えば、特定の駐車場ガレージに対して駐車が認められるレストランは、２つのフィーチャー間に或る種のビジネス関係を表している。
・「地理アイテム（Ｇｅｏｇｒａｐｈｉｃ  ｉｔｅｍ）」。この説明のために、ここでは、ＩＳＯ規格以外の用語が使用される。地理アイテムは、ここでは、フィーチャー、複数のフィーチャー、フィーチャーのサブセット、属性のいずれかであると定義されている。
・「位置（Ｌｏｃａｔｉｏｎ）」。実世界においてフィーチャーがある位置は、このフィーチャー自体とは異なる。例えば、このフィーチャーはレストランであることもあるが、その位置は、或る緯度、経度（経緯度）座標対、または、同様な或る測地参照系（geodetic referencing system）からの座標として、あるいは、人間が読取り可能な住所（例えば、サンフランシスコの「３２２  Ｂａｔｔｅｒｙ  Ｓｔｒｅｅｔ」）として、指定できる。位置は、フィーチャーとも、また、それらの位置に関連づけられた他の地理アイテムとも混同してはならない。
・「フィーチャーの階層（Ｈｉｅｒａｒｃｈｙ  ｏｆ  ｆｅａｔｕｒｅｓ）」。フィーチャーは、構成階層を形成することが多い。例えば、国は、州で構成されるか、あるいは州から成っているが、州は、郡などで構成されることがある。同様に、車道は、多くのブロック面道路要素（block face road element）から成っている。「スタンフォード大学キャンパスエリア」を含む複合エリアの道路と公園と建物は、さらに大きいフィーチャーの諸部分である。このフィーチャーの階層は、フィーチャー間の関係の特定の場合であり、この階層を、明瞭に取り込んで、表すことができるか、あるいは、できない。
・「関心地点（Ｐｏｉｎｔ  ｏｆ  ｉｎｔｅｒｅｓｔ）」。関心地点（ＰＯＩ）は、点フィーチャーの特定タイプであり、特に、この関心地点は、レストラン、ホテル、博物館などのさらに具体的な他のタイプを含むことのあるタイプである。
【００３７】
ここで述べられるように、一実施形態により、ＵＬＲＯは、永久識別コードと、選択位置を一意的に識別することを目的とした充分な情報とを含む。さらに、位置が、１つまたは複数の地理アイテムに関連づけられることがある。ＵＬＲＯは、広範囲のデータベース・フォーマットに対して、参照ファイルと、１つまたは複数のサードパーティ・ファイルとの間に横断可能なリンクを確立するために使用されることもある。同様に、ＵＬＲＯは、２つ以上のサードパーティ・ファイル間に横断可能なリンクを確立するために使用される。
【００３８】
さらにここで述べられるように、一実施形態により、参照ファイルは、文書所有者の地理データの永久記憶に使用される地理空間データベースである。参照ファイルは、一般に、いくつかの用途にさらに適するかもしれない他のフォーマットに変換できる。一実施形態により、ＵＬＲＯをサポートするために特定される参照ファイル・データベースがただ１つある。サードパーティ・ファイルは、地理的フィーチャー、フィーチャーの属性、あるいは、２つ以上のフィーチャーの関係から成っているかもしれない空間データの或る要素を含む任意ファイルである。サードパーティ・ファイルは、この参照ファイルとは異なっている。
ＵＬＲＯは、特定の位置に一意的に対応する。文書は、位置に関連づけられた地理アイテムを含むために、地図である必要はない。情報が変わるときに、また、さらに正確な情報が得られるときに、ＵＬＲＯは、容易に更新できる。ＵＬＲＯは、２つ以上の異なるファイル内で、同一の位置に関連づけられている地理アイテムをさし、したがって、これら２つのファイル間に、横断可能なリンクまたは連結が効果的に生み出される。ＵＬＲＯは、地理情報を含む異なる文書間に横断可能なリンクを生み出すためには、必要とされない。しかしながら、ＵＬＲＯは実際に、一組（Ｎ個）の地理アイテムのそれぞれの間に横断可能なリンクを生み出すのに必要な連結の数を大幅に減らす。一般に、Ｎ個の地理アイテムは、Ｍ個の別々のファイル内に見出される。ここで、ＭはＮよりも小さいか、あるいはＮに等しい値である。伝統的な手法を用いると、それぞれの文書は、別のそれぞれの文書をさす必要があり、次に、ポインタの総数がＮ！（Ｎ階乗）くらいの場合に、それぞれの文書を、別のそれぞれの文書がさすことになる。本発明は、必要なポインタの総数を２×Ｎ程度の数まで減らすスター構成を可能にする。多数の文書では、すなわちＮの値が大きい場合に、これは、連結の数を数桁分少なくする。さらに、（ａ）連結の総数がずっと少なくなり、また、（ｂ）ＵＬＲＯの技法が、これらのファイルへの直接のポインタ・アクセスの方を選んで、多数のファイルにわたって複数の発見を行う必要をなくすから、その結果、関連地図データを取得できる能力は、伝統的な手法を用いる場合よりもＵＬＲＯを用いる方がさらに速くなる。
【００３９】
（模範的な実施と使用）
一実施形態と模範的な実施により、ＵＬＲＯは、空間データを含む電子ファイル内の地理アイテムに関連づけられた位置に対応する。ＵＬＲＯは、以下の８つの主要コンポーネントを含む。
１）名称情報セット（例えば、住所「３２  Ｅｌ  Ｃａｍｉｎｏ  Ｒｅａｌ」）。
２）ｋ個の座標セットを含む座標上位セット。ここで、ｋは、その位置での地理的地点の数である（例えば、住所「４  Ｅｍｂａｒｃａｄｅｒｏ  Ｃｅｎｔｅｒ、Ｓａｎ  Ｆｒａｎｃｉｓｃｏ」に対する地点位置は、この上位セットに含まれるかもしれない座標セットの一例、すなわち、経度−１２２．３９７３０度、緯度３７．７９５１９度、高度海抜３メートルである）。
３）その位置に一意的に対応するユニバーサル位置参照コード（ＵＬＲＣ）（例えば、６３５７３）。
４）ＵＬＲＯの外部にあるか、あるいはＵＬＲＯの内部にある「サイド・ファイル」に入っている参照ファイル・ポインタを含む参照ファイル・ポインタ・フィールド。
５）この位置に関連づけられたそれぞれの地理アイテムに対して、サードパーティ・ファイル・ポインタを含むポインタ・フィールド。
６）参照ファイル・バックポインタを含む参照ファイル・バックポインタ・フィールド。
７）１つまたは複数のサードパーティ・ファイル・バックポインタを含むサードパーティ・ファイル・バックポインタ・フィールド。
８）メタデータ・フィールド。メタデータ・フィールドは、ＵＬＲＯに関するメタデータを含む。
【００４０】
ＵＬＲＯ中の上述のフィールドのうち、唯一の必須フィールドはＵＬＲＣである。一実施形態により、この名称情報セットと、この座標セットが、両方とも空白でないことも必須であるが、ただし、特定のＵＬＲＯに対しては、どちらか一方が空白であることもある。それぞれのフィールドに対する実際の要件は、その実際の実施に応じて、変わることもある。
【００４１】
一実施形態により、上記のコンポーネントのうちの最初の２つ、すなわち、この名称情報セットと、この座標上位セット（例えば、経度、緯度、高度、あるいは、主要高速道路または携帯電話塔とともに使用されるものなどの直線参照系（linear referencing system））は、２つの異なる参照空間内の座標と見なされることがある。この地理座標参照空間は、それが地上のあらゆる地点を一意的に、かつ間違えのないように指定するという意味で、数学に基礎を置き、正確で、かつすべてを尽くす。これと対照的に、その名称参照空間は、言葉と歴史に基礎を置き、不正確で、かつ不完全である。名称は、軽薄であるか、あるいは混乱させかねないやり方で、異なるオブジェクト間で、複数回、繰り返されることが多い。例えば、Ｐａｒｉｓは、テキサス州内の都市やメイン州内の都市に加えて、フランスの首都でもある。「Ｅｉｆｆｅｌ  Ｔｏｗｅｒ（エッフェル塔）」のような名称でさえ、ラスベガスにある人気のあるホテルの正面のイミテーションをさすだけでなく、フランスのもっとも愛されている名所の１つもさすこともある。これと対照的に、或る名称に、経度−１２２．３９７３０度、緯度３７．７９５１９度、高度海抜３メートルなどの座標が与えられるときには、混乱は生じない。
【００４２】
一実施形態により、この名称情報セットはさらに、１）住所（例えば、１ａ）郵便番号、１ｂ）ストリート・ナンバー、１ｃ）ストリート名、１ｄ）一連の名称を持つ階層的地区住所系（hierarchical area address system）、１ｅ）他の住所情報）、２）指定場所（named place）、３）地理的名称情報、４）電話番号などの他のタイプの名称情報、５）他の任意の名称メタ情報のうち、１つまたは複数を含む。さらに地理的名称情報が、５ａ）点フィーチャーに対する名称情報、５ｂ）線フィーチャーに対する名称情報、５ｃ）面フィーチャーに対する名称情報、５ｄ）立体フィーチャーに対する名称情報、５ｅ）線フィーチャーのセグメントに対する名称情報、５ｆ）面フィーチャーのセクターに対する名称情報、５ｇ）立体フィーチャーのセクションに対する名称情報、５ｈ）複数の関連地理アイテムに対する名称情報のうち、１つまたは複数を含む。
【００４３】
一実施形態により、上記の階層的地区住所系は、これらの地理情報タイプの少なくとも２つの間の関係についての情報を含む。例えば、面フィーチャーであるカリフォルニア大学の場合における名称情報は、カリフォルニア大学がＢｅｒｋｅｌｅｙにあり、さらにＢｅｒｋｅｌｅｙがＡｌａｍｅｄａ  Ｃｏｕｎｔｙにあり、さらに、Ａｌａｍｅｄａ  Ｃｏｕｎｔｙがカリフォルニア州にあり、さらにカリフォルニア州がアメリカ合衆国にあるという事実を含むかもしれない。比較すると、「Ｅｌ  Ｃａｍｉｎｏ  Ｒｅａｌ」は、ストリート全体に対する名称であって、これは、線フィーチャーを形成する。線フィーチャーは、一連の点によって表される。住所「３２  Ｅｌ  Ｃａｍｉｎｏ  Ｒｅａｌ」は、線フィーチャー沿いの特定位置の地点住所（point address）である。様々な異なる市（および／または郡）には、住所「３２  Ｅｌ  Ｃａｍｉｎｏ  Ｒｅａｌ」が存在し得ることが明らかである。これらの存在はそれぞれ、線フィーチャー沿いの特定位置にあるか、あるいは点フィーチャーにある地点住所である。この地点住所を一意的に指定するために、適切な市、郡、州のコンテキストを追加することがしばしば必要である。
【００４４】
一実施形態により、この座標の上位セットは、いくつか（ｋ個）の座標セットを含む。ここで、ｋは、この位置に含まれる地理的地点の数である。それぞれの座標上位セットは、地理座標セットの１つまたは複数を含む。それぞれの座標上位セットはさらに、定義済み座標参照系などの座標分類の１つまたは複数も含むことがある。このような地理座標セットの１つは、緯度と経度の座標参照系を含み、さらに、高度も含む場合がある。他の座標セットは、ユニバーサル横メルカトル図法（ＵＴＭ）などの他の地理座標参照系、あるいは、主要高速道路または携帯電話塔とともに使用されるものなどの直線参照系を含むことがある。
【００４５】
一実施形態により、ＵＬＲＯの第３のコンポーネントはＵＬＲＣである。ＵＬＲＣは、その位置に一意的に対応するように割り当てられる。ＵＬＲＣを引っ込めると、ＵＬＲＣを再使用できない。一実施形態では、ＵＬＲＯは、この割当てＵＬＲＣが以前に別の位置に割り当てられなかったことを保証できるカウンタを含む。他の実施形態により、ＵＬＲＯが生成されると、ＵＬＲＯは、ＵＬＲＣに応じてそれぞれにインデックス（指標）が付けられているＵＬＲＯの中央リポジトリに格納されることがある。これは、ＵＬＲＣが再使用されないことを保証するカウンタに代わる別法を提供する。すでに生成されたＵＬＲＣを必要とするときには、上記リポジトリは、これを認めて、適切なＵＬＲＣを提供し、したがって、重複し、無駄になり、混乱させるであろう新たなものを生成しないようにしている。
【００４６】
ＵＬＲＣも、このＵＬＲＯの一部として組み入れられるときに、このＵＬＲＯの名称情報セットと、この座標上位セット（それぞれ、コンポーネント１とコンポーネント２）がなぜ両方とも必要であるのか、読み手にはすぐには明らかでないかもしれない。しかしながら、異なる情報源からの情報のスムーズで、誤りのない統合を保証するために、このような明らかな重複（冗長）が望ましい。例示として、データソースＢからの新規アイテム３８２３を、既存のＵＬＲＯに関連づけられるか、あるいは別法として、新規アイテム３８２３が、新規ＵＬＲＯの生成を必要とするかどうかについて、判定が必要とされることがある。名称情報と座標情報は、適正なＵＬＲＯがあれば、そのＵＬＲＯを発見する手段として役立つ。次に、適正なＵＬＲＯが発見されると、この地理アイテムは、そのＵＬＲＣをさし、また、将来の検索は、名称および座標の比較をもう必要としない。このようなＵＬＲＯを見出せない場合には、新規ＵＬＲＯを生成し、そのＵＬＲＯに、地理アイテムを関連づける。そうしなければ、例えば、カナダのオンタリオ州を、南カリフォルニアにあるオンタリオ市と混同するか、あるいは、「３２  Ｅｌ  Ｃａｍｉｎｏ  Ｒｅａｌ，Ｍｅｎｌｏ  Ｐａｒｋ」を、「３２  Ｅｌ  Ｃａｍｉｎｏ  Ｒｅａｌ，Ｐａｌｏ  Ａｌｔｏ」と混同する可能性があるかもしれない。
【００４７】
位置は、その位置があるストリートと同一の名称を持っていることが普通である。また、同一名のストリートは、特定の都市内のいくつかの異なる場所にある複数のセクション（区画）を含むことが極めて普通である。アメリカのいくつかの州でさえ、同一名の自治都市が２つ以上あり、そのことから、名称情報や座標の情報のような追加情報がない場合に、混乱が起こりそうである。したがって、特定の位置を適切に表すために、３つすべてが必要であり、すなわち、最初の２つは、その位置を表すのに必要となり、また、３つ目のものは、横断可能性と簡潔さ（compactness）を効果的に容易ならしめるのに必要となる。
【００４８】
実際問題として、ほとんどのファイルは、これら３つの情報区分のうちの少なくとも２つに属する或るデータ形式を含むことになる。たいていの場合、アイテム間の適正なリンクを形成するのに、これら２つの情報区分で充分であろうが、ただし、３つの情報区分がすべてあれば、このようなリンクを問題なく形成できることは明らかである。ＵＬＲＯが生成されると、サードパーティ・データにおいて、すべての関連地理アイテムをリンクできる。このＵＬＲＯのすべてのフィールドを使用して、どの地理アイテムが、どのＵＬＲＯに伴うべきか（すなわち、どのオブジェクトが、同一位置の異なる現れであるか）について適正な決定を下すことができるのは、このときである。
【００４９】
例えば、「Ｅｌ  Ｃａｍｉｎｏ  Ｒｅａｌ」の場合に、そのストリートを表す参照ファイル内のオブジェクトは、サードパーティで作成された地図中の外見上対応するオブジェクトと、前もって同一視されるかもしれない。これら２つの地図は、そのストリートに関するいくつかの細部について一致しないかもしれないが、ただし、これら２つのオブジェクトが同等であることが立証される場合には、名称情報と座標は、これら２つのオブジェクト、および、これら２つの地図のリンクにとって、さほど重要とはならなくなる。
【００５０】
さらに、ＵＬＲＣは、その位置に一意的に対応し、他のどんな位置とも重複しない。ＵＬＲＣが割り当てられると、ＵＬＲＣは、ＵＬＲＣが割り当てられている位置に関してのみ使用できる。このＵＬＲＣは、普通なら、同一の位置に対して、変わりはない。特定の位置が、つねに、同一ＵＬＲＣにより表されるという事実から、異なるマッピング・アルゴリズムに従って、かつ／または、異なるマッピング技術に従って作成されたかもしれない異なる地図を調和（一致）させることが容易となる。このＵＬＲＣを用いれば、複数の電子地図などの異なる電子ファイル、あるいは、１つの電子地図を、一連のサードパーティ空間データ・コンテンツ・ファイル（third party spatial data content file）とマッチングおよび／または結合することができる。
【００５１】
一実施形態により、このＵＬＲＯの第４のコンポーネントは、その参照ファイル・ポインタ・フィールドである。この参照ファイル・ポインタ・フィールドは、この参照ファイル内の位置に関連づけられた地理アイテムを一意的に指定する参照ファイル・ポインタを含む。それぞれの参照ファイル・ポインタはさらに、この参照ファイル・ポイントの生成時間、この参照ファイル・ポインタのタイプとクラス、および、他の参照ファイル情報のうち、１つまたは複数を含むことがある。
【００５２】
一実施形態により、このＵＬＲＯの第５のコンポーネントは、そのサードパーティ・ファイル・ポインタ・フィールドである。このサードパーティ・ファイル・ポインタ・フィールドは、１つまたは複数のサードパーティ・ファイル・ポインタを含み、これらのサードパーティ・ファイル・ポインタはそれぞれ、上記１つまたは複数のサードパーティ・ファイルの１つに入っている上記位置を参照する１つまたは複数の地理アイテムを一意的に指定する。特定の位置に関するサードパーティ・ポインタの数（ｎ）は、その位置を含むサードパーティ・ファイルの数に関して合計された個々の地理アイテムの数に等しい。多くのサードパーティ・データベースがあることもあるが、ただし、参照ファイルはただ１つである。
【００５３】
このサードパーティ・ファイル・ポインタ・フィールドはさらに、このサードパーティ・ファイル・ポインタの生成時間、このサードパーティ・ファイル・ポインタのタイプとクラス、および、他のサードパーティ・ファイル・ポインタ情報のうち、１つまたは複数を含むことがある。このサードパーティ・ファイル・ポインタ・フィールドは、このＵＬＲＯに含まれるか、あるいは、このＵＬＲＯの外部のサイド・ファイルに含まれることがある。
【００５４】
一実施形態により、このＵＬＲＯの第６のコンポーネントは、その参照ファイル・バックポインタ・フィールドである。この参照ファイル・バックポインタ・フィールドは、上記参照ファイルから後方に、このＵＬＲＣをさす参照ファイル・バックポインタを含む。それぞれの参照ファイル・バックポインタはさらに、この参照ファイル・バックポインタの生成時間、この参照ファイル・バックポインタのタイプとクラス、および、他の参照ファイル・バックポインタ情報のうち、１つまたは複数を含むことがある。
【００５５】
一実施形態により、このＵＬＲＯの第７のコンポーネントは、そのサードパーティ・ファイル・バックポインタ・フィールドである。このサードパーティ・ファイル・バックポインタ・フィールドは、１つまたは複数のサードパーティ・ファイル・バックポインタを含み、しかも、それぞれの上記サードパーティ・ファイル・バックポインタは、上記サードパーティ・ファイルの１つから後方に、上記ＵＬＲＯ、すなわちこのＵＬＲＣを一意的にさす。特定の位置に関するサードパーティ・ポインタの数（ｎ）は、その位置を含むサードパーティ・ファイルの数に関して合計された個々の地理アイテムの数に等しい。それぞれのサードパーティ・ファイル・バックポインタは、このサードパーティ・ファイル・バックポインタの生成時間、このサードパーティ・ファイル・バックポインタのタイプとクラス、および、他のサードパーティ・ファイル・バックポインタ情報のうち、１つまたは複数を含むことがある。
【００５６】
一実施形態により、このＵＬＲＯの第８のコンポーネントは、そのメタデータ・フィールドである。このメタデータ・フィールドは、ＵＬＲＯ分類、そのＵＬＲＯの生成時間、そのＵＬＲＯのタイプとクラス、および、他のメタデータ情報のうち、１つまたは複数を含むことがある。
【００５７】
この参照ファイル・ポインタ・フィールドと、このサードパーティ・ファイル・ポインタ・フィールドはそれぞれ、このＵＬＲＯに入っているか、あるいは、このＵＬＲＯの外部のサイド・ファイルに入っていることがある。このＵＬＲＯが参照ファイル・ポインタ・フィールドを内部に含んでいない任意の実施形態では、この参照ファイル・ポインタ・フィールドを含むサイド・ファイルが定められている。同様に、このＵＬＲＯがサードパーティ・ファイル・ポインタ・フィールドを内部に含んでいない任意の実施形態では、このサードパーティ・ファイル・ポインタ・フィールドを含むサイド・ファイルが定められている。このＵＬＲＯが参照ファイル・ポインタ・フィールドとサードパーティ・ファイル・ポインタ・フィールドを両方とも内部に含んでいる実施形態は、一般に、サイド・ファイルの使用を必要としないであろう。その一方、このＵＬＲＯが、参照ファイル・ポインタ・フィールドとサードパーティ・ファイル・ポインタ・フィールドを両方とも内部に含むことのない場合には、その必要とされるポインタ・フィールド（１つまたは複数）を含むサイド・ファイルが必要となる。新規サードパーティが追加されるときには、このＵＲＬＯにわずかな修正が必要となり（ただし、このサードパーティ・ポインタがサイド・ファイルに格納されてない場合に限る）、すなわち、このＵＬＲＯにサードパーティ・ポインタ・フィールドが追加される（このサードパーティ・ポインタがサイド・ファイル内にあるときには、そのサイド・ファイル内で上記修正がなされ、しかも、ＵＬＲＯ自体への修正はまったく必要でない）。
【００５８】
（仮想データベースおよび仮想地図へのＵＬＲＯの適用）
上述の通り、ＵＬＲＯは、位置に関して使用されることを目的としている。ＵＬＲＯは、ＵＬＲＣから成っている。このＵＬＲＣは、位置に関連づけられた地理アイテムを参照することを特に目的とする永久識別コードを含む。このＵＬＲＯは、その対応する位置に関する情報をコード化し、それにより、多分多くのファイルに分散されている位置に関連づけられた関連地理アイテムを一まとめにすることが容易となる。したがって、ＵＬＲＯ（さらに具体的に言えば、ＵＬＲＣ）は、１つまたは複数の異なる地図中のフィーチャーが同等であるか、あるいは同一であることを認識できるようにする。ＵＬＲＯにより、１つまたは複数の地図を動的に組み合わせて、それぞれの地理アイテムの根源である地図（１つまたは複数）に関係なく、異なる地理アイテム間を横断可能に連結して１つの仮想地図を形成することが容易となる。例えば、サンフランシスコの地図が考察される場合には、本発明の実施形態により、サンフランシスコの市街地図、サンフランシスコの道路地図、および、サンフランシスコのレストランと駐車施設のデータファイルから得られた要素間を横断可能に連結して、仮想地図を作成することができる。次に、ストリート、レストラン、駐車施設、鉄道の相互作用（インタラクション）を取り込んで、操作者に提供することもある。Ｇｉｌ  Ｆｕｃｈｓ氏、Ｅｔｔｉｅ  Ｅｔｔｉｎｇｅｒ氏、Ａｌｌｅｎ  Ｂｒｏｗｎ氏、Ｅｒｉｃ  Ｃｒｏｗｅ氏らの発明者による同時係属出願「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＶＩＲＴＵＡＬ  ＤＡＴＡＢＡＳＥ  ＳＴＯＲＡＧＥ  ＡＮＤ  ＰＲＯＶＩＤＩＮＧ  ＯＦ  ＤＩＧＩＴＡＬ  ＭＡＰ  ＩＮＦＯＲＭＡＴＩＯＮ（デジタル地図情報を仮想データベースに蓄積して、提供するシステムおよび方法）」（Ａｔｔｏｒｎｅｙ  Ｄｏｃｋｅｔ  Ｎｏ．ＴＥＬＡ−０７７４８ＵＳ０）（この同時係属出願は、２００６年５月２日に出願された特許出願第６０／７９７，１３０号であり、参照によって本明細書に組み入れられている）に記載されている仮想データベース技術を利用して、ストリート、レストラン、駐車施設、鉄道の間の関係が、操作者により指定されて、この仮想地図からの出力として表示される。例えば、操作者は、特定のレストランがあるストリートと、そのレストランから、どの駐車施設が駐車許可を得られるのか、あるいは、近くの鉄道駅に到着する列車に対して、列車時刻表がどうであるのか知りたいと思うことがある。これは、その伝統的な階層化された眺め（layered view）よりも効果的である。伝統的な技法を用いる場合、位置の座標（充分正確であるか、あるいはそうでないかもしれない）を逆ジオコーディングの処理といっしょに使用すれば、他のどのストリートが「近い」か発見できるであろう。ただし、その処理は、時間がかかりすぎるとともに、不正確でもある。さらに、伝統的な技法では、すべてのデータを統合して、ただ１つの電子地図ファイルを形成することは別として、異種の地理アイテム間の関係を維持できるようにする機構はまったく存在しない。本発明の一実施形態により、直接のポインティング、および明白な関係は、速くて、しかも確実に正確な結果が得られるようにする。
【００５９】
さらに、この情報が地図の形式で、または別の形式で含まれているかどうかに関係なく、追加の属性も混ぜ込まれる（folded-in）こともある。例えば、レストラン情報が、レストラン名の文字一覧表である場合には、そのレストラン情報を、鉄道地図および市街地図と組み合わせて、そのレストラン情報が地図フォーマットであった場合と同じくらい容易で、かつ効果的に仮想地図を作成する。もちろん、レストランの名称は、空間データ、住所、または座標とともに増やされなければならず、したがって、そのレストランの名称が、適切なＵＬＲＯとリンクされることもある。地図フォーマット、文字（テキスト）フォーマット、または他のフォーマットでデータから統合されるかもしれないさらなる情報は、例えば、特定のストリート上または特定の地区でのそれぞれの家の築年齢、レストランの所有者一覧表、それぞれのレストランが出す食品の種類一覧表、列車時刻表、鉄道線路の年代に関するデータ、あるいは、その地区の高速輸送システムの入口の位置を含むかもしれない。仮想地図が作成されると、その仮想地図は、地図アイテム間に横断可能なリンクを持つただ１つの地図とは、使用中見分けがつかない。ＵＬＲＯの使用によって、エンドユーザー向けアプリケーションの操作者が、仮想地図から空間関連のデータを得ることがさらに容易である。仮想地図は、本発明の実施形態を利用して、参照ファイル内の情報を、様々なサードパーティ情報源の１つまたは複数に含まれる情報と有効に、かつアクセス可能に組み合わせることができる。
【００６０】
ＵＬＲＯの模範的な実施
上述の通り、一実施形態により、ＵＬＲＯ中のいくつかのフィールドを空白にしておくこともあるが、唯一の必須フィールドは、そのＵＬＲＣである。この名称情報セットと、この座標セットが両方とも同時に空白とならないことも必須であるが、ただし、特定のＵＬＲＯに対しては、どちらか一方が空白であることもある。
【００６１】
図１は、本発明の一実施形態により、永久ＩＤコードを含むＵＬＲＯを、電子参照ファイル内の位置に関連づけられた地理アイテムに割り当てる処理を描いた説明図である。図１に示されるように、ＵＬＲＯは、電子参照ファイル１３０内の位置１２０、位置１２２、位置１２４、位置１２６に関連づけられた地理アイテムに割り当てられる。上に与えられた定義に添うように、これらの地理アイテムは、フィーチャー、複数のフィーチャー、フィーチャーのサブセット、または、物理的位置に関連する属性のいずれであってもよく、したがって、図１では、地理アイテム１２０、地理アイテム１２２、地理アイテム１２４、地理アイテム１２６は、実際は、ただ１つの物理的位置に関連づけられることがある。ＵＬＲＯ１１０、ＵＬＲＯ１１２、ＵＬＲＯ１１４、ＵＬＲＯ１１６はそれぞれ、ＵＬＲＣ１３４、ＵＬＲＣ１３６、ＵＬＲＣ１３８、ＵＬＲＣ１４０を含む。さらに、一実施形態により、それぞれのＵＬＲＣは、永久識別子、すなわち永久ＩＤを含む。それぞれのＵＬＲＯは、容易に、かつ正確に維持され、更新され、また、この参照ファイル内の位置に関連づけられた地理アイテムを、１つまたは複数のサードパーティ・ファイル（１５０、１５２、１５４）内の対応する位置情報（１５５、１５６、１５７、１５８、１５９）とリンクさせるために利用されることもある。図１に示されるように、位置、例えば位置１２０に関連づけられたただ１つの地理アイテムは、ただ１つのＵＬＲＯ１１０とリンクされることがあり、さらに、ＵＬＲＯ１１０が、ただ１つのサードパーティ・ファイル１５０とリンクされる。別法として、位置、例えば位置１２２に関連づけられたただ１つの地理アイテムは、ただ１つのＵＬＲＯ１１２とリンクされることがあり、さらに、ＵＬＲＯ１１２が、複数のサードパーティ・ファイル（１５０、１５２）とリンクされる。
【００６２】
ＵＬＲＯ階層とＵＬＲＯグループ（両方とも、以下でさらに詳しく説明される）を利用すれば、他の種類のリンクが可能になり、したがって、参照ファイルとサードパーティ・ファイルのほぼどんな組合せも可能になる。さらに、リンク１６０、リンク１６２、リンク１６４、リンク１６６、リンク１７０、リンク１７２、リンク１７４、リンク１７６、リンク１８０は、一方向ポインタか、双方向ポインタか、あるいは、一方向ポインタと双方向ポインタの混成ポインタのいずれかであることもある。図１では、参照ファイル１３０が基準地図のような外観を呈するとはいえ、上記のサードパーティ・ファイルのどれも同等に、参照ファイルと見なし、また、その参照ファイル内の位置を、同様に他のファイル内の情報とリンクさせることも可能であると、上記の特徴から定められている。このＵＬＲＯのマッピングの双方向の性質から、どんなサードパーティ・ファイルも、その参照ファイルとして働くことができ、また、特定の用途に応じて、その参照ファイルは、サードパーティ・ファイルとして働くことができる。
【００６３】
図２は、本発明の一実施形態により、参照ファイル内の位置に関連づけられた選択地理アイテムに対応するＵＬＲＯを含む環境を描いた説明図である。図２に示されるように、ＵＬＲＯ２１０により、電子参照ファイル２３０と、サードパーティ・ファイル２７４の１つまたは複数のとの間で、位置関連情報をマッピングすることができる。サードパーティ・ファイル２７４はそれぞれ、これらのサードパーティ・ファイルをリンクさせる関連するポインタおよび情報とともに、位置に関連づけられた１つまたは複数の地理アイテム２２０を含む。上述の通り、ＵＬＲＯ中の唯一の必須フィールドがＵＬＲＣ２０８である。この名称情報セットと、この座標セットが、両方とも空白でないことも必須であるが、ただし、特定のＵＬＲＯに対しては、これらのフィールドのいずれかが空白であることもある。
【００６４】
図２に示されるように、一実施形態により、このＵＬＲＯは、論理的に、このＵＬＲＯ環境内の３つの場所にある。大部分のＵＬＲＯは、このインターネットに接続されているサーバー上のファイル内のように、ほぼどこにでもある場合もある。全ＵＬＲＯはまた、参照ファイル２３０と、サードパーティ・ファイル２７４にそれぞれ物理的に関連づけられている他のコンポーネント（すなわち、バックポインタ）も含む。一実施形態により、ＵＬＲＯ２１０は、名称情報セット２０６、座標上位セット２０７、ＵＬＲＣ２０８、参照ファイル・ポインタ・フィールド２０９、サードパーティ・ファイル・ポインタ・フィールド２１１、参照ファイル・バックポインタ・フィールド２１２、サードパーティ・ファイル・バックポインタ・フィールド２０５、メタデータ・フィールド２１６を含む。
【００６５】
一実施形態により、名称情報セット２０６は、１）住所２１７（さらに、住所２１７が、１ａ）郵便番号２１８、１ｂ）ストリート・ナンバー２１９、１ｃ）ストリート名２２１、１ｄ）一連の名称を持つ階層的地区住所系２２２、１ｅ）他の住所情報２２３）のうち、１つまたは複数を含む）、２）指定場所２２４、３）電話番号２２８、４）地理的名称情報２３１、５）他の名称情報２３４のうち、１つまたは複数を含む。一実施形態により、地理的名称情報２３１は、４ａ）点フィーチャーに対する名称情報２３６、４ｂ）線フィーチャーに対する名称情報２３８、４ｃ）面フィーチャーに対する名称情報２４０、４ｄ）立体フィーチャーに対する名称情報２４２、４ｅ）線フィーチャーのセグメントに対する名称情報２４４、４ｆ）面フィーチャーのセクターに対する名称情報２４６、４ｇ）立体フィーチャーのセクションに対する名称情報２４８、４ｈ）複数の関連地理アイテムに対する名称情報２５０のうち、１つまたは複数を含む。
【００６６】
一実施形態により、このＵＬＲＯは、１つまたは複数（ｋ個）の座標上位セット２０７を含む。ここで、ｋは、その物理的位置に含まれる座標上位セットの数であり、さらに、この物理的位置が、地理アイテム２２０に関連づけられている。わかりやすくするために、図２に示される例では、ただ１つの座標上位セット２０３が示されているが、ただし、ＵＬＲＯは、１つ、２つ、または３つ以上の座標上位セットを含むかもしれない。それぞれの座標上位セット２０３は、ｋ個の地理座標セット２５１を含む。さらに、地理座標セット２５１が、経度２５２と緯度２５４などの地理座標を含む。地理座標セット２５１は、高度２５６も含むことがある。一実施形態により、座標上位セット２０３はまた、座標分類２５８、および他の座標情報２６０も含むことがある。随意に、主要高速道路または携帯電話塔とともに使用されるものなど、直線参照系に関わる情報２５９が含まれることもある。これは、例えば、位置２２０に関連づけられた携帯電話網に関わる情報を含むことがある。これにより、そのシステムは、地理座標ではなくて、携帯電話塔または直線参照機構、あるいはこれらのうちどれでも組み合わせたものを使用できる。あるいは別法として、このシステムは、地理座標と携帯電話座標を両方とも組み合わせたものを使用できる。他の実施形態では、この座標上位セットは、鉄道システムまたはハイウェイ直線参照系（highway linear referencing system）などの輸送網に関して割り当てられることもある。
【００６７】
上述の通り、ＵＬＲＣ２０８は、その位置に一意的に対応する。一実施形態により、ＵＬＲＣ２０８は識別コード２６２を含む。ＵＬＲＣ２０８はまた、他のＵＬＲＣ情報２６４も含むことがある。
【００６８】
一実施形態により、参照ファイル・ポインタ・フィールド２０９は、上記参照ファイル２３０内の上記位置２２０を指定する参照ファイル・ポインタ２１３を適宜、含む。それぞれの参照ファイル・ポインタ２１３はさらに、参照ファイル・ポインタ２１３の生成時間２６６、参照ファイル・ポインタ・フィールド２０９のタイプとクラス２６９を特定する情報２６８、および、他の参照ファイル・ポインタ・フィールド情報２７０のうち、１つまたは複数を含むことがある。
【００６９】
一実施形態により、サードパーティ・ファイル・ポインタ・フィールド２１１は、１つまたは複数のサードパーティ・ファイル・ポインタ２７２を含み、これらのサードパーティ・ファイル・ポインタはそれぞれ、上記１つまたは複数のサードパーティ・ファイル２７４の１つに入っている１つまたは複数の上記位置関連づけアイテム２２０を一意的に指定する。位置に関連づけられた特定の１つの地理アイテム２２０に関するサードパーティ・ポインタ２７２の数は、位置に関連づけられた地理アイテム２２０を含むサードパーティ・ファイル２７４内の関連づけの総数に等しい。特定のどんなサードパーティ・ファイルでも、それぞれのファイル内では、１つの関連づけか、２つ以上の関連づけのいずれかがあることもある。それぞれのサードパーティ・ファイルが、その位置に関連づけられた地理アイテムに対して、通常、少なくとも一部の情報を提供すると考えると、サードパーティ・ファイル・ポインタの総数は、一般に、サードパーティ・ファイルの数に少なくとも等しくなるが、ただし、さらなる関連づけの数だけ多くなることがよくある。それぞれのサードパーティ・ファイル・ポインタ２７２はさらに、サードパーティ・ファイル・ポインタ２７２の生成時間２７６、サードパーティ・ファイル・ポインタ２７２のタイプ２７８とクラス２７９、および、他のサードパーティ・ファイル・ポインタ・フィールド情報２８０のうち、１つまたは複数を含むことがある。
【００７０】
一実施形態により、この参照ファイル・バックポインタ・フィールド２１２は、参照ファイル２３０から後方に上記ＵＬＲＯ２１０の上記中央コンポーネントをさす（さらに具体的に言えば、後方にＵＬＲＣコード２６２をさす）参照ファイル・バックポインタ２１４を含む。参照ファイル・バックポインタ２１４は、この論理ＵＬＲＯの一部であるが、参照ファイル２３０内に常駐しており、またそこでは、データ項目間での双方向の横断を容易ならしめることになっている。それぞれの参照ファイル・バックポインタ２１４はさらに、参照ファイル・バックポインタ２１４の生成時間２９１、参照ファイル・バックポインタ２１４のタイプ２９２とクラス２９３、および、他の参照ファイル・バックポインタ情報２９４のうち、１つまたは複数を含むことがある。
【００７１】
一実施形態により、サードパーティ・ファイル・バックポインタ・フィールド２０５は、１つまたは複数のサードパーティ・ファイル・バックポインタ２１８を含み、しかも、それぞれのサードパーティ・ファイル・バックポインタ２１８は、サードパーティ・ファイル２７４の１つから後方にＵＬＲＯ２１０を一意的にさす（さらに具体的に言えば、後方にＵＬＲＣコード２６２をさす）。サードパーティ・ファイル・バックポインタ２１８は、この論理ＵＬＲＯの一部であるが、サードパーティ・ファイル２７４内に常駐しており、またそこでは、データ項目間での双方向の横断を容易ならしめることになっている。上述のサードパーティ・ファイル・ポインタの数と同様に、特定の位置２２０に関連づけられたサードパーティ・ファイル・バックポインタ２１８の総数は、一般に、その位置を含むサードパーティ・ファイル２７４の数に少なくとも等しくなるが、ただし、いくつかのサードパーティ・ファイルは２つ以上の関連づけを提供するかもしれないから、その総数は、さらなる関連づけの数だけ多くなることがよくある。それぞれのサードパーティ・ファイル・バックポインタ２１８はさらに、サードパーティ・ファイル・バックポインタ２１８の生成時間２９５、サードパーティ・ファイル・バックポインタ２１８のタイプ２９６とクラス２９７を特定する情報、および、他のサードパーティ・ファイル・バックポインタ情報２９８のうち、１つまたは複数を含むことがある。
【００７２】
図２に示される実施形態は、ＵＬＲＯ分類２８２、このＵＬＲＯの生成時間２８４、このＵＬＲＯのタイプ２８５とクラス２８６、および他のメタデータ情報２８７のうち１つまたは複数を含むメタデータ・フィールド２１６も含む。一実施形態により、このメタデータ情報は、以下でさらに詳しく説明される通り、これらのＵＬＲＯ間に階層リンクを生み出すのに使用されることもある。他の実施形態により、この階層情報は、他の論理コンポーネントの中で維持されることもある。図２に示されるスター構成では、前の利用者またはサードパーティのすべてに影響を及ぼすことなく、別のサードパーティまたは利用者のファイルを追加する（すなわち、その場合、総数ＮがＮ＋１に増大する）ことが容易となる。例えば、第１の地図中のオブジェクトと、第２の地図中のオブジェクトとの間にリンクまたは「連結」を確立する（これらのオブジェクトが、同一オブジェクトの異なるものであると仮定して）ために、このシステムは、第１の地図から第２の地図へ（さらに、第２の地図から第１の地図へ）ポインタを維持しなければならない。後で、第３の地図を、そのオブジェクトとともに導入する場合には、第１の地図と第２の地図は両方とも、この第３の地図中の新たなオブジェクトをささなければならない。同様に、第３の地図は、後方に第１の地図と第２の地図を両方ともささなければならない。したがって、ここで元の２つのリンク上に、新たな４つのリンクが導入される。伝統的な方法を用いると、このようなリンクの数はＮ！（Ｎ階乗）となろう。しかしながら、本発明の一実施形態により、第１の地図、第２の地図、第３の地図はそれぞれ、考察中のオブジェクトのＵＬＲＯだけをさす必要があると、このＵＬＲＯによって定められていが、一方、このＵＬＲＯは、第１の地図、第２の地図、第３の地図のオブジェクトをさす。したがって、この手法を用いると、２×Ｎ個のポインタしか必要としない。Ｎの値が３に等しい場合には、いずれかの手法を用いると、リンクの総数が同一となるが、ただし、Ｎの値が３よりも大きい場合には、このスター構成が「もっと楽に得られる（cheaper）」（すなわち、それが必要とするリンクが少なくなる）ことが明らかとなる。Ｎの値が大きければ大きいほど、それだけ効率が高くなる。
【００７３】
図３は、本発明の一実施形態によるＵＬＲＯプロセスの流れを示す流れ図である。本明細書に示される通り、このシステムまたはプロセスは、ＵＬＲＯ中の位置を定める情報の一部とともに、ＵＬＲＯの要求を受け取って、後で、ＵＬＲＯを生成する。上述の通り、一実施形態により、このＵＬＲＯは、名称情報セット、座標上位セット、ＵＬＲＣ、参照ファイル・ポインタ、サードパーティ・ファイル・ポインタ・フィールド、参照ファイル・バックポインタ、サードパーティ・バックポインタ、および、メタデータ・フィールドという８つのコンポーネントのうち、いずれかを含む。
【００７４】
上述の通り、ＵＬＲＯ中の唯一の必須フィールドがＵＬＲＣである。この名称情報セットと、この座標セットが、両方とも空白でないことも必須であるが、ただし、特定のＵＬＲＯに対しては、これらのフィールドのどちらか一方が空白であることもある。ステップ３００において、１つまたは複数のサードパーティ・ファイルにも入っている選択位置に対応する名称情報セットを決定する。ステップ３１０において、その位置に対応する座標上位セットを決定する。次に、ステップ３２０において、この選択位置に対してＵＬＲＯがまだない場合に、このシステムは、その位置にＵＬＲＣを割り当てる。このＵＬＲＣは、恒久的なものであって、この位置を参照するときに一意的である。ＵＬＲＯがすでにある場合には、ステップ３２０において、中央リポジトリから全ＵＬＲＯが取得される。ステップ３３０において、この参照ファイル内の位置に関連づけられた地理アイテムを指定する参照ファイル・ポインタを含む参照ファイル・ポインタ・フィールドが生成される。ステップ３４０において、１つまたは複数のサードパーティ・ファイルの１つに入っている１つまたは複数の位置関連づけ地理アイテムをそれぞれが一意的に指定する１つまたは複数のサードパーティ・ファイル・ポインタを含むサードパーティ・ファイル・ポインタ・フィールドが生成される。ステップ３５０において、この参照ファイルから後方に、そのＵＬＲＯ用のＵＬＲＣをさす参照ファイル・バックポインタを含む参照ファイル・バックポインタ・フィールドが生成される。この参照ファイル・バックポインタは物理的に、この参照ファイル内にあるか、あるいはこの参照ファイルに連結されたサイド・ファイル内にある。ステップ３６０において、これらのサードパーティ・ファイルのうちの１つの上記位置関連づけアイテムの１つから後方に、そのＵＬＲＯ用のＵＬＲＣをそれぞれが一意的にさす１つまたは複数のサードパーティ・ファイル・バックポインタを含むサードパーティ・ファイル・バックポインタ・フィールドが生成される。このサードパーティ・ファイル・バックポインタは物理的に、このサードパーティ・ファイル内にあるか、あるいはこのサードパーティ・ファイルに連結されたサイド・ファイル内にある。ステップ３７０において、メタデータ・フィールドを生成する。最後に、ステップ３８０において、この名称情報、座標上位セット、ＵＬＲＣ、参照ファイル・ポインタ・フィールド、サードパーティ・ファイル・ポインタ・フィールド、参照ファイル・バックポインタ・フィールド、サードパーティ・ファイル・バックポインタ・フィールド、および、メタデータ・フィールドが論理的に組み合わされて、このＵＬＲＯを生成する。図３に述べられる実施形態では、ＵＬＲＯの複数のインスタンスは、ファイルに格納されたそれらの中央部分に対し、カスタマのほかに、サードパーティ・ファイル提供者も、仮想データベース（ＶＤＢ）アプリケーション提供者も容易にアクセスできることもある。
【００７５】
上述の通り、ＵＬＲＯ中の唯一の必須フィールドがＵＬＲＣコンポーネントである。同様に、ＵＬＲＯを形成するときに上述のステップのすべてを実行する必要があるとは限らないし、また、それらの実行されるステップを、特定の順序で行ったり、同一の時間順でさえ行う必要はない。例えば、名称情報などの或る情報は、最初の時点で利用でき、次に、そのＵＬＲＯに含まれることがある。座標情報などの他の情報は、後の時点で（おそらく、何日も、または何ヶ月も後で）のみ利用できるようになり、また、その情報が利用できるようになってはじめて、ＵＬＲＯに含まれることがある。
【００７６】
図４は、本発明の一実施形態によるプロセスの流れをさらに詳しく示す流れ図である。図４に示されるステップのそれぞれは主として、図２に示される論理実体（エンティティ）の１つまたは複数に対応している。本明細書に示されるように、このシステム（またはプロセス）は、位置に関連づけられた地理アイテムに関する情報を受け取って、任意の適用できる参照ファイル・バックポインタ・フィールドおよびサードパーティ・ファイル・バックポインタ・フィールドとともに、名称情報セット、座標上位セット、ＵＬＲＣ、参照ファイル・ポインタ・フィールド、サードパーティ・ファイル・ポインタ・フィールド、およびメタデータ・フィールドというコンポーネントのいずれかを含むＵＬＲＯを生成する。
【００７７】
図４に示されるプロセスは、一般にどんな順序でも実行できるいくつかのステップまたはアクションを含む。特に、これらのステップの一部は当然ながら、例えばストリート・ナンバーを住所に含めるか、あるいは、そうしないという決定など、実際に行われたり、行われない場合があるこのシステムによる随意のアクションと見なされる。上述の通り、それらの実行されるステップは、異なる時間順でも行われることがある。完璧であるために、様々なオプションが図４に示されている。一実施形態により、この唯一の必須フィールドがそのＵＬＲＣであることを除き、実際の実施に応じてこれらのステップの一部を完全に省いてもよい。この名称情報セットと、この座標セットが、両方とも空白でないことも必須であるが、ただし、特定のＵＬＲＯに対しては、これらの変数のいずれか１つが空白であることもある。
【００７８】
ステップ４００において、このシステムは、参照ファイルに入っているか、あるいは１つまたは複数のサードパーティ・ファイルに入っている位置関連づけ地理アイテムも持つ位置に関連づけられている地理アイテムに対応する名称情報セットを決定する。ステップ４０４において、このシステムは、住所４０６、指定場所４０８、電話番号４１２、地理的名称情報４１４、および他の名称情報４１６のうち１つまたは複数を含む名称情報セットを決定する。ステップ４１８において、その住所情報の一部として、このシステムは、郵便番号４２０、ストリート・ナンバー４２２、ストリート名４２３、一連の名称を持つ階層的地区住所系４２４、および他の住所情報４２５のうち１つまたは複数を含む住所を決定する。ステップ４２６において、その地理的名称情報の一部として、このシステムは、点フィーチャーに対する名称情報４２８、線フィーチャーに対する名称情報４３０、面フィーチャーに対する名称情報４３２、立体フィーチャーに対する名称情報４３４、線フィーチャーのセグメントに対する名称情報４３６、面フィーチャーのセクターに対する名称情報４３８、立体フィーチャーのセクションに対する名称情報４４０、および、１つまたは複数の関連位置に対する名称情報４４２のうち１つまたは複数を含む地理的名称情報を決定する。その主要位置に対する名称情報に加えて、上記の１つまたは複数の関連位置に対する名称情報セットがある。この名称情報セットは、これらの地理的名称情報タイプの間の関係に関する情報、および他の名称情報を含むことがある。例えば、このＵＬＲＯが、「サンフランシスコ」という名称の都市に関連づけられた地理アイテムを定める場合には、関連位置に対する名称情報は、「カリフォルニア」であるかもしれない。また、その関係は、「州内の都市」というタイプのものである場合がある。
【００７９】
ステップ４５０において、このシステムは、その位置に関連づけられた地理アイテムに対応する座標上位セット（super-set of coordinates）を決定する。
【００８０】
ステップ４５２において、この座標上位セットは、その位置のジオメトリを表すのに必要ないくつか（ｋ個）の座標セットを含む。それぞれの座標セットは、座標分類４５５、地理座標セット４５６、主要高速道路または携帯電話塔とともに使用されるものなどの直線参照系に関する情報４５７、および、他の座標情報４５８のうち１つまたは複数を含むことがある。ステップ４５９において、その地理座標セットの一部として、それぞれの地理座標セットは、経度４６０と緯度４６１、もしくは、異なる座標参照系からの同等な情報を含む。さらに、それぞれの地理座標セットは、高度４６２も含む。
【００８１】
ステップ４６４において、その位置に関連づけられた地理アイテムに対して、ＵＬＲＯがまだない場合には、このシステムは、その選択アイテムにＵＬＲＣを割り当てる。ＵＬＲＯがすでにある場合には、中央リポジトリから、そのＵＬＲＯが取り込まれる。ステップ４６６において、生成または検索されるＵＬＲＣは、識別コードを含む。ステップ４６８において、このＵＬＲＣは、他のＵＬＲＣ情報を含むことがある。
【００８２】
ステップ４６９において、この参照ファイル内の位置に関連づけられた上記地理アイテムを指定する参照ファイル・ポインタを含む参照ファイル・ポインタ・フィールドを、適切なときに生成する。ステップ４７０において、この参照ファイル・ポインタ・フィールドは、この参照ファイル・ポインタ・フィールドの生成時間４７１、この参照ファイル・ポインタ・フィールドのタイプとクラス４７３、および、他の参照ファイル・ポインタ・フィールド情報４７４のうち、１つまたは複数を含むことがある。一実施形態により、このシステムは、２００６年７月２１日に出願された発明者Ｈａｎｓ  Ｕｌｒｉｃｈ  Ｏｔｔｏ氏による「ＭＥＴＨＯＤ  ＦＯＲ  ＧＥＮＥＲＡＴＩＮＧ  Ａ  ＬＯＣＡＴＩＯＮ  ＲＥＦＥＲＥＮＣＥ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＭＡＰＰＩＮＧ  ＩＮＦＯＲＭＡＴＩＯＮ  ＴＯ  Ａ  ＰＯＳＩＴＩＯＮ  ＷＩＴＨＩＮ  Ａ  ＤＩＧＩＴＡＬ  ＭＡＰ  ＤＡＴＡＢＡＳＥ（位置参照をもたらす方法と、デジタル地図データベースに入っている位置に情報をマッピングする方法）」と称する同時係属ＰＣＴ特許出願第ＰＣＴ／ＮＬ２００６／０５０１８５号（参照によって本明細書に組み入れられている）に記載されるオフセット・ポインタ住所指定技法（technique of offset pointer addressing）を利用することもある。
【００８３】
ステップ４７５において、サードパーティ・ファイル・ポインタ・フィールドを生成する。このサードパーティ・ファイル・ポインタ・フィールドは、１つまたは複数のサードパーティ・ファイル・ポインタを含み、また、それらのサードパーティ・ファイル・ポインタはそれぞれ、その位置関連づけ地理アイテムを含む１つまたは複数のサードパーティ・ファイルの１つに入っている１つまたは複数の地理アイテムを一意的に指定する。ステップ４７６において、このサードパーティ・ファイル・ポインタ・フィールドは、このサードパーティ・ファイル・ポインタ・フィールドの生成時間４７７、このサードパーティ・ファイル・ポインタ・フィールドのタイプ４７８とクラス４７９、および、他のサードパーティ・ファイル・ポインタ・フィールド情報４８０のうち、１つまたは複数を含むことがある。
【００８４】
ステップ４８１において、参照ファイル・バックポインタ・フィールドを、適切なときに生成する。この参照ファイル・バックポインタ・フィールドは、この参照ファイルから後方にそのＵＬＲＯ、具体的に言えばそのＵＬＲＣをさす参照ファイル・バックポインタを含む。ステップ４８２において、この参照ファイル・バックポインタ・フィールドは、この参照ファイル・バックポインタ・フィールドの生成時間４８３、この参照ファイル・バックポインタ・フィールドのタイプ４８４とクラス４８５、および、他の参照ファイル・バックポインタ・フィールド情報４８６のうち、１つまたは複数を含むことがある。このＵＬＲＯは、絶えず更新され、また、いつでもフィールドに記入されることもある。
【００８５】
ステップ４８７において、サードパーティ・ファイル・バックポインタ・フィールドを生成する。このサードパーティ・ファイル・バックポインタ・フィールドは、１つまたは複数のサードパーティ・ファイル・バックポインタを含み、しかも、それぞれのサードパーティ・ファイル・バックポインタが、上記サードパーティ・ファイルのうちの１つの上記位置関連づけ地理アイテムの１つから後方に、そのＵＬＲＯを一意的にさす。このサードパーティ・ファイル・バックポインタ・フィールドは、このサードパーティ・ファイル・バックポインタ・フィールドの生成時間４８９、このサードパーティ・ファイル・バックポインタ・フィールドのタイプ４９０とクラス４９１、および、他のサードパーティ・ファイル・バックポインタ・フィールド情報４９２のうち、１つまたは複数を含むことがある。このサードパーティ・ファイル・バックポインタは、必ずしも、そのＵＬＲＯと同時に生成されるとは限らない。ＵＬＲＯが、そのＵＬＲＯに関連づけられる地理アイテムを含むサードパーティ・ファイルから要求を受け取るときに、このサードパーティ・ファイル・バックポインタを生成することが多い。
【００８６】
ステップ４９３において、メタデータ・フィールドを生成する。ステップ４９４において、このメタデータ・フィールドは、ＵＬＲＯ分類４９５、このＵＬＲＯの生成時間４９６、このＵＬＲＯのタイプおよび／またはクラス４９７、および他のメタデータ情報４９８のうち１つまたは複数を含む。
【００８７】
最後に、ステップ４９９において、その名称情報セット、その座標上位セット、そのＵＬＲＣ、その参照ファイル・ポインタ・フィールド、そのサードパーティ・ファイル・ポインタ・フィールド、その参照ファイル・バックポインタ・フィールド、そのサードパーティ・ファイル・バックポインタ・フィールド、および、そのメタデータ・フィールドが組み合わされて、そのＵＬＲＯを生成する。
【００８８】
（ＵＬＲＯの拡張型（advanced）フィーチャー）
上に簡潔に述べられるように、ＵＬＲＯ階層やＵＬＲＯグループの利用などのいくつかの拡張型フィーチャーは、本明細書に述べられるＵＬＲＯシステムに余分の機能を追加し、しかも、数の増したサードパーティ・ファイルおよびリソースを横切って地理的位置情報をリンクさせる自由度が高められるようにしている。
【００８９】
「ＵＬＲＯの関係と階層」。図５は、本発明の一実施形態により、ＵＬＲＯの関係と階層の利用を描いた説明図である。図５は、図１と同様なシステムを示しており、このシステムでは、永久識別コードを含むＵＬＲＯは、電子参照ファイル１３０内の位置１２２、位置１２４、位置１２６に関連づけられた地理アイテムに割り当てられる。これらのＵＬＲＯは、この参照ファイル内の位置に関連づけられた地理アイテムを、１つまたは複数のサードパーティ・ファイル（１５０、１５２、１５４）内の位置に関連づけられた対応する地理情報とリンクさせる。図５に示されるように、位置１２０に関連づけられたただ１つの地理アイテムは、ただ１つのＵＬＲＯ１１２とリンクされることがある。さらに、ＵＬＲＯの関係を用いると、このＵＬＲＯ１１２が、ＵＬＲＯの関係（５０２、５０４）を介して、他のＵＬＲＯ（１１４、１１６）とリンクされる。（ＵＬＲＯ１１４とＵＬＲＯ１１６を互いにリンクさせるために、他のＵＬＲＯの関係５０６が存在することがある）。例えば、ＵＬＲＯ１１４とＵＬＲＯ１１６はそれら自体、そのような階層リンクなしには、地理アイテム１２２との直接のポインタ・リンクを持たないから、このシステムは、位置１２２に関連づけられた地理情報を、ＵＬＲＯ１１２を介して、位置関連の情報（１５６、１５８）とリンクさせるだけであろう。しかしながら、ＵＬＲＯの関係を用いると、このシステムは、ＵＬＲＯ（１１４、１１６）を、それらの位置関連情報（１５７、１５９）とともに、位置１２２に関連づけられた地理情報ともリンクさせることができる。
【００９０】
特定形式のＵＬＲＯ関係は、ＵＬＲＯ階層である。一実施形態により、ＵＬＲＯ階層は、第１のＵＬＲＯが第２のＵＬＲＯの親である一方で、第２のＵＬＲＯが第１のＵＬＲＯの子であると定めている。親ＵＬＲＯは、多くの子ＵＬＲＯと孫ＵＬＲＯを持つことがある。ＵＬＲＯ階層を利用すれば、このシステムは、よく知られていて、かつ容易に理解される概念に等しい関係を提供できる。例えば、ＵＬＲＯ１１６が、サンフランシスコ市を表す場合に、その親ＵＬＲＯ１１４はカリフォルニア州であり、またそのカリフォルニア州の親は、アメリカ合衆国全体１１２であるかもしれない。このＵＬＲＯ関係が階層であるときには、循環的な関係を避けるとともに、更新情報の反映で変更しなければならないリンクの数を減らすために、通常、親／子のリンクだけが維持される。そこで、図５に示されるように、親／子のリンク（５０４、５０６）だけが利用されることになる。「祖父母」リンク５０２は利用されないし、また、そのようなリンクをこのシステムに含ませておくことも望ましくないであろう。
【００９１】
一実施形態により、このメタデータ情報のコンポーネントは、これらのＵＬＲＯ間の関係と階層リンクを記録して、維持するために利用されることもある。他の実施形態により、このＵＬＲＯの関係と階層情報は、他の論理コンポーネントで維持されることもある。
【００９２】
「ＵＬＲＯグループ」。図６は、本発明の一実施形態により、ＵＬＲＯグループの利用を描いた説明図である。図６も、図１と同様なシステムを示しており、このシステムでは、永久識別コードを含むＵＬＲＯは、電子参照ファイル１３０内の位置１２２、位置１２４、位置１２６に関連づけられた地理アイテムに割り当てられ、しかも、ＵＬＲＯは、この参照ファイル内の位置に関連づけられた地理アイテムを、１つまたは複数のサードパーティ・ファイル（１５０、１５２、１５４）内の対応する位置情報とリンクさせる。図６に示されるように、位置１２２、位置１２４、位置１２６に関連づけられたただ１つの地理アイテムがただ１つのＵＬＲＯ１１２とリンクされるような標準的な場合のほかに、ここでは、別の地理アイテム５１２が、グループ・リンク５１４を用いて、ＵＬＲＯ１１２、ＵＬＲＯ１１４、ＵＬＲＯ１１６から成る１グループ（そのグループ自体、囲み枠５１０で示されている）とリンクされることもある。このようにして、ただ１つの位置を１グループとリンクさせることは、さらに最適な構成を可能にし、また、よく知られていて、かつ容易に理解される概念にも等しい。例えば、アイテム１２２、アイテム１２４、アイテム１２６が、カリフォルニア州内の異なる郡に関する現地情報である場合には、グループ５１０は、カリフォルニア州内のこれらの郡に対して、ＵＬＲＯのグループ全体であるかもしれない。アイテム５１０を選択することは、アイテム１２２、アイテム１２４、アイテム１２６のそれぞれを選択することと同等であるが、ただし、いくつかの用途では、さらに便利であるかもしれない。
【００９３】
「オフセット・ポインタ住所指定」。一実施形態により、オフセット・ポインタ住所指定により、このシステムは、現行オブジェクトのない位置に対する情報を提供することができる。このような場合、このシステムは、その参照ファイルまたはサードパーティ・ファイル内の地理アイテムをさすポインタを指定せずに、適切なオフセットとともに、その参照ファイルまたはサードパーティ・ファイル内の別の地理アイテムをさすポインタを指定することもある。後で、その位置に対して、直接ポインタまたは非オフセット・ポインタが生成されることも、また生成されないこともある。一実施形態により、このオフセット・ポインタは、図２に示されている上述の参照ファイルをさす正方向ポインタ（囲み枠２１３）に含まれることもある。
【００９４】
一実施形態により、このシステムは、２００６年７月２１日に出願された発明者Ｈａｎｓ  Ｕｌｒｉｃｈ  Ｏｔｔｏ氏による「ＭＥＴＨＯＤ  ＦＯＲ  ＧＥＮＥＲＡＴＩＮＧ  Ａ  ＬＯＣＡＴＩＯＮ  ＲＥＦＥＲＥＮＣＥ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＭＡＰＰＩＮＧ  ＩＮＦＯＲＭＡＴＩＯＮ  ＴＯ  Ａ  ＰＯＳＩＴＩＯＮ  ＷＩＴＨＩＮ  Ａ  ＤＩＧＩＴＡＬ  ＭＡＰ  ＤＡＴＡＢＡＳＥ（位置参照をもたらす方法と、デジタル地図データベースに入っている位置に情報をマッピングする方法）」と称する同時係属ＰＣＴ特許出願第ＰＣＴ／ＮＬ２００６／０５０１８５号（参照によって本明細書に組み入れられている）に記載されるオフセット・ポインタ住所指定技法を利用することもある。
【００９５】
「ミッシング・ポインタ」。一実施形態により、そのＵＬＲＯ技法により、このシステムは、「ミッシング・ポインタ」のサポートを含むことができる。位置に関連した所望の地理アイテムが、この参照ファイルには含まれてないが、ただし、これらのサードパーティ・ファイルの１つまたは複数が、位置に関連づけられた地理アイテムに対して関連情報を実際に持っているときには、そのサードパーティ・ファイルとそのＵＬＲＯとの間のポインタだけが生成されることがある。普通なら、このＵＬＲＯをこの参照ファイルとリンクさせることになるポインタが欠けている。上述の通り、ＵＬＲＯを形成するのに用いられるステップは、どんな順序でも、あるいは異なる時間順でも実行できるから、同様に、その様々な参照ファイルとサードパーティ・ファイルとの間のポインタも、異なる時間順で生成することができる。この情報が利用できるようになると、この「ミッシング・ポインタ」が適正に形成されて、新たな情報をこのＵＬＲＯとリンクさせる。
【００９６】
（システムの実施）
図７は、本発明の一実施形態に利用できるシステムの一例を図式的に示した略図である。図７に示されるように、システム５２０により、地理アイテムに基づいてＵＬＲＯを生成することができる。この地理アイテムは、電子参照ファイル５５０に入っている位置５４０に関連づけられ、また、１つまたは複数のサードパーティ・ファイル（５９４、５９５）に入っている１つまたは複数の位置関連づけ地理アイテムも持っている。図７は、コンポーネントを、論理的に別々のものとして描いているが、そのような描写は、単に例示目的にすぎない。図７に描かれるコンポーネントを組み合わせて、ただ１つのコンポーネントを形成できるか、あるいは、これらのコンポーネントをさらに他の別々のソフトウェア、ファームウェア、および／またはハードウェアのコンポーネントに分けられることが、当業者には明らかになろう。さらに、どのように上記のコンポーネントを組み合わせるか、または分けるかに関係なく、そのようなコンポーネントが、同一のコンピューティング装置上で実行できるか、あるいは、１つまたは複数のネットワークまたは他の適切な通信手段を経て接続された異なるコンピューティング装置の間で、そのようなコンポーネントを分散できることも、当業者には明らかになろう。
【００９７】
図７に示されるように、システム５２０は、一般に、１つまたは複数のメモリ５２８、１つまたは複数のプロセッサ５３０、および或る種類の１つまたは複数のストレージまたはリポジトリ５３２を含むかもしれないコンピューティング装置５２４を含む。システム５２０はさらに、ディスプレイ装置５３４上で動作するグラフィカル・ユーザー・インターフェース（すなわち、ＧＵＩ）５３６を含め、ディスプレイ装置５３４も含むことがあり、それにより、このシステムが、デジタル地図および他の情報を表示できる。ディスプレイ装置は、他のいくつかの場合に、文字ベースのものであることもある。
【００９８】
ここに示されるシステムは、電子文書のコンテンツを操作者５３８に表示するか、あるいは、プロセッサ５３０上で実行するコンピュータ・プロセスに自動的に使用されることが可能である。ＵＬＲＯを割り当てるソフトウェアは、一般にプロプライエタリ（メーカー独自仕様）であろうから、ハード・コーディング５４４を使用するか、または、このシステムのロジックの中に組み込んで、ＵＬＲＯを生成することもある。電子参照ファイル５５０の全部または一部が外部ストレージ５５３（これは、ときには、ストレージ５３２と同一のストレージであるかもしれない）から取り込まれるときに、ＵＬＲＯおよび／またはＵＬＲＣは、それらが前に生成されなかった場合には生成されて（あるいは、それらが前に生成されたことがある場合には、中央リポジトリ５４７から取り出されて）、電子参照ファイル５５０に含まれる位置５４０に関連づけられている地理アイテムに対応することになる。この新たに生成または取り込まれたＵＬＲＯを使用して、この参照ファイル内の地理アイテムを、これらのサードパーティ・ファイル内の位置関連情報とリンクさせる。ときには、サードパーティ・ポインタを含むサイド・ファイルも使用されることがある。上述の通り、システム５２０の特徴は、システム５２０が、現在および将来の多種多様な文書フォーマットにおいて、位置および位置関連づけ地理アイテムと容易にリンクできるようにすることである。これらのＵＬＲＯは、様々な方式で生成できる。このような方式の１つは、必要性が生じる（そのデータの必要性に基づくサードパーティによる要求など）ときはいつでも、ＵＬＲＯを生成することである。ＵＬＲＯを生成する別の方式は、この参照ファイル内のすべての住所と位置のオブジェクトに基づいて、ＵＬＲＯを優先的に生成することである。混成方式および他の方式の形態も可能であって、想像できる。
【００９９】
これらのコンポーネントのいくつかは、図７に単一システムとして示されているが、異なる様々なコンピュータシステムおよびプロセッサにわたって分散されることもある。例えば、一実施形態により、利用者のコンピュータは、そのデータベースのすべて、参照ファイル、サードパーティ・ファイル、および他のコンポーネントが置かれているリモート・サーバー５７０とやり取りする（５７２、５７４）こともある。しかしながら、他の実施形態では、例えば、この参照ファイルは、これらのサードパーティ・ファイルとは異なるマシン上に置かれることがあるが、一方、そのＵＬＲＯリポジトリは、さらに他のマシン上にある。実際は、異なる販売業者を含め異なる様々な情報源を、広域または広域ネットワーク（例えば、インターネット）にわたって広く分散させても、そのＵＬＲＯが、それらの情報源から情報を動的にリンクできるようにすることが、本システムの特徴である。
【０１００】
本発明の実施形態は、コンピュータ分野の熟練者には明らかになる通り、この開示の教えによりプログラムされた従来の汎用型または専用型のデジタル・コンピュータあるいはマイクロプロセッサを用いて、従来のやり方で実施されることがある。ソフトウェア分野の熟練者には明らかになる通り、この開示の教えに基づいて、適切なソフトウェア・プログラムが、熟練のプログラマにより容易に作成されることもある。本発明の実施形態はまた、当業者には容易に明らかになる通り、特定用途向け集積回路を用意することにより、あるいは、従来の構成回路から成る適切な回路網を相互接続することにより、実施されることがある。
【０１０１】
本発明の実施形態は、本発明の実施形態のプロセスをどれでも実行するようにコンピュータをプログラムするのに用いられる命令が格納されている記憶媒体（１つまたは複数）であるコンピュータ・プログラム製品を含む。この記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、超小型ハードディスク、および光磁気ディスクを含む任意タイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ・デバイス、磁気式または光学式のカード、ナノシステム（分子メモリＩＣを含む）、あるいは、命令および／またはデータの格納に適した任意タイプの媒体またはデバイスを含む（ただし、それらには限定されない）こともある。
【０１０２】
本発明の実施形態は、上記のコンピュータ読取り可能媒体（１つまたは複数）のどれか１つに格納されるものとして、汎用型／専用型のコンピュータまたはマイクロプロセッサのハードウェアを制御するソフトウェアと、このコンピュータまたはマイクロプロセッサが、本発明の実施形態の結果を利用して、人間の利用者または他の機構と対話できるようにするソフトウェアを両方とも含む。このようなソフトウェアは、デバイス・ドライバ、オペレーティングシステム、ユーザー・アプリケーションを含む（ただし、それらには限定されない）ことがある。最後に、このようなコンピュータ読取り可能媒体はさらに、上述の通り、本発明の実施形態を実行するソフトウェアも含む。
【０１０３】
上記の汎用型／専用型のコンピュータまたはマイクロプロセッサのプログラム（ソフトウェア）に含まれているものは、電子参照ファイル内の選択位置に対応するユニバーサル位置参照オブジェクト（ＵＬＲＯ）を生成する（その場合、１つまたは複数のサードパーティ・ファイルにも１つまたは複数の位置関連づけ地理アイテムが含まれている）こと、選択位置に対応する名称情報セットを決定すること、この位置に対応する座標上位セットを決定すること、この位置に一意的に対応するユニバーサル位置参照コード（ＵＬＲＣ）を割り当てること、上記参照ファイル内のその位置を指定する参照ファイル・ポインタを含む参照ファイル・ポインタ・フィールドを生成すること、上記１つまたは複数のサードパーティ・ファイルの１つに入っている上記１つまたは複数の位置関連づけ地理アイテムをそれぞれが一意的に指定する１つまたは複数のサードパーティ・ファイル・ポインタを含むサードパーティ・ファイル・ポインタ・フィールドを生成すること、上記参照ファイルから後方に、上記参照ファイルまたは関連サイド・ファイルに常駐している上記ＵＬＲＯをさす参照ファイル・バックポインタを含む参照ファイル・バックポインタ・フィールドを生成すること、上記サードパーティ・ファイルまたは関連サイド・ファイルに常駐しているサードパーティ・ファイル・バックポインタであって、それぞれが上記サードパーティ・ファイルの１つの位置関連づけ地理アイテムから後方に上記ＵＬＲＯを一意的にさすサードパーティ・ファイル・バックポインタを含むサードパーティ・ファイル・バックポインタ・フィールドを生成すること、上記ＵＬＲＯに関するメタデータを含むように構成されたメタデータ・フィールドを生成すること、および、上記名称情報セット、上記座標上位セット、上記ＵＬＲＣ、上記参照ファイル・ポインタ・フィールド、上記サードパーティ・ファイル・ポインタ・フィールド、上記参照ファイル・バックポインタ・フィールド、上記サードパーティ・ファイル・バックポインタ・フィールド、上記メタデータ・フィールドを組み合わせて、上記ＵＬＲＯを生成することを含め（ただし、それらには限定されない）、本発明の教えを実施するためのソフトウェア・モジュールである。
【０１０４】
本発明の上の説明は、図示と説明の目的で与えられてきた。この説明は、すべてを尽くすつもりはないし、また、本発明の実施形態を、開示されている通りの形態に限定するつもりもない。多くの変更例や変形例が、当事者には明らかになろう。これらの実施形態は、本発明の原理、および本発明の実地応用をもっともよく説明するために、選択され、述べられ、それにより、他の当業者が、本発明を様々な実施形態に関して理解することができ、また、特定の用途に適した様々な変更が考えられた。本発明の範囲は、併記の特許請求の範囲、および、それらと同等なものにより定義されるつもりである。
【図面の簡単な説明】
【０１０５】
【図１】本発明の一実施形態により、永久ＩＤコードを含むＵＬＲＯを、電子参照ファイル内の位置に割り当てる処理を描いた説明図である。
【図２】本発明の一実施形態により、参照ファイル内の位置に関連づけられた選択地理アイテムに対応するＵＬＲＯを描いた説明図である。
【図３】位置に関連づけられた地理アイテムに関する情報を受け取って、ＵＬＲＯを作成する本発明の一実施形態によるプロセスの代表的な流れを示す流れ図である。
【図４】位置に関連づけられた地理アイテムに関する情報を受け取って、ＵＬＲＯを作成する本発明の一実施形態によるプロセスの代表的な流れをさらに詳しく示す流れ図である。
【図４Ａ】位置に関連づけられた地理アイテムに関する情報を受け取って、ＵＬＲＯを作成する本発明の一実施形態によるプロセスの代表的な流れをさらに詳しく示す流れ図である。
【図４Ｂ】位置に関連づけられた地理アイテムに関する情報を受け取って、ＵＬＲＯを作成する本発明の一実施形態によるプロセスの代表的な流れをさらに詳しく示す流れ図である。
【図４Ｃ】位置に関連づけられた地理アイテムに関する情報を受け取って、ＵＬＲＯを作成する本発明の一実施形態によるプロセスの代表的な流れをさらに詳しく示す流れ図である。
【図４Ｄ】位置に関連づけられた地理アイテムに関する情報を受け取って、ＵＬＲＯを作成する本発明の一実施形態によるプロセスの代表的な流れをさらに詳しく示す流れ図である。
【図４Ｅ】位置に関連づけられた地理アイテムに関する情報を受け取って、ＵＬＲＯを作成する本発明の一実施形態によるプロセスの代表的な流れをさらに詳しく示す流れ図である。
【図５】本発明の一実施形態により、ＵＬＲＯの関係と階層の利用を描いた説明図である。
【図６】本発明の一実施形態により、ＵＬＲＯグループの利用を描いた説明図である。
【図７】本発明の一実施形態に利用できるシステムの一例を図式的に示した略図である。
【図１】
2009520992.tif 000003
【図２】
2009520992.tif 000004
【図３】
2009520992.tif 000005
【図４】
2009520992.tif 000006
【図４Ａ】
2009520992.tif 000007
【図４Ｂ】
2009520992.tif 000008
【図４Ｃ】
2009520992.tif 000009
【図４Ｄ】
2009520992.tif 000010
【図４Ｅ】
2009520992.tif 000011
【図５】
2009520992.tif 000012
【図６】
2009520992.tif 000013
【図７】
2009520992.tif 000014