(57)【要約】  コンピューティングデバイス上のネイティブまたはノンネイティブクライアントの両方にジェスチャー及び頭部の位置に関するデータを提供することを可能にする追跡アーキテクチャが提供されている。供給路コンポーネントは、生画像データ及びセンサデータを取得し、そのデータを処理されるように同期して、例えばデバイスの入力に相当し得る位置及び／または運動データを特定することができる。このデータは、イベントパブリッシャー及びイベントプロバイダなどの別個のコンポーネントによって処理することができ、その各々が、位置、動き及び／または生センサデータのフィルタリングをすることで１セットのイベントデータを生成することが可能である。イベントデータはその後、登録されたリスナーに公開される、またはポーリングリクエストに応答して提供することができる。頭部の座標、ジェスチャーデータ及び他のそのような情報は、１つまたは複数のインターフェースレイヤを介して伝えることができ、そのデータがデバイス上のノンネイティブクライアントによって処理されることを可能にする。【選択図】図３
2017525024.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによって実行される際、
カメラまたはモーションセンサの少なくとも一方からデータを受け取るように構成された第１のハードウェアインターフェースを含む複数のハードウェアインターフェースと、
前記第１のハードウェアインターフェースからのセンサデータを記憶するシンクロナイザと、
画像および前記センサデータを処理することで、頭部の位置またはコンピューティングデバイスの動きのうちの少なくとも一方に相当する入力データを生成するエンジンと、
第１のイベントデータを公開するように構成されたイベントパブリッシャーと、
第２のイベントデータとして第２のフィルタリング後の入力データを提供するように構成されたイベントプロバイダとを提供する指示を含むメモリとを備えるコンピューティングデバイス。
【請求項２】
実行される際の前記指示がさらに、前記コンピューティングデバイスに、
少なくとも１つのポリシーに従って前記コンピューティングデバイスの動作を調節するように構成され、前記複数のハードウェアインターフェース、前記シンクロナイザおよび前記エンジンがデータ供給路の一部であるポリシーマネージャーを提供させ、
前記ポリシーマネージャーが、前記少なくとも１つのポリシーに従って前記供給路を選択式に作動させるように構成される、請求項１に記載のコンピューティングデバイス。
【請求項３】
実行される際の前記指示がさらに、前記コンピューティングデバイスに、
プルクライアントからポーリングリクエストを受信し、ポーリングプロバイダに前記第２のイベントデータを提供させるように構成された少なくとも１つのインターフェースレイヤを設けるようにさせ、前記少なくとも１つのインターフェースレイヤが前記ポーリングリクエストに応答して前記プルクライアントに前記第２のイベントデータを送信するようにさらに構成される、請求項１に記載のコンピューティングデバイス。
【請求項４】
第１のハードウェアインターフェースを介してセンサデータを受信し、前記センサデータがコンピューティングデバイスの少なくとも１つのモーションセンサを利用して取得されることと、
第２のハードウェアインターフェースを介して画像データを受信し、前記画像データが前記コンピューティングデバイスのカメラを利用して取得されることと、
前記コンピューティングデバイスの少なくとも１つのプロセッサを利用して、前記画像データと前記センサデータとを処理することで入力データを生成することと、
前記入力データをパブリッシャーコンポーネントおよびポーリングコンポーネントに送信することと、
前記パブリッシャーコンポーネントを利用して、第１のイベントデータを受信するように登録された少なくとも１つのリスナークライアントに対して前記入力データを第１のイベントデータとして利用可能にすることと、
プルクライアントからのポーリングリクエストに応答して、かつ前記ポーリングコンポーネントを利用して、前記入力データに少なくとも一部基づいた第２のイベントデータを提供することとを含む、コンピュータ実装方法。
【請求項５】
前記センサデータをシンクロナイザコンポーネントに記憶することと、
前記センサデータの受信の時間を示す時間情報を記憶することと、
前記画像データを受信することと、
前記時間情報を伴う前記センサデータと、前記画像データをエンジンに送信することで前記入力データを生成することとをさらに含む、請求項４に記載のコンピュータ実装方法。
【請求項６】
少なくとも１つの第１のフィルタを利用して前記入力データと前記センサデータとを処理することで使用すべき入力データを平滑化して前記第１のイベントデータを生成することと、
少なくとも１つの第２のフィルタを利用して前記入力データと前記カメラデータとを処理することで使用すべき入力データを平滑化して前記第１のイベントデータを生成することとをさらに含む、請求項４に記載のコンピュータ実装方法。
【請求項７】
前記第１の入力データまたは前記第２の入力データのうちの少なくとも一方が、動きに適応性のある融合フィルタ、パススルーフィルタ、有限インパルス応答（ＦＩＲ）フィルタまたは固定フィルタのうちの少なくとも１つを利用してフィルタリングされる、請求項６に記載のコンピュータ実装方法。
【請求項８】
前記入力データが、頭部の位置または前記コンピューティングデバイスの動きのうちの少なくとも一方に相当し、前記リスナークライアントおよび前記プルクライアントがイネーブルにされて、少なくとも一部が前記第１のイベントデータまたは前記第２のイベントデータのうちの少なくとも一方に基づいて、頭部の位置の変化またはジェスチャーのうちの少なくとも一方を特定する、請求項４に記載のコンピュータ実装方法。
【請求項９】
前記パブリッシャーコンポーネントを利用して少なくとも１つのリスナーマップを分析して前記第１のイベントデータを提供する少なくとも１つのリスナークライアントを特定し、前記少なくとも１つのリスナーマップがさらに、前記少なくとも１つのリスナークライアントのためのインターフェース情報をさらに含んでいることをさらに含む、請求項４に記載のコンピュータ実装方法。
【請求項１０】
前記第２のイベントデータが、前記ポーリングリクエストに応答するという条件で、少なくとも１つのインターフェースレイヤおよび少なくとも１つのプロセス間通信（ＩＰＣ）レイヤを通過するようにし、前記イベントデータがさらに、前記プルクライアントによって受信されるように前記イベントデータを修正するために、少なくとも１つの言語インターフェースコンポーネントを通過することが可能であることをさらに含む、請求項４に記載のコンピュータ実装方法。
【請求項１１】
前記第１のイベントデータまたは前記第２のイベントデータの特有のタイプの少なくとも一方を聞くように構成された少なくとも１つのデータマネージャーコンポーネントをリスナーとして登録することをさらに含む、請求項４に記載のコンピュータ実装方法。
【請求項１２】
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによって実行される際、コンピューティングデバイスに、
第１のハードウェアインターフェースを介して、前記コンピューティングデバイスの少なくとも１つのモーションセンサを利用して取得されるセンサデータを受信させ、
第２のハードウェアインターフェースを介して、前記コンピューティングデバイスのカメラを利用して取得される画像データを受信させ、
前記コンピューティングデバイスの少なくとも１つのプロセッサを利用して、前記画像データと前記センサデータを処理して入力データを生成させ、
第１のイベントデータを受信するように登録された少なくとも１つのリスナークライアントに第１のイベントデータとして前記入力データを提供させ、
プルクライアントからのポーリングリクエストに応答して第２のイベントデータとして前記入力データを提供させる指示を含むメモリとを備えるコンピューティングデバイス。
【請求項１３】
実行される際の前記指示がさらに前記コンピューティングデバイスに、
前記センサデータをシンクロナイザコンポーネントに記憶させ、
前記センサデータの受信の時間を示す時間情報を記憶させ、
前記画像データを受信させ、
前記時間情報を伴う前記センサデータと、前記画像データをエンジンに転送することで前記入力データを生成させる、請求項１２に記載のコンピューティングデバイス。
【請求項１４】
実行される際の前記指示がさらに前記コンピューティングデバイスに、
少なくとも１つのモニタリングコンポーネントを利用して前記画像データと前記センサデータを分析することで、少なくとも１つのモーションセンサまたはカメラがエラー状態にあることを判定させ、前記少なくとも１つのモニタリングコンポーネントが、前記少なくとも１つのモーションセンサまたはカメラがエラー状態から出るようにするように試みるように構成される、請求項１２に記載のコンピューティングデバイス。
【請求項１５】
実行される際の前記指示がさらに前記コンピューティングデバイスに、
前記入力データを処理して前記第１のイベントデータまたは前記第２のイベントデータの少なくとも一方を生成させ、前記第１のハードウェアインターフェースを介して受信した前記センサデータに少なくとも一部基づいて前記入力データを平滑化するように前記入力データが処理されており、前記入力データは、動きに適応性のある融合フィルタ、パススルーフィルタ、有限インパルス応答（ＦＩＲ）フィルタまたは固定フィルタのうちの少なくとも１つを利用して処理されている、請求項１２に記載のコンピューティングデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２０１４年６月１７日出願の「ＡＲＣＨＩＴＥＣＴＵＲＥＳ ＦＯＲ ＩＮＰＵＴ ＴＲＡＣＫＩＮＧ」と題する米国特許出願番号第１４／３０７，２８４号に対して優先権を主張しており、その全体があらゆる目的のために参照により本明細書に組み込まれる。
【背景技術】
【０００２】
ユーザは、様々なタスクのために携帯型コンピューティングデバイスにますます依存するようになっているため、ユーザがこのようなデバイスと対話し、これを制御することができる方法を改善することが望ましい。しかしながらユーザがそのようなデバイスと対話する能力は変化するため、対話のための情報が管理され、そのような情報を消費するアプリケーション及びサービスに伝える方法を改善させるよう対応する必要がある。
【０００３】
本開示による種々の実施形態が、図面を参照して記載される。
【図面の簡単な説明】
【０００４】
【図１（ａ）】図１（ａ）は、種々の実施形態の態様を利用することができる一例の携帯型コンピューティングデバイスを示す。
【図１（ｂ）】図１（ｂ）は、種々の実施形態の態様を利用することができる一例の携帯型コンピューティングデバイスを示す。
【図２（ａ）】図２（ａ）は、種々の実施形態により利用することができる一例の頭部追跡アプローチを示す。
【図２（ｂ）】図２（ｂ）は、種々の実施形態により利用することができる一例の頭部追跡アプローチを示す。
【図２（ｃ）】図２（ｃ）は、種々の実施形態により利用することができる一例の頭部追跡アプローチを示す。
【図２（ｄ）】図２（ｄ）は、種々の実施形態により利用することができる一例の頭部追跡アプローチを示す。
【図２（ｅ）】図２（ｅ）は、種々の実施形態により利用することができる一例の頭部追跡アプローチを示す。
【図３】種々の実施形態により利用することができる一例のサービスアーキテクチャを示す。
【図４】種々の実施形態により利用することができる一例の頭部追跡サービスのコンポーネントを示す。
【図５（ａ）】図５（ａ）は、種々の実施形態による追跡サービスを利用することができるクライアントアーキテクチャの例を示す。
【図５（ｂ）】図５（ｂ）は、種々の実施形態による追跡サービスを利用することができるクライアントアーキテクチャの例を示す。
【図６】種々の実施形態の態様により利用することができるクライアントが追跡データを取得することを可能にする一例のプロセスを示す。
【図７】種々の実施形態を利用することができるクライアントデバイスの一例のコンポーネントを示す。
【発明を実施するための形態】
【０００５】
本開示の種々の実施形態によるシステム及び方法は、ユーザ入力及び行動に関するデータを取得し、電子デバイス上で実行しているアプリケーション及びプロセスにその情報を伝えるための従来のアプローチにおける上記に参照した及びその他の欠陥のうちの１つまたは複数を克服する。詳細には、種々の実施形態は、ジェスチャー、頭部の動作及び他の動きならびに／あるいは行動に関するデータが管理され、かつ様々なクライアントに提供されることを可能にするアーキテクチャを提供する。このようなアーキテクチャは、カメラ及びモーションセンサなどのコンポーネントからデータを受け取り、そのデータを分析し、相対的な頭部の位置、ユーザのジェスチャー及びデバイスの回転などの情報を特定することができる。アーキテクチャはまた、信頼性を高めるために、種々のフィルタを利用してデータを平滑化することもできる。アーキテクチャは、プルアプローチとプッシュアプローチの両方を使用してデータを公開することができ、これはネイティブクライアントと、ノンネイティブクライアントの両方に提供することができる。別個の管理コンポーネントは、ユーザのジェスチャー、頭部の動作及びデバイスの回転などの異なるタイプの入力に使用することができる。アーキテクチャはまた、入力データの相関を改善するために異なるソースからのデータを同期させることもできる。
【０００６】
種々の実施形態によって提供され得るように、種々の他の機能及び利点が以下に記載され、提示される。
【０００７】
図１Ａ及び図１Ｂはそれぞれ、本明細書で考察されて提示される種々の実施形態を巧みに利用することができる一例の携帯型コンピューティングデバイスの前方図と後方図である。スマートフォンが示されているが、種々の実施形態の態様を有利に利用することができる種々のタイプの電子デバイスであって良く、とりわけタブレットコンピュータ、ファブレット、電子ブックリーダ、デスクトップコンピュータ、ノートブックコンピュータ、パーソナルデータアシスタント、ビデオゲームコンソール、テレビジョンセットトップボックス、スマートテレビジョン、ウエアラブルコンピュータ（例えばスマートウォッチ及び眼鏡）、携帯型メディアプレーヤ及びデジタルカメラが含まれ得ることを理解されたい。
【０００８】
図１Ａの前方図１００に示されるように、一例のスマートフォン１００は、前方側にディスプレイスクリーン１０４を有し、これは通常の作動においてはディスプレイスクリーンに直面しているユーザに（例えばコンピューティングデバイスのディスプレイスクリーンと同じ側の）情報を表示する。ディスプレイスクリーンは典型的にはタッチまたはジェスチャー入力を可能にするタッチセンシティブスクリーンであり、ディスプレイスクリーン１０４は、デバイスのケーシング１０２または筐体と同一面である、またはそこからくぼませる場合もある。筐体は典型的にはプラスチックであるが、アルミニウム、ポリマー、金属及びガラスなどの材料も様々なデバイスにおいて使用されている。デバイスは、メインの正面カメラ１０６を有し、これは一般に、作動中にユーザの写真及び／またはビデオを撮るのに使用される主要なカメラである。正面カメラ１０６は一般に、少なくとも８ビットの色の深さと共に４メガピクセルの解像度またはそれ以上のものを有するカメラなどのフルカラーで高解像度のカメラであってよい。一例のデバイスはまた、１セットの比較的低い解像度の全整色感光ジェスチャーカメラ１１２も含んでおり、そのような可能性の中でも正面カメラと同様の性能またはそれを超える性能を備えたカメラを種々の実施形態の範囲内で同様に使用することができる。ジェスチャーカメラは、全整色感光性であり、ジェスチャーカメラは、頭部追跡及びユーザ識別などのプロセスのために使用することができ、これらのプロセスは、そのようなカメラを使用することで適切な結果を伴うように実施することができるため、より低い解像度（例えば３ＭＰ以下）を利用することができる。解像度がより低くカラーが少ないカメラは一般に正面カメラなどのカメラと比べて価格が安く、機能及び分析するのに少ないリソースしか必要としない。各々のカメラ、または他の画像取り込み素子は、他の可能性の中でも例えば電荷結合素子（ＣＣＤ）、ＣＭＯＳデバイス、モーション検出センサまたは赤外線センサであってよい。種々の実施形態の範囲内で、同様のまたは異なる位置にあり、同様のまたは異なるタイプのより少ないまたは追加のカメラがある場合もある。一部の実施形態において、少なくとも１つの撮像素子は、少なくとも１つの広角の光学素子、例えばカメラが広範囲の角度、例えば１８０度などにわたって画像及び／または画像データを取り込むことを可能にする魚眼レンズを含むことができる。さらに各々の画像取り込み素子は、素早く連続して次のフレームを取り込むように構成されたデジタルスチールカメラ及び／またはストリーミングビデオなどのビデオを取り込むことが可能なビデオカメラを備える場合もある。ジェスチャーカメラ１１２は対で使用することで立体カメラとして機能することができ、これを使用して、立体（「ステレオ」）カメラによって取り込まれた画像内に表される物体に関する深度マップを生成するのに有益であり得るような深さまたは不一致情報を特定することができる。
【０００９】
一例のコンピューティングデバイスは、少なくとも１つのマイクロフォン１１０、またはデバイスのユーザが話す言葉や命令、デバイスの近くでかかっている音楽などの音声データを取り込むことができる他の音声取り込みデバイスを含む。この例では、マイクロフォンは、ディスプレイスクリーンと同じデバイスの側に配置されることで、マイクロフォンは典型的には、デバイスのユーザが話す言葉をより適切に取り込むことが可能になる。少なくとも一部の実施形態では、マイクロフォンは、ほぼ直にマイクロフォンの前方から音情報を取り込み、その他の方向からは制限された量の音しか拾い上げない指向性マイクロフォンであり得る。マイクロフォンは、様々な実施形態におけるデバイスの任意の領域、面または縁部の任意の適切な表面に位置決めされる可能性があり、複数のマイクロフォンを音声の記録及びフィルタリングの目的などで使用することができることを理解されたい。デバイスはまた、音楽、電話での会話などの音声を再生するための少なくとも１つのスピーカー１０８を含むことができる。図１Ｂの後方図１５０に示されるように、スマートフォンはまた、デバイスの裏側から画像を取り込むための後ろ向きのカメラ１５２を含む場合もある。このカメラは一般に、正面カメラと少なくとも同じの性能を有し、多くの実施形態ではより高い解像度を有する場合もある。デバイスは、画像取り込み及び取得を助けるための他のコンポーネント、デバイス付近の周辺の光の量を特定する光センサ１５４、フラッシュ要素（図示せず）及び他のこのようなコンポーネントなどを含む場合もある。
【００１０】
このようなデバイスにおける種々のコンポーネントの有用性によって、これらのデバイスとの対話のための追加の及び／または改善されたアプローチが可能になる。例えばあるデバイスは、ユーザがそのデバイスに対する場所に基づいてディスプレイスクリーン上に情報を与える場合がある。ユーザの頭部が所定の時間内に検出されなかった場合、そのデバイスは電源を切る場合もある。デバイスはまた、ユーザの頭部の動きまたはデバイスを傾ける作用に応答して追加の情報を表示するなど、デバイスの動きを入力として同様に受け入れることもある。これらの入力機構は、種々のカメラまたはセンサからの情報に頼ることで、動き、ジェスチャー及び頭部の動作などの事柄を特定することができる。
【００１１】
一例において、単一のカメラを使用して取り込まれた１つまたは複数の画像を使用してユーザの頭部の相対的な方向を特定することができる。三次元でのこの位置を得るために、頭部までの距離を同様に特定することが必須であり得る。単一のカメラから見た特徴部の間隔に基づいて推定値を作成することができるが、例えば多くの状況において、より正確な距離情報を得ることが望ましい場合がある。種々の特徴部または地点までの距離を特定するための１つの方法は、立体撮像、すなわち三次元撮像を利用することであるが、種々の実施形態の範囲内で種々の他の距離または深さ測定プロセスを同様に使用することもできる。少なくとも一部が重なり合う視野を有する任意の対のカメラに関して、三次元撮像は、２つの異なる視野または視点から１つまたは複数の物体に関する画像情報を取り込み、その情報を結合して立体または「３Ｄ」画像を生成することによって実施することができる。少なくとも一部の実施形態において、既知の較正基準を利用して撮像し、１つまたは複数のカメラの光学軸を調節して、これらの軸がほぼ平行になるようにすることなどによって、慎重な配置及び較正を通して視野を最初に一致させることができる。カメラはよって対応したカメラであってよく、これにより視野及び主軸が位置合わせされており、解像度及び種々の他のパラメータは、これらのカメラの各々に関して同様の値を有する。２つ以上のカメラを使用することで三次元または立体画像情報を取り込むことで三次元ポイントデータまたは不一致情報を提供することができ、これらの情報を利用して、深度マップを生成する、あるいはそうでなければカメラから種々の特徴または物体までの距離を特定することができる。所与のカメラの対に関して、対になった各々のカメラによって取り込まれたそれぞれの画像を使用して少なくとも１つの物体の立体画像を生成することができる。少なくとも１つの物体の距離の測定はこの場合、各々の立体画像を利用して特定することができる。
【００１２】
図２（ａ）から図２（ｅ）は、コンピューティングデバイスに対するユーザの頭部の相対的な位置を特定するための一例のアプローチを示している。図２（ａ）に示される状況２００において、コンピューティングデバイスは、ユーザ（またはカメラの視野の範囲内にある他の人の）の頭部２０２の表示を含んだ立体画像データを取り込むことが可能な一対の立体カメラ２０４を含む。これらのカメラは互いに対してずらされていることから、所与の距離までの物体は、各々のカメラによって取り込まれた画像の中で異なる場所に現れることになる。例えば第１のカメラからユーザの顔の地点までの方向２０６は、第２のカメラから同一地点までの方向２０８とは異なり、これにより、異なるカメラによって取り込まれた画像において異なる場所に顔の表示が生じることになる。例えば図２（ｂ）に示される画像２１０において、ユーザの特徴部は、図２（ｃ）に示される画像２２０におけるユーザの対応する特徴部の表示に対して画像内でわずかに右側に現れることになる。特徴部がカメラに近づく程、２つの画像におけるこのような特徴部の表示のずれは大きくなる。例えばカメラに最も近い鼻は、最も大きなずれまたは不一致を有する可能性がある。不一致の大きさを利用して、本明細書の他の場所で考察されるようにカメラからの距離を特定することができる。このようなアプローチを用いてユーザの顔の様々な部分または特徴部までの距離を特定することによって、深度マップを生成することが可能なり、これは頭部の表示に相当する画像内の各々のピクセルに関して、そのピクセルによって表される頭部の部分までの距離を特定することができる。他の場所で述べたように、種々の実施形態の態様に関して使用されるカメラは、位置、配向、距離または１つまたは複数の物体の配置に関するデータを取り込むまたは取得することが可能な適切なデバイスまたはセンサを含むことができ、ＣＭＯＳセンサ、赤外線（ＩＲ）センサ、飛行時間センサ、熱撮像センサ、光及び／または音声のための受信センサなどを含む場合がある。
【００１３】
様々な実施形態において、ユーザの頭部を識別するための種々のアプローチを利用することができる。例えば、画像を分析してユーザの頭部に相当し得る楕円形状を位置決めすることができる、あるいは画像マッチングを使用して、そのユーザの１つまたは複数の既存の画像に対して取り込まれた画像データを比較することによって特定のユーザの顔を認識することを試みることもできる。別のアプローチは、人の頭部または顔の固有の特徴部を識別し、その後これら特徴部の位置を利用してユーザの頭部の相対的な位置を特定するように試みる。例えば一例のアルゴリズムは、図２（ｄ）及び図２（ｅ）の一例の画像２３０、２４０に示されるように、左側のカメラと、右側のカメラが取り込んだ画像を分析することで、ユーザの顔の固有の特徴部２３４、２４４の位置を突き止めることを試みることができる。一方の画像における特徴部の互いに対する相対的な位置は、許容可能な大きさの偏差の範囲内で他方の画像における対応する特徴部の相対的な位置と一致すべきである。これらの及び／または他の特徴を使用して、頭部の位置に関して及び追跡の目的で１つまたは複数の地点または領域、ユーザの顔を取り囲む境界ボックス２３２、２４２または各々の画像におけるユーザの目の間の地点などを特定することができ、他にもそのような選択肢はあるが、これらを頭部の位置として示すことができる。各々の画像における境界ボックス及び／または示される頭部の位置の不一致は、頭部までの距離も同様に表すことができるため、頭部に関する位置を三次元で特定することができる。
【００１４】
しかしながらアプリケーションが頭部の位置データを利用することを可能にするためには、その位置を特定するために適切なセンサデータまたは画像データを取得し分析する必要がある。この情報は次に、これらのアプリケーションまたはクライアントにとって適切な方法で伝達させる必要がある。この情報を消費するネイティブまたはノンネイティブクライアントの両方が存在するため、情報は、複数の異なるチャネルに沿って様々な方法で提供する必要があり得る。さらに、ユーザによって行われるジェスチャーまたはコンピューティングデバイス自体の動きなどと同様に経時的に追跡することが望ましい別のタイプの入力または動作が存在する場合もある。このようなタイプの入力の各々は、少なくとも１つのモーションセンサによって提供される対応するデータを有することができ、これは適切なクライアント及び／またはアプリケーションに有益となるように取得される、分析される及び処理される必要がある。このようなデータに対して種々の他の操作及び／または処理が同様に行われることが望ましい場合もある。
【００１５】
したがって種々の実施形態によるアプローチは、頭部の追跡またはジェスチャー入力にとって有益であり得るなどの入力追跡に使用することができるアーキテクチャを提供する。このようなアーキテクチャは、コンピューティングデバイスの種々のハードウェアコンポーネントからデータを受け入れ、そのデータを処理することができるため、そのデータは様々なタイプのクライントによって消費することができる。このアーキテクチャはまた、これによりこれらのクラアントがデータを消費することができる種々のチャネルまたは方法を提供することもできる。
【００１６】
例えば図３は、種々の実施形態によって利用することができる一例のアーキテクチャ３００を示している。この例において、モーションセンサまたはカメラあるいはセンサスタックなどの１つまたは複数のハードウェアコンポーネントからの情報は、追跡サービス３１６の供給路３２４に受信させることができる。モーションセンサは、少なくとも１つのモーションセンサなどの（ジャイロスコープ、加速度計、慣性センサ及び／または電子コンパスなど）いくつかの異なるセンサのいずれかを含むことができる。カメラは、少なくとも１つの正面カメラ、後ろ向きのカメラまたはジェスチャーカメラなどの任意の適切なカメラを含むことができる。カメラスタック３２６またはセンサスタック３２８などの適切なスタックからデータを供給し、供給路３２４に受信させることができる。多くの場合、供給路に受信されるデータは、センサから受信した生データであり、これはカメラの場合、画像データならびに画像、カメラの設定などに関するメタデータを含むことができる。種々のセンサからの情報は供給路３２４内で結合され、１つまたは複数のコンポーネント、この場合イベントパブリッシャー３２０及び出力マルチプレクサ３２２へと伝えられ、これらはリスナーマネージャーとして機能することができ、この場合リスナーは追跡サービスに記録させることができる。イベントパブリッシャー３２０はデータを分析し、そのデータをバインダーレイヤなどの少なくとも１つのプロセス間通信（ＩＰＣ）レイヤ３１４を介して、例えば「リスナー」クライアント３０８に公開することを可能にすることができる。少なくとも１つの実施形態におけるリスナークライアントは、このサービスによって公開されたイベントを受信するように登録された任意の適切なクライアントであってよい。イベントパブリッシャーは、更新された頭部の位置またはジェスチャー情報などのイベントを公開することができる。リスナークライアント３０８はこの情報を利用して、１つまたは複数のインターフェース要素が表示される方法、ユーザに伝達すべき情報の選択などの様々な種類の情報を更新することができる。一例の実装態様はまた、イベントプロバイダまたは「マルチプレクサ」３２２も含んでおり、これは、別のイベントパブリッシャーのように機能して供給路から入力信号を受け取り、処理後、Ｊａｖａ（登録商標）、クライアント３０２などポーリングまたは別のそのようなプロセスを介して、クライアント３０２などの種々の「プル（ｐｕｌｌ）」クライアントにその情報を転送することができる。プルクライアントは、イベントデータを得るために追跡サービスを（直接または間接的に）呼び出すことが可能な任意の適切なクライアントであってよい。並行処理するコンポーネントは、プッシュアプローチとプルアプローチの両方を介して、異なるクライアント（または同一のクライアント）に提供すべき更新後のデータを提供する。
【００１７】
この例において、ポーリングインターフェースコール及びパブリッシュインターフェースコールなどのコールは、ここではファサードレイヤ３１８などの指定されたインターフェースレイヤを介して伝わることができ、これらのコールは、そのような選択肢の中でもＩＰＣレイヤ３１４のクライアント側にある対応するサービスインターフェースレイヤ３１２を通過することができる。図３に示されるように、ネイティブクライアント（頭部追跡サービスと同一のプロバイダによって提供された、同一のデバイス上に設置された、または特定の動作中のシステムプラットフォームに固有のクライアントなど）は、少なくとも一部の実施形態において、リスナーまたはプルクライアントとして作用することができ、それらをイネーブルにすることで追跡サービス３１６を直接呼び出し、この追跡サービスは少なくとも一部の実施形態において１つまたは複数のソフトウェアパッケージの形態を採る場合もあるが、他の実施形態では、コンポーネント及びプロセスの少なくとも一部は、少なくとも一部をハードウェアを介して実装することもできる。Ｊａｖａで実装されるクライアントなどのノンネイティブクライアントも同様にリスナーまたはプルクライアントとして機能することができるが、これらのクライアントは、少なくとも１つの追加のインターフェースレイヤ、Ｊａｖａクライアントがネイティブクライアント及び追跡サービスなどのコンポーネントを呼び出すことを可能にするＪａｖａネイティブインターフェース（ＪＮＩ）レイヤ３０４などを介して通信する必要がある場合がある。ＪＮＩを利用することで、例えば標準Ｊａｖａクラスライブラリが頭部追跡サービス固有の機能またはライブラリなどをサポートしない場合があることを説明することができる。本明細書の別の場所でより詳細に考察するように、Ｊａｖａクライアント（または他のノンネイティブクライアント）はまた、特定のタイプのイベントを聞き、そのデータをノンネイティブクライアントに伝えるように構成された追跡マネージャー、頭部追跡マネージャー及びジェスチャーマネージャーなどの種々のデータマネージャーを利用する場合もある。これらのマネージャーは、ポリシーサービス及びサービスファサードなどの種々のポリシーコンポーネント３０６と協働することで、本明細書の別の場所でより詳細に考察するようにオーバーライドインターフェースを呼び出すなど、頭部追跡サービスを呼び出す場合もある。実装及び／または利用することができるポリシーの例は、本明細書において後に考察する。
【００１８】
図４は、図３に関して記載されるものなどの追跡サービスの一例の実装態様４００の図を示している。同様の要素に関する参照番号は説明を容易にするために図面において持ち越されているが、これは単に簡便にするために行われているのであって種々の実施形態に対する限定であることは意図されていないことを理解されたい。さらに、説明の目的で、追跡サービスは説明の目的で頭部追跡に関して主に考察されるが、追跡システムは追加としてまたは代替として、ジェスチャー、のぞき見及び本明細書の別の場所で考察され提示される他のそのような入力に関するデータを提供することもできることを理解されたい。この例において、供給路３２４は、追跡サービスの少なくとも一部を通るデータの流れの制御を担うことができ、コンピューティングデバイス上のネイティブカメラスタックと相互作用するためのカメラハードウェアインターフェース４０２、ならびにネイティブセンサスタックと相互作用するためのセンサハードウェアインターフェース４０４を含むように示されている。考察するように、モーションセンサの例には、中でもジャイロスコープ、加速度計、慣性センサ、磁気形及び電子コンパスが含まれる。これらのコンポーネントは、それぞれのデバイスから生データを受け取ることができ、これはシンクロナイザコンポーネント４０８に供給することができる。シンクロナイザは、カメラフレーム間で受信されるセンサデータに関してバッファを形成するまたは利用することができる。カメラが概ね１秒に３０または６０回のフレームレートで稼働し、これはモーションセンサデータが受信される頻度著しく遅い可能性があるため、シンクロナイザは、多くのデバイスに関して有利であり得る。さらに１つまたは複数のカメラから受信されるデータは一般に、１つまたは複数のモーションセンサから受信されるデータと異なる回数受信されることになる。先のカメラフレーム（及び一部の実施形態においては場合によって先のカメラフレームも同様に）が、データ処理エンジン４１０に伝えることができるデータオブジェクトに結合されるため、シンクロナイザは、次のカメラフレームが受信されるまで、タイムスタンプまたは他のそのようなデータを利用して最近のモーションセンサデータ（例えばジャイロスコープデータ）をバッファに保留し、新たに受信されたカメラフレーム及び受信されたセンサデータをパッケージすることができる。入ってくるデータの非同期の性質にこの場合対処する必要がないエンジン４１０などのコンポーネントにとって、シンクロナイザの利用は有利である。そのようなエンジンの動作に関するさらなる詳細が以下で考察される。エンジン４１０は、プラグ着脱可能なコンポーネントであり得るため、必要に応じて他のエンジンをプラグ着脱させる、または取り外すこともできる。
【００１９】
データ処理エンジン４１０は、シンクロナイザ４０８からデータオブジェクトを受け取り、そのデータオブジェクトにおけるデータに対して、画像フレームから頭部の位置を突き止める及び／または抽出するなどの１つまたは複数の機能を実施するように試みることができる。例えばこの例におけるエンジンは、図２に関して考察したようなプロセスを利用して、入力カメラ画像に対して顔検出及び特徴部の抽出を実施するように試みることができる。一部の実施形態において、１つまたは複数のクライアントによって特定することが可能であるように、データを処理するのに複数のエンジンが利用可能である場合もある。一部の実施形態において、複数のエンジンが分析または結合されたデータ及びその結果を処理することで全体の精度を高めることを試みる場合もある。各々のエンジンは、一部の実施形態において追跡サービス３１６によって使用されるライブラリの形態を採る場合がある。顔、頭部及び／または特徴部を検出する際、エンジン４１０は、例えば「入力」データとしてデータをパッケージし、この入力データをイベントパブリッシャー３２０及び出力マルチプレクサ３２２によって実装される１つまたは複数のリスナーに転送することができる。一部の実施形態において、入力データは、顔及び特徴部の地点が検出された画像／フレーム空間における座標に相当する、または一部の実施形態では実空間における物体の座標（例えばｘ、ｙ、ｚ）に相当する場合もある。一部の実施形態において、１つまたは複数の更新されたカメラ及び／またはセンサ設定が、それぞれのインターフェースを介して、特定のカメラまたはセンサに作動または停止するように指示し、特有のタイプのデータを送信し、露出または絞りの設定を調節し、照明設定を調節するなど戻るようにされる場合もある。この例において、カメラハードウェアインターフェース４０２は同様に不良なスレッド、データクリーニング及びデータフォーマッティングに関する問題を回避するなど、他のタスクを担うこともできる。このようなコンポーネントはまた、別個のスレッドを生成することでフレームがなおもそのサービスによって受信されていることをモニターし、フレームが受信されていない場合はリスナーにエラーを送りつけることができる。センサハードウェアインターフェース４０４は、センサスタックの周りにラッパーインターフェースを設けることができ、スレッドを生成して、リスナーに送りつけるべきデータをセンサにポーリングする。このコンポーネントは、データに関するエラーまたはタイムアウトポーリングを検出することができ、このエラーを適切なリスナーに送りつけることができる。一部の実施形態において、内部ワッシャスレッドが、センサ及び／またはカメラのための接続を閉鎖するなどのタスクを実行することができる。
【００２０】
供給路３２４からのデータは、イベントパブリッシャー３２０に受信させることができ、これが頭部追跡サービス３１６に記録されたクライアントに対してイベントを公開し、このサービスのプッシュ性能を促進させるというタスクが課されている。イベントパブリッシャー３２０は、イベントを公開する際に使用するリスナーマップ４１６など様々なクライアントのリスト、及びそのようなクライアントイベントを送信するためのインターフェースを維持することができる。供給路から受信したデータは、頭部の位置データを処理する及び／または平滑化するのに使用され得るような１つまたは複数のフィルタオブジェクト４２０を利用してフィルタリングすることができ、各々のフィルタは、様々な機能性と変化に富んだ出力を提供する。フィルタは、例えばセンサフュージョンフィルタ、パススルーフィルタ、有限インパルス応答（ＦＩＲ）フィルタ、及び固定パスまたは固定位置データを出力することができる固定フィルタを含むことができる。一例のフィルタは、エンジンから入力データ（例えば像空間における頭部及び頭部の位置に関する生の位置データ）を得ることができ、このデータを平滑化する、またはそうでなければ処理するように試みることで、クライアントに伝えるべき頭部の位置の座標を出力することができる。センサフュージョンフィルタなどのフィルタは、任意のソースからの個別のデータよりも正確であり、かつ疑わしいデータまたは有意な量のノイズがより少ないデータを提供するために、異なるソースから、ここではハードウェアインターフェース及びエンジンからのデータを結合することができる。ＦＩＲフィルタは、有限期間の任意の有限の長さの入力に対する応答を有し、有限時にゼロに定着し、これにより本質的に安定したやり方で、フィードバックする必要のないデータの平滑化を実現することができる。種々の実施形態の範囲内でデータの平滑化、ノイズの除去及び他のそのような目的のために様々なその他のフィルタを同様に使用することができる。この例では、イベントパブリッシャーは、少なくとも２種類のリスナーを有し、センサハードウェア４０４及びカメラハードウェア４０２から直接データを取得する生リスナーと、一定の率でデータを取得する頭部追跡リスナーとが含まれ、この率は一部の実施形態ではカメラのフレームレートに相当する場合もあるが、カメラフレーム及び／または処理時間とは無関係である。処理後のデータは、パブリッシャーループコンポーネント４１８を利用して少なくとも一部の実施形態ではイベントとしてリスナークライアント３０８及び／またはリスナーに公開することができる。公開されるイベントには、例えば頭部追跡イベント（検出された頭部の位置、傾斜角を含む場合もある）、生データイベントまたはカメラフレームイベントが含まれてよい。少なくとも一部の実施形態では、パブリッシャーループは、適切なフィルタ４２０をサンプリングし、最近更新された頭部の位置の値を取得し、それらの値を任意のクライアントに、またはイベントを聞くように登録されたコンポーネントに公開することができる。
【００２１】
述べたように、追跡出力マルチプレクサ３２２はイベントパブリッシャー３２０と同様の機能を果たすことができるが、イベントのプッシングまたは公開の代わりにポーリング及び／またはサンプリングを促進する。マルチプレクサコンポーネントは、頭部トラッカーハンドルのリスト及びその様々な構成を維持することができ、少なくとも一部の実施形態では、イベントパブリッシャーと同じフィルタの選択を利用することができる。頭部追跡イベントを必要とするサンプルを出力マルチプレクサ上に形成することができる。フィルタは、受信する際、供給路３２４からの出力によって更新させることができ、これをサンプリングすることで頭部追跡イベントを元に戻すことができる。このようなイベントは、イベントパブリッシャーに関して考察したタイプと同様であり得る。イベントパブリッシャーでのように、所望されるようにデータを融合及び／またはフィルタリングするために、フィルタ４２４は、エンジン４１０から処理後の入力（例えば像空間における頭部の位置の座標）、ならびにハードウェアインターフェース４０２、４０４から生データを受信することができる。少なくとも一部の実施形態において、クライアントが特定のイベントに適合するようにフィルタを選択することを可能にすることができるフィルタ選択機構が提示される場合もある。フィルタは頭部追跡データ及び生センサデータを使用して、適切なクライアントに提供することができる最終的な頭部の位置の決定を特定することができる。出力マルチプレクサを介してサービス上でのサンプリングを可能にし、フィルタに対してサンプリング法を提供することによって、クライアントはサンプルコールが指示されるたびに最近の頭部の位置を得ることができる。
【００２２】
一例の追跡サービス３１６は、様々な他のコンポーネントも同様に上手く利用している。例えば先に考察したポリシーコンポーネント３０６は、パワーマネージャーサービスまたはウィンドウマネージャーサービスなどのネイティブサービスと対話することでデバイスの状態を得て、提供されたイベントデータを利用して特定されるなど、特定されたユーザの頭部のデバイスに対する状態に基づいて関連するコマンドを送信することができるポリシーサービスを含むことができる。例えばユーザが所定の時間にわたってデバイスを一瞬たりとも見なかったと特定された場合、ポリシーサービスは、特有のポリシーに従って、カメラまたはセンサの電源を切るあるいはスタンドバイ状態に入るようにする。所定の時間にわたって頭部が検出されなかった場合、このときデバイスのディスプレイスクリーンは、スタンドバイ状態に置かれる可能性がある。ポリシーコンポーネントは、少なくとも一部の実施形態では１つまたは複数のＪａｖａ ＡＰＩを利用して頭部追跡サービスと対話することができ、種々のハードウェアコンポーネントのための情報を維持するために１つまたは複数のオーバライドマップ４１２を上手く利用することができる。図示されるように、サービスはまた、標準的なアンドロイド（登録商標）バインダーレイヤなどのＩＰＣインターフェース３１４も上手く利用しており、これは、頭部追跡サービス３１６とクライアント３０８及び／またはサービスインターフェース３１２間のプロセス間通信を提供するシステムワイドサービスであり得る。１つまたは複数の診断モジュール４１４を利用して、頭部追跡サービスに関する問題を突き止めるように試みることもできる。
【００２３】
このサービスはまた、デバイスのハードウェアスタックのいずれかがデータを送信していない、または少なくとも有効データを送信していない場合を特定することを伴うタスクを課すことができる少なくとも１つのモニター４０６または「監視機関」コンポーネントを利用することができる。このような場合のモニターは、そのような選択肢の中でもデータを流れるようにする及び／または対応するコンポーネントをリスタートすることが課されている。一例において、データが特有のコンポーネントインターフェースから受信されてからどのくらいであるかを特定するのにタイムウインドウが使用される。データがウィンドウの時間を過ぎても受信されなかった場合、またはデータが受信されたが有効でないと判断された場合、モニターはエラーの種類を特定し、適切な改善行動を採るように試みることができる。「ハード」エラーは、少なくともモニターコンポーネントによってハードウェアコンポーネントが回復不能な程に故障した場合に生じるものと特定することができ、「ソフト」エラーは、データが提供されているが誤ったものである場合に生じるものと特定することができる。モニターコンポーネントは、接続を絶ち接続し直すことによってソフトエラーから回復させインターフェースをリセットするように試みることができる。リスタートまたは他のそのような行動の後、任意のまたは全ての登録されたリスナークライアントは、自動的に再接続が行われるため、クライアントは故障が生じたことを特定することができない。一部の実施形態において、クライアントは自動的に新たにインスタンス化されたサービスに登録される。他のコンポーネントからのデータはなおも受信され処理することができ、供給路はデータを流し続けることができる。ハードエラーの場合、モニターは、コンポーネント、追跡サービス及び／またはデバイスにリスタートを指示するように試みることができる。一例としてカメラの場合のソフトエラーは、フレームは出力されているが、露出設定など）に関して無効なデータを有することによるなどメタデータが不正確であると特定されることによって検出され得る。このようなモニターは、種々のリスタートに関して必要なシステムの状態及び情報に関するデータにアクセス権を有することができる。少なくとも一部の実施形態において、モニター４０６は、センサハードウェア４０４、カメラハードウェア４０２及びエンジン４１０と少なくとも通信しており、供給路３２４の内部で機能しているが、その一部ではない。図示されるように、ファサード３１８は、頭部追跡サービスを始動するまたは停止させることができる供給路スイッチを実行するなど供給路３２４を呼び出すことができ、少なくとも一部の実施形態ではハードウェアの状態も同様に制御することができる。少なくとも一部の実施形態における供給路スイッチは、ポリシーコンポーネント３０６によって少なくとも一部を制御することができる。モニターコンポーネント（同一のまたは異なるモニターコンポーネント）がクライアントの状況をモニターする場合もあり、クライアントがもはや登録されていないまたは利用できない場合にリスナーマップからクライアントに関する情報を除去することができる。クライアントが実際にデータまたはポーリングデータを聞いていない場合、資源を保護するために、モニターコンポーネントは、種々のセンサを停止させるまたは低電力状態に入るようにさせることができる。
【００２４】
図５（ａ）及び図５（ｂ）は、Ｊａｖａクライアントなどのクライアントが、種々の実施形態による追跡サービスを利用することを可能にするように構成することができるアーキテクチャ５００を示している。この例では、アーキテクチャは、ジェスチャーサービス５２０及び／または頭部追跡サービス５２２からデータを受信するように構成することができ、これらは共に種々の実施形態の範囲内で利用可能なプッシュ及び／またはプルデータを有する。考察されるように一部の実施形態では、データを代替として同一のサービスによって提供する場合もある。ジェスチャーサービス５２０は、先に考察した頭部追跡サービスと同様に機能することができるが、この例ではジェスチャーサービスは、センサデータ、場合によって一部の実施形態ではカメラデータを分析し、コンピューティングデバイスを傾けるまたはコンピューティングデバイスをタップするなどの入力ジェスチャーを特定する、コンピューティングデバイス上で作動する単一のプロセスである。本明細書で使用されるジェスチャーは、典型的にはある意図を示すユーザからの動き、そのような選択肢の中でも、首を傾ける、首を回す、のぞき見るまたは２回叩くなどの任意の入力を含むようにみなすことができる。一部の実施形態では、ジェスチャーは、経時的に発生する複数のイベントを分析及び／または比較することによって特定される場合もある。このような例では、ジェスチャーサービス５２０は、例えばデバイスの動きに関するデータを提供する場合もあるが、特有のジェスチャーを特定するには経時的な動きを分析する必要があり得、タップまたはチルトは、その動きがチルトまたはタップに相当すると特定する前に、特定された複数の動きに関するデータを有する必要があり得、このジェスチャーを立証するには特定の閾値または範囲を満たす必要があり得るなどである。同様に、この動きを分析して、動きがチルトとピークの一部であるかどうかを特定する場合もある。
【００２５】
この例において、別個のピーク検出器５１８と、ピークジェスチャーを管理するピークマネージャー５１６とが存在しており、これは一部の実施形態では特有の小さい角度のチルトジェスチャーまたは他のそういった動きを指すが、他の実施形態では、ピーク機能は、ジェスチャーサービス及びジェスチャー関連コンポーネントの中に含まれる場合もある。ピークジェスチャー及びピークジェスチャー特定のさらなる例が本明細書で後に考察される。ジェスチャーサービス５２０はまた、少なくともある程度、モニターされる、追跡される、または検出されるべきジェスチャーのタイプによって、必要に応じてセンサまたは他のハードウェアコンポーネントに登録させる場合もある。ジェスチャーマネージャー５１４はリスナーマネージャーであり、これに１セットのリスナー５１２のいずれか、ここではジェスチャーとチルトリスナーを登録することができる。述べたように、一部の実施形態ではピークリスナーをジェスチャーマネージャーに同様に登録させることもできる。ジェスチャーサービス５２０とリスナーのセット５１２の間に位置するジェスチャーマネージャー５１４は、内部のリスナーマネージャーであり、クライアント５０２と追跡マネージャー５０８の間に位置するパブリックジェスチャーマネージャー５０４を使用することができ、追跡マネージャー５０８は、リスナーの種々のリスナー５１２からデータを伝えるためにＪＮＩマネージャーの頂部に位置する。少なくとも一部の実施形態では、内部ジェスチャーマネージャーは、外部ＡＰＩとジェスチャーサービス５２０をつなぐ別のバインディングレイヤとして機能する場合もある。いずれの例のジェスチャーマネージャーも、リスナーとして登録することで、直接またはＪＮＩ追跡マネージャーを介してジェスチャーサービス５２０からイベントを受信することができる。このアーキテクチャにおいて、追跡マネージャー５０８は、中でもとりわけピーク、ジェスチャー及び頭部追跡イベントに関するデータを扱うことができる。内部ジェスチャーマネージャー５１４は、どのリスナー５１２がジェスチャーサービスから受信する任意のイベントに関するデータを受信すべきかを把握することができる。
【００２６】
頭部追跡サービス５２２から受信した、または引き寄せたイベントに関しても同様のフローが生じる。追跡マネージャー５０８は再び、サービス５２２とクライアントの間の中間レイヤとして機能する。頭部追跡データは、頭部追跡データポーラ、頭部追跡データリスナー及び／または生データリスナーなどのリスナーのセット５１２のうちの適切なリスナーへと伝えることができる。先に例示され考察されたように、少なくとも一部の実施形態ではデータはネイティブバインディングレイヤ５２４を経由して通過することもある。ポーラは、先に考察したバインダーコールを利用してサービスをサンプリングするように試みることができ、その一方でリスナーは公開されたイベントを受信することができる。データは、リスナーからＪＮＩ追跡マネージャー５１０及び追跡マネージャー５０８を経由して伝えられ、パブリック頭部追跡マネージャー５０６へと伝わるようにすることができ、パブリック頭部追跡マネージャー５０６はこの後クライアントへとデータを提供することができる。マネージャーは、異なるモードの処理を可能にすることができるため、スタンドバイモードにおいてもデータはなおも受信されるが、演算などのために使用されるわけではない。一部の電力及び処理作業を省略するために、ハードウェアのいずれかの電源を切ってリスタートする必要なしに頭部追跡サービスにおいても同様の機能を実施することができる。さらに、そのようなアプローチは、ほとんど遅れることなく計算を再開することを可能にする。マネージャーはまた、クライアントが異なる忠実度においてデータをリクエストすることを可能にすることができる。例えばクライアントは、より低いフレームレートでカメラを作動させることができ、より低い精度が許容可能である場合、精度が劣る追跡を提供することになるが電力を維持することもできる。また高い忠実度のデータを必要とするクライアントは、データを処理するために追加のフィルタまたはエンジンを利用することによって、あるいはカメラのフレームレートを超える特定の率でフィルタをサンプリングすることなどにより、センサからの生データをさらに利用することによって、頭部追跡及び／またはジェスチャーサービスにおいて実施すべき追加の処理を生じさせることができる。
【００２７】
図５（ｂ）の一例のアーキテクチャ５５０において、ジェスチャーコンポーネントは、タップ、チルト、ピーク及び他のそのようなジェスチャーに関するコンポーネントを含んでおり、これらはジェスチャーコンポーネント内にまとめられている。この例において、ジェスチャーリスナーアグリゲータ５５２コンポーネントが追加されて、全ての適切なジェスチャーイベントデータが適切なやり方でジェスチャーマネージャー５０４に伝えられることを確実にする。ジェスチャーデータは依然として、ジェスチャーマネージャー５１４とジェスチャーサービス５２０コンポーネントの間を流れることができるが、チルト、タップ、ピーク及び他のそのようなジェスチャーのリスナー５５６などのコンポーネントを聞く、またはそうでなければからそこからジェスチャーデータを受信することができる共通のジェスチャー検出器５５４によって提供される場合もある。そのようなアプローチは、各々のそれぞれのクライアントに対して作用している各々のジェスチャーに関する１つまたは複数のコンポーネントの代わりに、単一のジェスチャーコンポーネントまたはサービスがデバイス上でアクティブであることを可能にすることができる。
【００２８】
図６は、種々の実施形態によって利用することができるクライアントに追跡データを提供するための一例のプロセス６００を示す。特に明記しない限り、種々の実施形態の範囲内で、同様にまたは代替の順番で、あるいは並行して行われる追加の、さらに少ないまたは代替のステップが存在し得ることを理解されたい。この例では、モーションセンサ及び／またはセンサスタックからセンサデータが得られる６０２。考察されるように、これは中でもジャイロスコープ、慣性センサ及び加速度計などのセンサからのデータを含むことができる。センサデータは一般に、カメラデータと同期せずに、かつより高頻度で受信されるため、シンクロナイザなどのコンポーネントは、センサデータが受信される際、それをバッファに保留することができる６０４。少なくとも一部の実施形態では、シンクロナイザはまた、センサデータの各々の例に関するタイミング情報に印をつけることで、同期化及び／またはデータ処理を助けることもできる。画像フレームに関するデータがその後取得される際６０６、シンクロナイザまたは他のそのようなコンポーネントは、画像フレームデータとセンサデータを結合し、少なくとも１つのエンジンまたは他のそのようなコンポーネントにそのデータを伝えることができる。センサデータ及び画像フレームデータは処理されて、画像フレームにおける特徴部を突き止め、像空間における頭部の位置を特定することによって、あるいはジャイロスコープデータを分析してデバイスの回転の大きさ及び方向を特定することによって、位置及び／または動きデータを特定する６０８。位置／動き及び生センサデータはその後、本明細書で考察されるイベントパブリッシャー及び出力マルチプレクサなどによる処理のために提供することができる６１０。この例では、処理は、１つまたは複数のフィルタを使用したエンジンからの位置及び／または動きのフィルタリングをし、追跡サービスの出力として１セットのイベントデータ（例えば頭部の座標またはデバイスの回転のベクトル）を生成することを含むことができる６１２。イベントデータは、任意のリスナークライアント、または特有の追跡イベントを受信するように登録された他のそのようなコンポーネントに公開することができる６１４。プルクライアントなどの別のクライアントの場合、最近更新されたイベントデータに関してポーリングコールが受信される場合もある６１６。その後、リクエストに応答して現在のイベントデータを提供することができる６１８。述べたように、データは、少なくとも一部の実施形態ではノンネイティブクライアントによって処理することが可能になる前に、ＪＮＩまたは他のそのようなレイヤを経由して伝える必要がある場合もある。
【００２９】
述べたように、供給路におけるエンジンは、画像及び／またはセンサデータを使用して物体を検出するために多様なアルゴリズム及びアプローチを利用することができる。詳細には、種々の実施形態には、ユーザの頭部または顔の輪郭などのユーザの一部分を検出し追跡することが含まれる。詳細には多様なアプローチは、立体結合及び多様な追跡アルゴリズムを利用して主たるユーザが識別され追跡されることを可能にする。例えば、それぞれのカメラによって独立して取り込まれた各々の画像に対して顔の検出アルゴリズムを作動させることができる。顔を検出する際、顔検出アルゴリズムは、それぞれのカメラからの画像を独立して分析することで、全てのカメラにおいて顔を一致させることができる。顔が一致した場合、顔の対が形成され、物体の追跡を初期設定するためのメモリ内の第１のデータ地点として使用される。しかしながら顔がカメラのうちの１つのみにおいて検出された場合、合致アルゴリズムは、欠けている顔を回復させる試みにおいて、他方のフレームからの顔のテンプレートを利用して顔が欠けているフレームを分析することができる。欠けている顔が回復され、顔が一致されると、物体の追跡を開始することができる。さらに２つ以上の顔が画像内で検出された場合、以下でより詳細に説明するように、深度情報、中心までの距離、顔のサイズなどを利用して追跡する主たる顔またはユーザを特定することができる。したがってひとたび顔の対が確認されると物体の追跡が始まり、この顔の対がメモリに記憶される。
【００３０】
顔の対が確認されると、カメラの各々からのその後のフレームを分析して、画像フレームからフレームへと主たるユーザの顔を検出することができる（例えば検出ごとの追跡）。一部の追跡アルゴリズムは、先のフレームにおいて特定の顔が検出された場合、それを追跡するように設計されている。しかしながらそのような制限を設けることは、照明、視野角など、物体が様々な理由のために特定のフレームにおいて認識されない一部の例においてその方法を実施できないようにする可能性がある。したがって検出ごとの追跡法の利点をより広い範囲の状況まで拡張するために、顔の対が現在の画像フレームのうちの少なくとも１つにおいて検出されない場合、メディアンフロートラッカー（Ｍｅｄｉａｎ Ｆｌｏｗ Ｔｒａｃｋｅｒ）（ＭＦＴ）などの第２の追跡アルゴリズムを使用することができる。この後、その後のフレームにおいて、顔の対を検出しようと試みるプロセスを再開することができる。したがって、顔の対が先のフレームにおいて検出された場合、検出ごとの追跡が実施される。顔の対が先のフレームにおいて検出されない場合、第２の追跡アルゴリズムが使用される。
【００３１】
さらにそれぞれの境界ボックスの位置が決定されると、例えばユーザの目及び口の位置を特定するために各々の取り込まれたフレームに対して、この境界ボックスの範囲内のユーザの顔の特徴部を抽出することができる。ぶれを抑えより順調な追跡出力を提供するために、その後の画像フレームにおけるこのような特徴部の位置の変化を利用して、特定のフレームに対してどの特徴部の追跡法が使用されるかを決定することができる。例えば、現在の画像フレームと先の画像フレームの対に関して、ユーザの目のオプティカルフローの変化を計算することができる。一例において、このような変化が最初の大きさまたは閾値を下回る場合、このときユーザの位置は、先のフレームにおけるその位置に対してわずかに変化している。このような変化はわずかであるため、ユーザの目の現在の位置は、あたかもユーザが移動していないかのように先のフレームにおけるその位置として妥当に推定することができる。別の例では、このような変化が第１の閾値と第２の閾値の間にある場合、ぶれを抑えるために、単一の地点追跡アルゴリズムを使用してこのような２つのフレームにおけるユーザの目を追跡することができる。しかしながらオプティカルフローのこのような変化が第２の閾値を超えた場合、ユーザの目の現在の位置を使用することができる。しかしながらこのような例では、目の位置の変化がそのように大きい（すなわち第２の閾値を超える）ため、ユーザは迅速にまたは不意に移動しているため、追跡出力はかなりぶれて現れることになり、よってこのような例における不意の変化は単に許容することができるだけでなく、それは恐らく予測されるであろう。
【００３２】
多様な実施形態は、相対的な位置情報の中でもとりわけ、ユーザの関係性及び／または配向、ユーザの見ている角度の方向あるいはコンピューティングデバイスに対するユーザの頭部の角度（例えばユーザに相当する地点（例えばユーザの目の間の地点）からコンピューティングデバイスに相当する地点まで（例えばコンピューティングデバイスの前面の中心地点）まで特定の光線によって形成されるその入射角または誘導作用））などコンピューティングデバイスの角度に対するユーザの相対的な位置に少なくとも一部基づいて、ユーザがコンピューティングデバイスを制御することを可能にする。例えば、コンピューティングデバイスの表示要素を介してコンテンツの第１の視野がユーザに提示される場合がある。追加のコンテンツ、文脈情報、または表示要素の空間制限などにより表示要素上に直接は提示されない他の情報が存在する場合もある。しかしながらこのコンピューティングデバイスによって、関連するコンテンツを見るためにデバイスに対するユーザの頭部の角度を変えるために、他の可能な動作の中でも、静止位置から左方向に（例えば東向きに）、右側に（例えば西向きに）、上向きに（例えば北向きに）、下方に（例えば南向きに）、中間または序数（すなわち、北東（ＮＥ）、南東（ＳＥ）、南西（ＳＷ）、北西（ＮＷ））、及び／または二次的な方位中間方向に（例えばＮＮＥ、ＥＮＥ、ＥＳＥなど）デバイスを傾けることによって、ユーザが「ピーク」「スクロール」または別の動作を行うことを可能にすることができる。あるいはまたは追加として、ユーザは、上記に挙げた方向の１つまたは複数の方向に自分の頭部を傾けることもでき、これは、デバイスが所望される行動を果たすようにするためのコンピューティングデバイスに関する入力として認識することができる。
【００３３】
多様な実施形態において、ユーザの頭部の実際の動作及び／またはデバイスの動きに起因するユーザの頭部の見かけ上の動作が、１つまたは複数のカメラ及び／または１つまたは複数のモーション／配向要素（例えば加速度計、ジャイロスコープ、デジタルコンパスなど）によって検出されることで、デバイスの様々な機能を制御することができる。このようなアプローチは、デバイスのタッチセンシティブ要素（例えば抵抗方式、容量方式、表面音響波または赤外線タッチスクリーンなど）の使用を減らし、指紋、埃、汚れ及びそうでなければタッチセンシティブ要素上に残される可能性のある他の残留物を減少させることができる。これにより、グレアの大きさまたは鮮明度及び／または視界に関する他の問題を緩和させるまたはなくすことができる。さらに頭部のジェスチャーあるいはユーザの頭部の実際のまたは見かけ上の動作に基づくコンピューティングデバイスの制御は、ユーザがタッチスクリーンをスワイプさせたり仮想ボタンを押したりすることを必要とするなど、従来のアプローチよりもより速やかにユーザの意思に反応することができる。さらに、コンピューティングデバイスに対するユーザの頭部の角度に基づいた制御は、片手操作またはハンドフリー操作を可能にすることができ、これはユーザが別のコンピューティングデバイス（例えばデスクトップまたはラップトップコンピュータ）を操作しているときに有利であり得る。
【００３４】
種々の実施形態によるアプローチは、たとえユーザがコンピューティングデバイスに対して「軸外に」位置しているまたは直交していないならびに／あるいは中心に位置していない場合でも、コンピューティングデバイスに対するユーザの頭部の角度またはユーザの頭部の実際の及び／または見かけ上の動作をコンピューティングデバイスに対する入力として認識することを可能にする。種々の実施形態において、デバイスを制御するためにユーザの頭部がコンピューティングデバイスに対してどのくらい移動したかの特定を調整するために融通性のある「基準点」または「基準角度」を使用することができる。本明細書で使用される際、「基準点」または「基準角度」は、ユーザの自然な静止した位置におけるユーザの頭部の角度の推定値である。基準点または基準角度は、相対的な位置情報と基準点の先の値との経時的な融通性のある関数に基づいて決定される。一実施形態において、融通性のある関数には、融通性のある因数による、検出された頭部の角度と基準点の先の値との差またはデルタの重み付けが含まれるため、基準点及び頭部の角度は特定された期間内に集中する。例えば先の基準点と検出されたユーザの頭部の角度との差が大きい程、現在特定される基準点はより迅速に検出された角度に近づくことになる。融通性のある基準点と併せて、この基準点に基づいて「中立領域」を定義することができる。本明細書で使用される際、「中立領域」は、基準点の前後の固定された範囲あるいは基準点が移動することが許される基準点からの特定された領域である。すなわち基準点は、中立領域の制限の範囲内に拘束され、基準点は、検出されたユーザの頭部の角度が中立範囲内にあるとき継続して更新される。基準点または基準角度のこのような動的な調整によって、ユーザが、軸外でコンピューティングデバイスを操作することが可能になり、デバイスが、デバイスを制御するためのデバイスに対するユーザの頭部の角度の変化を検出し続けることが可能になる。このようなアプローチは、ユーザが自分の自然な静止位置を変える及び／またはデバイスの静止位置を変える場合と、ユーザが、デバイスに対する自分の頭部の角度に基づいてデバイスを制御しようと思う場合の違いを説明することができる。
【００３５】
種々の実施形態において、アプローチは、頭部の位置または多様な顔の特徴部の位置を見ることで、少なくとも一人のユーザが恐らく表示要素をじっくりと見ているか、またはそこから離れているかを特定することができる。別の実施形態において、アルゴリズムが、表示要素及び／または撮像要素に対する注視方向及びユーザの目の視野に基づいて、ユーザが表示要素に対して見ている場所、特定のアイコンを、あるいはさらには特定のピクセルまたは他の表示要素に集中していることなどをさらに特定する場合もある。ユーザの目の視野／相対的な位置の変化を追跡することによって、アルゴリズムは、ユーザがこのデバイスを見ているか、そうであればユーザがデバイス上のどこを見ているかを、いつでも特定することができる。
【００３６】
特定された視野、ユーザの見ている位置、注視方向の変化などに少なくとも一部基づいて、デバイスの機能性を変えることができる。機能性が修正される方法は、１つまたは複数のポリシーに少なくとも一部基づいて決定することができる。一部の例のポリシーに関して表示要素は、ユーザが表示要素及び／またはデバイスの方を見ているか、そこから離れているかに少なくとも一部基づいて、あるいはユーザの相対的な頭部の位置に少なくとも一部基づいて異なる輝度値を有する、あるいはさらには電源遮断を有することができる。すなわちそのような実施形態では、撮像要素は、デバイスの局面を制御するための入力を提供するのに使用される。
【００３７】
他の実施形態において１つまたは複数のポリシーに基づいて、特定されたユーザの注視方向または頭部の位置に少なくとも一部基づいてデバイスの種々の機能性または入力をイネーブルにする／ディスエーブルにする、電源を切る、あるいはそうでなければ修正することができる。例えば、ユーザがデバイスの表示要素を見ておらず、従来のキイボードの代わりにタッチセンシティブディスプレイ要素キイボードを利用して特定のメッセージをタイプしようとしていることが特定された場合、このキイボード入力を修正して、ユーザにタイピング能力を向上させることができる。例えばデバイスは、ユーザによって選択される際、各々のキイを聞き取れるように提示することができる。別の例では、デバイスは、ユーザが選択する前にキイの上方／すぐ上に自分の指を位置決めする際、各々のキイを聞き取れるように提示する場合もある。キイの選択の可聴式の提示に加えて、デバイスは、電源を保持するために表示要素の電源を遮断する場合もある。
【００３８】
本明細書に記載される種々の実施形態によるポリシーを利用して、いずれの数のデバイスの機構及び／または入力も制御することができる。例えばユーザの注視方向がデバイスに向いていないこと、または撮像要素がユーザの顔を含む画像を取り込んでいなかったことが特定された場合、デバイスは、ワンタッチダイアリングなどの入力をディスエーブルにして、そのような入力の選択が不注意に選択されることを阻止することができる。少なくとも一部の実施形態において、ユーザは、どの機能がイネーブル／ディスエーブルにされるかを構成し、ならびにどの機能が、特定の行動を行う際にユーザがディスプレイ要素を少なくとも見ることを要するかを規定することができる。
【００３９】
図７は、図１Ａに関して記載されたデバイス１００などの一例のコンピューティングデバイス７００の一セットの一般的なコンポーネントの論理的な配置を示している。この例ではデバイスは、メモリデバイスまたは要素７０４に記憶させることができる指示を実行するためのプロセッサ７０２を含む。当業者には明らかであるように、デバイスは、多くのタイプのメモリ、データストレージまたは非一時的なコンピュータ可読ストレージ媒体を含むことができ、プロセッサ７０２によって実行するためのプログラム指示のための第１のデータストレージ、画像またはデータのための別個のストレージ、他のデバイスと情報を共有するための取り外し可能メモリなどを含むことができる。デバイスは典型的には、何らかのタイプのディスプレイ要素７０６、タッチスクリーンまたは液晶ディスプレイ（ＬＣＤ）などを含むことになるが、携帯メデイアプレイヤなどのデバイスは、オーディオスピーカーなどの他の手段を介して情報を搬送する場合もある。考察されるように、多くの実施形態におけるデバイスは、デバイスの近傍の１つまたは複数の物体の画像またはビデオを取り込むことができる少なくとも１つのカメラ１００８を含む。カメラ要素を利用してコンピューティングデバイスによって画像またはビデオを取り込む方法は当技術分野でよく知られているため、本明細書では詳細に考察しないことにする。画像の取り込みは、単一の画像、複数の画像、周期的な撮像、継続的な画像取り込み、画像ストリーミングなどを利用して行うことができることを理解されたい。さらに、デバイスは、ユーザ、アプリケーションまたは他のデバイスからコマンドを受信する際などに画像の取り込みを開始及び／または停止する能力を含むことができる。一例のデバイスは、少なくとも１つの一次方向から音響情報を取り込むように作動可能な少なくとも１つのモノまたはステレオマイクロフォンあるいはマイクロフォンアレイを含むことができる。マイクロフォンは、そのようなデバイスに既知であるような単一または無指向性マイクロフォンであってよい。
【００４０】
一部の実施形態において、図７のコンピューティングデバイス７００は、Ｗｉ-Ｆｉ、ブルートゥース（登録商標）、ＲＦ、有線または無線通信システムなどの１つまたは複数の通信コンポーネント７１０を含むことができる。多くの実施形態におけるデバイスは、インターネットなどのネットワークと通信することができ、他のそのようなデバイスと通信することができる場合もある。一部の実施形態において、デバイスは、ユーザからの従来式の入力を受信することができる少なくとも１つの追加の入力要素７１２を含む。この従来式の入力には、例えばプッシュボタン、タッチパッド、タッチスクリーン、ホイール、ジョイスティック、キイボード、マウス、キイパッドあるいは任意の他のそのようなデバイスまたは要素が含まれ、これによりユーザがデバイスにコマンドを入力することができる。しかしながら一部の実施形態において、そのようなデバイスがいかなるボタンも全く含まない場合もあり、視覚的及び可聴コマンドの組み合わせを介してのみ制御されるため、ユーザはデバイスと接触する必要がなくデバイスを制御することができる。
【００４１】
デバイスはまた、少なくとも１つの配向またはモーションセンサを含むことができる。考察されるように、そのようなセンサは、配向及び／または配向の変化を検出するように作動可能な加速度計またはジャイロスコープ、あるいはデバイスが向いていると判定される特定の方向を指すことができる電子またはデジタルコンパスを含むことができる。この機構はまた（または代替として）、コンピューティングデバイスの位置に関する相対的な座標ならびにデバイスの比較的大きな移動に関する情報を特定するために全地球測位システム（ＧＰＳ）または同様の要素を含むまたは備えることができる。デバイスは同様に、三角測量または別のそのようなアプローチを介する位置の特定を可能にし得るような他の要素も含むことができる。このような機構は、プロセッサと通信することができ、これによりデバイスは本明細書に記載され提示されるいくつかの行動のいずれかを実施することができる。
【００４２】
上記で考察したように、種々の実施形態は、広範囲の動作環境において実施することができ、これは一部の例では、いくつかのアプリケーションのいずれかを作動させるのに使用することができる１つまたは複数のユーザコンピュータ、コンピューティングデバイスまたは処理デバイスを含むことができる。ユーザまたはクライアントデバイスは、標準的なオペレーティング・システムを稼働させるデスクトップまたはラップトップコンピュータ、ならびにモバイルソフトウェアを稼働させ、いくつかのネットワーク及びメッセージングプロトコルをサポートすることが可能な携帯、無線及びハンドヘルドデバイスなどのいくつかの汎用パーソナルコンピュータのいずれかを含むことができる。そのようなシステムはまた、多様な商業的に入手可能なオペレーティング・システム、ならびに開発及びデータベース管理などの目的の他の既知のアプリケーションのいずれかを稼働させるいくつかのワークステーションを含むこともできる。これらのデバイスはまた、ダミーターミナル、シンクライアント、ゲーミングシステム及びネットワークを介する通信することが可能な他のデバイスなどの他の電子デバイスを含むこともできる。
【００４３】
種々の態様はまた、サービス指向形アーキテクチャの一部であり得るなど、少なくとも１つのサービスまたはウェブサービスの一部として実施することもできる。ウェブサービスなどのサービスは、拡張マークアップ言語（ＸＭＬ）フォーマットでのメッセージを利用し、ＳＯＡＰ（「シンプルオブジェクトアクセスプロトコル」に由来する）などの適切なプロトコルを利用してやりとりされるなどして任意の適切なタイプのメッセージングを利用して通信することができる。そのようなサービスによって提供または実行されるプロセスは、ウェブサービス記述言語（ＷＳＤＬ）などの任意の適切な言語で書き表すことができる。ＷＳＤＬなどの言語を利用することで、種々のＳＯＡＰフレームワークにおけるクライアント側のコードの自動生成などの機能性が可能になる。
【００４４】
大抵の実施形態は、ＴＣＰ/ＩＰ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ及びＣＩＦＳなどの多様な商業的に入手可能なプロトコルのいずれかを利用して通信をサポートするために当業者によく知られている少なくとも１つのネットワークを利用する。ネットワークは、例えばローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク及びそれらのいずれかの組み合わせであってよい。
【００４５】
ウェブサービスを利用する実施形態において、ウェブサービスは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データサーバ、Ｊａｖａサーバ及びビジネスアプリケーションサーバを含む多様なサーバまたは中間層アプリケーションのいずれかを稼働させることができる。サーバはまた、Ｊａｖａ（登録商標）、Ｃ、Ｃ#またはＣ++などの任意のプログラミング言語で、あるいはＰｅｒｌ、ＰｙｔｈｏｎまたはＴＣＬなどの任意のスクリプト言語でならびにその組み合わせで書かれた１つまたは複数のスクリプトまたはプログラムとして実施され得る１つまたは複数のウェブアプリケーションを実行することによるなど、ユーザデバイスからのリクエストに応答してプログラムまたはスクリプトを実行することが可能な場合もある。サーバはまた、限定ではなくＯｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）及びＩＢＭ（登録商標）から商業的に入手可能であるものなどを含むデータベースサーバを含む場合もある。
【００４６】
このような環境は、多様なデータ記憶装置、ならびに上記で考察したような他のメモリ及びストレージ媒体を含むことができる。これらは、例えば１つまたは複数のコンピュータにローカルな（及び／またはその中にある）ストレージ媒体、あるいはネットワーク全体のコンピュータのいずれかまたは全てからリモートであるストレージ媒体など多様な場所に存在することができる。実施形態の特定のセットにおいて、この情報は、当業者によく知られたストレージエリアネットワーク（「ＳＡＮ」）内に存在する場合がある。同様にコンピュータ、サーバまたは他のネットワークデバイスに帰する機能を果たすのに必須のいかなるファイルも必要に応じて、ローカルに及び／またはリモートに記録することができる。システムがコンピュータ化されたデバイスを含む場合、各々のそのようなデバイスは、バスを介して電気的に結合され得るハードウェア要素を含むことができ、それらの要素には、例えば少なくとも１つの中央処理装置（ＣＰＵ）、少なくとも１つの入力デバイス（例えばマウス、キイボード、コントローラ、タッチスクリーンまたはキイパッド）、及び少なくとも１つの出力デバイス（例えばディスプレイデバイス、プリンタまたはスピーカー）が含まれる。そのようなシステムはまた、１つまたは複数のストレージデバイスを含む場合があり、ディスクドライブ、オプティカルストレージデバイス及びランダムアクセスメモリ（「ＲＡＭ」）または読み出し専用メモリー（「ＲＯＭ」）などのソリッドステートストレージデバイス、ならびに取り外し可能なメディアデバイス、メモリカード、フラッシュカードなどが含まれて良い。
【００４７】
そのようなデバイスはまた、コンピュータ可読ストレージ媒体リーダ、通信デバイス（例えばモデム、ネットワークカード（無線または有線）、赤外線通信デバイスなど）、上記に記載したワーキングメモリを含む場合もある。コンピュータ可読ストレージ媒体リーダは、リモートの、ローカルの、固定された及び／または取り外し可能なストレージデバイスを表すコンピュータ可読ストレージ媒体、ならびにコンピュータ可読情報を一時的に及び／またはより永続的に収容する、記憶する、伝達する及び検索するためのストレージ媒体と接続させる、またはこれを受信するように構成することができる。システム及び種々のデバイスはまた典型的には、クライアントアプリケーションまたはウェブブラウザなどのオペレーティング・システム及びアプリケーションプログラムを含む、いくつかのソフトウェアアプリケーション、モジュール、サービス、または少なくとも１つのワーキングメモリデバイスの中に配置された他の要素を含む。代替の実施形態は、上記に記載されるものからの多数の変形形態を有する可能性があることを理解されたい。例えば、カスタマイズされたハードウェアが使用される場合、及び／または特定の要素がハードウェア、ソフトウェア（アプレットなどのポータブルソフトウェアを含む）において実装される場合、あるいはその両方があり得る。さらにネットワーク入出力デバイスなどの他のコンピューティングデバイスへの接続が利用される場合もある。
【００４８】
コードまたはコードの一部分を収容するストレージ媒体及び非一時的コンピュータ可読媒体は、当技術分野で既知のまたは使用される任意の適切な媒体を含むことができ、これに限定するものではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、フラッシュメモリまたは他のメモリ技法、ＣＤーＲＯＭ、デジタル用途ディスク（ＤＶＤ）または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは所望される情報を記憶するのに使用することができ、システムデバイスによってアクセスすることができる他の媒体を含む、コンピュータ可読指示、データ構造、プログラムモジュールまたは他のデータなどの情報の記憶のために任意の方法または技術で実装された揮発性または不揮発性、取り外し可能及び非取り外し可能媒体などを含むことができる。本明細書において提供される開示及び教示に基づいて、当業者は、種々の実施形態を実施するための他の適切なやり方及び／または方法を理解するであろう。
【００４９】
上記は、以下の条項を鑑みて理解されて良い。  
１．少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによって実行される際、
各々のハードウェアインターフェースがカメラまたはモーションセンサの少なくとも一方からデータを受け取るように構成された複数のハードウェアインターフェースと、
前記複数のハードウェアインターフェースのうちのカメラインターフェースから画像が受信されるまで、前記複数のハードウェアインターフェースのうちの少なくとも１つのハードウェアインターフェースからのセンサデータを記憶するシンクロナイザと、
前記画像及び前記センサデータを処理して、頭部の位置またはコンピューティングデバイスの動きのうちの少なくとも一方に相当する入力データを生成するエンジンと、
前記入力データをフィルタリングすることで第１のフィルタリング後の入力データを生成し、前記第１のフィルタリング後の入力データを第１のイベントデータとして、イベントパブリッシャーによって公開されたイベントデータを受信するように登録された、前記コンピューティングデバイス上で実行中のリスナークライアントに公開するように構成されたイベントパブリッシャーと、
前記入力データをフィルタリングすることで、第２のフィルタリング後の入力データを生成し、前記コンピューティングデバイス上で実行中のプルクライアントからのポーリングリクエストに応答して、前記第２のフィルタリング後の入力データを第２のイベントデータとして提供するイベントプロバイダとを提供する指示を含むメモリとを備えるコンピューティングデバイスであって、
前記リスナークライアント及び前記プルクライアントがイネーブルにされて、前記第１のイベントデータまたは前記第２のイベントデータのうちの少なくとも一方に少なくとも一部基づいて、頭部の位置の変化またはジェスチャーのうちの少なくとも一方を特定する前記コンピューティングデバイス。  
２．実行される際の前記指示がさらに、前記コンピューティングデバイスに
少なくとも１つのポリシーに従って前記コンピューティングデバイスの動作を調節するように構成されたポリシーマネージャーコンポーネントを設けるようにさせ、前記複数のハードウェアインターフェース、前記シンクロナイザ及び前記エンジンがデータ供給路の一部であり、
前記ポリシーマネージャーが、前記少なくとも１つのポリシーに従って前記供給路を選択式に作動させるように構成される、条項１に記載のコンピューティングデバイス。  
３．実行される際の前記指示がさらに、前記コンピューティングデバイスに、
前記プルクライアントから前記ポーリングリクエストを受信し、ポーリングプロバイダに第２のイベントデータを提供させるように構成された少なくとも１つのインターフェースレイヤを設けるようにさせ、前記少なくとも１つのインターフェースレイヤが前記ポーリングリクエストに応答して前記プルクライアントに第２のイベントデータを送信するようにさらに構成される、条項１に記載のコンピューティングデバイス。  
４．前記複数のハードウェアインターフェースのうちの少なくとも１つのハードウェアインターフェースからのデータと、前記エンジンからの入力データとを受信するように構成された前記イベントパブリッシャー内の少なくとも１つの第１のフィルタと、
前記複数のハードウェアインターフェースのうちの少なくとも１つのハードウェアインターフェースからのデータと、前記エンジンからの入力データとを受信するように構成された前記イベントプロバイダ内の少なくとも１つの第２のフィルタとをさらに備え、
前記少なくとも１つの第１のフィルタと前記少なくとも１つの第２のフィルタが、少なくとも１つのハードウェアインターフェースから受信した前記データに少なくとも一部基づいて前記エンジンからの入力データを平滑化するように構成される、条項１に記載のコンピューティングデバイス。  
５．第１のハードウェアインターフェースを介してセンサデータを受信し、前記センサデータが前記コンピューティングデバイスの少なくとも１つのモーションセンサを利用して取得されることと、
第２のハードウェアインターフェースを介して画像データを受信し、前記画像データが前記コンピューティングデバイスのカメラを利用して取得されることと、
前記コンピューティングデバイスの少なくとも１つのプロセッサを利用して、前記画像データと前記センサデータとを処理することで入力データを生成することと、
前記入力データを前記パブリッシャーコンポーネント及び前記ポーリングコンポーネントに転送することと、
前記パブリッシャーコンポーネントを利用して、第１のイベントデータを受信するように登録された少なくとも１つのリスナークライアントに対して前記入力データを前記第１のイベントデータとして利用可能にすることと、
プルクライアントからのポーリングリクエストに応答して、かつ前記ポーリングコンポーネントを利用して、前記入力データに少なくとも一部基づいた第２のイベントデータを提供することとを含む、コンピュータ実装方法。  
６．前記センサデータをシンクロナイザコンポーネントに記憶することと、
前記センサデータの受信の時間を示す時間情報を記憶することと、
前記画像データを受信することと、
前記時間情報を伴う前記センサデータと、前記画像データをエンジンに転送することで前記入力データを生成することとをさらに含む、条項５に記載のコンピュータ実装方法。  
７．少なくとも１つの第１のフィルタを利用して、前記入力データと前記センサデータとを処理することで使用すべき入力データを平滑化して前記第１のイベントデータを生成することと、
少なくとも１つの第２のフィルタを利用して、前記入力データと前記カメラデータとを処理することで使用すべき入力データを平滑化して前記第１のイベントデータを生成することとをさらに含む、条項５に記載のコンピュータ実装方法。  
８．前記第１の入力データまたは前記第２の入力データのうちの少なくとも一方が、動きに適応性のある融合フィルタ、パススルーフィルタ、有限インパルス応答（ＦＩＲ）フィルタまたは固定フィルタのうちの少なくとも１つを利用してフィルタリングされる、条項７に記載のコンピュータ実装方法。  
９．前記入力データが、頭部の位置またはコンピューティングデバイスの動きのうちの少なくとも一方に相当し、前記リスナークライアント及び前記プルクライアントがイネーブルにされて、前記第１のイベントデータまたは前記第２のイベントデータのうちの少なくとも一方に少なくとも一部基づいて、頭部の位置の変化またはジェスチャーのうちの少なくとも一方を特定する、条項５に記載のコンピュータ実装方法。  
１０．前記パブリッシャーコンポーネントを利用して少なくとも１つのリスナーマップを分析して、前記第１のイベントデータを提供する前記少なくとも１つのリスナークライアントを特定し、前記少なくとも１つのリスナーマップがさらに、前記少なくとも１つのリスナークライアントのためのインターフェース情報をさらに含んでいることをさらに含む、条項５に記載のコンピュータ実装方法。  
１１．前記センサデータに少なくとも一部基づいて、前記少なくとも１つのモーションセンサの特定されたモーションセンサがエラー状態にあることを判定することと、
前記特定されたデバイスがエラー状態にあることに応答して前記特定されたモーションセンサをリスタートすることとをさらに含み、
前記特定されたモーションセンサがリスタートする間も前記画像データ及び前記センサデータの処理作業が継続している、条項５に記載のコンピュータ実装方法。  
１２．前記画像データと共に受信されたメタデータに少なくとも一部基づいて、前記カメラがエラー状態であることを判定することと、
前記カメラがエラー状態にあることに応答して第２のハードウェアインターフェースをリセットすることとをさらに含む、条項５に記載のコンピュータ実装方法。  
１３．前記第２のイベントデータが、前記ポーリングリクエストに応答するという条件で、少なくとも１つのインターフェースレイヤ及び少なくとも１つのプロセス間通信（ＩＰＣ）レイヤを通過するようにし、前記イベントデータがさらに、前記プルクライアントによって受信されるように前記イベントデータを修正するために、少なくとも１つの言語インターフェースコンポーネントを通過することが可能であることをさらに含む、条項５に記載のコンピュータ実装方法。  
１４．前記第１のイベントデータまたは前記第２のイベントデータの特有のタイプの少なくとも一方を聞くように構成された少なくとも１つのデータマネージャーコンポーネントをリスナーとして登録することをさらに含む、条項５に記載のコンピュータ実装方法。  
１５．ポリシーサービスと通信することで、リスナークライアント、プルクライアントまたはデータマネージャーのうちの少なくとも１つから受信したリクエストをどのように処理するかを特定することをさらに含む、条項１４に記載のコンピュータ実装方法。  
１６．少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによって実行される際、
前記コンピューティングデバイスに
第１のハードウェアインターフェースを介して、前記コンピューティングデバイスの少なくとも１つのモーションセンサを利用して取得されるセンサデータを受信させ、
第２のハードウェアインターフェースを介して、前記コンピューティングデバイスのカメラを利用して取得される画像データを受信させ、
前記コンピューティングデバイスの少なくとも１つのプロセッサを利用して、前記画像データと前記センサデータを処理して入力データを生成させ、
第１のイベントデータを受信するように登録された少なくとも１つのリスナークライアントに第１のイベントデータとして前記入力データを提供させ、
プルクライアントからのポーリングリクエストに応答して第２のイベントデータとして前記入力データを提供させる指示を含むメモリとを備える前記コンピューティングデバイス。  
１７．実行される際の指示がさらにコンピューティングデバイスに、
前記センサデータをシンクロナイザコンポーネントに記憶させ、
前記センサデータの受信の時間を示す時間情報を記憶させ、
前記画像データを受信させ、
前記時間情報を伴う前記センサデータと、前記画像データをエンジンに転送することで入力データを生成させる、条項１６に記載のコンピューティングデバイス。  
１８．実行される際の指示がさらにコンピューティングデバイスに
少なくとも１つのモニタリングコンポーネントを利用して前記画像データと前記センサデータを分析することで、少なくとも１つのモーションセンサまたはカメラがエラー状態にあることを判定させ、前記少なくとも１つのモニタリングコンポーネントが、前記少なくとも１つのモーションセンサまたはカメラがエラー状態から出るようにするように試みるように構成される、条項１６に記載のコンピューティングデバイス。  
１９．前記少なくとも１つのモーションセンサが、ジャイロスコープ、加速度計、慣性センサまたは電子コンパスのうちの少なくとも１つを含む、条項１６に記載のコンピューティングデバイス。  
２０．実行される際の指示がさらにコンピューティングデバイスに
前記入力データを処理して第１のイベントデータまたは第２のイベントデータの少なくとも一方を生成させ、前記第１のハードウェアインターフェースを介して受信した前記センサデータに少なくとも一部基づいて前記入力データを平滑化するように入力データが処理されており、前記入力データは、動きに適応性のある融合フィルタ、パススルーフィルタ、有限インパルス応答（ＦＩＲ）フィルタまたは固定フィルタのうちの少なくとも１つを利用して処理されている、条項１６に記載のコンピューティングデバイス。
【００５０】
明細書及び図面はしたがって、制限的な意味ではなく例示としてみなすべきである。しかしながら、特許請求の範囲に記載されるより広範な本発明の精神及び範囲から逸脱することなく種々の修正及び変更をそれに対して行うことができることは明らかである。
【図１（ａ）】
2017525024.tif 000003
【図１（ｂ）】
2017525024.tif 000004
【図２（ａ）】
2017525024.tif 000005
【図２（ｂ）】
2017525024.tif 000006
【図２（ｃ）】
2017525024.tif 000007
【図２（ｄ）】
2017525024.tif 000008
【図２（ｅ）】
2017525024.tif 000009
【図３】
2017525024.tif 000010
【図４】
2017525024.tif 000011
【図５（ａ）】
2017525024.tif 000012
【図５（ｂ）】
2017525024.tif 000013
【図６】
2017525024.tif 000014
【図７】
2017525024.tif 000015
【国際調査報告】
2017525024.tif 000016
2017525024.tif 000017
2017525024.tif 000018
2017525024.tif 000019
2017525024.tif 000020