JP2005505957A - ネットワーク上でのデータ伝送方法 - Google Patents

Abstract

本発明は、大規模ビデオ・オン・デマンド(VOD)システムの構築に適した多数のクライアントにネットワーク上でデータを伝送する新規な方法及びシステムを記載している。現在のVODシステムでは、ネットワーク負荷を深刻に増大すること無しに、クライアントは十分な対話機能を提供可能な要求データの受信を開始する前又はその逆の動作をする前に長い待ち時間を要する。この方法は、データストリームの２つのグループを用いる。一方は待ち時間を最小化し、他方は要求された対話機能を提供する。待ち時間防止データグループでは、均一、非均一又は階層的な時差ストリーム間隔が用いられる。本発明のシステムは、ユーザがビデオレコーダの特徴である対話機能を最大限楽しみながら、比較的短いスタートアップ待ち時間を有する。さらに、本発明は要求された多数のデータストリーム又は帯域を維持できる。

Description

【技術分野】
【０００１】
［発明の分野］
本発明は、ネットワーク上でのデータ伝送方法及びシステムに関し、特にビデオ・オン・デマンド（VOD）システムなど多数のクライアントに反復的内容の大量のデータを送るための方法及びシステムに関する。
【背景技術】
【０００２】
［発明の背景］
現在のVODシステムは、多数の課題に直面している。その1つは、数百万にも達するであろうクライアントにいかにして早送り/早戻し及び（または）送りジャンプ/戻しジャンプなど十分な対話性を与えるか、である。同時に、ネットワーク資源すなわち帯域幅は限られているので、この種の機能を与えることが深刻なネットワーク負荷となってはならない。さらに、一般的に言って、全てのクライアントが、自分が選択する映画ができる限り速やかに開始されることを好む。
【０００３】
以下の節においては、現在使用されているVODシステム及びその考えられる不利点についていくつか説明する。
【０００４】
1. 規則的なストリーム間隔のニアVOD
NVODシステムは、規則的なストリーム間隔Tの時差的マルチキャスト・ストリームから成る（図1）。ストリームはいくつかの多重送信メカニズム（例えば、時分割多重送信、周波数分割多重送信、コード分割多重送信、波長分割多重送信など）を通じてユーザーに配信するために同一のまたは異なる物理媒体に多重送信される。配信メカニズムにはポイント-トゥ-ポイント、ポイント-トゥ-マルチポイント及びその他の方法がある。各ストリームは規則的な間隔Tのセグメントに分割され、セグメントにはそれぞれ1、2、3、….、Nのラベルが付けられる。ユーザーに配信される内容は、N個のセグメントで搬送され、内容は全てのストリームにおいて複製される。内容はまた、各ストリームにおいて正しいタイミングで反復される。このような規則的なストリーム間隔Tの時差的ストリーミング配列を使用することによって、ユーザーは、Tより短いスタートアップ待ち時間でいつでも内容を受信することが保証される。ただし、この種のシステムはユーザー対話性を持たない。ユーザーが、例えばディスプレイを一時停止することによって内容視聴を中断する場合、ユーザーは、ユーザーが一時停止したプレイ・ポイントから視聴を再開することができず、連続的に放映されているマルチキャスト・ストリームに追いつくためにはある程度の内容をスキップせざるを得ない。
【０００５】
2. 不規則なストリーム間隔の準VOD（QVOD）
QVODシステムは、不規則なストリーム間隔の時差的マルチキャスト・ストリームから成る（図2）。ストリームはいくつかの多重送信メカニズム（例えば時分割多重送信、周波数分割多重送信、コード分割多重送信、波長分割多重送信など）を通じてユーザーに配信するために同一のまたは異なる物理媒体に多重送信される。配信メカニズムにはポイント-トゥ-ポイント、ポイント-トゥ-マルチポイント及びその他の方法がある。ストリームが一定に存在するNVODシステムと異なり、QVODシステムにおけるストリームはユーザーの内容要求によるデマンドに応じて生成される。ある一定の時間間隔T_i内のユーザーの要求は、一括処理されて、ストリーム_iによって一緒に応答される。ストリーム間隔T₁、T₂、….、T_iは、不規則である。ストリーム（ストリーム₁からストリーム_iまでなど）は、全てオン・デマンドで供給され、内容配信が完了したらすぐに取り除かれる。ストリームはユーザーの要求が着信すると絶え間なく生成される。このような不規則ストリーム間隔T_iの時差的ストリーミング配列を使用することによって、間隔T_i内に開始するユーザーの特定グループは、Ti（スタットアップ待ち時間）以内に内容を受信することが保証される。この場合にも、この種のシステムにはユーザー対話性がない。ユーザーが例えばディスプレイを一時停止することによって内容視聴を中断する場合、ユーザーは一時停止したプレイ・ポイントから視聴を再開することはできず、連続的に放映されているマルチキャスト・ストリームに追いつくためにはある程度の内容をスキップせざるを得ない。
【０００６】
3. 分散対話型ネットワーク・アーキテクチャ（DINA）
DINAシステムとは、該出願者のPCT出願第PCT/IB00/001857号及び001858号において説明される方法及びシステムを指す。DINAシステムにおいては、複数の分散対話型サーバーと共に複数のマルチキャスト・ビデオ・データ・ストリームによって早送り/早戻し、送りジャンプ/戻しジャンプ、スローモーションなどの対話機能を提供することができる。この種のDINAシステムにおいてはクライアントに対話機能を与えることができるが、各ユーザーの要求に対するスタートアップ時間を短縮しようとするとネットワーク負荷が増大するかも知れない。これは、マルチキャスト・データ・ストリームのストリーム間隔によって決まる。一般的に言って、データ・ストリームの数、従ってネットワーク負荷は、ストリーム間隔の減少に応じて増大する。
【０００７】
NVOD及びQNOVシステムにおいては、内容を見たいユーザーは、多くの時差的ストリームのうちの1つにアクセスして、このストリームを共有する他の全てのユーザーと同時にこの内容を見る。この仕組みは単純で効率的であるが、2つの支障、すなわちスタートアップ待ち時間の大きいこと及びユーザー・フレキシビリティの低いこと、がある。
【０００８】
第一の支障に関しては、ユーザーは、要求が応じられるまでに1ストリーム間隔Tも待たなければならず、待ち時間はストリーム間隔に応じてかなりの分になるかも知れず、数時間になる可能性さえある。ストリーム間隔は、例えば数秒など非常に短くすることができるが、これは、同量の内容を供給するためにシステムが多数のストリームを送らなければならないことも意味する。必要なストリームの数は単純にR/Tであり、ここで、Rは内容の長さであり、Tはストリーム間隔である。従ってスタートアップ待ち時間が小さければ、伝送帯域及びコストはずっと大きくなる。DINAシステムもまた同様の支障に直面する可能性がある。
【０００９】
第二の支障に関しては、他のビューアーがないので、マルチキャスト・ストリームを見るユーザーは自由にストリームを中断することができない。従って、NVOD及びQVODシステムは、一時停止、再開、巻き戻し、スローモーション、早送りなどVCRのような対話性を可能にすることができない。これらのシステムは、また、新方式の対話型媒体が導入されることを阻んでいる。近年、NVOD及びQVODシステムを通じてVCR様の対話性を与えるために一般的に使われる1つの方法は、放送されている全ての入手可能な内容をキャッシュするためにセットトップ・ボックス（STB）に記憶装置を加えることである。この種のシステムは、システム・コストが高くなり、記憶装置の故障及び管理という動作上の問題を伴う。
【００１０】
先行技術は、VODシステムにおける既存の問題に解決法を与えていないことが分かる。特に、現在のVODシステムは、望まれる対話機能を短いスタートアップ時間でクライアント/ユーザーに与え、同時にネットワーク負荷を最小限に抑えることはできないかも知れない。従って、先行技術に関して示される問題のうち少なくとも一部を解決することが本発明の目的である。少なくとも、人々に有益な選択肢を与えることが本発明の目的である。
［発明の要約］
従って、本発明は、広義には、クライアントへのデータの送信を開始するためにある待ち時間を有する、ネットワーク上で少なくとも1台のクライアントにデータを送信するための方法及びこれに対応するシステムを提供する。本発明の方法は、下記のステップを含む：
−クライアントが受信するために少なくともデータの先頭部分を含む待ち時間（レイテンシ）防止データ・ストリームを少なくとも1つ生成するステップ、及び
−待ち時間防止データ・ストリームの少なくとも一部を受信した後にクライアントが併合するために少なくとも前記データの残り部分を含む少なくとも1つの対話型データ・ストリームを生成するステップ。
【００１１】
待ち時間防止データ・ストリーム及び対話型データ・ストリームは、それぞれ少なくとも1つの待ち時間防止信号ジェネレータ及び少なくとも1つの対話型信号ジェネレータによって生成することができる。
【００１２】
各々がネットワーク上で送信するために時間Tを必要とするK個のデータ・セグメントにデータを細分化するステップを含む、ネットワーク上で少なくとも1台のクライアントにデータを送信するための方法及びこれに対応するシステムを提供することが、本発明の別の態様である。この方法及びシステムにおいて、K個のデータ・セグメントの各々は、頭部分及び末尾部分を含み、クライアントが受信するときK個のデータ・セグメントの併合を容易にするために、頭部分はすぐ前のセグメントの末尾部分のデータの一部を含む。
【００１３】
K個のデータ・セグメントは信号ジェネレータによって生成することができる。
【００１４】
クライアントへのデータの送信を開始するためにある待ち時間を有する、ネットワーク上で少なくとも1台のクライアントにデータを送信するための方法及びこれに対応するシステムを提供することが、本発明のさらに別の態様である。この方法は、下記のステップを含む：
クライアントが受信するために少なくともデータの先頭部分を含む少なくとも1つの待ち時間防止データ・ストリームを生成するステップ、
クライアントにおいて先頭部分を先読みデータとして先読みするステップ、及び
クライアントが先頭部分に併合するために少なくとも前記データの残り部分を含む少なくとも1つの対話型データ・ストリームを生成するステップ。
【００１５】
本発明は、また、複数の待ち時間防止データ・ストリームを生成するステップを含む、ネットワーク上で少なくとも1台のクライアントにデータを送信するための方法及びこれに対応するシステムも提供する。この方法及びシステムにおいて、待ち時間防止データ・ストリームは、以下のものを含む：
先頭データ・ストリーム内で連続的に反復される前記データの先頭部分の少なくとも1つの先頭セグメントを含む先頭データ・ストリーム、及び
複数の終了データ・ストリームであり、終了データ・ストリームの各々が、
・ 少なくとも前記データの先頭部分の残り部分を含み、
・ 前記終了データ・ストリーム内で連続的に反復され、各連続する終了データ・ストリームが待ち時間防止間隔の時差を持つ、
終了データ・ストリーム。
【００１６】
本発明は、さらに、ネットワーク上で少なくとも1台のクライアントにデータを送信するための方法及びこれに対応するシステムを提供する。この方法は、1からMまでM個の待ち時間防止データ・ストリームを生成するステップを含み、この方法において、m番目の待ち時間防止データ・ストリームは、F_m個のセグメントを有し、F_mは、ｍ番目のフィボナッチ数であり、かつ、この方法において、前記F_m個のセグメントは、m番目の待ち時間防止データ・ストリーム内で連続的に反復される。
【００１７】
各々がネットワーク上で送信するために時間Tを必要とするK個のセグメントにデータが細分化される、ネットワーク上で少なくとも1台のクライアントにデータを送信するための方法及びこれに対応するシステムを提供することが、本発明のさらに別の態様である。この方法は、1からKまでの待ち時間防止データ・セグメントを含むM個の待ち時間防止データ・ストリームを生成するステップを含み、この方法において、待ち時間防止データ・セグメントは、k番目の先頭セグメントが待ち時間防止データ・ストリーム内で待ち時間防止間隔≦kTで反復されるようにM個の待ち時間防止データ・ストリームにおいて配分される。
【００１８】
本発明は、さらに、ネットワーク上で少なくとも1台のクライアントに送信されるデータを受信するための方法を提供する。送信されるデータは、各々ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化される。データは、2つのバッチのデータ・ストリームに分割され、待ち時間防止データ・ストリームはM個の待ち時間防止データ・ストリームを含み、対話型データ・ストリームはN個の対話型データ・ストリームを含む。データを受信するための方法は、下記のステップを含む：
データ要求を発するステップ：要求はクライアントのプロセッサによって発することができる。
【００１９】
クライアントをM個の待ち時間防止データ・ストリームに接続して、M個の待ち時間防止データ・ストリームのデータを受信するステップ：クライアントまたは受信機はコネクタによって待ち時間防止データ・ストリームに接続できる。
【００２０】
本発明は、また、ネットワーク上で少なくとも1台のクライアントに送信されるデータを受信するための方法及びこれに対応するシステムを提供する。この方法及びシステムにおいて、前記データは先頭部分及び残り部分を含み、残り部分は少なくとも1つの対話型データ・ストリームによって送信される。この方法は、下記のステップを含む：
クライアントのバッファに含まれる先読みデータとしてクライアントにおいて先頭部分を先読みするステップ、及び
先読みデータをプロセッサによって残り部分と併合するステップ。
【００２１】
その代わりに、待ち時間防止データ・ストリームを連続的に生成しないで、これをクライアントの要求に応じて生成することができる。
【００２２】
上記の方法及びシステムのさらなる実施態様及び選択肢は、以下の節で説明するので、説明を読めば当業者には明らかであろう。
［望ましい実施態様の詳細な説明］
本発明について、以下の節において図面を参照しながら例として説明する。表1は、当業者にとってはその一部は容易に理解できるかもしれないが、略語または記号を簡単に参照できるように、明細書に使用される略語または記号とその意味を示している。
【００２３】
【表１】

【００２４】
以下の説明はビデオとして送られるデータに関して述べているが、他の形式のデータ例えばオーディオ・プログラムまたはソフトウェア・プログラムまたはそれらの組み合わせも、本発明のシステムにおいて送ることができるものと解釈される。例えば、本発明は、要求に応じてネットワーク上で多数のクライアントにオペレーティング・システム・ソフトウェアを配備するために使用することができる。さらに、本発明は、反復的内容の大量のデータを処理するデータ伝送システム例えば多くの複雑なしかし反復的な3Dオブジェクトを処理するコンピュータのビデオ・システム・バスにおいて、利用することができる。さらに、本発明は、デジタル・データの送信のみに限定されない。
【００２５】
本発明においては、背景の節において説明した通りVODシステムの既存の問題を克服するためにマルチストリーム・マルチキャスディング技法が使用される。この技法を使用することによって、ユーザーは、STBに記憶装置を追加して毎日ユーザーが見ることができる全ての内容をキャッシュする必要なくVCRのような対話性が与えられる。
【００２６】
図3は、システム構成を示している。マルチキャスト・ストリームはマルチキャスト・サーバー・ユニットから生成される。ストリームは物理媒体に多重送信され、配信ネットワーク上でエンド・ユーザーに配信される。各ユーザーエンドには、DDVRなどセットトップ・ボックス（STB）があり、これが処理のために多数のストリームを選択する。ストリームで搬送される内容を希望の方式で（図4−10において後に示される）配列することによって、スタートアップ待ち時間を最小限に抑えながらユーザーに対話機能を与えることができる。DDVRは、十分な帯域、バッファ及びマルチストリームを処理するための処理機能を持たなければならない。
【００２７】
IVODと呼ぶことができる本発明のデータ伝送システムは、NVODシステムと似ているように見えるかも知れない。しかし、IVODシステムとNVODシステムは以下の点で異なる：
1. 内容を時差的ストリームに配する方法
2. 時差的ストリームを生成する方法
3. DDVRが内容を復元するために多数の時差的ストリームを選択し処理する方法
データ・ストリームを説明する際に上に及び本明細書全体において使用される「時差的」という言葉は、データ・ストリームの各々の送信が異なる時点で開始する状況を意味する。従って、2つの隣接するデータ・ストリームの2つの「フレーム」（ここで、「フレーム」と言う用語は各データ・ストリームの反復単位を表す）はある時間間隔によって分離される。
【００２８】
広義には、データ伝送方法及びシステムは、データ・ストリームの2つのグループ、グループＩ及びIIの提供として説明することができる。グループＩデータ・ストリーム、すなわち待ち時間防止データ・ストリームは、要求されるデータの送信をスタートアップするための待ち時間を減少するために役立つ。グループＩデータ・ストリームは、少なくとも1つの待ち時間防止信号ジェネレータによって生成することができる。グループIIデータ・ストリーム、すなわち対話型データ・ストリームは、ユーザーに希望の対話機能を与えるのに役立つ。グループIIデータ・ストリームは、少なくとも1つの対話型信号ジェネレータによって生成することができる。グループIIデータ・ストリームによって与えられる対話機能については、該出願者のPCT出願第PCT/IB00/001857&1858号を参照することができ、その内容は参照により本出願に組み込まれる。対話機能の動作は本出願において本発明の一部とはみなされないので、その詳細についてはこれ以上説明しない。
【００２９】
IVODシステムの動作は、以下の例によって適切に例証することができる。これらの例の各々は有効なIVODシステムであるが、全て、さまざまなバランスのとり方を持つ細部において異なる。これらの例はIVODシステムの実用的原理を示すためだけのものであり、唯一可能なIVODの動作を説明しようとするものではない。
【００３０】
以下の例において、合計データ量Qを有する送信内容は、ネットワーク上で送信するために合計時間Rを必要とする。例えば、内容は、映画であるかも知れない。Qデータは、各々データ量Sを有するK個のセグメントに分割される。各データ・セグメントはネットワーク上で送信するために時間Tを必要とする。Q及びSは、メガバイトの単位で表されるのに対して、R及びTは時間の単位で表される。都合上、Qデータのデータ・セグメントはそれぞれ1からKまでラベルを付けられる。従って、K=R/Tである。Qデータは、先頭部分と残り部分に分割することができる。ほとんどの場合、グループＩの待ち時間防止データ・ストリームは、先頭部分のみを含む。グループIIの対話型データ・ストリームは、残り部分またはQデータのセット全体を含むことができ、これは、システム・マネージャが決定すべき設計上の選択肢となりうる。
【００３１】
個々のデータ・セグメントが相互に異なる量のデータを含んでいても、全てのセグメントが送信のために時間Tを必要とすることを条件として、システムは機能することに留意しなければならない。これは、個々のデータ・セグメントの伝送速度を制御することによって実現することができる。ただし、個々のデータ・セグメントは、エンジニアリングの都合上同じデータ量Sを持つことが望ましいかも知れない。一方、各データ・セグメントが同じデータ量Sを持つが伝送時間が異なるシステムを実現するのは、もっと難しいかも知れない。
【００３２】
以下の説明は1組のデータ例えば映画の送信に関するものであるが、この方法及びシステムは、例えば利用可能な帯域に応じて複数組のデータを送信するように改作できることが、当業者には明らかなはずである。
【００３３】
A. 二重ストリーミングIVODシステム（構成1）
一番単純なIVODシステムは、二重ストリーミング動作をその特徴とする。二重ストリーミングとは、各ユーザーが任意の時点でマルチキャスト・データ・ストリームのうち最大2つにアクセスすることを意味する。ほとんどの場合、ユーザーは、1つのデータ・ストリームにしかアクセスできない。
【００３４】
セグメントは、図4に示される通り時差的ストリームに配される。グループＩ待ち時間防止データ・ストリームの場合、各フレームにJ個のセグメントがある。Tは待ち時間防止時間間隔であり、IVODシステムのスタートアップ待ち時間の上限でもある。待ち時間防止時間間隔は、T以外の任意の希望の値に設定することができるが、各待ち時間防止データ・ストリームは、待ち時間防止時間間隔Tの時差を持つことが望ましい。
【００３５】
この特定の例において、Jは16に等しく、Tは30秒である。従って、グループＩデータ・ストリームの各々のフレームは、JTすなわち8分後反復する。グループＩには合計でM個のストリームがある。
【００３６】
グループIIの対話型データ・ストリームの場合、N個の対話型データ・ストリームがあり、その各々が対話型時間間隔の時差を持つ。対話型時間間隔も、任意の希望の値に設定することができるが、対話型時間間隔はエンジニアリングの都合上JT（すなわち、この例においては8分）であることが望ましい。内容の長さをR（例えば、Rは120分に等しい）とすると、グループIIには少なくとも合計でR/JT＝15のストリームがなければならない。Nはこの値より大きくてもよいが、そうすると不必要なネットワーク負荷を生じることになるだろう。
【００３７】
ユーザーが時刻t_iに内容を見始める場合、ユーザーエンドのDDVRは、アクセスのためにグループＩから1つのストリーム（ストリームI_i）及びグループIIから1つのストリーム（ストリームII_j）を選択する。クライアントがストリームIi及びまたはII_jに接続されると、データ・ストリームはDDVRすなわちクライアントによって処理されて、セグメントはセグメント通し番号に従ってバッファに記憶される。ストリーム間隔TのグループＩ時差的ストリームの効用は、スタートアップ待ち時間を最小限に抑えてTに等しくする。
【００３８】
その代わりに、ユーザーまたはクライアントはストリームI_iだけにアクセスして、ストリームII_jにアクセスする前にクライアントが先頭部分の全てのデータを受信するのを待つことができる。DDVRがグループＩストリームをラッチし終わった後、DDVRはすぐに併合のために適切なグループIIストリームを探す。この特定のケースにおいては、各グループIIデータ・ストリームは、Qデータの残り部分のみを含むことが望ましいかも知れない。
【００３９】
データ・ストリームを併合する方法は、DINAテクノロジーにおいて示されている。併合後、グループＩストリームはもはや必要ないかも知れず、DDVRはその後の視聴のためにストリームII_jのみに依存すればよい。これは、ネットワーク負荷を最小限に抑えるためだけの最適化された方法かも知れない。
【００４０】
システムが始動したら、ユーザーは、一時停止及び再開、巻き戻し及びスローモーション・プレイバックを含めてその後の対話型要求を開始できることに留意しなければならない。ただし、送りジャンプ及び戻しジャンプは、（任意の特定の時点に）グループＩまたはグループIIのストリームのいずれか1つにジャンプすることに限定されるかも知れない。この問題は、システムのパラメータを微調整することによって解決することができる。例えば、グループＩデータ・ストリームは、著作権告知など比較的少数の人しか見たがらない内容を含むように設計することができる。
【００４１】
このタイプのIVODシステムにおけるストリームの合計数は、M + R/JTである。最適なシステム構成は、M=N=J=(R/T)^1/2と算定され、ストリームの最適合計数は2(R/T)^1/2によって与えられる。
【００４２】
B. 二重ストリーミングIVODシステム（構成2）
IVODシステムの第二の例も二重ストリーミング動作をその特徴とする。この場合にも、内容は、規則的な長さTのK個のセグメントに分割され、セグメントにはそれぞれ1からKまでのラベルが付けられる。セグメントは図5に示される通りのパターンで時差的ストリームに配される。
【００４３】
この構成においても、2つのグループの時差的ストリームがある。グループＩ待ち時間防止データ・ストリームの場合、各フレームにJ個のセグメントがあり、各ストリームにおいてフレームが反復される。この例においても、Jは16に等しい値が選択され、Tは30秒である。この構成は、グループＩのデータ・ストリームのうち1つのストリームすなわちストリームＩ1が全てのタイムスロットにおいて反復されるセグメント1のみを含むことを特徴とする。ストリームＩ2からＩ9までは、セグメント 2から17までを含む。言い換えると、セグメント1は、先頭部分の先頭セグメントを含む先頭データ・ストリームとして見ることができる。セグメント2から9までは、J個のセグメントの先頭部分の残りを含む複数の終了データ・ストリームと見なすことができる。グループＩストリーム間隔として任意の希望の値を選択することができるが、この場合にも構成1と同じ理由でTに設定されることが望ましい。ストリームＩ2からＩ9までは、JT（すなわち、この例においては8分）後反復する。
【００４４】
この特定の例においては、先頭データ・ストリームと終了データ・ストリームを円滑に併合するためにグループＩに合計で少なくともM=J/2 + 1のストリームがなければならない。Mはこの値より小さくても良いが、その場合、ユーザーは「ドロッピング・フレーム」現象を経験する可能性がある。Mはこの値より大きくても良いが、これは不要なネットワーク負荷を生じる可能性がある。これは、システム管理者の決定に委ねられるべき設計上の選択の問題であろう。
【００４５】
図5に示される先頭セグメントは、1つの先頭セグメントしか含まないが、先頭データ・ストリームは複数の先頭セグメント、例えばセグメント1から4までを含むことができると解釈すべきである。この場合、この構成2のグループＩ待ち時間防止データ・ストリームの上記の条件はTが4倍になるものとして見ることができるが、この変化はグループIIの対話型データ・ストリームには影響を与えない。このような場合、ユーザーにとってはスタートアップ待ち時間が長くなる可能性がある。他方、先頭データ・ストリームと終了データ・ストリームを円滑に併合するためにMが実質的に小さくなりM=J/8 + 1とすることができる。これは前の例より望ましくないが、この場合にも、これはシステム管理者が決定すべき設計上の選択の問題であろう。
【００４６】
グループIIストリームの場合、ストリームの配列及びセットアップは前の例と同じであり、同じ設定及び変形をこれにも応用することができる。
【００４７】
ユーザーが時刻t_iに内容を見始める場合、ユーザーエンドのDDVRは直ちにストリームＩ1にアクセスする。先頭セグメントは時間周期Tごとに反復されるのでスタートアップ待ち時間はTに制限されるはずである。先頭セグメントの全てのデータを受信した後、DDVRはグループＩ終了データ・ストリーム（この場合には、ストリームＩ2からＩ9）のうち1つにもアクセスする。例証のためにストリームＩiを選択する。代替案として、DDVRは、その能力があれば、先頭データ・ストリームと終了データ・ストリームの1つに同時にアクセスすることができる。後者の場合、両方のストリームはDDVRによって処理され、セグメントはセグメント通し番号に従ってバッファで記憶される。
【００４８】
DDVRは、またグループIIストリームの1つ（この場合にはストリームII2）にもアクセスする。DDVRがグループIIストリームにアクセスする時点は選択の問題であるが、下記のような可能性がある：
1. 先頭データ・ストリームストリームＩ₁にアクセスした直後
2. 終了データ・ストリームの1つにアクセスした直後
3. グループＩデータ・ストリームに含まれる先頭部分の全てのデータがDDVRによって受信された後
一般的に言って、DDVRは、遅くともグループＩストリームの全てのデータがクライアントによって受信またはプレイされる直前までにグループIIストリームの1つにアクセスしなければならない。
【００４９】
グループＩデータ・ストリームの全てのデータがバッファに入れられ受信された後、DDVRはグループIIストリームの1つに併合する。併合の技法についてはDINAテクノロジーにおいて説明する。併合後、グループＩストリーム（すなわち、ストリームＩi）はもはや必要ないかも知れず、DDVRは帯域を節約するためにその後の視聴をグループIIストリームに依存することができる。DINAテクノロジーにおいて示される通り任意の時点で受信する許容可能な対話型要求に応じることができる。
【００５０】
このIVODシステムのストリームの合計数は（J/2 + 1）+Nである。NはR/JTに等しいことが望ましいので、最適構成はJ=(2K)^1/2＝(2R/T)^1/2によって与えられ、システムのデータ・ストリームの最適合計数は、(2K)^1/2 + 1=(2R/T)^1/2 + 1に等しい。
【００５１】
C. 二重ストリーミングIVODシステム（構成3）
IVODシステムの第三の例も、二重ストリーミング動作をその特徴とし、セグメントはフィボナッチ数に基づくサイズの階層周期フレーム構造に配列される。この場合にも、内容は規則的長さTのK個のセグメントに分割され、セグメントにはそれぞれ1からNまでラベルが付けられる。セグメントは図6に示されるパターンで時差的ストリームに配される。また、2つのグループの時差的ストリームがある。
【００５２】
この構成においては、グループＩデータ・ストリームは、J個のセグメントを有する先頭部分のデータを含む。このJは構成1及び2において使用されるのと多少異なることに留意すること。1からMまでのラベルが付けられるM個のグループＩデータ・ストリームがある。グループＩストリームの各々ストリームI_m（ここで、mはストリーム番号を表す整数である）について、フレーム周期がF_m（ここで、F_mはｍ番目のフィボナッチ数である）で示される。最初の多少のフィボナッチ数が表2に示されている。フィボナッチ数は、F_y＝F_y-1 + F_y-2という特性を持っている。ここでyは3から始まる整数である。グループＩストリーム間隔はこの場合も構成1及び2と同じくTに設定されることが望ましい。この例においては12のグループＩストリームがある。グループIIストリームに関しては、ストリームの配列及びセットアップは以前の例と同様であるが、例証のためにグループIIはセグメント81から始まっている。
【００５３】
【表２】

【００５４】
多くの異なる変形が可能であるが、動作の原理は以下の説明によって一番よく説明することができる。ユーザーが時刻tに内容を見始める場合、ユーザーエンドのDDVRは、直ちに2つのグループＩデータ・ストリームストリームＩ1及びＩ2にアクセスする。ストリームＩ1からのセグメント1及びストリームＩ2からのセグメント2または3は、両方ともバッファに記憶される。これで、2つのセグメントがバッファの中にある。ストリームＩ2は、2のフレーム・サイズを有し、ストリームＩ2をDINAテクノロジーにおいて説明するとおりの方法を使用して円滑に併合することができる。このようにして、スタートアップ待ち時間はTに制限されるはずである。セグメント1が受信された後、DDVRはストリームＩ2及びＩ3にアクセスする。ストリームＩ2には2つのセグメントしかないので、セグメント3はセグメント2が受信されている間バッファに入れられるか、またはセグメント2の完了後直ちにストリームＩ2上でセグメント3を入手できる。セグメント2及び3の両方が受信された後、DDVRはストリーム3及び4にアクセスし、前と同様処理が続く。両方のストリームはDDVRによって処理されて、余分なセグメントはセグメント通し番号に従ってバッファに記憶される。
【００５５】
上の説明においては、DDVRは、待ち時間がTに制限されるように、映画をスタートアップするために1番目及び2番目のデータ・ストリームに接続されると仮定している。ただし、ユーザーが望む場合には、最初にm番目及び（ｍ+1）番目のデータ・ストリームにアクセスすることができる（この場合mは任意の1より大きい数）。ユーザーは、この場合でも内容を見ることができるが、待ち時間が長くなるかも知れない。これは、例えば映画の最初の数分間をスキップしたい一部のユーザーには好まれるかも知れない。
【００５６】
さらに、構成2と同様、図６に示されるデータ・セグメントの各々は、送信されるK個のセグメントのうち2つ以上を含むことができる。例えば、図６に示されるデータ・ブロックの各々は、実際には5つのデータ・セグメントを含むことができる。この場合、この構成3のグループＩ待ち時間防止データ・ストリームの上記の条件は、Tが5倍の長さであるとして見ることができるが、この変化は、グループIIの対話型データ・ストリームには影響を及ぼさない。このような場合、ユーザーにとってスタートアップ待ち時間が長くなるかも知れない。
【００５７】
対案として、ユーザーがもっと長いスタートアップ待ち時間及びデータのトリミングを許容できる場合、mは1から始まる必要はない。例えば、システム管理者は、図6においてグループＩの最初の4つのデータ・ストリームを取り除くことができる。ソフトウェア送信の場合、この配列は許容されない。そうでなければ、ユーザーは完全なソフトウェアを受信できないかも知れない。しかし、ビデオ送信の場合、著作権所有者がビデオのトリミングを許容することを条件としてこれが許容される場合がある。
【００５８】
フィボナッチ数F_mに従ってストリームのフレーム周期を構成することによって、ストリームＩ_m-1が受信された後には、DDVRは少なくともF_m=F_m-1 + F_m-2のタイム・スロットをバッファに記憶している。ストリームＩ_mのフレーム・サイズは丁度F_mなので、DINAテクノロジーにおいて説明する通り併合法を使用して、ストリームＩ_m-1をストリームＩ_mに円滑に併合することができる。
【００５９】
二重ストリーミング配列なので、ｍ個のセグメントが受信された後には、丁度m個のセグメントがバッファに記憶されていることになる。DDVRは、最低限でも帯域を節約するために、バッファに記憶されたセグメントの数がグループIIストリーム間隔のサイズ（この場合、8分のグループIIストリーム間隔には80のセグメントが必要）を超えたら、グループIIストリームのうち1つに併合し始めることが望ましい。併合後、グループＩストリーム（すなわち、ストリームＩi）はもはや必要ないかも知れず、DDVRはその後の視聴のためにグループIIストリームのみに依存することができる。任意の時点で受信される許容可能な対話型要求には、DINAテクノロジーにおいて説明される通りに応えることができる。
【００６０】
この構成には最適パラメータはない。帯域を節約するためには、1つのグループIIデータ・ストリームもあるべきではない。ただし、ユーザーは、どの程度のデータがDDVRにおいて受信されてバッファに記憶されるかに応じて限られた対話性しか享受できないかも知れない。特に、ユーザーは、一時停止、再開、巻き戻し、スローモーション及び戻りジャンプを行えるが、早送り及び送りジャンプ機能は実行できないかも知れない。
【００６１】
必要とされるグループＩデータ・ストリームの数Mは、グループIIデータ・ストリームの数によって決められ、グループIIデータ・ストリームの数は、各種システム・ファクタに従って手作業で決定される。スタートアップ待ち時間Tが与えられる場合、このIVODシステムにおいて必要とされるストリームの合計数は、関連するフィボナッチ数を含むテーブルから必要なフレーム・サイズを探索することによって見つけることができる。データ・ストリームの最小数は、個々のグループＩデータ・ストリームの間が円滑に併合されるために、F_M≧ 2K/NになるようなMでなければならない。Mがこの値より小さくても良いが、ユーザーは、「ドロッピング・フレーム」現象を経験する可能性がある。Mはこの値より大きくても良いが、不要なネットワーク負荷を生じる可能性がある。これは、システム管理者の決定に委ねられるべき設計上の選択の問題であろう。
【００６２】
この技法を用いて、8分のグループIIストリーム間隔で、スタートアップ待ち時間を6秒程度（平均で3秒）にすることができる。2時間の内容に必要とされるストリームの合計数はわずか26程度にすることができる。
【００６３】
グループＩストリームの代替配列が図7に示されている。ストリームのフレーム構造は、ストリーム4以降のみがフィボナッチ数列に従っていることに留意すること。
【００６４】
D. 多重ストリーミングIVODシステム（構成4）
前の3つの例は、二重ストリーミングのIVODシステムの可能ないくつかの実施例である。実際には、もっと多くの可能なIVODシステムの実施方法があり、その各々がさまざまなストリームのさまざまなセグメント配列、及びエンド・ユーザーのDDVRが同時にアクセスし処理しなければならないストリームの最高数に応じて左右される。上記の3つの例は、理解し実施するのが比較的単純であるが、ある任意の時点でアクセスされ処理されるストリームは最高で2つという制約があるので、使用されるストリームの数は最適ではない。この構成においては、最適数のストリームを持つ多重ストリーミングIVODシステムについて説明する。
【００６５】
この構成は、内容を搬送する全てのストリームが全てエンド・ユーザーDDVRによってアクセスされ処理されるという仮定で実現される。図8は、調和級数法に基づくさまざまなストリームにおける最初の30程度のセグメントの考えうる最適配列を示している。セグメントには1、2、3、….などのラベルがつけられる。最適数のストリームだけを使用してスタートアップ待ち時間を1スロット間隔に制限することを保証するための必要十分条件は、1からJまでの全てのjについてセグメント j（すなわち先頭部分の始めからj番目のセグメント）がj個またはそれ以下のタイムスロットごとに反復されるようにセグメントの配置が行われることである。例えば、スタートアップ待ち時間が1待ち時間防止間隔T以内に制限されるためには、セグメント1は1タイムスロットごとに反復されなければならない。従って、1つのストリーム全体がセグメント1だけで占められる。最初のセグメントを受信した後にすぐに2番目のセグメントが入手可能であるためには、セグメント2は1つおきのタイムスロットに反復されなければならない。同様に、セグメント3は3タイムスロットごとに反復されなければならず、セグメント jはjタイムスロットごとに反復されなければならない。j＞1の場合、セグメント jは、要求されるより頻繁に反復してもよい。すなわち、j番目のセグメントは待ち時間防止時間間隔≦jTで反復される。この構成4における「待ち時間防止時間間隔」と言う用語の定義は構成1から3までの定義とは異なる。
【００６６】
全てのストリームがDDVRによって受信され処理されることを想定しているので、セグメントが配置される正確なストリームは問題ではない。セグメントはDDVRによってバッファに記憶され、適切な順序で再配列される。図9の空白のスロットはどのようなデータでも含むことができ、また空白のままでもよい。
【００６７】
構成3の場合と同様、この構成には最適パラメータはない。帯域を節約するためには、1つのグループIIデータ・ストリームもあるべきではない。この場合、ユーザーはどの程度のデータがDDVRにおいて受信されバッファに記憶されるかに応じて限られた対話性しか享受できないかも知れない。これは望ましいことではないだろう。必要とされるグループＩデータ・ストリームの数MはグループIIデータ・ストリームの数によって決められ、グループIIデータ・ストリームの数は各種システム・ファクタに従って手作業で決定される。J個のタイムスロットを搬送するために必要なストリームの合計数Mは、
【００６８】
【数１】

【００６９】
であるように1からJまでの調和級数を加算することによって見つけることができる。これは、ほぼγ+ ln(J) に等しい。ここで、Jが大きいときγはオイラー定数（〜0.5772…）である。JはK/Nより大きい任意の希望の数に設定することができるが、設計の都合上、J = K/N（すなわち対話型時間間隔におけるデータ・セグメントの数に等しい）であることが望ましい。これが、スタートアップ待ち時間を1スロット間隔以内に制限するために必要とされるストリームの最適数である。
【００７０】
さらに、構成2及び3と同様、図8に示されるデータ・セグメントの各々は、送信されるデータのK個のセグメントのうち複数を含むことができる。例えば、図8に示されるデータ・ブロックの各々は、実際には10データ・セグメントを含むことができる。この場合、この構成4のグループＩ待ち時間防止データ・ストリームの上記の条件は、Tが10倍の長さであるとして見ることができるが、その変化はグループII対話型データ・ストリームに影響を及ぼさないかも知れない。このような場合、ユーザーにとってスタートアップ待ち時間が長くなるかも知れない。
【００７１】
この場合にも、対案として、jは1から始める必要はなく1より大きい数から始めることができる。ただし、ユーザーがより長いスタートアップ待ち時間を受容できることをその条件とする。例えば、システム管理者は、図8において最初の3つのグループＩデータ・ストリームを取り除くことができる。ソフトウェア送信の場合、この配列は許容されないかも知れない。そうでなければ、ユーザーは完全なソフトウェアを受信できない場合がある。しかし、ビデオ送信の場合、著作権所有者がビデオのトリミングを許容することを条件としてこれが許容される場合がある。
【００７２】
その代わりに、jは1より大きい任意の数例えば5から始めることができる。ただし、これは、単に図8に示される最初のデータ・セグメントがTの代わりに5Tの待ち時間防止時間間隔で反復され、その後のj番目のデータ・セグメントが待ち時間防止間隔（5+j）Tで反復されることを意味するだけである。この変化は当業者には自明のはずである。
【００７３】
この最適多重ストリーミング条件に基づきIVODシステムを構成するために、ストリームはこの場合にも2つのグループ、グループＩ及びグループIIに分割される。グループＩストリームのセグメント配列は図8に示されるとおりである。グループIIストリームのセグメント配列は、図4から6のいずれか1つに示される配列と同じである。ユーザーが視聴要求を発すると、グループＩストリームの全てがDDVRによって受信され処理されなければならない。さらに、適切なグループIIストリームもアクセスされ処理される。これによってグループＩストリーム（ここに最初のm個のセグメントが配される）を単一のグループIIストリームに円滑に併合することができる。対案として、グループＩストリームに含まれる先頭部分の全てのデータがクライアントDDVRによって受信されるまで、グループIIストリームへのアクセスを待つことができる。
【００７４】
1グループIIストリーム間隔（この場合にも意識的にJTに設定される）後、全てのグループＩストリームはもはや必要ないかも知れず、ユーザーが連続して視聴するために単一のグループIIストリームだけが必要とされる。これまでと同様、複数のグループIIストリームを使用することによって、システムがひとたびスタートしたら、ユーザーは一時停止及び再開、巻き戻し及びスローモーション・プレイバックを含めて許容される対話型要求をどれでも発することができる。
【００７５】
構成3と同様、前に説明した通り、完全にグループＩストリームに基づくIVODシステムを構成することができる。こうすることによって、スタートアップ待ち時間を最小限に抑えて、ストリームの数を減らすことができる。ただし、この種のシステムのユーザーは、構成3において説明した通り、限られた対話性に制約されるかも知れない。さらに、DDVRのバッファ・サイズは内容全体の大きさがなければならず、DDVRの処理能力は現在構成に関してさらに要求の大きいものとなる。どのシステムを配備するかに関する決定はサービス・プロバイダの選択に委ねられるべきである。
【００７６】
さらに、この多重ストリーミング配列は、必要とされるストリームの数をさらに減らすために構成4においてフィボナッチ・ストリーム・シーケンス（グループＩストリーム）に代わって使用することができる。条件は、DDVRが受信データをバッファに記憶し処理するための十分なバッファ及び処理力を持つことである。下の節の表3は、さまざまな構成全てにおける結果の一部を記載している。
【００７７】
対数ストリーミングとして知られる非最適多重ストリーミング配列が図9に示されている。
【００７８】
E. 混合二重-二重/多重-二重ストリーミングIVODシステム（構成5）
構成3及び4は、匹敵する数のストリームを使用する構成1及び2と比べてスタートアップ待ち時間が非常に短いIVODシステムを示している。しかし、構成1または2にも構成3または4より有利な点がある。すなわち、これらの構成は、第一のストリーム間隔中ストリームからストリームに粗ジャンプができるのに対して、構成3または4はこれができない。現実の生活において、通常、内容ソースの最初の数分間は、多くのヘッダ及び多くのユーザーがジャンプしてスキップしたいかも知れない情報を含んでいる。従って、ユーザーに少なくとも多少のジャンプ機能を提供することが望ましい。
【００７９】
構成1または2と構成3または4を組み合わせることによって、外部ユニキャスト・ストリームの助けがなくてもある程度のジャンプ機能を有するIVODシステムを構成することができる。このIVODシステムは、3つのグループ、すなわちグループＩ(1)及びグループＩ(2)の時差的ストリームを含む。グループＩ(1)データ・ストリームは、C個のセグメントを有するデータの配信を担当する合計でA個のデータ・ストリームを有する。同様に、グループＩ(2)データ・ストリームは、D個のセグメントを有するデータの配信を担当する合計でB個のデータ・ストリームを有し、B個のデータ・ストリームの各々は粗ジャンプ間隔の時差を持つ。粗ジャンプ間隔にはE個のデータ・セグメントがある。
【００８０】
もっと具体的な例を示すために、セグメント・サイズTを6秒と仮定してみる。グループＩ(1)が構成3に示される通り最初の7個のフィボナッチ・ストリームを含むとする。グループＩ(2)は構成1に示される通りセグメント11から90までを含む8つのグループＩストリームを含み、時差ストリーム間隔は10セグメントとする。冗長と思われるかも知れないが、グループＩ(2)は1から90までのデータ・セグメントを含むことができることに留意すること。従って、グループＩ(2)ストリームのフレーム周期は80セグメントすなわち8分であり、これが、DDVRがグループＩデータ・ストリームに接続されているときにユーザーが粗ジャンプ対話を実行できるようにする粗ジャンプ・フレーム周期である。構成5のグループIIストリームは、他の構成のグループIIストリームと同じである。この特定の例においては、グループIIストリームの各々はセグメント1から始まり、内容全体の終了まで完了する。ストリーム及びセグメントの配列は図10に示される通りである。
【００８１】
このような階層的なストリーム及びセグメントの配列によって、ユーザーは1セグメントのスタートアップ待ち時間（この例においては6秒）でいつでもスタートできることが分かる。さらに、ユーザーは、DDVRがグループＩストリームに接続される時間であるスタートアップ時間内のいつでも粗ジャンプできる。スタートアップ時間は、これまでの構成と同様、最初のグループIIストリーム間隔（すなわち、0分ポイントから9分ポイントまで）以内の時間に定義されることが望ましい。各粗ジャンプは相互に1分離れており、これは粗ジャンプ・フレーム周期によって決定される。このようにして、ユーザーはこの配列を使ってヘッダをスキップすることができる。図10に示される特定の例において2時間の内容を保持するために必要なストリームの合計数は30である。
【００８２】
図10はグループＩデータ・ストリームにおける構成3と1の組み合わせしか示していないが、下記の組み合わせも可能であることが当業者には明らかなはずである：
a. 4と1の組み合わせ
b. 3と2の組み合わせ
c. 4と2の組み合わせ
必要とされるグループＩ(1)データ・ストリームの数Aは、構成3及び4においてEをK/Nとすることによって決定することができる。すなわち、グループＩ(1)において構成3が使用される場合、グループＩ(1)においてF_A≧2EとなるようにA個のデータ・ストリームがなければならない。構成4が使用される場合には、
【００８３】
【数２】

【００８４】
である。構成4の場合と同様、グループＩ(1)において送信されるデータ・セグメントの合計数CはEに等しいことが望ましい。必要とされるデータ・ストリームの数に関して構成3及び4の場合と同じ考え方がグループＩ(1)にも応用できる。
【００８５】
どの組み合わせを配備するかに関する決定は、この場合にもサービス・プロバイダの選択に委ねられるべきである。
［構成1、2及び3の代替配列］
多数のユーザー向けに構築されるVODシステムの場合、上に説明した通りの待ち時間防止データ・ストリームは、ユーザーがアクセスするために連続的にまたは少なくともゴールデンアワー中（例えば午後6−11時）システムに存在するように連続的に生成されることが望ましいかも知れない。一方、システムのユーザーが比較的少ない場合例えばユーザーが数千人の場合または配信される特定のプログラムがあまり頻繁に要求されない場合、待ち時間防止データ・ストリームがユーザーの要求に応じて生成されれば、さらに帯域が節約されるだろう。この対案は、構成1、2及び3にとって有利かもしれない。これが図14、15及び16に示されている。これらの図において、灰色のデータ・セグメントは、ユーザーからの要求に応じて「オンになる」データ・セグメントまたはデータ・ストリームを表している。
【００８６】
構成1の場合、グループＩ待ち時間防止データ・ストリームの各々は、やはり待ち時間防止ストリーム間隔Tの時差を持つ。ただし、上に説明した通り、必ずしもグループＩ待ち時間防止データ・ストリームの全てがいつも存在するわけではないまたは「オンになる」わけではない。待ち時間防止データ・ストリームは、ユーザーからの要求に応じて生成され、要求はT内に「一括処理」される。すなわち、ユーザーがある待ち時間防止ストリーム間隔内にデータ要求を発する場合、待ち時間防止データ・ストリームはすぐ次の待ち時間防止ストリーム間隔に生成される。例として図14を参照して、ユーザーが2T、3T及び16Tに等しい時点でデータを要求するとしよう。ここでは、これは、ユーザーがそれぞれ1Tから2Tまで、2Tから3Tまで及び15Tから16Tまでの間隔にデータを要求することを意味する。従って、この例においては、システムのデータ・ストリームのスナップショットにおいてストリーム2、3及び16のみが生成されるまたは「オンになり」、ストリーム1及びストリーム4−15は「オフになる」。図14に示される通り、その結果得られるグループＩデータ・ストリームは規則的なストリーム間隔を持たないように見えるかも知れない。
【００８７】
この概念は構成2及び3にも拡大できる。
【００８８】
従って、構成2においては、必ずしも先頭データ・ストリームの先頭データ・セグメントの全てがあるいは終了データ・ストリームの全てがいつも「オンになる」わけではない。これは、ユーザーの要求に応じて「オンになる」。一例が図15に示されている。先頭データ・セグメントの各々が対応する終了データ・ストリームに関係することが当業者には自明のはずであり、このことは通常のプログラミング技法によって目標を達成するのに役立つであろう。先頭データ・セグメントが生成されるときに対応する終了データ・ストリームも生成されなければならない。
【００８９】
同様に、構成3においては、必ずしもグループＩデータ・ストリームに配分されるF_m個のセグメントの全てがいつも「オンになる」わけではない。一例が図16に示されている。この場合にも、グループのデータ・セグメント間の関係は当業者にとって自明のはずであり、このことは、通常のプログラミング方法によって目標を達成するのに役立つだろう。クライアントが要求を発するとき妥当な時点で対応するFm個のセグメントの全てが生成されなければならない。特に、前のF_m個のセグメントの全てのデータがクライアントによって受信される前に、その後のF_(m+1)個のセグメントが生成されなければならない。
【００９０】
さらに、DDVRがひとたびグループIIデータ・ストリームと併合すると、帯域使用を最小限に抑えるために待ち時間防止データ・ストリームを終結することができる。
【００９１】
構成4の基本的要件の1つはユーザーをグループＩデータ・ストリームの全てに接続できることなので、この「オン・デマンド」法は、構成4には応用できるようには思えない。
【００９２】
この対案は元々の構成に比べてさらにある程度帯域を節約するように見えるかも知れないが、いくつかの理由であまり好ましくない可能性がある。第一に、サーバー側の仕事負荷及び処理必要量を増大し、プログラミング及び実現を複雑にする。第二に、設計の段階で必要な帯域の割り当てに注意しないとその結果システムの過負荷を引き起こすかも知れない。第三に、この代替方法は、実際にはユーザーからの要求の数が大きい場合元々の構成になる。
［個々のデータ・セグメントの付加的特徴］
遷移中データの実質的損失を生じることなくストリームの切替えを容易にするために、各データ・セグメントの始まり（ヘッド部と呼ぶことができる）は、すぐ前のセグメントの末尾部分の複製データを含むことができる。複製部分において搬送されるデータの量はT’（ストリームのデータ伝送速度に対して標準化される）とすることができる。ここでT’はストリームの切替え中に生じる遅延である。一般に、T’は10−20ミリ秒程度とすることができる。
［IVODシステム要件］
下記の通りいくつかのシステム要件がある：
a. サーバーは、構成1から5までのいずれか1つにおいて示されるパターンまたは考案されるパターンの適切なマルチストリームを生成する必要がある。
【００９３】
b. 配信ネットワークは、必要な全てのストリームをエンド・ユーザーDDVRに搬送するために十分な容量を持たなければならない。
【００９４】
c. エンド・ユーザーDDVRは、マルチストリームを処理するために十分な帯域、バッファ及び処理能力を持たなければならない。DDVRは、また、マルチストリームからの少なくとも1グループIIストリーム間隔のデータをバッファに記憶するために十分な記憶領域を持たなければならない。
【００９５】
これらのファクタは、サービス・プロバイダがどの構成を配備すべきかを決定する際に影響を与えるかも知れない。
［ディスクレスDVRの概念］
一般的に言って、DDVR受信機は内容要求を発するためのプロセッサ、及びグループＩ及びグループIIデータ・ストリームを接続するためのコネクタを有する。
【００９６】
構成1及び2の場合、DDVRは、受信したグループＩデータ・ストリームを一時記憶するためにバッファを含む必要があるかも知れない。構成3及び4の場合、DDVRは、グループＩデータ・ストリームから受信したデータを一時記憶するためにバッファを含まなければならない。この場合、プロセッサは、適切な順番でデータを配するためにデータの処理も担当する。
【００９７】
多重ストリーミングの概念の場合、ユーザーエンドの受信装置である受信機は、ハードディスク記憶装置を持つ必要がないかも知れない。STBすなわちクライアント/受信機に必要とされる唯一のメモリまたはバッファは、1ストリーム間隔分のデータを一時記憶するためのRAM（ランダムアクセス・メモリ）であろう。ストリーム間隔を8分と仮定すると、1Mb/s MPEG-4ストリームの場合おおよそ60MBのRAMを必要とすることになる。これは、STBに大容量のハードディスク記憶装置（時には60GBにもなる）を必要とする多くのVOD技法と対照的である。従って、このIVODシステムは、ユーザーにとってディスクレスDVRのように見える。ただし、システム・プロバイダは、ハードディスクまたはその他の不揮発性媒体の形でユーザーに付加的記憶領域を提供するか、データをバッファに記憶し受信するために必要なその他の設備を使用することができる。
【００９８】
さらに、DDVRにはいくつかの選択肢がありうることに留意しなければならない。
【００９９】
第一に、DDVRは、データの伝送速度より遅い速度で受信データを放映するように構成することができる。伝送速度は、各データ・セグメントが同じ量のデータを含むという条件の下でS/Tで表すことができる。このような場合、DDVRは未受信データを入れるためにより大きなバッファ・サイズを持つ必要があるかも知れない。
【０１００】
第二に、DDVRは、グループＩデータ・ストリームの少なくとも一部すなわち送信されるデータの先頭部分を一定期間ローカル・バッファに入れるまたは先読みするように構成することができる。この種のデータは「先読みデータ」と呼ぶことができる。希望する場合には、DDVRが適切なバッファ・サイズを持つことを条件として、先読みデータは、グループＩデータ・ストリームに含まれるデータ全てを含むことができる。極端な場合には、送信されるデータの内容は、ビデオ・データの場合には毎日または日に1回以上リフレッシュされるかも知れない。この特定の例においては、先読みデータを毎日リフレッシュする必要があるかも知れない。リフレッシュ時間は1日から1年に及ぶまでの範囲の任意の希望の値に設定することができる。深夜過ぎ（例えば、01：00−06：00）または10：00−15：00などクライアントの要求から生じるネットワーク・アクティビティが最小となるオフピーク時間帯に先読みデータをリフレッシュすることが望ましいかも知れない。このプロセスは、待ち時間防止信号ジェネレータ、対話型信号ジェネレータまたはクライアントによるルーチン呼び出し手順によって開始することができる。そうすることで、ネットワークにおいて必要な待ち時間及びデータ・ストリームの合計数をさらに少なくすることができる。このことは、特に多数のデータ・セットを送信するVODシステムの場合特に重要かも知れない。
［スペース-時間-帯域のバランスの取り方］
本発明のIVODシステムのさまざまな構成には、必要とされるDDVRのバッファ記憶領域（スペース）、スタートアップ待ち時間（時間）及びストリーム（伝送帯域）の間でバランス関係がある。これが表3に示され、さらに図13において図解されている。
【０１０１】
図13において、頂点1は、クライアントがデータ要求を発するか否かに関係なく全てのデータが送られSTBに記憶される現在のVODシステムとして理解できる。このような場合、STBは比較的大きなバッファ・サイズを持たなければならない。これによってSTBの生産コストが増大するだろう。頂点2は、構成1−5において説明されるシステムを表す。このような構成の下では、STBの要件は最小限に抑えることができるが、システムの帯域に関する要求はより大きくなるだろう。頂点3は、頂点1と頂点2の混成システムを示している。
【０１０２】
どの頂点を選択するかの決定は、利用可能な帯域、STBの仕様、待ち時間及び対話性に関する局部的要件などを含めてさまざまなファクタに応じた設計上の選択の問題であろう。
【０１０３】
【表３】

【０１０４】
［有線、衛星及び地上波放送システムへの応用］
本発明のIVODシステムは、既存の有線TV、地上波放送及び衛星放送システムにおいてすぐに応用できるだろう。既存のインフラをごくわずか修正するだけで、非対話型放送またはNVODシステムをIVODシステムに変換することができる。アナログ及びデジタル両方の送信システムが多重ストリーミングの概念を利用することができる。ただし、下ではデジタル送信システムのシステム構成についてのみ説明する。
【０１０５】
デジタル放送システムにおいては、RF伝送帯域は通常6MHz（NTSC）または8MHz（ＰＡＬ）チャネルに分割される。有線ＴＶ、地上波または衛星放送システムには百を超えるチャネルが存在する可能性がある。図11は、この多重ストリーミング・システムの典型的なシステム構成を示している。これは、既存の放送システムに非常に似ている。待ち時間防止装置と呼ぶことができるヘッドエンドの送信ユニット及びユーザーエンドの受信ユニットであるクライアント/受信機だけを修正すればよい。ヘッドエンドにおいては、各チャネルにおいてアナログ信号を送る代わりにQAMなどデジタル信号が送信される。一般に、1つのRFチャネルに30−40Mb/秒を配することができる。2時間の内容と仮定すると、まずMPEG-4またはその他の圧縮アルゴリズムを使って、ほぼ1Mb/秒のビット速度でアナログ信号をデジタル・ストリームに変換することができる。フィボナッチ二重ストリーミング（構成３）または最適調和多重ストリーミングIVOD概念（構成4）を使用すると、単一のRFチャネルに30から40のIVODストリームを配することができる。既存の放送システムとの互換性を維持するために、内容はPAL/NTSC/SECAM標準に従ってさまざまなRFチャネルに配され、各RFチャネルは数時間の内容を含むことができる。
【０１０６】
ユーザーエンドにおいては、セットトップ・ボックスが特定のRFチャネルにRF調整されなければならない。こうして、ケーブル・モデムは30−40Mb/秒デジタル・ストリームをフィルタアウトして、同時に2つのストリームをデコードするか（フィボナッチ二重ストリーミング・システムの場合）または全ての調和マルチストリームをデコードする（調和多重ストリーミング・システムの場合）。図12は、STB/ケーブル・モデムのブロック図を示している。このSTB/ケーブル・モデムは、その処理ユニットが単一のストリームではなく同時に少なくとも２つのマルチストリームを処理できることを除くと、他のSTB/ケーブル・モデムと同様である。デコードされたストリームはSTBのバッファで記憶され、内容はセグメントの通し番号に従って再構成される。典型的な放送システムにおいては数百のチャネルが利用可能なので、これは、無限数のユーザーが利用できる完全対話型プログラムの200時間分かそれ以上に相当する。
【０１０７】
本発明の望ましい実施態様は例によって詳細に説明されているが、当業者が本発明の修正及び改作を思いつくことは明らかである。ただし、この種の修正及び改作は以下のクレームに示されるとおり本発明の範囲内にあると明確に解釈されるものとする。さらに、本発明の実施態様は例または図のみによって制約されるとは解釈されないものとする。
【０１０８】
本発明の望ましい実施態様について、例として、添付の図面を参照しながら説明する。
【図面の簡単な説明】
【０１０９】
【図１】NVODシステムのデータ・ストリーム構造を示している。
【図２】QVODシステムのデータ・ストリーム構造を示している。
【図３】本発明のデータ伝送システムの全体的システム・アーキテクチャを示している。
【図４】本発明のデータ伝送システムの構成1のデータ・ストリーム配列を示している。
【図５】本発明のデータ伝送システムの構成2のデータ・ストリーム配列を示している。
【図６】本発明のデータ伝送システムの構成3のデータ・ストリーム配列を示している。グループIIデータ・ストリームの配列が図4及び5と比較して異なることに留意すること。
【図７】構成3の別のグループＩデータ・ストリーム配列を示している。
【図８】本発明のデータ伝送システムの構成4のグループＩデータ・ストリームのデータ・ストリーム配列を示している。
【図９】本発明のデータ伝送システムの構成4のグループＩデータ・ストリームの別の配列を示している。
【図１０】本発明のデータ伝送システムの構成5のデータ・ストリーム配列の1つを示している。この図に示されるグループＩデータ・ストリームの特定の配列は、構成1と3を組み合わせている。
【図１１】本発明のデータ伝送システムのマルチキャスト・データ・ストリーム・ジェネレータのシステム構成を示している。
【図１２】本発明のデータ伝送システムの受信機のシステム構成を示している。
【図１３】局部記憶と伝送帯域のバランス関係を示している。
【図１４】構成1の「オン・デマンド」代替方法を示している。
【図１５】構成2の「オン・デマンド」代替方法を示している。
【図１６】構成3の「オン・デマンド」代替方法を示している。

Claims (141)

1. 少なくとも1台のクライアントへのデータの送信を開始するためにある待ち時間を有する、ネットワーク上で前記クライアントに前記データを送信するためのシステムであって、
   前記クライアントが受信するために少なくともデータの先頭部分を含む少なくとも1つの待ち時間防止データ・ストリームを生成するための少なくとも1つの待ち時間防止信号ジェネレータと、
   待ち時間防止データ・ストリームの少なくとも一部を受信した後前記クライアントが併合するために前記データの少なくとも残り部分を含む対話型データ・ストリームを生成するための少なくとも1つの対話型信号ジェネレータと、
   を含む、システム。
2. 前記データが、各々前記ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化され、
   前記待ち時間防止データ・ストリームがM個の待ち時間防止データ・ストリームを含み、
   前記対話型データ・ストリームがN個の対話型データ・ストリームを含む、
   請求項1に記載のシステム。
3. 前記待ち時間防止データ・ストリームが前記データの前記先頭部分のみを含み、
   前記対話型データ・ストリームが前記データのセット全体を含む、
   請求項1に記載のシステム。
4. 前記M個の待ち時間防止データ・ストリームの各々が、前記待ち時間防止データ・ストリーム内で連続的に反復される実質的に同一のデータを含み、かつ該システムにおいて、連続する各待ち時間防止データ・ストリームが待ち時間防止時間間隔の時差を持ち、
   前記N個の対話型データ・ストリームの各々が前記対話型データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各対話型データ・ストリームが対話型時間間隔の時差を持つ、
   請求項2に記載のシステム。
5. 前記M個の待ち時間防止データ・ストリームの各々がJ個のセグメントを有し、
   前記待ち時間防止時間間隔≧Tである、
   請求項4に記載のシステム。
6. 前記対話型時間間隔≧JTである、請求項4に記載のシステム。
7. 該システムにおいて、M≧Jである、請求項5に記載のシステム。
8. 該システムにおいて、M=Jである、請求項7に記載のシステム。
9. 該システムにおいて、N≧ R/JTである、請求項6に記載のシステム。
10. 該システムにおいて、N= R/JTである、請求項9に記載のシステム。
11. M=N=J=(R/T)^1/2である、請求項8または10に記載のシステム。
12. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項4に記載のシステム。
13. 該システムにおいて、前記N個のデータ・ストリームの各々が前記データの前記残り部分のみを含む、請求項4に記載のシステム。
14. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記M個の待ち時間防止データ・ストリームのうち任意の1つに接続され、
    前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続される、
    請求項4に記載のシステム。
15. 前記待ち時間防止データ・ストリームが、
    Ｉ．前記データの前記先頭部分の少なくとも1つの先頭セグメントを含む先頭データ・ストリームであり、前記少なくとも1つの先頭セグメントが該先頭データ・ストリーム内で連続的に反復される、先頭データ・ストリームと、
    II．複数の終了データ・ストリームであり、該終了データ・ストリームの各々が
    ・ 前記データの前記先頭部分の残りを含み、
    ・ 該終了データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各終了データ・ストリームが待ち時間防止時間間隔の時差を持つ、
    複数の終了データ・ストリームと、
    を含み、
    前記N個の対話型データ・ストリームの各々が前記対話型データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各対話型データ・ストリームが対話型時間間隔の時差を持つ、
    請求項2に記載のシステム。
16. 前記終了データ・ストリームの各々がJ個のセグメントを有し、
    前記待ち時間防止時間間隔≧Tである、
    請求項15に記載のシステム。
17. 該システムにおいて、前記対話型時間間隔≧JTである、請求項15に記載のシステム。
18. M≧ J/2 + 1である、請求項16に記載のシステム。
19. M=J/2 + 1である、請求項18に記載のシステム。
20. N≧R/JTである、請求項17に記載のシステム。
21. 該システムにおいて、N=R/JTである、請求項20に記載のシステム。
22. J=(2K)^1/2である、請求項19または21に記載のシステム。
23. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項15に記載のシステム。
24. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項15に記載のシステム。
25. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記先頭データ・ストリームに接続され、
    その後、前記クライアントが前記終了データ・ストリームのうち任意の1つに接続され、
    前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続される、
    請求項15に記載のシステム。
26. 前記N個の対話型データ・ストリームの各々が前記対話型データ・ストリーム内で連続的に反復され、かつ該システムにおいて連続する各データ・ストリームが対話型時間間隔＝KT/Nの時差を持ち、
    前記M個の待ち時間防止データ・ストリーム［1からMまで］が、
    ・ m番目の待ち時間防止データ・ストリームがF_m個のセグメントを持ち、ここで、F_mがm番目のフィボナッチ数であり、
    ・ 前記F_m個のセグメントがm番目の待ち時間防止データ・ストリーム内で連続的に反復される、
    ように、生成される、
    請求項2に記載のシステム。
27. 前記先頭部分の全てのデータが前記クライアントによって受信されるまで、
    前記クライアントが前記データの要求を発するとき、前記クライアントが少なくともm番目及び（ｍ+1）番目の待ち時間防止データ・ストリームに接続され、
    前記クライアントにおいて少なくとも前記m番目及び（ｍ+1）番目の待ち時間防止データ・ストリームのデータがバッファに記憶され、
    その後、前記クライアントが後に続く待ち時間防止データ・ストリームに接続される、
    請求項26に記載のシステム。
28. 前記先頭部分の全てのデータが前記クライアントによって受信された後、前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続される、
    請求項27に記載のシステム。
29. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項26に記載のシステム。
30. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項26に記載のシステム。
31. F_M≧2K/Nである、請求項26に記載のシステム。
32. mが1から始まる、請求項26に記載のシステム。
33. mが4から始まり、反復する1番目、2番目及び3番目の待ち時間防止データ・ストリームが下記の構成を有する、請求項26に記載のシステム。
    

    
34. 前記N個の対話型データ・ストリームの各々が、前記対話型データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各対話型データ・ストリームが対話型時間間隔＝KT/Nの時差を持ち、
    前記M個の待ち時間防止データ・ストリームにおいて、
    Ｉ．前記データの前記先頭部分が［1からJまで］J個の［ラベル付き］先頭データ・セグメントを含み、
    II．前記先頭データ・セグメントが、j番目の先頭セグメントが前記待ち時間防止データ・ストリーム内で待ち時間防止時間間隔≦jTで反復されるように、前記M個の待ち時間防止データ・ストリームにおいて配分される、
    請求項2に記載のシステム。
35. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記M個の待ち時間防止データ・ストリームの全てに接続され、
    前記クライアントにおいて前記M個の待ち時間防止データ・ストリームの前記データの前記先頭部分がバッファに記憶される、
    請求項34に記載のシステム。
36. 前記先頭部分の全てのデータが前記クライアントによって受信された後、前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続される、
    請求項35に記載のシステム。
37. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項34に記載のシステム。
38. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項34に記載のシステム。
39. 

    及びJ=K/Nである、請求項34に記載のシステム。
40. 前記先頭データ・セグメントを含む前記M個の待ち時間防止データ・ストリームのうち6つが下記の通りに配列され、該システムにおいて、空白のセグメントが任意のデータを含む、請求項34に記載のシステム。
    

    
41. 前記M個の待ち時間防止データ・ストリームが、
    前記データの前記先頭部分を含み、
    さらに、待ち時間防止データ・ストリームの第一のセット及び待ち時間防止データ・ストリームの第二のセットである2つのバッチのデータ・ストリームを含む、
    請求項2に記載のシステム。
42. 前記第一の待ち時間防止データ・ストリームがA個の第一の待ち時間防止データ・ストリーム［1からAまで］を有し、該システムにおいて、
    Ｉ．a番目の待ち時間防止データ・ストリームがF_a個のセグメントを有し、F_aがa番目のフィボナッチ数であり、
    II．前記F_a個のセグメントがa番目の第一の待ち時間防止データ・ストリーム内で連続的に反復され、
    前記第二の待ち時間防止データ・ストリームがB個の第二の待ち時間防止データ・ストリームを有し、該システムにおいて、前記B個の第二の待ち時間防止データ・ストリームの各々が前記第二の待ち時間防止データ・ストリーム内で連続的に反復される実質的に同一のデータを含み、かつ該システムにおいて、連続する各第二の待ち時間防止データ・ストリームが粗ジャンプ・フレーム周期の時差を持つので、
    前記クライアントが、前記B個の待ち時間防止データ・ストリームに接続されるとき、前記クライアントが粗ジャンプ機能を実行できる、
    請求項41に記載のシステム。
43. 前記A個の第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信されるまで、
    前記クライアントが前記データの要求を発するとき、前記クライアントが少なくともa番目及び（a+1）番目の第一の待ち時間防止データ・ストリームに接続され、
    前記クライアントにおいて少なくとも前記a番目及び（a+1）番目の第一の待ち時間防止データ・ストリームのデータがバッファに記憶され、
    その後、前記クライアントが後に続く第一の待ち時間防止データ・ストリームに接続される、
    請求項42に記載のシステム。
44. 前記第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記B個の第二の待ち時間防止データ・ストリームのうち任意の1つに接続され、
    前記接続されたB個の第二の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つにされる、
    請求項43に記載のシステム。
45. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項42に記載のシステム。
46. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項42に記載のシステム。
47. 該システムにおいて、前記粗ジャンプ・フレーム周期がE個のデータ・セグメントを含み、F_A≧2Eである、請求項42に記載のシステム。
48. 該システムにおいて、aが1から始まる、請求項42に記載のシステム。
49. aが4から始まり、反復する1番目、2番目及び3番目の待ち時間防止データ・ストリームが下記の構成を有する、請求項42に記載のシステム。
    

    
50. 前記第一の待ち時間防止データ・ストリームがA個の第一の待ち時間防止データ・ストリーム［1からAまで］を有し、該システムにおいて、
    Ｉ．a番目の待ち時間防止データ・ストリームがFa個のセグメントを有し、ここでFaがa番目のフィボナッチ数であり、
    II．前記Fa個のセグメントがa番目の第一の待ち時間防止データ・ストリーム内で連続的に反復され、
    前記第二の待ち時間防止データ・ストリームがB個の第二の待ち時間防止データ・ストリームを有し、前記B個の第二の待ち時間防止データ・ストリームが
    Ｉ．前記データの前記先頭部分の少なくとも1つの先頭セグメントを含む先頭データ・ストリームであり、前記少なくとも1つの先頭セグメントが該先頭データ・ストリーム内で連続的に反復される、先頭データ・ストリームと、
    II．複数の終了データ・ストリームであり、該終了データ・ストリームの各々が
    ・ 前記データの前記先頭部分の残りを含み、
    ・ 該終了データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各終了データ・ストリームが粗ジャンプ・フレーム周期の時差を持つ、
    複数の終了データ・ストリームと、
    を含むので、
    前記クライアントが前記B個の第二の待ち時間防止データ・ストリームに接続されるとき、前記クライアントが粗ジャンプ対話機能を実行できる、
    請求項41に記載のシステム。
51. 前記A個の第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信されるまで、
    前記クライアントが前記データの要求を発するとき、前記クライアントが少なくともa番目及び（a+1）番目の第一の待ち時間防止データ・ストリームに接続され、
    前記クライアントにおいて、少なくとも前記a番目及び（a+1）番目の第一の待ち時間防止データ・ストリームのデータがバッファに記憶され、
    その後、前記クライアントが後に続く第一の待ち時間防止データ・ストリームに接続される、
    請求項50に記載のシステム。
52. 前記第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記先頭データ・ストリームに接続され、
    その後、前記クライアントが前記終了データ・ストリームのうち任意の1つに接続され、
    前記B個の第二の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続される、
    請求項51に記載のシステム。
53. 該システムにおいて、前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項50に記載のシステム。
54. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項50に記載のシステム。
55. 前記粗ジャンプ・フレーム周期がE個のデータ・セグメントを含み、F_A≧2Eである、請求項50に記載のシステム。
56. aが1から始まる、請求項50に記載のシステム。
57. aが4から始まり、前記A個の第一の待ち時間防止データ・ストリームのうち反復する1番目、2番目及び3番目のデータ・ストリームが下記の構成を有する、請求項50に記載のシステム。
    

    
58. 前記第一の待ち時間防止データ・ストリームがA個の第一の待ち時間防止データ・ストリームを有し、該システムにおいて、
    Ｉ．前記A個の第一の待ち時間防止データ・ストリームが［1からCまで］C個の第一のデータ・セグメントを含み、
    II．c番目の先頭セグメントが前記A個の第一の待ち時間防止データ・ストリーム内で待ち時間防止時間間隔≦cTで反復されるように、前記第一のデータ・セグメントが前記A個の第一の待ち時間防止データ・ストリームにおいて配分され、
    前記第二の待ち時間防止データ・ストリームがB個の第二の待ち時間防止データ・ストリームを有し、該システムにおいて、前記B個の第二の待ち時間防止データ・ストリームの各々が、前記第二の待ち時間防止データ・ストリーム内で連続的に反復される実質的に同一のデータを含み、かつ該システムにおいて、連続する各第二の待ち時間防止データ・ストリームが粗ジャンプ・フレーム周期の時差を持つので、
    前記クライアントが前記B個の第二の待ち時間防止データ・ストリームに接続されるとき、前記クライアントが粗ジャンプ対話機能を実行できる、
    請求項41に記載のシステム。
59. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記A個の第一の待ち時間防止データ・ストリームの全てに接続され、
    前記A個の第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信されるまで、前記クライアントにおいて前記A個の第一の待ち時間防止データ・ストリームのデータがバッファに記憶される、
    請求項58に記載のシステム。
60. 前記第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記B個の第二の待ち時間防止データ・ストリームの任意の1つに接続され、
    前記接続されたB個の第二の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続される、
    請求項59に記載のシステム。
61. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項58に記載のシステム。
62. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項58に記載のシステム。
63. 前記粗ジャンプ・フレーム周期がE個のデータ・セグメントを含み、
    

    

    である、請求項58に記載のシステム。
64. 前記A個の第一の待ち時間防止データ・ストリームのうち6つが下記の通りに配列され、該システムにおいて、空白のセグメントが任意のデータを含む、請求項58に記載のシステム。
    

    
65. 前記第一の待ち時間防止データ・ストリームがA個の第一の待ち時間防止データ・ストリームを有し、該システムにおいて、
    Ｉ．前記A個の第一の待ち時間防止データ・ストリームが［1からCまで］C個の第一のデータ・セグメントを含み、
    II．c番目の先頭セグメントが前記A個の第一の待ち時間防止データ・ストリーム内で待ち時間防止時間間隔≦cTで反復されるように、前記データ・セグメントＩが前記A個の第一の待ち時間防止データ・ストリームにおいて配分され、
    前記第二の待ち時間防止データ・ストリームがB個の第二の待ち時間防止データ・ストリームを有し、前記B個の第二の待ち時間防止データ・ストリームが、
    Ｉ．前記データの前記先頭部分の少なくとも1つの先頭セグメントを含む先頭データ・ストリームであり、前記少なくとも1つの先頭セグメントが該先頭データ・ストリーム内で連続的に反復される、先頭データ・ストリームと、
    II．複数の終了データ・ストリームであり、該終了データ・ストリームの各々が
    ・ 前記データの前記先頭部分の残りを含み、
    ・ 該終了データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各終了データ・ストリームが粗ジャンプ・フレーム周期の時差を持つ、
    複数の終了データ・ストリームと、
    を含むので、
    前記クライアントが前記B個の第二の待ち時間防止データ・ストリームに接続されるとき、前記クライアントが粗ジャンプ対話機能を実行できる、
    請求項41に記載のシステム。
66. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記A個の第一の待ち時間防止データ・ストリームの全てに接続され、
    前記A個の第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信されるまで、前記クライアントにおいて前記A個の第一の待ち時間防止データ・ストリームのデータがバッファに記憶される、
    請求項65に記載のシステム。
67. 前記第一の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記B個の第二の待ち時間防止データ・ストリームの前記先頭データ・ストリームに接続され、
    その後、前記クライアントが前記終了データ・ストリームのうち任意の1つに接続され、
    ステップFにおいて接続された前記B個の第二の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続される、
    請求項66に記載のシステム。
68. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項65に記載のシステム。
69. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項65に記載のシステム。
70. 前記粗ジャンプ・フレーム周期がE個のデータ・セグメントを含み、
    

    

    である、請求項65に記載のシステム。
71. 前記A個の第一の待ち時間防止データ・ストリームのうち6つが下記の通りに配列され、該システムにおいて、空白のセグメントが任意のデータを含む、請求項67に記載のシステム。
    

    
72. 前記K個のデータ・セグメントの各々が頭部分及び末尾部分を含み、前記クライアントによって受信されるとき前記K個のデータ・セグメントの併合を容易にするために前記頭部分がすぐ前のセグメントの末尾部分のデータの一部を含む、請求項2、4、15、26、34、41、42、50、58または65のいずれか一項に記載のシステム。
73. 前記クライアントにおいて前記先頭部分のデータの少なくとも一部が先読みされる、請求項2、4、15、26、34、41、42、50、58または65のいずれか一項に記載のシステム。
74. 各々ネットワーク上で送信するために時間Tを必要とするK個のデータ・セグメントにデータを細分化するための信号ジェネレータを含む、ネットワーク上で少なくとも1台のクライアントに前記データを送信するためのシステムであり、該システムにおいて、前記K個のデータ・セグメントの各々が頭部分及び末尾部分を含み、前記クライアントによって受信されるとき前記K個のデータ・セグメントの併合を容易にするために前記頭部分がすぐ前のセグメントの末尾部分のデータの一部を含む、システム。
75. クライアントへのデータの送信を開始するためにある待ち時間を有する、ネットワーク上で少なくとも1台のクライアントに前記データを送信するためのシステムであり、
    クライアントが受信するためにデータの少なくとも先頭部分を含む待ち時間防止データ・ストリームを少なくとも1つ生成するための少なくとも1つの待ち時間防止信号ジェネレータと、
    前記先頭部分を先読みデータとして先読みするための前記クライアントのバッファと、
    前記クライアントが前記先頭部分に併合するために前記データの少なくとも残り部分を含む少なくとも1つの対話型データ・ストリームを生成するための少なくとも1つの対話型ジェネレータと、
    を含む、システム。
76. 該システムにおいて、リフレッシュ時間中に前記先読みデータがリフレッシュされる、請求項75に記載のシステム。
77. 前記リフレッシュ時間がオフピーク時間帯である、請求項76に記載のシステム。
78. 前記先読みデータが日に1度リフレッシュされる、請求項76に記載のシステム。
79. 複数の待ち時間防止データ・ストリームを生成するための少なくとも1つの待ち時間防止信号ジェネレータを含む、ネットワーク上で少なくとも1台のクライアントにデータを送信するためのシステムであり、前記待ち時間防止データ・ストリームが、
    前記データの先頭部分の少なくとも1つの先頭セグメントを含む先頭データ・ストリームであり、前記先頭セグメントが該先頭データ・ストリーム内で連続的に反復される、先頭データ・ストリームと、
    複数の終了データ・ストリームであり、該終了データ・ストリームの各々が、
    ・ 前記データの前記先頭部分の少なくとも残りを含み、
    ・ 該終了データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各終了データ・ストリームが待ち時間防止時間間隔の時差を持つ、
    複数の終了データ・ストリームと、
    を含む、システム。
80. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記先頭データ・ストリームに接続され、
    その後、前記クライアントが前記終了データ・ストリームのうち任意の1つに接続される、
    請求項79に記載のシステム。
81. 前記データが、各々ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化され、前記待ち時間防止時間間隔≧Tである、請求項79に記載のシステム。
82. 複数の待ち時間防止データ・ストリームを生成するために少なくとも1つの待ち時間防止信号ジェネレータを含む、ネットワーク上で少なくとも1台のクライアントにデータを送信するためのシステムであり、該システムにおいて、前記待ち時間防止データ・ストリームが、
    M個の待ち時間防止データ・ストリーム［1からMまで］であり、該システムにおいて、m番目の待ち時間防止データ・ストリームがF_m個のセグメントを有し、F_mがm番目のフィボナッチ数であり、かつ該システムにおいて、前記F_m個のセグメントがm番目の待ち時間防止データ・ストリーム内で連続的に反復される、M個の待ち時間防止データ・ストリーム、
    を含む、システム。
83. 該システムにおいて、
    全てのデータが前記クライアントによって受信されるまで、
    前記クライアントが前記データの要求を発するとき、前記クライアントが少なくともm番目及び（m+1）番目の待ち時間防止データ・ストリームに接続され、
    前記クライアントにおいて、少なくとも前記m番目及び（m+1）番目の待ち時間防止データ・ストリームのデータがバッファに記憶され、
    その後、前記クライアントが後に続く待ち時間防止データ・ストリームに接続される、
    請求項82に記載のシステム。
84. mが1から始まる、請求項82に記載のシステム。
85. mが4から始まり、反復する1番目、2番目及び3番目の待ち時間防止データ・ストリームが下記の構成を有する、請求項82に記載のシステム。
    

    
86. ネットワーク上で少なくとも1台のクライアントにデータを送信するためのシステムであり、前記データが、各々前記ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化され、該システムが、複数の待ち時間防止データ・ストリーム生成するための少なくとも1つの待ち時間防止信号ジェネレータを含み、該システムにおいて、前記待ち時間防止データ・ストリームが、
    ［1からKまで］K個の待ち時間防止データ・セグメントを含むM個の待ち時間防止データ・ストリームであり、該システムにおいて、前記待ち時間防止データ・セグメントが、k番目の先頭セグメントが該待ち時間防止データ・ストリーム内で待ち時間防止時間間隔≦kTで反復されるように該M個の待ち時間防止データ・ストリームにおいて配分される、M個の待ち時間防止データ・ストリーム、
    を含む、システム。
87. 前記クライアントが前記M個の待ち時間防止データ・ストリームの全てに接続され、
    前記クライアントが前記データの要求を発するとき、前記クライアントにおいて前記M個の待ち時間防止データ・ストリームの前記データがバッファに記憶される、
    請求項86に記載のシステム。
88. 前記先頭データ・セグメントを含む前記M個の待ち時間防止データ・ストリームのうち6つが下記の通りに配列され、該システムにおいて空白のセグメントが任意のデータを含む、請求項86に記載のシステム。
    

    
89. 請求項2に従ってネットワーク上で少なくとも1台のクライアントに送信されるデータを受信するための受信機であり、
    前記データの要求を発するためのプロセッサと、
    前記M個の待ち時間防止データ・ストリームに前記クライアントを接続し、前記M個の待ち時間防止データ・ストリームのデータを受信するための少なくとも1つのコネクタと、
    を含む、受信機。
90. 前記M個の待ち時間防止データ・ストリームの全てのデータが前記クライアントによって受信された後、前記コネクタが前記N個の対話型データ・ストリームに接続される、
    請求項89に記載の受信機。
91. 前記先頭部分のデータが順次受信される、請求項89に記載の受信機。
92. 該受信機が、前記待ち時間防止データ・ストリームのうち少なくとも2つに同時に接続される、請求項89に記載の受信機。
93. さらに、
    前記クライアントによって順次受信される前記クライアントに接続された前記2つの待ち時間防止データ・ストリームのデータをバッファに記憶するためのバッファ、
    を含む、請求項92に記載の受信機。
94. 前記バッファがランダム・アクセス・メモリ及びコンピュータ・ハードディスクを含む、請求項93に記載の受信機。
95. 前記バッファがランダム・アクセス・メモリから成る、請求項93に記載の受信機。
96. 該受信機が前記待ち時間防止データ・ストリームの全てに同時に接続される、請求項89に記載の受信機。
97. さらに、
    前記クライアントにおいて接続された前記待ち時間防止データ・ストリームのデータをバッファに記憶するためのバッファ、
    を含み、該受信機において、前記プロセッサが適切なシーケンスに従って前記バッファに記憶されたデータを再配列する、
    請求項96に記載の受信機。
98. 前記バッファがランダム・アクセス・メモリ及びコンピュータ・ハード・ディスクを含む、請求項97に記載の受信機。
99. 前記バッファがランダム・アクセス・メモリから成る、請求項97に記載の受信機。
100. 前記クライアントにおいて前記M個の待ち時間防止データ・ストリームのデータの少なくとも一部が先読みデータとして先読みされる、請求項89に記載の受信機。
101. 前記先読みデータがリフレッシュ時間中リフレッシュされる、請求項100に記載の受信機。
102. 前記リフレッシュ時間が01：00−06：00である、請求項101に記載の受信機。
103. 前記リフレッシュ時間が10：00−15：00である、請求項101に記載の受信機。
104. ネットワーク上で少なくとも1台のクライアントに送信されるデータを受信するための受信機であり、該受信機において、前記データが先頭部分及び残り部分を含み、前記残り部分が少なくとも1つの対話型データ・ストリームによって送信され、該受信機が、
     前記クライアントにおいて前記先頭部分を先読みデータとして先読みするためのバッファと、
     前記先読みデータを前記残り部分に併合するためのプロセッサと、
     を含む、受信機。
105. 前記先読みデータがリフレッシュ時間中リフレッシュされる、請求項104に記載の受信機。
106. 前記リフレッシュ時間がオフピーク時間帯である、請求項105に記載の受信機。
107. 前記先読みデータが1日に1度リフレッシュされる、請求項105に記載の受信機。
108. クライアントへのデータの送信を開始するためにある待ち時間を有する、ネットワーク上で少なくとも1台のクライアントに前記データを送信するためのシステムであり、
     前記クライアントが受信するために前記データの少なくとも先頭部分を含む待ち時間防止データ・ストリームを少なくとも1つ生成するための少なくとも1つの待ち時間防止信号ジェネレータと、
     待ち時間防止データ・ストリームの少なくとも一部を受信した後に前記クライアントが併合するために前記データの少なくとも残り部分を含む少なくとも1つの対話型データ・ストリームを生成するための少なくとも1つの対話型信号ジェネレータと、
     を含み、該システムにおいて、
     前記データの前記先頭部分が、
     ・ 規則的な待ち時間防止ストリーム間隔で生成でき、
     ・ 少なくとも1台のクライアントが前記データの要求を発した後すぐ次の待ち時間防止ストリーム間隔に生成される、
     システム。
109. 前記ネットワーク上で送信するために時間Rを必要とする前記データが、各々前記ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化され、
     前記待ち時間防止データ・ストリームがM個の待ち時間防止データ・ストリームを含み、該システムにおいて、前記M個の待ち時間防止データ・ストリームの各々が、
     ・ 実質的に同一のデータを含み、
     ・ 規則的な待ち時間防止時間間隔で生成することができ、
     ・ 前記クライアントが前記データの要求を発した後すぐ次の待ち時間防止ストリーム間隔に生成され、
     前記対話型データ・ストリームがN個の対話型データ・ストリームを含み、該システムにおいて、前記N個の対話型データ・ストリームの各々が前記対話型データ・ストリーム内で連続的に反復され、連続する各対話型データ・ストリームが対話型時間間隔の時差を持つ、
     請求項108に記載のシステム。
110. 前記M個の待ち時間防止データ・ストリームの各々がJ個のセグメントを有し、
     前記待ち時間防止時間間隔≧Tである、
     請求項109に記載のシステム。
111. 前記対話型時間間隔≧JTである、請求項110に記載のシステム。
112. M≧Jである、請求項111に記載のシステム。
113. N≧R/JTである、請求項110に記載のシステム。
114. M=N=J=(R/T)^1/2である、請求項113に記載のシステム。
115. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項109に記載のシステム。
116. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項109に記載のシステム。
117. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記クライアントのために生成される前記M個の待ち時間防止データ・ストリームに接続され、
     前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続され、
     前記クライアントが前記N個の対話型データ・ストリームのうち1つに接続された後、前記クライアントのために生成される前記M個の待ち時間防止データ・ストリームが終結される、
     請求項109に記載のシステム。
118. 該システムにおいて、
     前記ネットワーク上で送信するために時間Rを必要とする前記データが、各々前記ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化され、
     前記待ち時間防止データ・ストリームがM個の待ち時間防止データ・ストリームを含み、前記M個の待ち時間防止データ・ストリームが、
     Ｉ．先頭データ・ストリームであり、該先頭データ・ストリームが、
     ・ 前記データの前記先頭部分の少なくとも1つの先頭セグメントを含み、
     ・ 規則的な待ち時間防止時間間隔で生成することができ、
     ・ 前記クライアントが前記データの要求を発した後すぐ次の待ち時間防止ストリーム間隔に生成される、
     先頭データ・ストリームと、
     II．複数の終了データ・ストリームであり、該システムにおいて、該終了データ・ストリームの各々が、
     ・ 前記データの前記先頭部分の残りを含み、
     ・ 前記先頭セグメントのうち1つに対応し、
     ・ 前記対応する先頭セグメントが生成されるとき生成される、
     複数の終了データ・ストリームと、
     を含み、
     前記対話型データ・ストリームがN個の対話型データ・ストリームを含み、該システムにおいて、前記N個の対話型データ・ストリームの各々が前記対話型データ・ストリーム内で連続的に反復され、連続する各対話型データ・ストリームが対話型時間間隔の時差を持つ、
     請求項108に記載のシステム。
119. 前記終了データ・ストリームの各々がJ個のセグメントを有し、
     前記待ち時間防止時間間隔≧Tである、
     請求項118に記載のシステム。
120. 前記対話型時間間隔≧JTである、請求項119に記載のシステム。
121. M≧J/2 + 1である、請求項119に記載のシステム。
122. N≧R/JTである、請求項120に記載のシステム。
123. J=(2K)^1/2である、請求項120に記載のシステム。
124. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項118に記載のシステム。
125. 前記N個の対話型データ・ストリームの各々が、前記データの前記残り部分のみを含む、請求項118に記載のシステム。
126. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記クライアントのために生成される前記先頭データ・セグメントに接続され、
     その後、前記クライアントが前記対応する終了データ・ストリームに接続され、
     前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続され、
     前記クライアントが前記N個の対話型データ・ストリームのうち1つに接続された後、前記クライアントのために生成される前記先頭データ・セグメント及び前記対応する終了データ・ストリームが終結される、
     請求項118に記載のシステム。
127. 前記ネットワーク上で送信するために時間Rを必要とする前記データが、各々前記ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化され、
     前記対話型データ・ストリームが、N個の対話型データ・ストリームを含み、該システムにおいて、前記N個の対話型データ・ストリームの各々が前記対話型データ・ストリーム内で連続的に反復され、かつ該システムにおいて、連続する各対話型データ・ストリームが対話型時間間隔＝KT/Nの時差を持ち、
     前記待ち時間防止データ・ストリームがM個の待ち時間防止データ・ストリームを含み、
     ・ m番目の待ち時間防止データ・ストリームがF_m個のセグメントを有し、F_mがm番目のフィボナッチ数であり、
     ・ 前記Fm個のセグメントを規則的な待ち時間防止ストリーム間隔で生成することができ、
     ・ 前記クライアントが前記データの要求を発するとき、最初のF_m個のセグメントがすぐ次の待ち時間防止ストリーム間隔に生成され、
     ・ 前のF_m個のセグメントの全てのデータが前記クライアントによって受信される前にその後のF_(m+1)個のセグメントが生成される、
     請求項108に記載のシステム。
128. 前記クライアントが前記データの要求を発するとき、前記クライアントが少なくともｍ番目及び（ｍ+1）番目の待ち時間防止データ・ストリームに接続され、
     前記クライアントにおいて少なくとも前記ｍ番目及び（ｍ+1）番目の待ち時間防止データ・ストリームのデータがバッファに記憶され、
     その後、前記クライアントが後に続く待ち時間防止データ・ストリームに接続される、
     請求項127に記載のシステム。
129. 前記先頭部分の全てのデータが前記クライアントによって受信された後、前記クライアントが前記N個の対話型データ・ストリームのうち任意の1つに接続され、
     前記クライアントが前記N個の対話型データ・ストリームのうち1つに接続された後、前記M個の待ち時間防止データ・ストリームが終結される、
     請求項127に記載のシステム。
130. 前記N個の対話型データ・ストリームの各々が、K個のセグメントを有する前記データのセット全体を含む、請求項127に記載のシステム。
131. 前記N個の対話型データ・ストリームの各々が前記データの前記残り部分のみを含む、請求項127に記載のシステム。
132. F_M≧2K/Nである、請求項127に記載のシステム。
133. mが1から始まる、請求項127に記載のシステム。
134. mが4から始まり、反復する1番目、2番目及び3番目の待ち時間防止データ・ストリームが下記の構成を有する、請求項127に記載のシステム。
     

     
135. ネットワーク上で少なくとも1台のクライアントにデータを送信するために複数の待ち時間防止データ・ストリームを生成するための待ち時間防止信号ジェネレータであり、前記待ち時間防止データ・ストリームが、
     先頭データ・ストリームであり、該先頭データ・ストリームが、
     ・ 前記データの前記先頭部分の少なくとも1つの先頭セグメントを含み、
     ・ 規則的な待ち時間防止時間間隔で生成することができ、
     ・ 前記クライアントが前記データの要求を発した後すぐ次の待ち時間防止ストリーム間隔に生成される、
     先頭データ・ストリームと、
     複数の終了データ・ストリームであり、該終了データ・ストリームの各々が、
     ・ 前記データの前記先頭部分の残りを含み、
     ・ 前記先頭セグメントのうち1つに対応し、
     ・ 前記対応する先頭セグメントが生成されるとき生成される、
     複数の終了データ・セグメントと、
     を含む、待ち時間防止信号ジェネレータ。
136. 前記クライアントが前記データの要求を発するとき、前記クライアントが前記先頭データ・ストリームに接続され、
     その後、前記クライアントが前記対応する終了データ・ストリームに接続される、
     請求項135に記載の待ち時間防止信号ジェネレータ。
137. 前記データが、各々前記ネットワーク上で送信するために時間Tを必要とするK個のセグメントに細分化され、前記待ち時間防止時間間隔≧Tである、請求項135に記載の待ち時間防止信号ジェネレータ。
138. ネットワーク上で少なくとも1台のクライアントにデータを送信するためにM個の待ち時間防止データ・ストリームを生成するための待ち時間防止信号ジェネレータであり、該待ち時間防止信号ジェネレータにおいて、
     m番目の待ち時間防止データ・ストリームがF_m個のセグメントを有し、F_mがm番目のフィボナッチ数であり、
     前記F_m個のセグメントを規則的な待ち時間防止ストリーム間隔で生成することができ、
     前記クライアントが前記データの要求を発するとき、最初のF_m個のセグメントがすぐ次の待ち時間防止ストリーム間隔に生成され、
     前のF_m個のセグメントの全てのデータが前記クライアントによって受信される前に、その後のF_(m+1)個のセグメントが生成される、
     待ち時間防止信号ジェネレータ。
139. 前記クライアントが前記データの要求を発するとき、前記クライアントが少なくともm番目及び（ｍ+1）番目の待ち時間防止データ・ストリームに接続され、
     前記クライアントにおいて少なくとも前記m番目及び（ｍ+1）番目の待ち時間防止データ・ストリームのデータがバッファに記憶され、
     その後、前記先頭部分の全てのデータが前記クライアントによって受信されるまで、前記クライアントが後に続く待ち時間防止データ・ストリームに接続される、
     請求項138に記載の待ち時間防止信号ジェネレータ。
140. mが1から始まる、請求項138に記載の待ち時間防止信号ジェネレータ。
141. mが4から始まり、反復する1番目、2番目及び3番目の待ち時間防止データ・ストリームが下記の構成を有する、請求項138に記載の待ち時間防止信号ジェネレータ。
     

     

Images