JP2014222506A - プロテイン、プール、およびスロークス処理環境 - Google Patents

Abstract

【課題】プロセス間でまたはプロセスを跨って共有する必要があるデータをカプセル化するメカニズムを提供する。
【解決手段】メカニズムはスロー、プロテイン、およびプールを含む。スローは、プロセス間交換について最低レベルのデータ定義を規定し、プロテインは、中間レベルの構造を規定し、問い合わせおよびフィルタリングのためのフックを備え、プールは高レベルの編成およびアクセス・セマンティクスを規定する。スローは、効率的なプラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、スローをペイロードとして用いる、データ・カプセル化および輸送方式を規定する。プールは、１つのプロセス内部、ローカル・プロセス間、遠隔プロセスまたは分散プロセス間にあるネットワークを跨いだ、そして長期記憶による、プロテインの構造化され柔軟な集計、順序付け、フィルタ処理、および分散を規定する。
【選択図】図１

Description

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

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

技術分野
実施形態は、計算プロセス内および計算プロセス間におけるデータの表現、操作、およ
び交換に関して説明する。

従来のプログラミング環境は、マルチ・コンピュータ演算装置（ＣＰＵ）やクロス・ネ
ットワーク実行、あるいは多数の計算プロセス間におけるデータの柔軟な共有を最大限支
援していない。

例えば、従来のユーザ対面(user-facing)計算プラットフォーム（例えば、OS X、Micro
soft Windows（登録商標）、UNIX（登録商標）上のX Windows（登録商標））は、プロセ
ス間においてイベント・データを伝送する設備(facilities)を提供する。しかし、これら
既存のメカニズムの全てには欠点があり、そのためにマルチ・プロセスおよびマルチ・マ
シン・アプリケーションを構築することが困難となっており、更に複数のプログラミング
言語で作業するユーザは、苛立たしい輪を潜り抜けることを余儀なくされている。例えば
、従来のイベント・フレームワークは厳しく類型に分けられており、そのためにこれらは
柔軟性を欠き、アプリケーション・プログラマに対するシステム販売業者の専有(assumpt
ion)が特権として認められており、増々普及しつつある動的言語（例えば、Ruby、Python
、およびPerl）の設備との不一致が形成される。また、従来のフレームワークは、２点間
データ転送しかサポートしないように構成されており、数個を超える別個のプロセスの活
動(activity)を調整することが困難または不可能となる。また、従来のフレームワークは
、特定のローカル・メモリ内データ構造に強く依存するので、ディスク上の格納またはネ
ットワークを跨る送信には不向きとなっている。

引用による包含
本明細書において述べる各特許、特許出願、および／または刊行物は、本願において引
用することにより、個々の特許、特許出願、および／または刊行物の各々が具体的にそし
て個々に、引用することにより本願に含まれることを示した場合と同程度にその全体が本
願にも含まれるものとする。

本明細書では、大規模マルチ・プロセス相互動作を可能としかつ促進する新規のプログ
ラミングまたは処理環境を含む実施形態を教示する。本明細書において提供する実施形態
は、マルチ・コンピュータ演算装置（ＣＰＵ）およびクロス・ネットワーク実行や、多数
の計算処理間における柔軟なデータ共有を最大限支援しない従来のプログラミング環境に
おける問題を克服する。

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

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

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

以下の用語は、本明細書において用いられる場合、以下の一般的な意味を有することを
意図している。「プロセス」という用語は、本明細書において用いられる場合、ある時間
期間実行するコンピュータ・プログラムを意味する。この実行は、休止あるいはプロセッ
サまたはマシン間の転送によって中断される場合もあるので、プロセスを無期限に保留す
ること、「直列化」すること、あるいはディスクに、メモリ・バス間で、またはネットワ
ーク上で「整列」(marshal)させることも可能である。前述の意味は、当業者によって理
解される別の意味を含むこともできる。

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

図１は、一実施形態の下における、スロークス、プロテイン、およびプールを用いたデータ表現を含む処理環境のブロック図である。 図２は、一実施形態の下における、プロテインのブロック図である。 図３は、一実施形態の下における、デスクリップ(descrip)のブロック図である。 図４は、一実施形態の下における、インジェスト(ingest)のブロック図である。 図５は、一実施形態の下におけるスロー(slaw)のブロック図である。 図６Ａは、一実施形態の下における、プールの中にあるプロテインのブロック図である。 図６Ｂは、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。 図６Ｃは、一実施形態の下においてプロテインを用いる際の流れ図である。 図６Ｄは、一実施形態の下において、プロテインを組み立てるまたは発生する際の流れ図である。 図７は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。 図８は、一実施形態の下において、多数のデバイスと、これらのデバイスの１つ又は複数で走る多数のプログラムを含み、プラズマ構造(plasma construct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。 図９は、一代替実施形態の下において、多数のデバイスと、これらのデバイスの１つ又は複数で走る多数のプログラムを含み、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。 図１０は、別の代替実施形態の下において、多数の入力デバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。 図１１は、更に別の代替実施形態の下において、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする処理環境のブロック図である。 図１２は、更に別の代替実施形態の下において、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする処理環境のブロック図である。 図１３は、追加の代替実施形態の下において、多数のデバイスを含み、これらが当該デバイスの１つ又は複数で走る多数のプログラム間に結合されており、プラズマ構造（例えば、プール、プロテイン、およびスロー）を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる処理環境のブロック図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一実施形態では、各スローの最初の４バイトは、ヘッダ構造(structure)を備えている
。ヘッダ構造(structure)は、タイプ記述およびその他のメタ情報をエンコードし、特定
的なタイプの意味を特定のビット・パターンに帰属させる(ascribe)。例えば、スロー・
ヘッダの最初の（最上位）ビットは、そのスローのサイズ（クアッド・ワード単位の長さ
）が最初の４バイトのタイプ・ヘッダに従うか否か指定するために用いることができる。
このビットがセットされている場合、スローのサイズが当該スローの次の４バイト（例え
ば、バイト５から８まで）に明示的に記録されていることが分かる。スローのサイズが、
４バイトでは表現できないような場合（即ち、サイズが２の３２乗以上である場合）、ス
ローの最初の４バイトの次の最上位ビットもセットする。これは、スローが８バイト（４
バイトではなく）長を有することを意味する。その場合、検査プロセスが、序数バイト(o
rdinal 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 co
nstruct)（例えば、プール、プロテイン、およびスロー）を用いることにより、多数の実
行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答するこ
とを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピ
ュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、
多数のデバイス（例えば、デバイスＡ、Ｂ等）およびこれらのデバイス上で走る多数のプ
ログラム（例えば、appsAA-AX、appsBA-ＢＸ等）を備えている双方向処理システムが、プ
ラズマ構造(construct)（例えば、プール、プロテイン、およびスロー）を用いて、実行
中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的に
これらのイベントに応答することを可能にする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上に記載したシステムおよび方法の例には、ソース・デバイスのイベントを検出する
ステップと、イベントを指定するデバイス・イベント・データと、当該イベントの状態情
報とを備えている少なくとも１つのデータ・シーケンスを発生するステップであって、デ
バイス・イベント・データおよび状態情報は、ソース・デバイスのアプリケーションに対
応するタイプを有するタイプ特定データである、ステップと、少なくとも１つのデータ・
シーケンスを含むようにデータ・カプセルを形成するステップであって、データ・カプセ
ルが、少なくとも１つのデータ・シーケンスのアプリケーション特定表現を備えているデ
ータ構造を有する、ステップとを備えている、方法が含まれる。

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

一実施形態の第１個別データ集合を発生するステップは、ソース・デバイスの識別デー
タを含むように第１個別データ集合を形成するステップを含み、識別データは、ソース・
デバイスを識別するデータを含む。

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

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

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

一実施形態の第１個別データ集合は、記述リストであり、この記述リストはデータの記
述を含む。
一実施形態のデバイス・イベント・データは、類別したデータを表す、タグ付きのバイ
ト・シーケンスである。

一実施形態のデバイス・イベント・データは、タイプ・ヘッダと、タイプ特定データ・
レイアウトとを含む。
一実施形態の状態情報は、類別したデータを表す、タグ付きのバイト・シーケンスであ
る。

一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む
。
一実施形態では、前述の方法は、少なくとも１つのオフセットを発生するステップと、
少なくとも１つのオフセットを含むように、データ・カプセルを形成するステップとを備
えている。

一実施形態では、前述の方法は、第１変数長を有する第１オフセットを発生するステッ
プを備えており、第１オフセットは、少なくとも１つのデータ・シーケンスの第１データ
・シーケンスのデバイス・イベント・データを指し示す。

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

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

一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータ
を含み、このメタデータは、アプリケーションのコンテキストに対応する、コンテキスト
特定メタデータを備えている。

一実施形態では、前述の方法は、データ・カプセルの長さを含むヘッダを発生するステ
ップと、ヘッダを含むようにデータ・カプセルを形成するステップとを備えている。
一実施形態では、前述の方法は、データ・カプセルをレポジトリに転送するステップを
備えている。

一実施形態では、前述の方法は、第２ソース・デバイスの第２イベントを検出するステ
ップと、第２イベントに対応するデータ・カプセルを求めて、レポジトリを検索するステ
ップとを備えている。

一実施形態では、前述の方法は、データ・カプセルと第２イベントとの間にある対応を
特定するステップと、特定に応答して、レポジトリからデータ・カプセルを抽出するステ
ップと、データ・カプセルの内容に応答して、第２ソース・デバイスの代わりに第２イベ
ントに対応する処理動作を、第２ソース・デバイスの代わりに実行するステップであって
、ソース・デバイスは第１タイプのアプリケーションに対応し、第２ソース・デバイスは
第２タイプの第アプリケーションに対応する、ステップとを備えている。

一実施形態のレポジトリは、複数のアプリケーションに結合されており、レポジトリは
、複数のアプリケーションに対応する複数のデータ・カプセルを含み、レポジトリは、複
数のアプリケーションによる複数のデータ・カプセルへのアクセスを与え、複数のアプリ
ケーションの内少なくとも２つが異なるアプリケーションである。

一実施形態のレポジトリは、複数のデータ・カプセルの状態をキャッシュする処理に備
える。
一実施形態のレポジトリは、複数のデータ・カプセルを線形に整列する処理に備える。

一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、デバイス・イベント・データおよび状
態情報のプラットフォーム独立表現を規定する。

一実施形態のデータ・カプセルのデータ構造は、デバイスイベント・データおよび状態
情報へのプラットフォーム独立アクセスを与える。
一実施形態では、前述の方法は、データ・カプセルを、第１アプリケーション・タイプ
を有する第１アプリケーションから、少なくとも１つの第２アプリケーション・タイプを
有する少なくとも１つの第２アプリケーションに転送するステップを備えており、第１ア
プリケーション・タイプは第２アプリケーション・タイプとは異なり、少なくとも１つの
データ・シーケンスを発生するステップを、第１アプリケーションによって実行するステ
ップと、転送の間、データ・カプセルの少なくとも１つのデータ・シーケンスを不変のま
ま維持するステップとを備えている。

一実施形態では、前述の方法は、第２アプリケーションの動作中、少なくとも１つのデ
ータ・シーケンスを用いるステップを備えている。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。

一実施形態のイベントは、グラフィクス・イベントを備えている。
一実施形態のイベントは、状態情報の貯入を備えている。
前述のシステムおよび方法の例は、デバイス・イベント・データとソース・デバイスの
識別データとを含む第１データ集合を発生するステップであって、デバイス・イベント・
データは、ソース・デバイスが登録したイベントを指定するデータを含み、識別データは
、ソース・デバイスを識別するデータを含む、ステップと、イベントの状態情報集合全体
を含む第２データ集合を発生するステップと、第１データ集合および第２データ集合の各
々は、タイプ特定データ・レイアウトとした類型データ・バンドルを備えており、第１デ
ータ集合および第２データ集合を含むようにデータ・カプセルを形成することにより、第
１データ集合および第２データ集合をカプセル化するステップであって、データ・カプセ
ルが、少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデ
ータ構造を有する、ステップとを備えている、方法を含む。

前述のシステムおよび方法の例は、第１タイプのアプリケーションの下で走るデバイス
のイベントを検出するステップと、イベントを指定するデバイス・イベント・データと、
イベントの状態情報とを備えているデータ・シーケンスを発生するステップであって、デ
バイス・イベント・データおよび状態情報が、アプリケーションに対応するタイプを有す
るタイプ特定データである、ステップと、データ・シーケンスを含むようにデータ・カプ
セルを形成するステップであって、データ・カプセルが、データ・シーケンスのアプリケ
ーション独立表現を備えているデータ構造を有する、ステップと、少なくとも１つの第２
タイプを有する少なくとも１つの第２アプリケーションの下で走る少なくとも１つの第２
ソース・デバイスの第２イベントを検出するステップであって、第２タイプが第１タイプ
とは異なる、ステップと、データ・カプセルと第２イベントとの間にある対応を特定する
ステップと、第２イベントに応答して、データ・カプセルのデータ・シーケンスの内容を
用いて、動作を実行するステップとを備えている、方法を含む。

一実施形態のデータ・シーケンスを発生するステップは、デバイス・イベント・データ
を含む第１データ集合を発生するステップと、状態情報を含む第２データ集合を発生する
ステップと、第１データ集合および第２データ集合を含むように、第１データ・シーケン
スを形成するステップとを備えている。

一実施形態のデバイス・イベント・データは、類別したデータを表す、タグ付きのバイ
ト・シーケンスである。
一実施形態のデバイス・イベント・データは、タイプ・ヘッダと、タイプ特定データ・
レイアウトとを含む。

一実施形態の状態情報は、類別したデータを表す、タグ付きのバイト・シーケンスであ
る。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む
。

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

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

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

一実施形態の第１オフセットおよび第２オフセットの内少なくとも１つは、メタデータ
を含み、このメタデータは、アプリケーションのコンテキストに対応する、コンテキスト
特定メタデータを備えている。

一実施形態では、前述の方法は、データ・カプセルをレポジトリに転送するステップを
備えている。
一実施形態では、前述の方法は、第２イベントに対応するデータ・カプセルを求めて、
レポジトリを検索するステップと、対応の特定に応答して、レポジトリからデータ・カプ
セルを抽出するステップとを備えている。

一実施形態のレポジトリは、アプリケーションおよび少なくとも１つの第２アプリケー
ションに結合されており、レポジトリは、アプリケーションおよび少なくとも１つの第２
アプリケーションに対応する複数のデータ・カプセルを含み、レポジトリは、アプリケー
ションおよび少なくとも１つの第２アプリケーションによる複数のデータ・カプセルへの
アクセスを与える。

一実施形態のレポジトリは、複数のデータ・カプセルの状態をキャッシュする処理に備
える。
一実施形態のレポジトリは、複数のデータ・カプセルを線形に整列する処理に備える。

一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、デバイス・イベント・データおよび状
態情報のプラットフォーム独立表現を規定する。

一実施形態のデータ・カプセルのデータ構造は、デバイスイベント・データおよび状態
情報へのプラットフォーム独立アクセスを与える、方法。
前述のシステムおよび方法の例は、第１タイプのアプリケーションの下で走る第１ソー
ス・デバイスのイベントを検出するステップと、イベントを指定するデバイス・イベント
・データと、イベントの状態情報とを備えているデータ・シーケンスを発生するステップ
であって、デバイス・イベント・データおよび状態情報は、アプリケーションに対応する
タイプを有するタイプ特定データである、ステップと、データ・シーケンスを含むように
データ・カプセルを形成するステップであって、データ・カプセルが、データ・シーケン
スのアプリケーション独立表現を備えているデータ構造を有する、ステップと、データ・
カプセルをレポジトリに入れるステップと、少なくとも１つの第２タイプを有する少なく
とも１つの第２アプリケーションの下で走る少なくとも１つの第２ソース・デバイスの第
２イベントを検出するステップと、レポジトリを検索し、データ・カプセルと第２イベン
トとの間にある対応を特定するステップと、データ・カプセルのデータ・シーケンスの内
容を用いて、第２イベントに対応する動作を、第２ソース・デバイスの代わりに実行する
ステップとを備えている、方法を含む。

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

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

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

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

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

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

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

Claims (51)

1. ソース・デバイスのイベントを検出するステップと、
   前記イベントを指定するデバイス・イベント・データと、当該イベントの状態情報とを
   備えている少なくとも１つのデータ・シーケンスを発生するステップであって、前記デバ
   イス・イベント・データおよび状態情報は、前記ソース・デバイスのアプリケーションに
   対応するタイプを有するタイプ特定データである、ステップと、
   前記少なくとも１つのデータ・シーケンスを含むようにデータ・カプセルを形成するス
   テップであって、該データ・カプセルが、前記少なくとも１つのデータ・シーケンスのア
   プリケーション特定表現を備えているデータ構造を有する、ステップと、
   を備えている、方法。
2. 請求項１記載の方法において、前記少なくとも１つのデータ・シーケンスを発生するス
   テップは、
   第１個別デバイス・イベント・データを含む第１個別データ集合を発生するステップと
   、
   第２個別状態情報を含む第２個別データ集合を発生するステップと、
   前記第１個別データ集合および前記第２個別データ集合を含むように第１データ・シー
   ケンスを形成するステップと、
   を備えている、方法。
3. 請求項２記載の方法において、前記第１個別データ集合を発生するステップは、前記ソ
   ース・デバイスの識別データを含むように前記第１個別データ集合を形成するステップを
   含み、前記識別データは、前記ソース・デバイスを識別するデータを含む、方法。
4. 請求項２記載の方法において、前記少なくとも１つのデータ・シーケンスを発生するス
   テップは、
   第１個別デバイス・イベント・データを含む第１個別データ集合を発生するステップと
   、
   第２個別状態情報を含む第２個別データ集合を発生するステップと、
   前記第１個別データ集合および前記第２個別データ集合を含むように、第２データ・シ
   ーケンスを形成するステップと、
   を備えている、方法。
5. 請求項４記載の方法において、前記第１個別データ集合を発生するステップは、第１個
   別データ集合オフセットを発生するステップを含み、前記第１個別データ集合オフセット
   は、前記第２データ・シーケンスの第１個別データ集合を指し示す、方法。
6. 請求項４記載の方法において、前記第２個別データ集合を発生するステップは、第２個
   別データ集合オフセットを発生するステップを含み、前記第２個別データ集合オフセット
   は、前記第２データ・シーケンスの第２個別データ集合を指し示す、方法。
7. 請求項２記載の方法において、前記第１個別データ集合は、記述リストであり、該記述
   リストは前記データの記述を含む、方法。
8. 請求項１記載の方法において、前記デバイス・イベント・データは、類別したデータを
   表す、タグ付きのバイト・シーケンスである、方法。
9. 請求項８記載の方法において、前記デバイス・イベント・データは、タイプ・ヘッダと
   、タイプ特定データ・レイアウトとを含む、方法。
10. 請求項１記載の方法において、前記状態情報は、類別したデータを表す、タグ付きのバ
    イト・シーケンスである、方法。
11. 請求項１０記載の方法において、前記状態情報は、タイプ・ヘッダと、タイプ特定デー
    タ・レイアウトとを含む、方法。
12. 請求項１記載の方法であって、
    少なくとも１つのオフセットを発生するステップと、
    前記少なくとも１つのオフセットを含むように、前記データ・カプセルを形成するステ
    ップと、
    を備えている、方法。
13. 請求項１２記載の方法であって、
    第１変数長を有する第１オフセットを発生するステップを備えており、
    前記第１オフセットは、前記少なくとも１つのデータ・シーケンスの第１データ・シー
    ケンスの前記デバイス・イベント・データを指し示す、方法。
14. 請求項１２記載の方法であって、
    第２可変長を有する第２オフセットを発生するステップを備えており、
    前記第２オフセットは、前記少なくとも１つのデータ・シーケンスの第１データ・シー
    ケンスの前記状態情報を指し示す、方法。
15. 請求項１２記載の方法であって、
    前記少なくとも１つのオフセットの第１オフセットを用いて、前記データ・カプセルを
    通る第１コード・パスを形成するステップと、
    前記少なくとも１つのオフセットの第２オフセットを用いて、前記データ・カプセルを
    通る第２コード・パスを形成するステップと、
    を備えており、前記第１コード・パスおよび前記第２コード・パスは異なるパスである、
    方法。
16. 請求項１２記載の方法において、前記第１オフセットおよび前記第２オフセットの内少
    なくとも１つは、メタデータを含み、該メタデータは、前記アプリケーションのコンテキ
    ストに対応する、コンテキスト特定メタデータを備えている、方法。
17. 請求項１記載の方法であって、
    前記データ・カプセルの長さを含むヘッダを発生するステップと、
    前記ヘッダを含むように前記データ・カプセルを形成するステップと、
    を備えている、方法。
18. 請求項１記載の方法であって、前記データ・カプセルをレポジトリに転送するステップ
    を備えている、方法。
19. 請求項１８記載の方法であって、
    第２ソース・デバイスの第２イベントを検出するステップと、
    前記第２イベントに対応するデータ・カプセルを求めて、前記レポジトリを検索するス
    テップと、
    を備えている、方法。
20. 請求項１９記載の方法であって、
    前記データ・カプセルと前記第２イベントとの間にある対応を特定するステップと、
    前記特定に応答して、前記レポジトリから前記データ・カプセルを抽出するステップと
    、
    前記データ・カプセルの内容に応答して、前記第２ソース・デバイスの代わりに前記第
    ２イベントに対応する処理動作を、前記第２ソース・デバイスの代わりに実行するステッ
    プであって、前記ソース・デバイスは第１タイプのアプリケーションに対応し、前記第２
    ソース・デバイスは第２タイプの第２アプリケーションに対応する、ステップと、
    を備えている、方法。
21. 請求項１８記載の方法において、前記レポジトリは、複数のアプリケーションに結合さ
    れており、前記レポジトリは、前記複数のアプリケーションに対応する複数のデータ・カ
    プセルを含み、前記レポジトリは、前記複数のアプリケーションによる前記複数のデータ
    ・カプセルへのアクセスを与え、前記複数のアプリケーションの内少なくとも２つが異な
    るアプリケーションである、方法。
22. 請求項１８記載の方法において、前記レポジトリは、複数のデータ・カプセルの状態を
    キャッシュする処理に備える、方法。
23. 請求項１８記載の方法において、前記レポジトリは、複数のデータ・カプセルを線形に
    整列する処理に備える、方法。
24. 請求項１記載の方法において、前記データ構造は、類別されていない、方法。
25. 請求項１記載の方法において、前記データ・カプセルのデータ構造は、前記デバイス・
    イベント・データおよび前記状態情報のプラットフォーム独立表現を規定する、方法。
26. 請求項１記載の方法において、前記データ・カプセルのデータ構造は、前記デバイスイ
    ベント・データおよび前記状態情報へのプラットフォーム独立アクセスを与える、方法。
27. 請求項１記載の方法であって、
    前記データ・カプセルを、第１アプリケーション・タイプを有する第１アプリケーショ
    ンから、少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２
    アプリケーションに転送するステップを備えており、前記第１アプリケーション・タイプ
    は前記第２アプリケーション・タイプとは異なり、前記少なくとも１つのデータ・シーケ
    ンスを発生するステップを、前記第１アプリケーションによって実行するステップと、
    前記転送の間、前記データ・カプセルの少なくとも１つのデータ・シーケンスを不変の
    まま維持するステップと、
    を備えている、方法。
28. 請求項２７記載の方法であって、前記第２アプリケーションの動作中、前記少なくとも
    １つのデータ・シーケンスを用いるステップを備えている、方法。
29. 請求項１記載の方法において、前記イベントは、ユーザ・インターフェース・イベント
    を備えている、方法。
30. 請求項１記載の方法において、前記イベントは、グラフィクス・イベントを備えている
    、方法。
31. 請求項１記載の方法において、前記イベントは、状態情報の貯入を備えている、方法。
32. データをカプセル化する方法であって、
    デバイス・イベント・データとソース・デバイスの識別データとを含む第１データ集合
    を発生するステップであって、前記デバイス・イベント・データは、前記ソース・デバイ
    スが登録したイベントを指定するデータを含み、前記識別データは、前記ソース・デバイ
    スを識別するデータを含む、ステップと、
    前記イベントの状態情報集合全体を含む第２データ集合を発生するステップと、
    前記第１データ集合および前記第２データ集合の各々は、タイプ特定データ・レイアウ
    トとした類型データ・バンドルを備えており、
    前記第１データ集合および前記第２データ集合を含むようにデータ・カプセルを形成す
    ることにより、前記第１データ集合および前記第２データ集合をカプセル化するステップ
    であって、前記データ・カプセルが、前記少なくとも１つのデータ・シーケンスのアプリ
    ケーション独立表現を備えているデータ構造を有する、ステップと、
    を備えている、方法。
33. 第１タイプのアプリケーションの下で走るデバイスのイベントを検出するステップと、
    前記イベントを指定するデバイス・イベント・データと、前記イベントの状態情報とを
    備えているデータ・シーケンスを発生するステップであって、前記デバイス・イベント・
    データおよび状態情報は、前記アプリケーションに対応するタイプを有するタイプ特定デ
    ータである、ステップと、
    前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、
    前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現を備えて
    いるデータ構造を有する、ステップと、
    少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で走
    る少なくとも１つの第２ソース・デバイスの第２イベントを検出するステップであって、
    前記第２タイプが前記第１タイプとは異なる、ステップと、
    前記データ・カプセルと前記第２イベントとの間にある対応を特定するステップと、
    前記第２イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用
    いて、動作を実行するステップと、
    を備えている、方法。
34. 請求項３３記載の方法において、前記データ・シーケンスを発生するステップは、
    前記デバイス・イベント・データを含む第１データ集合を発生するステップと、
    前記状態情報を含む第２データ集合を発生するステップと、
    前記第１データ集合および前記第２データ集合を含むように、第１データ・シーケンス
    を形成するステップと、
    を備えている、方法。
35. 請求項３３記載の方法において、前記デバイス・イベント・データは、類別したデータ
    を表す、タグ付きのバイト・シーケンスである、方法。
36. 請求項３５記載の方法において、前記デバイス・イベント・データは、タイプ・ヘッダ
    と、タイプ特定データ・レイアウトとを含む、方法。
37. 請求項３３記載の方法において、前記状態情報は、類別したデータを表す、タグ付きの
    バイト・シーケンスである、方法。
38. 請求項３７記載の方法において、前記状態情報は、タイプ・ヘッダと、タイプ特定デー
    タ・レイアウトとを含む、方法。
39. 請求項３３記載の方法であって、
    少なくとも１つのオフセットを発生するステップと、
    前記少なくとも１つのオフセットを含むように、前記データ・カプセルを形成するステ
    ップと、
    を備えている、方法。
40. 請求項３９記載の方法であって、
    第１変数長を有する第１オフセットを発生するステップであって、前記第１オフセット
    は、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記デバイス
    ・イベント・データを指し示す、ステップと、
    第２可変長を有する第２オフセットを発生するステップであって、前記第２オフセット
    は、前記少なくとも１つのデータ・シーケンスの第１データ・シーケンスの前記状態情報
    を指し示す、ステップと、
    を備えている、方法。
41. 請求項３９記載の方法であって、
    前記少なくとも１つのオフセットの第１オフセットを用いて、前記データ・カプセルを
    通る第１コード・パスを形成するステップと、
    前記少なくとも１つのオフセットの第２オフセットを用いて、前記データ・カプセルを
    通る第２コード・パスを形成するステップと、
    を備えており、前記第１コード・パスおよび前記第２コード・パスは異なるパスである、
    方法。
42. 請求項３９記載の方法において、前記第１オフセットおよび前記第２オフセットの内少
    なくとも１つは、メタデータを含み、該メタデータは、前記アプリケーションのコンテキ
    ストに対応する、コンテキスト特定メタデータを備えている、方法。
43. 請求項３３記載の方法であって、前記データ・カプセルをレポジトリに転送するステッ
    プを備えている、方法。
44. 請求項４３記載の方法であって、
    前記第２イベントに対応するデータ・カプセルを求めて、前記レポジトリを検索するス
    テップと、
    前記対応の特定に応答して、前記レポジトリから前記データ・カプセルを抽出するステ
    ップと、
    を備えている、方法。
45. 請求項４３記載の方法において、前記レポジトリは、前記アプリケーションおよび前記
    少なくとも１つの第２アプリケーションに結合されており、前記レポジトリは、前記アプ
    リケーションおよび前記少なくとも１つの第２アプリケーションに対応する複数のデータ
    ・カプセルを含み、前記レポジトリは、前記アプリケーションおよび前記少なくとも１つ
    の第２アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法
    。
46. 請求項４３記載の方法において、前記レポジトリは、複数のデータ・カプセルの状態を
    キャッシュする処理に備える、方法。
47. 請求項４３記載の方法において、前記レポジトリは、複数のデータ・カプセルを線形に
    整列する処理に備える、方法。
48. 請求項３３記載の方法において、前記データ構造は、類別されていない、方法。
49. 請求項３３記載の方法において、前記データ・カプセルのデータ構造は、前記デバイス
    ・イベント・データおよび前記状態情報のプラットフォーム独立表現を規定する、方法。
50. 請求項３３記載の方法において、前記データ・カプセルのデータ構造は、前記デバイス
    イベント・データおよび前記状態情報へのプラットフォーム独立アクセスを与える、方法
    。
51. 第１タイプのアプリケーションの下で走る第１ソース・デバイスのイベントを検出する
    ステップと、
    前記イベントを指定するデバイス・イベント・データと、前記イベントの状態情報とを
    備えているデータ・シーケンスを発生するステップであって、前記デバイス・イベント・
    データおよび状態情報は、前記アプリケーションに対応するタイプを有するタイプ特定デ
    ータである、ステップと、
    前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、
    前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現を備えて
    いるデータ構造を有する、ステップと、
    前記データ・カプセルをレポジトリに入れるステップと、
    少なくとも１つの第２タイプを有する少なくとも１つの第２アプリケーションの下で走
    る少なくとも１つの第２ソース・デバイスの第２イベントを検出するステップと、
    前記レポジトリを検索し、前記データ・カプセルと前記第２イベントとの間にある対応
    を特定するステップと、
    前記データ・カプセルのデータ・シーケンスの内容を用いて、前記第２イベントに対応
    する動作を、前記第２ソース・デバイスの代わりに実行するステップと、
    を備えている、方法。

Images