(57)【要約】  【課題】  【解決手段】類似または非類似特性を有するデバイス間の通信を提供し、その間のシームレスなインタオペラビリティを容易にするためのシステム、デバイス、方法およびコンピュータプログラム、およびコンピュータプログラム製品である。類似および非類似の恒久的または間断的に接続された電子デバイス間でコンテンツ、アプリケーション、リソース、およびコントロールを共有するためのシステムおよびデバイスのコンピュータプログラムソフトウェアおよび方法である。フレームワーク内で通信および／または相互運用するデバイス、システム、機器等が提供される。リクルートメントインタオペラビリティ方法、レンディショニングアダプテーション、インタオペラビリティセグメンテーション方法、インタオペラビリティソース、インタオペラビリティフレームワーク、インタオペラビリティツール、インタオペラビリティフォーマット、インタオペラビリティランタイム、リニアタスキング、バーチカルレイヤリング、アプリケーション駆動パワーマネージメント、インタオペラビリティアプリケーション駆動エラー復元、インタオペラビリティ命令セット、クリエイショニズム、インタオペラビリティエンジン、インタオペラビリティデバイスイネーブリング、インタオペラビリティセキュリティモデル、ソーシャル同期インタオペラビリティ方法、ソーシャルセキュリティインタオペラビリティモデル、インタオペラビリティデバイス、インタオペラビリティプラットフォーム、バーチャルポインタ、およびＤａｒｔ固有バージョンまたはこれらのインプリメンテーションである。【選択図】図１０
2008503011.tif 000002
【特許請求の範囲】
【請求項１】
開始ソースデバイスと検査手順を到達させようとするデバイスの両方に共通な実行可能な形式でコード化された検査手順命令を含み、必要なリソースまたはケイパビリティを有するデバイスを探すよう動作可能な検査手順を、少なくとも１つの通信リンクを介して少なくとも１つの開始ソースデバイスと異なる到達可能なデバイスに送信することと；
到達可能なデバイスのそれぞれから、通信リンクを介して直接または間接的に、開始デバイスでリターン応答を受信することと；
ソフトウェアアプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイスのケイパビリティおよびリソースの組み合わせを特定する利用プランを決定するために、開始デバイスで実行する手順により、全ての応答到達可能デバイスからの受信リターンを分析することと；
開始デバイスで実行するアプリケーションプログラムにより、特定された利用プランに従って必要なリソースまたはケイパビリティを有すると特定された到達可能デバイスのそれぞれの少なくとも１つに実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを配信することとを含むことを特徴とする、デバイスのチームをリクルートするためソースデバイスで動作するソフトウェアアプリケーションのための方法。
【請求項２】
候補デバイスで受信し、受信デバイスとリクルートデバイスの両方に既知の実行可能形式でコード化された検査手順命令を含み受信到達可能候補デバイスが別のリクルートデバイスの必要とするリソースまたはケイパビリティを有するか否かを通信リンクを介して判断する動作可能な検査手順を実行することと；
受信した検査手順についてソースデバイスを特定し、受信到達可能デバイスが、開始ソースデバイスが必要としていると特定されたリソースまたはケイパビリティまたはリソースおよびケイパビリティのセットにアクセス可能か否かに関するステータスおよび情報をソースデバイスにリターンを送信することと；
到達可能デバイスが、ソフトウェアアプリケーションの意図を実行するためチームを結成するのに必要なリソースまたはケイパビリティを有するとソースデバイスによって判断された場合、実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを、ソースデバイス、リクルートデバイスまたは別の候補デバイスから受信することとを含むことを特徴とする、デバイスのチームをリクルートするための方法。
【請求項３】
（ａ）開始ソースデバイスと検査手順を到達させようとするデバイスの両方に共通する実行可能形式でコード化された検査手順命令を含み、少なくとも１つの通信リンクを介して開始ソースデバイスと異なる少なくとも１つの到達可能デバイスに必要なリソースまたはケイパビリティを有するデバイスを見つける動作可能な検査手順を、開始ソースデバイスから送信することと；
（ｂ）開始ソースデバイスが必要とする到達可能デバイスの少なくとも１つのリソースまたはケイパビリティがあるか否かを特定するために、受信をし、到達可能デバイスのそれぞれで受信した検査手順を実行することと；
（ｃ）到達可能デバイスが、少なくとも開始ソースデバイスが必要とすると特定されたリソースまたはケイパビリティにアクセスできる場合に、開始ソースデバイスにリターンを送信することと；
（ｄ）通信リンクを介して直接あるいは間接的に、到達可能デバイスのそれぞれからリターンを受信することと；
（ｅ）アプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイスのケイパビリティおよびリソースの組み合わせを特定する利用プランを決定するために、開始デバイスで実行するアプリケーションによって、全ての応答到達可能デバイスからの受信リターンを分析することと；
（ｆ）開始デバイスで実行するアプリケーションプログラムにより、特定された利用プランに従って必要なリソースまたはケイパビリティを有すると特定された到達可能デバイスのそれぞれの少なくとも１つに実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを配信することとを含むことを特徴とする、デバイスのチームをリクルートするための方法。
【請求項４】
少なくとも１つの到達可能デバイスによって、配信された実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを受信することをさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記開始デバイスのアプリケーションの意図の少なくとも一部を実行するため実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つが配信された少なくとも１つの到達可能デバイスと相互運用することをさらに含むことを特徴とする請求項３に記載の方法。
【請求項６】
各到達可能デバイスを二次開始ソースデバイスとして動作させ、開始および到達可能デバイス間で実行可能コード、データ、コンテンツおよび／またはＤａｒｔをスプレッドし、任意で、到達可能デバイスに常駐するアプリケーションコード、データ、コンテンツおよび／またはＤａｒｔｓを、必要に応じて前もって到達してチームとしたデバイスによって到達可能な他のデバイスに再帰的にスプレッドし、当初の開始デバイスアプリケーションの意図を実行するため所望のデバイスおよび必要あるいは所望のリソースまたはケイパビリティの所定の基準に達するまで、他の到達可能デバイスユニットに必要に応じてまたは所望によってアプリケーションを拡張し、より大きく完全なデバイスのチームを効果的に結成することと；
開始デバイスのアプリケーションの意図を実行するため、コードを実行し、開始アプリケーションの意図を実行するためデバイスのチーム間で実行すべきオペレーションを実行および／または調整するために必要なあらゆる実行可能コード、データおよびコンテンツおよび／またはＤａｒｔｓを交換することにより、必要あるいは望ましいオペレーションおよびリソースアクセスを実行する開始デバイスのアプリケーションのニーズおよび所望に従って、開始および到達可能デバイスのチームから、およびこの中で実行可能コード、データ、コンテンツおよび／またはＤａｒｔを配信することとを含むことを特徴とする請求項３に記載の方法。
【請求項７】
前記開始デバイスが、１以上の中間到達可能デバイスを介して直列または再帰的方法で、別の到達可能デバイスへ、またはこれから間接的に、リクルートメントメッセージを送信したというリターンを、開始ソースデバイスが最初に到達したデバイスから直接受信することを特徴とする請求項３に記載の方法。
【請求項８】
前記開始ソースデバイスへのリターンは、到達可能デバイスが、開始ソースデバイスが必要とすると特定されたリソースまたはケイパビリティにアクセスできない場合にも送信されることを特徴とする請求項３に記載の方法。
【請求項９】
前記開始ソースデバイスへのリターンは、到達可能デバイスが、開始ソースデバイスが必要とすると特定されたリソースまたはケイパビリティを自身が持っているか、アクセスできる（真または論理的「１」）か、自身が持っていないかアクセスできない（偽または論理的「０」）であることを特定する単純なパラメータであることを特徴とする請求項３に記載の方法。
【請求項１０】
前記開始ソースデバイスへのリターンは、ＤａｒｔＥｖｅｎｔ、Ｄａｒｔの一部、データ、コンテンツ、実行可能手順、Ｄａｒｔ、複数のＤａｒｔｓおよびその組み合わせのうちの１つを含むことを特徴とする請求項３に記載の方法。
【請求項１１】
前記開始ソースデバイスへのリターンは、通信プロトコルを介して開始デバイスに、特定の到達可能デバイスのリソースおよび／またはケイパビリティを特定するリターンされたデータまたはコンテンツを含むことを特徴とする請求項３に記載の方法。
【請求項１２】
前記検査手順は、開始ソースデバイスで少なくとも部分的に実行されるアプリケーションタスクの意図を実行するため、開始ソースデータが必要とする特定された少なくとも１つのリソースまたはケイパビリティを検査する命令を含むことを特徴とする請求項３に記載の方法。
【請求項１３】
前記方法は、デバイスのチーム間でアプリケーションをリクルートし、効果的に実行するコンピュータプログラム製品としてエンコードされたソフトウェアアプリケーションによって、少なくとも部分的にインプリメントされることを特徴とする請求項３に記載の方法。
【請求項１４】
前記方法は、リクルートしたデバイスとリクルートされたデバイスの全てのリソースを組み合わせた１台のデバイスであるかのように、リクルートしたデバイスとリクルートされたデバイスのオペレーションのコントロールを効果的に連結して許可することを特徴とする請求項３に記載の方法。
【請求項１５】
前記リターンは、リターンなし、データ或いはコンテンツのリターン、あらゆるデジタルにエンコードされた情報、１以上の手順、デバイスが有益である表示、リターンされたイベント、ファイルのペイロードを介したデータの量またはデータのセットを含むリターンイベント、リターン手順、Ｄａｒｔ、どのデバイスを利用するかを人間が開始デバイスのメニューから選択できるようなデバイスのテキスト名および記述を含むリターンイベント、ソースデバイスに常駐しまたは当該デバイスから生成可能な実行可能コード、データおよびコンテンツのセットの少なくとも１つのインスタンスの特定のパッケージの識別子、デバイスで動作するのに最も適したレンディション或いはレンディションのセット、またはこれらのいずれかの組み合わせのどれか１つを含むことを特徴とする請求項３に記載の方法。
【請求項１６】
少なくとも１つのリソースまたはケイパビリティは、（ｉ）利用可能なリソースまたは特定の必要なリソース、（ｉｉ）利用可能なケイパビリティまたは特定の必要なケイパビリティ、（ｉｉｉ）到達可能デバイスのリソースおよびケイパビリティの１以上の相互関連セット、またはアプリケーションの意図を実行するため到達可能デバイスが利用可能なリソースおよび／あるいはケイパビリティ、ならびに（ｉｖ）これらの組み合わせからなるセットから選択することを特徴とする請求項３に記載の方法。
【請求項１７】
前記リソースまたはケイパビリティは、特定されたデータ操作ソフトウェア、特定された情報処理ソフトウェア、特定されたコンピュテーションソフトウェア、特定された画像処理ソフトウェア、特定された通信ソフトウェア、特定された通信ハードウェア、特定されたメディア、特定されたデータセット、特定されたコンテンツ、特定された単数または複数のプログラム、特定された構成情報、特定されたグラフィック加速ハードウェアまたはソフトウェア、一時的または非一時的（恒久的）を問わず特定された記憶媒体、特定された印刷ケイパビリティ、特定されたファックスケイパビリティ、特定されたスキャンケイパビリティ、入力または出力あるいは入力および出力両方かを問わず、特定されたユーザインターフェースデバイス、デバイスが通信でき、他のデバイスが無限チェーンで通信できるほかのデバイスのリソースへのアクセス、およびこれらの２個以上の組み合わせからなるリソースまたはケイパビリティのセットから選択した特定されたケイパビリティの少なくとも１つのセットを含むことを特徴とする請求項３に記載の方法。
【請求項１８】
共通の実行可能形式の前記検査手順は、Ｄａｒｔ命令互換エンジン（ＤａｒｔＥｎｇｉｎｅ）その他インタオペラビリティ命令セットに埋め込まれたＤａｒｔ準拠命令セット（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ）から形成した少なくとも１つの検査手順を含むことを特徴とする請求項３に記載の方法。
【請求項１９】
少なくとも１つの通信リンクは、あらゆる数の通信リンクと、チャンネルと、および／または有線か無線かを問わず、また恒久的に利用可能か間断的かを問わず、あらゆる数の同種または異種の通信プロトコルまたはそのセットを有するプロトコルを備えることを特徴とする請求項３に記載の方法。
【請求項２０】
前記異種および同種の通信リンク、チャンネルおよびプロトコルは、いずれか２以上の通信デバイスで動作するプレイヤの部分である特定されたハードウェア抽象化層インプリメンテーションによってサポートされることを特徴とする請求項３に記載の方法。
【請求項２１】
前記特定されたハードウェア抽象化層インプリメンテーションは、ＤａｒｔＥｎｇｉｎｅのコンポーネントであるＤａｒｔハードウェア抽象化層インプリメンテーションを含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
少なくとも１つの通信リンクおよび通信プロトコルを用いて、ラン手順タイプのイベントを送信し、イベントのイベント識別子は、前記到達可能デバイスで動作するため前記手順を識別するファイルを参照することを特徴とする請求項３に記載の方法。
【請求項２３】
前記イベントは、ＤａｒｔＥｖｅｎｔｓを含み、ラン手順タイプのイベントは、Ｄａｒｔ  ＲＵＮ＿ＰＲＯＣＥＤＵＲＥタイプイベントを含むことを特徴とする請求項２２に記載の方法。
【請求項２４】
前記到達可能デバイスで動作するため手順を識別するファイルを参照するイベント識別子は、到達可能デバイスで動作するため手順の画像を含むファイルを参照するイベントのファイル識別子を含むことを特徴とする請求項３に記載の方法。
【請求項２５】
前記ファイルは、ＤａｒｔＦｏｒｍａｔに準拠するＤａｒｔ準拠ファイル（ＤａｒｔＦｉｌｅ）を含み、手順の画像は、ＤａｒｔＰｒｏｃｅｄｕｒｅ（ＤａｒｔＰｒｏｃｅｄｕｒｅ）のバイナリデータ画像を含むことを特徴とする請求項２４に記載の方法。
【請求項２６】
前記検査手順は、ＤａｒｔＰｒｏｃｅｄｕｒｅｓまたは完全なＤａｒｔｓのいずれかを含むことを特徴とする請求項３に記載の方法。
【請求項２７】
前記検査手順をイベントと関連するファイルとして送信し、イベントと関連するファイルとしての検査手順の到達可能デバイスによる受信によって、到達可能デバイスでの検査手順の実行が開始されることを特徴とする請求項３に記載の方法。
【請求項２８】
前記検査手順は、ＤａｒｔＰｒｏｃｅｄｕｒｅを含むことを特徴とする請求項３に記載の方法。
【請求項２９】
前記到達可能デバイスの基本リソースおよびケイパビリティを含むリソースおよびケイパビリティは、命令セットプロフィール命令の利用によって決定されることを特徴とする請求項３に記載の方法。
【請求項３０】
前記命令セットプロフィール命令は、Ｄａｒｔ準拠命令セット（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ）のＤａｒｔ準拠プロフィール命令（Ｄａｒｔ  ＰＲＯＦＩＬＥ＿ＩＮＳＴＲＵＣＴＩＯＮ）を含むことを特徴とする請求項２９に記載の方法。
【請求項３１】
各到達可能デバイス内の前記検査手順実行は、特定の到達可能デバイスまたはそのそれぞれに送られるレンディション決定ルールに従って、開始Ｄａｒｔ具現化アプリケーションの最良レンディションを決定し、決定した最良レンディションの識別子を返すデータの一部として送り返すことを特徴とする請求項３に記載の方法。
【請求項３２】
前記レンディション決定ルールは、必要とされる複雑なコンピュテーションを実行し、到達可能デバイスのリソース、ケイパビリティおよび／または状態を決定するプロフィール命令を通じて必要なプロフィール情報にアクセスするよう適合された少なくとも１つの手順に具現化されることを特徴とする請求項３１に記載の方法。
【請求項３３】
前記検査手順実行は、レンディションの順序を定義するルールを参照し、複数のレンディションのそれぞれの要件全てが予め定義されたレンディション優先順序を満たすか否か、複数のレンディション中でレンディションの要件全てを満たす最初のレンディションが見つかるまで到達可能デバイスのそれぞれをチェックすることにより、複数のレンディションから最良のレンディションを決定することを特徴とする請求項３１に記載の方法。
【請求項３４】
前記検査手順は、Ｄａｒｓ、手順、データまたはコンテンツを、理解された通信プロトコルを用いて通信リンクを介して開始デバイスに返すことを特徴とする請求項３に記載の方法。
【請求項３５】
前記リターンは、少なくとも返された手順、データまたはコンテンツと、完全なＤａｒｔｓ、ＤａｒｔＰａｒｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅｓまたはＤａｒｔＥｖｅｎｔｓのいずれかあるいは組み合わせのうちの少なくとも１つを含み、その１つまたは組み合わせは、関連するイベントファイルありまたはなしで返されることを特徴とする請求項３に記載の方法。
【請求項３６】
前記リターンは、返された手順、データ、コンテンツおよび／またはＤａｒｔのうち少なくとも１つを含み、さらに任意で、エラー発生を示すリターンコードを含み、エラーコードは、特定のエラーが発生したこと、または非特定エラーが発生したことを示し、エラーコードは任意で特定のエラーおよび／またはエラーの性質を是正または通信するのに有益な情報を含むことを特徴とする請求項３に記載の方法。
【請求項３７】
前記アプリケーションコードは、Ｄａｒｔ、ＤａｒｔＰｒｏｃｅｄｕｒｅ、または、開始デバイスあるいはプログラムの転送または実行を開始し、実行の結果を利用するために開始デバイスがアクセスするデバイス上で実行可能なあらゆる形式のプログラムのうち少なくとも１つであることを特徴とする請求項３に記載の方法。
【請求項３８】
前記アプリケーションコードは、Ｄａｒｔ、ＤａｒｔＰｒｏｃｅｄｕｒｅ、または、手順的フォーマットが到達可能デバイスで実行するためのＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔを利用するか否かを問わず、到達可能デバイスで実行可能または情報を送ることができる別の手順的フォーマットを含むことを特徴とする請求項３に記載の方法。
【請求項３９】
前記リクルートされたデバイスのチームは、前記チームをダイナミックに拡張して、他の到達可能デバイスを含めたり、デバイスのチームを縮小して、アプリケーションの寿命または定義された実行期間中に所望の到達可能デバイスを除外したりできることを特徴とする請求項３に記載の方法。
【請求項４０】
前記配信は、Ｄａｒｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅｓ、データ、コンテンツその他情報、またはこれらの組み合わせの少なくとも１つの送信により達成され、イベントでフィールドが参照した情報がイベントと共に、あるいはイベントの一部として送信されたか否かを問わず、ダートイベント（ＤａｒｔＥｖｅｎｔｓ）の一部としてカプセル化されていることを特徴とする請求項３に記載の方法。
【請求項４１】
前記デバイスのチームから、またはその間で前記開始アプリケーションのニーズに従って配信されたコード、データおよびコンテンツは、コードを実行し、開始アプリケーションの意図をさらに実行するためにデバイスのチーム間で実行するオペレーションの実行または調整に必要なあらゆる追加または異なるコード、データおよびコンテンツを任意で交換することにより、発信アプリケーションの意図を実行するため必要なオペレーションおよびリソースアクセスを実行することを特徴とする請求項３に記載の方法。
【請求項４２】
前記アプリケーションは、リクルートメントプロセスの一部として全デバイスに配信された全てのコードを含むシングルバイナリイメージに具現化されることを特徴とする請求項３に記載の方法。
【請求項４３】
前記方法はさらに、デバイスのチーム上の同期、直列化、調整を含み、同期、直列化および調整は、イベント、またはＤａｒｔＥｖｅｎｔｓのみ、または任意でＤａｒｔＥｖｅｎｔｓまたはイベントと関連するファイルをパスまたは交換することによって完全にまたは部分的に達成することを特徴とする請求項３に記載の方法。
【請求項４４】
前記イベントは少なくとも１つのファイルを参照し、その参照によって、ファイルまたは複雑性のファイルイメージを有するファイルを効果的に含有して組み込み、これらファイルイメージがイベント構造コンテンツと通信するようにすることを特徴とする請求項４３に記載の方法。
【請求項４５】
相互運用および通信している開始およびリクルートされたデバイスのみ、または任意で、ＤａｒｔＥｖｅｎｔｓまたはイベントに関連するファイルの間でＤａｒｔＥｖｅｎｔｓイベントをパスまたは交換することをさらに含み、前記イベントがＤａｒｔＥｖｅｎｔ構造のファイル識別子（フィールド）参照によりファイルまたは他のデータまたは複雑性のデータ構造を含み、参照時にファイルイメージは常にイベント構造コンテンツと通信されることを特徴とする請求項３に記載の方法。
【請求項４６】
ＤａｒｔＥｖｅｎｔまたはイベントは、ＤａｒｔＦｒａｍｅｗｏｒｋ、ＤａｒｔＲｕｎｔｉｍｅおよび／またはＤａｒｔＥｎｇｉｎｅ、あるいは代替的に非ＤａｒｔＰｌａｔｆｏｒｍ固有イベント駆動型インプリメンテーションにより、チーム化されたあらゆる数のデバイスのイベント待ち行列間で自動的にコピーおよび／または同期され、自動同期について識別されＤａｒｔによってイベント待ち行列に入れられたＤａｒｔＥｖｅｎｔｓまたはイベントが、自動直列化および同期によってあらゆる数のチーム化されたデバイスのイベント待ち行列に現れることを特徴とする請求項４３に記載の方法。
【請求項４７】
前記自動直列および同期は、開始デバイスを含む複数の協働デバイス間で動作するイベント駆動型協調アプリケーション、機能またはレンディションの自動直列化および同期のための手順によって達成され、この方法は：
所望の各デバイス間協働機能用のアプリケーションにより、発信デバイス上で接続マネージャオブジェクトインスタンスを作成することと；
全ての協働デバイス上でアプリケーションにより順に同期されるイベントタイプのリストを接続マネージメントに通信することと；
各デバイスに１つの接続マネージャを有するイベントタイプのチームを確立し、同じ同期イベントタイプのリストを共有することと；
接続マネージャによって、チーム化されたデバイスと同期するイベントタイプを特定するセッションリストを維持することと、接続マネージャによって、イベント待ち行列に入れる全てのイベントを調べ、調べた特定のイベントが、接続マネージャがセッションリストから同期すべきとわかるイベントタイプである場合、他のセッションと同期するイベントとして、そのイベントを接続マネージャに一覧したデバイスのイベント待ち行列に入れることとを含むことを特徴とする請求項４６に記載の方法。
【請求項４８】
前記イベント駆動型協働アプリケーション機能またはレンディションのいずれか１つによって協働デバイスイベント待ち行列に入れる全てのイベントを、いずれかのデバイスによってイベントを直接送信された全ての協働デバイスイベント待ち行列が協働デバイスのイベント待ち行列に無事に入れられたとの肯定応答を受信するまで、あらゆるデバイスのイベント待ち行列にイベントを入れることを許可しないことによって直列化することを特徴とする請求項４７に記載の方法。
【請求項４９】
前記イベント駆動型協働アプリケーション機能またはレンディションのいずれか１つが受信した協働デバイスイベント待ち行列に入れる全てのイベントを、いずれかの受信デバイスによってイベントを送信された全ての協働デバイスイベント待ち行列が協働デバイスのイベント待ち行列に入れられたとの肯定応答を受信するまで、受信側のあらゆるデバイスのイベント待ち行列にイベントを入れることを許可しないことによって直列化することを特徴とする請求項４８に記載の方法。
【請求項５０】
前記デバイスが、直接通信デバイスのチェーンを介して直接あるいは間接に通信しているかを問わず、あらゆる数の協働デバイスのイベント待ち行列が、全協働デバイス間で待ち行列イベントの直列化された１つのシステムを確立することを特徴とする請求項４８に記載の方法。
【請求項５１】
前記デバイスが、直接通信デバイスのチェーンを介して直接あるいは間接に通信しているかを問わず、あらゆる数の協働デバイスのイベント待ち行列が、全協働デバイス間で待ち行列イベントの直列化された１つのシステムを確立することを特徴とする請求項４９に記載の方法。
【請求項５２】
１つのマスタデバイスのみが同期するイベントタイプのリストにそのタイプのイベントを入れることで、かかるイベントすべてが全協働デバイス間で直列化されるようにできるシステムにより、２つ以上の協働デバイスから協働デバイスの待ち行列に入れるイベントを同期し、協働デバイスの待ち行列のイベントに単一直列化させることを特徴とする請求項４７に記載の方法。
【請求項５３】
前記マスタデバイスは、マスタデバイスが全協働デバイスの待ち行列に目的とするイベントを入れるために必要な全ての情報を含むマスタの要求イベントタイプのイベントによって、他の協働デバイスに代わり発行するイベントを知らされることを特徴とする請求項５２に記載の方法。
【請求項５４】
他のデバイスによって協働デバイスのセットになるよう前記協働デバイスのチームにリクルートされた各デバイスは、その相対的マスタデバイスを、自分をリクルートしたデバイスとみなすことを特徴とする請求項５２に記載の方法。
【請求項５５】
他のデバイスによって協働デバイスのセットになるよう前記協働デバイスのチームにリクルートされた各デバイスは、その相対的マスタデバイスを、自分をリクルートしたデバイスとみなすことを特徴とする請求項５３に記載の方法。
【請求項５６】
マスタ要求イベントタイプのイベントをマスタのデバイスの待ち行列に入れることにより、相対的マスタを持たない開始マスタデバイスがマスタデバイスに必要な情報を用いてイベントを形成し、目的とするイベントを全協働デバイスの待ち行列に入れるまで、イベントをデバイスから相対マスタデバイスへ伝播させることを特徴とする請求項５４に記載の方法。
【請求項５７】
協働デバイスの同期および／または直列化された待ち行列に、自身が直列化イベントのリストにある変更マスタタイプイベントを発行し、新しいマスタデバイスが現行マスタデバイスに取って代わることを同期直列化方法で全デバイスに知らせることにより、前記指定されたマスタデバイスを変更できることを特徴とする請求項５２に記載の方法。
【請求項５８】
前記マスタ要求イベントは、新しいマスタデバイスがイベントを処理するまで、協働デバイスの待ち行列を通じて伝播することを特徴とする請求項５４に記載の方法。
【請求項５９】
前記マスタ要求イベントは、新しいマスタデバイスがイベントを処理するまで、協働デバイスの待ち行列を通じて伝播することを特徴とする請求項５５に記載の方法。
【請求項６０】
前記マスタ要求イベントタイプのイベントによって送られると指定されたイベントの一部と特定されたオプションのファイルは、かかるファイル参照が存在する場合、識別子のある各伝播デバイスに維持され、マスタによって送信されるイベントの一部として送信されたかのように、マスタによって送信されるイベントと再び関連できるようになり、これは、マスタに処理されるマスタ要求イベントタイプの結果として送られる各イベントの一部として送らなければならなかった情報量を減らすためであることを特徴とする請求項５３に記載の方法。
【請求項６１】
メモリと接続され、目的とするタスクの実行命令を含む手順を実行するよう適合されたプロセッサと；
目的とするタスク実行のバージョンに必要な少なくともハードウェアリソースを備え、目的とするタスク実行に参加するため装置と異なる外部の少なくとも１つのリクルートされたデバイスを、リクルートするためプロセッサおよびメモリで少なくとも部分的に実行する手段と；
ハードウェアのリソースと使用可能にされた補完リソースが、リクルートされたデバイスが目的のタスクの実行を完全に可能にするために、リクルートされたデバイスのリソースを補完するための装置内に完全に保存された手段とを備えることを特徴とする開始装置。
【請求項６２】
前記装置およびリクルートされたデバイスはそれぞれ共通の手順的環境で動作し、リクルートのためプロセッサおよびメモリで少なくとも部分的に実行される手段は、少なくとも１つの接続を介して、共通の手順的環境を含みまたはここで動作する他のデバイスに共通手順的環境でインプリメントされた手順をブロードキャストする手段を備えることを特徴とする請求項６１に記載の開始装置。
【請求項６３】
前記リクルートするための手段はさらに、各デバイスが特定のタスクの実行に参加するのに必要なリソースまたはケイパビリティを有するか否か判断するために、他のデバイスそれぞれのリソースおよびケイパビリティをプログラムで検査するための他のデバイス上の手順の実行を開始する手段を備えることを特徴とする請求項６２に記載の開始装置。
【請求項６４】
前記検査は、特定のデバイスに保存されまたは当該デバイスについて計算したデバイス固有抽象化層情報に少なくとも部分的にアクセスすることにより、他の特定のデバイスごとで実行されることを特徴とする請求項６３に記載の開始装置。
【請求項６５】
前記補完手段はさらに、各デバイスが特定のタスクの一部を実行できるようにするために必要なイネーブリング手順、データおよび／またはコンテンツを送信およびインストールするための手段を含むことを特徴とする請求項６４記載の開始装置。
【請求項６６】
前記開始デバイスと他のデバイスとの間でオペレーションを一時的または恒久的に同期させるための手段をさらに備え、同期手段は、タスクイベント待ち行列と、前記タスクイベント待ち行列を維持するための手段とを含むことを特徴とする請求項６１に記載の開始装置。
【請求項６７】
リクルートされた装置であって、プロセッサとプロセッサに接続されたメモリとを備えるハードウェアリソースのセットと、タスクのセットの実行のために適合されたコンピュータプログラムコードリソースとを備え、前記ハードウェアリソースは、少なくとも特定のタスク実行の１バージョンを実行することが可能だが、前記コンピュータプログラムコードリソースは、特定のタスクまたは特定のタスクの態様を実行するための所望のバージョンまたは方法と、コンピュータプログラムコード通信およびデータ通信の少なくとも一方を含む通信を受信するための手段を実行することが初めはできず、前記コンピュータプログラムコード通信は、特定のタスクの所望のバージョン、方法または態様の実行が可能な装置をレンダリングする補完的コンピュータプログラムコードリソースを備えることを特徴とするリクルートされた装置。
【請求項６８】
前記リクルートされた装置と開始デバイスは、共通手順的環境でそれぞれ動作することを特徴とする請求項６７に記載のリクルートされた装置。
【請求項６９】
前記リクルートされたデバイスが、特定のタスクの実行に参加するために必要なリソースまたはケイパビリティを有するか否か判断するため、前記リクルートされたデバイスのリソースおよびケイパビリティをプログラムで検査する、開始デバイスから受信した手順を実行するための手段をさらに備えることを特徴とする請求項６８に記載のリクルートされた装置。
【請求項７０】
前記検査は、前記リクルートされたデバイスに保存されまたは当該デバイスについて計算したデバイス固有抽象化層情報に少なくとも部分的にアクセスすることにより、リクルートされたデバイスで実行することを特徴とする請求項６９に記載のリクルートされた装置。
【請求項７１】
前記リクルートされたデバイスが、前記特定のタスクの一部を実行できるようにするために必要なイネーブリング手順、データおよび／またはコンテンツをインストールするための手段を備えることを特徴とする請求項７０に記載のリクルートされた装置。
【請求項７２】
開始デバイスとリクルートされたデバイスとの間でオペレーションを一時的に同期させるための手段をさらに備え、前記同期手段が、タスクイベント待ち行列と、前記タスクイベント待ち行列を維持するための手段とを含むことを特徴とする請求項６１に記載のリクルートされた装置。
【請求項７３】
特定のタスクの実行に参加するため、複数の異種デバイスの間で一体化された特別なオンザフライ配信情報処理システムを形成する方法であって：
少なくとも１つの通信チャンネルと、特定のタスクの実行に参加するためのリソースまたはケイパビリティを所有する他のリクルートされたデバイスを識別およびリクルートする目的のあるプロトコルを用いて、メッセージをブロードキャストすることを含み、開始デバイスによって配信された情報処理システムの結成を開始することと；
前記リクルートされたデバイスのそれぞれが特定のタスクの一部を実行できるよう、リクルートされたデバイスのそれぞれに必要とされる手順、データおよびコンテンツの少なくとも１つを通信することとを含むことを特徴とする方法。
【請求項７４】
前記目的のタスクの実行に参加するため、少なくとも前記目的のタスクの実行のバージョンに必要なハードウェアリソースを含み開始デバイスと異なる外部の少なくとも１つのリクルートされたデバイスをリクルートするための手順を、開始デバイスのプロセッサとメモリで少なくとも部分的に実行することと；
ハードウェアのリソースと使用可能にされた補完リソースが、リクルートされたデバイスが目的のタスクを完全に実行できるようにするために、リクルートされたデバイスのリソースを補完する手順および任意のデータを開始装置内に完全に保存することとをさらに含むことを特徴とする請求項７３に記載の方法。
【請求項７５】
前記開始デバイスとリクルートされたデバイスは、共通手順的環境でそれぞれ動作し、リクルートするためプロセッサおよびメモリで少なくとも部分的に実行する手順は、やはり共通手順的環境を含むかこれで動作する他のデバイスに少なくとも１つの接続を介して共通手順的環境でインプリメントされた手順をブロードキャストすることを含むことを特徴とする請求項７４に記載の方法。
【請求項７６】
前記リクルートはさらに、各デバイスが前記特定のタスクの実行に参加するために必要なリソースまたはケイパビリティを有するか否か判断するため、他のデバイスで、他のデバイスのそれぞれのリソースとケイパビリティをプログラムで検査する手順を実行開始することを含むことを特徴とする請求項７５に記載の方法。
【請求項７７】
前記検査は、前記特定のデバイスに保存されまたは当該デバイスについて計算したデバイス固有抽象化層情報に少なくとも部分的にアクセスすることにより、特定の他のリクルートされたデバイスのそれぞれで実行されることを特徴とする請求項７６に記載の方法。
【請求項７８】
前記補完はさらに、各デバイスが前記特定のタスクの一部を実行できるようにするために必要なイネーブリング手順、データおよび／またはコンテンツを送信およびインストールすることを含むことを特徴とする請求項７７に記載の方法。
【請求項７９】
前記開始デバイスと他のリクルートされたデバイスとの間でオペレーションを一時的に同期させることをさらに含み、同期は、タスクイベント待ち行列と、タスクイベント待ち行列の生成と維持とを含むことを特徴とする請求項７７に記載の方法。
【請求項８０】
前記通信は、クライアントサーバ通信インタラクションでもピアツーピア通信インタラクションでもない通信およびインタラクションであることを特徴とする請求項７３に記載の方法。
【請求項８１】
前記リクルートメントは、必要なデバイスを識別するため、特別なデバイス、サービスおよびリソース発見を実行し、イベントを用いてデバイスにイネーブリング手順および情報を送信し、インテリジェントおよび有効にデバイスのチームを結成してから、イベントを用いてデバイスのチームを調整し、ソース開始デバイスで当初動作しているＤａｒｔまたはアプリケーションまたはタスクの目標を達成することを特徴とする請求項７３に記載の方法。
【請求項８２】
前記分散情報処理システムは、前記デバイスの物理的ケイパビリティの一部または全部のアクセスと調整された利用とを含むことを特徴とする請求項７３に記載の方法。
【請求項８３】
前記デバイスの物理的ケイパビリティは、任意で印刷、ファックス、表示、音楽のレンダリング、ビデオのレンダリング、他のデバイスの制御、デジタルかアナログかを問わず、あらゆる媒体でのデータの保存、グッズの製造、排除、撮影その他、デバイスの処理ケイパビリティによってアクセス、モニタまたは制御できるあらゆる物理的ケイパビリティを含む能力のセットから選択することを特徴とする請求項８２に記載の方法。
【請求項８４】
１以上のデバイスで動作する前記ソフトウェアアプリケーションは、当初は開始デバイス上の単一のソフトウェアパッケージの一部であったコードおよび／またはデータおよび／またはコンテンツを有する２以上のデバイスでのインタオペラビリティオペレーションを少なくとも部分的に実行することで、開発および／または独立的配信したアプリケーションを用いてインタオペラビリティオペレーションを実行する場合より大きなインタオペラビリティ信頼性を享受することを特徴とする請求項１に記載の方法。
【請求項８５】
コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品であって、コンピュータリーダブル記憶媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとを備えるコンピュータプログラム製品において、前記コンピュータプログラムメカニズムは：
コンピュータシステムまたは情報機器に、相互動作するためリクルートされたデバイスのチームを指定の方法でリクルートする機能を指示するプログラムモジュールを備え、前記プログラムモジュールは：
開始ソースデバイスと検査手順を到達させるデバイスとの両方に共通する実行可能形式でコード化された検査手順命令を含み、少なくとも１つの通信リンクを介して前記開始ソースデバイスと異なる少なくとも１つの到達可能デバイスに必要なリソースまたはケイパビリティを有するデバイスを見つけるよう動作可能な検査手順を送信する命令と；
開始デバイスにおいて、通信リンクを介して直接あるいは間接的に到達可能デバイスのそれぞれからリターン応答を受信する命令と；
ソフトウェアアプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイスとのケイパビリティおよびリソースの組み合わせを特定する利用プランを決定するために、開始デバイスで実行する手順により、応答到達可能デバイス全てからの受信リターンを分析する命令と；
開始デバイスで実行するアプリケーションプログラムによって、特定された利用プランにしたがって必要なリソースまたはケイパビリティを有すると特定された到達可能デバイスのそれぞれの少なくとも１つに、実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを配信する命令とを含むことを特徴とするコンピュータプログラム製品。
【請求項８６】
前記コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品であって、コンピュータリーダブル記憶媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとを備えるコンピュータプログラム製品において、前記コンピュータプログラムメカニズムは：
単一のバーチャルデバイスとして動作して、特定のタスクの実行に参加するため、複数の異種デバイスの中で一体型の特別でオンザフライの分散情報処理システムを指定の方法で形成するよう機能することをコンピュータシステムまたは情報機器に指示するプログラムモジュールを備え、当該プログラムモジュールは：
少なくとも１つの通信チャンネルと、特定のタスクの実行に参加するためのリソースまたはケイパビリティを所有する他のリクルートされたデバイスを識別およびリクルートする目的を持つプロトコルとを用いてメッセージをブロードキャストする結成であって開始デバイスによる配信情報処理システムの結成を開始する命令と；
リクルートされたデバイスのそれぞれが特定のタスクの一部を実行できるようにするため、前記リクルートされたデバイスのそれぞれに必要とされた手順、データおよびコンテンツの少なくとも１つを通信する命令とを備えることを特徴とするコンピュータプログラム製品。
【請求項８７】
ソフトウェアアプリケーションを別個に実行可能なイメージのセットにセグメント化する方法において、当該方法は：
アプリケーションが意図する１以上の態様を実行するため考えられるリソースおよびケイパビリティに従い、遭遇するデバイスをクラスに分けることと；
アプリケーションが意図する１以上の態様を実行するため、明確なレンダリングその他ランタイム要件に関するニーズに従って、遭遇しそうな環境または動作要件をクラスに分けることと；
デバイスの各クラスおよび各環境または動作要件で、アプリケーションが意図する１以上の態様を実行できるようにするために必要な実行可能イメージに必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定することと；
ある候補デバイスのリストで、アプリケーションの意図を実行するのに利用する各デバイスで動作するデバイスと、対応する個々に割り当てられた実行可能イメージと、そのリソースおよびケイパビリティ、必要または所望の環境または動作パラメータを選択するための利用プランを生成することと；
各クラスのデバイスおよび各環境または動作要件で利用プランをインプリメントおよび実行するために必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定することとを含むことを特徴する方法。
【請求項８８】
前記ソフトウェアアプリケーションは、１以上の同種または異種の通信デバイス間で動作することを意図することを特徴とする請求項８７に記載の方法。
【請求項８９】
そのように正確に選択した１つの実行可能イメージが、特定の環境においてデバイスが動作するよう選択されることを特徴とする請求項８７に記載の方法。
【請求項９０】
そのように正確に選択した１つの実行可能イメージが、各デバイスのリソースおよびケイパビリティおよび環境と動作要件に関してアプリケーションのニーズに従ってデバイスで動作するよう選択されることを特徴とする請求項８９に記載の方法。
【請求項９１】
前記デバイスの少なくとも１つは、Ｄａｒｔデバイスであることを特徴とする請求項８９に記載の方法。
【請求項９２】
前記生成された利用プランを実行することをさらに含むことを特徴とする請求項８７に記載の方法。
【請求項９３】
前記ソフトウェアアプリケーションはＤａｒｔと表現されることを特徴とする請求項８７に記載の方法。
【請求項９４】
前記別個に実行するイメージはレンディションであることを特徴とする請求項８７に記載の方法。
【請求項９５】
前記レンディションは、ＤａｒｔＦｏｒｍａｔに従ってＤａｒｔＴｏｏｌｓによってパッケージ化されたＤａｒｔレンディションの形式で表現されることを特徴とする請求項９３に記載の方法。
【請求項９６】
請求項１の利用プランは、候補デバイスで動作するために送られる手順の全体または一部としてインプリメントされ、デバイスの特定のクラス、そのリソースおよび／またはその動作環境を決定することを特徴とする請求項８８に記載の方法。
【請求項９７】
前記手順は、インタオペラビリティ命令セットの命令として少なくとも部分的に構成されるＤａｒｔＰｒｏｃｅｄｕｒｅｓであることを特徴とする請求項９６に記載の方法。
【請求項９８】
前記インタオペラビリティ命令セットは、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔであることを特徴とする請求項９７に記載の方法。
【請求項９９】
前記インタオペラビリティ命令セットは、手順を動作させる１以上の同種または異種の通信デバイスで実行可能な形式であることを特徴とする請求項９７に記載の方法。
【請求項１００】
前記通信デバイスは、特定のクラスのデバイス、そのリソースおよび／またはその動作環境を決定する手順を動作させることを特徴とする請求項９９に記載の方法。
【請求項１０１】
前記手順は、アプリケーションの一部であるＤａｒｔｓとして表現されることを特徴とする請求項９６に記載の方法。
【請求項１０２】
前記アプリケーションは、異種の通信デバイス上でアプリケーションの意図を実行するために用いる他のＤａｒｔｓを含むＤａｒｔとして表現されることを特徴とする請求項１０１に記載の方法。
【請求項１０３】
請求項１のリクルートメント方法を用いて手順と別個実行可能イメージを送信および配信し、異種または同種デバイスのチームを結成することを特徴とする請求項８７に記載の方法。
【請求項１０４】
パーツは、インタオペラビリティアプリケーションのサイズを制限するために、異なる対象デバイスおよび処理環境で別個に動作する異なるイメージ間で共有可能であることを特徴とする請求項８７に記載の方法。
【請求項１０５】
パーツは、ソフトウェアに保存するデータの量を制限するために、別個に動作するイメージ間で共有可能であることを特徴とする請求項８７に記載の方法。
【請求項１０６】
パーツは、デバイス間で通信するデータの量を制限するために、別個に動作するイメージ間で共有可能であることを特徴とする請求項８７に記載の方法。
【請求項１０７】
パーツは、コード、データ、コンテンツ、手順、コードセット、データセット、コンテンツ、コンテンツセット、パーツを発見し組み合わせる方法に関するメタ情報、記述的テキスト、絵、ビデオ、画像、データの表その他デジタル形式で表現可能な情報の単位または情報のセットのうちの１つであることを特徴とする請求項１０４に記載の方法。
【請求項１０８】
パーツは、ＤａｒｔＰａｒｔｓおよび／またはメタ情報は、Ｄａｒｔ  ＲｅｎｄｉｔｉｏｎｓＴａｂｌｅパーツ、および／またはＤａｒｔ  ＲｅｎｄｉｔｉｏｎＴａｂｌｅパーツおよび／またはＤａｒｔＰａｒｔＴａｂｌｅおよび／またはＤａｒｔＴｒａｉｌｅｒとして表現されることを特徴とする請求項１０７に記載の方法。
【請求項１０９】
ソフトウェアアプリケーションを別個に実行可能なイメージのセットにセグメント化する方法であって、前記方法は：
考えられるリソースおよびケイパビリティに従い、遭遇するデバイスをクラスに分けることと；
遭遇しそうな環境または動作要件をクラスに分けることと；
各クラスのデバイスおよび各環境または動作要件でアプリケーションが意図する１以上の態様を実行できるよう実行可能イメージに必要なデータ、コード、コンテンツおよび／またはその他デジタル表現可能なリソースを指定することと；
アプリケーションの意図を実行するために用いる各デバイスで動作するデバイスおよび実行可能イメージを選択するための利用プランを生成することとを含むことを特徴とする方法。
【請求項１１０】
ソフトウェアアプリケーションを別個に実行可能なイメージのセットにセグメント化するための装置であって、前記装置は：
アプリケーションが意図する１以上の態様を実行するため考えられるリソースおよびケイパビリティに従い、遭遇するデバイスをクラスに分けるための手段と；
アプリケーションが意図する１以上の態様を実行するため、明確なレンダリングその他ランタイム要件に関するニーズに従って、遭遇しそうな環境または動作要件をクラスに分けるための手段と；
デバイスの各クラスおよび各環境または動作要件で、アプリケーションが意図する１以上の態様を実行できるようにするために必要な実行可能イメージに必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定するための手段と；
ある候補デバイスのリストで、アプリケーションの意図を実行するのに利用する各デバイスで動作するデバイスと、対応する個々に割り当てられた実行可能イメージと、そのリソースおよびケイパビリティ、必要または所望の環境または動作パラメータを選択するための利用プランを生成するための手段と；
各クラスのデバイスおよび各環境または動作要件で利用プランをインプリメントおよび実行するために必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定するための手段とを備えることを特徴とする装置。
【請求項１１１】
コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品であって、コンピュータリーダブル記憶媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとを備えるコンピュータプログラム製品において、前記コンピュータプログラムメカニズムは：
コンピュータシステムまたは情報機器に、コンピュータソフトウェアコードアプリケーションを別個に実行可能なコンピュータプログラムソフトウェアコードイメージのセットにセグメント化するため指定の方法で機能するよう命令するプログラムモジュールを含み、前記プログラムモジュールは：
遭遇するデバイスを、そのリソースおよびケイパビリティに従ってクラスに分ける命令と；
遭遇する可能性のある環境または動作要件をクラスに分ける命令と；
各デバイスのクラスおよび各環境または動作要件でアプリケーションが意図する１以上の態様を実行できるようにするため実行可能イメージに必要なデータ、コード、コンピュータおよび／またはその他デジタル表現可能なリソースを指定する命令と；
アプリケーションの意図を実行するために用いる各デバイスで動作するデバイスおよび実行可能イメージを選択するための利用プランを生成する命令とを備えることを特徴とするコンピュータプログラム製品。
【請求項１１２】
コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品であって、コンピュータリーダブル記憶媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとを備えるコンピュータプログラム製品において、前記コンピュータプログラムメカニズムは：
コンピュータシステムまたは情報機器に、コンピュータソフトウェアコードアプリケーションを別個に実行可能なコンピュータプログラムソフトウェアコードイメージのセットにセグメント化するため指定の方法で機能するよう命令するプログラムモジュールとを備え、前記プログラムモジュールは：
遭遇するデバイスを、アプリケーションの意図の１以上の態様を実行するためそのリソースおよびケイパビリティに従ってクラスに分ける命令と；
アプリケーションの意図の１以上の態様を実行するため明確なレンダリングその他ランタイム要件に関するニーズに従って、遭遇しそうな環境または動作要件をクラスに分けるクラスに分ける命令と；
デバイスの各クラスおよび各環境または動作要件で、アプリケーションの意図の１以上の態様を実行できるようにするために必要な実行可能イメージに必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定する命令と；
ある候補デバイスのリストで、アプリケーションの意図を実行するのに利用する各デバイスで動作するデバイスと、対応する個々に割り当てられた実行可能イメージと、そのリソースおよびケイパビリティ、必要または所望の環境または動作パラメータを選択するための利用プランを生成する命令と；
各クラスのデバイスおよび各環境または動作要件で利用プランをインプリメントおよび実行するために必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定する命令とを備えることを特徴とするコンピュータプログラム製品。
【請求項１１３】
デバイスのチームをリクルートするためソースデバイスで動作するソフトウェアアプリケーションと、デバイスのチームで実行可能な別個に実行可能なイメージのセットにソフトウェアアプリケーションをセグメント化する方法であって、前記方法は：
開始ソースデバイスと検査手順を到達させようとするデバイスの両方に共通な実行可能な形式でコード化された検査手順命令を含み、必要なリソースまたはケイパビリティを有するデバイスを探すよう動作可能な検査手順を、少なくとも１つの通信リンクを介して少なくとも１つの開始ソースデバイスと異なる到達可能なデバイスに送信することと；
到達可能なデバイスのそれぞれから、通信リンクを介して直接または間接的に、開始デバイスでリターン応答を受信することと；
ソフトウェアアプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイスのケイパビリティおよびリソースの組み合わせを特定する利用プランを決定するために、開始デバイスで実行する手順により、全ての応答到達可能デバイスからの受信リターンを分析することと；
開始デバイスで実行するアプリケーションプログラムにより、特定された利用プランに従って必要なリソースまたはケイパビリティを有すると特定された到達可能デバイスのそれぞれの少なくとも１つに実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを配信することと；
遭遇するデバイスを、アプリケーションの意図の１以上の態様を実行するためそのリソースおよびケイパビリティに従ってクラスに分けることと；
アプリケーションの意図の１以上の態様を実行するため明確なレンダリングその他ランタイム要件に関するニーズに従って、遭遇しそうな環境または動作要件をクラスに分けることと；
デバイスの各クラスおよび各環境または動作要件で、アプリケーションの意図の１以上の態様を実行できるようにするために必要な実行可能イメージに必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定することと；
ある候補デバイスのリストで、アプリケーションの意図を実行するのに利用する各デバイスで動作するデバイスと、対応する個々に割り当てられた実行可能イメージと、そのリソースおよびケイパビリティ、必要または所望の環境または動作パラメータを選択するための利用プランを生成することと；
各クラスのデバイスおよび各環境または動作要件で利用プランをインプリメントおよび実行するために必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定することとを含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００４年６月０８日に出願された、「効率的で低コストで、シームレスなデバイスインターオペラビリティソフトウェアプラットフォームのためのアーキテクチャ、装置および方法」」という名称で、発明者、Ｄａｎｉｅｌ  Ｉｌｌｏｗｓｋｙによる特許仮出願第６０／５７７，９７１号の、３５Ｕ．Ｓ．Ｃ．１１９（ｅ）による優先権を主張し、この出願はここに、参照によりその全体を本書に組み込む。
【０００２】
次の同時係属中の米国通常特許出願およびＰＣＴ国際特許出願もまた関連出願であり、参照によりその全体を本書に組み込む。
【０００３】
２００５年６月０８日に出願され、「デバイスリクルートメントインタオペラビリティおよび統一相互運用デバイスコンステレーションのアセンブリング」という名称の代理人整理番号第１８６２４５／ＵＳ／８号。
【０００４】
２００５年６月０８日に出願され、「コンテンツレンディションアダプテーションおよびインタオペラビリティセグメンテーションモデルのための方法およびシステムという名称の代理人整理番号第１８６２４５／ＵＳ／９号。
【０００５】
２００５年６月０８日に出願され、「相互運用可能なデバイスチームのレンディションデータおよびのコードを指定するデバイスインタオペラビリティソースを指定するための方法および装置」という名称の代理人整理番号第１８６２４５／ＵＳ／５号。
【０００６】
２００５年６月０８日に出願され、「相互運用可能なデバイスチームのためのインタオペラビリティアプリケーションを構築するためのデバイスインタオペラビリティフレームワーク」という名称の代理人整理番号第１８６２４５／ＵＳ／２号。
【０００７】
２００５年６月０８日に出願され、「インタオペラビリティアプリケーション仕様を相互運用可能なアプリケーションパッケージに処理するためのデバイスインタオペラビリティツールセットおよび方法」という名称の代理人整理番号第１８６２４５／ＵＳ／１４号。
【０００８】
２００５年６月０８日に出願され、「インタオペラビリティアプリケーションパッケージを組み立てるためのデバイスインタオペラビリティフォーマットルールセットおよび方法」という名称の代理人整理番号第１８６２４５／ＵＳ／１５号。
【０００９】
２００５年６月０８日に出願され、「複数の独立した処理ユニット中のデバイスインタオペラビリティランタイム確立イベントのシリアル化および同期ならびに制御データおよびオペレーションの調整方法」という名称の代理人整理番号第１８６２４５／ＵＳ／１６号。
【００１０】
２００５年６月０８日に出願され、「複数の処理ユニット中のリニアタスキングのための方法およびシステム」という名称の代理人整理番号第１８６２４５／ＵＳ／１１号。
【００１１】
２００５年６月０８日に出願され、「トランスレーションのない直接イベント構造およびイベント待ち行列レベルツーレベル通信を容易化する処理ユニットにおけるレベル間の縦階層化のための方法ならびにシステム」という名称の代理人整理番号第１８６２４５／ＵＳ／１０号。
【００１２】
２００５年６月０８日に出願され、「間断的に連結される相互運用可能な電子装置中のアプリケーション駆動型パワーマネージメントのためのシステムおよび方法」という名称の代理人整理番号第１８６２４５／ＵＳ／７号。
【００１３】
２００５年６月０８日に出願され、「インタオペラビリティアプリケーション駆動型エラーマネージメントおよび間断的に連結された相互運用可能電子装置間のリカバリーのためのシステムおよび方法」という名称の代理人整理番号第１８６２４５／ＵＳ／１７号。
【００１４】
２００５年６月０８日に出願され、「インタオペラビリティ命令セットのためのデバイスおよび方法」という名称の代理人整理番号第１８６２４５／ＵＳ／４号。
【００１５】
２００５年６月０８日に出願され、「インタオペラビリティコンテンツのカスタマイズされたプログラムダイナミックな生成のための方法およびシステム」という名称の代理人整理番号第１８６２４５／ＵＳ／３号。
【００１６】
２００５年６月０８日に出願され、「相互運用可能なコンテンツプレイヤデバイスエンジンのための方法およびシステム」という名称の代理人整理番号第１８６２４５／ＵＳ／１２号。
【００１７】
２００５年６月０８日に出願され、「ハードウェア抽象化層修正およびエンジンポーティングを可能にする相互運用可能なでデバイスのための方法およびシステム」という名称の代理人整理番号第１８６２４５／ＵＳ／１８号。
【００１８】
２００５年６月０８日に出願され、「間断的に接続された相互運用デバイス間のデバイス整合性およびセキュリティを維持するためのシステム方法ならびにモデル」という名称の代理人整理番号第１８６２４５／ＵＳ／１３号。
【００１９】
２００５年６月０８日に出願され、「間断的に接続された相互運用デバイス間のソーシャル同期インタオペラビリティのためのシステム方法およびモデル」という名称の代理人整理番号第１８６２４５／ＵＳ／１９号。
【００２０】
２００５年６月０８日に出願され、「間断的に接続された相互運用デバイス間のソーシャルセキュリティインタオペラビリティのためのシステム方法およびモデル」という名称の代理人整理番号第１８６２４５／ＵＳ／２０号。
【００２１】
２００５年６月０８日に出願され、「プレイヤおよびエンジンを有する相互運用可能デバイスの設定および操作のためのシステムデバイスならびに方法」という名称の代理人整理番号第１８６２４５／ＵＳ／６号。
【００２２】
２００５年６月０８日に出願され、「相互運用可能デバイスのインテリジェントチームの生成および形成を明確にするための方法ならびにシステム」という名称の代理人整理番号第１８６２４５／ＵＳ／２１号。
【００２３】
２００５年６月０８日に出願され、「１以上の独立したアドレス空間にアクセスするためバーチャルポインタを設定および利用するための方法ならびにシステム」という名称の代理人整理番号第１８６２４５／ＵＳ／２２号。
【００２４】
２００５年６月０８日に出願され、「シームレスなユニバーサルデバイスインタオペラビリティプラットフォームのためのアーキテクチャ装置および方法」という名称の代理人整理番号第１８６２４５／ＰＣＴ／２号。
【００２５】
２００５年６月０８日に出願され、「ユニバーサルデバイスインタオペラビリティプラットフォームのためのデバイスチームリクルートメントおよびコンテンツレンディションのためのアーキテクチャ装置ならびに方法」という名称の代理人整理番号第１８６２４５／ＰＣＴ／３号。
【００２６】
本発明は、類似または非類似特性を有し、装置間のシームレスなインタオペラビリティを容易にするデバイス間の通信を行うためのシステム、装置、方法、およびコンピュータプログラムソフトウェア製品に関し、特に、類似または非類似の恒久的または間断的に接続された電子装置間でコンテンツ、アプリケーション、リソース、および制御アクセスを共有するためのソフトウェア、方法、システム、および装置に関する。
【背景技術】
【００２７】
電子装置、特にポータブルおよびワイヤレス装置の数および種類が膨大に広がり、また、アプリケーションプログラムおよび装置の種類も拡張している時代において、複数の装置の電子およびプログラムのリソースを使用することでのみ達成できるアプリケーションの目的を実行するためには、種類が異なるこれらの装置の間で直接共有されるデータおよびコードに対応したニーズが生じている。デバイスのユーザが、ユーザの所望のする通信、データ転送、または共有の種類が前もってセットアップされあるいはされていない他のデバイスと通信できるというニーズもまた生じ、大きくなっている。例えば、ユーザは、デジタルカメラ上で写真コレクションを作成し、当該写真コレクションを見るためにパーソナルデータアシスタント（ＰＤＡ）タイプのデバイスやテレビ、プロジェクタに直接転送し、記憶装置に保存し、プリンタに転送できることを望んでいる。ユーザはまた、写真、タイトル、スライドのインデックスその他を含む連続したスライドショーをインプリメントするコードを、スライド画像が備えられているデバイスより大きなスクリーン用の解像度、またはよいグラフィック性能を有する別のデバイスに転送することを望んでいる。ユーザはまた、利用可能なプリンタでスライドショーの写真の一部を選択および印刷できることを望んでいる。このようなコード、データ、およびコンテンツ共有には他にも多くの例がある。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
従来の静的および手順的ソリューションの試み
リソースを計算する関連デバイスとのデータおよびコードの共有や、類似（同種）および非類似（異種）デバイスまたはデバイスタイプ間のデバイス制御は、「装置のインタオペラビリティ」または単に「インタオペラビリティ」として本分野において周知である。このインタオペラビリティに関連する必須および任意の重点課題には、（ｉ）コンテンツアダプテーション、（ｉｉ）コンテンツフォーマット、（ｉｉｉ）デバイスドライバ、（ｉｖ）デバイス間通信、（ｖ）個々のデバイスリソースおよび性能、（ｖｉ）デバイスに備えられるアプリケーションプログラム、（ｖｉｉ）デバイスへのアプリケーションプログラムのローディング、（ｖｉｉｉ）インタオペラビリティをサポートするデバイスリソースに関連する費用、（ｉｘ）相互運用デバイスのパワーまたはエネルギー管理、（ｘ）デバイス間接続が間断的で信頼性が低いインタオペラビリティ環境で実行するコードの信頼性がある。さらに、（ｘｉ）インタオペラビリティを可能にするために必要な開発、配備、および試験の取り組みの目的、（ｘｉｉ）詳細なインタオペラビリティ基準が存在していても、独立して開発または販売されたインタオペラビリティコンポーネントを有することに固有の信頼性の問題、（ｘｉｉｉ）エンドユーザが高度な技術的知識を有し、インタオペラビリティの管理に充分な時間と手間をかけることの困難さ、（ｘｉｖ）インタオペラビリティデバイス、データ、およびコンテンツのセキュリティ、（ｘｖ）インタオペラビリティインフラに関連するサイズ、性能、パワーマネージメント、およびコストトレードオフもさらに問題となる。これらの課題については以下にさらに詳述する。
【００２９】
コンテンツアダプテーションに関して、データ、アプリケーションプログラム（アプリケーション）、またはコントロールをある種類のデバイスから別の種類のデバイスに転送する際、注意する必要のある写真サイズ、ユーザインターフェース、制御装置および特殊効果、コンテンツフォーマット、機能その他パラメータ（アプリケーションおよびデータタイプ依存）については、コンテンツのインテリジェントなスケーリングまたはアダプテーションが必要である。これらを「アダプテーション」と総称する。コンテンツ、アプリケーション、コントロールを共有する際のアダプテーションが高度になるほど、相互運用可能なデバイスのセットは大きくなり、各デバイスの機能が高度になるほど、データ、情報、および／またはその他ケイパビリティの転送は効率的になり、デバイス、コードデータ、およびコンテンツが、ユーザにとってアプリケーションを実行しやすいものとなる。
【００３０】
インタオペラビリティにおける第２の問題は、ユーザが一般に、コンテンツフォーマットを指定するか、少なくとも考慮しなければならないという好ましくない要件から生じる。他のデバイスと通信ができても、他のデバイスとのインタオペラビリティを望むユーザが、コンテンツフォーマットおよび／または他のデバイスのコンテンツフォーマットの扱い方を知らない場合、この要因のみでもインタオペラビリティを阻害する恐れがある。
【００３１】
インタオペラビリティにおける第３の問題は、ユーザが一般に、インタオペラビリティを実行するには、その前に１以上のデバイスに１以上の特定の目的を有するドライバ、コード、データ、またはコンテンツのローディングを指定、考慮、または実行しなければならないという好ましくない要件から生じる。
【００３２】
インタオペラビリティにおける第４の問題は、ユーザが、ユーザのデバイスと１以上の他のデバイスとの間の通信に用いられ、、それぞれが通信メカニズム、プロトコル、インターフェース等を必要とする物理的な通信メカニズムおよびプロトコルを指定、考慮、または選択しなければならないという好ましくない要件から生じる。
【００３３】
インタオペラビリティにおける第５の問題は、ユーザが、自分の装置または必要なデータあるいはアプリケーションと相互運用するために必要なケイパビリティ、メモリ、プロセッサその他機能を持つデバイスを考慮または選択する必要があるという好ましくない要件から生じる。
【００３４】
インタオペラビリティにおける第６の問題は、ユーザが、関連する潜在的に相互運用可能なデバイスの一部またはすべてに備えておかなければならないアプリケーションを指定、考慮、および／またはロードする必要があるという好ましくない要件から生じる。
【００３５】
インタオペラビリティの第７の問題は、１以上のデバイスにコード、データまたはコンテンツのバージョンが違ったり、古いかったり、あるいは互換性がないによる完全あるいは部分的なアプリケーションの障害から生じる。
【００３６】
インタオペラビリティの第８の問題は、デバイスが、必要なアプリケーションを実行するためのコードをすべて、製造時またはアプリケーションを起動させる前に備えるか、ユーザによってデバイスの一部または全部に明確にロードされなければならないという好ましくない要件から生じる。
【００３７】
インタオペラビリティの第９の問題は、相互運用するデバイスに通信その他プロトコルおよびアプリケーションをインプリメントするために必要なプロセッサもしくはＣＰＵリソース、メモリリソース、電子ゲート、またはロジックその他インフラの量を提供することに関連する金銭的コストから生じる。
【００３８】
インタオペラビリティの第１０の問題は、相互運用するポータブルまたはモバイルデバイスに必要なバッテリの寿命を延ばし、またはサイズを小さくする効果的なパワーまたはエネルギーマネージメント方法を提供する必要性から生じる。短期間のインタオペラビリティには特に必要ないが、
他のデバイスとの相互運用では、ユーザがケイパビリティをほとんど利用しなかったり、他のユーザの当該デバイスへのアクセスを拒否しないデバイスでバッテリパワードレインを生成しないよう、このようなパワーマネージメントは非常に所望のされる。
【００３９】
インタオペラビリティの第１１の問題は、デバイス間の接続が断続的あるいは瞬間的で信頼性の低い環境で動作し続ける必要があるアプリケーションの信頼性に対する必要性から生じる。例えば、第２のデバイスと相互運用され、これと通信する第１のデバイスのアプリケーションを実行するコードは、それ自体がフリーズしたり、ハングしたり、大きな問題を起こしたり、第２のデバイスが範囲を離れるか、第１デバイスからの通信に応答できない時、フリーズしたり、ハングしたり、大きな問題を生じさせてはならない。さらに、インタオペラビリティアプリケーションを実行するために必要なすべてのコード、データ、およびコンテンツは、第２デバイスが再び信頼性があり利用可能になった場合に、自動的に復元および更新されることが好ましい。
【００４０】
インタオペラビリティの第１２の問題は、基本的に、現実的で将来的なデバイスニーズやケイパビリティを予測する能力や、完全かつ正確に理解し、インプリメントし、これらのインプリメンテーションを正しく備える能力が低いプログラマまたは回路設計者のインタオペラビリティ標準に基づいて、デバイスが独立したメーカーによって生産される場合のアプリケーションの信頼性の欠如から生じる。インタオペラビリティの第１３の問題は、グラフィックやビデオ、サウンド等に必要な最適化に依存できないコード実行速度の低さから生じる。
【００４１】
インタオペラビリティの第１４の問題は、ユーザとプロバイダの両方を失望させる前述の総ての問題により、インタオペラビリティについて採用される可能性のあるアプリケーションおよびデバイスを実行するための相互運用可能なコード、データ、およびコンテンツの利用可能性の欠如から報じる。
【００４２】
これら１４のインタオペラビリティ上の問題は、生じる可能性のある問題の種類を単に例示したもので、すべての状況で生じる問題の完全な一覧を意図するものでも問題を特定するものでもない。例えば、製造時に互いと相互運用することを目的とする２つの同一デバイス間のインタオペラビリティは前述の問題のどれも、あるいは一部しか呈示しないが、この種の類似デバイスのインタオペラビリティは、デバイスユーザが今日直面する一般的な状況を示さず、類似デバイスのインタオペラビリティ問題に取り組むささやかな試みは不完全で洞察力に欠け、明らかに成功していない。
従来の静的および手順的ソリューションの試み
【００４３】
インタオペラビリティソリューションに対する従来の試みは全体として２つのカテゴリー、（ｉ）静的インタオペラビリティソリューション（「静的」）または、（ｉｉ）手順的インタオペラビリティソリューション（「手順的」）に分けられる。従来の静的ソリューションでは、各デバイスが同じ特定の通信プロトコルをサポートし、固定フィールドレイアウトの特定の厳しく指定されたデータ構造を送ることを求める。静的アプローチでは、セマンティック、コード、ディスプレイケイパビリティは、インタオペラビリティがデバイス間に確立される前にすべてのデバイスに存在していなくてはならない。各コンテンツタイプ、アプリケーション、またはデバイスケイパビリティは、関連する全デバイスについて製造時に周知で、インプリメントおよびインストールされ、あるいは、ユーザは、デバイス、ソフトウェアデータまたはコンテンツの所望のインタオペラビリティ開始前に、必要に応じてアプリケーションプログラム、プロトコルおよび／またはドライバをインストールしなければならない。ユーザは、訓練を受けた情報技術専門家でなく、ドライバ、アプリケーション、オペレーティングシステムコンポーネント、プロトコル等を知らず、または持っていない場合があるため、利用可能な時間内で所望のインタオペラビリティを設けることが不可能な場合がある。さらに、静的ソリューションでは、特定の静的ソリューションのセットをインプリメントしなければならない場合が多い。
【００４４】
例えば、デジタルカメラとテレビまたは表示装置（ＴＶ）との間で、スライドショーケイパビリティによって写真セットを共有するには、スライド画像データやスライド順序またはシーケンス情報をＴＶに送るためのＢｌｕｅｔｏｏｔｈ無線ケイパビリティ等の共通の静的プロトコルが必要になる。ＴＶがどのように処理したらよいのか認識させるものとしてのスライドおよびスライド順序情報を、ＴＶに認識させるために、静的なコンテントフォーマットが必要である。そして、特定のコンテンツフォーマットでスライドショーをレンダリングおよび制御できる少なくとも１の静的スライドショープログラムが、ＴＶとデジタルカメラの両方に存在しなければならない。ユーザは、画像または写真およびスライド順序情報の転送を別途開始しなければならなかったり、ＴＶで情報を探したり関連させたり、ＴＶで正しいスライドショーアプリケーションを動かしたりしなければならない。両側の静的スライドショープログラムの高度化により、デジタルカメラが、カメラで開始したＴＶ上のスライドショーの制御に利用できない場合もあり得る。このようなカメラに基づく制御が不可能な場合、必然的に制御のための何らかのメカニズムを設けることになる。静的アプローチは、相互運用可能なすべてのデバイスの製造時に周知の特定のアプリケーションをよく理解するためより適したソリューションになる場合がある。しかしながら、静的アプローチは、ほとんどすべてのケイパビリティを製造時に周知し、カスタムインプリメントしなければならないことと、製造後のアップグレードやエラー修正能力が限られていることと、各静的プログラムインプリメンテーションを正しくかつ完全にポーティングして、相互運用前に異なるデバイスで動作し、すべてのデバイスに備えるようにしなければならないこととを含む大きな制限がある。これは、特定のアプリケーション、通信媒体およびインタオペラビリティを必要とする所望のデバイスセットについて特定のドライバのローディングおよびアップデートによって解決されることが多い。
【００４５】
静的ソリューションが利用可能な場合でも、標準やアプリケーションのバージョン違いの必然性により信頼性は下がる。そのため、２個のデバイスでデータまたは手順を共有しようとする場合、デバイスが基準の異なるバージョンのに依存したり、プログラムが基準の異なるバージョンに依存したり、バージョンの異なるアプリケーションがデバイスに備えられていると、障害が発生することがある。さらなる信頼性上の問題は、相互運用に用いる標準セットの独立したインプリメンテーションでの予測できないエラーやショートカットから生じる。このような標準インプリメンテーションは、２つのインプリメンテーションが共に動作しようとする場合、予測できない方法でインタラクトすることがある。一般に、開始デバイスと相互運用しなければならない対象デバイスすべてが、開始デバイスの製造時に存在しない場合は特に、すべてのデバイスセットですべての標準インプリメンテーションのすべての順列を試験することは実用的でないか、不可能な場合が多い。
【００４６】
静的アプローチのさらに重要な制限の１つは、多数のＮ個のデバイスまたはアプリケーションを相互運用させるための仕事量が、装置および／またはアプリケーションの数Ｎが増えるにつれ、非常に急激に増している点である。メーカーは現在、サイズの限定されたデバイスセットさえ、増え続ける大型デバイスおよびアプリケーションセットで相互作用させるため、コンテンツタイプ、アプリケーションプログラム（「プログラム」）、通信プロトコル等に数百もの静的標準を生成することに疲弊している。これはまた、各デバイスが、所望のすべての相互運用可能デバイスで所望のインタオペラビリティオプションについて各静的ソリューションに対応するようメモリ、スクリーンサイズ、制御装置、プロセッサ、およびバッテリ電力を有することを必要とする。そうでなければ、真のデバイスおよびアプリケーションインタオペラビリティは達成できない。この従来の問題および限界をよりよく理解するため、ここで、アダプテーションでは、他のタイプのデバイス（Ｎ−１つのデバイス）それぞれと共有しなければならない各タイプのデバイス（Ｎ個のデバイス）について、ソフトウェアエンジニアリング開発プロジェクトが必要なことを考えてみる。開発の観点からは、これは、すべてが互いと相互運用したいＮ個のデバイスタイプの世界では、Ｎ×（Ｎ−１）のアダプテーションを考慮、開発、インプリメント、および試験しなければならないため、Ｎ×ＮまたはＮ２のオーダーの問題となる。
【００４７】
さらに、デバイス数が増し、必要なアダプテーションがＮ２に向かって増えるにつれ、高品質製品を得るための費用と困難さは、全体的な複雑度の増加のため、さらに早い速度で増加する傾向にある。これは、高信頼性および高品質のソフトウェアおよびハードウェアソリューション実現の困難さが、全体的な複雑度の増加と共に高まるためである。これは純粋に「ソースコードのサイズ」の問題ではなく、行動の予測不可能性やイベントの予測不可能性、未知の将来ケイパビリティ等、異なるメーカーのデバイスを共に動かそうとする際の一般的な要因によるものである。
【００４８】
例えば、デバイスの数が５から６に増えると、インタオペラビリティアダプテーション要件はＮ×（Ｎ−１）の関係により２０から３０に増える。そのため、これが増えるにつれ、プロジェクト全体の複雑さがさらに早く増すことになる。
【００４９】
Ｎ個のデバイスを共に動かすには、実質的にＮ２個のアダプテーションを必要とするというＮ乗のオーダーの問題を図１に示す。静的アプリケーションを用いた従来のデバイス間協働は、ユーザにとっては利用が比較的単純だが、高度の開発、管理および配備努力と、古いデバイス、アプリケーションおよびデータタイプと新しいデバイス、アプリケーションおよびデータタイプとの間の互換性とインタオペラビリティを維持する為の不断のアップデートが必要である。
【００５０】
図２を参照すると、総当りアプローチを用いたわずか８個のデバイスタイプのデバイス間協働または限られたインタオペラビリティのインタラクションに５６個のアダプテーションとさらに５６個の試験手順を必要とすることを示す。
【００５１】
総当り方法のＮ２個の問題とは別に、静的アプローチではまた、多数の標準を組み合わせなければならない。Ｍｉｃｒｏｓｏｆｔが提唱するＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）アプローチはおそらく、静的アプローチの中では最大の支持者と範囲を持っている。ＵＰｎＰは、静的（非手順的）標準のセットを組み込み、異なるＸＭｌやデータ構造ベース記述を有する異なるクラスのデバイスおよびサービスをすべて列挙することで、デバイスインタオペラビリティ関連の問題の一部を解決しようとするものである。しかしながら、ＵＰｎＰアプローチでさえ大きな限界があり、その一部を以下に簡単に説明する。
【００５２】
第１に、ＵＰｎＰは、動かすためにモジュール、コード、電力、メモリの大型集積を必要とするため重い。これにより、小規模なプロセッサや小型ランダムアクセスメモリ、小型バッテリ容量等を有する薄型で低コストのバッテリベース電力デバイスに適さなくなる。
【００５３】
第２に、ＵＰｎＰのコンテンツや機能最適化ケイパビリティは少ない。ＵＰｎＰは一般に、ワンサイズのアプリケーション、コンテンツまたはユーザインターフェースがすべての関連デバイスでうまく動くことを想定している。これは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓベースのデスクトップ型パーソナルコンピュータ（ＰＣ）では、十年前には妥当な想定だったが、次世代に生まれるであろうハイブリッドおよび多様化した電子機器は言うまでもなく、ページャー、デジタルカメラ、パーソナルコンピュータ等様々に相互運用されなければならないデバイスに満ち溢れた世界のオペレーションにとっては、粗末な想定であり基礎である。
【００５４】
第３に、ＵＰｎＰは現在利用可能な多様で広範囲なデバイスセットのニーズを満たさない限られたユーザインターフェースセットしか与えない。
【００５５】
第４に、ＵＰｎＰは、要求されたタスクを実行するため、プログラムとドライバが利用する前に全デバイスに備えられていることを必要とする。
【００５６】
第５に、ＵＰｎＰの目的は、少なくともＮ（Ｎ２）問題を部分的には回避することだが、実際には、インタオペラビリティの基礎としてＮ２を用いても、複雑な標準の独立したインプリメンテーションの置換により信頼性高いインタオペラビリティを実現しようとする場合、プログラムやコード、データおよびコンテンツを、相互運用するすべてのデバイスでポーティング、配信および試験する必要のある新しいアプリケーションを出すには、やはり前述のような大がかりなＮ乗（Ｎ２）開発／配備／試験努力が必要である。
【００５７】
第６に、ＵＰｎＰプログラム、デバイス、コンテンツおよび標準はすべて同期させ、同じか少なくとも互換性のあるバージョンおよびアップデートを同時に配備しなければならない。
【００５８】
第７に、デバイスやコンテンツのケイパビリティの進化に伴い、既存ＵＰｎＰプログラム、データおよびコンテンツベースのデバイは新しいデバイスをサポートしなくなる傾向がある。
【００５９】
第８に、既存デバイス、ＵＰｎＰを含む標準およびアプリケーションのバージョンの互換性を維持するコストは、全体的なプロジェクト複雑性をさらに急激に増加させる。
【００６０】
第９に、プロジェクトの複雑性が増すと、標準静的アプローチとしてのＵＰｎＰの複雑性や多様性固有の問題のため、使いやすさや信頼性が下がる。
【００６１】
第１０に、ＵＰｎＰは、デバイス間で１つまたは多くのデータ構造を送る多くのニーズや、このデータ構造を、バイナリ表記よりはるかに多くの送信帯域と時間を必要とする人間が読めるテキストフォーマットで表現する場合のニーズによって課される要件にはまだ対応していない。さらに、デバイス間で送られるデータ構造の多くは、バイナリや、さらに一般的でないフォーマットより、ＸＭＬ、人間が読めるテキストフォーマットで表現され、ＸＭＬフォーマットは、ＸＭＬに必要なＣＰＵ集約構文解析オペレーションを実行するため、はるかに多くのＣＰＵオペレーション、メモリおよび／またはソフトウェアプログラムコードサイズを必要とする。
【００６２】
最後に、デバイスやアプリケーションのインタオペラビリティに対する従来の静的アプローチの限界の一部に比較して、静的標準は、標準ベースインプリメンテーションの全体的な複雑さやサイズを減少させるため、プロトコルの数やコンテンツタイプ、アプリケーションタイプを制限することが多い。例として、ＵＰｎＰはベース通信プロトコルとしてＴＣＰ／ＩＰしか許可しないことが揚げられる。これはＢｌｕｅｔｏｏｔｈ、ＵＳＢ、ＭＯＳＴ、ＩＲ等その他非ＴＣＰ／ＩＰプロトコル等、他の重要な既存通信プロトコルの効率的利用を有効に除外する。
従来の手順的ソリューションの試み
【００６３】
静的標準アプローチの代替は、手順的標準の作成に依存する。ハードウェアに実装されたり、ソフトウェアにエミュレートされた手順的標準技術はユビキタスである。膨大な数のハードウェアマイクロプロセッサが存在し、それぞれが異なる問題クラスに最適化された命令セットやインターフェースを有し、特定のタスクセット周辺に最適化された多数の高レベルなソフトウェアでエミュレートされた命令セットおよび環境が存在する。これらは例えば、Ｊａｖａ（一般にポータビリティやプログラミングしやすさのために最適化されたアプローチ）、ＰｏｓｔＳｃｒｉｐｔ（一般に、印刷済みページ表示やプリンタ制御機能のために最適化されたアプローチ）、Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｉｅｓ（一般に、非常に広範囲で豊富なマルチメディアメッセージを効率的に表すよう最適化）を含む。ＪａｖａおよびＰｏｓｔＳｃｒｉｐｔは、コンピュータ技術では周知である。Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｉｅｓおよび関連システムと方法の態様は、例えば、「セキュアな通信およびメッセージングのためのハードウェアアーキテクチャ、オペレーティングシステムおよびネットワークトランスポートニュートラルシステム、方法およびコンピュータプログラム製品」という名称で、Ｍｉｃｈａｅｌ  Ｌ  Ｗｅｎｏｃｕｒ、Ｒｏｂｅｒｔ  Ｗ．  ＢａｌｄｗｉｎおよびＤａｎｉｅｌ  Ｈ．  Ｉｌｌｏｗｓｋｙを発明者として２００３年１月９日に公開された米国特許出願公開第２００３０００９６９４Ａ１号、「セキュアな証明書およびシステムとそれを発行し、利用するための方法」という名称で、Ｍｉｃｈａｅｌ  Ｌ  Ｗｅｎｏｃｕｒ、Ｒｏｂｅｒｔ  Ｗ．  ＢａｌｄｗｉｎおよびＤａｎｉｅｌ  Ｈ．  Ｉｌｌｏｗｓｋｙを発明者として２００２年１１月７日に公開された米国特許出願公開第２００２０１６５９１２Ａ１号その他特許出願に記載される。
【００６４】
手順的インタオペラビリティアプローチは、基本的なデータ構造や静的アプリケーションに加えて、デバイスでプログラム、手順、データおよびコンテンツを送信できるよう、相互運用する全デバイスに共通のランタイム環境を確立するか、あるいはこれを有するか設けることが一般的である。現在、先進的なインタオペラビリティ手順的ソリューションの１つは、ＪａｖａプラットフォームとそのＪＩＮＩ拡張である。Ｊａｖａベースの手順的アプローチの例として、Ｊａｖａで書いたスライドショーは、写真やスライドの順やシーケンスデータをカプセル化や参照、他デバイスとの相互運用、他デバイスへのコンテンツの適合、情報やＪａｖａスライドショープログラムのＴＶへの送信ができる。Ｊａｖａスライドショープログラムは、製造後、カメラで動作可能で、スライドショープログラムがＴＶに予め存在していない場合でも、ＪａｖａイネーブルなＴＶとのインタオペラビリティを可能にする。
【００６５】
Ｊａｖａは広く利用され、対応して限定されるインタオペラビリティの提供において限られた成功となっているが、幅広い利用を妨げる重大な欠陥があり、特に、プログラムコードやデータ、一時的バッファを保存するためのコスト、パワー効率、プロセッサ効率、メモリ効率が非常に重要な問題となる小型モバイルデバイスではそれが当てはまる。また、異なるデバイスで動作するアプリケーションのバイナリ互換性に対するＪａｖａバーチャルマシン（ＶＭ）アプローチは、デバイスが存在するまさにその理由と矛盾する。Ｊａｖａその他従来の手順的インタオペラビリティアプローチには厳しい限界がある。例として５つの限界を以下に述べる。
【００６６】
第１に、Ｊａｖａバーチャルマシンアプローチは、すべてのデバイスで同じバイナリコード（Ｊａｖａバイナリコード）が動作できるようにするため、すべてのデバイスがアプリケーションに対して正確に同じバーチャルコンピュータのように見えるようにするか、少なくともそれを試みる。バイナリ互換性を維持するためには、バーチャルマシンの定義およびインプリメンテーションの一部として予め定義していないデバイスケイパビリティにアクセスする試みを回避する必要がある。そのため、本来の機能が共通のバーチャルマシン定義の一部でないデバイスのケイパビリティにアクセスする必要がある場合、複数のデバイス間でバイナリ互換性が失われる。大半の非ＰＣデバイスハードウェアやソフトウェアは、特定の目的やフォームファクタ、価格ポイント、ユーザインターフェースあるいは機能性について特化または最適化されているのが普通であるため、そのデバイスが対象とするアプリケーションについて、基本的で独自のネイティブな機能やケイパビリティにアクセスしなければならない場合が多い。多くのポータブルまたは特殊目的デバイスでは、その存在意義は、独自で異なるケイパビリティと機能に対するニーズである。これは、アプリケーションにとってすべてを同じに見せるためデバイス間の相違を隠すＪａｖａバーチャルマシンアプローチと対立する。
【００６７】
第２に、Ｊａｖａは、効率的な実行と効率的なメモリ利用を犠牲にしてプログラミングし易さのための最適化した汎用言語である。そのため、中度の処理能力で利用できるメモリがほとんどない多くの薄型デバイスやコストが重要な場合には、最も効率的または効果的なソリューションではなくなる。
【００６８】
第３に、マルチメディアコンテンツの応答時間は、Ｊａｖａ手順的アプローチを用いて保証することができない。大半のＪａｖａプログラムは、異なるサイズのメモリ構造の頻発する割り当ておよび再割り当てに大きく依存しており、メモリフラグメンテーションを招く。このメモリフラグメンテーションはしばしば、デバイス内のプロセッサがメモリ内のガーベージコレクションを実行している間、コンテンツのレンダリングを停止しなければならない時間を生じさせる。ユーザは、これが発生すると、オーディオやビデオのレンダリングの円滑さの途絶を経験することになる。
【００６９】
第４に、Ｊａｖａは重要な速度とサイズの問題を生じる。インタオペラビリティに必要なＪａｖａとその関連技術およびライブラリは比較的重量で、実行のための比較的多数のＣＰＵサイクルと、保存のための比較的大量のメモリを必要とする。Ｊａｖａで書かれたインタオペラビリティプログラムはユーザインターフェース、マルチメディアレンダリング、デバイス列挙、堅牢度クラスプラットフォームデバイスのインタオペラビリティ、異なるタイプのコードおよびデータ動的アダプテーションを含み、これらオペレーションのどれもＪａｖａ命令セットや環境にネイティブでないため、これら機能はすべてライブラリや特殊目的のＪａｖａコードシーケンスを用いて構築しなければならず、大量のコードを書いて交換する必要がある。その結果、インタオペラビリティのためのＪａｖａプログラムは非常に遅くなり、プロセッサのパワーやバッテリの寿命またはコストが重要な問題となるデバイスでの利用を制限することになる。デバイスが充分なリソースを持たない場合、Ｊａｖａベースのインタオペラビリティソリューションは不可能である。
【００７０】
第５に、Ｊａｖａは、インタオペラビリティにとってせいぜい限られた不完全なベースインプリメンテーションを提供するだけである。このため、相互運用のためには全デバイスに多数のライブラリが存在するか、必要なプログラムコードを含むサーバに高速で常時接続する必要がある。Ｊａｖａのベース命令セットに含まれないオペレーションのパフォーマンスをＪａｖａ言語自体に設けなければならず、これらオペレーションの実行に使えたであろうネイティブなコードに対し、ランタイムパフォーマンスを大きく制限する。不足しているインタオペラビリティのベースオペレーションは、（ｉ）マルチメディア動画再生、（ｉｉ）他デバイス対象のプログラム、データ、コンテンツ、ユーザインターフェース、コントロールのアダプテーション、（ｉｉｉ）コンテンツを発したデバイスが自動的かつ容易にそのコンテンツをインタオペラビリティプログラムと結合できるようなカスタムプログラムのコンピュータ生成、（ｉｖ）広範囲なプロトコル上でのデバイス、サービスおよびリソースの発見、（ｖ）異なるデバイスで動作するプロセスの同期および／または直列化、（ｖｉ）デバイスのパワーマネージメント、（ｖｉｉ）デバイスが間断的に接続を中断および再取得する時のアプリケーションおよび同期の復元のネイティブなサポートを含む。
【００７１】
Ｊａｖａ  ＶＭ仕様があるクラスのデバイスやアプリケーションに不十分であることがわかると、この新しいクラスのデバイスの、既知となったネイティブなサポートのニーズに対処するため、新しいＪａｖａ  ＶＭ仕様が生まれるが、あるＶＭのために書かれたＪａｖａプログラムは、異なるＶＭ仕様に従うデバイスとのバイナリ互換性や相互運用性を持たないのが一般的である。Ｊａｖａ  ＶＭ仕様は、Ｊ２ＭＥ、ＭＩＤＰ１．０、ＭＩＤＰ２．０、ＣＤＣを含む様々なデバイスクラスに存在するが、さらに相互運用不可能なＪａｖａ  ＶＭ仕様とインプリメンテーションのこのような増加は、Ｊａｖａ  ＶＭ利用によるほんのわずかなインタオペラビリティを達成するプログラムやデバイスのタイプや形式を細分化し続けている。
【００７２】
Ｘｅｒｏｘ  Ｐａｌｏ  Ａｌｔｏ  Ｒｅｓｅａｒｃｈ  Ｃｏｍｐｌｅｘ（ＰＡＲＣ）は、「Ｏｂｊｅ」というＪａｖａプラスＪｉｎｉインタオペラビリティ技術のバリエーションを発表した。Ｏｂｊｅは、明示的にＪａｖａに基づくか、あるいは代替としての、未指定で未実現の小型バーチャルマシンベース技術である。Ｏｂｊｅは、デバイスを効果的にチームにし、全デバイスが、全マシンでプログラムをポーティングするか常駐させなければならないという要件を取り除くために必要な手順的方法を与える１つの方法を指し示すが、Ｏｂｊｅインプリメンテーションは、用いる手順ベースについて、細部にＪａｖａ  ＶＭモデルからの違いをまったく示さないため、ＪａｖａプラスＪｉｎｉアプローチとして類似のケイパビリティおよび限界を有することが予想される。
【００７３】
別の手順的アプローチであるＰｏｓｔＳｃｒｉｐｔはかなり長い期間存在しており、ＰｏｓｔＳｃｒｉｐｔ文書とＰｏｓｔＳｃｒｉｐｔプリンタとの間に高度なインタオペラビリティを確立する際、非常に有効な印刷ページ記述言語を与える。ＰｏｓｔＳｃｒｉｐｔ文書は、プリンタ内部のＰｏｓｔＳｃｒｉｐｔソフトウェアエンジンで実行される時、ＰｏｓｔＳｃｒｉｐｔが今いるプリンタ上に可能な最高解像度を利用しながら、ハードウェアのプリンタエンジンを制御し、印刷ページの画像を再生するプログラムである。ＰｏｓｔＳｃｒｉｐｔは、文書とプリンタのインタオペラビリティに大きく限定される。この限界の理由は、ＰｏｓｔＳｃｒｉｐｔ文書が、人間が読むことの出来るテキストで表されるという事実を含む。これが、文書とプログラムのサイズを、バイナリプログラムを超えて大きく拡張することになる。プログラムが動作している時、テキストは構文解析オペレーションを必要とするため、必要なプロセッササイクルが増え、プログラムがバイナリで表現されている場合はやスクラッチメモリが必要になる。さらに、ＰｏｓｔＳｃｒｉｐｔは、（ｉ）マルチメディアビデオ／オーディ／動画再生、（ｉｉ）アプリケーション、データ、コンテンツ、ユーザインターフェースまたはコントロールの他対象デバイスへのアダプテーション、（ｉｉｉ）デバイス、サービスおよびリソースの発見、（ｉｖ）複数デバイスで動作しているプログラムの同期および直列化、（ｖ）デバイスのパワーマネージメント、（ｖｉ）他のデバイスの発見および利用、（ｖｉｉ）デバイス間の堅牢な接続の維持、または（ｖｉｉｉ）今はデバイスで共通の共通フラッシュメモリを含む各種記憶媒体への効率的なアクセスの重要な本来のサポートを提供しない。
【００７４】
Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｉｅｓは、マルチメディアメッセージをカプセル化するために設計された可変長さ手順的命令セットを与える。Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｉｅｓおよび関連システムと方法の態様は、例えば、「セキュアな通信およびメッセージングのためのハードウェアアーキテクチャ、オペレーティングシステムおよびネットワークトランスポートニュートラルシステム、方法およびコンピュータプログラム製品」という名称で、Ｍｉｃｈａｅｌ  Ｌ  Ｗｅｎｏｃｕｒ、Ｒｏｂｅｒｔ  Ｗ．  ＢａｌｄｗｉｎおよびＤａｎｉｅｌ  Ｈ．  Ｉｌｌｏｗｓｋｙを発明者として２００３年１月９日に公開された米国特許出願公開第２００３０００９６９４Ａ１号、「セキュアな証明書およびシステムとそれを発行し、利用するための方法」という名称で、Ｍｉｃｈａｅｌ  Ｌ  Ｗｅｎｏｃｕｒ、Ｒｏｂｅｒｔ  Ｗ．  ＢａｌｄｗｉｎおよびＤａｎｉｅｌ  Ｈ．  Ｉｌｌｏｗｓｋｙを発明者として２００２年１１月７日に公開された米国特許出願公開第２００２０１６５９１２Ａ１号その他特許出願に記載される。
【００７５】
Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｙ構造および関連技術を含むＳｔｏｒｙｍａｉｌ発明は、本特許と同じ発明者であるＤａｎｉｅｌ  Ｈ．  Ｉｌｌｏｗｓｋｙによって発明された。このＳｔｏｒｙｍａｉｌ命令セットにより、それまで既知のマルチメディアコンテンツ表現で大きな利点となる「Ｓｔｏｒｉｅｓ」と呼ばれるユニバーサル手順的フォーマットでトランスコード化されたマルチメディアコンテンツを表現できるようになる。しかしながら、Ｓｔｏｒｙｍａｉｌ技術は、デバイス対デバイスのインタオペラビリティ問題に完全に対処しておらず、Ｓｔｏｒｙｍａｉｌ技術をデバイス対デバイスのインタオペラビリティ達成に適用しようとすると、すぐに複数の問題および限界が明らかになる。第１に、Ｓｔｏｒｙｍａｉｌ命令セットは、多くのスクラッチメモリの利用を必要とする小型エンジンサイズに最適化されている。第２に、Ｓｔｏｒｙｍａｉｌ命令セットは、コンテンツ動作中、特殊なスレッディングモデルのインプリメンテーションという負担を負っている。第３に、Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｉｅｓは、ＪＰＥＧやビットマップ画像等の基本的なコンテンツタイプさえトランスコーディングを必要とする。第４に、Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｙ技術は、デバイス、サービスまたはリソース発見をネイティブにサポートしない。第５に、Ｓｔｏｒｙｍａｉｌ  Ｓｔｏｒｙ技術は、複数のデバイスで動作するプログラムの同期に対し、本来のベースサポートを持たない。そのため、Ｓｔｏｒｙｍａｉｌ技術およびユニバーサル手順メディアフォーマットは、今日の従来技術には重大な利点となるが、電子およびコンピュータ業界で現在明らかなデバイス対デバイスのインタオペラビリティ問題の充分な解決にはならない。
【００７６】
そのため、静的アプローチも現在の手順的アプローチも、特に異種デバイスと事前に未知のアプリケーションには満足いくデバイス対デバイスインタオペラビリティを提供しない。この問題は、現在のクライアント−サーバおよびピアツーピアのデバイス間インタオペラビリティモデルを考えるとさらに複雑になる。
従来のクライアント−サーバおよびピアツーピアモデル
【００７７】
当業の現状では、複数デバイスで動作する相互運用プログラムは一般にクライアントサーバモデルまたはピアツーピアモデルを利用する。
【００７８】
クライアントサーバ環境モデルでは、１つのデバイス（すなわち、サーバ）がサービスを提供し、別のデバイス（すなわち、クライアント）がそのサービスを利用する。これによって、複数のクライアントデバイスが１つのより能力のあるサーバデバイスを利用してデータの保存や処理をする一方、より軽量なクライアントデバイスは、要求を行って結果を表示する力があるだけで充分となる。クライアントサーバアプローチの限界は、一般にサーバをネットワークに登録して、比較的高速接続でクライアントが常にアクセス可能であるようにしなければならない点である。
【００７９】
ピアツーピア環境モデルでは、相互運用デバイスは一般に、アプリケーションを実行するために必要なすべての機能を持つと想定される。ピアツーピアモデルではまた、相互運用するデバイスはすべて、適切な連結やプロトコルについて同意できるよう、接続を確立する前に採用するプログラムやサービスを知っていなければならない。アプリケーションを実行するため完全なケイパビリティを持っていなければならず、相互運用するデバイスすべてにピアとなるプログラムプロトコルレイヤが予め存在していなければならないことは、ピアツーピアモデルをデバイスインタオペラビリティに適用する際の大きな限界となる。実際、ピアツーピアデバイスは、ソフトウェアの別の不完全なインプリメンテーションまたはバージョンに遭遇することも多く、様々な不完全なインプリメンテーションの予測できない反復のため協働に失敗することになる。このような問題を是正するため、ドライバや他のソフトウェアをしばしばアップデート、配信およびインストールしなければならない。これによってインタオペラビリティの問題を是正することはできるが、管理やインプリメンテーション、配信、障害に関連するフラストレーションやこれを修正するために必要な複雑性、高度化、時間は、ピアツーピアベースデバイスのインタオペラビリティの重大な問題であり続ける。
【００８０】
パーソナルコンピュータの時代では、現在、最も広く使われているが限られたインタオペラビリティプラットフォームは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムである。Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）では、ＰＣをＩＢＭ、東芝、シャープ、Ｄｅｌｌその他どのメーカーが製造したかに関わらず、理論的にどんなアプリケーションのバイナリ画像も、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムで動作するあらゆる標準的ＰＣアーキテクチャデバイスでは動作可能で有益である。しかしながら、実際には、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓの実際の動作環境ではインタオペラビリティに限界がある。
【００８１】
コンピューティングデバイスと情報機器が汎用パーソナルコンピュータモデルから分かれ、携帯電話や携帯音楽プレイヤ、リモコン、ネットワーク可能メディアプレイヤおよびルータ、その他多数のデバイスとしてより専門的に特化したデバイスになるにつれ、総ての（あるいは少なくとも大半の）デバイスでバイナリ互換であるだけでなく、各デバイスのリソースに基づき、複数プロトコルで特別なオンザフライのデバイスチームを形成できるアプリケーションの迅速かつ効率的な開発ができるアプリケーションプラットフォームが求められている。アプリケーションは、どのデバイスもすべてのソフトウェア、ハードウェアその他リソースを自身へインプリメントする必要のないアプリケーションを実行するため、すべてのデバイスに実行をスプレッドできなければならない。
【００８２】
現在の技術では、スプレッド対象のデバイスが多様なタイプで、異種のデバイスハードウェア、ソフトウェアおよびオペレーティングシステム（あれば）特徴を有する場合は特に、複数のデバイスで動作可能でスプレッドできるプログラムの作るための効果的なソフトウェアプラットフォームはない。標準化された埋め込みオペレーティングシステムは多数あるが、ディスプレイやコントロールの配置を含め、アプリケーションがデバイス独自のケイパビリティや機能にアクセスする必要があるため、両デバイスが同じ埋め込みオペレーティングシステムおよびプロセッサを使っていたとしても、あるデバイスのために作られたプログラムが別の異なるデバイスで動かした時に有用である可能性はほとんどない。そのため、これまで周知の先行技術の装置および方法の欠点や短所を回避しながら、信頼性が高く、使いやすいデバイス、アプリケーションプログラム、データおよびコンテンツのインタオペラビリティを提供する改良された方法およびシステムに対する大きなニーズが本分野において存在することは明白である。
【課題を解決するための手段】
【００８３】
本発明は、多数の進歩的システム、デバイス、装置、コンピュータプログラムおよびコンピュータプログラム製品、手順、方法からなり、共にデバイスおよびシステムインタオペラビリティを、これまでの本分野の現状より単純で、信頼性高く、堅牢、パワフル、コスト効果高いものにする。採用する技術は、手順的インタオペラビリティ技術に基づく。本発明は、既存の手順的インタオペラビリティ技術と重要かつ深遠な方法で異なる。従来技術は、デバイス間の相違を隠し、全デバイスで同じ実行可能バイナリ画像が動くようにしているが、本発明は、デバイスのすべての資産に対するアクセスを互いに与え、アプリケーションが特別のデバイスグループを形成し、グループ内のデバイスが１つのデバイスであるかのように、デバイスのグループ全体に実行を効果的にスプレッドできるようにする。
【００８４】
従来の既存インタオペラビリティ技術の大半は、信頼性の高い高速ネットワークで接続され、ほとんど再構成されることがなく、充分な電力に連続してアクセスでき、訓練を受けた常勤専門化によって構成および維持される法人や政府ネットワークのパワフルな汎用コンピュータ上で開発された技術の延長である。これらの技術は、現在利用可能になりつつあり、インタオペラビリティに必要なソフトウェアとハードウェアの構成や維持について訓練を受けておらず、あまり関心もない個人によって利用されるモバイル、バッテリ電源、間断的接続および制約の多いデバイスのインタオペラビリティに適用された場合には不十分である。
【００８５】
本発明は必然的に、勢いを増して市場に進出しつつあるモバイルその他特殊目的デバイスのインタオペラビリティの単純さ、堅牢度、コスト効果、効率およびセキュリティを大きく前進させるために協働する方法である新しいソフトウェアエコシステムを含む。
【００８６】
図３は、それ自体がインタオペラビリティプログラムであるＤａｒｔＰｌａｔｆｏｒｍと総称する新しい手順的およびソフトウェアエコシステムの実施例の例示的構成要素を示す。ここではＤａｒｔＳｏｕｒｃｅ１００であるソースには、アプリケーションの趣旨を実行するために必要なすべてのコード、データおよびコンテンツが含まれる。ＤａｒｔＳｏｕｒｃｅは、ＤａｒｔＴｏｏｌｓ２００が処理して、ＤａｒｔＳｏｕｒｃｅが当初指定したとおりのインタオペラビリティアプリケーションの目的を実行するために必要なすべてをカプセル化したバイナリ実行可能アプリケーションパッケージにする。パッケージのバイナリ画像はＤａｒｔＦｏｒｍａｔ３００に準拠する。カプセル化されたアプリケーションをＤａｒｔｓと呼び、これが１以上のＤａｒｔＤｅｖｉｃｅｓ４００によって実行される。ポーティングされたＤａｒｔＥｎｇｉｎｅ６００を含み、他のＤａｒｔＤｅｖｉｃｅｓと通信するため少なくとも１つの通信プロトコル４０１を有するネイティブなコード実行可能プログラムであるＤａｒｔＰｌａｙｅｒを動かす装置は、それ自体がＤａｒｔＤｅｖｉｃｅで、他のＤａｒｔＤｅｖｉｃｅｓに実行を拡張してその組み合わせたケイパビリティやリソースを利用することのできるＤａｒｔｓを動作可能である。図４は、例示的ＤａｒｔＤｅｖｉｃｅ３０００を示す。上部に、デバイス３０００上で動く３個のＤａｒｔアプリケーション３００１が示される。３個のＤａｒｔのコードは、本発明のＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔに準拠するようＤａｒｔＴｏｏｌｓ（図３、２００参照）によって生成され、その個々のオペレーションは、ＤａｒｔＥｎｇｉｎｅ３０１０のポータブル部分とＤａｒｔＥｎｇｉｎｅのデバイス固有部分、ハードウェア抽象化層（ＨＡＬ）３０２０によってセキュアな方法で実行される。
【００８７】
ＤａｒｔＥｎｇｉｎｅによって実行されるＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔオペレーションは、暗号オペレーション、グラフィックス、テキスト処理等のインタオペラビリティに必要なプロセッサ集約オペレーションを含むことに注意する。さらに、エンジンには、本セクションでさらに詳しく後述する本発明のインタオペラビリティ方法のためのサポートが組み込まれている。ＨＡＬは、ＤａｒｔのＰＲＯＦＩＬＥ＿ＩＮＳＴＲＵＣＴＩＯＮ命令を通じてアクセスされ、デバイスとその機能のデバイス固有の特徴を決定するプロフィール方法を含む。ＨＡＬはまた、存在する場合、エンジンが共通のＤａｒｔ標準ハードウェア機能にアクセスための方法を提供する。おそらく最も進歩的なのは、ＨＡＬの一部を用いて、デバイスのすべてのネイティブなアプリケーション、機能およびリソースを、Ｄａｒｔｓが利用可能で他のデバイスにその実行を拡張することのできるデバイス上で動作するＤａｒｔまたはＤａｒｔの一部に露出することができる点である。
【００８８】
インタオペラビリティの単純性、信頼性、堅牢度は、コード、データおよびコンテンツと、異種デバイスに自身をインテリジェントかつ効率的にスプレッドするため特定のアプリケーション目的に必要なメタコード、データおよびコンテンツをカプセル化することによって部分的に達成される。インタオペラビリティデバイスで動作するアプリケーションコード、データおよびコンテンツはすべて１つのＤａｒｔパッケージから発生するため、独立して生成および配信される構成要素に関連する非互換性や管理問題は何もない。データおよびコードをパッケージ化することにより、データフォーマットとデータ管理のために選択したアプリケーションプログラムとのバージョニングの非互換性から生じる共通のインタオペラビリティ問題も除外できる。
【００８９】
主に、パワフルな汎用コンピュータネットワークのために長年開発されてきた技術の延長である既存インタオペラビリティ技術上の装置のインタオペラビリティの堅牢度、パワー、効率およびセキュリティの強化に貢献する進歩的システム、方法、コンピュータプログラムおよびコンピュータプログラム製品および／または手段は独自に記述して少なくとも２１ある。これら技術革新を以下に簡単に明確にしてから、詳細な説明の後部でより詳細に説明する。発明の別個のシステム、方法、コンピュータプログラム製品およびまたはその他手段の有益な組み合わせをそれぞれ組み合わせた場合、さらに多くのものがある。用いる技術の多くは、特定のタスクを実行するため特別のチームを形成して共同作業するため、人間が採用するソーシャリゼーションを共有している。特別のチームを結成する必要があり、間断的にのみ接続されより特殊目的でモバイルのデバイスが急速に広がる世界では、従来のインタオペラビリティ技術を借りた汎用コンピュータネットワークよりも人間的な協力と共通する点が多い。
【００９０】
リクルートメントインタオペラビリティモデル。リクルートメントは、既存のクライアント／サーバおよびピアツーピアデバイスのインタオペラビリティモデルの有利な代替である。リクルートメントは１つのソフトウェアアプリケーションパッケージまたはＤａｒｔが、デバイスのケイパビリティやコンテンツに基づいてデバイスのチームを結成し、Ｄａｒｔアプリケーションパッケージの意図する目的を実行するため共同作業できるデバイスのチームに自身の一部をインテリジェントにスプレッドするために用いられる。
【００９１】
レンディショニングアダプテーションとインタオペラビリティセグメンテーションモデル。レンディショニングによって、インタオペラビリティアプリケーションを緊密に一体化してはいるが、別個に実行可能な複数のプログラムに細分化することができる。個々のレンディションは、リクルートメントプロセス中に選ばれ、他のデバイスで動作するために送られて、個々のデバイスのケイパビリティおよびコンテンツに調整されたアクセスができるようにする。
【００９２】
ＤａｒｔＳｏｕｒｃｅ／インタオペラビリティソース。ＤａｒｔＳｏｕｒｃｅは、パッケージ化されたＤａｒｔインタオペラビリティアプリケーションに必要なすべてのプログラムレンディションとコードコンテンツおよびデータを指定するための方法である。ＤａｒｔＳｏｕｒｃｅは、特定のデバイス対象の１つの実行可能プログラムの指定に共通して用いられる言語構造を、デバイスのチームのインテリジェントなリクルートメントに必要な手順と、指定されているアプリケーションの目的の内、そのデバイスの部分を実行するためリクルートされた各デバイスで動作するよう送るのに適したレンディションがあるよう、必要なレンディションとも指定することができる言語に拡張する。
【００９３】
ＤａｒｔＦｒａｍｅｗｏｒｋ／インタオペラビリティフレームワーク。ＤａｒｔＦｒａｍｅｗｏｒｋは、プログラマがインタオペラビリティアプリケーションを構築する際に利用するもので、ＤａｒｔＰｌａｔｆｏｒｍの有利な機能の多くへのアクセスをカプセル化し、プログラマがＤａｒｔＰｌａｔｆｏｒｍの所望のインタオペラビリティ機能の多くを理解してインプリメントする必要がないようにする。
【００９４】
ＤａｒｔＴｏｏｌｓ／インタオペラビリティツール。ＤａｒｔＴｏｏｌは、ＤａｒｔＳｏｕｒｃｅアプリケーション仕様をＤａｒｔアプリケーションパッケージに処理する。
【００９５】
ＤａｒｔＦｏｒｍａｔ／インタオペラビリティフォーマット。ＤａｒｔＦｏｒｍａｔは、インタオペラビリティアプリケーションに必要なすべてのコード、データおよびコンテンツをカプセル化したＤａｒｔパッケージをまとめて、動作中のＤａｒｔＰｌａｙｅｒを含むＤａｒｔＤｅｖｉｃｅにロードし、動作できるようにするためのルールである。
【００９６】
ＤａｒｔＲｕｎｔｉｍｅ／インタオペラビリティランタイム。ＤａｒｔＲｕｎｔｉｍｅは、処理ユニットが１つのデバイスで動いているか、リクルートされたデバイスのチーム全体で動いているかに関わらず、動作中のＤａｒｔの別個処理ユニット間のコントロール、データ、オペレーションの緊密な調整を確立するためのシステムである。これは、アプリケーションの全処理ユニットを通じて流れるイベントの直列化と同期を確保するイベント駆動型システムによって実行され、すべての処理ユニットが、処理ユニット間でデータとオペレーションを調整および同期させるために必要なすべての指令に同じ順序でアクセスできるようにする。
【００９７】
リニアタスキング。リニアタスキングは、大半のデバイスで広く用いられる従来のプリエンプティブで協調的なスレッディングモデルの代替として有利で、同時に実行されているかのように複数のオペレーションを指定できる。リニアタスキングによって、非常に決定的で容易に試験された方法で活動を調整するための単純で信頼性が高く、柔軟で広範囲な処理ユニットのための方法が得られる。リニアタスキングは、単一デバイス内部で動作するＤａｒｔＲｕｎｔｉｍｅの一部である。
【００９８】
バーチカルレイヤリング。バーチカルレイヤリングは、プロトコルの全ての中間レベルを通じて通信するため異なるレベルのプロトコルを必要とし、各プロトコルインターフェースの様々なニーズに合わせて情報を変換する必要があるデバイスの大半で広く用いられるプロトコルのホリゾンタルレイヤリングの代替として有利である。Ｄａｒｔ処理ユニットはバーチカルレイヤリングを用い、レベルに関わらず、処理ユニットが、変換なしに全処理ユニットによってアクセス可能かつ理解可能なイベント構造およびイベント待ち行列を利用して他の全ての処理ユニットと直接通信できるようにする。
【００９９】
アプリケーション駆動型パワーマネージメント。リニアタスキングおよび／またはバーチカルレイヤリングを用いて、ＤａｒｔＦｒａｍｅｗｏｒｋに少なくとも部分的に埋め込んで構築したＤａｒｔアプリケーションは、プロセッサのスローダウン等の効率的なパワーマネージメント技術によってバッテリの寿命を延ばし、消費エネルギー量を制限し、またはデバイスに生成される熱量を制限できるよう正確な応答時間ニーズの記録を常に取っている。現在の技術では、大半のアプリケーションは応答時間ニーズの追跡を取っておらず、もし取ると、アプリケーションからデバイスのハードウェアへ応答時間ニーズを通信するインターフェースを含まない仕様に合わせている既存プロトコル層を通じてこれらニーズを通信することができない。
【０１００】
インタオペラビリティアプリケーション駆動型エラー復元。デバイス対デバイスの無線通信接続は、干渉や距離制限、バッテリ電力低下により急激なシャットダウンのためしばしば信頼性が低くなる。従来のデバイス上の水平レイヤプロトコルソフトウェアインプリメンテーションでは、たった１つの層の致命的エラーも、アプリケーションを復元させることが困難な回復不可能なエラーにつながることになるが、これは、アプリケーションが接続や接続のコンテキストを容易に再確立するための標準インターフェースを持たず、従来のアプリケーションプログラムは、異なるデバイス間で動作するアプリケーション間で共有状態を追跡および再確立するための多くのインフラを持たないためである。ＤａｒｔＦｒａｍｅｗｏｒｋは、共有状態を追跡し、レンディショニングを用いてデバイス間の失われた状態を容易に再確立でき、バーチカルレイヤリングは通信エラーをＤａｒｔに中継し、Ｄａｒｔが復元情報を直接、通信処理ユニットに中継することを容易にしている。そのため、デバイス間で動くＤａｒｔは、協働デバイス間で通信の間断的な完全なロスからシームレスに復元可能で、以前に失われたデバイスがアプリケーション状態を全て失っていたとしても、接続が復元された時、デバイスの共有状態を復元することができる。
【０１０１】
インタオペラビリティ命令セット。インタオペラビリティ命令セットを用いて、Ｄａｒｔのコード部分を表す。ＤａｒｔＥｎｇｉｎｅはこれらの命令を実行する。従来のプロセッサのフェッチ、保存、試験、コンピュテーション、ブランチング命令に加えて、インタオペラビリティ命令セットは、オペレーション速度強化の命令を含み、インタオペラビリティ方法を実行し、互いにデバイスのケイパビリティとコンテンツをさらす。特筆すべきは、他のデバイスが独自のケイパビリティやコンテンツを前もって知らない場合でも、他のデバイスに対するあるデバイス独自のケイパビリティおよびコンテンツの露出と利用の命令がある点である。
【０１０２】
クリエイショニズム。クリエイショニズムとは、特定の対象デバイスおよび／または通信セッションおよび／または目的のために高度にカスタマイズされたＤａｒｔをダイナミックに生成するためにＤａｒｔを用いる方法である。Ｄａｒｔ命令セットの命令は、動作中のＤａｒｔ自身の一部からのＤａｒｔと、動作中のＤａｒｔが収集または計算することが可能なあらゆる情報のプログラム的生成のために存在する。
【０１０３】
インタオペラビリティエンジン／ＤａｒｔＥｎｇｉｎｅ。ＤａｒｔＥｎｇｉｎｅは、デバイス上のＤａｒｔの命令を実行し、その意図する目的を果たすために用いられるソフトウェアおよび／またはハードウェアである。ＤａｒｔＥｎｇｉｎｅおよび中にカプセル化されたデバイス固有のＤａｒｔＰｌａｙｅｒは、共通の実行およびＤａｒｔＲｕｎｔｉｍｅ環境を与え、リクルートメントとレンディションが効率的なデバイスチームを確立し、Ｄａｒｔの目的を実行するために最良のコード、データ、コンテンツをスプレッドできるようにする。
【０１０４】
インタオペラビリティデバイスイネーブリング。インタオペラビリティデバイスイネーブリングは、ＤａｒｔＰｌａｙｅｒの一部としてＤａｒｔＥｎｇｉｎｅのポーティングを通じて、従来のデバイスを高度に相互運用可能なＤａｒｔデバイスに変えるプロセスである。さらに、デバイスのデバイス固有情報、ケイパビリティ、コンテンツにアクセスするために必要なハードウェア抽象化層のインプリメンテーションも必要である。ＤａｒｔＰｌａｙｅｒのあるデバイスをＤａｒｔデバイスにするには、少なくとも１つの通信プロトコルをインプリメントしなければならない。
【０１０５】
インタオペラビリティセキュリティモデル／ＤａｒｔＳｅｃｕｒｉｔｙ。ＤａｒｔＳｅｃｕｒｉｔｙは、デバイスとそのコンテンツの整合性を悪意または偶発的な損傷から守るために必要なインフラを与えるシステムである。
【０１０６】
ソーシャル同期インタオペラビリティ方法／Ｄａｒｔソーシャル同期。ソーシャル同期は、どのデバイスもマスタデバイスに接触することなく、またどのデバイスもマスタとして動作する必要なしに、あらゆる数のデバイスおよびプロトコルを通じてデータおよび／またはオペレーションの特定のセットを同期させるための効率的かつ管理容易な方法である。デバイスとコンテンツのソーシャル同期は、人間が情報とタスクを共有する方法に似ており、現在本分野で広く用いられるマスタ方式の同期技術に対する有利な代替である。
【０１０７】
ソーシャルセキュリティインタオペラビリティモデル／Ｄａｒｔソーシャルセキュリティ。ソーシャルセキュリティは、考えられる間断的接続デバイスのチーム間でセキュリティのウェブを形成するために特に管理の簡単な方法である。ソーシャルセキュリティは、人間が他の人間を信頼するようになる方法と似ている。ソーシャルセキュリティの基礎は、ＤａｒｔＳｅｃｕｒｉｔｙシステムと、デバイスからデバイスへ推移的に移動する許可されるアクセス権利を用いて生成した独自のＩＤを広げるため、ソーシャル同期を用いることである。直接通信したことのないデバイスしばしば、さらなる許可を必要とすることなく、一定のアクセス権利で相互運用を許されたデバイスチームの一部であることを発見する。
【０１０８】
インタオペラビリティデバイス／ＤａｒｔＤｅｖｉｃｅ。ＤａｒｔＤｅｖｉｃｅは、ＤａｒｔＥｎｇｉｎｅと、他のＤａｒｔＤｅｖｉｃｅと接続するための少なくとも１つの通信プロトコルを含むＤａｒｔＰｌａｙｅｒにより高度に相互運用可能なデバイスである。
【０１０９】
インタオペラビリティプラットフォーム／ＤａｒｔＰｌａｔｆｏｒｍ。ＤａｒｔＰｌａｔｆｏｒｍは、ＤａｒｔＤｅｖｉｃｅの指定、生成、インテリジェントチーム結成を実行し、１以上のＤａｒｔＤｅｖｉｃｅ間のＤａｒｔインタオペラビリティアプリケーションのスプレッドと動作を容易にすることができるＤａｒｔ方法セットである。
【０１１０】
バーチャルポインタ。バーチャルポインタは、１つのプログラムで１以上の独立したデータアドレス空間にアクセスし、これを利用するための単純かつ効率的な方法をプログラマに与えるための方法である。ソフトウェアプログラムで用いるバーチャルポインタによって、メインメモリや記憶装置を、高速でもメインメモリが小さかったり、大きくても記憶装置が遅かったりするサイズや速度の異なるデバイスでも効率的に動作するよう適合することができる。
【０１１１】
実施例の詳細な説明は、以下の添付の図面と共に読まなければならない。
【発明を実施するための最良の形態】
【０１１２】
１．概要と序論
１つの態様では、本発明は、類似、およびさらに重要なことには、多様で非類似のデバイスおよびシステムの間で、デバイスがコンテンツ、コントロール、リソースおよびアプリケーションを効率的に共有するための方法およびシステムに関する。本発明の態様は、「ＤａｒｔＰａｒｔｆｏｒｍ」として具現化される。この名称、「Ｄａｒｔ」は、アプリケーション、データおよび／または処理、手順、データ、意図その他最も広い範囲での情報のハイブリッドな形式をＡＲＴであるＤａｔａに組み合わせたこと、Ｄａｒｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅｓおよびＤａｒｔＰａｒｔｓの形式の手順、コンテンツ、データの完全にインテリジェントなパッケージが、デバイス間を文字通り移動（または通信）し、デバイス、デバイスリソースおよびデバイスケイパビリティの多様なセットを跨り、高度な単純性、効率、堅牢度、セキュリティ、インタオペラビリティを達成する方法を意味する。
【０１１３】
さらに、本書の説明では、Ｄａｒｔという用語は本発明の特定の実施例で、インタオペラビリティという用語は、Ｄａｒｔがインタオペラビリティの特定の形式である請求の発明の態様に関する全体的な用語であることを意味し、またはこれを指すことが理解される。
【０１１４】
本発明は、これまで文献に記載されたことのない新しいパラダイムを確立する多くの新技術システム、デバイス、方法およびコンピュータアーキテクチャおよびプログラム的特徴を導入する。少なくとも一部分において技術およびコンピュータ用語は、従来の要素に対して発明の要素を完全に識別する簡潔な用語をまだ持たないためもあり、本説明ではしばしば、Ｄａｒｔ手順、Ｄａｒｔパーツ等のフレーズで用いるように、他の用語に「Ｄａｒｔ」またはその他「Ｄａｒｔ何某」と接頭辞や修飾語としての用語を頻繁に用いる。ＤａｒｔＰｒｏｃｅｄｕｒｅ、ＤａｒｔＰａｒｔ、ＤａｒｔＤｅｖｉｃｅなどのように、２つの用語を連結する場合もある。さらに、デバイス、パーツ、手順等のさらにコンパクトな形式を用いて本発明の態様を記述する場合があることも理解される。意図する意味は常に説明の文脈から明らかでなければならないが、「ＤａｒｔＰｒｏｃｅｄｕｒｅｓ」のように大文字で始まる１つの単語形式は、本発明の態様を記述する場合は、「Ｄａｒｔ  Ｐｒｏｃｅｄｕｒｅ」、「Ｄａｒｔ  ｐｒｏｃｅｄｕｒｅｓ」または「ｐｒｏｃｅｄｕｒｅｓ」などの複数の単語形式と等しいと理解されなければならない。これは、Ｄａｒｔ  Ｐａｒｔｓ、Ｄａｒｔ  Ｐｌａｙｅｒ、Ｄａｒｔ  Ｐｌａｔｆｏｒｍなどのほかの「Ｄａｒｔ何某」にも当てはまる。
【０１１５】
最も一般的な形式のＤａｒｔｓは、単なるデータや、単なる手順またはプログラム、単なるコンテンツではなく、Ｄａｒｔｓはあらゆるものであり、全ての要素の組み合わせでもあり得る。「Ｄａｒｔｓ」は、ソフトウェア、コード、データおよび／またはコンテンツの特別な一体型デジタルバイナリパッケージとインタオペラビリティアプリケーションの趣旨を実行するデバイス間でそれ自体またはその一部をインテリジェントにアセンブリング、セーブおよび分布するために用いることのできるコード、データおよびコンテンツと考えられる。本発明により、同種および異種のデバイス両方の間で、単純、効率的、高信頼性およびセキュアなインタオペラビリティが生じる。
【０１１６】
残念ながら、コンピューティングおよび情報システムおよびデバイスの現代のパラダイムは、オペレーティングシステム（ＯＳ）コンポーネント、デバイスドライバ、コンピュータプログラム、アプリケーションプログラム、ユーザその他データコンポーネントを分離および配信する共通慣行に固定化されているため、コンピュータサイエンス業界で広く用いられる用語の一部は、厳密には本発明の要素に当てはまらない。そのため、正確でなくても意味が適切である時には、出来る限り、共通のコンピューティングおよびコンピュータサイエンス用語を用い、「Ｄａｒｔ」表現および用語は、多くの修飾語を持つ一般的言語の利用を避けるためより具体的意味を意図する時に適用する。
【０１１７】
本発明の実施例のコンポーネント、特徴、利点をまず説明し、読者をＤａｒｔ  Ｐｌａｔｆｏｒｍ、システム、方法およびコンピュータプログラム要素に導く。これらおよび他のコンポーネント、特徴および要素については、詳細な説明の後半でさらに説明する。本発明の各実施例による全てのコンポーネント、特徴または利点の全てを限られたパラグラフに簡単に一覧することはできないため、以下の説明は、オプションだが有利なコンポーネントおよび特徴を含む一部実施例のコンポーネント、要素および利点の例示であり、限定的説明と理解してはならない。本発明の実施例は本書に記載する特徴の一部または多くを提供および利用したり、提供または利用しないことがあり、他の実施例が本書記載の特徴やコンポーネントの全てでないにしても多くまたは大半を提供および利用することが理解される。
【０１１８】
オペレーティングシステム、プログラムフォーマット、プログラミングツールおよび通信プロトコルに関する既存の方法は、充分で信頼性の高い電源および信頼性の高い、高速、常時接続の通信プロトコルにアクセスするよりパワフルな汎用コンピュータの世界のために主に開発されたものである。さらに、コンピュータのネットワークは比較的静的で、共同作業のために構成または再構成する必要はほとんどなかった。また、コンピュータ、ネットワーク、オペレーティングシステムおよびプログラムのインストール、構成、再構成、アップデート、修理その他維持には知識のある多くの人間管理者がいると想定されていた。
【０１１９】
これら既存の方法は、バッテリで動作することが多く、コンピューティングリソースが限られていて、低速の信頼性の低い無線または電線プロトコルで通信し、他のデバイスとコンスタントに共同作業するため、ダイナミックに再構成する必要があり、その多くはポータブルで間断的にしか接続されない特殊目的デバイスが急速に発達している現代で広く適用するには向かない。相互作業しなければならないデバイスとそのケイパビリティの、よりダイナミックな構成ニーズや多様性にもかかわらず、これらデバイスと関連するソフトウェアは、システム管理者ほど知識のない人間が利用およびメンテナンスすることが強く望まれている。
【０１２０】
ＤａｒｔＰｌａｔｆｏｒｍは、急速に発展する特殊目的の通信デバイスの世界の特徴と機能に特に合わせて設計されたソフトウェアと、オプションでハードウェア、エコシステムの進歩的な方法およびコンポーネントのセットを含む。
【０１２１】
本発明の実施例によると、発明のＤａｒｔ  Ｐｌａｔｆｏｒｍ（ＤＰ）は、次のコンポーネントを含むことが有利である。
１．ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ：インタオペラビリティ命令セット
２．ＤａｒｔＥｎｇｉｎｅ：ポータブルインタオペラビリティエンジン
３．ＤａｒｔＦｏｒｍａｔ：ＤａｒｔＥｎｇｉｎｅと、（通常はビットファイルまたはビットイメージ等のデジタルバイナリのセット）ＤａｒｔＦｏｒｍａｔ情報をＤａｒｔＥｎｇｉｎｅで処理するためデバイスに送るメカニズムを両方含むあらゆるデバイスまたはサブシステムにおいて最適に（または最適に近く）、データ、コンテンツ、コード、手順その他情報を動作、保存、最適化、コピーおよび／または共有するために必要なデータ、コンテンツ、コード、手順、構文その他情報の考えられる組み合わせをカプセル化するファイルまたはビットマップフォーマット。
４．Ｄａｒｔｏｏｌｓ：ＤａｒｔＦｏｒｍａｔのビットイメージおよびファイルを作成するためのソフトウェアツールのセット。Ｄａｒｔ  Ｔｏｏｌｓは、ＤａｒｔＣｏｍｐｉｌｅｒ、ＤａｒｔＬｉｎｋｅｒ、ＤａｒｔＭａｓｔｅｒＰｌａｙｅｒその他ツールを含むが、それぞれについては以下に詳述する。
５．ＤａｒｔまたはＤａｒｔｓ：ＤａｒｔＦｏｒｍａｔファイルまたはビットイメージフォーマットに準拠するＤａｒｔＥｎｇｉｎｅを含むデバイスによって処理するため、Ｄａｒｔｏｏｌｓによって作成したビット、ビットイメージおよび／またはインスタンスのパッケージ。ＤａｒｔＦｏｒｍａｔは、ＤａｒｔＥｎｇｉｎｅと、ＤａｒｔＥｎｇｉｎｅで処理するためＤａｒｔＦｏｒｍａｔビットイメージを送るメカニズムの両方を含むあらゆるデバイスまたはデバイスのセットにおいて最適に、データ／コンテンツ／コードを動作、保存、最適化、コピーおよび／または共有するために必要なデータ／コンテンツ／コードおよび構文の組み合わせをカプセル化する。Ｄａｒｔｓは、Ｄａｒｔの複数形である。
６．ＤａｒｔＰｒｏｃｅｄｕｒｅ（ｓ）：Ｄａｒｔ命令セットと、命令が動作するデータ画像およびデータ画像値との組み合わせからの命令シーケンスからなる内蔵型軽量手順およびデータ。
７．ＤａｒｔＰｌａｙｅｒ：Ｄａｒｔｓを処理するためＤａｒｔＥｎｇｉｎｅを採用するデバイスの特定のサブセットで動作するよう設計されたソフトウェアプログラム。
８．ＤａｒｔＭａｓｔｅｒ：ＤａｒｔＭａｓｔｅｒＰｌａｙｅｒと呼ばれる特殊なＤａｒｔｏｏｌでＤａｒｔＭａｓｔｅｒを処理することにより、１以上の効率的および／または特化されたＤａｒｔｓまたはＤａｒｔにさらに最適化されるＤａｒｔ。
９．ＤａｒｔＦｒａｍｅｗｏｒｋまたはＤａｒｔＯｂｊｅｃｔＦｒａｍｅｗｏｒｋ：Ｄａｒｔｓ構築に用いるベースクラスのセットについてデータおよび方法を定義するソースコードのセット。ＤａｒｔＯｂｊｅｃｔＦｒａｍｅｗｏｒｋは、初期実行ポイント、初期オブジェクトデータポインタ、コードとデータと入力データおよびコードを処理する順序を制御する構造および構文のセットを想定する。これは、ＤａｒｔＲｕｎｔｉｍｅのデバイス内ランタイム部分を具現化し、デバイス内ランタイムをデバイス間ランタイムに拡張して、あらゆる数のチームにしたデバイス間でランタイム活動を同期および直列化する。
１０．ＤａｒｔＲｕｎｔｉｍｅ：ＤａｒｔＦｒａｍｅｗｏｒｋまたはＤａｒｔＯｂｊｅｃｔフレームは、当初実行ポイント、当初オブジェクトデータポインタ、コードおよびデータおよび入力データおよびコードを処理する順序を制御する構造および構文のセットを有利に想定する。これは、「ＤａｒｔＲｕｎｔｉｍｅ」のデバイス内部分とも呼ばれる。チームにしたデバイス間の活動とデータ交換の同期と調整を制御するイベント構造インスタンスが、イベント待ち行列の間で自動的に直列化および同期され、その１つは各デバイスのＤａｒｔＥｎｇｉｎｅによって維持されることを想定するデバイス間ランタイムでもある。デバイス内ＤａｒｔＲｕｎｔｉｍｅおよびデバイス間ランタイムは共に、Ｄａｒｔの異なるレンディションがチームにしたデバイスのセットのそれぞれで動作することが考えられる場合、Ｄａｒｔの目的を実行するため使いやすいが高度に堅牢で効果的なシステムを提供する。
【０１２２】
他の態様の中でも、本発明は、あらゆるタイプのデバイス間のインタオペラビリティを改善し、間断的に相互接続されるか、常に相互接続されるデバイス、システムまたはサブシステム間の限定のないインタオペラビリティにおける次のような問題その他を解決するよう設計されている。
１．非類似または異種デバイス間でコンテンツ、アプリケーションおよびコントロールを移動する際のディスプレイ、コントロール、コード、データおよい機能のアダプテーションおよび最適化。
２．デバイスユーザの希望が、プログラムやファイルおよび／またはコンテンツに関わらず、動作する（および出来る限り動作する）コンテンツである場合、プログラム、コンテンツフォーマット、ドライバおよび／またはファイルについてユーザが考えなければならない必要性を取り除く。
３．ユーザが、１または複数のデバイス間で用いるデバイス接続または通信の種類を指定するか、知っていなければならないという必要性を取り除く。
４．使用可能にされた全てのデバイス間でコンテンツ、コントロールおよび／またはリソースの単純で効率的な共有を可能にする。
５．高価で複雑なコンピュータ支援技術（ＣＡＴ）スキャナから（薄型プロセッサ／メモリ）ライトスイッチその他単純なデバイスまで、あらゆるデバイスまたはシステムを、接続されたほかのデバイスに対し利用可能にし、機能、リソース、ケイパビリティおよびニーズを文書化およびアクセスを許可できるようにする。
６．従来の非手順的アプローチを用いて必要な圧倒的な開発努力を、劇的に少ない数の開発プロジェクトおよびコストで容易に達成可能な上記可能な全てまたは一部のレベルまで引き下げる。
７．（コードサイズ、実行ロジックおよびメモリの点で）ローエンドのコストを抑えた、および／またはパワーの制約のあるデバイスに適した軽量とする。
８．特に、次の１つまたは組み合わせのため緊密に絡み合った本来のサポートを含むことで意味を成すようなあらゆる方法により、あらゆる数のＤａｒｔＤｅｖｉｃｅｓが全てのＤａｒｔＤｅｖｉｃｅｓとシームレスに相互運用できるようにする：
（ａ）デバイスハードウェアがサポートできる限り、ダイナミックなマルチメディア豊富インターフェースと、デバイスハードウェアがサポートしない場合は、階層が少ないインターフェース；
（ｂ）デバイスのパワーマネージメント；
（ｃ）デバイスの発見；
（ｄ）サービスの発見；
（ｅ）リソースの発見；
（ｆ）Ｄａｒｔアプリケーションを、各種通信の物理およびプロトコル層の詳細を知る必要性から隔離；
（ｇ）Ｄａｒｔアプリケーションを、物理的表示形式について詳細を知る必要性から隔離；
（ｈ）Ｄａｒｔアプリケーションを、複数の類似または非類似デバイス間で動くアプリケーションとの同期の維持について詳細を知る必要性から隔離；
（ｉ）コントロールパネルを取り出したデバイスでローカルに動作するが、実際にはこれを制御するよう最適化されたコントロールパネルの再待ち行列、取り出しおよび動作；
（ｊ）１以上の親Ｄａｒｔｓのデバイス内ＤａｒｔＲｕｎｔｉｍｅ環境の子Ｄａｒｔ拡張として、別個に生産したＤａｒｔコンテンツのローディング、動作および最適化。
９．発信デバイスでＤａｒｔに具現化されているインタオペラビリティアプリケーションを開始するデバイス（開始デバイス）以外のデバイスのいずれかにプログラム、データまたはコンテンツを予め存在させる必要性を取り除く。
１０．どのデバイスもマスタにもスレーブにもなる必要なく、デバイスのケイパビリティおよび限界の全てあるいは一部サブセットに基づき、デバイスがそのリソースを効率的に共有できるようにする。
１１．接続されたデバイスがアプリケーションを利用して、さらに発信または開始デバイスが接続されなくなった後も、無限に他のデバイスにスプレッドしているような方法で、アプリケーションのコード、データ、コンテンツおよびそのハイブリッド（Ｄａｒｔｓに埋め込まれる）が、接続されたデバイスに自身をダイナミックにスプレッドできるようにする。
１２．単一パッケージ（またはパッケージのセット）のインタオペラビリティアプリケーションのコード、データおよびコンテンツ全てをカプセル化して、その後、必要に応じて他のデバイス間にスプレッドすることでマルチデバイスオペレーションを改良し、各デバイスに別個に作成および／または配信しなければならなかった別個に作成および配信したアプリケーションまたはプロトコルソフトウェアのインプリメンテーション、コード、データまたはコンテンツを混合および一致させることに関連する問題を取り除く。
１３．上記全てを、単純で信頼性の高い安全な方法で実現する。
【０１２３】
図８を参照すると、写真のソースとして用いるネットワーク接続ストレージデバイスと、写真印刷を実行する目的地として動作する印刷デバイスをリクルートした携帯電話上で動作するＰｒｉｎｔＰｉｃｔｕｒｅ  Ｄａｒｔの例が示される。デバイスは全て、各デバイスにポーティングされたＤａｒｔＰｌａｙｅｒを含むものと想定する。
【０１２４】
携帯電話上のＤａｒｔは、３つのレンディション（Ｒ１、Ｒ２およびＲ３）を含み、それぞれがＤａｒｔＰｌａｙｅｒ上で動作する時、個々に実行可能な画像として機能することができる。レンディションＲ３は携帯電話上で動作し、その前に、ＤａｒｔＰｒｏｃｅｄｕｒｅｓを送信して候補デバイス上で実行して他の２つのデバイスのリクルートメントを実行しており、特定のネットワーク接続ストレージデバイスが写真のベストソースとして機能することと、プリンタデバイスが写真印刷を目的として最良に機能することを決定している。
【０１２５】
携帯電話上のレンディションＲ３は、ネットワーク接続ストレージ（ＮＡＳ）デバイスから写真を特定し取り出すため、イベント処理コードを含むレンディションＲ１のみ含むＤａｒｔについて画像を生成する。そして、レンディションＲ１を含むＤａｒｔが、ＲＵＮ＿ＤＡＲＴタイプイベントの一部としてネットワーク接続ストレージデバイスに送られる。ＲＵＮ＿ＤＡＲＴタイプイベントがＮＡＳデバイス上のＤａｒｔＥｎｇｉｎｅによって処理されると、レンディションＲ１がロードされ、実行を開始して、ＮＡＳデバイスに情報または写真の保存を要求するあらゆる同期イベントを処理する。同様に、ＰＲＩＮＴ＿ＰＩＣＴＵＲＥタイプイベントの一部である写真印刷を扱うレンディションＲ２が形成され、選択したプリンタデバイスで動作するため送られる。
【０１２６】
３つのレンディションはすべて、最初は携帯電話上にのみ常駐していた同じＰｒｉｎｔＰｉｃｔｕｒｅ  Ｄａｒｔから生成されたことに注意する。これにより、アプリケーションは実際には、従来のインタオペラビリティ方法に必要な独立してインプリメント、ポーティングおよび配信されたコンポーネントではなく、自身のパーツに話しかけるため、高度な互換性を確保する。
【０１２７】
レンディションはまたコード、データおよび／またはコンテンツを共有し、ＰｒｉｎｔＤａｒｔアプリケーション固有のイベントタイプの相互関連セットを理解することにさらに注意する。Ｒ３レンディションは、他の２つのＤａｒｔＤｅｖｉｃｅｓを以前知らず、デバイスは携帯電話またはＰｒｉｎｔＤａｒｔについて以前知らなくとも、ＤａｒＤｅｖｉｃｅｓにＰｒｉｎｔＰｉｃｔｕｒｅ  Ｄａｒｔの一部をインテリジェントにスプレッドすることができる。
【０１２８】
携帯電話上で動作するレンディションＲ３はイベントをシグナリングし、リクルートしたＮＡＳおよびプリンタデバイスの間で、３個のデバイス上で確立されたイベント駆動型ＤａｒｔＲｕｎｔｉｍｅを通じて選択と写真印刷を制御することができる。
【０１２９】
さらに、プロトコルの組み合わせを、携帯電話とＮＡＳデバイスの共通プロトコルに従って採用し、リクルートしたプリンタデバイスの共通プロトコルに用いるため独立して選択できることにさらに注意する。また、全てのデバイスはＤａｒｔＰｌａｙｅｒの一部としてポーティングされたＤａｒｔＥｎｇｉｎｅを含むため、デバイスは、異なるプロセッサの異なるオペレーティングシステムで動作している場合でも相互運用することができる。
【０１３０】
本発明は、緊密に結ばれた複雑な相関関係を有する多数の要素を持つシステムを含むため、ある要素がなぜ存在するか、その要素がどう動いて、他の要素とどうインタラクトするかについて理解できるよう、要素の一部の概要をまず説明する。そして、各要素について他の要素とのインタラクションをさらに詳細に説明する。本発明で具現化するインタオペラビリティで当業の現状を劇的に改善するため、データパッシングから、現在広く用いられているオブジェクト指向方法への動きに似た非常に新しいタイプのソフトウェアエコシステムの作成が必要であった。発明のシステム、データおよびコード構造をより簡単に説明するため、まず、本発明の実施例の理論、概念、特徴およびコンポーネントを説明する新しい用語を紹介することが有益である。
【０１３１】
一実施例では、本発明は次の９つのイネーブリング方法を具現化するが、その一部はオプションだが、リクルートメント、インタオペラビリティ、命令セット、レンディショニング、クリエイショニズム、バーチカルレイヤリング、リニアタスキング、ソーシャル同期、ソーシャルセキュリティ、バーチャルポインタを含むと有利である。
【０１３２】
デバイス「リクルートメント」は、デバイスインタラクションモデルと関連する構造および方法を含み、既存のクライアント／サーバおよびピアツーピアモデルの有利な代替である。「インタオペラビリティ命令セット」は、ポータブルベースの命令セットで、デバイス間に共通の効率的実行可能環境を与え、あるデバイス独自のケイパビリティを他のデバイスに露出するための独走的プログラマチックメカニズムを提供する。「レンディショニング」とは、アプリケーション、データ、コンテンツおよび／またはその他情報の容易な試験と効率的なアダプテーションを可能にするための構造および方法を指す。一部の態様では、レンディショニングはコード、データ、コンテンツのグループを独立した実行可能画像に効率的にセグメント化し、複数のデバイス間で「レンディション」をインテリジェントに生成および配信することを含む。「クリエイショニズム」とは、接続されたデバイスおよび間断的接続デバイス間で異なる形式のアプリケーション、データ、コンテンツおよび／または情報のダイナミックで効率的な生成および配信を可能にする構造および方法を指す。「バーチカルレイヤリング」では、ツール、アプリケーション、フレームワーク、エンジンおよび命令セットレベルで本来、緊密に協力する特徴を効率的かつ効果的にインプリメンテーションできるようにする。「リニアタスキング」は、デバイスの処理ユニット間でプロセッサのコントロールおよびデバイスリソースの単純で決定的なフローを可能にし、処理ユニットを、Ｄａｒｔや、別個にコンパイルしたＤａｒｔｓ、他のデバイスで動作するＤａｒｔｓやレンディションにコンパイルした処理ユニットを含む１つの階層に容易に再構成できるようにする。「ソーシャル同期」とは、ユーザが最小、あるいはまったく関わらずに、あらゆる数のデバイス間でデータやコンテンツを同期させるための効率的なシステムおよび方法を指す。「ソーシャルセキュリティ」とは、ユーザが最小の関わりで相互運用するための正しい認証のあるデバイスのグループを容易に確立および維持するための進歩的で効率的なシステムおよび方法を指す。これらおよびその他コンポーネントは、デバイスのプロセッサ内で実行するため実行可能な命令を含むコンピュータプログラムコードセグメントの形式でインプリメントされる。さらに、これらコンポーネントの要素は、ソフトウェアおよび／またはファームウェアおよび／またはマイクロコードを持つハードウェアおよび／またはハードウェアの組み合わせに埋め込まれる。
【０１３３】
任意であるが、有利に設けることのできる別のイネーブリング方法を「バーチャルポインタ」と称し、これは、各種有利な特製を有するバーチャルメモリ上の様々な重要な改良を与え、例えば次を含む：。
（ａ）複数の大型で独立したアドレス空間
（ｂ）リアルなメモリページ数上のアプリケーション固有コントロール
（ｃ）記憶装置パフォーマンス特性に一致する実際のメモリページサイズ上のデバイス固有コントロール
（ｄ）プログラマが、データ構造またはリストに必要なメモリ量を予測または管理する必要がない
（ｅ）ページサイズまたはページ数から独立した形式のデータの自動セービング
（ｆ）貴重で高速なＲＡＭを最小量として、大型で低速のデータ保存からの効率的なデータのキャッシュで、アプリケーションが実際よりはるかに大きなＲＡＭメモリを持つかのように動作することができる
（ｇ）データおよびインデックスが異なるバーチャルポインタアドレス空間に保存されている場合、インデックス化されたデータベースオペレーションのための単純で効率的なベースインフラ。
【０１３４】
本発明の方法、コンポーネント、特徴の多くを概要として述べてきたが、ここで、原則的方法、構造および方法の実施例の詳細な説明に注目する。手順および方法の多くは、マイクロコントローラ、プロセッサ、マイクロプロセッサ、中央演算処理装置（ＣＰＵ）その他処理ハードウェア、あるいはソフトウェア、ファームウェアまたはその２つの組み合わせのいずれかを問わず、コンピュータプログラムコードで実行または動作可能なロジック等の汎用または特殊目的処理ロジックで実行できることに注意する。
【０１３５】
セクションに見出しがある場合、これは単に、読者の注意を、特定の態様または方法を述べた明細書の一部に向けるためのもので、全ての方法および構造の態様は明細書全体および図面と特許請求の範囲に記載し、小見出し部分内の発明の態様を含むことや除外することにより、制限を暗示するものでないことが理解される。
ＩＩ．リクルートメントインタオペラビリティモデル
【０１３６】
「リクルートメント」には、本発明のインプリメンテーションを通じて具現化されるデバイスインタラクションモデルおよび方法が含まれる。これは、現在本分野で用いられるクライアント／サーバおよびピアツーピアのデバイスインタラクションモデルの有利な代替である。リクルートメントモデルおよび方法は、相互運用を予期してリソースを相互運用または検査する全てのデバイスで動作する共通の手順的環境を利用している。本発明の一実施例では、この共通手順的環境は、Ｄａｒｔ命令セット（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ等）または、本書およびその同等物に記載する共通の手順的環境要件を満たす他の名称による命令セット等の命令セットによって提供される。
【０１３７】
図５を参照すると、複数またはチームのデバイスを、全てのデバイスのリソースが組み合わされた１つのデバイスであるかのようにリクルートし、後にそこで効果的に動作するソフトウェアアプリケーションのための方法を提供するリクルートメント手順の一実施例のフローチャート図が示される。図６の共有スライドショー１００００のリクルートメント例と、図７のスライドショー２００００からの１枚以上のスライドの遠隔印刷の例も参照する。デバイスのリクルートメント（あるいは単純に「リクルートメント」）を実行する。リクルートメントは、一団、チームその他複数のデバイスおよび／またはシステムが、全デバイスのリソースを組み合わせた１つのデバイスであるかのようにリクルートし、そこで効果的に動作するソフトウェアアプリケーションのための方法を提供する。
【０１３８】
リソースは、ハードウェア、ソフトウェア、ファームウェア、通信ケイパビリティ、構成、データまたはデータセット、デバイスまたはシステムが所有またはアクセス可能なケイパビリティである。リソースは例えば、プロセッサ、ＣＰＵ、メモリ、連絡先リスト、サウンド出力デバイス、ディスプレイのタイプ、ＤＡＲＴ、図その他手順的、構造的または情報アイテム等である。ケイパビリティは例えば、リスト、ハードウェアまたはソフトウェアをソートしてｍｐｅｇファイルにデコードし、Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイスなどと通信するためのコンピュータコードである。リクルートメント手順は、フレームワーク、プラットフォーム、エンジン等のプログラミングおよびサポートによって、開始デバイスから独立して、手順を送ったアプリケーションの意図やアプリケーションの意図の一部を実行するためリクルート可能またはリクルートしたデバイスの適性について複雑な判断を下すインテリジェンスを有する。
【０１３９】
一実施例では、図６の１００１１および図７の２００１１に示すように、開始デバイスはまず、共通実行可能形式の検査手順の形式のメッセージを、ソースとしての自分自身または開始デバイスから、多数の通信プログラム上で到達可能なあらゆる数のデバイスに送信またはブロードキャストする。開始デバイスはこのメッセージを形成および送信して、必要なリソースまたはケイパビリティを持つ他のデバイスを探し、共通手順的環境で構造化、コード化その他インプリメントされた単数または複数の手順を、これも共通手順的環境を含む他のデバイス（通信時には既知または未知）との単数または複数の接続を通じて送信、伝送、ブロードキャストその他通信する。開始デバイスは、メッセージを送信またはブロードキャストする時は、どのデバイスが到達可能かを知っている必要がある。他のデバイスが到達可能か否かは、例えば、リクルート候補デバイスに考えられるセットに対して開始デバイスが持つ通信チャンネルおよび／またはプロトコルに依存する。
【０１４０】
このソースデバイスは、インタラクションを開始するため（図６の１０１００および図７の２０１００参照）、開始デバイス、リクルートメント手順のソースであるため、ソースデバイス、または自身をリクルートされたデバイス、目的地デバイス、対象デバイスあるいは単に開始デバイス以外のデバイスと呼ぶ他のデバイスをリクルートしようとするデバイスであるため、代替的にリクルータデバイスと呼ばれる。
【０１４１】
開始デバイスが例えばＢｌｕｅｔｏｏｔｈ（登録商標）無線通信リンク、赤外線通信リンク、ＩＥＥＥ８０２．１１（ａ）（ｂ）または（ｇ）通信リンクを含み、これらチャンネルのそれぞれでメッセージをブロードキャストする場合、これら通信リンク上で通信を受信するよう構成されたリクルート可能の候補デバイスのみがリクルートメントメッセージを受信することができる。これらのうち、動作環境を提供し、検査手順の応答を理解して実行することのできるデバイスのみが応答する。これら応答可能デバイスの中でも、他のリクルート可能デバイスのユーザは、例えばセキュリティ設定に応じてこのようなリクルートメントまたは調査検査手順を選択的あるいはグローバルにブロックすることができる。
【０１４２】
第２に、検査手順は次に、応答して発見された各デバイス上でその命令を実行し、アプリケーションまたはアプリケーションの意図の一部を実行するため、そのデバイスの必要なリソースおよびケイパビリティおよび／または相互関連するリソースおよびケイパビリティのセット、またはそのデバイスが利用可能なものを特定する。一実施例では、この検査は、例えばＤａｒｔ命令セットプロフィール命令（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ  ＰＲＯＦＩＬＥ＿ＩＮＳＴＲＵＣＴＩＯＮ等）等の命令セットプロフィールまたはゲットプロフィール命令を用いて実行し、リクルート可能な候補デバイスのハードウェア抽象化層（ＨＡＬ）にアクセスするかコールして、デバイス固有ハードウェア抽象化層（図２７のハードウェア抽象化層ＨＡＬ６５２参照）に保存またはコンピューティングされる特定のデバイスおよびそのリソースとケイパビリティに関する情報にアクセスする。
【０１４３】
第３に、検査手順は、通信チャンネルおよびプロトコル上で開始デバイスに手順、データ、コンテンツその他情報を返し、メッセージを受けたことを示す（図６の１００１２および図７の２００１２参照）。応答デバイスは、受信した通信チャンネルおよびプロトコルの表示と、任意で、リクルートメントメッセージを受信したデバイスのアイデンティティを識別およびセーブするか、開始デバイスによって受信される応答をブロードキャストする。
【０１４４】
ある実施例では、応答デバイスは、特定のリソースまたはリソースセット（カラー印刷ケイパビリティ等）の利用可能性について開始者のクエリに答えるのみだが、他の実施例では、検査手順は特徴、機能、リソースの完全なセットを識別し、これで応答する。通常は、通信のサイズを最小限にするために、単純にイエス、必要なリソースを持っている、が望ましい（応答は、シングルビットまたはバイトまたはワード）。１以上のタイプまたはクラスのリソースまたはリソースサブクラスを識別するコードを用いてもよい。一実施例では、検査手順は、動作したデバイスのリソースおよびケイパビリティに関して、ソースデバイスに情報を返す。この情報は例えば、静的データ構造、手順、Ｄａｒｔ、フリーフォームのタグ付き言語その他情報形式を取ることができる。図６の１００１２のイエス応答と、ＭＩＰＳのプロセッサ速度、および図６のスライドショー例１００００のリクルートされたＤａｒｔデバイス１０２００の優先ディスプレイ解像度、図７のスライド印刷例における図７のリクルートされたＤａｒｔデバイス２０２００のイエス応答と優先プリンタ解像度のリターンの図７の２００１２を参照されたい。
【０１４５】
第４に、開始デバイス上のアプリケーションコードは、応答到達可能デバイス全ての手順、データ、コンテンツその他情報を含む返された情報全てを集め、受信したあらゆる手順を実行し、アプリケーションの意図を実行するために到達可能デバイスとそのリソースをどのように利用するか決定するためそれらを検査する。
【０１４６】
第５に、開始デバイスのアプリケーション固有コードは、第４ステップ（図６の１００２０、１００２１および図７の２００２０、２００２１を参照）の決定に従って必要に応じ、到達可能デバイスのそれぞれにコード、データ、コンテンツその他情報をスプレッドする。アプリケーションコード、データ、コンテンツその他情報は、１つの共通形式で送ることもでき、レンディションおよびクリエイショニズムに関連して説明する方法を用いたり、その他方法および技術に従って本発明の実施例に従ってカスタマイズすることもできる。
【０１４７】
第６に、開始および当初到達可能デバイス間に広がったコード、データ、コンテンツを、到達可能デバイスに常駐するアプリケーションコード、データおよびコンテンツと共に、現在は開始デバイス（二次または後続開始デバイス）として動作している当初到達可能デバイスのセットで、必要に応じて第１から第４のステップを用いてさらに回帰的にスプレッドし、当初のアプリケーションの意図を実行するために必要あるいは望ましい全てのデバイスおよびリソースに到達するまで、必要に応じてアプリケーションを拡張し、デバイスとその関連するリソースの完全なチームを結成することが任意であるが望ましい。必要なリソースを有するデバイスを第１ラウンドで特定した場合、二次または後続ラウンドのリクルートメントは不要であることが理解される。一方、必要であるか望ましいリソースを最初に発見できない場合、二次または後続再帰的リクルートメントラウンドが必要になる。再帰的リクルートメントはまた、第１ラウンドでリクルートされたデバイスを通じて動作する当初開始者が、第２ラウンドでリクルートされたデバイスと通信できるよう（Ｂｌｕｅｔｏｏｔｈ通信を有線ネットワーク接続に変換するよう動作する等）、ブリッジまたはトランスレータとして動作する可能性も高める。
【０１４８】
第７に、開始アプリケーションのニーズに従って、デバイスのチーム間に配信されたコード、データ、コンテンツに、必要なオペレーションおよびリソースアクセスを実行させ、開始アプリケーションの意図を実行するため、コードを実行し、前記デバイスチーム間で実行すべきオペレーションの実行および調整に必要か、あるいは望ましいあらゆるコード、データ、コンテンツその他情報を交換することにより、発信アプリケーションの意図を実行する。
【０１４９】
実行可能コード、データおよびコンテンツを配信させるこのステップは、アプリケーション自身の継続的オペレーションで、このポイントまでプロセスは主に、チームを結成し、アプリケーションの各パートを実行するのに必要なものでチームのメンバーを確立するデータ、コード、コンテンツをスプレッドすることに焦点を当てている。プロセスは、アプリケーションまたはタスクの意図の実行を継続する。スライドショーの例では、スライド（真のデジタル画像またはデータセット）が共同スライドショーに追加されるか、全デバイスで表示されるように、全デバイスでスライドがフリップまたは逐次表示されている。この初期リクルートメント段階を超える相互運用を継続する手順は本書において別に述べる。
【０１５０】
これにより初期リクルートメント段階を完了し、リクルータ（開始者）および被リクルータ（他のチームにされたデバイス）が、図６の１００３１、１００３２、１００３３に示し、本書で別に述べるように、相互運用してリソースを共有できるようにする。
【０１５１】
そして、アプリケーションのデバイス間のオペレーションを、本書に別に述べるようにアプリケーションの処理を駆動し、全ての入力をここから取得するのが有利なイベント８００（図１７参照）を、そのイベントタイプに同期するとマークされた全てのリクルートデバイスとリクルートされたデバイスの待ち行列に入れることにより同期させる。イベントとイベント待ち行列については、図１７関連を含み、本書で詳細に後述する。
【０１５２】
図１７を参照すると、イベント８００は、本実施例を含む図１７の８００に示すフィールド、イベントタイプ８０１、イベントパラメータ８０２、手順８１１、コンテンツ８１２および／またはＤａｒｔ８１３を含むイベント関連ファイル８１０を持つデータ構造インスタンスである。これらイベント８００は、ＤａｒｔＲｕｎｔｉｍｅ８０００（図１５参照）、Ｇｉｚｍｏ階層１００００（図１８参照）または４５１−ｘというラベルのついた回線（図１７参照）に沿ったＤａｒｔＤｅｖｉｃｅｓ４００間でランタイムを流れながら、入力を与え、データおよびセマンティックスを通信し、同期機能を実行する。
【０１５３】
イベント８００は、あらゆる種類または量のデータについてファイル８１０の参照を含む。参照は、オープンファイルに行うのが望ましい。一般に、ファイルは、別のＤａｒｔＤｅｖｉｃｅで動く１以上のＤａｒｔＰｒｏｃｅｄｕｒｅｓ、別のＤａｒｔ  ＤｅｖｉｃｅへＤａｒｔアプリケーションのリーチを拡張する完全なＤａｒｔｓ、別のデバイスへのコントロールパネルを含むＤａｒｔ、図１７の８００に示すようにイベントの他のパラメータに適合しない一般的列挙や入力情報のうち１以上を含む。これらおよび他のＤａｒｔタイプと一般的列挙または入力情報については、本書で別途詳述する。イベント処理についてはさらに、図１５に示すＤａｒｔＲｕｎｔｉｍｅフローチャート８０００および図１６のＥｎｇｉｎｅ  Ｅｖｅｎｔ処理内蔵機能フローチャート５０００に示す。
【０１５４】
イベント８００と関連するファイル８１０は、本発明の一実施例では、イベントを自動的に送る構造的方法的インフラがイベントと共に関連ファイルを送信するため、イベントに関連するファイルをイベントとは別のイベントまたはイベントの望ましい一部とみなす。そのため、少なくとも一実施例では、イベントをイベント受信者のイベント待ち行列に入れる前に、送信側で参照したファイルを通信インフラが受信側ファイルにコピーし、受信側デバイスのコピーされたファイル画像に関連するファイル識別子（フィールド等）を用いて読み取れるようにする。送信および受信デバイスでは、共通あるいは差別化したファイル名またはファイル識別子を用いることができる。動作中のＤａｒｔ（ＲＵＮ＿ＤＡＲＴタイプイベント等）や動作中の手順（ＲＵＮ＿ＰＲＯＣＥＤＵＲＥ等）タイプのイベントの場合、イベントが待ち行列の先頭に来て、待ち行列で次になると、エンジンがＤａｒｔＰｒｏｃｄｅｄｕｒｅまたはＤａｒｔを、実行するイベント中のフィールドを用いて読み取れるようにする。アプリケーションが現在何も動いていなくとも、Ｄａｒｔエンジン自体が処理するイベントあるのが一般的である。一実施例では、イベント待行列の駆動は常に、エンジンに内蔵された動作中のＤａｒｔか非動作中の手順（ＤａｒｔＩｄｌｅＰｒｏｃｅｄｕｒｅ等）で、通信を継続させるため、常にエンジンイベント処理手順をコールしている。これは本質的に、処理するイベントがなくなるまで動作を続けるループである。パワーマネージメント（本書で別途説明）を適用する場合、このループを停止およびその後ウェイクアップまたは再スタートさせる各種技術がインプリメントされる。
【０１５５】
このように、リクルートメントモデル、方法および関連する構造が、特別なデバイス、サービスおよびリソース発見を実行して必要なデバイスを特定し、その後、イベント８００のようなイベントデータ構造を用いてデバイスにイネーブリング手順および情報を送信し、デバイスのチームをインテリジェントかつ効果的に結成してから、さらに、再びイベント８００のイベントデータ構造を用いてデバイスのチームを調整し、Ｄａｒｔ７００の当初の目標またはソースデバイスで当初動作しているアプリケーションを実現しようとする。
【０１５６】
図１０は、リクルートメントによって、接続されたデバイスのグループを１台のデバイスのように動作させる方法を示す。これが持つ最も深遠な影響の１つは、新しいインタオペラビリティデバイスおよびＤａｒｔベースアプリケーションのインプリメンテーションと試験に、デバイス数のＮに比例する手間しか必要なくなることである。従来の静的および手順的アプリケーションでは、相互運用する必要のある全デバイスにコンポーネントをそれぞれインプリメントおよび配信させる必要があり、必要な手間はＮ乗に比例して増える。
【０１５７】
リクルートしたデバイス間のイベントの直列化と同期を含む、リクルートメントおよびリクルートメントインタオペラビリティモデルの他の態様については、例を含み本明細書で別に説明する。リクルートメントインタオペラビリティモデルの特定の実施例についても以下に述べる。
【０１５８】
一実施例（１）では、本発明は、デバイスのチームをリクルートするためソースデバイスで動作するソフトウェアアプリケーションのための方法を提供し、この方法は、必要なリソースまたはケイパビリティを有するデバイスを探すよう動作可能な検査手順を、少なくとも１つの通信リンクを介して少なくとも１つの開始ソースデバイスと異なる到達可能なデバイスに送信することで、検査手順は、開始ソースデバイスと検査手順を到達させようとするデバイスの両方に共通な実行可能な形式でコード化された検査手順命令を含むものと、到達可能なデバイスのそれぞれから、通信リンクを介して直接または間接的に、開始デバイスでリターン応答を受信することと、開始デバイスで実行する手順により、全ての応答到達可能デバイスからの受信リターンを分析し、ソフトウェアアプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイスのケイパビリティおよびリソースの組み合わせを特定する利用プランを決定することと、開始デバイスで実行するアプリケーションプログラムにより、特定された利用プランに従って必要なリソースまたはケイパビリティを有すると特定された到達可能デバイスのそれぞれの少なくとも１つに実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを配信することとを含む。
【０１５９】
別の実施例（２）では、本発明は、デバイスのチームをリクルートする方法を提供し、その方法は、候補デバイスで受信し、受信到達可能候補デバイスが別のリクルートデバイスの必要とするリソースまたはケイパビリティを有するか否かを通信リンクを介して判断するよう動作可能な検査手順を実行することで、検査手順は、受信デバイスとリクルートデバイスの両方に既知の実行可能形式でコード化された検査手順命令を含むものと、受信した検査手順についてソースデバイスを特定し、受信到達可能デバイスが、開始ソースデバイスが必要としていると特定されたリソースまたはケイパビリティまたはリソースおよびケイパビリティのセットにアクセス可能か否かに関するステータスおよび情報をソースデバイスにリターンを送信することと、到達可能デバイスが、ソフトウェアアプリケーションの意図を実行するためチームを結成するのに必要なリソースまたはケイパビリティを有するとソースデバイスによって判断された場合、実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを、ソースデバイス、リクルートデバイスまたは別の候補デバイスから受信することとを含む。
【０１６０】
別の実施例（３）では、本発明は、デバイスのチームをリクルートするための方法を提供し、この方法は、（ａ）開始ソースデバイスから、少なくとも１つの通信リンクを介して、開始ソースデバイスと異なる少なくとも１つの到達可能デバイスに必要なリソースまたはケイパビリティを有するデバイスを見つけるよう動作可能な検査手順を送信することで、検査手順は、開始ソースデバイスと、検査手順を到達させようとするデバイスの両方に共通する実行可能形式でコード化された検査手順命令を含むものと、（ｂ）受信および到達可能デバイスのそれぞれで受信した検査手順を実行し、開始ソースデバイスが必要とする到達可能デバイスの少なくとも１つのリソースまたはケイパビリティがあるか否かを特定することと、（ｃ）到達可能デバイスが、少なくとも開始ソースデバイスが必要とすると特定されたリソースまたはケイパビリティにアクセスできる時、開始ソースデバイスにリターンを送信することと、（ｄ）通信リンクを介して直接あるいは間接的に、到達可能デバイスのそれぞれからリターンを受信することと、（ｅ）開始デバイスで実行するアプリケーションによって、全ての応答到達可能デバイスからの受信リターンを分析し、アプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイスのケイパビリティおよびリソースの組み合わせを特定する利用プランを決定することと、（ｆ）開始デバイスで実行するアプリケーションプログラムにより、特定された利用プランに従って必要なリソースまたはケイパビリティを有すると特定された到達可能デバイスのそれぞれの少なくとも１つに実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを配信することとを含む。
【０１６１】
別の実施例（４）では、本発明は（３）の方法を提供し、少なくとも１つの到達可能デバイスによって、配信された実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを受信することをさらに含む。なる。
【０１６２】
別の実施例（５）では、本発明は（３）の方法を提供し、この方法はさらに、開始デバイスのアプリケーションの意図の少なくとも一部を実行するため実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つが配信された少なくとも１つの到達可能デバイスと相互運用することを含む。
【０１６３】
別の実施例（６）では、本発明は（３）の方法を提供し、この方法はさらに、各到達可能デバイスを二次開始ソースデバイスとして動作させ、開始および到達可能デバイス間で実行可能コード、データ、コンテンツおよび／またはＤａｒｔをスプレッドし、任意で、到達可能デバイスに常駐するアプリケーションコード、データ、コンテンツおよび／またはＤａｒｔｓを、必要に応じて以前に到達しチームとしたデバイスによって到達可能な他のデバイスに再帰的にスプレッドし、当初の開始デバイスアプリケーションの意図を実行するため望ましいデバイスおよび必要か望ましいリソースまたはケイパビリティの所定の基準に達するまで、他の到達可能デバイスユニットに必要に応じてまたは所望によってアプリケーションを拡張し、より大きく完全なデバイスのチームを効果的に結成することと、開始デバイスのアプリケーションの意図を実行するため、コードを実行し、開始アプリケーションの意図を実行するためデバイスのチーム間で実行すべきオペレーションを実行および／または調整するために必要なあらゆる実行可能コード、データおよびコンテンツおよび／またはＤａｒｔｓを交換することにより、必要あるいは望ましいオペレーションおよびリソースアクセスを実行する開始デバイスのアプリケーションのニーズおよび所望に従って、開始および到達可能デバイスのチームから、およびこの中で実行可能コード、データ、コンテンツおよび／またはＤａｒｔを配信することとを含む。
【０１６４】
別の実施例（７）では、本発明は（３）の方法を提供し、開始デバイスが、１以上の中間到達可能デバイスを介して直列または再帰的方法で、別の到達可能デバイスへ、またはこれから間接的に、リクルートメントメッセージを送信したというリターンを、開始ソースデバイスが最初に到達したデバイスから直接受信することを特徴とする。
【０１６５】
別の実施例（８）では、本発明は（３）の方法を提供し、開始ソースデバイスへのリターンは、到達可能デバイスが、開始ソースデバイスが必要とすると特定されたリソースまたはケイパビリティにアクセスできない時にも送信されることを特徴とする。
【０１６６】
別の実施例（９）では、本発明は（３）の方法を提供し、開始ソースデバイスへのリターンは、到達可能デバイスが、開始ソースデバイスが必要とすると特定されたリソースまたはケイパビリティを自身が持っているか、アクセスできる（真または論理的「１」）か、自身が持っていないかアクセスできない（偽または論理的「０」）であることを特定する単純なパラメータであることを特徴とする。
【０１６７】
別の実施例（１０）では、本発明は（３）の方法を提供し、開始ソースデバイスへのリターンは、ＤａｒｔＥｖｅｎｔ、Ｄａｒｔの一部、データ、コンテンツ、実行可能手順、Ｄａｒｔ、複数のＤａｒｔｓおよびその組み合わせの１つを含むことを特徴とする。
【０１６８】
別の実施例（１１）では、本発明は（３）の方法を提供し、開始ソースデバイスへのリターンは、通信プロトコルを介して開始デバイスに、特定の到達可能デバイスのリソースおよび／またはケイパビリティを特定するリターンされたデータまたはコンテンツを含むことを特徴とする。
【０１６９】
別の実施例（１２）では、本発明は（３）の方法を提供し、検査手順は、開始ソースデバイスで少なくとも部分的に実行されるアプリケーションタスクの意図を実行するため、開始ソースデータが必要とすると特定された少なくとも１つのリソースまたはケイパビリティを検査する命令を含むことを特徴とする。
【０１７０】
別の実施例（１３）では、本発明は（３）の方法を提供し、この方法は、デバイスのチーム間でアプリケーションをリクルートし、効果的に実行するコンピュータプログラム製品としてエンコードされたソフトウェアアプリケーションによって少なくとも部分的にインプリメントされることを特徴とする。
【０１７１】
別の実施例（１４）では、本発明は（３）の方法を提供し、この方法は、リクルートしたデバイスとリクルートされたデバイスの全てのリソースを組み合わせた１台のデバイスであるかのように、リクルートしたデバイスとリクルートされたデバイスのオペレーションのコントロールを連結し、その後に許可するのに有効であることを特徴とする。
【０１７２】
別の実施例（１５）では、本発明は（３）の方法を提供し、リターンは、リターンがないか、データまたはコンテンツのリターンか、あらゆるデジタルにエンコードされた情報か、１以上の手順か、デバイスが有益である表示か、リターンされたイベントか、ファイルのペイロードを介したデータの量またはデータのセットを含むリターンイベントか、リターン手順か、Ｄａｒｔか、どのデバイスを利用するかを人間が開始デバイスのメニューから選択できるようなデバイスのテキスト名および記述を含むリターンイベントか、ソースデバイスに常駐するか、生成されることの可能な実行可能コード、データおよびコンテンツのセットの少なくとも１つのインスタンスの特定のパッケージの識別子か、デバイスで動作するのに最も適したレンディションまたはレンディションのセットか、これらのいずれかの組み合わせかのどれか１つであることを特徴とする。
【０１７３】
別の実施例（１６）では、本発明は（３）の方法を提供し、少なくとも１つのリソースまたはケイパビリティは、（ｉ）利用可能なリソースまたは特定の必要なリソース、（ｉｉ）利用可能なケイパビリティまたは特定の必要なケイパビリティ、（ｉｉｉ）到達可能デバイスのリソースおよびケイパビリティの１以上の相互関連セット、またはアプリケーションの意図を実行するため到達可能デバイスが利用可能なリソースおよび／またはケイパビリティ、および（ｉｖ）これらの組み合わせからなるセットから選択することを特徴とする。
【０１７４】
別の実施例（１７）では、本発明は（３）の方法を提供し、リソースまたはケイパビリティは、特定されたデータ操作ソフトウェア、特定された情報処理ソフトウェア、特定されたコンピュテーションソフトウェア、特定された画像処理ソフトウェア、特定された通信ソフトウェア、特定された通信ハードウェア、特定されたメディア、特定されたデータセット、特定されたコンテンツ、特定された単数または複数のプログラム、特定された構成情報、特定されたグラフィック加速ハードウェアまたはソフトウェア、一時的または非一時的（恒久的）を問わず特定された記憶媒体、特定された印刷ケイパビリティ、特定されたファックスケイパビリティ、特定されたスキャンケイパビリティ、入力または出力あるいは入力および出力両方かを問わず、特定されたユーザインターフェースデバイス、デバイスが通信でき、他のデバイスが無限チェーンで通信できるほかのデバイスのリソースへのアクセス、およびこれらの２個以上の組み合わせからなるリソースまたはケイパビリティのセットから選択した特定されたケイパビリティの少なくとも１つのセットを含むことを特徴とする。
【０１７５】
別の実施例（１８）では、本発明は（３）の方法を提供し、共通の実行可能形式の検査手順は、Ｄａｒｔ命令互換エンジン（ＤａｒｔＥｎｇｉｎｅ）その他インタオペラビリティ命令セットに埋め込まれたＤａｒｔ準拠命令セット（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ）から形成した少なくとも１つの検査手順を含むことを特徴とする。
【０１７６】
別の実施例（１９）では、本発明は（３）の方法を提供し、少なくとも１つの通信リンクは、あらゆる数の通信リンクと、チャンネルと、および／または有線か無線かを問わず、また恒久的に利用可能か間断的かを問わず、あらゆる数の同種または異種の通信プロトコルまたはそのセットを有するプロトコルを備えることを特徴とする。
【０１７７】
別の実施例（２０）では、本発明は（３）の方法を提供し、異種および同種の通信リンク、チャンネルおよびプロトコルは、いずれか２以上の通信デバイスで動作するプレイヤの部分である特定されたハードウェア抽象化層インプリメンテーションによってサポートされることを特徴とする。
【０１７８】
別の実施例（２１）では、本発明は（２０）の方法を提供し、特定されたハードウェア抽象化層インプリメンテーションは、ＤａｒｔＥｎｇｉｎｅのコンポーネントであるＤａｒｔハードウェア抽象化層インプリメンテーションを含むことを特徴とする。
【０１７９】
別の実施例（２２）では、本発明は（３）の方法を提供し、少なくとも１つの通信リンクおよび通信プロトコルを用いて、ラン手順タイプのイベントを送信し、イベントのイベント識別子は、到達可能デバイスで動作するため手順を識別するファイルを参照することを特徴とする。
【０１８０】
別の実施例（２３）では、本発明は（２２）の方法を提供し、イベントは、ＤａｒｔＥｖｅｎｔｓを含み、ラン手順タイプのイベントは、Ｄａｒｔ  ＲＵＮ＿ＰＲＯＣＥＤＵＲＥタイプイベントを含むことを特徴とする。
【０１８１】
別の実施例（２４）では、本発明は（３）の方法を提供し、到達可能デバイスで動作するため手順を識別するファイルを参照するイベント識別子は、到達可能デバイスで動作するため手順の画像を含むファイルを参照するイベントのフィールドある識別子から含むことを特徴とする。
【０１８２】
別の実施例（２５）では、本発明は（２４）の方法を提供し、ファイルは、ＤａｒｔＦｏｒｍａｔに準拠するＤａｒｔ準拠ファイル（ＤａｒｔＦｉｌｅ）を含み、手順の画像は、ＤａｒｔＰｒｏｃｅｄｕｒｅ（ＤａｒｔＰｒｏｃｅｄｕｒｅ）のバイナリデータ画像を含むことを特徴とする。
【０１８３】
別の実施例（２６）では、本発明は（３）の方法を提供し、検査手順は、ＤａｒｔＰｒｏｃｅｄｕｒｅｓまたは完全なＤａｒｔｓのいずれかを含むことを特徴とする。
【０１８４】
別の実施例（２７）では、本発明は（３）の方法を提供し、検査手順をイベントと関連するファイルとして送信し、イベントと関連するファイルとしての検査手順の到達可能デバイスによる受信によって、到達可能デバイスでの検査手順の実行が開始されることを特徴とする。
【０１８５】
別の実施例（２８）では、本発明は（３）の方法を提供し、検査手順は、ＤａｒｔＰｒｏｃｅｄｕｒｅを含むことを特徴とする。
【０１８６】
別の実施例（２９）では、本発明は（３）の方法を提供し、到達可能デバイスの基本リソースおよびケイパビリティを含むリソースおよびケイパビリティは、命令セットプロフィール命令の利用によって決定することを特徴とする。
【０１８７】
別の実施例（３０）では、本発明は（２９）の方法を提供し、命令セットプロフィール命令は、Ｄａｒｔ準拠命令セット（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ）のＤａｒｔ準拠プロフィール命令（ＤａｒｔＰｒｏｆｉｌｅＩｎｓｔｒｕｃｔｉｏｎ）を含むことを特徴とする。
【０１８８】
別の実施例（３１）では、本発明は（３）の方法を提供し、各到達可能デバイス内の検査手順実行は、特定の到達可能デバイスまたはそのそれぞれに送られるレンディション決定ルールに従って、開始Ｄａｒｔ埋め込みアプリケーションの最良レンディションを決定し、返すデータの一部として決定した最良レンディションの識別子を送り返すことを特徴とする。
【０１８９】
別の実施例（３２）では、本発明は（３１）の方法を提供し、レンディション決定ルールは、あらゆる複雑性の必要なコンピュテーションを実行し、到達可能デバイスのリソース、ケイパビリティおよび／または状態を決定するプロフィール命令を通じて必要なプロフィール情報にアクセスするよう適合された少なくとも１つの手順に埋め込まれることを特徴とする。
【０１９０】
別の実施例（３３）では、本発明は（３１）の方法を提供し、検査手順実行は、レンディションの順序を定義するルールを参照し、複数のレンディションのそれぞれの要件全てが予め定義されたレンディション優先順序を満たすか否か、複数のレンディション中でレンディションの要件全てを満たす最初のレンディションが見つかるまで到達可能デバイスのそれぞれをチェックすることにより、複数のレンディションから最小のレンディションを決定することを特徴とする。
【０１９１】
別の実施例（３４）では、本発明は（３）の方法を提供し、検査手順は、Ｄａｒｓ、手順、データまたはコンテンツを、理解された通信プロトコルを用いて通信リンクを介して開始デバイスに返すことを特徴とする。
【０１９２】
別の実施例（３５）では、本発明は（３）の方法を提供し、リターンは、少なくとも返された手順、データまたはコンテンツと、完全なＤａｒｔｓ、ＤａｒｔＰａｒｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅｓまたはＤａｒｔＥｖｅｎｔｓのいずれかあるいは組み合わせのうちの少なくとも１つを含み、その１つまたは組み合わせは関連するイベントファイルありまたはなしで返されることを特徴とする。
【０１９３】
別の実施例（３６）では、本発明は（３）の方法を提供し、リターンは、返された手順、データまたはコンテンツおよび／またはＤａｒｔのうち少なくとも１つを含み、さらに任意で、エラー発生をしめすリターンコードを含み、エラーコードは、特定のエラーが発生したこと、または非特定エラーが発生したことを示し、エラーコードは任意で、特定のエラーおよび／またはエラーの性質を是正または通信するのに有益な情報を含むことを特徴とする。
【０１９４】
別の実施例（３７）では、本発明は（３）の方法を提供し、アプリケーションコードは、Ｄａｒｔ、ＤａｒｔＰｒｏｃｅｄｕｒｅ、または、開始デバイスあるいはプログラムの転送または実行を開始し、実行の結果を利用するために開始デバイスがアクセスするデバイス上で実行可能なあらゆる形式のプログラムのうち少なくとも１つであることを特徴とする。
【０１９５】
別の実施例（３８）では、本発明は（３）の方法を提供し、アプリケーションコードは、Ｄａｒｔ、ＤａｒｔＰｒｏｃｅｄｕｒｅ、または、手順的フォーマットが到達可能デバイスで実行するためのＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔを利用するか否かを問わず、到達可能デバイスで実行可能または情報を送ることができる別の手順的フォーマットを含むことを特徴とする。
【０１９６】
別の実施例（３９）では、本発明は（３）の方法を提供し、リクルートされたデバイスのチームは、そのチームをダイナミックに拡張して、他の到達可能デバイスを含めたり、デバイスのチームを縮小して、アプリケーションの寿命または定義された実行期間中に所望の到達可能デバイスを除外したりできることを特徴とする。
【０１９７】
別の実施例（４０）では、本発明は（３）の方法を提供し、配信は、Ｄａｒｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅｓ、データ、コンテンツその他情報、またはこれらの組み合わせで、イベントでフィールドが参照した情報がイベントと共に、あるいはイベントの一部として送信されたか否かを問わず、ダートイベント（ＤａｒｔＥｖｅｎｔｓ）の一部としてカプセル化されていることを特徴とする。
【０１９８】
別の実施例（４１）では、本発明は（３）の方法を提供し、デバイスのチームから、またはその間で開始アプリケーションのニーズに従って配信されたコード、データおよびコンテンツは、コードを実行し、開始アプリケーションの意図をさらに実行するためにデバイスのチーム間で実行するオペレーションの実行または調整に必要なあらゆる追加または異なるコード、データおよびコンテンツを任意で交換することにより、発信アプリケーションの意図を実行するため必要なオペレーションおよびリソースアクセスを実行することを特徴とする。
【０１９９】
別の実施例（４２）では、本発明は（３）の方法を提供し、アプリケーションは、リクルートメントプロセスの一部として全デバイスに配信された全てのコードを含むシングルバイナリイメージに埋め込まれることを特徴とする。
【０２００】
別の実施例（４３）では、本発明は（３）の方法を提供し、この方法はさらに、デバイスのチーム上の同期、直列化、調整からなり、同期、直列化および調整は、イベント、またはＤａｒｔＥｖｅｎｔｓのみ、または任意でＤａｒｔＥｖｅｎｔｓまたはイベントと関連するファイルをパスまたは交換することによって完全にまたは部分的に達成することを特徴とする。
【０２０１】
別の実施例（４４）では、本発明は（４３）の方法を提供し、イベントは少なくとも１つのファイルを参照し、その参照によって、ファイルまたは複雑性のファイルイメージを有するファイルを効果的に含有して組み込み、これらファイルイメージがイベント構造コンテンツと通信するようにすることを特徴とする。
【０２０２】
別の実施例（４５）では、本発明は（３）の方法を提供し、相互運用および通信している開始およびリクルートされたデバイスのみ、または任意で、ＤａｒｔＥｖｅｎｔｓまたはイベントに関連するファイルの間でＤａｒｔＥｖｅｎｔｓイベントをパスまたは交換することからさらになり、イベントは、ＤａｒｔＥｖｅｎｔ構造のファイル識別子（フィールド）参照により、ファイルまたは他のデータまたは複雑性のデータ構造を含み、参照時、ファイルイメージは常にイベント構造コンテンツと通信されることを特徴とする。
【０２０３】
別の実施例（４６）では、本発明は（４３）の方法を提供し、ＤａｒｔＥｖｅｎｔまたはイベントは、ＤａｒｔＦｒａｍｅｗｏｒｋ、ＤａｒｔＲｕｎｔｉｍｅおよび／またはＤａｒｔＥｎｇｉｎｅ、あるいは非ＤａｒｔＰｌａｔｆｏｒｍ固有イベント駆動型インプリメンテーションにより、チーム化されたあらゆる数のデバイスのイベント待ち行列間で自動的にコピーおよび／または同期され、自動同期について識別され、Ｄａｒｔによってイベント待ち行列に入れられたＤａｒｔＥｖｅｎｔｓまたはイベントが、自動直列化および同期によってあらゆる数のチーム化されたデバイスのイベント待ち行列に現れることを特徴とする。
【０２０４】
別の実施例（４７）では、本発明は（４６）の方法を提供し、自動直列および同期は、開始デバイスを含む複数の協働デバイス間で動作するイベント駆動型協調アプリケーション、機能またはレンディションの自動直列化および同期のための手順によって達成され、この方法は、所望の各デバイス間協働機能のためのアプリケーションによって発信デバイス上で接続マネージャオブジェクトインスタンスを作成することと、全ての協働デバイス上でアプリケーションによって手順的に同期されるイベントタイプのリストを接続マネージメントに通信することと、各デバイスに１つの接続マネージャを有する協働デバイスのリストを確立し、同じ同期イベントタイプのリストを共有することと、接続マネージャによって、チーム化されたデバイスと同期するイベントタイプを特定するセッションリストを維持することと、接続マネージャによって、イベント待ち行列に入れる全てのイベントを調べ、調べた特定のイベントが、接続マネージャがセッションリストから同期すべきとわかるイベントタイプである場合、そのイベントと、他のセッションと同期するイベントとして、そのイベントを接続マネージャに一覧したデバイスのイベント待ち行列に入れることとを含むことを特徴とする。
【０２０５】
別の実施例（４８）では、本発明は（４７）の方法を提供し、イベント駆動型協働アプリケーション機能またはレンディションのいずれか１つが受信した協働デバイスイベント待ち行列に入れる全てのイベントを、いずれかのデバイスによってイベントを直接送信された全ての協働デバイスイベント待ち行列が協働デバイスのイベント待ち行列に入れられたとの肯定応答を受信するまで、あらゆるデバイスのイベント待ち行列にイベントを入れることを許可しないことによって直列化することを特徴とする。
【０２０６】
別の実施例（４９）では、本発明は（４８）の方法を提供し、イベント駆動型協働アプリケーション機能またはレンディションのいずれか１つが受信した協働デバイスイベント待ち行列に入れる全てのイベントを、いずれかの受信デバイスによってイベントを送信された全ての協働デバイスイベント待ち行列が協働デバイスのイベント待ち行列に入れられたとの肯定応答を受信するまで、受信側のあらゆるデバイスのイベント待ち行列にイベントを入れることを許可しないことによって直列化することを特徴とする。
【０２０７】
別の実施例（５０）では、本発明は（４８）の方法を提供し、デバイスが、直接通信デバイスのチェーンを介して直接あるいは間接に通信しているかを問わず、あらゆる数の協働デバイスのイベント待ち行列が、全協働デバイス間で待ち行列イベントの直列化された１つのシステムを確立することを特徴とする。
【０２０８】
別の実施例（５１）では、本発明は（４９）の方法を提供し、デバイスが、直接通信デバイスのチェーンを介して直接あるいは間接に通信しているかを問わず、あらゆる数の協働デバイスのイベント待ち行列が、全協働デバイス間で待ち行列イベントの直列化された１つのシステムを確立することを特徴とする。
【０２０９】
別の実施例（５２）では、本発明は（４７）の方法を提供し、１つのマスタデバイスのみが同期するイベントタイプのリストにそのタイプのイベントを入れることで、かかるイベントすべてが全協働デバイス間で直列化されるようにできるシステムにより、２つ以上の協働デバイスから協働デバイスの待ち行列に入れるイベントを協働デバイスの待ち行列のイベントに単一同期することを特徴とする。
【０２１０】
別の実施例（５３）では、本発明は（５２）の方法を提供し、マスタデバイスは、マスタデバイスが全協働デバイスの待ち行列に目的のイベントを入れるために必要な全ての情報を含むマスタの要求イベントタイプのイベントによって、他の協働デバイスに代わり発行するイベントを知らされることを特徴とする。
【０２１１】
別の実施例（５４）では、本発明は（５２）の方法を提供し、他のデバイスによって協働デバイスのセットになるよう協働デバイスのチームにリクルートされた各デバイスは、その相対的マスタデバイスを、自分をリクルートしたデバイスとみなすことを特徴とする。
【０２１２】
別の実施例（５５）では、本発明は（５３）の方法を提供し、他のデバイスによって協働デバイスのセットになるよう協働デバイスのチームにリクルートされた各デバイスは、その相対的マスタデバイスを、自分をリクルートしたデバイスとみなすことを特徴とする。
【０２１３】
別の実施例（５６）では、本発明は（５４）の方法を提供し、マスタ要求イベントタイプのイベントをマスタのデバイスの待ち行列に入れることにより、相対的マスタを持たない開始マスタデバイスが、マスタデバイスが全協働デバイスの待ち行列に目的のイベントを入れるために必要な情報を用いて、イベントを形成するまで、イベントをデバイスから相対マスタデバイスへ伝播させることを特徴とする。
【０２１４】
別の実施例（５７）では、本発明は（５２）の方法を提供し、指定されたマスタデバイスは、協働デバイスの同期および／または直列化された待ち行列に、自身が直列化イベントのリストにある変更マスタタイプイベントを発行し、同期直列化方法で全デバイスに、新しいマスタデバイスが現行マスタデバイスに取って代わることを知らせることにより、変更できることを特徴とする。
【０２１５】
別の実施例（５８）では、本発明は（５４）の方法を提供し、マスタ要求イベントは、新しいマスタデバイスがイベントを処理するまで、協働デバイスの待ち行列を通じて伝播することを特徴とする。
【０２１６】
別の実施例（５９）では、本発明は（５５）の方法を提供し、マスタ要求イベントは、新しいマスタデバイスがイベントを処理するまで、協働デバイスの待ち行列を通じて伝播することを特徴とする。
【０２１７】
別の実施例（６０）では、本発明は（５３）の方法を提供し、マスタ要求イベントタイプのイベントによって送られると指定されたイベントの一部と特定されたオプションのファイルは、かかるファイル参照が存在する場合、識別子のある各伝播デバイスに維持され、マスタに送信されるイベントの一部として送信されたかのように、マスタによって送信されるイベントと再び関連できるようになり、これは、マスタに処理されるマスタ要求イベントタイプの結果として送られる各イベントの一部として送らなければならなかった情報量を減らすためである。
【０２１８】
別の実施例（６１）では、本発明は、メモリと接続され、目的のタスクの実行命令を含む手順を実行するよう適合されたプロセッサと、目的のタスク実行に参加するため装置と異なる外部の少なくとも１つのリクルートされたデバイスをリクルートするためプロセッサおよびメモリで少なくとも部分的に実行する手段で、リクルートされたデバイスは、目的のタスク実行のバージョンに必要な少なくともハードウェアリソースを含むものと、リクルートされたデバイスのリソースを補完するための装置内に完全に保存された手段で、ハードウェアのリソースと使用可能にされた補完リソースは、リクルートされたデバイスが目的のタスクの実行を完全に可能にするものとを備える開始装置を提供する。
【０２１９】
別の実施例（６２）では、本発明は（６１）の開始装置を提供し、装置およびリクルートされたデバイスはそれぞれ共通の手順的環境で動作し、リクルートのためプロセッサおよびメモリで少なくとも部分的に実行される手段は、少なくとも１つの接続を介して、共通の手順的環境を含むかここで動作する他のデバイスに共通手順的環境でインプリメントされた手順をブロードキャストする手段を含むことを特徴とする。
【０２２０】
別の実施例（６３）では、本発明は（６２）の開始装置を提供し、リクルートするための手段はさらに、他のデバイスそれぞれのリソースおよびケイパビリティをプログラムで検査するための他のデバイス上の手順の実行を開始する手段を含み、各デバイスが特定のタスクの時刻に参加するのに必要なリソースまたはケイパビリティを有するか否か判断することを特徴とする。
【０２２１】
別の実施例（６４）では、本発明は（６３）の開始装置を提供し、検査は特定のデバイスに保存するか、これについて計算したデバイス固有抽象化層情報に少なくとも部分的にアクセスすることにより各特定のほかのデバイスで実行することを特徴とする。
【０２２２】
別の実施例（６５）では、本発明は（６４）の開始装置を提供し、補完手段はさらに、各デバイスが特定のタスクの一部を実行できるようにするために必要なイネーブリング手順、データおよび／またはコンテンツを送信およびインストールするための手段を含むことを特徴とする。
【０２２３】
別の実施例（６６）では、本発明は（６１）の開始装置を提供し、開始デバイスと他のデバイスとの間でオペレーションを一時的または恒久的に同期させるための手段をさらに含み、同期手段は、タスクイベント待ち行列と、タスクイベント待ち行列を維持するための手段とを含むことを特徴とする。
【０２２４】
別の実施例（６７）では、本発明は、プロセッサと、プロセッサに接続されたメモリとを含むハードウェアリソースのセットと、タスクのセットの実行のために適合されたコンピュータプログラムコードリソースとからなり、ハードウェアリソースは、特定のタスクの実行の少なくとも１バージョンを実行することが可能だが、コンピュータプログラムコードリソースは、特定のタスクまたは特定のタスクの態様を実行するための所望のバージョンまたは方法と、コンピュータプログラムコード通信およびデータ通信の少なくとも一方を含む通信を受信するための手段の実行が当初は可能ではなく、コンピュータプログラムコード通信は、特定のタスクの所望のバージョン、方法または態様の実行が可能な装置をレンダリングする補完的コンテンツプログラムコードリソースを含むことを特徴とする。
【０２２５】
別の実施例（６８）では、本発明は（６７）のリクルートされた装置を提供し、リクルートされた装置と開始デバイスは、共通手順的環境でそれぞれ動作することを特徴とする。
【０２２６】
別の実施例（６９）では、本発明は（６８）のリクルートされた装置を提供し、リクルートされたデバイスが特定のタスクの実行に参加するために必要なリソースまたはケイパビリティを有するか否か判断するため、リクルートされたデバイスのリソースおよびケイパビリティをプログラムで検査する、開始デバイスから受信した手順の実行のための手段をさらに含むことを特徴とする。
【０２２７】
別の実施例（７０）では、本発明は（６９）のリクルートされた装置を提供し、検査は、リクルートされたデバイスに保存するか、これについて計算したデバイス固有抽象化層情報に少なくとも部分的にアクセスすることによりリクルートされたデバイスで実行することを特徴とする。
【０２２８】
別の実施例（７１）では、本発明は（７０）のリクルートされた装置を提供し、リクルートされたデバイスが特定のタスクの一部を実行できるようにするために必要なイネーブリング手順、データおよび／またはコンテンツをインストールするための手段を含むことを特徴とする。
【０２２９】
別の実施例（７２）では、本発明は（６１）のリクルートされた装置を提供し、開始デバイスとリクルートされたデバイスとの間でオペレーションを一時的に同期させるための手段をさらに含み、同期手段は、タスクイベント待ち行列と、タスクイベント待ち行列を維持するための手段とを含むことを特徴とする。
【０２３０】
別の実施例（７３）では、本発明は、特定のタスクの実行に参加するため、複数の異種デバイスの間で一体化された特別ななオンザフライ配信情報処理システムを形成する方法を提供し、その方法は、開始デバイスによって配信された情報処理システムの結成を開始することで、情報は、少なくとも１つの通信チャンネルと、特定のタスクの実行に参加するためのリソースまたはケイパビリティを所有するほかのリクルートされたデバイスを識別またはリクルートする目的のあるプロトコルを用いて、メッセージをブロードキャストすることを含むものと、リクルートされたデバイスのそれぞれに必要とされた手順、データおよびコンテンツの少なくとも１つを通信し、リクルートされたデバイスのそれぞれが特定のタスクの一部を実行できるようにすることとを含むことを特徴とする。
【０２３１】
別の実施例（７４）では、本発明は（７３）の方法を提供し、目的のタスクの実行に参加するため、開始デバイスと異なる外部の少なくとも１つのリクルートされたデバイスをリクルートするための手順を、開始デバイスのプロセッサとメモリで少なくとも部分的に実行することで、リクルートされたデバイスは、目的のタスクの実行のバージョンに必要な少なくともハードウェアリソースを含むものと、リクルートされたデバイスのリソースを補完する手順および任意のデータを開始装置内に完全に保存し、ハードウェアのリソースと使用可能にされた補完リソースが、リクルートされたデバイスが目的のタスクを完全に実行できるようにすることとをさらに含むことを特徴とする。
【０２３２】
別の実施例（７５）では、本発明は（７４）の方法を提供し、開始デバイスとリクルートされたデバイスは、共通手順的環境でそれぞれ動作し、リクルートするためプロセッサおよびメモリで少なくとも部分的似実行する手順は、やはり共通手順的環境を含むかこれで動作する他のデバイスに少なくとも１つの接続を介して共通手順的環境でインプリメントされた手順をブロードキャストすることを含むことを特徴とする。
【０２３３】
別の実施例（７６）では、本発明は（７５）の方法を提供し、リクルートはさらに、各デバイスが、特定のタスクの実行に参加するために必要なリソースまたはケイパビリティを有するか否か判断するため、他のデバイスのそれぞれのリソースとケイパビリティをプラグラム的に検査する手順の実行を他のデバイスで開始することを含むことを特徴とする。
【０２３４】
別の実施例（７７）では、本発明は（７６）の方法を提供し、検査は、特定のデバイスに保存するか、これについて計算したデバイス固有抽象化層情報に少なくとも部分的にアクセスすることにより特定の他のリクルートされたデバイスのそれぞれで実行することを特徴とする。
【０２３５】
別の実施例（７８）では、本発明は（７７）の方法を提供し、保管はさらに、各デバイスが特定のタスクの一部を実行できるようにするために必要なイネーブリング手順、データおよび／またはコンテンツを送信およびインストールするための手段を含むことを特徴とする。
【０２３６】
別の実施例（７９）では、本発明は（７７）の方法を提供し、開始デバイスとリクルートされたデバイスとの間でオペレーションを一時的に同期させることをさらに含み、同期は、タスクイベント待ち行列と、タスクイベント待ち行列の生成と維持とを含むことを特徴とする。
【０２３７】
別の実施例（８０）では、本発明は（７３）の方法を提供し、通信は、クライアントサーバ通信インタラクションでもピアツーピア通信インタラクションでもない通信およびインタラクションであることを特徴とする。
【０２３８】
別の実施例（８１）では、本発明は（７３）の方法を提供し、リクルートメントは、必要なデバイスを識別するため、特別なデバイス、サービスおよびリソース発見を実行し、イベントを用いてデバイスにイネーブリング手順および情報を送信し、インテリジェントおよび有効にデバイスのチームを結成してから、イベントを用いてデバイスのチームを調整し、ソース開始デバイスで当初動作しているＤａｒｔまたはアプリケーションまたはタスクの目標を達成することを特徴とする。
【０２３９】
別の実施例（８２）では、本発明は（７３）の方法を提供し、分散情報処理システムは、デバイスの物理的ケイパビリティの一部または全部のアクセスと調整された利用とを含むことを特徴とする。
【０２４０】
別の実施例（８３）では、本発明は（８２）の方法を提供し、デバイスの物理的ケイパビリティは、任意で印刷、ファックス、表示、音楽のレンダリング、ビデオのレンダリング、他のデバイスの制御、デジタルかアナログかを問わず、あらゆる媒体でのデータの保存、グッズの製造、排除、撮影その他、デバイスの処理ケイパビリティによってアクセス、モニタまたは制御できるあらゆる物理的ケイパビリティを含む能力のセットから選択することを特徴とする。
【０２４１】
別の実施例（８４）では、本発明は（１）の方法を提供し、１以上のデバイスで動作するソフトウェアアプリケーションは、当初は開始デバイス上の単一のソフトウェアパッケージの一部であったコードおよび／またはデータおよび／またはコンテンツを有する２以上のデバイスでのインタオペラビリティオペレーションを少なくとも部分的に実行することで、開発および／または独立的配信したアプリケーションを用いてインタオペラビリティオペレーションを実行する場合より大きなインタオペラビリティ信頼性を享受することを特徴とする。
【０２４２】
別の実施例（８５）では、本発明は、コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品を提供し、このコンピュータプログラム製品は、コンピュータリーダブル記憶媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとからなり、コンピュータプログラムメカニズムは、コンピュータシステムまたは情報機器に、インタオペラビリティのためリクルートされたデバイスのチームを指定の方法でリクルートする機能を指示するプログラムモジュールで、プログラムモジュールは、少なくとも１つの通信リンクを介して開始ソースデバイスと異なる少なくとも１つの到達可能デバイスに必要なリソースまたはケイパビリティを有するデバイスを見つけるよう動作可能な検査手順を送信する命令で、検査手順は、開始ソースデバイスと、検査手順を到達させるデバイスとの両方に共通する実行可能形式でコード化された検査手順命令を含むものと、開始デバイスにおいて、通信リンクを介して直接あるいは間接的に到達可能デバイスのそれぞれからリターン応答を受信することと、開始デバイスで実行する手順により、応答到達可能デバイス全てからの受信リターンを分析し、ソフトウェアアプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイスとのケイパビリティおよびリソースの組み合わせを特定する利用プランを決定することと、開始デバイスで実行するアプリケーションプログラムによって、特定された利用プランにしたがって必要なリソースまたはケイパビリティを有すると特定された到達可能デバイスのそれぞれの少なくとも１つに、実行可能コード、データおよび／またはＤａｒｔの少なくとも１つを配信することとを含むことを特徴とする。
【０２４３】
別の実施例（８６）では、本発明は、コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品を提供し、このコンピュータプログラム製品は、コンピュータリーダブル媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとからなり、コンピュータプログラムメカニズムは、単一のバーチャルデバイスとして動作して、特定のタスクの実行に参加するため、複数の非類似デバイスの中で一体型の特別でオンザフライの分散情報処理システムを指定の方法で形成するよう機能することをコンピュータシステムまたは情報機器に指示するプログラムモジュールで、プログラムモジュールは、開始デバイスによる配信情報処理システムの形成を開始することで、形成は、少なくとも１つの通信チャンネルと、特定のタスクの実行に参加するためのリソースまたはケイパビリティを所有する他のリクルートされたデバイスを識別およびリクルートする目的を持つプロトコルを用いてメッセージをブロードキャストすることと、リクルートされたデバイスのそれぞれに必要とされた手順、データおよびコンテンツの少なくとも１つを通信し、リクルートされたデバイスのそれぞれが特定のタスクの一部を実行できるようにすることとを含むことを特徴とする。
【０２４４】
これら実施例およびこの詳細な説明または図面の他の部分に記載する実施例の特徴および／または要素は、様々な方法で組み合わせることができ、上述の実施例が本発明の限定ではなく、特徴および要素の異なる組み合わせまたは置き換えによる追加または代替実施例もまた本発明の実施例である。
ＩＩＩ．レンディションアダプテーションおよびインタオペラビリティセグメンテーションモデル
【０２４５】
本発明の別の態様では、レンディションのためのシステム、装置、方法およびコンピュータプログラムが提供される。レンディションには、インタオペラビリティアプリケーションを離散実行ユニットのセットにセグメント化する方法が含まれ、ある状況および時点であるデバイスまたはプレイヤで動作するよう正確にそのうちの１つが選択される。
【０２４６】
ある特定の有利な実施例およびインプリメンテーションでは、Ｄａｒｔアプリケーションフレームワーク（ＤａｒｔＦｒａｍｅｗｏｒｋ）は、Ｇｉｚｍｏ（図１１参照）と呼ばれる処理ユニット階層のトップとして動作するレンディションオブジェクトを含む。レンディションとは何かを理解するため、完全な従来プログラムとして単一レンディションを考慮するが、これは、インタオペラビリティオペレーションを実行するのに必要な相互関連機能およびコンテンツと共に生成およびパッケージ化された複数のレンディションの１つである点で、従来のプログラムと同一ではない。セットのレンディションのどれ１つとして、自身のアプリケーションまたはレンディションのパッケージの意図を効果的または効率的に実行できないことがしばしばあり得る。Ｄａｒｔなどのインタオペラビリティオペレーションは、一体化されたプログラムパーツの集合で、これは、パーツから動的および静的に組み立てたプログラムまたはレンディションを形成および管理するため、パーツをまとめる方法を知っている手順、データ、コンテンツおよび／またはリソースを含む（図３の３００、図１３、図１４参照）。さらに、インタオペラビリティアプリケーションまたはＤａｒｔは、異なるレンディションまたはレンディションのセットを、デバイスのチームの各デバイスに１セット、インテリジェントに配信する手段を含み、これで、アプリケーションの意図を効果的かつ効率的に実行するためチームの他のデバイスの他のレンディションによって、チームとして通信および協力することができる。
【０２４７】
レンディションの利点には、中でも、実行ユニット間でパーツを共有し、インタオペラビリティアプリケーションのサイズを限定できることがある。従来のプログラミング技術を用いると、各対象デバイスまたは環境に適した１つがあるように、アプリケーションのセットをパッケージする必要がしばしばある。レンディションなしだと、パッケージのプログラムのそれぞれに冗長な手順、データコンテンツおよびリソースを保存する必要が出てくる。レンディションの別の利点は、対象デバイスまたは環境で動作する正しいレンディションをインテリジェントに選択するため、リクルートメントモデルで用いる各レンディションに関連する選択手順（図１４、４０００参照）があり得る点である。レンディションのさらに別の利点は、あるデバイスまたは環境でよく動作するのに適した少なくとも１つのレンディションが存在するに充分な大きさのセットを可能にしながら、インタオペラビリティアプリケーションの徹底的な試験が可能な充分小さいセットにアプリケーションの数を限定できる点である。
【０２４８】
レンディションを用いて、Ｄａｒｔツール（図１２、２００のＤａｒｔＴｏｏｌｓ参照）に他のデバイスに送る特別目的Ｄａｒｔｓにパーツを自動的に構成させることもできる。これは例えば、画像や文書の印刷のための準備でもよい。このようなレンディション、またはレンディションのセットは、ＤａｒｔＴｏｏｌｓで静的に、または、本書に別の部分に記載するように、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ等のインタオペラビリティ命令セットを用いる他の技術クリエイショニズム方法（図７、２００２０）を通してダイナミックに、あるいはその２つを他の技術と共に用いて生成することができる。
【０２４９】
レンディションの他の利用法は、ユーザのニーズまたは希望に従って選択する言語または文化バージョンのセットの生成である。例えば、本質的に同じ情報を有する異なるレンディションを、フランス語、中国語等について生成したり、主に日本人観客への衣服の宣伝のための日本人モデルの写真を使ったり、イタリア人または欧州人顧客へ提示する同じ宣伝にイタリア人モデルの写真を使う等、異なるレンディションで異なる方法を提供することもできる。
【０２５０】
レンディションのさらに別の利用法は、理由を問わず、何らかのグループにとって好ましくない、あるいは重要でないか適切でないコンテンツの利用を制限することである。レンディションのさらに別の利用法は、子供やテキサス人など特定のグループまたはデバイスにコンテンツの利用を対象にすることである。レンディションのさらに別の利用法は、地方気象関連情報を含むＤａｒｔレンディションなど、異なる地方性を対象にすることである。
【０２５１】
ある態様では、レンディションは、ソフトウェアアプリケーションと関連するデータ、手順、コンテンツ、選択基準手順のセットのパーツをシングルバイナリイメージに緊密にパッケージ化する方法を提供する。これによって、パーツ、その特性、識別子およびバイナリイメージ中の位置のデータベースも提供される。手順および／またはデータおよび／またはコンテンツを含む個々に実行可能な複数のソフトウェアアプリケーションにパーツをマッピングすることもできる。さらに、実行した時、あるデバイス、ユーザの好み、通信特性および／または環境で、バイナリイメージのソフトウェアアプリケーションおよび関連データ、手順およびコンテンツのセットの中のどれを実行するかを判断する手順または手順のセットを提供する。さらに、ソース材料のセットに従い、パーツをシングルバイナリイメージ（また所望の場合は、複数のバイナリその他フォーマットのイメージ）に自動生成およびパッケージ化できるツールセットを提供する。レンディションの態様はまた、あるバイナリイメージ内部のパーツのデータベースを見つけてアクセスするためのメカニズムも提供する。単一Ｄａｒｔ内のこれによる配信レンディションの利用例については図８および図９に示す。
【０２５２】
レンディションアダプテーションおよびインタオペラビリティセグメンテーションモデルの特定の実施例についても以下に述べる。
【０２５３】
一実施例（１）では、本発明は、ソフトウェアアプリケーションを別個に実行可能なイメージのセットにセグメント化する方法を提供し、この方法は、アプリケーションの意図の１以上の態様を実行するため考えられるリソースおよびケイパビリティに従い、遭遇するデバイスをクラスに分けることと、アプリケーションの意図の１以上の態様を実行するため、明確なレンダリングその他ランタイム要件に関するニーズに従って、遭遇しそうな環境または動作要件をクラスに分けることと、デバイスの各クラスおよび各環境または動作要件で、アプリケーションの意図の１以上の態様を実行できるようにするために必要な実行可能イメージに必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定することと、ある候補デバイスのリストで、アプリケーションの意図を実行するのに利用する各デバイスで動作するデバイスと、対応する個々に割り当てられた実行可能イメージと、そのリソースおよびケイパビリティ、必要または所望の環境または動作パラメータを選択するための利用プランを生成することと、各クラスのデバイスおよび各環境または動作要件で利用プランをインプリメントおよび実行するために必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定することとを含むことを特徴とする。
【０２５４】
別の実施例（２）では、本発明は（１）の方法を提供し、ソフトウェアアプリケーションは、１以上の類似または非類似の通信デバイス間で動作することを意図する。
【０２５５】
別の実施例（３）では、本発明は（１）の方法を提供し、特定の環境であるデバイスで動作するよう、正確に１つのそのように選択した実行可能イメージを選択することを特徴とする。
【０２５６】
別の実施例（４）では、本発明は（３）の方法を提供し、各デバイスのリソースおよびケイパビリティおよび環境と動作要件に関してアプリケーションのニーズに従って、デバイスで動作するよう、正確に１つのそのように選択した実行可能イメージを選択することを特徴とする。
【０２５７】
別の実施例（５）では、本発明は（３）の方法を提供し、デバイスの少なくとも１つは、Ｄａｒｔデバイスであることを特徴とする。
【０２５８】
別の実施例（６）では、本発明は（１）の方法を提供し、生成された利用プランを実行することからさら含むことを特徴とする。
【０２５９】
別の実施例（７）では、本発明は（１）の方法を提供し、ソフトウェアアプリケーションはＤａｒｔと表現されることを特徴とする。
【０２６０】
別の実施例（８）では、本発明は（１）の方法を提供し、別個に実行するイメージはレンディションであることを特徴とする。
【０２６１】
別の実施例（９）では、本発明は（７）の方法を提供し、レンディションは、ＤａｒｔＦｏｒｍａｔに従ってＤａｒｔＴｏｏｌｓによってパッケージ化されたＤａｒｔレンディションの形式で表現されることを特徴とする。
【０２６２】
別の実施例（１０）では、本発明は（２）の方法を提供し、（１）の利用プランは、候補デバイスで動作するために送られる手順の全体または一部としてインプリメントされ、デバイスの特定のクラス、そのリソースおよび／またはその動作環境を決定することを特徴とする。
【０２６３】
別の実施例（１１）では、本発明は（１０）の方法を提供し、手順は、インタオペラビリティ命令セットの命令として少なくとも部分的に構成されるＤａｒｔＰｒｏｃｅｄｕｒｅｓであることを特徴とする。
【０２６４】
別の実施例（１２）では、本発明は（１１）の方法を提供し、インタオペラビリティ命令セットはＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔであることを特徴とする。
【０２６５】
別の実施例（１３）では、本発明は（１１）の方法を提供し、インタオペラビリティ命令セットは、手順を動作させる１以上の類似または非類似の通信デバイスで実行可能な形式であることを特徴とする。
【０２６６】
別の実施例（１４）では、本発明は（１３）の方法を提供し、通信デバイスは、特定のクラスのデバイス、そのリソースおよび／またはその動作環境を決定する手順を動作させることを特徴とする。
【０２６７】
別の実施例（１５）では、本発明は（１０）の方法を提供し、手順は、アプリケーションの一部であるＤａｒｔとして表現されることを特徴とする。
【０２６８】
別の実施例（１６）では、本発明は（１５）の方法を提供し、アプリケーションは、非類似の通信デバイス上でアプリケーションの意図を実行するために用いる他のＤａｒｔｓを含むＤａｒｔとして表現されることを特徴とする。
【０２６９】
別の実施例（１７）では、本発明は（１）の方法を提供し、（１）のリクルートメント方法を用いて手順と別個実行可能イメージを送信および配信し、非類似または類似デバイスのチームを結成することを特徴とする。
【０２７０】
別の実施例（１８）では、本発明は（１）の方法を提供し、パーツは異なる対象デバイスおよび処理環境で別個に動作する異なるイメージ間で共有可能で、インタオペラビリティアプリケーションのサイズを制限できることを特徴とする。
【０２７１】
別の実施例（１９）では、本発明は（１）の方法を提供し、パーツは異なる対象デバイスおよび処理環境で別個に動作する異なるイメージ間で共有可能で、ソフトウェアに保存するデータの量を制限できることを特徴とする。
【０２７２】
別の実施例（２０）では、本発明は（１）の方法を提供し、パーツは異なる対象デバイスおよび処理環境で別個に動作する異なるイメージ間で共有可能で、デバイス間で通信するデータの量を制限できることを特徴とする。
【０２７３】
別の実施例（２１）では、本発明は（１８）の方法を提供し、パーツは、コード、データ、コンテンツ、手順、コードセット、データセット、コンテンツ、コンテンツセット、パーツを発見し組み合わせる方法に関するメタ情報、記述的テキスト、絵、ビデオ、画像、データの表その他デジタル形式で表現可能な情報の単位または情報のセットのうちの１つである。
【０２７４】
別の実施例（２１）では、本発明は（２１）の方法を提供し、パーツは、ＤａｒｔＰａｒｔｓおよび／またはメタ情報は、Ｄａｒｔ  ＲｅｎｄｉｔｉｏｎｓＴａｂｌｅパーツ、および／またはＤａｒｔ  ＲｅｎｄｉｔｉｏｎＴａｂｌｅパーツおよび／またはＤａｒｔＰａｒｔＴａｂｌｅおよび／またはＤａｒｔＴｒａｉｌｅｒとして表現されることを特徴とする。
【０２７５】
別の実施例（２２）では、本発明は、ソフトウェアアプリケーションを別個に実行可能なイメージのセットにセグメント化する方法を提供し、この方法は、考えられるリソースおよびケイパビリティに従い、遭遇するデバイスをクラスに分けることと、遭遇しそうな環境または動作要件をクラスに分けることと、各クラスのデバイスおよび各環境または動作要件でアプリケーションの意図の１以上の態様を実行できるよう実行可能イメージに必要なデータ、コード、コンテンツおよび／またはその他デジタル表現可能なリソースを指定することと、アプリケーションの意図を実行するために用いる各デバイスで動作するデバイスおよび実行可能イメージを選択するための利用プランを生成することとを含むことを特徴とする。
【０２７６】
別の実施例（２３）では、本発明は、ソフトウェアアプリケーションを別個に実行可能なイメージのセットにセグメント化するための装置を提供し、この装置は、アプリケーションの意図の１以上の態様を実行するため考えられるリソースおよびケイパビリティに従い、遭遇するデバイスをクラスに分けるための手段と、アプリケーションの意図の１以上の態様を実行するため、明確なレンダリングその他ランタイム要件に関するニーズに従って、遭遇しそうな環境または動作要件をクラスに分けるための手段と、デバイスの各クラスおよび各環境または動作要件で、アプリケーションの意図の１以上の態様を実行できるようにするために必要な実行可能イメージに必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定するための手段と、ある候補デバイスのリストで、アプリケーションの意図を実行するのに利用する各デバイスで動作するデバイスと、対応する個々に割り当てられた実行可能イメージと、そのリソースおよびケイパビリティ、必要または所望の環境または動作パラメータを選択するための利用プランを生成するための手段と、各クラスのデバイスおよび各環境または動作要件で利用プランをインプリメントおよび実行するために必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定するための手段とを具えることを特徴とする。
【０２７７】
別の実施例（２４）では、本発明は、コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品を提供し、このコンピュータプログラム製品は、コンピュータリーダブル記憶媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとを具え、コンピュータプログラムメカニズムは、コンピュータシステムまたは情報機器に、コンピュータソフトウェアコードアプリケーションを別個に実行可能なコンピュータプログラムソフトウェアコードイメージのセットにセグメント化するため指定の方法で機能するよう命令するプログラムモジュールを具え、プログラムモジュールは、遭遇するデバイスを、そのリソースおよびケイパビリティに従ってクラスに分ける命令と、遭遇する可能性のある環境または動作要件をクラスに分ける命令と、各デバイスのクラスおよび各環境または動作要件でアプリケーションの意図の１以上の態様を実行できるようにするため実行可能イメージに必要なデータ、コード、コンピュータおよび／またはその他デジタル表現可能なリソースを指定する命令と、アプリケーションの意図を実行するために用いる各デバイスで動作するデバイスおよび実行可能イメージを選択するための利用プランを生成する命令とを含むことを特徴とする。
【０２７８】
別の実施例（２５）では、本発明は、コンピュータシステムまたは情報機器と共に用いるコンピュータプログラム製品を提供し、このコンピュータプログラム製品は、コンピュータリーダブル記憶媒体と、そこに埋め込まれたコンピュータプログラムメカニズムとを具え、コンピュータプログラムメカニズムは、コンピュータシステムまたは情報機器に、コンピュータソフトウェアコードアプリケーションを別個に実行可能なコンピュータプログラムソフトウェアコードイメージのセットにセグメント化するため指定の方法で機能するよう命令するプログラムモジュールを具え、プログラムモジュールは、遭遇するデバイスを、アプリケーションの意図の１以上の態様を実行するためそのリソースおよびケイパビリティに従ってクラスに分ける命令と、アプリケーションの意図の１以上の態様を実行するため明確なレンダリングその他ランタイム要件に関するニーズに従って、遭遇しそうな環境または動作要件をクラスに分けるクラスに分ける命令と、デバイスの各クラスおよび各環境または動作要件で、アプリケーションの意図の１以上の態様を実行できるようにするために必要な実行可能イメージに必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定する命令と、ある候補デバイスのリストで、アプリケーションの意図を実行するのに利用する各デバイスで動作するデバイスと、対応する個々に割り当てられた実行可能イメージと、そのリソースおよびケイパビリティ、必要または所望の環境または動作パラメータを選択するための利用プランを生成する命令と、各クラスのデバイスおよび各環境または動作要件で利用プランをインプリメントおよび実行するために必要なデータ、コード、コンテンツその他デジタル表示可能リソースを指定する命令とを具えることを特徴とする。
【０２７９】
これら実施例およびこの詳細な説明または図面の他の部分に記載する実施例の特徴および／または要素は、様々な方法で組み合わせることができ、上述の実施例が本発明の限定ではなく、特徴および要素の異なる組み合わせまたは置き換えによる追加または代替実施例もまた本発明の実施例である。
ＩＶ．ＤａｒｔＳｏｕｒｃｅ／インタオペラビリティソース
【０２８０】
ＤａｒｔＳｏｕｒｃｅは、パッケージ化されたＤａｒｔインタオペラビリティアプリケーションに必要な全てのプログラムレンディションおよびコードコンテンツおよびデータを指定するための構造および方法を提供することに注意する。ＤａｒｔＳｏｕｒｃｅは、特定のデバイスを対象とする単一実行可能プログラムの指定に共通して用いられる言語構造を、デバイスのチームのインテリジェントなリクルートメントおよびレンディションに必要な手順も指定することのできる言語に拡張し、指定されたアプリケーションの目的のそのデバイスの部分を実行するためにリクルートされた各デバイスで動作するよう送信する好適なレンディションがあるようにするものである。
【０２８１】
一実施例（１）では、本発明は、接続された、または間断的に接続された１以上のデバイスで意図する目的（意図）を実行するために必要なデータ、コードおよびコンテンツの形式のメタ情報と共に、デジタルにコード化されたデータ、コード、コンテンツのソフトウェアアプリケーションパッケージを指定するための方法を提供し、この方法は、（ａ）オブジェクト指向フレームワークまたはライブラリと、（ｂ）１つの実行可能イメージとして表現されるか、実行可能イメージの一体型セットとして表現されるかを問わず、アプリケーションのロジックを実行するために用いられるメインコードおよびデータを表現するためのソースコードと、（ｃ）デジタル表現可能なリソースと、（ｄ）デバイスのネイティブな下層のハードウェアおよびソフトウェアにアプリケーションのロジックを接続するために必要なシステムコールまたは命令呼び出しのうちの１以上またはあらゆる組み合わせを、インタオペラビリティソフトウェアプログラミング言語で表現することとを含むことを特徴とする。
【０２８２】
別の実施例（２）では、本発明は、（１）システムコールまたは命令を用いて、アプリケーションのロジックをデバイスの次のネイティブな下層のハードウェアおよびソフトウェアの１以上に接続する方法で、（ａ）ソフトウェアエンジンと、（ｂ）ソフトウェアオペレーティングシステムと、（ｃ）通信サブシステムと、（ｄ）グラフィックサブシステムと、（ｅ）暗号サブシステムと、（ｆ）セキュリティサブシステムと、（ｇ）記憶、オーディオレンダリング、および／または入出力サブシステムと、（ｈ）本来のコード表現のアルゴリズムまたは手順と、（ｉ）媒体圧縮および／または解凍サブシステムと、（ｊ）データ処理またはデータベース処理と、（ｋ）デバイスのリソース、コンテンツおよびケイパビリティに関する情報を取り出すためのデバイス固有プロフィール情報と、（ｌ）デバイス間でアプリケーションの同期および非同期オペレーションを駆動するイベント待ち行列と関連するイベント待ち行列管理サブシステムと、（ｍ）ユーザインターフェース、テキスト、オーディオ、ビデオその他トランスコードまたはレンダリングオペレーションおよび／または一般的コンピュテーションオペレーションおよび／または一般的データベースオペレーションと、（ｎ）１以上の協働デバイス内および／または間でソフトウェア、データ、コンテンツおよび状態の共有および協働オペレーションを駆動するイベントの利用を通じた間断接続のパワーマネージメント、中断／再開および／またはアプリケーションレベルのエラー復元と、（ｏ）物理的ストレージまたは他の接続されたデバイスとの間で、パーツ、パーツのパッケージ、手順、実行可能イメージまたは実行可能イメージのパッケージをダイナミックに保存、構成、最適化および／または送信するためのサブシステムと、（ｐ）これらの組み合わせである。
【０２８３】
別の実施例（３）では、本発明は（１）の方法を提供し、フレームワークまたはライブラリおよび／またはソースコードは、（ａ）から（ｐ）に一覧されたネイティブな下層のアクセス可能な１以上のソフトウェアまたはハードウェアを実行、カプセル化、アクセス指令および／または整理するためのクラス定義およびオブジェクトインプリメンテーションを含むことを特徴とする。
【０２８４】
別の実施例（４）では、本発明は（１）の方法を提供し、フレームワークまたはライブラリおよび／またはソースコードは、１以上の協働デバイス上またはその間でイベント駆動実行に用いる固有ランタイム規約に準拠する基礎を提供するためのクラス定義およびオブジェクトインプリメンテーションを含むことを特徴とする。
【０２８５】
別の実施例（５）では、本発明は（１）の方法を提供し、フレームワークまたはライブラリおよび／またはソースコードは、配信され、協働デバイスのセットで実行されるソフトウェアアプリケーションのパーツ間でイベントの処理を直列化することにより、デバイス間で、実行可能および同期オペレーション内でのイベントの同期処理を確保するためのクラス定義およびオブジェクトインプリメンテーションを含むことを特徴とする。
Ｖ．ＤａｒｔＦｒａｍｅｗｏｒｋ／インタオペラビリティフレームワーク
【０２８６】
ＤａｒｔＦｒａｍｅｗｏｒｋは、プログラマが、ＤａｒｔＰｌａｔｆｏｒｍの有利な機能の多くへのアクセスをカプセル化したインタオペラビリティアプリケーションを構築する際に用いるＤａｒｔＳｏｕｒｃｅの一部である、プログラマがＤａｒｔＰｌａｔｆｏｒｍの所望のインタオペラビリティ機能の多くを理解しインプリメンとする必要をなくす。特定のＤａｒｔＦｒａｍｅｗｏｒｋの態様を含むインタオペラビリティＦｒａｍｅｗｏｒｋの追加態様についても、本説明のリニアタスキングセクションに関連して述べる。
【０２８７】
一実施例（１）では、本発明は、イベント駆動ソフトウェアアプリケーションパッケージのソース使用の一部として用いるオブジェクト指向のクラス定義のセットを有するオブジェクト指向のインタオペラビリティフレームワークと、そのインプリメンテーションコードとを指定する方法を提供し、この方法は、（ｉ）少なくとも次のデータとコードメンバーを含むベースイベント処理クラスとしてオブジェクト指向言語を用いることを指定することで、（ａ）パラメータとして、イベントデータ構造のインスタンスの参照またはコピーをとるプロセスメンバーと、（ｂ）同じベースクラスを有する他のイベント処理オブジェクトへの参照またはこのインスタンスの順序付けたリストメンバーであるものと、（ｉｉ）ソースコードにクラス指定のメンバーと方法とをインプリメントすることとを含むことを特徴とする。
【０２８８】
別の実施例（２）では、本発明は（１）の方法を提供し、ソフトウェアアプリケーションパッケージは、１以上の接続された、または間断的に接続されたデバイス上で意図する目的（意図）を実行するため設計およびインプリメントされることを特徴とする。
【０２８９】
別の実施例（３）では、本発明は（２）の方法を提供し、ソフトウェアアプリケーションパッケージは、ＤａｒｔＦｏｒｍａｔに従うことを特徴とする。
【０２９０】
別の実施例（４）では、本発明は（１）の方法を提供し、ベースクラスは、ＤａｒｔＧｉｚｍｏクラスであることを特徴とする。
【０２９１】
別の実施例（５）では、本発明は（１）の方法を提供し、ベースクラスの継承インスタンスのツリーの根として動作するベースクラスから継承したレンディションクラスもあり、プロセスメンバーのパラメータは、任意で空またはＮＵＬＬ参照であることを特徴とする。
【０２９２】
別の実施例（６）では、本発明は（５）の方法を提供し、レンディションクラスを用いて、オブジェクト指向インタオペラビリティフレームワークを利用してソースコードから生成する出力パッケージに埋め込む別個に実行可能なイメージの実行のための開始エントリポイントを意味することを特徴とする。
ＶＩ．ＤａｒｔＴｏｏｌｓ／インタオペラビリティツール
【０２９３】
ＤａｒｔＴｏｏｌｓは、ＤａｒｔＳｏｕｒｃｅアプリケーション指定をＤａｒｔアプリケーションパッケージに処理することに注意する。
【０２９４】
一実施例（１）では、本発明は、デジタルコード化情報のインタオペラビリティソフトウェアアプリケーションパッケージを、１以上の接続された、または間断的に接続されたデバイス上で意図する目的（意図）を実行するために必要なメタ情報と共に生成するための方法を提供し、この方法は、インタオペラビリティコンパイラプロセス［ソフトウェア製品］を通じてオブジェクトファイルを生成するためのソース材料の処理と、ライブラリまたはインタオペラビリティソフトウェアアプリケーションパッケージを生成するためのインタオペラビリティリンカプロセスを通じてオブジェクトファイルおよび任意のライブラリを処理することとを含むことを特徴とする。
【０２９５】
別の実施例（２）では、本発明は（１）の方法を提供し、デジタルコード化された情報は、コード化されたデータ、コードおよび／またはコンテンツを含み、メタ情報は、コントロール、データ、コードおよび／またはコンテンツの形式のメタ情報を含むことを特徴とする。
【０２９６】
別の実施例（３）では、本発明は（１）の方法を提供し、インタオペラビリティコンパイラプロセスは、コンパイラコンピュータプログラムソフトウェア製品としてインプリメントされ、リンカプロセスは、リンカコンピュータプログラムソフトウェア製品としてインプリメントされることを特徴とする。
【０２９７】
別の実施例（４）では、本発明は（１）の方法を提供し、ソース材料は、インタオペラビリティソース方法に従ってアセンブルされることを特徴とする。
ＶＩＩ．ＤａｒｔＦｏｒｍａｔ／インタオペラビリティフォーマット
【０２９８】
ＤａｒｔＦｏｒｍａｔは、インタオペラビリティアプリケーションに必要な全てのコード、データおよびコンテンツをカプセル化するＤａｒｔフォーマットパッケージをまとめるための構造およびルールを含み、これによりアプリケーションをＤａｒｔＤｅｖｉｃｅにロードして動作させることが可能で、ＤａｒｔＰｌａｙｅｒを含むことに注意する。
【０２９９】
一実施例（１）では、本発明は、インタオペラビリティフォーマットのデジタルコード化されたデータ、コードおよびコンテンツと、接続された、または間断的に接続された１以上のデバイス上で意図する目的（意図）を実行するために必要なデータ、コードおよびコンテンツの形式のメタ情報とに準拠するソフトウェアアプリケーションパッケージを保存するための方法で、この方法は、少なくとも１つの線形に連続するバイナリコード化されたパーツイメージを形成することと、アプリケーションパッケージの一部として識別、ロード、選択、特定、実行または処理に用いられるバイナリコード化されたリソースまたはプログラム要素の組み合わせを含む、必要なあらゆる線形連続パーツイメージを形成することと、パーツイメージを決定的に位置決めし、独立して実行可能なイメージを識別、ロード、実行する形式でパーツおよびメタ情報を共にパッケージ化することとを含むことを特徴とする。
【０３００】
別の実施例（２）では、本発明は（１）の方法を提供し、少なくとも１つの線形連続バイナリコード化パーツイメージは、独立して実行可能なイメージのそれぞれについてメインコード、メインデータ、レコードの記録と、独立して実行可能な特定のイメージに属するパーツのそれぞれについてのレコードのテーブルのうち少なくとも１つを含むことを特徴とする。
【０３０１】
別の実施例（３）では、本発明は（１）の方法を提供し、少なくとも１つの線形連続バイナリコード化パーツイメージは、独立して実行可能なイメージのそれぞれについてメインコード、メインデータ、レコードの記録と、独立して実行可能な特定のイメージに属するパーツのそれぞれについてのレコードのテーブルのそれぞれを含むことを特徴とする。
【０３０２】
別の実施例（４）では、本発明は（１）の方法を提供し、必要な線形連続パーツイメージは任意で、次からなるセットから選択したあらゆる数の組み合わせを含み、（ａ）プログラム、Ｄａｒｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅｓまたは手順と、（ｂ）写真、ビデオ、画像、オーディオ、サウンドその他レンダリング可能なメディアと、（ｃ）データ構造インスタンス、リストおよび／またはパラメータと、（ｄ）データのリストまたはデータのテーブルと、（ｅ）これらの組み合わせとからなる。
【０３０３】
別の実施例（５）では、本発明は（１）の方法を提供し、メタ情報の形成は、少なくとも次の１つのめた情報の形成を含み、（ａ）その識別子でパーツを探すテーブルと、（ｂ）パーツのテーブルを探すために用いる第１の情報と、（ｃ）線形連続パーツイメージのロードおよび実行に必要な第２の情報と、（ｄ）独立して実行可能なイメージのリストを探すために用いる第３の情報とを含むことを特徴とする。
【０３０４】
別の実施例（６）では、本発明は（１）の方法を提供し、次の線形連続バイナリコード化パーツイメージの１以上も形成し、（ｉ）手順、Ｄａｒｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅｓと、（ｉｉ）写真、オーディオ、ビデオその他マルチメディアコンテンツまたは動画を含むコンテンツアイテムのセットから選択したコンテンツを含むコンテンツと、（ｉｉｉ）データベースと、（ｉｖ）インデックスと、（ｖ）リストアイテムまたはテーブルアイテムのパラメータと、（ｖｉ）バーチャルポインタデータと、（ｖｉｉ）アプリケーションヒープデータと、（ｖｉｉｉ）連続バイナリデータイメージとしての他に表現可能なあらゆるものとからなる。
【０３０５】
別の実施例（７）では、本発明は（１）の方法を提供し、次のメタ情報のうち１以上も形成し、（ｉ）署名情報と、（ｉｉ）ソフトウェアアプリケーションパッケージの名称、タイプ、コンテンツまたは利用法を識別するためアクセスするキーワードその他情報と、（ｉｉｉ）リストアイテムまたはテーブルアイテムのパラメータと、（ｉｖ）バーチャルポインタパラメータと、（ｖ）セキュリティチェックサムおよび／または署名および／または証明書またはハッシュと、（ｖｉ）一意の識別子とからなる。
【０３０６】
別の実施例（８）では、本発明は（１）の方法を提供し、インタオペラビリティコンパイラ、インタオペラビリティリンカおよび／またはインタオペラビリティマスタプレイヤに埋め込まれたツールによってステップが実行されることを特徴とする。
ＶＩＩＩ．ＤａｒｔＲｕｎｔｉｍｅ／インタオペラビリティランタイム
【０３０７】
別の態様では、本発明は、Ｄａｒｔかデバイス制御関連かを問わず、全てのソフトウェアオペレーションについて、大幅にイベント駆動で、実施例によっては完全なイベント駆動であるソフトウェアランタイムモデル（ＤａｒｔＲｕｎｔｉｍｅモデルなど）を提供する。アプリケーションと低レベルデバイス制御ソフトウェアの両方に共通するイベントセマンティックス、タイプ、構造およびオペレーションのセットが、相互運用デバイス（図１７、６６０）のチームの各相互運用デバイス上に動作する１つのイベント待ち行列によって与えられ、同期アプリケーションイベント処理および非同期アプリケーション、デバイス、通信およびインタオペラビリティオペレーションのシーケンスを駆動する。また、イベントの待ち行列、待ち行列解除、処理の管理に用いる命令セットまたはシステムコールが与えられる。デバイス間の通信を維持し、エラー補正し、必要な場合は、協力によって再確立される任意の堅牢なデバイス相互運用通信ランタイムモデルが与えられるが、相互運用デバイスのチーム間で有効に動作するＤａｒｔｓに対する混乱はほんのわずかかまったくない（図１９参照）。このような機能は、任意で別個に生成したＤａｒｔｓおよび／または他のデバイスに拡張できる。
【０３０８】
ＤａｒｔＲｕｎｔｉｍｅの他の態様は、以下の例および例示的実施例を含む本書の他の場所で説明する。
【０３０９】
一実施例（１）では、本発明は、デジタルコード化データ、コードおよびコンテンツと、接続された、または間断的に接続された１以上のデバイス上で意図する目的（意図）を実行するために必要なデータ、コードおよびコンテンツの形式のメタ情報とのイベント駆動ソフトウェアアプリケーションパッケージを実行するためのインタオペラビリティランタイムシステムのための方法を提供し、この方法は、（ａ）独立して実行可能なイメージのあるパッケージから別個に実行可能なイメージを選択およびロードすることと、（ｂ）イメージを実行することにより、デバイスをチームにリクルートすることと、（ｃ）リクルートされたデバイスのチームの中でコード、レンディション、データおよび／またはコンテンツのうち少なくとも１つを配信することと、（ｄ）意図を実行するため同期および非同期イベントを順序だった方法で処理することと、（ｅ）リクルートされたデバイスのチームのデバイス内およびデバイス間でイベント処理を同期および直列化することと、（ｆ）データと状態のストレージへの保存を含み、別個に実行可能なイメージのパッケージを保存することとを含むことを特徴とする。
【０３１０】
別の実施例（２）では、（１）の方法が提供され、（ａ）独立して実行可能なあるイメージのパッケージから別個に実行可能なイメージを選択およびロードすることは、独立して実行可能なイメージのあるパッケージから特に別個に実行可能なイメージを選択およびロードすることであることを特徴とする。
【０３１１】
別の実施例（３）では、（１）の方法が提供され、ランタイムはＤａｒｔＲｕｎｔｉｍｅであることを特徴とする。
【０３１２】
別の実施例（４）では、（１）の方法が提供され、選択およびロード、リクルート、配信、処理および同期と再直列化は、リクルートメント手順に従って実行されることを特徴とする。
ＩＸ．  リニアタスキング
【０３１３】
本発明の別の態様では、リニアタスキングのためのシステム、装置、方法およびコンピュータプログラムが提供される。リニアタスキングは、処理ユニット間のプロセッサコントロールおよびデバイスリソースの単純な決定性フローを可能にする方法を含む。処理ユニットは、アプリケーション、別個にコンパイルされたアプリケーション、他のデバイスで動作するアプリケーションにまでコンパイルする処理ユニットを含む単一の階層に容易に再構成することができる。
【０３１４】
リニアタスキングモデルの利点は、インタオペラビリティアプリケーションのほとんどが個々のユーザを対象としているため、これらに特に適している点である。ここで、人間の応答時間ニーズは、一般に３０分の１秒以上に限られているため、各処理ユニットにコントロールをパスしなければならないランタイムのペナルティは重要ではない。
【０３１５】
発明のリニアタスキングモデルおよび方法には多くの利点があるが、その一部についてのみ記載し、残りは本書のさらなる説明から明らかになる。
【０３１６】
第１の利点は、チーム化された全てのデバイスの全処理ユニットの処理順の決定的またはほぼ決定的な経路であり、オペレーションがうまく制御されたパターンで実行される順序に限定できるため、プログラミングモデルが単純になり、バグが大幅に減ることである。
【０３１７】
第２に、時間が中断されたり、割り込みプロセスのアクションに影響されたりすることなく、全ての処理ユニットが複雑なオペレーションのシーケンスを完了できる。
【０３１８】
第３に、制御されたシャットダウン、制御された休止および復元と有利なバーチカルレイヤリングメカニズムに容易に対応するため、かかるアプリケーションをパワーマネージメントとして用いること等ができる。
【０３１９】
第４に、階層の配置および再配置は、オペレーションやユーザとのインタラクションのモードの変更に応じて、処理ユニットのグループを使用可能または使用禁止にする少なくとも１つの容易な方法である。
【０３２０】
第５に、子の処理ユニットがビットマップや時間の感知等の環境の制御等、親ユニットの出力の使い方がわかるコードを含む必要ないがい方法で、親処理ユニットによって環境の継承や変更、変形が可能である。
【０３２１】
第６に、別個に生産した実行可能を、動作中の実行可能の処理階層に容易に同化できる。ＤａｒｔＰｌａｔｆｏｒｍでは、この機能によって、Ｄａｒｔｓは利用中、他のＤａｒｔｓをそのランタイムに同化することができる。例えば、前述のスライドショー（ＳｌｉｄｅＳｈｏｗ）Ｄａｒｔアプリケーションを容易に組み込み、静止ＪＰＥＧ画像をスライドとして集めるのと同じくらい容易に、別個に生成したＤａｒｔｓをスライドとして集め、収納することができる。ＪＰＥＧ画像は静止画像表示Ｇｉｚｍｏ（Ｇｉｚｍｏは、イベント処理ユニットのベースコール）に含まれる一方、ＤａｒｔはＤａｒｔ含有Ｇｉｚｍｏに含まれることになる。
【０３２２】
一実施例では、リニアタスキングは、Ｄａｒｔフレームワーク（ＤａｒｔＦｒａｍｅｗｏｒｋ、図１１）からＤａｒｔランタイム（ＤａｒｔＲｕｎｔｉｍｅ、図９、図１６、図１７）、Ｄａｒｔエンジン（ＤａｒｔＥｎｇｉｎｅ、図２２、６００）およびＤａｒｔ命令セットの命令（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ、図２０、図２５）へ、Ｄａｒｔプラットフォーム（ＤａｒｔＰｌａｔｆｏｒｍ、図３）のインプリメンテーションを通じて有利に具体化される。他の実施例は、完全なＤａｒｔインフラの利点のある代替インプリメンテーションと共にリニアタスキングを利用することができる。
【０３２３】
一実施例では、本発明のリニアタスキングは、ソフトウェアアプリケーションプログラムの複数の処理ユニットの実行およびランタイム環境を決定的に順序付ける方法を提供する。ソフトウェアまたはファームウェアプログラムイベント駆動ランタイムモデルは、処理ユニット間のリンケージに基づく所定の順序で全ての処理ユニットを実行する環境を提供または生成する。ソフトウェアのオブジェクト指向フレームワーク、ＤａｒｔＦｒａｍｅｗｏｒｋ（図１１）を設け、これには、あらゆる組み合わせでの次のオブジェクトメンバー（図１１、１１５）の少なくとも１つおよび可能な場合は全てを含むベース処理ユニットクラス（図１１のＧｉｚｍｏ、１１５）がある：
（ａ）親処理ユニットのヌルの可能性のある参照；
（ｂ）子処理ユニットの参照の空の可能性のある順序付けたリニアリスト；
（ｃ）この処理ユニットの作用するイベントタイプのクラスに対応する任意でバイナリのフラッグ；
（ｃ）子がいなくなるまで親および子処理のチェーンを下り、子処理ユニットのいずれかの作用するイベントタイプのクラスに対応する任意でバイナリのフラッグ；
（ｄ）親および子処理ユニットの参照を追加、削除または再順序付けするための手順的方法；
（ｅ）イベントの処理の順序付けのための手順的方法。
【０３２４】
少なくとも一実施例では、イベント処理を順序付けるための手順的方法は、次のステップを含む（図１５参照）：
（１）イベントタイプ、その値および処理ユニットのタスクの参照とイベントが指定する現在のランタイム環境、デバイスの親および状態に基づき、必要なイベントのプレチルドレンの処理を実行する（図１５、８００４参照）；
（２）子の処理ユニットチェーンの作用するイベントタイプのクラスに対応する任意のフラッグを設定して、作用するイベントタイプがないことを示す；
（３）各個の処理に必要な環境変更をセットアップし、子の処理ユニットの参照のリスト順に各子を呼び出す（図１５、８００５参照）；
（４）各コールが、呼び出された子が処理するために必要な処理タイプの論理的ＯＲバイナリフラッグを返す；
（５）イベントタイプ、その値および参照、処理ユニットのタスクおよびイベントンが指定する現在のランタイム環境、デバイスの親と状態に基づき、イベントのポストチルドレン処理を実行する（図１５の８００４参照）；
（６）将来この処理ユニットが取り扱うイベントタイプのフラッグを設定する；
（７）参照が非ヌルの場合、親処理ユニットにコントロールを返す（図１５、８００６を参照）；
（８）親がヌルの場合メイン処理ループにコントロールを返す（図１５、８００８）。
【０３２５】
フラッグを用いて、各子およびその全ての子孫が処理するために必要でないイベントタイプを示すことができるため、集めたバイナリフラッグを任意で用いて、コールの刈り込みができる。フラッグが関連するイベントタイプ分類に対応する子の順序付けフラッグ値が１でない場合、子とその子孫はイベントを処理する必要はない。
【０３２６】
リニアタスキングの他の実施例を説明する。一実施例（１）では、本発明は、ソフトウェアアプリケーションパッケージの複数のイベント処理ユニットのイベント駆動実行およびランタイム環境の順序付けと管理のためのリニアタスキングの方法を提供し、この方法は、ベースイベント処理ユニットクラスを含むソフトウェアのオブジェクト指向フレームワークと、ベースイベント処理ユニットクラスから直接または間接的に継承する０以上の処理ユニットクラスとを設けることと、リンクによって形成された処理ユニットのグラフをイベントが通過するため常に単一線形の決定的順序付けがあるような方法で、イベント処理ユニットのグラフまたはトポロジーを形成するリンクを生成、維持、追加、削除または再順序付けすることと、動作中アプリケーションのニーズに従って、処理ユニットのグラフまたはトポロジーをダイナミックに変更することとを含むことを特徴とする。
【０３２７】
別の実施例（２）では、本発明はリニアタスキング（１）の方法を提供し、グラフは１以上のアプリケーションパッケージまたはそれ自体が１以上のほかのアプリケーションパッケージの一部であるアプリケーションパッケージ内で参照により静的に別個生成されたアプリケーションパッケージのグラフを含むよう論理的に拡張されることを特徴とする。
【０３２８】
別の実施例（３）では、本発明は（１）の方法を提供し、グラフは、アプリケーションパッケージの動作中、別個に生成されたアプリケーションパッケージのグラフをダイナミックに含むよう論理的に拡張されることを特徴とする。
【０３２９】
別の実施例（４）では、本発明は（２）の方法を提供し、別個に生成されたアプリケーションパッケージのグラフの最上ノードにあるイベント処理ユニットは、イベント処理方法にパスされたパラメータによって、それが論理的に拡張されたグラフの一部であるか、他のアプリケーションパッケージによって拡張されていない、実際には最上位アプリケーションパッケージの起点であるかを判断することを特徴とする。
【０３３０】
別の実施例（５）では、本発明は（３）の方法を提供し、別個に生成されたアプリケーションパッケージのグラフの最上位ノードにあるイベント処理ユニットは、イベント処理方法にパスされたパラメータによって、それが論理的に拡張されたグラフの一部であるか、他のアプリケーションパッケージによって拡張されていない、実際には最上位アプリケーションパッケージの起点であるかを判断することを特徴とする。
【０３３１】
別の実施例（６）では、本発明は（４）の方法を提供し、パラメータが処理するイベントを指定しない場合のみ、最上位ノードが自分自身で処理するためイベントの待ち行列からイベントその他グラフの線形順のイベント処理ユニットを明示的に取り出そうとすることを特徴とする。
【０３３２】
別の実施例（７）では、本発明は（５）の方法を提供し、パラメータが処理するイベントを指定しない場合のみ、最上位ノードが自分自身で処理するためイベントの待ち行列からイベントその他グラフの線形順のイベント処理ユニットを明示的に取り出そうとすることを特徴とする。
Ｘ．バーチカルレイヤリング
【０３３３】
本発明の別の実施例では、バーチカルレイヤリングのシステム、装置、方法およびコンピュータプログラムが提供される。バーチカルレイヤリングは、生来、ツール、アプリケーションフレームワーク、エンジン、レンディションおよび命令セットインプリメンテーション、オペレーションの間で緊密に協力する機能の効率的かつ効果的なインプリメンテーションを可能にする。
【０３３４】
本発明のバーチカルレイヤリングは当業の現状である従来の水平レイヤリングに代わるもので、プログラミングツール、アプリケーション、プレイヤ、ランタイム、オペレーティングシステムおよび／または低レベル機能が全体でデータ構造と通信構文を共有できる場合、有利に採用することができる。
【０３３５】
一実施例では、バーチカルレイヤリングは、ＤａｒｔＰｌａｔｆｏｒｍのインプリメンテーションを通じて任意に、しかし有利に具体化される（図３）。ＤａｒｔＰｌａｔｆｏｒｍにバーチカルレイヤリングを有利に採用できる箇所の２つの例は、パワーマネージメントとアプリケーションレベルのエラー復元である（図１９）。
【０３３６】
例えば、パワーマネージメント機能は、最下位レベルで検出された入力または出力アクティビティに基づき、経験則を用いて従来のデバイスに多くインプリメントされるが、１／３０秒でビデオの次のコマをデコードする処理にコントロールを返さなければならないか、ユーザが何かするまで次の処理の要件はないかが本当にわかるのはアプリケーション自身のみである。
【０３３７】
本発明の有利な一実施例では、ダートプラットフォーム（ＤａｒｔＰｌａｔｆｏｒｍ）は、Ｄａｒｔランタイム（ＤａｒｔＲｕｎｔｉｍｅ）がＧｉｚｍｏと呼ばれるイベント処理ユニットの単一階層リニアタスキングを通過する際、プロセッサ応答要件を収集する（図１１、図１５）。ＤａｒｔＲｕｎｔｉｍｅのデバイス内パーツをそれぞれ通過した後（図１５）、Ｄａｒｔが構築されたら常に、Ｇｉｚｍｏベースの処理ユニットのＤａｒｔフレームワーク（ＤａｒｔＦｒａｍｅｗｏｒｋ）階層を用いて（図１１）、ＤａｒｔＰｌａｔｆｏｒｍは最小同期Ｇｉｚｍｏツリー応答時間要件（図１５、８０１０）と、デバイスエンジン（ＤａｒｔＥｎｇｉｎｅ，図２２、６００）のイベント待ち行列の非同期イベント時間要件（ＥｖｅｎｔＱｕｅｕｅ、図２２、６６０）を組み合わせ、ＤａｒｔＰｌａｙｅｒにコントロールを返す前に、デバイスがパワーダウン、またはパワーレベルや消費量を削減できる正確で信頼できる時間量を決定する。プロセッサの論理クロックの削減、論理または電源電圧レベルの削減、大型回路部分のパワーダウン等パワーマネージメントの方法は当業で周知である。例えば、前述のインタオペラビリティスライドショーのＤａｒｔアプリケーションを考える。発信デバイスで動作するこのアプリケーションは、各接続および各デバイスでの効率的な送信と表示のため任意で縮尺あるいは適合されていたとしても、チームの各デバイスが発信アプリケーションと同じスライドを表示する、例えば５つのデバイスのチームを、リクルートメントを通じて結成することができる。無線接続のデバイスが圏外になった時、またはポータブルデバイスがバッテリの寿命をセーブするため自動的にシャットダウンした場合にどうなるか。従来のインプリメンテーションでは、このデバイスが突然圏内に戻ったり、電源が戻ったりした場合に、復元方法を知っているのはスライドショー（ＳｌｉｄｅＳｈｏｗ）アプリケーションのみである（図１９の例参照）。非発信デバイスの電源が切れたり、スライドショーのデータや状態を完全に失ったりした場合は特に、従来の水平レイヤデバイスがシームレスに復元できるようにするためには全てのレベルで大量のプログラミングが必要になる。これは、失われた接続を検出する低レベルルーチンからアプリケーションまで全てのレベルで必要な構文を従来のソフトウェアエコシステムが水平抽象化に組み込んでいないためである。情報が、アプリケーションから低レベルの通信システムまで流れて戻る直接的なメカニズムがなければ、接続を回復したデバイスにデータと状態情報を自動的に再送するようアプリケーションに書き込むことは難しい。
【０３３８】
ＤａｒｔＰｌａｔｆｏｒｍで採用されるバーチカルレイヤリングでは、接続が失われた時、デバイスのチームにアプリケーションを復元するアプリケーションデータおよび手順を再送することは、ＤａｒｔＦｒａｍｅｗｏｒｋ、ＤａｒｔＲｕｎｔｉｍｅおよびＤａｒｔＥｎｇｉｎｅを通じてアプリケーションに組み込まれている。そのため、ＤａｒｔＦｒａｍｅｗｏｒｋを用いて組み込まれ、ＤａｒｔＰｌａｙｅｒ上で動作するアプリケーションはどれも、堅牢なマルチデバイスアプリケーションおよびデータ同期復元のための特殊なプログラミングを必要としない。
【０３３９】
Ｄａｒｔ  Ｐｌａｔｆｏｒｍの一実施例では、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔで動作しているＤａｒｔアプリケーションと、通信を渡すネイティブなコードとの間で直接ＤａｒｔＥｖｅｎｔｓをパスすることにより、伝統的な低レベルオペレーション（例えば、通信等）が伝統的な高レベルオペレーション（例えば、アプリケーション等）と直接相互運用する。
【０３４０】
ＤａｒｔＴｏｏｌｓ（図３、２００、図１２、２００）、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ、ＤａｒｔＲｕｎｔｉｍｅ（図９、図１５、図１６、図１７）およびリニアタスキング（図１８）は全て、ＤａｒｔＥｎｇｉｎｅ内部の通信機能と正確に同じ（または実質的に同じ）構造およびセマンティックスでアプリケーションがＤａｒｔＥｖｅｎｔｓを形成および処理する、抽象化層を大きく欠いた環境を提供するよう設計されている。そのため、アプリケーションは、コンポーネントがアプリケーションの一部であるか、エンジンがアプリケーションを実行しているか、アプリケーションの相互運用パーツがデバイスのチームを通じて配信されているかを問わず、各レベルで相互運用システムのほぼ全てのコンポーネントが理解するＥｖｅｎｔｓのパスおよび処理を通じて、ＤａｒｔＰｌａｔｆｏｒｍに一部であるほかの全てのソフトウェアアプリケーションとそのニーズやステータスを容易かつ効果的に収集、同期および通信することができる。
【０３４１】
一実施例では、バーチカルレイヤは、低複雑性、低処理要件、少ないアプリケーションプログラムインターフェース、少ないプロトコルインターフェースでアプリケーションとデバイス制御ソフトウェアとの間で高レベルの協力機能を形成するため、ソフトウェアアプリケーションとデバイス制御ソフトウェアのアプリケーションを緊密に連結するシステム、方法およびコンピュータプログラムを提供する。関連するアプリケーションやデバイス制御に関わらず、全てのソフトウェアオペレーションのイベント駆動のソフトウェアランタイムモデル、イベントセマンティックス、タイプ、構造およびアプリケーションと低レベルデバイス制御ソフトウェアに共通するイベント上のオペレーションのセットを提供する。同期アプリケーションイベント処理および非同期アプリケーション、デバイス、通信およびインタオペラビリティオペレーションのシーケンシングを駆動するイベント待ち行列もまた提供される。バーチカルレイヤリングアプローチは、イベントの待ち行列、待ち行列解除および処理の管理に用いる命令セットまたはシステムコールも提供する。任意の堅牢なデバイスインタオペラビリティ通信ランタイムモデルも提供され、デバイス間の通信が維持、エラー補正され、必要に応じて協力によって再確立されるが、相互運用デバイスのチーム間で有効に動作するアプリケーションへの影響は少量である。協調的デバイスチームを通過するイベントの直列化および同期のシステムは、非同期オペレーションの相互運用システムの全コンポーネントを緊密に連結し続けるために有利に適用され、これにより、信頼性の高い、インプリメントの単純な、効率的で使いやすいものとする。
【０３４２】
別の実施例では、本発明は、ソフトウェアアプリケーションのオペレーションとデバイスまたは通信中のデバイスのセット上のデバイス制御ソフトウェアオペレーションを直接接続し、１デバイスか、１以上の協働デバイス間かを問わず、ソフトウェアオペレーション間に高度に効率的かつ柔軟な協力的機能性を育てる方法、コンピュータプログラム、ソフトウェア、デバイスおよびシステムを提供する。これは、ソースコードおよびリソース、ソフトウェアツール、予めパッケージされるか、予め指定されたソフトウェアフレームワークまたはライブラリ、イベント駆動ランタイム、命令セットまたはシステムセットで、各デバイス上のイベントの待ち行列を管理するものを含むことができる。少なくとも１つの実施例では、正確に１つのイベントの待ち行列をこの目的のために各デバイスで管理する。
【０３４３】
アプリケーションは、Ｄａｒｔでよく、デバイス制御ソフトウェアは、ＤａｒｔＥｎｇｉｎｅまたはＤａｒｔＰｌａｙｅｒでよい。一部実施例では、デバイスのセットは、本書で説明するリクルートメントを用いるか、デバイスのチームをリクルートする別の方法によってセットアップしたチームであるか、これを含む。一実施例では、ソフトウェアフレームワークは、ＤａｒｔＦｒａｍｅｗｏｒｋである。一実施例では、イベント駆動ランタイムは、ＤａｒｔＲｕｎｔｉｍｅである。一実施例では、ソースコードおよびリソースは、ＤａｒｔＳｏｕｒｃｅソースコードで、ソフトウェアツールはＤａｒｔＴｏｏｌｓである。一実施例では、命令セットおよびシステムコールは、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔおよび／またはＤａｒｔ  ＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮ（図２０、６７０、６７１、６７２、６７３）および／またはＯＥＭ＿ＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮ（図２０、６７４、６８０、６８１、６８２参照）などの内蔵命令タイプ命令の一部として呼び出すことができる機能である。
【０３４４】
少なくとも一実施例では、デバイスのシステム（図１７、８００）、アプリケーション、通信コードの中で情報および／またはコンテンツおよび／またはステータスを通信するために用いる共通に理解されるセマンティックスのシングルデータ構造を有することで少なくとも部分的に効率が達成される
【０３４５】
少なくとも一実施例では、シングルデータ構造として例えばＤａｒｔＥｖｅｎｔｓ（図１７、８００）などのイベントが用いられる。
【０３４６】
少なくとも一実施例では、デバイス制御ソフトウェアオペレーションは、通信、デバイス構成管理、デバイス発見、管理割り当て、管理解除およびメモリ、物理的ストレージ、物理的ディスプレイ、物理的入力／出力デバイス、またはデバイスのその他物理的またはソフトウェアヴァーチャル化の物理的態様へのアクセスを含む。
【０３４７】
一実施例では、ソフトウェアツールは、予め指定されたソフトウェアフレームワークを用いるため書かれたソフトウェアソースコードおよびリソースを取り、イベントの待ち行列化、処理、行列解除の管理に用いる命令セットまたはシステムコールのセットにアクセスすることによりサポートされるイベント駆動のランタイム実行モデルに準拠させる。
【０３４８】
少なくとも一実施例では、アプリケーションのイベント処理は、図１５、図９、図１６、図１７に示し、説明される。少なくとも一実施例では、デバイスの待ち行列に入れられるイベントは、直列化および同期される。直列化と同期は、図９に示す直列化および同期方法に従って実行される。
【０３４９】
バーチカルレイヤリングの一態様を含む特定の実施例をここで説明する。一実施例（１）では、本発明は、手順的（ソフトウェア）コンポーネント間のオペレーションの調整およびデータ移動のためのイベント駆動バーチカルレイヤリングシステムを提供し、１以上のチーム化されたデバイス内またはその間でのアプリケーションレベルオペレーション、デバイスハードウェア制御レベルオペレーション、通信レベルオペレーションその他オペレーションのレベルまたはサブセットを実行し、手順的（ソフトウェア）コンポーネント間の効率的および／または堅牢な協力機能を確立するもので、このシステムは、（ａ）１以上のデバイスおよび１以上のデバイスで動作する手順的（ソフトウェア）コンポーネントのすべてのイベント生成および処理ユニット間で、そのフィールドおよびフィールドセマンティックスが一般的に知られ、理解される静的イベントデータ構造と、（ｂ）イベントデータ構造インスタンスへのアクセスを保存、削除、管理および制御するチーム化された各デバイス上の待ち行列と、（ｃ）すべての手順的（ソフトウェア）コンポーネントからアクセス可能な待ち行列上のイベントの設置、修正および削除を管理するための手段と、（ｄ）協働デバイスの待ち行列の間で直列化および同期されるイベントタイプの共通リストの指定と維持のための手段と、（ｅ）どの手順的（ソフトウェア）コンポーネントがイベントを開始したか、チーム化されたデバイスのどれで、イベントを開始した手順的（ソフトウェア）コンポーネントが動作しているかを問わず、共通リスト上のあらゆるタイプのすべてのイベントが、全デバイスで正確に同じ順序で、手順的（ソフトウェア）コンポーネントによって処理されるようにするための手段とを備えることを特徴とする。
【０３５０】
別の実施例（２）では、本発明は（１）のシステムを提供し、イベントデータ構造インスタンスへのアクセスを保存、削除、管理および制御するチーム化された各デバイス上の待ち行列は、チーム化された各デバイスの正確に１つの待ち行列からなることを特徴とする。
【０３５１】
別の実施例（３）では、本発明は（１）のシステムを提供し、すべての協同手順的（ソフトウェア）コンポーネントからアクセス可能な待ち行列上のイベントの設置、修正および削除を管理する手段は、相互運用デバイスのプロセッサロジックで実行する複数のプログラム命令を含むコンピュータプログラムとしてインプリメントされる手順を含むことを特徴とする。
【０３５２】
別の実施例（４）では、本発明は（１）のシステムを提供し、協働デバイスの待ち行列間で直列化および同期するイベントタイプの共通リストを指定および維持するための手段は、相互運用デバイスのプロセッサロジックで実行する複数のプログラム命令を含むコンピュータプログラムとしてインプリメントされる手順を含むことを特徴とする。
【０３５３】
別の実施例（５）では、本発明は（１）のシステムを提供し、どの手順的（ソフトウェア）コンポーネントがイベントを開始したか、チーム化されたデバイスのどれで、イベントを開始した手順的（ソフトウェア）コンポーネントが動作しているかを問わず、共通リスト上のあらゆるタイプのすべてのイベントが、全デバイスで正確に同じ順序で、手順的（ソフトウェア）コンポーネントによって処理されるようにするための手段は、相互運用デバイスのプロセッサロジックで実行する複数のプログラム命令を含むコンピュータプログラムとしてインプリメントされる手順を含むことを特徴とする。
【０３５４】
別の実施例（６）では、本発明は（１）のシステムを提供し、次の１以上またはあらゆる組み合わせが真である：（１）静的イベントデータ構造はＤａｒｔＥｖｅｎｔである、（２）チーム化されたデバイスは、デバイスリクルートメントを利用して協力のためにアセンブリングされる、（３）イベントの設置、修正および削除の管理の方法は、インタオペラビリティ命令セットまたはＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔを利用してアクセスされる、（４）システムは、インタオペラビリティランタイムまたはＤａｒｔＲｕｎｔｉｍｅを介して少なくとも部分的にそのイベント駆動機能を実行する、（５）共通リストを指定し、共通リスト上のいずれかのタイプの全イベントが同じ順序で処理されるようにする方法は、リクルートメントのイベントの直列化および同期について説明される通りである、および（６）システムのソフトウェアアプリケーションオペレーションコードの生成にはインタオペラビリティツールまたはＤａｒｔＴｏｏｌｓを用いる。
ＸＩ．アプリケーションイベント駆動パワーマネージメント
【０３５５】
少なくとも部分的にＤａｒｔＦｒａｍｅｗｏｒｋに具現化されたリニアタスキングまたはバーチカルレイヤリングを用いて構築したＤａｒｔアプリケーションは、正確な応答時間ニーズを常に追跡し、プロセッサのスローダウン等の効率的なパワーマネージメント技術によって、バッテリの寿命を延ばし、消費エネルギー量を制限し、またはデバイスで生成される熱量を制限できるようにすることに注意する。当業の現状では、大半のアプリケーションが応答時間ニーズを追跡しておらず、追跡すると、デバイスのハードウェアからアプリケーションへ応答時間ニーズを通信するためのインターフェースを含まない仕様に準拠した既存のプロトコルの層では、これらニーズを通信することができない。
【０３５６】
アプリケーションイベント駆動パワーマネージメントの特定の実施例についてここに述べる。さらなる実施例は例に記載する。一実施例（１）では、本発明は、デバイスエネルギーおよびパワーマネージメントと、エネルギーおよびパワー消費量削減の方法を提供し、この方法は、少なくとも１つのデバイス内に、エネルギーおよびパワーマネージメントと消費量削減を達成するためのイベント駆動ランタイム環境を確立することと、待ち行列の処理イベントについて、すべての同期および非同期処理イベントおよび関連最小予測処理時間を特定する少なくとも１つのイベント待ち行列を生成および維持することと、待ち行列の予測される最小同期および非同期イベント処理時間に基づき、最終的最小推定応答時間を選択することとを含むことを特徴とする。
【０３５７】
別の実施例（２）では、本発明は（１）の方法を提供し、これはさらに、すべての非同期処理を駆動する第１の非同期イベント待ち行列上の全イベントを検索し、非同期イベントのいずれかを処理しなければならなくなる前に、必要な最小時間を収集することと、すべての同期処理を駆動する第２の同期イベント待ち行列上の全イベントを検索し、同期イベントのいずれかを処理しなければならなくなる前に、必要な最小時間を収集することと、非同期イベントに必要な最小時間と、非同期イベントに必要な最小時間の小さい方を選択することにより、必要な最終的最小応答時間を決定することとを含むことを特徴とする。
【０３５８】
別の実施例（３）では、本発明は（２）の方法を提供し、これはさらに、イベントをそれ以上処理する前に、最終的最小応答時間を用いてパワーマネージメントまたはパワー消費量削減タスクを実行することをさらに含むことを特徴とする。
【０３５９】
別の実施例（４）では、本発明は（２）の方法を提供し、第１の非同期イベント待ち行列と第２の非同期イベント待ち行列は、同一の単一統一イベント待ち行列であることを特徴とする。
【０３６０】
別の実施例（５）では、本発明は（２）の方法を提供し、第１の非同期イベント待ち行列と第２の非同期イベント待ち行列は、異なるイベント待ち行列であることを特徴とする。
【０３６１】
別の実施例（６）では、本発明は（３）の方法を提供し、イベントは、ＤａｒｔＥｖｅｎｔｓであることを特徴とする。
ＸＩＩ．インタオペラビリティアプリケーションイベント駆動エラー復元
【０３６２】
デバイス対デバイスの無線通信は、干渉や距離制限、バッテリ電力低下による突然のシャットダウンなどによりしばしば信頼性が低いことに注意する。従来のデバイス上の水平層プロトコルソフトウェアインプリメンテーションでは、どれか１つの層の致命的エラーによって、アプリケーションを復元するのが困難な復元不可能なエラーを生じることになるが、これは、アプリケーションが接続と接続のコンテキストを容易に再確立する標準インターフェースを持たないためと、従来のアプリケーションプログラムは、異なるデバイスで動作するアプリケーション間で共有状態を追跡および再確立する多くのインフラを持たないためである。ＤａｒｔＦｒａｍｅｗｏｒｋは共有状態を追跡し、レンディションを用いてデバイス間の失われた状態を容易に再確立でき、バーチカルレイヤリングによって、通信エラーをＤａｒｔｓに中継し、Ｄａｒｔが復元情報を通信処理ユニットに直接中継することが単純になる。そのため、デバイス間で動作するＤａｒｔｓは、協働デバイス間の通信の間断的完全なロスからシームレスに復元でき、前に失われたデバイスが自身のアプリケーション状態をすべて失っていたとしても、接続が復元された時、デバイスの共有状態が復元される。
【０３６３】
インタオペラビリティアプリケーションイベント駆動エラー復元のさらなる実施例について述べる。一実施例（１）では、本発明は、失われるか、間断的な通信環境において、オペレーションを優雅に継続するための方法を提供し、複数のチーム化されたデバイス間で協力して動作するイベント駆動インタオペラビリティアプリケーションパッケージは、そのオペレーションを優雅に継続し、および／またはチームの一部であるデバイスとの一時的に失われた通信を部分的に復元するもので、その方法は、（１）チームメンバーのデバイスからチームのデバイスへの通信が失われるか、中断され、所定またはダイナミックに決定された時間内で再確立できない時、チームメンバーデバイスで通信セッションロストタイプのイベントインスタンスを生成することで、各チームメンバーおよびチーム化されたデバイスは、アプリケーションパッケージの意図の一部を実行するものと、（２）通信セッションロストタイプのイベントを直接、またはアプリケーションの動機オペレーションを駆動するイベントの待ち行列を介して、通信セッションロストイベントを取り扱うアプリケーションイベント処理ユニットに送信することと、（３）アプリケーションパッケージのイベント処理ユニットが、可能な場合はアプリケーションパッケージの行動を修正し、通信が失われるか中断されたチーム化デバイスなしに、そのオペレーションを継続することと、（４）チームメンバーとチーム化デバイスとの間に通信が復元されたら、チームメンバーデバイス上で通信セッション復元タイプイベントインスタンスを生成することと、（５）通信セッション復元タイプイベントは、直接、またはアプリケーションの同期オペレーションを駆動するイベントの待ち行列を介して、復元通信セッションを取り扱うアプリケーションイベント処理ユニットに送信されることと、（６）アプリケーションのイベント処理ユニットは、チームメンバーのデバイスに、イベント駆動インタオペラビリティアプリケーションの残りとチーム化デバイスを同期するために必要なあらゆるコード、データおよび／またはコンテンツを送信させることと、（７）アプリケーションのイベント処理ユニットは、アプリケーションパッケージの行動を修正して、復元されたチーム化デバイスをアプリケーションの意図を実行するプロセスに含めることとを含むことを特徴とする。
【０３６４】
別の実施例（２）では、本発明は（１）の方法を提供し、次の１以上があらゆる組み合わせで真である。（１）イベント駆動インタオペラビリティアプリケーションパッケージが、インタオペラビリティフォーマットに従うか、ＤａｒｔＦｏｒｍａｔである、（２）インタオペラビリティアプリケーションが詳細な説明の他に記載された通りであるか、インタオペラビリティパッケージがＤａｒｔである、（３）リクルートメント方法を用いて、複数チーム化デバイス間の協働動作を確立する、（４）イベントはＤａｒｔＥｖｅｎｔであるか、これを含む、（５）イベント処理ユニットはＤａｒｔ  Ｇｉｚｍｏクラスインスタンスであるか、Ｄａｒｔ  Ｇｉｚｍｏクラスから直接または間接に継承したあらゆるクラスのインスタンスである、（６）イベントの調整および同期は、インタオペラビリティエンジンによって各デバイスで実行するかＤａｒｔＥｎｇｉｎｅによって実行する、（７）デバイス上およびデバイス間のイベントの調整および同期は、インタオペラビリティランタイムまたはＤａｒｔＲｕｎｔｉｍｅにしたがって実行する。
【０３６５】
別の実施例（３）では、本発明は（１）の方法を提供し、アプリケーションが、チーム化デバイスなしにそのオペレーションを継続するための修正された行動は、次の１以上のあらゆる組み合わせからなる修正のセットから選択される：（１）失われたデバイスは単にステータスを表示しており、表示なしにアプリケーションの継続を可能にする、（２）失われたデバイスが実行していた機能は冗長であるため、アプリケーションの意図を実行するために必要ではない、（３）失われたデバイスが実行していた機能は、残りのメンバーまたはチームのメンバーによって代わりに実行することができる、（４）失われたデバイスが実行していた機能は、チームが到達可能で、チームにリクルート可能な別のデバイスによって代わりに実行可能である、（５）残りのチーム化デバイスの機能は、削減したオペレーションのモードによって進行可能である、および（６）上記のあらゆる組み合わせ。
ＸＩＩＩ．インタオペラビリティ命令セット
【０３６６】
別の態様では、本発明は、インタオペラビリティ方法、ソフトウェアおよび命令セットを提供する。インタオペラビリティ命令セット（ＩＩＳ）をインプリメントするソフトウェアまたはハードウェアは、が次にとって有利な共通手順的環境をインプリメントするための効率的な方法である。（ｉ）アプリケーションをチーム化してスプレッドまたは分散させるためのリクルートメントモデル、（ｉｉ）無修正のアプリケーションが、非類似デバイスで動作できるようにする、（ｉｉｉ）独自のリソース、独自のケイパビリティおよび／または独自のコンテンツを他のアプリケーションおよびデバイスに露出する。
【０３６７】
一実施例および本発明のインプリメンテーションでは、インタオペラビリティ命令セットは、Ｄａｒｔエンジン中に具現化された、またはこれと互換のＤａｒｔ命令セット（ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ）である（図２２、ＤａｒｔＥｎｇｉｎｅ，６００）。
【０３６８】
コンピュータおよび情報システムとデバイスのコンポーネントは、ハードウェア、ファームウェアおよび／またはソフトウェアにインプリメントされ、特定のインプリメンテーションの特定のコンポーネントにどのハードウェア、ファームウェアまたはソフトウェアを用いるかについて設計およびインプリメンテーションの選択がしばしば行われることが理解される。それはＤａｒｔエンジンおよびインタオペラビリティ命令セットと共に行われる。そのため、ある実施例のあるコンポーネントをハードウェア、ファームウェアまたはソフトウェアについて記載していても、別の実施例では所望の機能または結果を達成する手段を提供するためにハードウェア、ファームウェアまたはソフトウェアの別の組み合わせを用いることがあるのが理解される。
【０３６９】
ある実施例では、インタオペラビリティ命令セットを実行するためのハードウェアおよび／またはソフトウェアは、１１のコンポーネントを備えるが、コンポーネントと機能は異なってグループ化することができるため、数は、エンジンまたは命令セットの構造またはオペレーションについて決定的ではない（図４、３０１０参照）。
【０３７０】
まず、プログラムを動作させ、または実行し、デバイス外部のシステム、デバイス、ネットワーク等との通信をサポートする、プロセッサまたは中央処理ユニット（ＣＰＵ）、メモリ、入力出力（Ｉ／Ｏ）ケイパビリティである。
【０３７１】
第２に、少なくとも従来の汎用コンピューティングタスクを実行するためにメモリアクセス、コンピュテーション、テストおよびブランチ、入力／出力命令がなければならない。
【０３７２】
第３に、共通バイナリアプリケーションとレンディションの実用的到達範囲を広げ、パフォーマンスデバイスを下げるために用いるインタオペラビリティ性能強化命令を設けると有利である。
【０３７３】
第４に、リクルートメント、レンディション、クリエイショニズム、バーチカルレイヤリング、リニアタスキング、ソーシャル同期、ソーシャルセキュリティ、バーチャルポインタのＤａｒｔ方法を実行するためのインタオペラビリティ命令を設けると有利であるが、本書の別の場所に記載するように、インプリメンテーションのすべての実施例にこれらＤａｒｔコンポーネントのすべてが必要なわけではない。
【０３７４】
第５に、特定のデバイスが所有するか、これからアクセス可能な特性、リソース、ケイパビリティおよび／または機能をソフトウェアアプリケーションその他デバイスに露出するよう動作可能な独自のケイパビリティ命令を設けると有利である。
【０３７５】
第６に、デバイスおよび／またはリソースへのアプリケーションのため、セキュリティ特徴の設定、クロスデバイスアクセス権の特定のセットのあるデバイスのグルーピングおよび／またはアクセス権を制御およびそうでない場合はアクセスするため、セキュリティメンテナンス命令を設けると有利である。
【０３７６】
第７に、Ｄａｒｔ包含（ＤａｒｔＣｏｎｔａｉｎｍｅｎｔ）命令等の包含命令を設けて、ＤａｒｔまたはＤａｒｔ互換命令が、発信Ｄａｒｔのオペレーションの一部として収集、維持および動作する他の別個に生成されたＤａｒｔｓに発信Ｄａｒｔの実行を効果的に拡張できるようにすることも有利である。
【０３７７】
第８に、デコーディング、エンコーディング、圧縮および解凍および写真、ビットマップ、音響、入力イベント、テキストレンダリングの操作およびレンダリングその他オペレーションの１以上のための共通ユーザインターフェース（ＵＩ）命令を設けると有利である。
【０３７８】
第９に、セッションおよびセッション間を移動するデータの例えば開閉および維持のための通信命令を設けると有利である。
【０３７９】
第１０に、ストレージ、ストレージデバイス、ストレージリソース等へのアクセスを制御し、維持するためにストレージ命令を設けると有利である。
【０３８０】
第１１に、フォーマットまたはパラメータの異なるデータ、コンテンツおよび／またはコードの間の変換またはトランスコードのために互換性命令を設けると有利である。
【０３８１】
バーチャルマシンの利用など、他の共通方法を介したインタオペラビリティ命令セットの利点は、インタオペラビリティ命令セット（および特にＤａｒｔインタオペラビリティ命令セット）は、デバイスプロセッサのネイティブなコードにコンパイルまたはアセンブルされた機能にディスパッチされる命令としての必要なすべてのインタオペラビリティオペレーションを実行するよう設計および最適化されている。一部任意の特徴およびケイパビリティを含む一実施例では、インタオペラビリティ命令セットは、次の全てとは言わないまでも大半を有していなければならない：（ｉ）リクルートメント命令、（ｉｉ）プロフィール命令、（ｉｉｉ）同期命令、（ｉｖ）ユーザインターフェースまたはＵＩおよびグラフィック命令、（ｖ）パワーマネージメント命令、（ｖｉ）接続およびセッションマネージメント命令、（ｖｉｉ）ストレージ命令、（ｖｉｉｉ）レンディション命令、（ｉｘ）クリエイショニズム命令、（ｘ）アプリケーションパーツマネージメント命令、（ｘｉ）暗号大数数学命令、（ｘｉｉ）テキストおよび／または記号パーシング命令、（ｘｉｉｉ）バーチャルポインタマネージメント命令、（ｘｉｖ）デバイスの独自のケイパビリティをＤＡＲＴ、これにより、他のＤａｒｔＤｅｖｉｃｅまたはＤａｒｔ互換デバイスに露出できるようにする命令。
【０３８２】
インタオペラビリティ命令セットのさらなる特定の実施例について以下に述べる。一実施例（１）では、本発明はインタオペラビリティ命令セット（ＩＩＳ）を実行するための装置を提供し、その装置は、プロセッサと、プロセッサに連結されたメモリと、装置外部のエンティティによるプロセッサとの通信をサポートする入力／出力（Ｉ／Ｏ）インターフェースと、リクルートメント、レンディション、クリエイショニズム、バーチカルレイヤリング、リニアタスキング、ソーシャル同期およびソーシャルセキュリティの少なくとも１つに関わる方法を実行するための実行支援インタオペラビリティ手段と、通信セッション中、通信デバイス間を移動する通信セッションおよび手順、データ、コンテンツその他情報を開放し、維持するための通信インタオペラビリティ命令とを備えることを特徴とする。
【０３８３】
別の実施例（２）では、本発明は（２）の装置を提供し、実行支援インタオペラビリティ手段は、方法を実行するためのインタオペラビリティ命令を含む。
ＸＩＶ．クリエイショニズム
【０３８４】
本発明の別の態様では、クリエイショニズムのためのシステム、装置、方法およびコンピュータプログラムが提供される。クリエイショニズムは、インタオペラビリティアプリケーションが他のインタオペラビリティアプリケーションを形成できるようにして、これがさらにインタオペラビリティアプリケーションを形成できるようにする方法を含む。これによって、接続されたデバイスおよび間断的に接続されたデバイスの世界を通じて異なる形式でアプリケーション、データ、コンテンツの効率的でダイナミックな生成および配信を可能にする。
【０３８５】
１つの有利な実施例およびインプリメンテーションでは、これはＤａｒｔｓが他のＤａｒｔｓ（図１２、７００）またはＤａｒｔ手順（ＤａｒｔＰｒｏｃｅｄｕｒｅｓ、図１４、４０００）を形成し、これらがさらに他のＤａｒｔｓまたはＤａｒｔｓＰｒｏｃｅｄｕｒｅｓを形成する能力である。クリエイショニズムは、Ｄａｒｔプラットフォーム（図３、ＤａｒｔＰｌａｔｆｏｒｍ）を通じて具体化される。例えば、Ｄａｒｔツール（図３、ＤａｒｔＴｏｏｌｓ、２００）は、ソースコード中のパーツの指定し、これらパーツを含むソースコードをＤａｒｔＭａｓｔｅｒ（図１２、２３０）にコンパイルすることを可能にする。ＤａｒｔＭａｓｔｅｒをＭａｓｔｅｒＰｌａｙｅｒ（図１２、２０３）でプレイすると、必要な場合はより多くのリソースを収集し、出力ＤａｒｔまたはＤａｒｔＰｒｏｃｅｄｕｒｅにどのレンディションおよびパーツを含めるかについて必要な情報を要求するためのユーザインターフェースを提供する。
【０３８６】
ＤａｒｔＰｌａｙｅｒで動作するＤａｒｔは、ＤａｒｔＥｎｇｉｎｅにサポートされるＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔからの命令を含み、パーツからダイナミックにレンディションを形成し、これらを効率的にＤａｒｔＦｏｒｍａｔファイルにパッケージすることができる。このカスタマイズされたＤａｒｔｓによるＤａｒｔ生成プロセスは、生成されたＤａｒｔｓおよびＰｒｏｃｅｄｕｒｅｓがそのために必要なデータ、コンテンツおよび手順で形成される限り、無限に続くことができる。
【０３８７】
クリエイショニズムは、インタオペラビリティアプリケーションが他のインタオペラビリティアプリケーションを形成し、これがさらに再帰的および／または直列的および／または散開的にさらにインタオペラビリティアプリケーションを形成できるようにするための方法、関連手順およびコンピュータプログラムコードおよび製品を提供する。ソースコード（図３、１００）と任意でソースデータおよび／またはソースリソースを少なくとも１つのレンディションを含むバイナリイメージにコンパイルするためのツールが提供される。これはまた、デジタルパーツをレンディションのセット（Ｄａｒｔレンディション等）および通信ケイパビリティ、デバイス特性および対象デバイスの環境に基づき、レンディションのアセンブリング方法を制御するパーツを含むバイナリイメージにダイナミックにアセンブリングするための実行可能命令および／またはアプリケーションプログラミングインターフェースをも用い、これらを提供することができる。
【０３８８】
ツールには、Ｄａｒｔ  Ｔｏｏｌｓ（図１２、２００）を含むことができる。バイナリイメージは、ＤａｒｔフォーマットのＤａｒｔ（図３、３００、図１３、図１４）を含むか、これから構成されるか、異なるフォーマットのバイナリイメージまたは非バイナリ形式でエンコードされたイメージであってもよい。デジタルパーツは、数の構造化されたシーケンスとして表現されるあらゆるタイプまたは形式の手順、データセットおよび／またはコンテンツでよい。
【０３８９】
クリエイショニズムのさらなる東低の実施例を以下に述べる。一実施例（１）では、本発明は、当初の個々に実行可能なイメージまたは個々に実行可能なイメージのパッケージが、当初の実行可能イメージまたは個々に実行可能なイメージのパッケージの意図を実行するための少なくとも１つのほかの対象の個々に実行可能なデータイメージまたは個々に実行可能なデータイメージのパッケージをダイナミックに生成できるようにする方法を提供し、この方法は、（１）生成した実行可能イメージまたはイメージのパッケージを実行するためのデバイスおよび／または他の環境の特性、コンテンツ、リソースまたはケイパビリティの少なくとも１つに関する第１の情報を収集し、生成実行可能イメージまたはパッケージの意図または意図の一部の実行に用いることと、（２）次の少なくとも１つをアセンブリングする方法を決定することで、（ｉ）それ自身のイメージの一部、（ｉｉ）収集された情報、または（ｉｉｉ）情報を収集した対象デバイスまたは環境のリソース、ケイパビリティおよびコンテンツを効率的に利用するため、プログラムで生成された情報と、（３）生成された対象実行可能イメージまたはイメージパッケージの意図を無制限シーケンスで実行するために必要とされた１以上のほかの個々に生成された実行可能データイメージパッケージの生成に必要な第２の情報を収集することとを含むことを特徴とする。
ＸＶ．インタオペラビリティエンジン／ＤａｒｔＥｎｇｉｎｅ
【０３９０】
ＤａｒｔＥｎｇｉｎｅは、デバイス上でＤａｒｔｓの命令を実行し、その意図する目的を実行するために用いるソフトウェアおよび／またはハードウェアであるか、これを含むことに注意する。ＤａｒｔＥｎｇｉｎｅと、それがカプセル化されたデバイス固有のＤａｒｔＰｌａｙｅｒは、リクルートメントとレンディションが効率的なデバイスのチームを確立し、Ｄａｒｔｓの意図する目的を最良に実行するコード、データおよびコンテンツを広げることができる共通の実行およびＤａｒｔＲｕｎｔｉｍｅ環境を提供する。
【０３９１】
インタオペラビリティエンジンのさらなる特定の実施例と、インタオペラビリティエンジンのより固有な実施例、ＤａｒｔＥｎｇｉｎｅについて以下に述べる。一実施例（１）では、本発明は、デバイスが互いに相互運用できるよう、またはこれを支援するインタオペラビリティエンジンを提供し、このエンジンは、（１）コードを有し、コードの少なくとも一部がインタオペラビリティ命令セットに準拠する命令のシーケンスに埋め込まれているインタオペラビリティソフトウェアパッケージの意図の少なくとも一部をロード、動作、および実行するための手段と、（２）他のインタオペラビリティデバイスを発見するための手段と、（３）他のインタオペラビリティデバイスと直接または間接的二方向通信のための手段とを備えることを特徴とする。
【０３９２】
別の実施例（２）では、本発明は（１）のインタオペラビリティエンジンを提供し、次の１以上があらゆる組み合わせで真である。（１）エンジンがＤａｒｔＥｎｇｉｎを備え、（２）インタオペラビリティソフトウェアパッケージがインタオペラビリティソフトウェアパッケージを備え、またはＤａｒｔＦｏｒｍａｔに準拠するＤａｒｔを備える、（３）他のインタオペラビリティデバイスを発見するための手段は、少なくとも部分的に、リクルートメント手順またはＤａｒｔリクルートメント手順を用いて実行される。
【０３９３】
別の実施例（３）では、本発明は（１）のインタオペラビリティエンジンを提供し、エンジンは、イベント待ち行列を含み、インタオペラビリティアプリケーションパッケージによるイベント待ち行列の利用をサポートする命令を実行することを特徴とする。
ＸＶＩ．インタオペラビリティデバイスイネーブリング
【０３９４】
インタオペラビリティデバイスイネーブリングは、ＤａｒｔＰｌａｙｅｒの一部としてのＤａｒｔＥｎｇｉｎｅのポーティングを通じて従来のデバイスを高度に相互運用可能なＤａｒｔＤｅｖｉｃｅに変えるプロセスである。さらに、デバイスのデバイス固有情報、ケイパビリティおよびコンテンツにアクセスするために必要なハードウェア抽象化層のインプリメンテーションも必要である。ＤａｒｔＰｌａｙｅｒのあるデバイスがＤａｒＤｅｖｉｃｅになるには少なくとも１つの通信プロトコルをインプリメントしなければならない。
【０３９５】
インタオペラビリティデバイスイネーブリングのさらなる特定の実施例を以下に述べる。一実施例（１）では、本発明は、デバイスをインタオペラビリティデバイスにするために必要なインタオペラビリティソフトウェアを形成するため、インタオペラビリティエンジンに共通ソフトウェアソースコードを用いる方法を提供し、この方法は（１）インタオペラビリティエンジンオブジェクトまたはインスタンスを生成することと、（２）デバイスハードウェア抽象化層（ＨＡＬ）オブジェクトまたはインスタンスを生成することと、（３）ｈａｌＢａｓｅクラスまたは仕様の予め定義された必要なｈａｌＢａｓｅメンバー機能全ての機能を特定および埋めることと、（４）実行のスレッドでエンジンを実質的に継続して動作させるデバイス固有Ｐｌａｙｅｒオブジェクトを生成することとを含むことを特徴とする。
【０３９６】
別の実施例（２）では、本発明は（１）の方法を提供し、実行のスレッドで実質的に連続してエンジンを動作させるデバイス固有Ｐｌａｙｅｒオブジェクトの生成は、次のようにエンジンを動作させる：（ａ）エンジンの初期化機能を呼び出す、（ｂ）返された値が復元不可能なエラー発生を示す場合に終了したり、エンジンを閉じるためのループでエンジンのプロセスの機能を呼び出す、（ｃ）エンジンの非初期化機能を呼び出す、（ｄ）実行のスレッドを停止する。
ＸＶＩＩ．インタオペラビリティセキュリティモデル／ＤａｒｔＳｅｃｕｒｉｔｙ
【０３９７】
ＤａｒｔＳｅｃｕｒｉｔｙは、デバイスとそのコンテンツの整合性を悪意ある、あるいは偶発的な損傷から守るために必要なインフラを提供するシステムおよび方法であることに注意する。
【０３９８】
堅牢なセキュリティインフラが、デバイス、そのコンテまたは機能を乱用や改悪その他侵害や望ましくない方法での利用から守るための基盤として作用することが望ましい。このようなインフラは、図２９に示すようにＤａｒｔＰｌａｔｆｏｒｍの要素によって望ましい方法で具体化された本発明のＤａｒｔＳｅｃｕｒｉｔｙシステムである。
【０３９９】
好適な実施例では、ＤａｒｔＤｅｖｉｃｅが初めてＤａｒｔＰｌａｙｅｒを実行するとき、ＤａｒｔＥｎｇｉｎｅの初期化プロセスの一部は次を実行する。
【０４００】
１．パブリックおよびプライベート暗号キーペアと一意のＩＤ（ＵＩＤ）を生成するのに適した十分なエントロピーを集め、生成したキーペアと一意のＩＤが、同様の方法だが異なる収集エントロピーで生成された他のものに対して真に一意であることを統計的に保証する。
【０４０１】
エントロピーは、ＤａｒｔＤｅｖｉｃｅによって、サンプリングハードウェアを動かすクロックにいかなる方法でも同期されていないデバイスの外の世界の態様をデジタルにサンプリングすることによって信頼性高く集めることができる。他のデバイスに話しかけるために用いる通信メカニズムはしばしばよいエントロピー源になるが、それは、データのパケット、タイミング、バリエーションのタイミングがサンプリングを制御するプロセッサのクロックに相関しない電磁妨害および量子雑音によって影響を受けるためである。別の簡単なエントロピー源は、デバイスが人間ユーザからの入力を要求し、ユーザが入力を与えた時、非常に細かいクロックをサンプルすることである。タイミングおよびデータサンプルを含むエントロピーは、乱数ジェネレータをシードするのに用いるデータ値のセットにハッシュできる。実際には、十分なエントロピーが集まったことを知るのは難しいが、推定は可能で、十分集まり、ハッシュされたデータ値に維持されているようオーバーサンプリングすることができる。
【０４０２】
２．従来の乱数生成アルゴリズムと従来の暗号オペレーションを用いて、ユニバーサルに一意のパブリック／プライベートキーペアとユニバーサルに一意のＤａｒｔＤｅｖｉｃｅ  ＵＩＤを生成し、常にデバイスを一意に識別するようにする。好適なインプリメンテーションでは、全てのＵＩＤの長さは１２８ビットである。
【０４０３】
３．プライベートキーとデータ値のエントロピーハッシュセットは、デバイス上でデータをわかりにくくするか、隠しながら、エンジンがデータを利用できるようにするため、当業の現状で知られる従来の方法によってデバイスに保存される。
【０４０４】
４．バイナリフラッグのセットに基づき、デバイスのデータ、コンテンツまたは機能のリソースへのアクセスを制限する。好適なインプリメンテーションでは、デバイスの機能について対応するデータへのアクセスがブロックされる場合、これらフラッグは１である。例として、ここのフラッグは次のリソースについて存在することができる：
ａ．プライベートとマークされているデータまたはコンテンツへのアクセスのブロック、
ｂ．別のデバイスへの通信セッション開放へのアクセスのブロック、
ｃ．ネイティブなストレージデバイスへのアクセスのブロック、
ｄ．スクリーンおよびキーボード、マウスおよび音声生成などのユーザインターフェース要素へのアクセスのブロック。
【０４０５】
５．ＤａｒｔＥｎｇｉｎｅで動作させるためロードする各ＤａｒｔまたはＤａｒｔＰｒｏｃｅｄｕｒｅは、ＤａｒｔＤｅｖｉｃｅのリソースへのアクセスを制御するフラッグ値の明示的または暗示的セットを有する。各ＤａｒｔＤｅｖｉｃｅは、セキュリティのレベルにマッピングするアクセスフラッグの明示的または暗示的セットを有する。アプリケーションまたはアプリケーションを送るデバイスがリソースのフラッグをすべて持たない場合、デバイスがまず、特定のデバイスで動作させるＤａｒｔまたはＤａｒｔＰｒｏｃｅｄｕｒｅを認証する許容可能な証明またはフラッグをユーザまたは他のデバイスから入手しない限り、ＤａｒｔアプリケーションまたはＤａｒｔＰｒｏｃｅｄｕｒｅをロードしない対象デバイスにゼロを設定するアクセスが必要である。Ｄａｒｔ、ＤａｒｔＰｒｏｃｅｄｕｒｅまたはＤａｒｔＤｅｖｉｃｅのＵＩＤに結びついたアクセスフラッグは、対象のＤａｒｔＤｅｖｉｃｅで恒久的に、または指定の期間、またはＤａｒｔあるいはＤａｒｔＰｒｏｃｅｄｕｒｅの実行中またはデバイス間の通信セッション中、維持することができる。
【０４０６】
６．Ｄａｒｔアプリケーションが、アプリケーションのコンテキストフラッグが１に設定されたＤａｒｔＥｎｇｉｎｅを自身に代わってリソースのどれかにアクセスさせようとした場合、ＤａｒｔＥｎｇｉｎｅは直ちにアプリケーションの命令の実行を停止し、アプリケーションをクローズダウンする。
【０４０７】
一実施例では、Ｄａｒｔｓはアクセスについてフラッグセットと共にデジタルに署名されていなければならない。デバイス間の通信セッションのパーツまたはコンテンツの暗号／復号もまたＤａｒｔＳｅｃｕｒｉｔｙシステムの一部である。
【０４０８】
図２５は、セキュリティシステム要素の一部のあるＤａｒｔＤｅｖｉｃｅ４００である。ＤａｒｔＥｎｇｉｎｅは暗号化１５０、エントロピー収集１５３、乱数生成１５２、およびあらゆる２つのＤａｒｔＤｅｖｉｃｅ間の通信が自動的に暗号化され、ＤａｒｔＥｎｇｉｎｅベースの通信がデータの通信を守るため外のプロトコルに依存する必要なないよう、ＤａｒｔＳｅｃｕｒｅプロトコルを用いたデバイス間の全ての通信のセキュアリングをサポートする命令ベースの方法を有する。ＤａｒｔＳｅｃｕｒｅプロトコル１５３は、セキュアソケットレイヤ（ＳＳＬ）プロトコルその他、デバイス間のセキュアな通信リンクを確立するプロトコルを用いてインプリメントすることができる。好適なインプリメンテーションでは、ＳＳＬプロトコル標準の機能性のサブセットがインプリメントされ、ＳＳＬのオプションの多くが必要でないため、サイズと複雑性を削減する。必要な大数数学暗号プリミティブ１５０および１５１をＤａｒｔＥｎｇｉｎｅの一部として示す。パフォーマンス上の理由から、暗号数学プリミティブは、Ｄａｒｔ内部ではなくエンジンのネイティブなコードにインプリメントすることが非常に望ましい。
【０４０９】
図２５は、ＤａｒｔＥｎｇｉｎｅがセキュリティのレベルに対応するＵＩＤ１５５および１５６のリストを維持するところを示す。この図はまた、レベル番号をアクセス権フラッグ１５９のセットにマッピングする表も示す。特定レベルの権利の一部であるデバイスおよびアプリケーションＩＤのリストは、ＤａｒｔＥｎｇｉｎｅによって維持され、デバイスからデバイスへ許可されると、好適なオペレーションモードが伝達され、リスト上のあらゆるデバイスがそれ以上証明書を集める必要なしに、新しいデバイスにアクセスできるようになる。特定レベルのセキュリティ、ＳｏｃｉａｌＳｅｃｕｒｉｔｙにおける本発明のデバイスおよびアプリケーションの過渡的チーム化は、本書で別にさらに述べる。
【０４１０】
フラッグの提示、収集のパス、ローディングの後でも、ＤａｒｔアプリケーションまたはＤａｒｔＰｒｏｃｅｄｕｒｅが意図的あるいは偶発的にオフリミットのリソースにアクセスできないようにするため、このようなアクセスの試みはすべて、ＤａｒｔまたはＤａｒｔＰｒｏｃｅｄｕｒｅが当初提示した許可フラッグ全てを持つコンテキストデータ構造１６０および１７０を用いてエンジンによってチェックされる。
【０４１１】
取り消しリスト１５５を、ソーシャル同期として本書の他にさらに述べるように過渡的に維持し、以前に他のデバイスと特定のセキュリティレベルでチーム化したデバイスは、他のチームデバイスからの取り消しを過渡的に知ったあらゆるデバイスとのインタオペラビリティについて論理的に取り消されたアクセス権を持てることに注意する。一実施例では、取り消されたデバイスが取り消しを知るチーム化デバイスと接触すると、ＤａｒｔＥｎｇｉｎｅが取り消されたデバイスを動作不能または部分的に動作不能にする。共通アクセス権を有する相互運用可能デバイスチーム間のアクセス権の取り消しは完全ではないが、多くの状況で、間断的に接続されたデバイスのチーム間の失われた、あるいは不正な処理を行うか、悪意のあるデバイスのアクセス権の取り消しを実行するための実際的なシステムである。
【０４１２】
アクセス権またはその取り消しのスプレッド方法は、態度の悪い人について友達に知らせる人間によく似ており、情報は人から人へゴシップのように広がり、ほとんどの人が、その人の悪意を最初に知った人と直接話したことがなくても、悪意のある人から離れていられるようになる。
【０４１３】
アクセスフラッグに加えてＤａｒｔＥｎｇｉｎｅコンテキストも、動作中Ｄａｒｔの一部でないメモリ、ストレージまたはコードへの動作中のＤａｒｔまたはＤａｒｔＰｒｏｃｅｄｕｒｅによるアクセスを制限するため、エンジンが利用する情報を含む。このアクセス制限は、当業の現状で「サンドボックス」として知られるものである。ＤａｒｔＥｎｇｉｎｅは全てのＤａｒｔｓおよびＤａｒｔＰｒｏｃｅｄｕｒｅｓ上でこのようなサンドボックスを実行し、サンドボックスで動作しているＤａｒｔｓまたはＤａｒｔＰｒｏｃｅｄｕｒｅｓの利用のために明示的に提供された機能、メモリ、ストレージ部分以外でデバイスにアクセスするためＤａｒｔｓを利用することができないようになっている。
Ｄａｒｔｓ
【０４１４】
本発明の好適な一実施例では、従来はコード、データ、オペレーティングシステム、グラフィックス、またはユーザ入力サブシステムと、スレッディングと考えられてきたものの間、またはコンテント、プログラムあるいはデバイスの間にさえ、特殊化はほとんどない。ＤａｒｔＰｌａｔｆｏｒｍ（図３）は、Ｄａｒｔ設計者が設計し、ＤａｒｔＳｏｕｒｃｅ（図３、１００）で指定したようにアプリケーションの意図を実行する一体化されたバーチャルシステムに、ソフトウェア手順、コード、データ、コンテンツ、およびデバイスエレクトロニクスをインテリジェントに混合および一致させる。
【０４１５】
ＤａｒｔＴｏｏｌｓが構築したＤａｒｔｓは、各種デバイス間のプログラム、コントロール、ハードウェアリソースおよびコンテンツの効率的な共有のため、自身のバージョンまたは拡張を自己最適化、再構成、送信および同期することができる。
【０４１６】
Ｄａｒｔｓは、あらゆる数の非類似デバイス、同時に多数の類似または非類似デバイス間でうまく動作できる一体型作業アプリケーションを確立するのに必要な全てのデータ、コンテンツおよび手順と共に構築される。
【０４１７】
さらに、単一Ｄａｒｔのランタイム環境も、あらゆるＤａｒｔの親Ｄａｒｔまたは子Ｄａｒｔ拡張として他のＤａｒｔｓを動的または静的に含むことができる。そのため、ＤａｒｔＲｕｎｔｉｍｅ環境は未知のデバイスおよび未知の別個に生成されたＤａｒｔｓ間の到達において一意である。
【０４１８】
現在採用されているインタオペラビリティ技術と異なり、このようなタスクに限られないＤａｒｔ技術は、写真スライドショー、予約カレンダー、連絡先、コントロールパネル、メッセージ等の人間がサイズを決めたデータおよびタスク周辺で最適化される。このシステムの応答時間は、動画ビデオを行い、５分の１秒で個人連絡先リストの特定の連絡先を見つけるためのボタン押し下げまたは要求に応答できるだけ十分速い。人間にとっては、このような応答時間はほぼ瞬間的と変わらない。Ｄａｒｔ応答時間要件は、大半のアプリケーション環境を基にしたほとんどのリアルタイムオペレーティングシステムに比べるとはるかにゆるいが、これは、リアルタイムオペレーティングシステムは一般的に、数百ものオペレーションを毎秒取り扱わなければならないデータサーバなどのアプリケーションを動作させることを期待されるためである。Ｄａｒｔｓは人間の時間で応答すればよく、有利に単純かつ高度に堅牢で柔軟な階層的イベント処理メカニズムが、現状のインタオペラビリティオペレーティングシステムおよび関連ランタイム環境で採用される標準的プリエンプティブまたは協力的スレッドシステムの代わりに採用されているためでもある。
【０４１９】
スライドショーＤａｒｔアプリケーションを例に考えてみる。どのようなプログラミング言語も使えるが、一実施例では、スライドショーＤａｒｔは、やはりＣ＋＋で書かれたＤａｒｔＦｒａｍｅｗｏｒｋを用いて（図１１、１０２）Ｃ＋＋プログラムコード言語で書かれ、ＤａｒｔＴｏｏｌｓ（図１２、２００）を用いてコンパイルおよびリンクされる。Ｃ＋＋ソースコードは、Ｄａｒｔアプリケーションが他のデバイスを見に発見したデバイスの一部で実行せしめ、関連する全てのデバイス上でイベント待ち行列によって相互運用するために必要な全てのＤａｒｔＰｒｏｃｅｄｕｒｅｓ、レンディションおよびその他インタオペラビリティ拡張を含んで生成できるようアプリケーションを拡張するＤａｒｔ固有Ｃ＋＋プラグマステートメントも含む。このようなデバイスは、アプリケーションの全てのコンポーネントが高度に協力的および堅牢な方法で動作し、Ｄａｒｔにカプセル化された相互運用可能アプリケーションの意図を表現できるよう（図９）、自動的に直列化および／または同期されたイベントによるイベント駆動でよい。好適な実施例では、ＤａｒｔＭａｓｔｅｒ（図１２、２３０）がＤａｒｔＴｏｏｌｓ（図１２、２００）から直接生成され、単一のＭａｓｔｅｒＲｅｎｄｉｔｉｏｎ（図１１、１１３）由来オブジェクトからなり、これが実行の起点としてメインの方法を提供し、これがＭａｓｔｅｒＲｅｎｄｉｔｉｏｎオブジェクトの維持するリストを構築し、これには、他のレンディション由来オブジェクト（図１１、１１４）の参照が含まれる。
【０４２０】
ＤａｒｔＭａｓｔｅｒは一般にプログラマによってＣ＋＋またはＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔを対象とするツールおよびフレームワークを用いてその他ハイレベル言語で構築される。Ｄａｒｔが自分を動作させることになるデバイスの全範囲をカバーするため、ＭａｓｔｅｒＤａｒｔは一般に、１から５の間の異なるレンディションを生成するＭａｓｔｅｒＰｌａｙｅｒの用いるコンテンツおよび手順を含むことになる。
【０４２１】
論理的に、レンディションは別個プログラムまたは実行可能イメージと考えることができ、好適な実施例では、そのうち１つのみを選択して、いずれかの時にいずれかのデバイスで動作させる。
【０４２２】
物理的に、レンディションはしばしばそのデータ、コード、コンテンツコンポーネントの大半を有利に共有し、実際のＤａｒｔＦｏｒｍａｔバイナリイメージまたはファイルの重複量を有利に最小限にする。
【０４２３】
Ｄａｒｔのリソース（図３、１００）は、どのレンディションがそのデバイスで最もよく動作するか判断するためデバイス上で動かす手順を含まなければならない。
【０４２４】
例えば、写真のコレクションを含むスライドショーＤａｒｔは次の３つのレンディションを持つ場合がある：（ｉ）１行または数行のテキストディスプレイしか持たないデバイスのためのシンプルテキストレンディションで、このレンディションは、画像そのものを見せることができないため、スライドショーの名前と含まれるスライドの名前のリストをスクロールする、（ｉｉ）携帯電話は、画面寸法の小さいＰＤＡ、限られたＣＰＵ電力などに適した小画面レンディション、（ｉｉｉ）大型画面パーソナルコンピュータ（ＰＣ）またはホームエンターテインメントシステムでの動作に適した複数のディスプレイオプション、インデックス、遷移効果のある大きな写真を見せるハイエンド大型スクリーンレンディション。
【０４２５】
ある特定の有利な動作モードでは、複数のレンディションを含むＤａｒｔがまずデバイスで動作を開始する時、Ｄａｒｔ手順はＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔのプロフィール命令を用いて、そのデバイス上のＤａｒｔＥｎｇｉｎｅに構築されたデバイスプロフィールを検査し、そのデバイスが、最も高度なレンディションを動作させるのに必要な機能を全て持っているか否か判断する。持っている場合、最も高度なレンディションを動作させる。持っていない場合、そのデバイスで効果的に動作できるものが見つかるまで、デバイスプロフィールをより高度でないレンディションに対して手順的にチェックする。
【０４２６】
ＤａｒｔＥｎｇｉｎｅを内蔵していない対象デバイスは、対象デバイスをよく知っていて、対象デバイスへの接続を介してデバイスのＤａｒｔＥｎｇｉｎｅのオペレーションをプロキシし、バーチャライズする能力のある内蔵ＤａｒｔＥｎｇｉｎｅのあるデバイスによって、あるいはこれを通じてアクセス可能である。この例の１つが、ＤａｒｔＥｎｇｉｎｅのないプリンタの利用で、これは、ＰＲＯＦＩＬＥ＿ＩＮＳＴＲＵＣＴＩＯＮを通じてその印刷リソースを露出し、ＤａｒｔＥｎｇｉｎｅを動作させているパーソナルコンピュータを通じて印刷を望むデバイスによって到達可能である。ＰＣで動作しているＤａｒｔＥｎｇｉｎｅが印刷ケイパビリティを露出し、パーソナルコンピュータのＤａｒｔＥｎｇｉｎｅのハードウェア抽象化層（ＨＡＬ）オブジェクトのプロフィールと印刷方法を通じてアクセスできる限り、ＤａｒｔＥｎｇｉｎｅのある他の開始デバイスは、パーソナルコンピュータが利用可能なプリンタにアクセスすることができる。
【０４２７】
Ｄａｒｔが他のデバイスに自身を送るよう要求された場合、大半のＤａｒｔｓのユーザオプションの１つは、送信するレンディションのセットを対象デバイスで動作できるものに限ることである。このようにして、ユーザは、対象デバイスへの送信時間と、メモリ要件を制限することが出来る。当然ながら、新しいデバイスはより有能なデバイスに再送するさらに高レベルのレンディションは持たない。
【０４２８】
大量のコンテンツと、コンテンツを作成および編集するアプリケーションプログラムはＰＣまたはインターネットベースであるため、Ｄａｒｔコンテンツが既存のソフトウェアシステムにとってネイティブな形式でコンテンツのインポートおよびエクスポートができるのは重要である。
【０４２９】
Ｄａｒｔｓは、ＪＰＥＧ画像の標準フォーマットデータ、その他遭遇しそうなその他形式のデータまたはコンテンツ等を有利に含み、メニューオプションを、写真、ビデオ、オーディオ、テキスト、各種コンポーネントを結び付けるＸＭＬ文書をインポートおよびエクスポートするＤａｒｔコンテンツに内蔵することができる。
【０４３０】
ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔは、任意であるが、有利に、ＪＰＥＧその他標準メディアフォーマット解凍および再生命令を含み、ＣＰＵ集約解凍タスクをＤａｒｔＥｎｇｉｎｅの一部としてＤａｒｔＤｅｖｉｃｅのＣＰＵのネイティブな命令セットにコンパイルされた効率的な機能にインプリメントされている。これら命令も、ＤａｒｔＥｎｇｉｎｅが解凍の大半を行い、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔの実行の一部として表示するため、Ｄａｒｔｓに含まれるべきコード量を制限する。同様に、テキスト、ＲＴＦ、ＸＭＬその他テキストベース文書のパーシング時、アプリケーションコードの量を制限し、ネイティブなコード速度の利点を与えるＸＭＬその他テキストパーシング命令がある。
【０４３１】
さらに、ＰＣアプリケーションは、そのメーカーによって、Ｄａｒｔコンテンツを直接インポートおよびエクスポートできるように容易に適合可能である。Ｄａｒｔｓは、他のアプリケーションおよびＤａｒｔｓがＪＰＥＧ画像やオーディオクリップ等のコンテンツパーツを、パーツのテキスト名や記述と共にプログラムで列挙して取り出せるよう、コンテンツアクセスＡＰＩと制御ＡＰＩを含むことができる。
【０４３２】
Ｄａｒｔ制御ＡＰＩと、ＡＰＩ機能のテキスト記述も、列挙およびアクセスして、Ｄａｒｔｓ自身のオペレーションを他のＤａｒｔｓやデバイスから制御し、Ｄａｒｔｓやそれらが動作するデバイスの遠隔制御を可能にすることができる。
Ｄａｒｔ  Ｅｎｇｉｎｅをデバイスにポーティングするための手順の実施例
【０４３３】
ＤａｒｔＥｎｇｉｎｅを新しいデバイスにポーティングする手順を以下に述べる。この例では、Ｄａｒｔ  ＥｎｇｉｎｅがＣ＋＋コードＤａｒｔＥｎｇｉｎｅであることを想定するが、手順の一般性からそれない。
【０４３４】
第１に、ｈａｌＢａｓｅのオブジェクトから継承するか、直接生成などの他の方法で、自分のハードウェア抽象化層（図４、３０２０、図２２、６５０、図２７、６５０）オブジェクトを形成する。
【０４３５】
第２に、あるサイズのメモリの単一連続ブロックの割り当てや、ミリ秒での時間のリターン、３つの標準内部フォーマットの１つでのビットマップの移動、または時間バリアントのある位置の画面へのコンパイルなどの機能を含むｈａｌＢａｓｅメンバー機能の機能性を満たす。ｈａｌＢａｓｅクラスはまた、ＤａｒｔＥｎｇｉｎｅ上で動作するＤａｒｔｓがＣＰＵ、メモリ、画面、通信、音響、印刷その他実際のデバイスの特性を決定できるように設けなければならない、プロフィール情報ワードを入手するためのバーチャル機能も含む。特に利点は、基礎のｈａｓＢａｓｅクラスの純粋にバーチャルな方法では露出されないデバイスの独自のケイパビリティ、コンテンツまたは機能性を露出するため、ＯＥＭ＿Ｆｕｎｃｔｉｏｎ方法を利用してプログラム的インターフェースを設計および構築することである。
【０４３６】
第３に、ＰｌａｙｅｒＢａｓｅオブジェクトから継承するか、継承の利点なしに直接、デバイス固有のＤａｒｔＥｎｇｉｎｅオブジェクト（図２２、６００）を生成する。
【０４３７】
第４に、ＤａｒｔＥｎｇｉｎｅを採用するデバイスのＤａｒｔＰｌａｙｅｒ実行可能（図２２、６００）を構築するが、これは非ゼロ値など所定の条件が返されるまで、ループのＤａｒｔＥｎｇｉｎｅのＰｒｏｃｅｓｓ（）メンバー機能（例えば、ｐｌａｙｅｒＢａｓｅ：：Ｐｒｏｃｅｓｓ（）メンバー機能（図２３、４００３、図２５、６１１））を呼び出すループを含む。通信を含むＤａｒｔＰｌａｙｅｒｎｏ全ての同期（図１５、８０１０）および非同期オペレーション（図１６点線ボックス内部の非同期イベント処理）は、マルチスレッドのＯＳが必要ないように、この単純なループの実行スレッドによって駆動される。
【０４３８】
デバイスインタオペラビリティに対するＤａｒｔソリューションは、Ｎ乗（図１および図２）からＮ順まで適合と試験複雑性数式を有利に変更する。新しいデバイスが他の種類の非類似デバイスそれぞれとコンテンツおよびコントロールを共有し、ここのソリューションをインプリメントする方法を考慮する必要なしに、ＤａｒｔがＤａｒｔＥｎｇｉｎｅをデバイス固有のＤａｒｔＰｌａｙｅｒにポーティングするだけでよい（図１０）。
【０４３９】
そのデバイスが有する通信チャンネルを全て理解している機能をインプリメントし、ＣＰＵ速度、画面サイズ等をレポートするルーチンを構築する必要はあるが、デバイスがコンテンツやコントロールを共有する方法を考える必要はまったくない。デバイスの内蔵ソフトウェアの代わりに、Ｄａｒｔコンテンツがそれを行う。
【０４４０】
このポーティングによって、Ｎ乗ソリューションではなく管理可能なＮ順ソリューションであるＤａｒｔを提供され、ＤａｒｔＰｌａｙｅｒのポーティングは新しいデバイス毎に１回のみ、さらに、新しい各アプリケーションにつきＤａｒｔは１回開発すればよく、新しい各デバイスまたはアプリケーションには追加作業単位が１つしか必要ないことが理解される。
ＤａｒｔＰｌａｙｅｒの実施例
【０４４１】
例えば、Ｃ＋＋言語でインプリメントされ、従来のプログラミングツールを用いて、ＤａｒｔＤｅｖｉｃｅのプロセッサのネイティブな命令セットまたは一部実施例では中央演算処理装置（ＣＰＵ）にコンパイルしたＤａｒｔＰｌａｙｅｒ（図２２、５００）について以下に説明する。
【０４４２】
ＤａｒｔＰｌａｙｅｒクラスが継承するＰｌａｙｅｒＢａｓｅクラスは、一連のパラメータ付オペレーションコードであるＤａｒｔプログラムを実行する。基本的に、ＤａｒｔＰｌａｙｅｒはマイクロプロセッサに類似し、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔはマシン命令セットに類似しているが、Ｄａｒｔｓの場合、命令の大半は一般的なマイクロプロセッサよりはるかに高レベルである。ＤａｒｔＰｌａｙｅｒにネイティブな命令は、例えば、ＪＰＥＧ画像をバッファに解凍したり、バッファの画像を正しいフォーマットで物理的スクリーンの特定の場所に移動したり、動作中のＤＡＲＴおよびそのコードとデータの全状態を保存したりする単一の命令を含むことができる。さらに、フルセットの２Ｄグラフィックプリミティブ、高度ユーザ入力処理、オーディオ解凍処理命令も、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔに有利に内蔵することができる。
【０４４３】
Ｄａｒｔが次のことをしたい場合、（ｉ）自分自身を送る、（ｉｉ）自分自身の最適化バージョンを送る、（ｉｉｉ）コントロールパネルを要求する、（ｉｖ）ＤＡＲＴ手順を要求する、または（ｖ）他のデバイスからデータを要求する、ＥｎｕｍｅｒａｔｉｏｎＩｎｓｔｒｕｃｔｉｏｎを用いるか、ＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎｗｏ用いて、ＥｖｅｎｔＱｕｅｕｅにＥｎｕｍｅｒａｔｉｏｎＥｖｅｎｔを入れる。ＥｎｕｍｅｒａｔｉｏｎＩｎｓｔｒｕｃｔｉｏｎまたはＥｎｕｍｅｒａｔｉｏｎＥｖｅｎｔによって、プレイヤにｈａｌベース列挙メンバー機能を呼び出させ、接続できる各Ｄａｒｔデバイスの名前と記述を入手する。任意で、ＤａｒｔＰｒｏｃｅｄｕｒｅをこのような各デバイスに送り、これが手順を実行し、自身が発信デバイスで動作する手順を返すことができる。このため、Ｅｎｕｍｅｒａｔｉｏｎ命令と一般的処理、数学および試験と制御命令を用いて、あらゆる接続デバイスを効果的に検査し、所望の機能のセットの大半を実行できるか、利用する、または関心のあるコード、データまたはコンテンツを含むかを調べることができる。
【０４４４】
他のデバイスに送られ、受け取り返したＤａｒｔＰｒｏｃｅｄｕｒｅｓまたはＤａｒｔｓの機能は、ほとんどのことを行うコードを含むことができ、この機能性は、広い範囲のデバイス間の協力的タスクに必要な全てである。大半のインスタンスで、他のデバイスに接続する時、どのタイプの物理的接続、プロトコル、セキュリティ対策などの設計選択を行うかは、デバイスにプレイヤをポーティングする人物、プログラマによる。ある特定の有利なインプリメンテーションでは、ＤａｒｔＰｌａｙｅｒは、受信した通信ブロックはエラー補正されており、すでにポーティングしたプログラマがｈａｌＢａｓｅバーチャル機能に組み込んでいるセキュリティ要件をパスしていると想定している。ＨＡＬのデバイス固有機能のこのようなブロックの低レベル送受信を別として、セキュアな通信セッションをセットアプリケーションし、関連するデータ、コード、コンテと共にイベントを送信し、過渡で失われたブロックを自動的に要求および処理し、デバイス間で一時的に失われたセッションを自動的に復元することをＤａｒｔＥｎｇｉｎｅのポータブルコード部分ですべて実行する。これによって、ＤａｒｔＤｅｖｉｃｅ上の各種通信プロトコルをサポートするために必要な作業量が大幅に減り、同一ソースコードベースを用いてＤａｒｔＥｎｇｉｎｅのポータブルパーツのポーティングを行うため、デバイス間のインプリメンテーションの信頼性が大きく改善される。
物理的発見のためのＤａｒｔ命令セットの利用の実施例
【０４４５】
ＤａｒｔＩｎｓｔｒｕｃｔｉｎｏＳｅｔの実施例は、非常に高レベルの機能性でデバイス、サービスおよびリソース発見とデバイス間通信を取り扱い、有利である。ある実施例では、ＤａｒｔＩｎｓｕｔｒｕｃｔｉｏｎＳｅｔは、非常に高レベルの機能性でデバイス、サービスおよびリソース発見とデバイス間通信のみを取り扱う。動作中のＤａｒｔはデバイスプロフィールを検査し、通信速度や待ち時間などの実際の通信特性を判断することができるが、一般に動作中のＤａｒｔは、デバイス間の実際の通信が、ＨＴＴＰ、ＴＣＰ  ＩＰ、ＵＳＢ、８０２．１１ｂの他プロトコルのいずれであるか、共有メモリカード、物理的変換メモリカードその他物理的媒体またはプロトコルであるかを気にかけないし、知る必要もなく、有利である。
【０４４６】
同様に、他のデバイス、サービスまたはリソースあるいは認証とセキュリティの物理的発見を、ポートを指定してインプリメントする人によってｈａｌＢａｓｅ上書き機能に組み込むことができる。
【０４４７】
このようなポートを構築する有利な方法に、ｐｌａｙｅｒＢａｓｅベースのＤａｒｔＰｌａｙｅｒの一部として、ユーザ編集可能な「フレンドリー」デバイスリストを生成するものがある。これにより、ユーザは、他の方法では発見不可能、発見困難または他の多数のネットワーク化されたデバイスの中でピンポイントするのが難しいデバイスにアクセスさせたい全デバイスにアクセスするために必要なインターネットプロトコル（ＩＰ）アドレスおよび／またはネットワーク名および／またはパスワードを指定することができる。
【０４４８】
本発明の実施例は、すべてのＤａｒｔＰｌａｔｆｏｒｍキャラクターが３２ビットワードで、Ｄａｒｔ手順による内部の特別取り扱いの必要なく、Ｕｎｉｃｏｄｅまたはマルチバイトなどのあらゆるキャラクター表現システムに有利に対応できるようになっている。特定のデバイスのネイティブなケイパビリティを一致させるのは、３２ビット文字との変換のためオブジェクトをインプリメントする ｈａｌＢａｓｅ由来のＨＡＬである。しかしながら、本発明は特定のビットワードサイズに限定されず、これより大きいか、小さいビットワードサイズを用いることができる。
【０４４９】
デバイス、リソースおよび／またはサービス発見を望むデバイスは、そこにある標準に準拠しなければならない。Ｄａｒｔ列挙命令インターフェースまたはＳｉｇｎａｌＥｖｅｎｔ  ＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎ（図２０、６７０）処理は、Ｄａｒｔアプリケーションの各種デバイス発見標準間の相違を有利に隠す一方、ハードウェア抽象化層で用いるヘルパー機能を設け、ＩＰ、赤外線（ＩＲ）、Ｂｌｕｅｔｏｏｔｈ、８０２．１１ｘその他接続されているか、接続可能なデバイスまたはシステムの互換サポート構築を支援する。
【０４５０】
少なくとも１つの例示的ＤａｒｔＰｌａｔｆｏｒｍでは、コンテンツ、データおよび手順の適合のほとんどすべてが、エンジンに組み込む代わりに、Ｄａｒｔによって有利に実行される。対象デバイスでどのレンディションが一番よく動作するか決定するのはＤａｒｔ自身である。そして、それは接続されたＤａｒｔＤｅｖｉｃｅｓのコンテンツ再生を適合するＤａｒｔの手順である。
【０４５１】
ＤａｒｔＰｌａｔｆｏｒｍでは、デバイス間のプロトコルが非常に単純であるか、強力でもあるため、新しいデバイスが作業する各アプリケーションや他のデバイスについて計画を立てる必要はないのが有利である。１つのＤａｒｔＤｅｖｉｃｅが対象ＤａｒｔＤｅｖｉｃｅで自動的に動作する他のＤａｒｔＤｅｖｉｃｅにＤａｒｔＰｒｏｃｅｄｕｒｅを送り、Ｅｖｅｎｔまたは手順を返し、これが自動的に発信デバイスで動作または処理される。ＤａｒｔＤｅｖｉｃｅは自らが動作している手順またはＤａｒｔｓがデータ、アプリケーション、コントロールパネルを送っているのか、ケイパビリティを検査しているだけなのか知る必要がない。
【０４５２】
少なくとも１つの有利な実施例では、ＤａｒｔＰｌａｔｆｏｒｍはデバイス間インタオペラビリティのクライアント／サーバもピアツーピアモードも利用しない。その代わり、リクルートメントモデルを有利に利用する。
【０４５３】
リクルートメントおよびリクルートメントモデルと方法は、Ｄａｒｔアプリケーションがその到達範囲または接続性を複数の異なる接続およびデバイスに自動的に拡張できるようにする。リクルートメントは、クライアントサーバまたはピアツーピア接続性または通信からの根本的な逸脱で、ＤａｒｔＰｌａｔｆｏｒｍに、一意で高度に望ましい特性を与える。
【０４５４】
リクルートメントモデルの実施例により、Ｄａｒｔアプリケーションは、人が仕事をするためにチームを結成するのと同じ方法でアプリケーション周囲にデバイスのチームを結成することができる。１人が、家を建てたい建設業者だとすると、建設作業に必要な技術とリソースを持つ大工や木材供給業者を探す。そして、大工に木材を供給するためリクルートした供給業者や大工とチームとして作業し、家の建設を開始した業者の意図に従って家の建築を調整する。同様に、Ｄａｒｔアプリケーションは、対象デバイスで自動的に動作する手順を送信することにより、あらゆる既存通信媒体で通信可能な全てのＤａｒｔＤｅｖｉｃｅｓのリソースに到達し、これを検査することができる。動作中のＤａｒｔ自身は、ＤａｒｔＤｅｖｉｃｅのチームを発見し、認定し、結成し、チームのＤａｒｔＤｅｖｉｃｅが必要なあらゆるコンテンツおよびコードを送り、ユーザにとってアプリケーションを実行する。デバイスユーザの関わりは必要ない。
【０４５５】
Ｄａｒｔｓは、リクルートしたＤａｒｔＤｅｖｉｃｅｓにオペレーションを拡張し、すべてのＤａｒｔＤｅｖｉｃｅｓ内部で同時に有効に動作する。その結果、クライアント／サーバ構成またはオペレーションのような中央制御装置を有利に必要としないシステムとなる。Ｄａｒｔシステムは、ピアツーピア構成およびオペレーションとは反対に、発信デバイス以外のあらゆるデバイスに常駐するための発信Ｄａｒｔのミッションに関連するプログラムを必要としない。デバイスユーザは、メディアフォーマットや通信プロトコル、ドライバのローディングについて一切考える必要がない。リクルートメントモデルはまた、他のＤａｒｔＤｅｖｉｃｅがチームにリクルートされると、ＤａｒｔアプリケーションやデータがＤａｒｔデバイスからＤａｒｔデバイスへ自分自身を広げていくことができる。そのため、Ｄａｒｔｓとそのカプセル化されたコンテンツ、プログラムおよびデータの配信は、アプリケーションやその関連データの利用、明示的ローディングやセービングなしに行うことができて有利である。悪意ある、あるいは誤作動Ｄａｒｔｓまたは他のコードおよびデータの広がりを防止するため、セキュリティはＤａｒｔＰｌａｔｆｏｒｍの必要な一部である場合が多い。このセキュリティは、通信を許可しなかったり、他のデバイスからの手順またはＤａｒｔｓの動作を単純に拒否したりすることで、リクルートメントを受け入れたり拒絶したりする潜在的被リクルートデバイスを必要とする形式でやってくる場合がある。
【０４５６】
特に有利な実施例では、リクルートメントモデルと方法は、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔに基づく。この手順は、デバイスインタオペラビリティ、マルチメディアユーザインターフェースおよびリクルートメントモデルと方法の利用について最適化された、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔを用いて表現される。
【０４５７】
高級言語の大半は、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔを対象に有利にコンパイルできる。この時、特に有利な実施例では、使用する高級言語はＣ＋＋で、Ｃ＋＋プラグマ機能を通じて拡張が追加されている。これら利点は、Ｃ＋＋プログラミング言語の利用が現在広がっていることから生じるが、本発明は特定の言語に限定されず、現在存在しているか、Ｃ＋＋プログラミング言語の改良、強化および／または拡張などによって将来開発されるであろう他の言語でも等しく、あるいはよりよくインプリメントされる。
【０４５８】
インタオペラビリティセキュリティモデルまたはより固有の実施例、ＤａｒｔＳｅｃｕｒｉｔｙモデルのさらなる実施例について以下に述べる。一実施例（１）では、本発明はインタオペラビリティアプリケーションパッケージのリソースまたはケイパビリティおよび／またはインタオペラビリティデバイスのリソースまたはケイパビリティへのアクセスを制限し、および／またはこれを理解するための方法を提供し、この方法は、（１）少なくとも次の複数のステップを用いてセキュリティの基礎を形成することで、（ａ）デバイスに関連するエントロピー状態尺度を自動的に収集することと、（ｂ）キーペアを生成することと、（ｃ）デバイスＩＤを生成することと、（ｄ）キーペア、デバイスＩＤおよびエントロピー状態尺度を、デバイスがアクティブになった時に継続利用するため保存することとからなるものと、（２）限定アクセスを許可あるいは防止するためのルールの形成と、（３）少なくともデバイスについてセキュリティタスクを設けるため形成された基礎と形成されたルールを用いることとを含むことを特徴とする。
【０４５９】
別の実施例（２）では、本発明はインタオペラビリティアプリケーションパッケージのリソースまたはケイパビリティおよび／またはインタオペラビリティデバイスのリソースまたはケイパビリティへのアクセスを制限し、および／またはこれを理解するための方法を提供し、この方法は、（１）デバイスが最初にオペレーションを開始した時に次のステップの少なくとも１つでセキュリティの基礎を形成することで、（ａ）エントロピーを自動的に収集することと、（ｂ）パブリック／プライベートキーペアを生成することと、（ｃ）一意のデバイスＩＤの生成と、（ｄ）デバイスがアクティブになった時の継続利用のため、デバイス上の乱数ジェネレータのためにパブリックおよびプライベートキーペア、デバイス一意ＩＤ、エントロピー状態を保存することと、（２）制限アクセスを許可あるいは防止するためのルールを形成することと、（３）次のセキュリティタスクの１以上に形成された基礎を利用することで、（ａ）デバイス、アプリケーションおよびリソースへのアクセスのルールを実施することと、（ｂ）ルールが無許可のユーザまたはエージェントによって修正できないよう、ルール自体の安全確保と、（ｃ）乱数ジェネレータのためのパブリックおよびプライベートキーペア、デバイス一意ＩＤ、エントロピー状態の保存の安全確保と、（ｄ）アプリケーションおよびデバイス間で共有する動作パラメータまたはデータの安全確保と、（ｅ）通信チャンネルの安全確保と、（ｆ）特定のデバイスまたはデバイスセット、および／または特定のアプリケーションまたはアプリケーションのセットによって、および／または共有秘密を用いてアクセスされた時のみ理解または利用できるようリソースを暗号化することと、（ｇ）デバイス、アプリケーション、データフォーマット、収集、記録、個々のメディアファイル、または全デバイスおよび／またはアプリケーションおよび／またはデータセットまたはアイテム間で常に有効な個々のデータアイテムを識別するため、ユニバーサルに一意のＩＤを生成し、これを用いることとを含むことを特徴とする。
【０４６０】
別の実施例（３）では、本発明は（２）の方法を提供し、アクセスの制限に用いるルールの取り消しまたは修正をさらに含む。
【０４６１】
別の実施例（４）では、本発明は（２）の方法を提供し、リソースへの限定アクセスおよび／または理解は、次の１以上のあらゆる組み合わせを含むことを特徴とする：（１）デバイスが互いとの通信を許可されるデバイスと、デバイスが通信を許可された目的に関するルールを実施することと、（２）デバイス間を流れるデータを暗号化して、データにアクセスできるほかのデバイスが、データを理解したり利用したりできないようにすることと、（３）署名が発生してから、パッケージが修正されていないようにするため、データ、コンテンツコードその他リソースのパッケージに署名することと、（４）次のアクションの１以上に関してデータ、コード、コンテンツその他デジタル表現可能リソースの取り扱いに関するルールのセットを実施するデジタル権を管理することで、アクチュエータは、共有、コピー、印刷、表示、実行、配信、再生、レンダリング、実行、修正またはこれらのあらゆる組み合わせである。
ＸＶＩＩＩ．ソーシャル同期インタオペラビリティ方法／Ｄａｒｔソーシャル同期
【０４６２】
複数のデバイス間のデータセットまたはオペレーションの同期は、他の全てのデバイスがそのデータセットを直接同期させる単一のマスターデバイスが想定される場合は、従来の方法でしばしば実行される。これらの方法は、訓練された専門家が管理および維持する信頼できる高速ネットワークで互いと常に接続される汎用コンピュータの法人および政府ネットワークの高度に堅牢な同期システムを提供する。携帯電話、ＰＤＡ、デジタルカメラなど個人のデバイスの現在の同期の多くは、マスターデバイスがパーソナルコンピュータまたはインターネット接続サーバである単一マスターデバイス方法へ直接、これら同一のものを用いて従来のように実行しているが、大半がモバイルデバイスの間断的接続の世界では、単一マスターへの同期を必要とすることは、次を含む多くの理由から非常に限られている。
１．全てのデバイスが、マスターデバイスと少なくとも１つの通信プロトコルを共有しなければならない。
２．一部モバイルデバイスは、マスターとデータセットを同期させるのに適した有線または無線直接接続範囲が限られているため、マスターデバイスに近接している時しか同期できない。
３．マスターデバイスは全デバイスの障害の単一ソースを提供する。
４．訓練を受けていない個人ユーザは、マスターデバイス上のデバイス固有同期ソフトウェアのローディングとこのソフトウェアの構成および維持を気にしなければならない。
５．モバイルデバイスは、互いと近接していて、共通の通信プロトコルを共有していても、互いと直接同期するための簡単な方法がない。
【０４６３】
本発明のＳｏｃｉａｌＳｙｎｃｈｒｏｎｉｚａｔｉｏｎは、現状で広く利用されている従来のマスター式同期方法に対して多くの利点を提供するＤａｒｔＤｅｖｉｃｅ同期に用いることのできる方法の特定のサブセットである。ＳｏｃｉａｌＳｙｎｃｈｒｏｎｉｚａｔｉｏｎは、各デバイスがマスターデバイスとコンタクトしたり、いずれかのデバイスがマスターとして動作する必要なしに、あらゆる数のデバイスおよびプロトコルを通じてデータおよび／またはオペレーションの固有のセットを同期させるための方法を管理する効率的かつ容易な方法であることに注意する。デバイスおよびコンテンツのＳｏｃｉａｌＳｙｎｃｈｒｏｎｉｚａｔｉｏｎは、人間が情報やタスクを共有する方法と似ており、現状でよく用いられるマスター式同期技術の代替として有利である。
【０４６４】
当業の現状で広く用いられる従来のマスター式同期方法に対する本発明のシステムおよび方法の利点には以下を含む：
１．デバイスの全てが単一のマスターと直接通信できる必要がない場合、デバイスのチームに同期を実行可能で、しかも、互いとの間であらゆる数のデバイスの間に通信経路がある限り同期を実行可能で、かかる経路は同時に確立する必要がない。
２．モバイルデバイスがマスターと直接接続できる必要がないばかりでなく、同期を確立したデバイスのチームのモバイルデバイスの１つと直接接続できればよい。
３．マスターデバイスがないため、障害の単一原因もない。故障したチーム化デバイスは新しいデバイスと交換し、すぐにチームの他のデバイスと容易に同期することができる。
４．デバイスのいずれかにデバイス固有ソフトウェアをインストールしたり、このようなソフトウェアを積極的に維持または構成する必要がない。さらに、同期チームのあらゆるデバイスが他のデバイスをチームの直接追加することができる。
５．デバイスは、デバイス間のなんらかの接続のシーケンスを介して接続性の経路があるチームの他のデバイスと、このような接続が同時に利用可能でない場合でも直接同期可能である。
【０４６５】
ＳｏｃｉａｌＳｙｎｃｈｒｏｎｉｚａｔｉｏｎは、出会った他の人間と情報を共有し、それがさらに別に人間と同じ情報を共有するする人間のチームにやや似ている。人間との類似は、マスター式同期の制限の図解にも用いることができる。１人のボスに話しかける以外、同僚の活動やイニシアチブの全てに関する情報を共有する方法がない多数の従業員を擁する企業を考える。全ての知識を共有して一人のボスや、決まったボスの階層を通じて届くようにするには必要な情報すべてを流通させるのに必要なインタラクションが多すぎる。個々の従業員は、互いと遭遇したとき、互いに直接共通の関心のある情報を共有する必要があり、その情報が、仲介者を通じて知る必要のある他の従業員に流通されることを期待する。事実、このようなソーシャル同期の方法は、完全ではないが、人間やデバイスの間で間断的かつおそらく不規則な多数の接続が継続する場合、人やデバイスのグループまたはチーム間で情報を流通させる非常に効果的な方法である。
【０４６６】
図３０は、１つの好適な実施例で同期が実行される方法の例を示す。この例は、単純な変更の単純な連絡先リストとの同期を示すが、同期は複雑なデータベースについて実行されたり、データだけでなくＤａｒｔＤｅｖｉｃｅおよび／またはＤａｒｔｓチームのオペレーションおよびオペレーションの結果の同期もあることを理解しなければならない。
【０４６７】
図３０の例では、開始デバイス、Ａ、と、２個の入力名を当初含むＣｏｎｔｒｏｌＬｉｓｔ  Ｄａｒｔアプリケーションがある。この２個の他のデバイス、ＢとＣは、Ａで動作しているＣｏｎｔａｃｔＬｉｓｔ  Ｄａｒｔの存在や特性については最初何も知らない。１つの好適な実施例では、デバイスＡで動くＣｏｎｔａｃｔＬｉｓｔ  Ｄａｒｔは、連絡先のリストを含み、これを制御するＣｏｎｔａｃｔＬｉｓｔ  Ｄａｒｔ  を共有できる全てのデバイスを列挙する。ＣｏｎｔａｃｔＬｉｓｔ  Ｄａｒｔは、Ｄａｒｔリクルートメントの方法、および任意でレンダリングの方法を用いる。デバイスＡ上のＣｏｎｔａｃｔＬｉｓｔ  ＤａｒｔによるデバイスＢのリクルートメントは、ユーザが「他のデバイスへのチーム」メニューアイテムを選択することによって開始する。するとユーザは、現在到達可能で、到達可能なデバイスで動くよう送られた１以上のＤａｒｔＰｒｏｃｅｄｕｒｅまたはＤａｒｔｓの決定するＣｏｎｔａｃｔＬｉｓｔのチーム化に適したデバイスのリストを提示し、リクルートされた場合の適性に関する情報を返す。ユーザはリストからデバイスＢを選択し、その結果、ＣｏｎｔａｃｔＬｉｓｔ  Ｄａｒｔは、そのレンディションおよびコンテンツリスト要素を構成するデータの１以上または全てを含むＤａｒｔをセーブする。このセーブされたＤａｒｔがＲｕｎＤａｒｔタイプイベントの一部としてＢに送られる。ＤａｒｔがデバイスＢで動作すると、このデバイスがデバイスＡから切断されたりオフになった後でもＢで利用可能になるよう、自分自身をセーブする。こうして両デバイスで動作するようになったＤａｒｔは、各デバイスのＳｏｃｉａｌＳｙｎｃ  ｕｉｄリストにまだ存在しない場合はエントリを行う。このエントリは、Ｄａｒｔが最初の連絡先名のこの特定のリストを作ったときに生成された、共有すべき２つの名前のあるＣｏｎｔａｃｔＬｉｓｔのｕｉｄを含む。Ｕｉｄは、本書で別に説明するＤａｒｔＳｅｃｕｒｉｔｙインフラを用いて生成する。このエントリはまた、ＣｏｎｔａｃｔＬｉｓｔ  Ｄａｒｔのｕｉｄも含む。ＤａｒｔＴｏｏｌｓは生成した各Ｄａｒｔインスタンスに自動的にｕｉｄを入れる。
【０４６８】
同様に、デバイスＡがＢとの恒久的チーム化オペレーションを終えてしばらくすると、デバイスＢを用いて、連絡先リストの特定のチーム化論理インスタンスを識別する１２８ＢｉｔＵｉｄＡのエントリと共に、ＯｂｊｅｃｔＵｉｄ／ＤａｒｔＨａｎｄｌｅｒＵｉｄリストに恒久的にチーム化する。このエントリも、リストの連絡先の同期を実行するために利用できる同じデバイス上に保存されたＤａｒｔのＵＩＤを含む。一般に、ハンドラＤａｒｔは、Ｄａｒｔとして表現可能なあらゆる同期決定またはオペレーションまたはルールを実行することができ、この例のように、単純なデータ同期オペレーションに限られないことに注意する。
【０４６９】
この３つのデバイスがこれで全て、デバイスＣがデバイスＡと直接通信したことがなくても、当初の連絡先リストのＵＩＤと２つの名前の入ったＳｏｃｉａｌＳｙｎｃエントリを含むことになる。
【０４７０】
この例では、デバイスがチーム化された後、接続が閉じられ、新しい名前がＣｏｎｔａｃｔＨａｎｄｌｅｒＤａｒｔ  Ｚを動かすユーザによってデバイスＣのリストに追加される。この３個のブロック図は、第３の名前がデバイスＣに追加された直後の３個のデバイスの状態を示す。
【０４７１】
次に、ＣｏｎｔａｃｔＨａｎｄｌｅｒＤａｒｔ  Ｚその他Ｃで動作するデバイスが、デバイスＡとの接続を開始する。接続をセットアップしている間、ＣのＤａｒｔＥｎｇｉｎｅが自動的に２個のデバイス上のＳｏｃｉａｌＳｙｎｃ  ｕｉｄを比較し、１２８ＢｉｔＵｉｄＡ  Ｕｉｄの共有を判断する。ＣのＤａｒｔＥｎｇｉｎｅは自動的にＣｏｎｔａｃｔＨａｎｄｌｅｒＤａｒｔ  Ｚを起動し、Ｄａｒｔｓに保存されるか、別に保存されるかを問わず、データの同期を調整する。こうして、デバイスＡおよびＣはその連絡先リストに３つの名前全てを含むことになる。
【０４７２】
デバイスＢがＡかＣに接続した後、同様にＣｏｎｔａｃｔＨａｎｄｌｅｒＤａｒｔ  Ｙを動作させ、これがデバイスＢと接続先のデバイスとの間の名前の同期を実行する。Ａが同期前にＣと一度も通信したことがなくとも、個々のチーム化中に仲介デバイスＢがパスするＤａｒｔとデータのため、同期する必要があることと、同期方法がわかっている。
【０４７３】
新しいデバイスが、Ｃｏｎｔａｃｔｌｉｓｔ／ＣｏｎｔａｃｔＨａｎｄｌｅｒ  Ｄａｒｔまたは発信Ｄａｒｔについてチーム化されるまで何も知らなくとも、論理的に、あらゆる数のデバイスをすでにチーム化されたデバイスにより過渡的に容易にチームに追加できることになる。デバイスのチーム間の特別な接続が十分である限り、マスターデバイスが存在しなくとも、全てのデバイスが自動的に連絡先の共有リストの高度な同期を維持する。
【０４７４】
本発明のシステム、方法およびコンピュータプログラムとコンピュータプログラム製品はまた、直列化および同期を有するプラットフォームを提供する。図１５、図１６、および図１８に示すデバイス間ＤａｒｔＲｕｎｔｉｍｅと、図１７に示すデバイス間ＤａｒｔＲｕｎｔｉｍｅは共に、チーム化デバイスの全処理ユニットを通じて有利に慎重に直列化および同期される場合、単一イベント駆動ＤａｒｔＲｕｎｔｉｍｅを生成する。図９は、この直列化および同期インフラが、Ｄａｒｔ  リクルートメント、Ｄａｒｔレンディショニング、ＤａｒｔＳｏｕｒｃｅ、ＤａｒｔＴｏｏｌｓ、ＤａｒｔＦｒａｍｅｗｏｒｋ、ＤａｒｔＲｕｎｔｉｍｅおよびＤａｒｔＥｎｇｉｎｅを含むＤａｒｔＰｌａｔｆｏｒｍを通じて具現化されるのを示す。これらシステムと方法および手段は共に、通信その他エラーに直面しても、Ｄａｒｔプログラマ側が複雑なインタラクションのセットアップや管理、複数のデバイス上またはその間で協働する処理ユニット間のオペレーションの順序付けを行う必要のほとんどないＤａｒｔインタオペラビリティアプリケーションのための堅牢なインタオペラビリティを確保するためのインフラを提供する。
【０４７５】
ＤａｒｔＰｌａｔｆｏｒｍ、特にＤａｒｔＦｒａｍｅｗｏｒｋを用いてＤａｒｔアプリケーションを書くことにより、ＤａｒｔＤｅｖｉｃｅ全体にアプリケーションバイナリポータビリティ、堅牢なパワーマネージメント、堅牢なアプリケーションレベルのエラー回復、単純で効率的なデバイスのチーム化、デバイス全体のインテリジェントな発見とリソースの利用、ＤａｒｔＰｌａｔｆｏｒｍのほかの利点の多くを自動的に与える。これら利点を可能にする中心的要素は、図９の例に示すように、イベントの大きく自動的な直列化および同期を通じてＤａｒｔＲｕｎｔｉｍｅの具現化される。
【０４７６】
ＤａｒｔＲｕｎｔｉｍｅは、相互運用および通信中の開始およびリクルートされたデバイスの間でＤａｒｔイベントと関連ファイルのパスまたは交換を調整する。Ｄａｒｔイベントは、あらゆる数のチーム化デバイスのイベント待ち行列で自動的にコピーおよび／または同期される。同期イベントと指定されたイベントは、同期イベントタイプのリストを共有する全てのデバイスのイベント待ち行列全体に堅牢に配信される。これは、図９に示す例で次のように実行される：
１．開始アプリケーション、Ｄａｒｔ７００のレンディション７０１ａが、固有の未指定のデバイス間協力機能について発信デバイス４００−１上で接続マネージャオブジェクトインスタンスを作成する。この接続マネージャは、ＤａｒｔＦｒａｍｅｗｏｒｋ（図３、ｌ０２）の一部としてＤａｒｔＰｌａｔｆｏｒｍ（図３）に設けられるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒクラスのインスタンスである。
２．開始レンディション、７０１ａは、リクルートメントとレンディショニングを用いてデバイスのチームをリクルートし、全ての協力デバイスで直列化および同期するイベントタイプの共有重複可能リストを有するデバイスのチームを結成する。このリストは、チーム化デバイス（４００−１、４００−２、４００−３、４００−Ｎ）のそれぞれで接続マネージャ４２０のインスタンスによって維持される。
３．共有リスト中のチーム化デバイスのいずれかの待ち行列にイベントを入れる時は常に、イベントはまず、全ての直接接続されたチーム化デバイスの全待ち行列（６６０）に入れてから、イベントが全ての直接チーム化デバイスの待ち行列に入れられたという肯定応答を受け取るまで、開始デバイスの待ち行列にイベントを入れることを遅延させる。全てのデバイスが同じことをするため、開始デバイスに直接接続されていないデバイスでも、全てのほかのチーム化デバイスの待ち行列にイベントが入るまで、開始デバイスに当初イベントは入れられない。これにより、チーム化デバイスの待ち行列のいずれかでイベントの設置を妨害する何らかのエラーがある場合、チーム化デバイスのいずれによってもイベントが処理されないようにする。エラーは、イベントがリターンステータスであることを示すエラーフラッグと、イベント構造インスタンスの返された値ワードにエラーコードを入れて、当初イベントの直列伝達リターンによって送り主に報告される。
４．１つのデバイスで生成されたイベントが、直接接続されたデバイスに順序を外れて到着するのを防ぐため、前に送ったイベントが待ち行列に入れられたとの肯定応答を受信するまで、直接接続されたチーム化デバイスのイベント待ち行列に入れる全てのイベントは、チーム化デバイスの待ち行列に新しいイベントを入れないようにすることで直列化する。必然的にこのようになる例は、第１のイベントが新しいスライドショーを共有スライドショーに追加するため用いたＡＤＤ＿ＳＬＩＤＥタイプイベントで、第２のイベントが、新しいスライドを表示することを示すショースライド（ＳＨＯＷ＿ＳＬＩＤＥ）タイプイベントの場合である。そのサイズがはるかに小さいため、第２のイベントは、第１およびアプリケーションがその到着を終える前、スライドを表示しようとする前にデバイスに到着してしまう可能性が高い。全ての直接接続デバイス間でイベントを直列化しなければならないのはこのためである。
【０４７７】
全ての直接接続デバイスに送られたイベントの直列化により、個々のデバイスから送られた全てのイベントがチーム化デバイス全てで正確に送られた順序で処理されるようにするが、２以上の異なるデバイスが独立して、全てのチーム化デバイス上のある共有同期イベントリスト４３０上で同期とマークされたイベントをシグナリングする時は、イベントの正確な順序も同期する必要がある。
【０４７８】
同期イベントが２以上のデバイスが独立してシグナリングしなければならない時でも、全同期イベントが全デバイスで同じ順序で処理されるようにする一実施例が、接続マネージャ用に留保されるＭａｓｔｅｒＳｅｎｄＥｖｅｎｔイベントタイプの利用である。各接続マネージャは、直接接続によってリクルートを行ったデバイスをその論理マスターとみなす。図９において、デバイス４００−Ｎの論理マスターはデバイス４００−３、デバイス３００−４の論理マスターはデバイス４００−３、デバイス４００−３の論理マスターはデバイス４００−１である。デバイス４００−１は、チームの開始リクルートメントを実行したため、論理マスターを持たない。これにより、デバイス４００−１がチームマスターになる。接続マネージメントがＭａｓｔｅｒＳｅｎｄＥｖｅｎｔイベントタイプのイベントにイベントをシグナリングしてそれを全ての直接接続チーム化デバイスに入れるのに必要な情報を全てカプセル化するのではなく、論理マスターの接続マネージャのあるデバイスはその論理マスターによって入れられるまで、待ち行列に入れるべきイベントを待ち行列に入れない。このようなＭａｓｔｅｒＳｅｎｄＥｖｅｎｔイベントは必然的にチームマスターに伝播する。このイベントを待ち行列に入れる時、それがチームマスターであることを知る接続マネージャは再構成した当初含まれるイベントをその待ち行列に入れようとする。含まれるイベントのタイプが接続マネージャの同期リストにある場合、それは、チームマスターによって生成され、シグナリングされたかのように、直列化されて全てのチーム化デバイスに伝播される。
【０４７９】
実際、チームマスターは、他のチーム化デバイスの待ち行列に入れる同期イベントを送ることができる唯一のデバイスである。他の全てのデバイスは、マスターになんらかの同期イベントを送るよう要求する必要がある。同期イベントは全てチームマスターが直列化チャンネルを介して送られるため、チームの全デバイスは、正確に同じ順序で待ち行列に全てのイベントを受信し、全チーム化デバイス全体で同期オペレーションの整合性が所望どおり保全される。
【０４８０】
一実施例では、同期イベントの直列化が自分自身を利用し、全デバイス上の接続マネージャが同期するイベントタイプの正確に同じリストを維持することができる。また、直列化システムを用いて、新しいデバイスをチームマスターとみなすことを示すタイプの直列および同期イベントを送ることができる。新しいマスターを宣言したイベントを直列化および同期するため、全デバイスが正確に同じ順序でこのようなイベントを受け取り、イベントを送る複数のデバイスが異なる新マスターを宣言しても、全デバイスが新マスターを宣言する同一の最後のイベントを取得することで必然的に自身を解決し、最後のこのように処理されたイベントが勝つことになる。
【０４８１】
ソーシャル同期インタオペラビリティ方法を含む本発明の特定の実施例または１以上の特定のＤａｒｔ  ＳｏｃｉａｌＳｙｎｃｈｒｏｎｉｚａｔｉｏｎについて以下に述べる。一実施例（１）では、本発明は、１以上のダイナミックに生成された、他のチーム化デバイスとの間で独立して間断的に行うことができる直接接続のシーケンスを通じて間断的に直接接続、および／または間接的に接続できる類似および／または非類似デバイスのチーム間でリソースの同期を維持するための方法を提供し、この方法は、（１）インタオペラビリティデバイス上で、同期する単数または複数のリソースを論理的または物理的にカプセル化し、および／または同期するリソースの収集および管理に必要な全てのケイパビリティを含む１以上の独立して実行可能なイメージのインタオペラビリティアプリケーションプログラムパッケージを開始することと、（２）他のデバイスと間断的接続が可能な場合、インタオペラビリティアプリケーションプログラムを開始することにより他のデバイスとチーム化し、開始アプリケーションがインタオペラビリティ情報を新規にチーム化したデバイスに広げることとを含むことを特徴とする。
【０４８２】
別の実施例（２）では、本発明は（１）の方法を提供し、この方法は任意でさらに、（３）１上のチーム化デバイスで動作するインタオペラビリティアプリケーションパッケージが開始インタオペラビリティアプリケーションプログラムパッケージとして動作する場合、他のデバイスとのチーム化を反復し、デバイスのチームが制限的あるいは無制限的に成長し続けるようにすることを含むことを特徴とする。
【０４８３】
別の実施例（３）では、本発明は（１）の方法を提供し、この方法は任意でさらに、（４）デバイス間でリソースを同期することを含むことを特徴とする。
【０４８４】
別の実施例（４）では、本発明は（１）の方法を提供し、この方法は任意でさらに、（３）１上のチーム化デバイスで動作するインタオペラビリティアプリケーションパッケージが開始インタオペラビリティアプリケーションプログラムパッケージとして動作する場合、他のデバイスとのチーム化を反復し、デバイスのチームが制限的あるいは無制限的に成長し続けるようにすることと、（４）デバイス間でリソースを同期することとを含むことを特徴とする。
【０４８５】
別の実施例（５）では、本発明は（３）の方法を提供し、同期方法はさらに任意で、（ａ）いずれか２つのチーム化デバイスの間で通信セッションを開始することと、（ｂ）１デバイスの同期一意ＩＤを他のデバイスの同期一意ＩＤと比較することと、（ｃ）一致する一意ＩＤと関連するインタオペラビリティアプリケーションプログラムを動作させることと、（ｄ）両デバイス間にインタオペラビリティアプリケーションプログラムの実行を広げることと、（ｅ）２つのデバイスにオペレーションを広げたインタオペラビリティアプリケーションプログラムによって、インタオペラビリティ同期目的を実行するために必要なあらゆる同期方法を実行することを含むことを特徴とする。
【０４８６】
別の実施例（６）では、本発明は（４）の方法を提供し、同期方法はさらに任意で、（ａ）いずれか２つのチーム化デバイスの間で通信セッションを開始することと、（ｂ）１デバイスの同期一意ＩＤを他のデバイスの同期一意ＩＤと比較することと、（ｃ）一致する一意ＩＤと関連するインタオペラビリティアプリケーションプログラムを動作させることと、（ｄ）両デバイス間にインタオペラビリティアプリケーションプログラムの実行を広げることと、（ｅ）２つのデバイスにオペレーションを広げたインタオペラビリティアプリケーションプログラムによって、インタオペラビリティ同期目的を実行するために必要なあらゆる同期方法を実行することを含むことを特徴とする。
【０４８７】
別の実施例（７）では、本発明は（１）の方法を提供し、インタオペラビリティ情報は、（ｉ）そのデバイスが同期目的のためのチーム化されることを意味するために用いる１以上のインタオペラビリティのユニバーサルに一意なＩＤと、（ｉｉ）同期目的を実行するために実行可能なユニバーサルに一意のＩＤと関連する１以上のインタオペラビリティアプリケーションパッケージを含むことを特徴とする。
【０４８８】
別の実施例（８）では、本発明は（６）の方法を提供し、インタオペラビリティ情報は、（ｉ）そのデバイスが同期目的のためのチーム化されることを意味するために用いる１以上のインタオペラビリティのユニバーサルに一意なＩＤと、（ｉｉ）同期目的を実行するために実行可能なユニバーサルに一意のＩＤと関連する１以上のインタオペラビリティアプリケーションパッケージを含むことを特徴とする。
【０４８９】
別の実施例（９）では、本発明は（１）の方法を提供し、次の１以上があらゆる組み合わせで真であることで、（１）デバイスリクルートメント手順またはＤａｒｔ  リクルートメントを用いて少なくとも部分的にチームを結成し、（２）インタオペラビリティデバイスの１以上がＤａｒｔＤｅｖｉｃｅで、（３）インタオペラビリティアプリケーションプログラムパッケージはインタオペラビリティフォーマットに従うか、ＤａｒｔＦｏｒｍａｔに従うか、Ｄａｒｔである、（４）独立して実行可能なイメージはレンディションであるか、Ｄａｒｔレンディションである、（５）リソースは、インタオペラビリティソースの説明によりリソースと説明されるタイプの１以上である、（６）インタオペラビリティのユニバーサルに一意のＩＤを、ソーシャルセキュリティ手順ベースを用いて生成する、（７）リクルートメント方法またクリエイショニズム方法をいずれか、または両方を用いて１以上のインタオペラビリティアプリケーションプログラムパッケージを生成する。
【０４９０】
別の実施例（１０）では、本発明は（１）の方法を提供し、同期は、次の１以上のあらゆる組み合わせを含む：（１）独立したインスタンスおよび／または共通に識別されるデータベースインスタンスのセマンティックスおよび／または別個インスタンスに独立して行われた変更は、次の１以上を維持するため必要なあらゆる方法で解決するよう、データベースまたはデータベースに含まれる要素によって保持できるあらゆるものを維持することで、（ａ）意図するデータおよび共通識別に関連する目的をカプセル化する際のデータベースの整合性、（ｂ）データベースの要素、（ｃ）データベースのセマンティックスおよび／またはデータベースの要素の相関関係、（ｄ）データベースのインスタンスの共通アイデンティティと、（２）独立して保存される、および／または独立デバイス上で修正されるアイテムのリスト上の要素の追加、削除または修正、（３）デバイスのチームによる情報の収集および／または処理および／または照合、（４）デバイスのリソースまたはケイパビリティを制御したり、アクセスを制限したりするために必要な一意ＩＤ、共有秘密およびセキュリティ設定のリストの維持、（５）デバイスまたはデバイスセットのオペレーションを実行する背亭のデバイス間管理、（６）複数デバイス間の構成管理、（７）複数デバイス間のソフトウェアまたはコンテンツのインストール、（８）デバイスおよび／またはデバイスのリソースまたはデバイスで到達可能なもの、またはそのためにデバイスの１以上で情報を保存しているものおよび／または維持しているものの記録、（９）複数デバイス間のソフトウェアまたはコンテンツ分散またはアップデート、および（１０）上記のいずれかの組み合わせ。
ＸＩＸ．ソーシャルセキュリティインタオペラビリティモデル／Ｄａｒｔ  ＳｏｃｉａｌＳｅｃｕｒｉｔｙ
【０４９１】
ＳｏｃｉａｌＳｅｃｕｒｉｔｙは、間断的接続デバイスのチーム間でセキュリティのウェブを形成する方法を管理するのに特に単純であることに注意する。ＳｏｃｉａｌＳｅｃｕｒｉｔｙは、人間が他の人間を信頼するようになるやり方とよく似ている。ＳｏｃｉａｌＳｅｃｕｒｉｔｙの基礎は、ＤａｒｔＳｅｃｕｒｉｔｙシステムを、デバイスからデバイスへ横に移動する許可されたアクセス権と共に用いて生成した一意のＩＤを広げるＳｏｃｉａｌＳｙｎｃｈｒｏｎｉｚａｔｉｏｎの利用である。直接通信したことのないデバイスはしばしば自分たちがさらに許可を集める必要なくある種のアクセス権で相互運用が許されたデバイスチームの一部であることを発見する。
【０４９２】
当業の現状で最も大きな問題の１つが、エンドユーザがセキュリティ方法を理解管理することが非常に難しいため、まったく利用しないで終わってしまうことである。利用されるセキュリティ方法の強みと管理の複雑性との間には直接的関係がある。従来の法人および政府コンピュータネットワークでは、高度な強みが必要と考えられ、必然的に高度な訓練を受けた常勤専門家によって管理されていた。このようなネットワークが再構成されることは少ないという事実が、専門家の管理量を妥当なものにしていた。これら同様の従来型セキュリティ方法が、訓練を受けておらず、モバイルデバイスの消長に伴いコンスタントが管理を必要とするデバイスのネットワークを保全するフルタイムの管理のための時間や辛抱がない個人によって用いられるモバイルデバイスの進化と成長に適用されることがしばしばある。本発明のＳｏｃｉａｌＳｅｃｕｒｉｔｙ方法は、法人および政府ネットワークに採用される従来の方法ほど強力ではないかもしれないが、優れたレベルのセキュリティを提供する一方、デバイスの管理が容易で、ほとんどの人が実際に利用するようになるため、従来の方法は利用しないか停止することになる。そのため、ＳｏｃｉａｌＳｅｃｕｒｉｔｙはセキュリティが利用されなかったである状況に優れたレベルのセキュリティを有利に提供する。
【０４９３】
Ｅメールがよい例である。従来のセキュアなＥメールプロトコルが利用され、Ｅメールを使い始めて以来、既存Ｅメールユーザのクライアントソフトウェアの大半に内蔵されているが、ＥメールのエンドユーザでこれらセキュアなＥメールプロトコルを利用している人はほとんどいない。その理由の１つは、証明書を入手、保全および利用して、Ｅメールを安全に送りたい相手が全員、証明書を入手、保全、利用するのに必要な管理も実行しなければならないことが、複雑で手間がかかるからである。もう１つの例が、無線アクセスポートでセキュリティをセットアップするのが難しいため、多くの家庭内無線ネットワークがセキュアでないままになっていることである。
【０４９４】
ＳｏｃｉａｌＳｅｃｕｒｉｔｙは、インタラクションを保全するための人間の方法に類似している。ある人が会社の占有情報を新入社員に任せられるとわかるのは、その新入社員が社内のほかの人に紹介されたからである。古い社員は、その新入社員が会社の真正な社員であるというオリジナルな知識を持つ人と直接話すことさえなく、その新入社員を信頼するようになることはよくある。中央調整や追跡の必要なく、信頼のウェブが確立される。携帯電話、プリンタ、ＰＤＡ、ラップトップ、デジタルカメラ、ポータブル音楽プレイヤ等のデバイスは、共有すべき媒体、情報または制御を持つことが多いが、これら全てが一度に１つの中央ソースに接続されていることはない。それどころか、他のデバイスやソフトウェアによる不正な利用や改悪からデバイス上の情報の整合性を守るためのセキュリティ方法を用いることが望ましい。ＤａｒｔＰｌａｔｆｏｒｍのＳｏｃｉａｌＳｅｃｕｒｉｔｙ方法は、本発明のインタオペラビリティセキュリティまたは本発明のＤａｒｔＰｌａｔｆｏｒｍのＤａｒｔＳｅｃｕｒｉｔｙ方法の特定のサブセットで、アクセス権はデバイスからデバイスへパスされ、デバイスおよびソフトウェアまたはデバイスユーザ側に必要な管理や訓練が最小限のアクセス権の特定セットを持つＤａｒｔｓの信頼されるウェブを自動的に確立する。
【０４９５】
ＳｏｃｉａｌＳｅｃｕｒｉｔｙ方法は、本書で別に説明するＤａｒｔＳｅｃｕｒｉｔｙ方法を基に構築する。ＤａｒｔＳｅｃｕｒｉｔｙ（図２９）は、各ＤａｒｔＤｅｖｉｃｅおよびＤａｒｔアプリケーションがユニバーサルに一意の識別子、ＵＩＤを持つようにしている。各ＤａｒｔＤｅｖｉｃｅはまた、バイナリフラッグのセットの示す許可されたアクセス権であるほかのＤａｒｔＤｅｖｉｃｅのＵＩＤのリストを維持する。バイナリアクセス権の各セットはレベルに割り当てられる。
【０４９６】
ＳｏｃｉａｌＳｅｃｕｒｉｔｙは、デバイスのチームを結成し維持し、チーム化されたデバイス全体で共通のアクセス権を持つデバイスのリストを分配および維持するための過渡的方法である。図３１は、ＤｅｖｉｃｅＳｅｃｕｒｉｔｙリスト、取り消されたリスト、ＳｏｃｉａｌＳｅｃｕｒｉｔｙのＤｅｖｉｃｅ  Ｕｉｄ要素とＤａｒｔＤｅｖｉｃｅを左側に示す。図示のＳｏｃｉａｌＳｙｎｃリストは、本書で別に説明するソーシャル同期方法の一部で、デバイス間でＤａｒｔＬｉｓｔｓを過渡的に広げ、同期させるために少なくとも部分的に好適な実施例で用いられる。
【０４９７】
図３１の右側は、ＳｏｃｉａｌＳｅｃｕｒｉｔｙ方法の図解を助けるため、チーム化前後の新旧ＤａｒｔＤｅｖｉｃｅの状態例を示す。この例では、チーム化前は、古いＤａｒｔＤｅｖｉｃｅ  ｕｉｄＡがアプリケーションとデバイスのｕｉｄのリストを有し、これがリストのレベルに対応するフラッグのアクセス権内で相互運用が許される。チーム化前、新しいＤａｒｔＤｅｖｉｃｅ  ｕｉｄＺのＤｅｖｉｃｅＳｅｃｕｒｉｔｙリストのみがデバイス自身をレベル９において自身と相互運用可能にする。通常、メーカーからデバイスと共に出荷されたＤａｒｔアプリケーションの一部は、デバイス構成する高レベルのアクセスおよび／またはデバイスのセキュリティ側面を必要とするため、デバイスはデバイス自身のレベル９リスト中のｕｉｄで示す高レベルのアクセスをデバイスのアプリケーションに与える。
【０４９８】
新しいデバイスのＤａｒｔが古いデバイスとそのデバイスの最初の接触を開始し、古いデバイスで動作させるため自身のレンディションから生成したＤａｒｔを送信および動作させようとすると、Ｄａｒｔと新しいデバイスのアクセス権がチェックされる。当然、古いデバイスは新しいデバイスについて何も知らず、この例では、古いデバイスに実行を広げようとしているＤａｒｔアプリケーションのアクセス権についてセキュリティ情報を持たない。この例では、ユーザはこれらデバイスがＤａｒｔのフラッグによって通信されたアクセスニーズにしたがって相互運用するための許可を、各デバイス上のユーザインターフェースを介して要求される。図３１は、右下に、デバイスがレベル７で相互運用する許可を与えられた後のデバイスの状態を示し、これは古いデバイスにパスされたＤａｒｔ指定の全てのアクセス権を与えるアクセスフラッグセットに対応する。ユーザインターフェースを介してユーザから許可を得た後、新旧ＤａｒｔＤｅｖｉｃｅはデバイスとＤａｒｔｓのｕｉｄの同一のレベル７リストを含むことになり、許可を求めることなく相互運用が許される。新しいＤａｒｔＤｅｖｉｃｅが次に、同じセキュリティアクセスフラッグ要件を持つ新しいレベル７リストで他のデバイスのいずれかにＤａｒｔを送ろうとすると、ユーザに訪ねる必要なく動作が許可されることに注意する。実際、デバイスは自分が知っている他のデバイス全ての保証をしていることになる。信頼されるデバイスのチームは、チームのｕｉｄのリストが、間断的であってもチームの他のデバイスに接続を通じて分配されていれば、以前に直接コンタクトがないデバイスでも互いに信頼することになる。好適な実施例では、ｕｉｄのリストは、本書で別に説明するソーシャル同期方法の一部を用いて同期される。
【０４９９】
チームの結成および維持にユーザの関与または理解を必要とする唯一の管理は、デバイスが必要な方法で相互運用を開始できるために与えられなければならないアクセスの種類に関して直接質問する能力だけであったことに注意する。デバイスおよびＤａｒｔｓデバイスを利用する単純なタスクで、ユーザからの許可を求める少数の理解しやすい要求でアクセス権を収集および分配する。
【０５００】
デバイスのアクセス権の取り消しも、ＳｏｃｉａｌＳｅｃｕｒｉｔｙを用いてＤａｒｔｓのデバイスの取り消されたｕｉｄのリストを広げることによって達成できる。好適な実施例では、必要な権利を有するデバイスの取り消されたリストの中の１つであるデバイス間での相互運用の試みは許されず、適切なセキュリティレベルの取り消されたデバイスのチームのリストにあるｕｉｄは削除される。
【０５０１】
本発明のソーシャルセキュリティインタオペラビリティモデルおよびこのモデルのより固有なバージョン、Ｄａｒｔソーシャルセキュリティモデルの追加実施例を以下に示す。一実施例（１）では、本発明はインタオペラビリティデバイス間でアクセス権と証明書を自動的かつ過渡的に広げる方法を提供し、この方法は、（１）各インタオペラビリティデバイスに一意のｉｄを割り当てることと、（２）各インタオペラビリティデバイスにアクセス権の初期セットを割り当てることと、（３）各インタオペラビリティソフトウェアパッケージに、１以上の一意のｉｄを割り当て、パッケージ中に、アプリケーションパッケージの一部である独立して実行可能なイメージの全ておよび／またはそれぞれが必要とする一意のｉｄセットと関連するアクセス権を埋め込むこととを含み、（４）２つのインタオペラビリティデバイスが通信チャネルを開くと、いずれかのデバイスでの２個のデバイスのインタオペラビリティに既存のものと同程度に制限的な一意のｉｄと関連するデバイスチームまたはアプリケーションの既存のアクセス権が、他方のデバイスでそれらと同期される。
【０５０２】
別の実施例（２）では、本発明は（１）の方法を提供し、次の１以上が真である、（１）インタオペラビリティデバイスは、Ｄａｒｔデバイスを備え、（２）一意ｉｄの基礎は、インタオペラビリティセキュリティ手順である、（３）アクセス権は、インタオペラビリティセキュリティ手順で説明した通りである、（４）パッケージは、インタオペラビリティソフトウェアパッケージおよび／またはＤａｒｔである、（５）通信チャンネルの開放は、デバイスリクルートメント手順の一部として開始する、（６）アクセス権は、ソーシャル同期手順を用いて同期する。
【０５０３】
別の実施例（３）では、本発明は（１）の方法を提供し、この方法は次のステップで実行され、（１）特定のインタオペラビリティ目的を実行するため、開始インタオペラビリティデバイスで動作するインタオペラビリティソフトウェアパッケージから対象インタオペラビリティデバイスへ通信セッションを開始することと、（２）意図する目的のためデバイス間に正しいアクセス権が存在するか否かを決定することと、（３）正しいアクセス権が存在する場合、アプリケーションソフトウェアパッケージが、独立して実行可能なイメージを対象デバイスに送り、必要なアクセス権を持つコンテキストでイメージを動作させることにより、その実行を拡張できるようにすることとを含む。
ＸＸ．インタオペラビリティデバイス／ＤａｒｔＤｅｖｉｃｅ
【０５０４】
ＤａｒｔＤｅｖｉｃｅは、ＤａｒｔＥｎｇｉｎｅと、他のＤａｒｔＤｅｖｉｃｅｓに接続するための少なくとも１つの通信プロトコルを含むＤａｒｔＰｌａｙｅｒを動作させることにより、高度に相互運用可能なデバイスである。インタオペラビリティデバイスとより特定化されたＤａｒｔＤｅｖｉｃｅｓの側面を図３（３００）および図４（３０００）に示す。
【０５０５】
一実施例（１）では、本発明はインタオペラビリティデバイスを提供し、これは、（１）一般的コンピュテーションおよび／または入力／出力オペレーションを実行可能な物理的メモリと連結された物理的チューリング完全命令セットプロセッサと、（２）他のデバイスとの２方向通信のための少なくとも１つの手段と、（３）プロセッサで動作し、デバイスにロード可能で実行可能な実行可能フォーマットで埋め込まれたインタオペラビリティプレイヤにカプセル化されたインタオペラビリティエンジンとを含むことを特徴とする。
【０５０６】
別の実施例（２）では、本発明は（１）のインタオペラビリティデバイスを提供し、これはさらに、インタオペラビリティプレイヤを含むことを特徴とする。
【０５０７】
別の実施例（３）では、本発明は（１）のインタオペラビリティデバイスを提供し、次の１以上がそれだけ、あるいはあらゆる組み合わせで真である、（１）インタオペラビリティデバイスはＤａｒｔＤｅｖｉｃｅである、（２）インタオペラビリティエンジンは、ＤａｒｔＥｎｇｉｎｅを備える、（３）インタオペラビリティプレイヤはＤａｒｔＰｌａｙｅｒである。
【０５０８】
別の実施例（４）では、本発明は、他の類似または非類似デバイスとインタオペラビリティモードでデータを作動させる方法を提供し、この方法は、（１）物理的メモリに連結され、組み合わされて一般的コンピュテーションおよび／または入力／出力オペレーションを実行可能なプロセッサ内で実行可能な物理的チューリング完全命令セットを設けることと、（２）少なくともこのデバイスと別のデバイスとの間で２方向の通信を送受信することと、（３）データベースでロード可能および実行可能な実行可能フォーマットで具現化されたインタオペラビリティプレイヤにカプセル化されたプロセッサ上のインタオペラビリティエンジンを動作させることとを含む。
ＸＸＩ．  インタオペラビリティプラットフォーム／ＤａｒｔＰｌａｔｆｏｒｍ
【０５０９】
ＤａｒｔＰｌａｔｆｏｒｍは、ＤａｒｔＤｅｖｉｃｅｓの仕様、生成、インテリジェントなチーム化を実行でき、１以上のＤａｒｔＤｅｖｉｃｅ間でＤａｒｔインタオペラビリティアプリケーションのスプレッドと実行を容易にできるあらゆるＤａｒｔ方法セットでよいことに注意する。インタオペラビリティプラットフォームの側面と、一般的インタオペラビリティプラットフォームの特定のＤａｒｔＰｌａｔｆｏｒｍについて、図３と詳細な説明の他の部分に示す。
【０５１０】
ＤａｒｔＰｌａｔｆｏｒｍが固有の例であるインタオペラビリティプラットフォームの追加実施例について以下に述べる。一実施例（１）では、本発明は、複数の非類似デバイス間で、セキュアで信頼性高く、効率的で堅牢な方法で独立して実行可能なイメージのインタオペラビリティソフトウェアパッケージの意図を指定、構築、分配、実行するためのシステムを提供し、このシステムは、（１）インタオペラビリティコンピュータプログラムソフトウェアパッケージを指定するためのインタオペラビリティソースと、（２）手順的命令を構築するためのインタオペラビリティツールと、（３）少なくとも手順的命令をパッケージ化するためのインタオペラビリティフォーマットと、（４）インタオペラビリティツールの生成した手順的命令を表すためのインタオペラビリティ命令セットと、（５）すべてのインタオペラビリティデバイス上で、インタオペラビリティソフトウェアパッケージを実行し、共通のインタオペラビリティインフラを与えるためのインタオペラビリティエンジンと、（６）インタオペラビリティデバイスのチームを結成、分配、維持するためのデバイスリクルートメント手段とを備えることを特徴とする。
【０５１１】
別の実施例（２）では、本発明は（１）のシステムを提供し、デバイスリクルートメント手段はさらに、必要なリソースまたはケイパビリティを有するデバイスを探す検査手順オペラティブを、少なくとも１つの通信リンクを介して開始ソースデバイスと異なる少なくとも１つの到達可能デバイスに送る手段で、検査手順は、開始ソースデバイスと、検査手順を到達させようとするデバイスの両方に共通する実行可能形式でコード化された検査手順命令を含むものと、到達可能デバイスのそれぞれから通信リンクを介して直接または間接的に開始デバイスでリターン応答を受ける手段と、開始デバイス上で実行する手順により、応答した全ての到達可能デバイスからの受信リターンを分析し、ソフトウェアアプリケーションの意図を最もよく実行する開始ソースデバイスと応答到達可能デバイス手段のケイパビリティおよびリソースの組み合わせを特定する利用プランを決定することと、開始デバイスで時刻するアプリケーションプログラムによって、特定された利用プランにしたがって必要なリソースまたはケイパビリティを有するとされた到達可能デバイスのそれぞれの少なくとも１つに、実行可能コード、データ、コンテンツおよび／またはＤａｒｔの少なくとも１つを分配する手段とを備えることを特徴とする。
【０５１２】
別の実施例（３）では、本発明は（１）のシステムを提供し、次の任意のコンポーネントの１以上があらゆる組み合わせでシステムに含まれるか、または使用され、（１）インタオペラビリティフレームワーク、（２）リニアタスキング手段と、（３）バーチカルレイヤリング手段と、（４）アプリケーション駆動型パワーマネージメント手段と、（５）アプリケーション駆動型エラー復元手段と、（６）インタオペラビリティランタイムと、（７）インタオペラビリティアプリケーション駆動ランタイムと、（８）クリエイショニズム手段と、（９）バーチャルポインタと、（１０）インタオペラビリティセキュリティモデル手段と、（１１）ソーシャル同期手段と、（１２）ソーシャルセキュリティ手段と、（１３）インタオペラビリティデバイスイネーブリング手段とを含む。
【０５１３】
別の実施例（４）では、本発明は（１）のシステムを提供し、次の１以上の組み合わせが真であり、（１）システムはＤａｒｔＰｌａｔｆｏｒｍを含み、（２）インタオペラビリティソフトウェアパッケージは、インタオペラビリティフォーマットに準拠するか、ＤａｒｔＦｏｒｍａｔに準拠するＤａｒｔであり、（３）独立して実行可能なイメージはレンディションであり、（４）インタオペラビリティソースは、ＤａｒｔＳｏｕｒｃｅであり、（５）インタオペラビリティツールは、ＤａｒｔＴｏｏｌｓであり、（６）インタオペラビリティフォーマットは、ＤａｒｔＦｏｒｍａｔであり、（７）インタオペラビリティ命令セットは、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔであり、（８）リクルートメント方法は、Ｄａｒｔリクルートメント方法である。
ＸＸＩＩ．バーチャルポインタ
【０５１４】
従来のプログラムは、１つの線形データアドレススペースのみ直接アドレス指定できる従来プロセッサを対象にコンパイルおよびリンクされることが多い。プロセッサは、バーチャルメモリのシステムをインプリメントすることにより、バーチャルメモリをインプリメントして、プログラムとオペレーティングシステムが物理的メモリより大きいメインメモリを直接アドレス指定できるようにすることが多く、限られた数の実際のメモリブロックまたはページが、より大きいが速度の遅いストレージデバイスと自動的にスワップされる。これにより、プログラマは直接アドレス指定可能の高速メインメモリと低速だが大型のストレージデバイスとの間のスワップを直接管理するために必要だったロジックを気にかける必要がなくなる。
【０５１５】
それでもプログラマは、別個データ構造がプログラム実行中、ダイナミックにサイズを変更する時、互いとアドレス指定対立を起こさないようメモリ管理ロジックをしばしば気にかける必要がある。単一アドレススペースの共有利用のダイナミックな分割と管理はしばしば複雑で、バーチャルメモリ技術を利用して大型の効果的なデータアドレススペースを形成してもバグが生じやすい。
【０５１６】
従来のバーチャルメモリ技術のもう１つの限界は、動作中のプログラムの特性に関わらず、プロセッサは固定サイズの実際のメモリページをサポートするだけか、サイズが全ての同時ロードプログラムまたはプログラムのセクションのニーズに最適に一致する場合、複数のプログラムに用いるため実際のメモリ変更を１サイズとするような方法でしかサポートしない。
【０５１７】
本発明の１つのインプリメンテーションでは、ハードウェアプロセッサまたはソフトウェア命令セット実行エンジンのいずれかでより複雑なアドレス指定ロジックを用いて、各プログラムの利用する複数の独立したアドレススペースを提供し、実際のメモリページ数とそのサイズが、利用可能な実際のメインメモリの物理的サイズ、速度およびメインメモリのパフォーマンス特性と、固有プログラムの固有データセットへの期待されるアクセスパターンに応じて、有利に変化できるようにする。本発明のプログラミング言語拡張は、ソースコード、コンパイラおよびリンカでサポートされ、本発明のＶｉｒｔｕａｌＰｏｉｎｔｅｒｓの利用を提供する。ＶｉｒｔｕａｌＰｏｉｎｔｅｒｓの利用には次の利点がある。
１．複数の大型独立アドレススペース。ダイナミックにリサイズされたデータ構造はそれぞれ、自身のＶｉｒｔｕａｌＰｏｉｎｔｅｒｓアドレススペースに保持され、他のアドレススペースのデータ構造と対立が起きないようにできる。
２．ここの独立したアドレススペースについて実際のメモリページ数のアプリケーション固有制御。実際のメモリページの最適数を、必要な実際メモリ数を制限したり、および／または実際のメモリとストレージとの間でデータを交換するのに必要な低速ブロック読み書き数を制限したりする予測されるアクセスパターンにしたがって設定できる。たとえば、ゼロから始まって線形順で継続する大量のデータに常にアクセスする場合、１以上のメモリページが余分になる。ページサイズを実際のストレージの最適アクセスブロックサイズに設定し、よいパフォーマンス速度を確保するか、ストレージブロックへのアクセス数を制限して、デバイスを磨耗させないようにする。
３．ストレージデバイスのパフォーマンス特性に一致させるか、ストレージデバイスの寿命を改善するための実際のメモリページサイズのデバイス固有制御。デバイスは、誤作動開始前に、保証されたブロックアクセスについて既知の限定数を持つストレージ用フラッシュメモリを用いることが多い。ハードディスクは、固有サイズのブロックにデータを保存したりキャッシュしたりすることが多い。
４．バーチャルポインタは自動的かつ論理的に、アクセスに用いるデータ構造またはリスト等予想される最大のものより大きいアドレススペースの値を含むため、データ構造やリストに必要なメモリ量を予測したり管理したりする必要がない。
５．ページサイズまたはページ数から独立した形式でのデータの自動セービング。ＤａｒｔＳｏｕｒｃｅを用いて、各ＶｉｒｔｕａｌＰｏｉｎｔｅｒ変数のパラメータを設定することができ、これはＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ  ＳＡＶＥ＿ＩＮＳＴＲＵＣＴＯＩＮを用いたＤａｒｔのセービングがアドレススペースの全データ状態を自動的にセーブするか否かを示す。ある好適なインプリメンテーションでは、セーブされる各ＶｉｒｔｕａｌＰｏｉｎｔｅｒの値は、動作中のＤａｒｔが現在利用しているページサイズやページ数に関わらず、値の範囲のスパースリストとＤａｒｔＰａｒｔとして保持される。これにより、ページサイズやページ数を異ならせる必要のない場合、他のデバイスでセーブされたＤａｒｔを動作させることが可能になる。
６．大型で低速の可能性もある少量の貴重なメインメモリのデータストアから効率的にデータをキャッシュすることで、アプリケーションは、物理的サイズよりはるかに大きいＲＡＭメモリを持つかのように動作する。
７．インデックス化されたデータベースオペレーションの単純かつ有効なベースインフラで、データおよびインデックスは異なるバーチャルアドレススペースに保持される。
【０５１８】
好適なインプリメンテーションでは、ＶｉｒｔｕａｌＰｏｉｎｔｅｒはＤａｒｔＳｏｕｒｃｅ、ＤａｒｔＴｏｏｌｓおよびＤａｒｔＥｎｇｉｎｅにサポートされて一覧された利点を提供する。
【０５１９】
ＤａｒｔＳｏｕｒｃｅでは、各バーチャルポインタを、ＣまたはＣ＋＋言語の＃ｐｒａｇｍａ  ＶｉｒｔｕａｌＰｏｉｎｔｅｒ（パラメータ）拡張を用いて指定し、パラメータは次を含む：
１．プログラムが実行を開始した時、バーチャルアドレススペースの開始アドレスを保持するポインタ変数の名称。
２．実際の利用用メモリページの数。
３．アドレススペースの値がアプリケーションと共に自動的にセーブされるか否かを示すフラッグ。
４．実際のメモリサイズの示唆される大きさ。
【０５２０】
ＤａｒｔＴｏｏｌｓはＤａｒｔＳｏｕｒｃｅ  ＃ｐｒａｇｍａステートメントを処理して、Ｄａｒｔを生成し、これが、別個アドレススペースの開始オフセットとして有効に作用するポインタアドレス値をロードする。この開始オフセットは、実際は固有バーチャルポインタを特定するＤａｒｔＥｎｇｉｎｅによって解釈されるマルチフィールドアドレスの一部である。
【０５２１】
Ｄａｒｔバーチャルポインタの例を図３２に示す。好適なインプリメンテーションでは、Ｄａｒｔのアドレススペースは、最大直接アドレス指定可能スペースが２＾３２  ８ビットバイトである大半の従来プロセッサでより一般的な８ビットバイトではなく、３２ビットワードの単位である。ＤａｒｔＰｌａｔｆｏｒｍは利用するアドレススペースのタイプを示すフィールドとして３２ビットアドレスの２個の最上位ビットを用いる。ＤａｒｔＥｎｇｉｎｅの実行するＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔのアドレス指定単位が３２ビットワードであるため、メモリアドレス指定可能なサイズにはこれより小さいものはなく、２＾３０  ３２ビットワードである。図３２の例は、これがＶｉｒｔｕａｌＰｏｉｎｔｅｒアドレススペースであることを示すアドレススペースタイプフィールドであるアドレスを示す。次の５ビットフィールドは、ＶｉｒｔｕａｌＰｏｉｎｔｅｒ１を使用中で、このインプリメンテーションでは、２＾５＝３２までの異なるＶｉｒｔｕａｌＰｏｉｎｔｒｅアドレススペースが可能なことを意味する。残りの２５ビットはＶｉｒｔｕａｌＰｏｉｎｔｅｒ１のアドレススペースのデータアイテムのオフセットまたはアドレスである。
【０５２２】
図３２の例は、ＶｉｒｔｕａｌＰｏｉｎｔｅｒ１のアクセスが固有アドレス、０×５００００１について固有デバイス上のＤａｒｔＥｎｇｉｎｅによって管理されているところの固有インスタンスを示す。ブロック（ページ）サイズが６４Ｋ＝２＾１６ワードであるため、２５ビットオフセットの上位９ビットは、どの６４Ｋブロックがアクセス中のデータ値を含むかを示す。図示の例では、２つの実際のメモリページのいずれも、現在そのブロックを保持していない。また、ＶｉｒｔｕａｌＰｏｉｎｔｅｒ１のフラッシュストレージファイルのいずれも必要なデータブロックを保持していない。これらファイルは過去のアクセスの結果で、ブロック１００および１０１の実際のメモリページを他のページによって過去に置き換える必要があった。ＤａｒｔＥｎｇｉｎｅは、実際のメモリページを置き換える前に２個のフラッシュメモリファイルのこれらブロックのデータ値を自動的にセーブした。このアクセスの実際の現行データ値はまだ動作中ＤａｒｔファイルのＶｉｒｔｕａｌＰｏｉｎｔｅｒ１パーツにある。このパーツは。ＶｉｒｔｕａｌＰｏｉｎｔｅｒ１のアドレススペースで当時現行のデータ値を用いて動作中のＤａｒｔが最後にセーブされた時、作られた。この例におけるアクセスは、パーツの第２レンジからブロック１０１のデータ値を２つの実際のメモリページの一方へ読み取る。置き換える実際のメモリページが、変更済あるいは「ダーティ」とマークされたデータを有する場合、新しいフラッシュストレージファイルが書き出され、その値が置き換えられる前に実際のメモリページに現行の値がセーブされる。このアクセスは、実際のメモリで０×５０００１の値のポインタが返され、アクセスしているＤａｒｔ命令によって処理される。
【０５２３】
バーチャルポインタの追加態様および実施例と本発明の他の態様に関係するその利用法について述べる。ある実施例（１）では、本発明は、物理的メモリおよび／または物理的ストレージデバイスを効率的に利用するソフトウェアアプリケーションプログラム内でアクセス可能な複数の大型独立データアクセスアドレススペースを提供する方法を提供し、この方法は、（１）１以上の独立したアドレススペースの特性を指定することと、（２）バーチャルポインタ昨日をサポートする特定のソフトウェアエンジンおよび／またはハードウェアプロセッサ上で動作するのに適した実行可能イメージにコンピュータプログラムコードソースを処理することとを含み、（３）特定のソフトウェアエンジンまたはハードウェアプロセッサ上で実行可能イメージを動作させることで、これは高速アクセス限定サイズのメインメモリと、低速アクセスだが大型サイズの二次ストレージを効率的な方法で用いることにより、アドレススペースの参照するデータへのアクセスを解決する命令セットを実行する。
【０５２４】
別の実施例（２）では、本発明は（１）の方法を提供し、１以上の独立したアドレススペースの特性の指定は、そのためのシンタックスやセマンティックスに準拠するステートメントをサポートするコンピュータプログラミング言語を用いて実行する。
【０５２５】
別の実施例（３）では、本発明は（１）の方法を提供し、処理は、ソースステートメントを、特定のソフトウェアエンジンおよび／またはハードウェアプロセッサ上で動作するのに適した実行可能イメージに処理するソフトウェアツールを動作させることを含むことを特徴とする。
【０５２６】
別の実施例（４）では、本発明は（１）の方法を提供し、効率的利用法と効率的な方法は、少なくとも部分的に次によって実行され、（１）独立した各アドレススペースについて、全てが１つの特定のサイズの多数の実際のメモリページを作成および維持することと、（２）独立したアドレススペースで論理的にデータにアクセスするとき、次の手順を用いて、アクセスを解決し、アクセスする命令またはプログラムへの値を含むメインメモリへ値またはポインタを返すことで、（ａ）データがメインメモリページの１つにあるか否かを決定することと、（ｂ）データがメインメモリページの１つにない場合、次の手順を実行することで、（ｉ）データが二次ストレージにあるか否か決定することと、（ｉｉ）二次ストレージにない場合、次の手順の１以上を実行することで、（１）デフォルト値を返すことと、（２）デフォルト値を含むメインメモリデータ要素へのポインタへポインタ付きで返すことと、（３）データに周知の値がないことの未知のデータコードその他インジケータへのアクセス付きで返すことと、（ｃ）データが二次ストレージにある場合、次の手順を実行することで、（ｉ）実際のメモリページを選択し、必要なデータ値を含むデータのブロックを保持することになるアドレスを開始することと、（ｉｉ）選択した実際のメモリページがダーティとマークされている場合、選択した実際のメモリページの値を二次ストレージに書き出すか、書き差出せることと、（ｉｉｉ）連続するアドレス指定可能データの範囲を読み取るか、実際のメモリページと同じサイズおよび新しい開始アドレスを持つ実際のメモリページにロードすることと、（ｉｖ）実際のメモリページをダーティでないとマークすることと、（ｖ）選択したメインメモリページにあるデータの値または、選択したメインメモリページにあるデータへのポインタを返すことと、（ｄ）データがメインメモリページの１つにある場合、次の手順を実行することで、（ｉ）値の消費者がデータの値を変える可能性があることを示すものであることがわかっている場合、メインメモリページをダーティとマークすることと、（ｉｉ）データメインメモリページの値またはデータに含まれることがわかったメインメモリページのデータへのポインタを返すこととを含むことを特徴とする。
【０５２７】
別の実施例（５）では、本発明は（４）の方法を提供し、データが実際のメモリページになく、データが二次ストレージにない場合、データが二次ストレージにあったかのように進めるが、選択した実際のメモリページを二次ストレージからロードすることは除き、選択した実際のメモリページをデフォルトで埋める。
ＸＸＩＩＩ．アプリケーション例とアプリケーションシナリオ
Ａ．ニュートリノディテクタアプリケーション例
【０５２８】
図２１を参照すると、本発明の実施例の図示が、ＤａｒｔＰｌａｔｆｏｒｍが、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔのＯＥＭ＿ＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮの利用を通じて、携帯電話が最初はニュートリノディテクタ３５００の存在や特性を知らなくとも、新しいタイプのＤａｒｔＤｅｖｉｃｅ，家庭用ニュートリノディテクタ３５００のネイティブな機能性を携帯電話ＤａｒｔＤｅｖｉｃｅ３６００によって発見可能および利用可能とすることができる様子を示す。
【０５２９】
家庭用ニュートリノディテクタ３５００は、現在、理論的にのみ存在するデバイスだが、存在する場合、このようなデバイスと相互運用するため既存標準が必要なくなることが理解される。それでも、ＤａｒｔＰｌａｔｆｏｒｍは、ニュートリノディテクタ（ＮＤ）が他のＤａｒｔＤｅｖｉｃｅ，この場合は携帯電話３６００と、このようなデバイスの機能性の既存標準や知識を携帯電話ＤａｒｔＤｅｖｉｃｅ３６００のメーカーが知らなくとも、相互運用可能にするための方法を提供する。
【０５３０】
ＮＤのメーカーはＭｉｒａｂｅｌｌａ  Ｅｌｅｃｔｒｏｎｉｃｓで、シンボルに割り当てられた一意のｉｄ、ＭＩＲＡＢＥＬＬＡ＿ＥＬＥＣＴＲＯＮＩＣＳ＿ＩＤを割り当てられ、他のメーカーが作成および利用するものと異なる、Ｍｉｒａｂｅｌｌａ  Ｅｌｅｃｔｒｏｎｉｃｓの作成および利用する独自のＯＥＭ機能と差別化している。自社のデバイスとＤａｒｔＤｅｖｉｃｅｓとの相互運用可能を臨むＭｉｒａｂｅｌｌａ社は、ＤａｒｔＥｎｇｉｎｅをＮＤで動作するＤａｒｔＰｌａｙｅｒの一部としてポーティングした。５秒間にディテクタを通過するニュートリノの数をサンプリングするこのデバイス独自の機能を露出するため、ネイティブな埋め込み機能、収集を行い、ディテクタを通過したニュートリノの数を返すＣｏｌｌｅｃｔＳａｍｐｌｅｓを、ＨＡＬのＯＥＭ（＜ｏｅｍｉｄ＞，  ＜ｓｕｂｆｕｎｃｔｉｏｎ＞）方法から呼び出す。ＭｉｒａｂｅｌｌａＥｌｅｃｔｒｏｎｉｃｓは、ＤａｒｔＳｏｕｒｃｅとＤａｒｔＴｏｏｌｓを用いて、コントロールパネルのユーザインターフェースを表示するレンディション、Ｒ１と、サンプリング発生のシグナリングのため留保したタイプのＤａｒｔ固有イベントを処理するレンディション、Ｒ０を生成する。
【０５３１】
ユーザインターフェースケイパビリティのある各ＤａｒｔＤｅｖｉｃｅは、ＧｅｔＣｏｎｔｒｏｌＰａｎｅｌｓ  Ｄａｒｔを常駐させて出荷されるのが通常で、これは、他のＤａｒｔＤｅｖｉｃｅとのコントロールパネルＤａｒｔｓの共有を望む到達可能ＤａｒｔＤｅｖｉｃｅに常駐するＤａｒｔｓとしてインプリメントされた全てのコントロールパネルを見つけるために用いる。ＧｅｔＣｏｎｔｒｏｌＰａｎｅｌｓＤａｒｔを携帯電話３６００上で起動すると、これはＧｅｔＣｏｎｔｒｏｌＰａｎｅｌＬｉｓｔ  ＤａｒｔＰｒｏｃｅｄｕｒｅを送り、その通信プロトコルのいずれかで到達可能な全てのデバイスで動作させる。この場合、携帯電話は、両デバイスに共通するＢｌｕｅｔｏｏｔｈプロトコルを用いて通信セッションを探して確立し、ＤａｒｔＰｒｏｃｅｄｕｒｅを動作させるニュートリノディテクタにＲｕｎＰｒｏｃｅｄｕｒｅタイプのイベントの一部としてＤａｒｔＰｒｏｃｅｄｕｒｅを送る。ＤａｒｔＰｒｏｃｅｄｕｒｅは、ＮＤ上で実行されると、各ＤａｒｔＤｅｖｉｃｅのＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔの一部である内蔵命令を利用してＣｏｎｔｒｏｌＰａｎｅｌ  Ｄａｒｔの名称および記述と一意のＩＤのリストを集める。ＮＤ上に常駐する利用可能なコントロールパネルＤａｒｔの名称および記述は携帯電話に送り返され、ＧｅｔＣｏｎｔｒｏｌＰａｎｅｌｓＤａｒｔによって表示され、ユーザが選択する。携帯電話上のリストからコントロールパネルを選択した後、その一意のＩＤで識別されるコントロールパネルがＮＤ上で実行を始め、確立された通信セッションで携帯電話をリクルートするよう要求するイベントを送り、これがリクルートするＮＤのＣｏｎｔｒｏｌＰａｎｅｌ  Ｄａｒｔの動作Ｒ０レンディションによって送られた動作レンディションＲ１と共に電話上のＧｅｔＣｏｎｔｒｏｌＰｎｅｌＤａｒｔに自動的に置き換わる。
【０５３２】
すると、レンディションＲ１は携帯電話の画面上の大きな緑のサンプルボタンを表示する。ユーザがボタンを選択すると、Ｒ１はサンプル取得を要求する同期についてマークされたイベントを生成する。イベントはＤａｒｔＲｕｎｔｉｍｅによってチーム化されたＮＤのイベント待ち行列に自動的に送られ、ＯＥＭ＿ＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＯＩＮを用いてイベントを処理し、Ｍｉｒａｂｅｌｌａ  Ｅｌｅｃｔｒｏｎｉｃｓにより割当てられたパラメータでＤａｒｔＥｎｇｉｎｅにｈａｌＯＥＭ（）方法を呼び出させてサンプリングを実行し、ＣｏｌｌｅｃｔＳａｍｐｌｅｓ（）ネイティブデバイス機能を生じ、ｈａｌＯＥＭ（）のコール元にサンプル数を返し、これがエンジンによって実行中のＲ０レンディションに返される。Ｒ０は、同期についてマークされているＤｉｓｐｌａｙＮｕｍｂｅｒＯｆＳａｍｐｌｅｓタイプイベントを待ち行列に入れるよう求め、ＤｉｓｐｌａｙＮｕｍｂｅｒＯｆＳａｍｐｌｅｓタイプイベントがチーム化携帯電話の待ち行列に入れられる。携帯電話で動作中のＲ１レンディションは、イベントを処理し、ＤｉｓｐｌａｙＮｕｍｂｅｒＯｆＳａｍｐｌｅｓタイプイベントに運ばれる検出済みニュートリノの数を画面に表示する。
【０５３３】
図２１の例は、ＤａｒｔＰｌａｔｇｏｒｍを用いて、独自デバイスの存在や特性、ケイパビリティを事前に知らなくとも、ＤａｒｔＤｅｖｉｃｅｓに非常に独自なデバイスでもそのケイパビリティとコントロールを有利に露出および拡張できる。
【０５３４】
上記例および説明の重要なポイントは次を含む。
【０５３５】
第１に、唯一の目的を標準委員会によって想定できないデバイスがＤａｒｔＤｅｖｉｃｅ４００になることができ、他のデバイスをＤａｒｔＤｅｖｉｃｅ４００にするのと同じ開発努力を必要とする。
【０５３６】
第２に、この新しいデバイスは、この種のデバイスが存在する前から存在していた独自のハードウェアケイパビリティを他のデバイスに容易に露出することができる。予め存在するＤａｒｔＤｅｖｉｃｅｓ４００は、新しいデバイスと相互運用し、その行動を制御することができ、これは新規で独自であり、あらゆるデバイスにとって未知である。
【０５３７】
第３に、ニュートリノディテクタ３５００をＤａｒｔＤｅｖｉｃｅ４００にするために必要な開発努力は、あらゆるデバイスをＤａｒａｔＤｅｖｉｃｅ４００にするのと同じで、これらで場が技術露出前に存在していたとしても、他のデバイスへの追加作業はない。すなわち、従来のインタオペラビリティ方法を用いるとＮ乗に増加する開発努力が、ＤａｒｔＰｌａｔｆｏｒｍに具現化する方法を用いてインプリメントすると、Ｎ順の努力で済む。ＤａｒｔＡｐｐｌｉｃａｔｉｏｎｓのレンディションは、他のレンディションと同じ当初Ｄａｒｔｓから通信しているため、非互換性に遭遇しやすいインタオペラビリティコンポーネントを別個にインプリメントして分散させる必要のある従来のインタオペラビリティに比べて、高度な信頼性を得られる。
Ｂ．スライドショーアプリケーション例−利用を通じた開発段階
【０５３８】
ここで、例示システム、方法、コンピュータプログラムおよびそのコンポーネントを、スライドショーＤａｒｔアプリケーションを主要なアプリケーション例として利用法を通じて開発の例をコンテキストからより詳しく説明する。このスライドショー例は説明目的としてのみのもので、同一技術は、一度に１デバイスか、逐次か、同時または並行して多くのデバイスかその他かを問わず、事実上あらゆるデバイスまたはデバイスのセットで動作する必要があるハードウェアとインタラクトまたはこれを利用または制御するソフトウェアアプリケーションを含む事実上あらゆるソフトウェアアプリケーションに有利に採用可能である。
【０５３９】
この例では、ＤａｒｔＳｏｕｒｃｅ（図３、１００）ファイル（Ｃ＋＋）とクラス定義およびソースコード（図３、１０１）のＤａｒｔＦｒａｍｅｗｏｒｋ（図３、１０２）は、インタオペラビリティアプリケーションの構築に必要なアルゴリズムおよびコードを表現するオプションのべースとして用いるよう設計された。
【０５４０】
図３を参照すると、例示スライドショーＤａｒｔアプリケーションは、図３のＤａｒｔＳｏｕｒｃｅファイル、１００として始まる。アプリケーションコード１０１は一般に標準Ｃ＋＋言語に準拠する。ＳｌｉｄｅＳｈｏｗ  ＤａｒｔＳｏｕｒｃｅ１００はまた、ＤａｒｔＦｒａｍｅｗｏｒｋ１０２を表現する標準Ｃ＋＋ソースファイルを含む。ＤａｒｔＦｒａｍｅｗｏｒｋ１０２は、ＤａｒｔＦｏｒｍａｔ３００にレンダリングされるインタオペラビリティアプリケーションを構築するのに必要なアルゴリズムおよびコードを表現するオプションのベースとして用いるよう、ＤａｒｔＲｕｎｔｉｍｅ８０００（図１５参照）に準拠して設計されるクラス定義およびコードのセットである。
【０５４１】
ＤａｒｔＳｏｕｒｃｅ１００からＤａｒｔ  Ｅｎｇｉｎｅ機能へのコールは、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔの一部であるＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮ（図２０、６７０）を通じて行う。Ｃ＋＋ソースコードからエンジン機能へのコールは、コンパイラ２０１生成ＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮ（図２０参照）を通じて行われ、これはＤａｒｔＤｅｖｉｃｅ４００（図４参照）上で動作するデバイス固有ＤａｒｔＰｌａｙｅｒ５００の一部であるデバイス独立ＤａｒｔＥｎｇｉｎｅ６００によって生成されるＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔの一部である。
【０５４２】
Ｃ＋＋言語に有利に拡張を行い、多くの種類のリソース１０３をアプリケーションコード１０１とＤａｒｔＦｒａｍｅｗｏｒｋ１０２内から参照できるようにする。これは、特別に名づけられた内蔵機能、特別に名づけられたデータ構造、Ｄａｒｔ  Ｃｏｍｐｉｌｅｒ２０１に認識されるキーボードによる＃ｐｒａｇｍａ拡張によって行う。
【０５４３】
リソースは、ファイルシステム（図２２、６１２、図２７、５１００、図２８、５０００、および図２６参照）またはあらゆる形式のネットワークアクセス、無線アクセスまたはあらゆる形式の通信を介して、あらゆるタイプのデータまたはコード、あるいはファイルのいずれかの場所にあるか、またはＤａｒｔＴｏｏｌｓ２００によってダイナミックに生成され到達可能なデータまたはコードへの参照を含むことができる。スライドショーアプリケーション例では、リソース１０３は、例えば、ＪＰＥＧフォーマットの背景画像ファイル、ＰＣＭフォーマットのサウンドエフェクトファイルおよび／またはスライドまたは画像、ビデオ、テキスト、記号あるいはデフォルトのデモンストレーションスライドとして含まれる完全なＤａｒｔファイル（７００）を含むことができる。Ｃ＋＋言語のＰｒａｇｍａ拡張を用いて、ＭａｉｎＣｏｄｅ２１０３およびＭａｉｎＤａｔａ２１０２（図１３参照）パーツ（図３、３０３）に含まれるのではなく、機能を自動的にＤａｒｔＰｒｏｃｅｄｕｒｅｓ４０００（図１４参照）またはパーツ３０３（図１３参照）にする機能をＤａｒｔＴｏｏｌｓ２００に識別することもできる。機能もしくはＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔの一部である内臓命令に対するパラメータとして使用される時、Ｃ＋＋言語に対するｐａｒｔｎｕｍｂｅｒ（）内蔵機能拡張はソースコードで使用され、コンパイラ２０１にパーツを参照するのに使用されるパーツＩＤ３２ビット値を生成させる。
【０５４４】
ＤａｒｔＦｒａｍｅｗｏｒｋ１０２（図３および図１１参照）は、クラス指定およびインプリメンテーションの階層を有利に含む。重要な基本的クラスの１つがＧｉｚｍｏ１１５クラスである。Ｇｉｚｍｏｓ１１５を用いて、処理の単一機能的ユニットをカプセル化することができる。Ｇｉｚｍｏ１１５派生クラスには、Ｓｅｔｕｐ（）およびＰｒｏｃｅｓｓ（）方法、親Ｇｉｚｍｏ参照、および子Ｇｉｚｍｏｓのリストが含まれる。これらの参照はオプションでヌル参照でよい。
【０５４５】
レンディション１１４クラスは、Ｇｉｚｍｏクラスからの継承で、アプリケーションで他のレンディション１１４から独立してロードおよび動作できるアプリケーションの一部の基点として作用するよう設計されている。
【０５４６】
ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎ１１３クラスは、レンディション１１４クラスからの継承である。これは、ＭａｓｔｅｒＤａｒｔ２３０（図１２参照）の唯一のアクティブなレンディションである。ＭａｓｔｅｒＤａｒｔ２３０はバイナリＤａｒｔＦｏｒｍａｔ３００ファイルまたは単一のＭａｓｔｅｒＲｅｎｄｉｔｉｏｎインスタンスを優先的に含むＤａｒｔＴｏｏｌｓ２００（図３および図１２参照）からの画像出力である。ＭａｓｔｅｒＤａｒｔ２３０は、ソースコードで参照される全てのコード、データ、コンテンツ、手順およびリソースを有利に含み、ＭａｓｔｅｒＰｌａｙｅｒ２０３で再生される時、自動的にロードされる。ＭａｓｔｅｒＤａｒｔ２３０ローディング後、ＭａｓｔｅｒＰｌａｙｅｒ２０３はＣ＋＋コンストラクタ方法を実行するが、これはｍａｉｎ（）エントリポイントの開始前に実行しなければならない。マスタレンディションの１１３Ｍａｉｎ（）方法はＭａｓｔｅｒＤａｒｔ２３０の論理基点となる。
【０５４７】
図１２は、ＤａｒｔＴｏｏｌｓ２００にＤａｒｔＳｏｕｒｃｅ１００を入力する実施例を示す。コンパイラ２０１は、ＤａｒｔＳｏｕｒｃｅを一度にＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ１ファイルへ、オブジェクト２２０へ、これらオブジェクトの集合をライブラリへ変換する。あるいは、これらライブラリは、ライブラリツールで生成することができる。オブジェクトおよび／またはライブリ２２０はまた、他のＤａｒｔＭａｓｔｅｒｓおよびＤａｒｔアプリケーションのＤａｒｔＳｏｕｒｃｅ１００のリソース１０３としても作用する。コンパイラ２０１のオペレーション、任意のライブラリアンツール、リンカ２０２は、全体として現在使われている従来のＣ＋＋コンパイラ、ライブラリアンおよびリンカに似ているが、一部重要な差異がある。これら差異は次のようなものを含む。
【０５４８】
第１に、対象命令セットは、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔからである。第２に、実行可能出力は、実際のエンド対象デバイスではなく、ＭａｓｔｅｒＰｌａｙｅｒ２０３上での実行を目的とするＭａｓｔｅｒＤａｒｔ２３０で、ＭａｓｔｅｒＤａｒｔおよびＭａｓｔｅｒＰｌａｙｅｒは本発明独自のコンポーネントを表す。第３に、通常は使用後に捨てられる従来のコンパイラ、ライブラリアン、およびリンカの動作中に生成されるクラス定義およびリンケージ構造の多くが、ＭａｓｔｅｒＰｌａｙｅｒによる利用のためにＭａｓｔｅｒＤａｒｔに維持される。保持されるクラス定義およびリンケージ構造は、従来のコンパイラ、ライブラリアンおよびリンカに過渡的に存在するものとも異なる。第４に、ＤａｒｔＴｏｏｌｓ２００は、次のためのソース言語への拡張を処理する、（ｉ）実行中に必要となるランタイムリソース要件の指定または自動的収集、（ｉｉ）パーツ３０３（図３、図１３）としてのリソース１０３のＭａｓｔｅｒＤＡｒｔへの含有、およびアプリケーション手順が用いるためＤａｒｔＴｏｏｌｓ２００に割り当てられたリソースの識別子として作用するパーツ番号を与えるｐａｒｔｎｕｍｂｅｒ（）ソースコード機能。さらに発明的なのは、結果として生じるＤａｒｔＴｏｏｌｓによるＭａｓｔｅｒＤａｒｔｓおよびＤａｒｔｓ出力は、これらレンディションを必要に応じて構築するためＤａｒｔまたはＭａｓｔｅｒＤａｒｔイメージで共有パーツを集めるためのあらゆる数のレンディションおよび情報を含むことができる。さらに発明的なのは、ＤａｒｔＴｏｏｌｓによるＤａｒｔｓおよびＭａｓｔｅｒＤａｒｔ出力は、デバイスの特別なチームをインテリジェントに設立して、ＤａｒｔＲｕｎｔｉｍｅにしたがってアプリケーションの意図を実行するためリクルートメントを実行するのに必要な手順、データ、コードおよびコンテンツを含む。
【０５４９】
図１２のリンカ２０２は、オブジェクト／ライブラリ２２０を、ＤａｒｔＦｏｒｍａｔ３００（図３）に準拠する単一バイナリイメージに組み合わせ、パッケージ化している。このイメージは、ＤａｒｔＭａｓｔｒｅ２３０である。ＤａｒｔＭａｓｔｅｒ２３０は、ＭａｓｔｅｒＰｌａｙｅｒ２０３上で動作することを意図しており、ＤａｒｔＥｎｇｉｎｅ５００（図２２参照）を含むこのＤａｒｔＥｎｇｉｎｅ５００は、記号テーブルパーツ２１００（図１３および図１４参照）を利用するＤａｒｔＥｎｇｉｎｅシステム機能呼び出しのＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎ（図２５および図２０参照）サポートと、コンパイラ２０１およびリンカ２０２の生成する他のメタデータパーツを含む。これら機能は、例えばリソース１０３の収集、データの初期化、パーツ２１００とパーツ２２００のＤａｒｔ７００またはＤａｒｔｓ７００のセットへのアセンブラージュを支援するため、ＭａｓｔｅｒＤａｒｔ中のコードが利用することができる。これら機能はまた、コードのサイズの縮小、パーツ２１００および生成するＤａｒｔやＤａｒｔｓで必要なデータによるコードの処理効率性の増強も支援する。
【０５５０】
ＭａｓｔｅｒＤａｒｔはＤａｒｔＦｏｒｍａｔ３００（図３参照）に準拠するが、１つのレンディションテーブル２１０４のみをレンディションテーブル２１０１でそのパーツＩＤに参照させるよう制限することがある。パーツＩＤは、Ｄａｒｔ７００内のパーツ図１２、３０３の参照として用いられる整数の値の識別子である。一実施例では、パーツＩＤは３２ビットだが、識別子は、１６ビット、２４ビット、４０ビット、４８ビット、６４ビットその他あらゆる数のビットの異なるビットカウントの識別子を用いることができる。一実施例では、ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎオブジェクトインスタンスのみがＤａｒｔＳｏｕｒｃｅに許可される。ＤａｒｔＴｏｏｌｓ２００はＭａｓｔｅｒＲｅｎｄｉｔｉｏｎ１１３オブジェクトインスタンスの初期化のためのソースコードとそれがレンディションテーブル２１０１レコード内のパラメータの初期化のために参照するデータ構造の情報を利用する。ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎ１１３インスタンスに対応するレンディションテーブル２１０１レコード中の一部パラメータは、ＤａｒｔＴｏｏｌｓ２００によって自動的に満たすことができる。これらレンディションテーブルパラメータは、イベントおよびファイルの数、レンディション１１４オブジェクトインスタンスをまずロードして、ＤａｒｔＰｌａｙｅｒ５００による実行を準備する時、最初に割り当てなければならないヒープメモリの量を含む。Ｄａｒｔ７００がいずれかのＤａｒｔＰｌａｙｅｒ５００で動作できるようにするには、ＤａｒｔＤｅｖｉｃｅ４００上で動作するＤａｒｔＰｌａｙｅｒ５００のＤａｒｔＥｎｇｉｎｅ６００がまずレンディションを選択し、ロードするのが有利である。
【０５５１】
ＤａｒｔＰｌａｙｅｒ５００は、ＤａｒｔＥｎｇｉｎｅ６００周囲のデバイス固有アプリケーション実行可能シェルを提供するが、動作するレンディションパーツＩＤを指定するか、ゼロ（「０」）を指定することができ、一実施例では、これは違法なパーツＩＤであることの表示である。ゼロが指定されると、ＤａｒｔＥｎｇｉｎｅはレンディションテーブル２１０１の最初のレコードのパーツＩＤを持つレンディション１１４をロードすることになる。
【０５５２】
レンディションテーブルを見つけるには、ＤａｒｔＥｎｇｉｎｅ６００は、まずトレイラー３０５（図３参照）をロードしなければならず、これは、一実施例では、ＤＡｒｔ７００ファイルの最後の４個の３２ビットワードでなければならない。トレイラー３０５は、Ｄａｒｔ７００ファイルの冒頭からＰａｒｔＴａｂｌｅ３０４のオフセットを含む。ＰａｒｔＴａｂｌｅＲｅｃｏｒｄ３１４（図１４参照）、ＰａｒｔＴａｂｌｅ３０４の各レコードは、Ｄａｒｔ７００ファイルの冒頭からＳｔａｒｔＯｆｆｓｅｔおよびＥｎｄＯｆｆｓｅｔと共に３２ビットパーツＩＤ等のパーツＩＤを含み、パーツ３０３の連続イメージがＤａｒｔ７００ファイルで見つかる。
【０５５３】
ＤａｒｔＦｏｒｍａｔ３００ファイルには、通常、図１３の１つのレンディションテーブル２１０１のみ許され、これはレンディションテーブル２１０１部分に対応するＰａｒｔＴａｂｌｅＲｅｃｏｒｄ３１４を見つけるためエンジンが利用する永久的に割り当てられたパーツＩＤ値を有する。このＰａｒｔＴａｂｌｅＲｅｃｏｒｄ３１４のオフセットを用いてレンディションテーブル２１０１を探し、レンディションテーブルレコードは、そのレコードでパーツＩＤによって参照されるレンディションが必要とするＭａｉｎＤａｔａ２１０２およびＭａｉｎＣｏｄｅ２１０３パーツ内の線形セグメントに関する情報を含む。レンディションテーブル２１０１レコードはまた、レンディション１１４インスタンスの実行を開始する起点コードイメージアドレスを含む。レンディションテーブル２１０４レコードは、レンディション１１４インスタンスに属する部分のパーツＩＤを保持する１つの３２ビットワードのみであることが望ましい。
【０５５４】
本発明の一実施例では、ＤａｒｔＰｌａｙｅｒ２０３ではいくつかのステップがＤａｒｔ２３０のローディングに関連する。ＭａｓｔｅｒＰｌａｙｅｒでＭａｓｔｅｒＤａｒｔｗｏロードする時、これらはそれぞれＤａｒｔおよびＤａｒｔＰｌａｙｅｒの固有インスタンスであるため、同じステップを用いる。これらステップは次のステップを含み、任意であるが実行すると有利であるステップを含む：
ステップ１．アプリケーション開発デバイス９００（図１２参照）のＤａｒｔＰｌａｙｅｒ２０３が、値ゼロで始めるレンディションパーツＩＤを指定するパラメータと共にＤａｒｔ  Ｅｎｇｉｎｅ６００Ｉｎｉｔ（）方法（図２４、６０００、図２３、４００２）を呼び出す。
ステップ２．ＤａｒｔＥｎｇｉｎｅ６００は、ＤＡｒｔ２３０ファイルの終わりからトレイラーを読み、ＰａｒｔＴａｂｌｅ３０４のオフセットを抽出する。
ステップ３．全てのレンディションテーブルのパーツＩＤの予め割り当てられた固定値のあるレコードが見つかるまで、ＰａｒｔＴａｂｌｅ３０４の各レコードを読む。この固定値パーツＩＤを持つレンディションテーブルを１つのみ、あらゆるＤａｒｔＦｏｒｍａｔイメージに許可される。
ステップ４．ＤａｒｔＥｎｇｉｎｅ６００は、レンディションテーブル２１０１のＳｔａｒｔＯｆｆｓｅｔとＥｎｄＯｆｆｓｅｔを抽出し、第１のレンディションテーブルレコードを読むためにこれ（ＳｔａｒｔＯｆｆｓｅｔとＥｎｄＯｆｆｓｅｔ）を用いる。
ステップ５．第１レンディションテーブルレコードを読み出し、メモリを割り当てるファイルやイベントの数、ヒープおよびスタックに割り当てるスペースの量などの初期ランタイムパラメータを抽出する。レンディションテーブル２１０４パーツＩＤも抽出する。
ステップ６．レンディションテーブルパーツＩＤを用いて、このパーツＩＤのＰａｒｔＴａｂｌｅ３０４からレンディションテーブル２１０４のＳｔａｒｔＯｆｆｓｅｔとＥｎｄＯｆｆｓｅｔを見つける。
ステップ７．レンディションテーブル２１０４の各レコードを読み出す。一実施例では各レコードはレンディションに属するパーツのパーツＩＤを持つ３２ビットワード１つのみである。各ＰａｒｔＴａｂｌｅＲｅｃｏｒｄ３１４は、ロード時間に発生するものを支配するフラッグおよびパラメータを含む。例えば、パーツをコンテンツタイプ、パラメータ０、パラメータ１および／またはパラメータ２値、あるいは何か他のパラメータまたは条件にしたがって何らかの方法で処理しなければならない場合、フラッグがある。ＭａｉＤａｔａおよびＭａｉｎＣｏｄｅパーツは、レンディションが実行を開始する前にメモリに必要なコードとデータを入れるため、ロード時に処理しなければならないパーツの例である。
ステップ８．必要なＭａｉｎＣｏｄｅ２１０３ＰａｒｔＴａｂｌｅＲｅｃｏｒｄ３１４が見つかったら、コンテンツタイプがＭａｉｎＣｏｄｅ２１０３コンテンツタイプに割り当てた固定値を保持し、フラッグパラメータワードのＡｕｔｏ−Ｌｏａｄフラッグビットを設定し、パラメータ０とパラメータ１はＭａｉｎＣｏｄｅ２１０３パーツに含まれる最初と最後のＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔコードイメージアドレスを保持する。広く利用可能なＣ＋＋ツールからの実行可能イメージ出力の大半は、常に同じ固定オフセットで始まるコードイメージを生じるが、ＭａｓｔｅｒＤａｒｔ２３０を動作させるか、またはバックアップのためＤａｒｔのレンディションのセットをセーブするか、他のチーム化デバイスに送った結果としての出力であるレンディションには線形連続領域しか必要でないため、Ｄａｒｔｓには通常、あてはまらない場合がある。言い換えると、Ｄａｒｔコードイメージは常に同じ固定オフセットで始まるのではなく、クリエイショニズムまたはＳＡＶＥ＿ＩＮＳＴＲＵＣＴＩＯＮの利用またはセーブＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮを通じたＭａｓｔｅｒＤａｒｔ２３０またはＤａｒｔからの出力であるレンディションに必要な線形連続領域のみ通常は存在する。他のＤａｒｔｓを形成するどのＤａｒｔ７００も一般には、オリジナルコードの線形連続アドレス指定部分か、生成されたＤＡｒｔで実際にレンディションに必要なＤａｒｔＴｏｏｌｓ２００により出力されたデータのみ含む。例えば、ＭａｓｔｅｒＤａｒｔ２３０の静的コンストラクタコードがロードプロセスの一部として動作していたら、ＭａｓｔｅｒＤａｒｔ２３０の動作中、生成されたＤＡｒｔｓのスペースをとるコンストラクタコードの必要はない。これは、生成されたＤａｒｔｓ自身、ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎ２３０を通常は含まないためである。ＭａｓｔｅｒＤａｒｔｓ２３０または他のＤａｒｔｓの実行によって生成されたＤａｒｔファイルのＭａｉｎＤａｔａ２１０２部分のデータにもこれが当てはまる。
ステップ９．コンテキスト構造またはコンテキストオブジェクトインスタンス用のメモリは、ロードするＤａｒｔと関連して、メモリ、アクセス権、ステータスを追跡するために割り当てられる。一意のコンテキスト値を、Ｄａｒｔのコードまたは同じＤａｒｔＥｎｇｉｎｅ６００インスタンスで動作している可能性のある他のＤａｒｔｓによるコールのグローバル参照として用いるために生成される。コンテキストのフラッグは、特定の動作中Ｄａｒｔのデータ、ＤａｒｔＨｅａｐまたはＤａｒｔＳｔａｃｋとして明示的に割り当てられたメモリへのＤａｒｔコードのアクセスを制限する。また、このＤａｒｔまたはそのＤａｒｔＥｎｇｉｎｅ環境の一部でなかったり、コンテキストのフラッグ値で表すようにアクセス権が確立されていない機能、メモリまたはファイルへのアクセスの試みは、一実施例では、ＤａｒｔＥｎｇｉｎｅ  Ｐｒｏｃｅｓｓコール４００３からの負の値のエラーリターンコードとなり、不正なアクセス違反が発生する前にＤａｒｔの実行が終了する。
ステップ１０．ＰａｒｔＴａｂｌｅＲｅｃｏｒｄｓ３１４のパラメータに表現される環境および初期メモリニーズと、ＲｅｎｄｉｔｉｏｎｓＴａｂｌｅレコードを抽出する。エンジン維持ＥｖｅｎｔＩｎｆｏ構造、ＦｉｌｅＩｎｆｏ構造またはＣｏｍｍＳｅｓｓｉｏｎＩｎｆｏ構造のいずれかにメモリを割り当てまたは再割り当てする必要があるか、ロードするＤａｒｔの予期される実行に必要な他のリソースがある場合、割り当て、再割り当て、初期化等を実行し、同じＤａｒｔＥｎｇｉｎｅインスタンスで動作するＤａｒｔＣｏｎｔｅｘｔｓ、ＤａｒｔＰｒｏｃｅｄｕｒｅＣｏｎｔｅｘｔｓおよびＤａｒｔＩｄｌｅＣｏｎｔｅｘｔｓが共有するＤａｒｔＣｏｎｔｅｘｔとＤａｒｔＥｎｇｉｎｅ環境を準備する。
ステップ１１．ＳｕｂＦｉｌｅ６９８（図２６参照）のようなＳｕｂＦｉｌｅを開き、読み取って、データを別のファイルにコピーする必要のない独立したファイルであるかのように、ＤａｒｔＦｏｒｍａｔ３００イメージのパーツを処理または実行するのが望ましい。
ＤａｒｔＰｌａｔｆｏｒｍ５０は、独自のファイルシステムを利用するのが有利である。ファイルシステムは処理され６１２（図２６参照）、Ｄａｒｔコードのファイルを参照したり、データを読み取ったり、パスしたり、書き込んだり、共有したりする時に用いることができるファイル識別子（フィールド）値に添付するファイル抽象を生成する。
複数のＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎ６７０（図２０参照）オペレーションコード値を、リード、ライト、オープン、クローズ、リネーム、ポジションオペレーションに用いることができる。各フィールドと１対１で関連するＦｉｌｅＩｎｆｏ構造は、ストレージ、特性およびアクセス権のタイプおよび形式と、現在のストレージ箇所、ファイル等への現在のポインタの位置を追跡する。
ＤａｒｔＥｎｇｉｎｅ４００上で動作するために必要な小さい機能セットと共にＤａｒｔＥｎｇｉｎｅ６００インプリメンテーションのポータブル部分をマッピングするデバイス固有ｈａｌＢａｓｅオブジェクトを小さく単純なままにするのが有利だが、これは、大半のオペレーションが実際のここに物理的に保存されたファイルと関係がなく、図２６に示すようなＤａｒｔＥｎｇｉｎｅのポータブルコードによってバーチャル化されるためである。
ファイルの処理では、ＤａｒｔＥｎｇｉｎｅ６００を新しいＤａｒｔＤｅｖｉｃｅ４００にポーティングするには、ＨＡＬのリード、ライト、オープン、クローズ、ポジション、ＧｅｔＰｏｓｉｔｉｏｎ、リネームおよびデリート方法のみインプリメントする必要がある。ＤａｒｔＥｎｇｉｎｅ６００インプリメンテーションのポータブル部分で、割り当てられたメモリ６９７（図２６参照）または他のファイルのサブファイルに保持されたファイルのファイルアクセス抽象を構築する。一度開くと、ＳｕｂＦｉｌｅを他のあらゆるファイルのように読むことができるが、データのソースおよび境界は実際には前に開いた別のファイルの正しいサブセットである。
ＳｕｂＦｉｌｅは、ソースファイルがＳｕｂＦｉｌｅの前に閉じても動作可能なままであるのが有利である。実行のためＤａｒｔのコードを読むのにＳｕｂＦｉｌｅを利用することにより、コードがその場で実行され、コードをファイルからメモリにロードする必要がなくなる。これは、ＤａｒｔがＲＯＭにあったり、ＤａｒｔＤｅｖｉｃｅのファイルストレージが、低速ハードディスクドライブ等ではなく他の迅速に読み取り可能なメモリデバイスにインプリメントされている時に特に有利である。
実行速度を改善することが必要あるいは望ましい場合、動作させるレンディションに関連するＤａｒｔのコード部分を、ＤａｒｔＣｏｎｔｅｘｔのコードの保持および動作用に割り当てられているメモリにロードして、メモリファイル（図２６、６９７）またはその同等機能を用いて実際のＤａｒｔＣｏｄｅを実行することができる。
ステップ１２．ここに述べる特に有利な実施例およびインプリメンテーションでは、ＤａｒｔＴｏｏｌｓ２００またはＭａｓｔｅｒＤａｒｔ２３０または他の初期コンストラクタをまだ含んでいる可能性のあるＤａｒｔ７００の生成したＤａｒｔコードが、ｍａｉｎ（）機能を呼び出す前に呼び出さなければならない初期コンストラクタ手順で実行を開始できる。実行を開始するコードアドレスは、動作するレンディションインスタンスに対応するＲｅｎｄｉｔｉｏｎｓＴａｂｌｅレコードの３２ビットワードの１つにある。
ステップ１３．ＤａｒｔＴｏｏｌｓ２００は、ＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎ６５９を、サブ機能値付き初期コンストラクタの末尾に自動的に入れ、これが、ＤａｒｔＥｎｇｉｎｅ  Ｐｒｏｃｅｓｓ方法４００３が初めて呼び出された時、ＤａｒｔＥｎｇｉｎｅに開始実行アドレスと、ＭａｓｔｅｒＤａｒｔ２３０命令の継続実行のためのこのオブジェクトインスタンスポインタを設定させる。
【０５５５】
これが、本発明の方法およびコンピュータプログラムの特定の実施例によるＤａｒｔの生成およびローディングの最後のステップ（ステップ１３）である。
ＤａｒｔおよびＤａｒｔ手順のダイナミック生成−クリエイショニズム
【０５５６】
Ｄａｒｔおよび／またはＤａｒｔおよびその子孫ＤａｒｔｓによるＤａｒｔＰｒｏｃｅｄｕｒｅｓの継続的動的生成の能力は、ＤａｒｔＰｌａｔｆｏｒｍ５０とＤａｒｔ技術ベースのシステムおよび方法のより強力な特性の１つである。ＤａｒｔＰｌａｔｆｏｒｍ５０の実施例は、初期ＤａｒｔｓからＤａｒｔｓの継続的で効率的な生成をサポートするためシステムを通じて設計およびアークテクチャされる。この方法をクリエイショニズムと称する。
【０５５７】
例えば、ＤａｒｔＳｏｕｒｃｅ１００は、Ｃ＋＋拡張の利用を通じて、オリジナルＭａｓｔｅｒＤａｒｔ２３０または他のＤａｒｔＴｏｏｌｓによって直接生成されたＤａｒｔｓのレンディションの生成間で混合、一致および共有できるパーツの指定を含むことができる。
【０５５８】
Ｄａｒｔｆｒａｍｅｗｏｒｋ１０２の実施例は、レンディションの指定のためのメカニズムおよび方法を明示的に提供し、全てのコード、データおよびパーツは各レンディションに入れられる。これにより、ＤａｒｔＴｏｏｌｓ２００はコンパイラ２０１とリンカ２０２によって生成されたオブジェクトの依存性ツリーを通じて構文解析をして、ＤａｒｔｓおよびＤａｒｔＰｒｏｃｅｄｕｒｅｓ４０００のダイナミックな生成に必要なコード、データおよびリソースのセクションの効果的なデータベースを形成する。同様の方法で、ＭａｓｔｅｒＰｌａｙｅｒ２０３は、あらゆる起点セットのランタイムで到達可能な全てのデータ、コード、方法および機能を通じてトレース可能で、これにより、必要なデータ、コードおよびリソースのみ含むＤａｒｔｓを生成するのに必要な情報を形成するのに有利である。到達不可能なデータ、コードおよびコンテンツは、含まれるレンディションの起点およびデータ値に基づいてＤａｒｔＦｏｒｍａｔイメージから自動的に除外される。
【０５５９】
ＤａｒｔＰｌａｔｆｏｒｍ５０の別のメカニズムを有利に用いて、他のＤａｒｔｓ７００またはＤａｒｔＰｒｏｃｅｄｕｒｅｓ４０００を生成する時点で動作中のＤａｒｔの全部あるいは一部データ状態の自動セーブ、および上記列挙したＤａｒｔＥｎｇｉｎｅのＤａｒｔローディングステップの一部としての全部あるいは一部データ状態の自動リロードに必要なコードおよびデータ量を制限できる。動作中ｄａｒｔのデータ値およびコンテンツはＤａｒｔＦｏｒｍａｔイメージの一部であるため、動作中、これらは容易にセーブおよび復元され、生成されたＤＡｒｔｓには、ＤａｒｔＰｌａｔｆｏｒｍ５０がそのために最適化され、目的としているユーザ中心アプリケーションの多くを取る初期コンストラクタおよびセットアップコードの必要は一般的にない。例えば、ＭａｓｔｅｒＤａｒｔ２３０をまずロードした時、多くのコンストラクタを呼び出してから、実行をｍａｉｎ（）機能で始まるようにセットする。これは、ほぼ全てのＣ＋＋生成プログラムおよび本発明と主に用いる他の異なるソフトウェアまたはプログラミング言語に当てはまる。ＭａｓｔｅｒＤａｒｔ２３０は、ＤａｒｔＥｎｇｉｎｅのＳａｖｅ（）方法にアクセスするのにＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎ６５９を利用した内蔵機能を用いて、ｍａｉｎ（）機能の最小命令セットで自身をセーブすることができる。現在のデータ値の完全なイメージがデフォルトでセーブされ、その後、セーブされたＤａｒｔ７００がロードされた時に復元されるため、セーブしたＤａｒｔ７００でコンストラクタを実行する必要がない。この理由から、ＭａｓｔｅｒＤａｒｔ２３０は、既に動作している初期コンストラクタを実行するコードの連続線形範囲が、生成したＤａｒｔのレンディションのいずれにも含まれないよう、セービングプロセスを指示することができる。この方法で、生成されたＤＡｒｔはこれを生成したＭａｓｔｅｒＤａｒｔ２３０より有意に小さくなることができる。アプリケーション開始時に出た状態を再確立するために必要な全ての静的コンストラクタおよびセットアップコードを保持する類似機能の従来型アプリケーション実行可能イメージよりはるかに小さくなることも多い。
【０５６０】
初期コンストラクタコードを含む必要をなくすことは、生成されたＤａｒｔｓのサイズ、複雑性、コンピュテーション要件の最適化に用いる他の多くのメカニズムおよび方法の１つにすぎない。これら最適化によって一般に、従来のメカニズムおよび方法を用いると必要なものより小さいサイズ、低い複雑性およびコンピュテーション要件になる。
【０５６１】
データメンバーデータまたはメンバー方法の除外は、ＭａｓｔｅｒＤａｒｔ２３０またはＤａｒｔＦｏｒｍａｔ３００に準拠するＭａｓｔｅｒＰｌａｙｅｒ２０３上で動作するあらゆるＤａｒｔ７００がＤａｒｔまたはＤａｒｔｓのセットを生成する時に実行される。ＭａｓｔｅｒＰｌａｙｅｒ２０３のユーザインターフェースまたはＭａｓｔｅｒＰｌａｙｅｒ  ２０３で再生中のＤａｒｔの実行を通じて、レンディションオブジェクトのあらゆる正しいサブセットが選択され、生成されるＤａｒｔ７００に含められる。
【０５６２】
一部レンディションに必要なコードおよびデータのパーツおよびセクションのみ、通常は生成したＤａｒｔｓに入れなければならない。これは、ＤａｒｔＴｏｏｌｓ２００およびＭａｓｔｅｒＰｌａｙｅｒ２０３により、コンパイラ２０１およびリンカ２０２の生成したメタデータ両方からのオブジェクトの関係を構文解析し、ランタイムデータメンバ、手順および方法コールと実際のポインタ値を通じてトレースすることにより実行され、各クラスの全てのデータメンバ、コードメンバおよび方法を見つけ、一部レンディションをその開始Ｐｒｏｃｅｓｓ（）メンバ機能から動作させることでは到達できないデータメンバ、構造メンバ、方法メンバへの全て参照およびそのスペースを、オブジェクトインスタンスおよびアクセスコードからダイナミックに除外する。こうして、生成するＤａｒｔ（ｓ）７００についてすべての開始場所が特定されると、ＭａｓｔｅｒＰｌａｙｅｒ２０３で動作するＤａｒｔの実際のランタイムセットアップに基づき、全てのクラス情報が効果的に最適化される。
【０５６３】
ＤａｒｔＰｌａｔｆｏｒｍが主に目的とするユーザ中心アプリケーションの重要な部分は、ユーザインターフェースイメージの初期画面位置設定、データ構造の初期化、接続されたオブジェクトのグラフ構築、テーブルの生成等のためのセットアップコードまたはデータから構成されるか、これを含む。ＤａｒｔＦｒａｍｅｗｏｒｋ１０２は、ほとんどのクラス定義に、ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎによってのみ呼び出されるためのＳｅｔｕｐ（）コールか、他のＳｅｔｕｐ（）コールからの入れ子コールを含む。ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎを生成したＤａｒｔ（ｓ）７００に含めるために選択しない場合、Ｓｅｔｕｐ（）方法その他方法および機能および、一部レンディションから到達できないクラスまたは静的データ要素のデータメンバのどれも生成されたＤａｒｔ（ｓ）７００には含まれないのが有利である。選択したランタイム起点から到達不可能なコード、データ、方法等は、ＤＡｒｔＴｏｏｌｓ２００によって生成されたＤａｒｔ（ｓ）７００に含まれないため、この最適化を生じさせるＳｅｔｕｐ（）コールに特別なところは何もない。
ＧａｔｈｅｒＲｅｓｏｕｒｃｅ手順
【０５６４】
ＧａｔｈｅｒＲｅｓｏｕｒｃｅｓ手順または方法は、生成したＤａｒｔ（ｓ）７００の不要なコードおよびデータを除外するためＤａｒｔＦｒａｍｅｗｏｒｋ１０２に用いることを目的とした別の手順である。ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎのＳｅｔｕｐ（）方法またはこの方法へのコールからのコールツリーが、ＧａｔｈｒｅＲｅｓｏｕｒｃｅｓ（）関連方法および機能の階層を呼び出し、ユーザインターフェースを構築するか、ＭａｓｔｅｒＤａｒｔ２３０をＭａｓｔｅｒＰｌａｙｅｒ２０３で動作させる時にデータ、コンテンツその他リソースをダイナミックに集める。
【０５６５】
本書記述と共に、ＤａｒｔＴｏｏｌｓ２００は、ＭａｓｔｅｒＤａｒｔ２３０の中に、ＭａｓｔｅｒＰｌａｙｅｒ２０３の必要とするシンボルテーブル、クラス定義、その他メタデータを保持する多数のパーツを含み、記述した最適化を実行することにも注意する。これらパーツが選択したレンディションのいずれにも含まれていない場合、生成したＤａｒｔ（ｓ）７００に含まれないのが有利である。
ＭａｓｔｅｒＤａｒｔｓの他の利用法
【０５６６】
ＭａｓｔｅｒＤａｒｔｓ２３０が、生成するＤａｒｔアプリケーション７００よりはるかに大きいサイズおよび複雑性のＤａｒｔＰｌａｔｆｏｒｍ５０のコードおよびデータを含むことは（必要ではないが）普通である。この余分なコードを用いて、アクセス、要求、初期化、ユーザインターフェース、テーブルのプレ計算、パーツの組み立て等を実行する。そのため、ＭａｓｔｅｒＤａｒｔ（ｓ）２３０は、コンパイラ２０１によってコンパイルされ、リンカ２０２によってリンクされると、時間と共に、または株価等他の状況に応じて変化する新しいパラメータ、リソースまたはその他データを用いて、プログラマまたは非プログラマがカスタマイズされたＤａｒｔ（ｓ）７００を生成するために利用または再利用することができ、リンカ２０２によってリンクされ、ＭａｓｔｅｒＰｌａｙｅｒ  ２０３上でＭａｓｔｅｒＤａｒｔ２３０を動作させた後、自動的に、あるいはユーザの要求によっていつでも、非常に広範囲にＤａｒｔアプリケーションを生成する。
パーツのダイナミックな再構成、生成、組み立ておよび最適化
【０５６７】
ここまでで明らかなように、ＭａｓｔｅｒＤａｒｔｓ２３０および他のＤａｒｔｓから生成されたＤａｒｔｓは、新しい機能および対象トランスポートおよび環境に適合した子孫の子Ｄａｒｔｓの生成について、パーツの選択およびパーツのパーツをダイナミックに再構成、生成、組み立ておよび最適化する能力を保持する。
ｃｏｎｔｅｘｔＴｙｐｅパラメータによるパーツのローディング
【０５６８】
それぞれが各レンディションについて含まれるパーツを参照するＲｅｎｄｉｔｉｏｎＴａｂｌｅｓを参照するＲｅｎｄｉｔｏｉｎｓＴａｂｌｅを用いてＤａｒｔ２３０のレンディションをロードすると、ローディングの必要なパーツはすべて、ｃｏｎｔｅｎｔＴｙｐｅパラメータにしたがってロードされる。ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔと、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔのＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎによってインプリメントされた拡張は、効率的な再構成と、Ｄａｒｔ７００またはＤａｒｔ手順４０００からの高度に最適化されたＤａｒｔｓ７００およびＤａｒｔＰｒｏｃｅｄｕｒｅｓ４０００の生成を行う。一実施例では、ＰａｒｔＴａｂｌｅＥｎｔｒｙレコードのフラッグパラメータのフラッグビットは、ローディング中、必要なｃｏｎｔｅｎｔＴｙｐｅ固有処理のあるパーツにのみ設定される。
【０５６９】
ＭａｓｔｅｒＤａｒｔは、ＭａｉｎＣｏｄｅパーツのＭａｓｔｅｒＲｅｎｄｉｔｉｏｎオブジェクトインスタンスから始まる到達可能な全てのコードについて、通常、完全なコードイメージを含む。同様に、ＭａｓｔｅｒＤａｒｔは、通常、ＭａｓｔｅｒＲｅｎｄｉｔｉｏｎオブジェクトインスタンスから始まる分岐可能な全てのデータについて完全なデータイメージを含む。この多くは、生成されたＤａｒｔＦｏｒｍａｔから除外される。
ＤａｒｔＦｒａｍｅｗｏｒｋ、ＤａｒｔＲｕｎｔｉｍｅおよびＤａｒｔＥｎｇｉｎｅ
【０５７０】
ＤａｒｔＦｒａｍｅｗｏｒｋ１０２、ＤａｒｔＲｕｎｔｉｍｅ８０００およびＤａｒｔＥｎｇｉｎｅ６００を以下にさらに詳しく述べる。ＤａｒｔＦｒａｍｅｗｏｒｋは、ＤａｒｔＥｎｇｉｎｅ，一定のＤａｒｔＲｕｎｔｉｍｅオペレーションに内蔵した機能の効率と有効利用を想定しているが、ほとんどあらゆるＣ＋＋プログラムは、あらゆるＣ＋＋ツールの標準セットにインプリメント可能か、インプリメントしたほぼ全てのランタイムを用いて、組み込みおよび動作させることができる。ＤａｒｔＦｒａｍｅｗｏｒｋの主な力の１つは、ＤａｒｔＥｎｇｉｎｅの一部としてインプリメントされた命令、メカニズム、手順および機能の緊密な統合と利用から派生するものが大きい。例えば、圧縮されたＪＰＥＧファイルまたはパーツからのビットマップイメージの解凍および構築は、インターネットで広く利用可能なＪＰＥＧ標準例からＣ＋＋ソースコードをコンパイルすることにより実行できるが、このようなコードは、ＤａｒｔＥｎｔｉｎｅ方法を呼び出して、ＤａｒｔＥｎｇｉｎｅソースコードがＤａｒｔＤｅｖｉｃｅの実際のプロセッサについてコンパイルされた時生成されるネイティブなコードを使ってＪＰＥＧ解凍オペレーションを実行するため、ＢｕｉｌｔｉｎＩｎｓｔｒｕｃｔｉｏｎ（ＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮとも呼ぶ）を採用した内蔵機能を単純に利用するより、実行がはるかに低速になることが予想される。
【０５７１】
同様に、ＤａｒｔＦｒａｍｅｗｏｒｋ１０２は、ＤａｒｔＰｌａｔｆｏｒｍ５０のインプリメンテーションを通じて内蔵機能のエコシステムまたは環境を利用し、これは、一部実施例において、実際のＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ、ＤａｒｔＲｕｎｔｉｍｅ８０００システム、通信サブシステム、イベント処理システム、ファイルシステム（図２６のファイルシステム６１２参照）、グラフィックスおよび入力システム、パワーマネージメントシステム、Ｄａｒｔアセンブリ圧縮および暗号化メカニズム、および解凍、アクセス、保護、デジタル権利マネージメントおよび生成メカニズムの全てを必要とはしないが限定せずに含む。
【０５７２】
各デバイスに具現化されたネイティブなプロセッサについて生成されたコードの効率で表現されるユーザ中心機能の正しく定義された幅広いセットまたは集合を有することは有利であり、一部実施例においては、自身を他のデバイスに拡張できるポータブルなアプリケーションに必要な機能およびアダプテーションを実用的にするための鍵であることが理解される。
【０５７３】
特に、理論的には、あらゆるチューリン準拠命令セットを他のコードの生成やアルゴリズムの実行に用いることができるが、実際には、このアプローチには、比較的完全なプラットフォームを提供する緊密に統合されたプラットフォームと同じくらいの実行、メモリ、パワーまたはコストの効率はあり得ず、ＤａｒｔＥｎｇｉｎｅのＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔの処理の場合のように、プラットフォーム固有の方法で必要なコンピュテーションまたはメモリハングリーな機能をインプリメントすることを理解しなければならない。
【０５７４】
一般に、あるデバイスをＤａｒｔデバイス（ＤａｒｔＤｅｖｉｃｅ）４００とみなすためには、ＤａｒｔＰｌａｙｅｒ５００等のＤａｒｔプレイヤをデバイスにインストールし、使用可能にされたデバイスには少なくとも１つの通信メカニズムがサポートされていなければならない。ＤａｒｔＰｌａｙｅｒ５００は、ＤａｒｔＥｎｇｉｎｅ６００の起動、初期化、プロセッサ制御およびクローズダウンに必要な環境およびオプションのユーザインターフェースを提供するデバイス固有の実行可能ユニットである。ＤａｒｔＥｎｇｉｎｅ６００は、２つの相互接続されたクラス、ポータブルのｐｌａｙｅｒＢａｓｅクラスと、デバイス固有のｈａｌＢａｓｅクラスのインスタンスとして構築される。ＤａｒｔＥｎｇｉｎｅ６００を新しいデバイスにポーティングする時、デバイス固有ＤａｒｔＰｌａｙｅｒ５００アプリケーションをＤａｒｔＥｎｇｉｎｅの実行をカプセル化するよう構築しなければならず、デバイス固有ｈａｌＢａｓｅ由来クラスは、ＤａｒｔＥｎｇｉｎｅのプラットフォーム独立パーツから実際のデバイスのオペレーティングシステムおよび／またはハードウェアへのブリッジを提供するよう構築しなければならない。
【０５７５】
ＤａｒｔＰｌａｙｅｒ５００のメインループフローを図２３に示す。まず、ＤａｒｔＥｎｇｉｎｅ．Ｉｎｉｔ（）６０００機能を、ある場合はロードするＤａｒｔ７００を特定するパラメータで呼び出す。そして、負の値が返され、ＤａｒｔＰｌａｙｅｒ．Ｕｎｉｎｉｔ（）が呼び出されて、ＤａｒｔＰｌａｙｅｒ５００アプリケーションが閉じるまで、ＤａｒｔＥｎｇｉｎｅ．Ｐｒｏｃｅｓｓ（）（図２３、４００２、図２４、６０００）機能をループで呼び出す。正のリターン値は、メインループに返す前に実行する値固有のＤａｒｔＰｌａｙｅｒ処理を生じさせる（図２３、４０００参照）。
【０５７６】
このような固有のＤａｒｔＰｌａｙｅｒ処理は、デバイスで動作する他のアプリケーションまたはプロセスへのコントロールのリリース、パワーマネージメント値に基づくＰｌａｙｅｒＥｎｇｉｎｅスレッドの中断、マウスの動きやキーボードの押し下げ等の入力の収集と、これらをコールに変換し、イベント８００をＤａｒｔＥｎｇｉｎｅのＥｖｅｎｔＱｕｅｕｅ（図１５の８００２および図１６の５０００参照）への追加することを含む。正のリターンコード値が、Ｄａｒｔが処理を終了したことを意味するために留保されているものの１つである場合、ＤａｒｔＰｒｏｃｅｓｓ．Ｕｎｉｎｉｔ（）が呼び出され、Ｄａｒｔ処理が中止される。例えば、ＤＯＮＥの正のリターンコード値を返すことは、動作中Ｄａｒｔがその終了をシグナルする通常の方法である。
【０５７７】
ＤａｒｔＥｎｇｉｎｅ．Ｉｎｉｔ（）処理を図２４に示すが、これは、ロードするＤａｒｔ７００への参照を含むＤａｒｔＥｎｇｉｎｅ．Ｉｎｉｔ（）へのコールである。アクティブなコンテキストがない時にＤａｒｔＥｎｇｉｎｅ６００が呼び出され、ロードするＤａｒｔ７００がない場合、Ｄａｒｔｅｎｇｉｎｅ内部のＩｄｌｅＰｒｏｃｅｄｕｒｅがＤａｒｔ７００のかわりにＩｄｌｅＣｏｎｔｅｘｔにロードされる。ＩｄｌｅＣｏｎｔｅｘｔで動作するＩｄｌｅＰｒｏｃｅｄｕｒｅは、図２３のＤａｒｔＥｎｇｉｎｅＥｖｅｎｔｓ４００３プロセスをアクティブに保つために必要な処理を実行するＤａｒｔＩｎｓｔｒｕｃｉｔｏｎＳｅｔ命令のループから構成される。一実施例では、ＩｄｌｅＰｒｏｃｅｄｕｒｅは単に命令を実行し、これが、図１２および図１５のＥｎｇｉｎｅＥｖｅｎｔＰｒｏｃｅｓｓｉｎｇ機能８００２へのコールを生じさせる。一実施例では、ＤａｒｔＰｌａｙｅｒ５００の単一インスタンスは、一般に、複数の方法のどれかであらゆる数の実行Ｄａｒｔｓ７００を取り扱うことができる。１つの方法は、メインループ４０００を修正するか、何らかの数の別個ＤａｒｔＥｎｇｉｎｅ６００インスタンスを作成するか、または別個スレッドを用いるか、上記の組み合わせにより、同じ動作中ネイティブプロセッサスレッド内で別個ループを呼び出すものである。別の方法は、Ｄａｒｔｓを明示的にロードし、動作中の親Ｄａｒｔサブダートまたは子として動作させるものである。ここでは、イベント処理ユニットを通過するイベント処理を、コンパイルされ、リンクされた親Ｄａｒｔの一部であるかのように、ロードしたらサブダートのイベント処理ユニットにパスする。好適なインプリメンテーションでは、これらのイベント処理ユニットはＧｉｚｍｏと呼ばれ、ＤａｒｔＦｒａｍｅｗｏｒｋクラスＧｉｚｍｏのインスタンスである。
Ｇｉｚｍｏｓ
【０５７８】
Ｄａｒｔｓ７００は、Ｄａｒｔｓが他のＤａｒｔｓの処理階層の一部として動作する場合は、直列または並列または高度に協力的な方法で他のＤａｒｔｓ７００を動作させることもできる。ＤａｒｔＦｒａｍｅｗｏｒｋ１０２は、主にＧｉｚｍｏ１１５派生オブジェクトから作ることができる。これらＧｉｚｍｏｓは、子および親Ｇｉｚｍｏポインタ（図１８の１００００参照）に従って、厳密に定義された線形順序で構成することが有利である。この順序は、Ｇｉｚｍｏｓを相互接続されたツリーグラフに集め、実行の順序と、アクセス権および画面リアルエステート、時間の観念、その他環境的特徴からその関係を決定する。例えば、親は子または子Ｇｉｚｍｏｓとその子孫のため、時間または明白な時間変化率を変更し、その処理とペースを制御することができる。これはすべて、図１８の例に示すように、指定の処理準に厳密に準拠することで、堅牢な方法でインプリメントが容易になる。
【０５７９】
図１８は、スライドショーＤａｒｔ７００アプリケーションのＧｉｚｍｏ１１５派生オブジェクトの階層例を示す。スライドショーＤａｒｔ７００アプリケーションが、スライドショーＤａｒｔのコードを構成するＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ命令を実行するのにＤａｒｔＥｎｇｉｎｅ６００を利用していることを理解することが重要である。特に、ＤａｒｔＰｌａｙｅｒ５００とＤａｒｔＥｎｇｉｎｅ６００が、ＤａｒｔＤｅｖｉｃｅ４００ネイティブプロセッサとオペレーティングシステムを対象とする標準ビルドツールを用いてコンパイル、リンク、ロード、動作されていることに注意する。ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔからの命令で構成されるスライドショーＤａｒｔ７００を実行するのはＤａｒｔＥｎｇｉｎｅ６００で、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔはＤａｒｔＴｏｏｌｓ２００から生成されている。図１８に示す階層の上部にあるＭｅｎｕ  Ｇｉｚｍｏはまず、Ｍｅｎｕ．Ｐｒｏｃｅｓｓ（）方法に基づくＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔが、ＤａｒｔＰｌａｙｅｒ．Ｐｒｏｃｅｓｓ（）コールの結果エンジン上で実行開始され、ＤａｒｔＥｎｇｉｎｅ６００にＤａｒｔ７００命令の処理を始めさせた時、制御を取るものである。好適なインプリメンテーションでは、階層上部のＧｉｚｍｏは、図１１に示すように基本Ｇｉｚｍｏクラスから継承したクラスのレンディションオブジェクトである。
【０５８０】
図１８の例では、角の丸いコーナーボックスは、スライドショーアプリケーションのユーザインターフェースのユニットを扱うＧｉｚｍｏ派生オブジェクトを表す。このメニューは、スライドの追加、スライドの自動シーケンスの開始、スライド遷移効果の選択等を含む各種機能を選択するためのユーザインターフェースを扱う。メニューから選択できるオプションの１つに、スライドショーのビューがある。この例におけるビューは、例えばユーザがスライドの名称や説明をクリックできるハイパーリンクインデックスビューや、ユーザがスライドの小さいサムネイルビューをクリックできるサムネイルインデックスビュー、スライドが画面の最大限を取るスライドショービューや、スクリーンで、矢印や物理的ボタンまたはマウスまたはペンを用いて、スライドの階層を前後に動けるものなどがある。メニューは、子Ｇｉｚｍｏ派生オブジェクトは１つしかないが、ユーザがメニューからビューを選択すると、子Ｇｉｚｍｏ派生オブジェクトへのポインタが、選択したビューをサポートするＧｉｚｍｏに変わる。そのため、ユーザの見え方と、スライドショーのナビゲーションを変更するのに必要な全てがメニューＧｉｚｍｏのポインタ１つの変更となり有利である。
【０５８１】
例における各ビューは、図１８でその下の列に示す３個の子Ｇｉｚｍｏ１１５派生オブジェクトへのポインタのリストを有する。子はすべて、３つのビューの子ポインタリストのそれぞれでポインタの順の左から右に示す単純な静止画またはスライドである。「３」のラベルがついたＧｉｚｍｏ派生オブジェクトの子ポインタリストは、左から右へ示す順序で３個の子をポイントする。「４」のラベルのオブジェクトは、別個に製造した動作サブダートをカプセル化するＧｉｚｍｏ１１５派生オブジェクトを表し、これは１枚のスライドとしてスライドショーに含まれるが、実際は、それぞれが画像、ビューまたはＤａｒｔ７００とその全ての機能性を含むことができる自身のスライド階層を持つことができる。「７」と「９」のラベルのついたボックスは、リアルタイム再生ビデオ／オーディオスライドを表示するＧｉｚｍｏ１１５派生オブジェクトを含む。このスライドでは、Ｇｉｚｍｏ１１５派生オブジェクトとＤａｒｔ再生Ｇｉｚｍｏｓ１１５の被含有Ｄａｒｔｓ７００全てによるイベントの処理が、子および親へのポインタによって生成されるグラフの順序で処理制御を受け取ることに注意する。この順序は、図１８のボックス内に示す数値のシーケンスに明示的に記載される。
【０５８２】
Ｇｉｚｍｏ１１５派生オブジェクトによる処理はほぼ全て、パラメータとして処理するイベントへのポインタでそのＰｒｏｃｅｓｓ（）方法をコールすることによるため、どの親も、その子の見るパラメータまたはイベントのタイプを生成または変更することができ、または、その子に処理させるイベントをパスするか否か決定することができる。そのため、実際は、どの親もその子全ての環境を設定することができる。例えば、Ｄａｒｔ含有Ｇｉｚｍｏオブジェクトは、その親が利用可能なスクリーンリアルエステートの一部しか与えられないことを知る必要はない。同様に、Ｇｉｚｍｏ１１５派生オブジェクトがそのＧｅｔＴｉｍｅ（）方法にアクセスする時、親が、その子のタイムソースであることをシグナルしている場合、内蔵コールからエンジンではなく、その親に自動的にタイムを要求する。この親がその子のランタイム環境とその子を制御する能力は、ＤａｒｔＦｒａｍｅｗｏｒｋ２００とＤａｒｔＲｕｎｔｉｍｅ８０００の非常に強力な特性である。これによって、例えば、スライドショーのスライドショー、Ｄａｒｔｓを集めただけのコレクションＤａｒｔｓを構築し、ユーザがどれを動作させるか選択すること、Ｄａｒｔ７００の形式のコントロールパネルをプリンタから他のＤａｒｔイネーブルなデバイスにフェッチして、フェッチしたＤａｒｔ内部に埋め込んだ四角形で動作させる能力が容易になる。
ＤａｒｔＥｎｇｉｎｅアーキテクチャ−コントロールのパス
【０５８３】
ＤａｒｔＥｎｇｉｎｅ６００のアーキテクチャは、ＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮ機能を含むことにより、Ｇｉｚｍｏ１１５派生オブジェクトの含有を可能にして、被含有Ｄａｒｔ７００にＤａｒｔＣｏｎｔｅｘｔを生成し、そのコンテキストにＤａｒｔ７００をロードしてから、階層の最上部のＧｉｚｍｏ１１５の被含有ＤａｒｔのＰｒｏｃｅｓｓ（）方法へのＤａｒｔＥｎｔｉｎｅのＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮコールを介して被含有Ｄａｒｔ７００Ｐｒｏｃｅｓｓ（）をコールすることにより、被含有Ｄａｒｔの階層でＤａｒｔ含有Ｇｉｚｍｏ１１５派生オブジェクトから最上部のＧｉｚｍｏ１１５へのコントロールのパスを容易にする。
【０５８４】
処理を管理し、被含有Ｄａｒｔｓ７００にパスするコールと共に。ＤａｒｔＥｎｇｉｎｅ６００は、イベント８００へのポインタを含むＥｖｅｎｔＰｒｏｃｅｓｓｉｎｇ構造インスタンスを被含有Ｄａｒｔで処理できるようにすることで、含有Ｄａｒｔ７００コードから被含有Ｄａｒｔコードへより効率的に遷移させ、メモリへの特殊ポインタ（図３２、ポインタタイプ１１参照）の利用により直接アクセス可能なメモリで全てのＤａｒｔＣｏｎｔｅｘｔｓ間で効果的に共有されるようにする。これにより、それぞれ別個アドレススペースを有するＤａｒｔｓ７００間でイベント８００およびその他パラメータの効率的なパスが可能になる。
【０５８５】
１つのＤａｒｔ７００から別のＤａｒｔ７００へコールした時、ＤａｒｔＥｎｇｉｎｅはコールしたＤａｒｔのＤａｒｔＣｏｎｔｅｘｔを覚えてから、エンジンスタックが当初コールが行われた場所と同じ場所になった時にコールされたＤａｒｔのＤａｒｔＣｏｎｔｅｘｔがＤｏｎｅＩｎｓｔｒｕｃｔｉｏｎを実行するまで、コールされたＤａｒｔのＤａｒｔＣｏｎｔｅｘｔから動作を開始する。このように、ＤａｒｔＥｎｇｉｎｅ６００は、Ｄａｒｔｓ７００が１つのＤａｒｔ７００としてＤａｒｔＴｏｏｌｓによって生成されたかのように、Ｇｉｚｍｏ１１５派生階層の一部としてＤａｒｔ７００を無限に動作させるＤａｒｔ７００の動作を非常に容易かつ効率的にする。含有Ｄａｒｔｓは、子のＧｉｚｍｏ１１５派生オブジェクトに対して可能なのと同じように、被含有Ｄａｒｔｓ７００に求めるあらゆる環境を提示することができる。
【０５８６】
再表示の必要がない静止画像を提示するＧｉｚｍｏ１１５派生オブジェクトのような処理を必要としないＧｉｚｍｏ１１５派生オブジェクトのコールで階層全体を下ってコントロールを単にパスすることはプロセッサの時間の無駄と考えられるかもしれない。この問題は、Ｇｉｚｍｏ１１５派生オブジェクトコールのツリーを切り詰めるシステムによってある好適な実施例では悪影響を受ける恐れがある。各ＥｖｅｎｔＴｙｐｅ８０１の値は、正確に１ビットを設定するカテゴリーフラッグフィールドと、そのカテゴリーに属する、処理すべきイベント８００のイベントサブタイプフィールドとからなる。ある実施例では、イベントタイプ８０１のカテゴリーフラッグに対応する２セットのフラッグがある。Ｇｉｚｍｏ派生オブジェクト自身がこのタイプのイベントを取り扱う必要がある場合、一方のフラッグが設定され、その子孫のいずれかがイベント８０１の特定のカテゴリーを見る必要がある場合は他方のフラッグが設定される。一実施例では、階層を通じた各パスで、Ｇｉｚｍｏ１１５派生オブジェクトは自分自身にフラッグを設定し、自分がコールする全ての子によって設定されたフラッグの論理的ＯＲされた集合を集める。そのため、Ｇｉｚｍｏは常に、処理するイベント８００のカテゴリーによりその子を呼び出す必要があるかないかを知っている。カテゴリーは、不要なコールの除外を効率的にするため、ＥｖｅｎｔｓＴｙｐｅｓのセットによって定義される。例えば、ユーザ入力と関係するイベント８００は、ユーザ入力を処理する必要のあるＧｉｚｍｏ１１５派生オブジェクトを含まないＧｉｚｍｏ１１５派生オブジェクトのツリーを下にパスする必要はない。
ＤａｒｔＥｎｇｉｎｅ．Ｐｒｏｃｅｓｓ（）処理
【０５８７】
ＤａｒｔＥｎｇｉｎｅ．Ｐｒｏｃｅｓｓ（）処理を図２３、図１５および図１６の実施例に示す。これは、ＤａｒｔのＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ命令６１１の主な実行を駆動する。メインループを実行して、Ｄａｒｔの命令ストリームから次の命令を取得し、命令のオペコードとソースと目的地フィールドをデコードし、アドレス指定されたソースおよび目的地パラメータがＤａｒｔのＤａｒＣｏｎｔｅｘｔのデータ領域外ではないことをチェックしてから、命令のオペコードフィールドによって呼び出される機能を実行するＤａｒｔＰｌａｙｅｒ６００方法または機能のデバイスプロセッサネイティブコードにジャンプする。命令のソースまたは目的地フィールドがアクセスの許されたもの以外のパラメータを指定する場合、オペコードに基づくディスパッチは行わず、特定のアクセス違反を反映する特定のネイティブリターン値のあるＤａｒｔＰｌａｙｅｒ．Ｐｒｏｃｅｓｓ（）コール直後にコントロールが返される。これにより、ＤａｒｔＰｌａｙｅｒ５００はＤａｒｔＰｌａｙｅｒ．Ｕｎｉｎｉｔ（）を呼び出し、エラーメッセージその他任意のインジケータでＤａｒｔの実行を終了する。
【０５８８】
図２２は、ＤａｒｔＰｌａｙｅｒ５００、ＤａｒｔＥｎｇｉｎｅ６００およびハードウェア抽象化層（ＨＡＬ）６５０の関係と機能の一部を示す。ＨＡＬ６５０は、必要なデバイス固有アクセス機能をカプセル化するために用いるｈａｌＢａｓｅクラスから派生したクラスとしてインプリメントされるプレイヤの一部である。インプリメントする必要のあるｈａｌＢａｓｅ機能の数と複雑性は、新しいＤａｒｔＤｅｖｉｃｅ４００タイプへのポーティングが迅速かつ容易になるよう最小限に抑えられる。ｈａｌＢａｓｅ設計への最小限アプローチはまた、別個にインプリメントしたＤａｒｔＥｎｇｉｎｅｓ６００が、インプリメンテーションソースコード機能の大半を共有するため非常に高度な互換性を持つことができるという利点もある。そのため、できるだけ多くの機能性をＤａｒｔＰｌａｙｅｒ５００のポータブルデバイス独立部分に移すことが非常に有利である。ポーティングの容易さと非常に高度な互換性は、可能な場合は常にポータブルコードを利用し、可能な場合は常に各デバイスで同じソースコードを利用することにより部分的に実現されるＤａｒｔＰｌａｔｆｏｒｍ５０の実施例の重要な特徴である。そのため、リコンパイルとリンクがそれぞれのデバイスに必要になることが多いが、機能性の多くは、そのデバイスと協力して動作できるよう他のデバイスと同じソースコードからコンパイルされることになる。
アーキテクチャのパワーマネージメント特徴
【０５８９】
パワーマネージメントは、ＤａｒｔＰｌａｔｆｏｒｍ５０アーキテクチャの多くのパーツを通じて任意であるが動作するもう１つの特徴である。ＤａｒｔＰｌａｙｅｒ５００がＤａｒｔＥｎｇｉｎｅ．Ｐｒｏｃｅｓｓ４００３方法を呼び出すと、Ｇｉｚｍｏ派生オブジェクト階層の実行が、ミリ秒（またはその他単位）で必要な応答時間を保持する変数を設定することにより、最上位表現可能値に設定することによって開始される。イベントがＧｉｚｍｏ１１５派生オブジェクトの順序付けツリーに処理される時、各オブジェクトはＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮを用いて、Ｐｒｏｃｅｓｓ（）方法を再び呼び出す必要が出るまでどのくらい待てるかをＤａｒｔＥｎｇｉｎｅ６００に知らせる。
【０５９０】
例えば、動画ビデオを表示するオブジェクトについては、ビデオのフレームレートである場合、これは１秒の１／３０になる。ＤａｒｔＥｎｇｉｎｅ６００は、パラメータとしてパスされた最小応答時間ニーズの収集をインプリメントするＢＵＩＬＴＩＮ＿ＩＮＳＴＲＵＣＴＩＯＮの報告する最低応答時間ニーズを集める。Ｇｉｚｍｏツリーグラフの階層全体を完全にパスした後、ＤａｒｔＰｌａｙｅｒ５００にコントロールが返されると、ＤａｒｔＰｌａｙｅｒ５００またはＤａｒｔＥｎｇｉｎｅ６００は、この情報を用いてそのスレッドをブロックするか、少なくとも表示の時間は電力が必要ないとシグナリングすることができる。通常は、ＤａｒｔＰｌａｙｅｒ５００は、集めた最小応答時間に等しいタイムアウトでスレッドをブロックする。Ｄａｒｔ７００によって処理する必要のある新しい入力が到着すると、このブロックも終了する。多くの場合、プロセッサで動作するアプリケーションは、常に真の応答時間ニーズを知っている唯一のエンティティで、Ｄａｒｔアプリケーションは、ＤａｒｔＰｌａｙｅｒ５００がこの情報を受け取り、ダイナミックなアプリケーションのパフォーマンスを大きく低下させることなく、デバイスのパワーおよびエネルギー消費量を大きく減らすためにこれを活用できるような方法で、設計および生成するのが有利である。
イベント処理待ち行列メカニズム
【０５９１】
イベント処理待ち行列メカニズムは、ＥｎｇｉｎｅＥｖｅｎｔＰｒｏｃｅｓｓｉｎｇ（図１５、８００２、図１６、５０００）処理中に実行されるものだが、Ｇｉｚｍｏ．Ｐｒｏｃｅｓｓ（ＥｖｅｎｔＩｎｆｏ＊）呼び出し階層の一部ではない非同期プロセス（図１６、点線ボックスの中身）の応答時間ニーズを追跡または監視もすることができる。このように、アクティブなＤａｒｔｓの報告する最小応答時間ニーズは、Ｇｉｚｍｏツリーのリニアタスキングが実行中のメインストリーム同期Ｄａｒｔアプリケーション処理と、ＤａｒｔＥｎｇｉｎｅ６００のイベント処理部分の扱う非同期プロセスのニーズの組み合わせを反映する。
セキュリティと整合性−命令デコード中に実行される実行チェック
【０５９２】
ＤａｒｔＰｌａｔｆｏｒｍ５０のセキュリティ、整合性および堅牢度は、少なくとも部分的に、ＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔの命令をデコードしている間実行される実行チェックを利用して保証することができる。命令のデータおよびソースフィールドのアドレスをエンジンによって試験して、動作中のＤａｒｔＣｏｎｔｅｘｔにしたがって実行Ｄａｒｔｓの合法的にアクセス可能なデータ領域の範囲内でデータを参照するようにする。同様に、アプリケーションの手順を構成するＤａｒｔアプリケーションとＤａｒｔＩｎｓｔｒｕｃｔｉｏｎＳｅｔ命令を、動作Ｄａｒｔに属する物理的ストレージへのアクセスに制限する。これは、悪意または誤作動のＤａｒｔｓが、動作Ｄａｒｔｓがアクセス可能であってはならないプライベートなデータやストレージリソースにアクセスする権限を持つことを防ぐためである。
【０５９３】
ハードウェア抽象化層（ＨＡＬ）ファイルシステムのネーミング規約によって、Ｄａｒｔアプリケーションがその合法的ドメイン外のファイルを指定する方法がない（しかし、オプションの意図的な例外は見る）ようにしている。オープンや削除等のオペレーションについてファイルを指定する際、Ｄａｒｔアプリケーションは完全なファイルパスを指定することはできず、図２８の５０１０に示すようにロケーションＩＤおよび番号、またはロケーションＩＤおよびターミナル名ストリングのみ指定できる。このように、物理的アクセス可能ストレージはＨＡＬの中で図２８の５０２０に出現するロケーションに限定される。ファイルを指定するためこれらパラメータにのみ基づき、オープン、クローズ、リード、ライト、ポジション、リネームおよびゲットポジションオペレーションを実行するのはＨＡＬの責任である。ＨＡＬ実施サンドボックス外でのアクセス禁止の意図的だが任意の１つの例外は、ＵＳＥＲ＿ＳＰＥＣＩＦＩＥＤ＿ＬＯＣＡＴＩＯＮに対応するロケーションＩＤを任意でＨＡＬでサポートし、Ｄａｒｔｓ  Ｃｏｎｔｅｘｔ限界外でファイルへのアクセスを提供するものである。これにより、アプリケーションはユーザの関与により与えられた暗示的許可がある場合のみ、ファイルのインポートおよびエクスポートができる。
【０５９４】
本発明の構造、方法、装置、コンピュータプログラムおよびコンピュータプログラム製品をいくつかの特定の実施例を参照して説明したが、この説明は本発明を図解するためのもので、本発明を限定すると解釈してはならない。添付の特許請求の範囲に定義する本発明の精神および範囲を逸脱することなく各種修正が当業者に発生する。本書で行う引用は、参照により本書に組み込まれる。
【図面の簡単な説明】
【０５９５】
【図１】Ｎ個のデバイスを相互運用または全体として共に動かすには、Ｎ乗のオーダーのアダプテーションが必要な状況を示す図である。
【図２】８個のデバイスを直接協働させることの複雑性と、オペレーションの試験と検証に５６のオーダーのアダプテーションと５６の異なる試験構成が必要なことを示す図である。
【図３】本発明の一実施例のメインコンポーネントとサブコンポーネントのブロック図を示す。
【図４】本発明の一実施例による例示的代表的ＤａｒｔＤｅｖｉｃｅの概要を示す図である。
【図５】フローチャートの形式でリクルートメント手順の例を示す図である。
【図６】第１のＤａｒｔＤｅｖｉｃｅが、発信の第１ＤａｒｔＤｅｖｉｃｅやＤａｒｔアプリケーションについて何も知らない第２のＤａｒｔＤｅｖｉｃｅとＤａｒｔアプリケーションを（スライドショーＤａｒｔアプリケーション等）拡張して共有するための進歩的なリクルートメント方法の一例を示す図である。
【図７】発信ＤａｒｔＤｅｖｉｃｅで動作するスライドショーアプリケーションから、発信の第１のＤａｒｔＤｅｖｉｃｅやスライドショーアプリケーションについて当初は何も知らない別のＤａｒｔＤｅｖｉｃｅでリモート印刷するためのリクルートメントの例を示す図である。
【図８】それぞれが発信Ｄａｒｔの異なるレンディションを動かす３つのデバイスのチームで動作するＤａｒｔとして表される写真印刷アプリケーションの例を示す図である。
【図９】リクルートされた協働デバイスのチーム間で動作するＤａｒｔアプリケーションの同期と直列化の実施例を示す図である。
【図１０】Ｎに対する単純比例であるよう、リクルートメントによってデバイスのグループを１つのデバイスとして動作させ、Ｎ個のデバイスのインタオペラビリティを達成する努力を制限する様子を示す図である。
【図１１】クラス階層の主なＤａｒｔＦｒａｍｅｗｏｒｋオブジェクトとその相対位置の実施例のブロック図である。
【図１２】アプリケーションの開発デバイスとＤａｒｔアプリケーションの生産に用いる静的および手順的コンポーネントを示すブロック図である。
【図１３】ＤａｒｔＦｏｒｍａｔの実施例のパーツコンポーネントの構造の実施例の構造を示すブロック図である。
【図１４】ＤａｒｔＰｒｏｃｅｄｕｒｅの実施例の構造を別途示す、ＤａｒｔＦｏｒｍａｔのＰａｒｔＴａｂｌｅコンポーネントと、ＰａｒｔＴａｂｌｅのＰａｒｔＴａｂｌｅレコードコンポーネントの実施例の構造のブロック図である。
【図１５】ＤａｒｔアプリケーションのＧｉｚｍｏ由来オブジェクトの階層を通過するＤａｒｔＲｕｎｔｉｍｅ処理のフローチャート図を示す。
【図１６】ＤａｒｔＲｕｎｔｉｍｅのプロセスイベント処理部分の態様を示すフローチャート図である。
【図１７】１つのＤａｒｔＤｅｖｉｃｅで始まり、リクルートメントを用いて他のＤａｒｔＤｅｖｉｃｅに拡張し、これがそれぞれの活動を調整するため図示のイベントデータ構造の形式でメッセージを交換する、Ｄａｒｔアプリケーションの実施例が用いるＤａｒｔＤｅｖｉｃｅ間の接続を示すブロック図である。
【図１８】スライドショーまたはメディアディスプレイアプリケーションの実施例で用いるＧｉｚｍｏ処理ユニットの階層的処理配置と実行順を示すブロック図である。
【図１９】本発明の一実施例によるＤａｒｔアプリケーションレベルエラー復元の例を示す図である。
【図２０】ＤａｒｔＥｎｇｉｎｅによって実行されるＢｕｉｌｉｎＩｎｓｔｒｕｃｔｉｏｎおよびＯＥＭ＿Ｂｕｉｌｔｉｎｉｎｓｔｒｕｃｔｉｏｎ処理を示すフローチャート図である。
【図２１】あるデバイスが、独自のケイパビリティを前もって知らないデバイスに、独自のケイパビリティを露出する方法を示す仮説的Ｎｅｕｔｒｉｎｏ  Ｄｅｔｅｃｔｏｒ／Ｍｏｂｉｌｅ  Ｐｈｏｎｅ例を示す。
【図２２】ＤａｒｔＰｌａｙｅｒの実施例と、ＤａｒｔＥｎｇｉｎｅの実施例の特定のインプリメンテーションの２つの主なコンポーネント、すなわち、ポータブルコンポーネントと、非ポータブルのハードウェア抽象化層コンポーネントを示す図である。
【図２３】ＤａｒｔＰｌａｙｅｒの特定の実施例のメインループ処理フローのフローチャート図を示す。
【図２４】ＤａｒｔＰｌａｙｅｒによるＤａｒｔＥｎｇｉｎｅ初期化機能へのコール中に発生する処理のフローチャート図を示す。
【図２５】ＤａｒｔＰｌａｙｅｒにインプリメントしたＤａｒｔＲｕｎｔｉｍｅ命令処理を示すフローチャート図を示す。
【図２６】ＤａｒｔＰｌａｙｅｒのファイルシステム命令処理のフローチャート図を示す。
【図２７】ＤａｒｔＥｎｇｉｎｅの一実施例の非ポータブルのハードウェア抽象化層のコンポーネントを示すブロック図である。
【図２８】Ｄａｒｔからのファイルへのアクセスを提供するが、動作中Ｄａｒｔの保護Ｓａｎｄｂｏｘの一部とみなされないファイルへのアクセスのための機構は提供しないファイルシステムの非ポータブルなＤａｒｔＤｅｖｉｃｅ固有部分を示す図である。
【図２９】ＤａｒｔＤｅｖｉｃｅのＤａｒｔＳｅｃｕｒｉｔｙコンポーネントの実施例のブロック図を示す。
【図３０】ソーシャル同期連絡先リスト例の実施例を示す。
【図３１】例示的ＤａｒｔＤｅｖｉｃｅとそのソーシャルセキュリティコンポーネントのブロック図、および古いＤａｒｔＤｅｖｉｃｅと新しいＤａｒｔＤｅｖｉｃｅのソーシャルセキュリティコンテンツのチーム化前後を示すブロック図である。
【図３２】特定のバーチャルポインタアドレスでデータ要素にアクセスするために用いられるＤａｒｔバーチャルポインタ例を示す。
【図１】
2008503011.tif 000003
【図２】
2008503011.tif 000004
【図３】
2008503011.tif 000005
【図４】
2008503011.tif 000006
【図５】
2008503011.tif 000007
【図６】
2008503011.tif 000008
【図７】
2008503011.tif 000009
【図８】
2008503011.tif 000010
【図９】
2008503011.tif 000011
【図１０】
2008503011.tif 000012
【図１１】
2008503011.tif 000013
【図１２】
2008503011.tif 000014
【図１３】
2008503011.tif 000015
【図１４】
2008503011.tif 000016
【図１５】
2008503011.tif 000017
【図１６】
2008503011.tif 000018
【図１７】
2008503011.tif 000019
【図１８】
2008503011.tif 000020
【図１９】
2008503011.tif 000021
【図２０】
2008503011.tif 000022
【図２１】
2008503011.tif 000023
【図２２】
2008503011.tif 000024
【図２３】
2008503011.tif 000025
【図２４】
2008503011.tif 000026
【図２５】
2008503011.tif 000027
【図２６】
2008503011.tif 000028
【図２７】
2008503011.tif 000029
【図２８】
2008503011.tif 000030
【図２９】
2008503011.tif 000031
【図３０】
2008503011.tif 000032
【図３１】
2008503011.tif 000033
【図３２】
2008503011.tif 000034
【国際調査報告】
2008503011.tif 000035
2008503011.tif 000036
2008503011.tif 000037
2008503011.tif 000038
2008503011.tif 000039