JP2015525381A - 相互ユーザ手追跡および形状認識ユーザ・インターフェース - Google Patents

Abstract

実施形態は、手または物体追跡および形状認識を実行する視覚系インターフェースを含む。この視覚系インターフェースは、センサからデータを受信し、このデータは、センサによって検出された物体に対応する。このインターフェースは、データの各フレームから画像を生成し、これらの画像は多数の解像度を表す。このインターフェースは、画像におけるブロブを検出し、これらのブロブを物体のトラックと関連付けることによって、物体を追跡する。このインターフェースは、各ブロブを、多数の物体形状の内の１つに対応するものとして分類することによって物体のポーズを検出する。このインターフェースは、ポーズおよびトラックに応答して、ジェスチャ・インターフェースを制御する。【選択図】 図１Ｂ

Description

関連出願
本出願は、２０１２年５月４日に出願した米国特許出願第６１／６４３，１２４号の優先権を主張する。

本出願は、２０１２年６月４日に出願した米国特許出願第６１／６５５，４２３号の優先権を主張する。

本願は、２０１２年１０月８日に出願した米国特許出願第６１／７１１，１５２号の一部継続出願である。

本願は、２０１２年１０月２６日に出願した米国特許出願第６１／７１９，１０９号の一部継続出願である。

本願は、２０１２年１１月２日に出願した米国特許出願第６１／７２２，００７号の一部継続出願である。

本願は、２０１２年１１月２日に出願した米国特許出願第６１／７２５，４４９号の一部継続出願である。

本願は、２０１３年３月１５日に出願した米国特許出願第６１／７８７，７９２号の一部継続出願である。

本願は、２０１３年３月１４日に出願した米国特許出願第６１／７８５，０５３号の一部継続出願である。

本願は、２０１３年３月１５日に出願した米国特許出願第６１／７８７，６５０号の一部継続出願である。

本願は、２０１２年１２月３１日に出願した米国特許出願第６１／７４７，９４０号の一部継続出願である。

本願は、米国特許出願第１２／５７２，６８９号、第１２／５７２，６９８号、第１３／８５０，８３７号、第１２／４１７，２５２号、第１２／４８７，６２３号、第１２／５５３，８４５号、第１２／５５３，９０２号、第１２／５５３，９２９号、第１２／５５７，４６４号、第１２／５７９，３４０号、第１３／７５９，４７２号、第１２／５７９，３７２号、第１２／７７３，６０５号、第１２／７７３，６６７号、第１２／７８９，１２９号、第１２／７８９，２６２号、第１２／７８９，３０２号、第１３／４３０，５０９号、第１３／４３０，６２６号、第１３／５３２，５２７号、第１３／５３２，６０５号、および第１３／５３２，６２８号の一部継続出願である。
発明の分野
本明細書において説明する実施形態は、一般に、処理システムに関し、更に特定すれば、手追跡および形状認識処理システムに関する。

従来技術

視覚系インターフェース(vision-based interface)では、カーソル制御、３Ｄナビゲーション、動的ジェスチャの認識、ならびに一貫性のあるフォーカスおよびユーザ識別というようなユーザ対話処理をサポートするために、手追跡(hand tracking)が使用されることが多い。

乱雑な視覚的にノイズが多い場面におけるロバストな追跡のために多くの精巧なアルゴリズムが開発されているが、長期間追跡および追跡初期化のための手検出は、困難な作業であり続けている。
引用による包含
本明細書において述べる各特許、特許出願、および／または刊行物は、本願において引用することにより、個々の特許、特許出願、および／または刊行物の各々が具体的にそして個々に、引用することにより本願に含まれることを示した場合と同程度にその全体が本願にも含まれるものとする。

図１Ａは、一実施形態の下における、手追跡および形状認識コンポーネントまたはアプリケーションをホストするプロセッサ、ディスプレイ、およびセンサを含むＳＯＥキオスクのブロック図である。 図１Ｂは、一実施形態の下における、ＳＯＥキオスクと操作者との間の関係を示す。 図２は、一実施形態の下において手または物体追跡および形状認識を実行する視覚系インターフェースの動作の流れ図である。 図３は、一実施形態の下において手または物体追跡および形状認識を実行ための流れ図である。 図４は、一実施形態の下において手追跡および形状認識において使用される８つの手の形状を示す。 図５は、同じ手形状カテゴリに対するユーザ間の変形を示すサンプル画像を示す。 図６Ａ、図６Ｂ、および図６Ｃ（纏めて図６）は、一実施形態の下において、追跡結果と共に擬似カラー深度画像を示し、追跡履歴を示し、更に信頼度値と共に認識結果を示す。 ６Ａ、図６Ｂ、および図６Ｃ（纏めて図６）は、一実施形態の下において、追跡結果と共に擬似カラー深度画像を示し、追跡履歴を示し、更に信頼度値と共に認識結果を示す。 図６Ａ、図６Ｂ、および図６Ｃ（纏めて図６）は、一実施形態の下において、追跡結果と共に擬似カラー深度画像を示し、追跡履歴を示し、更に信頼度値と共に認識結果を示す。 図７は、一実施形態の下における、隣接する生センサ読み取り値間における計量距離(metric distance)に基づく深度の関数として指定した最少深度曖昧さのプロットを示す。 図８は、一実施形態の下において、（ａ）４つの矩形を示す集合Ｂ、および（ｂ）１対のグリッド・セル間における平均深度の差を示す集合Ｃについて抽出された特徴を示す。 図９は、一実施形態の下における、ランダム化判断フォーレスト（ＲＦ：randomized decision forest）および４つの特徴集合にわたるサポート・ベクトル・マシン（ＳＶＭ）クラシファイアについて手形状認識精度の比較のプロットである。 図１０は、一実施形態において、ランダム化判断フォーレストにおいて異なる数のツリーを使用する手形状認識精度の比較のプロットである。 図１１は、一実施形態の下におけるジェスチャ制御システムのブロック図である。 図１２は、 一実施形態の下におけるマーキング・タグの図である。 図１３は、実施形態の下におけるジェスチャ・ボキャブラリ(gesture vocabulary)におけるポーズの図である。 図１４は、一実施形態の下におけるジェスチャ・ボキャブラリにおける方位の図である。 図１５は、一実施形態におけるジェスチャ・ボキャブラリにおける２つの手の組み合わせの図である。 図１６は、一実施形態におけるジェスチャ・ボキャブラリにおける方位配合の図である。 図１７は、 一実施形態におけるシステム動作の流れ図である。 図１８／１および図１８／２は、一実施形態におけるコマンドの一例を示す。 図１８／１および図１８／２は、一実施形態におけるコマンドの一例を示す。 図１９は、一実施形態の下において、スロークス(slawx)、プロテイン(protein)、およびプール(pool)を使用したデータ表現を含む処理環境のブロック図である。 図２０は、一実施形態の下における、プロテインのブロック図である。 図２１は、一実施形態の下における、デスクリップ(descrip)のブロック図である。 図２２は、一実施形態の下における、インジェスト(ingest)のブロック図である。 図２３は、一実施形態の下におけるスロー(slaw)のブロック図である。 図２４Ａは、一実施形態の下において、プールの中にあるプロテインのブロック図である。 図２４Ｂ／１および図２４Ｂ／２は、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。 図２４Ｂ／１および図２４Ｂ／２は、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。 図２４Ｃは、一実施形態の下においてプロテインを使用する際の流れ図である。 図２４Ｄは、一実施形態の下において、プロテインを組み立てるまたは生成する際の流れ図である。 図２５は、一実施形態の下において、スロークス、プロテイン、およびプールを使用したデータ交換を含む処理環境のブロック図である。 図２６は、多数のデバイスと、これらのデバイスの１つ以上で走る多数のプログラムとを含む処理環境のブロック図であり、一実施形態の下において、プラズマ構造(plasma construct)（即ち、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。 図２７は、多数のデバイスと、これらのデバイスの１つ以上で走る多数のプログラムを含む処理環境のブロック図であり、一代替実施形態の下において、プラズマ構造（即ち、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。 図２８は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、別の代替実施形態の下において、プラズマ構造（即ち、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。 図２９は、多数のデバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造（即ち、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする。 図３０は、多数のデバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造（即ち、プール、プロテイン、およびスロー）を使用することにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする。 図３１は、多数のデバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、追加の代替実施形態の下において、プラズマ構造（即ち、プール、プロテイン、およびスロー）を使用することにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる。

本明細書において説明する実施形態は、広い１組の手形状を自動的に認識し、広範囲のユーザにわたってジェスチャを追跡および認識するときに高い正解率(high accuracy rates)を維持するジェスチャ・インターフェースを提供する。実施形態は、センサから受信されたデータを使用して、リアル・タイムの手検出および追跡を行う。本明細書において説明する手追跡および形状認識ジェスチャ・インターフェースは、空間動作環境（ＳＯＥ）キオスク（「キオスク」または「ＳＯＥキオスク」とも呼ぶ）を可能にするか、またはその１コンポーネントであり、空間動作環境（ＳＯＥ）およびそのジェスチャ・インターフェースは、信頼性があり、マーカレス・手追跡システム内において動作する。このＳＯＥとマーカレス・ジェスチャ認識との組み合わせは、手形状の追跡および分類における新規性、ならびにＳＯＥアプリケーションの設計、実行、および権限(purview)における進展(development)を組み込んだ機能性を提供する。

本明細書において引用した関連出願は、ジェスチャ・ベース制御のためのシステムおよび方法の説明を含み、実施形態には、マーカレス・ジェスチャ認識を提供するものもあり、更に他の実施形態では、１つまたは複数の手袋の形態としたユーザの手をある種の指標によって識別するものもある。ＳＯＥキオスク・システムは、マーカレス設定(markerless setting)を設け、この設定では、一例として、グローブレスで指標を使用しないシステム(gloveless, indicia-free system)においてジェスチャが追跡および検出され、普通でない指検出およびレイテンシを与える。ＳＯＥシステムは、少なくとも、ジェスチャ入力／出力、ネットワーク・ベースのデータ表現、移行(transit)、および相互交換、ならびに空間的に適合された表示メッシュを含む。見た目には(in scope)、ＳＯＥは、完全なアプリケーションおよび開発プラットフォームであるので、オペレーティング・システムに類似する。しかし、これは、従前の計算システムを超えて広がる、設計および機能を規定する展望(perspective) を想定する。

豊富な能力は、ジェスチャ・インターフェースを含み、ユーザがシステムと対話処理し、このシステムが手のポーズ、ジェスチャ、および動きを追跡し解釈する。

本明細書の説明および関連出願において詳しく記載されるように、ＳＯＥは実世界幾何属性(geometry)を規定して、このようなインターフェースおよび対話処理を可能にする。関連出願の全ては、引用したことによって本願に含まれるものとする。例えば、ＳＯＥは、空間的に一致する表示メッシュ(spatially conformed display mesh)を採用し、この表示メッシュは、「実世界」の広がりの中に、システムの視覚的、聴覚的、および触覚的表示が存在するように、物理空間および仮想空間を整列させる。その機能のこのエリア全体は、三次元幾何属性に関してＳＯＥによって実現される。画素は、モニタ上の解像度に加えて、世界における位置を有する。何故なら、二次元モニタ自体がサイズおよび方位を有するからである。この方式では、実世界座標がプロパティを注釈する(annotate)。この記述的能力は、全てのＳＯＥ関与物(participant)をカバーする。例えば、ワンド(wand)および移動体ユニットのようなデバイスは、多数の実現される入力エレメントの１つとなることができる。

この空間の信頼できる観念がＳＯＥに浸透する(pervade)。あらゆるレベルにおいて、これはその座標表記(coordinate notation)へのアクセスを与える。物体（物理的または仮想的の如何を問わない）の位置は幾何属性に関して表現できるので、物体（物理的または仮想的の如何を問わない）間の空間的関係を幾何属性に関して表現することができる。（この場合も、あらゆる種類の入力デバイスをこの関係のコンポーネントとして含ませることができる。）関連出願および本明細書における説明において記されるように、ユーザが画面上の物体を指し示すと、ＳＯＥは交点計算を解釈する。画面の物体は、ユーザの動作に応答して、反応する。ユーザがこの因果関係を知覚して応答すると、古いモードのコンピュータ対話処理に取って代わる。ＳＯＥ内部では、グラフィクスがユーザと同じ室内にあることを理解して、ユーザは行動する。その結果、直接的な空間操作が得られる。この動的インターフェースでは、入力は古い方法の制約を超えて広がる。ＳＯＥは、三次元空間の全ボリュームを開放し、多様な入力エレメントを受け入れる。

この再着想された(reconceived)一層豊富な計算空間に、ＳＯＥは再結合(recombinant)ネットワーキング、相互作用可能性に対する新たな手法を導入する。関連出願および本明細書における説明は、ＳＯＥが、大規模なマルチプロセス相互動作を支える(sustain)プログラミング環境であると説明する。ＳＯＥは、「プラズマ」を含む。これは、少なくとも多数のプロセス間におけるデータの効率的な交換、柔軟なデータ「タイピング」(typing)、および構造を構成するので、広範囲で多様な種類のデータおよびその使用がサポートされ、全て実質的に同様なＡＰＩによって駆動される、データ交換のための柔軟なメカニズム（例えば、ローカル・メモリ、ディスク、ネットワーク等）、異なるプログラム言語で書かれたプロセス間におけるデータ交換、ならびにデータ・キャッシングおよび集計状態の自動保守、その他数多くがサポートされるアーキテクチャである。技術スタック(technology stack)やオペレーティング・システムには関係なく、ＳＯＥは、旧来の表現を含む、外部データおよび動作を利用する。これは、iPhoneのような移動体ユニットを含むがこれらに限定されないデバイスからの比較的低レベル品質の空間データを統合することを含む。このようなデバイスは、「エッジ」ユニットとも呼ばれる。

先に述べたように、本明細書において説明するＳＯＥキオスクは、自己完結型マーカレス設定内部においてＳＯＥのロバストな手法を提供する。ユーザは、手袋、マーカ、またはこのような指標を全く使用せずに、ＳＯＥを「自由な」エージェントとして使用し(engage)、更に画面、カメラ、または発光体(emitter)の設置というような、空間の変更も必要としない。唯一必要なことは、手形状および他の入力エレメントを検出し、追跡し これらに応答するシステムに近接することである。本明細書において詳細に説明するように、本システムは、マーカレス追跡システムと組み合わせられた代表的センサを含み、予め指定された範囲内においてポーズの認識を行う（例えば、１メートルと３メートルの間等）。ＳＯＥキオスク・システムは、したがって、可搬性および設置に柔軟性を与えるが、実施形態はそのように限定されるのではない。

図１Ａは、ＳＯＥキオスク・システムのブロック図である。一実施形態の下において、ＳＯＥキオスク・システムは、手追跡および形状認識を使用する視覚系インターフェースを設けるジェスチャ・インターフェース・コンポーネントまたはアプリケーションをホストするプロセッサ、ディスプレイ、およびセンサを含む。図１Ｂは、一実施形態の下における、ＳＯＥキオスクと操作者との間の関係を示す。一般的な用語「キオスク」は、本明細書において説明するマーカレス追跡および認識プロセスを使用する種々の設定および構成を包含する。これらの異なる設置は、例えば、センサおよび少なくとも１つのディスプレイに結合されたプロセッサ、ならびにこのプロセッサ上で実行して視覚パイプラインを統合するＳＯＥを提供する追跡および認識コンポーネントまたはアプリケーションを含む。一実施形態のＳＯＥキオスクは、ネットワーク能力を含み、ルータのような結合または接続されたデバイスによって提供されても、またはワイヤレスのようなアクセスによって使用されてもよい。

図２は、一実施形態の下において、手または物体追跡および形状認識２０を実行するジェスチャまたは視覚系インターフェースの動作の流れ図である。この視覚系インターフェースは、センサ２１からデータを受信し、このデータは、センサによって検知された物体に対応する。このインターフェースは、データ２２の各フレームから画像を生成し、これらの画像は多数の解像度を表す。このインターフェースは、画像におけるブロブを検出し、ブロブを物体２３の追跡と関連付けることによって、物体を追跡する。ブロブとは、あるプロパティ（例えば、明るさ、色、深度等）が一定であるかまたは既定の範囲の値以内で変化するディジタル画像の領域であり、ブロブにおける全ての点が、ある意味で、互いに同様であると考えることができる。このインターフェースは、各ブロブを多数の物体形状２４の内の１つに対応するとして分類することによって、物体のポーズを検出する。このインターフェースは、ポーズおよび追跡２５に応答して、ジェスチャ・インターフェースを制御する。

図３は、一実施形態の下において手または物体追跡および形状認識３０を実行するための流れ図である。物体追跡および形状認識は、例えば、視覚系ジェスチャ・インターフェースにおいて使用されるが、そのように限定されるのではない。追跡および認識は、身体３１の四肢のセンサ・データを受信することを含む。追跡および認識は、センサ・データから、第１解像度３２を有する第１画像を生成することを含む。追跡および認識は、第１画像３３においてブロブを検出することを含む。追跡および認識は、ブロブを四肢３４の追跡と関連付けることを含む。追跡および認識は、センサ・データから、第２解像度３５を有する第２画像を生成することを含む。追跡および認識は、第２画像を使用して、ブロブの各々を多数の手形状３６の内の１つとして分類することを含む。

ＳＯＥキオスク・ハードウェア構成の実施形態例が以下に続くが、実施形態はこれらの構成例に限定されるのではない。一実施形態のＳＯＥキオスクは、 Asus Xtion Proを有する２７インチ・バージョンのApple iMacであり、iMacの上面にセンサが取り付けられる。Tenbaのケースは、iMac、センサ、ならびにキーボード、マウス、電力ケーブル、およびテーブル・タップ(power strip)を含むアクセサリを含む。

他の一実施形態例のＳＯＥキオスクは、３０インチ画面の比較的小さな形状係数のパーソナル・コンピュータ（ＰＣ）を含む携帯用ミニキオスクである。画面およびスタンドがプロセッサから離れているので、この設定は、横向き表示および縦向き表示の双方をサポートする。

追加の一実施形態例のＳＯＥキオスクは、ＤＶＩまたはＨＤＭＩ（登録商標）入力を受け入れる５０インチの１９２０×１０８０テレビジョンまたはモニタであるディスプレイと、センサ（例えば、Asus Xtion Pro Live、Asus Xtion Pro、Microsoft Kinect、Windows（登録商標） 用Microsoft Kinect、Panasonic D-Imager、SoftKinetic DS311, Tyzx G3 EVS等）、ならびにクアッドコアＣＰＵおよび NVIDIA NVS 420 GPUを実行する比較的小さな形状係数のＰＣを含むコンピュータまたはプロセスを含む。

前述のように、ＳＯＥキオスクの実施形態は、センサとしてMicrosoft Kinectを含むが、実施形態はそのように限定されるのではない。一実施形態のKinectセンサは、概略的に、カメラ、赤外線（ＩＲ）発光体、マイクロフォン、および加速度計を含む。更に具体的には、Kinectは、３チャネル・データを１２８０×９６０の解像度で格納するカラーＶＧＡカメラ、またはＲＧＢカメラを含む。また、ＩＲ発光体およびＩＲ深度センサも含まれる。発光体は、赤外線ビームを放出し、深度センサは、センサから反射されるＩＲビームを読み取る。反射ビームは、物体とセンサとの間の距離を測定する深度情報に変換され、深度画像の取り込みを可能にする。

また、Kinectは、音を取り込むための４つのマイクロフォンを内蔵するマルチアレイ・マイクロフォンも含む。４つのマイクロフォンがあるので、オーディオを記録するだけでなく、音源の位置および音波(audio wave)の方向を発見することも可能である。更に、このセンサには、２Ｇ範囲用に構成された３軸加速度計が含まれ、ここでＧは重力加速度を表す。加速度計は、Kinectの現在の方位を判定するために使用することができる。

低コストの深度カメラは、ロバストで遍在的な視覚系インターフェースの新たな好機を創造する。多くの研究は身体全体のポーズ指定および全体的な身体の動きの解釈を目標とするが、この作業(work)は、骨格を使用しない手の検出、追跡、および形状分類を調査する。本明細書において説明する実施形態は、広い１組の手形状を認識し、広い範囲のユーザにわたって高い正解率を維持する方法を開発することによって、豊富で信頼性のあるジェスチャ・インターフェースを提供する。

実施形態は、一例として、Microsoft Kinectからの深度データを使用して、リアル・タイムでの手の検出および追跡を行うが、このように限定されるのではない。１６人のユーザから収集された８つの手の形状に対して、定量的な形状認識結果が提示され、信頼性および全体的なユーザ体験を高めるのに役立つ物理的構成およびインターフェース設計問題が提示される。

手追跡、ジェスチャ認識、および視覚系インターフェースは、コンピュータ視覚団体(computer vision community)内において長い歴史を有する（例えば、１９８０年に公開されたプット−ザット−ゼア・システム(put-that-there system)（例えば、 R. A. Bolt. Put-that-there: Voice and gesture at the graphics interface（プット−ザット−ゼア：グラフィクス・インターフェースにおける音声およびジェスチャ）、Conference on Computer Graphics and Interactive Techniques, 1980（「ボルト」）））。興味を持った読者には、更に広い分野をカバーする多くの研究論文の１つを勧める（例えば、A. Erol, G. Bebis, M. Nicolescu, R. Boyle, and X. Twomblyの Vision-based hand pose estimation: A review. Computer Vision and Image Understanding（視覚に基づく手のポーズ推定：考察、コンピュータ視覚および画像理解）、108:52-73, 2007 (「Erol et al.」); S. Mitra and T. Acharya. Gesture recognition。ある調査、IEEE Transactions on Systems, Man and Cybernetics -Part C, 37(3):311-324, 2007 (「Mitra et al.」)。 X. Zabulis, H. Baltzakis, and A. Argyros. Vision-based hand gesture recognition for human-computer interaction（人間−コンピュータ対話処理用視覚系手ジェスチャ認識）、The Universal Access Handbook, pages 34.1-34.30, 2009 (「Zabulis et al.」)。T. B. Moeslund and E. Granum、A survey of computer vision-based human motion capture（コンピュータ視覚に基づく人間モーション・キャプチャ）、Computer Vision and Image Understanding, 81 :231-268, 2001 (「Moeslund-1 et al.」)。T. B. Moeslund, A. Hilton, and V. Kruger、A survey of advances in vision-based human motion capture and analysis（視覚に基づく人間モーション・キャプチャおよび分析における発展の調査） Computer Vision and Image Understanding, 104:90-126, 2006 (「Moeslund-2 et al.」))。

Plagemann et al.の功績は、頭、手、および脚のような身体部分を深度画像から検出し分類する方法を紹介する（例えば、C. Plagemann, V. Ganapathi, D. Koller, and S. Thrun、 Real-time identification and localization of body parts from depth images（深度画像からの身体部分のリアル・タイム識別および定位）IEEE International Conference on Robotics and Automation (ICRA), 2010 (「Plagemann et al.」))。これらは、これらの身体部分を測地線極値と同等視し、深度画像において接続されたメッシュを突き止め、次いで直前の１組のポイントまでの即値線距離を最大化するメッシュ・ポイントを繰り返し発見することによって検出される。このプロセスは、メッシュの重心を使用するか、または２つの最も遠いポイントを突き止めることのいずれかによって、シードされる(seed)。本明細書において紹介する手法は、概念的には同様であるが、乱雑(clutter)を無視するために、予め指定された境界ボックスを必要としない。更に、Plagemann et al.は、極値を有効な頭、手、または脚と識別するために、学習されたクラシファイアを使用したが、本方法は、解像度を高めた深度センサを利用し、極値を様々な異なる手形状の内の１つとして認識する。

Shwarz et al.は、追加の身体部分を検出し、全身体の骨格をメッシュに当てはめることによって、Plagemann et al.の業績を拡大する（例えば、L. A. Schwarz, A. Mkhitaryan, D. Mateus, and N. Navab、Estimating human 3d pose from time-of-flight images based on geodesic distances and optical flow（測地線距離および光流に基づく飛行時間画像からの人間３Dポーズの推定）、 Automatic Face and Gesture Recognition, pages 700-706, 201 1 (「Shwarz et al.」)）。また、これらは、自己隠蔽を補償するのに役立てるために、光流(optical flow)情報を組み込む。しかしながら、本願において紹介する実施形態に対する関係は、Shwarz et al.が測地線距離を計算するために全体的情報(global information)を利用するが、混乱場面において信頼性が低下する虞があり、これらは指の外形(finger configuration)を検出しようとも、全体的な手形状を認識しようともしないことから、Plagemann et al.に対するものと同様である。

Shotton et al.は、局在的近隣においてクエリ・ポイント(query point)と他のものとの間の距離について訓練されたランダム化判断フォーレスト（例えば、L. Breiman、Random forests（ランダム・フォーレスト）、Machine Learning, 45(l):5-32, 2001 (「Breiman」)を使用して深度ポイントを異なる身体部分として直接分類する方法を開発した（例えば、J. Shotton, A. Fitzgibbon, M. Cook, T. Sharp, M. Finocchio, R. Moore, A. Kipman, and A. Blake、Real-time human pose recognition in parts from a single depth image（１つの深度画像から部分的な人間ポーズのリアル・タイム認識）、 IEEE Conf on Computer Vision and Pattern Recognition, 2011 (「Shotton et al.」))。これらの目標は、より高いレベルの情報をリアル・タイム骨格追跡システムに提供することであり、したがってこれらは３１通りの異なる身体部分を認識する。これは、単なる頭、手、および脚を遙かに超える。また、本明細書において説明する手法は、ランダム化判断フォーレストも使用する。何故なら、それらの分類オーバーヘッドが低く、そのモデルがマルチクラス問題を扱う本来的な能力を有するからである。本明細書において説明する実施形態は、様々な異なる手形状を認識するために、フォーレストを訓練するが、手以外の身体部分を検出しない。

本明細書において特筆するような視覚系インターフェースでは、カーソル制御、３Ｄナビゲーション、動的ジェスチャの認識、ならびに一貫したフォーカスおよびユーザ識別というようなユーザ対話処理をサポートするために、手追跡が使用されることが多い。多くの精巧なアルゴリズムが、混乱した視覚的にノイズが多い場面におけるロバストな追跡のために開発されている（例えば、J. Deutscher, A. Blake, and I. Reid、Articulated body motion capture by annealed particle filtering（アニール粒子フィルタリング(annealed particle filtering)による明瞭な身体モーション・キャプチャ）、Computer Vision and Pattern Recognition, pages 126-133, 2000 (「Deutscher et al.」)、A. Argyros and M. Lourakis、Vision-based interpretation of hand gestures for remote control of a computer mouse（コンピュータ・マウスの遠隔制御のための手ジェスチャの視覚に基づく解釈）、Computer Vision in HCI, pages 40-51, 2006. 1 (「Argyros et al.」)）が、長期間の追跡および追跡初期化のための手検出は、困難な作業であり続けている。本明細書において説明する実施形態は、信頼性の高い、マーカレス手追跡システムを構築する。このシステムは、手形状、ポーズ、および動きに基づくジェスチャ・インターフェースの作成をサポートする。このようなインターフェースは、低レイテンシの手追跡および高精度の形状分類を必要とするが、併せて、適時なフィードバックおよびシームレスなユーザ体験にも対処する。

本明細書において説明する実施形態は、局所的セグメント化および手検出のために、１つのカメラからの深度情報を利用する。高精度の画素毎の深度データは、視覚的複雑さに大きく独立した方法で、前景／背景セグメント化の問題を著しく低減する。したがって、実施形態は、局所的なテキスチャおよび色というような二次的なプロパティではなく、人間の身体の３Ｄ構造に基づいて、身体部分検出器および追跡システムを構築する。二次的プロパティは、通例、異なるユーザおよび環境にわたって遙かに高い度合いのばらつきを呈する（Shotton et al., Plagemann et al.参照）。

実施形態は、視覚系ユーザ・インターフェースのための基礎として、マーカレス手追跡および手形状認識を行う。したがって、ユーザの身体全体を識別し追跡することは全く必要とせず、実際に、身体全体（または上半身全体であっても）が見えることを想定しない。代わりに、実施形態は、ユーザが着座しており机がユーザの腕の一部を隠すので、手が身体の残りに繋がっているのが観察できないというような、視認性が限定される場合のみに対処する状況を思い描く(envision)。このようなシナリオは、実世界環境では非常に自然に現れ、ユーザが彼らの肘を彼らの椅子の肘掛けに載せる場合もあり、または開いているラップトップというような机上の混乱によりカメラの視野の下部分が遮られる場合もある。

図４は、一実施形態の下における手追跡および形状認識において使用される８通りの手形状を示す。左または右端にあるポーズ名は、その手に特定的であり、一方「開」および「閉」は、親指が開いているか、または掌側に折り曲げられているかを指す。頭文字語「ｏｆｐ」は、「ワン・フィンガ・ポイント」(one finger point)を表し、外側に延びた人差し指に対応する。

一実施形態の初期の１組の８通りのポーズは、比較的強い視覚的相違を維持しつつ、有用な対話処理の範囲を規定する。例えば、開いた手と拳の組み合わせは、カーソルを動かし、次いである物体を掴むまたは選択するために使用するのでもよい。同様に、掌を開いたポーズは、アクティブ化しもっと多くの情報を露出させ（空間でグラフィック表現を逆に「押す」ことによって）、次いで横方向の手の動きによってデータ全体をスクロールするために使用することができる。

他の１組の手形状は、もっと広いが、指の外形について遙かに精度高く完全な情報を必要とする。例えば、アメリカ手話法（ＡＳＬ）指話伝達アルファベットは、２６文字および０から９までの数字をカバーする、遙かに豊富な１組の手のポーズを含む。これらの手形状は、微妙な指の合図を利用するが、ユーザおよび視覚システム双方にとって、特に視覚システムにとって、区別することが困難である可能性がある。

一実施形態のジェスチャ集合は視覚的に別個であるように構成されるという事実にも拘わらず、各形状クラス内に、広い範囲のばらつきが見られた。図５は、同じ手形状カテゴリに対するユーザ間におけるばらつきを示すサンプル画像である。

もっと精度が高く解像度が高い深度センサがあれば、クラス内の相違の一部は低減されるであろうが、主要な原因は、人の手の間にある本質的なばらつき、そして１つ視点だけを使用することによって生ずる遠近感(perspective)および閉塞効果である。物理的な手のばらつきは、全体的なサイズ、指の幅、指の長さと掌のサイズの比率、関節の範囲、柔軟性、および指の制御において観察された。例えば、掌を開いたポーズでは、一部のユーザは自然に彼らの親指を広げるので、かれらの掌および人差し指に対してほぼ直角になったが、他のユーザは、彼らの親指を４５度を超えて動かそうとしたときに、つらさを訴えた。同様に、ばらつきは、１回の対話処理の間にも見られた。例えば、ユーザが彼らの指同士をきつく結んだところから掌を開くジェスチャを開始して、次いでこのジェスチャが進むに連れて彼らの指を弛緩させると、開いた掌と開いた手との間の区別が曖昧になるかもしれない。

本明細書における実施形態の中心的な寄与は、手形状および運動(mechanics)における広いばらつきにも拘わらず、異なるユーザにわたって信頼性高く動作するリアル・タイム視覚インターフェースの設計および実施にある。一実施形態の手法は、効率的で、骨格を使用しない手検出および追跡アルゴリズムに基づく。このアルゴリズムは、フレーム毎の局在極点検出を高速手形状分類と組み合わせて使用し、本明細書における方法の定量的評価は、以前に見たことがないユーザについて９７％よりも高い手形状認識率を与える。

本明細書における実施形態の検出および追跡は、ユーザの身体質量(body mass)の中心からの測地線距離に関して、手が極点に対応するという考えに基づく。この仮定は、例えば、ユーザが両手を腰に当てて立っているときには破られるが、このような身体のポーズは、インターフェースとの有効な対話処理を妨げ、したがってこれらの低レベルの偽陰性は、高レベルの偽陰性には対応しない。実施形態は、処理ボリュームを限定するための予め指定された境界ボックスを必要とすることなく、混乱に対してロバストであるようにするため、これらの実施形態の手法は、大域的な測地線距離を計算することを避け、それよりも簡素な局所的手法をとる。具体的には、極点の候補は、深度画像において局所的な指向性ピークを直接検出し、次いで空間的に接続された成分を潜在的な手として抽出することによって発見される。

実施形態のコア検出および追跡は、６４０×４８０の入力解像度を８０×６０にサブサンプリングした後に、深度フレーム毎に実行される。しかしながら、手形状分析は、本明細書において説明するように、それよりも高い解像度で実行される。ダウンサンプリングされた深度画像は、失われた深度データに対応するゼロ値を無視し、エッジを保存するロバストな手法を使用して計算される。深度読み取り値は本質的に場面における質量(mass)を表すので、異種の深度値の平均を取ることは避けるのが望ましい。さもないと、中間深度において「幻覚」の質量を生ずるであろう。

局所ピークは、８０×６０深度画像において、４つの直行方向（上、下、左、および右）のいずれかにおいて、それらの空間的隣接物よりも遠くまで延びる画素を求めることによって検出される。この経験則は、多くの偽陽性を犠牲にして、低い偽陰性率を与える。言い換えると、実施形態は実際の手を失いたくないが、多数の検出または他の物体を含んでもよい。何故なら、これらは後の段階で排除されるからである。

各ピーク画素は、最大の手のサイズによって結ばれた接続成分（「ブロブ」）のシード(seed)になる。最大の手のサイズは、３００ｍｍに、深度に依存する緩慢値(slack value)を加算したものが選ばれる。この緩慢値は予想深度誤差を表す。Microsoft Kinectでは、深度誤差は、２つの隣接する生のセンサ読み取り値によって表される物理距離に対応する（図７参照。図７は、隣接する生のセンサ読み取り値間のメートル単位の距離に基づく深度の関数として、推定最少深度曖昧さのプロットを示す）。言い換えると、緩慢値は、２０００ｍｍの距離における１０ｍｍの深度の差を求めることは、その深度における代表的な精度が２５ｍｍでしかないので、正当ではないという事実を考慮する。

一実施形態のアルゴリズムは、ブロブの境界から最も離れた画素を発見することによって、ブロブ毎に潜在的な手の中心を推定する。これは、距離変換を使用すると、効率的に計算することができる。次いで、更に、２００ｍｍの掌の半径を使用して、ブロブを間引き、前腕および他の身体部分を除外しつつ手の画素を含ませることを目標とする。最後に、同様の深度を有するブロブに隣接する画素として定められるブロブを「拡張する」(extend)深度画素の外境界を検索することによって、低レベル処理は終了する。一実施形態のアルゴリズムは、拡張画素を分析して、境界長に対して相対的に小さな領域を探し、非常に大きな拡張領域または接続されていない拡張領域を有するブロブを間引く。拡張領域は、有効な手のブロブにおいて手首に対応すると想定され、Plagemann et al.が測地線後戻りポイントを使用するのと全く同じように、方位を推定するために使用される（ Plagemann et al.を参照のこと）。

次いで、ブロブは追跡モジュールに送られる。追跡モジュールは、現在のフレームにおけるブロブを既存のトラック(tracks)と関連付ける。各ブロブ／軌道対は、ブロブの重心とトラックの現在の速度によって制限される軌道との間の最少距離にしたがって、採点される。加えて、低レベルの曖昧さのために重複するブロブがあるかもしれず、したがって、追跡モジュールは暗黙の相互除外(implied mutual exclusion)を実施する。ブロブは、一致の全てにわたる総スコアを最小化することによって、全域的に最適な方法で、トラックと関連付けられる。過度に貧弱な一致を防止するために、２５０ｍｍのスコア閾値が使用されるので、一部のブロブおよび／またはトラックは不一致になるものもあり得る。

主要なトラック拡張の後、残っている不一致ブロブがトラックと比較され、これらが空間的近傍内にある場合、二次ブロブとして追加される。このように、多数のブロブを１つのトラックと関連付けることができる。これは、１つの手が場合によっては様々な別個の成分として観察されることもあるからである。観察を分解する(disjoint)ことに至るシナリオは、ユーザが大きな輝く指輪をはめており、投射された構造化光のKinectの分析を妨げるときである。これらの場合、指輪がはまっている指を視覚的に手から分離させることができる。何故なら、指輪自体をカバーする深度データがないからである。指がないと、手の形状の解釈が完全に代わる可能性があるので、指ブロブをトラックと関連付けるには極めて重要になる。

次いで、追跡モジュールは、いずれかの残りのブロブを使用して、新たなトラックをシードし、対応する物体の視覚的証拠が全くないまま数フレーム進んだ古いトラックを間引く。

手形状認識に関して、ブロブ抽出および追跡に使用される８０×６０深度画像は、場合によっては、形状分析には十分な情報を提供しない。代わりに、手ポーズ認識は、３２０×２４０深度画像の、Quarter Video Graphics Array (QVGA) 表示解像度を利用する。QVGAモードは、画素単位で画像のサイズまたは解像度を記述する。一実施形態は、どのQVGA画素が各トラックに対応するかについて決定を行う。これらの画素は、その対応する８０×６０画素から小さな深度距離以内にある各QVGA画素において、接続成分検索をシードすることによって識別される。また、一実施形態のアルゴリズムは、QVGA画素を使用して手の中心を再度推定して、カーソル制御および他の連続的な位置に基づく対話処理のために、一層感度が高い３Ｄ位置推定値を供給する。

一実施形態は、各ブロブを８つのモデル化された手形状の内１つとして分類するために、ランダム化判断フォーレスト（Breimanを参照のこと）を使用する。各フォーレストは、判断ツリーの集合体(ensemble)であり、最終的な分類（またはクラス全体における分布）は、これらのツリー全てにわたる結果を併合することによって計算される。１つの判断ツリーはその訓練データを容易に重ね合わせることができるので、これらのツリーは、分散を増大させ複合誤差を減少させるためにランダム化される。

ランダム化は、次の２つの形態を取る。（１）訓練データ集合全体からブートストラップ・サンプルに対して各ツリーを学習させる。（２）ツリーにおけるノードは、ランダムに選択された少数の特徴に対して最適化する。ランダム化判断フォーレストは、リアル・タイム手形状分類に有用な様々な興味を引くプロパティを有する。即ち、これらは実行時に非常に高速であり、自動的に特徴選択を実行し、本質的にマルチクラス分類をサポートし、容易に並列化することができる。

一実施形態の方法は、３つの異なる種類の画像特徴を利用して、セグメント化された手のパッチを特徴付ける。集合Ａは、ブロブ輪郭によってカバーされる画素のパーセンテージ、検出された指先の数、ブロブの重心から指先までの平均角度、および指先自体の平均角度というような、全体的な画像統計を含む。また、これは７つの独立Flusser-Sukモメント全ても含む（例えば、J. Flusser and T. Suk、Rotation moment invariants for recognition of symmetric objects（対称形物体の認識のための回転モーメント不変関係）、IEEE Transactions on Image Processing, 15:3784-3790, 2006 (「Flusser et al」)）。

指先は、高い正の湾曲の領域を検索することによって、各ブロブの輪郭から検出される。湾曲は、しかるべきラップアラウンド(wrap-around)でサンプリングされた輪郭点Ｃ_ｉと、そのｋ個の隣接Ｃ_ｉ−ｋおよびＣ_ｉ＋ｋによって形成されたベクトル間の角度を見ることによって推定される。一実施形態のアルゴリズムは、２つのスケールにおける高い湾曲を使用し、ブロブの深度に依存してｋの値を変調し、第１スケールに対してｋが大まかに３０ｍｍになり、第２スケールに対してクエリ・ポイントから約５０ｍｍになるようにする。

特徴集合Ｂは、ブロブの境界ボックスをその全サイズで正規化したものにおいて可能な各矩形によってカバーされる画素の数で構成される。スケール不変(scale-invariance)を確保するために、各ブロブ画像は５×５格子にサブサンプリングされ、これが意味するのは、集合Ｂには２２５個の矩形があり、したがって２２５個の記述子があるということである（（ａ）４つの矩形を示す集合Ｂ、および（ｂ）格子セルの１対間における平均深度の差を示す集合Ｃを表す図８を参照のこと）。

特徴集合Ｃは、集合Ｂと同じ格子を使用するが、異なる矩形内における被覆範囲(coverage)を見る代わりに、個々のセルの対毎の平均深度間の差を含む。５×５格子上には２５個のセルがあるので、集合Ｃには３００個の記述子がある。特徴集合Ｄは、集合Ａ、Ｂ、およびＣからの特徴の全てを組み合わせ、合計５３６個の特徴が得られる。

本明細書において説明するように、ブロブ抽出アルゴリズムは、拡張画素を求めることによって、各ブロブの手首位置を推定しようとする。このような領域が発見されると、この拡張領域の重心をブロブの重心に接続するベクトルに基づいて方位を推定するために使用される。QVGA画像パッチをこの角度の逆数(inverse)だけ回転させることによって、多くのブロブは、いずれの記述子が計算される前でも、規準的方位(canonical orientation)を有するように変形することができる。このプロセスは、あるレベルの回転不変性を与えることによって、分類精度を高める。しかしながら、全てのブロブについて方位を推定することはできない。例えば、カメラに腕が直接向けられた場合、ブロブは拡張画素を全く有さない。これらの場合、記述子は、変形されないブロブ画像に対して計算される。

本明細書における実施形態を、リアル・タイム手追跡および形状認識について評価するために、１６人の被験者(subject)からサンプル・ビデオが記録された（図６Ａ、図６Ｂ、および図６Ｃ（纏めて図６）は、擬似カラー深度画像を、追跡結果６０１、追跡履歴６０２，および信頼度値を伴う認識結果（テキスト・レベル）と共に示す３つのサンプル・フレームを示す）。これらのビデオは、６４０×４８０の解像度で３０Ｈｚにおいて、Microsoft Kinectを使用して取り込まれた。Microsoft Kinectは、構造化光に基づく手法を使用して、画素毎の深度を推定する。各被験者は、図４に示した８つの手形状に対応する８つのビデオ・セグメントに寄与した。本明細書において説明するセグメント化および追跡アルゴリズムは、これらのビデオに対して実行され、後処理(post-process)を変更して、最も近いQVGAブロブ画像をディスクに保存した。つまり、訓練例は、オンライン・バージョンにおいて使用された同じアルゴリズムを使用して、これらのビデオから自動的に抽出された。唯一の手作業の介入は、少数の追跡誤差の除去であった。こうしなければ、訓練集合が汚染されたであろう。例えば、数個のビデオの先頭において、本システムは、ユーザの手を自動追跡する前に、ユーザの頭に対応するブロブを保存した。

手のポーズの内いくつかは、左手または右手のいずれかに特定的であり（例えば、掌が左向きに開く）、一方他のポーズは双方の手に対して非常に似通っている（例えば、Ｖサイン）。第２集合におけるポーズは、訓練データに２回含まれ、全く変形がない状態で１回、そして垂直軸を中心とした反射の後に１回である。ライブ・インタラクティブ・システムによる定性的実験によって、反射された例を含めると、認識性能に著しい改善に繋がることが発見された。

１６人の被験者は、２５才から４０才までで身長が１６０ｃｍから１８８ｃｍまでの４人の女性および１２人の男性を含んだ。反射バージョンを含むと、各人物は８通りの手のポーズにわたって、１，８９８および９，６２５の間の例に寄与し、合計で９３，３３６個の標識付きの例が得られた。初期評価は、標準的なクロス検証を使用して、総合性能(generalization performance)を推定した。非常に低い誤差率が見出されたが、ライブ・システムを使用した新たなユーザが比較的貧弱な分類率に気付いた(saw)という体験は、 暗示された性能が信頼性高く予測するには至らなかった。

１つの解釈は、ランダム・パーティションが訓練集合および検査集合双方において各ユーザからのサンプルを含んでいたので、クロス検証が性能を過大評価していたということである。訓練例はビデオから抽出されたので、高度の時間相関があり、したがって検査パーティションは、総合性能を示さなかった。ユーザ間誤差(cross-user error)の有効な推定値によってもっと意味のある実験を行うために、１ユーザ抜き出し手法(leave-one-user-out approach)を代わりに使用するための切り替えが行われた。この評価方式の下では、モデルおよび特徴集合の各組み合わせが、１５人の被験者からのデータに対して訓練され、結果的に得られたクラシファイア(classifier)を、見られなかった１６番目の被験者について評価した。このプロセスは、繰り返す毎に異なる被験者からのデータを検査集合として使用して、１６回繰り返した。

図９は、４つの特徴集合に対するランダム化判断フォーレスト（ＲＦ）およびサポート・ベクトル・マシン（ＳＶＭ）クラシファイアについての手形状認識精度の比較を表す。ここで、特徴集合Ａは全体的統計を使用し、特徴集合Ｂは異なる矩形において正規化占有率(occupancy rates)を使用し、特徴集合Ｃはポイント間の深度差を使用し、特徴集合Ｄは、集合Ａ、Ｂ、およびＣを組み合わせる。図９は、したがって、ランダム化判断フォーレスト（ＲＦ）およびサポート・ベクトル・マシン（ＳＶＭ）モデルの双方に対する平均認識率を示す。ＳＶＭは、ＬＩＢＳＶＭによって訓練され（例えば、C.C. Chang and C.J. Lin. LIBSVM: A library for support vector machines（サポート・ベクトル・マシンのためのライブラリ）、ACM Transactions on Intelligent Systems and Technology, 2:27: 1-27:27, 2011 (「Chang et al.」)、データの部分集合における小さな検索の結果に基づいて精度を最大化するように選択されたパラメータと共に、ラジアル基底関数カーネルを使用した。ＲＦおよびＳＶＭの双方は、本明細書において説明した４つの特徴集合によって検査された。

最良の結果は、特徴集合Ｄを使用したＲＦモデル（ＲＦ−Ｄ）によって達成された。この組み合わせによって、９７．２％の平均ユーザ間正解率を、２．４２の標準偏差で得られた。ＲＦ−Ｄの下における任意の被験者に対する最悪の性能は９２．８％であり、６人の被験者は９９％よりも高い正解率を見た。比較のために、ＳＶＭを使用した最良の性能は、特徴集合Ｂとによるものであり、９５．６％の平均正解率、２．７３の標準偏差、および８９．０％の最悪事態が得られた。

図９に示すＲＦ結果は、１００本のツリーを有するフォーレストに基づく。各ツリーは、３０の最大深度および間引きなしで学習された。各分割ノードにおいて、選択されたランダム特徴の数は、記述子の総数の二乗根に設定された。アンサンブル・クラシファイア(ensemble classifier)は、ランダム・ツリーの全てにわたって結果を併合することによって入力データを評価し、したがって、実行時間はツリーの本数に比例する。リアル・タイム・システムでは、特にレイテンシが問題になる場合、自然な質問は、フォーレストにおけるツリーの本数が減少するに連れて分類精度はどのように変化するかということである。図１０は、ランダム化判断フォーレストにおいて異なる本数のツリーを使用した手形状認識精度の比較を示す。このグラフは、平均精度、および約９５％の信頼度間隔（青い円、左側の軸）を示す±２σ線を、１つの例を分類するための平均時間（緑色の菱形、右側の軸）と共に示す。図１０は、手形状分類問題について、認識精度は、３０本のツリーに落ちるまでは安定であり、９７．２％から９６．９％に低下するだけであることを示す。２０本のツリーでも、平均ユーザ間精度は、９６．４％に低下するに過ぎないが、この点よりも低いと、性能は更に劇的に低下し始める。使用した検査機械上では、観察された平均分類速度は、１００本のツリーでは例当たり９３．３μ秒であったが、３０本のツリーでは２０．１に過ぎなかった。

正解率は高い程望ましいであろうが、一実施形態のインタラクティブ・システムを使用して作業したユーザの非公式な報告および観察の解釈は、９７．２％の現在の正解率は、明確な(positive)ユーザ体験には十分であるということである。ほぼ３％の誤差率は、平均して、一実施形態のシステムは、大凡３０フレーム毎にユーザのポーズを分類し損ねる可能性があることを意味するが、このような均一な分布は、実際には期待されない。何故なら、誤差は独立でありそうもないからである。誤差は凝集する(clump)だけでなく、これらの多くは、様々な重要な要因によって、実際の使用中に隠されることが考えられる。最初に、本ライブ・システムは、ランダムな短期間誤差を避けるために、時間的一貫性(temporal consistency)を使用することができる。十分なフィードバックがある場合、そして些細な行動変化だけが必要な場合、第２に、協働ユーザがシステムに適合する。そして第３に、混同し易い手のポーズの影響を最小限にするように、ユーザ・インターフェースを構成することができる。

インターフェースを適合させる格好の例が、掌を開いたポーズに基づくプッシュバック対話処理(pushback interaction)で生ずる。この対話処理の典型的な使用は、グラフィカル表現を更に画面内に押し戻す(push back)ことによって、ユーザが彼らの作業空間を一層多く見ることを可能にする。また、ユーザが、作業空間の異なるエリアにパンニングすること、または異なる物体（例えば、映画、画像、または商品）全体をスクロールすることができることもあり得る。スクロールは、比較的長い対話処理になるので、ユーザは彼らの指を弛緩させることが多いので、彼らの意図は変化しなくても、開いた掌(palm-open)が開いた手(open-hand)のように見え始める。一実施形態は、開いた手が他の状況では別個の解釈に繋がるのであっても、開いた手がプッシュバック(pushback)対話処理を混乱させるのを防止する単純な知覚微調整(tweak)を実装した。

本質的に、開いた掌だけがそれを開始することができるが、双方共対話処理を継続することを許される。更に、これらの間における移行ポーズに対応するために、分類信頼性が２つのポーズの間でプールされる。

また、インターフェースおよび作業空間に対する物理変化を伴う実験が行われた。例えば、深度カメラが主要画面の上の代わりに下に装着されたときに、ユーザ体験に顕著な改善が見られた。この差は、恐らく、ユーザが基本的な身体の運動(mechanics)および重力のために彼らの手を上げるよりは弛緩させて下げる傾向に由来するからである。カメラを底部に装着すると、手を多少曲げるかまたは下げることによって、手形状の映像がより良く得られるが、上部に装着したカメラからの映像は劣化する。同様に、大きな画面程それよりも遠くに立つユーザの自然な傾向を利用することができる。Kinectおよび多くの他の深度カメラは３０〜８０ｃｍの範囲に最少検知距離を有するので、ユーザはできるだけ少ない明示的な備忘録および警告メッセージで、機能的距離(functional distance)を維持することを勧めることができる。一実施形態のインターフェースは、対話処理が検知平面またはカメラの視野のエッジに近づいたときに視覚的指示を与えるが、画面サイズのような暗黙の自然な合図の方が遙かに好ましい。

空間動作環境（ＳＯＥ）
空間連続入力システムの実施形態について、本明細書では、空間動作環境（ＳＯＥ）のコンテキストで説明する。一例として、図１１は、一実施形態の下における、空間動作環境（ＳＯＥ）のブロック図である。ユーザが、カメラのアレイ（例えば、１つ以上のカメラまたはセンサ１０４Ａ〜１０４Ｄ）の視野１５０内に手１０１（または手１０１および１０２）を配置する。これらのカメラは、指ならびに手１０１および１０２の位置、方位、および移動を空間追跡データとして検出し、出力信号をプリプロセッサ１０５に生成する。プリプロセッサ１０５は、カメラ出力をジェスチャ信号に変換し、このジェスチャ信号をシステムのコンピュータ演算装置１０７に供給する。コンピュータ１０７は、入力情報を使用して、１つ以上の画面上カーソルを制御するコマンドを生成し、ビデオ出力をディスプレイ１０３に供給する。リアル・タイム視覚系手追跡システムを初期化するための、以上で詳細に説明したシステムおよび方法は、例えば、ＳＯＥおよび類似するシステムにおいて使用することができる。

このシステムでは、一人のユーザの手を入力として示すが、ＳＯＥ１００は、多数のユーザを使用しても実現することができる。加えて、手の代わりにまたは手に加えて、本システムはユーザの身体の任意の１つ以上の部分を追跡することができ、その部分とは、頭部、足、脚部、腕、肘、膝等を含む。

ＳＯＥは、本明細書において説明した手または物体追跡および形状認識を実行する視覚系インターフェースを含むが、代替実施形態は、局在環境においてユーザの手の位置、方位、および動きを検出するためにある数のカメラを含むセンサまたはセンサを使用する。図示した実施形態例では、１つ以上のカメラまたはセンサが、視野１５０においてユーザの手１０１および１０２の位置、方位、および動きを検出するために使用される。尚、 ＳＯＥの範囲や主旨から逸脱することなく、ＳＯＥ１００がこれらよりも多いカメラ（例えば、６台のカメラ、８台のカメラ等）または少ないカメラ（例えば、２台のカメラ）とでも使用することができることは言うまでもない。加えて、実施形態例では、カメラまたはセンサは対称的に配置されるが、ＳＯＥにはこのような対称性の要件はない。ユーザの手の位置、方位、および移動を許容するのであれば、カメラまたはセンサは、いずれの数および位置付けでも、ＳＯＥ１００において使用することができる。

一実施形態では、使用されるカメラは、グレー・スケール画像を取り込むことができるモーション・キャプチャ・カメラである。一実施形態では、使用されるカメラは、Vicon MX40カメラのような、Vicon社が製造するカメラである。このカメラは、カメラ内部処理を含み、毎秒１０００フレームの画像キャプチャが可能である。モーション・キャプチャ・カメラは、マーカを検出しその位置を突き止めることができる。

説明した実施形態では、カメラは光学的検出に使用されるセンサである。他の実施形態では、カメラまたは他の検出器は、電磁、静磁気、ＲＦＩＤ、またはその他の任意の適した種類の検出に使用することができる。

プリプロセッサ１０５は、三次元空間点再現および骨格点ラベリングを生成するために使用される。ジェスチャ変換器１０６は、３Ｄ空間情報およびマーカ・モーション情報をコマンド言語に変換するために使用される。コマンド言語は、コンピュータ・プロセッサによって解釈され、ディスプレイ上におけるカーソルの位置、形状、および動作(action)を更新することができる。ＳＯＥ１００の代替実施形態では、プリプロセッサ１０５およびジェスチャ変換器１０６を統合して、または組み合わせて１つのデバイスにすることもできる。

コンピュータ１０７は、Apple社、Dell社、または任意のその他の適した製造業者によって製造されるような、任意の汎用コンピュータとすればよい。コンピュータ１０７は、アプリケーションを実行し、表示出力を供給する。カーソル情報は、他の場合にはマウスまたはその他の先行技術の入力デバイスから得られるが、ここではジェスチャ・システムから得られる。

マーカ・タグ
本明細書において説明した実施形態はマーカレス視覚系追跡システムを含むが、代替実施形態のＳＯＥは、本システムがユーザの手を突き止め、それが左手または右手のどちらを見ているのか、そしてどの指が見えるのか識別することができるように、ユーザの１本以上の指におけるマーカ・タグの使用も想定する。これによって、本システムは、ユーザの手の位置、方位、および移動を検出することが可能になる。この情報によって、本システムは多数のジェスチャを認識することが可能となり、これらのジェスチャは、ユーザによってコマンドとして使用することが可能になる。

一実施形態におけるマーカ・タグは基板（本実施形態では、人の手の上の種々の位置に装着するのに適している）と、基板の表面上に一意識別パターンで配列された離散マーカとを含む物理的タグである。

マーカおよび関連付けられた外部検知システムは、それらの三空間位置の高精度、正確、ならびに迅速および連続的捕獲が可能である任意のドメイン（光学、電磁、静磁気ドメイン等）において動作することができる。マーカ自体は、能動的（例えば、構造化した電磁パルスを放出することによって）、または受動的（例えば、本実施形態におけるように光学的に逆反射型とすることによって）のいずれでも動作することができる。

各捕獲フレームにおいて、検出システムは、器具を備え付けた作業空間立体（カメラまたはその他の検出器の可視範囲内）において現在タグからの全てのマーカを含む三空間位置を再現した、粒団状「クラウド」を受ける。各タグ上のマーカは、十分に多数であり、一意のパターンに配列されているので、検出システムは以下のタスクを行うことができる。（１）再現した各マーカ位置を、１つのタグを形成する点の１つのみの副集合体に割り当てるセグメント化、（２）セグメント化した点の各副集合体を特定のタグとして識別するラベリング、（３）識別したタグの三空間位置を再現する位置突き止め、および（４）識別したタグの三空間方位を再現する方位決定(orientation)。タスク（１）および（２）は、マーカ・パターンの具体的な本質によって可能となる。これについては、図１２の一実施形態において以下で説明し例示する。

一実施形態では、タグ上のマーカは、規則的な格子位置の部分集合に装着される。この基礎となる格子は、本実施形態のように、従来からのデカルト型であってもよいし、代わりに、他の何らかの規則的平面碁盤目状（例えば、三角形／六角形タイリング配列）であってもよい。格子のスケールおよび空間は、隣接する格子位置が混乱する可能性がないように、マーカ検知システムの既知の空間分解能に関して確定する。全てのタグについてのマーカ・パターンの選択は、次の制約を満たさなければならない。タグのパターンは、回転、平行移動、または鏡像(mirroring)のいずれの組み合わせによる他のいずれのタグ・パターンとも一致してはならない。更に、ある指定した数のコンポーネント・マーカの損失（または遮蔽(occlusion)が許容されるように、多数のマーカおよびその配列を選択するとよい。いずれの任意の変換後であっても、損なったモジュール(compromised module)を他のいずれとも混同させることが起こりそうにないようにしなければならない。

これより図１２を参照すると、多数のタグ２０１Ａ〜２０１Ｅ（左手）および２０２Ａ〜２０２Ｅ（右手）が示されている。各タグは、矩形であり、本実施形態では、５×７の格子アレイで構成される。矩形形状が選択されたのは、タグの方位を決定し易いため、そして鏡面複製(mirror duplicate)の可能性を低減するためである。図示の実施形態では、各手の指毎にタグがある。実施形態によっては、手毎に１つ、２つ、３つ、または４つのタグを使用することが適当である場合もある。各タグは、異なるグレー・スケールまたは色調の境界を有する。この境界の内部には、３×５格子アレイがある。マーカ（図１２の黒いドットで表す）は、情報を提供するために、この格子のある点に配置される。

各パターンを「共通」および「一意」のサブパターンにセグメント化することにより、タグのマーカ・パターンにおいて、認定情報(qualifying information)をエンコードすることができる。例えば、本実施形態は、２つの可能な「境界パターン」、矩形境界線(boundary)を中心としたマーカの分布を指定する。つまり、タグの「ファミリー」を確立する。このため、左手を意図したタグは、タグ２０１Ａ〜２０１Ｅにおいて示されるような同じ境界パターンを全て使用することができ、一方右手の指に取り付けられているタグには、タグ２０２Ａ〜２０２Ｅに示すように異なるパターンを割り当てることができる。タグの全ての方位において、左パターンを右パターンから区別できるように、このサブパターンを選択する。図示した例では、左手パターンは、各角に１つのマーカ、そして角格子位置から２番目に１つのマーカを含む。右手パターンは、２つの角のみにマーカを有し、角でない格子位置に２つのマーカを有する。このパターンを検査することによって、４つのマーカの内いずれか３つが見ることができる限り、左手パターンを右手パターンから明確に区別することができることが明らかとなった。一実施形態では、境界の色または色調も、利き手(handedness)のインディケータとして使用することができる。

各タグは、勿論、一意の内部パターンを採用し続けなければならず、マーカはそのファミリーの共通境界以内に分散される。図示の実施形態では、内部格子アレイにおける２つのマーカが、１０本の指の各々を一意に特定するのに十分であり、指の回転または方位による複製が生じないことが分かる。マーカの１つが遮蔽されたとしても、タグのパターンおよび利き手の組み合わせから、一意の識別子が得られる。

本実施形態では、格子の位置は、各逆反射マーカをその意図する位置に装着する（手作業の）タスクに対する補助として、視覚的に剛性基板上に存在する。これらの格子および意図するマーカ位置は、カラー・インクジェット・プリンタによって基板上にそっくりそのまま印刷される。ここでは、基板はシート状の（初期状態では）可撓性の「収縮フィルム」である。各モジュールがこのシートから切り離され、炉で焼成される。この熱処理の間に、各モジュールには正確で繰り返し可能な収縮が起こる。この手順に続く短い間隔において、冷却するタグには、例えば、指の長手方向曲線にしたがって、僅かに形状を付けることができる。その後、基板は適度に剛性となり、マーカを、指示された格子点に装着することができる。

一実施形態では、マーカ自体は、接着剤または何らかのその他のしかるべき手段によって基板に装着された小さな反射球体のように、三次元である。このマーカが三次元であることは、二次元マーカ上における検出および位置突き止めに役立つことができる。しかしながら、いずれも、本明細書に記載するＳＯＥの主旨や範囲から逸脱することなく使用することができる。

現在では、タグはベルクロ(Velcro（登録商標）)またはその他のしかるべき手段によって、操作者が身に付けている手袋に装着されるか、あるいは、柔らかな両面テープを使用して操作者の指に直接装着される。第３実施形態では、剛性基板を全くなしで済ませ、操作者の指および手に直接個々のマーカを装着するまたは「描く」することができる。
ジェスチャ・ボキャブラリ
一実施形態のＳＯＥは、手のポーズ、方位、手の組み合わせ、および方位の配合(orientation blends)を含むジェスチャ・ボキャブラリ(gesture vocabulary)を想定する。ＳＯＥのジェスチャ・ボキャブラリにおいてポーズおよびジェスチャを立案および伝達するために、表記言語(notation language)も実施する。ジェスチャ・ボキャブラリとは、力学的連結の瞬時的な「ポーズ状態」を簡潔な文字形態で表すシステムである。対象となる連結は、生物（例えば、人の手、または人の身体全体、あるいはバッタの足、あるいはキツネザルの関節脊柱）であってもよく、あるいは代わりに非生物であってもよい（例えば、ロボットのアーム）。

いずれの場合でも、この連結は、単純（脊柱）でもまたは分岐（手）でもよい。ＳＯＥのジェスチャ・ボキャブラリ・システムは、いずれの特定的な連結についても、一定長のストリングを確立する。こうして、ストリングの「キャラクタ位置」を占める特定のＡＳＣＩＩキャラクタの集合体が、連結の瞬時的状態、即ち、「ポーズ」の一意の記述となる。

手のポーズ
図１３は、ＳＯＥを使用したジェスチャ・ボキャブラリの一実施形態における手のポーズを示す。ＳＯＥは、１本の手における５本の指の各々を使用することを仮定する。これらの指には、ｐ−小指、ｒ−薬指、ｍ−中指、ｉ−人差し指、およびｔ−親指とコーディングする。図１３には、指および親指の多数のポーズが、一実施形態のジェスチャ・ボキャブラリにおいて定義され例示される。ジェスチャ・ボキャブラリ・ストリングは、連結（この場合指）の表現可能な自由度毎に１つのキャラクタ位置を確定する。更に、このような各自由度は、離散化（または「量子化」）されることが分かるので、その最大運動範囲は、当該ストリング位置における有限数の標準的ＡＳＣＩＩキャラクタの内の１つの割り当てによって表現することができる。これらの自由度は、本体特定の原点および座標系（手の裏、バッタの身体の中心、ロボット・アームの底辺等）に関して表現される。したがって、連結の位置および方位を「全体的に」更に大域的な座標系において表現するために、少数の追加のジェスチャ・ボキャブラリ・キャラクタ位置が使用される。

引き続き図１３を参照すると、多数のポーズが定義されており、ＡＳＣＩＩキャラクタを使用して識別される。これらのポーズの一部は、親指およびそれ以外の指の間で分けられている。この実施形態におけるＳＯＥは、ＡＳＣＩＩキャラクタ自体がポーズを示唆するようなコーディングを使用する。しかしながら、示唆的であろうがなかろうが、ポーズを表すには、いずれのキャラクタでも使用することができる。加えて、本発明では、表記ストリングにＡＳＣＩＩキャラクタを使用する必要性はない。本発明の範囲や主旨から逸脱することなく、適したシンボル、数値、またはその他の表現であればいずれでも使用することができる。例えば、望ましければ、表記は指毎に２ビットを使用することもでき、あるいは所望に応じて、他の何らかの数のビットを使用することもできる。

巻き込んだ指(curled finger)は、キャラクタ「＾」によって表され、一方巻き込んだ親指は「＞」で表される。真っ直ぐな指または上を向いた親指は、「ｌ」によって示され、角度をなす場合は「＼」または「／」で示される。「−」は、真っ直ぐに横を向いた親指を表し、「ｘ」は平面内に向いた親指を表す。

これら個々の指および親指の記述を使用すると、確固不動の数(robust number)の手のポーズを、本発明の方式を使用して、定義し記述することができる。各ポーズは、５つのキャラクタによって表され、その順序は、前述したように、ｐ−ｒ−ｍ−ｉ−ｔとなる。手を平らにして地面に平行に保持する場合、「ｌｌｌｌｌ」で表される。握り拳は「＾＾＾＾＞」によって表される。「ＯＫ」の合図は、「ｌｌｌ＾＞」によって表される。

キャラクタ・ストリングは、示唆的キャラクタを使用する場合、単純な「人間可読性」(human readability)の機会を与える。各自由度を記述する１組の可能なキャラクタは、総じて、素早い認識および明白な類似性に着目して選択することができる。例えば、垂直線（「｜」）は、連結エレメントが「直線状」であることを意味するように思われ、エル（「Ｌ」）は、９０度の屈曲を意味することもでき、曲折アクセント記号（「＾」）は、鋭角の屈曲を示すことができる。先に注記したように、所望に応じて、いずれのキャラクタまたはコーディングでも使用することができる。

本明細書に記載するようなジェスチャ・ボキャブラリ・ストリングを採用するシステムはいずれも、ストリング比較の高い計算効率の恩恵を享受する。指定されたいずれのポーズについても、その識別または検索は、文字どおり、所望のポーズ・ストリングと瞬時的な実際のストリングとの間における「ストリングの比較」（例えば、ＵＮＩＸ（登録商標）の「stremp()」関数）となる。更に、「ワイルドカード・キャラクタ」の使用によって、プログラマやシステム設計者には、もっと見慣れた効率(efficiency)および有効性(efficacy)が得られる。自由度の瞬時状態が一致とは関わりがない場合、疑問符（「？」）として指定することができ、追加のワイルド・カードの意味を割り当てることができる。

方位
指および親指のポーズに加えて、手の方位が情報を表すことができる。大域空間(global-space)方位を記述するキャラクタも、透過的に選択することができる。キャラクタ「＜」、「＞」、「＾」、および「ｖ」は、方位キャラクタ位置において遭遇した場合、左、右、上、および下の考えを示すために使用することができる。図１４は、手方位記述子、ならびにポーズおよび方位をコード化する例を示す。一実施形態では、２つのキャラクタ位置が、最初に手の平の方向を指定し、次いで指の方向を指定する（指が真っ直ぐになっている場合、指の実際の屈曲には関係なく）。これら２つの位置に可能なキャラクタは、方位の「本体中心」観念(body-centric notion)を表現し、「−」、「＋」、「ｘ」、「＊」、「＾」、および「ｖ」は、中間、横方向、前方（順方向、本体から離れる側）、後方（逆方向、本体から離れる側）、頭上（上方）、および後端（下方）を記述する。

本発明の表記方式および実施形態では、キャラクタを示す５本指のポーズに続いて、コロン、次いで完全なコマンド・ポーズを定義するために２つの方位キャラクタがある。一実施形態では、開始位置は「ｘｙｚ」ポーズと呼ばれ、親指は真っ直ぐ上を指し示し、人差し指は前方を指し示し、中指は人差し指に対して垂直であり、右手によってこのポーズが作られる場合、左を指し示す。これは、ストリング「＾＾ｘｌ−：−ｘ」によって表される。

「ＸＹＺ−手」は、視覚的に提示された三次元構造の最大６自由度のナビゲーションを可能にするために、人の手の幾何学的形状を利用する技法である。この技法は操作者の手の全体的(bulk)平行移動および回転のみに依存し、したがってその指は原則として、いずれの所望のポーズに保持することができるが、本実施形態は、人差し指が本体から離れる方向を指し、親指が天井を指し、中指が左−右を指す、静止構成(static configuration)を優先する。つまり、これら３本の指は、三空間座標系の３本の相互に直交する軸、つまり、「ＸＹＺ−手」を記述する（大まかであるが、明白な歴然とした趣旨がある）。

次いで、ＸＹＺ−手ナビゲーションは、操作者の身体の前において所定の「中立位置」に保持された、前述のようなポーズの手、指に進む。三空間物体（またはカメラ）の三平行移動および三回転自由度へのアクセス(access)は以下の自然な方法で行われる。手の右−左移動（身体の自然座標系に対して）により、計算的コンテキストのｘ−軸に沿った移動が生じ、手の上下移動により、被制御コンテキストのｙ−軸に沿った移動が生じ、前後の手の移動（操作者の身体に向かう方向／から離れる方向）によって、このコンテキストにおけるｚ−軸運動が生ずる。同様に、人差し指を中心とする操作者の手の回転により、計算的コンテキストの方位の「転動」(roll)変化が生じ、操作者の手の中指および親指をそれぞれ中心とする回転によって、「縦方向」および「横方向」変化が類似的に生ずる。

尚、「計算的コンテキスト」は、本明細書では、ＸＹＺ−手方法によって制御される全体に言及するために使用されており、合成三空間物体またはカメラのいずれかを示唆するように思われるが、この技法は実世界物体の種々の自由度を制御するため、例えば、しかるべき回転アクチュエータを装備したビデオまたはモーション・ピクチャ・カメラのパン／ティルト／ロール制御にも等しく有用であることは言うまでもないことを注記しておく。更に、ＸＹＺ−手の姿勢によって得られる物理的自由度は、仮想ドメインであっても、ありのままにマッピングされ難い場合もある。本実施形態では、ＸＹＺ−手は、大きな全景的表示画像に対してナビゲーション的アクセスを提供するためにも使用されるので、操作者の手の左−右および上−下の運動が、画像を中心とする予期された左−右または上−下「パンニング」に繋がるが、操作者の手の前−後運動は「ズーミング」制御にマッピングする。

あらゆる場合において、手の運動と誘発される計算的平行移動／回転との間の結合は、直接的（即ち、操作者の手の位置的または回転オフセットが、一対一で、何らかの線形または非線形関数によって、計算的コンテキストにおける物体またはカメラの位置的または回転オフセットにマッピングする）、または間接的（即ち、操作者の手の位置的または回転オフセットが、一対一で、何らかの線形または非線形関数によって、計算的コンテキストにおける位置／方位の第１導関数またはより上位の導関数にマッピングし、実行中の積分が、計算的コンテキストの実際のゼロ次位置／方位における被静的変化を生み出す）のいずれかであることができる。この後者の制御手段は、自動車の「アクセル・ペダル」の使用に類似しており、ペダルの一定のオフセットによって、ほぼ一定の車速が得られる。

実世界のＸＹＺ−手の局所的六自由度座標原点としての役割を果たす「中立位置」は、（１）空間における絶対位置および方位として（例えば、密閉室に対する）、（２）操作者の全体的な位置および「方向」(heading)には関係なく、操作者自身に対する固定位置および方位（例えば、身体の前方８インチ、顎の下１０インチ、横方向に肩の平面と一直線状）として、あるいは（３）操作者の故意の二次的行動によって、対話的に（例えば、操作者の「別の」手によって演じられるジェスチャ・コマンドを使用して。前記コマンドは、ＸＹＺ−手の現在の位置および方位が今後平行移動および回転の原点として使用されるべきことを示す）確立することができる。

更に、ＸＹＺ−手の中立位置の周囲に「抑止」(detent)領域（または「デッド・ゾーン」）を設けて、この立体空間における移動が被制御コンテキストにおける移動にマッピングしないようにすると便利である。

他のポーズも含むことができる。
[lllll:vx]は、手を平らにして（親指が他の指と平行）、手のひらが下を向き、指が前方に突き出している。
[lllll:x^]は、手を平らにして、手のひらが前を向き、指が天井を向いている。
[lllll:-x]は、手を平らにして、手のひらが身体の中心に向いており（左手の場合は右、右手の場合は左）、指が前方に突き出している。
[^^^^-:-x]は、手を１つにして親指を合わしている（親指は天井を向いている）。
[^^^|-:-x]は、銃を前方に構える真似である。

２つの手の組み合わせ
一実施形態のＳＯＥは、１つの手のコマンドおよびポーズだけでなく、２つの手によるコマンドおよびポーズも想定する。図１５は、一実施形態の下における、ＳＯＥのジェスチャ・ボキャブラリにおける二手組み合わせおよび関連する表記の例を示す。第１の例の表記を検討すると、「完全停止」とは２つの拳を閉じていることを示す。「スナップショット」の例では、各手の親指および人差し指が広げられ、親指が互いに向き合って、ゴール・ポストの形状の枠を定めている。「舵およびスロットル開始位置」は、指および親指が上を向いており、手のひらが画面に面している。

方位配合
図１６は、一実施形態の下における方位配合の一例を示す。図示の例では、配合は、指ポーズ・ストリングの後ろにある括弧の中に囲まれた方位表記の対によって表される。例えば、第１コマンドは、全て真っ直ぐに伸ばした指の位置を示す。方位コマンドの第１対により、手のひらをディスプレイに向かって平らにして、第２対によって、手を画面に向けて４５度縦に回転させる。この例では、配合の対を示したが、ＳＯＥではいずれの数の配合でも考えられる。

コマンド例
図１８／１および図１８／２は、ＳＯＥと共に使用することができる、多数の可能なコマンドを示す。本明細書における論述の一部は、ディスプレイ上におけるカーソルの制御についてであったが、ＳＯＥはその行動に限定されるのではない。実際に、ＳＯＥは、画面上における全てのデータおよびデータの一部、更にはディスプレイの状態を操作する際に、様々に応用することができる。例えば、ビデオ・メディアの再生中に、これらのコマンドをビデオ制御に代わって使用することができる。これらのコマンドは、一時停止、早送り、巻き戻しなどを行うために使用することができる。加えて、画像のズーム・インおよびズーム・アウトを行うため、画像の方位を変化させるため、いずれかの方向にパンニングするため等に実施することができる。また、ＳＯＥは、開く、閉じる、保存する等のような、メニュー・コマンドの代わりに使用することもできる。言い換えると、想像することができるいずれのコマンドまたは活動でも、手のジェスチャによって実施することができる。

動作
図１７は、一実施形態におけるＳＯＥの動作を示す流れ図である。ステップ７０１において、検出システムはマーカおよびタグを検出する。判断ブロック７０２において、タグおよびマーカが検出されたか否か判断を行う。検出されていない場合、システムはステップ７０１に戻る。ステップ７０２においてタグおよびマーカが検出された場合、システムはステップ７０３に進む。ステップ７０３において、システムは、検出されたタグおよびマーカから、手、指、およびポーズを識別する。ステップ７０４において、システムは、ポーズの方位を識別する。ステップ７０５において、システムは、検出された１つまたは双方の手の三次元空間位置を識別する。（ステップ７０３、７０４、および７０５の内いずれでも、または全てを１つの動作として組み合わせてもよいことに注意されたい）。

ステップ７０６において、以上の情報を、前述したジェスチャ表記に変換する。判断ブロック７０７において、ポーズが有効か否か判断を行う。これは、生成した表記ストリングを使用した単純なストリング比較によって行うことができる。ポーズが有効でない場合、システムはステップ７０１に戻る。ポーズが有効である場合、ステップ７０８において、システムは表記および位置情報をコンピュータに送る。ステップ７０９において、コンピュータは、ジェスチャに応答して、取るべきしかるべき行為を決定し、ステップ７１０においてそれに応じてディスプレイを更新する。

ＳＯＥの一実施形態では、動作７０１〜７０５をカメラ内蔵プロセッサによって実行する。他の実施形態では、望ましければ、この処理をシステム・コンピュータによって実行することもできる。
解析および変換
本システムは、基礎となるシステムによって再現された低レベルのジェスチャの流れを「解析」および「変換」し、これら解析し変換したジェスチャを、コマンドまたはイベント・データの流れに変換することができる。このデータは、広範囲のコンピュータ・アプリケーションおよびシステムを制御するために使用することができる。これらの技法およびアルゴリズムは、これらの技法を実現するエンジン、およびエンジンの能力を利用するコンピュータ・アプリケーションを構築するプラットフォームの双方を提供するコンピュータ・コードから成るシステムにおいて具体化することができる。

一実施形態は、コンピュータ・インターフェースにおいて、人の手の豊富なジェスチャの使用を可能にすることを中心に据えるが、他の身体部分によって行われるジェスチャ（限定ではなく、腕、胴体、脚部、および頭部を含む）や、手ではない種々の器具によって行われるジェスチャを認識することもできる。これらの器具は、静止および連結式(articulating)双方であり、限定ではないが、キャリパ、コンパス、可撓性曲線近似器(curve approximator)、および種々の形状のポインティング・デバイスが含まれる。マーカおよびタグは、操作者によって所望に応じて携行および使用することができる品目および器具に被着することができる。

本明細書において記載するシステムは、認識し反応することができるジェスチャの範囲が豊富なジェスチャ・システムを構築することを可能にしつつ、同時にアプリケーションへの容易な統合にも備えた、多数の改革を組み込む。

一実施形態では、ジェスチャ解析および変換システムは、以下のものを備えている。

１）様々な異なる集計レベルにおいて、ジェスチャを指定する（コンピュータ・プログラムにおいて使用するためのエンコード）緻密かつ効率的な方法。

ａ．１本の手の「ポーズ」（手の部分の外形および互いに対する方位）。三次元空間における１つの手の方位および位置。
ｂ．２つの手の組み合わせ。いずれかの手がポーズ、位置、または双方を考慮に入れる。
ｃ．多数の人物の組み合わせ。本システムは２つよりも多い手を追跡することができ、したがって、一人よりも多い事物が協同して（ゲーム・アプリケーションの場合には競合して）目標システムを制御することができる。
ｄ．ポーズが連続して組み合わされる順次ジェスチャ。これらを「動画」ジェスチャと呼ぶ。
ｅ．操作者が空間内の形状を追跡する「書記素」ジェスチャ(grapheme gesture)。

２）所与のアプリケーション・コンテキストに関連があるものの上で、各カテゴリから特定のジェスチャを登録するプログラム技法。

３）登録されたジェスチャを識別することができ、これらのジェスチャをカプセル化するイベントを関連するアプリケーション・コンテキストに配信することができるように、ジェスチャの流れを解析するアルゴリズム。

指定システム（１）は、構成エレメント（１ａ）から（１ｆ）と共に、本明細書に記載するシステムのジェスチャ解析および変換能力を利用するための基礎を提供する。

１本の手の「ポーズ」は、
ｉ）手の指と甲との間の相対的方位、
ｉｉ）少数の離散状態への量子化、
のストリングとして表される。

相対的接合方位を使用することにより、本明細書に記載するシステムは、手のサイズおよび外形形状が異なることに伴う問題を回避することができる。このシステムでは、「操作者較正」を必要としない。加えて、ポーズをストリングまたは相対的方位の集合体として指定することにより、ポーズ表現を更に別のフィルタおよび指定と組み合わせることによって、一層複雑なジェスチャ指定(specification)を容易に作成することが可能になる。

ポーズ指定に少数の離散状態を使用することによって、ポーズを簡潔に指定することができ、更に種々の基礎となる追跡技術（例えば、カメラを使用した受動的光学追跡、点灯ドットおよびカメラを使用した能動的光学追跡、電磁場追跡等）を使用して、精度の高いポーズ認識を確実に行うことができる。

各カテゴリ（１ａ）から（１ｆ）におけるジェスチャは、部分的に（または最小限に）指定することができるので、重大でないデータは無視される。例えば、２本の指の位置が明確であり他の指の位置は重要でないジェスチャは、２本の関連のある指の動作位置が与えられ、同じストリング内において、「ワイルド・カード」または包括的「無視」インディケータが他の指に対して掲示された１つの指定によって表すことができる。

本明細書において記載するジェスチャ認識のための改革の全ては、限定ではなく、多層指定技法、相対的方位の使用、データの量子化、および各レベルにおける部分的または最小指定の許容を含み、手のジェスチャの指定を超えて、他の身体部分や「製造した」器具および物体を使用したジェスチャの指定に一般化する。

「ジェスチャを登録する」プログラム技法（２）は、どのジェスチャをエンジンが実行システムの他の部分に入手可能にすべきか定めることをプログラマに可能にする、定められた１組のアプリケーション・プログラミング・インターフェース・コールによって構成される。

これらのＡＰＩルーチンは、アプリケーション設定時に使用することができ、実行アプリケーションの寿命の間使用することができる静止インターフェース定義を作成する。また、これらは、実行中にも使用することができ、インターフェース特性を動作中に変更することができる。このリアル・タイムでのインターフェース変更により、
ｉ）複雑なコンテキストおよび条件付き制御状態を構築すること、
ｉｉ）動的にヒステリシスを制御環境に追加すること、および
ｉｉｉ）ユーザが実行システム自体のインターフェース・ボキャブラリを変更または拡張することができるアプリケーションを作成すること、
が可能となる。

ジェスチャの流れを解析するアルゴリズム（３）は、（１）におけるように指定され（２）におけるように登録されたジェスチャを、入来する低レベルのジェスチャ・データと比較する。登録されたジェスチャに対する一致が認識された場合、一致したジェスチャを表すイベント・データが積層され実行アプリケーションに配信される。

このシステムの設計においては、効率的なリアル・タイムでの照合が望まれ、指定されたジェスチャは、できるだけ素早く処理される可能性のツリーとして扱われる。

加えて、指定されたジェスチャを認識するために内部で使用される原始的比較演算子は、アプリケーション・プログラマが使用するためにも露出されるので、アプリケーション・コンテキスト内部からでも、より多くの比較（例えば、複雑なジェスチャまたは複合ジェスチャにおける柔軟な状態の検査）を行うことができる。

認識「ロッキング」セマンティクス(recognition locking semantics)は、本明細書に記載するシステムの改革の１つである。これらのセマンティクスは、登録ＡＰＩ（２）（および、より狭い範囲で、指定ボキャブラリ（１）内に埋め込まれる）によって暗示される(imply)。登録ＡＰＩコールは、
ｉ）「エントリ」状態通知部および「連続」状態通知部、ならびに
ｉｉ）ジェスチャ優先度指定部
を含む。

ジェスチャが認識された場合、その「連続」状態は、同じまたは低い優先度のジェスチャの全ての「エントリ」状態よりも優先される。このエントリ状態と連続状態との間の区別は、認められるシステム使用可能性に大きくプラスになる。

本明細書において記載するシステムは、実世界のデータ・エラーおよび不確実性をものともせずに、ロバストな動作のためのアルゴリズムを含む。低レベル追跡システムからのデータは不完全である場合もある（光学追跡におけるマーカの遮蔽、ネットワーク・ドロップアウト、処理の遅れ等を含む、種々の理由による）。

欠損データは、解析システムによって印が付けられ、その欠損データの量およびコンテキストに応じて、「最後に分かっていた」状態または「最もあり得る」状態のいずれかに組み込まれる。

特定のジェスチャ・コンポーネント（例えば、特定の関節の方位）についてのデータが見つからないが、その特定のコンポーネントの「最後に分かっていた」状態を、物理的に可能であると分析することができる場合、本システムはこの最後に分かっていた状態をそのリアル・タイム照合において使用する。

逆に、最後に分かっていた状態が、物理的に不可能であると分析された場合、本システムはそのコンポーネントにとって「最良のジェスチャ範囲」に後退し、この合成データをそのリアル・タイム照合において使用する。

本明細書において記載する指定および解析システムは、「利き手不可知論」をサポートするように注意深く設計されるので、多数の手のジェスチャについて、いずれの手でもポーズの要件を満たすことができる。
同時仮想／表示および物理空間
一実施形態のシステムは、１つ以上のディスプレイ・デバイス（「画面」）上に描かれた仮想空間を、当該システムの一人または複数の操作者によって占められる物理空間と一致するものとして扱う環境を提供することができる。このような環境の一実施形態についてここで説明する。この現実施形態は、固定位置に３つのプロジェクタ駆動画面を含み、１つのデスクトップ・コンピュータによって駆動され、本明細書に記載したジェスチャ・ボキャブラリおよびインターフェース・システムを使用して制御される。しかしながら、記載する技法は、いかなる数の画面でもサポートすること、これらの画面は移動可能であってもよいこと（固定ではなく）、画面は多くの独立したコンピュータによって同時に駆動してもよいこと、そしてシステム全体はいずれの入力デバイスまたは技法によっても制御できることを注記しておく。

本開示において記載するインターフェース・システムは、物理空間における画面の寸法、方位、および位置を決定する手段を有していなければならない。この情報を仮定して、本システムは、これらの画面が配置される（そして、本システムの操作者が占める）物理空間を、本システム上で実行しているコンピュータ・アプリケーションの仮想空間への投影として動的にマッピングすることができる。この自動マッピングの一部として、本システムは、システムによってホストされるアプリケーションの必要性に応じて、種々の方法で２つの空間の規模、角度、深さ、寸法、およびその他の空間特性も変換する。

この物理空間と仮想空間との間における連続変換によって、既存のアプリケーション・プラットフォームでは達成が困難である、または既存のプラットフォーム上で実行するアプリケーション毎に１つ１つ実装しなければならない多数のインターフェース技法の一貫性があり普及する使用が可能となる。これらの技法は、（限定ではないが）以下を含む。

１）「リテラル・ポインティング」(literal pointing)の広く行き渡る自然なインターフェース技法としての使用。ジェスチャ・インターフェース環境において手を使用するか、あるいは物理的ポインティング・ツールまたはデバイスを使用する。
２）画面の移動または再位置決めに対する自動補償。
３）操作者の位置に応じて変化するグラフィクス・レンダリング。例えば、深度の知覚を高めるためにパララックス・シフトをシミュレーションする。
４）実世界位置、方位、状態等を考慮に入れた、画面上表示への物理的オブジェクトの含入。例えば、大きく不透明な画面の前に立っている操作者は、アプリケーションのグラフィクスと、画面の背後にある（そして、恐らく移動しているか、または方位を変えている）スケール・モデル(scale model)の真の位置の表現との双方を見ることができる。

リテラル・ポインティングは、マウスに基づくウィンドーイング・インターフェースや殆どのその他の現在のシステムにおいて使用される絶対ポインティングとは異なることを注記するのは重要である。これらのシステムでは、操作者は仮想ポインタと物理ポインティング・デバイスとの間の変換を管理することを学習しなければならず、更にこれら２つの間で経験的知識に基づいてマッピングしなければならない。

対照的に、本開示において記載するシステムでは、アプリケーションまたはユーザの観点のいずれからでも、仮想空間と物理空間との間に差がないので（仮想空間の方が数学的操作がし易いことを除く）、操作者に経験的知識に基づく変換は必要とされない。

本明細書において記載する実施形態によって提供されるリテラル・ポインティングに最も近い類似性は、接触感応画面（例えば、多くのＡＴＭ機械上で見られる）である。接触感応画面は、画面上の二次元表示空間と画面表面の二次元入力空間との間に１対１のマッピングを規定する。同様に、本明細書において記載するシステムは、１つ以上の画面上に表示される仮想空間と、操作者によって占められる物理空間との間に柔軟なマッピング（１対１のマッピングも可能であるが、その必要性はない）を規定する。この類似性の有益さ(usefulness of the analogy)にも拘わらず、この「マッピング手法」の三次元、任意に大きなアーキテクチャ環境、および多数の画面への拡張は重要である。

本明細書において記載するコンポーネントに加えて、本システムは、環境の物理空間と各画面上の表示空間との間に連続的なシステム・レベルのマッピング（恐らく回転、平行移動、倍率調整、またはその他の幾何学的変換によって変更される）を実現するアルゴリズムも実装することができる。

レンダリング・スタックは、計算オブジェクトおよびマッピングを取り込み、仮想空間のグラフィカル表現を出力する。

入力イベント処理スタックは、制御システムからイベント・データを取り込み（現実施形態では、システムおよびマウス入力からのジェスチャ・データおよびポインティング・データの双方）、入力イベントからの空間データを仮想空間における座標にマッピングする。次いで、変換されたイベントは、実行中のアプリケーションに配信される。

「グルー・レイヤ」は、システムが、ローカル・エリア・ネットワークにある数台のコンピュータに跨って実行するアプリケーションをホストすることを可能にする。

データ表現、移行、および交換
ＳＯＥ即ち空間連続入力システムの実施形態について説明する。ここでは、以下で詳しく説明するが、このシステムは、サブシステム「スロークス」、「プロテイン」、および「プール」を構成する「プラズマ」と呼ばれるシステムを含む、ネットワーク系データ表現、移行、および交換を含む。プールおよびプロテインは、プロセス間でまたはプロセスを跨いで共有すべきデータをカプセル化するために、本明細書において説明する方法およびシステムのコンポーネントである。また、これらのメカニズムは、プロテインおよびプールの他に、スロークス（「スロー」(slaw)の複数形）も含む。一般に、スロークスは、プロセス間交換についての最も低いレベルのデータ定義を規定し、プロテインは、中間レベルの構造を規定し、照会(querying)およびフィルタリングを担い(hook for)、プールは、高レベルの編成およびアクセス・セマンティクスを規定する。スロークスは、効率的で、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、スロークスをペイロードとして使用して、データ・カプセル化および輸送方式を規定する。プールは、ローカル・プロセッサ間での、リモートまたは分散プロセス間にあるネットワークを跨いだ、そして「長期」（例えば、ディスク上等における）記憶を通じた、プロセス内におけるプロテインの構造化されるが柔軟な集計、順序付け、フィルタリング、および分散を規定する。

本明細書に記載する実施形態の構成および実施態様は、様々な構造(construct)を含み、これらが一緒になって多数の能力を可能にする。例えば、本明細書において記載する実施形態は、前述のように大多数のプロセス間における効率的な交換に備えている。また、本明細書において記載する実施形態は、柔軟なデータ「タイピング」(typing)および構造にも備えているので、広範囲にわたる多様な種類のデータおよび使用をサポートする。更に、本明細書において記載する実施形態は、データ交換のための柔軟なメカニズム（例えば、ローカル・メモリ、ディスク、ネットワーク等）を含み、これらは全て実質的に同様のアプリケーション・プログラミング・インターフェース（ＡＰＩ）によって駆動される。更に、本明細書において記載する実施形態は、異なるプログラミング言語で書かれたプロセス間におけるデータ交換を可能にする。加えて、本明細書において記載する実施形態は、データ・キャッシュおよび集計状態の自動的な保守を可能にする。

図１９は、一実施形態の下において、スロークス、プロテイン、およびプールを使用したデータ表現を含む処理環境のブロック図である。本明細書において紹介する実施形態の主要な構造には、スロークス（「スロー」(slaw)の複数形）、プロテイン、およびプールが含まれる。本明細書において記載する場合、スロークスは、効率的で、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、本明細書において詳細に説明するように、データ・カプセル化および輸送方式を規定し、一実施形態のプロテインのペイロードはスロークスを含む。プールは、本明細書において記載する場合、プロテインの構造化されるが柔軟な集計、順序付け、フィルタ処理、および分散を規定する。プールは、プロテインのための、プロセス内部における、ローカル・プロセッサ間での、リモートまたは分散プロセス間にあるネットワークを跨いだ、そして「長期」（例えば、ディスク上）記憶による、データへのアクセスを与える。

図２０は、一実施形態の下におけるプロテインのブロック図である。プロテインは、長さヘッダ、ディスクリップ(descrip)、およびインジェスト(ingest)を含む。以下で詳細に説明するが、ディスクリップおよびインジェストの各々は、スローまたはスロークスを含む。

図２１は、一実施形態の下におけるディスクリップのブロック図である。以下で詳細に説明するが、ディスクリップは、オフセット、長さ、およびスロークスを含む。

図２２は、一実施形態の下におけるインジェストのブロック図である。以下で詳細に説明するが、インジェストは、オフセット、長さ、およびスローを含む。

図２３は、一実施形態の下におけるスローのブロック図である。以下で詳細に説明するが、スローは、タイプ・ヘッダ、およびタイプ特定データを含む。

図２４Ａは、一実施形態の下における、プールの中にあるプロテインのブロック図である。プロテインは、長さヘッダ（「プロテイン長」）、ディスクリップ・オフセット、インジェスト・オフセット、ディスクリップ、およびインジェストを含む。ディスクリップは、オフセット、長さ、およびスローを含む。インジェストは、オフセット、長さ、およびスローを含む。

プロテインは、本明細書において記載する場合、プロセッサ間で共有する、あるいはバスまたはネットワークまたはその他の処理構造を跨いで移動する必要があるデータをカプセル化するメカニズムのことである。一例として、プロテインは、ユーザ・インターフェース・イベントに対応するまたは関連するデータを含むデータの輸送および操作のための改良メカニズムを提供する。具体的には、一実施形態のユーザ・インターフェース・イベントは、先に説明したジェスチャ・インターフェースのそれを含む。更に別の例として、プロテインは、限定ではく、グラフィクス・データまたはイベント、および状態情報等その他多数を含むデータの輸送および操作のための改良メカニズムを提供する。プロテインは、構造化レコード・フォーマット、およびレコードを操作するための１組の関連方法である。本明細書において使用する場合、レコードの操作は、データを構造に入力すること、構造からデータを取り出すこと、およびデータのフォーマットおよび存在を問い合わせることを含む。プロテインは、種々のコンピュータ言語で書かれたコードを通じて使用されるように構成される。また、プロテインは、本明細書において記載するような、プールの基本的構築ブロックとなるように構成される。更に、プロテインは、それらが含むデータを不変のまま維持しつつ、プロセッサ間そしてネットワークを跨いで自然に移動できるように構成される。

従来のデータ輸送メカニズムとは対照的に、プロテインにはタイプが決められていない。タイプは決められていないが、プロテインは、「タイプ状」機能を実装することに加えて、強力で柔軟性のあるパターン照合装置(facility)を備えている。また、本明細書に記載するように構成されたプロテインは、本質的に多点型でもある（しかし、二点間形態も、多点伝送の部分集合として容易に実現される）。加えて、プロテインはメモリ内、ディスク上、およびワイヤ（ネットワーク）上フォーマット間で異なることがない「ユニバーサル」レコード・フォーマットを定義する（即ち、実行する任意の最適化の種類だけが異なる）。

図２０および図２４Ａを参照すると、一実施形態のプロテインは、バイトの線形シーケンスである。これらのバイトの中には、ディスクリップ・リストと、１組のキー値対がカプセル化される。キー値対をインジェストと呼ぶ。ディスクリップ・リストは、綿密(elaborate)であるが効率的にフィルタ可能なプロテイン毎のイベント記述を任意に含む。インジェストは、１組のキー値対を含み、これらがプロテインの実際の内容を構成する。

プロテインのキー値対との関わり、ならびにネットワークに都合がよい(network-friendly)多点データ相互交換に関する中核的観念の一部は、「タプル」の概念を特別に許可する(priviledge)もっと簡単なシステム（例えば、Linda、Jini）と共有される。プロテインは、タプル指向システムとは様々な面で大きく異なり、その相違には、標準的、最適化可能なパターン照合基盤を設けるためにディスクリップ・リストを使用することが含まれる。また、プロテインがタプル指向システムと異なるのは、種々の記憶および言語構造に適したレコード・フォーマットの厳格な仕様、そしてそのレコード・フォーマットに対する「インターフェース」の色々な特定的な実施態様である。

プロテインの説明に戻って、プロテインの最初の４バイトまたは８バイトは、プロテインの長さを指定する。一実施形態では、長さは１６バイトの倍数でなければならない。この１６バイトの粒度により、バイト整合およびバス整合効率が現在のハードウェアでも達成可能であることを確保する。本来「４ワード整合」型でないプロテインには、任意のバイトを詰めこんで、その長さが１６バイトの倍数となるようにする。

プロテインの長さ部分は、次のフォーマットを有する。ビッグ・エンディアン・フォーマット(big-endian format)で長さを指定する３２ビット。その下位４ビットはマクロ・レベルのプロテイン構造特性を示すフラグとして機能する。プロテインの長さが２＾３２バイトよりも大きい場合、その次に来る更に別の３２ビット。

一実施形態における１６バイト整合条件は、最初の４バイトの最下位ビットがフラグとして利用可能であることを意味する。そして、このため、最下位の３ビット・フラグは、プロテインの長さが最初の４バイトで表現できるのか、または８バイト必要なのかを示し、プロテインがビッグ・エンディアンまたはリトル・エンディアンの内どちらのバイト順序付けを使用するのかを示し、更に、プロテインが標準的構造または非標準的構造のどちらを採用するのかをそれぞれ示すが、プロテインはこのように限定されるのではない。４番目のフラグ・ビットは、今後の使用のために保存される。

８バイト長フラグ・ビットがセットされる場合、プロテインの長さを計算するには、次の４バイトを読み取り、これらをビッグ・エンディアン、８バイト整数の上位バイトとして使用する（４バイトは既に読み取られ、下位部分を供給する）。リトル・エンディアン・フラグがセットされる場合、プロテインの中にある全ての二進数値データをリトル・エンディアンとして解釈する（それ以外の場合は、ビッグ・エンディアン）。非標準フラグ・ビットがセットされる場合、プロテインの残りの部分は、以下で説明する標準構造に従わない。

非標準プロテイン構造については、プロテインおよびプールを使用するシステム・プログラマには、非標準プロテイン・フォーマットを記述しこれに同期するための種々の方法が利用可能であること、そしてこれらの方法は、空間または計算サイクルが制限されるときに有用となることができることを除いて、ここではこれ以上論じない。例えば、一実施形態では、最短のプロテインは１６バイトである。標準フォーマットのプロテインは、実際のペイロード・データをこれらの１６バイトにはめ込むことは全くできない（その一番大きい部分は既に、プロテインのコンポーネント・パーツの位置を記述することが任される）。しかし、非標準フォーマット・プロテインは、その１６バイトの内１２バイトをデータに使用することができると考えられる。２つのアプリケーションがプロテインを交換すると、これらが発信するいずれの１６バイト長プロテインでも常に１２バイトを含み、これらは、例えば、リアル・タイム・アナログ／ディジタル変換器からの１２個の８ビット・センサ値を表すことを相互に決定することができる。

長さヘッダの直後には、プロテインの標準構造では、更に２つの可変長整数値が現れる。これらの数値は、それぞれ、ディスクリップ・リストにおける最初のエレメント、および最初のキー値対（インジェスト）に対するオフセットを指定する。これらのオフセットは、本明細書では、それぞれディスクリップ・オフセットおよびインジェスト・オフセットとも呼ぶ。これらの数値の各クアッド(quad)のバイト順序は、プロテイン・エンディアンネス・フラグ・ビット(protein endianness flag bit)によって指定される。各々について、最初の４バイトの最上位ビットは数値が４または８バイト幅のどちらであるかを決定する。最上位ビット（ｍｓｂ）がセットされる場合、最初の４バイトは二重ワード（８バイト）数値の最上位バイトとなる。ここでは、これを「オフセット形式」と呼ぶ。ディスクリップおよび対を指し示す別個のオフセットを使用することにより、ディスクリップおよび対を異なるコード・パスによって扱うことが可能となり、例えば、ディスクリップ・パターン照合およびプロテイン・アセンブリに関する個々の最適化を行うことができるようになる。また、これら２つのオフセットがプロテインの先頭にあるため、様々な有用な最適化に対処できる。

殆どのプロテインは８バイト長またはポインタを必要とする程大きくないので、一般に長さ（とフラグ）および２つのオフセット数値は、プロテインの最初の３バイトを占めるに過ぎない。多くのハードウェアまたはシステム・アーキテクチャでは、最初のバイトを超えるある数のバイトのフェッチ即ちリードは、「自由」である（例えば、１６バイトは、セル・プロセッサ(Cell processor)の主要バスを介して引き込むには、１バイトと全く同じ数のクロック・サイクルを要する。）
多くの場合、プロテイン内部において実施態様特定またはコンテキスト特定のキャッシング(caching)またはメタデータを許容することは有用である。オフセットの使用により、プロテインの先頭付近に、任意のサイズの「孔」を作成し、その中にこのようなメタデータを割り込ませることができる。８バイトのメタデータを利用することができる実施態様では、多くのシステム・アーキテクチャ上でこれらのバイトを、長さヘッダをフェッチする毎に１つのプロテインに対して自由に得ることができる。

ディスクリップ・オフセットは、プロテインの先頭と最初のディスクリップ・エントリとの間のバイト数を指定する。各ディスクリップ・エントリは、次のディスクリップ・エントリまでのオフセット（勿論、オフセット形態で）を備えており、その後に可変幅の長さフィールド（これもオフセット・フォーマットで）が続き、更にその後にスローが続く。これ以上ディスクリップがない場合、オフセットは、規則上、０の４バイトとなる。それ以外の場合、オフセットは、当該ディスクリップ・エントリの開始と次との間のバイト数を指定する。長さフィールドは、バイト単位で、スローの長さを指定する。

殆どのプロテインでは、各ディスクリップは、スロー・ストリング様式でフォーマットしたストリングであり、４バイトの長さ／タイプ・ヘッダを有し、最上位ビットがセットされ、下位３０ビットだけが長さを指定するために使用され、その後に、ヘッダが指示する数のデータ・バイトが続く。通常通り、長さヘッダはそのエンディアンネスをプロテインから取り込む。バイトは、ＵＴＦ−８キャラクタをエンコードすると仮定する（したがって、キャラクタ数は必ずしもバイト数と同じではないことを注記しておく）。

インジェスト・オフセットは、プロテインの先頭と最初のインジェスト・エントリとの間のバイト数を指定する。各インジェスト・エントリは、次のインジェスト・エントリまでのオフセット（オフセット・フォームで）を備えており、その後にこの場合も長さフィールドおよびスローが続く。インジェスト・オフセットは、次のディスクリップ・エントリの代わりに次のインジェスト・エントリを指し示すことを除いて、ディスクリップ・オフセットと機能的には同一である。

殆どのプロテインでは、各インジェストは、スロー・コンス・タイプ(slaw cons type)であり、二値リストを備えている。このリストは通常キー／値対として使用される。スロー・コンス・レコードは、最上位から２番目のビットがセットされており、下位３０ビットだけが長さを指定するために使用される４バイトの長さ／タイプ・ヘッダと、４バイトの値（２番目）エレメントの先頭までのオフセットと、前述の４バイトのキー・エレメント長と、キー・エレメントに対するスロー・レコードと、４バイト長の値エレメントと、最後に前述の値エレメントに対するスロー・レコードとを備えている。

一般に、コンス・キーはスロー・ストリングである。数個のプロテインおよびスロー・コンス長ならびにオフセット・フィールドを跨いでデータを複製することにより、工夫(refinement)および最適化の一層多くの機会が得られる。

前述のように、類型に分けたデータをプロテイン内部に埋め込むために一実施形態において使用される構造は、タグ付きのバイト・シーケンス指定および抽象化(abstraction)であり、「スロー」と呼ばれる（複数形は「slawx」となる）。スローは、類型に分けた（恐らくは、集計）データの一片を表すバイトの線形シーケンスであり、プログラミング言語特定ＡＰＩと関連付けられている。ＡＰＩは、スロークスを作成し、修正し、メモリ空間、記憶媒体、およびマシンの間で移動させることができる。スロー・タイプ方式(slaw type scheme)は、拡張可能でできるだけ軽量であり、あらゆるプログラミング言語からでも使用することができる共通基盤となることを意図している。

効率的な、大規模プロセス間通信メカニズムを構築することの要望が、スロー・コンフィギュレーションの原動力(driver)である。従来のプログラミング言語は、精巧なデータ構造およびタイプ機能を備えており、プロセス特定のメモリ・レイアウトでは申し分なく動作するが、データをプロセッサ間で移動させたり、ディスク上に格納することが必要となると、これらのデータ表現はいつでも決まって分解する。スロー・アーキテクチャは、第１に、プロセス間通信に対する、非常に効率的で、マルチ・プラットフォームに都合がよい低レベル・データ・モデルである。

しかし、更に一層重要なのは、スロークスが、プロテインと共に、今後の計算機ハードウェア（マイクロプロセッサ、メモリ・コントローラ、ディスク・コントローラ）の開発に影響を及ぼし、それを可能にするように構成されることである。例えば、広く一般に入手可能なマイクロプロセッサの命令セットに、多少の具体的な追加を行うことにより、スロークスが、殆どのプログラミング言語において使用される方式と同様に、単一プロセス、メモリ内データ・レイアウトに対しても効率的となることが可能になる。

各スローは、可変長のタイプ・ヘッダと、その後に続くタイプ特定データ・レイアウトとを備えている。例えば、Ｃ、Ｃ＋＋、およびRubyにおけるスロー機能を全てサポートする実施形態の一例では、タイプは、各言語からアクセス可能なシステム・ヘッダ・ファイルにおいて定義されるユニバーサル整数(universal integer)によって示される。更に精巧化し柔軟性を高めたタイプ解明機能(type resolution functionality)、例えば、ユニバーサル・オブジェクトＩＤおよびネットワーク参照による間接的類型決定も可能である。

一実施形態のスロー・コンフィギュレーションは、スロー・レコードを、例えば、RubyおよびＣ＋＋双方から言語に優しい様式でオブジェクトとして使用することを可能にする。Ｃ＋＋コンパイラ外部の１組のユーティリティが、スロー・バイト・レイアウトの健全性をチェックし、個々のスロー・タイプに特定的なヘッダ・ファイルおよびマクロを作成し、Rubyに対するバインディング(binding)を自動的に生成する。その結果、正しく構成したスロー・タイプは、１つのプロセスの中から使用した場合でも、非常に効率的となる。プロセスのアクセス可能なメモリのいずれの場所におけるいずれのスローでも、コピーや「非直列化」ステップがなくても、アドレスすることができる。

一実施形態のスロー機能は、以下の内１つ以上を実行するＡＰＩ機能を含む。具体的なタイプの新たなスローを作成する。ディスク上またはメモリ内におけるバイトからのスローへの言語特定参照を作成または構築する。タイプに特定の様式でスロー内にデータを埋め込む。スローのサイズを問い合わせる。スロー内部からデータを引き出す。スローのクローンを作成する。そして、スロー内部にある全てのデータのエンディアンネスおよびその他のフォーマット属性を変換する。スローのあらゆる種(species)が以上の挙動を実施する。

図２４Ｂ／１および図２４Ｂ／２は、一実施形態の下におけるスロー・ヘッダのフォーマットを示す。以下にスローの詳細な説明を行う。

各スローの内部構造は、タイプ解明、カプセル化データへのアクセス、および当該スロー・インスタンスについてのサイズ情報の各々を最適化する。一実施形態では、１組のスロー・タイプ全体は、設計上、最小限の全てが揃っており、スロー・ストリング、スロー・コンス（即ち、ダイアッド(dyad)）、スロー・リスト、およびスロー数値オブジェクトを含む。スロー数値オブジェクト自体は、半ダース程度の基本的な属性の組み合わせ(permutation)として理解される、広範な１組の個別数値タイプを表す。いずれのスローでも、その他の基本的プロパティはそのサイズである。一実施形態では、スロークスは、４の倍数に量子化したバイト長を有し、これらの４バイト・ワードを、ここでは「クアッド」と呼ぶ。一般に、このようなクアッドに基づくサイズ決定により、スロークスを最新のコンピュータ・ハードウェア・アーキテクチャのコンフィギュレーションと正確に整合させる。

一実施形態では、各スローの最初の４バイトは、ヘッダ構造を備えている。ヘッダ構造は、タイプ記述およびその他のメタ情報をエンコードし、特定的なタイプの意味を特定のビット・パターンに帰属させる(ascribe)。例えば、スロー・ヘッダの最初の（最上位）ビットは、そのスローのサイズ（クアッド・ワード単位の長さ）が最初の４バイトのタイプ・ヘッダに従うか否か指定するために使用することができる。このビットがセットされる場合、スローのサイズが当該スローの次の４バイト（例えば、バイト５から８まで）に明示的に記録されることが分かる。スローのサイズが、４バイトでは表現できないような場合（即ち、サイズが２の３２乗以上である場合）、スローの最初の４バイトの次の最上位ビットもセットする。これは、スローが８バイト（４バイトではなく）長を有することを意味する。その場合、検査プロセスが、序数バイト(ordinal byte)５から１２までに格納されたスローの長さを発見する。他方で、スロー・タイプの数値が小さいことは、多くの場合、完全に指定した類型ビット・パターンが、４バイトのスロー・ヘッダにおける多くのビットを「未使用のまま残してある」ことを意味し、そのような場合、これらのビットは、スローの長さをエンコードするために使用してもよく、そうしなければ必要となるはずのバイト（５から８まで）を取っておくことができる。

例えば、一実施形態では、スロー・ヘッダの最上位ビット（「長さ従属」フラグ）をセットしないままにしておき、次のビットをセットして、そのスローが「微小コンス」であることを示し、この場合、スローの長さ（クアッド単位）を残りの３０ビットにエンコードする。同様に、「微小ストリング」は、ヘッダにおけるパターン００１によって印され、スロー・ストリングの長さを表すために、２９ビットが残され、ヘッダにおける最初の０００１が「微小リスト」を記述する。これは、２８ビットの利用可能長表現ビットのために、サイズが２から２８クアッドまでのスロー・リストとすることができる。「最大ストリング」（あるいはコンスまたはリスト）は、ヘッダに異なるビット・シグネーチャを有し、ヘッダの最上位ビットは必ずセットされる。何故なら、スロー長はバイト５から８（または、極端な場合には１２）において別個にエンコードされるからである。尚、プラズマ実施態様は、スローの組立時に、これらの構造の「微小」バージョンまたは「最大」バージョンのどちらを採用すべきか「決定する」（決定は、最終的なサイズが利用可能な微小ビットに「納まるか」否かに基づく）が、最大−対−微小の詳細は、プラズマ実施態様のユーザには隠される。ユーザは、スロー・ストリング、またはスロー・コンス、またはスロー・リストを使用していることしか知らないし、そのことしか気に留めない。

一実施形態では、数値スロークスは、最初のヘッダ・パターン００００１によって示される。後続のヘッダ・ビットは、任意の順列に組み合わせることができる１組の直交プロパティを表すために使用される。一実施形態では、数値が（１）浮動小数点、（２）複素数、（３）符号なし、（４）「広い」、（５）「太くて短い」(stumpy)であるか否かを示すために、５つのこのようなキャラクタ・ビットを使用するが、これらに限定されるのではない（（４）「広い」および（５）「太くて短い」の順序を変えて、８、１６、３２、および６４ビット数表現を示す）。２つの追加ビット（例えば、（７）および（８））は、カプセル化した数値データが、２−、３−、または４−エレメント・ベクトルであることを示す（双方のビットが０の場合、数値が「１−エレメント・ベクトル」（即ち、スカラー）であることを示唆する）。この実施形態では、４番目のヘッダ・バイトの８ビットを使用して、カプセル化した数値データのサイズを（クアッド単位ではなく、バイト単位で）エンコードする。このサイズのエンコード処理は、１から２５６までの間のいずれのサイズでも表すことができるように、１だけずらされる。最後に、２つのキャラクタ・ビット（例えば、（９）および（１０））を使用して、数値データが個々の数値エンティティの配列をエンコードすることを示す。数値エンティティの各々は、キャラクタ・ビット（１）から（８）までによって記述されるタイプのものである。アレイの場合、個々の数値エンティティには、各々、追加のヘッダが添付されず、１つのヘッダおよび恐らくは、明示的なスロー・サイズ情報に続く連続データとしてパックされる。

この実施形態では、単純かつ効率的なスローの複製（バイト毎のコピーとして実施することができる）、および非常に単純で効率的なスローの比較が可能となる（この実施形態では、連続と見なされる構成バイトの各々に１対１の一致がある場合に限って、２つのスロークスは同一となる）。後者のプロパティは、例えば、プロテイン・アーキテクチャの効率的な実現には重要である。その重要なそして波及する(pervasive)特徴は、プロテインのディスクリップ・リスト全体を検索できること、または「リスト上で照合」できることである。

更に、本明細書における実施形態は、集計スロー形態（例えば、スロー・コンスおよびスロー・リスト）を簡単かつ効率的に作成することを可能にする。例えば、一実施形態では、スロー・コンスを、いずれのタイプでもよく、これら自体集計を含む、２つの成分スロークスから次のように構築する。（ａ）各成分スローのサイズを問い合わせ、（ｂ）２つの成分スロークスのサイズ、およびヘッダ・プラス・サイズ構造に必要な１、２、または３クアッドの和に等しいサイズのメモリを割り当て、（ｃ）最初の４、８、または１２バイトにスロー・ヘッダ（およびサイズ情報）を記録し、次いで（ｄ）成分スロークスのバイトを順番に、直後に続くメモリにコピーする。重要なのは、このような組立ルーチンは、２つの成分スロークスのタイプについて何も知る必要がなく、それらのサイズ（そして、バイトのシーケンスとしてのアクセス可能性）だけが問題であることである。同じプロセスは、スロー・リストの作成にも関与する。スロー・リストは、（恐らくは）異質なタイプの任意の多くのサブ・スロークス(sub-slawx)の順序付けしたカプセル化である。

メモリにおける連続バイトとしてのスロー・システムの基本的フォーマットの更に別の成果が、「横断」活動(traversal activities)と関連して得られる。反復使用パターンが、例えば、スロー・リストに格納された個々のスロークスへの順次アクセスを使用する。プロテイン構造内部におけるディスクリップおよびインジェストを表す個々のスロークスも同様に横断しなければならない。このような操作は、驚く程単純かつ効率的な方法で遂行される。つまり、スロー・リストにおける次のスローに「進み」、現在のスローの長さをそのメモリ位置に追加し、結果的に得られたメモリ位置が、次のスローのヘッダと同一となる。このような簡素さが可能なのは、スローおよびプロテインの設計が「間接」を避けるからである。つまり、ポインタがなく、データは単純にその全体が本来の場所に存在する。

スロー比較の時点までに、プラズマ・システムの完全な実施態様は、異なるオペレーティング・システム、ＣＰＵ、およびハードウェア・アーキテクチャに跨ってそしてこれらの間において、異なり互換性のないデータ表現方式の存在を承認しなければならない。このような相違の主要なものには、バイト順序付け方針（例えば、リトル−エンディアン対ビッグ−エンディアン）および浮動小数点表現が含まれ、その他の相違も存在する。プラズマ仕様では、スロークスによってカプセル化したデータが解釈可能である(interprable)（即ち、スローを検査している元のアーキテクチャまたはプラットフォームのネーティブ・フォーマットで現れなければならない）。この要件は、一方、プラズマ・システム自体がデータ・フォーマット変換の責任を負うことを意味する。しかしながら、仕様では、スローが、それを検査するかもしれない実行中のプロセスに対して「完全に可視」になる前に変換を行うことしか規定していない。したがって、どの時点でこのようなフォーマットｃ変換を実行するかを選択するのは、個々の実施態様次第となる。２つのしかるべき手法があり、それは、（１）個々のスローがパックされていたプロテインから「引き出す」際に、または（２）プロテインが入っていたプールからそのプロテインを抽出する際に、当該プロテインの中にあるスロー全てについて同時に、スロー・データ・ペイロードをローカル・アーキテクチャのデータ・フォーマットに準拠させることである。尚、変換規定は、ハードウェア補助実施態様の可能性も考慮することを注記しておく。例えば、明示的プラズマ能力によって構築したネットワーキング・チップセットは、受信システムの既知の特性に基づいて、インテリジェントにそして「送信の時点」にフォーマット変換を実行することを選択することができる。あるいは、送信のプロセスがデータ・ペイロードを基軸フォーマットに変換することもでき、受信プロセスは、対称的に基軸フォーマットから「ローカル」フォーマットに変換する。別の実施形態では、「メタル」において(at the metal)フォーマット変換を実行する。これが意味するのは、データは、ローカル・メモリの中であっても、常に基軸フォーマットで格納されており、データをメモリから引き出し隣接するＣＰＵのレジスタに入れるときに、メモリ・コントローラ・ハードウェア自体が変換を実行する。

一実施形態の最小（そして読み取り専用）プロテインの実施態様は、プロテインを利用する１つ以上のアプリケーションまたはプログラミング言語における動作または挙動を含む。図２４Ｃは、一実施形態の下でプロテインを使用するための流れ図６５０である。動作を開始すると、６５２においてプロテインの長さをバイト単位で問い合わせる。６５４において、ディスクリップ・エントリの数を問い合わせる。６５６において、インジェストの数を問い合わせる。６５８において、インデックス番号によってディスクリップ・エントリを引き出す。６６０において、インデックス番号によってインジェストを引き出す。

また、本明細書において記載する実施形態は、プロテインを作成してデータを充填させる基本的な方法、プログラマによって共通のタスクを容易に行えるようにするヘルパ方法、および最適化を遂行するためのフック(hook)も定める。図２４Ｄは、一実施形態の下においてプロテインを作成する、即ち、生成するための流れ図６７０である。動作は、６７２における新たなプロテインの作成から開始する。６７４において、一連のディスクリップ・エントリを添付する。また、６７６においてインジェストも添付する。６７８において、一致するディスクリップの存在を問い合わせ、６８０において、一致するインジェスト・キーの存在を問い合わせる。インジェスト・キーが得られたなら、６８２において、インジェスト値を引き出す。６８４において、ディスクリップ全体でパターン照合を実行する。６８６において、プロテインの先頭付近に、非構造化メタデータを埋め込む。

前述のように、スロークスはプロセス間交換のための低レベルのデータ定義を規定し、プロテインは問い合わせおよびフィルタ処理のために中間レベルの構造およびフックを規定し、プールは高レベルの編成およびアクセス・セマンティックスについて規定する。プールは、プロテインのためのレポジトリであり、線形シーケンシング(linear sequencing)および状態キャッシング(state caching)に備えている。また、プールは、多数のプログラムまたは多数の異なる種類のアプリケーションによるマルチ・プロセス・アクセスにも備えている。更に、プールは、１組の共通な、最適化可能なフィルタ処理およびパターン照合挙動にも備えている。

一実施形態のプールは、数万ものプロテインを収容することができ、状態を維持するように機能することができるので、個々のプロセスはマルチ・プロセス・プログラム・コードに共通する厄介なブックキーピングの多くの負担を軽減することができる。プールは、利用可能な過去のプロテインの大きなバッファを維持または保持し、プラトニック・プール(Platonic pool)は明示的に無限であるので、関与するプロセスは、プールにおいて意のままに逆方向および順方向の双方に走査することができる。バッファのサイズは、実施態様に左右されるが、勿論、慣例的な仕様では、プロテインをプールの中に数時間または数日保持できることが多い。

本明細書において記載するプール使用の最も慣例的な様式では、既存のプロセス間通信フレームワークが採用する機械論的(mechanistic)二点間手法とは対照的に、生物的比喩に従う。プロテインという名称は、生物的発想を暗示する。生物組織における化学的蛋白質が、多数の細胞因子(cellular agent)によるパターン照合およびフィルタ処理に利用可能であるのと同様に、プールの中にあるデータ・プロテインは、多数の計算プロセスによる柔軟な問い合わせおよびパターン照合に利用可能である。

２つの付加的な抽象化が生物的比喩に同調し(lean)、「ハンドラ」の使用およびゴルジ・フレームワーク(Golgi framework)を含む。プールに関与するプロセスは、一般に、多数のハンドラを作成する。ハンドラは、比較的小さい１群のコードであり、照合条件をハンドル挙動と関連付ける。１つ以上のハンドラをプールに類別することにより、プロセスは、状態をカプセル化し新たなプロテインに反応する、柔軟なコール・バック・トリガ(call-back trigger)を設定する。

数個のプールに関与するプロセスは、一般に、抽象的ゴルジ・クラスから継承する。ゴルジ・フレームワークは、多数のプールおよびハンドラを管理するための多くの有用なルーチンを提供する。また、ゴルジ・クラスは、親−子関係もカプセル化し、プールを使用しないローカル・プロテイン交換のためのメカニズムを提供する。

一実施形態の下で提供するプールＡＰＩは、種々の方法でプールを実現し、システム特定の目標、ならびに所与のハードウェアおよびネットワーク・アーキテクチャの利用可能な処理能力双方を考慮に入れるように構成される。プールが依存する２つの基礎的なシステムの常設機構(provision)は、記憶装置およびプロセス間通信手段である。本明細書において記載する、現存する(extant)システムは、共有メモリ、仮想メモリ、および記憶装置用ディスク、ならびにプロセス間通信のためのＩＰＣクエリおよびＴＣＰ／ＩＰソケットの柔軟な組み合わせを使用する。

一実施形態のプールの機能には、限定ではなく、以下が含まれる。プールに関与する。プロテインをプールの中に入れる。次の未見プロテインをプールから引き出す。プール内の内容（例えば、プロテイン）を逆回しまたは早送りする。加えて、プールの機能には、限定ではなく、以下も含むことができる。プロセスに対するストリーミング・プール・コール・バックを設定する。ディスクリップまたはインジェスト・キーの特定のパターンと一致するプロテインを選択的に引き出す。ディスクリップまたはインジェスト・キーの特定のパターンと一致するプロテインについて逆方向および順方向に走査する。

前述のプロテインは、他のアプリケーションとプロテイン・データ・コンテンツを共有する方法として、プールに供給される。図２５は、一実施形態の下において、スロークス、プロテイン、およびプールを使用したデータ交換を含む処理環境のブロック図である。この環境例は、前述のようにスロークス、プロテイン、およびプールの使用によりデータを共有する３つのデバイス（例えば、デバイスＸ、デバイスＹ、およびデバイスＺ、ここでは纏めて「デバイス」と呼ぶ）を含む。これらのデバイスの各々は、３つのプール（例えば、プール１、プール２、プール３）に結合される。プール１は、それぞれのデバイスから当該プールに提供または転送された多数のプロテイン（例えば、プロテインＸ１、プロテインＺ２、プロテインＹ２、プロテインＸ４、プロテインＹ４）を含む（例えば、プロテインＺ２は、デバイスＺによってプール１に転送または提供された等）。プール２は、それぞれのデバイスから当該プールに提供または転送された多数のプロテイン（例えば、プロテインＺ４、プロテインＹ３、プロテインＺ１、プロテインＸ３）を含む（例えば、プロテインＹ３は、デバイスＹによってプール２に転送または提供された等）。プール３は、それぞれのデバイスから当該プールに供給または転送された多数のプロテイン（例えば、プロテインＹ１、プロテインＺ３、プロテインＸ２）を含む（例えば、プロテインＸ２は、デバイスＸによってプール３に転送または提供された等）。前述の例では、３つのプール間に結合または接続された３つのデバイスが含まれるが、あらゆる数のデバイスを、あらゆる数のプール間に如何様にでもまたはいずれの組み合わせでも結合または接続することができ、いずれのプールも、あらゆる数または組み合わせのデバイスから提供されるあらゆる数のプロテインを含むことができる。この例のプロテインおよびプールについては、図２５から図３０までを参照しながら先に説明した。

図２６は、多数のデバイスと、これらのデバイスの１つ以上で走る多数のプログラムを含む処理環境のブロック図であり、一実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、多数のデバイス（例えば、デバイスＡ、Ｂ等）およびこれらのデバイス上で走る多数のプログラム（例えば、appsAA-AX、appsBA-ＢＸ等）を備えている双方向処理システムが、プラズマ構造（例えば、プール、プロテイン、およびスロー）を使用して、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。

この例では、各デバイス（例えば、デバイスＡ、Ｂ等）は、それぞれのデバイス上で走っているプログラム（例えば、appsAA-AX、appsBA-BX等）が生成したまたは出力された離散生データを、プラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入する。例えば、プログラムＡＸはデータまたは出力を生成し、この出力をデバイスＡに供給する。一方、デバイスＡはこの生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、プログラムＢＣがデータを生成し、このデータをデバイスＢに供給する。一方、デバイスＢはこのデータをプロテイン（例えば、プロテイン１Ｂ、プロテイン２Ｂ等）に変換し、これらのプロテインをプールに貯入する。

各プロテインは、アプリケーションが生成し、プログラム自体についての情報を特定するデータまたは出力を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップは出力イベントまたは行動について一般的な意味論的意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、プログラム・イベントについての１組の有用な状態情報全体を搬送する。

前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されたあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で走っているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマ(consumer)を多重化し、デバイスを一人で制御できるように、または数人（例えば、プラズマに基づく入力フレームワークは、多くの同時ユーザをサポートする）で同時に使用することができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに見えるようになることである。

一例として、デバイスＣは１つ以上のプロテイン（例えば、プロテイン１Ａ、２Ａ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、プロテイン・データが対応する処理イベントにおいて使用することができる。別の例として、デバイスＢは、プールから１つ以上のプロテイン（例えば、プロテイン１Ｃ、プロテイン２Ａ等）を抽出することができる。プロテインの抽出に続いて、デバイスＢは、プロテイン・データが対応する処理イベントにおいて、プロテインのデータを使用することができる。

プールに結合または接続されたデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されたイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。

図２７は、多数のデバイスと、これらのデバイスの１つ以上で走る多数のプログラムを含む処理環境のブロック図であり、一代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、多数のデバイス（例えば、デバイスＡおよびＢにそれぞれ結合されたデバイスＸおよびＹ）および１つ以上のコンピュータ（例えば、デバイスＡ、デバイスＢ等）上で走る多数のプログラム（例えば、appsAA-AX、appsBA-ＢＸ等）を備えている双方向処理システムが、プラズマ構造（例えば、プール、プロテイン、およびスロー）を使用して、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。

この例では、各デバイス（例えば、デバイスＡおよびＢにそれぞれ結合されたデバイスＸおよびＹ）は、デバイス・ハードウェア（例えば、デバイスＸ、デバイスＡ、デバイスＹ、デバイスＢ等）が生成した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス（例えば、デバイスＡ、デバイスＢ等）上にホストされた１つ以上のプログラムの下で、またはこれらと連携して動作するように管理および／または結合される。例えば、デバイスＡ上にホストされたアプリケーションＡＢと連携して動作するデバイスＸは、生データを生成し、この離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、デバイスＡ上にホストされたアプリケーションＡＴと連携して動作するデバイスＸが、離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａなど）に変換し、これらのプロテインをプールに貯入する。更に別の例として、デバイスＣ上にホストされたアプリケーションＣＤと連携して動作するデバイスＺは、生データを生成し、この離散生データをプロテイン（例えば、プロテイン１Ｃ、プロテイン２Ｃ等）に変換し、これらのプロテインをプールに貯入する。

各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的な意味論的意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、デバイス・イベントについての１組の有用な状態情報全体を搬送する。

前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されたあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で走っているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人（例えば、プラズマに基づく入力フレームワークは、多くの同時ユーザをサポートする）で同時に使用することができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。

プールに結合または接続されたデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されたイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。

図２８は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、双方向処理システムは、多数の入力デバイス（例えば、入力デバイスＡ、Ｂ、ＢＡ、およびＢＢ等）を備えており、１つ以上のコンピュータ（例えば、デバイスＡ、デバイスＢ等）上で走る多数のプログラム（図示せず）を備えており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を使用して、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。

この例では、各入力デバイス（例えば、入力デバイスＡ、Ｂ、ＢＡ、およびＢＢ等）は、入力デバイス・ハードウェアが生成した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス（例えば、デバイスＡ、デバイスＢ等）上にホストしたソフトウェア・ドライバ・プログラムによって管理される。例えば、入力デバイスＡは生データを生成し、この生データをデバイスＡに供給する。一方、デバイスＡは離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、入力デバイスＢＢは生データを生成し、この生データをデバイスＢに供給する。一方、デバイスＢは離散生データをプロテイン（例えば、プロテイン１Ｂ、プロテイン３Ｂ等）に変換し、これらのプロテインをプールに貯入する。

各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的な意味論的意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、デバイス・イベントについての１組の有用な状態情報全体を搬送する。

例示のために、ここに、このようなシステムにおける２つの典型的なイベントに対するプロテインを示す。ここでは、プロテインはテキストとして表すが、実際の実施態様では、これらのプロテインの構成部分は、類別されたデータ・バンドル（例えば、スロー）である。g-speak "one finger click" pose（「指１本によるクリック」のポーズ）（関連出願に記載されている）を記述するプロテインは、次の通りである。

[Descrips: {point, engage, one, one-finger-engage, hand,
pilot-id-02, hand-id-23}
Ingests: {pilot-id => 02,
hand-id => 23,
pos => [0.0, 0.0, 0.0]
angle-axis => [0.0, 0.0, 0.0, 0.707]
grip => ..^||:vx
time => 184437103.29}]
別の例として、マウスのクリックを記述するプロテインは次の通りである。

[Descrips: {point, click, one, mouse-click, button-one,
mouse-id-02 }
Ingests: {mouse-id =>23,
pos => [0.0, 0.0, 0.0]
time => 184437124.80}]
以上のプロテインの見本のいずれかまたは双方は、そのコードの特定の部分を走らせるホスト・デバイスの関与プログラム(participating program)を生ずる可能性もある。これらのプログラムは、一般的なセマンティック・レベルに関係する場合がある。全ての内最も一般的なのは「point」であり、更に具体的な対は「engage, one」である。また、これらは、正確なデバイス：「one-finger-engage」または正に１つの集計オブジェクト(aggregate object)「hand-id-23」のみによってもっともらしく発生されるイベントを求めている場合もある。

前述のように、プロテインは、プログラムやデバイスの種類には関係なく、プールに結合または接続されたあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能である。したがって、あらゆる数のコンピュータ上で走るあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出する。これらのデバイスは、プロテインをプールから抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、入力イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人（例えば、プラズマに基づく入力フレームワークは、多くの同時ユーザをサポートする）で同時に使用することができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。

プロテイン使用の一例として、デバイスＣは１つ以上のプロテイン（例えば、プロテイン１Ｂ等）をプールから抽出することができる。プロテイン抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、当該プロテイン・データが対応する入力デバイスＣＡおよびＣＣの入力イベントを処理する際に使用することができる。別の例として、デバイスＡは、１つ以上のプロテイン（例えば、プロテイン１Ｂ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＡは、プロテイン・データが対応する入力デバイスＡの入力イベントを処理する際に、当該プロテインのデータを使用することができる。

プールに結合または接続されたデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されたイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。

本明細書において記載するシステムの実施形態に使用される入力デバイスの例には、ジェスチャ入力センサ、キーボード、マウス、消費者電子機器において使用されるような赤外線リモコン装置、およびタスク指向有体媒体オブジェクト(task-oriented tangible media object)、その他にも数多く含まれる。

図２９は、多数のデバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を使用することにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする。このシステムは、多数の実行中のプログラム（例えば、グラフィクスＡ〜Ｅ）および１つ以上のディスプレイ・デバイス（図示せず）を備えているシステムの一例に過ぎず、プログラムの一部または全部のグラフィック出力が、プラズマ構造（例えば、プール、プロテイン、およびスロー）を使用して、調整しながら他のプログラムにも利用可能とし、実行中のプログラムが、これらのデバイスによって発生したグラフィック・イベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。

コンピュータ・プログラムが、別のプログラムによって生成したグラフィクスを表示することが有用な場合は多い。広く知れ渡っている様々な例には、テレビ会議アプリケーション、ネットワークを使用したスライドショーおよびデモ・プログラム、ならびにウィンドウ・マネージャが含まれる。この構成の下では、プールは、ビデオ、ネットワーク・アプリケーション共有、およびウィンドウ管理をカプセル化したフレームワークを一般化して実施するためにプラズマ・ライブラリとして使用され、プログラマは、このようなプログラムの現バージョンでは一般には入手できない多数の特徴に追加することが可能になる。

プラズマ合成環境において走るプログラム（例えば、グラフィクスＡ〜Ｅ）は、プールへの結合および／または接続を通じて、調整プールに関与する。各プログラムは、種々の種類のグラフィック・ソースの可用性を示すために、そのプールにプロテインを貯入する。また、グラフィックスを表示するために利用可能なプログラムも、それらの表示処理能力、セキュリティおよびユーザ・プロファイル、ならびに物理的位置およびネットワーク位置を示すために、プロテインを貯入する。

また、グラフィクス・データをプールを通じて送信することもでき、あるいは表示プログラムに、他の種類（例えば、ＲＴＳＰストリーム）のネットワーク・リソースを指し示させることもできる。「グラフィクス・データ」という用語は、本明細書において使用する場合、広義の連続体(broad continuum)に沿って存在する種々の異なる表現のことを指し、グラフィクス・データの例には、文字で表現される例（例えば、「画像」、または画素のブロック）、手順的例（例えば、典型的なopenGLパイプラインを下って行くような一連の「描画」指令）、および記述的例（例えば、幾何学的変形、クリッピング、および合成動作によって他のグラフィック構造を組み合わせる命令）が含まれるが、これらに限定されるのではない。

ローカル・マシン上では、グラフィクス・データは、プラットフォーム特定の表示ドライバ最適化を通じて配信することもできる。プールを通してグラフィクスを送信しない場合でも、多くの場合、周期的な画面キャプチャは、調整プールに格納されるので、より内部(esoteric)のソースに直接アクセスできないクライアントであっても、万一のときのグラフィクス(fall-back graphics)を表示することもできる。

本明細書において記載するシステムの利点の１つは、殆どのメッセージ伝達フレームワークおよびネットワーク・プロトコルとは異なり、プールがデータの大量のバッファを維持することである。したがって、プログラムはプールの中に逆戻りして、アクセスおよび使用パターン（調整プールの場合）を見たり、以前のグラフィクス・フレーム（グラフィクス・プールの場合）を抽出することができる。

図３０は、多数のデバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を使用することにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする。このシステムは、多数のデバイス（例えば、デバイスＡ、デバイスＢ等）上に多数の実行プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）を備えており、一部のプログラムがプールを使用してまたはプールを通じて他のプログラムの内部状態にアクセスするシステムの一例に過ぎない。

殆どの双方向処理コンピュータ・システムは、多くのプログラムを備えており、これらは、１台のマシンまたは多数のマシン上で互いに一緒に走り、ネットワークを跨いで双方向処理を行う。実行時データが各プロセス内部に隠されアクセスするのが困難なので、マルチ・プログラム・システムは、構成設定、分析、およびデバッグするのが難しい。本明細書において記載する一実施形態の一般化したフレームワークおよびプラズマ構造は、実行中のプログラムがプールを通じてそれらのデータの多くを利用可能にするので、他のプログラムがそれらの状態を検査することができる。このフレームワークによって、従来のデバッガよりも柔軟なデバッギング・ツール、精巧なシステム保守ツール、および１つまたは複数のプログラムが通過した一連の状態を、人の操作者に詳細に分析させるように構成された可視化ハーネスを可能にする。

図３０を参照すると、このフレームワークにおいて走るプログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）は、プログラムの起動時にプロセス・プールを生成または作成する。このプールは、システム・アルマナックに登録され、セキュリティおよびアクセス制御が適用される。更に特定すると、各デバイス（例えば、デバイスＡ、Ｂ等）が、それぞれのデバイス上で走るプログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が生成または出力した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールの中に貯入する。例えば、プログラムＰ−Ａは、データまたは出力を生成し、この出力をデバイスＡに供給する。一方、デバイスＡは、この生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ、プロテイン３Ａ等）に変換し、これらのプロテインをプールの中に貯入する。別の例として、プログラムＰ−Ｂはデータを生成し、このデータをデバイスＢに供給する。一方、デバイスＢは、データをプロテイン（例えば、プロテイン１Ｂ〜４Ｂ等）に変換し、これらのプロテインをプールの中に貯入する。

プログラムの寿命の期間中、十分なアクセス許可を有する別のプログラムがプールに接続し(attach)、プログラムが貯入したプロテインを読み取ることもできる。これは、基本的な検査様式を表し、概念的に「一方向」即ち「読み取り専用」の提案(proposition)である。プログラムＰ−Ａに関与するエンティティが、そのプロセス・プールの中にＰ−Ａによって貯入されたステータス情報の流れを検査する。例えば、デバイスＣの下で走る検査プログラムまたはアプリケーションが１つ以上のプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出した即ち読み出したプロテインのデータを使用して、プログラムＰ−Ａの内部状態にアクセスし、これを解釈し、検査することができる。

しかし、プラズマ・システムは単に効率的なステートフル(stateful)伝送方式であるだけでなく、全方向メッセージング環境であることを思い起こすと、様々な追加モードがプログラム対プログラムの状態検査をサポートする。許可された検査プログラムは、それ自体でプロテインをプログラムＰのプロセス・プールに貯入して、生成してそのプロセス・プールの中に入れた状態情報の特性に影響を及ぼし、これらの特性を制御することができる（結局、プログラムＰはプロセス・プールに書き込むだけでなく、そこから読み取りも行う）。

図３１は、多数のデバイスを含み、これらが当該デバイスの１つ以上で走る多数のプログラム間に結合された処理環境のブロック図であり、追加の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を使用することにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる。このシステム例では、デバイスＣの検査プログラムは、例えば、プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が、１回だけまたは特定の期間にわたって、通常よりも多い状態をプールにダンプすることを要求することができる。または、デバッグ通信の次の「レベル」を予示しておくと、関与するプログラムは、プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が、デバッグ・プールを通じた双方向処理が個々に可能でありそのために利用可能な、その実行時間環境において残存するオブジェクトを一覧に纏めたプロテインを放出(emit)することを要求することができる。このように通知すると、関与するプログラムはプログラムの実行時においてオブジェクトの中の個々に「アドレス」し、特定のオブジェクトだけが専有し応答するプロセス・プールにプロテインを入れることができる。関与するプログラムは、例えば、オブジェクトが、その成分変数全ての瞬時値を記述した報告プロテインを放出することを要求することもあり得る。それよりも更に重要なのは、関与するプログラムが、他のプロテインを通じて、オブジェクトにその挙動またはその変数の値を変更するように指令できることである。

更に具体的には、この例では、デバイスＣの検査アプリケーションが、プールの中に、オブジェクト・リスト（例えば、「要求−オブジェクト・リスト」）の要求を（プロテインの形態で）入れて、次いでこのプールに結合された各デバイス（例えば、デバイスＡ、デバイスＢ等）が抽出する。要求に応答して、各デバイス（例えば、デバイスＡ、デバイスＢ等）がプールの中に、その実行時環境において残存する、デバッグ・プールを通じて個々に検査することができそのために利用可能なオブジェクトを一覧に纏めたプロテイン（例えば、プロテイン１Ａ、プロテイン１Ｂ等）を入れる。

このようにデバイスからのリストを通じて通知され、オブジェクトのリストに応答して、デバイスＣの検査アプリケーションは、プログラム実行中におけるオブジェクトの中の個々にアドレスし、特定のオブジェクトのみが専有し応答するプロセス・プールにプロテインを入れる。デバイスＣの検査アプリケーションは、例えば、要求プロテイン（例えば、プロテイン「要求報告Ｐ−Ａ−Ｏ」、「要求報告Ｐ−Ｂ−Ｏ」）を、オブジェクト（例えば、それぞれ、オブジェクトＰ−Ａ−Ｏ、オブジェクトＰ−Ｂ−Ｏ）が、その成分変数の全ての瞬時値を記述する報告プロテイン（例えば、プロテイン２Ａ、プロテイン２Ｂ等）を放出するプールに入れる。各オブジェクト（例えば、オブジェクトＰ−Ａ−Ｏ、オブジェクトＰ−Ｂ−Ｏ）は、その要求（例えば、それぞれ、プロテイン「要求報告Ｐ−Ａ−Ｏ」、「要求報告Ｐ−Ｂ−Ｏ」）を抽出し、それに応答して、要求された報告（例えば、それぞれ、プロテイン２Ａ、プロテイン２Ｂ）を含むプールにプロテインを入れる。次いで、デバイスＣは種々の報告プロテイン（例えば、プロテイン２Ａ、プロテイン２Ｂ等）を抽出し、適宜報告の内容に合わせて続く処理行為を実行する。

このように、プラズマを相互交換媒体として使用すると、デバッグ処理、プロセス制御、ならびにプログラム対プログラムの通信および調整の間にある区別を究極的に解消し易くなる。

このため、一般化したプラズマ・フレームワークは、疎結合の様式で可視化および分析プログラムを設計することを可能にする。例えば、メモリ・アクセス・パターンを表示する可視化ツールは、基本的なメモリ・リードおよびライトをプールに出力するいずれのプログラムとでも合わせて使用することができる。分析を受けるプログラムは、可視化ツールの存在や設計を知る必要がなく、その逆も成り立つ。

以上のようにプールを使用すると、システム性能に不当に影響を及ぼすことはない。例えば、実施形態は、毎秒数十万個のプロテインをプールに貯入することを考慮するので、比較的冗漫なデータ出力を可能にしても、殆どのプログラムの応答性や双方向処理特性を著しく阻害することはない。

本明細書において説明した実施形態は、センサによって検出された物体に対応するデータをセンサから受信するステップを含む方法を含む。この方法は、データの各フレームから画像を生成するステップを含む。これらの画像は、複数の解像度を表す。この方法は、画像においてブロブを検出し、ブロブを物体のトラックと関連付けることによって、物体を追跡するステップを含む。この方法は、各ブロブを複数の物体形状の内の１つに対応するものとして分類することによって、物体のポーズを検出するステップを含む。この方法は、ポーズおよびトラックに応答して、ジェスチャ・インターフェースを制御するステップを含む。

本明細書において説明した実施形態は、センサによって検出された物体に対応するデータをセンサから受信するステップと、データの各フレームから画像を生成するステップであって、画像が複数の解像度を表す、ステップと、画像においてブロブを検出し、ブロブを物体のトラックと関連付けることによって、物体を追跡するステップと、各ブロブを複数の物体形状の内の１つに対応するものとして分類することによって、物体のポーズを検出するステップと、ポーズおよびトラックに応答して、ジェスチャ・インターフェースを制御するステップとを含む。

一実施形態のポーズおよびトラックの検出は、物体の三次元構造に基づく。

一実施形態のポーズおよびトラックの検出は、リアル・タイム局所セグメント化と、センサの深度データを使用する物体検出とを含む。

一実施形態の画像の生成は、少なくとも、第１解像度を有する第１画像と、第２解像度を有する第２画像とを生成することを含む。

一実施形態のブロブの検出は、第１画像においてブロブを検出することを含む。

一実施形態のポーズの検出は、第２画像においてポーズを検出することを含む。

一実施形態の物体が人間の被験者の手であり、ポーズの検出および物体の追跡は、スケルトンを使用しない検出を含む。

この方法は、手が、人間の被験者の身体質量の中心からの測地線距離に関して極値に対応すると判定するステップを含む。

一実施形態のポーズの検出および物体の追跡は、フレーム毎の極値検出を含む。

一実施形態のポーズの検出は、検出された極値を人間の被験者の部分と照合することを含む。

この方法は、画像の第１深度画像において指向性ピークを検出することによって、極値候補を識別するステップを含む。
この方法は、潜在的な手を、極値候補に空間的に接続されたブロブとして識別するステップを含む。

この方法は、処理ボリュームを制限するために予め指定された境界ボックスの使用を除外するステップを含む。

一実施形態のデータは、深度センサからのデータを含む。

この方法は、深度センサのデータを入力解像度から第１解像度にダウンサンプリングすることによって、第１深度画像を形成するステップを含む。

一実施形態の指向性ピークの検出は、複数の直交方向のいずれかにおいて、その空間的隣接画素よりも遠くに延びるピーク画素を識別するステップを含む。

一実施形態のブロブの検出は、各ピーク画素をブロブのシードとして指定し、最大の手のサイズによってブロブを拘束することを含む。

この方法は、最大の手のサイズを、サイズ値に、予想深度誤差を表す深度依存緩慢値を加えた値として確定するステップを含む。

一実施形態のサイズ値は、約３００ミリメートル（ｍｍ）である。

一実施形態の深度誤差は、複数の隣接する生センサ読み取り値によって表される物理距離に対応する。

この方法は、ブロブ毎に、当該ブロブの境界から最も遠い画素を識別することによって、潜在的な手の中心を推定するステップを含む。

この方法は、掌の半径を使用して各ブロブを間引きするステップを含む。

一実施形態の間引きは手の画素を含み、人間の被験者の他の部分に対応する画素を除外する。

一実施形態の掌の半径は、約２００ｍｍである。

この方法は、一実施形態のブロブを拡張する拡張画素を識別するステップを含む。

この方法は、各ブロブの外側境界を探し、拡張画素を識別するステップを含む。

一実施形態の拡張画素は、ブロブの画素と同様の深度を有しブロブに隣接する画素を含む。

この方法は、拡張画素を分析して、境界長に対して小さな領域を求めるステップを含む。

この方法は、切断された拡張領域を有するブロブを間引くステップを含む。

一実施形態の有効な手のブロブにおいて、拡張領域は人間の被験者の手首に対応する。

一実施形態の物体の追跡は、第１画像におけるブロブを手の既存のトラックと照合することを含む。

この方法は、ブロブの重心と現在の速度によって拘束されるトラックの軌跡との間の最少距離にしたがって、各ブロブ／トラック対に採点するステップを含む。

この方法は、全ての一致にわたって総合スコアを最小化することによって、ブロブとトラックとの間における関連付けを最適化するステップを含む。

一実施形態の総合スコアの最小化は、スコア閾値を使用し、ブロブ／トラック対のスコアが閾値を超過するとき、少なくとも１つのブロブ／トラックが不一致である(unmatch)。

一実施形態のスコア閾値は、約２５０ｍｍである。

この方法は、残りの不一致ブロブを既存のトラックと比較するステップを含む。

この方法は、不一致ブロブが既存のトラックに空間的に近接するとき、不一致ブロブを既存のトラックに二次一致ブロブとして追加するステップを含む。

一実施形態の複数のブロブは、１つのトラックに関連付けられる。

この方法は、新たなトラックをシードするために、任意の残りの不一致ブロブを使用するステップを含む。

この方法は、古いトラックを間引くために、任意の残りの不一致ブロブを使用するステップを含む。

一実施形態のポーズの検出は、画像の第２深度画像を使用して、手のトラックに対応する画素を識別することを含む。

この方法は、深度センサのデータを入力解像度から第２解像度にダウンサンプリングすることによって、第２深度画像を形成するステップを含む。

この方法は、第１深度画像の対応する画素からある深度距離以内にある各画素において、接続成分検索(connected component search)をシードすることによって、画素を識別するステップを含み、接続成分は、極値候補に空間的に接続された第１深度画像のブロブを含む。

この方法は、識別された画素を使用して、手の中心を再度推定するステップを含み、再推定は、相対的に更に高い感度を有する三次元位置推定値を与える。

この方法は、各ブロブを複数の物体形状の内１つとして分類するステップを含み、複数の物体形状が複数の手の形状を含む。

一実施形態の分類は、ランダム化判断フォーレストを使用する。

一実施形態の各判断フォーレストは、複数の判断ツリーを含み、各ブロブの最終的な分類は、複数の判断ツリーにわたる結果を併合することによって計算される。

一実施形態の複数の判断ツリーがランダム化される。

一実施形態の複数の手形状の１つとして分類するステップは、複数の画像特徴の集合の使用を含む。

一実施形態の第１画像特徴集合は、全体的画像統計を含む。

一実施形態の全体的画像統計は、ブロブ輪郭によってカバーされる画素のパーセンテージ、検出された指先の数、ブロブの重心から指先までの平均角度、および指先の平均角度の内少なくとも１つを含む。

この方法は、高い正の湾曲の領域を識別することによって、各ブロブの輪郭から指先を検出するステップを含む。

一実施形態の第２画像特徴集合は、その全サイズによって正規化されたブロブの境界ボックス内部において各格子によってカバーされる数の画素を含む。

この方法は、各ブロブを予め指定された格子サイズにサブサンプリングするステップを含む。

一実施形態の第３画像特徴集合は、ブロブの境界ボックス内部における各格子の個々のセルの各対に対する平均深度間の差を含む。

一実施形態の第４画像特徴集合は、第１画像特徴集合と、第２画像特徴集合と、第３画像特徴集合との組み合わせを含む。

拡張領域が識別されたときに、拡張領域の中心をブロブの重心に接続するベクトルに基づいて、一実施形態の手形状の方位を推定するステップを含む。

一実施形態のセンサは、深度センサを含む。

一実施形態の深度センサは、物体の成分とセンサとの間の距離のデータを出力する赤外線（ＩＲ）深度センサである。

一実施形態のセンサは、物体を赤外線光ビームで照明する赤外線（ＩＲ）発光体を含む。

一実施形態のセンサは、ビデオ・カメラを含む。

一実施形態のビデオ・カメラは、マルチチャネル・データを出力するカラー・カメラである。

本明細書において説明した実施形態は、身体の四肢のセンサ・データを受信するステップを含む方法を含む。この方法は、センサ・データから、第１解像度を有する第１画像を生成するステップを含む。この方法は、第１画像において複数のブロブを検出するステップを含む。この方法は、複数のブロブを四肢のトラックと関連付けるステップを含む。この方法は、センサ・データから第２解像度を有する第２画像を生成するステップを含む。この方法は、第２画像を使用して、複数のブロブの内各ブロブを複数の手形状の内１つとして分類するステップを含む。

本明細書において説明した実施形態は、身体の四肢のセンサ・データを受信するステップと、センサ・データから、第１解像度を有する第１画像を生成するステップと、第１画像において複数のブロブを検出するステップと、複数のブロブを四肢のトラックと関連付けるステップと、センサ・データから第２解像度を有する第２画像を生成するステップと、第２画像を使用して、複数のブロブの内各ブロブを複数の手形状の内１つとして分類するステップとを含む方法を含む。

本明細書において説明した実施形態は、センサに結合されたプロセッサ上で実行するジェスチャ・インターフェース・アプリケーションを含むシステムを含む。このジェスチャ・インターフェース・アプリケーションは、センサによって検出された物体に対応するデータをセンサから受信する。このジェスチャ・インターフェース・アプリケーションは、データの各フレームから画像を生成する。これらの画像は、複数の解像度を表す。このジェスチャ・インターフェース・アプリケーションは、画像においてブロブを検出し、ブロブを物体のトラックと関連付けることによって物体を追跡する。このジェスチャ・インターフェース・アプリケーションは、各ブロブを複数の物体形状の内の１つに対応するものとして分類することによって物体のポーズを検出する。このジェスチャ・インターフェース・アプリケーションは、ポーズおよびトラックに応答してジェスチャ信号を生成し、このジェスチャ信号によってインターフェース・システムに結合されたコンポーネントを制御する。

本明細書において説明した実施形態は、センサに結合されたプロセッサ上で実行するジェスチャ・インターフェース・アプリケーションを含むシステムを含み、このジェスチャ・インターフェース・アプリケーションが、センサによって検出された物体に対応するデータをセンサから受信し、データの各フレームから画像を生成し、画像が複数の解像度を表し、画像においてブロブを検出し、ブロブを物体のトラックと関連付けることによって物体を追跡し、各ブロブを複数の物体形状の内の１つに対応するものとして分類することによって物体のポーズを検出し、ポーズおよびトラックに応答してジェスチャ信号を生成し、ジェスチャ信号によってインターフェース・システムに結合されたコンポーネントを制御する。

一実施形態のポーズおよびトラックの検出は、物体の三次元構造に基づく。

一実施形態のポーズおよびトラックの検出は、リアル・タイム局所セグメント化と、センサの深度データを使用する物体検出とを含む。

一実施形態の画像の生成は、少なくとも、第１解像度を有する第１画像と、第２解像度を有する第２画像とを生成することを含む。

一実施形態のブロブの検出は、第１画像においてブロブを検出することを含む。

一実施形態のポーズの検出は、第２画像においてポーズを検出することを含む。

一実施形態の物体は、人間の被験者の手であり、ポーズの検出および物体の追跡は、スケルトンを使用しない検出を含む。

このシステムは、手が、人間の被験者の身体質量の中心からの測地線距離に関して極値に対応することを判定することを含む。

一実施形態のポーズの検出および物体の追跡は、フレーム毎の極値検出を含む。

一実施形態のポーズの検出は、検出された極値を人間の被験者の部分と照合することを含む。

このシステムは、画像の第１深度画像において指向性ピークを検出することによって、極値候補を識別することを含む。

このシステムは、潜在的な手を、極値候補に空間的に接続されたブロブとして識別することを含む。

このシステムは、処理ボリュームを制限するために予め指定された境界ボックスの使用を除外することを含む。

一実施形態のデータは、深度センサからのデータを含む。

このシステムは、深度センサのデータを入力解像度から第１解像度にダウンサンプリングすることによって、第１深度画像を形成することを含む。

一実施形態の指向性ピークの検出は、複数の直交方向のいずれかにおいて、その空間的隣接画素よりも遠くに延びるピーク画素を識別することを含む。

一実施形態のブロブの検出は、各ピーク画素をブロブのシードとして指定し、最大の手のサイズによってブロブを拘束することを含む。

このシステムは、最大の手のサイズを、サイズ値に、予想深度誤差を表す深度依存緩慢値を加えた値として確定することを含む。

一実施形態のサイズ値は、約３００ミリメートル（ｍｍ）である。

一実施形態の深度誤差は、複数の隣接する生センサ読み取り値によって表される物理距離に対応する。

このシステムは、ブロブ毎に、当該ブロブの境界から最も遠い画素を識別することによって、潜在的な手の中心を推定することを含む。

このシステムは、掌の半径を使用して各ブロブを間引きすることを含む。

一実施形態の間引きは、手の画素を含み、人間の被験者の他の部分に対応する画素を除外する。

一実施形態の掌の半径は、約２００ｍｍである。

このシステムは、ブロブを拡張する拡張画素を識別することを含む。

このシステムは、各ブロブの外側境界を探し、拡張画素を識別すること。

一実施形態の拡張画素は、ブロブの画素と同様の深度を有する、ブロブに隣接する画素を含む。

このシステムは、拡張画素を分析して、境界長に対して小さな領域を求めることを含む。

このシステムは、切断された拡張領域を有するブロブを間引くことを含む。

有効な手のブロブにおいて、一実施形態の拡張領域は、人間の被験者の手首に対応する。

一実施形態の物体の追跡は、第１画像におけるブロブを、手の既存のトラックと照合することを含む。

このシステムは、ブロブの重心と現在の速度によって拘束されるトラックの軌跡との間の最少距離にしたがって、各ブロブ／トラック対に採点することを含む。

このシステムは、全ての一致(match)にわたって総合スコアを最小化することによって、ブロブとトラックとの間における関連付けを最適化することを含む。

一実施形態の総合スコアの最小化は、スコア閾値を使用し、ブロブ／トラック対のスコアが閾値を超過するとき、少なくとも１つのブロブ／トラックが不一致である。

一実施形態のスコア閾値は、約２５０ｍｍである。

このシステムは、残りの不一致ブロブを既存のトラックと比較することを含む。

このシステムは、不一致ブロブが既存のトラックに空間的に近接するとき、不一致ブロブを既存のトラックに二次一致ブロブとして追加することを含む。

一実施形態の複数のブロブは、１つのトラックに関連付けられる。

このシステムは、新たなトラックをシードするために、任意の残りの不一致ブロブを使用することを含む。

このシステムは、古いトラックを間引くために、任意の残りの不一致ブロブを使用することを含む。

一実施形態のポーズの検出は、画像の第２深度画像を使用して、手のトラックに対応する画素を識別することを含む。

このシステムは、深度センサのデータを入力解像度から第２解像度にダウンサンプリングすることによって、第２深度画像を形成することを含む。

このシステムは、第１深度画像の対応する画素からある深度距離以内にある各画素において、接続成分検索(connected component search)をシードすることによって、画素を識別することを含み、接続成分は、極値候補に空間的に接続された第１深度画像のブロブを含む。

このシステムは、識別された画素を使用して、手の中心を再度推定することを含み、再推定は、相対的に更に高い感度を有する三次元位置推定値を与える。

このシステムは、各ブロブを複数の物体形状の内１つとして分類することを含み、複数の物体形状が複数の手の形状を含む。

一実施形態の分類は、ランダム化判断フォーレストを使用する。

一実施形態の各判断フォーレストは、複数の判断ツリーを含み、各ブロブの最終的な分類は、複数の判断ツリーにわたる結果を併合することによって計算される。

一実施形態の複数の判断ツリーは、ランダム化される。

一実施形態の複数の手形状の１つとして分類することは、複数の画像特徴の集合の使用を含む。

一実施形態の第１画像特徴集合は、全体的画像統計を含む。

一実施形態の全体的画像統計は、ブロブ輪郭によってカバーされる画素のパーセンテージ、検出された指先の数、ブロブの重心から指先までの平均角度、および指先の平均角度の内少なくとも１つを含む。

このシステムは、高い正の湾曲の領域を識別することによって、各ブロブの輪郭から指先を検出することを含む。

一実施形態の第２画像特徴集合は、その全サイズによって正規化されたブロブの境界ボックス内部において各格子によってカバーされる数の画素を含む。

このシステムは、各ブロブを予め指定された格子サイズにサブサンプリングすることを含む。

一実施形態の第３画像特徴集合は、ブロブの境界ボックス内部における各格子の個々のセルの各対に対する平均深度間の差を含む。

一実施形態の第４画像特徴集合は、第１画像特徴集合と、第２画像特徴集合と、第３画像特徴集合との組み合わせを含む。

このシステムは、拡張領域が識別されたときに、拡張領域の中心をブロブの重心に接続するベクトルに基づいて、手形状の方位を推定することを含む。

一実施形態のセンサは、深度センサを含む。

一実施形態の深度センサは、物体の成分とセンサとの間の距離のデータを出力する赤外線（ＩＲ）深度センサである。

一実施形態のセンサは、物体を赤外線光ビームで照明する赤外線（ＩＲ）発光体を含む。

一実施形態のセンサは、ビデオ・カメラを含む。

一実施形態のビデオ・カメラは、マルチチャネル・データを出力するカラー・カメラである。

本明細書において説明した実施形態は、センサに結合されたプロセッサ上で実行する検出および追跡アルゴリズムを含むシステムを含む。この検出および追跡アルゴリズムはジェスチャ・インターフェースに結合される。この検出および追跡アルゴリズムは、身体の四肢のセンサ・データを受信する。この検出および追跡アルゴリズムは、センサ・データから、第１解像度を有する第１画像を生成する。この検出および追跡アルゴリズムは、第１画像において複数のブロブを検出する。この検出および追跡アルゴリズムは、複数のブロブを四肢のトラックと関連付ける。この検出および追跡アルゴリズムは、センサ・データから第２解像度を有する第２画像を生成する。この検出および追跡アルゴリズムは、第２画像を使用して、複数のブロブの内各ブロブを複数の手形状の内１つとして分類する。

本明細書において説明した実施形態は、センサに結合されたプロセッサ上で実行する検出および追跡アルゴリズムを含むシステムを含み、検出および追跡アルゴリズムがジェスチャ・インターフェースに結合され、この検出および追跡アルゴリズムは、身体の四肢のセンサ・データを受信し、センサ・データから、第１解像度を有する第１画像を生成し、第１画像において複数のブロブを検出し、複数のブロブを四肢のトラックと関連付け、センサ・データから第２解像度を有する第２画像を生成し、第２画像を使用して、複数のブロブの内各ブロブを複数の手形状の内１つとして分類する。

本明細書において記載したシステムおよび方法は、処理システムを含む、および／または処理システムの下で実行する、および／または処理システムと連動して実行する。処理システムは、当技術分野では周知のように、互いに動作するプロセッサ・ベースのデバイスまたは計算デバイスのあらゆる集合体、あるいは処理システムまたはデバイスのコンポーネントを含む。例えば、処理システムは、携帯用コンピュータ、通信ネットワークにおいて動作する携帯用通信デバイス、および／またはネットワーク・サーバの１つ以上を含むことができる。携帯用コンピュータは、パーソナル・コンピュータ、セルラ電話機、パーソナル・ディジタル・アシスタント、携帯用計算デバイス、および携帯用通信デバイスの中から選択した多数のデバイスおよび／またはデバイスの組み合わせのいずれでも可能であるが、そのように限定されるのではない。処理システムは、それよりも大きなコンピュータ・システムの中にあるコンポーネントを含むことができる。

一実施形態の処理システムは、少なくとも１つのプロセッサと、少なくとも１つのメモリ・デバイスまたはサブシステムとを含む。また、処理システムは、少なくとも１つのデータベースを含むか、またはこれに結合することができる。「プロセッサ」という用語は、本明細書において一般に使用する場合、１つ以上の中央演算装置（ＣＰＵ）、ディジタル信号プロセッサ（ＤＳＰ）、特定用途集積回路（ＡＳＩＣ）等のような、あらゆる論理演算装置を指す。プロセッサおよびメモリは、１つのチップ上にモノリシックに集積することができ、多数のチップまたはホスト・システムのコンポーネント間で分散することができ、および／またはアルゴリズムの何らかの組み合わせによって提供することができる。本明細書において記載した方法は、ソフトウェア・アルゴリズム（１つまたは複数）、プログラム、ファームウェア、ハードウェア、コンポーネント、回路の１つ以上で、いずれの組み合わせでも実現することができる。

本明細書において記載したシステムおよび方法を具体化するシステム・コンポーネントは、一緒に配置すること、または別個の位置に配置することができる。したがって、本明細書において記載したシステムおよび方法を具現化するシステム・コンポーネントは、単一のシステム、多数のシステム、および／または地理的に離れたシステムのコンポーネントとすることができる。また、これらのコンポーネントは、単一のシステム、多数のシステム、および／または地理的に離れたシステムのサブコンポーネントまたはサブシステムとすることもできる。これらのコンポーネントは、ホスト・システムの１つ以上のその他のコンポーネント、またはホスト・システムに結合されたシステムに結合することができる。

通信経路は、システム・コンポーネントを結合し、コンポーネント間においてファイルを伝達または転送するあらゆる媒体を含む。通信経路は、ワイヤレス接続、有線接続、混成ワイヤレス／有線接続を含む。また、通信経路は、ローカル・エリア・ネットワーク（ＬＡＮ）、都市エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、企業固有ネットワーク、事務所間またはバックエンド・ネットワーク、およびインターネットを含むネットワークへの結合または接続も含む。更に、通信経路は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクのような、リムーバブル固定媒体、ならびにフラッシュＲＡＭ、ユニバーサル・シリアル・バス（ＵＳＢ）接続、ＲＳ−２３２接続、電話回線、バス、および電子メール・メッセージを含む。

文脈が特に明確に要求しない限り、説明全体を通じて、「備える」(comprise)、「備えている」(comprising)等の単語は、排他的または網羅的な意味とは逆に、包含的意味で解釈することとする。即ち、「含むがそれに限定されない」という意味である。また、単数または複数を使用する単語は、それぞれ、複数または単数も含むこととする。加えて、「ここでは」(herein)、「以下では」(hereunder)、「以上」(above)、「以下」(below)および同様の趣旨の単語は、本願のいずれかの特定部分ではなく、本願全体を指すこととする。「または」という単語が２つ以上の項目の羅列に関して使用される場合、その単語は以下の単語の解釈全てに及ぶこととする。羅列における項目のいずれか、羅列における項目全て、および羅列における項目のあらゆる組み合わせ。

以上における処理環境の実施形態の説明は、網羅的であることも、記載したシステムおよび方法を、開示した形態そのものに限定することも意図していない。具体的な実施形態およびその例は、本明細書では例示の目的で記載したが、その他のシステムおよび方法の範囲内において、種々の同等な変更も可能であることは、当業者であれば認められよう。本明細書において提案した教示は、前述のシステムおよび方法だけでなく、他の処理システムおよび方法にも適用することができる。

以上で説明した種々の実施形態の要素および動作(act)を組み合わせて、更に別の実施形態を提案することができる。これらおよびその他の変更は、以上に詳細に記載した説明を参照すれば、実施形態に対して行うことができる。

Claims (126)

1. 方法であって、
   センサによって検出された物体に対応するデータを前記センサから受信するステップと、
   前記データの各フレームから画像を生成するステップであって、前記画像が複数の解像度を表す、ステップと、
   前記画像においてブロブを検出し、前記ブロブを前記物体のトラックと関連付けることによって、前記物体を追跡するステップと、
   各ブロブを複数の物体形状の内の１つに対応するものとして分類することによって、前記物体のポーズを検出するステップと、
   前記ポーズおよびトラックに応答して、ジェスチャ・インターフェースを制御するステップと、
   を含む、方法。
2. 請求項１記載の方法において、前記ポーズおよびトラックの検出が、前記物体の三次元構造に基づく、方法。
3. 請求項１記載の方法において、前記ポーズおよびトラックの検出が、リアル・タイム局所セグメント化と、前記センサの深度データを使用する物体検出とを含む、方法。
4. 請求項１記載の方法において、前記画像の生成が、少なくとも、第１解像度を有する第１画像と、第２解像度を有する第２画像とを生成することを含む、方法。
5. 請求項４記載の方法において、前記ブロブの検出が、前記第１画像において前記ブロブを検出することを含む、方法。
6. 請求項５記載の方法において、前記ポーズの検出が、前記第２画像において前記ポーズを検出することを含む、方法。
7. 請求項１記載の方法において、 前記物体が人間の被験者の手であり、前記ポーズの検出および前記物体の追跡が、スケルトンを使用しない検出を含む、方法。
8. 請求項７記載の方法であって、前記手が、前記人間の被験者の身体質量の中心からの測地線距離に関して極値に対応する、方法。
9. 請求項７記載の方法において、前記ポーズの検出および前記物体の追跡が、フレーム毎の極値検出を含む、方法。
10. 請求項９記載の方法において、前記ポーズの検出が、前記検出された極値を前記人間の被験者の部分と照合することを含む、方法。
11. 請求項９記載の方法であって、前記画像の第１深度画像において指向性ピークを検出することによって、極値候補を識別するステップを含む、方法。
12. 請求項１１記載の方法であって、潜在的な手を、前記極値候補に空間的に接続されたブロブとして識別するステップを含む、方法。
13. 請求項１２記載の方法であって、処理ボリュームを制限するために予め指定された境界ボックスの使用を除外するステップを含む、方法。
14. 請求項１１記載の方法において、前記データが深度センサからのデータを含む、方法。
15. 請求項１４記載の方法であって、前記深度センサのデータを入力解像度から第１解像度にダウンサンプリングすることによって、前記第１深度画像を形成するステップを含む、方法。
16. 請求項１１記載の方法において、前記指向性ピークの検出が、前記複数の直交方向のいずれかにおいて、その空間的隣接画素よりも遠くに延びるピーク画素を識別するステップを含む、方法。
17. 請求項１６記載の方法において、前記ブロブの検出が、各ピーク画素をブロブのシードとして指定し、最大の手のサイズによって前記ブロブを拘束することを含む、方法。
18. 請求項１７記載の方法であって、前記最大の手のサイズを、サイズ値に、予想深度誤差を表す深度依存緩慢値を加えた値として確定するステップを含む、方法。
19. 請求項１８記載の方法において、前記サイズ値が約３００ミリメートル（ｍｍ）である、方法。
20. 請求項１８記載の方法において、前記深度誤差が、複数の隣接する生センサ読み取り値によって表される物理距離に対応する、方法。
21. 請求項１７記載の方法であって、ブロブ毎に、当該ブロブの境界から最も遠い画素を識別することによって、潜在的な手の中心を推定するステップを含む、方法。
22. 請求項２１記載の方法であって、掌の半径を使用して各ブロブを間引きするステップを含む、方法。
23. 請求項２２記載の方法において、前記間引きが、手の画素を含み、前記人間の被験者の他の部分に対応する画素を除外する、方法。
24. 請求項２２記載の方法において、前記掌の半径が約２００ｍｍである、方法。
25. 請求項２２記載の方法であって、前記ブロブを拡張する拡張画素を識別するステップを含む、方法。
26. 請求項２５記載の方法であって、各ブロブの外側境界を探し、拡張画素を識別するステップを含む、方法。
27. 請求項２５記載の方法において、前記拡張画素が、前記ブロブの画素と同様の深度を有する、前記ブロブに隣接する画素を含む、方法。
28. 請求項２５記載の方法であって、前記拡張画素を分析して、境界長に対して小さな領域を求めるステップを含む、方法。
29. 請求項２８記載の方法であって、切断された拡張領域を有するブロブを間引くステップを含む、方法。
30. 請求項２９記載の方法において、有効な手のブロブにおいて、前記拡張領域が前記人間の被験者の手首に対応する、方法。
31. 請求項２５記載の方法において、前記物体の追跡が、前記第１画像におけるブロブを、前記手の既存のトラックと照合することを含む、方法。
32. 請求項３１記載の方法であって、前記ブロブと現在の速度によって拘束される前記トラックの軌跡との間の最少距離にしたがって、各ブロブ／トラック対に採点するステップを含む、方法。
33. 請求項３２記載の方法であって、全ての一致にわたって総合スコアを最小化することによって、前記ブロブとトラックとの間における関連付けを最適化するステップを含む、方法。
34. 請求項３３記載の方法において、前記総合スコアの最小化が、スコア閾値を使用し、前記ブロブ／トラック対のスコアが前記閾値を超過するとき、少なくとも１つのブロブ／トラックが不一致である、方法。
35. 請求項３４記載の方法において、前記スコア閾値が約２５０ｍｍである、方法。
36. 請求項３１記載の方法であって、残りの不一致ブロブを既存のトラックと比較するステップを含む、方法。
37. 請求項３６記載の方法であって、不一致ブロブが前記既存のトラックに空間的に近接するとき、前記不一致ブロブを既存のトラックに二次一致ブロブとして追加するステップを含む、方法。
38. 請求項３７記載の方法において、複数のブロブが１つのトラックに関連付けられる、方法。
39. 請求項３６記載の方法であって、新たなトラックをシードするために、任意の残りの不一致ブロブを使用するステップを含む、方法。
40. 請求項３６記載の方法であって、古いトラックを間引くために、任意の残りの不一致ブロブを使用するステップを含む、方法。
41. 請求項３６記載の方法において、前記ポーズの検出が、前記画像の第２深度画像を使用して、前記手のトラックに対応する画素を識別することを含む、方法。
42. 請求項４１記載の方法であって、前記深度センサのデータを入力解像度から第２解像度にダウンサンプリングすることによって、前記第２深度画像を形成するステップを含む、方法。
43. 請求項４１記載の方法であって、前記第１深度画像の対応する画素からある深度距離以内にある各画素において、接続成分検索(connected component search)をシードすることによって、前記画素を識別するステップを含み、前記接続成分が、極値候補に空間的に接続された前記第１深度画像のブロブを含む、方法。
44. 請求項４３記載の方法であって、前記識別された画素を使用して、前記手の中心を再度推定するステップを含み、前記再推定が、相対的に更に高い感度を有する三次元位置推定値を与える、方法。
45. 請求項４１記載の方法であって、各ブロブを前記複数の物体形状の内１つとして分類するステップを含み、前記複数の物体形状が複数の手の形状を含む、方法。
46. 請求項４５記載の方法において、前記分類が、ランダム化判断フォーレストを使用する、方法。
47. 請求項４６記載の方法において、各判断フォーレストが、複数の判断ツリーを含み、各ブロブの最終的な分類が、前記複数の判断ツリーにわたる結果を併合することによって計算される、方法。
48. 請求項４７記載の方法において、前記複数の判断ツリーがランダム化される、方法。
49. 請求項４５記載の方法において、前記複数の手形状の１つとして分類することが、複数の画像特徴の集合の使用を含む、方法。
50. 請求項４９記載の方法において、第１画像特徴集合が、全体的画像統計を含む、方法。
51. 請求項５０記載の方法において、前記全体的画像統計が、ブロブ輪郭によってカバーされる画素のパーセンテージ、検出された指先の数、ブロブの重心から前記指先までの平均角度、および前記指先の平均角度の内少なくとも１つを含む、方法。
52. 請求項５１記載の方法であって、高い正の湾曲の領域を識別することによって、各ブロブの輪郭から指先を検出するステップを含む、方法。
53. 請求項５０記載の方法において、第２画像特徴集合が、その全サイズによって正規化されたブロブの境界ボックス内部において各格子によってカバーされる数の画素を含む、方法。
54. 請求項５３記載の方法であって、各ブロブを予め指定された格子サイズにサブサンプリングするステップを含む、方法。
55. 請求項５３記載の方法において、第３画像特徴集合が、ブロブの境界ボックス内部における各格子の個々のセルの各対に対する平均深度間の差を含む、方法。
56. 請求項５５記載の方法において、第４画像特徴集合が、前記第１画像特徴集合と、前記第２画像特徴集合と、前記第３画像特徴集合との組み合わせを含む、方法。
57. 請求項４９記載の方法であって、拡張領域が識別されたときに、前記拡張領域の中心を前記ブロブの重心に接続するベクトルに基づいて、前記手形状の方位を推定するステップを含む、方法。
58. 請求項１記載の方法において、前記センサが深度センサを含む、方法。
59. 請求項５８記載の方法において、前記深度センサが、前記物体の成分と前記センサとの間の距離のデータを出力する赤外線（ＩＲ）深度センサである、方法。
60. 請求項５９記載の方法において、前記センサが、前記物体を赤外線光ビームで照明する赤外線（ＩＲ）発光体を含む、方法。
61. 請求項５８記載の方法において、前記センサがビデオ・カメラを含む、方法。
62. 請求項６１記載の方法において、前記ビデオ・カメラが、マルチチャネル・データを出力するカラー・カメラである、方法。
63. 方法であって、
    身体の四肢のセンサ・データを受信するステップと、
    前記センサ・データから、第１解像度を有する第１画像を生成するステップと、
    前記第１画像において複数のブロブを検出するステップと、
    前記複数のブロブを前記四肢のトラックと関連付けるステップと、
    前記センサ・データから第２解像度を有する第２画像を生成するステップと、
    前記第２画像を使用して、前記複数のブロブの内各ブロブを複数の手形状の内１つとして分類するステップと、
    を含む、方法。
64. センサに結合されたプロセッサ上で実行するジェスチャ・インターフェース・アプリケーションを含むシステムであって、前記ジェスチャ・インターフェース・アプリケーションが、前記センサによって検出された物体に対応するデータを前記センサから受信し、前記データの各フレームから画像を生成し、前記画像が複数の解像度を表し、前記画像においてブロブを検出し、前記ブロブを前記物体のトラックと関連付けることによって前記物体のポーズを検出し、各ブロブを複数の物体形状の内の１つに対応するものとして分類することによって前記物体のポーズを検出し、前記ポーズおよびトラックに応答してジェスチャ信号を生成し、前記ジェスチャ信号によって前記インターフェース・システムに結合されたコンポーネントを制御する、システム。
65. 請求項６４記載のシステムにおいて、前記ポーズおよびトラックの検出が、前記物体の三次元構造に基づく、システム。
66. 請求項６４記載のシステムにおいて、前記ポーズおよびトラックの検出が、リアル・タイム局所セグメント化と、前記センサの深度データを使用する物体検出とを含む、システム。
67. 請求項６４記載のシステムにおいて、前記画像の生成が、少なくとも、第１解像度を有する第１画像と、第２解像度を有する第２画像とを生成することを含む、システム。
68. 請求項６７記載のシステムにおいて、前記ブロブの検出が、前記第１画像において前記ブロブを検出することを含む、システム。
69. 請求項６８記載のシステムにおいて、前記ポーズの検出が、前記第２画像において前記ポーズを検出することを含む、システム。
70. 請求項６４記載のシステムにおいて、 前記物体が人間の被験者の手であり、前記ポーズの検出および前記物体の追跡が、スケルトンを使用しない検出を含む、システム。
71. 請求項７０記載のシステムであって、前記手が、前記人間の被験者の身体質量の中心からの測地線距離に関して極値に対応することを判定することを含む、システム。
72. 請求項７０記載のシステムにおいて、前記ポーズの検出および前記物体の追跡が、フレーム毎の極値検出を含む、システム。
73. 請求項７２記載のシステムにおいて、前記ポーズの検出が、前記検出された極値を前記人間の被験者の部分と照合することを含む、システム。
74. 請求項７２記載のシステムであって、前記画像の第１深度画像において指向性ピークを検出することによって、極値候補を識別することを含む、システム。
75. 請求項７４記載のシステムであって、潜在的な手を、前記極値候補に空間的に接続されたブロブとして識別することを含む、システム。
76. 請求項７５記載のシステムであって、処理ボリュームを制限するために予め指定された境界ボックスの使用を除外することを含む、システム。
77. 請求項７４記載のシステムにおいて、前記データが深度センサからのデータを含む、システム。
78. 請求項７７記載のシステムであって、前記深度センサのデータを入力解像度から第１解像度にダウンサンプリングすることによって、前記第１深度画像を形成することを含む、システム。
79. 請求項７４記載のシステムにおいて、前記指向性ピークの検出が、前記複数の直交方向のいずれかにおいて、その空間的隣接画素よりも遠くに延びるピーク画素を識別することを含む、システム。
80. 請求項７９記載のシステムにおいて、前記ブロブの検出が、各ピーク画素をブロブのシードとして指定し、最大の手のサイズによって前記ブロブを拘束することを含む、システム。
81. 請求項８０記載のシステムであって、前記最大の手のサイズを、サイズ値に、予想深度誤差を表す深度依存緩慢値を加えた値として確定することを含む、システム。
82. 請求項８１記載のシステムにおいて、前記サイズ値が約３００ミリメートル（ｍｍ）である、システム。
83. 請求項８１記載のシステムにおいて、前記深度誤差が、複数の隣接する生センサ読み取り値によって表される物理距離に対応する、システム。
84. 請求項８０記載のシステムであって、ブロブ毎に、当該ブロブの境界から最も遠い画素を識別することによって、潜在的な手の中心を推定することを含む、システム。
85. 請求項８４記載のシステムであって、掌の半径を使用して各ブロブを間引きすることを含む、システム。
86. 請求項８５記載のシステムにおいて、前記間引きが、手の画素を含み、前記人間の被験者の他の部分に対応する画素を除外する、システム。
87. 請求項８５記載のシステムにおいて、前記掌の半径が約２００ｍｍである、システム。
88. 請求項８５記載のシステムであって、前記ブロブを拡張する拡張画素を識別することを含む、システム。
89. 請求項８８記載のシステムであって、各ブロブの外側境界を探し、前記拡張画素を識別することを含む、システム。
90. 請求項８８記載のシステムにおいて、前記拡張画素が、前記ブロブの画素と同様の深度を有する、前記ブロブに隣接する画素を含む、システム。
91. 請求項８８記載のシステムであって、 前記拡張画素を分析して、境界長に対して小さな領域を求めることを含む、システム。
92. 請求項９１記載のシステムであって、切断された拡張領域を有するブロブを間引くことを含む、システム。
93. 請求項９２記載のシステムにおいて、有効な手のブロブにおいて、前記拡張領域が前記人間の被験者の手首に対応する、システム。
94. 請求項８８記載のシステムにおいて、前記物体の追跡が、前記第１画像におけるブロブを、前記手の既存のトラックと照合することを含む、システム。
95. 請求項９４記載のシステムであって、前記ブロブと現在の速度によって拘束される前記トラックの軌跡との間の最少距離にしたがって、各ブロブ／トラック対に採点することを含む、システム。
96. 請求項９５記載のシステムであって、全ての一致にわたって総合スコアを最小化することによって、前記ブロブとトラックとの間における関連付けを最適化することを含む、システム。
97. 請求項９６記載のシステムにおいて、前記総合スコアの最小化が、スコア閾値を使用し、前記ブロブ／トラック対のスコアが前記閾値を超過するとき、少なくとも１つのブロブ／トラックが不一致である、システム。
98. 請求項９７記載のシステムにおいて、前記スコア閾値が約２５０ｍｍである、システム。
99. 請求項９４記載のシステムであって、残りの不一致ブロブを既存のトラックと比較することを含む、システム。
100. 請求項９９記載のシステムであって、不一致ブロブが前記既存のトラックに空間的に近接するとき、前記不一致ブロブを既存のトラックに二次一致ブロブとして追加することを含む、システム。
101. 請求項１００記載のシステムにおいて、複数のブロブが１つのトラックに関連付けられる、システム。
102. 請求項９９記載のシステムであって、新たなトラックをシードするために、任意の残りの不一致ブロブを使用することを含む、システム。
103. 請求項９９記載のシステムであって、古いトラックを間引くために、任意の残りの不一致ブロブを使用することを含む、システム。
104. 請求項９９記載のシステムにおいて、前記ポーズの検出が、前記画像の第２深度画像を使用して、前記手のトラックに対応する画素を識別することを含む、システム。
105. 請求項１０４記載のシステムであって、前記深度センサのデータを入力解像度から第２解像度にダウンサンプリングすることによって、前記第２深度画像を形成することを含む、システム。
106. 請求項１０４記載のシステムであって、前記第１深度画像の対応する画素からある深度距離以内にある各画素において、接続成分検索(connected component search)をシードすることによって、前記画素を識別することを含み、前記接続成分が、極値候補に空間的に接続された前記第１深度画像のブロブを含む、システム。
107. 請求項１０６記載のシステムであって、前記識別された画素を使用して、前記手の中心を再度推定することを含み、前記再推定が、相対的に更に高い感度を有する三次元位置推定値を与える、システム。
108. 請求項１０４記載のシステムであって、各ブロブを前記複数の物体形象の内１つとして分類することを含み、前記複数の物体形状が複数の手の形状を含む、システム。
109. 請求項１０８記載のシステムにおいて、前記分類が、ランダム化判断フォーレストを使用する、システム。
110. 請求項１０９記載のシステムにおいて、各判断フォーレストが、複数の判断ツリーを含み、各ブロブの最終的な分類が、前記複数の判断ツリーにわたる結果を併合することによって計算される、システム。
111. 請求項１１０記載のシステムにおいて、前記複数の判断ツリーがランダム化される、システム。
112. 請求項１０８記載のシステムにおいて、前記複数の手形状の１つとして分類することが、複数の画像特徴の集合の使用を含む、システム。
113. 請求項１１２記載のシステムにおいて、第１画像特徴集合が、全体的画像統計を含む、システム。
114. 請求項１１３記載のシステムにおいて、前記全体的画像統計が、ブロブ輪郭によってカバーされる画素のパーセンテージ、検出された指先の数、ブロブの重心から前記指先までの平均角度、および前記指先の平均角度の内少なくとも１つを含む、システム。
115. 請求項１１４記載のシステムであって、高い正の湾曲の領域を識別することによって、各ブロブの輪郭から指先を検出することを含む、システム。
116. 請求項１１３記載のシステムにおいて、第２画像特徴集合が、その全サイズによって正規化されたブロブの境界ボックス内部において各格子によってカバーされる数の画素を含む、システム。
117. 請求項１１６記載のシステムであって、各ブロブを予め指定された格子サイズにサブサンプリングすることを含む、システム。
118. 請求項１１６記載のシステムにおいて、第３画像特徴集合が、ブロブの境界ボックス内部における各格子の個々のセルの各対に対する平均深度間の差を含む、システム。
119. 請求項１１８記載のシステムにおいて、第４画像特徴集合が、前記第１画像特徴集合と、前記第２画像特徴集合と、前記第３画像特徴集合との組み合わせを含む、システム。
120. 請求項１１２記載のシステムであって、拡張領域が識別されたときに、前記拡張領域の中心を前記ブロブの重心に接続するベクトルに基づいて、前記手形状の方位を推定することを含む、システム。
121. 請求項６４記載のシステムにおいて、前記センサが深度センサを含む、システム。
122. 請求項１２１記載のシステムにおいて、前記深度センサが、前記物体の成分と前記センサとの間の距離のデータを出力する赤外線（ＩＲ）深度センサである、システム。
123. 請求項１２２記載のシステムにおいて、前記センサが、前記物体を赤外線光ビームで照明する赤外線（ＩＲ）発光体を含む、システム。
124. 請求項１２１記載のシステムにおいて、前記センサがビデオ・カメラを含む、システム。
125. 請求項１２４記載のシステムにおいて、前記ビデオ・カメラが、マルチチャネル・データを出力するカラー・カメラである、システム。
126. センサに結合されたプロセッサ上で実行する検出および追跡アルゴリズムを含むシステムであって、前記検出および追跡アルゴリズムがジェスチャ・インターフェースに結合され、前記検出および追跡アルゴリズムが、身体の四肢のセンサ・データを受信することと、前記センサ・データから、第１解像度を有する第１画像を生成することと、前記第１画像において複数のブロブを検出することと、前記複数のブロブを前記四肢のトラックと関連付けることと、前記センサ・データから第２解像度を有する第２画像を生成することと、前記第２画像を使用して、前記複数のブロブの内各ブロブを複数の手形状の内１つとして分類することとを含む、システム。