(57)【特許請求の範囲】
【請求項１】
ソース・デバイスによって生成又は出力されるデータ、又は前記ソース・デバイスに対応するプログラムを使用して、前記ソース・デバイスのイベントを検出するステップと、
前記イベントを指定するデバイス・イベント・データであるディスクリプトと、当該イベントの状態情報であるインジェストとを備えている少なくとも１つのデータ・シーケンスを含むプロテインを発生するステップであって、前記デバイス・イベント・データおよび状態情報は、前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている、ステップと、
前記少なくとも１つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって、該データ・カプセルが、前記少なくとも１つのデータ・シーケンスを含む前記プロテインを、類別されていない（untyped）データ構造を用いて表現する、ステップと、
前記データ・カプセルを、第１アプリケーション・タイプを有する第１アプリケーションから、少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションにプールを介して転送するステップであって、前記第１アプリケーション・タイプは前記第２アプリケーション・タイプとは異なり、前記少なくとも１つのデータ・シーケンスを発生するステップを、前記第１アプリケーションによって実行する、ステップと、
前記転送の間、前記データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するステップと、
を備えている、方法。
【請求項２】
請求項１記載の方法において、前記少なくとも１つのデータ・シーケンスを発生するステップは、
第１個別デバイス・イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項３】
請求項２記載の方法において、前記第１個別データ集合を発生するステップは、前記ソース・デバイスの識別データを含むように前記第１個別データ集合を形成するステップを含み、前記識別データは、前記ソース・デバイスを識別するデータを含む、方法。
【請求項４】
請求項２記載の方法において、前記少なくとも１つのデータ・シーケンスを発生するステップは、
第１個別デバイス・イベント・データを含む第１個別データ集合を発生するステップと、
第２個別状態情報を含む第２個別データ集合を発生するステップと、
前記第１個別データ集合および前記第２個別データ集合を含むように、第２データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項５】
請求項４記載の方法において、前記第１個別データ集合を発生するステップは、第１個別データ集合オフセットを発生するステップを含み、前記第１個別データ集合オフセットは、前記第２データ・シーケンスの第１個別データ集合を指し示す、方法。
【請求項６】
請求項４記載の方法において、前記第２個別データ集合を発生するステップは、第２個別データ集合オフセットを発生するステップを含み、前記第２個別データ集合オフセットは、前記第２データ・シーケンスの第２個別データ集合を指し示す、方法。
【請求項７】
請求項２記載の方法において、前記第１個別データ集合は、記述リストであり、該記述リストは前記データの記述を含む、方法。
【請求項８】
請求項１記載の方法において、前記デバイス・イベント・データは、類別したデータを表す、タグ付きのバイト・シーケンスである、方法。
【請求項９】
請求項８記載の方法において、前記デバイス・イベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項１０】
請求項１記載の方法において、前記状態情報は、類別したデータを表す、タグ付きのバイト・シーケンスである、方法。
【請求項１１】
請求項１０記載の方法において、前記状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項１２】
請求項１記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように、前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項１３】
請求項１２記載の方法であって、
第１変数長を有する第１オフセットを発生するステップを備えており、
前記第１オフセットは、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記デバイス・イベント・データを指し示す、方法。
【請求項１４】
請求項１２記載の方法であって、
第２可変長を有する第２オフセットを発生するステップを備えており、
前記第２オフセットは、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報を指し示す、方法。
【請求項１５】
請求項１２記載の方法であって、
前記少なくとも１つのオフセットの第１オフセットを用いて、前記データ・カプセルを通る第１コード・パスを形成するステップと、
前記少なくとも１つのオフセットの第２オフセットを用いて、前記データ・カプセルを通る第２コード・パスを形成するステップと、
を備えており、前記第１コード・パスおよび前記第２コード・パスは異なるパスである、方法。
【請求項１６】
請求項１２記載の方法において、前記第１オフセットおよび前記第２オフセットの内少なくとも１つは、メタデータを含み、該メタデータは、前記アプリケーションのコンテキストに対応する、コンテキスト特定メタデータを備えている、方法。
【請求項１７】
請求項１記載の方法であって、
前記データ・カプセルの長さを含むヘッダを発生するステップと、
前記ヘッダを含むように前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項１８】
請求項１記載の方法であって、前記データ・カプセルをレポジトリに転送するステップを備えている、方法。
【請求項１９】
請求項１８記載の方法であって、
第２ソース・デバイスの第２イベントを検出するステップと、
前記第２イベントに対応するデータ・カプセルを求めて、前記レポジトリを検索するステップと、
を備えている、方法。
【請求項２０】
請求項１９記載の方法であって、
前記データ・カプセルと前記第２イベントとの間にある対応を特定するステップと、
前記特定に応答して、前記レポジトリから前記データ・カプセルを抽出するステップと、
前記データ・カプセルの内容に応答して、前記第２ソース・デバイスの代わりに前記第２イベントに対応する処理動作を、前記第２ソース・デバイスの代わりに実行するステップであって、前記ソース・デバイスは第１タイプのアプリケーションに対応し、前記第２ソース・デバイスは第２タイプの第２アプリケーションに対応する、ステップと、
を備えている、方法。
【請求項２１】
請求項１８記載の方法において、前記レポジトリは、複数のアプリケーションに結合されており、前記レポジトリは、前記複数のアプリケーションに対応する複数のデータ・カプセルを含み、前記レポジトリは、前記複数のアプリケーションによる前記複数のデータ・カプセルへのアクセスを与え、前記複数のアプリケーションは、少なくとも前記第１アプリケーション及び前記第２アプリケーションを含み、前記複数のアプリケーションの内少なくとも２つが異なるアプリケーションである、方法。
【請求項２２】
請求項１８記載の方法において、前記レポジトリは、複数のデータ・カプセルの状態をキャッシュする処理に備える、方法。
【請求項２３】
請求項１８記載の方法において、前記レポジトリは、複数のデータ・カプセルを線形に整列する処理に備える、方法。
【請求項２４】
請求項１記載の方法であって、前記第２アプリケーションの動作中、前記少なくとも１つのデータ・シーケンスを用いるステップを備えている、方法。
【請求項２５】
請求項１記載の方法において、前記イベントは、ユーザ・インターフェース・イベントを備えている、方法。
【請求項２６】
請求項１記載の方法において、前記イベントは、グラフィクス・イベントを備えている、方法。
【請求項２７】
請求項１記載の方法において、前記イベントは、状態情報の貯入を備えている、方法。
【請求項２８】
データをカプセル化する方法であって、
デバイス・イベント・データとソース・デバイスの識別データとを含むディスクリップ・リストを含む第１データ集合を発生するステップであって、前記デバイス・イベント・データは、前記ソース・デバイスが登録したイベントを指定するデータを含み、前記識別データは、前記ソース・デバイスを識別するデータを含む、ステップと、
前記イベントの状態情報集合全体を含むインジェストを含む第２データ集合を発生するステップと、
前記第１データ集合および前記第２データ集合の各々は、タイプ特定データ・レイアウトとした類型データ・バンドルを備えており、
前記第１データ集合および前記第２データ集合を含むようにデータ・カプセルを形成することにより、前記第１データ集合および前記第２データ集合をカプセル化するステップであって、前記データ・カプセルが、前記第１データ集合及び前記第２データ集合の類別されていない表現であるデータ構造を有する、ステップと、
前記データ・カプセルを、第１アプリケーション・タイプを有する第１アプリケーションから、少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションに少なくとも１つのプールを介して転送するステップであって、前記第１アプリケーション・タイプは前記第２アプリケーション・タイプとは異なり、前記少なくとも１つのデータ・シーケンスを発生するステップを、前記第１アプリケーションによって実行する、ステップと、
前記転送の間、前記データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するステップと、
を備えている、方法。
【請求項２９】
第１タイプのアプリケーションの下で走るデバイスのイベントを検出するステップと、
前記イベントを指定するデバイス・イベント・データであるディスクリプトと、当該イベントの状態情報であるインジェストとを備えている少なくとも１つのデータ・シーケンスを含むプロテインを発生するステップであって、前記デバイス・イベント・データおよび状態情報は、それぞれ前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている、ステップと、
前記データ・シーケンスであるプロテインを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記データ・シーケンスの類別されていない表現であるデータ構造を有する、ステップと、
前記データ・カプセルをレポジトリに転送するステップと、
少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で走る少なくとも１つの第２ソース・デバイスの第２イベントを検出するステップであって、前記第２タイプが前記第１タイプとは異なる、ステップと、
前記第２イベントに対応するデータ・カプセルを求めて、前記レポジトリを検索するステップと、
前記データ・カプセルと前記第２イベントとの間にある対応を特定するステップと、
前記対応の特定に応答して、前記レポジトリから前記データ・カプセルを抽出するステップと、
前記第２イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用いて、動作を実行するステップと、
を備えている、方法。
【請求項３０】
請求項２９記載の方法において、前記データ・シーケンスを発生するステップは、
前記デバイス・イベント・データを含む第１データ集合を発生するステップと、
前記状態情報を含む第２データ集合を発生するステップと、
前記第１データ集合および前記第２データ集合を含むように、第１データ・シーケンスを形成するステップと、
を備えている、方法。
【請求項３１】
請求項２９記載の方法において、前記デバイス・イベント・データは、類別したデータを表す、タグ付きのバイト・シーケンスである、方法。
【請求項３２】
請求項３１記載の方法において、前記デバイス・イベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項３３】
請求項２９記載の方法において、前記状態情報は、類別したデータを表す、タグ付きのバイト・シーケンスである、方法。
【請求項３４】
請求項３３記載の方法において、前記状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
【請求項３５】
請求項２９記載の方法であって、
少なくとも１つのオフセットを発生するステップと、
前記少なくとも１つのオフセットを含むように、前記データ・カプセルを形成するステップと、
を備えている、方法。
【請求項３６】
請求項３５記載の方法であって、
第１変数長を有する第１オフセットを発生するステップであって、前記第１オフセットは、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記デバイス・イベント・データを指し示す、ステップと、
第２可変長を有する第２オフセットを発生するステップであって、前記第２オフセットは、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報を指し示す、ステップと、
を備えている、方法。
【請求項３７】
請求項３５記載の方法であって、
前記少なくとも１つのオフセットの第１オフセットを用いて、前記データ・カプセルを通る第１コード・パスを形成するステップと、
前記少なくとも１つのオフセットの第２オフセットを用いて、前記データ・カプセルを通る第２コード・パスを形成するステップと、
を備えており、前記第１コード・パスおよび前記第２コード・パスは異なるパスである、方法。
【請求項３８】
請求項３５記載の方法において、前記第１オフセットおよび前記第２オフセットの内少なくとも１つは、メタデータを含み、該メタデータは、前記アプリケーションのコンテキストに対応する、コンテキスト特定メタデータを備えている、方法。
【請求項３９】
請求項２９記載の方法において、前記レポジトリは、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに結合されており、前記レポジトリは、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、前記レポジトリは、前記アプリケーションおよび前記少なくとも１つの第２アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法。
【請求項４０】
請求項２９記載の方法において、前記レポジトリは、複数のデータ・カプセルの状態をキャッシュする処理に備える、方法。
【請求項４１】
請求項２９記載の方法において、前記レポジトリは、複数のデータ・カプセルを線形に整列する処理に備える、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、２００７年４月２７日に出願した米国（ＵＳ）特許出願第６０／９２６，１１６の優先権を主張する。
【０００２】
本願は、２００５年２月８日に出願した米国仮特許出願第６０／６５１，２９０号の優先権を主張する、２００６年２月８日に出願した米国特許出願第１１／３５０，６９５７号に関連がある。
【０００３】
技術分野
実施形態は、計算プロセス内および計算プロセス間におけるデータの表現、操作、および交換に関して説明する。
【背景技術】
【０００４】
従来のプログラミング環境は、マルチ・コンピュータ演算装置（ＣＰＵ）やクロス・ネットワーク実行、あるいは多数の計算プロセス間におけるデータの柔軟な共有を最大限支援していない。
【０００５】
例えば、従来のユーザ対面(user-facing)計算プラットフォーム（例えば、OS X、Microsoft Windows（登録商標）、UNIX（登録商標）上のX Windows（登録商標））は、プロセス間においてイベント・データを伝送する設備(facilities)を提供する。しかし、これら既存のメカニズムの全てには欠点があり、そのためにマルチ・プロセスおよびマルチ・マシン・アプリケーションを構築することが困難となっており、更に複数のプログラミング言語で作業するユーザは、苛立たしい輪を潜り抜けることを余儀なくされている。例えば、従来のイベント・フレームワークは厳しく類型に分けられており、そのためにこれらは柔軟性を欠き、アプリケーション・プログラマに対するシステム販売業者の専有(assumption)が特権として認められており、増々普及しつつある動的言語（例えば、Ruby、Python、およびPerl）の設備との不一致が形成される。また、従来のフレームワークは、２点間データ転送しかサポートしないように構成されており、数個を超える別個のプロセスの活動(activity)を調整することが困難または不可能となる。また、従来のフレームワークは、特定のローカル・メモリ内データ構造に強く依存するので、ディスク上の格納またはネットワークを跨る送信には不向きとなっている。
【発明の概要】
【０００６】
引用による包含
本明細書において述べる各特許、特許出願、および／または刊行物は、本願において引用することにより、個々の特許、特許出願、および／または刊行物の各々が具体的にそして個々に、引用することにより本願に含まれることを示した場合と同程度にその全体が本願にも含まれるものとする。
【０００７】
本明細書では、大規模マルチ・プロセス相互動作を可能としかつ促進する新規のプログラミングまたは処理環境を含む実施形態を教示する。本明細書において提供する実施形態は、マルチ・コンピュータ演算装置（ＣＰＵ）およびクロス・ネットワーク実行や、多数の計算処理間における柔軟なデータ共有を最大限支援しない従来のプログラミング環境における問題を克服する。
【０００８】
本明細書では、プロセス間でまたはプロセスを跨って共有しようとするデータをカプセル化する方法およびシステムについて記載する。これらのメカニズムはスロークス(slawx)（「slaw」の複数形）、プロテイン(protein)、およびプール(pool)を含む。概して、スロークスは、プロセス間交換について最低レベルのデータ定義を規定し、プロテインは、中間レベルの構造を規定し、問い合わせおよびフィルタリングのためのフック(hook)を備えており、プールは高レベルの編成およびアクセス・セマンティクス(semantics)を規定する。スロークスは、効率的な、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、スロークスをペイロードとして用いる、データ・カプセル化および輸送方式を規定する。プールは、１つのプロセス内部、ローカル・プロセス間、遠隔プロセスまたは分散プロセス間にあるネットワークを跨いだ、そして長期（例えば、ディスク上等における）記憶による、プロテインの構造化された柔軟な集計、順序付け、フィルタ処理、および分散を規定する。
【０００９】
本明細書において記載する実施形態の構成および実施態様には、数個の構造が含まれ、これらが一緒になって多数の処理能力が可能となる。例えば、本明細書において記載する実施形態は、多数の処理間における効率的なデータ交換に備えている。また、本明細書において記載する実施形態は、柔軟なデータ「類別」(typing)および構造も規定するので、データの広範囲の多様な種類および使用をサポートする。更に、本明細書において記載する実施形態は、データ交換のための柔軟なメカニズム（例えば、ローカル・メモリ、ディスク、ネットワーク等）を含み、これらは全て実質的に同様のアプリケーション・プログラミング・インターフェース（ＡＰＩ）によって駆動される。更に、記載する実施形態は、異なるプログラム言語で書かれたプロセス間におけるデータ交換も可能にする。加えて、本明細書において記載する実施形態は、データ・キャッシュおよび集計状態の自動保守も可能にする。
【００１０】
以下の説明では、本明細書において記載する実施形態の完全な理解が得られ、その実施を可能にする説明を提示するために、多数の具体的な詳細を紹介する。しかしながら、これらの実施形態は、その具体的詳細の１つ又は複数がなくても、または他のコンポーネント、システム等を用いても実用化できることは、当業者には認められよう。一方、周知の構造または動作は、開示する実施形態の態様が曖昧になるのを避けるために、示さないか、または詳細には説明しないこととする。
【００１１】
以下の用語は、本明細書において用いられる場合、以下の一般的な意味を有することを意図している。「プロセス」という用語は、本明細書において用いられる場合、ある時間期間実行するコンピュータ・プログラムを意味する。この実行は、休止あるいはプロセッサまたはマシン間の転送によって中断される場合もあるので、プロセスを無期限に保留すること、「直列化」すること、あるいはディスクに、メモリ・バス間で、またはネットワーク上で「整列」(marshal)させることも可能である。前述の意味は、当業者によって理解される別の意味を含むこともできる。
【００１２】
「デバイス」という用語は、本明細書において用いる場合、１つ又は複数のプログラムまたはアルゴリズムを走らせるあらゆるプロセッサ主体デバイス、１つ又は複数のプログラムまたはアルゴリズムの下で走るあらゆるプロセッサ主体デバイス、および／または１つ又は複数のプログラムまたはアルゴリズムを走らせる、および／または１つ又は複数のプログラムまたはアルゴリズムの下で走るプロセッサ主体デバイスに結合または接続されているあらゆるデバイスを意味する。「イベント」という用語は、本明細書において用いる場合、走っている即ち実行中のプログラムまたはアルゴリズム、プロセッサ主体デバイス、および／またはプロセッサ主体デバイスに結合または接続されているデバイスと関連のあるあらゆるイベントを意味する（例えば、イベントは、入力、出力、制御、状態、状態変化、処置(action)、データ（データのフォーマットや、データと関連のある処理における段階には無関係）等を含むことができるが、これらに限定されるのではない）。
【図面の簡単な説明】
【００１３】
【図１】図１は、一実施形態の下における、スロークス、プロテイン、およびプールを用いたデータ表現を含む処理環境のブロック図である。
【図２】図２は、一実施形態の下における、プロテインのブロック図である。
【図３】図３は、一実施形態の下における、デスクリップ(descrip)のブロック図である。
【図４】図４は、一実施形態の下における、インジェスト(ingest)のブロック図である。
【図５】図５は、一実施形態の下におけるスロー(slaw)のブロック図である。
【図６Ａ】図６Ａは、一実施形態の下における、プールの中にあるプロテインのブロック図である。
【図６Ｂ】図６Ｂは、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。
【図６Ｃ】図６Ｃは、一実施形態の下においてプロテインを用いる際の流れ図である。
【図６Ｄ】図６Ｄは、一実施形態の下において、プロテインを組み立てるまたは発生する際の流れ図である。
【図７】図７は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。
【図８】図８は、一実施形態の下において、多数のデバイスと、これらのデバイスの１つ又は複数で走る多数のプログラムを含み、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。
【図９】図９は、一代替実施形態の下において、多数のデバイスと、これらのデバイスの１つ又は複数で走る多数のプログラムを含み、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。
【図１０】図１０は、別の代替実施形態の下において、多数の入力デバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。
【図１１】図１１は、更に別の代替実施形態の下において、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。
【図１２】図１２は、更に別の代替実施形態の下において、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする処理環境のブロック図である。
【図１３】図１３は、追加の代替実施形態の下において、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる処理環境のブロック図である。
【発明を実施するための形態】
【００１４】
図１は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ表現を含む処理環境のブロック図である。本明細書において紹介する実施形態の主要な構造には、スロークス（「スロー」(slaw)の複数形）、プロテイン、およびプールが含まれる。本明細書において記載する場合、スロークスは、効率的で、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、本明細書において詳細に説明するように、データ・カプセル化および輸送方式を規定し、一実施形態のプロテインのペイロードはスロークスを含む。プールは、本明細書において記載する場合、プロテインの構造化されているが柔軟な集計、順序付け、フィルタ処理、および分散を規定する。プールは、プロテインのための、プロセス内部における、ローカル・プロセッサ間での、リモートまたは分散プロセス間にあるネットワークを跨いだ、そして「長期」（例えば、デスク上）記憶による、データへのアクセスを与える。
【００１５】
図２は、一実施形態の下におけるプロテインのブロック図である。プロテインは、長さヘッダ、ディスクリップ(descrip)、およびインジェスト(ingest)を含む。以下で詳細に説明するが、ディスクリップおよびインジェストの各々は、スローまたはスロークスを含む。
【００１６】
図３は、一実施形態の下におけるディスクリップのブロック図である。以下で詳細に説明するが、ディスクリップは、オフセット、長さ、およびスロークスを含む。
図４は、一実施形態の下におけるインジェストのブロック図である。以下で詳細に説明するが、インジェストは、オフセット、長さ、およびスローを含む。
【００１７】
図５は、一実施形態の下におけるスローのブロック図である。以下で詳細に説明するが、スローは、タイプ・ヘッダ、およびタイプ特定データを含む。
図６Ａは、一実施形態の下における、プールの中にあるプロテインのブロック図である。プロテインは、長さヘッダ（「プロテイン長さ」）、ディスクリップ・オフセット、インジェスト・オフセット、ディスクリップ、およびインジェストを含む。ディスクリップは、オフセット、長さ、およびスローを含む。インジェストは、オフセット、長さ、およびスローを含む。
【００１８】
プロテインは、本明細書において記載する場合、プロセッサ間で共有する、あるいはバスまたはネットワークまたはその他の処理構造を跨いで移動する必要があるデータをカプセル化するメカニズムのことである。一例として、プロテインは、ユーザ・インターフェース・イベントに対応するまたは関連するデータを含むデータの輸送および操作のための改良メカニズムを提供する。具体的には、一実施形態のユーザ・インターフェース・イベントは、２００６年２月８日に出願した米国特許出願第１１／３５０，６９７号に記載されているジェスチャ・インタフェースのそれを含む。この特許出願をここで引用したことにより、その内容が本願にも含まれるものとする。更に別の例として、プロテインは、限定ではく、グラフィクス・データまたはイベント、および状態情報等その他多数を含むデータの輸送および操作のための改良メカニズムを提供する。プロテインは、構造化レコード・フォーマット、およびレコードを操作するための１組の関連方法である。本明細書において用いる場合、レコードの操作は、データを構造に入力すること、構造からデータを取り出すこと、およびデータのフォーマットおよび存在を問い合わせることを含む。プロテインは、種々のコンピュータ言語で書かれたコードを通じて用いられるように構成されている。また、プロテインは、本明細書において記載するような、プールの基本的構築ブロックとなるように構成されている。更に、プロテインは、それらが含むデータを不変のまま維持しつつ、プロセッサ間そしてネットワークを跨いで自然に移動できるように構成されている。
【００１９】
従来のデータ輸送メカニズムとは対照的に、プロテインにはタイプが決められていない。タイプは決められていないが、プロテインは、「タイプ状」機能性を実装することに加えて、強力で柔軟性のあるパターン照合設備(facility)を備えている。また、本明細書に記載するように構成されているプロテインは、本質的に多点型でもある（しかし、二点間形態も、多点伝送の部分集合として容易に実現される）。加えて、プロテインはメモリ内、ディスク上、およびワイヤ（ネットワーク）上フォーマット間で異なることがない「ユニバーサル」レコード・フォーマットを定義する（即ち、実行する任意の最適化の種類だけが異なる）。
【００２０】
図２および図６を参照すると、一実施形態のプロテインは、バイトの線形シーケンスである。これらのバイトの中には、ディスクリップ・リストと、１組のキー値対がカプセル化されている。キー値対をインジェストと呼ぶ。ディスクリップ・リストは、綿密(elaborate)であるが効率的にフィルタ可能なプロテイン毎のイベント記述を任意に含む。インジェストは、１組のキー値対を含み、これらがプロテインの実際の内容を構成する。
【００２１】
プロテインのキー値対との関わり、ならびにネットワークに都合がよい(network-friendly)多点データ相互交換に関する中核的観念の一部は、「タプル」の概念を特別に許可する(priviledge)もっと簡単なシステム（例えば、Linda、Jini）と共有される。プロテインは、タプル指向システムとは様々な面で大きく異なり、その相違には、標準的、最適化可能なパターン照合基盤を設けるためにディスクリップ・リストを用いることが含まれる。また、プロテインがタプル指向システムと異なるのは、種々の記憶および言語構造に適したレコード・フォーマットの厳格な仕様、そしてそのレコード・フォーマットに対する「インターフェース」の色々な特定的な実施態様である。
【００２２】
プロテインの説明に戻って、プロテインの最初の４バイトまたは８バイトは、プロテインの長さを指定する。一実施形態では、長さは１６バイトの倍数でなければならない。この１６バイトの粒度により、バイト整合およびバス整合効率が現在のハードウェアでも達成可能であることを確保する。本来「４ワード整合」型でないプロテインには、任意のバイトを詰めこんで、その長さが１６バイトの倍数となるようにする。
【００２３】
プロテインの長さ部分は、次のフォーマットを有する。ビッグ・エンディアン・フォーマット(big-endian format)で長さを指定する３２ビット。その下位４ビットはマクロ・レベルのプロテイン構造特性を示すフラグとして機能する。プロテインの長さが２＾３２バイトよりも大きい場合、その次に来る更に別の３２ビット。
【００２４】
一実施形態における１６バイト整合条件は、最初の４バイトの最下位ビットがフラグとして利用可能であることを意味する。そして、このため、最下位の３ビット・フラグは、プロテインの長さが最初の４バイトで表現できるのか、または８バイト必要なのかを示し、プロテインがビッグ・エンディアンまたはリトル・エンディアンの内どちらのバイト順序付けを用いるのかを示し、更に、プロテインが標準的構造または非標準的構造のどちらを採用するのかをそれぞれ示すが、プロテインはこのように限定されるのではない。４番目のフラグ・ビットは、今後の使用のために保存されている。
【００２５】
８バイト長フラグ・ビットがセットされている場合、プロテインの長さを計算するには、次の４バイトを読み取り、これらをビッグ・エンディアン、８バイト整数の上位バイトとして用いる（４バイトは既に読み取られ、下位部分を供給する）。リトル・エンディアン・フラグがセットされている場合、プロテインの中にある全ての二進数値データをリトル・エンディアンとして解釈する（それ以外の場合は、ビッグ・エンディアン）。非標準フラグ・ビットがセットされている場合、プロテインの残りの部分は、以下で説明する標準構造に従わない。
【００２６】
非標準プロテイン構造については、プロテインおよびプールを用いるシステム・プログラマには、非標準プロテイン・フォーマットを記述しこれに同期するための種々の方法が利用可能であること、そしてこれらの方法は、空間または計算サイクルが制限されているときに有用となることができることを除いて、ここではこれ以上論じない。例えば、一実施形態では、最短のプロテインは１６バイトである。標準フォーマットのプロテインは、実際のペイロード・データをこれらの１６バイトにはめ込むことは全くできない（その一番大きい部分は既に、プロテインのコンポーネント・パーツの位置を記述することが任されている）。しかし、非標準フォーマット・プロテインは、その１６バイトの内１２バイトをデータに用いることができると考えられる。２つのアプリケーションがプロテインを交換すると、これらが発信するいずれの１６バイト長プロテインでも常に１２バイトを含み、これらは、例えば、リアル・タイム・アナログ／ディジタル変換器からの１２個の８ビット・センサ値を表すことを相互に決定することができる。
【００２７】
長さヘッダの直後には、プロテインの標準構造では、更に２つの可変長整数値が現れる。これらの数値は、それぞれ、ディスクリップ・リストにおける最初のエレメント、および最初のキー値対（インジェスト）に対するオフセットを指定する。これらのオフセットは、本明細書では、それぞれディスクリップ・オフセットおよびインジェスト・オフセットとも呼ぶ。これらの数値の各クアッド(quad)のバイト順序は、プロテイン・エンディアンネス・フラグ・ビット(protein endianness flag bit)によって指定される。各々について、最初の４バイトの最上位ビットは数値が４または８バイト幅のどちらであるかを決定する。最上位ビット（ｍｓｂ）がセットされている場合、最初の４バイトは二重ワード（８バイト）数値の最上位バイトとなる。ここでは、これを「オフセット形式」と呼ぶ。ディスクリップおよび対を指し示す別個のオフセットを用いることにより、ディスクリップおよび対を異なるコード・パスによって扱うことが可能となり、例えば、ディスクリップ・パターン照合およびプロテイン・アセンブリに関する個々の最適化を行うことができるようになる。また、これら２つのオフセットがプロテインの先頭にあるため、様々な有用な最適化に対処できる。
【００２８】
殆どのプロテインは８バイト長またはポインタを必要とする程大きくないので、一般に長さ（とフラグ）および２つのオフセット数値は、プロテインの最初の３バイトを占めるに過ぎない。多くのハードウェアまたはシステム・アーキテクチャでは、最初のバイトを超えるある数のバイトのフェッチ即ちリードは、「自由」である（例えば、１６バイトは、セル・プロセッサ(Cell processor)の主要バスを介して引き込むには、１バイトと全く同じ数のクロック・サイクルを要する。）
多くの場合、プロテイン内部において実施態様特定またはコンテキスト特定のキャッシング(caching)またはメタデータを許容することは有用である。オフセットの使用により、プロテインの先頭付近に、任意のサイズの「孔」を作成し、その中にこのようなメタデータを割り込ませることができる。８バイトのメタデータを利用することができる実施態様では、多くのシステム・アーキテクチャ上でこれらのバイトを、長さヘッダをフェッチする毎に１つのプロテインに対して自由に得ることができる。
【００２９】
ディスクリップ・オフセットは、プロテインの先頭と最初のディスクリップ・エントリとの間のバイト数を指定する。各ディスクリップ・エントリは、次のディスクリップ・エントリまでのオフセット（勿論、オフセット形態で）を備えており、その後に可変幅の長さフィールド（これもオフセット・フォーマットで）が続き、更にその後にスローが続く。これ以上ディスクリップがない場合、オフセットは、規則上、０の４バイトとなる。それ以外の場合、オフセットは、当該ディスクリップ・エントリの開始と次との間のバイト数を指定する。長さフィールドは、バイト単位で、スローの長さを指定する。
【００３０】
殆どのプロテインでは、各ディスクリップは、スロー・ストリング様式でフォーマットしたストリングであり、４バイトの長さ／タイプヘッダを有し、最上位ビットがセットされ、下位３０ビットだけが長さを指定するために用いられ、その後に、ヘッダが指示する数のデータ・バイトが続く。通常通り、長さヘッダはそのエンディアンネスをプロテインから取り込む。バイトは、ＵＴＦ−８キャラクタをエンコードすると仮定する（したがって、キャラクタ数は必ずしもバイト数と同じではないことを注記しておく）。
【００３１】
インジェスト・オフセットは、プロテインの先頭と最初のインジェスト・エントリとの間のバイト数を指定する。各インジェスト・エントリは、次のインジェスト・エントリまでのオフセット（オフセット・フォームで）を備えており、その後にこの場合も長さフィールドおよびスローが続く。インジェスト・オフセットは、次のディスクリップ・エントリの代わりに次のインジェスト・エントリを指し示すことを除いて、ディスクリップ・オフセットと機能的には同一である。
【００３２】
殆どのプロテインでは、各インジェストは、スロー・コンス・タイプ(slaw cons type)であり、二値リストを備えている。このリストは通常キー／値対として用いられる。スロー・コンス・レコードは、最上位から２番目のビットがセットされており、下位３０ビットだけが長さを指定するために用いられる４バイトの長さ／タイプ・ヘッダと、４バイトの値（２番目）エレメントの先頭までのオフセットと、前述の４バイトのキー・エレメント長と、キー・エレメントに対するスロー・レコードと、４バイト長の値エレメントと、最後に前述の値エレメントに対するスロー・レコードとを備えている。
【００３３】
一般に、コンス・キーはスロー・ストリングである。数個のプロテインおよびスロー・コンス長ならびにオフセット・フィールドを跨いでデータを複製することにより、工夫(refinement)および最適化の一層多くの機会が得られる。
【００３４】
前述のように、類型に分けたデータをプロテイン内部に埋め込むために一実施形態において用いられる構造(construct)は、タグ付きのバイト・シーケンス指定および抽象化(abstraction)であり、「スロー」と呼ばれる（複数形は「slawx」となる）。スローは、類型に分けた（恐らくは、集計）データの一片を表すバイトの線形シーケンスであり、プログラミング言語特定ＡＰＩと関連付けられている。ＡＰＩは、スロークスを作成し、修正し、メモリ空間、記憶媒体、およびマシンの間で移動させることができる。スロー・タイプ方式(slaw type scheme)は、拡張可能でできるだけ軽量であり、あらゆるプログラミング言語からでも用いることができる共通基盤となることを意図している。
【００３５】
効率的な、大規模プロセス間通信メカニズムを構築することの要望が、スロー・コンフィギュレーションの原動力(driver)である。従来のプログラミング言語は、精巧なデータ構造およびタイプ設備を備えており、プロセス特定のメモリ・レイアウトでは申し分なく動作するが、データをプロセッサ間で移動させたり、ディスク上に格納することが必要となると、これらのデータ表現はいつでも決まって分解する。スロー・アーキテクチャは、第１に、プロセス間通信に対する、非常に効率的で、マルチ・プラットフォームに都合がよい低レベル・データ・モデルである。
【００３６】
しかし、更に一層重要なのは、スロークスが、プロテインと共に、今後の計算機ハードウェア（マイクロプロセッサ、メモリ・コントローラ、ディスク・コントローラ）の開発に影響を及ぼし、それを可能にするように構成されていることである。例えば、広く一般に入手可能なマイクロプロセッサの命令セットに、多少の具体的な追加を行うことにより、スロークスが、殆どのプログラミング言語において用いられている方式と同様に、単一プロセス、メモリ内データ・レイアウトに対しても効率的となることが可能になる。
【００３７】
各スローは、可変長のタイプ・ヘッダと、その後に続くタイプ特定データ・レイアウトとを備えている。例えば、Ｃ、Ｃ＋＋、およびRubyにおけるスロー機能性を全てサポートする実施形態の一例では、タイプは、各言語からアクセス可能なシステム・ヘッダ・ファイルにおいて定義されているユニバーサル整数(universal integer)によって示される。更に精巧化し柔軟性を高めたタイプ解明機能性(type resolution functionality)、例えば、ユニバーサル・オブジェクトＩＤおよびネットワーク参照による間接的類型決定も可能である。
【００３８】
一実施形態のスロー・コンフィギュレーションは、スロー・レコードを、例えば、RubyおよびＣ＋＋双方から言語に優しい様式でオブジェクトとして用いることを可能にする。Ｃ＋＋コンパイラ外部の１組のユーティリティが、スロー・バイト・レイアウトの健全性をチェックし、個々のスロー・タイプに特定的なヘッダ・ファイルおよびマクロを作成し、Rubyに対するバインディング(binding)を自動的に発生する。その結果、正しく構成したスロー・タイプは、１つのプロセスの中から用いた場合でも、非常に効率的となる。プロセスのアクセス可能なメモリのいずれの場所におけるいずれのスローでも、コピーや「非直列化」ステップがなくても、アドレスすることができる。
【００３９】
一実施形態のスロー機能性は、以下の内１つ又は複数を実行するＡＰＩ機能性を含む。具体的なタイプの新たなスローを作成する。ディスク上またはメモリ内におけるバイトからのスローへの言語特定参照を作成または構築する。タイプに特定の様式でスロー内にデータを埋め込む。スローのサイズを問い合わせる。スロー内部からデータを引き出す。スローのクローンを作成する。そして、スロー内部にある全てのデータのエンディアンネスおよびその他のフォーマット属性を変換する。スローのあらゆる種(species)が以上の挙動を実施する。
【００４０】
図６Ｂは、一実施形態の下におけるスロー・ヘッダーのフォーマットを示す。以下にスローの詳細な説明を行う。
各スローの内部構造(structure)は、タイプ解明、カプセル化データへのアクセス、および当該スロー・インスタンスについてのサイズ情報の各々を最適化する。一実施形態では、１組のスロー・タイプ全体は、設計上、最小限の全てが揃っており、スロー・ストリング、スロー・コンス（即ち、ダイアッド(dyad)）、スロー・リスト、およびスロー数値オブジェクトを含む。スロー数値オブジェクト自体は、半ダース程度の基本的な属性の組み合わせ(permutation)として理解される、広範な１組の個別数値タイプを表す。いずれのスローでも、その他の基本的プロパティはそのサイズである。一実施形態では、スロークスは、４の倍数に量子化したバイト長を有し、これらの４バイト・ワードを、ここでは「クアッド」と呼ぶ。一般に、このようなクアッドに基づくサイズ決定により、スロークスを最新のコンピュータ・ハードウェア・アーキテクチャのコンフィギュレーションと正確に整合させる。
【００４１】
一実施形態では、各スローの最初の４バイトは、ヘッダ構造(structure)を備えている。ヘッダ構造(structure)は、タイプ記述およびその他のメタ情報をエンコードし、特定的なタイプの意味を特定のビット・パターンに帰属させる(ascribe)。例えば、スロー・ヘッダの最初の（最上位）ビットは、そのスローのサイズ（クアッド・ワード単位の長さ）が最初の４バイトのタイプ・ヘッダに従うか否か指定するために用いることができる。このビットがセットされている場合、スローのサイズが当該スローの次の４バイト（例えば、バイト５から８まで）に明示的に記録されていることが分かる。スローのサイズが、４バイトでは表現できないような場合（即ち、サイズが２の３２乗以上である場合）、スローの最初の４バイトの次の最上位ビットもセットする。これは、スローが８バイト（４バイトではなく）長を有することを意味する。その場合、検査プロセスが、序数バイト(ordinal byte)５から１２までに格納されているスローの長さを発見する。他方で、スロー・タイプの数値が小さいことは、多くの場合、完全に指定した類型ビット・パターンが、４バイトのスロー・ヘッダにおける多くのビットを「未使用のまま残してある」ことを意味し、そのような場合、これらのビットは、スローの長さをエンコードするために用いてもよく、そうしなければ必要となるはずのバイト（５から８まで）を取っておくことができる。
【００４２】
例えば、一実施形態では、スロー・ヘッダの最上位ビット（「長さ従属」フラグ）をセットしないままにしておき、次のビットをセットして、そのスローが「微小コンス」であることを示し、この場合、スローの長さ（クアッド単位）を残りの３０ビットにエンコードする。同様に、「微小ストリング」は、ヘッダにおけるパターン００１によって印され、スロー・ストリングの長さを表すために、２９ビットが残され、ヘッダにおける最初の０００１が「微小リスト」を記述する。これは、２８ビットの利用可能長表現ビットのために、サイズが２から２８クアッドまでのスロー・リストとすることができる。「最大ストリング」（あるいはコンスまたはリスト）は、ヘッダに異なるビット・シグネーチャを有し、ヘッダの最上位ビットは必ずセットされる。何故なら、スロー長はバイト５から８（または、極端な場合には１２）において別個にエンコードされるからである。尚、プラズマ実施態様は、スローの組立時に、これらの構造(construct)の「微小」バージョンまたは「最大」バージョンのどちらを採用すべきか「決定する」（決定は、最終的なサイズが利用可能な微小ビットに「納まるか」否かに基づく）が、最大−対−微小の詳細は、プラズマ実施態様のユーザには隠されている。ユーザは、スロー・ストリング、またはスロー・コンス、またはスロー・リストを用いていることしか知らないし、そのことしか気に留めない。
【００４３】
一実施形態では、数値スロークスは、最初のヘッダ・パターン００００１によって示される。後続のヘッダ・ビットは、任意の順列に組み合わせることができる１組の直交プロパティを表すために用いられる。一実施形態では、数値が（１）浮動小数点、（２）複素数、（３）符号なし、（４）「広い」、（５）「太くて短い」(stumpy)であるか否かを示すために、５つのこのようなキャラクタ・ビットを用いるが、これらに限定されるのではない（（４）「広い」および（５）「太くて短い」の順序を変えて、８、１６、３２、および６４ビット数表現を示す）。２つの追加ビット（例えば、（７）および（８））は、カプセル化した数値データが、２−、３−、または４−エレメント・ベクトルであることを示す（双方のビットが０の場合、数値が「１−エレメント・ベクトル」（即ち、スカラー）であることを示唆する）。この実施形態では、４番目のヘッダ・バイトの８ビットを用いて、カプセル化した数値データのサイズを（クアッド単位ではなく、バイト単位で）エンコードする。このサイズのエンコード処理は、１から２５６までの間のいずれのサイズでも表すことができるように、１だけずらされる。最後に、２つのキャラクタ・ビット（例えば、（９）および（１０））を用いて、数値データが個々の数値エンティティの配列をエンコードすることを示す。数値エンティティの各々は、キャラクタ・ビット（１）から（８）までによって記述されるタイプのものである。アレイの場合、個々の数値エンティティには、各々、追加のヘッダが添付されず、１つのヘッダおよび恐らくは、明示的なスロー・サイズ情報に続く連続データとしてパックされる。  
【００４４】
この実施形態では、単純かつ効率的なスローの複製（バイト毎のコピーとして実施することができる）、および非常に単純で効率的なスローの比較が可能となる（この実施形態では、連続と見なされる構成バイトの各々に１対１の一致がある場合に限って、２つのスロークスは同一となる）。後者のプロパティは、例えば、プロテイン・アーキテクチャの効率的な実現には重要である。その重要なそして波及する(pervasive)特徴は、プロテインのディスクリップ・リスト全体を検索できること、または「リスト上で照合」できることである。
【００４５】
更に、本明細書における実施形態は、集計スロー形態（例えば、スロー・コンスおよびスロー・リスト）を簡単かつ効率的に作成することを可能にする。例えば、一実施形態では、スロー・コンスを、いずれのタイプでもよく、これら自体集計を含む、２つの成分スロークスから次のように構築する。（ａ）各成分スローのサイズを問い合わせ、（ｂ）２つの成分スロークスのサイズ、およびヘッダ・プラス・サイズ構造(structure)に必要な１、２、または３クアッドの和に等しいサイズのメモリを割り当て、（ｃ）最初の４、８、または１２バイトにスロー・ヘッダ（およびサイズ情報）を記録し、次いで（ｄ）成分スロークスのバイトを順番に、直後に続くメモリにコピーする。重要なのは、このような組立ルーチンは、２つの成分スロークスのタイプについて何も知る必要がなく、それらのサイズ（そして、バイトのシーケンスとしてのアクセス可能性）だけが問題であることである。同じプロセスは、スロー・リストの作成にも関与する。スロー・リストは、（恐らくは）異質なタイプの任意の多くのサブ・スロークス(sub-slawx)の順序付けしたカプセル化である。
【００４６】
メモリにおける連続バイトとしてのスロー・システムの基本的フォーマットの更に別の成果が、「横断」活動(traversal activities)と関連して得られる。反復使用パターンが、例えば、スロー・リストに格納されている個々のスロークスへの順次アクセスを用いる。プロテイン構造(structure)内部におけるディスクリップおよびインジェストを表す個々のスロークスも同様に横断しなければならない。このような操作は、驚く程単純かつ効率的な方法で遂行される。つまり、スロー・リストにおける次のスローに「進み」、現在のスローの長さをそのメモリ位置に追加し、結果的に得られたメモリ位置が、次のスローのヘッダと同一となる。このような簡素さが可能なのは、スローおよびプロテインの設計が「間接」を避けるからである。つまり、ポインタがなく、データは単純にその全体が本来の場所に存在する。
【００４７】
スロー比較の時点までに、プラズマ・システムの完全な実施態様は、異なるオペレーティング・システム、ＣＰＵ、およびハードウェア・アーキテクチャに跨ってそしてこれらの間において、異なり互換性のないデータ表現方式の存在を承認しなければならない。このような相違の主要なものには、バイト順序付け方針（例えば、リトル−エンディアン対ビッグ−エンディアン）および浮動小数点表現が含まれ、その他の相違も存在する。プラズマ仕様では、スロークスによってカプセル化したデータが解釈可能である(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-ＢＸ等）を備えている双方向処理システムが、プラズマ構造(construct)（例えば、プール、プロテイン、およびスロー）を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。
【００５９】
この例では、各デバイス（例えば、デバイスＡ、Ｂ等）は、それぞれのデバイス上で走っているプログラム（例えば、appsAA-AX、appsBA-BX等）が発生したまたは出力された離散生データ(raw data)を、プラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入する。例えば、プログラムＡＸはデータまたは出力を発生し、この出力をデバイスＡに供給する。一方、デバイスＡはこの生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、プログラムＢＣがデータを発生し、このデータをデバイスＢに供給する。一方、デバイスＢはこのデータをプロテイン（例えば、プロテイン１Ｂ、プロテイン２Ｂ等）に変換し、これらのプロテインをプールに貯入する。
【００６０】
各プロテインは、アプリケーションが発生し、プログラム自体についての情報を特定するデータまたは出力を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップは出力イベントまたは行動について一般的な意味論的意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、プログラム・イベントについての１組の有用な状態情報全体を搬送する。
【００６１】
前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で走っているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマ(consumer)を多重化し、デバイスを一人で制御できるように、または数人（例えば、プラズマに基づく入力フレームワークは、多くの同時ユーザをサポートする）で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに見えるようになることである。
【００６２】
一例として、デバイスＣは１つ又は複数のプロテイン（例えば、プロテイン１Ａ、２Ａ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、プロテイン・データが対応する処理イベントにおいて用いることができる。別の例として、デバイスＢは、プールから１つ又は複数のプロテイン（例えば、プロテイン１Ｃ、プロテイン２Ａ等）を抽出することができる。プロテインの抽出に続いて、デバイスＢは、プロテイン・データが対応する処理イベントにおいて、プロテインのデータを用いることができる。
【００６３】
プールに結合または接続されているデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する設備は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
【００６４】
図９は、多数のデバイスと、これらのデバイスの１つ又は複数で走る多数のプログラムを含む処理環境のブロック図であり、一代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、多数のデバイス（例えば、デバイスＡおよびＢにそれぞれ結合されているデバイスＸおよびＹ）および１つ又は複数のコンピュータ（例えば、デバイスＡ、デバイスＢ等）上で走る多数のプログラム（例えば、appsAA-AX、appsBA-ＢＸ等）を備えている双方向処理システムが、プラズマ構造(construct)（例えば、プール、プロテイン、およびスロー）を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。
【００６５】
この例では、各デバイス（例えば、デバイスＡおよびＢにそれぞれ結合されているデバイスＸおよびＹ）は、デバイス・ハードウェア（例えば、デバイスＸ、デバイスＡ、デバイスＹ、デバイスＢ等）が発生した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス（例えば、デバイスＡ、デバイスＢ等）上にホストされている１つ又は複数のプログラムの下で、またはこれらと連携して動作するように管理および／または結合されている。例えば、デバイスＡ上にホストされているアプリケーションＡＢと連携して動作するデバイスＸは、生データを発生し、この離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、デバイスＡ上にホストされているアプリケーションＡＴと連携して動作するデバイスＸが、離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａなど）に変換し、これらのプロテインをプールに貯入する。更に別の例として、デバイスＣ上にホストされているアプリケーションＣＤと連携して動作するデバイスＺは、生データを発生し、この離散生データをプロテイン（例えば、プロテイン１Ｃ、プロテイン２Ｃ等）に変換し、これらのプロテインをプールに貯入する。
【００６６】
各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的な意味論的意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、デバイス・イベントについての１組の有用な状態情報全体を搬送する。
【００６７】
前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で走っているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人（例えば、プラズマに基づく入力フレームワークは、多くの同時ユーザをサポートする）で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。
【００６８】
プールに結合または接続されているデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する設備は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
【００６９】
図１０は、多数の入力デバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されている処理環境のブロック図であり、別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、双方向処理システムは、多数の入力デバイス（例えば、入力デバイスＡ、Ｂ、ＢＡ、およびＢＢ等）を備えており、１つ又は複数のコンピュータ（例えば、デバイスＡ、デバイスＢ等）上で走る多数のプログラム（図示せず）を備えており、、プラズマ構造(construct)（例えば、プール、プロテイン、およびスロー）を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。
【００７０】
この例では、各入力デバイス（例えば、入力デバイスＡ、Ｂ、ＢＡ、およびＢＢ等）は、入力デバイス・ハードウェアが発生した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス（例えば、デバイスＡ、デバイスＢ等）上にホストしたソフトウェア・ドライバ・プログラムによって管理される。例えば、入力デバイスＡは生データを発生し、この生データをデバイスＡに供給する。一方、デバイスＡは離散生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）に変換し、これらのプロテインをプールに貯入する。別の例として、入力デバイスＢＢは生データを発生し、この生データをデバイスＢに供給する。一方、デバイスＢは離散生データをプロテイン（例えば、プロテイン１Ｂ、プロテイン３Ｂ等）に変換し、これらのプロテインをプールに貯入する。
【００７１】
各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的な意味論的意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード（例えば、インジェスト）は、デバイス・イベントについての１組の有用な状態情報全体を搬送する。
【００７２】
例示のために、ここに、このようなシステムにおける２つの典型的なイベントに対するプロテインを示す。ここでは、プロテインはテキストとして表すが、実際の実施態様では、これらのプロテインの構成部分は、類別されたデータ・バンドル（例えば、スロー）である。g-speak "one finger click" pose（「指１本によるクリック」のポーズ）（関連出願に記載されている）を記述するプロテインは、次の通りである。
【００７３】
【表１】
0005905662.tif 000002
別の例として、マウスのクリックを記述するプロテインは次の通りである。
【００７４】
【表２】
0005905662.tif 000003
以上のプロテインの見本のいずれかまたは双方は、そのコードの特定の部分を走らせるホスト・デバイスの関与プログラム(participating program)を生ずる可能性もある。これらのプログラムは、一般的なセマンティック・レベルに関係する場合がある。全ての内最も一般的なのは「point」であり、更に具体的な対は「engage, one」である。また、これらは、正確なデバイス：「one-finger-engage」または正に１つの集計オブジェクト(aggregate object)「hand-id-23」のみによってもっともらしく発生されるイベントを求めている場合もある。
【００７５】
前述のように、プロテインは、プログラムやデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが用いるために、プールにおいて利用可能である。したがって、あらゆる数のコンピュータ上で走るあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出する。これらのデバイスは、プロテインをプールから抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、入力イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人（例えば、プラズマに基づく入力フレームワークは、多くの同時ユーザをサポートする）で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。
【００７６】
プロテイン使用の一例として、デバイスＣは１つ又は複数のプロテイン（例えば、プロテイン１Ｂ等）をプールから抽出することができる。プロテイン抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、当該プロテイン・データが対応する入力デバイスＣＡおよびＣＣの入力イベントを処理する際に用いることができる。別の例として、デバイスＡは、１つ又は複数のプロテイン（例えば、プロテイン１Ｂ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＡは、プロテイン・データが対応する入力デバイスＡの入力イベントを処理する際に、当該プロテインのデータを用いることができる。
【００７７】
プールに結合または接続されているデバイスおよび／またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する設備は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
【００７８】
本明細書において記載するシステムの実施形態に用いられる入力デバイスの例には、ジェスチャ入力センサ、キーボード、マウス、消費者電子機器において用いられるような赤外線リモコン装置、およびタスク指向有体媒体オブジェクト(task-oriented tangible media object)、その他にも数多く含まれる。
【００７９】
図１１は、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする。このシステムは、多数の実行中のプログラム（例えば、グラフィクスＡ〜Ｅ）および１つ又は複数のディスプレイ・デバイス（図示せず）を備えているシステムの一例に過ぎず、プログラムの一部または全部のグラフィック出力が、プラズマ構造(construct)（例えば、プール、プロテイン、およびスロー）を用いて、調整しながら他のプログラムにも利用可能とし、実行中のプログラムが、これらのデバイスによって発生したグラフィック・イベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。
【００８０】
コンピュータ・プログラムが、別のプログラムによって発生したグラフィクスを表示することが有用な場合は多い。広く知れ渡った様々な例には、テレビ会議アプリケーション、ネットワークを用いたスライドショーおよびデモ・プログラム、ならびにウィンドウ・マネージャが含まれる。この構成の下では、プールは、ビデオ、ネットワーク・アプリケーション共有、およびウィンドウ管理をカプセル化したフレームワークを一般化して実施するためにプラズマ・ライブラリとして用いられ、プログラマは、このようなプログラムの現バージョンでは一般には入手できない多数の特徴に追加することが可能になる。
【００８１】
プラズマ合成環境において走るプログラム（例えば、グラフィクスＡ〜Ｅ）は、プールへの結合および／または接続を通じて、調整プールに関与する。各プログラムは、種々の種類のグラフィック・ソースの可用性を示すために、そのプールにプロテインを貯入する。また、グラフィックスを表示するために利用可能なプログラムも、それらの表示処理能力、セキュリティおよびユーザ・プロファイル、ならびに物理的位置およびネットワーク位置を示すために、プロテインを貯入する。
【００８２】
また、グラフィクス・データをプールを通じて送信することもでき、あるいは表示プログラムに、他の種類（例えば、ＲＴＳＰストリーム）のネットワーク・リソースを指し示させることもできる。「グラフィクス・データ」という用語は、本明細書において用いる場合、広義の連続体(broad continuum)に沿って存在する種々の異なる表現のことを指し、グラフィクス・データの例には、文字で表現される例（例えば、「画像」、または画素のブロック）、手順的例（例えば、典型的なopenGLパイプラインを下って行くような一連の「描画」指令）、および記述的例（例えば、幾何学的変形、クリッピング、および合成動作によって他のグラフィック構造(construct)を組み合わせる命令）が含まれるが、これらに限定されるのではない。
【００８３】
ローカル・マシン上では、グラフィクス・データは、プラットフォーム特定の表示ドライバ最適化を通じて配信することもできる。プールを通してグラフィクスを送信しない場合でも、多くの場合、周期的な画面キャプチャは、調整プールに格納されるので、より内部(esoteric)のソースに直接アクセスできないクライアントであっても、万一のときのグラフィクス(fall-back graphics)を表示することもできる。
【００８４】
本明細書において記載するシステムの利点の１つは、殆どのメッセージ伝達フレームワークおよびネットワーク・プロトコルとは異なり、プールがデータの大量のバッファを維持することである。したがって、プログラムはプールの中に逆戻りして、アクセスおよび使用パターン（調整プールの場合）を見たり、以前のグラフィクス・フレーム（グラフィクス・プールの場合）を抽出することができる。
【００８５】
図１２は、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする。このシステムは、多数のデバイス（例えば、デバイスＡ、デバイスＢ等）上に多数の実行プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）を備えており、一部のプログラムがプールを用いてまたはプールを通じて他のプログラムの内部状態にアクセスするシステムの一例に過ぎない。
【００８６】
殆どの双方向処理コンピュータ・システムは、多くのプログラムを備えており、これらは、１台のマシンまたは多数のマシン上で互いに一緒に走り、ネットワークを跨いで双方向処理を行う。実行時データが各プロセス内部に隠されアクセスするのが困難なので、マルチ・プログラム・システムは、構成設定、分析、およびデバッグするのが難しい。本明細書において記載する一実施形態の一般化したフレームワークおよびプラズマ構造(construct)は、実行中のプログラムがプールを通じてそれらのデータの多くを利用可能にするので、他のプログラムがそれらの状態を検査することができる。このフレームワークによって、従来のデバッガよりも柔軟なデバッギング・ツール、精巧なシステム保守ツール、および１つまたは複数のプログラムが通過した一連の状態を、人の操作者に詳細に分析させるように構成された可視化ハーネスを可能にする。
【００８７】
図１２を参照すると、このフレームワークにおいて走るプログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）は、プログラムの起動時にプロセス・プールを発生または作成する。このプールは、システム・アルマナックに登録され、セキュリティおよびアクセス制御が適用される。更に特定すると、各デバイス（例えば、デバイスＡ、Ｂ等）が、それぞれのデバイス上で走るプログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が発生または出力した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールの中に貯入する。例えば、プログラムＰ−Ａは、データまたは出力を発生し、この出力をデバイスＡに供給する。一方、デバイスＡは、この生データをプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ、プロテイン３Ａ等）に変換し、これらのプロテインをプールの中に貯入する。別の例として、プログラムＰ−Ｂはデータを発生し、このデータをデバイスＢに供給する。一方、デバイスＢは、データをプロテイン（例えば、プロテイン１Ｂ〜４Ｂ等）に変換し、これらのプロテインをプールの中に貯入する。
【００８８】
プログラムの寿命の期間中、十分なアクセス許可を有する別のプログラムがプールに接続し(attach)、プログラムが貯入したプロテインを読み取ることもできる。これは、基本的な検査様式を表し、概念的に「一方向」即ち「読み取り専用」の提案(proposition)である。プログラムＰ−Ａに関与するエンティティが、そのプロセス・プールの中にＰ−Ａによって貯入されたステータス情報の流れを検査する。例えば、デバイスＣの下で走る検査プログラムまたはアプリケーションが１つ又は複数のプロテイン（例えば、プロテイン１Ａ、プロテイン２Ａ等）をプールから抽出することができる。プロテインの抽出に続いて、デバイスＣは、ディスクリップのスローおよびプロテインのインジェストから引き出した即ち読み出したプロテインのデータを用いて、プログラムＰ−Ａの内部状態にアクセスし、これを解釈し、検査することができる。
【００８９】
しかし、プラズマ・システムは単に効率的なステートフル(stateful)伝送方式であるだけでなく、全方向メッセージング環境であることを思い起こすと、様々な追加モードがプログラム対プログラムの状態検査をサポートする。許可された検査プログラムは、それ自体でプロテインをプログラムＰのプロセス・プールに貯入して、生成してそのプロセス・プールの中に入れた状態情報の特性に影響を及ぼし、これらの特性を制御することができる（結局、プログラムＰはプロセス・プールに書き込むだけでなく、そこから読み取りも行う）。
【００９０】
図１３は、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されている処理環境のブロック図であり、追加の代替実施形態の下において、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる。このシステム例では、デバイスＣの検査プログラムは、例えば、プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が、１回だけまたは特定の期間にわたって、通常よりも多い状態をプールにダンプすることを要求することができる。または、デバッグ通信の次の「レベル」を予示しておくと、関与するプログラムは、プログラム（例えば、プログラムＰ−Ａ、プログラムＰ−Ｂ等）が、デバッグ・プールを通じた双方向処理が個々に可能でありそのために利用可能な、その実行時間環境において残存するオブジェクトを一覧に纏めたプロテインを放出(emit)することを要求することができる。このように通知すると、関与するプログラムはプログラムの実行時においてオブジェクトの中の個々に「アドレス」し、特定のオブジェクトだけが専有し応答するプロセス・プールにプロテインを入れることができる。関与するプログラムは、例えば、オブジェクトが、その成分変数全ての瞬時値を記述した報告プロテインを放出することを要求することもあり得る。それよりも更に重要なのは、関与するプログラムが、他のプロテインを通じて、オブジェクトにその挙動またはその変数の値を変更するように指令できることである。
【００９１】
更に具体的には、この例では、デバイスＣの検査アプリケーションが、プールの中に、オブジェクト・リスト（例えば、「要求−オブジェクト・リスト」）の要求を（プロテインの形態で）入れて、次いでこのプールに結合されている各デバイス（例えば、デバイスＡ、デバイスＢ等）が抽出する。要求に応答して、各デバイス（例えば、デバイスＡ、デバイスＢ等）がプールの中に、その実行時環境において残存する、デバッグ・プールを通じて個々に検査することができそのために利用可能なオブジェクトを一覧に纏めたプロテイン（例えば、プロテイン１Ａ、プロテイン１Ｂ等）を入れる。
【００９２】
このようにデバイスからのリストを通じて通知され、オブジェクトのリストに応答して、デバイスＣの検査アプリケーションは、プログラム実行中におけるオブジェクトの中の個々にアドレスし、特定のオブジェクトのみが専有し応答するプロセス・プールにプロテインを入れる。デバイスＣの検査アプリケーションは、例えば、要求プロテイン（例えば、プロテイン「要求報告Ｐ−Ａ−Ｏ」、「要求報告Ｐ−Ｂ−Ｏ」）を、オブジェクト（例えば、それぞれ、オブジェクトＰ−Ａ−Ｏ、オブジェクトＰ−Ｂ−Ｏ）が、その成分変数の全ての瞬時値を記述する報告プロテイン（例えば、プロテイン２Ａ、プロテイン２Ｂ等）を放出するプールに入れる。各オブジェクト（例えば、オブジェクトＰ−Ａ−Ｏ、オブジェクトＰ−Ｂ−Ｏ）は、その要求（例えば、それぞれ、プロテイン「要求報告Ｐ−Ａ−Ｏ」、「要求報告Ｐ−Ｂ−Ｏ」）を抽出し、それに応答して、要求された報告（例えば、それぞれ、プロテイン２Ａ、プロテイン２Ｂ）を含むプールにプロテインを入れる。次いで、デバイスＣは種々の報告プロテイン（例えば、プロテイン２Ａ、プロテイン２Ｂ等）を抽出し、適宜報告の内容に合わせて続く処理行為を実行する。
【００９３】
このように、プラズマを相互交換媒体として用いると、デバッグ処理、プロセス制御、ならびにプログラム対プログラムの通信および調整の間にある区別を究極的に解消し易くなる。
【００９４】
このため、一般化したプラズマ・フレームワークは、疎結合の様式で可視化および分析プログラムを設計することを可能にする。例えば、メモリ・アクセス・パターンを表示する可視化ツールは、基本的なメモリ・リードおよびライトをプールに出力するいずれのプログラムとでも合わせて用いることができる。分析を受けるプログラムは、可視化ツールの存在や設計を知る必要がなく、その逆も成り立つ。
【００９５】
以上のようにプールを用いると、システム性能に不当に影響を及ぼすことはない。例えば、実施形態は、毎秒数十万個のプロテインをプールに貯入することを考慮しているので、比較的冗漫なデータ出力を可能にしても、殆どのプログラムの応答性や双方向処理特性を著しく阻害することはない。
【００９６】
以上に記載したシステムおよび方法の例には、ソース・デバイスのイベントを検出するステップと、イベントを指定するデバイス・イベント・データと、当該イベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップであって、デバイス・イベント・データおよび状態情報は、ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、ステップと、少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップであって、データ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション特定表現を備えているデータ構造を有する、ステップとを備えている、方法が含まれる。
【００９７】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別デバイス・イベント・データを含む第１個別データ集合を発生するステップと、第２個別状態情報を含む第２個別データ集合を発生するステップと、第１個別データ集合および第２個別データ集合を含むように第１データ・シーケンスを形成するステップとを備えている。
【００９８】
一実施形態の第１個別データ集合を発生するステップは、ソース・デバイスの識別データを含むように第１個別データ集合を形成するステップを含み、識別データは、ソース・デバイスを識別するデータを含む。
【００９９】
一実施形態の少なくとも１つのデータ・シーケンスを発生するステップは、第１個別デバイス・イベント・データを含む第１個別データ集合を発生するステップと、第２個別状態情報を含む第２個別データ集合を発生するステップと、第１個別データ集合および第２個別データ集合を含むように、第２データ・シーケンスを形成するステップとを備えている。
【０１００】
一実施形態の第１個別データ集合を発生するステップは、第１個別データ集合オフセットを発生するステップを含み、第１個別データ集合オフセットは、第２データ・シーケンスの第１個別データ集合を指し示す。
【０１０１】
一実施形態の第２個別データ集合を発生するステップは、第２個別データ集合オフセットを発生するステップを含み、第２個別データ集合オフセットは、第２データ・シーケンスの第２個別データ集合を指し示す。
【０１０２】
一実施形態の第１個別データ集合は、記述リストであり、この記述リストはデータの記述を含む。
一実施形態のデバイス・イベント・データは、類別したデータを表す、タグ付きのバイト・シーケンスである。
【０１０３】
一実施形態のデバイス・イベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別したデータを表す、タグ付きのバイト・シーケンスである。
【０１０４】
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態では、前述の方法は、少なくとも１つのオフセットを発生するステップと、少なくとも１つのオフセットを含むように、データ・カプセルを形成するステップとを備えている。
【０１０５】
一実施形態では、前述の方法は、第１変数長を有する第１オフセットを発生するステップを備えており、第１オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのデバイス・イベント・データを指し示す。
【０１０６】
一実施形態では、前述の方法は、第２可変長を有する第２オフセットを発生するステップを備えており、第２オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す。
【０１０７】
一実施形態では、前述の方法は、少なくとも１つのオフセットの第１オフセットを用いて、データ・カプセルを通る第１コード・パスを形成するステップと、少なくとも１つのオフセットの第２オフセットを用いて、データ・カプセルを通る第２コード・パスを形成するステップとを備えており、第１コード・パスおよび第２コード・パスは異なるパスである。
【０１０８】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータを含み、このメタデータは、アプリケーションのコンテキストに対応する、コンテキスト特定メタデータを備えている。
【０１０９】
一実施形態では、前述の方法は、データ・カプセルの長さを含むヘッダを発生するステップと、ヘッダを含むようにデータ・カプセルを形成するステップとを備えている。
一実施形態では、前述の方法は、データ・カプセルをレポジトリに転送するステップを備えている。
【０１１０】
一実施形態では、前述の方法は、第２ソース・デバイスの第２イベントを検出するステップと、第２イベントに対応するデータ・カプセルを求めて、レポジトリを検索するステップとを備えている。
【０１１１】
一実施形態では、前述の方法は、データ・カプセルと第２イベントとの間にある対応を特定するステップと、特定に応答して、レポジトリからデータ・カプセルを抽出するステップと、データ・カプセルの内容に応答して、第２ソース・デバイスの代わりに第２イベントに対応する処理動作を、第２ソース・デバイスの代わりに実行するステップであって、ソース・デバイスは第１タイプのアプリケーションに対応し、第２ソース・デバイスは第２タイプの第アプリケーションに対応する、ステップとを備えている。
【０１１２】
一実施形態のレポジトリは、複数のアプリケーションに結合されており、レポジトリは、複数のアプリケーションに対応する複数のデータ・カプセルを含み、レポジトリは、複数のアプリケーションによる複数のデータ・カプセルへのアクセスを与え、複数のアプリケーションの内少なくとも２つが異なるアプリケーションである。
【０１１３】
一実施形態のレポジトリは、複数のデータ・カプセルの状態をキャッシュする処理に備える。
一実施形態のレポジトリは、複数のデータ・カプセルを線形に整列する処理に備える。
【０１１４】
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、デバイス・イベント・データおよび状態情報のプラットフォーム独立表現を規定する。
【０１１５】
一実施形態のデータ・カプセルのデータ構造は、デバイスイベント・データおよび状態情報へのプラットフォーム独立アクセスを与える。
一実施形態では、前述の方法は、データ・カプセルを、第１アプリケーション・タイプを有する第１アプリケーションから、少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションに転送するステップを備えており、第１アプリケーション・タイプは第２アプリケーション・タイプとは異なり、少なくとも１つのデータ・シーケンスを発生するステップを、第１アプリケーションによって実行するステップと、転送の間、データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するステップとを備えている。
【０１１６】
一実施形態では、前述の方法は、第２アプリケーションの動作中、少なくとも１つのデータ・シーケンスを用いるステップを備えている。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。
【０１１７】
一実施形態のイベントは、グラフィクス・イベントを備えている。
一実施形態のイベントは、状態情報の貯入を備えている。
前述のシステムおよび方法の例は、デバイス・イベント・データとソース・デバイスの識別データとを含む第１データ集合を発生するステップであって、デバイス・イベント・データは、ソース・デバイスが登録したイベントを指定するデータを含み、識別データは、ソース・デバイスを識別するデータを含む、ステップと、イベントの状態情報集合全体を含む第２データ集合を発生するステップと、第１データ集合および第２データ集合の各々は、タイプ特定データ・レイアウトとした類型データ・バンドルを備えており、第１データ集合および第２データ集合を含むようにデータ・カプセルを形成することにより、第１データ集合および第２データ集合をカプセル化するステップであって、データ・カプセルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する、ステップとを備えている、方法を含む。
【０１１８】
前述のシステムおよび方法の例は、第１タイプのアプリケーションの下で走るデバイスのイベントを検出するステップと、イベントを指定するデバイス・イベント・データと、イベントの状態情報とを備えているデータ・シーケンスを発生するステップであって、デバイス・イベント・データおよび状態情報が、アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、データ・カプセルが、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する、ステップと、少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で走る少なくとも１つの第２ソース・デバイスの第２イベントを検出するステップであって、第２タイプが第１タイプとは異なる、ステップと、データ・カプセルと第２イベントとの間にある対応を特定するステップと、第２イベントに応答して、データ・カプセルのデータ・シーケンスの内容を用いて、動作を実行するステップとを備えている、方法を含む。
【０１１９】
一実施形態のデータ・シーケンスを発生するステップは、デバイス・イベント・データを含む第１データ集合を発生するステップと、状態情報を含む第２データ集合を発生するステップと、第１データ集合および第２データ集合を含むように、第１データ・シーケンスを形成するステップとを備えている。
【０１２０】
一実施形態のデバイス・イベント・データは、類別したデータを表す、タグ付きのバイト・シーケンスである。
一実施形態のデバイス・イベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０１２１】
一実施形態の状態情報は、類別したデータを表す、タグ付きのバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
【０１２２】
一実施形態では、前述の方法は、少なくとも１つのオフセットを発生するステップと、少なくとも１つのオフセットを含むように、データ・カプセルを形成するステップとを備えている。
【０１２３】
一実施形態では、前述の方法は、第１変数長を有する第１オフセットを発生するステップであって、第１オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスのデバイス・イベント・データを指し示す、ステップと、第２可変長を有する第２オフセットを発生するステップであって、第２オフセットは、少なくとも１つのデータ・シーケンスの第１データ・シーケンスの状態情報を指し示す、ステップとを備えている。
【０１２４】
一実施形態では、前述の方法は、少なくとも１つのオフセットの第１オフセットを用いて、データ・カプセルを通る第１コード・パスを形成するステップと、少なくとも１つのオフセットの第２オフセットを用いて、データ・カプセルを通る第２コード・パスを形成するステップとを備えており、第１コード・パスおよび第２コード・パスは異なるパスである。
【０１２５】
一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータを含み、このメタデータは、アプリケーションのコンテキストに対応する、コンテキスト特定メタデータを備えている。
【０１２６】
一実施形態では、前述の方法は、データ・カプセルをレポジトリに転送するステップを備えている。
一実施形態では、前述の方法は、第２イベントに対応するデータ・カプセルを求めて、レポジトリを検索するステップと、対応の特定に応答して、レポジトリからデータ・カプセルを抽出するステップとを備えている。
【０１２７】
一実施形態のレポジトリは、アプリケーションおよび少なくとも１つの第２アプリケーションに結合されており、レポジトリは、アプリケーションおよび少なくとも１つの第２アプリケーションに対応する複数のデータ・カプセルを含み、レポジトリは、アプリケーションおよび少なくとも１つの第２アプリケーションによる複数のデータ・カプセルへのアクセスを与える。
【０１２８】
一実施形態のレポジトリは、複数のデータ・カプセルの状態をキャッシュする処理に備える。
一実施形態のレポジトリは、複数のデータ・カプセルを線形に整列する処理に備える。
【０１２９】
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、デバイス・イベント・データおよび状態情報のプラットフォーム独立表現を規定する。
【０１３０】
一実施形態のデータ・カプセルのデータ構造は、デバイスイベント・データおよび状態情報へのプラットフォーム独立アクセスを与える、方法。
前述のシステムおよび方法の例は、第１タイプのアプリケーションの下で走る第１ソース・デバイスのイベントを検出するステップと、イベントを指定するデバイス・イベント・データと、イベントの状態情報とを備えているデータ・シーケンスを発生するステップであって、デバイス・イベント・データおよび状態情報は、アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、データ・カプセルが、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する、ステップと、データ・カプセルをレポジトリに入れるステップと、少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で走る少なくとも１つの第２ソース・デバイスの第２イベントを検出するステップと、レポジトリを検索し、データ・カプセルと第２イベントとの間にある対応を特定するステップと、データ・カプセルのデータ・シーケンスの内容を用いて、第２イベントに対応する動作を、第２ソース・デバイスの代わりに実行するステップとを備えている、方法を含む。
【０１３１】
本明細書において記載したシステムおよび方法は、スロークス、プロテイン、および方法の使用を通じてデータをカプセル化し、カプセル化したデータを転送および使用するシステムおよび方法を含み、処理システムを含み、および／または処理システムの下でおよび／または処理システムと連携して実行する。処理システムは、当技術分野では周知のように、互いに動作するプロセッサ主体デバイスまたは計算デバイスのあらゆる集合体、あるいは処理システムまたはデバイスのコンポーネントを含む。例えば、処理システムは、携帯用コンピュータ、通信ネットワークにおいて動作する携帯用通信デバイス、および／またはネットワーク・サーバの１つ又は複数を含むことができる。携帯用コンピュータは、パーソナル・コンピュータ、セルラ電話機、パーソナル・ディジタル・アシスタント、携帯用計算デバイス、および携帯用通信デバイスの中から選択した多数のデバイスおよび／またはデバイスの組み合わせのいずれとすることもできるが、そのように限定されるのではない。処理システムは、それよりも大きなコンピュータ・システムの中にあるコンポーネントを含むことができる。
【０１３２】
一実施形態の処理システムは、少なくとも１つのプロセッサと、少なくとも１つのメモリ・デバイスまたはサブシステムとを含む。また、処理システムは、少なくとも１つのデータベースを含むか、またはこれに結合することができる。「プロセッサ」という用語は、本明細書において一般に用いる場合、１つ又は複数の中央演算装置（ＣＰＵ）、ディジタル信号プロセッサ（ＤＳＰ）、特定用途集積回路（ＡＳＩＣ）等のような、あらゆる論理演算装置を指す。プロセッサおよびメモリは、１つのチップ上にモノリシックに集積することができ、多数のチップまたはホスト・コンピュータのコンポーネント間で分散することができ、および／またはアルゴリズムの何らかの組み合わせによって提供することができる。本明細書において記載した方法は、ソフトウェア・アルゴリズム（群）、プログラム、ファームウェア、ハードウェア、コンポーネント、回路の１つ又は複数で、いずれの組み合わせでも実現することができる。
【０１３３】
本明細書において記載したシステムおよび方法を具現化するシステム・コンポーネントは、一緒に配置すること、または別個の位置に配置することができる。したがって、本明細書において記載したシステムおよび方法を具現化するシステム・コンポーネントは、単一のシステム、多数のシステム、および／または地理的に離れたシステムのコンポーネントとすることができる。また、これらのコンポーネントは、単一のシステム、多数のシステム、および／または地理的に離れたサブシステムのサブコンポーネントまたはサブシステムとすることもできる。これらのコンポーネントは、ホストシステムの１つ又は複数のその他のコンポーネント、またはホスト・システムに結合されているシステムに結合することができる。
【０１３４】
通信経路は、システム・コンポーネントを結合し、コンポーネント間においてファイルを伝達または転送する媒体であればいずれでも含む。通信経路は、無線接続、有線接続、混成無線／有線接続を含む。また、通信経路は、ローカル・エリア・ネットワーク（ＬＡＮ）、都市エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、企業固有ネットワーク、事務所間またはバックエンド・ネットワーク、およびインターネットを含むネットワークへの結合または接続も含む。更に、通信経路は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクのような、リムーバブル固定媒体、ならびにフラッシュＲＡＭ、ユニバーサル・シリアル・バス（ＵＳＢ）接続、ＲＳ−２３２接続、電話回線、バス、および電子メール・メッセージを含む。
【０１３５】
文脈が特に明確に要求しない限り、説明全体を通じて、「備える」(comprise)、「備えている」(comprising)等の単語は、排他的または網羅的な意味とは逆に、包含的意味で解釈することとする。即ち、「含むがそれに限定されない」という意味である。また、単数または複数を用いる単語は、それぞれ、複数または単数も含むこととする。加えて、「ここでは」、「以下では」、「以上」、「以下」および同様の趣旨の単語は、本願のいずれかの特定部分ではなく、本願全体を指すこととする。「または」という単語が２つ以上の項目のリストに関して用いられる場合、その単語は以下の単語の解釈全てに及ぶこととする。リストにおける項目のいずれか、リストにおける項目全て、およびリストにおける項目のあらゆる組み合わせ。
【０１３６】
以上におけるプログラミング環境の実施形態の説明は、網羅的であることも、記載したシステムおよび方法を、開示した形態そのものに限定することも意図していない。プログラミング環境の具体的な実施形態およびその例は、本明細書では例示の目的で記載したが、その他のシステムおよび方法の範囲内において、種々の同等な修正も可能であることは、当業者であれば認められよう。本明細書において提案したプログラミング環境の教示は、前述のシステムおよび方法だけでなく、他の処理システムおよび方法にも適用することができる。
【０１３７】
以上で説明した種々の実施形態の要素および行為(act)を組み合わせて、更に別の実施形態を提案することができる。これらおよびその他の変更は、以上に詳細に記載した説明を参照すれば、プログラミング環境に対して行うことができる。
【図１】
0005905662.tif 000004
【図２】
0005905662.tif 000005
【図３】
0005905662.tif 000006
【図４】
0005905662.tif 000007
【図５】
0005905662.tif 000008
【図６Ａ】
0005905662.tif 000009
【図６Ｂ】
0005905662.tif 000010
【図６Ｃ】
0005905662.tif 000011
【図６Ｄ】
0005905662.tif 000012
【図７】
0005905662.tif 000013
【図８】
0005905662.tif 000014
【図９】
0005905662.tif 000015
【図１０】
0005905662.tif 000016
【図１１】
0005905662.tif 000017
【図１２】
0005905662.tif 000018
【図１３】
0005905662.tif 000019