(57)【要約】データストリームを配信する配信システムは、１つの中央配信装置から少なくとも１つの中間配信装置レイヤを介し複数の配信受信機までのデータ配信装置の階層的ネットワークを有する。データストリームは、ネットワークのダウンストリームチャネルを介し複数の配信受信機に配信される。中央配信装置の階層的に下位にある少なくとも１つの配信装置は、中央配信装置へのネットワークの少なくとも１つのアップストリームチャネルに配信データを挿入するよう動作する。中央配信装置は、少なくとも１つのアップストリームチャネルを介し受信した配信データをネットワークの少なくとも１つのダウンストリームチャネルを介し再配信するよう構成される。
2006509456.tif 000002
【特許請求の範囲】
【請求項１】
１つの中央配信装置から少なくとも１つの中間配信装置レイヤを介し複数の配信受信機までのデータ配信装置の階層的ネットワークを有し、前記ネットワークのダウンストリームチャネルを介し前記複数の配信受信機にデータを配信するための配信システムであって、
前記中央配信装置の階層的に下位にある少なくとも１つの配信装置は、前記中央配信装置への前記ネットワークの少なくとも１つのアップストリームチャネルに配信データを挿入するよう動作し、前記中央配信装置は、少なくとも１つのアップストリームチャネルを介し受信した配信データを前記ネットワークの少なくとも１つのダウンストリームチャネルに再配信するよう構成されることを特徴とするシステム。
【請求項２】
請求項１記載の配信システムであって、
少なくとも１つのアップストリームチャネルへの配信データの以降の挿入のため、タイトルのデータブロックが複数の配信装置のストレージ上でストライプ処理されることを特徴とするシステム。
【請求項３】
請求項２記載の配信システムであって、
前記タイトルがストライプ処理されるストレージを有する複数の配信装置は、配信受信機による前記複数の配信装置からのブロックストリームの実質的に中断のない受信を可能にする共通な１つの配信プロトコルの制御の下、格納されているブロックを前記ネットワークの少なくとも１つのデータチャネルに挿入するよう動作することを特徴とするシステム。
【請求項４】
請求項３記載の配信システムであって、
前記複数の配信装置の少なくとも２つは、格納されているブロックを１つのデータチャネルの各自のサブチャネルに挿入するよう動作することを特徴とするシステム。
【請求項５】
請求項３記載の配信システムであって、
前記複数の配信装置の少なくとも２つは、格納されているブロックを前記ネットワークの異なるデータチャネルに挿入するよう動作することを特徴とするシステム。
【請求項６】
請求項３記載の配信システムであって、
前記共通の配信プロトコルは、前記チャネルに割当てられたブロックの異なる繰り返しレートの少なくとも２つのネットワークチャネルを介したタイトルの配信のため、ニアビデオオンデマンドプロトコルであることを特徴とするシステム。
【請求項７】
請求項１記載の配信システムであって、
該配信システムは、前記ネットワークのアップストリームチャネル及び/またはサブチャネルへの配信データの挿入を制御する配信コントローラを有することを特徴とするシステム。
【請求項８】
請求項７記載の配信システムであって、
前記配信コントローラは、少なくとも１つのアップストリームチャネル及び/またはサブチャネルへの以降の挿入のため、複数の配信装置にデータブロックを提供するよう動作することを特徴とするシステム。
【請求項９】
請求項１記載の配信システムであって、
少なくとも１つの配信受信機は、前記ネットワークの少なくとも１つのアップストリームデータチャネル及び/またはサブチャネルに配信データを挿入するよう動作することを特徴とするシステム。
【請求項１０】
請求項２または９記載の配信システムであって、
複数の配信受信機が、前記ネットワークの少なくとも１つのアップストリームデータチャネル及び/またはサブチャネルに配信データを挿入するよう動作し、前記複数の配信受信機の各々は各自のストレージを有し、タイトルは前記複数の配信受信機のストレージ上でストライプ処理されることを特徴とするシステム。
【請求項１１】
請求項１０記載の配信システムであって、
前記ストレージは、ソリッドステートメモリを有することを特徴とするシステム。
【請求項１２】
請求項１記載の配信システムであって、
前記中間配信装置は、前記複数の配信受信機に対する前記配信データのスピリット処理及び/またはフィルタリングを実行するよう動作することを特徴とするシステム。
【請求項１３】
１つの中央配信装置から少なくとも１つの中間配信装置レイヤを介し複数の配信受信機までのデータ配信装置の階層的ネットワークを介しデータストリームを配信する方法であって、前記ネットワークのダウンストリームチャネルを介し前記複数の配信受信機にデータストリームを配信するため、該方法は、
前記中央配信装置の階層的に下位にある少なくとも１つの配信装置における配信データを前記中央配信装置への前記ネットワークの少なくとも１つのアップストリームチャネルに配信データを挿入するステップと、
前記ネットワークのアップストリームチャネルを介し配信データを受信するステップと、
前記ネットワークの少なくとも１つのダウンストリームチャネルを介し前記受信した配信データを再配信するステップと、
を有することを特徴とする方法。
【請求項１４】
請求項１記載の配信システムにおいて利用される配信受信機であって、
該配信受信機は、以降における再生のため、前記ネットワークの少なくとも１つのダウンストリームチャネルを介し配信されるデータブロックを受信し、前記中央配信装置による前記ネットワークの少なくとも１つのダウンストリームチャネルを介した再配信のため、前記中央配信装置への前記ネットワークの少なくとも１つのアップストリームチャネルに配信データを挿入するよう動作することを特徴とする配信受信機。
【請求項１５】
請求項１記載の配信システムにおいて利用される配信コントローラであって、
該配信コントローラは、前記配信ネットワークの少なくとも１つのアップストリームチャネル及び/またはサブチャネルへの配信データの同期された挿入を制御するよう動作することを特徴とする配信コントローラ。
【請求項１６】
請求項１記載の配信システムにおいて利用される中央配信装置であって、
該中央配信装置は、少なくとも１つのアップストリームチャネルを介し受信した配信データを複数の配信受信機への前記ネットワークの少なくとも１つのアップストリームチャネルを介し再配信するよう動作することを特徴とする中央配信装置。
【請求項１７】
１つの中央配信装置から少なくとも１つの中間配信装置レイヤを介し複数の配信受信機までのデータ配信装置の階層的ネットワークを有し、前記ネットワークのダウンストリームチャネルを介し前記複数の配信受信機にデータを配信するための請求項１記載の配信システムにおいて利用される中間配信コントローラであって、
前記中間配信装置は、前記中央配信装置による前記ネットワークの少なくとも１つのダウンストリームチャネルを介した配信データの再配信のため、前記中央配信装置への前記ネットワークの少なくとも１つのアップストリームチャネルに前記配信データを挿入するよう動作することを特徴とする中間配信コントローラ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１つの中央配信装置から少なくとも１つの中間配信装置レイヤを介し複数の配信受信機までのデータ配信装置の階層的ネットワークのダウンストリームチャネルを介し複数の配信受信機にデータを配信する配信システムに関する。本発明はまた、データストリームを配信する方法に関する。本発明はさらに、当該システムにおいて使用される配信受信機、配信装置及びコントローラに関する。
【背景技術】
【０００２】
ケーブルネットワークなどの複数の配信受信機にデータストリームを配信する従来の配信システムは、データ配信装置の階層的ネットワークを利用する。ネットワークのトップは、１つの中央ヘッドエンドにより構成され、最下位の装置レイヤは、宅内の配信受信機により構成される。図１は、７つの装置レイヤの階層を利用して音声/映像を合計２００，０００世帯に配信するためのシステムの一例を示す。最上位では、マスタヘッドエンドにより各々が離散的な都市域をカバーする５つのメトロポリタンヘッドエンドにデータが供給される。各地域は、メトロポリタンヘッドエンドとハブとの間の直接的なリンクにより、さらに５つ以上のハブに分割される。各ハブは、各々が４つの同軸ヘッドエンドに接続される２０個のファイバノードに直接接続される。各同軸ケーブルは、１００世帯までの家庭に接続される。
【０００３】
典型的には、同軸ケーブルは、ダウンストリーム（すなわち、配信受信機方向に）に１秒あたり１ギガビットのオーダによる容量を有する。この容量の一部は、最も普及したテレビ局などの従来の放送チャネルに用意されている。このようなチャネルは、実際の受信は支払いに応じた限定的なものであるかもしれないが、原則的にはすべての受信機により受信可能である（すなわち、すべての同軸ケーブルを介し送信される）。帯域幅の一部は、ネットワークを介した配信受信機からネットワーク外部の対象となる主体へのアップストリーム通信に用意されてもよい。通常、このアップストリーム通信は、ブロードバンドケーブルモデムを利用したインターネットに向かうものである。それはまた、対話的アプリケーションのサービス提供者へのものであってもよい。残りの帯域幅により、タイトルの受信を所望していることをユーザが示した直後に供給が実質的に開始され、大部分の受信機が同時にタイトル（映画など）の受信が可能な効果的なビデオオンデマンドサービスを提供することは、実現不可能ではないが、困難である。これを解消するため、複数の配信チャネルのグループを用いて１つのタイトルが繰り返し配信されるいわゆるニアビデオオンデマンド（ｎｅａｒ−ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ）放送配信プロトコルが開発された。効果的なプロトコルとして、Ｊ．Ｆ．Ｐａｒｉｓの「Ａ  ｆｉｘｅｄ−ｄｅｌａｙ  ｂｒｏａｄｃａｓｔｉｎｇ  ｐｒｏｔｏｃｏｌ  ｆｏｒ  ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ」（Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  １０ｔｈ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｎｅｔｗｏｒｋｓ，ｐａｇｅ４１８−４２３）に開示されるＰａｇｏｄａ配信プロトコルがあげられる。このプロトコルでは、例えば、１分間の開始時の遅延の後、配信受信機は、チャネルにおけるブロック送信シーケンスと、ブロックがどのチャネルにおいて送信されるかプロトコルにより規定された複数のチャネルからブロックを抽出することにより、リアルタイムでのタイトルの再生が可能となる。典型的には、受信機は、データのアンダフロー（ｕｎｄｅｒｆｌｏｗ）を回避するため、チャネルグループのいくつか（例えば、２つ）をタップ処理する必要がある。第１チャネルの繰り返しレートは最大となり、これにより、開始時の遅延は比較的低いものとなる。最後のチャネルの繰り返しレートは最小となる（当該チャネルは、大部分の異なるブロックの送信に利用することができる）。大量のタイトルを格納することに伴う初期費用は、上記システムの導入を妨げるものとなる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の課題は、より良いスケーラブル配信システムを提供することである。
【課題を解決するための手段】
【０００５】
本発明の課題を解決するため、データを配信するための配信システムは、ネットワークのダウンストリームチャネルを介し複数の配信受信機にデータストリームを配信するため、１つの中央配信装置から少なくとも１つの中間配信装置レイヤを介し複数の配信受信機までのデータ配信装置の階層的ネットワークを有し、前記中央配信装置の階層的に下位にある少なくとも１つの配信装置は、前記中央配信装置への前記ネットワークの少なくとも１つのアップストリームチャネルに配信データを挿入するよう動作し、前記中央配信装置は、少なくとも１つのアップストリームチャネルを介し受信した配信データを前記ネットワークの少なくとも１つのダウンストリームチャネルに再配信するよう構成される。従来、多数のタイトルの配信をサポートするためのシステムでは、中央配信装置には、これをサポートしたり、あるいは拡張を可能にするインフラストラクチャが備えられる必要があった。このため、すべてのストレージ及び帯域幅が即座に使用されなくても、価格は高いものとなっていた。本発明によるシステムでは、データをアップストリームチャネルに挿入することができる。典型的には、システムが拡張するに従い、より多くの配信装置が追加される。本発明による構成では、配信装置がタイトル（の一部）を格納するための（おそらく比較的小さな）ストレージを備えるため、限られたコストによりより大きな配信帯域幅が自動的に生成される。このとき、これらのタイトルは本システムを介した配信に利用可能となる。
【０００６】
ここで、ＷＯ９７/４８０４９は、各ユーザのノード上に効果的に分散化されたファイルサーバを有するビデオオンデマンドシステムを開示している。データ転送リンクは、これらノード間に設けられる。ノードがファイルを受信すると、他のノードによる抽出のため、当該ノードはファイルをそれのストレージに保持する。中央管理システムは、ファイルのコピーがどのノードに格納されているか記録している。ユーザがファイルを要求すると、ユーザのノードは、どのノードが要求されたファイルを有するかチェックする中央管理システムにコンタクトする。次に、最も近い経由可能なノードからユーザのノードまでのルートが確立され、データ転送が開始される。複数のユーザにより同時に要求されたファイルは、複数のノードから当該ファイルを要求した新たなノードに同時に利用可能となるであろう。当該システムは、ノード間の音声/映像のリアルタイムによる供給を可能にするため、各ノード間の高速データリンクまたはルートのために構成される。このアプローチは、このようなシステムが各エンド受信機のすべて（または大部分）にファイルを送信する機能を備えていないため、配信システムには利用することができない。特に、エンド受信機は、典型的には、データを送信するための極めて限られた帯域幅しか備えていない。通常は、このような帯域幅はリアルタイムでの音声/映像の送信には十分でない。
【０００７】
従属クレーム２の手段により示されるように、タイトルのデータブロックは、複数の配信装置のストレージ上にストライプ処理される。これにより、配信装置におけるアップストリーム帯域幅要求を軽減させ、各配信装置における格納要求を限定的なものとすることができる。
【０００８】
従属クレーム３の手段により示されるように、タイトルがストライプ処理されるストレージを有する複数の配信装置は、配信受信機による前記複数の配信装置からのブロックストリームの実質的に中断のない受信を可能にする共通な１つの配信プロトコルの制御の下、格納されているブロックを前記ネットワークの少なくとも１つのデータチャネルに挿入するよう動作する。ブロックがチャネルグループを介し送信されるシーケンスを規定する同一プロトコルを利用することにより、配信装置は、適切な時点（すなわち、適切なタイムスロット）に適切なチャネルにブロックを容易に挿入することができる。
【０００９】
従属クレーム４の手段により示されるように、前記複数の配信装置の少なくとも２つは、格納されているブロックを１つのデータチャネルの各自のサブチャネルに挿入するよう動作する。当該サブチャネルは、チャネル内の定期的に発生するタイムスロットとしてみなすことができる。同一プロトコルを利用することにより、適切なタイムスロットを使用することが容易になり、これにより、配信装置をサブチャネルに割当てることが可能となる。
【００１０】
同様に、従属クレーム５の手段により示されるように、前記複数の配信装置の少なくとも２つは、格納されているブロックを前記ネットワークの異なるデータチャネルに挿入するよう動作する。
【００１１】
従属クレーム６の手段により示されるように、前記共通の配信プロトコルは、前記チャネルに割当てられたブロックの異なる繰り返しレートの少なくとも２つのネットワークチャネルを介したタイトルの配信のため、ニアビデオオンデマンドプロトコルであり、最も高い繰り返しレートのチャネルに割当てられるブロックが第１配信装置グループにより挿入され、最も低い繰り返しレートのチャネルに割当てられるブロックが第２配信装置グループにより挿入され、第１グループの配信装置は、第２グループの配信装置より階層的に上位に置かれる。このようにして、階層の下位にある安価で低機能の配信装置に低周波数チャネルが効果的に割当てられる。また、それらはより小さなアップストリーム帯域幅しか必要とせず、格納要求はより小さなものとなる。
【００１２】
従属クレーム７の手段により示されるように、本システムは、前記ネットワークのアップストリームチャネル及び/またはサブチャネルへの配信データの挿入を制御する配信コントローラを有する。配信コントローラは、例えば、配信装置による挿入をトリガーし、各配信装置にどのブロックを挿入する必要があるか、使用されるチャネルグループ及び挿入開始を通知する。コントローラは、配信受信機からの要求に応答して、タイトルが挿入される必要があると判断するかもしれない。
【００１３】
従属クレーム８の手段により示されるように、前記配信コントローラは、少なくとも１つのアップストリームチャネル及び/またはサブチャネルへの以降の挿入のため、複数の配信装置にデータブロックを提供するよう動作する。このようにして、コントローラは、好ましくは、ネットワークの配信装置の階層位置及び/または配信装置に対する負荷（帯域幅及び/または格納に関する）に依存して、配信装置にタイトルを割当てることができる。
【００１４】
従属クレーム９の手段により示されるように、少なくとも１つの配信受信機は、前記ネットワークの少なくとも１つのアップストリームデータチャネル及び/またはサブチャネルに配信データを挿入するよう動作する。好ましくは、配信受信機のアップストリーム容量は、他の配信受信機へのデータの配信に利用される。より多くの配信受信機に恒久的なストレージ（ハードディスクレコーダの形態など）が備えられるため、受信機の合成されたストレージは、システムの残りに対する追加的コストなく、タイトルのための大量のストレージを生成する。
【００１５】
従属クレーム１０の手段により示されるように、複数の配信受信機が、前記ネットワークの少なくとも１つのアップストリームデータチャネル及び/またはサブチャネルに配信データを挿入するよう動作し、前記複数の配信受信機の各々は各自のストレージを有し、タイトルは前記複数の配信受信機のストレージ上でストライプ処理される。複数の受信機上にタイトルをストライプ処理することにより、受信機のアップストリーム帯域幅要求は低く抑えることができ、データの配信に用いられるストレージを限定的なものとすることができる。
【００１６】
従属クレーム１１の手段により示されるように、前記ストレージは、ソリッドステートメモリを有する。十分な個数の受信機上でタイトルをストライブ処理することにより、各受信機の格納要求は極めて小さいものとなり、極めて限定的なコストによる信頼性の高いソリッドステートメモリの使用を可能にする。
【００１７】
本発明の上記及び他の特徴は、以降で説明される実施例を参照することにより明らかとされる。
【発明を実施するための最良の形態】
【００１８】
図２は、本発明による配信システムのブロック図を示す。配信システム１００は、データ配信装置の階層的ネットワークを有する。ネットワークの最上位は、中央配信装置１１０により構成される。本システムは、少なくとも１つの中間配信装置レイヤを有する。図を簡単化するため、各々が離散的な地理的エリアをカバーする３つの中間配信装置１２０、１３０及び１４０によるダウンストリーム配信のための１つのみの中間レイヤが示される。図１は、３つの中間ダウンストリームレイヤ（メトロヘッドエンド、ハブ、ファイバノード）による接続された２００，０００世帯の家庭を有する町に対する典型的な階層的ネットワークを示す。本例では、４つの同軸セグメントが各ファイバノードに接続されている。図２はまた、中央配信装置１１０から始まり、中間配信装置１２０、１３０及び１４０を介し行われ、システムの複数の配信受信機において終わるダウンストリームパス１６０を示す。従来、配信装置は階層的に１段低いレイヤ上の受信機/配信装置に配信信号を分割する。簡単化のため、配信受信機１５０のみが示される。典型的には、当該パスは複数のチャネルに分割され、各チャネルはサブチャネルに分割されてもよい。最下位レベルでは、通常は配信受信機に共有される媒体を構成する同軸セグメントが利用される。同軸上では、チャネルは通常は周波数多重化されている。当該チャネル内のサブチャネルは、時間多重化されてもよい。より上位のレベルでは、典型的には、光ファイバが利用される。このような媒体では、チャネルはまた時間多重化されてもよい。各種メディア及び多重化技術などの任意の適切な送信技術が利用されてもよい。ネットワークを介し複数の配信受信機にデジタルデータストリームを配信するための配信システムが説明される。データストリームは、ＭＰＥＧ２映像符号化などの任意の適切な技術を用いて符号化されていてもよい。配信データは特定の受信機にアドレス指定されるのでなく、原則的には階層的ネットワークのすべてのセグメントにおける受信機全体に受信可能とされる。データへのアクセスは、支払いによるものであってもよい。本発明による配信システムでは、適切な限定受信機構を用いてアクセスが制御されてもよい。システムの各装置に対して、図２は、配信データの送受信及びすべての必要な処理の実行に必要とされるハードウェア/ソフトウェア機能１１２、１２２、１３２、１４２及び１５２を概略的に示す。このようなハードウェア/ソフトウェアは既知であり、本発明によるシステムに利用可能である。ハードウェア/ソフトウェアは、信号プロセッサなどの適切なプロセッサを利用することにより制御される適切な送受信機（光ファイバ受信機及び/またはケーブルモデムなど）により構成されてもよい。また、ＭＰＥＧエンコーダ/デコーダ、バッファなどの専用ハードウェアが利用されてもよい。
【００１９】
従来、すべてのデータストリームは中央配信装置１１０により挿入され、各中間レイヤによりネットワークの最下位部分に無修正でコピーされていた。このため、中央配信装置は、映画などの複数のタイトルを格納するストレージ１１５を有するようにしてもよい。中央配信装置はまた、衛星接続などを介しライブの配信を受信する接続１６０を有するようにしてもよい。ストレージ１１５は、ＲＡＩＤシステムなどに基づき適切なサーバプラットフォーム上で実現されてもよい。本発明によると、中央配信装置から階層的に下位にある少なくとも１つの配信装置は、中央配信装置へのネットワークの少なくとも１つのアップストリームチャネルに配信データを挿入するよう動作する。図２は、参照番号１７０によりアップストリームチャネルを示す。原則的に、アップストリームチャネルは、上位に向かう中間レベルにおいて開始される。好ましくは、アップストリームチャネルは、最下位レベルにすでに存在し、配信システム外部との通信を可能にしている（例えば、中央配信装置または中間配信層を介しインターネットへなど）。中間/中央配信装置は、それの下位にある複数の装置からアップストリームチャネルを介しデータストリームを受信するかもしれない。これらのストリームを合成することは、配信装置のタスクである。これは、例えば、これらのストリームの一部を一時的に格納し、それを１つの共通の時間ベースを用いて上位に送信することによってなど、各ストリーム間の時間差を補償することにより（デジッタリング（ｄｅ−ｊｉｔｔｅｒｉｎｇ））行われてもよい。このような時間ベースは、ダウンストリームチャネルを介し中央配信装置により提供されるようにしてもよい。デジッタリングは周知であり、さらなる説明は与えられない。特に、中央配信装置は、少なくとも１つのアップストリームチャネルを介し受信された配信データをネットワークの少なくとも１つのダウンストリームチャネルを介し再配信するよう構成される。アップストリームチャネルを介しタイトルを供給することが可能となるように、注入装置は、当該タイトルのソースにアクセスする必要がある。図２は、中間配信装置１２０、１３０及び１４０の各々がタイトルの少なくとも一部を格納するための各自のストレージ１２５、１３５及び１４５を有することを示す。このようなストレージは、例えば、ＲＡＩＤシステムを用いて実現されたハードディスクや、ソリッドステートメモリなどの他の適切なストレージにより構成されてもよい。以下で詳細に説明されるように、配信受信機１５０はタイトルを上位に挿入するかもしれない。その場合、受信機はまた格納されているタイトルにアクセスする必要がある。ストレージ１５５が示されている。当該ストレージはまた、ハードディスクやソリッドステートメモリなどの他の適切なストレージにより構成されてもよい。このようなハードディスクは、ダウンストリームチャネルを介し受信されるタイトルを（一時的または永久的に）格納するため何れかの方法により既に設けられていてもよい。
【００２０】
好ましくは、タイトルのデータブロックは、複数の配信装置のストレージにストライプ処理（ｓｔｒｉｐｅｄ）されている。これにより、配信装置におけるアップストリーム容量及び格納に対する要求を低減させることができる。典型的には、１つのレベルにおける配信装置は、同様のアップストリーム能力を有し、この容量は階層が下位になるほど減少する。ストライプ処理を簡単化するため、１つのレベルの配信装置のみを用いてタイトルをストライプ処理することが好ましい。好ましくは、このタイトルは、配信装置が階層の下位にある場合、より多くの配信装置にストライプ処理される。ストライプ処理自体は、１つのローカルストレージシステムのハードディスクに対して既知である。本発明によるシステムでは、ストライプ処理は配信システムを介し接続されるストレージ上で実行される。あるタイトルのブロックの適切な選択が関係する配信装置の各自のストレージに格納されると、ストライプ処理されたタイトルの再生が開始可能となる。再生は、図２の装置１８０などの中央装置（配信コントローラ）の制御の下で実行されるかもしれない。好ましくは、中央装置１８０は、中央配信装置１１０に接続されるか、あるいはそれの一部として構成される。所望される場合には、各配信装置がネットワークの一部に供するように、各レイヤに１つ、あるいは各中間配信装置に１つなどのように、複数の配信コントローラを設けることも可能である。中央装置１８０は、タイトルのどのブロックがどのストレージに格納されているか把握しているようにしてもよい。このとき中央装置は、ブロックが適切なシーケンスにより配信されることを確実にするため、適切な時点において明示的な「リード」命令を適切な配信装置に発するようにしてもよい。特に、配信コントローラは、ネットワークのアップストリームチャネル及び/またはサブチャネルへの配信データの挿入を制御する。
【００２１】
好適な一実施例では、タイトルがストライプ処理されるストレージを有する複数の配信装置は、１つの共通の配信プロトコルの制御の下、ネットワークの少なくとも１つのデータチャネルに格納されているブロックを挿入するよう動作する。この実施例では、再生制御は分散化される。同じプロトコルを利用することは、配信受信機による複数の配信装置からのブロックストリームの実質的に中断のない受信を可能にする。１つのチャネルは、複数のサブチャネルに分割されてもよい。チャネル内のどのサブチャネルが使用される必要があるか規定する共通のプロトコルを利用することにより、配信装置は、１つのデータチャネルの各自のサブチャネルにストライプ処理されたブロックを挿入するよう動作する。このプロトコルはまた、タイトルを配信するため複数のチャネルを利用することに基づくものであってもよい。タイトルの各データブロックに対し、挿入される必要があるチャネルを規定することにより、受信機があたかも中央配信装置により配信されているかのようにタイトルを依然として受信することが可能であるが、配信装置は、ネットワークの異なるデータチャネルに格納されているブロックを挿入するよう動作する。
【００２２】
タイトルのブロックは、複数の階層レイヤの配信装置によって挿入されてもよい。好ましくは、挿入を制御する共通の配信プロトコルは、チャネルに割当てられたブロックの異なる繰り返しレートの少なくとも２つのネットワークチャネルを介したタイトルの配信のためのニアビデオオンデマンド（ＮＶｏＤ）プロトコルである。このようなプロトコルを利用することにより、最大繰り返しレートのチャネルに割当てられるブロックは、効果的に、第２の配信装置グループの階層的に上位にある配信装置グループにより挿入される。この第２の配信装置グループは、最も低い繰り返しレートチャネルに割当てられるブロックを挿入する。このようにして、挿入により生じる負荷は、（特にアップストリーム容量及び格納要求に関して）、関与する配信装置の容量に対応する。
［固定遅延Ｐａｇｏｄａ配信］
好ましくは、タイトルのデータブロックを配信するためのニアビデオオンデマンドプロトコルとして、固定遅延Ｐａｇｏｄａ配信プロトコルが利用される。このプロトコルは、漸近的に最適であり、限定的なクライアントＩ/Ｏ帯域幅に容易に適応可能である。図３Ａにおいて、これの小さな例が与えられる。図３Ｂは、任意の時点における要求に対し抽出がどのように実行されるか示す。図３の例では、高々２つのチャネルが同時にタップ処理され、すべてのブロックが時間内に到着する。このＮＶｏＤスキームのキーは、チャネルｉがチャネルｉ−２のタッピングが完了した後にタップ処理を開始されるというものであり、これにより、タップ処理されるチャネル数を２に限定することができる。このことは、例えば、チャネル４に対して、受信機は当該チャネルのタップ処理が開始可能となる前に、２時間単位だけ待機する必要があるということを意味するものである。ブロック７は要求後に７時間単位以内で受信される必要があるため、これは、５時間単位のみが受信するのに残され、これにより７でなく高々５期間で送信される必要があるということを意味するものである。実際、それは４期間で送信される。上記配信スキームの一般的構成が、受信可能な所定数ｒのクライアントチャネルと所定数ｃのサーバチャネルに対して説明される。さらに、オフセットｏは、説明されるように、再生前にユーザが追加的ｏ時間単位だけ常に待機するということを意味すると考えられる。チャネルｉの（タップ処理）のセグメントの始まりはｓｉにより表され、終わりはｅｉにより表される。このとき、ユーザが受信可能な最大チャネル数ｒを超えないように、チャネルｉ＝ｒ＋Ｉ，．．．，ｃにおけるタップ処理は、チャネルｉ−ｒのタップ処理が終了した後に開始される。従って、
【００２３】
【数１】
2006509456.tif 000003
次に、チャネルｉにおいて、ブロックｌｉ，．．．，ｈｉが送信される。従って、チャネルｉで送信される相異なるブロック数は、
ｎｉ＝ｈｉ−ｌｉ＋１により与えられる。ただし、
【００２４】
【数２】
2006509456.tif 000004
である。
【００２５】
時間内に各ブロックを受信するため、ブロックｋは、時間単位ｏ＋ｋにおいて、またはそれ以前に送信されるべきである。ブロックｋが時間単位ｓｉで受信を開始するチャネルｉで送信される場合、これは、ブロックｋが高々ｏ＋ｋ−（ｓｉ―１）の期間で配信されるべきであるということを意味する。理想的には、当該期間は各ブロックｋに対し正確に満たされるが、十分近接させるには十分である。
【００２６】
Ｐａｇｏｄａスキームによるチャネルｉの構成は以下のようなものである。まず、チャネルｉは、
【００２７】
【数３】
2006509456.tif 000005
によって、すなわち、最も近い整数に丸められたブロックｌｉの最適期間の平方根によって与えられるｄｉ個のサブチャネルに分割される。各サブチャネルは、ラウンドロビン方式によりブロックを送信するための時間単位の一部１/ｄｉを取得する。言い換えると、時間単位ｔにおいて、サブチャネルｔ  ｍｏｄ  ｄｉは１つのブロックを送信することが可能であり、サブチャネルは０，１，．．．，ｄｉ−１に番号付けされる。
【００２８】
ここで、ブロックｋにチャネルｉのサブチャネル内において期間ｐｋが与えられると、ブロックｋはｐｋｄｉの期間によりチャネルｉにおいて配信される。従って、
ｐｋｄｉ≦ｏ＋ｋ−（ｓｉ―１）
とするため、
【００２９】
【数４】
2006509456.tif 000006
となることを意味する。
【００３０】
各サブチャネル内のすべてのブロックに対して等しい期間をとることにより、衝突を回避することができる。従って、ｌｉｊがチャネルｉのサブチャネルｊにおける最小ブロック番号である場合、これは、チャネルｉのサブチャネルｊ内のすべてのブロックに対して、以下の期間が選ばれることを意味する。
【００３１】
【数５】
2006509456.tif 000007
従って、当該サブチャネルにおいてｎｉｊ＝ｐｉｊ個のブロック（ブロックｌｉｊ，．．．，ｌｉｊ＋ｎｉｊ−１）を送信することが可能となる。ブロック番号ｌｉｊは、
【００３２】
【数６】
2006509456.tif 000008
により与えられる。
【００３３】
チャネルｉで送信されるブロックの総数ｎｉは、
【００３４】
【数７】
2006509456.tif 000009
により与えられ、これにより、
ｈｉ＝ｌｉ＋ｎｉ−１
を計算することができる。
【００３５】
最終的に、あるチャネル内のセグメントのスタート及びエンド時点が参照される。チャネルｉのすべてのサブチャネルは、時点ｓｉにおいて送信を開始する。チャネルｉのサブチャネルｊは、ｎｉｊブロックの後に準備され、チャネルｉ内でｄｉｎｉｊ時間単位を要する。従って、サブチャネルｊの当該セグメントのエンドは、
ｅｉｊ＝ｓｉ−１＋ｄｉｎｉｊにより与えられ、それの最後のサブチャネルが、
【００３６】
【数８】
2006509456.tif 000010
において終了するとき、チャネルｉは終了する。
【００３７】
上記を例示するため、図４は、図３の例に第５チャネルを追加することを示す。第５チャネルに対して、以下の式が成り立つ。すなわち、ｌ５＝１２，ｓ５＝ｅ３＋１＝６及びオフセットｏ＝０である。サブチャネル数は、
【００３８】
【数９】
2006509456.tif 000011
である。サブチャネルｊ＝０に対し、これはｌ５，０＝１２を与え、これにより当該サブチャネルにおいてブロック１２と１３である
【００３９】
【数１０】
2006509456.tif 000012
個のブロックを送信することが可能である。サブチャネルｊ＝１に対し、これはｌ５，１＝１４を与え、これにより当該サブチャネルにおいてブロック１４、１５及び１６である
【００４０】
【数１１】
2006509456.tif 000013
個のブロックを送信することが可能となる。サブチャネルｊ＝２に対し、これはｌ５，２＝１７を与え、これにより当該サブチャネルにおいてブロック１７、１８、１９及び２０である
【００４１】
【数１２】
2006509456.tif 000014
個のブロックを送信することが可能となる。当該サブチャネルのセグメントのエンドは、
ｅ５，０＝５＋３＊２＝１１、
ｅ５，１＝５＋３＊３＝１４及び
ｅ５，２＝５＋３＊４＝１７
により与えられ、これによりｅ５＝１７となる。
【００４２】
ｈｉの値、すなわち、映画が分割可能であるブロック数は、オフセットゼロとｒの各値に対してテーブル１により与えられる。当該系列は、ｒ＝２，３，４及び∞のそれぞれに対し、約１．７５，２．４２，２．６２及び
【００４３】
【数１３】
2006509456.tif 000015
をベースとするべき級数に収束する。
【００４４】
【表１】
2006509456.tif 000016
最後の列は、クライアントチャネル数が無制限であることに対応する。ｈｃの上記値を用いて、最大待機時間は、ｃ個のチャネルを使用するとき、映画の長さの一部１/ｈｃにより与えられる。正のオフセットｏが用いられる場合、最大待機時間の一般的な式は、映画の長さの一部（ｏ＋１）/ｈｃとなる。
【００４５】
以前のセクションでは、チャネルｉのサブチャネルの個数ｄｉは一定とされ、式（１）により与えられる。ここで、映画が分割可能となるブロック数に関してより良い解を得るために、異なる値が用いられるようにしてもよい。このため、チャネルｉごとに式（１）で与えられる目標値近傍のいくつかの異なる値を求め、チャネルｉに適合可能なブロック数を計算し、チャネルｉが最大となるブロック数を有することが可能なサブチャネル数をとることにより、１次最適化が適用可能である。ここで、当該処理は、直接的な実現により指数的な実行時間がかかることを回避するため、個々のチャネルごとに実行される。すなわち、以前のチャネルへのバックトラッキングは発生しない。これは、チャネルｉにおいてより多くのブロックを取得するためチャネルｉにおいて異なる個数のサブチャネルを選択することが、エンド時間ｅｉを増加させ、これによりチャネルｉ＋ｒのスタート時間ｓｉ＋ｒを増加させ、当該チャネルに適合可能なブロック数を減少させるとき、次善解を導くかもしれない。にもかかわらず、この１次最適化は、テーブル２に示されるような良好な結果を与える。オフセットゼロとｒの異なる値に対して、ｈｉの新たな値が与えられる。これらの値は前のテーブルのものより大きいが、べき級数のベースはテーブル１のものと同一である。
【００４６】
【表２】
2006509456.tif 000017
以下では、従来のＰａｇｏｄａプロトコルに対するテーブル１の値が用いられる。
【００４７】
これまでの説明では、タイトルは一定のビットレート（ＣＢＲ）を有すると仮定されていた。しかしながら、この送信スキームは、可変ビットレート（ＶＢＲ）ストリームに対処するよう容易に適応化可能である。ブロックｋが到達しなければならない時点は、ＣＢＲストリームではｏ＋ｋにより与えられ、このとき関数ｏ＋ｔ（ｋ）により与えられる。ここで、ｔ（ｋ）は、当該ストリームが時間内に再生される方法を説明する増加関数である。送信スキームに対する効果は以下の通りである。ブロックｋが時点ｓｉにおいて開始されるチャネルｉにおいて送信される場合、ブロックｋは高々ｏ＋ｔ（ｋ）−（ｓｉ―１）の期間により配信される必要がある。従って、式（１）で与えられるようなサブチャネル数の目標値は、
【００４８】
【数１４】
2006509456.tif 000018
となる。
【００４９】
このとき、チャネルｉのサブチャネルｊにおけるブロック数、すなわち、当該サブチャネル内で用いられる期間は、
【００５０】
【数１５】
2006509456.tif 000019
により与えられる。残りの計算は同様である。
［ネットワーク仮定］
以下において、本発明によるマルチポイント挿入の３つの例が与えられる。これらの例をサポートする計算は、図１に示される階層的ネットワークに対して与えられる。主要なボトルネックは、家庭とファイバノードとの間のアップストリーム及びダウンストリームリンクの容量により与えられる。この例では、これらはそれぞれ４００ｋｂ/ｓと２０Ｍｂ/ｓとされる。５Ｍｂ/ｓの映像伝送レートを仮定すると、１つの家庭に対して、０．０８の映像チャネルがアップストリームとされ、４つの映像チャネルがダウンストリームとされる。２００，０００家庭を有するとき、１６，０００の映像チャネルのトータルアップストリーム容量が与えられる。ニアビデオオンデマンドスキームを利用することにより、限定的なダウンストリーム容量が考慮されるべきである。これらの例では、ファイバノードの上位の帯域幅には実際的な制限はないと仮定される。当業者は、説明される原理に基づき異なるシステムを構成することが可能となるであろう。さらに、すべての家庭が恒久的に接続され、ノードにおけるエラーや送信中のデータロスは生じないと仮定される。最後に、各々が６０００秒（１００分）からなる１０００本の映画を有することが望ましいと仮定される。映画のサイズは、３０Ｇｂ、すなわち、３．７５ＧＢである。
［好適なＮＶｏＤ手段］
約１秒の最大反応時間と、タップ処理されるｒ＝３チャネルの制約を目標として、テーブル１は、映画が６３０８ブロックに分割可能な１１の送信チャネルが利用されるべきであることを示し、実際の最大反応時間は、６０００/６３０８≒０．９５秒となる。家庭において１０００本の映画すべての１１の送信チャネルを生成することは、利用可能な１６，０００のチャネルのうち１１，０００を利用することになるであろう。図６に示される第１の例では、いくつかのチャネルがファイバノードから送信される。残りのチャネルは、中央配信装置などの他の配信装置から送信されるようにしてもよい。第１の例では、残りのチャネルは配信受信機がアップストリーム配信装置として動作することにより送信される。より上位のレベルのいくつかのチャネルを挿入することにより、家庭からのアップストリームチャネルに関する帯域幅要求が低減される。好ましくは、各映画の第１送信チャネルがファイバノードに格納され、各映画の第１送信チャネルは比較的少数のブロックに関するものであるため、ファイバノードに対する格納要求を限定的なものとする。たとえば、ファイバノードから最初の６つのＮＶｏＤチャネルを送信することにより、各映画の８６/６３０８≒０．０１４に相当する部分が、ファイバノードレベルに格納される必要があり、それは各映画の３７５０＊８６/６３０８≒５１ＭＢに相当する。１０００本の映画と５００個のファイバノード有する場合、これを各ファイバノードに対して１０２ＭＢのＲＡＭモジュールやフラッシュメモリモジュールなどのソリッドステートメモリに格納することができる。このようにして、各ファイバノードは、２つの映画の６つのチャネルに対しブロックを格納する。約３．７ＧＢに相当する各映画の（６３０８−８６）/６３０８≒０．９８６に相当する残りのストレージは、家庭に分散されている必要がある。もちろん、これは１または少数の配信受信機に格納されるようにしてもよい。しかしながら、より一様な分布を利用することが好ましい。すべての受信機に分散させると、ソリッドステートメモリに格納可能な各家庭に対し３７００＊１０００/２００，０００≒１８．５ＭＢの格納容量が必要とされる。この一様な分散化は、各映画を２００のストライプにストライプ処理し、各家庭にＮＶｏＤチャネル７〜１１の各々のストライプを送信させることにより実現させることが可能である。もちろん、より少数の配信装置しか関与させず、その他の配信装置に冗長性を持たせるようにしてもよい。図５は、映画をブロック及びストライプに分割する方法に関する図式表現を与える。この例では、映画の最初の６つのチャネルに対するブロックが１つのファイバノードに格納され、残りのブロックが家庭の配信受信機にストライプ処理される（このストライプ処理は、水平グレイストライプを用いて示される）。この図はスケーリングが行われていない。１１のＮＶｏＤチャネルのセグメントの境界は、テーブル１のｈｉの値により与えられる。このとき、ファイバノードは、各ＮＶｏＤチャネルに対し２００個の「ストライプチャネル」をマージすることにより与えられる。各ファイバノードは、それに接続された４００の家庭を有し、このため、２つの映画の���ＶｏＤスキーム全体を生成することができる。ここで、各「ストライプチャネル」は、各家庭に対し１２５ｋｂ/ｓのトータルアップストリームビットレートを与える５０００/２００＝２５ｋｂ/ｓのビットレートを有する。
【００５１】
ファイバノードと家庭において要求されるストレージは、使用されるチャネル数、すなわち、求められる反応時間から比較的独立している。例えば、チャネル数を１２に増やす場合、反応時間は、６０００/１５１９２≒０．３９秒に短縮される。この結果、映画は約２．４倍の個数のブロックに分割され、これにより、当該ブロックは約１/２．４だけ小さくなる。従って、他の例では、ファイバノードに１以上のチャネル、すなわち、チャネル１〜７を生成させ、家庭にチャネル８〜１２を生成させることが可能となる。このとき、ファイバノードのストレージは、各映画に対し３７５０＊１９８/１５１９２≒４９ＭＢに等しくなり、これは１１個のチャネルに求められる５１ＭＢにほぼ等しい。家庭のストレージは、映画の１/２００よりやや小さいものとなる。テーブル３は、様々な個数のチャネルがファイバノードと家庭に割当てられる場合の図５の値を示す。
【００５２】
【表３】
2006509456.tif 000020
あるいは、各映画のＮＶｏＤチャネル７〜１１がまた、ネットワークにより上位に挿入することができる。図７は、それらがファイバノードに挿入される解法を示す。このために、ファイバノードは、タイトルを格納するためのハードディスクなどのさらなるストレージが備えられる必要がある。図８は、チャネルがハブに挿入されるさらなる他の解法を示す。これは、各ハブに対し１５０ＧＢのストレージを有することに関する。
【００５３】
図２の配信コントローラ１８０は、少なくとも１つのアップストリームチャネル及び/またはサブチャネルへの以降の挿入のため、適切な配信装置にタイトルのデータブロックを提供するタスクを有するようにしてもよい。これは、当該ブロックを意図された各配信装置に直接アドレス指定することにより実行されてもよい。あるいは、各配信装置がそれに割当てられたブロックを抽出及び格納することができるように、各配信装置にどのブロックが抽出されるか指示し、その後タイトルを配信するというものである。
［フィルタリング］
多数のニアビデオオンデマンド映画（例えば、１０００本の映画）の同時送信をサポートするため、配信システムは、高帯域幅を必要とする。マスタヘッドエンドとファイバノードとの間のレベルに対し、これは、光ファイバベースの配信を利用するなど、適切な専用リンクを利用することにより容易に実現することができる。特に最下位レベルでは、同軸などの共有媒体の使用が最も経済的である。例えば、光ファイバモードによりデータを選択的にフィルタリングし、少なくとも１つの対象となる受信機が存在するデータ上にわたすことによって、帯域幅を比較的多数の映画の同時配信に十分なものにすることができる。フィルタリングを利用することによって、マスタヘッドエンドにより送信されたデータは、実際にはすべての配信受信機により受信可能となることを保証するものではない。すなわち、それはローカルネットワークセグメント上に存在しないかもしれない。ここで、ネットワークの上位レベルではまた、すでに選択を行うことが可能であり、例えば、ハブはそれのサブツリーの任意のユーザにより使用される映画のブロックのみを転送するだけでよく、その他のものは転送される必要はない。
［冗長性］
上述の配信スケジュールは、配信装置の１つ（配信受信機を含む）がブロックの送出ができない場合には失敗するかもしれない。例えば、映画の配信に加入する２００世帯の家庭の何れかのセットトップボックス（配信受信機）が時間内にストライプチャネルのそれの共有分を送出しない場合、当該タイトルは完全には受信されないか、あるいはリアルタイムでの再生が不可能となる。受信機にブロックをストライプ処理する上述の例では、共有分は５つのストライプチャネルから構成される。セットトップボックスがそれの共有分の送出に失敗する理由は多数考えられるが、最も可能性のある理由としては、所有者が休日で不在であったり、あるいは停電のためセットトップボックスのスイッチがオフになっているためであるかもしれない。他の理由としては、ユーザが緊急なもののためアップストリーム帯域幅全体を一時的に使用する必要がある場合があげられる。前者の場合には、セットトップボックスは数日または数週間の単位で長期間利用可能でないかもしれず、このため、それのアップストリーム帯域幅は同じ同軸上の他のセットトップボックスにより使用可能となる。このことは、それの配信タスクが同じ同軸上の他のセットトップボックスに引継ぎ可能であるということを意味する。配信タスクの再分散化は、数分以上かかるものとされるべきでない。後者の場合には、中断は数秒あるいは数分の単位の極めて短いものとあるであろう。これは、セットトップボックスまたはコントローラ１８０の帯域幅スケジューラにより実現可能である。
【００５４】
受信機が割当てられたブロックを供給することができなくなる確率を低下させるため、多くの対策がとられてもよい。例えば、受信機は、ユーザが受信機をスイッチオフすることを奨励されないように構成されてもよい。受信機は、例えば、それの共有分を格納するためフラッシュメモリを利用し、短時間の電源故障に対処するためバッテリーを利用するなどすることにより、適度な耐故障性を備えるよう実現されてもよい。
【００５５】
好適な一実施例では、少なくとも１つの装置にブロックをストライプ処理し、アクセス可能な符号化ブロックからブロックを再生成することにより、１つの装置の故障に対処可能となるように、格納されているブロックを符号化することにより、冗長性が導入される。ストライプチャネルの好適な符号化スキームは、（Ｎ，ｋ）Ｒｅｅｄ−Ｓｏｌｏｍｏｎ符号化である。Ｒｅｅｄ−Ｓｏｌｏｍｏｎ符号化自体は周知なものである。その説明は、Ｓ．Ｂ．ＷｉｃｋｅｒｔｏＶ．Ｋ．Ｂｈａｒｇａｖａの編集による「Ｒｅｅｄ−Ｓｏｌｏｍｏｎ  Ｃｏｄｅｓ  ａｎｄ  Ｔｈｅｉｒ  Ａｐｐｌｉｃａｔｉｏｎｓ」（ＩＥＥＥ  Ｐｒｅｓｓ，１９９４）に求めることができる。例えば、Ｒｅｅｄ−Ｓｏｌｏｍｏｎ符号化は、好ましくは、Ｎ＝２００とｋ＝２００−ｒのパラメータにより利用される。映画は、（２００−ｒ）個のストライプチャネルの共有分に分割され、ｒ個のストライプチャネルのパリティ類似共有分が計算される。結果として得られる２００個の共有分が２００個のセットトップボックスに分散化される。これら符号化されたストライプチャネルは、以前のセクションで説明された未処理のストライプチャネルの２００/（２００−ｒ）倍だけ増加している。ｒ＝１０に対して、このことは、セットトップボックスにおいて必要とされるアップストリーム帯域幅と格納の約５％の増加を犠牲にすることにより、送信失敗時の部分が１００万分の１以下に減少し、映画の３０秒の中断の確率が１：２０，０００であるということを意味するものである。
【００５６】
タイトルがネットワークのあるレベルの装置にストライプ処理されると仮定すると、上位階層レベルは容易にブロックを復元することが可能である。一例として、タイトルが１つのファイバノードより階層的に下位にあるすべてのセットトップボックスのグループにストライプ処理されている場合、当該ファイバノードはもとのブロックを容易に抽出することが可能となる。このため、ファイバノードは、それの下位の４００個のセットトップボックスから配信される映画の復号化（Ｒｅｅｄ−Ｓｏｌｏｍｏｎ復号化）を実行する追加的なハードウェア及び/またはソフトウェアを必要とする。このようなハードウェア/またはソフトウェアは既知であり、さらなる説明は与えない。１つのファイバノードの下位の全体に映画を格納することが好適であるため、ファイバノードは復号化を実行することが可能であり、これにより、冗長性の実現はファイバノードレベルより上位の帯域幅及び追加的ハードウェア/ソフトウェアを必要としない。
【００５７】
ここで、上記実施例は本発明を限定するのでなく例示するものであり、当業者は添付された請求項の範囲から逸脱することなく他の多くの実施例を構成することができるであろう。請求項において、カッコ内の参照符号は、当該請求項を限定するものと解釈されるべきではない。「有する」という用語は、請求項列挙されたもの以外の他の要素またはステップの存在を排除するものでない。本発明は、複数の相異なる要素を有するハードウェアによって、そして適切にプログラムされたコンピュータによって実現することができる。複数の手段を列挙したシステムクレームでは、これらの手段の一部は、同一のハードウェアアイテムにより実現することができる。コンピュータプログラムプロダクツは、光記憶装置などの適切な媒体に格納/配布されてもよいが、配信システムのネットワーク、インターネットまたは無線通信システムを介し配布されるなど、他の形態により配布されてもよい。
【図面の簡単な説明】
【００５８】
【図１】図１は、本発明が利用可能な一例となる階層的配信ネットワークを示す。
【図２】図２は、本発明による配信システムのブロック図を示す。
【図３】図３は、ＰａｇｏｄａＮＶｏＤプロトコルを示す。
【図４】図４は、Ｐａｇｏｄａプロトコルによるチャネルの追加を示す。
【図５】図５は、本発明によるマルチポイント挿入及びストライプ処理を示す。
【図６】図６は、好適な一実施例を示す。
【図７】図７は、好適な一実施例を示す。
【図８】図８は、好適な一実施例を示す。
【図１】
2006509456.tif 000021
【図２】
2006509456.tif 000022
【図３】
2006509456.tif 000023
【図４】
2006509456.tif 000024
【図５】
2006509456.tif 000025
【図６】
2006509456.tif 000026
【図７】
2006509456.tif 000027
【図８】
2006509456.tif 000028
【国際調査報告】
2006509456.tif 000029
2006509456.tif 000030
2006509456.tif 000031