(57)【特許請求の範囲】
【請求項１】
ユーザーの画像データから導出される骨格モデル・データに基づく身体動きの動き認識および／または類似性解析の方法であって：
捕捉装置からユーザー・データ動き特徴を表す骨格動きデータを受領する段階であって、該骨格動きデータはシーン内のユーザーの位置に関係する、段階と；
受領された骨格動きデータの、プロトタイプ動き特徴データベースからの複数のプロトタイプ動き特徴に関するプロトタイプ平均に対する相互相関を決定する段階と；
前記骨格動きデータが前記複数のプロトタイプ動き特徴のそれぞれに対応する確からしさをランク付けする段階であって、それらの確からしさは前記相互相関に基づく、段階と；
前記複数のプロトタイプ動き特徴の部分集合に対して、分類動作を実行する段階であって、前記複数のプロトタイプ動き特徴の前記部分集合は、前記骨格動きデータに対応する相対的に最高の確からしさをもつ、段階とを含む、
方法。
【請求項２】
前記骨格動きデータが、一組の一次関節および一組の二次関節についての角度の対によって表現される角度ワイヤフレーム・データを含む、請求項１記載の方法。
【請求項３】
前記角度の対がテート・ブライアン角として表現される、請求項２記載の方法。
【請求項４】
前記骨格動きデータが、前記捕捉装置の座標系に対する胴体系の回転行列を含む、請求項１記載の方法。
【請求項５】
前記複数のプロトタイプ動き特徴を表すデータを、該複数のプロトタイプ動き特徴のそれぞれについての複数のトレーニング・サンプルに基づいて修正するトレーニング動作を実行する段階をさらに含む、請求項１記載の方法。
【請求項６】
前記骨格動きデータが前記複数のプロトタイプ動き特徴に対応する確からしさを得るモデルの能力を評価する試験動作を実行する段階をさらに含む、請求項１記載の方法。
【請求項７】
ユーザーの画像データから導出される骨格モデル・データに基づく身体動きの動き認識および／または類似性解析を実行するシステムであって：
処理ユニット；および
システム・メモリを有しており、前記システム・メモリは前記処理ユニットに：
捕捉装置からユーザー・データ動き特徴を表す骨格動きデータを受領する段階と；
受領された骨格動きデータの、プロトタイプ動き特徴データベースからの複数のプロトタイプ動き特徴に対する相互相関を決定する段階と；
前記骨格動きデータが前記複数のプロトタイプ動き特徴のそれぞれに対応する確からしさをランク付けする段階であって、それらの確からしさは前記相互相関に基づく、段階と；
前記複数のプロトタイプ動き特徴の部分集合に対して、分類動作を実行する段階であって、前記複数のプロトタイプ動き特徴の前記部分集合は、前記骨格動きデータに対応する相対的に最高の確からしさをもつ、段階とを実行させるよう構成されたコードを含む、
システム。
【請求項８】
前記処理ユニットに、前記複数のプロトタイプ動き特徴を表すデータを、該複数のプロトタイプ動き特徴のそれぞれについての複数のトレーニング・サンプルに基づいて修正するトレーニング動作を実行させるよう構成されたコードを含む、請求項７記載のシステム。
【請求項９】
前記処理ユニットに、前記骨格動きデータが前記複数のプロトタイプ動き特徴に対応する確からしさを得るモデルの能力を評価する試験動作を実行させるコードを含む、請求項７記載のシステム。
【請求項１０】
処理ユニットに：
捕捉装置からユーザー・データ動き特徴を表す骨格動きデータを受領する段階と；
受領された骨格動きデータの、プロトタイプ動き特徴データベースからの複数のプロトタイプ動き特徴に関するプロトタイプ平均に対する相互相関を決定する段階と；
前記骨格動きデータが前記複数のプロトタイプ動き特徴のそれぞれに対応する確からしさをランク付けする段階であって、それらの確からしさは前記相互相関に基づく、段階と；
前記複数のプロトタイプ動き特徴の部分集合に対して、分類動作を実行する段階であって、前記複数のプロトタイプ動き特徴の前記部分集合は、前記骨格動きデータに対応する相対的に最高の確からしさをもつ、段階とを実行させるためのコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は動き認識に関する。
【背景技術】
【０００２】
コンピュータ・ゲームおよびマルチメディア・アプリケーションのようなコンピューティング・アプリケーションは、ゲーム・キャラクターまたはアプリケーションの他の側面をユーザーが操作できるようにする制御を使ってきた。典型的には、そのような制御は、たとえばコントローラ、リモコン、キーボード、マウスなどを使って入力される。より最近は、コンピュータ・ゲームおよびマルチメディア・アプリケーションは、カメラおよびソフトウェア・ジェスチャー認識エンジンを使って人‐コンピュータ・インターフェース（HCI:  human  computer  interface）または自然なユーザー・インターフェース（NUI:  natural  user  interface）を提供するようになってきた。HCIやNUIでは、ユーザー動きが検出され、いくつかの動きまたは姿勢が、ゲーム・キャラクター（たとえばユーザーのアバター）またはマルチメディア・アプリケーションの他の側面を制御するために使われるジェスチャーを表す。
【０００３】
自然なユーザー・インターフェースでは、画像捕捉装置がその視野内のユーザーの動きの画像を捕捉する。視野は、有限のユークリッド三次元（3D）空間として表現できる。たとえば、ユーザーが体操またはダンスのような活動を実行することによって運動できるようにするゲームが生成されうる。ゲーム装置がユーザーの動きパターンを認識できることが望ましいことがある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
下記は、本稿に記載されるいくつかの側面の基本的な理解を提供するために、本革新の簡略化された概要を呈示する。この概要は、特許請求される主題の包括的な概観ではない。特許請求される主題のキーとなるまたは決定的な要素を特定することも、主題となる革新の範囲を画定することも意図されていない。その唯一の目的は、のちに呈示されるより詳細な記述への導入として、特許請求される主題のいくつかの概念を、簡略化された形で呈示しておくことである。
【課題を解決するための手段】
【０００５】
ユーザーの画像データから導出される骨格モデル（skeletal  model）によって表現される人体の動きの認識のための技術が提示される。動き認識の例示的な方法は、捕捉装置からユーザー・データ動き特徴を表す骨格動きデータを受領する段階を含む。該骨格動きデータはシーン内のユーザーの位置に関係する。受領された骨格動きデータの、プロトタイプ動き特徴データベースからの複数のプロトタイプ動き特徴に対する相互相関が決定される。骨格動きデータが前記複数のプロトタイプ動き特徴のそれぞれに対応する確からしさがランク付けされる。それらの確からしさは前記相互相関に基づく。前記複数のプロトタイプ動き特徴の部分集合に対して、分類動作が実行される。前記複数のプロトタイプ動き特徴の前記部分集合が選ばれるのは、前記部分集合の要素が前記骨格動きデータに対応する相対的に最高の確からしさをもつことによる。分類動作の「勝者」が、受領された骨格動きデータによって表される動きに対するマッチとして選ばれてもよい。
【０００６】
体の動きの動き認識および／または類似性解析を実行するシステムに関係する技術がさらに提示される。動き認識は、ユーザーの画像データから導出される骨格モデル（skeletal  model）に基づいていてもよい。ある実施形態では、システムは処理ユニットおよびシステム・メモリを含む。システム・メモリは一つまたは複数の有体の非一時的なコンピュータ可読記憶媒体を含む。有体の非一時的なコンピュータ可読記憶媒体は、処理ユニットに、捕捉装置からユーザー・データ動き特徴を表す骨格動きデータを受領するよう指令するよう構成されたコードを含む。追加的なコードが、処理ユニットに、受領された骨格動きデータの、プロトタイプ動き特徴データベースからの複数のプロトタイプ動き特徴に対する相互相関を決定するよう指令する。さらなる追加的なコードは、処理ユニットに、骨格動きデータが前記複数のプロトタイプ動き特徴のそれぞれに対応する確からしさをランク付けするよう指令する。ある例示的な実施形態では、それらの確からしさは前記相互相関に基づく。他のコードが、処理ユニットに、前記複数のプロトタイプ動き特徴の部分集合に対して、分類動作を実行するよう指令する。前記複数のプロトタイプ動き特徴の前記部分集合が選ばれるのは、要素が前記骨格動きデータに対応する相対的に最高の確からしさをもつことによる。
【０００７】
一つまたは複数の有体の非一時的なコンピュータ可読記憶媒体に関係する技術がさらに提示される。前記有体の非一時的なコンピュータ可読記憶媒体は、プロセッサに、捕捉装置からユーザー・データ動き特徴を表す骨格動きデータを受領するよう指令しうるコードを記憶している。前記有体の非一時的なコンピュータ可読記憶媒体に記憶された追加的なコードが、プロセッサに、受領された骨格動きデータの、プロトタイプ動き特徴データベースからの複数のプロトタイプ動き特徴に対する相互相関を決定するよう指令する。前記有体の非一時的なコンピュータ可読記憶媒体上の他のコードが、プロセッサに、骨格動きデータが前記複数のプロトタイプ動き特徴のそれぞれに対応する確からしさをランク付けするよう指令する。それらの確からしさは前記相互相関に基づいていてもよい。前記有体の非一時的なコンピュータ可読記憶媒体上に記憶されている追加的なコードが、プロセッサに、前記複数のプロトタイプ動き特徴の部分集合に対して、分類動作を実行するよう指令する。前記複数のプロトタイプ動き特徴の前記部分集合が選ばれるのは、該部分集合の要素が前記骨格動きデータに対応する相対的に最高の確からしさをもつことによる。
【０００８】
以下の記述および付属の図面は特許請求される主題のある種の例示的な側面を詳細に記述する。しかしながら、これらの側面は、本革新の原理が用いられうるさまざまな仕方のほんのいくつかを示すものであり、特許請求される主題は、そのようなすべての側面およびその等価物を含むことが意図されている。特許請求される主題の他の利点および新規な特徴は、図面との関連で参酌する、本革新の以下の詳細な説明から明白となるであろう。
【図面の簡単な説明】
【０００９】
【図１Ａ】動き認識のための技術実施形態が動作できる、ユーザーが対話しているターゲット認識、解析および追跡システムのある例示的な実施形態を示す図である。
【図１Ｂ】カメラ視野および該視野内で定義される3D直交座標基準系の実施形態を示す図である。
【図１Ｃ】ユーザーのパフォーマンスに際してユーザーにフィードバックを与える視覚的に特徴的なインジケーターの例を示す図である。
【図２】一つまたは複数の実施形態によって使われることのできる、ユーザーの骨格モデルの例を示す図である。
【図３】ターゲット認識、解析および追跡システムのある実施形態において使用されうる捕捉装置の例示的な実施形態を示す図である。
【図４】ターゲット認識、解析および追跡システムのある実施形態において使用されうるジェスチャー分類システムの例示的な実施形態を示すブロック図である。
【図５】本願の技術に基づく動き認識の例示的な方法を示すプロセス流れ図である。
【図６】本願の技術に基づくダンス・ステップ認識を実行するためにモデルがトレーニングされるトレーニング・フェーズを示すブロック図である。
【図７Ａ】図７Ｂとともに、本願の技術に基づく、複数のクラス動きについてのトレーニング・フェーズを示すブロック図である。
【図７Ｂ】図７Ａとともに、本願の技術に基づく、複数のクラス動きについてのトレーニング・フェーズを示すブロック図である。
【図８】動き認識を実行する前にユーザー・データを記憶されているプロトタイプ・データと整列させるために使用されうる位相シフト・プロセスを示すブロック図である。
【図９】本願の技術に基づく、モデルがダンス・ステップを認識する能力の試験を示すブロック図である。
【図１０】本願の技術に基づく、動きのサブシーケンスを分類するためのモデルの使用を示すブロック図である。
【図１１】本願の技術に基づく、ジェスチャー認識エンジン実施形態のブロック図である。
【図１２】ターゲット認識、解析および追跡システムにおいて人体動きを認識するために使用されうるコンピューティング環境の例示的な実施形態を示す図である。
【図１３】ターゲット認識、解析および追跡システムにおいて人体動きを認識するために使用されうるコンピューティング環境のもう一つの例示的な実施形態を示す図である。
【発明を実施するための形態】
【００１０】
特許請求される主題は図面を参照して記述される。全図を通じて、同様の要素を指すために同様の参照符号が使われる。以下の記述では、説明の目的で、主題となる革新の十全な理解を提供するために数多くの個別的な詳細が記載される。しかしながら、特許請求される主題がこうした個別的な詳細なしでも実施されうることは明白であろう。他方、主題となる革新を記述するのを容易にするため、よく知られた構造および装置はブロック図の形で示されている。
【００１１】
本稿での用法では、「コンポーネント」、「システム」、「マルチメディア・コンソール」、「ゲーム・コンソール」などの用語は、ハードウェア、ソフトウェア（たとえば実行中）および／またはファームウェアのいずれであれ、コンピュータ関係のエンティティを指すことが意図される。たとえば、コンポーネントは、プロセッサ上で走っているプロセス、オブジェクト、実行可能物、プログラム、関数、ライブラリ、サブルーチンおよび／またはコンピュータまたはソフトウェアとハードウェアの組み合わせであることができる。例示として、サーバー上で走っているアプリケーションと該サーバーは、コンポーネントであることができる。一つまたは複数のコンポーネントがプロセス内に存在することができ、コンポーネントは一つのコンピュータ上に局在していることも、および／または二つ以上のコンピュータ間に分散されていることもできる。「プロセッサ」の用語は一般に、コンピュータ・システムの処理ユニットのような、ハードウェア・コンポーネントを指すものと理解される。
【００１２】
さらに、特許請求される主題は、開示される主題を実装するようコンピュータを制御するためのソフトウェア、ファームウェア、ハードウェアまたはその任意の組み合わせを生成するための標準的なプログラミングおよび／またはエンジニアリング技法を使って、方法、装置または製造物として実装されうる。本稿で使うところの用語「製造物」は、コンピュータ可読記憶媒体のような任意の非一時的なコンピュータ可読デバイスまたは媒体からアクセス可能なコンピュータ・プログラムを包含することが意図されている。
【００１３】
非一時的なコンピュータ可読記憶媒体は、これに限られないが、磁気記憶デバイス（たとえば中でもハードディスク、フロッピー(登録商標)ディスクおよび磁気ストリップ）、光ディスク（たとえば中でもコンパクトディスク（CD）およびデジタル多用途ディスク（DVD））、スマートカードおよびフラッシュメモリ・デバイス（たとえば中でもカード、スティックおよびキー・ドライブ）を含むことができる。これとは対照的に、コンピュータ可読媒体といえば、一般的に（すなわち、必ずしも記憶媒体ではなく）、さらに電気信号もしくは電気信号などの伝送媒体のような通信媒体をも含む。
【００１４】
当業者は、特許請求される主題の範囲もしくは精神から外れることなく、この構成に対して多くの修正がなしうることを認識するであろう。さらに、本稿では単語「例示的」は例、事例または例示のはたらきをすることを意味するために使われる。本稿で「例示的」として記述されるいかなる側面もしくはデザインも、必ずしも、他の側面もしくはデザインに対して好ましいまたは有利であると解釈されない。
【００１５】
本願の技術は、骨格ワイヤフレーム動きのためのリアルタイムのジェスチャー分類システムに関する。ある例示的な実施形態は、ノイズの多い入力のもとでの認識の堅牢性を提供する骨格の角度表現、多変量時系列データについての縦続式の相関ベース分類器および取得されたジェスチャー（すなわちユーザー入力の動き特徴）と一致するジェスチャーについてのオラクル（すなわちプロトタイプ動き特徴）との間の動きの相違を評価するための動的な時間歪め（time-warping）に基づく距離メトリックを含む。分類器が縦続式（cascaded）にされるのは、二フェーズの動作を実行するからである。第一フェーズでは、プロトタイプ動き特徴データが、相互相関に基づいてスコア付けされる。ユーザーの動きを表すデータがそれぞれの特定のプロトタイプ動き特徴に対応する最大の確からしさを計算するためである。第二フェーズでは、ユーザー入力に一致する最高の確からしさをもつ諸プロトタイプ動き特徴が、分類動作にかけられて、最も近いマッチが選択される。分類動作はいくつかの技法を含んでいてもよく、若干例を挙げると、ロジスティック回帰を使ったペア毎の分類（pairwise  classification）、線形判別分析またはサポートベクターマシン（SVM:  support  vector  machine）解析などがある。本願の技術に基づく分類器は、入力動きが、音楽の拍子のような既知の、正準的な時間ベースに従うという想定のもとで動作しうる。
【００１６】
リアルタイムの奥行き感知システムは、人体がゲームのアクションを制御できるようにするために使用できるので、ビデオ・ゲームにおいて有用である。一つのそのようなシステムは、毎秒30フレームで奥行きマップ・ストリームをパースして、動いているユーザーのワイヤフレーム骨格を構成する16個のあらかじめ定義された点の位置をリアルタイムで推定する。すると、その後のアルゴリズム処理が、ゲームプレーを対話的に制御するためにユーザーの動きを理解しようと（たとえばユーザー・ジェスチャーを認識しようと）試みることができる。
【００１７】
本願の技術の例示的な実施形態は、データベースにおいてプロトタイプ動き特徴としてモデル化されているあらかじめ振り付けされたジェスチャーのうちの任意のものを任意の時点においてダンサー（ユーザー）が踊ることを許容することによって、ダンサー（ユーザー）がアバター・アニメーションに対してもつ対話および制御を向上させうる。この目的に取り組むため、例示的なシステムは、所定のジェスチャー・クラスの集合のニュアンスを捕捉する統計的モデルを学習し、次いで、そのモデルを使ってユーザーの入力骨格動きを分類する。
【００１８】
まず図１Ａを参照するに、本願の技術を実装するためのハードウェアは、ユーザー１０６のような人間のターゲットを認識、解析および／または追跡するために使用されうるターゲット認識、解析および追跡システム１００を含む。ターゲット認識、解析および追跡システム１００の実施形態は、ゲームまたは他のアプリケーションを実行するためのコンピューティング環境１０２と、ゲームまたは他のアプリケーションからのオーディオおよびビジュアル表現を提供するためのオーディオビジュアル装置１６とを含む。システム１００はさらにユーザーによって実行される動きおよび位置を捕捉する捕捉装置１１０を含む。これらをコンピューティング環境が受け取り、解釈し、ゲームまたは他のアプリケーションを制御するために使う。これらのコンポーネントのそれぞれは、のちにより詳細に説明する。
【００１９】
図１Ａに示されるように、ある例示的な実施形態では、コンピューティング環境１０２上で実行されているアプリケーションは、ユーザー１０６がプレイしていることがありうるボクシング・ゲームのような、リアルタイム対話をもつゲームであってもよい。たとえば、コンピューティング環境１０２はオーディオビジュアル装置１６を使って、ボクシング対戦相手１０８の視覚的表現をユーザー１０６に対して提供してもよい。コンピューティング環境１０２はまた、オーディオビジュアル装置１６を使って、ユーザー１０６が自分の動きで制御しうるプレーヤー・アバター１１２の視覚的表現を提供してもよい。たとえば、ユーザー１０６は物理的な空間においてパンチを繰り出すことで、プレーヤー・アバター１１２にゲーム空間においてパンチを出させてもよい。このように、ある例示的な実施形態によれば、ターゲット認識、解析および追跡システム１００のコンピュータ環境１０２および捕捉装置１１０は、物理的な空間内でのユーザー１０６のパンチを認識および解析するために使用されてもよく、それによりそのパンチがゲーム空間におけるプレーヤー・アバター１１２のゲーム制御として解釈されてもよい。
【００２０】
ユーザー１０６による他の動きも他の制御またはアクションとして解釈されうる。たとえば、ちょっと頭を下げる、ウィービングする、すり足する、ブロックする、ジャブを出すまたは多様な異なるパワー・パンチを繰り出すなどの制御である。ユーザー動きをモデル化するために使われるデータは、動き、姿勢、手の位置などに対応するデータを含んでいてもよい。図１Ｂは、カメラ視野１１４および該視野内に定義される3D直交座標基準系の実施形態を示している。この例では、ユーザー１０６は、ユーザーが音楽に合わせて踊るダンス・エクササイズ・アプリケーションと対話している。ユーザー１０６の動きは捕捉装置１１０によって捕捉される。捕捉装置１１０は、コンピューティング環境１０２と連携して、ボクシングの例と同じように、ディスプレイ上のアバターの動きをアニメートし、制御する。その動きの一部はジェスチャーであってもよい。
【００２１】
3D直交座標基準系の原点は捕捉装置１１０の視野の中心に描かれており、ユーザー１０６と肘掛け椅子１１８の間に位置している。以下で論じる骨格モデルは捕捉された各画像フレームから導出される。最初は、骨格モデルはこのカメラ・ベースの座標系で表現される。この座標系がカメラ・ベースと呼ばれるのは、カメラの位置が視野を決め、空間はカメラに対して定義される平面および法線を使って特徴付けられるからである。カメラ・ベースの基準系は固定されており、ユーザーとともに動きはしない。
【００２２】
図１Ｃは、ユーザー１０６のパフォーマンスに際してユーザー１０６にフィードバックを提供するオーディオビジュアル装置１０４上でのユーザーのプレーヤー・アバター１１２上で、ユーザーに対して表示される、視覚的に特徴的なインジケーター１２０の例を示す図である。プレーヤー・アバター１１２の右脚がオーディオビジュアル装置１０４上の視覚的に特徴的なインジケーター１２０を介して描かれており、ユーザーの右脚による脚上げが、モデルまたはダンス・エクササイズ・ゲームを使う他者によって実行される平均の脚上げジェスチャーの標準、たとえば高さを満たしていないという視覚的なフィードバックを提供する。
【００２３】
図２は、捕捉装置１１０から生成されうるユーザーの例示的な骨格マッピングを描いている。この実施形態では、多様な関節および骨が同定されている：左右の手２０２、左右の前腕２０４、左右の肘２０６、左右の二頭筋２０８、左右の肩２１０、左右のヒップ２１２、左右の腿２１４、左右の膝２１６、左右の前脚２１８、左右の足２２０、頭２２２、脊椎中央２２４、脊椎の頂部２２６および底部２２８およびウエスト２３０。より多くの点が追跡される場合には、手指または足指の骨および関節または鼻や目などの顔の個々の特徴などといった、追加的な特徴が同定されてもよい。図２に示される点の一つまたは複数が省略されてもよく、および／または他の点が追加されてもよいことは理解される。さらに、骨格マッピングはユーザーのコンピュータ・モデルの一例であり、他のコンピュータ・モデルも考えられる。
【００２４】
図２における各点は、捕捉装置１１０に対する基準系におけるx、yおよびz座標による三次元のデカルト空間（カメラ空間）において記述されてもよい。このことの一つの帰結は、この基準系における関節の任意の絶対的な動きが計算されるべきであるということである。たとえば、再び図１Ｂを参照するに、ユーザー１０６が、手１０６ａをまっすぐ下げて体に対して静止させたままこの基準系において動いている場合、それでもその手はカメラ空間の基準系では動いている。前のフレームに対する、カメラ空間におけるその動きを決定するには、時間およびプロセッサ資源が要求される。
【００２５】
身体部分の基準系を、絶対的な動きが測定されるカメラ空間から、「上流の」関節に対して動きが測定される基準系に適合させるまたは変換することが、本願の技術の一つの側面である。この基準系は、身体空間または身体基準系と称される。ある実施形態では、上流の関節は、胴体により近い、次の隣接する関節である。よって、手首の上流関節は肘であり、肘の上流関節は肩であり、足首の上流関節は膝であり、膝の上流関節はヒップである。
【００２６】
カメラ基準系から身体基準系への剛体変換（たとえば並進および回転）は、関節位置に関して同じ情報を与えるが、より効率的かつ低エントロピーの仕方でである。ユーザーが手１０６ａを体側に静止させたまま視野を通じて動いている上記の例を続けると、絶対（カメラ）空間では動いているが、ユーザーの手はその上流関節に対して動いていない。よって、身体空間におけるユーザーの手の追跡は、フレームからフレームへの関節の追跡を簡単にする。一般に、関節の他の関節に対する動きを追跡することは、下記で説明するように、より小さな探索空間およびデータ・セットならびにより高速な処理およびジェスチャー認識につながる。それは、3Dにおける相似変換（スケーリング、回転、並進）の群に対して不変な表現である。
【００２７】
やはり下記で説明するように、本願の技術のもう一つの側面は、肩およびヒップを含む胴体を剛体として扱うというものである。この良好な近似は、胴体が、カメラ空間に対する後述する三つの角度で記述されることを許容し、骨格追跡を簡単にする。
【００２８】
本願の技術は、ダンス・ステップなどのような比較的複雑なジェスチャーを認識および解釈できるターゲット認識、動き解析および追跡システム１００を提供しうる。さらに、熟達者によって実行された特定のダンス・ステップまたは動きを表すプロトタイプ・ジェスチャー・データがトレーニング・プロセスにおいて用いられてもよく、次いで、捕捉装置１１０によって得られたユーザー・ジェスチャー・データに基づいてユーザーによって実行されたステップを分類するまたはユーザーのパフォーマンスを評価もしくはレート付けするために使用されてもよい。本願の技術によれば、該データは、精確、スケーラブルかつ堅牢な仕方で評価されうる。
【００２９】
ある例示的な実施形態では、ダンス・ステップに対応する特定の動きが、図２に示される骨格点の少なくとも一部の動きに関係するユーザー入力データに基づいて評価される。これらの点の相対的な動きが何らかの固定した時間期間（たとえば音楽の8拍）にわたって評価され、特定のプロトタイプ動きまたはステップのカタログを表す記憶されているプロトタイプ・データと比較される。次いで、どの特定のダンス・ステップまたは動きがユーザーによって実行されているかに関する判定がなされてもよい。明確に区別されるプロトタイプ・ステップまたは動きは本稿では動きクラス（motion  class）と称される。さらに、ユーザーの測定された動きおよびエネルギーの、プロトタイプ・データとの相関が、その特定のダンス動きが実行されているというユーザーの解釈の品質を表すスコアを与えるために使われてもよい。
【００３０】
図２に示される骨格点に対応する入力データに基づいて、ダンス・ジェスチャーの効果的な認識を可能にする動き特徴の組が推定されてもよい。ある例示的な実施形態は、再レンダリングのために必要とされる完全性のレベルまたは精度に依存しない、いくつかの特定の目標に基づいてジェスチャー認識を実行してもよい。前記目的はエントロピー低減を含む。エントロピー低減を容易にするため、ワイヤフレーム関節は、伝統的な関節‐角度表現でのように、その親ノードに対して表現されてもよい。発見法的に、これは結果として得られる多変量時系列のエントロピーを低下させるべきである。
【００３１】
ある例示的な実施形態のもう一つの目的は、データ誤りを克服する能力における堅牢性である。さらに、本願の技術は、動き捕捉システムに比較した、リアルタイム奥行きセンサーについてのデータ堅牢性を提供することにも関する。第一の関連する因子は、骨格追跡アルゴリズムを通じて伝搬して結果として得られる骨格データにはいってくる、感知システムに固有の強い加法性ノイズの存在である。第二の関連する因子は、誤りのもとになりうる、骨格の隠蔽された部分の推定に関係する。
【００３２】
ある例示的な実施形態は、入力センサー配向に対する不変性を提供してもよい。さらに、ある実施形態は、カメラ位置に対する骨格表現の不変性を最大化するよう努めてもよい。
【００３３】
相対的な位置を計算するために使われる座標軸を、信号不連続、たとえばジンバル・ロック（gimbal  lock）の確率を最小化するよう配向させることによって、信号連続性および安定性が提供されうる。この目的は、ジェスチャー検出のための規格化された相関を使うときに特に有意である。
【００３４】
動きの特性を保持しつつ、分類のための探索空間に対して次元削減が用いられてもよい。アニメーションまたは動き捕捉に焦点を与える表現に比較して、ある例示的な実施形態は、完全に可逆でなくてもよい特徴を計算することに関する。
【００３５】
人間の胴体の点（図２に示される7個の骨格ノード２１０ａ、２１０ｂ、２１２ａ、２１２ｂ、２２４、２２６、２２８によって定義される）が強い独立した動きを示すことはめったにない。よって、胴体は縦長の剛体として扱うことができる。それでも、奥行き感知システムにおける強いノイズ・パターンのため、個々の胴体点、特に肩およびヒップが現実的でない動きを示すことがあると観察されることがある。そのような現実的でない動きは、相対表現によって伝搬されるのではなく、制限されることが望ましいであろう。よって、胴体は剛体として扱われ、その点すべてがその位置の推定に寄与するとしてもよい。すると、この推定が、人間の骨格の残りの部分を相対的な仕方で表現するために使用されうる。
【００３６】
胴体点についての主成分、すなわち3D直交基底が、7かける3の胴体行列に主成分解析（PCA:  principal  component  analysis）を適用した結果として計算されてもよい。第一の主成分u〔ベクトル〕は胴体のより長い寸法方向と整列させられる。これは正準的に（上下方向に）配向されてもよい。たいていのダンスではプレーヤーの胴体がセンサーに対して上下さかさまになることは予期されないからである。対照的に、両肩をつなぐ直線と整列させられる二番目の主成分r〔ベクトル〕については、配向はそれほど簡単には推定されず、ここでは骨格追跡アルゴリズムによって推定される「左右」骨格配向上に置かれてもよい。最後に、正規直交基底の最後の軸が、最初の二つの主成分のクロス積として計算される。すなわち〔ベクトル〕t＝u×rである。結果として得られる基底{u,r,t}は本稿では胴体系と称されることがある。
【００３７】
主題となる技術によれば、胴体系は、人体の配向に基づく座標系のための、堅牢かつ信頼できる基礎を与える。カメラ位置には依存するが、胴体系から導出される座標系内で表現される点は、センサーに対して完全に不変となりうる。これはもとの問題規定の7つの3D軌跡を、結果として得られる正規直交基底の3D基底のみを記述することをねらいとする新しい信号の組に帰着させる。本稿で述べるように、胴体の動きを直観的かつ堅牢に記述するために、一組の単純な特徴が用いられる。最後に、根底にある奥行きマップ・シルエットから胴体系をより正確に計算することも可能でありうる。さらに、そのようなアプローチの計算上のオーバーヘッドは、結果として得られる認識パフォーマンスの軽微な改善に関し、有利なトレードオフをもたらさない。
【００３８】
図２に示されるように、胴体に隣接する関節は一次関節として同定されてもよい。よって、一次関節は肘、膝および頭を含む。これらの点は、胴体系から導出される座標系において、胴体内の隣接関節を基準として表現されうる。本願の技術によれば、LE（left  elbow［左肘］）はLS（left  shoulder［左肩］）に対して表現されてもよい。第一に、胴体系{u,r,t}がLSに並進されてもよい。原点がLSを中心とし、天頂軸がuであり、方位角軸がrとなるよう、球面座標系が構築されてもよい。すると、LEの位置はその動径R（原点からのLEの距離）、その傾斜θ（ベクトルuと、LEからLSへのベクトルとの間の角度）および方位角φ（ベクトルrとLEpからLSへのベクトルとの間の角度；ここでLEpはLEの、uを法線とする平面への投影（projection））によって記述されうる。
【００３９】
人間の骨の長さは規格化され、一定なので、動径Rはこの先の考察については無視してもよい。よって、この表現モデルを使うと、各一次関節は二つの角{θ,φ}をもって表現される。
【００４０】
二次関節はワイヤフレーム外肢の先端として表されてもよい。よって、二次関節は手および足を含む。二次関節に関連する最も記述的なベクトルは、隣接する一次関節とその隣接する胴体関節をつなぐ骨である。たとえば、上腕骨から突き出るベクトルbは、左肘LEに原点のある球面座標系の天頂方向についての潜在的な良好な候補である。左手（left  hand）の関節はLHと表されてもよい。すると、LHの位置はその動径R（原点からのLHの距離）、その傾斜θ（ベクトルbと、LHからLEへのベクトルとの間の角度）および方位角φ（rの、bを法線とする平面Sへの投影であるベクトルrpと、LHpからLEへのベクトルとの間の角度；ここで、LHpはLHのS上への投影）によって記述されうる。
【００４１】
前腕骨の長さは規格化され、一定なので、動径Rは無視してもよい。よって、モデルは各二次関節を二つの角度{θ,φ}を使って表現してもよい。その結果は、一次関節の結果と同じだが、一つ顕著な違いがある。二次関節についての傾斜θは異例なほど堅牢な記述子である一方、方位角はそうではない。球面座標系の原点は胴体系を定義する剛体の一部ではないため、rの配向は胴体の配向に依存し、φにノイズを導入する。この効果は有意ではないことが確認されており、分類器の残りの動作に関して有意な問題を呈するものではない。
【００４２】
ベクトルbおよびrは、b・r＝1となるよう配向され、よって投影rpが一点になることがありうる。そうなる可能性は低いが、bとrの間の角度が小さい場合には常に、rpの不安定性のため、ノイズ・レベルの増大に直面する可能性が高い。この問題はいくつかの仕方で解決できるが、rが方位角基準として選ばれる場合にはb・r≒1というケースが起こる頻度が低いことが観察されている。rの代わりにベクトルuまたはtまたはそれらの何らかの線形結合を使うことができるが、最終的なパフォーマンスに対しては幅広い範囲の影響がある。rの選択は、上記の問題を十分に減衰させることが観察されている。
【００４３】
ある例示的な実施形態では、角度ワイヤフレーム・モデルが、一次および4つの二次関節の各組についての8対の角{θ,φ}およびカメラの座標系に対する胴体系の回転行列によって表現される。ある例示的な実施形態では、頭点は無視されるので、四つの一次点しかない。
【００４４】
回転行列をパラメータ表現するためには、「狭義の」オイラー角を考えてもよいが、「狭義の」オイラー角の値は予測できないほどジンバル・ロックを受けやすいことを示す証拠がある。この問題は四元数を使って回避できるが、四元数はどちらかというと直観的でない時系列データを与えることが観察されている。ある例示的実施形態では、テート・ブライアン（Tait-Bryan）角（すなわち、ヨー、ピッチ、ロール）が使われる。骨格追跡アルゴリズムがスピンしているプレーヤーを追跡することをサポートしない場合、テート・ブライアン角は、ジンバル・ロックをほとんど導入しないような配向にされることができる。これは、本願の技術による分類器における規格化された相関方式のパフォーマンスを改善する。
【００４５】
骨格動きから得られる特徴時系列の集合は、f＝{fi(t),i＝1…19}として得られてもよい。この定式化は、入力の複雑さを、16個の3D曲線の集まりから19個の1Dベクトルの集合に減らすことを注意しておく。この単純化は、計算効率の観点から比較的実質的であり、結果として起こる情報の損失もまれであり、無視できることが観察されている。結果として、これらの特徴は分類のために好適である。整列された一次元の比較を容易にする相対的な仕方で動きを表現するからである。
【００４６】
図３は、ターゲット認識、解析および追跡システム１００において使用されうる捕捉装置１１０の例示的な実施形態を示す図である。本願の技術とともに使う捕捉装置に関するさらなる詳細は、上記の同時係属中の特許出願の一つまたは複数において記述されている。しかしながら、ある例示的な実施形態では、捕捉装置１１０は、たとえば飛行時間、構造化された光、ステレオ・イメージなどを含む任意の好適な技法を介して奥行き値を含みうる奥行き画像をもつビデオを捕捉するよう構成されていてもよい。ある実施形態によれば、捕捉装置１１０は計算された奥行き情報を、「Z層」または奥行きカメラからその視線に沿って延びるZ軸に垂直でありうる層に整理してもよい。
【００４７】
図３に示されるように、捕捉装置１１０は画像カメラ・コンポーネント１２４を含んでいてもよい。ある例示的な実施形態によれば、画像カメラ・コンポーネント１２４は、シーンの奥行き画像を捕捉しうる奥行きカメラであってもよい。奥行き画像は捕捉されたシーンの二次元（2D）ピクセル領域を含んでいてもよく、該2Dピクセル領域中の各ピクセルは、カメラからの捕捉されたシーン内のオブジェクトのたとえばセンチメートル、ミリメートルなどでの長さを表しうる。
【００４８】
図３に示されるように、ある例示的な実施形態によれば、画像カメラ・コンポーネント１２４は、シーンの奥行き画像を捕捉するために試用されうるIR光コンポーネント１２６、三次元（3D）カメラ１２８およびRGBカメラ１３０を含んでいてもよい。たとえば、飛行時間解析では、捕捉装置１１０のIR光コンポーネント１２６が赤外光をシーンに対して放出してもよく、次いで、たとえば3Dカメラ１２８および／またはRGBカメラ１３０を使ってシーン内の一つまたは複数のターゲットおよびオブジェクトの表面からの後方散乱光を検出するためにセンサー（図示せず）を使ってもよい。
【００４９】
もう一つの実施形態によれば、捕捉装置１１０は、奥行き情報を生成するために分解されうる視覚的なステレオ・データを得るために、異なる角度からシーンを見てもよい二つ以上の物理的に離間したカメラを含んでいてもよい。
【００５０】
捕捉装置１１０はさらにマイクロホン１３２を含んでいてもよい。マイクロホン１３２は、音を受領して電気信号に変換しうるトランスデューサまたはセンサーを含んでいてもよい。ある実施形態によれば、マイクロホン１３２は、ターゲット認識、解析および追跡システム１００内の捕捉装置１１０とコンピューティング環境１２との間のフィードバックを減らすために使用されうる。さらに、マイクロホン１３２は、コンピューティング環境１２によって実行されうるゲーム・アプリケーション、非ゲーム・アプリケーションなどのようなアプリケーションを制御するためにユーザーによって与えられてもよいオーディオ信号を受領するために使われてもよい。
【００５１】
ある例示的な実施形態では、捕捉装置１１０はさらに、画像カメラ・コンポーネント１２４と動作上通信してもよいプロセッサ１３４を含んでいてもよい。プロセッサ１３４は、奥行き画像を受領し、該奥行き画像に好適なターゲットが含まれていることがありうるかどうかを判定し、好適なターゲットを該ターゲットの骨格表現またはモデルに変換するための命令または他の任意の好適な命令を実行しうる標準化されたプロセッサ、特化されたプロセッサ、マイクロプロセッサなどを含んでいてもよい。
【００５２】
捕捉装置１１０はさらに、一つまたは複数の有体の機械可読記憶媒体を有するメモリ・コンポーネント１３６を含んでいてもよい。メモリ・コンポーネントは、プロセッサ１３４によって実行されうる命令、3DカメラまたはRGBカメラによって捕捉される画像もしくは画像のフレームまたは他の任意の好適な情報、画像などを記憶していてもよい。ある例示的な実施形態によれば、メモリ・コンポーネント１３６は、ランダム・アクセス・メモリ（RAM）、読み出し専用メモリ（ROM）、キャッシュ、フラッシュ・メモリ、ハードディスクまたは他の任意の好適な記憶コンポーネントを含んでいてもよい。図３に示されるように、ある実施形態では、メモリ・コンポーネント１３６は、画像カメラ・コンポーネント１２４およびプロセッサ１３４と通信する別個のコンポーネントであってもよい。別の実施形態によれば、メモリ・コンポーネント１３６はプロセッサ１３４および／または画像カメラ・コンポーネント１２４に統合されていてもよい。
【００５３】
図３に示されるように、捕捉装置１１０はコンピューティング環境１２と通信リンク１３８を介して通信していてもよい。通信リンク１３８は、たとえばUSB接続、ファイアワイヤ接続、イーサネット（登録商標）ケーブル接続などを含む有線接続および／または無線802.11b、g、aまたはn接続のような無線接続でありうる。ある実施形態によれば、コンピューティング環境１２は、いつ通信リンク１３８を介してたとえばシーンを捕捉するかを決定するために使用されうる、捕捉装置１１０へのクロックを提供してもよい。
【００５４】
さらに、捕捉装置１１０は、たとえば3Dカメラ１２８および／またはRGBカメラ１３０によって捕捉された奥行き情報および画像ならびに捕捉装置１１０によって生成されうる骨格モデルを通信リンク１３８を介してコンピューティング環境１２に提供してもよい。捕捉装置１１０によって検出されたターゲットまたはオブジェクトが人間のターゲットに対応するかどうかを判定するには多様な既知の技法が存在している。次いで、そのユーザーの骨格上のさまざまなスポット、手の関節、手首、肘、膝、首、足首、肩およびどこで骨盤が脊椎に出会うかを決定するために、骨格マッピング（skeletal  mapping）技法が使用されてもよい。他の技法は、画像をその人物の身体モデル表現に変換することおよび画像をその人物のメッシュ・モデル表現に変換することを含む。
【００５５】
次いで骨格モデルは、コンピューティング環境が該骨格モデルを追跡し、該骨格モデルに関連付けられたアバターをレンダリングしうるよう、コンピューティング環境１２に与えられてもよい。コンピューティング環境はさらに、骨格モデルから認識された、たとえばユーザーのジェスチャーに基づいて、コンピュータ環境上で実行されるアプリケーションにおいてどの制御を実行するかを決定してもよい。たとえば、図３に示されるように、コンピューティング環境１２はジェスチャー分類システム４００を含んでいてもよい。ジェスチャー分類システム４００は、以下で図４を参照して説明するが、概括的には、ジェスチャー・フィルタの集合を含んでいてもよい。各ジェスチャー・フィルタは、（ユーザーが動く際に）骨格モデルによって実行されうるジェスチャーに関する情報を含む。カメラ１２８、１３０および捕捉装置１１０によって、骨格モデルおよびそれに関連付けられた動きの形で捕捉されるデータは、いつ（骨格モデルによって表現される）ユーザーが一つまたは複数のジェスチャーを実行したかを同定するために、ジェスチャー分類システム４００内のジェスチャー・フィルタと比較されてもよい。そうしたジェスチャーは、アプリケーションのさまざまな制御に関連付けられていてもよい。よって、コンピューティング環境１２は、骨格モデルの動きを解釈し、該動きに基づいてアプリケーションを制御するために、ジェスチャー分類システム４００を使用してもよい。ある例示的な実施形態では、ユーザー入力または活動に対応するジェスチャー・データは、ユーザーが特定の活動、たとえば特定のダンスの動きをうまく実行したかどうかを判定するために、記憶されている熟達者のジェスチャー・データと比較されてもよい。
【００５６】
本願の技術のある例示的な実施形態は、全体的なシステム・パフォーマンスを改善するために角度による骨格表現を用いる。これは、骨格動きデータを、ノイズの多い入力から堅牢に推定することができるがそれでいて動きの顕著な側面を保持する諸特徴（それぞれスカラー時系列）のより小さなセットにマッピングするために使われる。そのねらいは、信号の全体的なエントロピーを低下させ、カメラ位置に対する依存性をなくし、ジンバル・ロック近くなどでの不安定なパラメータ構成を避けることである。そのアプローチは、単一の基準系を用いて胴体全体をフィッティングし、この基準系を使って一次および二次両方の肢関節の配向推定をパラメータ化することである。
【００５７】
ジェスチャー分類システム４００のある例示的な実施形態では、縦続された相関ベースの最大尤度多変量分類器が使用されてもよい。トレーニング・プロセスの間に、分類器は、プロトタイプ・データ（すなわちオラクル）および幅広い範囲のダンス技量をもつ被験者のグループによって実行されたジェスチャー・インスタンスのデータベース両方に基づいて、各ジェスチャー・クラスについて統計的モデルを構築する。実行時には、分類器は、多変量入力バッファを、各クラスについてのプロトタイプ・ジェスチャー・モデルと相関付けし、クラス毎の対数尤度スコアを構築する。次いで、それらのスコアを使ってすべてのクラスにランク付けし、上位の諸クラスの間でロジスティック回帰試験の諸ラウンドを実行して勝ち残るマッチを同定する。
【００５８】
ある例示的な実施形態は、分類器への骨格入力データがある拍子パターンに従うダンスを表しているとの想定のもとに動作しうる。よって、分類器は、実際の時間を無視して、入力時系列をサンプリングし直してもよい。それにより、固定した期間（たとえば8拍）内に、骨格動きのある数のフレーム（たとえば120）が生成される。このようにして、約30フレーム毎秒（fps）のフレーム・レートが提供されうる。分類器は、種々の音楽作品における拍子のペースには、比較的不変でありうる。さらに、同じジェスチャーを踊っている諸プレーヤーの異なるインスタンスどうしを歪み除去し（unwarp）同期させる必要性が減じられうる。前提とされうるもう一つの想定は、ゲーム中に演奏される音楽の各拍がラベル付けされているということである。このセッティングにおいては拍子検出アルゴリズムも使用できる。
【００５９】
ある例示的な実施形態では、プレーヤーが、限られた、よく定義された、既知の集合Mの、8拍にわたる動きK個のみを踊ることを許容されるという想定がなされる。このようにして、全体的なエラー・レートに対して不都合となりうるオンライン学習シナリオが回避される。はいってくるフレームは骨格動きデータとともに、先入れ先出し（FIFO:  first-in,  first-out）バッファに記憶されてもよい。分類に先立ち、コンテンツが8拍当たり120フレームのレートでサンプリングし直されてもよい。分類器は、M内の最もよく一致したクラスを見出し、最終的に、プレーヤーが一致したジェスチャーをどのくらいよく踊ったかを概説するレポートをもって応答する。
【００６０】
時空間収縮拡張距離メトリックが、入力ジェスチャーの、一致したプロトタイプ（オラクル）との堅牢な比較を達成するよう、時空間の指数関数的スケーリングをもつ動的な時間歪めを用いてもよい。骨格動きデータに存在するノイズや、人間は特定の動きを再現する幅広い範囲の能力を示すという事実にもかかわらず、ある例示的な実施形態は、よい性能を発揮している。
【００６１】
図４は、ターゲット認識、動き解析および追跡システムのある実施形態において使用されうるジェスチャー分類システム４００の例示的な実施形態を示している。この例示的なジェスチャー分類システム４００は、プレーヤー・パフォーマンス・コンポーネント４０２およびジェスチャー分類コンポーネント４０４を含む。プレーヤー・パフォーマンス・コンポーネント４０２はユーザーまたはプレーヤーに関する入力を取得し、ジェスチャー分類コンポーネント４０４はそのデータを解析し、ユーザー入力に関する分類情報を与える。
【００６２】
例示的なプレーヤー・パフォーマンス・コンポーネント４０２は、奥行き画像４０８を提供しうる奥行き感知モジュール４０６を含む。本稿で説明するように、奥行き画像４０８は、捕捉装置１１０によって取得されるビュー・フレーム内でのプレーヤーの3Dの位置付けに関する情報を表していてもよい。骨格追跡モジュール４１０がプレーヤーの身体のさまざまな部分の相対的な動きについて情報を取得する。ワイヤフレーム・データ４１２と称されてもよい骨格追跡データは、図２に関して本稿で述べた形のものであってもよい。
【００６３】
ジェスチャー分類コンポーネント４０４はジェスチャー・モデル・コンポーネント４１４を有する。ジェスチャー・モデル・コンポーネント４１４は、プロトタイプ特徴のライブラリに関するデータを提供するプロトタイプ平均モジュール４１６を含む。プロトタイプ平均モジュール４１６によって提供されるデータは、プロトタイプ動き特徴（オラクル・データ）に対応するデータと、ユーザー動き特徴を表す幅広い範囲のサンプル・データとを使ってトレーニングされたものである。さらに、プロトタイプ平均モジュール４１６によって与えられるデータは、実際のプレーヤー・ジェスチャー（ユーザー・データ動き特徴として表される）を特定のダンス動きまたはステップに対応するものとして分類するために使用されうる「平均」プレーヤー・データを組み込んでいる。
【００６４】
トレーニング動作では、振り付けされた各ジェスチャーのモデルが、トレーニング集合FT＝{fj,  j＝1…L}に依拠して構築されてもよい。トレーニング集合は、このジェスチャーを踊る被験者のL個の記録の集まりを含む。さまざまな技量の被験者が記録に参加することがあり、各人は典型的にはジェスチャー毎に若干数の記録を生成する。
【００６５】
トレーニング動作において発展させられるモデルは、プロのダンサーによって実行されるジェスチャーの記録を含んでいてもよい、オラクルfoを表すプロトタイプ動き特徴をも用いてもよい。この記録は、ジェスチャーの定義と考えられる。単一のまたは少数の記録が、各オラクル表現について考慮されてもよい。これは主として、プロのダンサーは通例、特定のジェスチャーを非常に正確に反復するので、記録における変動の大半はセンサー・ノイズに由来するからである。
【００６６】
プロトタイプ平均と記される、各個々の特徴についてダンサーの期待される平均軌跡を生成するために、トレーニング・データは、foと各個々のfjとの間の巡回規格化相互相関を計算することによって、プロトタイプ動き特徴（すなわちオラクル）に関して整列させられる。規格化巡回相互相関動作は、波形間の時間オフセットを与えられたときに二つの波形の類似性を同定するために使われる数学的操作である。相互相関は、（波形などの）データのより大きなセット内でより短い既知のパターンを同定するために使用されうる技法である。
【００６７】
ある例示的な実施形態では、二つのベクトルuおよびvの巡回規格化相互相関cは次のように計算される。
【００６８】
【数１】
0005902204.tif 000002
ここで、￣付きのuはuの平均を表す。二つのベクトルuおよびvの規格化されない巡回
相互相関は
【００６９】
【数２】
0005902204.tif 000003
として計算される。ここで、R(  )は時系列ベクトルを反射することを表し、Fは離散フーリエ変換を表す。規格化されない巡回相互相関は各特徴について計算される。身体全体の同期を取り入れるために、相互相関ベクトルは、すべての特徴について加算されて単一のベクトルにされる。
【００７０】
【数３】
0005902204.tif 000004
二つのベクトルの位相オフセットは次式に等しい。
【００７１】
【数４】
0005902204.tif 000005
このように、fj記録をfoと整列させるために、fjにおいてすべての特徴は−τjサンプルだけ位相シフトされる。
【００７２】
プロトタイプ平均は、ある特定の特徴について次のように定義されてもよい。
【００７３】
【数５】
0005902204.tif 000006
ジェスチャー・プロトタイプは
【００７４】
【数６】
0005902204.tif 000007
と表されてもよい。fmとfoの関係は、fmはジェスチャーを踊る平均被験者の動きを表し、一方foは熟達者のそれであるという点である。典型的には、両者は形は似ているが、プロトタイプ平均はしばしば振幅が減衰している。というのも、技量のあるダンサーは通例、全体的なアピールのために動きを強調するからである。
【００７５】
次に、クラス内およびクラス外相関統計を捕捉するモデルがまとめられてもよい。FT内の各記録jおよび特徴iについて、
【００７６】
【数７】
0005902204.tif 000008
として
【００７７】
【数８】
0005902204.tif 000009
が計算されてもよい。各特徴iについて、
【００７８】
【数９】
0005902204.tif 000010
にわたる相関値のヒストグラムがまとめられてもよい。Lは典型的には小さいので、ガウス・カーネルを使ってヒストグラムを平滑化する単純なカーネル密度推定（KDE:  kernel  density  estimation）フィルタが適用されてもよい。特定の特徴iについてのヒストグラム曲線はルックアップ・テーブルpi(c)に格納されてもよい。ここで、−1≦c≦1は相関引数である。特定の特徴について、ルックアップ・テーブルはこのように、プロトタイプ平均と入力（すなわち入力データ動き特徴）との相関が与えられたときに入力ジェスチャーがこの特定のクラスに属する確からしさを返す。同様に、クラス外相関に対して収集されうる統計および対応するルックアップ・テーブルqi(c)が生成されてもよい。これら二つのテーブルは、特定の相関値についてスコア付け関数を生成するために組み合わされてもよい。スコア付け関数の一例は、hi(c)＝2log(pi(c))−log(qi(c))と表される。技量のあるダンサー、すなわちプロトタイプ平均に対する高い相関を出すダンサーは典型的にはFTにおいてまれであるという事実は、高いcについて低いpi(c)という結果を与えうる。その場合、それらのスコアは本質的には、そのダンスが「うますぎる」ためにペナルティを与えられるのである。この異常を正すため、KDEフィルタを適用するのに先立って、高い相関についてのヒストグラム係数が調整されてもよい。
【００７９】
検出技法としての規格化された相互相関は、形のマッチングでは効果的だが、その振幅のマッチングではそれほど効果的ではない。規格化なしでユークリッド距離または相関を使うのではなく、ある例示的な実施形態は、平均信号エネルギーという追加的な距離計量を、規格化された相関に対する補完として用いてもよい。よって、クラス内ジェスチャー・インスタンスの各特徴fiについて、プロトタイプ動き特徴に対するエネルギー・レベルがαi＝‖fo,i‖−‖fi‖として計算されてもよく、FT内のすべてのインスタンスのエネルギー・レベルにわたる−4π2≦α≦4π2についてのヒストグラムei+(α)が構築されてもよい。KDEフィルタが適用されてもよい。相関ヒストグラムhi(c)と同様に、クラス外インスタンスについての同じ統計ei-(α)が計算されてもよい。それらはei(α)＝2log(ei+(α))−log(ei-(α))として組み合わされてもよい。最後に、ei(α)は、用いられるベンチマークにおいて普通ではない、技量のあるダンサーがより幅広い範囲の動きをもつことがあり、よってその記録の増大したエネルギーをもつことがあるという事実について補償されてもよい。この調整は、低いαの場合についてei+(α)のヒストグラム計数を増すことによって実行されてもよい。よって、特定のジェスチャーおよび特徴iについて、本願の技術は、プロトタイプ平均fm,i、相関ヒストグラムhi(c)およびエネルギー・レベル・ヒストグラムei(α)を含む三つ組{fm,i,hi,ei}を包含する。
【００８０】
ジェスチャー・モデル・コンポーネント４１４は相関統計モジュール４１８およびエネルギー統計モジュール４２０をも含む。本稿で述べるように、相関統計およびエネルギー統計は、ジェスチャー分類システム４００によって、ユーザーのダンス動きを分類するとともに、該ダンス動きの品質を表すスコアを割り当てるために使われてもよい。
【００８１】
ロジスティック回帰係数モジュール４２２がジェスチャー・モデル・コンポーネント４１４内に含まれていてもよい。本稿で説明するように、ロジスティック回帰は、共通の特徴をもつプロトタイプ動き間で選択を行うためにダンス動きを分類するときに使われてもよい。さらに、ロジスティック回帰データは、比較的互いに近いプロトタイプ動き特徴間で選択を行うよう、本願の技術に基づく分類プロセスを微調整するために使われてもよい。
【００８２】
ジェスチャー・モデル・コンポーネント４１４はクラス・ランク付けコンポーネント４２６を含んでいてもよい。クラス・ランク付けコンポーネントは、ユーザー入力動き特徴を表す所与のデータについて、マッチするプロトタイプ動き特徴を選択するプロセスにおいて使用されてもよい。特に、クラス・ランク付けコンポーネント４２６は、所与のユーザー入力データが各プロトタイプ動き特徴についてのマッチである確率に基づいて、プロトタイプ動き特徴データベース内でスコア付けされたプロトタイプ動き特徴をランク付けするために使われてもよい。さらに、所与のユーザー入力データによりよく似ているプロトタイプ動き特徴は、クラス・ランク付けコンポーネント４２６によってより高いマッチ確率を割り当てられてもよい。この機能を実行するために、クラス・ランク付けコンポーネント４２６は、規格化された相関モジュール４２８およびスコア計算モジュール４３０を有していてもよい。
【００８３】
クラス・ランク付けコンポーネント４２６は、特徴表現モジュール４３２を介してプレーヤー・パフォーマンス・コンポーネント４０２からデータを受け取る。特徴表現モジュール４３２は、ユーザー・データの動き特徴全体の部分集合を表す個別的な特徴に関係するデータを提供してもよい。
【００８４】
本稿で説明するように、ジェスチャー認識システムのある例示的な実施形態は、ひとたびトレーニングされたら、たとえばビデオ・ゲームのコンテキストにおけるユーザー動きのリアルタイムの分類を実行するために用いられてもよい。そのような場合、分類器への入力は、特徴集合に変換された骨格ワイヤフレームのストリームである。ベクトルx＝{xi,  i＝1…19}が、それぞれNサンプルの長さの19個の特徴の入力ストリームを表すとする。関連するプロトタイプ動き特徴データベース内の各ジェスチャー・モデルg＝{{fm,i,hi,ei},  i＝1…19}について、そのスコアは以下の方法論を使って計算されてもよい。
【００８５】
まず、規格化された相互相関動作が実行される。この動作において、各入力特徴xiはその対応するプロトタイプ平均fm,iとの相互相関を取られる。これは、ジェスチャー認識分類器の、比較的計算量的に要求の高い動作である。長さNの二進高速フーリエ変換（FFT）はO(NlogN)回の動作で計算されるからである。次に、最大尤度スコアが決定される。ある例示的な実施形態では、対応するヒストグラム・スコアが検索され、すべての特徴にわたって合計されてもよい。次の公式が、該合計を実行するために使われてもよい。
【００８６】
【数１０】
0005902204.tif 000011
最大尤度スコアが決定されたのち、位相オフセット動作が実行されてもよい。入力の、プロトタイプ平均に対する位相シフトτは次のように同定されてもよい。
【００８７】
【数１１】
0005902204.tif 000012
位相シフトは、各クラスについて異なっている。
【００８８】
データベース中の各ジェスチャー・クラスkについての分類スコアはsk(τk)である。これらのスコアはすべてのクラスをランク付けするために使われてもよい。最良のマッチは最高のスコアをもつものである。
【００８９】
ペア毎マッチング・コンポーネント４３４がジェスチャー分類コンポーネント４０４に含まれていてもよい。図４に示される例示的な実施形態では、ペア毎マッチング・コンポーネント４３４は、正規化された相関モジュール４２８、スコア計算モジュール４３０およびロジスティック回帰係数モジュール４２２から入力を集める。この情報に基づいて、ペア毎マッチング・コンポーネント４３４は、プロトタイプ動き特徴データベースからの、プレーヤー・パフォーマンス・コンポーネント４０２から受領されたユーザー入力データに最もよくマッチするプロトタイプ動き特徴を同定する出力を与える。ユーザー入力データに最もよくマッチするプロトタイプ動き特徴は、図４におけるキャプション「一致したクラス」で同定されている。
【００９０】
いくつかのクラスがしばしば動きにおいて、全特徴にわたるそれらのプロトタイプ平均が一つを除いて等価であるまでに似ていることがあることから、ランク付け分類器を改善することができる。二つのジェスチャー・クラスのすべてのインスタンスは、大きな2(19+19)次元空間のある近傍における点の集合と見ることができる。取得ノイズおよび人間があるジェスチャーを演じることのできる多様な仕方のため、プロトタイプ平均がほぼ同一である（ごくわずかな特徴を除くすべての特徴にわたって同じ）二つのクラスは、たとえば特定のクラスのすべての点を含み検出するために多次元球が使われる場合、交わる体積をもつことがある。二つのクラスの曖昧さのない区別はより微妙な違いがあり、特徴には選択的に依存するので、高度な、ペア毎マッチング・ツールを使って隣り合うクラスをよりよく区別する必要がある。
【００９１】
式(3)における尤度に重みをかけることが、分類の機敏さ（agility）を改善する方法の一例である。この「任意的な」重みは、再計算される必要があることがあり、ジェスチャー・マッチのペア毎の比較それぞれについて相異なっている可能性が高い。よって、本稿で述べるように、ロジスティック回帰を使ってこれらの重みを計算し、トレーニングされた係数を分類において展開することが望ましいことがある。
【００９２】
例として、ロジスティック回帰は最高のs(τ)スコアをもつ二つのトップ階層のクラス、たとえばk1およびk2のインデックスで指定されるクラスについて実行されてもよい。二項分類が、次式を計算することによって実行されてもよい。
【００９３】
【数１２】
0005902204.tif 000013
ここで、すべての重みはロジスティック回帰を使ってトレーニングされている。Pr(C＝k1|x)≧0.5である場合にはクラスk1が、それ以外の場合にはk2が最良のマッチと表される。「勝者クラス」を次の「次点クラス」とペア毎マッチングするプロセスは、再帰的に反復されてもよい。ただし、s(τ)リストで深いところにあるクラスが「勝つ」可能性は急速に低下する。よって、ある例示的な実施形態は、ロジスティック回帰を介した、ペア毎クラス比較の3層の深さのシーケンスを用いてもよい。
【００９４】
したがって、ジェスチャー・モデル{fm,i,hi,ei}はもう一つのデータ・フィールド、ロジスティック回帰のための係数行列
【００９５】
【数１３】
0005902204.tif 000014
を用いて増強されてもよい。ここで、Kはジェスチャー・クラスの数である。分類のために要求される資産のサイズはO(K2)に比例するので、大きなKについては、分類データベースのサイズは禁止的なほどに増大する。たいていのジェスチャー・クラスについて、それらの間の相違は、式(3)におけるスコア付け関数がそれらの間を曖昧さなく区別するために十分大きいことを注意しておく。トレーニングにおいては、「同様な」ジェスチャーが同定され、重み付け行列はそれらのまばらな対についてのみトレーニングされてもよい。完全なK×K行列における対の密度は、ジェスチャー動きクラスの類似性に依存する。
【００９６】
本願の技術に基づくジェスチャー認識システムの分類器は、いくつかの興味深い性質を呈することがある。たとえば、入力バッファの長さは必ずしもクラス・プロトタイプの長さに等しくない。よって、より短い入力シーケンスが同じアルゴリズムを使ってマッチングされることができる。相互相関の規格化パラメータのみが適応される必要がある。
【００９７】
本願の技術に基づくジェスチャー認識アルゴリズムは、マッチしたクラスのプロトタイプに関する位相シフトを副作用として返すことがある。この情報は、ユーザーのダンス・パターンをゲーム・プラットフォームと同期させるために有用であることがある。
【００９８】
例示的なジェスチャー分類システムによって報告される誤差は、短い入力バッファについては特に、無害であることがある。そのような分類器の一つの特性は、ジェスチャー・データベース全体内での最良一致したクラスを、そのプロトタイプ平均内での位相シフトとともに返しうるということである。したがって、アバターがプレーヤーの動きをレンダリングするシナリオでは、誤差は、短期間の（short-spanned）クラス横断類似性のため、気づかれずに過ぎることがある。
【００９９】
ユーザー入力データは距離メトリック・モジュール４２４に与えられる。距離メトリック・モジュール４２４は、ジェスチャー・モデル・コンポーネント４１４からの入力およびペア毎マッチング・モジュール４３４からの一致したクラスに関係する情報をも受け取ってもよい。距離メトリック・モジュール４２４は、ユーザーによって実行されたダンス動きの指標品質（または「良さ」）を表す出力として、距離レポートを与えてもよい。
【０１００】
ひとたび最良一致した動きクラスが同定されたら、残る問題は、一致したプロトタイプ動き特徴に対する、（ユーザー・データ動き特徴によって表される）ユーザーの動きの品質に関するものである。プロトタイプ平均に対する比較（プロトタイプ平均との相関付けによって得られるスコアを含む）は、熟達者ダンサーではなく平均に対して、プレーヤーがどのくらいうまく実行したかを示すものなので、ミスリーディングであることがある。他方、単一のスコア付け数をもつことに加えて、ゲーム・プレーヤーがどのくらい「うまく」踊ったかを関節毎に示すレポートを提供することが望ましいことがありうる。この問題を解決するため、芸術的なアピールについてラベル付けされた動き記録を得て、人間の専門家を再現するこのデータ・セットに対する回帰モデルを学習することが望まれることがある。それでも、人間によるラベル付けがどのくらい一貫したものであるかは議論があるかもしれない。体の動きの等級付けの意味的性質を回避するため、現在の演者と熟達者の相対的な動きの間の食い違いが測定されてもよい。
【０１０１】
本願の技術によれば、プレーヤーの特徴シーケンスは、前記分類方法によって与えられる位相シフトを使ってグローバルに整列されてもよい。その後、考えられる局所的な整列不良を考慮して二つの信号の食い違いを測定するために、動的な時間歪めが使われてもよい。ノイズに起因する突出値を克服するため、動的な時間歪めの計算において、次のように定義される堅牢なコストを用いることが望ましいことがある。
【０１０２】
【数１４】
0005902204.tif 000015
ここで、σは許容される熟達者のパフォーマンスからの逸脱の量を制御するパラメータであり、δは突出値の効果を最小化する閾値である。
【０１０３】
このメトリックは、σおよびδをきつくしたり緩和したりすることによって空間および時間に沿った種々の動き精度標準に調整するようパラメータ化されてもよい。これは、すべてのオラクルに対して計算されるとき、比較的効果的な検出器であることが観察されている。それでも、その計算上の複雑さは、クラス毎の適用の活用を許容するには大きすぎるかもしれない。
【０１０４】
ジェスチャー分類コンポーネント４０４によって、ジェスチャー分類インターフェース４３６を介して情報が提供されてもよい。この情報は、ユーザーによって実行されるダンス動きまたはステップの同定（図４のキャプション「どのジェスチャー？」によって表される）および該ダンス動きまたはステップの品質の評価（図４のキャプション「どのくらいうまく？」によって表される）に関係していてもよい。さらに、ジェスチャー分類インターフェース４３６は、ジェスチャー分類コンポーネント４０４からの情報を、ビデオ・ゲーム・マルチメディア・コンソール（図１２参照）またはジェスチャー分類システム４００をホストするコンピュータ・システム（図１３参照）に転送するために使用されてもよい。
【０１０５】
図５は、本願の技術に基づく動き認識の例示的な方法５００を示すプロセス流れ図である。方法５００は、ターゲット認識、解析および追跡システム１００のためのコンピューティング環境１２の、捕捉装置１１０のプロセッサ１３４、CPU  １２０２（図１２）または処理ユニット１３７６（図１３）のような一つまたは複数のプロセッサ上で実行されるソフトウェアによって実行されてもよい。
【０１０６】
ブロック５０２では、固定したカメラ・ベースの3D座標基準系に関して三次元空間内での人体を表す骨格モデル・データの諸フレームが捕捉装置１１０から受領される。任意的に、骨格動きデータの諸セットにおける骨のサイズが規格化されてもよい。特に、異なるユーザーは異なるサイズであってもよく、四肢や胴体が異なるサイズであってもよい。
【０１０７】
本願の技術によれば、図２に示される各骨格点は、ユーザーがダンス動きを実行するにつれてユーザー・データを受け取る独自の入力バッファを有していてもよい。図２に示される各骨格点について同時に得られたユーザー・データの単一のフレームまたはインスタンスが、本稿では、ユーザー・データ動き特徴と称されることがある。得られたユーザー・データ動き特徴に基づいて、熟達者によって実行されるダンス動きのような多様なジェスチャーに対応するプロトタイプ動き特徴データの組を記憶しているジェスチャー・データベースを参照して、ユーザーのパフォーマンスを評価してもよい。データベースは、プロトタイプ動き特徴データベースと称されてもよい。
【０１０８】
ブロック５０４に示されるように、各ユーザー・データ動き特徴について、プロトタイプ動き特徴データベース内のプロトタイプ動き特徴の前記組に対して、相互相関動作が実行されてもよい。相互相関動作の実行において、諸特徴または図２に示される骨格データ点のそれぞれを使って、相互相関ベクトルが形成されてもよい。巡回相互相関動作が、ユーザーがゲームをプレイする際に収集されるユーザー・データの位相を、ゲーム内のデータベースに記憶されているプロトタイプ・データと整列させるはたらきをしてもよい。たとえば、ユーザー・データのフレームは、入力データおよび熟達者プロトタイプ・データを使ってトレーニングを実行することによって得られる平均データと相互相関を取られてもよい。巡回相互相関動作はFFTを使って実行されてもよい。
【０１０９】
ある実施形態では、巡回相互相関は、規格化された巡回相互相関動作を含んでいてもよい。規格化された巡回相互相関は、ユーザー・データおよびプロトタイプ・データに関して背景ノイズが異なることがありうるといった因子を考慮に入れる。さらに、相互相関は、規格化された巡回相互相関であってもよい。相互相関動作は、動き認識モデルが、プロトタイプ動き特徴データベース内の、所与のユーザー・データ動き特徴に対応する特定のプロトタイプ動き特徴を同定する能力を高めうる。
【０１１０】
図２に示される各骨格点についての入力バッファからのデータが、プロトタイプ動き特徴データベース内の各プロトタイプ動き特徴について個々に評価されてもよい。さらに、プロトタイプ動き特徴のそれぞれについて、個々に、入力バッファ・データの整列のための最も近い（closest）オフセットが見出されてもよい。
【０１１１】
図５に示される例示的な実施形態のブロック５０６では、前記一組のプロトタイプ動き特徴のそれぞれが入力骨格動きデータについてのマッチである確率または確からしさが、相互相関に基づいて決定される。入力骨格動きデータに最もよく似ている諸プロトタイプ動き特徴が、高めのマッチング可能性をもつものと判定される。このように決定された確率または確からしさは、どれが入力骨格動きデータにマッチする可能性が最も高いかに基づいて前記一組のプロトタイプ動き特徴をランク付けするために使われる。ある例示的な実施形態では、ブロック５０６は、プロトタイプ動き特徴データベースから最良のマッチを選択する縦続式のプロセスにおける第一段階を表す。
【０１１２】
前記確率は、所与のユーザー・データ動き特徴がプロトタイプ動き特徴データベース内の各プロトタイプ動き特徴に実際に対応する、対数スケールでの確率を表す対数確率を含んでいてもよい。純粋な確率の代わりに対数確率を使うには二つの理由がある。ｉ）確率の[0,1]区間を[−∞,0]にスケーリングし直すことで、分類のためにより適正になる、そしてｉｉ）諸特徴が素朴なベイジアン・ネットワークをなすと想定して、個々の各特徴の影響を分離する。
【０１１３】
対数確率は、各動きクラスについて別個に合計され、報告されてもよい。本稿で説明するように、動きクラスは、プロトタイプ動き特徴データベース内の各サンプルによって表される。動きクラスは、結果として得られるスコアに基づいてソートされてもよい。
【０１１４】
ブロック５０８では、プロトタイプ動き特徴のランク付けを使って分類動作が実行される。この分類動作は、最良のマッチを選択する縦続式のプロセスにおける第二段階と考えてもよい。ある例示的な実施形態では、分類動作は、入力骨格動きデータにマッチする可能性が最も高い二つの（可能性としては三つの）プロトタイプ動き特徴に対して実行されてもよい。分類プロセスを実行するには数多くの技法が利用できる。たとえば、ジェスチャー・クラスの諸ペアの間で分離するために、ロジスティック回帰が適用されてもよい。特に、ロジスティック回帰は、いくつかの点で同様であるがより微妙な点で異なっている候補プロトタイプ動き特徴の間で区別をするために使用されてもよい。ロジスティック回帰に加えて、候補プロトタイプ動き特徴の間の区別をするために、入力データに基づく他の型の二項分類が適用されてもよい。代替的な二項分類戦略の例は、中でも線形判別解析およびSVM解析を含む。
【０１１５】
ユーザーによって実行されるジェスチャーは、この解析において最高のスコアをもつプロトタイプ動き特徴とのマッチであると考えられてもよい。さらに、検出されたジェスチャー（すなわち、プロトタイプ動き特徴のいずれかにマッチする最高の可能性をもつと同定されたジェスチャー）は、プロトタイプ動き特徴によって表される特定のダンス・ステップまたはその一部に対応してもよい。
【０１１６】
所与のユーザー・データ動き特徴に最もよく似ているプロトタイプ動き特徴が選択されたのち、ユーザーによって実行されている対応するダンス・スタイルが同定されてもよい。たとえば、検出されたユーザー・データは、プロトタイプ動き特徴データベースにおいて、ワルツ、ルンバまたはフォックストロットなど特定のダンス・スタイルからものもとしてタグ付けされていてもよい。検出されたダンス・スタイルは、ゲーム・コンテキストの一部としてユーザーに対して呈示されてもよい。
【０１１７】
本稿で説明するように、ユーザー・データは、たとえばダンス動きのようなジェスチャーを認識するジェスチャー認識エンジンにおいて実装されている動き認識モデルをトレーニングするために使われてもよい。トレーニング・フェーズでは、比較的多数のユーザーからのユーザー・データが、プロトタイプとの関連で使用されてもよい。それにより、該モデルは、ユーザー・データがそのプロトタイプに等しい動きを表すときに正確に同定する基礎を与えられる。該モデルをトレーニングする目的は、該モデルを、試験中のユーザー入力データと記憶されている「理想的な」またはプロトタイプ・データとの間の相関を認識することにおいてより効果的にすることである。典型的または平均的なプレーヤーについての平均データ・プロファイルが発展されてもよく、そのデータ・プロファイルがその後、効果的な仕方でプレーヤーのダンス動きを分類するために使用されてもよい。所与のユーザー入力がプロトタイプ・データベース内のプロトタイプ動きクラスに対応する可能性を決定するために統計モデルが発展されてもよい。トレーニング・フェーズ後、モデルは、ダンス動きまたはステップのような動き型を認識することにおけるその成功を判定するために試験されてもよい。図６は、モデルのトレーニング・フェーズを表している。
【０１１８】
図６は、本願の技術に基づくダンス・ステップ認識を実行するための動き認識モデルのトレーニングを示すブロック図６００である。ブロック図６００の左のパネル６００ａでは、単一クラスの動きがトレーニングの目的のために評価されている。ブロック図６００の右のパネル６００ｂでは、複数のクラス動きが評価されている。
【０１１９】
クラス動きを表すデータは、動き特徴データに基づいてさまざまなダンス・ステップまたは動きを認識するためのモデルをトレーニングするために使われる。該データは、図２に示される各点について得られたデータのフレームを含んでいてもよい。左のパネル６００ａでは、例示的なクラス動き６０２が示されている。特定のダンス動きまたはステップを表すこのクラス動きは、プロトタイプ動き特徴のデータベースから得られる特徴データ６０４を含んでいてもよい。プロトタイプ６０６は、プロトタイプ動き特徴データの例として示されている。該プロトタイプ動き特徴についてのデータは、上記ダンス動きまたはステップの熟達者による実演から捕捉されてもよい。
【０１２０】
特徴の分布６０８が、図６に示されるようなクラス動きを実行するデータのいくつかのインスタンスを使って当該システムをトレーニングすることによって得られる。確からしさスコア６１０が特徴の各分布６０８について決定されてもよい。確からしさスコアは、その特徴が所与のプロトタイプについてのマッチである可能性を表す。
【０１２１】
右のパネル６００ｂでは、ジェスチャーを認識するモデルをトレーニングするために、複数のクラス動き６１２が使われる。複数のクラス動き６１２が評価される。各クラス動き６１２は、プロトタイプ動き特徴が利用可能な異なるダンス動きまたはステップに対応してもよい。各クラス動きについて、別個の確からしさスコア６１４が生成される。本願の技術によれば、確からしさスコア６１４は、左のパネル６００ａに示されるように決定されてもよい。それらの確からしさスコア６１４に対して二項（binary）ロジック回帰６１６が実行されて、ロジスティック回帰係数６１８を生成してもよい。本稿で説明するように、ロジスティック回帰は、二つのプロトタイプ動き特徴の比較的近いマッチのうちから選択を行うために実行されてもよい。
【０１２２】
モデルがトレーニングされたのち、確率の形の相関データが、各プロトタイプ動き特徴について、たとえばルックアップ・テーブル中に記憶されてもよい。記憶された相関データは、動き認識試験および実際の検出の際に使用されうる。ルックアップ・テーブル・データは、所与のプロトタイプ動き特徴について骨格データの各点についての相関データを含んでいてもよい。加えて、のちの使用のために、ルックアップ・テーブルには相対的なエネルギー・データも記憶されてもよい。
【０１２３】
図７は、本願の技術に基づく、複数クラス動きについてのトレーニング・フェーズを示すブロック図７００である。上のパネル７０２はクラス動きiについてのモデルのトレーニングを示しており、下のパネル７０４はクラス動きjについての前記モデルのトレーニングを示している。
【０１２４】
上のパネル７０２においてクラス動きiについてのモデルをトレーニングする際、複数のトレーニング・サンプル７０６が受領される。規格化された巡回相互相関（normalized,  circular  cross-correlation）動作（図７では略語NCXCで表されている）がトレーニング・サンプル７０６と、たとえばプロトタイプ動き特徴データベースに記憶されている複数のプロトタイプ動き特徴７０８との間で実行される。上のパネル７０２に表される例では、規格化された巡回相互相関動作は、二つのプロトタイプ動き特徴７０８を使って実行される。後述するように、本願の技術は、プロトタイプ動き特徴７０８のどちらがトレーニング・サンプル７０６に最もよく似ているかを同定するために用いられてもよい。ある実施形態では、ダンス・ステップを同定し、スコア付けすることにおいて支援するために、相対的なエネルギーが使用されてもよい。ユーザー・データおよびプロトタイプ・データについて、所与の時間期間にわたる平均エネルギーが決定されてもよい。
【０１２５】
トレーニング・サンプル７０６ａ、７０６ｂ、７０６ｃとプロトタイプ動き特徴i  ７０８ａとの間の規格化された巡回相互相関動作の結果は、複数の相関および相対エネルギー・データ・セット７１０ａ、７１０ｂ、７１０ｃであり、そのそれぞれがトレーニング・サンプル７０６ａ、７０６ｂ、７０６ｃの一つに対応する。相関および相対エネルギー・データ・セット７１０ａ、７１０ｂ、７１０ｃについての特徴の分布がグラフ７１２ａによって表される。
【０１２６】
トレーニング・サンプル７０６ａ、７０６ｂ、７０６ｃとプロトタイプ動き特徴j  ７０８ｂとの間の規格化された巡回相互相関動作の結果は、複数の相関および相対エネルギー・データ７１０ｄ、７１０ｅ、７１０ｆであり、そのそれぞれがトレーニング・サンプル７０６ａ、７０６ｂ、７０６ｃの一つに対応する。相関および相対エネルギー・データ・セット７１０ｄ、７１０ｅ、７１０ｆについての特徴の分布がグラフ７１２ｂによって表される。
【０１２７】
相関および相対エネルギー・データ・セット７１０ａ、７１０ｂ、７１０ｃは、対応するトレーニング・サンプル７０６ａ、７０６ｂ、７０６ｃのどれがプロトタイプ動き特徴i  ７０８ａに最も近く相関しているかを判定するために評価されてもよい。相関の最大確率が、ユーザー・データとプロトタイプ・データとの間の相対エネルギーとともに、判別されてもよい。最大確率についての時間オフセットも判別されてもよい。これは、ユーザーのパフォーマンスのさらなる動き解析のために有用であることがある。相関および相対エネルギー・データ・セット７１０ａ、７１０ｂ、７１０ｃについての最大確率は、最大指示７１４ａ、７１４ｂ、７１４ｃとして表される。最大指示７１４ａ、７１４ｂ、７１４ｃは、対応する確からしさスコア７１６ａ、７１６ｂ、７１６ｃを決定するために使用されてもよい。確からしさスコアは、ユーザー・データが、プロトタイプ動き特徴データベースに記憶されているあるプロトタイプ動き特徴を実行することを意図している確率を表す。
【０１２８】
相関および相対エネルギー・データ・セット７１０ｄ、７１０ｅ、７１０ｆは、対応するトレーニング・サンプル７０６ａ、７０６ｂ、７０６ｃのどれがプロトタイプ動き特徴j  ７０８ｂに最も近く相関しているかを判定するために評価されてもよい。相関の最大確率が、ユーザー・データとプロトタイプ・データとの間の相対エネルギーとともに、判別されてもよい。相関および相対エネルギー・データ・セット７１０ｄ、７１０ｅ、７１０ｆについての最大確率は、最大指示７１４ｄ、７１４ｅ、７１４ｆとして表される。最大指示７１４ｄ、７１４ｅ、７１４ｆは、対応する確からしさスコア７１６ｄ、７１６ｅ、７１６ｆを決定するために使用されてもよい。
【０１２９】
下のパネル７０４においてクラス動きjについてモデルをトレーニングする際、複数のトレーニング・サンプル７１８が受領される。トレーニング・サンプル７１８とたとえばプロトタイプ動き特徴データベースに記憶されている複数のプロトタイプ動き特徴７２０との間で、規格化された巡回相互相関動作が実行される。下のパネル７０４に表されている例では、規格化された巡回相互相関動作は、二つのプロトタイプ動き特徴７２０を使って実行される。後述するように、本願の技術は、プロトタイプ動き特徴７２０のいずれがトレーニング・サンプル７１８に最もよく似ているかを同定するために用いられてもよい。
【０１３０】
トレーニング・サンプル７１８ａ、７１８ｂ、７１８ｃとプロトタイプ動き特徴j  ７２０ａとの間の規格化された巡回相互相関動作の結果は、複数の相関および相対エネルギー・データ・セット７２２ａ、７２２ｂ、７２２ｃであり、そのそれぞれはトレーニング・サンプル７１８ａ、７１８ｂ、７１８ｃのうちの一つに対応する。相関および相対エネルギー・データ・セット７２２ａ、７２２ｂ、７２２ｃについての特徴の分布はグラフ７２４ａによって表される。
【０１３１】
トレーニング・サンプル７１８ａ、７１８ｂ、７１８ｃとプロトタイプ動き特徴i  ７２０ｂとの間の規格化された巡回相互相関動作の結果は、複数の相関および相対エネルギー・データ・セット７２２ｄ、７２２ｅ、７２２ｆであり、そのそれぞれはトレーニング・サンプル７１８ａ、７１８ｂ、７１８ｃのうちの一つに対応する。相関および相対エネルギー・データ・セット７２２ｄ、７２２ｅ、７２２ｆについての特徴の分布はグラフ７２４ｂによって表される。
【０１３２】
相関および相対エネルギー・データ・セット７２２ａ、７２２ｂ、７２２ｃは、対応するトレーニング・サンプル７１８ａ、７１８ｂ、７１８ｃのどれがプロトタイプ動き特徴j  ７２０ａに最も近く相関しているかを判定するために評価されてもよい。図７では、相関および相対エネルギー・データ・セット７２２ａ、７２２ｂ、７２２ｃの最大確率は、最大指示７２６ａ、７２６ｂ、７２６ｃとして表されている。最大指示７２６ａ、７２６ｂ、７２６ｃは、対応する確からしさスコア７２８ａ、７２８ｂ、７２８ｃを決定するために使用されてもよい。
【０１３３】
相関および相対エネルギー・データ・セット７２２ｄ、７２２ｅ、７２２ｆは、対応するトレーニング・サンプル７１８ａ、７１８ｂ、７１８ｃのどれがプロトタイプ動き特徴i  ７２０ｂに最も近く相関しているかを判定するために評価されてもよい。相関および相対エネルギー・データ・セット７２２ｄ、７２２ｅ、７２２ｆの最大確率は、最大指示７２６ｄ、７２６ｅ、７２６ｆとして表されている。最大指示７２６ｄ、７２６ｅ、７２６ｆは、対応する確からしさスコア７２８ｄ、７２８ｅ、７２８ｆを決定するために使用されてもよい。
【０１３４】
確からしさスコア７１６ａ〜ｆ、７２８ａ〜ｆを使って、二項ロジスティック回帰動作７３０が実行されてもよい。二項ロジスティック回帰動作７３０は、ロジスティック回帰係数７３２を与えてもよく、それは同様の確からしさスコアをもつプロトタイプ動き特徴の間でマッチを選択するために使われてもよい。
【０１３５】
図８は、動き認識を実行する前にユーザー・データを記憶されているプロトタイプ・データと整列させるために使われてもよい位相シフト・プロセスを示すブロック図８００である。クラス動きのトレーニング・サンプル８０２はトレーニング・フェーズの一環として与えられる。規格化された巡回相互相関（図８では略語NCXCで表される）を含んでいてもよい相互相関動作８０４が実行される。規格化された巡回相互相関動作８０４は、熟達者データを含んでいてもよいプロトタイプ・サンプル８０６を用いる。主としてトレーニング・サンプル８０２とプロトタイプ・サンプル８０６との間の位相シフトに対処するために、整列動作８０８が実行される。整列動作８０８の結果は、トレーニング・サンプル８０２によって表されるクラス動きのトレーニングされたプロトタイプ８１０である。
【０１３６】
図９は、本願の技術に基づく、モデルがダンス・ステップを認識する能力の試験を示している。ジェスチャー認識モデルのトレーニング後、該モデルは実際の入力データを分類するために使用されてもよい。モデルを試験するときには、モデルが正しい結果を生成するかどうかを検証するために、既知の入力データが使用されてもよい。
【０１３７】
最初、サンプル動き９０２がモデルに与えられる。サンプル動き９０２は、捕捉装置１１０から得られたユーザー・データ動き特徴を含んでいてもよい。サンプル動き９０２は図９では複数のプロトタイプ９０４として表されている。これらは対応する特徴９０６を有する。特徴の分布９０８が、各特徴９０６について与えられる。確からしさスコア９１０は、特徴の分布９０８のそれぞれについて与えられる。ブロック９１２で示されるように、プロトタイプ動き特徴に関して最大確率が計算される。本稿で説明するように、最大確率は、確からしさスコア９１０に基づいて決定されてもよい。
【０１３８】
図９に示される例示的な実施形態では、「勝ち残る」（すなわちもっともよく相関している）ダンス・ステップまたは動きが選択される前に、最高の確率をもつ諸プロトタイプを含む部分集合がさらに評価されてもよい。プロトタイプの部分集合９１４は、プロトタイプ動き特徴データベースにおいてサンプル動き９０２を最もよく表すサンプル・クラス９１８を選ぶために、ロジスティック回帰９１６にかけられてもよい。
【０１３９】
図１０は、本願の技術に基づく、動きのサブシーケンスを分類するためのモデルの使用を示すブロック図１０００である。本願の技術によれば、あるクラスの計算されたプロトタイプの一部とのサブシーケンス・マッチを認識するために、動き認識モデルが使用されてもよい。
【０１４０】
複数のトレーニング・サンプル部分１００２が受領される。図１０に示されるように、トレーニング・サンプル部分１００２は動きクラスiの一部を表す。複数のトレーニング・サンプル部分１００４も受領される。トレーニング・サンプル部分１００４は否定クラスを表す：動きクラスi以外の動きクラスを実行するデータである。トレーニング・サンプル部分１００２、１００４を使って、プロトタイプ動きクラスi  １００６に対して相互相関動作が実行される。相互相関動作は、トレーニング・サンプル部分１００２ａ、１００２ｂ、１００２ｃに対応する複数の相関および相対エネルギー・データ・セット１００８ａ、１００８ｂ、１００８ｃを生成する。さらに、トレーニング・サンプル部分１００４ａ、１００４ｂ、１００４ｃに対応する複数の相関および相対エネルギー・データ・セット１０１０ａ、１０１０ｂ、１０１０ｃも生成される。
【０１４１】
相関および相対エネルギー・データ・セット１００８ａ〜ｃおよび１０１０ａ〜ｃは、特徴の分布を生成するために使用されてもよい。図１０では、特徴の分布はグラフ１０１２によって表されている。相関および相対エネルギー・データ・セット１００８ａ、１００８ｂ、１００８ｃは、対応するトレーニング・サンプル部分１００２ａ、１００２ｂ、１００２ｃのどれがプロトタイプ動き特徴iのサブシーケンスに最も近く相関しているかを判定するために評価されてもよい。相関および相対エネルギー・データ・セット１００８ａ、１００８ｂ、１００８ｃの最大確率は、最大指示１０１４ａ、１０１４ｂ、１０１４ｃとして表されている。最大指示１０１４ａ、１０１４ｂ、１０１４ｃは、対応する確からしさスコア１０１６ａ、１０１６ｂ、１０１６ｃを決定するために使用されてもよい。
【０１４２】
本願のシステムの一つの目標は、コンピューティング環境１２上で走っているアプリケーションによって再生される音楽に合わせて踊るときのユーザーのダンス動きのような動きを同定することである。本願のシステムは、ダンス動きのような動きは典型的には反復的であるという事実を利用する。音楽の各拍において基本的な動きがあり、それら基本的な動きの組み合わせが複数拍動きをなし、それもまた反復する。このように、ユーザーは、音楽の一拍当たりまたは複数拍の組当たり一回、所与の動きを反復することがある。音楽が速くなると、ユーザーもより速く動く傾向がある。音楽がゆっくりになると、ユーザーもよりゆっくり動く傾向がある。その結果、ユーザーが行う傾向のある動きは、拍毎に、または所定数の拍毎に繰り返される。よって、本願のシステムは、時間に基づくのではなく音楽の拍子（または他の周期的な測定単位）に基づくある期間にわたる反復性の動きを解析する。
【０１４３】
特に、本システムにおいて実行されているソフトウェアは、骨格動きデータのフレーム数を測定の周期的単位に規格化し、規格化された骨格動きデータ・セットを提供してもよい。測定の周期的単位の例は、音楽におけるあらかじめ定義された拍数である。フレーム数を音楽の拍または他の何らかの周期的な測定単位に規格化することによって、本願のシステムは、反復的なユーザー動きを、時間とは独立な、固定した周期に規格化することができる。より速い拍子をもつ音楽については、ユーザーが一サイクルの動きを完了する期間内のフレーム数も速くなるであろう。より遅い拍子をもつ音楽については、ユーザーが一サイクルの動きを完了する期間内のフレーム数も遅くなるであろう。しかしながら、周期自身は、時間とは独立である。
【０１４４】
音楽の拍子および作品中で該拍子がどのように変わるかは、一般にはあらかじめ決まっているが、音楽ソフトウェアを使って検出することもできる。時間ではなく拍を基準として使うことによって、ジェスチャーが行われる速さとは独立に、ジェスチャーが認識されることができる。フレーム数を拍または他の期間に対して規格化することは、反復的な固定期間内の反復的な動きを識別することを容易にすることによって、リアルタイムのジェスチャー認識において計算を簡略化する。この情報は、たとえば、ダンス動きのようなジェスチャーまたは特定の動きを識別するために使われてもよい。
【０１４５】
対応するジェスチャーを実行する際にユーザーによって示された技量のレベルを評価するためにさらなる解析が実行されてもよい。たとえば、ユーザー・データ動き特徴とプロトタイプ動き特徴データベースからのプロトタイプ動き特徴データとの間の相関または類似性の度合いが、ゲーム・コンテキストにおけるユーザーのパフォーマンスにスコア付けする基礎として使われてもよい。換言すれば、ユーザーは、プロトタイプ動き特徴データベースにおいて表されている動きまたはジェスチャーをよりよく近似することに対して、より高いゲーム・スコアを授与されてもよい。
【０１４６】
図１１は、本願の技術に基づく、ジェスチャー認識エンジン実施形態のブロック図１１００である。ジェスチャー認識エンジン１１０２はユーザー入力動き特徴１１０４の形のユーザー入力データを処理する。さらに、ジェスチャー認識エンジンは、図４に示されるジェスチャー分類システム４００のようなジェスチャー分類システムを有していてもよい。
【０１４７】
ある実施形態では、ジェスチャー認識エンジン１１０２によってアクセス可能なプロトタイプ動き特徴データベースまたはライブラリ１１０６が、ユーザーの動きの相関を調べることのできる対象となる、ダンス種別、ステップなどのような動きクラスを表すプロトタイプ動き特徴１１０８のカタログを記憶している。記憶されたプロトタイプ動き特徴は、図２に示される骨格データ点のうちの複数について、位置、場所などを定義してもよい。プロトタイプ動き特徴１１０８は、プロのダンサーによって実行される動き特徴を捕捉することなどにより、熟達者データを使って生成されてもよい。ジェスチャー認識エンジン１１０２の例示的な実施形態は、たとえば、隠れマルコフ・モデルおよびロジスティック回帰を使ってもよい。
【０１４８】
図１２は、ターゲット認識、解析および追跡システムにおいて一つまたは複数のジェスチャーを解釈するために使用されてもよいコンピューティング環境の例示的な実施形態を示している。図１Ａ〜１Ｃに関して上記したコンピューティング環境１２のようなコンピューティング環境は、ゲーム・コンソールのようなマルチメディア・コンソール１２００であってもよい。図１２に示されるように、マルチメディア・コンソール１２００は、レベル１キャッシュ１２０４、レベル２キャッシュ１２０６およびフラッシュROM  １２０８を含んでいてもよいコンピュータ可読記憶媒体を有する中央処理ユニット（CPU）１２０２を有する。レベル１キャッシュ１２０４およびレベル２キャッシュ１２０６は一時的にデータを記憶し、よってメモリ・アクセス・サイクルの数を減らし、それにより処理スピードおよびスループットを改善する。二つ以上のコアを、よって追加的なレベル１およびレベル２キャッシュ１２０４および１２０６を有するCPU  １２０２が提供されてもよい。フラッシュROM  １２０８は、マルチメディア・コンソール１２００の電源がオンにされるときのブート・プロセスの初期フェーズの間にロードされる実行可能なコードを記憶していてもよい。
【０１４９】
グラフィック処理ユニット（GPU）１２１０およびビデオ・エンコーダ／ビデオ・コーデック（コーダ／デコーダ）１２１６は、高速かつ高解像度のグラフィック処理のためのビデオ処理パイプラインをなす。データはGPU  １２１０からビデオ・エンコーダ／ビデオ・コーデック１２１６にバスを介して運ばれる。ビデオ処理パイプラインは、テレビジョンまたは他のディスプレイへの伝送のため、データをA/V（オーディオ／ビデオ）ポート１２３８に出力する。これに限られないがRAMのようなさまざまな型のメモリ１２１４へのプロセッサ・アクセスを容易にするよう、メモリ・コントローラ１２１２がGPU  １２１０に接続される。
【０１５０】
マルチメディア・コンソール１２００は、I/Oコントローラ１２１８、システム管理コントローラ１２２０、オーディオ処理ユニット１２２２、ネットワーク・インターフェース・コントローラ１２２４、第一のUSBホスト・コントローラ１２２６、第二のUSBホスト・コントローラ１２２８およびモジュール上に実装されていてもよいフロント・パネルI/Oサブアセンブリー１２３０を含む。USBコントローラ１２２６および１２２８は、周辺コントローラ１２４０（１）〜１２４０（２）、無線アダプター１２４４および外部メモリ・デバイス１２４２（たとえば、フラッシュ・メモリ、外部CD/DVD  ROMドライブ、リムーバブル・メディアなど）のためのホストとしてはたらく。ネットワーク・インターフェース１２２４および／または無線アダプター１２４４はネットワーク（インターネット、家庭ネットワークなど）へのアクセスを提供し、イーサネット(登録商標)・カード、モデム、ブルートゥース・モジュール、ケーブル・モデムなどを含む、幅広い多様なさまざまな有線または無線のアダプター・コンポーネントのうちの任意のものであってもよい。
【０１５１】
システム・メモリ１２３６は、ブート・プロセスの間にロードされるアプリケーション・データを記憶するために設けられる。メディア・ドライブ１４４が設けられ、DVD/CDドライブ、ハードドライブまたは他のリムーバブル・メディア・ドライブなどを含んでいてもよい。メディア・ドライブ１４４はマルチメディア・コンソール１２００の内部でも外部でもよい。アプリケーション・データは、マルチメディア・コンソール１２００による実行、再生などのために、メディア・ドライブ１４４を介してアクセスされてもよい。メディア・ドライブ１４４は、シリアルATAバスまたは他の高速接続（たとえばIEEE1394）のようなバスを介してI/Oコントローラ１２１８に接続される。
【０１５２】
システム管理コントローラ１２２０は、マルチメディア・コンソール１２００の可用性を保証することに関係した多様なサービス機能を提供する。オーディオ処理ユニット１２２２およびオーディオ・コーデック１３２は、高忠実度およびステレオ処理をもつ対応するオーディオ処理パイプラインをなす。オーディオ・データは、オーディオ処理ユニット１２２２とオーディオ・コーデック１３２との間で通信リンクを介して搬送される。オーディオ処理パイプラインは、オーディオ機能をもつ外部オーディオ・プレーヤーまたは装置による再生のために、A/Vポート１２３８にデータを出力する。
【０１５３】
フロント・パネルI/Oサブアセンブリー１２３０は電源ボタン１２４６およびイジェクト・ボタン１２４８ならびにもしあればマルチメディア・コンソール１２００の外側表面上に露出しているLED（発光ダイオード）または他のインジケーターの機能をサポートする。ファン１２３４がマルチメディア・コンソール１２００内の回路を冷却する。
【０１５４】
CPU  １２０２、GPU  １２１０、メモリ・コントローラ１２１２およびマルチメディア・コンソール１２００内のさまざまな他のコンポーネントは一つまたは複数のバスを介して相互接続されている。該バスは、多様なバス・アーキテクチャのうち任意のものを使う、シリアルおよびパラレル・バス、メモリ・バス、周辺バスおよびプロセッサまたはローカル・バスを含む。例として、そのようなアーキテクチャは、周辺コンポーネント相互接続（PCI:  Peripheral  Component  Interconnects）バス、PCIエクスプレス（PCI-Express）バスなどを含むことができる。
【０１５５】
マルチメディア・コンソール１２００の電源がオンにされるとき、アプリケーション・データがシステム・メモリ１２３６からメモリ１２１４および／またはキャッシュ１２０４、１２０６にロードされ、CPU  １２０２上で実行されてもよい。アプリケーションは、マルチメディア・コンソール１２００上で利用可能な種々のメディア種別にナビゲートするときに一貫したユーザー経験を提供するグラフィカル・ユーザー・インターフェースを呈示してもよい。動作では、メディア・ドライブ１４４内に含まれるアプリケーションおよび／または他のメディアがメディア・ドライブ１４４から起動または再生されてもよく、それによりマルチメディア・コンソール１２００に追加的な機能が提供される。
【０１５６】
マルチメディア・コンソール１２００は、単に該システムをテレビジョンまたは他のディスプレイに接続することによって、スタンドアローンのシステムとして動作されてもよい。このスタンドアローン・モードでは、マルチメディア・コンソール１２００は一つまたは複数のユーザーがシステムと対話する、映画を見る、または音楽を聴くことを許容する。しかしながら、ブロードバンド接続性の統合がネットワーク・インターフェース１２２４または無線アダプター１２４４を通じて利用可能にされると、マルチメディア・コンソール１２００はさらに、より大きなネットワーク・コミュニティーにおける一員として動作させられてもよい。
【０１５７】
マルチメディア・コンソール１２００の電源がオンにされるとき、設定された量のハードウェア資源が、マルチメディア・コンソール・オペレーティング・システムによるシステム使用のために予約される。これらの資源はメモリ（たとえば16MB）、CPUおよびGPUサイクル（たとえば5%）、ネットワーク帯域幅（たとえば8kbs）などの予約を含んでいてもよい。これらの資源はシステム・ブート時に予約されるので、予約された資源は、アプリケーションの観点からは、存在しない。
【０１５８】
具体的には、メモリ予約は、立ち上げカーネル、同時並行システム・アプリケーションおよびドライバを含むのに十分大きいことが望ましい。CPU予約は一定であることが望ましく、そのため、予約されたCPU使用がシステム・アプリケーションによって使用されない場合、何らかの不使用サイクルがあればそれをアイドル・スレッドが使用する。
【０１５９】
GPU予約に関しては、システム・アプリケーションによって生成される軽いメッセージ（たとえばポップアップ）が、ポップアップをオーバーレイ中にレンダリングするコードをスケジューリングするためにGPU割り込みを使うことによって表示される。オーバーレイのために必要とされるメモリ量は、オーバーレイ領域サイズに依存し、オーバーレイは画面解像度とともにスケーリングしてもよい。フル・ユーザー・インターフェースが同時並行システム・アプリケーションによって使用されるときは、アプリケーション解像度とは独立な解像度を使うことが望ましいことがある。この解像度を設定するためにスカラーが使用されてもよく、周波数を変え、テレビに再同期させる必要がなくなる。
【０１６０】
マルチメディア・コンソール１２００がブートし、システム資源が予約されたのち、同時並行システム・アプリケーションが、システム機能を提供するよう実行される。システム機能は、上記の予約されたシステム資源内で実行される一組のシステム・アプリケーションにおいてカプセル化される。オペレーティング・システム・カーネルが、ゲーム・アプリケーション・スレッドではなくシステム・アプリケーション・スレッドであるスレッドを同定する。システム・アプリケーションは、アプリケーションに対して一貫したシステム資源ビューを与えるために、あらかじめ決められた時間および間隔でCPU  １２０２上で走るようスケジューリングされてもよい。スケジューリングは、コンソール上で走っているゲーム・アプリケーションにとってのキャッシュ破壊を最小限にするべきである。
【０１６１】
同時並行システム・アプリケーションがオーディオを必要とするとき、オーディオ処理は、時間敏感性のため、ゲーム・アプリケーションに対して非同期的にスケジューリングされる。システム・アプリケーションがアクティブなとき、マルチメディア・コンソール・アプリケーション・マネージャ（後述）がゲーム・アプリケーション・オーディオ・レベルを制御する（たとえばミュートする、減衰させる）。
【０１６２】
入力装置（たとえばコントローラ１２４０（１）および１２４０（２））はゲーム・アプリケーションおよびシステム・アプリケーションによって共有される。入力装置は予約される資源ではないが、各アプリケーションが当該装置のフォーカスをもつよう、システム・アプリケーションとゲーム・アプリケーションとの間で切り換えられるものである。アプリケーション・マネージャは、ゲーム・アプリケーションの知識を知ることなく、入力ストリームの切り換えを制御してもよく、ドライバがフォーカス切り換えに関する状態情報を維持する。カメラ１２８、１３０および捕捉装置１２２は、コンソール１２００についての追加的な入力装置を定義しうる。
【０１６３】
図１３は、ターゲット認識、解析および追跡システムにおける一つまたは複数のジェスチャーを解釈するために使われる、図１Ａ〜図２に示されるコンピューティング環境１２であってもよいコンピューティング環境１３００のもう一つの例示的な実施形態を示す。コンピューティング環境１３００は好適なコンピューティング環境のほんの一例であり、本願に開示される主題の使用または機能の範囲に関して何ら限定を示唆することを意図されてはいない。また、コンピューティング環境１３００は、例示的なコンピューティング環境１３００に示されるコンポーネントのどの一つまたは組み合わせに関係するいかなる依存性も要求ももつものと解釈すべきではない。いくつかの実施形態では、さまざまな描かれているコンピューティング要素は、本開示の個別的な側面のインスタンスをなすよう構成された回路を含んでいてもよい。たとえば、本開示において使用される回路という用語は、ファームウェアまたはスイッチによって機能（単数または複数）を実行するよう構成された特化したハードウェア・コンポーネントを含むことができる。他の例示的実施形態では、回路という用語は、機能（単数または複数）を実行するよう機能できる論理を具現するソフトウェア命令によって構成される汎用処理ユニット、メモリなどを含むことができる。回路がハードウェアおよびソフトウェアの組み合わせを含む例示的実施形態では、実装者は、論理を具現するソース・コードを書いてもよく、該ソース・コードが、汎用処理ユニットによって処理できる機械可読コードにコンパイルされることができる。当業者は、現状技術がハードウェア、ソフトウェアまたはハードウェア／ソフトウェアの組み合わせの間にほとんど相違がないという点にまで進化していることを認識することができるので、特定の機能を実現するためのハードウェアかソフトウェアかの選択は、実装者に委ねられる設計上の選択である。より具体的には、当業者は、ソフトウェア・プロセスは等価なハードウェア構造に変換でき、ハードウェア構造自身が等価なソフトウェア・プロセスに変換できることを理解できる。よって、ハードウェア実装かソフトウェア実装かの選択は設計上の選択であり、実装者に委ねられるのである。
【０１６４】
図１３では、コンピューティング環境１３００は、典型的には多様なコンピュータ可読媒体を含むコンピュータ１３４０を有する。コンピュータ可読媒体は、コンピュータ１３４０によってアクセスできる任意の利用可能な媒体であることができ、揮発性および不揮発性媒体の両方、リムーバブルおよび非リムーバブル媒体を含む。システム・メモリ１３０２は、ROM  １３０４およびRAM  １３８０のような揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。スタートアップ中などにコンピュータ１３４０内での諸要素の間で情報を転送するのを助ける基本的なルーチンを含む基本入出力システム１３０６（BIOS）が典型的にはROM  １３０４内に記憶されている。RAM  １３８０は典型的には、処理ユニット１３７６にとってすぐアクセス可能なおよび／または処理ユニット１３７６によって現在作用されているデータおよび／またはプログラム・モジュールを含む。限定ではなく例として、図１３は、オペレーティング・システム１３０８、アプリケーション・プログラム１３１０、他のプログラム・モジュール１３１２およびプログラム・データ１３１４を示している。
【０１６５】
コンピュータ１３４０は、他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶媒体をも含んでいてもよい。単に例として、図１３は、非リムーバブル、不揮発性磁気媒体の読み書きをするハードディスク・ドライブ１３３４、リムーバブル、不揮発性磁気ディスク１３６６の読み書きをする磁気ディスク・ドライブ１３３６およびCD-ROMもしくは他の光学式媒体のようなリムーバブル、不揮発性光ディスク１３６４の読み書きをする光ディスク・ドライブ１３３８を示している。例示的な動作環境において使用できる他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶媒体は、これに限られないが、磁気テープ・カセット、フラッシュメモリ・カード、デジタル多用途ディスク、デジタル・ビデオ・テープ、半導体RAM、半導体ROMなどを含む。ハードディスク・ドライブ１３３４は典型的にはインターフェース１３２６のような非リムーバブル・メモリ・インターフェースを通じてシステム・バス１３７８に接続され、磁気ディスク・ドライブ１３３６および光ディスク・ドライブ１３３８は典型的にはインターフェース１３２８のようなリムーバブル・メモリ・インターフェースによってシステム・バス１３７８に接続される。
【０１６６】
上記で論じ、図１３に示したドライブおよび関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラム・モジュールおよびコンピュータ１３４０のための他のデータの記憶を提供する。図１３では、たとえば、ハードディスク・ドライブ１３３４がオペレーティング・システム１３７４、アプリケーション・プログラム１３７２、他のプログラム・モジュール１３７０およびプログラム・データ１３６８を記憶するとして示されている。これらのコンポーネントは、オペレーティング・システム１３０８、アプリケーション・プログラム１３１０、他のプログラム・モジュール１３１２およびプログラム・データ１３１４と同じであっても、異なっていてもよいことを注意しておく。オペレーティング・システム１３７４、アプリケーション・プログラム１３７２、他のプログラム・モジュール１３７０およびプログラム・データ１３６８は、少なくとも異なるコピーであるということを示すために、ここでは異なる番号を与えられている。ユーザーは、キーボード１３６０および、一般にマウス、トラックボールまたはタッチパッドと称されるポインティング・デバイス１３６２のような入力装置を通じてコンピュータ１３４０にコマンドおよび情報を入力してもよい。他の入力装置（図示せず）はマイクロホン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナなどを含んでいてもよい。これらおよび他の入力装置は、しばしばシステム・バスに結合されているユーザー入力インターフェース１３３０を通じて処理ユニット１３７６に接続されるが、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（USB）のような他のインターフェースおよびバス構造によって接続されてもよい。カメラ１２８、１３０および捕捉装置１１０は、コンソール１２００のための追加的な入力装置を定義してもよい。モニタ１３４２または他の型の表示装置もビデオ・インターフェース１３２２のようなインターフェースを介してシステム・バス１３７８に接続される。モニタに加えて、コンピュータは、出力周辺インターフェース１３２４を通じて接続されうる、スピーカー１３４６およびプリンタ１３４４のような他の周辺出力装置をも含んでいてもよい。
【０１６７】
コンピュータ１３４０は、リモート・コンピュータ１３５０のような一つまたは複数のリモート・コンピュータへの論理的な接続を使ってネットワーク接続された環境において動作してもよい。リモート・コンピュータ１３５０は、パーソナル・コンピュータ、サーバー、ルータ、ネットワークPC、ピア装置または他の一般的なネットワーク・ノードであってもよく、典型的にはコンピュータ１３４０に関して上記した要素の多くまたは全部を含むが、図１３では、メモリ記憶デバイス１３５２のみが示されている。図１３に描かれている論理的な接続はローカル・エリア・ネットワーク（LAN）１３４８および広域ネットワーク（WAN）１３５６を含むが、他のネットワークを含んでいてもよい。そのようなネットワーク接続環境はオフィス、企業規模のコンピュータ・ネットワーク、イントラネットおよびインターネットにおいてありふれたものである。
【０１６８】
LANネットワーク環境で使われるとき、コンピュータ１３４０はネットワーク・インターフェースまたはアダプター１３３２を通じてLAN  １３４８に接続される。WANネットワーク環境において使われるとき、コンピュータ１３４０は典型的にはモデム１３５８またはインターネットのようなWAN  １３５６を通じた通信を確立するための他の手段を含む。内蔵であっても外付けであってもよいモデム１３５８は、ユーザー入力インターフェース１３３０または他の適切な機構を介してシステム・バス１３７８に接続されていてもよい。ネットワーク環境では、コンピュータ１３４０に関して描かれているプログラム・モジュールまたはその一部がリモート・メモリ記憶デバイスに記憶されていてもよい。限定ではなく例として、図１３は、リモート・アプリケーション・プログラム１３５４を、メモリ・デバイス１３５２上にあるものとして示している。図示したネットワーク接続は例示的であって、コンピュータ間の通信リンクを確立する他の手段が使われてもよいことは理解されるであろう。
【０１６９】
上記は主題となる革新の例を含む。もちろん、特許請求される主題を記述する目的のためにコンポーネントまたは方法論の考えられるあらゆる組み合わせを記述することは可能ではないが、当業者は、主題となる革新の多くのさらなる組み合わせおよび入れ替えが可能であることを認識しうる。よって、特許請求される主題は、付属の請求項の精神および範囲内にはいるあらゆるそのような変更、修正および変形を包含することが意図されている。
【０１７０】
特に、上記のコンポーネント、装置、回路、システムなどによって実行されるさまざまな機能に関し、そのようなコンポーネントを記述するために使われる用語（「手段」への言及を含む）は、特に断りのない限り、記述されるコンポーネントの特定される機能を実行する、たとえ開示される構造と構造的に等価でなくても本稿で示される特許請求される主題の例示的な側面における機能を実行する、任意のコンポーネント（たとえば機能的な等価物）に対応することが意図されている。これに関し、本革新がシステムおよび特許請求される主題のさまざまな方法の工程および／またはイベントを実行するためのコンピュータ実行可能な命令を有するコンピュータ可読記憶媒体を含むことも認識されるであろう。
【０１７１】
主題となる革新を実装する多くの方法がある。たとえば、アプリケーションおよびサービスが本稿に記載される技法を使うことを可能にする、適切なAPI、ツール・キット、ドライバ・コード、オペレーティング・システム、コントロール、スタンドアローンまたはダウンロード可能なソフトウェア・オブジェクトなどである。特許請求される主題は、API（または他のソフトウェア・オブジェクト）の観点から、および本稿に記載される技法に従って動作するソフトウェアまたはハードウェア・オブジェクトからの使用を考えている。よって、本稿に記載される主題となる革新のさまざまな実装は、完全にハードウェアである、部分的にハードウェア、部分的にソフトウェアである、またソフトウェアである諸側面を有しうる。
【０１７２】
上述したシステムは、いくつかのコンポーネントの間の相互作用に関して記述してきた。そのようなシステムおよびコンポーネントは、それらのコンポーネントまたは指定されたサブコンポーネント、指定されたコンポーネントまたはサブコンポーネントの一部および／または追加的なコンポーネントならびに上記のさまざまな入れ替えおよび組み合わせを含むことができることは理解できる。サブコンポーネントは、親コンポーネント内に含まれる（階層的）のではなく、他のコンポーネントに通信上結合されるコンポーネントとして実装されることもできる。さらに、一つまたは複数のコンポーネントが総合的な機能を提供する単一のコンポーネントに組み合わされてもよく、あるいはいくつかの別個のサブコンポーネントに分割されてもよく、統合された機能を提供するためにそのようなサブコンポーネントに通信上結合するよう管理層のような任意の一つまたは複数の中間層が設けられてもよいことに注意しておいてもよい。本稿に記載した任意のコンポーネントは、本稿に特定的に記載されないが当業者には一般に知られている一つまたは複数の他のコンポーネントと相互作用してもよい。
【０１７３】
さらに、主題となる革新の特定の特徴がいくつかの実装のうち一つだけとの関連で開示されていることもありうるが、そのような特徴は、任意の所与のまたは具体的な応用についての所望および利点に応じて、他の実装の一つまたは複数の他の特徴と組み合わされてもよい。さらに、用語「含む」、「もつ」、その変形および他の同様の単語が詳細な説明または請求項のいずれかにおいて使用される限りにおいて、これらの用語は、何らかの追加的なまたは他の要素を排除しない、オープンな移行語として包含的であることが意図されている。
【図１Ａ】
0005902204.tif 000016
【図１Ｂ】
0005902204.tif 000017
【図１Ｃ】
0005902204.tif 000018
【図２】
0005902204.tif 000019
【図３】
0005902204.tif 000020
【図４】
0005902204.tif 000021
【図５】
0005902204.tif 000022
【図６】
0005902204.tif 000023
【図７Ａ】
0005902204.tif 000024
【図７Ｂ】
0005902204.tif 000025
【図８】
0005902204.tif 000026
【図９】
0005902204.tif 000027
【図１０】
0005902204.tif 000028
【図１１】
0005902204.tif 000029
【図１２】
0005902204.tif 000030
【図１３】
0005902204.tif 000031