特許 5698733 三空間入力の検出、表現、および解釈：自由空間、近接、および表面接触モードを組み込むジェスチャ連続体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5698733

(24)【登録日】2015年2月20日

(45)【発行日】2015年4月8日

(54)【発明の名称】三空間入力の検出、表現、および解釈：自由空間、近接、および表面接触モードを組み込むジェスチャ連続体

(51)【国際特許分類】

   G06F 3/042 20060101AFI20150319BHJP

   G06T 7/20 20060101ALI20150319BHJP

   G06F 3/0346 20130101ALI20150319BHJP

   G06F 3/01 20060101ALI20150319BHJP

【ＦＩ】

   G06F3/042 473

   G06T7/20 300A

   G06F3/033 422

   G06F3/01 310A

【請求項の数】27

【全頁数】95

(21)【出願番号】特願2012-509917(P2012-509917)

(86)(22)【出願日】2010年5月4日

(65)【公表番号】特表2012-526328(P2012-526328A)

(43)【公表日】2012年10月25日

(86)【国際出願番号】US2010033613

(87)【国際公開番号】WO2010129599

(87)【国際公開日】20101111

【審査請求日】2013年5月7日

(31)【優先権主張番号】61/175,374

(32)【優先日】2009年5月4日

(33)【優先権主張国】US

(31)【優先権主張番号】12/553,845

(32)【優先日】2009年9月3日

(33)【優先権主張国】US

(31)【優先権主張番号】12/572,689

(32)【優先日】2009年10月2日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】507266336

【氏名又は名称】オブロング・インダストリーズ・インコーポレーテッド

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100075270

【弁理士】

【氏名又は名称】小林 泰

(74)【代理人】

【識別番号】100080137

【弁理士】

【氏名又は名称】千葉 昭男

(74)【代理人】

【識別番号】100096013

【弁理士】

【氏名又は名称】富田 博行

(74)【代理人】

【識別番号】100153028

【弁理士】

【氏名又は名称】上田 忠

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(72)【発明者】

【氏名】アンダーコフラー，ジョン・エス

(72)【発明者】

【氏名】クレイマー，クウィンドラ・ハルトマン

【審査官】 藤原 拓也

(56)【参考文献】

【文献】 特表２００８−５３０６６１（ＪＰ，Ａ）

【文献】 国際公開第２００７／０６１０５７（ＷＯ，Ａ１）

【文献】 国際公開第２００３／０２５８５９（ＷＯ，Ａ１）

【文献】 特開平１１−０１５９８１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ３／０１，３／０３−３／０４８９

Ｇ０６Ｔ ７／００−７／６０

(57)【特許請求の範囲】

【請求項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】

請求項１記載のシステムにおいて、前記オブジェクトが、少なくとも１つの人間の手と、人間の手の少なくとも１本の指の内少なくとも一方を含む、システム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【0002】

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

【0003】

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

【0004】

本願は、２００９年９月３日に出願したＵＳ特許出願第１２／５５３，８４５号の一部継続出願である。
発明の分野
計算プロセス内および計算プロセス間におけるデータの表現、操作、および交換を含むジェスチャ主体(gesture-based)制御システムに関する実施形態について説明する。

【従来技術】

【0005】

従来のプログラミング環境は、ネットワークを跨る実行および／または多数の計算プロセス間における柔軟なデータ共有を完全にサポートしてはいない。例えば、従来のユーザが向き合う計算プラットフォームは、プロセス間でイベント・データを送信する機能を提供する。しかし、これら従来のメカニズムには全て、欠点があり、マルチプロセス・アプリケーションやマルチマシン・アプリケーションを構築することが困難となっている。例えば、従来のイベント・フレームワークは、厳格に形式が決められているため、柔軟性がなく、増々普及しつつある動的なアプリケーションの機能とのミスマッチが生ずる。また、従来のフレームワークは、２点間データ転送のみをサポートするように構成されており、このために、多数の別個のプロセスの動作(activity)を調整することが困難または不可能となる。また、従来のフレームワークは、個々のローカルなメモリ内データ構造に強く依存するため、これらのフレームワークは、ディスク上への格納またはネットワークを跨いだ送信には相応しくないものとなる。
引用による包含
本明細書において述べる各特許、特許出願、および／または刊行物は、本願において引用することにより、個々の特許、特許出願、および／または刊行物の各々が具体的にそして個々に、引用することにより本願に含まれることを示した場合と同程度にその全体が本願にも含まれるものとする。

【図面の簡単な説明】

【0006】

【図1】図１は、一実施形態の下における、三空間入力を検出、表現、および解釈するシステムのブロック図である。

【図2】図２は、一実施形態の下における、三空間入力を検出、表現、および解釈するシステムの処理を中心としたブロック図である。

【図3】図３は、一実施形態の下における、三空間入力を検出、表現、および解釈するシステムの代替ブロック図である。

【図4】図４は、一実施形態の下におけるジェスチャＩ／Ｏのブロック図である。

【図5】図５は、一実施形態の下におけるジェスチャＩ／Ｏのデータ・ファンネル(data funnel)である。

【図6】図６は、一実施形態の下におけるジェスチャＩ／Ｏのジェスチャ・エンジンである。

【図7】図７は、一実施形態の下における、ディストリビュータ(distributor)のアノニマス(anonymous)非同期レポジトリ配信メカニズムのブロック図である。

【図8】図８は、一実施形態の下におけるディストリビュータの受取先指定(directed recipient)配信メカニズムのブロック図である。

【図9】図９は、一実施形態の下における、空間連続体入力システムのブロック図である。

【図10】図１０は、一実施形態の下における、ジェスチャ制御システムのブロック図である。

【図11】図１１は、一実施形態の下における標識タグの図である。

【図12】図１２は、一実施形態の下におけるジェスチャ・ボキャブラリにおけるポーズの図である。

【図13】図１３は、一実施形態の下におけるジェスチャ・ボキャブラリにおける方位の図である。

【図14】図１４は、一実施形態の下におけるジェスチャ・ボキャブラリにおける２つの手の組み合わせの図である。

【図15】図１５は、一実施形態におけるジェスチャ・ボキャブラリにおける方位配合の図である。

【図16】図１６は、一実施形態の下におけるシステム動作のフロー図である。

【図17A】図１７Ａは、一実施形態の下におけるコマンドの一例である。

【図17B】図１７Ｂは、一実施形態の下におけるコマンドの一例である。

【図18】図１８は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。

【図19】図１９は、一実施形態の下における、プロテインのブロック図である。

【図20】図２０は、一実施形態の下における、デスクリップ(descrip)のブロック図である。

【図21】図２１は、一実施形態の下における、インジェスト(ingest)のブロック図である。

【図22】図２２は、一実施形態の下におけるスロー(slaw)のブロック図である。

【図23A】図２３Ａは、一実施形態の下において、プールの中にあるプロテインのブロック図である。

【図23B-1】図２３Ｂ−１は、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。

【図23B-2】図２３Ｂ−２は、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。

【図23C】図２３Ｃは、一実施形態の下においてプロテインを用いる際のフロー図である。

【図23D】図２３Ｄは、一実施形態の下において、プロテインを組み立てるまたは発生する際のフロー図である。

【図24】図２４は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。

【図25】図２５は、多数のデバイスと、これらのデバイスの１つ以上で起動する多数のプログラムとを含み、一実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。

【図26】図２６は、多数のデバイスと、これらのデバイスの１つ以上で起動する多数のプログラムとを含み、一実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。

【図27】図２７は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されており、別の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。

【図28】図２８は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されており、更に別の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。

【図29】図２９は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されており、更に別の代替実施形態の下において、更に別の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする処理環境のブロック図である。

【図30】図３０は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されており、追加の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる処理環境のブロック図である。

【発明を実施するための形態】

【0007】

空間追跡データの複数のソースから低レベル・データを処理するシステムおよび方法について説明する。これらのシステムおよび方法の実施形態は、以下で詳細に説明する空間動作環境（ＳＯＥ）のコンテキストにおいて提示することとする。ＳＯＥは、ジェスチャ制御システム、またはジェスチャ主体制御システムを含み、空間ユーザ・インターフェース（ＳＵＩ）または空間インターフェース（ＳＩ）と代わりに呼ぶこともできる。

【0008】

図１は、一実施形態の下における三空間入力を検出、表現、および解釈するシステム１０のブロック図である。システム１０の実施形態は、ＳＯＥ５のコンテキストでは、空間追跡データの複数のソースから低レベル・データ１を処理し、これら意味的に相関付けられていない空間時間データを分析し、１組の動的に構成可能な暗示的および明示的ジェスチャ記述２にしたがって高レベル・ジェスチャ・イベント３を発生する。生成されたイベント３は、インタラクティブ・システム（図示せず）による消費(consumption)に適しており、本実施形態は、これらのコンシューマ(consumer)へのイベント配信を制御し実行する１つ以上のメカニズム４を設ける。本実施形態は、更に、そのイベント３のコンシューマに、任意の空間および意味規準フレーム間でジェスチャ・イベントを変換する機能も設ける。

【0009】

本明細書における実施形態にとって中心になるのは、ジェスチャの概念的ドメインが空間および意味的連続体６であるという断定(assertion)である。連続体６の一端には、完全に拘束されない自由空間ジェスチャ入力６Ａがあり、１つ以上の手が協同して三次元空間に渡る曲線軌道を記述し、同時に、時間の経過と共に集合的な指のポーズが徐々に現れる。他端には、表面接触入力６Ｄがあり、１本以上の指が一次元または二次元の多様体(manifold)上に位置するという「制約を受ける」（文献では、この形態を「接触主体入力」(contact-basedinput)と呼ぶ場合が多い）。これら両極の間には、タッチ(touch)の加工(elaboration)があり、「ホバー入力」(hover input：空中浮揚入力）６Ｃと呼ぶことができる。ここでは、指が多様体に近接したままでいるが、それに接触していない。このような接触(contact)要件の緩和によって、設定しようとする自由度を増すことが可能になる。更に一般的には、「近接入力」６Ｂについて述べることは有用である。近接入力とは、１つ以上の表面に対して定められた近接範囲内でジェスチャを行うこと、または特定の立体的空間にジェスチャが制限されることである。各ジェスチャ「分類」は、次々に移り変わる、即ち、自由空間６Ａから、近接６Ｂへ、ホバー６Ｃへ、そしてタッチ６Ｄになること、更に、このような分類の各々は適正に、形式的に、そして幾何学的に次の分類を包含することは明白である。同様に、この「ジェスチャ入力」の連続体６は、人間の手には全く限定されず、標識が付けられた物理的オブジェクトまたはそれ以外の追跡可能な物理的オブジェクトも入力連続体６における有効な関与物であることは言うまでもない。

【0010】

本明細書における実施形態は、入力連続体６に沿った点を考察することができる２つの方法間における区別を明らかにする。検知(sensing)の観点から、異なる入力メカニズムは、連続体６の異なる領域に呼応する(subscribe)ことが明らかである。高忠実度モーション・キャプチャ・リグは、例えば、６自由度の自由空間入力６Ａを供給するように思われ、一方電界検知装置は、ホバー型入力６Ｃを発生するように思われ、そして典型的な容量型検知ユニットは、タッチ入力６Ｄを報告するように思われる。イベント消費の観点から、つまり意味論の観点からは、低レベルのイベントの起源は、殆ど関心が持たれないのが当然であり、実際に、同じイベントを異なる表現（例えば、自由空間ジェスチャとして、そしてホバー・ジェスチャとして）に表出したものとして理解できると非常に有益であることが多い。しかしながら、従来の成果では、２つの観点を合体させる傾向があった。即ち、他のシステムは、通例、タッチ・スクリーンの表面を、例えば、必然的にそして専ら二次元タッチ・イベントを発生するものとみなす。

【0011】

逆に、２つの観点間における区別を維持することは、本明細書において記載する実施形態の進歩の１つである。図２は、一実施形態の下における三空間入力を検出、表現、および解釈するシステム１０の処理を中心としたブロック図である。一実施形態の第１段階１１では、本質的に異なるソースの集合体から低レベル入力を照合し、均一に表現された空間時間データの１つのストリームに様々に生成された低レベル・イベントを一致させる。第２段階１２では、一致させた低レベル・データを解析して、意味的に有意なジェスチャ・イベントを求め、これらを中立であるが完全にはっきりと表現された形態で表す。第３段階１３では、得られた中立イベントをコンシューマに配信し、コンシューマがいずれのイベントでもローカルに最適な意味形態に変換することができる機能を提供する。したがって、例えば、一実施形態では、指毎に忠実度が高い６自由度入力を用いて、テーブル表面を基準としてタッチ・イベントを生成する。この場合、表面自体には器具は取り付けられていないが、代わりに数学的に、幾何学的構造として表されるので、特殊なタッチ感応ハードウェアがなくても、計算上、幾何学的交差によって、タッチを推測することができる。端的に言うと、本実施形態の数学的表現(formalism)が、変化に富む空間入力の完全に一般的な行使を可能にする。

【0012】

本実施形態の説明は次のようになっている。この説明は、以下のように構成されている。（１）実施形態についてのより大きなコンテキスト。実施形態が重要な役割を演ずるシステムの典型的な生態環境(ecology)。（２）実施形態を構成する３つのパイプライン状コンポーネントの概要。（３）これら３つのコンポーネントの詳細な説明、および各々についての補助的な図示例。（４）パイプラインの第２コンポーネントの完全な実施態様。（５）本実施形態によって実施可能な異なるインタラクティブ・システムを例示する４つのシナリオ。

【0013】

以下の説明では、本明細書において説明する実施形態の完全な理解が得られるように、そして実施形態についての説明が可能となるように、多数の具体的な詳細を導入する。しかしながら、これらの実施形態は、これらの具体的な詳細の１つ以上がなくても、または他のコンポーネント、システム等を用いても実施できることは、当業者には認められよう。一方、開示される実施形態の態様を曖昧にするのを避けるために、周知の構造または動作については、図示しないか、または詳細に説明しないこととする。

【0014】

以下の用語が本明細書において用いられる場合、以下の一般的な意味を持つことを意図している。「プロセス」という用語は、本明細書において用いられる場合、分離可能なプログラム実行コンテキストを意味する。コンピュータ・アーキテクチャおよびオペレーティング・システムは、プロセス実施の技術的詳細において相違する。本明細書において記載するメカニズムは、広範囲のプロセス実施態様に跨って動作し、できるだけ多い利用可能な計算リソースを利用する混成アプリケーション設計またはコンフィギュレーションを容易にするように構成されている。

【0015】

「デバイス」という用語は、本明細書において用いる場合、１つ以上のプログラムまたはアルゴリズムを起動させるあらゆるプロセッサ主体デバイス、１つ以上のプログラムまたはアルゴリズムの下で起動するあらゆるプロセッサ主体デバイス、および／または１つ以上のプログラムまたはアルゴリズムを起動させる、および／または１つ以上のプログラムまたはアルゴリズムの下で起動するプロセッサ主体デバイスに結合または接続されているあらゆるデバイスを意味する。「イベント」という用語は、本明細書において用いる場合、起動している即ち実行中のプログラムまたはアルゴリズム、プロセッサ主体デバイス、および／またはプロセッサ主体デバイスに結合または接続されているデバイスと関連のあるあらゆるイベントを意味する（例えば、イベントは、入力、出力、制御、状態、状態変化、動作(action)、データ（データのフォーマットや、データと関連のある処理における段階には無関係）等を含むことができるが、これらに限定されるのではない）。

【0016】

前述のように、本システムおよび方法の実施形態は、空間動作環境（ＳＯＥ）のコンテキストにおいて提示する。ＳＯＥは、完成されたアプリケーション開発および実行プラットフォームであり、いくつかの点でオペレーティング・システムに類似する。しかしながら、ＳＯＥは、実世界三次元幾何学、およびコンピュータと人間の操作者との間における効率的な広帯域幅対話処理の双方を提供する優位性があり(privilege)、したがって洗練されたインターフェース方式を実現する。一方、ＳＯＥは、このような豊富で微妙な差異があるインターフェースの要件には不適当な、多くの従前からのＯＳサービスおよびアーキテクチャを、新たな低レベルおよび中間レベルのシステム・インフラストラクチャと置き換える。

【0017】

図３は、一実施形態の下における、三空間入力を検出、表現、および解釈するシステム２０の代替ブロック図である。システム２０は、ＳＯＥ５のコンテキストにおいて動作している。ＳＯＥ５の主要なコンポーネントは、ジェスチャＩ／Ｏ１４、ネットワーク系データ表現、通過(transit)、および交換部１５、ならびに空間一致ディスプレイ・メッシュ１６である。ＳＯＥ５のコンポーネントの各々について、以下に詳細に説明する。

【0018】

一実施形態のジェスチャＩ／Ｏ１４を説明するにあたり、人間の手の組み合わせ位相幾何学的な関わり合い(combinatoric implications)、つまり、その全体的な位置および向き、ならびにその指の屈曲の集合体によって形成される「ポーズ」、そして殆どの人間が享有する細やかな運動制御の調和には、手主体のジェスチャ(hand-based gesture)が、ＳＯＥ入力システムにおけるきわめて重要な外部コンポーネントとなる。つまり、ＳＯＥ５は、三空間の大きさ全域において高い忠実度で手を追跡する。他の従属的オブジェクト（例えば、ディジタル・コンテンツを伝えるまたは操作するための物理的な、そして多くの場合掴むことができる「ツール」）を追跡することもできる。ジェスチャ型対話処理は、殆どの場合、視覚、聴覚、および触覚ドメインにおいて動作する二次元および三次元ディスプレイ上に描写される動的実態を参照して行われる(undertake)ことが多い。アクティブ・フィードバック「グリフ」(glyph)は、（ａ）システムの瞬時的なおよび進行中のジェスチャ入力の解釈を操作者に知らせるため、（ｂ）システム状態およびローカルのジェスチャ履歴に基づいて可能なジスチャの「次のステップ」を列挙するため、そして（ｃ）ジェスチャ・シーケンスによって近いうちに起こる操作上の結末のスケッチのような「プレビュー」を提供するために、ＳＯＥのディスプレイ群の同時使用を行う。

【0019】

構造的に、ＳＯＥのジェスチャＩ／Ｏ１４システムの入力部は、ほぼ線形パイプラインの形態を取る。最も早い段階においては、パイプラインは、データ・ストリーム／ソースＳＹ（Ｙは、いずれかの数値、１，２，．．．である）のあらゆる数、タイプ、および／または組み合わせを含む、可能な複数のソースからの空間追跡情報を処理し、相関付け、そして繋ぎ合わせるように動作し、続いて、個々のエレメントを収集して、既知の構成および望ましさ(desirability)を求める（例えば、最初別々と見なされた指が、纏められて手全体の表現となる）。パイプラインの第２段階は、第１段階の結果を解釈し、ジェスチャ発生を検出し明確にしようとするジェスチャ・エンジンである。第３段階では、中間レベル表現の「イベント」がイベント・コンシューマに受け渡され、イベント・コンシューマは、ＳＯＥ機能を利用して、これらの包括的イベントを、幾何学的にローカルな状況に関係のある形態に変換することができる。

【0020】

一実施形態のネットワーク系データ表現、通過、および交換部１５は、「プラズマ」と呼ばれるシステムを含む。「プラズマ」は、以下で詳しく説明するような、サブシステム「スロークス」、「プロテイン」、および「プール」を含む。スロークス（「ｓｌａｗ」の複数）は、自己記述データ構造であり、原始的形態、複素数、ベクトル、クリフォード(Clifford)（または、「マルチベクトル」）、およびアレイ・エンティティに対する基礎的サポートを含む、数値タイプ(numeric type)のストリングおよび広範な集合体、ならびに任意にネスティング可能な集計形態(aggregate form)、即ち、「コンス」ダイアッド(cons dyad)，異質リスト(heterogeneous list)、および一意に統一された連携リストを含む。プロテインは、多数のスロークスの規定された構造のカプセル化である。「デスクリップ」と呼ばれるスロークス（通常ではストリング）の任意長連結が、検索に便利なプロテインの記述を与える。一方、キー値コンス・ダイアッドの任意長の連結は、「インジェスト」と呼ばれ、プロテインのデータ・ペイロードを形成する。一実施形態では、プロテインは、それら自体、スローの特定の種(species)である。プールは、プロテインの永続的な、線形連続集合体である。任意に多くのプロセスが所与のプールに並列に接続することができる。接続されている各プロセスは、プロテインをプールの中に預け入れ、プロテインをプールから引き出すか、または双方を行う。低レベルのプール・メカニズムは、ローカル・マシン上におけるプール・トランザクション、および離れて（ネットワークを通じて）行われるトランザクションは、プログラマおよび実行コードの視点からは、区別不可能であることを保証する。離れたプロセスによって預け入れられたプロテインを読み出すと、カプセル化されている全てのスロークスが自動的に一致するので、ハードウェアおよびアーキテクチャ特定のデータ・フォーマットの相違（例えば、エンディアンネス(endianness)）は、公にされずに解決される。プールは、概念的に無限の容量および時間的期間を有するので、プロセスは、いずれの時点でも、プールの履歴全域において逆方向に「巻き戻す」ことができ、古い方のプロテインにアクセスすることができる。プラズマを実施すると、特別に最適化される。このようにプールによって仲介されるプロテインは、インターフェース・イベント、システム・イベント、プロセス間メッセージング、高密度媒体のストリーミング、構造化データの交換等に、非常に望ましい表現メカニズムを形成する。更に、プラズマ・システムを備えることによって、プロテインの相互交換によって調整された、独立したモジュール状プロセスの生態環境として、複雑な「アプリケーション」の構築を可能とし、そして促進する。

【0021】

前述のように、一実施形態のＳＯＥ５は、空間的に一致するディスプレイ・メッシュ１６を含む。ＳＯＥ５の中心的な前提は、計算プロセスの外部への明示、即ち、プロセスがその状態を表し情報を表現する手段となる視覚的、聴覚的、および触覚的表示は、それらが物理的に埋め込まれる実世界空間に、それら自体が論理的に一致しなければならないということである。つまり、ＳＯＥ５は、各プログラム・レベルにおいて、三次元幾何学的形状の記述および操作のための基本的構造のシステムを提供する。

【0022】

幾何学的形状(geometry)は、常に「実世界」座標枠において記述され、このような座標は、ＳＯＥ５が存在する部屋(room)、即ち空間の記述に適することが熟慮されている。したがって、例えば、ＳＯＥ５によって制御される二次元視覚ディスプレイ（例えば、モニタ）はいずれも、その画素解像度の記述だけでなく、その物理的サイズ、位置、および当該部屋における向きの記述も維持する。これが意味するのは、ディスプレイ上にある個々の画素は実世界の位置および広がりを有するということであり、同様に、そのデバイス上に表示されるグラフィック構造は、真正の物理的（部屋に適合した）幾何学的形状を有することを意味する。この幾何学的形状に基づく表現方式は、同じ幾何学的形状および座標系がＳＯＥの入力システムによっても採用されているので、直接的で本質的な意味を有する。その結果、ＳＯＥ５は、同じ位置に置かれた入力および出力を供給する。操作者がある距離から画面上に表示されているグラフィック・オブジェクトを指し示すとき、システムは、知ることができる幾何学的関係によって、同じ三空間連続体の中に操作者とグラフィクスがあると論理的に考えることができる。したがって、何が指し示されているのか判断する交点計算は、数学的には取るに足らぬものであり、グラフィック・オブジェクトは直ちに操作者の操作に反応するか、またはそれ自体が操作者の操作に従うことができる。一方、その結果得られる空間的な因果関係から、グラフィクスが操作者と共にその部屋にあるという操作者の知覚および認識による確信が得られ、そして関連のあるあらゆる意味において、このような確信は正しい。現在他に勝っている人間／機械インターフェースによって誘発される期待および様式は、これによって、貴重な反転を受け、「直接空間操作」の枠組みが得られる。

【0023】

ＳＯＥ５は、互いに素な空間（例えば、特権視覚ディスプレイ群間で２つ以上の別々の対話処理サイトを「繋ぎ合わせる」遠隔協力システムのような）を幾何学的に関係付け、異なるローカル基準フレームにおける解釈を可能にするために幾何学的構造を変換するために、更に別の機能も備えている。最後に、ＳＯＥ５は、「縮小幾何学的形状」、即ち、接続空間（即ち、ユークリッド、ミンコウスキー、アンチ・デ・シッタ(anti de Sitter)等）形態を通じて有意に理解することができないデータ間における論理的関係のために、楽に判読できる表現を提供する。ここでは、ＳＯＥは、基本的トポロジ表現を提供する。

【0024】

本明細書において記載する実施形態は、ＳＯＥ５のジェスチャＩ／Ｏシステム１４の入力側の主要部分を形成する。本実施形態は、非常に低レベルの（意味的には、「信号レベル」）の入力を、遙かに高度に構造化された、象徴的で、コンテキスト特定の入力に変換し、例えば、更に高いレベルのＳＯＥコンポーネントによる消費に適するようにする、パイプラインに類似するとみなすことができる。しかしながら、これは、本実施形態が、非構造化、純粋に文字通りの、またはコンテキスト貧弱モードで動作すると言うのではない。パイプラインのきわめて重要な有効性の多くは、ＳＯＥのコンポーネント・システムの他のものに属する高レベル幾何学的および計算的コンテキストへの、障害のないアクセスから得られる。

【0025】

図４は、一実施形態の下における、ジェスチャＩ／Ｏ１４のブロック図である。要約すると、ジェスチャＩ／Ｏ１４の一番早い段階、即ち、概念的「データ・ファンネル」２０は、可能な複数のソースからの空間追跡情報を処理し、相関付け、繋ぎ合わせるように動作する。例えば、一実施形態のパイプラインの一部をなすＳＯＥ５は、（ａ）別個のボリュームを配給する様々なモーション追跡デバイス、（ｂ）個々のワークステーションの近傍において視野追跡(vision tracking)を行う範囲制約マシン(constrained-purview machine)、ならびに（ｃ）大きな投影テーブルと関連付けられた電界分析近接およびタッチ検知を調整して、同時に使用することができる。ファンネル２０は、いずれの数、タイプ、および／または組み合わせのデータ・ストリーム／ソースＳＹ（Ｙはいずれかの数値、１、２、．．．）からの低レベル空間イベントであっても、（全域的な部屋の空間を基準として）適合座標表現でレンダリングする。その直後に、ファンネル２０は、しかるべき場合に、ありのままの(literal)幾何学的および意味的特性を表現する論理的集合を発生する（１つの手の指を個々に追っていくと、この段階において、非常に正確な全体的な位置および方位が、長短短格のポーズ(dactylic pose)の簡潔な表記と共に得られる）。

【0026】

これらの基本的イベントは、入力システムの第２段階、即ち、「ジェスチャ・エンジン」２１に受け渡される。ジェスチャ・エンジン２１の作業は、個々のプロセス、アクティブな計算オブジェクト、システム全体の通知構造等にとって関心があるかもしれない個々の空間時間状況、即ち、「ジェスチャ」を検出し、解明することである。ジェスチャ・エンジン２１の動作は、１組の空間時間規則、即ち、個々のジェスチャの記述またはジェスチャのクラスによって誘導され、これらの規則は静的または動的に構成することができる。このエンジンは、検出されたジェスチャ状況を明確に表現する、詳細であるが中立的な記述データ・バンドル（「プロトイベント」(protoevent)）を生成する。

【0027】

最後に、ジェスチャＩ／Ｏ１４の第３段階２２は、ジェスチャ・エンジンによって放出されたプロトイベントを、プログラム的にそれと接触し得るような、イベント消費メカニズムに配信する。各イベント・コンシューマは、第３段階によって提供される機能にアクセスすることができる。この機能は、プロトイベント・バンドルを「ローカルな観点で」レンダリングし直す。即ち、特定のローカルな幾何学的形状に関して空間−意味的な形態でイベントを表現し直すことができる。例えば、人差し指および中指が「勝利の象徴」であるＶを形成した手を画面に向けて押し出すと、正確な三空間部屋の位置における１つの姿勢を示す外形としてレンダリングすることができ、あるいは、画面に対する手全体の近接状態として、あるいは各指が別々に考慮された、タッチ寸前イベントの集合体(constellation)としてレンダリングすることができる。

【0028】

図５は、一実施形態の下における、ジェスチャＩ／Ｏ１４のデータ・ファンネル２０である。データ・ファンネル２０は、ここでは入力ファンネル２０とも呼ばれ、低レベル空間入力データ１（意味的な観点から、「信号レベル」）を、ジェスチャ・エンジン・レディ（ＧＥＲ：gesture-engine-ready）データ２７の時間解明ストリームに変換し、このストリームは、パイプラインの第２段階、即ち、ジェスチャ・エンジン２１に供給される。データ・ファンネル２０によって実行される変換は、低レベル入力データを収集し、時間的に整合し（２３）、空間的に繋ぎ合わせ（２４）、１つの合成（「適合」）データ・ストリームを形成する。続いて、ファンネルは、適合データの特権部分集合を識別し、各部分集合をエントロピ減少意味的集合体に組み立てる（２５）。

【0029】

ファンネルは、入力として、１つ以上の空間時間データ・ストリームＳＹ（Ｙはいずれかの数値、１，２，．．．）を受け取る。データ・ストリームＳＹは、本来異なる自由度のカウントを表すことができる。光学的モーション追跡システムは、通例、しかるべく指を個々に追っていくと、それらを高い忠実度で、６自由度（３つは並進、３つは回転）で解明することができる。飛行時間に基づくカメラは、用いられる分析方法に基づいて、手の指について３、５、または６自由度のデータを供給する。電界検知リグは、手の全体的塊の位置を記述する３つのＤＯＦ情報を、位置に依存する別々の分解能で供給することができる。タッチ・スクリーンは、物理的接触制約を受ける二次元追跡情報を放出することができる、などがあげられる。データ・ストリームＳＹは、異なるレートで個々の空間時間イベントを供給することができる。データ・ストリームＳＹは、例えば、追跡されている手または他の物体が、検知メカニズムによって扱われる立体空間に出入りするときのように、間欠的であってもよい。

【0030】

データ・ストリームＳＹは、入手可能であるならば、表される空間および時間量の精度の推定値、または誤差可能範囲を含む。例えば、電界検知リグからのデータ・ストリームは、各イベントに空間誤差の評価を施し、このようなデバイスでは、ローカルなｘおよびｙ（「平面」）軸に沿った場合とローカルｚ（「距離」）軸に沿った場合で異なるだけでなく、真の空間位置の関数として全体的な大きさも変動する。このような精度の注釈は、データ・ストリームの「受信された」エレメントであってもよく（デバイス自体またはデバイスのドライバがそれを供給できる場合）、またはファンネルの以前の処理によって推論してもよい（発信元デバイスの動作のモデルを維持している場合）。

【0031】

ファンネル２０のコンポーネントは、複数のデータ・ストリームＳＹを時間的に整合する（２３）。ファンネル２０は、このような整合を様々な別個の方法で遂行するように構成することができる。整合方式２３は、以下を含むが、これらに限定されるのではない。（１）内挿補間によって、１つ以上のデータ・ストリームからあらゆる「実」時間イベント・インスタンスにおける全ての他のデータ・ストリームからの「仮想」空間時間イベントを供給する。（２）内挿補間によって、データ・レートが最も高いストリームにおける各時間的イベント・インスタンスにおいて、他のストリームの各々からの仮想イベントを供給し、他のストリームの「実」イベントを破棄する。（３）前述と同様であるが、明示的に指定されたストリームを「かちかち音がするメトロノーム」のように用い、他の全てのストリームをこれに整合させる。（４）以上のようにして、しかし全てのストリームが内挿補間されるように、外部から加えられたメトロノームのかちかち音がストリームのいずれとも一致しない。時間的整合２３の結果、各タイムステップにおいて、データ・ストリームに対する可能な多数の表現イベントが放出され、タイムスタンプ毎の集計が、同じ「目的]（実世界）イベントに可能な代替解釈を提供する。整合後に得られる各イベントは、可能な場合には、その一意の固体識別(identity)の表現（例えば、しかるべく追っていったときまたは信頼性高く推論したときの特定の指または物体）を含む。このような固体識別情報は、同じ実世界イベントの代替表現から１つの空間イベントを合成しなければならないときというような、後続の処理に有用である。時間的整合２３の動作が、コンポーネント自由度の推定誤差または精度範囲を変化させる場合、それにしたがってイベントを追いかける(tag)。

【0032】

一実施形態のファンネル２０は、複数のデータ・ストリームからのイベントを繋ぎ合わせる（２４）。空間の繋ぎ合わせ２４は、常にではないが多くの場合、固体情報が添付されているイベントの事前時間的整合を予め仮定する。空間の繋ぎ合わせ２４は、一般に、各寄与イベントの可能な限り最も高いレベルの記述への促進を必要とする。このような記述の促進が、コンポーネント自由度の推定誤差または精度範囲を変化させる場合、それにしたがってイベントを追いかける。このような促進が不可能な自由度には、明示的に標識を付ける。場合によっては、この状況は、機能的にまたは明示的に、無限誤差範囲に対応する。記述促進は、単に、関与するイベントを、適合空間基準フレーム（データ・ストリームが初期状態において空間イベントをローカル・フレームで表す場合、必要に応じて）にレンダリングし直すことを伴えばよい。一方、このために、ファンネルは、各ローカル・フレームのユニバーサル（「部屋」）フレームに関する関係の概念を維持すること、またはそれにアクセスできることが必要となる。つまり、例えば、接触検知面からのタッチ・イベントが、その面のローカル（ｘ’、ｙ’）フレームにおいて初期状態で表されていると、分かっているその面の物理的外形を用いて、部屋の（ｘ、ｙ、ｚ）フレームに変換する。その場合、３つの回転自由度は、察知不能と識別される。何故なら、デバイスのデータ・ストリームからこれらを推論することができないからである。帰納(inference)および演繹(deduction)に頼る方法を含む、代わりの、もっと複雑な記述促進方法を用いることもできる。

【0033】

続いて、空間の繋ぎ合わせ２４は、同じ実世界イベントの代替記述の集合体毎に、１つの「合成」イベント（実世界イベントの最も高精度な表現であると捕らえられる）を生成する。合成方法には、（１）複数の入力データ・ストリーム間から１つの記述を選択し、残りを破棄すること（この合成イベントは「勝者総取り」である）、（２）促進された記述自由度毎に、１つの記述から対応するコンポーネント・データを選択し、残りを破棄する（この合成イベントは、コンポーネント毎の「勝者総取り」である）、（３）全ての記述に渡って各自由度コンポーネントの加重平均を求め、構成変更可能でコンテキストに感応する関数によって重みを決定する、（４）（２）および（３）の変形。合成の方法を選択する判断基準は、暗示的または明示的に固定してもよく、あるいはコンテキストに応答するように静的または動的に構成してもよい。

【0034】

一例では、立体空間(volume)は、同一のセンサの集合体によって「扱われ」、各センサは、有限範囲を有し、各々のセンサの精度は、その検知範囲の縁端に近づくに連れて低下し、これらのセンサは、その検知範囲が重複するように、空間的に配置されている。空間の繋ぎ合わせは、問題のイベントが１つのセンサの高精度範囲の内側に十分収まっている場合には、１つの記述を選択することができるが、イベントが第１センサの範囲限界付近で発生した場合、隣接するセンサのストリーム間で加重平均を求めるとよい。加重は、それぞれの検知境界に対するイベントの推定近接度に応答して、空間的に変化する。

【0035】

第２の例では、イベント・ストリームは、高忠実度光学モーション追跡部およびタッチ面を表す。空間の繋ぎ合わせは、一般に、モーション追跡部を優先するが、追跡がタッチ面に近づくと、調節機能を光学位置データに適用して、タッチ面からの距離が漸近的に減少するようにする。接触面が確定的な接触を検知したときのみ、つなぎ合わされたイベントは、幾何学的および意味的に表面と一致することが許容される。

【0036】

最後の例では、ディスプレイが背後にある表面に、高正確度電界検知装置を装備し、ステレオ深度処理を有する１対のカメラをこの表面上で訓練する。電界検知リグは、ディスプレイに近い指について（視覚システムよりも）分解能が高い位置データを供給するが、電界検知の方位検出能力は取るに足りないので、空間繋ぎ合わせによって、１つのセンサからの３つの位置成分を他のセンサの３つの方位成分と併合し、６自由度全てにおいて高い分解能を呈する合成イベントが得られる。

【0037】

空間の繋ぎ合わせ２４が時間的整合２３よりも前に行うことができるのは、ファンネルの明示的に構成変更可能なまたはコンテキスト的にトリガ可能な態様である。これは、連続的にでも間欠的にでも起こってよい。例えば、入力ストリームＳＹが、データ・レートが最も高いストリームに対して普通に整合されるように、しかし、異常イベント（例えば、指が近端閾値を交差した場合）の検出時に、全ての他のストリームを検出時点に内挿補間することによって、「省略」集計イベントを発生するように、ファンネル２０を構成することもできる。

【0038】

また、一実施形態のファンネル２０は、意味的集計２５も実行する。意味的集計２５は、直前のファンネル動作から得られた関連イベントを収集して、意味的集合体にすることを含む。このような集計収集２５が行われる際の態様またはパターンは、静的または動的に構成することができる。この段階においてファンネルが生成するように構成することができる集計は、常にではないが通例、（１）その識別および組み立てが、洗練されていない推測(inference) に従う直接的かつ因果的事項となるように、明示的に指定され、（２）普遍的な「ダウンストリーム」有用性がある。非常に普及している例では、人の手の組み立て(assembly)の識別を処理する。６ＤＯＦの幾何学的形状および各指の固体識別が信頼性高く報告されるように個々の指を追いかける入力インフラストラクチャでは、手の構成エレメントを先験的に規定することができる。すると、更に高いレベルの意味的な手の集合体を形成する動作は、単に、適合入力ストリームから、手を構成することが知られている静的固体識別と一致する固体識別を有するタグを選択することだけとなる。

【0039】

尚、この例においてであっても、コンポーネント・タグが入力ストリームにおいて報告される限り集合体を組み立てる可能性が保証されているが、出力ストリームは、結果的に得られる高レベル表現だけでなく、集合体が組み立てられた際に用いられた低レベル・タグ情報もおそらくは含むことを注記しておく。したがって、後に、このイベント情報のコンシューマには、必要なときそして必要に応じて、この低レベル・データにアクセスする可能性が与えられる（直ぐ下を参照のこと）。

【0040】

加えて、ファンネル２０は、前述の１つ異常の動作の間、メタ情報タギング(tagging)２６も実行することができる。前述の動作のいずれかにおいてまたはその一部においてメタ情報タギング２６が用いられる場合、その結果生ずるイベントは、それらの構造に関する情報を保持する。この情報は、これらが得られた元となった元来のイベントの完全なリストまたは要約したリスト、特定の合成方法に導いた判断経路などが含まれる。次いで、後のコンシューマは、これらの合成イベントを解釈し直すためまたは更に分析するために、この情報を精査することを選択してもよい。

【0041】

図６は、一実施形態の下におけるジェスチャＩ／Ｏ１４のジェスチャ・エンジン２１である。ジェスチャ・エンジン２１は、空間および幾何学的出現を表す低レベルの、意味的に生のデータ（「ジェスチャ・エンジン・レディ・データ」またはＧＥＲデータ２７）を、１つ以上の表現を類別したジェスチャ・プロトイベント３に変換する。一実施形態のＧＥＲデータ２７は、以下を含むが、これらに限定されるのではない。（１）１つの指の三空間位置、および、可能であれば方位。（２）手全体の総合的な「塊の」三空間位置および方位、ならびに手のポーズの意味的要録、即ち、全体的な指の屈曲。（３）不活性な、非生物オブジェクトの三空間位置および方位。（４）一例を挙げると操作者の手のような、他の解剖学的に関連のある構造の三空間位置および方位。

【0042】

ジェスチャ・エンジン２１は、可能な複数の別個のジェスチャ記述判断基準を調べて、種々の空間ＧＥＲデータ２７をこれらの判断基準と照合しようとする。この照合実施の結果、判断基準を満たすものがない、一部を満たす、または全てを満たすことになり、一致毎に、ＧＥＲデータ２７の内０個以上が関係付けられていたことになる。ジェスチャ・エンジン２１は、ＧＥＲデータ２７を「排他的に」扱い、１つの照合に関係付けられたデータが、第２の照合には関与しないように構成することができ、あるいは、ジェスチャ・エンジン２１は、代わりに、データが多数の照合に関与することを許容してもよい。明白な一致毎に、ジェスチャ／エンジン２１は、これに応答して、０個以上の「プロトイベント」３を用意する。これらは、一致した低レベル・データを、一致したジェスチャ判断基準の意味的コンテキストで解釈したものの要録を示す。プロトイベント３は、以下で説明するように、パイプラインの第３段階に受け渡される。

【0043】

ジェスチャ・エンジン２１は、論理的に密封された実行経路を備えることができ、この経路の中には、一定で帰ることができない１組のジェスチャ認識判断基準、または有限の１組の選択可能かつ構成変更可能なジェスチャ認識判断基準のいずれかが存在する（この選択および構成変更は、エンジンの論理的境界の外側から実行される）。しかし、一実施形態では、各認識判断基準は、「認識部」(recognizer)と呼ばれる、論理的に独立したユニットとして存在する。認識部は、ライブラリ（図示せず）から選択することができ、ジェスチャ・エンジン２１とは独立して作成することができる。この実施形態では、外部エージェンシが１つ以上の認識部を選択および構成変更し、次いで各々をジェスチャ・エンジン２１とデータ構造的に関連付ける。これは、ジェスチャ・エンジンの使用(engagement)に先だって１回行えばよく、あるいは外部エージェンシが動的にジェスチャ・エンジンの実行中に認識部を追加（２８）、除去（２９）、および／または修正あるいは構成変更（図示せず）することもできる。尚、本実施形態は、ジェスチャ・エンジン２１が、ある種の条件に応答して、それ自体が認識部を、それと関連付けて、追加（２８）、除去（２９）、および／または修正あるいは構成変更（図示せず）をすることを可能にすることを注記しておく。更に、認識部がそれ自体を除去（２９）および／または構成変更すること、あるいは同じジェスチャ・エンジン２１と関連付けて、他の認識部を追加（２８）、除去（２９）、または構成変更することも可能である。

【0044】

希な状況では、ＧＥＲデータ本体２７が時間的に単独であって、ジェスチャ・エンジンの動作が１回だけ行われるようになっていてもよいが、ＧＥＲデータ本体２７は、殆ど常に時間可変で周期的にジェスチャ・エンジン２１に提示される。この後者の場合、入力データ２７は、殆どの場合、永続的な固体識別を有しているので、認識部は、時点Ｔ＿ｎにおけるデータＤ＿ｉによって表される幾何学的情報を、時点Ｔ＿ｎ＋１におけるデータＤ＿ｊと、知り得るように関連付けることができる。Ｄ＿ｉおよびＤ＿ｊは、空間全域を動く（そして変形させる可能性もある）同じ実世界オブジェクトを表す。この説明の残り全体において、「ＧＥＲデータ」は同じ固体識別情報を保持する時間連続データの進行中の発展のことを指す、即ち、同じ実世界オブジェクトを指すことは言うまでもない。一実施形態では、認識部は、対象の入力データの空間時間起動の態様を表すために、内部状態を維持する。

【0045】

ある場合には、認識部は、１つ以上の入力データ２７の幾何学的および空間時間的状況が認識部の特定の「起動」判断基準と一致するまで、それを予期して「休眠状態」のままと成っており、判断基準と一致したときに、「アクティブ」になる。認識部は、入力データ２７が第２組の「維持」判断基準（起動判断基準と同一であっても、なくてもよい）を満たす限り、アクティブのままになっている。認識部は、入力データ２７が第２組の判断基準を満たせなくなったときに、インアクティブになる。

【0046】

認識部、つまり認識可能なジェスチャの自然なカテゴリは、（１）起動および維持判断基準が取ることができる異なる形態、ならびに（２）プロトイベントがジェスチャ・エンジンから放出される状況の考慮から生まれる。

【0047】

ジェスチャ・エンジン２１がＧＥＲデータ２７を排他的に扱うように構成されている場合、初期の照合に成功して１つの認識部によってあるデータが包含されても、このデータの使用は他のいずれの認識部にも許されない。このように、認識部は１つ以上のＧＥＲデータ２７を「取り込み」、この認識部がアクティブである期間中、これらの取り込まれたデータは、他の認識部による考慮のためには継続的に利用できないままになる。

【0048】

一実施形態では、ジェスチャ・エンジン２１は、「プライマシ・メトリック」(primacy metric)にしたがって、それに関連のある認識部を格付けすることができる。このようなメトリックは、ジェスチャ・エンジン２１が存在する間中静的であってもよく、ジェスチャ・エンジン２１の外部にあるエージェンシによって離散間隔で意志的に修正または交換してもよく、あるいはジェスチャ・エンジン２１が実行するに連れて、自動的かつ動的に、離散的または連続的に発展させてもよい。このような場合全てにおいて、ジェスチャ・エンジン２１は、プライマシ・メトリックの格付けが示唆する順序で、その複数の認識部に報酬(consideration)を与え、ジェスチャ・エンジン２１がそのように構成され、加えて入力データを排他的に扱うように配置されていると、格付けが高い方の認識部が、他の格付けが低い方の認識部によって以前に取り込まれた入力データを「不正使用」することが可能になる。この場合、データが不正使用された認識部は通知され、インアクティブ状態に戻る機会が与えられ、強制された状態変化を記述するのに必要となり得る、あらゆるプロトイベントを放出する。

【0049】

例示の目的上、ここでは、本実施態様のジェスチャ・エンジンおよびその認識部について最大限詳しく明瞭に表現した(articulate)。

【0050】

図７および図８は、異なる実施形態の下における、ジェスチャＩ／Ｏ１４のディストリビュータ２２を示す。一実施形態の「ディストリビュータ」２２は、以前のパイプライン動作によって発生したプロトイベント３を、１つ以上の次の受取先に送信する。このように送信されるプロトイベント３の主要なクラスは、ジェスチャ・エンジンによって検出されたジェスチャ・イベントを構成するが、ディストリビュータ２２は、加えて、「的確なジェスチャ」の検出および合成には関与しなかったような低い方のレベルのイベントも送信するように構成することもできる。イベント受取先および他のダウンストリーム・システムに利用可能なディストリビュータ２２の更に別の機能によって、送信されたプロトイベント３を、特定の幾何学的および意味的形態で解釈し直す（変換する）ことが可能になる。

【0051】

イベント配信のメカニズムは様々であり、ディストリビュータには、これらの任意の集合体と関わるように静的または動的に指示することができる。一実施形態の配信メカニズムは、以下を含むが、これらに限定されるのではない。アノニマスの非同期レポジトリ、指定された非同期受取先、および指定された同期受取先。配信メカニズムの説明を以下で行う。

【0052】

図７は、一実施形態の下におけるディストリビュータ２２のアノニマス非同期レポジトリ配信メカニズムのブロック図である。アノニマス非同期レポジトリ配信メカニズムの下では、ディストリビュータ２２は、ある数のオーディタ(auditor)３１への結合または接続を有することができる１つ以上のレポジトリ３０へのその接続を実施する。ディストリビュータ２２は、これらのレポジトリ３０にプロトイベント３を預ける。プロトイベント３は、後に、関与のあるオーディタ３１によって受け取られる。このようなレポジトリ３０は、ディストリビュータ２２と同じ実行空間内に存在することができ、オーディタ３１からの近接した(proximal) 接続またはばらばらの(disjoint)接続をサポートすることができる。あるいは、同じハードウェア上で別のプロセスとして存在し、ディストリビュータ２２およびオーディタ３１からの接続を、プロセス間通信プロトコルによってサポートすることもでき、あるいは遠隔ハードウェア上のプロセスとして存在し、ネットワークを通じてディストリビュータ２２およびオーディタ３１からの接続をサポートすることができ、あるいは以上のものから組み合わせた特性と共に存在することもできる。この配信パターンに共通するのは、ディストリビュータ２２がオーディタ３１の数や本質について知る必要がない（場合によっては、知ることができない）ことである。以下で詳しく説明するように、一実施形態では、このようなレポジトリを、プロテインおよびプールの配備によって実現する。

【0053】

図８は、一実施形態の下における、ディストリビュータ２２の受取先指定配信メカニズムのブロック図である。ディストリビュータ２２が非同期受取先指定配信メカニズムを含むまたは実行する場合、ディストリビュータ２２はオーディタ・リスト３２を維持する。オーディタ・リスト３２は、非同期オーディタ３３のリストを構成し、オーディタ・リスト３２の母集団(population)は静的または動的に制御される。ディストリビュータ２２は、各非同期オーディタ３３に、発生した各プロトイベント３のコピーを送信する。このような送信は、非同期様式で行われるので、非同期オーディタ３３からの受信承認は不要である。観念的に、この非同期消費モデルは、アーラン・プログラミング言語によって提供される、メッセージ受け渡し「メールボックス」通信に類似している。一実施形態では、このような非同期消費を、ミューテックス保護(mutex-protected)共有メモリ方法によって実現する。

【0054】

ディストリビュータ２２が同期受取先指定配信メカニズムを含むまたは実行する場合（引き続き図８を参照する）、ディストリビュータ２２はオーディタ・リスト３２を維持する。オーディタ・リスト３２は、同期オーディタ３３のリストを構成し、オーディタ・リスト３２の母集団は静的または動的に制御される。ディストリビュータ２２は、各同期オーディタ３３に、発生した各プロトイベント３のコピーを送信する。このような送信は同期的に行われるので、ディストリビュータの同期オーディタ３３によるイベントの受信は、制限されたプログラム時間内に暗示的または明示的に承認される。このような同期消費の最も簡単な実施態様は、コンシューマがディストリビュータ２２と同じ実行空間内にあるときに得ることができる。次いで、直接機能コールを用いて、プロトイベント３の送信を行うことができる。コンシューマがディストリビュータ・プロセスから離れている状況では、プロセス間通信技法を採用すれば、同期送信を実現することができる。

【0055】

そのイベント送信または配信動作とは独立して、そして図７および図８を参照すると、ディストリビュータ２２は、イベント変換３４のための機能(facilities)を含み、これらを利用可能にする。いずれの数のサプリカント・エンティティ(supplicant entities)ＳＥでも、このようなイベント変換要求を、同期および非同期の、先に明確に表現した手段のいずれかによってディストリビュータ２２に伝達することができ、更に、サプリカント・エンティティＳＥ自体もオーディタ３３である場合、このようなイベント変換要求は、監査(audition)と同じ通信手段を用いるためには必要とされない。変換のために提出されるイベントは、ディストリビュータ２２から発生したものであってもよく（例えば、プロトイベント３）、あるいはディストリビュータの動作の外部で合成または取得された空間時間データを表すこともできる。前者の場合、サプリカント・エンティティＳＥは、イベントをディストリビュータ２２に「再送信」することを選択し、最大限忠実にそのイベントを詳細に受け渡すことができ、あるいは、代わりに、イベントに対する参照、即ち、イベントに付随する一意の識別子を受け渡してもよく、この識別子によってディストリビュータ２２はイベントを読み出すことができる。

【0056】

サプリカント・エンティティＳＥは、単純な幾何学的イベント変換を要求することができ、この場合、イベントの基礎をなす座標系には、擬似変換が行われる。このような変換の結果、一般に、イベントの幾何学的形状の数値表現に対する変化（即ち、座標に基づく要素の変化）だけでなく、その意味的内容のある部分の数値表現に対する変化も生ずる。

【0057】

したがって、以下のように表現されるプロトイベントＥは、

【0058】

【表1】

【0059】

ｙ−軸を中心とした９０度回転、および下方平行移動（元の座標系から負方向に９０度ｙ−回転させ、上方に平行移動させた座標系における幾何学的形状の表現と等価）を受けて、以下の表現を求めることができる。

【0060】

【表2】

【0061】

尚、この場合、手の全体的な指の姿勢構成および集合的方位の意味的ダイジェストであるＧＲＩＰＥストリングも変化することを注記しておく。つまり、基本的方位を指定する最終的な２つのキャラクタが、「．−」に変換されている（「−ｘ」から）。

【0062】

ディストリビュータ２２によって実行されるイベント変換が更に複雑になると、新たなコンテキストにおけるプロトイベントの幾何学的および意味的内容の何らかの組み合わせの再解釈を伴う。上と同じプロトイベントＥ、即ち、手の人差し指および中指を広げ、親指を垂直に立て、薬指および小指を巻いた、見かけ上「指し示す」ジェスチャの例は、丁度手の前に位置する近接表示画面のローカル幾何学的コンテキストで再解釈することもできる。

【0063】

【表3】

【0064】

前述した実施形態を参照しながら、ジェスチャ・エンジンの実施態様について多くの例を以下に示す。図９は、一実施形態の下におけるジェスチャ・エンジンの実施態様９００のブロック図である。以下のジェスチャ・エンジンの実施態様では、多数の主要なエレメントを仮定し、これら主要なエレメントの各々の説明を、ジェスチャ・エンジンの実施態様９００を参照しながら以下に行う。

【0065】

以下のジェスチャ・エンジンの実施態様例の第１の主要エレメントは、ある数の被追跡エンティティの存在であり、その各々の表現は、（ａ）高忠実度全三空間位置、（ｂ）高忠実度全三空間方位、および（ｃ）エンティティの「ポーズ」の表現的記述、即ち、その付加的な自由度の半意味的ダイジェスト(semisemantic digest)で構成される。このようなエンティティを「ＧｒｉｐｅＥｎｔｓ」と呼ぶことにする（ＧｒｉｐｅＥｎｔは、前述の一般的な「ＧＥＲデータ」に対応する）。ＧｒｉｐｅＥｎｔの特に重要な種(species)は人間の手であり、その「ポーズ」は指の種々の屈曲を記述し、米国特許出願第１１／３５０６９号に明確に表現されている表現方式をおそらくは用いて表現する。

【0066】

以下のジェスチャ・エンジンの実施態様例の第２の主要エレメントは、１つ以上のソースからの低レベル空間入力データを相関付け、ＧｒｉｐｅＥｎｔｓの集合体を周期的に更新するためにそのデータを分析するシステムである。このシステムを、ここでは、「ＧｒｉｐｅＲｅｆｉｎｅｒｙ」と呼ぶ。ＧｒｉｐｅＲｅｆｉｎｅｒｙは、先に説明した「データ・ファンネル」に対応する。知覚的に満足のいく対話処理を提供するために、ＧｒｉｐｅＲｅｆｉｎｅｒｙは３０ヘルツよりも遙かに高いレートで完全な出力集合を生成しなければならない。

【0067】

以下のジェスチャ・エンジンの実施態様例の第３の主要エレメントは、「ＧｅｓｔａｔｏｒＴｏｔｓ」または「ＧＴｏｔｓ」と呼ばれるジェスチャ照合モジュールの集合体の包含である（ＧＴｏｔは、先の一般的な「認識部」に対応するが、本実施形態はそのように限定されるのではない）。各ＧＴｏｔは、いずれの時点においても、「多数」Ｓを有する。Ｓ個の別個のＧｒｉｐｅＥｎｔｓの調整は、ＧＴｏｔが表現するジェスチャの認識を成功させるために必要となる。各ＧＴｏｔは、いずれの時点においても、「待ち」状態または「アクティブ」状態のいずれかになっている。これらの状態には、ＧＴｏｔの２つの主要な実行経路、「ＥｎｔｒａｎｃｅＡｔｔｅｍｐｔ」および「ＣｏｎｔｉｎｕａｔｉｏｎＡｔｔｅｍｐｔ」がそれぞれ関連付けられており、そのいずれかまたは双方は中間レベルの対話処理イベント・データを発信することができる。第３の任意選択的な実行経路に、ＧＴｏｔの「Ｕｐｄａｔｅ」ルーチンがあり、ＧＴｏｔがその内部状態の維持に必要な追加の計算を実行するためにループ毎にその機会を与える。ＥｎｔｒａｎｃｅＡｔｔｅｍｐｔの実行により、３つの可能な結果コード、ＣＯＰＡＣＥＴＣ、ＰＲＯＭＯＴＥ、およびＥＸＣＬＵＳＩＶＥの内１つが生成される。ＣｏｎｔｉｎｕａｔｉｏｎＡｔｔｅｍｐの実行により、３つの可能な結果コード、ＣＯＰＡＣＥＴＩＣ、ＤＥＭＯＴＥ、およびＥＸＣＬＵＳＩＶＥの内１つが生成される。

【0068】

ＥｎｔｒａｎｃｅＡｔｔｅｍｐｔは、待ち状態にあるＧＴｏｔについて、利用可能なＧｒｉｐｅＥｎｔｓをＧＴｏｔの特定の入力判断基準に照らし合わせて検査する。これらの判断基準を満たす場合、ＧＴｏｔをアクティブ状態に設定し、判断基準を満たす際に関与した（１つ以上の）ＧｒｉｐｅＥｎｔｓに、捕獲済みの印を付け、そのＧＴｏｔと関連付ける。アクティブ状態にあるＧＴｏｔに対して、ＣｏｎｔｉｎｕａｔｉｏｎＡｔｔｅｍｐは、最初に、以前に捕獲されたＧｒｉｐｅＥｎｔｓが（１）まだ利用可能であること、即ち、もっと高いプライマシのＧＴｏｔによってこれらが「不正使用」(usurp)されていないか否か、そして（２）ＧＴｏｔの判断基準を引き続き空間的、意味的、およびコンテキスト的に満足することを検証するように動作する。（１）または（２）が満たされない場合、これまでに捕獲されたＧｒｉｐｅＥｎｔｓは、ＧＴｏｔとの関連から解放され、それ以外の場合、これらは捕獲されたままとなる。

【0069】

これらの論理的関係および因果関係については、以下の状態遷移の説明において詳しく解明する。

【0070】

以下のジェスチャ・エンジンの実施態様例の第４の主要エレメントは、ＧＴｏｔの集合全体を規定の順序で精査し、各々にそのＥｎｔｒａｎｃｅＡｔｔｅｍｐｔまたはＣｏｎｔｉｎｕａｔｉｏｎＡｔｔｅｍｐルーチンのいずれかを実行させる、調停エンジンの包含である。この調停エンジンを、ここでは、「Ｇｅｓｔａｔｏｒ」と呼ぶ（Ｇｅｓｔａｔｏｒは先の一般的な「ジェスチャ・エンジン」に対応するが、実施形態はそのように限定されるのではない）。Ｇｅｓｔａｔｏｒは、アクティブ状態にある全てのＧＴｏｔの動的なリスト、および待ち状態にある全てのＧＴｏｔの別のこのようなリストを維持する。これらのリストは、必然的に互いに素である。Ｇｅｓｔａｔｏｒは、１つの主要実行経路、「ＰｒｏｃｅｓｓＴｏｔｓ」を有する。

【0071】

以下のジェスチャ・エンジンの実施態様例の第５の主要エレメントは、Ｇｅｓｔａｔｏｒの動作によって発生する「イベント」の直接的な受取先の存在である。この受取先は、ディスパッチ・メカニズムのＦＩＦＯバッファのような、単純なレポジトリでもよい。その作業は、蓄積されたイベントを周期的にしかるべき最終コンシューマに配信することである。あるいは、または加えて、受取先は、もっと複雑なパイプラインであってもよく、Ｇｅｓｔａｔｏｒによって供給される中間レベルのイベントを洗練(refine)する、組み合わせる、またはそれ以外で条件を整えて、成り行きを待つサブシステムに役立つためのコンテキスト特定情報を有する、更に高いレベルのイベント構造を生成するように動作するのでもよい。

【0072】

したがって、システムの入力処理ループを通る１本のパスは、ＧｒｉｐｅＲｅｆｉｎｅｒｙに各ＧｒｉｐｅＥｎｔの状態を更新させ、次いでＧｅｓｔａｔｏｒのＰｒｏｃｅｓｓＴｏｔｓを実行することを含む。一方、ＲｐｒｏｃｅｓｓＴｏｔｓは、（作業の中でもとりわけ）登録されている各ＧＴｏｔのＥｎｔｒａｎｃｅＡｔｔｅｍｐｔまたはＣｏｎｔｉｎｕａｔｉｏｎＡｔｔｅｍｐのいずれかを実行することを伴う。

【0073】

一実施形態のＧｅｓｔａｔｏｒのＰｒｏｃｅｓｓＴｏｔｓルーチンは、次の通りである。

【0074】

ＰＴ１。ＧＴｏｔの集合全体をソートして、メタ−セットＭＳ［１．．ｎ］を求める。ソート判断基準は、静的または動的のいずれでもよい。典型的な静的判断基準は、「ＧＴｏｔによって記述されたジェスチャを形成するために必要な、調整されたＧｒｉｐｅＥｎｔｓの数」、即ち、前述の多数Ｓであり、このような場合、したがって、メタ−セットＭＳ［ｎ］は、ｎ個のＧｒｉｐｅＥｎｔｓを必要とするジェスチャを記述するＧＴｏｔを収容する。

【0075】

ＰＴ２。ＭＳ［ｉ］［ｊ］がｊ番目のＧＴｏｔとなるように、各メタ−セットＭＳ［ｉ］においてＧＴｏｔｓに対して順序を選択する。ソート判断基準は、この場合も、静的または動的のいずれでもよい。ある種の状況では、この順序が、単に、ＧＴｏｔｓが最初にインスタンス化されＧｅｓｔａｔｏｒに追加されたときの順序に対応してもよい。

【0076】

ＰＴ３ａ。アクティブなＧＴｏｔのＧｅｓｔａｔｏｒのリストを精査し、各ＧＴｏｔのＵｐｄａｔｅを実行する。

【0077】

ＰＴ３ｂ。 待機中のＧＴｏｔのＧｅｓｔａｔｏｒのリストを精査し、各ＧＴｏｔのＵｐｄａｔｅを実行する。

【0078】

ＰＴ４。全てのＧｒｉｐｅＥｎｔｓのリストを作成する。ａｖａｉｌ＿ｅｎｔｓをコールする。

【0079】

ＰＴ５。ＭＳ［ｎ］からＭＳ［１］までメタ−セットを精査する。

【0080】

ＰＴ６ａ。メタ−セットＭＳ［ｉ］毎に、ＭＳ［ｉ］［ｍ]からＭＳ［ｉ］［１］までのコンポーネントＧＴｏｔｓを精査し、順番にＧＴｏｔＭＳ［ｉ］［ｊ］を検討する。

【0081】

ＰＴ６ｂ。ＭＳ［ｉ］［ｊ］がアクティブ状態にある場合、そのＣｏｎｔｉｎｕａｔｉｏｎＡｔｔｅｍｐアルゴリズムを実行し、リストａｖａｉｌ＿ｅｎｔｓをそれに利用可能にする。そうでない場合、（ＰＴ６ａ）における精査を継続する。

【0082】

ＰＴ６ｃ。（ＰＴ６ｂ）からの結果コードがＣＯＰＡＣＥＴＩＣである場合、（ＰＴ６ａ）における精査を継続する。リストａｖａｉｌ＿ｅｎｔｓは修正されている。

【0083】

ＰＴ６ｄ。または、結果コードがＥＸＣＬＵＳＩＶＥである場合、（ＰＴ６ａ）における精査を放棄し、（ＰＴ７ａ）に進む。リストａｖａｉｌ＿ｅｎｔｓは修正されている。

【0084】

ＰＴ６ｅ。それ以外の場合（結果コードがＤＥＭＯＴＥである）、 ＭＳ［ｉ］［ｊ］をアクティブなＧＴｏｔｓのＧｅｓｔａｔｏｒのリストから除去し、それを待機ＧＴｏｔｓのリストに加える。（ＰＴ６ａ）における精査を継続する。

【0085】

ＰＴ７ａ。 メタ−セット ＭＳ［ｉ］毎に、 ＭＳ［ｉ］［ｍ］から ＭＳ［ｉ］［１］までコンポーネントＧＴｏｔｓを精査し、順番に各ＧＴｏｔＭＳ［ｉ］［ｊ］を検討する。

【0086】

ＰＴ７ｂ。 ＭＳ［ｉ］［ｊ］が待ち状態にある場合、そのＥｎｔｒａｎｃｅＡｔｔｅｍｐｔアルゴリズムを実行し、リストａｖａｉｌ＿ｅｎｔｓをそれに利用可能にする。そうでない場合、（ＰＴ７ａ）における精査を継続する。

【0087】

ＰＴ７ｃ。（ＰＴ７ｂ）からの結果コードがＣＯＰＡＣＥＴＩＣである場合、（ＰＴ６ａ）における精査を継続する。

【0088】

ＰＴ７ｄ。ここで、結果コードがＰＲＯＭＯＴＥまたはＰＲＯＭＯＴＥ＿ＥＸＣＬＵＳＩＶＥのいずれかであることが分かる。 ＭＳ［ｉ］［ｊ］を待機ＧＴｏｔｓのＧｅｓｔａｔｏｒのリストから除去し、それをアクティブなＧＴｏｔｓのリストに加える。リストａｖａｉｌ＿ｅｎｔｓは修正されている。

【0089】

ＰＴ７ｅ。（ＰＴ７ｂ）の結果コードがＰＲＯＭＯＴＥ＿ＥＸＣＬＵＳＩＶＥである場合、（ＰＴ７ａ）における精査を放棄し、（ＰＴ８）に進み、ＰｒｏｃｅｓｓＴｏｔｓ実行を完全に終結させる。

【0090】

ＰＴ７ｆ。それ以外の場合（結果コードがＰＲＯＭＯＴＥである）、（ＰＴ７ａ）の精査を継続する。

【0091】

ＰＴ８。ＰｒｏｃｅｓｓＴｏｔｓの実行を終結させる。

【0092】

一実施形態のＧＴｏｔのＥｎｔｒａｎｃｅＡｔｔｅｍｐｔルーチンは次の通りである。

【0093】

ＥＡ１。リストａｖａｉｌ＿ｅｎｔｓを精査する。

【0094】

ＥＡ２。一度にＳ個取り上げ、ａｖａｉｌ＿ｅｎｔｓのエレメントを特定の入力判断基準と比較する（Ｓは多数あるＧＴｏｔの個数である）。

【0095】

ＥＡ３。このリストのしかるべき組み合わせをし尽くしても一致が得られない場合、応答コードＣＯＰＡＣＥＴＩＣを返す。

【0096】

ＥＡ４。それ以外の場合、ＧｒｉｐｅＥｎｔｓの内一部、Ｓ個のタプル、（ＧＥ［１．．ｓ］と呼ぶ）が、入力判断基準を満たしたことになる。

【0097】

ＥＡ５。ＧＥ［１．．Ｓ］の各ＧＥ［ｋ］をリストａｖａｉｌ＿ｅｎｔｓから除去する。

【0098】

ＥＡ６。ＧＴｏｔによって保持される永続的状態の一部として、一致したＧＥ［１．．Ｓ］の各ＧＥ［ｋ］を記録する。これらのＧｒｉｐｅＥｎｔｓは、こうして「捕獲された」ことになる。

【0099】

ＥＡ７。記述するジェスチャのＧＴｏｔの初期「認識」の記述に相応しいと思われるこのようなイベント（１つまたは複数）をいずれも、発生しイベント・キューに注入する。

【0100】

ＥＡ８。結果コードＰＲＯＭＯＴＥを戻すか、ＧＴｏｔのコンテキストおよびコンディショニングがそのように処置された場合には、ＰＲＯＭＯＴＥ＿ＥＸＣＬＵＳＩＶＥを戻す。

【0101】

一実施形態のＧＴｏｔのＣｏｎｔｉｎｕａｔｉｏｎＡｔｔｅｍｐルーチンは次の通りである。

【0102】

ＣＡ１。捕獲されたＧｒｉｐｅＥｎｔｓＧＥ［１．．Ｓ］の各々が、リストａｖａｉｌ＿ｅｎｔｓの中にあることを確認する。

【0103】

ＣＡ２。（ＣＡ１）の確認ができない場合、即ち、現在のＧＴｏｔよりもプライマシが大きいＧＴｏｔが、現在のＧＴｏｔによって以前に捕獲されたコンポーネントＧｒｉｐｅＥｎｔｓの内１つ以上を不正使用していたことを意味する場合、スキップして（ＣＡ５）に進む。

【0104】

ＣＡ３。捕獲されたＧｒｉｐｅＥｎｔｓＧＥ［１．．Ｓ］の各々が、現在のＧＴｏｔの維持判断基準を意味的および幾何学的に満たすことを確認する。

【0105】

ＣＡ４。（ＣＡ３）の確認ができた場合、スキップして（ＣＡ８）に進む。（ＣＡ３）の確認ができない場合、即ち、ＧＥ［１．．Ｓ］を構成するジェスチャ入力が、現在のＧＴｏｔによって記述されたジェスチャから「脱落する」場合、（ＣＡ５）に進む。

【0106】

ＣＡ５。現在のＧＴｏｔによって記述されたジェスチャの終了を記述するのに相応しいと思われるようなイベント（１つまたは複数）をいずれも発生し、イベント・キューに注入する。

【0107】

ＣＡ６。現在のＧＴｏｔによって保持されている永続的状態から、以前に捕獲されたＧＥ［１．．Ｓ］への参照を除去する。

【0108】

ＣＡ７。結果コードＤＥＭＯＴＥを返す。

【0109】

ＣＡ８。捕獲されたＧｒｉｐｅＥｎｔ集合ＧＥ［１．．Ｓ］の各ＧＥ［ｋ］をリストａｖａｉｌ＿ｅｎｔｓから除去する。

【0110】

ＣＡ９。新しく更新されたと想定されるＧＥ［ｋ］から、発展しつつあるジェスチャの状態の記述に相応しいと思われるようなイベント（１つまたは複数）をいずれも発生し、これをイベント・キューに注入する。

【0111】

ＣＡ１０。結果コードＣＯＰＡＣＥＴＩＣを戻すか、ＧＴｏｔのコンテキストおよびコンディショニングがそのように処置された場合には、ＥＸＣＬＵＳＩＶＥを戻す。

【0112】

以上で紹介した空間連続体入力システムの一実施形態を用いた３つの例示的な応用について、以下に詳細な説明を行う。各例は、一人以上の操作者に属する手をセンサによって追跡し、これらのセンサが指の位置および方位、ならびに、可能ならば、手の塊全体の位置および方位を、高い正確度および高い時間的レートで解明する。更に、このシステムは、各手の「ポーズ」、即ち、互いに対する指、および手の塊に対する指の幾何学的配置を特徴付けるために、得られた空間データを分析する。

【0113】

センサ、操作者の手を追跡し分析する手法、ならびに手のポーズ、位置、および全体的な方位を表すための方式について、以下に詳しく説明することができる。以下の説明全体において、実証的具体性(demonstrative specificity)に関して言うとすれば、象徴的なポーズの表現は、その観念的方式にしたがってレンダリングするものとする。しかしながら、これらの例によって示される実施形態は、同等の象徴的および表現的効果を有することを条件に、他の類似システムを利用してもよいことを注記しておく。

【0114】

同様に、これらの例は、例示の目的で、先に概説した見本の実施態様−アーキテクチャのエレメントを参照するが、代わりの、類似アーキテクチャおよび実施態様も等しく適用できる。

【0115】

有益である場合には、典型的な高レベル(higher level)のイベント構造がジェスチャ対話処理の間に得られた場合、その一部も以下で再現することにする。これらのイベントは、それらの好ましい表現方式と調和する観念でレンダリングされ、原始的な「スロークス」から構築された「プロテイン」としてレンダリングされる（以下で詳しく説明する）。このようなイベント・プロテインは、通例、プラットフォームに依存せず、履歴を保持するプロセス間データ制御および相互交換メカニズムである、「プール」内に貯めておかれる（これについても、以下で詳しく説明する）。そして、しかるべきプールから読み出され、コンテキストに特定のコンディショニングが行われた後に、イベント・プロテインは、関係がある(interested)と考えられるプログラム的オブジェクトに系統的に配信される。プールは、それをホストするマシンにとってローカルなプロセス、そしてネットワークを通じて、遠隔マシン上で実行するプロセスの双方に透過的にアクセス可能である。これらのイベント・プロテインは、以下に続く退屈な説明にわたって、点在し、各場合において、直前のパラグラフで説明した対話処理を指す。また、有機的に統合されたプロテイン(articulated protein)は必ずしも「完璧」ではなく、ある種のフィールドは、実行中のシステム全体に必要であるかもしれないが、明確さ、関連性、および簡潔性を高めるために、省略される場合もあることも注記しておく。

【0116】

第１の例は、立体的視幾何学指導(stereoscopic geometry tutorial)である。この最初の例では、操作者は、約１メートルの正方形でウェストの高さの水平なテーブル状の面の隣に起立している。ディスプレイ・システムが、ステレオ画像をこの面に投射し、加えて、操作者の頭部を追跡し、彼女がテーブルの回りを動くに連れて、左目および右目の視野が、彼女の瞬時位置に対応するように、正確に発生する。

【0117】

このテーブルは、幾何学の指導書を示し、種々の多面体が次元的に(dimensionally)表示される（即ち、実物ではなく、立体視的）。各多面体は、それが安定してその面の１つの上に「静止する」ように位置付けられ方位付けられる。各々は、約１５センチメートルの高さである。

【0118】

操作者は、彼女の右手を挙げ、彼女の人差し指および中指でテーブルを「指し示す」（第４および第５の指は折り曲げられ、親指は左側を指し示す。即ち、人差し指に対して垂直となる）。手は、掌が実質的に下を向くように方位付けられる。このポーズは、［＾＾｜｜−：ｖ＊］と記述することができる。操作者の手がこのポーズを取ったなら直ちに、テーブルは動的カーソルを表示する。正確な幾何学的計算によって、最も近い交差する多面体（ある場合）の表面上、またはテーブルの表面上（多面体が交差しない場合）に、カーソルが現れることができる。操作者は、類似のポーズにして彼女の左手を上げ、同様にそれを用いて指し示し始める。更に別の合図として、多面体が、色を変えることによって、このような「指示対話処理」(pointing interaction)に応答する。操作者が彼女の右手で指し示すと、最も近くで交差する多面体が灰色から青に変化し、彼女の左手を用いると、灰色から緑色に変化する。多面体は、もはや交差されなくなると、それらの元の灰色に戻る。

【0119】

【表4】

【0120】

十面体を指し示している間、操作者は、彼女の親指が彼女の人差し指に対して平行になり、それと接触するように、親指を折り曲げ、次いでその元の垂直な向きに戻す（［ ＾＾｜｜−：−＊］−−＞［ ＾＾｜｜｜：−＊］−−＞［ ＾＾｜｜−：ｖ＊］）。十面体は反応して、グラフィック・タグ、即ち、テーブルの表面上に次元的に位置し、印刷上の記述「｛５，３｝」を収容する正方形のフレーム（十面体に対するシュレフリ・シンボル(Schlaefli symbol)を発する。このタグは、十面体の底面付近にあるその初期位置から、滑らかにテーブルの最も近い縁端までスライドし、そこで静止する。操作者は、引き続きテーブルの周囲を指し示し、彼女の親指を「クリック」することによって、追加のこのようなタグを発生する。得られたタグは全て、テーブルの縁端周囲に配列される結果となる。

【0121】

【表5】

【0122】

【表6】

【0123】

【表7】

【0124】

次いで、操作者は、多少前傾し、手の平はほぼ下を向いたままであるが、ここでは中指および親指が軽く下に巻き込まれた状態（［＾＾＾｜＞：ｖ＊］）で、彼女の左手を下に向けてテーブル表面上にしかるべく持って行く。彼女の手が、テーブルから２０センチメートル上にある閾値平面を交差すると、システムのグラフィック・フィードバックが変化する。これまでは、操作者の人差し指の目標進路とシミュレーションの種々の面および幾何学的エレメントとの交点を（カーソルの位置によって）示していたが、フィードバック・システムはここで多数の「垂線」カーソルを配備し、指の瞬時的位置に対する相対面(relative surfaces)上で最も近い点を示す。したがって、例えば、カーソルが指の真「下」に現れ、それと共にテーブルの表面上を追跡する。指の位置の多面体面上への直交投射が面の多角形内部にある場合も、カーソルは現れる。加えて、テーブルに平行であり指の位置を含む平面を示唆するために、近接多面体面(proximal polyhedral face)上に不鮮明な横の「水平線」が現れる。これらのグラフィック・マークは、システムの自然なフレーム・レート（約９０ヘルツ）で連続的に更新され、したがって指のモーションを認識によって(cognitively)「追跡する。」

【0125】

【表8】

【0126】

操作者が彼女の指を多面体の１つから３センチメートル以内に持って行くと、接近しつつある指に最も近い面が、接触間近の近接を示すために、色相が移り変わり始める。最終的に、指が幾何学的に多面体の表面を通過してその内部立体空間内に入ると、形態全体が発光し、同期したオーディオ・キューが接触の発生を印し、そしてもっと遠くで指し示す手がプラトン・フォーム(Platonic form)「上でクリックした」ときのように、グラフィック・タグが形態の底面から発生し、テーブルの最も近い縁端までスライドしていく。このようにして、操作者は、離れて指し示すことにより、または直接接触することにより、システムの幾何学的内容に同じようにアクセスすることができる。

【0127】

【表9】

【0128】

【表10】

【0129】

これより、操作者は彼女のアクティブな手の中指を延ばして、人差し指と平行となるようにする（［＾＾｜｜＞：ｖ＊］）。このモードでは、システムの多面体との幾何学的接触が、シミュレーションによる物理学(simulated physics)に関係する(engage)ので、操作者が八面体の側面を小突くと、小突きのベクトルおよび接触点への半径方向ベクトルの外積（実際には、幾何代数の規則では、楔積）に比例するトルクを受ける。このように、彼女の人差し指および中指によって小突くまたははじくことによって、操作者は八面体を、その底面の中心を通る垂直（重力と一直線上に向けられた）軸を中心として回転させる。次いで、彼女は、八面体の最上部の立体空間を通過するように垂直に彼女の指を押し込むことによって、この回転を停止させる。

【0130】

【表11】

【0131】

【表12】

【0132】

同様に、操作者はシミュレーションのオブジェクトを位置付けし直すことができる。彼女が彼女の人差し指および中指の先端を四面体の底面に近づけると、黄色の「アンダーハロー」(underhalo)が、指のテーブル表面に対する近接度に対して逆の関係でその明るさを形成する。操作者の指が物理面と直接接触すると（一般に、中指は解剖学的にこれを最初に行い易くなっている）、アンダーハローは黄色から赤に変わり、指の最初の接触点からの偏倚に等しい平行移動偏倚が、四面体に連続的に加えられる。このように、彼女は、表示された物体であればいずれでも、テーブル表面上であちこちにスライドさせることができ、単にテーブルとの接触を断つと、このスライド対話処理が終了する。

【0133】

【表13】

【0134】

最後に、操作者は、テーブルの縁端に蓄積しているタグを、遠隔指示および近接押し込み対話処理双方によって操作する。彼女は、１群のタグがある、テーブルの左側に向けて、彼女の左手を下ろす。いずれのタグも手に近づくので、その輝度は、この場合も、タグから最も近い指までの距離に反比例して、高くなり始める。加えて、いずれかの指の近接度が５センチメートルの外側閾値を交差すると、ライン（テーブル表面の平面内にある）が、タグから、それが関連付けられている多面体までのその道をくねらせる。

【0135】

【表14】

【0136】

【表15】

【0137】

指が、タグとの明確な接触を行ったとき、即ち、投射されたタグの幾何学的境界内にある点におけるテーブル表面との接触を行ったとき、タグの輪郭が赤に変わる。タグおよび指は論理的に結合され、操作者の指がテーブルと接触したままである限り、操作者がテーブルの表面であちこちにタグをスライドさせることができるように、タグは指に従う。

【0138】

【表16】

【0139】

【表17】

【0140】

個々のタグへの指毎の結合が意味するのは、このモードでは、操作者が彼女の手の指を独立して用いることができるということである。彼女が多数の硬貨に軽くタッチしスライドさせているかのように正確に、各指は別々に個々のタグにタッチしこれを制御することができる。タグがスライドしてその位置が変わっていくに連れて、それとその多面体との間にある曲がりくねった線が、２つの構造が図で見ると接続されたままとなるように、しかるべく更新される。

【0141】

【表18】

【0142】

【表19】

【0143】

操作者が彼女の指をタグから持ち上げると、その位置がその後引き続きシミュレーション面の縁端上にある限り、その最後の位置に留まる。彼女がその縁端から「内側に」余りに遠くにタグを放出すると、タグは放射方向に外側に向かってスライドして行き、縁端の近くで一旦静止する。あるいは、彼女がいずれかのタグをテーブルの縁端から離れるようにスライドさせて、それを床上に「投棄」すると、そのタグは無視され消滅する。

【0144】

第２の例は、フィルム操作システムである。この第２の例では、「高速プロトタイピング」フィルム製作作業空間は、交差する壁上に互いに９０度で取り付けられた２つの大きな投射画面と、前方の画面から２メートルのところに位置付けられ、少々傾斜している大きな投射テーブルとを備えている。操作者は、この投射テーブルの真後ろに立ち、前方の画面に面する。前方の画面上に表示されてこれを満たすのは、最近撮影された一連の映像場面からの静止フレームである。

【0145】

操作者は、彼の手を肩の高さまで上げ、各々の手は、手の平を前に向け、指は平行であり、親指は水平に向けられ(［｜｜｜｜−：ｘ＾＆＆｜｜｜｜−：ｘ＾］）、操作者は、もっと大きな連続撮影場面の集合体にアクセスすることがえきる（ここでは、「プッシュバック」制御システムと呼び、以下で詳しく説明する）。彼が彼の手を真っ直ぐ前に平行移動させながら、それらの全体的なポーズを維持すると、現在のフレームが、押し戻されて遠景に飲み込まれるように、後退する。画面上におけるフレームのサイズが縮小するに連れて、他の横方向に並べられているフレームと合体し、したがって、元のフレームは、水平方向のフレーム・ストリップにおける１つであったことが明らかにされる。操作者は、彼の手を更に前方に突き出すことにより、または手を後ろに引くことにより、それぞれ、見ることができるフレームを増加または減少させることができ、こうしてばね荷重構造に対抗して押し動かす物理的な相互作用を模擬する。同様に、操作者が彼の手を左右に動かすと、水平方向のフレーム集合体が左右に引っ張られる。一実施形態のプッシュバック・システムは、手の垂直方向変位を無視することによって、故意にナビゲーションに制約を加えているが、そのように限定されるのではない。

【0146】

図で示すと画面上の中心におかれているレティクルが、操作者がプッシュバック・システムを起動する(engage)と直ぐに現れ、プッシュバック対話処理が終了したときにどのフレームが「選択される」かを示す。彼の手を右に動かして、操作者は、レティクルの直下に新たなフレームを位置付け、双方の手を閉じて拳を作って（［＾＾＾＾＞：ｘ＾＆＆＾＾＾＾＞：ｘ＾］）、プッシュバック・セッションを終了する。選択されたフレームが前方に湧き出すに連れて、レティクルは徐々に薄れて行き、フレーム自体が中心に来て、素早く投射画面を埋めていく。

【0147】

本システムは、場面再生の基本的な制御を行う。操作者は、いずれかの手を床に対して平行な平らなポーズに保持し（［｜｜｜｜｜：ｖｘ］）、次いで指がほぼ右を指し示すまで（［｜｜｜｜：ｖR］）手を時計回り方向に回転させることによって、単位レートで場面を順方向に再生することができる。同様に、平らにした手を反時計回り方向に回転させることにより（［｜｜｜｜｜：ｖｘ］−−＞［｜｜｜｜｜：ｖL］）、場面を逆方向に再生することもできる。彼は、いずれかの手上げて、手の平を前に向け「警官の止まれ」のポーズ、［｜｜｜｜：ｘ＾］にすることによって、再生を中断、即ち、「一時停止」する。

【0148】

操作者は、いずれかの手を垂直平面ポーズにし、指を前方に向けさせる（［｜｜｜｜−ｘ］）ことによって、再生位置およびレートに対する更に別の制御を行うことができる。このようにすると、「対数タイムライン」が起動し(engage)、画面の底部に位置付けられた水平バーのスタックとして、画面上に表される。このタイムライン・スタックの内最も上にあるバーは、場面シーケンスの最大時間幅を表し、このバーの左端は最も早いフレームに対応し、右端は最後のフレームに対応する。連続的に下にあるバーの各々は、１／Ｒに小さくした（つまり、一層精細に「解像」される）場面の部分区間を表し、Ｎ本のバーの内一番下にあるバーは、最大期間よりも小さい場面Ｒ＾＾（Ｎ−１）の区間を表す。

【0149】

操作者は、彼の手を実質的に垂直な軸に沿って（床に向かってまたは床から遠ざかるように）平行移動させることによって、異なるバー、つまり、異なる時間分解能にアクセスする。彼の手を横に振ると、場面の下辺速度再生が起動する。手を右に回転させると（右手の場合、［｜｜｜｜：−ｘ］から少し［｜｜｜｜：ｘ＋］に向かって、または左手の場合、［｜｜｜｜：．−］に向かって）、場面が前方に行ったり来たりし始める。更に回転させると、往復の速度が高くなる。手が直接前方の画面を指し示す姿勢に手を戻すと、再生が中断し（この中央角度位置の周囲に、小さな角度の抑止ゾーンを任意に設けると、中断させた再生を信頼性高く維持するのに役立てることができる）、一方、手を連続的に左に回転させると、場面が後方に行ったり来たりし始める。尚、全体的な往復速度は、現在アクティブになっているバーによって決定される、即ち、場面は、操作者の制御手の姿勢の所与の角度に合わせて、「一番上のバー」のときよりもＲ＾＾ｎ倍だけ遅く再生する。ここで、Ｎは０からｎ−１までの範囲におけるバーの序数である（０は、一番上のバーを表す）。

【0150】

各バーの横方向の先端には、そのように表された瞬時的な場面のタイムスタンプが付記されている。バーのスタックの直下には、現在アクセスおよび表示されているフレームに属するタイムスタンプが表示されており、各バーにおいて、グラフィック・マークがその現在のフレームの位置を示す。加えて、各バーの中には、「マークされたフレーム」、即ち、何らかの方法で注釈を付けられた場面の一部、の時間的位置のグラフィック指示が現れる。このようなマークの中には、編集ポイントを示すものもあり、この例の残りの部分では、これらのマークがロトスコープされたエレメントの利用可能性を示す場合について検討する。

【0151】

操作者が場面をナビゲートして、利用可能なエレメントを含む時点に達したなら、彼は制御手をタイムライン・ポーズから解放し、シャトル・モードを解放する。タイムラインは徐々に薄れて半透明になり、一方画面の右側には、グラフィック・タグの垂直アレイが現れる。各タグは、場面の現在のフレームの中で利用可能なエレメントを表す。

【0152】

操作者は、彼の手を頭の高さまで持ち上げ、指を開き、親指を横にし、掌を床に平行にする（［｜｜｜｜−：ｖｘ］）。そして、彼がこのようにすると、一番上にあるエレメント・タグが拡大し目立つことによって、その選択を示す。同時に、前方画面上で一時停止されている場面のフレーム内において、そのように識別された(tagged)エレメントが明るくなる一方、そのフレームの残りの部分は、低い端数の輝度に落ちる。操作者が、姿勢をほぼ一定に保ったまま、彼の手を上げたり下ろしたりすると、１組のエレメント・タグ全てに連続的にアクセスする（そして、各々が順番に、そのエレメント自体の対応するフレーム内指示によって、目立って見える）。

【0153】

これによって何らかの特定のロトスコープ・エレメントが選択および強調されると、操作者は指示ジェスチャ(pointing gesture)を用いて（人差し指を除いて全ての指を丸め、親指を高く伸ばし、人差し指は前方画面に向かって指し示す：［＾＾＾｜−：−ｘ］）、続いて「親指クリック」による変更を行って（親指を人差し指に平行にする：［＾＾＾｜｜：−ｘ］）、選択されたエレメントを前方画面から掴み取る。直ちに、強調されたエレメントの複製が現れる。選択されたエレメントが静的である場合（一時停止された場面の現在のフレームの一部として）、新たな複製が「生きており」、再生が進み、そのロトスコープの続き(subsequence)の終点において輪を描いて戻ってくる(looping)。次いで、操作者は、親指でクリックするポーズを維持しながら、テーブルの表面を指し示すまで、彼の手を下げる。この操作全体を通じて、動画化されたロト・エレメントが正確に彼の「目標」に従い、最初に前方画面を滑るように下がり、前方画面とテーブルとの間にある幾何学的空隙(geometric void)の中に消え、次いで、指示手の目標がテーブルの四辺形の表面としかるべく交差すると、そこで再び現れる。操作者は、彼の指示手を向け直すことによって、しばらくの間テーブル上において動画化されたロト・エレメントの位置を調節し続け、次いで彼の親指を上げる（［＾＾＾｜｜：−ｖ］−−＞［＾＾＾｜−：−ｖ］）と、そのときにこのエレメントはテーブル上の適所に放される。

【0154】

操作者は、第２の独立したエレメントを、同じシーケンス・フレームから引き出し、前述のジェスチャ操作を繰り返し、次いで往復ナビゲートして同じシーケンスにおける他のポイントに移り、第３エレメントを、テーブル上に蓄積されている構図(composition)に追加する。次いで、彼は全く異なるシーケンスにアクセスし（プッシュバック対話処理において起動することによって）、このシーケンスから更に別のエレメントをテーブルに追加する等となる。

【0155】

最終的に、テーブル表面は、多数のロトスコープ・エレメント、即ち、ばらばらのキャラクタ、プロップ、背景等を含む構図を保持する。これらは全て、引き続き動画となって動いており、これらが構図に追加された順序で描かれる。したがって、不透明なエレメントについては、最後に追加されたものが、その直下にあるエレメントを塞いでしまう。これらのエレメントの（完全なまたは部分的な）不透明性、およびそれらの潜在的な幾何学的重なり合いは、順序が構図の重要な特性になることを意味するので、ここではこれらのエレメントを「レイヤ」と呼ぶことが適している。

【0156】

この構図のレイヤの各々は、象徴的なグラフィック・タグによって表現され、タグの集合体が、テーブルの表面の右側の縁端に沿って（前後軸に沿って）並べられる。タグは、新たなエレメントがテーブルの構図に追加されると直ぐに現れ、新しく来た各エレメントを組み入れるように、タグの直線的な配置が滑らかに順応する。

【0157】

ここで、操作者は、テーブルの右辺より約１０センチメートル上で、タグの集合体の真上において彼の手をホバリングさせる。彼が手を前後に平行移動させると、その手に最も近いタグ、およびそのタグが指し示すエレメント・レイヤの双方が「選択される」。タグは、更に右側にスライドし、明るさおよび透明度を増すことによって、これを示す。一方他の全ての構図レイヤは、ほぼ完全な透明まで徐々に薄れていく。選択されたレイヤは、このように視覚的に分離される。

【0158】

彼の右手を、特定のタグ上でほぼ安定な位置に保持し、これによって１つのレイヤを選択し、操作者は、彼の左手をテーブル表面の、選択されたレイヤの視覚的中心に近いところに向けて持って行く。彼の左手が第１閾値平面（表面に平行であるが、それよりも約２０センチメートル上にある）を横断すると、視覚フィードバック・システムが起動する。図で示す小さな十字（「プラスの記号」）の規則的な格子が、表面上に現れ、それに位置的に固定される。各十字の明るさおよび透明度は、表面上にある手の高さ、および下方投射した手の中心からのその十字の二次元放射距離双方の関数となる。しかるべき倍率および加法定数をこれら２つのパラメータに適用すると、手の位置（投射されて表面に接触する）を追跡して有限半径円内で固定された格子を照らすスポットライトが移動している印象が得られる。この照らされた格子は、手が表面に向かって降下するにつれて、明るさが増していく。

【0159】

操作者の左手は、降下して、次いでテーブルと物理的に接触し、フィードバック・システムのモード変化を誘起する。これまで表面に固定されていたフィードバック格子は、ここでは、接触する手と共にドラッグされていく。同時に、レイヤの再位置付けが起動され、操作者が彼の手をテーブルの回りでスライドさせると、レイヤは正確に追従する。その印象は、一枚の紙を表面の回りでスライドさせているといったものとなる（勿論、レイヤ自体は動き続けることを除く）。

【0160】

操作者が満足するようにレイヤを位置付けし直した後、操作者は次に彼の左手を上げて、表面との接触を断つ。レイヤ「ドラッグ」モードが終了し、レイヤは適所に残される。格子に基づくフィードバック・システムは、同時に以前のモードに戻るので、格子は、テーブル表面に関して固定されたままとなる。最終的に手がテーブルよりも十分遠くまで（垂直に）動くと、手は第１閾値と再度交差し、格子フィードバックは視覚的に消失する。右手を十分に、縦方向または横方向（左右）に動かすと、同様にレイヤ・タグの近接閾値を超過するので、全てのタグおよびレイヤが非選択となり、次いで全てのレイヤが完全に透明となるので、構図全体（この場合、１つのレイヤが移動している）が再度明示される。

【0161】

操作者は、彼の右手の指がテーブルの右縁端に近いレイヤ・タグの１つと完全に接触するように彼の右手を下に持っていくことによって、更に別の対話処理を起動する。すると、「直接操作」モードに入ったことを示すために、タグが明るくなり色相が移り変わる。ここで、操作者は、彼の手をテーブルに沿って前後に、右縁端に平行にスライドさせると、彼の指の直下にあるタグが追従し、十分遠くまで平行移動すると、その（他のタグに対する）順序位置が変化する。操作者が彼の手を表面から持ち上げると、新たなタグの順序が保持され、対応するレイヤの新たな論理的順序となる。このように、レイヤを描く順序を操作することができ、個々のレイヤをそのスタック内において「上に」または「下に」動かすことができる。

【0162】

最後に、システムおよびその内容の高レベル操作を実行するために、１組の「瞬時的」ジェスチャが利用可能である。例えば、操作者は彼の両手をさっと動かし(sweep)、平らに保持し、全ての指および親指を広げて、最初に均一に前方、外側、および横側を指し示し、それまで蓄積されていた構図をクリアし削除するために、右手が右側を指し示し、左手が左側を指し示す（［｜｜｜｜｜：ｖｘ＆｜｜｜｜｜：ｖｘ］−−＞［｜｜｜｜：ｖ＋＆｜｜｜｜：ｖ＋］）ようにする。または、２つの手を左に向かって「押す」モーションを行って、同一平面上に両手があり、一方の手が他方の上になるようにすると、左側を指し示している掌（｜｜｜｜｜：Ｌｘ＆｜｜｜｜｜：Ｌｘ）が、前方画面の内容を左スクリーンに移動させる。このジェスチャは、前方の場面が滑らかに左に向かって平行移動することを誘起し、同時に場面は時計回り方向に垂直軸を中心として、その中心および法線ベクトルが左画面の中心および法線と一致するまで回転する。アプリケーションの区間全体、およびそのコンポーネント・データは、このように、表示面間で、配置し直したり、または動かすことができる。

【0163】

尚、本明細書において説明したフィルム操作システムは、多くの更に別の機能も含むことを注記しておく。例えば、エレメントを手によって、それらを含むシーケンスから、そのままロトスコープし、操作者の指が関連のあるシルエットをフレーム毎に追跡するモード、構図テーブル上におけるエレメントの時間整合（または正確なタイム・オフセット）のための手段等があるが、本開示に関する自由空間、近接、およびタッチに基づくジェスチャ対話処理は、これらのモードの詳細な検討によってこれ以上（または一位に）解明しないことにする。

【0164】

第３の例は、ポーテージ・スレート(portage slate)のそれである。この第３の例では、広く利用される対話処理が、「ポーテージ・スレート」（または「ｐ−スレート」）と呼ばれる１つ以上の特権物理オブジェクトを伴う。ポーテージ・スレート機能は、本明細書において記載されるシステム上に構築され、しかるべく構成されているあらゆるアプリケーションに、自動的に利用可能となる。ポーテージ・スレートは、物理的トレイであり、その上に操作者は、第１の位置に表示されているグラフィック・オブジェクトやアーチファクトを「擦り落とし」、そしてそこから、動き回る輸送にしたがって、スレート化したオブジェクト(enslated object)を、新たなアプリケーションに転送し、第２の位置に新たな表示コンテキストを示す。

【0165】

この第３の例は、先の第１および第２の例を参照しながら説明する。幾何学指導担当者(tutorial operator)は、二十面体を単に軽く叩いて、それを表すタグがテーブルの縁端近くに静止するようにし、続いて、前述したような態様で、この二十面体のスピニング(spinning)を設定した。ここで、彼女は、彼女の左手で、近くにあるｐ−スレートを拾い上げる。このｐ−スレートは寸法が約２０×３０センチメートルのつや消し色をした硬質シートであり、通例（しかし必ずではない）操作者の手を追跡するために用いられたのと同じメカニズムによって、システムによって能動的に追跡される。

【0166】

操作者は、このｐ−プレートをテーブルの縁端に近づけ、ｐ−スレートの縁端の１つがテーブルの縁端に平行となりほぼそれに触れるように、このｐ−スレートを方位付ける。テーブル表面の役割を果たす投射システムは、画素のその拡大円錐がテーブルの厳格な物理的境界を故意に「溢れる」ように構成されている。実際に、投射画素フィールドは、今行われるように、ｐ−スレートをテーブルに突き合わせたときに、ｐ−スレートの全体を扱うのに十分な大きさとなっている。

【0167】

ｐ−スレートが近接して存在すると、システムの一部に、投射画素へのローカル・アクセスを行うように誘導し、一過性規制表示（「ＴＰＤ」）構造をインスタンス化する。ｐ−スレート上に物理的に載っている画素の部分集合を別個の表示として操作すること、ｐ−スレート上の画素サブアレイの垂直でない投射の入射によって引き起こされるあらゆる幾何学的歪みを補償すること、ならびに仮想レンダリング・コンテキストをｐ−スレートおよびそれの上に描画することを許可されているあらゆるプロセスに提供することは、ＴＰＤの役割である。

【0168】

ｐ−スレートが、その角の内テーブルに最も近い１つにおいて、それが生きており利用可能である指示として、動画化したグリフを生成することを可能にするのは、このレンダリング・コンテキストである。同期された動画化(synchronized animation)と一致するグリフが、ｐ−スレートに近いテーブル上に生成される。操作者は、２つの表面、一方は固定表面、一方は可動表面が、ここでは論理的に接続されていることを、グリフ・ダイアッド(glyphic dyad)が示すことを理解する。

【0169】

操作者の右人差し指は、二十面体のタグ上に着地し、彼女の指、つまり因果的にタグを、テーブルの周囲に沿ってそしてｐ−プレート上にスライドさせる。タグは、この場合テーブルの境界の外側にあるが、この時点では破棄された（タグが「床の上に投下された」第１の例からの対話処理におけるように）とは見なされず、代わりに、このタグはｐ−スレート上に「存在する」ことを、システムはここでは断言する。

【0170】

実際、操作者が多面体幾何学ワークステーションの直ぐそばから離れて、動き出して部屋を横切るように移動すると、彼女の軌跡は、ｐ−プレートを少し高く持ち上げ、次いでテーブルの投射円錐を通って前方に持って行く。システムの追跡が低レイテンシであるため、ｐ−スレートの位置および方位が変化すると、移動可能なディスプレイの幾何学的形状のＴＰＤの内部モデルを更新することができる。このモデルによって、ＴＰＤ構造は、移動する表面と交差するプロジェクタの画素を正確に取り込み(commandeer)続けることが可能になる。ｐ−スレートは、単に、それ自体の固定した幾何学的形状に対して、それとプロジェクタとの間に生ずる複雑な投射関係を明示的に参照することなく（実際、おそらく計算的に自明）、そのコンテンツを適所にレンダリングし続ける。このようにして、操作者は、タグが、ｐ−スレート上の、彼女がそれを置いた場所にあり続け、あらゆる認識的に関連する意味で、タグは今ｐ−スレート上にあることを観察する。

【0171】

操作者が前方に進むことによって、ｐ−スレートの幾何学的形状が投射ピラミッドから完全に外れるように、ｐ−スレートを平行移動させると、本システムは、ＴＰＤ構造の使用を中止し、そのレンダリング・コンテキストを不活性にする。

【0172】

操作者が彼女の道を長い部屋の多端に向けて取ると、彼女は、プロジェクタがアクティブである他の立体空間を通過する。各場合において、ネットワーク接続されている追跡システムは、ローカル投影画素へのアクセスによって、そのイベント・ストリームをプロセスに利用可能にする。追跡イベントが、ｐ−スレートが新たにピラミッド状投射円錐を交差していることを示すときにはいつでも、他のＴＰＤ構造がインスタンス化される。このように、ｐ−スレートは、その瞬間的な投影立体空間の通過の間に、その「内容」をレンダリングすることができる。特に、二十面体タグは、ｐ−スレート上におけるその位置に固定されたままであるように見える。

【0173】

直に、操作者は第２の例の高速プロトタイピング・フィルム・ワークステーションに到達する。ここでも、投射パラメータは、下方プロジェクタの画素が、アセンブリ・テーブルから十分に溢れるように構成されている。操作者がｐ−スレートを作業テーブルに近づけると、ローカルＴＰＤが再度インスタンス化され、もう一度タグが明示される。加えて、グリフのダイアッドも再度現れて、１つはｐ−スレート上に、もう１つはテーブル上に現れて、２つの表面がデータ−論理的に接触していることを示す。

【0174】

操作者は、ｐ−プレートを、テーブルの後方縁端（彼女の身体に最も近い）の右側に、ｐ−スレートを位置付けている。ここで、彼女は、ｐ−スレートを彼女の左手で押さえながら、彼女の右手の指をタグ上に下ろすと、タグは明るくなって、接触を確認する。彼女は滑らかにタグを前方にスライドさせ、ｐ−スレートの前方縁端を横切って、テーブル上に置く。彼女が彼女の指をテーブルから持ち上げ、タグとの接触を終了させると、タグは移動してロトスコープ・エレメントの垂直アレイに加入する。一方、このアレイは、新たなタグを収容するために、それらの位置に対して僅かな調節を行う。

【0175】

ここで、オペレータがテーブルに追加したばかりのタグの上で軽く叩くと、タグはその「ペイロード」をディスペンスする。彼女が放置したときにはまだ回転していた二十面体の二次元投射が、素早くタグの位置からスライドし出し、動くに連れて倍率が大きくなり、構図テーブルの中心の位置を占める。ここでは、二十面体は、組成において用いられている他のフィルム・エレメントのいずれとも同様に振る舞う。操作者は、二十面体を位置付けし直し、そのレイヤの順序付けを変更する、等を行う。

【0176】

第４の例は、ホバー型入力を特に利用する、一般的な対話処理様式を伴う。この第４の例について、都市サービスの用途というコンテキストにおいて説明する。大きな前方画面が、都市エリアの三次元図を示す。このエリアは、地下設備だけでなく地上構造も備えており、電気、水、ガス、汚水、および地下鉄のエレメントといった、多数の互いに貫通しあうレイヤを備えている。自由空間ジェスチャ・ナビゲーションによって、操作者は、以下に詳細に述べる態様で、前方ディスプレイ上の配景シーン上で「飛び回る」ことができる。一方、投射テーブルは、操作者の直前に、同じ都市領域の上下正投影図を示す。本明細書において記載するホバーに基づく対話処理により、アプリケーションが地中構造の探査および選択を行うことを可能にする。

【0177】

操作者は軽く前に傾き、彼の左手を、ある中間地区領域の十分上から初めて、テーブルの表面まで持って行く。テーブルの上方にある閾値を通って手が降下すると（例えば、テーブルから約２０センチメートル上）、構造選択メカニズムがイネーブルされ、光を放つ半透明のディスクが、都市の地図のような図の上に図式的に重ねられる。ディスクの半径以内に位置する地下構造毎に、簡潔な視覚的表現が現れる。同時に、これらの同じ「強調された」構造の更に詳細な三次元図が、前方の投影図上の正しい三空間位置に現れる。操作者が、彼の手を、表面上から一定の高さに保持しつつ横に平行移動させると、ディスクもそれに応じて平行移動し、常に手の直下に現れる。強調した構造の集合体は継続的に更新されるので、移動するディスクは、一種の選択スポットライトのように動作する。

【0178】

更に、一実施形態の対話処理サブシステムは、テーブル表面上で追跡される手の高さ、および選択ディスクの半径のマッピングも行う。このマッピングは、逆関係となるので、操作者が彼の手をテーブルに近づける程、ディスクのサイズは小さくなる。最大半径の選択は、本モードが最初に起動されるときに、相応の「全体像」の選択が得られるように行われる。操作者の手がテーブル表面に直接接触したときに達する、最小半径は、個々の地下エレメントの選択が大体可能になるように選択される。このように、表示面に対して平行な、１つの手の平行移動自由度の内２つが、ドメイン特定の空間自由度にマッピングされ、一方、第３軸は、用途内において観念的に「正確度」または「特定性」パラメータであるものにマッピングされる。

【0179】

尚、この対話処理では、ホバーと実際の物理的なテーブルとの接触（タッチ）との間には、論理的な区別が行われないことを注記しておく。本システムは、差別のある意味(differential meaning)をタッチが持っているとはみなさない。しかしながら、操作者は、全接触の可能性によって授けられる特定の物理的優位性を享有する。選択ディスクは、操作者の指がテーブルに触れているときに最も小さくなり、これが意味するのは、手の横方向のモーションによって、選択に可能な限り最も大きな変化（即ち、ディスク・サイズに対して最大）が生ずるということである。しかしながら、操作者の指は、一旦表面と接触したなら、高い位置的安定性を得る。

【0180】

また、操作者はアプリケーションを２つの手で駆動してもよいので、一方の手がホバーに基づくエレメントの選択を引き受け、他方の手が前方統制図の６自由度操作を行うために用いられるようにしてもよい。あるいは、２人の操作者が協同し、各人が１つの手を用いてもよい。

【0181】

最後に、輝くディスクの近くで、第２のディスクを操作しない手でテーブルを叩くことによって、選択を「ロック」することもできる。この短い叩く行動は、対照的に、タッチを区別する。このように選択状態を凍結すると、元の手はテーブルから離れて自由に動くことができる。要約すれば、このメカニズムは、可変選択半径によって、空間的に分散されたエレメントの平面的選択を可能にする。

【0182】

勿論、例えば、電気およびガスの設備のみが選択されるように、アプリケーションを調整するために、他の対話処理工作(maneuver)が、実際の配備における中核選択活動を取り巻いている。しかしながら、本実施形態は、そのように限定されるのではない。

【0183】

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

【0184】

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

【0185】

図示の実施形態では、４台のカメラまたはセンサを用いて、視野１５０内においてユーザの手１０１および１０２の位置、方位、および移動を検出する。ＳＯＥの範囲や主旨から逸脱することなく、ＳＯＥ１００はこれらよりも多いカメラ（例えば、６台のカメラ、８台のカメラ等）または少ないカメラ（例えば、２台のカメラ）とでも用いることができることは言うまでもない。加えて、実施形態例では、カメラまたはセンサは対称的に配置されているが、ＳＯＥ１００にはこのような対称性の要件はない。ユーザの手の位置、方位、および移動を許容するのであれば、カメラまたはセンサは、いずれの数および位置付けでも、ＳＯＥ１００において用いることができる。

【0186】

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

【0187】

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

【0188】

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

【0189】

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

【0190】

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

【0191】

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

【0192】

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

【0193】

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

【0194】

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

【0195】

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

【0196】

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

【0197】

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

【0198】

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

【0199】

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

【0200】

現在では、タグはベルクロ(Velcro)またはその他のしかるべき手段によって、操作者が身に付けている手袋に装着されるか、あるいは、柔らかな両面テープを用いて操作者の指に直接装着される。第３実施形態では、剛性基板を全くなしで済ませ、操作者の指および手に直接個々のマーカを装着するまたは「描く」することができる。

【0201】

ジェスチャ・ボキャブラリ
ＳＯＥは、手のポーズ、方位、手の組み合わせ、および方位の配合(orientation blends)で構成されるジェスチャ・ボキャブラリ(gesture vocabulary)を想定する。ＳＯＥのジェスチャ・ボキャブラリにおいてポーズおよびジェスチャを立案および伝達するために、表記言語(notation language)も実施する。ジェスチャ・ボキャブラリとは、力学的連結の瞬時的な「ポーズ状態」を簡潔な文字形態で表すシステムである。対象となる連結は、生物（例えば、人の手、または人の身体全体、あるいはバッタの足、あるいはキツネザルの関節脊柱）であってもよく、あるいは代わりに非生物であってもよい（例えば、ロボットのアーム）。いずれの場合でも、この連結は、単純（脊柱）でもまたは分岐（手）でもよい。ＳＯＥのジェスチャ・ボキャブラリ・システムは、いずれの特定的な連結についても、一定長のストリングを確立する。こうして、ストリングの「キャラクタ位置」を占める特定のＡＳＣＩＩキャラクタの集合体が、連結の瞬時的状態、即ち、「ポーズ」の一意の記述となる。

【0202】

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

【0203】

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

【0204】

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

【0205】

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

【0206】

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

【0207】

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

【0208】

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

【0209】

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

【0210】

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

【0211】

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

【0212】

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

【0213】

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

【0214】

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

【0215】

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

【0216】

他のポーズも含むことができる。

【0217】

[|||||:vx]は、手を平らにして（親指が他の指と平行）、掌が下を向き、指が前方に突き出している。

【0218】

[|||||:x^]は、手を平らにして、掌が前を向き、指が天井を向いている。

【0219】

[|||||:-x]は、手を平らにして、掌が身体の中心に向いており（左手の場合は右、右手の場合は左）、指が前方に突き出している。

【0220】

[^^^^-:-x]は、手を１つにして親指を合わしている（親指は天井を向いている）。

【0221】

[^^^|-:-x]は、銃を前方に構える真似である。

【0222】

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

【0223】

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

【0224】

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

【0225】

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

【0226】

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

【0227】

ＳＯＥの一実施形態では、動作７０１〜７０５をカメラ内蔵プロセッサによって実行する。他の実施形態では、望ましければ、この処理をシステム・コンピュータによって実行することもできる。

【0228】

解析および変換
本システムは、基礎となるシステムによって再現された低レベルのジェスチャのフローを「解析」および「変換」し、これら解析し変換したジェスチャを、コマンドまたはイベント・データのフローに変換することができる。このデータは、広範囲のコンピュータ・アプリケーションおよびシステムを制御するために用いることができる。これらの技法およびアルゴリズムは、これらの技法を実現するエンジン、およびエンジンの能力を利用するコンピュータ・アプリケーションを構築するプラットフォームの双方を提供するコンピュータ・コードから成るシステムにおいて具体化することができる。

【0229】

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

【0230】

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

【0231】

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

【0232】

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

【0233】

ａ．１本の手の「ポーズ」（手の部分の外形および互いに対する方位）。三次元空間における１つの手の方位および位置。

【0234】

ｂ．２つの手の組み合わせ。いずれかの手がポーズ、位置、または双方を考慮に入れる。

【0235】

ｃ．多数の人物の組み合わせ。本システムは２つよりも多い手を追跡することができ、したがって、一人よりも多い事物が協同して（ゲーム・アプリケーションの場合には競合して）目標システムを制御することができる。

【0236】

ｄ．ポーズが連続して組み合わされる順次ジェスチャ。これらを「動画」ジェスチャと呼ぶ。

【0237】

ｅ．操作者が空間内の形状を追跡する「書記素」ジェスチャ(grapheme gesture)。

【0238】

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

【0239】

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

【0240】

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

【0241】

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

【0242】

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

【0243】

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

【0244】

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

【0245】

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

【0246】

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

【0247】

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

【0248】

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

【0249】

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

【0250】

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

【0251】

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

【0252】

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

【0253】

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

【0254】

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

【0255】

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

【0256】

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

【0257】

本明細書において記載する指定および解析システムは、「利き手不可知論」をサポートするように注意深く設計されているので、多数の手のジェスチャについて、いずれの手でもポーズの要件を満たすことができる。

【0258】

データ空間のナビゲーション
一実施形態のＳＯＥは、グラフィック空間または他のデータ表現空間全域における線形推移または追跡運動を制御するために、「プッシュバック」(pushback)、即ち、人間の操作者の手の線形空間運動、または同質の次元活動の実行を可能にする。ＳＯＥ、およびそれによって確立される計算および認識の連携は、スケールのレベルをナビゲートする、主に線形な「深度次元」を横断する、あるいは、最も一般的には、量子化されたまたは「抑止された」(detented)パラメータ空間にアクセスするための、基本的な構造化された方法を提供する。また、ＳＯＥは、操作者が意図的に追加コンテキストを取得することができる有効な手段、空間的、概念的、または計算的のいずれであっても、近傍(vicinities)および近隣(neighborhoods)を理解するための素早い技法を提供する。

【0259】

ある種の実施形態では、プッシュバック技法は、従前の入力デバイス（例えば、マウス、トラックボール、一体化したスライダ、またはノブ）を用いることができ、または操作者自身の身体(person)から外部のタグ付きオブジェクトまたは追跡対象オブジェクトに依存することができる（例えば、器具を取り付けられた連鎖のリンク(instrumented kinematic linkages)、静磁気的に追跡される「入力レンガ」(input bricks)）。別の代替実施形態では、プッシュバックの実施は、制御システム全体として十分であればよい。

【0260】

一実施形態のＳＯＥは、それよりも大きな空間相互作用システムの一部であり、その中に統合されている。このシステムは、コンピュータの制御のための慣習的なマウス主体グラフィック・ユーザ・インターフェース（「ＷＩＭＰ」ＵＩ）方法に取って代わり、代わりに、（ａ）１つ以上のタイプの物体（例えば、人間の手、人間の手の上にある物体、静止物体等）を追跡することができる物理的センサ、（ｂ）検知された手の徐々に進展する位置、方位、およびポーズを分析して、一連のジェスチャ・イベントにする手段、（ｃ）このような空間的イベントおよびジェスチャ・イベントを表すための記述的方式、（ｄ）このようなイベントを制御プログラムにそしてその内部に配信するフレームワーク、（ｅ）ジェスチャ・イベントのストリームによってエンコードされた人間の意思（コマンド）を、イベント・ストリーム自体およびイベント解釈の用途特定結果双方のグラフィック、聴覚的、およびその他の表示様式描写(display-modal depiction)と同期させる方法を備えている。これらの全てについて、以下で詳しく説明する。このような実施形態では、プッシュバック・システムは、追加の空間およびジェスチャ入力−および−インターフェース技法と統合される。

【0261】

一般に、データ空間のナビゲーションは、検出器によって検出されたジェスチャ・データから、本体のジェスチャを検出することを含む。ジェスチャ・データは、ある時点および物理的空間における本体の瞬時的状態の絶対三次元位置データである。検出は、ジェスチャ・データを用いてジェスチャを識別することを含む。ナビゲーションは、ジェスチャをジェスチャ信号に変換すること、そしてこのジェスチャ信号に応答してデータ空間全体をナビゲートすることを含む。このデータ空間は、物理的空間において表されるデータ集合を含むデータ表現空間である。

【0262】

一実施形態の全体的な往復レイテンシ(round-trip latency)（センサに対する手のモーション→ポーズ分析→プッシュバック解釈システム→ディスプレイ・デバイスへのコンピュータ・グラフィクスのレンダリング→操作者の視覚系）が低く抑えられているとき（例えば、実施形態が約１５ミリ秒のレイテンシを呈する）、そして、システムの他のパラメータが適正に調整されているとき、プッシュバック相互作用の知覚的結果(perceptual consequence)は、物理的因果関係(causality)の格別な感覚となる。ＳＯＥは、ばね装填構造に対抗して押すことの物理的に反響する比喩(physically resonant metaphor)を文字どおりに解釈する(literalize)。知覚される因果関係は、非常に有効なフィードバックとなる。プッシュバック・システムによって供給される他のもっと抽象的なグラフィック・フィードバック様式と共に、そして操作者の移動の解釈におけるある程度の自由度の意図的な抑制によって、このようなフィードバックは、総体的および精細な人間動力活動(human motor activity)双方の、制御メカニズムとしての、安定した、信頼性のある、そして繰り返し可能な使用を可能にする。

【0263】

ＳＯＥのコンテキストを評価する際、多くのデータ集合は本質的に空間的である。これらは、リテラル物理空間(literal physical space)内における現象、イベント、測定、観察、または構造を表す。より抽象的な他のデータ集合、またはリテラルであるが非空間的情報をエンコードする他のデータ集合については、表現（視覚的、聴覚的、または他の表示様式を伴う）を用意することが望ましいことが多い。その基本的態様の一部は、１つのスカラー値パラメータによって制御され、そのパラメータを空間的次元と関連付けることも有益であることが多い。プッシュバック・メカニズムによる操作から利点が得られるのは、この１つのスカラー・パラメータの操作である。これについては、以下で詳しく説明する。

【0264】

更に、表現は、それらのパラメータに、小さな複数の離散値だけを許可することもできる。実際には、離散値は１つのこともあり、それに対してデータ集合は最適に見なされる。このような場合、「抑止されたパラメータ」、即ち、パラメータが明示的に「抑止されたパラメータ」の表現空間の一次元にマッピングされているか否か伝えることが有用である。本明細書における「抑止された」(detented)という用語の使用は、パラメータの好ましい量子化だけでなく、ラチェットの視野触覚的感覚(visuo-haptic sensation)、磁気整合メカニズム、ジョグ−シャトル・ホイール、および意図的な機械的抑止を有する他の豊かなこの世のデバイス(worldly devices)を呼び起こすことを意図している。

【0265】

このようなパラメータの自明であるが極めて重要な例には、限定ではなく、（１）コンピュータ・グラフィクス環境における、データ集合のレンダリング可能な表現からの合成カメラの距離、（２）データが元のデータ集合からサンプリングされ、レンダリング可能な形態に変換される密度、（３）サンプルが時間可変データ集合から引き出され、レンダリング可能な表現に変換される時間的インデックスが含まれる。これらは、普遍的な手法であり、無数のドメイン特定パラメータ化も存在する。

【0266】

ＳＯＥのプッシュバックは、一般に、データ集合のパラメータ−制御軸を、物理的空間におけるローカルに関連のある「深度次元」と整合させ、深度次元に沿った構造化実世界運動(real-world motion)が制御軸に沿ったデータ−空間変換を実行することを可能にする。その結果、パラメータ空間をナビゲートする非常に効率的な手段が得られる。以下に、ＳＯＥにおいて実施した場合のプッシュバックの代表的な実施形態の詳細な説明が続く。

【0267】

プッシュバックの一例では、操作者は、テキストおよび画像を含む１つの「データ・フレーム」が現れる大きな壁ディスプレイの前において、十分な距離のところに立つ。グラフィック・データ・エレメントは、静的でも動的でもよい。データ・フレームは、例えば、画像を含むが、そのように限定されるのではない。データ・フレーム自体は二次元構造であるが、三次元コンピュータ・グラフィクス・レンダリング環境内に存在する。その基礎となる座標系は、部屋、ならびにディスプレイおよび操作者を含む、その内容物を記述するのに都合がよい実世界座標と一致するように配置されている。

【0268】

操作者の手は、センサによって追跡され、センサは、彼女の指の位置および方位、ならびに恐らくは手の塊全体の位置および方位を、高い正確度および高い時間率(temporal rate)で解明する。システムは、各手の「ポーズ」、即ち、指の互いに対する、そして手の塊に対する幾何学的配置を特徴付けるために、得られた空間データを分析する。この実施形態例で追跡する物体は、人間の手（１つまたは複数である）が、代替実施形態では多くの他の物体も入力デバイスとして追跡することができる。一例には、一方側に押し返す場面(one-sided pushback scenario)があり、この場合、本体が開放位置にある操作者の手であり、掌が前方方向に面している（ｚ−軸に沿って）（例えば、操作者の前にある表示画面に向かって）。この説明に限って言えば、壁ディスプレイは、ｘおよびｙ次元を占めるように置かれ、ｚは操作者とディスプレイとの間における次元を記述する。このプッシュバック実施形態と関連のあるジェスチャ相互作用空間は、定数ｚの平面で突き合わされた２つの空間を備えている。ディスプレイから遠い（即ち、操作者に近い）抑止間隔空間(detented interval space)を「デッド・ゾーン」と呼び、近い方の半空間を「アクティブ・ゾーン」と呼ぶ。デッド・ゾーンは、逆方向（操作者に向かい、ディスプレイから離れる方向）に不定に広がるが、前方には有限距離だけ広がり、デッド・ゾーン閾値にて終端となる。アクティブ・ゾーンは、デッド・ゾーン閾値からディスプレイまで前方に広がる。ディスプレイ上にレンダリングされるデータ・フレーム（１つまたは複数）は、アクティブ・ゾーンにおける本体の移動によって、相互作用的に制御される、即ち、「押し戻される」。

【0269】

データ・フレームは、ディスプレイのサイズおよびアスペクト比と正確に一致するサイズおよびアスペクト比で構成され、その中心および法線ベクトルがディスプレイのこれら物理的属性と一致するように位置付けおよび方位が決められるが、実施形態はそのように限定されるのではない。シーン(scene)をレンダリングするために用いられる仮想カメラは、ディスプレイから直接前方に、大まかに操作者の距離に配置されている。このコンテキストでは、レンダリングされたフレームは、したがって、正確にディスプレイを満たすことになる。

【0270】

可視フレームの左右には、論理的に多数の追加の共面データ・フレームが配置されている。これらの共面データ・フレームは均一に離間され、適度のギャップがそれに直接隣接するものから互いに分離する。これらは、コンピュータ・グラフィクス・レンダリング幾何学体系の物理的／仮想レンダリング境界の外側にあるので、これらの横方向に変位した隣接データ・フレームは初期状態では見えない。データ空間は、その幾何学的構造が与えられれば、ｚ−方向において１つの自然な抑止部を、そして複数のｘ−抑止部を有することは理解されよう。

【0271】

操作者は、彼女の左手を軽く握ったポーズで保持して、彼女の肩まで持ち上げる。次いで、彼女は指を開いて、これらが上方を指し示し、親指が右側を指し示し、彼女の掌が画面に面するようにする（以下で詳細に説明するジェスチャ記述言語では、このポーズ遷移は、［＾＾＾＾＞：ｘ＾から｜｜｜｜−：ｘ＾］というように表現される）。本システムは、新たなポーズを検出すると、プッシュバック相互作用を誘起し、そのポーズが最初に入力されたところである手の絶対三空間位置を直ちに記録する。この位置は、「原点」として用いられ、以降の手の運動は、この原点からの相対的オフセットとして報告される。

【0272】

直ちに、２つの同心円状の、部分的に透明なグリフ(glyph)がフレームの中心に（つまり、ディスプレイの中心に）重畳される。例えば、グリフは、デッド・ゾーンにおける、デッド・ゾーン閾値の点までの本体プッシュバック・ジェスチャを示すことができる。第２グリフが第１グリフよりも小さいのは、操作者の手がデッド・ゾーン内に存在し、それを貫通するプッシュバック動作が「未だ」加わっていないことを示す。操作者が彼女の手を前方に（デッド・ゾーン閾値およびディスプレイに向かって）移動させると、第２グリフが徐々に大きくなる。操作者の手がデッド・ゾーン閾値に来る地点で、第２グリフのサイズは第１グリフと同等になる。この例のグリフは、操作者の手がその開始位置から、デッド・ゾーンをアクティブ・ゾーンから分離するデッド・ゾーン閾値に向かって進行する際における、グリフの同心円エレメントの進展を示す。グリフの内部にある「歯状」部分は、手が閾値に近づくにつれて大きくなり、手が閾値の位置に達したときに、内側グリフおよび（静止）外側グリフの半径が、正確に一致するように配置されている。

【0273】

第２グリフは、操作者が彼女の手をデッド・ゾーン閾値から遠離るように、そしてディスプレイから遠離るように移動させると、第１グリフの内側でサイズが小さくなるが、常に第１グリフと同心状にあり、ディスプレイの中心に位置することに変わりはない。極めて重要なのは、操作者の手の運動のｚ−成分のみがグリフのスケーリングにマッピングされており、手の運動の副次的なｘ−およびｙ−成分は何の寄与もなさないことである。

【0274】

操作者の手がデッド・ゾーンの閾値を順方向に横断し、アクティブ・ゾーンに入ると、プッシュバック・メカニズムが関与する(engage)。手の相対的なｚ−位置（閾値から測定する）は、スケーリング関数の対象となり(subject)、その結果得られる値は、データ・フレームおよびその横方向の近隣のｚ−軸変位を行うために用いられるので、そのフレームのレンダリング画像はディスプレイから後退するように見え、そして近隣データ・フレームも見えてきて、表示空間の縁から「埋まっていく」。合成カメラの一定角度範囲(constant angular subtent)は、平面がカメラから離れるように移動するに連れて、フレームが位置する平面のより多くを幾何学的に「取り込む」。ｚ−変位は連続的に更新されるので、操作者は、彼女の手をディスプレイに向けて押し込んだり、彼女自身に向かって引いたりすると、彼女のモーションに直接応答して、横方向に後退および近接するフレームの集合体(lateral collections)を知覚する。

【0275】

対応するプッシュバックから得られるデータ・フレームの第１の相対的ｚ−軸変位の一例として、レンダリングされたデータ・フレームの画像は、ディスプレイから後退するように見え、隣接するデータ・フレームが見えるようになり、ディスプレイ空間の縁から「埋まっていく」。隣接するデータ・フレームは、多数の追加の共面データ・フレームを含み、可視フレームの左右に論理的に配置され、均一に離間され、適度なギャップが各々をその直接隣接するものから分離する。対応するプッシュバックから生ずるデータ・フレームの第２の相対的ｚ−軸変位の一例として、そして第１の相対的ｚ−軸変位について検討する。第１の相対的ｚ−軸変位が生じたプッシング(pushing)から、操作者の手を更にプッシングした（ｚ−軸に沿ってディスプレイに向かい操作者から離れる更なるプッシング）と仮定すると、レンダリングされたフレームの画像は、更にディスプレイから後退するように見えるので、より多くの隣接データ・フレームが見えるようになり、更に表示空間の縁から「埋まっていく」。

【0276】

一方、対をなす同心円状グリフは、ここでフィードバックの変更を示す。操作者の手はアクティブ・ゾーン内にあり、第２グリフは、スケーリングに基づく反応から、回転反応に切り替わり、手の閾値からの物理的なｚ−軸オフセットが、正の（平面内）角度オフセットにマッピングされる。デッド・ゾーンにおいてデッド・ゾーン閾値の点を超えた本体のプッシュバック・ジェスチャ（ｚ−軸に沿って、ディスプレイに向かって、そして操作者から遠離る）をグリフが示す例では、これらのグリフは、一旦操作者の手がデッド・ゾーン閾値を交差した際における、即ち、プッシュバック・メカニズムが能動的に関与するときの、グリフの進展を示す。つまり、操作者の手のディスプレイに向かう移動およびディスプレイから離れる移動が、第２グリフの時計回りおよび反時計回り方向の回転によって視覚的に示され（第１グリフは、以前と同様、静止基準状態を示す）、グリフの「歯状」エレメントが、手の閾値からのオフセットの線形関数として回転し、線形運動を回転表現に変える。

【0277】

したがって、この例では、ディスプレイに向かうｚ−軸に沿った手の移動が第１増分だけ加わると、第２グリフの増分時計回り方向回転によって視覚的に示され（第１グリフは、以前と同様、静止基準状態を示す）、グリフの「歯状」エレメントは、手の閾値からのオフセットの線形関数に対応する第１の量だけ回転する。ディスプレイに向かうｚ−軸に沿った手の移動が第２増分だけ加わると、第２グリフの増分時計回り方向回転によって視覚的に示され（第１グリフは、以前と同様、静止基準状態を示す）、グリフの「歯状」エレメントは、手の閾値からのオフセットの線形関数に対応する第２の量だけ回転する。更に、ディスプレイに向かうｚ−軸に沿った手の移動の第３の増分は、第２グリフの増分時計回り方向回転によって視覚的に示され（第１グリフは、以前と同様、静止基準状態を示す）、グリフの「歯状」エレメントは、手の閾値からのオフセットの線形関数に対応する第３の量だけ回転する。

【0278】

この見本とした用途では、操作者の手がアクティブ・ゾーン内にあるとき、副次的な次元感度が関与する。手の横方向（ｘ−軸）運動が、この場合も可能なスケーリング関数によって、水平フレーム・シーケンスのｘ−変位にマッピングされる。スケーリング関数が正である場合、その効果は操作者の手の位置的「追従」(positional following)の１つであり、操作者はフレームを左右にスライドさせていることを知覚する。本体の横方向運動から生ずるデータ・フレームの横方向ｘ−軸変位の一例として、データ・フレームは左から右にスライドし、特定のデータ・フレームが、表示空間の左縁端を通って視野から消えるまたは部分的に消えていき、一方追加のデータ・フレームが表示空間の右縁端から埋まっていくようになっている。

【0279】

最後に、操作者が彼女の手の掌を前方に向けたポーズを終了させると（例えば、手を閉じて拳を作ることによって）、プッシュバック相互作用が終了し、フレームの集合体は素早くその元のｚ−抑制（即ち、ディスプレイと同一平面上）に戻される。同時に、フレーム集合体は、１つのフレームのディスプレイとのｘ−一致を達成するために、横方向に調節させられる。終了するフレーム、つまり、「ディスプレイの中心に来る」フレームは、プッシュバック終了の時点において同心円状グリフの中心に最も近かった、即ち、最も近いｘ−抑止点(nearest x-detent)にあった、いずれかのフレームである。ここでは、グリフ構造は、選択レティクルとして第２の機能を果たすように見えるが、実施形態はそのように限定されるのではない。フレーム集合体のｚ−およびｘ−位置は、通例、「ばね装填戻り」(spring-loaded return)の視覚的感覚を与えるために、短い時間感覚でそれらの最終的なディスプレイ−一致値まで進行することが許される。

【0280】

この例において配備されるプッシュバック・システムは、（１）直接視覚視線−−深度次元−−に沿って総計したデータ集合を可変的に変位させることによって、認識的に貴重な「近隣コンテキスト」を取得することによって、視野に入れるデータ集合を増やす（データ集合のいずれの所与の部分についても、その角度範囲を縮小することと交換に）、（２）横方向に配列されたデータ集合をその自然水平次元に沿って可変的に変位させることによって、近隣コンテンツを取得し、データのいずれの所与の区間についてもその角度範囲を維持するが、馴染みのある「スクローリング」という感覚で、古いデータの見える範囲(visibility)を新しいデータのそれと交換する、（３）素早く次元的に制約されたナビゲーションによって、データ集合の離散化エレメントを選択するための効率的な制御様式を提供する。

【0281】

一実施形態のプッシュバックの他の例では、操作者がウェスト・レベル・ディスプレイ・デバイスの直ぐ隣に起立する。ディスプレイ・デバイスのアクティブ面は、床面と平行な水平面にある。ここでは、座標系は、以前の例のそれと矛盾しないように設定される。表示面はｘ−ｚ面内にあるので、表面に対して法線を表すｙ−軸は、物理的重力ベクトルに対して反対に位置合わせされる。

【0282】

本体をテーブル状表示面の上で水平に保持した、物理的場面の一例では、本体は操作者の手であるが、実施形態はそのように限定されるのではない。プッシュバック相互作用は両面型であるので、上側デッド・ゾーン閾位値および下側デッド・ゾーン閾値１がある。加えて、プッシュバック操作によってアクセスされる線形空間には、離散空間抑止点（例えば、「第１抑止点」、「第２抑止点」、「第３抑止点」、「第４抑止点」）が上側アクティブ・ゾーンの中に設けられており、離散空間抑止点（例えば、「第１抑止点」、「第２抑止点」、「第３抑止点」、「第４抑止点」）が下側アクティブ・ゾーンの中に設けられている。一実施形態の相互作用空間は、上側デッド・ゾーンおよび下側デッド・ゾーンを備えている比較的小さなデッド・ゾーンが、プッシュバックが関与する垂直（ｙ−軸）位置を中心に配され、アクティブ・ゾーンがこのデッド・ゾーンの上となり、アクティブ・ゾーンがこのデッド・ゾーンの下になるように構成されている。

【0283】

操作者は、データ集合の一例を用いて作業しており、このデータ集合は離散平行面のスタックに分析されており、これらの離散平行面がデータ・フレームとなる。このデータ集合は、このようにして、それが表す物理的現実の自然な結末（例えば、断層写真走査からの離散スライス、三次元集積回路の多数のレイヤ等）として構成することができ、またはこれは、データ（例えば、多数のスペクトル帯域において取得した衛星画像、１０年毎のデータが別個のレイヤに入っている、地理的に組織された人口調査データ等）を分離および離散化するように論理的または有益であるので、そのように構成することができる。更に、データの視覚表現は、静的であってもよく、または動的エレメントを含んでもよい。

【0284】

プッシュバック機能が関与していない区間では、１つのレイヤが「現行」と見なされ、表示によって視覚的に目立って表され、物理的にディスプレイと一致すると知覚される。現行のレイヤの上および下にあるレイヤは、この例では、視覚的に一目瞭然ではない（その存在を示すためにこじんまりした図象が用いられているが）。

【0285】

操作者は、ディスプレイ上で彼の閉じた右手を広げる。手を広げると、指が前方に広がり、親指が左に広がり、掌は下方を指し示し（遷移：［＾＾＾＾＞：ｖｘから｜｜｜｜−：ｖｘ］）、このときにプッシュバック・システムが関与する。短い間隔（例えば、２００ミリ秒）の間、現行のレイヤに隣接するある数のレイヤが、異なる視感度で現れる。各々は、ぼやけフィルタおよび透明性で、上下に合成される。その「程度」(severities)はそれぞれのレイヤの現行レイヤからの通常距離(ordinal distance)に依存する。

【0286】

例えば、プッシュバック・システムを起動させると、現行のレイヤ（例えば、データ・フレーム）に隣接するレイヤ（例えば、データ・フレーム）が、異なる視感度で、徐々に現れる。この例では、スタックが多数のデータ・フレーム（データ・フレームのデータ集合に相応しいいずれかの数）を備えており、プッシュバック・システムを用いてこれらの間であちこちに移動する(traverse)ことができる。

【0287】

同時に、以前の例から馴染みのある同心円状フィードバック・グリフが現れる。この場合、小さなデッド・ゾーンが、プッシュバックが関与する垂直（ｙ−軸）位置を中心として配置され、アクティブ・ゾーンがデッド・ゾーンの上下双方に来るように、相互作用が構成されている。この配置によって、元のレイヤに「帰り着く」際において補助が与えられる。この場合、グリフは、連続レイヤに対する接近指示(directed proximity)を示す追加の単純なグラフィックによって作成される。

【0288】

操作者の手がデッド・ゾーン内に残っている間、レイヤ・スタックの変位は発生しない。グリフは、直前の例における場合と同じ「予備的」行動を表し、手がゾーンのいずれかの境界に近づくに連れて、内側のグリフが大きくなる（勿論、ここでは、行動は両面で対称的である。内側のグリフは、手の開始ｙ−位置では最小スケールにあり、手が上または下に動いても、外側のグリフと一致する方向に大きくなる）。

【0289】

操作者の手がデッド・ゾーンの上平面を超えて上方に移動すると、内側のグリフは外側のグリフと重なり合い、以前と同様に、その方向に手が更に移動すると、内側グリフの反時計回り方向の回転運動が生ずる。同時に、レイヤ・スタックは「上方に平行移動」し始める。これらのレイヤの位置、元の現行レイヤの上にあるレイヤほど透明性が高くぼやけており、元の現行レイヤ自体はますます透過して行きそして一層ぼやけていく。その下にあるレイヤは、はっきりと見えてきてぼやけが少なくなる方向に移動する。

【0290】

スタックの上方向への平行移動の他の例では、以前の現行レイヤが透明度を増して行き（この例では、見えなくなっていく）、この直前の現行レイヤに隣接するレイヤが、現時点における現行レイヤとして見ることができるようになる。加えて、スタックが上方に平行移動するに連れて、現時点における現行レイヤに隣接するレイヤが、異なる視感度で徐々に現れてくる。前述のように、スタックは、多数のデータ・フレーム（データ・フレームのデータ集合に相応しいいずれかの数）を備えており、プッシュバック・システムを用いてこれらの間であちこちに移動することができる。

【0291】

レイヤ・スタックは、実世界距離（即ち、操作者の手のその初期位置からの変位を、部屋の座標(room coordinates)において測定したもの）と連続するレイヤ間における「論理的」距離との間におけるマッピングによって構成されている。レイヤ・スタックの平行移動は、勿論、近接度グラフィクスの瞬時的出現のように、このマッピングの結果である。一方、これは、表示面と現行レイヤとの間において（当初は）大きくなる距離を示す。また、これは、表示面が現在現行レイヤの下にあることも示す。

【0292】

手の運動は続き、レイヤ・スタックは最終的に、現行のレイヤおよびその次の下にあるレイヤが正に表示面を跨る（即ち、表示面から等距離となる）位置を通過する。この地点を丁度通過するときに、近接度グラフィクスが変化して、表示面が今や現行のレイヤよりも高いことを示す。このとき、「現行レイヤ・ステータス」は既に次に低いレイヤに割り当てられている。一般に、現行のレイヤは、常に物理的表示面に最も近いレイヤであり、操作者がプッシュバック・システムを解除したときに、「選択される」レイヤである。

【0293】

操作者が彼の手を上げ続けると、連続する各レイヤが表示面に向けて送られ、徐々に良く見えるようになり(resolved)、表示面との一時的な一致を得て、次いで次に低いレイヤを優先して、再び透明になりぼやけていく。操作者が彼の手の運動方向を逆にして、それを下げると、プロセスが逆になり、内側のグリフが時計回り方向に回転する。手が最終的にデッド・ゾーンを通過すると、元の現行レイヤが正確に表示面とｙ−軸と一直線になり(y-alignment)、スタックが停止する。次いで、スタックのｙ−進行が再開し、元の現行レイヤの上にある平面に連続的に焦点を合わせる。操作者の総合的な知覚は、彼が彼の手を用いて、レイヤのスタックを押し下げそして引き上げているという、強くそして単純なものである。

【0294】

最後に、操作者が彼の手を閉じて（または、それ以外でそのポーズを変化させる）ことによってプッシュバックを解除すると、システムは、スタックを、表示面と一直線にｙ−軸方向に抑止するように(detented y-axis alignment)「急に変化させ」、プッシュバックを終了したときに表示面に最も近かったレイヤを、現行レイヤとする。この位置合わせ(positional alignment)の短い区間の間、他の全てのレイヤは、完全な透明状態に徐々に戻り、フィードバック・グリフは滑らかに消失する。

【0295】

この例のデータ集合（ここでは、レイヤ）の離散化したエレメントは、主要プッシュバック（深度）軸に沿って分散される。以前では、これらのエレメント（データ・フレーム）は同じ平面にあり、深度軸に対して直交する次元に沿って横方向に配列されていた。この現在の配列は、透明技法の配備と共に、データが重畳されることが多く、あるレイヤは他のレイヤを通して見られることを意味する。しかしながら、この例における操作者は、（１）近隣コンテキスト（現行レイヤの上および下にあるレイヤの内容はなにか）を素早く得る装置(facility)、および（２）データ集合における平行積層エレメント間で効率的に選択し切り換える装置も享受する。操作者が（１）のみを意図する場合、デッド・ゾーンを設けることによって、操作者は元来選択されたレイヤに確実に戻ることができる。操作全体にわたって、２つの平行移動次元(translational dimensions)の抑制によって、速度および精度が可能になる（殆どの人間にとって、横方向にドリフトを生じることなく手を垂直に平行移動させることは比較的難しいが、前述したような様式は、このような横方向変位を単純に全て無視する）。

【0296】

尚、ある種の目的のために、デッド・ゾーンが無限に広がるようにプッシュバック入力空間を構成することが好都合である場合もあることを注記しておく。そして、プッシュバックが関与すると直ぐに、そのアクティブなメカニズムも投入される。本明細書において紹介する第２の例では、これは、本来の現行レイヤは、一旦プッシュバック操作が開始されたなら、他のいずれとも同じように扱われることを意味する。経験的に、デッド・ゾーンの直線的な広がりは、操作者の好みの問題である。

【0297】

この第２の例において説明した様式は、二次元（投影式または放射式のいずれでも構わない）および三次元（自動ステレオ式で、空中画像生成式(aerial-image-producing)等であろうとなかろうと構わない）デバイス双方を含む多種多様のディスプレイにわたって関連がある。後者、即ち、３Ｄの高品質な実施態様の場合、媒体のある種の特性が、プッシュバックの基礎となる知覚メカニズムを広く補助することができる。例えば、パララックス、光学被写体深度、および視覚的適応(ocular accommodation)現象の組み合わせは、多数のレイヤを同時に捕らえることを可能とし、表示面から多いレイヤを激しく褪せさせたりぼけさせる（または実際には一緒に除外する）必要性を解消する。更に、これらの様式は、ディスプレイの方位に関係なく適用される。これは、例におけるように、主に水平とするとよく、または壁上の目の高さに取り付けても同様に有用であると考えられる。

【0298】

この第２の例の場面に対する拡張では、２つの手による操作の有用性を示す。ある種の用途では、レイヤ・スタック全体の平行移動、または個々のレイヤの横方向（即ち、ｘおよびｚ方向）の平行移動が必要となることがある。一実施形態では、操作者の他の、即ち、プッシュバックではない、手がこの変換を、例えば、ある様式によって行うことができる。この様式では、手を表示面に近接させると、データ集合のレイヤの内１つを「スライドさせ回す」(slide around)ことができるので、そのオフセットｘ−ｚ位置が手のそれを追従するようになる。

【0299】

操作者は、一般に、横方向平行移動およびプッシュバック操作を同時に着手することを、便利であり容易に御し易い(tractable)と考えることができる。連続ドメイン操作を一方の手に割り当て、離散型作業を他方の手に割り当てることにより、認識負荷(cognitive load)を最適化するように作用することができると提案することは、恐らく全面的に無意味なことではない。

【0300】

データ集合に対して自然な視覚的側面がないＳＯＥの下においてプッシュバックの更に別の例について検討することは有用である。代表的なのは、複数のオーディオ・チャネルを監視し、集合体の中から間欠的に１つを選択する問題である。プッシュバック・システムを適用すると、聴覚的出力には備えているが視覚出力には備えていない環境において、このようなタスクを可能にする。この様式は、直前の例のそれと非常に似ている。

【0301】

操作者は、起立または着座して、１つのオーディオ・チャネルを聞いている。概念的に、このオーディオは、「聴覚面」と呼ばれる垂直面に存在し、この面には、幾何学的に、彼女の耳が含まれる。追加のオーディオ・チャネルは、この聴覚面に平行な追加の面内に存在するが、ｚ−軸に沿って前方または後方に変位されている。

【0302】

彼女の手を開いて、彼女の前９インチのところに保持し、掌を前方に向けて、プッシュバック・システムを投入する。数個の近接する面におけるオーディオが、差別的に徐々に現れ、各々の音量は、現行チャネルの面からのその元の距離に逆に依存する。実際には、２つまたは４つの追加チャネルを聴取可能にすることは、知覚的に非現実的である。同時に、「オーディオ・グリフ」が徐々に現れて、近接度フィードバックを与える。初期状態では、操作者の手がデッド・ゾーン内に保持されているが、グリフは辛うじて聞くことができる２音調の和音である（初期状態では、調和している）。

【0303】

操作者が彼女の手を前方または後方に、デッド・ゾーンを通過するように移動させると、オーディオ・チャネルの音量は一定のままであるが、グリフの音量が増大する。手がデッド・ゾーンの前または後ろの閾値と交差すると、グリフはその「アクティブな」音量に到達する（未だ現行チャネルの音量に従う）。

【0304】

一旦操作者の手が、例えば、前方方向に、アクティブ・ゾーンを通過して移動始めると、オーディオ・チャネルに期待される効果が得られる。現行のチャネル面が聴覚面から更に遠離るように押され、その音量が徐々に減少する（そして、これらのチャネルの音量はなおも更に先に進む(forward)）。一方、「背後の」(dorsal)チャネル面の音量は、それが聴覚面に近づくに連れて、増大する。

【0305】

一方、オーディオ・グリフはモードを切り換えている。手の前方への繰り出しには、トーンの１つの周波数上昇が伴い、「中点」において、聴覚面が１つのオーディオ・チャネル面および次のオーディオ・チャネル面に二等分すると、トーンが正確な１／５を形成する（数学的に、これは三全音間隔(triton interval)であるべきであるが、これを避けるべき理由がふんだんにある）。可変トーンの周波数は、手が更に前方に移動し続けるにしたがって、最終的に操作者が次のオーディオ面に「到達」するまで、上昇し続ける。次のオーディオ面に到達した時点で、トーンは正確に１オクターブに広がる。

【0306】

種々のチャネルの試聴が続き、操作者は彼女の手を前後に平行移動させて、各々に順番にアクセスする。最後に、１つを選択するためには、単に彼女の手を閉じて、プッシュバック・セッションを終了させ、オーディオ面の集合体を整列状態(alignment)に「素早く変化させる」(spring)。他の（選択されなかった）チャネルは、グリフと同様に、徐々に消えて行き聞こえなくなる。

【0307】

この例は、プッシュバック用途の異種を例示したのであり、同じ機能がこの場合も得られる。即ち、近隣コンテキストへのアクセス、および離散化したデータ・エレメント（ここでは、個々のオーディオ・ストリーム）の迅速な選択である。この場面は、聴覚フィードバック・メカニズム、特に、操作者が選択を行える程に目標チャネルに「十分近づいている」か否かについての情報を操作者に提供するために、信頼性のある人間のある種の周波数間隔を認識する能力(capacity)を利用するメカニズムに取って代わる。これは、特に、「可聴」信号が間欠的に現れるのみである音声チャネルにおいて重要である。オーディオ・フィードバック・グリフの連続性によって、それが存在したままとなり、チャネル自体が無音になっていても識別可能であり続ける。

【0308】

尚、本例におけるＳＯＥが空間化オーディオ(spatialized audio)を含む場合、前方距離(forward distance)に遠のくそして背後から近づく（またはその逆）連続オーディオ・レイヤの知覚を大幅に改善することができることを注記しておく。更に、操作者の位置において選択されたオーディオ面を一層文字どおりに(literally)「定位」する機会(opportunity)が、操作者の前にある後続レイヤおよび背後にある以前のレイヤと共に、有用に活用可能となる。

【0309】

オーディオ・グリフの他のインスタンス化も可能であり、実際に、スペクトル分布を含む、種々のチャネル内容の特質が、どの種のグリフが最も明確に認識できるかを決定付ける傾向がある。一例として、他のオーディオ・グリフ・フォーマットが一定の音量を維持するが、周期的なクリックを用い、クリック間の間隔が聴覚面と最も近いオーディオ・チャネル面との近接性に比例する。最後に、ある種の状況の下では、そして操作者の鋭さに応じて、フィードバック・グリフが全くないオーディオ・プッシュバックを用いることが可能である。

【0310】

プッシュバック・メカニズムを参照して、データ集合の表現において空間抑止点の数および密度が非常に大きくなる方向に増大するにつれて、空間およびそのパラメータ化が事実上連続になる。即ち、非抑止(non-detented)となる。しかしながら、このような極限においてもプッシュバックは有効であり続ける。これは、部分的に、プッシュバックの各呼び出し前におけるデータ集合の「初期状態」を、一時的抑止として扱うことができ、単純にデッド・ゾーンとして理解できるからである。

【0311】

このような非抑止プッシュバックの用途は、無限に（または少なくとも実質的に）ズーム可能な図の考えと関連付けて見出すことができる。ズーム機能のプッシュバック制御は、オフセット手位置(offset hand position)をアフィン・スケール値(affine scale value)と関連付けるので、操作者は彼の手を前方または後方にズームの減少または増大（それぞれ）の度合いだけプッシュ(push)する。しかしながら、位置のズーム・パラメータへの直接マッピングによって、制御の手をデッド・ゾーンに戻しても、ズーム値をその初期状態に戻せることを保証するので、元の事前プッシュバック・ズーム状態(pre-pushback zoom state)は常に容易にアクセス可能である。

【0312】

以上の例において説明した各場面では、プッシュバック・システムの突出した態様、およびＳＯＥ下におけるその使用についての説明を行った。更に、本明細書において記載した操作の各々は、効率および正確度のために、特定の種類の知覚フィードバックが人間の移動を案内することを可能にすることによって、１秒以下で高精度にそして総合的に着手する(undertake)ことができることは言うまでもない。また、他のときには、操作者は数十秒の間１つの連続プッシュバック「セッション」に留まっていることを有用と思う。調査の目標やコンテキスト取得の目標は、更に長い間隔にわたるプッシュバックによって十分に果たされる。

【0313】

以上で説明した例は、物理的入力（ジェスチャ）空間の表現空間への線形マッピングを採用した。実空間においてＡ単位だけ制御手(control hand)を平行移動させると、Ａ平行移動が行われた実空間の位置には係わらず、常に、表現空間におけるＢ単位［プライム］(prime)だけの平行移動が得られる。しかしながら、他のマッピングも可能である。即ち、殆どの人間の操作者によって享受される精細モータ制御(fine motor control)によって、非線形マッピングの使用が可能となり、その場合、例えば、アクティブ閾値から遠く離れた差動ジェスチャ変換は、閾値付近におけるジェスチャ変換よりも、パラメータ化された次元に沿って大きな変位に変換することができる。

【0314】

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

【0315】

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

【0316】

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

【0317】

１）「リテラル・ポインティング」(literal pointing)の広く行き渡る自然なインターフェース技法としての使用。ジェスチャ・インターフェース環境において手を用いるか、あるいは物理的ポインティング・ツールまたはデバイスを用いる。

【0318】

２）画面の移動または再位置決めに対する自動補償。

【0319】

３）操作者の位置に応じて変化するグラフィクス・レンダリング。例えば、深度の知覚を高めるためにパララックス・シフトをシミュレーションする。

【0320】

４）実世界位置、方位、状態等を考慮に入れた、画面上表示への物理的オブジェクトの含入。例えば、大きく不透明な画面の前に立っている操作者は、アプリケーションのグラフィクスと、画面の背後にある（そして、恐らく移動しているか、または方位を変えている）スケール・モデル(scale model)の真の位置の表現との双方を見ることができる。

【0321】

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

【0322】

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

【0323】

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

【0324】

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

【0325】

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

【0326】

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

【0327】

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

【0328】

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

【0329】

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

【0330】

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

【0331】

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

【0332】

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

【0333】

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

【0334】

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

【0335】

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

【0336】

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

【0337】

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

【0338】

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

【0339】

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

【0340】

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

【0341】

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

【0342】

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

【0343】

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

【0344】

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

【0345】

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

【0346】

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

【0347】

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

【0348】

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

【0349】

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

【0350】

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

【0351】

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

【0352】

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

【0353】

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

【0354】

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

【0355】

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

【0356】

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

【0357】

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

【0358】

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

【0359】

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

【0360】

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

【0361】

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

【0362】

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

【0363】

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

【0364】

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

【0365】

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

【0366】

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

【0367】

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

【0368】

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

【0369】

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

【0370】

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

【0371】

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

【0372】

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

【0373】

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

【0374】

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

【0375】

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

【0376】

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

【0377】

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

【0378】

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

【0379】

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

【0380】

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

【0381】

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

【0382】

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

【0383】

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

【0384】

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

【0385】

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

【0386】

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

【0387】

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

【0388】

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

【0389】

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

【0390】

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

【0391】

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

【0392】

【表20】

【0393】

別の例として、マウスのクリックを記述するプロテインは次の通りである。

【0394】

【表21】

【0395】

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

【0396】

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

【0397】

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

【0398】

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

【0399】

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

【0400】

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

【0401】

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

【0402】

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

【0403】

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

【0404】

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

【0405】

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

【0406】

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

【0407】

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

【0408】

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

【0409】

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

【0410】

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

【0411】

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

【0412】

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

【0413】

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

【0414】

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

【0415】

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

【0416】

以上のようにプールを用いると、システム性能に不当に影響を及ぼすことはない。例えば、実施形態は、毎秒数十万個のプロテインをプールに貯入することを考慮しているので、比較的冗漫なデータ出力を可能にしても、殆どのプログラムの応答性や双方向処理特性を著しく阻害することはない。 本明細書において記載した実施形態は、複数のソースからの入力データを照合するステップを備えている方法を含む。入力データは、オブジェクトの基準フレームにおいて当該オブジェクトの瞬時的空間および幾何学的状態の、意味的に相関付けられていない三空間データである。一実施形態の方法は、入力データを空間時間データのストリームに適合させるステップを備えている。空間時間データのストリームは、均一に表される。一実施形態の方法は、複数のジェスチャ記述を用いて、空間時間データからジェスチャ・イベントを発生するステップを備えている。一実施形態の方法は、アプリケーションにニュートラルであり完全に有機的に統合されているデータ・フォーマットを備えるプロトイベントにおいて、ジェスチャ・イベントを表現するステップを備えている。一実施形態の方法は、ジェスチャ・イベントを配信し、少なくとも１つのイベント・コンシューマの空間−意味的基準フレームにおいて、少なくとも１つのイベント・コンシューマによる対応するプロトイベントを通じたジェスチャ・イベントへのアクセスを提供するステップを備えている。

【0417】

本明細書において記載した実施形態は、方法を含む。この方法は、複数のソースからの入力データを照合するステップであって、入力データが、オブジェクトの基準フレームにおいて当該オブジェクトの瞬時的空間および幾何学的状態の、意味的に相関付けられていない三空間データである、ステップと、入力データを空間時間データのストリームに適合させるステップであって、空間時間データのストリームが均一に表される、ステップと、複数のジェスチャ記述を用いて、空間時間データからジェスチャ・イベントを発生するステップと、アプリケーションにニュートラルであり完全に有機的に統合されているデータ・フォーマットを備えるプロトイベントにおいて、ジェスチャ・イベントを表現するステップと、ジェスチャ・イベントを配信し、少なくとも１つのイベント・コンシューマの空間−意味的基準フレームにおいて、少なくとも１つのイベント・コンシューマによる対応するプロトイベントを通じたジェスチャ・イベントへのアクセスを提供するステップとを備えている。

【0418】

一実施形態の入力データは、オブジェクトの非制約自由空間ジェスチャ・データを構成する。

【0419】

一実施形態の入力データは、オブジェクトが表面に対する近接範囲以内および定められた立体空間以内の内少なくとも一方にあるとき、オブジェクトの近接ジェスチャ・データを構成する。

【0420】

一実施形態の入力データは、オブジェクトが表面に直接隣接する空間の中にあるとき、オブジェクトのホバー・ジェスチャ・データを構成する。

【0421】

一実施形態の入力データは、オブジェクトが表面と接触しているとき、オブジェクトの表面接触ジェスチャ・データを構成する。

【0422】

一実施形態の入力データは、複数のデータ・ストリームを構成する。

【0423】

一実施形態の方法は、複数のデータ・ストリームを時間的に整合するステップを備えている。

【0424】

一実施形態の方法は、複数のデータ・ストリームからのイベントを空間的に繋ぎ合わせ、１つの合成イベントを発生するステップを備えている。

【0425】

一実施形態の方法は、 データ・ファンネルの以前の動作から得られた関連イベントを収集することを含む、意味的集計を実行するステップを備えている。

【0426】

一実施形態の方法は、メタ情報タギングを実行するステップを備えている。

【0427】

一実施形態の方法は、光学式モーション追跡システム、飛行時間追跡システム、電界検知システム、およびタッチ・スクリーン・デバイスの内少なくとも１つから入力データを受け取るステップを備えている。

【0428】

一実施形態の方法は、光学式モーション追跡システムから入力データを受け取るステップを備えている。

【0429】

一実施形態の方法は、飛行時間追跡システムから入力データを受け取るステップを備えている。

【0430】

一実施形態の方法は、タッチ・スクリーン・デバイスから入力データを受け取るステップを備えている。

【0431】

一実施形態の方法は、電界検知システムから入力データを受け取るステップを備えている。

【0432】

一実施形態の方法は、容量式検知システムから入力データを受け取るステップを備えている。

【0433】

一実施形態の方法は、オブジェクトの三空間位置を含む空間時間データを受け取るステップを備えている。

【0434】

一実施形態の方法は、オブジェクトの三空間方位を含む空間時間データを受け取るステップを備えている。

【0435】

一実施形態の方法は、オブジェクトのモーションを含む空間時間データを受け取るステップを備えている。

【0436】

一実施形態の方法は、オブジェクトを構成する複数のエレメントおよびオブジェクトに結合されている複数のエレメントの内少なくとも１つの全体的三空間位置を含む空間時間データを受け取るステップを備えている。

【0437】

一実施形態の方法は、オブジェクトを構成する複数のエレメントおよびオブジェクトに結合されている複数のエレメントの内少なくとも１つの全体的三空間方位を含む空間時間データを受け取るステップを備えている。

【0438】

一実施形態の方法は、オブジェクトを構成する複数のエレメントおよびオブジェクトに結合されている複数のエレメントの内少なくとも１つの全体的モーションを含む空間時間データを受け取るステップを備えている。

【0439】

一実施形態の方法は、オブジェクトを構成する複数のエレメントのポーズの意味的ダイジェストを含む空間時間データを受け取るステップを備えている。

【0440】

一実施形態の方法は、空間時間データをジェスチャ記述と比較するステップを備えている。

【0441】

一実施形態の方法は、空間時間データとジェスチャ記述との間における一致に応答してプロトイベントを発生するステップを備えており、このプロトイベントが、一致した空間時間データを、一致したジェスチャ記述の意味的コンテキストで解釈したダイジェストを構成する、データ・フォーマットを含む。

【0442】

一実施形態の方法は、複数の認識部を設けるステップを備えており、各認識部がジェスチャ記述を備えている。

【0443】

一実施形態の方法は、複数の認識部において複数の動作を実行するステップを備えており、これら複数の動作が、認識部を格付けすることを含む。

【0444】

一実施形態の方法は、複数の認識部において複数の動作を実行するステップを備えており、これら複数の動作が、認識部を追加することを含む。

【0445】

一実施形態の方法は、複数の認識部において複数の動作を実行するステップを備えており、これら複数の動作が、認識部を除去することを含む。

【0446】

一実施形態の方法は、複数の認識部において複数の動作を実行するステップを備えており、これら複数の動作が、認識部を修正することを含む。

【0447】

一実施形態の方法は、複数の認識部において複数の動作を実行するステップを備えており、これら複数の動作が、認識部を構成し直すことを含む。

【0448】

空間時間データと認識部の始動(activation)判断基準との間で一致が得られる前には、一実施形態の認識部が休止状態であり続ける。

【0449】

空間時間データの幾何学的および空間時間的な側面が、始動判断基準と一致したときに、一実施形態の認識部がアクティブになる。

【0450】

空間時間データが認識部の維持判断基準を満たす限り、一実施形態の認識部がアクティブであり続ける。

【0451】

空間時間データが維持判断基準を満たすことができなくなったときに、一実施形態の認識部がインアクティブになる。

【0452】

一実施形態の方法は、少なくとも１つのイベント・コンシューマによるアクセスのために、プロトイベントを少なくとも１つのレポジトリに預けるステップを備えている。

【0453】

一実施形態の方法は、少なくとも１つのイベント・コンシューマのリストを提供するステップを備えている。

【0454】

一実施形態の方法は、発生された各プロトイベントを、非同期に、少なくとも１つのイベント・コンシューマの各々に送信するステップを備えている。

【0455】

一実施形態の方法は、発生された各プロトイベントを、同期して、少なくとも１つのイベント・コンシューマの各々に送信するステップを備えている。

【0456】

一実施形態の方法は、複数のイベント・コンシューマに対応する複数の空間−意味基準フレームの間で、ジェスチャ・イベントを変換するステップを備えている。

【0457】

一実施形態の方法は、少なくとも１つのイベント・コンシューマの空間−意味基準フレームにおいて、ジェスチャ・イベントをレンダリングし直すステップを備えている。

【0458】

一実施形態の方法は、ジェスチャ・イベントを指定するジェスチャ・イベント・データと、ジェスチャ・イベントの状態情報とを含む少なくとも１つのデータ・シーケンスを発生し、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成することによって、プロトイベントを発生するステップを備えており、データ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を含むデータ構造を有する。

【0459】

少なくとも１つのデータ・シーケンスを発生するステップは、第１個別ジェスチャ・イベント・データを含む第１個別データ集合を発生するステップを含む。少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを含む。少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第１データ・シーケンスを形成するステップを含む。

【0460】

少なくとも１つのデータ・シーケンスを発生するステップは、第１個別ジェスチャ・イベント・データを含む第１個別データ集合を発生するステップを含む。少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを含む。少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第２データ・シーケンスを形成するステップを含む。

【0461】

一実施形態の第１個別データ集合を発生するステップは、第１個別データ集合オフセットを発生するステップを含み、第１個別データ集合オフセットが、第２データ・シーケンスの第１個別データ集合を指し示す。

【0462】

第２個別データ集合を発生するステップは、第２個別データ集合オフセットを発生するステップを含み、第２個別データ集合オフセットが、第２データ・シーケンスの第２個別データ集合を指し示す。

【0463】

一実施形態の第１個別データ集合は、記述リストであり、この記述リストがデータの記述を含む。

【0464】

一実施形態の方法は、少なくとも１つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットを含むように、データ・カプセルを形成するステップを備えている。

【0465】

一実施形態の方法は、第１可変長を有する第１オフセットを発生するステップを備えている。第１オフセットは、少なくとも１つのデータ・シーケンスの内第１データ・シーケンスのジェスチャ・イベント・データを指し示す。

【0466】

一実施形態の方法は、第２可変長を有する第２オフセットを発生するステップを備えている。第２オフセットは、少なくとも１つのデータ・シーケンスの内第１データ・シーケンスの状態情報を指し示す。

【0467】

一実施形態の方法は、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通じて第１コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通じて第２コード経路を形成するステップを備えている。第１コード経路および第２コード経路は、異なる経路である。

【0468】

一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータを含み、このメタデータがコンテキスト特定メタデータを含む。

【0469】

一実施形態の少なくとも１つのイベント・コンシューマは、複数のインタラクティブ・システムの内少なくとも１つのインタラクティブ・システムであり、複数のインタラクティブ・システムは、複数の基準フレームを備えている。

【0470】

一実施形態の少なくとも１つのイベント・コンシューマは、当該少なくとも１つのイベント・コンシューマに特定のアプリケーション・タイプを用いて、プロトイベントを消費する。

【0471】

一実施形態の少なくとも１つのイベント・コンシューマは、第１基準フレームを有する第１インタラクティブ・システムと、第２基準フレームを有する第２インタラクティブ・システムとを備えている。

【0472】

一実施形態の第１インタラクティブ・システムは、第１アプリケーション・タイプを用いて、プロトイベントを消費し、第２インタラクティブ・システムは、第２アプリケーション・タイプを用いて、プロトイベントを消費する。

【0473】

一実施形態のオブジェクトは、人間の手である。

【0474】

一実施形態のオブジェクトは、人間の手の少なくとも１本の指である。

【0475】

一実施形態のオブジェクトは、少なくとも１つの人間の手と、人間の手の少なくとも１本の指を含む。

【0476】

本明細書において記載した実施形態は、複数のソースからの入力データを照合するステップを備えている方法を含む。入力データは、オブジェクトに対応する、意味的に相関付けられていない三空間データであり、複数のソースが別々のソースを構成する。一実施形態の方法は、入力データから、オブジェクトの複数の空間イベントをレンダリングするステップを備えている。複数の空間イベントが、全域的部屋空間に対する、適合座標表現を構成する。一実施形態の方法は、空間イベントから空間イベントの集計を発生するステップを備えている。この集計は、オブジェクトの忠実な幾何学的および意味的特性を含む論理集計である。一実施形態の方法は、空間イベントの集計から、ジェスチャを検出し明確にするステップを備えている。一実施形態の方法は、ジェスチャを表すデータ・バンドルを発生するステップを備えている。このデータ・バンドルは、中立的に記述的である。一実施形態の方法は、複数の別々のアプリケーションによる消費のために、データ・バンドルを配信するステップを備えている。

【0477】

本明細書において記載した実施形態は、方法を含む。この方法は、複数のソースからの入力データを照合するステップであって、入力データが、オブジェクトに対応する、意味的に相関付けられていない三空間データであり、複数のソースが別々のソースを構成するステップと、入力データから、オブジェクトの複数の空間イベントをレンダリングするステップであって、複数の空間イベントが、全域的部屋空間に対して適合座標表現を構成する、ステップと、空間イベントから空間イベントの集計を発生するステップであって、この集計が、オブジェクトの忠実な幾何学的および意味的特性を含む論理集計である、ステップと、空間イベントの集計から、ジェスチャを検出し明確にするステップと、ジェスチャを表すデータ・バンドルを発生するステップであって、データ・バンドルが中立的に記述的である、ステップと、複数の別々のアプリケーションによる消費のために、データ・バンドルを配信するステップとを備えている。

【0478】

本明細書において記載した実施形態は、プロセッサに結合されているデータ・ファンネルを備えているシステムを含む。このデータ・ファンネルは、複数のソースからの入力データを照合する。入力データは、オブジェクトの瞬時的空間および幾何学的状態の、オブジェクトの基準フレームにおける、意味的に相関付けられていない三空間データである。複数のソースは、別々のソースを構成する。データ・ファンネルは、入力データを空間時間データのストリームに適合させる。ストリームの空間時間データは、一意に表される。一実施形態のシステムは、データ・ファンネルに結合されているジェスチャ・エンジンを備えている。このジェスチャ・エンジンは、複数のジェスチャ記述を用いて、空間時間データからジェスチャ・イベントを発生する。ジェスチャ・エンジンは、アプリケーションにニュートラルに完全に有機的に統合される(articulate）データ・フォーマットを備えるプロトイベントでジェスチャ・イベントを表現する。一実施形態のシステムは、ジェスチャ・エンジンに結合されているディストリビュータを備えている。このディストリビュータは、少なくとも１つのイベント・コンシューマによるジェスチャ・イベントへのアクセスを、少なくとも１つのイベント・コンシューマの空間意味的基準フレームにおいて対応するプロトイベントを通じて提供する。

【0479】

本明細書において記載した実施形態は、システムを含む。このシステムは、プロセッサに結合されているデータ・ファンネルであって、このデータ・ファンネルが複数のソースからの入力データを照合し、この入力データが、オブジェクトの瞬時的空間および幾何学的状態の、オブジェクトの基準フレームにおける、意味的に相関付けられていない三空間データであり、複数のソースが、別々のソースを構成し、データ・ファンネルが入力データを空間時間データのストリームに適合させ、ストリームの空間時間データが一意に表される、データ・ファンネルと、データ・ファンネルに結合されているジェスチャ・エンジンであって、このジェスチャ・エンジンが、複数のジェスチャ記述を用いて、空間時間データからジェスチャ・イベントを発生し、ジェスチャ・エンジンが、アプリケーションにニュートラルに完全に有機的に統合されるデータ・フォーマットを備えるプロトイベントでジェスチャ・イベントを表現する、ジェスチャ・エンジンと、ジェスチャ・エンジンに結合されているディストリビュータであって、少なくとも１つのイベント・コンシューマによるジェスチャ・イベントへのアクセスを、少なくとも１つのイベント・コンシューマの空間意味的基準フレームにおいて対応するプロトイベントを通じて提供する、ディストリビュータとを備えている。

【0480】

一実施形態の入力データは、オブジェクトの非制約自由空間ジェスチャ・データを構成する。

【0481】

一実施形態の入力データは、オブジェクトが表面に対する近接範囲以内および定められた立体空間以内の内少なくとも一方にあるとき、オブジェクトの近接ジェスチャ・データを構成する。

【0482】

一実施形態の入力データは、オブジェクトが表面に直接隣接する空間の中にあるとき、オブジェクトのホバー・ジェスチャ・データを構成する。

【0483】

一実施形態の入力データは、オブジェクトが表面と接触しているとき、オブジェクトの表面接触ジェスチャ・データを構成する。

【0484】

一実施形態の入力データは、複数のデータ・ストリームを構成する。

【0485】

一実施形態のデータ・ファンネルは、複数のデータ・ストリームを時間的に整合する。

【0486】

一実施形態のデータ・ファンネルは、複数のデータ・ストリームからのイベントを空間的に繋ぎ合わせ、１つの合成イベントを発生する。

【0487】

一実施形態のデータ・ファンネルは、データ・ファンネルの以前の動作から得られた関連イベントを収集することを含む、意味的集計を実行する。

【0488】

一実施形態のデータ・ファンネルは、メタ情報タギングを実行する。

【0489】

一実施形態の入力データは、光学式モーション追跡システム、飛行時間追跡システム、電界検知システム、およびタッチ・スクリーン・デバイスの内少なくとも１つから受け取られる。

【0490】

一実施形態の入力データは、光学式モーション追跡システムから受け取られる。

【0491】

一実施形態の入力データは、飛行時間追跡システムから受け取られる。

【0492】

一実施形態の入力データは、タッチ・スクリーン・デバイスから受け取られる。

【0493】

一実施形態の入力データは、電界検知システムから受け取られる。

【0494】

一実施形態の入力データは、容量式検知システムから受け取られる。

【0495】

一実施形態のジェスチャ・エンジンは、オブジェクトの三空間位置を含む空間時間データを受け取る。

【0496】

一実施形態のジェスチャ・エンジンは、オブジェクトの三空間方位を含む空間時間データを受け取る。

【0497】

一実施形態のジェスチャ・エンジンは、オブジェクトのモーションを含む空間時間データを受け取る。

【0498】

一実施形態のジェスチャ・エンジンは、オブジェクトを構成する複数のエレメントおよびオブジェクトに結合されている複数のオブジェクトの内少なくとも１つの全体的三空間位置を含む空間時間データを受け取る。

【0499】

一実施形態のジェスチャ・エンジンは、オブジェクトを構成する複数のエレメントおよびオブジェクトに結合されている複数のオブジェクトの内少なくとも１つの全体的三空間方位を含む空間時間データを受け取る。

【0500】

一実施形態のジェスチャ・エンジンは、オブジェクトを構成する複数のエレメントおよびオブジェクトに結合されている複数のエレメントの内少なくとも１つの全体的モーションを含む空間時間データを受け取る。

【0501】

一実施形態のジェスチャ・エンジンは、オブジェクトを構成する複数のエレメントのポーズの意味的ダイジェストを含む空間時間データを受け取る。

【0502】

一実施形態のジェスチャ・エンジンは、空間時間データをジェスチャ記述と比較する。

【0503】

一実施形態のジェスチャ・エンジンは、空間時間データとジェスチャ記述との間における一致に応答してプロトイベントを発生し、このプロトイベントが、一致した空間時間データを、一致したジェスチャ記述の意味的コンテキストで解釈したダイジェストを構成する、データ・フォーマットを含む。

【0504】

一実施形態のジェスチャ・エンジンは、複数の認識部を備えており、各認識部がジェスチャ記述を備えている。

【0505】

一実施形態のジェスチャ・エンジンは、複数の認識部において複数の動作を実行し、これら複数の動作が、認識部を格付けすることを含む。

【0506】

一実施形態のジェスチャ・エンジンは、複数の認識部において複数の動作を実行し、これら複数の動作が、認識部を追加することを含む。

【0507】

一実施形態のジェスチャ・エンジンは、複数の認識部において複数の動作を実行し、これら複数の動作が、認識部を除去することを含む。

【0508】

一実施形態のジェスチャ・エンジンは、複数の認識部において複数の動作を実行し、これら複数の動作が、認識部を修正することを含む。

【0509】

一実施形態のジェスチャ・エンジンは、複数の認識部において複数の動作を実行し、これら複数の動作が、認識部を構成し直すことを含む。

【0510】

空間時間データと認識部の始動判断基準との間で一致が得られる前には、一実施形態の認識部は、休止状態であり続ける。

【0511】

空間時間データの幾何学的および空間時間的な側面が、始動判断基準と一致したときに、一実施形態の認識部はアクティブになる。

【0512】

空間時間データが認識部の維持判断基準を満たす限り、一実施形態の認識部はアクティブであり続ける。

【0513】

空間時間データが維持判断基準を満たすことができなくなったときに、一実施形態の認識部はインアクティブになる。

【0514】

一実施形態のディストリビュータは、少なくとも１つのイベント・コンシューマによるアクセスのために、プロトイベントを少なくとも１つのレポジトリに預ける。

【0515】

一実施形態のディストリビュータは、少なくとも１つのイベント・コンシューマのリストを備えている。

【0516】

一実施形態のディストリビュータは、ジェスチャ・エンジンによって発生された各プロトイベントを、非同期に、少なくとも１つのイベント・コンシューマの各々に送信する。

【0517】

一実施形態のディストリビュータは、ジェスチャ・エンジンによって発生された各プロトイベントを、同期して、少なくとも１つのイベント・コンシューマの各々に送信する。

【0518】

一実施形態のシステムは、少なくとも１つのコンシューマのリモート・クライアント・デバイスに結合されている変換器を備えており、この変換器が、少なくとも１つのイベント・コンシューマの空間意味的基準フレームにおいて、ジェスチャ・イベントをレンダリングし直す。

【0519】

一実施形態のディストリビュータは、変換器を含む。

【0520】

一実施形態のジェスチャ・エンジンは、ジェスチャ・イベントを指定するジェスチャ・イベント・データと、ジェスチャ・イベントの状態情報とを含む少なくとも１つのデータ・シーケンスを発生し、少なくとも１つのデータ・カプセルを形成することによって、プロトイベントを発生し、データ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を含むデータ構造を有する。

【0521】

一実施形態の少なくとも１つのデータ・シーケンスの発生は、第１個別ジェスチャ・イベント・データを含む第１個別データ集合を発生することを含む。一実施形態の少なくとも１つのデータ・シーケンスの発生は、第２個別状態情報を含む第２個別データ集合を発生することを含む。一実施形態の少なくとも１つのデータ・シーケンスの発生は、第１個別データ集合および第２個別データ集合を含むように、第１データ・シーケンスを形成することを含む。

【0522】

一実施形態の少なくとも１つのデータ・シーケンスの発生は、第１個別ジェスチャ・イベント・データを含む第１個別データ集合を発生することを含む。一実施形態の少なくとも１つのデータ・シーケンスの発生は、第２個別状態情報を含む第２個別データ集合を発生することを含む。一実施形態の少なくとも１つのデータ・シーケンスの発生は、第１個別データ集合および第２個別データ集合を含むように、第２データ・シーケンスを形成することを含む。

【0523】

一実施形態の第１個別データ集合の発生は、第１個別データ集合オフセットを発生することを含み、第１個別データ集合オフセットは、第２データ・シーケンスの第１個別データ集合を指し示す。

【0524】

一実施形態の第２個別データ集合の発生は、第２個別データ集合オフセットを発生することを含み、第２個別データ集合オフセットは、第２データ・シーケンスの第２個別データ集合を指し示す。

【0525】

一実施形態の第１個別データ集合は、記述リストであり、この記述リストがデータの記述を含む。

【0526】

一実施形態のシステムは、少なくとも１つのオフセットを発生することを含む。一実施形態のシステムは、少なくとも１つのオフセットを含むように、データ・カプセルを形成することを含む。

【0527】

一実施形態のシステムは、第１可変長を有する第１オフセットを発生することを含む。第１オフセットは、少なくとも１つのデータ・シーケンスの内第１データ・シーケンスのジェスチャ・イベント・データを指し示す。

【0528】

一実施形態のシステムは、第２可変長を有する第２オフセットを発生することを含む。第２オフセットは、少なくとも１つのデータ・シーケンスの内第１データ・シーケンスの状態情報を指し示す。

【0529】

一実施形態のシステムは、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通じて第１コード経路を形成することを含む。一実施形態のシステムは、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通じて第２コード経路を形成することを含む。第１コード経路および第２コード経路は、異なる経路である。

【0530】

一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータを含み、このメタデータがコンテキスト特定メタデータを含む。

【0531】

一実施形態の少なくとも１つのイベント・コンシューマは、複数のインタラクティブ・システムの内少なくとも１つのインタラクティブ・システムであり、複数のインタラクティブ・システムは、複数の基準フレームを備えている。

【0532】

一実施形態の少なくとも１つのイベント・コンシューマは、当該少なくとも１つのイベント・コンシューマに特定のアプリケーション・タイプを用いて、プロトイベントを消費する。

【0533】

一実施形態の少なくとも１つのイベント・コンシューマは、第１基準フレームを有する第１インタラクティブ・システムと、第２基準フレームを有する第２インタラクティブ・システムとを備えている。

【0534】

一実施形態の第１インタラクティブ・システムは、第１アプリケーション・タイプを用いて、プロトイベントを消費し、第２インタラクティブ・システムは、第２アプリケーション・タイプを用いて、プロトイベントを消費する。

【0535】

一実施形態のオブジェクトは、人間の手である。

【0536】

一実施形態のオブジェクトは、人間の手の少なくとも１本の指である。

【0537】

一実施形態のオブジェクトは、少なくとも１つの人間の手と、人間の手の少なくとも１本の指を含む。

【0538】

本明細書において記載した実施形態は、プロセッサに結合されているデータ・ファンネルを備えているシステムを含む。このデータ・ファンネルは複数のソースからの入力データを照合し、入力データを空間時間データのストリームに適合させる。入力データは、時間および空間の１点における本体の瞬時的状態の絶対三空間位置データである。一実施形態のシステムは、データ・ファンネルに結合されているジェスチャ・エンジンを備えている。このジェスチャ・エンジンは、複数のジェスチャ記述を用いて、空間時間データ・ストリームからジェスチャ・イベントを発生する。ジェスチャ・エンジンは、アプリケーションにニュートラルであるデータ・フォーマットを備えるプロトイベントで各ジェスチャ・イベントを表現する。一実施形態のシステムは、ジェスチャ・エンジンに結合されているディストリビュータを備えている。このディストリビュータは、複数のイベント・コンシューマによる複数のプロトイベントへのアクセスを通じて、ジェスチャ・イベントへのアクセスを提供する。ジェスチャ・イベントへのアクセスは、複数のイベント・コンシューマの空間−意味フレームにおいて行われる。

【0539】

本明細書において記載した実施形態は、システムを含む。このシステムは、プロセッサに結合されているデータ・ファンネルであって、このデータ・ファンネルが複数のソースからの入力データを照合し、入力データを空間時間データのストリームに適合させ、入力データが時間および空間の１点における本体の瞬時的状態の絶対三空間位置データである、データ・ファンネルと、データ・ファンネルに結合されているジェスチャ・エンジンであって、このジェスチャ・エンジンが、複数のジェスチャ記述を用いて、空間時間データ・ストリームからジェスチャ・イベントを発生し、ジェスチャ・エンジンが、アプリケーションにニュートラルであるデータ・フォーマットを備えるプロトイベントで各ジェスチャ・イベントを表現する、ジェスチャ・エンジンと、ジェスチャ・エンジンに結合されているディストリビュータであって、このディストリビュータが、複数のイベント・コンシューマによる複数のプロトイベントへのアクセスを通じて、ジェスチャ・イベントへのアクセスを与え、ジェスチャ・イベントへのアクセスが、複数のイベント・コンシューマの空間−意味基準フレームにおいて行われる、ディストリビュータとを備えている。

【0540】

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

【0541】

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

【0542】

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

【0543】

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

【0544】

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

【0545】

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

【0546】

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

【0547】

一般に、以下の特許請求の範囲では、前述の実施形態を本明細書および特許請求の範囲に開示される特定の実施形態に限定するように、用いられる用語を解釈してはならず、特許請求の範囲の下で動作する全てのシステムを含むように解釈してしかるべきである。したがって、前述の実施形態は、本明細書における開示に限定されるのではなく、代わりに、実施形態の範囲は、特許請求の範囲によって全体的に判断されるものとする。

【0548】

以上の実施形態のある種の態様が、以下にある種の請求項の形態で提示されるが、本発明者は、これら実施形態の種々の態様を、いかなる数の請求項の形態でも想定している。したがって、本発明者は、本願を出願した後に本実施形態の他の態様に対してこのような追加の請求項の形態を追求するために、追加の請求項を加える権利を保持することとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17A】

【図17B】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23A】

【図23B-1】

【図23B-2】

【図23C】

【図23D】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】