JP5805537B2 - マルチプロセス・インタラクティブ・システムおよび方法 - Google Patents

マルチプロセス・インタラクティブ・システムおよび方法 Download PDF

Info

Publication number
JP5805537B2
JP5805537B2 JP2011532225A JP2011532225A JP5805537B2 JP 5805537 B2 JP5805537 B2 JP 5805537B2 JP 2011532225 A JP2011532225 A JP 2011532225A JP 2011532225 A JP2011532225 A JP 2011532225A JP 5805537 B2 JP5805537 B2 JP 5805537B2
Authority
JP
Japan
Prior art keywords
data
event
processes
capsule
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2011532225A
Other languages
English (en)
Other versions
JP2012506097A (ja
Inventor
クラマー,クウィンドラ・ハルトマン
アンダーコフラー,ジョン・エス
Original Assignee
オブロング・インダストリーズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/417,252 external-priority patent/US9075441B2/en
Priority claimed from US12/487,623 external-priority patent/US20090278915A1/en
Priority claimed from US12/553,845 external-priority patent/US8531396B2/en
Priority claimed from US12/557,464 external-priority patent/US9910497B2/en
Priority claimed from US12/572,689 external-priority patent/US8866740B2/en
Application filed by オブロング・インダストリーズ・インコーポレーテッド filed Critical オブロング・インダストリーズ・インコーポレーテッド
Publication of JP2012506097A publication Critical patent/JP2012506097A/ja
Application granted granted Critical
Publication of JP5805537B2 publication Critical patent/JP5805537B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/017Gesture based interaction, e.g. based on a set of recognized hand gestures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V40/00Recognition of biometric, human-related or animal-related patterns in image or video data
    • G06V40/20Movements or behaviour, e.g. gesture recognition
    • G06V40/28Recognition of hand or arm movements, e.g. recognition of deaf sign language

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • General Health & Medical Sciences (AREA)
  • Psychiatry (AREA)
  • Social Psychology (AREA)
  • Quality & Reliability (AREA)
  • Processing Or Creating Images (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Image Processing (AREA)
  • User Interface Of Digital Computer (AREA)
  • Digital Computer Display Output (AREA)

Description

関連出願
本出願は、2008年10月14日に出願した米国(US)特許出願第61/105,243号の優先権を主張する。
本出願は、2008年10月14日に出願した米国(US)特許出願第61/105,253号の優先権を主張する。
本願は、2008年4月24日に出願したUS特許出願第12/109,263号の一部継続出願である。
本願は、2009年4月2日に出願したUS特許出願第12/417,252号の一部継続出願である。
本願は、2009年6月18日に出願したUS特許出願第12/487,623号の一部継続出願である。
本願は、2009年9月3日に出願したUS特許出願第12/553,845号の一部継続出願である。
本願は、2009年9月10日に出願したUS特許出願第12/557,464号の一部継続出願である。
本願は、2009年10月2日に出願したUS特許出願第12/572,689号の一部継続出願であり、US特許出願第12/572,689号は、米国特許第7,598,942号の一部継続出願である。
発明の分野
計算プロセス内および計算プロセス間におけるデータの表現、操作、および交換に関する実施形態について説明する。
従来技術
従来のプログラミング環境は、マルチコンピュータ演算装置(CPU)やネットワークを跨いだ実行、あるいは多数の計算プロセス間における柔軟なデータ共有を完全にサポートしてはいない。ユーザが向き合うコンピュータ・プログラムは、従前より、処理の大多数および全てのグラフィカル出力が1つの計算プロセスによって生成されるように構成されている。このメカニズムは、標準的であり、ツール・チェーン開発環境およびオペレーティング・システムによって十分にサポートされているが、規模の調整がしずらく、広く用いられている同世代のアプリケーションが膨大で不安定となる大きな一因となっている。
引用による包含
本明細書において述べる各特許、特許出願、および/または刊行物は、本願において引用することにより、個々の特許、特許出願、および/または刊行物の各々が具体的にそして個々に、引用することにより本願に含まれることを示した場合と同程度にその全体が本願にも含まれるものとする。
図1Aは、一実施形態の下における、マルチプロセス・インタラクティブ・システムのブロック図である。 図1Bは、代替実施形態の下におけるマルチプロセス・インタラクティブ・システムのブロック図である。 図1Cは、他の代替実施形態の下におけるマルチプロセス・インタラクティブ・システムのブロック図である。 図2は、一実施形態の下におけるマルチプロセス・インタラクティブ・システムの動作の流れ図である。 図3は、一実施形態の下において、スロークス(slawx)、プロテイン(protein)、およびプール(pool)を用いたデータ表現を含む処理環境のブロック図である。 図4は、一実施形態の下における、プロテインのブロック図である。 図5は、一実施形態の下における、デスクリップ(descrip)のブロック図である。 図6は、一実施形態の下における、インジェスト(ingest)のブロック図である。 図7は、一実施形態の下におけるスロー(slaw)のブロック図である。 図8Aは、一実施形態の下において、プールの中にあるプロテインのブロック図である。 図8Bは、一実施形態の下における、スロー・ヘッダ・フォーマットを示す。 図8Cは、一実施形態の下においてプロテインを用いる際の流れ図である。 図8Dは、一実施形態の下において、プロテインを組み立てるまたは発生する際の流れ図である。 図9は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。 図10は、多数のデバイスと、これらのデバイスの1つ以上で起動する多数のプログラムとを含む処理環境のブロック図であり、一実施形態の下において、プラズマ構造(plasma construct)(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。 図11は、多数のデバイスと、これらのデバイスの1つ以上で起動する多数のプログラムを含む処理環境のブロック図であり、一代替実施形態の下において、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。 図12は、多数の入力デバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、別の代替実施形態の下において、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。 図13は、多数のデバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクスイベントを共有し、集合的に応答することを可能にする。 図14は、多数のデバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする。 図15は、多数のデバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、追加の代替実施形態の下において、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる。 図16は、一実施形態の下における、ジェスチャ制御システムのブロック図である。 図17は、一実施形態の下における標識タグの図である。 図18は、実施形態におけるジェスチャ・ボキャブラリにおけるポーズの図である。 図19は、実施形態におけるジェスチャ・ボキャブラリにおける方位の図である。 図20は、一実施形態におけるジェスチャ・ボキャブラリにおける2つの手の組み合わせの図である。 図21は、一実施形態におけるジェスチャ・ボキャブラリにおける方位配合の図である。 図22は、一実施形態の下におけるジェスチャ制御の流れ図である。 図23は、一実施形態の下におけるコマンドの一例である。 図23は、一実施形態の下におけるコマンドの一例である。 図24は、一実施形態の下において、マルチプロセス・インタラクティブ・システムを用いて実現した空間動作環境(SOE)のブロック図である。 図25は、一実施形態の下において、ジェスチャ制御システムからの入力を用いるマルチプロセス・インタラクティブ・システムの動作の流れ図である。
本明細書では、インタラクティブ・アプリケーションを起動させる(give rise to)ように多数のコンピュータ・プロセスの挙動および出力を調整するシステムおよび方法を含む実施形態について説明する。本明細書において説明する実施形態は、総合的に、マルチプロセス・インタラクティブ・システム、プログラム、またはアプリケーションと呼ばれ、並列に実行することができる多数の別個のコンピュータ・プロセスに分割されたアプリケーション・プログラムを含む。1組のこれらのプロセスは、システム出力全体の内の一部分を生成することができ、この一部分とユーザが対話処理を行う。1組のこれらのプロセスは、構造化され明確に定義されたデータ交換メカニズムにアクセスすることができる。このデータ交換メカニズムは、アクティビティを調整するために用いられる。1組のこれらのプロセスは、構造化データ交換メカニズムを通じて、ユーザ入力(例えば、生のユーザ入力、重度に変換されたユーザ入力、生および重度に変換されたユーザ入力等)を利用するために動作可能である。
本明細書において記載する実施形態は、計算プロセスの境界を跨ぐアプリケーション・コンポーネントに対してモジュール性(modularity)を提供する。この提供されたモジュール性の結果、本明細書に記載する実施形態では、コンポーネントの再利用、相互動作可能性(interoperability)の機会増大、検査および検証の易化、ロバスト性向上、および実行中のフォールト・トレランスが得られる。
更に、同世代のコンピュータは、多数のプロセッサ・エレメント(例えば、CPUコア)を内蔵する場合がおおい。本明細書における実施形態は、従来のアプリケーション構成技法よりも、多重プロセッサ・アーキテクチャのスケーリングが格段に優れている。この「マルチコア」スケーリングは、コンピュータの設計および製造の傾向が、クロック速度上昇ではなく、コアの数量増大に増々傾倒しつつあるので、一層重要になる。
本明細書において記載する実施形態は、プロセス・コンポーネントの動的な構築、分解、および再組み合わせを可能にする。本明細書において記載する実施形態は、ネットワーキング(または他の相互接続)プロトコルを用いる多数のコンピュータに跨る構造化データ交換メカニズムの拡張を可能にする。本明細書において記載する実施形態は、コンピュータ間におけるプロセス・コンポーネントの動的な移転を可能にする。本明細書に記載する実施形態は、関与するプロセスの数、組成、および実行コンテキストにしたがって、構造化データ交換メカニズムの動的な最適化を可能にする。本明細書に記載する実施形態は、多数のコンピュータ上で作成されたグラフィカル出力を、1つのディスプレイにおいて一緒に組み合わせることを可能にする。本明細書において記載する実施形態は、多数のディスプレイを包括的に含むグラフィカル・コンテキストを共有し、調整することを可能にする。本明細書において記載する実施形態は、多数のコンピュータによってドライブされる多数の表示を包含するマルチディスプレイ・グラフィカル・コンテキストの共有および調整を可能にする。本明細書において記載する実施形態は、自動履歴バッファを導入し、過去のデータの内ある両が常にアプリケーション・コンポーネントに利用可能となるように、この自動履歴バッファを構造化データ交換メカニズムに組み込む。
以下の用語が本明細書において用いられる場合、以下の一般的な意味を持つことを意図している。「プロセス」という用語は、本明細書において用いられる場合、分離可能なプログラム実行コンテキストを意味する。コンピュータ・アーキテクチャおよびオペレーティング・システムは、プロセス実施の技術的詳細において相違する。本明細書において記載するメカニズムは、広範囲のプロセス実施態様に跨って動作し、できるだけ多い利用可能な計算リソースを利用する混成アプリケーション設計またはコンフィギュレーションを容易にするように構成されている。
「デバイス」という用語は、本明細書において用いる場合、1つ以上のプログラムまたはアルゴリズムを起動させるあらゆるプロセッサ主体デバイス、1つ以上のプログラムまたはアルゴリズムの下で起動するあらゆるプロセッサ主体デバイス、および/または1つ以上のプログラムを起動させる、および/または1つ以上のプログラムまたはアルゴリズムの下で起動するプロセッサ主体デバイスに結合または接続されているあらゆるデバイスを意味する。「イベント」という用語は、本明細書において用いる場合、起動している即ち実行中のプログラムまたはアルゴリズム、プロセッサ主体デバイス、および/またはプロセッサ主体デバイスに結合または接続されているデバイスと関連のあるあらゆるイベントを意味する(例えば、イベントは、入力、出力、制御、状態、状態変化、動作(action)、データ(データのフォーマットや、データと関連のある処理における段階には無関係)等を含むことができるが、これらに限定されるのではない)。
以下の説明では、本明細書において説明する実施形態の完全な理解が得られるように、そして実施形態についての説明が可能となるように、多数の具体的な詳細を導入する。しかしながら、これらの実施形態は、これらの具体的な詳細の1つ以上がなくても、または他のコンポーネント、システム等を用いても実施できることは、当業者には認められよう。一方、開示される実施形態の態様を曖昧にするのを避けるために、周知の構造または動作については、図示しないか、または詳細に説明しないこととする。
本明細書における実施形態は、少なくとも1つの処理デバイス上で多数のプロセスを実行するシステムおよび方法を含む。一実施形態のシステムおよび方法は、各プロセスのイベントをデータ・カプセルに変換する。一実施形態のシステムおよび方法は、このデータ・カプセルを多数のプールまたはレポジトリに転送する。各プロセスは、認識プロセスとして動作し、この認識プロセスは、プールにおいて、当該認識プロセスのインタラクティブ機能および/または認識プロセスの識別に対応する内容を備えているデータ・カプセルを認識する。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルのコンテンツに適した処理を実行する。
例えば、図1Aは、一実施形態の下における、マルチプロセス・インタラクティブ・システム10のブロック図である。このシステム10は、任意の数のプロセスP1〜P7をホストするまたは実行する処理デバイス11を含む。この例のマルチプロセス・インタラクティブ・システム10は、1つのコンピュータ11を含むまたは1つのコンピュータ11において実行するが、1つのコンピュータに限定されるのではなく、任意の数の処理デバイスまたはシステム、および/またはその組み合わせに跨って実行することもできる。一実施形態のプロセスP1〜P7は、1つ以上のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムは、少なくとも1つのプロセスを備えているが、本実施形態はそのように限定されるのではない。各プロセスの間に発生または生成されたイベントは、ある数のデータ・カプセルDC1〜DC9に変換され、これらのデータ・カプセルは多数のプール15〜17またはレポジトリに転送される。システム10の楕円エレメントは、プール15〜17を表し、プールまたはレポジトリとは、構造化データ交換のためのメカニズムである。これについては、以下で詳細に説明し、更に関連出願においても記載されている。データ・カプセルDC1〜DC9は、データ・メッセージとも呼ばれ、プール15〜17を通過する。データ・カプセルを、包括的に、「プロテイン」と記述する。プロテインについては以下で説明する。
各プロセスP1〜P7は、認識プロセスとして動作し、認識プロセスは、プール15〜17において、当該認識プロセスP1〜P7のインタラクティブ機能および/または認識プロセスP1〜P7の識別に対応する内容を備えているデータ・カプセルを認識する。認識プロセスP1〜P7は、認識したデータ・カプセルDC1〜DC9をプールから引き出し、認識したデータ・カプセルのコンテンツに適した処理を実行する。マルチプロセス・インタラクティブ・システム10については、以下で図3から図15を参照しながら更に詳しく説明する。
図1Bは、代替実施形態の下におけるマルチプロセス・インタラクティブ・システム20のブロック図である。このシステム20は、任意の数のプロセスP1〜PXをホストするまたは実行する処理デバイス21を含み、Xは、処理デバイス21および/またはシステム20の構成に適した任意の数を表す。また、システム20は、任意の数のプロセスP1〜PYをホストするまたは実行する処理デバイス22も含み、Yは、処理デバイス22および/またはシステム20の構成に適した任意の数を表す。この例のマルチプロセス・インタラクティブ・システム20は、2つの処理デバイス21/22を含む、またはこれらに跨って実行するが、2つのデバイスに限定されるのではなく、任意の数の処理デバイスまたはシステム、および/またはその組み合わせに跨って実行することもできる。一実施形態のプロセスP1〜PXおよびプロセスP1〜PYは、1つ以上のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムは少なくとも1つのプロセスを備えているが、本実施形態はそのように限定されるのではない。
各プロセスの実行中に発生または生成されるイベントは、データ・カプセル(図示せず)に変換され、これらのデータ・カプセルは1つ以上のプールに転送される。システム20の楕円エレメントはプールを表し、これらのプールまたはレポジトリは、構造化データ交換のためのメカニズムである。これについては、以下で詳細に説明し、更に関連出願においても記載されている。この例では、プールPL1が処理デバイス21上にホストされているが、任意の数のプールを処理デバイス21上にホストすることもできる。プールPL1〜PLYは処理デバイス22上にホストされており、Yは、処理デバイス22および/またはシステム20の構成に適した任意の数を表し、任意の数のプールを処理デバイス22上にホストすることができる。また、システム20はプールPL11〜PLXも含み、Xは、処理デバイス22および/またはシステム20の構成に適した任意の数を表し、任意の数のプールをシステム20においてホストすることができる。データ・カプセルを発生する任意のプロセスおよび/またはデバイスが、データ・カプセルをシステムにおける任意のプールに転送することができる。
各プロセスP1〜PX/P1〜PYは、認識プロセスとして実行し、この認識プロセスは、プールにおいて、当該認識プロセスP1〜PX/P1〜PYのインタラクティブ機能に対応する内容を備えているデータ・カプセル、および/または認識プロセスP1〜PX/P1〜PYの識別を認識する。認識プロセスP1〜PX/P1〜PYは、認識したデータ・カプセルをプールから引き出し、これら認識したデータ・カプセルの内容に適した処理を実行する。マルチプロセス・インタラクティブ・システム20については、図3から図15を参照して以下で更に詳しく説明する。
本明細書における実施形態は、少なくとも1つの処理デバイス上において多数のプロセスを実行するシステムおよび方法を含む。一実施形態のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備えている。一実施形態のシステムおよび方法は、複数のプロセスの内各プロセスのイベントをデータ・カプセルに変換する。データ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、そのデータ・カプセルを発生したプロセスの状態情報とを含む。一実施形態のシステムおよび方法は、データ・カプセルを多数のプールまたはレポジトリに転送する。一実施形態の各プロセスは、認識プロセスとして動作する。この認識プロセスは、プールにおいて、当該認識プロセスのインタラクティブ機能に対応するコンテンツを備えているデータ・カプセル、および/または認識プロセスの識別を認識する。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する。
本明細書において記載する実施形態の例は、インタラクティブ・アプリケーションを可能にするために、多数のコンピュータ・プロセスの挙動およびグラフィカル出力を調整するシステムおよび方法を含む。この例はグラフィカル処理およびグラフィカル出力を対象とするが、マルチプロセス・インタラクティブ・システムの実施形態は、グラフィカル・プロセスに限定されるのではなく、任意の数の処理デバイスの下で起動する任意のプロセスに適用することができる。マルチプロセス・インタラクティブ・システムは、並列に実行することができる多数の別個のコンピュータ・プロセスに分割されたアプリケーション・プログラムを含み、1組のこれらのプロセスが、ユーザが対話処理するグラフィカル出力全体における一部を生成することができる。1組のこれらのプロセスは、構造化され明確に定義されたデータ交換メカニズムにアクセスすることができる。このデータ交換メカニズムは、構造化データ交換メカニズムを通じてユーザ入力を利用するために動作可能となるように、アクティビティを調整するために用いられる。
更に具体的な一例として、以下に続く説明は、本明細書ではスクエア(Squares)と呼ばれる、マルチプロセス・グラフィカル・プログラムについて、インタラクティブ・アプリケーションを起動するように多数のコンピュータ・プロセスの挙動およびグラフィカル出力を調整する実施形態のインスタンス化(instantiation)の一例として教示する。このインスタンス化の一例の説明は、本明細書において開示するメカニズムが、どのように動作するのかを、任意のインタラクティブ・プログラムに合わせてそれを実施するのに十分に詳細なレベルで示すことを意図している。このメカニズム(および、実際にはこの構成部分)は完全に汎用であり、実際には種々の異なる方法で実現することができる。このようなプログラムでは典型的であるように、本明細書において開示するメカニズムは、ユーザ入力へのアクセス、プロセスを跨るプログラム状態の細かい粒度の調整、およびグラフィカル出力の調整を含み、これらには限定されない主要なサービスを提供する。
本明細書において紹介するスクエア・プログラムは、実世界プログラムにおいて有用な様々な種類の基本的調整を実演(demonstrate)する役割を果たす。このスクエア・プログラムは、柔軟な数の有色、半透明の正方形を1つ以上のコンピュータ・ディスプレイ上にレンダリングするための装備がある。これらの正方形に各々は、1つの計算プロセスにおいて具体化される。各正方形の状態およびグラフィック上の詳細は、種々の要因に依存する。これらの要因には、ユーザの入力アクション、他の正方形の状態、および大域的に配信される外部メッセージが含まれる。これらの正方形は、入力デバイス(例えば、マウス、タッチ・スクリーン等)を用いて、ディスプレイ上のあらゆるところに移動させることができる。関連出願において記載されているジェスチャ/空間入力システムも、これらの正方形を移動させるために用いることができ、その場合、ジェスチャ/空間ネットワークに関与するコンピュータに利用可能なディスプレイの内任意のものに、正方形を位置付けることができる。
図1Cは、他の代替実施形態の下における、マルチプロセス・インタラクティブ・システム100のブロック図である。このシステム100は、プロセスおよび相互接続を含み、これらが組合わさることによってプログラムの実行(run)例を形成する。無地の矩形エレメント(solid rectangle element)(例えば、エレメントM、P、S、G全般)は、システム100におけるプロセスを表す。楕円のエレメント(例えば、エレメントUi、Coo、フレーム)は、プール、即ち、以下で詳細に説明するような構造化データ交換のためのメカニズムを表す。このメカニズムは、関連出願にも記載されている。プールを通過するデータ・メッセージは、以下で説明するように、包括的に「プロテイン」と呼ばれる。
この例のマルチプロセス・インタラクティブ・システム100は、2つのコンピュータ101および102を含む、またはこれらのコンピュータ101および102に跨って実行するが、2つのコンピュータに限定されるのではなく、任意の数の処理システム、および/またはその組み合わせに跨って実行するこができる。この例では、第1コンピュータ101が2つの正方形S(例えば、S21、S22)を具体化するプロセスをホストし、第2コンピュータ102が4つの正方形S(例えば、S11、S12、S13、S14)を具体化するプロセスをホストする。代替実施形態では、任意の数のコンピュータ上で実行する任意の数の正方形プロセスSを含むことができる。第1コンピュータ101は1つのディスプレイ110に結合されており、第2コンピュータ102は3つのディスプレイ121、122、123に結合されている。代替実施形態では、任意の数のコンピュータに結合されている任意の数のディスプレイを含むことができる。
2つのコンピュータ101および102の各々は、少なくとも1つの「マウス」プロセスM(例えば、M1、M2)をホストする。マウス・プロセスMは、コンピュータのマウス入力イベントを、ユーザ入力プロテインの相応しいストリームに変換し、これらのプロテインを少なくとも1つの「ユーザ入力」プールUiに配信する上位ドライバを含む。ジェスチャ/空間システム(以下で詳細に説明する)が、ジェスチャ/空間プロセスGとしてカプセル化されており、これもユーザ入力プロテインをユーザ入力プールUiに配信する。
また、2つのコンピュータ101および102の各々は、少なくとも1つの「ポインタ」プロセスP(例えば、P1、P2)もホストする。ポインタ・プロセスPは、Uiプールからデータを取り込むまたは受け取り、ユーザがポインタの「注意(attention)」をどこに向けているのか判断し、しかるべきポインタ・グラフィクスを描画またはレンダリングする役割を担う。ポインタ・プロセスPは、ポインタ位置およびモードに関するデータまたはこれらを表すデータを、「調整(coordination)」プールCooに入れる。ポインタ・プロセスPは、グラフィカル出力を「フレーム」プールに配信する。「フレーム」プールは、以下で詳細に説明する、特殊化された抽象(specialized abstraction)である。
更に、2つのコンピュータ101および102の各々は、先に説明した様々な「スクエア」プロセスSもホストする。各スクエア・プロセスSは、調整プールCooを参照して、ポインタ・データおよびピア・スクエア・プロセスSの状態を求める。また、各スクエア・プロセスSは、これら自体の空間およびモード状態を記述するデータを調整プールCooに戻す。スクエア・プロセスSは、グラフィカル出力を「フレーム」プールに配信する。フレーム・プールは、特殊化した抽象であり、以下で詳しく説明する。
ジェスチャ/空間プロセスGは、ユーザ入力プールUiおよび調整プールCooと共に、2つのコンピュータ101および102のいずれにでもホストすることができる。あるいは、ジェスチャ/空間プロセスGをユーザ入力プールUiおよび調整プールCooと共にホストすることは、2つのコンピュータ101および102間で分担することもできる。更に別の代替構成として、ジェスチャ/空間プロセスGを、ユーザ入力プールUiおよび調整プールCooと共に、他のコンピュータ(図示せず)にホストすることもできる。
ローカル・フレーム・プールに貯入されたプロテインに合わせて、システム100は専用の合成プロセスcomを含む。このプロセスは、フレーム・レイヤを組み合わせて、1秒毎に多数回、ディスプレイ毎に1つの出力フレームを形成する。総合的なディスプレイ・フレーム・レートは、一般に、システム・レベルの構成選択によって設定されるが、スクエア・アプリケーションを構成する個々のプロセスの各々は、異なるフレーム・レートを用いることができるようになっている。合成プロセスcomは、フレーム・レイヤをしかるべく対照させる(match up)ように監視する。
図2は、一実施形態の下におけるマルチプロセス・インタラクティブ・システムの動作についての流れ図200である。この動作は、複数のプロセスを少なくとも1つの処理デバイス上で実行する(202)ことを含む。複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備えるようになっている。この動作は、複数のプロセスの内各プロセスのイベントをデータ・カプセルに変換する(204)ことを含む。データ・メッセージは、イベントのイベント・データのアプリケーションに独立した表現と、このデータ・メッセージを発生したプロセスの状態情報を含む。この動作は、データ・メッセージを複数のプールの内少なくとも1つのプールに転送する(206)ことを含む。各プロセスは、認識プロセスとして動作し、この認識プロセスが、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容の少なくとも1つを備えているデータ・カプセルと、認識プロセスの識別を認識する(208)。認識プロセスは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する(210)。このマルチプロセス・インタラクティブ・システムの動作は、プロセス間における調整を可能にし、この調整には、複数のプールからピア・プロセスの状態情報を引き出すことによって、複数のプロセスのピア・プロセスと対等になる複数のプロセスの内各プロセスが含まれる。また、この動作は、複数のプールの内少なくとも1つのプールの1組のデータ・カプセルの内容をインタラクティブに組み合わせることによって、複数のプロセスの出力を発生することも可能にする。
マウスおよびジェスチャ/空間入力を扱う際に、マウス・プロセスMは下位マウス・ハードウェアを監視し、従前のマウス・ドライバ・イベントを、画面に独立したプロテインに変換する。以下の記載にしたがって、ユーザ入力プールUiに配信される一実施形態のマウス・プロセスMのプロテインは、次の通りである。
Figure 0005805537


ジェスチャ/空間プロセスGのプロテインは、以下のように、同様に見える。
Figure 0005805537


ポインタ・プロセスPは、これらのメッセージを、これらが描画する役割を担っている種々のポインタの三次元空間における位置を暗示するものとして解釈する。静的な1組のポインタが、アプリケーション・コードにおいて定義されていてもよく、または早期のプロテインがポインタを定義し初期化していてもよい。
空間動作環境内において実行するスクエア・プログラムのインスタンス化について、ポインタ・プロセスPの各々は、これらがホストされているコンピュータに取り付けられている表示画面の正確な実世界位置を知っている。この場合も、これらの表示画面は、起動時に初期化されていても、またはデータ・メッセージによって動的に初期化されてもよい。
プロテインがユーザ入力プールUiに到達すると、ポインタ・プロセスPは反応して、以下のように、新たなプロテインを構築し、これらを調整プールCooに配信する。
Figure 0005805537


これらのプロテインまたはメッセージは、利用可能なディスプレイに関するポインタ・オブジェクトの位置を定義する。各ポインタ・プロセスPは、それがホストされているコンピュータのみに取り付けられているディスプレイに対する数学的変換を管理するように構成されている。
周期的に、各ポインタ・プロセスPはグラフィカル出力のフレームも描画する。このグラフィカル・データはフレーム・プールに配信される。ポインタ・プロセスPによって生成される各フレームは、全てのポインタ・グラフィクスをレンダリングし、そのプロセスをホストするコンピュータに取り付けられているディスプレイ上に、そのポインタ・グラフィクスが現れる。
一実施形態のアプリケーション・モデルおよびグラフィクスに移ると、スクエア・プロセスSは、スクエア・アプリケーションの焦点となる半透明な正方形を追跡し描画する役割を担う。各正方形は、位置、方位、サイズ、および色を有する。スクエア・プロセスSは、正方形の状態が変化したときはいつでも、プロテインを調整プールCooに入れる。
Figure 0005805537



また、スクエア・プロセスSは、ポインタ・プロセスが行うのと全く同様に、グラフィカル出力をフレーム・プールに配信する。各スクエア・プロセスSは、しかしながら、当該プロセスをホストするコンピュータに取り付けられているディスプレイにその正方形が現れるか否かには係わらず、それ自体の正方形をレンダリングする。フレームの扱いについては、以下で詳しく説明する。
ポインタおよび正方形の状態を記述するプロテインをマルチ・サブスクライバ・プール(multi-subscriber pool)に配置または転送することによって、このアプリケーションを構成する別個のプロセスが調整することが可能となり、こうして異なるプロセス間において調整が行われる。一実施形態のスクエア・プロセスSは、正方形の境界のエリア内に進んだポインタを示すプロテインを監視する。これが行われると、スクエア・プロセスSはプロテインをプールに入れて、以下のようにして、重複、および関与する正方形およびポインタへの参照を示す。
Figure 0005805537


ポインタ・プロセスPは、この形態のプロテインを監視する。ポインタ・プロセスPがそれ自体のmidを参照する重複プロテインを特定または発見(see)すると、ポインタ・フレームを描画するときに用いるグラフィカル表現を変更する。重複を示すグラフィックは、例えば、プロセスが然るべき重複終了(overlap-exit)プロテインを確認するまで用いられる。
Figure 0005805537


以上の調整方策には、多くの変形が可能である。ポインタ・プロセスPは、幾何学的重複(前述のようにスクエア・プロセスSがそれを行うのではなく)をチェックする役割(duty)を扱うことができる。これらのプロセスは全て、フレーム同期させることができ、重複プロテインをフレーム毎に発生することができ、これによって別々の開始および終了プロテインの必要性が解消する。
殆ど常に、本明細書において説明するメカニズム内において動作するときに直面する所与の調整問題にはいずれにも、利用可能な多様な解決策がある。この柔軟性は、実際には、本明細書における実施形態の強さの1つである。本明細書における説明は、典型的なマルチプロセス・グラフィカル・アプリケーションを構築しようとする際に直面する様々な重なり合い(interlocking)の問題に対して実施される解決策の少なくとも1つを記録に取っている。多数の参考文献が、有用なメッセージング・パターンを収集しており、その多くは、適用可能である。例えば、G. Hohpe and B. Woolfによる"Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions", ISBN 0321146530がある。
一実施形態の下においてユーザ入力を操作アクション(manipulatory action)に繋げる際、正方形を対話的に動かすには、ポインタ・プロセスPが調整プールCooに入れたデータをスクエア・プロセスSが利用することが含まれる。スクエア・プロセスPは、認識されたポインタ重複状態ならびに「ポインタ」および「クリック」デスクリップを有するプロテインの組み合わせに応答して、移動を初期化する。移動が進展している間、正方形のグラフィカル表現が変化し、空間における正方形の位置がポインタに追従する。この移動は、対応する「ポインタ」/「クリック解除(unclick)」プロテインが発生するまで続く。
また、一実施形態の正方形は、これらが互いに重なり合ったときにも、その色を変化させる。Sプロセスが「tsquare」/「ポジション」プロテインを確認したときはいつでも、それ自体とそのプロテインのデポジッタ(depositor)との間に何らかの重複がないか計算を行う。重複がある場合、その次のフレームをレンダリングするときに、重複を指示する色を用いる。そうでない場合、その通常の色を用いる。
尚、一実施形態の疎結合アーキテクチャの柔軟性によって、この挙動を実現する他のまたは変わりの方法も得られることを注記しておく。スクエア・プロセスSは、重複計算を行うのを回避し、代わりにこの作業を他のプロセスに肩代わりさせることができる。例えば、正方形の一部または全部について計算(math)を連続的に行い、重複状態を記述するプロテインを、調整プールCooに落下させる。スクエア・プロセスSは、単にこれらのプロテインを待つだけである。
Figure 0005805537


このアプリケーション作業負荷をスライスしさいの目に切る柔軟性は非常に有用である。計算集約的なジョブは、余分なパワーを有するプロセッサまたは機械に移動することができる。データの生成部(producers)は、必要に応じて、ヘルパー・プロセスをインスタンス化することができる(そして、もはやこれらが不要となったときはこれらを終了させることができる)。ユーザが直接対話処理しているアプリケーション・エリアには、またユーザが直ちにより大きな粒度、詳細、またはリフレッシュ・レートを知覚できる場合にも、より大きな計算およびレンダリング・リソースを適用することができる。
これの全てが可能なのは、本明細書において説明するマルチプロセス・インタラクティブ・システムがアプリケーション状態を外面化し(externalize)、マルチプロセスがその状態にアクセスすることを可能にするからである。対照的に、同世代のプログラミング・モデルでは、実行時の状態は、個々のプロセスの内部に殆ど完全に「閉じ込められる」ことになる。
マルチプロセス・インタラクティブ・システムは、プログラマが全てのインタラクティブ機能をプロテイン・ドライブ可能状態として露出することを促進する。アプリケーション・プログラミング・インターフェース(API)は、従前の関数コールではなく、各プロセスが認識するプロテインによって定義される。例えば、正方形の内任意のもの(または全て)の色を変化させるプロテインは、次のように定義される。
Figure 0005805537



いずれかのスクエア・プロセスSがこのプロテインを調整プールCooにおいて確認した場合、それ自体の一意のオブジェクトidまたは一般的なアドレス0x0のいずれかが存在するか否か確かめるために、tidsリストをチェックする。そうである場合、プロセスは、2つの新たに指定された色を用いて(1つは通常の場合、そして1つは重複の場合)その正方形をレンダリングし始める。
このメカニズムおよびこの「全てのインタラクティブ機能をプロテインとして露出する(expose)」手法を用いると、スクエア・アプリケーションの他の全てのコードが既に終了し、配備され、実行した後に、正方形の色を制御する新たなユーティリティを書くことができる。新たな機能を実行中のアプリケーションに追加するのに、再コンパイルも再リンクも必要としない。
グラフィカル・アプリケーション用のインタラクティブ・デバッガは、この手法の効果が得られる他のプログラム・タイプである。従前のデバッガは、一般に、プログラムを一時停止した後でないと、プログラムの内部状態について詳しく表示することができない。しかしながら、プログラムの操作可能な状態の全てが、本明細書において記載したように、プールを通じて露出されると、デバッガは、プログラムが実行している間に、プログラムの状態を監視することおよびプログラム状態を操作することの双方が可能になる。
ポインタ・プロセスPおよびスクエア・プロセスSの双方は、あらゆるディスプレイ出力がユーザに見えるようにするために、グラフィクス・データをフレーム・プールに押し出す。本明細書において説明する実施形態は、グラフィクスを出力するための多数の方法を含む。その一部についてここで詳しく説明する。他の実施形態は、グラフィクス・データをフレーム・プールにプッシュし、グラフィクスを出力するために、以下で説明するプロセスの異なる組み合わせの下で動作することができる。
一実施形態では、プロセスは、OpenGLのような、直接レンダリング・フレームワークを用いて、直接システム・グラフィクス・レイヤに描画することができる。この手法の下では、プールは、グラフィクス・コマンドや画素データのためではなく、調整のために用いられる。
他の実施形態では、レンダリング・コマンドをプールに伝えるプロセスを通じて、グラフィクス・データを出力する。ここでは、他のプロセス(または複数のプロセス)が、レンダリング・コマンドを解釈しシステム・グラフィクス・レイヤをドライブする役割を担う。これらのコマンドは、例えば、ベアOpenGLコール(bare OpenGL calls)のように、非常に低レベルにすることができる。逆に、これらのレンダリング・コマンドは、例えば、専用レンダリング・プロセスがフレーム毎に正方形を描画することができる十分の情報を備えている、前述のtsqureプロテインのように、非常に高レベルにすることができる。
更に他の実施形態では、メモリ内画素バッファにレンダリングし、次いで結果的に得られる生フレーム・データをプールに転送するまたは入れるプロセスを通じて、グラフィクス・データを出力する。他のプロセス(または複数のプロセス)は、生フレーム・データを組み合わせる。プールが扱うデータのボリュームは、一般に、前述したグラフィクス出力手法のものよりも、この手法の方が遥かに大きい。しかしながら、ローカル・レンダリングおよびネットワーク・フレーム・トラスポートは、大量の柔軟性をもたらし、したがって高帯域幅ネットワークおよび高速プール実施態様が利用可能である場合、これが用いられることが多い。
図1Cを参照して先に説明したシステム例100は、一般に、メモリ内画素バッファにレンダリングし、次いで得られた生フレーム・データをプールに転送するプロセスを通じて、グラフィクス・データを出力する。他のプロセス(または複数のプロセス)は、生のフレーム・データを組み合わせる。プールが扱うデータのボリュームは、一般に、この手法の方が前述したグラフィクス出力手法よりも遥かに大きい。しかしながら、ローカル・レンダリングおよびネットワーク・フレーム・トラスポートは、大量の柔軟性をもたらし、したがって高帯域幅ネットワークおよび高速プール実施態様が利用可能である場合、これが用いられることが多い。
したがって、ポインタ・プロセスPおよびスクエア・プロセスSは、各々、それら自体の個々のグラフィカル・エレメントをレンダリングする。各プロセスは、色成分の数、およびレンダリングする画素の数を選択する。1つのプロセスは、RGBA(赤、緑、青、アルファ)色空間の成分、またはアルファ配合およびアルファ合成によるRGB色彩モデルを用いて、ディスプレイの最大数に値する画素(例えば、2560×1600)をレンダリングすることができる。計算サイクル、レンダリング・オーバーヘッド、およびプールの帯域幅を節約するために、しかしながら、プロセスは、特定のグラフィカル・オブジェクトの投影された文字枠(bounding box)を捉えるために、必要なだけの画素のみを生成することもでき、そして輝度(透明度と共に)のレンダリングが十分であれば、2つの成分のみを用いることもできる。
レンダリングされた画素データは、種々のメタデータ(例えば、幾何学的広がり、レイヤリング情報、フレーム・レートの指示、余分な色情報等)と共に、フレーム・プールに転送または伝達される。スクエア・アプリケーションが空間動作環境のコンテキストで実行していると、各プロセスは実世界の幾何学データにアクセスし、しかるべき出力をフレーム・プールの各々に伝達することができる。これには、出力サイクル毎に1つよりも多いフレームをレンダリングすることを伴うこともある。
ローカル・フレーム・プールへのプロテインの貯入(deposit)は、一般に画素データの圧縮を不要にするレートで行われる。しかしながら、インタラクティブ・アプリケーションのために比較的低いレイテンシを達成するには、ネットワーク貯入がフレーム毎に送られるデータ量を低減することができる。一実施形態では、ハードウェア圧縮を用いて、各画素アレイを表すのに必要とされるバイト数を低減するが、本実施形態はそのように限定されるのではない。
図1Cを参照すると、システム100の一実施形態は、専用合成プロセスCOMを用いる。この合成プロセスCOMは、これらのフレーム・レイヤを組み合わせて、1秒毎に多数回、ディスプレイ毎に1つの出力フレームを形成する。総合的なディスプレイ・フレーム・レートは、一般に、システム・レベルの構成選択によって設定されるが、スクエア・アプリケーションを構成する個々のプロセスの各々は、異なるフレーム・レートを用いることができるようになっている。合成プロセスcomは、フレーム・レイヤをしかるべく対照させる(match up)ように監視する。
図1Aから図1Cを参照しながら先に説明したように、一実施形態のマルチプロセス・インタラクティブ・システムは、プロセス、プール、およびプロテインを含む。システムにおいて無地の矩形は、プロセスを表し、一方楕円はプール、即ち、構造化データ交換のためのメカニズムを表す。プールを通過するデータ・メッセージは、包括的に「プロテイン」と呼ばれる。プロセスの各々は、プロテインを発生し、このプロテインを1つ以上のプールに貯入し、1つ以上のプールからプロテインを引き出す。
プールおよびプロテインは、本明細書において説明する、プロセス間でまたはプロセスに跨って共有されるべきデータをカプセル化するための方法およびシステムの構成要素である。また、これらのメカニズムは、プロテインおよびプールの他に、スロークス(「スロー」(slaw)の複数形)も含む。一般に、スロークスは、プロセス間交換についての最も低いレベルのデータ定義を規定し、プロテインは、中間レベルの構造を規定し、照会(querying)およびフィルタリングを担い(hook for)、プールは、高レベルの編成およびアクセス・セマンティクスを規定する。スロークスは、効率的で、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、スロークスをペイロードとして用いて、データ・カプセル化および移送方式を規定する。プールは、ローカル・プロセス間での、リモートまたは分散プロセス間にあるネットワークを跨いだ、そして長期(例えば、ディスク上等における)記憶を通じた、プロセス内におけるプロテインの構造化された柔軟な集計、順序付け、フィルタリング、および分散を規定する。
マルチプロセス・インタラクティブ・システムの実施形態の構成および実施態様は、様々な構造(construct)を含み、これらが一緒になって多数の能力を可能にする。例えば、本明細書において記載する実施形態は、前述のように大多数のプロセス間におけるデータの効率的な交換に備えている。また、本明細書において記載する実施形態は、柔軟なデータの「分類」 (typing)および構造にも備えているので、広範囲にわたる多様な種類のデータおよび使用をサポートする。更に、本明細書において記載する実施形態は、データ交換のための柔軟なメカニズム(例えば、ローカル・メモリ、ディスク、ネットワーク等)を含み、これらは全て実質的に同様のアプリケーション・プログラミング・インターフェース(API)によってドライブされる。更に、本明細書において記載する実施形態は、異なるプログラミング言語で書かれたプロセス間におけるデータ交換を可能にする。加えて、本明細書において記載する実施形態は、データ・キャッシュおよび集計状態の自動的な保守を可能にする。
図3は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ表現を含む処理環境のブロック図である。本明細書において紹介する実施形態の主要な構造には、スロークス(「スロー」(slaw)の複数形)、プロテイン、およびプールが含まれる。本明細書において記載する場合、スロークスは、効率的で、プラットフォームに依存しないデータ表現およびアクセスのためのメカニズムを含む。プロテインは、本明細書において詳細に説明するように、データ・カプセル化および輸送方式を規定し、一実施形態のプロテインのペイロードはスロークスを含む。プールは、本明細書において記載する場合、プロテインの構造化されているが柔軟な集計、順序付け、フィルタ処理、および分散を規定する。プールは、プロテインのための、プロセス内部における、ローカル・プロセッサ間での、リモートまたは分散プロセス間にあるネットワークを跨いだ、そして「長期」(例えば、ディスク上)記憶による、データへのアクセスを与える。
図4は、一実施形態の下におけるプロテインのブロック図である。プロテインは、長さヘッダ、ディスクリップ、およびインジェストを含む。以下で詳細に説明するが、ディスクリップおよびインジェストの各々は、スローまたはスロークスを含む。
図5は、一実施形態の下におけるディスクリップのブロック図である。以下で詳細に説明するが、ディスクリップは、オフセット、長さ、およびスロークスを含む。
図6は、一実施形態の下におけるインジェストのブロック図である。以下で詳細に説明するが、インジェストは、オフセット、長さ、およびスローを含む。
図7は、一実施形態の下におけるスローのブロック図である。以下で詳細に説明するが、スローは、タイプ・ヘッダ、およびタイプ特定データを含む。
図8Aは、一実施形態の下における、プールの中にあるプロテインのブロック図である。プロテインは、長さヘッダ(「プロテイン長」)、ディスクリップ・オフセット、インジェスト・オフセット、ディスクリップ、およびインジェストを含む。ディスクリップは、オフセット、長さ、およびスローを含む。インジェストは、オフセット、長さ、およびスローを含む。
プロテインは、本明細書において記載する場合、プロセッサ間で共有する、あるいはバスまたはネットワークまたはその他の処理構造を跨いで移動する必要があるデータをカプセル化するメカニズムのことである。一例として、プロテインは、ユーザ・インターフェース・イベントに対応するまたは関連するデータを含むデータの輸送および操作のための改良メカニズムを提供する。具体的には、一実施形態のユーザ・インターフェース・イベントは、米国特許第7,598,942号に記載されており、引用したことによってその全体が本願にも含まれるものとしたジェスチャ・インターフェースのそれらを含む。更に別の例として、プロテインは、限定ではく、グラフィクス・データまたはイベント、および状態情報等その他多数を含むデータの輸送および操作のための改良メカニズムを提供する。プロテインは、構造化レコード・フォーマット、およびレコードを操作するための1組の関連方法である。本明細書において用いる場合、レコードの操作は、データを構造に入力すること、構造からデータを取り出すこと、およびデータのフォーマットおよび存在を問い合わせることを含む。プロテインは、種々のコンピュータ言語で書かれたコードを通じて用いられるように構成されている。また、プロテインは、本明細書において記載するような、プールの基本的構築ブロックとなるように構成されている。更に、プロテインは、それらが含むデータを不変のまま維持しつつ、プロセッサ間そしてネットワークを跨いで自然に移動できるように構成されている。
従来のデータ輸送メカニズムとは対照的に、プロテインにはタイプが決められていない。タイプは決められていないが、プロテインは、「タイプ状」機能を実装することに加えて、強力で柔軟性のあるパターン照合装置(facility)を備えている。また、本明細書に記載するように構成されているプロテインは、本質的に多点型でもある(しかし、二点間形態も、多点伝送の部分集合として容易に実現される)。加えて、プロテインはメモリ内、ディスク上、およびワイヤ(ネットワーク)上フォーマット間で異なることがない「ユニバーサル」レコード・フォーマットを定義する(即ち、実行する任意の最適化の種類だけが異なる)。
図4および図8を参照すると、一実施形態のプロテインは、バイトの線形シーケンスである。これらのバイトの中には、ディスクリップ・リストと、1組のキー値対がカプセル化されている。キー値対をインジェストと呼ぶ。ディスクリップ・リストは、綿密(elaborate)であるが効率的にフィルタ可能なプロテイン毎のイベント記述を任意に含む。インジェストは、1組のキー値対を含み、これらがプロテインの実際の内容を構成する。
プロテインのキー値対との関わり、ならびにネットワークに都合がよい(network-friendly)多点データ相互交換に関する中核的観念の一部は、「タプル」の概念を特別に許可する(priviledge)もっと簡単なシステム(例えば、Linda、Jini)と共有される。プロテインは、タプル指向システムとは様々な面で大きく異なり、その相違には、標準的、最適化可能なパターン照合基盤を設けるためにディスクリップ・リストを用いることが含まれる。また、プロテインがタプル指向システムと異なるのは、種々の記憶および言語構造に適したレコード・フォーマットの厳格な仕様、そしてそのレコード・フォーマットに対する「インターフェース」の色々な特定的な実施態様である。
プロテインの説明に戻って、プロテインの最初の4バイトまたは8バイトは、プロテインの長さを指定する。一実施形態では、長さは16バイトの倍数でなければならない。この16バイトの粒度により、バイト整合およびバス整合効率が現在のハードウェアでも達成可能であることを確保する。本来「4ワード整合」型でないプロテインには、任意のバイトを詰めこんで、その長さが16バイトの倍数となるようにする。
プロテインの長さ部分は、次のフォーマットを有する。ビッグ・エンディアン・フォーマットで長さを指定する32ビット。その下位4ビットはマクロ・レベルのプロテイン構造特性を示すフラグとして機能する。プロテインの長さが2^32バイトよりも大きい場合、その次に来る更に別の32ビット。
一実施形態における16バイト整合条件は、最初の4バイトの最下位ビットがフラグとして利用可能であることを意味する。そして、このため、最下位の3ビット・フラグは、プロテインの長さが最初の4バイトで表現できるのか、または8バイト必要なのかを示し、プロテインがビッグ・エンディアンまたはリトル・エンディアンの内どちらのバイト順序付けを用いるのかを示し、更に、プロテインが標準的構造または非標準的構造のどちらを採用するのかをそれぞれ示すが、プロテインはこのように限定されるのではない。4番目のフラグ・ビットは、今後の使用のために保存されている。
8バイト長フラグ・ビットがセットされている場合、プロテインの長さを計算するには、次の4バイトを読み取り、これらをビッグ・エンディアン、8バイト整数の上位バイトとして用いる(4バイトは既に読み取られ、下位部分を供給する)。リトル・エンディアン・フラグがセットされている場合、プロテインの中にある全ての二進数値データをリトル・エンディアンとして解釈する(それ以外の場合は、ビッグ・エンディアン)。非標準フラグ・ビットがセットされている場合、プロテインの残りの部分は、以下で説明する標準構造に従わない。
非標準プロテイン構造については、プロテインおよびプールを用いるシステム・プログラマには、非標準プロテイン・フォーマットを記述しこれに同期するための種々の方法が利用可能であること、そしてこれらの方法は、空間または計算サイクルが制限されているときに有用となることができることを除いて、ここではこれ以上論じない。例えば、一実施形態では、最短のプロテインは16バイトである。標準フォーマットのプロテインは、実際のペイロード・データをこれらの16バイトにはめ込むことは全くできない(その一番大きい部分は既に、プロテインのコンポーネント・パーツの位置を記述することが任されている)。しかし、非標準フォーマット・プロテインは、その16バイトの内12バイトをデータに用いることができると考えられる。2つのアプリケーションがプロテインを交換すると、これらが発信するいずれの16バイト長プロテインでも常に12バイトを含み、これらは、例えば、リアル・タイム・アナログ/ディジタル変換器からの12個の8ビット・センサ値を表すことを相互に決定することができる。
長さヘッダの直後には、プロテインの標準構造では、更に2つの可変長整数値が現れる。これらの数値は、それぞれ、ディスクリップ・リストにおける最初のエレメント、および最初のキー値対(インジェスト)に対するオフセットを指定する。これらのオフセットは、本明細書では、それぞれディスクリップ・オフセットおよびインジェスト・オフセットとも呼ぶ。これらの数値の各クアッド(quad)のバイト順序は、プロテイン・エンディアンネス・フラグ・ビット(protein endianness flag bit)によって指定される。各々について、最初の4バイトの最上位ビットは数値が4または8バイト幅のどちらであるかを決定する。最上位ビット(msb)がセットされている場合、最初の4バイトは二重ワード(8バイト)数値の最上位バイトとなる。ここでは、これを「オフセット形式」と呼ぶ。ディスクリップおよび対を指し示す別個のオフセットを用いることにより、ディスクリップおよび対を異なるコード・パスによって扱うことが可能となり、例えば、ディスクリップ・パターン照合およびプロテイン・アセンブリに関する個々の最適化を行うことができるようになる。また、これら2つのオフセットがプロテインの先頭にあるため、様々な有用な最適化に対処できる。
殆どのプロテインは8バイト長またはポインタを必要とする程大きくないので、一般に長さ(とフラグ)および2つのオフセット数値は、プロテインの最初の3バイトを占めるに過ぎない。多くのハードウェアまたはシステム・アーキテクチャでは、最初のバイトを超えるある数のバイトのフェッチ即ちリードは、「自由」である(例えば、16バイトは、セル・プロセッサ(Cell processor)の主要バスを介して引き込むには、1バイトと全く同じ数のクロック・サイクルを要する。)
多くの場合、プロテイン内部において実施態様特定またはコンテキスト特定のキャッシュ(caching)またはメタデータを許容することは有用である。オフセットの使用により、プロテインの先頭付近に、任意のサイズの「孔(hole)」を作成し、その中にこのようなメタデータを割り込ませることができる。8バイトのメタデータを利用することができる実施態様では、多くのシステム・アーキテクチャ上でこれらのバイトを、長さヘッダをフェッチする毎に1つのプロテインに対して自由に得ることができる。
ディスクリップ・オフセットは、プロテインの先頭と最初のディスクリップ・エントリとの間のバイト数を指定する。各ディスクリップ・エントリは、次のディスクリップ・エントリまでのオフセット(勿論、オフセット形態で)を備えており、その後に可変幅の長さフィールド(これもオフセット・フォーマットで)が続き、更にその後にスローが続く。これ以上ディスクリップがない場合、オフセットは、規則上、0の4バイトとなる。それ以外の場合、オフセットは、当該ディスクリップ・エントリの開始と次との間のバイト数を指定する。長さフィールドは、バイト単位で、スローの長さを指定する。
殆どのプロテインでは、各ディスクリップは、スロー・ストリング様式でフォーマットしたストリングであり、4バイトの長さ/タイプヘッダを有し、最上位ビットがセットされ、下位30ビットだけが長さを指定するために用いられ、その後に、ヘッダが指示する数のデータ・バイトが続く。通常通り、長さヘッダはそのエンディアンネスをプロテインから取り込む。バイトは、UTF−8キャラクタをエンコードすると仮定する(したがって、キャラクタ数は必ずしもバイト数と同じではないことを注記しておく)。
インジェスト・オフセットは、プロテインの先頭と最初のインジェスト・エントリとの間のバイト数を指定する。各インジェスト・エントリは、次のインジェスト・エントリまでのオフセット(オフセット・フォームで)を備えており、その後にこの場合も長さフィールドおよびスローが続く。インジェスト・オフセットは、次のディスクリップ・エントリの代わりに次のインジェスト・エントリを指し示すことを除いて、ディスクリップ・オフセットと機能的には同一である。
殆どのプロテインでは、各インジェストは、スロー・コンス・タイプ(slaw cons type)であり、二値リストを備えている。このリストは通常キー/値対として用いられる。スロー・コンス・レコードは、最上位から2番目のビットがセットされており、下位30ビットだけが長さを指定するために用いられる4バイトの長さ/タイプ・ヘッダと、4バイトの値(2番目)エレメントの先頭までのオフセットと、前述の4バイトのキー・エレメント長と、キー・エレメントに対するスロー・レコードと、4バイト長の値エレメントと、最後に前述の値エレメントに対するスロー・レコードとを備えている。
一般に、コンス・キーはスロー・ストリングである。数個のプロテインおよびスロー・コンス長ならびにオフセット・フィールドを跨いでデータを複製することにより、工夫(refinement)および最適化の一層多くの機会が得られる。
前述のように、類型に分けたデータをプロテイン内部に埋め込むために一実施形態において用いられる構造は、タグ付きのバイト・シーケンス指定および抽象化(abstraction)であり、「スロー」と呼ばれる(複数形は「slawx」となる)。スローは、類型に分けた(恐らくは、集計)データの一片を表すバイトの線形シーケンスであり、プログラミング言語特定APIと関連付けられている。APIは、スロークスを作成し、修正し、メモリ空間、記憶媒体、およびマシンの間で移動させることができる。スロー・タイプ方式(slaw type scheme)は、拡張可能でできるだけ軽量であり、あらゆるプログラミング言語からでも用いることができる共通基盤となることを意図している。
効率的な、大規模プロセス間通信メカニズムを構築することの要望が、スロー・コンフィギュレーションの原動力(driver)である。従来のプログラミング言語は、精巧なデータ構造およびタイプ機能を備えており、プロセス特定のメモリ・レイアウトでは申し分なく動作するが、データをプロセッサ間で移動させたり、ディスク上に格納することが必要となると、これらのデータ表現はいつでも決まって分解する。スロー・アーキテクチャは、第1に、プロセス間通信に対する、非常に効率的で、マルチ・プラットフォームに都合がよい低レベル・データ・モデルである。
しかし、更に一層重要なのは、スロークスが、プロテインと共に、今後の計算機ハードウェア(マイクロプロセッサ、メモリ・コントローラ、ディスク・コントローラ)の開発に影響を及ぼし、それを可能にするように構成されていることである。例えば、広く一般に入手可能なマイクロプロセッサの命令セットに、多少の具体的な追加を行うことにより、スロークスが、殆どのプログラミング言語において用いられている方式と同様に、単一プロセス、メモリ内データ・レイアウトに対しても効率的となることが可能になる。
各スローは、可変長のタイプ・ヘッダと、その後に続くタイプ特定データ・レイアウトとを備えている。例えば、C、C++、およびRubyにおけるスロー機能を全てサポートする実施形態の一例では、タイプは、各言語からアクセス可能なシステム・ヘッダ・ファイルにおいて定義されているユニバーサル整数(universal integer)によって示される。更に精巧化し柔軟性を高めたタイプ解明機能(type resolution functionality)、例えば、ユニバーサル・オブジェクトIDおよびネットワーク参照による間接的類型決定も可能である。
一実施形態のスロー・コンフィギュレーションは、スロー・レコードを、例えば、RubyおよびC++双方から言語に優しい様式でオブジェクトとして用いることを可能にする。C++コンパイラ外部の1組のユーティリティが、スロー・バイト・レイアウトの健全性をチェックし、個々のスロー・タイプに特定的なヘッダ・ファイルおよびマクロを作成し、Rubyに対するバインディング(binding)を自動的に発生する。その結果、正しく構成したスロー・タイプは、1つのプロセスの中から用いた場合でも、非常に効率的となる。プロセスのアクセス可能なメモリのいずれの場所におけるいずれのスローでも、コピーや「非直列化(deserialization)」ステップがなくても、アドレスすることができる。
一実施形態のスロー機能は、以下の内1つ以上を実行するAPI機能を含む。具体的なタイプの新たなスローを作成する。ディスク上またはメモリ内におけるバイトからのスローへの言語特定参照を作成または構築する。タイプに特定の様式でスロー内にデータを埋め込む。スローのサイズを問い合わせる。スロー内部からデータを引き出す。スローのクローンを作成する。そして、スロー内部にある全てのデータのエンディアンネスおよびその他のフォーマット属性を変換する。スローのあらゆる種(species)が以上の挙動を実施する。
図8Bは、一実施形態の下におけるスロー・ヘッダーのフォーマットを示す。以下にスローの詳細な説明を行う。
各スローの内部構造は、タイプ解明、カプセル化データへのアクセス、および当該スロー・インスタンスについてのサイズ情報の各々を最適化する。一実施形態では、1組のスロー・タイプ全体は、設計上、最小限の全てが揃っており、スロー・ストリング、スロー・コンス(即ち、ダイアッド(dyad))、スロー・リスト、およびスロー数値オブジェクトを含む。スロー数値オブジェクト自体は、半ダース程度の基本的な属性の組み合わせ(permutation)として理解される、広範な1組の個別数値タイプを表す。いずれのスローでも、その他の基本的プロパティはそのサイズである。一実施形態では、スロークスは、4の倍数に量子化したバイト長を有し、これらの4バイト・ワードを、ここでは「クアッド」と呼ぶ。一般に、このようなクアッドに基づくサイズ決定により、スロークスを最新のコンピュータ・ハードウェア・アーキテクチャのコンフィギュレーションと正確に整合させる。
一実施形態では、各スローの最初の4バイトは、ヘッダ構造を備えている。ヘッダ構造は、タイプ記述およびその他のメタ情報をエンコードし、特定的なタイプの意味を特定のビット・パターンに帰属させる(ascribe)。例えば、スロー・ヘッダの最初の(最上位)ビットは、そのスローのサイズ(クアッド・ワード単位の長さ)が最初の4バイトのタイプ・ヘッダに従うか否か指定するために用いることができる。このビットがセットされている場合、スローのサイズが当該スローの次の4バイト(例えば、バイト5から8まで)に明示的に記録されていることが分かる。スローのサイズが、4バイトでは表現できないような場合(即ち、サイズが2の32乗以上である場合)、スローの最初の4バイトの次の最上位ビットもセットする。これは、スローが8バイト(4バイトではなく)長を有することを意味する。その場合、検査プロセスが、序数バイト(ordinal byte)5から12までに格納されているスローの長さを発見する。他方で、スロー・タイプの数値が小さいことは、多くの場合、完全に指定した類型ビット・パターンが、4バイトのスロー・ヘッダにおける多くのビットを「未使用のまま残してある」ことを意味し、そのような場合、これらのビットは、スローの長さをエンコードするために用いてもよく、そうしなければ必要となるはずのバイト(5から8まで)を取っておくことができる。
例えば、一実施形態では、スロー・ヘッダの最上位ビット(「長さ従属」フラグ)をセットしないままにしておき、次のビットをセットして、そのスローが「微小コンス(wee cons)」であることを示し、この場合、スローの長さ(クアッド単位)を残りの30ビットにエンコードする。同様に、「微小ストリング」は、ヘッダにおけるパターン001によって印され、スロー・ストリングの長さを表すために、29ビットが残され、ヘッダにおける最初の0001が「微小リスト」を記述する。これは、28ビットの利用可能長表現ビットのために、サイズが2から28クアッドまでのスロー・リストとすることができる。「最大ストリング」(あるいはコンスまたはリスト)は、ヘッダに異なるビット・シグネーチャを有し、ヘッダの最上位ビットは必ずセットされる。何故なら、スロー長はバイト5から8(または、極端な場合には12)において別個にエンコードされるからである。尚、プラズマ実施態様は、スローの組立時に、これらの構造の「微小(wee)」バージョンまたは「最大(full)」バージョンのどちらを採用すべきか「決定する」(決定は、最終的なサイズが利用可能な微小ビットに「納まるか」否かに基づく)が、最大−対−微小の詳細は、プラズマ実施態様のユーザには隠されている。ユーザは、スロー・ストリング、またはスロー・コンス、またはスロー・リストを用いていることしか知らないし、そのことしか気に留めない。
一実施形態では、数値スロークスは、最初のヘッダ・パターン00001によって示される。後続のヘッダ・ビットは、任意の順列に組み合わせることができる1組の直交プロパティを表すために用いられる。一実施形態では、数値が(1)浮動小数点、(2)複素数、(3)符号なし、(4)「広い」、(5)「太くて短い」(stumpy)であるか否かを示すために、5つのこのようなキャラクタ・ビットを用いるが、これらに限定されるのではない((4)「広い」および(5)「太くて短い」の順序を変えて、8、16、32、および64ビット数表現を示す)。2つの追加ビット(例えば、(7)および(8))は、カプセル化した数値データが、2−、3−、または4−エレメント・ベクトルであることを示す(双方のビットが0の場合、数値が「1−エレメント・ベクトル」(即ち、スカラー)であることを示唆する)。この実施形態では、4番目のヘッダ・バイトの8ビットを用いて、カプセル化した数値データのサイズを(クアッド単位ではなく、バイト単位で)エンコードする。このサイズのエンコード処理は、1から256までの間のいずれのサイズでも表すことができるように、1だけずらされる。最後に、2つのキャラクタ・ビット(例えば、(9)および(10))を用いて、数値データが個々の数値エンティティの配列をエンコードすることを示す。数値エンティティの各々は、キャラクタ・ビット(1)から(8)までによって記述されるタイプのものである。アレイの場合、個々の数値エンティティには、各々、追加のヘッダがアペンドされず、1つのヘッダおよび恐らくは、明示的なスロー・サイズ情報に続く連続データとしてパックされる。
この実施形態では、単純かつ効率的なスローの複製(バイト毎のコピーとして実施することができる)、および非常に単純で効率的なスローの比較が可能となる(この実施形態では、連続と見なされる構成バイトの各々に1対1の一致がある場合に限って、2つのスロークスは同一となる)。後者のプロパティは、例えば、プロテイン・アーキテクチャの効率的な実現には重要である。その重要なそして波及する(pervasive)特徴は、プロテインのディスクリップ・リスト全体を検索できること、または「リスト上で照合」できることである。
更に、本明細書における実施形態は、集計スロー形態(例えば、スロー・コンスおよびスロー・リスト)を簡単かつ効率的に作成することを可能にする。例えば、一実施形態では、スロー・コンスを、いずれのタイプでもよく、これら自体集計を含む、2つの成分スロークスから次のように構築する。(a)各成分スローのサイズを問い合わせ、(b)2つの成分スロークスのサイズ、およびヘッダ・プラス・サイズ構造に必要な1、2、または3クアッドの和に等しいサイズのメモリを割り当て、(c)最初の4、8、または12バイトにスロー・ヘッダ(およびサイズ情報)を記録し、次いで(d)成分スロークスのバイトを順番に、直後に続くメモリにコピーする。重要なのは、このような組立ルーチンは、2つの成分スロークスのタイプについて何も知る必要がなく、それらのサイズ(そして、バイトのシーケンスとしてのアクセス可能性)だけが問題であることである。同じプロセスは、スロー・リストの作成にも関与する。スロー・リストは、(恐らくは)異質なタイプの任意の多くのサブ・スロークス(sub-slawx)の順序付けしたカプセル化である。
メモリにおける連続バイトとしてのスロー・システムの基本的フォーマットの更に別の成果が、「横断」(traversal)アクティビティと関連して得られる。反復使用パターンが、例えば、スロー・リストに格納されている個々のスロークスへの順次アクセスを用いる。プロテイン構造内部におけるディスクリップおよびインジェストを表す個々のスロークスも同様に横断しなければならない。このような操作は、驚く程単純かつ効率的な方法で遂行される。つまり、スロー・リストにおける次のスローに「進み」、現在のスローの長さをそのメモリ位置に追加し、結果的に得られたメモリ位置が、次のスローのヘッダと同一となる。このような簡素さが可能なのは、スローおよびプロテインの設計が「間接」を避けるからである。つまり、ポインタがなく、データは単純にその全体が本来の場所に存在する。
スロー比較の時点までに、プラズマ・システムの完全な実施態様は、異なるオペレーティング・システム、CPU、およびハードウェア・アーキテクチャに跨ってそしてこれらの間において、異なり互換性のないデータ表現方式の存在を承認しなければならない。このような相違の主要なものには、バイト順序付けポリシ(例えば、リトル−エンディアン対ビッグ−エンディアン)および浮動小数点表現が含まれ、その他の相違も存在する。プラズマ仕様では、スロークスによってカプセル化したデータが解釈可能である(interprable)(即ち、スローを検査している元のアーキテクチャまたはプラットフォームのネーティブ・フォーマットで現れなければならない)。この要件は、一方、プラズマ・システム自体がデータ・フォーマット変換の責任を負うことを意味する。しかしながら、仕様では、スローが、それを検査するかもしれない実行中のプロセスに対して「完全に可視」になる前に変換を行うことしか規定していない。したがって、どの時点でこのようなcフォーマット変換を実行するかを選択するのは、個々の実施態様次第となる。2つのしかるべき手法があり、それは、(1)個々のスローがパックされていたプロテインから「引き出す」際に、または(2)プロテインが入っていたプールからそのプロテインを抽出する際に、当該プロテインの中にあるスロー全てについて同時に、スロー・データ・ペイロードをローカル・アーキテクチャのデータ・フォーマットに準拠させることである。尚、変換規定は、ハードウェア補助実施態様の可能性も考慮することを注記しておく。例えば、明示的プラズマ能力によって構築したネットワーキング・チップセットは、受信システムの既知の特性に基づいて、インテリジェントにそして「送信の時点」にフォーマット変換を実行することを選択することができる。あるいは、送信のプロセスがデータ・ペイロードを基軸フォーマットに変換することもでき、受信プロセスは、対称的に基軸フォーマットから「ローカル」フォーマットに変換する。別の実施形態では、「メタル」において(at the metal)フォーマット変換を実行する。これが意味するのは、データは、ローカル・メモリの中であっても、常に基軸フォーマットで格納されており、データをメモリから引き出し隣接するCPUのレジスタに入れるときに、メモリ・コントローラ・ハードウェア自体が変換を実行する。
一実施形態の最小(そして読み取り専用)プロテインの実施態様は、プロテインを利用する1つ以上のアプリケーションまたはプログラミング言語における動作または挙動を含む。図8Bは、一実施形態の下でプロテインを用いるための流れ図850である。動作を開始すると、852においてプロテインの長さをバイト単位で問い合わせる。854において、ディスクリップ・エントリの数を問い合わせる。856において、インジェストの数を問い合わせる。858において、インデックス番号によってディスクリップ・エントリを引き出す。860において、インデックス番号によってインジェストを引き出す。
また、本明細書において記載する実施形態は、プロテインを作成してデータを充填させる基本的な方法、プログラマによって共通のタスクを容易に行えるようにするヘルパ方法、および最適化を遂行するためのフック(hook)も定める。図8Cは、一実施形態の下においてプロテインを作成する、即ち、発生するための流れ図870である。動作は、872における新たなプロテインの作成から開始する。874において、一連のディスクリップ・エントリをアペンドする。また、876においてインジェストもアペンドする。878において、一致するディスクリップの存在を問い合わせ、880において、一致するインジェスト・キーの存在を問い合わせる。インジェスト・キーが得られたなら、882において、インジェスト値を引き出す。884において、ディスクリップ全体でパターン照合を実行する。886において、プロテインの先頭付近に、非構造化メタデータを埋め込む。
前述のように、スロークスはプロセス間交換のための低レベルのデータ定義を規定し、プロテインは問い合わせおよびフィルタ処理のために中間レベルの構造およびフックを規定し、プールは高レベルの編成およびアクセス・セマンティックスについて規定する。プールは、プロテインのためのレポジトリであり、線形シーケンシング(linear sequencing)および状態キャッシング(state caching)に備えている。また、プールは、多数のプログラムまたは多数の異なる種類のアプリケーションによるマルチ・プロセス・アクセスにも備えている。更に、プールは、1組の共通な、最適化可能なフィルタ処理およびパターン照合挙動にも備えている。
一実施形態のプールは、数万ものプロテインを収容することができ、状態を維持するように機能することができるので、個々のプロセスはマルチ・プロセス・プログラム・コードに共通する厄介なブックキーピングの多くの負担を軽減することができる。プールは、利用可能な過去のプロテインの大きなバッファを維持または保持し、プラトニック・プール(Platonic pool)は明示的に無限であるので、関与するプロセスは、プールにおいて意のままに逆方向および順方向の双方に走査することができる。バッファのサイズは、実施態様に左右されるが、勿論、慣例的な仕様では、プロテインをプールの中に数時間または数日保持できることが多い。
本明細書において記載するプール使用の最も慣例的な様式では、既存のプロセス間通信フレームワークが採用する機械論的(mechanistic)二点間手法とは対照的に、生物的比喩に従う。プロテインという名称は、生物的発想を暗示する。生物組織における化学的蛋白質が、多数の細胞因子(cellular agent)によるパターン照合およびフィルタ処理に利用可能であるのと同様に、プールの中にあるデータ・プロテインは、多数の計算プロセスによる柔軟な問い合わせおよびパターン照合に利用可能である。
2つの付加的な抽象化が生物的比喩に同調し(lean)、「ハンドラ」の使用およびゴルジ・フレームワーク(Golgi framework)を含む。プールに関与するプロセスは、一般に、多数のハンドラを作成する。ハンドラは、比較的小さい1群のコードであり、照合条件をハンドル挙動と関連付ける。1つ以上のハンドラをプールに類別することにより、プロセスは、状態をカプセル化し新たなプロテインに反応する、柔軟なコール・バック・トリガ(call-back trigger)を設定する。
数個のプールに関与するプロセスは、一般に、抽象的ゴルジ・クラスから継承する。ゴルジ・フレームワークは、多数のプールおよびハンドラを管理するための多くの有用なルーチンを提供する。また、ゴルジ・クラスは、親−子関係もカプセル化し、プールを用いないローカル・プロテイン交換のためのメカニズムを提供する。
一実施形態の下で提供するプールAPIは、種々の方法でプールを実現し、システム特定の目標、ならびに所与のハードウェアおよびネットワーク・アーキテクチャの利用可能な処理能力双方を考慮に入れるように構成されている。プールが依存する2つの基礎的なシステムの常設機構(provision)は、記憶装置およびプロセス間通信手段である。本明細書において記載する、現存する(extant)システムは、共有メモリ、仮想メモリ、および記憶装置用ディスク、ならびにプロセス間通信のためのIPCキューおよびTCP/IPソケットの柔軟な組み合わせを用いる。
一実施形態のプールの機能には、限定ではなく、以下が含まれる。プールに関与する。プロテインをプールの中に入れる。次の未見プロテインをプールから引き出す。プール内の内容(例えば、プロテイン)を逆回しまたは早送りする。加えて、プールの機能には、限定ではなく、以下も含むことができる。プロセスに対するストリーミング・プール・コール・バックを設定する。ディスクリップまたはインジェスト・キーの特定のパターンと一致するプロテインを選択的に引き出す。ディスクリップまたはインジェスト・キーの特定のパターンと一致するプロテインについて逆方向および順方向に走査する。
前述のプロテインは、他のアプリケーションとプロテイン・データ・コンテンツを共有する方法として、プールに供給される。図9は、一実施形態の下において、スロークス、プロテイン、およびプールを用いたデータ交換を含む処理環境のブロック図である。この環境例は、前述のようにスロークス、プロテイン、およびプールの使用によりデータを共有する3つのデバイス(例えば、デバイスX、デバイスY、およびデバイスZ、ここでは纏めて「デバイス」と呼ぶ)を含む。これらのデバイスの各々は、3つのプール(例えば、プール1、プール2、プール3)に結合されている。プール1は、それぞれのデバイスから当該プールに提供または転送された多数のプロテイン(例えば、プロテインX1、プロテインZ2、プロテインY2、プロテインX4、プロテインY4)を含む(例えば、プロテインZ2は、デバイスZによってプール1に転送または提供された等)。プール2は、それぞれのデバイスから当該プールに提供または転送された多数のプロテイン(例えば、プロテインZ4、プロテインY3、プロテインZ1、プロテインX3)を含む(例えば、プロテインY3は、デバイスYによってプール2に転送または提供された等)。プール3は、それぞれのデバイスから当該プールに供給または転送された多数のプロテイン(例えば、プロテインY1、プロテインZ3、プロテインX2)を含む(例えば、プロテインX2は、デバイスXによってプール3に転送または提供された等)。前述の例では、3つのプール間に結合または接続されている3つのデバイスが含まれるが、あらゆる数のデバイスを、あらゆる数のプール間に如何様にでもまたはいずれの組み合わせでも結合または接続することができ、いずれのプールも、あらゆる数または組み合わせのデバイスから提供されるあらゆる数のプロテインを含むことができる。この例のプロテインおよびプールについては、図3から図8までを参照しながら先に説明した。
図10は、多数のデバイスと、これらのデバイスの1つ以上で起動する多数のプログラムを含む処理環境のブロック図であり、一実施形態の下において、プラズマ構造(plasma construct)(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、多数のデバイス(例えば、デバイスA、B等)およびこれらのデバイス上で起動する多数のプログラム(例えば、appsAA-AX、appsBA-BX等)を備えている双方向処理システムが、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。
この例では、各デバイス(例えば、デバイスA、B等)は、それぞれのデバイス上で走っているプログラム(例えば、appsAA-AX、appsBA-BX等)が発生したまたは出力された離散生データを、プラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入する。例えば、プログラムAXはデータまたは出力を発生し、この出力をデバイスAに供給する。一方、デバイスAはこの生データをプロテイン(例えば、プロテイン1A、プロテイン2A等)に変換し、これらのプロテインをプールに貯入する。別の例として、プログラムBCがデータを発生し、このデータをデバイスBに供給する。一方、デバイスBはこのデータをプロテイン(例えば、プロテイン1B、プロテイン2B等)に変換し、これらのプロテインをプールに貯入する。
各プロテインは、アプリケーションが発生し、プログラム自体についての情報を特定するデータまたは出力を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップは出力イベントまたは行動について一般的なセマンティックな意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード(例えば、インジェスト)は、プログラム・イベントについての1組の有用な状態情報全体を搬送する。
前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で起動しているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマ(consumer)を多重化し、デバイスを一人で制御できるように、または数人(例えば、プラズマ・ベースの入力フレームワークは、多くの同時ユーザをサポートする)で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに見えるようになることである。
一例として、デバイスCは1つ以上のプロテイン(例えば、プロテイン1A、2A等)をプールから抽出することができる。プロテインの抽出に続いて、デバイスCは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、プロテイン・データが対応する処理イベントにおいて用いることができる。別の例として、デバイスBは、プールから1つ以上のプロテイン(例えば、プロテイン1C、プロテイン2A等)を抽出することができる。プロテインの抽出に続いて、デバイスBは、プロテイン・データが対応する処理イベントにおいて、プロテインのデータを用いることができる。
プールに結合または接続されているデバイスおよび/またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
図11は、多数のデバイスと、これらのデバイスの1つ以上で起動する多数のプログラムを含む処理環境のブロック図であり、一代替実施形態の下において、プラズマ構造(plasma construct)(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、多数のデバイス(例えば、デバイスAおよびBにそれぞれ結合されているデバイスXおよびY)および1つ以上のコンピュータ(例えば、デバイスA、デバイスB等)上で起動する多数のプログラム(例えば、appsAA-AX、appsBA-BX等)を備えている双方向処理システムが、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有し、集合的にこれらのイベントに応答することを可能にする。
この例では、各デバイス(例えば、デバイスAおよびBにそれぞれ結合されているデバイスXおよびY)は、デバイス・ハードウェア(例えば、デバイスX、デバイスA、デバイスY、デバイスB等)が発生した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス(例えば、デバイスA、デバイスB等)上にホストされている1つ以上のプログラムの下で、またはこれらと連携して動作するように管理および/または結合されている。例えば、デバイスA上にホストされているアプリケーションABと連携して動作するデバイスXは、生データを発生し、この離散生データをプロテイン(例えば、プロテイン1A、プロテイン2A等)に変換し、これらのプロテインをプールに貯入する。別の例として、デバイスA上にホストされているアプリケーションATと連携して動作するデバイスXが、離散生データをプロテイン(例えば、プロテイン1A、プロテイン2Aなど)に変換し、これらのプロテインをプールに貯入する。更に別の例として、デバイスC上にホストされているアプリケーションCDと連携して動作するデバイスZは、生データを発生し、この離散生データをプロテイン(例えば、プロテイン1C、プロテイン2C等)に変換し、これらのプロテインをプールに貯入する。
各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的なセマンティックな意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード(例えば、インジェスト)は、デバイス・イベントについての1組の有用な状態情報全体を搬送する。
前述のように、プロテインは、プログラムまたはデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが使用するために、プールにおいて利用可能となっている。したがって、あらゆる数のコンピュータ上で起動しているあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出することができる。これらのデバイスは、プールからプロテインを抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、処理イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人(例えば、プラズマ・ベースの入力フレームワークは、多くの同時ユーザをサポートする)で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。
プールに結合または接続されているデバイスおよび/またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
図12は、多数の入力デバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、別の代替実施形態の下において、プラズマ構造(plasma construct)(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、入力デバイスによって発生したイベントを共有し、集合的に応答することを可能にする。このシステムは、マルチ・ユーザ、マルチ・デバイス、マルチ・コンピュータ双方向処理制御状況または構成の一例に過ぎない。更に特定すれば、この例では、双方向処理システムは、多数の入力デバイス(例えば、入力デバイスA、B、BA、およびBB等)を備えており、1つ以上のコンピュータ(例えば、デバイスA、デバイスB等)上で起動する多数のプログラム(図示せず)を備えており、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いて、実行中のプログラムが、これらの入力デバイスによって発生したイベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。
この例では、各入力デバイス(例えば、入力デバイスA、B、BA、およびBB等)は、入力デバイス・ハードウェアが発生した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールに貯入するそれぞれのデバイス(例えば、デバイスA、デバイスB等)上にホストしたソフトウェア・ドライバ・プログラムによって管理される。例えば、入力デバイスAは生データを発生し、この生データをデバイスAに供給する。一方、デバイスAは離散生データをプロテイン(例えば、プロテイン1A、プロテイン2A等)に変換し、これらのプロテインをプールに貯入する。別の例として、入力デバイスBBは生データを発生し、この生データをデバイスBに供給する。一方、デバイスBは離散生データをプロテイン(例えば、プロテイン1B、プロテイン3B等)に変換し、これらのプロテインをプールに貯入する。
各プロテインは、入力デバイスが登録し、デバイス自体についての情報を特定する行動を指定するディスクリップ・リストを収容する。可能な場合には、プロテイン・ディスクリップはデバイスの行動について一般的なセマンティックな意味(semantic meaning)を認めることもできる。プロテインのデータ・ペイロード(例えば、インジェスト)は、デバイス・イベントについての1組の有用な状態情報全体を搬送する。
例示のために、ここに、このようなシステムにおける2つの典型的なイベントに対するプロテインを示す。ここでは、プロテインはテキストとして表すが、実際の実施態様では、これらのプロテインの構成部分は、類別されたデータ・バンドル(例えば、スロー)である。g-speak "one finger click" pose(「指1本によるクリック」のポーズ)(関連出願に記載されている)を記述するプロテインは、次の通りである。
Figure 0005805537


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


以上のプロテインの見本のいずれかまたは双方は、そのコードの特定の部分を起動させるホスト・デバイスの関与プログラム(participating program)を生ずる可能性もある。これらのプログラムは、一般的なセマンティック・レベルに関係する場合がある。全ての内最も一般的なのは「point」であり、更に具体的な対は「engage, one」である。また、これらは、正確なデバイス:「one-finger-engage」または正に1つの集計オブジェクト(aggregate object)「hand-id-23」のみによってもっともらしく発生されるイベントを求めている場合もある。
前述のように、プロテインは、プログラムやデバイスの種類には関係なく、プールに結合または接続されているあらゆるプログラムまたはデバイスが用いるために、プールにおいて利用可能である。したがって、あらゆる数のコンピュータ上で起動するあらゆる数のプログラムでも、入力プールからイベント・プロテインを抽出する。これらのデバイスは、プロテインをプールから抽出するためには、ローカル・メモリ・バスまたはネットワーク接続のいずれかを通じて、プールに関与することができるだけでよい。これによって即座に得られる結果は、イベントを使用または解釈するプロセスから、入力イベントを発生する役割を担うプロセスを切断できるという利点である。別の結果は、イベントのソースおよびコンシューマを多重化し、入力デバイスを一人で制御できるように、または数人(例えば、プラズマ・ベースの入力フレームワークは、多くの同時ユーザをサポートする)で同時に用いることができるようにしつつ、結果的に得られるイベント・ストリームは多数のイベント・コンシューマに順に見えるようになることである。
プロテイン使用の一例として、デバイスCは1つ以上のプロテイン(例えば、プロテイン1B等)をプールから抽出することができる。プロテイン抽出に続いて、デバイスCは、ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを、当該プロテイン・データが対応する入力デバイスCAおよびCCの入力イベントを処理する際に用いることができる。別の例として、デバイスAは、1つ以上のプロテイン(例えば、プロテイン1B等)をプールから抽出することができる。プロテインの抽出に続いて、デバイスAは、プロテイン・データが対応する入力デバイスAの入力イベントを処理する際に、当該プロテインのデータを用いることができる。
プールに結合または接続されているデバイスおよび/またはプログラムは、プロテインの特定のシーケンスを求めて、プールの中を逆方向および順方向に進む(skim)こともできる。これは、例えば、ある種のパターンと一致するプロテインの出現を待ち、次いで逆方向に進み、このプロテインがある種の他のものと共に出現したか否か判断するようにプログラムを設定する際に、有用となる場合が多い。この入力プールに格納されているイベント履歴を利用する装置は、多くの場合、状態管理コードの書き込みを不要としたり、少なくともこのような望ましくない符号化パターンに対する依存を著しく低減する。
本明細書において記載するシステムの実施形態に用いられる入力デバイスの例には、ジェスチャ入力センサ、キーボード、マウス、消費者電子機器において用いられるような赤外線リモコン装置、およびタスク指向有体媒体オブジェクト(task-oriented tangible media object)、その他にも数多く含まれる。
図13は、多数のデバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)(例えば、プール、プロテイン、およびスロー)を用いることにより、多数の実行中のプログラムが、デバイスによって発生したグラフィクス・イベントを共有し、集合的に応答することを可能にする。このシステムは、多数の実行中のプログラム(例えば、グラフィクスA〜E)および1つ以上のディスプレイ・デバイス(図示せず)を備えているシステムの一例に過ぎず、プログラムの一部または全部のグラフィック出力が、プラズマ構造(例えば、プール、プロテイン、およびスロー)を用いて、調整しながら他のプログラムにも利用可能とし、実行中のプログラムが、これらのデバイスによって発生したグラフィック・イベントを共有すること、および集合的にこれらのイベントに応答することを可能にする。
コンピュータ・プログラムが、別のプログラムによって発生したグラフィクスを表示することが有用な場合は多い。広く知れ渡っている様々な例には、テレビ会議アプリケーション、ネットワークを用いたスライドショーおよびデモ・プログラム、ならびにウィンドウ・マネージャが含まれる。この構成の下では、プールは、ビデオ、ネットワーク・アプリケーション共有、およびウィンドウ管理をカプセル化したフレームワークを一般化して実施するためにプラズマ・ライブラリとして用いられ、プログラマは、このようなプログラムの現バージョンでは一般には入手できない多数の特徴に追加することが可能になる。
プラズマ合成環境において起動するプログラム(例えば、グラフィクスA〜E)は、プールへの結合および/または接続を通じて、調整プールに関与する。各プログラムは、種々の種類のグラフィック・ソースの可用性を示すために、そのプールにプロテインを貯入する。また、グラフィックスを表示するために利用可能なプログラムも、それらの表示処理能力、セキュリティおよびユーザ・プロファイル、ならびに物理的位置およびネットワーク位置を示すために、プロテインを貯入する。
また、グラフィクス・データをプールを通じて送信することもでき、あるいは表示プログラムに、他の種類(例えば、RTSPストリーム)のネットワーク・リソースを指し示させることもできる。「グラフィクス・データ」という用語は、本明細書において用いる場合、広義の連続体(broad continuum)に沿って存在する種々の異なる表現のことを指し、グラフィクス・データの例には、文字で表現される例(例えば、「画像」、または画素のブロック)、手順的例(例えば、典型的なopenGLパイプラインを下って行くような一連の「描画」指令)、および記述的例(例えば、幾何学的変形、クリッピング、および合成動作によって他のグラフィック構造を組み合わせる命令)が含まれるが、これらに限定されるのではない。
ローカル・マシン上では、グラフィクス・データは、プラットフォーム特定の表示ドライバ最適化を通じて配信することもできる。プールを通してグラフィクスを送信しない場合でも、多くの場合、周期的な画面キャプチャは、調整プールに格納されるので、より内部(esoteric)のソースに直接アクセスできないクライアントであっても、フォールバック・グラフィクス(fall-back graphics)を表示することもできる。
本明細書において記載するマルチプロセス・インタラクティブ・システムは、殆どのメッセージ伝達フレームワークおよびネットワーク・プロトコルとは異なり、プールがデータの大量のバッファを維持することである。したがって、プログラムはプールの中に逆戻りして、アクセスおよび使用パターン(調整プールの場合)を見たり、以前のグラフィクス・フレーム(グラフィクス・プールの場合)を抽出することができる。
図14は、多数のデバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、更に別の代替実施形態の下において、プラズマ構造(plasma construct)(例えば、プール、プロテイン、およびスロー)を用いることにより、実行中のプログラムの状態検査、可視化、およびデバッグ処理を可能にする。このシステムは、多数のデバイス(例えば、デバイスA、デバイスB等)上に多数の実行プログラム(例えば、プログラムP−A、プログラムP−B等)を備えており、一部のプログラムがプールを用いてまたはプールを通じて他のプログラムの内部状態にアクセスするシステムの一例に過ぎない。
殆どの双方向処理コンピュータ・システムは、多くのプログラムを備えており、これらは、1台のマシンまたは多数のマシン上で互いに一緒に起動し、ネットワークを跨いで双方向処理を行う。実行時データが各プロセス内部に隠されアクセスするのが困難なので、マルチ・プログラム・システムは、構成設定、分析、およびデバッグするのが難しい。本明細書において記載する一実施形態の一般化したフレームワークおよびプラズマ構造は、実行中のプログラムがプールを通じてそれらのデータの多くを利用可能にするので、他のプログラムがそれらの状態を検査することができる。このフレームワークによって、従来のデバッガよりも柔軟なデバッギング・ツール、精巧なシステム保守ツール、および1つまたは複数のプログラムが通過した一連の状態を、人の操作者に詳細に分析させるように構成された可視化ハーネスを可能にする。
図14を参照すると、このフレームワークにおいて起動するプログラム(例えば、プログラムP−A、プログラムP−B等)は、プログラムの起動時にプロセス・プールを発生または作成する。このプールは、システム・アルマナックに登録され、セキュリティおよびアクセス制御が適用される。更に特定すると、各デバイス(例えば、デバイスA、B等)が、それぞれのデバイス上で起動するプログラム(例えば、プログラムP−A、プログラムP−B等)が発生または出力した離散生データをプラズマ・プロテインに変換し、これらのプロテインをプラズマ・プールの中に貯入する。例えば、プログラムP−Aは、データまたは出力を発生し、この出力をデバイスAに供給する。一方、デバイスAは、この生データをプロテイン(例えば、プロテイン1A、プロテイン2A、プロテイン3A等)に変換し、これらのプロテインをプールの中に貯入する。別の例として、プログラムP−Bはデータを発生し、このデータをデバイスBに供給する。一方、デバイスBは、データをプロテイン(例えば、プロテイン1B〜4B等)に変換し、これらのプロテインをプールの中に貯入する。
プログラムの寿命の期間中、十分なアクセス許可を有する別のプログラムがプールに接続し(attach)、プログラムが貯入したプロテインを読み取ることもできる。これは、基本的な検査様式を表し、概念的に「一方向」即ち「読み取り専用」の提案(proposition)である。プログラムP−Aに関与するエンティティが、そのプロセス・プールの中にP−Aによって貯入されたステータス情報の流れを検査する。例えば、デバイスCの下で起動する検査プログラムまたはアプリケーションが1つ以上のプロテイン(例えば、プロテイン1A、プロテイン2A等)をプールから抽出することができる。プロテインの抽出に続いて、デバイスCは、ディスクリップのスローおよびプロテインのインジェストから引き出した即ち読み出したプロテインのデータを用いて、プログラムP−Aの内部状態にアクセスし、これを解釈し、検査することができる。
しかし、プラズマ・システムは単に効率的なステートフル(stateful)伝送方式であるだけでなく、全方向メッセージング環境であることを思い起こすと、様々な追加モードがプログラム対プログラムの状態検査をサポートする。許可された検査プログラムは、それ自体でプロテインをプログラムPのプロセス・プールに貯入して、生成してそのプロセス・プールの中に入れた状態情報の特性に影響を及ぼし、これらの特性を制御することができる(結局、プログラムPはプロセス・プールに書き込むだけでなく、そこから読み取りも行う)。
図15は、多数のデバイスを含み、これらが当該デバイスの1つ以上で起動する多数のプログラム間に結合されている処理環境のブロック図であり、追加の代替実施形態の下において、プラズマ構造(plasma construct)(例えば、プール、プロテイン、およびスロー)を用いることにより、当該プロセス・プールにおいて生成し配置された状態情報の特性に影響を及ぼすまたは制御することができる。このシステム例では、デバイスCの検査プログラムは、例えば、プログラム(例えば、プログラムP−A、プログラムP−B等)が、1回だけまたは特定の期間にわたって、通常よりも多い状態をプールにダンプすることを要求することができる。または、デバッグ通信の次の「レベル」を予示しておくと、関与するプログラムは、プログラム(例えば、プログラムP−A、プログラムP−B等)が、デバッグ・プールを通じた双方向処理が個々に可能でありそのために利用可能な、その実行時間環境において残存するオブジェクトを一覧に纏めたプロテインを放出(emit)することを要求することができる。このように通知すると、関与するプログラムはプログラムの実行時においてオブジェクトの中の個々に「アドレス」し、特定のオブジェクトだけが専有し応答するプロセス・プールにプロテインを入れることができる。関与するプログラムは、例えば、オブジェクトが、その成分変数全ての瞬時値を記述した報告プロテインを放出することを要求することもあり得る。それよりも更に重要なのは、関与するプログラムが、他のプロテインを通じて、オブジェクトにその挙動またはその変数の値を変更するように指令できることである。
更に具体的には、この例では、デバイスCの検査アプリケーションが、プールの中に、オブジェクト・リスト(例えば、「要求−オブジェクト・リスト」)の要求を(プロテインの形態で)入れて、次いでこのプールに結合されている各デバイス(例えば、デバイスA、デバイスB等)が抽出する。要求に応答して、各デバイス(例えば、デバイスA、デバイスB等)がプールの中に、その実行時環境において残存する、デバッグ・プールを通じて個々に検査することができそのために利用可能なオブジェクトを一覧に纏めたプロテイン(例えば、プロテイン1A、プロテイン1B等)を入れる。
このようにデバイスからのリストを通じて通知され、オブジェクトのリストに応答して、デバイスCの検査アプリケーションは、プログラム実行中におけるオブジェクトの中の個々にアドレスし、特定のオブジェクトのみが専有し応答するプロセス・プールにプロテインを入れる。デバイスCの検査アプリケーションは、例えば、要求プロテイン(例えば、プロテイン「要求報告P−A−O」、「要求報告P−B−O」)を、オブジェクト(例えば、それぞれ、オブジェクトP−A−O、オブジェクトP−B−O)が、その成分変数の全ての瞬時値を記述する報告プロテイン(例えば、プロテイン2A、プロテイン2B等)を放出するプールに入れる。各オブジェクト(例えば、オブジェクトP−A−O、オブジェクトP−B−O)は、その要求(例えば、それぞれ、プロテイン「要求報告P−A−O」、「要求報告P−B−O」)を抽出し、それに応答して、要求された報告(例えば、それぞれ、プロテイン2A、プロテイン2B)を含むプールにプロテインを入れる。次いで、デバイスCは種々の報告プロテイン(例えば、プロテイン2A、プロテイン2B等)を抽出し、適宜報告の内容に合わせて続く処理アクションを実行する。
このように、プラズマを相互交換媒体として用いると、デバッグ処理、プロセス制御、ならびにプログラム対プログラムの通信および調整の間にある区別を究極的に解消し易くなる。
このため、一般化したプラズマ・フレームワークは、疎結合の様式で可視化および分析プログラムを設計することを可能にする。例えば、メモリ・アクセス・パターンを表示する可視化ツールは、基本的なメモリ・リードおよびライトをプールに出力するいずれのプログラムとでも合わせて用いることができる。分析を受けるプログラムは、可視化ツールの存在や設計を知る必要がなく、その逆も成り立つ。
以上のようにプールを用いると、システム性能に不当に影響を及ぼすことはない。例えば、実施形態は、毎秒数十万個のプロテインをプールに貯入することを考慮しているので、比較的冗漫なデータ出力を可能にしても、殆どのプログラムの応答性や双方向処理特性を著しく阻害することはない。
空間動作環境(SOE)
マルチプロセス・インタラクティブ・システムは、空間動作環境(SOE)の構成要素であること、またはこれと共に用いるために結合することができる。SOEは、ジェスチャ制御システムまたはジェスチャ基準制御システムを含み、空間ユーザ・インターフェース(SUI)または空間インターフェース(SI)と呼ぶこともできる。一例として、図16は、一実施形態の下における空間動作環境(SOE)のブロック図である。ユーザは、彼の手1601および1602を、カメラ1604A〜1604Dのアレイの視野に置く。これらのカメラは、指ならびに手1601および1602の位置、方位、および移動を検出し、出力信号をプリプロセッサ1605に発生する。プリプロセッサ1605は、カメラ出力をジェスチャ信号に変換し、このジェスチャ信号をシステムのコンピュータ演算装置1607に供給する。コンピュータ1607は、入力情報を用いて、1つ以上の画面上カーソルを制御するコマンドを発生し、ビデオ出力をディスプレイ1603に供給する。
このシステムでは、一人のユーザの手を入力として示すが、SOEは、多数のユーザを用いても実施することができる。加えて、手の代わりにまたは手に加えて、本システムはユーザのボディの任意の1つ以上の部分を追跡することができ、その部分とは、頭部、足、脚部、腕、肘、膝等を含む。
図示の実施形態では、4台のカメラまたはセンサを用いて、視野1650内においてユーザの手1601および1602の位置、方位、および移動を検出する。SOEの範囲や主旨から逸脱することなく、SOEはこれらよりも多いカメラ(例えば、6台のカメラ、8台のカメラ等)または少ないカメラ(例えば、2台のカメラ)とでも用いることができることは言うまでもない。加えて、実施形態例では、カメラまたはセンサは対称的に配置されているが、SOEにはこのような対称性の要件はない。ユーザの手の位置、方位、および移動を許容するのであれば、カメラまたはセンサは、いずれの数および位置付けでも、SOEにおいて用いることができる。
一実施形態では、用いられるカメラは、グレー・スケール画像を取り込むことができるモーション・キャプチャ・カメラである。一実施形態では、用いられるカメラは、Vicon MX40カメラのような、Vicon社が製造するカメラである。このカメラは、カメラ内部処理を含み、毎秒1000フレームの画像取り込みが可能である。モーション・キャプチャ・カメラは、マーカを検出し位置を突き止めることができる。
記載している実施形態では、カメラは光学的検出に用いられるセンサである。他の実施形態では、カメラまたは他の検出器は、電磁、静磁気、RFID、またはその他の任意の適した種類の検出に用いることができる。
プリプロセッサ1605は、三次元空間点再現および骨格点ラベリングを発生するために用いられる。ジェスチャ変換器1606は、3D空間情報およびマーカ・モーション情報をコマンド言語に変換するために用いられる。コマンド言語は、コンピュータ・プロセッサによって解釈され、ディスプレイ上におけるカーソルの位置、形状、および動作(action)を更新することができる。SOEの代替実施形態では、プリプロセッサ1605およびジェスチャ変換器1606を組み合わせて1つのデバイスにすることもできる。
コンピュータ1607は、Apple社、Dell社、または任意のその他の適した製造業者によって製造されるような、任意の汎用コンピュータとすればよい。コンピュータ1607は、アプリケーションを起動し、表示出力を供給する。カーソル情報は、他の場合にはマウスまたはその他の先行技術の入力デバイスから得られるが、ここではジェスチャ・システムから得られる。
SOEまたは一実施形態は、ユーザの1つ以上の指においてマーカ・タグの使用を想定し、本システムがユーザの手を突き止め、ユーザが左または右のどちらの手を見ているのか特定し、どの指が見えるか特定することができるようにする。これによって、本システムは、ユーザの手の位置、方位、および移動を検出することが可能になる。この情報によって、本システムは多数のジェスチャを認識することが可能となり、これらのジェスチャは、ユーザによってコマンドとして用いることが可能になる。
一実施形態では、マーカ・タグは基板(本実施形態では、人の手の上の種々の位置に装着するのに適している)と、基板の表面上に一意識別パターンで配列された離散マーカとを備えている物理的タグである。
マーカおよび連携する外部検知システムは、それらの三空間位置の高精度、正確、ならびに迅速および連続的捕獲が可能である任意のドメイン(光学、電磁、静磁気等)において動作することができる。マーカ自体は、能動的(例えば、構造化した電磁パルスを放出することによって)、または受動的(例えば、本実施形態におけるように光学的に逆反射型とすることによって)のいずれでも動作することができる。
各捕獲フレームにおいて、検出システムは、器具を備え付けた作業空間立体(カメラまたはその他の検出器の可視範囲内)において現在タグからの全てのマーカを含む三空間位置を再現した、粒団状「クラウド」を受ける。各タグ上のマーカは、十分に多数であり、一意のパターンに配列されているので、検出システムは以下のタスクを行うことができる。(1)再現した各マーカ位置を、1つのタグを形成する点の1つのみの副集合体に割り当てるセグメント化、(2)セグメント化した点の各副集合体を特定のタグとして識別するラベリング、(3)識別したタグの三空間位置を再現する位置突き止め、および(4)識別したタグの三空間方位を再現する方位決定(orientation)。タスク(1)および(2)は、マーカ・パターンの具体的な本質によって可能となる。これについては、図17の一実施形態において以下で説明し例示する。
一実施形態では、タグ上のマーカは、規則的な格子位置の部分集合に装着されている。この基礎となる格子は、本実施形態のように、従来からのデカルト型であってもよいし、代わりに、他の何らかの規則的平面碁盤目状(例えば、三角形/六角形タイリング配列)であってもよい。格子のスケールおよび空間は、隣接する格子位置が混乱する可能性がないように、マーカ検知システムの既知の空間分解能に関して確定する。全てのタグについてのマーカ・パターンの選択は、次の制約を満たさなければならない。タグのパターンは、回転、平行移動、または鏡像のいずれの組み合わせによる他のいずれのタグ・パターンとも一致してはならない。更に、ある指定した数のコンポーネント・マーカの損失(または遮蔽(occlusion)が許容されるように、多数のマーカおよびその配列を選択するとよい。いずれの任意の変換後であっても、損なったモジュール(compromised module)を他のいずれとも混同させることが起こりそうにないようにしなければならない。
ここで図17を参照すると、多数のタグ1701A〜1701E(左手)および1702A〜1702E(右手)が示されている。各タグは、矩形であり、本実施形態では、5×7の格子アレイで構成されている。矩形形状が選択されたのは、タグの方位を決定し易いため、そして鏡面複製(mirror duplicate)の可能性を低減するためである。図示の実施形態では、各手の指毎にタグがある。実施形態によっては、手毎に1つ、2つ、3つ、または4つのタグを用いることが適当である場合もある。各タグは、異なるグレー・スケールまたは色調の境界を有する。この境界の内部には、3×5格子アレイがある。マーカ(図17の黒いドットで表す)は、情報を提供するために、この格子のある点に配置されている。
各パターンを「共通」および「一意」のサブパターンにセグメント化することにより、タグのマーカ・パターンにおいて、認定情報(qualifying information)をエンコードすることができる。例えば、本実施形態は、2つの可能な「境界パターン」、矩形境界線(boundary)を中心としたマーカの分布を指定する。つまり、タグの「ファミリー」を確立する。このため、左手を意図したタグは、タグ1701A〜1701Eにおいて示されるような同じ境界パターンを全て用いることができ、一方右手の指に取り付けられているタグには、タグ1702A〜1702Eに示すように異なるパターンを割り当てることができる。タグの全ての方位において、左パターンを右パターンから区別できるように、このサブパターンを選択する。図示した例では、左手パターンは、各角に1つのマーカ、そして角格子位置から2番目に1つのマーカを含む。右手パターンは、2つの角のみにマーカを有し、角でない格子位置に2つのマーカを有する。このパターンを検査することによって、4つのマーカの内いずれか3つが見ることができる限り、左手パターンを右手パターンから明確に区別することができることが明らかとなった。一実施形態では、境界の色または色調も、利き手(handedness)のインディケータとして用いることができる。
各タグは、勿論、一意の内部パターンを採用し続けなければならず、マーカはそのファミリーの共通境界以内に分散されている。図示の実施形態では、内部格子アレイにおける2つのマーカが、10本の指の各々を一意に特定するのに十分であり、指の回転または方位による複製が生じないことが分かる。マーカの1つが遮蔽されたとしても、タグのパターンおよび利き手の組み合わせから、一意の識別子が得られる。
本実施形態では、格子の位置は、各逆反射マーカをその意図する位置に装着する(手作業の)タスクに対する補助として、視覚的に剛性基板上に存在する。これらの格子および意図するマーカ位置は、カラー・インクジェット・プリンタによって基板上にそっくりそのまま印刷される。ここでは、基板はシート状の(初期状態では)可撓性の「収縮フィルム」である。各モジュールがこのシートから切り離され、炉で焼成される。この熱処理の間に、各モジュールには正確で繰り返し可能な収縮が起こる。この手順に続く短い間隔において、冷却するタグには、例えば、指の長手方向曲線にしたがって、僅かに形状を付けることができる。その後、基板は適度に剛性となり、マーカを、指示された格子点に装着することができる。
一実施形態では、マーカ自体は、接着剤または何らかのその他のしかるべき手段によって基板に装着された小さな反射球体のように、三次元である。このマーカが三次元であることは、二次元マーカ上における検出および位置突き止めに役立つことができる。しかしながら、いずれも、本明細書に記載するSOEの主旨や範囲から逸脱することなく用いることができる。
現在では、タグはベルクロまたはその他のしかるべき手段によって、操作者が身に付けている手袋に装着されるか、あるいは、柔らかな両面テープを用いて操作者の指に直接装着される。第3実施形態では、剛性基板を全くなしで済ませ、操作者の指および手に直接個々のマーカを装着するまたは「描く」することができる。
SOEは、手のポーズ、方位、手の組み合わせ、および方位の配合(orientation blends)で構成されるジェスチャ・ボキャブラリ(gesture vocabulary)を想定する。SOEのジェスチャ・ボキャブラリにおいてポーズおよびジェスチャを立案および伝達するために、表記言語(notation language)も実施する。ジェスチャ・ボキャブラリとは、力学的連結の瞬時的な「ポーズ状態」を簡潔な文字形態で表すシステムである。対象となる連結は、生物(例えば、人の手、または人のボディ全体、あるいはバッタの足、あるいはキツネザルの関節脊柱)であってもよく、あるいは代わりに非生物であってもよい(例えば、ロボットのアーム)。いずれの場合でも、この連結は、単純(脊柱)でもまたは分岐(手)でもよい。SOEのジェスチャ・ボキャブラリ・システムは、いずれの特定的な連結についても、一定長のストリングを確立する。こうして、ストリングの「キャラクタ位置」を占める特定のASCIIキャラクタの集合体が、連結の瞬時的状態、即ち、「ポーズ」の一意の記述となる。
図18は、SOEを用いたジェスチャ・ボキャブラリの一実施形態における手のポーズを示す。SOEは、1本の手における5本の指の各々を用いることを仮定する。これらの指には、p−小指、r−薬指、m−中指、i−人差し指、およびt−親指とコーディングする。指および親指の多数のポーズを、一実施形態のジェスチャ・ボキャブラリにおいて定義し例示する。ジェスチャ・ボキャブラリ・ストリングは、連結(この場合指)の表現可能な自由度毎に1つのキャラクタ位置を確定する。更に、このような各自由度は、離散化(または「量子化」)されていることが分かるので、その最大運動範囲は、当該ストリング位置における有限数の標準的ASCIIキャラクタの内の1つの割り当てによって表現することができる。これらの自由度は、ボディ特定の原点および座標系(手の裏、バッタのボディの中心、ロボット・アームの底辺等)に関して表現される。したがって、連結の位置および方位を「全体的に」更に大域的な座標系において表現するために、少数の追加のジェスチャ・ボキャブラリ・キャラクタ位置が用いられる。
引き続き図18を参照すると、多数のポーズが定義されており、ASCIIキャラクタを用いて識別されている。これらのポーズの一部は、親指およびそれ以外の指の間で分けられている。この実施形態におけるSOEは、ASCIIキャラクタ自体がポーズを示唆するようなコーディングを用いる。しかしながら、示唆的であろうがなかろうが、ポーズを表すには、いずれのキャラクタでも用いることができる。加えて、本発明では、表記ストリングにASCIIキャラクタを用いる必要性はない。本発明の範囲や主旨から逸脱することなく、適したシンボル、数値、またはその他の表現であればいずれでも用いることができる。例えば、望ましければ、表記は指毎に2ビットを用いることもでき、あるいは所望に応じて、他の何らかの数のビットを用いることもできる。
巻き込んだ指(curled finger)は、キャラクタ「^」によって表され、一方巻き込んだ親指は「>」で表される。真っ直ぐな指または上を向いた親指は、「l」によって示され、角度をなす場合は「\」または「/」で示される。「−」は、真っ直ぐに横を向いた親指を表し、「x」は平面内に向いた親指を表す。
これら個々の指および親指の記述を用いると、確固不動の数(robust number)の手のポーズを、本発明の方式を用いて、定義し記述することができる。各ポーズは、5つのキャラクタによって表され、その順序は、前述したように、p−r−m−i−tとなる。手を平らにして地面に平行に保持する場合、「lllll」で表される。握り拳は「^^^^>」によって表される。「OK」の合図は、「lll^>」によって表される。
キャラクタ・ストリングは、示唆的キャラクタを用いる場合、単純な「人間可読性」(human readabiity)の機会を与える。各自由度を記述する1組の可能なキャラクタは、総じて、素早い認識および明白な類似性に着目して選択することができる。例えば、垂直線(「|」)は、連結エレメントが「直線状」であることを意味するように思われ、エル(「L」)は、90度の屈曲を意味することもでき、曲折アクセント記号(「^」)は、鋭角の屈曲を示すことができる。先に注記したように、所望に応じて、いずれのキャラクタまたはコーディングでも用いることができる。
本明細書に記載するようなジェスチャ・ボキャブラリ・ストリングを採用するシステムはいずれも、ストリング比較の高い計算効率の恩恵を享受する。指定されたいずれのポーズについても、その識別または検索は、文字どおり、所望のポーズ・ストリングと瞬時的な実際のストリングとの間における「ストリングの比較」(例えば、UNIX(登録商標)の「stremp()」関数)となる。更に、「ワイルドカード・キャラクタ」の使用によって、プログラマやシステム設計者には、もっと見慣れた効率(efficiency)および有効性(efficacy)が得られる。自由度の瞬時状態が一致とは関わりがない場合、疑問符(「?」)として指定することができ、追加のワイルドカードの意味を割り当てることができる。
指および親指のポーズに加えて、手の方位が情報を表すことができる。大域空間(global-space)方位を記述するキャラクタも、透過的に選択することができる。キャラクタ「<」、「>」、「^」、および「v」は、方位キャラクタ位置において遭遇した場合、左、右、上、および下の考えを示すために用いることができる。図19は、手方位記述子、ならびにポーズおよび方位をコード化する例を示す。一実施形態では、2つのキャラクタ位置が、最初に手の平の方向を指定し、次いで指の方向を指定する(指が真っ直ぐになっている場合、指の実際の屈曲には関係なく)。これら2つの位置に可能なキャラクタは、方位の「ボディ中心」観念(body-centric notion)を表現し、「−」、「+」、「x」、「*」、「^」、および「v」は、中間、横方向、前方(順方向、ボディから離れる側)、後方(逆方向、ボディから離れる側)、頭上(上方)、および後端(下方)を記述する。
本発明の表記方式および実施形態では、キャラクタを示す5本指のポーズに続いて、コロン、次いで完全なコマンド・ポーズを定義するために2つの方位キャラクタがある。一実施形態では、開始位置は「xyz」ポーズと呼ばれ、親指は真っ直ぐ上を指し示し、人差し指は前方を指し示し、中指は人差し指に対して垂直であり、右手によってこのポーズが作られる場合、左を指し示す。これは、ストリング「^^xl−:−x」によって表される。
「XYZ−手」は、視覚的に提示された三次元構造の最大6自由度のナビゲーションを可能にするために、人の手の幾何学的形状を利用する技法である。この技法は操作者の手の全体的(bulk)平行移動および回転のみに依存し、したがってその指は原則として、いずれの所望のポーズに保持することができるが、本実施形態は、人差し指がボディから離れる方向を指し、親指が天井を指し、中指が左−右を指す、静止構成(static configuration)を優先する。つまり、これら3本の指は、三空間座標系の3本の相互に直交する軸、つまり、「XYZ−手」を記述する(大まかであるが、明白な歴然とした趣旨がある)。
次いで、XYZ−手ナビゲーションは、操作者のボディの前において所定の「中立位置」に保持された、前述のようなポーズの手、指に進む。三空間オブジェクト(またはカメラ)の三平行移動および三回転自由度へのアクセス(access)は以下の自然な方法で行われる。手の右−左移動(ボディの自然座標系に対して)により、計算的コンテキストのx−軸に沿った移動が生じ、手の上下移動により、被制御コンテキストのy−軸に沿った移動が生じ、前後の手の移動(操作者のボディに向かう方向/から離れる方向)によって、このコンテキストにおけるz−軸運動が生ずる。同様に、人差し指を中心とする操作者の手の回転により、計算的コンテキストの方位の「転動」(roll)変化が生じ、操作者の手の中指および親指をそれぞれ中心とする回転によって、「縦方向」および「横方向」変化が類似的に生ずる。
尚、「計算的コンテキスト」は、本明細書では、XYZ−手方法によって制御される全体に言及するために用いられており、合成三空間オブジェクトまたはカメラのいずれかを示唆するように思われるが、この技法は実世界オブジェクトの種々の自由度を制御するため、例えば、しかるべき回転アクチュエータを装備したビデオまたはモーション・ピクチャ・カメラのパン/ティルト/ロール制御にも等しく有用であることは言うまでもないことを注記しておく。更に、XYZ−手の姿勢によって得られる物理的自由度は、仮想ドメインであっても、ありのままにマッピングされ難い場合もある。本実施形態では、XYZ−手は、大きな全景的表示画像に対してナビゲーション的アクセスを提供するためにも用いられるので、操作者の手の左−右および上−下の運動が、画像を中心とする予期された左−右または上−下「パンニング」に繋がるが、操作者の手の前−後運動は「ズーミング」制御にマッピングする。
あらゆる場合において、手の運動と誘発される計算的平行移動/回転との間の結合は、直接的(即ち、操作者の手の位置的または回転オフセットが、一対一で、何らかの線形または非線形関数によって、計算的コンテキストにおけるオブジェクトまたはカメラの位置的または回転オフセットにマッピングする)、または間接的(即ち、操作者の手の位置的または回転オフセットが、一対一で、何らかの線形または非線形関数によって、計算的コンテキストにおける位置/方位の第1導関数またはより上位の導関数にマッピングし、実行中の積分が、計算的コンテキストの実際のゼロ次位置/方位における被静的変化を生み出す)のいずれかであることができる。この後者の制御手段は、自動車の「アクセル・ペダル」の使用に類似しており、ペダルの一定のオフセットによって、ほぼ一定の車速が得られる。
実世界のXYZ−手の局所的六自由度座標原点としての役割を果たす「中立位置」は、(1)空間における絶対位置および方位として(例えば、密閉室に対する)、(2)操作者の全体的な位置および「方向」(heading)には関係なく、操作者自身に対する固定位置および方位(例えば、ボディの前方8インチ、顎の下10インチ、横方向に肩の平面と一直線状)として、あるいは(3)操作者の故意の二次的行動によって、対話的に(例えば、操作者の「別の」手によって演じられるジェスチャ・コマンドを用いて。前記コマンドは、XYZ−手の現在の位置および方位が今後平行移動および回転の原点として用いられるべきことを示す)確立することができる。
更に、XYZ−手の中立位置の周囲に「抑止」(detent)領域(または「デッド・ゾーン」)を設けて、この立体空間における移動が被制御コンテキストにおける移動にマッピングしないようにすると便利である。
他のポーズも含むことができる。
[lllll:vx]は、手を平らにして(親指が他の指と平行)、手のひらが下を向き、指が前方に突き出している。
[lllll:x^]は、手を平らにして、手のひらが前を向き、指が天井を向いている。
[lllll:-x]は、手を平らにして、手のひらがボディの中心に向いており(左手の場合は右、右手の場合は左)、指が前方に突き出している。
[^^^^-:-x]は、手を1つにして親指を合わしている(親指は天井を向いている)。
[^^^|-:-x]は、銃を前方に構える真似である。
一実施形態のSOEは、1つの手のコマンドおよびポーズだけでなく、2つの手によるコマンドおよびポーズも想定している。図20は、一実施形態の下における、SOEのジェスチャ・ボキャブラリにおける二手組み合わせおよ対応する表記の例を示す。第1の例の表記を検討すると、「完全停止(full stop)」とは2つの拳を閉じていることを示す。「スナップショット」の例では、各手の親指および人差し指が広げられ、親指が互いに向き合って、ゴール・ポストの形状の枠を定めている。「舵およびスロットル開始位置」は、指および親指が上を向いており、手のひらが画面に面している。
図21は、一実施形態のSOEの下における方位配合の一例を示す。図示の例では、配合は、指ポーズ・ストリングの後ろにある括弧の中に囲まれた方位表記の対によって表されている。例えば、第1コマンドは、全て真っ直ぐに伸ばした指の位置を示す。方位コマンドの第1対により、手のひらをディスプレイに向かって平らにして、第2対によって、手を画面に向けて45度縦に回転させる。この例では、配合の対を示したが、SOEではいずれの数の配合でも考えられる。
図23は、SOEと共に用いることができる、多数の可能なコマンドを示す。本明細書における論述の一部は、ディスプレイ上におけるカーソルの制御についてであったが、SOEはその行動に限定されるのではない。実際に、SOEは、画面上における全てのデータおよびデータの一部、更にはディスプレイの状態を操作する際に、様々に応用することができる。例えば、ビデオ・メディアの再生中に、これらのコマンドをビデオ制御に代わって用いることができる。これらのコマンドは、一時停止、早送り、巻き戻しなどを行うために用いることができる。加えて、画像のズーム・インおよびズーム・アウトを行うため、画像の方位を変化させるため、いずれかの方向にパンニングするため等に実施することができる。また、SOEは、開く、閉じる、保存する等のような、メニュー・コマンドの代わりに用いることもできる。言い換えると、想像することができるいずれのコマンドまたはアクティビティでも、手のジェスチャによって実施することができる。
図22は、一実施形態におけるSOEの動作を示す流れ図である。ステップ2201において、検出システムはマーカおよびタグを検出する。判断ブロック2202において、タグおよびマーカが検出されたか否か判断を行う。検出されていない場合、システムはステップ2201に戻る。ステップ2202においてタグおよびマーカが検出された場合、システムはステップ2203に進む。ステップ2203において、システムは、検出されたタグおよびマーカから、手、指、およびポーズを識別する。ステップ2204において、システムは、ポーズの方位を識別する。ステップ2205において、システムは、検出された1つまたは双方の手の三次元空間位置を識別する。(ステップ2203、2204、および2205の内いずれでも、または全てを1つの動作として組み合わせてもよいことに注意されたい)。
ステップ2206において、以上の情報を、前述したジェスチャ表記に変換する。判断ブロック2207において、ポーズが有効か否か判断を行う。これは、発生した表記ストリングを用いた単純なストリング比較によって行うことができる。ポーズが有効でない場合、システムはステップ2201に戻る。ポーズが有効である場合、ステップ2208において、システムは表記および位置情報をコンピュータに送る。ステップ2209において、コンピュータは、ジェスチャに応答して、取るべきしかるべきアクションを決定し、ステップ2210においてそれに応じてディスプレイを更新する。
SOEの一実施形態では、動作2201〜2205をカメラ内蔵プロセッサによって実行する。他の実施形態では、望ましければ、この処理をシステム・コンピュータによって実行することもできる。
本システムは、基礎となるシステムによって再現された低レベルのジェスチャの流れを「解析(parse)」および「変換(translate)」し、これら解析し変換したジェスチャを、コマンドまたはイベント・データの流れに変換することができる。このデータは、広範囲のコンピュータ・アプリケーションおよびシステムを制御するために用いることができる。これらの技法およびアルゴリズムは、これらの技法を実現するエンジン、およびエンジンの能力を利用するコンピュータ・アプリケーションを構築するプラットフォームの双方を提供するコンピュータ・コードから成るシステムにおいて具体化することができる。
一実施形態は、コンピュータ・インターフェースにおいて、人の手の豊富なジェスチャの使用を可能にすることを中心に据えるが、他のボディ部分によって行われるジェスチャ(限定ではなく、腕、胴体、脚部、および頭部を含む)や、手ではない種々の器具によって行われるジェスチャを認識することもできる。これらの器具は、静止および連結式(articulating)双方であり、限定ではないが、キャリパ、コンパス、可撓性曲線近似器(curve approximator)、および種々の形状のポインティング・デバイスが含まれる。マーカおよびタグは、操作者によって所望に応じて携行および使用することができる品目および器具に被着することができる。
本明細書において記載するシステムは、認識し反応することができるジェスチャの範囲が豊富なジェスチャ・システムを構築することを可能にしつつ、同時にアプリケーションへの容易な統合にも備えた、多数の改革を組み込む。
一実施形態では、ジェスチャ解析および変換システムは、以下のものを備えている。
1)様々な異なる集計レベルにおいて、ジェスチャを指定する(コンピュータ・プログラムにおいて用いるためのエンコード)緻密かつ効率的な方法。
a.1本の手の「ポーズ」(手の部分の外形および互いに対する方位)。三次元空間における1つの手の方位および位置。
b.2つの手の組み合わせ。いずれかの手がポーズ、位置、または双方を考慮に入れる。
c.多数の人物の組み合わせ。本システムは2つよりも多い手を追跡することができ、したがって、一人よりも多い事物が協同して(ゲーム・アプリケーションの場合には競合して)目標システムを制御することができる。
d.ポーズが連続して組み合わされる順次ジェスチャ。これらを「動画」ジェスチャと呼ぶ。
e.操作者が空間内の形状を追跡する「書記素」ジェスチャ(grapheme gesture)。
2)所与のアプリケーション・コンテキストに関連があるものの上で、各カテゴリから特定のジェスチャを登録するプログラム技法。
3)登録されているジェスチャを識別することができ、これらのジェスチャをカプセル化するイベントを関連するアプリケーション・コンテキストに配信することができるように、ジェスチャの流れを解析するアルゴリズム。
指定システム(1)は、構成エレメント(1a)から(1f)と共に、本明細書に記載するシステムのジェスチャ解析および変換能力を利用するための基礎を提供する。
1本の手の「ポーズ」は、
i)手の指と甲との間の相対的方位、
ii)少数の離散状態への量子化、
のストリングとして表される。
相対的接合方位を用いることにより、本明細書に記載するシステムは、手のサイズおよび外形形状が異なることに伴う問題を回避することができる。このシステムでは、「操作者較正」を必要としない。加えて、ポーズをストリングまたは相対的方位の集合体として指定することにより、ポーズ表現を更に別のフィルタおよび指定と組み合わせることによって、一層複雑なジェスチャ指定(specification)を容易に作成することが可能になる。
ポーズ指定に少数の離散状態を用いることによって、ポーズを簡潔に指定することができ、更に種々の基礎となる追跡技術(例えば、カメラを用いた受動的光学追跡、点灯ドットおよびカメラを用いた能動的光学追跡、電磁場追跡等)を用いて、精度の高いポーズ認識を確実に行うことができる。
各カテゴリ(1a)から(1f)におけるジェスチャは、部分的に(または最小限に)指定することができるので、重大でないデータは無視される。例えば、2本の指の位置が明確であり他の指の位置は重要でないジェスチャは、2本の関連のある指の動作位置が与えられ、同じストリング内において、「ワイルド・カード」または包括的「無視」インディケータが他の指に対して掲示されている1つの指定によって表すことができる。
本明細書において記載するジェスチャ認識のための改革の全ては、限定ではなく、多層指定技法、相対的方位の使用、データの量子化、および各レベルにおける部分的または最小指定の許容を含み、手のジェスチャの指定を超えて、他のボディ部分や「製造した」器具およびオブジェクトを用いたジェスチャの指定に一般化する。
「ジェスチャを登録する」プログラム技法(2)は、どのジェスチャをエンジンが実行システムの他の部分に入手可能にすべきか定めることをプログラマに可能にする、定められた1組のアプリケーション・プログラミング・インターフェース・コールによって構成されている。
これらのAPIルーチンは、アプリケーション設定時に用いることができ、実行アプリケーションの寿命の間用いることができる静止インターフェース定義を作成する。また、これらは、実行中にも用いることができ、インターフェース特性を動作中に変更することができる。このリアル・タイムでのインターフェース変更により、
i)複雑なコンテキストおよび条件付き制御状態を構築すること、
ii)動的にヒステリシスを制御環境に追加すること、および
iii)ユーザが実行システム自体のインターフェース・ボキャブラリを変更または拡張することができるアプリケーションを作成すること、
が可能となる。
ジェスチャの流れを解析するアルゴリズム(3)は、(1)におけるように指定され(2)におけるように登録されたジェスチャを、入来する低レベルのジェスチャ・データと比較する。登録されているジェスチャに対する一致が認識された場合、一致したジェスチャを表すイベント・データが積層され実行アプリケーションに配信される。
このシステムの設計においては、効率的なリアル・タイムでの照合が望まれ、指定されたジェスチャは、できるだけ素早く処理される可能性のツリーとして扱われる。
加えて、指定されたジェスチャを認識するために内部で使用されている原始的比較演算子は、アプリケーション・プログラマが用いるためにも露出されるので、アプリケーション・コンテキスト内部からでも、より多くの比較(例えば、複雑なジェスチャまたは複合ジェスチャにおける柔軟な状態の検査)を行うことができる。
認識「ロッキング」セマンティクス(recognition locking semantics)は、本明細書に記載するシステムの改革の1つである。これらのセマンティクスは、登録API(2)(および、より狭い範囲で、指定ボキャブラリ(1)内に埋め込まれる)によって暗示される(imply)。登録APIコールは、
i)「エントリ」状態通知部および「連続」状態通知部、ならびに
ii)ジェスチャ優先度指定部
を含む。
ジェスチャが認識されている場合、その「連続」状態は、同じまたは低い優先度のジェスチャの全ての「エントリ」状態よりも優先される。このエントリ状態と連続状態との間の区別は、認められるシステム使用可能性に大きくプラスになる。
本明細書において記載するシステムは、実世界のデータ・エラーおよび不確実性をものともせずに、ロバストな動作のためのアルゴリズムを含む。低レベル追跡システムからのデータは不完全である場合もある(光学追跡におけるマーカの遮蔽、ネットワーク・ドロップアウト、処理の遅れ等を含む、種々の理由による)。
欠損データは、解析システムによって印が付けられ、その欠損データの量およびコンテキストに応じて、「最後に分かっていた」状態または「最もあり得る」状態のいずれかに組み込まれる。
特定のジェスチャ・コンポーネント(例えば、特定の関節の方位)についてのデータが見つからないが、その特定のコンポーネントの「最後に分かっていた」状態を、物理的に可能であると分析することができる場合、本システムはこの最後に分かっていた状態をそのリアル・タイム照合において用いる。
逆に、最後に分かっていた状態が、物理的に不可能であると分析された場合、本システムはそのコンポーネントにとって「最良のジェスチャ範囲」に後退し、この合成データをそのリアル・タイム照合において用いる。
本明細書において記載する指定および解析システムは、「利き手不可知論」をサポートするように注意深く設計されているので、多数の手のジェスチャについて、いずれの手でもポーズの要件を満たすことができる。
一実施形態のシステムは、1つ以上のディスプレイ・デバイス(「画面」)上に描かれた仮想空間を、当該システムの一人または複数の操作者によって占められる物理空間と一致するものとして扱う環境を提供することができる。このような環境の一実施形態についてここで説明する。この現実施形態は、固定位置に3つのプロジェクタ・ドライブ画面を含み、1つのデスクトップ・コンピュータによってドライブされ、本明細書に記載したジェスチャ・ボキャブラリおよびインターフェース・システムを用いて制御される。しかしながら、記載する技法は、いかなる数の画面でもサポートすること、これらの画面は移動可能であってもよいこと(固定ではなく)、画面は多くの独立したコンピュータによって同時にドライブしてもよいこと、そしてシステム全体はいずれの入力デバイスまたは技法によっても制御できることを注記しておく。
本開示において記載するインターフェース・システムは、物理空間における画面の寸法、方位、および位置を決定する手段を有していなければならない。この情報を仮定して、本システムは、これらの画面が配置されている(そして、本システムの操作者が占める)物理空間を、本システム上で実行しているコンピュータ・アプリケーションの仮想空間への投影として動的にマッピングすることができる。この自動マッピングの一部として、本システムは、システムによってホストされているアプリケーションの必要性に応じて、種々の方法で2つの空間の規模、角度、深さ、寸法、およびその他の空間特性も変換する。
この物理空間と仮想空間との間における連続変換によって、既存のアプリケーション・プラットフォームでは達成が困難である、または既存のプラットフォーム上で実行するアプリケーション毎に1つ1つ実装しなければならない多数のインターフェース技法の一貫性があり普及する使用が可能となる。これらの技法は、(限定ではないが)以下を含む。
1)「リテラル・ポインティング」(literal pointing)の広く行き渡る自然なインターフェース技法としての使用。ジェスチャ・インターフェース環境において手を用いるか、あるいは物理的ポインティング・ツールまたはデバイスを用いる。
2)画面の移動または再位置決めに対する自動補償。
3)操作者の位置に応じて変化するグラフィクス・レンダリング。例えば、深度の知覚を高めるためにパララックス・シフトをシミュレーションする。
4)実世界位置、方位、状態等を考慮に入れた、画面上表示への物理的オブジェクトの含入。例えば、大きく不透明な画面の前に立っている操作者は、アプリケーションのグラフィクスと、画面の背後にある(そして、恐らく移動しているか、または方位を変えている)スケール・モデル(scale model)の真の位置の表現との双方を見ることができる。
リテラル・ポインティングは、マウス・ベースのウィンドーイング・インターフェースや殆どのその他の現在のシステムにおいて用いられている絶対ポインティングとは異なることを注記するのは重要である。これらのシステムでは、操作者は仮想ポインタと物理ポインティング・デバイスとの間の変換を管理することを学習しなければならず、更にこれら2つの間で経験的知識に基づいてマッピングしなければならない。
対照的に、本開示において記載するシステムでは、アプリケーションまたはユーザの観点のいずれからでも、仮想空間と物理空間との間に差がないので(仮想空間の方が数学的操作がし易いことを除く)、操作者に経験的知識に基づく変換は必要とされない。
本明細書において記載する実施形態によって提供されるリテラル・ポインティングに最も近い類似性は、接触感応画面(例えば、多くのATMマシン上で見られる)である。接触感応画面は、画面上の二次元表示空間と画面表面の二次元入力空間との間に1対1のマッピングを規定する。同様に、本明細書において記載するシステムは、1つ以上の画面上に表示される仮想空間と、操作者によって占められる物理空間との間に柔軟なマッピング(1対1のマッピングも可能であるが、その必要性はない)を規定する。この類似性の有益さ(usefulness of the analogy)にも拘わらず、この「マッピング手法」の三次元、任意に大きなアーキテクチャ環境、および多数の画面への拡張は重要である。
本明細書において記載するコンポーネントに加えて、本システムは、環境の物理空間と各画面上の表示空間との間に連続的なシステム・レベルのマッピング(恐らく回転、平行移動、倍率調整、またはその他の幾何学的変換によって変更される)を実現するアルゴリズムも実装することができる。
レンダリング・スタックは、計算オブジェクトおよびマッピングを取り込み、仮想空間のグラフィカル表現を出力する。
入力イベント処理スタックは、制御システムからイベント・データを取り込み(現実施形態では、システムおよびマウス入力からのジェスチャ・データおよびポインティング・データの双方)、入力イベントからの空間データを仮想空間における座標にマッピングする。次いで、変換されたイベントは、実行中のアプリケーションに配信される。
「グルー・レイヤ」は、システムが、ローカル・エリア・ネットワークにある数台のコンピュータに跨って実行するアプリケーションをホストすることを可能にする。
SOEについての前述の説明を考慮すると、SOEは、図1から図1Cまでおよび本明細書における他のところを参照して先に説明したマルチプロセス・インタラクティブ・システムの構成要素として用いること、および/またはマルチプロセス・インタラクティブ・システムに結合することができる。一実施形態のSOEは、先に説明したように、ユーザ入力プロテインをユーザ入力プールUiに伝達するジェスチャ/空間プロセスGとしてカプセル化することができる。
本明細書における実施形態は、ジェスチャ・データからボディによって行われたジェスチャを検出するシステムおよび方法を含む。ジェスチャ・データは、検出器を通じて受け取られる。一実施形態のシステムおよび方法は、処理デバイス上において多数のプロセスを実行する。これらのプロセスは、ジェスチャを表す1組のイベントを含むイベントを発生する。一実施形態のシステムおよび方法は、各プロセスのイベントをデータ・カプセルに変換する。一実施形態のシステムおよび方法は、これらのデータ・カプセルを多数のプールまたはレポジトリに転送する。多数のプロセスにおける1組のプロセスは、認識プロセスとして動作する。この認識プロセスは、プールにおいて、ジェスチャに対応する内容を備えているデータ・カプセルを認識する。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生する。ジェスチャ信号はジェスチャを表す。
図24は、一実施形態の下において、マルチプロセス・インタラクティブ・システムのコンポーネントと共に実装する、またはマルチプロセス・インタラクティブ・システムとして実装する空間動作環境(SOE)(図1CのエレメントGを参照)のブロック図である。ユーザは、彼の手2401および2402をカメラ2404A〜2404Dのアレイの視野2450に置く。これらのカメラは、指ならびに手2401および2402の位置、方位、および動きを検出、出力信号をプリプロセッサ2405に発生する。プリプロセッサ2405は、カメラ出力をジェスチャ信号に変換し、このジェスチャ信号を本システムのコンピュータ・プロセッサに供給する。この実施形態では、前述のコンピュータ2407によって実行される、コンピュータ・プロセッサの機能は、マルチプロセス・インタラクティブ・システム(図1C)のプロセッサによって実行すること、および/またはマルチプロセス・インタラクティブ・システムに結合することができる。ジェスチャ信号は、マルチプロセス・インタラクティブ・システムのプール(プールUi、図1C)に供給または転送することができる。その結果、マルチプロセス・インタラクティブ・システムはジェスチャ信号を用いて、マルチプロセス・インタラクティブ・システムに結合されている1つ以上のコンポーネント(例えば、ディスプレイ・カーソル等)を制御するコマンドを発生する。
本システムでは、1人のユーザの手を入力として示すが、SOEは、多数のユーザを用いても実現することができる。加えて、手の代わりまたは手に加えて、本システムは、ユーザのボディであればいずれの1つまたは複数の部分でも追跡することができ、その部分には、頭部、足、脚部、腕、肘、膝等が含まれる。
図示した実施形態では、視野2450におけるユーザの手2401および2402の位置、方位、および移動を検出するために用いられる4台のカメラを用いる。尚、SOEの範囲や趣旨から逸脱することなく、SOEは、これらよりも多いカメラ(例えば、6台のカメラ、8台のカメラ等)または少ないカメラ(例えば、2台のカメラ)、あるいはセンサとでも用いることができることは言うまでもない。加えて、実施形態例では、カメラまたはセンサは対称的に配置されているが、SOEにはこのような対称性の要件はない。ユーザの手の位置、方位、および移動を許容するのであれば、カメラまたはセンサは、いずれの数および位置付けでも、SOEにおいて用いることができる。
一実施形態では、用いられるカメラは、グレー・スケール画像を取り込むことができるモーション・キャプチャ・カメラである。一実施形態では、用いられるカメラは、Vicon MX40カメラのような、Vicon社が製造するカメラである。このカメラは、カメラ内部処理を含み、毎秒1000フレームの画像取り込みが可能である。モーション・キャプチャ・カメラは、マーカを検出し位置を突き止めることができる。
記載している実施形態では、カメラは光学的検出に用いられるセンサである。他の実施形態では、カメラまたは他の検出器は、電磁、静磁気、RFID、またはその他の任意の適した種類の検出に用いることができる。
プリプロセッサ2405は、三次元空間点再現および骨格点ラベリングを発生するために用いられる。ジェスチャ変換器2406は、3D空間情報およびマーカ・モーション情報をコマンド言語に変換するために用いられる。コマンド言語は、プールUi(図1参照)から情報を受信するマルチプロセス・インタラクティブ・システムのコンポーネントによって解釈することができる。SOEの代替実施形態では、プリプロセッサ2405およびジェスチャ変換器106を統合してまたは組み合わせて1つのデバイスにすることもできる。
図25は、一実施形態の下において、ジェスチャ制御システムからの入力を用いるマルチプロセス・インタラクティブ・システム100(図1参照)の動作の流れ図2500である。これらの動作は、ボディによって行われたジェスチャを、ジェスチャ・データから検出すること(2502)を含む。ジェスチャ・データは、検出器を通じて受信される。この動作は、処理デバイス上で複数のプロセスを実行する(2504)ことを含む。これらのプロセスは、ジェスチャを表す1組のイベントを含むイベントを発生する。これらのプロセスは、空間動作アプリケーションの分離可能なプログラム実行コンテキストを含むが、そのように限定されるのではない。各プロセスのイベントをデータ・カプセルに変換する(2506)。データ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、データ・カプセルから発生したプロセスの状態情報とを含むが、そのように限定されるのではない。データ・カプセルを複数のプールに転送する(2508)。多数のプロセスの内1組のプロセスが、認識プロセスとして動作する。認識プロセスは、プールにおいて、ジェスチャに対応する内容を備えているデータ・カプセルを認識する(2510)。認識プロセスは、認識したデータ・カプセルをプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生する(2512)。このジェスチャ信号は、ジェスチャを表す。
本明細書において記載した実施形態は、方法を含む。この方法は、少なくとも1つの処理デバイス上において複数のプロセスを実行するステップと、これら複数のプロセスの内各プロセスのイベントをデータ・カプセルに変換するステップと、このデータ・カプセルを複数のプールに転送するステップと、各プロセスが認識プロセスとして動作するステップであって、認識プロセスが、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、当該認識プロセスの識別との内少なくとも1つを備えているデータ・カプセルを認識する、ステップと、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するステップとを備えている。
一実施形態のデータ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージが発生したプロセスの状態情報とを含む。
一実施形態の方法は、データ・カプセルおよび複数のプールを用いて、複数のプロセスの各々の動作を調整することによって、複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている。
一実施形態の方法は、データ・カプセルおよび複数のプールの内少なくとも1つを用いて、複数のプロセスの動作を調整するステップを備えている。
一実施形態の方法は、アプリケーション・プログラムを1組のプロセスに分割するステップを備えており、複数のプロセスが1組のプロセスを含む。
一実施形態の方法は、複数のプールの内少なくとも1つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている。
一実施形態の複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備えている。
一実施形態の方法は、複数のプロセスを並列に実行するステップを備えている。
一実施形態の方法は、第1組のプロセスを並列に実行し、第2組のプロセスを順次実行するステップを備えており、複数のプロセスが第1組のプロセスおよび第2組のプロセスを含む。
一実施形態のイベントは、プロセス入力を表す。
一実施形態のイベントは、プロセス出力を表す。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。
一実施形態のイベントは、グラフィクスイベントを備えている。
一実施形態のイベントは、イベントがプロセスの状態を表す。
一実施形態のプロセスの状態は、当該プロセスのインタラクティブ機能を表し、プロセスのインタラクティブ機能を複数のプロセスに、データ・カプセルの内容として露出する。
一実施形態の方法は、アプリケーション・プログラミング・インターフェース(API)を関数コールによって定義する代わりに、データ・カプセルの内容によって複数のプロセスのAPIを定義するステップを備えている。
一実施形態のデータ・カプセルの内容は、アプリケーションに独立しており、複数のプロセスによって認識可能である。
一実施形態の少なくとも1つの処理デバイスは、複数の処理デバイスを備えている。
一実施形態の複数のプロセスの内少なくとも1つの第1組のプロセスは、一実施形態の複数の処理デバイスの内少なくとも1つの第1組の処理デバイスの下で起動し、複数のプロセスの内少なくとも1つの第2組のプロセスは、複数の処理デバイスの内少なくとも1つの第2組の処理デバイスの下で起動する。
一実施形態の複数のプロセスは、第1プロセスを含む。
一実施形態の変換するステップは、第1プロセスのイベントを、イベントを指定する第1プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態の第1プロセス・イベント・データおよび状態情報は、第1プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、第2プロセスを含む。
一実施形態の変換するステップは、第2プロセスの状態変化イベントを、イベントを指定する第2プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態の第2プロセス・イベント・データおよび状態情報は、第2プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の認識プロセスは、第2プロセスであり、第2プロセスは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するステップを含む。
一実施形態の認識したデータ・カプセルの内容は、第1プロセスの状態情報を表すデータである。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、少なくとも1つの新たなデータ・シーケンスは、第1プロセスのイベントおよび第2プロセスのイベントの内少なくとも1つを表す。
一実施形態の少なくとも1つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、第1プロセスおよび第2プロセスの内少なくとも1つの状態情報とを備えている。
一実施形態のイベント・データならびに第1プロセスおよび第2プロセスの内少なくとも1つの状態情報は、第1プロセスおよび第2プロセスの内少なくとも1つのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、少なくとも1つの新たなデータ・シーケンスを用いる。
一実施形態の認識したデータ・カプセルの内容に適した処理は、グラフィカル・オブジェクトをレンダリングするステップを含み、少なくとも1つの処理デバイスのディスプレイ上にグラフィカル・オブジェクトをレンダリングする。
一実施形態のレンダリングするステップは、直接レンダリングを行い、複数のプロセスが少なくとも1つの処理デバイスのグラフィクス・レイヤに直接描画を行い、複数のプロセス間においてレンダリングに適するような調整を行うために複数のプールを用いる。
一実施形態のレンダリングするステップは、レンダリング・コマンドを備えているデータ・カプセルを複数のプールに転送する複数のプロセスを備えている。一実施形態のレンダリングするステップは、レンダリング・コマンドを複数のプールから引き出し、レンダリング・コマンドを解釈し、レンダリング・コマンドに応答して少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする複数のプロセスを備えている。
一実施形態のレンダリングするステップは、画素バッファにレンダリングする複数のプロセスを備えている。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールに転送する複数のプロセスを備えており、生のフレーム・データは、画素バッファへのレンダリングの結果得られる。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールから引き出し、少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、生のフレーム・データを組み合わせる複数のプロセスを備えている。
一実施形態の方法は、複数のプロセスのイベントを検出するステップを備えている。一実施形態の方法は、イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生するステップを備えており、イベント・データおよび状態情報は、少なくとも1つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、このデータ・カプセルが、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別イベント・データを含む第1個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第2個別状態情報を含む第2個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別データ集合および第2個別データ集合を含むように、第1データ・シーケンスを形成するステップを備えている。
一実施形態の第1個別データ集合を発生するステップは、少なくとも1つの処理デバイスの識別データを含むように、第1個別データ集合を形成するステップを含み、識別データは、少なくとも1つの処理デバイスを識別するデータを含む。
一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別イベント・データを含む第1個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第2個別状態情報を含む第2個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別データ集合および第2個別データ集合を含むように、第2データ・シーケンスを形成するステップを備えている。
一実施形態の第1個別データ集合を発生するステップは、第1個別データ集合オフセットを発生するステップを含み、第1個別データ集合オフセットは、第2データ・シーケンスの第1個別データ集合を指し示す。
一実施形態の第2個別データ集合を発生するステップは、第2個別データ集合オフセットを発生するステップを含み、第2個別データ集合オフセットは、第2データ・シーケンスの第2個別データ集合を指し示す。
一実施形態の第1個別データ集合は、記述リストであり、この記述リストは、データの記述を含む。
一実施形態のイベント・データは、類別されたデータ(typed data)を表すタグ付き(tagged)バイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも1つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットを含むように、データ・カプセルを形成するステップを備えている。
一実施形態の方法は、第1可変長を有する第1オフセットを発生するステップを備えており、第1オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスのイベント・データを指し示す。
一実施形態の方法は、第2可変長を有する第2オフセットを発生するステップを備えており、第2オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスの状態情報を指し示す。
一実施形態の方法は、少なくとも1つのオフセットの内第1オフセットを用いて、データ・カプセルを通過する第1コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットの内第2オフセットを用いて、データ・カプセルを通過する第2コード経路を形成する、ステップを備えており、第1コード経路および第2コード経路は、異なる経路である。
一実施形態の第1オフセットおよび第2オフセットの内少なくとも1つは、メタデータを含み、このメタデータは、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
一実施形態の方法は、データ・カプセルの長さを含むヘッダを発生するステップを備えている。一実施形態の方法は、ヘッダを含むようにデータ・カプセルを形成するステップを備えている。
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、少なくとも1つの処理デバイスの第2イベントを検出するステップを備えている。一実施形態の方法は、複数のプールを検索して、第2イベントに対応するデータ・カプセルを求めるステップを備えている。
一実施形態の方法は、データ・カプセルと第2イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、特定に応答して、プールからデータ・カプセルを抽出するステップを備えている。一実施形態の方法は、データ・カプセルの内容に応答して、少なくとも1つの処理デバイスの代わりに、第2イベントに対応する処理動作を実行するステップを備えており、少なくとも1つの処理デバイスが第1タイプのアプリケーションおよび第2タイプのアプリケーションに対応する。
一実施形態の複数のプールは、複数のアプリケーションに結合されており、複数のプールは、複数のアプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、複数のアプリケーションによる複数のデータ・カプセルへのアクセスに備えており、複数のアプリケーションの内少なくとも2つのアプリケーションが異なるアプリケーションである。
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュ(state caching)に備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンス(sequencing)に備えている。
一実施形態のデータ構造は、類別されていない(untyped)。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
一実施形態の転送するステップは、第1アプリケーション・タイプを有する第1アプリケーションから少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションにデータ・カプセルを転送するステップを含み、第1アプリケーション・タイプが第2アプリケーション・タイプとは異なり、少なくとも1つのデータ・シーケンスを発生するステップは、第1アプリケーションによって実行され、本方法は、転送するステップの間、データ・カプセルの少なくとも1つのデータ・シーケンスをそのまま保持するステップを備えている。
一実施形態の方法は、第2アプリケーションの動作中少なくとも1つのデータ・シーケンスを用いるステップを備えている。
一実施形態の方法は、イベント・データと、少なくとも1つの処理デバイスのソース・デバイスの識別データとを含む第1データ集合を発生するステップを備えており、デバイス・イベント・データは、ソース・デバイスによって登録されたイベントを指定するデータを含み、識別データは、ソース・デバイスを識別するデータを含む。
一実施形態の方法は、イベントの完全な1組の状態情報を含む第2データ集合を発生するステップを備えており、第1データ集合および第2データ集合の各々は、タイプ特定データ・レイアウトとした類別データ・バンドル(typed data bundle)を備えている。
一実施形態の変換するステップは、第1データ集合および第2データ集合を含むようにデータ・カプセルを形成することによって、第1データ集合および第2データ集合をカプセル化するステップを備えており、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の方法は、第1タイプのアプリケーションの下で起動する第1処理デバイスのイベントを検出するステップを備えている。一実施形態の方法は、第1処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップを備えており、イベント・データがイベントおよびこのイベントの状態情報を指定し、イベント・データおよび状態情報は、アプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、データ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、データ・カプセルは、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。一実施形態の方法は、少なくとも1つの第2タイプを有する少なくとも1つの第2アプリケーションの下で起動する第2処理デバイスの第2イベントを検出するステップを備えており、第2タイプが第1タイプとは異なり、少なくとも1つの処理デバイスは、第1処理デバイスおよび第2処理デバイスを含む。一実施形態の方法は、データ・カプセルと第2イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、第2イベントに応答して、データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップを備えている。
一実施形態のデータ・シーケンスを発生するステップは、イベント・データを含む第1データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、状態情報を含む第2データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、第1データ集合および第2データ集合を含むように第1データ・シーケンスを形成するステップを備えている。
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも1つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットを含むようにデータ・カプセルを形成するステップを備えている。
一実施形態の方法は、第1可変長を有する第1オフセットを発生するステップを備えており、第1オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスのイベント・データを指し示す。一実施形態の方法は、第2可変長を有する第2オフセットを発生するステップを備えており、第2オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスの状態情報を指し示す。
一実施形態の方法は、少なくとも1つのオフセットの内第1オフセットを用いて、データ・カプセルを通過する第1コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットの内第2オフセットを用いて、データ・カプセルを通過する第2コード経路を形成するステップを備えており、第1コード経路および第2コード経路が異なる経路である。
一実施形態の第1オフセットおよび第2オフセットの内少なくとも1つは、メタデータを含み、このメタデータは、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、複数のプールを検索して、第2イベントに対応するデータ・カプセルを求めるステップを備えている。一実施形態の方法は、対応を特定したことに応答して、プールからデータ・カプセルを抽出するステップを備えている。
一実施形態の複数のプールがアプリケーションおよび少なくとも1つの第2アプリケーションに結合されており、複数のプールは、アプリケーションおよび少なくとも1つの第2アプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、アプリケーションおよび少なくとも1つの第2アプリケーションによる複数のデータ・カプセルへのアクセスを与える。
一実施形態のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
本明細書において記載した実施形態は、方法を含む。この方法は、処理デバイス上において複数のプロセスを実行するステップであって、これら複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、このデータ・メッセージが、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージを発したプロセスの状態情報とを含む、ステップと、データ・メッセージを、複数のプールの内少なくとも1つのプールに転送するステップと、プロセス間において調整を行うステップであって、この調整は、複数のプロセスの各プロセスは、複数のプールからピア・プロセスの状態情報を引き出すことによって、複数のプロセスのピア・プロセスと対等になることを含む、ステップと、複数のプールの内少なくとも1つのプールの1組のデータ・メッセージをインタラクティブに組み合わせることによって、複数のプロセスの出力を発生するステップとを備えている。
本明細書において記載した実施形態は、システムを含む。このシステムは、少なくとも1つの処理デバイスであって、複数のプロセスを実行する、処理デバイスと、少なくとも1つの処理デバイスに結合されている複数のプールとを備えており、少なくとも1つの処理デバイスは、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを複数のプールに転送し、複数のプロセスの各プロセスは、認識プロセスとして動作し、この認識プロセスは、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、認識プロセスの識別との内少なくとも1つを備えているデータ・カプセルを認識し、認識プロセスは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する。
本明細書において記載した実施形態は、方法を含む。この方法は、少なくとも1つの処理デバイス上において複数のプロセスを実行するステップであって、これら複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップであって、データ・カプセルが、イベントのイベント・データのアプリケーションに独立した表現と、データ・カプセルを発したプロセスの状態情報とを含む、ステップと、データ・カプセルを、複数のプールに転送するステップと、各プロセスが認識プロセスとして動作し、この認識プロセスは、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、認識プロセスの識別との少なくとも1つを備えているデータ・カプセルを認識するステップと、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するステップとを備えている。
一実施形態の方法は、データ・カプセルおよび複数のプールを用いて、複数のプロセスの各々の動作を調整することによって、複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている。
一実施形態の方法は、データ・カプセルおよび複数のプールの内少なくとも1つを用いて、複数のプロセスの動作を調整するステップを備えている。
一実施形態の方法は、アプリケーション・プログラムを1組のプロセスに分割するステップを備えており、複数のプロセスが1組のプロセスを含む。
一実施形態の方法は、複数のプールの内少なくとも1つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている。
一実施形態の方法は、複数のプロセスを並列に実行するステップを備えている。
一実施形態の方法は、第1組のプロセスを並列に実行し、第2組のプロセスを順次実行するステップを備えており、複数のプロセスが第1組のプロセスおよび第2組のプロセスを含む。
一実施形態のイベントは、プロセス入力を表す。
一実施形態のイベントは、プロセス出力を表す。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。
一実施形態のイベントは、グラフィクスイベントを備えている。
一実施形態のイベントは、プロセス状態を表す。
一実施形態のプロセスの状態は、当該プロセスのインタラクティブ機能を表し、プロセスのインタラクティブ機能を複数のプロセスに、データ・カプセルの内容として露出する。
一実施形態の方法は、アプリケーション・プログラミング・インターフェース(API)を関数コールによって定義する代わりに、データ・カプセルの内容によって複数のプロセスのAPIを定義するステップを備えている。
一実施形態のデータ・カプセルの内容は、アプリケーションに独立しており、複数のプロセスによって認識可能である。
一実施形態の少なくとも1つの処理デバイスは、複数の処理デバイスを備えている。
一実施形態の複数のプロセスの内少なくとも1つの第1組のプロセスは、複数の処理デバイスの内少なくとも1つの第1組の処理デバイスの下で起動し、複数のプロセスの内少なくとも1つの第2組のプロセスは、複数の処理デバイスの内少なくとも1つの第2組の処理デバイスの下で起動する。
一実施形態の複数のプロセスは、第1プロセスを含む。
一実施形態の方変換するステップは、第1プロセスのイベントを、イベントを指定する第1プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態の第1プロセス・イベント・データおよび状態情報は、第1プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、第2プロセスを含む。
一実施形態の変換するステップは、第2プロセスの状態変化イベントを、イベントを指定する第2プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態の第2プロセス・イベント・データおよび状態情報は、第2プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の認識プロセスは、第2プロセスであり、引き出すステップは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する第2プロセスを備えている。
一実施形態の認識したデータ・カプセルの内容は、第1プロセスの状態情報を表すデータである。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、少なくとも1つの新たなデータ・シーケンスは、第1プロセスのイベントおよび第2プロセスのイベントの内少なくとも1つを表す。
一実施形態の少なくとも1つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、第1プロセスおよび第2プロセスの内少なくとも1つの状態情報とを備えている。
一実施形態のイベント・データならびに第1プロセスおよび第2プロセスの内少なくとも1つの状態情報は、第1プロセスおよび第2プロセスの内少なくとも1つのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスが少なくとも1つの新たなデータ・シーケンスを用いる。
一実施形態の複数のプロセスが入力プロセスを含み、この入力プロセスが入力イベントを入力デバイスから受ける。
一実施形態の変換するステップは、入力デバイスの入力イベントを、イベントを指定する入力デバイス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態の入力デバイス・イベント・データおよび状態情報は、ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、ポインタ・プロセスを含む。
一実施形態の認識プロセスは、ポインタ・プロセスであり、引き出すステップは、ポインタ・プロセスが複数のプールから認識したデータ・カプセルを引き出し、認識したデータ・カプセルの内容に適したプロセスを実行するステップを含む。
一実施形態の認識したデータ・カプセルの内容は、入力プロセスからの入力イベントを表すデータである。
一実施形態の認識データ・カプセルの内容は、少なくとも1つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、少なくとも1つの新たなデータ・シーケンスは、ディスプレイに関するポインタ・オブジェクトの位置を定める。
一実施形態の少なくとも1つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、ポインタ・プロセス・イベントの状態情報とを備えている。
一実施形態のポインタ・プロセス・イベント・データおよび状態情報は、ポインタ・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、ディスプレイ上にポインタ・オブジェクトをレンダリングする際に、少なくとも1つの新たなデータ・シーケンスを用いる。
一実施形態の複数のプロセスは、グラフィカル・プロセスを含む。
一実施形態の変換するステップは、グラフィカル・プロセスの状態変化イベントを、イベントを指定するグラフィカル・プロセス・イベント・データと、イベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態のグラフィカル・プロセス・イベント・データおよび状態情報は、グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の認識するプロセスは、グラフィカル・プロセスであり、引き出すステップは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行するグラフィカル・プロセスを含む。
一実施形態の認識したデータ・カプセルの内容は、複数のプロセスの内他のプロセスの状態情報を表すデータである。
一実施形態の状態情報は、空間状態およびモード状態の内少なくとも1つの情報を含む。
一実施形態の認識データ・カプセルの内容は、少なくとも1つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである。
一実施形態のポインタ・オブジェクトの位置は、グラフィカル・オブジェクトの境界内部にあり、グラフィカル・オブジェクトがグラフィカル・プロセスによってレンダリングされる。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、少なくとも1つの新たなデータ・シーケンスは、グラフィカル・オブジェクト、ポインタ・オブジェクト、およびポインタ・オブジェクトと境界との重複の内少なくとも1つを表す。
一実施形態の少なくとも1つの新たなデータ・シーケンスは、イベントを指定するグラフィカル・プロセス・イベント・データと、グラフィカル・プロセス・イベントの状態情報とを備えている。
一実施形態のグラフィカル・プロセス・イベント・データおよび状態情報は、グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、このデータ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、グラフィカル・オブジェクトおよびポインタ・オブジェクトの内少なくとも1つをディスプレイ上にレンダリングする際に、少なくとも1つの新たなデータ・シーケンスを用いる。
一実施形態の認識したデータ・カプセルの内容に適した処理は、グラフィカル・オブジェクトのレンダリングを含み、グラフィカル・オブジェクトが少なくとも1つの処理デバイスのディスプレイ上にレンダリングされる。
一実施形態のレンダリングするステップは、直接レンダリングを行い、複数のプロセスが少なくとも1つの処理デバイスのグラフィクス・レイヤに直接描画を行い、複数のプロセス間においてレンダリングに適するような調整を行うために複数のプールを用いる。
一実施形態のレンダリングするステップは、レンダリング・コマンドを備えているデータ・カプセルを複数のプールに転送する複数のプロセスを備えている。一実施形態のレンダリングするステップは、レンダリング・コマンドを複数のプールから引き出し、レンダリング・コマンドを解釈し、レンダリング・コマンドに応答して少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする複数のプロセスを備えている。
一実施形態のレンダリングするステップは、画素バッファにレンダリングする複数のプロセスを備えている。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールに転送する複数のプロセスを備えており、生のフレーム・データが画素バッファへのレンダリングの結果得られる。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールから引き出し、少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、生のフレーム・データを組み合わせる複数のプロセスを備えている。
一実施形態の方法は、複数のプロセスのイベントを検出するステップを備えている。一実施形態の方法は、イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生するステップを備えており、イベント・データおよび状態情報は、少なくとも1つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別イベント・データを含む第1個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第2個別状態情報を含む第2個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別データ集合および第2個別データ集合を含むように、第1データ・シーケンスを形成するステップを備えている。
一実施形態の第1個別データ集合を発生するステップは、少なくとも1つの処理デバイスの識別データを含むように、第1個別データ集合を形成するステップを含み、識別データは、少なくとも1つの処理デバイスを識別するデータを含む。
一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別イベント・データを含む第1個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第2個別状態情報を含む第2個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別データ集合および第2個別データ集合を含むように、第2データ・シーケンスを形成するステップを備えている。
一実施形態の第1個別データ集合を発生するステップは、第1個別データ集合オフセットを発生するステップを含み、第1個別データ集合オフセットは、第2データ・シーケンスの第1個別データ集合を指し示す。
一実施形態の第2個別データ集合を発生するステップは、第2個別データ集合オフセットを発生するステップを含み、第2個別データ集合オフセットは、第2データ・シーケンスの第2個別データ集合を指し示す。
一実施形態の第1個別データ集合は、記述リストであり、この記述リストは、データの記述を含む。
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも1つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットを含むように、データ・カプセルを形成するステップを備えている。
一実施形態の方法は、第1可変長を有する第1オフセットを発生するステップを備えており、記第1オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスのイベント・データを指し示す。
一実施形態の方法は、第2可変長を有する第2オフセットを発生するステップを備えており、第2オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスの状態情報を指し示す。
一実施形態の方法は、少なくとも1つのオフセットの内第1オフセットを用いて、データ・カプセルを通過する第1コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットの内第2オフセットを用いて、データ・カプセルを通過する第2コード経路を形成するステップを備えており、第1コード経路および第2コード経路は、異なる経路である。
一実施形態の第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータは、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
一実施形態の方法は、データ・カプセルの長さを含むヘッダを発生するステップを備えている。一実施形態の方法は、ヘッダを含むようにデータ・カプセルを形成するステップを備えている。
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、少なくとも1つの処理デバイスの第2イベントを検出するステップを備えている。一実施形態の方法は、複数のプールを検索して、第2イベントに対応するデータ・カプセルを求めるステップを備えている。
一実施形態の方法は、データ・カプセルと第2イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、特定に応答して、プールからデータ・カプセルを抽出するステップを備えている。一実施形態の方法は、データ・カプセルの内容に応答して、少なくとも1つの処理デバイスの代わりに、第2イベントに対応する処理動作を実行するステップを備えており、少なくとも1つの処理デバイスが第1タイプのアプリケーションおよび第2タイプのアプリケーションに対応する。
一実施形態の複数のプールが複数のアプリケーションに結合されており、複数のプールは、複数のアプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、複数のアプリケーションによる複数のデータ・カプセルへのアクセスに備えており、複数のアプリケーションの内少なくとも2つのアプリケーションが異なるアプリケーションである。
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
転送するステップは、第1アプリケーション・タイプを有する第1アプリケーションから少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションにデータ・カプセルを転送するステップを含み、第1アプリケーション・タイプが第2アプリケーション・タイプとは異なり、少なくとも1つのデータ・シーケンスを発生するステップは、第1アプリケーションによって実行され、本方法は、転送するステップの間、データ・カプセルの少なくとも1つのデータ・シーケンスをそのまま保持するステップを備えている。
一実施形態の方法は、第2アプリケーションの動作中少なくとも1つのデータ・シーケンスを用いるステップを備えている。
一実施形態の方法は、イベント・データと、少なくとも1つの処理デバイスのソース・デバイスの識別データとを含む第1データ集合を発生するステップを備えており、デバイス・イベント・データは、ソース・デバイスによって登録されたイベントを指定するデータを含み、識別データは、ソース・デバイスを識別するデータを含む。
一実施形態の方法は、イベントの完全な1組の状態情報を含む第2データ集合を発生するステップを備えており、第1データ集合および第2データ集合の各々は、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている。
一実施形態の変換するステップは、第1データ集合および第2データ集合を含むようにデータ・カプセルを形成することによって、第1データ集合および第2データ集合をカプセル化するステップを備えており、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の方法は、第1タイプのアプリケーションの下で起動する第1処理デバイスのイベントを検出するステップと、第1処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、イベント・データがイベントおよびこのイベントの状態情報を指定し、イベント・データおよび状態情報は、アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、データ・カプセルは、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する、ステップと、少なくとも1つの第2タイプを有する少なくとも1つの第2アプリケーションの下で起動する第2処理デバイスの第2イベントを検出するステップであって、第2タイプが第1タイプとは異なり、少なくとも1つの処理デバイスは、第1処理デバイスおよび第2処理デバイスを含み、データ・カプセルと第2イベントとの間における対応を特定するステップと、第2イベントに応答して、データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップとを備えている。
一実施形態のデータ・シーケンスを発生するステップは、イベント・データを含む第1データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、状態情報を含む第2データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、第1データ集合および第2データ集合を含むように第1データ・シーケンスを形成するステップとを備えている。
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも1つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットを含むようにデータ・カプセルを形成するステップを備えている。
一実施形態の方法は、第1可変長を有する第1オフセットを発生するステップを備えており、第1オフセットが、少なくとも1つのデータ・シーケンスの第1データ・シーケンスのイベント・データを指し示す。一実施形態の方法は、第2可変長を有する第2オフセットを発生するステップを備えており、第2オフセットが、少なくとも1つのデータ・シーケンスの第1データ・シーケンスの状態情報を指し示す。
一実施形態の方法は、少なくとも1つのオフセットの内第1オフセットを用いて、データ・カプセルを通過する第1コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットの内第2オフセットを用いて、データ・カプセルを通過する第2コード経路を形成するステップを備えており、第1コード経路および第2コード経路が異なる経路である。
一実施形態の第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、複数のプールを検索して、第2イベントに対応するデータ・カプセルを求めるステップを備えている。一実施形態の方法は、対応を特定したことに応答して、プールからデータ・カプセルを抽出するステップを備えている。
一実施形態の複数のプールは、アプリケーションおよび少なくとも1つの第2アプリケーションに結合されており、複数のプールが、アプリケーションおよび少なくとも1つの第2アプリケーションに対応する複数のデータ・カプセルを含み、複数のプールが、アプリケーションおよび少なくとも1つの第2アプリケーションによる複数のデータ・カプセルへのアクセスを与える。
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
本明細書において記載した実施形態は、方法を含む。この方法は、アプリケーション・プログラムを複数のプロセスに分割するステップと、これら複数のプロセスの中にあるプロセスを用いて、アプリケーション・プログラムの出力の一部を発生するステップと、出力の一部を第1データ・カプセルにカプセル化し、第1データ・カプセルを複数のプールの内少なくとも1つに転送するステップであって、複数のプールが、複数のプロセスから受け取られる複数のデータ・カプセルを備えている、ステップと、複数のプールにアクセスし、複数のプロセスの内第2プロセスの入力を引き出すステップであって、入力が複数のデータ・カプセルの内第2データ・カプセルの中にある、ステップと、複数のデータ・カプセルおよび複数のプールを用いて、複数のプロセス間における処理を調整するステップとを備えている。
本明細書において記載した実施形態は、システムを含む。このシステムは、少なくとも1つの処理デバイスであって、この処理デバイスが複数のプロセスを実行し、複数のプロセスが複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備えている、処理デバイスと、少なくとも1つの処理デバイスに結合されている複数のプールと、
を備えており、少なくとも1つの処理デバイスが、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを複数のプールに転送し、データ・カプセルが、イベントのイベント・データのアプリケーション独立表現と、データ・カプセルが発したプロセスの状態情報とを含み、各プロセスが認識プロセスとして動作し、この認識プロセスが、複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、認識プロセスの識別との内少なくとも1つを備えているデータ・カプセルを認識し、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する。
本明細書において記載した実施形態は、方法を含む。この方法は、ジェスチャ・データから人が行ったジェスチャを検出するステップであって、ジェスチャ・データが検出器を通じて受け取られる、ステップと、処理デバイス上において複数のプロセスを実行するステップであって、複数のプロセスがイベントを発生し、このイベントが、ジェスチャを表す1組のイベントを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップと、データ・カプセルを複数のプールに転送するステップとを備えており、複数のプロセスの内1組のプロセスが認識プロセスとして動作し、この認識プロセスが、複数のプールにおいて、ジェスチャに対応するコンテンツを備えているデータ・カプセルを認識し、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生し、ジェスチャ信号がジェスチャを表す。
一実施形態の複数のプロセスは、空間動作アプリケーションの分離可能なプログラム実行コンテキストを含む。
一実施形態のジェスチャ・データは、ある時点および空間におけるユーザの瞬時的状態の絶対三空間位置データである。
一実施形態の方法は、ジェスチャ・データのみを用いてジェスチャを識別するステップを備えている。
一実施形態の検出するステップは、ボディの位置を検出すること、ボディの方位を検出すること、およびボディの運動を検出することの内少なくとも1つを含む。
一実施形態の方法は、ジェスチャを識別するステップを備えており、識別は、ボディの一部のポーズおよび方位の識別を含む。
一実施形態の検出するステップは、ボディの第1組の付属器官および第2組の付属器官の内少なくとも1つを検出するステップを含む。
一実施形態の検出するステップは、ボディに結合されている少なくとも1つのタグの位置を動的に検出するステップを含む。
一実施形態の検出するステップは、ボディに結合されている1組のタグの位置を検出するステップを含む。
一実施形態の1組のタグにおける各タグがパターンを含み、1組のタグにおける各タグの各パターンが、複数のタグにおけるいずれの残りのタグのいずれのパターンとも異なる。
一実施形態の検出するステップは、ボディ上にあるマーカを動的に検出し位置を突き止めるステップを含む。
一実施形態の検出するステップは、ボディに結合されている1組のマーカの位置を検出するステップを含む。
一実施形態の1組のマーカがボディ上において複数のパターンを形成する。
一実施形態の検出するステップは、ボディの複数の付属器官の各々に結合されている1組のマーカを用いて、付属器官の位置を検出するステップを含む。
一実施形態の変換するステップは、ジェスチャの情報をジェスチャ表記に変換するステップを含む。
一実施形態のジェスチャ表記は、ジェスチャ・ボキャブラリを表し、ジェスチャ信号がジェスチャ・ボキャブラリの通信を含む。
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携の瞬時的ポーズ状態をテキスト形態で表す。
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携の方位をテキスト形態で表す。
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携の方位の組み合わせを、テキスト形態で表す。
一実施形態のジェスチャ・ボキャブラリは、ボディの力学的連携状態を表す、キャラクタのストリングを含む。
一実施形態の力学的連携がボディの少なくとも1つの第1付属器官である。
一実施形態の方法は、ストリングにおける各位置を第2付属器官に割り当てるステップを備えており、第2付属器官が第1付属器官に接続されている。
一実施形態の方法は、複数のキャラクタの中にあるキャラクタを、第2付属器官の複数の位置の各々に割り当てるステップを備えている。
一実施形態の複数の位置は、座標原点に対して確定される。
一実施形態の方法は、空間における絶対位置および方位、ボディの全体的な位置および方位とは無関係のボディに対する固定位置および方位から成るグループから選択された位置を用いて、更にボディのアクションにインタラクティブに応答して、座標原点を確立するステップを備えている。
一実施形態の方法は、複数のキャラクタの中にあるキャラクタを、第1付属器官の複数の方位の各々に割り当てるステップを備えている。
一実施形態の検出するステップは、ボディの外挿補間位置が仮想空間と交差するときを検出するステップを含み、仮想空間が、少なくとも1つの処理デバイスに結合されているディスプレイ・デバイス上に描画された空間を含む。
一実施形態の方法は、外挿補間位置が仮想空間と交差するときに、仮想空間において仮想オブジェクトを制御するステップを備えている。
一実施形態の制御するステップは、仮想空間における外挿位置に応答して、仮想空間における仮想オブジェクトの位置を制御するステップを備えている。
一実施形態の制御するステップが、ジェスチャに応答して、仮想空間における仮想オブジェクトの姿勢を制御するステップを含む。
一実施形態の方法は、仮想空間と物理空間との間において一致を生じさせるために、検出および制御のスケーリングを制御するステップを備えており、仮想空間がディスプレイ上に描画された空間を構成し、物理空間が、ボディが存在する空間を含む。
一実施形態の方法は、物理空間における少なくとも1つの物理オブジェクトの移動に応答して、仮想空間において少なくとも1つの仮想オブジェクトを制御するステップを備えている。
一実施形態の方法は、ジェスチャ信号を用いてコンポーネントを制御するステップを備えており、コンポーネントが少なくとも1つの処理デバイスに結合されている。
一実施形態のコンポーネントを制御するステップは、ジェスチャを三空間オブジェクトにマッピングすることによって、6自由度で同時に三空間オブジェクトを制御するステップを含む。
一実施形態のコンポーネントを制御するステップは、3空間移動自由度および3回転自由度で三空間オブジェクトを制御するステップを含む。
一実施形態の三空間オブジェクトを、少なくとも1つの処理デバイスに結合されているディスプレイ・デバイス上に呈示する。
一実施形態の三空間オブジェクトは、コンピュータに結合されている遠隔システムである。
一実施形態の方法は、ジェスチャを三空間オブジェクトの複数のオブジェクト平行移動にマッピングすることによって、三空間オブジェクトの移動を制御するステップを備えている。
一実施形態のマッピングは、ジェスチャと複数のオブジェクト平行移動との間における直接マッピングを含む。
一実施形態のマッピングは、ジェスチャと複数のオブジェクト平行移動との間における間接マッピングを含む。
一実施形態のデータ・カプセルは、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージが発生したプロセスの状態情報とを含む。
一実施形態の方法は、データ・カプセルおよび複数のプールを用いて、複数のプロセスの各々の動作を調整することによって、複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている。
一実施形態の方法は、データ・カプセルおよび複数のプールの内少なくとも1つを用いて、複数のプロセスの動作を調整するステップを備えている。
一実施形態の方法は、アプリケーション・プログラムを1組のプロセスに分割するステップを備えており、複数のプロセスが1組のプロセスを含む。
一実施形態の方法は、複数のプールの内少なくとも1つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている。
一実施形態の複数のプロセスは、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備えている。
一実施形態の方法は、複数のプロセスを並列に実行するステップを備えている。
一実施形態の方法は、第1組のプロセスを並列に実行し、第2組のプロセスを順次実行するステップを備えており、複数のプロセスが第1組のプロセスおよび第2組のプロセスを含む。
一実施形態のイベントは、プロセス入力を表す。
一実施形態のイベントは、プロセス出力を表す。
一実施形態のイベントは、ユーザ・インターフェース・イベントを備えている。
一実施形態のイベントは、グラフィクスイベントを備えている。
一実施形態のイベントは、プロセス状態を表す。
一実施形態のプロセスの状態は、当該プロセスのインタラクティブ機能を表し、プロセスのインタラクティブ機能を複数のプロセスに、データ・カプセルの内容として露出する。
一実施形態の方法は、アプリケーション・プログラミング・インターフェース(API)を関数コールによって定義する代わりに、データ・カプセルの内容によって複数のプロセスのAPIを定義するステップを備えている。
一実施形態のデータ・カプセルの内容は、アプリケーションに独立しており、複数のプロセスによって認識可能である。
一実施形態の少なくとも1つの処理デバイスは、複数の処理デバイスを備えている。
一実施形態の複数のプロセスの内少なくとも1つの第1組のプロセスは、複数の処理デバイスの内少なくとも1つの第1組の処理デバイスの下で起動し、複数のプロセスの内少なくとも1つの第2組のプロセスが、複数の処理デバイスの内少なくとも1つの第2組の処理デバイスの下で起動する。
一実施形態の複数のプロセスは、第1プロセスを含む。
一実施形態の変換するステップは、第1プロセスのイベントを、イベントを指定する第1プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態の第1プロセス・イベント・データおよび状態情報は、第1プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルが、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、第2プロセスを含む。
一実施形態の変換するステップは、第2プロセスの状態変化イベントを、イベントを指定する第2プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む。
一実施形態の第2プロセス・イベント・データおよび状態情報は、第2プロセスのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルが、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の認識プロセスは、第2プロセスであり、引き出すステップは、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容に適した処理を実行する第2プロセスを備えている。
一実施形態の認識したデータ・カプセルの内容は、第1プロセスの状態情報を表すデータである。
一実施形態の変換するステップは、認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、少なくとも1つの新たなデータ・シーケンスが、第1プロセスのイベントおよび第2プロセスのイベントの内少なくとも1つを表す。
一実施形態の少なくとも1つの新たなデータ・シーケンスは、イベントを指定するイベント・データと、第1プロセスおよび第2プロセスの内少なくとも1つの状態情報とを備えている。
一実施形態のイベント・データならびに第1プロセスおよび第2プロセスの内少なくとも1つの状態情報は、第1プロセスおよび第2プロセスの内少なくとも1つのアプリケーションに対応するタイプを有するタイプ特定データである。
一実施形態の変換するステップは、少なくとも1つの新たなデータ・シーケンスを含むようにデータ・カプセルを形成するステップを含み、データ・カプセルが、少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の複数のプロセスは、少なくとも1つの新たなデータ・シーケンスを用いる。
一実施形態の認識したデータ・カプセルの内容に適した処理は、グラフィカル・オブジェクトをレンダリングするステップを含み、少なくとも1つの処理デバイスのディスプレイ上にグラフィカル・オブジェクトをレンダリングする。
一実施形態のレンダリングするステップは、直接レンダリングを行い、複数のプロセスが少なくとも1つの処理デバイスのグラフィクス・レイヤに直接描画を行い、複数のプロセス間においてレンダリングに適するような調整を行うために複数のプールを用いる。
一実施形態のレンダリングするステップは、レンダリング・コマンドを備えているデータ・カプセルを複数のプールに転送する複数のプロセスを備えている。一実施形態のレンダリングするステップは、レンダリング・コマンドを複数のプールから引き出し、レンダリング・コマンドを解釈し、レンダリング・コマンドに応答して少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする複数のプロセスを備えている。
一実施形態のレンダリングするステップは、画素バッファにレンダリングする複数のプロセスを備えている。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールに転送する複数のプロセスを備えており、生のフレーム・データは、画素バッファへのレンダリングの結果得られる。一実施形態のレンダリングするステップは、生のフレーム・データを複数のプールから引き出し、少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、生のフレーム・データを組み合わせるプロセス複数のプロセスを備えている。
一実施形態の方法は、複数のプロセスのイベントを検出するステップを備えている。一実施形態の方法は、イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生するステップを備えており、イベント・データおよび状態情報は、少なくとも1つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別イベント・データを含む第1個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第2個別状態情報を含む第2個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別データ集合および第2個別データ集合を含むように、第1データ・シーケンスを形成するステップを備えている。
一実施形態の第1個別データ集合を発生するステップは、少なくとも1つの処理デバイスの識別データを含むように、第1個別データ集合を形成するステップを含み、識別データは、少なくとも1つの処理デバイスを識別するデータを含む。
一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別イベント・データを含む第1個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第2個別状態情報を含む第2個別データ集合を発生するステップを備えている。一実施形態の少なくとも1つのデータ・シーケンスを発生するステップは、第1個別データ集合および第2個別データ集合を含むように、第2データ・シーケンスを形成するステップとを備えている。
一実施形態の第1個別データ集合を発生するステップは、第1個別データ集合オフセットを発生するステップを含み、第1個別データ集合オフセットが、第2データ・シーケンスの第1個別データ集合を指し示す。
一実施形態の第2個別データ集合を発生するステップは、第2個別データ集合オフセットを発生するステップを含み、第2個別データ集合オフセットが、第2データ・シーケンスの第2個別データ集合を指し示す。
一実施形態の第1個別データ集合は記述リストであり、この記述リストが、データの記述を含む。
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも1つのオフセットを発生するステップを備えている。一実施形態の方法は、なくとも1つのオフセットを含むように、データ・カプセルを形成するステップを備えている。
一実施形態の方法は、第1可変長を有する第1オフセットを発生するステップを備えており、第1オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスのイベント・データを指し示す。
一実施形態の方法は、第2可変長を有する第2オフセットを発生するステップを備えており、第2オフセットは、少なくとも1つのデータ・シーケンスの第1データ・シーケンスの状態情報を指し示す。
一実施形態の方法は、少なくとも1つのオフセットの内第1オフセットを用いて、データ・カプセルを通過する第1コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットの内第2オフセットを用いて、データ・カプセルを通過する第2コード経路を形成するステップを備えており、第1コード経路および第2コード経路は、異なる経路である。
一実施形態の第1オフセットおよび第2オフセットの内少なくとも1つは、メタデータを含み、このメタデータが、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
一実施形態の方法は、データ・カプセルの長さを含むヘッダを発生するステップを備えている。 一実施形態の方法は、ヘッダを含むようにデータ・カプセルを形成するステップを備えている。
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、少なくとも1つの処理デバイスの第2イベントを検出するステップを備えている。一実施形態の方法は、複数のプールを検索して、第2イベントに対応するデータ・カプセルを求めるステップを備えている。
一実施形態の方法は、データ・カプセルと第2イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、特定に応答して、プールからデータ・カプセルを抽出するステップを備えている。一実施形態の方法は、データ・カプセルの内容に応答して、少なくとも1つの処理デバイスの代わりに、第2イベントに対応する処理動作を実行するステップを備えており、少なくとも1つの処理デバイスは、第1タイプのアプリケーションおよび第2タイプのアプリケーションに対応する。
一実施形態の複数のプールは、複数のアプリケーションに結合されており、これら複数のプールは、複数のアプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、複数のアプリケーションによる複数のデータ・カプセルへのアクセスに備えており、複数のアプリケーションの内少なくとも2つのアプリケーションは、異なるアプリケーションである。
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
一実施形態の転送するステップは、第1アプリケーション・タイプを有する第1アプリケーションから少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションにデータ・カプセルを転送するステップを含み、第1アプリケーション・タイプが第2アプリケーション・タイプとは異なり、少なくとも1つのデータ・シーケンスを発生するステップが、第1アプリケーションによって実行され、本方法は、転送するステップの間、データ・カプセルの少なくとも1つのデータ・シーケンスをそのまま保持するステップを備えている。
一実施形態の方法は、第2アプリケーションの動作中少なくとも1つのデータ・シーケンスを用いるステップを備えている。
一実施形態の方法は、イベント・データと、少なくとも1つの処理デバイスのソース・デバイスの識別データとを含む第1データ集合を発生するステップを備えており、デバイス・イベント・データが、ソース・デバイスによって登録されたイベントを指定するデータを含み、識別データが、ソース・デバイスを識別するデータを含む。
一実施形態の方法は、イベントの完全な1組の状態情報を含む第2データ集合を発生するステップを備えており、第1データ集合および第2データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている。
一実施形態の変換するステップは、第1データ集合および第2データ集合を含むようにデータ・カプセルを形成することによって、第1データ集合および第2データ集合をカプセル化するステップを備えており、データ・カプセルは、少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。
一実施形態の方法は、第1タイプのアプリケーションの下で起動する第1処理デバイスのイベントを検出するステップを備えている。一実施形態の方法は、第1処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップを備えており、イベント・データがイベントおよびこのイベントの状態情報を指定し、イベント・データおよび状態情報が、アプリケーションに対応するタイプを有するタイプ特定データである。一実施形態の方法は、データ・シーケンスを含むようにデータ・カプセルを形成するステップを備えており、このデータ・カプセルが、データ・シーケンスのアプリケーション独立表現を備えているデータ構造を有する。一実施形態の方法は、少なくとも1つの第2タイプを有する少なくとも1つの第2アプリケーションの下で起動する第2処理デバイスの第2イベントを検出するステップを備えており、第2タイプが第1タイプとは異なり、少なくとも1つの処理デバイスが、第1処理デバイスおよび第2処理デバイスを含む。一実施形態の方法は、データ・カプセルと第2イベントとの間における対応を特定するステップを備えている。一実施形態の方法は、第2イベントに応答して、データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップを備えている。
一実施形態のデータ・シーケンスを発生するステップは、イベント・データを含む第1データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、状態情報を含む第2データ集合を発生するステップを備えている。一実施形態のデータ・シーケンスを発生するステップは、第1データ集合および第2データ集合を含むように第1データ・シーケンスを形成するステップを備えている。
一実施形態のイベント・データは、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態のイベント・データは、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の状態情報は、類別されたデータを表すタグ付きバイト・シーケンスである。
一実施形態の状態情報は、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む。
一実施形態の方法は、少なくとも1つのオフセットを発生するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットを含むようにデータ・カプセルを形成するステップを備えている。
一実施形態の方法は、第1可変長を有する第1オフセットを発生するステップを備えており、第1オフセットが、少なくとも1つのデータ・シーケンスの第1データ・シーケンスのイベント・データを指し示す。一実施形態の方法は、第2可変長を有する第2オフセットを発生するステップを備えており、この第2オフセットが、少なくとも1つのデータ・シーケンスの第1データ・シーケンスの状態情報を指し示す。
一実施形態の方法は、少なくとも1つのオフセットの内第1オフセットを用いて、データ・カプセルを通過する第1コード経路を形成するステップを備えている。一実施形態の方法は、少なくとも1つのオフセットの内第2オフセットを用いて、データ・カプセルを通過する第2コード経路を形成するステップを備えており、第1コード経路および第2コード経路が異なる経路である。
一実施形態の第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む。
一実施形態の方法は、データ・カプセルを複数のプールにおけるプールに転送するステップを備えている。
一実施形態の方法は、複数のプールを検索して、第2イベントに対応するデータ・カプセルを求めるステップを備えている。一実施形態の方法は、対応を特定したことに応答して、プールからデータ・カプセルを抽出するステップを備えている。
一実施形態の複数のプールは、アプリケーションおよび少なくとも1つの第2アプリケーションに結合されており、複数のプールは、アプリケーションおよび少なくとも1つの第2アプリケーションに対応する複数のデータ・カプセルを含み、複数のプールは、アプリケーションおよび少なくとも1つの第2アプリケーションによる複数のデータ・カプセルへのアクセスを与える。
一実施形態の複数のプールは、複数のデータ・カプセルの状態のキャッシュに備えている。
一実施形態の複数のプールは、複数のデータ・カプセルの線形シーケンスに備えている。
一実施形態のデータ構造は、類別されていない。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報のプラットフォームに独立した表現を与える。
一実施形態のデータ・カプセルのデータ構造は、イベント・データおよび状態情報へのプラットフォームに独立したアクセスを与える。
本明細書において記載した実施形態は、方法を含む。この方法は、処理デバイス上において複数のプロセスを実行するステップであって、複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを含む、ステップと、複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、データ・メッセージが、イベントのイベント・データのアプリケーションに独立した表現と、データ・メッセージを発したプロセスの状態情報とを含む、ステップと、データ・メッセージを、複数のプールの内少なくとも1つのプールに転送するステップと、プロセス間において調整を行うステップであって、この調整が、複数のプールからピア・プロセスの状態情報を引き出すことによって、複数のプロセスの各プロセスが、複数のプロセスのピア・プロセスと対等になることを含む、ステップと、複数のプールの内少なくとも1つのプールの1組のデータ・メッセージをインタラクティブに組み合わせることによって、複数のプロセスの出力を発生するステップとを備えている。
本明細書において記載した実施形態は、システムを含む。このシステムは、ボディによって行われたジェスチャを表すジェスチャ・データを受け取る検出器と、検出器に結合されているプロセッサであって、このプロセッサがジェスチャ・データから自動的にジェスチャを検出し、プロセッサが複数のプロセスを実行し、これら複数のプロセスが、ジェスチャを表す1組のイベントを含むイベントを発生し、プロセッサが、複数のプロセスにおける各プロセスのイベントをデータ・カプセルに変換し、プロセッサがデータ・カプセルを複数のプールに転送し、複数のプロセスの内1組のプロセスが、認識プロセスとして機能し、この認識プロセスが、複数のプールにおいて、ジェスチャに対応する内容を備えているデータ・カプセルを認識し、認識プロセスが、認識したデータ・カプセルを複数のプールから引き出し、認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、認識したデータ・カプセルからジェスチャ信号を発生し、ジェスチャ信号がジェスチャを表す、プロセッサとを備えている。
本明細書において記載したシステムおよび方法は、処理システムを含む、および/または処理システムの下で実行する、および/または処理システムと連動して実行する。処理システムは、当技術分野では周知のように、互いに動作するプロセッサ主体デバイスまたは計算デバイスのあらゆる集合体、あるいは処理システムまたはデバイスのコンポーネントを含む。例えば、処理システムは、携帯用コンピュータ、通信ネットワークにおいて動作する携帯用通信デバイス、および/またはネットワーク・サーバの1つ以上を含むことができる。携帯用コンピュータは、パーソナル・コンピュータ、セルラ電話機、パーソナル・ディジタル・アシスタント、携帯用計算デバイス、および携帯用通信デバイスの中から選択した多数のデバイスおよび/またはデバイスの組み合わせのいずれとすることもできるが、そのように限定されるのではない。処理システムは、それよりも大きなコンピュータ・システムの中にあるコンポーネントを含むことができる。
一実施形態の処理システムは、少なくとも1つのプロセッサと、少なくとも1つのメモリ・デバイスまたはサブシステムとを含む。また、処理システムは、少なくとも1つのデータベースを含むか、またはこれに結合することができる。「プロセッサ」という用語は、本明細書において一般に用いる場合、1つ以上の中央演算装置(CPU)、ディジタル信号プロセッサ(DSP)、特定用途集積回路(ASIC)等のような、あらゆる論理演算装置を指す。プロセッサおよびメモリは、1つのチップ上にモノリシックに集積することができ、多数のチップまたはホスト・システムのコンポーネント間で分散することができ、および/またはアルゴリズムの何らかの組み合わせによって提供することができる。本明細書において記載した方法は、ソフトウェア・アルゴリズム(1つまたは複数)、プログラム、ファームウェア、ハードウェア、コンポーネント、回路の1つ以上で、いずれの組み合わせでも実現することができる。
本明細書において記載したシステムおよび方法を具体化するシステム・コンポーネントは、一緒に配置すること、または別個の位置に配置することができる。したがって、本明細書において記載したシステムおよび方法を具現化するシステム・コンポーネントは、単一のシステム、多数のシステム、および/または地理的に離れたシステムのコンポーネントとすることができる。また、これらのコンポーネントは、単一のシステム、多数のシステム、および/または地理的に離れたシステムのサブコンポーネントまたはサブシステムとすることもできる。これらのコンポーネントは、ホスト・システムの1つ以上のその他のコンポーネント、またはホスト・システムに結合されているシステムに結合することができる。
通信経路は、システム・コンポーネントを結合し、コンポーネント間においてファイルを伝達または転送する媒体であればいずれでも含む。通信経路は、ワイヤレス接続、有線接続、混成ワイヤレス/有線接続を含む。また、通信経路は、ローカル・エリア・ネットワーク(LAN)、都市エリア・ネットワーク(MAN)、ワイド・エリア・ネットワーク(WAN)、企業固有ネットワーク、事務所間またはバックエンド・ネットワーク、およびインターネットを含むネットワークへの結合または接続も含む。更に、通信経路は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびCD−ROMディスクのような、リムーバブル固定媒体、ならびにフラッシュRAM、ユニバーサル・シリアル・バス(USB)接続、RS−232接続、電話回線、バス、および電子メール・メッセージを含む。
文脈が特に明確に要求しない限り、説明全体を通じて、「備える」(comprise)、「備えている」(comprising)等の単語は、排他的または網羅的な意味とは逆に、包含的意味で解釈することとする。即ち、「含むがそれに限定されない」という意味である。また、単数または複数を用いる単語は、それぞれ、複数または単数も含むこととする。加えて、「ここでは」(herein)、「以下では」(hereunder)、「以上」(above)、「以下」(below)および同様の趣旨の単語は、本願のいずれかの特定部分ではなく、本願全体を指すこととする。「または」という単語が2つ以上の項目のリストに関して用いられる場合、その単語は以下の単語の解釈全てに及ぶこととする。リストにおける項目のいずれか、リストにおける項目全て、およびリストにおける項目のあらゆる組み合わせ。
以上における実施形態の説明は、網羅的であることも、記載したシステムおよび方法を、開示した形態そのものに限定することも意図していない。具体的な実施形態およびその例は、本明細書では例示の目的で記載したが、その他のシステムおよび方法の範囲内において、種々の同等な修正も可能であることは、当業者であれば認められよう。本明細書において提案した教示は、前述のシステムおよび方法だけでなく、他の処理システムおよび方法にも適用することができる。
以上で説明した種々の実施形態の要素および動作(act)を組み合わせて、更に別の実施形態を提案することができる。これらおよびその他の変更は、以上に詳細に記載した説明を参照すれば、実施形態に対して行うことができる。
一般に、以下の特許請求の範囲では、前述の実施形態を本明細書および特許請求の範囲に開示される実施形態に限定するように、用いられる用語を解釈してはならず、特許請求の範囲の下で動作する全てのシステムを含むように解釈してしかるべきである。したがって、前述の実施形態は、本明細書における開示に限定されるのではなく、代わりに、実施形態の範囲は、特許請求の範囲によって全体的に判断されるものとする。
以上の実施形態のある種の態様が、以下にある種の請求項の形態で提示されるが、本発明者は、これら実施形態の種々の態様を、いかなる数の請求項の形態でも想定している。したがって、本発明者は、本願を出願した後に本実施形態の他の態様に対してこのような追加の請求項の形態を追求するために、追加の請求項を加える権利を保持することとする。

Claims (331)

  1. 少なくとも1つの処理デバイス上において複数のプロセスを実行するステップであって、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
    前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップであって、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含んでいる、ステップと、
    前記データ・カプセルを複数のプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含んでいる、ステップと、
    各プロセスが認識プロセスとして動作するステップであって、前記認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、当該認識プロセスの識別との内少なくとも1つを備えているデータ・カプセルを認識する、ステップと、
    前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行するステップと、
    を備えている、方法。
  2. 請求項1記載の方法において、データ・カプセルが、データ・メッセージが発生したプロセスの状態情報をさらに含む、方法。
  3. 請求項1記載の方法であって、前記データ・カプセルおよび前記複数のプールを用いて、前記複数のプロセスの各々の動作を調整することによって、前記複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている、方法。
  4. 請求項1記載の方法であって、前記データ・カプセルおよび前記複数のプールの内少なくとも1つを用いて、前記複数のプロセスの動作を調整するステップを備えている、方法。
  5. 請求項1記載の方法であって、アプリケーション・プログラムを1組のプロセスに分割するステップを備えており、前記複数のプロセスが前記1組のプロセスを含む、方法。
  6. 請求項1記載の方法であって、前記複数のプールの内少なくとも1つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている、方法。
  7. 請求項1記載の方法において、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備えている、方法。
  8. 請求項1記載の方法であって、前記複数のプロセスを並列に実行するステップを備えている、方法。
  9. 請求項1記載の方法であって、第1組のプロセスを並列に実行し、第2組のプロセスを順次実行するステップを備えており、前記複数のプロセスが前記第1組のプロセスおよび前記第2組のプロセスを含む、方法。
  10. 請求項1記載の方法において、前記イベントがプロセス入力を表す、方法。
  11. 請求項1記載の方法において、前記イベントがプロセス出力を表す、方法。
  12. 請求項1記載の方法において、前記イベントがユーザ・インターフェース・イベントを備えている、方法。
  13. 請求項1記載の方法において、前記イベントがグラフィクスイベントを備えている、方法。
  14. 請求項1記載の方法において、前記イベントがプロセスの状態を表す、方法。
  15. 請求項14記載の方法において、プロセスの状態が、当該プロセスのインタラクティブ機能を表し、前記プロセスのインタラクティブ機能を複数のプロセスに、前記データ・カプセルの内容として露出する、方法。
  16. 請求項15記載の方法であって、アプリケーション・プログラミング・インターフェース(API)を関数コールによって定義する代わりに、前記データ・カプセルの内容によって前記複数のプロセスのAPIを定義するステップを備えている、方法。
  17. 請求項16記載の方法において、前記データ・カプセルの内容が、アプリケーション独立表現であり、前記複数のプロセスによって認識可能である、方法。
  18. 請求項1記載の方法において、前記少なくとも1つの処理デバイスが、複数の処理デバイスを備えている、方法。
  19. 請求項18記載の方法において、前記複数のプロセスの内少なくとも1つの第1組のプロセスが、前記複数の処理デバイスの内少なくとも1つの第1組の処理デバイスの下で起動し、前記複数のプロセスの内少なくとも1つの第2組のプロセスが、前記複数の処理デバイスの内少なくとも1つの第2組の処理デバイスの下で起動する、方法。
  20. 請求項19記載の方法において、前記複数のプロセスが第1プロセスを含む、方法。
  21. 請求項20記載の方法であって、前記変換するステップが、前記第1プロセスのイベントを、前記イベントを指定する第1プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  22. 請求項21記載の方法において、前記第1プロセス・イベント・データおよび状態情報が、前記第1プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  23. 請求項22記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  24. 請求項20記載の方法において、前記複数のプロセスが第2プロセスを含む、方法。
  25. 請求項24記載の方法において、前記変換するステップが、前記第2プロセスの状態変化イベントを、前記イベントを指定する第2プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  26. 請求項25記載の方法において、前記第2プロセス・イベント・データおよび状態情報が、前記第2プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  27. 請求項26記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  28. 請求項24記載の方法において、前記認識プロセスが前記第2プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記第2プロセスを備えている、方法。
  29. 請求項28記載の方法において、前記認識したデータ・カプセルの内容が、前記第1プロセスの状態情報を表すデータである、方法。
  30. 請求項29記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも1つの新たなデータ・シーケンスが、前記第1プロセスのイベントおよび前記第2プロセスのイベントの内少なくとも1つを表す、方法。
  31. 請求項30記載の方法において、前記少なくとも1つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、前記第1プロセスおよび前記第2プロセスの内少なくとも1つの状態情報とを備えている、方法。
  32. 請求項31記載の方法において、前記イベント・データならびに前記第1プロセスおよ
    び前記第2プロセスの内少なくとも1つの状態情報が、前記第1プロセスおよび前記第2プロセスの内前記少なくとも1つのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  33. 請求項32記載の方法において、前記変換するステップが、前記少なくとも1つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  34. 請求項33記載の方法において、前記複数のプロセスが前記少なくとも1つの新たなデータ・シーケンスを用いる、方法。
  35. 請求項1記載の方法において、前記認識したデータ・カプセルの内容に適した前記処理が、グラフィカル・オブジェクトをレンダリングするステップを含み、前記少なくとも1つの処理デバイスのディスプレイ上に前記グラフィカル・オブジェクトをレンダリングする、方法。
  36. 請求項35記載の方法において、前記レンダリングするステップが、直接レンダリングを行い、前記複数のプロセスが前記少なくとも1つの処理デバイスのグラフィクス・レイヤに直接描画を行い、前記複数のプロセス間において前記レンダリングに適するような調整を行うために前記複数のプールを用いる、方法。
  37. 請求項35記載の方法において、前記レンダリングするステップが、
    レンダリング・コマンドを備えているデータ・カプセルを前記複数のプールに転送するプロセスと、
    前記レンダリング・コマンドを前記複数のプールから引き出し、前記レンダリング・コマンドを解釈し、前記レンダリング・コマンドに応答して前記少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブするプロセスと、
    を含む、複数のプロセスを備えている、方法。
  38. 請求項35記載の方法において、前記レンダリングするステップが、
    画素バッファにレンダリングするプロセスと、
    生のフレーム・データを前記複数のプールに転送するプロセスであって、前記生のフレーム・データが前記画素バッファへのレンダリングの結果得られる、プロセスと、
    前記生のフレーム・データを前記複数のプールから引き出し、前記少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、前記生のフレーム・データを組み合わせるプロセスと、
    を含む、複数のプロセスを備えている、方法。
  39. 請求項1記載の方法であって、
    前記複数のプロセスのイベントを検出するステップと、
    前記イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生するステップであって、前記イベント・データおよび状態情報が、前記少なくとも1つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
    前記少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
    を備えている、方法。
  40. 請求項39記載の方法において、前記少なくとも1つのデータ・シーケンスを発生する前記ステップが、
    第1個別イベント・データを含む第1個別データ集合を発生するステップと、
    第2個別状態情報を含む第2個別データ集合を発生するステップと、
    前記第1個別データ集合および前記第2個別データ集合を含むように、第1データ・シーケンスを形成するステップと、
    を備えている、方法。
  41. 請求項40記載の方法において、前記第1個別データ集合を発生する前記ステップが、前記少なくとも1つの処理デバイスの識別データを含むように、前記第1個別データ集合を形成するステップを含み、前記識別データが、前記少なくとも1つの処理デバイスを識別するデータを含む、方法。
  42. 請求項40記載の方法において、前記少なくとも1つのデータ・シーケンスを発生する前記ステップが、
    第1個別イベント・データを含む第1個別データ集合を発生するステップと、
    第2個別状態情報を含む第2個別データ集合を発生するステップと、
    前記第1個別データ集合および前記第2個別データ集合を含むように、第2データ・シーケンスを形成するステップと、
    を備えている、方法。
  43. 請求項42記載の方法において、前記第1個別データ集合を発生する前記ステップが、第1個別データ集合オフセットを発生するステップを含み、前記第1個別データ集合オフセットが、前記第2データ・シーケンスの前記第1個別データ集合を指し示す、方法。
  44. 請求項42記載の方法において、前記第2個別データ集合を発生する前記ステップが、第2個別データ集合オフセットを発生するステップを含み、前記第2個別データ集合オフセットが、前記第2データ・シーケンスの前記第2個別データ集合を指し示す、方法。
  45. 請求項40記載の方法において、前記第1個別データ集合が、記述リストであり、この記述リストが、前記データの記述を含む、方法。
  46. 請求項39記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  47. 請求項46記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  48. 請求項39記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  49. 請求項48記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  50. 請求項39記載の方法であって、
    少なくとも1つのオフセットを発生するステップと、
    前記少なくとも1つのオフセットを含むように、前記データ・カプセルを形成するステップと、
    を備えている、方法。
  51. 請求項50記載の方法であって、
    第1可変長を有する第1オフセットを発生するステップを備えており、
    前記第1オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記イベント・データを指し示す、方法。
  52. 請求項50記載の方法であって、
    第2可変長を有する第2オフセットを発生するステップを備えており、
    前記第2オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記状態情報を指し示す、方法。
  53. 請求項50記載の方法であって、
    前記少なくとも1つのオフセットの内第1オフセットを用いて、前記データ・カプセルを通過する第1コード経路を形成するステップと、
    前記少なくとも1つのオフセットの内第2オフセットを用いて、前記データ・カプセルを通過する第2コード経路を形成する、ステップと、
    を備えており、
    前記第1コード経路および前記第2コード経路が異なる経路である、方法。
  54. 請求項50記載の方法において、第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
  55. 請求項39記載の方法であって、
    前記データ・カプセルの長さを含むヘッダを発生するステップと、
    前記ヘッダを含むように前記データ・カプセルを形成するステップと、
    を備えている、方法。
  56. 請求項39記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
  57. 請求項56記載の方法であって、
    前記少なくとも1つの処理デバイスの第2イベントを検出するステップと、
    前記複数のプールを検索して、前記第2イベントに対応するデータ・カプセルを求めるステップと、
    を備えている、方法。
  58. 請求項57記載の方法であって、
    前記データ・カプセルと前記第2イベントとの間における対応を特定するステップと、
    前記特定に応答して、前記プールから前記データ・カプセルを抽出するステップと、
    前記データ・カプセルの内容に応答して、前記少なくとも1つの処理デバイスの代わりに、前記第2イベントに対応する処理動作を実行するステップであって、前記少なくとも1つの処理デバイスが第1タイプのアプリケーションおよび第2タイプのアプリケーションに対応する、ステップと、
    を備えている、方法。
  59. 請求項56記載の方法において、前記複数のプールが複数のアプリケーションに結合されており、前記複数のプールが、前記複数のアプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記複数のアプリケーションによる前記複数のデータ・カプセルへのアクセスに備えており、前記複数のアプリケーションの内少なくとも2つのアプリケーションが異なるアプリケーションである、方法。
  60. 請求項56記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
  61. 請求項56記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
  62. 請求項39記載の方法において、前記データ構造が、類別されていない、方法。
  63. 請求項39記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
  64. 請求項39記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
  65. 請求項39記載の方法において、前記転送するステップが、第1アプリケーション・タイプを有する第1アプリケーションから少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションに前記データ・カプセルを転送するステップを含み、前記第1アプリケーション・タイプが前記第2アプリケーション・タイプとは異なり、前記少なくとも1つのデータ・シーケンスを発生するステップが、前記第1アプリケーションによって実行され、前記方法が、前記転送するステップの間、前記データ・カプセルの少なくとも1つのデータ・シーケンスをそのまま保持するステップを備えている、方法。
  66. 請求項65記載の方法であって、前記第2アプリケーションの動作中、前記少なくとも1つのデータ・シーケンスを用いるステップを備えている、方法。
  67. 請求項39記載の方法であって、イベント・データと、前記少なくとも1つの処理デバイスのソース・デバイスの識別データとを含む第1データ集合を発生するステップを備えており、デバイス・イベント・データが、前記ソース・デバイスによって登録されたイベントを指定するデータを含み、前記識別データが、前記ソース・デバイスを識別するデータを含む、方法。
  68. 請求項67記載の方法であって、前記イベントの完全な1組の状態情報を含む第2データ集合を発生するステップを備えており、前記第1データ集合および前記第2データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている、方法。
  69. 請求項68記載の方法において、前記変換するステップが、前記第1データ集合および前記第2データ集合を含むようにデータ・カプセルを形成することによって、前記第1データ集合および前記第2データ集合をカプセル化するステップを備えており、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  70. 請求項39記載の方法であって、
    第1タイプのアプリケーションの下で起動する第1処理デバイスのイベントを検出するステップと、
    前記第1処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、前記イベント・データが前記イベントおよびこのイベントの状態情報を指定
    し、前記イベント・データおよび状態情報が、前記アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
    前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
    少なくとも1つの第2タイプを有する少なくとも1つの第2アプリケーションの下で起動する第2処理デバイスの第2イベントを検出するステップであって、前記第2タイプが前記第1タイプとは異なり、前記少なくとも1つの処理デバイスが、前記第1処理デバイスおよび前記第2処理デバイスを含み、
    前記データ・カプセルと前記第2イベントとの間における対応を特定するステップと、
    前記第2イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップと、
    を備えている、方法。
  71. 請求項70記載の方法において、前記データ・シーケンスを発生する前記ステップが、
    前記イベント・データを含む第1データ集合を発生するステップと、
    前記状態情報を含む第2データ集合を発生するステップと、
    前記第1データ集合および前記第2データ集合を含むように第1データ・シーケンスを形成するステップと、
    を備えている、方法。
  72. 請求項70記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  73. 請求項72記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  74. 請求項70記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  75. 請求項74記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  76. 請求項70記載の方法であって、
    少なくとも1つのオフセットを発生するステップと、
    前記少なくとも1つのオフセットを含むように前記データ・カプセルを形成するステップと、
    を備えている、方法。
  77. 請求項76記載の方法であって、
    第1可変長を有する第1オフセットを発生するステップであって、前記第1オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記イベント・データを指し示す、ステップと、
    第2可変長を有する第2オフセットを発生するステップであって、前記第2オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記状態情報を指し示す、ステップと、
    を備えている、方法。
  78. 請求項76記載の方法であって、
    前記少なくとも1つのオフセットの内第1オフセットを用いて、前記データ・カプセル
    を通過する第1コード経路を形成するステップと、
    前記少なくとも1つのオフセットの内第2オフセットを用いて、前記データ・カプセルを通過する第2コード経路を形成する、ステップと、
    を備えており、
    前記第1コード経路および前記第2コード経路が異なる経路である、方法。
  79. 請求項76記載の方法において、第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
  80. 請求項70記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
  81. 請求項80記載の方法であって、
    前記複数のプールを検索して、前記第2イベントに対応するデータ・カプセルを求めるステップと、
    前記対応を特定したことに応答して、前記プールから前記データ・カプセルを抽出するステップと、
    を備えている、方法。
  82. 請求項80記載の方法において、前記複数のプールが前記アプリケーションおよび前記少なくとも1つの第2アプリケーションに結合されており、前記複数のプールが、前記アプリケーションおよび前記少なくとも1つの第2アプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記アプリケーションおよび前記少なくとも1つの第2アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法。
  83. 請求項80記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
  84. 請求項80記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
  85. 請求項70記載の方法において、前記データ構造が、類別されていない、方法。
  86. 請求項70記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
  87. 請求項70記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
  88. 処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを含み、かつ、各プロセスが、対応するプロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
    前記複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、データ・メッセージが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変
    換されたデータと、前記データ・メッセージを発したプロセスの状態情報とを含む、ステップと、
    前記データ・メッセージを、複数のプールの内少なくとも1つのプールに転送するステップであって、各プールが、前記複数のプロセスによって生成されたデータ・メッセージを含んでいる、ステップと、
    前記プロセス間において調整を行うステップであって、この調整が、前記複数のプロセスの各プロセスが、前記複数のプールからピア・プロセスの状態情報を引き出すことによって、前記複数のプロセスの前記ピア・プロセスと対等になることを含む、ステップと、
    前記複数のプールの内少なくとも1つのプールの1組のデータ・メッセージをインタラクティブに組み合わせることによって、前記複数のプロセスの出力を発生するステップと、
    を備えている、方法。
  89. 複数のプロセスを実行する少なくとも1つの処理デバイスであって、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する少なくとも1つの処理デバイスと、
    前記少なくとも1つの処理デバイスに結合されている複数のプールと、
    を備えており、
    前記少なくとも1つの処理デバイスが、前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを前記複数のプールに転送し、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含み、各プールが、前記複数のプロセスによって生成されたデータ・カプセルを含んでおり、
    前記複数のプロセスの各プロセスが、認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、前記認識プロセスの識別との内少なくとも1つを備えているデータ・カプセルを認識し、
    前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する、システム。
  90. 少なくとも1つの処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを含み、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
    前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換するステップであって、データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータと、前記データ・カプセルを発したプロセスの状態情報とを含む、ステップと、
    前記データ・カプセルを、複数のプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含んでいる、ステップと、
    各プロセスが認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、前記認識プロセスの識別との少なくとも1つを備えているデータ・カプセルを認識するステップと、
    前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行するステップと、
    を備えている、方法。
  91. 請求項90記載の方法であって、前記データ・カプセルおよび前記複数のプールを用いて、前記複数のプロセスの各々の動作を調整することによって、前記複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている、方法。
  92. 請求項90記載の方法であって、前記データ・カプセルおよび前記複数のプールの内少なくとも1つを用いて、前記複数のプロセスの動作を調整するステップを備えている、方法。
  93. 請求項90記載の方法であって、アプリケーション・プログラムを1組のプロセスに分割するステップを備えており、前記複数のプロセスが前記1組のプロセスを含む、方法。
  94. 請求項90記載の方法であって、前記複数のプールの内少なくとも1つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている、方法。
  95. 請求項90記載の方法の方法であって、前記複数のプロセスを並列に実行するステップを備えている、方法。
  96. 請求項90記載の方法であって、第1組のプロセスを並列に実行し、第2組のプロセスを順次実行するステップを備えており、前記複数のプロセスが前記第1組のプロセスおよび前記第2組のプロセスを含む、方法。
  97. 請求項90記載の方法において、前記イベントがプロセス入力を表す、方法。
  98. 請求項90記載の方法において、前記イベントがプロセス出力を表す、方法。
  99. 請求項90記載の方法において、前記イベントがユーザ・インターフェース・イベントを備えている、方法。
  100. 請求項90記載の方法において、前記イベントがグラフィクスイベントを備えている、方法。
  101. 請求項90記載の方法において、前記イベントがプロセスの状態を表す、方法。
  102. 請求項101記載の方法において、プロセスの状態が、当該プロセスのインタラクティブ機能を表し、前記プロセスのインタラクティブ機能を複数のプロセスに、前記データ・カプセルの内容として露出する、方法。
  103. 請求項102記載の方法であって、アプリケーション・プログラミング・インターフェース(API)を関数コールによって定義する代わりに、前記データ・カプセルの内容によって前記複数のプロセスのAPIを定義するステップを備えている、方法。
  104. 請求項103記載の方法において、前記データ・カプセルの内容が、アプリケーションに依存せず、前記複数のプロセスによって認識可能である、方法。
  105. 請求項90記載の方法において、前記少なくとも1つの処理デバイスが、複数の処理デバイスを備えている、方法。
  106. 請求項105記載の方法において、前記複数のプロセスの内少なくとも1つの第1組のプロセスが、前記複数の処理デバイスの内少なくとも1つの第1組の処理デバイスの下で
    起動し、前記複数のプロセスの内少なくとも1つの第2組のプロセスが、前記複数の処理デバイスの内少なくとも1つの第2組の処理デバイスの下で起動する、方法。
  107. 請求項90記載の方法において、前記複数のプロセスが第1プロセスを含む、方法。
  108. 請求項107記載の方法であって、前記変換するステップが、前記第1プロセスのイベントを、前記イベントを指定する第1プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  109. 請求項108記載の方法において、前記第1プロセス・イベント・データおよび状態情報が、前記第1プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  110. 請求項109記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  111. 請求項107記載の方法において、前記複数のプロセスが第2プロセスを含む、方法。
  112. 請求項111記載の方法において、前記変換するステップが、前記第2プロセスの状態変化イベントを、前記イベントを指定する第2プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  113. 請求項112記載の方法において、前記第2プロセス・イベント・データおよび状態情報が、前記第2プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  114. 請求項113記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  115. 請求項111記載の方法において、前記認識プロセスが前記第2プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記第2プロセスを備えている、方法。
  116. 請求項115記載の方法において、前記認識したデータ・カプセルの内容が、前記第1プロセスの状態情報を表すデータである、方法。
  117. 請求項116記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも1つの新たなデータ・シーケンスが、前記第1プロセスのイベントおよび前記第2プロセスのイベントの内少なくとも1つを表す、方法。
  118. 請求項117記載の方法において、前記少なくとも1つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、前記第1プロセスおよび前記第2プロセ
    スの内少なくとも1つの状態情報とを備えている、方法。
  119. 請求項118記載の方法において、前記イベント・データならびに前記第1プロセスおよび前記第2プロセスの内少なくとも1つの状態情報が、前記第1プロセスおよび前記第2プロセスの内前記少なくとも1つのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  120. 請求項119記載の方法において、前記変換するステップが、前記少なくとも1つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  121. 請求項120記載の方法において、前記複数のプロセスが前記少なくとも1つの新たなデータ・シーケンスを用いる、方法。
  122. 請求項90記載の方法において、前記複数のプロセスが入力プロセスを含み、この入力プロセスが入力イベントを入力デバイスから受ける、方法。
  123. 請求項122記載の方法において、前記変換するステップが、前記入力デバイスの入力イベントを、前記イベントを指定する入力デバイス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  124. 請求項123記載の方法において、前記入力デバイス・イベント・データおよび状態情報が、ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  125. 請求項124記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  126. 請求項90記載の方法において、前記複数のプロセスがポインタ・プロセスを含む、方法。
  127. 請求項126記載の方法において、前記認識プロセスが前記ポインタ・プロセスであり、前記引き出すステップが、前記ポインタ・プロセスが前記複数のプールから前記認識したデータ・カプセルを引き出し、前記認識したデータ・カプセルの内容に適したプロセスを実行するステップを含む、方法。
  128. 請求項127記載の方法において、前記認識したデータ・カプセルの内容が、入力プロセスからの入力イベントを表すデータである、方法。
  129. 請求項127記載の方法において、認識データ・カプセルの内容が、前記少なくとも1つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである、方法。
  130. 請求項129記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも1つの新たなデータ・シーケンスが、ディスプレイに関する前記ポインタ
    ・オブジェクトの位置を定める、方法。
  131. 請求項130記載の方法において、前記少なくとも1つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、ポインタ・プロセス・イベントの状態情報とを備えている、方法。
  132. 請求項131記載の方法において、ポインタ・プロセス・イベント・データおよび状態情報が、前記ポインタ・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  133. 請求項132記載の方法において、前記変換するステップが、前記少なくとも1つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  134. 請求項133記載の方法において、前記複数のプロセスが、前記ディスプレイ上に前記ポインタ・オブジェクトをレンダリングする際に、前記少なくとも1つの新たなデータ・シーケンスを用いる、方法。
  135. 請求項90記載の方法において、前記複数のプロセスがグラフィカル・プロセスを含む、方法。
  136. 請求項135記載の方法において、前記変換するステップが、前記グラフィカル・プロセスの状態変化イベントを、前記イベントを指定するグラフィカル・プロセス・イベント・データと、前記イベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  137. 請求項136記載の方法において、前記グラフィカル・プロセス・イベント・データおよび状態情報が、前記グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  138. 請求項137記載の方法において、前記変換するステップが、前記少なくとも1つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  139. 請求項135記載の方法において、前記認識するプロセスが前記グラフィカル・プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記グラフィカル・プロセスを備えている、方法。
  140. 請求項139記載の方法において、前記認識したデータ・カプセルの内容が、前記複数のプロセスの内他のプロセスの状態情報を表すデータである、方法。
  141. 請求項140記載の方法において、前記状態情報が、空間状態およびモード状態の内少なくとも1つの情報を含む、方法。
  142. 請求項139記載の方法において、認識データ・カプセルの内容が、前記少なくとも1つの処理デバイスのユーザがポインタ・オブジェクトを誘導しているディスプレイ上の位置を表すデータである、方法。
  143. 請求項142記載の方法において、前記ポインタ・オブジェクトの位置が、グラフィカル・オブジェクトの境界内部にあり、前記グラフィカル・オブジェクトが前記グラフィカル・プロセスによってレンダリングされる、方法。
  144. 請求項142記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも1つの新たなデータ・シーケンスが、グラフィカル・オブジェクト、前記ポインタ・オブジェクト、および前記ポインタ・オブジェクトと境界との重複の内少なくとも1つを表す、方法。
  145. 請求項144記載の方法において、前記少なくとも1つの新たなデータ・シーケンスが、前記イベントを指定するグラフィカル・プロセス・イベント・データと、グラフィカル・プロセス・イベントの状態情報とを備えている、方法。
  146. 請求項145記載の方法において、前記グラフィカル・プロセス・イベント・データおよび状態情報が、前記グラフィカル・プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  147. 請求項146記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  148. 請求項147記載の方法において、前記複数のプロセスが、グラフィカル・オブジェクトおよび前記ポインタ・オブジェクトの内少なくとも1つを前記ディスプレイ上にレンダリングする際に、前記少なくとも1つの新たなデータ・シーケンスを用いる、方法。
  149. 請求項90記載の方法において、前記認識したデータ・カプセルに適した前記処理が、グラフィカル・オブジェクトのレンダリングを含み、前記グラフィカル・オブジェクトが前記少なくとも1つの処理デバイスのディスプレイ上にレンダリングされる、方法。
  150. 請求項149記載の方法において、前記レンダリングするステップが、直接レンダリングを行い、前記複数のプロセスが前記少なくとも1つの処理デバイスのグラフィクス・レイヤに直接描画を行い、前記複数のプロセス間において前記レンダリングに適するような調整を行うために前記複数のプールを用いる、方法。
  151. 請求項149記載の方法において、前記レンダリングするステップが、
    レンダリング・コマンドを備えているデータ・カプセルを前記複数のプールに転送するプロセスと、
    前記レンダリング・コマンドを前記複数のプールから引き出し、前記レンダリング・コマンドを解釈し、前記レンダリング・コマンドに応答して前記少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブするプロセスと、
    を含む、複数のプロセスを備えている、方法。
  152. 請求項149記載の方法において、前記レンダリングするステップが、
    画素バッファにレンダリングするプロセスと、
    生のフレーム・データを前記複数のプールに転送するプロセスであって、前記生のフレーム・データが前記画素バッファへのレンダリングの結果得られる、プロセスと、
    前記生のフレーム・データを前記複数のプールから引き出し、前記少なくとも1つの処
    理デバイスのグラフィクス・レイヤをドライブする際に用いるために、前記生のフレーム・データを組み合わせるプロセスと、
    を含む、複数のプロセスを備えている、方法。
  153. 請求項90記載の方法であって、
    前記複数のプロセスのイベントを検出するステップと、
    前記イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生するステップであって、前記イベント・データおよび状態情報が、前記少なくとも1つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
    前記少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
    を備えている、方法。
  154. 請求項153記載の方法において、前記少なくとも1つのデータ・シーケンスを発生する前記ステップが、
    第1個別イベント・データを含む第1個別データ集合を発生するステップと、
    第2個別状態情報を含む第2個別データ集合を発生するステップと、
    前記第1個別データ集合および前記第2個別データ集合を含むように、第1データ・シーケンスを形成するステップと、
    を備えている、方法。
  155. 請求項154記載の方法において、前記第1個別データ集合を発生する前記ステップが、前記少なくとも1つの処理デバイスの識別データを含むように、前記第1個別データ集合を形成するステップを含み、前記識別データが、前記少なくとも1つの処理デバイスを識別するデータを含む、方法。
  156. 請求項154記載の方法において、前記少なくとも1つのデータ・シーケンスを発生する前記ステップが、
    第1個別イベント・データを含む第1個別データ集合を発生するステップと、
    第2個別状態情報を含む第2個別データ集合を発生するステップと、
    前記第1個別データ集合および前記第2個別データ集合を含むように、第2データ・シーケンスを形成するステップと、
    を備えている、方法。
  157. 請求項156記載の方法において、前記第1個別データ集合を発生する前記ステップが、第1個別データ集合オフセットを発生するステップを含み、前記第1個別データ集合オフセットが、前記第2データ・シーケンスの前記第1個別データ集合を指し示す、方法。
  158. 請求項156記載の方法において、前記第2個別データ集合を発生する前記ステップが、第2個別データ集合オフセットを発生するステップを含み、前記第2個別データ集合オフセットが、前記第2データ・シーケンスの前記第2個別データ集合を指し示す、方法。
  159. 請求項154記載の方法において、前記第1個別データ集合が、記述リストであり、この記述リストが、前記データの記述を含む、方法。
  160. 請求項153記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  161. 請求項160記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  162. 請求項153記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  163. 請求項162記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  164. 請求項153記載の方法であって、
    少なくとも1つのオフセットを発生するステップと、
    前記少なくとも1つのオフセットを含むように、前記データ・カプセルを形成するステップと、
    を備えている、方法。
  165. 請求項164記載の方法であって、
    第1可変長を有する第1オフセットを発生するステップを備えており、
    前記第1オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記イベント・データを指し示す、方法。
  166. 請求項164記載の方法であって、
    第2可変長を有する第2オフセットを発生するステップを備えており、
    前記第2オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記状態情報を指し示す、方法。
  167. 請求項164記載の方法であって、
    前記少なくとも1つのオフセットの内第1オフセットを用いて、前記データ・カプセルを通過する第1コード経路を形成するステップと、
    前記少なくとも1つのオフセットの内第2オフセットを用いて、前記データ・カプセルを通過する第2コード経路を形成する、ステップと、
    を備えており、
    前記第1コード経路および前記第2コード経路が異なる経路である、方法。
  168. 請求項164記載の方法において、第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
  169. 請求項153記載の方法であって、
    前記データ・カプセルの長さを含むヘッダを発生するステップと、
    前記ヘッダを含むように前記データ・カプセルを形成するステップと、
    を備えている、方法。
  170. 請求項153記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
  171. 請求項170記載の方法であって、
    前記少なくとも1つの処理デバイスの第2イベントを検出するステップと、
    前記複数のプールを検索して、前記第2イベントに対応するデータ・カプセルを求めるステップと、
    を備えている、方法。
  172. 請求項171記載の方法であって、
    前記データ・カプセルと前記第2イベントとの間における対応を特定するステップと、
    前記特定に応答して、前記プールから前記データ・カプセルを抽出するステップと、
    前記データ・カプセルの内容に応答して、前記少なくとも1つの処理デバイスの代わりに、前記第2イベントに対応する処理動作を実行するステップであって、前記少なくとも1つの処理デバイスが第1タイプのアプリケーションおよび第2タイプのアプリケーションに対応する、ステップと、
    を備えている、方法。
  173. 請求項170記載の方法において、前記複数のプールが複数のアプリケーションに結合されており、前記複数のプールが、前記複数のアプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記複数のアプリケーションによる前記複数のデータ・カプセルへのアクセスに備えており、前記複数のアプリケーションの内少なくとも2つのアプリケーションが異なるアプリケーションである、方法。
  174. 請求項170記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
  175. 請求項170記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
  176. 請求項153記載の方法において、前記データ構造が、類別されていない、方法。
  177. 請求項153記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
  178. 請求項153記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
  179. 請求項153記載の方法において、前記転送するステップが、第1アプリケーション・タイプを有する第1アプリケーションから少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションに前記データ・カプセルを転送するステップを含み、前記第1アプリケーション・タイプが前記第2アプリケーション・タイプとは異なり、前記少なくとも1つのデータ・シーケンスを発生するステップが、前記第1アプリケーションによって実行され、前記方法が、前記転送するステップの間、前記データ・カプセルの少なくとも1つのデータ・シーケンスをそのまま保持するステップを備えている、方法。
  180. 請求項179記載の方法であって、前記第2アプリケーションの動作中、前記少なくとも1つのデータ・シーケンスを用いるステップを備えている、方法。
  181. 請求項153記載の方法であって、イベント・データと、前記少なくとも1つの処理デバイスのソース・デバイスの識別データとを含む第1データ集合を発生するステップを備えており、デバイス・イベント・データが、前記ソース・デバイスによって登録されたイベントを指定するデータを含み、前記識別データが、前記ソース・デバイスを識別するデータを含む、方法。
  182. 請求項181記載の方法であって、前記イベントの完全な1組の状態情報を含む第2デ
    ータ集合を発生するステップを備えており、前記第1データ集合および前記第2データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている、方法。
  183. 請求項182記載の方法において、前記変換するステップが、前記第1データ集合および前記第2データ集合を含むようにデータ・カプセルを形成することによって、前記第1データ集合および前記第2データ集合をカプセル化するステップを備えており、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  184. 請求項153記載の方法であって、
    第1タイプのアプリケーションの下で起動する第1処理デバイスのイベントを検出するステップと、
    前記第1処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、前記イベント・データが前記イベントおよびこのイベントの状態情報を指定し、前記イベント・データおよび状態情報が、前記アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
    前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
    少なくとも1つの第2タイプを有する少なくとも1つの第2アプリケーションの下で起動する第2処理デバイスの第2イベントを検出するステップであって、前記第2タイプが前記第1タイプとは異なり、前記少なくとも1つの処理デバイスが、前記第1処理デバイスおよび前記第2処理デバイスを含み、
    前記データ・カプセルと前記第2イベントとの間における対応を特定するステップと、
    前記第2イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップと、
    を備えている、方法。
  185. 請求項184記載の方法において、前記データ・シーケンスを発生する前記ステップが、
    前記イベント・データを含む第1データ集合を発生するステップと、
    前記状態情報を含む第2データ集合を発生するステップと、
    前記第1データ集合および前記第2データ集合を含むように第1データ・シーケンスを形成するステップと、
    を備えている、方法。
  186. 請求項184記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  187. 請求項186記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  188. 請求項184記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  189. 請求項188記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  190. 請求項184記載の方法であって、
    少なくとも1つのオフセットを発生するステップと、
    前記少なくとも1つのオフセットを含むように前記データ・カプセルを形成するステップと、
    を備えている、方法。
  191. 請求項190記載の方法であって、
    第1可変長を有する第1オフセットを発生するステップであって、前記第1オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記イベント・データを指し示す、ステップと、
    第2可変長を有する第2オフセットを発生するステップであって、前記第2オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記状態情報を指し示す、ステップと、
    を備えている、方法。
  192. 請求項190記載の方法であって、
    前記少なくとも1つのオフセットの内第1オフセットを用いて、前記データ・カプセルを通過する第1コード経路を形成するステップと、
    前記少なくとも1つのオフセットの内第2オフセットを用いて、前記データ・カプセルを通過する第2コード経路を形成する、ステップと、
    を備えており、
    前記第1コード経路および前記第2コード経路が異なる経路である、方法。
  193. 請求項190記載の方法において、第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
  194. 請求項184記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
  195. 請求項194記載の方法であって、
    前記複数のプールを検索して、前記第2イベントに対応するデータ・カプセルを求めるステップと、
    前記対応を特定したことに応答して、前記プールから前記データ・カプセルを抽出するステップと、
    を備えている、方法。
  196. 請求項194記載の方法において、前記複数のプールが前記アプリケーションおよび前記少なくとも1つの第2アプリケーションに結合されており、前記複数のプールが、前記アプリケーションおよび前記少なくとも1つの第2アプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記アプリケーションおよび前記少なくとも1つの第2アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法。
  197. 請求項194記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
  198. 請求項194記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
  199. 請求項184記載の方法において、前記データ構造が、類別されていない、方法。
  200. 請求項184記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
  201. 請求項184記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
  202. アプリケーション・プログラムを複数のプロセスに分割するステップと、
    前記複数のプロセスの中にあるプロセスを用いて、前記アプリケーション・プログラムの出力の一部を発生するステップであって、当該プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいる前記一部を生成する、ステップと、
    前記出力の前記一部を第1データ・カプセルにカプセル化し、前記第1データ・カプセルを複数のプールの内少なくとも1つに転送するステップであって、前記第1データ・カプセルが、前記出力の前記一部のアプリケーションに依存せずに前記複数のプロセスによって認識可能なイベントの表現であるアプリケーション独立表現に変換された前記一部のデータを含み、前記複数のプールの各プールが、前記複数のプロセスから受け取られる複数のデータ・カプセルを備えている、ステップと、
    前記複数のプールにアクセスし、前記複数のプロセスの内第2プロセスの入力を引き出すステップであって、前記入力が前記複数のデータ・カプセルの内第2データ・カプセルの中にある、ステップと、
    前記複数のデータ・カプセルおよび前記複数のプールを用いて、前記複数のプロセス間における処理を調整するステップと、
    を備えている、方法。
  203. 複数のプロセスを実行する少なくとも1つの処理デバイスであって、前記複数のプロセスが複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備え、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、処理デバイスと、
    前記少なくとも1つの処理デバイスに結合されている複数のプールと、
    を備えており、
    前記少なくとも1つの処理デバイスが、前記複数のプロセスの各プロセスのイベントをデータ・カプセルに変換し、このデータ・カプセルを前記複数のプールに転送し、
    データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現に変換されたデータと、前記データ・カプセルが発したプロセスの状態情報とを含み、各プールが、前記複数のプロセスによって生成されたデータ・カプセルを含み、
    各プロセスが認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、当該認識プロセスのインタラクティブ機能に対応する内容と、前記認識プロセスの識別との内少なくとも1つを備えているデータ・カプセルを認識し、
    前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する、システム。
  204. ジェスチャ・データから人が行ったジェスチャを検出するステップであって、前記ジェスチャ・データが検出器を通じて受け取られる、ステップと、
    処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスがイベントを発生し、これらイベントが、対応するプロセスのアプリケーションに対応するタイプを有するタイプ特定データを含み、かつ、前記ジェスチャを表す1組のイベ
    ントを含む、ステップと、
    前記複数のプロセスの各プロセスの前記イベントをデータ・カプセルに変換するステップであって、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含んでいる、ステップと、
    前記データ・カプセルを複数のプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含んでいる、ステップと、
    を備えており、
    前記複数のプロセスの内1組のプロセスが認識プロセスとして動作し、この認識プロセスが、前記複数のプールにおいて、前記ジェスチャに対応するコンテンツを備えているデータ・カプセルを認識し、
    前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、前記認識したデータ・カプセルからジェスチャ信号を発生し、前記ジェスチャ信号が前記ジェスチャを表す、方法。
  205. 請求項204記載の方法において、前記複数のプロセスが、空間動作アプリケーションの分離可能なプログラム実行コンテキストを含む、方法。
  206. 請求項204記載の方法において、前記ジェスチャ・データが、ある時点および空間におけるユーザの瞬時的状態の絶対三空間位置データである、方法。
  207. 請求項204記載の方法であって、前記ジェスチャ・データのみを用いて前記ジェスチャを識別するステップを備えている、方法。
  208. 請求項204記載の方法において、前記検出するステップが、ボディの位置を検出すること、前記ボディの方位を検出すること、および前記ボディの運動を検出することの内少なくとも1つを含む、方法。
  209. 請求項204記載の方法であって、前記ジェスチャを識別するステップを備えており、前記識別が、ボディの一部のポーズおよび方位の識別を含む、方法。
  210. 請求項204記載の方法において、前記検出するステップが、ボディの第1組の付属器官および第2組の付属器官の内少なくとも1つを検出するステップを含む、方法。
  211. 請求項204記載の方法において、前記検出するステップが、ボディに結合されている少なくとも1つのタグの位置を動的に検出するステップを含む、方法。
  212. 請求項211記載の方法において、前記検出するステップが、前記ボディに結合されている1組のタグの位置を検出するステップを含む、方法。
  213. 請求項212記載の方法において、前記1組のタグにおける各タグがパターンを含み、前記1組のタグにおける各タグの各パターンが、前記複数のタグにおけるいずれの残りのタグのいずれのパターンとも異なる、方法。
  214. 請求項204記載の方法において、前記検出するステップが、ボディ上にあるマーカを動的に検出し位置を突き止めるステップを含む、方法。
  215. 請求項214記載の方法において、前記検出するステップが、前記ボディに結合されている1組のマーカの位置を検出するステップを含む、方法。
  216. 請求項214記載の方法において、前記1組のマーカが前記ボディ上において複数のパターンを形成する、方法。
  217. 請求項214記載の方法において、前記検出するステップが、前記ボディの複数の付属器官の各々に結合されている1組のマーカを用いて、前記付属器官の位置を検出するステップを含む、方法。
  218. 請求項204記載の方法において、前記変換するステップが、前記ジェスチャについての情報をジェスチャ表記に変換するステップを含む、方法。
  219. 請求項218記載の方法において、前記ジェスチャ表記が、ジェスチャ・ボキャブラリを表し、前記ジェスチャ信号が前記ジェスチャ・ボキャブラリの通信を含む、方法。
  220. 請求項219記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携の瞬時的ポーズ状態をテキスト形態で表す、方法。
  221. 請求項219記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携の方位をテキスト形態で表す、方法。
  222. 請求項219記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携の方位の組み合わせを、テキスト形態で表す、方法。
  223. 請求項219記載の方法において、前記ジェスチャ・ボキャブラリが、ボディの力学的連携状態を表す、キャラクタのストリングを含む、方法。
  224. 請求項223記載の方法において、前記力学的連携がボディの少なくとも1つの第1付属器官である、方法。
  225. 請求項224記載の方法であって、前記ストリングにおける各位置を第2付属器官に割り当てるステップを備えており、前記第2付属器官が前記第1付属器官に接続されている、方法。
  226. 請求項225記載の方法であって、複数のキャラクタの中にあるキャラクタを、前記第2付属器官の複数の位置の各々に割り当てるステップを備えている、方法。
  227. 請求項226記載の方法において、前記複数の位置が、座標原点に対して確定される、方法。
  228. 請求項227記載の方法であって、空間における絶対位置および方位、ボディの全体的な位置および方位とは無関係のボディに対する固定位置および方位から成るグループから選択された位置を用いて、更にボディのアクションにインタラクティブに応答して、前記座標原点を確立するステップを備えている、方法。
  229. 請求項226記載の方法であって、前記複数のキャラクタの中にあるキャラクタを、前記第1付属器官の複数の方位の各々に割り当てるステップを備えている、方法。
  230. 請求項224記載の方法において、前記検出するステップが、ボディの外挿補間位置が仮想空間と交差するときを検出するステップを含み、前記仮想空間が、前記少なくとも1つの処理デバイスに結合されているディスプレイ・デバイス上に描画された空間を含
    む、方法。
  231. 請求項230記載の方法であって、前記外挿補間位置が仮想オブジェクトと交差するときに、前記仮想空間において前記仮想オブジェクトを制御するステップを備えている、方法。
  232. 請求項231記載の方法において、前記制御するステップが、前記仮想空間における外挿位置に応答して、前記仮想空間における前記仮想オブジェクトの位置を制御するステップを備えている、方法。
  233. 請求項231記載の方法であって、前記制御するステップが、前記ジェスチャに応答して、前記仮想空間における前記仮想オブジェクトの姿勢を制御するステップを含む、方法。
  234. 請求項204記載の方法であって、仮想空間と物理空間との間において一致を生じさせるために、前記検出および制御のスケーリングを制御するステップを備えており、前記仮想空間がディスプレイ上に描画された空間を構成し、前記物理空間が、ボディが存在する空間を含む、方法。
  235. 請求項234記載の方法であって、前記物理空間における少なくとも1つの物理オブジェクトの移動に応答して、前記仮想空間において少なくとも1つの仮想オブジェクトを制御するステップを備えている、方法。
  236. 請求項204記載の方法であって、前記ジェスチャ信号を用いてコンポーネントを制御するステップを備えており、前記コンポーネントが前記少なくとも1つの処理デバイスに結合されている、方法。
  237. 請求項236記載の方法において、前記コンポーネントを制御するステップが、前記ジェスチャを三空間オブジェクトにマッピングすることによって、6自由度で同時に三空間オブジェクトを制御するステップを含む、方法。
  238. 請求項236記載の方法において、前記コンポーネントを制御するステップが、3空間移動自由度および3回転自由度で三空間オブジェクトを制御するステップを含む、方法。
  239. 請求項238記載の方法において、前記三空間オブジェクトを、前記少なくとも1つの処理デバイスに結合されているディスプレイ・デバイス上に呈示する、方法。
  240. 請求項238記載の方法において、前記三空間オブジェクトが、コンピュータに結合されている遠隔システムである、方法。
  241. 請求項238記載の方法であって、前記ジェスチャを前記三空間オブジェクトの複数のオブジェクト平行移動にマッピングすることによって、前記三空間オブジェクトの移動を制御するステップを備えている、方法。
  242. 請求項241記載の方法において、前記マッピングが、前記ジェスチャと前記複数のオブジェクト平行移動との間における直接マッピングを含む、方法。
  243. 請求項241記載の方法において、前記マッピングが、前記ジェスチャと前記複数のオブジェクト平行移動との間における間接マッピングを含む、方法。
  244. 請求項204記載の方法において、データ・カプセルが、データ・メッセージが発生したプロセスの状態情報をさらに含む、方法。
  245. 請求項204記載の方法であって、前記データ・カプセルおよび前記複数のプールを用いて、前記複数のプロセスの各々の動作を調整することによって、前記複数のプロセスからインタラクティブ・アプリケーションを形成するステップを備えている、方法。
  246. 請求項204記載の方法であって、前記データ・カプセルおよび前記複数のプールの内少なくとも1つを用いて、前記複数のプロセスの動作を調整するステップを備えている、方法。
  247. 請求項204記載の方法であって、アプリケーション・プログラムを1組のプロセスに分割するステップを備えており、前記複数のプロセスが前記1組のプロセスを含む、方法。
  248. 請求項204記載の方法であって、前記複数のプールの内少なくとも1つのプールから引き出した複数のデータ・カプセルをインタラクティブに処理することによって、出力を発生するプロセスを備えている、方法。
  249. 請求項204記載の方法において、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを備えている、方法。
  250. 請求項204記載の方法であって、前記複数のプロセスを並列に実行するステップを備えている、方法。
  251. 請求項204記載の方法であって、第1組のプロセスを並列に実行し、第2組のプロセスを順次実行するステップを備えており、前記複数のプロセスが前記第1組のプロセスおよび前記第2組のプロセスを含む、方法。
  252. 請求項204記載の方法において、前記イベントがプロセス入力を表す、方法。
  253. 請求項204記載の方法において、前記イベントがプロセス出力を表す、方法。
  254. 請求項204記載の方法において、前記イベントがユーザ・インターフェース・イベントを備えている、方法。
  255. 請求項204記載の方法において、前記イベントがグラフィクスイベントを備えている、方法。
  256. 請求項204記載の方法において、前記イベントがプロセスの状態を表す、方法。
  257. 請求項256記載の方法において、プロセスの前記状態が、当該プロセスのインタラクティブ機能を表し、前記プロセスのインタラクティブ機能を複数のプロセスに、前記データ・カプセルの内容として露出する、方法。
  258. 請求項257記載の方法であって、アプリケーション・プログラミング・インターフェース(API)を関数コールによって定義する代わりに、前記データ・カプセルの内容によって前記複数のプロセスのAPIを定義するステップを備えている、方法。
  259. 請求項258記載の方法において、前記データ・カプセルの内容が、アプリケーションに依存せずに、前記複数のプロセスによって認識可能である、方法。
  260. 請求項204記載の方法において、前記少なくとも1つの処理デバイスが、複数の処理デバイスを備えている、方法。
  261. 請求項260記載の方法において、前記複数のプロセスの内少なくとも1つの第1組のプロセスが、前記複数の処理デバイスの内少なくとも1つの第1組の処理デバイスの下で起動し、前記複数のプロセスの内少なくとも1つの第2組のプロセスが、前記複数の処理デバイスの内少なくとも1つの第2組の処理デバイスの下で起動する、方法。
  262. 請求項204記載の方法において、前記複数のプロセスが第1プロセスを含む、方法。
  263. 請求項262記載の方法であって、前記変換するステップが、前記第1プロセスのイベントを、前記イベントを指定する第1プロセス・イベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  264. 請求項263記載の方法において、前記第1プロセス・イベント・データおよび状態情報が、前記第1プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  265. 請求項264記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  266. 請求項262記載の方法において、前記複数のプロセスが第2プロセスを含む、方法。
  267. 請求項266記載の方法において、前記変換するステップが、前記第2プロセスの状態変化イベントを、前記イベントを指定する第2プロセス・イベント・データとこのイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスに変換するステップを含む、方法。
  268. 請求項267記載の方法において、前記第2プロセス・イベント・データおよび状態情報が、前記第2プロセスのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  269. 請求項268記載の方法において、前記変換するステップが、前記少なくとも1つのデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  270. 請求項266記載の方法において、前記認識プロセスが前記第2プロセスであり、前記引き出すステップが、前記認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容に適した処理を実行する前記第2プロセスを備えている、方法。
  271. 請求項270記載の方法において、前記認識したデータ・カプセルの内容が、前記第1プロセスの状態情報を表すデータである、方法。
  272. 請求項271記載の方法において、前記変換するステップが、前記認識したデータ・カプセルの内容を少なくとも1つの新たなデータ・シーケンスに変換するステップを含み、前記少なくとも1つの新たなデータ・シーケンスが、前記第1プロセスのイベントおよび前記第2プロセスのイベントの内少なくとも1つを表す、方法。
  273. 請求項272記載の方法において、前記少なくとも1つの新たなデータ・シーケンスが、前記イベントを指定するイベント・データと、前記第1プロセスおよび前記第2プロセスの内少なくとも1つの状態情報とを備えている、方法。
  274. 請求項273記載の方法において、前記イベント・データならびに前記第1プロセスおよび前記第2プロセスの内少なくとも1つの状態情報が、前記第1プロセスおよび前記第2プロセスの内前記少なくとも1つのアプリケーションに対応するタイプを有するタイプ特定データである、方法。
  275. 請求項274記載の方法において、前記変換するステップが、前記少なくとも1つの新たなデータ・シーケンスを含むように前記データ・カプセルを形成するステップを含み、前記データ・カプセルが、前記少なくとも1つの新たなデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  276. 請求項275記載の方法において、前記複数のプロセスが前記少なくとも1つの新たなデータ・シーケンスを用いる、方法。
  277. 請求項204記載の方法において、前記認識したデータ・カプセルの内容に適した処理が、グラフィカル・オブジェクトをレンダリングするステップを含み、前記少なくとも1つの処理デバイスのディスプレイ上に前記グラフィカル・オブジェクトをレンダリングする、方法。
  278. 請求項277記載の方法において、前記レンダリングするステップが、直接レンダリングを行い、前記複数のプロセスが前記少なくとも1つの処理デバイスのグラフィクス・レイヤに直接描画を行い、前記複数のプロセス間において前記レンダリングに適するような調整を行うために前記複数のプールを用いる、方法。
  279. 請求項277記載の方法において、前記レンダリングするステップが、
    レンダリング・コマンドを備えているデータ・カプセルを前記複数のプールに転送するプロセスと、
    前記レンダリング・コマンドを前記複数のプールから引き出し、前記レンダリング・コマンドを解釈し、前記レンダリング・コマンドに応答して前記少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブするプロセスと、
    を含む、複数のプロセスを備えている、方法。
  280. 請求項277記載の方法において、前記レンダリングするステップが、
    画素バッファにレンダリングするプロセスと、
    生のフレーム・データを前記複数のプールに転送するプロセスであって、前記生のフレーム・データが前記画素バッファへのレンダリングの結果得られる、プロセスと、
    前記生のフレーム・データを前記複数のプールから引き出し、前記少なくとも1つの処理デバイスのグラフィクス・レイヤをドライブする際に用いるために、前記生のフレーム・データを組み合わせるプロセスと、
    を含む、複数のプロセスを備えている、方法。
  281. 請求項204記載の方法であって、
    前記複数のプロセスのイベントを検出するステップと、
    前記イベントを指定するイベント・データと、このイベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生するステップであって、前記イベント・データおよび状態情報が、前記少なくとも1つの処理デバイスのアプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
    前記少なくとも1つのデータ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
    を備えている、方法。
  282. 請求項204記載の方法において、少なくとも1つのデータ・シーケンスを発生する前記ステップが、
    第1個別イベント・データを含む第1個別データ集合を発生するステップと、
    第2個別状態情報を含む第2個別データ集合を発生するステップと、
    前記第1個別データ集合および前記第2個別データ集合を含むように、第1データ・シーケンスを形成するステップと、
    を備えている、方法。
  283. 請求項282記載の方法において、前記第1個別データ集合を発生する前記ステップが、前記少なくとも1つの処理デバイスの識別データを含むように、前記第1個別データ集合を形成するステップを含み、前記識別データが、前記少なくとも1つの処理デバイスを識別するデータを含む、方法。
  284. 請求項282記載の方法において、少なくとも1つのデータ・シーケンスを発生する前記ステップが、
    第1個別イベント・データを含む第1個別データ集合を発生するステップと、
    第2個別状態情報を含む第2個別データ集合を発生するステップと、
    前記第1個別データ集合および前記第2個別データ集合を含むように、第2データ・シーケンスを形成するステップと、
    を備えている、方法。
  285. 請求項284記載の方法において、前記第1個別データ集合を発生する前記ステップが、第1個別データ集合オフセットを発生するステップを含み、前記第1個別データ集合オフセットが、前記第2データ・シーケンスの前記第1個別データ集合を指し示す、方法。
  286. 請求項284記載の方法において、前記第2個別データ集合を発生する前記ステップが、第2個別データ集合オフセットを発生するステップを含み、前記第2個別データ集合オフセットが、前記第2データ・シーケンスの前記第2個別データ集合を指し示す、方法。
  287. 請求項282記載の方法において、前記第1個別データ集合が、記述リストであり、この記述リストが、前記データの記述を含む、方法。
  288. 請求項204記載の方法において、イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  289. 請求項288記載の方法において、イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  290. 請求項204記載の方法において、状態情報が、類別されたデータを表すタグ付き
    バイト・シーケンスである、方法。
  291. 請求項290記載の方法において、状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  292. 請求項204記載の方法であって、
    少なくとも1つのオフセットを発生するステップと、
    前記少なくとも1つのオフセットを含むように、前記データ・カプセルを形成するステップと、
    を備えている、方法。
  293. 請求項292記載の方法であって、
    第1可変長を有する第1オフセットを発生するステップを備えており、
    前記第1オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスのイベント・データを指し示す、方法。
  294. 請求項292記載の方法であって、
    第2可変長を有する第2オフセットを発生するステップを備えており、
    前記第2オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの状態情報を指し示す、方法。
  295. 請求項292記載の方法であって、
    前記少なくとも1つのオフセットの内第1オフセットを用いて、前記データ・カプセルを通過する第1コード経路を形成するステップと、
    前記少なくとも1つのオフセットの内第2オフセットを用いて、前記データ・カプセルを通過する第2コード経路を形成する、ステップと、
    を備えており、
    前記第1コード経路および前記第2コード経路が異なる経路である、方法。
  296. 請求項292記載の方法において、第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
  297. 請求項204記載の方法であって、
    前記データ・カプセルの長さを含むヘッダを発生するステップと、
    前記ヘッダを含むように前記データ・カプセルを形成するステップと、
    を備えている、方法。
  298. 請求項204記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
  299. 請求項298記載の方法であって、
    前記少なくとも1つの処理デバイスの第2イベントを検出するステップと、
    前記複数のプールを検索して、前記第2イベントに対応するデータ・カプセルを求めるステップと、
    を備えている、方法。
  300. 請求項299記載の方法であって、
    前記データ・カプセルと前記第2イベントとの間における対応を特定するステップと、
    前記特定に応答して、前記プールから前記データ・カプセルを抽出するステップと、
    前記データ・カプセルの内容に応答して、前記少なくとも1つの処理デバイスの代わりに、前記第2イベントに対応する処理動作を実行するステップであって、前記少なくとも1つの処理デバイスが第1タイプのアプリケーションおよび第2タイプのアプリケーションに対応する、ステップと、
    を備えている、方法。
  301. 請求項298記載の方法において、前記複数のプールが複数のアプリケーションに結合されており、前記複数のプールが、前記複数のアプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記複数のアプリケーションによる前記複数のデータ・カプセルへのアクセスに備えており、前記複数のアプリケーションの内少なくとも2つのアプリケーションが異なるアプリケーションである、方法。
  302. 請求項298記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
  303. 請求項298記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
  304. 請求項204記載の方法において、データ構造が、類別されていない、方法。
  305. 請求項204記載の方法において、前記データ・カプセルのデータ構造が、イベント・データおよび状態情報のプラットフォームに依存しない表現である、方法。
  306. 請求項204記載の方法において、前記データ・カプセルのデータ構造が、イベント・データおよび状態情報へのプラットフォームに依存しないアクセスを与える、方法。
  307. 請求項204記載の方法において、前記転送するステップが、第1アプリケーション・タイプを有する第1アプリケーションから少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションに前記データ・カプセルを転送するステップを含み、前記第1アプリケーション・タイプが前記第2アプリケーション・タイプとは異なり、前記少なくとも1つのデータ・シーケンスを発生するステップが、前記第1アプリケーションによって実行され、前記方法が、前記転送するステップの間、前記データ・カプセルの少なくとも1つのデータ・シーケンスをそのまま保持するステップを備えている、方法。
  308. 請求項307記載の方法であって、前記第2アプリケーションの動作中、前記少なくとも1つのデータ・シーケンスを用いるステップを備えている、方法。
  309. 請求項204記載の方法であって、イベント・データと、前記少なくとも1つの処理デバイスのソース・デバイスの識別データとを含む第1データ集合を発生するステップを備えており、デバイス・イベント・データが、前記ソース・デバイスによって登録されたイベントを指定するデータを含み、前記識別データが、前記ソース・デバイスを識別するデータを含む、方法。
  310. 請求項309記載の方法であって、前記イベントの完全な1組の状態情報を含む第2データ集合を発生するステップを備えており、前記第1データ集合および前記第2データ集合の各々が、タイプ特定データ・レイアウトとした類別データ・バンドルを備えている、方法。
  311. 請求項310記載の方法において、前記変換するステップが、前記第1データ集合および前記第2データ集合を含むようにデータ・カプセルを形成することによって、前記第1データ集合および前記第2データ集合をカプセル化するステップを備えており、前記データ・カプセルが、少なくとも1つのデータ・シーケンスのアプリケーション独立表現のデータ構造を有する、方法。
  312. 請求項204記載の方法であって、
    第1タイプのアプリケーションの下で起動する第1処理デバイスのイベントを検出するステップと、
    前記第1処理デバイスのイベント・データを含むデータ・シーケンスを発生するステップであって、前記イベント・データが前記イベントおよびこのイベントの状態情報を指定し、前記イベント・データおよび状態情報が、前記アプリケーションに対応するタイプを有するタイプ特定データである、ステップと、
    前記データ・シーケンスを含むようにデータ・カプセルを形成するステップであって、前記データ・カプセルが、前記データ・シーケンスのアプリケーション独立表現のデータ構造を有する、ステップと、
    少なくとも1つの第2タイプを有する少なくとも1つの第2アプリケーションの下で起動する第2処理デバイスの第2イベントを検出するステップであって、前記第2タイプが前記第1タイプとは異なり、前記少なくとも1つの処理デバイスが、前記第1処理デバイスおよび前記第2処理デバイスを含み、
    前記データ・カプセルと前記第2イベントとの間における対応を特定するステップと、
    前記第2イベントに応答して、前記データ・カプセルのデータ・シーケンスの内容を用いて動作を実行するステップと、
    を備えている、方法。
  313. 請求項312記載の方法において、前記データ・シーケンスを発生する前記ステップが、
    前記イベント・データを含む第1データ集合を発生するステップと、
    前記状態情報を含む第2データ集合を発生するステップと、
    前記第1データ集合および前記第2データ集合を含むように第1データ・シーケンスを形成するステップと、
    を備えている、方法。
  314. 請求項312記載の方法において、前記イベント・データが、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  315. 請求項314記載の方法において、前記イベント・データが、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  316. 請求項312記載の方法において、前記状態情報が、類別されたデータを表すタグ付きバイト・シーケンスである、方法。
  317. 請求項316記載の方法において、前記状態情報が、タイプ・ヘッダと、タイプ特定データ・レイアウトとを含む、方法。
  318. 請求項312記載の方法であって、
    少なくとも1つのオフセットを発生するステップと、
    前記少なくとも1つのオフセットを含むように前記データ・カプセルを形成するステップと、
    を備えている、方法。
  319. 請求項318記載の方法であって、
    第1可変長を有する第1オフセットを発生するステップであって、前記第1オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記イベント・データを指し示す、ステップと、
    第2可変長を有する第2オフセットを発生するステップであって、前記第2オフセットが、前記少なくとも1つのデータ・シーケンスの第1データ・シーケンスの前記状態情報を指し示す、ステップと、
    を備えている、方法。
  320. 請求項318記載の方法であって、
    前記少なくとも1つのオフセットの内第1オフセットを用いて、前記データ・カプセルを通過する第1コード経路を形成するステップと、
    前記少なくとも1つのオフセットの内第2オフセットを用いて、前記データ・カプセルを通過する第2コード経路を形成する、ステップと、
    を備えており、
    前記第1コード経路および前記第2コード経路が異なる経路である、方法。
  321. 請求項318記載の方法において、第1オフセットおよび第2オフセットの内少なくとも1つがメタデータを含み、このメタデータが、前記アプリケーションのコンテキストに対応するコンテキスト特定メタデータを含む、方法。
  322. 請求項312記載の方法であって、前記データ・カプセルを前記複数のプールにおけるプールに転送するステップを備えている、方法。
  323. 請求項322記載の方法であって、
    前記複数のプールを検索して、前記第2イベントに対応するデータ・カプセルを求めるステップと、
    前記対応を特定したことに応答して、前記プールから前記データ・カプセルを抽出するステップと、
    を備えている、方法。
  324. 請求項322記載の方法において、前記複数のプールが前記アプリケーションおよび前記少なくとも1つの第2アプリケーションに結合されており、前記複数のプールが、前記アプリケーションおよび前記少なくとも1つの第2アプリケーションに対応する複数のデータ・カプセルを含み、前記複数のプールが、前記アプリケーションおよび前記少なくとも1つの第2アプリケーションによる前記複数のデータ・カプセルへのアクセスを与える、方法。
  325. 請求項322記載の方法において、前記複数のプールが、複数のデータ・カプセルの状態のキャッシュに備えている、方法。
  326. 請求項322記載の方法において、前記複数のプールが、複数のデータ・カプセルの線形シーケンスに備えている、方法。
  327. 請求項312記載の方法において、前記データ構造が、類別されていない、方法。
  328. 請求項312記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報のプラットフォームに依存しない表現である、方法。
  329. 請求項312記載の方法において、前記データ・カプセルのデータ構造が、前記イベント・データおよび前記状態情報へのプラットフォームに依存しないアクセスを与える、方法。
  330. 処理デバイス上において複数のプロセスを実行するステップであって、前記複数のプロセスが、複数のアプリケーション・プログラムの分離可能なプログラム実行コンテキストを含み、各アプリケーション・プログラムが少なくとも1つのプロセスを含み、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成する、ステップと、
    前記複数のプロセスの各プロセスのイベントをデータ・メッセージに変換するステップであって、データ・メッセージが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータと、前記データ・メッセージを発したプロセスの状態情報とを含む、ステップと、
    前記データ・メッセージを、複数のプールの内少なくとも1つのプールに転送するステップであって、各プールが、前記複数のプロセスによって生成された前記データ・メッセージを含んでいる、ステップと、
    前記プロセス間において調整を行うステップであって、この調整が、前記複数のプールからピア・プロセスの状態情報を引き出すことによって、前記複数のプロセスの各プロセスが、前記複数のプロセスのピア・プロセスと対等になることを含む、ステップと、
    前記複数のプールの内少なくとも1つのプールの1組のデータ・メッセージをインタラクティブに組み合わせることによって、前記複数のプロセスの出力を発生するステップと、
    を備えている、方法。
  331. ボディによって行われたジェスチャを表すジェスチャ・データを受け取る検出器と、
    前記検出器に結合されているプロセッサであって、このプロセッサが前記ジェスチャ・データから自動的に前記ジェスチャを検出し、前記プロセッサが複数のプロセスを実行し、これら複数のプロセスが、前記ジェスチャを表す1組のイベントを含むイベントを発生し、各プロセスが、該プロセスのアプリケーションに対応するタイプを有するタイプ特定データを含んでいるイベントを生成し、前記プロセッサが、前記複数のプロセスにおける各プロセスのイベントをデータ・カプセルに変換し、各データ・カプセルが、各データ・カプセルが、各プロセスのアプリケーションに依存せずに前記複数のプロセスによって認識可能な前記イベントの表現であるアプリケーション独立表現に変換されたデータを含み、前記プロセッサが前記データ・カプセルを複数のプールに転送し、各プールが、前記複数のプロセスによって生成された前記データ・カプセルを含み、前記複数のプロセスの内1組のプロセスが、認識プロセスとして機能し、この認識プロセスが、前記複数のプールにおいて、前記ジェスチャに対応する内容を備えているデータ・カプセルを認識し、前記認識プロセスが、認識したデータ・カプセルを前記複数のプールから引き出し、前記認識したデータ・カプセルの内容を合成してジェスチャ信号を形成することによって、前記認識したデータ・カプセルから前記ジェスチャ信号を発生し、前記ジェスチャ信号が前記ジェスチャを表す、プロセッサと、
    を備えている、システム。
JP2011532225A 2008-10-14 2009-10-14 マルチプロセス・インタラクティブ・システムおよび方法 Expired - Fee Related JP5805537B2 (ja)

Applications Claiming Priority (15)

Application Number Priority Date Filing Date Title
US10524308P 2008-10-14 2008-10-14
US10525308P 2008-10-14 2008-10-14
US61/105,243 2008-10-14
US61/105,253 2008-10-14
US12/417,252 2009-04-02
US12/417,252 US9075441B2 (en) 2006-02-08 2009-04-02 Gesture based control using three-dimensional information extracted over an extended depth of field
US12/487,623 US20090278915A1 (en) 2006-02-08 2009-06-18 Gesture-Based Control System For Vehicle Interfaces
US12/487,623 2009-06-18
US12/553,845 2009-09-03
US12/553,845 US8531396B2 (en) 2006-02-08 2009-09-03 Control system for navigating a principal dimension of a data space
US12/557,464 US9910497B2 (en) 2006-02-08 2009-09-10 Gestural control of autonomous and semi-autonomous systems
US12/557,464 2009-09-10
US12/572,689 US8866740B2 (en) 2005-02-08 2009-10-02 System and method for gesture based control system
US12/572,689 2009-10-02
PCT/US2009/060725 WO2010045394A1 (en) 2008-10-14 2009-10-14 Multi-process interactive systems and methods

Publications (2)

Publication Number Publication Date
JP2012506097A JP2012506097A (ja) 2012-03-08
JP5805537B2 true JP5805537B2 (ja) 2015-11-04

Family

ID=42106884

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011532225A Expired - Fee Related JP5805537B2 (ja) 2008-10-14 2009-10-14 マルチプロセス・インタラクティブ・システムおよび方法

Country Status (5)

Country Link
EP (1) EP2350774A4 (ja)
JP (1) JP5805537B2 (ja)
KR (1) KR101649769B1 (ja)
CN (1) CN102224476B (ja)
WO (1) WO2010045394A1 (ja)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9740293B2 (en) 2009-04-02 2017-08-22 Oblong Industries, Inc. Operating environment with gestural control and multiple client devices, displays, and users
US9684380B2 (en) * 2009-04-02 2017-06-20 Oblong Industries, Inc. Operating environment with gestural control and multiple client devices, displays, and users
US9952673B2 (en) 2009-04-02 2018-04-24 Oblong Industries, Inc. Operating environment comprising multiple client devices, multiple displays, multiple users, and gestural control
US10824238B2 (en) 2009-04-02 2020-11-03 Oblong Industries, Inc. Operating environment with gestural control and multiple client devices, displays, and users
US9971807B2 (en) 2009-10-14 2018-05-15 Oblong Industries, Inc. Multi-process interactive systems and methods
US10481769B2 (en) * 2013-06-09 2019-11-19 Apple Inc. Device, method, and graphical user interface for providing navigation and search functionalities
US9430808B2 (en) * 2013-06-19 2016-08-30 Microsoft Technology Licensing, Llc Synchronization points for state information
GB2521151B (en) * 2013-12-10 2021-06-02 Advanced Risc Mach Ltd Configurable thread ordering for a data processing apparatus
US9990046B2 (en) 2014-03-17 2018-06-05 Oblong Industries, Inc. Visual collaboration interface
EP3062142B1 (en) 2015-02-26 2018-10-03 Nokia Technologies OY Apparatus for a near-eye display
US9734000B2 (en) * 2015-06-18 2017-08-15 Microsoft Technology Licensing, Llc Seamless transitions between applications and devices
CN106055123B (zh) * 2016-06-08 2019-01-29 Tcl移动通信科技(宁波)有限公司 一种基于文字输入速度的备选字查找速度控制方法及系统
CN106571888B (zh) * 2016-11-10 2018-08-14 中国人民解放军空军航空大学军事仿真技术研究所 一种仿真系统自动同步可靠通信方法
US10650552B2 (en) 2016-12-29 2020-05-12 Magic Leap, Inc. Systems and methods for augmented reality
EP4300160A3 (en) 2016-12-30 2024-05-29 Magic Leap, Inc. Polychromatic light out-coupling apparatus, near-eye displays comprising the same, and method of out-coupling polychromatic light
US10578870B2 (en) 2017-07-26 2020-03-03 Magic Leap, Inc. Exit pupil expander
CN107479973A (zh) * 2017-08-08 2017-12-15 西安万像电子科技有限公司 数据传输方法、装置、系统
JP7282090B2 (ja) 2017-12-10 2023-05-26 マジック リープ, インコーポレイテッド 光学導波管上の反射防止性コーティング
KR20200100720A (ko) 2017-12-20 2020-08-26 매직 립, 인코포레이티드 증강 현실 뷰잉 디바이스용 인서트
CN108196686B (zh) * 2018-03-13 2024-01-26 北京无远弗届科技有限公司 一种手部动作姿态捕捉设备、方法及虚拟现实交互系统
US10755676B2 (en) 2018-03-15 2020-08-25 Magic Leap, Inc. Image correction due to deformation of components of a viewing device
US11885871B2 (en) 2018-05-31 2024-01-30 Magic Leap, Inc. Radar head pose localization
WO2020010097A1 (en) 2018-07-02 2020-01-09 Magic Leap, Inc. Pixel intensity modulation using modifying gain values
US11856479B2 (en) 2018-07-03 2023-12-26 Magic Leap, Inc. Systems and methods for virtual and augmented reality along a route with markers
US11510027B2 (en) 2018-07-03 2022-11-22 Magic Leap, Inc. Systems and methods for virtual and augmented reality
WO2020023543A1 (en) 2018-07-24 2020-01-30 Magic Leap, Inc. Viewing device with dust seal integration
EP4270016A3 (en) 2018-07-24 2024-02-07 Magic Leap, Inc. Temperature dependent calibration of movement detection devices
US11112862B2 (en) 2018-08-02 2021-09-07 Magic Leap, Inc. Viewing system with interpupillary distance compensation based on head motion
US10795458B2 (en) 2018-08-03 2020-10-06 Magic Leap, Inc. Unfused pose-based drift correction of a fused pose of a totem in a user interaction system
CN109143983B (zh) * 2018-08-15 2019-12-24 杭州电子科技大学 嵌入式可编程控制器的运动控制方法及装置
JP7487176B2 (ja) 2018-08-22 2024-05-20 マジック リープ, インコーポレイテッド 患者視認システム
CN109491725B (zh) * 2018-11-12 2022-12-27 火烈鸟网络(广州)股份有限公司 应用程序可交互多开方法和系统、存储介质、电子设备
JP7472127B2 (ja) 2018-11-16 2024-04-22 マジック リープ, インコーポレイテッド 画像鮮明度を維持するための画像サイズによってトリガされる明確化
US11425189B2 (en) * 2019-02-06 2022-08-23 Magic Leap, Inc. Target intent-based clock speed determination and adjustment to limit total heat generated by multiple processors
EP3939030A4 (en) 2019-03-12 2022-11-30 Magic Leap, Inc. REGISTRATION OF LOCAL CONTENT BETWEEN FIRST AND SECOND VIEWERS OF AUGMENTED REALITY
CN114127837A (zh) 2019-05-01 2022-03-01 奇跃公司 内容提供系统和方法
US11514673B2 (en) 2019-07-26 2022-11-29 Magic Leap, Inc. Systems and methods for augmented reality
US12033081B2 (en) 2019-11-14 2024-07-09 Magic Leap, Inc. Systems and methods for virtual and augmented reality
EP4058979A4 (en) 2019-11-15 2023-01-11 Magic Leap, Inc. VIEWING SYSTEM FOR USE IN A SURGICAL ENVIRONMENT
CN112907437A (zh) * 2021-03-26 2021-06-04 长沙景嘉微电子股份有限公司 多个3d进程运行方法、装置、电子设备和存储介质
CN116302579B (zh) * 2023-05-25 2023-08-04 智成时空(西安)创新科技有限公司 面向Web端的时空大数据高效加载渲染方法及系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2517531B2 (ja) * 1994-02-28 1996-07-24 株式会社エイ・ティ・アール通信システム研究所 ステレオ画像を用いた姿勢検出装置
JP2000514944A (ja) * 1997-05-08 2000-11-07 アイレディー コーポレイション オブジェクト指向プログラミング言語のためのハードウェア加速器
US7548238B2 (en) * 1997-07-02 2009-06-16 Nvidia Corporation Computer graphics shader systems and methods
JP3762173B2 (ja) * 1999-11-26 2006-04-05 株式会社東芝 計算機システム及びネットワークシステム並びに記録媒体
SE0000850D0 (sv) * 2000-03-13 2000-03-13 Pink Solution Ab Recognition arrangement
US8745541B2 (en) * 2003-03-25 2014-06-03 Microsoft Corporation Architecture for controlling a computer using hand gestures
US7436535B2 (en) * 2003-10-24 2008-10-14 Microsoft Corporation Real-time inking
US7366368B2 (en) * 2004-06-15 2008-04-29 Intel Corporation Optical add/drop interconnect bus for multiprocessor architecture
US7613830B2 (en) * 2004-12-10 2009-11-03 Microsoft Corporation Reliably transferring queued application messages
EP1851750A4 (en) * 2005-02-08 2010-08-25 Oblong Ind Inc SYSTEM AND METHOD FOR CONTROL SYSTEM BASED ON GESTURES
US8769127B2 (en) * 2006-02-10 2014-07-01 Northrop Grumman Systems Corporation Cross-domain solution (CDS) collaborate-access-browse (CAB) and assured file transfer (AFT)
JP5007060B2 (ja) * 2006-03-28 2012-08-22 株式会社野村総合研究所 ジョブ管理装置およびジョブ管理方法
EP2163987A3 (en) * 2007-04-24 2013-01-23 Oblong Industries, Inc. Processing of events in data processing environments

Also Published As

Publication number Publication date
JP2012506097A (ja) 2012-03-08
KR20110079839A (ko) 2011-07-08
EP2350774A4 (en) 2014-11-05
KR101649769B1 (ko) 2016-08-19
WO2010045394A1 (en) 2010-04-22
CN102224476A (zh) 2011-10-19
CN102224476B (zh) 2017-08-01
EP2350774A1 (en) 2011-08-03

Similar Documents

Publication Publication Date Title
JP5805537B2 (ja) マルチプロセス・インタラクティブ・システムおよび方法
US10565030B2 (en) Multi-process interactive systems and methods
US9063801B2 (en) Multi-process interactive systems and methods
US10990454B2 (en) Multi-process interactive systems and methods
US10235412B2 (en) Detecting, representing, and interpreting three-space input: gestural continuum subsuming freespace, proximal, and surface-contact modes
JP5698733B2 (ja) 三空間入力の検出、表現、および解釈:自由空間、近接、および表面接触モードを組み込むジェスチャ連続体
US9933852B2 (en) Multi-process interactive systems and methods
US20180136734A1 (en) Spatial, multi-modal control device for use with spatial operating system
US8669939B2 (en) Spatial, multi-modal control device for use with spatial operating system
US9495013B2 (en) Multi-modal gestural interface
US8665213B2 (en) Spatial, multi-modal control device for use with spatial operating system
JP5806615B2 (ja) データ空間の主要次元をナビゲートするための制御システム
JP5782431B2 (ja) 空間動作システムと共に用いるための空間マルチモード制御デバイス
US9052970B2 (en) Multi-process interactive systems and methods
JP2015525381A (ja) 相互ユーザ手追跡および形状認識ユーザ・インターフェース

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20121015

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140213

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20140513

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20140520

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140813

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150114

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20150410

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20150513

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150714

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150804

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150902

R150 Certificate of patent or registration of utility model

Ref document number: 5805537

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees