JP6648211B2 - マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置 - Google Patents

Description

優先権の主張

（米国特許法第１１９条の下での優先権の請求）
本特許出願は、２００５年４月８日に提出され、譲受人に譲渡され、米国仮出願６０／６６９，５０５号、「移動体ブロードキャスト通信用途のためにファイル配信を拡張する方法および装置（Method and Apparatus to Enhance File Distribution for Mobile Broadcast Applications）」に対して優先権を請求するものであり、参照として明確に本明細書に組み込まれている。

Ｉ．分野
本発明は、概してデータ通信に関し、特に、マルチキャスト通信またはマルチキャスト通信環境におけるデータ通信システムでのファイル配信の拡張に関する。

ＩＩ．背景
ネットワークを地球規模で相互接続することで、地理的距離に関係なく、情報に非常に素早くアクセスできるようになる。図１はネットワークの地球規模の接続の簡単な概略図を示す。この接続は一般にインターネットと呼ばれ、同図中では参照符号２０を付している。インターネット２０は本質的に、階層レベルの異なる多数のネットワークである。インターネット２０は、インターネット技術標準化タスクフォース（Internet Engineering Task Force）（ＩＥＴＦ）が公表しているインターネットプロトコル（ＩＰ）の下で動作される。ＩＰの詳細は、ＩＥＴＦから発行されたコメントの要求（Request for Comments）（ＲＦＣ）７９１に見ることができる。

インターネット２０には様々な個々のネットワークが接続しており、多くの場合、これらはネットワークサイズによってローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）と呼ばれる。図１には、こうしたネットワークのいくつかである２２、２４、２６を示している。

各ネットワーク２２、２４、２６内では、様々な設備が接続し、相互に通信することができる。これの本発明の数例として、コンピュータ、プリンタ、サーバが挙げられ、これらは一般にノードと呼ばれる。ノードは、属するネットワークを超え、インターネット２０を介して通信する場合には、ＩＰに準拠したデータパケットを別のネットワーク内の関連するノードへ送信する必要がある。同様に、別のネットワーク内の関連するノードによって開始ノードへ送出されたデータパケットもＩＰと一致しなければならない。

タイプの異なる用途には、ＩＰと連係して動作する各種レベルのプロトコルが必要である。数例を挙げて例証する。ネットワーク２２内のノード２８が、ネットワーク２６内の別のノード３０からファイルをダウンロードしようとしたと仮定する。ファイルを転送するには、非常に多くの場合、ファイル転送プロトコル（ＦＴＰ）と呼ばれるより高次のプロトコルを使用する。ＦＴＰは、ＩＥＴＦより発行のＲＦＣ９５９に見ることができる。そのため、ノード３０がノード２８へ送信したデータパケットは、とりわけＦＴＰおよびＩＰと一致しなければならない。

別例として、ネットワーク２２内のノード２８が、インターネット２０を介して、また別のネットワーク２４内のノード３２が提示したウェブサイトをブラウジングする場合を挙げる。この場合は、ノード２８、３２は別のより高次なプロトコル、即ちハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用する。ＨＴＴＰについては、ＩＥＴＦが発行しているＲＦＣ２６１６に見ることができる。この場合にも、交換されたデータパケットは、とりわけＨＴＴＰおよびＩＰと一致している必要がある。

例証的なプロトコルＦＴＰ、ＨＴＴＰは、さらに別の中間レベルのプロトコル、即ち転送制御プロトコル（ＴＣＰ）によっても伝送できる。ＴＣＰはＲＦＣ７９３に見ることができる。ＴＣＰの下では、データを正確に伝送することが目的である。そのため、エラーを含んだデータは常に再伝送される。１対１のアプリケーションでは、ＴＣＰと、これに実装されたＦＴＰやＨＴＴＰのようなプロトコルとを採用することが一般的である。

技術の進歩により、データ集約型のデータ転送が可能となった。例えば、広帯域幅に対応可能なネットワークによって、通常は大容量のデータを保持したオーディオファイルやビデオファイルのようなマルチメディアファイルを交換することができるようになった。多数のノードがこうしたマルチメディアファイルを受信する場合には、従来のユニキャスト方法によるファイル送達では不十分であることが多い。とりわけ、まずファイルを複製し、その後で個々のファイルを各ノードへ送達しなければならない。したがって、１対多数のアプリケーションにおける増加する要求に対応でき、ブロードキャストまたはマルチキャストサービスでの使用に適した別タイプのプロトコルを開発する必要がある。

この要求を満たすために、マルチキャストファイル配信用途に好適な１方向移送上でのファイル送達（ＦＬＵＴＥ）プロトコルが考案された。ＦＬＵＴＥプロトコルは、ＩＥＴＦより２００３年１１月１４日に発行のＲＦＣ３９２６「ＦＬＵＴＥ−１方向移送上でのファイル送達（File Delivery over Unidirectional Transport）」に見ることができる。マルチキャストセッションでは、トラフィックの流れは幾分１方向的である。これは即ち、反対方向のデータの流れがあれば全て制限されるということである。こうした１方向的な使用は、１つの通信ソースが多数の受信側にデータを送信するブロードキャストまたはマルチキャスト用途では一般的である。

ＦＬＵＴＥプロトコルの下で伝送されたデータは、ＨＴＴＰおよびＦＴＰプロトコルでのようにＴＣＰ上に実装されるのではなく、ユーザデータグラムプロトコル(User Datagram Protocol)（ＵＤＰ）上に実装される。ＵＤＰの下では、エラーを含んだデータは通常再送信されない。データを正確に伝送するために、通常、ＦＬＵＴＥプロトコルは冗長においてデータを伝送し、エラー修正スキームを使用する。

ＦＬＵＴＥプロトコルを使用することにより、ファイル送達セッション中に１または複数のファイルが転送される。ファイルはＡＬＣパケットと呼ばれる非同期層符号化（ＡＬＣ）の形式のデータパケットにて運ばれる。各ファイルは、これの長さに応じて、１または複数のＡＬＣパケットにて識別される。ファイルはオブジェクトと呼ばれる。オブジェクトは、ファイル伝送テーブル（ＦＤＴ）に含まれたファイル属性(file attributes)によって識別される。このファイル属性は、受信側にて、ＡＬＣパケットからオリジナルのファイルを再構築する上で信頼される。受信したファイルオブジェクトは、関連のファイル属性が正確に受信されるまでは処理されない。ＦＤＴ受信の信頼性を高めるために、複写ＦＤＴインスタンスの間には、受信側へ送られたＡＬＣパケット内のペイロードデータが介在している。以前は、ＦＤＴファイルとコンテンツファイルは幾分併発的に伝送されていた。そのため、常に正常に受信されるわけではないコンテンツファイルがたとえ正確に受信された場合でも、受信側はＦＤＴを正確に受信し、ＦＤＴからファイル属性を抽出し、その後、受信したコンテンツファイルを処理する必要がある。即ち、受信したファイルの復号とその後の表示の成功は、ＡＬＣパケットの処理に必要なファイル属性のダウンロードの成功に幾分同時に依存する。このような依存性によって遅延が生じることは不可避であり、また、多くの場合、コンテンツ表示の質に悪影響を及ぼす。さらに、ユーザが正確なファイル属性を持っていない場合には、必要なファイル属性の取得を試みようとして通信チャネルの入力を複数回繰り返すことが非常に多い。これの結果、利用可能な通信リソースの最も効率的な使用でなくなってしまう可能性がある。

したがって、よりよい品質のブロードキャストのためのより効果的なスキームと、通信リソースをより経済的に利用するスキームとを提供する必要がある。

ブロードキャストサービスを提供する通信システムでは、ユーザはブロードキャスト用のファイルにアクセスできる。ブロードキャストファイルのコンテンツは１つの通信セッション中に送信される。ブロードキャストファイルの処理に必要なファイル属性は、別の通信セッションで別個に送信される。こうして配列することにより、コンテンツファイルよりも先にファイル属性を受信することで、ブロードキャストファイルをより効率的にダウンロードおよび処理できるようになる。

これらおよびこれ以外の特徴や利点は、添付の図面と以下の詳細な説明から当業者に明白となる。図面中、同様の部分には同様の参照符号を付している。

図１は、ネットワークの地球規模の接続の概略図である。 図２は、本発明の例証的な実施形態に関与するノードおよびネットワークの概略図である。 図３は、階層順序にあるプロトコルのスタックを示す概略図である。 図３Ａは、ＦＬＵＴＥプロトコルのより詳細な概略図である。 図４は、ＦＬＵＴＥプロトコルの下で動作するＣＦＤ方法の方法論を示す概略図である。 図５は、本発明の例証的な実施形態に従って動作するＣＦＤ方法を示す概略図である。 図６は、異なる時間ウィンドウ中に実行されるファイルの伝送および表示を示す時間線図である。 図７は、本発明の例証的な実施形態による、ファイルの取り出しおよび処理を示すフローチャートである。 図８は、本発明の例証的な実施形態によるファイル伝送を示すフローチャートである。 図９は、例証的なコンパクトなＡＬＣデータパケットを示す概略図である。 図１０は、無線通信上でのファイル伝送に適した別のコンパクトなパケットフォーマットを示す概略図である。 図１１は、本発明の例証的な実施形態による、ブロードキャストファイルを受信および処理するように構成されたノードの回路の一部を示す概略図である。 図１２は、本発明の例証的な実施形態による、ブロードキャストファイルを伝送するように構成されたノードの回路の一部の概略図である。

以下の説明は、全ての当業者が本発明を使用できるようにするために示される。また、以下の説明では説明の目的で詳細を述べている。当業者は、こうした詳細を使用しなくても本発明を実現できることを理解するはずである。別の場合では、不要な説明によって本発明を不明瞭化しないために、よく知られている構造および処理については詳述していない。そのため、本発明はここで示す実施形態に限定されるのではなく、ここで述べている原理および特徴と一致する最も広範囲に従うものである。

図２は、本発明の例証的な実施形態の簡略化した概略図を示している。システム全体を参照符号４０によって総体的に示している。図面を簡略化し説明を明瞭化するために、この通信システム４０では２つのネットワーク４２、４４のみ示す。ネットワーク４２、４４は、イントラネットまたはインターネットのようなバックボーンネットワーク４６で繋がれている。

この実施形態では、ネットワーク４２はサービスプロバイダによって操作されると仮定する。サービスプロバイダは、ネットワーク４２にノード４８をインストールする。この例では、ノード４８をブロードキャスト・サービスディストリビュータ（ＢＳＤ）と呼ぶ。コンテンツサーバ４８は、ブロードキャストコンテンツと、さらにこれに関連する、サービスプロバイダによって提供されたブロードキャスト情報とを保持することができる。

ネットワーク４４では、バックボーンネットワーク４６を介してサーバノード４８によって提供されたサービスを含むサービスを受信できる加入者ノード５０が存在する。この実施形態では、ノード５０は無線装置として表されており、このノード５０の例のいくつかには、パーソナル・デジタル・アシスタント（ＰＤＡ）、モバイルコンピュータ、携帯電話がある。ネットワーク４４は、米国のＴＩＡ／ＥＩＡ（電気通信業界団体／米国電子工業会）を含む国際標準化機関である３ＧＰＰ（登録商標）２（第３次世代パートナーシッププロジェクト２）によって説明するｃｄｍａ２０００規格のような無線技術をサポートする。ネットワーク４０はこれ以外の標準、例えば、様々な欧州の標準実体が調整およびサポートする３ＧＰＰ（第３世代パートナーシッププロジェクト）によって公表されたＷＣＤＭＡ（登録商標）（広帯域符号分割多重アクセス）標準をサポートできる点について留意されたい。別の例として、送リンク専用（ＦＬＯ）ネットワークで使用する無線業界促進標準化における様々な実体の機関である転ＦＬＯフォーラムが開発した標準を挙げる。

加入者ユニット５０は、無線アクセスネットワーク（ＲＡＮ）５２を介してネットワーク４４と通信する。ＲＡＮ５２は、複数の基地局（ＢＳ）６６Ａ〜６６Ｎに接続した基地局制御装置／パケットデータ制御機能（ＢＳＣ／ＰＤＦ）５４を含む。パケットデータ・サービスノード（ＰＤＳＮ）６８とブロードキャスト・サービングノード（ＢＳＮ）７０がネットワーク４４内で実現される。ＰＤＳＮ６８とＢＳＮ７０の両方は、ネットワーク４４内のバックボーンネットワーク４６とＲＡＮ５２をインターフェースする機能を果たす。ＰＤＳＮ６８が主にユニキャスト通信の利用に対応しているのに対し、ＢＳＮ７０はむしろマルチキャスト通信またはブロードキャスト通信を扱う場合向けにインストールされることが多い。本明細書では、「マルチキャスト」、「ブロードキャスト」という用語を相互交換可能な意味で使用している。

ネットワーク４４内には、ＢＳＮ７０に接続したブロードキャスト／マルチキャストサービス（ＢＣＭＣＳ）コンテンツサーバ６３と呼ばれる別のサーバも存在する。一般に、ＢＣＭＣＳコンテンツサーバ６３は、ブロードキャストコンテンツと、これに関連した、コンテンツサーバ４８から提供されたものと、バックボーンネットワーク４６を介して転送されたものとを含む、ブロードキャストコンテンツのデータとを事前に記憶する。

この例証的な実施形態では、いくつかのノード間での通信を、無線で実施されたものとして表している。しかし、常にこの限りではない点を理解すべきである。これ以外の様々な手段によるノード間の非無線通信も適用可能である。例えば、ノード５０は無線装置でなく据置きコンピュータであったり、光リンクや従来の伝導ケーブルでネットワーク４４と通信する他のサーバ通信であってもよい。

この実施形態において、バックボーンネットワーク４６がインターネットプロトコル（ＩＰ）をサポートすると仮定する。動作の詳細について説明する以前に、まず、階層の異なる多様なレベルのプロトコルを介して行われ、これらの相互関係がＩＰの下で動作するパケットデータ通信中におけるデータパケットの処理について大まかに説明する。

ネットワーク通信の技術において、プロトコルは、国際標準化機構（ＩＳＯ）と国際電信電話諮問委員会（ＩＴＵ−Ｔ）が説明しているとおりの開放型システム間相互接続（ＯＳＩ）モデルに従って階層化される。この目的は、マルチベンダ設備相互使用可能性の促進である。即ち、各レベルのプロトコル階層には独自の仕様がある。そのため、特定の階層レベルの仕様が満たされる限り、このレベルにおける製品の開発が別レベルの他の製品と互換することが保証される。

図３は階層順序に並んだプロトコルのスタックを概略的に示しており、これは一般に「プロトコルスタック」と呼ばれ、この図では参照符号７２を付している。ＩＰプロトコルスタック７２は、ＯＳＩモデルと類似するが完全に同一ではないインターネット技術標準化タスクフォース（ＩＥＴＦ）モデルと一致した構造を有する。ＩＥＴＦモデルに従って、ＩＰプロトコルスタック７２は、層１〜５までの５つの層を有する。そのため、ノードから送信されたデータパケット、例えば図２に示すノード４８や５０は、プロトコルスタッック７２で処理しなければならない。プロトコル７２のスタックは、ソフトウェアまたはハードウェア、あるいはこれらの組み合わせの形式のノード内に構築される。同様に、同一のノードによって受信されたデータパケットは、同一のプロトコルスタック７２を介し、逆の順序で処理されなければならない。

一例を挙げて例証を行う。データパケットをノード、例えばノード４８（図２）から送信するように処理する場合、このデータパケットはまず、例えば層５のようなアプリケーション層内のプロトコルの１つに従って作成される。層５は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、サービスメール転送プロトコル（ＳＭＴＰ）、ファイル転送プロトコル（ＦＴＰ）、リアルタイム転送プロトコル（ＲＴＰ）、１方向移送／非同期層符号化上でのファイル送達（ＦＬＵＴＥ／ＡＬＣ）プロトコルを含む。さらに、データパケットはＶｏＩＰ（ヴォイスオーバ・インターネットプロトコル）セッションの積であると仮定する。そのため、層５内で、データパケットをＲＴＰに従ってフォーマットする必要がある。

例えば層５内のＲＴＰによって生じたデータパケットのような、時間に敏感なデータパケットは、リアルタイムで処理する必要がある。詳細には、通常、欠陥パケットは再送信されず、他の接近中のデータパケットの伝送を妨害することがないよう単純にドロップされる。そのため、ＲＴＰデータパケットは、通常、移送層である層４内のユーザデータパケットプロトコル（ＵＤＰ）を介して運ばれる。したがって、層５内のＲＴＰからのデータパケットは、層４内のＵＤＰに従って公式化される。

一方、データパケットが層５内の別のプロトコル、例えばＦＴＰから発生している場合には、通常、このデータパケットは層４内の移送制御プロトコル（ＴＣＰ）を介して送信される。ＴＣＰの下では、データパケットの正確な送達は最も重要である。そのため、全体のデータ伝送処理が遅速化する可能性があっても、欠陥パケットは常に再送信される。

この移送層である層４を通過したデータパケットには、セキュアポート番号や宛先ポート番号のような情報が追加される。

移送層である層４を通過するデータパケットは、次に、処理のためにネットワーク層である層３へ送信される。この特定の場合には、層４から生じたデータパケットに、データパケットのソースアドレスと宛先アドレスを追加した状態にし、さらに、ＩＰに従って再びフォーマットする必要がある。

その後、データパケットをフレーム化して、リンク層である層２内に適したプロトコルに適合させる。電気電子学会（Institute of Electrical and Electronics Engineers）（ＩＥＥＥ）発行の文書第ＩＥＥＥ８０２．３で説明されているように、例えば、イーサーネット（登録商標）を介してサーバノード４８をネットワークに接続した場合には、層２はイーサネット（登録商標）プロトコル形式となる。

図５中のプロトコルスタック７２の最下層は、物理層である層１であり、この層はデータパケットの送信を物理的に実現する。例えば、図２では、ノード４８とネットワーク４２の間の通信リンクが従来の有線リンクである場合に、物理層である層１は、両ノード４８上のハードウェア回路とネットワーク４２の物理インターフェース回路に関連する。ノード５０とＢＳ６６Ａの間の通信リンクがエアーインターフェースである場合には、図２の別の例のようになる。この場合は、物理層である層１は、エアースペースと、このエアースペースを介して信号のやり取りを行うＲＡＮ５２のハードウェア回路とに関連する。

次に再び図３を参照する。例証的なノード５０が受信したデータパケットの場合（図２）、データパケットは同じプロトコルスタック７２を介して処理されるが、しかしこの場合には、層１から層５の逆の順序で処理されなければならない。

次に、システム４０における例証的なブロードキャスト処理の動作について説明する。図２では、先述したように、ノード４８、即ちＢＳＤが、加入者にブロードキャストサービスを提供するサービスプロバイダによってネットワーク４２にインストールされる。この場合、ノード５０はこうした加入者の１人である。例えばこの場合、ノード５０は別のネットワークからネットワーク４４へのローミングであってよく、ネットワーク４２を動作しているサービスプロバイダより入手可能な夜７時のニュースのようなニュースクリップのアクセスをシークすることができる。

ネットワーク４４がブロードキャストサービスをサポートする場合には、ネットワーク４４には利用可能なサービスのブロードキャストチャネルが設けられていることが多い。利用可能なサービスの情報は、ダウンロード可能なファイル形式で編成できる。あるいは、この情報を、リアルタイム・ビューイング可能なデータの一定のストリームの形式で表すこともできる。

この例証的な実施形態では、無線通信における多様な標準を統一する目的で、サービスプロバイダ、ハードウェアおよびソフトウェアベンダ、ネットワークオペレータその他を含む無線業界の様々な実体の共同体であるオープン・モバイル・アライアンス（ＯＭＡ）が公表したブロードキャストサービス案内（ＳＧ）と類似した方法で、利用可能な複数のサービスをダウンロード可能なファイルとしてグループ化するものとする。ＳＧの詳細は、ＯＭＡより発行の文書ＯＭＡ−ＴＳ−ＢＣＡＳＴ−ＳｅｒｖｉｃｅＧｕｉｄｅ−Ｖ１．〜＠＃＄＠＠`で説明されている。

これまで、ノード５０のユーザは、ネットワーク４４内にある場合、利用可能なサービスについてＳＧを参照する必要があった。このために、ネットワーク４４からＳＧをダウンロードしなければならない。次に、ノード５０のユーザはシークしたサービスをＳＧから選択して、このサービスを装備しているチャネルがＳＧに提供された時にこれに同調する。

例えば音楽のダウンロードのようないくつかのサービスでは、ノード５０のユーザはシークしたファイルを最初にダウンロードし、後にこのファイルを楽しむことができる。ニュースブロードキャストセッションのような別のサービスでは、シークしたファイルのコンテンツがダウンロードされ、これとほぼ同時に表示される。これは即ち、シークしたサービスと、このサービスに関連したファイルのダウンロードとがリアルタイムに提示されるということである。こうしたアプローチにはいくつか欠点がある。これはとりわけ、ファイルコンテンツの連続提示が、コンテンツ自体のダウンロードの成功のみでなく、コンテンツファイルの処理に必要なファイル属性のダウンロードの成功にも依存することによる。こうした依存性によって遅延が生じるのは不可避であり、また多くの場合、コンテンツ提示に関連したユーザの経験に悪影響を及ぼす。これに加え、信頼性の高いデータパケットの受信度を高めるために、通常は冗長データが送信される。この結果、以降でさらに説明している利用可能な通信リソースの最も効率的な使用が得られなくなる可能性がある。

シークしたサービスのファイルのコンテンツが、ＦＬＵＴＥ／ＡＬＣプロトコルを介して移送されるとする。正確なデータ移送を確実に得るために、従来は、ＦＬＵＴＥ／ＡＬＣプロトコルと共にカルーセルファイル配信（ＣＦＤ）方法が使用された。図３ＡはＦＬＵＴＥ／ＡＬＣプロトコルのより詳細な概略図を示している。これについては以降でより詳細に説明する。図４は、ＦＬＵＴＥ／ＡＬＣプロトコルの下で動作するＣＦＤスキームの方法論を示している。

図４では、ファイルを参照符号７４で表している。１片のマルチメディアコンテンツ、この例では例えばニュースクリップが、複数のファイルを備えていてよい。ファイル７４内では、各ＡＬＣデータパケットがデータパケット＃１〜＃５の１つで表されている。確ファイル７４の送達には、ファイル送達テーブル（ＦＤＴ）７８を設け、やはりＡＬＣプロトコル形式で構成されたＡＬＣデータパケットが関連している。

ＦＤＴ７８には、データパケット＃１〜＃５の復号化に必要な多様なパラメータまたは属性が含まれている。こうしたパラメータは、ファイル名、ファイル識別（ＩＤ）、ファイルのソース場所（即ちＵＲＩ）、表示時間、ファイルサイズ、コンテンツタイプ、符号化スキーム、転送エラー修正（ＦＥＣ）タイプとＦＥＣ関連のパラメータ、さらに、適切であればセキュリティ関連のパラメータを備えていてよいが、しかしこれらのパラメータに限定されるものではない。

ＣＦＤ方法ではファイルは複数回伝送される。この例では、ファイル７４はコンテンツパケット＃１〜＃５と、これに関連するＦＤＴ７８とを含んでおり、第１パス７３において１回目、次に第２パス７５において２回目の伝送が実行される。第１パス７３では、ＦＤＴ７８がコンテンツパケット＃１〜＃５よりも先に伝送される。第２パス７５では、これと同一のＦＤＴ７８が、コンテンツパケット＃１〜＃５の最後に伝送される。

各ファイルを繰り返し伝送する１つの目的は、全ての受信者が確実に同じ時間にファイルを受信する必要を排除することである。即ち、ファイル受信のために受信者を同期する必要はない。

各ファイルを繰り返し伝送する別の目的は、ＦＥＣスキームがインストールされていない場合、あるいは、たとえインストールされていてもＦＥＣ機構の動作が失敗した場合に、データ移送中の正確性を確実にすることである。この目的は、ＣＦＤ方法を、図４に示すシナリオＡ、Ｂ、Ｃと識別される３つのシナリオを包括するように設計することで達成される。この３つのシナリオＡ、Ｂ、Ｃ以外にも、失敗したファイルのダウンロードの宣言を行える。

シナリオＡでは、ノード５０がファイル７４のダウンロードを試みると仮定する。第１パス７３の最中に、ノード５０はＦＤＴ７８の受信に成功する必要がある。第１パス７３におけるＦＤＴ７８のダウンロードがエラーなく成功する。次に、ノード５０が後続のデータパケット＃１〜＃５を受信する。第１パス７３において、データパケット＃１〜＃５全てのダウンロードも成功したと想定する。ファイル７４全体を組み立てるために、ノード５０は、第１パス７３からダウンロードしたＦＤＴ７８内の情報を使用して、全てのパケット＃１〜＃５内のデータを復号化することができる。

シナリオＢでは、第１パス７３でのファイル７４のダウンロードの最中に、ＦＤＴパケット７８の取り出しが成功したと仮定する。第１パス内での、＃３を除いた全てのコンテンツパケット＃１〜＃５の取り出しも成功したとする。実現されたＦＥＣ機構は機能しないと仮定する。この場合ノード５０は、第１パス７３において受信した関連する欠陥パケット＃３を補正するために、第２パス７５の最中に、第２パス７５が同一のデータパケット＃３を受信するまで待つ必要がある。その後、ノード５０は、ファイル７４を再構築するために、第１パスから入手したＦＤＴ７８からの情報を使用して、全てのデータパケットを復号化することができる。

シナリオＣでは、全てのデータパケット＃１〜＃５が第１パス７３内に正確にダウンロードされるが、ノードはＦＤＴ７８を第１パス７３内に正確に受信することができない。この場合には、ノード５０は、第１パス７３からの誤ったＦＤＴ７８を補正して、ファイル７４の全てのデータパケットを正確に復号できるよう、第２パス７５が関連のＦＤＴ７８を取り出すまで待たなくてはならない。

望ましくない信号受信条件の下では、上のシナリオＡ、Ｂ、Ｃの部分で説明したＦＥＣの一番最初に追加のステップを実行しても、エラーのあるデータを修正することはできない可能性がある。すなわち、先に述べたように、ファイル７４のダウンロードは失敗と宣言される可能性がある。シナリオＢでは、データパケット＃３が損失しても、表示中のファイル７４の品質にしか影響が及ばないことがある。しかし、シナリオＣでは、ＦＤＴ７８がなければファイル７４全体の処理ができないため、ＦＤＴ７８の取り出しの失敗によってファイル７４全体が損失しかねない。この場合には、ノード５０は、次のカルーセル周期まで待つ必要がある。この周期は、後にＦＤＴ７８取得の別の機会を得るだけのために、時間パス７３、７５で延長された期間のように非常に長くなる可能性がある。この場合には、さらなる時間の遅延と、通信チャネルの固定が不可避となる。この例のようにデバイス５０が移動体装置である場合は、時間遅延の増加はデバイス５０の電池の電力消費増加につながる。移動通信では、電池寿命の維持が非常に重要である。

本発明の例証的な実施形態によれば、ＦＤＴとコンテンツデータパケットは、従来実施されていたようにインバンド方式で受信されない。代わりに、ファイル属性とコンテンツデータがアウトオブバンド方式で受信される。これについては以降で説明する。

これ以降では、用語「インバンド方式」は、伝送チャネルを介し、さらに実質的に同一の伝送セッション内での情報の移送を意味するものとして解釈される。インバンド方式の情報移送の一例は、図４の伝送工程に図示し、説明しているとおりのものである。一方、用語「アウトバンド方式」は、図５に図示し、以降で説明する伝送工程によって例証されるように、こうした移送が同一の伝送チャネルを介して行われるか、あるいは別の伝送チャネルを介して行われるかに関係なく、多様な伝送セッションを介して、情報の移送を意味するものとして解釈される。

次に図５を参照する。この実施形態では、データパケット＃１〜＃５のようなペイロードデータと比較して、先に述べたＦＤＴ７８に含まれているファイル属性のようなファイル属性８２が別々に、即ち、インバンド方式ではなくアウトバンド方式で送信される。

ＦＡは、ネットワーク４４（図２）により、またブロードキャストチャネル内で伝送されることが好ましい。例えば、ＦＡは先に述べたＳＧの一部であってよい。ＳＧとさらにＦＡは、ブロードキャストサービスをシークするノード５０によって最初に取得される。即ち、ＦＡ８２は第１通信セッション８１中に取得される。ＦＡ８２を正確に取得した後、ノード５０は、ファイル８４のようなコンテンツファイルを取得するために、ＳＧ内に提供された情報に従ってチャネルに同調する。即ち、コンテンツファイルは第２通信セッション８６中に取得される。図５に示すように、コンテンツファイルパケット同士の間にはＦＤＴが割り込んでいない。むしろ、コンテンツファイル（例えばファイル８３、８４）は、連続的および非妨害的に伝送されるよう設計されている。表現を変えれば、通信セッション８１中の早い時期にノード５０がＦＡ８２を正確に取り出したと確認された後にのみ、コンテンツファイルが通信セッション８６中にダウンロードされる。これにより、ファイルとＦＤＴの両方がインバンド方式で、また上述したとおりに受信される場合に、ファイル処理の成功が関連するＦＤＴのダウンロードの成功によって決まってしまう状況を回避できる。

伝送工程中の第１パス８５において、図５の参照符号９０で示す欠陥のあるデータパケット、例えばデータパケット＃４がファイル８４内に見付かり、さらに、インストールされたＦＥＣ機構ファイルがこの欠陥パケット＃４を修正すると仮定した場合には、第２パス８７内の関連するデータパケット＃４を取り出して修復することができる。修復工程が失敗した場合には、表示中のファイル８４に特定の品質劣化が生じる可能性がある。しかし、図４に示し、上述したような失敗したシナリオＣでの状況が生じることは絶対にない。これの理由は、先述したように、先の通信セッション８１の最中にＦＡ８２の受信が成功しているためである。

上述した方法で動作する場合には、ＦＤＴの伝送用としてインバンドチャネルを固定する必要はない。そのため、コンテンツファイルの取り出しをより高い確実性にて行える。ファイル取得時間も実質的に短縮することができる。この結果、通信チャネル間のふくそうが容易化されるため、利用可能な通信リソースをより効率的に使用できるようになる。さらに、ノード５０（図２）が移動体装置である場合には、ファイル取得時間が短いことは、コンテンツファイルのダウンロード中に、ノード５０の電池の起動に要する時間が短くて済むことを意味する。したがって、電池電力を温存できる。

図５に示すＦＡ８２は、シークしたサービスセッションについて全てのファイルを適切に復号するために取得すべき多数のＦＡのうちの１つであり、ファイル８４はこうしたファイルのうちの１つであることに留意されたい。しかし、ＦＡ８２は、ファイル８４だけでなく、隣接するファイル８３のような他のファイルをも取り出すための共通の属性を多く有する。したがって、全てのＦＡを、１伝送セッション中の全てのファイルの取り出しに適した１つのマスターＦＡとして編成することができる。あるいはこれの代替として、マスターＦＡの代わりに、集合体としてのＦＡを２つの部分に分割することもできる。第１部分は、永続ファイルとして考慮されたファイルの属性を保持することができる。このような属性は、ファイル名、ファイルＩＤ，ファイルの場所、表示時間、配信時間ウィンドウを含んでいてよい。一方、比較的短命と考えられる属性はＦＡの第２部分に配置できる。短命の属性は、アプリケーションファイルのサイズ、伝送されたファイルのサイズ、コンテンツタイプ、符号化スキーム、ＦＥＣタイプおよびパラメータ、セキュリティ関連のパラメータを含んでいてよい。第１部分は、比較的不変のままＳＧ内に長期間滞留することができる。第２部分は、変化する状況を反映するために、ＳＧ内で定期的に更新することができる。

先述したように、最初にいくつかのファイルをダウンロードしておき、後でユーザが選択した時間に実行することが可能である。この例には、音楽ファイルやソフトウェア更新用ファイルがある。最初にダウンロードしておくことができるが、しかし、特定の時間に表示させることが好ましいファイルもある。これの一例には、以下で説明するニュースブロードキャストセッションがある。いずれの場合でも、本発明の別の態様に従って、コンテンツファイルの取得および表示は同時に実行される必要はない。代わりに、ファイル取得をファイル表示工程前に別個に実行することができる。

説明を簡単にするために、より具体的な例を例証する。次に再び図２を参照する。この例では、ノード５０のユーザが、通常午後７時に、標準テレビブロードキャストを介して利用できるニュースブロードキャストを視聴したいと仮定する。ネットワーク４４によってブロードキャストされたＳＧ内では、これに関連した、午後７時のニュースクリップに関する情報が通常利用可能である。ネットワーク４４は、ネットワーク４２をバックボーンネットワーク４６を介して提供しているサービスから取得した情報を有する。ＳＧ内では、２つの時間ウィンドウ、即ち「配信ウィンドウ（ＤＷ）」と「表示ウィンドウ（ＰＷ）」が指定される。図６はこうした配列を示す。

ＤＷ内では時間ウィンドウが指定される。この時間ウィンドウ内では、午後７時のニュースセッションのファイルを受信するために、ノード５０が起動される必要がある。時間ウィンドウは、この例においては例えば午後５時〜午後６時半であり、これは、ニュースファイルを受信するためにノード５０の電源がオンにされる時間間隔である。一方、ＰＷは、例えば午後７時〜午後７時半の間にダウンロードしたニュースセッションの表示時間を識別した。これは即ち、この時間スパン中に、ダウンロードしたファイルが午後７時のニュースとして表示されるということである。ＤＷをＰＷから分離することの追加的利点に、加入者が、表示時間以前にファイルをダウンロードできるため、通常、ピーク時間帯にぶつかってしまう表示時間中におけるトラヒックチャネルの過負荷を回避できるということがある。ＤＷ中にネットワーク４４内のトラヒック負荷が混雑している場合でも、それぞれのファイルダウンロードを受信側の受信機内へ少量ずつ行い、ＰＷが開始する前に都合よく完了することができる。

ノード５０は、ＳＧが提供した情報に基づいて、ニュースクリップを受信するために、午後５時２５分〜午後５時３７分の期間中に電源オンにされ、起動されると仮定する。適切なファイル圧縮技術を実現した場合、ダウンロードに要する時間はこの例では１２分間であり、表示時間（この場合は３０分間）よりも短い。

前述のノード５０のための方法を図７のフローチャートに示す。図８は、ネットワーク４４によって実行されるこれと関連した方法である。

本発明のさらに別の態様では、ペイロードデータの移送をさらにストリームライン化することができる。

ファイルコンテンツをダウンロードするために、ＦＬＵＴＥ／ＡＬＣプロトコルを採用できる。先述したように、データパケットがＴＣＰ移送層（図３）を介して移送されるＦＴＰとは異なり、ＦＬＵＴＥ／ＡＬＣ内のデータパケットがＵＤＰ移送層へ運ばれる。伝送工程全体は遅速化するが、ＦＴＰはより１対１のアプリケーションへと調整され、エラーが生じたパケットも正常に再伝送される。ＵＤＰを介して運ばれるＦＬＵＴＥ／ＡＬＣプロトコルは、マルチキャストまたはブロードキャストアプリケーションに適するように設計される。エラーの生じたデータは正常に伝送されない。その代わりに、適切な転送エラー修正（ＦＥＣ）スキームを採用することにより、データ伝送におけるエラーが縮小される。

次に、参照符号９６で全体的に表されるＦＬＵＴＥ／ＡＬＣプロトコルを示した図３Ａを参照する。ＦＬＵＴＥプロトコルのパケットはＡＬＣプロトコルによって運ばれることで移送される。ＡＬＣプロトコルについては、２００２年１２月にＩＥＴＦより発行された刊行物ＲＦＣ３４５０「非同期層符号化（ＡＣＬ）プロトコルの例示（Asynchronous Layered Coding (ALC) Protocol Instantiation））」」」」）で説明されている。ＡＬＣプロトコルは、マルチキャスト移送に提案された基本プロトコルの１つである。ＡＬＣが関与するデータ移送ではアップリングシグナリング、即ち受信機から送信機へのシグナリングが不要であり、信頼性の高いデータ取り出しを行うためにＦＥＣの使用が採用されている。ＡＬＣはまた、マルチレートふくそう制御（ＣＣ）９７に階層型符号移送（Layered Coding Transport）（ＬＣＴ）ビルディングブロック９８を利用し、さらに、信頼性の高いコンテンツ送達のためにＦＥＣビルディングブロック９９を利用する。ＬＣＴについては、２００２年１２月にＩＥＴＦより発行された刊行物、ＲＦＣ３４５１「階層型符号化移送（ＬＣＴ）ビルディングブロック（Layered Coding Transport (LCT) Building Block）」にて説明されている。ＦＥＣは、やはりＩＥＴＦから発行されたＲＦＣ３４５３で説明されている。

ＦＬＵＴＥプロトコルは、マルチキャストファイル送達へのＡＬＣの適用を表す。しかし、従来のＦＬＵＴＥ／ＡＬＣプロトコルは主に非移動環境用として設計されている。電池電力を温存する必要があり、エアーリンク帯域幅が貴重である無線環境では、ファイルダウンロード工程をさらにストリームライン化することが可能である。この目的を達成するために、ペイロード内の各データパケットをよりコンパクトに設計することができる。

図９は、参照符号９４で表されたコンパクトなＡＬＣデータパケットの一例を示しており、このＡＬＣデータパケットは、ＲＦＣ３４５０に明記されているとおりの従来のＡＬＣパケットにより従うようにフォーマットされている。ＡＬＣパケットフォーマット９４は、３ＧＰＰ２が刊行文書３ＧＰＰ ＴＳ ２３．３４６で公表したブロードキャスト／マルチキャストサービス（ＭＢＭＳ）と同一になるように設計されている。データパケット８４内に示されているフォーマットと文書３ＧＰＰ ＴＳ ２３．３４６に明記されたフォーマットとの主な違いは、ファイル記述情報のインバンド伝送が全くない、即ち、データパケット９４のペイロードを処理するために必要なファイル属性が全くないことである。

図１０は、別の例証的なコンパクトなパケットフォーマットを参照符号９６で示している。データパケット９６は実質的にストリームライン化され、無線通信環境での使用に好適となる。とりわけ、ふくそう制御情報を設けずに済むようになる。無線環境と同様に、無線媒体は唯一のアクセス手段であり、異なるデータ速度での複数のアクセス手段を規制するふくそう制御が不要となる。図９に示すデータパケット９４では、過負荷は１６バイトである。図１０に示すデータパケット９６の場合には、過負荷はたった８バイトである。

図１１は、本発明の例証的な実施形態による、例えば図２のノード５０のような装置のハードウェア実現の部分を概略的に示している。このハードウェア実現部分には参照符号１００を付している。装置１００は、例えば数例としてラップトップコンピュータ、ＰＤＡ、携帯電話のような多様な形式で構築および組込むことができる。

装置１００は、数個の回路を繋ぐ中央データバス１０２を備えている。これらの回路はＣＰＵ（中央処理装置）または制御装置１０４、受信回路１０６、送信回路１０８、メモリユニット１１０を含んでいる。

装置１００が無線装置の一部である場合には、受信回路１０６と送信回路１０８を無線周波数（ＲＦ）回路に接続することができるが、これは図示していない。受信回路１０６は、受信した信号を、データバス１０２へ送信する前に処理およびバッファリングする。一方、送信回路１０８は、データバス１０２からのデータを、装置１００へ送信する前に処理およびバッファリングする。ＣＰＵ／制御装置１０４は、データバス１０２のデータ管理機能と、さらに、メモリユニット１１０の命令コンテンツの実行を含む汎用データ処理機能とを実施する。

送信回路１０８と受信回路１０６を、図１１に示すように別個に配置するのではなく、代替形としてＣＰＵ／制御装置１０４の一部とすることができる。

メモリユニット１１０は、全体を参照符号１０１で示した１組の命令を含んでいる。この実施形態において、これらの命令は、とりわけ上述のＦＵＬＴＥ／ＡＬＣプロトコルを処理することができるプロトコルスタック機能１１２のような部分を含んでいる。この１組の命令はまた、図７に図示し説明したような方法の実行が可能なブロードキャストクライアント機能１１４を含んでいる。

この実施形態では、メモリユニット１１０はＲＡＭ（ランダムアクセスメモリ）回路である。例証的な命令部分１１２、１１４は、ソフトウェアルーチンまたはモジュールである。メモリユニット１１０は、揮発性または非揮発性タイプのいずれかであってよい別のメモリ回路（図示せず）に連結することができる。これの代替形として、メモリユニット１１０を他の回路タイプ、ＥＥＰＲＯＭ（登録商標）（電気的に消去できるプログラム可能な読み出し専用メモリ）、ＥＰＲＯＭ（電気的にプログラム可能な読み出し専用メモリ）、ＲＯＭ（読み出し専用メモリ）、ＡＳＩＣ（特定用途向け集積回路）、磁気ディスク、光学ディスク、また技術上よく知られているこれ以外のものによって作成することが可能である。

図１２は、図２に示したＢＳＮ装置７０のようなブロードキャストサーバのハードウェア実現の部分を、参照符号１２０を付して概略的に示す。この装置１２０は、数個の回路を繋ぐ中央データバス１２２を備えている。これらの回路はＣＰＵ（中央処理装置）または制御装置１２４、受信回路１２６、送信回路１２８、データベース格納ユニット１２９、メモリユニット１３１を含んでいる。

受信回路１２６、送信回路１２８は、装置１２０が繋がれたネットワークデータバス（図示せず）に接続できる。受信回路１２６は、ネットワークデータバス（図示せず）から受信した信号を、内部データバス１２２へルーティング前に、処理およびバッファリングする。送信回路１２８は、データバス１２２からのデータを、装置１２０へ送出する前に、処理およびバッファリングする。あるいは、送信回路１２８と受信回路１２６を総体的にインターフェース回路と呼ぶこともできる。ＣＰＵ／制御装置１２４は、データバス１２２のデータ管理の任務と、メモリユニット１３１の命令コンテンツの実行を含む汎用データ処理機能委の任務を実施する。データベース格納ユニット１２９は、様々なパラメータとコンテンツファイルを含んだＳＧのようなデータを格納する。

メモリユニット１３１は、参照符号１２１で全体的に示す１組の命令を含んでいる。この実施形態では、命令は、とりわけプロトコルスタック１３２およびブロードキャストホスト１３４の部分を含む。メモリユニット１３１は、上述したメモリ回路タイプで作成されているため、これ以上の説明の繰り返しは省略する。プロトコルスタック１２１およびブロードキャストホスト１３４のための機能は、図３、図８に示し、先述したような本発明による命令の組を含んでいる。

さらに、図７、図８に示し、上述した工程を、技術上周知のあらゆるコンピュータ読み出し媒体上に収容されるコンピュータ読み出し可能な命令として符号化することも可能である点に留意されたい。本明細書および添付の請求項において、用語「コンピュータ読み出し可能な媒体」とは、それぞれ図１１、図１２に図示し説明したＣＰＵ／制御装置１０４、１２４のような任意のプロセッサに命令を提供し、実行する際に関与するあらゆる媒体を意味する。こうした媒体は、格納タイプのものであってよく、また、例えばそれぞれ図１１、図１２のメモリユニット１１０、１３１の記述において先述したような揮発性あるいは非揮発性の格納媒体の形態であってよい。このような媒体は伝送タイプであってもよく、また、同軸ケーブル、銅線、光ケーブルや、さらに、マシンまたはコンピュータによって読み出し可能な信号を運べる音響波あるいは電磁波を伝達するエアーインターフェースを含んでいてよい。

最後に、この実施形態で説明したように、ノード、即ちＢＳＤ４８は、サービスプロバイダのネットワーク４２にインストールされたものとして記述されている。しかし、常にこの限りでなくてもよい。ＢＳＤ４８を、サービスプロバイダが所有しているものではない別のネットワークにインストールすることも可能である。さらに、例証的な実施形態で説明したアウトオブバンド伝送チャネルを、拡散スペクトル通信の技術において一般的に実施されるように論理的または物理的に区別することができる。これに加え、多種のアウトオブバンドセッションを、前述した時間分離ではなく異なるポート番号によって識別することもできる。そのため、例えば図５では、ＦＤＴを、第１送信セッションに関連した１つの宛先ポートを介して、層４のＵＤＰ（図３）上で伝送できる。また、第２伝送セッション中に、コンテンツファイルを、別の宛先ポート番号を介し、層４のＵＤＰ上で伝送することが可能である。これに加え、図７、図８のフローチャートが、音楽ファイルのようなファイルをユーザの選択でダウンロードおよび実行するためにも適用できる点を明白にしておくべきである。例えば、ユーザはＳＧからファイルを拾い集め、自分のファイル配信ウィンドウおよびファイル表示ウィンドウ上で決定を行うことができる。さらに、例証的な実施形態では、バックボーンネットワークはＩＰの下で動作されると説明している。ＩＰ以外のプロトコルの使用も可能である。例えば、ＦＬＯネットワークでは、ＦＬＯフォーラム（ＦＬＯ Ｆｏｒｕｍ）が発行したｆｌｏｆｏｒｕｍ２００５．００１の文書「ＦＬＯエアーインターフェース仕様書（FLO Air Interface Specification）」によるプロトコルの適用が可能である。ＦＬＯネットワークでは、ＳＧではなく、関連する属性をシステム情報（ＳＩ）に入れることができる。これについての詳細は、ＦＬＯ Ｆｏｒｕｍが発行した文書ｆｌｏｆｏｒｕｍ２００６．００５を参照できる。これに加え、本発明に関連して説明した論理ブロック、回路、アルゴリズムステップを、ハードウェア、ソフトウェア、ファームウェア内、あるいはこれらの組み合わせにおいて実現することができる。当業者は、本発明の範囲と精神から逸脱しない限り、形態および詳細に、ここで説明した変更やその他の変更を加えられることを理解するだろう。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
通信システム内でブロードキャストのファイルをダウンロードする方法であって、
第１通信セッションにおいて、前記ブロードキャストの少なくとも１つのファイルを処理するためにファイル属性を受信することと、
第２通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも１つのファイルを受信することと、
を備える方法。
［Ｃ２］
第１通信チャネルを介して前記ファイル属性を受信することと、
前記少なくとも１つのファイルを第２通信チャネルを介して受信することと、
を備える、Ｃ１に記載の方法。
［Ｃ３］
前記通信システムはインターネットプロトコル（ＩＰ）をサポートし、前記方法はさらに、
前記ファイル属性を、第１ポート番号によって前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと、
前記少なくとも１つのファイルを、第２ポート番号によって前記ＩＰの前記ＵＤＰを通して受信することと、
を備える、Ｃ１に記載の方法。
［Ｃ４］
前記第２通信セッション内で、前記ブロードキャストのために複数のファイルを連続的に受信することと、前記第２通信セッションよりも前の前記第１通信セッション内で前記複数のファイルを処理するために、前記ファイル属性を受信することとをさらに備える、Ｃ１に記載の方法。
［Ｃ５］
前記少なくとも１つのファイルは複数のデータパケットを含んでおり、前記方法はさらに、前記少なくとも１つのファイルを処理するための、前記各データパケット内にファイル属性を受信しないことを備える、Ｃ１に記載の方法。
［Ｃ６］
前記第２通信セッションにおいて前記ブロードキャストの複数のファイルを受信することを備え、前記複数のファイルを処理するために前記複数のファイル間で共用される前記ファイル属性のいくつかを使用して、前記複数のファイルを処理することをさらに備える、Ｃ１に記載の方法。
［Ｃ７］
前記少なくとも１つのファイルを所定の時間に表示できるようにするために、前記ブロードキャストの前記少なくとも１つのファイルを表示するための前記ファイル属性時間情報を提供することをさらに備える、Ｃ１に記載の方法。
［Ｃ８］
通信システムにおけるブロードキャストのファイル送達方法であって、前記方法は、
第１通信セッションにおいて、前記ブロードキャストの少なくとも１つのファイルを表示するためのファイル属性を送信することと、
第２通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも１つのファイルを送信することと、
を備える方法。
［Ｃ９］
前記ファイル属性を第１通信チャネルを介して送信することと、
前記少なくとも１つのファイルを第２通信チャネルを介して送信することと、
をさらに備える、Ｃ８に記載の方法。
［Ｃ１０］
前記通信システムはインターネットプロトコル（ＩＰ）をサポートし、前記方法はさらに、
前記ファイル属性を、第１ポート番号を介し、前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して送信することと、
前記少なくとも１つのファイルを、第２ポート番号を介し、前記ＩＰの前記ＵＤＰを通して送信することと、
を備える、Ｃ８に記載の方法。
［Ｃ１１］
前記第２通信セッションにおいて、前記ブロードキャスト用に複数のファイルを連続して送信することと、前記第２通信セッションよりも前の前記第１通信セッションにおいて、前記複数のファイルを処理するために、前記ファイル属性を送信することとをさらに備える、Ｃ８に記載の方法。
［Ｃ１２］
前記少なくとも１つのファイルは複数のデータパケットを含んでおり、前記方法は、前記少なくとも１つのファイルを処理するために、前記各データパケット内にファイル属性を提供しないことをさらに備える、Ｃ８に記載の方法。
［Ｃ１３］
さらに、前記第２通信セッションにおいて前記ブロードキャストの複数のファイルを送信することと、またさらに、前記第１通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供することとを備える、Ｃ８に記載の方法。
［Ｃ１４］
前記ブロードキャストの前記少なくとも１つのファイルを表示するための、前記ファイル属性時間情報をさらに備える、Ｃ８に記載の方法。
［Ｃ１５］
通信システム内でブロードキャストを受信するように構成された装置であって、前記装置は、
第１通信セッションにおいて、前記ブロードキャストの少なくとも１つのファイルを処理するためにファイル属性を受信する手段と、
第２通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも１つのファイルを受信する手段と、
を備える装置。
［Ｃ１６］
第１通信チャネルを介して前記ファイル属性を受信する手段と、
第２通信チャネルを介して前記少なくとも１つのファイルを受信する手段と、
をさらに備える、Ｃ１５に記載の装置。
［Ｃ１７］
前記通信システムはインターネットプロトコル（ＩＰ）をサポートし、前記装置はさらに、
第１ポート番号を介し、前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して前記ファイル属性を受信する手段と、
第２ポート番号を介し、前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを受信する手段と、
を備える、Ｃ１５に記載の装置。
［Ｃ１８］
前記第２通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に受信する手段と、前記第２通信セッションよりも前の前記第１通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信する手段とをさらに備える、Ｃ１５に記載の装置。
［Ｃ１９］
前記少なくとも１つのファイルは複数のデータパケットを含んでおり、前記各データパケットは、前記少なくとも１つのファイルを処理するためのファイル属性を含んでいない、Ｃ１５に記載の装置。
［Ｃ２０］
前記第２通信セッションにおいて前記ブロードキャストの複数のファイルを受信する手段をさらに備え、前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して、前記複数のファイルを処理するための手段をさらに備える、Ｃ１５に記載の装置。
［Ｃ２１］
前記ファイル属性は、所定の時間に前記少なくとも１つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも１つのファイルを表示するための時間情報を備えている、Ｃ１５に記載の装置。
［Ｃ２２］
通信システムにおいてブロードキャストのファイルを送達する装置であって、
第１通信セッションにおいて、前記ブロードキャストの少なくとも１つのファイルを処理するためにファイル属性を送信する手段と、
第２通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも１つのファイルを送信する手段と、
を備える装置。
［Ｃ２３］
第１通信チャネルを介して前記ファイル属性を送信する手段と、
第２通信チャネルを介して前記少なくとも１つのファイルを送信する手段と、
をさらに備える、Ｃ２２に記載の装置。
［Ｃ２４］
前記通信システムはインターネットプロトコル（ＩＰ）をサポートし、前記装置はさらに、
第１ポート番号を介し、前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して前記ファイル属性を送信する手段と、
第２ポート番号を介し、前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを送信する手段と、
を備える、Ｃ２２に記載の装置。
［Ｃ２５］
前記第２通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信する手段と、前記第２通信セッションよりも前の前記第１通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を送信する手段とをさらに備える、Ｃ２２に記載の装置。
［Ｃ２６］
前記少なくとも１つのファイルは複数のデータパケットを含んでおり、前記装置は、前記少なくとも１つのファイルを処理するための、前記各データパケット内にファイル属性を提供しない手段をさらに備えている、Ｃ２２に記載の装置。
［Ｃ２７］
前記第２通信セッションにおいて前記ブロードキャストの複数のファイルを送信する手段をさらに備え、前記第１通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供する手段をさらに備える、Ｃ２２に記載の装置。
［Ｃ２８］
前記ファイル属性は、前記ブロードキャストの前記少なくとも１つのファイルを表示するための時間情報を備えている、Ｃ２２に記載の装置。
［Ｃ２９］
通信システム内のブロードキャストにおいて使用される装置であって、前記装置は、 プロセッサと、
前記プロセッサに結合したメモリユニットとを備え、前記メモリユニットは、第１通信セッションにおいて前記ブロードキャストの少なくとも１つのファイルを処理するためのファイル属性を受信するための、及び第２通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも１つのファイルを受信するための、コンピュータ読み出し可能な命令とを含む装置。
［Ｃ３０］
前記メモリユニットは、前記第１通信チャネルを介して前記ファイル属性を受信するための、及び前記少なくとも１つのファイルを第２通信チャネルを介して受信するための、コンピュータ読み出し可能な命令とをさらに備える、Ｃ２９に記載の装置。
［Ｃ３１］
前記通信システムは、インターネットプロトコル（ＩＰ）をサポートし、前記メモリユニットはさらに、第１ポート番号を介し、前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して前記ファイル属性を受信するための、及び第２ポート番号を介して、前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを受信するための、コンピュータ読み出し可能な命令とを備える、Ｃ２９に記載の装置。
［Ｃ３２］
前記メモリユニットはさらに、前記第２通信セッションにおいて前記ブロードキャスト
用に複数のファイルを連続的に受信するための、及び前記第２通信セッションよりも前の前記第１通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信するためのコンピュータ読み出し可能な命令とを備える、Ｃ２９に記載の装置。
［Ｃ３３］
前記少なくとも１つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも１つのファイルを処理するためのファイル属性を含んでいない、Ｃ２９に記載の装置。
［Ｃ３４］
前記メモリユニットはさらに、前記第２通信セッションにおいて前記ブロードキャストの複数のファイルを受信するための、及び前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して前記複数のファイルを処理するための、コンピュータ読み出し可能な命令とを備える、Ｃ２９に記載の装置。
［Ｃ３５］
前記ファイル属性は、所定の時間に前記少なくとも１つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも１つのファイルを表示するための時間情報を備える、Ｃ２９に記載の装置。
［Ｃ３６］
通信システムにおいてブロードキャストのファイルを送達する装置であって、前記装置は、
プロセッサと、
前記プロセッサに結合されたメモリユニットとを備え、前記メモリユニットは、第１通信セッションにおいて前記ブロードキャストの少なくとも１つのファイルを処理するためのファイル属性を送信するための、及び第２通信セッションにおいて前記ブロードキャストの前記少なくとも１つのファイルを前記ファイル属性とは別に送信するための、コンピュータ読み出し可能な命令と、
を備える装置。
［Ｃ３７］
前記メモリユニットはさらに、前記ファイル属性を第１通信チャネルを介して送信するための、及び前記少なくとも１つのファイルを第２通信チャネルを介して送信するための、コンピュータ読み出し可能な命令とを備える、Ｃ３６に記載の装置。
［Ｃ３８］
前記通信システムはインターネットプロトコル（ＩＰ）をサポートし、前記メモリユニットはさらに、第１ポート番号を介し、前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して前記ファイル属性を、送信するための、及び第２ポート番号を介して、前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを送信するための、コンピュータ読み出し可能な命令とを備える、Ｃ３６に記載の装置。
［Ｃ３９］
前記メモリユニットは、前記ＩＰの前記ＵＤＰと結合した前記ＩＰの１方向移送上でのファイル送達（ＦＬＵＴＥ）とを通して少なくとも１つのファイルを送信するためのコンピュータ読み出し可能な命令をさらに備える、Ｃ３６に記載の装置。
［Ｃ４０］
前記メモリユニットは、前記第２通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信するための、前記第２通信セッションよりも前の前記第１通信セッションにおいて前記複数のファイルを処理するための前記ファイル属性を送信するための、コンピュータ読み出し可能な命令とをさらに備える、Ｃ３６に記載の装置。
［Ｃ４１］
前記少なくとも１つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも１つのファイルを処理するためのファイル属性を含まない、Ｃ３６に記載の装置。
［Ｃ４２］
前記メモリユニットは、前記第２通信セッションにおいて前記ブロードキャストの複数のファイルを送信するための、前記第１通信セッションにおいて前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供するための、コンピュータ読み出し可能な命令とをさらに備える、Ｃ３６に記載の装置。
［Ｃ４３］
前記ファイル属性は、前記ブロードキャストの前記少なくとも１つのファイルを表示するための時間情報を備える、Ｃ３６に記載の装置。
［Ｃ４４］
コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体であって、前記命令は、
第１通信セッションにおいてブロードキャストの少なくとも１つのファイルを処理するためのファイル属性を受信する命令と、
第２通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも１つのファイルを受信する命令と、
であるコンピュータ読み出し可能な媒体。
［Ｃ４５］
第１通信チャネルを介して前記ファイル属性を受信するための、及び第２通信チャネルを介して前記少なくとも１つのファイルを受信するための、コンピュータ読み出し可能な命令をさらに備える、Ｃ４４に記載のコンピュータ読み出し可能な媒体。
［Ｃ４６］
前記通信システムはインターネットプロトコル（ＩＰ）をサポートし、前記コンピュータ読み出し可能な媒体は、
第１ポート番号を介して、前記ＩＰのユーザデータグラムプログラム（ＵＤＰ）を通して前記ファイル属性を受信するための、及び第２ポート番号を介して、前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを受信するための、コンピュータ読み出し可能な命令
をさらに備える、Ｃ４４に記載のコンピュータ読み出し媒体。
［Ｃ４７］
第１通信セッションにおいて、ブロードキャストの少なくとも１つのファイルを処理するためのファイル属性を送信するための、及び第２通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも１つのファイルを送信するための、コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体。
［Ｃ４８］
第１通信チャネルを介して前記ファイル属性を送信するための、及び第２通信チャネルを介して前記少なくとも１つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、Ｃ４７に記載のコンピュータ読み出し可能な媒体。
［Ｃ４９］
第１ポート番号を介して、前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して前記ファイル属性を送信するための、及び第２ポート番号を介して、前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、Ｃ４７に記載のコンピュータ読み出し可能な媒体。

Claims (29)

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. 前記少なくとも１つのファイルは複数のデータパケットを含んでおり、前記装置は、前記少なくとも１つのファイルを処理するための、前記各データパケットにおいてファイル属性を提供しない手段をさらに備えている、請求項２２に記載の装置。
27. 前記第２通信セッションにおいて前記ブロードキャストの複数のファイルを送信する手段をさらに備え、前記第１通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用される前記ファイル属性のいくつかを提供する手段をさらに備える、請求項２２に記載の装置。
28. 前記ファイル属性は、前記ブロードキャストの前記少なくとも１つのファイルを表示するための時間情報を備える、請求項２２に記載の装置。
29. コンピュータ上で起動されるとき、請求項１−１４のいずれか一項にしたがった方法を実行するための命令を備える、コンピュータプログラム。

Images