JP4132630B2 - 放送システム及びその方法 - Google Patents
放送システム及びその方法 Download PDFInfo
- Publication number
- JP4132630B2 JP4132630B2 JP2000310007A JP2000310007A JP4132630B2 JP 4132630 B2 JP4132630 B2 JP 4132630B2 JP 2000310007 A JP2000310007 A JP 2000310007A JP 2000310007 A JP2000310007 A JP 2000310007A JP 4132630 B2 JP4132630 B2 JP 4132630B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- program data
- digest
- client
- program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は放送システム及びその方法に関し、特にサーバと複数のクライアントとが通信媒体を介して接続され、前記クライアントからの要求に応答して前記サーバが番組データを送信するようにした放送方式に関するものである。
【０００２】
【従来の技術】
ネットワーク技術の発達に伴い、従来放送用電波を用いて行われていた放送をネットワーク上で流通させることが可能となってきた。例えば、特開平９−１４９３５４号公報には、ビデオサーバと、クライアントとなるセットトップ・ボックスを高速ネットワークバスで接続し、ユーザからの要求に従い、必要なビデオデータをサーバからクライアントに転送して再生を行う技術が開示されている。また、ユーザはビデオデータの再生をいつでも要求することが可能となっている。
【０００３】
【発明が解決しようとする課題】
上述した特開平９−１４９３５４号公報のようなビデオ配送システムでは、サーバとクライアントが１対１で通信を行うため、ｎ（ｎは２以上の整数）台のクライアントからビデオデータの要求を受けた場合にはクライアントが１台の場合に比べｎ倍の通信帯域が必要となる。一方、既存のテレビ放送のように１対多でビデオデータの送信を行っている場合には、クライアントの数によらず一定の通信帯域で済むという利点はあるが、送られてくるビデオデータは予め決められたスケジュールに従って送信されており、任意の時刻にビデオデータを先頭から視聴することが出来ないという欠点や、同サイズのデータを送信する場合には１対１通信よりも１対多通信の方がコストがかかるため、受信するクライアント数が少ない場合には非効率的となるという欠点がある。
【０００４】
また、ホームサーバのように放送されてくるビデオデータを、クライアント上の補助記憶装置に蓄積しつつデータの再生を行う形態の場合には、一定の通信帯域で複数のクライアントにビデオデータを送信しつつ、クライアント側でビデオデータの視聴開始時刻を自由に選択することが可能となるが、
（ａ）クライアントに大容量の補助記憶装置が必要になる；
（ｂ）クライアントに蓄積されていないビデオデータは視聴することが出来ない；
といった欠点がある。
【０００５】
本発明の目的は、クライアントに一切の補助記憶装置を設けることなく、クライアント側でビデオデータの視聴開始時刻を柔軟に指定可能にし、かつ必要な通信帯域と通信コストを要望に応じて低減する放送システム及びその方法を提供することである。
【０００６】
【課題を解決するための手段】
本発明によれば、サーバと複数のクライアントとが、前記クライアントからの要求に応答して動的に通信方式や通信経路が変更制御される通信媒体を介して接続され、前記要求に応答して前記サーバが番組データを送信するようにした放送システムであって、前記サーバは、前記番組データを送信している期間中に他のクラインアントからこの番組データの要求があった場合、この番組データの送信開始から当該要求を受信するまでの間に送信済みの番組データと、前記クライアントに番組のダイジェストデータを送信する間に送信される予定の番組データとから前記ダイジェストデータを生成するダイジェスト生成手段と、このダイジェストデータとそれに続く番組データとを、通信路を切替えて送信する送信手段とを含むことを特徴とする放送システムが得られる。
【００１０】
前記クラインアントは、前記ダイジェストデータを受信し、この受信終了後には送信中の前記番組データを受信するよう切替える手段を、更に含むことを特徴とし、また前記ダイジェスト生成手段は、前記ダイジェストデータを生成する範囲の開始点を、前記番組データの開始点からではなく前記クライアントの指示した時点からとすることを特徴とする。前記ダイジェストデータの生成範囲の終了時点を、前記クライアントが指定可能としたことを特徴とする。
【００１１】
また、前記番組データの１以上のダイジェストデータを予め蓄積する蓄積手段を更に含み、前記送信手段は、前記クライアントからの要求に応答して前記蓄積手段からダイジェストデータを読み出して送信するようにしたことを特徴とする。また、前記サーバは、前記通信媒体と前記ダイジェストデータの品質に応じて前記クライアントに対する課金をなす手段を、更に含み、また前記クライアントに関する利用者情報を収集して、前記番組データを送信する際に使用する前記通信媒体と前記ダイジェストデータの品質とを決定する手段を、更に含むことを特徴とする。
【００１２】
本発明によれば、サーバと複数のクライアントとが、前記クライアントからの要求に応答して動的に通信方式や通信経路が変更制御される通信媒体を介して接続され、前記要求に応答して前記サーバが番組データを送信するようにした放送方法であって、前記サーバにおいて、前記番組データを送信している期間中に他のクラインアントからこの番組データの要求があった場合、この番組データの送信開始から当該要求を受信するまでの間に送信済みの番組データと、前記クライアントに番組のダイジェストデータを送信する間に送信される予定の番組データとから前記ダイジェストデータを生成するダイジェスト生成ステップと、このダイジェストデータとそれに続く番組データとを、通信路を切替えて送信する送信ステップとを含むことを特徴とする放送方法が得られる。
【００１６】
また、前記クラインアントにおいて、前記ダイジェストデータを受信し、この受信終了後には送信中の前記番組データを受信するよう切替えるステップを更に含むことを特徴とする。また、前記ダイジェスト生成ステップは、前記ダイジェストデータを生成する範囲の開始点を、前記番組データの開始点からではなく前記クライアントの指示した時点からとすることを特徴とする。更に、前記ダイジェストデータの生成範囲の終了時点を、前記クライアントが指定可能としたことを特徴とする。
【００１７】
そして、前記送信ステップは、前記クライアントからの要求に応答して、前記番組データの１以上のダイジェストデータを予め蓄積した蓄積手段からダイジェストデータを読み出して送信するようにしたことを特徴とする。また、前記サーバにおいて、前記通信媒体と前記ダイジェストデータの品質に応じて前記クライアントに対する課金をなすステップを、更に含むことを特徴とする。また、前記サーバにおいて、前記クライアントに関する利用者情報を収集して、前記番組データを送信する際に使用する前記通信媒体と前記ダイジェストデータの品質とを決定するステップを、更に含むことを特徴とする。
【００１８】
本発明の作用を述べる。利用者は視聴したい番組データをクライアントを通じてサーバにリクエストし、クライアントはその結果サーバから送信されてくる番組データを受信して利用者に提示する。このとき、サーバのリクエスト処理部はリクエストされた番組データと同じ番組データを送信しているクライアントの数や、リクエストされた番組データを送信するために必要な通信帯域などから、番組データを送信するために使用する通信手段を動的に変化させる。すなわち、ある番組データをリクエストするクライアントの数が少数のうちは個々のクライアントに対し１対１通信で番組データの送信を行い、クライアント数が予め決められた閾値を越えた時には同番組データを送信するために使用する通信手段を、同番組データをリクエストしている全てのクライアントに向けての１対多通信に切り替える。また、この逆に、ある番組データを１対多通信で送信している状態で、同番組データをリクエストしているクライアントの数が予め決められた閾値を下回った時には同番組データを送信するために使用する通信手段を、個々のクライアントに対する１対１通信に切り替える。
【００１９】
また、上記の放送システムにおいて、視聴率調査などにより送信予定の番組データをリクエストしてくるクライアントの数の時間推移を予想し、そのクライアント数の増減予想をもとに番組データを送信するために使用する通信手段を動的に変化させる機能を持つようにすることができる。
【００２０】
上記動作により、多くのクライアントに対し１対１通信で番組データを送信するために通信帯域を大量に占有することや、通常１対１通信よりも多くのコストがかかる１対多通信を少数のクライアントに対して使用するといった無駄を減少させるという効果が得られる。
【００２１】
また、ある番組データが１対多通信により送信されている状態で同番組データを利用者がクライアントを通じてサーバにリクエストした時に、同番組データのすでに送信済みの部分とクライアントにダイジェストを送信する間に送信される予定の部分のダイジェストをダイジェスト生成部で生成し、同番組データをリクエストしてきたクライアントに生成したダイジェストを１対１通信で送信する。同番組データをリクエストしたクライアントは、まず、１対１通信で送信されてくる番組データのダイジェストを受信し利用者に提示する。ダイジェストの受信終了後は、もともと１対多通信により送信中の番組データの受信に切り替え、引続き利用者に番組データを提示する。
【００２２】
上記の動作により、すでに１対多通信で送信が開始されている番組データを途中から利用者がリクエストしても同番組データを先頭から視聴することが可能となり、かつ、ダイジェスト送信が終了した後、クライアントは番組データの続きを１対多通信で受信するため、ダイジェストの送信以外で余分な通信を必要としないという効果が得られる。さらに、本発明ではクライアント側に特に補助記憶装置を用意する必要がないため、クライアントを低価格、小型化することが可能となるという効果も得られる。
【００２３】
更に、ダイジェストを生成する範囲を番組データの開始部分からクライアントへのダイジェスト送信が終了するまでに送信される予定の部分までではなく、番組データをリクエストするクライアントが自由に指定可能とするようにする。これにより利用者は、番組データの希望しない部分を除いたダイジェストを受信可能となるという効果が得られる。
【００２４】
更にはまた、上記の放送システムにおいて、番組データのダイジェストをクライアントからのリクエストを受け付けた時点で生成するのではなく、予め何種類かの長さのダイジェストを生成してデータ蓄積部に蓄積しておき、クライアントからリクエストを受け付けた時には、上記手順により決定されるダイジェストの範囲に最も近い範囲のダイジェストをデータ蓄積部内から選択しクライアントに送信する機能を有するよう構成する。かかる機能により、リアルタイムでダイジェストを生成することなしに前述の効果が得られる。
【００２５】
また、データ作成部で作成される番組データはデータ送信部からクライアントに送信されるとともに、データ蓄積部に蓄積されていく。クライアントから同番組データのリクエストがあった時には、リアルタイムに蓄積されていく番組データからダイジェストを作成し、上記の手順によりクライアントに番組データとそのダイジェストを送信する。上記の動作により、予めデータ蓄積部に蓄積されている番組データだけでなく、ライブ映像のようにリアルタイムに生成されていく番組データに対しても上記のダイジェスト送信を行うことが可能となる。
【００２６】
さらに、番組データを送信する際に使用する通信手段の種類とダイジェスト生成部が生成するダイジェストの品質の組み合わせにより、クライアントからのリクエストに対して課金を行う機能を持つように構成する。これにより、利用者に適切なサービスを適正な価格で提供することが可能となる。
【００２７】
さらに、リクエスト処理部でクライアントの利用者情報を予め管理しておき、その利用者情報を用いてデータを送信する際に使用する通信手段の種類とダイジェスト生成部が生成するダイジェストの品質を決定する機能を持つよう構成する。これにより、利用者毎に適応したサービスを提供することが可能となる。
【００２８】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して詳細に説明する。図１は本実施の形態の放送システムの１構成例を示した図である。この放送システムは、Ｎ個（Ｎは１以上の任意の数で、例えばＮ＝３となっている）の通信経路によって結ばれたサーバ１０とクライアント２０から構成されている。図１では便宜上、クライアントの数は１となっているが、実際には２以上のクライアントが接続されているとして説明する。また、以下の説明では本発明の実施に不可欠な要素についてのみ示し、当業者にとって良く知られている従来品と同一の要素についてはその説明を省略する。
【００２９】
図１のサーバ１０は、クライアントに送信する番組データを蓄積しておくデータ蓄積部１１と、データ送信部１５の送信状況とクライアント２０からのリクエスト内容に従い、通信手段の決定を行うリクエスト処理部１２と、リクエスト処理部１２からの指示内容に従いデータ蓄積部１１に蓄積されている番組データのダイジェストを生成するダイジェスト生成部１３と、リクエスト処理部１２からの指示内容に従い通信方式や通信経路の選択指示を行う通信手段選択部１４と、通信手段選択部１４からの指示内容に従いデータ蓄積部１１に蓄積されている番組データやダイジェスト生成部１３が生成した番組データのダイジェストをクライアント２０に送信するデータ送信部１５と、データ蓄積部１１に蓄積する番組データを作成するデータ作成部１６とを備えている。
【００３０】
ここで通信手段とは、サーバ１０とクライアント２０とをつなぐ通信経路の種類と、サーバ１０からクライアント２０にデータを送信する際に使用する通信方式の種類のことであり、通信経路の種類とは、例えば、イーサネットや電話回線のような有線回線や、放送用電波や無線通信のような無線回線のことであり、通信方式の種類とは、例えば、１対１で通信を行うユニキャストや、１対多で通信を行うマルチキャストやブロードキャストのことである。
【００３１】
番組データとは、クライアント２０の利用者が閲覧する動画や音から構成されるマルチメディアデータのことで、例えば、ＭＰＥＧ２形式の映像データのことである。
【００３２】
図１のクライアント２０は、サーバに番組データをリクエストするデータリクエスト部２１と、通信経路を通じてサーバから送られてくる番組データを受信するデータ受信部２２と、１種類以上の通信手段によりサーバから送られてくる番組データの中からデータ受信部２２で受信する番組データの選択指示を行うデータ選択部２３と、データ受信部２２で受信した番組データを利用者に提示するデータ出力部２４とを備えている。
【００３３】
次に、上述の放送システムにおいて、番組データを受信するクライアント２０の数が増加した場合の動作内容を図を用いて具体的に説明する。サーバ１０は、リクエスト処理部１２でクライアント２０からの番組データリクエストを常時待ちうけておき、リクエストがあった場合には、図２に示される処理手順に従い、データ蓄積部１１に蓄積されている番組データの送信を行う。リクエスト処理部１２はリクエストを受け付けると（ステップＳ１）、リクエストされた番組データを送信するために必要な通信帯域とリクエストを受け付けた時点で、すでにデータ送信部１５から同リクエスト番組データを送信しているクライアント２０の数とから決定される状態が、図３のどの領域に存在するかを調べる（ステップＳ２）。
【００３４】
ここで、図３は、リクエスト処理部１２が持つ通信手段選択のための判断基準の一例を表したもので、例えば、広い通信帯域を必要とする番組データや送信するクライアントの数が多数の場合、すなわち、図３の領域Ｂに位置する場合には、放送用電波を用いたブロードキャストで番組データの送信を行い、逆に狭い通信帯域で十分な番組データや送信するクライアントの数が少ない場合、すなわち、図３の領域Ａに位置する場合には、電話回線を用いたユニキャストで番組データの送信を行う。
【００３５】
クライアント２０から番組データのリクエストを受け付けた時点で、すでに図３の領域Ｂに位置する場合には、同番組データはブロードキャストで送信されている状態にあるので、サーバ１０の通信手段選択部１４はリクエストを行ったクライアント２０に対しブロードキャストで送信されている番組データの受信を指示する（ステップＳ３，Ｓ４）。
【００３６】
クライアント２０から番組データのリクエストを受け付けた時点で、図３の領域Ａに位置する場合には、クライアント数が１増えることで領域Ｂに移行するかどうかを調べる（ステップＳ５）。領域Ｂに移行しない場合には、サーバ１０の通信手段選択部１４はリクエストを行ったクライアント２０に対しユニキャストで送信される番組データの受信を指示し（ステップＳ６）、データ送信部１５からクライアント２０に対してユニキャストで同番組データの送信を開始する（ステップＳ７）。
【００３７】
一方、クライアント数が１増えたことで、図３の領域Ａから領域Ｂに移行する場合には、サーバ１０の通信手段選択部１４は、同リクエスト番組データを受信している全てのクライアント２０に対し、通信手段をユニキャストからブロードキャストに切り替える指示を出し（ステップＳ８）、さらに、通信手段選択部１４はデータ送信部１５に同番組データの送信をユニキャストからブロードキャストに切り替えるよう指示を出す。また、リクエストを行ったクライアント２０に対してはブロードキャストで送信される番組データの受信を指示する。
【００３８】
クライアント２０は利用者から番組データのリクエストを受け付け、図４に示される処理手順に従い番組データの受信を行う。データリクエスト部２１は、利用者からのリクエストに従い、希望する番組データをサーバ１０に対しリクエストする（ステップＳ１１）。リクエストを送信した後、データ選択部２３はサーバ１０から送られてくる番組データを受信するために使用する通信手段の指示を待ちうけ（ステップＳ１２）、送られてきた通信手段に関する指示をデータ受信部２２に受け渡す。
【００３９】
データ受信部２２はデータ選択部２３からの指示に従いブロードキャストで送信される番組データ、あるいはユニキャストで送信される番組データの受信を行い、受信した番組データをデータ出力部２４に受け渡す。データ出力部２４はデータ受信部２２から受け渡された番組データを、例えばディスプレイやスピーカのような既存のデータ出力機器を用いて利用者に提示する。
【００４０】
番組データを受信しているクライアント２０は、サーバ１０からの番組データ送信が終了するか、利用者から新たな番組データのリクエストを受け取る、あるいは番組データの受信停止を指示されるまで番組データの受信と利用者への提示を続ける（ステップＳ１４，Ｓ１５）。その間、データ選択部２３はサーバ１０からの通信手段切り替え指示を待ちうけ（ステップＳ１６，Ｓ１７）、ユニキャストからブロードキャストへの切り替え、あるいはブロードキャストからユニキャストへの切り替え指示を受け取った場合には、データ受信部２２に番組データの受信をブロードキャスト、あるいはユニキャストで行うように指示を出し、データ受信部２２はその指示に従い番組データの受信のために用いる通信手段を切り替える。
【００４１】
番組データを受信しているクライアント２０は、サーバ１０からの番組データ送信が終了するか、利用者から番組データの受信停止を指示されると（ステップＳ１８，Ｓ１９）、データ受信部２２で行っている番組データの受信とデータ出力部２４で行っている番組データの利用者への提示を停止し（ステップＳ２０）、利用者からの番組データリクエストを待ちうける。さらに、データリクエスト部２１はサーバ１０に番組データの受信終了を通知する。
【００４２】
番組データを受信しているクライアント２０は、利用者から新たな番組データのリクエストを受け取ると、その時点で行っているデータ受信部２２の番組データ受信とデータ出力部２４の番組データの利用者への提示を停止し、上述した手順に従い新たにリクエストされた番組データの受信と利用者への提示を行う。
【００４３】
次に、上述の放送システムにおいて、番組データを受信するクライアント２０の数が減少した場合の動作内容を図を用いて具体的に説明する。
【００４４】
サーバ１０は番組データを送信しているクライアント２０から番組データの受信終了通知を受け取ると、図５に示される処理手順に従い、通信手段の再選択を行う。リクエスト処理部１２はクライアント２０から受信終了通知を受け取ると（ステップＳ２１）、その受信が終了した番組データの送信状態が図３のどの領域にあったのかを調べる（ステップＳ２２）。終了通知を受け取る前から領域Ａに位置していた場合には、これまで通りユニキャストで番組データの送信を続ける（ステップＳ２３）。
【００４５】
領域Ｂに位置していた場合には、クライアント２０の数がひとつ減少することにより、送信状態が図３の領域Ｂから領域Ａに移行するがどうかを調べる（ステップＳ２４）。移行しない場合には、これまで通りブロードキャストで番組データの送信を続ける（ステップＳ２５）。領域Ｂから領域Ａに移行する場合には、サーバ１０の通信手段選択部１４は、受信終了を送信してきたクライアント以外で同番組データを受信している全てのクライアント２０に対し、通信手段をブロードキャストからユニキャストに切り替える指示を出し（ステップＳ２６）、さらに、通信手段選択部１４はデータ送信部１５に同番組データの送信をブロードキャストからユニキャストに切り替えるよう指示を出す。データ送信部１５は通信手段選択部１４の指示に従い、通信手段をユニキャストに切り替えて番組データの送信を続ける。
【００４６】
以上で述べたように、本実施の形態の放送システムでは、番組データをリクエストするクライアントの数の増減に従い通信手段を動的に切り替えるため、多数のクライアントに対してユニキャストで送信を行うために多くの通信帯域を占有する、あるいは、少数のクライアントに対しコストのかかるブロードキャストで送信を行うといった通信経路の利用の無駄を抑え、効率的な運用が可能となる。
【００４７】
また、上記実施の形態の説明では、図３の領域Ａと領域Ｂに位置する時の通信手段としては、電話回線上のユニキャストと放送電波上のブロードキャストのように通信経路と通信方式の双方が異なるものとしているが、通信経路は同一で通信方式のみを切り替える形態、あるいは、通信方式は同一で通信経路のみを切り替える形態でもよい。
【００４８】
また、上記実施の形態の説明では、番組データをリクエストしてくるクライアント２０の数は、リクエスト処理部１２に実際にリクエストを送信してくるクライアント２０の数を用いることとしているが、番組データをリクエストしてくるクライアント数の時間推移を視聴率調査などにより予め予想しておき、その予想クライアント数をもとに番組データを送信するために使用する通信手段を動的に切り替えるようにし、通信手段選択部１４はクライアント２０に対する通信手段の切り替え指示をブロードキャストを用いて行う形態でもよい。
【００４９】
上記の実施の形態では、クライアント２０からサーバ１０にリクエストを送る必要がないため、クライアント２０からサーバ１０向きの通信経路を用意することなしに通信手段を動的に変化させる放送システムを構成することが可能となる。
【００５０】
次に、上述の放送システムにおいて、番組データを受信するクライアント２０が番組ダイジェストの配信をリクエストした場合の動作内容を、図を用いて具体的に説明する。ここで、番組ダイジェストとは、番組データの一部を抜き出す、あるいは再生速度を上げることにより、同番組データの提示に本来要する時間よりも短時間で提示することが出来る番組データのことである。
【００５１】
クライアント２０が番組ダイジェストの配信をリクエストした時にサーバ１０から送信されている番組データの流れを図６に示す。図６は、クライアント２０が番組データＣをリクエストした時刻Ｒで、すでに同番組データＣがブロードキャストで他のクライアント２０に（リクエスト時刻Ｒ−番組開始時刻Ｓ）時間分の送信が行われている状態を表している。また、同番組データＣは番組終了時刻Ｅで送信が終了する。
【００５２】
図７は、番組データＣをリクエストしたクライアント２０が、同番組データを番組データＣの途中であるリクエスト時刻Ｒからではなく、番組データＣ全体である番組開始時刻Ｓから番組終了時刻Ｅまでの範囲で受信するために、サーバ１０に対し番組ダイジェストのリクエストを行った時の番組データの流れを示したものである。クライアント２０はリクエスト時刻Ｒからダイジェスト終了時刻Ｄまでの間は、ユニキャストにより番組データＣの番組ダイジェストを受信し、ダイジェスト終了時刻Ｄから番組終了時刻Ｅまではブロードキャストにより番組データＣを受信する。
【００５３】
上記図６と図７の番組データの流れを実現するサーバ１０の動作手順を図８に、クライアントの動作手順を図９に、それぞれ示す。ここで、図中の時間Ｔ１、Ｔ２は番組ダイジェストの生成動作を決めるパラメータで、Ｔ１＞Ｔ２という制約条件を満たす任意の値、例えばＴ１＝１０分、Ｔ２＝３分が設定されている。また、図中の縮尺Ｐは生成する番組ダイジェストの長さを決めるパラメータで、Ｐ＞０という制約条件を満たす任意の値、例えばＰ＝２が設定されている。
【００５４】
サーバ１０は、ブロードキャストによりデータ蓄積部１１に蓄積された番組データＣの送信を行いながら、リクエスト処理部１２でクライアント２０からの番組データリクエストを常時待ちうけておき、リクエストがあった場合には、図８に示される処理手順に従いデータ蓄積部１１に蓄積されている番組データＣの番組ダイジェストの送信を行う。
【００５５】
リクエスト処理部１２はリクエストを受け付けると（ステップＳ３１）、（番組終了時刻Ｅ−リクエスト時刻Ｒ）の値が時間Ｔ１以下であるかどうかを調べる（ステップＳ３２）。時間Ｔ１未満である場合には、ダイジェスト終了時刻Ｄを番組終了時刻Ｅと同じ値に設定し（ステップＳ３３）、番組ダイジェストの生成処理へと進む。時間Ｔ１以上である場合には、（リクエスト時刻Ｒ−番組開始時刻Ｓ）／Ｐの値が時間Ｔ２未満であるかどうかを調べ（ステップＳ３４）、時間Ｔ２未満である場合には、ダイジェスト終了時刻Ｄを（リクエスト時刻Ｒ−番組開始時刻Ｓ）／Ｐ＋リクエスト時刻Ｒに設定する（ステップＳ３５）。時間Ｔ２以上である場合には、ダイジェスト終了時刻Ｄを（時間Ｔ２＋リクエスト時刻Ｒ）に設定する（ステップＳ３６）。
【００５６】
ダイジェスト生成部１３は、クライアント２０からのリクエストに従いリクエスト処理部１２で決定されたダイジェスト終了時刻Ｄをもとに、例えば特開平０９−１３８６９３号公報や特開平０９−２７０９９７号公報に開示の公知の手法を用いて、番組データＣの番組開始時刻Ｓからダイジェスト終了時刻Ｄまでの長さの番組データから、（ダイジェスト終了時刻Ｄ−リクエスト時刻Ｒ）の値だけの長さを持つ番組ダイジェストを生成する（ステップＳ３７）。
【００５７】
データ送信部１５は、ダイジェスト生成部１３が生成した番組ダイジェストを番組データＣをリクエストしてきたクライアント２０に対しユニキャストで送信する（ステップＳ３８）。番組ダイジェストの送信が終了すると、通信手段選択部１４は同クライアント２０に通信手段をユニキャストからブロードキャストに切り替える指示を出す（ステップＳ３９）。また、データ送信部１５は前述の番組ダイジェストを送信する間も、番組データＣのブロードキャストによる送信は並行して行っている。
【００５８】
サーバ１０に対し番組データＣの番組ダイジェストをリクエストしたクライアント２０は、図９に示される処理手順に従い、番組データの受信を行う。データリクエスト部２１は、利用者が希望する番組データＣの番組ダイジェストをサーバ１０に対しリクエストする（ステップＳ４１）。リクエストを送信した後、データ受信部２２はサーバ１０からユニキャストで送信される番組データＣの番組ダイジェストを受信し、受信した番組ダイジェストをデータ出力部２４に受け渡す。データ出力部２４はデータ受信部２２から受け渡された番組ダイジェストを、例えばディスプレイやスピーカのような既存のデータ出力機器を用いて利用者に提示する（ステップＳ４２）。
【００５９】
データ選択部２３は、データ受信部２２が番組ダイジェストを受信している一方でサーバ１０からの通信手段の切り替え指示を待ちうけ、サーバ１０からブロードキャストに切り替える指示を受信すると（ステップＳ４３）、データ受信部２２にブロードキャストで番組データの受信を行うよう指示を出す。データ選択部２３からブロードキャストに切り替える指示を受け取ったデータ受信部２２は、ユニキャストでの番組ダイジェストの受信を終了し、ブロードキャストで送信されている番組データＣの受信を開始する。受信した番組データＣはデータ出力部２４に受け渡され利用者に提示される（ステップＳ４４）。
【００６０】
以上で述べたように、本実施の形態の放送システムでは、クライアントは番組データをリクエストした時点ですでに送信済みである番組データを番組ダイジェストとして受信し、番組ダイジェストの受信終了後はブロードキャストで送信されている番組データを受信するという形式になっているため、番組データの途中で同番組をリクエストしても番組データの開始時点からのデータを得ることが出来、かつ、サーバは番組ダイジェストの送信以外ではブロードキャストにより番組データを送信するため、異なる時刻に複数のクライアントからリクエストがあっても番組ダイジェスト以外の共通部分の送信に必要な通信帯域は一定であるので、番組データの送信に要する通信帯域を、個々の端末にユニキャストで番組データを送信する場合に比べ、少なくすることが可能となる。
【００６１】
また、クライアントは番組データを番組開始時刻より遅れて受信開始しても、番組データの受信終了時刻を番組終了時刻と同一にすることが可能となる。
【００６２】
また、上記実施の形態の説明では、通信方式はユニキャストとブロードキャストで切り替えるとしているが、通信経路に関しては同一であっても異なっていてもよい。
【００６３】
また、上記実施の形態の説明では、クライアント２０が番組データ、あるいは番組ダイジェストを受信するために使用する通信方式をユニキャストからブロードキャストに切り替えるタイミングは、サーバ１０からの切り替え指示を受信した時点としているが、サーバ１０からは切り替え指示を一切出さずに、クライアント２０は送信されてくる番組ダイジェストが終了した時点を通信方式の切り替えタイミングと判断するようにしてもよい。
【００６４】
また、上記実施の形態の説明では、ダイジェスト生成部１３は番組開始時刻Ｓからダイジェスト終了時刻Ｄまでの範囲の番組データから番組ダイジェストを生成するとなっており、番組ダイジェスト生成の範囲はサーバ１０で決定されるようになっているが、クライアント２０が番組ダイジェストをリクエストする際に、番組ダイジェストを生成する範囲の開始時刻と縮尺Ｐの一方、あるいは両方を受け渡すようにしておき、ダイジェスト生成部１３では、クライアント２０から受け渡されたパラメータをもとに番組ダイジェストを生成する範囲を決定するようにしてもよい。
【００６５】
また、上記実施の形態の説明では、ダイジェスト生成部１３での番組ダイジェスト生成が終了してからデータ送信部１５がクライアント２０に番組ダイジェストを送信するとなっているが、ダイジェストの生成とデータの送信は並列的に行ってもよい。
【００６６】
また、上記実施の形態の説明では、ダイジェスト生成部１３での番組ダイジェスト生成はクライアント２０からリクエストがあった時点で行うものとしているが、例えば、番組データの先頭から、長さ５分、１０分、１５分、……と、５分刻に切り出した番組データを、予め長さが５分の番組ダイジェストに変換してデータ蓄積部１１に蓄積しておき、クライアント２０から番組ダイジェストのリクエストがあった時のダイジェスト生成部１３の処理手順を、（リクエスト時刻Ｒ−番組開始時刻Ｓ＋５）の値に最も近い長さの番組ダイジェストを選択する作業に置き換えてもよい。
【００６７】
次に、上述の放送システムにおいて、サーバ１０から送信する番組データが予めデータ蓄積部１１に蓄積されたものではなく、データ作成部１６でリアルタイムに作成されたものである場合の動作内容について具体的に説明する。
【００６８】
データ作成部１６は、例えば、既存のビデオカメラとＭＰＥＧ２エンコーダから構成されており、撮影した映像をリアルタイムにＭＰＥＧ２形式の映像データに変換する。データ作成部１６は、変換したＭＰＥＧ２形式の映像データを番組データとしてデータ蓄積部１１に蓄積するとともにデータ送信部１５に受け渡して、同番組データをリクエストしたクライアント２０に対し送信する。このとき、サーバ１０とクライアント２０が前述の図２から図９で示される処理手順に従い動作することで、リアルタイムで作成される同番組データをリクエストするクライアント２０の数の増減に対する通信手段の動的な変更と、同番組データの番組ダイジェストの送信を実現することが出来る。
【００６９】
また、上記実施の形態において、リクエスト処理部１２に、番組データをクライアント２０に送信する際に使用する通信手段の種類と、ダイジェスト生成部１３が番組ダイジェストを生成するために使用するアルゴリズムや番組ダイジェストの生成範囲と生成される番組ダイジェストの時間長によって決定される番組ダイジェストの品質の組み合わせに応じて、クライアント２０からのリクエストに対して課金を行う機能を付け加えてもよい。
【００７０】
例えば、スポーツ中継の番組データを放送する場合に、番組データの最初の２時間はブロードキャストで番組データを送信し、クライアント２０の利用者からは特に料金を徴収しない。番組データの送信が２時間経過した後はユニキャストでの送信に切り替え、引続き視聴を希望する利用者はクライアント２０を通じてサーバ１０にスポーツ中継の番組データをリクエストする。サーバ１０は、リクエストを送信してきたクライアント２０に対してのみスポーツ中継の番組データをユニキャストで放送するとともに、リクエストを送信してきたクライアント２０の利用者に対して、例えば１００円の課金を行う。
【００７１】
また、上記実施の形態において、リクエスト処理部１２でクライアント２０の利用者情報（例えば、年齢、性別や嗜好などに関する情報）を予め管理しておき、その利用者情報を用いて、番組データをクライアント２０に送信する際に使用する通信手段の種類と、ダイジェスト生成部１３が生成する番組ダイジェストの品質を決定する機能を、リクエスト処理部１２に付け加えてもよい。
【００７２】
また、上記実施の形態において、通信手段選択のための判断基準を示した図３の領域Ｂに位置する時に使用する通信手段はブロードキャストとしているが、マルチキャストを用いる、あるいは、図１０に示されるように、領域Ｂを領域Ｂ１と領域Ｂ２に分割し、領域Ｂ１ではマルチキャストを、領域Ｂ２ではブロードキャストを用いるようにしてもよい。
【００７３】
上記実施の形態において、通信手段選択のための判断基準を示した図３は、番組データを送信するために必要な通信帯域と番組データをリクエストしてくるクライアント数を軸に構成されているが、番組データを送信するために必要な通信コスト、番組データの制作費などを含めて構成してもよい。
【００７４】
【発明の効果】
以上の説明から明らかなように、本発明によれば、番組データをリクエストするクライアント数の増減に従いデータ送信に使用する通信手段を動的に変化させることが可能となるので、通信経路の効率的な利用とコストの低減が実現されるという効果がある。また、番組ダイジェストの送信を行うことにより、クライアントが番組データの受信を開始する時刻が番組データの開始時刻より遅れても、番組データを先頭から受信し、かつ、番組データの受信終了時刻を番組終了時刻と同一にすることが可能となる。さらに、その際に必要となる通信経路は必要最小限に押さえられるという効果や、クライアントに補助記憶装置を用意する必要がないという効果もある。
【図面の簡単な説明】
【図１】本発明の実施の形態による放送システムのブロック構成図である。
【図２】本実施の形態における、クライアント数が増加した場合にサーバが通信手順を動的に切り替えながら番組データを送信する処理手順を示した図である。
【図３】本実施の形態における、通信手順を切り替える判断基準を示した図である。
【図４】本実施の形態における、クライアントが通信手順を動的に切り替えながら番組データを受信する処理手順を示した図である。
【図５】本実施の形態における、クライアント数が減少した場合にサーバが通信手順を動的に切り替えながら番組データを送信する処理手順を示した図である。
【図６】本実施の形態における、番組データの送信状況を示した図である。
【図７】本実施の形態における、クライアントが番組ダイジェストをリクエストした時の番組データと番組ダイジェストの送信状況を示した図である。
【図８】本実施の形態における、クライアントが番組ダイジェストをリクエストした時にサーバが番組ダイジェストと番組データを送信する処理手順を示した図である。
【図９】本実施の形態における、クライアントが番組ダイジェストをリクエストした時にクライアントが番組ダイジェストと番組データを受信する処理手順を示した図である。
【図１０】本実施の形態における、通信手順を切り替える判断基準の他の例を示した図である。
【符号の説明】
１０ サーバ
１１ データ蓄積部
１２ リクエスト処理部
１３ ダイジェスト生成部
１４ 通信手順選択部
１５ データ送信部
１６ データ作成部
２０ クライアント
２１ データリクエスト部
２２ データ受信部
２３ データ選択部
２４ データ出力部
【発明の属する技術分野】
本発明は放送システム及びその方法に関し、特にサーバと複数のクライアントとが通信媒体を介して接続され、前記クライアントからの要求に応答して前記サーバが番組データを送信するようにした放送方式に関するものである。
【０００２】
【従来の技術】
ネットワーク技術の発達に伴い、従来放送用電波を用いて行われていた放送をネットワーク上で流通させることが可能となってきた。例えば、特開平９−１４９３５４号公報には、ビデオサーバと、クライアントとなるセットトップ・ボックスを高速ネットワークバスで接続し、ユーザからの要求に従い、必要なビデオデータをサーバからクライアントに転送して再生を行う技術が開示されている。また、ユーザはビデオデータの再生をいつでも要求することが可能となっている。
【０００３】
【発明が解決しようとする課題】
上述した特開平９−１４９３５４号公報のようなビデオ配送システムでは、サーバとクライアントが１対１で通信を行うため、ｎ（ｎは２以上の整数）台のクライアントからビデオデータの要求を受けた場合にはクライアントが１台の場合に比べｎ倍の通信帯域が必要となる。一方、既存のテレビ放送のように１対多でビデオデータの送信を行っている場合には、クライアントの数によらず一定の通信帯域で済むという利点はあるが、送られてくるビデオデータは予め決められたスケジュールに従って送信されており、任意の時刻にビデオデータを先頭から視聴することが出来ないという欠点や、同サイズのデータを送信する場合には１対１通信よりも１対多通信の方がコストがかかるため、受信するクライアント数が少ない場合には非効率的となるという欠点がある。
【０００４】
また、ホームサーバのように放送されてくるビデオデータを、クライアント上の補助記憶装置に蓄積しつつデータの再生を行う形態の場合には、一定の通信帯域で複数のクライアントにビデオデータを送信しつつ、クライアント側でビデオデータの視聴開始時刻を自由に選択することが可能となるが、
（ａ）クライアントに大容量の補助記憶装置が必要になる；
（ｂ）クライアントに蓄積されていないビデオデータは視聴することが出来ない；
といった欠点がある。
【０００５】
本発明の目的は、クライアントに一切の補助記憶装置を設けることなく、クライアント側でビデオデータの視聴開始時刻を柔軟に指定可能にし、かつ必要な通信帯域と通信コストを要望に応じて低減する放送システム及びその方法を提供することである。
【０００６】
【課題を解決するための手段】
本発明によれば、サーバと複数のクライアントとが、前記クライアントからの要求に応答して動的に通信方式や通信経路が変更制御される通信媒体を介して接続され、前記要求に応答して前記サーバが番組データを送信するようにした放送システムであって、前記サーバは、前記番組データを送信している期間中に他のクラインアントからこの番組データの要求があった場合、この番組データの送信開始から当該要求を受信するまでの間に送信済みの番組データと、前記クライアントに番組のダイジェストデータを送信する間に送信される予定の番組データとから前記ダイジェストデータを生成するダイジェスト生成手段と、このダイジェストデータとそれに続く番組データとを、通信路を切替えて送信する送信手段とを含むことを特徴とする放送システムが得られる。
【００１０】
前記クラインアントは、前記ダイジェストデータを受信し、この受信終了後には送信中の前記番組データを受信するよう切替える手段を、更に含むことを特徴とし、また前記ダイジェスト生成手段は、前記ダイジェストデータを生成する範囲の開始点を、前記番組データの開始点からではなく前記クライアントの指示した時点からとすることを特徴とする。前記ダイジェストデータの生成範囲の終了時点を、前記クライアントが指定可能としたことを特徴とする。
【００１１】
また、前記番組データの１以上のダイジェストデータを予め蓄積する蓄積手段を更に含み、前記送信手段は、前記クライアントからの要求に応答して前記蓄積手段からダイジェストデータを読み出して送信するようにしたことを特徴とする。また、前記サーバは、前記通信媒体と前記ダイジェストデータの品質に応じて前記クライアントに対する課金をなす手段を、更に含み、また前記クライアントに関する利用者情報を収集して、前記番組データを送信する際に使用する前記通信媒体と前記ダイジェストデータの品質とを決定する手段を、更に含むことを特徴とする。
【００１２】
本発明によれば、サーバと複数のクライアントとが、前記クライアントからの要求に応答して動的に通信方式や通信経路が変更制御される通信媒体を介して接続され、前記要求に応答して前記サーバが番組データを送信するようにした放送方法であって、前記サーバにおいて、前記番組データを送信している期間中に他のクラインアントからこの番組データの要求があった場合、この番組データの送信開始から当該要求を受信するまでの間に送信済みの番組データと、前記クライアントに番組のダイジェストデータを送信する間に送信される予定の番組データとから前記ダイジェストデータを生成するダイジェスト生成ステップと、このダイジェストデータとそれに続く番組データとを、通信路を切替えて送信する送信ステップとを含むことを特徴とする放送方法が得られる。
【００１６】
また、前記クラインアントにおいて、前記ダイジェストデータを受信し、この受信終了後には送信中の前記番組データを受信するよう切替えるステップを更に含むことを特徴とする。また、前記ダイジェスト生成ステップは、前記ダイジェストデータを生成する範囲の開始点を、前記番組データの開始点からではなく前記クライアントの指示した時点からとすることを特徴とする。更に、前記ダイジェストデータの生成範囲の終了時点を、前記クライアントが指定可能としたことを特徴とする。
【００１７】
そして、前記送信ステップは、前記クライアントからの要求に応答して、前記番組データの１以上のダイジェストデータを予め蓄積した蓄積手段からダイジェストデータを読み出して送信するようにしたことを特徴とする。また、前記サーバにおいて、前記通信媒体と前記ダイジェストデータの品質に応じて前記クライアントに対する課金をなすステップを、更に含むことを特徴とする。また、前記サーバにおいて、前記クライアントに関する利用者情報を収集して、前記番組データを送信する際に使用する前記通信媒体と前記ダイジェストデータの品質とを決定するステップを、更に含むことを特徴とする。
【００１８】
本発明の作用を述べる。利用者は視聴したい番組データをクライアントを通じてサーバにリクエストし、クライアントはその結果サーバから送信されてくる番組データを受信して利用者に提示する。このとき、サーバのリクエスト処理部はリクエストされた番組データと同じ番組データを送信しているクライアントの数や、リクエストされた番組データを送信するために必要な通信帯域などから、番組データを送信するために使用する通信手段を動的に変化させる。すなわち、ある番組データをリクエストするクライアントの数が少数のうちは個々のクライアントに対し１対１通信で番組データの送信を行い、クライアント数が予め決められた閾値を越えた時には同番組データを送信するために使用する通信手段を、同番組データをリクエストしている全てのクライアントに向けての１対多通信に切り替える。また、この逆に、ある番組データを１対多通信で送信している状態で、同番組データをリクエストしているクライアントの数が予め決められた閾値を下回った時には同番組データを送信するために使用する通信手段を、個々のクライアントに対する１対１通信に切り替える。
【００１９】
また、上記の放送システムにおいて、視聴率調査などにより送信予定の番組データをリクエストしてくるクライアントの数の時間推移を予想し、そのクライアント数の増減予想をもとに番組データを送信するために使用する通信手段を動的に変化させる機能を持つようにすることができる。
【００２０】
上記動作により、多くのクライアントに対し１対１通信で番組データを送信するために通信帯域を大量に占有することや、通常１対１通信よりも多くのコストがかかる１対多通信を少数のクライアントに対して使用するといった無駄を減少させるという効果が得られる。
【００２１】
また、ある番組データが１対多通信により送信されている状態で同番組データを利用者がクライアントを通じてサーバにリクエストした時に、同番組データのすでに送信済みの部分とクライアントにダイジェストを送信する間に送信される予定の部分のダイジェストをダイジェスト生成部で生成し、同番組データをリクエストしてきたクライアントに生成したダイジェストを１対１通信で送信する。同番組データをリクエストしたクライアントは、まず、１対１通信で送信されてくる番組データのダイジェストを受信し利用者に提示する。ダイジェストの受信終了後は、もともと１対多通信により送信中の番組データの受信に切り替え、引続き利用者に番組データを提示する。
【００２２】
上記の動作により、すでに１対多通信で送信が開始されている番組データを途中から利用者がリクエストしても同番組データを先頭から視聴することが可能となり、かつ、ダイジェスト送信が終了した後、クライアントは番組データの続きを１対多通信で受信するため、ダイジェストの送信以外で余分な通信を必要としないという効果が得られる。さらに、本発明ではクライアント側に特に補助記憶装置を用意する必要がないため、クライアントを低価格、小型化することが可能となるという効果も得られる。
【００２３】
更に、ダイジェストを生成する範囲を番組データの開始部分からクライアントへのダイジェスト送信が終了するまでに送信される予定の部分までではなく、番組データをリクエストするクライアントが自由に指定可能とするようにする。これにより利用者は、番組データの希望しない部分を除いたダイジェストを受信可能となるという効果が得られる。
【００２４】
更にはまた、上記の放送システムにおいて、番組データのダイジェストをクライアントからのリクエストを受け付けた時点で生成するのではなく、予め何種類かの長さのダイジェストを生成してデータ蓄積部に蓄積しておき、クライアントからリクエストを受け付けた時には、上記手順により決定されるダイジェストの範囲に最も近い範囲のダイジェストをデータ蓄積部内から選択しクライアントに送信する機能を有するよう構成する。かかる機能により、リアルタイムでダイジェストを生成することなしに前述の効果が得られる。
【００２５】
また、データ作成部で作成される番組データはデータ送信部からクライアントに送信されるとともに、データ蓄積部に蓄積されていく。クライアントから同番組データのリクエストがあった時には、リアルタイムに蓄積されていく番組データからダイジェストを作成し、上記の手順によりクライアントに番組データとそのダイジェストを送信する。上記の動作により、予めデータ蓄積部に蓄積されている番組データだけでなく、ライブ映像のようにリアルタイムに生成されていく番組データに対しても上記のダイジェスト送信を行うことが可能となる。
【００２６】
さらに、番組データを送信する際に使用する通信手段の種類とダイジェスト生成部が生成するダイジェストの品質の組み合わせにより、クライアントからのリクエストに対して課金を行う機能を持つように構成する。これにより、利用者に適切なサービスを適正な価格で提供することが可能となる。
【００２７】
さらに、リクエスト処理部でクライアントの利用者情報を予め管理しておき、その利用者情報を用いてデータを送信する際に使用する通信手段の種類とダイジェスト生成部が生成するダイジェストの品質を決定する機能を持つよう構成する。これにより、利用者毎に適応したサービスを提供することが可能となる。
【００２８】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して詳細に説明する。図１は本実施の形態の放送システムの１構成例を示した図である。この放送システムは、Ｎ個（Ｎは１以上の任意の数で、例えばＮ＝３となっている）の通信経路によって結ばれたサーバ１０とクライアント２０から構成されている。図１では便宜上、クライアントの数は１となっているが、実際には２以上のクライアントが接続されているとして説明する。また、以下の説明では本発明の実施に不可欠な要素についてのみ示し、当業者にとって良く知られている従来品と同一の要素についてはその説明を省略する。
【００２９】
図１のサーバ１０は、クライアントに送信する番組データを蓄積しておくデータ蓄積部１１と、データ送信部１５の送信状況とクライアント２０からのリクエスト内容に従い、通信手段の決定を行うリクエスト処理部１２と、リクエスト処理部１２からの指示内容に従いデータ蓄積部１１に蓄積されている番組データのダイジェストを生成するダイジェスト生成部１３と、リクエスト処理部１２からの指示内容に従い通信方式や通信経路の選択指示を行う通信手段選択部１４と、通信手段選択部１４からの指示内容に従いデータ蓄積部１１に蓄積されている番組データやダイジェスト生成部１３が生成した番組データのダイジェストをクライアント２０に送信するデータ送信部１５と、データ蓄積部１１に蓄積する番組データを作成するデータ作成部１６とを備えている。
【００３０】
ここで通信手段とは、サーバ１０とクライアント２０とをつなぐ通信経路の種類と、サーバ１０からクライアント２０にデータを送信する際に使用する通信方式の種類のことであり、通信経路の種類とは、例えば、イーサネットや電話回線のような有線回線や、放送用電波や無線通信のような無線回線のことであり、通信方式の種類とは、例えば、１対１で通信を行うユニキャストや、１対多で通信を行うマルチキャストやブロードキャストのことである。
【００３１】
番組データとは、クライアント２０の利用者が閲覧する動画や音から構成されるマルチメディアデータのことで、例えば、ＭＰＥＧ２形式の映像データのことである。
【００３２】
図１のクライアント２０は、サーバに番組データをリクエストするデータリクエスト部２１と、通信経路を通じてサーバから送られてくる番組データを受信するデータ受信部２２と、１種類以上の通信手段によりサーバから送られてくる番組データの中からデータ受信部２２で受信する番組データの選択指示を行うデータ選択部２３と、データ受信部２２で受信した番組データを利用者に提示するデータ出力部２４とを備えている。
【００３３】
次に、上述の放送システムにおいて、番組データを受信するクライアント２０の数が増加した場合の動作内容を図を用いて具体的に説明する。サーバ１０は、リクエスト処理部１２でクライアント２０からの番組データリクエストを常時待ちうけておき、リクエストがあった場合には、図２に示される処理手順に従い、データ蓄積部１１に蓄積されている番組データの送信を行う。リクエスト処理部１２はリクエストを受け付けると（ステップＳ１）、リクエストされた番組データを送信するために必要な通信帯域とリクエストを受け付けた時点で、すでにデータ送信部１５から同リクエスト番組データを送信しているクライアント２０の数とから決定される状態が、図３のどの領域に存在するかを調べる（ステップＳ２）。
【００３４】
ここで、図３は、リクエスト処理部１２が持つ通信手段選択のための判断基準の一例を表したもので、例えば、広い通信帯域を必要とする番組データや送信するクライアントの数が多数の場合、すなわち、図３の領域Ｂに位置する場合には、放送用電波を用いたブロードキャストで番組データの送信を行い、逆に狭い通信帯域で十分な番組データや送信するクライアントの数が少ない場合、すなわち、図３の領域Ａに位置する場合には、電話回線を用いたユニキャストで番組データの送信を行う。
【００３５】
クライアント２０から番組データのリクエストを受け付けた時点で、すでに図３の領域Ｂに位置する場合には、同番組データはブロードキャストで送信されている状態にあるので、サーバ１０の通信手段選択部１４はリクエストを行ったクライアント２０に対しブロードキャストで送信されている番組データの受信を指示する（ステップＳ３，Ｓ４）。
【００３６】
クライアント２０から番組データのリクエストを受け付けた時点で、図３の領域Ａに位置する場合には、クライアント数が１増えることで領域Ｂに移行するかどうかを調べる（ステップＳ５）。領域Ｂに移行しない場合には、サーバ１０の通信手段選択部１４はリクエストを行ったクライアント２０に対しユニキャストで送信される番組データの受信を指示し（ステップＳ６）、データ送信部１５からクライアント２０に対してユニキャストで同番組データの送信を開始する（ステップＳ７）。
【００３７】
一方、クライアント数が１増えたことで、図３の領域Ａから領域Ｂに移行する場合には、サーバ１０の通信手段選択部１４は、同リクエスト番組データを受信している全てのクライアント２０に対し、通信手段をユニキャストからブロードキャストに切り替える指示を出し（ステップＳ８）、さらに、通信手段選択部１４はデータ送信部１５に同番組データの送信をユニキャストからブロードキャストに切り替えるよう指示を出す。また、リクエストを行ったクライアント２０に対してはブロードキャストで送信される番組データの受信を指示する。
【００３８】
クライアント２０は利用者から番組データのリクエストを受け付け、図４に示される処理手順に従い番組データの受信を行う。データリクエスト部２１は、利用者からのリクエストに従い、希望する番組データをサーバ１０に対しリクエストする（ステップＳ１１）。リクエストを送信した後、データ選択部２３はサーバ１０から送られてくる番組データを受信するために使用する通信手段の指示を待ちうけ（ステップＳ１２）、送られてきた通信手段に関する指示をデータ受信部２２に受け渡す。
【００３９】
データ受信部２２はデータ選択部２３からの指示に従いブロードキャストで送信される番組データ、あるいはユニキャストで送信される番組データの受信を行い、受信した番組データをデータ出力部２４に受け渡す。データ出力部２４はデータ受信部２２から受け渡された番組データを、例えばディスプレイやスピーカのような既存のデータ出力機器を用いて利用者に提示する。
【００４０】
番組データを受信しているクライアント２０は、サーバ１０からの番組データ送信が終了するか、利用者から新たな番組データのリクエストを受け取る、あるいは番組データの受信停止を指示されるまで番組データの受信と利用者への提示を続ける（ステップＳ１４，Ｓ１５）。その間、データ選択部２３はサーバ１０からの通信手段切り替え指示を待ちうけ（ステップＳ１６，Ｓ１７）、ユニキャストからブロードキャストへの切り替え、あるいはブロードキャストからユニキャストへの切り替え指示を受け取った場合には、データ受信部２２に番組データの受信をブロードキャスト、あるいはユニキャストで行うように指示を出し、データ受信部２２はその指示に従い番組データの受信のために用いる通信手段を切り替える。
【００４１】
番組データを受信しているクライアント２０は、サーバ１０からの番組データ送信が終了するか、利用者から番組データの受信停止を指示されると（ステップＳ１８，Ｓ１９）、データ受信部２２で行っている番組データの受信とデータ出力部２４で行っている番組データの利用者への提示を停止し（ステップＳ２０）、利用者からの番組データリクエストを待ちうける。さらに、データリクエスト部２１はサーバ１０に番組データの受信終了を通知する。
【００４２】
番組データを受信しているクライアント２０は、利用者から新たな番組データのリクエストを受け取ると、その時点で行っているデータ受信部２２の番組データ受信とデータ出力部２４の番組データの利用者への提示を停止し、上述した手順に従い新たにリクエストされた番組データの受信と利用者への提示を行う。
【００４３】
次に、上述の放送システムにおいて、番組データを受信するクライアント２０の数が減少した場合の動作内容を図を用いて具体的に説明する。
【００４４】
サーバ１０は番組データを送信しているクライアント２０から番組データの受信終了通知を受け取ると、図５に示される処理手順に従い、通信手段の再選択を行う。リクエスト処理部１２はクライアント２０から受信終了通知を受け取ると（ステップＳ２１）、その受信が終了した番組データの送信状態が図３のどの領域にあったのかを調べる（ステップＳ２２）。終了通知を受け取る前から領域Ａに位置していた場合には、これまで通りユニキャストで番組データの送信を続ける（ステップＳ２３）。
【００４５】
領域Ｂに位置していた場合には、クライアント２０の数がひとつ減少することにより、送信状態が図３の領域Ｂから領域Ａに移行するがどうかを調べる（ステップＳ２４）。移行しない場合には、これまで通りブロードキャストで番組データの送信を続ける（ステップＳ２５）。領域Ｂから領域Ａに移行する場合には、サーバ１０の通信手段選択部１４は、受信終了を送信してきたクライアント以外で同番組データを受信している全てのクライアント２０に対し、通信手段をブロードキャストからユニキャストに切り替える指示を出し（ステップＳ２６）、さらに、通信手段選択部１４はデータ送信部１５に同番組データの送信をブロードキャストからユニキャストに切り替えるよう指示を出す。データ送信部１５は通信手段選択部１４の指示に従い、通信手段をユニキャストに切り替えて番組データの送信を続ける。
【００４６】
以上で述べたように、本実施の形態の放送システムでは、番組データをリクエストするクライアントの数の増減に従い通信手段を動的に切り替えるため、多数のクライアントに対してユニキャストで送信を行うために多くの通信帯域を占有する、あるいは、少数のクライアントに対しコストのかかるブロードキャストで送信を行うといった通信経路の利用の無駄を抑え、効率的な運用が可能となる。
【００４７】
また、上記実施の形態の説明では、図３の領域Ａと領域Ｂに位置する時の通信手段としては、電話回線上のユニキャストと放送電波上のブロードキャストのように通信経路と通信方式の双方が異なるものとしているが、通信経路は同一で通信方式のみを切り替える形態、あるいは、通信方式は同一で通信経路のみを切り替える形態でもよい。
【００４８】
また、上記実施の形態の説明では、番組データをリクエストしてくるクライアント２０の数は、リクエスト処理部１２に実際にリクエストを送信してくるクライアント２０の数を用いることとしているが、番組データをリクエストしてくるクライアント数の時間推移を視聴率調査などにより予め予想しておき、その予想クライアント数をもとに番組データを送信するために使用する通信手段を動的に切り替えるようにし、通信手段選択部１４はクライアント２０に対する通信手段の切り替え指示をブロードキャストを用いて行う形態でもよい。
【００４９】
上記の実施の形態では、クライアント２０からサーバ１０にリクエストを送る必要がないため、クライアント２０からサーバ１０向きの通信経路を用意することなしに通信手段を動的に変化させる放送システムを構成することが可能となる。
【００５０】
次に、上述の放送システムにおいて、番組データを受信するクライアント２０が番組ダイジェストの配信をリクエストした場合の動作内容を、図を用いて具体的に説明する。ここで、番組ダイジェストとは、番組データの一部を抜き出す、あるいは再生速度を上げることにより、同番組データの提示に本来要する時間よりも短時間で提示することが出来る番組データのことである。
【００５１】
クライアント２０が番組ダイジェストの配信をリクエストした時にサーバ１０から送信されている番組データの流れを図６に示す。図６は、クライアント２０が番組データＣをリクエストした時刻Ｒで、すでに同番組データＣがブロードキャストで他のクライアント２０に（リクエスト時刻Ｒ−番組開始時刻Ｓ）時間分の送信が行われている状態を表している。また、同番組データＣは番組終了時刻Ｅで送信が終了する。
【００５２】
図７は、番組データＣをリクエストしたクライアント２０が、同番組データを番組データＣの途中であるリクエスト時刻Ｒからではなく、番組データＣ全体である番組開始時刻Ｓから番組終了時刻Ｅまでの範囲で受信するために、サーバ１０に対し番組ダイジェストのリクエストを行った時の番組データの流れを示したものである。クライアント２０はリクエスト時刻Ｒからダイジェスト終了時刻Ｄまでの間は、ユニキャストにより番組データＣの番組ダイジェストを受信し、ダイジェスト終了時刻Ｄから番組終了時刻Ｅまではブロードキャストにより番組データＣを受信する。
【００５３】
上記図６と図７の番組データの流れを実現するサーバ１０の動作手順を図８に、クライアントの動作手順を図９に、それぞれ示す。ここで、図中の時間Ｔ１、Ｔ２は番組ダイジェストの生成動作を決めるパラメータで、Ｔ１＞Ｔ２という制約条件を満たす任意の値、例えばＴ１＝１０分、Ｔ２＝３分が設定されている。また、図中の縮尺Ｐは生成する番組ダイジェストの長さを決めるパラメータで、Ｐ＞０という制約条件を満たす任意の値、例えばＰ＝２が設定されている。
【００５４】
サーバ１０は、ブロードキャストによりデータ蓄積部１１に蓄積された番組データＣの送信を行いながら、リクエスト処理部１２でクライアント２０からの番組データリクエストを常時待ちうけておき、リクエストがあった場合には、図８に示される処理手順に従いデータ蓄積部１１に蓄積されている番組データＣの番組ダイジェストの送信を行う。
【００５５】
リクエスト処理部１２はリクエストを受け付けると（ステップＳ３１）、（番組終了時刻Ｅ−リクエスト時刻Ｒ）の値が時間Ｔ１以下であるかどうかを調べる（ステップＳ３２）。時間Ｔ１未満である場合には、ダイジェスト終了時刻Ｄを番組終了時刻Ｅと同じ値に設定し（ステップＳ３３）、番組ダイジェストの生成処理へと進む。時間Ｔ１以上である場合には、（リクエスト時刻Ｒ−番組開始時刻Ｓ）／Ｐの値が時間Ｔ２未満であるかどうかを調べ（ステップＳ３４）、時間Ｔ２未満である場合には、ダイジェスト終了時刻Ｄを（リクエスト時刻Ｒ−番組開始時刻Ｓ）／Ｐ＋リクエスト時刻Ｒに設定する（ステップＳ３５）。時間Ｔ２以上である場合には、ダイジェスト終了時刻Ｄを（時間Ｔ２＋リクエスト時刻Ｒ）に設定する（ステップＳ３６）。
【００５６】
ダイジェスト生成部１３は、クライアント２０からのリクエストに従いリクエスト処理部１２で決定されたダイジェスト終了時刻Ｄをもとに、例えば特開平０９−１３８６９３号公報や特開平０９−２７０９９７号公報に開示の公知の手法を用いて、番組データＣの番組開始時刻Ｓからダイジェスト終了時刻Ｄまでの長さの番組データから、（ダイジェスト終了時刻Ｄ−リクエスト時刻Ｒ）の値だけの長さを持つ番組ダイジェストを生成する（ステップＳ３７）。
【００５７】
データ送信部１５は、ダイジェスト生成部１３が生成した番組ダイジェストを番組データＣをリクエストしてきたクライアント２０に対しユニキャストで送信する（ステップＳ３８）。番組ダイジェストの送信が終了すると、通信手段選択部１４は同クライアント２０に通信手段をユニキャストからブロードキャストに切り替える指示を出す（ステップＳ３９）。また、データ送信部１５は前述の番組ダイジェストを送信する間も、番組データＣのブロードキャストによる送信は並行して行っている。
【００５８】
サーバ１０に対し番組データＣの番組ダイジェストをリクエストしたクライアント２０は、図９に示される処理手順に従い、番組データの受信を行う。データリクエスト部２１は、利用者が希望する番組データＣの番組ダイジェストをサーバ１０に対しリクエストする（ステップＳ４１）。リクエストを送信した後、データ受信部２２はサーバ１０からユニキャストで送信される番組データＣの番組ダイジェストを受信し、受信した番組ダイジェストをデータ出力部２４に受け渡す。データ出力部２４はデータ受信部２２から受け渡された番組ダイジェストを、例えばディスプレイやスピーカのような既存のデータ出力機器を用いて利用者に提示する（ステップＳ４２）。
【００５９】
データ選択部２３は、データ受信部２２が番組ダイジェストを受信している一方でサーバ１０からの通信手段の切り替え指示を待ちうけ、サーバ１０からブロードキャストに切り替える指示を受信すると（ステップＳ４３）、データ受信部２２にブロードキャストで番組データの受信を行うよう指示を出す。データ選択部２３からブロードキャストに切り替える指示を受け取ったデータ受信部２２は、ユニキャストでの番組ダイジェストの受信を終了し、ブロードキャストで送信されている番組データＣの受信を開始する。受信した番組データＣはデータ出力部２４に受け渡され利用者に提示される（ステップＳ４４）。
【００６０】
以上で述べたように、本実施の形態の放送システムでは、クライアントは番組データをリクエストした時点ですでに送信済みである番組データを番組ダイジェストとして受信し、番組ダイジェストの受信終了後はブロードキャストで送信されている番組データを受信するという形式になっているため、番組データの途中で同番組をリクエストしても番組データの開始時点からのデータを得ることが出来、かつ、サーバは番組ダイジェストの送信以外ではブロードキャストにより番組データを送信するため、異なる時刻に複数のクライアントからリクエストがあっても番組ダイジェスト以外の共通部分の送信に必要な通信帯域は一定であるので、番組データの送信に要する通信帯域を、個々の端末にユニキャストで番組データを送信する場合に比べ、少なくすることが可能となる。
【００６１】
また、クライアントは番組データを番組開始時刻より遅れて受信開始しても、番組データの受信終了時刻を番組終了時刻と同一にすることが可能となる。
【００６２】
また、上記実施の形態の説明では、通信方式はユニキャストとブロードキャストで切り替えるとしているが、通信経路に関しては同一であっても異なっていてもよい。
【００６３】
また、上記実施の形態の説明では、クライアント２０が番組データ、あるいは番組ダイジェストを受信するために使用する通信方式をユニキャストからブロードキャストに切り替えるタイミングは、サーバ１０からの切り替え指示を受信した時点としているが、サーバ１０からは切り替え指示を一切出さずに、クライアント２０は送信されてくる番組ダイジェストが終了した時点を通信方式の切り替えタイミングと判断するようにしてもよい。
【００６４】
また、上記実施の形態の説明では、ダイジェスト生成部１３は番組開始時刻Ｓからダイジェスト終了時刻Ｄまでの範囲の番組データから番組ダイジェストを生成するとなっており、番組ダイジェスト生成の範囲はサーバ１０で決定されるようになっているが、クライアント２０が番組ダイジェストをリクエストする際に、番組ダイジェストを生成する範囲の開始時刻と縮尺Ｐの一方、あるいは両方を受け渡すようにしておき、ダイジェスト生成部１３では、クライアント２０から受け渡されたパラメータをもとに番組ダイジェストを生成する範囲を決定するようにしてもよい。
【００６５】
また、上記実施の形態の説明では、ダイジェスト生成部１３での番組ダイジェスト生成が終了してからデータ送信部１５がクライアント２０に番組ダイジェストを送信するとなっているが、ダイジェストの生成とデータの送信は並列的に行ってもよい。
【００６６】
また、上記実施の形態の説明では、ダイジェスト生成部１３での番組ダイジェスト生成はクライアント２０からリクエストがあった時点で行うものとしているが、例えば、番組データの先頭から、長さ５分、１０分、１５分、……と、５分刻に切り出した番組データを、予め長さが５分の番組ダイジェストに変換してデータ蓄積部１１に蓄積しておき、クライアント２０から番組ダイジェストのリクエストがあった時のダイジェスト生成部１３の処理手順を、（リクエスト時刻Ｒ−番組開始時刻Ｓ＋５）の値に最も近い長さの番組ダイジェストを選択する作業に置き換えてもよい。
【００６７】
次に、上述の放送システムにおいて、サーバ１０から送信する番組データが予めデータ蓄積部１１に蓄積されたものではなく、データ作成部１６でリアルタイムに作成されたものである場合の動作内容について具体的に説明する。
【００６８】
データ作成部１６は、例えば、既存のビデオカメラとＭＰＥＧ２エンコーダから構成されており、撮影した映像をリアルタイムにＭＰＥＧ２形式の映像データに変換する。データ作成部１６は、変換したＭＰＥＧ２形式の映像データを番組データとしてデータ蓄積部１１に蓄積するとともにデータ送信部１５に受け渡して、同番組データをリクエストしたクライアント２０に対し送信する。このとき、サーバ１０とクライアント２０が前述の図２から図９で示される処理手順に従い動作することで、リアルタイムで作成される同番組データをリクエストするクライアント２０の数の増減に対する通信手段の動的な変更と、同番組データの番組ダイジェストの送信を実現することが出来る。
【００６９】
また、上記実施の形態において、リクエスト処理部１２に、番組データをクライアント２０に送信する際に使用する通信手段の種類と、ダイジェスト生成部１３が番組ダイジェストを生成するために使用するアルゴリズムや番組ダイジェストの生成範囲と生成される番組ダイジェストの時間長によって決定される番組ダイジェストの品質の組み合わせに応じて、クライアント２０からのリクエストに対して課金を行う機能を付け加えてもよい。
【００７０】
例えば、スポーツ中継の番組データを放送する場合に、番組データの最初の２時間はブロードキャストで番組データを送信し、クライアント２０の利用者からは特に料金を徴収しない。番組データの送信が２時間経過した後はユニキャストでの送信に切り替え、引続き視聴を希望する利用者はクライアント２０を通じてサーバ１０にスポーツ中継の番組データをリクエストする。サーバ１０は、リクエストを送信してきたクライアント２０に対してのみスポーツ中継の番組データをユニキャストで放送するとともに、リクエストを送信してきたクライアント２０の利用者に対して、例えば１００円の課金を行う。
【００７１】
また、上記実施の形態において、リクエスト処理部１２でクライアント２０の利用者情報（例えば、年齢、性別や嗜好などに関する情報）を予め管理しておき、その利用者情報を用いて、番組データをクライアント２０に送信する際に使用する通信手段の種類と、ダイジェスト生成部１３が生成する番組ダイジェストの品質を決定する機能を、リクエスト処理部１２に付け加えてもよい。
【００７２】
また、上記実施の形態において、通信手段選択のための判断基準を示した図３の領域Ｂに位置する時に使用する通信手段はブロードキャストとしているが、マルチキャストを用いる、あるいは、図１０に示されるように、領域Ｂを領域Ｂ１と領域Ｂ２に分割し、領域Ｂ１ではマルチキャストを、領域Ｂ２ではブロードキャストを用いるようにしてもよい。
【００７３】
上記実施の形態において、通信手段選択のための判断基準を示した図３は、番組データを送信するために必要な通信帯域と番組データをリクエストしてくるクライアント数を軸に構成されているが、番組データを送信するために必要な通信コスト、番組データの制作費などを含めて構成してもよい。
【００７４】
【発明の効果】
以上の説明から明らかなように、本発明によれば、番組データをリクエストするクライアント数の増減に従いデータ送信に使用する通信手段を動的に変化させることが可能となるので、通信経路の効率的な利用とコストの低減が実現されるという効果がある。また、番組ダイジェストの送信を行うことにより、クライアントが番組データの受信を開始する時刻が番組データの開始時刻より遅れても、番組データを先頭から受信し、かつ、番組データの受信終了時刻を番組終了時刻と同一にすることが可能となる。さらに、その際に必要となる通信経路は必要最小限に押さえられるという効果や、クライアントに補助記憶装置を用意する必要がないという効果もある。
【図面の簡単な説明】
【図１】本発明の実施の形態による放送システムのブロック構成図である。
【図２】本実施の形態における、クライアント数が増加した場合にサーバが通信手順を動的に切り替えながら番組データを送信する処理手順を示した図である。
【図３】本実施の形態における、通信手順を切り替える判断基準を示した図である。
【図４】本実施の形態における、クライアントが通信手順を動的に切り替えながら番組データを受信する処理手順を示した図である。
【図５】本実施の形態における、クライアント数が減少した場合にサーバが通信手順を動的に切り替えながら番組データを送信する処理手順を示した図である。
【図６】本実施の形態における、番組データの送信状況を示した図である。
【図７】本実施の形態における、クライアントが番組ダイジェストをリクエストした時の番組データと番組ダイジェストの送信状況を示した図である。
【図８】本実施の形態における、クライアントが番組ダイジェストをリクエストした時にサーバが番組ダイジェストと番組データを送信する処理手順を示した図である。
【図９】本実施の形態における、クライアントが番組ダイジェストをリクエストした時にクライアントが番組ダイジェストと番組データを受信する処理手順を示した図である。
【図１０】本実施の形態における、通信手順を切り替える判断基準の他の例を示した図である。
【符号の説明】
１０ サーバ
１１ データ蓄積部
１２ リクエスト処理部
１３ ダイジェスト生成部
１４ 通信手順選択部
１５ データ送信部
１６ データ作成部
２０ クライアント
２１ データリクエスト部
２２ データ受信部
２３ データ選択部
２４ データ出力部
Claims (16)
- サーバと複数のクライアントとが、前記クライアントからの要求に応答して動的に通信方式や通信経路が変更制御される通信媒体を介して接続され、前記要求に応答して前記サーバが番組データを送信するようにした放送システムであって、前記サーバは、前記番組データを送信している期間中に他のクライアントからこの番組データの要求があった場合、この番組データの送信開始から当該要求を受信するまでの間に送信済みの番組データと、前記クライアントに番組のダイジェストデータを送信する間に送信される予定の番組データとから前記番組データの少なくとも送信終了時刻までに送信が終了する長さのダイジェストデータを生成するダイジェスト生成手段と、このダイジェストデータとそれに続く番組データとを、通信路を切替えて送信する送信手段とを含むことを特徴とする放送システム。
- 前記クライアントは、前記ダイジェストデータを受信し、この受信終了後には送信中の前記番組データを受信するよう切替える手段を更に含むことを特徴とする請求項１記載の放送システム。
- 前記ダイジェスト生成手段は、前記ダイジェストデータを生成する範囲の開始点を、前記番組データの開始点からではなく前記クライアントの指示した時点からとすることを特徴とする請求項１または２記載の放送システム。
- 前記ダイジェストデータの生成範囲の終了時点を、前記クライアントが指定可能としたことを特徴とする請求項１〜３いずれか記載の放送システム。
- 前記番組データの１以上のダイジェストデータを予め蓄積する蓄積手段を更に含み、前記送信手段は、前記クライアントからの要求に応答して前記蓄積手段からダイジェストデータを読み出して送信するようにしたことを特徴とする請求項１記載の放送システム。
- 前記サーバは、前記通信媒体と前記ダイジェストデータの品質に応じて前記クライアントに対する課金をなす手段を、更に含むことを特徴とする請求項１〜５いずれか記載の放送システム。
- 前記サーバは、前記クライアントに関する利用者情報を収集して、前記番組データを送信する際に使用する前記通信媒体と前記ダイジェストデータの品質とを決定する手段を、更に含むことを特徴とする請求項１〜６いずれか記載の放送システム。
- 前記送信手段は、前基番組データを一対多通信で、前記ダイジェストデータを一対一通信で切替えて送信することを特徴とする請求項１〜７いずれか記載の放送システム。
- サーバと複数のクライアントとが、前記クライアントからの要求に応答して動的に通信方式や通信経路が変更制御される通信媒体を介して接続され、前記要求に応答して前記サーバが番組データを送信するようにした放送方法であって、前記サーバにおいて、前記番組データを送信している期間中に他のクライアントからこの番組データの要求があった場合、この番組データの送信開始から当該要求を受信するまでの間に送信済みの番組データと、前記クライアントに番組のダイジェストデータを送信する間に送信される予定の番組データとから前記番組データの少なくとも送信終了時刻までに送信が終了する長さのダイジェストデータを生成するダイジェスト生成ステップと、このダイジェストデータとそれに続く番組データとを、通信路を切替えて送信する送信ステップとを含むことを特徴とする放送方法。
- 前記クライアントにおいて、前記ダイジェストデータを受信し、この受信終了後には送信中の前記番組データを受信するよう切替えるステップを更に含むことを特徴とする請求項９記載の放送方法。
- 前記ダイジェスト生成ステップは、前記ダイジェストデータを生成する範囲の開始点を、前記番組データの開始点からではなく前記クライアントの指示した時点からとすることを特徴とする請求項９または１０記載の放送方法。
- 前記ダイジェストデータの生成範囲の終了時点を、前記クライアントが指定可能としたことを特徴とする請求項９〜１１いずれか記載の放送方法。
- 前記送信ステップは、前記クライアントからの要求に応答して、前記番組データの１以上のダイジェストデータを予め蓄積した蓄積手段からダイジェストデータを読み出して送信するようにしたことを特徴とする請求項９記載の放送システム。
- 前記サーバにおいて、前記通信媒体と前記ダイジェストデータの品質に応じて前記クライアントに対する課金をなすステップを、更に含むことを特徴とする請求項９〜１３にいずれか記載の放送方法。
- 前記サーバにおいて、前記クライアントに関する利用者情報を収集して、前記番組データを送信する際に使用する前記通信媒体と前記ダイジェストデータの品質とを決定するステップを、更に含むことを特徴とする請求項９〜１４いずれか記載の放送方法。
- 前記送信ステップは、前記番組データを一対多通信で、前記ダイジェストデータを一対一通信で切替えて送信することを特徴とする請求項９〜１５いずれか記載の放送方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000310007A JP4132630B2 (ja) | 2000-10-11 | 2000-10-11 | 放送システム及びその方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000310007A JP4132630B2 (ja) | 2000-10-11 | 2000-10-11 | 放送システム及びその方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002118553A JP2002118553A (ja) | 2002-04-19 |
| JP4132630B2 true JP4132630B2 (ja) | 2008-08-13 |
Family
ID=18790040
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000310007A Expired - Lifetime JP4132630B2 (ja) | 2000-10-11 | 2000-10-11 | 放送システム及びその方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4132630B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4408677B2 (ja) | 2002-11-29 | 2010-02-03 | キヤノン株式会社 | 受信装置及び受信方法 |
| JP2005020235A (ja) * | 2003-06-25 | 2005-01-20 | Nec Access Technica Ltd | コンテンツ録画予約サービスシステム及びその方法及びそのプログラム |
| KR100611985B1 (ko) * | 2004-07-27 | 2006-08-11 | 삼성전자주식회사 | 실시간 컨텐츠 관리 방법, 소오스 장치 및 싱크 장치 |
| US8155580B2 (en) * | 2006-06-23 | 2012-04-10 | Qualcomm Incorporated | Methods and apparatus for efficient data distribution to a group of users |
| JP2009089131A (ja) * | 2007-10-01 | 2009-04-23 | Kddi Corp | オンデマンド放送装置、受信装置およびシステム |
| JP6969520B2 (ja) * | 2018-08-02 | 2021-11-24 | 日本電信電話株式会社 | 通信装置および切替方法 |
-
2000
- 2000-10-11 JP JP2000310007A patent/JP4132630B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002118553A (ja) | 2002-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11831962B2 (en) | Switched multicast video streaming | |
| US8769593B1 (en) | Client terminal for storing an initial program segment and appending a remaining program segment to provide a video program on demand | |
| JP3320976B2 (ja) | ビデオオンデマンドを提供する方法及びビデオオンデマンド・システム | |
| JP4165686B2 (ja) | デジタルコンテンツの配信方法およびシステム | |
| US9237361B2 (en) | Method and apparatus for content delivery | |
| EP1935177B1 (en) | Systems and methods for recording multiple programs simultaneously with a single tuner | |
| US7657337B1 (en) | Skip feature for a broadcast or multicast media station | |
| EP1071287A2 (en) | Television advertisement delivery system and method | |
| JP4268496B2 (ja) | コンテンツの記録に要する記録メディアの記録容量を節約する放送記録システム、記録装置、放送装置および記録プログラム | |
| KR20080067337A (ko) | 복수의 디바이스에 어드레스 지정된 오디오-비디오콘텐츠의 수신 | |
| WO2012001575A2 (en) | System and method for managing distributed content | |
| CN101710968B (zh) | 一种双向机顶盒共享收看点播节目的方法及其数字电视广播系统 | |
| JP4132630B2 (ja) | 放送システム及びその方法 | |
| WO2005081528A1 (ja) | 情報配信システム及び方法とその情報配信装置、受信端末、情報中継装置 | |
| JP2007324897A (ja) | 配信サーバ及びクライアント端末 | |
| JP5045715B2 (ja) | 放送受信装置 | |
| US20010021999A1 (en) | Method and device for transmitting data units of a data stream | |
| KR101541540B1 (ko) | 컨텐츠 다운로드 서비스 제공 방법 및 장치 | |
| KR20040041574A (ko) | 네트워크를 거쳐서 데이터를 전달하는 시스템 | |
| JP2004146869A (ja) | ビデオ・オン・デマンド・システム、方法、プログラムおよび該ビデオ・オン・デマンド・プログラムを記録したコンピュータ読取り可能な記録媒体 | |
| WO2003103293A1 (en) | Client terminal for providing video on demand | |
| JP2002112231A (ja) | 映像配信・受信システム | |
| JP3588386B2 (ja) | ビデオ・オン・デマンド提供システム及びビデオ・オン・デマンド提供方法 | |
| JP3577302B2 (ja) | ビデオデータ配信装置 | |
| JP3553900B2 (ja) | オンデマンド放送システムおよび受信端末 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041217 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041228 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050228 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050405 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050606 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050628 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050719 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20050719 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050719 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050908 |
|
| A912 | Removal of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20060106 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20070117 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080602 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110606 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4132630 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110606 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120606 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120606 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130606 Year of fee payment: 5 |