JP2013538391A - 拡張現実のためのフレキシブルなデータダウンロードのモデル - Google Patents

Abstract

ARシステム、ARシステムを動作させるための方法、モバイルデバイス、およびモバイルデバイスを動作させるための方法において、異なる画像データの提供者に対して異なり得る、フレキシブルなロクセルが使われる。これによって、ARアプリケーションは、都市のような密集した領域などのより情報が多くより狭いロクセル、または、たとえば砂漠領域のような情報が少なくより広いロクセルを、ダウンロードできるようになる。データのダウンロードは、クライアントの方位および移動の方向を考慮して、クライアントが移動するに従ってダウンロードされる必要のある、付加的なデータを決定することができる。ロクセルは、ロケーション情報にマッピングされたロクセル識別子によって符号化されるので、特定のアプリケーションに対して必要なロクセルしかダウンロードする必要がなく、クライアントは、いつ新しい画像データを取得するか、およびどれだけのデータを取得するかを、自律的に決定できるようになる。

Description

関連出願の相互参照
本出願は、参照により本明細書に組み込まれている、2010年7月23日に出願された米国仮出願第61/367,300号の利益を主張するものである。

本開示は、たとえばモバイルデバイスにおいて、拡張現実デバイスおよびディスプレイを提供するための、方法、装置、およびシステムに関する。

近年、拡張現実(AR)に対する関心が高まっており、ARとは、現実世界と仮想現実とが組み合わされて、リアルタイムで対話可能な状態のことである。一般に知られているARの例には、アメリカンフットボールの試合のテレビ放送で見られる、黄色の「ファーストダウン」ラインがある。現実世界の要素はフットボールのフィールドと選手であり、仮想的な要素は黄色のラインであり、このラインはコンピュータによってリアルタイムでフィールドの画像に重ねて描かれる。同様に、ラグビーのフィールドおよびクリケットのピッチ上に、拡張現実を用いてスポンサーの商標が表示される。すなわち、テレビで見ると大きなロゴがフィールド上に挿入される。自動車または航空機のような一部の現在の適用例では、「警告」ディスプレイがフロントガラスに組み込まれて、ドライバーまたはパイロットの見る現実世界に重畳して情報を示す。

ARアプリケーションは通常、画像の検出および追跡のためのバックエンドデータベースに存在する、画像データに依存する。画像データは通常、バックエンドデータベースに事前にロードされた未加工の画像のキーポイントを含むが、追加の画像データも、任意の時点でデータベースに付加的に加えられ得る。

携帯電話などのようなモバイルデバイスがより遍在するようになり、そのようなデバイスの機能および特性が向上するのにつれて、ARの使用が実現される場面は増え続けている。提案されてきた1つのARシステムは、携帯電話に組み込まれたカメラを使う。ユーザは写真を撮り、その写真はサーバへワイヤレスに送られ、サーバはその写真をデータベースの画像と照合する。次いでサーバは、データベースの画像を電話に返し、電話上でデータベースの画像が元の画像に重畳され得る。データベースの画像は、たとえば、建物の名前、構造物の歴史、または視界内の他の項目などのような、元のカメラ画像の中に見える特徴に関する情報を含み得る。

モバイルARの実施には、画像データを受信して、画像検出を実行して、モバイルデバイスでローカルに取得されたカメラの視界と照合することが必要なので、最良の性能のために、画像データは通常、検出の目的でモバイルデバイスのRAMにロードされる。利用可能なRAMおよびワイヤレス帯域幅の制限によって、任意の所与の時間にダウンロードでき使用できる画像データの量の点で、課題が生じる。この課題の一部を克服するために、モバイルデバイスのロケーションを使って、任意の所与の時間にダウンロードされ使われる画像データの量を制限することができる。しかし、利用可能なシステムは、性能、帯域幅、および電力使用量の適切な組合せを実現できないことがある。

改善されたARシステムを実現する際の課題の1つは、モバイルデバイスのロケーションを判定して、必要な画像処理をサーバが効率的に実現できるようにすることである。モバイルデバイスのロケーションを判定できる1つの方法は、GPS測位単独による方法、または、セルラー基地局のロケーション情報による支援を伴うGPS測位による方法である。提案されてきたシステムは、たとえば、1つまたは2つの街区内での、粗いロケーション測定を用いる。

1つのシステムでは、モバイルデバイスは、モバイルデバイスの現在のロケーションに関するデータをプリフェッチするように構成され、次いでユーザが、モバイルデバイスと関連するカメラを使って、関心のあるロケーションの写真を撮る。次いで写真の画像がプリフェッチされたデータと照合され、その結果がユーザに示される。

大量のデータを管理するために、セルに基づく体系を使って、地球の地理座標空間を体系化し、各ARセル内で考慮される画像またはキーポイントの数を制限することが提案されてきた。(この文脈における「ARセル」という用語は、セルラー電話システムの文脈における「セル」という用語とは同じではない。)ARセルは「ロクセル(loxel)」と名付けられ、ロケーションに基づくピクセル記憶モデルであることを示す。ロクセルは通常、特定のロケーションと関連付けられ、特定の領域(通常は簡単にするために直線的な座標で定義される)にわたる。カーネルは、一般に特定のロクセルから見える領域を指し、特定のロクセルにわたるものとして、またはロクセルの配置として、通常は定義される。

ユーザのロケーションに応じて、3×3のロクセルのカーネル領域に対応する画像データがクライアントに送られ、カーネルの中心はユーザの現在のロクセルである。ユーザが新しいロクセルに入ると、新しいカーネル領域に対応する追加の画像データが送られる。使われてきたロクセルの大きさは、30メートル四方である。この技法は、任意の所与の時間にユーザへ送る必要がある画像データの量を大きく低減するが、依然としていくつかの欠点がある。

一部のシステムでは、任意の所与の時間にダウンロードされなければならない付加的なロクセルの数は、4つの主要な方向に沿ったモバイルデバイス動きのみを考慮して、3個であった。現実には、任意の所与のロクセルに対して8個の隣接するロクセルが存在する。したがって、隣接するロクセルの1つへの移動においては、最高で5個の付加的なロクセルのデータをダウンロードする必要があり得る。さらに、ARアプリケーションの次の有効な使用が、隣接するロクセルで常に行われるとは限らない。ユーザの用途および移動に応じて、次の有効なロクセルは隣接しないロクセルであることがあり、この場合、より多くのデータをダウンロードする必要がある。

ダウンロードは、ユーザが新しいロクセルへ入った後の付加的な画像データを含むだけでよいという、仮定も行われてきた。このことは、画像データを取得する際に最適ではない遅延をもたらすことがあり、転じて、データを要求するアプリケーションにおいて望ましくない遅延を引き起こす。このことは、次の有効なロクセルが現在のロクセルと隣接しない場合に、特に当てはまる。

360度の視野に関心があり、焦点は隣接するロクセルの1つよりも遠くにはないという仮定も、行われてきた。360度の視野は、ARアプリケーションが使われているときにパンするために必要であり得るが、すべてのARアプリケーションで必要であるとは限らない。さらに、あるARアプリケーションには間欠的な使用パターンしかないとすると、360度の視野のデータをダウンロードすることは、一部の状況では過剰である可能性がある。携帯電話のカメラの視野はせいぜい70度であり、通常の視野は約55度である。このため、見える領域は、1つだけのロクセル中の静止したカメラの視界になる。ロクセルの大きさに応じて、カメラの視界は、1つまたは複数の隣接するロクセルを含み得るが、平均的には、カメラの視界は依然として、360度の視野で想定されている視野の、25%以下でしかない。

過去に提案された典型的なシステムは、モバイルデバイスが新しいロクセルにいつ到達したかをモバイルデバイスが自動的に検出するための、手段を提供しない。そのため、デフォルトで、モバイルデバイスは、自身の新しいロケーションによってサーバを継続的に更新し、サーバが新しいデータセットをいつ送るかを決定できるようにする必要がある。この手法は、ARアプリケーションが長時間バックグラウンドで実行されるように設計された場合には特に、電力を消費する。さらに、これを行う複数のアプリケーションは存在するが、最終利用者に対するプライバシーの問題を引き起こす。

提案されてきた別のARシステムは、潜在的可視集合(PVS(potentially visible sets))のシステムである。潜在的可視集合の概念は、コンピュータビジョンにおいては長年知られている。PVSは、障害物を考慮して、カメラまたは人の目に見えるオブジェクトのセットを判定するように設計された。この技法は、特定のオブジェクトの可視性を得るために、障害物に対する良好な訓練データが利用可能であることと、障害物に対するいくらか正確なカメラの位置の測定およびカメラの方位が必要である。したがって、PVSは、オブジェクトまたは画像の潜在的可視集合を決定するために、画像データに加えて、その画像に関するカメラと障害物の相対的な配置のデータも必要とする。

純粋にセルに基づく画像の体系化の代わりに、拡張現実環境にPVSの使用を適用する試みが、行われてきている。障害物という概念は、屋内環境でははるかに適用可能性が高いが(たとえば、壁、部屋の内部からの可視性など)、障害物のための訓練データを取得するのが現実的ではないことが多い屋外環境に対して、障害物という概念はそれほど簡単にマッピングしない。さらに、カメラの所与のロケーションおよび方位に対して正確なPVSを得ることは、非常に複雑であり、許容可能な照合率を得るために、少なくはない量のデータをキーポイントに付加する必要があり得る。したがって、PVSの使用は、屋外でのモバイルARの使用を、セルに基づく体系化と比較して、何ら大きく助けるものにはなり得ない。

本発明の一実施形態は、異なる画像データの提供者に対して異なり得る、フレキシブルなロクセルを提供する。したがって、たとえば、本発明の一実施形態は、フレキシブルな大きさのロクセルを用いる。これによって、ARアプリケーションは、都市のような密集した領域などのより情報が多くより狭いロクセル、または、たとえば砂漠領域のような情報が少なくより広いロクセルを、ダウンロードできるようになる。ロクセルの大きさはまた、関心のある領域で利用可能なGPSの精度などのような、他の要因を用いて決められてもよい。

本発明の別の実施形態によれば、ロケーションに加えてクライアントの方位と移動の方向とを考慮して、ダウンロードされる必要のある付加的なデータを決定する、フレキシブルなデータダウンロードのモデルが提供され、ダウンロードは、アプリケーションに対する重要性という因子に基づいて、効率を最大化するように調整され得る。

本発明のさらに別の実施形態によれば、ロクセルがロクセル識別子によって符号化され、ロケーション情報が各々の符号化されたロクセルにマッピングされる。これによって、各ロクセルと関連付けられた画像データを分類することが可能になり、必要な場合にのみ画像データを検索することが可能になる。したがって、特定のアプリケーションに必要なロクセルしか、ダウンロードする必要がない。

この符号化は、クライアントが、必要とするロクセルの識別の自動的な計算を実行できるように、なされ得る。これによって、クライアントは、新しい画像データをいつ取得して、どれだけのデータを取得するかを、自律的に決定できるようになる。このことは、メッセージングの節約につながり、転じて、ロケーションの更新をサーバに継続的に送る必要がなくなることで、電池の寿命を向上させる。また、クライアントの正確なロケーションを常時サーバに開示する必要がなくなることで、クライアントに対してより良好なプライバシーを提供するのに役立つ。

本発明の一実施形態によれば、ロクセルに基づくデータの体系化に対するベクトル量子化の使用が、各ロクセルに固有の符号ベクトルを与えるために行われる。そしてクライアントは、ロクセル識別子のコードブックをダウンロードし、サーバに対する継続的なロケーションの更新を必要とすることなく、クライアントの位置するロクセルを自己計算することができる。これによって、電池の電力が節減され、プライバシーが守られる。ロクセルの識別は、たとえば、各ロクセルのロケーションが(緯度、経度)の対の形の符号ベクトルとして表される、ベクトル量子化技法を使って行われ得る。(緯度、経度)の対は、たとえば、ロクセルに存在するすべての(緯度、経度)の対の平均として、選択され得る。クライアントが初期化すると、クライアントは、マスターARサーバに連絡し、符号ベクトルのセットを取得する。このことは、クライアントの現在の(緯度、経度)パラメータを提供し、クライアントのロケーションの周りの符号ベクトルのセットを取得することによって行うことができ、これによってクライアントは、少なくとも一部のロクセルのコードブックをダウンロードできるようになる。

所望のロクセルのコードブックを決定するために、クライアントは、クライアントの現在の(緯度、経度)ロケーションから最もユークリッド距離が近い、符号ベクトルを探す。クライアントが移動すると、クライアントは、近くのロクセルへのユークリッド距離をローカルで計算し、ロクセルIDの変化を検出すると、または、アプリケーションの使用法に基づいて新しいデータが必要であることを検出すると、サーバに連絡することができる。したがって、このモデルは、初期のコードブックを得るためにサーバとの初期の情報交換を必要とするが、サーバ側が最適なグリッドモデルを決定する際の柔軟性と、クライアントに対する性能の改善およびプライバシーの保護の機会との両方を実現して、より多くのデータのためにサーバに連絡するのに適切な時間を決定する。同時に、このモデルは、クライアントが、どのロクセルをダウンロードするかを自身で決定できるようにする。

したがって、広範な拡張現実(AR)システムの実施形態によれば、判定された必要性、カメラの視界、およびARモデルを使うクライアント装置の使用パターンに基づいて、ARモデルを適合させるための手段が提供される。ARモデルは、ロクセルの大きさがロクセルに含まれる情報の量に関連する、フレキシブルなロクセルの大きさの体系を有する、ロクセルに基づくデータの体系に、少なくとも一部基づく。ロクセルに基づくデータの体系は、識別のための各ロクセルの符号化を実現し、ロクセルの符号化は、クライアントによって自律的に復号され得る。ロクセルIDは、ベクトル量子化技法を使って決定されてよく、クライアントは、クライアントの現在の緯度、経度のパラメータからユークリッド距離が最も近いロクセル符号ベクトルを見つけることによって、現在のロクセルを特定することができ、クライアントが移動してロクセルIDの変化を検出すると、クライアントは、最小のユークリッド距離を計算して、ダウンロードすべき次のロクセルを自己特定する。

別のARシステムの実施形態によれば、ARサーバは、情報のカーネルへと体系化されたARデータを提供する。各カーネルは、複数のロクセルに体系化され、各ロクセルは、それぞれのカーネルの中の地理的な領域と関連付けられ、ロケーションベクトルによって特定される。クライアントデバイスは、どのロクセルがクライアントに近接して位置しているかを判定することによって、どのロクセルをダウンロードすべきかを自己判定することができる。クライアントは、クライアントが位置するカーネルの中のロクセルまでのユークリッド距離を求めることによって、どのロクセルがクライアントに近接して位置するかを自己判定することができる。さらに、クライアントは、どのロクセルが、クライアントの方位の向きに存在するかを、自己判定することができる。ロクセルの少なくともいくつかは大きさが異なり、ロクセルの少なくともいくつかの大きさは、ロクセルの少なくともいくつかに含まれる情報の量に関連する。

ロケーションベクトルは、緯度、経度の対を含む符号ベクトルであってよく、ここで緯度、経度の対は、その緯度、経度の対によって特定されたロクセルの少なくとも一部のロケーションに対応する。

クライアントデバイスに拡張現実(AR)情報を表示するための方法のある実施形態によれば、クライアントデバイスは、その現在位置を自己測定するように動作する。ARサーバからの、クライアントデバイスによって要求されたロクセルのロケーションベクトルのコードブックが、クライアントデバイスに提供され、クライアントデバイスは、ロクセルのロケーションベクトルおよびクライアントデバイスの現在位置から、クライアントデバイスが位置するコードブック中の初期ロクセルを自己判定するように動作する。この方法はまた、クライアントデバイスによって特定された複数のロクセルと関連付けられるAR情報を、クライアントデバイスに提供するステップを含む。

クライアントデバイスは、初期ロクセルの外側に移動したかどうかを自己判定するように動作することができ、移動した場合、クライアントデバイスは、コードブック中のロクセルのロケーションベクトルから追加のロクセルを特定し、追加のロクセルと関連付けられるAR情報を要求するように動作する。追加のロクセルは、クライアントデバイスの移動の方向に基づいて、クライアントデバイスの方位によって、またはこれらの両方によって特定され得る。加えて、追加のロクセルを特定することは、クライアントデバイスと関連付けられるカメラの視野に基づいてもよい。

クライアントデバイス上でAR情報を表示するための方法のさらに別の実施形態によれば、ARアプリケーションがクライアントデバイスで実行され、測位アプリケーションがクライアントデバイスで実行されて、クライアントデバイスの現在位置を測定する。クライアントデバイスは、クライアントデバイスの位置に基づいて、ARサーバからのロクセルの識別情報を要求する。ロクセルは、情報のカーネルに体系化され、各ロクセルは、それぞれのカーネルの中の地理的な領域と関連付けられ、ロケーションベクトルによって特定される。ロクセルの識別情報のセットが、要求に応答して、ARサーバからクライアントデバイスにアップロードされ、ロクセルの識別情報のアップロードされたセットは、クライアントデバイスが位置するロクセルの識別情報を少なくとも含む。ロクセルの識別情報のセットは、コードブックとしてアップロードされ得る。アプリケーションがクライアントデバイスで実行され、ロクセルのアップロードされたセットの中で、初期ロクセルを見つける。その後、クライアントデバイスが初期ロクセルの外側に移動したと、クライアントデバイスが判定すると、クライアントデバイスは、追加のロクセルの識別情報をアップロードするように、ARサーバへ要求を行う。

モバイルデバイスの実施形態の広範な態様によれば、モバイルデバイスは、ハードウェア、ソフトウェア、ファームウェア、または組合せで実装された測位エンジンのような、モバイルデバイスの現在位置を求めるための手段を含む。それぞれの地理的な領域と関連付けられる複数のロクセルのロケーションベクトルを、ARサーバから取得するための手段も、含まれる。この手段は、受信機/送受信機、関連する受信回路、プロセッサ、およびメモリ、さらには、他のハードウェア、ソフトウェア、および/またはファームウェアのコンポーネントを含み得る。加えて、現在位置と、現在位置が位置する初期ロクセルを少なくとも含むロケーションベクトルとに基づいて、複数のロクセルのセットを特定するための手段が提供される。この手段は、現在位置を入手して、セットを求めるための命令を実行するプロセッサ、さらには、他のハードウェア、ソフトウェア、および/またはファームウェアのコンポーネントを含み得る。(上で概説されたような受信機、送受信機などのような)手段が、ARサーバからセットのためのAR情報をアップロードするために、含まれ得る。

この実施形態では、モバイルデバイスが初期ロクセルの外側に移動したかどうかを判定するための手段が含まれてよく、この手段は、上で説明されたような測位エンジンと、位置情報を入手して、追加のロクセルの必要性を示すのに位置の変化が十分大きいかどうかを判定するための、プロセッサとを含み得る。位置の変化が十分に大きい場合、メモリに記憶されたコードブック情報が、アップロードすべき追加のロクセルを特定するために入手され得る。追加のロクセルは、モバイルデバイスの移動の方向および/またはモバイルデバイスの方位に基づいて、特定され得る。モバイルデバイスは、特定された追加のロクセルをアップロードすることができる。モバイルデバイスはさらに、カメラと、追加のロクセルを特定するための手段(プロセッサのような)を含んでよく、カメラの視野に基づいて、追加のロクセルを特定する。カメラの視野が70度である場合、追加のロクセルは、1つまたは2つのロクセルであり得る。カメラの視野が180度である場合、追加のロクセルは、3つのロクセルであり得る(当然、ロクセルの数は3つでなくてもよく、たとえば、1以上の任意の数であってよい)。上で説明された手段のいずれも、ハードウェア、ソフトウェア、ファームウェア、または組合せ、特に当技術分野で知られている任意の手段を使って実装することができる。

ARサーバシステムの広範な実施形態によれば、マスターARサーバは、モバイルデバイスによって要求されるロクセルのロケーションベクトルのコードブックを提供して、モバイルデバイスが、モバイルデバイスの位置するロクセルを自己判定できるようにする。少なくとも1つのARロクセルサーバは、コードブックを提供するために、マスターARサーバによって選択可能なロクセルのロケーションベクトルを含むロクセルの識別情報を少なくとも格納する。画像データベースは、AR情報を提供する。モバイルデバイスからのマスターARサーバとの通信は、インターネットを通じたものであってよい。所望される場合には、ARサーバシステムは、ARアプリケーションのサポートをモバイルデバイスに提供するアプリケーションサーバを含んでよく、モバイルデバイスの近くのロクセルについての関心地点情報をモバイルデバイスに提供するための、特別ARサーバも含まれてよい。

ARサーバシステムを動作させるための方法の広範な実施形態によれば、マスターARサーバは、モバイルデバイスによって要求されるロクセルのロケーションベクトルのコードブックを提供し、モバイルデバイスが、モバイルデバイスの位置するロクセルを自己判定できるようにして、モバイルデバイスによって自己特定されたロクセルからAR情報を提供するように動作する。コードブックを提供するために、マスターARサーバによって選択可能なロクセルのロケーションベクトルを含むロクセルの識別情報を少なくとも格納するための、少なくとも1つのARロクセルサーバが動作する。画像データベースが、AR情報を提供するために保持される。

AR情報が、記憶されて、サーバによってサービスされる領域のクライアントに提供される、ARシステムのブロック図である。 関連付けられた視界領域を示す、ロクセルのセットの3つのカーネルの図である。 L(x+1,y+1)に対応した視界領域および方位角θを示す、図2の3つの異なるカーネル領域の図である。 異なるサイズのロクセルを有するカーネル領域の図である。 ARクライアントデバイスと、マスターARサーバと、ロクセルARサーバと、POIサーバとの間の、例示的な呼の流れを示す図である。 関連する情報がARクライアントデバイスへより近いロケーションで利用可能なときに、ARクライアントデバイスがローカルARサーバにリダイレクトされる機構を示す、ARクライアントデバイスと、マスターARサーバと、ロクセルARサーバと、ローカルARサーバとの間の、例示的な呼の流れを示す図である。 ARシステムとともに動作する、モバイルデバイスのある実施形態のブロック図である。

図面の様々な図において、同様の参照番号は同様のまたは類似の部分を指すために用いられる。

上で言及されたように、拡張現実(AR)アプリケーションは通常、画像の検出および追跡のためのバックエンドデータベースに存在する、画像データに依存する。画像データは通常、データベースに事前にロードされた未加工の画像のキーポイントを含むが、追加の画像データが、任意の時点でデータベースに付加的に加えられ得る。モバイルARの実施は、画像データを受信することと、画像検出を実行することと、モバイルデバイスでローカルに取得されたカメラの視界に対して照合することとに依存する。データベース情報のダウンロードを容易にするために、本発明の一実施形態は、異なる種類の画像データに対しては異なり得る、フレキシブルなロクセルのモデルを提供する。したがって、たとえば、本発明の一実施形態は、フレキシブルな大きさのロクセルを用いる。これによって、ARアプリケーションは、都市のような密集した領域を表す情報などのより情報が多くより狭いロクセル、または、たとえば砂漠領域を表す情報のような格納する情報が少なくより広いロクセルを、ダウンロードできるようになる。ロクセルの大きさはまた、関心のある領域で利用可能なGPSの精度などのような、他の要因を用いて決められてもよい。たとえば、ロケーションの不確実さが比較的大きい場合、より大きなロクセルが、実際のモバイルデバイスの位置についての関連するAR情報を含む可能性が高いことがある。対照的に、不確実さが小さい場合、小さなロクセルの大きさが使われ得る。さらに、フレキシブルなデータダウンロードのモデルは、ロケーションに加えてクライアントの方位と移動の方向とを考慮して、ダウンロードされる必要のある付加的なデータを決定するように構成されてよく、ダウンロードは、アプリケーションに対する重要性という因子に基づいて、効率を最大化するように調整され得る。

フレキシブルなデータダウンロードのモデルが実装され得るARシステムアーキテクチャ10の例が図1に示され、ここで図1を参照する。示される実施形態では、1つまたは複数の拡張現実クライアントが存在し、2つのクライアント12および14が示されている。2つのクライアントが示されるが、システムの帯域幅の能力に応じて、任意の数のクライアントが存在してよいことが理解されよう。ARアプリケーションは、モバイルデバイス12および14で実行され得る。クライアント12および14に地理的に近いキャッシュされた記述子データベースを有する、ローカルARキャッシュ16、たとえば、キャッシュされた記述子データベースを含むサーバが提供される。ローカルARキャッシュ16は、ローカルAR情報を提供する。示される実施形態では、クライアント12および14は、互いに通信し、ローカルARキャッシュ16と通信し、かつインターネット18と通信する。

クライアント12および14が通信する際に通常使うインターネット18のような、1つまたは複数のネットワークを介してアクセス可能な、ロクセルのデータベースを有する、特別ARサーバ20が提供される。たとえば、特別ARサーバは、たとえば、ジオコーディングされていない画像、関心地点(POI)の特定の画像などを扱うための、特別な機能を提供する、記述子データベースを有し得る。任意選択のアプリケーションサーバ22が、クライアント12および14上のARアプリケーションによる使用のために、提供され得る。

メインARサーバ30は、主要なAR能力を提供し、マスターARサーバ32、ARロクセルサーバ36〜40、および画像データベース42を含む。マスターARサーバ32は、クライアントが連絡を開始する際に使い得る、フロントエンドARサーバコンポーネントを提供する。ARロクセルサーバ36〜40は、ジオコーディングされロクセルに基づいた画像記述子を格納する、ARサーバコンポーネントのセットであり、画像データベースは、完全な画像(つまり、キーポイントだけではなく、画像全体にわたる、圧縮されたまたは圧縮されていない画像データ)のデータベースである。画像データベースは、ARロクセルサーバ36〜40のそれぞれ1つと一緒に配置されていてもよい、いくつかの物理デバイスに分散していてよい。

図1の実施形態では、フレキシブルなデータの体系化およびダウンロードモデルは、アプリケーションのニーズ、クライアントカメラの視界、および使用パターンに基づいて補強され得る。このモデルは、ロクセルに基づくデータの体系化に基本的に基づくが、その体系化に対して様々な改良を実現する。設計は、以下の指針、すなわち、様々なARアプリケーションの遅延を最小にすること、利用可能なワイヤレス帯域幅リソースの使用を最適化すること、画像データの提供者のためのフレキシブルなデータ体系化技法を提供すること、およびクライアントの電池の寿命に与える影響を最小にすることに、基づき得る。

システム10は、重複しない「ジオスクエア」セル領域に分割される、地球規模の地理座標系を使うことができる。「ジオスクエア」は、すべての辺が等しい物理的な距離に相当する正方形(たとえば、30×30m)のようなものである。これは、たとえば、メイデンヘッドロケータシステム(MLS)で使われるグリッドスクエアとは異なり、グリッドスクエアはむしろ、緯度および経度の大きさが等しくなるように分割した、地理的な四角形に相当する。グリッドスクエアは、地球上の任意の地点において、1度の緯度と2度の経度で囲まれる。その結果、グリッドスクエアは、地球の様々な部分で面積が変化することになり、グリッドスクエアの一部または多くは、その大きさを前提にすると、ロクセルとして考えるには適していない。説明される実施形態では、任意の多角形または重複するジオスクエアは、何ら価値を加えることなく設計を不必要に複雑にするものであり、したがってモデルの一部としては許可されない。

異なるデータの提供者は、異なるロクセルの大きさを使うことができるので、互換性の要件をロクセルの大きさについて設定する必要はない。述べられたように、異なるロクセルは、オブジェクトの密度または他のパラメータに基づいて、異なる大きさであってよい。カーネルは通常、3×3のロクセルを包含するが、これは、ロクセルの大きさ自体に応じて変化してもよい。たとえば、ロクセルの大きさがある閾値よりも小さく、モバイルデバイスのロケーションの平均の誤差が2つの隣接するロクセルの領域にわたることが許容される場合、カーネルは、5×5のロクセルを含む必要があり得る。

一般化すると、カーネルの面積は、π×R²/S²として動的に計算することができ、ここでRはロクセルの周囲の360度の視野の半径であり、Sはクライアントの現在のロクセルの各辺の長さである。等しくないロクセルの大きさが使われる場合、カーネルの面積の計算はより複雑であり、各々の隣接するロクセルの大きさを考慮する必要がある。簡単にするために、3×3のロクセルのカーネルの領域が本明細書では想定され、また、ロケーションの平均の誤差は1つの隣接するロクセルより大きくなることはなく、したがって誤差はカーネル内に保たれると想定する。30×30m²の大きさのロクセルは、最悪の場合のロケーションの精度誤差(たとえば50m)に対しても、上記を満たすことに留意されたい。したがって、カーネル中の画像データを使って検出を実行することができ、その後、ロクセルをより正確に決定することができる。

カーネルのロクセルへのマッピングが動的であることは、システムがどのようにプルーニングを処理するか、および、画像データベースがダウンロードに対してどのように最適化され得るかということにも、影響を与える。ロクセルをまたがるプルーニングは、キーポイントの全体的な優先順位付け、および、検出に必要な画像データの量の最小化という点で、利点をもたらし得る。しかし、データベース全体にわたってプルーニングを行うということは、照合がデータベース全体に対して行われたときしか、最適化が有意義にならないということを意味する。現実世界のARの画像データベースに対しては、これは現実的ではない。

したがって、可能な選択肢は、利用可能なデータをロクセルを基本としてプルーニングすること(すなわち、ロクセルをまたがるプルーニングはない)と、カーネルを基本としてプルーニングすること(ロクセルをまたがるプルーニングをいくらか認める)である。前者の場合、データは、何ら影響を与えることなく、必要に応じてロクセルごとにダウンロードされ得る。後者の場合、データが付加的にダウンロードされると、一部の最適化が失われる。つまり、新しいカーネルに対応する2つまたは3つの付加的なロクセルをダウンロードすると、カーネル内のロクセルにまたがるプルーニングによってもたらされた最適化が、完全には使われない。さらに、カーネルデータに基づいて捨てられたいくつかのキーポイントが、付加的なロクセルのダウンロードの状況において、今度は実際に関連があるものになり得る。照合の精度に応じて、そのようなキーポイントは、別々に管理され送信される必要があることがあり、ダウンロードモデルの複雑さが増す。現在は、カーネルに基づくプルーニングの手法によって、最適化または精度に明らかな改善がもたらされない限りは、付加的なダウンロードを認めるために、ロクセルに基づくプルーニングが有利であり得るように見える。しかし、いくつかの状況では、2つのプルーニングの手法が有利であり得る。

各ロクセルは、識別子と関連付けられた画像データを分類して検索するための識別子を有し、それぞれのロクセルへのロケーション情報の決定性のマッピングを可能にする。ロケーション情報は、たとえば、GPS、A-GPS、WiFi三角測量、または他の技法を介して取得され得る。ロケーションを取得するために使われる機構に関係なく、同じロクセルIDのマッピングが、所与のロケーションに対して取得されるべきである。屋内での測位技法における、大きく異なる特性および不正確さによって、屋内のロケーションはロクセルに簡単にはマッピングできないので、本明細書で説明されたロクセルに基づく体系化は、今のところ屋外の環境において最適である。当然、同様のマッピングの可能性がある屋内環境では、ここで概説された設計を使うこともできる。

ロクセル識別子の使用は、クライアントによるロクセルIDの自動的な計算を可能にする。それは、ロクセル識別子の使用によって、新しい画像データをいつ取得するか、およびどれだけのデータを取得するかを、クライアントが自動的に決定できるようになるからである。これによって、メッセージングをかなり節約することができ、転じて、ロケーションの更新をサーバに継続的に送る必要がなくなることで、電池の寿命を延ばすことができる。また、クライアントの正確なロケーションを常時サーバに開示する必要がなくなることで、クライアントに対してより良好なプライバシーも提供する。

現在、ロケーションデータの利用可能性は、プラットフォーム(Android対Windows(登録商標)、Mobile対iPhoneなど)によって大きく異なるように思われる。また、GPSデータの精度も、大きく異なるように思われる(1mから最悪の場合には50m)。したがって、グリッドモデルの標準化された定義が使われる。この定義は、グリッドスクエアなどによって囲まれた領域を決定するための、正規化された(緯度、経度)および互換性のあるアルゴリズムを提案する。処理において、異なるデータ提供者のためにロクセルの大きさまたはグリッドモデルを定義する際のあらゆる柔軟性が、失われる。そのため、この設計では、クライアントによってロクセルIDを決定するための、ハイブリッドな手法を考える。

したがって、所与のロケーションに対応するロクセルIDを得るために、ベクトル量子化技法がグリッドモデルに対して適用される。ロケーションは、(緯度、経度)の対で表現され、この対は、任意の屋外測位技法の少なくとも共通の基準である。グリッドモデルは、以下で詳細に説明される方式で、マスターARサーバ32によって決定される。各ロクセルの符号ベクトルも、マスターARサーバ32によって事前に計算される。符号ベクトルは、(緯度、経度)の対として表現され、所与のロクセルに存在するすべての(緯度、経度)の対の平均として選択され得る。マスターARサーバ32は、すべての符号ベクトルおよび対応するインデックスのリストを記憶する。「ロクセルID」と名付けられる符号ベクトルのインデックスは、ベクトルの(緯度、経度)パラメータのハッシュとして計算される。

Loxel ID (LID) = SHA1 (緯度、経度)

したがって、クライアント、たとえばクライアント12が初期化するとき、クライアント12は、マスターARサーバ32に連絡し、符号ベクトルのセットを取得する。このことは、クライアントの現在の(緯度、経度)パラメータを提供し、クライアントのロケーションの周りの符号ベクトルのセットを取得することによって行うことができる。これによって、コードブック全体のダウンロードが無駄であると見られる場合に、部分的なコードブックのダウンロードが可能になる。しかし、クライアントはまた、コードブック全体をダウンロードするように要求することができ、この場合、マスターARサーバ32は、符号ベクトルの完全なリストを送る。クライアントは、今後の使用のためにコードブックを記憶することができるが、コードブックは様々なデータ提供者によって異なることがあるので、ある特定のコードブックは、所与のマスターARサーバにしか有効ではないと考えるべきであることに、留意されたい。したがって、コードブックがクライアント12によってキャッシュされる場合、それは、照合を行うマスターARサーバ32に対して行われるべきである。

現在のロクセルを決定するために、クライアント12は、クライアントの現在の(緯度、経度)パラメータから最もユークリッド距離が近い、符号ベクトルを探す。クライアントが移動するに従って、クライアントは、そのユークリッド距離をローカルで計算し、ロクセルIDの変化を検出すると、または、アプリケーションの使用法に基づいて新しいデータが必要であることを検出すると、マスターARサーバ32に連絡することができる。したがって、この実施形態は、コードブックを得るためにマスターARサーバ32との初期の情報交換を必要とするが、サーバ側が最適なグリッドモデルを決定する際の柔軟性と、クライアント12に対する性能の改善およびプライバシーの保護の機会との両方を実現して、より多くのデータのためにマスターARサーバ32に連絡するのに適切な時間を決定する。

グリッドモデルを実現し、様々な画像要素に対するロクセルIDのマッピングを管理するために、マスターARサーバ32は、少なくとも以下の要素を記憶することができる。

対応するロクセルID(インデックス)を有する符号ベクトルのリスト。

ロクセルIDとARロクセルサーバIDとのマッピング。

1つの一次ARロクセルサーバおよび1つまたは複数の二次ARロクセルサーバ。

各ARロクセルサーバの動作可能時間。

ロクセルIDによってインデックスを付けられたARキャッシュ。

ロクセルID当たりの複製の数。

アクセスの人気度に基づく動的な変動。

ロクセルIDの人気度の測定基準。

ロクセルIDがある期間内にアクセスされる回数(キャッシングの閾値を決定するのに有用)。

隣接箇所の情報。

特定のロクセルIDに対応するカーネル領域についての情報。これは、通常はカーネル中の他のロクセルIDの集合体であり得る。

マスターARサーバ32は、これらに加えて他の要素も記憶してよい。

上記に加えて、実際のロクセルのデータベースは、ARロクセルサーバ36〜40に記憶される。ロクセルのデータベースは、様々な言語(たとえば、XML、SQLなど)で表されてよく、以下の要素を格納し得る。

ロクセルID。

個々の特徴記述子およびメタ特徴記述子を含む、特徴記述子。

記述子のランク。記述子のランクは、特定の特徴のクラスタサイズに基づいて計算され得る(より多くの同じオブジェクトの画像にその特徴が現れると、そのランクは高くなる)。他のランキング計算技法も使われ得る。たとえば、固有の照合能力を示すシングルトンの特徴も、高いランクを有し得る。

画像IDのリスト(すべての画像が画像データベース中のIDと関連付けられている必要がある)、特徴に対応する画像の座標のタプル(特徴の画像の座標は、地理的な一貫性の確認に有用である)、代替的な座標、高度。当然、リストに対するポインタがロクセルのデータベースで管理されてよく、実際のリストは別の位置(たとえば画像データベース)に記憶される。

それ自体が代替的なロケーションを有するオブジェクト(たとえばユーザ生成コンテンツ(UGC)ピクチャ)を、画像が表すのに使うインジケータ。代替的な座標が、画像中の実際のオブジェクトのロケーションを表すために存在し得る。

可能であれば、高度情報。高度情報は、様々なオブジェクトの視界の高度および相対的な高度に基づいて、異なる視界を決定するのに有用である。しかし、高度に基づく考慮のいくつかは非常に複雑であることがあり、たとえば、クライアントの高度、地球の曲率、POIの高度、視界領域における平均的な障害物などが、すべて寄与する要因である。

画像IDによってインデックスを付けられたPOIデータ。これは、別のPOIデータベース中の実際のデータへのポインタであってもよい。名前、住所、Universal Resource Identifier (URI)が、格納され得るPOI詳細情報の例である。

本明細書で説明される実施形態では、パンニングを可能にするためにクライアントが有効なカメラの視界に関して静止している大半の用途に対して、一般に、360度の視野を提供するロクセル情報が望ましい。しかし、一部の用途は、そのような広い視野を常に必要とはしないことがある。たとえば、ほとんどの携帯電話のカメラの視野は、70度以下である。モバイルARアプリケーションは通常、一回で数分の使用パターンと結びついていることがあり、場合によっては使用と使用の間に移動があり、有効なカメラの視界が連続的に利用可能ではないことがある。

ここでさらに参照する図2は、ロクセルセットの3つの異なるカーネル領域52、54、および56の図であり、それらのカーネル領域と関連付けられる視界領域を示す。カーネル領域52、54、および56はそれぞれ、K_(x,y)、K_(x+1,y+1)、およびK_(x',y')によって示され、カーネル領域56は、連続する次のカーネルである必要はないので、説明のためにK_(x',y')として一般化されている。

カーネル領域52、54、および56は、それぞれ、ロクセルL_(x,y)、L_(x+1,y+1)、およびL_(x',y')を中心とする。示されるように、カーネルは、クライアントの現在のロクセルに相当する所与のロクセルを中心とする、3×3のロクセル領域である。説明のために、カーネル52、54、および56はX-Y軸上に示され、これは上から見たものである。つまり、カーネル52の中心のロクセルL_(x,y)は、次のカーネル54の左下の角にあるロクセルL(_x-1,_y-1)にあり、カーネル54の中心のロクセルL_(x+1,y+1)は、カーネル56のロクセルL_(x'-1,y'-1)にある、などとなるように、カーネルは部分的に重複する。さらに、図2の例示では、クライアントの例示的な移動の方向が北東なので、カーネル52、54、および56は、上側かつ右側に進んでいるように見える。カーネルは、クライアントの移動に対応する任意の方向に進み得ることを、理解されたい。このことは、クライアントが移動するにしたがってダウンロードされるべきデータの量を考慮して、以下でさらに詳細に論じられる。

より具体的には、大半の携帯電話のカメラが対応する視野では、サーバから完全なカーネルに相当するデータをダウンロードするのは、通常は無駄である。したがって、高速な画像の検出および照合には、画像データをモバイルデバイスのRAMにロードするのが必要であることを考えると、照合を実行する関連する画像データの量は少ないのが好ましい。一方で、クライアントのARエンジン/アプリケーションがアクティブであり、画像データを処理できる限りは、画像データを付加的にダウンロードするのが望ましいことがある。このことは、ARアプリケーションがバックグラウンドで実行される実施形態では特に、課題となる。

したがって、ある例として、カーネルK_(x,y)52の中のL_(x,y)のロクセル位置にいる、図1のクライアント12のようなクライアントが、パンニングを許可されて、カーネルK_(x,y)52に対応する3×3のロクセル行列の画像データのすべてを、最初にダウンロードすることができる。クライアント12が北東に移動してカーネルK_(x,y)52のロクセルL(_x+1,_y+1)に入った状況では、カーネルK_(x+1,y+1)54のロクセルが関連するようになり、クライアント12が、カーネルK_(x+1,y+1)54の中心のロクセルL_(x+1,y+1)に位置するようになる。クライアント12がカーネル54のロクセルL_(x+1,y+1)に入ると、移動の方向とクライアントのカメラの視野に基づいて、画像データが付加的にダウンロードされる。たとえば、クライアントが北東に向かい続けている間は、クライアントは、180度の視野のために、ロクセルL_(x+1,y+2)、L_(x+2,y+2)、およびL_(x+2,y+1)を付加的にダウンロードすることができる。このことは、クライアントが再び静止し、方位に変換される有効なカメラの視界および予想される軌跡を有するようになるまで、続き得る。最終的には、図2の例ではクライアントは、カーネルK_(x',y')56の中心のロクセルL_(x',y')にある、カーネルK_(x+1,y+1)54のロクセルL_(x+2,y+2)で止まり、180度の視野のために、ロクセルL_(x'+2,y'+3)、L_(x'+3,y'+3)、およびL_(x'+3,y'+2)を付加的にダウンロードする。

ここでさらに参照する図3は、L_(x+1,y+1)に対応する視界領域および方位角θを示す、ロクセルセットの3つの異なるカーネル領域52、54、および56の図である。領域A_(θ,x+1,y+1)60は、焦点の中心がカーネル56のロクセルL_(x',y')である、カーネル52のL_(x+1,y+1)を中心とする視界領域を示し、方位はθ(θ≒45度として示されている)となり、180度の視野62の視界領域を再び想定する。より現実的な、70度の視界64によって、視界領域はロクセル1つだけに限定され、任意の所与の方位に対して、視界領域は最大でも2つのロクセルに限定される。

したがって、慎重なデータダウンロードの実施形態は、方位角に基づいた、または、有効な方位が利用可能ではない場合は移動の方向に基づいた、1つまたは2つだけのロクセルの付加的なデータのダウンロードによって実施され得る。デバイスが、有効なカメラの視界を伴って再び静止すると、より多くのデータをダウンロードすることができる。しかし、アプリケーションの種類に応じて、より多くのデータのダウンロードを許容してもよい。モバイルデバイスが移動しているときは、デバイスは有効なターゲットに向くことができないので、カメラの視界は無効である可能性が高いことに留意されたい。つまり、デバイスは、たとえばポケットに入れられ、または下を向いている可能性がある。

カーネル中の隣接するロクセルに対応するには、論理的には、可能な移動の方向は8つで十分である。移動の任意の所与の方向に対して、θは、方向線と、参照座標のx軸の正方向(たとえば、参照として真北が使われている)との間の角度であると、想定することができる。デバイスが静止し、カメラの視界が再び有効になったときは、ダウンロードする必要がある残りのロクセルを決定するために、より有意義なθが取得され得る。

したがって、360度の視野を想定すると、クライアント12が、カーネル52においてロクセルL_(x,y)からロクセルL_(x+1,y+1)に移動するとき、5つのロクセル(ロクセルL_(x,y+2)、L_(x+1,y+2)、L_(x+2,y+2)、L_(x+2,y+1)およびL_(x+2,y))のダウンロードが、カーネル54の完全な視界を保持するクライアント12において行われる。180度の視野では、必要なデータの量は3つのロクセル(ロクセルL_(x+1,y+2)、L_(x+2,y+2)、およびL_(x+2,y+1))に減り、70度の視野では、1つのロクセル(ロクセルL_(x+2,y+2))にさらに減る。

1つの実施形態は、デバイスが移動しているときには情報はダウンロードされないと想定し得る。しかし、そうすると、デバイスがL_(x',y')で再び静止したときに、8つのロクセルのダウンロードが発生する。したがって、クライアント12が移動するに従って、付加的なダウンロードを積極的に行うと、その時点で必要な新しいデータは、2つのロクセルにまで減らすことができる。付加的なダウンロードをより慎重に行うと、これは6つのロクセルになり得る。しかし、アプリケーションのニーズおよび使用モデルに基づいて、付加的なダウンロードは、所望のユーザ体験に対して最適となるように適合され得る。一般に、無駄なデータのダウンロードと、ARアプリケーションが再開されたときのよりシームレスな動作との間には、トレードオフがある。ローカルARサーバが利用可能であり、より高速なダウンロードのために後続のデータがローカルARサーバにプッシュされ得る場合には、慎重な付加的なダウンロードで十分であり得る。

1つの特徴が30バイト(圧縮を仮定して)であり、1つのオブジェクト(クラスタリングおよびプルーニングの後の5つの表示にわたった)に1000の特徴があり、1つのカーネルに5つのオブジェクトがある場合、1つのロクセル中のデータの量は約150kバイトである。したがって、1〜3個のロクセルの付加的なダウンロードでは、1.2〜3.6Mビットの付加的なデータが交換されることになる。

さらに、上で述べられたように、ロクセルは、ここでさらに参照される図4に示されるように、大きさが異なっていてもよい。示されるように、カーネル65は9個のロクセルを含み、各ロクセルは、それぞれのロクセルを特定する符号ベクトルを格納する。特定のロクセルの大きさは、いくつかの要因に依存する。したがって、たとえば、ARアプリケーションは、都市のような密集した領域などのより情報が多くより狭いロクセル、または、たとえば砂漠領域のような情報が少なくより広いロクセルを、ダウンロードすることができる。ロクセルの大きさはまた、関心のある領域で利用可能なGPSの精度などのような、他の要因を用いて決められてもよい。

示されるように、各ロクセルは、符号ベクトル、たとえば緯度、経度の対によって特定される。特定のロクセルと関連付けられる特定の緯度、経度の対は、いくつかの方法で求められ得る。たとえば、緯度、経度の対は、ロクセルに基づくデータの体系に対してベクトル量子化を使うことで求められ、ロクセルごとに固有の符号ベクトルを提供することができる。これによって、特定の地理的な領域における緯度、経度の対を、クライアントがダウンロードできるコードブックの中に、並べられるようになる。コードブック中のロクセル識別子から、クライアント12は、マスターARサーバ32に対する継続的なロケーションの更新を必要とせずに、自身が位置しているロクセルを自己計算することができる。これによって、電池の電力が節減され、プライバシーが守られる。ロクセルの識別は、たとえば、各ロクセルのロケーションが、たとえばロクセル中に存在するすべての(緯度、経度)の対の平均として選択された(緯度、経度)の対の形の符号ベクトルとして表される、ベクトル量子化技術を使って、行われ得る。ロクセル中に存在する(緯度、経度)の対は、たとえば、ロクセル内に位置する各関心地点と関連付けられた(緯度、経度)の対を含み得る。当業者は、符号ベクトル、(緯度、経度)の対などのような、固有のロクセル識別子を生成するための他の方法を、認識するだろう。

所望のロクセルのコードブックを決定するために、クライアントは、クライアントの現在の(緯度、経度)ロケーションから最もユークリッド距離が近い、符号ベクトルを探す。クライアント12が移動すると、クライアント12は、近くのロクセルへのユークリッド距離をローカルで計算し、ロクセルIDの変化を検出すると、または、アプリケーションの使用法に基づいて新しいデータが必要であることを検出すると、マスターARサーバ32に連絡することができる。したがって、このモデルは、初期のコードブックを得るためにマスターARサーバ32との初期の情報交換を必要とするが、マスターARサーバ32側が最適なグリッドモデルを決定する際の柔軟性と、クライアント12に対する性能の改善およびプライバシーの保護の機会との両方を実現して、より多くのデータのためにマスターARサーバ32と連絡するのに適切な時間を決定する。同時に、このモデルは、クライアントが、どのロクセルをダウンロードするかを自身で決定できるようにする。

適切なデータのダウンロードの要件は、具体的なARの用途に応じて変わり得るが、以下のリストは、ARの用途の分類の一部に対して何が適切であり得るかについての、予備的な分析を与えるものである。

ナビゲーション/地図

適度に高速な応答時間が必要である。

パンニング(少なくとも、移動を伴う連続的なパンニング)はさほど重要ではなくてもよい。

視野および移動の方向に基づく付加的なデータのダウンロードは、この用途の分類に対して最適であると思われる。

データのダウンロードのための追加の基準は、所望の行き先および、現在のユーザのロケーションに対する行き先のロケーションであり得る。

パンニングが必要であるときに、より多くのデータをダウンロードする必要があり得る。

ソーシャルネットワーキング

許容可能なリアルタイムとは言えない応答時間。

パンニングは必要であり得る。

カメラが有効ではないときは、視野および移動の方向に基づく、データの慎重な付加的なダウンロードが、許容可能である可能性が高い。

有効なカメラの視界がパンニングのために利用可能であるときは、より多くのデータをダウンロードする必要があるが、応答時間の増加はさほど問題ではない可能性が高い。

ゲーム

高度にリアルタイムな応答時間が必要である。

パンニングは、ある程度必要であり得る(180度で十分である可能性が高い)。

高速な応答での少なくとも180度の視野を考慮すると、付加的なダウンロードはより積極的である必要がある。

使用パターンに多くの様々なものがあり、ゲームの間は連続的に有効なカメラの視界を提供するので、積極的な付加的なダウンロードのモデルが、データの無駄なダウンロードを伴うことなく使われ得る。

いくつかの実施形態では、マスターARサーバ32は、無状態の動作モードを有することが想定され、無状態の動作モードでは、マスターARサーバ32は、複数のトランザクションにわたるクライアントごとの状態をまったく保持しない。したがって、各トランザクションは自己完結型であり、正確な実行に必要なすべてのパラメータを格納している。これによって、サーバがクラッシュしてもシステムが正しく機能することが可能になり、ロクセルARサーバ36〜40にまたがるシームレスな移行も可能にする。以下は、ローカルARサーバが関与する場合と、関与しない場合の、例示的な呼の流れを示す。示されるパラメータは、たとえば、RESTまたはSOAPのような、プロトコルフレームワークに含まれるXMLデータであり得る。

ローカルARサーバが示されない例示的な呼の流れ70が、ここでさらに参照する図5に示される。呼の流れ70は、クライアント12が、要求Init_Req(lat,long)によって、コードブックのためにのマスターARサーバ32に対して初期化を行うことを示す。この場合、クライアント12は、現在のロケーション(緯度、経度)をマスターARサーバ32に送り、サーバは、そのロケーションの周りの部分的なコードブックInit_Resp(codebook)によって応答する。代替的には、クライアント12は、ロケーションパラメータを何ら送ることなくコードブック全体を要求し、マスターARサーバ32は、符号ベクトルの完全なリストによって応答する。

次いでクライアント12は、情報要求メッセージInfo_Req(LID L1, Full Kernel, θ, direction, LID_prev=none)を、自身のロクセルIDとともに送り、LIDに対応する完全なカーネルに対応する画像データを要求する。この画像データは、適宜画像データの方位および移動の方向についての情報を含み得るが、完全なカーネル情報を要求した場合には、これらの情報はさほど関連がない。クライアントは、前のLIDを「none」に設定することによって、これが最初の要求であることを示す。このことは、クライアントがサーバに初めて連絡したとき、または、何らかの理由で、前にダウンロードされたすべてのロクセルを関連がないと見なすので、データのリセットを望むときに、起こり得る。

情報応答メッセージInfo_Resp(LID,Loxel AR Srv List)の一部として、マスターARサーバ32は、要求されたカーネル中の各ロクセルに対応する画像データを取得するために、どのロクセルARサーバ36〜40に連絡すべきかをクライアント12に示す、(ロクセルID、ロクセルARサーバID)の対のリストを、クライアント12に送る。そしてクライアント12は、関連するロクセルARサーバ36〜40の各々によって、データ要求Data_Req(LID List)およびデータ応答Data_Resp(Loxel Data)の交換を実行し、自身が必要とする画像データを取得する。ロクセルARサーバ36〜40は、要求されたLIDに対応するロクセルのデータベースからのデータを返す。得られたロクセルのデータは、ロクセル中の関連するPOIについての情報を含む。用途およびユーザ対話に応じて、クライアント12は、POIデータ要求メッセージPOI_Data_Req(POI Name)によって1つまたは複数のPOIサーバ20に連絡することを選択でき、POIについての追加の情報を要求する。要求の送信先のPOIサーバ20は、要求されたPOIデータPOI_Data_Resp(POI Data)によって応答する。

LIDの変化を検出すると、クライアント12は、マスターARサーバ32との別の情報交換を実行し、クライアント12がダウンロードを望む新しいロクセルに対応するロクセルARサーバリストを要求することができる。示されるメッセージングは、要求とともに示された方位および/または移動の方向に対応する、部分的なカーネル要求Info_Req(LID,Partial,θ,direction,LID_prev=L1)を示す。加えて、クライアント12は、前のLIDをマスターARサーバ32に提示するので、マスターARサーバ32は、すでにダウンロードされたデータを除外することを知っている(部分的なカーネルが以前にダウンロードされている場合には、前の方位および/または移動の方向が提示されるべきであり、あるいは、すでにダウンロードされたロクセルのリストが含まれ得る)。そしてマスターARサーバ32は、要求された情報を伴うData_Resp(Loxel Data)によって応答する。そしてクライアント12は、前と同じ手順をたどり、ロクセルARサーバ36〜40からロクセルデータをダウンロードする。

ローカルARサーバ20による呼の流れ80の例が、ここでさらに参照する図6に示される。呼の流れ80は、ローカルARサーバ20'の追加を除いて、図5を参照して上で説明された呼の流れ70と実質的に同じであり、ローカルARサーバ20'は、図1に示される特別ARサーバ20の1つであり得る。呼の流れ80は、関連する情報がクライアント12により近いロケーションで利用可能になると、クライアント12がローカルARサーバ20'にリダイレクトされ得る機構を示す。

呼の流れ80は、クライアント12が、要求Init_Req(lat,long)によって、コードブックのためのマスターARサーバ32に対して初期化を行うことを示す。この場合、クライアント12は、現在のロケーション(緯度、経度)をマスターARサーバ32に送り、サーバは、そのロケーションの周りの部分的なコードブックInit_Resp(codebook)によって応答する。代替的には、やはり、クライアント12は、ロケーションパラメータを何ら送ることなくコードブック全体を要求し、マスターARサーバ32は、符号ベクトルの完全なリストによって応答する。

次いでクライアント12は、情報要求メッセージInfo_Req(LID L1, Full Kernel, θ, direction, LID_prev=none)を、自身のロクセルIDとともに送り、LIDに対応する完全なカーネルに対応する画像データを要求する。この画像データは、適宜画像データの方位および移動の方向についての情報を含み得るが、完全なカーネル情報を要求した場合には、これらの情報はさほど関連がない。クライアントは、前のLIDを「none」に設定することによって、これが最初の要求であることを示す。このことは、クライアントがサーバに初めて連絡したとき、または、何らかの理由で、前にダウンロードされたすべてのロクセルを関連がないと見なすので、データのリセットを望むときに、起こり得る。

情報応答メッセージInfo_Resp(LID,Loxel AR Srv List)の一部として、マスターARサーバ32は、要求されたカーネル中の各ロクセルに対応する画像データを取得するために、どのロクセルARサーバ36〜40に連絡すべきかをクライアント12に示す、(ロクセルID、ロクセルARサーバID)の対のリストを、クライアント12に送る。

呼の流れ80において、マスターARサーバ32はさらに、クライアント12のロクセルデータの予測される必要性に基づいて、ローカルARサーバ20'においてキャッシングを開始する。たとえば、クライアントの最初の情報要求に応答して、マスターARサーバ32は、Replicate_Req(LID list,Local AR Server)によって、適切なロクセルARサーバ36〜40に対して、ローカルARサーバ20'におけるあるLIDに対応するロクセルデータを複製するように指示する。次いで適切なロクセルデータが、Data_Puch_Req(LID List Data)によって、ローカルARサーバ20'にプッシュされる。ローカルARサーバ20'は、Data_Push_Resp(Success)によって応答し、複製されたロクセルデータの受信を確定する。

ロクセルの変化の後に、クライアントが、Info_Req(LID,Partial,θ,direction,LID_prev=L1)によってマスターARサーバ32に連絡すると、マスターARサーバ32は、Info_Resp(LID,Local AR Srv)によって、クライアントをローカルARサーバ20'にリダイレクトする。そしてクライアントは、データ要求Data_Req(LID List)をローカルARサーバ20'に送ることによって、ロクセルデータを受信する。そしてローカルARサーバ20'は、要求されたデータを伴うData_Resp(Loxel Data)によって応答する。

ローカルARサーバ20'は、たとえば、古典的なDNS方式の識別機構を使って、または他の適切な機構を使って、識別され得る。しかし、ローカルARサーバ20'が何らかの特定の媒体(WiFiのような)を通じてクライアントにアクセス可能である場合、クライアントがより高速なリンクを通じてデータを取得できるような接続パラメータを有することが助けとなる。

図1のシステム10のようなARシステムとともに動作できるモバイルデバイス12のような、モバイルデバイス(クライアントデバイスであってよい)のある実施形態のブロック図が、図7に示される。モバイルデバイス12は、たとえば、既知のGPSまたは他の測位技法によってその現在位置を測定するための、測位エンジン92を含む。測位エンジン92は、すべての測位関連の処理を実行する必要はない。たとえば、測位エンジン92は、1つまたは複数の衛星または地上の擬似距離を示す情報を求め、次いで擬似距離の情報をネットワークリソースに転送して、擬似距離を使って位置を測定することができる。その後モバイルデバイス12は、ネットワークから位置情報(たとえば、緯度および経度)を受信することができる。測位エンジン92は、プロセッサ16、メモリ15、および/または、送受信機のようなモバイルデバイス12の1つもしくは複数の他のモジュールと、通信していてよい。

モバイルデバイス12はさらに、コードブック情報94を含む、メモリ15を含む。コードブック情報94は、それぞれの地理的な領域と関連付けられたロクセルのロケーションベクトルのような、ロクセル識別子を含む。図1に示されるようなシステムでは、コードブック情報94は、マスターARサーバ32から取得され得る。たとえば、それぞれの地理的な領域と関連付けられる複数のロクセルのロケーションベクトルは、マスターARサーバ32のような1つまたは複数のネットワークリソースから取得され得る。モバイルデバイス12は、本明細書で概説された、説明された機能を実施するための、プロセッサ16を含み得る。たとえば、プロセッサ16は、現在位置情報と、複数のロクセルと関連付けられた記憶されたロケーションベクトルとを入手し、現在位置およびロケーションベクトルに基づいて、ロクセルのセットを特定するように構成され得る。複数のロクセルのセットは、現在位置が位置する少なくとも初期のロクセルを含む。マスターARサーバ32からアップロードされ得る設定情報98(ロクセルのセットと関連付けられたAR情報)は、メモリ15に記憶され得る。

モバイルデバイス12の位置が確定されると、プロセッサ16は、モバイルデバイス12が初期ロクセルの外側に移動したかどうかを判定するように構成され得る。プロセッサ16はさらに、モバイルデバイス12の移動の方向および/または方位に基づいて、モバイルデバイス12が初期ロクセルの外側に移動した場合にアップロードすべき、追加のロクセルを特定するように構成され得る。追加のロクセルが特定されると、モバイルデバイス12は、特定された追加のロクセル99(特定された追加のロクセルと関連付けられるAR情報)のアップロードを開始するように構成され得る。モバイルデバイス12の方位を判定するために、モバイルデバイス12はカメラ106を備えてよく、カメラ106は、モバイルデバイス12の内部にあっても外部にあってもよい。カメラ106は、特定の視野108を有し、上で述べられたように、視野108は、モバイルデバイス12があるロクセルから次のロクセルに移動するに従って、ダウンロードすべき追加のロクセルの数を決定するために、使われ得る。また、メモリ15は、1つまたは複数のARアプリケーションに関連する情報、たとえば、拡張現実機能を提供するための命令および/またはデータを、記憶することができる。

「モバイルデバイス」とは、任意の種類のモバイルデバイス、たとえば、コードレス電話、携帯電話、パーソナル通信システム(PCS)電話、衛星などを介して通信する電話、または他の種類のワイヤレス電話を含む、ワイヤレス電話のような、ワイヤレスデバイスを指す。モバイルデバイスはまた、トランシーバ、または他の種類の通信送受信機、ワイヤレスアクセスを有する携帯情報端末、ワイヤレスアクセスを有するノートブックコンピュータなどのような、双方向の無線機であってもよい。モバイルデバイスは、関連する内部カメラまたは外部カメラと、画像表示デバイスとを有する。少なくとも1つの拡張現実アプリケーションが、本明細書で説明されたモバイルデバイス上で実行されていることが想定されるので、「モバイルデバイス」および「クライアント」という用語は、交換可能に使われる。

図7を参照して説明された機能は、いくつかの方法で実装され得ることに留意されたい。たとえば、プロセッサ16は、測位エンジン92のためにいくつかの機能を提供することができる。一例では、プロセッサ16は、支援データを処理することができ、擬似距離データを処理して1つまたは複数のネットワークリソースに送ることができ、受信されたロケーション情報を処理することができ、または、測位を支援する他の処理を行うことができる。プロセッサ16は単一のユニットであってよく、または処理機能は、複数のユニットによって実行されてもよい。同様に、メモリ15は単一のユニットとして示されるが、情報は、モバイルデバイス12の様々なモジュールに記憶されてもよい。

一実装形態では、図7のデバイス12のようなモバイルデバイスは、以下のように、1つまたは複数のARアプリケーションのためのデータをフレキシブルにダウンロードすることができる。本開示では、固有の符号ベクトルが、特定のロクセルと関連付けられ得る。モバイルデバイス12は、位置情報およびロクセル情報が「復号」され得るように、メモリ15にコードブック情報94を記憶することができる。つまり、モバイルデバイス12の現在位置を示す位置情報を入手したことに応答して、モバイルデバイス12は、コードブック情報94を入手して、現在位置に対応する特定のロクセル識別子を求めることができる。特定のロクセル識別子が得られると、そのロクセルと関連付けられるAR情報を入手して、1つまたは複数のARアプリケーションにおいて使うことができる。

いくつかの実装形態では、ロクセルの大きさはフレキシブルであってよい。モバイルデバイス12は、ロクセルの大きさ(および/または、帯域幅、メモリ、ARの必要性などのような他の要因)に応じて、より多数または少数のロクセルから情報を記憶するように構成され得る。このことは、一部の従来のシステムと比べて、大きな利点をもたらし得る。情報が密集している領域では、標準的な30m×30mのロクセルの大きさではなく、10m×10mのようなロクセルの大きさが使われ得る。標準的なロクセルのためのダウンロード情報が、モバイルデバイス12が利用可能なリソースに負荷をかける場合、またはそれを超える場合、モバイルデバイス12は、1つまたはいくつかのより小さなロクセルのためのAR情報をダウンロードできてよい。本開示はまた、方位および/または移動の方向を用いて、ロクセル情報をダウンロードするための技法を提供し、これはさらなる利益をもたらし得る。本明細書では、AR情報の「密度」は、単位領域あたりのARの情報の量を指す。

いくつかの実装形態では、モバイルデバイス12は、メモリ15中の複数のロクセルと関連付けられたロクセル識別子情報を示す、コードブック情報94を記憶するように構成される。モバイルデバイス12は、現在位置を示す現在位置情報を求めることができ、たとえば、モバイルデバイス12の測位エンジン92は、モバイルデバイス12の位置を測定することができ、または、1つまたは複数の測位衛星への擬似距離のような、位置を測定するのに必要な何らかの情報を求めることができる。モバイルデバイス12において位置が測定されない場合、位置情報をネットワークリソースに送信し、位置を測定してモバイルデバイス12に位置情報を返信することができる。多くの測位技法、たとえば、衛星測位(モバイルベースの、モバイル支援された、またはスタンドアロンの)、地上測位(たとえば、Advanced Forward Link Trilateration、WiFi測位など)、さらに、異なる技法の組合せ(ハイブリッド技法)を、使うことができる。

モバイルデバイス12は、記憶されたコードブック情報94を入手して、初期ロクセルのためのロクセル識別子情報を求めることができる。たとえば、ロクセル識別子情報は、ロクセルの及ぶ地理的な領域に含まれるロケーションを示すことができ、初期ロクセルは、その識別子がモバイルデバイス12の現在位置に最も近い(たとえば距離が最小の)ロクセルとして、選択され得る。地理的な領域に含まれるロケーションは、緯度および経度によって示され得る。

いくつかの実施形態では、モバイルデバイス12は、現在位置情報の少なくとも一部を、送信機(図示せず)を用いて1つまたは複数のネットワークリソースに送信することができる。モバイルデバイス12は、それに応答して、受信機(図示せず)を用いて複数のロクセルと関連付けられるAR情報を受信することができる。当然、送信機能と受信機能の両方が、送受信機において提供されてもよい。複数のロクセルが、現在位置情報の少なくともいくつかを用いて選択される。いくつかの実施形態では、モバイルデバイス12は、ダウンロードされるべきロクセルと関連付けられたロクセル識別子を求めることができ、ダウンロードされるべきロクセルに対する要求を送信することができる。コードブック情報94を入手することができ、少なくとも1つのロクセル識別子は、モバイルデバイス12の現在位置に基づいて選択され得る。少なくとも1つのロクセル識別子はまた、現在のカメラの視界、ARアプリケーションと関連付けられる使用パターン、モバイルデバイス12の方位についての情報、および/または、モバイルデバイス12の動きについての情報(移動の方向のような)に基づいて、選択されてもよい。様々な実施形態において、カメラの視野は約70度(たとえば65度と75度の間)であってよく、約180度(たとえば、175度と185度の間)であってもよい。他の実施形態では、異なる角度の視野が使われてもよい。

モバイルデバイス12は、測位情報を入手して、現在のロクセルが及ぶ地理的な領域の外側の位置に移動したかどうかを判定することができる。外側の位置に移動した場合、モバイルデバイス12は、コードブック情報94を入手して、ダウンロードすべき追加のロクセルを決定することができる。

いくつかの実施形態では、ARアプリケーションのための命令およびデータはメモリ15に記憶されてよく、本技法は、プロセッサ16を用いて、ARアプリケーションのための命令を実行するとともに、実行されてよい。

本明細書で説明される方法は、用途に応じて様々な手段によって実施することができる。たとえば、これらの方法は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実施され得る。ハードウェア実装形態の場合、処理ユニットは、本明細書で説明される機能を実行するように設計された、1つもしくは複数の特定用途向け集積回路(ASIC)、デジタルシグナルプロセッサ(DSP)、デジタルシグナルプロセシングデバイス(DSPD)、プログラマブル論理デバイス(PLD)、フィールドプログラマブルゲートアレイ(FPGA)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、他の電子ユニット、またはそれらの組合せ内で実装され得る。本明細書では、「制御論理回路」という用語は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの組合せによって実装された論理回路を包含する。

ファームウェアおよび/またはソフトウェア実装形態の場合、これらの方法は、本明細書で説明される機能を実行するモジュール(たとえば、プロシージャ、関数など)によって実施され得る。命令を有形に具現化するいずれの機械可読媒体も、本明細書で説明される方法の実施において使用され得る。たとえば、ソフトウェアコードは、メモリに記憶され、処理ユニットによって実行され得る。メモリは、処理ユニット内に実装されてもよく、または処理ユニットの外部に実装されてもよい。本明細書で用いられる「メモリ」という用語は、長期メモリ、短期メモリ、揮発性メモリ、不揮発性メモリ、または他の記憶デバイスのいずれかの種類を指し、特定のメモリの種類またはメモリの数には限定されず、あるいはメモリが格納される媒体の種類に関して限定されない。

ファームウェアおよび/またはソフトウェアで実装される場合、機能は、コンピュータ可読媒体上に1つもしくは複数の命令またはコードとして記憶され得る。この例には、データ構造によって符号化されたコンピュータ可読媒体、およびコンピュータプログラムによって符号化されたコンピュータ可読媒体が含まれる。コンピュータ可読媒体は製造物品の形態をとり得る。「コンピュータ可読媒体」という語句は、物理的なコンピュータ記憶媒体を含み、一時的な伝播信号は指さない。記憶媒体は、コンピュータによってアクセスされ得る任意の使用可能な媒体であってよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または、所望のプログラムコードを命令もしくはデータ構造の形で記憶するのに使用することができ、かつコンピュータからアクセスすることのできる任意の他の媒体を含んでよく、本明細書で使用されるディスク(diskおよびdisc)には、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フレキシブルディスク、およびブルーレイディスクが含まれ、ディスク(disk)は通常、データを磁気的に再生し、一方、ディスク(disc)はデータをレーザによって光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含めるべきである。

命令および/またはデータは、コンピュータ可読媒体上に記憶されるだけでなく、通信装置に含まれる伝送媒体上の信号として提供されてもよい。たとえば、通信装置には、命令およびデータを示す信号を有する送受信機を含めてもよい。命令およびデータは、1つまたは複数のプロセッサに、特許請求の範囲で概説された機能を実施させるように構成される。すなわち、通信装置は、開示する機能を実行するための情報を示す信号をもつ伝送媒体を含む。第1の時間において、通信装置中に含まれる伝送媒体は、開示される機能を実行するための情報の第1の部分を含んでもよく、一方、第2の時間において、通信装置中に含まれる伝送媒体は、開示される機能を実行するための情報の第2の部分を含んでもよい。

本開示は、Wi-Fi/WLANまたは他のワイヤレスネットワークとともに実装され得る。Wi-Fi/WLAN信号に加えて、ワイヤレス局/移動局はまた、本明細書では各々全般に衛星測位システム(SPS)またはGNSS(全地球的航法衛星システム)と呼ばれる、全地球測位システム(GPS)、Galileo、GLONASS、NAVSTAR、QZSS、これらのシステムの組合せによる衛星を用いるシステム、または将来開発される任意のSPSの形態であり得る、衛星からの信号を受信することもできる。本開示はまた、擬似衛星とともに、または、擬似衛星を含むシステムの組合せとともに、実装され得る。本開示はまた、フェムトセルとともに、または、フェムトセルを含むシステムの組合せとともに、実装され得る。

本開示は、ワイヤレスワイドエリアネットワーク(WWAN)、ワイヤレスローカルエリアネットワーク(WLAN)、ワイヤレスパーソナルエリアネットワーク(WPAN)などのような、様々なワイヤレス通信ネットワークとともに実装され得る。「ネットワーク」および「システム」という用語は、しばしば互換的に使用される。「位置」および「ロケーション」という用語は、しばしば互換的に使用される。WWANは、符号分割多元接続(CDMA)ネットワーク、時分割多元接続(TDMA)ネットワーク、周波数分割多元接続(FDMA)ネットワーク、直交周波数分割多元接続(OFDMA)ネットワーク、シングルキャリア周波数分割多元接続(SC-FDMA)ネットワーク、Long Term Evolution(LTE)ネットワーク、WiMAX(IEEE802.16)ネットワークなどであり得る。CDMAネットワークは、cdma2000、広帯域CDMA(W-CDMA)などのような、1つまたは複数の無線アクセス技術(RAT)を実装することができる。cdma2000は、IS-95、IS-2000、およびIS-856規格を含む。TDMAネットワークは、Global System for Mobile Communications(GSM(登録商標))、Digital Advanced Mobile Phone System(D-AMPS)または何らかの他のRATを実装することができる。GSM(登録商標)およびW-CDMAは、「第3世代パートナーシッププロジェクト」(3GPP)という名称の組織からの文書で説明される。cdma2000は、「第3世代パートナーシッププロジェクト2」(3GPP2)という名称の組織からの文書で説明される。3GPPおよび3GPP2の文書は、公に利用可能である。WLANは、IEEE 802.11xネットワークでよく、WPANは、Bluetooth(登録商標)ネットワーク、IEEE 802.15x、または何らかの他のタイプのネットワークでよい。本技法はまた、WWAN、WLAN、および/またはWPANの任意の組合せとともに実装され得る。

「例」または「例示的な」という語は、「事例、例示、特質、または他の特性である」ことを意味するために使われる。本明細書で「例」および/または「例示的」として説明されるいかなる実施形態も、必ずしも他の実施形態よりも好ましいまたは有利であると解釈すべきではない。

本発明は、ある程度の具体性を伴って説明され例示されたが、本開示は単に例示として行われ、部分の組合せおよび配置に対する多くの変更が、以下で特許請求されるような本発明の趣旨および範囲から逸脱することなく、講じられてもよいことを理解されたい。

12 クライアント
16 ローカルARキャッシュ
18 インターネット
20 特別ARサーバ
22 アプリケーションサーバ
30 メインARサーバ
32 マスターARサーバ
36 ARロクセルサーバ
42 画像データベース
52 カーネル領域
92 測位エンジン
94 コードブック情報
98 設定情報
99 追加のロクセル
106 カメラ

Claims (56)

1. 拡張現実(AR)モデルと関連付けられた命令およびデータを記憶し、AR情報の1つまたは複数のロクセルを記憶するためのメモリと、
   前記ARモデルと関連付けられた命令を実行するためのプロセッサと、
   関連するカメラの視界を有するカメラと
   を含む、クライアントデバイスであって、前記クライアントデバイスが、AR情報の1つまたは複数の追加のロクセルに対する要求を生成するように構成され、前記追加のロクセルが、前記クライアントデバイスの現在位置を示す情報と、現在のカメラの視界を示す情報、ARアプリケーションと関連付けられる使用パターンを示す情報、および前記クライアントデバイスの移動を示す情報からなる群から選択される少なくとも1つのパラメータとを用いて選択される、クライアントデバイス。
2. AR情報の前記1つまたは複数のロクセルが、ロクセル識別子と各々関連付けられ、前記メモリがさらに、複数のロクセル識別子を含むコードブック情報を記憶することになる、請求項1に記載のクライアントデバイス。
3. 前記メモリがさらに、複数のロクセルの大きさを処理するための命令を記憶することになる、請求項2に記載のクライアントデバイス。
4. 前記クライアントデバイスが、第1の大きさを有するAR情報の1つまたは複数の追加のロクセルを、第1の時点において要求し、さらに、第2の大きさを有するARの情報の1つまたは複数の追加のロクセルを、第2の時点において要求するように構成される、請求項3に記載のクライアントデバイス。
5. 前記第1の大きさが前記第2の大きさより小さく、前記第1の大きさの前記ロクセルのAR情報の密度が、前記第2の大きさの前記ロクセルのAR情報の密度よりも高い、請求項4に記載のクライアントデバイス。
6. 前記ロクセル識別子の各々が、ロクセル符号ベクトルを含む、請求項2に記載のクライアントデバイス。
7. 前記クライアントデバイスが、前記コードブック情報を入手して、前記クライアントデバイスの前記現在位置からのユークリッド距離が最も近い、ロクセル符号ベクトルを特定することによって、現在のロクセルを特定するように構成される、請求項6に記載のクライアントデバイス。
8. 前記クライアントデバイスが、前記クライアントデバイスの最新の位置を検出したことに応答して、AR情報の1つまたは複数の追加のロクセルに対する要求をさらに生成するように構成される、請求項7に記載のクライアントデバイス。
9. 前記クライアントデバイスがさらに、前記コードブック情報を入手して、前記最新の位置からのユークリッド距離が最も近いロクセル符号ベクトルを特定することによって、前記1つまたは複数の追加のロクセルを特定するように構成される、請求項8に記載のクライアントデバイス。
10. AR情報のカーネルへと体系化されたARデータを記憶するメモリであって、AR情報の各カーネルが、AR情報の複数のロクセルを含み、前記ロクセルの地理的な領域を示すロクセル識別子と関連付けられ、前記ARデータが、第1の大きさの少なくとも1つのロクセルと、第2の異なる大きさの少なくとも1つのロクセルとを含む、メモリを含む拡張現実(AR)装置であって、
    前記AR装置が、コードブック情報をクライアントデバイスに送信するように構成され、前記コードブック情報が、前記複数のロクセルの少なくとも一部のロクセル識別子情報を含む、AR装置。
11. 前記AR装置がさらに、追加のロクセルに対するクライアントデバイスからの要求を入手し、前記要求に応答して、前記追加のロクセルを前記クライアントデバイスに送信するように構成される、請求項10に記載のAR装置。
12. 前記第1の大きさが前記第2の大きさより小さく、前記第1の大きさの前記少なくとも1つのロクセルに含まれる前記AR情報の密度が、前記第2の大きさの前記少なくとも1つのロクセルに含まれる前記AR情報の密度よりも高い、請求項10に記載のAR装置。
13. 前記ロクセルの地理的な領域を示す前記ロクセル識別子が、前記ロクセルの前記地理的な領域に含まれるロケーションの緯度および経度を示す情報を含む、請求項10に記載のAR装置。
14. クライアントデバイスを用いるための方法であって、前記クライアントデバイスにおいて、複数のロクセルと関連付けられるロクセル識別子情報を示す、コードブック情報を記憶するステップと、
    前記クライアントデバイスの現在位置を示す、現在位置情報を求めるステップと、
    前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記現在位置と関連付けられる初期ロクセルのロクセル識別子情報を求めるステップと
    を含む、方法。
15. 前記クライアントデバイスの前記現在位置を示す、現在位置情報を求める前記ステップが、衛星測位、支援された衛星測位、および地上測位からなる群から選択された1つまたは複数の測位技法を用いて、前記現在位置情報を求めるステップを含む、請求項14に記載の方法。
16. 前記現在位置情報の少なくとも一部を1つまたは複数のネットワークリソースに送信し、それに応答して複数のロクセルと関連付けられるAR情報を受信するステップをさらに含み、前記複数のロクセルが、前記現在位置情報の少なくとも一部を用いて選択される、請求項14に記載の方法。
17. ダウンロードされるべきロクセルと関連付けられたロクセル識別子を求め、前記ダウンロードされるべきロクセルに対する要求を送信するステップをさらに含む、請求項14に記載の方法。
18. ダウンロードされるべきロクセルと関連付けられたロクセル識別子を求めるステップが、前記コードブック情報を入手し、前記クライアントデバイスの前記現在位置と、現在のカメラの視界を示す情報、ARアプリケーションと関連付けられる使用パターンを示す情報、および前記クライアントデバイスの移動を示す情報からなる群から選択される1つまたは複数のパラメータとに基づいて、少なくとも1つのロクセル識別子を選択するステップを含む、請求項17に記載の方法。
19. 前記クライアントデバイスが、前記初期ロクセルと関連付けられる地理的な領域の外側の最新の位置に移動したかどうかを、判定するステップと、
    前記クライアントデバイスが、前記初期ロクセルと関連付けられる前記地理的な領域の外側の最新の位置に移動した場合に、前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求めるステップと、
    前記1つまたは複数の異なるロクセルと関連付けられるAR情報を要求するステップと
    をさらに含む、請求項14に記載の方法。
20. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求めるステップが、前記クライアントデバイスの移動の方向に基づいて、前記1つまたは複数の異なるロクセルを特定するステップを含む、請求項19に記載の方法。
21. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求める前記ステップが、前記クライアントデバイスの方位に基づいて、前記1つまたは複数の異なるロクセルを特定するステップを含む、請求項19に記載の方法。
22. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求める前記ステップが、前記クライアントデバイスと関連付けられるカメラの視野に基づいて、前記1つまたは複数の異なるロクセルを特定するステップを含む、請求項19に記載の方法。
23. 前記カメラの前記視野が、65度から75度の範囲に含まれる、請求項22に記載の方法。
24. 前記カメラの前記視野が、175度から185度の範囲に含まれる、請求項22に記載の方法。
25. 各ロクセルと関連付けられる前記ロクセル識別子情報が、前記ロクセルの地理的な領域の中のロケーションを示し、前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる前記初期ロクセルのロクセル識別子情報を求めるステップが、前記現在位置に最も近いロケーションを示す前記ロクセル識別子を求めるステップを含む、請求項14に記載の方法。
26. 前記現在位置に最も近いロケーションを示す前記ロクセル識別子を求めるステップが、前記クライアントデバイスの前記現在位置と、前記ロクセルの前記地理的な領域の中の前記ロケーションを示す前記複数のロクセル識別子との間のユークリッド距離を求めるステップを含む、請求項25に記載の方法。
27. 各ロクセルと関連付けられる前記ロクセル識別子情報が、前記ロクセルの地理的な領域の中のロケーションの、緯度と経度の対である、請求項18に記載の方法。
28. 複数のロクセルと関連付けられるロクセル識別子情報を示す前記コードブック情報を、ARサーバから受信するステップをさらに含む、請求項14に記載の方法。
29. 前記クライアントデバイスでARアプリケーションを実行し、前記クライアントデバイスで前記ARアプリケーションが実行されたことに基づいて、前記コードブック情報を要求するステップをさらに含む、請求項28に記載の方法。
30. 前記クライアントデバイスにおいて、複数のロクセルと関連付けられるロクセル識別子情報を示す、コードブック情報を記憶するための手段と、
    前記クライアントデバイスの現在位置を示す、現在位置情報を求めるための手段と、
    前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記現在位置と関連付けられる初期ロクセルのロクセル識別子情報を求めるための手段と
    を含む、モバイルデバイス。
31. 前記クライアントデバイスの前記現在位置を示す、現在位置情報を求めるための前記手段が、衛星測位、支援された衛星測位、および地上測位からなる群から選択された1つまたは複数の測位技法を用いて、前記現在位置情報を求めるための手段を含む、請求項30に記載のモバイルデバイス。
32. 前記現在位置情報の少なくとも一部を1つまたは複数のネットワークリソースに送信し、それに応答して複数のロクセルと関連付けられるAR情報を受信するための手段をさらに含み、前記複数のロクセルが、前記現在位置情報の少なくとも一部を用いて選択される、請求項30に記載のモバイルデバイス。
33. ダウンロードされるべきロクセルと関連付けられたロクセル識別子を求めるための手段と、前記ダウンロードされるべきロクセルに対する要求を送信するための手段とをさらに含む、請求項30に記載のモバイルデバイス。
34. ダウンロードされるべきロクセルと関連付けられたロクセル識別子を求めるための前記手段が、前記コードブック情報を入手し、前記クライアントデバイスの前記現在位置と、現在のカメラの視界を示す情報、ARアプリケーションと関連付けられる使用パターンを示す情報、および前記クライアントデバイスの移動を示す情報からなる群から選択される1つまたは複数のパラメータとに基づいて、少なくとも1つのロクセル識別子を選択するための手段を含む、請求項33に記載のモバイルデバイス。
35. 前記クライアントデバイスが、前記初期ロクセルと関連付けられる地理的な領域の外側の最新の位置に移動したかどうかを、判定するための手段と、
    前記クライアントデバイスが、前記初期ロクセルと関連付けられる前記地理的な領域の外側の最新の位置に移動した場合に、前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる、1つまたは複数の異なるロクセルのロクセル識別子情報を求めるための手段と、
    前記1つまたは複数の異なるロクセルと関連付けられるAR情報を要求するための手段と
    をさらに含む、請求項30に記載のモバイルデバイス。
36. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求めるための前記手段が、前記クライアントデバイスの移動の方向に基づいて、前記1つまたは複数の異なるロクセルを特定するための手段を含む、請求項35に記載のモバイルデバイス。
37. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求めるための前記手段が、前記クライアントデバイスの方位に基づいて、前記1つまたは複数の異なるロクセルを特定するための手段を含む、請求項35に記載のモバイルデバイス。
38. カメラをさらに含む、請求項35に記載のモバイルデバイスであって、前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求めるための前記手段が、前記クライアントデバイスと関連付けられた前記カメラの視野に基づいて、前記1つまたは複数の異なるロクセルを特定するための手段を含む、請求項35に記載のモバイルデバイス。
39. 前記カメラの前記視野が、65度から75度の範囲に含まれる、請求項38に記載のモバイルデバイス。
40. 前記カメラの前記視野が、175度から185度の範囲に含まれる、請求項38に記載のモバイルデバイス。
41. 各ロクセルと関連付けられる前記ロクセル識別子情報が、前記ロクセルの地理的な領域の中のロケーションを示し、前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる前記初期ロクセルのロクセル識別子情報を求めるための前記手段が、前記現在位置に最も近いロケーションを示す前記ロクセル識別子を求めるための手段を含む、請求項30に記載のモバイルデバイス。
42. 前記現在位置に最も近いロケーションを示す前記ロクセル識別子を求めるための前記手段が、前記クライアントデバイスの前記現在位置と、前記ロクセルの前記地理的な領域の中の前記ロケーションを示す前記複数のロクセル識別子との間のユークリッド距離を求めるための手段を含む、請求項41に記載のモバイルデバイス。
43. 各ロクセルと関連付けられる前記ロクセル識別子情報が、前記ロクセルの地理的な領域の中のロケーションの、緯度と経度の対である、請求項34に記載のモバイルデバイス。
44. 複数のロクセルと関連付けられるロクセル識別子情報を示す前記コードブック情報を、ARサーバから受信するための手段をさらに含む、請求項30に記載のモバイルデバイス。
45. 前記クライアントデバイスでARアプリケーションを実行するための手段と、前記クライアントデバイスで前記ARアプリケーションが実行されたことに基づいて、前記コードブック情報を要求するための手段とをさらに含む、請求項44に記載のモバイルデバイス。
46. クライアントデバイスにおいて、複数のロクセルと関連付けられるロクセル識別子情報を示す、コードブック情報を記憶するステップと、
    前記クライアントデバイスの現在位置を示す、現在位置情報を入手するステップと、
    前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記現在位置と関連付けられる初期ロクセルのロクセル識別子情報を求めるステップと
    を含む動作を実行させるように構成される命令を記録する、コンピュータ可読記録媒体。
47. 前記動作が、ダウンロードされるべきロクセルと関連付けられたロクセル識別子を求め、前記ダウンロードされるべきロクセルに対する要求を生成するステップをさらに含む、請求項46に記載のコンピュータ可読記録媒体。
48. ダウンロードされるべきロクセルと関連付けられたロクセル識別子を求めるステップが、前記コードブック情報を入手し、前記クライアントデバイスの前記現在位置と、現在のカメラの視界を示す情報、ARアプリケーションと関連付けられる使用パターンを示す情報、および前記クライアントデバイスの移動を示す情報からなる群から選択される1つまたは複数のパラメータとに基づいて、少なくとも1つのロクセル識別子を選択するステップを含む、請求項47に記載のコンピュータ可読記録媒体。
49. 前記動作がさらに、
    前記クライアントデバイスが、前記初期ロクセルと関連付けられる地理的な領域の外側の最新の位置に移動したかどうかを、判定するステップと、
    前記クライアントデバイスが、前記初期ロクセルと関連付けられる前記地理的な領域の外側の最新の位置に移動した場合に、前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求めるステップと、
    前記1つまたは複数の異なるロクセルと関連付けられるAR情報に対する要求を生成するステップと
    を含む、請求項44に記載のコンピュータ可読記録媒体。
50. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求めるステップが、前記クライアントデバイスの移動の方向を示す情報に基づいて、前記1つまたは複数の異なるロクセルを選択するステップを含む、請求項49に記載のコンピュータ可読記録媒体。
51. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求める前記ステップが、前記クライアントデバイスの方位を示す情報に基づいて、前記1つまたは複数の異なるロクセルを選択するステップを含む、請求項49に記載のコンピュータ可読記録媒体。
52. 前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる1つまたは複数の異なるロクセルのロクセル識別子情報を求める前記ステップが、前記クライアントデバイスと関連付けられるカメラの視野を示す情報に基づいて、前記1つまたは複数の異なるロクセルを選択するステップを含む、請求項49に記載のコンピュータ可読記録媒体。
53. 各ロクセルと関連付けられる前記ロクセル識別子情報が、前記ロクセルの地理的な領域の中のロケーションを示し、前記記憶されたコードブック情報を入手して、前記クライアントデバイスの少なくとも前記最新の位置と関連付けられる前記初期ロクセルのロクセル識別子情報を求めるステップが、前記現在位置に最も近いロケーションを示す前記ロクセル識別子を求めるステップを含む、請求項42に記載のコンピュータ可読記録媒体。
54. 前記現在位置に最も近いロケーションを示す前記ロクセル識別子を求めるステップが、前記クライアントデバイスの前記現在位置と、前記ロクセルの前記地理的な領域の中の前記ロケーションを示す前記複数のロクセル識別子との間のユークリッド距離を求めるステップを含む、請求項53に記載のコンピュータ可読記録媒体。
55. 各ロクセルと関連付けられる前記ロクセル識別子情報が、前記ロクセルの地理的な領域の中のロケーションの、緯度と経度の対である、請求項46に記載のコンピュータ可読記録媒体。
56. 前記動作がさらに、ARアプリケーションのための命令を実行して、前記ARアプリケーションのための前記命令が実行されたことに基づいて、前記コードブック情報に対する要求を生成するステップをさらに含む、請求項42に記載のコンピュータ可読記録媒体。

Images