JP2018077882A

JP2018077882A - 複数クライアント装置およびディスプレイを有する動作環境のための方法、およびシステム

Info

Publication number: JP2018077882A
Application number: JP2017246355A
Authority: JP
Inventors: クレーマー，クウィンドラ・ハルトマン; Hultman Kramer Kwindla; アンダーコフラー，ジョン; Underkoffler John
Original assignee: Oblong Industries Inc
Current assignee: Oblong Industries Inc
Priority date: 2012-11-12
Filing date: 2017-12-22
Publication date: 2018-05-17
Also published as: CN105122790A; EP2918074A4; US20140240231A1; EP2918074A1; US10642364B2; JP2016504652A; WO2014075090A1; KR20150105308A

Abstract

【課題】空間的動作環境のジェスチャ制御において、複数の遠隔クライアント装置のコンテンツを同時に結集し、ディスプレイ装置を同時に制御できる方法を提供する。
【解決手段】方法は、ディスプレイ装置、センサ、プロセッサ、遠隔クライアント装置と、コンピュータアプリケーションとを備えたシステムを含む。コンピュータアプリケーションは、ディスプレイ装置および遠隔クライアント装置にまたがって遠隔クライアント装置のコンテンツを同時に結集し、ディスプレイ装置を同時に制御する。同時の制御には、センサを介して受信されたジェスチャデータから少なくとも一つのオブジェクトのジェスチャを自動的に検出することが含まれる。検出することには、ジェスチャデータのみを用いてジェスチャを識別することが含まれる。コンピュータアプリケーションは、ジェスチャをジェスチャ信号に変換し、ジェスチャ信号に応じてディスプレイ装置を制御する。
【選択図】なし

Description

［関連出願］
本出願は、出願日２０１２年１１月１２日の、米国特許出願第６１／７２５，４４９号の利益を主張する。
本出願は、出願日２０１２年１２月３１日の、米国特許出願第６１／７４７，９４０号の利益を主張する。
本出願は、出願日２０１３年３月１５日の、米国特許出願第６１／７８７，７９２号の利益を主張する。
本出願は、出願日２０１３年３月１４日の、米国特許出願第６１／７８５，０５３号の利益を主張する。
本出願は、出願日２０１３年３月１５日の、米国特許出願第６１／７８７，６５０号の利益を主張する。
本出願は、米国特許出願第１２／５７２，６８９号、第１２／５７２，６９８号、第１３／８５０，８３７号、第１２／４１７，２５２号、第１２／４８７，６２３号、第１２／５５３，８４５号、第１２／５５３，９０２号、第１２／５５３，９２９号、第１２／５５７，４６４号、第１２／５７９，３４０号、第１３／７５９，４７２号、第１２／５７９，３７２号、第１２／７７３，６０５号、第１２／７７３，６６７号、第１２／７８９，１２９号、第１２／７８９，２６２号、第１２／７８９，３０２号、第１３／４３０，５０９号、第１３／４３０，６２６号、第１３／５３２，５２７号、第１３／５３２，６０５号、第１３／５３２，６２８号、第１３／８８８，１７４号、第１３／９０９，９８０号、第１４／０４８，７４７号、第１４／０６４，７３６号の一部継続出願である。

［技術分野］
ここに記載する実施形態は、一般には、システムの処理に関し、より詳細には、空間的動作環境におけるジェスチャ制御に関する。

［背景］
従来の協調空間ソリューションは、個人使用の権限を与え、低帯域という前提を反映した、より古い入出力のアーキテクチャを反映している。さらに、ユーザが仕事を行うために集まった場合でも、それらのデジタルツールは互換性がない。人々が会議やプレゼンテーションのために持ち寄るこのような装置や「ソリューション」は、全く共働することができないことが多い。ユーザが協調（コラボレーション）するために集まる物理空間は、新しい技術、そして重要なことに、ユーザおよびビジネスの要望を反映するために進化しなければならない。市場における二つの転換を考えてみよう。

第一に、ピクセルが充分にある。ディスプレイは価格がより安く、品質がより高い。会社及び組織は、増加したディスプレイ解像度、ネットワーク容量、及び計算システムを活用して、会議室にて混合メディアを提示し、壁の設定を命令する。ユーザの目標は、印象深くピクセル通の、表現、議論、そして分析である。第二に、データが充分にある。データを格納、アクセスそして操作するための計算装置とシステムは、より安くより高品質である。

コンピュータのフォームファクタもまた多様であり、その実施形態―デスクトップ、ラップトップ、携帯電話、タブレット、ネットワークソリューション、クラウドコンピューティング、企業システム―はひたすら急増し続けている。これらの装置とソリューションは、データを無数の方法で扱う。低レベルのデータの保存から、高レベルの適切なイベントへのその処理、ユーザによる操作、そしてネットワーク越しの交換というあらゆる形態にわたり、コンピュータは、たとえばデータ形式と型、オペレーティングシステム、およびアプリケーションにおいて異なるアプローチを実装する。これらは相互運用性を阻害する多くの課題のなかのいくつかに過ぎない。

［参照による援用］
本明細書において言及されている特許、特許出願、及び／又は、出願公開の各々は、個々の特許、特許出願、及び／又は、出願公開の各々が具体的かつ個別的に示されて参照により援用されたのと同程度に、その全体が参照によりここに援用される。

一実施形態における、手の追跡および形状認識のコンポーネントまたはアプリケーションを担うプロセッサ、ディスプレイおよびセンサを含むＳＯＥキオスクのブロック図である。一実施形態における、ＳＯＥキオスクと操作者の関係を示す図である。一実施形態における、メザニンの導入を示す図である。一実施形態における、メザニンの論理図の例を示す図である。一実施形態における、メザニンのラック図の例を示す図である。一実施形態における、メザニンのドシエポータルのブロック図である。一実施形態における、メザニンのトリプティク（フルスクリーン）のブロック図である。一実施形態における、メザニンのトリプティク（プッシュバック）のブロック図である。一実施形態における、メザニンのアセットビンとライブビンのブロック図である。一実施形態における、メザニンのウィンドシールドのブロック図である。一実施形態における、メザニンのプッシュバック制御を示すブロック図である。一実施形態における、メザニンの入力モード制御を示す図である。一実施形態における、メザニンのオブジェクト移動制御を示す図である。一実施形態における、メザニンのオブジェクトのスケーリングを示す図である。一実施形態における、ボタンの解放でのメザニンのオブジェクトのスケーリングを示す図である。一実施形態における、接続前のメザニンのリーチスルーを示すブロック図である。一実施形態における、接続後のメザニンのリーチスルーを示すブロック図である。一実施形態における、リーチスルーポインタとメザニンのリーチスルーを示す図である。一実施形態における、メザニンのスナップショット制御を示す図である。一実施形態における、メザニンの削除制御を示す図である。一実施形態における、手またはオブジェクトの追跡および形状認識を行う視覚に基づくインタフェースの動作を示すフロー図である。一実施形態における、手またはオブジェクトの追跡および形状認識を行うためのフロー図である。一実施形態における、手の追跡および形状認識で用いられる８つの手の形状を示す図である。同じ手の形状の分類のためのユーザ間の差違を示すサンプル図である。、、（まとめて図６という）一実施形態における、追跡結果、追跡履歴と認識結果をともなう疑似カラー深度図を示す信頼値をともなうサンプルフレームを示す図である。一実施形態における、近隣のローセンサーの読み込みとの間の距離行列に基づいた深度の機能として最小深度の曖昧さを推定するプロットを示す図である。一実施形態における、１組のグリッドセル間の（ａ）４つの矩形を示すセットＢと（ｂ）平均深度の差を示すセットＣのために抽出された特徴を示す図である。一実施形態における、４つの特徴セットにわたるランダム決定フォレスト（ＲＦ）とサポートベクターマシン（ＳＶＭ）分類器の手の形状認識精度の比較のプロットである。一実施形態における、ランダム決定フォレストで異なる数の木を用いた手の形状認識精度の比較のプロットである。一実施形態における、キオスクシステムに実装された追跡および検出コンポーネントを用いた各フレームの処理時間結果（遅延）のヒストグラムである。一実施形態における、ＳＯＥのジェスチャボキャブラリにおけるポーズの図である。一実施形態における、ＳＯＥのジェスチャボキャブラリにおける姿勢の図である。一実施形態における、空間的マッピングアプリケーションで用いられるキオスクシステムにおけるＳＯＥの命令の例である。一実施形態における、メディアブラウザアプリケーションで用いられるキオスクシステムにおけるＳＯＥの命令の例である。一実施形態における、アップロード、ポインタ、回転を含むアプリケーションで用いられるキオスクシステムにおけるＳＯＥの命令の例である。ユーザが手を動かし雑音をさらに悪化させる、ズームのための手の変位の指数マッピングを示す図である。一実施形態における、代表的な適応フィルタ機能を用いた正の手の変位（ユーザの方に引く）のためのズーム因子（Ｚ）（Ｙ軸）対手の変位（Ｘ軸）のプロットを示す図である。一実施形態における、手のひらが地図ディスプレイ上の領域を対象にするための画面上のカーソルを動かすようにズームするための手の変位の指数マッピングを示す図である。一実施形態における、パン／ズームのジェスチャを開始するために手の握りしめに関連するズームするための手の変位の指数マッピングを示す図である。一実施形態における、地図のパンとズーム（同時に起こってもよい）の間のズームするための手の変位の指数マッピングを示す図である。一実施形態における、ユーザが快適な物理範囲の動作からより長距離に到達することを許可する地図ディスプレイ上の領域を対象にするための画面上のカーソルを手のひらが動かすようにズームレベルのための手の変位の指数マッピングを示す図である。一実施形態における、ユーザがジェスチャを開始するにあたりユーザが位置とズームを常に戻してよいことを保証する手の変位のダイレクトマッピングを示す図である。一実施形態における、第一範囲［０．．．１２００］（全範囲）のためのショーブフィルタレスポンスである。一実施形態における、第二範囲［０．．．２００］（ズーム）のためのショーブフィルタレスポンスである。一実施形態における、手の距離に関連する速度を表す第一プロットである。一実施形態における、手の距離に関連する速度を表す第二プロットである。一実施形態における、手の距離に関連する速度を表す第三プロットである。一実施形態における、ジェスチャ制御システムのブロック図である。一実施形態における、マーキングタグの図である。一実施形態における、ジェスチャボキャブラリにおけるポーズの図である。一実施形態における、ジェスチャボキャブラリにおける姿勢の図である。一実施形態における、ジェスチャボキャブラリにおける２つの手の組み合わせの図である。一実施形態における、ジェスチャボキャブラリにおける姿勢の融合の図である。一実施形態における、システム動作のフロー図である。、一実施形態における、コマンドの例を示す図である。一実施形態における、スロークス、プロテイン、およびプールを用いたデータ表現を含む処理環境のブロック図である。一実施形態における、プロテインのブロック図である。一実施形態における、デスクリップのブロック図である。一実施形態における、インジェストのブロック図である。一実施形態におけるスローのブロック図である。一実施形態における、プールの中にあるプロテインのブロック図である。、一実施形態における、スロー・ヘッダ・フォーマットを示す。一実施形態においてプロテインを用いる際のフロー図である。一実施形態において、プロテインを組み立てるまたは発生する際のフロー図である。一実施形態において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。一実施形態において、多数の装置と、これらの装置の１つ又は複数で走る多数のプログラムを含み、プラズマ構造（即ち、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、装置によって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。一代替実施形態において、多数の装置と、これらの装置の１つ又は複数で走る多数のプログラムを含み、プラズマ構造（即ち、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、装置によって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。別の代替実施形態において、多数の入力装置を含み、これらが当該装置の１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（即ち、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、入力装置によって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。更に別の代替実施形態において、多数の装置を含み、これらが当該装置の１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（即ち、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、装置によって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。更に別の代替実施形態において、多数の装置を含み、これらが当該装置の１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（即ち、プール、プロテイン、およびスロー）を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする処理環境のブロック図である。追加の代替実施形態において、多数の装置を含み、これらが当該装置の１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（即ち、プール、プロテイン、およびスロー）を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる処理環境のブロック図である。一実施形態における、メズファイルシステムのブロック図である。図４２〜図８５は、一実施形態における特徴によるメズプロテイン通信のフロー図であり、図４２は、一実施形態においてメズがクライアントとのハートビートを開始するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがメズとのハートビートを開始するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがセッションへの参加を要求するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがセッションへの参加を要求するための、メズ・プロセスのフロー図（最大）である。一実施形態において、メズがドシエを新規作成するための、メズ・プロセスのフロー図である。一実施形態において、クライアントが新規のドシエを要求するための、メズ・プロセスのフロー図である。一実施形態において、クライアントが新規のドシエを要求するための、メズ・プロセスのフロー図（エラー１）である。一実施形態において、クライアントが新規のドシエを要求するための、メズ・プロセスのフロー図（エラー２、３）である。一実施形態において、メズがドシエをオープンするための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエのオープンを要求するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエのオープンを要求するための、メズ・プロセスのフロー図（エラー１）である。一実施形態において、クライアントがドシエのオープンを要求するための、メズ・プロセスのフロー図（エラー２）である。一実施形態において、クライアントがドシエ名の変更を要求するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエ名の変更を要求するための、メズ・プロセスのフロー図（エラー１）である。一実施形態において、クライアントがドシエ名の変更を要求するための、メズ・プロセスのフロー図（エラー２）である。一実施形態において、メズがドシエを複製するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエを複製するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエを複製するための、メズ・プロセスのフロー図（エラー１）である。一実施形態において、クライアントがドシエを複製するための、メズ・プロセスのフロー図（エラー２、３）である。一実施形態において、メズがドシエを削除するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエを削除するための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエを削除するための、メズ・プロセスのフロー図（エラー）である。一実施形態において、メズがドシエをクローズするための、メズ・プロセスのフロー図である。一実施形態において、クライアントがドシエをクローズするための、メズ・プロセスのフロー図である。一実施形態における、新規スライドのための、メズ・プロセスのフロー図である。一実施形態において、スライドを削除するための、メズ・プロセスのフロー図である。一実施形態において、スライドを整列するための、メズ・プロセスのフロー図である。一実施形態における、新規ウィンドシールドアイテムのための、メズ・プロセスのフロー図である。一実施形態において、ウィンドシールドアイテムを削除するための、メズ・プロセスのフロー図である。一実施形態における、ウィンドシールドアイテムの変倍／移動／フルフェルドのための、メズ・プロセスのフロー図である。一実施形態における、スライドのスクロール／プッシュバックのための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントがデッキスクロールをするための、メズ・プロセスのフロー図である。一実施形態における、ｗｅｂクライアントのプッシュバックのための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントがラチェットのパスフォワードをするための、メズ・プロセスのフロー図である。一実施形態における、新規アセット（ピクセルグラブ）のための、メズ・プロセスのフロー図である。一実施形態において、クライアントがアセット／スライドをアップロードするための、メズ・プロセスのフロー図である。一実施形態において、クライアントがアセット／スライドを直接アップロードするための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントがアセット／スライドをアップロードするための、メズ・プロセスのフロー図（タイムアウト発生）である。一実施形態において、ｗｅｂクライアントがアセットをダウンロードするための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントが全アセットをダウンロードするための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントが全スライドをダウンロードするための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントがアセットを削除するための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントが全アセットを削除するための、メズ・プロセスのフロー図である。一実施形態において、ｗｅｂクライアントが全スライドを削除するための、メズ・プロセスのフロー図である。図８６〜図１１５は、一実施形態におけるメズプロテインに対するプロテイン仕様であり、図８６は、一実施形態におけるメズプロテイン仕様（参加）の一例である。一実施形態におけるメズプロテイン仕様（状態要求）の一例である。一実施形態におけるメズプロテイン仕様（ドシエ新規作成）の一例である。一実施形態におけるメズプロテイン仕様（ドシエオープン）の一例である。一実施形態におけるメズプロテイン仕様（ドシエ名変更）の一例である。一実施形態におけるメズプロテイン仕様（ドシエ削除）の一例である。一実施形態におけるメズプロテイン仕様（ドシエクローズ）の一例である。一実施形態におけるメズプロテイン仕様（画像アップロード）の一例である。一実施形態におけるメズプロテイン仕様（新規ドシエ）の一例である。一実施形態におけるメズプロテイン仕様（ドシエオープン済み）の一例である。一実施形態におけるメズプロテイン仕様（ドシエ名変更済み）の一例である。一実施形態におけるメズプロテイン仕様（ドシエ削除済み）の一例である。一実施形態におけるメズプロテイン仕様（ドシエクローズ済み）の一例である。一実施形態におけるメズプロテイン仕様（デッキ状態変化済み）の一例である。一実施形態におけるメズプロテイン仕様（新規アセット）の一例である。一実施形態におけるメズプロテイン仕様（プロテイン参加可能）の一例である。一実施形態におけるメズプロテイン仕様（プロテイン参加不可）の一例である。一実施形態におけるメズプロテイン仕様（全状態応答（ポータル））の一例である。一実施形態におけるメズプロテイン仕様（全状態応答（ドシエ））の一例である。一実施形態におけるメズプロテイン仕様（ドシエ新規作成（エラー））の一例である。一実施形態におけるメズプロテイン仕様（ドシエ新規作成（エラー））の他の例である。一実施形態におけるメズプロテイン仕様（ドシエオープン（エラー））の一例である。一実施形態におけるメズプロテイン仕様（ドシエ名変更（エラー））の一例である。一実施形態におけるメズプロテイン仕様（ドシエ削除（エラー））の一例である。一実施形態におけるメズプロテイン仕様（ドシエ削除（エラー））の他の例である。一実施形態におけるメズプロテイン仕様（画像準備完了（エラー））の一例である。一実施形態におけるメズプロテイン仕様（画像アップロード（成功））の一例である。一実施形態におけるメズプロテイン仕様（画像アップロード（エラー））の一例である。一実施形態におけるメズプロテイン仕様（画像アップロード（部分的成功））の一例である。一実施形態におけるメズプロテイン仕様（画像準備完了）の一例である。

＜＜詳細な説明＞＞
［ＳＯＥキオスク］
ここに記載されている実施形態は、手の形状の広範な集合を自動的に認識し、幅広い範囲のユーザにわたってジェスチャの追跡および認識における高い確度を維持するジェスチャインタフェースを提供する。実施形態は、センサから受信したデータを使用して、リアルタイムな手の検出と追跡とを提供する。ここに記載されている手の追跡と形状認識ジェスチャインタフェースは、空間的動作環境（ＳＯＥ：Spatial Operating Environment）キオスク（「キオスク」もしくは「ＳＯＥキオスク」とも呼ばれる）を可能とするか、又は、そのコンポーネント（構成要素）であり、そこでは、空間的動作環境（ＳＯＥ）とそのジェスチャインタフェースが、信頼性を有しマーカーレスの手追跡（トラッキング）システムにおいて動作する。このようなＳＯＥとマーカーレスのジェスチャ認識との組み合わせは、手の形状の追跡と分類に新規性を組み込む機能性、およびＳＯＥアプリケーションのデザイン、実行、および領域における発展を提供する。

ここに記載されている実施形態は、ディスプレイ装置、センサ、遠隔クライアント装置（「エッジ装置」とも呼ばれる）、およびコンピュータアプリケーションに結合されたプロセッサを備えるシステムもまた含む。コンピュータアプリケーションは、ディスプレイ装置と遠隔クライアント装置との少なくとも一つにわたって遠隔クライアント装置のコンテンツを同時に結集し、ディスプレイ装置の同時制御を許可する。同時制御は、センサを経由して受信したジェスチャデータからの少なくとも一つのオブジェクトオブジェクトの自動的なジェスチャ検出を含む。ジェスチャデータは、ある時点と空間における少なくとも一つのオブジェクトオブジェクトの瞬間状態の絶対的な３次元位置データである。検出はジェスチャデータの集約、およびジェスチャデータのみを使用するジェスチャの識別を備える。コンピュータアプリケーションは、ジェスチャをジェスチャ信号に変換し、ジェスチャ信号に応じて、ディスプレイ装置と遠隔クライアント装置との少なくとも一つを制御する。

ここで参照されている関連出願は、いくつかの実施形態ではマーカーレスのジェスチャ認識が提供され、他の実施形態では特定のしるしで一つ以上のグローブ状のユーザの手が識別される、ジェスチャベースの制御のためのシステム及び方法の説明を含む。ＳＯＥキオスクシステムは、一例として普通でない指の検出と遅延を提供する、グローブレスでしるしのないシステムにおいてジェスチャが追跡および検出される、マーカーレス設定を提供する。ＳＯＥは、少なくとも、ジェスチャの入出力、ネットワークベースのデータ表現、推移および入れ替え、並びに、空間的に同調されたディスプレイメッシュを含む。作用域内で、ＳＯＥは、それが完全なアプリケーションと開発プラットフォームであるようなオペレーティングシステムに類似する。しかしながら、これは、伝統的なコンピューティングシステムを逸脱して広がるデザインや機能を成立させる見方を想定している。強化された能力は、手のポーズ、ジェスチャ、および動きを追跡し、解釈するシステムにユーザが作用するジェスチャインタフェースを含む。

ここでの説明と、参照により全体が本明細書に組み込まれる関連出願とで詳細に記載されるように、ＳＯＥはそのようなインタフェースと作用を可能とする実世界のジオメトリ（配置）を成立させる。例えば、ＳＯＥは「実世界」の拡張の中でシステムの視覚、聴覚、触覚ディスプレイが存在するように、物理空間と仮想空間に沿う空間的に同調されたディスプレイメッシュを採用する。この機能の全域は、３次元ジオメトリの観点からＳＯＥによって実現される。２次元モニタ自体が大きさと姿勢をもっているように、ピクセルは、モニタ上の解像度に加え、世界において位置を有している。このスキームでは、実世界の座標が属性に注釈を付与する。この記述的な能力はすべてのＳＯＥ参加者を対象にする。例えば、ワンド（棒状ユニット）や携帯端末のような装置は、多数の実現されている入力要素の一つとなりうる。

このような空間の確実な概念が、ＳＯＥに浸透している。あらゆるレベルで、それはその座標表記へのアクセスを提供する。オブジェクトオブジェクト（それが物理であろうと仮想であろうと）の位置がジオメトリの観点から表現できるように、従ってオブジェクトオブジェクト（それが物理であろうと仮想であろうと）間の空間的関係はジオメトリの観点から表されうる。（また、任意の種類の入力装置はこの関係のコンポーネントとして含まれうる。）ユーザが画面上のオブジェクトオブジェクトを指した場合、関連出願とここでの説明で述べられているように、ＳＯＥは交差計算を解釈する。画面のオブジェクトオブジェクトは、ユーザの動作に応じて反応する。ユーザがこの因果関係に気づいて、応答するとき、コンピュータ作用の古いやり方は取って代わられる。ユーザはＳＯＥの中で、グラフィックがユーザと同じ部屋にいると理解しているように振る舞う。この結果が直接空間的操作である。このようなダイナミックなインタフェースでは、入力は古い方法の制約を超えて拡大する。ＳＯＥは３次元空間の全体積を広げ、多様な入力要素を受け入れる。

この再設計された、より豊かなコンピューティング空間に、ＳＯＥは組み換えネットワーク化や、相互運用への新たなアプローチをもたらす。本明細書における関連出願および説明は、ＳＯＥが大規模なマルチプロセスの相互運用を支持するプログラミング環境であることを記載する。ＳＯＥは、いくつか例を挙げると、多数のプロセス間におけるデータの少なくとも効率的な交換、データの非常にさまざまな種類および用途がサポートされるような、柔軟なデータ「タイピング」および構造、データ交換のための柔軟な機構（例えば、ローカルメモリ、ディスク、ネットワークなど）、実質的に同様のＡＰＩによってすべてが駆動されること、異なるプログラミング言語で書かれたプロセス間におけるデータ交換、及び、データキャッシングの自動保守や状態の集約を行うアーキテクチャである、「プラズマ」を備える。技術スタックまたはオペレーティングシステムにかかわらず、ＳＯＥは従来（レガシー）の表現を含む外部データおよび動作を活用する。これは、ｉＰｈｏｎｅのような携帯電話端末を含むがこれに限定されない装置からの、比較的低レベル品質の空間的データを統合することを含む。そのような装置はまた「エッジ」端末とも呼ばれる。

上記のように、ここに記載されているＳＯＥキオスクは、自己完結型マーカーレス設定においてＳＯＥの堅固なやり方を提供する。ユーザはグローブ、マーカー、またはそのようなあらゆるしるしを用いずに「フリー」の代理人としてＳＯＥに従事し、また、ＳＯＥは、画面、カメラ、またはエミッタの導入のような空間修正も必要としない。唯一必要なのは、手の形状および他の入力要素を検出し、追跡し、応答するシステムへの近接である。ここに詳細に記載されているように、マーカーレスの追跡システムと組み合わされる代表的なセンサを備えるこのシステムは、あらかじめ決められた範囲（例えば、１から３メートル、など）内でポーズ認識を提供する。ＳＯＥキオスクシステムはそれゆえ可搬性と導入との柔軟性を提供するが、実施形態はこれに限定されない。

図１Ａは一実施形態における、手の追跡および形状認識を使用する視覚ベースのインタフェースを提供する、ジェスチャインタフェースのコンポーネントまたはアプリケーションを担うプロセッサ、ディスプレイ、およびセンサ含む、ＳＯＥキオスクのブロック図である。図１Ｂは一実施形態における、ＳＯＥキオスクと操作者との間の関係を示す。一般用語の「キオスク」は、ここに記載されているマーカーレスな追跡および認識プロセスを使用する様々な組立または構成を包含する。これらの異なる導入は、例えば、センサおよび少なくとも一つのディスプレイに結合されたプロセッサと、視覚パイプラインを統合するＳＯＥを提供するためのプロセッサ上で稼働する、追跡および認識のコンポーネントまたはアプリケーションとを含む。一実施形態のＳＯＥキオスクはルータのような結合または接続される装置によって提供される、もしくはワイヤレスのようなアクセスを通して従事される、ネットワーク能力を含む。

一実施形態のキオスクはまた「メザニン（Ｍｅｚｚａｎｉｎｅ）」また「メズ（Ｍｅｚｚ）」とも呼ばれる。メザニンは複数の画面、複数のユーザ、および複数の装置を備える作業空間である。図１Ｃは一実施形態における、メザニンの導入を示す。図１Ｄは一実施形態における、メザニンの論理図の一例を示す。図１Ｅは一実施形態における、メザニンのラック図の一例を示す。

メザニンはジェスチャの入出力、空間的に同調されたディスプレイメッシュ、および組み換えネットワーク化を含むが、これに限定されない。空間的動作環境（ＳＯＥ）のコンポーネントとして、メザニンは途切れのない堅固な協調を可能とする。デザイン、実行、および特徴にて、それは「テレプレゼンス」、「テレビ会議」、「ホワイトボーディング」、「協調」、および関連分野に限らない伝統的な技術に不足しているものに取り組む。メザニンの能力は、複数ディスプレイ設定のリアルタイムな結集、ディスプレイ環境の同時制御、ラップトップの映像およびアプリケーション共有、グループのホワイトボーディング、映像の遠隔ストリーミング、および複数のメザニン導入と追加のメディアソースの遠隔ネットワーク接続を含むが、これに限定されない。

メザニンは、ジェスチャの入出力、空間的に同調されたディスプレイメッシュ、および組み換えネットワーク化（これらに限定されない）を含む。

図１Ｃ−図１Ｅに関して、協調技術であるメズのシステムおよび方法は、複数の画面、複数のユーザ、および複数の装置にわたる作業空間を備える。これは、任意の会議室の（一つ以上の）高解像度ディスプレイを共有作業空間の中に転用し、そのようにして複数ディスプレイ設定のリアルタイム結集を許可し、ディスプレイ環境の同時制御、ラップトップの映像およびアプリケーションの共有、およびグループのホワイトボーディングを有効にする。複数のユーザは様々な装置上で、部屋の共有画面上に画像および映像アセットを提示し、操作することができる。ユーザは、マルチモード入力装置（ＭＭＩＤ）（関連出願を参照）、ブラウザベースのクライアント、および参加者自身のｉＯＳおよびＡｎｄｒｏｉｄ装置を通じて、システムを制御する。ラップトップがメズに結合または接続されると、それらデスクトップのピクセルはディスプレイのトリプティク（三連画面）上に現れ、移動、縮尺変更、ないしセッションのワークフローの中に統合されうる。そして参加者は、任意の接続されたラップトップ上で実行中のアプリケーションと直接作用するために、協調画面を「リーチスルー」することができる。一実施形態はまた複数メズシステム間の協調をサポートする。

本明細書に詳細に記載されているように、メズが空間的動作環境（ＳＯＥ）の上に設けられるとき、メズは、ジェスチャの入出力、空間的に同調されたメッシュ、および組み換えネットワーク化（これらに限定されない）を含む。デザイン、実行、および特徴にて、それは、「テレプレゼンス」、「テレビ会議」、「ホワイトボーディング」、「協調」、および関連分野、ないしこれらに限定されない、伝統的な技術における欠陥に取り組む。

一般的に、ユーザはエレクトロニックアセット（例えば画像、映像、など）をメズにアップロードする。これらのアセットは、ファイルと似ていないとはいえない、ドシエにまとめられる。ドシエはメズにワーキングセッションを備え、画像アセット、映像アセット、およびデッキも含みうる。デッキは、スライドの順序づけられたコレクションであるが、ここではスライドがアセットである。ポータルはドシエのコレクションである。アセット、スライド、およびドシエを含むこれらのアプリケーション要素を操作するために、ユーザは、作成、開く、削除、移動、スケーリング、整列、名前の変更、複製、ダウンロード、およびクリアといったアクションに関与する。メズは、アセットの表示および操作のための特定の種類のコンテナであるコンポーネントを含み、それはアセット用のホワイトボードやコルクボードも含む。ユーザはポータルもしくはドシエのどちらかにいる。メズ制御は、２〜３例を挙げると、マルチモード入力装置（ＭＭＩＤ）、ウェブベースのクライアント、ｉＯＳクライアント、および／またはＡｎｄｒｏｉｄクライントを通じて、利用可能である。一実施形態のメズの機能性は、トリプティク、ポータル、ドシエ、パラマス、ホーボーケ、デッキ、スライド、コルクボード、ホワイトボード、ワンド制御、ｉＯＳクライアント、およびウェブクライアントを含むがこれらに限らず、また、機能は、アセットのアップローディング、デッキを備えるスライドの挿入、整列、および削除、あるいは、ホワイトボード入力のキャプチャ、およびリーチスルーを含むがこれらに限定されない。

メズは、関連出願に記載されている「ｇ−ｓｐｅａｋ」と呼ばれるプラットフォームの上に設けられる。関連出願でいくつか文書化されている、その中心となる機能的コンポーネントは、複数装置および空間的入出力、プラズマネットワーキングおよびマルチアプリケーションサポート、そして実世界空間的登録で複数の画面にわたりピクセルをレンダリングするジオメトリエンジンを含む。より具体的には、メザニンは、リアルタイムで互いに通信し、作用する、プロセスと装置のエコシステムである。これらの分離したモジュールは、本明細書に記載されている、プラズマを使用して互いに通信する。本明細書及び関連出願に詳細に記載されるように、プラズマは、時間ベースの内部プロセス、プロセス間、又はマシン間のデータ転送のためのフレームワークである。

アーキテクチャのレベルで、メズは、入力装置及び他の装置からの入力を扱うとともにシステム全体の状態を維持するトリプティクへの要素のレンダリングを担当する、ヨボ（yovo）アプリケーションを参照する。ヨボアプリケーションは、クライアントと呼ばれる他の装置から受信した画像を転送する、アセットマネージャと呼ばれる別のヨボプロセスによって支援される。クライアントは、メズに結合又は接続する非ヨボ、非メズ装置として広く定義される。クライアントは、ｉＯＳ又はＡｎｄｒｏｉｄプラットフォームをサポートする、メズウェブアプリケーション及び携帯装置を含む。

メズの一実施形態は、トラッキングシステム、一実施形態で「トリプティク」と呼ばれるメインディスプレイ画面、多数の映像又はコンピュータソース、ネットワークポート、マルチモード入力装置、デジタルコルクボード、ホワイトボードを含むがこれらに限定されないコンポーネントに結合または接続されるハードウェア装置を備える。トラッキングシステムは空間的データ入力を提供する。一実施形態において、トラッキングシステムは、インターセンスＩＳ−９００トラッキングシステムであるが、これに限定されない。別の実施形態は、内部ＰＣＩのＩＳ−９００のバージョンを使用するが、これに限定されない。

ハードウェア装置の出力ポート（例えば、ＤＶＩ、など）は、メインディスプレイ画面／トリプティクとして一つ以上のディスプレイ（例えば、２つ、４つ、など）に結合または接続する。一実施形態例においては、３つの５５’’ディスプレイが互いに隣接して設置されるが、これは一つの「トリプティク」を備えている。
他の実施形態は、例えば、それぞれ１９２０×１２８０の解像度まで、ディスプレイの縦横タイルをサポートする。

入力ポート（例えば、ＤＶＩ、など）は多数の映像／コンピュータソース（例えば、２つ、４つ、など）に結合または接続する。一実施形態において、１ギガビットのイーサネットネットワークポートは、遠隔ストリーミング映像のソースへの結合または接続と、接続されたコンピュータ上で稼働しているアプリケーションとの作用とを許可するために提供される。多数の空間的なワンドまたは入力装置もまたサポートされる。

メズは異なるフェルド構成によって特徴付けられる。ここで使われる「フェルド」という言葉は、画面の考えを一般化するために使われる、通常は平面ディスプレイ空間の抽象的なアイデアを指す。広い意味で、それは、図形の構図及び空間的構図が取り付けられうる、興味のある分画された領域である。ビジフェルドはレンダリングバージョンである。

例えば、ユーザはより小さい部屋でメザニンを使うことを希望してもよい。すべての大会議室について、任意のサイズの組織は、物理的には完全なトリプティク設置に適合しなくてもよい、多くの部屋及びオフィスをもつ同じエンティティがある。シングルフェルドメザニンはユーザにより多くの選択肢を与える。その上、それは、ディスプレイ及び通信インフラの異なる種類で投資しなければならないことから組織を救う。それはまた、その技術すべてが途切れなく協調しうることを確かにする。例えば、オフィスにシングルフェルドのメザニンをもつ重役が、より大きな会議室の完全なトリプティクメザインを用いて、協調に参加することができる。混合ジオメトリの協調のためのサポートは、これらユーザのニーズに不可欠である。

二つ目の例は価格の柔軟性に関係する。シングルフェルドのメズは、メザニン及びそれが提供する特徴に興味を持ってよい、より小さい組織に選択肢を提供する。

三つ目の例は大きなピクセルのディスプレイに関与する。いくつかの会社はすでに、ピクセルで壁いっぱいに表示するようにデザインされた特別注文のディスプレイ技術である、「大きなピクセルのディスプレイ」の導入に多額の投資をしてきた。これらの構成には多様なアスペクト比と同様に、多種多様な解像度があってよい。これらの会社はしばしば多くのソースから可視化する多くのデータを持つが、見せるためのソースの構成は扱いにくく、柔軟性がない。彼らの投資を最大限に利用することに加え、メズは、追加の柔軟性を加え、ＩＴ経費を削減し、協調の可能性をもたらす。

メズのサポートはトリプティク、ユニプティク、及びポリプティクのジオメトリを含む。トリプティクは標準のメザニン構成であり、記載のように、その特質には、三つのディスプレイ、同一平面上、１６：９のアスペクト比、４８：９の混合アスペクト比、５５’’ディスプレイのみ、及び同サイズのベゼルとムリオンが含まれる。

「ユニプティク」は、ジオメトリ定義の「イプティク」ファミリーとの関連付けをとどめる、シングルフェルドディスプレイのための用語である。それに応じて、明細書は、数に関わらず、作業空間フェルドの境界を超えて存在する空間の領域に言及するために「オフプティク」を用いてもよい。それはディスプレイの大きさの範囲が４５’’から６５’’、及び１６：９のアスペクト比である単一のディスプレイを備えるが、もっとも、他の実施形態ではアスペクト比は変わりうる。「ポリプティク」は、ジオメトリ定義の「イプティク」ファミリーとの関連付けをとどめる、マルチフェルドディスプレイのための用語である。

メズは、ネイティブで稼働するアプリケーションを提供する。一実施形態は下記のような多数のアプリケーションを含む。ウェブサーバアプリケーションはＣＭＣを制御、構成するウェブブラウザを通じて、ユーザがメズに接続することを可能とする。作用例は、出力映像ポート上の解像度の設定、ネットワーク設定の構成、ソフトウェアアップデートの制御、及びファイル転送の許可を含む。それは「ウェブクライアント」と呼ばれうる。ｉＯＳ及びＡｎｄｒｏｉｄアプリケーションは、ｉＯＳまたはＡｎｄｒｏｉｄプラットフォームの携帯装置を通じて、ユーザがメズに接続してシステムを制御することを可能とする。キャリブレーション（較正）アプリケーションは、ユーザが新たに、またはすでに設置されたシステムを較正することを許可し、またユーザがシステムの較正を検証することを許可するアプリケーションである。

メズはまた、ジェスチャ又はワンドの制御を使用する、表示されたウィンドウ、アプリケーション、及び、ウィジットとともに、ユーザがリアルタイムに相互作用することを可能とするＳＯＥウィンドウズアプリケーションマネージャを含む。ユーザは、ウィンドウを選択、移動、スケーリングしたり、または、個別のアプリケーションに直接相互作用してもよい。このアプリケーションは、レイアウトを保存、及び復元しうる、記録能力を含む。

映像パススルーアプリケーションは、ローカルで接続された生中継映像ソースのウィンドウマネージャにおいてウィンドウを作成する。これらの供給が接続されたコンピュータからのものである場合、アプリケーションは、接続された小さな画面上の入力を制御するワンド／大きな画面からのイベントのパススルー制御を可能とする。それは「パススルー」と呼ばれる。

ホワイトボードアプリケーションは、ホワイトボードの機能性をウィンドウマネージャに統合する。これは、ウェブブラウザを通じて、接続されたコンピュータからのプレゼンテーション画面及びウィンドウのウェブ制御を含む。「パス・フォワード」又は「パスフォワード」として知られているプロキシアプリケーションは、ラップトップまたはデスクトップ上に容易に設置され、装置がＤＶＩ及びイーサネットを通じてメズに結合または接続されると、装置上で稼働しているアプリケーションが、プロキシウィジットを通じてメズコマンドウォール上で制御されることを可能とする。

メズ環境は、ここで詳細に記載されているように、様々な装置にわたるマルチユーザの協調を可能とする。一実施形態例において、トリプティクはメズの心臓部であり、この例では、メズのユーザ体験の中心における接続された三つの画面を備え、ユーザがグラフィック及び映像アセットを表示したり、操作することを許可する。メズ画面はトリプティク内におけるそれらの位置（例えば、左、中央、右）によって指定される。

トリプティクは二つのモード：フルスクリーン及びプッシュバックモードで利用することができる。フルスクリーンモードはまた、「プレゼンテーション」モードとして、プッシュバックモードは「編集」モードとして考えることができる。これらの名前はそれらの機能を厳密に定義しないが、利用されるかもしれない方法について、一般的な指針として振る舞う。メズのワンド（棒状ユニット）は、メズ環境においてオブジェクトを操作するのと同様にモード間を切り替えるために利用することができる。メズの主要な制御装置は、ワンドであるが、それはまた２〜３例を挙げると、ウェブブラウザクライアント及びｉＯＳ装置を経由しても制御されうる。さらに、これら装置の任意の組み合わせが、同時に利用されてもよい。ドシエの命名のようないくつかの機能は、ウェブブラウザクライアント又は接続されたｉＯＳ装置を使用して実行される。

一実施形態のメズは、コルクボード及びホワイトボードを備える。コルクボードは、メズのトリプティクを超えた追加の画面であり、追加のアセットを眺めるのに利用することができる。ホワイトボードは、ホワイトボードエリア上にワンドを向け、ワンドボタンを押すことで、メズによってデジタル処理で保存することができるエリアである。保存された画像アセットは、アセットビンの中に即座に現れる。

ワンドは一実施形態においてメズ環境を制御する主要な手段である。メズは、三次元（３Ｄ）空間においてワンドの位置及び姿勢を極めて正確に追跡し、オブジェクトの精密な制御及びメズ環境内のモード選択を許可する。メズは複数のワンドを同時に追跡する。それぞれのワンドは、メズに制御されたディスプレイに照準を定めたとき、ポインタを投影する。メズ環境に現れるそれぞれのポインタは、それに関連付けられる色分けされた点をもち、それはメズセッションの参加者に、誰が特定のタスクを果たしているのかを知ることを許可する。多くの革新的なジェスチャにつながれて、ワンドは、すべてのメズ機能を実行するために使用される単一のボタンをもつ。

図１Ｆは一実施形態における、メズのドシエポータルのブロック図である。運用において、メズと連動し始めるためにドシエを開く。ドシエポータルは、メズ環境内で開かれうる、すべての利用できるドシエのリストを示す。ドシエの選択（例えば、クリックすること）によりドシエは開き、セレクターのクリック及び保持により重複及び削除の機能性が明らかになる。メズはドシエポータル又はドシエそれ自身の中のどちらか一方にある。それぞれのドシエは、編集された最終時間からのタイムスタンプを示す。ドシエからのサムネイルは名前の左に現れる。右画面は、新規の、空のメズドシエを作成するためにクリックする、「新規ドシエ作成」ボタンを示す。新規の、空のドシエを開くためにクリックする。一実施形態のドシエ命名は、ウェブクライアントまたは接続されたｉＯＳ装置を使用して行われるが、これに限定されない。右画面は、サポートされたウェブブラウザでメズセッションに接続するために使用されるウェブアドレスを示す。

図１Ｇは一実施形態における、メズのトリプティク（フルスクリーン）のブロック図である。フルスクリーンモードはよく、プレゼンテーションをするために使用される。フルスクリーンモードはメズ環境の「ズームイン」ビューである。フルスクリーンモード及びプッシュバックモードの間で切り替えるためにプッシュバックジェスチャを使用する。ワンドを右の画面外に指し、ボタンをクリックすることで、デッキを前進させる。ワンドを左の画面外に指し、ボタンをクリックすることで、デッキを後退させる。スライドデッキの中のスライドは、それらを左または右にドラッグすることで並べ替えることができる。一度スライドが別のスライドの位置にほとんど覆うようにドラッグされると、場所を失ったスライドは移動されたスライドの元の位置にスナップする。

図１Ｈは一実施形態における、メズのトリプティク（プッシュバック）のブロック図である。プッシュバックモードはメズアセットを操作し、編集するのに便利である。プッシュバックモードはメズ環境の「ズームアウト」ビューである。このビューはユーザが、アセット及びライブビンと同様に、デッキの中の、より多くのスライドを見ることを許可する。アセットがドシエに追加されるにつれ、それらは初めに中央のアセットビンを、そして右のアセットビンを、そして左のアセットビンをいっぱいに満たす。アセットビンの中の画像は、ワンドを使用して、デッキ内、又はウィンドシールド上にドラッグすることができる。デッキは画面外の右または左をクリックすることで、前進または後退できる。ワンドでアセットサムネイルまたは映像サムネイルのどちらか一方に対してシングルクリックを行うと、オブジェクトをウィンドシールド上に配置する。映像ソースが接続されると、映像サムネイルがライブビンに現れる。ドシエの名前及び「クローズドシエ」ボタンのあるバナーは、ポインタが右画面の下部から照準をはずされると、プッシュバックモードに現れる。「クローズドシエ」ボタンをクリックすることで、すべてのユーザ及び装置との接続を断ち、メズをドシエポータルに戻す。

図１Ｉは一実施形態における、メズのアセットビン及びライブビンのブロック図である。アセットビンは現在のドシエ内に読み込まれた画像オブジェクトを表示する。映像ビンはＤＶＩ接続された映像ソースを含む。ビンオブジェクトはデッキ内にドラッグされ、又は、ウィンドシールド上に配置されうる。アセット及びライブビンはプッシュバックモードでは可視化される。ライブビンのサムネイルは、定期的にアップデートする。デッキ内にオブジェクトを配置するために、オブジェクトをその所望の位置にドラッグし、ボタンを解放する。ウィンドシールド上にオブジェクトを配置するために、オブジェクトをデッキの外のエリアにドラッグし、ボタンを解放する。または、それをクリックすることで、オブジェクトを最大化する。スライドは、ビンからドラッグされたオブジェクトのためのスペースをあけるために、その場所から移動される。

図１Ｊは一実施形態における、メズのウィンドシールドのブロック図である。ウィンドシールドは「常に上部にある」作業エリアである。メズがフルスクリーンモードであろうと、プッシュバックモードであろうと、ウィンドシールド上のオブジェクトは他の全ての上に合成される。フルスクリーンのオブジェクトは、デッキのオブジェクトのためのフレーム又はカバーとしての役割を果たすために使用されうる。例えば、操作者が、同時に単一のスライドのみが現れることを望むような場合である。オブジェクトをウィンドシールド上に配置することは、オブジェクトをアセットビン又はライブビンからその所望の位置へドラッグすることを伴う。ライブビンからのソースもまたウィンドシールド上に配置されうる。これらのオブジェクトがフォーカスをもつとき、「ローカルＤＶＩ入力」のヘッダーとともに現れる。オブジェクトをウィンドシールド上に移動させるために、それをドラッグする。フルスクリーンにされたウィンドシールドのオブジェクトは、それらが移動されたとき、画面のエッジにブラケットの表示をもたらす。

図１Ｋは一実施形態における、メズのプッシュバック制御を示すブロック図である。メズの視点を変更するために、プッシュバックジェスチャを使用する。プッシュバックは、メズ全体の作業空間の視点を滑らかにスケーリングし、これにより操作者がモード間を容易に移動することを許可する。プッシュバックに従事するために、ワンドを天井に向けて指し、ボタンを保持し、そして画面に向かって押し、画面から引き離す。メズの作業空間は、このジェスチャを使用して押したり引いたりして、滑らかにズームイン、アウトする。ボタンを解放することで、今のズームレベルに依存しているフルスクリーンモード又はプッシュバックモードのどちらか一方をスナップする。視界が押しのけられると、メズはプッシュバックモードにスナップする。視界がズームインされると、メズはフルスクリーンモードにスナップする。ワンドを左または右に（画面と平行に）動かすと、動きと同じ方向にデッキ内でスライドが動く。オブジェクトは常に同じサイズのままであるように、ウィンドシールド上のオブジェクトはプッシュバックに影響を受けない。

図１Ｌは一実施形態における、メズの入力モード制御を示す図である。メズで入力モードを変更するために、ラチェットジェスチャを使用する。移動・スケーリング、スナップショット、そしてリーチスルーの３つのワンドの入力モードがメズで利用可能である。時計回りまたは反時計回りに回転させてワンドをラチェットすることによりモード間が切り変わり、これによりどちらのモードがアクティブであるか指し示すポインタが変化する。任意のモードから、所望のモードをアクティブにするために、上図に示されている方向にラチェットする。同じ方向への連続的なラチェットにより、最終的に操作者は彼／彼女が開始したモードに戻されるように、モード選択は循環（ラップアラウンド）する。どんなときでも、操作者は移動・スケーリングモードに戻るためにワンドを天井に向けてよい。

図１Ｍは一実施形態における、メズのオブジェクトの移動制御を示す図である。メズでオブジェクトを動かすには、それをドラッグする。操作者は動かしたいと思うウィンドシールド上のオブジェクトにワンドを向け、ワンドのボタンをクリックし、オブジェクトを新たな位置へドラッグし、ボタンを解放する。オブジェクトが動かされるにつれ、アンカーがオブジェクトの最初の位置の中央に現れる。波線はアンカーをオブジェクトの新たな位置に接続する。ワンドを用いて、操作者はオブジェクトを動かし、同時にそれをスケーリングすることができる。フルスクリーンのオブジェクトをある画面から他へ移動させるとき、ボタンを解放すると、オブジェクトが画面をいっぱいに満たすようにスナップするであろうことを示すために、ブラケットが画面のエッジに現れる。スライドデッキにあるオブジェクトは同じ方法を使用して移動される―オブジェクトをその所望の位置にドラッグし、ボタンを解放する。

図１Ｎは一実施形態における、メズのオブジェクトスケーリングを示す図である。メズでオブジェクトをスケーリングするために、スケーリングジェスチャを使用し、ワンドをオブジェクトに向け、ワンドのボタンを押下し、そしてオブジェクトを大きくするためにワンドを画面から引き離し、オブジェクトを小さくするためにワンドを画面に向けて押す。オブジェクトが所望のサイズのとき、ボタンを解放する。オブジェクトで画面をいっぱいに満たす（フルスクリーン化する）ために、ブラケットが画面の端に現れるまでそれを大きくし、そしてボタンを解放する。フルスクリーンのオブジェクトは画面の中央にスナップする。図１Ｏは一実施形態における、ボタン解放でのメズのオブジェクトスケーリングを示す図である。ブラケットは、そのスケールレベルでボタン解放がそのオブジェクトをフルスクリーン化することを示すために画面のエッジに現れる。

図１Ｐは一実施形態における、接続より前のメズのリーチスルーを示すブロック図である。図１Ｑは一実施形態における、接続後のメズのリーチスルーを示すブロック図である。メズのリーチスルー能力を使用するために、操作者は接続されたコンピュータ上でリーチスルーアプリケーションを稼働させる。コンピュータＤＶＩ出力はメズのＤＶＩ入力の一つに接続される。ＤＶＩ出力がメズに接続されると、デスクトップのサムネイルがメズのライブビンの対応する入力に現れる。リーチスルーは対応するアプリケーションが稼働するまで、非アクティブなままである。ＭｚＲｅａｃｈアイコンをダブルクリックすることで、リーチスルーを稼働する。メズがリーチスルーすることを許可するために、操作者が参加することを望んでいるメズサーバのＩＰアドレスまたはホスト名をタイプするか、または最近使用されたメズサーバを選択するためにドロップダウンメニューを使用する。次に、Ｃｏｎｎｅｃｔボタンをクリックする。操作者は終了するとき、Ｄｉｓｃｏｎｎｅｃｔボタンをクリックする。メズのＩＰアドレスまたはホスト名は通常、ドシエポータルに表示される。さらなる情報については、システム管理者に会う。物理的な（ＤＶＩ）接続及びネットワーク接続の両方ともリーチスルー機能をサポートするが、どちらか一方の接続が独立に存在してよい。

図１Ｒは一実施形態における、リーチスルーポインタを用いたメズのリーチスルーを示す図である。操作者は、リーチスルーポインタを用いてＤＶＩ接続された映像ソースを制御する。ラチェットジェスチャを用いてリーチスルーポインタをアクティブにする。リーチスルーポインタを使用して、マウスで行われるであろう、クリック、ドラッグ、選択などを行う。リーチスルーを使用する間に提供されるフィードバックは、ソースを直接制御した場合に提供されるであろうものと正確に同一であるべきである。ＤＶＩ接続された機械は、リーチスルーをサポートして、リーチスルーアプリケーションを稼働している。

図１Ｓは一実施形態における、メズのスナップショット制御を示す図である。ラチェットジェスチャを用いて、スナップショットポインタをアクティブにし、そして保存したい作業空間のエリア越しにドラッグする。エリアが覆われたら、ワンドのボタンを解放する。所望のエリア越しにドラッグすると、保存される予定のエリアを示す、マーキーで強調されたエリアが現れる。すべての目に見えるオブジェクト（ウィンドシールド上のオブジェクトを含む）は保存され、スナップショットがアセットビンの最後に現れる。取り消すためには、ワンドのボタンを解放する前に、ポインタを元の地点を超えてドラッグして戻し、そしてワンドを解放する。

図１Ｔは一実施形態における、メズの削除制御を示す図である。移動・スケーリングの入力モードに入ることで操作者は、任意のオブジェクトを削除するために、それを天井にドラッグし、ワンドのボタンを解放する。そしてオブジェクトは、ドシエから取り除かれる。スライド、ウィンドシールドのオブジェクト、または画像アセットの削除は、すべて同じ方法で行われる。フルスクリーンまたはプッシュバックモードにおける任意の目に見えるオブジェクトは削除することができる。操作者がオブジェクトを削除しているときにメズが提供するフィードバックは、天井に向けて画面外にドラッグしたときは、削除バナー及び赤いアンカーでオブジェクトを置き換える。スライドがデッキから削除されると、削除バナーはスライドの元の位置の上に重ねられる。

図２は一実施形態における、手またはオブジェクトの追跡及び形状認識（２０）を行う、ジェスチャまたは視覚ベースのインタフェースの動作のフロー図である。視覚ベースのインタフェースは、センサからデータを受信し（２１）、そのデータはセンサによって検出されたオブジェクトに対応する。インタフェースは、データの各フレームから画像を生成し（２２）、その画像は多数の解像度を示す。インタフェースは画像の中にブロブ（しみ）を検出し、ブロブをオブジェクトの軌跡に関連付けることで、オブジェクトを追跡する（２３）。ブロブとは、当該ブロブの中のすべての点が、ある意味で互いに似ていると考えられうるような、いくつかの特性（例えば、明るさ、色、深さ、など）が、一定であるか、または規定された値の範囲内で変化する、デジタル画像の領域である。インタフェースは、各ブロブを、多数のオブジェクト形状の一つに対応するものとして分類することによって、オブジェクトのポーズを検出する（２４）。インタフェースは、ポーズおよび軌跡に応じて、ジェスチャインタフェースを制御する（２５）。

図３は、一実施形態における、手またはオブジェクト追跡および形状認識（３０）を行うためのフロー図である。オブジェクト追跡および形状認識は、例えば視覚ベースのジェスチャインタフェースに用いられるがこれに限定されない。追跡および認識は、ボディの付属器官のセンサデータを受信する工程（３１）を備える。追跡および認識は、センサデータから第一の解像度を有する第一の画像を生成する工程（３２）を備える。追跡および認識は、第一の画像のブロブを検出する工程（３３）を備える。追跡および認識は、付属器官の追跡とブロブとを関連付ける工程（３４）を備える。追跡および認識は、センサデータから、第二の解像度を有する第二の画像を生成する工程（３５）を備える。追跡および認識は、ブロブのそれぞれを多数の手の形状の一つとして分類するために第二の画像を使用する工程（３６）を備える。

ＳＯＥキオスクのハードウェア構成の実施形態例は、以下であるが、実施形態はこれらの構成例に限定されない。一実施形態例のＳＯＥキオスクは、ＡｓｕｓＸｔｉｏｎＰｒｏを用いるＡｐｐｌｅｉＭａｃの２７“バージョンを備えるｉＭａｃベースのキオスクであり、センサはｉＭａｃの上部に取り付けられる。Ｔｅｎｂａケースは、ｉＭａｃと、センサと、そしてキーボード、マウス、電源ケーブルおよびパワースプリッタを含むアクセサリとを含む。

別の実施形態例のＳＯＥキオスクは、比較的小さなフォームファクタのパーソナルコンピュータ（ＰＣ）を用いる、３０“画面を備える携帯用ミニキオスクである。画面とスタンドがプロセッサから分離し、このセットアップはディスプレイの横方向と縦方向の両方をサポートする。

さらなる実施形態例のＳＯＥキオスクは、ＤＶＩまたはＨＤＭＩ入力を受け付ける、５０“１９２０×１０８０テレビまたはモニタであるディスプレイと、センサ（例えばＡｓｕｓＸｔｉｏｎＰｒｏＬｉｖｅ、ＡｓｕｓＸｔｉｏｎＰｒｏ、ＭｉｃｒｏｓｏｆｔＫｉｎｅｃｔ、ＭｉｃｒｏｓｏｆｔＫｉｎｅｃｔｆｏｒＷｉｎｄｏｗｓ、ＰａｎａｓｏｎｉｃＤ−Ｉｍａｇｅｒ、ＳｏｆｔＫｉｎｅｔｉｃＤＳ３１１、ＴｙｚｘＧ３Ｅｖｓ、など）と、クアッドコアＣＰＵとＮＶＩＤＩＡＮＶＳ４２０ＧＰＵが稼働する比較的小さなフォームファクタのＰＣを含むコンピュータまたはプロセスとを備える。

上記のように、ＳＯＥキオスクの実施形態は、センサとしてＭｉｃｒｏｓｏｆｔＫｉｎｅｃｔ（キネクト）センサを含むが、実施形態はこれに限定されない。一実施形態のキネクトセンサは、カメラ、赤外線（ＩＲ）エミッタ、マイク、および加速度計を一般的に含む。より具体的には、キネクトは、１２８０×９６０解像度で３チャネルデータを保存するカラーＶＧＡカメラまたはＲＧＢカメラを含む。また、ＩＲエミッタおよびＩＲ深度センサも含まれる。エミッタは赤外光の光線を放射し、深度センサはセンサへ反射されたＩＲ光線を読み取る。反射された光線は、オブジェクトとセンサの間の距離を測定する深度情報へと変換され、深度画像の保存を可能にする。

キネクトは、音の保存のための４つのマイクを包含する複数アレーのマイクもまた含む。４つのマイクがあるため、音の記録と同様に音源の位置および音波の方向の発見が可能となる。さらに、Ｇが重力に起因する加速度を表すとして、センサには、２Ｇの範囲で構成された３軸加速度計が含まれる。加速度計は、キネクトの現在の姿勢を判定するために使用されうる。

低コスト深度カメラは、堅固で遍在する視覚ベースのインタフェースのための新たな機会を創造する。数多くの研究が、体全体のポーズ推定および全体的な体の動きの解釈に重点的に取り組んできた一方、この研究は骨格を用いない手の検出、追跡そして形状の分類を評価する。ここで記載される実施形態は、手の形状の広範なセットを認識し、広範なユーザにわたって高精度を維持する方法の開発によって、豊かで信頼性のあるジェスチャインタフェースを提供する。実施形態は、一例としてＭｉｃｒｏｓｏｆｔＫｉｎｅｃｔからの深度データを用いてリアルタイムな手の検出および追跡を提供するが、これに限定されない。１６人のユーザから集められた８つの手の形状に対して定量的な形状認識結果が提示されるとともに、物理的な構成およびインタフェース設計の課題が提示されて信頼性および全体のユーザ体験を向上させる助けになる。

手の追跡、ジェスチャ認識、そして視覚ベースのインタフェースはコンピュータビジョンコミュニティ内で長い歴史を有する（例えば１９８０年に出版されたプット・ザット・ゼア（あれをそこに置く）システム（例えばＲ．Ａ．Ｂｏｌｔ．「プット・ザット・ゼア：グラフィックインタフェースにおける音声及びジェスチャ（Ｐｕｔ−ｔｈａｔ−ｔｈｅｒｅ：Ｖｏｉｃｅａｎｄｇｅｓｔｕｒｅａｔｔｈｅｇｒａｐｈｉｃｉｎｔｅｒｆａｃｅ．」ＣｏｎｆｅｒｅｎｃｅｏｎＣｏｍｐｕｔｅｒＧｒａｐｈｉｃｓａｎｄＩｎｔｅｒａｃｔｉｖｅＴｅｃｈｎｉｑｕｅｓ，１９８０（「Ｂｏｌｔ」）））。興味を持った読者はより広い分野に広がる多くの調査論文へ向けられる（例えばＥｒｏｌ，Ｇ．Ｂｅｂｉｓ，Ｍ．Ｎｉｃｏｌｅｓｃｕ，Ｒ．Ｂｏｙｌｅ，ａｎｄＸ．Ｔｗｏｍｂｌｙ．「視覚ベースの手ポーズ推定（Ｖｉｓｉｏｎ−ｂａｓｅｄｈａｎｄｐｏｓｅｅｓｔｉｍａｔｉｏｎ）」：Ａｒｅｖｉｅｗ．ＣｏｍｐｕｔｅｒＶｉｓｉｏｎＡｎｄＩｍａｇｅＵｎｄｅｒｓｔａｎｄｉｎｇ，１０８：５２−７３，２００７（「Ｅｒｏｌ他」）、Ｓ．ＭｉｔｒａａｎｄＴ．Ａｃｈａｒｙａ．「ジェスチャ認識−調査（Ｇｅｓｔｕｒｅｒｅｃｏｇｎｉｔｉｏｎ：Ａｓｕｒｖｅｙ．）」ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏｎＳｙｓｔｅｍｓ，ＭａｎＡＮＤＣｙｂｅｒｎｅｔｉｃｓ −ＰａｒｔＣ，３７（３）：３１１−３２４，２００７（「Ｍｉｔｒａ他」）、Ｘ．Ｚａｂｕｌｉｓ，Ｈ．Ｂａｌｔｚａｋｉｓ，ａｎｄａ．Ａｒｇｙｒｏｓ．「人間コンピュータ相互作用のための視覚ベース手ジェスチャ認識（Ｖｉｓｉｏｎ−ｂａｓｅｄｈａｎｄｇｅｓｔｕｒｅｒｅｃｏｇｎｉｔｉｏｎｆｏｒｈｕｍａｎ−ｃｏｍｐｕｔｅｒｉｎｔｅｒａｃｔｉｏｎ．）」ＴｈｅＵｎｉｖｅｒｓａｌＡｃｃｅｓｓＨａｎｄｂｏｏｋ，ｐａｇｅｓ３４．１−３４．３０，２００９（「Ｚａｂｕｌｉｓ他」）、Ｔ．Ｂ．ＭｏｅｓｌｕｎｄａｎｄＥ．Ｇｒａｎｕｍ．「コンピュータビジョンベースの人間モーションキャプチャの調査（ａｓｕｒｖｅｙｏｆｃｏｍｐｕｔｅｒｖｉｓｉｏｎ−ｂａｓｅｄｈｕｍａｎｍｏｔｉｏｎｃａｐｔｕｒｅ．）」ＣｏｍｐｕｔｅｒＶｉｓｉｏｎａｎｄＩｍａｇｅＵｎｄｅｒｓｔａｎｄｉｎｇ，８１：２３１−２６８，２００１（「Ｍｏｅｓｌｕｎｄ他−１」）、Ｔ．Ｂ．Ｍｏｅｓｌｕｎｄ，ａ．Ｈｉｌｔｏｎ，ａｎｄＶ．Ｋｒｕｇｅｒ．「視覚ベースの人間モーションキャプチャ・分析の展開に関する調査（ａｓｕｒｖｅｙｏｆａｄｖａｎｃｅｓｉｎｖｉｓｉｏｎ−ｂａｓｅｄｈｕｍａｎｍｏｔｉｏｎｃａｐｔｕｒｅａｎｄａｎａｌｙｓｉｓ．）」ＣｏｍｐｕｔｅｒＶｉｓｉｏｎａｎｄＩｍａｇｅＵｎｄｅｒｓｔａｎｄｉｎｇ，１０４：９０−１２６，２００６（「Ｍｏｅｓｌｕｎｄ他−２」）））。

Ｐｌａｇｅｍａｎｎ他の研究は、頭、手、および足といった体の一部を深度画像から直接検出および分類するための方法を示している（例えばＣ．Ｐｌａｇｅｍａｎｎ，Ｖ．Ｇａｎａｐａｔｈｉ，Ｄ．Ｋｏｌｌｅｒ，ａｎｄＳ．Ｔｈｒｕｎ．「深度情報からの身体部分のリアルタイム識別及び位置決め（Ｒｅａｌ−ｔｉｍｅｉｄｅｎｔｉｆｉｃａｔｉｏｎａｎｄｌｏｃａｌｉｚａｔｉｏｎｏｆｂｏｄｙｐａｒｔｓｆｒｏｍｄｅｐｔｈｉｍａｇｅｓ．」」ＩＥＥＥＩｎｔｅｒｎａｔｉｏｎａｌＣｏｎｆｅｒｅｎｃｅｏｎＲｏｂｏｔｉｃｓａｎｄＡｕｔｏｍａｔｉｏｎ（ＩＣＲＡ），２０１０（「Ｐｌａｇｅｍａｎｎ他」））。彼らはこれらの体の一部を、深度画像において接続されたメッシュを配置し、前の点のセットからの測地的な距離を最大化するメッシュ点を繰り返し探索することで検出される、測地的な極値と同等とみなす。このプロセスは、メッシュの重心を用いるか、２つのもっとも遠い点を配置することによって結実される。ここで示される手法は概念的には似ているが、散乱を無視するためのあらかじめ決められた境界ボックスを必要としない。さらに、Ｐｌａｇｍａｎｎ他は、正当な頭、手、または足としての極値を特定するために学習済の分類器を用いたが、我々の方法は、より高解像度の深度センサを利用し、極値をいくつかの異なる手の形状の一つとして認識する。

Ｓｃｈｗａｒｚ他は、Ｐｌａｇｅｍａｎｎ他の研究を、付加的な体の部分の検出と全身の骨格のメッシュへの適合とによって拡張する（例えば、Ｌ．Ａ．Ｓｃｈｗａｒｚ，Ａ．Ｍｋｈｉｔａｒｙａｎ，Ｄ．Ｍａｔｅｕｓ，ａｎｄＮ．Ｎａｖａｂ．「測地的距離及びオプティカルフローに基づく飛行時間画像からの人間の３次元ポーズの推定（Ｅｓｔｉｍａｔｉｎｇｈｕｍａｎ３ｄｐｏｓｅｆｒｏｍｔｉｍｅ−ｏｆ−ｆｌｉｇｈｔｉｍａｇｅｓｂａｓｅｄｏｎｇｅｏｄｅｓｉｃｄｉｓｔａｎｃｅｓａｎｄｏｐｔｉｃａｌｆｌｏｗ．））」、ＡｕｔｏｍａｔｉｃＦａｃｅａｎｄＧｅｓｔｕｒｅＲｅｃｏｇｎｉｔｉｏｎ，ｐａｇｅｓ７００−７０６，２０１１（「Ｓｃｈｗａｒｚ他」））。彼らはまた、自己遮蔽に対する補償を支援するためのオプティカルフロー情報を組み込む。しかしながら、本明細書で示される実施形態に対する関係は、Ｓｃｈｗａｒｚ他が、散乱する状況においておそらく信頼性を低下させるであろう、測地的距離を計算するためのグローバル情報を利用しており、彼らが指の構成の検出または手の全体の形状を認識しようとしないという、Ｐｌａｇｅｍａｎｎ他の関係に似ている。

Ｓｈｏｔｔｏｎ他は、クエリ点と局所的な近隣の他の点との距離に照準を合わせたランダム決定フォレスト（例えば、Ｌ．Ｂｒｅｉｍａｎ．「ランダムフォレスト（Ｒａｎｄｏｍｆｏｒｅｓｔｓ．）ＭａｃｈｉｎｅＬｅａｒｎｉｎｇ）」，４５（ｌ）：５−３２，２００１（「Ｂｒｅｉｍａｎ」））を用いる、異なる体の部分として深度点を直接分類する方法を開発した（例えば、Ｊ．Ｓｈｏｔｔｏｎ，Ａ．Ｆｉｔｚｇｉｂｂｏｎ，Ｍ．Ｃｏｏｋ，Ｔ．Ｓｈａｒｐ，Ｍ．Ｆｉｎｏｃｃｈｉｏ，Ｒ．Ｍｏｏｒｅ，Ａ．Ｋｉｐｍａｎ，ａｎｄＡ．Ｂｌａｋｅ．「単一の深度情報からの分解したリアルタイムの人間ポーズ認識（Ｒｅａｌ−ｔｉｍｅｈｕｍａｎｐｏｓｅｒｅｃｏｇｎｉｔｉｏｎｉｎｐａｒｔｓｆｒｏｍａｓｉｎｇｌｅｄｅｐｔｈｉｍａｇｅ．）」ＩＥＥＥＣｏｎｆｏｎＣｏｍｐｕｔｅｒＶｉｓｉｏｎａｎｄＰａｔｔｅｒｎＲｅｃｏｇｎｉｔｉｏｎ，２０１１（「Ｓｈｏｔｔｏｎ他」））。それらの目標は、リアルタイムな骨格追跡システムへより高レベルな情報を提供することであったため、それらは、頭、手、足だけよりもはるかにうまくいく、３１の異なる体の部分を認識する。ここで記載されるこの手法もまた、それらは分類オーバーヘッドが低く、また、そのモデルは複数クラス問題を扱うための能力が本来備わっているため、ランダム決定フォレストを用いる。ここで記載される実施形態は、いくつかの異なる手の形状を認識するためにフォレストに学習を行わせるが、手ではない体の部分は検出しない。

視覚ベースのインタフェースにおいて、ここで説明されるように、手の追跡は、カーソル制御、３Ｄナビゲーション、動的なジェスチャの認識、および一貫したフォーカスとユーザ認識のような、ユーザ相互作用をサポートするためにしばしば用いられる。散乱し、視覚的に雑音の多い状況における堅固な追跡のため、数々の洗練されたアルゴリズムが開発されてきたが（例えば、Ｊ．Ｄｅｕｔｓｃｈｅｒ，Ａ．Ｂｌａｋｅ，ａｎｄＩ．Ｒｅｉｄ．「アニールした粒子フィルタリングによる多関節身体モーションキャプチャ（Ａｒｔｉｃｕｌａｔｅｄｂｏｄｙｍｏｔｉｏｎｃａｐｔｕｒｅｂｙａｎｎｅａｌｅｄｐａｒｔｉｃｌｅｆｉｌｔｅｒｉｎｇ．）」ＣｏｍｐｕｔｅｒＶｉｓｉｏｎａｎｄＰａｔｔｅｒｎＲｅｃｏｇｎｉｔｉｏｎ，ｐａｇｅｓ１２６−１３３，２０００（「Ｄｅｕｔｓｃｈｅｒ他」）、Ａ．ＡｒｇｙｒｏｓａｎｄＭ．Ｌｏｕｒａｋｉｓ．「コンピュータマウスの遠隔制御のための視覚ベースの手のジェスチャ解釈（Ｖｉｓｉｏｎ−ｂａｓｅｄｉｎｔｅｒｐｒｅｔａｔｉｏｎｏｆｈａｎｄｇｅｓｔｕｒｅｓｆｏｒｒｅｍｏｔｅｃｏｎｔｒｏｌｏｆａｃｏｍｐｕｔｅｒｍｏｕｓｅ．）」ＣｏｍｐｕｔｅｒＶｉｓｉｏｎｉｎＨＣＩ，ｐａｇｅｓ４０−５１，２００６．１（「Ａｒｇｙｒｏｓ他」））、長期にわたる追跡および追跡の初期化のための手の検出は、依然として困難な課題のままである。ここで記載される実施形態は、手の形状、ポーズおよび動きに基づくジェスチャインタフェースの作成をサポートする、信頼性のある、マーカーレスな手の追跡システムを構築する。そのようなインタフェースは、時宜にかなったフィードバックと継ぎ目のないユーザ体験をともに許可する、低遅延の手の追跡と正確な形状の分類とを要求する。

ここで記載される実施形態は、局所分割と手の検出のための単一のカメラからの深度情報を利用する。正確で、ピクセルごとの深度データは、視覚的な複雑さとは大いに無関係なやり方で、前面／背景の分割問題を著しく軽減する。それゆえ実施形態は、異なるユーザおよび環境にわたって非常に高度の変化が現れることが典型的な、局所組織および色といった第二の特性よりむしろ、人体の３Ｄ構造を基にした身体部分の検出器および追跡システムを構築する（Ｓｈｏｔｔｏｎ他、Ｐｌａｇｅｍａｎｎ他を参照）。

実施形態は、視覚ベースのユーザインタフェースのための基盤としてマーカーレスの手の追跡および手の形状認識を提供する。そのようなものとして、ユーザの体全体の識別および追跡は厳密には必要でなく、実際、全身（または上半身全体さえ）が可視であることは想定されていない。代わりに、実施形態は、机がユーザの腕の一部をふさいで、手が体の残りに観察可能に接続されていない、座ったユーザのような、限られた可視性しか許可しない状況を想定する。そのようなシナリオは、ユーザが彼らの肘を彼らの椅子のアームに乗せてもよい場合や、または開いたラップトップのような机上の散らかりがカメラの視界のより低い位置をふさいでもよい場合のような、現実世界の環境において極めて自然に生じる。

図４は、一実施形態における、手の追跡および形状認識にて用いられる８つの手の形状を描く。「−左」または「−右」で終わるポーズの名前は、その手に特有であり、一方で「オープン（ｏｐｅｎ）」または「クローズド（ｃｌｏｓｅｄ）」は、親指が伸びているまたは手のひらに折りたたまれているかを指す。頭字語「ｏｆｐ」は「ｏｎｅｆｉｎｇｅｒｐｏｉｎｔ（一本指ポイント）」を表し、伸ばされた人差し指に対応する。

一実施形態の８つのポーズの初期セットは、広範な有用な作用を提供し、一方で比較的強い視覚の独自性を維持する。例えば、オープン−ハンドと握りこぶし（ｆｉｓｔ）の組み合わせは、カーソルを動かし、そしてオブジェクトを握るか、または選択するために用いられてよい。同様に、パーム−オープンのポーズは、さらなる情報を起動およびさらけ出し（空間へ「押し込む」グラフィカルな表現）、そして次に横方向の手の動きでデータの中をスクロールさせるために用いることができる。

手の形状の他のセットはより広範だが、指の構成に関する、はるかに正確で完全な情報もまた必要とする。例えば、アメリカ手話（ＡＳＬ：ＡｍｅｒｉｃａｎＳｉｇｎＬａｎｇｕａｇｅ）の指つづりのアルファベットは、２６文字に加え０から９までの数字をカバーする、はるかに豊富な手のポーズのセットを含む。しかしながら、これらの手の形状は、ユーザと特に視覚システムとの両方にとって識別するのが困難でありうる、微妙な指のキュー（合図）を利用する。

一実施形態のジェスチャのセットは視覚的に区別可能であるように設定されたという事実にも関わらず、幅広い範囲の変化が各形状クラス内に見られた。図５は、同一の手の形状のカテゴリに対する、ユーザにわたる変化を示すサンプル画像を示す。より正確で、より高い解像度の深度センサが、クラス内の差異をいくらか減らすであろうが、最も重要な原因は人々の手および奥行きにわたる本来的な変化と、単一の視点のみを用いることで発生する閉塞効果である。全体のサイズ、指の幅、手のひらのサイズに対する指の長さの比、可動域、柔軟さ、そして指の制御において、物理的な手の変化が観察された。例えば、パーム−オープンポーズにおいて、いくらかのユーザは親指を自然に伸ばして、それがほぼ手のひらと人差し指に対して垂直になるようにするだろうが、一方で他のユーザは彼らの親指を４５度以上動かそうとすると不快を表した。同様に、例えばユーザがパーム−オープンジェスチャを、彼らの指をしっかりと押し付けて開始したものの、それからジェスチャが進むにつれて、彼らの指が緩んでしまい、従ってパーム−オープンとオープン−ハンドの区別が不明瞭になる場合ように、単一の作用の間において変化が見られた。加えて、ＳＯＥキオスクシステムは、カメラのセンサ（つまり、カメラがｚ軸を見下ろすと仮定するとｘｙ平面）に対して平行な平面内にある手の指す角度を推定することができる。指先を用いることで、それは実世界の（２次元の）指す角度に気が付く。

ここでの実施形態の主要な寄与は、手の形状および機構における幅広い変化にも関わらず、異なるユーザにわたり確実に動作する、リアルタイム視覚インタフェースの設計と実装である。一実施形態の手法は、高速な手の形状分類と組み合わされたフレームごとの局所的極値の検出を用いた、効率的で、骨格を用いない手の検出および追跡アルゴリズムに基づいており、ここでこの手法の定量的な評価は、以前見たことがないユーザに対して、９７％を上回る手の形状認識率を提供する。

ここで実施形態の検出および追跡は、ユーザの体の主要部の中心からの測地的距離の観点から、手は極値に対応するというアイデアに基づく。この仮定は、例えばユーザが両手を腰に当てて肘を張って立つときに破られるが、そのような身体のポーズはインタフェースとの有効な作用を除外するので、これらの低レベルの検出漏れは高レベルの検出漏れに対応しない。実施形態は、処理量を制限するためのあらかじめ決められた境界ボックスを要求することなしに散乱に対して堅固であるべきであるので、それらの実施形態の手法はグローバル測地的距離を計算することを避け、代わりにより単純で局所的な手法をとる。具体的には、深度画像中の局所的で方向のピークを直接検出することで極値の候補が発見され、つぎに空間的に結合されたコンポーネントを潜在的な手として抽出する。

実施形態の主要な検出および追跡は、入力解像度６４０×４８０から８０×６０にサブサンプリングした後の各深度フレームに対して実行される。しかし、手の形状の分析は、ここで記載されるように、より高い解像度で実行される。ダウンサンプリングされた深度画像は、深度データを失うことに対応するゼロの値の無視を行うとともに、エッジを保つ、堅固な手法を用いて計算される。深度の読み込み値は本質的にこの状況における主要部を表すため、異種の深度の値の平均化は避けることが望ましく、さもなければ中間の深度において「幻覚」の主要部に繋がるであろう。

局所的ピークは、４つの基本方位（上、下、左、右）のいずれかにおいて空間的に隣接した場合よりも、より広がったピクセルを探すことで、８０×６０の深度画像から検出される。このヒューリスティックは、多くの誤検出の原因となっても、低い検出漏れを提供する。言い換えると、実施形態は現実の手を逃したくないが、複数の検出または他のオブジェクトを含んでもよい。なぜならそれらは後段で除去されるだろうからである。

各ピークのピクセルは、手の最大サイズによって限界が画された接続されたコンポーネント（「ブロブ」）の種になるが、手の最大サイズは、３００ｍｍに対して、想定される深度誤差を示す深度依存性のある緩和値を加えたものである。ＭｉｃｒｏｓｏｆｔＫｉｎｅｃｔにとって、深度誤差は２つの近接したセンサの生の読み込み値（近隣のセンサの生の読み込み値の間のメトリック距離に基づく深度の関数としての、推定される最小の深度の曖昧さのプロットを示す図７を参照）によって表現される物理的な距離に対応する。言い換えると、２０００ｍｍの距離において１０ｍｍの深度の違いを探すことは、その深度における代表的な精度は２５ｍｍしかないので、妥当ではないという事実について、緩みの値は説明になる。

一実施形態のアルゴリズムは、距離変換を用いて効率的に計算されることができる、ブロブの境界から最も離れたピクセルを見つけることで、各ブロブに対して潜在的な手の中心を推定する。次に、前腕および他の体の部位を除く一方で、それはさらに手のピクセルを含むことを目標に、２００ｍｍの手のひらの半径を用いてブロブを刈り取る。最終的に、低レベル処理は、似た深度を持つ、ブロブの近隣にあるそれらのピクセルとして定義される、ブロブを「拡張」する深度ピクセルに対する外側の境界を検索することで結論を出す。一実施形態のアルゴリズムは、境界の長さと比較して小さい単一の領域を探して拡張ピクセルを解析し、それはとても大きいもしくは切断された拡張領域を持つブロブを刈り取る。この拡張領域は、有効な手のブロブにおける手首に対応すると想定され、Ｐｌａｇｅｍａｎｎ他が測地的なバックトラックポイントを使用する（Ｐｌａｇｅｍｅｎｎ他を参照）のとほとんど同じやり方で、姿勢を推定するために使用される。

次にブロブは、現在のフレーム中のブロブを既存の軌跡と結び付ける、追跡モジュールへ送られる。各ブロブ／軌跡の対は、ブロブの重心と追跡の軌跡の境界との間の最小距離を、その現在の速度によって得点づける。加えて、低レベルのあいまいさによって重なるブロブがあってよく、それで追跡モジュールは、暗示された相互排除を実行する。ブロブは、適合の全てにわたる総合得点を最小化することで、全体的に最適な方法で軌跡と関連付けられる。２５０ｍｍの得点の閾値は、極度に悪い一致を防ぐために使用され、それゆえいくつかのブロブおよび／または軌跡は一致しなくてよい。

主な軌跡の拡張の後、残存する一致しないブロブは軌跡と比較され、空間的にごく近接していれば第二のブロブとして加えられる。この方法では、単一の手が時々いくつかの分離したコンポーネントとして観察されてよいため、複数のブロブが単一の軌跡と関連付けられうる。観察が支離滅裂になる原因となるシナリオは、キネクトの照射された構成された光の解析を失敗させる大きな光る指輪をユーザがつけていた場合である。これらの場合、指輪自身に覆われて深度データがないであろうために、指輪をつけた指は、手から視覚的に分離されてよい。指の欠如は手の形状の解釈を完全に変えうるため、指のブロブを軌跡と関連付けることは極めて重要になる。

そして追跡モジュールは、対応オブジェクトの任意の視覚的証拠なしで、いくつかのフレームを進める、新しいトラックを植え付け、古いトラックを削るために任意の残存ブロブを使用する。

手の形状認識に関して、ブロブの抽出及び追跡に使用される８０×６０の深度画像の奥行きは、時として、形状分析のための不十分な情報を提供する。代わりに、手のポーズ認識は、クォーター・ビデオ・グラフィクス・アレイ（ＱＶＧＡ）ディスプレイ解像度である３２０×２４０の深度画像を活用する。ＱＶＧＡモードは、ピクセルにおける画像のサイズまたは解像度を描写する。一実施形態は、どのＱＶＧＡピクセルがそれぞれの軌跡に対応するかを決定する。これらのピクセルは、その対応する８０×６０ピクセルからの小さい深度距離内の、それぞれのＱＶＧＡピクセルに、接続されたコンポーネントサーチを植え付けることにより、識別される。一実施形態のアルゴリズムはまた、カーソル制御及び他の連続的な、位置ベースの作用における、より繊細な３Ｄ位置推定を提供するＱＶＧＡピクセルを使用して手の中心を再度推定する。

一実施形態は、それぞれのブロブを８つのモデル化された手の形状の一つとして分類するために、ランダム決定フォレスト（Ｂｒｅｉｍａｎを参照）を使用する。それぞれのフォレストは、決定木の集合体であり、最終的な分類（またはクラス上の分布）はすべての木にわたる結果を合併させることによってコンピュータで計算される。単一の決定木は、そのトレーニングデータに容易にオーバーフィットしうる、そのため木は分散を増大し、合成のエラーを減少するためにランダム化される。ランダム化は二つの形をとる。（１）それぞれの木は、十分なトレーニングデータセットからブートストラップサンプルを通じて学ばれ、（２）木の中のノードは少なく、ランダムに選択された数の特徴上で最適化する。ランダム決定フォレストは、リアルタイムな手の形状認識に便利である、いくつかの好ましい属性をもっている：それらは極端に実行時間が速く、それらは自動的に特徴の選択を果たし、それらは本質的に複数クラスの分類をサポートし、それらは容易に並列化されることができる。

一実施形態の方法は、分割された手のパッチを特徴付ける、画像特徴の三つの異なる種類を活用する。集合Ａは、ブロブの輪郭に覆われたピクセルのパーセンテージ、検出された指先の数、ブロブの重心から指先への平均角度、および指先自身の平均角度のように、グローバルな画像統計を含む。それはまた、７つすべての独立したフラッサーサックモーメント（例えば、Ｊ．ＦｌｕｓｓｅｒａｎｄＴ．Ｓｕｋ．「対称なオブジェクトの認識に向けた回転モーメントの不変条件」（Ｒｏｔａｔｉｏｎｍｏｍｅｎｔｉｎｖａｒｉａｎｔｓｆｏｒｒｅｃｏｇｎｉｔｉｏｎｏｆｓｙｍｍｅｔｒｉｃｏｂｊｅｃｔｓ．）ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏｎＩｍａｇｅＰｒｏｃｅｓｓｉｎｇ，１５：３７８４−３７９０，２００６（「Ｆｌｕｓｓｅｒ他」））を含む。

指先は、高い正の曲率の領域をさがすことにより、それぞれのブロブの輪郭から検出される。曲率は、適当な丸め込みでサンプリングされた、輪郭点Ｃｉ及びそのｋ近傍Ｃｉ−ｋとＣｉ＋ｋによって形成されたベクトル間の角度を見ることによって推定される。一実施形態のアルゴリズムは、二つのスケールで高い曲率を使用し、ブロブの深度に依存するｋの値を調節するため、ｋは第一のスケールではおおよそ３０ｍｍで、第二のスケールではクエリ点からおおよそ５０ｍｍである。

特徴集合Ｂは、その全体のサイズで正規化されたブロブの境界ボックス内の、すべての実行可能な長方形に覆われたピクセルの数で構成されている。スケールの不変性を確かにするために、それぞれのブロブ画像は、集合Ｂにおける２２５の長方形ひいては２２５の記述子（集合Ｂが四つの長方形を示し、集合Ｃが一つの対になったグリッドセル間の平均深度の違いを示すという、抽出された特徴を示す図８を参照）を意味する５×５のグリッドにサブサンプリングされる。

特徴集合Ｃは、異なる長方形内の対象範囲を見る代わりに、集合Ｂと同じグリッドを使用し、それはそれぞれの対になった個別セルにおける平均深度間の違いを備える。５×５のグリッド上に２５のセルがあるため、集合Ｃにおいては３００の記述子がある。特徴集合Ｄは、５３６の全体の特徴に至る、集合Ａ、Ｂ、及びＣからのすべての特徴を組み合わせる。

本明細書で記載されるように、ブロブの抽出アルゴリズムは、拡張ピクセルの検索により、それぞれのブロブの手首の位置を推定しようと試みる。そのような領域を見つかれば、それは拡張領域の中心をブロブの重心に接続するベクトルに基づく姿勢を推定するために使用される。この角度の逆にＱＶＧＡ画像パッチを回転させることで、多くのブロブは、任意の記述子が計算される前に、正準な姿勢を持つように変換されうる。このプロセスは、回転不変性のレベルを提供することで、分類精度を改善する。しかしながらすべてのブロブに対し、姿勢を推定することはできない。例えば、腕で直接カメラを指すとすると、ブロブはどんな拡張ピクセルも持たないだろう。これらの場合において、記述子は変換されないブロブ画像上で計算される。

リアルタイムな手の追跡及び形状認識において本明細書で実施形態を評価するために、サンプル映像は、１６の題材から記録された（図６Ａ、６Ｂ、及び６Ｃ（まとめて図６）は、追跡結果６０１、トラック履歴６０２、および信頼値を伴う認識結果（テキストラベル）、を伴う疑似カラー深度画像を示している３つのサンプルフレームを示す）。映像は、構造化された光に基づく手法を使用してピクセルごとの奥行きを推定する、マイクロソフトキネクトを使用し、３０Ｈｚ、６４０×４８０の解像度で保存された。８つの映像に貢献されるそれぞれの題材は、図４に描かれる８つの手の形状への対応を分割する。本明細書に記載される分割及び追跡アルゴリズムは、最も近いＱＶＧＡブロブ映像をディスクに保存した、修正されたポストプロセスで、これらの映像上で稼働した。従って、トレーニングの例は、オンラインバージョンで使用される同じアルゴリズムを使用する映像から自動的に抽出された。唯一の手動の介入は、さもなければトレーニング集合の品質を落とすであろう少量の追跡エラーの除去であった。例えば、少しの映像の初めに、システムはユーザの手に固定して自動追尾する前に、ユーザの頭へのブロブの対応を保存した。

手のポーズのいくつかは、他のものが両手（例えば、勝利（ｖｉｃｔｏｒｙ））で非常に似ている一方で、左または右手のどちらか一方（例えば、パーム−オープン−左）に特定される。第二集合におけるポーズは、一度は任意の変換なしで、一度は垂直軸に沿った反射のあとの二度、トレーニングデータに含まれた。ライブの対話型システムを用いた質的実験を通じて、反射された例の包含が、認識のパフォーマンスにおける顕著な改善を導いたことが発見された。

１６の題材は、２５歳から４０歳の、身長１６０ｃｍから１８８ｃｍに及ぶ４人の男性と１２人の女性を含んだ。反射されたバージョンを含み、各人は、合計で９３，３３６ラベルの例に至る８つの手のポーズにわたって、１，８９８から９，６２５の例に貢献した。初期評価は、一般化パフォーマンスを推定するために、標準の相互検証を使用した。極端に低いエラー率が見つかったが、暗示的パフォーマンスは、比較的低い分類率を見る、ライブシステムを用いた新規ユーザの経験を確実には予測しなかった。

一つの解釈は、相互検証が過剰推定パフォーマンスであったというものである、なぜならトレーニングおよびテスト集合において、ランダムなパーティションがそれぞれのユーザからの例を含んだからである。トレーニング例が映像から抽出されたため、時間的相関関係の割合が高く、従って、テストパーティションは一般化パフォーマンスを示さなかった。クロスユーザのエラーの有効な推定を用いた、より有意義な実験を稼働するために、スイッチは、代わりにｌｅａｖｅ−ｏｎｅ−ｕｓｅｒ−ｏｕｔアプローチを使用するために作られた。この評価スキームにおいて、モデル及び特徴集合のそれぞれの組み合わせは、１５の題材からのデータでトレーニングされ、まだ見ていない１６番目の題材に対する分類器の結果を評価された。このプロセスは、テスト集合として異なる題材からのデータを使用するそれぞれの繰り返しを用いて、１６回繰り返された。

図９は、特徴集合Ａはグローバルな統計を使用し、特徴集合Ｂは異なる長方形において正規化された占有率を使用し、特徴集合Ｃはポイント間の深度の違いを使用し、特徴集合Ｄは集合Ａ、Ｂ、及びＣを組み合わせる、４つの特徴集合にわたる、ランダム決定フォレスト（ＲＦ）とサポートベクターマシン（ＳＶＭ）分類器との手の形状認識精度の比較をプロットする。それゆえ図９は、ランダム決定フォレスト（ＲＦ）およびサポートベクターマシン（ＳＶＭ）モデルの両方における平均認識率を提示する。ＳＶＭはＬＩＢＳＶＭ（例えば、Ｃ．Ｃ．ＣｈａｎｇａｎｄＣ．Ｊ．Ｌｉｎ．ＬＩＢＳＶＭ：Ａｌｉｂｒａｒｙｆｏｒｓｕｐｐｏｒｔｖｅｃｔｏｒｍａｃｈｉｎｅｓ．ＡＣＭＴｒａｎｓａｃｔｉｏｎｓｏｎＩｎｔｅｌｌｉｇｅｎｔＳｙｓｔｅｍｓａｎｄＴｅｃｈｎｏｌｏｇｙ，２：２７：１−２７：２７，２０１１（“Ｃｈａｎｇｅｔａｌ．”））を用いてトレーニングされ、データの部分集合上で小さな検索の結果に基づく、精度を最大化するように選択されたパラメータを用いた半径の基底機能カーネルを使用した。ＲＦ及びＳＶＭの両方は本明細書に記載される四つの特徴集合を用いてテストされた。

最も良い結果は、特徴集合Ｄを使用するＲＦモデル（ＲＦ−Ｄ）で達成された。この組み合わせは、２．４２の標準偏差における９７．２％の平均クロスユーザ確度を導いた。六つの題材が９９％の確度以上を見込んだ一方で、ＲＦ−Ｄでの任意の題材における最も悪いパフォーマンスは９２．８％であった。ちなみに、ＳＶＭを使用する最も良いパフォーマンスは、特徴集合Ｂで、それは２．７３の標準偏差で９５．６％の平均確度、及び最も悪い場合で８９．０％を与えた。

図９に提示されるＲＦの結果は、１００の木があるフォレストに基づく。それぞれの木は、３０の最大深度で学ばれ、枝刈りはなかった。それぞれの分かれたノードで、選択されたランダムな特徴の数は、記述子の総数の平方根に設定された。アンサンブル分類器はすべてのランダム木にわたって結果を合併させることにより、入力データを評価し、従って、実行時間は木の数に比例する。リアルタイムシステムにおいて、とくに遅延が問題であるとき、自然な質問は、フォレストの中の木の数が減少するにつれて、どのように分類精度が変化するか、である。図１０は、ランダム決定フォレストの中の木の異なる数を使用する手の形状認識精度の比較を提示する。グラフは、単一の例（緑のひしがた、右軸）を分類する平均時間を伴う、近似の９５％信頼区間（青い円、左軸）を描く平均精度及び±２σラインを示す。
図１０は、手の形状分類問題において、認識精度は、木を３０まで減らしても、９７．２％から９６．９％に落ちるだけで安定していることを示す。２０の木であっても、平均クロスユーザ精度は９６．４％に減少するだけであるが、この点を下回ると、パフォーマンスはより著しく落ち始める。使用したテストマシンにおいて、見受けられた平均分類速度は、１００の木を用いると例ごとに９３．３μｓだったが、３０の木を用いるとたった２０．１μｓだった。

高い確度は望ましいかもしれないが、一実施形態の対話型システムを用いて働くユーザの非公式報告と見解の解釈は、９７．２％という現在の精度は、肯定的なユーザ体験には十分であるということである。３％近いエラー率は、平均しておおよそ３０フレームに一度、一実施形態のシステムがユーザのポーズを誤って分類することを意味するが、そのような一様分布は、エラーが独立であるとは思えないため、実際には想定しない。エラーは凝集するであろうが、またそれらの多くはいくつかの重要な要因が原因で、実際使用する間、隠されるであろう。初めに、ライブシステムはランダムで短期間のエラーを避けるために時間的な一貫性を使用できる。二番目に、もし十分なフィードバックがあり、もしたったささいな行動の変化を必要とされれば、協力的なユーザはシステムに順応するであろう。そして三番目に、ユーザインタフェースは、容易に混乱される手のポーズの影響を最小化するよう、構成されうる。

インタフェースへの順応の良い例は、パーム−オープンポーズに基づくプッシュバック作用で生じる。この作用の典型的な使用法は、ユーザがグラフィカルな表現をより遠くから画面に戻すことにより、いっそう多くの作業空間を眺めることを許可する。ユーザはまた、作業空間の異なる領域をパンし、または異なるオブジェクト（例えば、動画、画像、または商品）を通じてスクロールすることができてよい。スクローリングは比較的長い作用を引き起こし、そのため、たとえユーザの意図が変わっていなくても、パーム−オープンがオープン−ハンドのようになり始めるように、ユーザはしばしば指をリラックスさせる。一実施形態は、たとえオープン−ハンドが他の状況において、はっきりと異なる作用を引き起こす場合であっても、オープン−ハンドがプッシュバック作用を中断させることを防ぐ単純な感覚の微調整を実施した。本来、パーム−オープンだけがそれを実施できても、両方のポーズは作用を続けることを許可される。さらに、分類の信頼度は、二つのポーズ間で遷移しているポーズの主要因であるために二つのポーズ間でプールされる。

実験はまた、インタフェース及び作業空間への物理的な変化を用いて執り行われた。例えば、顕著な改善は、深度カメラが第一の画面の上よりむしろ下の方に実装されたときのユーザ経験に見られた。この違いはおそらく、リラックスする、および基本の身体技巧および重力に起因する、手を上げるよりむしろ低くするユーザの傾向から生じる。上部に取り付けられたカメラからのビューが劣化するであろう一方で、下部に取り付けられたカメラを用いて、若干角度のある、またはより低い手は、手の形状のよりよいビューを提供する。同様に、大画面から離れて立つユーザの自然な傾向をうまく利用することができる。キネクト及び他の奥行きカメラが３０―８０ｃｍの範囲での最小のセンサ距離をもつため、ユーザはできるたけ少ないリマインダ及び警告メッセージで機能距離を維持するよう、働きかけられうる。一実施形態のインタフェースは、作用が近いセンサの面、またはカメラの視界のエッジに近づくとき、目に見える表示を提供するが、画面サイズのような暗黙の、自然な手がかりは、もっと好ましい。

本明細書に記載されるように、他のマーカーレス研究は、スケルトンシステムに重点的に取り組んでいる。ＳＯＥの表現として、本明細書に記載されるキオスクシステムは、従来のマーカーレスシステムと対照的に、指及び手の追跡及び検出に重点的に取り組む。人間の手は、ＳＯＥにおいて最適な入力候補を表現する。機敏で器用な、その構成はシステムボリュームを十分に活用する。さらに、ＳＯＥのキー値は、ユーザの因果関係の信念である。ジェスチャ言語が第一に単調で固定されたものである従来のシステムとは対照的に、一実施形態のキオスクシステムは、次元の深度に従って、動きを合併する動的で順次的なジェスチャを用いた空間的操作を達成する。

遅延の特性評価において、処理アルゴリズムは、状況の複雑さによって、２から３０ｍｓ（例えば、平均約８．５ｍｓ、標準偏差約２．５ｍｓ、最小値約２ｍｓ、最大値約２７ｍｓ）の範囲を示す実験で、遅延の約１０ミリセカンド（ｍｓ）を追加する。実施形態における実験は、代表シナリオ（例えば、一人のユーザで散乱物なし、一人のユーザで散乱物あり、二人のユーザで散乱物なし）を反映した。結果は、典型的なハードウェアのセットアップ（２．１３Ｇｈｚで稼働するＱｕａｄＣｏｒｅＸｅｏｎＥ５５０６）におけるデータの１，２８７フレームから推定された。図１１は、一実施形態における、キオスクシステムで実施される追跡及び検出コンポーネントを使用するそれぞれのフレームでの処理時間の結果（遅延）のヒストグラムである。結果は、カメラ上の保存とコンピュータへの転送の間の時間として定義される、ハードウェアの遅延を含まない。結果はまた、ドライバからの、及び最初のプールへの深度データを取得する時間として定義される、取得遅延を含まない、なぜなら後者の値はドライバの実装によって決まり、実験はキオスク装置でサポートされる二つのドライバのより遅いほうで段階分けされたためである。処理の手の形状における一実施形態の達成された遅延はいままでになく、典型的なインタラクティブディスプレイシステムにおける、一つの映像フレーム内での相互作用遅延に変換する。この正確な手の認識及び低遅延の組み合わせは、ＳＯＥに必要な途切れのない経験を提供する。

［キオスクにおけるＳＯＥのジェスチャ］
関連出願は、入力ジェスチャ言語を記載し、ここで参照され、本明細書の図表で説明されるジェスチャボキャブラリ（語彙）の文字列を定義している。例えば、図１２は、一実施形態に係るＳＯＥのジェスチャボキャブラリにおけるポーズの図を示す。図１３は、一実施形態に係るＳＯＥのジェスチャボキャブラリにおける姿勢の図を示す。このマーカーレスシステムは少なくとも以下のジェスチャを認識するが、これらのジェスチャに限定されない。
１．グラブ／ナビ、パン／ズーム：動的な順に、オープンハンド（開いた手）（＼／＼／−：ｘ＾）またはオープンパーム（開いた手のひら）（｜｜｜｜−：ｘ＾）がｘ軸に沿って押し、次に握りこぶし（＾＾＾＾＞）へ遷移する。
２．パレット：天井に向かい上方を指すワン・フィンガー・ポイント・オープン（ｏｆｐ−オープン、＾＾＾｜−＞：ｘ＾、ｇｕｎ、Ｌ）から親指クリックへ遷移する。
３．勝利：静的なジェスチャ（＾＾＼／＞：ｘ＾）
４．ゴールポスト／フレームイット：人差し指が天井に向かって平行に上方を指す２つのｏｆｐ−オープンの手（＾＾＾｜−＞：ｘ＾）および（＾＾＾｜−：ｘ＾）。
５．シネマトグラファ（撮影カメラマン）：両手のジェスチャにて、一方のｏｆｐ−オープンは、上方に向かって指さす人差し指により指し示す（＾＾＾｜−：ｘ＾）。第二の手は、これもまたｏｆｐ−オープンで、人差し指が互いに垂直になるように回転させられる（＾＾＾｜−：ｘ＾）。
６．左／右クリック：一連のジェスチャにおいて、ｏｆｐ−オープン（＾＾＾｜−：ｘ＾）は、親指を閉じる（つまり親指を手のひらに向かって「閉じる」ように動かす）ことで完成される。
７．ホーム／終了：両手の一連のジェスチャにおいて、水平な軸に沿った両手でどちらか片方のｏｆｐ−オープン（＾＾＾｜−：ｘ＾）またはｏｆｐ−クローズド（＾＾＾｜＞：ｘ＾）が、握りこぶし（＾＾＾＾＞：ｘ＾）を指さす。
８．プッシュバック：米国特許出願第１２／５５３，８４５号が、プッシュバックジェスチャを詳しく説明している。キオスクの実装において、オープンパーム（｜｜｜−：ｘ＾）がｚ軸に押し込み、次に水平軸を横断する。
９．ジョグダイヤル：この連続した両手のジェスチャでは、片手はベースで、別の手はシャトルである。ベースの手はｏｆｐ−オープンのポーズ（＾＾＾｜−：ｘ＾）で、シャトルの手はｏｆｐ−クローズドのポーズ（＾＾＾｜＞：ｘ＾）である。

これらのジェスチャは、本明細書で詳細に記載され、また、図１４−１６に示されるように実施される。空間的マッピングアプリケーションは、上記のジェスチャ１から５を含み、図１４は、一実施形態において、空間的マッピングアプリケーションによって用いられるキオスクシステム内のＳＯＥの命令の例である。メディアブラウザアプリケーションは、上記のジェスチャ４から９を含み、図１５は、一実施形態においてメディアブラウザアプリケーションによって用いられるキオスクシステム内のＳＯＥの命令の例である。アップロード／ポインタ／回転のエッジアプリケーションスイート（パッケージソフト）は、上記のジェスチャ３から８を含み、図１６は一実施形態において、アップロード、ポインタ、回転を含むアプリケーションによって用いられるキオスクシステム内のＳＯＥの命令の例である。

［アプリケーション］
マーカーレス設定の特殊性の中でＳＯＥのやり方を実現するアプリケーションの例として、アプリケーションをここに記載するが、ＳＯＥキオスクの実施形態はこれらのアプリケーションのみに限定されない。マーカーレス設定でＳＯＥを実装することにより、これらのアプリケーションは今までにない作用を達成し、異なる能力と優先度を反映する。一実施形態のこのアプリケーションは、空間的マッピング、メディアブラウザ、回転、アップロードそしてポインタを含む。空間的マッピングアプリケーションは、外部データセットの統合を含む複雑なデータセットの堅固な操作を有効にする。メディアブラウザアプリケーションは、ライトフットプリント（かすかな足跡）のプレゼンテーションの滑らかで直感的な制御を可能にする。回転、アップロードおよびポインタのアプリケーションは、キオスクのアプリケーション間の途切れのないナビゲーションを有効にするアプリケーションのｉＯＳスイートを備える。導入、可搬性そして選択の自由という観点から参入への低い障壁を提供するため、キオスクは削減されたセンシング資源とともに作用する。例えば、本明細書で詳細に説明されるキネクトセンサは、３０Ｈｚのフレームレートを提供する。関連出願にて説明されるシステムは、一実施形態にてＶｉｃｏｎカメラによって読み込まれるグローブを備え、１００Ｈｚという特徴をもつ。この制約のなかで、キオスクは、その追跡と検出システムを用いて、低遅延かつ信頼性のあるポーズ認識を達成する。

ここで提示されるＳＯＥアプリケーションは単なる例であり、実施形態を特定のアプリケーションに制限するものではなく、代わりにＳＯＥの新規性を表現する働きをもつ。具体的に、ＳＯＥアプリケーションは空間環境の割り当てを構築し、どのようにユーザがＳＯＥのジオメトリ空間を満たすかを適切にレンダリングする。利用者価値の観点から述べると、ＳＯＥアプリケーションはさらに、ユーザがＳＯＥの体積を十分に利用できる、途切れのない快適な実装を達成する。同様に、ＳＯＥアプリケーションは、確かに適切な視覚的表現のため、そしてＳＯＥにとってより根本的なことに、ユーザのジェスチャとシステムの反応とを連結する空間的操作のため、視覚的要素およびフィードバックを画面上に構築する。

ここで記載されるＳＯＥアプリケーションは、直接の空間的操作のユーザ体験−すなわち、３次元空間への関与、及び、グラフィックともに空間を共有するという確信−を支持する。ユーザとグラフィックとが同一の空間にあるようにユーザがデータを操作するために、ＳＯＥアプリケーションは、広範なジェスチャ、速度閾値、次元に制約のあるジェスチャ、そしてフォールオフを含むがこれらに限定されない、後述する技術を展開する。

アーキテクチャに関して、一実施形態のＳＯＥアプリケーションは、ＳＯＥの相互運用性の手法を十分に利用する。ＳＯＥアプリケーションは、技術スタック／オペレーティングシステムにかかわらずデータを表示し、同様にたとえばエッジ装置（ｉＰｈｏｎｅなど）からの低レベルデータを利用する。エッジ装置をＳＯＥに接続するために、ユーザは関連するｇ−ｓｐｅａｋアプリケーションをダウンロードする。本明細書における記載では、ｉＯＳまたは任意の他のクライアント向けのｇ−ｓｐｅａｋアプリケーションに制限することなく、代表例であるｇ−ｓｐｅａｋポインタアプリケーションによって提供される機能性を記載する。

関連出願で記載されたように、入力装置にかかわらず、ＳＯＥはプロテインによってそのプールアーキテクチャ内に蓄積されたイベントを受け入れる。同様に、ＳＯＥキオスクは、ｉＯＳ装置からのデータをプロテインとプールアーキテクチャを用いて統合する。ここで説明されるアプリケーションは、キオスクスタック内に組み立てられるフィードバックを利用する。左端から右端まで、同様に上面から底面まで、ユーザのジェスチャがセンサの範囲を超えて動くとき、システムは関連する端に沿った影付きのバーで信号を送ることができる。デザイン上の理由から、このアプリケーションは左右上の端を超えた動きに対するフィードバックを提供する。

［アプリケーション―空間的マッピング］
（ここで「ｓマッピング」または「ｓマップ」とも呼ばれる）空間的マッピング（Spatial Mapping）アプリケーションは、ユーザが大きなデータセットを眺め、重ね、そして操作することを許可する、ナビゲーションおよびデータ可視化機能を提供する。実世界ジオメトリに組み立てられたＳＯＥ内で動作して、ｓマップは、空間的データのレンダリングに適したベアアセットをもたらす。このようなＳＯＥの枠組みを用いて、空間的マッピングにより、大きなデータセットの３次元操作が提供される。データの表現をインタフェースと同期させるにつれ、ユーザの堅固なデータの作用は、より直感的でより印象的なものとなる。このようなレンダリングは、ここで記載されているようなデータセットの範囲に関連したものである。ここでの記載は、地理空間的な構成体（アプリケーションの開発で用いられるシナリオ）を呼び出す。

空間的マッピングアプリケーションは、どのようにユーザが空間的データに作用するかという手法の組み合わせを提供する。ベースラインとして、これは制御の特定の認知を強調する。このアプリケーションは、ユーザの動きを空間的な動きに直接対応付ける。安定した操作が望まれる状況において一対一の対応関係、有用な理解、そして制御が影響される。任意のシナリオにおけるキー値である直接のデータ位置は、たとえば地理空間地図の操作者に対して特に有用でありうる。同時に、ｓマップは、ユーザが大きなデータセットの中を高速に進む、迅速なナビゲーションという特徴を利用可能にする。ユーザ入力の影響を増大させるように、空間的マッピングアプリケーションは、空間的データを通じて入力を加速度に関連付ける。安定した操作および迅速なナビゲーションに向けたジェスチャの供給において、ｓマッピングは、ユーザの動きと快適さのみならず、機能もまた考慮に入れる。ここに記載されたように、空間的マッピングアプリケーションは、ジェスチャをユーザが開始した動作の種類へ対応させる。それゆえＳＯＥはユーザからデータへの途切れのないスループットを提供する。ユーザの操作は、データ命令そのものである。

（フィルタリング）
一実施形態の空間的マッピングアプリケーションは、この記載にわたって用いられる例である、地球の地図のようなホーム画像の表示を開放する。ユーザが入力された手の要素を提示したとき、追跡および検出パイプラインはジェスチャデータを提供する。システム内の様々なアクションを実行が簡単かつ楽しめるようにする一方で、高度な精度および表現力をユーザに提供するために、アプリケーションはこのデータに追加的にフィルタをかける。駆動している任意のインタフェース要素に適用される前に、未加工の空間的な動きが、一次ローパスフィルタを通される。

ユーザの物理的な動きがデジタルマップの論理動作を直接駆動する状況において、マップナビゲーションジェスチャのような作用を用いると、意図しない動作もしくは雑音により、所望の位置への到達が困難または不可能になりうる。雑音源は、ユーザの手の自然な震え、忠実度の低い追跡センサに起因する誤差、そしてユーザの動きを追跡するために用いられるアルゴリズムの副作用を含む。一実施形態のフィルタリングはこれらの雑音源に対抗する適応フィルタを備え、このフィルタリングは、２、３の例を挙げると、グラブ（つかむ）ナビゲーション、フレームイット（枠組みを作る）、垂直メニューを含むがこれらに制限されない、アナログ型のジェスチャにて用いられる。

一実施形態の適応フィルタを用いた例として、手でつかむ（グラブ）ジェスチャを考えると、図１７Ａは、ユーザが手を動かすにつれてよりノイズを悪化させる、ズーム（拡大）のための手の変位の指数マッピングを示す。この効果に対抗するため、一実施形態では、ユーザの変位に比例してフィルタの強さを適応的に（たとえば増加、減少させて）変化させる。図１７Ｂは、一実施形態における、代表的な適応フィルタ関数を用いる、正の手の変位（ユーザの方に手を引く）について、手の変位（Ｘ軸）に対するズーム因子（Ｚ）（Ｙ軸）のプロットを示す。代表的な適応フィルタ関数の一例は以下の通りであるが、これに限定するものではない。
［数１］
変数εはフィルタの機能曲線の離心率を表し、変数ｘは動きの範囲を表し、Ｚｍａｘは最大ズーム率を表す。ユーザにかかわらず各々が身体のパラメータ（たとえば腕の長さなど）の物理的な違いにかかわらずシステムに対して同等の制御を有するように、正規化された変位は、最大ズーム率をユーザ個人の動きの範囲にマッピングすることを許可する。負の手の変位（手を押しやる）に対して、ズーム因子（Ｚ）は以下のように計算される。：［数２］

手でつかむ（グラブ）ジェスチャの例をより詳細に考慮し、図１７Ｃは、一実施形態における、開いた手のひら（オープンパーム）がマップディスプレイ上の一エリアを目標として画面上のカーソルを駆動させるような、ズームのための手の変位の指数マッピングを示す。図１７Ｄは、一実施形態における、パン／ズームのジェスチャを開始するために手を握り締めることに関連した、ズームのための手の変位の指数マッピングを示す。この変位は最初に握りこぶしが出現した位置から測定される。

図１７Ｅは、一実施形態における、地図のパン及びズーム（同時に発生してよい）を行う間の、ズームのための手の変位の指数マッピングを示す。一実施形態の初期の手の変位は比較的浅い量のズームを提供し、この寛容な区間は、より安定した方法で固定されたズームレベルでの地図のナビゲートを許可する。

図１７Ｆは、一実施形態において、画面上のカーソルをマップディスプレイ上の一エリアを目標として開いた手のひらで駆動し、動きの快適な物理範囲からずっと離れた距離にユーザが到達することを許可するような、レベルをズームするための手の変位の指数マッピングを示す。図１７Ｇは、一実施形態において、手の変位のダイレクトマッピングにより、ユーザは、ジェスチャを開始した位置およびズーム率へ常に戻ってもよいことが保証されることを示す。

（ナビゲーションデータセット）
ユーザは、実質的に二重のジェスチャ系列を用いて、このホーム画像および後のグラフィックをナビゲートすることができる。この系列はグラブ／ナビおよびパン／ズームを含む用語を用いて参照される。空間的マッピングアプリケーションを通して、「Ｖ」ジェスチャ（＾＾＼／＞：ｘ＾）は、全リセットを開始する。マップはその「ホーム」ディスプレイ（たとえば、上記で開始された地理空間の例における、地球全体）にズームバックする。

第一に、ユーザは地図を「つかむ」（グラブする）。オープンハンド（＼／＼／−：ｘ＾）またはオープンパーム（｜｜｜｜−：ｘ＾）は、一エリアを目標にするために横方面にわたりカーソルを動かす。次に、握りこぶし（＾＾＾＾＞：ｘ＾）への遷移は、地図へカーソルを固定する。ユーザは、ここで地図を「ドラッグ」することができる。前頭面を横断し、画像フレームへマッピングされた握りこぶしは、地図を動かす。プッシュバックに類似した機能（以下にコメントする）において、パン／ズームは、深度次元に沿った移動を他の論理変換と関連付ける。

パン／ズームの系列において、ユーザは、ズームをもたらすために、握りこぶし（＾＾＾＾＞：ｘ＾）を画面に向けて押し出す。地図の可視領域は、より大きなデータ領域を表示するようにスケーリングされる。ジェスチャ動作を通して、データフレームディスプレイはズームレベルに結び付けられる。現在のズームレベルをもっとも鮮明にレンダリングするデータフレームは、地図のズームとして大きすぎるか小さすぎるものを、流すか或いは置換する。同様に、ユーザが握りこぶしを画面から離れるように引くにつれ、地図は、指示される領域に対してスケーリングし、漸進的により小さいデータ領域を表示する。加えて、ユーザは、握りこぶしを地図と平行に前頭面内で移動させることで、地図の可視領域をパンしてよい。握りこぶしの横方向の移動は地図を左右にパンし、垂直方向の移動は地図を上下にパンする。

キオスクのセンシング環境は限られており、開いた手から握りこぶしへのこの遷移を誤って解釈するだろう。ユーザが横方面を高速に横断すると、センサは、ぼやけた手のひらを握りこぶしとして解釈する。機能性を確保するため、空間的マッピングアプリケーションはジェスチャに速度閾値を組みこむ。高速な移動は、握りこぶしの検出およびそれに続くフィードバックを引き起こさない。そのかわりに、実施形態は意図的な関与を用いる。すなわち、もし横方向の移動にて所定の速度を超えた場合、アプリケーションは移動を連続するものとして解釈する。これは、「握りこぶし」の認識へはジャンプしない。

握りこぶしのジェスチャは広範なジェスチャであり、センサの精度領域で動作する。同時に握ることにより求められる感覚的な設計効果を提供する。ユーザはデータ空間の位置を「確保」または「固定」する。ピクセル精度の検出を許可しない、ここに記載されたキネクトのようなセンサであっても、ユーザは地図領域を正確に選択することができる。

大きなデータセットを操作するための道具として、ｓマッピングはこの固定ステップを素早い動きと併存させる。広範囲におよぶデータセットを使って作業するため、ユーザは広大な範囲を実行する必要がある。地球の地図を用いるユーザは、地球レベルから国、州および都市までジャンプしてもよい。

ダイレクトマッピングは、このようなデータを介したスイープの危険をもたらしうるだろう。それゆえ、一実施形態のシステムのジェスチャ空間は、ジェスチャの範囲を制限する。さらに、使用公差は一実施形態のジェスチャ範囲を制限する。典型的に、ユーザは限られた距離内でのみ快適にその手を動かせる。不正確さはユーザのジェスチャを侵害し、入力を不安定化させる。

有用性のパラメータにジェスチャを一致させることは、ＳＯＥの基本原理および設計実施である。大きなデータセットを通じた堅固なナビゲーションのために、アプリケーションは「フォールオフ」という入力から出力への非線形マッピングの技術を用いる。それは、ユーザがデータ範囲をズームインまたはズームアウトするような、加速度コンポーネントを提供する。

このシステムは、握りこぶしが最初に出現した位置からの変位を測定する。これはｚ変位の原点を記憶するため、ユーザはズームジェスチャを開始した位置へ戻ることができる。このアプリケーションが同時に起こるパンとズームとをサポートする一方、初期の手のオフセットは限られた効果を生み出す。このようなバッファゾーンは、固定されたズームレベルにおいて安定したナビゲーションを利用可能にする。

ここで詳細に記載されるように、アプリケーションは手のｚ変位をズームへと指数関数的にマッピングする。この効果において、マッピングアプリケーションは、大きなデータセット内でユーザが迅速にコンテキストを入手する、プッシュバックの主要な機能性を呼び起こす。関連出願はこのジェスチャを詳細に状況にあてはめ、記載する。プッシュバックは、深度次元に沿った移動を、水平軸に沿ったデータ空間の変換に関連付ける。深度次元に沿ったユーザの移動は、データフレームおよびその横方の近隣（つまり、左右のフレーム）のｚ軸変位を引き起こす。ｓマップにおいて、マップは空間的に固定されたままであり、ユーザの移動は論理ズームレベルまたは「高さ因子」へマッピングされる。すでに述べたように、アプリケーションにおいて、パンおよびズームは同時に発生しうる。「デッドスペース」やグリフフィードバックといった、ｓマップで計算しないコンポーネントは、本明細書で後述するメディアブラウザアプリケーションに含まれる。

（データセットのレイヤリング）
ｓマップの第二の供給は、複数データセットのその可視化である。複雑で、大きなデータセットの拡散とともに、個々の範囲のナビゲーションは、並置の疑問によって効果的に追われる。アプリケーションは、データセットへのアクセスを流動的なレイヤリングと組み合わせる。

関連出願は、ＳＯＥがいかに新しいプログラミング環境であるかを記載する。従来の相互作用コンピューティングから出発し、それは多様で根本的に異なるプロセスを統合する。それは、プログラミング言語やデータタイプないし構造の差異にかかわらず交換をサポートする。そして、マッピングアプリケーションにおいて、ユーザは、全く異なるソースおよびシステムからのデータレイヤに対するアクセスまたは制御を行うことができる。たとえば、地理空間の反復により、商業的なマッピングベンダからの市・州マップへのアクセス、自身のレガシーなシステムからの個人データへのアクセス、そしてベンダーのシステムからのウェアハウスアセットへのアクセスがなされてもよい。データはローカルに保管またはネットワーク越しにアクセスされうる。

このアプリケーションは、このデータにアクセスするために「レンズ」の特徴を組み込んでいる。この特徴のための他の用語は、「フルオロスコープ」を含むがこれに限定されない。マップの区画に置かれたとき、このレンズはこのエリアに対するデータをレンダリングする。「レンズ」ラベルによって示されたやり方で、選択されたエリアはデータレンズを通じて観察される。このデータセットは、パネル（「ペイン」、「パレット」、「ドロワ」および他の類似の用語で呼ばれる）内のディスプレイの左側に出現する。ｓマップのデザインは背景地図を強調する。使用中にはビジュアルドロワのみが提示される。これは、操作としてのグラフィクス上のＳＯＥの強調と、クリーンな空間体験に干渉しかねない持続的なメニューを降格させることと調和する。

このサイドメニューを引き上げるジェスチャは、ワークフローを映し出す。まず、ｏｆｐ−オープン（＾＾＾｜−：ｘ＾）は、画面の左側での表示のために垂直メニューを引き起こす。この呼び出しは両利きであり、左手または右手によって召集される。次に、垂直な動きが選択内で移動し、最終的に親指でのクリックまたは手首のラチェット回転はこの選択を固定する。選択のために上下移動するとき、ｙ軸のみがインタフェースの応答に寄与する。偶発的な手の動きのｘおよびｚコンポーネントは何一つ寄与しない。この単一軸への固定は、ＳＯＥアプリケーションでしばしば採用される重要な利便性の技術である。

このデザインは一実施形態に係るシステムの２つの原理を反映する。ワークフローと協調して、このシーケンスは、ユーザがジェスチャをどのように使うかに関連付けるために設計される。第二に、これらの１次元の特徴は、その次元の拡張された使用を許可する。ＳＯＥは、３次元を開放する一方で、効率的な入力を構成し、肯定的なユーザ体験をもたらすために、そのジオメトリのコンポーネントを戦略的に用いる。

この選択プロセスの間、プログラム中にわたって、ユーザは２つの方法でリセットすることができる。ここで述べられるように、「Ｖ」ジェスチャ（＾＾＼／＞：ｘ＾）は全体のリセットを生み出す。地図はその「ホーム」ディスプレイへズームバックする（例えば上記の開始された地理空間の例では地球全体）。任意の持続的なレンズは次第にフェイドし、それら自身を削除する。握りこぶしのジェスチャは「ローカル」リセットを達成する。ユーザがあるエリア上をズームしていたら、マップはこの伸縮された表現を保持する。しかしながら、握りこぶしのジェスチャを形成することで、レンズは、ジェスチャから免れて、次第にフェイドし、それ自身を削除するだろう。「Ｖ」および握りこぶしのリセットの両方で、レンズの物理的なインスタンスが消散したとしても、このシステムはレンズ選択のメモリを保持する。リセットの後にレンズを組み立てているユーザは、最後に選択したレンズタイプのインスタンスを作成する。

握りこぶしのジェスチャは、ここで記載されるように、ナビゲーション内で「つかむ」機能である。このジェスチャを呼び出すことにより、インタフェースはクリーンで単純な印象を維持する。しかしながら、このアプリケーションはまた、使用公差の周辺で設計される。握りこぶしを形成する際、あるユーザの慣行は、指を閉じて丸めるだけではなく、次に手をおろす。アプリケーションはダイレクトマッピングを展開し、握りこぶしのジェスチャで地図を「つかむ」ため、手の降下は地図を床に引っ張ってしまう。また、速度閾値がジェスチャに組み込まれる。すなわち、所定の速度を超えたユーザはグラブを引き起こさない。代わりにシステムが握りこぶしをリセットと解釈する。

（データセットのレイヤリング − オーバーレイ）
データセットの選択後、ユーザはレイヤを、（１）地図中の移動、（２）レンズのサイズ変更、（３）地図を再定義するための拡大、の３つの方法で作成・使用する。これらのアクションに関与するため、ユーザはレンズのインスタンスを作成する。再びワークフローに従うと、選択後のジェスチャは、左もしくは右のどちらかのｏｆｐ−オープンの手の構成を基礎とする。選択されたレンズをレンダリングするため、第二の手は「フレームイット」に持ち上げられる（ゴールポストのように見える）。これは、平行で天井に向けて指した人差し指による、２つのｏｆｐ−オープン（＾＾＾｜−：ｘ＾）および（＾＾＾｜−：ｘ＾）を使用する。このジェスチャは、パレットメニューのジェスチャからきれいに切れ目なく続き、容易に拡張することができる。

ここで、このデータレンズは再配置されうる。ここで記載したように、ユーザがこれを動かすにつれ、レンズは、データをそれがレイヤ化されているエリアにわたって投影する。ユーザは、ユーザの「フレーム」の横方向のベースに沿って（つまり、ｘ軸に沿った、差し伸ばした親指を通る仮想的な線に平行に）ユーザの手を拡げることで、レンズのサイズを広げたり、縮めたりしてもよい。標準のフルオロスコープの表現は四角であり、そのエリアはサイズ変更に伴い広がったり縮んだりする。ユーザは「フレームイット」を９０度回転させることでアスペクト比を変更することができる。機能において、このような「シネマトグラファ」ジェスチャ（＾＾＾｜−：ｘ＾）および（＾＾＾｜−：ｘ−）は「フレームイット」と等価である。もっとも、特徴的には、ユーザはその手によって形成された矩形をサイズ変更することでアスペト比を設定できる。

この「フレームイット」―追随ジェスチャ―はより高度であり、特徴とプレゼンテーションとの両方を最適化する「プロ」ユーザによって完全に活用される。ＳＯＥジェスチャのインタフェースは、プレゼンテーションアセットの集まりである。すなわち、ジェスチャが急に行われたときに印象的に、そして可能であればボリュームを最大にして表現する。ユーザはこのシネマトグラファのフレームを大きな弧でスイングし、それによりレンズの重ね合わせ（オーバーレイ）を強調することができる。この豊かなジェスチャインタフェースはまた、ユーザがシステムの公差を学習するように、ユーザがユーザのジェスチャを細かく調節することを許可する。これらの急な、または、印象的なジェスチャにより、彼は彼の入力を最適化する。

フルオロスコープは画面に関与し、多数の方法でそのデータを表現することができる。フルオロスコープが画面に関与し、それによりそのデータを表現するための方法の３つの例は以下の通りである。：

（１）全体画面（「全画面」モードへの移行）を包含するデータレイヤのために、ユーザはその手を広げる。閾値の距離を超え、レンズはそれが全体画面を包含する全画面モードへと移行する。

（２）地図へデータレイヤを固定するため、ユーザはレンズを地図の「上」に押し付ける。つまり、画面に向かって押し付ける。例えば、ユーザは、レンズを地理的な領域のような特定のエリアへ割り当てうる。ユーザが地図をあちこち移動させたとしても、レンズはその割り当てられたエリアへ固定されたままとどまる。

（３）データレイヤをディスプレイに固定するために、ユーザはレンズを自身に向かって引く。ディスプレイに付されたレンズは背景画像の上を漂う。ユーザが地図をあちこち移動させるにつれ、地図はレンズの下に移動された場合にデータを見せる。

この押し付けまたは引っ張りは、レンズをそれぞれ地図またはディスプレイに留める。サイズ変更から留め置きまでの一連の流れは、どのようにアプリケーションがＳＯＥのジオメトリのビルディングブロック（構成要素）を用いるかを説明している。レンズの選択（１次元内に表現／制約されたジェスチャがパレットを呼び起こすとき）と同様に、レンズのサイズ変更もまた１つの平面、つまり前部で発生する。次に、ｚ軸がスナップの動作のために用いられる。

データのレイヤリングのためのこれらのジェスチャは、２つの理由からユーザの実施にのっとって設計される。第一に、ユーザがレンズを「組み立てる」とき、この実施形態は、ユーザがどのくらい迅速にユーザの手を一緒に／別々にスライドさせたいかを考慮する。快適で表現可能な動きの範囲が、実空間の観点から測定される。体がどのくらい遠くまで移動したいかを反映するため、このアプリケーションは、ユーザごと、及びジェスチャごとに、調整または適応されうる。ユーザ体験を高めることに加え、この手法は出力に依存しない。画面のサイズはジェスチャの表現に影響しない。ユーザの動作が不変であるというこの分離は、このアプリケーションの移植を容易にする。

ユーザがレンズを選択および実装するにつれて、オーバーレイは透明性を組み込みうる。トポロジデータは透明性を使用するレンズの例である。このシステムは、ベースの地図および他のレイヤの上のレンズを合成し、透明性を適切に取り入れる。

（エッジ装置）
ＳＯＥエージェントのように、ｓマップは、エッジ装置からの低レベルデータを組み込む選択肢を許可する（上記の「コンテキスト」で定義される）。これは、アプリケーションが装置からの慣性データを使用する、「ポインタ」機能を含むが、これに限定されない。例えばｉＰｈｏｎｅのようなこの装置は、ｉＯＳクライアントのためにダウンロードされたｇ−ｓｐｅａｋポインタアプリケーションを備える。電話を画面に向け、そして指を押すと、ＳＯＥエリア内の任意のユーザは、ディスプレイにわたってカーソルを追跡できる。

［アプリケーション―メディアブラウザ］
メディアブラウザは、容易な使用およびアクセスを提供するために形成される。それはＳＯＥの根本的な適応性を反映する。すなわち、そのエンジニアリングが複雑なデータセットの動的な制御を可能にする一方、その手法は生来より単純な表現で抽出される。完全なＳＯＥ開発空間であるキオスクは、広範なユーザおよび操作への要求に適したアプリケーションをサポートする。ここで、ブラウザはメディアデッキの直感的なナビゲーションを許可する。

始動の際、アプリケーションは、右手のエリアの上部の握る「鏡」を用いて、ホームスライドへ開く。システムフィードバック要素であるこの鏡は、検出された入力を表示する小さなウィンドウである。この情報は匿名化され、システムは、深度の外にいるユーザに特有の情報を収集、表示または保存しない。この鏡は深度情報と握るストリングの両方を表示する。フィードバックは２つの利益を含む。第一に、このアプリケーションは動作していることを示し、システムがアクティブであることをユーザに伝達する。第二に、鏡は入力のための即席のデバッグ機構として動作する。
入力のフィードバックを用いて、ユーザが何をしているとシステムは解釈しているかを、ユーザは知ることができる。

（非スクロールジェスチャ／機能）
一実施形態において、その開始にあたり動作を開始するためにジェスチャは何一つ求められない。ユーザは、必要に応じてユーザの機能入力を提供することができる。この機能には、ユーザがスライドを一つずつ通るために左または右を「クリック」する前／後、ユーザが最初または最後のスライドにジャンプするホーム／エンド、ユーザがグリッドディスプレイですべてのスライドを見て選択できるオーバービュー、及び、ユーザが横方向のスライド表示を通して高速にスクロールできる速度ベースのスクロールが含まれるが、これに限定されない。

ここでの目録は、名前および関連する機能によってジェスチャをリストアップし、そして次にシステム入力を説明する。スライドを一つずつ進むために、ユーザは前／後のために左／右を「クリック」する。

このジェスチャは二部のシーケンスである。第一のコンポーネントはｏｆｐ−オープン（＾＾＾｜−：ｘ＾）である。すなわち、その姿勢が方向を表示する。そして、左手で上を指すことで左の、前のスライドへ移動する。右手で上を指すことで右の、後のスライドへ移動する。左または右を指すことで（地面に水平な人差し指で）、指し示した方向へ移動する。

アプリケーションは、ユーザの入力に対して視覚的なフィードバックを提供する。このジェスチャの第一の部分は、振動する矢印を引き起こす。矢印は、画面の関係する側に出現し、ユーザの姿勢の入力によって定義されたように、ブラウザが移動する方向を表示する。ジェスチャの第二の部分は、親指を閉じることによって（＾＾＾｜｜：ｘ＾または＾＾＾｜＞：ｘ＾）、その方向を「クリック」する。視覚的なフィードバックは、可能な移動を表示するわずかに暗い矢印と、スライドデッキの一方の端であることをユーザに示す点滅する赤いブロックとを含むが、これに限定されない。

最初または最後のスライドにジャンプするために、ユーザは両手を水平軸に沿えて、ユーザの握りこぶしを指す。システムはオープン（＾＾＾｜−：ｘ＾）またはクローズド（＾＾＾｜＞：ｘ＾）の指示を受け入れる。指す方向は方向を決定する。左を指す（左の握りこぶしに向かって）と最初のスライドへジャンプする。右を指す（右の握りこぶしに向かって）と最後のスライドへジャンプする。

オーバービュー機能にともない、ブラウザはすべてのスライドをグリッドで表示する。オーバービューに入るために、ユーザは両手をシネマトグラファのジェスチャで指す。シネマトグラファもしくはゴールポストはユーザを外観から抜け出させ、最後に表示されたスライドへ戻らせる。プッシュバックはユーザがスライドにわたってスクロールし、連続した水平なデッキに表示するために異なるスライドを選択することを許可する。

（スクロールジェスチャ／機能 ― プッシュバック）
ブラウザのスクロール機能は、ユーザが高速かつ正確に、デッキであるスライドの水平なコレクションを横切ることを可能にする。プッシュバックとジョグダイヤルの２つのジェスチャは、はスクロールに似た性能を成立させる。ここでのこれらの説明は、メディアブラウザアプリケーションが、どのようにユーザの代わりに空間を割り当てるか、そしてユーザの移動をどのように画像表示に関連づけるか、についてのコメントを含む。

関連出願は、プッシュバックが、ユーザの相互作用をどのように量子化された―「戻り止めされた」―空間で構成するか、を説明する。パラメータ制御を空間次元に関連付けることで、ユーザは高速にコンテキストを得ることが許可される。具体的には、メディアブラウザにおいて、データセットの要素を備えるスライドは、同一直線上にあり、横方向に並べられる。このデータ空間は、ｚ方向における単一の自然な戻り止めと、複数のｘの戻り止めとを含む。プッシュバックはこれらの２つを結び付ける。

このプッシュバックのスキーマは、深度次元を２つのゾーンに分ける。「デッド」ゾーンはディスプレイからより遠い半分の空間である。「アクティブ」ゾーンはディスプレイにより近い半分の空間である。水平面に沿った、可視のスライドの左または右に対して、その同一直線上の規則的間隔で設けられたデータフレームが存在する。

ユーザは、スライド上にいるとき、オープンパーム（｜｜｜｜−：ｘ＾）を形成する。その点を空間に登録しているシステムは、２つの同心のグリフを備えるレチクル（十字線）を表示する。このより小さい内径のグリフは、この手がデッドゾーンにあることを示す。このグリフは、ユーザがその手をデッドゾーンで前および後ろに動かすにつれて、大きくおよび小さくなる。ユーザの手のひらと画面との間で利用可能な距離を拡張するために、ユーザはユーザの手を後ろに引くことができる。内側のグリフは、所定の閾値に達するまでサイズを小さくし、リングの表示は安定する。

任意の時間に、ユーザはｚ軸方向に押すことができる。ユーザが、アクティブゾーンからデッドゾーンを分離する閾値を横切る場合、システムはプッシュバックを引き起こす。システムはこの閾値に関連する手のｚ値を測定し、これとここで記述されるスケーリング関数との対応を生成する。この結果の値は、データフレームとその横方の近傍のｚ軸の変位を生み出す。画像フレームは、あたかも奥行きに押しのけられるように、ディスプレイから後退する。メディアブラウザにおいて、この効果は、個々のスライドのスライド列への後退である。ユーザが押したり引いたりするにつれ、ｚの変位は連続的に更新される。この効果は、横方向に配置され、ユーザの移動に直接反応して後退および接近する、スライドセットである。

このグリフはまた、ユーザがプッシュバックの閾値を横切るときに変化する。スケーリングベースのディスプレイから、それは回転モードへと変化する。すなわち、閾値からの手の物理的なｚ軸のオフセットは、正の（平面内の）角度オフセットへとマッピングされる。これまで通り、外側のグリフは不変である。内側のグリフは、画面へ向かうかまたは離れる方向の移動に関連し、時計回りまたは反時計回りに回転する。

アクティブゾーンへ入るユーザは、第二の次元の活動を引き起こす。ｘ軸の移動は、同様に、水平なフレームセットのｘ変位に相関づけられる。正の値は、ユーザの手によって操作されて左および右にスライドするデータセット要素―つまりスライド―に対応する。メディアブラウザにおいて、ユーザが右にスクロールするにつれて、グリフは時計回りに回転する。左のスクロールで、グリフは反時計回りに回転する。ユーザは、開いたオープンパームのポーズを崩すことで、プッシュバックを抜け出してスライドを選択する。スライドを選択するために、ユーザはグリフの位置を合わせる。グリフの中心に最も近いスライドがディスプレイに広がる。フレームコレクトが、一つのスライドがディスプレイと同一線上にある、その元々のｚの戻り止めへ跳ね返る。

システムのプッシュバックフィルタの表現が、図１８Ａおよび図１８Ｂに図示されている。要約すると、アプリケーションは、ｚ軸およびｘ軸に対応するコンポーネントへ分離された、手の位置の変位を計算する。オフセットは、オフセットの大きさに依存する係数によりスケーリングされる。係数計算は、横および深さ平面に沿った動きの速度へ結び付けられる。効果的に、小さい速度は減衰され、速い動きは誇張される。

メディアブラウザ内のプッシュバックは２つのコンポーネントを含む。ユーザは、ｚ軸に押し込む前に引き戻すことで、より大きな範囲のｚ軸の押し込みがもたらされることは前述した。ユーザが引き戻すにつれて、システムは変位を計算し、プッシュバックを行うために交差するｚ位置にこの値を適用する。ユーザがジェスチャの終わりの付近でプッシュバックに関与するだけの状況とは対照的に、この結合は効率的なジェスチャ動作を提供する。

さらに、メディアブラウザアプリケーションのプッシュバックは、センサのｚジッタへ適合される。手のひらが、ｚ軸に沿って、より深く／より早く押しこむにつれて、センサはジッタに直面する。センサの公差内での安定した入力を可能にするために、システムは、ジェスチャの最大の深さ範囲を制約する。キオスクのメディアブラウザアプリケーションに実装されたプッシュバックジェスチャフィルターの表現の例は、以下の通りであるが、実施形態はこれに限定されない。

double Pushback::ShimmyFilterCoef(double mag, double dt)
{
const double vel = mag / dt; // mm/s
const double kmin = 0.1;
const double kmax = 1.1;
const double vmin = 40.0;
const double vmax = 1800.0;
double k = kmin;
if (vel＞vmax) k = kmax;
else if (vel＞vmin) k = kmin + (vel-vmin)/(vmax-vmin)*(kmax-kmin);
return k;
}

double Pushback::ShoveFilterCoef(double mag, double dt)
{
const double vel = mag / dt; // mm/s
const double kmin = 0.1;
const double kmax = 1.1;
const double vmin = 40.0;
const double vmax = 1000.0;
double k = kmin;
if (vel＞vmax) k = kmax;
else if (vel＞vmin) k = kmin + (vel-vmin)/(vmax-vmin)*(kmax-kmin);
return k;
}

pos_prv = pos_cur; // new time step so cur becomes prev
const Vect dv = e−＞CurLoc() - pos_prv;
double deltaShove = dv.Dot(shove direc);
deltaShove *= ShoveFilterCoef(fabs(deltaShove), dt);
double deltaShimmy = dv.Dot(shimmy_direc);
deltaShimmy *= ShimmyFilterCoef(fabs(deltaShimmy), dt);

pos eur = pos_prv + shove_direc*deltaShove + shimmy_direc*deltaShimmy;

「Ｓｈｉｍｍｙ」は横方向の動作をカバーし、「Ｓｈｏｖｅ」は前方／後方の動作をカバーする。一実施形態において、ショーブフィルタのｖｍａｘがより小さく、すぐより早い移動に終わることを除き、両方のフィルタは同じである。

一般的に、一実施形態は現在のフレームのための位置オフセット（ｄｖ）を計算し、次にそれをｚ軸およびｘ軸に対応するショーブコンポーネント（ｄｅｌｔａＳｈｏｖｅ）およびシミーコンポーネント（ｄｅｌｔａＳｈｉｍｍｙ）へ分離する。一実施形態は、オフセットの振幅に依存し、複合のオフセットを再構築する係数によって、部分的なオフセットをスケーリングする。

係数が１．０の場合、スケーリングは適用されず、物理的なオフセットは仮想的なオフセットに正確にマッピングされる。（０．０、１．０）の値は動きを減衰させ、１．０より大きい値は動きを増幅させる。

係数計算は、速度が別の範囲（シミーは４０から１８００でショーブは４０から１０００）にある状況に基づく、最小および最大の係数（ここでは０．１と１．１）の間の線形補間である。実際には、これは小さい速度には大きな減衰が適用されるが、速い動きはある程度（たとえば１０％など）増幅されるということを意味する。

図１８Ａは一実施形態における、第一の範囲［０．．．１２００］（全部）に対するショーブフィルタの応答である。図１８Ｂは一実施形態における、第二の範囲「０．．．２００」（ズーム）に対するショーブフィルタの応答である。

（スクロール入力／機能―Ｊｏｇ−Ｄｉａｌ）
Ｊｏｇ−ｄｉａｌは付加的なスクロール作用を提供する。この両手のジェスチャは、ベースと速度制御を提供するシャトルとを持つ。ベースの手はｏｆｐ−オープン（＾＾＾｜−：ｘ＾）で、シャトルの手はｏｆｐ−クローズド（＾＾＾｜＞：ｘ＾）である。システムがジェスチャを検出する際、２００ｍｓにわたってそれらの距離を推定し、次にマップは距離をスライドデッキの水平速度に変える。このジェスチャは、関連出願で記載されたような「デッド」ゾーンまたは中央の戻り止めに頼る。

最小のものを超える任意の距離において、このアプリケーションはこの値を速度へマッピングする。このアプリケーションが画面アセットの大きさを考慮できるように、計算されるパラメータは画面サイズに比例する。これは例えば、ディスプレイ要素がより大きい場合には、より大きい画面における高速な移動を可能にする。この速度はフレームレートによって調節され、シャトルの手の計算された速度に混合される。

キオスクの一実施形態において実装されたｊｏｇ−ｄｉａｌの説明例は以下のようであるが、実施形態はこれに限定されない。

double MediaGallery::ShuttleSpeed(double vel) const
{
double sign = 1.0;
if(vel＜0.0){
sign = -1.0;
vel = -vel;
}
const double a = 200.0;
const double b = 1.0;
const double c = 0.05;
const double d = 140.0;
const double alpha = std::min(1.0, vel/a);

return sign * -shuttleScale * (vel*alpha + (1.0-alpha)*a / (b+exp(-c*(vel-d))));
}

const double detent = 15.0;
double dx = dist - baseShuttleDist;
if (fabs(dx)＜detent) return OB_OK; // central detent
if (dx＜0) dx += detent;
else dx -= detent;

// map hand offset into slide offset
double dt = now - timeLastShuttle;
timeLastShuttle = now;

double offset = ShuttleSpeed(dx) * dt;
shuttleVelocity = offset*0.6 + shuttleVelocity*0.4;

一般的に、一実施形態のＳＯＥキオスクは、作用を開始する際に手の距離（ｂａｓｅＳｈｕｔｔｌｅＤｉｓｔ）を推定し、次におおよそ＋／−１５ｍｍ以内の任意の変化は影響がない（中央の戻り止め）、しかし実施形態はこれに限定されない。ユーザが＋／−１５ｍｍ以上移動する際、（戻り止めの大きさを引いた）距離はＳｈｕｔｔｌｅＳｐｅｅｄ関数によって速度へマッピングされる。アセット自体は物理的により大きいので、より大きな画面ではより早く移動することを自然に感じるように、ｓｈｕｔｔｌｅＳｃａｌｅパラメータは画面サイズに比例する。さらに、速度はフレームレートによって調節され、グローバルなｓｈｕｔｔｌｅＶｅｌｏｃｉｔｙへと融合される。

異なるスケールおよび手の距離にわたりどのようにこの関数が振舞うのかを示す、図１９Ａ−１９Ｃに描かれるように、達成される効果は基本的に線形である。図１９Ａは、一実施形態における、手の距離に関連する速度を表す第一のプロットである。図１９Ｂは、一実施形態における、手の距離に関連する速度を表す第二のプロットである。図１９Ｃは、一実施形態における、手の距離に関連する速度を表す第三のプロットである。この実施形態は一般的に線形で、平均距離は直接速度にマッピングされ、しかし小さな距離に対して、ここで開示される特徴の組み合わせが正確でゆっくりした移動および高速な移動を許可するため、システムはさらなる制御を許可するために、さらにいっそうゆっくり移動できる。

（ｉＰｈｏｎｅ入力）
ＳＯＥの代理人として、メディアブラウザは、異なる装置からの利用可能な低レベルデータを受け入れ、そして反応する。例えば、このブラウザは、ｉＯＳクライアントに対応するｇ−ｓｐｅａｋアプリケーションをダウンロードしたｉＰｈｏｎｅのような装置からの慣性データを受け入れる。このアーキテクチャは、動作のための装置原産の入力を指定することができ、この場合、ダブルタップは、ｇ−ｓｐｅａｋポインタアプリケーションによって提供される「ポインタ」機能に関与する。圧力を維持し、ユーザはスライドにわたってカーソルを追跡できる。

（映像）
このアプリケーションは映像の統合と制御をサポートする。ｏｆｐ−オープン（＾＾＾｜−：ｘ＾）は映像を再生し、握りこぶし（＾＾＾＾＞：ｘ＾）への閉じは一時停止する。再び、このシステムはまたｇ−ｓｐｅａｋポインタアプリケーションで可能になったｉＰｈｏｎｅからのデータのようなデータを受け入れ、ダブルタップは再生を一時停止し、スライドはスクラブを引き起こす。

［アプリケーション―エッジスイート―アップロード、ポインタ、回転］
アプリケーションのスイートは、キオスクのデータ／装置の統合能力を強調する。先ほど述べたように、ＳＯＥは普遍的な空間である。関連出願で記載されたプラズマアーキテクチャは、広範なイベントを探索し受け入れる、データに依存しないプールを構成する。それは堅固で空間的な機能性を提供するために設計および実行される一方、それはまたＳＯＥに接続される装置からの利用可能な低レベルデータを利用する。

アップロード、ポインタ、そして回転のアプリケーションは、根本的にこの環境原産ではない、つまり、装置が明確にＳＯＥのために形成されたのではない装置によって提供された低レベルデータを収集および反応する。エッジ装置は、所望のＳＯＥに接続するためにｇ−ｓｐｅａｋアプリケーションをダウンロードする。ここで記載される機能性は、ｉＯＳまたは任意の他のクライアント向けのｇ−ｓｐｅａｋアプリケーションに限定することなく代表するｇ−ｓｐｅａｋポインタアプリケーションによって提供される。

これらのアプリケーションにおいて、関連するｇ−ｓｐｅａｋアプリケーションを有するｉＯＳ装置は、任意の時刻にＳＯＥに参加でき、そしてこの「外部」代理人からのデータは受け入れられる。そのデータは、定義で制限される低レベルデータである。しかしながら、ＳＯＥはその外部からの調達、プロファイル、または品質に基づいてそれを削除しない。データは、関連出願および本明細書に記載される、プロテイン、プール、スローアーキテクチャを通じて交換される。エッジ装置は、プロテインをプール構造の中に堆積させ、そしてプロテインをプール構造から引き出すことができ、システムはそのようなイベントを情報源に関わらず探す。

一実施形態のこの低レベルデータは２つの形式をとる。第一に、ｉＯＳは、関連する位置を提供する、慣性データを生成する。ＳＯＥはまた、コマンドを画面に直接マッピングする、「タッチパッド」モードを利用する。持続性は、ＳＯＥの堅固な空間的操作であり、それと同時に、ジェスチャの使用は戦略的である。アップロード／回転／ポインタのようなアプリケーションは、制限されない観客がキオスクに作用する、特に一般人の設定のために開発される。このスイートは、次に、使いやすさと、プレゼンテーションのために最適化する、選択された数のジェスチャを選ぶ。

システムのホーム画面に表示される要素は、ｇ−ｓｐｅａｋポインタアプリアイコン、キオスクアプリケーションアイコン、チュートリアル、そしてセンサミラーを含む。ｇ−ｓｐｅａｋポインタアプリアイコンは、ダウンロード情報を提供する。アプリケーションにわたってナビゲートするため、ユーザ入力はプッシュバックである。ユーザのオープンパームを画面に向かって（ｚ軸へ）押されるにつれて、メニューはディスプレイへと後退し、ユーザは高速に追跡する（この例では、水平軸に沿って）。アプリケーションを選択するため、ユーザは所望のアプリケーションの上で一時停止する。「Ｖ」ジェスチャ（＾＾Ｖ＞：ｘ＾）は選択を促す。プッシュバック（｜｜｜｜−：ｘ＾）はアプリケーションにわたって、退出のジェスチャとして用いられる。一度ユーザのオープンパームが距離閾値を横切ると、画面は暗くなり、アセットは消えていく。閉じた握りこぶしを用いて、ジェスチャを壊すことは、退出を引き起こす。

チュートリアルおよびセンサミラーは、このシステムスタート画面を含み、すべての画面の底部付近のパネルに表示される。一般人がキオスクと作用する、この例のスイートが制限されない設定で使用される、本明細書で導入が記載される。チュートリアルおよびセンサミラーはそのような設定に有益な要素である。

チュートリアルは、アプリケーション（およびアプリケーションを用いるための選択内）にわたってナビゲートするための命令を描いたアニメーションセットである。上述したように、センサミラーは、デバッグするメカニズムとして効率的に動作でき、そのフィードバックはユーザが入力に順応する助けとなる。チュートリアルと同様に、それもまたパブリックアクセスにとっても有用である。伝統的なコンピュータを用い、システムはユーザが仕事を起動するまで休止状態である。キオスクで、センサミラーは、ユーザにシステムが関与していることを示すフラグである。ここで述べられるように、情報は匿名化され、深度に限定される。

［アプリケーション―エッジスイート―アップロード］
アップロードは、画像をアップロードまたは見るためのアプリケーションであり、そのデザインは、小売りおよびマーケティングといった設定における、その一般人の使用を反映するが、これに制限されない。それは有名なｉＯＳクライアント動作を展開する。垂直なスワイプはｉＰｈｏｎｅをそのカメラ画面へ切り替え、ユーザは写真を撮る。電話は、ユーザに画像を廃棄または保存するよう促す。ユーザが保存することを選択した場合、ファイルはシステムへアップロードされ、システムはそのコレクションの画像を表示する。システムは、装置によって設定されたデフォルト画像エリアを受け入れ、この値はアプリケーションの管理人によって修正されうる。

デフォルトディスプレイは「ランダム」なもので、画面にわたって画像を分散させる。強調された円は、たった今アップロードされた画像の後ろに現れる。ダブルタップは写真を選択する。ドラッグするために、ユーザはプレッシャーを維持する。画面との指の関与は、キオスクによって受け入れられた慣性データを発行する。

この例では、画像の前面および中央への移動は画像を拡大する。付加的なディスプレイパターンはグリッド、らせんが画面を覆いうる渦巻き、そして放射状の半円を含む。水平方向のスワイプは、これらのディスプレイを循環する（例えば、左は前へ、そして右は次へ）。ダブルタップは、ディスプレイによって回転された画像をらせんまたは放射状に回転する。

ユーザはまた、タッチパッド入力を提供できる。これは画面への（慣性の代わりの）ダイレクトマッピングである。ダブルタップは再度画像を選択し、維持されたプレッシャーは要素を移動させる。スワイプはこの同一の圧力として理解され、２本の指のスワイプは次にディスプレイを循環させる。

［アプリケーション―エッジスイート―ポインタ］
ポインタは、２人までのユーザが関与する、体験的、協調的なアプリケーションである。スワイプがこのアプリケーションを開始する。それぞれのユーザのために、発光性のチェーンリンクグラフィックが表示される。チェーンはそのリンクで曲げられ、ランダムなやり方で巻かれ、角度づけられる。ダブルタップは選択入力であり、プレッシャーを維持することは、まるで指揮するように、ユーザが次にチェーンを動かすのを許可する。

この関与は、遅延および精度の課題を表す、システム環境の周りに設計される。第一に、ユーザは概してワイヤレスネットワークにわたって接続し、遅延に苦しみうる。また、装置によって提供されるデータによってもまた制限される入力で、ユーザの動きは一貫性がなくてもよい。特定のポイントの周りに選択を構築する代わりに、アプリケーションは一般的なエリアでの発生として選択を読む。ユーザが画面にわたってチェーンを回転させるにつれ、視覚的なフィードバックは流動性を持つ。それはこの景観に配慮した、マスクの遅延を強調する。

ポインタアプリケーションはまた、タッチパッド作用も提供する。ダブルタップはエリアを選択し、プレッシャーの維持はポインタを動かす。このアプリケーションは２台までの装置の入力を受け付け、表示する。

［アプリケーション―エッジスイート―回転］
協調的なピンポンゲームのマルチプレイヤは、加速度データの上のジェスチャモーションのレイヤを回転する。この例では、ラチェットモーションがピンポンゲームのパドルを制御する。

開始にあたって表示される、プレイのフィールドは半円である（１８０度）。半円のベースラインで反射するボールは、ユーザによって制御されるパドルである、弧に向かってあるランダムな角度で跳ね返る。各参加者は弧に割り当てられ、その色はそのプレイヤに対応付けられる。プレイヤは、ボールをベースラインに打ち返すようにパドル／弧を動かす。ボールが中央へ跳ね返ってくるたびに、その速度は増える。パドルを打つたびに、パドルはより小さくなる。（この減少は、いくらかの設定された小さい割合で、パドルは消えない。）したがって、このゲームの難易度が上がる。

ダブルタップでゲームに参加する。ユーザは、指でプレッシャーを維持し、パドルをラチェットの動きで回転させる。装置からの放射状の入力は、指が画面上にあるときだけ通過する。パドルは空中で停止し、ユーザがプレッシャーを開放した場合にもボールは依然跳ねる。パドルは、入力のない約１０秒の後に脈を打つ。ユーザがゲームを退出するために移動するとき、ゲームの状態が固まるとともに、ボールを停止させる。

ラチェットの動きは、ユーザの練習の主要因となるように設計される、画面上の視覚をマッピングする。手首が完全に１８０度の回転を提供する一方、「中央」位置から開始するユーザはだいたいどちらかの方向に３０度回転する。この振る舞いの主要因であるこのアプリケーションは、比較的この動きをパドルの制御およびフィードバックへマッピングする。どちらかの方向の最大距離に到達するために、例えばユーザは１８０度を満たすことを求められない。

１つのデザインおよび速度の特徴は、ユーザの関与を拡張する：パドルの大きさは、いつもヒット範囲に直接マッピングされない。ユーザの成功を育成し、体験を繰り返すために、このアプリケーションは、その視覚的に把握されるエリアの外で、所定の条件でパドル機能を拡張する。所定の速度閾値を上回り、ユーザはパドルを高速に動かし、ヒット範囲が増える。「Ａｎｇｅｌｓｉｎｔｈｅｏｕｔｆｉｅｌｄ」効果と類似で、ユーザのバグの知覚を避けるために、この拡張は表示されない。パドルは本当に高速に移動しているため、ユーザの不安はだいたい追随しない。商業的な設定とかかわりがあるアプリケーションごとに、管理人は、弧の広さ、中心から弧の距離、およびボールの速度を含む、ゲームを制御する、テキスト入力で修正される、値を定義する。

［ユースケースの例］
キオスクシステムは、その導入がより容易であり、また、可搬であるため、柔軟性の利点の発生をもたらす。以下のユースケース（使用事案）例は、このようなオペレーション（運用）上の操縦性を際立たせ、前述のベースラインアプリケーションにおいて記載した機能性やジェスチャを引き起こすものである。これらの例は、ＳＯＥキオスクから利益を得るドメインを示すが、これに限られるわけではない。

軍事的状況においては、オペレーションの分野における近時の出来事をレビューするために、ブリーフィングが開催される。キオスクを用いたオペレーション室では、将校が、政治的境界、地形、人的アセット（資源）、人口密度、衛星画像をタッチして、情報の範囲を伝えるためにマッピングアプリケーションを使用する。アセットの位置や衛星画像は、ブリーフィングの性質に適したソースからリンク付けされている。データソースは、ローカルに記憶するか、あるいは、ネットワークを介してアクセスすることができる。将校は、政治的境界データを選択し（パレットジェスチャ、＾＾＾｜−：ｘ＾）、全表示領域にそれをスナップし（シネマトグラファ、＾＾＾｜−：ｘ＾）、その後、アクティビティにおける近時の勃発にズームインする（パン／ズーム、＼／＼／−：ｘ＾から＾＾＾＾＞：ｘ＾へ）。彼は、ディスプレイ左側のフルオロスコープメニューを引き出す（パレット、＾＾＾｜−：ｘ＾）。彼は、まず人口密度レンズを選択（親指を閉じる）、スナップ（シネマトグラファ、＾＾＾｜−：ｘ＾）し、次に、地形レンズを選択、スナップする。これらの領域の輪郭について議論した後、彼は、アクティビティ時におけるアセットの位置に言及するために、押し込む（ズーム、＾＾＾＾＞：ｘ＾）。さらにズームインを行って（＾＾＾＾＞：ｘ＾）、彼は領域表示を拡大し、現在におけるアセットの位置を再検討する。

ハリケーンが海岸線に近づいた場合のように、緊急の準備や対応を伴うユースケースの例においては、政府機関や役人は、勧告を発行し、公衆と情報を共有するために素早く行動する。知事室は、その緊急対応の専門家、気象サービス長、法的措置の担当者、公共事業の職員、並びに、知事室の役人の参加の下で、記者会見を開催する。これらの異なる機関からのデータを集めたキオスクを用いて、記者会見は、風データ、降雨データ、人口密度、避難ルート、及び、緊急避難所を表示した地図を使用する。

採取エンジニアと地質学者は、付加的なユースケースにおいて、土壌サンプル、地下トポロジー、元の底土資源、与えられた底土資源等の、トポロジーに対するレンズを有する地理空間地図を使用して、採取エリアを再検討する。カスタマイズされたアプリケーションには、エッジ装置の認識が含まれる。オペレーションのグローバル地図から、採取エンジニアは、採取エリアの詳細表示に対して押し込む（パン／ズーム、＼／＼／−：ｘ＾から＾＾＾＾＞：ｘ＾へ）。レンズメニューから、採取エンジニアは、与えられた底土資源を選択する（パレット、＾＾＾｜−：ｘ＾）。ネットワークを介して外部データベースからアクセスされると、それは底土資源の現在の表現を表示する。採取エンジニアは、過去のある時点の採取を表示する、元の底土資源のレンズを作成する（フレームイット、＾＾＾｜−：ｘ＾）。地質学者は、ｇ−ｓｐｅａｋポインタアプリケーションがダウンロードされたｉＰｈｏｎｅを使用して、特定の刈り跡を指定する。近時の地質学上の出来事を議論する際に、地質学者は、地下トポロジーレンズを構成し（フレームイット、＾＾＾｜−：ｘ＾）、それを自分自身に向けて引っ張って、地下河川が採取エリアに近づいているディスプレイにフルオロスコープを固定する。そして、地質学者は地図をつかむ（握りこぶし、＾＾＾＾＞：ｘ＾）。地質学者はそれを動かして隣接する領域を地下レンズの下にスライドさせ、２人の同僚は近時のアクティビティについて議論する。

ユースケースのさらなる他の例では、無菌手術室で関節再建治療が２つのキオスクを利用する。一方の画面では、看護師がメディアブラウザのバージョンを制御する。そのデフォルトの概略ディスプレイは、心拍数、血圧、体温、尿、血液等の患者データを示す。第２のキオスクは空間マッピング実装を実行し、これにより執刀医は、Ｘ線、ＣＴスキャン、ＭＲＩ、及び病院で用いられているカスタマイズされた治療ソフトウェアを含むアセットに対して、ズームインすることができる。チームが作業するにあたり、位置決め情報を提供する治療ソフトウェアからの画像が表示される。大腿骨をより詳細に見るために、治療チームの執刀医は、拳を持ち上げ、自分に向けて引きつける（＾＾＾＾＞：ｘ＾）。関連する軟骨において予期しないレベルの抵抗と遭遇した場合、チームの執刀医は、レンズパネルを引きつけ、エリアのＭＲＩ画像を選択する（パレット、＾＾＾｜−：ｘ＾）。

金融サービスセミナーでは、話者はデッキプレゼンテーションを開始する。話者は、あるスライドから次へ移動するために、右をクリックする（クリックＲ、＾＾＾｜−：ｘ＾）。聴衆が完全なポートフォリオ構築について質問を提起した場合、話者は、両手を使って素早く前のスライドに戻るようにナビゲーションし（ジョグダイアル、＾＾＾｜−：ｘ＾）、これによりパイチャートのポートフォリオのコンポーネントが示される。話者は、ｇ−ｓｐｅａｋポインタアプリケーションがダウンロードされた電話を取り出し、その装置をポインタとして使用するために指を押下して、異なる投資型を説明する。話者は、ある投資信託について詳細に時間をかけて説明する。空いている手を使って、話者は、再び異なるスライドへ素早くナビゲーションするが、このときはプッシュバックによる（｜｜｜｜−：ｘ＾）。聴衆は、孫の進学資金を構築することについて尋ねる。話者は、ビデオを用いたスライドへジョグダイアルを行う（＾＾＾｜−：ｘ＾及び＾＾＾｜＞：ｘ＾）。ビデオでは、顧客が、同じ目的について話しており、顧客の様々な金銭的利害を調和させる上で、話者の会社が顧客にとっていかに助けとなったかを述べている。

ラグジュアリーブランドは、ニューヨーク、ロンドン、パリ、東京を含む、主要なデパートの要所にキオスクを導入する。そのハードウェア設置物はブランド価値を反映したものとなり、これには画面の覆いのハイエンドなカスタマイズが含まれる。それは、ブランドの「ルックブック」を展示するとともにキャンペーン広告を行う、メディアブラウザを稼働させる。単純な「Ｌ」字のジェスチャ（＾＾＾｜−：ｘ＾から、＾＾＾｜｜：ｘ＾または＾＾＾｜＞：ｘ＾へ）を用いて、ユーザは、様々なルックスのスライドを通じてクリックすることができる。ビデオスライドは至る所で、スタイリストと写真家が撮影について議論している写真撮影の「舞台裏」映像を上映する。中心となるビデオは、パリでの最新のファッションショーからの映像を上映する。

飲料会社は、新しいエナジードリンクを紹介するために、食料品店のエンドキャップ（商品陳列棚の両端）にキオスクを導入する。経験上、キオスクは、ユーザがあるバージョンの共同回転ゲームで遊べるようにする。母親といっしょに通り過ぎた１０代の少年は、立ち止まってホーム画面上のセンターグラフィックに目をやる。メインのゲームグラフィックでは、パドルが逆回転ないし順回転して、跳ねたボールをブロックする。少年は、画面上部の簡単なインストラクションに従って、無料のｇ−ｓｐｅａｋポインタアプリケーションを自分の電話にダウンロードする。画面下部のチュートリアルグラフィックは、手、電話を押す指、手首の回転を示している。少年はそのジェスチャに従い、親が買い物をしている間に数ラウンドをプレイする。親が戻ると、２人は、プッシュバックを示す（｜｜｜｜−：ｘ＾）、画面下部の他のチュートリアルに従う。このジェスチャは、栄養成分情報を有するスライドを引き出すものである。あるスライドは、地域の有名なスポーツ選手からの拡張した推薦を含む。

（空間的動作環境（ＳＯＥ））
空間的連続入力システムの実施形態を、空間的動作環境（ＳＯＥ）の状況において、ここに説明する。一例として、図２０は、一実施形態における、空間的動作環境（ＳＯＥ）のブロック図である。ユーザは、多数のカメラ（例えば、１以上のカメラまたはセンサ１０４Ａ〜１０４Ｄ）の観察エリア１５０の中に手１０１（あるいは手１０１、１０２）を置く。カメラは、指および手１０１、１０２の位置、姿勢、及び移動を空間追跡データとして検出し、プリプロセッサ１０５への出力信号を生成する。プリプロセッサ１０５は、カメラ出力を、システムのコンピュータプロセッサ１０７へ提供されるジェスチャ信号へ変換する。コンピュータ１０７は、入力情報を使用して１以上の画面カーソルを制御するコマンドを生成し、ビデオ出力をディスプレイ１０３へ提供する。詳しく前述した、リアルタイムで視覚ベースの手追跡システムを初期化するシステム及び方法は、例えば、ＳＯＥや類似のシステムにおいて用いることができる。

単一のユーザの手を入力として用いるシステムを示すが、ＳＯＥ１００は、複数のユーザを用いて実装してもよい。さらに、手に代えて、あるいは、手に加えて、システムは、頭部、足、脚部、腕、肘、膝などを含む、ユーザの身体の（１つまたは複数の）任意の部分を追跡してもよい。

ＳＯＥは、ここに説明する手またはオブジェクトの追跡と形状認識を行う視覚ベースインタフェースを有するが、他の実施形態は、少数のカメラを備えたセンサ、又は、ローカル環境におけるユーザの手の位置、姿勢、及び移動を検出するセンサを使用する。ここに示す実施形態例では、１以上のカメラまたはセンサが、観察エリア１５０内のユーザの手１０１、１０２の位置、姿勢、及び移動を検出するために使用される。ＳＯＥ１００は、ＳＯＥの範囲ないし精神から離れることなく、より多数（例えば、６台のカメラ、８台のカメラ等）または少数（例えば、２台のカメラ）のカメラまたはセンサを有してもよいことを理解すべきである。さらに、本実施形態例では、カメラまたはセンサが対称的に配置されているが、そのような対称性はＳＯＥ１００において要件とされない。ユーザの手の位置、姿勢、及び移動を許容する、任意の数ないし位置のカメラまたはセンサを、ＳＯＥ１００において使用してもよい。

一実施形態において、使用されるカメラは、グレースケール画像を記録することが可能なモーションキャプチャカメラである。一実施形態において、使用されるカメラは、ＶｉｃｏｎＭＸ４０カメラのような、Ｖｉｃｏｎ社製のカメラである。このカメラは、オンカメラ（撮影中）処理を有し、一秒あたり１０００フレームで画像を撮影することができる。モーションキャプチャカメラは、マーカーの検出および特定を行うことができる。

本明細書の実施形態において、カメラは光検出に用いられるセンサである。他の実施形態では、電磁気、静磁気、ＲＦＩＤ、又は他の任意の適した種類の検出のために、カメラ又は他の検出器を使用してもよい。

プリプロセッサ１０５は、３次元空間点の再構成と骨格点ラベリングを生成する。ジェスチャ変換部１０６は、３次元空間情報とマーカーモーション情報をコンピュータプロセッサが解釈可能なコマンド言語へ変換して、ディスプレイ上のカーソルの位置、形状、及びアクションを更新する。ＳＯＥ１００の他の実施形態では、プリプロセッサ１０５とジェスチャ変換部１０６は、単一の装置に統合されるか、組み合わされる。

コンピュータ１０７は、アップル、デル、または他の任意の適した製造者が製造したもののような、任意の汎用コンピュータとしてもよい。コンピュータ１０７はアプリケーションを実行し、ディスプレイ出力を提供する。他にはマウスないし他の従来技術の入力装置に由来するであろうカーソル情報は、ここではジェスチャシステムに由来する。

（マーカータグ）
ここに記載される実施形態にはマーカーレスで視覚ベースの追跡システムを含まれるが、他の実施形態のＳＯＥは、システムがユーザの手を発見し、それが左手と右手のどちらを観察しているのか、及び、どの指が見えているのかを識別することができるように、ユーザの１本以上の指でマーカータグを使用することを予期する。これにより、システムはユーザの手の位置、姿勢、及び移動を検出することが可能となる。この情報は、多数のジェスチャをシステムが認識し、ユーザによるコマンドとして用いることを可能にする。

一実施形態におけるマーカータグは、基板（本実施形態では人間の手の上の様々な場所に取り付けるのに適している）と、パターンを一意に識別する基板表面上に配置された離散マーカーとを備えた物理タグである。

マーカー及び関連する外部センシングシステムは、正確、精密、高速で、かつ連続的なその三間位置の取得を可能にする、（光学、電磁気、静磁気等の）任意のドメインにおいて動作してもよい。マーカーそれ自体は、（例えば、構造化された電磁パルスを放射することにより）能動的に、または、（例えば、本実施形態のように、光学的に逆反射することにより）受動的に動作してもよい。

各フレームを取得する際に、検出システムは、（カメラ又は他の検出器の可視範囲内にある）機器が設置された作業空間ボリュームに存在するタグからの全てのマーカーを含む、回復された三間位置の集合体である「クラウド」を受信する。各タグ上のマーカーは、十分な多様性を有し、一意のパターンに配置されており、これにより、検出システムは次のタスクを実行することができる。すなわち、（１）回復された各マーカー位置が単一のタグを形成する点の１つかつ１つのみのサブコレクションに割り当てられる、セグメント化、（２）それぞれセグメント化された点のサブコレクションが特定のタグとして識別される、ラベリング、（３）識別されたタグの三空間位置が復元される、ロケーション、及び、（４）識別されたタグの三空間姿勢（オリエンテーション）が復元される、オリエンテーションである。タスク（１）、（２）は、以下に説明し、図２１の一実施形態に示される、マーカーパターンの具体的内容を通じて可能になる。

一実施形態において、タグ上のマーカーは、規則的なグリッド位置の一部に取り付けられている。本実施形態のように、この基本的なグリッドは、伝統的なカルテシアンソートのものでもよいし、あるいは、何か他の規則的な平面モザイク配列（例えば、三角形／六角形のタイル配列）でもよい。グリッドの縮尺及び間隔は、隣接するグリッド位置が混同することのないように、マーカーセンシングシステムの既知の空間解像度に関連して規定される。全てのタグに対するマーカーパターンの選択は、次の制約を満たすべきである。すなわち、どのタグパターンも、回転、変換、あるいは、ミラーリングのいかなる組み合わせを介しても、他のいかなるタグパターンのそれと一致しないことである。ある特定数のコンポーネントマーカーの喪失（または閉塞）が許容されるように、マーカーの多様性および配置がさらに選択されてもよい。任意の変換の後に、障害が生じたモジュールを他のものと混同しないようにすべきである。

ここで図２１を参照すると、多数のタグ２０１Ａ〜２０１Ｅ（左手）及び２０２Ａ〜２０２Ｅ（右手）が示されている。各タグは、長方形であり、本実施形態では５×７のグリッドアレイから構成されている。長方形の形状は、タグの姿勢を判定する助けとなり、鏡映重複の可能性を低下させるために、選択されている。ここに示す実施形態では、各手の各指に対してタグが存在する。ある実施形態では、手につき、１つ、２つ、３つ、または、４つのタグを使用することが適切かもしれない。各タグは、異なるグレースケールまたは色合いのボーダー（縁）を有する。このボーダーの内部には３×５のグリッドアレイが存在する。情報を提供するために、グリッドアレイの中の特定の場所には、（図２１の黒点で示す）マーカーが設けられている。

各パターンを「ありふれた」「一意の」サブパターンにセグメント化することにより、タグのマーカーパターンにおいて適格情報を符号化してもよい。例えば、本実施形態は、２つのとりうる「ボーダーパターン」、すなわち、長方形の境界についてのマーカーの分布を特定している。このようにして、タグの「ファミリー」が定められる。したがって、左手を対象とするタグは全て、タグ２０１Ａ〜２０１Ｅに示される同一のボーダーパターンを使用しうる一方で、右手の指に取り付けられたタグは、タグ２０２Ａ〜２０２Ｅに示されるように異なるパターンが割り当てられうるだろう。このサブパターンは、タグのあらゆる姿勢において、左のパターンが右のパターンと区別できるように選択される。ここに示す例では、左手のパターンは、各コーナー（角）にマーカーを有し、コーナーのグリッド位置から２つめの位置に１つのマーカーを有している。右手のパターンは、２つのコーナーにおいてのみマーカーと、コーナーでないグリッド位置に２つのマーカーを有する。パターンの検査により、４つのマーカーのうち任意の３つが観察できる限り、左手のパターンは、左手のパターンから確実に区別することができることが明らかとなる。一実施形態では、ボーダーの色または陰影もまた利き手の標識として用いることができる。

各タグはもちろん、そのファミリーの共通のボーダー内で配布されたマーカーの、一意の内側パターンをなお採用しなければならない。ここに示す実施形態では、内側グリッドアレイの２つのマーカーは、指の回転や姿勢により重複することなく、１０本の指の各々を一意に識別するのに十分であることがわかる。たとえマーカーの一つが塞がれた場合であっても、タグのパターンと利き手の組み合わせにより、一意の識別子が導かれる。

本実施形態では、グリッド位置が硬質な基板上に視覚的に存在し、これは、逆反射マーカーの各々をその意図する位置に取り付ける（手による）作業の助けとなる。これらのグリッドと意図されたマーカー位置は、ここでは１枚の（当初は）柔軟性のある「収縮性フィルム」である基板上に、カラーインクジェットプリンタにより文字通りプリント（印刷）される。各モジュールはシートから切り離されて、次にオーブン焼きにされ、その間、各モジュールは熱処理により正確で反復可能な収縮を受ける。この手順に続く短いインターバルの間、例えば指の長手方向の湾曲に沿った、冷却タグがわずかに形成されてもよい。その後、基板は適度に硬化し、マーカーは意図されたグリッド点に取り付けられてもよい。

一実施形態では、マーカーそれ自体は３次元であり、接着剤または他の何か適切な手段により基板上に取り付けられた、小さな反射型の球体のようなものである。マーカーが３次元であることは、２次元のマーカーを超えて、検出や発見の助けとなりうる。しかし、ここに記載するＳＯＥの精神ないし範囲から離れることなく、いずれかを用いることができる。

今のところ、タグは、オペレータが装着するグローブに対してベルクロまたは他の適切な手段により取り付けられるか、あるいはそれに代えて、低刺激性の両面テープを用いてオペレータの指に直接取り付けられる。第３の実施形態では、硬質な基板を全て免除し、オペレータの指や手に直接、個々のマーカーを接着するか、あるいは「ペイント」することができる。

（ジェスチャボキャブラリ）
一実施形態のＳＯＥは、手のポーズ、姿勢、手の組み合わせ、及び姿勢の混合を含む、ジェスチャボキャブラリ（語彙）を予期する。ＳＯＥのジェスチャボキャブラリにおいてポーズ及びジェスチャを設計及び通信するために、表記（ノーテーション）言語もまた実装される。ジェスチャボキャブラリは、コンパクトなテキスト形式で運動の連鎖（リンク）の瞬間的な「ポーズ状態」を表すシステムである。連鎖するものは、生物的なもの（例えば人間の手、人間の全身、バッタの脚、または、キツネザルの多関節脊椎）でもよいし、そうではなく、非生物的なもの（例えば、ロボットのアーム）でもよい。いずれの場合も、連鎖は、単純で（脊椎）、あるいは分岐するもの（手）としてよい。ＳＯＥのジェスチャボキャブラリシステムは、任意の具体的な連鎖に対しても、一定長のストリング（文字列）を規定する。そこで、ストリングの「キャラクタ位置」を占める特定のＡＳＣＩＩキャラクタ（文字）の集合体は、連鎖の瞬間的な状態、または「ポーズ」の一意の記述である。

（手のポーズ）
図２２は、一実施形態における、ＳＯＥのジェスチャボキャブラリの一実施形態での手のポーズを示している。ＳＯＥは、手の５本の指の各々が使用されることを想定している。これらの指は、ｐ−小指、ｒ−薬指、ｍ−中指、ｉ−人差し指、ｔ−親指、とコード化される。図２２では、指及び親指についての多数のポーズが定義され、示されている。ジェスチャボキャブラリのストリングは、（この場合は、指の）連鎖において、それぞれ表現可能な自由度に対し、単一のキャラクタ位置を規定する。さらに、そのような自由度の各々は、離散化（または「量子化」）されていると理解されており、これにより、そのストリングの位置において有限数の標準ＡＳＣＩＩキャラクタの一つを割り当てることにより、全範囲の動きを表現することができる。これらの自由度は、身体固有の原点及び座標系（手の裏、バッタの体の中央、ロボットアームのベース、等）に基づき表現される。したがって、よりグローバルな座標系において位置姿勢の連鎖を「全体として」表現するために、少数の追加的なジェスチャボキャブラリのキャラクタ位置が用いられる。

図２２の参照を続けると、ＡＳＣＩＩキャラクタを用いて、多数のポーズが定義および特定されている。ポーズのいくつかは、親指と親指以外の指とで分けられている。この実施形態のＳＯＥは、ＡＳＣＩＩキャラクタそれ自体がポーズを暗示するようなコードを使用している。しかし、暗示的であるか否かにかかわらず、ポーズを示すのには任意のキャラクタを使用してもよい。さらに、表記ストリングに対してＡＳＣＩＩキャラクタを使用する実施形態において、いかなる要件も存在しない。本実施形態の範囲ないし精神から離れることなく、任意の適切なシンボル、数字、又は他の表示を用いてもよい。例えば、望まれるのならば、表記は、指毎に２ビットを使用してもよいし、あるいは、何か他の所望の数のビットを使用してもよい。

丸めた指はキャラクタ「＾」により示されるが、丸めた親指は「＞」により示される。上を指しているまっすぐの指または親指は「｜」で示され、角度がついたものは「＼」または「／」で示される。「−」はまっすぐ横向きを指す親指を示し、「ｘ」は平面内を指す親指を示す。

これらの個々の指と親指の記述を使用することで、本実施形態のスキームを用いて、ロバストな数の手のポーズを定義して書くことができる。各ポーズは、前述のようにｐ−ｒ−ｍ−ｉ−ｔの順で、５つのキャラクタにより表すことができる。図２２は多数のポーズを示しているが、ここでは、少数を実例および例示の方法で説明する。平らで地面に平行に保たれた手は「｜｜｜｜｜」で示される。握り拳は「＾＾＾＾＞」により示される。「ＯＫ」のサインは「｜｜｜＾＞」により示される。

キャラクタストリングは、暗示的なキャラクタを用いる場合、単純な「人間の可読性」の機会を提供する。各自由度を記述するとりうるキャラクタの集合は、一般に、素早い認識と明白な類似性のために目を用いて選択されてもよい。例えば、縦のバー（「｜」）は、おそらく連鎖要素が「まっすぐ」であることを意味するであろうし、エル（「Ｌ」）は９０度の曲がりを意味してよく、アクセント（「＾」）は急な曲がりを示しうるだろう。前述のように、所望の任意のキャラクタないしコーディングを使用してよい。

ここに記載したようなジェスチャボキャブラリストリングを採用する任意のシステムは、ストリングの比較につき計算効率が高いという利益を享受する。任意の特定のポーズの識別又は検索はまさに、所望のポーズのストリングと即座の実際のストリングとの間の「ストリング比較」（例えば、ＵＮＩＸの「ｓｔｒｃｍｐ（）」関数）となる。さらに、「ワイルドカードキャラクタ」の使用により、プログラマまたはシステムデザイナに、追加的ななじみのある効率性及び有効性が提供される。すなわち、その瞬間的な状態が照合に無関係の自由度は、疑問符（「？」）として特定されてもよい。さらなるワイルドカードの意味が割り当てられてもよい。

（姿勢）
指や親指のポーズに加えて、手の姿勢も情報を示すことができる。グローバル空間の姿勢を記述するキャラクタが、透過的に選択されることもできる。姿勢のキャラクタ位置に出現した場合、「＜」、「＞」、「＾」、「ｖ」のキャラクタは、左、右、上、下の概念を示すために用いられてもよい。図２３は、手の姿勢の記述子と、ポーズと姿勢を組み合わせたコードの例を示している。一実施形態において、２つのキャラクタ位置は、まず手のひらの方向を特定し、次に指の方向を（指が真っすぐの場合は、指の実際の曲がりにかかわらず）特定する。これらの２つの位置に対してとりうるキャラクタは、「身体中心の」姿勢の概念を示す。すなわち、「−」、「＋」、「ｘ」、「＊」、「＾」、「ｖ」は、中央、横、前（体から離れる、前方）、後（体から離れる、後方）、頭方（上方）、尾方（下方）を記述する。

一実施形態の表記スキームにおいては、５本指のポーズを示すキャラクタの後にコロンが続き、そして２つの姿勢キャラクタが続いて完全なコマンドポーズを定義する。一実施形態では、開始位置が「ｘｙｚ」ポーズとして参照される。このポーズでは、親指がまっすぐ上を指し、人差し指は前方を指し、中指は人差し指に垂直で、ポーズが右手で作られているときは左を指す。これはストリング「＾＾ｘ｜−：−ｘ」で示される。

「ＸＹＺ−手」は、人間の手のジオメトリを利用して、視覚的に提示された３次元構造の全６次元自由度のナビゲーションを可能にする手法である。この手法は、原理的には指を所望の任意のポーズに保持してもよいように、オペレータの手のバルク解釈と回転のみに依存するものであるが、本実施形態は、人差し指が身体から離れる方向を指し示し、親指は天井に向かって指し示し、中指は左−右を指し示す、静的配置を選ぶ。このように、３本の指が、（大ざっぱではあるが、明らかに明白な意図を持って）三間空間の座標系の互いに直交する３つの軸を記述する。よって、「ＸＹＺ−手」である。

次に、ＸＹＺ−手のナビゲーションは、前述のポーズの、オペレータの身体の前の所定の「ニュートラル位置」に指が保持された手に進む。三間オブジェクト（又はカメラ）の並進三自由度及び回転三自由度へのアクセスが、以下の自然な方法においてもたらされる。すなわち、（身体の自然座標系に対する）手の左右の移動は、計算コンテキストのｘ軸に沿った移動をもたらす。手の上下の移動は、制御されたコンテキストのｙ軸に沿った移動をもたらす。前後の手の移動（オペレータの身体に向かう／離れる）は、コンテキスト内でのｚ軸の動きをもたらす。同様に、人差し指に関するオペレータの手の回転は、計算コンテキストの姿勢の「回転」変化につながる。「ピッチ」、「ヨー」の変化が、それぞれ中指、親指に関するオペレータの手の回転を通じて同じようにもたらされる。

留意すべきは、ここでは「計算コンテキスト」は、ＸＹＺ−手の方法により制御されるエンティティを指すために用いられる−合成三間オブジェクト又はカメラを意味するように見える−が、この手法は、現実世界のオブジェクトの様々な自由度を制御するのに等しく有用であることを理解すべきである。例えば、適切な回転アクチュエータを備えた映像又は映画のカメラのパン／チルト／ロールの制御である。さらに、ＸＹＺ−手の姿勢により利用可能な物理的自由度は、仮想ドメインにおいてさえ文言通りよりもやや低くマッピングされてもよい。すなわち、本実施形態では、ＸＹＺ−手は、大きなパノラマディスプレイ画像へのナビゲーションアクセスを提供するためにも用いられ、オペレータの手の左右、上下の動きは、画像に関する期待された左右又は上下の「パンニング」につながるが、オペレータの手の前後の動きは「ズーミング」制御にマッピングされる。

あらゆる場合において、手の動きと導かれた計算上の並進／移動との間の結合は、直接的（すなわち、オペレータの手の位置または回転のオフセットは、何らかの線形又は非線形の関数を通じて、計算コンテキストにおけるオブジェクト又はカメラの位置又は回転のオフセットへ一対一にマッピングされる）または間接的（すなわち、オペレータの手の位置または回転のオフセットは、何らかの線形又は非線形の関数を通じて、計算コンテキストにおける位置又は回転の一次またはより高次の微分係数へ一対一にマッピングされる。そして、継続的な積分により計算コンテキストの実際の０次の位置／姿勢における静的でない変化がもたらされる。）なものとしてよい。この後者の制御の手段は、ペダルの一定のオフセットがおおよそ一定の車両速度につながる、自動車のアクセルペダルの使用に類似している。

現実世界のＸＹＺ−手の局所的な６次元自由度座標の原点としての役割を果たす「ニュートラル位置」が、次のように設けられてもよい。すなわち、（１）（例えば、囲み部屋に対する）空間における絶対的な位置姿勢として、（２）オペレータの総合位置及び「機首方位」に無関係の、オペレータ自身に対する固定された位置姿勢（例えば、身体の正面８インチ、顎の下１０インチ、肩平面に一致して横方に）として、又は、（３）オペレータの意図的な二次アクションを介して（例えば、ＸＹＺ−手の現在の位置姿勢は、以後、並進及び回転の原点として用いられることを示す、オペレータの「他の」手により定められたジェスチャーコマンドを用いて）双方向に、設けられてもよい。

当該領域内での移動は制御されたコンテキストにおける移動にマッピングされない、ＸＹＺ−手のニュートラル位置に関する「戻り止め」領域（又は「デッドゾーン」）を提供することは更に便利である。

以下のような他のポーズが含まれてもよい。
［｜｜｜｜｜：ｖｘ］は、掌が伏せられ指が前向きの平手（親指が他の指に並行）である。
［｜｜｜｜｜：ｘ＾］は、掌が前向きで指が天井を向いた平手である。
［｜｜｜｜｜：−ｘ］は、掌が身体の中心に向けられ（左手は右、右手は左）、指が前向きの平手である。
［＾＾＾＾−：−ｘ］は、片手のサムアップ（親指が天井を向いている）である。
［＾＾＾｜−：−ｘ］は、前方を向いた銃の手振りである。

（両手の組み合わせ）
一実施形態のＳＯＥは、片手のコマンドないしポーズだけでなく、両手のコマンドないしポーズを予期している。図２４は、ＳＯＥの一実施形態における、両手の組み合わせと関連付けられた表記との例を示している。最初の例の表記を概説すると、「完全停止」は、２つの閉じた握りこぶしを備えることを示している。「スナップショット」の例は、各手の親指と人差し指を伸ばし、親指はお互いに向けて指して、ゴールポスト形状のフレームを規定する、親指、人差し指を有する。「ラダーおよびスロットルの開始位置」は、掌が画面に向けられ、上を向いた親指及びその他の指である。

（姿勢の混合）
図２５は、ＳＯＥの一実施形態における姿勢の混合の一例を示している。ここに示した例では、指のポーズのストリングの後に、複数対の丸括弧で姿勢表記を囲むことにより、混合が示されている。例えば、最初のコマンドは、いずれもまっすぐを指す指の位置を示している。姿勢コマンドの最初の対は、ディスプレイに向けられた平らな掌をもたらし、二番目の対は、画面に向けられた４５度ピッチに回転した手を有する。この例では混合の対が示されているが、ＳＯＥでは任意の数の混合を予期することができる。

（コマンドの例）
図２７／１、図２７／２は、ＳＯＥとともに用いられてもよい多数の可能なコマンドを示している。ここでの議論のいくつかはディスプレイ上のカーソルの制御に関するものであったが、ＳＯＥはそのようなアクティビティに限られない。実際、ＳＯＥは、ディスプレイの状態だけでなく、画面上の任意ないし全てのデータ、及び、データの一部を操作する広範な有用性を有する。例えば、コマンドは、映像メディアの再生中の映像コントロールの代わりに用いられてもよい。コマンドは、一時停止、早送り、巻き戻し等に用いられてもよい。また、コマンドは、画像のズームインないしズームアウト、画像の姿勢の変化、任意の方向へのパン等のために実装されてもよい。また、ＳＯＥは、例えば、オープン、クローズ、保存等のメニューコマンドの代わりに用いられてもよい。換言すれば、想定できる任意のコマンドないしアクティビティは、手のジェスチャで実装することができる。

（動作）
図２６は、一実施形態におけるＳＯＥの動作を示すフロー図である。７０１において、検出システムはマーカーとタグを検出する。７０２において、タグとマーカーが検出されたか否かが判定される。検出されなかったときは、システムは７０１に戻る。タグとマーカーが７０２で検出されたときは、システムは７０３に進む。７０３において、システムは、検出されたタグとマーカーから手、指、ポーズを識別する。７０４において、システムはポーズの姿勢を識別する。７０５において、システムは、検出された単数または複数の手の３次元空間位置を識別する（７０３、７０４、７０５の任意または全てを組み合わせてもよいことにご留意下さい。）。

７０６において、情報は、上述のジェスチャ表記に変換される。７０７において、ポーズが正当か否かが判定される。これは、生成された表記ストリングを用いた単純なストリングの比較により実現されてもよい。ポーズが正当でない場合、システムは７０１に戻る。ポーズが正当である場合、７０８において、システムは、表記と位置の情報をコンピュータへ送信する。７０９において、コンピュータは、ジェスチャに応じてとるべき適切なアクションを判定し、７１０において判定に応じてディスプレイを更新する。

ＳＯＥの一実施形態において、７０１〜７０５は撮影中のプロセッサにより実現される。他の実施形態では、望まれるならば、処理はシステムコンピュータにより実現することができる。

（パースおよび変換）
システムは、下層システムにより復元された低レベルジェスチャのストリームを「パース（構文解析）」及び「変換」し、これらパース及び変換されたジェスチャを、広範なコンピュータアプリケーション及びシステムを制御するために用いることが可能な、コマンド又はイベントデータのストリームに変えることができる。これらの手法及びアルゴリズムは、これらの手法を実装するエンジンとこのエンジンの能力を利用するコンピュータアプリケーションを構築するためのプラットフォームとの両方を提供する、コンピュータコードからなるシステムにおいて具体化されてもよい。

一実施形態は、コンピュータインタフェースにおいて人間の手の豊富なジェスチャを使用することに焦点が向けられているが、身体の他の部分（腕、胴体、脚、頭を含むが、これに限られない）や、キャリパー、コンパス、弾力のある曲線近似器、及び、様々な形状のポインティング装置を含むがこれに限られない、据え付けで関節を有する、様々な種類の手以外の物理的道具により作られたジェスチャを認識することもできる。マーカー及びタグは、所望のように、オペレータが運び使用してもよい、項目及び道具に適用されてもよい。

ここに記載のシステムは、認識しそれに対して作動可能なジェスチャの範囲が豊富であると同時に、アプリケーションへの統合が容易な、ジェスチャシステムの構築を可能にする多数の革新を組み込んでいる。

一実施形態では、ジェスチャパース変換システムは、以下のものを備えている。
１）様々な異なる集約レベルにおいて、ジェスチャを指定する（コンピュータ・プログラムにおいて用いるためのエンコード）コンパクトかつ効率的な方法。
ａ．１つの手の「ポーズ」（手の部分の外形および互いに対する方位）。三次元空間における１つの手の方位および位置。
ｂ．２つの手の組み合わせ。いずれかの手がポーズ、位置、または双方を考慮に入れる。
ｃ．多数の人物の組み合わせ。本システムは２つよりも多い手を追跡することができ、したがって、一人よりも多い事物が協同して（ゲーム・アプリケーションの場合には競合して）目標システムを制御することができる。
ｄ．ポーズが連続して組み合わされる順次ジェスチャ。これらを「動画」ジェスチャと呼ぶ。
ｅ．操作者が空間内の形状を追跡する「書記素」ジェスチャ。
２）所与のアプリケーション・コンテキストに関連があるものの上で、各カテゴリから特定のジェスチャを登録するプログラム技法。
３）登録されているジェスチャを特定することができ、これらのジェスチャをカプセル化するイベントを関連するアプリケーション・コンテキストに配信することができるように、ジェスチャの流れをパースするアルゴリズム。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この物理空間と仮想空間との間における連続変換によって、既存のアプリケーション・プラットフォームでは達成が困難である、または既存のプラットフォーム上で実行するアプリケーション毎に１つ１つ実装しなければならない多数のインターフェース技法の一貫性があり普及する使用が可能となる。これらの技法は、（限定ではないが）以下を含む。
１）「リテラル・ポインティング」の広く行き渡る自然なインターフェース技法としての使用。ジェスチャ・インターフェース環境において手を用いるか、あるいは物理的ポインティング・ツールまたは装置を用いる。
２）画面の移動または再位置決めに対する自動補償。
３）操作者の位置に応じて変化するグラフィクス・レンダリング。例えば、深度の知覚を高めるためにパララックス・シフトをシミュレーションする。
４）実世界位置、方位、状態等を考慮に入れた、画面上表示への物理的オブジェクトの含入。例えば、大きく不透明な画面の前に立っている操作者は、アプリケーションのグラフィクスと、画面の背後にある（そして、恐らく移動しているか、または方位を変えている）スケール・モデルの真の位置の表現との双方を見ることができる。

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

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

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

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

計算オブジェクト及びマッピングを取得し、仮想空間のグラフィック表現を出力するレンダリングスタック。

制御システムからイベントデータ（本実施形態では、システム及びマウス入力からのジェスチャおよびポインティングデータ）を取得し、入力イベントからの空間データを仮想空間における座標にマッピングする入力イベント処理スタック。

ローカルエリアネットワーク上の複数のコンピュータをまたいで稼働するアプリケーションをシステムがホストすることを可能にする「グルー（接着）層」。

（データ表現、推移、入れ替え）
ＳＯＥ又は空間的連続入力システムの実施形態を詳細を後述するサブシステム「スロークス」、「プロテイン」、「プール」を備えた「プラズマ」と呼ばれるシステムを含む、ネットワークベースのデータ表現、推移、入れ替えを備えるものとして説明する。プールおよびプロテインは、プロセス間でまたはプロセスをまたがって共有しようとするデータをカプセル化する、本明細書における方法およびシステムのコンポーネントである。これらのメカニズムはスロークス(slawx)（「スロー（slaw）」の複数形）、プロテイン、およびプールを含む。概して、スロークスは、プロセス間交換について最低レベルのデータ定義を規定し、プロテインは、中間レベルの構造を規定し、問い合わせおよびフィルタリングのためのフックを備えており、プールは高レベルの編成およびアクセス・セマンティクスを規定する。スロークスは、効率的な、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、スロークスをペイロードとして用いる、データ・カプセル化および輸送方式を規定する。プールは、１つのプロセス内部、ローカル・プロセス間、遠隔プロセスまたは分散プロセス間にあるネットワークをまたいだ、そして長期（例えば、ディスク上等における）記憶による、プロテインの構造化された柔軟な集約、順序付け、フィルタ処理、および分散を規定する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

殆どのプロテインは８バイト長またはポインタを必要とする程大きくないので、一般に長さ（とフラグ）および２つのオフセット数値は、プロテインの最初の３バイトを占めるに過ぎない。多くのハードウェアまたはシステム・アーキテクチャでは、最初のバイトを超えるある数のバイトのフェッチ即ちリードは、「自由」である（例えば、１６バイトは、セル・プロセッサの主要バスを介して引き込むには、１バイトと全く同じ数のクロック・サイクルを要する。）。

多くの場合、プロテイン内部において実施態様特定またはコンテキスト特定のキャッシングまたはメタデータを許容することは有用である。オフセットの使用により、プロテインの先頭付近に、任意のサイズの「孔」を作成し、その中にこのようなメタデータを割り込ませることができる。８バイトのメタデータを利用することができる実施態様では、多くのシステム・アーキテクチャ上でこれらのバイトを、長さヘッダをフェッチする毎に１つのプロテインに対して自由に得ることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ Descrips: { point, engage, one, one-finger-engage, hand,
pilot-id-02, hand-id-23 }
Ingests: { pilot-id =＞ 02,
hand-id =＞ 23,
pos =＞ [ 0.0, 0.0, 0.0 ]
angle-axis =＞ [ 0.0, 0.0, 0.0, 0.707 ]
gripe =＞ .. ^||:vx
time =＞ 184437103.29}]

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

[ Descrips: { point, click, one, mouse-click, button-one,
mouse-id-02 }
Ingests: { mouse-id =＞ 23,
pos =＞ [ 0.0, 0.0, 0.0 ]
time =＞ 184437124.80}]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［メザニン相互作用とデータ表現］
前述のように、メズは、その高解像度ディスプレイのトリプティクが共有された作業空間の中心を形成する、新たな協調、ホワイトボード、及びプレゼンテーションの環境である。複数の参加者は、システムの直感的に理解できる空間的ワンド、流動的なブラウザベースのクライアント、及び、自分のポータブル装置を介して作業するで、メズのディスプレイ上の要素を同時に操作する。ラップトップがメズに接続された場合、そのコンピュータの画素はディスプレイトリプティク上に表れ、移動、リスケール、及び、セッションのワークフローへの統合をすることができる。次に、任意の参加者は、トリプティクに「リーチスルー」して、接続された任意のコンピュータ上で稼働しているアプリケーションと直接相互作用することが可能となる。その結果、メズは、伝統的なテレプレゼンスやビデオ会議の強力な補完となる。かつてない複数参加者の制御のフレームワーク内にいずれも存する、協調的ホワイトボード、プレゼンテーションのデザイン及び配信、並びにアプリケーション共有の技術を融合するためである。

より具体的には、メザニンは、互いにリアルタイムに通信及び相互作用するプロセスと装置の生態系である。これらの分離したモジュールは、プラズマという、時間ベースのプロセス内、プロセス間、マシン間のデータ転送のためのオブロングのフレームワークを用いて互いに通信する。以下の説明では、メズの技術的インフラストラクチャの主要コンポーネントと、これらのコンポーネントが互いに相互作用することを可能にするプラズマプロトコルを定義する。

技術用語において、メザニンは、トリプティクへの要素のレンダリング、ワンドや他の装置からの人間の入力の処理、及び、システム全体の状態の保持を担当する、ヨボ・アプリケーションの名前である。これは、クライアントと呼ばれる他の装置から受信した画像を変換する、アセットマネージャと呼ばれる他のヨボ・プロセスに支援される。クライアントは広くは、メズに結合または接続された非ヨボで非メズの装置と定義される。クライアントは、ｉＯＳまたはＡｎｄｒｏｉｄプラットフォームをサポートする、メズｗｅｂアプリケーションおよびモバイル装置を含む。

メズのアーキテクチャ要素は、コア・ヨボ・プロセス、アセットマネージャ、クォーターマスタ、イベンチレータ、ｗｅｂクライアント、及びｉＯＳないしＡｎｄｒｏｉｄのクライアントを含む。単一スレッドのヨボ・プロセスは、全アプリケーションの状態を管理し、全クライアント間の通信を促進する。メズは、クライアントからの要求を仲介し、必要ならばその結果を全クライアントに報告する。ｇ−ｓｐｅａｋプラットフォームにおいて気軽なため、このプロセスは、口語的に「ネイティブアプリケーション」と呼ばれることが多い。メズはセッション状態を制御し、ユーザがドシエ−メズのスライドデッキまたは文書−の選択及びオープンを行うことを許可したり、あるいは、ドシエがすでにオープンしているときはセッションへの参加を許可したりする。また、ネイティブのメズ・プロセスは、全てのグラフィクスをトリプティクにレンダリングし、様々なソース−ワンドやクライアントも同様−からの入力に対する全てのフィードバック・グリフを生成したりもする。

アセットマネージャは、クライアントとネイティブ・メズの両方からの画像コンテンツを処理する。それは、メズとクライアントの両方がアクセスしやすいディスク上の画像ファイルの保持および作成を担当する。また、アセットマネージャは、標準フォーマットへの変換を行ってもよく、メズのアセット及びスライドの、画像サムネイル、スライド解像度画像、及びｚｉｐアーカイブの作成を処理する。

クォーターマスタは、自動的およびユーザコントロールへの応答の両方の場合において、映像及び音声ソースのキャプチャ、符号化、及びトランスコードを行うプロセスのグループを指す。とりわけ、クォーターマスタは、例えば、ＷｅｓｔａｒＨＲＥＤＰＣＩカードからのＤＶＩ入力をキャプチャ及び符号化するために用いられるが、これに限られるわけではない。メズのハードウェアは４つのＤＶＩ入力を有し、メズのソフトウェアはクォーターマスタと連携して映像を流す。

イベンチレータは、メザニンの「パススルー」の特徴を可能にする。一実施形態のイベンチレータは、ユーザがそのコンピュータ（例えば、ラップトップコンピュータ等）上で稼働することができるアプリケーションである。イベンチレータＧＵＩは、ユーザがそのラップトップをメズの映像フィードと関連付け、それにより他のミーティング参加者がそのマウスカーソルを制御できるようにすることを可能にする。

メズｗｅｂアプリケーションは、ユーザがｗｅｂブラウザを介してディスプレイのトリプティクと相互作用することを可能にする。リーチスルーと呼ばれる一実施形態の仕組みを用いて、ｗｅｂクライアントは、そのマウスを全権限が付与されたマウスカーソルとして使用することができる。ｗｅｂクライアントはまた、デッキのスクロール、スライド及び画像コンテンツのアップロード、及び、映像フィードのソース及びボリュームの調整を行うこともできる。ｗｅｂクライアントは、要求はペンディングのまま、一時的に、自分の状態をメズとは独立に設定することができるが、メズには常にアプリケーション状態に影響させるべきである。ｗｅｂクライアントは、プラズマ・プールを介してメズとの同期を保つ。

ｉＯＳまたはＡｎｄｒｏｉｄを有するモバイル端末は、セッションが有効なときは、トリプティクの最小ビューを有するメズクライアントへのアクセス、スライドのアップロード、及び、スライドのデッキを通じたスクロールを行うことができる。モバイル装置のクライアントは、同一のプラズマプロトコルを使用して、ｗｅｂクライアントとしてネイティブアプリケーションと通信する。

メズは、プロテインを用いて促進される多数のクライアントの相互作用を可能にし、また、包含する。一実施形態において、メズは、経験のコンポーネントとして識別されたクライアントの集合をサポートする。これらのクライアントは、ｉＯＳ装置（例えば、ｉＰａｄ、ｉＰｈｏｎｅ、ｉＰｏｄ等）だけでなく、任意のｗｅｂブラウザにおいて稼働する１以上のｗｅｂクライアントを含む。メズは、セッションへの参加が、メズ、及び、それが属する空間に存在するものの参加に加わることを意味する参加型環境である。そのため、文書化されたプロテインのパッセージにより引き起こされた任意のアクションは、メズのセッションに参加している他者によっても観察され、経験されることになる。

本明細書で詳述するプロテインは、メズ内で用いられるその部分集合と、さらに本明細書で提示されるフロー図内で参照されるその部分集合を備える。本明細書では、クライアントから又はクライアントへ通過するそのようなプロテインについてのみ説明する。本明細書に提示されるフロー図は、ありうる全てのエラー状態を含んでいるわけではない。もっとも、本明細書に記載されるプロテインは、文書化されたアクションから生じてもよいエラープロテインを備える。

スロークス、プロテイン、及びプールに関して本明細書に記載するように、スロークスは、プラズマ・ライブラリの最下レベルである。スロークスは一データ単位を表し、符号なし６４ビット整数、複素数、ベクトル、ストリング、あるいはリストのような、多くの種類のデータを格納することができる。プロテインはスロークスから作成または生成され、プロテインはアモルファスの（一定の形を持たない）データ構造を備える。

プロテインは、ディスクリップおよびインジェストを含む２つのコンポーネントを有する。ディスクリップはスローのストリングであることが想定され、インジェストはキー−値の対であることが想定されているが、これらの期待は厳格に実施されなくてもよい。ここで、キーとは、アクセスを促進するストリングである。

あらゆるプロテインは、ディスクリップのリストを備える。ディスクリップは、プロテインを識別するスキーマと考えることができる。ディスクリップのリストに与えられたスキーマに基づいて、プロテインが備えるインジェストの集合は、一般に推論することができる。しかし、本明細書に記載のように、プロテインに対する規則は緩やかに実施されてよいため、単一のスキーマや、あるいは、少数のプロテインに対するインジェストの、正当で直交する数個の集合にマッピングする、ディスクリップのリストを有することも可能である。ディスクリップはマップを備えることはできないが、フィルタをＯＮにするために、キー：値のデータを提供することはできる。ディスクリップがコロン（：）で終わる場合、リスト中の次のディスクリップは、その対応する値を表すことが想定されている。プールに参加しているクライアントは、ディスクリップのリストに基づいてプロテインをフィルタリングして、その特定のフィルタ集合にマッチするもののみに新陳代謝−すなわち、処理を選択−することができる。

インジェストはキー：値の対の集まりを備えたマップを含み、これはデータが存在する場所である。あなたがディスクリップを封筒に殴り書きされた非常にルーズな形式のアドレスと考えたとしたら、たとえ複数の受取人に届いてもよいとしても、そのときはインジェストがレターの中と考えることができる。

プールは、預けられた時間で線形に順序づけられた、プロテインに対する移送と不変の記憶機構である。プールは、プロテインを介して通信するためのプロセスの手段である。

本明細書に記載のプロテインは、視認性に役立つ擬似コードシンタックス（構文）で示される。このシンタックスは、プラズマの実装でプロテインがとる実際の形式を反映したものではないので、プロテインは、プラズマライブラリＡＰＩ（ｌｉｂＰｌａｓｍａＡＰＩ）を使用して構築されなければならない。

以下、多くのメザニン・プロテインで参照されるドキュメンテーション・スタイルと少数のキー値を説明する。

ブレース（中括弧）−｛｝−は、キー：値の対のリストを含むマップを表すために、ドキュメンテーションにわたり用いられる。マッピングはインジェスト内でのみ許されるが、ネスト化されてもよい。所与のプロテインに対するインジェストの集合はマップであるが、第一次のブレースは表示の明確さのため省略される。

ブラケット（角括弧）−［］−は、リストを表すために、ドキュメンテーションにわたり用いられる。ディスクリップとインジェストの両方は、ネスト化されてもよいリストを備えてもよい。所与のプロテインに対するディスクリップの集合はリストであるが、第一次のブラケットは表示の明確さのため省略される。

ディスクリップとインジェストの両方は変数を備えてもよい。変数は、例えば＜変数名＞のように、小なり（＜）と大なり（＞）のシンボルの間に含まれるストリングにより表される。いくつかのインジェストは、特定のストリングのみを値として受け入れてもよい。これらの例において、全ての取り得る値は、列挙され、論理ＯＲシンボル（｜｜）により分離される。例えば、原色：赤｜｜黄｜｜青のように。

ほとんどのディスクリップはストリングである。全てのキーはストリングであるか、またはストリングであるべきである。インジェスト内の多くの値もストリングである。このドキュメンテーションでは余分なシンタックスを避けるために、特定の例の場合を除き、引用符（"）はストリングの周囲で省略されるのが一般的である。

多くのインジェストは数値を許容し、＜ｉｎｔ＞や＜ｆｌｏａｔ＞のように表されることが多い。ある範囲の値のみが許されるときは、その範囲は変数内で示される。例えば、＜ｆｌｏａｔ：［０，１］＞はパーセンテージを示し、＜ｉｎｔ：［０，ｍａｘ］＞は正の整数を示す。

いくつかのインジェストは、例えばｖ３ｆ＜ｘ，ｙ，ｚ＞またはｖ２ｆ＜ｗ，ｈ＞のような、その型に適合する省略フォームと、それに続くマルチパートの変数代入とにより表される、ベクトルを許容する。

一実施形態の共通スロー変数は、以下のものを含むが、これに限られるわけではない。すなわち、＜クライアントｕｉｄ＞（クライアントの固有ｉｄ、例えば、ブラウザ−ｘｘｘ・・・あるいはｉＰａｄ−ｘｘｘ・・・）、＜トランザクション番号＞（対応する応答が単調増加整数として含む、要求の固有識別子）、＜ドシエｕｉｄ＞（ドシエの固有ｉｄ、ｄｓ−ｘｘｘ・・・のフォームを有する）、＜アセットｕｉｄ＞（アセットの固有ｉｄ、ａｓ−ｘｘｘ・・・のフォームを有する）、＜ｕｔｃタイムスタンプ＞（Ｕｎｉｘエポックタイム）、＜タイムスタンプ＞（ｓｔｒｆｔｉｍｅで取得される人間が読めるタイムスタンプ）を含む。

図４１は、一実施形態における、メズファイルシステムのブロック図である。

図４２〜図８５は、一実施形態における特徴によるメズプロテイン通信のフロー図である。

図４２は、一実施形態においてメズがクライアントとのハートビートを開始するための、メズ・プロセスのフロー図である。

図４３は、一実施形態において、クライアントがメズとのハートビートを開始するための、メズ・プロセスのフロー図である。

図４４は、一実施形態において、クライアントがセッションへの参加を要求するための、メズ・プロセスのフロー図である。

図４５は、一実施形態において、クライアントがセッションへの参加を要求するための、メズ・プロセスのフロー図（最大）である。

図４６は、一実施形態において、メズがドシエを新規作成するための、メズ・プロセスのフロー図である。

図４７は、一実施形態において、クライアントが新規のドシエを要求するための、メズ・プロセスのフロー図である。

図４８は、一実施形態において、クライアントが新規のドシエを要求するための、メズ・プロセスのフロー図（エラー１）である。

図４９は、一実施形態において、クライアントが新規のドシエを要求するための、メズ・プロセスのフロー図（エラー２、３）である。

図５０は、一実施形態において、メズがドシエをオープンするための、メズ・プロセスのフロー図である。

図５１は、一実施形態において、クライアントがドシエのオープンを要求するための、メズ・プロセスのフロー図である。

図５２は、一実施形態において、クライアントがドシエのオープンを要求するための、メズ・プロセスのフロー図（エラー１）である。

図５３は、一実施形態において、クライアントがドシエのオープンを要求するための、メズ・プロセスのフロー図（エラー２）である。

図５４は、一実施形態において、クライアントがドシエ名の変更を要求するための、メズ・プロセスのフロー図である。

図５５は、一実施形態において、クライアントがドシエ名の変更を要求するための、メズ・プロセスのフロー図（エラー１）である。

図５６は、一実施形態において、クライアントがドシエ名の変更を要求するための、メズ・プロセスのフロー図（エラー２）である。

図５７は、一実施形態において、メズがドシエを複製するための、メズ・プロセスのフロー図である。

図５８は、一実施形態において、クライアントがドシエを複製するための、メズ・プロセスのフロー図である。

図５９は、一実施形態において、クライアントがドシエを複製するための、メズ・プロセスのフロー図（エラー１）である。

図６０は、一実施形態において、クライアントがドシエを複製するための、メズ・プロセスのフロー図（エラー２、３）である。

図６１は、一実施形態において、メズがドシエを削除するための、メズ・プロセスのフロー図である。

図６２は、一実施形態において、クライアントがドシエを削除するための、メズ・プロセスのフロー図である。

図６３は、一実施形態において、クライアントがドシエを削除するための、メズ・プロセスのフロー図（エラー）である。

図６４は、一実施形態において、メズがドシエをクローズするための、メズ・プロセスのフロー図である。

図６５は、一実施形態において、クライアントがドシエをクローズするための、メズ・プロセスのフロー図である。

図６６は、一実施形態における、新規スライドのための、メズ・プロセスのフロー図である。

図６７は、一実施形態において、スライドを削除するための、メズ・プロセスのフロー図である。

図６８は、一実施形態において、スライドを整列するための、メズ・プロセスのフロー図である。

図６９は、一実施形態における、新規ウィンドシールドアイテムのための、メズ・プロセスのフロー図である。

図７０は、一実施形態において、ウィンドシールドアイテムを削除するための、メズ・プロセスのフロー図である。

図７１は、一実施形態における、ウィンドシールドアイテムの変倍／移動／フルフェルドのための、メズ・プロセスのフロー図である。

図７２は、一実施形態における、スライドのスクロール／プッシュバックのための、メズ・プロセスのフロー図である。

図７３は、一実施形態において、ｗｅｂクライアントがデッキスクロールをするための、メズ・プロセスのフロー図である。

図７４は、一実施形態における、ｗｅｂクライアントのプッシュバックのための、メズ・プロセスのフロー図である。

図７５は、一実施形態において、ｗｅｂクライアントがラチェットのパスフォワードをするための、メズ・プロセスのフロー図である。

図７６は、一実施形態における、新規アセット（ピクセルグラブ）のための、メズ・プロセスのフロー図である。

図７７は、一実施形態において、クライアントがアセット／スライドをアップロードするための、メズ・プロセスのフロー図である。

図７８は、一実施形態において、クライアントがアセット／スライドを直接アップロードするための、メズ・プロセスのフロー図である。

図７９は、一実施形態において、ｗｅｂクライアントがアセット／スライドをアップロードするための、メズ・プロセスのフロー図（タイムアウト発生）である。

図８０は、一実施形態において、ｗｅｂクライアントがアセットをダウンロードするための、メズ・プロセスのフロー図である。

図８１は、一実施形態において、ｗｅｂクライアントが全アセットをダウンロードするための、メズ・プロセスのフロー図である。

図８２は、一実施形態において、ｗｅｂクライアントが全スライドをダウンロードするための、メズ・プロセスのフロー図である。

図８３は、一実施形態において、ｗｅｂクライアントがアセットを削除するための、メズ・プロセスのフロー図である。

図８４は、一実施形態において、ｗｅｂクライアントが全アセットを削除するための、メズ・プロセスのフロー図である。

図８５は、一実施形態において、ｗｅｂクライアントが全スライドを削除するための、メズ・プロセスのフロー図である。

図８６〜図１１５は、一実施形態におけるメズプロテインに対するプロテイン仕様である。

図８６は、一実施形態におけるメズプロテイン仕様（参加）の一例である。

図８７は、一実施形態におけるメズプロテイン仕様（状態要求）の一例である。

図８８は、一実施形態におけるメズプロテイン仕様（ドシエ新規作成）の一例である。

図８９は、一実施形態におけるメズプロテイン仕様（ドシエオープン）の一例である。

図９０は、一実施形態におけるメズプロテイン仕様（ドシエ名変更）の一例である。

図９１は、一実施形態におけるメズプロテイン仕様（ドシエ削除）の一例である。

図９２は、一実施形態におけるメズプロテイン仕様（ドシエクローズ）の一例である。

図９３は、一実施形態におけるメズプロテイン仕様（画像アップロード）の一例である。

図９４は、一実施形態におけるメズプロテイン仕様（新規ドシエ）の一例である。

図９５は、一実施形態におけるメズプロテイン仕様（ドシエオープン済み）の一例である。

図９６は、一実施形態におけるメズプロテイン仕様（ドシエ名変更済み）の一例である。

図９７は、一実施形態におけるメズプロテイン仕様（ドシエ削除済み）の一例である。

図９８は、一実施形態におけるメズプロテイン仕様（ドシエクローズ済み）の一例である。

図９９は、一実施形態におけるメズプロテイン仕様（デッキ状態変化済み）の一例である。

図１００は、一実施形態におけるメズプロテイン仕様（新規アセット）の一例である。

図１０１は、一実施形態におけるメズプロテイン仕様（プロテイン参加可能）の一例である。

図１０２は、一実施形態におけるメズプロテイン仕様（プロテイン参加不可）の一例である。

図１０３は、一実施形態におけるメズプロテイン仕様（全状態応答（ポータル））の一例である。

図１０４は、一実施形態におけるメズプロテイン仕様（全状態応答（ドシエ））の一例である。

図１０５は、一実施形態におけるメズプロテイン仕様（ドシエ新規作成（エラー））の一例である。

図１０６は、一実施形態におけるメズプロテイン仕様（ドシエ新規作成（エラー））の他の例である。

図１０７は、一実施形態におけるメズプロテイン仕様（ドシエオープン（エラー））の一例である。

図１０８は、一実施形態におけるメズプロテイン仕様（ドシエ名変更（エラー））の一例である。

図１０９は、一実施形態におけるメズプロテイン仕様（ドシエ削除（エラー））の一例である。

図１１０は、一実施形態におけるメズプロテイン仕様（ドシエ削除（エラー））の他の例である。

図１１１は、一実施形態におけるメズプロテイン仕様（画像準備完了（エラー））の一例である。

図１１２は、一実施形態におけるメズプロテイン仕様（画像アップロード（成功））の一例である。

図１１３は、一実施形態におけるメズプロテイン仕様（画像アップロード（エラー））の一例である。

図１１４は、一実施形態におけるメズプロテイン仕様（画像アップロード（部分的成功））の一例である。

図１１５は、一実施形態におけるメズプロテイン仕様（画像準備完了）の一例である。

本明細書に記載の実施形態は、複数のディスプレイ装置と複数のセンサとに結合されたプロセッサを備えたシステムを含む。システムはプロセッサに結合された複数の遠隔クライアント装置を含む。システムはプロセッサに結合された複数のアプリケーションを含む。複数のアプリケーションは、複数のディスプレイ装置と複数の遠隔クライアント装置との少なくとも一つにまたがって複数の遠隔クライアント装置のコンテンツを同時に結集し、複数のディスプレイ装置を同時に制御できるようにする。同時に制御することには、複数のセンサを介して受信されたジェスチャデータから少なくとも一つのオブジェクトのジェスチャを自動的に検出することが含まれる。ジェスチャデータは、ある時空間点における、少なくとも一つのオブジェクトの瞬間状態の絶対的な三空間位置データである。検出することには、ジェスチャデータを集約することと、ジェスチャデータのみを用いてジェスチャを識別することが含まれる。複数のアプリケーションは、ジェスチャをジェスチャ信号に変換し、ジェスチャ信号に応じて、複数のディスプレイ装置と複数の遠隔クライアント装置との少なくとも一つを制御する。

本明細書に記載の実施形態は、複数のディスプレイ装置と複数のセンサとに結合されたプロセッサと、プロセッサに結合された複数の遠隔クライアント装置と、プロセッサに結合された複数のアプリケーションとを備え、複数のアプリケーションは、複数のディスプレイ装置と複数の遠隔クライアント装置との少なくとも一つにまたがって複数の遠隔クライアント装置のコンテンツを同時に結集し、複数のディスプレイ装置を同時に制御できるようにし、同時に制御することには、複数のセンサを介して受信されたジェスチャデータから少なくとも一つのオブジェクトのジェスチャを自動的に検出することが含まれ、ジェスチャデータは、ある時空間点における、少なくとも一つのオブジェクトの瞬間状態の絶対的な三空間位置データであり、検出することには、ジェスチャデータを集約することと、ジェスチャデータのみを用いてジェスチャを識別することが含まれ、複数のアプリケーションは、ジェスチャをジェスチャ信号に変換し、ジェスチャ信号に応じて、複数のディスプレイ装置と複数の遠隔クライアント装置との少なくとも一つを制御する、システムを含む。

本明細書に記載のシステムおよび方法は、処理システムの下で、及び／又は処理システムと共同で、包含及び／又は稼働する。処理システムは、当該技術分野で知られているように、協働するプロセッサに基づく装置あるいはコンピュータ装置、又は、処理システムまたは装置のコンポーネントの、任意の集積を含む。例えば、処理システムは、携帯型コンピュータ、通信ネットワークにおいて動作する携帯型通信装置、及び／又は、ネットワークサーバの、一つ又は複数を含むことができる。携帯型コンピュータは、パーソナルコンピュータ、セルラ電話、携帯情報端末（ＰＤＡ）、携帯型コンピュータ装置、及び、携帯型通信装置から選択された装置の、任意の多数及び／又は組み合わせとすることができるが、これに限られない。処理システムは、より大きなコンピュータシステム内でのコンポーネントを含むことができる。

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

本明細書に記載のシステム及び方法を具体化するシステムコンポーネントは、共に設けることもできるし、あるいは、別の場所に設けることもできる。結果として、本明細書に記載のシステム及び方法を具体化するシステムコンポーネントは、単一システム、複数システム、及び／又は、地理的に離れたシステムのコンポーネントとすることができる。これらのコンポーネントは、単一システム、複数システム、及び／又は、地理的に離れたシステムの、サブコンポーネント又はサブシステムとすることもできる。これらのコンポーネントは、ホストシステム又はホストシステムに結合されたシステムの、１以上の他のコンポーネントに結合することもできる。

通信経路は、システムコンポーネントを結合し、コンポーネント間でファイルを通信または転送する任意の媒体を含む。通信経路は、無線コネクション、有線コネクション、及び、無線／有線のハイブリッドコネクションを含む。通信経路は、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、専用ネットワーク、オフィス間またはバックエンドネットワーク、及び、インターネットを含むネットワークへの、結合又はコネクションをも含む。さらに、通信経路は、フロッピーディスク、ハードディスクドライブ、ＣＤ−ＲＯＭディスクのような着脱可能な固定媒体だけでなく、フラッシュＲＡＭ、ユニバーサルシリアルバス（ＵＳＢ）コネクション、ＲＳ−２３２コネクション、電話線、バス、及び、電子メールメッセージを含む。

文脈が明らかに別のものを要求していない限り、記載の全体にわたり、「備える」「備えている」等の単語は、排他的又は網羅的な意味とは対照的に、両立的な意味で解釈すべきである。つまり、「を含むが、これに限られない。」という意味である。また、単数または複数を用いる単語は、それぞれ、複数または単数も含む。加えて、「ここでは」、「以下では」、「以上」、「以下」および同様の趣旨の単語は、本願のいずれかの特定部分ではなく、本願全体を指す。「又は」という単語が２つ以上の項目のリストに関して用いられる場合、その単語は、次のような単語の解釈全てに及ぶ。すなわち、リストにおける項目のいずれか、リストにおける項目全て、およびリストにおける項目のあらゆる組み合わせに及ぶ。

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

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

Claims

複数のディスプレイ装置と複数のセンサとに結合されたプロセッサと、
前記プロセッサに結合された複数の遠隔クライアント装置と、
前記プロセッサに結合された複数のアプリケーションと
を備え、
前記複数のアプリケーションは、前記複数のディスプレイ装置と前記複数の遠隔クライアント装置との少なくとも一つにまたがって、前記複数の遠隔クライアント装置のコンテンツを同時に結集し、該複数のディスプレイ装置を同時に制御することができるようにし、
前記同時に制御することには、前記複数のセンサを介して受信されたジェスチャデータから少なくとも一つのオブジェクトのジェスチャを自動的に検出することが含まれ、
前記検出することには、前記ジェスチャデータのみを用いて前記ジェスチャを識別することと、当該ジェスチャをジェスチャ信号に変換することと、当該ジェスチャ信号に応じて前記複数のディスプレイ装置を制御することとが含まれる
ことを特徴とするシステム。