JP2010140503A - 統一データ交換および記憶フォーマットを供給するための方法とシステム - Google Patents

Abstract

【課題】統一データ交換および記憶フォーマットを供給するための方法とシステム
【解決手段】ネットワーク内でデータ交換およびデータ記憶プロトコルの両者のための統一フォーマットを供給する方法とシステムとが表示される。統一データ・フォーマットは、変更サイズの実時間データを受信、構文解析、復号、および蓄積するための効率的なプロトコルを供給する。
【選択図】図１

Description

本開示された実施形態は一般に通信システムに関し、そしてより詳しくは、データ交換およびデータ記憶プロトコルのための統一フォーマットを供給する方法とシステムとに関する。

ネットワークでのデータ交換のための現存のフォーマットはデータ記憶のための現存のフォーマットと大幅に異なっており、従って、データ・クライアントにより受信されたデータは記憶される前に再フォーマットされねばならない。現存のデータ交換フォーマットとディスク記憶フォーマットとは小サイズおよび大サイズの両者についてではなく、いずれか一方について最適化される。最近のデータ記憶フォーマットはそれらをネットワーク接続を介して実時間でサイズ変更データをエラー強く交換するのに役立たせるために必要な特徴を欠き、そして最近のネットワーク・プロトコルはデータをエラー強く記憶するのに必要な特徴を欠いている。

従って、統一フォーマットがコスト的に有効な実施、他のツールとの互換性、および符号の再使用性に帰着するように、データ交換および記憶の両者に適する統一フォーマットについての当技術分野内の要求がある。またハードウェアおよび／またはソフトウェア実行時コストを減少させるために効率的なデータ圧縮／復元のための統一データ交換および記憶フォーマットについての要求がある。

この中に開示された実施形態は、データ・クライアントおよびデータ・マネージャを含むネットワーク内でデータをフォーマットするための方法とシステムとを供給することにより上述の要求をアドレスする。この方法とシステムとは、そのデータ・フォーマットがデータ交換とデータ記憶との両者に適用されるように、ヘッダ・セクション、レコード・セクション、およびテール・セクションを有する統一データ・フォーマットを供給する。

この発明のもう１つの観点では、データ・クライアント装置は、ネットワーク接続を介して受信されたデータと記憶ユニットに送られたデータとが同一フォーマットを有するように、ネットワーク接続を介してデータ・マネージャからデータを受信するように構成された受信器および記憶ユニットにデータを送るように構成された送信器を含む。

この発明のもう１つの観点では、ネットワーク内のデータをフォーマットするためのデータ構造は、そのデータ構造がデータ交換およびデータ記憶プロトコルの両者に適用されるように、ヘッダ・セクション、レコード・セクション、およびテール・セクションを含む。

データ交換プロトコルを実施するための１つの例示的なネットワーク・インターフェイスの代表を示す図。 １つの例示的なデータ・フォーマットの代表を示す図。 １つの例示的な総合データ・フォーマットの代表を示す図。 １つの例示的なレコード・フォーマットの代表を示す図。 １つの例示的なレコード・フォーマットの代表を示す図。 総合データ・フォーマットのための１つの例示的なヘッダの代表を示す図。 １つの例示的なレコード・フォーマットの代表を示す図。 図１で動作しているデータ・クライアントおよびデータ・マネージャのため１つの例示的な実施形態のブロック図の代表を示す。

［発明の詳細な説明］
図１は接続１０６と１０８とを介したデータ・マネージャ１０２とデータ・クライアント１０４との間の例示的なネットワーク・インターフェイスの代表を示す。データ・マネージャ１０２はウェブ・サーバまたはアクセス・ネットワーク（ＡＮ）のようなネットワーク要素を含んでもよい。データ・マネージャ１０２はモデム・プール・コントローラ（ＭＰＣ）１１０、モデム・プール・トランシーバ（ＭＰＴ）１１２、および／またはアクセス端末（ＡＴ）１１４のようなデータ源とデータ通信中であってもよい。データ・クライアント１０４はパーソナル・コンピュータ、ＨＤＲ分析ツール（ＨＡＴ）、またはそれ自身のデータの中にデータ・マネージャ１０２からのデータを組み込むもう１つのデータ・サーバのようなクライアント端末を含んでもよい。

１実施形態では、データ・マネージャ１０２とデータ・クライアント１０４との間のデータ通信は２つのプロトコル：データ制御用のデータ・マネージャ・プロトコル(ＤＭＰ)およびデータ伝送と記憶とのためのバイナリ・データ交換フォーマット（ＢＤＥＦ)、により制御されてもよい。ＤＭＰプロトコルは、出願中の特許申請において詳細に検討されるように、データ・マネージャ制御プロトコル（ＤＭＣＰ）とデータ・マネージャ発見プロトコル（ＤＭＤＰ）とを含んでもよい。

データ・マネージャ・プロトコル
ＤＭＰプロトコルは楽な実施とデバッギングのために設計される。設計のゴールは極小のコマンドとステートレスなサーバ接続とを有することを含む。すべてのことが直ちに行われる時には、１つの命令はいくつかのことを“極小に(atomically)”行い、そしてその命令が半分完了されたり、散在させられたり、または中断される機会はない。ステートレスなサーバは、どの以前の要求とも関係なく、各要求は別々のトランザクションとして取り扱う。これは、もしもクライアントがトランザクションの中間で消えれば、その蓄積を解放することが進行中かまたはそれを気にするコンピュータとの会話を扱うために記憶装置を割り当てる必要がないので、サーバの設計を単純にする。コマンドとレスポンスとは情報交換用の米国標準符号（ＡＳＣＩＩ）内にあってもよく、そしてそれらのフォーマットはマシン解析を実施することを容易にするように選ばれる。

データ・マネージャ制御プロトコル(ＤＭＣＰ)
データ・マネージャ１０２は、例えば、双方向接続１０６を介して、ＤＭＣＰコマンドを送受信するためのＤＭＣＰプロトコルをサポートしてもよい。双方向接続１０６はＴＣＰまたはユーザ・データグラム・プロトコル（ＵＤＰ）接続を含んでもよい。データ・マネージャ１０２はポート１８８０上にＤＭＣＰコマンドのためのＴＣＰ接続を使用してもよい。しかしながら、下に定義されたように、もしもデータ・マネージャ１０２がＤＭＤＰプロトコルをサポートするならば、それはまた他のポート上でＤＭＣＰプロトコルをサポートしてもよい。

バイナリ・データ交換フォーマット（ＢＤＥＦ）
統一データ交換および記憶フォーマットは、好都合に効率的な実施、他のネットワーク・コンポーネントとの互換性、および符号の再使用性に帰着する。そのようなデータ・フォーマットは実時間で起こるかもしれない大量のサイズ変更のデータ向きである。図１はネットワーク接続１０８を介して交換されたデータと、記憶ユニット１１６内に蓄積されたデータとが統一フォーマット、例えば、ＢＤＥＦを有する１例のネットワークを示す。データ・クライアント１０４はネットワーク接続１０８を介してデータ・マネージャ１０２からデータを受信し、そして接続１１８を介して記憶ユニット１１６にデータを送ることができる。１実施形態では、ネットワーク接続１０８を介したデータ交換フォーマットと記憶ユニット１１６内のデータ記憶フォーマットとは統一される。

1実施形態では、そのような統一フォーマットは総合フォーマットおよびレコード・フォーマットを含んでもよい。総合フォーマットはデータ記憶フォーマットを定義することができるファイル・フォーマットと、ネットワークを通してデータ交換フォーマットを定義することができるネットワーク・フォーマットとの両者として考察されてもよい。

図2は1実施形態に従って、統一データ・フォーマットのための1例のデータ構造を示す。ファイル２０２の総合フォーマットは、ヘッダ・セクション２０４、レコード・セクション２０６、およびテール・セクション２０８を含むことができる。１実施形態では、総合フォーマット２０２は１レコード・セクションのみを有することができる。レコード・セクション２０６内の１レコードのレコード・フォーマットもレコード・ヘッダ２１０、レコード・ボディ２１２、およびレコード・テール２１４を含むことができる。

図３はＢＤＥＦフォーマットのための１例の詳細な総合フォーマットを示す。列３０２〜３２２はヘッダ・セクション２０４に対応し、列３２４〜３３２はレコード・セクション２０６に対応し、そして列３３４〜３３６はテール・セクション２０８に対応する。これらの列の一部は下に記述される：
ＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＩＤ３０２は基本総合フォーマットを識別する。１実施形態では、基本総合フォーマットは基準バイナリ・レコード・フォーマット（ＧＢＲＦ）である。いずれかのファイル・ビューワまたはエディタは、基本総合フォーマット、例えば、ＧＢＲＦを決定するために、１ファイルの第１の４バイト、即ちＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＩＤ３０２を試験するために使用されることができる。図３に示されるように、もしもファイルがフォーマットされたＧＢＲＦファイルであれば、対応するＩＤ値はＧＢＲＦ用のＡＳＣＩＩキャラクタに設定されねばならない。

ＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＶＥＲＳＩＯＮ３０４はそのファイルが基礎を置く基本総合フォーマット、例えば、ＧＢＲＦの何版かを指定する。

ＲＥＣＯＲＤ ＦＯＲＭＡＴ ＴＹＰＥ３０６およびＲＥＣＯＲＤ ＦＯＲＭＡＴ ＶＥＲＳＩＯＮ３０８はそのレコード・フォーマット・タイプ、例えば、ＢＤＥＦ、およびそれの版、例えば、２をそれぞれ指定する。“０ｘ０００２”内のプレフィックス“０ｘ”
は２のヘクサデシマル表示を示す。

ＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＯＰＴＩＯＮＳ３１０はフォーマット・オプションを指定する。１実施形態では、２つの１６ビットはオプションのフィールドを指定してもよく、そして他のビットは将来のフォーマット・オプションのためにリザーブされ、即ち、０にセットされてもよい。

ＥＯＲ ＳＥＮＴＩＮＥＬ３１２およびＥＯＳ ＳＥＮＴＩＮＥＬ３１４フィールドは、どの標識値がレコードの終りおよびストリームの終りとしてそれぞれ使用されるかを指定する。ＥＯＲ ＳＥＮＴＩＮＥＬ３１２は１レコードの終りを示し、ＥＯＳ ＳＥＮＴＩＮＥＬ３１４は１総合フォーマットの終りを示す。これらの値は、そのフォーマットされたＧＢＲＦファイルが他のフォーマットされたＧＢＲＦファイルのレコードに容易にはめ込まれることができるように固定されない可能性があり、それによって帰納的なファイル構造を提供する。

ＴＯＴＡＬ ＲＥＣＯＲＤＳ ＳＩＺＥ３１６、ＦＩＲＳＴ ＲＥＣＯＲＤ ＢＹＴＥ３１８、およびＬＡＳＴ ＲＥＣＯＲＤ ＢＹＴＥ３２０フィールドは、そのレコードがバイト順ではないが、ラップされるストリームのために使用されることができる。レコード・ラッピングは、レコードが固定サイズのバッファ内に局部的にバッファされ、そしてそのバッファ・サイズよりも大量のデータが適当である状態で有用である。従って、ラップされたレコードはファイル、例えばＦＩＦＯキューに適合するであろう最後のレコードをまさに保存する。

ＥＮＤ ＯＦ ＨＥＡＤＥＲ３２２は、パーサがヘッダ情報を構文解析した後に単純なデータ統合性チェックとして使用されることができる。

ストリームの終りでＣＲＣフィールド３３４はアプリケーション・レベルのデータ統合性チェックを供給する。もしもそのファイルがラップされると、そのときＣＲＣは時刻順に計算される。データ・パーサはこの特徴をサポートしなければならないかもしれないが、しかしアプリケーション・ライタはそれを実施しないことのオプションを有してもよい。

ＥＮＤ ＯＦ ＳＴＲＥＡＭ３３６はもう１つのデータ統合性チェックを供給する。それは信頼性のないトランスポートをチェックするために、実時間トランスポートの終りを決定するために、およびＧＢＲＦ帰納的フォーマット内のデータ統合性チェックのために使用されてもよい。

実例１．
以下の例は、実施するのに１９ヘクサデシマル・バイト、例えば、“４７ ４２ ５２ ４６ ００ ４２ ４４ ４５ ４６ ００ ０１ ０２ ００ ００ ＦＡ ＣＥ ＤＥ ＡＤ Ｃ０ ＤＥ”を必要とする、オプション付きでないヘッダを示す。

図５を参照して、構成バイトは下記として定義される：
バイト０〜３はＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＩＤ３０２、例えば、ＧＢＲＦを定義 する
バイと４はＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＶＥＲＳＩＯＮ３０４を定義する
バイト５〜８はＲＥＣＯＲＤ ＦＯＲＭＡＴ ＴＹＰＥ３０６、例えば、ＢＤＥＦを定 義する
バイト９〜１０はＲＥＣＯＲＤ ＦＯＲＭＡＴ ＶＥＲＳＩＯＮ３０８を定義する
バイト１１〜１２はＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＯＰＴＩＯＮ３１０、例えば、オ プション無しを定義する
バイト１３〜１４および１５〜１６は、それぞれＥＯＲ ＳＥＮＴＩＮＥＬ３１２お よびＥＯＳ ＳＥＮＴＩＮＥＬ３１４を定義する
バイト１７〜１８はＥＮＤ ＯＦ ＨＥＡＤＥＲ３２２を定義する
イネーブルされたＣＲＣオプションを有する以外の同一ヘッダもまた１９ヘクサデシマル・バイト、例えば、“４７ ４２ ５２ ４６ ００ ４２ ４４ ４５ ４６ ００ ０１ ０２ ００ ０１ ＦＡ ＣＥ ＤＥ ＡＤ Ｃ０ ＤＥ”を必要とし、ここでバイト１１〜１２はＯＶＥＲＡＬＬ ＦＯＲＭＡＴ ＯＰＴＩＯＮＳ３１０、例えば、ＣＲＣが存在することを意味する、Ｂ０＝１を定義する。ＣＲＣオプション付きでないトレーラは２つのヘクサデシマル・バイト“ＤＥ ＡＤ”を必要とするかもしれない。

図４Ａおよび４Ｂは、１実施形態に従って、１例のＢＤＥＦレコード・フォーマットを示す。列４０２〜４３４はレコード・ヘッダ２１０に対応し、列４３６〜４４０はレコード・ボディ２１２に対応し、そして列４４４〜４４６はレコード・テール２１４に対応する。これらのフィールドの一部は下に記述される。

実施の形態を非常に単純にする、ＲＥＣ ＳＩＺＥ ＳＩＺＥ４０２は、ＲＥＣ ＳＩＺＥ４０４のために割り当てられるビット数を供給する。データ・パーサはＲＥＣ ＳＩＺＥ４０４を完成するのに何バイトが必要かを決定するために１バイトを早急に読み取ることができる。一度パーサが全ＲＥＣ ＳＩＺＥ４０４を読み取ってそれを復号すると、そのパーサはメモリを効率的に割り当てる。

ＲＥＣ ＳＩＺＥ ＳＩＺＥ４０２を使用することは１レコードをスキップすることを容易にする。レコードを書き込むアプリケーションはそのデータ・サイズを既に知っているかもしれないので、レコードの書込みもまた簡単になされる。しかしながら、もしもレコード・ライタが３２ビット・ワードの上位２ビットをハード・コードして、まさに小さい値としてさえ３０ビットのワード・サイズを使用するならば、アプリケーション・ライタは可変ＲＥＣ ＳＩＺＥデータを書き込む時に、ＲＥＣ ＳＩＺＥ ＳＩＺＥフィールド４０２に悩む必要はないかもしれない。従って、この中に開示されたレコード・フォーマットは最善に順応性があり、そして特別な実施コストを必要としないかもしれない。

ＥＮＤ ＯＦ ＲＥＣＯＲＤ４４４もまた、レコード・ライタが使用できる、総合フォーマット・ヘッダ・フィールドＥＯＲ ＳＥＮＴＩＮＥＬ３１２（図３）内に指定されることができる。

データ・マネージャ（制作者）とデータ・クライアント（消費者）との両者は、それらがあるＲＥＣ ＴＹＰＥ値を定義されてそれにマップされることができるため、種々のレコードＢＯＤＹフィールドについての定義を事前に知ることができる。ＢＯＤＹ定義もまたいくつかのプロトコルによりまたは蓄積された特別のレコードから決定されることができる。しかしながら、そのデータ消費者に明白に知られないＲＥＣＯＲＤ ＴＹＰＥ値は、まるでＢＯＤＹ定義がＢＯＤＹフィールドに使用できるいかに多くのビットを有する整数ワード・フィールドであったかのように扱われることができる。任意のサイズのワードとして扱われた未知のＲＥＣＯＲＤ ＴＹＰＥ値を有することにより、データ制作者は、それらが現存のデータ消費者で自動的に働くように新しいデータ・タイプを早急に定義して実施できる。

１実施形態では、ＢＤＥＦストリームは、このような時間を切り替えることができる名前および定義にするためにＲＥＣ ＴＹＰＥ値の組み合わせを省いて、第１のレコードとしてデータ・タイプの要約レコードを含むことができる。

実例２．
例示的な１実施形態では、データ・ソース、ＡＴ ＩＰ＝０ｘ１２３４５６７８を定義し、データ・ターゲットＲＥＣ ＴＹＰＥ＝０ｘ２、および記号０，１，２，および３から成る４バイトＢＯＤＹを定義する、ＴＩＭＥ＝0ｘ１２３４５６７８９ＡＢ、ＣＡＲＤ ＩＰ＝０ｘＡＢＣＤＥＦ０１のために、レコード・フォーマットは２２ヘクサデシマル・バイト、例えば、“１５ ０２ １１ ２３ ４５ ６７ ８９ ＡＢ ＡＢ ＣＤ ＥＦ ０１ １２ ３４ ５６ ７８ ３０ ３１ ３２ ３３ ＦＡ ＣＥ”を必要とするかもしれない。

図６を参照して、構成バイトおよび／またはビットは下に記述される：
バイト０の第１の２ビットはＲＥＣ ＳＩＺＥ ＳＩＺＥ４０２、例えば、０を定義す る
バイト０の最終の６ビットはＲＥＣ ＳＩＺＥ４０４、例えば、レコード・フォーマ ットの残りを定義するのに２１バイトが必要であることを指示して、６を定義する バイト１の第１のビットはＲＥＣ ＦＯＲＭＡＴ４０６、例えば、６を定義する
バイト１の第２のビットはＲＥＣ ＴＹＰＥ ＳＩＺＥ４０８、例えば、ＲＥＣ ＴＹ ＰＥ４１０を定義するのに６バイトが必要であることを指示して、０を定義する バイト１の最終の６ビットはＲＥＣ ＴＹＰＥ４１０、例えば、２を定義する
バイト２〜７はＤＡＴＡ ＴＩＭＥ ＳＴＡＭＰ４１４を定義する
バイト８〜１１はデータ・ソースＩＰアドレスを定義して、ＤＡＴＡ ＣＡＲＤ ＩＰ ４１６を定義する
バイト１２〜１５はデータ・ターゲットＩＰアドレスを定義して、ＤＡＴＡ ＡＴ Ｉ Ｐ４１８を定義する
バイト１６〜１９はデータ記号を定義する
バイト２０〜２１はＥＮＤ ＯＦ ＲＥＣＯＲＤ４４６を定義する
セル電話機またはパーソナル・ディジタル・アシスタント（ＰＤＡ）のようなデータ・クライアント１０４について、あるいは図１のシステム内で動作しているデータ・マネージャ１０２についての例示的な１実施形態が図７に図示される。図７におけるシステムはデータを送受信するためのアンテナ７０２を含む。アンテナ７０２は受信器パスを送信器パスから分離するためのデュプレクサ７０４と連結される。デュプレクサ７０４は、受信器パスを形成して、受信器回路７０６と連結され、そして送信器パスを形成して、増幅器７０８および送信器回路７１０と連結される。増幅器７０８はさらに、増幅器７０８を制御するパワー制御調整ユニット７１２と連結される。増幅器７０８は送信器回路７１０から送信信号を受信する。アンテナ７０２を介して受信された信号は、閉ループ・パワー制御スキームを実施できるパワー制御ユニット７１２に供給される。パワー制御ユニット７１２は通信パス７１４に連結される。通信パス７１４は図７内の他のモジュール間の共通接続を供給する。通信パス７１４はさらにメモリ・ユニット７１６に連結される。メモリ７１６はデータ・クライアント１０４またはデータ・マネージャ１０２に適用できる種々の動作および機能のためのコンピュータ可読命令を蓄積する。プロセッサ７１８はメモリ７１４に蓄積された命令を実行する。

述語“典型的な”は“一例、事例、または実例として機能すること”を意味すべくこの中で独占的に使用されている。ここで“典型的な”として記述されたいずれかの実施形態は必ずしも他の実施形態以上に好ましいとか有利であると解釈されるべきではない。

この分野の技術者は、情報および信号がいろいろな異なるテクノロジーおよびテクニックのいずれかを使用して表され得ることを理解するであろう。例えば、上記説明の全体を通して参照される可能性があるデータ、指示、命令、情報、信号、ビット、記号、およびチップは、電圧、電流、電磁波、磁界または粒子、光学界あるいは粒子、あるいはそれのいずれかの組合わせにより表されることができる。

技術者は、この中に開示された実施形態に関して記述された種々の実例となる論理ブロック、モジュール、回路、およびアルゴリズム・ステップは電子ハードウェア、コンピュータ・ソフトウェア、または両者の組合わせとして実施され得ることをさらに認識するであろう。ハードウェアおよびソフトウェアのこの互換性を明確に説明するために、種々の実例となるコンポーネント、ブロック、モジュール、回路、およびステップは、一般にそれらの機能性の表現で上述された。そのような機能性がハードウェアまたはソフトウェアとして実施されるかどうかはシステム全体に課された特定のアプリケーションと設計の制約とによる。熟練技工は各特定のアプリケーションについて異なる方法で記述された機能性を実施できるが、しかしそのような実施の決定が本発明の範囲からの逸脱を引き起こすと理解されてはならない。

この中に開示された実施形態に関して記述された種々の実例となる論理ブロック、モジュール、および回路は、汎用プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）または他のプログラマブルな論理装置、ディスクリート・ゲートかトランジスタ論理、ディスクリート・ハードウェア・コンポーネント、あるいはこの中に記述された機能を実行するように設計されたそれのいずれかの組合わせで実施または実行されることができる。汎用プロセッサはマイクロプロセッサであってもよいが、しかし代替案では、プロセッサはいずれか従前のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた計算装置、例えば、ＤＳＰとマイクロプロセッサとの組合わせ、複数のマイクロプロセッサ、ＤＳＰコアとともに１つまたはそれ以上のマイクロプロセッサ、あるいはいずれか他のそのような構成として実施されてもよい。

この中に開示された実施形態に関して記述された方法のステップまたはアルゴリズムはハードウェアで、プロセッサにより実行されるソフトウェア・モジュールで、またはこの２つの組合わせで直接具体化されることができる。ソフトウェア・モジュールはＲＡＭメモリ、フラッシュ・メモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、着脱可能形ディスク、ＣＤ―ＲＯＭ、あるいはこの分野において既知のいずれか他の形式の蓄積媒体に属してもよい。典型的な蓄積媒体はプロセッサに連結され、そのようなプロセッサはこの蓄積媒体から情報を読み取り、それに情報を書き込むことができる。代替案では、蓄積媒体はプロセッサに一体化されることができる。プロセッサと蓄積媒体とは１つのＡＳＩＣ内に存在してもよい。ＡＳＩＣはユーザ端末内に存在してもよい。代替案では、プロセッサと蓄積媒体とはディスクリート・コンポーネントとして１つのユーザ端末内に存在することができる。

開示された実施形態の前の説明は、この分野のいかなる技術者も本発明を製作または使用することを可能とする。これらの実施形態へのいろいろな変更は、この分野の技術者にはたやすく明白であるだろうし、この中に定義された包括的な原理は本発明の精神および範囲を逸脱すること無しに他の実施形態に適用されることができる。したがって、本発明はこの中に示された実施形態に限定されるつもりはなく、しかしこの中に開示された原理および新規な特徴と矛盾しない最も広い範囲が許容されるべきである。

Claims (40)

1. 下記を具備する、ネットワーク内でデータを交換するための装置：
   ネットワーク接続を介してデータ・プロデューサからデータを受信するように構成された受信器；および
   記憶ユニットに該データを送るように構成された送信器、
   ここにおいて該ネットワーク接続を介して受信された該データおよび該記憶ユニット内に蓄積されたデータは同一フォーマットを有する。
2. 該データはレコード・セクションを含む請求項１記載の装置。
3. 該データはヘッダ・セクション、レコード・セクション、およびテール・セクションを含む請求項１記載の装置。
4. 該レコード・セクション内のレコードはレコード・ヘッダ、レコード・ボディ、およびレコード・テールを含む請求項３記載の装置。
5. 該ネットワークは無線ネットワークを含む請求項１記載の装置。
6. 該ネットワークは光ネットワークを含む請求項１記載の装置。
7. 下記を具備する、ネットワーク内でデータをフォーマットするための方法：
   該データがデータ交換およびデータ記憶の両者に適用されるように、
   該データのためのヘッダ・セクションを供給する；
   該データのためのレコード・セクションを供給する；および
   該データのためのテール・セクションを供給する。
8. 該レコード・セクション内のレコードとして、レコード・ヘッダ、レコード・ボディ、およびレコード・テールをさらに供給する請求項7の方法。
9. 該データのためのフォーマットを識別する情報をさらに供給する請求項７記載の方法。
10. 該データのためのバージョンを識別する情報をさらに供給する請求項７記載の方法。
11. レコード・フォーマット・タイプを識別する情報をさらに供給する請求項７記載の方法。
12. レコード・フォーマット・バージョンを識別する情報をさらに供給する請求項７記載の方法。
13. 該データのためのオプションを識別する情報をさらに供給する請求項７記載の方法。
14. 該データの該終りを識別する情報をさらに供給する請求項７記載の方法。
15. 該レコード・セクションについてのサイズを識別する情報をさらに供給する請求項７記載の方法。
16. 該レコード・セクション内の該第1のレコードを識別する情報をさらに供給する請求項７記載の方法。
17. 該レコード・セクション内の該最終レコードを識別する情報をさらに供給する請求項７記載の方法。
18. 該ヘッダ・セクションの該終りを識別する情報をさらに供給する請求項７記載の方法。
19. ＣＲＣについての情報をさらに供給する請求項７記載の方法。
20. 該レコード・セクション内のレコードのサイズを識別する情報をさらに供給する請求項７記載の方法。
21. 該レコード・セクション内のレコードのサイズをさらに供給する請求項７記載の方法。
22. 該レコード・セクション内のレコードのためのフォーマットを識別する情報をさらに供給する請求項７記載の方法。
23. 該レコード・セクション内のレコード・タイプのサイズを識別する情報をさらに供給する請求項７記載の方法。
24. 該レコード・セクション内のレコードのレコード・タイプをさらに供給する請求項２３記載の方法。
25. 該データのためのフォーマットを識別する情報をさらに供給する請求項７記載の方法。
26. 該データのためのタイム・スタンプをさらに供給する請求項７記載の方法。
27. 該ネットワーク内の該データ・サブシステムのソースを識別する情報をさらに供給する請求項７記載の方法。
28. 該ネットワーク内の該データ・アクセス端末のための目標を識別する情報をさらに供給する請求項７記載の方法。
29. 該ネットワーク内のサブシステム内のセクタを識別する情報をさらに供給する請求項７記載の方法。
30. 該レコード・セクション内のレコードのためのＣＲＣを識別する情報をさらに供給する請求項７記載の方法。
31. 該レコード・セクション内のレコードの該終りを識別する情報をさらに供給する請求項７記載の方法。
32. 下記を具備する、ネットワーク内でデータをフォーマットするための装置：
    該データがデータ交換およびデータ記憶の両者に適用されるように、
    ヘッダ・セクションを供給するための手段；
    レコード・セクションを供給するための手段；および
    テール・セクションを供給するための手段。
33. ネットワーク内でデータをフォーマットするための方法を具体化するコンピュータ可読媒体、該方法は下記を具備する：
    該データがデータ交換およびデータ記憶の両者に適用されるように、
    ヘッダ・セクションを供給する；
    レコード・セクションを供給する；および
    テール・セクションを供給する。
34. 下記を具備する、ネットワーク内でデータをフォーマットするための装置：
    メモリ・ユニット；
    該メモリ・ユニットと通信的に連結されたディジタル信号プロセッサ（ＤＳＰ）、該ＤＳＰは下記が可能である；
    該データがデータ交換およびデータ記憶の両者に適用されるように、
    ヘッダ・セクションを供給する；
    レコード・セクションを供給する；および
    テール・セクションを供給する。
35. 下記を具備する、データ・クライアントおよびデータ・マネージャを含むネットワーク内でデータを処理するための方法：
    該データ・クライアントで、ネットワーク接続を介して該データ・マネージャからデータを受信する；および
    記憶ユニットに該データを蓄積する、
    ここにおいて該ネットワーク接続を介して受信された該データおよび該記憶ユニットに蓄積された該データは同一フォーマットを有する。
36. データ・クライアントおよびデータ・マネージャを含むネットワーク内でデータを処理するための方法を具体化するコンピュータ可読媒体、該方法は下記を具備する：
    該データ・クライアントで、ネットワーク接続を介して該データ・マネージャからデータを受信する；および
    記憶ユニット内にデータを蓄積する、
    ここにおいて該ネットワーク接続を介して受信された該データおよび該記憶ユニット内に蓄積された該データは同一フォーマットを有する。
37. 下記を具備する、データ・クライアントおよびデータ・マネージャを含むデータ処理システムのネットワーク内でデータを処理するための装置：
    該データ・クライアントで、ネットワーク接続を介して該データ・マネージャからデータを受信するための手段；および
    記憶ユニット内にデータを蓄積するための手段、
    ここにおいて該ネットワーク接続を介して受信された該データおよび該記憶ユニット内に蓄積された該データは同一フォーマットを有する。
38. 下記を具備する、データ・クライアントおよびデータ・マネージャを含むネットワーク内でデータを処理するための装置：
    メモリ・ユニット；および
    該メモリ・ユニットと通信的に連結されたディジタル信号プロセッサ（ＤＳＰ）、該ＤＳＰユニットは下記が可能である；
    該データ・クライアントで、ネットワーク接続を介して該データ・マネージャからデータを受信する；および
    記憶ユニットに該データを蓄積する、
    ここにおいて該ネットワーク接続を介して受信された該データおよび該記憶ユニット内に蓄積された該データは同一フォーマットを有する
39. ネットワーク内でデータをフォーマットするためのデータ構造、該データ構造は下記を具備する：
    該データがデータ交換およびデータ記憶の両者に適用されるように、
    該データのためのヘッダ・セクション；
    該データのためのレコード・セクション；および
    該データのためのテール・セクション。
40. 該レコード・セクションのためのレコード・ヘッダ、レコード・ボディ、およびレコード・テールをさらに含む請求項３９のデータ構造。

Images