パケット交換ネットワークを通じて、電子デバイスまたはシステムから、1つまたは複数のデータオブジェクトを配信する方法であって、前記1つまたは複数のデータオブジェクトのソースデータが、前記ソースデータがパケット中の符号化シンボルから少なくともおおよそ復元可能であるように、前記符号化シンボルによって表される、方法において、a配信されるべき前記1つまたは複数のデータオブジェクトの各データオブジェクトについて、オクテット単位での前記データオブジェクトのサイズF、前記データオブジェクトを表すのに使われる各シンボルを表すために使われるオクテットの数T、および、前記データオブジェクトの配信のための分割先のソースブロックの数Zを含む、オブジェクト送信情報を特定するステップと、b前記1つまたは複数のデータオブジェクトのための複数のパケットの各パケットに対して、汎用オブジェクトシンボル識別子を生成するステップであって、所与のパケットに対する前記UOSIが、可能なUOSI値のセットから選択され、前記セットが、前記所与のパケットにおいて表される各データオブジェクトのための前記OTIの値とは独立である、ステップと、c前記1つまたは複数のデータオブジェクトを表す前記ソースデータを含む、複数のソースシンボルから複数の符号化シンボルを生成するステップであって、前記ソースシンボルの各々が前記ソースデータ中の位置を有し、所与のデータオブジェクトのための所与のパケットの符号化シンボルを生成するステップが、1使用すべきFEC符号化処理を決定するステップと、2前記所与のパケットの前記UOSIおよび前記所与のデータオブジェクトの前記OTIから、ソースブロック番号および符号化シンボル識別子を決定するステップと、3前記符号化シンボルについて、前記FEC符号化処理、前記符号化シンボルの前記SBNから決定された前記Z個のソースブロックのうちの1つのソースブロックからの1つまたは複数のソースシンボル、および前記符号化シンボルの前記ESIに少なくとも基づいて、サイズTの符号化シンボル値を生成するステップとを含む、ステップと、dステップaで扱われた前記データオブジェクトの各々の前記OTIを表すものを含むOTIフィールドを生成するステップであって、前記OTIフィールドが、前記OTIフィールドによって表されるデータオブジェクトの数であるdも含む、ステップと、e前記1つまたは複数のデータオブジェクトのための前記複数のパケットを生成するステップであって、前記複数のパケットの各パケットが、前記パケットの前記UOSIと、前記データオブジェクトの前記OTIおよび前記パケットの前記UOSIを使って前記データオブジェクトから生成された、前記パケット中で表される各データオブジェクトの1つまたは複数の符号化シンボルとを含む、ステップと、f前記パケット交換ネットワークによって使用可能な形態で、前記OTIフィールドおよび前記複数のパケットを出力するステップとを含む、方法。各データオブジェクトの前記OTIが、前記データオブジェクトの各ソースオブジェクトの送信のための分割先であるサブブロックの数Nも含む、請求項1に記載の方法。SBNをUOSImoduloZに等しく設定するステップと、ESIを、UOSIをZで除算したもの以下の最大の整数に等しく設定するステップとをさらに含む、請求項1に記載の方法。パケット交換ネットワークを通じて、電子デバイスまたはシステムから、1つまたは複数のデータオブジェクトを配信する方法であって、前記1つまたは複数のデータオブジェクトのソースデータが、前記ソースデータがパケット中の符号化シンボルから少なくともおおよそ復元可能であるように、前記符号化シンボルによって表される、方法において、a配信されるべき前記1つまたは複数のデータオブジェクトの各データオブジェクトについて、オブジェクト送信情報を特定するステップであって、前記1つまたは複数のデータオブジェクトが2個以上のデータオブジェクトを含む場合、1つの配信の中の2個のデータオブジェクトのOTIが異なり得る、ステップと、b前記1つまたは複数のデータオブジェクトのための複数のパケットの各パケットに対して、汎用オブジェクトシンボル識別子を生成するステップであって、所与のパケットに対する前記UOSIが、可能なUOSI値のセットから選択され、前記セットが、前記所与のパケットにおいて表される各データオブジェクトのための前記OTIの値とは独立である、ステップと、c前記1つまたは複数のデータオブジェクトを表す前記ソースデータを含む、複数のソースシンボルから複数の符号化シンボルを生成するステップであって、前記ソースシンボルの各々が前記ソースデータ中の位置を有し、所与のデータオブジェクトのための所与のパケットの符号化シンボルを生成するステップが、前記所与のパケットの前記UOSI、前記所与のデータオブジェクトの前記OTI、および1つまたは複数のソースシンボル値から前記符号化シンボルの値を決定するステップを含む、ステップと、d配信されるべき前記1つまたは複数のデータオブジェクトのための前記複数のパケットを生成するステップであって、前記複数のパケットの各パケットが、前記パケットの前記UOSIと、前記データオブジェクトの前記OTIおよび前記パケットの前記UOSIを使って前記データオブジェクトから生成された、前記パケット中で表される各データオブジェクトの1つまたは複数の符号化シンボルとを含む、ステップと、e前記パケット交換ネットワークによって使用可能な形態で、少なくとも前記複数のパケットを出力するステップとを含む、方法。シンボルが、データオブジェクトのソースシンボルに相当するか、それとも、1つまたは複数のソースシンボルの復元のためのFEC復号処理で使用可能なFEC修復シンボルに相当するかを、受信機が判定できるように、シンボルを標識するステップをさらに含み、前記受信機が、前記シンボルを含む前記パケットの前記UOSIを、データオブジェクト中のシンボルの数を表す値と比較することによって、前記判定を実行する、請求項4に記載の方法。前記UOSIが負ではない整数であり、各データオブジェクトの前記OTIが、前記データオブジェクトのオクテット単位のサイズ、前記データオブジェクト表すために使われる各シンボルを表すのに使われるオクテットの数、前記データオブジェクトの配信のための分割先であるソースブロックの数、ソースブロックの分割先のサブブロックの数、および、好ましいメモリの整列に対応する整列係数を含む、請求項4に記載の方法。前記所与のデータオブジェクトの前記OTIが基本UOSI値を含み、前記所与のパケットの前記UOSI、前記所与のデータオブジェクトの前記OTI、および1つまたは複数のソースシンボル値から、前記符号化シンボルの値を決定するステップが、前記符号化シンボルの値を決定する前に、前記基本UOSI値によって、前記所与のパケットの前記UOSIを調整して、それによって前記UOSIのオフセット値を可能にするステップを含む、請求項4に記載の方法。前記符号化シンボルの値を決定するステップが、前方誤り訂正を使うステップを含み、異なるレベルのFEC保護が、異なるデータオブジェクトに対して可能にされ、FEC保護のレベルが、異なる各データオブジェクトの前記OTIから決定される、請求項4に記載の方法。前記1つまたは複数のデータオブジェクトが、単一のデータオブジェクトを含み、OTIの単一のセットが、前記1つまたは複数のデータオブジェクトの各符号化シンボルを生成するために使われる、請求項4に記載の方法。前記1つまたは複数のデータオブジェクトが、複数のデータオブジェクトを含み、OTIフィールドが、データオブジェクトごとに1つの複数のOTIサブフィールドと、前記複数のデータオブジェクト中のデータオブジェクトの数を示すカウントサブフィールドとを含み、前記OTIサブフィールドのすべてが同一とは限らず、あるOTIサブフィールドが、少なくとも1つの他のOTIサブフィールドとは独立に生成される、請求項4に記載の方法。各OTIサブフィールドが、そのデータオブジェクトに対して、前記データオブジェクトのサイズ、前記データオブジェクトの転送のための分割先であるソースブロックの数、ソースブロック当たりの使われるサブブロックの数、使われるシンボルサイズ、および整列係数を含み、少なくとも2つのデータオブジェクトに対するソースブロックの前記数が異なる、請求項10に記載の方法。前記1つまたは複数のデータオブジェクトが、少なくとも第1のデータオブジェクトおよび第2のデータオブジェクトを含み、前記配信が、少なくとも2つの別々のパケットシーケンスへと編成され、前記第1のデータオブジェクトの符号化シンボルが、第1のパケットシーケンスのパケットと、第2のパケットシーケンスのパケットとに現れ、前記第2のデータオブジェクトの符号化シンボルが、前記第1のパケットシーケンスのパケットには現れるが、前記第2のパケットシーケンスのパケットには現れない、請求項4に記載の方法。前記1つまたは複数のデータオブジェクトの各々が、データをファイルとして記憶するコンピュータ可読媒体に記憶された異なるファイルを含む、請求項4に記載の方法。前記1つまたは複数のデータオブジェクトの少なくとも1つが、データをファイルとして記憶するコンピュータ可読媒体に記憶された異なるファイルの一部を含む、請求項4に記載の方法。電子デバイスまたはシステムを用いて、パケット交換ネットワークを通じて受信される1つまたは複数のデータオブジェクトを受信して復号する方法であって、十分な符号化シンボルが受信される場合には、受信される符号化シンボルが、前記1つまたは複数のデータオブジェクトを表すソースシンボルへと復号される、方法において、a配信される前記1つまたは複数のデータオブジェクトの各データオブジェクトについて、オブジェクト送信情報を特定するステップであって、前記1つまたは複数のデータオブジェクトが2個以上のデータオブジェクトを含む場合、1つの配信の中の2個のデータオブジェクトのOTIが異なり得る、ステップと、b復号において使われるべき各符号化シンボルについて、前記符号化シンボルによって自身のソースシンボルが符号化されるデータオブジェクト、符号化シンボルの値、および、前記符号化シンボルを含むパケットの汎用オブジェクトシンボル識別子を決定するステップと、c復号において使われるべき各符号化シンボルについて、復号のために使われる復号パラメータを決定するステップであって、前記符号化シンボルおよび前記対応するデータオブジェクトのOTIを含む前記パケットの前記UOSIを使って、前記復号パラメータを決定する、ステップと、d符号化シンボルおよびステップcで決定された復号パラメータを使って、前記符号化シンボルを、データオブジェクトを表す復元されたソースシンボルへと復号するステップと、e前記復元されたソースシンボルを、コンピュータ可読の形態で出力するステップとを含む、方法。前記受信された符号化シンボルとともに前記OTIを受信するステップをさらに含む、請求項15に記載の方法。前記復号パラメータが、ソースブロック番号および符号化シンボル識別子を含み、前記方法が、UOSImoduloと等しく、前記ソースブロックの数を設定するステップと、使用されるソースブロックの前記数によってUOSIを除算したもの以下の最大の整数と等しく、前記符号化シンボル識別子を設定するステップとをさらに含む、請求項15に記載の方法。前記符号化シンボルが、ソースシンボルに相当するか、それとも、1つまたは複数のソースシンボルの復元のためのFEC復号処理で使用可能な前方誤り訂正修復シンボルに相当するかを、複数の前記符号化シンボルの各々について判定するステップをさらに含み、受信機が、前記符号化シンボルを含む前記パケットの前記UOSIを、データオブジェクト中のシンボルの数を表す値と比較することによって、前記判定を実行する、請求項15に記載の方法。前記UOSIが負ではない整数であり、複数のデータオブジェクトの各々の前記OTIが、各データオブジェクトのオクテット単位のサイズ、各データオブジェクト表すために使われる各シンボルを表すのに使われるオクテットの数、各データオブジェクトの配信のための分割先であるソースブロックの数、ソースブロックの分割先のサブブロックの数、および、好ましいメモリの整列に対応する整列係数を含み、OTIの値が少なくとも2つのデータオブジェクトで異なり、異なるレベルの前方誤り訂正が、少なくとも2つのデータオブジェクトに対して使われる、請求項15に記載の方法。電子デバイスまたはシステムを用いて、パケット交換ネットワークを通じて受信される1つまたは複数のデータオブジェクトを受信して復号する方法であって、十分な符号化シンボルが受信される場合には、受信される符号化シンボルが、前記1つまたは複数のデータオブジェクトを表すソースシンボルへと復号される、方法において、a各データオブジェクトのための符号化シンボルを含む、1つまたは複数のパケットを受信するステップと、bある数の追加のシンボルが所望のデータオブジェクトの復元に必要であると、判定するステップと、c複数の符号化シンボルファイル順序から、ある符号化シンボルファイル順序を選択して、前記数の追加のシンボルを要求するのに必要なバイト範囲の指定が、別の符号化シンボルファイル順序が選択された場合に必要なバイト範囲の指定よりも狭くなるようにするステップと、d前記所望のデータオブジェクトの復元に必要な、少なくとも前記数の追加のシンボルを受信するために行うべき、1つまたは複数のバイト要求を決定するステップであって、前記選択された符号化シンボルファイル順序に基づく、ステップと、e前記選択された符号化シンボルファイル順序をサービスするように構成されたハイパーテキスト転送プロトコルサーバへ、前記1つまたは複数のバイト要求を送信するステップとを含む、方法。符号化シンボルファイル順序を選択するステップが、前記受信された1つまたは複数のパケットの転送の種類に基づいて、前記符号化シンボルファイル順序を選択するステップを含む、請求項20に記載の方法。パケット交換ネットワークを通じて、電子デバイスまたはシステムから、1つまたは複数のデータオブジェクトを配信する方法であって、前記1つまたは複数のデータオブジェクトのソースデータが、前記ソースデータがパケット中の符号化シンボルから少なくともおおよそ復元可能であるように、前記符号化シンボルによって表され、aファイル要求およびバイト範囲要求に応答し、ファイルおよびバイト範囲をサービスする、ハイパーテキスト転送プロトコルサーバを構成するステップと、b使用される前方誤り訂正に基づいて要求パターンを決定するステップと、c前記バイト範囲要求に応答するために使われる元順序HTTPファイルの順序を変えるステップと、d前記順序を変えられたHTTPファイルへのアクセス権を、前記HTTPサーバに与えるステップとを含み、使用される前記FECに基づく予想される要求が、前記HTTPサーバが前記元順序HTTPファイルへのアクセス権を有するが前記順序を変えられたHTTPファイルへのアクセス権を有さない場合に要求されるバイト範囲の指定よりも狭い、バイト範囲の指定を要求するように、前記順序の変更が行われる、方法。前記使われるFECが、データオブジェクトのソースブロックを複数のサブブロックへと分割し、前記ソースブロックがソースシンボルを含み、前記順序を変えられたHTTPファイルが、連続的なソースブロックの順序であり、ソースブロック内で、ソースシンボルの順序である、請求項22に記載の方法。前記使われるFECが、複数のソースブロックを交互の順序で使い、データオブジェクトのソースブロックを複数のサブブロックへと分割し、前記ソースブロックがソースシンボルを含み、前記順序を変えられたHTTPファイルが、ソースブロックの交互の順序であり、ソースブロック内で、ソースシンボルの順序である、請求項22に記載の方法。LubyIは、計算、メモリ、帯域幅を効率的に使用してエラー訂正に対処するための、連鎖反応符号のような符号の使用を説明する。連鎖反応エンコーダによって生成される符号化シンボルの1つの特性は、十分な符号化シンボルが受信されるとすぐに、受信機が元のファイルを復元できるということである。具体的には、元のK個のソースシンボルを高い確率で復元するために、受信機は約KA個の符号化シンボルを必要とする。所与の状況での絶対的な受信オーバーヘッドは値Aによって表され、相対的な受信オーバーヘッドは比AKとして計算され得る。絶対的な受信オーバーヘッドは、理論的な最小量のデータである情報に加えて、どれだけの余剰なデータを受信する必要があるかの基準であり、これはデコーダの信頼性に依存することがあり、ソースシンボルの数Kの関数として変化し得る。同様に、相対受信オーバーヘッドAKは、復元されているソースデータのサイズに対する、理論的な最小量のデータである情報に加えて受信する必要がある余剰なデータの量の基準であり、これもデコーダの信頼性に依存することがあり、ソースシンボルの数Kの関数として変化し得る。連鎖反応符号は、パケットベースのネットワークを通じた通信には非常に有用である。しかし、連鎖反応符号は時々かなり計算集約的であり得る。ソースシンボルが、連鎖反応または別のレートレス符号を使って符号化する動的エンコーダの前に、静的エンコーダを使って符号化される場合、デコーダは、より頻繁に、またはより簡単に復号できる可能性がある。そのようなデコーダは、たとえばShokrollahiIに示されている。そこに示されている例では、ソースシンボルは、符号化シンボルである出力シンボルを生成する動的エンコーダに対する入力シンボルである、出力シンボルを生成する静的エンコーダに対する入力シンボルであり、動的エンコーダは、入力シンボルの数に対して一定の比率ではない量の多数の出力シンボルを生成できる、レートレスエンコーダである。静的エンコーダは、2つ以上のレート一定のエンコーダを含み得る。たとえば、静的エンコーダは、ハミングエンコーダ、低密度パリティ検査エンコーダ、高密度パリティ検査エンコーダなどを含み得る。一部のシンボルが受信されたシンボルからデコーダにおいて復元されると、そうした復元されたシンボルを使ってさらなるシンボルを復元できる可能性があり、そのさらなるシンボルが、より多くのシンボルを回復するために使われ得るという特性を、連鎖反応符号は有する。好ましくは、所望のシンボルのすべてが、受信されたシンボルの貯えを使い切る前に回復されるように、デコーダにおいて起きるシンボルの連鎖反応は続き得る。好ましいことに、連鎖反応による符号化および復号の実行の、計算的な複雑さは低い。デコーダにおける復元処理は、どのシンボルが受信されたかを判定することと、元の入力シンボルを受信された符号化シンボルへと対応付ける行列を生成することと、その逆行列を求めて、逆行列と受信された符号化シンボルのベクトルとの行列の乗算を実行することとを伴い得る。通常のシステムでは、この総当たり式の実装形態は、過度の計算能力およびメモリ要件を費やし得る。当然、受信された符号化シンボルのある特定のセットに対しては、元の入力シンボルのすべてを復元するのが不可能であることがあり、それが可能である場合でも、結果を計算するのに非常に多くの計算能力を費やし得る。前方誤り訂正オブジェクト送信情報またはFECOTIFECOTIに基づいて、受信機は受信し、受信機は、ファイル転送のソースブロックおよびサブブロック構造を決定することができる。本明細書の図1で示されるように、RaptorRFC5053およびRaptorQSpecでは、FECペイロードIDはであり、RaptorRFC5053ではソースブロック番号は16ビットであり符号化シンボルIDは16ビットであり、RaptorQSpecではSBNは8ビットでありESIは24ビットである。このFECペイロードIDフォーマットの1つの欠点は、SBNおよびESIへ割り当てるべきFECペイロードIDのビットの数を事前に決定しなければならず、すべてのファイル配信パラメータに対して妥当になる適切な組合せを決定するのが難しいことがある、ということである。たとえば、RaptorRFC5053を使う場合、利用可能なESIが21665536個のみであることは一部の状況では制約となり得る。それは、一部の場合には、8192個のソースシンボルを有するソースブロックが存在することがあるので、符号化シンボルの数は8以上の倍数に限られ、この場合、使われ得る可能な符号化レートは、18よりも小さくはならないように制限されるからである。この例では、21665536個の利用可能なソースブロックは、これまで使われてきた利用可能なソースブロックよりも多い可能性があり、たとえば、各々が1024オクテットの8192個のソースシンボルでは、サポートされ得るファイルのサイズは524GBであり、これは多くの用途において、必要な大きさよりも2桁大きいということがあり得る。別の例として、RaptorQSpecを使う場合、利用可能なSBNが28256個のみであることは一部の状況では制約となり得る。それは、4GBのファイルでは、各ソースブロックは8MBに制限され、ソースブロックの数が256に制限され、そしてファイルサイズが2GBに制限される。この例では、利用可能な22416777216個の符号化シンボルは、これまで使われてきた符号化シンボルよりも多く、たとえば8192個のソースシンボルでは利用可能な符号化シンボルの数は2048倍大きく、これは一部の用途では決して必要になり得ない、ということがあり得る。別の望ましい特性は、不均一誤り保護とも呼ばれることもある、ファイルの異なる部分の間での優先順位を付けられた符号化送信の能力を提供することである。たとえば、ファイルの最初の10を、残りの90よりも強力に、パケット喪失に対して保護するのが望ましいことがある。たとえば、LDPCExtensionsは、LDPCRFC5170がUEPをサポートするためにどのように拡張され得るかを説明する。この場合、実際のFEC符号自体が、ファイルの異なる部分に対して異なるレベルのパリティ保護を提供するように、修正される。しかし、この手法には欠点がある。たとえば、FEC符号自体の実装および検査が複雑になるので、UEPを実現するためにFEC符号自体を修正しなければならないのは望ましくない。さらに、LDPCExtensionsの図6で示される結果のように、ファイルの異なる部分に対して提供される、パケット喪失に対する弾力性の面でのそのような手法により得られる性能は、理想からはかけ離れている。UEPファイル配信能力を提供する1つの方法は、PETおよびPETPatentで説明されるように、優先順位およびサイズに従って、ファイルの異なる部分に対して、各パケットの異なる部分を割り当てることである。しかし、問題は、ファイルの異なる各部分がファイルの他の部分とは独立にソースブロックおよびサブブロックに分割され、たとえば、ファイルの各部分の少量のメモリの復号をサポートし、さらに同時に、ファイルの各部分のためのシンボルが各パケット内に含まれていると受信機が判定できるようにする各パケット内のFECペイロードIDを、各パケット内に提供できるように、そのようなUEPの方法をどのように組み込むかである。このことは、フォーマットのFECペイロードIDを使って対応するのは非常に難しい。それは、ファイルの各部分について、ファイルの第1の部分に対するパケット中のシンボルの対応するSBNおよびESIは、ファイルの第2の部分に対するパケット中のシンボルのSBNおよびESIとは異なり得るからである。HTTP修復手法ブロードキャストマルチキャストファイル配信のための3GPPMBMS規格TS26346において、修復要求が行われる方法は、たとえば、RaptorRFC5053で規定される、すなわち、ソースブロック番号および符号化シンボル識別子を規定することによって規定される、FECペイロードIDを使うことである。修復要求に応答するサーバが、ブロードキャストマルチキャストファイル配信において使われるファイル配信構造を決定するようにそのサーバに要求する特別な方法を有する場合、すなわち、そうしたサーバが、ソースブロックおよびサブブロックの構造とともにシンボルサイズTを知っていることを必要とする、ファイルのどの部分が要求されたSBNおよびESIによって参照されるかの解釈を行うように要求される場合には、この方法は合理的である。一方、広大な地理的領域にわたって分散する数百万個のブロードキャストマルチキャスト受信機が存在することがあり、専用の応答サーバの配備を必要とすることは、設備投資と運用の両方の観点において、高価であるとともに煩わしい。広範に配備されているのは、たとえばウェブページ、ビデオストリーミングなどのインターネット配信をサポートする、標準的なHTTPウェブサーバおよびウェブキャッシュである。望ましいのは、標準的なHTTPウェブサーバおよびウェブキャッシュを、ブロードキャストマルチキャスト応答サーバとして使用するのをサポートする方法である。ファイル配信の方法および装置の実施形態において、汎用ファイルシンボル識別子または汎用オブジェクトシンボル識別子が、パケットに含まれる符号化シンボルを特定するのに必要なパケット内の構造を特定するためにパケットと関連付けられる。そのように使われると、UFSIUOSIは、不均一誤り保護を含めて、FECおよびファイルオブジェクト配信の改善された処理を可能にし、配信されたデータのすべての部分が、FEC保護および一括オブジェクト配信に関して同じレベルにあるとは限らず、複数のオブジェクトを、別々に処理する場合よりも効率的に処理することができる。以下の発明を実施するための形態は、添付の図面とともに、本発明の性質および利点のさらなる理解をもたらす。本明細書の実施形態では、ファイル配信が、ファイルを送信するエンコーダ送信機システムと、ファイルを受信する受信機デコーダシステムとによって、実行される。エンコーダが符号化したものをデコーダが理解するように、送信の形式は調整される。以下の様々な例で示されるように、ファイル配信は、一般的なオブジェクト配信の例であり、別段示されない限り、オブジェクトはファイルとして扱われ得ること、場合によってはファイルはオブジェクトとして扱われ得ることが、これらの例から明らかであろう。パケット配信システムにおいて、データはパケットへと編成され、パケットとして送信される。各パケットは、パケット中に何があるか、それがどのように配置されているかを受信機が判定できるようにする、要素を有する。本明細書で説明される技法を使って、前方誤り訂正が使われる場合にパケットを送信するための柔軟性が提供される。これらの技法を使って、不均一なFECの保護が、ファイルの一括配信とともに実現され得る。多くのファイルが別々のファイルとして配信される場合、パケット喪失に対する配信の弾力性は、すべてのファイルがより大きなファイルへと連結されその大きなファイルが配信において保護される場合よりも、はるかに低くなり得ることがよく知られている。しかし、より小さなファイルの組合せとしてより大きなファイルの構造をシグナリングするのが必要であり、受信機がより小さなファイルの部分集合の復元にしか関心がなくても、受信機は一般に、より大きなファイル全体を復元して、より大きなファイル内のより小さなファイルのすべてを復元する必要がある。したがって、好ましいファイル配信システムまたは方法は、ソースブロックの数と、ファイルのためにファイル配信構造として使われるソースブロック当たりの符号化シンボルの数との、あらゆる柔軟な組合せを可能にしなければならない。ファイル配信方法が、パケット喪失に対して効率的な保護を実現し、異なる優先順位で保護されるファイルの異なる部分を有するファイルの配信をサポートし、ファイルの各部分が、ファイルの他の部分とは異なる、ソースブロック構造およびサブブロック構造を有し得ることも、当てはまらなければならない。また、一部の場合には、ファイルはオブジェクトの特定の例であると考えられるが、ファイルの転送および処理を説明するために本明細書で使われる例は、場合によってはファイルとしては呼ばれないデータオブジェクト、たとえば、データベースからのデータの大きな塊、ビデオシーケンスの一部などに対しても使われ得ることを、ここで理解されたい。ファイルオブジェクト配信システムまたは方法は、大きなファイルオブジェクトの保護の効率性とともに、多くのより小さなファイルオブジェクトの配信を実現し、より小さなファイルオブジェクトの構造の単純なシグナリングを実現し、受信機が、より小さなファイルのオブジェクトのすべてを復元することなく、より小さなファイルオブジェクトの部分集合のみを独立に復元するための能力を提供できなければならない。これらの望ましい品質を有するシステムの例が、ここで説明される。基本的な汎用ファイル配信の方法およびシステム基本的な汎用ファイルの配信の方法および対応するシステムがここで説明され、UFDは、既存のファイル配信方法に対する大きな利点を含む。基本的なUFDの方法に対する、前方誤り訂正ペイロードIDは、たとえば32ビットのフィールドであり得る、汎用ファイルシンボル識別子フィールドを含む。基本的なUFDの方法のための、送信機および受信機の方法が、同じくここで説明される。また、ファイルがオブジェクトと呼ばれる場合、UFSIは代わりにUOSIと呼ばれ得る。送信機の基本的なUFDの方法が、図3を参照して説明される。送信機は、たとえば、RaptorRFC5053またはRaptorQSpecで説明されるように、既存の方法を使ってFECオブジェクト送信情報を生成し、FECOTIを使って、ファイルの送信に使用すべきソースブロックおよびサブブロックの構造を決定し、のペアとファイルの符号化シンボルとの関係を決定することができる。たとえば、RaptorQSpecで説明されるように、生成されるFECOTIはであってよく、Fは送信されるファイルのサイズ、Alは、Alの倍数であるメモリの境界上でサブシンボルが揃えられるのを確実にするために使われる整列係数、Tは生成され送信において送信されるシンボルのサイズ、Zは送信のためのファイルの分割先であるソースブロックの数、Nは送信のための各ソースブロックの分割先であるサブブロックの数である。これは、図3のステップ300に示されている通りである。たとえば、RaptorQSpecで説明されるように、送信機は、パケット内で送信されるべき符号化シンボルを形成し、ソースブロックに基づいて、かつサブブロックが使われる場合にはサブブロック構造にも基づいて、既存の方法を使ってこれらの符号化シンボルのためのSBNおよびESIを生成することができる。符号化システムが送信されるべきである度に、送信機は、図3のステップ310に示されるように、生成されるべき符号化シンボルのSBNAおよびESIBを決定することができ、次いで送信機は、図3のステップ320に示されるように、たとえばRaptorQSpecで説明される技法のような既存の技法を使って、に基づいて符号化シンボルの値を生成することができる。そして、図3のステップ330に示されるように、その符号化シンボルのUFSICは、CB×ZAとして計算される。送信機は、図3のステップ340に示されるように、パケットのFECペイロードIDが符号化シンボルのUFSICへ設定されたパケット中で、符号化シンボルを送信することができる。次いで、送信機は、図3のステップ350に示されるように、さらなる符号化シンボルが送信されるべきかどうかを判定することができ、送信されるべきである場合、送信機は、図3のステップ310へのYes分岐で示されるように、送信すべき追加の符号化シンボルを生成することができ、送信されるべきではない場合、送信機は、図3のステップ360へのNo分岐で示されるように、終了することができる。送信機の基本的なUFDの方法の、多くの変形形態がある。たとえば、送信機は、パケットの少なくとも一部で2個以上の符号化シンボルを送信することができ、この場合、FECペイロードIDは、パケットに含まれる第1の符号化シンボルのUFSIに設定されてよく、パケットに含まれる追加のシンボルは、対応するUFSIの値が連続的になるように、選択され得る。たとえば、パケット中で搬送される3個の符号化シンボルがあり、第1のそのようなシンボルのUFSIが4234である場合、他の2個の符号化シンボルは、それぞれUFSIが4235および4235である符号化シンボルであり得る。他の代替形態の例として、送信機は、どれだけの符号化シンボルを生成するかを事前に決定し、符号化シンボルのいずれかを生成する前に、生成されるべきすべての符号化シンボルのの値を決定することができる。別の例では、UFSIの値は、の値を生成する中間ステップなしで、直接生成されてよい。変形形態の別の例として、他の形態のFECOTI情報を生成することができる。たとえば、基本UFSIBUが、ファイルのFECOTIに含まれてよく、BUは次のように使われ得る。すなわち、パケットに含まれる符号化シンボルについて、FECの送信機および受信機によって使われるべきUFSIはUBUであり、Uは、符号化シンボルを搬送するパケット中で搬送されるUFSIである。したがって、たとえば、パケットがU1045を搬送し、FECOTIの中の基本UFSIがBU2000000である場合、符号化シンボルのUFSIは2001045である。基本UFSIの使用には、いくつかの利点がある。1つの利点として、FLUTE、ALC、LCT、FECBBにおいて説明されるプロトコルスイートが、TOIとも呼ばれる送信オブジェクト識別子を、転送されるべきファイルまたはオブジェクトのFECOTIと関連付ける。同じファイルの符号化シンボルが、異なる時間に、または異なるセッションで送信され、異なるTOIと関連付けられ得ることが可能である。また、異なる各TOIと関連付けられるパケットについて、UFSI0から始まる符号化パケットを送信できるのが有利である。FECOTIの一部として基本UFSIを規定できることで、異なる基本UFSIを、ファイルのために符号化シンボルが送信される際の各TOIと関連付けることができ、異なるTOIに対して重複する符号化シンボルが送信されない。たとえば、同じファイルの符号化シンボルは、TOI1と関連付けられTOI2と関連付けられるパケットで送信されてよく、TOI1と関連付けられる基本UFSIは0に設定され、TOI2と関連付けられる基本UFSIは1000000に設定される。そして、TOI1とTOI2の両方の符号化パケットは、UFSI0、1、2などというシーケンスを含んでよく、TOI1でファイルのために送信される符号化シンボルが1000000個より少ない限り、2つのTOIと関連付けられて送信される符号化シンボルの中に、重複する送信される符号化シンボルはない。受信機の基本的なUFDの方法が、図4を参照して説明される。受信機は、図4のステップ400で示されるように、既存の技法を使って、送信機について上で説明されたのと同じ形式の、FECOTIを決定することができる。たとえば、FECOTIは、FLUTEセッションの説明に組み込まれてよく、またはFECOTIは、URLへと符号化されてよく、またはFECOTIは、SDPメッセージを介して取得されてよい。ステップ410において、受信機は、さらに符号化シンボルが受信されるかどうかを確かめて、別の符号化シンボルを受信するまで、またはさらなる符号化シンボルは今後受信されないと受信機が判定するまで、このステップに留まることができ、他の手段、たとえばファイル修復サーバへのHTTP要求を使ってファイルの復元を試み、または受信機は、後でさらなる符号化シンボルを受信するために別のセッションを待機することができ、または受信機は、ファイルを回復できないと判定することができる。別の符号化シンボルが利用可能である場合、ステップ430において、受信機は符号化シンボルのUFSICを決定し、符号化シンボルの値を受信する。ステップ440において、受信機は、ソースブロックの数ZおよびUFSICに基づいて、ACmoduloZ、およびBfloorを計算し、ステップ450において、受信機は、符号化シンボルのをに設定し、ステップ460において、受信機は、符号化シンボルの値およびファイル復元のために使われるを記憶する。ステップ470において、受信機は、ファイルを復元するのに十分な符号化シンボルが受信されたかどうかを判定し、受信されている場合、ステップ480のファイルの復元に進み、受信されていない場合、ステップ410のさらなる符号化シンボルの受信に進む。受信機の基本的なUFDの方法の、多くの変形形態がある。たとえば、受信機は、パケットの少なくとも一部で2個以上の符号化シンボルを受信することができ、この場合、FECペイロードIDは、パケットに含まれる最初の符号化シンボルのUFSIに設定されてよく、パケット中の追加のシンボルは、連続的な対応するUFSIの値を有し得る。たとえば、パケット中で搬送される3個の符号化シンボルがあり、第1のそのようなシンボルのUFSIが4234である場合、他の2個の符号化シンボルは、それぞれUFSIが4235および4235である符号化シンボルであってよく、パケット中で搬送されるUFSIは、第1の符号化シンボルのUFSI4234であり得る。他の代替形態の例として、受信機は、復元を試みる前に、どれだけの符号化シンボルを受信すべきかを事前に決定することができる。別の例として、受信機は、ファイルの復元に十分な符号化シンボルが受信されたかどうかを判定するのに使われるFEC符号に特有の、何らかの処理を行うことができる。別の例として、UFSIの値は、復元処理において、の値を生成する中間ステップなしで、直接使用されてよい。別の例として、ファイルの復元は、符号化シンボルの受信と同時に行われてよい。別の例として、他の形態のFECOTI情報を使用することができる。基本的なUFDの方法を、ソースブロックおよびサブブロックの構造を決定するためのRaptorQSpecで説明された技法と組み合わせることで、多くの利点がもたらされる。たとえば、ファイルを送信するための、SBNとESIの組合せによって特定される、従来の方法ではソースシンボルと呼ばれていたものは、基本的なUFDの方法を使うと、UFSIによって特定されるファイルシンボルとして見なされ得る。Fを、オクテット単位での送信されるべきファイルのサイズ、Tを、ファイルを送信するときにFEC符号化復号のために使われるべきシンボルサイズとすると、KTceilは、ファイル中のシンボルの総数であり、ceilは、x以上の最小の整数である。ソースブロック構造およびサブブロック構造はたとえば、RaptorQSpecで説明されるように決定され、上で説明された基本的なUFDの方法を使って、シンボルの識別情報を形式からUFSI形式へと変換し、ファイルシンボルのUFSIの範囲は012KTであり、ファイルから生成される任意の修復シンボルは、範囲KT1、KT2などの中にUFSIを有する。この特性は、シンボルが元のファイルの一部であるかどうか、またはファイルから生成された修復シンボルであるかどうかを、シンボルのUFSIをKTの値と単に比較することによって判定するのを可能にする。このことはたとえば、どのシンボルが元のファイルの一部であるか、ならびにどのシンボルを修復シンボルとして無視できるかを、パケット中で搬送されるUFSIの値とファイルのKTの値とに基づいて、FEC復号をサポートしない受信機が判定できるようにするのに、有用であり得る。図5はある例を示し、この場合、ファイルサイズがF28669オクテット、シンボルサイズがT1024オクテットであり、したがってKTceil28である。図5では、ファイルのシンボルの標示が上側に示され、各行はソースブロックに対応し、各列は同じESI値を有するシンボルに対応する。シンボルの対応するUFSI標示が、下側に示されている。この場合、UFSI27であるシンボル、すなわちUFSI標示に関して28番目のシンボルは、FECの符号化および復号のために、最後のF3オクテットを0によってパディングされているが、このシンボルの最後のパディングされた3オクテットは、送信する必要はない。この例では、UFSI28以上の任意の符号化シンボルは修復シンボルであり、UFSI28である符号化シンボルは、SBN3のソースブロックから生成され、UFSI29である符号化シンボルは、SBN4のソースブロックから生成され、UFSI30である符号化シンボルは、SBN0のソースブロックから生成され、以下同様である。当業者が認識するように、この特性には多くの他の利点がある。基本的なUFDの方法の別の利点は、符号化シンボルが、UFSIによって定義される順序で、すなわちUFSIの順序01234で送信される場合、Z個のソースブロックの符号化シンボルは、交互の順序で送信され、すなわち、Z個のソースブロックの各々のうちのESI0であるZ個の符号化シンボルが最初に送信され、続いて、Z個のソースブロックの各々のうちのESI1であるZ個の符号化シンボルが送信される、などである。大半の送信に対しては、この単純な送信順序で十分であり、それが好ましい。しかし、ソースブロックの数Zと同期し得る何らかの周期性がパケット喪失にある場合、より良い可能性のある送信順序は、UFSIが連続したZ個の符号化シンボルの各セットを、送信する前にランダムに順序を変えるというものであり、すなわち、UFSI0Z1である最初のZ個の符号化シンボルが、ランダムに変えられた順序で送信され、次いで、UFSIZ2×Z1である次のZ個の符号化シンボルが、ランダムに変えられた順序で送信される、などである。この説明の全体で、別段示されない限り、ランダムは擬似ランダムを含み得ることを理解されたい。基本的なUFDの方法を使うことで、従来の既知の方法に対する多くのさらなる利点がもたらされる。たとえば、所定のサイズのSBNおよびESIフィールドを含むFECペイロードIDを使う場合、可能なソースブロックの所定の数と、ソースブロックあたりの可能な符号化シンボルの所定の数は別々である。たとえば、32ビットのFECペイロードIDを生じる8ビットのSBNおよび24ビットのESIは、可能なソースブロックの数を256に制限し、ソースブロック当たりの可能な符号化シンボルの数を16777216に制限する。UFSIフィールドを含むFECペイロードIDは、そうではなく、ファイルのソースブロック構造とは無関係に、ファイルの可能な符号化シンボルの総数のみを制限する。たとえば、32ビットのFECペイロードIDを生じる32ビットのUFSIを使うと、ファイルのために生成され得る符号化シンボルの総数は4294967296であり、これは、ファイルが何個のソースブロックへと分割されるかに無関係であり、サブブロックが使われる場合には、ファイルのサブブロック構造にも無関係である。したがって、シンボルのサイズが1024オクテットである場合、この例では、ファイルサイズは最大で4GBであってよく、符号化シンボルの数はファイルサイズの1024倍であってよく、これは、ファイルが1つのソースブロックへと分割されるか、16384個のソースブロックへと分割されるか、または4194304個のソースブロックへと分割されるかには無関係である。別の例として、ファイルサイズは2TBであってよく、符号化シンボルの数は、ファイルサイズの2倍であってよい。すべての場合において、サブブロック構造が使われる場合、ファイルのために生成され得る符号化シンボルの数は、ファイルのサブブロック構造とは無関係である。不均一誤り保護ファイル配信サービスのための汎用ファイル配信方法ほとんどの従来のファイル配信方法は、不均一誤り保護ファイル配信をサポートしない。ファイルの異なる部分を符号化するのに使われる実際のFEC符号を変えることによってUEPをサポートする、たとえば、ISDBTmm規格で現在規定されておりLDPCExtensionsで説明される方法を用いる、いくつかの従来の方法がある。UEPを使うときに実際のFEC符号を変更しなければならないという欠点とは別に、さらなる欠点は、これらの方法によって実現される保護が理想からかけ離れているということである。ある例として、結果がLDPCExtensionsの図6に示される例を考える。その例では、パケット中で送信されるべき1000KBのサイズのファイルに2つの部分があり、各パケットは1KBのシンボルを含む。ファイルの第1の部分はサイズが30KBであり、100個のパリティパケットまたは修復パケットによって保護され、ファイルの第2の部分は970KBであり、全体で1000個のソースパケットおよび1000個のパリティパケットがそのファイルのために送信される。実現される保護は、2つの問題によって理想からはかけ離れている。1つの問題は、LDPCRFC5170に基づく、用いられるFEC符号が、ソースブロックを復元するために大きな受信オーバーヘッドを必要とすることが多いということであり、すなわち、ファイルを復元するために、ファイル中のソースパケットよりも多くのパケットを、受信する必要がある。第2の問題は、この方法は基本的に、ファイルの第2の部分を送信して保護するのに使われるパケットとは別個のセットを使って、ファイルの第1の部分を送信して保護するということである。第2の問題について、ファイルの第1の部分のために送信される、130個のパケットのうちの30個のパケットを受信する際の変動は、大きいものであり得る。それは、ファイルの第1の部分が、そのような少数のパケットを通じて送信されるからである。LDPCExtensionsで説明されたUEPファイル配信方法は、本明細書では単純UEPファイル配信方法と呼ばれる拡張によって、改善することができる。単純UEPファイル配信方法は、ファイル配信のための既存の技法を使い、優先順位に基づいてファイルの各部分に対して異なる保護の量を使って、ファイルの複数の部分を別個のファイル配信として配信し、配信された複数のファイルが同じファイルの複数の部分であると受信機が知るように、ファイルの複数の部分の間の論理的な接続がシグナリングされ得る。たとえば、単純UEPファイル配信方法は、上の例のRaptorQSpecを使い、ファイルの第1の30KB部分を、その第1の部分から生成されたサイズが1024オクテットの符号化シンボルを各々含む全体で130個のパケットを送信することによって、配信することができ、ファイルの第2の970KB部分は、その第2の部分から生成されたサイズが1024オクテットの符号化シンボルを各々含む全体で1870個のパケットを送信することによって、別個のファイルとして配信され得る。したがって、ファイルの2つの部分に対して、全体で2000個のパケットが別個のファイルとして送信される。単純UEPファイル配信方法は、LDPCExtensionsで説明された方法に対する改善である。それは、FEC符号自体が修正されず、本明細書の図10に示されるように、パケット喪失状態の異なるファイルの2つの部分の配信の性能が、LDPCExtensionsの図6に示されたものよりも優れているからである。この違いの1つの可能性のある原因は、RaptorQSpecで規定されたFEC符号が、LDPCRFC5170で規定されたFEC符号よりも、優れた復元特性を有しているからである。しかし、単純UEPファイル配信方法は依然として、上で説明された第2の問題を抱える。PETおよびPETPatentは、UEPファイル配信サービスを提供するための、改善の可能性がある方法を提供し、各パケットは、優先順位に基づいて、ファイルの各部分からの規定された量の符号化データを含む。PETの簡単な組み込みは、ファイルの各部分に対して適切なサイズの符号化シンボルを各パケットに含めて、ファイルの各部分に対するペアを含む別個のFECペイロードIDを含めることであろう。しかし、この方法は、いくつかの理由によって不利である。たとえば、各部分に対する所定のサイズのSBNおよびESIフィールドを含むFECペイロードIDを使う場合、ファイルの各部分に対する、可能なソースブロックの所定の数と、ソースブロックあたりの可能な符号化シンボルの所定の数とは、別々である。たとえば、d個の部分の各々に対する、8ビットのSBNおよび24ビットのESIは、1つの部分当たりの可能なソースブロックの数を256に制限し、ソースブロック当たりの可能な符号化シンボルの数を16777216に制限する、ビットのFECペイロードIDをもたらす。さらに、FECペイロードIDのサイズは、d個の部分の各々に対して32ビットであり、これは、各パケットのすべての部分に対するFECペイロードIDが全体で32×dビットになることを意味し、各パケット中のFECペイロードIDヘッダだけに対して、たとえばd10であればこれは320ビットであり、または等価的に40オクテットである。ファイル配信のための基本的なUFDの方法は、以下で詳細に説明されるような、従来の不均一誤り保護ファイル配信方法に対して大きな利点をもたらすUEPファイル配信サービスを実現するように、拡張され得る。本明細書では、これらの拡張された方法は、UFDUEPファイル配信方法と呼ばれる。これらのUFDUEPファイル配信方法は、PETおよびPETPatentで説明される方法の一部を使うことができる。例示的なUFDUEPファイル配信方法が、ここでより詳細に説明される。そのような方法では、送信機は、サイズがFであるファイルを、サイズがF0F1Fd1であるd1個の部分に分割するので、Fは、Fiのiにわたる合計に等しい。送信機は、パケットサイズTを、サイズがT0T1Td1であるd個の部分に分割するので、Tは、Tiのiにわたる合計に等しい。Tのこの分割は、F0F1Fd1と、対応するファイルの部分の優先順位とに基づく。比FiTiは、1つのソースブロックとしてのファイルの部分iを保護するために理想的なFEC符号が使われると仮定して、ファイルの部分iを復元するためにどれだけのパケットを受信する必要があるかを判定するので、比FiTiが小さいほど、ファイルの部分iの優先順位は高い。実際には、たとえば、FEC符号は完璧ではなく何らかの受信オーバーヘッドを示すので、または、ファイルのその部分が複数のソースブロックに分割され、一部のソースブロックの符号化シンボルが他のソースブロックの符号化シンボルよりも高い比率で失われるので、または、FiTiが整数ではないので、FiTiよりもわずかに多くのパケットが、ファイルの部分iを復元するために必要であり得る。UEPの例として、F1MB、T1024オクテット、d2、F032KB、F1FF0992KB、かつT064オクテット、T1TT0960オクテットであるとする。この例では、F0T0512なので、理想的には512パケットの受信によって、ファイルの部分0の復元が可能であり、F1T1105813なので、理想的には1059パケットの受信によって、ファイルの部分1の復元が可能である。したがって、この例では、ファイルの部分0は、ファイルの部分1の復元に必要なパケットのおよそ半分のパケットから、復元され得る。この例では、UEPが使われない場合、すなわち、d1であり、したがってF0F1MBであり、T0T1024オクテットである場合、F0T01024個のパケットがファイルの復元に必要である。したがって、前の段落で説明されたUEPの例では、ファイルの部分0の優先順位がより高いので、ファイルの部分1の復元には、UEPが使われない場合よりもわずかに多くのパケットが必要である。この基本的なトレードオフの分析的な研究を、PETにおいて見出すことができる。F0F1Fd1と、異なるファイルの部分の優先順位とに基づいて、Tの部分T0T1Td1を生成するための、送信機のUFDUEPの方法に対する様々な方式がある。FiTi≒FTとなるようにTiが選ばれる場合、ファイルの部分iの優先順位は平均的であると見なされ、部分iの優先順位は、FiTiFTであるかに応じて、それぞれ、比較的高いかまたは低い。FECOTIの生成のための送信者のUFDUEPの方法が、図6を参照してここで説明される。dF0F1Fd1T0T1Td1AlWSの値を与えると、ファイルのd個の部分の各々に適用されるFECOTIは、既存の方法を使って、たとえば、RaptorQSpecのセクション43で説明される方法を使って、通常通りに独立に計算することができる。すなわち、各々のi0d1に対して、送信機は、ファイルの部分iに対するFECOTIを生成することができ、このFECOTIは、たとえば、RaptorQSpecのセクション43で説明された方法を使い、Fiをファイルサイズとして、Tiを部分iのための情報を各パケットで搬送するために使われるべきシンボルサイズとして扱って、ファイルの部分iがどのようにソースブロックおよびサブブロックへと分割されるべきかを決定する。こうして、送信機は、ファイルの他の部分とは独立に、ファイルの部分iに対するFECOTIを生成する。この処理は、本明細書の図6のステップ600に示されている。送信機はまた、ソースブロックおよびサブブロックへのファイルの部分iの分割、および、ファイルの部分iの符号化シンボルのと、既存の方法、たとえば、RaptorQSpecのセクション44およびセクション5で説明される方法を使って、符号化シンボルがどのようにファイルの部分iから生成されるかということとの対応付けを、生成することができる。これらのUFDUEPの方法は、ファイルの他の部分とは独立に、ファイルの部分iに適用されるので、ファイルの異なる部分は、異なるソースブロックおよびサブブロック構造を有してよく、特に、この方法はファイルの各部分に対して独立に適用されるので、ファイルの異なる部分の間で、ソースブロック当たりのソースシンボルの数およびソースブロックの数が異なっていてよい。整列係数Alは、好ましくはファイルの部分のすべてに対して同一であり、特に、各部分iに対して、Tiの値がAlの倍数であることが好ましい。さらに、たとえば、RaptorQSpecのセクション45で説明される方法が、FECOTIを導出するために使われる場合、ファイルの部分の各々のソースブロックおよびサブブロック構造を導出するときに、同じ値のAlおよびWSが使われることが好ましい。Alに同じ値を使うことで、Alの倍数個のオクテット上に整列されたメモリに対して、受信機において復号が行えることが確実になり、WSに同じ値を使うことで、受信機において復号される必要のあるランダムアクセスメモリ中の最大のブロックサイズが、ファイルのすべての部分に対して同一になることが確実になる。たとえば、ファイルの優先順位の高い部分を復元するのにより少量のメモリを使用するのが望ましい場合には、FECOTIを導出するのに、ファイルの異なる部分に対して異なる値のWSを使うのが好ましい、いくつかの適用例がある。異なる部分に対して異なる整列係数を使うのが有利である、適用例が存在し得る。たとえば、優先順位の高い部分は、4オクテットで整列されたメモリを有するローエンド受信機と、8オクテットで整列されたメモリを有するハイエンド受信機の両方によって復号されてよく、優先順位の低い部分は、ハイエンド受信機のみによって復号されてよい。この例では、ローエンド受信機がこれらの部分を効率的に復号できるように、優先順位の高い部分に対してはAl4を使うのが有利であり得るが、優先順位の低い部分に対してはAl8を使うのが有利であり得る。それは、ハイエンド受信機は、Al4よりもAl8で、優先順位の低い部分をより効率的に復号できるからである。送信機のUFDUEPの方法によって生成された、ファイルの部分iに固有の対応するFECOTIは、Fi、Ti、Zi、Niを含み、Ziは、ファイルの部分iの分割先のソースブロックの数であり、Niは、ファイルの部分iの各ソースブロックの分割先のサブブロックの数である。したがって、ファイルのために送信機のUFDUEPの方法が生成する全体のFECOTIは、を含み得る。たとえば、dが一定であり、したがってFECOTIで明示的に列挙される必要がない場合、または、ソースブロック構造と、使われる場合にはサブブロック構造とを示すために、他の方法が使われる場合には、FECOTIの他のバージョンも利用可能である。送信機は、UFDUEPの方法を使って、パケット中で送信されるべきファイルの各部分のための1つの符号化シンボルを組み立て、パケットのFECペイロードIDは、UFSI値Cを含む。パケットが送信されるべきである場合、送信機は、図6のステップ610で示されるように、パケットのFECペイロードIDとして使われるべき、UFSI値Cを決定する。使われるべきUFSI値は、たとえば連続的であってよく、たとえばUFSI値0123などであってよい。図6のステップ620に示されるように、所与のUFSI値Cに対して、ファイルの部分iのためのパケット中の、パケットのi番目の部分に配置されるべきサイズTiの符号化シンボルは、AiCmoduloZi、およびBifloorとして計算される、SBNAiおよびESIBiを有する。図6のステップ630、640、および650に示されるように、i0d1に対して、これらのd個の符号化シンボルが、パケットのd個の部分の各々について生成され、次いで、合計のサイズがTである、UFSICとこれらのd個の符号化シンボルとが一緒にパケット中で送信される。図6のステップ660で行われる判定で示されるように、送信機のUFDUEPの方法は、符号化パケットの生成と送信を続ける。受信機のUFDUEPの方法が、図7を参照して説明される。図7のステップ700で示されるように、受信機は、既存の技法を使って、送信機について上で説明されたものと同じ形式で、FECOTIを決定することができる。たとえば、FECOTIは、FLUTEセッションの説明に組み込まれてよく、またはFECOTIは、URLへと符号化されてよく、またはFECOTIは、SDPメッセージを介して取得されてよい。ステップ710において、受信機は、さらなるパケットが受信されるかどうかを確認し、受信機が別のパケットを受信するまで、または、さらなるパケットが受信される予定はないと受信機が判定するまで、このステップに留まってよく、そして、ファイルの十分な部分が復元されたと判定して停止し、または、他の手段を使って、たとえば、ファイル修復サーバへのHTTP要求を使って、ファイルのさらなる部分を復元しようと試み、または受信機は、後でさらなるパケットを受信するための別のセッションを待機することができる。別のパケットが利用可能である場合、ステップ730において、受信機は、受信されたパケットのUFSICを求め、各i0d1に対して、各i0d1のパケットからサイズTiの符号化シンボルを抽出する。ステップ740において、各i0d1に対して、受信機は、ソースブロックの数ZiおよびUFSICに基づいて、AiCmoduloZi、およびBifloorを計算し、ステップ750において、受信機は、部分iの符号化シンボルのをに設定し、ステップ760において、受信機は、部分iの符号化シンボルの値と、ファイルの部分iを復元するために使われるべきとを記憶する。ステップ770において、受信機は、各i0d1に対して、ファイルの部分iを復元するのに十分な符号化シンボルが受信されたかどうかを判定し、受信されている場合、ステップ780におけるファイルの部分iの復元に進み、受信されていない場合、ステップ710におけるさらなるパケットの受信に進む。受信機のUFDUEPの方法の、多くの変形形態がある。たとえば、送信機は、パケットの少なくとも一部で、ファイルの各部分のための2個以上の符号化シンボルを送信できるので、受信機はこれを受信することができ、この場合、FECペイロードIDは、パケットに含まれる各部分に対する第1の符号化シンボルに対応するUFSIに設定されてよく、パケット中の各部分に対する追加のシンボルは、連続的な対応するUFSI値を有し得る。たとえば、パケット中で搬送される、ファイルの各部分のための3個の符号化シンボルがあり、各部分のための第1のシンボルがUFSI4234に対応する場合、各部分のための他の2個の符号化シンボルは、UFSI4235および4235にそれぞれ対応してよく、パケット中で搬送されるUFSIは、UFSI4234であり得る。他の代替形態の例として、受信機は、復元を試みる前にどれだけの符号化シンボルを受信すべきかを事前に決定することができ、または、セッション中のパケット喪失の統計情報を計算し、これに基づいて、ファイルのどの部分の回復を試みるべきかを決定することができる。別の例として、受信機は、ファイルの各部分の復元に十分な符号化シンボルが受信されたかどうかを判定するのに使われるFEC符号に特有の、何らかの処理を行うことができる。別の例として、UFSIの値は、ファイルの各部分の復元処理において、の値を生成する中間ステップなしで、直接使用されてよい。別の例として、ファイルの部分の復元は、符号化シンボルの受信と同時に行われてよい。別の例として、他の形態のFECOTI情報を使用することができる。たとえば、基本UFSIBUIが、他の部分とは独立に部分iのFECOTIにおいて規定されてよく、BUIは次のように使われ得る。すなわち、パケットに含まれる部分iの符号化シンボルのために、FECの送信機および受信機によって使われるべきUFSIはUBUIであり、Uは、符号化シンボルを搬送するパケット中で搬送されるUFSIである。したがって、たとえば、パケットがU1045を搬送し、部分iのFECOTIの中の基本UFSIがBUi2000000である場合、符号化シンボルのUFSIは2001045である。基本UFSIの使用には、いくつかの利点がある。たとえば、異なる部分については修復シンボルのみが送信されるべきである場合、BUiKTiに設定するのが有利である可能性があり、KTiは部分iのファイルシンボルの数である。この場合、送信されるパケットシーケンスにおけるUFSIのシーケンスは、0、1、2、3などであってよいが、それでも、各部分については、その部分から生成された修復シンボルのみがパケット中で送信される。この段落は、基本UFSIの使用の別の例示的な利点を説明する。FLUTE、ALC、LCT、FECBBにおいて説明されるプロトコルスイートは、TOIとも呼ばれる送信オブジェクト識別子を、転送されるべきファイルまたはオブジェクトのFECOTIと関連付ける。同じ部分の符号化シンボルが、異なる時間に、または異なるセッションで送信され、異なるTOIと関連付けられ得ることが可能である。また、異なる各TOIと関連付けられるパケットについて、UFSI0から始まる符号化パケットを送信できるのが有利である。各部分について独立に、FECOTIの一部として基本UFSIを規定できることで、各部分の異なる基本UFSIを、ファイルのために符号化シンボルが送信される際の各TOIと関連付けることができ、異なるTOIに対して重複する符号化シンボルが送信されない。たとえば、同じ部分の符号化シンボルは、TOI1と関連付けられTOI2と関連付けられるパケットで送信されてよく、TOI1と関連付けられる部分の基本UFSIは0に設定され、TOI2と関連付けられる同じ部分の基本UFSIは1000000に設定される。そして、TOI1とTOI2の両方の符号化パケットは、UFSI0、1、2などのシーケンスを含んでよく、TOI1でその部分のために送信される符号化シンボルが1000000個より少ない限り、2つのTOIと関連付けられて送信される符号化シンボルの中に、その部分のための送信される重複する符号化シンボルはない。各部分に対して異なる基本UFSIを規定する代わりに、部分のすべてによって使われるべき基本UFSIをFECOTIの中に有することも、有利であり得る。それは、これによって、FECOTIを搬送するのに必要なオクテット数を低減でき、それと同時に、FECOTIにおいて各部分に対して別個の基本UFSIを規定することの利点の多くを共有できるからであり、この方法とともに使われるFEC符号が、たとえばLubyIで説明されるような情報追加型のFEC符号である場合には、すべての部分のためのUFSIの有効な範囲は非常に広くなり得るので、特に上記のことが当てはまる。UFDUEPの方法を、ソースブロックおよびサブブロックの構造を決定するためのRaptorQSpecで説明された技法と組み合わせることで、多くの利点がもたらされる。具体的には、基本的なUFDの方法の利点のすべては、UFDUEPの方法でも有効である。たとえば、ファイルのUEP部分の1つを送信するための、SBNとESIの組合せによって特定される、従来の方法ではソースシンボルと呼ばれていたものは、UFDUEPの方法を使うと、UFSIによって特定されるその部分のためのファイルシンボルとして見なされ得る。KTiceilは、ファイルの部分iにおけるファイルシンボルの総数であることに留意されたい。ソースブロック構造およびサブブロック構造がたとえば、RaptorQSpecで説明されるようにファイルの各部分について決定され、上で説明されたUFDUEPの方法を使って、ファイルの部分のためのシンボルの識別情報を形式からUFSI形式へと変換する場合、ファイルシンボルのUFSIの範囲は012KTiであり、ファイルから生成される任意の修復シンボルは、範囲KTi1、KTi2などの中にUFSIを有する。この特性は、シンボルがファイルの元の部分iの一部であるかどうか、またはファイルの部分iから生成された修復シンボルであるかどうかを、シンボルのUFSIをKTiの値と単に比較することによって判定するのを可能にする。このことはたとえば、パケットのどの部分が元のファイルの一部を含むか、ならびにパケットのどの部分が、無視され得る修復シンボルを含むかを、パケット中で搬送されるUFSIの値とファイルの各部分iに対するTiおよびKTiの値とに基づいて、FEC復号をサポートしない受信機が判定できるようにするのに、有用であり得る。図8はある例を示し、この場合ではファイルは2つの部分を含む。第1の部分は5個のソースブロックに分割され、これらのソースブロックの最初の3個は各々6個のソースシンボルを有し、残りの2個のソースブロックは各々5個のソースシンボルを有し、これらのシンボルの各々のサイズは、たとえば48オクテットなので、第1の部分のサイズは28×481344オクテットである。第2の部分は4個のソースブロックに分割され、これらのソースブロックの最初の3個は各々4個のソースシンボルを有し、残りの1個のソースブロックは各々3個のソースシンボルを有し、これらのシンボルの各々のサイズは、たとえば256オクテットなので、第2の部分のサイズは256×483840オクテットである。図9は、図8に示されるファイル構造のための、可能なパケット化を示す。この例では、各パケットは、UFSIC、図6を参照して上で説明されたような、Cに基づく、図8で示されるファイル構造の第1の部分から生成されるサイズが48オクテットの第1の符号化シンボル、および、図6を参照して前に説明されたような、Cに基づく、図8で示されるファイル構造の第2の部分から生成されるサイズが256オクテットの第2の符号化シンボルを含む。パケットの保護されていない部分は、ファイルの対応する部分のソースシンボルを搬送し、保護されている部分は、ファイルの対応する部分から生成された修復シンボルを搬送する。この例では、ファイルの第1の部分を復元するのに必要なパケットの最小の数は28であり、一方ファイルの第2の部分を復元するのに必要なパケットの最小の数は15である。図9は、UFSIが027である28個のパケットを示し、したがって、これらのパケットで搬送されるファイルの第1の部分の符号化シンボルのすべてが、ソースシンボルである。少なくとも28のUFSI値を有するように生成される任意の追加のパケットは、ファイルの第1の部分の修復シンボルを搬送する。UFDUEPの方法の別の利点は、符号化シンボルが、UFSIによって定義される順序で、すなわちUFSIの順序01234で送信される場合、ファイルの部分iのZi個のソースブロックの符号化シンボルは、交互の順序で送信され、すなわち、Zi個のソースブロックの各々のうちのESI0であるZi個の符号化シンボルが最初に送信され、続いて、Zi個のソースブロックの各々のうちのESI1であるZi個の符号化シンボルが送信される、などである。この特性は、各部分が独立のソースブロック構造を有する場合であっても、ファイルのすべての部分に対して当てはまる。大半の送信に対しては、この単純な送信順序で十分であり、それが好ましい。しかし、ソースブロックの数Ziと同期し得る何らかの周期性がパケット喪失にある場合、より良い可能性のある送信順序は、Z個のUFSIが連続した符号化シンボルの各セットを、送信する前にランダムに順序を変えるというものであり、ここでZはすべてのi0d1に対するZiの最大値である。すなわち、UFSI0Z1である最初のZ個の符号化シンボルが、ランダムに変えられた順序で送信され、次いで、UFSIZ2×Z1である次のZ個の符号化シンボルが、ランダムに変えられた順序で送信される、などである。別の可能な送信順序は、送信されるべき符号化シンボルのすべてを、送信する前にランダムに順序を変えるというものである。UFDUEPの方法を使うことで、従来の方法、または従来の方法の単純な拡張に対して、多くのさらなる利点がもたらされる。たとえば、UFSIフィールドを含むFECペイロードIDフィールドを使ったUFDUEPの方法では、ファイルの各部分のための可能な符号化シンボルの総数は、UFSIフィールドのサイズのみによって制限され、ファイルの各部分のソースブロック構造とは独立である。さらに、ファイルの各部分の完全に異なるソースブロック構造から生成されるシンボルの同時の識別を可能にする、汎用的で簡潔なFECペイロードIDが、UFSIフィールドの使用によって実現される。たとえば、32ビットのFECペイロードIDを生じる32ビットのUFSIを使う場合、ファイルのために生成され得る符号化シンボルの総数は4294967296であり、これは、ファイルの各部分について、ファイルが何個のソースブロックへと分割されるかに無関係であり、サブブロックが使われる場合には、ファイルのサブブロック構造にも無関係である。したがって、ファイルの第1の部分のシンボルのサイズが256オクテットであり、ファイルの第2の部分のシンボルのサイズが1024オクテットである場合、この例では、ファイルの第1の部分のサイズは1GBであり、ファイルの第2の部分のサイズは4GBであり、符号化シンボルの数は、ファイルの各部分のソースシンボルの数の1024倍であってよく、これは、ファイルの各部分が1つのソースブロックに分割されるか、16384個のソースブロックに分割されるか、または4194304個のソースブロックに分割されるかに無関係である。UFDUEPのファイル配信方法が単純なUEPファイル配信方法に対して実現する改善の例が、図11に示される。この例では、1MBのファイルが、32KBの第1の部分と992KBの第2の部分とに分割される。両方の方法において、RaptorQSpecで規定されるFEC符号が使われ、符号化シンボルを搬送するための各パケット内のサイズは1024オクテットであり、全体で2048個のパケットが送信される。図11に示される単純UEPファイル配信方法の例では、ファイルの第1の部分およびファイルの第2の部分は、独立に処理および配信され、第1の部分と第2の部分の両方の場合において、サイズが1024オクテットのちょうど1つの符号化シンボルが各パケット中で搬送される。ファイルの第1の部分のソースは32個のパケットで搬送され、符号化シンボルを含む全体で128個のパケットが送信される。ファイルの第2の部分のソースは992個のパケットで搬送され、符号化シンボルを含む全体で1920個のパケットが送信される。図11に示されるUFDUEPファイル配信方法の例では、ファイルの第1の部分およびファイルの第2の部分は、組み合わされて処理および配信される。すなわち、送信される各パケットは、2つの部分の各々について符号化シンボルを含み、第1の部分については符号化シンボルのサイズは64オクテットであり、第2の部分については符号化シンボルのサイズは960オクテットである。ファイルの第1の部分のソースは512個のパケットで搬送され、すべての2048個のパケットが第1の部分の符号化シンボルを含む。ファイルの第2の部分のソースは1059個のパケットで搬送され、すべての2048個のパケットが第2の部分の符号化シンボルを含む。図11で見られるように、単純UEPファイル配信方法とUFDUEPファイル配信方法の復元性能は、ファイルの第2の部分については、パケット喪失率の関数として実質的に同一である。すなわち、両方の場合において、ファイルの第2の部分は、最大で48に達するパケット喪失率まで、かなり安定して復元される。一方、ファイルの第1の部分に対しては、UFDUEPファイル配信方法の復元性能は、単純UEPファイル配信方法の復元性能を大きく上回る。単純UEPファイル配信方法は、パケット喪失率が65未満である場合に、ファイルの第1の部分を安定して復元できるが、UFDUEPファイル配信方法は、パケット喪失率が75に達しても、ファイルの第1の部分を安定して復元できる。一括ファイル配信サービスのための汎用ファイル配信方法およびシステム大半の従来のファイル配信方法は、一括ファイル配信、すなわち、単一の一括ファイルとしての複数のファイルの配信をサポートしない。いくつかのファイルを配信する単純な方法は、各ファイルを独立に配信することである。しかし、この単純な方法にはいくつかの欠点がある。たとえば、ファイルが小さい場合に、実現される保護が理想から離れたものになる。それは、各ファイルの符号化シンボルを含むパケットの数が少ない場合に、パケット喪失の統計値に大きな変動が存在し得るからである。図12は、この問題を例示する。図12では、32KBのファイル配信の信頼性が、配信中のネットワークにおけるパケット喪失の百分率の関数として示されている。このファイル配信の例では、シンボルはサイズが1024であり、ファイルの32個のソースシンボルが、RaptorQSpecで規定されるFEC符号を使って64個の符号化シンボルへと符号化され、各符号化シンボルは別個のパケットで送信される。図12で見られるように、上記の変動によって、ファイルの信頼性のある配信を実現できる喪失率は、50よりもはるかに低い。さらに、多くの小さなファイルが独立に符号化されて送信される場合、すべてのファイルが信頼性をもって受信されるパケット喪失率は、さらに低い。図12は、各々が32KBのサイズである、32個のファイルの配信についてのこの現象を示し、各ファイルの符号化および送信は、前の段落で説明されたパラメータと同じパラメータを使って、他のファイルとは独立に実行される。理解され得るように、すべての32個のファイルの配信は、パケット喪失が、50よりもはるかに低い25前後よりも低い場合にのみ、信頼性をもって実現できる。UFDUEPファイル配信方法は、以下のように拡張されて、UFD一括ファイル配信方法を提供することができる。UFD一括ファイル配信方法は、UFDUEPファイル配信方法と同じ方法を使うことができるが、同じファイルのd個の部分の配信をシグナリングする代わりに、各部分が別々のファイルであり、d個のファイルが一括して配信されていることをシグナリングする。送信機が、それぞれサイズがF0F1Fd1であるd個のファイルの一括配信を行うのを望んでいるとする。送信機のUFD一括方法は、パケットサイズTを、サイズがT0T1Td1であるd個の部分に分割するので、Tは、Tiのiにわたる合計に等しい。Tのこの分割は、F0F1Fd1と、対応するファイルの優先順位とに基づく。比FiTiは、1つのソースブロックとしてのファイルの部分iを保護するために理想的なFEC符号が使われると仮定して、ファイルiを復元するためにどれだけのパケットを受信する必要があるかを判定するので、比FiTiが小さいほど、ファイルの部分iの優先順位は高い。実際には、たとえば、FEC符号は完璧ではなく何らかの受信オーバーヘッドを示すので、または、ファイルのその部分が複数のソースブロックに分割され、一部のソースブロックの符号化シンボルが他のソースブロックの符号化シンボルよりも高い比率で失われるので、または、FiTiが整数ではないので、FiTiよりもわずかに多くのパケットが、ファイルの部分iを復元するために必要であり得る。配信されるすべてのファイルの優先順位が同一であることが望ましい場合、FiTi≒FTとなるようにTiが設定される。UFD一括ファイル配信方法の多くの詳細情報は、送信機と受信機の両方について、UFDUEPファイル配信方法とほとんど同一なので省略する。UFD一括ファイル配信方法は、一括ファイル配信とUEPファイル配信の両方を同時に実現するように拡張することができ、すなわち、束の中の各ファイルの優先順位は異なるように設定され得る。さらに、UFD一括ファイル配信方法は、複数のファイルの優先順位付けられた配信と、ファイルの部分の優先順位付けられた配信との、両方の配信を、適切なシグナリングによってサポートすることができる。たとえば、UFD一括ファイル配信方法を使って、3個のオブジェクトが符号化され送信されることになる場合、最初の2個のオブジェクトは、異なる優先順位を有する同じファイルの異なる部分であってよく、3番目のオブジェクトは、さらに異なる優先順位を有する異なるファイルであってよい。受信機は、多くの要因に基づいて、一括ファイルおよびまたはファイルの部分のいずれの復元に受信機が関心があるかを決定し、他のファイルまたはファイルの部分とは独立に、そうしたファイルまたはファイルの部分のみを復元することができる。当業者が認識するように、本開示を読むと、UFD一括ファイル配信方法の多くの可能な代替的なバージョンがある。UFD一括ファイル配信の単純な例として、各ファイルのサイズが32KBの、32個のファイルの束が配信されるべきであり、各ファイルの優先順位が同じであるとする。T1024オクテットであるとする。この場合、各i031について、Tiの値は32オクテットである。各パケットは、32個のファイルの各々のための32オクテットの符号化シンボルと、パケット中で32個の符号化シンボルを特定するUFSIとを含む。この例では、32個のサイズが等しいファイルの各々からのソースシンボルを含む、1024個のパケットがあり、これらのパケットは、0から1023の範囲のUFSIを有するパケットである。この例では、1024個の追加の修復シンボルが、各ファイルについて生成され、1024から2047の範囲のUFSIを有する追加の1024個のパケット中で送信されるものとする。図12は、パケット喪失の関数として、このUFD一括ファイル配信の例の復元特性を示す。この例では、50に達するパケット喪失率において、32個のファイルすべてを、UFD一括ファイル配信方法を使って信頼性をもって復元することができ、これは、各ファイルを別々に符号化して送信した場合に32個のファイルすべての信頼性のある配信が可能になる約25のパケット喪失率に対して、かなり改善されている。ユニキャスト修復要求のネイティブなHTTPサポートのための方法ファイルまたはファイルの部分は、受信機によるファイルまたはファイルの部分へのアクセス権を記憶および提供するために標準的なHTTPウェブキャッシュサーバによって使われ得る関連するURLを有する、HTTPファイルへと編成されてよく、またはHTTPファイルとして利用可能にされてよい。HTTPファイルとして利用可能にされる、その元の順序のファイルまたはファイルの部分は、本明細書では元順序HTTPファイルと呼ばれる。一般に、ユニキャスト修復要求のネイティブなHTTPサポートのための方法は、SBNおよびESIに基づいて、HTTPファイルのソースブロックのシンボルおよびサブシンボルの修復要求を、HTTPファイル内の標準的なHTTPオクテット範囲要求へと変換することができる。これによって、標準的なHTTPウェブキャッシュサーバが、これらの修復要求をサービスできるようになり、HTTPファイルがソースブロックおよびソースブロック内のソースシンボルへとどのように分割されるかを理解する、専用のHTTPウェブキャッシュサーバを大量に配備する必要がなくなる。そのような状況では、システマチックなFEC符号が使用中である場合、セッションの一部、たとえばブロードキャストマルチキャストセッションにおいて、修復シンボルのみを送信するのが有利であることが多い。それは、受信機が、ユニキャスト修復要求においてソースシンボルのみを要求できるようになるからである。このことには、HTTPファイル、または、以下でさらに詳細に説明されるようなHTTPファイルの単純な順序変更の変換しか、標準的なHTTPウェブキャッシュサーバであってよいユニキャスト修復サーバに提供しなくてもよいという利点があり、HTTPファイルの定義およびHTTPファイルの配信の管理が、FEC符号化と独立なのでより簡単になる。別の利点は、セッションにおいてソースシンボルが送信されない場合、ソースシンボルのすべてが欠けているので、受信機がユニキャスト修復要求においてソースシンボルの任意のシーケンスを要求できるということであり、このことは、ソースシンボルの連続的なシーケンスに対する修復要求を可能にするので好ましいことがある。たとえば、完全な復元特性を有するFEC符号が使われ、ある部分のソースブロックが1000個のソースシンボルを含み、700個の修復シンボルがソースブロックのために受信されるものとする。次いで、受信機は、ユニキャスト修復要求において、ソースブロックの最初の300個の連続するソースシンボルを要求し、これらのソースシンボルを700個の修復シンボルと組み合わせてソースブロックを復元することができる。ソースシンボルがHTTPファイル中で連続的である場合、単一のHTTPオクテット範囲要求を使って、300個の連続するソースシンボルのすべてを要求して受信することができる。受信機は、プレフィックス要求を必ずしも行う必要はないが、一部の場合には、それを行うのがよりシンプルである。この要求は、特定の数のバイトまたはシンボルに対するものである。一部の場合には、受信機は、受信された修復シンボルの数と、受信されることになるファイルまたはオブジェクトの中に含まれると予想されるソースシンボルの数とに基づいて、要求すべきソースシンボルの数を決定する。他の場合には、受信機は、スケジューリング動作を実行してもよく、このとき受信機は、すでに受信した修復シンボルのみを使ってどのように復号するかを決定するので、必要なソースシンボルのより具体的な数を知ることができる。たとえば、修復シンボルの一部が他の修復シンボルの冗長部分であることがあり、この場合、より多くのソースシンボルが必要であり得る。他の場合には、必要なソースシンボルはより少数であると判明することがある。受信機は、FECOTIに基づいて、特定のペアに対応する元順序HTTPファイルのソースシンボルに対する要求を、HTTPオクテット範囲要求へと変換することができる。たとえば、ファイルのFECOTIがであり、要求されることになるソースシンボルのSBNがAであり、ソースシンボルのESIがBであるものとし、簡単にするために、N1、すなわち、ソースブロックがこの例ではファイル構造のサブブロックへとさらに分割はされないものとする。次いで、受信機は、RaptorQSpecのセクション44で説明された方法をたとえば適用して、を決定することができ、ここで最初のZL個のソースブロックはKL個のソースシンボルを有し、残りのZS個のソースブロックはKS個のソースシンボルを有する。次いで、A、B、およびシンボルサイズTに基づいて、受信機は、ファイル内のソースシンボルの開始オクテットインデックスが式1に示される通りであると決定することができ、ファイル内のソースシンボルの終了オクテットインデックスは、EISITである。そして、受信機は、ソースシンボルに対して標準的なHTTPオクテット範囲要求を使うことができる。SIT×当業者が認識するように、これらの方法に対する多くの拡張および改善がある。たとえば、サブブロックが使われない場合には、複数の連続するソースシンボルが元順序HTTPファイルから要求されれば、単一のHTTPオクテット範囲要求が行われ得る。別の例として、HTTPウェブキャッシュサーバは、元順序HTTPファイルに加えて、またはその代わりに、修復シンボルを含むファイルを有してよく、または、元順序HTTPファイルはすでに、修復シンボルを含むように拡張されていてよく、受信機は、本明細書で説明された方法と同様の方法を使って、修復シンボルに対するHTTPオクテット範囲要求を行うことができる。改善の別の例として、これらの方法は、当業者が認識するような方法と同様の方法を使って、サブブロックが使われる場合を扱うように拡張され得る。たとえば、受信機は、RaptorQSpecのセクション44で説明された方法を使ってを決定することができ、このときソースブロックの最初のNL個のサブブロックのサイズはTL×Alであり、ソースブロックの残りのNS個のサブブロックのサイズはTS×Alである。そして、A、B、およびシンボルサイズTに基づいて、受信機は、ソースシンボルに対応するファイル内のN個のサブシンボルの開始オクテットインデックスおよび終了オクテットインデックスを決定し、標準的なHTTPオクテット範囲要求を使ってこれらのオクテットに対する要求を行うことができる。別の例として、受信機は、FECOTIに基づいて、特定のUFSIに対応するファイルまたはファイルの部分のソースシンボル対する要求を、HTTPオクテット範囲要求へと変換することができる。以下の方法は、受信機による標準的なHTTPバイト範囲要求を使ってHTTPファイルのシンボルを復元する際の効率を大幅に改善することができ、それと同時に、標準的なHTTPウェブキャッシュサーバを使って、要求されたオクテット範囲要求を受信機に配信する。説明されるようなHTTPオクテット範囲要求をサポートするための単純な方法は、元順序HTTPファイルを使うことである。この方法には、HTTPウェブキャッシュサーバのための元順序HTTPファイルを生成するのに、元のファイルまたはファイルの部分の変換が必要ないという利点があるが、各ソースブロックに対して連続的なソースシンボルのみが要求される場合であっても、ソースシンボルを要求するために多くの異なるHTTPオクテット範囲要求が必要になり得るという、欠点がある。これには、少なくとも2つの理由がある。すなわち、複数のソースブロックと、各ソースブロックにおいて欠けているソースシンボルが存在することがあり、その場合、各ソースブロックに対して別々のオクテット範囲要求が必要になり得る。ソースブロック当たり複数のサブブロックが存在することがあり、ソースシンボルのためのサブシンボルが元順序HTTPファイルに置いて連続的ではないことがあるので、1つのソースブロックから単一のソースシンボルを要求するのにも、ソースシンボルを含む複数のサブシンボルに対する、複数のHTTPオクテット範囲要求が必要になり得る。上で説明されたHTTPオクテット範囲要求をサポートするための有利な方法はまず、元のファイルまたはファイルの部分のFECOTIに基づいて、本明細書ではUFSI順序HTTPファイルと呼ばれる新しい形式へと、ファイルまたはファイルの一部を再編成する。この方法は、複数のソースブロックがある場合、およびまたはソースブロック当たり複数のサブブロックがある場合に有用である。UFSI順序HTTPファイルの中のデータの順序は、UFSI0のファイルシンボル、UFSI1のファイルシンボル、UFSI2のファイルシンボル、などの順序であり、すなわち、UFSI順序HTTPファイルの中のデータの順序は、FECOTIによって決定されるような、連続的なUFSIの昇順に従って並べられたファイルシンボルへと編成される。URLは、UFSI順序HTTPファイルと関連付けられてよく、URLは、HTTPウェブキャッシュシステムへと与えられ得る。次いで受信機は、HTTPオクテット範囲要求を使って、必要に応じてUFSI順序HTTPファイルの部分を要求することができる。UFSI順序HTTPファイルの1つの利点は、受信機がソースブロックの各々からほぼ同じ数の修復シンボルを受信した場合に、元のファイルまたはファイルの部分を復元するのに十分なソースシンボルを取得するのに必要とされる、HTTPオクテット範囲要求の数を最小限にできるということであり、たとえば、各ソースブロックに対して全く同じ数の修復シンボルが受信される場合には、1つのHTTPオクテット範囲要求で十分であり得る。たとえば、元のファイルまたはファイルの部分のZ個のソースブロックの各々から、サイズTの最初のL個のソースシンボルを受信するには、UFSI順序HTTPファイルの最初のL×T×Z個の連続的なオクテットに対する要求で十分である。KL個の修復シンボルが、Z個のソースシンボルの各々の1つまたは複数のセッションにおいて受信される場合、かつ、FEC符号が理想的な復元特性を有する場合、HTTPファイルをFEC復号するには、HTTPオクテット範囲要求から受信されるL×T×Z個のオクテットで十分であり、この例では、Z個のソースブロックの各々の中にあるソースシンボルの数はKであると仮定される。上で説明されたHTTPオクテット範囲要求をサポートするための別の有利な方法はまず、元のファイルまたはファイルの部分のFECOTIに基づいて、本明細書ではSS順序HTTPファイルと呼ばれる異なる新しい形式へと、ファイルまたはファイルの一部を再編成する。この方法は、ソースブロック当たり複数のサブブロックがある場合に有用である。なぜなら、この場合、各ソースシンボルは、元のファイルまたはファイルの部分の連続的な部分ではないことがあり、すなわち、ソースシンボルのサブシンボルが、元のファイルの順序ではソースブロック全体に分散し得るからである。SS順序HTTPファイルの中のデータの順序は、最初のソースブロックのすべてのソースシンボル、続いて2番目のソースブロックのすべてのソースシンボル、続いて3番目のソースブロックのすべてのソースシンボル、などという順序であり、すなわち、SS順序HTTPファイルの中のデータの順序は、FECOTIによって決定されるように、ソースブロック内の連続的なESIの昇順に従って並べられたソースシンボルへと編成され、連続的なSBNの昇順の順序でのソースブロックの連結である。URLは、SS順序HTTPファイルと関連付けられてよく、URLは、HTTPウェブキャッシュシステムへと与えられ得る。次いで受信機は、HTTPオクテット範囲要求を使って、必要に応じてSS順序HTTPファイルの部分を要求することができる。受信機が、ソースブロックの各々から異なる数の修復シンボルを受信する場合には、SS順序HTTPファイルは特に有利である。たとえば、各々1000個のソースシンボルを有する2つのソースブロックがあり、受信機が、1つまたは複数のセッションから、第1のソースブロックのために900個の修復シンボルを受信し、第2のソースブロックのために100個の修復シンボルを受信する場合、受信機は、SS順序HTTPファイルの最初のT×100オクテットに対する1つの要求を行い、第1のソースブロックのための100個のソースシンボルを受信することができ、受信機は、SS順序HTTPファイルのオクテットT×10001からT×1900に対する別の要求を行い、第2のソースブロックのための900個のソースシンボルを受信することができ、この例では、Tは両方のソースブロックのオクテット単位でのシンボルサイズである。上で説明された方法の両方の組合せも使われてよく、すなわち、UFSI順序HTTPファイルとSS順序HTTPファイルの両方が、異なるURLを通じて受信機に対して利用可能にされてよく、受信機は、2つの異なる形式のHTTPファイルに対して、HTTPオクテット要求の組合せを使ってよい。たとえば、各々1000個のソースシンボルを有する10個のソースブロックがある場合、かつ、1つまたは複数のセッションにおいて、最初の8個のソースブロックの各々のために800個の修復シンボルが受信され、9番目のソースブロックのために820個の修復シンボルが受信され、10番目のソースブロックのために500個の修復シンボルが受信される場合、受信機は、UFSI順序HTTPファイルに対するHTTPオクテット範囲要求を行い、10個のソースブロックの各々のために200個のソースシンボルを受信でき、SS順序HTTPファイルに対する追加のHTTPオクテット範囲要求を行い、10番目のソースブロックのための追加の300個のソースシンボルを受信できる。この例では、受信機は、9番目のソースブロックのために不必要な20個のソースシンボルを受信し得るが、一部の場合には、より少数のHTTPオクテット範囲要求を使って、いくつかのソースブロックのために必要最小限よりも多くのオクテットを要求することは、はるかに多数の異なるHTTPオクテット範囲要求が必要になり得る、各ソースブロックのためにちょうど必要な数のソースシンボルを要求することよりも、効率的であり得る。当業者が認識するように、これらの方法に対する多くの変形形態がある。たとえば、HTTPファイル、UFSI順序HTTPファイル、およびSS順序HTTPファイルが、要求に対して利用可能にされ得る。別の例として、SS順序HTTPファイルは、分割されて多数のHTTPファイルとして利用可能にされてよく、そのようなHTTPファイルの1つが、各ソースブロックのためのものである。変形形態の他の例として、HTTPに基づくもの以外の方法およびプロトコル、たとえば、RTPUDP、またはUDPの上層に構築されたプロプライエタリプロトコルに基づく方法が用いられてよい。ハードウェアシステムおよび例上で説明された方法およびシステムは、ハードウェア、ソフトウェア、およびまたは、プログラムコードもしくは他の命令を格納する適切に体系化されたコンピュータ可読媒体として、実装され得る。上記の教示を使い得るシステムのいくつかの例が、本明細書で与えられる。図13は、パケットを送信するのに使われ得るような多段階の符号化を使う、本明細書で説明されたようなファイル配信システムの一部としての、通信システム1300のブロック図である。当然、他の符号およびまたはハードウェアが、代わりに使われてよい。通信システム1300において、入力ファイル1301、または入力ストリーム1305が、入力シンボル生成器1310に与えられる。入力シンボル生成器1310は、入力ファイルまたは入力ストリームから、1つまたは複数の入力シンボルISISのシーケンスを生成し、各入力シンボルは、値および位置を有する。上で説明されたように、入力シンボルの可能な値、すなわちそのアルファベットは、通常は2M個のシンボルのアルファベットなので、各入力シンボルは、入力ファイルのMビットを符号化する。Mの値は一般に、通信システム1300を使って決定されるが、汎用システムは、Mが使用ごとに変化し得るように、入力シンボル生成器1310に対するシンボルサイズ入力を含み得る。入力シンボル生成器1310の出力は、エンコーダ1315に与えられる。静的鍵生成器1330は、静的鍵S0S1のストリームを生成する。生成される静的鍵の数は一般に限られており、エンコーダ1315の具体的な実施形態に依存する。静的鍵の生成は、後でより詳細に説明される。動的鍵生成器1320は、エンコーダ1315によって生成されることになる各出力シンボルのための、動的鍵を生成する。各動的鍵は、同じ入力ファイルに対する動的鍵の大部分が一意になるように生成される。たとえば、LubyIは、使用され得る鍵生成器の実施形態を説明する。動的鍵生成器1320および静的鍵生成器1330の出力は、エンコーダ1315に与えられる。動的鍵生成器1320によって与えられる各鍵Iから、エンコーダ1315は、入力シンボル生成器によって与えられる入力シンボルから、値Bを有する出力シンボルを生成する。エンコーダ1315の動作は、以下でより詳細に説明される。各出力シンボルの値は、各出力シンボルの鍵に基づいて、入力シンボルの1つまたは複数と、場合によっては入力シンボルから計算された1つまたは複数の冗長シンボルとの何らかの関数によって生成される。特定の出力シンボルを生じさせる入力シンボルおよび冗長シンボルの収集は、本明細書では、出力シンボルの関連するシンボルまたは単に出力シンボルの関連物と呼ばれる。関数および関連物の選択は、以下でより詳細に説明される処理に従って行われる。常時ではないが通常、Mは、入力シンボルと出力シンボルに対して同一であり、すなわち、入力シンボルと出力シンボルの両方が、同じ数のビットを符号化する。いくつかの実施形態では、関連物を選択するために、入力シンボルの数Kがエンコーダ1315によって使われる。Kが事前に知られていない場合、たとえば入力がストリーミングファイルである場合、Kは単に推定値であってよい。値Kはまた、入力シンボルおよびエンコーダ1315によって生成される任意の中間シンボルのための記憶領域を割り当てるために、エンコーダ1315によって使われ得る。エンコーダ1315は、出力シンボルを送信モジュール1340に与える。送信モジュール1340はまた、動的鍵生成器1320から、そのような出力シンボルの各々の鍵を与えられる。送信モジュール1340は出力シンボルを送信し、使われる変調方法に応じて、送信モジュール1340はまた、送信される出力シンボルの鍵についての何らかのデータを、チャネル1345を通じて受信モジュール1350に送信し得る。チャネル1345は消失通信路であると想定されるが、これは通信システム1300の適切な動作の要件ではない。送信モジュール1340が、出力シンボルおよびその鍵についての任意の必要なデータをチャネル1345へ送信するようになされ、受信モジュール1350が、シンボルおよび場合によってはその鍵についての何らかのデータをチャネル1345から受信するようになされる限り、モジュール1340、1345、および1350は、任意の適切なハードウェアコンポーネント、ソフトウェアコンポーネント、物理媒体、またはこれらの任意の組合せであってよい。Kの値は、関連物を決定するために使われる場合、チャネル1345を通じて送信されてよく、または、エンコーダ1315とデコーダ1355との合意によって前もって設定されてもよい。図13に示される他の要素も、モジュール、ステップ、処理などとして説明されるかどうかに関わらず、ハードウェア、ソフトウェア、およびまたは電気的な可読媒体に記憶されたプログラムコードを用いて、実装され得る。上で説明されたように、チャネル1345は、リアルタイムのチャネル、たとえば、テレビジョン送信機からテレビジョン受信機への、インターネットもしくはブロードキャストリンクを通じた経路、または、ある点から別の点への電話接続であってよく、またはチャネル1345は、CDROM、ディスクドライブ、ウェブサイトなどのような、記憶チャネルであってよい。チャネル1345は、リアルタイムチャネルと記憶チャネルの組合せ、たとえば、ある人物がパーソナルコンピュータからインターネットサービスプロバイダへと電話線を通じて入力ファイルを送信するときに形成されるチャネルであってもよく、入力ファイルはWebサーバに記憶され、その後インターネットを通じて受信者に送信される。チャネル1345は消失通信路であると想定されるので、通信システム1300は、受信モジュール1350から出た出力シンボルと、送信モジュール1340へと入る出力シンボルとの間に、1対1の対応を想定しない。実際には、チャネル1345がパケットネットワークを含む場合、通信システム1300は、任意の2つ以上のパケットの相対的な順序が、チャネル1345を通じた送信において保存されると、想定できないこともある。したがって、出力シンボルの鍵は、上で説明された鍵方式の1つまたは複数を使って決定され、出力シンボルが受信モジュール1350から出る際の順序によって決まるとは限らない。受信モジュール1350は、出力シンボルをデコーダ1355に与え、これらの出力シンボルの鍵について受信モジュール1350が受信する任意のデータは、動的鍵生成器1360に与えられる。動的鍵生成器1360は、受信された出力シンボルのために動的鍵を再生成し、これらの動的鍵をデコーダ1355に与える。静的鍵生成器1363は、静的鍵S0S1を生成し、デコーダ1355に与える。静的鍵生成器は、符号化処理と復号処理の両方において使われる、乱数生成器1335へのアクセス権を有する。このアクセス権は、乱数がそのようなデバイスで生成される場合には、同じ物理デバイスへのアクセス権の形態であってよく、または、理想的な挙動を実現するための乱数の生成のための同じアルゴリズムに対するアクセス権の形態であってよい。デコーダ1355は、動的鍵生成器1360および静的鍵生成器1363によって与えられる鍵を対応する出力シンボルとともに使い、入力シンボルISISを復元する。デコーダ1355は、復元された入力シンボルを入力ファイル再組立器1365に与え、入力ファイル再組立器1365は、入力ファイル1301または入力ストリーム1305のコピー1370を生成する。ファイル配信は、複数の受信機およびまたは複数の送信機によって行われ得る。これらの考え方は、図14~図15に示されている。図14は、1つの受信機2402が、3つの送信機2404から3つのチャネル2406を通じて、データを受信する構成を示す。この構成を使って、受信機が利用可能な帯域幅を3倍にすることができ、または、任意の1つの送信機から全体のファイルを取得するのに十分広い帯域幅が利用可能ではない送信機を扱うことができる。示されるように、各送信機2404は、値のストリームSを送信する。各々のSの値は、出力シンボルBおよび鍵Iを表し、これらの使用は上で説明されている。たとえば、値Sは、送信機2402において生成される出力シンボルのシーケンスにおける、nA番目の出力シンボルおよびnA番目の鍵である。送信機の作業が重複しないように、1つの送信機からの鍵のシーケンスは、好ましくは、他の送信機からの鍵のシーケンスとは別物である。このことは、シーケンスSが送信機の関数であるという事実によって、図14において示されている。送信機2402は、作業が重複しないように、同期または協調されなくてもよいことに留意されたい。実際には、協調することなく、各送信機は、そのシーケンス中で異なる位置にある可能性が高い。図15では、1つの入力ファイル2502のコピーが、複数の送信機2504に与えられる。送信機2504は、入力ファイル2502のコンテンツから生成された出力シンボルを、チャネル2506を通じて受信機2508へと独立に送信する。示されている2つの送信機の各送信機は、受信機のデコーダが入力ファイル全体を復元できるまでに、2個の出力シンボルしか送信する必要がなくてよい。2つの受信機および2つの送信機を使うと、受信機ユニット2510によって受信される情報の総量は、1つのチャネル2506を通じて入手可能な情報の4倍であり得る。情報の量は、たとえば、送信機が同じデータを両方の受信機にブロードキャストする場合には、単一のチャネル情報の4倍よりも少なくなり得る。その場合、データがいずれかのチャネルで失われると、受信機ユニット2510における情報の量は、少なくとも2倍であり、それより多くなることが多い。送信機が1つの信号しかブロードキャストしない場合でも、受信機が異なる時間において送信の範囲にあれば、各送信機を聴取する受信機が2つ以上あることが有利であることに留意されたい。図15では、受信機ユニット2510は、図1に示される、受信機150、デコーダ155、鍵生成器160、および入力ファイル再組立器165の機能と同様の機能を実行する。いくつかの実施形態では、入力ファイル2502は、コンピューティングデバイスが一方の送信機に対する1つの出力および他方の送信機に対する別の出力を提供できるように、2つのエンコーダを有する1つのコンピューティングデバイスにおいて符号化される。これらの例の他の変形形態は、本開示を検討することで明らかであろう。本明細書で説明される符号化の装置および方法は、他の通信状況においても使われてよく、インターネットのような通信ネットワークには限定されないことを理解されたい。たとえば、コンパクトディスク技術も、消失符号およびエラー訂正符号を使って、傷のついたディスクの問題に対処し、ディスク上に情報を記憶する際に、連鎖反応符号を使用することで利益を受ける。別の例として、衛星システムは、送信のための出力要件を犠牲にするために消失符号を使って、出力を下げることによってより多くのエラーを意図的に許容することがあり、この用途においては連鎖反応符号化が有用である。また、消失符号は、情報の記憶の信頼性のための、RAIDシステムの開発に使われてきた。したがって、本発明は、喪失またはエラーが多い可能性のあるデータについての問題に対処するために符号が使われる、上の例のような他の用途で有用であることがわかり得る。いくつかの好ましい実施形態では、上で説明された通信処理を実行するための命令のセットが、喪失が多い可能性のある通信媒体を通じて通信する、2つ以上の多目的コンピューティングマシンへ与えられる。マシンの数は、1つの送信機および1つの受信機から、任意の数の送信およびまたは受信するマシンにまで、わたり得る。マシンを接続する通信媒体は、有線媒体、光学媒体、ワイヤレス媒体などであってよい。上述の通信システムには多くの使用法があり、それらはこの説明から明らかであろう。HTTPストリーミングサーバを用いたブロック要求ストリーミングシステムが、上で説明されたようにファイルを配信し得る。以下では、そのようなシステムの例示的な実装形態が説明される。HTTPストリーミングでは、ソースは、標準的なウェブサーバおよびコンテンツ配信ネットワークであってよく、標準的なHTTPを使用してよい。クライアント側では、クライアントによってシームレスに一緒につなぎ合わされた個々のセグメントに対して、HTTPを使って要求が行われ得る。HTTPストリーミングの利点には、標準的な既存のインフラを使用することがある。図16は、ファイルを配信し得るブロック要求ストリーミングシステムの簡略図を示す。図16では、取込システム103を含むブロックサービングインフラストラクチャ101を含むブロックストリーミングシステム100が示されており、取込システム103は、コンテンツ102を取り込み、取込システム103とHTTPストリーミングサーバ104の両方へアクセス可能なコンテンツ記憶装置110へとそのコンテンツを記憶することによって、HTTPストリーミングサーバ104によるサービスのためにそのコンテンツを準備してパッケージングするためのものである。示されるように、システム100は、HTTPキャッシュ106も含み得る。動作において、HTTPストリーミングクライアントのようなクライアント108は、要求112をHTTPストリーミングサーバ104へ送信し、HTTPストリーミングサーバ104またはHTTPキャッシュ106から応答114を受信する。各場合において、図16に示される要素は、少なくとも一部は、プロセッサまたは他の電子回路で実行されるプログラムコードを含むソフトウェアで実装されてよい。図17で示されるように、メディアブロックは、たとえば、HTTPサーバ、コンテンツ配信ネットワークデバイス、HTTPプロキシ、FTPプロキシもしくはサーバ、または何らかの他のメディアサーバもしくはシステムであってよい、ブロックサービングインフラストラクチャ101内に記憶されてよい。ブロックサービングインフラストラクチャ101は、たとえば、インターネットのようなインターネットプロトコルネットワークであってよい、ネットワーク122に接続される。ブロック要求ストリーミングシステムクライアントは、6個の機能的コンポーネント、すなわち、上で説明されたメタデータを与えられ、メタデータによって示される複数の利用可能なブロックの中から要求されるべきブロックまたは部分ブロックを選択する機能を実行する、ブロック選択器123、ブロック選択器123から要求命令を受信し、規定されたブロック、ブロックの部分、または複数のブロックに対する要求を、ネットワーク122を通じてブロックサービングインフラストラクチャ101へ送信し、返答としてそのブロックを含むデータを受信するのに必要な動作を実行する、ブロック要求器124、さらには、ブロックバッファ125、バッファモニタ126、メディアデコーダ127、およびメディアの利用を容易にする1つまたは複数のメディアトランスデューサ128を、有するものとして示されている。ブロック要求器124によって受信されるブロックデータは、一時的な記憶のために、メディアデータを記憶するブロックバッファ125へと渡される。あるいは、受信されたブロックデータは、図16に示されるように、ブロックバッファ125へと直接記憶されてもよい。メディアデコーダ127は、ブロックバッファ125によってメディアデータを与えられ、メディアトランスデューサ128へ適切な入力を与えるために必要な変換を、このデータに対して実行し、メディアトランスデューサ128は、メディアをユーザの利用または他の利用に適切な形態にする。メディアトランスデューサの例には、携帯電話、コンピュータシステムまたはテレビにおいて見出されるような、視覚ディスプレイデバイスが含まれ、スピーカまたはヘッドフォンのような音声表現デバイスも含まれ得る。バッファモニタ126は、ブロックバッファ125のコンテンツに関する情報を受信し、この情報および場合によっては他の情報に基づいて、本明細書で説明されるような、要求すべきブロックの選択を決定するのに使われるブロック選択器123へ、入力を与える。ブロック要求ストリーミングシステムは、1つまたは複数のコンテンツサーバへ要求を行う、1つまたは複数のクライアントを含む。取込システムは、1つまたは複数の取込プロセッサを含み、取込プロセッサは、コンテンツを受信し、BRSSによる使用のためにコンテンツを処理し、コンテンツサーバへアクセス可能な記憶装置に、場合によっては取込プロセッサによって生成されたメタデータとともに、コンテンツを記憶する。BRSSは、コンテンツサーバと協調するコンテンツキャッシュも含み得る。コンテンツサーバおよびコンテンツキャッシュは、URLを含むHTTP要求の形態でファイルまたはセグメントに対する要求を受信する、従来のHTTPサーバおよびHTTPキャッシュであってよく、URLによって示されるファイルまたはセグメントのすべてよりも少数のものを要求するために、オクテット範囲も含み得る。クライアントは、HTTPサーバの要求を行い、そうした要求への応答を処理する、従来のHTTPクライアントを含んでよく、ここでHTTPクライアントは、要求を作成し、その要求をHTTPクライアントへ渡し、HTTPクライアントから応答を取得し、クライアントデバイスによる再生のために表示プレーヤーへとその応答を与えるためにその応答を処理する、新規のクライアントシステムによって動作させられる。通常、クライアントシステムは、どのメディアが必要になるかを事前には知らず、そのため、受信されるとすぐに、または受信の後まもなく、メディアが消費されるという点で、これはストリーミングシステムと呼ばれる。その結果、応答の遅延および帯域幅の制約は、表示に遅延を引き起こすことがあり、たとえば、ユーザが表示を見ている箇所にストリームが追いつくと、表示に一時停止が生じる。良好な品質であると知覚される表示を提供するために、クライアント側、取込側、またはこれら両方のいずれかにおいて、いくつかの細部がBRSSに実装され得る。一部の場合には、実装される細部は、ネットワークにおけるクライアントとサーバとのインターフェースを考慮して、またはそれに対応するようになされる。いくつかの実施形態では、クライアントシステムと取込システムの両方が改善を認識し、他の実施形態では、片側のみが改善を認識する。そのような場合、片側が改善を認識していなくても、システム全体が改善から利益を得て、他の場合には、双方が改善を認識する場合にのみ利益が生じるが、片側が改善を認識しなくても、システムは破綻することなく動作し続ける。図18に示されるように、様々な実施形態に従って、取込システムは、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。取込システムは、本明細書で論じられた方法の任意の1つまたは複数をシステムに実行させるように実行され得る、命令のセットを含み得る。システムは、コンピュータの形態である固有の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ、または、そのシステムによってとられるべき動作を規定する命令のセットを実行できる、任意のシステムであってよい。さらに、単一のシステムのみが示されているが、システムという用語は、本明細書で論じられた方法の任意の1つまたは複数を実行するための命令のセットを、個々にまたは一緒に実行する、システムの任意の集合も含むと、解釈されるべきである。取込システムは、取込プロセッサ302、実行中のプログラムコードを記憶できるメモリ304、およびディスク記憶装置306を含んでよく、これらのすべてが、バス300を介して互いに通信する。システムはさらに、ビデオディスプレイユニット308または陰極線管を含み得る。システムはまた、英数字入力デバイス310、および、コンテンツのソースを受信しコンテンツの貯えを配信するための、ネットワークインターフェースデバイス312を含み得る。ディスク記憶ユニット306は、本明細書で説明される方法または機能の任意の1つまたは複数を具現化する、命令の1つまたは複数のセットが記憶され得る、機械可読媒体を含み得る。命令はまた、システムによるその実行の間、完全にまたは少なくとも部分的に、メモリ304内、かつまたは取込プロセッサ302内に存在してよく、メモリ304および取込プロセッサ302も、機械可読媒体を構成する。図19に示されるように、様々な実施形態に従って、クライアントシステムは、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。クライアントシステムは、本明細書で論じられた方法の任意の1つまたは複数をシステムに実行させるように実行され得る、命令のセットを含み得る。システムは、コンピュータの形態である固有の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ、または、そのシステムによってとられるべき動作を規定する命令のセットを実行できる、任意のシステムであってよい。さらに、単一のシステムのみが示されているが、システムという用語は、本明細書で論じられた方法の任意の1つまたは複数を実行するための命令のセットを、個々にまたは一緒に実行する、システムの任意の集合も含むと、解釈されるべきである。クライアントシステムは、クライアントプロセッサ402、実行中のプログラムコードを記憶できるメモリ404、およびディスク記憶装置406を含んでよく、これらのすべてが、バス400を介して互いに通信する。システムはさらに、ビデオディスプレイユニット408または陰極線管を含み得る。システムはまた、英数字入力デバイス410、および、要求を送信し応答を受信するための、ネットワークインターフェースデバイス412を含み得る。ディスク記憶ユニット406は、本明細書で説明される方法または機能の任意の1つまたは複数を具現化する、命令の1つまたは複数のセットが記憶され得る、機械可読媒体を含み得る。命令はまた、システムによるその実行の間、完全にまたは少なくとも部分的に、メモリ404内、かつまたはクライアントプロセッサ402内に存在してよく、メモリ404およびクライアントプロセッサ402も、機械可読媒体を構成する。具体的な実施形態の例このセクションでは、RaptorQSpecで規定されるRaptorQFEC方式を使った、汎用的なオブジェクト配信のための完全に規定されたFEC方式の、特定の実施形態が説明される。UOSIFECペイロードIDが、簡素で改善されたオブジェクト配信能力を提供するために、RaptorQSpecにおけるRaptorQFEC方式とともに使われ得る。具体的には、より柔軟で簡単なサポートが、基本的なオブジェクト配信のために提供され、不均一誤り保護オブジェクト配信、一括オブジェクト配信、およびUEPオブジェクト配信と一括オブジェクト配信の組合せに対するサポートも提供される。適切なハードウェアおよびまたはソフトウェアを使って、通信デバイス間でUODRaptorQFEC方式を実装できることを理解されたい。FECペイロードIDの形式は、図2に示されるように4オクテットフィールドであり、この特定の実装形態では、32ビットの符号なしの整数である汎用ファイルシンボル識別子は、やはり32ビットの符号なしの整数である汎用オブジェクトシンボル識別子によって一般化される。UOSIは、そのペイロードIDを搬送するパケット内に含まれる符号化シンボルを特定するために、FECOTIとともに使われる、負ではない整数である。単一のオブジェクト、または複数のオブジェクト、または優先順位の異なる複数の部分に分割される単一のオブジェクト、またはこれらの任意の組合せの配信について、FECOTIは以下のように説明される。配信される各オブジェクトについて、FECOTIは、RaptorQFEC方式で規定されるものと同じであってよいことに留意されたい。配信は、dを何らかの正の整数としてd個のオブジェクトを含み得る。各オブジェクトは、同じファイルの異なる部分、または異なるファイル、またはこれらの組合せを含み得る。オブジェクトiのサイズFiと、オブジェクトiのために使われるべき符号化シンボルのサイズTiとの関係を使って、送信の際のオブジェクトiの優先順位を決定することができる。図20は、一般のFECOTIフィールドの例を示す。そのフィールドで用いられる、配信されるオブジェクトの数のための8ビットの符号なしの整数dがあり、示される例はd2の場合である。デフォルトの値は、d1であり得る。他のサブフィールドは、d個のオブジェクトの各々に対する、オブジェクトiに固有である一般のFECOTI要素を含み、一般のFECOTI要素は、216未満の正の整数でありオブジェクトiのためのシンボルのサイズをオクテット単位で示す、シンボルサイズTiに対する16ビットの符号なしの整数と、最大で240の負ではない整数でありオブジェクトiの転送長をオクテット単位で示す、オブジェクトiの転送長Fiに対する40ビットの符号なしの整数とを含む。適切なパディングが行われる。一般のFECOTIフィールドとは対照的に、図21に示されるような、方式固有のFECOTI要素が存在し得る。その例で示されるように、方式固有のFECOTI要素は、シンボル整列パラメータを含み、各オブジェクトに対する方式固有のFECOTI要素は、オブジェクトiのためのソースブロックの数Ziと、オブジェクトiのためのサブブロックの数Niとを含む。符号化された方式固有のオブジェクト送信情報は、オクテットのフィールドである。図21の例は、d2の場合である。そして、符号化されたFECOTIは、符号化された一般のFECOTIと符号化された方式固有のFECOTI要素との連結を含む、オクテットのフィールドであってよい。符号化されたFECOTIを用いたコンテンツ配信には、UODRaptorQFEC方式と、オブジェクト配信のためにUODRaptorQFEC方式を使用するコンテンツ配信プロトコルとを使った、デバイス間、コンピュータ間、システムのプログラム間での情報交換が伴い得る。CDPは、d、Alをエンコーダおよびデコーダに与えなければならず、各オブジェクトについてFi、Ti、ZiおよびNiを与えなければならない。エンコーダは、オブジェクトi自体を与えられる。UODRaptorQエンコーダ方式を用いるエンコーダは、送信されるべき各パケットについて、パケットのUOSIおよびd個のオブジェクトのための符号化シンボルを、CDPに供給する。CDPは、この情報を受信機に伝える。パラメータ選択の例が、ここで説明される。一例では、RaptorQSpecのセクション43で説明される例示的なパラメータの導出が、d個のオブジェクトの各々に対して独立に使用され適用され得る。ある例では、Al4オクテット、SS8であり、オブジェクトiのTiは好ましくは少なくともSS×Alオクテットであり、TiはAlの倍数であり、各符号化パケットのペイロードサイズは好ましくは少なくともTのサイズであり、TはTiのi1dにわたる和である。ソースブロックの構築では、RaptorQSpecのセクション441の手順が、d個のオブジェクトの各々に対して独立に適用され得る。符号化パケットの構築では、各符号化パケットは、d個のオブジェクトに対するUOSIおよび符号化シンボルを含む。RaptorQSpecのRaptorQFEC方式によって使われるFECペイロードIDのフォーマットと、UODRaptorQFEC方式によって使われるUOSIフォーマットとの互換性のために、UOSIフォーマットは特定のフォーマットであり得る。たとえば、各オブジェクトについて、UOSIの値Cから、オブジェクトiの対応するの値への対応付けは、BfloorおよびACB×Ziであり得る。同様に、各オブジェクトについて、オブジェクトiのの値から、対応するUOSIの値Cへの対応付けは、CAB×Ziである。各オブジェクトi1dについて、0からKTi1のUOSI値が、ソースブロック中のオブジェクトiのソースシンボルを交互の順序で特定し、KTiceilである。KTi以降のUOSI値は、RaptorQエンコーダを使って、オブジェクトiのソースシンボルから生成された修復シンボルを特定する。符号化パケットは、ソースシンボル、修復シンボル、またはソースシンボルと修復シンボルの組合せを含み得る。パケットは、オブジェクトiの同じソースブロックからの、任意の数のシンボルを含み得る。オブジェクトiのソースパケット中の最後のソースシンボルは、FEC符号化のために追加されたパディングオクテットを含み、これらのオクテットはパケット中に含まれるべきなので、シンボル全体のみが各パケットに含まれる。各符号化パケットで搬送される汎用オブジェクトシンボル識別子Cは、そのパケットで搬送される各オブジェクトのための第1の符号化シンボルのUOSIである。各オブジェクトのためのパケット中の後続の符号化シンボルは、連続的な順序でC1からCG1まで番号を付けられたUOSIを有し、ここでGは、パケット中の各オブジェクトのための符号化シンボルの数である。好ましい実装形態では、各符号化パケットにおいて、d個のオブジェクトの各々に対して1つの符号化シンボルがある。好ましい実装形態では、符号化パケットは、以下の手順に従って生成され送信される。各UOSI値C0123について、エンコーダは、以下のように符号化パケットを生成して送信し、符号化パケットのFECペイロードIDの値はUOSI値Cに設定され、i1dである各オブジェクトiに対して、エンコーダは、UOSI値Cに対応する値を決定し、RaptorQFEC方式RaptorQSpecの手順に従って、オブジェクトiからの値に対応するサイズTiの符号化シンボルEiを生成し、符号化シンボルEiを符号化パケットのペイロードに追加し、符号化パケットを送信する。受信機は、符号化パケットの総数を必ずしも知らなくてもよいことに留意されたい。これは、1つの特定の例である。本開示を読んだ後で、当業者はさらなる実施形態を想起し得る。他の実施形態では、有利には、上で開示された発明の組合せまたは副組合せが作られ得る。コンポーネントの例示的な構成は例示のために示されており、組合せ、追加、再構成などが、本発明の代替的な実施形態で考慮されることを理解されたい。したがって、本発明は、例示的な実施形態に関して説明されてきたが、当業者は、多くの修正が可能であることを認識するだろう。たとえば、本明細書で説明された処理は、ハードウェアコンポーネント、ソフトウェアコンポーネント、およびまたはこれらの任意の組合せを使って実装され得る。したがって、本明細書および図面は、限定ではなく例示であると見なされるべきである。しかし、特許請求の範囲において述べられる本発明のより広範な趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にあるすべての修正および等価物を包含することが意図されることが、明らかであろう。