JP2017130193A - プロセス間通信を改善する方法及び装置 - Google Patents

Abstract

【課題】送信ピアのネットワーク伝送効率を改善する方法、装置、システム及び製品を提供する。【解決手段】システムは、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するエンコーダインタフェースと、ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成する複合インタフェース記述（ＣＩＤ）エンジンと、ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成する複合レイアウト記述（ＣＬＤ）エンジンと、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善するクライアントペイロードエンジンと、を備える。【選択図】図１Ａ

Description

本開示は、一般に情報交換に関し、より詳細には、プロセス間通信を改善する方法及び装置に関する。

近年、サーバ装置は、携帯電話、タブレット、パーソナルコンピュータ等のユビキタスネットワーククライアント装置から情報を収集している。一部の例では、クライアント装置は、そこで実行されるプログラムによって指示される情報を収集するために１以上のタスクを実行する。クライアント装置からの要求に応答して、サーバ装置は、要求側エンティティが収集された情報を取り出すことを望む状況では、収集された情報を特定のフォーマットで記憶する。クライアント装置、サーバ装置及び要求側エンティティが異なるとアーキテクチャタイプが異なることがあるので、クライアント装置は、収集されたタスク情報を、サーバ装置によって読み取られ且つ／又は処理され得る１以上の特定のフォーマットに符号化する。

プロセス間通信を改善するシステムを含むネットワーク環境の概略図である。 図１Ａに示される例示のプロセス間通信エンジンの概略図である。 本開示の教示に従って構成された送信側クライアント装置の概略図である。 本開示の教示に従って構成された例示の複合インタフェース記述（ＣＩＤ）を示す図である。 本開示の教示に従って構成された例示の複合レイアウト記述（ＣＬＤ）を示す図である。 本開示の教示に従って構成された受信側サーバ装置の概略図である。 本開示の教示に従って構成されたサーバ側ＣＩＤ及びサーバ側ＣＬＤの例示の生成を示す図である。 列挙データタイプに関連する例示のＣＩＤ及び例示のＣＬＤを示す図である。 本開示の教示に従って構成された例示の列挙解決テーブル（ＥＲＴ）を示す図である。 図２の例示の送信側クライアント装置及び／又は図４の例示の受信側サーバ装置を実現するために実行されてよい例示の機械可読命令を表すフローチャートである。 図２の例示の送信側クライアント装置及び／又は図４の例示の受信側サーバ装置を実現するために実行されてよい例示の機械可読命令を表すフローチャートである。 図２の例示の送信側クライアント装置及び／又は図４の例示の受信側サーバ装置を実現するために実行されてよい例示の機械可読命令を表すフローチャートである。 図２の例示の送信側クライアント装置及び／又は図４の例示の受信側サーバ装置を実現するために実行されてよい例示の機械可読命令を表すフローチャートである。 図２の例示の送信側クライアント装置及び／又は図４の例示の受信側サーバ装置を実現するために実行されてよい例示の機械可読命令を表すフローチャートである。 図２の例示の送信側クライアント装置及び／又は図４の例示の受信側サーバ装置を実現するために実行されてよい例示の機械可読命令を表すフローチャートである。 図２の例示の送信側クライアント装置及び／又は図４の例示の受信側サーバ装置を実現するために実行されてよい例示の機械可読命令を表すフローチャートである。 図２の例示の送信側クライアント装置又は図４の例示の受信側サーバ装置を実現するために、図８〜１４の例示の機械可読命令を実行するように構成される例示のプロセッサプラットフォームのブロック図である。

ネットワークアプリケーションは、リモートプロシージャコール（ＲＰＣ）等の１以上のトリガに応答してデータを交換してよい。この場合、例示の第１のアプリケーション（例えばネットワーク化されたサーバ）は、特定のデータフィールドを有する要求を送信し、それらの同じデータフィールドを含む例示の第２のアプリケーション（例えばネットワーク化されたモバイルピアデバイス）からの応答を期待する。一部の例では、第２のアプリケーションは、周期的持続時間、非周期的持続時間、スケジュールされた時間持続時間、メモリ記憶容量閾値、センサ応答イベント及び／又は手動トリガ等のトリガに応答して、レポートを送信することができる。例示の第２のアプリケーションによって収集され且つ／又は別の方法で取得されたデータは、第２のアプリケーションを実行するクライアント装置に記憶されてよい。この場合、収集されたデータは、バイナリフォーマット等のネイティブフォーマットで、メモリ及び／又は他のストレージに記憶される。バイナリフォーマットで記憶されたデータは、通常アーキテクチャ固有のものである。この場合、異なるアーキテクチャは、異なるバイトサイズ（１バイトあたり８ビット、１バイトあたり１６ビット等）、異なるエンディアンネス（ビッグエンディアン、リトルエンディアン、混合エンディアン等）及び／又は異なるオフセットアラインメントを利用する。

図１は例示のプロセス間環境１００であり、例示の送信側クライアント装置１０２が例示のネットワーク１０６を介して例示の受信側サーバ装置１０４と通信可能に接続される。一部の例では、送信側クライアント装置１０２及び受信側サーバ装置１０４は、共通のプラットフォーム上に常駐し、且つ／又は別の方法で動作し、これらの間の通信は、例示のネットワーク１０６の代わりに通信バス１８８を用いる。例示のネットワーク１０６は、任意のタイプの通信プロトコル（ＴＣＰ／ＩＰ、ソケット通信プロトコル／インタフェース、Ｉ^２Ｃを介するプロセス間通信、共有メモリ等）を採用してよく、有線ネットワーク（例えばＣＡＴ５ルータ／スイッチネットワーク）、無線ネットワーク（例えばＷｉＦｉ）及び／又はセルベースのネットワーク（ＧＳＭ（登録商標）、ＣＤＭＡ等）を含んでよい。更に別の例では、ネットワーク１０６は採用されず、ハードウェアベースの通信ではなく論理的通信と同じプラットフォーム内で、任意の他のタイプの通信プロトコルが採用されてよい。動作中、例示の送信側クライアント装置１０２は、例示のクライアントタスクエンジン１０３又は仮想マシン（ＶＭ）１５２を用いて、タスクプロセス１８４等の１以上のタスクを実行し、収集されたデータ及び／又は他の方法で生成されたデータ（送信側クライアント装置１０２の例示のペイロードストレージ１０８に記憶されたタスクデータ等）を（例示の送信クライアント入出力（Ｉ／Ｏ）インタフェース１１２を介して）例示の受信側サーバ装置１０４に送信して、（例示の受信側サーバＩ／Ｏインタフェース１１４を介して）例示のサーバデータストア１１６に記憶する。図１の図示の実施例は単一のタスクプロセス１８４を含むが、本明細書に開示される実施例は任意の数のタスクプロセスを含むことができる。送信前に、例示の送信側クライアント装置１０２の従来のアプリケーションは、エンコーダ１１０を呼び出して、例示の受信側サーバ装置１０４と互換性のあるフォーマットにペイロードを符号化する。特に、例示のエンコーダ１１０は、例示の受信側サーバ装置の例示のデコーダ１１８に準拠したフォーマットで符号化を行う。したがって、デバイスアーキテクチャ及び／又はデータスキーマが変更された場合、例示のエンコーダ１１０及び例示のデコーダ１１８の変更は、それらの間の通信を成功させるために行われなければならない。例示の送信側クライアント装置１０２は、例示の受信側サーバ装置１０４からの要求に応答して、且つ／又は他のタイプのトリガ（例えば、送信側クライアント装置１０２によって管理される時間ベースのトリガ、送信側クライアント装置１０２によって管理されるセンサベースのトリガ等）に応答して、例示のペイロードストレージ１０８内のデータの１以上の部分を送信してよい。

しかしながら、例示の送信側クライアント装置１０２のアーキテクチャは、例示の受信側サーバ装置１０４のアーキテクチャとは異なる可能性があるので、送信側クライアント装置１０２は、データの１以上の部分を、ネイティブバイナリフォーマットから例示の受信側サーバ装置１０４によって処理できるフォーマットに符号化する例示のエンコーダ１１０を備える。例えば、エンコーダ１１０は、ネイティブバイナリ（或いはその一部）を、拡張マークアップ言語（ＸＭＬ）フォーマット、抽象構文記法（ＡＳＮ、例えばＡＳＮ．１）フォーマット、テキストフォーマット（例えばＡＳＣＩＩ）等に変換してよく、且つ／又は他の方法で符号化してよい。一部の例では、ネイティブバイナリを代替フォーマットに符号化すると、データストレージフットプリントが比較的大きくなる。更に、送信側クライアント装置１０２の例示のエンコーダ１１０は、１以上の受信側サーバ装置と通信する所定の対象フォーマットに固有である。

図１の例示の送信側クライアント装置等の例示の送信側クライアント装置は、典型的には、限定された処理及び／又は記憶リソースを有する。一部の例では、送信側クライアント装置１０２は、（ａ）バッテリ容量によって制限される電力消費能力、（ｂ）オンボードメモリによって制限される記憶容量能力、及び／又は（ｃ）オンボード処理装置によって制限される処理能力を有する無線電話である。更に、バイナリが代替フォーマットに符号化されるとき、データの代替フォーマット（例えば、人間が読めるＡＳＣＩＩ）は、ネイティブバイナリフォーマットと比較して送信中の安全性が低い。更に、例示の送信側クライアント装置１０２及び／又は例示の受信側サーバ装置１０４が符号化及び／又は復号動作のスキーマを変更する場合、それらの間の互換性は中断され、通信を可能にする追加の構成動作が必要となる。

本明細書に開示される例示の方法、装置、製品及び／又はステムは、ネットワーク１０６（或いは共通のプラットフォーム内）のピア（例えば、例示の送信側クライアント装置１０２と例示の受信側サーバ装置１０４）間で情報を交換する改善された方法を容易にする。以下で更に詳述するように、例示のクライアントペイロードエンジン１５０は、例示のクライアントタスクエンジン１０３の１以上のタスクプロセス１８４によって生成され、且つ／又はペイロードストレージ１０８に記憶されていたネイティブバイナリフォーマットを保存する形で、例示の送信側クライアント装置１０２からのデータの送信を容易にする。

このようなネイティブバイナリフォーマットの保存により、１以上の宛先ピアに送信する前にネイティブバイナリを人間が読めるフォーマットに符号化する際に従来他の方法で発生した、例示の送信側クライアント装置１０２の計算負荷が軽減される。更に、このようなネイティブバイナリフォーマットの保存により、人間が読めるフォーマットで符号化されたデータよりもネイティブバイナリフォーマットは比較的小さなストレージフットプリントを呈するので、送信装置１０２のストレージ容量要件が低減される。ネイティブバイナリフォーマットを送信することは、バイナリを代替フォーマットに符号化するバージョンと比較して比較的低い帯域幅を反映するので、ネットワーク伝送効率が改善される。更に、データをそのネイティブバイナリフォーマットで送信することにより、人間が読めるフォーマットと比較して優れたセキュリティ特性を示し、送信中に消費する帯域幅が少なくなる。

更に、以下で更に詳述するように、例示のサーバペイロードエンジン１６０は、例示の受信側サーバ装置１０４のアーキテクチャの違いを示す送信ピアからのバイナリフォーマットのデータの受信を容易にし、これにより、バイナリフォーマットのネットワーク転送が従来の人間が読めるフォーマットと比較して固有のセキュリティを維持できるようになる。例示の列挙エンジン１７０は、以下で更に詳述するように、類似のアーキテクチャでは動作しないピア間のＥＮＵＭのデータ複合型マッピングを容易にする（例えば、異なる値を有する同様の名称のような、異なる値のマッピングをＥＮＵＭ要素に用いることができる）。例示の変換エンジン１８０は、以下で更に詳述するように、１以上の変換要求エンティティ１８２及び／又は例示の受信側サーバ装置１０４から発することができる要求（例えば、例示の受信側サーバ装置１０４（受信ピア）に記憶されたコンポジットに関連するデータをレンダリングするための変換要求）を容易にする。

ピア（例えば、例示の送信側クライアント装置１０２と例示の受信側サーバ装置１０４）間で情報を交換する改良された方法を容易にするために、例示のプロセス間環境１００は、例示のネットワーク１０６及び／又は例示の通信バス１８８のうちの少なくとも一方を介して、例示の送信側クライアント装置１０２及び／又は例示の受信側サーバ装置１０４に通信可能に接続された例示のメタデータエンジン１３６を含む。図１Ａの図示の実施例では、メタデータエンジン１３６（主にランタイムに先立って使用される）は、以下で更に詳述する複合インタフェース記述（ＣＩＤ）エンジン１２０、複合レイアウト記述（ＣＬＤ）エンジン１２６及びタスクプロセスコンパイラ１８６を含む。

動作中、例示の送信側クライアント装置１０２は、例示のペイロードストレージ１０８に記憶されるべきペイロードデータを取得及び／又は他の方法で収集する形で実行される１以上のタスクプロセス１８４を取得及び／又は他の方法で受信する。上述のように、例示の送信側クライアント装置１０２は、限定された処理及び／又は記憶リソースを有するが、例えばデータ取得動作を達成するために１以上のタスクプロセス１８４を実行することができてもよい。例示のタスクプロセス１８４は、例示のメタデータエンジン１３６の例示のタスクプロセスコンパイラ１８６により、実行可能なフォーマットにコンパイルされてよい。タスクプロセス１８４によって生成されるペイロードデータは、１以上の関連するコンポジットを含む。本明細書で使用する場合、コンポジットは、データフィールド及び／又はデータユニットを有する例示のペイロードストレージ１０８内のペイロードの一部を反映する。例示のコンポジットは、変数名、変数タイプ及び対応する変数値（例えば、各変数名の値）を有するＣ構造を含む。例示のペイロードストレージ１０８に記憶された１以上のペイロードは、任意の数及び／又はタイプのコンポジットを含むことができる。

従来の送信側クライアント装置１０２は、典型的には、要求されたコンポジットのネイティブバイナリを例示の受信側サーバ装置によって期待されるフォーマットに符号化するために例示のエンコーダ１１０を呼び出す１以上のペイロードを、送信及び／又は別の方法で伝送するように指示される。しかしながら、本明細書に開示される実施例は、（例えば、エンコーダを有するレガシーピアのための）エンコーダがコンポジットを符号化することを防止することにより、送信プロセス中に帯域幅利用を改善し、それにより、ピア（例えば例示の受信側サーバ装置１０４）にそのネイティブバイナリフォーマットでデータを送信することができる。更に、コンポジットはネイティブバイナリフォーマットで送信されるので、インターセプト及び／又はネットワークスニッフィングの際に人間が読めるフォーマットがレンダリングされないようにすることで、コンポジットのセキュリティが強化される。一部の例では、人間が読めるフォーマットと区別されるネイティブのネイティブバイナリフォーマットは、曖昧さによってセキュリティとみなされる。

図１Ｂは、図１Ａの例示のメタデータエンジン１３６に関連する追加の詳細を含む。図１Ｂの図示の実施例では、ＣＩＤエンジン１２０は、ＣＩＤポインタマネジャ１２２及びＣＬＤファイルジェネレータ１２４も含む。更に、例示のＣＬＤエンジン１２６は、例示のＣＬＤポインタマネジャ１２８、例示のＣＬＤファイルジェネレータ１３０及び例示のペイロードアナライザ１３２も含む。例示のタスクプロセスコンパイラ１８６がタスクプロセス１８４をコンパイルすることに応答して、例示のＣＩＤエンジン１２０は、送信されるコンポジットに関連するＣＩＤを生成する。一般的に言えば、以下で更に詳述するように、コンポジットメタデータは、コンポジットの関連するＣＩＤ及びＣＬＤへの簡略な参照を容易にする。以下で更に詳述するように、ＣＩＤは、コンポジットのアーキテクチャ非依存のテキスト又は結合バイナリ及びテキスト記述であり、コンポジットのタイプの定義（例えばＣ構造体）と、コンポジットの名称と、コンポジット要素名並びに対応するタイプ及び配列の次元のリストを含む。更に、例示のＣＬＤエンジン１２６は、送信されるコンポジットに関連付けられたＣＬＤを生成する。以下で更に詳述するように、ＣＬＤは、コンポジットのアーキテクチャ固有のテキスト又は結合テキスト／バイナリ記述であり、コンポジットのサイズ（例えばバイト数）、コンポジット内の要素の数、バイナリ画像内の各要素のバイトオフセット値を含む。

まとめると、例示のＣＩＤ及びＣＬＤは、タスクプロセス１８４にコンパイルされるコンポジットメタデータを表し、或いは、ＪＡＶＡ（登録商標）のような仮想化言語の場合、コンポジットメタデータは仮想マシン（ＶＭ）１５２に記憶され、且つ／又は送信側クライアント装置１０２の例示のペイロードストレージ１０８に記憶される。例示のタスクプロセス１８４がコンパイルされ、その中にメタデータが含まれた後は、例示のメタデータエンジン１３６は実行時にもはや必要ではない。一般的に言えば、例示のＣＩＤエンジン１２０がコンポジットに関連付けられたＣＩＤを生成し、例示のＣＬＤエンジン１２６がコンポジットに関連付けられたＣＬＤを生成した後、送信されるコンポジット（及び関連するＣＩＤとＣＬＤ）への以後の参照は、例示の送信側クライアント装置１０２の処理リソースを節約するために、例示のメタデータリファレンスを介して参照されてよい。生成されたコンポジットメタデータ（ＣＩＤ及びＣＬＤを含む）は、後に例示のメタデータリファレンスマネジャ１３４により実行時に取得され（コンパイルされたタスクプロセス１８４の状況において）、或いは、ＶＭ１５２から取得され、一意のメタデータリファレンス（例えば、コンポジットメタデータを識別するためのテキスト及び／又は数値の命名法）に関連付けられる。このリファレンスを使用する他のデバイスは、それらの間に存在し得るアーキテクチャの相違に関係なく、一貫した結果を生成することができる。例示のメタデータリファレンスマネジャ１３４は、例示のクライアントペイロードエンジン１５０に配置され、以下で更に詳述される。

図２は、図１の例示の送信側クライアント装置１０２の概略図であり、例示のペイロードストレージ１０８に記憶され、且つ／又は例示のクライアントタスクエンジン１０３の１以上のタスクプロセス１８４によって生成されたデータを管理することに関する追加の詳細を含む。図２の図示の実施例では、送信側クライアント装置１０２は、図１に関連して上述したように、１以上の実行可能なタスクプロセス１８４を有するクライアントタスクエンジン１０３と、ペイロードストレージ１０８と、エンコーダ１１０（例えばレガシーエンコーダ）と、ネットワーク１０６及び／又は通信バス１８８に通信可能に接続された送信側クライアントＩ／Ｏインタフェース１１２とを備える。更に、図２の例示の送信側クライアント装置１０２は、例示のＶＭ１５２、例示のクライアントペイロードエンジン１５０、例示のクライアントペイロードモニタ２０４、例示のエンコーダインタフェース２０８、例示のタスク記憶インタフェース２１０及び例示のメタデータリファレンスマネジャ１３４を備える。

動作中、例示のクライアントペイロードモニタ２０４は、例示のペイロードストレージ１０８が、例示の受信側サーバ装置１０４に送信されるべき情報及び／又は他の方法で伝送される情報を含むか否かを決定する。一部の例では、クライアントペイロードモニタ２０４は１以上のトリガに応答して、受信側サーバ装置１０４からの要求（例えばリモートプロシージャコール（ＲＰＣ））、時間ベースのトリガ、センサベースのトリガ、及び／又はペイロードストレージ１０８内の記憶された情報の閾値容量に基づくトリガ等の、ペイロードストレージ１０８内の利用可能な情報を識別する。例示のクライアントペイロードモニタ２０４がペイロード情報を送信する場合、例示のメタデータリファレンスマネジャ１３４は、タスクプロセス１８４でコンパイルされたメタデータを抽出及び／又は他の方法で取得して、アーキテクチャの相違を有する可能性のあるピア間のペイロード伝送の改善を容易にする。例示のメタデータリファレンスマネジャ１３４は、コンパイルされていない（仮想化された）タスクが呼び出された場合（例えば、例示のＶＭ１５２で実行されたタスク）、ＶＭ１５２又はペイロードストレージ１０８から関連するメタデータを抽出及び／又は他の方法で取得する。

図３Ａは、例示のＣＩＤエンジン１２０によって生成される例示のＣＩＤ３００を示す。図３Ａの図示の実施例では、ＣＩＤ３００は、コンポジットタイプ３０２（“ｓｔｒｕｃｔ”）と、コンポジット名３０４（“ｆｏｏｓ１”）と、コンポジット要素名３０６と、対応するコンポジット要素タイプ３０８を含む。上述のように、ＣＩＤは、コンポジットのアーキテクチャ非依存テキスト記述を含む（図３Ａの図示の実施例におけるＣ構造体）。更に、例示のＣＩＤ３００は、例示のペイロードストレージ１０８にファイル（例えばＣＩＤファイル）として記憶されてよく、例示のコンポジットメタデータの一部であってよい。

図３Ｂは、例示のＣＬＤエンジン１２６によって生成される例示のＣＬＤ３５０を示す。図３Ｂの図示の実施例では、ＣＬＤ３５０は、例示のコンポジットのサイズ識別子３５２と、対応するサイズ値３５４と、要素識別子３５６の数及び対応する要素値３５８と、対応するバイナリオフセット値３６２を伴うオフセット識別子３６０とを含む。更に、例示のＣＬＤ３５０は、例示のペイロードストレージ１０８にファイル（例えばＣＬＤファイル）として記憶されてよく、例示のコンポジットメタデータの一部であってよい。まとめると、例示のコンポジットメタデータは、例示のＣＩＤ３００及び例示のＣＬＤ３５０を含む。

例示のＣＩＤ３００を構築及び／又は他の方法で生成するために、例示のＣＩＤポインタマネジャ１２２は、タスクプロセスコンパイラ１８６によってコンパイルされるタスクプロセス１８４と関連付けられたコンポジットを取得する。一般的に言えば、変数名、オフセット値及び／又はサイズ情報等のコンポジット情報は、コンパイラによって利用可能であり、且つ／又は他の方法でコンパイラによってリゾルブされる。このように、例示のタスクプロセスコンパイラ１８６は、対応する実行可能ファイルが実行されるデバイスのアーキテクチャタイプと一致し、且つ／又は他の方法で関連付けられるタイプのものである。以下の表１に、例示のタスクプロセスコンパイラ１８６によって処理される例示のＣＬＤ構造（バイナリ）定義を示す。

更に、以下の表２に対応するテキストＣＩＤを示す。

更に、例示のタスクプロセスコンパイラ１８６は、以下の表３に示すようにバイナリＣＬＤをコンパイルすることができる。

例示のＣＩＤファイルジェネレータ１２４は、コンポジットに関連付けられたアーキテクチャ非依存の情報を取り込むＣＩＤシェルファイルを生成する。例示のＣＩＤポインタマネジャ１２２は、そこに含まれる各要素の情報についてコンポジットを解析するためのポインタを用いて、バイナリコンポジットの先頭を識別する。バイナリコンポジット内の各要素について、例示のＣＩＤファイルジェネレータ１２４は、ＣＩＤ３００への情報をテキストとして符号化する。全ての要素がＣＩＤ３００に符号化されると、例示のＣＬＤポインタマネジャ１２８は、タスクプロセスコンパイラ１８６によってコンパイルされるタスクプロセス１８４に関連付けられたコンポジットを取得し、例示のＣＬＤファイルジェネレータ１３０は、コンポジットに関連付けられたアーキテクチャ固有の情報を取り込むＣＬＤシェルファイルを生成する。例示のペイロードアナライザ１３２は、コンポジットのサイズを識別し、それをＣＬＤシェルファイルに書き込み、コンポジットの要素の数を識別し、その値をＣＬＤシェルファイルに書き込む（例示のＣＬＤ３５０の要素３５２，３５４，３５６，３５８を参照）。例示のＣＬＤポインタマネジャ１２８は、コンポジットの要素の数に基づいて、対応する回数だけコンポジットバイナリを増分及び／又は他の方法で解析して各要素を識別し、対応するバイナリオフセット値を識別し、例示のペイロードアナライザ１３２はその情報をＣＬＤシェルファイルに追加する。一部の例では、例示のペイロードアナライザ１３２は、使用可能であれば、例示のバイナリコンポジットのエンディアン値を決定し、それをＣＬＤシェルファイルに書き込む。コンポジット内の任意のサブコンポジットの場合、そのようなサブコンポジットには、上記と同様の方式で決定される独自の類似したメタデータ定義がある。

例示のメタデータリファレンスマネジャ１３４は、ＣＩＤ３００及びＣＬＤ３５０を、コンポジットメタデータとして以後の使用のために送信側クライアント装置１０２に送信して、ターゲットピア（例えば例示の受信側サーバ装置１０４）へのデータ転送／送信の改善を容易にする。一部の例では、送信側クライアント装置のタスクプロセス１８４が、利用可能なペイロードデータをターゲットピアに送信する準備ができているとき、そのような送信は、例示のメタデータエンジン１３６によるそれ以上の関与なしに進めることができる。しかしながら、１以上の追加及び／又は代替のタスクプロセス１８４がペイロードデータ収集のために例示の送信側クライアント装置に提供される場合、例示のメタデータエンジン１３６は、対応する実行可能ファイルと、対応するコンポジットのコンポジットメタデータ（例えばＣＩＤ、ＣＬＤ）の１以上のインスタンスを生成するために、上記の開示された例を繰り返す。

上述のように、１以上のタスクプロセス１８４は、コンパイルされた（例えばネイティブ）言語（例えばＣ、Ｃ＋＋）ではなく、仮想化言語（例えばＪＡＶＡ（登録商標）、Ｃ＃）に関連付けられる。そのような状況では、例示のＣＩＤ及びＣＬＤは、例示のＶＭ１５２からの協働による反映によって生成される。例えば、メタデータリファレンスマネジャ１３４（送信側クライアント装置１０２の例示のペイロードエンジン１５０を参照）は、送信側クライアント装置１０２のＶＭ１５２に問い合わせて、仮想化されたタスクプロセス１８４に関連付けられたコンポジットに利用可能な１以上の変数タイプ及び／又は変数名を決定する。更に、仮想マシンベースの言語（例えばＪＡＶＡ（登録商標）、Ｃ＃）はオフセット情報を含まないので、要素はパディングバイトの有無に関わらず連続してパックされる。一部の例では、仮想化されたタスクは、特に１以上のパディング技術が採用される場合、ＣＬＤを必要としない。更に、１以上の異なる位置にあるＶＭ（例えば、送信側クライアント装置１０２のＶＭ１５２、受信側サーバ装置１０４のＶＭ１５２）は、２以上のピア間のタスクプロセスの一貫性を保証するために、例示のメタデータエンジン１３６によって同期及び／又は別の方法で登録されてよい。

トリガ（例えば、ペイロードデータの要求）に応答して、図２の例示のタスク記憶インタフェース２１０は、コンポジットメタデータ（例示のＣＩＤ３００及び例示のＣＬＤ３５０を含み、特定のメタデータリファレンスに関連付けられている）が、以前の機会に例示の受信側サーバ装置１０４に送信されたか否かを決定する。そうでない場合、例示のクライアントペイロードエンジン１５０は、（ａ）ネイティブバイナリ（例えば、対象バイナリコンポジットを含むペイロードの一部）と、（ｂ）コンポジットメタデータと、（ｃ）バイナリコンポジット及び／又はそれに関連するコンポジットメタデータへの以後の参照を行うときに使用されるメタデータリファレンスとの両方を送信する。一部の例では、クライアントペイロードエンジン１５０は、任意の受信ピアが既にコンポジットメタデータを受信及び／又は他の方法で有しているという仮定の下で、（ａ）ネイティブバイナリ及び（ｂ）メタデータリファレンスを送信する。そうでない場合、例えばコンポジットメタデータが以前に送信されていない場合や、受信ピアが以前に受信したコンポジットメタデータをもはや有していない場合、例示の受信Ｉ／Ｏインタフェース１１４は要求コマンドを生成する。要求コマンドが例示のクライアントペイロードエンジン１５０によって受信されると、コンポジットメタデータは、例示の受信ピア（例えば受信側サーバ装置１０４）に送信される。

以下で更に詳述するように、ネイティブバイナリと共にコンポジットメタデータを送信することにより、例示の受信側サーバ装置１０４は受信時にネイティブバイナリを復号することが可能となり、符号化努力を回避することにより例示の送信側クライアント装置１０２の計算効率を改善することができる。更に、例示の送信側クライアント装置１０２は、符号化リソース／労力を費やすことなくネイティブバイナリを送信することができるので、例示の送信側クライアント装置１０２は、オンボード電力（例えばバッテリ）リソースを節約し、より低い送信帯域幅を消費する（送信効率を改善する）。また、ネイティブバイナリフォーマットは、人間が読めるフォーマットよりも比較的小さなストレージフットプリントを含むので、例示の送信側クライアント装置１０２は、オンボードストレージ（例えば、オンボードメモリ、ＲＡＭ、ＦＬＡＳＨ）リソースを節約する。更に、例示の送信側クライアント装置１０２が、生成されたコンポジットバイナリに関連するスキーマを変更した場合、送信ピア／受信ピア間で送信の互換性は中断されず、代わりに、更新されたコンポジットメタデータでスキーマの更新（例えばアーキテクチャの変更、コンポジット要素に関連付けられたバイナリオフセット値の変更）を管理することができる。

一部の例では、送信側クライアント装置１０２は、コンポジットに関連付けられたコンポジットメタデータを、例示の受信側サーバ装置１０４に以前に送信している。したがって、例示の受信側サーバ装置１０４は、（ａ）コンポジットメタデータ及び（ｂ）メタデータリファレンスの記憶されたコピーを既に有する。よって、例示のクライアントペイロードエンジン１５０は、（ａ）コンポジットメタデータ、（ｂ）メタデータリファレンス及び（ｃ）コンポジットバイナリの３つ全てを送信するのではなく、上述のようにメタデータリファレンス及びコンポジットバイナリのみを送信する。例示の受信側サーバ装置は、以前に記憶されたコンポジットメタデータのコピーを参照して、コンポジットバイナリを変換することを可能にする（例えば、テキスト、ＸＭＬ、受信ピアアーキテクチャに関連する代替バイナリ等の代替フォーマットに変換される）。

図４は、図１Ａの例示の受信側サーバ装置１０４の概略図であり、例示の送信側クライアント装置１０２によって受信されたデータを処理することに関する追加の詳細を含む。一部の例では、データを処理することは、受信ピアとは異なるアーキテクチャフォーマットを有する送信ピアによって取得されたコンポジットバイナリ等のデータをリゾルブすることを含む。図４の図示の実施例では、受信側サーバ装置１０４は、図１Ａに関連して上述したように、例示のネットワーク１０６に通信可能に接続された例示の受信側サーバＩ／Ｏインタフェース１１４と、例示のデコーダ１１８と、例示のサーバデータストア１１６と、例示のＶＭ１５２とを備える。更に、図４の例示の受信側サーバ装置１０４は、例示のサーバペイロードエンジン１６０、例示のサーバペイロードモニタ４０４、例示のサーバメタデータマネジャ４０６、例示のサーバ記憶インタフェース４０８、例示のデコーダマネジャ４１０、例示の列挙エンジン１７０、例示の解決テーブルマネジャ４１４、例示の例外ジェネレータ４１６、例示の変換エンジン１８０、例示の要求マネジャ４２０、例示のフォーマットリゾルバ４２２、例示の変換システム４２４、例示の例外ジェネレータ４１６、及び、ペイロードデータを１以上の要求エンティティの所望のフォーマット（例えば、例示の変換要求エンティティ１８２からの１以上の要求）に部分的に符号化する例示のフォーマットエンコーダ４２６を備える。

動作中、例示のサーバペイロードモニタ４０４は、ペイロードが例示の受信側サーバＩ／Ｏインタフェース１１４を介して受信されたか否かを判定する。上述のように、例示の送信側クライアント装置１０２は、例示の受信側サーバ装置１０４によって開始されるトリガ等のトリガに応答して、ペイロードデータを送信してよい。ペイロード情報が受信された場合、例示のサーバメタデータマネジャ４０６は、受信されたペイロードデータが、マッチするコンポジットメタデータリファレンスも含むか否かを判定する。上述のように、例示の送信側クライアント装置１０２がコンポジットメタデータ（例えば、例示のＣＩＤ３００及び例示のＣＬＤ３５０）を提供するとき、コンポジットタデータリファレンスも、以後の参照のためのコンポジットメタデータに関連付けられ、マッチし、且つ／又はその他の方法でタグ付けされる。この例について、受信されたペイロード（例えば、受信されたバイナリコンポジット、受信されたメタデータリファレンス、受信されたメタデータコンポジット情報）が初めて発生すると仮定すると、例示のサーバ記憶インタフェース４０８は、受信されたメタデータコンポジット情報を抽出して、対応するＣＩＤ及びＣＬＤを識別する。抽出されたＣＩＤ（例えば、図３Ａの例示のＣＩＤ３５０）と抽出されたＣＬＤ（例えば、図３Ｂの例示のＣＬＤ３５０）は、例示のサーバデータストア１１６に記憶され、抽出されたメタデータリファレンス命名法（例えば“ＳＦ１”）と関連付けられる。このように、同じスキーマ（例えば、同じＣＩＤと同じＣＬＤを有するコンポジットメタデータ）を有する別のバイナリコンポジットが送信された場合、例示の受信側サーバ装置１０４は、それをサーバデータストア１１６から取得してよい。よって、要求されたコンポジット内に記憶されたデータを取得及び／又は別の方法でレンダリングするための１以上の後続の要求の間に、受信側サーバ装置１０４の処理リソースが節約される。実際には、例示の送信側クライアント装置１０２（例えば送信ピア）からのメタデータリファレンスが、例示の受信側サーバ装置１０４（例えば受信ピア）からのメタデータリファレンスとマッチする場合、ＣＩＤ及びＣＬＤ情報の再構築及び／又はその他の取込みへの取組みはバイパスされる。

しかしながら、例示の送信側クライアント装置１０２と例示の受信側サーバ装置１０４は、それぞれ固有及び／又はその他の異なるアーキテクチャを有することができるので、送信側クライアント装置１０２からの受信ペイロードは、受信側サーバ装置１０４と互換性がない場合がある。このように、例示のサーバメタデータマネジャ４０６は、任意のアーキテクチャの相違に対応し、且つ／又は別の方法で解決するために、それ自身のサーバ側ＣＩＤファイルとサーバ側ＣＬＤファイルを生成する。一部の例では、サーバメタデータマネジャ４０６は、図１Ｂに示すような、サーバ側ＣＩＤファイル及びサーバ側ＣＬＤファイルを生成するための１以上の要素を含む。例示のタスクプロセスコンパイラは、例示の受信側サーバ装置１０４の特定のアーキテクチャタイプのタスクプロセスをコンパイルすることができる。更に別の例では、サーバメタデータマネジャ４０６は、例示の受信側サーバ装置１０４に関連付けられたアーキテクチャと互換性のあるメタデータエンジンに通信可能に接続される。

図５の図示の実施例では、例示のＣＩＤエンジン１２０によって生成された例示のＣＩＤ３００は、例示の変換エンジン１８０によって変換され、例示のサーバデータストア１１６に記憶されている。更に、例示のＣＬＤエンジン１２６によって生成された例示のＣＬＤ３５０は、例示の受信側サーバ装置１０４によって変換され、例示のサーバデータストア１１６に記憶されている。まとめると、例示のＣＩＤ３００及び例示のＣＬＤ３５０は、コンポジットメタデータ５７５（点線を参照）を生成する。図３Ａに関連して上述したように、例示のＣＩＤ３００は、コンポジットタイプ３０２（“ｓｔｒｕｃｔ”）、コンポジット名３０４（“ｆｏｏｓ１”）、コンポジット要素名３０６及び対応するコンポジット要素タイプ３０８を含む。図５の図示の実施例は“ｓｔｒｕｃｔ”のコンポジットタイプを含むが、本明細書に開示される実施例はこれに限定されない。一部の例では、コンポジットは、以下で更に詳述するように、１以上の要素がリゾルブされるタイプ、列挙（ｅｎｕｍ）であってよい。

サーバ側ＣＩＤ５００は、より多い要素又はより少ない要素を有するそれ自身の固有の定義を有してよく、ピア間でマッチするものだけが変換を可能にする。ピア間の対応するマッチを含まないこれらの１以上の要素について、それらは無視されてよく、且つ／又は、例示の例外ジェネレータ４１６によって例外エラーが生成され、その間に部分的な復号能力を伝えることができる。比較及び／又は変換が完了すると、例示のサーバ側ＣＩＤ５００は、コンポジットタイプ５０２、コンポジット名５０４、コンポジット要素名５０６及び対応するコンポジット要素タイプ５０８も含むことになる。更に、例示のサーバ側ＣＩＤ５００は、例示の送信側クライアント装置によって最初に確立されたのと同じメタデータリファレンス命名法に関連付けられることになる。図５の図示の実施例では、ＣＩＤ３００は、メタデータリファレンス“ＳＦ１”３１０に関連付けられ、これもサーバ側ＣＩＤ５００に帰属される（要素５１０を参照）。

図３Ｂに関連して上述したように、例示のＣＬＤ３５０は、コンポジットのサイズ識別子３５２と対応するサイズ値３５４、要素識別子の数３５６と対応する要素値３５８、対応するバイナリオフセット値３６２を伴うオフセット識別子３６０を含む。例示のサーバメタデータマネジャ４０６はまた、サーバ側ＣＬＤ５５０を生成し、それに、変換エンジン１８０によって受信されたＣＬＤ３５０から翻訳されたデータの１以上の部分を取り込む。具体的には、初期の比較／変換が完了すると、例示のＣＬＤ５５０は、サイズ識別子５５２、要素識別子の数５５６及びオフセット識別子５６０を含むことにより、受信されたＣＬＤ３５０とのパリティの程度を反映する。例示の受信側サーバ装置１０４のアーキテクチャが送信側クライアント装置１０２のアーキテクチャと異なる場合、例示の変換エンジン１８０は、受信側サーバ装置１０４のそれぞれのアーキテクチャタイプに基づいて、例示のサーバ側ＣＬＤ５５０に書き込まれるサイズ、要素数及び／又はバイナリオフセットの適切な値を決定する。

一部の例では、マッピングテーブルは送信側メタデータと受信側メタデータをリゾルブする。図５の図示の実施例では、変換エンジン１８０は、受信側サーバ装置１０４のアーキテクチャに基づいて、バイナリコンポジットのサイズが“７４”であると判定する（送信側クライアント装置１０２からのサイズ“８０”ではなく）。同様に、例示の変換エンジン１８０は、受信側サーバ装置１０４のアーキテクチャの要件に適合するように調整されるべきサーバ側ＣＬＤ５５０のバイナリオフセット値５６２の特定のものを識別している（例えば、要素Ａ．ｓｂのオフセット値は、送信側クライアント装置１０２では“４”であるが、受信側サーバ装置１０４では“２”である）。

バイナリコンポジットが将来例示の受信側サーバ装置１０４によって受信及び／又は他の方法で取得される場合（例えば、バイナリコンポジットが異なるペイロードデータを含むが、同じスキーマ／コンポジットフォーマットを示す場合）、受信側サーバ装置１０４は、オフセット位置を訂正するために、マッチするメタデータ及びマップを識別することができる。一部の例では、サーバメタデータマネジャ４０６は、図５の図示の実施例に示すような、比較のためのメタデータ解決テーブルとして機能する並列比較テーブルを生成する。例示の変換エンジン１８０は、取得されたＣＩＤ３００及び対応するメタデータリファレンス（例えば“ＳＦ１”３１０）を取得し、マッチするメタデータリファレンス（例えば“ＳＦ１”５１０）を識別／比較するために、例示のサーバデータストア１１６に問い合わせる。発見された場合、例示の変換エンジン１８０は、サーバ側ＣＩＤ５００及び／又はサーバ側ＣＬＤ５５０を再取込みするための任意の動作をバイパスしてよく、代わりに、以前に記憶されたサーバ側ＣＩＤ５００を取得し、それらを比較してそれらの間のパリティを確認する。

取得されたＣＩＤ３００と記憶されたサーバ側ＣＩＤ５００との間に１以上のディスパリティが識別されると、データ破損及び／又はデータの不一致を識別するために、変換エンジン１８０の例示の例外ジェネレータ４１６により１以上の例外が呼び出し及び／又は別の方法で生成される。更に、例示の変換エンジン１８０は、取得されたＣＬＤ３５０及び対応するメタデータリファレンス（例えば“ＳＦ１”３１０）を取得し、一致するメタデータリファレンス（例えば“ＳＦ１”５１０）を識別するために例示のサーバデータストア１１６に問い合わせる。発見された場合、例示の変換エンジン１８０は、以前に記憶されたサーバ側ＣＬＤ５５０を取得し、それを取得されたＣＬＤ３５０と比較して、オフセット値の相違を識別する。取得されたＣＬＤ３５０内のオフセット値を知ることにより、例示の受信側サーバ装置は、特定の要素に関連付けられたコンポジットバイナリ内に記憶されたデータを抽出することができ、それを、受信側サーバ装置１０４の特定のハードウェアアーキテクチャに準拠するバイナリフォーマットで例示のサーバデータストア１１６に記憶する。

更に、例示の受信側サーバ装置１０４が、変換要求エンティティ１８２（例えば、ＸＭＬでレンダリングされたバイナリコンポジット情報を必要とする第三者リクエスタ（例えば、変換要求エンティティ１８２のうちの１つ））の取得されたバイナリコンポジットの代替フォーマットを生成する変換要求を実行する場合、例示のサーバ側ＣＬＤ５５０は、例示の変換システム４２４が、（例えば、送信側クライアント装置１０２に固有ではなく受信側サーバ装置１０４に固有のバイナリ形式の）バイナリコンポジットを取得し、１以上の対象要素についてバイナリ内の正確な位置を識別し、適切なフォーマットエンコーダ４２６を起動してペイロードデータを更なる送信／配信のための所望の代替フォーマットにレンダリングする。図１の図示の実施例は、受信側サーバ装置１０４の外部の受信側サーバ装置１８２の外部の変換要求エンティティ１８２を示すが、一部の例は、受信側サーバ装置１０４内の１以上の変換要求エンティティ１８２を含んでよい。いずれの場合においても、変換要求エンティティ８２が独自のＣＩＤ／ＣＬＤ（メタデータ）を有する場合、上述のように、それらは送信側クライアント装置１０２に関連付けられた任意のメタデータと比較され、アーキテクチャ上の相違をリゾルブする。

要求マネジャ４２０が変換要求（例えば、特定のフォーマットのコンポジットデータを取得するための例示の受信側サーバ装置１０４に対する第三者の要求）を識別すると、例示のフォーマットリゾルバ４２２は、所望のフォーマットのタイプを識別する。例示のフォーマットリゾルバ４２２は、例示のサーバデータストア１１６に問い合わせて、要求されたコンポジットの所望のフォーマットが既に利用可能であるか否かを判定する。利用可能であれば、例示の変換エンジン１８０は、復号化されたコンポジットをストレージから取得し、例示の受信側サーバＩ／Ｏインタフェース１１４を介してそれをリクエスタに転送する。一部の例では、要求されたコンポジットは、バイナリコンポジットを第三者の変換要求によって要求された所望のフォーマットに復号するための１以上の以前の取組みに応答して、例示のサーバデータストア１１６に保存されているので、既に利用可能である。

一方、要求されたコンポジットの所望のフォーマットが例示のサーバデータストア１１６で利用可能でない（例えば、これが対象コンポジットバイナリに対して変換要求が最初に呼び出されたときである）場合、例示のフォーマットリゾルバ４２２は、サーバ側ＣＩＤ５００から第１のコンポジット要素を識別し、例示のサーバデータストア１１６に記憶されたコンポジットバイナリの要素に関連付けられたオフセット値を含むサーバ側ＣＬＤ５５０から、対応するコンポジット要素を識別する。コンポジットバイナリの要素のそれぞれのオフセット値に基づいて、例示の変換システム２４は、コンポジットバイナリに位置するデータを取得し、対応するフォーマットエンコーダ４２６を呼び出して、データをリクエスタに関連付けられたフォーマットに変換する（例えば、テキストへの変換、ＸＭＬへの変換、ＪＳＯＮへの変換）。フォーマットエンコーダ４２６は、任意の数のエンコーダタイプを含むことができ、それぞれが特定のフォーマットに符号化することができる。一部の例では、変換システム４２４は、フォーマットエンコーダ４２６を呼び出して、ネイティブバイナリからテキスト、ネイティブバイナリからＸＭＬ、ネイティブバイナリからＪＳＯＮ等に変換する。例示の変換エンジン１８０は、例示のサーバデータストア１１６に記憶されたターゲットコンポジットバイナリの各要素を変換するので、集約されたコンポジット要素を所望のフォーマットを有する出力ファイルに（例えば、例示のサーバデータストアに）記憶する。次に、例示の変換エンジン１８０は、変換されたファイルを、例示の受信側サーバＩ／Ｏインタフェース１１４を介してリクエスタに送信する。

上述のように、いくつかの例ではコンポジットはＥＮＵＭ型であり、受信ピアからのコンポジットＥＮＵＭと比較して送信ピアからのコンポジットＥＮＵＭの１以上の命名ディスパリティを解決するために、要素間の更なる解決が必要となる。図６は、列挙（ＥＮＵＭ）コンポジットタイプに関連付けられた例示のＣＩＤ及びＣＬＤテーブルを示す。一部の例では、サーバペイロードモニタ４０４は、ペイロードに記憶された特定のペイロードタイプ及び／又は特定のタイプのコンポジットを検出する。例えば、例示のサーバペイロードモニタ４０４が、受信されたコンポジットバイナリがＥＮＵＭタイプのものであることを検出した場合、例示の列挙エンジン１７０は、受信したコンポジットバイナリ（例示の送信側クライアント装置１０２からの）と、例示の受信側サーバ装置１０４で実装されたＥＮＵＭフォーマットとの間のＥＮＵＭデータの変換を容易にする。一般的に言えば、例示の送信側クライアント装置１０２（例えば、送信ピア）からのＥＮＵＭに関連付けられたデータは、例示の受信側サーバ装置１０４（例えば受信ピア）からのＥＮＵＭと同じデータを参照しているかもしれないが、各装置は、リファレンス命名法のいくつかの相違を有するＥＮＵＭを実施してよい。列挙型構造体は、コンパイラが名称／命名法に基づいて実際の値をリゾルブする対応する名称を用いて抽象化された、名前付き値のリストを表す。しかしながら、一緒にコンパイルされず、且つ／又は異なるアーキテクチャを有するピア（例えば、例示の送信側クライアント装置１０２と例示の受信側サーバ装置１０４）のネットワークにおいて通信する場合、ＥＮＵＭが最初に非バイナリ（例えばテキスト）フォーマットに変換されない限り、解決は不可能である。上述のように、バイナリフォーマットから１以上の代替フォーマットへの変換は、符号化処理中の膨大なストレージフットプリントと計算上の歪みをもたらす。よって、例示の送信側クライアント装置１０２と例示の受信側サーバ装置１０４の間の調整を可能にするために、例示の列挙エンジンは、１以上のディスパリティを解決するときに、符号化オーバヘッドを回避し、且つ／又はバイナリ変換作業を防止しながら、それらの間の変換を容易にする。

図６の図示の実施例では、ネットワーク６００上のピアからの（例えば、送信側クライアント装置１０２からの）ＣＩＤ６００は、コンポジットタイプ識別子６０２によって識別されるような列挙（ＥＮＵＭ）タイプのコンポジット構造を含む。例示のＣＩＤ６００はまた、名称“ｃｏｌｏｒｓ”を有するＥＮＵＭタグ６０４を含む。一部の例では、ＥＮＵＭタグ６０４はＥＮＵＭ名と呼ばれる。例示のＣＩＤ６００はまた要素名６０６を含み、要素の一部は対応するターゲット値（例えば、ｙｅｌｌｏｗ＝９００、ｂｌａｃｋ＝１０００）を含む。初期の明示的なターゲット値（ｒｅｄ、ｇｒｅｅｎ、ｂｌｕｅ等）を含まない要素については、暗黙の値が順次割り当てられる。例えば、ｒｅｄには０が割り当てられ、ｇｒｅｅｎには１が割り当てられる。一部の例では、ＥＮＵＭ要素の選択及び／又は識別は、要素名（例えば“ｙｅｌｌｏｗ”）、要素ターゲット値（例えば“９００”）、又はＥＮＵＭ要素のリスト内の要素バイナリ位置（例えば、ゼロベースのバイナリリストの第４の要素を参照する“３”）を参照して生じてよい。図６はまた、ピアからの（例えば送信側クライアント装置１０２からの）ＣＬＤ６１０を含み、ＥＮＵＭコンポジットのサイズに関する情報を含む。図６の図示の実施例では、ＥＮＵＭコンポジットのサイズは“２”であり、これは１６ビットを示すバイト値を反映する。以下で更に詳述するように、例示のＣＩＤ６００及び例示のＣＬＤ６１０は、マッピングされるＥＮＵＭコンポジットタイプのインスタンスに応答して、例示の変換エンジン１８０又はＥＮＵＭエンジン１７０に送信される。

図６はまた、ネットワーク６００上の別個のピアからの（例えば受信側サーバ装置１０４からの）ＣＩＤ６１２を含む。図６の図示の実施例では、ＣＩＤ６１２は、“ｃｏｌｏｒｓ”と命名されたＥＮＵＭタグ６１６を有するＥＮＵＭタイプ６１４を含み、それにより、例示のネットワーク６００上にマッピングされる他のＥＮＵＭコンポジットとの一致を示す。例示のＣＩＤ６１２は要素名６１８を含み、要素の一部は対応するターゲット値（例えば、ｇｒｅｅｎ＝５０、ｙｅｌｌｏｗ＝７００）を含む。上述のように、明示的な値をもたない要素には、暗黙の値が順次割り当てられる（例えば、ｒｅｄは０が割り当てられ、ｇｒｅｙは１００１が割り当てられる）。図６はまた、別個のピアからの（例えば受信側サーバ装置１０４からの）ＣＬＤ６２０を含み、ＥＮＵＭコンポジットのサイズに関する情報を含む。図６の図示の実施例では、ＥＮＵＭコンポジットのサイズは“４”であり、これは３２ビットを示すバイト値を反映する。例示のＣＩＤ６１２及び例示のＣＬＤ６２０は、マッピングされるＥＮＵＭコンポジットタイプのインスタンスに応答して、例示のデコーダ６１８に送信される
上述のように、ＥＮＵＭコンポジットタイプ間のディスパリティをマッピング及び／又は他の方法でリゾルブする従来のアプローチは、ＥＮＵＭを標準フォーマットに符号化及び／又は他の方法で変換するためにピア間の調整を必要とした。これは、元のバイナリフォーマットを比較的大きなメモリストレージフットプリントに変換し、対応するより大きな帯域幅消費を引き起こし、リソースの符号化を必要とし、データ転送中のデータセキュリティを低下させる（例えば、符号化された標準タイプが人間が読めるテキストになる）。本明細書に開示される実施例は、メモリストレージフットプリントを節約し、帯域幅消費を節約し、リソースの符号化を削減及び／又は排除し、データ転送中のデータセキュリティを改善する。

例示の受信側サーバ装置１０４の例示の解決テーブルマネジャ１１４は、列挙解決テーブル（ＥＲＴ）が以前に生成されたか否かを決定する。生成されていなければ、一致するコンポジットタグを共有するＣＩＤ及びＣＬＤ情報に基づいて、ＥＲＴ（例えば、最初は空のシェルファイル）が生成される。例示の解決テーブルマネジャは、ＥＲＴをファイルとして例示のサーバデータストア１１６に保存してよい。図７は、例示のネットワーク６００上の１対のピア（例えば、例示の送信側クライアント装置１０２と例示の受信側サーバ装置１０４）からのＣＩＤ及びＣＬＤ情報が取り込まれた、例示のＥＲＴ７００を示す。図７の図示の実施例では、ＥＲＴ７００は、第１のピア列７０２（例えば“Ｐｅｅｒ１”）及び第２のピア列７０４（例えば“Ｐｅｅｒ２”）を含む。更に、例示の第１のピア列７０２及び例示の第２のピア列７０４のそれぞれについて、ＥＲＴ７００は、例示のコンポジット識別子７０６、例示のコンポジット名識別子７０８、例示のコンポジットサイズ識別子７１０及び例示のコンポジット要素識別子７１２を含む。例示の第１のピア列７０２及び例示の第２のピア列７０４のそれぞれについて、例示のコンポジット要素識別子７１２は、要素インデックス列７１４、要素名列７１６及び要素値列７１８（例えばターゲット値）を含む。更に、例示のコンポジット要素識別子７１２は、第１のピア及び第２のピアの特定の要素のコンポジット位置が一致するか否かを識別するための要素パリティ列７２０と、例示の第１のピア７０２と例示の第２のピア７０４との間の要素を一致させるために、１以上の代替識別子（要素インデックス位置を除く）を使用できるか否かを識別するセカンダリ解決列７２２とを含む。換言すると、例示のセカンダリ解決列７２２は、例示の第１のピア７０２と例示の第２のピア７０４との間のそれぞれのＥＮＵＭ要素間のマッピングリンクを反映する。

例示の第１のピア７０２と例示の第２のピア７０４のＥＮＵＭ間でどの要素が一致するかを判定するために、ＥＮＵＭエンジン１７０の例示の例外ジェネレータ４１６は、要素位置の不一致が生じるか否かを判定する。具体的には、例示の例外ジェネレータ４１６は、両方のピアの第１の要素位置（例えば、要素インデックス位置列７１４のゼロ“０”ビット）を識別し、対応する要素名（例えば、要素名列７１６の要素名“ｒｅｄ”）が一致するか否かを決定する。そうである場合、評価された要素インデックス位置（例えば、インデックス位置“０”）に関連付けられる要素は一致とみなされ、例示の解決テーブルマネジャ４１４がＴＲＵＥの値を例示の要素パリティ列７２０に設定する。

一方、例示の例外ジェネレータ４１６がピア間の要素位置の不一致を識別した場合（図７の行７２４参照）、例示の例外ジェネレータ１６は、セカンダリ解決パラメータが異なる要素との一致候補を示すか否かを決定する（例えば、代替の要素インデックス値を有する別個の要素）。図７の図示の実施例では、Ｐｅｅｒ１ ７０２のインデックス位置“２”（行７２４）は、要素名７１６“ｂｌｕｅ”に関連付けられているが、Ｐｅｅｒ２ ７０４のインデックス位置“２”は、要素名７１６“ｙｅｌｌｏｗ”に関連付けられており、不一致を示す。このように、例示の解決テーブルマネジャ４１４は、インデックス位置“２”（行７２４）に関連付けられる例示の要素パリティ列７２０に値ＦＡＬＳＥを設定する。例示の第１のピア７０２と例示の第２のピア７０４との間でインデックス位置“２”の不一致が識別されたにも関わらず、例示の例外ジェネレータ４１６はセカンダリ解決パラメータを使用して一致する。具体的には、例示の例外ジェネレータ４１６は、例示の第１のピア７０２からの要素名“ｂｌｕｅ”のセカンダリ解決パラメータを使用し、一致する要素名“ｂｌｕｅ”について例示の第２のピア７０４の全ての要素名を検索する。図７の図示の実施例では、例示の第２のピア７０４において一致が識別されず、例示の例外ジェネレータ４１６は、要素名“ｂｌｕｅ”に関連付けられた任意の要素について例外を呼び出す。図示の実施例ではセカンダリ解決アプローチとして要素名を使用しているが、本明細書に開示の実施例はそれに限定されない。一部の例では、ＥＮＵＭとのピア間の任意の相違を識別するための主な手法は、要素名のみを採用してよい。

要素名“ｂｌｕｅ”に関連付けられた例示の第１のピア７０２と例示の第２のピア７０４との間の不一致に関係なく、その間の１以上の他の要素は、例示の第１のピア７０２及び例示の第２のピア７０４のＥＮＵＭ間の相違を解決するために用いることのできる一致を、更に示すことができる。例えば、第１のピア７０２のインデックス位置“３”の例示の要素名“ｙｅｌｌｏｗ”は、第２のピア７０４のインデックス位置“３”の要素名“ｂｌａｃｋ”と一致しないので、例示の例外ジェネレータ４１６はまた、インデックス位置“３”（図７の行７２６参照）のピア間のインデックス位置の不一致を識別する。しかしながら、例示の例外ジェネレータ４１６が要素名“ｙｅｌｌｏｗ”の代替のインデックス位置を検索すると、第２のピア７０４のインデックス位置“２”において一致が識別される。このように、例示の解決テーブルマネジャ４１４は、ビット位置「３」のセカンダリ解決列７２２に、第１のピア７０２が第２のピア７０４のインデックス位置“２”と一致するというマッピングインジケータと共にビット位置“３”を取り込む
例示のＥＲＴ７００に解決されたマッピング情報が取り込まれたとき、例示の列挙エンジン１７０は、ＥＮＵＭ“ｃｏｌｏｒｓ”をマッピングするための１以上の以後の要求が要求された場合に、ＥＲＴを例示のサーバデータストア１１６に記憶する。例えば、例示の列挙エンジン１７０が、例示の第１のピア７０２からＥＮＵＭ名“ｃｏｌｏｒｓ”に関連付けられるバイナリ入力クエリ値“１”を取得及び／又は別の方法で受け取る場合、例示の解決テーブルマネジャ４１４４１４を呼び出して、ＥＲＴ７００を参照することにより、例示の第２のピア７０４から“ｃｏｌｏｒｓ”という名称の適切なＥＮＵＭの対応するターゲット値を取得する。例示の入力クエリ値“１”は、第１のピア７０２からの要素名“ｇｒｅｅｎ”と関連付けられているので、第２のピア７０４の“５０”という対応する値が解決される（図７の行７２８参照）。上記で開示された実施例は、ペイロードデータを受信側サーバ装置１０４に送信するとき、送信側クライアント装置１０２が計算集約型変換から保護される例を示しているが、そのような例はこれに限定される。一部の例では、受信側サーバ装置１０４は、同様の方式で送信側クライアント装置１０２にペイロードデータを送信してよい。

図１のクライアントペイロードエンジン１５０、サーバペイロードエンジン１６０、列挙エンジン１７０及び変換エンジン１８０を実現する例示の方式を図２，３Ａ，３Ｂ，４〜７に示したが、図１，２，３Ａ，３Ｂ，４〜７に示される要素、プロセス及び／又はデバイスのうちの１以上は、任意の他の方式で組合わせ、分割、再配置、省略、除去及び／又は実施することができる。更に、図１，１Ｂ，２，４の例示の送信側クライアント装置１０２、例示の受信側サーバ装置１０４、例示のクライアントタスクエンジン１０３、例示のペイロードストレージ１０８、例示のエンコーダ１１０、例示の送信側クライアントＩ／Ｏインタフェース１１２、例示の受信側サーバＩ／Ｏインタフェース１１４、例示のサーバデータストア１１６、例示のデコーダ１１８、例示のメタデータエンジン１３６、例示のタスクプロセスコンパイラ１８６、例示のＶＭ１５２、例示のクライアントペイロードモニタ２０４、例示のメタデータリファレンスマネジャ１３４、例示のエンコーダインタフェース２０８、例示のタスク記憶インタフェース２１０、例示のＣＩＤエンジン１２０、例示のＣＩＤポインタマネジャ１２２、例示のＣＩＤファイルジェネレータ１２４、例示のＣＬＤエンジン１２６、例示のＣＬＤポインタマネジャ１２８、例示のペイロードアナライザ１３２、例示のＣＬＤファイルジェネレータ１３０、例示のサーバペイロードモニタ４０４、例示のサーバメタデータマネジャ４０６、例示のサーバ記憶インタフェース４０８、例示のデコーダマネジャ４１０、例示の解決テーブルマネジャ４１４、例示の例外ジェネレータ４１６、例示の要求マネジャ４２０、例示のフォーマットリゾルバ４２２、例示の変換システム４２４、例示のフォーマットエンコーダ４２６、及び／又は、より一般に、例示のクライアントペイロードエンジン１５０、例示のサーバペイロードエンジン１６０、例示の列挙エンジン１７０及び例示の変換エンジン１８０は、ハードウェア、ソフトウェア、ファームウェア、並びに／又は、ハードウェア、ソフトウェア及び／若しくはファームウェアの任意の組合わせによって実現されてよい。よって、例えば、図１，１Ｂ，２，４の例示の送信側クライアント装置１０２、例示の受信側サーバ装置１０４、例示のクライアントタスクエンジン１０３、例示のペイロードストレージ１０８、例示のエンコーダ１１０、例示の送信側クライアントＩ／Ｏインタフェース１１２、例示の受信側サーバＩ／Ｏインタフェース１１４、例示のサーバデータストア１１６、例示のデコーダ１１８、例示のメタデータエンジン１３６、例示のタスクプロセスコンパイラ１８６、例示のＶＭ１５２、例示のクライアントペイロードモニタ２０４、例示のメタデータリファレンスマネジャ１３４、例示のエンコーダインタフェース２０８、例示のタスク記憶インタフェース２１０、例示のＣＩＤエンジン１２０、例示のＣＩＤポインタマネジャ１２２、例示のＣＩＤファイルジェネレータ１２４、例示のＣＬＤエンジン１２６、例示のＣＬＤポインタマネジャ１２８、例示のペイロードアナライザ１３２、例示のＣＬＤファイルジェネレータ１３０、例示のサーバペイロードモニタ４０４、例示のサーバメタデータマネジャ４０６、例示のサーバ記憶インタフェース４０８、例示のデコーダマネジャ４１０、例示の解決テーブルマネジャ４１４、例示の例外ジェネレータ４１６、例示の要求マネジャ４２０、例示のフォーマットリゾルバ４２２、例示の変換システム４２４、例示のフォーマットエンコーダ４２６、及び／又は、より一般に、例示のクライアントペイロードエンジン１５０、例示のサーバペイロードエンジン１６０、例示の列挙エンジン１７０及び例示の変換エンジン１８０のいずれかは、１以上のアナログ若しくはデジタル回路、論理回路、プログラマブルプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）及び／又はフィールドプログラマブルロジックデバイス（ＦＰＬＤ）によって実現することができる。純粋なソフトウェア及び／又はファームウェア実装をカバーする本願の装置又はシステムの請求項のいずれかを読むと、図１，１Ｂ，２，４の例示の送信側クライアント装置１０２、例示の受信側サーバ装置１０４、例示のクライアントタスクエンジン１０３、例示のペイロードストレージ１０８、例示のエンコーダ１１０、例示の送信側クライアントＩ／Ｏインタフェース１１２、例示の受信側サーバＩ／Ｏインタフェース１１４、例示のサーバデータストア１１６、例示のデコーダ１１８、例示のメタデータエンジン１３６、例示のタスクプロセスコンパイラ１８６、例示のＶＭ１５２、例示のクライアントペイロードモニタ２０４、例示のメタデータリファレンスマネジャ１３４、例示のエンコーダインタフェース２０８、例示のタスク記憶インタフェース２１０、例示のＣＩＤエンジン１２０、例示のＣＩＤポインタマネジャ１２２、例示のＣＩＤファイルジェネレータ１２４、例示のＣＬＤエンジン１２６、例示のＣＬＤポインタマネジャ１２８、例示のペイロードアナライザ１３２、例示のＣＬＤファイルジェネレータ１３０、例示のサーバペイロードモニタ４０４、例示のサーバメタデータマネジャ４０６、例示のサーバ記憶インタフェース４０８、例示のデコーダマネジャ４１０、例示の解決テーブルマネジャ４１４、例示の例外ジェネレータ４１６、例示の要求マネジャ４２０、例示のフォーマットリゾルバ４２２、例示の変換システム４２４、例示のフォーマットエンコーダ４２６並びに／又は、より一般に、例示のクライアントペイロードエンジン１５０、例示のサーバペイロードエンジン１６０、例示の列挙エンジン１７０及び例示の変換エンジン１８０のうち少なくとも１つは、ソフトウェア及び／又はファームウェアを記憶するメモリ、デジタル多用途ディスク（ＤＶＤ）、コンパクトディスク（ＣＤ）、ブルーレイディスク等の、有形のコンピュータ可読記憶装置又は記憶ディスクを含むように明示的に定義される。更に、図１の例示のクライアントペイロードエンジン１５０、例示のサーバペイロードエンジン及び／又は例示の列挙エンジン１７０は、図１、１Ｂ、２及び／又は４に示されたものに加えて、又はその代わりに、１以上の要素、プロセス及び／又はデバイスを含んでよく、且つ／又は、図示された要素、プロセス及びデバイスのいずれか又は全てを含んでよい。

図１，１Ｂ，２，４のクライアントペイロードエンジン１５０、サーバペイロードエンジン１６０及び／又は列挙エンジン１７０を実施するための例示の機械可読命令を表すフローチャートを、図８〜１４に示す。これらの例では、機械可読命令は、図１５に関連して以下に説明される例示のプロセッサプラットフォーム５００に示されるプロセッサ１５１２等のプロセッサによる実行のための、１以上のプログラムを含む。プログラムは、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）、ブルーレイディスク、又はプロセッサ１５１２に関連付けられたメモリ等の、有形のコンピュータ可読記憶媒体に記憶されたソフトウェアで具現化されてよいが、プログラム全体及び／又はその一部は、代わりに、プロセッサ１５１２以外のデバイスによって実行され、且つ／又は、ファームウェア若しくは専用ハードウェアで具体化されてもよい。更に、図８〜１４に示されるフローチャートを参照して例示のプログラムを説明するが、例示のクライアントペイロードエンジン１５０、例示のサーバペイロードエンジン１６０及び／又は例示の列挙エンジン１７０を実現する多くの他の方法が代替として採用されてもよい。例えば、ブロックの実行順序が変更されてもよく、且つ／又は、記載されたブロックの一部が変更、削除或いは組み合わせられてもよい。

上述したように、図８〜１４の例示のプロセスは、ハードディスクドライブ、フラッシュメモリ、リードオンリーメモリ（ＲＯＭ）、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）、キャッシュ、ランダムアクセスメモリ（ＲＡＭ）、及び／又は任意の持続時間の間（例えば、長期間、恒久的、短時間、一時的なバッファリング、及び／又は情報のキャッシュ）に情報が記憶される任意の他の記憶装置若しくは記憶ディスク等の、有形のコンピュータ可読記憶媒体に記憶されたコード化された命令（例えば、コンピュータ及び／又は機械可読命令）を用いて、実現されてよい。本明細書で使用する場合、有形のコンピュータ可読記憶媒体という用語は、任意のタイプのコンピュータ可読記憶装置及び／又は記憶ディスクを含み、伝播信号を排除し伝送媒体を排除するように明示的に定義される。本明細書で使用する場合、「有形のコンピュータ可読記憶媒体」と「有形の機械可読記憶媒体」は、互換的に使用される。追加的又は代替的に、図８〜１４の例示のプロセスは、ハードディスクドライブ、フラッシュメモリ、読取専用メモリ、コンパクトディスク、デジタル多用途ディスク、キャッシュ、ランダムアクセスメモリ、及び／又は任意の持続時間の間（例えば、長期間、恒久的、短時間、一時的なバッファリング、及び／又は情報のキャッシュ）に情報が記憶される任意の他の記憶装置若しくは記憶ディスク等の、非一時的なコンピュータ及び／又は機械可読記憶媒体に記憶されたコード化された命令（例えば、コンピュータ及び／又は機械可読命令）を用いて、実現されてよい。本明細書で使用する場合、非一時的コンピュータ可読記憶媒体という用語は、任意のタイプのコンピュータ可読記憶装置及び／又は記憶ディスクを含み、伝播信号を排除し伝送媒体を排除するように明示的に定義される。本明細書で使用する場合、請求項のプリアンブルにおける遷移用語として「少なくとも」が使用されている場合、「含む」という用語がオープンエンドであるのと同じように、オープンエンドである。

図８のプログラム８００はブロック８０２で始まり、例示のプロセス間通信エンジン１３６は、新しいタスクがコンパイルされるべきか否かを決定する。そうである場合、例示のＣＩＤエンジン１２０が、送信されるコンポジットバイナリに関連付けられたＣＩＤを生成し（ブロック８１４）、例示のＣＬＤエンジン１２６が、送信されるコンポジットバイナリに関連付けられたＣＬＤを生成する（ブロック８１６）。例示のＣＩＤ及びＣＬＤの両方が生成された場合、ＣＩＤ及びＣＬＤをターゲットピアに再送信する必要なしにコンポジットバイナリを送信する１以上の以後のインスタンスが発生するように、例示のメタデータリファレンスマネジャ１３４は、それに関連付けられたメタデータリファレンスを生成する（ブロック８１８）。クライアントペイロードモニタ２０４は、ペイロード（例えば、１以上のコンポジット）がネットワーク１０６上の１以上の要求側デバイス（ピア）、例えば例示の受信側サーバ装置１０４に送信されるか否かを判定する（ブロック８１４）。上述のように、例示の送信側クライアント装置１０２は、１以上のピアからの要求に応答してペイロードデータを送信し、時間ベースの（例えば、周期的な、非周期的な、予定された）トリガに応答してペイロードデータを送信し、且つ／又は、条件ベースのトリガ（例えば、例示のペイロードストレージ１０８の閾値記憶消費値）に応答してペイロードデータを送信してよい。一部の例では、トリガがないと待機状態になり、他の例では、クライアントペイロードエンジン２０２は、ペイロードデータが利用可能になったときに準備が整うように、コンポジットメタデータを１以上のピアに送信及び／又は他の方法で配信する。

例示の送信側クライアント装置１０２のコンピューティングリソースを節約するために、例示のエンコーダインタフェース２０８は、例示のエンコーダ１１０が、送信されるコンポジットに対して符号化動作を実行することを中断及び／又は他の方法で防止する（ブロック８０４）。このように、例示の送信側クライアント装置によって送信された任意のコンポジットは、ネイティブフォーマット（例えばバイナリ）のままであり、これは、比較的小さなメモリ記憶領域を消費し、例示のネットワーク１０６を介して送信されるコンポジットの固有のセキュリティを保持する。

例示のタスク記憶インタフェース２１０は、前の機会にメタデータリファレンスがターゲットピアに送信されたか否かを判定する（ブロック８０８）。上述のように、例示のクライアントペイロードエンジンは、１以上のピアが比較的低い計算需要を経験している場合等、利用可能になるとすぐにコンポジットメタデータを配信してよい。メタデータリファレンスが以前に送信されていない場合、例示のクライアントペイロードエンジン２０２は、（ａ）メタデータリファレンス、（ｂ）コンポジットに関連付けられたＣＩＤ、（ｃ）コンポジットに関連付けられたＣＬＤ及び（ｄ）そのバイナリ形式でのコンポジットと共に、ペイロード（例えば、ペイロードを伴うコンポジット）を送信する（ブロック８１０）。一方、タスク記憶インタフェース２１０が、以前の機会にメタデータリファレンスがターゲットピアに送信されたと判定した場合（ブロック８０８）、これはターゲットピアが既にコンポジットに関連付けられた対応するＣＩＤ及びＣＬＤを受信したことを意味し、例示のクライアントペイロードエンジン２０２は、そのバイナリ形式でコンポジットのみを送信する（ブロック８１２）。更に別の例では、クライアントペイロードエンジン２０２は、デフォルトでメタデータリファレンスを伴うペイロードを常に送信する。受信ピアが対応するコンポジットメタデータを有さない場合、コンポジットメタデータを送信するために、クライアントペイロードエンジン２０２によって肯定応答さ及び／又は他の方法でサービスされる要求を送信する。

図９は、ブロック８１４のＣＩＤの生成に関する更なる詳細を示す。図９の図示の実施例では、ＣＩＤポインタマネジャ１２２は、構文解析ポインタを用いてコンポジットを取得し、コンポジットの開始部分を識別する（ブロック９０２）。例示のＣＩＤファイルジェネレータ１２４は、コンポジットに関連付けられたアーキテクチャ非依存データを取り込むＣＩＤシェルファイルを生成し（ブロック９０４）、例示のＣＩＤポインタマネジャ１２２は、ポインタをコンポジットの第１の要素に移動する（ブロック９０６）。例示のＣＩＤファイルジェネレータ１２４は、選択されたコンポジット要素の要素データをＣＩＤシェルファイルに符号化し（ブロック９０８）、例示のＣＩＤポインタマネジャ１２２は、送信されるコンポジット要素に残りの要素があるか否かを判定する（ブロック９１０）。そうであれば、制御はブロック９０６に戻り、そこで例示のＣＩＤポインタマネジャ１２２はポインタをバイナリコンポジット内の次の要素に進める。そうでなければ、例示のプログラム８１４は終了する。

図１０は、ブロック８１４のＣＬＤの生成に関する更なる詳細を示す。図１０の図示の実施例では、例示のＣＬＤポインタマネジャ１２８は、送信されるバイナリコンポジットを取得し（ブロック１００２）、例示のＣＬＤファイルジェネレータ１３０は、送信されるコンポジットバイナリに関連付けられたアーキテクチャ固有データで書き込まれるＣＬＤシェルファイルを生成する（ブロック１００４）。例示のペイロードアナライザ１３２は、送信されるコンポジットのサイズを識別し、この情報を例示のＣＬＤシェルファイルに書き込み（ブロック１００６）、コンポジット内の要素の数を識別し、このデータをＣＬＤシェルファイルに書き込む（ブロック１００８）。例示のペイロードアナライザ１３２は、対応するオフセット値を決定するためにバイナリコンポジット内の要素の数の１つを選択し（ブロック１０１０）、対応するオフセット値をＣＬＤシェルファイルに書き込む（ブロック１０１２）。例示のＣＬＤポインタマネジャ１２８が、解析すべきバイナリコンポジットに追加の要素が残っていると判定した場合（ブロック１０１４）、制御はブロック１０１０に戻る。全ての要素がそれぞれのオフセット値を決定するために評価された場合（ブロック１０１４）、例示のペイロードアナライザ１３２は、送信されるバイナリコンポジットに関連付けられた追加情報（例えば、エンディアン情報、浮動小数点情報、補数情報）を識別し、この値をＣＬＤシェルファイルに書き込む（ブロック１０１６）。次に、例示のプログラム８１６が終了する。

図８〜１０の例示のプログラムは、例示の送信側クライアント装置１０２によるペイロード情報（例えば、送信されるバイナリ内のコンポジット）の準備を示すが、図１１は、例示の受信側サーバ装置１０４によってペイロード情報を処理するためのプログラム１１００を示す。図１１の図示の実施例では、例示のサーバペイロードモニタ４０４は、ペイロード情報（例えば、ネットワークピアからのバイナリコンポジット）が受信されたか否かを判定する（ブロック１１０２）。そうである場合、例示のサーバメタデータマネジャ４０６は、受信したペイロード情報（例えばバイナリコンポジット）が一致するコンポジットメタデータリファレンスを含むか否かを判定する（ブロック１１０４）。そうでない場合、ペイロード情報を受信するこのインスタンスが最初に発生している可能性があり、例示のサーバ記憶インタフェース４０８は、それぞれのＣＩＤ、ＣＬＤ及び関連メタデータリファレンス命名法を抽出して、例示のサーバデータストア１１６に記憶する（ブロック１１０６）。

例示の受信側サーバ装置１０４が、例示の受信側サーバ装置１０４とは異なるアーキテクチャフォーマットを有し得るコンポジットバイナリを含む受信ペイロードを処理することができるように、例示のサーバメタデータマネジャ４０６は、それ自体のサーバ側ＣＩＤファイル及びサーバ側ＣＬＤファイルを生成する（ブロック１１０８）。一般的に言えば、サーバ側ＣＩＤファイル及びサーバ側ＣＬＤファイルは、受信側サーバ装置１０４のアーキテクチャ固有の要件の解決及びマッピングを可能にするように、送信ピア（例えば、送信側クライアント装置１０２）に関連付けられた対応するメタデータ情報を記憶する。上述のように、例示のサーバメタデータマネジャ４０６は、ピアから受信したＣＩＤ及びＣＬＤを考慮して、変換エンジン１８０によって変換及び／又は他の方法で比較される対応するメタデータを、サーバ側ＣＩＤ及びサーバ側ＣＬＤに取り込む（ブロック１１１０）。受信側サーバ装置１０４のアーキテクチャに基づいて、例示の変換エンジン１８０は、各要素にサーバ側ＣＬＤ内のオフセット値を割り当てることにより、アーキテクチャの不一致を解決する（ブロック１１１２）。更に、以下で更に詳述するように、コンポジットがＥＮＵＭ型であると例示の列挙エンジン１７０が判定した場合（ブロック１１１３）、列挙エンジン１７０は、例示の送信側クライアント装置１０２と例示の受信側サーバ装置１０４との間に存在し得る列挙命名の不一致を解決する（ブロック１１５０）。制御はブロック１１０２に戻る。

ブロック１１０４に戻り、例示のサーバメタデータマネジャ４０６が一致するコンポジットメタデータリファレンスを含む場合、例示のサーバ記憶インタフェース４０８は、受信されたメタデータリファレンスに関連付けられる以前に記憶されたサーバ側ＣＩＤ及びサーバ側ＣＬＤを取得する（ブロック１１１４）。例示の変換システム２４は、図５に示すように、以前に記憶されたサーバ側メタデータ（例えば、サーバ側ＣＩＤ５００及びサーバ側ＣＬＤ５５０）にアクセスする（ブロック１１１６）。一部の例では、例示の変換システム４２４は、適切なフォーマットエンコーダ４２６を呼び出し、サーバ側ＣＬＤ５５０からのオフセット値を用いて、受信側サーバ装置１０４と互換性のあるフォーマットで、受信したバイナリを例示のサーバデータストア１１６に記憶する（ブロック１１１８）。これは、以後の変換労力を低減することにより、特定のフォーマットに対する反復要求が受信されたときに、ある程度の計算効率をもたらすことができる。一方、一部の例では、デコーダマネジャ４１０を使用せず、代わりに、送信側クライアント装置から受信したバイナリを、必要に応じて以後の変換のための変更されていないフォーマットで記憶することができる。上述のように、受信されたコンポジットバイナリは、受信側サーバ装置１０４に関連付けられたネイティブバイナリフォーマットで記憶されるので、変換されたデータに対する１以上のピア（例えば第三者のクライアント）による以後の要求は、サーバ側ＣＬＤ５５０のオフセットマッピング情報を介してレンダリングされてよい。制御はブロック１１０２に戻る。

収集のための１以上のコンポジットバイナリを提供するネットワークピア（例えば、例示の送信側クライアント装置１０２）を参照して例示の受信側サーバ装置１０４を上述したが、受信側サーバ装置１０４は、コンポジットバイナリの変換バージョンを要求する他のピア（例えば、ネットワーク接続されたピア、同じプラットフォームのピア）からの要求（変換要求）もサービスする。上述のように、変換要求は、プレーンテキスト、ＸＭＬ、ＪＳＯＮ等、取得されるコンポジットデータのフォーマットに関する様々なプリファレンスを有するピアデバイスから生じる。このように、例示の変換エンジン１８０は、特定の符号化タイプのフォーマットに対応するために、例示の変換エンジン１８０の任意の数の異なるフォーマットエンコーダ４２６を含む。ブロック１１０２に戻り、ペイロード（例えばコンポジットバイナリ）が受信されなかった場合、例示の要求マネジャ４２０は、変換要求が発生したか否かを判定する（ブロック１１２０）。そうでなければ、例示のサービスペイロードモニタ４０４は、ＥＮＵＭマッピング要求が受信されたか否かを判定し（ブロック１１２２）、そうであれば、例示のＥＮＵＭエンジン１７０は、以下で更に詳述するように、ＥＮＵＭマッピング要求をサービスする（ブロック１４２０）。しかしながら、変換要求を検出することに応答して（ブロック１１２０）、例示の変換エンジン１８０は、例示の変換要求エンティティ１８２の１つからの要求等、要求をサービスする（ブロック１１２４）。

図１２は、例示の変換要求のサービス（ブロック１１２４）に関する追加の詳細を含む。図１２の図示の実施例では、フォーマットリゾルバ４２２は、（例えば、変換要求エンティティ１８２の１つからの）フォーマット要求タイプを識別し（ブロック１２０２）、要求されたフォーマットタイプが既に変換され例示のサーバデータストア１１６に記憶されているか否かを判定する（ブロック１２０４）。例えば、変換要求エンティティ１８２の例示の第１のものが、コンポジットがＸＭＬにフォーマットされることを要求することがあるが、そのような変換されたコンポジット情報は、変換要求エンティティ１８２の例示の第２のものもコンポジットがＸＭＬフォーマットにフォーマットされることを要求した場合に、例示のサーバデータストア１１６に任意に記憶されてよく、これにより、例示の受信側サーバ装置１０４に対する重複した変換作業を防止する。例示の変換エンジン１８０は、記憶装置（例えば例示のサーバデータストア）から復号されたコンポジットを取得し（ブロック１２０６）、復号化されたコンポジットを（例えば、例示の受信側サーバＩ／Ｏインタフェース１１４を介してリクエスタに転送する（ブロック１２０８）。

ブロック１２０４に戻り、要求されたフォーマットが例示のサーバデータストア１１６においてまだ利用可能ではないと例示のフォーマットリゾルバ４２２が判定した場合（バイナリコンポジットが要求に応答して初めて変換されたときに発生する可能性がある）、例示の変換システム４２４は、記憶されたバイナリ及び関連メタデータ（例えば、図５の例示のサーバ側ＣＩＤ５００及びサーバ側ＣＬＤ５５０）を取得する（ブロック１２１０）。上述のように、要求されたフォーマットタイプへの変換（符号化）を実行するとき、例示の変換エンジン１８０が対応するサーバ側ＣＩＤ５００及びサーバ側ＣＬＤ５５０を参照することができるように、バイナリコンポジットは、任意に、受信側サーバ装置１０４のアーキテクチャと互換性のあるフォーマットを有するサーバデータストア１１６に記憶されてよい（ブロック１２１２）。

図１３は、バイナリコンポジットの変換（ブロック１２１２）を実行するための更なる詳細を示す。図１３の図示の実施例では、例示の変換システム４２４は、サーバ側ＣＩＤ５００からコンポジット要素の１つを識別し（ブロック１３０２）、サーバ側ＣＬＤ５５０から対応する要素を識別して、対象要素に関連するデータのオフセット値を決定する（ブロック１３０４）。例示の変換システム４２４は、そのような情報を対応するフォーマットエンコーダ４２６に転送して、オフセット位置及びフォーマット要求タイプに基づいてデータを変換し（ブロック１３０６）、要求されたフォーマットタイプを有する対象要素に関連付けられたデータを生成する。例示のフォーマットリゾルバ４２２は、サーバ側ＣＩＤ５００が、変換されるバイナリコンポジット内の追加の対象要素を含むか否かを判定し（ブロック１３０８）、そうであれば、制御はブロック１３０２に戻る。しかしながら、要求されたバイナリコンポジットの全ての要素が要求されたフォーマットに変換されると、例示の変換エンジン１８０は、変換されたデータを例示のサーバデータストア１１６に記憶し（ブロック１３１０）、よって、このバイナリコンポジットに対する以後の要求は、重複した変換作業なしに、１以上の要求側ピア（例えば、例示の変換要求エンティティ１８２の１以上）に提供され得る。

図１１に戻る。一部の実施例では、ペイロードコンポジットがタイプＥＮＵＭであるとき（ブロック１１１３）、又はＥＮＵＭマッピング要求が発生したとき（ブロック１１２２Ａ）、例示の列挙エンジン１７０が呼び出されて、ＥＮＵＭの不一致が解決され（ブロック１１５０）、又はマッピン要求がサービスされる（ブロック１１２２Ａ）。図１４は、ブロック１１５０の列挙解決に関連付けられる更なる詳細を示す。図１４の図示の実施例では、例示の解決テーブルマネジャ４１４は、列挙解決テーブル（ＥＲＴ）が既にピア比較のために利用可能であるか否かを判定する（ブロック１４０２）。そうでない場合、図７の図示の実施例に示すように、例示の解決テーブルマネジャ４１４は、ＥＲＴシェルファイルを生成し（ブロック１１０４）、ＥＲＴシェルファイルの第１のピア及び第２のピアの列のフィールドに、それぞれのピアに関連付けられたＣＩＤ及びＣＬＤデータを取り込む（ブロック１１０６）。

列挙エンジン１７０の例外ジェネレータ４１６が、ピア間の不一致（例えば、要素位置の不一致、要素名の不一致、要素値の不一致）を識別する場合（例えば、例示の第２のピア７０４のＥＮＵＭ要素の順序と比較したときの、例示の第１のピア７０２のＥＮＵＭ要素順序間の不一致）、例示の例外ジェネレータ４１６は、二次（または他の）解決が利用可能であるか否かを判定する（ブロック１４１０）。上述のように、二次解決は、例示の第１のピア７０２と例示の第２のピア７０４の両方に共通する１以上の要素パラメータ（例えば要素名）に基づくことができる。利用可能であれば、例示の解決テーブルマネジャ４１４は、マッピングのための対応するパラメータを確立する（ブロック１４１２）。例えば、図７の図示の実施例に示されるように、例示の第１のピア７０２が要素“３”を参照する場合、例示の第２のピア７０４のインデックス“３”との要素位置の不一致に関わらず、対応する一致するパラメータ“ｙｅｌｌｏｗ”は、第２のピア７０４のインデックス位置“２”に一致する。このように、第１のピア７０２からの要素“３”のＥＮＵＭリファレンスは、以下で更に詳述するように、第２のピア７０４の対応する値“７００”をもたらす。このようなマッピングは、以後の参照のために例示のサーバデータストア１１６に記憶される（ブロック１４１４）。一方、例示の第１のピア７０２が例示の第２のピア７０４と対応する一致する要素名をもたない場合等、セカンダリ解決が不可能な場合（ブロック１４１０）、例示の例外ジェネレータ４１６は、その特定の要素の例外を呼び出す（ブロック１４１６）。

例示の例外ジェネレータ４１６が、例示の第１のピア７０２と例示の第２のピア７０４のＥＮＵＭコンポジット間の不一致（例えば、要素位置の不一致）がないと判定した場合（ブロック１４０８）、例示の解決テーブルマネジャ４１４は、マッピングのための対応するパラメータを確立し（ブロック１４１８）、これらのマッピングを以後の参照のために例示のサーバデータストア１１６に記憶する（ブロック１４１４）。

図１４の図示の実施例プログラム１１５０は、第１のピアと第２のピアのＥＮＵＭコンポジット間に存在し得る不一致を解決するためのＥＲＴを生成するが、例示のプログラム１１５０は、ＥＲＴが以前に生成されていた場合、ＥＮＵＭマッピング要求も処理する。例えば、図１１の図示の実施例に簡単に戻る。例示のサーバペイロードモニタ４０４がＥＮＵＭマッピング要求が発生したと判定すると（ブロック１１２２Ａ）、制御はブロック１４２０に進み、ＥＮＵＭマッピング要求が発生することを例示のＥＮＵＭエンジン１７００が確認する。例示の解決テーブルマネジャ４１４は、例示の第１のピア７０２（例えば、例示の送信側クライアント装置１０２）に関連付けられたＥＮＵＭコンポジットの要素位置“１”をマップする要求等の、対象要素のソース要求値を取得する（ブロック１４２２）。例示の解決テーブルマネジャ４１４は、第２のピア７０４（例えば、例示の受信側サーバ装置１０４）に関連付けられた対応する他のＥＮＵＭコンポジットに関連付けられたＥＲＴ７００から、対応するターゲット値を識別する（ブロック１４２４）。例示のデコーダ１１８は、ターゲット値をリクエスタに返し（ブロック１４２６）、これは図７の図示の実施例では値“５０”である。

図１５は、図１，２，４のクライアントペイロードエンジン１５０、サーバペイロードエンジン１６０、列挙エンジン１７０及び変換エンジン１８０を実現するための図８〜１４の命令を実行することができる、例示のプロセッサプラットフォーム１５００のブロック図である。プロセッサプラットフォーム１５００は、例えば、サーバ、パーソナルコンピュータ、モバイルデバイス（例えば、携帯電話、スマートフォン、ｉＰａｄ（登録商標）等のタブレット）、パーソナルデジタルアシスタント（ＰＤＡ）、インターネットアプライアンス、ＤＶＤプレーヤ、ＣＤプレーヤ、デジタルビデオレコーダ、ブルーレイプレーヤ、ゲームコンソール、パーソナルビデオレコーダ、セットトップボックス、デジタルカメラ、仮想マシンその他の任意のタイプのコンピューティングデバイスであってよい。

図示の実施例のプロセッサプラットフォーム１５００は、プロセッサ１５１２を含む。図示の実施例のプロセッサ１５１２はハードウェアである。例えば、プロセッサ１５１２は、任意の所望のファミリ又は製造業者からの１以上の集積回路、論理回路、マイクロプロセッサ又はコントローラによって実現することができる。図１５の図示の実施例では、プロセッサ１５１２は、例示の命令１５３２（図１，２及び／又は４の例示のクライアントペイロードエンジン１５０、例示のサーバペイロードエンジン１６０、例示の列挙エンジン１７０及び例示の変換エンジン１８０を実現するための図８〜１４の命令）を介して構成された１以上の例示の処理コア１５１５を含む。

図示の実施例のプロセッサ１５１２は、ローカルメモリ１５１３（例えばキャッシュ）を含む。図示の実施例のプロセッサ１５１２は、バス１５１８を介して、揮発性メモリ１５１４及び不揮発性メモリ１５１６を含むメインメモリと通信する。揮発性メモリ１５１４は、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、ＲＡＭバスダイナミックランダムアクセスメモリ（ＲＤＲＡＭ）及び／又は任意の他のタイプのランダムアクセスメモリデバイスによって実現されてよい。不揮発性メモリ１５１６は、フラッシュメモリ及び／又は任意の他の所望のタイプのメモリデバイスによって実現されてよい。メインメモリ１５１４，１５１６へのアクセスは、メモリコントローラによって制御される。

また、図示の実施例のプロセッサプラットフォーム１５００は、インタフェース回路１５２０を含む。インタフェース回路１５２０は、イーサネット（登録商標）インタフェース、ユニバーサルシリアルバス（ＵＳＢ）及び／又はＰＣＩエクスプレスインタフェース等の、任意のタイプのインタフェース規格によって実現されてよい。

図示の実施例では、１以上の入力装置１５２２がインタフェース回路１５２０に接続される。入力装置１５２２は、ユーザがデータ及びコマンドをプロセッサ１５１２に入力することを許可する。入力装置は、例えば、オーディオセンサ、マイク、カメラ（静止又はビデオ）、キーボード、ボタン、マウス、タッチスクリーン、トラックパッド、トラックボール、アイソポイント、音声認識システム及び／又は任意の他のヒューマンマシンインタフェースによって、実現することができる。

１以上の出力装置１５２４も、図示の実施例のインタフェース回路１５２０に接続される。出力装置１５２４は、例えば、ディスプレイデバイス（例えば、発光ダイオード（ＬＥＤ）、有機発光ダイオード（ＯＬＥＤ）、液晶ディスプレイ、陰極線管ディスプレイ（ＣＲＴ）、タッチスクリーン、触覚出力装置、プリンタ及び／又はスピーカ）によって実現することができる。したがって、図示の実施例のインタフェース回路１５２０は、典型的に、グラフィックスドライバカード、グラフィックドライバチップ又はグラフィックスドライバプロセッサを含む。

図示の実施例のインタフェース回路１５２０はまた、外部の機械（例えば、任意の種類のコンピューティングデバイス）とのネットワーク１５２６（例えば、イーサネット（登録商標）接続、類似の機械プラットフォーム内でのデータ交換を容易にするためのデジタル加入者線（ＤＳＬ）（例えば通信バス）、電話回線、同軸ケーブル、セルラー電話システム等）を介したデータ交換を容易にするために、送信機、受信機、トランシーバ、モデム及び／又はネットワークインタフェースカード等の通信デバイスを含む。図１５の図示の実施例では、インタフェース回路１５２０はまた、図１，２及び／又は４の例示の送信側クライアントＩ／Ｏインタフェース１１２及び／又は例示の受信側サーバＩ／Ｏインタフェース１１４の１以上を実現するように構成される。

図示の実施例のプロセッサプラットフォーム１５００はまた、外部の機械（例えば、任意の種類のコンピューティングデバイス）とのネットワーク１５２６及び／又はネットワーク１０６（例えば、イーサネット（登録商標）接続、デジタル加入者線（ＤＳＬ）、電話回線、同軸ケーブル、セルラー電話システム等）を介したデータ交換を容易にするために、送信機、受信機、トランシーバ、モデム及び／又はネットワークインタフェースカード等の通信デバイスを含む。

図示の実施例のプロセッサプラットフォーム１５００は、ソフトウェア及び／又はデータを記憶するための１以上の大容量記憶装置１５２８も含む。そのような大容量記憶装置１５２８の例には、フロッピーディスクドライブ、ハードドライブディスク、コンパクトディスクドライブ、ブルーレイディスクドライブ、ＲＡＩＤシステム、デジタル多用途ディスク（ＤＶＤ）ドライブが含まれる。一部の例では、大容量記憶装置１５３０は、例示のペイロードストレージ１０８及び／又は例示のサーバデータストア１１６を実現してよい。

図８〜１４のコード化された命令１５３２は、大容量記憶装置１５２８、揮発性メモリ１５１４、不揮発性メモリ１５１６、ローカルメモリ１５１３及び／又は取り外し可能な有形のコンピュータ可読記憶媒体、例えばＣＤ又はＤＶＤ１５３６に記憶されてよい。

本明細書では特定の例示の方法、装置及び製品が開示されたが、本願の適用範囲はそれに限定されない。対照的に、本願は、本願の特許請求の範囲に包含される全ての方法、装置及び製品を対象とする。

実施例１は、送信ピアのネットワーク伝送効率を改善するための装置である。本装置は、送信トリガに応答して、エンコーダが、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するエンコーダインタフェースと、ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成する複合インタフェース記述（ＣＩＤ）エンジンと、ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成する複合レイアウト記述（ＣＬＤ）エンジンであって、アーキテクチャ固有メタデータは、ネイティブフォーマットのデータの要素に関連するオフセット値を識別する、複合レイアウト記述（ＣＬＤ）エンジンと、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善するクライアントペイロードエンジンと、を備える。

実施例２は実施例１の主題を含む。未符号化データは、エンコーダによって符号化された後のネイティブフォーマットのデータよりもストレージフットプリントを含む。

実施例３は実施例１の主題を含む。ネイティブフォーマットのデータは、バイナリフォーマットを含む。

実施例４は実施例１の主題を含む。ターゲットフォーマットは、拡張マークアップ言語フォーマット、抽象構文記法フォーマット及びテキストフォーマットのうち少なくとも１つを含む。

実施例５は実施例１の主題を含む。ネイティブフォーマットのデータは、タイプに関連するコンポジットを含む。

実施例６は実施例５の主題を含む。タイプは、Ｃ構造と列挙のうち少なくとも一方を含む。

実施例７は実施例１の主題を含む。更に、ネイティブフォーマットのデータの要素のうち最初の要素を識別するポインタマネジャを備える。

実施例８は実施例７の主題を含む。更に、アーキテクチャ非依存メタデータを記憶するためのＣＩＤファイルを生成するＣＩＤファイルジェネレータを備える。

実施例９は実施例８の主題を含む。ＣＩＤファイルジェネレータは、要素データをＣＩＤファイルに符号化する。

実施例１０は実施例９の主題を含む。要素データは、コンポジットタイプ、コンポジット名、コンポジット要素名及びコンポジット要素タイプのうち少なくとも１つを含む。

実施例１１は実施例７の主題を含む。更に、アーキテクチャ固有メタデータを記憶するためのＣＬＤファイルを生成するＣＬＤファイルジェネレータを備える。

実施例１２は実施例１１の主題を含む。更に、ネイティブフォーマットのデータの要素に関連付けられたオフセット値を識別し、オフセット値をＣＬＤファイルに書き込むペイロードアナライザを備える。

実施例１３は実施例１の主題を含む。更に、結合されたアーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータに関連付けられたメタデータリファレンスを生成するメタデータリファレンスマネジャを備える。

実施例１４は実施例１の主題を含む。更に、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータを、送信ピアのタスク実行ファイルにコンパイルするタスクプロセスコンパイラを備える。

実施例１５は、送信ピアのネットワーク伝送効率を改善する方法である。本方法は、送信トリガに応答して、エンコーダが、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するステップと、ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成するステップと、ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成するステップであって、アーキテクチャ固有メタデータは、ネイティブフォーマットのデータの要素に関連するオフセット値を識別する、ステップと、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善するステップと、を含む。

実施例１６は実施例１５の主題を含む。未符号化データは、エンコーダによって符号化された後のネイティブフォーマットのデータよりもストレージフットプリントを含む。

実施例１７は実施例１５の主題を含む。ネイティブフォーマットのデータは、バイナリフォーマットを含む。

実施例１８は実施例１５の主題を含む。ターゲットフォーマットは、拡張マークアップ言語フォーマット、抽象構文記法フォーマット及びテキストフォーマットのうち少なくとも１つを含む。

実施例１９は実施例１５の主題を含む。ネイティブフォーマットのデータは、タイプに関連するコンポジットを含む。

実施例２０は実施例１９の主題を含む。タイプは、Ｃ構造と列挙のうち少なくとも一方を含む。

実施例２１は実施例１５の主題を含む。更に、ネイティブフォーマットのデータの要素のうち最初の要素を識別するステップを含む。

実施例２２は実施例２１の主題を含む。更に、アーキテクチャ非依存メタデータを記憶するための複合インタフェース記述（ＣＩＤ）ファイルを生成するステップを含む。

実施例２３は実施例２２の主題を含む。更に、要素データをＣＩＤファイルに符号化するステップを含む。

実施例２４は実施例２３の主題を含む。要素データは、コンポジットタイプ、コンポジット名、コンポジット要素名及びコンポジット要素タイプのうち少なくとも１つを含む。

実施例２５は実施例２１の主題を含む。更に、アーキテクチャ固有メタデータを記憶するための複合レイアウト記述（ＣＬＤ）ファイルを生成するステップを含む。

実施例２６は実施例２５の主題を含む。更に、ネイティブフォーマットのデータの要素に関連付けられたオフセット値を識別するステップと、オフセット値をＣＬＤファイルに書き込むステップとを含む。

実施例２７は実施例１５の主題を含む。更に、結合されたアーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータに関連付けられたメタデータリファレンスを生成するステップを含む。

実施例２８は実施例１５の主題を含む。更に、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータを、送信ピアのタスク実行ファイルにコンパイルするステップを含む。

実施例２９は、コンピュータ可読命令を有する有形のコンピュータ可読記憶媒体である。コンピュータ可読命令は、実行されると、プロセッサに、少なくとも送信トリガに応答して、エンコーダが、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するステップと、ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成するステップと、ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成するステップであって、アーキテクチャ固有メタデータは、ネイティブフォーマットのデータの要素に関連するオフセット値を識別する、ステップと、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善するステップと、を実行させる。

実施例３０は実施例２９の主題を含む。命令は、プロセッサに、エンコーダによって符号化された後のネイティブフォーマットのデータよりも低いストレージフットプリントで、未符号化データを送信するステップを実行させる。

実施例３１は実施例２９の主題を含む。命令は、プロセッサに、ネイティブフォーマットをバイナリフォーマットとして送信するステップを実行させる。

実施例３２は実施例２９の主題を含む。命令は、プロセッサに、ネイティブフォーマットのデータの要素のうち最初の要素を識別するステップを実行させる。

実施例３３は実施例３２の主題を含む。命令は、プロセッサに、アーキテクチャ非依存メタデータを記憶するための複合インタフェース記述（ＣＩＤ）ファイルを生成するステップを実行させる。

実施例３４は実施例３３の主題を含む。命令は、プロセッサに、要素データをＣＩＤファイルに符号化するステップを実行させる。

実施例３５は実施例３２の主題を含む。命令は、プロセッサに、アーキテクチャ固有メタデータを記憶するための複合レイアウト記述（ＣＬＤ）ファイルを生成するステップを実行させる。

実施例３６は実施例３５の主題を含む。命令は、プロセッサに、ネイティブフォーマットのデータの要素に関連付けられたオフセット値を識別するステップと、オフセット値をＣＬＤファイルに書き込むステップとを実行させる。

実施例３７は実施例２９の主題を含む。命令は、プロセッサに、結合されたアーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータに関連付けられたメタデータリファレンスを生成するステップを実行させる。

実施例３８は実施例２９の主題を含む。命令は、プロセッサに、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータを、送信ピアのタスク実行ファイルにコンパイルするステップを実行させる。

実施例３９は、送信ピアのネットワーク伝送効率を改善するためのシステムである。本システムは、送信トリガに応答して、エンコーダが、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するための手段と、ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成するための手段と、ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成するための手段であって、アーキテクチャ固有メタデータは、ネイティブフォーマットのデータの要素に関連するオフセット値を識別する、手段と、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善するための手段と、を備える。

実施例４０は実施例３９の主題を含む。未符号化データは、エンコーダによって符号化された後のネイティブフォーマットのデータよりもストレージフットプリントを含む。

実施例４１は実施例３９の主題を含む。ネイティブフォーマットのデータは、バイナリフォーマットを含む。

実施例４２は実施例３９の主題を含む。ターゲットフォーマットは、拡張マークアップ言語フォーマット、抽象構文記法フォーマット及びテキストフォーマットのうち少なくとも１つを含む。

実施例４３は実施例３９の主題を含む。ネイティブフォーマットのデータは、タイプに関連するコンポジットを含む。

実施例４４は実施例４３の主題を含む。タイプは、Ｃ構造と列挙のうち少なくとも一方を含む。

実施例４５は実施例３９の主題を含む。更に、ネイティブフォーマットのデータの要素のうち最初の要素を識別するための手段を備える。

実施例４６は実施例４５の主題を含む。更に、アーキテクチャ非依存メタデータを記憶するための複合インタフェース記述（ＣＩＤ）ファイルを生成するための手段を備える。

実施例４７は実施例４６の主題を含む。ＣＩＤファイルを生成するための手段は、要素データをＣＩＤファイルに符号化する。

実施例４８は実施例４７の主題を含む。要素データは、コンポジットタイプ、コンポジット名、コンポジット要素名及びコンポジット要素タイプのうち少なくとも１つを含む。

実施例４９は実施例４５の主題を含む。更に、アーキテクチャ固有メタデータを記憶するための複合レイアウト記述（ＣＬＤ）ファイルを生成するステップための手段を備える。

実施例５０は実施例４９の主題を含む。更に、ネイティブフォーマットのデータの要素に関連付けられたオフセット値を識別するための手段と、オフセット値をＣＬＤファイルに書き込むための手段とを備える。

実施例５１は実施例３９の主題を含む。更に、結合されたアーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータに関連付けられたメタデータリファレンスを生成するための手段を備える。

実施例５２は実施例３９の主題を含む。更に、アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータを、送信ピアのタスク実行ファイルにコンパイルするための手段を備える。

実施例５３は、互換性のないアーキテクチャフォーマットを有する受信ピアによって取得されたデータをリゾルブする例示の装置である。本装置は、互換性のないアーキテクチャフォーマットを有するコンポジットと、コンポジットに関連付けられたアーキテクチャ非依存メタデータを有するクライアント側複合インタフェース記述（ＣＩＤ）と、コンポジットに関連付けられたアーキテクチャ固有メタデータを有するクライアント側複合レイアウト記述（ＣＬＤ）とを取得するサーバ記憶インタフェースと、クライアント側ＣＩＤのアーキテクチャ非依存メタデータを伴うサーバ側ＣＩＤを符号化し、クライアント側ＣＬＤのアーキテクチャ固有メタデータを伴うサーバ側ＣＬＤを符号化するサーバメタデータマネジャと、受信ピアのアーキテクチャタイプに基づいて、サーバ側ＣＬＤの各要素のオフセット値を生成する変換エンジンと、を備える。

実施例５４は実施例５３の主題を含む。更に、互換性のないアーキテクチャフォーマットを有するデータをレンダリングする要求を検出する要求マネジャを備える。

実施例５５は実施例５４の主題を含む。更に、要求のフォーマットタイプを識別するフォーマットリゾルバを備える。

実施例５６は実施例５５の主題を含む。更に、（ａ）各要素の各オフセット値と（ｂ）要求のフォーマットタイプに基づいて、受信ピアによって取得されたデータの各要素を変換する変換エンジンを備える。

実施例５７は実施例５６の主題を含む。変換エンジンは、データの変換された各要素を要求のリクエスタに転送する。

実施例５８は実施例５４の主題を含む。サーバ記憶インタフェースは、クライアント側ＣＩＤ及びクライアント側ＣＬＤを受信ピアのメタデータリファレンスに関連付けることにより、後続の要求中の受信ピアの計算要求を低減する。

実施例５９は実施例５３の主題を含む。サーバ記憶インタフェースは、サーバ側ＣＩＤ及びサーバ側ＣＬＤを受信ピアのメタデータリファレンスと関連付ける。

実施例６０は実施例５９の主題を含む。サーバメタデータマネジャは、受信ピアによって取得されたデータが、受信ピアのメタデータリファレンスとマッチする送信ピアのメタデータリファレンスを含む場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤの延コーディングをバイパスすることにより、受信ピアの計算効率を改善する。

実施例６１は実施例６０の主題を含む。サーバメタデータマネジャは、送信ピアのメタデータリファレンスが受信ピアのメタデータリファレンスとマッチする場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤをローカルストレージから取得する。

実施例６２は、互換性のないアーキテクチャフォーマットを有する受信ピアによって取得されたデータをリゾルブする方法である。本方法は、互換性のないアーキテクチャフォーマットを有するコンポジットと、コンポジットに関連付けられたアーキテクチャ非依存メタデータを有するクライアント側複合インタフェース記述（ＣＩＤ）と、コンポジットに関連付けられたアーキテクチャ固有メタデータを有するクライアント側複合レイアウト記述（ＣＬＤ）とを取得するステップと、クライアント側ＣＩＤのアーキテクチャ非依存メタデータを用いてサーバ側ＣＬＤを符号化するステップと、クライアント側ＣＬＤのアーキテクチャ固有メタデータを用いてサーバ側ＣＬＤを符号化するステップと、受信ピアのアーキテクチャタイプに基づいて、サーバ側ＣＬＤの各要素に対するオフセット値を生成するステップと、を含む。

実施例６３は実施例６２の主題を含む。更に、互換性のないアーキテクチャフォーマットを有するデータをレンダリングする要求を検出するステップを含む。

実施例６４は実施例６３の主題を含む。更に、要求のフォーマットタイプを識別するステップを含む。

実施例６５は実施例６４の主題を含む。更に、（ａ）各要素の各オフセット値と（ｂ）要求のフォーマットタイプに基づいて、受信ピアによって取得されたデータのそれぞれの要素を変換するステップを含む。

実施例６６は実施例６５の主題を含む。更に、データの変換されたそれぞれの要素を要求のリクエスタに転送するステップを含む。

実施例６７は実施例６３の主題を含む。更に、クライアント側ＣＩＤ及びクライアント側ＣＬＤを受信ピアのメタデータリファレンスに関連付けることにより、後続の要求中の受信ピアの計算要求を低減するステップを含む。

実施例６８は実施例６２の主題を含む。更に、サーバ側ＣＩＤ及びサーバ側ＣＬＤを受信ピアのメタデータリファレンスと関連付けるステップを含む。

実施例６９は実施例６８の主題を含む。更に、受信ピアによって取得されたデータが、受信ピアのメタデータリファレンスとマッチする送信ピアのメタデータリファレンスを含む場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤの符号化を回避することにより、受信ピアの計算効率を改善するステップを含む。

実施例７０は実施例６９の主題を含む。更に、送信ピアのメタデータリファレンスが受信ピアのメタデータリファレンスとマッチする場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤをローカルストレージから取得するステップを含む。

実施例７１は、コンピュータ可読命令を有する有形のコンピュータ可読記憶媒体である。コンピュータ可読命令は、実行されると、互換性のないアーキテクチャフォーマットを有するコンポジットと、コンポジットに関連付けられたアーキテクチャ非依存メタデータを有するクライアント側複合インタフェース記述（ＣＩＤ）と、コンポジットに関連付けられたアーキテクチャ固有メタデータを有するクライアント側複合レイアウト記述（ＣＬＤ）とを取得するステップと、クライアント側ＣＩＤのアーキテクチャ非依存メタデータを用いてサーバ側ＣＬＤを符号化するステップと、クライアント側ＣＬＤのアーキテクチャ固有メタデータを用いてサーバ側ＣＬＤを符号化するステップと、受信ピアのアーキテクチャタイプに基づいて、サーバ側ＣＬＤの各要素のオフセット値を生成するステップと、をプロセッサに少なくとも実行させる。

実施例７２は実施例７１の主題を含む。命令は、プロセッサに、互換性のないアーキテクチャフォーマットを有するデータをレンダリングする要求を検出するステップを実行させる。

実施例７３は実施例７２の主題を含む。命令は、プロセッサに、要求のフォーマットタイプを識別するステップを実行させる。

実施例７４は実施例７３の主題を含む。命令は、プロセッサに、（ａ）各要素の各オフセット値と（ｂ）要求のフォーマットタイプに基づいて、受信ピアによって取得されたデータの各要素を変換するステップを実行させる。

実施例７５は実施例７４の主題を含む。命令は、プロセッサに、データの変換された各要素を要求のリクエスタに転送するステップを実行させる。

実施例７６は実施例７２の主題を含む。命令は、プロセッサに、クライアント側ＣＩＤ及びクライアント側ＣＬＤを受信ピアのメタデータリファレンスに関連付けることにより、後続の要求中の受信ピアの計算要求を低減するステップを実行させる。

実施例７７は実施例７１の主題を含む。命令は、プロセッサに、サーバ側ＣＩＤ及びサーバ側ＣＬＤを受信ピアのメタデータリファレンスと関連付けるステップを実行させる。

実施例７８は実施例７７の主題を含む。命令は、プロセッサに、受信ピアによって取得されたデータが、受信ピアのメタデータリファレンスとマッチする送信ピアのメタデータリファレンスを含む場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤの延コーディングをバイパスすることにより、受信ピアの計算効率を改善するステップを実行させる。

実施例７９は実施例７８の主題を含む。命令は、プロセッサに、送信ピアのメタデータリファレンスが受信ピアのメタデータリファレンスとマッチする場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤをローカルストレージから取得するステップを実行させる。

実施例８０は、互換性のないアーキテクチャフォーマットを有する受信ピアによって取得されたデータをリゾルブするためのシステムである。本システムは、互換性のないアーキテクチャフォーマットを有するコンポジットを取得するための手段と、コンポジットに関連付けられたアーキテクチャ非依存メタデータを有するクライアント側複合インタフェース記述（ＣＩＤ）を取得するための手段と、コンポジットに関連付けられたアーキテクチャ固有メタデータを有するクライアント側複合レイアウト記述（ＣＬＤ）を取得するための手段と、クライアント側ＣＩＤのアーキテクチャ非依存メタデータを用いてサーバ側ＣＬＤを符号化するための手段と、クライアント側ＣＬＤのアーキテクチャ固有メタデータを用いてサーバ側ＣＬＤを符号化するための手段と、受信ピアのアーキテクチャタイプに基づいて、サーバ側ＣＬＤの各要素に対するオフセット値を生成するための手段と、を備える。

実施例８１は実施例８０の主題を含む。更に、互換性のないアーキテクチャフォーマットを有するデータをレンダリングする要求を検出するための手段を備える。

実施例８２は実施例８１の主題を含む。更に、要求のフォーマットタイプを識別するための手段を備える。

実施例８３は実施例８２の主題を含む。更に、（ａ）各要素の各オフセット値と（ｂ）要求のフォーマットタイプに基づいて、受信ピアによって取得されたデータのそれぞれの要素を変換するための手段を備える。

実施例８４は実施例８３の主題を含む。更に、データの変換されたそれぞれの要素を要求のリクエスタに転送するための手段を備える。

実施例８５は実施例８１の主題を含む。更に、クライアント側ＣＩＤ及びクライアント側ＣＬＤを受信ピアのメタデータリファレンスに関連付けることにより、後続の要求中の受信ピアの計算要求を低減するための手段を備える。

実施例８６は実施例８０の主題を含む。更に、サーバ側ＣＩＤ及びサーバ側ＣＬＤを受信ピアのメタデータリファレンスと関連付けるための手段を備える。

実施例８７は実施例８６の主題を含む。更に、受信ピアによって取得されたデータが、受信ピアのメタデータリファレンスとマッチする送信ピアのメタデータリファレンスを含む場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤの符号化を回避することにより、受信ピアの計算効率を改善するための手段を備える。

実施例８８は実施例８７の主題を含む。更に、送信ピアのメタデータリファレンスが受信ピアのメタデータリファレンスとマッチする場合、サーバ側ＣＩＤ及びサーバ側ＣＬＤをローカルストレージから取得するための手段を備える。

実施例８９は、送信ピアの列挙（ＥＮＵＭ）コンポジットのバイナリ変換を防止する装置である。本装置は、送信ピアＥＮＵＭコンポジットに関連付けられた送信ピアメタデータを取得するサーバ記憶インタフェースと、送信ピアメタデータを受信ピアＥＮＵＭコンポジットに関連付けられた受信ピアメタデータと比較する列挙解決テーブル（ＥＲＴ）を生成する解決テーブルマネジャと、（ａ）送信ピアメタデータ及び（ｂ）受信ピアメタデータの各要素インデックス位置に基づいて一致する要素を識別することにより、送信ピアＥＮＵＭコンポジットの変換を防止することにより、受信ピアの計算要求を改善する例外ジェネレータと、を備える。

実施例９０は実施例８９の主題を含む。解決テーブルマネジャは、送信ピアＥＮＵＭコンポジットに関連付けられたマッピング要求値に基づいて、受信ピアＥＮＵＭコンポジットのそれぞれのターゲット値を識別する。

実施例９１は実施例９０の主題を含む。例外ジェネレータは、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータとの間の各要素インデックス位置のうち１つの不一致を識別する。

実施例９２は実施例９１の主題を含む。例外ジェネレータは、不一致の識別に応答してセカンダリ解決パラメータを識別する。

実施例９３は実施例９２の主題を含む。セカンダリ解決パラメータは、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータに共通する要素名を含む。

実施例９４は実施例９１の主題を含む。解決テーブルマネジャは、セカンダリ解決パラメータに基づいて、送信ピアＥＮＵＭコンポジットと受信ピアＥＮＵＭコンポジットとの間のマッピングリンクを確立する。

実施例９５は実施例９１の主題を含む。例外ジェネレータは、（ａ）不一致を含み（ｂ）利用可能なセカンダリ解決パラメータを含まないそれぞれの要素について例外を呼び出す。

実施例９６は、送信ピアの列挙（ＥＮＵＭ）コンポジットのバイナリ変換を防止する方法である。本方法は、送信ピアＥＮＵＭコンポジットに関連付けられた送信ピアメタデータを取得するステップと、送信ピアメタデータを受信ピアＥＮＵＭコンポジットに関連付けられた受信ピアメタデータと比較する列挙解決テーブル（ＥＲＴ）を生成するステップと、（ａ）送信ピアメタデータ及び（ｂ）受信ピアメタデータの各要素インデックス位置に基づいて一致する要素を識別することにより、送信ピアＥＮＵＭコンポジットの変換を防止することにより、受信ピアの計算要求を改善するステップと、を含む。

実施例９７は実施例９６の主題を含む。更に、送信ピアＥＮＵＭコンポジットに関連付けられたマッピング要求値に基づいて、受信ピアＥＮＵＭコンポジットのそれぞれのターゲット値を識別するステップを含む。

実施例９８は実施例９６の主題を含む。更に、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータとの間の各要素インデックス位置のうち１つの不一致を識別するステップを含む。

実施例９９は実施例９８の主題を含む。更に、不一致の識別に応答してセカンダリ解決パラメータを識別するステップを含む。

実施例１００は実施例９９の主題を含む。セカンダリ解決パラメータは、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータに共通する要素名を含む。

実施例１０１は実施例９８の主題を含む。更に、セカンダリ解決パラメータに基づいて、送信ピアＥＮＵＭコンポジットと受信ピアＥＮＵＭコンポジットとの間のマッピングリンクを確立するステップを含む。

実施例１０２は実施例９８の主題を含む。更に、（ａ）不一致を含み（ｂ）利用可能なセカンダリ解決パラメータを含まないそれぞれの要素について例外を呼び出すステップを含む。

実施例１０３は、コンピュータ可読命令を有する有形のコンピュータ可読記憶媒体である。コンピュータ可読命令は、実行されると、送信ピアＥＮＵＭコンポジットに関連付けられた送信ピアメタデータを取得するステップと、送信ピアメタデータを受信ピアＥＮＵＭコンポジットに関連付けられた受信ピアメタデータと比較する列挙解決テーブル（ＥＲＴ）を生成するステップと、（ａ）送信ピアメタデータ及び（ｂ）受信ピアメタデータの各要素インデックス位置に基づいて一致する要素を識別することにより、送信ピアＥＮＵＭコンポジットの変換を防止することにより、受信ピアの計算要求を改善するステップと、をプロセッサに少なくとも実行させる。

実施例１０４は実施例１０３の主題を含む。命令は、プロセッサに、送信ピアＥＮＵＭコンポジットに関連付けられたマッピング要求値に基づいて、受信ピアＥＮＵＭコンポジットのそれぞれのターゲット値を識別するステップを実行させる。

実施例１０５は実施例１０３の主題を含む。命令は、プロセッサに、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータとの間の各要素インデックス位置のうち１つの不一致を識別するステップを実行させる。

実施例１０６は実施例１０５の主題を含む。命令は、プロセッサに、不一致の識別に応答してセカンダリ解決パラメータを識別するステップを実行させる。

実施例１０７は実施例１０６の主題を含む。命令は、プロセッサに、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータに共通するセカンダリ解決パラメータの要素名を含むステップを実行させる。

実施例１０８は実施例１０５の主題を含む。命令は、プロセッサに、セカンダリ解決パラメータに基づいて、送信ピアＥＮＵＭコンポジットと受信ピアＥＮＵＭコンポジットとの間のマッピングリンクを確立するステップを実行させる。

実施例１０９は実施例１０５の主題を含む。命令は、プロセッサに、（ａ）不一致を含み（ｂ）利用可能なセカンダリ解決パラメータを含まないそれぞれの要素について例外を呼び出すステップを実行させる。

実施例１１０は、送信ピアの列挙（ＥＮＵＭ）コンポジットのバイナリ変換を防止するシステムである。本システムは、送信ピアＥＮＵＭコンポジットに関連付けられた送信ピアメタデータを取得するための手段と、送信ピアメタデータを受信ピアＥＮＵＭコンポジットに関連付けられた受信ピアメタデータと比較する列挙解決テーブル（ＥＲＴ）を生成するための手段と、（ａ）送信ピアメタデータ及び（ｂ）受信ピアメタデータの各要素インデックス位置に基づいて一致する要素を識別することにより、送信ピアＥＮＵＭコンポジットの変換を防止することにより、受信ピアの計算要求を改善するための手段と、を備える。

実施例１１１は実施例１１０の主題を含む。更に、送信ピアＥＮＵＭコンポジットに関連付けられたマッピング要求値に基づいて、受信ピアＥＮＵＭコンポジットのそれぞれのターゲット値を識別するための手段を備える。

実施例１１２は実施例１１０の主題を含む。更に、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータとの間の各要素インデックス位置のうち１つの不一致を識別するための手段を備える。

実施例１１３は実施例１１２の主題を含む。更に、不一致の識別に応答してセカンダリ解決パラメータを識別するための手段を備える。

実施例１１４は実施例１１３の主題を含む。セカンダリ解決パラメータは、（ａ）送信ピアメタデータと（ｂ）受信ピアメタデータに共通する要素名を含む。

実施例１１５は実施例１１２の主題を含む。更に、セカンダリ解決パラメータに基づいて、送信ピアＥＮＵＭコンポジットと受信ピアＥＮＵＭコンポジットとの間のマッピングリンクを確立するための手段を備える。

実施例１１６は実施例１１２の主題を含む。更に、（ａ）不一致を含み（ｂ）利用可能なセカンダリ解決パラメータを含まないそれぞれの要素について例外を呼び出すための手段を備える。

Claims (26)

1. 送信ピアのネットワーク伝送効率を改善するための装置であって、
   送信トリガに応答して、エンコーダが、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するエンコーダインタフェースと、
   ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成する複合インタフェース記述（ＣＩＤ）エンジンと、
   ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成する複合レイアウト記述（ＣＬＤ）エンジンであって、アーキテクチャ固有メタデータは、ネイティブフォーマットのデータの要素に関連するオフセット値を識別する、複合レイアウト記述（ＣＬＤ）エンジンと、
   アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善する、クライアントペイロードエンジンと、
   を備える装置。
2. 未符号化データは、エンコーダによって符号化された後のネイティブフォーマットのデータよりも低いストレージフットプリントを含む、
   請求項１に記載の装置。
3. ネイティブフォーマットのデータは、タイプに関連するコンポジットを含む、
   請求項１に記載の装置。
4. タイプは、Ｃ構造と列挙のうち少なくとも一方を含む、
   請求項３に記載の装置。
5. ネイティブフォーマットのデータの要素のうち最初の要素を識別するポインタマネジャ、
   を更に備える、請求項１に記載の装置。
6. アーキテクチャ非依存メタデータを記憶するためのＣＩＤファイルを生成するＣＩＤファイルジェネレータ、
   を更に備える、請求項５に記載の装置。
7. ＣＩＤファイルジェネレータは、要素データをＣＩＤファイルに符号化する、
   請求項６に記載の装置。
8. 要素データは、コンポジットタイプ、コンポジット名、コンポジット要素名及びコンポジット要素タイプのうち少なくとも１つを含む、
   請求項７に記載の装置。
9. アーキテクチャ固有メタデータを記憶するためのＣＬＤファイルを生成するＣＬＤファイルジェネレータ、
   を更に備える、請求項５に記載の装置。
10. ネイティブフォーマットのデータの要素に関連付けられたオフセット値を識別し、オフセット値をＣＬＤファイルに書き込むペイロードアナライザ、
    を更に備える、請求項９に記載の装置。
11. アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータを、送信ピアのタスク実行ファイルにコンパイルするタスクプロセスコンパイラ、
    を更に備える、請求項１に記載の装置。
12. 送信ピアのネットワーク伝送効率を改善する方法であって、
    送信トリガに応答して、エンコーダが、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するステップと、
    ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成するステップと、
    ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成するステップであって、アーキテクチャ固有メタデータは、ネイティブフォーマットのデータの要素に関連するオフセット値を識別する、ステップと、
    アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善するステップと、
    を含む方法。
13. ネイティブフォーマットのデータの要素のうち最初の要素を識別するステップ、
    を更に含む、請求項１２に記載の方法。
14. アーキテクチャ固有メタデータを記憶するための複合レイアウト記述（ＣＬＤ）ファイルを生成するステップ、
    を更に含む、請求項１３に記載の方法。
15. ネイティブフォーマットのデータの要素に関連付けられたオフセット値を識別するステップと、
    オフセット値をＣＬＤファイルに書き込むステップと、
    を更に含む、請求項１４に記載の方法。
16. 送信トリガに応答して、エンコーダが、ネイティブフォーマットのデータを要求側ピアに関連付けられたターゲットフォーマットに符号化するのを防止するステップと、
    ネイティブフォーマットのデータのアーキテクチャ非依存メタデータを生成するステップと、
    ネイティブフォーマットのデータのアーキテクチャ固有メタデータを生成するステップであって、アーキテクチャ固有メタデータは、ネイティブフォーマットのデータの要素に関連するオフセット値を識別する、ステップと、
    アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータと結合された未符号化データを、送信ピアのものとは異なるアーキテクチャを有する要求側ピアに送信することにより、ネットワーク伝送効率を改善するステップと、
    をプロセッサに実行させるためのプログラム。
17. エンコーダによって符号化された後のネイティブフォーマットのデータよりも低いストレージフットプリントで、未符号化データを送信するステップ、
    をプロセッサに実行させる、請求項１６に記載のプログラム。
18. ネイティブフォーマットをバイナリフォーマットとして送信するステップ、
    をプロセッサに実行させる、請求項１６に記載のプログラム。
19. ネイティブフォーマットのデータの要素のうち最初の要素を識別するステップ、
    をプロセッサに実行させる、請求項１６に記載のプログラム。
20. アーキテクチャ非依存メタデータを記憶するための複合インタフェース記述（ＣＩＤ）ファイルを生成するステップ、
    をプロセッサに実行させる、請求項１９に記載のプログラム。
21. 要素データをＣＩＤファイルに符号化するステップ、
    をプロセッサに実行させる、請求項２０に記載のプログラム。
22. 前記アーキテクチャ固有メタデータを記憶するための複合レイアウト記述（ＣＬＤ）ファイルを生成するステップ、
    をプロセッサに実行させる、請求項１９に記載のプログラム。
23. ネイティブフォーマットのデータの要素に関連付けられたオフセット値を識別するステップと、
    オフセット値をＣＬＤファイルに書き込むステップと、
    をプロセッサに実行させる、請求項２２に記載のプログラム。
24. 結合されたアーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータに関連付けられたメタデータリファレンスを生成するステップ、
    をプロセッサに実行させる、請求項１６に記載のプログラム。
25. アーキテクチャ非依存メタデータ及びアーキテクチャ固有メタデータを、送信ピアのタスク実行ファイルにコンパイルするステップ、
    をプロセッサに実行させる、請求項１６に記載のプログラム。
26. 請求項１６乃至２５のいずれか一項に記載のプログラムを記憶した、有形のコンピュータ可読記憶媒体。

Images