JPH09182055A - リアルタイムデータ伝送用情報提供システム - Google Patents

Abstract

(57)【要約】 【課題】 通信の効率を向上させ、サービスコストを低
減し、通信資源を有効利用する。 【解決手段】 リアルタイムデータの伝送に必要な品質
が保証される第１の通信要素と、上記第１の通信要素と
は別の第２の通信要素と、蓄積されたリアルタイムデー
タを第１の通信要素を利用して送信するとともに、上記
第１の通信要素により伝送されるリアルタイムデータよ
り時間的に先行するリアルタイムデータを第２の通信要
素を利用して送信する要素と、少なくとも第２の通信要
素により送られてきたデータを蓄積する蓄積要素と、上
記第１の通信要素から送られるリアルタイムデータ及び
上記蓄積要素に蓄積されたリアルタイムデータの再生時
間を監視し、蓄積要素に蓄積された第２の通信手段から
送られたリアルタイムデータの再生時間になったら、出
力を上記第１の通信要素からのリアルタイムデータから
上記蓄積要素からのリアルタイムデータへ切替える切り
替え要素とからなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はＶＯＤ（Video on D
emand ）サービスのような蓄積されたメディアをネット
ワークを介してリアルタイムで再生するサービスを実現
するシステムであり、特にネットワークの種々のサービ
スクラスをその特性にあったサービスごとに使い分ける
システムに関する。

【０００２】また、本発明は、ＶＯＤ（Video on Deman
d ）サービスやＭＯＤ（Multimediaon Demand）サービ
スのように、サーバに蓄積されたメディア情報を、ユー
ザからの要求に応じて、ネットワークを介してリアルタ
イムでユーザに提供するサービスを実現するシステムに
関する。

【０００３】特に本発明で対象としているのは、データ
が時系列的に順序管理されているようなデータ、あるい
はより限定して言えばそのデータの利用がタイムスタン
プなどの時間情報によって管理されているような性質の
データに関する装置及びシステムであり、本発明ではこ
れらのデータを総括してリアルタイムデータと称してい
る。

【０００４】

【従来の技術】近年、ネットワークの高速広帯域化とデ
ィジタル映像技術の進展により、インタラクティブなビ
デオサービスの実用化が始まろうとしている。このよう
なサービスの典型的な例の一つにＶＯＤサービスがあ
る。ＶＯＤサービスとは、ビデオソースを蓄えたビデオ
サーバが基本的にクライアントと１対１の回線接続を行
い、クライアントの通常再生、サーチ、特殊再生などの
要求に応じてビデオサーバからビデオソースの出力を行
うサービスである。これらＶＯＤサービスの多くは、少
なくともネットワークの基幹部分においては非同期転送
モード（以下、ＡＴＭという）を利用することが想定さ
れている。

【０００５】なお、本発明で言うところのビデオサーバ
には、あるユーザに対して提供中のビデオ情報を伝送す
るために設定された通信回線の途中またはその近傍にお
いて、そのビデオを蓄積しておき、他のユーザからの同
一のビデオへの要求に対して、これを再利用する、いわ
ゆるキャッシュノード、あるいはネットワークキャッシ
ュなどと呼ばれる一時記憶型のサーバをも包含するもの
とする。

【０００６】ＡＴＭではいくつかクラスが提供される。
たとえば、ＡＴＭの業界標準設定組織であるＡＴＭフォ
ーラムでは以下の５つのクラスが標準化される。すなわ
ち、固定ビットレート（以下、ＣＢＲ−Constant Bit R
ate −という）、リアルタイム可変ビットレート（以
下、ＲＴ−ＶＢＲ−RealTime Variable Bit Rate−とい
う）、非実時間可変ビットレート（以下、ＮＲＴ−ＶＢ
Ｒ−Non-RealTime Variable Bit Rate−という）、有効
ビットレート（以下、ＡＢＲ−Available Bit Rate−と
いう）、非特定ビットレート（以下、ＵＢＲ−Unspecif
ied Bit Rate−という）の５つである。これらのうち、
上述したようなビデオの伝送サービスはリアルタイムサ
ービスであるため、現状ではＣＢＲのサービスクラスが
使われるのが普通である。

【０００７】上述した５つのサービスクラスについて考
える。実時間性という見地からは、ギャランティクラス
であるＣＢＲ、ＲＴ−ＶＢＲの２クラスが品質保証され
る。また、ＣＢＲはセル廃棄確率が極めて低く、高品質
であるが、ＡＴＭで特に帯域の有効利用方法として有効
であると言われている統計多重効果を用いないのでコス
トは高い。ＲＴ−ＶＢＲは、セル廃棄特性はＣＢＲほど
よくないが統計多重効果を用いるのでＣＢＲよりも安価
である。一方、ＮＲＴ−ＶＢＲ、ＡＢＲ、ＵＢＲは実時
間性は保証されないが、空き帯域の有効利用を図るベス
トエフォートサービスであるため、通信コストの大幅な
低下が期待できる。

【０００８】上述のような従来の画像配送方式では、伝
送品質はＣＢＲで一定である。たとえば、ＶＯＤで２時
間のビデオを観る状況を考えてみる。一般的にＶＯＤで
は通信呼への要求品質としては、以下のような事項が考
えられる。即時提供のための実時間性、画像、あるいは
音声の品質確保のための低いセル廃棄率、ビデオサービ
スの低コスト化を実現するための低コスト通信などであ
る。実時間性、セル廃棄特性保証の点から、ＣＢＲが前
提となっている。

【０００９】一般に、ＣＢＲは呼接続手続きにおいて帯
域がピークセルレートで割り付けられ、この帯域は呼が
設定されている間は恒常的に設定されたままである。Ｃ
ＢＲは帯域を十分に確保して通信するから品質が良い反
面、多重効果を使わない方式であり、したがって、通信
コストとしては高価である。たとえば、上記ＶＯＤを考
えてみる。観ている間は呼を設定している必要がある。
１５５Ｍｂｐｓの通信回線上に６ＭｂｐｓのＭＰＥＧ
（Moving Picture Experts Group）方式で画像を配送す
ることを考えると同時に提供できる画像は２５本であ
る。その条件のもとで通信コストが設定される。もちろ
ん、総コストの中にはソフト的なコストも含まれてくる
から、通信コストを削減することは低コスト化の点から
も重要である。従来方式では、この低コスト化という点
で問題があった。

【００１０】また、従来も前のクライアントのために蓄
えられたビデオを別のクラアイントがアクセスする場合
に再利用することが行われていたが、データ蓄積装置の
蓄積容量が有限であるため、アクセス頻度の低いビデオ
は順次消去する必要がある。この場合、ビデオの消去は
ビデオソース単位で行うしかなかったので、消去された
直後に別のクライアントがアクセスした場合には、再度
上記ＣＢＲによる伝送を行う必要があり、上記問題点を
さらに増幅するという不具合があった。

【００１１】次に、ＶＯＤサービスにおけるサーバの配
置について説明する。ＶＯＤサービスにおいて提供すべ
きビデオソースとしては、映画館で上映された映画にと
どまらず、テレビ用に製作されたテレビ映画やドラマ、
記録映画など、そのジャンルは多岐にわたり、しかも映
画が発明されて以来、現在までに製作されてきた全ての
作品が対象となるため、その数は極めて膨大である。一
方、このようなビデオソースを蓄えるビデオサーバの持
つ記録容量は有限であり、一つのビデオサーバに全ての
ビデオソースを蓄えておくことは不可能である。しか
も、一つのビデオサーバから同時に読み出すことのでき
る情報量も有限であるため、一般にアクセス頻度が高い
と予想されるビデオソースを蓄積するビデオサーバは、
ユーザに近いところに地域ごとに配置し、アクセス頻度
が低いと予想されるビデオソースを蓄積するビデオサー
バは、ユーザから遠いセンターに設置するという２階層
構成、あるいはアクセス頻度に応じてさらに多階層の構
成をとることが考えられている。

【００１２】このように提供すべきビデオソースを蓄積
しているビデオサーバが、ネットワーク上に分散的に配
置されている場合、ユーザの要求に従って要求されたビ
デオソースを蓄積しているビデオサーバのうち、ユーザ
に最も近いサーバとユーザとの間に通信回線を設定し、
その通信回線を通じてビデオ伝送を行うことが通信コス
トの観点から必要である。従来は、ユーザが予め配布さ
れたビデオリストなどによって見たいビデオを決定し、
そのビデオを直接指定していたため、ユーザがビデオを
指定してから、そのビデオを提供すべき最適なビデオサ
ーバを決定し、通信回線の設定を行えば良かった。

【００１３】ところが、今後はユーザが、例えば最も末
端のビデオサーバとの間に通信回線を設定し、画面に表
示されたビデオリストやプレビュー用に用意されたビデ
オソースの一部、またはハイライトシーンを集めたプロ
モーションビデオなどインタラクティブにアクセスしな
がら、最終的に見たいビデオを決定するようになること
が考えられる。このとき、ユーザの操作に対する応答性
および通信コストの観点から、末端のビデオサーバにビ
デオリストまたはプレビュー用のビデオ情報を蓄積して
おくことが好ましいが、その場合、ユーザが見たいビデ
オを決定してから、実際にそのビデオソースが蓄積され
ているサーバとの間に通信回線を設定しようとすると、
通信ネットワークの幅輳があった場合には通信回線が設
定できず、そのビデオをユーザに提供できない。また、
そのビデオソースが蓄積されているサーバの同時サービ
ス数がサーバの性能限界に達している場合には、通信回
線の設定が可能であってもそのビデオを提供することは
できない。

【００１４】

【発明が解決しようとする課題】以上のように、従来の
画像配送方式で即時の画像提供を実現するためには、セ
ル廃棄率の低いサービスを実現することが必要であった
が、画像伝送サービスの低コスト化の点、また通信資源
の有効利用の点から問題があった。

【００１５】また、上述のようにサーバがネットワーク
に対して階層的に配置された場合、ユーザが見たいビデ
オを決定してから通信網資源やサーバ資源を確保しよう
とすると、見たいビデオを決定するために費やした時間
が無駄になる場合があり、ユーザにとって極めて不都合
である。

【００１６】本発明においては通信の効率を向上させ、
サービスコストの低減を図り、通信資源を有効利用する
ことが可能なリアルタイムデータ伝送用情報提供システ
ムを提供することを目的とする。

【００１７】

【課題を解決するための手段】上述の課題を解決するた
めに、本発明においては、リアルタイムデータの伝送に
必要な品質が保証される第１の通信手段と、上記第１の
通信手段とは別の第２の通信手段と、蓄積されたリアル
タイムデータを第１の通信手段を利用して送信するとと
もに、上記第１の通信手段により伝送されるリアルタイ
ムデータより時間的に先行するリアルタイムデータを第
２の通信手段を利用して送信する手段と、少なくとも第
２の通信手段により送られてきたデータを蓄積する蓄積
手段と、上記第１の通信手段から送られるリアルタイム
データ及び上記蓄積手段に蓄積されたリアルタイムデー
タの再生時間を監視し、蓄積手段に蓄積された第２の通
信手段から送られたリアルタイムデータの再生時間にな
ったら、出力を上記第１の通信手段からのリアルタイム
データから上記蓄積手段からのリアルタイムデータへ切
替える切り替え手段とを有し、上記第２の通信手段に必
ずしもリアルタイムデータの伝送に必要な品質を保証し
ないサービスクラスを用いることにより、効率の良い通
信を実現しコストの削減を図ろうとするものである。

【００１８】また、最低限のデータ伝送レートが保証さ
れる通信手段と、蓄積されたリアルタイムデータを上記
通信手段を利用して再生伝送レートが上記保証される最
低限のデータ伝送レート以下になるように送信する手段
と、上記送信されたリアルタイムデータを入力し、上記
再生伝送レートで出力する蓄積手段（ＦＩＦＯ）と、上
記蓄積手段からの出力を受信して上記リアルタイムデー
タを再生する再生手段とを有し、同じく効率の良い通信
を実現しコストの削減を図ろうとするものである。

【００１９】上記の方法は、特に、ＶＯＤのような蓄積
型のデータを実時間でサービスする場合に通信コストを
低減する方法として有効である。画像提供の要求を受け
たサーバシステムは、１本の映画など情報源の初めから
順方向に実時間で要求を出した受信装置に情報提供を始
める。その場合の品質としては実時間性、低セル廃棄特
性が必要であるから、ＣＢＲのような品質保証が十分な
されるクラスを用いている。一方、その呼の提供と同時
に、非実時間ではあるが、安価なベストエフォート通信
クラス、たとえば、ＡＢＲ、あるいは、ＵＢＲなどを第
２の通信路としてもちいて、実時間提供の必要の無い情
報、例えば、その情報源の最後尾部から時間を遡る方向
に情報を同じ受信装置に配送する。受信装置としては、
ＣＢＲを介して転送されてきた実時間情報はそのまま、
さらに下流に転送する。一方、ベストエフォートで転送
された非実時間情報は、蓄積装置に蓄えていって、実時
間情報と同じ情報まで至った時点で、実時間用の高品質
クラスの呼を解放する。その時点以降の情報は既に蓄積
装置に蓄えられているからＣＢＲでの転送の必要はな
い。

【００２０】つまり、１つの情報源の転送としてみる
と、高品質クラスの呼確保を要求する時間としては、第
２のクラスの通信路によって転送される情報分は不要に
なり、その分は低い通信コストで転送される。

【００２１】特に、第２の情報路をベストエフォートク
ラスとすれば、転送が極めて効率よく行える。すなわ
ち、上記の６ＭｂｐｓのＭＰＥＧ情報通信で考えてみる
と、実時間情報通信路は伝送路の帯域にかかわらず、６
Ｍｂｐｓで転送されなければならない。しかし、非実時
間情報側が使用するベストエフォートクラスでは、ギャ
ランティクラス以外の空いた帯域を無駄なく使用して情
報転送するから、もしも他のユーザからの情報提供要求
がなければ、１５５Ｍｂｐｓ−６Ｍｂｐｓ＝１４９Ｍｂ
ｐｓ分はベストエフォートクラスが使用できる。したが
って、実時間情報側よりも、２０倍以上の帯域で転送す
ることができ、情報の大部分をベストエフォートクラス
で転送することと等価になる。もちろん、他のユーザが
同時に情報提供を要求している場合はこれほどの効率は
でない。一般的には、通信路設計では、大群化効果等、
呼の非同期性など前提に帯域設計を行うが、そこで、帯
域にある一定基準で余裕をもたせている。これが、セル
レベルでの帯域使用効率という点からＡＴＭの運用上で
みると現実的には空き帯域がかなりあると期待できる。
たとえば、セルレベルでの帯域使用効率を５０％でネッ
トワーク設計すれば、残りの５０％はベストエフォート
クラスで使用することができ、ＣＢＲで情報転送するコ
ストと比較するとその半分はベストエフォートクラスの
コストで安価に転送できることになる。

【００２２】また、こういう品質の異なる複数クラスを
用いた多重伝送方式は、特に、ユーザ要求が多重される
サーバ装置に近い大容量伝送路を用いるコアネットワー
クで有効であり、個々の家庭へのアクセスネットワーク
の伝送路では、必ずしも必要ないかもしれない。そうい
う場合は、上記の複数クラスを受信し非実時間情報蓄積
する装置自体は、各家庭、あるいはユーザではなく、コ
アネットワークとアクセスネットワークとの間に置かれ
るヘッドエンドなどの中間装置にもつ機能として提供す
ることにより、ネットワーク全体のコストパフォーマン
スのよいシステムが提供できる。

【００２３】さらに、上記リアルタイムデータを蓄積す
る手段は、リアルタイムデータを複数のデータセグメン
トに分割して管理し、その蓄積容量が飽和状態になった
と見なした場合に、蓄積されているリアルタイムデータ
の最終アクセス時刻からの経過時間と、リアルタイムデ
ータの先頭から各データセグメントの最後までの所用再
生時間とから、各データセグメントの消去順序を決定す
るので、上記リアルタイムデータを蓄積する手段の蓄積
容量が飽和状態になって、アクセス頻度の低いビデオソ
ースを消去する必要が生じても、ビデオ単位で消去する
のではなく、ベストエフォートクラスで伝送するのに適
するビデオソースの先頭から遠い部分から消去し、再度
アクセスがあった場合に上記ＣＢＲ伝送する必要の生じ
る確率を低くすることができる。

【００２４】上述の課題を解決するために、本発明にお
いては、時系列的に順序管理されたリアルタイムデータ
を蓄積する複数のデータ蓄積手段と、該リアルタイムデ
ータを伝送する通信手段と、該リアルタイムデータを受
信して再生する再生手段と、該通信手段の通信資源を管
理し、該データ蓄積手段と再生手段との間に通信路を設
定する通信網資源管理制御手段と、該データ蓄積手段が
蓄積しているリアルタイムデータの種類を管理するとと
もに、該データ蓄積手段が同時に送信可能なリアルタイ
ムデータの数を管理し、要求されたリアルタイムデータ
を送信すべきデータ蓄積手段を決定する蓄積資源管理制
御手段と、ユーザからのサービス要求を受け付け、該通
信網資源管理制御手段と該蓄積資源管理制御手段とから
得た資源状態に基づき、通信網資源管理制御手段および
蓄積資源管理制御手段に対して資源の予約を指示し、選
択された場合に即座に提供可能なリアルタイムデータの
みを選択候補としてユーザに通知するサービス制御手段
とを有し、即座に提供することを保証できるリアルタイ
ムデータをあらかじめユーザに通知し、その中から選択
させることにより、必要とするリアルタイムデータをイ
ンタラクティブに選択するためにユーザが費やした時間
と労力が無駄になるのを防止し、ユーザの利便性の向上
を図るものである。

【００２５】また、上記サービス制御手段は、資源の予
約が選択されたとしても十分な資源の予約が成立してい
ないリアルタイムデータについては、即座に提供するこ
とを保証しない選択候補としてユーザに通知するように
構成してもよい。このように構成することにより、各リ
アルタイムデータを即座に提供することを保証するか否
かをあらかじめユーザに通知し、必要とするリアルタイ
ムデータをインタラクティブに選択するためにユーザが
費やした時間と労力が無駄になるリスクを犯すか否かの
判断をユーザの判断に委ねることにより、ユーザの利便
性の向上を図るものである。

【００２６】

【発明の実施の形態】本発明は、特にＶＯＤのような蓄
積型のデータを実時間でサービスする場合に通信コスト
を低減する方法として有効である。画像提供の要求を受
けたサーバシステムは、１本の映画など情報源の初めか
ら順方向に実時間で要求を出した受信装置に情報提供を
始める。その場合の品質としては、実時間性、低セル廃
棄特性が必要であるから、ＣＢＲのような品質保証が十
分なされるクラスを用いる。一方、その呼の提供と同時
に、非実時間ではあるが、安価なベストエフォート通信
クラス、例えば、ＡＢＲ或いはＵＢＲなどを第２の通信
路として用いて、実時間提供の必要の無い情報、例え
ば、その情報源の最後尾部から時間を遡る方向に情報を
同じ受信装置に配送する。

【００２７】受信装置としては、ＣＢＲを介して転送さ
れてきた実時間情報はそのまま、さらに下流に転送す
る。一方、ベストエフォートで転送された非実時間情報
は、蓄積装置に蓄えていって、実時間情報と同じ情報ま
で至った時点で、実時間用の高品質クラスの呼を解放す
る。その時点以降の情報は既に蓄積装置に蓄えられてい
るからＣＢＲでの転送の必要はない。

【００２８】つまり、１つの情報源の転送としてみる
と、高品質クラスの呼確保を要求する時間としては、第
２のクラスの通信路によって転送される情報分は不要に
なり、その分は低い通信コストで転送される。特に、第
２の情報路をベストエフォートクラスとすれば、転送が
極めて効率よく行える。

【００２９】すなわち、上記の６ＭｂｐｓのＭＰＥＧ情
報通信で考えてみると、実時間情報通信路は伝送路の帯
域にかかわらず、６Ｍｂｐｓで転送されなければならな
い。しかし、非実時間情報側が使用するベストエフォー
トクラスでは、ギャランティクラス以外の空いた帯域を
無駄なく使用して情報転送するから、もしも、他のユー
ザからの情報提供要求がなければ、１５５Ｍｂｐｓ−６
Ｍｂｐｓ＝１４９Ｍｂｐｓ分はベストエフォートクラス
が使用できる。

【００３０】したがって、実時間情報側よりも２０倍以
上の帯域で転送することができ、情報の大部分をベスト
エフォートクラスで転送することと等しいことになる。
もちろん、他のユーザが同時に情報提供を要求している
場合にはこれほどの効率で転送することはできない。一
般的には、通信路設計では、大群化効果等の呼の非同期
性などを前提に帯域設計を行なうが、そこで、帯域にあ
る一定基準で余裕をもたせている。これが、セルレベル
での帯域使用効率という点からＡＴＭの運用上でみると
現実的には空き帯域がかなりあると期待できる。たとえ
ば、セルレベルでの帯域使用効率を５０％でネットワー
ク設計すれば、残りの５０％はベストエフォートクラス
で使用することができ、ＣＢＲで情報転送するコストと
比較するとその半分はベストエフォートクラスのコスト
で安価に転送できることになる。

【００３１】またこういう品質の異なる複数クラスを用
いた多重伝送方式は、特にユーザ要求が多重されるサー
バ装置に近い大容量伝送路を用いるコアネットワークで
有効であり、個々の家庭へのアクセスネットワークの伝
送路では、必ずしも必要ないかもしれない。そういう場
合は、上記の複数クラスを受信し非実時間情報蓄積する
装置自体は、各家庭、あるいはユーザではなく、コアネ
ットワークとアクセスネットワークとの間に置かれるヘ
ッドエンドなどの中間装置にもつ機能として提供するこ
とにより、ネットワーク全体のコストパフォーマンスの
よいシステムが提供できる。

【００３２】以下、図面を参照しながら本発明の実施の
形態を説明する。なお、以下の説明は全て動画像データ
の伝送に関して行なうが、伝送されるデータは必ずしも
動画像に限る必要はなく一般的なリアルタイムデータで
あれば動画像以外のデータ（例えばオーディオデータな
ど）であってもよい。

【００３３】ここで本発明で対象としているのは、デー
タが時系列的に順序管理されているようなデータ、ある
いはより限定していえばそのデータの利用がタイムスタ
ンプなどの時間情報によって管理されているような性質
のデータに関する装置及びシステムであり、本発明では
これらのデータを総括してリアルタイムデータと称して
いる。

【００３４】なお、一般にリアルタイムデータの伝送に
ついてはＭＰＥＧ Ｓｙｓｔｅｍ規格に代表されるよう
な多重化伝送フォーマットにおいてタイムスタンプがつ
けられ、時間管理されている場合が多い。本発明におい
てもこのような場合を想定する。

【００３５】図２は、ＶＯＤシステムの一般的な構成を
示す図である。システムは図に示すように大きく分けて
サーバー１０１、ネットワーク、セットトップユニット
（ＳＴＵ：受信端末）１０４の３つからなる。ネットワ
ークはさらにコアネットワーク１０２とアクセスネット
ワーク１０３に分かれる。

【００３６】図１は本発明に係る情報提供システムの第
１の実施の形態としての動画像伝送システムの構成を示
す図である。図で、コアネットワークとアクセスネット
ワークの間には、例えばＣＡＴＶシステムでいうヘッド
エンドと呼ばれる施設があるような場合を想定してい
る。この場合、ヘッドエンドから先はアクセスネットワ
ーク（ＣＡＴＶ−CAble TeleVision−網）でＳＴＵまで
つながれている。

【００３７】図１において、２０１はビデオソースを蓄
えた蓄積装置で、ビデオソースの先頭から出力するポー
ト２０１ａとビデオソースの最後尾から出力するポート
２０１ｂの２つのポートを有している。各ポートに接続
されている符号２０２、２０３はネットワーク終端装置
であり、ネットワーク終端装置２０２はＣＢＲまたはＶ
ＢＲのように通信品質が保証されたサービスを用いて通
信を行なう。ネットワーク終端装置２０３はＡＢＲまた
はＵＢＲのような通信品質を必ずしも保証しないサービ
スクラスを用いて通信を行なう。これらはコアネットワ
ーク２０４を介してヘッドエンド２１２に接続してい
る。ヘッドエンド２１２のコアネットワーク側のネット
ワーク終端装置が２０５及び２０６である。

【００３８】蓄積装置２０１は１クライアントに対して
論理的に少なくとも２つのポートを提供でき、１つのリ
アルタイムデータストリームに時間的に２点以上からア
クセスすることのできる蓄積装置である（図１ではポー
ト、ネットワーク終端装置、回線が各々２つ書かれてい
るが、これは論理的に２つであることを示すものであっ
て、物理的にはむしろ１つであることも多い。また、時
間的に異なる２点以上からのアクセスはマルチクライア
ントをサポートするサーバーシステムでは通常サポート
されている仕様であり、多くは時分割によるアクセスに
よって実現される）。

【００３９】蓄積装置２０１はポート２０１ａを使って
リアルタイムの動画像データを回線２１３に流す。回線
２１３を流れるサービスはＣＢＲまたはＶＢＲであるの
で、ビットレート、遅延に対してサービス品質が保証さ
れている。このデータはネットワーク終端装置２０５を
通してスイッチ２０９に送られると同時に、ネットワー
ク終端装置２０５においてタイムスタンプが検知され、
検知されたタイムスタンプはストリーム制御回路２０８
に送られる。スイッチ２０９は２入力のうち一方をアク
セスネットワークに乗せ換え、ＳＴＵにサービスが行な
われる。

【００４０】一方、品質を保証しないサービスを用いる
回線２１４では、送れるビットレート、誤り率などが必
ずしも保証されない（ベストエフォート）、蓄積装置２
０１は回線を使ってビデオソースの最後尾からビデオデ
ータを送る。最後尾から送られたビデオデータはネット
ワーク終端装置２０６で必要に応じて誤り訂正または再
送要求を行うなどして誤りのないデータとして蓄積装置
２０７に送られ蓄積される。この際、ネットワーク終端
装置２０６では送られたデータのタイムスタンプを見て
その値をストリーム制御回路２０８に通知する。ここ
で、回線２１４より送られるデータは最後尾より時間を
さかのぼる方向に送られてくるので、タイムスタンプの
値も減少する方向に検知されるはずである。

【００４１】ストリーム制御回路２０８はネットワーク
終端装置２０５、２０６より送られてくるタイムスタン
プを常に監視している。ストリーム制御回路２０８はス
イッチ２０９に対して、常に時間的に早いタイムスタン
プがついている方のストリームを出力するように制御信
号を送る。言い換えると、ネットワーク終端装置２０５
からのタイムスタンプがネットワーク終端装置２０６か
らのタイムスタンプよりも小さい値である場合ネットワ
ーク終端装置２０５からの出力がアクセスネットを通し
てＳＴＵに送られるように、逆の場合蓄積装置２０７か
らの出力がアクセスネットを通してＳＴＵに送られるよ
うに制御信号を送り制御する。並行して、両者の関係が
初めて逆転すると同時に、蓄積装置２０７に制御信号を
送ってネットワークからのデータの蓄積を停止するとと
もに蓄積したデータをタイムスタンプの小さな値が付い
た方から再生するように要求する。この時点でアクセス
ネットを介してＳＴＵに送られる画像データはコアネッ
トワーク経由から蓄積装置２０７経由に切り替えられ
る。切り替えを確認後ストリーム制御回路２０８はネッ
トワーク終端装置２０５、２０６に対してサーバー側と
のコネクションを切断するよう要求を出す。これ以降コ
アネットワークはこのサービスに関しては使用する必要
が無くなるので、ネットワーク資源を別のサービスに振
り向けることができるようになる。

【００４２】図３は全体のビデオソースに対する伝送の
様子を示した図である。図３（ａ）に示したように出力
ポート２０１ａからは長さＴのストリームの先頭から、
ポート２０１ｂからは最後尾から出力する。図３（ｂ）
は同じストリームをネットワーク終端装置２０５からく
るストリームと２０７からくるストリームに分けたもの
である。図でタイムスタンプ値がＴ０の時に両者のタイ
ムスタンプ値の大小関係が逆転し、スイッチ２０９から
の出力が切り替わる。但しこの場合、図に示したよう
に、切り替えを完全にＴ０の時点で行なうのではなく少
しマージンを持たせた方がよい（図の重なりの部分）。
この場合、Ｔ０からしばらくの間は両方のストリームが
同方向に再生されるが、この両者が完全に同期したこと
を確認した時点でスイッチを切り替えるように制御すれ
ば、切り替えによる不連続が生じることなく自然にスト
リームの切り替えが行なわれる。

【００４３】また、上述の説明における最後尾からのア
クセスとは、必ずしもビットごとの逆転を意味するもの
ではなく、何らかの単位ごとに最後尾からデータを取っ
てくることを意味するものである。蓄積した後に逆順で
読み出しを行なうので、蓄積装置２０７において逆順の
読み出しを行なったときにもとのデータを順方向から読
み出したのと同じようにビットが並ぶようにする必要が
あり、これを実現するのが容易な単位は蓄積媒体の種類
に依存する。例えば、蓄積装置にハードディスクを使用
している場合、アクセスの単位はトラックになるので、
この単位で後ろから読み出してきて伝送することなどが
考えられる。

【００４４】以上の説明ではポート２０１ｂから伝送す
るソースは最後尾からとして説明したが、長いソースの
場合必ずしも最後尾でなくてもよく、全体を何分割かし
て各分割に対して上記のような処理を行なってもよい。
この場合、上記で説明したストリームの切り替え、コネ
クションの設定、切断が分割の回数だけ繰り返されるこ
とになる。

【００４５】また、以上の説明は蓄積装置に蓄えられる
データは実時間で再生されるデータと同時に送信される
実施例であったが、ここに蓄えられるデータは必ずしも
同時に送信されるのではなくあらかじめ蓄えられている
場合も考えられる。これは例えば蓄積装置を複数のクラ
イアントで共有する場合であって、別のクライアントが
既に見た番組をアクセスする場合に前のクライアントの
ために蓄えられたデータが既に蓄積装置内にあり、再利
用できるような場合などである。

【００４６】また、以上の説明ではヘッドエンドに蓄積
装置を配置した第１の実施の形態につき説明したが、図
４に示す第２の実施の形態のように図１の構成要素２０
５〜２０９の構成をそのままＳＴＵに配置しても同じ主
旨の発明を実施することが可能である（動作の説明は図
１の第１の実施例の場合と同様のため省略する）。この
場合、ＳＴＵを使用するクライアントがビデオソースよ
りも短い時間でコネクションを切断できることになり、
ＣＢＲのコネクションよりもＡＢＲのコネクションの方
が伝送単価が安い場合、サービスを受けるユーザのコス
トを下げることができる。

【００４７】構成のみを簡単に説明すると、図４に示
す、第２の実施の形態に係る情報提供システムは、動画
像データを蓄積しているサーバ４００と、コアネットワ
ーク４０４と、アクセスネットワーク４１０と、セット
トップユニット（ＳＴＵ）４１１と、を備えている。前
記サーバ４００は、ポート４０１ａ及び４０１ｂを有す
る蓄積装置４０１と、ポート４０１ａと回線４１３との
間に設けられるネットワーク終端装置４０２と、ポート
４０１ｂと回線４１４との間に設けられるネットワーク
終端装置４０３と、を備えている。前記セットトップユ
ニット（ＳＴＵ）４１１は、回線４１３及び４１４にそ
れぞれ接続されるネットワーク終端装置４０５及び４０
６と、ネットワーク終端装置４０６を介して供給される
動画像データを蓄積する蓄積装置４０７と、回線４１３
及び４１４を介して供給されるデータのタイムスタンプ
（Ｔ・Ｓ）をそれぞれ検知して時間的に早いタイムスタ
ンプ（Ｔ・Ｓ）のついている方のデータストリームを出
力するようにスイッチ４０９に切換信号を出力すると共
に蓄積装置４０７に蓄積を停止する制御信号を出力する
ストリーム制御回路４０８と、ネットワーク終端装置４
０５からのデータと蓄積装置４０７からのデータとをス
トリーム制御回路４０８の切換信号により切換えるスイ
ッチ４０９と、そして、スイッチ４０９により切換えら
れて順次供給されるデータを復号するデコーダ４１２
と、を備えている。

【００４８】また、以上の説明においては、クライアン
トが特殊再生を要求した場合についての対応が説明され
ていなかったが、特殊再生のうち早送り、スロー再生、
ポーズについては従来の場合と同様問題なく対応でき
る。問題となる可能性のあるのは出力が蓄積装置に切り
替わった後の逆転再生（高速、スローを含む）とランダ
ムアクセスである。これに対応する方法としては、
（１）上記の要求が出た時点で品質が保証されているサ
ービス側の回線を再発呼し、サーバーからのサービスを
再スタートする。（２）実時間再生している方のデータ
も蓄積装置に蓄積し、ここに蓄積されたデータで対応す
る等が考えられる。

【００４９】また、別の適用環境として、サーバーとヘ
ッドエンド間のコアネットワークに通信品質が保証され
た回線が専用線のように永続的に設定されている場合に
も本発明は有効に作用する。例えば、コアネットワーク
に複数のＣＢＲ回線（またはＶＢＲ回線）を（半）永続
的に設定し、それを複数のビデオデータが共用して使用
する構成を考える。本発明では、サーバーからコアネッ
トワークにて転送されるビデオデータは、ヘッドエンド
を経由してＳＴＵへそのまま再生する即時データと、ヘ
ッドエンドの蓄積装置に一時的に蓄積される一時記憶デ
ータの２種類がある。一時記憶データは、例えばビデオ
データの最後尾部から時間を遡る方向に転送されるデー
タである。従来は複数のＣＢＲ回線を即時データのみが
共用していた。このときビデオデータ転送要求の発生に
対して十分高い確率で空きＣＢＲ回線を得るために、複
数のＣＢＲ回線の利用率をある程度低くしておく必要が
あった。これではＣＢＲ回線の本来の転送能力を十分に
生かしているとはいえなかった。

【００５０】本発明では、ビデオデータの時間的に先行
する部分を一時記憶データとして従来使用していなかっ
た空きＣＢＲ回線を利用してヘッドエンドに転送すると
いう使用法に適用することも可能である。すなわち、ヘ
ッドエンドの蓄積装置はそのビデオデータを一時的に蓄
積する。即時データとしてＳＴＵへ転送しているビデオ
データと同じものを蓄積装置が再生できるとわかった
ら、即時データが使用しているＣＢＲ回線を空きに戻
し、ＳＴＵには蓄積装置から再生したビデオデータを伝
送する。この様に本発明は即時データがＣＢＲ回線を使
用する割合を低下させることができるわけである。この
場合、一時記憶データよりも即時データのＣＢＲ回線使
用の優先度を高く設定するとより効果が得られる。新た
なビデオデータ転送の要求があった時、空きＣＢＲ回線
が無ければ一時記憶データが使用しているＣＢＲ回線の
利用を中断し、代わりに即時データがその回線を使用す
るわけである。このようにしてもＳＴＵにて再生される
ビデオデータの品質が悪化することはなく（一時的に即
時データで転送するビデオデータの割合が高くなるだけ
である）、再び空きＣＢＲ回線が発生した場合に一時記
憶データの転送を再開すれば良い。

【００５１】次に、図５により蓄積手段２０７の読み出
しレートにつき説明する。ここでは前述したようにＡＶ
多重方式としてＭＰＥＧシステムを想定しているが、Ｍ
ＰＥＧシステムで多重されたビットストリームには、符
号化ソースが持つクロックを使ってクロック参照情報が
書き込まれている。理想的には符号化ソースが想定して
いる伝送ビットレートで蓄積手段２０７を読み出すべき
である。これを実現するために通常は図５のような構成
でローカルに符号化ソースのクロックを再生し、そのク
ロックを元に読み出しを行う。図５で、５０１は物理媒
体としての蓄積手段である。ここに蓄積されたデータを
読み出してクロック参照情報読み出し手段５０２でＭＰ
ＥＧシステムの解読を一部行いクロック参照情報読み出
す。クロック参照情報はソースクロックで動作するカウ
ンタ値をサンプルとしたものである。この情報はカウン
タ５０４と電圧制御発振器（以下、ＶＣＯ−Voltage Co
ntrolled Oscilator−という）５０３、低域通過フィル
タ５０５、減算器５０６よりなるフェーズロックループ
（以下、ＰＬＬ−Phase Locked Loop −という）に送ら
れる。動作開始時にまずカウンタにクロック参照情報が
カウンタの初期値としてセットされる。カウンタ５０４
はＶＯＣ５０３のクロックで動作するカウンタで、その
出力はクロック参照情報が読み出される度に減算器５０
６でクロック参照情報との差分がとられ差分は低域通過
フィルタ５０５を経てＶＣＯ５０３に入力される。この
動作によりＶＣＯは符号化ソースのクロックにロックし
て安定したときに差分が０となるようになる。このよう
にして符号化ソースのクロックがローカルに回復され、
このクロックに基づいて蓄積手段５０１のデータが読み
出される。ちなみに蓄積装置２０１のポート２０１ａ側
の読み出しも基本的にはこれと同じ動作である。読み出
されたデータはスイッチ２０９、図示されていないアク
セスネットワーク側のインタフェースを経て伝送される
が、アクセスネットワーク側の伝送クロックはスイッチ
２０９の切り替えによっても不変であり、更に一般にこ
のクロックは符号化ソースが持つクロックとは独立のク
ロックである。図４の第２の実施の形態では同様の動作
でもよいし、蓄積装置４０７はローカルであり読み出し
レートはデコーダ４１２にとって制御可能であるので、
スイッチ４０９を蓄積装置４０７に切り替えた後はロー
カルなデコーダのクロック（スイッチ切り替え前は上述
の方法で符号化ソースのクロックに同期していたもの）
が自走して動作するようにしても特に問題はない。

【００５２】次に図６により本発明において更に機能を
追加した場合の第３の実施の形態を説明する。本実施の
形態も図２、図４のように蓄積手段が存在する位置で２
つのバリエーションがあり得るが、簡単のためここでは
図４と同じ蓄積装置がＳＴＵ側にある場合の構成につい
てのみ説明する。基本的な動作は図４の実施の形態と同
様なので、動作が同じ部分の説明は省略する。

【００５３】蓄積装置６０１は、ビデオソースの先頭か
ら出力するポート６０１ａとビデオソースの最後尾から
出力するポート６０１ｂの２つのポートを持っている。
この実施例ではネットワーク終端装置６０２はＣＢＲ、
６０３はＵＢＲ（またはより一般的にはインターネット
のようなベストエフォートサービスを行う独立した回線
などでもよい。）を使って通信すると想定している。

【００５４】通信開始時にＳＴＵ側の通信制御手段６２
１はサーバー側の通信制御手段６１７に対して蓄積装置
６０７の使える容量を申告する。実際にネットワーク終
端装置６０３側を通って伝送されるデータの量はデータ
量カウント手段６１５でカウントされ、この値が申告さ
れた値と等しくなったら、蓄積手段６０７はいっぱいで
あると判断して、データ量カウント手段６１５は出力ポ
ート６０３からの先行データの伝送を停止するように蓄
積手段６０１、ネットワーク終端装置６０３に制御信号
を送る。

【００５５】これとは別に、通信開始時にＳＴＵ側は通
信モードとして出力ポート６０１ａのみを使った通信と
出力ポート６０１ａ及び６０１ｂを使った通信のどちら
かを選択できる。これは、コンテンツの内容によって先
送りが有効な場合とそうでない場合があるからである。
例えば、映画のように継続時間が長く最初から最後まで
見られる可能性の高いコンテンツの場合先送りは有効で
あるが、スポーツの結果、とりわけ相撲などのように短
い時間ごとに独立した内容が数多く集まって全体を形成
しているようなコンテンツの場合、先送りをした部分が
見られず捨てられてしまうかもしれず先送りがかえって
コスト高になる可能性もある。このようなコンテンツに
対してはＣＢＲの伝送のみにすることができるように、
通信開始時（コンテンツ選択時）に通信制御手段６２１
と６１７の間でその選択信号をやりとりする。あるいは
サーバー側でコンテンツとモードの対応をあらかじめ設
定するようにしてもよい。

【００５６】さて、ＵＢＲあるいはより一般的なインタ
ーネットのような回線では、誤りに対する保証がない。
そこでこのサービスを利用する回線ではサーバー側の誤
り検出符号化手段６１６で誤り検出符号を付加し、ＳＴ
Ｕ側の誤り検出手段６２０で誤りを検出、誤りが検出さ
れた伝送単位については通信制御手段６２１を介して再
送を要求するようにすることも有効である。図２、図４
の実施例ではそのようなことは行っていないので、誤り
はデコーダでコンシールされることが想定されている。
ビデオのデコーダはデコーダレベルで存在し得ないビッ
トの並びなどの誤りを検出すると前のフレームの画像を
出力するなど誤りを隠すように動作するものがあるた
め、誤りがあるままでも動作が大きく破綻することはな
いが、再送により誤りを正しておいた方が品質は向上す
る。オーディオについては誤りの影響はいっそう顕著で
ある。誤り検出の代わりに誤り訂正を行ってもよいが、
ＵＢＲで伝送するデータは実時間では再生しないので、
検出と再送とを行なうのみで十分である。

【００５７】本実施の形態ではＳＴＵの中に蓄積装置６
０７があり、伝送されたリアルタイムデータの一部が蓄
積装置に残って後からでもアクセス可能になる点が著作
権の関連で好ましくないこともあり得る。このため、蓄
積手段６０７はコンテンツの終わりを表す符号を検出す
る手段６２２を具備し、この符号を検出した後自動的に
蓄積内容を消去するようにしてもよい。

【００５８】また、別の実現形態では、画像提供の要求
を受けたサーバシステムは、１本の映画などを、必ずし
も実時間性は保証されないが最低データ伝送レート、低
セル廃棄特性が保証されるＡＢＲの通信路をもちいて情
報源の初めから順方向に伝送する。この際、最低限保証
されるデータ伝送レートを映画などをリアルタイムで再
生するのに十分な再生伝送レートになるようにして伝送
する。これにより再生伝送レートを最低限確保し、帯域
に余裕があれば更にそれ以上の伝送レートで伝送するこ
とが可能になる。帯域の余裕により先行して伝送された
リアルタイムデータは、送信手段と再生手段の間にある
ＦＩＦＯに滞留し、再生に必要になる時点で引き抜かれ
る。これはＦＩＦＯからの出力を再生伝送レートと一致
させることにより実現される。この場合、転送に使われ
る通信路は全体がベストエフォートクラスであり、全体
をＣＢＲで伝送するのと比較して低い通信コストで実現
される。

【００５９】次に図７を用いて本発明に係る第４の実施
の形態を説明する。本実施の形態も図２、図４のように
蓄積手段が存在する位置で２つのバリエーションがあり
得るが、簡単のためここでは図４と同じ蓄積装置がＳＴ
Ｕ側にある場合の構成についてのみ説明する。本件も図
４の実施例と同様の動作をする部分の説明については省
略する。

【００６０】本実施の形態ではＡＢＲのサービスクラス
を提供する回線７１３一本のみでリアルタイムデータを
伝送する。ＡＢＲでは最低限保証される伝送レート（Ｍ
ｉｎＲと表す）とピークレート（ＰｅａｋＲと表す）等
のパラメータを申告して通信を行う。すなわちＭｉｎＲ
の帯域を最低限確保した上で帯域に余裕があれば最大Ｐ
ｅａｋＲまでの伝送レートが得られる。そこで今送ろう
とするリアルタイムデータをリアルタイムで再生するた
めの伝送レートをＲｒとすると、Ｒｒ≦ＭｉｎＲとなる
ように申告して伝送すれば受信側にデータが必要な時刻
よりも遅れて到着することは起こらない。この方法で図
の先入れ先出し情報蓄積手段（以下、ＦＩＦＯ−Ｆｉｒ
ｓｔ‐ｉｎ Ｆｉｒｓｔ‐ｏｕｔ−という）７０７の入
り口までリアルタイムデータを伝送する。ＦＩＦＯ７０
７の出力の読み出しレートは図５で説明した原理により
決定し、Ｒｒの速度で読み出してデコーダ７１２に入力
し、リアルタイムで再生される。ＦＩＦＯ７０７には実
際の伝送レート「−Ｒｒ」の積分値が蓄積されていく。
最終的に送信側でデータを全部送り終わった時点で残っ
ているこの積分値のデータは、ネットワーク帯域の余裕
により送ることができた分であり、本質的にこの分をＣ
ＢＲで伝送するのに比べて安い伝送コストで送ることが
できる。ＦＩＦＯ７０７に蓄積されたデータ量は蓄積デ
ータ量監視手段７２２により監視されており、この蓄積
データ量を基に通信制御手段７１８，７１７を介した制
御信号により送信側のＭｉｎＲを越える伝送レートの範
囲について制御される。これは、ＦＩＦＯ７０７の容量
が有限で送信されるリアルタイムデータの最大値全部を
蓄積する容量（＝Ｔ（１−ＭｉｎＲ／ＰｅａｋＲ）、
Ｔ：全データ量）に満たない場合に、ＦＩＦＯ７０７が
オーバーフローしないようにするためである。一番簡単
な方法は、ＦＩＦＯ７０７がある値Ｔｈ１になった時点
以降は送信側の伝送レートをＭｉｎＲとするように制御
するものである。この様子を図８に示す。Ｔｈ１は以下
の関係から求められる。

【００６１】 Ｆ＝Ｎ／ＭｉｎＲ＊（ＭｉｎＲ−Ｒｒ）＋Ｔｈ１ Ｎ＝Ｔ−Ｒｒ＊ｔ−Ｔｈ１ ただし、Ｆ：ＦＩＦＯの容量 ｔ：今までの再生時間 Ｎ：送信側に残っているデータ量 また、ＡＢＲは必ずしも遅延に対する保証をしてくれな
いので、遅延に対するモデル化を行うなどにより確率的
に発生しても許容される遅延量Ｄを求め、Ｔｈ２＝Ｄ＊
ＲｒだけＦＩＦＯ７０７にデータがたまった後ＦＩＦＯ
７０７以降の部分の動作を開始するようにしてＦＩＦＯ
７０７のアンダーフローの確率を許容範囲内におさえる
ことが有効である。

【００６２】また、オーバーフローについては、現状で
はサポートされていないが将来シグナリングにより呼を
接続したまま帯域を変更することができるようになれ
ば、その機能を利用することも有効である。

【００６３】以下、図面を参照して本発明の第５の実施
の形態を説明する。

【００６４】以上説明した種々のバリエーションのうち
特にネットワーク内に蓄積手段を有する図２などの情報
提供システムにおいては、上記ビデオデータの蓄積装置
の持つ蓄積容量は有限であるため、蓄積容量が飽和状態
に達した場合には、新たなビデオデータを蓄積するため
に古いビデオデータを消去する必要が生じる。この場
合、各ビデオデータを複数のセグメントに分割して管理
しておき、各ビデオデータの最終アクセス時刻からの経
過時間と各セグメントのビデオデータの先頭からの所用
再生時間とから、各セグメントの消去順序を決定し、上
記ベストエフォートクラスでの伝送に適するセグメント
から優先的に消去することによって、再度同じビデオソ
ースへのアクセスがあった場合に、上記ＣＢＲ回線によ
る伝送の必要性を低下させ、通信リソースのさらなる有
効利用が図れる。この場合、ベストエフォートクラスで
の伝送に適するセグメントを優先する消去順序の決め方
は、例えば以下のようにすれば良い。

【００６５】今、ビデオソースｉの最終アクセス終了時
刻からの経過時間をｔｉとし、ビデオソースｉの先頭か
らｊ番目のセグメントの最後までの所要の再生時間をＴ
ｉｊとする。このとき、ビデオソースｉのセグメントｊ
の優先度Ｐｉｊを Ｐｉｊ＝ｔｉ×Ｔｉｊ で与え、Ｐｉｊの値の大きい順に消去する。図９はこの
様子を示したもので、縦軸は最終アクセス終了時刻から
の経過時間、横軸はビデオソースの先頭からセグメント
の最後までの所用再生時間を表し、４つのビデオソース
が蓄えられている場合を示している。各ビデオソースは
複数のセグメントに分割されており、その長さは必ずし
も等しくはない。図９では１つのビデオソースに含まれ
るセグメントの長さは等しく描かれているが、必ずしも
等しい必要はない。各セグメントの中に示された数字は
Ｐｉｊの値を表し、各セグメントの上に括弧付きで示さ
れた数字は消去順序を表している。即ち、最終アクセス
終了時刻からの経過時間の長いビデオソースほど、また
各ビデオソースの先頭から遠いセグメントほど、優先的
に消去されることが分かる。図９では、同じＰｉｊの値
を持つセグメントがあった場合、先頭からの所用再生時
間の大きいセグメントが優先されているが、これは一例
であって最終アクセス終了時刻からの経過時間の大きい
セグメントを優先しても構わない。上記のように各セグ
メントの消去順序を決めることにより、消去され始めた
ビデオソースが再度アクセスされた場合でも、ＣＢＲ回
線を使用することなく、ベストエフォートクラスのみで
消去されたセグメントの再送を行えば良いので、通信コ
ストの低減が図れる。

【００６６】また、上記ビデオソースｉのセグメントｊ
の優先度Ｐｉｊの計算は、消去を行う必要が起きる度に
行う必要があり、計算にはある程度の時間を必要とする
ので、蓄積容量の空きがある値以下になった場合にＰｉ
ｊを計算しセグメントの消去を行って、ある値以上の空
き容量を常に確保しておくことが望ましい。

【００６７】図１０は、ＶＯＤシステムの一般的な構成
を示す図である。このシステムは、図に示すように大き
く分けてサーバ、ネットワーク、セットトップ（ＳＴ
Ｕ：受信端末）の３つからなる。サーバはさらにセンタ
ーサーバ９０１とローカルサーバ９０３及び９０４とに
分かれ、ネットワークはさらにコアネットワーク９０２
とアクセスネットワーク９０５及び９０６とに分かれ
る。アクセスネットワーク９０５及び９０６は、例えば
一定数の加入者のいる地域ごとに設けられる加入者収容
のための網であり、コアネットワーク９０２は、複数の
アクセスネットワーク９０５及び９０６を相互接続する
広域ネットワークである。また、一般にローカルサーバ
９０３及び９０４はアクセス頻度が高いと予想されるビ
デオソースを蓄積し、一定の加入者のいる地域ごとに配
置され、センターサーバ９０１はアクセス頻度が低いと
予想されるビデオソースを蓄積し、ユーザから比較的遠
いセンターに配置され、高速広帯域のコアネットワーク
９０２を経由してアクセスされる。ＨＦＣ（Ｈｙｂｒｉ
ｄ Ｆｉｂｅｒ Ｃｏａｘ）と呼ばれるＣＡＴＶシステ
ムを例にとって言えば、ＳＴＵ９０７ないし９１０とツ
リー状に繋がった同軸ケーブルによるＣＡＴＶ網がアク
セスネットワークを構成し、光ファイバー網で構成され
るコアネットワーク９０２とアクセスネットワーク９０
５及び９０６との接続点に設置されたヘッドエンド（Ｈ
Ｅ）を少なくとも一つ包含する地域毎にローカルサーバ
９０３及び９０４を配置し、光ファイバー網の比較的遠
方にセンターサーバが配置される。

【００６８】図１１は、本発明に係るＶＯＤシステムの
第５の実施の形態の構成を示す図である。図１１で、１
００１は比較的アクセス頻度の低いビデオソースを蓄え
たセンターサーバ、１００５、１００６は比較的アクセ
ス頻度の高いビデオソースを蓄えたローカルサーバで、
コアネットワーク１００２に通信路１０１４、１０１
５、１０１６により、サーバリソース管理制御装置１０
０３へ各サーバのリソース状態を通知するとともに、サ
ーバリソース管理制御装置１００３の指示によって通信
路１０１９を介してユーザ端末の接続されたＳＴＵ１０
１０へのビデオ送信を行う。各サーバのリソース状態に
は、各サーバの蓄えているビデオソースの種類、各ビデ
オソースへの同時アクセス数、各サーバのサービス中の
ユーザ数などが含まれる。同一のビデオソースへの同時
アクセス数やサーバごとの同時サービス可能なユーザ数
には上限が存在するので、既にこの上限に達している場
合には新たなサービス要求を受け付けることはできな
い。サーバリソース管理制御装置１００３は、サーバリ
ソース状態を通信路１０１７を介してサービス制御装置
１００７に通知する。通信路１０１９はネットワークリ
ソース管理制御装置１００４により設定される。ネット
ワークリソース管理制御装置１００４は、コアネットワ
ーク１００２に含まれる伝送路の帯域や交換ノードのバ
ッファ量などの通信網資源を管理、制御している。伝送
路の帯域や交換ノードのバッファ量には上限が存在する
ので、既にこの上限に達している場合には新たな通信路
を設定することはできない。前記ネットワークリソース
管理制御装置１００４は、ネットワークリソース状態を
通信路１０１８を介してサービス制御装置１００７に通
知する。

【００６９】新たにＶＯＤサービスを受けようとするユ
ーザ１０１０は、シグナリング手段を用いてネットワー
ク管理制御装置１００４に要求を出し、サービス制御装
置１００７との間に通信路１０２０を設定してもらい、
サービス制御装置１００７に対して、新たなＶＯＤサー
ビスの開始を要求する。サービス制御装置１００７は、
ローカルサーバ１００５、１００６、センターサーバ１
００１のそれぞれとユーザ１０１０との間にビデオ伝送
のための通信路を設定可能か否かを判断し、設定可能な
サーバとの間の帯域予約を通信路１０１８を介してネッ
トワーク管理制御装置１００７に対して行う。この場
合、ビデオ伝送のために必要な帯域としては、サーバ上
に等しいビット速度で符号化されたビデオソースのみが
蓄積されている場合はそのビット速度に相当する帯域
を、サーバ上に異なるビット速度で符号化されたビデオ
ソースが混在して蓄積されている場合は最低速度に相当
する帯域以上最高速度に相当する帯域以下で、最も大き
い帯域を確保する。異なるビット速度のビデオソースが
混在し、最高速度に相当する帯域まで帯域が確保できな
かった場合は、確保できた帯域を超えるビットレートの
ビデオリソースは提供不可能となる。サービス制御装置
１００７は、さらに帯域予約ができたサーバのリソース
状態から、ユーザからの要求があれば即座に提供可能な
ビデオソースを選択し、サーバリソース予約を通信路１
０１７を介してサーバリソース管理制御装置１００３に
対して行う。

【００７０】サービス制御装置１００７は、ネットワー
クリソースとサーバリソースの両方が確保できたビデオ
ソースについては即座に提供可能として、ネットワーク
リソースかサーバリソースかの少なくとも一方が確保で
きないビデオソースについては提供不可能として、リソ
ース予約処理途中のビデオソースについては即座に提供
可能か否か保証できないビデオソースとしてそれぞれ識
別し、それに基づいて選択候補をユーザ１０１０に通信
路１０２０を介して通知する。この場合の通知方法とし
ては、文字によるビデオタイトル一覧であっても、ビデ
オ内容を示すグラフィック表示やアイコン表示、あるい
はそれらの組み合わせであってもよく、その形式には全
く依存しない。ユーザ１０１０は、サービス管理制御装
置１００７から通知された選択候補から希望のビデオソ
ースを選択し、通信路１０２０を介してサービス制御装
置１００７に通知する。サービス制御装置１００７は、
ユーザの選択したビデオソースを提供すべきサーバ（例
えばローカルサーバ１００５）を決定し、ローカルサー
バ１００５とユーザ１０１０との間にビデオ伝送のため
の通信路１０１９の設定を、通信路１０１８を介してネ
ットワークリソース管理制御装置１００９に指示する。
ネットワークリソース管理制御装置１００４が通信路１
０１９の設定完了を通信路１０１８を介して通知してく
ると、サービス制御装置１００７はローカルサーバ１０
０５の通信路１０１９によるユーザ１０１０へのビデオ
伝送開始を、サーバリソース管理制御装置１００３に通
信路１０１７を介して指示する。サーバリソース管理制
御装置１００３は、ローカルサーバ１００５に対して通
信路１０１９によるユーザ１０１０へのビデオ伝送開始
を指示し、ローカルサーバ１００５がビデオの伝送を開
始する。ビデオ送信中の巻き戻し、早送り、あるいは一
時停止などの特殊再生は、通信路１０１９を介してユー
ザ１０１０とローカルサーバ１００６との間で直接やり
とりされ、制御される。

【００７１】ここで、サービス制御装置１００７がユー
ザ１０１０に対して、ネットワークリソースとサーバリ
ソースの両方の予約のできたビデオソースを即座に提供
可能な選択候補として通信路１０２０を介してユーザ１
０１０に通知する場合には、それらの選択候補のいずれ
をユーザが選択したとしても即座に提供可能であるた
め、ユーザが選択してから拒絶される可能性がなく、ユ
ーザは確実なサービスを受けることが可能となる。

【００７２】また、サービス制御装置１００７がユーザ
１０１０に対して、リソース予約の処理途中のビテオソ
ースを即座に提供可能か否かを保証しない条件付き選択
候補としてユーザ１０１０に通知する場合には、これら
の条件付き選択候補をユーザが選択したとすると、リソ
ースが確保できずにサービスを拒絶される可能性がある
が、ユーザにとっては選択肢の数が増えるメリットがあ
り、しかもサービス拒絶のリスクをあらかじめ知ること
ができるので、万一拒絶された場合にも納得性が高い。

【００７３】また、サービス制御装置１００７がユーザ
１０１０に対して、現在提供不可能なビデオソースを選
択不可能な選択候補として通知する場合には、ユーザに
とっては見たいビデオソースがサービスメニューに存在
することを認識でき、暫く待つなどの判断基準を得られ
るというメリットがある。

【００７４】また、サービス制御装置１００７が予約し
たリソースの内、ユーザの選択したビデオソースを提供
するために必要なリソースのみを確保し、不要となった
リソースを解放する場合には、実際のビデオ伝送には不
要な帯域を別のユーザへのサービスに再利用可能とな
り、ネットワークリソースの有効利用を図ることが可能
となる。この場合、ユーザが選択したビデオソースの一
部、あるいは選択したビデオソースのハイライトシーン
を集めたプロモーションビデオなどのプレビューを行う
ときには、通信路の予約されたネットワークリソースを
使用して通信路の設定は行うが、ユーザがそのビデオソ
ースを見ることを確定するまでは、残りのネットワーク
リーソスを解放は行わないようにする。ユーザがプレビ
ューしたビデオソースを見ることを決定し、例えば課金
の開始を承諾する操作を行った場合にはじめて残りのネ
ットワークリソースを解放する。もし、ユーザがプレビ
ューしたビデオソースが気に入らなかった場合には、設
定された通信路を解放するものの、帯域の予約はもとの
状態に戻す。

【００７５】また、ユーザが即座に提供することを保証
できないビデオソースを選択した場合に、サービス制御
装置１００７が要求されたビデオソース提供に必要なビ
デオリソースとネットワークリソースの確保を行い、そ
れらリソースの確保ができた場合には不要となった残り
のリソースを解放し、それらリソースの確保ができなか
った場合にはそのビデオソース提供の拒絶を通知するこ
とで、ユーザ自身のリスクで選択の幅を広げることが可
能となる。

【００７６】一方、サービス制御装置１００７がアクセ
スしているユーザ数よりも少ない人数分だけのリソース
を、リソース不足の起こる確率がある値以下になるよう
に予約することによって、リソースの利用効率の向上を
図ることができる。１人のユーザは最終的には１つのビ
デオソースを選択するので、残りのリソースは最終的に
は使われないことになる。今１０４人のユーザが同時に
アクセスしている場合を考える。ローカルサーバにはア
クセス頻度の高いビデオソースを置くと考えられるの
で、各ユーザがローカルサーバ上にあるビデオソースを
選択する確率が仮に８０％とすると、アクセスしている
１０４人全員がこのローカルサーバのビデオソースを選
択する確率は約８．３×１０^-11 となる。従って、例え
ば１０３人分のリソースしか予約しなくても、リソース
が不足する確率は１０^-10 以下となる。同様に、アクセ
ス頻度の低いビデオソースを蓄積しているセンターサー
バ上のビデオソースが選択される確率を２０％とする
と、１５人のユーザに対して１４人分のリソースを確保
すれば、リソースが不足する確率を１０^-10 以下にする
ことができる。これは大群化効果と呼ばれる現象で、多
くの人がランダムに選択する場合に、人数よりも少ない
リソースを予約するだけで、リソース不足が起こる確率
をある値以下にすることができ、リソースの効率的運用
が可能となる。特に、アクセス頻度の低いセンターサー
バに対するリソース確保において、大幅な効率向上が期
待できる。

【００７７】次に、サービス制御装置１００７がユーザ
１０１０に対して、ネットワークリソースとサーバリソ
ースの両方について、リソース不足の起こる確率がある
値以下になるように予約したビデオソースを、即座に提
供可能な選択候補として通信路１０２０を介してユーザ
１０１０に通知する場合には、それらの選択候補のいず
れをユーザが選択したとしても即座に提供不可能な確率
はある値以下であるため、ユーザが選択してから拒絶さ
れる可能性が低く、ユーザは確実なサービスを受けるこ
とが可能となる。

【００７８】一方、サービス制御装置１００７がユーザ
１０１０に対して、リソース予約の処理途中のビデオソ
ースを即座に提供可能か否かを保証しない条件付き選択
候補としてユーザ１０１０に通知する場合には、それら
の条件付き選択候補をユーザが選択すると、リソースが
確保できずにサービスを拒絶される可能性がある。しか
し、ユーザにとっては選択肢の数が増えるメリットがあ
り、しかもサービス拒絶のリスクをあらかじめ知ること
ができるので、万一拒絶された場合にもユーザはサービ
スが拒絶されたことを納得する可能性が高い。

【００７９】また、サービス制御装置１００７がユーザ
１０１０に対して、現在提供不可能なビデオソースを選
択不可能な選択候補として通知する場合には、ユーザに
とっては見たいビデオソースがサービスメニューに存在
することを認識でき、暫く待つなどの判断基準を得られ
るというメリットがある。

【００８０】以上、本発明について具体的な例をあげて
説明してきたが、本発明はこれらの例に限定されるもの
ではなく、サーバはセンターサーバ、ローカルサーバの
２階層構成で説明したが、３階層以上の多階層構成であ
ってもよい。また、センターサーバ、ローカルサーバ、
サーバリソース管理制御装置、ネットワークリソース管
理制御装置、サービス制御装置、ヘッドエンドがそれぞ
れ別々にコアネットワークに収容されている例で説明し
たが、これらの装置のうちの２つ以上の組み合わせが物
理的に一つの装置としてコアネットワークに接続され、
通信路を介さずに互いに通信し合える構成であっても構
わない。さらに、上記説明ではビデオの伝送に必要な帯
域が、ビデオソースによらず等しい場合について説明し
たが、ビデオソースごとに伝送に必要な帯域が異なって
いても構わないことは言うまでもない。

【００８１】

【発明の効果】上述してきたように、本発明によればリ
アルタイムデータの伝送にあまり適さないベストエフォ
ートサービスクラスをリアルタイムデータの伝送に有効
に利用することができるようになり、通信の効率を向上
させ、サービス実現のためのコストを低減することがで
きるようになる。

【００８２】また、本発明によれば、即座に提供するこ
とを保証できるリアルタイムデータのみをあらかじめユ
ーザに通知し、あるいは、各リアルタイムデータを即座
に提供することを保証するか否かをあらかじめユーザに
通知し、必要とするリアルタイムデータをインタラクテ
ィブに選択するためにユーザが費やした時間と労力が無
駄になるのを防止することにより、あるいは、そのリス
クを犯すか否かの判断をユーザの判断に委ねることによ
り、ユーザの利便性を高めることができる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係る情報提供装置
を説明するブロック図である。

【図２】一般的なＶＯＤシステムの構成例を説明する図
である。

【図３】情報ストリームと時間の関係を説明する図であ
る。

【図４】本発明の第２の実施の形態に係る情報提供装置
を示すブロック図である。

【図５】蓄積手段からの読み出しビットレートの決定に
つき説明する図である。

【図６】本発明の第３の実施の形態に係る情報提供装置
を示すブロック図である。

【図７】本発明の第４の実施の形態に係る情報提供装置
を示すブロック図である。

【図８】図７の第４の実施の形態の蓄積容量と制御につ
き説明する図である。

【図９】本発明の第１ないし第４の実施の形態において
データ蓄積手段での消去順序の決め方を説明する図であ
る。

【図１０】一般的なＶＯＤシステムの構成例を説明する
図である。

【図１１】本発明の第５の実施の形態を説明する図であ
る。

【符号の説明】

１０１、２００、４００、６００、７００、９０１、９
０３、９０４、１００１、１００５、１００６ サーバ １０２、２０４、４０４、６０４、７０４、９０２、１
００２ コアネットワーク １０３、２１０、４１０、６１０、７１０、９０５、９
０６、１００８、１００９ アクセスネットワーク １０４、２１１、４１１、６１１、７１１、９０７〜９
１０、１０１０〜１０１３ セットートップユニット
（ＳＴＵ） ２０７、４０７、６０７、７０７ 蓄積装置

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｎ 7/10 9466−5Ｋ Ｈ０４Ｌ 11/20 Ｇ Ｈ０４Ｑ 3/00 Ｈ０４Ｎ 5/93 Ｅ (72)発明者 面 川 光 教 神奈川県川崎市幸区小向東芝町１ 株式会 社東芝研究開発センター内 (72)発明者 釜 谷 幸 男 神奈川県川崎市幸区小向東芝町１ 株式会 社東芝研究開発センター内 (72)発明者 下 條 義 満 神奈川県川崎市幸区小向東芝町１ 株式会 社東芝研究開発センター内 (72)発明者 広 瀬 次 宏 東京都港区芝浦一丁目１番１号 株式会社 東芝本社事務所内

Claims (23)

【特許請求の範囲】
1. 【請求項１】時系列的に順序管理された複数の部分情報
   からなる情報が順方向に入力される第１の入力部と、前
   記時系列的に順序管理された複数の部分情報からなる情
   報が逆方向に入力される第２の入力部と、第２の入力部
   から入力される部分情報を入力された順に蓄積する蓄積
   部と、第１の入力部に入力された部分情報と前記蓄積部
   に蓄積された部分情報を比較する比較部と、比較部の比
   較結果に基づき第１の入力部からの部分情報の出力を停
   止すると共に蓄積部に蓄積された部分情報を出力する切
   替手段と、を備えて情報を中継することを特徴とするリ
   アルタイムデータ伝送用情報提供システム。
2. 【請求項２】リアルタイムデータを入力する入力ポート
   と、リアルタイムデータを出力する出力ポートと、入力
   ポートから入力するリアルタイム情報の時間的に先行す
   る部分を蓄積する蓄積部と、入力ポートから入力した情
   報を出力ポートへ出力するとともにそれを監視し、出力
   ポートから出力する情報と同じ情報を蓄積部から送信で
   きると判断した場合に、出力ポートから出力する情報を
   入力ポートから入力した情報から蓄積部に蓄積している
   情報へ切替える切り替え手段とを具備して情報を中継す
   ることを特徴とするリアルタイムデータ伝送用情報提供
   システム。
3. 【請求項３】リアルタイムデータの伝送に必要な品質が
   保証される第１の通信手段と、上記第１の通信手段とは
   別の第２の通信手段と、蓄積されたリアルタイムデータ
   を第１の通信手段を利用して送信するとともに、上記第
   １の通信手段により伝送されるリアルタイムデータより
   時間的に先行するリアルタイムデータを第２の通信手段
   を利用して送信する手段と、少なくとも第２の通信手段
   により送られてきた情報を蓄積する蓄積手段と、上記第
   １の通信手段から送られるリアルタイムデータ及び上記
   蓄積手段に蓄積されたリアルタイムデータの再生時刻を
   監視し、蓄積手段に蓄積された第２の通信手段から送ら
   れたリアルタイムデータの再生時刻になったら、出力を
   上記第１の通信手段からのリアルタイムデータから上記
   蓄積手段からのリアルタイムデータへ切替える切り替え
   手段とを具備することを特徴とするリアルタイムデータ
   伝送用情報提供システム。
4. 【請求項４】上記第２の通信手段により送られる情報は
   リアルタイムデータの時間をさかのぼるように送られる
   ことを特徴とする請求項３に記載のリアルタイムデータ
   伝送用情報提供システム。
5. 【請求項５】上記リアルタイムデータを送信する手段
   は、第２の通信手段を用いて伝送され上記の蓄積手段に
   蓄積されている情報を第１の通信手段により送信しない
   ことを特徴とする請求項３記載のリアルタイムデータ伝
   送用情報提供システム。
6. 【請求項６】リアルタイムデータの伝送に必要な品質が
   保証される第１の通信手段と、 上記第１の通信手段とは別の第２の通信手段と、 蓄積されたリアルタイムデータを前記第１の通信手段を
   利用して送信するとともに、上記第１の通信手段により
   伝送されるリアルタイムデータより時間的に先行するリ
   アルタイムデータを第２の通信手段を利用して送信する
   手段と、 少なくとも前記第２の通信手段により送られてきたデー
   タを蓄積する蓄積手段と、 上記第１の通信手段から送られるリアルタイムデータ及
   び上記蓄積手段に蓄積されたリアルタイムデータの再生
   時刻を監視し、蓄積手段に蓄積された第２の通信手段か
   ら送られたリアルタイムデータの再生時刻になったら、
   出力を上記第１の通信手段からのリアルタイムデータか
   ら上記蓄積手段からのリアルタイムデータへ切替える切
   り替え手段と、 上記切り替え手段からの出力を受信して上記リアルタイ
   ムデータを再生する再生手段とを具備することを特徴と
   するリアルタイムデータ伝送用情報提供システム。
7. 【請求項７】上記第１の通信手段と第２の通信手段を使
   用した上記リアルタイムデータ伝送と、上記第１の通信
   手段のみを使用した上記リアルタイムデータ伝送とを上
   記送信手段側または上記再生手段側で選択することがで
   きることを特徴とする請求項６に記載のリアルタイムデ
   ータ伝送用情報提供システム。
8. 【請求項８】上記蓄積手段は第２の通信手段を使用して
   伝送されたリアルタイムデータの誤りを検出する手段
   と、上記誤りを検出したデータの再送を要求する手段と
   を具備し、上記送信手段は上記再送要求手段からの再送
   要求に基づき誤ったデータの再送を行うことを特徴とす
   る請求項６記載のリアルタイムデータ伝送用情報提供シ
   ステム。
9. 【請求項９】上記蓄積手段は通信開始時に使用可能なメ
   モリ量を上記送信手段に申告し、上記送信手段は第２の
   通信手段を使用して上記申告されたメモリ量分のリアル
   タイムデータを伝送した時点で、上記第２の通信手段を
   使用したリアルタイムデータ伝送を停止することを特徴
   とする請求項６記載のリアルタイムデータ伝送用情報提
   供システム。
10. 【請求項１０】最低限のデータ伝送レートが保証される
    通信手段と、 蓄積されたリアルタイムデータを上記通信手段を利用し
    て再生伝送レートが上記保証される最低限のデータ伝送
    レート以下になるように送信する手段と、 上記送信されたリアルタイムデータを入力し、上記再生
    伝送レートで出力する先入れ先出し（ＦＩＦＯ）蓄積手
    段と、 上記蓄積手段の出力を受信して上記リアルタイムデータ
    を再生する再生手段と、 を具備することを特徴とするリアルタイムデータ伝送用
    情報提供システム。
11. 【請求項１１】上記蓄積手段には蓄積データ量を監視す
    る手段を具備し、上記蓄積データ量に基づいて上記保証
    される最低限のデータ伝送レートを越えて出力できる伝
    送レートに対する制御信号を上記送信手段に対して送
    り、上記送信手段は上記制御信号に基づき動作すること
    を特徴とする請求項１０記載のリアルタイムデータ伝送
    用情報提供システム。
12. 【請求項１２】上記通信手段を使用した上記リアルタイ
    ムデータ伝送と、リアルタイムデータの伝送のための品
    質が保証された通信手段を使用した上記リアルタイムデ
    ータ伝送とを上記送信手段側または上記再生手段側で選
    択することができることを特徴とする請求項１０記載の
    リアルタイムデータ伝送用情報提供システム。
13. 【請求項１３】上記蓄積手段に蓄積されたリアルタイム
    データの再生後に、上記蓄積手段に残されたリアルタイ
    ムデータを消去することを特徴とする請求項１０記載の
    リアルタイムデータ伝送用情報提供システム。
14. 【請求項１４】時系列的に順序管理されたリアルタイム
    データを蓄積する複数のデータ蓄積手段と、 該リアルタイムデータを伝送する通信手段と、 該リアルタイムデータを受信して再生する再生手段と、 該通信手段の通信資源を管理し、該データ蓄積手段と再
    生手段との間に通信路を設定する通信網資源管理制御手
    段と、 該データ蓄積手段が蓄積しているリアルタイムデータの
    種類を管理するとともに、該データ蓄積手段が同時に送
    信可能なリアルタイムデータの数を管理し、要求された
    リアルタイムデータを送信すべきデータ蓄積手段を決定
    する蓄積資源管理制御手段と、 ユーザからのサービス要求を受け付け、該通信網資源管
    理制御手段と該蓄積資源管理制御手段とから得た資源状
    態に基づき、通信網資源管理制御手段及び蓄積資源管理
    制御手段に対して資源の予約を指示し、選択された場合
    に即座に提供可能なリアルタイムデータと提供不可能な
    リアルタイムデータとを識別した上で選択候補をユーザ
    に通知するサービス制御手段とを具備することを特徴と
    するリアルタイムデータ伝送用情報提供システム。
15. 【請求項１５】該サービス制御手段は、選択された場合
    に即座に提供可能なリアルタイムデータを、即座に提供
    可能な選択候補としてユーザに通知することを特徴とす
    る請求項１４に記載のリアルタイムデータ伝送用情報提
    供システム。
16. 【請求項１６】該サービス制御手段は、選択された場合
    に即座に提供可能か否かが確定していないリアルタイム
    データを、即座に提供可能か否かを保証しない条件付き
    の選択候補としてユーザに通知することを特徴とする請
    求項１４に記載のリアルタイムデータ伝送用情報提供シ
    ステム。
17. 【請求項１７】該サービス制御手段は、蓄積資源か通信
    網資源かの少なくとも一方が確保できないリアルタイム
    データを、選択されても即座に提供不可能なリアルタイ
    ムデータとしてユーザに通知することを特徴とする請求
    項１４に記載のリアルタイムデータ伝送用情報提供シス
    テム。
18. 【請求項１８】時系列的に順序管理されたリアルタイム
    データを蓄積する複数のデータ蓄積手段と、 該リアルタイムデータを伝送する通信手段と、 該リアルタイムデータを受信して再生する再生手段と、 該通信手段の通信資源を管理し、該データ蓄積手段と再
    生手段との間に通信路を設定する通信網資源管理制御手
    段と、 該データ蓄積手段が蓄積しているリアルタイムデータの
    種類を管理するとともに、該データ蓄積手段が同時に送
    信可能なリアルタイムデータの数を管理し、要求された
    リアルタイムデータを送信すべきデータ蓄積手段を決定
    する蓄積資源管理制御手段と、 ユーザからのサービス要求を受け付け、該通信網資源管
    理制御手段と該蓄積資源管理制御手段とから得た資源状
    態に基づき、通信網資源管理制御手段及び蓄積資源管理
    制御手段に対して資源の予約を指示し、選択された場合
    にある値以上の確率で即座に提供可能なリアルタイムデ
    ータと全く提供可能なリアルタイムデータとを識別した
    上で選択候補をユーザに通知するサービス制御手段とを
    具備することを特徴とするリアルタイムデータ伝送用情
    報提供システム。
19. 【請求項１９】該サービス制御手段は、選択された場合
    にある値以上の確率で即座に提供可能なリアルタイムデ
    ータを選択候補としてユーザに通知することを特徴とす
    る請求項１８に記載のリアルタイムデータ伝送用情報提
    供システム。
20. 【請求項２０】該サービス制御手段は、即座に提供可能
    な選択候補の中のリアルタイムデータをユーザが選択し
    た場合には、該通信網資源管理制御手段と該蓄積資源管
    理制御手段とに対し、予約した資源のうちの該リアルタ
    イムデータを提供するするために必要な資源の割当確定
    と不要となった資源の解放とを指示することを特徴とす
    る請求項１９に記載のリアルタイムデータ伝送用情報提
    供システム。
21. 【請求項２１】該サービス制御手段は、選択された場合
    にある値以上の確率で即座に提供可能であることが確定
    していないリアルタイムデータを、即座に提供可能か否
    かを保証しない条件付き選択候補としてユーザに通知す
    ることを特徴とする請求項１８に記載のリアルタイムデ
    ータ伝送用情報提供システム。
22. 【請求項２２】該サービス制御手段は、即座に提供可能
    か否かを保証しない選択候補の中のリアルタイムデータ
    をユーザが選択した場合には、該リアルタイムでの提供
    に必要な資源を確保できるか否かを判断し、確保できる
    場合は該通信網資源管理制御手段と該蓄積資源管理制御
    手段とに対し、該リアルタイムデータを提供するために
    必要な資源の割当と不要となった資源の解放とを指示
    し、確保できない場合は該リアルタイムデータの提供の
    拒絶をユーザに通知することを特徴とする請求項２１に
    記載のリアルタイムデータ伝送用情報提供システム。
23. 【請求項２３】該サービス制御手段は、蓄積資源か通信
    網資源かの少なくとも一方が確保できないリアルタイム
    データを、選択されても即座に提供可能なリアルタイム
    データとしてユーザに通知することを特徴とする請求項
    １８に記載のリアルタイムデータ伝送用情報提供システ
    ム。