(57)【特許請求の範囲】
【請求項１】
ヘッドマウントディスプレイ（ＨＭＤ）が配置される対話型環境の撮影画像を受信することと、
前記ＨＭＤの少なくとも１つの慣性センサから処理される慣性データを受信することと、
前記撮影画像及び前記慣性データを分析して前記ＨＭＤの予測将来位置を決定することと、
前記ＨＭＤの前記予測将来位置を使用して、ＲＦ送受信機のビーム形成方向を前記ＨＭＤの前記予測将来位置の方へ調整することと、
前記調整されたビーム形成方向を使用して、前記ＨＭＤのための仮想環境のビューを表す画像データを前記ＲＦ送受信機を介して前記ＨＭＤに送信することと
を含む、方法。
【請求項２】
前記撮影画像及び前記慣性データを分析することは、前記ＨＭＤの動きを特定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記特定された動きを使用して決定される、請求項１に記載の方法。
【請求項３】
前記ＨＭＤの動きを特定することは、前記ＨＭＤの動きベクトルを決定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記動きベクトルを前記ＨＭＤの現在位置に適用することによって決定される、請求項２に記載の方法。
【請求項４】
前記動きベクトルの大きさは前記ＨＭＤの前記動きの速さを特定し、前記動きベクトルの方向は前記ＨＭＤの前記動きの方向を特定する、請求項３に記載の方法。
【請求項５】
前記ＨＭＤの前記動きの前記速さに基づいて前記ＲＦ送受信機の角度広がりを調整すること
をさらに含む、請求項４に記載の方法。
【請求項６】
前記角度広がりは、前記ＨＭＤの前記動きの速さの増加と共に増加する、請求項５に記載の方法。
【請求項７】
前記ＨＭＤの動きを特定することは、前記ＨＭＤの並進運動及び／または回転運動を特定することを含み、
前記動きベクトルを決定することは、前記並進運動及び／または前記回転運動の加速度を決定することを含む、
請求項３に記載の方法。
【請求項８】
前記ＲＦ送受信機はＲＦエミッタのフェーズドアレイを含み、
前記ＲＦ送受信機の前記ビーム形成方向を調整することは、前記フェーズドアレイの前記ＲＦエミッタのうちの少なくとも１つの位相または振幅を調整させるように構成される送受信機制御データを生成することを含む、
請求項１に記載の方法。
【請求項９】
前記ＨＭＤの前記少なくとも１つの慣性センサは、加速度計、ジャイロスコープ、または磁力計のうちの１つまたは複数を含む、請求項１に記載の方法。
【請求項１０】
前記ＨＭＤは複数のライトを含み、
前記撮影画像を分析することは、前記撮影画像内の前記複数のライトのうちの１つまたは複数を識別することを含む、
請求項１に記載の方法。
【請求項１１】
慣性データを生成するように構成される少なくとも１つの慣性センサを有するヘッドマウントディスプレイ（ＨＭＤ）と、
前記ＨＭＤが配置される対話型環境の画像を撮影するように構成されるカメラと、
ＲＦ送受信機と、
前記カメラによる撮影画像及び前記慣性データを分析して前記ＨＭＤの予測将来位置を決定し、前記ＨＭＤの前記予測将来位置を使用して、前記ＲＦ送受信機のビーム形成方向を前記ＨＭＤの前記予測将来位置の方へ調整し、前記調整されたビーム形成方向を使用して、前記ＨＭＤのための仮想環境のビューを表す画像データを前記ＲＦ送受信機を介して前記ＨＭＤに送信するように構成されるコンピュータと
を備える、システム。
【請求項１２】
前記撮影画像及び前記慣性データを分析することは、前記ＨＭＤの動きを特定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記特定された動きを使用して決定される、請求項１１に記載のシステム。
【請求項１３】
前記ＨＭＤの動きを特定することは、前記ＨＭＤの動きベクトルを決定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記動きベクトルを前記ＨＭＤの現在位置に適用することによって決定される、請求項１２に記載のシステム。
【請求項１４】
前記動きベクトルの大きさは前記ＨＭＤの前記動きの速さを特定し、前記動きベクトルの方向は前記ＨＭＤの前記動きの方向を特定する、請求項１３に記載のシステム。
【請求項１５】
前記コンピュータは、前記ＨＭＤの前記動きの前記速さに基づいて前記ＲＦ送受信機の角度広がりを調整するようにさらに構成される、請求項１４に記載のシステム。
【請求項１６】
前記角度広がりは、前記ＨＭＤの前記動きの速さの増加と共に増加する、請求項１５に記載のシステム。
【請求項１７】
前記ＨＭＤの動きを特定することは、前記ＨＭＤの並進運動及び／または回転運動を特定することを含み、
前記動きベクトルを決定することは、前記並進運動及び／または前記回転運動の加速度を決定することを含む、
請求項１３に記載のシステム。
【請求項１８】
前記ＲＦ送受信機はＲＦエミッタのフェーズドアレイを含み、
前記ＲＦ送受信機の前記ビーム形成方向を調整することは、前記フェーズドアレイの前記ＲＦエミッタのうちの少なくとも１つの位相または振幅を調整させるように構成される送受信機制御データを生成することを含む、
請求項１１に記載のシステム。
【請求項１９】
前記ＨＭＤの前記少なくとも１つの慣性センサは、加速度計、ジャイロスコープ、または磁力計のうちの１つまたは複数を含む、請求項１１に記載のシステム。
【請求項２０】
前記ＨＭＤは複数のライトを含み、
前記撮影画像を分析することは、前記撮影画像内の前記複数のライトのうちの１つまたは複数を識別することを含む、
請求項１１に記載のシステム。
【請求項２１】
ヘッドマウントディスプレイ（ＨＭＤ）が配置される対話型環境の撮影画像を受信することと、
前記ＨＭＤの少なくとも１つの慣性センサから処理される慣性データを受信することと、
前記撮影画像及び前記慣性データを分析して前記ＨＭＤの現在位置及び前記ＨＭＤの予測将来位置を決定することと、
前記ＨＭＤの前記予測将来位置を使用して、ＲＦ送受信機のビーム形成方向を前記ＨＭＤの前記予測将来位置へ向かう方向に調整することと、
前記ＨＭＤのユーザの視線を追跡することと、
前記ＨＭＤのための仮想環境のビューを表す画像データを生成することであって、前記ビューの領域は前記ユーザの前記追跡された視線に基づいて異なってレンダリングされる、前記生成することと、
前記仮想環境からの音を表す音声データを生成することであって、前記音声データは、前記ＨＭＤに接続されるヘッドフォンにレンダリングされる場合に前記ユーザによる前記音の定位を可能にするように構成される、前記生成することと、
前記調整されたビーム形成方向を使用して、前記画像データ及び前記音声データを前記ＲＦ送受信機を介して前記ＨＭＤに送信することと
を含む、方法。
【請求項２２】
前記ユーザの前記視線が向けられる前記ビューの領域は、前記ビューの他の領域よりも高い画質設定でレンダリングされ、前記ビューの前記他の領域は、前記画像データのサイズを縮小するためにより低い画質設定でレンダリングされる、請求項２１に記載の方法。
【請求項２３】
前記画質設定は、更新周波数、解像度、画像の複雑度、または前記ビューの前記領域をレンダリングするための順序を決定するレンダリング順序値のうちの１つまたは複数を含む、請求項２２に記載の方法。
【請求項２４】
前記ユーザの前記視線の軌道を追跡することと、
前記ユーザの前記視線の前記軌道に基づいて、前記ユーザの前記視線の動きを予測することと
をさらに含み、
前記ビューの前記領域は、前記ユーザの前記視線の前記予測された動きに基づいて異なってレンダリングされる、
請求項２１に記載の方法。
【請求項２５】
前記音声データを生成することは、前記音の前記仮想環境における１つまたは複数の発出位置を決定することを含み、前記音声データは、前記ヘッドフォンにレンダリングされる場合に、前記音を前記１つまたは複数の発出位置から発生するものとして模擬するように構成される、請求項２１に記載の方法。
【請求項２６】
前記音声データを生成することは、前記ユーザに対して識別されるＨＲＴＦを使用する、請求項２１に記載の方法。
【請求項２７】
前記音声データを生成することは、前記ＨＭＤの前記現在位置及び／または前記予測将来位置に基づく、請求項２１に記載の方法。
【請求項２８】
前記撮影画像及び前記慣性データを分析することは、前記ＨＭＤの動きを特定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記特定された動きを使用して決定される、請求項２１に記載の方法。
【請求項２９】
前記ＨＭＤの動きを特定することは、前記ＨＭＤの動きベクトルを決定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記動きベクトルを前記ＨＭＤの現在位置に適用することによって決定され、
前記動きベクトルの大きさは前記ＨＭＤの前記動きの速さを特定し、前記動きベクトルの方向は前記ＨＭＤの前記動きの方向を特定する、
請求項２８に記載の方法。
【請求項３０】
前記ＨＭＤの前記動きの前記速さに基づいて前記ＲＦ送受信機の角度広がりを調整すること
をさらに含み、
前記角度広がりは、前記ＨＭＤの前記動きの速さの増加と共に増加する、
請求項２９に記載の方法。
【請求項３１】
ヘッドマウントディスプレイ（ＨＭＤ）が配置される対話型環境の撮影画像を受信することと、
前記ＨＭＤの少なくとも１つの慣性センサから処理される慣性データを受信することと、
前記撮影画像及び前記慣性データを分析して前記ＨＭＤの現在位置及び前記ＨＭＤの予測将来位置を決定することと、
前記ＨＭＤの前記予測将来位置を使用して、ＲＦ送受信機のビーム形成方向を前記ＨＭＤの前記予測将来位置へ向かう方向に調整することと、
前記ＨＭＤのユーザの視線を追跡することと、
前記ＨＭＤのための仮想環境のビューを表す画像データを生成することであって、前記ビューの領域は前記ユーザの前記追跡された視線に基づいて異なってレンダリングされる、前記生成することと、
前記調整されたビーム形成方向を使用して、前記画像データを前記ＲＦ送受信機を介して前記ＨＭＤに送信することと
を含む、方法。
【請求項３２】
前記ユーザの前記視線が向けられる前記ビューの領域は、前記ビューの他の領域よりも高い画質設定でレンダリングされ、前記ビューの前記他の領域は、前記画像データのサイズを縮小するためにより低い画質設定でレンダリングされる、請求項３１に記載の方法。
【請求項３３】
前記画質設定は、更新周波数、解像度、画像の複雑度、または前記ビューの前記領域をレンダリングするための順序を決定するレンダリング順序値のうちの１つまたは複数を含む、請求項３２に記載の方法。
【請求項３４】
前記ユーザの前記視線の軌道を追跡することと、
前記ユーザの前記視線の前記軌道に基づいて、前記ユーザの前記視線の動きを予測することと
をさらに含み、
前記ビューの前記領域は、前記ユーザの前記視線の前記予測された動きに基づいて異なってレンダリングされる、
請求項３１に記載の方法。
【請求項３５】
前記撮影画像及び前記慣性データを分析することは、前記ＨＭＤの動きを特定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記特定された動きを使用して決定される、請求項３１に記載の方法。
【請求項３６】
ヘッドマウントディスプレイ（ＨＭＤ）が配置される対話型環境の撮影画像を受信することと、
前記ＨＭＤの少なくとも１つの慣性センサから処理される慣性データを受信することと、
前記撮影画像及び前記慣性データを分析して前記ＨＭＤの現在位置及び前記ＨＭＤの予測将来位置を決定することと、
前記ＨＭＤの前記予測将来位置を使用して、ＲＦ送受信機のビーム形成方向を前記ＨＭＤの前記予測将来位置へ向かう方向に調整することと、
仮想環境からの音を表す音声データを生成することであって、前記音声データは、前記ＨＭＤに接続されるヘッドフォンにレンダリングされる場合にユーザによる前記音の定位を可能にするように構成される、前記生成することと、
前記調整されたビーム形成方向を使用して、前記音声データを前記ＲＦ送受信機を介して前記ＨＭＤに送信することと
を含む、方法。
【請求項３７】
前記音声データを生成することは、前記音の前記仮想環境における１つまたは複数の発出位置を決定することを含み、前記音声データは、前記ヘッドフォンにレンダリングされる場合に、前記音を前記１つまたは複数の発出位置から発生するものとして模擬するように構成される、請求項３６に記載の方法。
【請求項３８】
前記音声データを生成することは、前記ユーザに対して識別されるＨＲＴＦを使用する、請求項３６に記載の方法。
【請求項３９】
前記音声データを生成することは、前記ＨＭＤの前記現在位置及び／または前記予測将来位置に基づく、請求項３６に記載の方法。
【請求項４０】
前記撮影画像及び前記慣性データを分析することは、前記ＨＭＤの動きを特定することを含み、前記ＨＭＤの前記予測将来位置は、前記ＨＭＤの前記特定された動きを使用して決定される、請求項３６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ヘッドマウントディスプレイ（ＨＭＤ）にデータを送信するための予測的ＲＦビーム形成、ならびに関連する方法、装置、及びシステムに関する。
【背景技術】
【０００２】
ビデオゲーム業界では、長年にわたり多くの変化が見られてきた。計算能力が拡大するにつれて、ビデオゲームの開発者も同様にこれらの計算能力の向上を利用したゲームソフトウェアを作成してきた。この目的で、ビデオゲーム開発者は非常に細密で魅力的なゲーム体験を生み出すための高度な演算及び数学を組み込んだゲームをコーディングしてきた。
【０００３】
例示的なゲームプラットフォームには、Ｓｏｎｙ  Ｐｌａｙｓｔａｔｉｏｎ（登録商標）、Ｓｏｎｙ  Ｐｌａｙｓｔａｔｉｏｎ２（登録商標）（ＰＳ２）、Ｓｏｎｙ  Ｐｌａｙｓｔａｔｉｏｎ３（登録商標）（ＰＳ３）、及びＳｏｎｙ  Ｐｌａｙｓｔａｔｉｏｎ４（登録商標）（ＰＳ４）があり、これらはそれぞれゲームコンソールの形態で販売されている。よく知られているように、ゲームコンソールはディスプレイ（典型的にはテレビ）に接続され、手持ち式コントローラを介してユーザとの対話を可能にするように設計される。ゲームコンソールは専用の処理ハードウェア、たとえば、ＣＰＵ、集中的なグラフィック演算を処理するためのグラフィックシンセサイザ、ジオメトリ変換を実行するためのベクトルユニット、ならびに他の接合用（ｇｌｕｅ）ハードウェア、ファームウェア、及びソフトウェアを使用して設計される。ゲームコンソールはさらに、ゲームコンソールによりローカルでプレイするためのゲームディスクを受けるための光ディスクリーダを使用して設計され得る。ユーザがインターネットを介して他のユーザと対話形式で対戦するまたは協力プレイすることができるオンラインゲームも可能である。ゲームの複雑性がプレイヤーを魅了し続けるのと共に、ゲームメーカー及びハードウェアメーカーはさらなる対話及びコンピュータプログラムを可能にするために革新し続けている。
【０００４】
コンピュータゲーム業界において高まっているトレンドは、ユーザとゲームシステムとの対話を向上させるゲームを開発することである。より豊かな対話体験を実現する１つの方法は、ゲームシステムによって動きが追跡される無線ゲームコントローラを使用してプレイヤーの動きを追跡し、これらの動きをゲームの入力として使用することである。一般的に言えば、ジェスチャ入力とは、たとえば、コンピューティングシステム、ビデオゲームコンソール、スマート家電などの電子デバイスに、プレイヤーにより行われ、電子デバイスによりキャプチャされる何らかのジェスチャに反応させることを指す。
【０００５】
より没入感のある対話体験を実現するための他の方法は、ヘッドマウントディスプレイを使用することである。ヘッドマウントディスプレイはユーザによって装着され、仮想空間のビューなどの様々なグラフィックを提示するように構成することができる。ヘッドマウントディスプレイに提示されるグラフィックは、ユーザの視野の大部分または全体さえも覆うことができる。したがって、ヘッドマウントディスプレイは、視覚的に没入感のある体験をユーザに提供することができる。
【０００６】
ヘッドマウントディスプレイ（ＨＭＤ）はユーザの動きに反応するように仮想環境のリアルタイムのビューをレンダリングするので、ＨＭＤは没入感のある仮想現実体験を提供する。ＨＭＤを装着しているユーザには、全方向への動きの自由が与えられ、それに応じて、ＨＭＤを介して全方向への仮想環境のビューを提供することができる。しかしながら、ＨＭＤ上にレンダリングされるビデオの生成に必要な処理リソースはかなりのものであり、したがって、たとえばパーソナルコンピュータまたはゲームコンソールなどの別個のコンピューティングデバイスによって処理される。コンピューティングデバイスはＨＭＤにレンダリングするためのビデオを生成し、そのビデオをＨＭＤに送信する。
【０００７】
忠実度の高い体験を提供するためには、（たとえば、高解像度かつ高フレームレートの）高品質のビデオを提供することが望ましい。しかしながら、そのようなビデオは大量のデータの伝送を必要とするので、広い帯域幅及び安定した接続が必要となる。したがって、ＨＭＤレンダリングのための現在のシステムは、コンピューティングデバイスからＨＭＤへデータを転送するために有線接続を使用し、その理由は、必須の帯域幅及び接続安定性に対して余裕があるためである。しかしながら、ＨＭＤに接続されるワイヤの存在は、ワイヤがユーザに接触し、ＨＭＤを使用する没入体験を損ない得るので、ユーザにとって煩わしい場合がある。さらに、有線接続は、ユーザがワイヤを伸ばしすぎないように注意しなければならず、ワイヤの断線または損傷を引き起こし得るいかなる動きも回避しなければならないので、ユーザの動きの自由を妨げ得る。さらに、ワイヤの存在はつまずく危険を生み、これはユーザがＨＭＤの使用中に現実環境を見ることができないことによって高まる。
【０００８】
この文脈で、本開示の実施態様が生じる。
【発明の概要】
【０００９】
本開示の実施態様は、ヘッドマウントディスプレイ用のＲＦビーム形成に関するデバイス、方法及びシステムを含む。
【００１０】
いくつかの実施態様では、以下の方法動作、すなわち、ヘッドマウントディスプレイ（ＨＭＤ）が配置される対話型環境の撮影画像を受信することと、ＨＭＤの少なくとも１つの慣性センサから処理される慣性データを受信することと、撮影画像及び慣性データを分析してＨＭＤの予測将来位置を決定することと、ＨＭＤの予測将来位置を使用して、ＲＦ送受信機のビーム形成方向をＨＭＤの予測将来位置の方へ調整することとを含む、方法を提供する。
【００１１】
いくつかの実施態様では、撮影画像及び慣性データを分析することは、ＨＭＤの動きを特定することを含み、ＨＭＤの予測将来位置は、ＨＭＤの特定された動きを使用して決定される。
【００１２】
いくつかの実施態様では、ＨＭＤの動きを特定することは、ＨＭＤの動きベクトルを決定することを含み、ＨＭＤの予測将来位置は、ＨＭＤの動きベクトルをＨＭＤの現在位置に適用することによって決定される。
【００１３】
いくつかの実施態様では、動きベクトルの大きさはＨＭＤの動きの速さを特定し、動きベクトルの方向はＨＭＤの動きの方向を特定する。
【００１４】
いくつかの実施態様では、この方法は、ＨＭＤの動きの速さに基づいてＲＦ送受信機の角度広がりを調整することをさらに含む。
【００１５】
いくつかの実施態様では、角度広がりは、ＨＭＤの動きの速さの増加と共に増加する。
【００１６】
いくつかの実施態様では、ＨＭＤの動きを特定することは、ＨＭＤの並進運動及び／または回転運動を特定することを含み、動きベクトルを決定することは、並進運動及び／または回転運動の加速度を決定することを含む。
【００１７】
いくつかの実施態様では、ＲＦ送受信機はＲＦエミッタのフェーズドアレイを含み、ＲＦ送受信機のビーム形成方向を調整することは、フェーズドアレイのＲＦエミッタのうちの少なくとも１つの位相または振幅を調整させるように構成される送受信機制御データを生成することを含む。
【００１８】
いくつかの実施態様では、ＨＭＤの少なくとも１つの慣性センサは、加速度計、ジャイロスコープ、または磁力計のうちの１つまたは複数を含む。
【００１９】
いくつかの実施態様では、ＨＭＤは複数のライトを含み、撮影画像を分析することは、撮影画像内の複数のライトのうちの１つまたは複数を識別することを含む。
【００２０】
いくつかの実施態様では、慣性データを生成するように構成される少なくとも１つの慣性センサを有するヘッドマウントディスプレイ（ＨＭＤ）と、ＨＭＤが配置される対話型環境の画像を撮影するように構成されるカメラと、ＲＦ送受信機と、撮影画像及び慣性データを分析してＨＭＤの予測将来位置を決定し、ＨＭＤの予測将来位置を使用して、ＲＦ送受信機のビーム形成方向をＨＭＤの予測将来位置の方へ調整するように構成されるコンピュータとを含む、システムを提供する。
【００２１】
本開示の他の態様及び利点は、添付の図面と併せて、本開示の原理を例示した以下の詳細な説明から明らかになろう。
【００２２】
本開示の実施態様は、ヘッドマウントディスプレイ用のＲＦビーム形成に関するデバイス、方法及びシステムを含む。
【００２３】
いくつかの実施態様では、以下の方法動作、すなわち、ヘッドマウントディスプレイ（ＨＭＤ）が配置される対話型環境の撮影画像を受信することと、ＨＭＤの少なくとも１つの慣性センサから処理される慣性データを受信することと、撮影画像及び慣性データを分析してＨＭＤの現在位置及びＨＭＤの予測将来位置を決定することと、ＨＭＤの予測将来位置を使用して、ＲＦ送受信機のビーム形成方向をＨＭＤの予測将来位置へ向かう方向に調整することと、ＨＭＤのユーザの視線を追跡することと、ＨＭＤのための仮想環境のビューを表す画像データを生成することであって、ビューの領域はユーザの追跡された視線に基づいて異なってレンダリングされる、生成することと、仮想環境からの音を表す音声データを生成することであって、音声データは、ＨＭＤに接続されるヘッドフォンにレンダリングされる場合にユーザによる音の定位を可能にするように構成される、生成することと、調整されたビーム形成方向を使用して、ＲＦ送受信機を介して画像データ及び音声データをＨＭＤに送信することとを含む、方法を提供する。
【００２４】
いくつかの実施態様では、ユーザの視線が向けられるビューの領域は、ビューの他の領域よりも高い画質設定でレンダリングされ、ビューの他の領域は、画像データのサイズを縮小するためにより低い画質設定でレンダリングされる。
【００２５】
いくつかの実施態様では、画質設定は、更新周波数、解像度、画像の複雑度、またはビューの領域をレンダリングするための順序を決定するレンダリング順序値のうちの１つまたは複数を含む。
【００２６】
いくつかの実施態様では、この方法は、ユーザの視線の軌道を追跡することと、ユーザの視線の軌道に基づいて、ユーザの視線の動きを予測することとをさらに含み、ビューの領域は、ユーザの視線の予測された動きに基づいて異なってレンダリングされる。
【００２７】
いくつかの実施態様では、音声データを生成することは、音の仮想環境における１つまたは複数の発出位置を決定することを含み、音声データは、ヘッドフォンにレンダリングされる場合に、音を１つまたは複数の発出位置から発生するものとして模擬するように構成される。
【００２８】
いくつかの実施態様では、音声データを生成することは、ユーザに対して識別されるＨＲＴＦを使用する。
【００２９】
いくつかの実施態様では、音声データを生成することは、ＨＭＤの現在位置及び／または予測将来位置に基づく。
【００３０】
いくつかの実施態様では、撮影画像及び慣性データを分析することは、ＨＭＤの動きを特定することを含み、ＨＭＤの予測将来位置は、ＨＭＤの特定された動きを使用して決定される。
【００３１】
いくつかの実施態様では、ＨＭＤの動きを特定することは、ＨＭＤの動きベクトルを決定することを含み、ＨＭＤの予測将来位置は、ＨＭＤの動きベクトルをＨＭＤの現在位置に適用することによって決定され、動きベクトルの大きさはＨＭＤの動きの速さを特定し、動きベクトルの方向はＨＭＤの動きの方向を特定する。
【００３２】
いくつかの実施態様では、この方法は、ＨＭＤの動きの速さに基づいてＲＦ送受信機の角度広がりを調整することをさらに含み、角度広がりは、ＨＭＤの動きの速さの増加と共に増加する。
【００３３】
本開示の他の態様及び利点は、添付の図面と併せて、本開示の原理を例示した以下の詳細な説明から明らかになろう。
【図面の簡単な説明】
【００３４】
本開示は、添付の図面と併せて以下の説明を参照することによってより良く理解され得る。
【００３５】
【図１】本開示の一実施態様による、ヘッドマウントディスプレイ（ＨＭＤ）を介して仮想環境と対話するためのシステムを示す図である。
【００３６】
【図２Ａ−１】本開示の一実施態様による、ヘッドマウントディスプレイ（ＨＭＤ）を示す図である。
【図２Ａ−２】本開示の一実施態様による、ヘッドマウントディスプレイ（ＨＭＤ）を示す図である。
【００３７】
【図２Ｂ】一実施態様による、ＨＭＤユーザがクライアントシステムとインターフェースをとり、クライアントシステムが、セカンドスクリーンと呼ばれるセカンドスクリーンディスプレイにコンテンツを提供する一例を示す図である。
【００３８】
【図３】本開示の一実施態様による、実行中のビデオゲームと連動するＨＭＤの機能を概念的に示す図である。
【００３９】
【図４】本開示の実施態様による、ＨＭＤの将来位置の予測に基づく送受信機のビーム形成方向の調整を示す図である。
【００４０】
【図５Ａ】本開示の実施態様による、ＨＭＤの動きに基づくビーム形成角度広がりの調整を示す図である。
【図５Ｂ】本開示の実施態様による、ＨＭＤの動きに基づくビーム形成角度広がりの調整を示す図である。
【００４１】
【図５Ｃ】本開示の実施態様による、ＨＭＤの速さに対する送受信機のビーム形成角度広がりを示すグラフである。
【００４２】
【図５Ｄ】本開示の実施態様による、送受信機からのＨＭＤの半径方向距離に対する送受信機のビーム形成角度広がりを示すグラフである。
【００４３】
【図５Ｅ】本開示の実施態様による、送信データレートに対する送受信機のビーム形成角度広がりを示すグラフである。
【００４４】
【図６Ａ】本開示の実施態様による、ユーザ１００の視線方向に基づいてビーム形成方向が調整されるシナリオを示す図である。
【図６Ｂ】本開示の実施態様による、ユーザ１００の視線方向に基づいてビーム形成方向が調整されるシナリオを示す図である。
【図６Ｃ】本開示の実施態様による、ユーザ１００の視線方向に基づいてビーム形成方向が調整されるシナリオを示す図である。
【００４５】
【図７】本開示の実施態様による、ＨＭＤの位置分布を示す部屋７００の俯瞰図である。
【００４６】
【図８】本開示の実施態様による、予測モデルを使用したビーム形成パラメータの決定を概念的に示す図である。
【００４７】
【図９】本開示の実施態様による、予測将来位置を使用してビーム形成パラメータを調整するための方法を示す図である。
【００４８】
【図１０】本開示の実施態様による、コンピュータとＨＭＤとの間に無線通信を提供するためのシステムを概念的に示す図である。
【００４９】
【図１１Ａ】本開示の実施態様による、ビーム形成送信機の構成要素を示す概略図である。
【００５０】
【図１１Ｂ】本開示の実施態様による、ビーム形成受信機の構成要素を示す概略図である。
【００５１】
【図１２Ａ】本開示の実施態様による、複数のアンテナアレイを有するＨＭＤを概念的に示す図である。
【００５２】
【図１２Ｂ】本開示の実施態様による、ＨＭＤ上のアクティブアンテナアレイの切り替えを示す、対話型の現実環境におけるＨＭＤの俯瞰図である。
【図１２Ｃ】本開示の実施態様による、ＨＭＤ上のアクティブアンテナアレイの切り替えを示す、対話型の現実環境におけるＨＭＤの俯瞰図である。
【図１２Ｄ】本開示の実施態様による、ＨＭＤ上のアクティブアンテナアレイの切り替えを示す、対話型の現実環境におけるＨＭＤの俯瞰図である。
【００５３】
【図１３】本開示の実施態様による、（たとえばＨＭＤの）ディスプレイのリフレッシュを示す図である。
【００５４】
【図１４】本開示の実施態様による、ＨＭＤのディスプレイ上に表示されるゲームシーンを示す図である。
【００５５】
【図１５】本開示の実施態様による、優先レンダリングのためのディスプレイ内の領域の生成を示す図である。
【００５６】
【図１６】本開示の実施態様による、ＨＭＤ上に画像をレンダリングするためのフローチャートである。
【００５７】
【図１７】ヘッドフォンに配信される音が修正される一実施態様を示す図である。
【００５８】
【図１８】本開示の実施態様による、ユーザがＨＭＤを介してリアルな音の配信と共にＶＲ環境を見ていることを示す図である。
【００５９】
【図１９】本発明の実施態様による、音源を模擬するための音像定位アルゴリズムのフローチャートである。
【００６０】
【図２０】本開示の実施態様による、受け取った音のユーザの知覚に基づいて音像定位関数を選択するための方法を示す図である。
【００６１】
【図２１】本発明の実施態様を実装するためのコンピュータシステムの簡易な概略図である。
【００６２】
【図２２】本発明の実施態様を実装するために使用され得るデバイスのアーキテクチャを示す図である。
【００６３】
【図２３】本開示の様々な実施態様による、ゲームシステム２３００のブロック図である。
【発明を実施するための形態】
【００６４】
本開示の以下の実施態様は、ヘッドマウントディスプレイ（ＨＭＤ）用の予測的ＲＦビーム形成に関するデバイス、方法、及びシステムを提供する。
【００６５】
様々な実施態様において、方法、システム、画像撮影オブジェクト、センサ、及び関連するインターフェースオブジェクト（たとえば、グローブ、コントローラ、周辺デバイスなど）は、ディスプレイ画面上に実質的にリアルタイムにレンダリングされるように構成されるデータを処理するように構成される。このディスプレイは、ヘッドマウントディスプレイ（ＨＭＤ）のディスプレイ、セカンドスクリーンのディスプレイ、ポータブルデバイスのディスプレイ、コンピュータディスプレイ、ディスプレイパネル、１人または複数人のリモート接続されたユーザ（たとえば、対話体験においてコンテンツを視聴または共有し得る人々）のディスプレイなどであり得る。
【００６６】
しかしながら、本開示がこれらの具体的な詳細の一部または全部がなくても実施され得ることは当業者には明らかであろう。他の例では、本開示を不必要に不明瞭にしないように、よく知られている処理動作については詳細に説明していない。
【００６７】
図１に、本開示の一実施態様による、ヘッドマウントディスプレイ（ＨＭＤ）を介して仮想環境と対話するためのシステムを示す。ヘッドマウントディスプレイ（ＨＭＤ）１０２を装着したユーザ１００が示されている。ＨＭＤ１０２は眼鏡、ゴーグル、またはヘルメットと同じように着用され、ビデオゲームまたは他のコンテンツをユーザ１００に表示するように構成される。ＨＭＤ１０２はユーザの目のすぐ近くに表示機構を設けることによって、非常に没入感のある体験をユーザに提供する。このようにして、ＨＭＤ１０２はユーザの視野の大部分または全体さえも占有する表示領域を、ユーザのそれぞれの目に対して設けることができる。
【００６８】
図示の実施態様では、ＨＭＤ１０２はコンピュータ１０６に無線で接続される。コンピュータ１０６は当技術分野で知られている任意の汎用または専用コンピュータ、たとえば、限定はしないが、ゲームコンソール、パーソナルコンピュータ、ラップトップ、タブレットコンピュータ、モバイルデバイス、携帯電話、タブレット、シンクライアント、セットトップボックス、メディアストリーミングデバイスとすることができる。一実施態様では、コンピュータ１０６はビデオゲームを実行し、ＨＭＤ１０２によりレンダリングされるビデオゲームのビデオ及び音声を出力するように構成することができる。送受信機１１０はビデオゲームのビデオ及び音声をＨＭＤ１０２に無線送信して、その上にレンダリングできるようにするように構成される。送受信機１１０は、ＨＭＤ１０２へのデータの無線送信のための送信機と、ＨＭＤ１０２によって無線送信されたデータを受信するための受信機とを含む。
【００６９】
いくつかの実施態様では、ＨＭＤ１０２は代替の機構またはチャネルを介して、たとえば、ＨＭＤ１０２とコンピュータ１０６との両方が接続されたネットワーク１１２を介して、コンピュータと通信し得る。
【００７０】
ユーザ１００は、ビデオゲームに入力を提供するためのインターフェースオブジェクト１０４を操作し得る。加えて、カメラ１０８はユーザ１００が位置する対話型環境の画像を撮影するように構成することができる。これらの撮影画像を分析して、ユーザ１００、ＨＭＤ１０２、及びインターフェースオブジェクト１０４の位置及び動きを決定することができる。様々な実施態様において、インターフェースオブジェクト１０４は、インターフェースオブジェクトの位置及び向きを決定できるようにするための、追跡可能なライト及び／または慣性センサ（複数可）を含む。
【００７１】
ユーザがＨＭＤ１０２に表示された仮想現実シーンとインターフェースをとる方法は異なることができ、インターフェースオブジェクト１０４に加えて他のインターフェースデバイスを使用することができる。たとえば、様々な種類の片手用ならびに両手用コントローラを使用することができる。いくつかの実施態様では、コントローラに関連付けられたライトを追跡するか、またはコントローラに関連する形状、センサ、及び慣性データを追跡することによって、コントローラはそれだけで追跡することができる。これらの様々な種類のコントローラ、さらには単純に、実施され１つまたは複数のカメラによってキャプチャされるハンドジェスチャを使用することによって、ＨＭＤ１０２上に提示される仮想現実環境とインターフェースをとり、制御し、操作し、対話し、参加することが可能になる。
【００７２】
加えて、ＨＭＤ１０２は、ＨＭＤ１０２の位置及び向きを決定するために追跡することが可能な１つまたは複数のライトを含み得る。カメラ１０８は、対話型環境から音をキャプチャするための１つまたは複数のマイクロフォンを含むことができる。マイクロフォンアレイによってキャプチャされた音は、音源の位置を特定するために処理され得る。特定された位置からの音を選択的に利用または処理して、特定された位置からではない他の音を排除することができる。さらに、カメラ１０８は、複数の画像撮影デバイス（たとえば、カメラのステレオペア）、ＩＲカメラ、深度カメラ、及びそれらの組み合わせを含むように定義することができる。
【００７３】
他の実施態様では、コンピュータ１０６は、ネットワーク１１２を介してクラウドゲームプロバイダ１１４と通信するシンクライアントとして機能する。そのような実施態様では、一般的に言えば、クラウドゲームプロバイダ１１４は、ユーザ１０２によってプレイされているビデオゲームを維持し実行する。コンピュータ１０６は、ＨＭＤ１０２、指向性インターフェースオブジェクト１０４、及びカメラ１０８からの入力をクラウドゲームプロバイダに送信し、クラウドゲームプロバイダは入力を処理して実行中のビデオゲームのゲーム状態に影響を及ぼす。実行中のビデオゲームからの出力、たとえば、ビデオデータ、音声データ、及び触覚フィードバックデータは、コンピュータ１０６に送信される。コンピュータ１０６は送信前にデータをさらに処理し得、またはデータを関連するデバイスに直接送信し得る。たとえば、ビデオストリーム及び音声ストリームはＨＭＤ１０２に提供され、振動フィードバックコマンドはインターフェースオブジェクト１０４に提供される。
【００７４】
いくつかの実施態様では、ＨＭＤ１０２、インターフェースオブジェクト１０４、及びカメラ１０８は、それら自体が、たとえばクラウドゲームプロバイダ１１４と通信するためにネットワーク１１２に接続されるネットワークデバイスであり得る。いくつかの実施態様では、コンピュータ１０６は、ビデオゲーム処理を別段実行せず、ネットワークトラフィックの通過を円滑化する、ルータなどのローカルネットワークデバイスであり得る。ＨＭＤ１０２、インターフェースオブジェクト１０４、及びカメラ１０８によるネットワークへの接続は、有線または無線であり得る。
【００７５】
加えて、本開示における実施態様はヘッドマウントディスプレイを参照して説明する場合があるが、他の実施態様では、非ヘッドマウントディスプレイ、たとえば、限定はしないが、ポータブルデバイススクリーン（たとえば、タブレット、スマートフォン、ラップトップなど）、あるいは本実施態様による対話型シーンまたは仮想環境のビデオをレンダリングし、及び／またはその表示を提供するように構成することができる他の任意の種類のディスプレイに置き換えられ得ることは理解されよう。
【００７６】
仮想環境の視聴時に高品質のユーザ体験を提供するためにＨＭＤに送信されなければならない、特にビデオデータ（たとえば、画像データ及び音声データを含む）の形態のデータ量は非常に大きい。この理由で、現在のＨＭＤ技術では、ビデオデータを生成するコンピュータとＨＭＤとの間の有線接続が必要となる。しかしながら、上述のように、ＨＭＤへの有線接続はユーザの動きの自由を損ね、ＨＭＤを介して非常に効果的にレンダリングすることが可能な本来の没入体験を低下させる。
【００７７】
高品質の体験に必要なデータ量を確実に伝送することが可能な無線接続を提供するには、広いデータ帯域幅のために高い信号対雑音比を提供しつつ、ユーザの動きに応じてＨＭＤが動く場合のＨＭＤへの高い接続安定性を維持することに関する問題を克服する必要がある。これを実現するために、本開示の実施態様は、予測的ビーム形成を使用したＨＭＤへの無線データ送信を提供する。すなわち、いくつかの実施態様では、ＨＭＤの追跡された動きを分析してＨＭＤの将来位置を予測し、ビーム形成を使用してＲＦ信号をＨＭＤの予測将来位置の方へ予測的に誘導する。これにより、ＨＭＤの位置をより良く追跡するように予期してＲＦ信号を誘導することによって、ＲＦ信号強度が維持される。
【００７８】
本開示における説明を容易にする目的で、ＨＭＤの実際の位置または予測位置を、ＲＦ信号が向けられるべき現実世界空間内の位置として参照する。しかしながら、ＨＭＤの位置はより具体的には、ＨＭＤ上の、内部の、または相対的な特定の位置、たとえば、ＨＭＤの一部である受信機アンテナの位置、ＨＭＤのディスプレイ部分の位置、ＨＭＤの中心などを指す場合があることを理解されたい。
【００７９】
引き続き図１を参照すると、本開示の実施態様による、ＨＭＤへのデータ送信のための予測的ビーム形成のための手順の概要が示されている。ＨＭＤ１０２の位置は任意の種々の技術を使用して追跡できることを理解されたい。図示の実施態様では、ＨＭＤ１０２は、ＨＭＤの１つまたは複数の慣性センサから生成された慣性データ１１６をコンピュータ１０６に送信する。さらに、コンピュータ１０６は、ＨＭＤ１０２及びユーザ１００が配置された対話型環境の画像を撮影するように構成されるカメラ１１０から撮影画像データ１１８を受信する。慣性データ１１６及び／または画像データ１１８は、ＨＭＤ１０２と、その位置、向き、及び動きとを特定し追跡するためにコンピュータ１０６によって分析される。
【００８０】
ＨＭＤの予測将来位置は、ＨＭＤ１０２の追跡された動きを使用して決定される。例として、コンピュータ１０６によってＨＭＤ１０２の追跡された動きに基づいて動きベクトルを生成することができる。この動きベクトルをＨＭＤ１０２の現在位置に適用して、ＨＭＤの将来位置を予測することができる。ＨＭＤの予測将来位置を使用して、コンピュータ１０６は、送受信機１１０のビーム形成方向をＨＭＤの予測将来位置の方へ向けるように構成されるビーム形成データ１２０を生成する。送受信機のビーム形成方向を予測的に向けることによって、強い無線信号を維持することができ、その理由は、ＨＭＤ１０２の動きが予期され、信号のビーム形成方向がそのような動きに遅れなくなり、ＨＭＤのそのような動きと同時に及び／または予期して動くことができるためである。本開示では、送受信機１１０のビーム形成パラメータ（たとえば、方向及び角度広がり）が参照される。そのようなビーム形成パラメータが、送受信機の一部である送信機及び受信機の一方または両方に適用できることは理解されよう。おおまかに言って、コンピュータからＨＭＤへのビデオデータの送信に焦点を合わせた実施態様では、送受信機の送信機による送信に関してビーム形成を論じ得る。しかしながら、ビーム形成に関するいかなるそのような議論も、送受信機の受信機による信号受信にも適用できることを理解されたい。
【００８１】
いくつかの実施態様では、カメラ１０８及び送受信機１１０を同一のデバイス内に統合して、カメラ及び送受信機が互いに固定の空間関係を有するようにし、より具体的には、カメラによる画像撮影と、送受信機によるＲＦビーム形成とが、互いに対して空間的に既知となるようにする。そのような実施態様では、ＨＭＤの位置はカメラによる撮影画像から決定することができ、送受信機によるビーム形成は、追加の較正を必要とせずにＨＭＤの方へ適切に向けることができる。
【００８２】
他の実施態様では、送受信機１１０及びカメラ１０８は、ローカル環境内の異なる場所に配置することができる別々のデバイスである。そのような実施態様では、カメラによる画像撮影と、送受信機によるＲＦビーム形成との空間関係を決定するために較正が実行され得る。一実施態様では、これは、カメラからの撮影画像を分析してカメラに対するＨＭＤの位置を決定し、決定されたＨＭＤの位置に対する最適なビーム形成方向を決定するためのテストを実行し、これらの情報を関連付けることによって実行することができる。そのような手順は、より正確な較正結果を実現するために、ＨＭＤの複数の位置に対して実行され得る。
【００８３】
いくつかの実施態様では、信号品質フィードバック１２２が、たとえば送受信機１１０またはネットワーク１１２を介して、ＨＭＤ１０２からコンピュータ１０６に提供される。信号品質フィードバック１２２は無線伝送の品質（たとえば、信号強度、誤り率など）を示すものであり、十分なデータ伝送レートを提供するために、ビーム形成方向がＨＭＤ１０２の方へ効果的に誘導されているか否かを評価するのに使用可能な情報を提供する。
【００８４】
図２Ａ−１及び図２Ａ−２に、本開示の一実施態様による、ヘッドマウントディスプレイ（ＨＭＤ）を示す。特に図２Ａ−１はＰｌａｙｓｔａｔｉｏｎ（登録商標）ＶＲヘッドセットを示し、これは本開示の実施態様によるＨＭＤの一例である。図示のように、ＨＭＤ１０２は複数のライト２００Ａ−Ｈを含む。これらのライトのそれぞれは、特定の形状を有するように構成され得、同一のまたは異なる色を有するように構成することができる。ライト２００Ａ、２００Ｂ、２００Ｃ、及び２００ＤはＨＭＤ１０２の前面に配置される。ライト２００Ｅ及び２００ＦはＨＭＤ１０２の側面に配置される。そして、ライト２００Ｇ及び２００Ｈは、ＨＭＤ１０２の前面及び側面に広がるように、ＨＭＤ１０２の角部に配置される。ユーザがＨＭＤ１０２を使用する対話型環境の撮影画像においてライトを識別できることは理解されよう。ライトの識別及び追跡に基づいて、対話型環境におけるＨＭＤ１０２の位置及び向きを決定することができる。画像撮影デバイスに対するＨＭＤ１０２の特定の向きに応じて、いくつかのライトが見えたり見えなかったりすることはさらに理解されよう。また、画像撮影デバイスに対するＨＭＤ１０２の向きに応じて、ライトの異なる部分（たとえば、ライト２００Ｇ及び２００Ｈ）が画像撮影のために露光され得る。
【００８５】
一実施態様では、ライトは、ＨＭＤの現在の状態を周囲の他の人々に示すように構成することができる。たとえば、ライトの一部または全部は、特定の色配置、強度配置を有するように構成され得、点滅し、特定のオン／オフ構成を有し、またはＨＭＤ１０２の現在の状態を示す他の配置を有するように構成され得る。例として、ライトは、ビデオゲームの活発なゲームプレイ（一般には、活発なタイムライン中またはゲームのシーン内で発生するゲームプレイ）中に、ビデオゲームの他の活発でないゲームプレイの状況、たとえば、メニューインターフェース内の移動またはゲーム設定の変更など（この間にゲームのタイムラインまたはシーンは不活発であるかまたは一時停止され得る）とは異なる構成を表示するように構成することができる。また、ライトはゲームプレイの相対的な激しさのレベルを示すように構成され得る。たとえば、ゲームプレイの激しさが増加した場合、ライトの強度または点滅速度が増加し得る。このようにして、ユーザの外部の人は、ＨＭＤ１０２上のライトを見て、ユーザが激しいゲームプレイに積極的に取り組んでおり、その時に邪魔されたくないと思い得ることを理解し得る。
【００８６】
ＨＭＤ１０２は１つまたは複数のマイクロフォンをさらに含み得る。図示の実施態様では、ＨＭＤ１０２は、ＨＭＤ１０２の前面に画定されたマイクロフォン２０４Ａ及び２０４Ｂと、ＨＭＤ１０２の側面に画定されたマイクロフォン２０４Ｃとを含む。マイクロフォンのアレイを利用することによって、各マイクロフォンからの音を処理して音源の位置を決定することができる。この情報は、たとえば、不要な音源の排除、音源と視覚識別との関連付けなど、様々な方法で利用することができる。
【００８７】
また、ＨＭＤ１０２は１つまたは複数の画像撮影デバイスを含み得る。図示の実施態様では、ＨＭＤ１０２は画像撮影デバイス２０２Ａ及び２０２Ｂを含むように示されている。画像撮影デバイスのステレオペアを利用することによって、環境の３次元（３Ｄ）画像及びビデオをＨＭＤ１０２の視点から撮影することができる。そのようなビデオをユーザに提示して、ＨＭＤ１０２の装着中に、ユーザに「ビデオシースルー」能力を提供することができる。すなわち、ユーザは厳密な意味ではＨＭＤ１０２を透かして見ることはできないが、それにもかかわらず、画像撮影デバイス２０２Ａ及び２０２Ｂ（あるいは、以下の図３に示すＨＭＤ１０２の外側本体に配置された１つまたは複数の正面カメラ１０８'など）によって撮影されたビデオは、あたかもＨＭＤ１０２を透かして見ているかのようにＨＭＤ１０２の外部の環境を見ることができることと機能的に同等なものを提供することができる。そのようなビデオは、拡張現実体験を提供するために仮想要素で拡張することができ、または他の方法で仮想要素と組み合わせまたはブレンドされ得る。図示の実施態様では、２つのカメラがＨＭＤ１０２の前面に示されているが、ＨＭＤ１０２上に設置され、任意の方向を向けられた任意数の外向きのカメラが存在し得ることは理解されよう。たとえば、他の実施態様では、環境の追加のパノラマ画像撮影を提供するためにＨＭＤ１０２の側面に取り付けられたカメラが存在し得る。
【００８８】
図２Ｂに、ＨＭＤ１０２のユーザ１００がクライアントシステム１０６とインターフェースをとり、クライアントシステム１０６が、セカンドスクリーン２０７と呼ばれるセカンドスクリーンディスプレイにコンテンツを提供する一例を示す。クライアントシステム１０６は、ＨＭＤ１０２からセカンドスクリーン２０７へのコンテンツの共有を処理するための集積電子機器を含み得る。他の実施態様は、クライアントシステムと、ＨＭＤ１０２及びセカンドスクリーン２０７のそれぞれとの間でインターフェースをとる別個のデバイス、モジュール、コネクタを含み得る。この一般的な例では、ユーザ１００はＨＭＤ１０２を装着しており、コントローラを使用してビデオゲームをプレイしており、コントローラは指向性インターフェースオブジェクト１０４でもよい。ユーザ１００による対話型プレイによってビデオゲームコンテンツ（ＶＧＣ）が生成され、これはＨＭＤ１０２に対して対話形式で表示される。
【００８９】
一実施態様では、ＨＭＤ１０２内に表示されているコンテンツは、セカンドスクリーン２０７に共有される。一例では、セカンドスクリーン２０７を見ている人は、ユーザ１００によってＨＭＤ１０２内で対話形式でプレイされているコンテンツを見ることができる。他の実施態様では、他のユーザ（たとえばプレイヤー２）は、クライアントシステム１０６と対話してセカンドスクリーンコンテンツ（ＳＳＣ）を生成することができる。プレイヤーがコントローラ１０４（または任意の種類のユーザインターフェース、ジェスチャ、音声、または入力）とも対話することによって生成されるセカンドスクリーンコンテンツはＳＳＣとしてクライアントシステム１０６へ生成され得、ＳＳＣはＨＭＤ１０２から受信されたＶＧＣと共にセカンドスクリーン２０７上に表示することができる。
【００９０】
したがって、同一の場所にいるかまたはＨＭＤユーザから離れている場合がある他のユーザによる対話は、ＨＭＤユーザと、セカンドスクリーン２０７上でＨＭＤユーザによってプレイされているコンテンツを見ている場合があるユーザとの両方にとって、ソーシャルで、対話的で、より没入感のあるものとすることができる。図示のように、クライアントシステム１０６はインターネット２１０に接続することができる。インターネットは様々なコンテンツソース２２０のコンテンツへのアクセスをクライアントシステム１０６に提供することもできる。コンテンツソース２２０は、インターネットを介してアクセス可能な任意の種類のコンテンツを含むことができる。
【００９１】
そのようなコンテンツは、限定なしに、ビデオコンテンツ、映画コンテンツ、ストリーミングコンテンツ、ソーシャルメディアコンテンツ、ニュースコンテンツ、フレンドコンテンツ、広告コンテンツなどを含むことができる。一実施態様では、クライアントシステム１０６を使用して、ゲームプレイ中の対話に関連付けられたマルチメディアコンテンツがＨＭＤに提供されるように、ＨＭＤユーザ用のコンテンツを同時に処理することができる。そして、クライアントシステム１０６は、セカンドスクリーンへのビデオゲームコンテンツとは無関係であり得る他のコンテンツを提供することもできる。クライアントシステム１０６は、一実施態様では、コンテンツソース２２０のうちの１つ、もしくはローカルユーザ、またはリモートユーザからセカンドスクリーンコンテンツを受信することができる。
【００９２】
図３に、本開示の一実施態様による、実行中のビデオゲームと連動するＨＭＤ１０２の機能を概念的に示す。実行中のビデオゲームは、ビデオゲームのゲーム状態を更新するための入力を受け取るゲームエンジン３２０によって定義される。ビデオゲームのゲーム状態は、たとえば、オブジェクトの存在及び位置、仮想環境の状況、イベントのトリガ、ユーザプロファイル、ビューの視点など、現在のゲームプレイの様々な側面を定義するビデオゲームの様々なパラメータの値によって少なくとも部分的に定義することができる。
【００９３】
図示の実施態様では、ゲームエンジンは、例として、コントローラ入力３１４、音声入力３１６、及びモーション入力３１８を受け取る。コントローラ入力３１４は、手持ち式ゲームコントローラ（たとえば、Ｓｏｎｙ  ＤＵＡＬＳＨＯＣＫ（登録商標）４ワイヤレスコントローラ、Ｓｏｎｙ  ＰｌａｙＳｔａｔｉｏｎ（登録商標）Ｍｏｖｅモーションコントローラ）、または指向性インターフェースオブジェクト１０４などの、ＨＭＤ１０２から分離したゲームコントローラの操作から定義され得る。例として、コントローラ入力３１４は、方向入力、ボタン押下、トリガ起動、動き、ジェスチャ、またはゲームコントローラの操作から処理される他の種類の入力を含み得る。音声入力３１６は、ＨＭＤ１０２のマイクロフォン３０２から、もしくは画像撮影デバイス１０８に含まれるマイクロフォンから、またはローカル環境内の他の場所から処理することができる。モーション入力３１８は、ＨＭＤ１０２に含まれるモーションセンサ３００から、またはＨＭＤ１０２の画像を撮影したときに画像撮影デバイス１０８から処理することができる。ゲームエンジン３２０は、ゲームエンジンの構成に従って処理される入力を受け取って、ビデオゲームのゲーム状態を更新する。ゲームエンジン３２０はゲーム状態データを様々なレンダリングモジュールに出力し、これらはゲーム状態データを処理して、ユーザに提示されるコンテンツを定義する。
【００９４】
図示の実施態様では、ビデオレンダリングモジュール３２２は、ＨＭＤ１０２上に提示されるビデオストリームをレンダリングするように定義される。ビデオストリームはディスプレイ／プロジェクタ機構３１０によって提示され、ユーザの目３０６によって光学系３０８を通して見られ得る。音声レンダリングモジュール３０４は、ユーザにより聴取される音声ストリームをレンダリングするように構成される。一実施態様では、音声ストリームは、ＨＭＤ１０２に関連付けられたスピーカー３０４を介して出力される。スピーカー３０４は、オープンエアスピーカー、ヘッドフォン、または音声を提示することが可能な他の任意の種類のスピーカーの形態を取り得ることを理解されたい。
【００９５】
一実施態様では、ユーザの視線の追跡を可能にするために、視線追跡カメラ３１２がＨＭＤ１０２に含まれる。視線追跡カメラは、ユーザの視線方向を決定するために分析される、ユーザの目の画像を撮影する。一実施態様では、ユーザの視線方向に関する情報を利用してビデオレンダリングに影響を及ぼすことができる。たとえば、ユーザの目が特定の方向を見ていると決定された場合、その方向のビデオレンダリングは、ユーザが見ている領域においてさらなる細部またはより速い更新を提供することなどによって優先または強調することができる。ユーザの視線方向は、ヘッドマウントディスプレイに対して、ユーザが位置する現実環境に対して、及び／またはヘッドマウントディスプレイ上にレンダリングされている仮想環境に対して定義できることを理解されたい。
【００９６】
おおまかに言って、視線追跡カメラ３１２によって撮影画像の分析は、単独で考慮すると、ＨＭＤ１０２に対するユーザの視線方向を提供する。しかしながら、ＨＭＤ１０２の追跡された位置及び向きと組み合わせて考慮すると、ユーザの現実世界の視線方向を決定することができ、その理由は、ＨＭＤ１０２の位置及び向きはユーザの頭の位置及び向きと同義であるためである。すなわち、ユーザの現実世界の視線方向は、ユーザの目の位置の動きを追跡すること、及びＨＭＤ１０２の位置及び向きを追跡することから決定することができる。仮想環境のビューがＨＭＤ１０２上にレンダリングされた場合、ユーザの現実世界の視線方向を利用して、仮想環境におけるユーザの仮想世界の視線方向を決定することができる。
【００９７】
加えて、触覚フィードバックモジュール３２６は、ＨＭＤ１０２またはユーザによって操作される他のデバイス、たとえば、指向性インターフェースオブジェクト１０４のいずれかに含まれる触覚フィードバックハードウェアに信号を提供するように構成される。触覚フィードバックは、たとえば、振動フィードバック、温度フィードバック、圧力フィードバックなどの様々な種類の触感の形態を取り得る。指向性インターフェースオブジェクト１０４は、そのような形態の触覚フィードバックをレンダリングするための対応するハードウェアを含むことができる。
【００９８】
図４に、本開示の実施態様による、ＨＭＤの将来位置の予測に基づく送信機のビーム形成方向の調整を示す。図示の実施態様では、ＨＭＤ１０２は、３次元空間内の初期位置Ａに示されている。ＨＭＤ１０２はユーザの制御下で任意の方向に動かすことができ、したがって、送信ビームをＨＭＤ１０２の方へ誘導することが望ましい。
【００９９】
いくつかの実施態様では、ＨＭＤ１０２の現在の動きを示す動きベクトル４００が決定される。ＨＭＤの現在の動きは、ＨＭＤ１０２の１つまたは複数の慣性センサによって生成されるデータからだけでなく、（たとえば、ライトまたはＨＭＤの他の認識可能な部分の動きを追跡するために）ＨＭＤの撮影画像を分析することからも決定することができる。いくつかの実施態様では、動きベクトル４００は、ＨＭＤの動きの空間的（３次元（３Ｄ））方向と、動きの速さとの両方を示す速度ベクトルである。動きベクトル４００をＨＭＤの現在位置Ａに適用して、ＨＭＤの予測将来位置Ｂを決定することができる。すなわち、ＨＭＤの動きの方向及び速さを使用して現在位置Ａから外挿することによって、将来位置Ｂが予測される。
【０１００】
いくつかの実施態様では、動きベクトル４００自体は、ＨＭＤ１０２の決定された加速度に基づいて予測される。すなわち、ＨＭＤの速度の変化（方向及び速さの変化を含む）を、より早い時点でのＨＭＤの以前に決定された速度、及び／または加速度検知ハードウェア（たとえば１つまたは複数の加速度計）から決定して、ＨＭＤの現在の加速度を定義することができる。この加速度を直前の動きベクトルに適用して動きベクトル４００を決定することができ、動きベクトル４００を現在位置に適用して上述のように将来位置を予測する。
【０１０１】
図示の実施態様では、送受信機１１０の初期のビーム形成方向４０２は、図示のようにＨＭＤの初期位置Ａの方へ向けられている。ＨＭＤの予測将来位置Ｂに基づいて、ビーム形成方向は、更新されたビーム形成方向４０４によって示されるように、将来位置Ｂの方へ向けられるように調整される。ビーム形成方向の調整は、ＨＭＤ１０２の実際の将来位置が分かる前に行われる予測的な方法で実行されることは理解されよう。ＨＭＤの将来位置を予期し、それに応じてビーム形成方向を予測的に誘導することによって、送受信機１１０とＨＭＤ１０２との間の無線通信を改善することができ、その理由は、ＲＦビーム形成を介して提供される改善された帯域幅が、その方向をＨＭＤ１０２の方へ継続的に誘導することによって維持されるためである。
【０１０２】
ビーム形成方向は予測的に調整されるので、ＨＭＤの実際の動きに様々な度合いで一致するまたはしない場合があることは理解されよう。しかしながら、本開示の実施態様によれば、その後の予測位置は、最新の利用可能な情報に基づいて（たとえば、カメラからの撮影画像の分析を介して）決定される既知の現在位置から決定することができる。したがって、所与の調整されたビーム形成方向はＨＭＤの実際の動きと詳細に一致しない場合があるが、その後のビーム形成方向の調整は、ＨＭＤの実際の既知の位置に少なくとも部分的に基づくので、ビーム形成方向の継続的な調整は、ＨＭＤ１０２の実際の位置から過度にずれやすくはならならない。
【０１０３】
いくつかの実施態様では、ビーム形成更新レートは約１０から１００ミリ秒のオーダーであるので、ＨＭＤの将来位置が予測されるレートはビーム形成更新レートと一致する。いくつかの実施態様では、予測レートは、カメラのフレームレート、たとえばいくつかの実施態様では６０、１２０、または２４０Ｈｚと一致するように構成される。したがって、この予測は、次のフレームにおけるＨＭＤの位置を予測することになる。
【０１０４】
いくつかの実施態様では、ＨＭＤ１０２の慣性センサは、カメラ１０８よりも、動きを検出するためのより優れた能力を有し得る。たとえば、カメラはその解像度（たとえば、いくつかの実施態様では７２０ｐまたは１０８０ｐの解像度）によって制限され得るので、慣性センサはカメラ１０８よりも小さい動きに反応し得る。さらに、慣性センサのサンプルレートは、カメラのフレームレートよりもかなり高い場合がある。たとえば、カメラは約６０、１２０または２４０Ｈｚのフレームレートを有し得、慣性センサは１０００Ｈｚを超えるサンプルレートを有し得る。さらに、カメラは、位置及び／または動きを決定するために、（たとえば、撮影画像を分析するために）より長い処理時間を必要とし得る。このように、慣性センサは、カメラ１０８よりも速い過渡応答で、動きに対してより敏感であり得る。
【０１０５】
しかしながら、相対運動を検出する慣性センサは、時間が経つにつれてドリフト効果を起こしやすい場合があるので、ＨＭＤの位置の決定を行うのにもっぱら信頼されているわけではない。一方、カメラ１０８はＨＭＤの位置の正確な決定を行うのにより適しており、その理由は、ローカル環境内の固定オブジェクトが、ローカル環境内のＨＭＤの位置を決定するためのアンカーとして機能することができるためである。
【０１０６】
したがって、様々な実施態様において、別々または組み合わせでの慣性センサデータ対画像撮影データの使用は、時間と共に変化し得る。たとえば、いくつかの実施態様では、慣性センサのサンプルレートは、カメラのフレームレートよりもＮ倍速い場合がある。したがって、ＨＭＤの予測位置は、慣性センサのサンプルレートと一致するレートで決定することができるが、Ｎ回ごとの予測位置は、カメラからの画像撮影データを考慮に入れる（たとえば、ＨＭＤの実際の位置を検証し、それに基づいて予測位置が決定される）。ＨＭＤの各予測位置を使用して、送受信機１１０のビーム形成方向をそれに応じて調整することによって、ＨＭＤの予測位置の方へ向けるようにすることができることは理解されよう。このように、ビーム形成方向の調整は、カメラのフレームレートよりも速いレートで行われ得る。
【０１０７】
関連する実施態様では、ＨＭＤの予測位置が決定されるレートは慣性センサのサンプルレートと必ずしも一致しないが、それでもなおカメラのフレームレートよりは速く、及び／または予測位置の決定が撮影画像データを考慮に入れるレートよりも速い。慣性センサのサンプルレート及びカメラのフレームレートはこれらのデバイスの動作範囲内で設定可能にすることができ、これを必要に応じて制御して、前述の位置予測を可能にすることができることは理解されよう。
【０１０８】
いくつかの実施態様では、慣性センサのより高速なサンプリングレートを利用して動きベクトルの決定を改善し、たとえば、（撮影画像に対して追加的にサンプリングされた）慣性センサデータに基づいて現実空間におけるＨＭＤの加速度を考慮に入れることによって行う。このようにして、動きベクトル４００は、ＨＭＤの実際の動きと一致するようにより良く調整され得、それによってＨＭＤのより正確な予測位置が可能になる。
【０１０９】
いくつかの実施態様では、カメラからの撮影画像データを処理し分析するのに必要な時間は、撮影画像データを使用したＨＭＤの位置の決定がＨＭＤの実際の動きよりもかなりの程度遅れ得るようなものである。したがって、いくつかの実施態様では、撮影画像データは、ＨＭＤの過去位置を決定するために分析されるが、（慣性センサデータに基づいて）予測将来位置を決定するための現在位置としては利用されない。むしろ、ＨＭＤの過去位置をＨＭＤの以前の予測位置などに対して検証するために、撮影画像データの分析が実行され利用される。たとえば、ＨＭＤの以前の予測位置が所定量を超えて過去位置と異なる場合、ＨＭＤの位置の現在の予測はそのような情報に基づいて調整され得る。
【０１１０】
加えて、以下でさらに詳細に論じるように、ＨＭＤの位置の予測は予測モデルを使用し得る。予測モデルの精度は、カメラからの撮影画像データを使用して決定されたＨＭＤの過去位置と、同時刻の以前の予測位置との比較に基づいて評価され得る。予測モデルはそのような比較に基づいて改善された結果を提供するように調整され得る。
【０１１１】
図５Ａ及び図５Ｂに、本開示の実施態様による、ＨＭＤの動きに基づくビーム形成角度広がりの調整を示す。本開示では、ビーム形成方向とは、ビーム形成送受信機１１０のメインローブのピーク強度方向を指すことは理解されよう。しかしながら、ビーム形成方向を調整することに加えて、メインローブの角度幅／広がりであるビーム形成角度広がりを調整することもできる。電磁ビームの角度広がりは様々な定義、たとえば、「半値全幅」（ＦＷＨＭ：ｆｕｌｌ  ｗｉｄｔｈ  ａｔ  ｈａｌｆ  ｍａｘｉｍｕｍ）（または「電力半値ビーム幅」（ＨＰＢＷ：ｈａｌｆ  ｐｏｗｅｒ  ｂｅａｍ  ｗｉｄｔｈ））定義などを使用して定義することができ、これは角度広がりを最大強度の半分におけるビームの全幅として定義するものである。
【０１１２】
いくつかの実施態様では、角度広がりはＨＭＤ１０２の速さに基づいて調整される。たとえば、図５Ａにおいて、ユーザ１００によって操作されるＨＭＤ１０２は、動きベクトル５００によって示される第１の速さを有する。それに応じて、送受信機１１０のビーム形成角度広がりは、角度広がり５０２を有するように制御される。図５Ｂにおいて、ユーザ１００によって操作されるＨＭＤ１０２は、動きベクトル５０４によって示される、第１の速さより速い第２の速さを有する。それに応じて、送受信機１１０のビーム形成角度広がりは、角度広がり５０２よりも広い／大きい角度広がり５０６を有するように制御される。現在説明している実施態様は、ＨＭＤの速さが増加するにつれて角度広がりが増加するように、ＨＭＤの速さと正に相関するようビーム形成広がりを調整することを企図している。これは無線接続の安定性を維持するために有用であり、その理由は、ＨＭＤの可能性のある将来位置の範囲はＨＭＤの速さが速いほど大きくなる傾向を有し得るので、そのような状況下でより大きい角度幅を有するビーム形成角度広がりはメインローブの広がりの中にＨＭＤを維持する可能性が高いためである。
【０１１３】
関連する実施態様では、ビーム形成角度広がりを決定する目的で、送受信機に対するＨＭＤの横方向の速さが、他の方向におけるＨＭＤの速さに対して優先される。ＨＭＤ１０２が送受信機１１０へ向かってまたは離れて動いている場合、ＨＭＤが送受信機１１０に対して横方向に動いている場合とは対照的に、ＨＭＤが送受信機のメインローブから出る可能性が低くなり得ることは理解されよう。したがって、いくつかの実施態様では、送受信機１１０に対するＨＭＤ１０２の横方向の動きが考慮され、ビーム形成角度広がりは横方向の速さと正の相関で調整される。
【０１１４】
いくつかの実施態様では、送受信機１１０のビーム形成角度広がりは、横方向の速さが増加するにつれて角度広がりが増加するように、送受信機に対するＨＭＤの横方向の速さに応じて、他の非横方向のＨＭＤの速さを排除して調整される。他の実施態様では、送受信機１１０のビーム形成角度広がりは、ＨＭＤの速さが増加するにつれて角度広がりが増加するような正の相関で、ＨＭＤの速さに応じて調整されるが、ＨＭＤの横方向の速さが、角度広がりを決定する目的で、他の方向のＨＭＤの速さよりも大きく重み付けられる。
【０１１５】
いくつかの実施態様では、送受信機からのＨＭＤの距離はビーム形成角度広がりに影響を及ぼす。たとえば、ＨＭＤが送受信機に近い場合、ＨＭＤが動くと、ＨＭＤが送受信機から遠い場合と比べて、ＨＭＤが送受信機のメインローブから外に出やすくなり得る。したがって、いくつかの実施態様では、ビーム形成角度広がりは、送受信機からのＨＭＤの距離が減少するにつれて角度広がりが増加するように、送受信機からのＨＭＤの距離に対して逆相関で調整される。
【０１１６】
関連する実施態様では、この概念は、ＨＭＤの検出された動きに基づいて応用することができる。たとえば、いくつかの実施態様では、送受信機へ向かうＨＭＤの半径方向の動きが検出された場合に角度広がりが増加し、送受信機から離れるＨＭＤの半径方向の動きが検出された場合に角度広がりが減少するように、送受信機へ向かう／離れるＨＭＤの半径方向の動きに基づいてビーム形成角度広がりが調整される。さらに、角度広がりの増加または減少の量は、それぞれ送受信機へ向かうまたは離れるＨＭＤの半径方向の動きの速さに正に相関させることができる。
【０１１７】
図５Ｃは、本開示の実施態様による、ＨＭＤの速さに対する送受信機のビーム形成角度広がりを示すグラフである。おおまかに言って、角度広がりはＨＭＤの速さに正に相関し、ＨＭＤの速さが増加するにつれて送受信機の角度広がりも増加する。しかしながら、特定の最小の速さを下回ると、角度広がりは最小値に維持される。そして特定の最大の速さを上回ると、角度広がりは最大値に維持される。いくつかの実施態様では、ＨＭＤの速さは、具体的には送受信機に対するＨＭＤの横方向の速さである。本開示の原理によれば、ＨＭＤの速さは、たとえば現在の速さ及び／または加速度などの要因に基づいて予測された速さであり得、したがって、速さに基づく角度広がりの調整を予測的に実行できることは理解されよう。
【０１１８】
図５Ｄは、送受信機からのＨＭＤの半径方向距離に対する送受信機のビーム形成角度広がりを示すグラフである。図示のように、角度広がりは全体的に送受信機からのＨＭＤの半径方向距離と逆相関し、半径方向距離が増加するにつれて角度広がりは全体的に減少する。しかしながら、特定の最小半径方向距離を下回ると、角度広がりは最大値に維持される。そして特定の最大半径方向距離を上回ると、角度広がりは最小値に維持される。本開示の原理によれば、送受信機からのＨＭＤの半径方向距離は、たとえば現在の動き及び加速度などの様々な要因に基づいて予測された半径方向距離であり得、したがって、半径方向距離に基づく角度広がりの調整を予測的に実行できることは理解されよう。
【０１１９】
いくつかの実施態様では、角度広がりは、データレートなどの他の要因に基づいて決定することができる。図５Ｅは、本開示の実施態様による、送信データレートに対する送受信機のビーム形成角度広がりを示すグラフである。おおまかに言って、角度広がりは送信データレートと逆相関し、データレートが増加するにつれて角度広がりは減少する。角度広がりを狭めると帯域幅を広げることができ、ただし、角度広がりは狭くなる。したがって、このようにデータレートに応じて角度広がりを変化させることによって、信号がＨＭＤの方へ適切に向けられた場合に利用可能な帯域幅と、ＨＭＤの動きに対する無線接続の許容範囲との間にはトレードオフがある。いくつかの実施態様では、特定の最小データレートを下回ると、角度広がりは最大値に維持される。そして特定の最大データレートを上回ると、角度広がりは最小値に維持される。
【０１２０】
ビーム形成角度広がりの調整に関する上述の実施態様は、限定なく例として提供している。本開示の範囲に入るさらなる実施態様は、互いに排他的ではない前述の実施態様のいずれかの組み合わせによって包含される。
【０１２１】
いくつかの実施態様では、ビーム形成方向及び／または角度広がりは、ユーザの視線方向に基づいて調整することができる。図６Ａ、図６Ｂ、及び図６Ｃに、本開示の実施態様による、ユーザ１００の視線方向に基づいてビーム形成方向が調整されるシナリオを示す。図６Ａに、ＨＭＤ１０２を装着しているユーザ１００の俯瞰図を示す。ユーザ１００は視線方向６００を有するように示されている。送受信機１１０は、ＨＭＤ１０２の方へ向けられたビーム形成方向６０２を有するように構成される。送受信機の角度広がりはＨＭＤ１０２をほぼ中心とすることは理解されよう。
【０１２２】
図６Ｂでは、ユーザ１００は視線方向を右へ視線方向６０６に動かしている。ユーザ１００の視線方向の変化は、ユーザが、たとえば、おおよそ新たな視線方向の方向に動こうとしていることを示し得る。したがって、いくつかの実施態様によれば、送受信機１１０のビーム形成方向はユーザの視線方向の変化に応答して調整される。引き続き図６Ｂを参照すると、視線方向６０６がユーザ１００の右側に動いたので、ビーム形成方向６０８は同様の方向に動かされ、更新されたビーム形成方向６０８に応答的に変更される。ビーム形成方向６０８は変更されているが、その角度広がり６１０は、ＨＭＤ１０２が依然としてメインローブ内に位置するようなものであり、ＨＭＤが実際にはまだ新たな位置に動いていないので、ＨＭＤとの無線接続が維持される。ビーム形成方向はユーザの視線方向の変化に基づいて予測的に動かされていることは理解されよう。ＨＭＤの位置は変化していないが、ビーム形成方向は予測的に調整され得、ただしＨＭＤ１０２を送受信機１１０の角度広がり内に維持する範囲内である。
【０１２３】
図６Ｃでは、ユーザ１００は、たとえば追加的に頭を回転させることによって、視線方向を視線方向６１２にさらに動かしている。ユーザは次いで、符号６１４で示す新たな位置に移動する。ユーザ１００が移動すると、送受信機のビーム形成方向は、強い無線接続を維持するために方向６１６に予測的に動かされる。
【０１２４】
いくつかの実施態様では、ユーザの視線方向（及び／またはその変化）は、ＨＭＤの将来位置を予測する目的で考慮することができる他の要因である。視線方向は、予測将来位置を決定するための追加で説明する要因と組み合わせて重み付けすることができ、それに応じてビーム形成方向を調整することができる。さらに、追加の実施態様では、ユーザの視線方向を利用してビーム形成角度広がりに影響を及ぼすことができる。
【０１２５】
いくつかの実施態様では、ＨＭＤの位置は時間と共に追跡することができ、対話型環境内でのＨＭＤの位置の分布を決定することができる。ＨＭＤの将来位置は、ＨＭＤの過去位置分布に少なくとも部分的に基づいて決定することができる。
【０１２６】
図７に、本開示の実施態様による、ＨＭＤの位置分布を示す部屋７００の俯瞰図を示す。部屋７００は、ＨＭＤがユーザによって操作され、カメラ１０８及び送受信機１１０が配置された、対話型の現実環境を定義する。線７０４ａ−ｅ及び７０６ａ−ｄは、部屋７００内のＨＭＤの過去位置に基づく位置分布の等高線である。すなわち、対話中のＨＭＤの位置は、たとえば周期的な間隔でＨＭＤの位置を記録することによって時間と共に追跡されており、部屋７００内の位置の分布は、発生の密度（単位面積当たりの発生数）もしくは頻度または確率が、線７０４ａ−ｅまたは７０６ａ−ｄのうちの所与の１つに沿って同一またはほぼ同一であるようなものである。図示の実施態様では、図示した最も高い等高値は線７０４ａ及び７０６ａのものであり、線７０４ｂ、ｃ、及びｄ、ならびに線７０６ｂ、ｃ、及びｄでは値が減少していく。図示の実施態様では、線７０４ｅは図示した最も低い等高値を表している。
【０１２７】
領域７０８及び７１０が、ＨＭＤに関して最も高い分布密度の位置を示すことは理解されよう。換言すれば、ＨＭＤは、領域７０８及び７１０の単位面積内に位置する確率が、部屋７００の他の領域の単位面積内に位置する確率よりも統計的に高い。図示の実施態様では、カウチ／椅子７０２が部屋７００内に示されている。ユーザはカウチ７０２に座りながらＨＭＤを使用してかなりの時間を費やし得るので、領域７１０及びその周辺領域は、カウチ７０２上の中央の座る位置に対応する。領域７０８及びその周辺領域はカウチの前にあり、それによって、ユーザがＨＭＤを使用しながらカウチの前に立っている領域を示し得る。
【０１２８】
いくつかの実施態様では、位置分布は、ＨＭＤの予測将来位置を決定するための要因として利用される。たとえば、確率または重みは、ＨＭＤがある位置に位置する尤度を示す位置の関数として決定することができ、これはＨＭＤの予測将来位置を決定するための要因として使用することができる。
【０１２９】
関連する実施態様では、所与の対話型アプリケーションについて、複数のユーザにわたるＨＭＤの位置／動きパターンを決定することができ、たとえば複数のＨＭＤに関する位置／動き情報を記録し、そのような情報をサーバにアップロードして処理及び分析することによって行う。位置／動き情報は対話型アプリケーションの状態に関連付けられ、それによって、（たとえば、対話型アプリケーションによって定義される仮想環境内の特定の時間的または地理的位置における）対話型アプリケーションの所与の状態についてのＨＭＤの位置／動きパターンを決定することができる。これにより、特定のアプリケーション状態についてのＨＭＤの位置及び動きに関するクラウドソースのデータを提供することができ、これを利用して、対話型アプリケーションとの対話中の特定のユーザのＨＭＤの将来位置及び動きを予測することができる。
【０１３０】
図８に、本開示の実施態様による、予測モデルを使用したビーム形成パラメータの決定を概念的に示す。予測モデル８００は、１つまたは複数の入力を使用してＨＭＤの将来位置及び／または動き（たとえば速度、加速度）を予測するように構成される。
【０１３１】
例として、そのような入力は、モーションデータ８０８（たとえば、速度（方向及び速さ）、加速度、回転など）、位置データ８１０（たとえば、３Ｄ座標、相対位置情報、過去位置情報など）、視線方向８１２、ユーザバイオメトリクス８１４（たとえば、身長、体重、心拍数、呼吸、瞳孔拡張など）、ユーザプロファイル／履歴（たとえば、ユーザの嗜好、ユーザの動き／ジェスチャパターンなど）、ならびにアプリケーション状態８１８（たとえば、アプリケーション変数状態、仮想オブジェクト状態など）のいずれかを含むことができる。
【０１３２】
予測モデルの出力に基づいて、送受信機のビーム形成パラメータが調整され（符号８０２）、これはメインローブの方向及び／または角度広がりの調整を含むことができる。ＨＭＤがビーム形成メインローブ内に留まり、継続して強力な無線接続が提供されるようにするために、ビーム形成調整がＨＭＤの実際の動きと同時にまたはその前にすら実行できるように、送受信機のビーム形成が予測的に調整されることは理解されよう。
【０１３３】
動作８０４において、フィードバックデータを処理して、ビーム形成調整の有効性及び／または予測モデルの精度を評価することができる。いくつかの実施態様では、フィードバックデータは、送受信機からＨＭＤによって受信された無線信号の品質を示す、ＨＭＤによって取得された信号品質測定値を含む。例として、そのような信号品質測定値は、信号強度、信号対雑音比、帯域幅、誤り、または送受信機によって送信され、ＨＭＤによって受信される無線信号の品質の他の測定値を含むことができる。送受信機の信号品質を評価することによって、ビーム形成調整の有効性及び／または予測モデルの精度を評価することができる。
【０１３４】
いくつかの実施態様では、フィードバックデータは、ＨＭＤの実際の位置及び／または動きを示す位置及び／または動きデータを含み、これを予測モデルによって生成された予測位置／動きと比較して、予測モデルの精度を評価することができる。
【０１３５】
上記に基づいて、次いで動作８０６において、予測モデル８００を調整してその精度を向上させることができる。いくつかの実施態様では、予測モデルを改善するために機械学習技術を利用することができる。
【０１３６】
図９に、本開示の実施態様による、予測将来位置を使用してビーム形成パラメータを調整するための方法を示す。方法動作９００において、ＨＭＤを含む現実世界の対話型環境の画像がカメラによって撮影される。方法動作９０２において、ＨＭＤの慣性運動が、ＨＭＤの１つまたは複数の慣性センサによって検知される。方法動作９０４において、ＨＭＤの検知された慣性運動と、ＨＭＤの撮影画像との一方または両方に少なくとも部分的に基づいて、ＨＭＤの現在位置が決定される。
【０１３７】
方法動作９０６において、ＨＭＤの検知された慣性運動と、ＨＭＤの撮影画像との一方または両方に少なくとも部分的に基づいて、動きベクトルが生成される。方法動作９０８において、動きベクトル及びＨＭＤの現在位置を使用してＨＭＤの将来位置が予測される。方法動作９１０において、方向及び／または角度広がりなどの送受信機の１つまたは複数のビーム形成パラメータが、ＨＭＤの予測将来位置に基づいて調整される。
【０１３８】
本開示では、ＨＭＤの将来位置を予測し、ＲＦビーム形成方向を予測将来位置の方へ誘導することに関して実施態様を全体的に説明しているが、いくつかの実施態様では、必ずしも特定の将来位置が決定されるわけではないことを理解されたい。むしろ、予測的な方法でのビーム形成方向の調整は、特定の将来位置を具体的に決定または特定することなく、様々な入力パラメータに基づいて実現される。そのような実施態様におけるビーム形成方向は、入力に基づいて、予測将来位置が決定された場合にそこへ向かうように予測的に誘導されることは理解されよう。
【０１３９】
図１０に、本開示の実施態様による、コンピュータとＨＭＤとの間に無線通信を提供するためのシステムを概念的に示す。コンピュータ１０６はカメラ１０８及び送受信機１１０に接続される。上述のように、カメラ１０８及び送受信機１１０は、いくつかの実施態様では同一のデバイスの一部であり得、または他の実施態様では別々のデバイスであり得る。カメラ１０８は、コンピュータ１０６から受信した命令を処理して、カメラ１０６の動作パラメータ、たとえば、絞り、センサゲインなどを制御するように構成されるコントローラ１０２６を含む。送受信機１１０は、コンピュータ１０６からの命令を処理して、送受信機の送信機１０３０及び受信機１０３２の制御を含む送受信機１１０の動作を制御するように構成されるコントローラ１０２８を含む。送信機１０３０及び受信機１０３２が、本開示の原理によるビーム形成をもたらすように構成できることは理解されよう。
【０１４０】
おおまかに言って、コンピュータ１０６は、対話型アプリケーション１０１６（たとえば、ビデオゲーム）を実行して、ＨＭＤ１０２のディスプレイ１０４８にレンダリングするためにＨＭＤ１０２に無線送信されるビデオデータ（画像及び音声データを含む）を生成する。送受信機１１０のビーム形成方向及び／または広がりは、無線受信可能範囲及びＨＭＤへの指向性を維持するように調整される。ＨＭＤは、たとえば１つまたは複数の加速度計１０４０、ジャイロスコープ１０４２、及び磁力計１０４４を含む様々な慣性センサ１０３８を含む。慣性センサ１０３８から処理されたデータはＨＭＤによって、ＨＭＤの送受信機１０３４から送受信機１１０への送信を介してコンピュータ１０６に通信される。コンピュータ１０６は、ＨＭＤからの慣性センサデータを処理して、たとえばＨＭＤの動きを決定または特定するように構成されるセンサデータプロセッサ１０００を含む。
【０１４１】
カメラ１０８は、ユーザがＨＭＤを操作する対話型の現実環境の画像を撮影するように構成される。カメラ１０８によって撮影された画像は、たとえばＨＭＤ１０２のライト１０４６を識別することによってＨＭＤを識別するなどのために、画像分析器１００２によって処理される。
【０１４２】
追跡ロジック１００４は、ＨＭＤの位置、向き、及び／または動きをさらに分析、特定及び／または定量化するように構成される。この目的で、位置分析器１００６は、慣性センサデータ及び撮影画像データに基づいてＨＭＤの位置を決定するように構成される。向き分析器は、慣性センサデータ及び撮影画像データに基づいてＨＭＤの向きを決定するように構成される。動き分析器は、慣性センサデータ及び撮影画像データに基づいてＨＭＤの動きを決定するように構成される。
【０１４３】
予測ロジック１０１８はモデルを使用して、前述のＨＭＤ１０２の位置、向き及び動きなどの様々な入力に基づいてＨＭＤ１０２の将来位置及び／または動きを予測する。いくつかの実施態様では、予測ロジック１０１８は、ユーザ設定１０１４または対話型アプリケーション１０１６からの情報などの追加の入力を使用する。たとえば、対話型アプリケーション１０１６は、対話型アプリケーションの現在の状態に基づいて、ＨＭＤの将来の予想位置または動きに関する情報を提供し得る。ビーム形成プロセッサ１０２０は、ＨＭＤの予測将来位置及び／または動きに基づいて、ビーム形成パラメータ及びその調整を決定するように構成される。方向処理モジュール１０２２は、送受信機１１０のビーム形成方向及びその調整を決定するように構成される。広がり処理モジュール１０２４は、送受信機１１０の角度広がり及びその調整を決定するように構成される。更新されたビーム形成パラメータは送受信機１１０のコントローラ１０２８に通信され、それによって、ビーム形成方向を更新された方向に誘導／更新すること、及び／または角度広がりを更新することなどの、送受信機のパラメータの調整がもたらされる。
【０１４４】
いくつかの実施態様では、ＨＭＤ１０２は、送受信機１１０から受信した信号の品質を評価するように構成される信号分析器１０３６を含む。たとえば、信号分析器１０３６は送受信機１１０からの無線信号を分析してその信号強度を決定し得る。この情報をコンピュータ１０６にフィードバックとして戻すことによって、強い信号が維持されているか、及びビーム形成方向及び角度広がりの予測的調整が有効であるかの評価を可能にすることができる。いくつかの実施態様では、フィードバックデータは、ＨＭＤ１０２へのビデオデータの送信に利用されるものとは別の通信チャネル及び／または別の通信プロトコル／コンテキストを介して提供される。たとえば、いくつかの実施態様では、フィードバックデータは、（送受信機１１０を介して送信されるのではなく）ネットワーク１１２を介してＨＭＤからコンピュータ１０６に送信される。例として、ネットワーク１１２は、ＨＭＤ１０２がそれを通してネットワーク１１２に無線アクセスする無線ルータまたは他の無線ネットワーキングデバイスを含み得る。また、コンピュータ１０６は有線または無線接続を介してネットワーク１０６にアクセスし得る。
【０１４５】
フィードバックデータを提供する目的での代替通信プロトコル／コンテキストの使用は、送受信機１１０を介した無線接続が失われた場合に有益であり、その場合、コンピュータ１０６へ戻る通信のための代替経路が可能である。フィードバックデータ、及び他の種類のデータを送信するための帯域幅要件は、ビデオデータの送信に必要な要件よりもかなり狭くできることは理解されよう。したがって、（たとえば、ビデオデータをＨＭＤに送信するのに使用されるものよりも）帯域幅が狭い通信コンテキスト、たとえば従来のＷｉＦｉ（登録商標）ネットワーク接続を介したフィードバックデータの送信は、そのような目的には十分な場合がある。
【０１４６】
いくつかの実施態様では、フィードバックデータの送信は、ＨＭＤへのビデオデータの無線送信に使用されるものとは別の周波数帯域で行われる。たとえば、ビデオデータは６０ＧＨｚの周波数帯域でＨＭＤに送信され得、フィードバックデータは異なる周波数帯域、たとえば２．４ＧＨｚまたは５ＧＨｚの帯域で送信される。そのような実施態様では、送受信機１１０の送信機１０３０及びＨＭＤの送受信機１０３４の対応する受信機は６０ＧＨｚで動作するように構成され、送受信機１１０の受信機１０３２及びＨＭＤの送受信機１０３４の対応する送信機は異なる周波数帯域で動作するように構成されることは理解されよう。
【０１４７】
既に述べたように、いくつかの実施態様では、ビーム形成が送受信機１１０によって送信及び受信両方の目的で利用される。しかしながら、いくつかの実施態様では、ビーム形成は送受信機１１０によって送信のみのために選択的に利用することができ、ビーム形成は受信のためには利用されない。このようにして、（たとえば、メインローブがＨＭＤを適切に追跡するのに失敗したために）ＨＭＤの送信が損なわれたり失われたりしても、ＨＭＤから送受信機へ戻る通信は維持される可能性が高い。他の実施態様では、ビーム形成は、送信対受信について異なる方法で利用することができる。たとえば、送受信機１１０による受信のためのビーム形成の角度広がりは、送受信機１１０による送信のためのビーム形成の角度広がりよりも大きくなるように構成され得る。これにより、受信の指向性に関していくらかの利益を提供しながらも、（ＨＭＤへの送信と比べて）ＨＭＤからの通信を受信するためのより高い信号安定性を与えることができる。
【０１４８】
さらに他の実施態様では、送受信機１１０による信号受信の品質は、送受信機のビーム形成方向がＨＭＤの方へ効果的に誘導されているか否かを示す追加のフィードバックデータとして機能することができる。
【０１４９】
本開示の実施態様は、指向性信号送信及び／または受信を実現するための信号処理技術としてビーム形成を使用する。ビーム形成技術は、送信素子または受信素子のフェーズドアレイを動作させて、所望の方向にかつ所望の角度幅にわたって建設的干渉を意図的に生じさせることを必要とする。ビーム形成は、送信及び受信の両方に対する空間的選択性を実現するために使用することができる。おおまかに言って、送信ビーム形成は、複数の空間的に分離されたアンテナのそれぞれにおける信号の位相及び相対振幅を制御することを必要とし、受信ビーム形成は、位相及び振幅が調整されたそのようなアンテナから受信した信号を結合することを必要とする。ビーム形成の基本的な議論は、"Ａ  Ｐｒｉｍｅｒ  ｏｎ  Ｄｉｇｉｔａｌ  Ｂｅａｍｆｏｒｍｉｎｇ，"  Ｔｏｂｙ  Ｈａｙｎｅｓ，Ｓｐｅｃｔｒｕｍ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｉｎｇ，Ｍａｒｃｈ  ２６，１９９８（ｈｔｔｐ：／／ｗｗｗ．ｓｐｅｃｔｒｕｍｓｉｇｎａｌ．ｃｏｍ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｂｅａｍｆｏｒｍ＿ｐｒｉｍｅｒ．ｐｄｆ）を参照して見つけることができ、その開示は引用により組み込まれている。
【０１５０】
実施態様は概して、ＨＭＤの位置及び動きを決定する目的で慣性データ及び撮影画像データを使用することに関して説明しているが、本開示の原理は、ＨＭＤの位置／向き及び／または動きを決定するための任意の知られている方法と共に利用できることを理解されたい。たとえばいくつかの実施態様では、ＨＭＤは、当技術分野で知られている同時位置決め地図作成（ＳＬＡＭ：ｓｉｍｕｌｔａｎｅｏｕｓ  ｌｏｃａｌｉｚａｔｉｏｎ  ａｎｄ  ｍａｐｐｉｎｇ）技術などを使用した動き及び位置追跡に利用することができる１つまたは複数の外向きカメラを含む。いくつかの実施態様では、認識可能なオブジェクト（たとえば、エミッタ（たとえば、ＲＦ、ＩＲ、可視スペクトル、レーザ、超音波、磁気など）、ライト、反射物体、タグ、成形物体、パターンなど）をローカル環境に配置して、そのような追跡を支援することができる。そのようなオブジェクトは、ＨＭＤに取り付けられた適切なセンサ（たとえば、カメラ、フォトセンシングダイオード、磁気センサ、マイクロフォンなど）によって検出することができる。そのようなセンサは、ＨＭＤの周りに分散された１つまたは複数のセンサ、またはＨＭＤの位置特定及び追跡を可能にするために協調して動作することが可能な所定の構成のセンサのアレイを含むことができることは理解されよう。本開示の原理による予測的ＲＦビーム形成を可能にして、完全に無線で動作するＨＭＤを可能にするために、ＨＭＤの位置特定及び追跡のための任意の知られている方法を利用することができる。そのような実施態様の全ては本明細書では詳細に説明していないが、当業者には容易に明らかになり、本開示の一部として理解されよう。
【０１５１】
図１１Ａは、本開示の実施態様による、送受信機１１０の送信機１０３０などの、ビーム形成送信機の構成要素を示す概略図である。符号化器１１００は、無線送信すべき情報（たとえば、ＨＭＤに送信すべきビデオデータ）を受け取り、符号化するように構成される。符号器１１００は、たとえばブロック符号化、圧縮、誤り低減のための冗長性の付加などを実行して、送信すべき情報をフォーマットし、または他の方法で処理し得る。変調器１１０２は、たとえば２進数を搬送波周波数にマッピングすること（たとえば、パルス振幅変調（ＰＡＭ）、位相シフトキーイング（ＰＳＫ）など）によって、符号化データを波形に変換する。いくつかの実施態様では、搬送波周波数は搬送波発振器１１０４によって生成される。具体的には示していないが、いくつかの実施態様では、変調器によって生成された波形は、周波数アップコンバート及び／または増幅することができる。
【０１５２】
波形はビーム形成器１１０６に供給され、ビーム形成器１１０６は波形を複数の振幅調整器１１０８ａ−ｄと、複数の移相器１１１０ａ−ｄとに並列に供給する。振幅調整器及び移相器は、アンテナアレイ１１１４の各アンテナ１１１６ａ−ｄに対する波形の振幅及び位相の個別調整／チューニングを可能にする。対応する増幅器１１１２ａ−ｄを設けて調整された波形を増幅することによって、アンテナ１１１６ａ−ｄを介して送信できるようにする。アンテナアレイ１１１４のアンテナ１１１６ａ−ｄは、所定の構成で空間的に配置される。上述のように、アンテナアレイのアンテナから位相及び振幅が調整された信号を送信することによって、所望のビーム形成効果を生み出す建設的干渉及び相殺的干渉のパターンを有する波面が生成される。
【０１５３】
図１１Ｂは、本開示の実施態様による、送受信機１１０の受信機１０３２などの、ビーム形成受信機の構成要素を示す概略図である。アンテナアレイ１１２０は複数のアンテナ１１２２ａ−ｄを含む。アンテナアレイ１１２０によって受信された信号はビーム形成器１１２４に供給され、ビーム形成器１１２４は、複数の位相調整器１１２６ａ及び振幅調整器１１２８ａを介して受信した信号の位相及び振幅をアンテナごとに個別に調整する。調整された信号は次いで結合器１１３０を介して結合され、結合器１１３０は結合された信号の増幅も行い得る。具体的には示していないが、いくつかの実施態様では、結合された信号は周波数ダウンコンバート及び／または別々に増幅することができる。
【０１５４】
復調器１１３２は結合された信号を復調して符号化データを抽出し、復号器１１３４は符号化データを復号して元の情報を抽出する。
【０１５５】
いくつかの実施態様では、アンテナアレイ１１１４（送信機アンテナアレイ）とアンテナアレイ１１２０（受信機アンテナアレイ）とは別々のデバイスである。しかしながら、他の実施態様では、アンテナアレイ１１１４及び１１２０は、たとえば、送信信号及び受信信号を適切に振り向けるように構成されるダイプレクサを有する同一のデバイスである。様々な実施態様において、アンテナアレイは、本開示の原理によるビーム形成を可能にするように所定の構成で配置された複数のアンテナを有するマイクロストリップ／パッチアンテナアレイまたは他の種類のアンテナアレイであり得る。当技術分野で知られているパッチアンテナは、数十から数百の個別のアンテナ素子を有し得る。
【０１５６】
いくつかの実施態様では、（たとえば、ビデオデータをＨＭＤに送信するための）本開示の原理による無線通信は、６０ＧＨｚの周波数帯域にわたって行われる。いくつかの実施態様では、無線通信は他の周波数帯域にわたって行われ、さらに異なる周波数帯域の組み合わせを利用し得る。
【０１５７】
図１２Ａに、本開示の実施態様による、複数のアンテナアレイを有するＨＭＤを概念的に示す。図示のように、ＨＭＤは、ＨＭＤ１０２の前部に配置されたアンテナアレイ１２００と、ＨＭＤ１０２の上部に配置されたアンテナアレイ１２０２と、ＨＭＤ１０２の側部に配置されたアンテナアレイ１２０６と、ＨＭＤ１０２の後部に配置されたアンテナアレイ１２０８とを含む。アンテナアレイは、送受信機１０３４による信号受信及び／または信号送信の目的でどのアンテナアレイがアクティブであるかを管理するセレクタ１２１０に接続される。ユーザ１００が対話型の現実環境内で動くと、ＨＭＤの位置及び向きは変化し得、それによって、どのアンテナアレイが最適な位置にあるかが変わる。いくつかの実施態様では、最適な位置にあるアンテナアレイは、送受信機に最も近いか、または送受信機に最良の見通し線を提供するアンテナアレイであり得る。それに応じて、セレクタ１２１０は、様々なアンテナアレイ間で切り替えて、最も適した位置にあるものを選択するように構成することができる。いくつかの実施態様では、セレクタ１２１０は、各アンテナアレイ１２００、１２０２、１２０６、及び１２０８からの受信信号強度を継続的に測定し、最大の信号強度を提供するものを決定し、必要であれば現在のアンテナアレイの使用から、最大の信号強度を提供するアンテナアレイの使用に切り換えるように構成される。
【０１５８】
符号１２０４に示されているのは、１つのアンテナアレイの拡大図である。各アンテナアレイは複数の個別のアンテナ素子１２０５を含むことができる。
【０１５９】
図１２Ｂ、図１２Ｃ、及び図１２Ｄに、本開示の実施態様による、ＨＭＤ上のアクティブアンテナアレイの切り替えを示す、対話型の現実環境におけるＨＭＤの俯瞰図を示す。図１２Ｂでは、ＨＭＤ１０２の前面は送受信機１１０の方を向いている。本開示の実施態様によれば、送受信機１１０はビーム形成方向１２２０がアンテナアレイ１２００の方へ向けられており、これはＨＭＤの現在のアクティブアンテナアレイであり、そこから受信された信号が処理されてビデオデータが抽出／復号され、ＨＭＤ上にレンダリングされる。さらなるアンテナアレイ１２０６ａ、１２０６ｂ、及び１２０８は現在非アクティブ状態にあり、すなわち、これらのアンテナアレイから受信された信号は、アンテナアレイ１２００の場合のようにビデオレンダリングのために特段処理されない。しかしながら、アンテナアレイ１２０６ａ／ｂ及び１２０８の信号を監視し続けて、たとえば、それらの信号強度を決定することによって、どのアンテナアレイが所与の瞬間に最適な位置にあるかを決定し得る。
【０１６０】
図１２Ｃでは、ＨＭＤは時計方向に回転しており、それによってアンテナアレイ１２００が動かされている。送受信機はそれに応じてビーム形成方向１２２２がアンテナアレイ１２００へ向けられるように調整され、本明細書で論じる原理に従って予測的に誘導され得る。アンテナアレイ１２００はアクティブアンテナアレイとして留まり、その他は非アクティブである。
【０１６１】
しかしながら、図１２Ｄでは、ＨＭＤ１０２は、アンテナアレイ１２０６ａが現在最も近い点まで回転しており、最も遮られていない見通し線を送受信機１１０に提供する。したがって、アクティブアンテナアレイは、アンテナアレイ１２００からアンテナアレイ１２０６ａに切り替えられる。加えて、送受信機のビーム形成方向は、アレイ１２００の代わりに新たにアクティブになったアンテナアレイ１２０６ａの方へ向け直される。
【０１６２】
いくつかの実施態様では、対話型環境におけるＨＭＤの向き（たとえば、送受信機に対する向き）は、前述のように慣性データ及び撮影画像データを使用して決定できることは理解されよう。次いで、ＨＭＤの向きを利用して、どのアンテナアレイがＨＭＤによる信号受信に最も適しているかを決定することができる。加えて、現在説明しているアンテナ切り替え方式は、ＨＭＤの予測された将来の向きに基づいてアンテナアレイがアクティブ化または非アクティブ化されるように、予測的に実行することができる。
【０１６３】
図１３に、本開示の実施態様による、（たとえばＨＭＤの）ディスプレイのリフレッシュを示す。多くのディスプレイでは、ディスプレイのコンテンツは行単位でレンダリングされ、これはスキャンアウト、リフレッシュまたは更新とも呼ばれる。上から下の順に１行ずつレンダリングされる。各行において、その行に関連付けられたピクセルは左から右にリフレッシュされる。この種類のレンダリングは、ディスプレイ上の全てのピクセルに対して同一のリフレッシュ周波数を提供する。
【０１６４】
本明細書に提示した実施態様はディスプレイ内に異なる領域を定義し、各領域内のピクセルは異なるレンダリング優先度が与えられる。レンダリング優先度は、ピクセルの表示方法を決定する。一実施態様では、ピクセルのレンダリング優先度が高いほど、そのピクセルはより頻繁にリフレッシュされる。
【０１６５】
本明細書で使用される場合、ディスプレイ上の特定された領域に対するレンダリングポリシーは、特定された領域がスキャンアウトされる方法を決定する。レンダリングポリシーは、領域が表示されるべき方法を特定する１つまたは複数の値（または画質設定）を含む。一実施態様では、レンダリングポリシーは、領域についての画面更新の周波数（たとえば、毎秒３０回であるが、他の値も可能である）、レンダリング解像度、領域における画像のレンダリングの複雑度、レンダリング順序値、またはユーザのビューをレンダリングするために使用される画像データの画質及び／または量に影響を及ぼし得る他の設定のうちの１つまたは複数を含む。
【０１６６】
レンダリング解像度によって、領域内の全てのピクセルが個別にリフレッシュされるか否かが決まる。最大解像度（たとえば１００％）では、領域内の全てのピクセルが色及び明るさの個々の値と共にリフレッシュされる。しかしながら、領域の解像度を下げられることもあり（たとえば６４％）、これは領域内のピクセルの一部のみがパスごとにリフレッシュされることを意味する。たとえば、５０％のレンダリング解像度では、領域内のピクセルの半分が１サイクルでリフレッシュされ、残りの半分が次のサイクルでリフレッシュされる。
【０１６７】
領域内の画像のレンダリングの複雑度は、領域内のピクセルのピクセル値を生成するために必要な処理量に基づく。たとえば、均一な色の背景領域、または背景画像のピクセル値で塗りつぶされた領域は、動くアバターを含む領域よりもレンダリングが複雑にならない。アバターのいくつかの属性に応じて複雑度が大きく増加し得、たとえば、アバターが自由になびく長い髪を含む場合、アバターが体毛のある動物である場合などである。さらに、鏡を含む領域は、鏡の画像がユーザの視線に依存するので、ピクセル値を決定するための処理も複雑になり得、鏡の向きを決定するための計算が必要となり得る。
【０１６８】
他の実施態様では、領域の定義は、ピクセル情報を記憶するために使用されるメモリセルの数を減らすことによって変更される。この場合、領域の定義が最大値を下回った場合、ピクセルデータを記憶するために使用されるメモリがそれに応じて減少する。たとえば、２５％の定義を有する領域は、１００％の定義に関連付けられたメモリの２５％しか使用しない。これは、領域内の４ピクセルのグループのスキャンに同一のピクセルデータが使用されることを意味する。
【０１６９】
また、ディスプレイ技術により、領域に関連付けられたソースメモリをアップスケーリングすることによって、ピクセル領域を埋めることができる。他の実施態様では、アップスケーリングまたはダウンスケーリングのための様々な方法が使用され得、たとえば、ニアレストネイバー補間、ミップマッピングを使用したニアレストネイバー、バイリニアフィルタリング、トリリニアフィルタリング、または異方性フィルタリングなどがある。
【０１７０】
たとえば、バイリニアフィルタリングは、第２の複数のピクセルを使用してディスプレイの領域上に第１の複数のピクセルを表示する場合にテクスチャを平滑化するためのテクスチャフィルタリング方法であり、ここで第２の複数のピクセルのピクセル数は第１の複数のピクセルのピクセル数と異なる。換言すれば、第２の複数のピクセルは、第１の複数のピクセルの（アップまたはダウン）スケーリングを必要とする。
【０１７１】
多くの場合、画面上にテクスチャのある形状を描画する場合、テクスチャは歪みなく記憶された通りに正確に表示されない。このため、ほとんどのピクセルは、テクセル（テクスチャ空間の単位）がそれぞれのセル内のどこかに位置する点であると仮定して、テクセル間にあるテクスチャ上の点を使用することが必要になってしまう。バイリニアフィルタリングはこれらの点を使用して、ピクセルが表す点（通常、ピクセルの中央または左上）に最も近い４つのテクセル間でバイリニア補間を実行する。
【０１７２】
１つの領域の解像度または定義を低下させることによって、ユーザにより良い体験を提供するためにより重要となる画面上の他の領域に計算リソースが割り当てられ得る。
【０１７３】
レンダリング順序値は、領域がレンダリングされる順序を定義するためにコンピューティングデバイスによって割り当てられる値である。一実施態様では、コンピューティングデバイスは各領域にレンダリング順序値を提供し、次いで、レンダリング順序値によって定義された順序で全ての領域がスキャンアウトされる。換言すれば、コンピューティングデバイスは、レンダリングされる全ての領域のソートされたリストを生成する。
【０１７４】
一実施態様では、１つまたは複数のレンダリングルールがレンダリングポリシーを定義する。たとえば、レンダリングポリシーは、１つのルール（たとえば、ピクセルを左から右へ、及び上から下へ表示する）を含み得、または２つ以上のルールを含み得る。たとえば、第１のルールは、ディスプレイの中央の領域がディスプレイの周辺の領域よりも高い優先度を有することを定義し得、第２のルールは、ゲームキャラクタがいる領域がゲームキャラクタがいない領域よりも高いレンダリング優先度を有することを定義し得る。
【０１７５】
図１４に、本開示の実施態様による、ＨＭＤのディスプレイ上に表示されるゲームシーンを示す。いくつかの実施態様では、視線追跡及びＨＭＤ動き追跡を使用して、ＨＭＤディスプレイ１４０２上の異なる領域のスキャンアウトを優先させる。
【０１７６】
一実施態様では、画面は複数の領域またはセクションに分割され、領域は異なる優先度及び異なる解像度レベルで更新される。これは、一部の領域が他の領域よりも頻繁に、またはより高い解像度でリフレッシュされ得ることを意味する。
【０１７７】
ユーザが視線を変更しようとしている場合に、目の動きと比較して頭の動きがわずかであっても、頭を同一の方向に動かす生来の本能があるので、ＨＭＤ追跡はユーザが視線を投影しようとしている場所を決定するのを支援する。たとえば、ユーザがまっすぐ前を見ており、頭が（ＨＭＤと共に）左へ動き始めた場合、コンピューティングデバイスは、ユーザが視線を左に動かすことになると予測する。この検出に応答して、画面の左側の領域は画面の右側の領域よりも高い優先度でレンダリングされる。実際に、シーンが左にシフトすると、画面の右縁の方の領域が視野から消える可能性が非常に高い。
【０１７８】
異なる領域のスキャンアウトを優先することにより、ユーザが見ている場所またはユーザが次に見ようとしている場所に焦点を合わせることによってユーザにより良い体験を与え、コンピュータリソースをより効率的に利用して、ユーザのビューをより高速かつより高品質にレンダリングすることが可能になる。
【０１７９】
本明細書に記載の実施態様に従ってビデオデータがＨＭＤに無線送信される場合、帯域幅は限られている場合があり、及び／またはユーザの動きに応じて変化し得るので、利用可能な無線伝送帯域幅を効率的に利用することがさらに重要となることは理解されよう。このように、本明細書に記載の優先レンダリング方法はより効率的なデータ使用を可能にし、これにより、ユーザ体験全体を向上させることができ、たとえば、より滑らかな視聴体験のためのより高いフレームレート及び／またはより少ないドロップフレームが可能になる。
【０１８０】
視線の動きよりもＨＭＤの動きを検出する方が速いことがあるので、ＨＭＤ動き追跡は重要である。場合により、ＨＭＤを視覚的に追跡するコンピューティングデバイスは、ＨＭＤよりも多くの計算リソースを有するので、コンピューティングデバイスはＨＭＤの動きを検出し、ＨＭＤの動きに基づいてＨＭＤの軌道を予測することができる。加えて、ＨＭＤは視線の現在位置に関する情報をコンピューティングデバイスに提供し、コンピューティングデバイスは視線の軌道をより良く予測するために両方の情報源を組み合わせることができる。
【０１８１】
図１４に、仮想現実ゲームの画面を示す。本明細書で提示する実施態様は、画面がコンピューティングデバイスによって生成されたシーンだけを表示する、仮想現実ディスプレイを参照して説明する。しかしながら、本明細書に提示する原理は、画面上のビューが現実世界の画像とコンピューティングデバイスが生成した画像との組み合わせである、拡張現実ゲームにも適用され得る。一実施態様では、ゲームは広範な仮想世界でプレイされる。ユーザは常に仮想世界の一部のみを見ており、ユーザは仮想世界を動き回ることができる。ユーザが仮想世界を動き回ると、仮想世界の他の部分が現れる。
【０１８２】
いくつかの実施態様では、現在のユーザの視点１４０４には、ユーザの視点１４０４の外側の領域よりも高いレンダリング優先度が与えられる。ユーザの視点は、ユーザが視野の焦点を合わせているディスプレイ上の領域として定義される。したがって、ゲーム対話のほとんどはユーザの視点１４０４内で行われる。もちろん、ユーザの視線は視点１４０４を中心とする。
【０１８３】
多くの人々は視野内で、左へ約９０°から右へ約９０°までの領域を見ることができる。しかしながら、ユーザの視野の周辺の領域ははっきりとは知覚されないが、人はそれらの周辺領域内で何らかの動きまたは変化を感じ得る。
【０１８４】
図１４に示す実施態様では、視点は画面上の長方形のセクションとして定義され、ユーザの視線はこの長方形のセクション内の中心にある。しかしながら、他の種類の視点領域が定義され得る。たとえば、一実施態様では、視点領域は、画面上のユーザの注視点の周りの円として定義される。視野角は、両目の中点から画面上の注視点までの線を基準にして定義される。そして、視点円の半径は視野角で決まる。いくつかの実施態様では、視野角は５°から４５°の範囲の値を有し得るが、他の値も可能である。
【０１８５】
いくつかの実施態様では、レンダリングポリシーは、ゲームキャラクタがいる領域が、ゲームキャラクタがいない領域よりも高いレンダリング優先度を与えられることを要求する。他の実施態様では、他のレンダリングポリシーは、ゲームキャラクタと、ゲームによって重要なゲームオブジェクトとしてランク付けされた特別なゲームオブジェクトとにより高いスキャンアウト優先度を与える。たとえば、重要なゲームオブジェクトは、出口ドア、車内または機内のナビゲーションコンソール、癒し系（ｓｏｏｔｈｉｎｇ）ゲーム上のターゲット、敵機などであり得る。一般に、重要なゲームオブジェクトとは、ユーザが作用することができるオブジェクトであり、重要でないゲームオブジェクトとは、シーンを埋めるために背景にレンダリングされるものである。
【０１８６】
図１４では、領域１４０６（ゲームキャラクタ１４１０及び１４１２を含む）及び領域１４０８（ゲームキャラクタ１４１４を含む）はゲームキャラクタがいる領域であり、ディスプレイの残りの部分よりも高いレンダリング優先度が与えられる。もちろん、いくつかの実施態様では、これは最終的なレンダリング優先度を計算する際の一要因にすぎず、その理由は、レンダリング優先度は他のルールによって、たとえば、ユーザが視線または頭を動かしている場合などに変更され得るためである。
【０１８７】
一実施態様では、ユーザが頭を速く動かすと画面上のぼけが発生し得、その理由は、速い動きはディスプレイの速い更新を必要とし、ＨＭＤがユーザの動きに追いつくための十分な計算リソースを有さない場合があるためである。ＨＭＤが速い動きをしている間のぼけを回避するために、レンダリングポリシーはユーザの動きに関連する領域のより高速なリフレッシュを開始し、他のいくつかの領域はより低い周波数またはより低い解像度でリフレッシュされ得る。ＨＭＤが動くのを止めると、より高品質のスキャンアウト画像が回復される。
【０１８８】
さらに、ユーザの視線の軌道を予測するために、コンピューティングデバイスは、所定の期間にわたってユーザの視線の軌道を追跡し、また、所定の期間（または他の一定の期間）にわたってＨＭＤの軌道を追跡することに留意されたい。過去データを使用して、視線の動き及びＨＭＤの動きにおけるトレンドを分析することによって、ユーザの視線の軌道を予測する。
【０１８９】
図１４に示す実施態様は例示的であることに留意されたい。他の実施態様は、異なる種類の視点領域、異なる種類のディスプレイ、異なるレンダリングポリシーなどを利用し得る。したがって、図１４に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
【０１９０】
図１５に、本開示の実施態様による、優先レンダリングのためのディスプレイ内の領域の生成を示す。図１５の実施態様では、等しいサイズの複数の領域が画面１５０２上に定義されている。例示的な実施態様では、３０個の領域（６×５）を生成するグリッドが画面上に定義されている。他の実施態様では、画面上に定義される領域は同一のサイズではない。たとえば、典型的には中央の領域は、より良いユーザ体験を提供するためにより重要であるので、ディスプレイの中央の領域はディスプレイの外側の領域よりも小さい。結果的に、これらの中央の領域にはより高いレンダリング優先度が与えられる。
【０１９１】
いくつかの実施態様では、ゲーム行動に基づいて、またはユーザがしていることに基づいて、いくつかの領域にはより高いレンダリング優先度が与えられる。たとえば、図６を参照して上記で論じたように、ユーザの頭の動きを検出し、これを使用して、ユーザの視線が存在すると予測される領域の優先度を高める。
【０１９２】
一実施態様では、ゲームキャラクタがいる領域は、ゲームキャラクタがいない領域よりも高い優先度が与えられる。図１５の例示的な実施態様では、領域１５０４及び１５０６の内側の領域はゲームキャラクタの一部を含む。一実施態様では、レンダリングポリシーは、領域１５０４及び１５０６のレンダリングの優先度を高めるルールを含む。他のレンダリングポリシーは、画面中央の領域に高いレンダリング優先度を与え、ディスプレイの周辺の領域に低いレンダリング優先度を与える。
【０１９３】
一実施態様では、各領域のレンダリングポリシーは、優先度を決定する複数の要因またはルールを考慮して計算される。次式を使用して、領域ｒｉのレンダリングポリシーｒｐ値を決定する。
【０１９４】
ｒｐ（ｒｉ）＝ｆ（ｒｕｌｅ１（ｒｉ），ｒｕｌｅ２（ｒｉ），．．．，ｒｕｌｅｎ（ｒｉ））
【０１９５】
ここで、ｒｐ（ｒｉ）は領域ｒｉのレンダリングポリシーであり、ｒｕｌｅ１−ｒｕｌｅｎはレンダリングポリシーを決定するために定義されたポリシールールである。たとえば、１つのルールは、ディスプレイの中央の領域により高いレンダリング優先度が与えられることを指示してもよく、２つ目のルールは、ゲームキャラクタがいる領域により高いレンダリング優先度が与えられることを決定してもよく、３つ目のルールは、注視点付近の領域により高い優先度を与えてもよく、４つ目のルールは、ユーザが自分の頭を動かしている場合に、頭が向きを変えると予測される領域により高いレンダリング優先度が与えられることを決定してもよい、などといった具合である。
【０１９６】
一実施態様では、レンダリングポリシーは、領域に対する画面更新の周波数、レンダリング解像度、及びレンダリング順序値のうちの１つまたは複数を含む。一実施態様では、領域に対するレンダリングポリシーを計算するために、各ルールに重みが与えられる。いくつかの実施態様では、重みは過去の体験に基づいて動的に調整され得る。
【０１９７】
図１６は、本開示の実施態様による、ＨＭＤ上に画像をレンダリングするためのフローチャートである。このフローチャートの様々な動作は順次的に提示し説明しているが、当業者であれば、動作のいくつかまたは全てが異なる順序で実行され、組み合わせもしくは省略され、または並列に実行され得ることを理解するであろう。
【０１９８】
動作１６０２において、この方法は、ＨＭＤ内の１つまたは複数の第１のカメラを使用してユーザの視線を追跡する。動作１６０２から、この方法は動作１６０４に進み、ここでこの方法はＨＭＤの動きを追跡する。動きを追跡することは、ＨＭＤ内にない第２のカメラ（たとえば、図１のカメラ１０８）で撮影されたＨＭＤの画像を分析することを含む。
【０１９９】
動作１６０４から、この方法は動作１６０６に進み、ここでユーザの視線の動き（たとえば、視線の予測軌道）が視線及びＨＭＤの動きに基づいて予測される。さらに、動作１６０６からこの方法は動作１６０８に進み、ここでＨＭＤのディスプレイ上に定義された複数の領域に対するレンダリングポリシーが決定される。レンダリングポリシーは、視線の予測された動きに基づいて決定される。
【０２００】
動作１６０８から、この方法は動作１６１０に進み、以前に計算されたレンダリングポリシーに基づいてディスプレイ上に画像をレンダリングする。また、一実施態様では、ＨＭＤが動いている場合に領域のレンダリング解像度が減少し、ＨＭＤが静止した場合に領域のレンダリング解像度が増加する。
【０２０１】
いくつかの実施態様では、ＨＭＤの動きに関する慣性情報が受信され、慣性情報はＨＭＤ内の慣性センサによってキャプチャされる。他の実施態様では、ＨＭＤの動きは、ＨＭＤ内にない第２のカメラで撮影されたＨＭＤの画像を分析することによって追跡される。さらに他の実施態様では、ＨＭＤの動きは、慣性情報と、第２のカメラで撮影された画像の画像分析の結果とを組み合わせることによって追跡される。
【０２０２】
さらに他の実施態様では、ＨＭＤ上に画像をレンダリングするための方法を提示する。この方法は、ＨＭＤ内のディスプレイによって生成されたビューを見ているユーザの視線を追跡するための動作を含む。さらにこの方法は、ユーザの視線に基づいて、ディスプレイ上にレンダリングされている複数のゲームオブジェクトにレンダリング優先度値を割り当てるための動作を含む。各ゲームオブジェクトのレンダリング優先度値は、レンダリング周波数及びレンダリング解像度を定義する。また、この方法は、ゲーム内の各ゲームオブジェクトの重要度値に基づいてレンダリング優先度値を変更するための動作を含む。他の動作では、この方法は、レンダリング優先度値に従ってディスプレイ上に複数のゲームオブジェクトをレンダリングする。
【０２０３】
他の実施態様では、実際のソース画像は、ソース画像と、そのソース画像がレンダリングされている領域とに基づいて変更される。たとえば、ゲームキャラクタを正視していない（たとえば、ゲームキャラクタがユーザの視野の中心に近くない場合）場合よりも、ゲームキャラクタを正視している（たとえば、ゲームキャラクタがユーザの視野の中心に近い）場合に、ゲームキャラクタがより詳細にレンダリングされる。
【０２０４】
音像定位とは、検出された音の位置または発生源を方向及び距離に関して特定する聴取者の能力を指す。それはまた、仮想３Ｄ空間における聴覚刺激の配置を模擬するための、音響工学における方法を指し得る。人間の聴覚系は、両耳間の時間差及びレベル差、スペクトル情報、タイミング分析、相関分析、及びパターンマッチングを含む、音源定位のためのいくつかの手がかりを使用する。
【０２０５】
人間には２つの耳があるが、音の位置を３次元で、すなわち、範囲（距離）、上下方向、前後、ならびに左右を特定することができる。脳、内耳、及び外耳は連携して、位置に関する推論を行う。人間は、片耳から得られる手がかりを取得し（片耳の手がかり）、両耳で受け取った手がかりを比較することによって（差異の手がかりまたは両耳の手がかり）、音源の位置を推定する。差異の手がかりの中に、到着の時間差と強度差とがある。片耳の手がかりは、音が外耳道に入って聴覚系により処理される前に元の原音が内部で修正される人間の解剖学的構造と、音源との間の相互作用からもたらされる。これらの修正は音源の位置を符号化し、音源の位置と耳の位置とを関連付けるインパルス応答を介してキャプチャされ得る。このインパルス応答は頭部インパルス応答（ＨＲＩＲ）と呼ばれる。任意の原音とＨＲＩＲとの畳み込みによって、音は、聴取者の耳が受信機の位置にある状態で音が音源の位置で再生されていたならば聴取者に聞こえていたはずの音に変換される。ＨＲＩＲを使用して仮想サラウンド音を生成することができる。
【０２０６】
音像定位関数ｆ（本明細書では別名、音像関数、定位関数、時には単に「関数」という）は、音と、その音の発生源として知覚される空間内の位置とに基づいて定位音（ｌｏｃａｌｉｚｅｄ  ｓｏｕｎｄ）を生成する関数またはアルゴリズムである。定位音は、スピーカーを通して再生された場合、音が実際にはスピーカーから発生していても、音が所望の位置から発生したという印象を聴取者に与える。関数ｆは数学的に次のように表すことができる。
【０２０７】
ｌｓ＝ｆ（ｓ，ｌ）  （１）
【０２０８】
ここでｓは音（たとえば、犬の鳴き声）であり、ｌはその音が本来発生するはずの位置であり、ｌｓは定位音である。音像定位関数の一例は頭部伝達関数（ＨＲＴＦ）であり、これは、耳が空間内のある点から音をどのように受け取るかを特徴付ける応答である。両耳についての一対のＨＲＴＦを利用して、空間内の特定の点から来たように思われるバイノーラル音を合成し得る。ＨＲＴＦは、自由大気（ｆｒｅｅ  ａｉｒ）中のある方向からの音に対する、鼓膜に到達する音への修正として記述することもできる。これらの修正には、聴取者の外耳の形状、聴取者の頭及び体の形状、音が再生される空間の音響特性などがある。これら全ての特性は、音が来ている方向を聴取者がどれほど正確に言い当てられるかに影響する。各人の身体的な違いのために、各人は異なるＨＲＴＦを有する。音像定位のための本発明の実施態様はＨＲＴＦを使用して説明するが、聴取者の身体的特徴を説明する他の任意の形態の音像定位を本発明の実施態様と共に使用することができる。
【０２０９】
図１７に、音がヘッドフォン１７１６から直接来たと知覚するのではなく、あたかも音が仮想位置「Ａ」から発出しているかのように、ヘッドフォン１７１６によって配信された音をユーザ１０２が知覚するよう、ヘッドフォン１７１６に配信される音が修正される本発明の一実施態様を示す。ローカルの対話型環境におけるＨＭＤ１０２及び／またはヘッドフォン１７１６（ヘッドセット、イヤフォン、またはイヤピースとも呼ばれる）の位置が追跡される。いくつかの実施態様では、ヘッドフォンの位置は、ＨＭＤを追跡することから推測または推論され得ることは理解されよう。ヘッドフォンの位置が分かると、コンピュータ１０６は、音が仮想位置Ａから来ているとユーザに信じさせるために、（たとえば、ユーザのＨＲＴＦを使用して）音を操作して定位音を生成する。
【０２１０】
図１７に示す実施態様では、（音声データ／信号の形態の）定位音はヘッドフォン１７１６によるレンダリングのために無線送信され、これは無線でも有線でもよい。いくつかの実施態様では、音声データ／信号はＨＭＤ１０２に無線送信され、次いでＨＭＤ１０２は音声データ／信号をヘッドフォン１７１６に（たとえば有線接続を介して）送信して音をレンダリングし得る。いくつかの実施態様では、音声データ／信号は、ヘッドフォンへ送信する前にＨＭＤ１０２によってさらに処理される。たとえば、ＨＭＤによって受信される無線送信される音声データは、音声に対する無線帯域幅要件を低減するために、圧縮音声フォーマットへデジタルに符号化され得る。したがって、ＨＭＤ１０２は符号化された音声データを復号して、ヘッドフォンに送信されるアナログ音声信号を生成し得る。定位音がヘッドフォン１７１６によって再生されると、ユーザはその音を仮想位置Ａから来たものと知覚する。
【０２１１】
他の実施態様では、音声データ／信号は、ＨＭＤ用のものとは別の無線伝送信号を使用してヘッドフォンに直接無線送信される。そのような実施態様では、画像データ及び音声データは、別々の伝送信号を使用して、それぞれＨＭＤ１０２及びヘッドフォン１７１６に別々に送信される。しかしながら、本明細書に記載のビーム形成技術が両方に適用できることは理解されよう。
【０２１２】
異なる人々は異なるＨＲＴＦを有し、ユーザのＨＲＴＦが利用された場合に、最も迫力のある体験が提供される。一実施態様では、ユーザのＨＲＴＦが利用できない場合に、標準ＨＲＴＦが利用される。標準ＨＲＴＦは人間の平均的な特性を考慮したものである。ユーザのＨＲＴＦは利用されないが、標準ＨＲＴＦはなおもユーザにリアルな体験を提供することができる。また、較正方法を利用して、音像定位体験を特定のユーザ用にさらにカスタマイズすることによって、そのユーザのＨＲＴＦを開発することができる。
【０２１３】
ヘッドフォンの位置を追跡するための複数の方法が存在し、これらはユーザの耳の位置を定義する。一般に、本明細書ではユーザの耳の位置を追跡すると称し、その理由は、耳の位置によって音がどのように定位されるかが決まるためである。説明を容易にするために、本明細書では、ユーザの位置を追跡する、ユーザの頭の位置を追跡する、ＨＭＤの位置を追跡する、またはユーザが装着しているヘッドフォンの位置を追跡する、と称することがある。耳の位置は頭、ユーザ、ＨＭＤまたはヘッドフォンの位置から推測できるので、これらの追跡方法は全て等価である。
【０２１４】
図１７の実施態様では、ヘッドフォン１７１６は、発光ダイオード（ＬＥＤ）１７１４などの光源を含むことができる。カメラ１０８はユーザ１００が位置する空間の画像を撮影し、次いでコンピュータ１０６は画像分析を実行してＬＥＤ１７１４の位置を決定する。画像内のより明るい部分は、ＬＥＤの位置を特定するのに役立つ。また、カメラ１０８からヘッドフォンまでの距離は、カメラ１０８によって撮影された画像内のＬＥＤ１７１４のサイズに基づいて推定される。ＬＥＤ１７１４の位置が決定されると、ヘッドフォンの物理的特性に従って、ＬＥＤが両耳の間かつ両耳を結ぶ線の数インチ上に位置すると仮定することによって、ユーザの耳の位置が推定される。
【０２１５】
図１７に示す実施態様は例示的であることに留意されたい。他の実施態様は、ユーザの耳の位置を追跡するために異なる方法を利用し得、または追跡方法の組み合わせを利用して精度を高めることができる。たとえば、位置追跡は、顔認識、超音波通信、ＲＦＩＤ、赤外光、全地球測位システム（ＧＰＳ）などを使用して実行することができる。したがって、図１７に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
【０２１６】
音響投影（ｓｏｕｎｄ  ｐｒｏｊｅｃｔｉｏｎ）はユーザに迫力のある体験を提供し、聴取体験からヘッドフォンを「消失」させる。ユーザは、耳付近に位置する２つのスピーカー要素から音が来ていると感じず、むしろ空間内の特定の点から音が来ていると感じ、この特定の点は状況に応じて、ポータブルデバイス、ゲームの仮想要素、仮想ユーザなどに関連付けることができる。仮想音源が変化するにつれて、またはユーザの位置が変化するにつれて、音響投影は音が正しい位置から発出しているように感じられるよう適応する。
【０２１７】
図１８に、本開示の実施態様による、ユーザがＨＭＤを介してリアルな音の配信と共にＶＲ環境を見ていることを示す。プレイヤー１００は部屋の中にいるが、本明細書では仮想シーンとも呼ばれる仮想現実は、部屋の物理的境界を超えて広がり得る。仮想シーンの基準点１８０２はテーブル１８０４の上に位置している。一実施態様では、点Ｐ０１８０２は基準点であって、座標（Ｘ０＝０，Ｙ０＝０，Ｚ０＝０）を有する座標原点でもある。プレイヤー１８０６ｂはプレイヤー１００と同じゲームをプレイしているが離れた場所におり、プレイヤー１８０６ｂはプレイヤー１００に対してゲーム内の仮想要素として描写されている。プレイヤー１８０６ｂはポータブルデバイス１８０８ｂを保持しており、これはプレイヤー１８０６ｂが位置する物理空間内の他の基準点に同期されている。
【０２１８】
１つ例示的な実施態様では、（ＨＭＤの画面を透かして見られる）仮想シーンのジオメトリは少なくとも部分的に基準点に基づくので、仮想シーンは基準点に関するものである。たとえば、仮想シーン内の仮想オブジェクトの座標は基準点に対して決定され得る。
【０２１９】
座標は任意の測定基準を使用して測定することができる。しかしながら、視覚的な例を提供するために、また、使用される実際の座標を限定せずに、仮想シーンの座標がメートルで測定される場合、座標（１，０，０）を有するオブジェクトは基準点の１メートル右に位置することになる。もちろん、現実または仮想オブジェクトの座標は、仮想オブジェクトがシーン内を動く場合など、シーンが変化したときに動的に更新され得る。また、その変化は、コンピュータによって設定された行為によって定義されるか（たとえば、対話型プログラム）、ユーザの行為によって駆動されるか、またはその両方の組み合わせとすることができる。加えて、明確にするために、対話型プログラムは任意の種類のプログラム、たとえば、ビデオゲーム、ビジネスプログラム、インターネットインターフェース、または単に、データ、他のユーザ、プログラム、あるいは表示またはスピーカーによる投影がされてもされなくてもよいオブジェクトへのアクセスを提供するグラフィカルユーザインターフェースとすることができる。
【０２２０】
またさらに、他の実施態様は異なる座標系を有するか、またはスケーリングを使用し得る。たとえば、座標系は、デカルト座標系の代わりに、極座標系、球面座標系、放物線座標系などとすることができる。加えて、基準点は座標系の原点である必要はなく、他の場所に配置することができる。一例を提供するために、基準点を座標（５，５，５）に配置することによって、５メートルを超える点で負の座標値を使用しなければならなくなる前に、各方向に５メートルのバッファを使用可能にすることができる。他のシナリオでは、仮想オブジェクトは一定の縮尺で生成され、座標も一定の縮尺で測定される。たとえば、仮想オブジェクトは１：１０の縮尺で構築され得、ジオメトリの軸も１：１０の縮尺を有することができ、その結果、座標（１，０，０）を有するオブジェクトは「現実」世界では１メートル離れており、仮想世界では１０メートル離れている。
【０２２１】
図１８では、仮想オブジェクトは、ヘリコプター１８１４ａ−１８１４ｃ、雲、鳥、太陽１８１６などを含む。プレイヤー１８０６ａがポータブルデバイス１８０８ａを動かすと、あたかもプレイヤーが仮想世界の中へのカメラを持っているかのように仮想シーンのビューが変化する。デバイス１８０８ａに表示されるビューは基準点を含んでも含まなくてもよいことに留意されたい。部屋はテーブル１８０４以外の他の静的オブジェクト、たとえば、テレビ１８１２及び窓１８１０を含む。
【０２２２】
図１８に示すように、仮想オブジェクトは空間内のどこにでも配置することができる。ポータブルデバイスがカメラを含む場合、室内の静的特徴をポータブルデバイスが使用して、カメラからのビューで慣性測定値を調整することによって、現在位置の正確な測定値を維持することができる。ポータブルデバイスにおける画像分析は、窓の縁、光源、テーブルの縁、壁の絵、テレビなどを検出することができる。
【０２２３】
コンピュータ／ゲームコンソール１０６は、拡張現実環境を配信するための情報をポータブルデバイス１８０８ａと交換する。この情報は、ゲーム情報、ユーザ追跡、ポータブルデバイスの位置、仮想オブジェクトの位置、リモートプレイヤーの位置などのうちの１つまたは複数を含む。
【０２２４】
一実施態様では、ゲームコンソール１０６は、プレイヤー１００の耳の位置を追跡する。ゲーム内で音（たとえば、ヘリコプターが飛行する音）が生成された場合、ゲームコンソール１０６は音の発生源の仮想空間内の座標を決定する。耳の位置及び音の発生源の位置が分かると、ゲームコンソール１０６は、音の発生源と、音を知覚している耳との間の相対位置を決定する。
【０２２５】
一実施態様では、ユーザ１００はヘッドフォン１７１６を装着している。ユーザのＨＲＴＦを使用して、音を、ユーザには音の発生源から来たように感じられる定位音に変換する。（場合により上述のようにＨＭＤを介して）ヘッドフォン１７１６に送信される定位音は、音の発生源の位置を模擬するための、ヘッドフォンの各個別のスピーカーについての異なる音響信号を含む。
【０２２６】
他の実施態様では、定位音はスピーカー１８２０によって生成される。ゲームコンソール１０６は、室内のスピーカー１８２０の位置に関する情報を有する。この場合もやはり、ユーザのＨＲＴＦを使用して、音を、ユーザには音の発生源から来たように感じられる定位音に変換する。スピーカー１８２０に送信される定位音は、音の発生源の位置を模擬するための、各スピーカー１８２０についての異なる音響信号を含む。
【０２２７】
この場合、定位音はヘッドフォンではなくスピーカーに配信される。スピーカーを使用する音像定位のためのアルゴリズムと、ヘッドフォンを使用するものとは類似しているが、スピーカーの場合、位置は固定されているのに対し、ユーザの位置は変化し得る。各スピーカーから来る音には移動時間が存在し、これは音像定位アルゴリズムによって考慮される必要がある。ヘッドフォンの場合、ユーザが動くとヘッドフォンが動くので、位置を追跡する必要がある。
【０２２８】
音像定位アルゴリズムはユーザのＨＲＴＦ、ならびにユーザの耳の現在位置を使用して、イヤフォン用の定位音を生成する。イヤフォンによって再生される定位音の音響信号は、仮想オブジェクトの空間内の仮想位置に関する音響的な手がかりをユーザに提供する。
【０２２９】
一実施態様では、音を発生しているオブジェクトまたは人物がＨＭＤ１０２のディスプレイ上に、またはゲームコンソール１０６に接続されたディスプレイ２０７（たとえば共有／ソーシャルスクリーン）内に表示されている場合、定位音の音響信号はより大きい音量で配信される。ＨＭＤはある意味では指向性マイクロフォンとしても機能する。音の発生源がＨＭＤのディスプレイ上にない場合、音量は小さくなる。ＨＭＤは指向性マイクロフォンとして機能しているので、ユーザがＨＭＤを動かすと、ユーザは音の発生源の所在についての音響的な手がかりを得る。
【０２３０】
リモートプレイヤー１８０６ｂに、プレイヤー１００の物理空間内の位置が割り当てられる。音像定位は、プレイヤー１８０６ｂまたはポータブルデバイス１８０８ｂから来るように感じられる音を生成することを含む。たとえば、プレイヤー１８０６ｂが話すと、その発話はポータブルデバイス１８０８ｂによってキャプチャされ、次いでゲームコンソール１０６に送信される。ユーザ１８０６ｂからの発話は次いで、ＨＲＴＦまたは他の何らかの音像定位アルゴリズムを使用して変換され、図示した仮想シーンに示されるように、あたかもプレイヤー１８０６ｂがプレイヤー１００の近くに立っているかのように、発話がユーザ１００に配信される。
【０２３１】
一実施態様では、ユーザを追跡するためにＧＰＳが使用される。たとえば、ＨＭＤまたはゲームコンソール内のＧＰＳモジュールを使用して、ユーザのＧＰＳ位置を決定する。ユーザ１８０６ｂが離れた場所（たとえば、数マイル離れた場所）にいる場合、ユーザ１８０６ｂのＧＰＳ位置を音響効果に使用することができる。たとえば、ユーザ１８０６ｂは、リモートプレイヤーによって発砲されるゲームの大砲を持っている。効果音は、ユーザ１８０６ｂの実際の位置からの大砲の発砲を模擬する。発砲のショットが最初に聞こえ、その後、砲弾がプレイヤー１８０６ｂの場所からプレイヤー１００の場所まで空中を移動するときに、砲弾の音が続く。砲弾が空中を移動するにつれて、現実生活のように音の強度が増す。最後に、砲弾が標的に当たった場合に爆発が聞こえ、標的がユーザの近くにいる場合は、音が大音量で配信されることになる。
【０２３２】
図１９は、本発明の実施態様による、音源を模擬するための音像定位アルゴリズムのフローチャートである。動作１９０２において、ユーザの頭の空間内での位置が特定され、ここでユーザは２つのスピーカーを含むヘッドフォンを装着している。前述のように、超音波、画像分析、ＲＦＩＤ、ＧＰＳ、赤外線などの複数の方法を利用してヘッドフォンの位置を決定することができる。さらに、動作１９０４において、スピーカーに配信すべき音が決定され、各スピーカーはユーザの片耳に関連付けられる。換言すれば、一方のスピーカーは左耳の隣に位置し、他方のスピーカーは右耳の隣に位置する。動作１９０６において、音の発出位置が決定される。音の発出位置とは、音がその音の発生源から来ているという印象をユーザが得るようにユーザに配信されることになる音の仮想的な発生源を定義する空間内の点を指す。
【０２３３】
動作１９０８において、各スピーカー用の音響信号が、空間内での頭の位置、音、空間内の発出位置、及びユーザの聴覚特性に基づいて確立される。ユーザの聴覚特性は、音がどこから来るかをユーザがどのように定位するかに影響を及ぼすユーザの身体的側面を定義する。一実施態様では、ユーザの聴覚特性は、ユーザの両耳に関する一対のＨＲＴＦによって定義される。
【０２３４】
動作１９０８の後、この方法は動作１９１０に進み、ここで音響信号が２つのスピーカーに送信される。音響信号が２つのスピーカーによって再生された場合、音は空間内の発出位置から発生しているように感じられる。
【０２３５】
図２０に、本開示の実施態様による、受け取った音のユーザの知覚に基づいて音像定位関数を選択するための方法を示す。ヘッドフォンによるバーチャルサラウンドは、人のＨＲＴＦ（または他の何らかの音像定位関数）の正確な測定と共に最良に動作する。ＨＲＴＦを測定するプロセスは困難である（すなわち、このプロセスは、小型のマイクロフォンを人の耳に入れ、背筋を伸ばして座った状態で、スピーカーを頭の周りの様々な位置及び距離に動かすことを必要とする）。本発明の実施態様は、ユーザの集団について測定されたＨＲＴＦのデータベースを利用する。一実施態様では、モーションコントローラを利用して、データベースの１つまたは複数のＨＲＴＦに基づく、ユーザの音像定位関数を生成する。ユーザのＨＲＴＦは実際には測定されないが、ユーザに「効果的な」１つまたは複数のＨＲＴＦを見つけることによって、定位音の配信を行うリアルなバーチャルサラウンドシステムが提供される。
【０２３６】
何百万人のユーザに対して音像定位関数を有することは現実的ではない。本発明の実施態様は、人々の代表的なセグメントに対して測定された音像定位関数を利用し、次いで特定のユーザに対してこれらの関数のうちの１つを選択するためのテストが実行される。
【０２３７】
図２０の実施態様では、ユーザ１００は室内におり、ＨＭＤ１０２及びヘッドフォン１７１６を装着している。ヘッドフォンの代わりに複数のスピーカー２００２を使用して較正プロセスが実行されてもよいことに留意されたい。コンピュータシステムはヘッドフォン１７１６を介して音を再生し、ユーザは、音源であったとユーザが思う方向２００８ａにコントローラ１０４ａを向けるように求められる。ユーザによって音の発生源として特定された方向２００８ａに基づいて、システムはこの方向に合致する１つまたは複数の音像定位関数をデータベースから選択する。換言すれば、ユーザ１００による各応答の後、システムはユーザ１００の特性を満たす可能性がある音像定位関数を絞り込む。
【０２３８】
一実施態様では、ユーザに２つの選択肢が提供される。ユーザがどこから音が来ているか分からない場合、ユーザが分からないことを示すためにコントローラの第１のボタンが押される。一方、ユーザが方向を特定した場合、ユーザは音の方向を指しながら第２のボタンを押す。これにより人々は、音像定位関数（たとえば、ＨＲＴＦ）のデータベースを検索することによって適切な音像定位関数を見つけ、ユーザ入力（たとえば、コントローラによって特定された方向）に最も近く合致する関数を見つけることが可能になる。
【０２３９】
このプロセスは様々な位置にある他の音を使用して繰り返される。コントローラの位置（たとえば１０４ｂ、１０４ｃ）に基づいて音ごとに新たな方向（たとえば２００８ｂ、２００８ｃ）が得られ、音像定位関数を分析して、その位置に最も合致するものを見つける。一実施態様では、最も合致するものは、全てのテスト音に対して最良の全体的な性能を提供する音像定位関数である。
【０２４０】
他の実施態様では、この特定のユーザについての関数は音像関数の組み合わせであり、ここで、ユーザの周囲の空間はセクタに分割され、各セクタから来る音はそのセクタに関連付けられた関数を使用し、各セクタは異なる関連付けられた関数を有する。一実施態様では、補間が使用され、いくつかのセクタは２つ以上の関数からの補間を使用する。所望の目標は完璧に選択された関数を得ることではなく、むしろ目標は、特定のゲームまたはある範囲のゲームに必要な３Ｄ体積を埋めるのに十分な、様々な位置におけるいくつかの許容できる関数を得ることである。特定数の離散的な伝達関数がただ１つの関数を選択するよりも優れていると考えられる場合、ただ１つの関数を選択する必要はない。一実施態様では、ユーザの周囲の３−Ｄ空間全体に対してテストを行うことは非常に退屈であるので、実際のテストが実行されていない領域のギャップを埋めるために補間が使用される。
【０２４１】
各テストで再生される音は、同一の音であるが異なる位置から投影され得、または異なる音声周波数のデータを取得するために、音は位置ごとに変化し得る。これにより、ユーザは全ての音がまったく同一であり、音が同一の場所から来ていると感じないので、ユーザの混乱を減らし得る。
【０２４２】
１つの伝達関数が全てのテスト音についてのユーザの音響特性と適切に合致しない場合、一実施態様では、ユーザに対して計算された音像関数は、音が来ている領域だけではなく、生成されている音の種類（たとえば、音についての支配的な周波数）も考慮に入れた関数の組み合わせとなる。たとえば、３−Ｄ空間内の特定のスポットでは、第１の関数が低周波数の音に使用され、第２の関数が高周波数または中周波数の音に使用され得る。
【０２４３】
ユーザ１００に関連する関数は既知ではないので、データベースから音像定位関数ｆ１を選択して較正プロセスを開始する。ユーザが１０４ａを方向２００８ａに向けると、システムは、ｆ１を使用して音が生成された場合に、どの定位関数ｆｕまたは複数の関数がこの応答をもたらし得るかを分析する。換言すれば、システムはｆ１をデータベース内の他の関数に関連付ける必要がある。ｓがテスト用に選択された音（たとえば、犬の鳴き声）であり、ｌ１が音の位置であり、ｌｓ１がスピーカーに配信される定位音である場合、式（１）は次のようになる。
【０２４４】
ｌｓ１＝ｆ１（ｓ，ｌ１）  （２）
【０２４５】
ユーザが方向２００８ａを指すと、方向２００８ａに基づいて位置ｌ２が計算される。ｆｕがこのユーザ及び位置ｌ２について音ｓに合致する関数である場合、次式が得られる。
【０２４６】
ｌｓ１＝ｆｕ（ｓ，ｌ２）  （３）
【０２４７】
これは、同一の音のテスト（たとえば、犬の鳴き声）の場合、ｆ１及びｆｕはスピーカーに送られる同一の音を生成するはずであるが、音像定位関数が異なるためにユーザに知覚される位置が変化することを意味する。換言すれば、関数ｆ１を有するユーザはｌ１から来る音を知覚し、関数ｆｕを有するユーザはｌ２から来る音を知覚する。
【０２４８】
式（２）及び式（３）を組み合わせると、以下の恒等式が得られる。
【０２４９】
ｆ１（ｓ，ｌ１）＝ｆｕ（ｓ，ｌ２）  （４）
【０２５０】
ｆ１、ｓ、ｌ１、及びｌ２は既知であるので、式（４）を利用してｆｕを得ることができる。しかしながら、ｆｕは位置ｌ２ではこのユーザに効果的であるが、ｆｕは他の位置では効果的でない場合があることに留意されたい。データベース内の多くの関数について式（４）が満たされ得るので、異なる位置でテストを継続することにより、システムは、可能性のある関数の中でこのユーザにさらに効果的なものを選択することが可能になる。一実施態様では、テストプロセスは、１つの最終的な関数（ユーザの特性により良く合致するもの）が選択されるまで、効果的でない関数を排除して継続する。
【０２５１】
一実施態様では、同一の関数ｆ１が全てのテストに使用される。他の実施態様では、システムがこのユーザにとって最も効果的な１つまたは複数の関数の微調整を開始すると、テストごとに使用される関数が変化する。たとえば、２回目のテストでは、前回のテストで得られた選択された関数ｆｕが、ｆ１の代わりに２回目のテストに使用される。２回目のテストの後、２つの測定値に基づいて新たな関数ｆｕ２が選択される。そして、このプロセスを繰り返して、全てのテストの測定値に基づいて、各テスト後に新たな関数を計算する。
【０２５２】
較正が行われている間にユーザが頭を動かすと、その動きによって結果が変わり得ることに留意されたい。一実施態様では、音は短く、頭の動きの影響は排除され、またはかなり低減される。他の実施態様では、ユーザの頭が追跡され、これはテスト中に耳の位置が分かっていることを意味する。一実施態様では、ユーザの撮影画像を分析することによって頭部追跡が実行されるが、磁力計付きヘッドフォンなどを使用するなど、他の方法も利用され得る。
【０２５３】
図２１は、本発明の実施態様を実装するためのコンピュータシステムの簡易な概略図である。本明細書に記載の方法は、従来の汎用コンピュータシステムなどのデジタル処理システムを使用して実行され得ることを理解されたい。１つまたは複数の特定の機能を実行するように設計またはプログラムされた専用コンピュータが代替で使用され得る。コンピューティングデバイス１０６はプロセッサ２１３２を含み、プロセッサ２１３２は、メモリ２１３４、永久記憶デバイス２１５８、及びコンピューティングデバイス１０６内の、またはこれに接続された他のモジュールに結合される。音像定位コンピュータプログラム２１３６はメモリ２１３４内に存在するが、永久記憶デバイス２１５８に存在することもできる。
【０２５４】
コンピューティングデバイス１０６は、音声／超音波キャプチャデバイス２１０８、画像撮影デバイス１０８、及びディスプレイ２０７と通信する。一実施態様では、音声キャプチャデバイス２１０８、画像撮影デバイス１０８、ＲＦＩＤモジュール２１０６、及びディスプレイ２０７は、コンピューティングデバイス１０６内に組み込まれ得、または別個のユニットであり得る。一実施態様では、超音波キャプチャデバイスはマイクロフォンを含み、他の実施態様では、超音波キャプチャデバイスはマイクロフォンアレイを含む。
【０２５５】
デバイス位置追跡モジュール７２４は、ＨＭＤ１０２、ヘッドフォン１７１６、コントローラ１０４などのデバイスの位置を決定する。位置追跡には複数の技術、たとえば、超音波、ＧＰＳ、ＲＦＩＤ、画像分析、三角測量、慣性など、またはそれらの組み合わせを使用することができる。頭部追跡モジュール２１３８は、ユーザの片耳または両耳の位置を決定する（これはヘッドフォンの位置を決定することによって間接的に決定され得る）。頭部追跡モジュール２１３８は、たとえば、画像認識、ＲＦＩＤ、超音波、赤外線、三角測量などの１つまたは複数の異なる技術を使用して、またはＨＭＤもしくはヘッドフォンなどのユーザにより装着されたデバイスの追跡に基づいて、ユーザの耳の位置を決定し得る。
【０２５６】
音響投影モジュール２１１６は、音像定位を実行するために、音響システムへの配信が意図された音響信号を修正して、修正された音響信号を受け取ったユーザが、音が意図された位置から発出しているという印象を受けるようにする。音響投影モジュール２１１６は、デバイス位置追跡モジュール２１２４及び頭部追跡モジュール２１３８によって提供された位置情報を使用して音声信号を修正する。
【０２５７】
永久記憶デバイス２１５８は、フロッピー（登録商標）ディスクドライブまたは固定ディスクドライブなどの永続的なデータ記憶デバイスを表し、これはローカルでもリモートでもよい。ネットワークインターフェース７４６はネットワーク接続を提供して、他のデバイスとの通信を可能にする。プロセッサ２１３２は、汎用プロセッサ、専用プロセッサ、または専用にプログラムされた論理デバイスで具現化され得ることを理解されたい。入出力（Ｉ／Ｏ）インターフェース２１４２は、たとえば、ディスプレイ２０７、キーボード２１５２、マウス２１５０、超音波キャプチャデバイス２１０８、画像撮影デバイス１０８、スピーカー１８２０、ヘッドフォン１７１６、ボタン、センサ、タッチスクリーン２１５６などの様々な周辺機器との通信を提供する。ユニバーサルシリアルバス（ＵＳＢ）モジュール２１４４は、ＵＳＢデバイスへの接続を提供する。
【０２５８】
ＨＭＤ１０２及び／またはディスプレイ２０７は、本明細書に記載のユーザインターフェースを表示するように構成される。キーボード２１５２、マウス２１５０、及び他の周辺機器は、情報をプロセッサ２１３２に通信するためにＩ／Ｏインターフェース２１４２に結合される。外部デバイスとの間のデータは、Ｉ／Ｏインターフェース２１４２を介して通信され得ることを理解されたい。本発明は、有線または無線ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することもできる。
【０２５９】
データベース２１１０は、複数の異なるユーザに関連する複数の音像定位関数を含む。一実施態様では、音像定位関数は、複数のユーザについて得られた測定されたＨＲＴＦ関数であるが、他の音像定位関数を利用することもできる。ユーザ用の音像定位関数であって、他のユーザ用に得られた既存の関数を活用したものを、データベース２１１０を使用して構築することができる。
【０２６０】
図２１に示す実施態様は例示的であることに留意されたい。他の実施態様は、異なるモジュールを利用すること、または１つのモジュールによって実行されるいくつかの機能を有することなどが可能である。したがって、図２１に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
【０２６１】
図２２に、本発明の実施態様を実装するために使用され得るデバイスのアーキテクチャを示す。ヘッドマウントディスプレイはコンピューティングデバイスであり、コンピューティングデバイス上に通常見られるモジュール、たとえば、プロセッサ２２０４、メモリ２２１６（ＲＡＭ、ＲＯＭなど）、１つまたは複数のバッテリ２２０６あるいは他の電源、及び永久記憶装置２２４８（ハードディスクなど）を含む。
【０２６２】
通信モジュールは、ＨＭＤが他のポータブルデバイス、他のコンピュータ、他のＨＭＤ、サーバなどと情報を交換することを可能にする。通信モジュールは、ユニバーサルシリアルバス（ＵＳＢ）コネクタ２２４６、通信リンク２２５２（Ｅｔｈｅｒｎｅｔ（登録商標）など）、超音波通信２２５６、Ｂｌｕｅｔｏｏｔｈ（登録商標）２２５８、及びＷｉＦｉ２２５４を含む。
【０２６３】
ユーザインターフェースは入力モジュール及び出力モジュールを含む。入力モジュールは、入力ボタン、センサ及びスイッチ２２１０、マイクロフォン２２３２、タッチ感応スクリーン（図示しないが、これはＨＭＤを構成または初期化するために使用され得る）、フロントカメラ２２４０、リアカメラ２２４２、視線追跡カメラ２２４４を含む。キーボードまたはマウスなどの他の入出力デバイスは、ＵＳＢまたはＢｌｕｅｔｏｏｔｈなどの通信リンクを介してポータブルデバイスに接続することもできる。
【０２６４】
出力モジュールは、ユーザの目の前に画像をレンダリングするためのディスプレイ２２１４を含む。いくつかの実施態様は、１つのディスプレイ、２つのディスプレイ（各眼に１つ）、マイクロプロジェクタ、または他のディスプレイ技術を含み得る。他の出力モジュールは、発光ダイオード（ＬＥＤ）２２３４（これはＨＭＤの視覚追跡にも使用され得る）、振動−触覚フィードバック２２５０、スピーカー２２３０、及びスピーカーまたはヘッドフォンに配信される音に対して音像定位を実行する音像定位モジュール２２１２を含む。ヘッドフォンなどの他の出力デバイスを、通信モジュールを介してＨＭＤに接続することもできる。
【０２６５】
動き追跡を容易にするために含まれ得る要素は、ＬＥＤ２２３４、１つまたは複数の視覚認識用オブジェクト２２３６、及び赤外ライト２２３８を含む。
【０２６６】
異なるデバイスからの情報は、ＨＭＤの位置を計算するために位置モジュール２２２８によって使用することができる。これらのモジュールは、磁力計２２１８、加速度計２２２０、ジャイロスコープ２２２２、全地球測位システム（ＧＰＳ）モジュール２２２４、及びコンパス２２２６を含む。加えて、位置モジュールは、カメラ及びマイクロフォンでキャプチャされた音または画像データを分析して、位置を計算することができる。またさらに、位置モジュールは、ポータブルデバイスの位置または近傍の他のデバイスの位置を決定するためのテスト、たとえば、ＷｉＦｉのｐｉｎｇテストまたは超音波テストを実行することができる。
【０２６７】
仮想現実生成器２２０８は、位置モジュールによって計算された位置を使用して、前述の仮想現実または拡張現実を生成する。仮想現実生成器２２０８は、他のコンピューティングデバイス（たとえば、ゲームコンソール、インターネットサーバなど）と協働して、ディスプレイモジュール２２１４用の画像を生成し得る。リモートデバイスは、画面上にゲームオブジェクトを生成するための画面更新または命令を送信し得る。
【０２６８】
図２２に示す実施態様はＨＭＤの例示的な実施態様であることを理解されたい。他の実施態様は、異なるモジュール、モジュールのサブセットを利用するか、または関連するタスクを異なるモジュールに割り当て得る。したがって、図２２に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
【０２６９】
図２３は、本開示の様々な実施態様による、ゲームシステム２３００のブロック図である。ゲームシステム２３００は、ネットワーク２３１５を介して１つまたは複数のクライアント２３１０にビデオストリームを提供するように構成される。ゲームシステム２３００は典型的には、ビデオサーバシステム２３２０と、任意選択のゲームサーバ２３２５とを含む。ビデオサーバシステム２３２０は、ビデオストリームを１つまたは複数のクライアント２３１０に最低限のサービス品質で提供するように構成される。たとえば、ビデオサーバシステム２３２０は、ビデオゲーム内の状態または視点を変更するゲームコマンドを受信し、この状態の変更を反映した更新されたビデオストリームをクライアント２３１０に最短の遅延時間で提供し得る。ビデオサーバシステム２３２０は、まだ定義されていないフォーマットを含む、多種多様な代替のビデオフォーマットのビデオストリームを提供するように構成され得る。さらに、ビデオストリームは、多種多様なフレームレートでユーザに提示するように構成されるビデオフレームを含み得る。典型的なフレームレートは、３０フレーム毎秒、６０フレーム毎秒、１２０フレーム毎秒である。ただし、より高いまたはより低いフレームレートが、本開示の代替の実施態様に含まれる。
【０２７０】
本明細書で個別に２３１０Ａ、２３１０Ｂなどと呼ぶクライアント２３１０は、ヘッドマウントディスプレイ、端末、パーソナルコンピュータ、ゲームコンソール、タブレットコンピュータ、電話、セットトップボックス、キオスク、無線デバイス、デジタルパッド、スタンドアロンデバイス、手持ち式ゲームプレイデバイス、及び／または同様のものを含み得る。典型的には、クライアント２３１０は、符号化されたビデオストリームを受信し、そのビデオストリームを復号し、その結果得られるビデオをユーザ、たとえばゲームのプレイヤーに提示するように構成される。符号化されたビデオストリームを受信する処理、及び／またはビデオストリームを復号する処理は、典型的には、個々のビデオフレームをクライアントの受信バッファに記憶することを含む。ビデオストリームは、クライアント２３１０に統合されたディスプレイ上で、またはモニタもしくはテレビなどの別個のデバイス上でユーザに提示され得る。クライアント２３１０は２人以上のゲームプレイヤーをサポートするように任意選択で構成される。たとえば、ゲームコンソールは、２人、３人、４人またはそれ以上の同時プレイヤーをサポートするように構成され得る。これらのプレイヤーはそれぞれ別々のビデオストリームを受信し得、あるいは単一のビデオストリームが、各プレイヤー専用に生成された、たとえば各プレイヤーの視点に基づいて生成されたフレームの領域を含み得る。クライアント２３１０は任意選択で地理的に分散している。ゲームシステム２３００に含まれるクライアントの数は、１または２から数千、数万、またはそれ以上まで幅広く変化し得る。本明細書で使用する場合、「ゲームプレイヤー」という用語はゲームをプレイする人を指すために使用され、「ゲームプレイデバイス」という用語はゲームをプレイするために使用されるデバイスを指すために使用される。いくつかの実施態様では、ゲームプレイデバイスは、ゲーム体験をユーザに配信するために協働する複数のコンピューティングデバイスを指す場合がある。たとえば、ゲームコンソール及びＨＭＤはビデオサーバシステム２３２０と協働して、ＨＭＤを通して見るゲームを配信し得る。一実施態様では、ゲームコンソールはビデオサーバシステム２３２０からビデオストリームを受信し、ゲームコンソールはビデオストリームまたはビデオストリームへの更新を、レンダリングのためにＨＭＤに転送する。
【０２７１】
クライアント２３１０は、ネットワーク２３１５を介してビデオストリームを受信するように構成される。ネットワーク２３１５は、電話ネットワーク、インターネット、無線ネットワーク、電力線ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、プライベートネットワーク、及び／または同様のものを含む任意の種類の通信ネットワークであり得る。典型的な実施態様では、ビデオストリームは、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰなどの標準プロトコルを介して通信される。あるいは、ビデオストリームは独自の規格を介して通信される。
【０２７２】
クライアント２３１０の典型的な例は、プロセッサ、不揮発性メモリ、ディスプレイ、復号ロジック、ネットワーク通信機能、及び入力デバイスを含むパーソナルコンピュータである。復号ロジックは、ハードウェア、ファームウェア、及び／またはコンピュータ可読媒体に記憶されたソフトウェアを含み得る。ビデオストリームを復号（及び符号化）するためのシステムは、当技術分野においてよく知られており、使用される特定の符号化方式に応じて変わる。
【０２７３】
クライアント２３１０は、必須ではないが、受信したビデオを修正するように構成されるシステムをさらに含み得る。たとえば、クライアントは、さらなるレンダリングを実行し、あるビデオ画像を他のビデオ画像に重ね合わせ、ビデオ画像を切り取り、及び／または同様のことを行うように構成され得る。たとえば、クライアント２３１０は、Ｉフレーム、Ｐフレーム、及びＢフレームなどの様々な種類のビデオフレームを受信し、これらのフレームをユーザに表示するための画像に処理するように構成され得る。いくつかの実施態様では、クライアント２３１０のメンバーは、さらなるレンダリング、シェーディング、３−Ｄへの変換、または同様の演算をビデオストリームに実行するように構成される。クライアント２３１０のメンバーは、任意選択で２つ以上の音声またはビデオストリームを受信するように構成される。クライアント２３１０の入力デバイスは、たとえば、片手ゲームコントローラ、両手ゲームコントローラ、ジェスチャ認識システム、視線認識システム、音声認識システム、キーボード、ジョイスティック、ポインティングデバイス、フォースフィードバックデバイス、動き及び／または位置検知デバイス、マウス、タッチスクリーン、ニューラルインターフェース、カメラ、未開発の入力デバイス、ならびに／あるいは同様のものを含み得る。
【０２７４】
クライアント２３１０によって受信されたビデオストリーム（及び任意選択で音声ストリーム）は、ビデオサーバシステム２３２０によって生成され提供される。本明細書の他の場所でさらに説明しているように、このビデオストリームはビデオフレームを含む（また、音声ストリームは音声フレームを含む）。ビデオフレームは、ユーザに表示される画像に有意義に寄与するように構成される（たとえば、適切なデータ構造のピクセル情報を含む）。本明細書で使用する場合、「ビデオフレーム」という用語は、ユーザに表示される画像に寄与する、たとえば、これを生じさせるように構成される情報を主に含むフレームを指すために使用される。「ビデオフレーム」に関する本明細書の教示の大部分は、「音声フレーム」に適用することもできる。
【０２７５】
クライアント２３１０は典型的にはユーザから入力を受け取るように構成される。これらの入力は、ビデオゲームの状態を変更するか、または他の方法でゲームプレイに影響を及ぼすように構成されるゲームコマンドを含み得る。ゲームコマンドは入力デバイスを使用して受け取ることができ、及び／またはクライアント２３１０上で実行される計算命令によって自動的に生成され得る。受け取られたゲームコマンドは、クライアント２３１０からネットワーク２３１５を介してビデオサーバシステム２３２０及び／またはゲームサーバ２３２５に通信される。たとえば、いくつかの実施態様では、ゲームコマンドはビデオサーバシステム２３２０を介してゲームサーバ２３２５に通信される。いくつかの実施態様では、ゲームコマンドの別々のコピーがクライアント２３１０からゲームサーバ２３２５及びビデオサーバシステム２３２０に通信される。ゲームコマンドの通信は任意選択で、そのコマンドの識別情報に依存するものである。ゲームコマンドは任意選択で、音声ストリームまたはビデオストリームをクライアント２３１０Ａに提供するために使用されるものとは異なる経路または通信チャネルを経由してクライアント２３１０Ａから通信される。
【０２７６】
ゲームサーバ２３２５は任意選択で、ビデオサーバシステム２３２０とは異なるエンティティによって運用される。たとえば、ゲームサーバ２３２５は多人数参加型ゲームの発行元によって運用され得る。この例では、ビデオサーバシステム２３２０は、任意選択でゲームサーバ２３２５によりクライアントと見なされ、ゲームサーバ２３２５の視点からは、従来技術のゲームエンジンを実行する従来技術のクライアントに見えるように任意選択で構成される。ビデオサーバシステム２３２０とゲームサーバ２３２５との間の通信は任意選択でネットワーク２３１５を介して行われる。したがって、ゲームサーバ２３２５は、ゲーム状態情報を複数のクライアントに送信する従来技術の多人数参加型ゲームサーバとすることができ、複数のクライアントのうちの１つがゲームサーバシステム２３２０である。ビデオサーバシステム２３２０は、ゲームサーバ２３２５の複数のインスタンスと同時に通信するように構成され得る。たとえば、ビデオサーバシステム２３２０は、複数の異なるビデオゲームを異なるユーザに提供するように構成することができる。これらの異なるビデオゲームのそれぞれは、異なるゲームサーバ２３２５によってサポートされ、及び／または異なるエンティティによって発行され得る。いくつかの実施態様では、ビデオサーバシステム２３２０のいくつかの地理的に分散したインスタンスが、ゲームビデオを複数の異なるユーザに提供するように構成される。ビデオサーバシステム２３２０のこれらのインスタンスのそれぞれは、ゲームサーバ２３２５の同一のインスタンスと通信し得る。ビデオサーバシステム２３２０と１つまたは複数のゲームサーバ２３２５との間の通信は、任意選択で専用の通信チャネルを介して行われる。たとえば、ビデオサーバシステム２３２０は、これら２つのシステム間の通信専用の広帯域幅チャネルを介してゲームサーバ２３２５に接続され得る。
【０２７７】
ビデオサーバシステム２３２０は、少なくともビデオソース２３３０、Ｉ／Ｏデバイス２３４５、プロセッサ２３５０、及び非一時的記憶装置２３５５を備える。ビデオサーバシステム２３２０は、１つのコンピューティングデバイスを含むか、または複数のコンピューティングデバイス間に分散され得る。これらのコンピューティングデバイスは、任意選択でローカルエリアネットワークなどの通信システムを介して接続される。
【０２７８】
ビデオソース２３３０はビデオストリーム、たとえば、ストリーミングビデオまたは動画を形成する一連のビデオフレームを提供するように構成される。いくつかの実施態様では、ビデオソース２３３０はビデオゲームエンジン及びレンダリングロジックを含む。ビデオゲームエンジンはプレイヤーからゲームコマンドを受け取り、受け取ったコマンドに基づいてビデオゲームの状態のコピーを維持するように構成される。このゲーム状態は、ゲーム環境内のオブジェクトの位置、ならびに典型的には視点を含む。ゲーム状態はオブジェクトの特性、画像、色及び／またはテクスチャも含み得る。ゲーム状態は典型的にはゲームルール、ならびにゲームコマンド、たとえば、移動、方向転換、攻撃、フォーカス設定、対話、使用、及び／または同様のものに基づいて維持される。ゲームエンジンの一部は任意選択でゲームサーバ２３２５内に配置される。ゲームサーバ２３２５は、地理的に分散したクライアントを使用する複数のプレイヤーから受信したゲームコマンドに基づいて、ゲームの状態のコピーを維持し得る。これらの場合、ゲーム状態はゲームサーバ２３２５によってビデオソース２３３０に提供され、ゲーム状態のコピーが記憶され、レンダリングが実行される。ゲームサーバ２３２５は、ネットワーク２３１５を介してクライアント２３１０から直接ゲームコマンドを受信し得、及び／またはビデオサーバシステム２３２０を介してゲームコマンドを受信し得る。
【０２７９】
ビデオソース２３３０は典型的にはレンダリングロジック、たとえば、ハードウェア、ファームウェア、及び／または記憶装置２３５５などのコンピュータ可読媒体に記憶されたソフトウェアを含む。このレンダリングロジックは、ゲーム状態に基づいてビデオストリームのビデオフレームを生成するように構成される。レンダリングロジックの全部または一部は、任意選択でグラフィック処理ユニット（ＧＰＵ）内に配置される。レンダリングロジックは典型的には、ゲーム状態及び視点に基づいて、オブジェクト間の３次元空間関係を決定すること、及び／または適切なテクスチャを適用することなどを行うように構成される処理段階を含む。レンダリングロジックは生ビデオを生成し、これは通常はクライアント２３１０へ通信する前に符号化される。たとえば、生ビデオは、Ａｄｏｂｅ  Ｆｌａｓｈ（登録商標）規格、．ｗａｖ、Ｈ．２６４、Ｈ．２６３、Ｏｎ２、ＶＰ６、ＶＣ−１、ＷＭＡ、Ｈｕｆｆｙｕｖ、Ｌａｇａｒｉｔｈ、ＭＰＧ−ｘ．Ｘｖｉｄ．ＦＦｍｐｅｇ、ｘ２６４、ＶＰ６−８、ｒｅａｌｖｉｄｅｏ、ｍｐ３などに従って符号化され得る。符号化処理は、任意選択でリモートデバイス上の復号器への配信のためにパッケージ化されたビデオストリームを生成する。ビデオストリームは、フレームサイズ及びフレームレートによって特徴付けられる。典型的なフレームサイズは８００×６００、１２８０×７２０（たとえば７２０ｐ）、１０２４×７６８を含むが、他の任意のフレームサイズが使用され得る。フレームレートは１秒あたりのビデオフレーム数である。ビデオストリームは異なる種類のビデオフレームを含み得る。たとえば、Ｈ．２６４規格は「Ｐ」フレーム及び「Ｉ」フレームを含む。Ｉフレームはディスプレイデバイス上の全てのマクロブロック／ピクセルをリフレッシュするための情報を含み、Ｐフレームはそのサブセットをリフレッシュするための情報を含む。Ｐフレームは典型的にはＩフレームよりもデータサイズが小さい。本明細書で使用する場合、「フレームサイズ」という用語は、フレーム内のピクセル数を指すものとする。「フレームデータサイズ」という用語は、フレームを記憶するのに必要なバイト数を指すために使用される。
【０２８０】
代替の実施態様では、ビデオソース２３３０はカメラなどのビデオ記録デバイスを含む。このカメラは、コンピュータゲームのビデオストリームに含めることができる遅延ビデオまたはライブビデオを生成するために使用され得る。結果的に得られるビデオストリームは、レンダリングされた画像と、スチルカメラまたはビデオカメラを使用して記録された画像との両方を任意選択で含む。ビデオソース２３３０はまた、ビデオストリームに含められる、以前に記録されたビデオを記憶するよう構成される記憶デバイスを含み得る。ビデオソース２３３０はまた、人などのオブジェクトの動きまたは位置を検出するように構成される、動きまたは位置検知デバイスと、検出された動き及び／または位置に基づいてゲーム状態を決定するまたはビデオを生成するように構成されるロジックとを含み得る。
【０２８１】
ビデオソース２３３０は、他のビデオ上に配置されるように構成されるオーバーレイを提供するように任意選択で構成される。たとえば、これらのオーバーレイは、コマンドインターフェース、ログイン命令、ゲームプレイヤーへのメッセージ、他のゲームプレイヤーの画像、他のゲームプレイヤーのビデオフィード（たとえば、ウェブカメラビデオ）を含み得る。タッチスクリーンインターフェースまたは視線検出インターフェースを含むクライアント２３１０Ａの実施態様では、オーバーレイは仮想キーボード、ジョイスティック、タッチパッド、及び／または同様のものを含み得る。オーバーレイの一例では、プレイヤーの声が音声ストリーム上にオーバーレイされる。ビデオソース２３３０は任意選択で１つまたは複数の音声ソースをさらに含む。
【０２８２】
ビデオサーバシステム２３２０が２人以上のプレイヤーからの入力に基づいてゲーム状態を維持するように構成される実施態様では、各プレイヤーは位置及び視野の方向を含む異なる視点を有し得る。ビデオソース２３３０は、各プレイヤーに各自の視点に基づいて別々のビデオストリームを提供するように任意選択で構成される。さらに、ビデオソース２３３０は、各クライアント２３１０に異なるフレームサイズ、フレームデータサイズ、及び／または符号化を提供するように構成され得る。ビデオソース２３３０は３−Ｄビデオを提供するように任意選択で構成される。
【０２８３】
Ｉ／Ｏデバイス２３４５は、ビデオサーバシステム２３２０が、たとえば、ビデオ、コマンド、情報の要求、ゲーム状態、視線情報、デバイスの動き、デバイスの位置、ユーザの動き、クライアント識別情報、プレイヤー識別情報、ゲームコマンド、セキュリティ情報、音声、及び／または同様のものなどの情報を送信及び／または受信するように構成される。Ｉ／Ｏデバイス２３４５は典型的にはネットワークカードまたはモデムなどの通信ハードウェアを含む。Ｉ／Ｏデバイス２３４５は、ゲームサーバ２３２５、ネットワーク２３１５、及び／またはクライアント２３１０と通信するように構成される。
【０２８４】
プロセッサ２３５０は、本明細書で論じるビデオサーバシステム２３２０の様々な構成要素内に含まれるロジック、たとえばソフトウェアを実行するように構成される。たとえば、プロセッサ２３５０は、ビデオソース２３３０、ゲームサーバ２３２５、及び／またはクライアントクオリファイア（Ｑｕａｌｉｆｉｅｒ）２３６０の機能を実行するようにソフトウェア命令でプログラムされ得る。ビデオサーバシステム２３２０は、プロセッサ２３５０の２つ以上のインスタンスを任意選択で含む。プロセッサ２３５０はまた、ビデオサーバシステム２３２０によって受信されたコマンドを実行し、または本明細書で論じるゲームシステム２３００の様々な要素の動作を調整するようにソフトウェア命令でプログラムされ得る。プロセッサ２３５０は１つまたは複数のハードウェアデバイスを含み得る。プロセッサ２３５０は電子プロセッサである。
【０２８５】
記憶装置２３５５は非一時的なアナログ及び／またはデジタル記憶デバイスを含む。たとえば、記憶デバイス２３５５は、ビデオフレームを記憶するように構成されるアナログ記憶デバイスを含み得る。記憶装置２３５５はコンピュータ可読デジタル記憶装置、たとえば、ハードドライブ、光学ドライブ、またはソリッドステート記憶装置を含み得る。記憶装置２３１５は、（たとえば、適切なデータ構造またはファイルシステムによって）ビデオフレーム、人工フレーム、ビデオフレームと人工フレームとの両方を含むビデオストリーム、音声フレーム、音声ストリーム、及び／または同様のものを記憶するように構成される。記憶装置２３５５は任意選択で複数のデバイス間に分散される。いくつかの実施態様では、記憶装置２３５５は、本明細書の他の場所で論じているビデオソース２３３０のソフトウェアコンポーネントを記憶するように構成される。これらのコンポーネントは、必要な場合に供給されるように準備された形式で記憶され得る。
【０２８６】
ビデオサーバシステム２３２０は任意選択でクライアントクオリファイア２３６０をさらに含む。クライアントクオリファイア２３６０は、クライアント２３１０Ａまたは２３１０Ｂなどのクライアントの能力をリモートで特定するように構成される。これらの能力は、クライアント２３１０Ａ自体の能力と、クライアント２３１０Ａ及びビデオサーバシステム２３２０の間の１つまたは複数の通信チャネルの能力との両方を含むことができる。たとえば、クライアントクオリファイア２３６０は、ネットワーク２３１５を介した通信チャネルをテストするように構成され得る。
【０２８７】
クライアントクオリファイア２３６０は、クライアント２３１０Ａの能力を手動または自動で特定（たとえば、発見）することができる。手動の特定は、クライアント２３１０Ａのユーザと通信することと、能力を提供するようにユーザに依頼することとを含む。たとえば、いくつかの実施態様では、クライアントクオリファイア２３６０は、クライアント２３１０Ａのブラウザ内に画像、テキスト、及び／または同様のものを表示するように構成される。一実施態様では、クライアント２３１０Ａはブラウザを含むＨＭＤである。他の実施態様では、クライアント２３１０Ａは、ＨＭＤに表示され得るブラウザを有するゲームコンソールである。表示されたオブジェクトは、ユーザがクライアント２３１０Ａのオペレーティングシステム、プロセッサ、ビデオ復号器の種類、ネットワーク接続の種類、ディスプレイ解像度などの情報を入力することを要求する。ユーザによって入力された情報はクライアントクオリファイア２３６０に返信される。
【０２８８】
自動の特定は、たとえば、クライアント２３１０Ａ上でエージェントを実行することによって、及び／またはテストビデオをクライアント２３１０Ａに送信することによって行われ得る。エージェントは、ウェブページに埋め込まれた、またはアドオンとしてインストールされたｊａｖａ（登録商標）  ｓｃｒｉｐｔなどの計算命令を含み得る。エージェントは任意選択でクライアントクオリファイア２３６０によって提供される。様々な実施態様では、エージェントは、クライアント２３１０Ａの処理能力、クライアント２３１０Ａの復号及び表示能力、クライアント２３１０Ａとビデオサーバシステム２３２０との間の通信チャネルの遅延時間の信頼性及び帯域幅、クライアント２３１０Ａのディスプレイの種類、クライアント２３１０Ａに存在するファイアウォール、クライアント２３１０Ａのハードウェア、クライアント２３１０Ａ上で実行されるソフトウェア、クライアント２３１０Ａ内のレジストリエントリ、及び／または同様のものを知ることができる。
【０２８９】
クライアントクオリファイア２３６０は、ハードウェア、ファームウェア、及び／またはコンピュータ可読媒体に記憶されたソフトウェアを含む。クライアントクオリファイア２３６０は任意選択で、ビデオサーバシステム２３２０の１つまたは複数の他の要素とは別のコンピューティングデバイス上に配置される。たとえば、いくつかの実施態様では、クライアントクオリファイア２３６０は、クライアント２３１０とビデオサーバシステム２３２０の２つ以上のインスタンスとの間の通信チャネルの特性を特定するように構成される。これらの実施態様では、クライアントクオリファイアによって発見された情報を使用して、ビデオサーバシステム２３２０のどのインスタンスがストリーミングビデオをクライアント２３１０のうちの１つに配信するのに最も適しているかを決定することができる。
【０２９０】
本開示の実施態様は、手持ち式デバイス、マイクロプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ミニコンピュータ、メインフレームコンピュータなどを含む様々なコンピュータシステム構成を使用して実施され得る。本開示は、有線または無線ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することもできる。
【０２９１】
上記の実施態様を念頭に置いて、本開示はコンピュータシステムに記憶されたデータに作用する様々なコンピュータ実施動作を採用できることを理解されたい。これらの動作は、物理量の物理的操作を必要とするものである。本開示の一部を形成する本明細書に記載の動作のいずれもが有用な機械動作である。本開示はまた、これらの動作を実行するためのデバイスまたは装置に関する。装置は要求された目的に合わせて専用に構築することができ、または装置は、コンピュータに記憶されたコンピュータプログラムによって選択的に起動もしくは構成される汎用コンピュータとすることができる。具体的には、様々な汎用機械を、本明細書の教示に従って記述されたコンピュータプログラムと共に使用することができ、または必要な動作を実行するためのより専門化された装置を構築するとより便利であり得る。
【０２９２】
本開示は、コンピュータ可読媒体上のコンピュータ可読コードとして具現化することもできる。コンピュータ可読媒体はデータを記憶することが可能な任意のデータ記憶デバイスであり、このデータは後でコンピュータシステムによって読み取ることができる。コンピュータ可読媒体の例には、ハードドライブ、ネットワーク接続記憶装置（ＮＡＳ）、読み出し専用メモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、及び他の光学及び非光学データ記憶デバイスがある。コンピュータ可読媒体は、コンピュータ可読コードが分散して記憶され実行されるようにネットワーク結合コンピュータシステム上に分散されたコンピュータ可読有形媒体を含むことができる。
【０２９３】
方法の動作は特定の順序で説明したが、他のハウスキーピング動作が動作間に実行され得、または動作がわずかに異なる時刻に行われるように調整され得、もしくはオーバーレイ動作の処理が所望の方法で実行される限り、処理に関連する様々な間隔での処理動作の実施を可能にするシステムにおいて分散され得ることを理解されたい。
【０２９４】
理解を明確にするために前述の開示をある程度詳細に説明したが、添付の特許請求の範囲内で特定の変更及び修正を実施できることは明らかであろう。したがって、本実施態様は限定的ではなく例示的と見なされるべきであり、本開示は本明細書で与えた詳細に限定されるべきではなく、本開示の範囲及び均等物内で修正され得る。
【図１】
0006813670.tif 000002
【図２Ａ−１】
0006813670.tif 000003
【図２Ａ−２】
0006813670.tif 000004
【図２Ｂ】
0006813670.tif 000005
【図３】
0006813670.tif 000006
【図４】
0006813670.tif 000007
【図５Ａ】
0006813670.tif 000008
【図５Ｂ】
0006813670.tif 000009
【図５Ｃ】
0006813670.tif 000010
【図５Ｄ】
0006813670.tif 000011
【図５Ｅ】
0006813670.tif 000012
【図６Ａ】
0006813670.tif 000013
【図６Ｂ】
0006813670.tif 000014
【図６Ｃ】
0006813670.tif 000015
【図７】
0006813670.tif 000016
【図８】
0006813670.tif 000017
【図９】
0006813670.tif 000018
【図１０】
0006813670.tif 000019
【図１１Ａ】
0006813670.tif 000020
【図１１Ｂ】
0006813670.tif 000021
【図１２Ａ】
0006813670.tif 000022
【図１２Ｂ】
0006813670.tif 000023
【図１２Ｃ】
0006813670.tif 000024
【図１２Ｄ】
0006813670.tif 000025
【図１３】
0006813670.tif 000026
【図１４】
0006813670.tif 000027
【図１５】
0006813670.tif 000028
【図１６】
0006813670.tif 000029
【図１７】
0006813670.tif 000030
【図１８】
0006813670.tif 000031
【図１９】
0006813670.tif 000032
【図２０】
0006813670.tif 000033
【図２１】
0006813670.tif 000034
【図２２】
0006813670.tif 000035
【図２３】
0006813670.tif 000036