(57)【特許請求の範囲】
【請求項１】
少なくとも１つの処理デバイス上において複数のプロセスを実行するステップであって、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップであって、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含んでいる、ステップと、
前記データ・カプセルを複数のプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含んでいる、ステップと、
各プロセスが認識プロセスとして動作するステップであって、前記認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、当該認識プロセスの識別との内少なくとも１つを備えているデータ・カプセルを認識する、ステップと、
前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行するステップと、
を備えている、方法。
【請求項２】
請求項１記載の方法において、データ・カプセルが、データ・メッセージが発生したプロセスの状態情報をさらに含む、方法。
【請求項３】
請求項１記載の方法であって、前記データ・カプセルおよび前記複数のプールを用いて、前記複数のプロセスの各々の動作を調整することによって、前記複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている、方法。
【請求項４】
請求項１記載の方法であって、前記データ・カプセルおよび前記複数のプールの内少なくとも１つを用いて、前記複数のプロセスの動作を調整するステップを備えている、方法。
【請求項５】
請求項１記載の方法であって、アプリケーション・プログラムを１組のプロセスに分割するステップを備えており、前記複数のプロセスが前記１組のプロセスを含む、方法。
【請求項６】
請求項１記載の方法であって、前記複数のプールの内少なくとも１つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている、方法。
【請求項７】
請求項１記載の方法において、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備えている、方法。
【請求項８】
請求項１記載の方法であって、前記複数のプロセスを並列に実行するステップを備えている、方法。
【請求項９】
請求項１記載の方法であって、第１組のプロセスを並列に実行し、第２組のプロセスを順次実行するステップを備えており、前記複数のプロセスが前記第１組のプロセスおよび前記第２組のプロセスを含む、方法。
【請求項１０】
請求項１記載の方法において、前記イベントがプロセス入力を表す、方法。
【請求項１１】
請求項１記載の方法において、前記イベントがプロセス出力を表す、方法。
【請求項１２】
請求項１記載の方法において、前記イベントがユーザ・インターフェース・イベントを備えている、方法。
【請求項１３】
請求項１記載の方法において、前記イベントがグラフィクスイベントを備えている、方法。
【請求項１４】
請求項１記載の方法において、前記イベントがプロセスの状態を表す、方法。
【請求項１５】
請求項１４記載の方法において、プロセスの状態が、当該プロセスのインタラクティブ機能を表し、前記プロセスのインタラクティブ機能を複数のプロセスに、前記データ・カプセルの内容として露出する、方法。
【請求項１６】
請求項１５記載の方法であって、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を関数コールによって定義する代わりに、前記データ・カプセルの内容によって前記複数のプロセスのＡＰＩを定義するステップを備えている、方法。
【請求項１７】
請求項１６記載の方法において、前記データ・カプセルの内容が、アプリケーション独立表現であり、前記複数のプロセスによって認識可能である、方法。
【請求項１８】
請求項１記載の方法において、前記少なくとも１つの処理デバイスが、複数の処理デバイスを備えている、方法。
【請求項１９】
請求項１８記載の方法において、前記複数のプロセスの内少なくとも１つの第１組のプロセスが、前記複数の処理デバイスの内少なくとも１つの第１組の処理デバイスの下で起動し、前記複数のプロセスの内少なくとも１つの第２組のプロセスが、前記複数の処理デバイスの内少なくとも１つの第２組の処理デバイスの下で起動する、方法。
【請求項２０】
請求項１９記載の方法において、前記複数のプロセスが第１プロセスを含む、方法。
【請求項２１】
請求項２０記載の方法であって、前記変換するステップが、前記第１プロセスのイベントを、前記イベントを指定する第１プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項２２】
請求項２１記載の方法において、前記第１プロセス・イベント・データおよび状態情報が、前記第１プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項２３】
請求項２２記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項２４】
請求項２０記載の方法において、前記複数のプロセスが第２プロセスを含む、方法。
【請求項２５】
請求項２４記載の方法において、前記変換するステップが、前記第２プロセスの状態変化イベントを、前記イベントを指定する第２プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項２６】
請求項２５記載の方法において、前記第２プロセス・イベント・データおよび状態情報が、前記第２プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項２７】
請求項２６記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項２８】
請求項２４記載の方法において、前記認識プロセスが前記第２プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記第２プロセスを備えている、方法。
【請求項２９】
請求項２８記載の方法において、前記認識したデータ・カプセルの内容が、前記第１プロセスの状態情報を表すデータである、方法。
【請求項３０】
請求項２９記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも１つの新たなデータ・シーケンスが、前記第１プロセスのイベントおよび前記第２プロセスのイベントの内少なくとも１つを表す、方法。
【請求項３１】
請求項３０記載の方法において、前記少なくとも１つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、前記第１プロセスおよび前記第２プロセスの内少なくとも１つの状態情報とを備えている、方法。
【請求項３２】
請求項３１記載の方法において、前記イベント・データならびに前記第１プロセスおよ
び前記第２プロセスの内少なくとも１つの状態情報が、前記第１プロセスおよび前記第２プロセスの内前記少なくとも１つのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項３３】
請求項３２記載の方法において、前記変換するステップが、前記少なくとも１つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項３４】
請求項３３記載の方法において、前記複数のプロセスが前記少なくとも１つの新たなデータ・シーケンスを用いる、方法。
【請求項３５】
請求項１記載の方法において、前記認識したデータ・カプセルの内容に適した前記処理が、グラフィカル・オブジェクトをレンダリングするステップを含み、前記少なくとも１つの処理デバイスのディスプレイ上に前記グラフィカル・オブジェクトをレンダリングする、方法。
【請求項３６】
請求項３５記載の方法において、前記レンダリングするステップが、直接レンダリングを行い、前記複数のプロセスが前記少なくとも１つの処理デバイスのグラフィクス・レイヤに直接描画を行い、前記複数のプロセス間において前記レンダリングに適するような調整を行うために前記複数のプールを用いる、方法。
【請求項３７】
請求項３５記載の方法において、前記レンダリングするステップが、
レンダリング・コマンドを備えているデータ・カプセルを前記複数のプールに転送するプロセスと、
前記レンダリング・コマンドを前記複数のプールから引き出し、前記レンダリング・コマンドを解釈し、前記レンダリング・コマンドに応答して前記少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブするプロセスと、
を含む、複数のプロセスを備えている、方法。
【請求項３８】
請求項３５記載の方法において、前記レンダリングするステップが、
画素バッファにレンダリングするプロセスと、
生のフレーム・データを前記複数のプールに転送するプロセスであって、前記生のフレーム・データが前記画素バッファへのレンダリングの結果得られる、プロセスと、
前記生のフレーム・データを前記複数のプールから引き出し、前記少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、前記生のフレーム・データを組み合わせるプロセスと、
を含む、複数のプロセスを備えている、方法。
【請求項３９】
請求項１記載の方法であって、
前記複数のプロセスのイベントを検出するステップと、
前記イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップであって、前記イベント・データおよび状態情報が、前記少なくとも１つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
前記少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
を備えている、方法。
【請求項４０】
請求項３９記載の方法において、前記少なくとも１つのデータ・シーケンスを発生する前記ステップが、
第１個別イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように、第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項４１】
請求項４０記載の方法において、前記第１個別データ集合を発生する前記ステップが、前記少なくとも１つの処理デバイスの識別データを含むように、前記第１個別データ集合を形成するステップを含み、前記識別データが、前記少なくとも１つの処理デバイスを識別するデータを含む、方法。
【請求項４２】
請求項４０記載の方法において、前記少なくとも１つのデータ・シーケンスを発生する前記ステップが、
第１個別イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように、第２データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項４３】
請求項４２記載の方法において、前記第１個別データ集合を発生する前記ステップが、第１個別データ集合オフセットを発生するステップを含み、前記第１個別データ集合オフセットが、前記第２データ・シーケンスの前記第１個別データ集合を指し示す、方法。
【請求項４４】
請求項４２記載の方法において、前記第２個別データ集合を発生する前記ステップが、第２個別データ集合オフセットを発生するステップを含み、前記第２個別データ集合オフセットが、前記第２データ・シーケンスの前記第２個別データ集合を指し示す、方法。
【請求項４５】
請求項４０記載の方法において、前記第１個別データ集合が、記述リストであり、この記述リストが、前記データの記述を含む、方法。
【請求項４６】
請求項３９記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項４７】
請求項４６記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項４８】
請求項３９記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項４９】
請求項４８記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項５０】
請求項３９記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように、前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項５１】
請求項５０記載の方法であって、
第１可変長を有する第１オフセットを発生するステップを備えており、
前記第１オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記イベント・データを指し示す、方法。
【請求項５２】
請求項５０記載の方法であって、
第２可変長を有する第２オフセットを発生するステップを備えており、
前記第２オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報を指し示す、方法。
【請求項５３】
請求項５０記載の方法であって、
前記少なくとも１つのオフセットの内第１オフセットを用いて、前記データ・カプセルを通過する第１コード経路を形成するステップと、
前記少なくとも１つのオフセットの内第２オフセットを用いて、前記データ・カプセルを通過する第２コード経路を形成する、ステップと、
を備えており、
前記第１コード経路および前記第２コード経路が異なる経路である、方法。
【請求項５４】
請求項５０記載の方法において、第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
【請求項５５】
請求項３９記載の方法であって、
前記データ・カプセルの長さを含むヘッダを発生するステップと、
前記ヘッダを含むように前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項５６】
請求項３９記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
【請求項５７】
請求項５６記載の方法であって、
前記少なくとも１つの処理デバイスの第２イベントを検出するステップと、
前記複数のプールを検索して、前記第２イベントに対応するデータ・カプセルを求めるステップと、
を備えている、方法。
【請求項５８】
請求項５７記載の方法であって、
前記データ・カプセルと前記第２イベントとの間における対応を特定するステップと、
前記特定に応答して、前記プールから前記データ・カプセルを抽出するステップと、
前記データ・カプセルの内容に応答して、前記少なくとも１つの処理デバイスの代わりに、前記第２イベントに対応する処理動作を実行するステップであって、前記少なくとも１つの処理デバイスが第１タイプのアプリケーションおよび第２タイプのアプリケーションに対応する、ステップと、
を備えている、方法。
【請求項５９】
請求項５６記載の方法において、前記複数のプールが複数のアプリケーションに結合されており、前記複数のプールが、前記複数のアプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記複数のアプリケーションによる前記複数のデータ・カプセルへのアクセスに備えており、前記複数のアプリケーションの内少なくとも２つのアプリケーションが異なるアプリケーションである、方法。
【請求項６０】
請求項５６記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
【請求項６１】
請求項５６記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
【請求項６２】
請求項３９記載の方法において、前記データ構造が、類別されていない、方法。
【請求項６３】
請求項３９記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
【請求項６４】
請求項３９記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
【請求項６５】
請求項３９記載の方法において、前記転送するステップが、第１アプリケーション・タイプを有する第１アプリケーションから少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションに前記データ・カプセルを転送するステップを含み、前記第１アプリケーション・タイプが前記第２アプリケーション・タイプとは異なり、前記少なくとも１つのデータ・シーケンスを発生するステップが、前記第１アプリケーションによって実行され、前記方法が、前記転送するステップの間、前記データ・カプセルの少なくとも１つのデータ・シーケンスをそのまま保持するステップを備えている、方法。
【請求項６６】
請求項６５記載の方法であって、前記第２アプリケーションの動作中、前記少なくとも１つのデータ・シーケンスを用いるステップを備えている、方法。
【請求項６７】
請求項３９記載の方法であって、イベント・データと、前記少なくとも１つの処理デバイスのソース・デバイスの識別データとを含む第１データ集合を発生するステップを備えており、デバイス・イベント・データが、前記ソース・デバイスによって登録されたイベントを指定するデータを含み、前記識別データが、前記ソース・デバイスを識別するデータを含む、方法。
【請求項６８】
請求項６７記載の方法であって、前記イベントの完全な１組の状態情報を含む第２データ集合を発生するステップを備えており、前記第１データ集合および前記第２データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている、方法。
【請求項６９】
請求項６８記載の方法において、前記変換するステップが、前記第１データ集合および前記第２データ集合を含むようにデータ・カプセルを形成することによって、前記第１データ集合および前記第２データ集合をカプセル化するステップを備えており、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項７０】
請求項３９記載の方法であって、
第１タイプのアプリケーションの下で起動する第１処理デバイスのイベントを検出するステップと、
前記第１処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、前記イベント・データが前記イベントおよびこのイベントの状態情報を指定
し、前記イベント・データおよび状態情報が、前記アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で起動する第２処理デバイスの第２イベントを検出するステップであって、前記第２タイプが前記第１タイプとは異なり、前記少なくとも１つの処理デバイスが、前記第１処理デバイスおよび前記第２処理デバイスを含み、
前記データ・カプセルと前記第２イベントとの間における対応を特定するステップと、
前記第２イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップと、
を備えている、方法。
【請求項７１】
請求項７０記載の方法において、前記データ・シーケンスを発生する前記ステップが、
前記イベント・データを含む第１データ集合を発生するステップと、
前記状態情報を含む第２データ集合を発生するステップと、
前記第１データ集合および前記第２データ集合を含むように第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項７２】
請求項７０記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項７３】
請求項７２記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項７４】
請求項７０記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項７５】
請求項７４記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項７６】
請求項７０記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項７７】
請求項７６記載の方法であって、
第１可変長を有する第１オフセットを発生するステップであって、前記第１オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記イベント・データを指し示す、ステップと、
第２可変長を有する第２オフセットを発生するステップであって、前記第２オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報を指し示す、ステップと、
を備えている、方法。
【請求項７８】
請求項７６記載の方法であって、
前記少なくとも１つのオフセットの内第１オフセットを用いて、前記データ・カプセル
を通過する第１コード経路を形成するステップと、
前記少なくとも１つのオフセットの内第２オフセットを用いて、前記データ・カプセルを通過する第２コード経路を形成する、ステップと、
を備えており、
前記第１コード経路および前記第２コード経路が異なる経路である、方法。
【請求項７９】
請求項７６記載の方法において、第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
【請求項８０】
請求項７０記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
【請求項８１】
請求項８０記載の方法であって、
前記複数のプールを検索して、前記第２イベントに対応するデータ・カプセルを求めるステップと、
前記対応を特定したことに応答して、前記プールから前記データ・カプセルを抽出するステップと、
を備えている、方法。
【請求項８２】
請求項８０記載の方法において、前記複数のプールが前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに結合されており、前記複数のプールが、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法。
【請求項８３】
請求項８０記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
【請求項８４】
請求項８０記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
【請求項８５】
請求項７０記載の方法において、前記データ構造が、類別されていない、方法。
【請求項８６】
請求項７０記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
【請求項８７】
請求項７０記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
【請求項８８】
処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを含み、かつ、各プロセスが、対応するプロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
前記複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、データ・メッセージが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変
換されたデータと、前記データ・メッセージを発したプロセスの状態情報とを含む、ステップと、
前記データ・メッセージを、複数のプールの内少なくとも１つのプールに転送するステップであって、各プールが、前記複数のプロセスによって生成されたデータ・メッセージを含んでいる、ステップと、
前記プロセス間において調整を行うステップであって、この調整が、前記複数のプロセスの各プロセスが、前記複数のプールからピア・プロセスの状態情報を引き出すことによって、前記複数のプロセスの前記ピア・プロセスと対等になることを含む、ステップと、
前記複数のプールの内少なくとも１つのプールの１組のデータ・メッセージをインタラクティブに組み合わせることによって、前記複数のプロセスの出力を発生するステップと、
を備えている、方法。
【請求項８９】
複数のプロセスを実行する少なくとも１つの処理デバイスであって、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する少なくとも１つの処理デバイスと、
前記少なくとも１つの処理デバイスに結合されている複数のプールと、
を備えており、
前記少なくとも１つの処理デバイスが、前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを前記複数のプールに転送し、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含み、各プールが、前記複数のプロセスによって生成されたデータ・カプセルを含んでおり、
前記複数のプロセスの各プロセスが、認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、前記認識プロセスの識別との内少なくとも１つを備えているデータ・カプセルを認識し、
前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する、システム。
【請求項９０】
少なくとも１つの処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを含み、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップであって、データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータと、前記データ・カプセルを発したプロセスの状態情報とを含む、ステップと、
前記データ・カプセルを、複数のプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含んでいる、ステップと、
各プロセスが認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、前記認識プロセスの識別との少なくとも１つを備えているデータ・カプセルを認識するステップと、
前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行するステップと、
を備えている、方法。
【請求項９１】
請求項９０記載の方法であって、前記データ・カプセルおよび前記複数のプールを用いて、前記複数のプロセスの各々の動作を調整することによって、前記複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている、方法。
【請求項９２】
請求項９０記載の方法であって、前記データ・カプセルおよび前記複数のプールの内少なくとも１つを用いて、前記複数のプロセスの動作を調整するステップを備えている、方法。
【請求項９３】
請求項９０記載の方法であって、アプリケーション・プログラムを１組のプロセスに分割するステップを備えており、前記複数のプロセスが前記１組のプロセスを含む、方法。
【請求項９４】
請求項９０記載の方法であって、前記複数のプールの内少なくとも１つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている、方法。
【請求項９５】
請求項９０記載の方法の方法であって、前記複数のプロセスを並列に実行するステップを備えている、方法。
【請求項９６】
請求項９０記載の方法であって、第１組のプロセスを並列に実行し、第２組のプロセスを順次実行するステップを備えており、前記複数のプロセスが前記第１組のプロセスおよび前記第２組のプロセスを含む、方法。
【請求項９７】
請求項９０記載の方法において、前記イベントがプロセス入力を表す、方法。
【請求項９８】
請求項９０記載の方法において、前記イベントがプロセス出力を表す、方法。
【請求項９９】
請求項９０記載の方法において、前記イベントがユーザ・インターフェース・イベントを備えている、方法。
【請求項１００】
請求項９０記載の方法において、前記イベントがグラフィクスイベントを備えている、方法。
【請求項１０１】
請求項９０記載の方法において、前記イベントがプロセスの状態を表す、方法。
【請求項１０２】
請求項１０１記載の方法において、プロセスの状態が、当該プロセスのインタラクティブ機能を表し、前記プロセスのインタラクティブ機能を複数のプロセスに、前記データ・カプセルの内容として露出する、方法。
【請求項１０３】
請求項１０２記載の方法であって、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を関数コールによって定義する代わりに、前記データ・カプセルの内容によって前記複数のプロセスのＡＰＩを定義するステップを備えている、方法。
【請求項１０４】
請求項１０３記載の方法において、前記データ・カプセルの内容が、アプリケーションに依存せず、前記複数のプロセスによって認識可能である、方法。
【請求項１０５】
請求項９０記載の方法において、前記少なくとも１つの処理デバイスが、複数の処理デバイスを備えている、方法。
【請求項１０６】
請求項１０５記載の方法において、前記複数のプロセスの内少なくとも１つの第１組のプロセスが、前記複数の処理デバイスの内少なくとも１つの第１組の処理デバイスの下で
起動し、前記複数のプロセスの内少なくとも１つの第２組のプロセスが、前記複数の処理デバイスの内少なくとも１つの第２組の処理デバイスの下で起動する、方法。
【請求項１０７】
請求項９０記載の方法において、前記複数のプロセスが第１プロセスを含む、方法。
【請求項１０８】
請求項１０７記載の方法であって、前記変換するステップが、前記第１プロセスのイベントを、前記イベントを指定する第１プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項１０９】
請求項１０８記載の方法において、前記第１プロセス・イベント・データおよび状態情報が、前記第１プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項１１０】
請求項１０９記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１１１】
請求項１０７記載の方法において、前記複数のプロセスが第２プロセスを含む、方法。
【請求項１１２】
請求項１１１記載の方法において、前記変換するステップが、前記第２プロセスの状態変化イベントを、前記イベントを指定する第２プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項１１３】
請求項１１２記載の方法において、前記第２プロセス・イベント・データおよび状態情報が、前記第２プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項１１４】
請求項１１３記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１１５】
請求項１１１記載の方法において、前記認識プロセスが前記第２プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記第２プロセスを備えている、方法。
【請求項１１６】
請求項１１５記載の方法において、前記認識したデータ・カプセルの内容が、前記第１プロセスの状態情報を表すデータである、方法。
【請求項１１７】
請求項１１６記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも１つの新たなデータ・シーケンスが、前記第１プロセスのイベントおよび前記第２プロセスのイベントの内少なくとも１つを表す、方法。
【請求項１１８】
請求項１１７記載の方法において、前記少なくとも１つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、前記第１プロセスおよび前記第２プロセ
スの内少なくとも１つの状態情報とを備えている、方法。
【請求項１１９】
請求項１１８記載の方法において、前記イベント・データならびに前記第１プロセスおよび前記第２プロセスの内少なくとも１つの状態情報が、前記第１プロセスおよび前記第２プロセスの内前記少なくとも１つのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項１２０】
請求項１１９記載の方法において、前記変換するステップが、前記少なくとも１つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１２１】
請求項１２０記載の方法において、前記複数のプロセスが前記少なくとも１つの新たなデータ・シーケンスを用いる、方法。
【請求項１２２】
請求項９０記載の方法において、前記複数のプロセスが入力プロセスを含み、この入力プロセスが入力イベントを入力デバイスから受ける、方法。
【請求項１２３】
請求項１２２記載の方法において、前記変換するステップが、前記入力デバイスの入力イベントを、前記イベントを指定する入力デバイス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項１２４】
請求項１２３記載の方法において、前記入力デバイス・イベント・データおよび状態情報が、ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項１２５】
請求項１２４記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１２６】
請求項９０記載の方法において、前記複数のプロセスがポインタ・プロセスを含む、方法。
【請求項１２７】
請求項１２６記載の方法において、前記認識プロセスが前記ポインタ・プロセスであり、前記引き出すステップが、前記ポインタ・プロセスが前記複数のプールから前記認識したデータ・カプセルを引き出し、前記認識したデータ・カプセルの内容に適したプロセスを実行するステップを含む、方法。
【請求項１２８】
請求項１２７記載の方法において、前記認識したデータ・カプセルの内容が、入力プロセスからの入力イベントを表すデータである、方法。
【請求項１２９】
請求項１２７記載の方法において、認識データ・カプセルの内容が、前記少なくとも１つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである、方法。
【請求項１３０】
請求項１２９記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも１つの新たなデータ・シーケンスが、ディスプレイに関する前記ポインタ
・オブジェクトの位置を定める、方法。
【請求項１３１】
請求項１３０記載の方法において、前記少なくとも１つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、ポインタ・プロセス・イベントの状態情報とを備えている、方法。
【請求項１３２】
請求項１３１記載の方法において、ポインタ・プロセス・イベント・データおよび状態情報が、前記ポインタ・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項１３３】
請求項１３２記載の方法において、前記変換するステップが、前記少なくとも１つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１３４】
請求項１３３記載の方法において、前記複数のプロセスが、前記ディスプレイ上に前記ポインタ・オブジェクトをレンダリングする際に、前記少なくとも１つの新たなデータ・シーケンスを用いる、方法。
【請求項１３５】
請求項９０記載の方法において、前記複数のプロセスがグラフィカル・プロセスを含む、方法。
【請求項１３６】
請求項１３５記載の方法において、前記変換するステップが、前記グラフィカル・プロセスの状態変化イベントを、前記イベントを指定するグラフィカル・プロセス・イベント・データと、前記イベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項１３７】
請求項１３６記載の方法において、前記グラフィカル・プロセス・イベント・データおよび状態情報が、前記グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項１３８】
請求項１３７記載の方法において、前記変換するステップが、前記少なくとも１つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１３９】
請求項１３５記載の方法において、前記認識するプロセスが前記グラフィカル・プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記グラフィカル・プロセスを備えている、方法。
【請求項１４０】
請求項１３９記載の方法において、前記認識したデータ・カプセルの内容が、前記複数のプロセスの内他のプロセスの状態情報を表すデータである、方法。
【請求項１４１】
請求項１４０記載の方法において、前記状態情報が、空間状態およびモード状態の内少なくとも１つの情報を含む、方法。
【請求項１４２】
請求項１３９記載の方法において、認識データ・カプセルの内容が、前記少なくとも１つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである、方法。
【請求項１４３】
請求項１４２記載の方法において、前記ポインタ・オブジェクトの位置が、グラフィカル・オブジェクトの境界内部にあり、前記グラフィカル・オブジェクトが前記グラフィカル・プロセスによってレンダリングされる、方法。
【請求項１４４】
請求項１４２記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも１つの新たなデータ・シーケンスが、グラフィカル・オブジェクト、前記ポインタ・オブジェクト、および前記ポインタ・オブジェクトと境界との重複の内少なくとも１つを表す、方法。
【請求項１４５】
請求項１４４記載の方法において、前記少なくとも１つの新たなデータ・シーケンスが、前記イベントを指定するグラフィカル・プロセス・イベント・データと、グラフィカル・プロセス・イベントの状態情報とを備えている、方法。
【請求項１４６】
請求項１４５記載の方法において、前記グラフィカル・プロセス・イベント・データおよび状態情報が、前記グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項１４７】
請求項１４６記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１４８】
請求項１４７記載の方法において、前記複数のプロセスが、グラフィカル・オブジェクトおよび前記ポインタ・オブジェクトの内少なくとも１つを前記ディスプレイ上にレンダリングする際に、前記少なくとも１つの新たなデータ・シーケンスを用いる、方法。
【請求項１４９】
請求項９０記載の方法において、前記認識したデータ・カプセルに適した前記処理が、グラフィカル・オブジェクトのレンダリングを含み、前記グラフィカル・オブジェクトが前記少なくとも１つの処理デバイスのディスプレイ上にレンダリングされる、方法。
【請求項１５０】
請求項１４９記載の方法において、前記レンダリングするステップが、直接レンダリングを行い、前記複数のプロセスが前記少なくとも１つの処理デバイスのグラフィクス・レイヤに直接描画を行い、前記複数のプロセス間において前記レンダリングに適するような調整を行うために前記複数のプールを用いる、方法。
【請求項１５１】
請求項１４９記載の方法において、前記レンダリングするステップが、
レンダリング・コマンドを備えているデータ・カプセルを前記複数のプールに転送するプロセスと、
前記レンダリング・コマンドを前記複数のプールから引き出し、前記レンダリング・コマンドを解釈し、前記レンダリング・コマンドに応答して前記少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブするプロセスと、
を含む、複数のプロセスを備えている、方法。
【請求項１５２】
請求項１４９記載の方法において、前記レンダリングするステップが、
画素バッファにレンダリングするプロセスと、
生のフレーム・データを前記複数のプールに転送するプロセスであって、前記生のフレーム・データが前記画素バッファへのレンダリングの結果得られる、プロセスと、
前記生のフレーム・データを前記複数のプールから引き出し、前記少なくとも１つの処
理デバイスのグラフィクス・レイヤをドライブする際に用いるために、前記生のフレーム・データを組み合わせるプロセスと、
を含む、複数のプロセスを備えている、方法。
【請求項１５３】
請求項９０記載の方法であって、
前記複数のプロセスのイベントを検出するステップと、
前記イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップであって、前記イベント・データおよび状態情報が、前記少なくとも１つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
前記少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
を備えている、方法。
【請求項１５４】
請求項１５３記載の方法において、前記少なくとも１つのデータ・シーケンスを発生する前記ステップが、
第１個別イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように、第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項１５５】
請求項１５４記載の方法において、前記第１個別データ集合を発生する前記ステップが、前記少なくとも１つの処理デバイスの識別データを含むように、前記第１個別データ集合を形成するステップを含み、前記識別データが、前記少なくとも１つの処理デバイスを識別するデータを含む、方法。
【請求項１５６】
請求項１５４記載の方法において、前記少なくとも１つのデータ・シーケンスを発生する前記ステップが、
第１個別イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように、第２データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項１５７】
請求項１５６記載の方法において、前記第１個別データ集合を発生する前記ステップが、第１個別データ集合オフセットを発生するステップを含み、前記第１個別データ集合オフセットが、前記第２データ・シーケンスの前記第１個別データ集合を指し示す、方法。
【請求項１５８】
請求項１５６記載の方法において、前記第２個別データ集合を発生する前記ステップが、第２個別データ集合オフセットを発生するステップを含み、前記第２個別データ集合オフセットが、前記第２データ・シーケンスの前記第２個別データ集合を指し示す、方法。
【請求項１５９】
請求項１５４記載の方法において、前記第１個別データ集合が、記述リストであり、この記述リストが、前記データの記述を含む、方法。
【請求項１６０】
請求項１５３記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項１６１】
請求項１６０記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項１６２】
請求項１５３記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項１６３】
請求項１６２記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項１６４】
請求項１５３記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように、前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項１６５】
請求項１６４記載の方法であって、
第１可変長を有する第１オフセットを発生するステップを備えており、
前記第１オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記イベント・データを指し示す、方法。
【請求項１６６】
請求項１６４記載の方法であって、
第２可変長を有する第２オフセットを発生するステップを備えており、
前記第２オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報を指し示す、方法。
【請求項１６７】
請求項１６４記載の方法であって、
前記少なくとも１つのオフセットの内第１オフセットを用いて、前記データ・カプセルを通過する第１コード経路を形成するステップと、
前記少なくとも１つのオフセットの内第２オフセットを用いて、前記データ・カプセルを通過する第２コード経路を形成する、ステップと、
を備えており、
前記第１コード経路および前記第２コード経路が異なる経路である、方法。
【請求項１６８】
請求項１６４記載の方法において、第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
【請求項１６９】
請求項１５３記載の方法であって、
前記データ・カプセルの長さを含むヘッダを発生するステップと、
前記ヘッダを含むように前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項１７０】
請求項１５３記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
【請求項１７１】
請求項１７０記載の方法であって、
前記少なくとも１つの処理デバイスの第２イベントを検出するステップと、
前記複数のプールを検索して、前記第２イベントに対応するデータ・カプセルを求めるステップと、
を備えている、方法。
【請求項１７２】
請求項１７１記載の方法であって、
前記データ・カプセルと前記第２イベントとの間における対応を特定するステップと、
前記特定に応答して、前記プールから前記データ・カプセルを抽出するステップと、
前記データ・カプセルの内容に応答して、前記少なくとも１つの処理デバイスの代わりに、前記第２イベントに対応する処理動作を実行するステップであって、前記少なくとも１つの処理デバイスが第１タイプのアプリケーションおよび第２タイプのアプリケーションに対応する、ステップと、
を備えている、方法。
【請求項１７３】
請求項１７０記載の方法において、前記複数のプールが複数のアプリケーションに結合されており、前記複数のプールが、前記複数のアプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記複数のアプリケーションによる前記複数のデータ・カプセルへのアクセスに備えており、前記複数のアプリケーションの内少なくとも２つのアプリケーションが異なるアプリケーションである、方法。
【請求項１７４】
請求項１７０記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
【請求項１７５】
請求項１７０記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
【請求項１７６】
請求項１５３記載の方法において、前記データ構造が、類別されていない、方法。
【請求項１７７】
請求項１５３記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
【請求項１７８】
請求項１５３記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
【請求項１７９】
請求項１５３記載の方法において、前記転送するステップが、第１アプリケーション・タイプを有する第１アプリケーションから少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションに前記データ・カプセルを転送するステップを含み、前記第１アプリケーション・タイプが前記第２アプリケーション・タイプとは異なり、前記少なくとも１つのデータ・シーケンスを発生するステップが、前記第１アプリケーションによって実行され、前記方法が、前記転送するステップの間、前記データ・カプセルの少なくとも１つのデータ・シーケンスをそのまま保持するステップを備えている、方法。
【請求項１８０】
請求項１７９記載の方法であって、前記第２アプリケーションの動作中、前記少なくとも１つのデータ・シーケンスを用いるステップを備えている、方法。
【請求項１８１】
請求項１５３記載の方法であって、イベント・データと、前記少なくとも１つの処理デバイスのソース・デバイスの識別データとを含む第１データ集合を発生するステップを備えており、デバイス・イベント・データが、前記ソース・デバイスによって登録されたイベントを指定するデータを含み、前記識別データが、前記ソース・デバイスを識別するデータを含む、方法。
【請求項１８２】
請求項１８１記載の方法であって、前記イベントの完全な１組の状態情報を含む第２デ
ータ集合を発生するステップを備えており、前記第１データ集合および前記第２データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている、方法。
【請求項１８３】
請求項１８２記載の方法において、前記変換するステップが、前記第１データ集合および前記第２データ集合を含むようにデータ・カプセルを形成することによって、前記第１データ集合および前記第２データ集合をカプセル化するステップを備えており、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項１８４】
請求項１５３記載の方法であって、
第１タイプのアプリケーションの下で起動する第１処理デバイスのイベントを検出するステップと、
前記第１処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、前記イベント・データが前記イベントおよびこのイベントの状態情報を指定し、前記イベント・データおよび状態情報が、前記アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で起動する第２処理デバイスの第２イベントを検出するステップであって、前記第２タイプが前記第１タイプとは異なり、前記少なくとも１つの処理デバイスが、前記第１処理デバイスおよび前記第２処理デバイスを含み、
前記データ・カプセルと前記第２イベントとの間における対応を特定するステップと、
前記第２イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップと、
を備えている、方法。
【請求項１８５】
請求項１８４記載の方法において、前記データ・シーケンスを発生する前記ステップが、
前記イベント・データを含む第１データ集合を発生するステップと、
前記状態情報を含む第２データ集合を発生するステップと、
前記第１データ集合および前記第２データ集合を含むように第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項１８６】
請求項１８４記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項１８７】
請求項１８６記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項１８８】
請求項１８４記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項１８９】
請求項１８８記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項１９０】
請求項１８４記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項１９１】
請求項１９０記載の方法であって、
第１可変長を有する第１オフセットを発生するステップであって、前記第１オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記イベント・データを指し示す、ステップと、
第２可変長を有する第２オフセットを発生するステップであって、前記第２オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報を指し示す、ステップと、
を備えている、方法。
【請求項１９２】
請求項１９０記載の方法であって、
前記少なくとも１つのオフセットの内第１オフセットを用いて、前記データ・カプセルを通過する第１コード経路を形成するステップと、
前記少なくとも１つのオフセットの内第２オフセットを用いて、前記データ・カプセルを通過する第２コード経路を形成する、ステップと、
を備えており、
前記第１コード経路および前記第２コード経路が異なる経路である、方法。
【請求項１９３】
請求項１９０記載の方法において、第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
【請求項１９４】
請求項１８４記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
【請求項１９５】
請求項１９４記載の方法であって、
前記複数のプールを検索して、前記第２イベントに対応するデータ・カプセルを求めるステップと、
前記対応を特定したことに応答して、前記プールから前記データ・カプセルを抽出するステップと、
を備えている、方法。
【請求項１９６】
請求項１９４記載の方法において、前記複数のプールが前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに結合されており、前記複数のプールが、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法。
【請求項１９７】
請求項１９４記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
【請求項１９８】
請求項１９４記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
【請求項１９９】
請求項１８４記載の方法において、前記データ構造が、類別されていない、方法。
【請求項２００】
請求項１８４記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
【請求項２０１】
請求項１８４記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
【請求項２０２】
アプリケーション・プログラムを複数のプロセスに分割するステップと、
前記複数のプロセスの中にあるプロセスを用いて、前記アプリケーション・プログラムの出力の一部を発生するステップであって、当該プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいる前記一部を生成する、ステップと、
前記出力の前記一部を第１データ・カプセルにカプセル化し、前記第１データ・カプセルを複数のプールの内少なくとも１つに転送するステップであって、前記第１データ・カプセルが、前記出力の前記一部のアプリケーションに依存せずに前記複数のプロセスによって認識可能なイベントの表現であるアプリケーション独立表現に変換された前記一部のデータを含み、前記複数のプールの各プールが、前記複数のプロセスから受け取られる複数のデータ・カプセルを備えている、ステップと、
前記複数のプールにアクセスし、前記複数のプロセスの内第２プロセスの入力を引き出すステップであって、前記入力が前記複数のデータ・カプセルの内第２データ・カプセルの中にある、ステップと、
前記複数のデータ・カプセルおよび前記複数のプールを用いて、前記複数のプロセス間における処理を調整するステップと、
を備えている、方法。
【請求項２０３】
複数のプロセスを実行する少なくとも１つの処理デバイスであって、前記複数のプロセスが複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備え、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、処理デバイスと、
前記少なくとも１つの処理デバイスに結合されている複数のプールと、
を備えており、
前記少なくとも１つの処理デバイスが、前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを前記複数のプールに転送し、
データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現に変換されたデータと、前記データ・カプセルが発したプロセスの状態情報とを含み、各プールが、前記複数のプロセスによって生成されたデータ・カプセルを含み、
各プロセスが認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、前記認識プロセスの識別との内少なくとも１つを備えているデータ・カプセルを認識し、
前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する、システム。
【請求項２０４】
ジェスチャ・データから人が行ったジェスチャを検出するステップであって、前記ジェスチャ・データが検出器を通じて受け取られる、ステップと、
処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスがイベントを発生し、これらイベントが、対応するプロセスのアプリケーションに対応するタイプを有するタイプ特定データを含み、かつ、前記ジェスチャを表す１組のイベ
ントを含む、ステップと、
前記複数のプロセスの各プロセスの前記イベントをデータ・カプセルに変換するステップであって、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含んでいる、ステップと、
前記データ・カプセルを複数のプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含んでいる、ステップと、
を備えており、
前記複数のプロセスの内１組のプロセスが認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、前記ジェスチャに対応するコンテンツを備えているデータ・カプセルを認識し、
前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、前記認識したデータ・カプセルからジェスチャ信号を発生し、前記ジェスチャ信号が前記ジェスチャを表す、方法。
【請求項２０５】
請求項２０４記載の方法において、前記複数のプロセスが、空間動作アプリケーションの分離可能なプログラム実行コンテキストを含む、方法。
【請求項２０６】
請求項２０４記載の方法において、前記ジェスチャ・データが、ある時点および空間におけるユーザの瞬時的状態の絶対三空間位置データである、方法。
【請求項２０７】
請求項２０４記載の方法であって、前記ジェスチャ・データのみを用いて前記ジェスチャを識別するステップを備えている、方法。
【請求項２０８】
請求項２０４記載の方法において、前記検出するステップが、ボディの位置を検出すること、前記ボディの方位を検出すること、および前記ボディの運動を検出することの内少なくとも１つを含む、方法。
【請求項２０９】
請求項２０４記載の方法であって、前記ジェスチャを識別するステップを備えており、前記識別が、ボディの一部のポーズおよび方位の識別を含む、方法。
【請求項２１０】
請求項２０４記載の方法において、前記検出するステップが、ボディの第１組の付属器官および第２組の付属器官の内少なくとも１つを検出するステップを含む、方法。
【請求項２１１】
請求項２０４記載の方法において、前記検出するステップが、ボディに結合されている少なくとも１つのタグの位置を動的に検出するステップを含む、方法。
【請求項２１２】
請求項２１１記載の方法において、前記検出するステップが、前記ボディに結合されている１組のタグの位置を検出するステップを含む、方法。
【請求項２１３】
請求項２１２記載の方法において、前記１組のタグにおける各タグがパターンを含み、前記１組のタグにおける各タグの各パターンが、前記複数のタグにおけるいずれの残りのタグのいずれのパターンとも異なる、方法。
【請求項２１４】
請求項２０４記載の方法において、前記検出するステップが、ボディ上にあるマーカを動的に検出し位置を突き止めるステップを含む、方法。
【請求項２１５】
請求項２１４記載の方法において、前記検出するステップが、前記ボディに結合されている１組のマーカの位置を検出するステップを含む、方法。
【請求項２１６】
請求項２１４記載の方法において、前記１組のマーカが前記ボディ上において複数のパターンを形成する、方法。
【請求項２１７】
請求項２１４記載の方法において、前記検出するステップが、前記ボディの複数の付属器官の各々に結合されている１組のマーカを用いて、前記付属器官の位置を検出するステップを含む、方法。
【請求項２１８】
請求項２０４記載の方法において、前記変換するステップが、前記ジェスチャについての情報をジェスチャ表記に変換するステップを含む、方法。
【請求項２１９】
請求項２１８記載の方法において、前記ジェスチャ表記が、ジェスチャ・ボキャブラリを表し、前記ジェスチャ信号が前記ジェスチャ・ボキャブラリの通信を含む、方法。
【請求項２２０】
請求項２１９記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携の瞬時的ポーズ状態をテキスト形態で表す、方法。
【請求項２２１】
請求項２１９記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携の方位をテキスト形態で表す、方法。
【請求項２２２】
請求項２１９記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携の方位の組み合わせを、テキスト形態で表す、方法。
【請求項２２３】
請求項２１９記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携状態を表す、キャラクタのストリングを含む、方法。
【請求項２２４】
請求項２２３記載の方法において、前記力学的連携がボディの少なくとも１つの第１付属器官である、方法。
【請求項２２５】
請求項２２４記載の方法であって、前記ストリングにおける各位置を第２付属器官に割り当てるステップを備えており、前記第２付属器官が前記第１付属器官に接続されている、方法。
【請求項２２６】
請求項２２５記載の方法であって、複数のキャラクタの中にあるキャラクタを、前記第２付属器官の複数の位置の各々に割り当てるステップを備えている、方法。
【請求項２２７】
請求項２２６記載の方法において、前記複数の位置が、座標原点に対して確定される、方法。
【請求項２２８】
請求項２２７記載の方法であって、空間における絶対位置および方位、ボディの全体的な位置および方位とは無関係のボディに対する固定位置および方位から成るグループから選択された位置を用いて、更にボディのアクションにインタラクティブに応答して、前記座標原点を確立するステップを備えている、方法。
【請求項２２９】
請求項２２６記載の方法であって、前記複数のキャラクタの中にあるキャラクタを、前記第１付属器官の複数の方位の各々に割り当てるステップを備えている、方法。
【請求項２３０】
請求項２２４記載の方法において、前記検出するステップが、ボディの外挿補間位置が仮想空間と交差するときを検出するステップを含み、前記仮想空間が、前記少なくとも１つの処理デバイスに結合されているディスプレイ・デバイス上に描画された空間を含
む、方法。
【請求項２３１】
請求項２３０記載の方法であって、前記外挿補間位置が仮想オブジェクトと交差するときに、前記仮想空間において前記仮想オブジェクトを制御するステップを備えている、方法。
【請求項２３２】
請求項２３１記載の方法において、前記制御するステップが、前記仮想空間における外挿位置に応答して、前記仮想空間における前記仮想オブジェクトの位置を制御するステップを備えている、方法。
【請求項２３３】
請求項２３１記載の方法であって、前記制御するステップが、前記ジェスチャに応答して、前記仮想空間における前記仮想オブジェクトの姿勢を制御するステップを含む、方法。
【請求項２３４】
請求項２０４記載の方法であって、仮想空間と物理空間との間において一致を生じさせるために、前記検出および制御のスケーリングを制御するステップを備えており、前記仮想空間がディスプレイ上に描画された空間を構成し、前記物理空間が、ボディが存在する空間を含む、方法。
【請求項２３５】
請求項２３４記載の方法であって、前記物理空間における少なくとも１つの物理オブジェクトの移動に応答して、前記仮想空間において少なくとも１つの仮想オブジェクトを制御するステップを備えている、方法。
【請求項２３６】
請求項２０４記載の方法であって、前記ジェスチャ信号を用いてコンポーネントを制御するステップを備えており、前記コンポーネントが前記少なくとも１つの処理デバイスに結合されている、方法。
【請求項２３７】
請求項２３６記載の方法において、前記コンポーネントを制御するステップが、前記ジェスチャを三空間オブジェクトにマッピングすることによって、６自由度で同時に三空間オブジェクトを制御するステップを含む、方法。
【請求項２３８】
請求項２３６記載の方法において、前記コンポーネントを制御するステップが、３空間移動自由度および３回転自由度で三空間オブジェクトを制御するステップを含む、方法。
【請求項２３９】
請求項２３８記載の方法において、前記三空間オブジェクトを、前記少なくとも１つの処理デバイスに結合されているディスプレイ・デバイス上に呈示する、方法。
【請求項２４０】
請求項２３８記載の方法において、前記三空間オブジェクトが、コンピュータに結合されている遠隔システムである、方法。
【請求項２４１】
請求項２３８記載の方法であって、前記ジェスチャを前記三空間オブジェクトの複数のオブジェクト平行移動にマッピングすることによって、前記三空間オブジェクトの移動を制御するステップを備えている、方法。
【請求項２４２】
請求項２４１記載の方法において、前記マッピングが、前記ジェスチャと前記複数のオブジェクト平行移動との間における直接マッピングを含む、方法。
【請求項２４３】
請求項２４１記載の方法において、前記マッピングが、前記ジェスチャと前記複数のオブジェクト平行移動との間における間接マッピングを含む、方法。
【請求項２４４】
請求項２０４記載の方法において、データ・カプセルが、データ・メッセージが発生したプロセスの状態情報をさらに含む、方法。
【請求項２４５】
請求項２０４記載の方法であって、前記データ・カプセルおよび前記複数のプールを用いて、前記複数のプロセスの各々の動作を調整することによって、前記複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている、方法。
【請求項２４６】
請求項２０４記載の方法であって、前記データ・カプセルおよび前記複数のプールの内少なくとも１つを用いて、前記複数のプロセスの動作を調整するステップを備えている、方法。
【請求項２４７】
請求項２０４記載の方法であって、アプリケーション・プログラムを１組のプロセスに分割するステップを備えており、前記複数のプロセスが前記１組のプロセスを含む、方法。
【請求項２４８】
請求項２０４記載の方法であって、前記複数のプールの内少なくとも１つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている、方法。
【請求項２４９】
請求項２０４記載の方法において、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備えている、方法。
【請求項２５０】
請求項２０４記載の方法であって、前記複数のプロセスを並列に実行するステップを備えている、方法。
【請求項２５１】
請求項２０４記載の方法であって、第１組のプロセスを並列に実行し、第２組のプロセスを順次実行するステップを備えており、前記複数のプロセスが前記第１組のプロセスおよび前記第２組のプロセスを含む、方法。
【請求項２５２】
請求項２０４記載の方法において、前記イベントがプロセス入力を表す、方法。
【請求項２５３】
請求項２０４記載の方法において、前記イベントがプロセス出力を表す、方法。
【請求項２５４】
請求項２０４記載の方法において、前記イベントがユーザ・インターフェース・イベントを備えている、方法。
【請求項２５５】
請求項２０４記載の方法において、前記イベントがグラフィクスイベントを備えている、方法。
【請求項２５６】
請求項２０４記載の方法において、前記イベントがプロセスの状態を表す、方法。
【請求項２５７】
請求項２５６記載の方法において、プロセスの前記状態が、当該プロセスのインタラクティブ機能を表し、前記プロセスのインタラクティブ機能を複数のプロセスに、前記データ・カプセルの内容として露出する、方法。
【請求項２５８】
請求項２５７記載の方法であって、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を関数コールによって定義する代わりに、前記データ・カプセルの内容によって前記複数のプロセスのＡＰＩを定義するステップを備えている、方法。
【請求項２５９】
請求項２５８記載の方法において、前記データ・カプセルの内容が、アプリケーションに依存せずに、前記複数のプロセスによって認識可能である、方法。
【請求項２６０】
請求項２０４記載の方法において、前記少なくとも１つの処理デバイスが、複数の処理デバイスを備えている、方法。
【請求項２６１】
請求項２６０記載の方法において、前記複数のプロセスの内少なくとも１つの第１組のプロセスが、前記複数の処理デバイスの内少なくとも１つの第１組の処理デバイスの下で起動し、前記複数のプロセスの内少なくとも１つの第２組のプロセスが、前記複数の処理デバイスの内少なくとも１つの第２組の処理デバイスの下で起動する、方法。
【請求項２６２】
請求項２０４記載の方法において、前記複数のプロセスが第１プロセスを含む、方法。
【請求項２６３】
請求項２６２記載の方法であって、前記変換するステップが、前記第１プロセスのイベントを、前記イベントを指定する第１プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項２６４】
請求項２６３記載の方法において、前記第１プロセス・イベント・データおよび状態情報が、前記第１プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項２６５】
請求項２６４記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項２６６】
請求項２６２記載の方法において、前記複数のプロセスが第２プロセスを含む、方法。
【請求項２６７】
請求項２６６記載の方法において、前記変換するステップが、前記第２プロセスの状態変化イベントを、前記イベントを指定する第２プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む、方法。
【請求項２６８】
請求項２６７記載の方法において、前記第２プロセス・イベント・データおよび状態情報が、前記第２プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項２６９】
請求項２６８記載の方法において、前記変換するステップが、前記少なくとも１つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項２７０】
請求項２６６記載の方法において、前記認識プロセスが前記第２プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記第２プロセスを備えている、方法。
【請求項２７１】
請求項２７０記載の方法において、前記認識したデータ・カプセルの内容が、前記第１プロセスの状態情報を表すデータである、方法。
【請求項２７２】
請求項２７１記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも１つの新たなデータ・シーケンスが、前記第１プロセスのイベントおよび前記第２プロセスのイベントの内少なくとも１つを表す、方法。
【請求項２７３】
請求項２７２記載の方法において、前記少なくとも１つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、前記第１プロセスおよび前記第２プロセスの内少なくとも１つの状態情報とを備えている、方法。
【請求項２７４】
請求項２７３記載の方法において、前記イベント・データならびに前記第１プロセスおよび前記第２プロセスの内少なくとも１つの状態情報が、前記第１プロセスおよび前記第２プロセスの内前記少なくとも１つのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
【請求項２７５】
請求項２７４記載の方法において、前記変換するステップが、前記少なくとも１つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項２７６】
請求項２７５記載の方法において、前記複数のプロセスが前記少なくとも１つの新たなデータ・シーケンスを用いる、方法。
【請求項２７７】
請求項２０４記載の方法において、前記認識したデータ・カプセルの内容に適した処理が、グラフィカル・オブジェクトをレンダリングするステップを含み、前記少なくとも１つの処理デバイスのディスプレイ上に前記グラフィカル・オブジェクトをレンダリングする、方法。
【請求項２７８】
請求項２７７記載の方法において、前記レンダリングするステップが、直接レンダリングを行い、前記複数のプロセスが前記少なくとも１つの処理デバイスのグラフィクス・レイヤに直接描画を行い、前記複数のプロセス間において前記レンダリングに適するような調整を行うために前記複数のプールを用いる、方法。
【請求項２７９】
請求項２７７記載の方法において、前記レンダリングするステップが、
レンダリング・コマンドを備えているデータ・カプセルを前記複数のプールに転送するプロセスと、
前記レンダリング・コマンドを前記複数のプールから引き出し、前記レンダリング・コマンドを解釈し、前記レンダリング・コマンドに応答して前記少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブするプロセスと、
を含む、複数のプロセスを備えている、方法。
【請求項２８０】
請求項２７７記載の方法において、前記レンダリングするステップが、
画素バッファにレンダリングするプロセスと、
生のフレーム・データを前記複数のプールに転送するプロセスであって、前記生のフレーム・データが前記画素バッファへのレンダリングの結果得られる、プロセスと、
前記生のフレーム・データを前記複数のプールから引き出し、前記少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、前記生のフレーム・データを組み合わせるプロセスと、
を含む、複数のプロセスを備えている、方法。
【請求項２８１】
請求項２０４記載の方法であって、
前記複数のプロセスのイベントを検出するステップと、
前記イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップであって、前記イベント・データおよび状態情報が、前記少なくとも１つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
前記少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
を備えている、方法。
【請求項２８２】
請求項２０４記載の方法において、少なくとも１つのデータ・シーケンスを発生する前記ステップが、
第１個別イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように、第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項２８３】
請求項２８２記載の方法において、前記第１個別データ集合を発生する前記ステップが、前記少なくとも１つの処理デバイスの識別データを含むように、前記第１個別データ集合を形成するステップを含み、前記識別データが、前記少なくとも１つの処理デバイスを識別するデータを含む、方法。
【請求項２８４】
請求項２８２記載の方法において、少なくとも１つのデータ・シーケンスを発生する前記ステップが、
第１個別イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように、第２データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項２８５】
請求項２８４記載の方法において、前記第１個別データ集合を発生する前記ステップが、第１個別データ集合オフセットを発生するステップを含み、前記第１個別データ集合オフセットが、前記第２データ・シーケンスの前記第１個別データ集合を指し示す、方法。
【請求項２８６】
請求項２８４記載の方法において、前記第２個別データ集合を発生する前記ステップが、第２個別データ集合オフセットを発生するステップを含み、前記第２個別データ集合オフセットが、前記第２データ・シーケンスの前記第２個別データ集合を指し示す、方法。
【請求項２８７】
請求項２８２記載の方法において、前記第１個別データ集合が、記述リストであり、この記述リストが、前記データの記述を含む、方法。
【請求項２８８】
請求項２０４記載の方法において、イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項２８９】
請求項２８８記載の方法において、イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項２９０】
請求項２０４記載の方法において、状態情報が、類別されたデータを表すタグ付き
バイト・シーケンスである、方法。
【請求項２９１】
請求項２９０記載の方法において、状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項２９２】
請求項２０４記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように、前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項２９３】
請求項２９２記載の方法であって、
第１可変長を有する第１オフセットを発生するステップを備えており、
前記第１オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスのイベント・データを指し示す、方法。
【請求項２９４】
請求項２９２記載の方法であって、
第２可変長を有する第２オフセットを発生するステップを備えており、
前記第２オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す、方法。
【請求項２９５】
請求項２９２記載の方法であって、
前記少なくとも１つのオフセットの内第１オフセットを用いて、前記データ・カプセルを通過する第１コード経路を形成するステップと、
前記少なくとも１つのオフセットの内第２オフセットを用いて、前記データ・カプセルを通過する第２コード経路を形成する、ステップと、
を備えており、
前記第１コード経路および前記第２コード経路が異なる経路である、方法。
【請求項２９６】
請求項２９２記載の方法において、第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
【請求項２９７】
請求項２０４記載の方法であって、
前記データ・カプセルの長さを含むヘッダを発生するステップと、
前記ヘッダを含むように前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項２９８】
請求項２０４記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
【請求項２９９】
請求項２９８記載の方法であって、
前記少なくとも１つの処理デバイスの第２イベントを検出するステップと、
前記複数のプールを検索して、前記第２イベントに対応するデータ・カプセルを求めるステップと、
を備えている、方法。
【請求項３００】
請求項２９９記載の方法であって、
前記データ・カプセルと前記第２イベントとの間における対応を特定するステップと、
前記特定に応答して、前記プールから前記データ・カプセルを抽出するステップと、
前記データ・カプセルの内容に応答して、前記少なくとも１つの処理デバイスの代わりに、前記第２イベントに対応する処理動作を実行するステップであって、前記少なくとも１つの処理デバイスが第１タイプのアプリケーションおよび第２タイプのアプリケーションに対応する、ステップと、
を備えている、方法。
【請求項３０１】
請求項２９８記載の方法において、前記複数のプールが複数のアプリケーションに結合されており、前記複数のプールが、前記複数のアプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記複数のアプリケーションによる前記複数のデータ・カプセルへのアクセスに備えており、前記複数のアプリケーションの内少なくとも２つのアプリケーションが異なるアプリケーションである、方法。
【請求項３０２】
請求項２９８記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
【請求項３０３】
請求項２９８記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
【請求項３０４】
請求項２０４記載の方法において、データ構造が、類別されていない、方法。
【請求項３０５】
請求項２０４記載の方法において、前記データ・カプセルのデータ構造が、イベント・データおよび状態情報のプラットフォームに依存しない表現である、方法。
【請求項３０６】
請求項２０４記載の方法において、前記データ・カプセルのデータ構造が、イベント・データおよび状態情報へのプラットフォームに依存しないアクセスを与える、方法。
【請求項３０７】
請求項２０４記載の方法において、前記転送するステップが、第１アプリケーション・タイプを有する第１アプリケーションから少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションに前記データ・カプセルを転送するステップを含み、前記第１アプリケーション・タイプが前記第２アプリケーション・タイプとは異なり、前記少なくとも１つのデータ・シーケンスを発生するステップが、前記第１アプリケーションによって実行され、前記方法が、前記転送するステップの間、前記データ・カプセルの少なくとも１つのデータ・シーケンスをそのまま保持するステップを備えている、方法。
【請求項３０８】
請求項３０７記載の方法であって、前記第２アプリケーションの動作中、前記少なくとも１つのデータ・シーケンスを用いるステップを備えている、方法。
【請求項３０９】
請求項２０４記載の方法であって、イベント・データと、前記少なくとも１つの処理デバイスのソース・デバイスの識別データとを含む第１データ集合を発生するステップを備えており、デバイス・イベント・データが、前記ソース・デバイスによって登録されたイベントを指定するデータを含み、前記識別データが、前記ソース・デバイスを識別するデータを含む、方法。
【請求項３１０】
請求項３０９記載の方法であって、前記イベントの完全な１組の状態情報を含む第２データ集合を発生するステップを備えており、前記第１データ集合および前記第２データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている、方法。
【請求項３１１】
請求項３１０記載の方法において、前記変換するステップが、前記第１データ集合および前記第２データ集合を含むようにデータ・カプセルを形成することによって、前記第１データ集合および前記第２データ集合をカプセル化するステップを備えており、前記データ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
【請求項３１２】
請求項２０４記載の方法であって、
第１タイプのアプリケーションの下で起動する第１処理デバイスのイベントを検出するステップと、
前記第１処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、前記イベント・データが前記イベントおよびこのイベントの状態情報を指定し、前記イベント・データおよび状態情報が、前記アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で起動する第２処理デバイスの第２イベントを検出するステップであって、前記第２タイプが前記第１タイプとは異なり、前記少なくとも１つの処理デバイスが、前記第１処理デバイスおよび前記第２処理デバイスを含み、
前記データ・カプセルと前記第２イベントとの間における対応を特定するステップと、
前記第２イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップと、
を備えている、方法。
【請求項３１３】
請求項３１２記載の方法において、前記データ・シーケンスを発生する前記ステップが、
前記イベント・データを含む第１データ集合を発生するステップと、
前記状態情報を含む第２データ集合を発生するステップと、
前記第１データ集合および前記第２データ集合を含むように第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項３１４】
請求項３１２記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項３１５】
請求項３１４記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項３１６】
請求項３１２記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
【請求項３１７】
請求項３１６記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項３１８】
請求項３１２記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項３１９】
請求項３１８記載の方法であって、
第１可変長を有する第１オフセットを発生するステップであって、前記第１オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記イベント・データを指し示す、ステップと、
第２可変長を有する第２オフセットを発生するステップであって、前記第２オフセットが、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報を指し示す、ステップと、
を備えている、方法。
【請求項３２０】
請求項３１８記載の方法であって、
前記少なくとも１つのオフセットの内第１オフセットを用いて、前記データ・カプセルを通過する第１コード経路を形成するステップと、
前記少なくとも１つのオフセットの内第２オフセットを用いて、前記データ・カプセルを通過する第２コード経路を形成する、ステップと、
を備えており、
前記第１コード経路および前記第２コード経路が異なる経路である、方法。
【請求項３２１】
請求項３１８記載の方法において、第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
【請求項３２２】
請求項３１２記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
【請求項３２３】
請求項３２２記載の方法であって、
前記複数のプールを検索して、前記第２イベントに対応するデータ・カプセルを求めるステップと、
前記対応を特定したことに応答して、前記プールから前記データ・カプセルを抽出するステップと、
を備えている、方法。
【請求項３２４】
請求項３２２記載の方法において、前記複数のプールが前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに結合されており、前記複数のプールが、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法。
【請求項３２５】
請求項３２２記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
【請求項３２６】
請求項３２２記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
【請求項３２７】
請求項３１２記載の方法において、前記データ構造が、類別されていない、方法。
【請求項３２８】
請求項３１２記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
【請求項３２９】
請求項３１２記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
【請求項３３０】
処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを含み、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
前記複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、データ・メッセージが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータと、前記データ・メッセージを発したプロセスの状態情報とを含む、ステップと、
前記データ・メッセージを、複数のプールの内少なくとも１つのプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・メッセージを含んでいる、ステップと、
前記プロセス間において調整を行うステップであって、この調整が、前記複数のプールからピア・プロセスの状態情報を引き出すことによって、前記複数のプロセスの各プロセスが、前記複数のプロセスのピア・プロセスと対等になることを含む、ステップと、
前記複数のプールの内少なくとも１つのプールの１組のデータ・メッセージをインタラクティブに組み合わせることによって、前記複数のプロセスの出力を発生するステップと、
を備えている、方法。
【請求項３３１】
ボディによって行われたジェスチャを表すジェスチャ・データを受け取る検出器と、
前記検出器に結合されているプロセッサであって、このプロセッサが前記ジェスチャ・データから自動的に前記ジェスチャを検出し、前記プロセッサが複数のプロセスを実行し、これら複数のプロセスが、前記ジェスチャを表す１組のイベントを含むイベントを発生し、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成し、前記プロセッサが、前記複数のプロセスにおける各プロセスのイベントをデータ・カプセルに変換し、各データ・カプセルが、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含み、前記プロセッサが前記データ・カプセルを複数のプールに転送し、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含み、前記複数のプロセスの内１組のプロセスが、認識プロセスとして機能し、この認識プロセスが、前記複数のプールにおいて、前記ジェスチャに対応する内容を備えているデータ・カプセルを認識し、前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、前記認識したデータ・カプセルから前記ジェスチャ信号を発生し、前記ジェスチャ信号が前記ジェスチャを表す、プロセッサと、
を備えている、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、２００８年１０月１４日に出願した米国（ＵＳ）特許出願第６１／１０５，２４３号の優先権を主張する。
【０００２】
本出願は、２００８年１０月１４日に出願した米国（ＵＳ）特許出願第６１／１０５，２５３号の優先権を主張する。
本願は、２００８年４月２４日に出願したＵＳ特許出願第１２／１０９，２６３号の一部継続出願である。
【０００３】
本願は、２００９年４月２日に出願したＵＳ特許出願第１２／４１７，２５２号の一部継続出願である。
本願は、２００９年６月１８日に出願したＵＳ特許出願第１２／４８７，６２３号の一部継続出願である。
【０００４】
本願は、２００９年９月３日に出願したＵＳ特許出願第１２／５５３，８４５号の一部継続出願である。
本願は、２００９年９月１０日に出願したＵＳ特許出願第１２／５５７，４６４号の一部継続出願である。
【０００５】
本願は、２００９年１０月２日に出願したＵＳ特許出願第１２／５７２，６８９号の一部継続出願であり、ＵＳ特許出願第１２／５７２，６８９号は、米国特許第７，５９８，９４２号の一部継続出願である。
発明の分野
計算プロセス内および計算プロセス間におけるデータの表現、操作、および交換に関する実施形態について説明する。
【従来技術】
【０００６】
従来のプログラミング環境は、マルチコンピュータ演算装置（ＣＰＵ）やネットワークを跨いだ実行、あるいは多数の計算プロセス間における柔軟なデータ共有を完全にサポートしてはいない。ユーザが向き合うコンピュータ・プログラムは、従前より、処理の大多数および全てのグラフィカル出力が１つの計算プロセスによって生成されるように構成されている。このメカニズムは、標準的であり、ツール・チェーン開発環境およびオペレーティング・システムによって十分にサポートされているが、規模の調整がしずらく、広く用いられている同世代のアプリケーションが膨大で不安定となる大きな一因となっている。
引用による包含
本明細書において述べる各特許、特許出願、および／または刊行物は、本願において引用することにより、個々の特許、特許出願、および／または刊行物の各々が具体的にそして個々に、引用することにより本願に含まれることを示した場合と同程度にその全体が本願にも含まれるものとする。
【図面の簡単な説明】
【０００７】
【図１Ａ】図１Ａは、一実施形態の下における、マルチプロセス・インタラクティブ・システムのブロック図である。
【図１Ｂ】図１Ｂは、代替実施形態の下におけるマルチプロセス・インタラクティブ・システムのブロック図である。
【図１Ｃ】図１Ｃは、他の代替実施形態の下におけるマルチプロセス・インタラクティブ・システムのブロック図である。
【図２】図２は、一実施形態の下におけるマルチプロセス・インタラクティブ・システムの動作の流れ図である。
【図３】図３は、一実施形態の下において、スロークス(slawx)、プロテイン(protein)、およびプール(pool)を用いたデータ表現を含む処理環境のブロック図である。
【図４】図４は、一実施形態の下における、プロテインのブロック図である。
【図５】図５は、一実施形態の下における、デスクリップ(descrip)のブロック図である。
【図６】図６は、一実施形態の下における、インジェスト(ingest)のブロック図である。
【図７】図７は、一実施形態の下におけるスロー(slaw)のブロック図である。
【図８Ａ】図８Ａは、一実施形態の下において、プールの中にあるプロテインのブロック図である。
【図８Ｂ】図８Ｂは、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。
【図８Ｃ】図８Ｃは、一実施形態の下においてプロテインを用いる際の流れ図である。
【図８Ｄ】図８Ｄは、一実施形態の下において、プロテインを組み立てるまたは発生する際の流れ図である。
【図９】図９は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。
【図１０】図１０は、多数のデバイスと、これらのデバイスの１つ以上で起動する多数のプログラムとを含む処理環境のブロック図であり、一実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。
【図１１】図１１は、多数のデバイスと、これらのデバイスの１つ以上で起動する多数のプログラムを含む処理環境のブロック図であり、一代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。
【図１２】図１２は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、別の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。
【図１３】図１３は、多数のデバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクスイベントを共有し、集合的に応答することを可能にする。
【図１４】図１４は、多数のデバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする。
【図１５】図１５は、多数のデバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、追加の代替実施形態の下において、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる。
【図１６】図１６は、一実施形態の下における、ジェスチャ制御システムのブロック図である。
【図１７】図１７は、一実施形態の下における標識タグの図である。
【図１８】図１８は、実施形態におけるジェスチャ・ボキャブラリにおけるポーズの図である。
【図１９】図１９は、実施形態におけるジェスチャ・ボキャブラリにおける方位の図である。
【図２０】図２０は、一実施形態におけるジェスチャ・ボキャブラリにおける２つの手の組み合わせの図である。
【図２１】図２１は、一実施形態におけるジェスチャ・ボキャブラリにおける方位配合の図である。
【図２２】図２２は、一実施形態の下におけるジェスチャ制御の流れ図である。
【図２３−１】図２３は、一実施形態の下におけるコマンドの一例である。
【図２３−２】図２３は、一実施形態の下におけるコマンドの一例である。
【図２４】図２４は、一実施形態の下において、マルチプロセス・インタラクティブ・システムを用いて実現した空間動作環境（ＳＯＥ）のブロック図である。
【図２５】図２５は、一実施形態の下において、ジェスチャ制御システムからの入力を用いるマルチプロセス・インタラクティブ・システムの動作の流れ図である。
【発明を実施するための形態】
【０００８】
本明細書では、インタラクティブ・アプリケーションを起動させる(give rise to)ように多数のコンピュータ・プロセスの挙動および出力を調整するシステムおよび方法を含む実施形態について説明する。本明細書において説明する実施形態は、総合的に、マルチプロセス・インタラクティブ・システム、プログラム、またはアプリケーションと呼ばれ、並列に実行することができる多数の別個のコンピュータ・プロセスに分割されたアプリケーション・プログラムを含む。１組のこれらのプロセスは、システム出力全体の内の一部分を生成することができ、この一部分とユーザが対話処理を行う。１組のこれらのプロセスは、構造化され明確に定義されたデータ交換メカニズムにアクセスすることができる。このデータ交換メカニズムは、アクティビティを調整するために用いられる。１組のこれらのプロセスは、構造化データ交換メカニズムを通じて、ユーザ入力（例えば、生のユーザ入力、重度に変換されたユーザ入力、生および重度に変換されたユーザ入力等）を利用するために動作可能である。
【０００９】
本明細書において記載する実施形態は、計算プロセスの境界を跨ぐアプリケーション・コンポーネントに対してモジュール性(modularity)を提供する。この提供されたモジュール性の結果、本明細書に記載する実施形態では、コンポーネントの再利用、相互動作可能性(interoperability)の機会増大、検査および検証の易化、ロバスト性向上、および実行中のフォールト・トレランスが得られる。
【００１０】
更に、同世代のコンピュータは、多数のプロセッサ・エレメント（例えば、ＣＰＵコア）を内蔵する場合がおおい。本明細書における実施形態は、従来のアプリケーション構成技法よりも、多重プロセッサ・アーキテクチャのスケーリングが格段に優れている。この「マルチコア」スケーリングは、コンピュータの設計および製造の傾向が、クロック速度上昇ではなく、コアの数量増大に増々傾倒しつつあるので、一層重要になる。
【００１１】
本明細書において記載する実施形態は、プロセス・コンポーネントの動的な構築、分解、および再組み合わせを可能にする。本明細書において記載する実施形態は、ネットワーキング（または他の相互接続）プロトコルを用いる多数のコンピュータに跨る構造化データ交換メカニズムの拡張を可能にする。本明細書において記載する実施形態は、コンピュータ間におけるプロセス・コンポーネントの動的な移転を可能にする。本明細書に記載する実施形態は、関与するプロセスの数、組成、および実行コンテキストにしたがって、構造化データ交換メカニズムの動的な最適化を可能にする。本明細書に記載する実施形態は、多数のコンピュータ上で作成されたグラフィカル出力を、１つのディスプレイにおいて一緒に組み合わせることを可能にする。本明細書において記載する実施形態は、多数のディスプレイを包括的に含むグラフィカル・コンテキストを共有し、調整することを可能にする。本明細書において記載する実施形態は、多数のコンピュータによってドライブされる多数の表示を包含するマルチディスプレイ・グラフィカル・コンテキストの共有および調整を可能にする。本明細書において記載する実施形態は、自動履歴バッファを導入し、過去のデータの内ある両が常にアプリケーション・コンポーネントに利用可能となるように、この自動履歴バッファを構造化データ交換メカニズムに組み込む。
【００１２】
以下の用語が本明細書において用いられる場合、以下の一般的な意味を持つことを意図している。「プロセス」という用語は、本明細書において用いられる場合、分離可能なプログラム実行コンテキストを意味する。コンピュータ・アーキテクチャおよびオペレーティング・システムは、プロセス実施の技術的詳細において相違する。本明細書において記載するメカニズムは、広範囲のプロセス実施態様に跨って動作し、できるだけ多い利用可能な計算リソースを利用する混成アプリケーション設計またはコンフィギュレーションを容易にするように構成されている。
【００１３】
「デバイス」という用語は、本明細書において用いる場合、１つ以上のプログラムまたはアルゴリズムを起動させるあらゆるプロセッサ主体デバイス、１つ以上のプログラムまたはアルゴリズムの下で起動するあらゆるプロセッサ主体デバイス、および／または１つ以上のプログラムを起動させる、および／または１つ以上のプログラムまたはアルゴリズムの下で起動するプロセッサ主体デバイスに結合または接続されているあらゆるデバイスを意味する。「イベント」という用語は、本明細書において用いる場合、起動している即ち実行中のプログラムまたはアルゴリズム、プロセッサ主体デバイス、および／またはプロセッサ主体デバイスに結合または接続されているデバイスと関連のあるあらゆるイベントを意味する（例えば、イベントは、入力、出力、制御、状態、状態変化、動作(action)、データ（データのフォーマットや、データと関連のある処理における段階には無関係）等を含むことができるが、これらに限定されるのではない）。
【００１４】
以下の説明では、本明細書において説明する実施形態の完全な理解が得られるように、そして実施形態についての説明が可能となるように、多数の具体的な詳細を導入する。しかしながら、これらの実施形態は、これらの具体的な詳細の１つ以上がなくても、または他のコンポーネント、システム等を用いても実施できることは、当業者には認められよう。一方、開示される実施形態の態様を曖昧にするのを避けるために、周知の構造または動作については、図示しないか、または詳細に説明しないこととする。
【００１５】
本明細書における実施形態は、少なくとも１つの処理デバイス上で多数のプロセスを実行するシステムおよび方法を含む。一実施形態のシステムおよび方法は、各プロセスのイベントをデータ・カプセルに変換する。一実施形態のシステムおよび方法は、このデータ・カプセルを多数のプールまたはレポジトリに転送する。各プロセスは、認識プロセスとして動作し、この認識プロセスは、プールにおいて、当該認識プロセスのインタラクティブ機能および／または認識プロセスの識別に対応する内容を備えているデータ・カプセルを認識する。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルのコンテンツに適した処理を実行する。
【００１６】
例えば、図１Ａは、一実施形態の下における、マルチプロセス・インタラクティブ・システム１０のブロック図である。このシステム１０は、任意の数のプロセスＰ１〜Ｐ７をホストするまたは実行する処理デバイス１１を含む。この例のマルチプロセス・インタラクティブ・システム１０は、１つのコンピュータ１１を含むまたは１つのコンピュータ１１において実行するが、１つのコンピュータに限定されるのではなく、任意の数の処理デバイスまたはシステム、および／またはその組み合わせに跨って実行することもできる。一実施形態のプロセスＰ１〜Ｐ７は、１つ以上のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムは、少なくとも１つのプロセスを備えているが、本実施形態はそのように限定されるのではない。各プロセスの間に発生または生成されたイベントは、ある数のデータ・カプセルＤＣ１〜ＤＣ９に変換され、これらのデータ・カプセルは多数のプール１５〜１７またはレポジトリに転送される。システム１０の楕円エレメントは、プール１５〜１７を表し、プールまたはレポジトリとは、構造化データ交換のためのメカニズムである。これについては、以下で詳細に説明し、更に関連出願においても記載されている。データ・カプセルＤＣ１〜ＤＣ９は、データ・メッセージとも呼ばれ、プール１５〜１７を通過する。データ・カプセルを、包括的に、「プロテイン」と記述する。プロテインについては以下で説明する。
【００１７】
各プロセスＰ１〜Ｐ７は、認識プロセスとして動作し、認識プロセスは、プール１５〜１７において、当該認識プロセスＰ１〜Ｐ７のインタラクティブ機能および／または認識プロセスＰ１〜Ｐ７の識別に対応する内容を備えているデータ・カプセルを認識する。認識プロセスＰ１〜Ｐ７は、認識したデータ・カプセルＤＣ１〜ＤＣ９をプールから引き出し、認識したデータ・カプセルのコンテンツに適した処理を実行する。マルチプロセス・インタラクティブ・システム１０については、以下で図３から図１５を参照しながら更に詳しく説明する。
【００１８】
図１Ｂは、代替実施形態の下におけるマルチプロセス・インタラクティブ・システム２０のブロック図である。このシステム２０は、任意の数のプロセスＰ１〜ＰＸをホストするまたは実行する処理デバイス２１を含み、Ｘは、処理デバイス２１および／またはシステム２０の構成に適した任意の数を表す。また、システム２０は、任意の数のプロセスＰ１〜ＰＹをホストするまたは実行する処理デバイス２２も含み、Ｙは、処理デバイス２２および／またはシステム２０の構成に適した任意の数を表す。この例のマルチプロセス・インタラクティブ・システム２０は、２つの処理デバイス２１／２２を含む、またはこれらに跨って実行するが、２つのデバイスに限定されるのではなく、任意の数の処理デバイスまたはシステム、および／またはその組み合わせに跨って実行することもできる。一実施形態のプロセスＰ１〜ＰＸおよびプロセスＰ１〜ＰＹは、１つ以上のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムは少なくとも１つのプロセスを備えているが、本実施形態はそのように限定されるのではない。
【００１９】
各プロセスの実行中に発生または生成されるイベントは、データ・カプセル（図示せず）に変換され、これらのデータ・カプセルは１つ以上のプールに転送される。システム２０の楕円エレメントはプールを表し、これらのプールまたはレポジトリは、構造化データ交換のためのメカニズムである。これについては、以下で詳細に説明し、更に関連出願においても記載されている。この例では、プールＰＬ１が処理デバイス２１上にホストされているが、任意の数のプールを処理デバイス２１上にホストすることもできる。プールＰＬ１〜ＰＬＹは処理デバイス２２上にホストされており、Ｙは、処理デバイス２２および／またはシステム２０の構成に適した任意の数を表し、任意の数のプールを処理デバイス２２上にホストすることができる。また、システム２０はプールＰＬ１１〜ＰＬＸも含み、Ｘは、処理デバイス２２および／またはシステム２０の構成に適した任意の数を表し、任意の数のプールをシステム２０においてホストすることができる。データ・カプセルを発生する任意のプロセスおよび／またはデバイスが、データ・カプセルをシステムにおける任意のプールに転送することができる。
【００２０】
各プロセスＰ１〜ＰＸ／Ｐ１〜ＰＹは、認識プロセスとして実行し、この認識プロセスは、プールにおいて、当該認識プロセスＰ１〜ＰＸ／Ｐ１〜ＰＹのインタラクティブ機能に対応する内容を備えているデータ・カプセル、および／または認識プロセスＰ１〜ＰＸ／Ｐ１〜ＰＹの識別を認識する。認識プロセスＰ１〜ＰＸ／Ｐ１〜ＰＹは、認識したデータ・カプセルをプールから引き出し、これら認識したデータ・カプセルの内容に適した処理を実行する。マルチプロセス・インタラクティブ・システム２０については、図３から図１５を参照して以下で更に詳しく説明する。
【００２１】
本明細書における実施形態は、少なくとも１つの処理デバイス上において多数のプロセスを実行するシステムおよび方法を含む。一実施形態のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備えている。一実施形態のシステムおよび方法は、複数のプロセスの内各プロセスのイベントをデータ・カプセルに変換する。データ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、そのデータ・カプセルを発生したプロセスの状態情報とを含む。一実施形態のシステムおよび方法は、データ・カプセルを多数のプールまたはレポジトリに転送する。一実施形態の各プロセスは、認識プロセスとして動作する。この認識プロセスは、プールにおいて、当該認識プロセスのインタラクティブ機能に対応するコンテンツを備えているデータ・カプセル、および／または認識プロセスの識別を認識する。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する。
【００２２】
本明細書において記載する実施形態の例は、インタラクティブ・アプリケーションを可能にするために、多数のコンピュータ・プロセスの挙動およびグラフィカル出力を調整するシステムおよび方法を含む。この例はグラフィカル処理およびグラフィカル出力を対象とするが、マルチプロセス・インタラクティブ・システムの実施形態は、グラフィカル・プロセスに限定されるのではなく、任意の数の処理デバイスの下で起動する任意のプロセスに適用することができる。マルチプロセス・インタラクティブ・システムは、並列に実行することができる多数の別個のコンピュータ・プロセスに分割されたアプリケーション・プログラムを含み、１組のこれらのプロセスが、ユーザが対話処理するグラフィカル出力全体における一部を生成することができる。１組のこれらのプロセスは、構造化され明確に定義されたデータ交換メカニズムにアクセスすることができる。このデータ交換メカニズムは、構造化データ交換メカニズムを通じてユーザ入力を利用するために動作可能となるように、アクティビティを調整するために用いられる。
【００２３】
更に具体的な一例として、以下に続く説明は、本明細書ではスクエア(Squares)と呼ばれる、マルチプロセス・グラフィカル・プログラムについて、インタラクティブ・アプリケーションを起動するように多数のコンピュータ・プロセスの挙動およびグラフィカル出力を調整する実施形態のインスタンス化(instantiation)の一例として教示する。このインスタンス化の一例の説明は、本明細書において開示するメカニズムが、どのように動作するのかを、任意のインタラクティブ・プログラムに合わせてそれを実施するのに十分に詳細なレベルで示すことを意図している。このメカニズム（および、実際にはこの構成部分）は完全に汎用であり、実際には種々の異なる方法で実現することができる。このようなプログラムでは典型的であるように、本明細書において開示するメカニズムは、ユーザ入力へのアクセス、プロセスを跨るプログラム状態の細かい粒度の調整、およびグラフィカル出力の調整を含み、これらには限定されない主要なサービスを提供する。
【００２４】
本明細書において紹介するスクエア・プログラムは、実世界プログラムにおいて有用な様々な種類の基本的調整を実演(demonstrate)する役割を果たす。このスクエア・プログラムは、柔軟な数の有色、半透明の正方形を１つ以上のコンピュータ・ディスプレイ上にレンダリングするための装備がある。これらの正方形に各々は、１つの計算プロセスにおいて具体化される。各正方形の状態およびグラフィック上の詳細は、種々の要因に依存する。これらの要因には、ユーザの入力アクション、他の正方形の状態、および大域的に配信される外部メッセージが含まれる。これらの正方形は、入力デバイス（例えば、マウス、タッチ・スクリーン等）を用いて、ディスプレイ上のあらゆるところに移動させることができる。関連出願において記載されているジェスチャ／空間入力システムも、これらの正方形を移動させるために用いることができ、その場合、ジェスチャ／空間ネットワークに関与するコンピュータに利用可能なディスプレイの内任意のものに、正方形を位置付けることができる。
【００２５】
図１Ｃは、他の代替実施形態の下における、マルチプロセス・インタラクティブ・システム１００のブロック図である。このシステム１００は、プロセスおよび相互接続を含み、これらが組合わさることによってプログラムの実行(run)例を形成する。無地の矩形エレメント(solid rectangle element)（例えば、エレメントＭ、Ｐ、Ｓ、Ｇ全般）は、システム１００におけるプロセスを表す。楕円のエレメント（例えば、エレメントＵｉ、Ｃｏｏ、フレーム）は、プール、即ち、以下で詳細に説明するような構造化データ交換のためのメカニズムを表す。このメカニズムは、関連出願にも記載されている。プールを通過するデータ・メッセージは、以下で説明するように、包括的に「プロテイン」と呼ばれる。
【００２６】
この例のマルチプロセス・インタラクティブ・システム１００は、２つのコンピュータ１０１および１０２を含む、またはこれらのコンピュータ１０１および１０２に跨って実行するが、２つのコンピュータに限定されるのではなく、任意の数の処理システム、および／またはその組み合わせに跨って実行するこができる。この例では、第１コンピュータ１０１が２つの正方形Ｓ（例えば、Ｓ２１、Ｓ２２）を具体化するプロセスをホストし、第２コンピュータ１０２が４つの正方形Ｓ（例えば、Ｓ１１、Ｓ１２、Ｓ１３、Ｓ１４）を具体化するプロセスをホストする。代替実施形態では、任意の数のコンピュータ上で実行する任意の数の正方形プロセスＳを含むことができる。第１コンピュータ１０１は１つのディスプレイ１１０に結合されており、第２コンピュータ１０２は３つのディスプレイ１２１、１２２、１２３に結合されている。代替実施形態では、任意の数のコンピュータに結合されている任意の数のディスプレイを含むことができる。
【００２７】
２つのコンピュータ１０１および１０２の各々は、少なくとも１つの「マウス」プロセスＭ（例えば、Ｍ１、Ｍ２）をホストする。マウス・プロセスＭは、コンピュータのマウス入力イベントを、ユーザ入力プロテインの相応しいストリームに変換し、これらのプロテインを少なくとも１つの「ユーザ入力」プールＵｉに配信する上位ドライバを含む。ジェスチャ／空間システム（以下で詳細に説明する）が、ジェスチャ／空間プロセスＧとしてカプセル化されており、これもユーザ入力プロテインをユーザ入力プールＵｉに配信する。
【００２８】
また、２つのコンピュータ１０１および１０２の各々は、少なくとも１つの「ポインタ」プロセスＰ（例えば、Ｐ１、Ｐ２）もホストする。ポインタ・プロセスＰは、Ｕｉプールからデータを取り込むまたは受け取り、ユーザがポインタの「注意(attention)」をどこに向けているのか判断し、しかるべきポインタ・グラフィクスを描画またはレンダリングする役割を担う。ポインタ・プロセスＰは、ポインタ位置およびモードに関するデータまたはこれらを表すデータを、「調整(coordination)」プールＣｏｏに入れる。ポインタ・プロセスＰは、グラフィカル出力を「フレーム」プールに配信する。「フレーム」プールは、以下で詳細に説明する、特殊化された抽象(specialized abstraction)である。
【００２９】
更に、２つのコンピュータ１０１および１０２の各々は、先に説明した様々な「スクエア」プロセスＳもホストする。各スクエア・プロセスＳは、調整プールＣｏｏを参照して、ポインタ・データおよびピア・スクエア・プロセスＳの状態を求める。また、各スクエア・プロセスＳは、これら自体の空間およびモード状態を記述するデータを調整プールＣｏｏに戻す。スクエア・プロセスＳは、グラフィカル出力を「フレーム」プールに配信する。フレーム・プールは、特殊化した抽象であり、以下で詳しく説明する。
【００３０】
ジェスチャ／空間プロセスＧは、ユーザ入力プールＵｉおよび調整プールＣｏｏと共に、２つのコンピュータ１０１および１０２のいずれにでもホストすることができる。あるいは、ジェスチャ／空間プロセスＧをユーザ入力プールＵｉおよび調整プールＣｏｏと共にホストすることは、２つのコンピュータ１０１および１０２間で分担することもできる。更に別の代替構成として、ジェスチャ／空間プロセスＧを、ユーザ入力プールＵｉおよび調整プールＣｏｏと共に、他のコンピュータ（図示せず）にホストすることもできる。
【００３１】
ローカル・フレーム・プールに貯入されたプロテインに合わせて、システム１００は専用の合成プロセスｃｏｍを含む。このプロセスは、フレーム・レイヤを組み合わせて、１秒毎に多数回、ディスプレイ毎に１つの出力フレームを形成する。総合的なディスプレイ・フレーム・レートは、一般に、システム・レベルの構成選択によって設定されるが、スクエア・アプリケーションを構成する個々のプロセスの各々は、異なるフレーム・レートを用いることができるようになっている。合成プロセスｃｏｍは、フレーム・レイヤをしかるべく対照させる(match up)ように監視する。
【００３２】
図２は、一実施形態の下におけるマルチプロセス・インタラクティブ・システムの動作についての流れ図２００である。この動作は、複数のプロセスを少なくとも１つの処理デバイス上で実行する（２０２）ことを含む。複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備えるようになっている。この動作は、複数のプロセスの内各プロセスのイベントをデータ・カプセルに変換する（２０４）ことを含む。データ・メッセージは、イベントのイベント・データのアプリケーションに独立した表現と、このデータ・メッセージを発生したプロセスの状態情報を含む。この動作は、データ・メッセージを複数のプールの内少なくとも１つのプールに転送する（２０６）ことを含む。各プロセスは、認識プロセスとして動作し、この認識プロセスが、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容の少なくとも１つを備えているデータ・カプセルと、認識プロセスの識別を認識する（２０８）。認識プロセスは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する（２１０）。このマルチプロセス・インタラクティブ・システムの動作は、プロセス間における調整を可能にし、この調整には、複数のプールからピア・プロセスの状態情報を引き出すことによって、複数のプロセスのピア・プロセスと対等になる複数のプロセスの内各プロセスが含まれる。また、この動作は、複数のプールの内少なくとも１つのプールの１組のデータ・カプセルの内容をインタラクティブに組み合わせることによって、複数のプロセスの出力を発生することも可能にする。
【００３３】
マウスおよびジェスチャ／空間入力を扱う際に、マウス・プロセスＭは下位マウス・ハードウェアを監視し、従前のマウス・ドライバ・イベントを、画面に独立したプロテインに変換する。以下の記載にしたがって、ユーザ入力プールＵｉに配信される一実施形態のマウス・プロセスＭのプロテインは、次の通りである。
【００３４】
【表１】
0005805537.tif 000002
【００３５】
ジェスチャ／空間プロセスＧのプロテインは、以下のように、同様に見える。
【００３６】
【表２】
0005805537.tif 000003
【００３７】
ポインタ・プロセスＰは、これらのメッセージを、これらが描画する役割を担っている種々のポインタの三次元空間における位置を暗示するものとして解釈する。静的な１組のポインタが、アプリケーション・コードにおいて定義されていてもよく、または早期のプロテインがポインタを定義し初期化していてもよい。
【００３８】
空間動作環境内において実行するスクエア・プログラムのインスタンス化について、ポインタ・プロセスＰの各々は、これらがホストされているコンピュータに取り付けられている表示画面の正確な実世界位置を知っている。この場合も、これらの表示画面は、起動時に初期化されていても、またはデータ・メッセージによって動的に初期化されてもよい。
【００３９】
プロテインがユーザ入力プールＵｉに到達すると、ポインタ・プロセスＰは反応して、以下のように、新たなプロテインを構築し、これらを調整プールＣｏｏに配信する。  
【００４０】
【表３】
0005805537.tif 000004
【００４１】
これらのプロテインまたはメッセージは、利用可能なディスプレイに関するポインタ・オブジェクトの位置を定義する。各ポインタ・プロセスＰは、それがホストされているコンピュータのみに取り付けられているディスプレイに対する数学的変換を管理するように構成されている。
【００４２】
周期的に、各ポインタ・プロセスＰはグラフィカル出力のフレームも描画する。このグラフィカル・データはフレーム・プールに配信される。ポインタ・プロセスＰによって生成される各フレームは、全てのポインタ・グラフィクスをレンダリングし、そのプロセスをホストするコンピュータに取り付けられているディスプレイ上に、そのポインタ・グラフィクスが現れる。
【００４３】
一実施形態のアプリケーション・モデルおよびグラフィクスに移ると、スクエア・プロセスＳは、スクエア・アプリケーションの焦点となる半透明な正方形を追跡し描画する役割を担う。各正方形は、位置、方位、サイズ、および色を有する。スクエア・プロセスＳは、正方形の状態が変化したときはいつでも、プロテインを調整プールＣｏｏに入れる。
【００４４】
【表４】
0005805537.tif 000005
【００４５】
また、スクエア・プロセスＳは、ポインタ・プロセスが行うのと全く同様に、グラフィカル出力をフレーム・プールに配信する。各スクエア・プロセスＳは、しかしながら、当該プロセスをホストするコンピュータに取り付けられているディスプレイにその正方形が現れるか否かには係わらず、それ自体の正方形をレンダリングする。フレームの扱いについては、以下で詳しく説明する。
【００４６】
ポインタおよび正方形の状態を記述するプロテインをマルチ・サブスクライバ・プール(multi-subscriber pool)に配置または転送することによって、このアプリケーションを構成する別個のプロセスが調整することが可能となり、こうして異なるプロセス間において調整が行われる。一実施形態のスクエア・プロセスＳは、正方形の境界のエリア内に進んだポインタを示すプロテインを監視する。これが行われると、スクエア・プロセスＳはプロテインをプールに入れて、以下のようにして、重複、および関与する正方形およびポインタへの参照を示す。
【００４７】
【表５】
0005805537.tif 000006
【００４８】
ポインタ・プロセスＰは、この形態のプロテインを監視する。ポインタ・プロセスＰがそれ自体のｍｉｄを参照する重複プロテインを特定または発見(see)すると、ポインタ・フレームを描画するときに用いるグラフィカル表現を変更する。重複を示すグラフィックは、例えば、プロセスが然るべき重複終了(overlap-exit)プロテインを確認するまで用いられる。
【００４９】
【表６】
0005805537.tif 000007
【００５０】
以上の調整方策には、多くの変形が可能である。ポインタ・プロセスＰは、幾何学的重複（前述のようにスクエア・プロセスＳがそれを行うのではなく）をチェックする役割(duty)を扱うことができる。これらのプロセスは全て、フレーム同期させることができ、重複プロテインをフレーム毎に発生することができ、これによって別々の開始および終了プロテインの必要性が解消する。
【００５１】
殆ど常に、本明細書において説明するメカニズム内において動作するときに直面する所与の調整問題にはいずれにも、利用可能な多様な解決策がある。この柔軟性は、実際には、本明細書における実施形態の強さの１つである。本明細書における説明は、典型的なマルチプロセス・グラフィカル・アプリケーションを構築しようとする際に直面する様々な重なり合い(interlocking)の問題に対して実施される解決策の少なくとも１つを記録に取っている。多数の参考文献が、有用なメッセージング・パターンを収集しており、その多くは、適用可能である。例えば、G. Hohpe and B. Woolfによる"Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions", ISBN 0321146530がある。
【００５２】
一実施形態の下においてユーザ入力を操作アクション(manipulatory action)に繋げる際、正方形を対話的に動かすには、ポインタ・プロセスＰが調整プールＣｏｏに入れたデータをスクエア・プロセスＳが利用することが含まれる。スクエア・プロセスＰは、認識されたポインタ重複状態ならびに「ポインタ」および「クリック」デスクリップを有するプロテインの組み合わせに応答して、移動を初期化する。移動が進展している間、正方形のグラフィカル表現が変化し、空間における正方形の位置がポインタに追従する。この移動は、対応する「ポインタ」／「クリック解除(unclick)」プロテインが発生するまで続く。
【００５３】
また、一実施形態の正方形は、これらが互いに重なり合ったときにも、その色を変化させる。Ｓプロセスが「ｔｓｑｕａｒｅ」／「ポジション」プロテインを確認したときはいつでも、それ自体とそのプロテインのデポジッタ(depositor)との間に何らかの重複がないか計算を行う。重複がある場合、その次のフレームをレンダリングするときに、重複を指示する色を用いる。そうでない場合、その通常の色を用いる。
【００５４】
尚、一実施形態の疎結合アーキテクチャの柔軟性によって、この挙動を実現する他のまたは変わりの方法も得られることを注記しておく。スクエア・プロセスＳは、重複計算を行うのを回避し、代わりにこの作業を他のプロセスに肩代わりさせることができる。例えば、正方形の一部または全部について計算(math)を連続的に行い、重複状態を記述するプロテインを、調整プールＣｏｏに落下させる。スクエア・プロセスＳは、単にこれらのプロテインを待つだけである。
【００５５】
【表７】
0005805537.tif 000008
【００５６】
このアプリケーション作業負荷をスライスしさいの目に切る柔軟性は非常に有用である。計算集約的なジョブは、余分なパワーを有するプロセッサまたは機械に移動することができる。データの生成部(producers)は、必要に応じて、ヘルパー・プロセスをインスタンス化することができる（そして、もはやこれらが不要となったときはこれらを終了させることができる）。ユーザが直接対話処理しているアプリケーション・エリアには、またユーザが直ちにより大きな粒度、詳細、またはリフレッシュ・レートを知覚できる場合にも、より大きな計算およびレンダリング・リソースを適用することができる。
【００５７】
これの全てが可能なのは、本明細書において説明するマルチプロセス・インタラクティブ・システムがアプリケーション状態を外面化し(externalize)、マルチプロセスがその状態にアクセスすることを可能にするからである。対照的に、同世代のプログラミング・モデルでは、実行時の状態は、個々のプロセスの内部に殆ど完全に「閉じ込められる」ことになる。
【００５８】
マルチプロセス・インタラクティブ・システムは、プログラマが全てのインタラクティブ機能をプロテイン・ドライブ可能状態として露出することを促進する。アプリケーション・プログラミング・インターフェース（ＡＰＩ）は、従前の関数コールではなく、各プロセスが認識するプロテインによって定義される。例えば、正方形の内任意のもの（または全て）の色を変化させるプロテインは、次のように定義される。
【００５９】
【表８】
0005805537.tif 000009
【００６０】
いずれかのスクエア・プロセスＳがこのプロテインを調整プールＣｏｏにおいて確認した場合、それ自体の一意のオブジェクトｉｄまたは一般的なアドレス０ｘ０のいずれかが存在するか否か確かめるために、ｔｉｄｓリストをチェックする。そうである場合、プロセスは、２つの新たに指定された色を用いて（１つは通常の場合、そして１つは重複の場合）その正方形をレンダリングし始める。
【００６１】
このメカニズムおよびこの「全てのインタラクティブ機能をプロテインとして露出する(expose)」手法を用いると、スクエア・アプリケーションの他の全てのコードが既に終了し、配備され、実行した後に、正方形の色を制御する新たなユーティリティを書くことができる。新たな機能を実行中のアプリケーションに追加するのに、再コンパイルも再リンクも必要としない。
【００６２】
グラフィカル・アプリケーション用のインタラクティブ・デバッガは、この手法の効果が得られる他のプログラム・タイプである。従前のデバッガは、一般に、プログラムを一時停止した後でないと、プログラムの内部状態について詳しく表示することができない。しかしながら、プログラムの操作可能な状態の全てが、本明細書において記載したように、プールを通じて露出されると、デバッガは、プログラムが実行している間に、プログラムの状態を監視することおよびプログラム状態を操作することの双方が可能になる。
【００６３】
ポインタ・プロセスＰおよびスクエア・プロセスＳの双方は、あらゆるディスプレイ出力がユーザに見えるようにするために、グラフィクス・データをフレーム・プールに押し出す。本明細書において説明する実施形態は、グラフィクスを出力するための多数の方法を含む。その一部についてここで詳しく説明する。他の実施形態は、グラフィクス・データをフレーム・プールにプッシュし、グラフィクスを出力するために、以下で説明するプロセスの異なる組み合わせの下で動作することができる。
【００６４】
一実施形態では、プロセスは、OpenGLのような、直接レンダリング・フレームワークを用いて、直接システム・グラフィクス・レイヤに描画することができる。この手法の下では、プールは、グラフィクス・コマンドや画素データのためではなく、調整のために用いられる。
【００６５】
他の実施形態では、レンダリング・コマンドをプールに伝えるプロセスを通じて、グラフィクス・データを出力する。ここでは、他のプロセス（または複数のプロセス）が、レンダリング・コマンドを解釈しシステム・グラフィクス・レイヤをドライブする役割を担う。これらのコマンドは、例えば、ベアOpenGLコール(bare OpenGL calls)のように、非常に低レベルにすることができる。逆に、これらのレンダリング・コマンドは、例えば、専用レンダリング・プロセスがフレーム毎に正方形を描画することができる十分の情報を備えている、前述のtsqureプロテインのように、非常に高レベルにすることができる。
【００６６】
更に他の実施形態では、メモリ内画素バッファにレンダリングし、次いで結果的に得られる生フレーム・データをプールに転送するまたは入れるプロセスを通じて、グラフィクス・データを出力する。他のプロセス（または複数のプロセス）は、生フレーム・データを組み合わせる。プールが扱うデータのボリュームは、一般に、前述したグラフィクス出力手法のものよりも、この手法の方が遥かに大きい。しかしながら、ローカル・レンダリングおよびネットワーク・フレーム・トラスポートは、大量の柔軟性をもたらし、したがって高帯域幅ネットワークおよび高速プール実施態様が利用可能である場合、これが用いられることが多い。
【００６７】
図１Ｃを参照して先に説明したシステム例１００は、一般に、メモリ内画素バッファにレンダリングし、次いで得られた生フレーム・データをプールに転送するプロセスを通じて、グラフィクス・データを出力する。他のプロセス（または複数のプロセス）は、生のフレーム・データを組み合わせる。プールが扱うデータのボリュームは、一般に、この手法の方が前述したグラフィクス出力手法よりも遥かに大きい。しかしながら、ローカル・レンダリングおよびネットワーク・フレーム・トラスポートは、大量の柔軟性をもたらし、したがって高帯域幅ネットワークおよび高速プール実施態様が利用可能である場合、これが用いられることが多い。
【００６８】
したがって、ポインタ・プロセスＰおよびスクエア・プロセスＳは、各々、それら自体の個々のグラフィカル・エレメントをレンダリングする。各プロセスは、色成分の数、およびレンダリングする画素の数を選択する。１つのプロセスは、ＲＧＢＡ（赤、緑、青、アルファ）色空間の成分、またはアルファ配合およびアルファ合成によるＲＧＢ色彩モデルを用いて、ディスプレイの最大数に値する画素（例えば、２５６０×１６００）をレンダリングすることができる。計算サイクル、レンダリング・オーバーヘッド、およびプールの帯域幅を節約するために、しかしながら、プロセスは、特定のグラフィカル・オブジェクトの投影された文字枠(bounding box)を捉えるために、必要なだけの画素のみを生成することもでき、そして輝度（透明度と共に）のレンダリングが十分であれば、２つの成分のみを用いることもできる。
【００６９】
レンダリングされた画素データは、種々のメタデータ（例えば、幾何学的広がり、レイヤリング情報、フレーム・レートの指示、余分な色情報等）と共に、フレーム・プールに転送または伝達される。スクエア・アプリケーションが空間動作環境のコンテキストで実行していると、各プロセスは実世界の幾何学データにアクセスし、しかるべき出力をフレーム・プールの各々に伝達することができる。これには、出力サイクル毎に１つよりも多いフレームをレンダリングすることを伴うこともある。
【００７０】
ローカル・フレーム・プールへのプロテインの貯入(deposit)は、一般に画素データの圧縮を不要にするレートで行われる。しかしながら、インタラクティブ・アプリケーションのために比較的低いレイテンシを達成するには、ネットワーク貯入がフレーム毎に送られるデータ量を低減することができる。一実施形態では、ハードウェア圧縮を用いて、各画素アレイを表すのに必要とされるバイト数を低減するが、本実施形態はそのように限定されるのではない。
【００７１】
図１Ｃを参照すると、システム１００の一実施形態は、専用合成プロセスＣＯＭを用いる。この合成プロセスＣＯＭは、これらのフレーム・レイヤを組み合わせて、１秒毎に多数回、ディスプレイ毎に１つの出力フレームを形成する。総合的なディスプレイ・フレーム・レートは、一般に、システム・レベルの構成選択によって設定されるが、スクエア・アプリケーションを構成する個々のプロセスの各々は、異なるフレーム・レートを用いることができるようになっている。合成プロセスｃｏｍは、フレーム・レイヤをしかるべく対照させる(match up)ように監視する。
【００７２】
図１Ａから図１Ｃを参照しながら先に説明したように、一実施形態のマルチプロセス・インタラクティブ・システムは、プロセス、プール、およびプロテインを含む。システムにおいて無地の矩形は、プロセスを表し、一方楕円はプール、即ち、構造化データ交換のためのメカニズムを表す。プールを通過するデータ・メッセージは、包括的に「プロテイン」と呼ばれる。プロセスの各々は、プロテインを発生し、このプロテインを１つ以上のプールに貯入し、１つ以上のプールからプロテインを引き出す。
【００７３】
プールおよびプロテインは、本明細書において説明する、プロセス間でまたはプロセスに跨って共有されるべきデータをカプセル化するための方法およびシステムの構成要素である。また、これらのメカニズムは、プロテインおよびプールの他に、スロークス（「スロー」(slaw)の複数形）も含む。一般に、スロークスは、プロセス間交換についての最も低いレベルのデータ定義を規定し、プロテインは、中間レベルの構造を規定し、照会(querying)およびフィルタリングを担い(hook for)、プールは、高レベルの編成およびアクセス・セマンティクスを規定する。スロークスは、効率的で、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、スロークスをペイロードとして用いて、データ・カプセル化および移送方式を規定する。プールは、ローカル・プロセス間での、リモートまたは分散プロセス間にあるネットワークを跨いだ、そして長期（例えば、ディスク上等における）記憶を通じた、プロセス内におけるプロテインの構造化された柔軟な集計、順序付け、フィルタリング、および分散を規定する。
【００７４】
マルチプロセス・インタラクティブ・システムの実施形態の構成および実施態様は、様々な構造(construct)を含み、これらが一緒になって多数の能力を可能にする。例えば、本明細書において記載する実施形態は、前述のように大多数のプロセス間におけるデータの効率的な交換に備えている。また、本明細書において記載する実施形態は、柔軟なデータの「分類」 (typing)および構造にも備えているので、広範囲にわたる多様な種類のデータおよび使用をサポートする。更に、本明細書において記載する実施形態は、データ交換のための柔軟なメカニズム（例えば、ローカル・メモリ、ディスク、ネットワーク等）を含み、これらは全て実質的に同様のアプリケーション・プログラミング・インターフェース（ＡＰＩ）によってドライブされる。更に、本明細書において記載する実施形態は、異なるプログラミング言語で書かれたプロセス間におけるデータ交換を可能にする。加えて、本明細書において記載する実施形態は、データ・キャッシュおよび集計状態の自動的な保守を可能にする。
【００７５】
図３は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ表現を含む処理環境のブロック図である。本明細書において紹介する実施形態の主要な構造には、スロークス（「スロー」(slaw)の複数形）、プロテイン、およびプールが含まれる。本明細書において記載する場合、スロークスは、効率的で、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、本明細書において詳細に説明するように、データ・カプセル化および輸送方式を規定し、一実施形態のプロテインのペイロードはスロークスを含む。プールは、本明細書において記載する場合、プロテインの構造化されているが柔軟な集計、順序付け、フィルタ処理、および分散を規定する。プールは、プロテインのための、プロセス内部における、ローカル・プロセッサ間での、リモートまたは分散プロセス間にあるネットワークを跨いだ、そして「長期」（例えば、ディスク上）記憶による、データへのアクセスを与える。
【００７６】
図４は、一実施形態の下におけるプロテインのブロック図である。プロテインは、長さヘッダ、ディスクリップ、およびインジェストを含む。以下で詳細に説明するが、ディスクリップおよびインジェストの各々は、スローまたはスロークスを含む。
【００７７】
図５は、一実施形態の下におけるディスクリップのブロック図である。以下で詳細に説明するが、ディスクリップは、オフセット、長さ、およびスロークスを含む。
図６は、一実施形態の下におけるインジェストのブロック図である。以下で詳細に説明するが、インジェストは、オフセット、長さ、およびスローを含む。
【００７８】
図７は、一実施形態の下におけるスローのブロック図である。以下で詳細に説明するが、スローは、タイプ・ヘッダ、およびタイプ特定データを含む。
図８Ａは、一実施形態の下における、プールの中にあるプロテインのブロック図である。プロテインは、長さヘッダ（「プロテイン長」）、ディスクリップ・オフセット、インジェスト・オフセット、ディスクリップ、およびインジェストを含む。ディスクリップは、オフセット、長さ、およびスローを含む。インジェストは、オフセット、長さ、およびスローを含む。
【００７９】
プロテインは、本明細書において記載する場合、プロセッサ間で共有する、あるいはバスまたはネットワークまたはその他の処理構造を跨いで移動する必要があるデータをカプセル化するメカニズムのことである。一例として、プロテインは、ユーザ・インターフェース・イベントに対応するまたは関連するデータを含むデータの輸送および操作のための改良メカニズムを提供する。具体的には、一実施形態のユーザ・インターフェース・イベントは、米国特許第７，５９８，９４２号に記載されており、引用したことによってその全体が本願にも含まれるものとしたジェスチャ・インターフェースのそれらを含む。更に別の例として、プロテインは、限定ではく、グラフィクス・データまたはイベント、および状態情報等その他多数を含むデータの輸送および操作のための改良メカニズムを提供する。プロテインは、構造化レコード・フォーマット、およびレコードを操作するための１組の関連方法である。本明細書において用いる場合、レコードの操作は、データを構造に入力すること、構造からデータを取り出すこと、およびデータのフォーマットおよび存在を問い合わせることを含む。プロテインは、種々のコンピュータ言語で書かれたコードを通じて用いられるように構成されている。また、プロテインは、本明細書において記載するような、プールの基本的構築ブロックとなるように構成されている。更に、プロテインは、それらが含むデータを不変のまま維持しつつ、プロセッサ間そしてネットワークを跨いで自然に移動できるように構成されている。
【００８０】
従来のデータ輸送メカニズムとは対照的に、プロテインにはタイプが決められていない。タイプは決められていないが、プロテインは、「タイプ状」機能を実装することに加えて、強力で柔軟性のあるパターン照合装置(facility)を備えている。また、本明細書に記載するように構成されているプロテインは、本質的に多点型でもある（しかし、二点間形態も、多点伝送の部分集合として容易に実現される）。加えて、プロテインはメモリ内、ディスク上、およびワイヤ（ネットワーク）上フォーマット間で異なることがない「ユニバーサル」レコード・フォーマットを定義する（即ち、実行する任意の最適化の種類だけが異なる）。
【００８１】
図４および図８を参照すると、一実施形態のプロテインは、バイトの線形シーケンスである。これらのバイトの中には、ディスクリップ・リストと、１組のキー値対がカプセル化されている。キー値対をインジェストと呼ぶ。ディスクリップ・リストは、綿密(elaborate)であるが効率的にフィルタ可能なプロテイン毎のイベント記述を任意に含む。インジェストは、１組のキー値対を含み、これらがプロテインの実際の内容を構成する。
【００８２】
プロテインのキー値対との関わり、ならびにネットワークに都合がよい(network-friendly)多点データ相互交換に関する中核的観念の一部は、「タプル」の概念を特別に許可する(priviledge)もっと簡単なシステム（例えば、Linda、Jini）と共有される。プロテインは、タプル指向システムとは様々な面で大きく異なり、その相違には、標準的、最適化可能なパターン照合基盤を設けるためにディスクリップ・リストを用いることが含まれる。また、プロテインがタプル指向システムと異なるのは、種々の記憶および言語構造に適したレコード・フォーマットの厳格な仕様、そしてそのレコード・フォーマットに対する「インターフェース」の色々な特定的な実施態様である。
【００８３】
プロテインの説明に戻って、プロテインの最初の４バイトまたは８バイトは、プロテインの長さを指定する。一実施形態では、長さは１６バイトの倍数でなければならない。この１６バイトの粒度により、バイト整合およびバス整合効率が現在のハードウェアでも達成可能であることを確保する。本来「４ワード整合」型でないプロテインには、任意のバイトを詰めこんで、その長さが１６バイトの倍数となるようにする。
【００８４】
プロテインの長さ部分は、次のフォーマットを有する。ビッグ・エンディアン・フォーマットで長さを指定する３２ビット。その下位４ビットはマクロ・レベルのプロテイン構造特性を示すフラグとして機能する。プロテインの長さが２＾３２バイトよりも大きい場合、その次に来る更に別の３２ビット。
【００８５】
一実施形態における１６バイト整合条件は、最初の４バイトの最下位ビットがフラグとして利用可能であることを意味する。そして、このため、最下位の３ビット・フラグは、プロテインの長さが最初の４バイトで表現できるのか、または８バイト必要なのかを示し、プロテインがビッグ・エンディアンまたはリトル・エンディアンの内どちらのバイト順序付けを用いるのかを示し、更に、プロテインが標準的構造または非標準的構造のどちらを採用するのかをそれぞれ示すが、プロテインはこのように限定されるのではない。４番目のフラグ・ビットは、今後の使用のために保存されている。
【００８６】
８バイト長フラグ・ビットがセットされている場合、プロテインの長さを計算するには、次の４バイトを読み取り、これらをビッグ・エンディアン、８バイト整数の上位バイトとして用いる（４バイトは既に読み取られ、下位部分を供給する）。リトル・エンディアン・フラグがセットされている場合、プロテインの中にある全ての二進数値データをリトル・エンディアンとして解釈する（それ以外の場合は、ビッグ・エンディアン）。非標準フラグ・ビットがセットされている場合、プロテインの残りの部分は、以下で説明する標準構造に従わない。
【００８７】
非標準プロテイン構造については、プロテインおよびプールを用いるシステム・プログラマには、非標準プロテイン・フォーマットを記述しこれに同期するための種々の方法が利用可能であること、そしてこれらの方法は、空間または計算サイクルが制限されているときに有用となることができることを除いて、ここではこれ以上論じない。例えば、一実施形態では、最短のプロテインは１６バイトである。標準フォーマットのプロテインは、実際のペイロード・データをこれらの１６バイトにはめ込むことは全くできない（その一番大きい部分は既に、プロテインのコンポーネント・パーツの位置を記述することが任されている）。しかし、非標準フォーマット・プロテインは、その１６バイトの内１２バイトをデータに用いることができると考えられる。２つのアプリケーションがプロテインを交換すると、これらが発信するいずれの１６バイト長プロテインでも常に１２バイトを含み、これらは、例えば、リアル・タイム・アナログ／ディジタル変換器からの１２個の８ビット・センサ値を表すことを相互に決定することができる。
【００８８】
長さヘッダの直後には、プロテインの標準構造では、更に２つの可変長整数値が現れる。これらの数値は、それぞれ、ディスクリップ・リストにおける最初のエレメント、および最初のキー値対（インジェスト）に対するオフセットを指定する。これらのオフセットは、本明細書では、それぞれディスクリップ・オフセットおよびインジェスト・オフセットとも呼ぶ。これらの数値の各クアッド(quad)のバイト順序は、プロテイン・エンディアンネス・フラグ・ビット(protein endianness flag bit)によって指定される。各々について、最初の４バイトの最上位ビットは数値が４または８バイト幅のどちらであるかを決定する。最上位ビット（ｍｓｂ）がセットされている場合、最初の４バイトは二重ワード（８バイト）数値の最上位バイトとなる。ここでは、これを「オフセット形式」と呼ぶ。ディスクリップおよび対を指し示す別個のオフセットを用いることにより、ディスクリップおよび対を異なるコード・パスによって扱うことが可能となり、例えば、ディスクリップ・パターン照合およびプロテイン・アセンブリに関する個々の最適化を行うことができるようになる。また、これら２つのオフセットがプロテインの先頭にあるため、様々な有用な最適化に対処できる。
【００８９】
殆どのプロテインは８バイト長またはポインタを必要とする程大きくないので、一般に長さ（とフラグ）および２つのオフセット数値は、プロテインの最初の３バイトを占めるに過ぎない。多くのハードウェアまたはシステム・アーキテクチャでは、最初のバイトを超えるある数のバイトのフェッチ即ちリードは、「自由」である（例えば、１６バイトは、セル・プロセッサ(Cell processor)の主要バスを介して引き込むには、１バイトと全く同じ数のクロック・サイクルを要する。）
多くの場合、プロテイン内部において実施態様特定またはコンテキスト特定のキャッシュ(caching)またはメタデータを許容することは有用である。オフセットの使用により、プロテインの先頭付近に、任意のサイズの「孔(hole)」を作成し、その中にこのようなメタデータを割り込ませることができる。８バイトのメタデータを利用することができる実施態様では、多くのシステム・アーキテクチャ上でこれらのバイトを、長さヘッダをフェッチする毎に１つのプロテインに対して自由に得ることができる。
【００９０】
ディスクリップ・オフセットは、プロテインの先頭と最初のディスクリップ・エントリとの間のバイト数を指定する。各ディスクリップ・エントリは、次のディスクリップ・エントリまでのオフセット（勿論、オフセット形態で）を備えており、その後に可変幅の長さフィールド（これもオフセット・フォーマットで）が続き、更にその後にスローが続く。これ以上ディスクリップがない場合、オフセットは、規則上、０の４バイトとなる。それ以外の場合、オフセットは、当該ディスクリップ・エントリの開始と次との間のバイト数を指定する。長さフィールドは、バイト単位で、スローの長さを指定する。
【００９１】
殆どのプロテインでは、各ディスクリップは、スロー・ストリング様式でフォーマットしたストリングであり、４バイトの長さ／タイプヘッダを有し、最上位ビットがセットされ、下位３０ビットだけが長さを指定するために用いられ、その後に、ヘッダが指示する数のデータ・バイトが続く。通常通り、長さヘッダはそのエンディアンネスをプロテインから取り込む。バイトは、ＵＴＦ−８キャラクタをエンコードすると仮定する（したがって、キャラクタ数は必ずしもバイト数と同じではないことを注記しておく）。
【００９２】
インジェスト・オフセットは、プロテインの先頭と最初のインジェスト・エントリとの間のバイト数を指定する。各インジェスト・エントリは、次のインジェスト・エントリまでのオフセット（オフセット・フォームで）を備えており、その後にこの場合も長さフィールドおよびスローが続く。インジェスト・オフセットは、次のディスクリップ・エントリの代わりに次のインジェスト・エントリを指し示すことを除いて、ディスクリップ・オフセットと機能的には同一である。
【００９３】
殆どのプロテインでは、各インジェストは、スロー・コンス・タイプ(slaw cons type)であり、二値リストを備えている。このリストは通常キー／値対として用いられる。スロー・コンス・レコードは、最上位から２番目のビットがセットされており、下位３０ビットだけが長さを指定するために用いられる４バイトの長さ／タイプ・ヘッダと、４バイトの値（２番目）エレメントの先頭までのオフセットと、前述の４バイトのキー・エレメント長と、キー・エレメントに対するスロー・レコードと、４バイト長の値エレメントと、最後に前述の値エレメントに対するスロー・レコードとを備えている。
【００９４】
一般に、コンス・キーはスロー・ストリングである。数個のプロテインおよびスロー・コンス長ならびにオフセット・フィールドを跨いでデータを複製することにより、工夫(refinement)および最適化の一層多くの機会が得られる。
【００９５】
前述のように、類型に分けたデータをプロテイン内部に埋め込むために一実施形態において用いられる構造は、タグ付きのバイト・シーケンス指定および抽象化(abstraction)であり、「スロー」と呼ばれる（複数形は「slawx」となる）。スローは、類型に分けた（恐らくは、集計）データの一片を表すバイトの線形シーケンスであり、プログラミング言語特定ＡＰＩと関連付けられている。ＡＰＩは、スロークスを作成し、修正し、メモリ空間、記憶媒体、およびマシンの間で移動させることができる。スロー・タイプ方式(slaw type scheme)は、拡張可能でできるだけ軽量であり、あらゆるプログラミング言語からでも用いることができる共通基盤となることを意図している。
【００９６】
効率的な、大規模プロセス間通信メカニズムを構築することの要望が、スロー・コンフィギュレーションの原動力(driver)である。従来のプログラミング言語は、精巧なデータ構造およびタイプ機能を備えており、プロセス特定のメモリ・レイアウトでは申し分なく動作するが、データをプロセッサ間で移動させたり、ディスク上に格納することが必要となると、これらのデータ表現はいつでも決まって分解する。スロー・アーキテクチャは、第１に、プロセス間通信に対する、非常に効率的で、マルチ・プラットフォームに都合がよい低レベル・データ・モデルである。
【００９７】
しかし、更に一層重要なのは、スロークスが、プロテインと共に、今後の計算機ハードウェア（マイクロプロセッサ、メモリ・コントローラ、ディスク・コントローラ）の開発に影響を及ぼし、それを可能にするように構成されていることである。例えば、広く一般に入手可能なマイクロプロセッサの命令セットに、多少の具体的な追加を行うことにより、スロークスが、殆どのプログラミング言語において用いられている方式と同様に、単一プロセス、メモリ内データ・レイアウトに対しても効率的となることが可能になる。
【００９８】
各スローは、可変長のタイプ・ヘッダと、その後に続くタイプ特定データ・レイアウトとを備えている。例えば、Ｃ、Ｃ＋＋、およびRubyにおけるスロー機能を全てサポートする実施形態の一例では、タイプは、各言語からアクセス可能なシステム・ヘッダ・ファイルにおいて定義されているユニバーサル整数(universal integer)によって示される。更に精巧化し柔軟性を高めたタイプ解明機能(type resolution functionality)、例えば、ユニバーサル・オブジェクトＩＤおよびネットワーク参照による間接的類型決定も可能である。
【００９９】
一実施形態のスロー・コンフィギュレーションは、スロー・レコードを、例えば、RubyおよびＣ＋＋双方から言語に優しい様式でオブジェクトとして用いることを可能にする。Ｃ＋＋コンパイラ外部の１組のユーティリティが、スロー・バイト・レイアウトの健全性をチェックし、個々のスロー・タイプに特定的なヘッダ・ファイルおよびマクロを作成し、Rubyに対するバインディング(binding)を自動的に発生する。その結果、正しく構成したスロー・タイプは、１つのプロセスの中から用いた場合でも、非常に効率的となる。プロセスのアクセス可能なメモリのいずれの場所におけるいずれのスローでも、コピーや「非直列化(deserialization)」ステップがなくても、アドレスすることができる。
【０１００】
一実施形態のスロー機能は、以下の内１つ以上を実行するＡＰＩ機能を含む。具体的なタイプの新たなスローを作成する。ディスク上またはメモリ内におけるバイトからのスローへの言語特定参照を作成または構築する。タイプに特定の様式でスロー内にデータを埋め込む。スローのサイズを問い合わせる。スロー内部からデータを引き出す。スローのクローンを作成する。そして、スロー内部にある全てのデータのエンディアンネスおよびその他のフォーマット属性を変換する。スローのあらゆる種(species)が以上の挙動を実施する。
【０１０１】
図８Ｂは、一実施形態の下におけるスロー・ヘッダーのフォーマットを示す。以下にスローの詳細な説明を行う。
各スローの内部構造は、タイプ解明、カプセル化データへのアクセス、および当該スロー・インスタンスについてのサイズ情報の各々を最適化する。一実施形態では、１組のスロー・タイプ全体は、設計上、最小限の全てが揃っており、スロー・ストリング、スロー・コンス（即ち、ダイアッド(dyad)）、スロー・リスト、およびスロー数値オブジェクトを含む。スロー数値オブジェクト自体は、半ダース程度の基本的な属性の組み合わせ(permutation)として理解される、広範な１組の個別数値タイプを表す。いずれのスローでも、その他の基本的プロパティはそのサイズである。一実施形態では、スロークスは、４の倍数に量子化したバイト長を有し、これらの４バイト・ワードを、ここでは「クアッド」と呼ぶ。一般に、このようなクアッドに基づくサイズ決定により、スロークスを最新のコンピュータ・ハードウェア・アーキテクチャのコンフィギュレーションと正確に整合させる。
【０１０２】
一実施形態では、各スローの最初の４バイトは、ヘッダ構造を備えている。ヘッダ構造は、タイプ記述およびその他のメタ情報をエンコードし、特定的なタイプの意味を特定のビット・パターンに帰属させる(ascribe)。例えば、スロー・ヘッダの最初の（最上位）ビットは、そのスローのサイズ（クアッド・ワード単位の長さ）が最初の４バイトのタイプ・ヘッダに従うか否か指定するために用いることができる。このビットがセットされている場合、スローのサイズが当該スローの次の４バイト（例えば、バイト５から８まで）に明示的に記録されていることが分かる。スローのサイズが、４バイトでは表現できないような場合（即ち、サイズが２の３２乗以上である場合）、スローの最初の４バイトの次の最上位ビットもセットする。これは、スローが８バイト（４バイトではなく）長を有することを意味する。その場合、検査プロセスが、序数バイト(ordinal byte)５から１２までに格納されているスローの長さを発見する。他方で、スロー・タイプの数値が小さいことは、多くの場合、完全に指定した類型ビット・パターンが、４バイトのスロー・ヘッダにおける多くのビットを「未使用のまま残してある」ことを意味し、そのような場合、これらのビットは、スローの長さをエンコードするために用いてもよく、そうしなければ必要となるはずのバイト（５から８まで）を取っておくことができる。
【０１０３】
例えば、一実施形態では、スロー・ヘッダの最上位ビット（「長さ従属」フラグ）をセットしないままにしておき、次のビットをセットして、そのスローが「微小コンス(wee cons)」であることを示し、この場合、スローの長さ（クアッド単位）を残りの３０ビットにエンコードする。同様に、「微小ストリング」は、ヘッダにおけるパターン００１によって印され、スロー・ストリングの長さを表すために、２９ビットが残され、ヘッダにおける最初の０００１が「微小リスト」を記述する。これは、２８ビットの利用可能長表現ビットのために、サイズが２から２８クアッドまでのスロー・リストとすることができる。「最大ストリング」（あるいはコンスまたはリスト）は、ヘッダに異なるビット・シグネーチャを有し、ヘッダの最上位ビットは必ずセットされる。何故なら、スロー長はバイト５から８（または、極端な場合には１２）において別個にエンコードされるからである。尚、プラズマ実施態様は、スローの組立時に、これらの構造の「微小(wee)」バージョンまたは「最大(full)」バージョンのどちらを採用すべきか「決定する」（決定は、最終的なサイズが利用可能な微小ビットに「納まるか」否かに基づく）が、最大−対−微小の詳細は、プラズマ実施態様のユーザには隠されている。ユーザは、スロー・ストリング、またはスロー・コンス、またはスロー・リストを用いていることしか知らないし、そのことしか気に留めない。
【０１０４】
一実施形態では、数値スロークスは、最初のヘッダ・パターン００００１によって示される。後続のヘッダ・ビットは、任意の順列に組み合わせることができる１組の直交プロパティを表すために用いられる。一実施形態では、数値が（１）浮動小数点、（２）複素数、（３）符号なし、（４）「広い」、（５）「太くて短い」(stumpy)であるか否かを示すために、５つのこのようなキャラクタ・ビットを用いるが、これらに限定されるのではない（（４）「広い」および（５）「太くて短い」の順序を変えて、８、１６、３２、および６４ビット数表現を示す）。２つの追加ビット（例えば、（７）および（８））は、カプセル化した数値データが、２−、３−、または４−エレメント・ベクトルであることを示す（双方のビットが０の場合、数値が「１−エレメント・ベクトル」（即ち、スカラー）であることを示唆する）。この実施形態では、４番目のヘッダ・バイトの８ビットを用いて、カプセル化した数値データのサイズを（クアッド単位ではなく、バイト単位で）エンコードする。このサイズのエンコード処理は、１から２５６までの間のいずれのサイズでも表すことができるように、１だけずらされる。最後に、２つのキャラクタ・ビット（例えば、（９）および（１０））を用いて、数値データが個々の数値エンティティの配列をエンコードすることを示す。数値エンティティの各々は、キャラクタ・ビット（１）から（８）までによって記述されるタイプのものである。アレイの場合、個々の数値エンティティには、各々、追加のヘッダがアペンドされず、１つのヘッダおよび恐らくは、明示的なスロー・サイズ情報に続く連続データとしてパックされる。  
【０１０５】
この実施形態では、単純かつ効率的なスローの複製（バイト毎のコピーとして実施することができる）、および非常に単純で効率的なスローの比較が可能となる（この実施形態では、連続と見なされる構成バイトの各々に１対１の一致がある場合に限って、２つのスロークスは同一となる）。後者のプロパティは、例えば、プロテイン・アーキテクチャの効率的な実現には重要である。その重要なそして波及する(pervasive)特徴は、プロテインのディスクリップ・リスト全体を検索できること、または「リスト上で照合」できることである。
【０１０６】
更に、本明細書における実施形態は、集計スロー形態（例えば、スロー・コンスおよびスロー・リスト）を簡単かつ効率的に作成することを可能にする。例えば、一実施形態では、スロー・コンスを、いずれのタイプでもよく、これら自体集計を含む、２つの成分スロークスから次のように構築する。（ａ）各成分スローのサイズを問い合わせ、（ｂ）２つの成分スロークスのサイズ、およびヘッダ・プラス・サイズ構造に必要な１、２、または３クアッドの和に等しいサイズのメモリを割り当て、（ｃ）最初の４、８、または１２バイトにスロー・ヘッダ（およびサイズ情報）を記録し、次いで（ｄ）成分スロークスのバイトを順番に、直後に続くメモリにコピーする。重要なのは、このような組立ルーチンは、２つの成分スロークスのタイプについて何も知る必要がなく、それらのサイズ（そして、バイトのシーケンスとしてのアクセス可能性）だけが問題であることである。同じプロセスは、スロー・リストの作成にも関与する。スロー・リストは、（恐らくは）異質なタイプの任意の多くのサブ・スロークス(sub-slawx)の順序付けしたカプセル化である。
【０１０７】
メモリにおける連続バイトとしてのスロー・システムの基本的フォーマットの更に別の成果が、「横断」(traversal)アクティビティと関連して得られる。反復使用パターンが、例えば、スロー・リストに格納されている個々のスロークスへの順次アクセスを用いる。プロテイン構造内部におけるディスクリップおよびインジェストを表す個々のスロークスも同様に横断しなければならない。このような操作は、驚く程単純かつ効率的な方法で遂行される。つまり、スロー・リストにおける次のスローに「進み」、現在のスローの長さをそのメモリ位置に追加し、結果的に得られたメモリ位置が、次のスローのヘッダと同一となる。このような簡素さが可能なのは、スローおよびプロテインの設計が「間接」を避けるからである。つまり、ポインタがなく、データは単純にその全体が本来の場所に存在する。
【０１０８】
スロー比較の時点までに、プラズマ・システムの完全な実施態様は、異なるオペレーティング・システム、ＣＰＵ、およびハードウェア・アーキテクチャに跨ってそしてこれらの間において、異なり互換性のないデータ表現方式の存在を承認しなければならない。このような相違の主要なものには、バイト順序付けポリシ（例えば、リトル−エンディアン対ビッグ−エンディアン）および浮動小数点表現が含まれ、その他の相違も存在する。プラズマ仕様では、スロークスによってカプセル化したデータが解釈可能である(interprable)（即ち、スローを検査している元のアーキテクチャまたはプラットフォームのネーティブ・フォーマットで現れなければならない）。この要件は、一方、プラズマ・システム自体がデータ・フォーマット変換の責任を負うことを意味する。しかしながら、仕様では、スローが、それを検査するかもしれない実行中のプロセスに対して「完全に可視」になる前に変換を行うことしか規定していない。したがって、どの時点でこのようなｃフォーマット変換を実行するかを選択するのは、個々の実施態様次第となる。２つのしかるべき手法があり、それは、（１）個々のスローがパックされていたプロテインから「引き出す」際に、または（２）プロテインが入っていたプールからそのプロテインを抽出する際に、当該プロテインの中にあるスロー全てについて同時に、スロー・データ・ペイロードをローカル・アーキテクチャのデータ・フォーマットに準拠させることである。尚、変換規定は、ハードウェア補助実施態様の可能性も考慮することを注記しておく。例えば、明示的プラズマ能力によって構築したネットワーキング・チップセットは、受信システムの既知の特性に基づいて、インテリジェントにそして「送信の時点」にフォーマット変換を実行することを選択することができる。あるいは、送信のプロセスがデータ・ペイロードを基軸フォーマットに変換することもでき、受信プロセスは、対称的に基軸フォーマットから「ローカル」フォーマットに変換する。別の実施形態では、「メタル」において(at the metal)フォーマット変換を実行する。これが意味するのは、データは、ローカル・メモリの中であっても、常に基軸フォーマットで格納されており、データをメモリから引き出し隣接するＣＰＵのレジスタに入れるときに、メモリ・コントローラ・ハードウェア自体が変換を実行する。
【０１０９】
一実施形態の最小（そして読み取り専用）プロテインの実施態様は、プロテインを利用する１つ以上のアプリケーションまたはプログラミング言語における動作または挙動を含む。図８Ｂは、一実施形態の下でプロテインを用いるための流れ図８５０である。動作を開始すると、８５２においてプロテインの長さをバイト単位で問い合わせる。８５４において、ディスクリップ・エントリの数を問い合わせる。８５６において、インジェストの数を問い合わせる。８５８において、インデックス番号によってディスクリップ・エントリを引き出す。８６０において、インデックス番号によってインジェストを引き出す。
【０１１０】
また、本明細書において記載する実施形態は、プロテインを作成してデータを充填させる基本的な方法、プログラマによって共通のタスクを容易に行えるようにするヘルパ方法、および最適化を遂行するためのフック(hook)も定める。図８Ｃは、一実施形態の下においてプロテインを作成する、即ち、発生するための流れ図８７０である。動作は、８７２における新たなプロテインの作成から開始する。８７４において、一連のディスクリップ・エントリをアペンドする。また、８７６においてインジェストもアペンドする。８７８において、一致するディスクリップの存在を問い合わせ、８８０において、一致するインジェスト・キーの存在を問い合わせる。インジェスト・キーが得られたなら、８８２において、インジェスト値を引き出す。８８４において、ディスクリップ全体でパターン照合を実行する。８８６において、プロテインの先頭付近に、非構造化メタデータを埋め込む。
【０１１１】
前述のように、スロークスはプロセス間交換のための低レベルのデータ定義を規定し、プロテインは問い合わせおよびフィルタ処理のために中間レベルの構造およびフックを規定し、プールは高レベルの編成およびアクセス・セマンティックスについて規定する。プールは、プロテインのためのレポジトリであり、線形シーケンシング(linear sequencing)および状態キャッシング(state caching)に備えている。また、プールは、多数のプログラムまたは多数の異なる種類のアプリケーションによるマルチ・プロセス・アクセスにも備えている。更に、プールは、１組の共通な、最適化可能なフィルタ処理およびパターン照合挙動にも備えている。
【０１１２】
一実施形態のプールは、数万ものプロテインを収容することができ、状態を維持するように機能することができるので、個々のプロセスはマルチ・プロセス・プログラム・コードに共通する厄介なブックキーピングの多くの負担を軽減することができる。プールは、利用可能な過去のプロテインの大きなバッファを維持または保持し、プラトニック・プール(Platonic pool)は明示的に無限であるので、関与するプロセスは、プールにおいて意のままに逆方向および順方向の双方に走査することができる。バッファのサイズは、実施態様に左右されるが、勿論、慣例的な仕様では、プロテインをプールの中に数時間または数日保持できることが多い。
【０１１３】
本明細書において記載するプール使用の最も慣例的な様式では、既存のプロセス間通信フレームワークが採用する機械論的(mechanistic)二点間手法とは対照的に、生物的比喩に従う。プロテインという名称は、生物的発想を暗示する。生物組織における化学的蛋白質が、多数の細胞因子(cellular agent)によるパターン照合およびフィルタ処理に利用可能であるのと同様に、プールの中にあるデータ・プロテインは、多数の計算プロセスによる柔軟な問い合わせおよびパターン照合に利用可能である。
【０１１４】
２つの付加的な抽象化が生物的比喩に同調し(lean)、「ハンドラ」の使用およびゴルジ・フレームワーク(Golgi framework)を含む。プールに関与するプロセスは、一般に、多数のハンドラを作成する。ハンドラは、比較的小さい１群のコードであり、照合条件をハンドル挙動と関連付ける。１つ以上のハンドラをプールに類別することにより、プロセスは、状態をカプセル化し新たなプロテインに反応する、柔軟なコール・バック・トリガ(call-back trigger)を設定する。
【０１１５】
数個のプールに関与するプロセスは、一般に、抽象的ゴルジ・クラスから継承する。ゴルジ・フレームワークは、多数のプールおよびハンドラを管理するための多くの有用なルーチンを提供する。また、ゴルジ・クラスは、親−子関係もカプセル化し、プールを用いないローカル・プロテイン交換のためのメカニズムを提供する。
【０１１６】
一実施形態の下で提供するプールＡＰＩは、種々の方法でプールを実現し、システム特定の目標、ならびに所与のハードウェアおよびネットワーク・アーキテクチャの利用可能な処理能力双方を考慮に入れるように構成されている。プールが依存する２つの基礎的なシステムの常設機構(provision)は、記憶装置およびプロセス間通信手段である。本明細書において記載する、現存する(extant)システムは、共有メモリ、仮想メモリ、および記憶装置用ディスク、ならびにプロセス間通信のためのＩＰＣキューおよびＴＣＰ／ＩＰソケットの柔軟な組み合わせを用いる。
【０１１７】
一実施形態のプールの機能には、限定ではなく、以下が含まれる。プールに関与する。プロテインをプールの中に入れる。次の未見プロテインをプールから引き出す。プール内の内容（例えば、プロテイン）を逆回しまたは早送りする。加えて、プールの機能には、限定ではなく、以下も含むことができる。プロセスに対するストリーミング・プール・コール・バックを設定する。ディスクリップまたはインジェスト・キーの特定のパターンと一致するプロテインを選択的に引き出す。ディスクリップまたはインジェスト・キーの特定のパターンと一致するプロテインについて逆方向および順方向に走査する。
【０１１８】
前述のプロテインは、他のアプリケーションとプロテイン・データ・コンテンツを共有する方法として、プールに供給される。図９は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。この環境例は、前述のようにスロークス、プロテイン、およびプールの使用によりデータを共有する３つのデバイス（例えば、デバイスＸ、デバイスＹ、およびデバイスＺ、ここでは纏めて「デバイス」と呼ぶ）を含む。これらのデバイスの各々は、３つのプール（例えば、プール１、プール２、プール３）に結合されている。プール１は、それぞれのデバイスから当該プールに提供または転送された多数のプロテイン（例えば、プロテインＸ１、プロテインＺ２、プロテインＹ２、プロテインＸ４、プロテインＹ４）を含む（例えば、プロテインＺ２は、デバイスＺによってプール１に転送または提供された等）。プール２は、それぞれのデバイスから当該プールに提供または転送された多数のプロテイン（例えば、プロテインＺ４、プロテインＹ３、プロテインＺ１、プロテインＸ３）を含む（例えば、プロテインＹ３は、デバイスＹによってプール２に転送または提供された等）。プール３は、それぞれのデバイスから当該プールに供給または転送された多数のプロテイン（例えば、プロテインＹ１、プロテインＺ３、プロテインＸ２）を含む（例えば、プロテインＸ２は、デバイスＸによってプール３に転送または提供された等）。前述の例では、３つのプール間に結合または接続されている３つのデバイスが含まれるが、あらゆる数のデバイスを、あらゆる数のプール間に如何様にでもまたはいずれの組み合わせでも結合または接続することができ、いずれのプールも、あらゆる数または組み合わせのデバイスから提供されるあらゆる数のプロテインを含むことができる。この例のプロテインおよびプールについては、図３から図８までを参照しながら先に説明した。
【０１１９】
図１０は、多数のデバイスと、これらのデバイスの１つ以上で起動する多数のプログラムを含む処理環境のブロック図であり、一実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、多数のデバイス（例えば、デバイスＡ、Ｂ等）およびこれらのデバイス上で起動する多数のプログラム（例えば、appsAA-AX、appsBA-BX等）を備えている双方向処理システムが、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。
【０１２０】
この例では、各デバイス（例えば、デバイスＡ、Ｂ等）は、それぞれのデバイス上で走っているプログラム（例えば、appsAA-AX、appsBA-BX等）が発生したまたは出力された離散生データを、プラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入する。例えば、プログラムＡＸはデータまたは出力を発生し、この出力をデバイスＡに供給する。一方、デバイスＡはこの生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、プログラムＢＣがデータを発生し、このデータをデバイスＢに供給する。一方、デバイスＢはこのデータをプロテイン（例えば、プロテイン１Ｂ、プロテイン２Ｂ等）に変換し、これらのプロテインをプールに貯入する。
【０１２１】
各プロテインは、アプリケーションが発生し、プログラム自体についての情報を特定するデータまたは出力を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップは出力イベントまたは行動について一般的なセマンティックな意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、プログラム・イベントについての１組の有用な状態情報全体を搬送する。
【０１２２】
前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で起動しているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマ(consumer)を多重化し、デバイスを一人で制御できるように、または数人（例えば、プラズマ・ベースの入力フレームワークは、多くの同時ユーザをサポートする）で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに見えるようになることである。
【０１２３】
一例として、デバイスＣは１つ以上のプロテイン（例えば、プロテイン１Ａ、２Ａ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、プロテイン・データが対応する処理イベントにおいて用いることができる。別の例として、デバイスＢは、プールから１つ以上のプロテイン（例えば、プロテイン１Ｃ、プロテイン２Ａ等）を抽出することができる。プロテインの抽出に続いて、デバイスＢは、プロテイン・データが対応する処理イベントにおいて、プロテインのデータを用いることができる。
【０１２４】
プールに結合または接続されているデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
【０１２５】
図１１は、多数のデバイスと、これらのデバイスの１つ以上で起動する多数のプログラムを含む処理環境のブロック図であり、一代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、多数のデバイス（例えば、デバイスＡおよびＢにそれぞれ結合されているデバイスＸおよびＹ）および１つ以上のコンピュータ（例えば、デバイスＡ、デバイスＢ等）上で起動する多数のプログラム（例えば、appsAA-AX、appsBA-BX等）を備えている双方向処理システムが、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。
【０１２６】
この例では、各デバイス（例えば、デバイスＡおよびＢにそれぞれ結合されているデバイスＸおよびＹ）は、デバイス・ハードウェア（例えば、デバイスＸ、デバイスＡ、デバイスＹ、デバイスＢ等）が発生した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス（例えば、デバイスＡ、デバイスＢ等）上にホストされている１つ以上のプログラムの下で、またはこれらと連携して動作するように管理および／または結合されている。例えば、デバイスＡ上にホストされているアプリケーションＡＢと連携して動作するデバイスＸは、生データを発生し、この離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、デバイスＡ上にホストされているアプリケーションＡＴと連携して動作するデバイスＸが、離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａなど）に変換し、これらのプロテインをプールに貯入する。更に別の例として、デバイスＣ上にホストされているアプリケーションＣＤと連携して動作するデバイスＺは、生データを発生し、この離散生データをプロテイン（例えば、プロテイン１Ｃ、プロテイン２Ｃ等）に変換し、これらのプロテインをプールに貯入する。
【０１２７】
各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的なセマンティックな意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、デバイス・イベントについての１組の有用な状態情報全体を搬送する。
【０１２８】
前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で起動しているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人（例えば、プラズマ・ベースの入力フレームワークは、多くの同時ユーザをサポートする）で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。
【０１２９】
プールに結合または接続されているデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
【０１３０】
図１２は、多数の入力デバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、双方向処理システムは、多数の入力デバイス（例えば、入力デバイスＡ、Ｂ、ＢＡ、およびＢＢ等）を備えており、１つ以上のコンピュータ（例えば、デバイスＡ、デバイスＢ等）上で起動する多数のプログラム（図示せず）を備えており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。
【０１３１】
この例では、各入力デバイス（例えば、入力デバイスＡ、Ｂ、ＢＡ、およびＢＢ等）は、入力デバイス・ハードウェアが発生した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス（例えば、デバイスＡ、デバイスＢ等）上にホストしたソフトウェア・ドライバ・プログラムによって管理される。例えば、入力デバイスＡは生データを発生し、この生データをデバイスＡに供給する。一方、デバイスＡは離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、入力デバイスＢＢは生データを発生し、この生データをデバイスＢに供給する。一方、デバイスＢは離散生データをプロテイン（例えば、プロテイン１Ｂ、プロテイン３Ｂ等）に変換し、これらのプロテインをプールに貯入する。
【０１３２】
各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的なセマンティックな意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、デバイス・イベントについての１組の有用な状態情報全体を搬送する。
【０１３３】
例示のために、ここに、このようなシステムにおける２つの典型的なイベントに対するプロテインを示す。ここでは、プロテインはテキストとして表すが、実際の実施態様では、これらのプロテインの構成部分は、類別されたデータ・バンドル（例えば、スロー）である。g-speak "one finger click" pose（「指１本によるクリック」のポーズ）（関連出願に記載されている）を記述するプロテインは、次の通りである。
【０１３４】
【表９】
0005805537.tif 000010
【０１３５】
別の例として、マウスのクリックを記述するプロテインは次の通りである。
【０１３６】
【表１０】
0005805537.tif 000011
【０１３７】
以上のプロテインの見本のいずれかまたは双方は、そのコードの特定の部分を起動させるホスト・デバイスの関与プログラム(participating program)を生ずる可能性もある。これらのプログラムは、一般的なセマンティック・レベルに関係する場合がある。全ての内最も一般的なのは「point」であり、更に具体的な対は「engage, one」である。また、これらは、正確なデバイス：「one-finger-engage」または正に１つの集計オブジェクト(aggregate object)「hand-id-23」のみによってもっともらしく発生されるイベントを求めている場合もある。
【０１３８】
前述のように、プロテインは、プログラムやデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが用いるために、プールにおいて利用可能である。したがって、あらゆる数のコンピュータ上で起動するあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出する。これらのデバイスは、プロテインをプールから抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、入力イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人（例えば、プラズマ・ベースの入力フレームワークは、多くの同時ユーザをサポートする）で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。
【０１３９】
プロテイン使用の一例として、デバイスＣは１つ以上のプロテイン（例えば、プロテイン１Ｂ等）をプールから抽出することができる。プロテイン抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、当該プロテイン・データが対応する入力デバイスＣＡおよびＣＣの入力イベントを処理する際に用いることができる。別の例として、デバイスＡは、１つ以上のプロテイン（例えば、プロテイン１Ｂ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＡは、プロテイン・データが対応する入力デバイスＡの入力イベントを処理する際に、当該プロテインのデータを用いることができる。
【０１４０】
プールに結合または接続されているデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
【０１４１】
本明細書において記載するシステムの実施形態に用いられる入力デバイスの例には、ジェスチャ入力センサ、キーボード、マウス、消費者電子機器において用いられるような赤外線リモコン装置、およびタスク指向有体媒体オブジェクト(task-oriented tangible media object)、その他にも数多く含まれる。
【０１４２】
図１３は、多数のデバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする。このシステムは、多数の実行中のプログラム（例えば、グラフィクスＡ〜Ｅ）および１つ以上のディスプレイ・デバイス（図示せず）を備えているシステムの一例に過ぎず、プログラムの一部または全部のグラフィック出力が、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いて、調整しながら他のプログラムにも利用可能とし、実行中のプログラムが、これらのデバイスによって発生したグラフィック・イベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。
【０１４３】
コンピュータ・プログラムが、別のプログラムによって発生したグラフィクスを表示することが有用な場合は多い。広く知れ渡っている様々な例には、テレビ会議アプリケーション、ネットワークを用いたスライドショーおよびデモ・プログラム、ならびにウィンドウ・マネージャが含まれる。この構成の下では、プールは、ビデオ、ネットワーク・アプリケーション共有、およびウィンドウ管理をカプセル化したフレームワークを一般化して実施するためにプラズマ・ライブラリとして用いられ、プログラマは、このようなプログラムの現バージョンでは一般には入手できない多数の特徴に追加することが可能になる。
【０１４４】
プラズマ合成環境において起動するプログラム（例えば、グラフィクスＡ〜Ｅ）は、プールへの結合および／または接続を通じて、調整プールに関与する。各プログラムは、種々の種類のグラフィック・ソースの可用性を示すために、そのプールにプロテインを貯入する。また、グラフィックスを表示するために利用可能なプログラムも、それらの表示処理能力、セキュリティおよびユーザ・プロファイル、ならびに物理的位置およびネットワーク位置を示すために、プロテインを貯入する。
【０１４５】
また、グラフィクス・データをプールを通じて送信することもでき、あるいは表示プログラムに、他の種類（例えば、ＲＴＳＰストリーム）のネットワーク・リソースを指し示させることもできる。「グラフィクス・データ」という用語は、本明細書において用いる場合、広義の連続体(broad continuum)に沿って存在する種々の異なる表現のことを指し、グラフィクス・データの例には、文字で表現される例（例えば、「画像」、または画素のブロック）、手順的例（例えば、典型的なopenGLパイプラインを下って行くような一連の「描画」指令）、および記述的例（例えば、幾何学的変形、クリッピング、および合成動作によって他のグラフィック構造を組み合わせる命令）が含まれるが、これらに限定されるのではない。
【０１４６】
ローカル・マシン上では、グラフィクス・データは、プラットフォーム特定の表示ドライバ最適化を通じて配信することもできる。プールを通してグラフィクスを送信しない場合でも、多くの場合、周期的な画面キャプチャは、調整プールに格納されるので、より内部(esoteric)のソースに直接アクセスできないクライアントであっても、フォールバック・グラフィクス(fall-back graphics)を表示することもできる。
【０１４７】
本明細書において記載するマルチプロセス・インタラクティブ・システムは、殆どのメッセージ伝達フレームワークおよびネットワーク・プロトコルとは異なり、プールがデータの大量のバッファを維持することである。したがって、プログラムはプールの中に逆戻りして、アクセスおよび使用パターン（調整プールの場合）を見たり、以前のグラフィクス・フレーム（グラフィクス・プールの場合）を抽出することができる。
【０１４８】
図１４は、多数のデバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする。このシステムは、多数のデバイス（例えば、デバイスＡ、デバイスＢ等）上に多数の実行プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）を備えており、一部のプログラムがプールを用いてまたはプールを通じて他のプログラムの内部状態にアクセスするシステムの一例に過ぎない。
【０１４９】
殆どの双方向処理コンピュータ・システムは、多くのプログラムを備えており、これらは、１台のマシンまたは多数のマシン上で互いに一緒に起動し、ネットワークを跨いで双方向処理を行う。実行時データが各プロセス内部に隠されアクセスするのが困難なので、マルチ・プログラム・システムは、構成設定、分析、およびデバッグするのが難しい。本明細書において記載する一実施形態の一般化したフレームワークおよびプラズマ構造は、実行中のプログラムがプールを通じてそれらのデータの多くを利用可能にするので、他のプログラムがそれらの状態を検査することができる。このフレームワークによって、従来のデバッガよりも柔軟なデバッギング・ツール、精巧なシステム保守ツール、および１つまたは複数のプログラムが通過した一連の状態を、人の操作者に詳細に分析させるように構成された可視化ハーネスを可能にする。
【０１５０】
図１４を参照すると、このフレームワークにおいて起動するプログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）は、プログラムの起動時にプロセス・プールを発生または作成する。このプールは、システム・アルマナックに登録され、セキュリティおよびアクセス制御が適用される。更に特定すると、各デバイス（例えば、デバイスＡ、Ｂ等）が、それぞれのデバイス上で起動するプログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が発生または出力した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールの中に貯入する。例えば、プログラムＰ−Ａは、データまたは出力を発生し、この出力をデバイスＡに供給する。一方、デバイスＡは、この生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ、プロテイン３Ａ等）に変換し、これらのプロテインをプールの中に貯入する。別の例として、プログラムＰ−Ｂはデータを発生し、このデータをデバイスＢに供給する。一方、デバイスＢは、データをプロテイン（例えば、プロテイン１Ｂ〜４Ｂ等）に変換し、これらのプロテインをプールの中に貯入する。
【０１５１】
プログラムの寿命の期間中、十分なアクセス許可を有する別のプログラムがプールに接続し(attach)、プログラムが貯入したプロテインを読み取ることもできる。これは、基本的な検査様式を表し、概念的に「一方向」即ち「読み取り専用」の提案(proposition)である。プログラムＰ−Ａに関与するエンティティが、そのプロセス・プールの中にＰ−Ａによって貯入されたステータス情報の流れを検査する。例えば、デバイスＣの下で起動する検査プログラムまたはアプリケーションが１つ以上のプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出した即ち読み出したプロテインのデータを用いて、プログラムＰ−Ａの内部状態にアクセスし、これを解釈し、検査することができる。
【０１５２】
しかし、プラズマ・システムは単に効率的なステートフル(stateful)伝送方式であるだけでなく、全方向メッセージング環境であることを思い起こすと、様々な追加モードがプログラム対プログラムの状態検査をサポートする。許可された検査プログラムは、それ自体でプロテインをプログラムＰのプロセス・プールに貯入して、生成してそのプロセス・プールの中に入れた状態情報の特性に影響を及ぼし、これらの特性を制御することができる（結局、プログラムＰはプロセス・プールに書き込むだけでなく、そこから読み取りも行う）。
【０１５３】
図１５は、多数のデバイスを含み、これらが当該デバイスの１つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、追加の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる。このシステム例では、デバイスＣの検査プログラムは、例えば、プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が、１回だけまたは特定の期間にわたって、通常よりも多い状態をプールにダンプすることを要求することができる。または、デバッグ通信の次の「レベル」を予示しておくと、関与するプログラムは、プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が、デバッグ・プールを通じた双方向処理が個々に可能でありそのために利用可能な、その実行時間環境において残存するオブジェクトを一覧に纏めたプロテインを放出(emit)することを要求することができる。このように通知すると、関与するプログラムはプログラムの実行時においてオブジェクトの中の個々に「アドレス」し、特定のオブジェクトだけが専有し応答するプロセス・プールにプロテインを入れることができる。関与するプログラムは、例えば、オブジェクトが、その成分変数全ての瞬時値を記述した報告プロテインを放出することを要求することもあり得る。それよりも更に重要なのは、関与するプログラムが、他のプロテインを通じて、オブジェクトにその挙動またはその変数の値を変更するように指令できることである。
【０１５４】
更に具体的には、この例では、デバイスＣの検査アプリケーションが、プールの中に、オブジェクト・リスト（例えば、「要求−オブジェクト・リスト」）の要求を（プロテインの形態で）入れて、次いでこのプールに結合されている各デバイス（例えば、デバイスＡ、デバイスＢ等）が抽出する。要求に応答して、各デバイス（例えば、デバイスＡ、デバイスＢ等）がプールの中に、その実行時環境において残存する、デバッグ・プールを通じて個々に検査することができそのために利用可能なオブジェクトを一覧に纏めたプロテイン（例えば、プロテイン１Ａ、プロテイン１Ｂ等）を入れる。
【０１５５】
このようにデバイスからのリストを通じて通知され、オブジェクトのリストに応答して、デバイスＣの検査アプリケーションは、プログラム実行中におけるオブジェクトの中の個々にアドレスし、特定のオブジェクトのみが専有し応答するプロセス・プールにプロテインを入れる。デバイスＣの検査アプリケーションは、例えば、要求プロテイン（例えば、プロテイン「要求報告Ｐ−Ａ−Ｏ」、「要求報告Ｐ−Ｂ−Ｏ」）を、オブジェクト（例えば、それぞれ、オブジェクトＰ−Ａ−Ｏ、オブジェクトＰ−Ｂ−Ｏ）が、その成分変数の全ての瞬時値を記述する報告プロテイン（例えば、プロテイン２Ａ、プロテイン２Ｂ等）を放出するプールに入れる。各オブジェクト（例えば、オブジェクトＰ−Ａ−Ｏ、オブジェクトＰ−Ｂ−Ｏ）は、その要求（例えば、それぞれ、プロテイン「要求報告Ｐ−Ａ−Ｏ」、「要求報告Ｐ−Ｂ−Ｏ」）を抽出し、それに応答して、要求された報告（例えば、それぞれ、プロテイン２Ａ、プロテイン２Ｂ）を含むプールにプロテインを入れる。次いで、デバイスＣは種々の報告プロテイン（例えば、プロテイン２Ａ、プロテイン２Ｂ等）を抽出し、適宜報告の内容に合わせて続く処理アクションを実行する。
【０１５６】
このように、プラズマを相互交換媒体として用いると、デバッグ処理、プロセス制御、ならびにプログラム対プログラムの通信および調整の間にある区別を究極的に解消し易くなる。
【０１５７】
このため、一般化したプラズマ・フレームワークは、疎結合の様式で可視化および分析プログラムを設計することを可能にする。例えば、メモリ・アクセス・パターンを表示する可視化ツールは、基本的なメモリ・リードおよびライトをプールに出力するいずれのプログラムとでも合わせて用いることができる。分析を受けるプログラムは、可視化ツールの存在や設計を知る必要がなく、その逆も成り立つ。
【０１５８】
以上のようにプールを用いると、システム性能に不当に影響を及ぼすことはない。例えば、実施形態は、毎秒数十万個のプロテインをプールに貯入することを考慮しているので、比較的冗漫なデータ出力を可能にしても、殆どのプログラムの応答性や双方向処理特性を著しく阻害することはない。
空間動作環境（ＳＯＥ）
マルチプロセス・インタラクティブ・システムは、空間動作環境（ＳＯＥ）の構成要素であること、またはこれと共に用いるために結合することができる。ＳＯＥは、ジェスチャ制御システムまたはジェスチャ基準制御システムを含み、空間ユーザ・インターフェース（ＳＵＩ）または空間インターフェース（ＳＩ）と呼ぶこともできる。一例として、図１６は、一実施形態の下における空間動作環境（ＳＯＥ）のブロック図である。ユーザは、彼の手１６０１および１６０２を、カメラ１６０４Ａ〜１６０４Ｄのアレイの視野に置く。これらのカメラは、指ならびに手１６０１および１６０２の位置、方位、および移動を検出し、出力信号をプリプロセッサ１６０５に発生する。プリプロセッサ１６０５は、カメラ出力をジェスチャ信号に変換し、このジェスチャ信号をシステムのコンピュータ演算装置１６０７に供給する。コンピュータ１６０７は、入力情報を用いて、１つ以上の画面上カーソルを制御するコマンドを発生し、ビデオ出力をディスプレイ１６０３に供給する。
【０１５９】
このシステムでは、一人のユーザの手を入力として示すが、ＳＯＥは、多数のユーザを用いても実施することができる。加えて、手の代わりにまたは手に加えて、本システムはユーザのボディの任意の１つ以上の部分を追跡することができ、その部分とは、頭部、足、脚部、腕、肘、膝等を含む。
【０１６０】
図示の実施形態では、４台のカメラまたはセンサを用いて、視野１６５０内においてユーザの手１６０１および１６０２の位置、方位、および移動を検出する。ＳＯＥの範囲や主旨から逸脱することなく、ＳＯＥはこれらよりも多いカメラ（例えば、６台のカメラ、８台のカメラ等）または少ないカメラ（例えば、２台のカメラ）とでも用いることができることは言うまでもない。加えて、実施形態例では、カメラまたはセンサは対称的に配置されているが、ＳＯＥにはこのような対称性の要件はない。ユーザの手の位置、方位、および移動を許容するのであれば、カメラまたはセンサは、いずれの数および位置付けでも、ＳＯＥにおいて用いることができる。
【０１６１】
一実施形態では、用いられるカメラは、グレー・スケール画像を取り込むことができるモーション・キャプチャ・カメラである。一実施形態では、用いられるカメラは、Vicon MX40カメラのような、Vicon社が製造するカメラである。このカメラは、カメラ内部処理を含み、毎秒１０００フレームの画像取り込みが可能である。モーション・キャプチャ・カメラは、マーカを検出し位置を突き止めることができる。
【０１６２】
記載している実施形態では、カメラは光学的検出に用いられるセンサである。他の実施形態では、カメラまたは他の検出器は、電磁、静磁気、ＲＦＩＤ、またはその他の任意の適した種類の検出に用いることができる。
【０１６３】
プリプロセッサ１６０５は、三次元空間点再現および骨格点ラベリングを発生するために用いられる。ジェスチャ変換器１６０６は、３Ｄ空間情報およびマーカ・モーション情報をコマンド言語に変換するために用いられる。コマンド言語は、コンピュータ・プロセッサによって解釈され、ディスプレイ上におけるカーソルの位置、形状、および動作(action)を更新することができる。ＳＯＥの代替実施形態では、プリプロセッサ１６０５およびジェスチャ変換器１６０６を組み合わせて１つのデバイスにすることもできる。
【０１６４】
コンピュータ１６０７は、Apple社、Dell社、または任意のその他の適した製造業者によって製造されるような、任意の汎用コンピュータとすればよい。コンピュータ１６０７は、アプリケーションを起動し、表示出力を供給する。カーソル情報は、他の場合にはマウスまたはその他の先行技術の入力デバイスから得られるが、ここではジェスチャ・システムから得られる。
【０１６５】
ＳＯＥまたは一実施形態は、ユーザの１つ以上の指においてマーカ・タグの使用を想定し、本システムがユーザの手を突き止め、ユーザが左または右のどちらの手を見ているのか特定し、どの指が見えるか特定することができるようにする。これによって、本システムは、ユーザの手の位置、方位、および移動を検出することが可能になる。この情報によって、本システムは多数のジェスチャを認識することが可能となり、これらのジェスチャは、ユーザによってコマンドとして用いることが可能になる。
【０１６６】
一実施形態では、マーカ・タグは基板（本実施形態では、人の手の上の種々の位置に装着するのに適している）と、基板の表面上に一意識別パターンで配列された離散マーカとを備えている物理的タグである。
【０１６７】
マーカおよび連携する外部検知システムは、それらの三空間位置の高精度、正確、ならびに迅速および連続的捕獲が可能である任意のドメイン（光学、電磁、静磁気等）において動作することができる。マーカ自体は、能動的（例えば、構造化した電磁パルスを放出することによって）、または受動的（例えば、本実施形態におけるように光学的に逆反射型とすることによって）のいずれでも動作することができる。
【０１６８】
各捕獲フレームにおいて、検出システムは、器具を備え付けた作業空間立体（カメラまたはその他の検出器の可視範囲内）において現在タグからの全てのマーカを含む三空間位置を再現した、粒団状「クラウド」を受ける。各タグ上のマーカは、十分に多数であり、一意のパターンに配列されているので、検出システムは以下のタスクを行うことができる。（１）再現した各マーカ位置を、１つのタグを形成する点の１つのみの副集合体に割り当てるセグメント化、（２）セグメント化した点の各副集合体を特定のタグとして識別するラベリング、（３）識別したタグの三空間位置を再現する位置突き止め、および（４）識別したタグの三空間方位を再現する方位決定(orientation)。タスク（１）および（２）は、マーカ・パターンの具体的な本質によって可能となる。これについては、図１７の一実施形態において以下で説明し例示する。
【０１６９】
一実施形態では、タグ上のマーカは、規則的な格子位置の部分集合に装着されている。この基礎となる格子は、本実施形態のように、従来からのデカルト型であってもよいし、代わりに、他の何らかの規則的平面碁盤目状（例えば、三角形／六角形タイリング配列）であってもよい。格子のスケールおよび空間は、隣接する格子位置が混乱する可能性がないように、マーカ検知システムの既知の空間分解能に関して確定する。全てのタグについてのマーカ・パターンの選択は、次の制約を満たさなければならない。タグのパターンは、回転、平行移動、または鏡像のいずれの組み合わせによる他のいずれのタグ・パターンとも一致してはならない。更に、ある指定した数のコンポーネント・マーカの損失（または遮蔽(occlusion)が許容されるように、多数のマーカおよびその配列を選択するとよい。いずれの任意の変換後であっても、損なったモジュール(compromised module)を他のいずれとも混同させることが起こりそうにないようにしなければならない。
【０１７０】
ここで図１７を参照すると、多数のタグ１７０１Ａ〜１７０１Ｅ（左手）および１７０２Ａ〜１７０２Ｅ（右手）が示されている。各タグは、矩形であり、本実施形態では、５×７の格子アレイで構成されている。矩形形状が選択されたのは、タグの方位を決定し易いため、そして鏡面複製(mirror duplicate)の可能性を低減するためである。図示の実施形態では、各手の指毎にタグがある。実施形態によっては、手毎に１つ、２つ、３つ、または４つのタグを用いることが適当である場合もある。各タグは、異なるグレー・スケールまたは色調の境界を有する。この境界の内部には、３×５格子アレイがある。マーカ（図１７の黒いドットで表す）は、情報を提供するために、この格子のある点に配置されている。
【０１７１】
各パターンを「共通」および「一意」のサブパターンにセグメント化することにより、タグのマーカ・パターンにおいて、認定情報(qualifying information)をエンコードすることができる。例えば、本実施形態は、２つの可能な「境界パターン」、矩形境界線(boundary)を中心としたマーカの分布を指定する。つまり、タグの「ファミリー」を確立する。このため、左手を意図したタグは、タグ１７０１Ａ〜１７０１Ｅにおいて示されるような同じ境界パターンを全て用いることができ、一方右手の指に取り付けられているタグには、タグ１７０２Ａ〜１７０２Ｅに示すように異なるパターンを割り当てることができる。タグの全ての方位において、左パターンを右パターンから区別できるように、このサブパターンを選択する。図示した例では、左手パターンは、各角に１つのマーカ、そして角格子位置から２番目に１つのマーカを含む。右手パターンは、２つの角のみにマーカを有し、角でない格子位置に２つのマーカを有する。このパターンを検査することによって、４つのマーカの内いずれか３つが見ることができる限り、左手パターンを右手パターンから明確に区別することができることが明らかとなった。一実施形態では、境界の色または色調も、利き手(handedness)のインディケータとして用いることができる。
【０１７２】
各タグは、勿論、一意の内部パターンを採用し続けなければならず、マーカはそのファミリーの共通境界以内に分散されている。図示の実施形態では、内部格子アレイにおける２つのマーカが、１０本の指の各々を一意に特定するのに十分であり、指の回転または方位による複製が生じないことが分かる。マーカの１つが遮蔽されたとしても、タグのパターンおよび利き手の組み合わせから、一意の識別子が得られる。
【０１７３】
本実施形態では、格子の位置は、各逆反射マーカをその意図する位置に装着する（手作業の）タスクに対する補助として、視覚的に剛性基板上に存在する。これらの格子および意図するマーカ位置は、カラー・インクジェット・プリンタによって基板上にそっくりそのまま印刷される。ここでは、基板はシート状の（初期状態では）可撓性の「収縮フィルム」である。各モジュールがこのシートから切り離され、炉で焼成される。この熱処理の間に、各モジュールには正確で繰り返し可能な収縮が起こる。この手順に続く短い間隔において、冷却するタグには、例えば、指の長手方向曲線にしたがって、僅かに形状を付けることができる。その後、基板は適度に剛性となり、マーカを、指示された格子点に装着することができる。
【０１７４】
一実施形態では、マーカ自体は、接着剤または何らかのその他のしかるべき手段によって基板に装着された小さな反射球体のように、三次元である。このマーカが三次元であることは、二次元マーカ上における検出および位置突き止めに役立つことができる。しかしながら、いずれも、本明細書に記載するＳＯＥの主旨や範囲から逸脱することなく用いることができる。
【０１７５】
現在では、タグはベルクロまたはその他のしかるべき手段によって、操作者が身に付けている手袋に装着されるか、あるいは、柔らかな両面テープを用いて操作者の指に直接装着される。第３実施形態では、剛性基板を全くなしで済ませ、操作者の指および手に直接個々のマーカを装着するまたは「描く」することができる。
【０１７６】
ＳＯＥは、手のポーズ、方位、手の組み合わせ、および方位の配合(orientation blends)で構成されるジェスチャ・ボキャブラリ(gesture vocabulary)を想定する。ＳＯＥのジェスチャ・ボキャブラリにおいてポーズおよびジェスチャを立案および伝達するために、表記言語(notation language)も実施する。ジェスチャ・ボキャブラリとは、力学的連結の瞬時的な「ポーズ状態」を簡潔な文字形態で表すシステムである。対象となる連結は、生物（例えば、人の手、または人のボディ全体、あるいはバッタの足、あるいはキツネザルの関節脊柱）であってもよく、あるいは代わりに非生物であってもよい（例えば、ロボットのアーム）。いずれの場合でも、この連結は、単純（脊柱）でもまたは分岐（手）でもよい。ＳＯＥのジェスチャ・ボキャブラリ・システムは、いずれの特定的な連結についても、一定長のストリングを確立する。こうして、ストリングの「キャラクタ位置」を占める特定のＡＳＣＩＩキャラクタの集合体が、連結の瞬時的状態、即ち、「ポーズ」の一意の記述となる。
【０１７７】
図１８は、ＳＯＥを用いたジェスチャ・ボキャブラリの一実施形態における手のポーズを示す。ＳＯＥは、１本の手における５本の指の各々を用いることを仮定する。これらの指には、ｐ−小指、ｒ−薬指、ｍ−中指、ｉ−人差し指、およびｔ−親指とコーディングする。指および親指の多数のポーズを、一実施形態のジェスチャ・ボキャブラリにおいて定義し例示する。ジェスチャ・ボキャブラリ・ストリングは、連結（この場合指）の表現可能な自由度毎に１つのキャラクタ位置を確定する。更に、このような各自由度は、離散化（または「量子化」）されていることが分かるので、その最大運動範囲は、当該ストリング位置における有限数の標準的ＡＳＣＩＩキャラクタの内の１つの割り当てによって表現することができる。これらの自由度は、ボディ特定の原点および座標系（手の裏、バッタのボディの中心、ロボット・アームの底辺等）に関して表現される。したがって、連結の位置および方位を「全体的に」更に大域的な座標系において表現するために、少数の追加のジェスチャ・ボキャブラリ・キャラクタ位置が用いられる。
【０１７８】
引き続き図１８を参照すると、多数のポーズが定義されており、ＡＳＣＩＩキャラクタを用いて識別されている。これらのポーズの一部は、親指およびそれ以外の指の間で分けられている。この実施形態におけるＳＯＥは、ＡＳＣＩＩキャラクタ自体がポーズを示唆するようなコーディングを用いる。しかしながら、示唆的であろうがなかろうが、ポーズを表すには、いずれのキャラクタでも用いることができる。加えて、本発明では、表記ストリングにＡＳＣＩＩキャラクタを用いる必要性はない。本発明の範囲や主旨から逸脱することなく、適したシンボル、数値、またはその他の表現であればいずれでも用いることができる。例えば、望ましければ、表記は指毎に２ビットを用いることもでき、あるいは所望に応じて、他の何らかの数のビットを用いることもできる。
【０１７９】
巻き込んだ指(curled finger)は、キャラクタ「＾」によって表され、一方巻き込んだ親指は「＞」で表される。真っ直ぐな指または上を向いた親指は、「ｌ」によって示され、角度をなす場合は「＼」または「／」で示される。「−」は、真っ直ぐに横を向いた親指を表し、「ｘ」は平面内に向いた親指を表す。
【０１８０】
これら個々の指および親指の記述を用いると、確固不動の数(robust number)の手のポーズを、本発明の方式を用いて、定義し記述することができる。各ポーズは、５つのキャラクタによって表され、その順序は、前述したように、ｐ−ｒ−ｍ−ｉ−ｔとなる。手を平らにして地面に平行に保持する場合、「ｌｌｌｌｌ」で表される。握り拳は「＾＾＾＾＞」によって表される。「ＯＫ」の合図は、「ｌｌｌ＾＞」によって表される。
【０１８１】
キャラクタ・ストリングは、示唆的キャラクタを用いる場合、単純な「人間可読性」(human readabiity)の機会を与える。各自由度を記述する１組の可能なキャラクタは、総じて、素早い認識および明白な類似性に着目して選択することができる。例えば、垂直線（「｜」）は、連結エレメントが「直線状」であることを意味するように思われ、エル（「Ｌ」）は、９０度の屈曲を意味することもでき、曲折アクセント記号（「＾」）は、鋭角の屈曲を示すことができる。先に注記したように、所望に応じて、いずれのキャラクタまたはコーディングでも用いることができる。
【０１８２】
本明細書に記載するようなジェスチャ・ボキャブラリ・ストリングを採用するシステムはいずれも、ストリング比較の高い計算効率の恩恵を享受する。指定されたいずれのポーズについても、その識別または検索は、文字どおり、所望のポーズ・ストリングと瞬時的な実際のストリングとの間における「ストリングの比較」（例えば、ＵＮＩＸ（登録商標）の「stremp()」関数）となる。更に、「ワイルドカード・キャラクタ」の使用によって、プログラマやシステム設計者には、もっと見慣れた効率(efficiency)および有効性(efficacy)が得られる。自由度の瞬時状態が一致とは関わりがない場合、疑問符（「？」）として指定することができ、追加のワイルドカードの意味を割り当てることができる。
【０１８３】
指および親指のポーズに加えて、手の方位が情報を表すことができる。大域空間(global-space)方位を記述するキャラクタも、透過的に選択することができる。キャラクタ「＜」、「＞」、「＾」、および「ｖ」は、方位キャラクタ位置において遭遇した場合、左、右、上、および下の考えを示すために用いることができる。図１９は、手方位記述子、ならびにポーズおよび方位をコード化する例を示す。一実施形態では、２つのキャラクタ位置が、最初に手の平の方向を指定し、次いで指の方向を指定する（指が真っ直ぐになっている場合、指の実際の屈曲には関係なく）。これら２つの位置に可能なキャラクタは、方位の「ボディ中心」観念(body-centric notion)を表現し、「−」、「＋」、「ｘ」、「＊」、「＾」、および「ｖ」は、中間、横方向、前方（順方向、ボディから離れる側）、後方（逆方向、ボディから離れる側）、頭上（上方）、および後端（下方）を記述する。
【０１８４】
本発明の表記方式および実施形態では、キャラクタを示す５本指のポーズに続いて、コロン、次いで完全なコマンド・ポーズを定義するために２つの方位キャラクタがある。一実施形態では、開始位置は「ｘｙｚ」ポーズと呼ばれ、親指は真っ直ぐ上を指し示し、人差し指は前方を指し示し、中指は人差し指に対して垂直であり、右手によってこのポーズが作られる場合、左を指し示す。これは、ストリング「＾＾ｘｌ−：−ｘ」によって表される。
【０１８５】
「ＸＹＺ−手」は、視覚的に提示された三次元構造の最大６自由度のナビゲーションを可能にするために、人の手の幾何学的形状を利用する技法である。この技法は操作者の手の全体的(bulk)平行移動および回転のみに依存し、したがってその指は原則として、いずれの所望のポーズに保持することができるが、本実施形態は、人差し指がボディから離れる方向を指し、親指が天井を指し、中指が左−右を指す、静止構成(static configuration)を優先する。つまり、これら３本の指は、三空間座標系の３本の相互に直交する軸、つまり、「ＸＹＺ−手」を記述する（大まかであるが、明白な歴然とした趣旨がある）。
【０１８６】
次いで、ＸＹＺ−手ナビゲーションは、操作者のボディの前において所定の「中立位置」に保持された、前述のようなポーズの手、指に進む。三空間オブジェクト（またはカメラ）の三平行移動および三回転自由度へのアクセス(access)は以下の自然な方法で行われる。手の右−左移動（ボディの自然座標系に対して）により、計算的コンテキストのｘ−軸に沿った移動が生じ、手の上下移動により、被制御コンテキストのｙ−軸に沿った移動が生じ、前後の手の移動（操作者のボディに向かう方向／から離れる方向）によって、このコンテキストにおけるｚ−軸運動が生ずる。同様に、人差し指を中心とする操作者の手の回転により、計算的コンテキストの方位の「転動」(roll)変化が生じ、操作者の手の中指および親指をそれぞれ中心とする回転によって、「縦方向」および「横方向」変化が類似的に生ずる。
【０１８７】
尚、「計算的コンテキスト」は、本明細書では、ＸＹＺ−手方法によって制御される全体に言及するために用いられており、合成三空間オブジェクトまたはカメラのいずれかを示唆するように思われるが、この技法は実世界オブジェクトの種々の自由度を制御するため、例えば、しかるべき回転アクチュエータを装備したビデオまたはモーション・ピクチャ・カメラのパン／ティルト／ロール制御にも等しく有用であることは言うまでもないことを注記しておく。更に、ＸＹＺ−手の姿勢によって得られる物理的自由度は、仮想ドメインであっても、ありのままにマッピングされ難い場合もある。本実施形態では、ＸＹＺ−手は、大きな全景的表示画像に対してナビゲーション的アクセスを提供するためにも用いられるので、操作者の手の左−右および上−下の運動が、画像を中心とする予期された左−右または上−下「パンニング」に繋がるが、操作者の手の前−後運動は「ズーミング」制御にマッピングする。
【０１８８】
あらゆる場合において、手の運動と誘発される計算的平行移動／回転との間の結合は、直接的（即ち、操作者の手の位置的または回転オフセットが、一対一で、何らかの線形または非線形関数によって、計算的コンテキストにおけるオブジェクトまたはカメラの位置的または回転オフセットにマッピングする）、または間接的（即ち、操作者の手の位置的または回転オフセットが、一対一で、何らかの線形または非線形関数によって、計算的コンテキストにおける位置／方位の第１導関数またはより上位の導関数にマッピングし、実行中の積分が、計算的コンテキストの実際のゼロ次位置／方位における被静的変化を生み出す）のいずれかであることができる。この後者の制御手段は、自動車の「アクセル・ペダル」の使用に類似しており、ペダルの一定のオフセットによって、ほぼ一定の車速が得られる。
【０１８９】
実世界のＸＹＺ−手の局所的六自由度座標原点としての役割を果たす「中立位置」は、（１）空間における絶対位置および方位として（例えば、密閉室に対する）、（２）操作者の全体的な位置および「方向」(heading)には関係なく、操作者自身に対する固定位置および方位（例えば、ボディの前方８インチ、顎の下１０インチ、横方向に肩の平面と一直線状）として、あるいは（３）操作者の故意の二次的行動によって、対話的に（例えば、操作者の「別の」手によって演じられるジェスチャ・コマンドを用いて。前記コマンドは、ＸＹＺ−手の現在の位置および方位が今後平行移動および回転の原点として用いられるべきことを示す）確立することができる。
【０１９０】
更に、ＸＹＺ−手の中立位置の周囲に「抑止」(detent)領域（または「デッド・ゾーン」）を設けて、この立体空間における移動が被制御コンテキストにおける移動にマッピングしないようにすると便利である。
【０１９１】
他のポーズも含むことができる。
[lllll:vx]は、手を平らにして（親指が他の指と平行）、手のひらが下を向き、指が前方に突き出している。
【０１９２】
[lllll:x^]は、手を平らにして、手のひらが前を向き、指が天井を向いている。
[lllll:-x]は、手を平らにして、手のひらがボディの中心に向いており（左手の場合は右、右手の場合は左）、指が前方に突き出している。
【０１９３】
[^^^^-:-x]は、手を１つにして親指を合わしている（親指は天井を向いている）。
[^^^|-:-x]は、銃を前方に構える真似である。
一実施形態のＳＯＥは、１つの手のコマンドおよびポーズだけでなく、２つの手によるコマンドおよびポーズも想定している。図２０は、一実施形態の下における、ＳＯＥのジェスチャ・ボキャブラリにおける二手組み合わせおよ対応する表記の例を示す。第１の例の表記を検討すると、「完全停止(full stop)」とは２つの拳を閉じていることを示す。「スナップショット」の例では、各手の親指および人差し指が広げられ、親指が互いに向き合って、ゴール・ポストの形状の枠を定めている。「舵およびスロットル開始位置」は、指および親指が上を向いており、手のひらが画面に面している。
【０１９４】
図２１は、一実施形態のＳＯＥの下における方位配合の一例を示す。図示の例では、配合は、指ポーズ・ストリングの後ろにある括弧の中に囲まれた方位表記の対によって表されている。例えば、第１コマンドは、全て真っ直ぐに伸ばした指の位置を示す。方位コマンドの第１対により、手のひらをディスプレイに向かって平らにして、第２対によって、手を画面に向けて４５度縦に回転させる。この例では、配合の対を示したが、ＳＯＥではいずれの数の配合でも考えられる。
【０１９５】
図２３は、ＳＯＥと共に用いることができる、多数の可能なコマンドを示す。本明細書における論述の一部は、ディスプレイ上におけるカーソルの制御についてであったが、ＳＯＥはその行動に限定されるのではない。実際に、ＳＯＥは、画面上における全てのデータおよびデータの一部、更にはディスプレイの状態を操作する際に、様々に応用することができる。例えば、ビデオ・メディアの再生中に、これらのコマンドをビデオ制御に代わって用いることができる。これらのコマンドは、一時停止、早送り、巻き戻しなどを行うために用いることができる。加えて、画像のズーム・インおよびズーム・アウトを行うため、画像の方位を変化させるため、いずれかの方向にパンニングするため等に実施することができる。また、ＳＯＥは、開く、閉じる、保存する等のような、メニュー・コマンドの代わりに用いることもできる。言い換えると、想像することができるいずれのコマンドまたはアクティビティでも、手のジェスチャによって実施することができる。
【０１９６】
図２２は、一実施形態におけるＳＯＥの動作を示す流れ図である。ステップ２２０１において、検出システムはマーカおよびタグを検出する。判断ブロック２２０２において、タグおよびマーカが検出されたか否か判断を行う。検出されていない場合、システムはステップ２２０１に戻る。ステップ２２０２においてタグおよびマーカが検出された場合、システムはステップ２２０３に進む。ステップ２２０３において、システムは、検出されたタグおよびマーカから、手、指、およびポーズを識別する。ステップ２２０４において、システムは、ポーズの方位を識別する。ステップ２２０５において、システムは、検出された１つまたは双方の手の三次元空間位置を識別する。（ステップ２２０３、２２０４、および２２０５の内いずれでも、または全てを１つの動作として組み合わせてもよいことに注意されたい）。
【０１９７】
ステップ２２０６において、以上の情報を、前述したジェスチャ表記に変換する。判断ブロック２２０７において、ポーズが有効か否か判断を行う。これは、発生した表記ストリングを用いた単純なストリング比較によって行うことができる。ポーズが有効でない場合、システムはステップ２２０１に戻る。ポーズが有効である場合、ステップ２２０８において、システムは表記および位置情報をコンピュータに送る。ステップ２２０９において、コンピュータは、ジェスチャに応答して、取るべきしかるべきアクションを決定し、ステップ２２１０においてそれに応じてディスプレイを更新する。
【０１９８】
ＳＯＥの一実施形態では、動作２２０１〜２２０５をカメラ内蔵プロセッサによって実行する。他の実施形態では、望ましければ、この処理をシステム・コンピュータによって実行することもできる。
【０１９９】
本システムは、基礎となるシステムによって再現された低レベルのジェスチャの流れを「解析(parse)」および「変換(translate)」し、これら解析し変換したジェスチャを、コマンドまたはイベント・データの流れに変換することができる。このデータは、広範囲のコンピュータ・アプリケーションおよびシステムを制御するために用いることができる。これらの技法およびアルゴリズムは、これらの技法を実現するエンジン、およびエンジンの能力を利用するコンピュータ・アプリケーションを構築するプラットフォームの双方を提供するコンピュータ・コードから成るシステムにおいて具体化することができる。
【０２００】
一実施形態は、コンピュータ・インターフェースにおいて、人の手の豊富なジェスチャの使用を可能にすることを中心に据えるが、他のボディ部分によって行われるジェスチャ（限定ではなく、腕、胴体、脚部、および頭部を含む）や、手ではない種々の器具によって行われるジェスチャを認識することもできる。これらの器具は、静止および連結式(articulating)双方であり、限定ではないが、キャリパ、コンパス、可撓性曲線近似器(curve approximator)、および種々の形状のポインティング・デバイスが含まれる。マーカおよびタグは、操作者によって所望に応じて携行および使用することができる品目および器具に被着することができる。
【０２０１】
本明細書において記載するシステムは、認識し反応することができるジェスチャの範囲が豊富なジェスチャ・システムを構築することを可能にしつつ、同時にアプリケーションへの容易な統合にも備えた、多数の改革を組み込む。
【０２０２】
一実施形態では、ジェスチャ解析および変換システムは、以下のものを備えている。
１）様々な異なる集計レベルにおいて、ジェスチャを指定する（コンピュータ・プログラムにおいて用いるためのエンコード）緻密かつ効率的な方法。
【０２０３】
ａ．１本の手の「ポーズ」（手の部分の外形および互いに対する方位）。三次元空間における１つの手の方位および位置。
ｂ．２つの手の組み合わせ。いずれかの手がポーズ、位置、または双方を考慮に入れる。
【０２０４】
ｃ．多数の人物の組み合わせ。本システムは２つよりも多い手を追跡することができ、したがって、一人よりも多い事物が協同して（ゲーム・アプリケーションの場合には競合して）目標システムを制御することができる。
【０２０５】
ｄ．ポーズが連続して組み合わされる順次ジェスチャ。これらを「動画」ジェスチャと呼ぶ。
ｅ．操作者が空間内の形状を追跡する「書記素」ジェスチャ(grapheme gesture)。
【０２０６】
２）所与のアプリケーション・コンテキストに関連があるものの上で、各カテゴリから特定のジェスチャを登録するプログラム技法。
３）登録されているジェスチャを識別することができ、これらのジェスチャをカプセル化するイベントを関連するアプリケーション・コンテキストに配信することができるように、ジェスチャの流れを解析するアルゴリズム。
【０２０７】
指定システム（１）は、構成エレメント（１ａ）から（１ｆ）と共に、本明細書に記載するシステムのジェスチャ解析および変換能力を利用するための基礎を提供する。
１本の手の「ポーズ」は、
ｉ）手の指と甲との間の相対的方位、
ｉｉ）少数の離散状態への量子化、
のストリングとして表される。
【０２０８】
相対的接合方位を用いることにより、本明細書に記載するシステムは、手のサイズおよび外形形状が異なることに伴う問題を回避することができる。このシステムでは、「操作者較正」を必要としない。加えて、ポーズをストリングまたは相対的方位の集合体として指定することにより、ポーズ表現を更に別のフィルタおよび指定と組み合わせることによって、一層複雑なジェスチャ指定(specification)を容易に作成することが可能になる。
【０２０９】
ポーズ指定に少数の離散状態を用いることによって、ポーズを簡潔に指定することができ、更に種々の基礎となる追跡技術（例えば、カメラを用いた受動的光学追跡、点灯ドットおよびカメラを用いた能動的光学追跡、電磁場追跡等）を用いて、精度の高いポーズ認識を確実に行うことができる。
【０２１０】
各カテゴリ（１ａ）から（１ｆ）におけるジェスチャは、部分的に（または最小限に）指定することができるので、重大でないデータは無視される。例えば、２本の指の位置が明確であり他の指の位置は重要でないジェスチャは、２本の関連のある指の動作位置が与えられ、同じストリング内において、「ワイルド・カード」または包括的「無視」インディケータが他の指に対して掲示されている１つの指定によって表すことができる。
【０２１１】
本明細書において記載するジェスチャ認識のための改革の全ては、限定ではなく、多層指定技法、相対的方位の使用、データの量子化、および各レベルにおける部分的または最小指定の許容を含み、手のジェスチャの指定を超えて、他のボディ部分や「製造した」器具およびオブジェクトを用いたジェスチャの指定に一般化する。
【０２１２】
「ジェスチャを登録する」プログラム技法（２）は、どのジェスチャをエンジンが実行システムの他の部分に入手可能にすべきか定めることをプログラマに可能にする、定められた１組のアプリケーション・プログラミング・インターフェース・コールによって構成されている。
【０２１３】
これらのＡＰＩルーチンは、アプリケーション設定時に用いることができ、実行アプリケーションの寿命の間用いることができる静止インターフェース定義を作成する。また、これらは、実行中にも用いることができ、インターフェース特性を動作中に変更することができる。このリアル・タイムでのインターフェース変更により、
ｉ）複雑なコンテキストおよび条件付き制御状態を構築すること、
ｉｉ）動的にヒステリシスを制御環境に追加すること、および
ｉｉｉ）ユーザが実行システム自体のインターフェース・ボキャブラリを変更または拡張することができるアプリケーションを作成すること、
が可能となる。
【０２１４】
ジェスチャの流れを解析するアルゴリズム（３）は、（１）におけるように指定され（２）におけるように登録されたジェスチャを、入来する低レベルのジェスチャ・データと比較する。登録されているジェスチャに対する一致が認識された場合、一致したジェスチャを表すイベント・データが積層され実行アプリケーションに配信される。
【０２１５】
このシステムの設計においては、効率的なリアル・タイムでの照合が望まれ、指定されたジェスチャは、できるだけ素早く処理される可能性のツリーとして扱われる。
加えて、指定されたジェスチャを認識するために内部で使用されている原始的比較演算子は、アプリケーション・プログラマが用いるためにも露出されるので、アプリケーション・コンテキスト内部からでも、より多くの比較（例えば、複雑なジェスチャまたは複合ジェスチャにおける柔軟な状態の検査）を行うことができる。
【０２１６】
認識「ロッキング」セマンティクス(recognition locking semantics)は、本明細書に記載するシステムの改革の１つである。これらのセマンティクスは、登録ＡＰＩ（２）（および、より狭い範囲で、指定ボキャブラリ（１）内に埋め込まれる）によって暗示される(imply)。登録ＡＰＩコールは、
ｉ）「エントリ」状態通知部および「連続」状態通知部、ならびに
ｉｉ）ジェスチャ優先度指定部
を含む。
【０２１７】
ジェスチャが認識されている場合、その「連続」状態は、同じまたは低い優先度のジェスチャの全ての「エントリ」状態よりも優先される。このエントリ状態と連続状態との間の区別は、認められるシステム使用可能性に大きくプラスになる。
【０２１８】
本明細書において記載するシステムは、実世界のデータ・エラーおよび不確実性をものともせずに、ロバストな動作のためのアルゴリズムを含む。低レベル追跡システムからのデータは不完全である場合もある（光学追跡におけるマーカの遮蔽、ネットワーク・ドロップアウト、処理の遅れ等を含む、種々の理由による）。
【０２１９】
欠損データは、解析システムによって印が付けられ、その欠損データの量およびコンテキストに応じて、「最後に分かっていた」状態または「最もあり得る」状態のいずれかに組み込まれる。
【０２２０】
特定のジェスチャ・コンポーネント（例えば、特定の関節の方位）についてのデータが見つからないが、その特定のコンポーネントの「最後に分かっていた」状態を、物理的に可能であると分析することができる場合、本システムはこの最後に分かっていた状態をそのリアル・タイム照合において用いる。
【０２２１】
逆に、最後に分かっていた状態が、物理的に不可能であると分析された場合、本システムはそのコンポーネントにとって「最良のジェスチャ範囲」に後退し、この合成データをそのリアル・タイム照合において用いる。
【０２２２】
本明細書において記載する指定および解析システムは、「利き手不可知論」をサポートするように注意深く設計されているので、多数の手のジェスチャについて、いずれの手でもポーズの要件を満たすことができる。
【０２２３】
一実施形態のシステムは、１つ以上のディスプレイ・デバイス（「画面」）上に描かれた仮想空間を、当該システムの一人または複数の操作者によって占められる物理空間と一致するものとして扱う環境を提供することができる。このような環境の一実施形態についてここで説明する。この現実施形態は、固定位置に３つのプロジェクタ・ドライブ画面を含み、１つのデスクトップ・コンピュータによってドライブされ、本明細書に記載したジェスチャ・ボキャブラリおよびインターフェース・システムを用いて制御される。しかしながら、記載する技法は、いかなる数の画面でもサポートすること、これらの画面は移動可能であってもよいこと（固定ではなく）、画面は多くの独立したコンピュータによって同時にドライブしてもよいこと、そしてシステム全体はいずれの入力デバイスまたは技法によっても制御できることを注記しておく。
【０２２４】
本開示において記載するインターフェース・システムは、物理空間における画面の寸法、方位、および位置を決定する手段を有していなければならない。この情報を仮定して、本システムは、これらの画面が配置されている（そして、本システムの操作者が占める）物理空間を、本システム上で実行しているコンピュータ・アプリケーションの仮想空間への投影として動的にマッピングすることができる。この自動マッピングの一部として、本システムは、システムによってホストされているアプリケーションの必要性に応じて、種々の方法で２つの空間の規模、角度、深さ、寸法、およびその他の空間特性も変換する。
【０２２５】
この物理空間と仮想空間との間における連続変換によって、既存のアプリケーション・プラットフォームでは達成が困難である、または既存のプラットフォーム上で実行するアプリケーション毎に１つ１つ実装しなければならない多数のインターフェース技法の一貫性があり普及する使用が可能となる。これらの技法は、（限定ではないが）以下を含む。
【０２２６】
１）「リテラル・ポインティング」(literal pointing)の広く行き渡る自然なインターフェース技法としての使用。ジェスチャ・インターフェース環境において手を用いるか、あるいは物理的ポインティング・ツールまたはデバイスを用いる。
【０２２７】
２）画面の移動または再位置決めに対する自動補償。
３）操作者の位置に応じて変化するグラフィクス・レンダリング。例えば、深度の知覚を高めるためにパララックス・シフトをシミュレーションする。
【０２２８】
４）実世界位置、方位、状態等を考慮に入れた、画面上表示への物理的オブジェクトの含入。例えば、大きく不透明な画面の前に立っている操作者は、アプリケーションのグラフィクスと、画面の背後にある（そして、恐らく移動しているか、または方位を変えている）スケール・モデル(scale model)の真の位置の表現との双方を見ることができる。
【０２２９】
リテラル・ポインティングは、マウス・ベースのウィンドーイング・インターフェースや殆どのその他の現在のシステムにおいて用いられている絶対ポインティングとは異なることを注記するのは重要である。これらのシステムでは、操作者は仮想ポインタと物理ポインティング・デバイスとの間の変換を管理することを学習しなければならず、更にこれら２つの間で経験的知識に基づいてマッピングしなければならない。
【０２３０】
対照的に、本開示において記載するシステムでは、アプリケーションまたはユーザの観点のいずれからでも、仮想空間と物理空間との間に差がないので（仮想空間の方が数学的操作がし易いことを除く）、操作者に経験的知識に基づく変換は必要とされない。
【０２３１】
本明細書において記載する実施形態によって提供されるリテラル・ポインティングに最も近い類似性は、接触感応画面（例えば、多くのＡＴＭマシン上で見られる）である。接触感応画面は、画面上の二次元表示空間と画面表面の二次元入力空間との間に１対１のマッピングを規定する。同様に、本明細書において記載するシステムは、１つ以上の画面上に表示される仮想空間と、操作者によって占められる物理空間との間に柔軟なマッピング（１対１のマッピングも可能であるが、その必要性はない）を規定する。この類似性の有益さ(usefulness of the analogy)にも拘わらず、この「マッピング手法」の三次元、任意に大きなアーキテクチャ環境、および多数の画面への拡張は重要である。
【０２３２】
本明細書において記載するコンポーネントに加えて、本システムは、環境の物理空間と各画面上の表示空間との間に連続的なシステム・レベルのマッピング（恐らく回転、平行移動、倍率調整、またはその他の幾何学的変換によって変更される）を実現するアルゴリズムも実装することができる。
【０２３３】
レンダリング・スタックは、計算オブジェクトおよびマッピングを取り込み、仮想空間のグラフィカル表現を出力する。
入力イベント処理スタックは、制御システムからイベント・データを取り込み（現実施形態では、システムおよびマウス入力からのジェスチャ・データおよびポインティング・データの双方）、入力イベントからの空間データを仮想空間における座標にマッピングする。次いで、変換されたイベントは、実行中のアプリケーションに配信される。
【０２３４】
「グルー・レイヤ」は、システムが、ローカル・エリア・ネットワークにある数台のコンピュータに跨って実行するアプリケーションをホストすることを可能にする。
ＳＯＥについての前述の説明を考慮すると、ＳＯＥは、図１から図１Ｃまでおよび本明細書における他のところを参照して先に説明したマルチプロセス・インタラクティブ・システムの構成要素として用いること、および／またはマルチプロセス・インタラクティブ・システムに結合することができる。一実施形態のＳＯＥは、先に説明したように、ユーザ入力プロテインをユーザ入力プールＵｉに伝達するジェスチャ／空間プロセスＧとしてカプセル化することができる。
【０２３５】
本明細書における実施形態は、ジェスチャ・データからボディによって行われたジェスチャを検出するシステムおよび方法を含む。ジェスチャ・データは、検出器を通じて受け取られる。一実施形態のシステムおよび方法は、処理デバイス上において多数のプロセスを実行する。これらのプロセスは、ジェスチャを表す１組のイベントを含むイベントを発生する。一実施形態のシステムおよび方法は、各プロセスのイベントをデータ・カプセルに変換する。一実施形態のシステムおよび方法は、これらのデータ・カプセルを多数のプールまたはレポジトリに転送する。多数のプロセスにおける１組のプロセスは、認識プロセスとして動作する。この認識プロセスは、プールにおいて、ジェスチャに対応する内容を備えているデータ・カプセルを認識する。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生する。ジェスチャ信号はジェスチャを表す。
【０２３６】
図２４は、一実施形態の下において、マルチプロセス・インタラクティブ・システムのコンポーネントと共に実装する、またはマルチプロセス・インタラクティブ・システムとして実装する空間動作環境（ＳＯＥ）（図１ＣのエレメントＧを参照）のブロック図である。ユーザは、彼の手２４０１および２４０２をカメラ２４０４Ａ〜２４０４Ｄのアレイの視野２４５０に置く。これらのカメラは、指ならびに手２４０１および２４０２の位置、方位、および動きを検出、出力信号をプリプロセッサ２４０５に発生する。プリプロセッサ２４０５は、カメラ出力をジェスチャ信号に変換し、このジェスチャ信号を本システムのコンピュータ・プロセッサに供給する。この実施形態では、前述のコンピュータ２４０７によって実行される、コンピュータ・プロセッサの機能は、マルチプロセス・インタラクティブ・システム（図１Ｃ）のプロセッサによって実行すること、および／またはマルチプロセス・インタラクティブ・システムに結合することができる。ジェスチャ信号は、マルチプロセス・インタラクティブ・システムのプール（プールＵｉ、図１Ｃ）に供給または転送することができる。その結果、マルチプロセス・インタラクティブ・システムはジェスチャ信号を用いて、マルチプロセス・インタラクティブ・システムに結合されている１つ以上のコンポーネント（例えば、ディスプレイ・カーソル等）を制御するコマンドを発生する。
【０２３７】
本システムでは、１人のユーザの手を入力として示すが、ＳＯＥは、多数のユーザを用いても実現することができる。加えて、手の代わりまたは手に加えて、本システムは、ユーザのボディであればいずれの１つまたは複数の部分でも追跡することができ、その部分には、頭部、足、脚部、腕、肘、膝等が含まれる。
【０２３８】
図示した実施形態では、視野２４５０におけるユーザの手２４０１および２４０２の位置、方位、および移動を検出するために用いられる４台のカメラを用いる。尚、ＳＯＥの範囲や趣旨から逸脱することなく、ＳＯＥは、これらよりも多いカメラ（例えば、６台のカメラ、８台のカメラ等）または少ないカメラ（例えば、２台のカメラ）、あるいはセンサとでも用いることができることは言うまでもない。加えて、実施形態例では、カメラまたはセンサは対称的に配置されているが、ＳＯＥにはこのような対称性の要件はない。ユーザの手の位置、方位、および移動を許容するのであれば、カメラまたはセンサは、いずれの数および位置付けでも、ＳＯＥにおいて用いることができる。
【０２３９】
一実施形態では、用いられるカメラは、グレー・スケール画像を取り込むことができるモーション・キャプチャ・カメラである。一実施形態では、用いられるカメラは、Vicon MX40カメラのような、Vicon社が製造するカメラである。このカメラは、カメラ内部処理を含み、毎秒１０００フレームの画像取り込みが可能である。モーション・キャプチャ・カメラは、マーカを検出し位置を突き止めることができる。
【０２４０】
記載している実施形態では、カメラは光学的検出に用いられるセンサである。他の実施形態では、カメラまたは他の検出器は、電磁、静磁気、ＲＦＩＤ、またはその他の任意の適した種類の検出に用いることができる。
【０２４１】
プリプロセッサ２４０５は、三次元空間点再現および骨格点ラベリングを発生するために用いられる。ジェスチャ変換器２４０６は、３Ｄ空間情報およびマーカ・モーション情報をコマンド言語に変換するために用いられる。コマンド言語は、プールＵｉ（図１参照）から情報を受信するマルチプロセス・インタラクティブ・システムのコンポーネントによって解釈することができる。ＳＯＥの代替実施形態では、プリプロセッサ２４０５およびジェスチャ変換器１０６を統合してまたは組み合わせて１つのデバイスにすることもできる。
【０２４２】
図２５は、一実施形態の下において、ジェスチャ制御システムからの入力を用いるマルチプロセス・インタラクティブ・システム１００（図１参照）の動作の流れ図２５００である。これらの動作は、ボディによって行われたジェスチャを、ジェスチャ・データから検出すること（２５０２）を含む。ジェスチャ・データは、検出器を通じて受信される。この動作は、処理デバイス上で複数のプロセスを実行する（２５０４）ことを含む。これらのプロセスは、ジェスチャを表す１組のイベントを含むイベントを発生する。これらのプロセスは、空間動作アプリケーションの分離可能なプログラム実行コンテキストを含むが、そのように限定されるのではない。各プロセスのイベントをデータ・カプセルに変換する（２５０６）。データ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、データ・カプセルから発生したプロセスの状態情報とを含むが、そのように限定されるのではない。データ・カプセルを複数のプールに転送する（２５０８）。多数のプロセスの内１組のプロセスが、認識プロセスとして動作する。認識プロセスは、プールにおいて、ジェスチャに対応する内容を備えているデータ・カプセルを認識する（２５１０）。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生する（２５１２）。このジェスチャ信号は、ジェスチャを表す。
【０２４３】
本明細書において記載した実施形態は、方法を含む。この方法は、少なくとも１つの処理デバイス上において複数のプロセスを実行するステップと、これら複数のプロセスの内各プロセスのイベントをデータ・カプセルに変換するステップと、このデータ・カプセルを複数のプールに転送するステップと、各プロセスが認識プロセスとして動作するステップであって、認識プロセスが、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、当該認識プロセスの識別との内少なくとも１つを備えているデータ・カプセルを認識する、ステップと、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するステップとを備えている。
【０２４４】
一実施形態のデータ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージが発生したプロセスの状態情報とを含む。
一実施形態の方法は、データ・カプセルおよび複数のプールを用いて、複数のプロセスの各々の動作を調整することによって、複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている。
【０２４５】
一実施形態の方法は、データ・カプセルおよび複数のプールの内少なくとも１つを用いて、複数のプロセスの動作を調整するステップを備えている。
一実施形態の方法は、アプリケーション・プログラムを１組のプロセスに分割するステップを備えており、複数のプロセスが１組のプロセスを含む。
【０２４６】
一実施形態の方法は、複数のプールの内少なくとも１つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている。
【０２４７】
一実施形態の複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備えている。
【０２４８】
一実施形態の方法は、複数のプロセスを並列に実行するステップを備えている。
一実施形態の方法は、第１組のプロセスを並列に実行し、第２組のプロセスを順次実行するステップを備えており、複数のプロセスが第１組のプロセスおよび第２組のプロセスを含む。
【０２４９】
一実施形態のイベントは、プロセス入力を表す。
一実施形態のイベントは、プロセス出力を表す。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。
【０２５０】
一実施形態のイベントは、グラフィクスイベントを備えている。
一実施形態のイベントは、イベントがプロセスの状態を表す。
一実施形態のプロセスの状態は、当該プロセスのインタラクティブ機能を表し、プロセスのインタラクティブ機能を複数のプロセスに、データ・カプセルの内容として露出する。
【０２５１】
一実施形態の方法は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を関数コールによって定義する代わりに、データ・カプセルの内容によって複数のプロセスのＡＰＩを定義するステップを備えている。
【０２５２】
一実施形態のデータ・カプセルの内容は、アプリケーションに独立しており、複数のプロセスによって認識可能である。
一実施形態の少なくとも１つの処理デバイスは、複数の処理デバイスを備えている。
【０２５３】
一実施形態の複数のプロセスの内少なくとも１つの第１組のプロセスは、一実施形態の複数の処理デバイスの内少なくとも１つの第１組の処理デバイスの下で起動し、複数のプロセスの内少なくとも１つの第２組のプロセスは、複数の処理デバイスの内少なくとも１つの第２組の処理デバイスの下で起動する。
【０２５４】
一実施形態の複数のプロセスは、第１プロセスを含む。
一実施形態の変換するステップは、第１プロセスのイベントを、イベントを指定する第１プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０２５５】
一実施形態の第１プロセス・イベント・データおよび状態情報は、第１プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０２５６】
一実施形態の複数のプロセスは、第２プロセスを含む。
一実施形態の変換するステップは、第２プロセスの状態変化イベントを、イベントを指定する第２プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０２５７】
一実施形態の第２プロセス・イベント・データおよび状態情報は、第２プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０２５８】
一実施形態の認識プロセスは、第２プロセスであり、第２プロセスは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するステップを含む。
【０２５９】
一実施形態の認識したデータ・カプセルの内容は、第１プロセスの状態情報を表すデータである。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、少なくとも１つの新たなデータ・シーケンスは、第１プロセスのイベントおよび第２プロセスのイベントの内少なくとも１つを表す。
【０２６０】
一実施形態の少なくとも１つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、第１プロセスおよび第２プロセスの内少なくとも１つの状態情報とを備えている。
【０２６１】
一実施形態のイベント・データならびに第１プロセスおよび第２プロセスの内少なくとも１つの状態情報は、第１プロセスおよび第２プロセスの内少なくとも１つのアプリケーションに対応するタイプを有するタイプ特定データである。
【０２６２】
一実施形態の変換するステップは、少なくとも１つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０２６３】
一実施形態の複数のプロセスは、少なくとも１つの新たなデータ・シーケンスを用いる。
一実施形態の認識したデータ・カプセルの内容に適した処理は、グラフィカル・オブジェクトをレンダリングするステップを含み、少なくとも１つの処理デバイスのディスプレイ上にグラフィカル・オブジェクトをレンダリングする。
【０２６４】
一実施形態のレンダリングするステップは、直接レンダリングを行い、複数のプロセスが少なくとも１つの処理デバイスのグラフィクス・レイヤに直接描画を行い、複数のプロセス間においてレンダリングに適するような調整を行うために複数のプールを用いる。
【０２６５】
一実施形態のレンダリングするステップは、レンダリング・コマンドを備えているデータ・カプセルを複数のプールに転送する複数のプロセスを備えている。一実施形態のレンダリングするステップは、レンダリング・コマンドを複数のプールから引き出し、レンダリング・コマンドを解釈し、レンダリング・コマンドに応答して少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする複数のプロセスを備えている。
【０２６６】
一実施形態のレンダリングするステップは、画素バッファにレンダリングする複数のプロセスを備えている。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールに転送する複数のプロセスを備えており、生のフレーム・データは、画素バッファへのレンダリングの結果得られる。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールから引き出し、少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、生のフレーム・データを組み合わせる複数のプロセスを備えている。
【０２６７】
一実施形態の方法は、複数のプロセスのイベントを検出するステップを備えている。一実施形態の方法は、イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップを備えており、イベント・データおよび状態情報は、少なくとも１つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、このデータ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０２６８】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別イベント・データを含む第１個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第１データ・シーケンスを形成するステップを備えている。
【０２６９】
一実施形態の第１個別データ集合を発生するステップは、少なくとも１つの処理デバイスの識別データを含むように、第１個別データ集合を形成するステップを含み、識別データは、少なくとも１つの処理デバイスを識別するデータを含む。
【０２７０】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別イベント・データを含む第１個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第２データ・シーケンスを形成するステップを備えている。
【０２７１】
一実施形態の第１個別データ集合を発生するステップは、第１個別データ集合オフセットを発生するステップを含み、第１個別データ集合オフセットは、第２データ・シーケンスの第１個別データ集合を指し示す。
【０２７２】
一実施形態の第２個別データ集合を発生するステップは、第２個別データ集合オフセットを発生するステップを含み、第２個別データ集合オフセットは、第２データ・シーケンスの第２個別データ集合を指し示す。
【０２７３】
一実施形態の第１個別データ集合は、記述リストであり、この記述リストは、データの記述を含む。
一実施形態のイベント・データは、類別されたデータ(typed data)を表すタグ付き(tagged)バイト・シーケンスである。
【０２７４】
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
【０２７５】
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも１つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットを含むように、データ・カプセルを形成するステップを備えている。
【０２７６】
一実施形態の方法は、第１可変長を有する第１オフセットを発生するステップを備えており、第１オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのイベント・データを指し示す。
【０２７７】
一実施形態の方法は、第２可変長を有する第２オフセットを発生するステップを備えており、第２オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す。
【０２７８】
一実施形態の方法は、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通過する第１コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通過する第２コード経路を形成する、ステップを備えており、第１コード経路および第２コード経路は、異なる経路である。
【０２７９】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータを含み、このメタデータは、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
【０２８０】
一実施形態の方法は、データ・カプセルの長さを含むヘッダを発生するステップを備えている。一実施形態の方法は、ヘッダを含むようにデータ・カプセルを形成するステップを備えている。
【０２８１】
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、少なくとも１つの処理デバイスの第２イベントを検出するステップを備えている。一実施形態の方法は、複数のプールを検索して、第２イベントに対応するデータ・カプセルを求めるステップを備えている。
【０２８２】
一実施形態の方法は、データ・カプセルと第２イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、特定に応答して、プールからデータ・カプセルを抽出するステップを備えている。一実施形態の方法は、データ・カプセルの内容に応答して、少なくとも１つの処理デバイスの代わりに、第２イベントに対応する処理動作を実行するステップを備えており、少なくとも１つの処理デバイスが第１タイプのアプリケーションおよび第２タイプのアプリケーションに対応する。
【０２８３】
一実施形態の複数のプールは、複数のアプリケーションに結合されており、複数のプールは、複数のアプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、複数のアプリケーションによる複数のデータ・カプセルへのアクセスに備えており、複数のアプリケーションの内少なくとも２つのアプリケーションが異なるアプリケーションである。
【０２８４】
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュ(state caching)に備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンス(sequencing)に備えている。
【０２８５】
一実施形態のデータ構造は、類別されていない(untyped)。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
【０２８６】
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
一実施形態の転送するステップは、第１アプリケーション・タイプを有する第１アプリケーションから少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションにデータ・カプセルを転送するステップを含み、第１アプリケーション・タイプが第２アプリケーション・タイプとは異なり、少なくとも１つのデータ・シーケンスを発生するステップは、第１アプリケーションによって実行され、本方法は、転送するステップの間、データ・カプセルの少なくとも１つのデータ・シーケンスをそのまま保持するステップを備えている。
【０２８７】
一実施形態の方法は、第２アプリケーションの動作中少なくとも１つのデータ・シーケンスを用いるステップを備えている。
一実施形態の方法は、イベント・データと、少なくとも１つの処理デバイスのソース・デバイスの識別データとを含む第１データ集合を発生するステップを備えており、デバイス・イベント・データは、ソース・デバイスによって登録されたイベントを指定するデータを含み、識別データは、ソース・デバイスを識別するデータを含む。
【０２８８】
一実施形態の方法は、イベントの完全な１組の状態情報を含む第２データ集合を発生するステップを備えており、第１データ集合および第２データ集合の各々は、タイプ特定データ・レイアウトとした類別データ・バンドル(typed data bundle)を備えている。
【０２８９】
一実施形態の変換するステップは、第１データ集合および第２データ集合を含むようにデータ・カプセルを形成することによって、第１データ集合および第２データ集合をカプセル化するステップを備えており、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０２９０】
一実施形態の方法は、第１タイプのアプリケーションの下で起動する第１処理デバイスのイベントを検出するステップを備えている。一実施形態の方法は、第１処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップを備えており、イベント・データがイベントおよびこのイベントの状態情報を指定し、イベント・データおよび状態情報は、アプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、データ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、データ・カプセルは、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。一実施形態の方法は、少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で起動する第２処理デバイスの第２イベントを検出するステップを備えており、第２タイプが第１タイプとは異なり、少なくとも１つの処理デバイスは、第１処理デバイスおよび第２処理デバイスを含む。一実施形態の方法は、データ・カプセルと第２イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、第２イベントに応答して、データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップを備えている。
【０２９１】
一実施形態のデータ・シーケンスを発生するステップは、イベント・データを含む第１データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、状態情報を含む第２データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、第１データ集合および第２データ集合を含むように第１データ・シーケンスを形成するステップを備えている。
【０２９２】
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０２９３】
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０２９４】
一実施形態の方法は、少なくとも１つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットを含むようにデータ・カプセルを形成するステップを備えている。
【０２９５】
一実施形態の方法は、第１可変長を有する第１オフセットを発生するステップを備えており、第１オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのイベント・データを指し示す。一実施形態の方法は、第２可変長を有する第２オフセットを発生するステップを備えており、第２オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す。
【０２９６】
一実施形態の方法は、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通過する第１コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通過する第２コード経路を形成するステップを備えており、第１コード経路および第２コード経路が異なる経路である。
【０２９７】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータを含み、このメタデータは、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
【０２９８】
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、複数のプールを検索して、第２イベントに対応するデータ・カプセルを求めるステップを備えている。一実施形態の方法は、対応を特定したことに応答して、プールからデータ・カプセルを抽出するステップを備えている。
【０２９９】
一実施形態の複数のプールがアプリケーションおよび少なくとも１つの第２アプリケーションに結合されており、複数のプールは、アプリケーションおよび少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、アプリケーションおよび少なくとも１つの第２アプリケーションによる複数のデータ・カプセルへのアクセスを与える。
【０３００】
一実施形態のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
【０３０１】
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
【０３０２】
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
本明細書において記載した実施形態は、方法を含む。この方法は、処理デバイス上において複数のプロセスを実行するステップであって、これら複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、このデータ・メッセージが、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージを発したプロセスの状態情報とを含む、ステップと、データ・メッセージを、複数のプールの内少なくとも１つのプールに転送するステップと、プロセス間において調整を行うステップであって、この調整は、複数のプロセスの各プロセスは、複数のプールからピア・プロセスの状態情報を引き出すことによって、複数のプロセスのピア・プロセスと対等になることを含む、ステップと、複数のプールの内少なくとも１つのプールの１組のデータ・メッセージをインタラクティブに組み合わせることによって、複数のプロセスの出力を発生するステップとを備えている。
【０３０３】
本明細書において記載した実施形態は、システムを含む。このシステムは、少なくとも１つの処理デバイスであって、複数のプロセスを実行する、処理デバイスと、少なくとも１つの処理デバイスに結合されている複数のプールとを備えており、少なくとも１つの処理デバイスは、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを複数のプールに転送し、複数のプロセスの各プロセスは、認識プロセスとして動作し、この認識プロセスは、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、認識プロセスの識別との内少なくとも１つを備えているデータ・カプセルを認識し、認識プロセスは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する。
【０３０４】
本明細書において記載した実施形態は、方法を含む。この方法は、少なくとも１つの処理デバイス上において複数のプロセスを実行するステップであって、これら複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップであって、データ・カプセルが、イベントのイベント・データのアプリケーションに独立した表現と、データ・カプセルを発したプロセスの状態情報とを含む、ステップと、データ・カプセルを、複数のプールに転送するステップと、各プロセスが認識プロセスとして動作し、この認識プロセスは、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、認識プロセスの識別との少なくとも１つを備えているデータ・カプセルを認識するステップと、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するステップとを備えている。
【０３０５】
一実施形態の方法は、データ・カプセルおよび複数のプールを用いて、複数のプロセスの各々の動作を調整することによって、複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている。
【０３０６】
一実施形態の方法は、データ・カプセルおよび複数のプールの内少なくとも１つを用いて、複数のプロセスの動作を調整するステップを備えている。
一実施形態の方法は、アプリケーション・プログラムを１組のプロセスに分割するステップを備えており、複数のプロセスが１組のプロセスを含む。
【０３０７】
一実施形態の方法は、複数のプールの内少なくとも１つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている。
【０３０８】
一実施形態の方法は、複数のプロセスを並列に実行するステップを備えている。
一実施形態の方法は、第１組のプロセスを並列に実行し、第２組のプロセスを順次実行するステップを備えており、複数のプロセスが第１組のプロセスおよび第２組のプロセスを含む。
【０３０９】
一実施形態のイベントは、プロセス入力を表す。
一実施形態のイベントは、プロセス出力を表す。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。
【０３１０】
一実施形態のイベントは、グラフィクスイベントを備えている。
一実施形態のイベントは、プロセス状態を表す。
一実施形態のプロセスの状態は、当該プロセスのインタラクティブ機能を表し、プロセスのインタラクティブ機能を複数のプロセスに、データ・カプセルの内容として露出する。
【０３１１】
一実施形態の方法は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を関数コールによって定義する代わりに、データ・カプセルの内容によって複数のプロセスのＡＰＩを定義するステップを備えている。
【０３１２】
一実施形態のデータ・カプセルの内容は、アプリケーションに独立しており、複数のプロセスによって認識可能である。
一実施形態の少なくとも１つの処理デバイスは、複数の処理デバイスを備えている。
【０３１３】
一実施形態の複数のプロセスの内少なくとも１つの第１組のプロセスは、複数の処理デバイスの内少なくとも１つの第１組の処理デバイスの下で起動し、複数のプロセスの内少なくとも１つの第２組のプロセスは、複数の処理デバイスの内少なくとも１つの第２組の処理デバイスの下で起動する。
【０３１４】
一実施形態の複数のプロセスは、第１プロセスを含む。
一実施形態の方変換するステップは、第１プロセスのイベントを、イベントを指定する第１プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０３１５】
一実施形態の第１プロセス・イベント・データおよび状態情報は、第１プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３１６】
一実施形態の複数のプロセスは、第２プロセスを含む。
一実施形態の変換するステップは、第２プロセスの状態変化イベントを、イベントを指定する第２プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０３１７】
一実施形態の第２プロセス・イベント・データおよび状態情報は、第２プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３１８】
一実施形態の認識プロセスは、第２プロセスであり、引き出すステップは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する第２プロセスを備えている。
【０３１９】
一実施形態の認識したデータ・カプセルの内容は、第１プロセスの状態情報を表すデータである。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、少なくとも１つの新たなデータ・シーケンスは、第１プロセスのイベントおよび第２プロセスのイベントの内少なくとも１つを表す。
【０３２０】
一実施形態の少なくとも１つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、第１プロセスおよび第２プロセスの内少なくとも１つの状態情報とを備えている。
【０３２１】
一実施形態のイベント・データならびに第１プロセスおよび第２プロセスの内少なくとも１つの状態情報は、第１プロセスおよび第２プロセスの内少なくとも１つのアプリケーションに対応するタイプを有するタイプ特定データである。
【０３２２】
一実施形態の変換するステップは、少なくとも１つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３２３】
一実施形態の複数のプロセスが少なくとも１つの新たなデータ・シーケンスを用いる。
一実施形態の複数のプロセスが入力プロセスを含み、この入力プロセスが入力イベントを入力デバイスから受ける。
【０３２４】
一実施形態の変換するステップは、入力デバイスの入力イベントを、イベントを指定する入力デバイス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０３２５】
一実施形態の入力デバイス・イベント・データおよび状態情報は、ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３２６】
一実施形態の複数のプロセスは、ポインタ・プロセスを含む。
一実施形態の認識プロセスは、ポインタ・プロセスであり、引き出すステップは、ポインタ・プロセスが複数のプールから認識したデータ・カプセルを引き出し、認識したデータ・カプセルの内容に適したプロセスを実行するステップを含む。
【０３２７】
一実施形態の認識したデータ・カプセルの内容は、入力プロセスからの入力イベントを表すデータである。
一実施形態の認識データ・カプセルの内容は、少なくとも１つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである。
【０３２８】
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、少なくとも１つの新たなデータ・シーケンスは、ディスプレイに関するポインタ・オブジェクトの位置を定める。
【０３２９】
一実施形態の少なくとも１つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、ポインタ・プロセス・イベントの状態情報とを備えている。
一実施形態のポインタ・プロセス・イベント・データおよび状態情報は、ポインタ・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
【０３３０】
一実施形態の変換するステップは、少なくとも１つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３３１】
一実施形態の複数のプロセスは、ディスプレイ上にポインタ・オブジェクトをレンダリングする際に、少なくとも１つの新たなデータ・シーケンスを用いる。
一実施形態の複数のプロセスは、グラフィカル・プロセスを含む。
【０３３２】
一実施形態の変換するステップは、グラフィカル・プロセスの状態変化イベントを、イベントを指定するグラフィカル・プロセス・イベント・データと、イベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０３３３】
一実施形態のグラフィカル・プロセス・イベント・データおよび状態情報は、グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３３４】
一実施形態の認識するプロセスは、グラフィカル・プロセスであり、引き出すステップは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するグラフィカル・プロセスを含む。
【０３３５】
一実施形態の認識したデータ・カプセルの内容は、複数のプロセスの内他のプロセスの状態情報を表すデータである。
一実施形態の状態情報は、空間状態およびモード状態の内少なくとも１つの情報を含む。
【０３３６】
一実施形態の認識データ・カプセルの内容は、少なくとも１つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである。
一実施形態のポインタ・オブジェクトの位置は、グラフィカル・オブジェクトの境界内部にあり、グラフィカル・オブジェクトがグラフィカル・プロセスによってレンダリングされる。
【０３３７】
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、少なくとも１つの新たなデータ・シーケンスは、グラフィカル・オブジェクト、ポインタ・オブジェクト、およびポインタ・オブジェクトと境界との重複の内少なくとも１つを表す。
【０３３８】
一実施形態の少なくとも１つの新たなデータ・シーケンスは、イベントを指定するグラフィカル・プロセス・イベント・データと、グラフィカル・プロセス・イベントの状態情報とを備えている。
【０３３９】
一実施形態のグラフィカル・プロセス・イベント・データおよび状態情報は、グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、このデータ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３４０】
一実施形態の複数のプロセスは、グラフィカル・オブジェクトおよびポインタ・オブジェクトの内少なくとも１つをディスプレイ上にレンダリングする際に、少なくとも１つの新たなデータ・シーケンスを用いる。
【０３４１】
一実施形態の認識したデータ・カプセルの内容に適した処理は、グラフィカル・オブジェクトのレンダリングを含み、グラフィカル・オブジェクトが少なくとも１つの処理デバイスのディスプレイ上にレンダリングされる。
【０３４２】
一実施形態のレンダリングするステップは、直接レンダリングを行い、複数のプロセスが少なくとも１つの処理デバイスのグラフィクス・レイヤに直接描画を行い、複数のプロセス間においてレンダリングに適するような調整を行うために複数のプールを用いる。
【０３４３】
一実施形態のレンダリングするステップは、レンダリング・コマンドを備えているデータ・カプセルを複数のプールに転送する複数のプロセスを備えている。一実施形態のレンダリングするステップは、レンダリング・コマンドを複数のプールから引き出し、レンダリング・コマンドを解釈し、レンダリング・コマンドに応答して少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする複数のプロセスを備えている。
【０３４４】
一実施形態のレンダリングするステップは、画素バッファにレンダリングする複数のプロセスを備えている。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールに転送する複数のプロセスを備えており、生のフレーム・データが画素バッファへのレンダリングの結果得られる。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールから引き出し、少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、生のフレーム・データを組み合わせる複数のプロセスを備えている。
【０３４５】
一実施形態の方法は、複数のプロセスのイベントを検出するステップを備えている。一実施形態の方法は、イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップを備えており、イベント・データおよび状態情報は、少なくとも１つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３４６】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別イベント・データを含む第１個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第１データ・シーケンスを形成するステップを備えている。
【０３４７】
一実施形態の第１個別データ集合を発生するステップは、少なくとも１つの処理デバイスの識別データを含むように、第１個別データ集合を形成するステップを含み、識別データは、少なくとも１つの処理デバイスを識別するデータを含む。
【０３４８】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別イベント・データを含む第１個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第２データ・シーケンスを形成するステップを備えている。
【０３４９】
一実施形態の第１個別データ集合を発生するステップは、第１個別データ集合オフセットを発生するステップを含み、第１個別データ集合オフセットは、第２データ・シーケンスの第１個別データ集合を指し示す。
【０３５０】
一実施形態の第２個別データ集合を発生するステップは、第２個別データ集合オフセットを発生するステップを含み、第２個別データ集合オフセットは、第２データ・シーケンスの第２個別データ集合を指し示す。
【０３５１】
一実施形態の第１個別データ集合は、記述リストであり、この記述リストは、データの記述を含む。
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
【０３５２】
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
【０３５３】
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも１つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットを含むように、データ・カプセルを形成するステップを備えている。
【０３５４】
一実施形態の方法は、第１可変長を有する第１オフセットを発生するステップを備えており、記第１オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのイベント・データを指し示す。
【０３５５】
一実施形態の方法は、第２可変長を有する第２オフセットを発生するステップを備えており、第２オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す。
【０３５６】
一実施形態の方法は、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通過する第１コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通過する第２コード経路を形成するステップを備えており、第１コード経路および第２コード経路は、異なる経路である。
【０３５７】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータは、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
【０３５８】
一実施形態の方法は、データ・カプセルの長さを含むヘッダを発生するステップを備えている。一実施形態の方法は、ヘッダを含むようにデータ・カプセルを形成するステップを備えている。
【０３５９】
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、少なくとも１つの処理デバイスの第２イベントを検出するステップを備えている。一実施形態の方法は、複数のプールを検索して、第２イベントに対応するデータ・カプセルを求めるステップを備えている。
【０３６０】
一実施形態の方法は、データ・カプセルと第２イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、特定に応答して、プールからデータ・カプセルを抽出するステップを備えている。一実施形態の方法は、データ・カプセルの内容に応答して、少なくとも１つの処理デバイスの代わりに、第２イベントに対応する処理動作を実行するステップを備えており、少なくとも１つの処理デバイスが第１タイプのアプリケーションおよび第２タイプのアプリケーションに対応する。
【０３６１】
一実施形態の複数のプールが複数のアプリケーションに結合されており、複数のプールは、複数のアプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、複数のアプリケーションによる複数のデータ・カプセルへのアクセスに備えており、複数のアプリケーションの内少なくとも２つのアプリケーションが異なるアプリケーションである。
【０３６２】
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
【０３６３】
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
【０３６４】
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
転送するステップは、第１アプリケーション・タイプを有する第１アプリケーションから少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションにデータ・カプセルを転送するステップを含み、第１アプリケーション・タイプが第２アプリケーション・タイプとは異なり、少なくとも１つのデータ・シーケンスを発生するステップは、第１アプリケーションによって実行され、本方法は、転送するステップの間、データ・カプセルの少なくとも１つのデータ・シーケンスをそのまま保持するステップを備えている。
【０３６５】
一実施形態の方法は、第２アプリケーションの動作中少なくとも１つのデータ・シーケンスを用いるステップを備えている。
一実施形態の方法は、イベント・データと、少なくとも１つの処理デバイスのソース・デバイスの識別データとを含む第１データ集合を発生するステップを備えており、デバイス・イベント・データは、ソース・デバイスによって登録されたイベントを指定するデータを含み、識別データは、ソース・デバイスを識別するデータを含む。
【０３６６】
一実施形態の方法は、イベントの完全な１組の状態情報を含む第２データ集合を発生するステップを備えており、第１データ集合および第２データ集合の各々は、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている。
【０３６７】
一実施形態の変換するステップは、第１データ集合および第２データ集合を含むようにデータ・カプセルを形成することによって、第１データ集合および第２データ集合をカプセル化するステップを備えており、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０３６８】
一実施形態の方法は、第１タイプのアプリケーションの下で起動する第１処理デバイスのイベントを検出するステップと、第１処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、イベント・データがイベントおよびこのイベントの状態情報を指定し、イベント・データおよび状態情報は、アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、データ・カプセルは、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する、ステップと、少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で起動する第２処理デバイスの第２イベントを検出するステップであって、第２タイプが第１タイプとは異なり、少なくとも１つの処理デバイスは、第１処理デバイスおよび第２処理デバイスを含み、データ・カプセルと第２イベントとの間における対応を特定するステップと、第２イベントに応答して、データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップとを備えている。
【０３６９】
一実施形態のデータ・シーケンスを発生するステップは、イベント・データを含む第１データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、状態情報を含む第２データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、第１データ集合および第２データ集合を含むように第１データ・シーケンスを形成するステップとを備えている。
【０３７０】
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０３７１】
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０３７２】
一実施形態の方法は、少なくとも１つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットを含むようにデータ・カプセルを形成するステップを備えている。
【０３７３】
一実施形態の方法は、第１可変長を有する第１オフセットを発生するステップを備えており、第１オフセットが、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのイベント・データを指し示す。一実施形態の方法は、第２可変長を有する第２オフセットを発生するステップを備えており、第２オフセットが、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す。
【０３７４】
一実施形態の方法は、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通過する第１コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通過する第２コード経路を形成するステップを備えており、第１コード経路および第２コード経路が異なる経路である。
【０３７５】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
【０３７６】
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、複数のプールを検索して、第２イベントに対応するデータ・カプセルを求めるステップを備えている。一実施形態の方法は、対応を特定したことに応答して、プールからデータ・カプセルを抽出するステップを備えている。
【０３７７】
一実施形態の複数のプールは、アプリケーションおよび少なくとも１つの第２アプリケーションに結合されており、複数のプールが、アプリケーションおよび少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、複数のプールが、アプリケーションおよび少なくとも１つの第２アプリケーションによる複数のデータ・カプセルへのアクセスを与える。
【０３７８】
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
【０３７９】
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
【０３８０】
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
本明細書において記載した実施形態は、方法を含む。この方法は、アプリケーション・プログラムを複数のプロセスに分割するステップと、これら複数のプロセスの中にあるプロセスを用いて、アプリケーション・プログラムの出力の一部を発生するステップと、出力の一部を第１データ・カプセルにカプセル化し、第１データ・カプセルを複数のプールの内少なくとも１つに転送するステップであって、複数のプールが、複数のプロセスから受け取られる複数のデータ・カプセルを備えている、ステップと、複数のプールにアクセスし、複数のプロセスの内第２プロセスの入力を引き出すステップであって、入力が複数のデータ・カプセルの内第２データ・カプセルの中にある、ステップと、複数のデータ・カプセルおよび複数のプールを用いて、複数のプロセス間における処理を調整するステップとを備えている。
【０３８１】
本明細書において記載した実施形態は、システムを含む。このシステムは、少なくとも１つの処理デバイスであって、この処理デバイスが複数のプロセスを実行し、複数のプロセスが複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備えている、処理デバイスと、少なくとも１つの処理デバイスに結合されている複数のプールと、
を備えており、少なくとも１つの処理デバイスが、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを複数のプールに転送し、データ・カプセルが、イベントのイベント・データのアプリケーション独立表現と、データ・カプセルが発したプロセスの状態情報とを含み、各プロセスが認識プロセスとして動作し、この認識プロセスが、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、認識プロセスの識別との内少なくとも１つを備えているデータ・カプセルを認識し、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する。
【０３８２】
本明細書において記載した実施形態は、方法を含む。この方法は、ジェスチャ・データから人が行ったジェスチャを検出するステップであって、ジェスチャ・データが検出器を通じて受け取られる、ステップと、処理デバイス上において複数のプロセスを実行するステップであって、複数のプロセスがイベントを発生し、このイベントが、ジェスチャを表す１組のイベントを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップと、データ・カプセルを複数のプールに転送するステップとを備えており、複数のプロセスの内１組のプロセスが認識プロセスとして動作し、この認識プロセスが、複数のプールにおいて、ジェスチャに対応するコンテンツを備えているデータ・カプセルを認識し、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生し、ジェスチャ信号がジェスチャを表す。
【０３８３】
一実施形態の複数のプロセスは、空間動作アプリケーションの分離可能なプログラム実行コンテキストを含む。
一実施形態のジェスチャ・データは、ある時点および空間におけるユーザの瞬時的状態の絶対三空間位置データである。
【０３８４】
一実施形態の方法は、ジェスチャ・データのみを用いてジェスチャを識別するステップを備えている。
一実施形態の検出するステップは、ボディの位置を検出すること、ボディの方位を検出すること、およびボディの運動を検出することの内少なくとも１つを含む。
【０３８５】
一実施形態の方法は、ジェスチャを識別するステップを備えており、識別は、ボディの一部のポーズおよび方位の識別を含む。
一実施形態の検出するステップは、ボディの第１組の付属器官および第２組の付属器官の内少なくとも１つを検出するステップを含む。
【０３８６】
一実施形態の検出するステップは、ボディに結合されている少なくとも１つのタグの位置を動的に検出するステップを含む。
一実施形態の検出するステップは、ボディに結合されている１組のタグの位置を検出するステップを含む。
【０３８７】
一実施形態の１組のタグにおける各タグがパターンを含み、１組のタグにおける各タグの各パターンが、複数のタグにおけるいずれの残りのタグのいずれのパターンとも異なる。
【０３８８】
一実施形態の検出するステップは、ボディ上にあるマーカを動的に検出し位置を突き止めるステップを含む。
一実施形態の検出するステップは、ボディに結合されている１組のマーカの位置を検出するステップを含む。
【０３８９】
一実施形態の１組のマーカがボディ上において複数のパターンを形成する。
一実施形態の検出するステップは、ボディの複数の付属器官の各々に結合されている１組のマーカを用いて、付属器官の位置を検出するステップを含む。
【０３９０】
一実施形態の変換するステップは、ジェスチャの情報をジェスチャ表記に変換するステップを含む。
一実施形態のジェスチャ表記は、ジェスチャ・ボキャブラリを表し、ジェスチャ信号がジェスチャ・ボキャブラリの通信を含む。
【０３９１】
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携の瞬時的ポーズ状態をテキスト形態で表す。
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携の方位をテキスト形態で表す。
【０３９２】
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携の方位の組み合わせを、テキスト形態で表す。
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携状態を表す、キャラクタのストリングを含む。
【０３９３】
一実施形態の力学的連携がボディの少なくとも１つの第１付属器官である。
一実施形態の方法は、ストリングにおける各位置を第２付属器官に割り当てるステップを備えており、第２付属器官が第１付属器官に接続されている。
【０３９４】
一実施形態の方法は、複数のキャラクタの中にあるキャラクタを、第２付属器官の複数の位置の各々に割り当てるステップを備えている。
一実施形態の複数の位置は、座標原点に対して確定される。
【０３９５】
一実施形態の方法は、空間における絶対位置および方位、ボディの全体的な位置および方位とは無関係のボディに対する固定位置および方位から成るグループから選択された位置を用いて、更にボディのアクションにインタラクティブに応答して、座標原点を確立するステップを備えている。
【０３９６】
一実施形態の方法は、複数のキャラクタの中にあるキャラクタを、第１付属器官の複数の方位の各々に割り当てるステップを備えている。
一実施形態の検出するステップは、ボディの外挿補間位置が仮想空間と交差するときを検出するステップを含み、仮想空間が、少なくとも１つの処理デバイスに結合されているディスプレイ・デバイス上に描画された空間を含む。
【０３９７】
一実施形態の方法は、外挿補間位置が仮想空間と交差するときに、仮想空間において仮想オブジェクトを制御するステップを備えている。
一実施形態の制御するステップは、仮想空間における外挿位置に応答して、仮想空間における仮想オブジェクトの位置を制御するステップを備えている。
【０３９８】
一実施形態の制御するステップが、ジェスチャに応答して、仮想空間における仮想オブジェクトの姿勢を制御するステップを含む。
一実施形態の方法は、仮想空間と物理空間との間において一致を生じさせるために、検出および制御のスケーリングを制御するステップを備えており、仮想空間がディスプレイ上に描画された空間を構成し、物理空間が、ボディが存在する空間を含む。
【０３９９】
一実施形態の方法は、物理空間における少なくとも１つの物理オブジェクトの移動に応答して、仮想空間において少なくとも１つの仮想オブジェクトを制御するステップを備えている。
【０４００】
一実施形態の方法は、ジェスチャ信号を用いてコンポーネントを制御するステップを備えており、コンポーネントが少なくとも１つの処理デバイスに結合されている。
一実施形態のコンポーネントを制御するステップは、ジェスチャを三空間オブジェクトにマッピングすることによって、６自由度で同時に三空間オブジェクトを制御するステップを含む。
【０４０１】
一実施形態のコンポーネントを制御するステップは、３空間移動自由度および３回転自由度で三空間オブジェクトを制御するステップを含む。
一実施形態の三空間オブジェクトを、少なくとも１つの処理デバイスに結合されているディスプレイ・デバイス上に呈示する。
【０４０２】
一実施形態の三空間オブジェクトは、コンピュータに結合されている遠隔システムである。
一実施形態の方法は、ジェスチャを三空間オブジェクトの複数のオブジェクト平行移動にマッピングすることによって、三空間オブジェクトの移動を制御するステップを備えている。
【０４０３】
一実施形態のマッピングは、ジェスチャと複数のオブジェクト平行移動との間における直接マッピングを含む。
一実施形態のマッピングは、ジェスチャと複数のオブジェクト平行移動との間における間接マッピングを含む。
【０４０４】
一実施形態のデータ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージが発生したプロセスの状態情報とを含む。
一実施形態の方法は、データ・カプセルおよび複数のプールを用いて、複数のプロセスの各々の動作を調整することによって、複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている。
【０４０５】
一実施形態の方法は、データ・カプセルおよび複数のプールの内少なくとも１つを用いて、複数のプロセスの動作を調整するステップを備えている。
一実施形態の方法は、アプリケーション・プログラムを１組のプロセスに分割するステップを備えており、複数のプロセスが１組のプロセスを含む。
【０４０６】
一実施形態の方法は、複数のプールの内少なくとも１つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている。
【０４０７】
一実施形態の複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを備えている。
【０４０８】
一実施形態の方法は、複数のプロセスを並列に実行するステップを備えている。
一実施形態の方法は、第１組のプロセスを並列に実行し、第２組のプロセスを順次実行するステップを備えており、複数のプロセスが第１組のプロセスおよび第２組のプロセスを含む。
【０４０９】
一実施形態のイベントは、プロセス入力を表す。
一実施形態のイベントは、プロセス出力を表す。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。
【０４１０】
一実施形態のイベントは、グラフィクスイベントを備えている。
一実施形態のイベントは、プロセス状態を表す。
一実施形態のプロセスの状態は、当該プロセスのインタラクティブ機能を表し、プロセスのインタラクティブ機能を複数のプロセスに、データ・カプセルの内容として露出する。
【０４１１】
一実施形態の方法は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を関数コールによって定義する代わりに、データ・カプセルの内容によって複数のプロセスのＡＰＩを定義するステップを備えている。
【０４１２】
一実施形態のデータ・カプセルの内容は、アプリケーションに独立しており、複数のプロセスによって認識可能である。
一実施形態の少なくとも１つの処理デバイスは、複数の処理デバイスを備えている。
【０４１３】
一実施形態の複数のプロセスの内少なくとも１つの第１組のプロセスは、複数の処理デバイスの内少なくとも１つの第１組の処理デバイスの下で起動し、複数のプロセスの内少なくとも１つの第２組のプロセスが、複数の処理デバイスの内少なくとも１つの第２組の処理デバイスの下で起動する。
【０４１４】
一実施形態の複数のプロセスは、第１プロセスを含む。
一実施形態の変換するステップは、第１プロセスのイベントを、イベントを指定する第１プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０４１５】
一実施形態の第１プロセス・イベント・データおよび状態情報は、第１プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０４１６】
一実施形態の複数のプロセスは、第２プロセスを含む。
一実施形態の変換するステップは、第２プロセスの状態変化イベントを、イベントを指定する第２プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスに変換するステップを含む。
【０４１７】
一実施形態の第２プロセス・イベント・データおよび状態情報は、第２プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０４１８】
一実施形態の認識プロセスは、第２プロセスであり、引き出すステップは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する第２プロセスを備えている。
【０４１９】
一実施形態の認識したデータ・カプセルの内容は、第１プロセスの状態情報を表すデータである。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも１つの新たなデータ・シーケンスに変換するステップを含み、少なくとも１つの新たなデータ・シーケンスが、第１プロセスのイベントおよび第２プロセスのイベントの内少なくとも１つを表す。
【０４２０】
一実施形態の少なくとも１つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、第１プロセスおよび第２プロセスの内少なくとも１つの状態情報とを備えている。
【０４２１】
一実施形態のイベント・データならびに第１プロセスおよび第２プロセスの内少なくとも１つの状態情報は、第１プロセスおよび第２プロセスの内少なくとも１つのアプリケーションに対応するタイプを有するタイプ特定データである。
【０４２２】
一実施形態の変換するステップは、少なくとも１つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルが、少なくとも１つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０４２３】
一実施形態の複数のプロセスは、少なくとも１つの新たなデータ・シーケンスを用いる。
一実施形態の認識したデータ・カプセルの内容に適した処理は、グラフィカル・オブジェクトをレンダリングするステップを含み、少なくとも１つの処理デバイスのディスプレイ上にグラフィカル・オブジェクトをレンダリングする。
【０４２４】
一実施形態のレンダリングするステップは、直接レンダリングを行い、複数のプロセスが少なくとも１つの処理デバイスのグラフィクス・レイヤに直接描画を行い、複数のプロセス間においてレンダリングに適するような調整を行うために複数のプールを用いる。
【０４２５】
一実施形態のレンダリングするステップは、レンダリング・コマンドを備えているデータ・カプセルを複数のプールに転送する複数のプロセスを備えている。一実施形態のレンダリングするステップは、レンダリング・コマンドを複数のプールから引き出し、レンダリング・コマンドを解釈し、レンダリング・コマンドに応答して少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする複数のプロセスを備えている。
【０４２６】
一実施形態のレンダリングするステップは、画素バッファにレンダリングする複数のプロセスを備えている。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールに転送する複数のプロセスを備えており、生のフレーム・データは、画素バッファへのレンダリングの結果得られる。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールから引き出し、少なくとも１つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、生のフレーム・データを組み合わせるプロセス複数のプロセスを備えている。
【０４２７】
一実施形態の方法は、複数のプロセスのイベントを検出するステップを備えている。一実施形態の方法は、イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップを備えており、イベント・データおよび状態情報は、少なくとも１つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０４２８】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別イベント・データを含む第１個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第１データ・シーケンスを形成するステップを備えている。
【０４２９】
一実施形態の第１個別データ集合を発生するステップは、少なくとも１つの処理デバイスの識別データを含むように、第１個別データ集合を形成するステップを含み、識別データは、少なくとも１つの処理デバイスを識別するデータを含む。
【０４３０】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別イベント・データを含む第１個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第２個別状態情報を含む第２個別データ集合を発生するステップを備えている。一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別データ集合および第２個別データ集合を含むように、第２データ・シーケンスを形成するステップとを備えている。
【０４３１】
一実施形態の第１個別データ集合を発生するステップは、第１個別データ集合オフセットを発生するステップを含み、第１個別データ集合オフセットが、第２データ・シーケンスの第１個別データ集合を指し示す。
【０４３２】
一実施形態の第２個別データ集合を発生するステップは、第２個別データ集合オフセットを発生するステップを含み、第２個別データ集合オフセットが、第２データ・シーケンスの第２個別データ集合を指し示す。
【０４３３】
一実施形態の第１個別データ集合は記述リストであり、この記述リストが、データの記述を含む。
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
【０４３４】
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
【０４３５】
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも１つのオフセットを発生するステップを備えている。一実施形態の方法は、なくとも１つのオフセットを含むように、データ・カプセルを形成するステップを備えている。
【０４３６】
一実施形態の方法は、第１可変長を有する第１オフセットを発生するステップを備えており、第１オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのイベント・データを指し示す。
【０４３７】
一実施形態の方法は、第２可変長を有する第２オフセットを発生するステップを備えており、第２オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す。
【０４３８】
一実施形態の方法は、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通過する第１コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通過する第２コード経路を形成するステップを備えており、第１コード経路および第２コード経路は、異なる経路である。
【０４３９】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータを含み、このメタデータが、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
【０４４０】
一実施形態の方法は、データ・カプセルの長さを含むヘッダを発生するステップを備えている。  一実施形態の方法は、ヘッダを含むようにデータ・カプセルを形成するステップを備えている。
【０４４１】
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、少なくとも１つの処理デバイスの第２イベントを検出するステップを備えている。一実施形態の方法は、複数のプールを検索して、第２イベントに対応するデータ・カプセルを求めるステップを備えている。
【０４４２】
一実施形態の方法は、データ・カプセルと第２イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、特定に応答して、プールからデータ・カプセルを抽出するステップを備えている。一実施形態の方法は、データ・カプセルの内容に応答して、少なくとも１つの処理デバイスの代わりに、第２イベントに対応する処理動作を実行するステップを備えており、少なくとも１つの処理デバイスは、第１タイプのアプリケーションおよび第２タイプのアプリケーションに対応する。
【０４４３】
一実施形態の複数のプールは、複数のアプリケーションに結合されており、これら複数のプールは、複数のアプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、複数のアプリケーションによる複数のデータ・カプセルへのアクセスに備えており、複数のアプリケーションの内少なくとも２つのアプリケーションは、異なるアプリケーションである。
【０４４４】
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
【０４４５】
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
【０４４６】
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
一実施形態の転送するステップは、第１アプリケーション・タイプを有する第１アプリケーションから少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションにデータ・カプセルを転送するステップを含み、第１アプリケーション・タイプが第２アプリケーション・タイプとは異なり、少なくとも１つのデータ・シーケンスを発生するステップが、第１アプリケーションによって実行され、本方法は、転送するステップの間、データ・カプセルの少なくとも１つのデータ・シーケンスをそのまま保持するステップを備えている。
【０４４７】
一実施形態の方法は、第２アプリケーションの動作中少なくとも１つのデータ・シーケンスを用いるステップを備えている。
一実施形態の方法は、イベント・データと、少なくとも１つの処理デバイスのソース・デバイスの識別データとを含む第１データ集合を発生するステップを備えており、デバイス・イベント・データが、ソース・デバイスによって登録されたイベントを指定するデータを含み、識別データが、ソース・デバイスを識別するデータを含む。
【０４４８】
一実施形態の方法は、イベントの完全な１組の状態情報を含む第２データ集合を発生するステップを備えており、第１データ集合および第２データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている。
【０４４９】
一実施形態の変換するステップは、第１データ集合および第２データ集合を含むようにデータ・カプセルを形成することによって、第１データ集合および第２データ集合をカプセル化するステップを備えており、データ・カプセルは、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
【０４５０】
一実施形態の方法は、第１タイプのアプリケーションの下で起動する第１処理デバイスのイベントを検出するステップを備えている。一実施形態の方法は、第１処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップを備えており、イベント・データがイベントおよびこのイベントの状態情報を指定し、イベント・データおよび状態情報が、アプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、データ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、このデータ・カプセルが、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。一実施形態の方法は、少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で起動する第２処理デバイスの第２イベントを検出するステップを備えており、第２タイプが第１タイプとは異なり、少なくとも１つの処理デバイスが、第１処理デバイスおよび第２処理デバイスを含む。一実施形態の方法は、データ・カプセルと第２イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、第２イベントに応答して、データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップを備えている。
【０４５１】
一実施形態のデータ・シーケンスを発生するステップは、イベント・データを含む第１データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、状態情報を含む第２データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、第１データ集合および第２データ集合を含むように第１データ・シーケンスを形成するステップを備えている。
【０４５２】
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０４５３】
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０４５４】
一実施形態の方法は、少なくとも１つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットを含むようにデータ・カプセルを形成するステップを備えている。
【０４５５】
一実施形態の方法は、第１可変長を有する第１オフセットを発生するステップを備えており、第１オフセットが、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのイベント・データを指し示す。一実施形態の方法は、第２可変長を有する第２オフセットを発生するステップを備えており、この第２オフセットが、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す。
【０４５６】
一実施形態の方法は、少なくとも１つのオフセットの内第１オフセットを用いて、データ・カプセルを通過する第１コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも１つのオフセットの内第２オフセットを用いて、データ・カプセルを通過する第２コード経路を形成するステップを備えており、第１コード経路および第２コード経路が異なる経路である。
【０４５７】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つがメタデータを含み、このメタデータが、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
【０４５８】
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、複数のプールを検索して、第２イベントに対応するデータ・カプセルを求めるステップを備えている。一実施形態の方法は、対応を特定したことに応答して、プールからデータ・カプセルを抽出するステップを備えている。
【０４５９】
一実施形態の複数のプールは、アプリケーションおよび少なくとも１つの第２アプリケーションに結合されており、複数のプールは、アプリケーションおよび少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、アプリケーションおよび少なくとも１つの第２アプリケーションによる複数のデータ・カプセルへのアクセスを与える。
【０４６０】
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
【０４６１】
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
【０４６２】
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
本明細書において記載した実施形態は、方法を含む。この方法は、処理デバイス上において複数のプロセスを実行するステップであって、複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも１つのプロセスを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、データ・メッセージが、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージを発したプロセスの状態情報とを含む、ステップと、データ・メッセージを、複数のプールの内少なくとも１つのプールに転送するステップと、プロセス間において調整を行うステップであって、この調整が、複数のプールからピア・プロセスの状態情報を引き出すことによって、複数のプロセスの各プロセスが、複数のプロセスのピア・プロセスと対等になることを含む、ステップと、複数のプールの内少なくとも１つのプールの１組のデータ・メッセージをインタラクティブに組み合わせることによって、複数のプロセスの出力を発生するステップとを備えている。
【０４６３】
本明細書において記載した実施形態は、システムを含む。このシステムは、ボディによって行われたジェスチャを表すジェスチャ・データを受け取る検出器と、検出器に結合されているプロセッサであって、このプロセッサがジェスチャ・データから自動的にジェスチャを検出し、プロセッサが複数のプロセスを実行し、これら複数のプロセスが、ジェスチャを表す１組のイベントを含むイベントを発生し、プロセッサが、複数のプロセスにおける各プロセスのイベントをデータ・カプセルに変換し、プロセッサがデータ・カプセルを複数のプールに転送し、複数のプロセスの内１組のプロセスが、認識プロセスとして機能し、この認識プロセスが、複数のプールにおいて、ジェスチャに対応する内容を備えているデータ・カプセルを認識し、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生し、ジェスチャ信号がジェスチャを表す、プロセッサとを備えている。
【０４６４】
本明細書において記載したシステムおよび方法は、処理システムを含む、および／または処理システムの下で実行する、および／または処理システムと連動して実行する。処理システムは、当技術分野では周知のように、互いに動作するプロセッサ主体デバイスまたは計算デバイスのあらゆる集合体、あるいは処理システムまたはデバイスのコンポーネントを含む。例えば、処理システムは、携帯用コンピュータ、通信ネットワークにおいて動作する携帯用通信デバイス、および／またはネットワーク・サーバの１つ以上を含むことができる。携帯用コンピュータは、パーソナル・コンピュータ、セルラ電話機、パーソナル・ディジタル・アシスタント、携帯用計算デバイス、および携帯用通信デバイスの中から選択した多数のデバイスおよび／またはデバイスの組み合わせのいずれとすることもできるが、そのように限定されるのではない。処理システムは、それよりも大きなコンピュータ・システムの中にあるコンポーネントを含むことができる。
【０４６５】
一実施形態の処理システムは、少なくとも１つのプロセッサと、少なくとも１つのメモリ・デバイスまたはサブシステムとを含む。また、処理システムは、少なくとも１つのデータベースを含むか、またはこれに結合することができる。「プロセッサ」という用語は、本明細書において一般に用いる場合、１つ以上の中央演算装置（ＣＰＵ）、ディジタル信号プロセッサ（ＤＳＰ）、特定用途集積回路（ＡＳＩＣ）等のような、あらゆる論理演算装置を指す。プロセッサおよびメモリは、１つのチップ上にモノリシックに集積することができ、多数のチップまたはホスト・システムのコンポーネント間で分散することができ、および／またはアルゴリズムの何らかの組み合わせによって提供することができる。本明細書において記載した方法は、ソフトウェア・アルゴリズム（１つまたは複数）、プログラム、ファームウェア、ハードウェア、コンポーネント、回路の１つ以上で、いずれの組み合わせでも実現することができる。
【０４６６】
本明細書において記載したシステムおよび方法を具体化するシステム・コンポーネントは、一緒に配置すること、または別個の位置に配置することができる。したがって、本明細書において記載したシステムおよび方法を具現化するシステム・コンポーネントは、単一のシステム、多数のシステム、および／または地理的に離れたシステムのコンポーネントとすることができる。また、これらのコンポーネントは、単一のシステム、多数のシステム、および／または地理的に離れたシステムのサブコンポーネントまたはサブシステムとすることもできる。これらのコンポーネントは、ホスト・システムの１つ以上のその他のコンポーネント、またはホスト・システムに結合されているシステムに結合することができる。
【０４６７】
通信経路は、システム・コンポーネントを結合し、コンポーネント間においてファイルを伝達または転送する媒体であればいずれでも含む。通信経路は、ワイヤレス接続、有線接続、混成ワイヤレス／有線接続を含む。また、通信経路は、ローカル・エリア・ネットワーク（ＬＡＮ）、都市エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、企業固有ネットワーク、事務所間またはバックエンド・ネットワーク、およびインターネットを含むネットワークへの結合または接続も含む。更に、通信経路は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクのような、リムーバブル固定媒体、ならびにフラッシュＲＡＭ、ユニバーサル・シリアル・バス（ＵＳＢ）接続、ＲＳ−２３２接続、電話回線、バス、および電子メール・メッセージを含む。
【０４６８】
文脈が特に明確に要求しない限り、説明全体を通じて、「備える」(comprise)、「備えている」(comprising)等の単語は、排他的または網羅的な意味とは逆に、包含的意味で解釈することとする。即ち、「含むがそれに限定されない」という意味である。また、単数または複数を用いる単語は、それぞれ、複数または単数も含むこととする。加えて、「ここでは」(herein)、「以下では」(hereunder)、「以上」(above)、「以下」(below)および同様の趣旨の単語は、本願のいずれかの特定部分ではなく、本願全体を指すこととする。「または」という単語が２つ以上の項目のリストに関して用いられる場合、その単語は以下の単語の解釈全てに及ぶこととする。リストにおける項目のいずれか、リストにおける項目全て、およびリストにおける項目のあらゆる組み合わせ。
【０４６９】
以上における実施形態の説明は、網羅的であることも、記載したシステムおよび方法を、開示した形態そのものに限定することも意図していない。具体的な実施形態およびその例は、本明細書では例示の目的で記載したが、その他のシステムおよび方法の範囲内において、種々の同等な修正も可能であることは、当業者であれば認められよう。本明細書において提案した教示は、前述のシステムおよび方法だけでなく、他の処理システムおよび方法にも適用することができる。
【０４７０】
以上で説明した種々の実施形態の要素および動作(act)を組み合わせて、更に別の実施形態を提案することができる。これらおよびその他の変更は、以上に詳細に記載した説明を参照すれば、実施形態に対して行うことができる。
【０４７１】
一般に、以下の特許請求の範囲では、前述の実施形態を本明細書および特許請求の範囲に開示される実施形態に限定するように、用いられる用語を解釈してはならず、特許請求の範囲の下で動作する全てのシステムを含むように解釈してしかるべきである。したがって、前述の実施形態は、本明細書における開示に限定されるのではなく、代わりに、実施形態の範囲は、特許請求の範囲によって全体的に判断されるものとする。
【０４７２】
以上の実施形態のある種の態様が、以下にある種の請求項の形態で提示されるが、本発明者は、これら実施形態の種々の態様を、いかなる数の請求項の形態でも想定している。したがって、本発明者は、本願を出願した後に本実施形態の他の態様に対してこのような追加の請求項の形態を追求するために、追加の請求項を加える権利を保持することとする。
0005805537.tif 000012
0005805537.tif 000013
【図１Ａ】
0005805537.tif 000014
【図１Ｂ】
0005805537.tif 000015
【図１Ｃ】
0005805537.tif 000016
【図２】
0005805537.tif 000017
【図３】
0005805537.tif 000018
【図４】
0005805537.tif 000019
【図５】
0005805537.tif 000020
【図６】
0005805537.tif 000021
【図７】
0005805537.tif 000022
【図８Ａ】
0005805537.tif 000023
【図８Ｂ】
0005805537.tif 000024
【図８Ｃ】
0005805537.tif 000025
【図８Ｄ】
0005805537.tif 000026
【図９】
0005805537.tif 000027
【図１０】
0005805537.tif 000028
【図１１】
0005805537.tif 000029
【図１２】
0005805537.tif 000030
【図１３】
0005805537.tif 000031
【図１４】
0005805537.tif 000032
【図１５】
0005805537.tif 000033
【図１６】
0005805537.tif 000034
【図１７】
0005805537.tif 000035
【図１８】
0005805537.tif 000036
【図１９】
0005805537.tif 000037
【図２０】
0005805537.tif 000038
【図２１】
0005805537.tif 000039
【図２２】
0005805537.tif 000040
【図２３−１】
0005805537.tif 000041
【図２３−２】
0005805537.tif 000042
【図２４】
0005805537.tif 000043
【図２５】
0005805537.tif 000044