配信速度制御装置、配信システム、配信速度制御方法、及び配信速度制御用プログラム
【課題】通信回線の伝送速度の変動の影響を受けることなく、配信された配信情報の再生までの時間を短縮することが可能な配信速度制御装置、配信システム、配信速度制御方法、及び配信速度制御用プログラムを提供する。
【解決手段】本発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する前記配信速度制御装置において、前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御手段を備える。
【解決手段】本発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する前記配信速度制御装置において、前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御手段を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツデータ等の配信情報を例えばストリーミング方式で配信する配信元装置と、当該配信情報の配信を受ける配信先装置と、を備える配信システム等の技術分野に関する。
【背景技術】
【０００２】
この種の配信システムにおいて、配信元装置である配信サーバからストリーミング方式で配信先装置である例えばクライアントにコンテンツデータが配信される場合、当該クライアントでは、ある程度のデータがバッファメモリに貯まった（蓄積された）時点で、コンテンツデータの再生が開始され、バッファメモリには、常に一定のデータが蓄積されるようになっている（例えば、特許文献１参照）。これは、配信元装置と、配信先装置とを接続する通信回線の伝送速度の変動の影響を吸収するためである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−１６９０８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の配信システムでは、通信回線が混雑しているような場合、バッファメモリにデータを蓄積するのに時間がかかり、コンテンツデータの再生が開始されるまで時間がかかってしまい、ユーザにとって好ましくない。特に、ストリーミングのチャンネルが多くある場合、ユーザは最初にいろいろなチャンネルを視聴してから一つのチャンネルに落ち着く場合が想定されるが、このような場合に、毎回十分なデータ量までバッファメモリに蓄積（バッファリング）することは、ユーザにとっての利便性が良くない。
【０００５】
一方で、バッファメモリに蓄積するデータ量を少なくすると、再生までの時間は短くなるが、伝送速度の変動の影響を受けやすく、再生が停止してしまうという問題が生じる。
【０００６】
本発明は、以上の問題等に鑑みてなされたものであり、通信回線の伝送速度の変動の影響を受けることなく、配信された配信情報の再生までの時間を短縮することが可能な配信速度制御装置、配信システム、配信速度制御方法、及び配信速度制御用プログラムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する前記配信速度制御装置において、前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御手段と、を備え、前記速度制御手段は、前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする。
【０００８】
この発明によれば、配信先装置に配信された配信情報の当該配信先装置における再生出力速度以上の範囲において、当該配信情報の蓄積量に基づき配信速度を変更する速度制御を行うように構成したので、通信回線の伝送速度の変動の影響を受けることなく、配信された配信情報の再生までの時間を短縮することができる。また、蓄積手段の蓄積量が第１蓄積量より少ない場合、配信速度が、再生出力速度より速い第１配信速度になるように制御し、蓄積量が第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、上記配信速度が、第１配信速度より遅く、且つ、再生出力速度より速い第２配信速度になるように制御し、更に、蓄積量が第２蓄積量以上の場合、配信速度が前記再生出力速度に追従する第３配信速度になるように制御するように構成したので、第１配信速度で配信情報を配信する時間を短くすることができ、したがって、配信元装置への負担を小さくすることができる。
【０００９】
また、請求項２に記載の発明は、請求項１に記載の配信速度制御装置において、前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始させる再生制御手段を備えることを特徴とする。
【００１０】
また、請求項３に記載の発明は、請求項２に記載の配信速度制御装置において、前記速度制御手段は、前記第２配信速度を、前記配信元装置と前記配信先装置とを接続する通信回線における伝送速度の変動を相殺するように設定することを特徴とする。
【００１１】
また、請求項４に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムにおいて、請求項１から３のいずれか一項に記載の配信速度制御装置を、備えることを特徴とする。
【００１２】
また、請求項５に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置の配信速度制御方法において、前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御工程を含み、前記速度制御工程は、前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする。
【００１３】
また、請求項６に記載の発明は、請求項５に記載の配信速度制御方法において、前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始することを特徴とする。
【００１４】
また、請求項７に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置に含まれるコンピュータを、請求項１から３のいずれか一項に記載の配信速度制御装置として機能させることを特徴とする。
【００１５】
この発明によれば、第１配信速度で配信情報を配信する時間を短くすることができ、したがって、配信元装置への負担を小さくすることができる。また、他の配信元装置に比べ配信速度の速い配信元装置を多くの配信先装置で効率良く利用することができる。さらに、他の配信元装置群に比べ配信速度の速い配信元装置群を多くの配信先装置で効率良く利用することができ、また、配信元装置群のうちの１つの配信元装置が機能停止（ダウン）したときでも、その影響を受けることなく配信情報を再生出力することができる。
【発明の効果】
【００１６】
本発明によれば、配信先装置に配信された配信情報の当該配信先装置における再生出力速度以上の範囲において、当該配信情報の蓄積量に基づき配信速度を変更する速度制御を行うように構成したので、通信回線の伝送速度の変動の影響を受けることなく、配信された配信情報の再生までの時間を短縮することができる。
【発明を実施するための形態】
【００１７】
以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する各実施形態は、コンテンツ配信システムに対して本発明を適用した場合の実施形態である。
【００１８】
（Ｉ）第１実施形態
先ず、本発明の第１実施形態におけるコンテンツ配信システムについて説明する。
【００１９】
始めに、図１乃至図３を参照して、第１実施形態におけるコンテンツ配信システムの構成及び機能について説明する。
【００２０】
図１は、第１実施形態におけるコンテンツ配信システムの概要構成例を示す図であり、図２は、配信サーバの概要構成例を示すブロック図であり、図３は、端末装置の概要構成例を示すブロック図である。
【００２１】
図１に示すように、配信システムとしてのコンテンツ配信システムは、配信されるべき配信情報としてのコンテンツ（例えば映画や楽曲等のコンテンツ）データを配信する配信元装置としての配信サーバ１と、当該コンテンツデータの配信を受ける配信先装置としての端末装置（クライアント）２と、を備えて構成されており、配信サーバ１と端末装置２には、夫々ＩＰ（Internet Protocol）アドレスが割り当てられており、これらはインターネット等のネットワーク３を介して相互に接続されている。
【００２２】
配信サーバ１は、図２に示すように、各種データ及びプログラム，更にはコンテンツデータ等を記憶（格納）するＨＤＤ（Hard Disc Drive）等から構成された記憶部１１と、当該コンテンツデータに含まれる映像情報（ビデオデータ）及び音声情報（オーディオデータ）等をエンコード（データ圧縮や暗号化等）するエンコーダ部１２と、ネットワーク３を通じて端末装置２との間の通信制御を行うための通信部１３と、ＣＰＵ（Central Processing Unit） ，作業用ＲＡＭ（Random-Access Memory），各種データ及びプログラムを記憶するＲＯＭ（Read-Only Memory）等から構成された制御部１４と、を備えて構成され、これらの各構成要素はバス１５を介して相互に接続されている。
【００２３】
制御部１４は、ＣＰＵが記憶部１１等に記憶されたプログラムを読み出して実行することにより、配信サーバ１全体を統括制御し、端末装置２からの要求に応じて、コンテンツデータの配信制御を行う。具体的には、制御部１４は、エンコーダ部１２によりエンコードされたコンテンツデータを、所定のデータ量に分割して連続する複数のデータパケットを生成し、これをデータストリームとして、端末装置２から要求された配信速度（以下、「転送速度」という）で通信部１３等を通じて端末装置２に配信（ストリーミング配信）するようになっている。なお、各データパケットには、そのコンテンツの先頭から連続するパケット番号が付与されている。
【００２４】
端末装置２は、図３に示すように、各種データ及びプログラム等を記憶するＨＤＤ等から構成された記憶部２１と、配信サーバ１からのコンテンツデータを一時的に蓄積（記憶）する蓄積手段としてのバッファメモリ２２と、バッファメモリ２２からのコンテンツデータに含まれる映像情報及び音声情報等をデコード（データ伸張や復号化等）して再生するデコーダ部２３と、当該再生された映像情報等に対して所定の描画処理を施し映像信号として出力する映像処理部２４と、当該映像処理部２４から出力された映像信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部２５と、上記再生された音声情報をアナログ音声信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部２６と、当該音声処理部２６から出力された音声信号を音波として出力するスピーカ２７と、ネットワーク３を通じて配信サーバ１との間の通信制御を行うための通信部２８と、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部２９と、ユーザ（視聴者）からの指示（例えば、再生出力指示、設定指示等）を入力し制御部２９に対してその指示信号を与える入力部（例えば、マウス、キーボード、操作パネル、或いはリモコン等）３０を備えて構成され、記憶部２１、バッファメモリ２２、デコーダ部２３、通信部２８、制御部２９、及び入力部３０はバス３１を介して相互に接続されている。なお、端末装置２としては、例えば、ＳＴＢ（Set Top Box）やパーソナルコンピュータが適用可能である。
【００２５】
バッファメモリ２２は、制御部２９の制御下、例えばＦＩＦＯ（First In First Out）形式のリングバッファメモリから構成されており、受信ポインタにより示される記憶領域に通信部２８を通じて受信されたコンテンツデータを一時的に蓄積し、再生ポインタにより示される記憶領域に格納されているコンテンツデータをバス３１を介してデコーダ部２３に出力するようになっている。
【００２６】
制御部２９は、ＣＰＵが記憶部２１等に記憶されたプログラム（本発明の配信速度制御用プログラムを含む）を読み出して実行することにより、端末装置２全体を統括制御し、かつ、再生制御手段及び速度制御手段等として機能する。なお、配信速度制御用プログラムは、例えば、ネットワーク３上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしてもよい。
【００２７】
再生制御手段としての制御部２９は、バッファメモリ２２におけるコンテンツデータの再生出力（つまり、デコーダ部２３、映像処理部２４、及び音声処理部２６等による再生出力）を制御するようになっており、バッファメモリ２２におけるコンテンツデータの蓄積量（以下、「バッファ量」という）が、当該コンテンツデータの再生出力を開始することが可能となる最小のバッファ量である再生可能バッファ量（本発明における第１蓄積量に対応）５３（例えば、例えば音声情報の場合、例えば１オーディオフレーム分のデータ量、映像情報の場合、例えば１フレーム（ピクチャ）分のデータ量、言い変えれば、デコーダ部２３が必要とする最小のデータ量）となったとき、当該コンテンツデータの再生出力を開始させる。
【００２８】
また、速度制御手段としての制御部２９は、配信サーバ１と協働（連携）して、バッファメモリ２２におけるコンテンツデータのバッファ量に基づき配信サーバ１から端末装置２へのコンテンツデータの転送速度を制御するようになっており、当該コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、上記コンテンツデータの再生出力速度以上の範囲において、上記転送速度を変更する制御を行う。
【００２９】
ここで、図４を参照して、制御部２９におけるコンテンツデータの転送速度制御について詳しく説明する。
【００３０】
図４は、コンテンツデータの転送速度が変更（この例では、２段階の変更）される様子を示す概念図である。なお、図４の例において、縦軸がデータ量（ｋbyte）を、横軸が時間（ｔ）を夫々示しており、また、線５１の傾きが転送速度（第１〜第３転送速度）を、線５２の傾きが再生出力速度を示している。また、任意の時間ｔにおける線５１と線５２との間のデータ量がバッファ量（つまり、バッファメモリ２２に蓄積されているコンテンツデータの蓄積量）を示している。
【００３１】
図４の例では、制御部２９は、コンテンツデータのバッファ量が再生可能バッファ量５３より少ない場合、転送速度が再生出力速度より速い第１転送速度（最も速い速度（フルスピード））になるように（図４の“Ａ”の期間）制御し、バッファ量が再生可能バッファ量５３以上であり、かつ、当該再生可能バッファ量より多いで予め設定された設定バッファ量（本発明における第２蓄積量に対応）５４より少ない場合、転送速度が上記第１転送速度より遅く、かつ、再生出力速度より速い第２転送速度になるように（図４の“Ｂ”の期間）制御し、更に、バッファ量が設定バッファ量５４以上の場合、転送速度が再生出力速度に追従する第３転送速度（言い換えれば、デコーダ部２３のデータ消費速度）になるように（図４の“Ｃ”の期間）制御している。つまり、制御部２９は、バッファメモリ２２におけるバッファ量に応じて、配信速度を、コンテンツデータの再生出力速度より速い第１配信速度と、第１配信速度より遅く、且つ、再生出力速度より速い第２配信速度と、再生出力速度に追従する第３配信速度と、に切り換えるように制御するようになっている。
【００３２】
ここで、転送速度は、配信サーバ１側の処理能力、端末装置２側の処理能力、及びネットワーク３経路の帯域幅（バンド幅）の３つの要素で決まるものであるため、第１転送速度（最も速い速度（フルスピード））とは、これらの３つの要素が考慮された上で可能な限り速い（つまり、これらの３つの要素のうちでボトルネックとなる箇所の速度で頭打ちとならない範囲で制御可能）ということを意味する。
【００３３】
また、設定バッファ量５４は、例えばネットワーク３のジッタ（つまり、配信サーバ１と端末装置２とを接続する通信回線における転送速度（伝送速度）の変動、言い換えれば、データパケットの到着時間のずれ（変位））が考慮されて設定されるものであり、コンテンツデータの再生出力が当該ジッタに影響されない（つまり、当該変動により再生出力が途切れない）バッファ量である。図４の“Ｃ”の期間では、転送速度が第３転送速度となって再生出力速度に追従することにより、設定バッファ量５４が維持されている。また、バッファメモリ２２におけるバッファ量が設定バッファ量５４に到達するまでの図４の“Ｂ”の期間では、転送速度は再生出力速度よりも速い第２配信速度になっているが、この第２転送速度は、上記ネットワークのジッタ（転送速度の変動）を相殺するように設定されるものであり、再生出力速度（言い換えれば、データ消費速度）＋調整速度“ａ”（この値は、ネットワークのジッタに応じて決定される）の転送速度となる。
【００３４】
次に、図５乃至図８等を参照して、第１実施形態におけるコンテンツ配信システムの動作について説明する。
【００３５】
図５乃至図８は、第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【００３６】
図５に示す処理は、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、配信サーバ１に対して接続要求（つまり、配信サーバ１に対して接続要求を示す情報を送信）を行う（ステップＳ１）。当該接続要求に対して、配信サーバ１は、所定の認証処理を実行し、良好である場合には、接続了解を示す情報を端末装置２に対して返信する。
【００３７】
接続が了解された場合、制御部２９は、配信サーバ１との間の接続確立処理を行い（ステップＳ２）、次いで、コンテンツデータの配信要求を行う（ステップＳ３）。当該配信要求に対して、配信サーバ１では、要求されたコンテンツデータの配信準備を行うことになる。
【００３８】
次いで、制御部２９は、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ４）、再生可能バッファ量５３未満である場合には（ステップＳ４：Ｌ）、ステップＳ５に示す第１転送速度での要求処理（図６）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ４：Ｍ）、ステップＳ６に示す第２転送速度での要求処理（図７）に移行し、設定バッファ量５４以上である場合には（ステップＳ４：Ｈ）、ステップＳ７に示す第３転送速度での要求処理（図８）に移行する。なお、ユーザが初めてコンテンツの要求指示を行った場合等、未だバッファメモリ２２にデータが蓄積されていない初期の段階では、第１転送速度での要求処理に移行されることになる。
【００３９】
第１転送速度での要求処理においては、図６に示すように、制御部２９は、先ず、配信サーバ１に対して第１転送速度（例えば、４００ｋｂｐｓ（bit per second）程度）での要求（つまり、配信サーバ１に対して第１転送速度でコンテンツデータに係るデータパケットを配信する要求を示す情報を送信）を行う（ステップＳ１１）。当該要求に対して、配信サーバ１は、転送速度を第１転送速度に設定し、当該第１転送速度でデータパケットを端末装置２に配信する（なお、配信サーバ１は、端末装置２から次の要求が来るまで当該第１転送速度で複数のデータパケットを順次送り続ける）ことになり、当該データパケットは、端末装置２の通信部２８を通じて受信され、バッファメモリ２２に蓄積されることになる。
【００４０】
次いで、制御部２９は、配信サーバ１から最後のデータパケットを受信したか否かを判別し（ステップＳ１２）、受信した場合には（ステップＳ１２：Ｙ）、当該配信サーバ１との接続を切り（ステップＳ１９）、バッファメモリ２２に未再生のコンテンツデータが蓄積されているか否かを判別し（ステップＳ２０）、蓄積されている場合（ステップＳ２０：Ｙ）には、バッファメモリ２２における残りのコンテンツデータを再生出力させ（ステップＳ２１）、当該処理を終了する。
【００４１】
一方、最後のデータパケットを受信していない場合には（ステップＳ１２：Ｎ）、制御部２９は、受信されたデータパケットに基づいてネットワーク８のジッタを計測する（ステップＳ１３）。
【００４２】
次いで、制御部２９は、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になったか（言い換えれば、到達したか）否かを判別し（ステップＳ１４）、再生可能バッファ量５３以上になっていない場合には（ステップＳ１４：Ｎ）、ステップＳ１２に戻り、上記と同様の処理を行う。
【００４３】
こうして、ネットワーク８のジッタは、例えば、再生可能バッファ量５３に到達するまでの間の所定時間における各データパケットの到着時間差の平均値、或いは標準偏差によって求められる。
【００４４】
そして、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になった場合には（ステップＳ１４：Ｙ）、制御部２９は、デコーダ部２３等に対して再生開始指令を与える（ステップＳ１５）。これにより、バッファメモリ２２に蓄積されたコンテンツデータの再生出力が開始される。
【００４５】
次いで、制御部２９は、上記ステップＳ１３における計測によって求められたジッタが所定値（例えば、通常許容できるジッタの最大値）よりも大きいか否かを判別し（ステップＳ１６）、当該所定値よりも大きくない場合には（ステップＳ１６：Ｎ）、設定バッファ量５４を規定バッファ量に設定し、かつ、調整速度“ａ”を規定速度に設定し（ステップＳ１８）、図５に示すステップＳ４の処理に戻る。一方、ジッタが所定値よりも大きい場合には（ステップＳ１６：Ｙ）、制御部２９は、設定バッファ量５４を規定バッファ量より大きいバッファ量（例えば、ジッタの大きさに比例した値）に設定し、かつ、調整速度“ａ”を規定速度より大きい速度（例えば、ジッタの大きさに比例した値、つまり、ジッタが大きければバッファ量を増やす）に設定し（ステップＳ１７）、図５に示すステップＳ４の処理に戻る。
【００４６】
次に、第２転送速度での要求処理においては、図７に示すように、制御部２９は、上記配信サーバ１に対して第２転送速度（再生出力速度＋上記設定された調整速度“ａ”。例えば、ジッタが所定値よりも大きくない場合、１５０ｋｂｐｓ程度、ジッタが所定値よりも大きい場合、２００ｋｂｐｓ程度）での要求（転送速度を変更するタイミング）を行う（ステップＳ２３）。当該要求に対して、配信サーバ１は、転送速度を第２転送速度に変更設定し、当該第２転送速度でコンテンツデータに係るデータパケットを端末装置２に配信することになる。
【００４７】
次いで、制御部２９は、配信サーバ１から最後のデータパケットを受信したか否かを判別し（ステップＳ２４）、受信した場合には（ステップＳ２４：Ｙ）、当該配信サーバ１との接続を切り（ステップＳ２６）、バッファメモリ２２に未再生のコンテンツデータが蓄積されている場合（ステップＳ２７：Ｙ）には、バッファメモリ２２における残りのコンテンツデータを再生出力させ（ステップＳ２８）、当該処理を終了する。
【００４８】
一方、最後のデータパケットを受信していない場合には（ステップＳ２４：Ｎ）、制御部２９は、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３未満又は設定バッファ量５４以上（つまり、再生可能バッファ量５３以上設定バッファ量５４以下の範囲外になった）になったか否かを判別し（ステップＳ２５）、再生可能バッファ量５３未満又は設定バッファ量５４以上になっていない場合には（ステップＳ２５：Ｎ）、ステップＳ２４に戻り、上記と同様の処理を行う。
【００４９】
一方、再生可能バッファ量５３未満又は設定バッファ量５４以上になった場合には（ステップＳ２５：Ｙ）、図５に示すステップＳ４の処理に戻る。
【００５０】
なお、データパケットが正常に配信され、バッファメモリ２２に蓄積されていけば、バッファ量が設定バッファ量５４に到達することになるが、例えば、配信サーバ１側、或いは、ネットワーク３経路上における何らかの原因によりデータパケットの配信が滞ることが生じれば、再生可能バッファ量５３未満になる場合もありうる。このような場合にも、当該処理は適切に対応することができる。
【００５１】
次に、第３転送速度での要求処理においては、図８に示すように、制御部２９は、上記配信サーバ１に対して第３転送速度（再生出力速度に追従する速度。例えば、１００ｋｂｐｓ程度）での要求（転送速度を変更するタイミング）を行う（ステップＳ３１）。当該要求に対して、配信サーバ１は、転送速度を第３転送速度に変更設定し、当該第３転送速度でコンテンツデータに係るデータパケットを端末装置２に配信することになる。
【００５２】
次いで、制御部２９は、配信サーバ１から最後のデータパケットを受信したか否かを判別し（ステップＳ３２）、受信した場合には（ステップＳ３２：Ｙ）、当該配信サーバ１との接続を切り（ステップＳ３４）、バッファメモリ２２に未再生のコンテンツデータが蓄積されている場合（ステップＳ３５：Ｙ）には、バッファメモリ２２における残りのコンテンツデータを再生出力させ（ステップＳ３６）、当該処理を終了する。
【００５３】
一方、最後のデータパケットを受信していない場合には（ステップＳ３２：Ｎ）、制御部２９は、バッファメモリ２２におけるバッファ量が設定バッファ量５４未満になったか否かを判別し（ステップＳ３３）、設定バッファ量５４未満になっていない場合には（ステップＳ３３：Ｎ）、ステップＳ３２に戻り、上記と同様の処理を行う。
【００５４】
一方、設定バッファ量５４未満になった場合には（ステップＳ３３：Ｙ）、図５に示すステップＳ４の処理に戻る。
【００５５】
以上説明したように上記第１実施形態によれば、バッファメモリ２２に蓄積されるバッファ量が再生可能バッファ量になるまで第１転送速度（フルスピード）でコンテンツデータを配信し（図４の“Ａ”の期間）、その後、上記バッファ量がネットワーク３のジッタが考慮された設定バッファ量になるまで第２転送速度（再生出力速度＋調整速度“ａ”）でコンテンツデータを配信し（図４の“Ｂ”の期間）、その後、第３転送速度（再生出力速度に追従する速度）でコンテンツデータを配信する（図４の“Ｃ”の期間）というように、上記コンテンツデータの再生出力速度以上の範囲において、バッファ量に応じて上記転送速度を段階的に変更するようにしたので、ネットワーク３のジッタの影響を受けることなく、配信されたコンテンツデータの再生までの時間を短縮することができる。また、図４の“Ａ”の期間において、配信サーバ１がフルスピードでデータパケットを転送（配信）する時間を短くできるので、配信サーバ１への負担を小さくすることができる。
【００５６】
特に、ストリーミングのチャンネルが多くある場合、ユーザは最初にいろいろなチャンネルを視聴してから一つのチャンネルに落ち着く場合が想定されるが、このような場合に、毎回十分なバッファ量までバッファリングするという無駄を省き、迅速に再生開始できるので、ユーザにとっての利便性を向上させることができる。
【００５７】
なお、上記実施形態においては、コンテンツデータの再生出力速度以上の範囲において、上記転送速度を２段階に変更（減速）する例を示したが、これに限定されるものではなく２段階より多く段階的に変更するように構成しても良い。例えば、図４の“Ｂ”の期間において、第２配信速度を複数段階で変化させたり、２次曲線的に変化させるように構成しても良い。
【００５８】
（ＩＩ）第２実施形態
次に、第２実施形態におけるコンテンツ配信システムについて説明する。
【００５９】
上記第１実施形態においては、第１〜第３転送速度は、端末装置２からの要求に応じて配信サーバ１によって設定されるサーバ主導型の形態について説明したが、第２実施形態では、第１〜第３転送速度が端末装置２の要求タイミングで決まるクライアント主導型の形態について、図９乃至図１３等を参照して説明する。なお、第２実施形態における配信サーバ１及び端末装置２の構成及び機能は第１実施形態と基本的には同様であるので、重複した説明は省略する。
【００６０】
図９乃至図１２は、第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートであり、図１３は、端末装置２から配信サーバ１へのデータブロックの要求タイミングの一例を示す図である。
【００６１】
図９に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始される。なお、図９に示すステップＳ４１〜ステップＳ４３までの処理は、図５に示すステップＳ１〜ステップＳ３までの処理と同様であるので重複する説明を省略する。
【００６２】
次に、図９のステップＳ４４では、制御部２９は、コンテンツデータを構成するデータブロックの番号ｉの初期値として“０”を設定（ｉ＝０に設定）する。
【００６３】
ここで、データブロックとは、配信サーバ１側でコンテンツデータがブロック単位（任意のデータ量（例えば数ｋｂｙｔｅ〜数Ｍｂｙｔｅ））に分割されたものであり、夫々のデータブロックに対して例えば連続する固有の番号が付与される。端末装置２は、このデータブロックの番号を指定して配信サーバ１に配信要求することになる。なお、このデータブロックは、更に、複数のデータパケットに分割されて配信される。
【００６４】
次いで、制御部２９は、第１実施形態と同様、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ４５）、再生可能バッファ量５３未満である場合には（ステップＳ４５：Ｌ）、ステップＳ４６に示す第１待ち時間での要求処理（図１０）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ４５：Ｍ）、ステップＳ４７に示す第２待ち時間での要求処理（図１１）に移行し、設定バッファ量５４以上である場合には（ステップＳ４５：Ｈ）、ステップＳ４８に示す第３待ち時間での要求処理（図１２）に移行する。
【００６５】
第１待ち時間での要求処理においては、図１０に示すように、制御部２９は、先ず、配信サーバ１に対してｉ番目のデータブロックを要求（つまり、配信サーバ１に対してｉ番目のデータブロックを配信する要求を示す情報を送信）する（ステップＳ５１）。当該要求に対して、配信サーバ１は、所定の転送速度でデータブロックに係るデータパケットを端末装置２に配信することになり、当該データパケットは、端末装置２の通信部２８を通じて受信され、バッファメモリ２２に蓄積されることになる。
【００６６】
次いで、制御部２９は、データブロックの番号ｉを“１”インクリメントし（ステップＳ５２）、続いて、配信サーバ１から最後のデータパケットを受信したか否かを判別する（ステップＳ５３）。最後のデータパケットを受信していない場合には（ステップＳ５３：Ｎ）、制御部２９は、第１実施形態と同様、受信されたデータパケットに基づいてネットワーク８のジッタを計測し（ステップＳ５４）、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になったか否かを判別する（ステップＳ５５）。
【００６７】
そして、再生可能バッファ量５３以上になっていない場合には（ステップＳ５５：Ｎ）、制御部２９は、第１待ち時間が経過した後（ステップＳ５６）、ステップＳ５１に戻り、次のデータブロック（ステップＳ５２でインクリメントされたｉ番目のデータブロック）を配信サーバ１に対して要求する。
【００６８】
ここで、「待ち時間」は、前回のデータブロックを要求したタイミングからの経過時間を規定するものであり、上記ステップＳ５６では、制御部２９が時計を監視して次の要求タイミングの時刻になるのを待つことになる。これにより、端末装置２のデータブロックの要求タイミングが決まり、複数の要求タイミングの時間間隔によって転送速度が定まることになる。
【００６９】
そして、第２実施形態においては、コンテンツデータのバッファ量が再生可能バッファ量５３より少ない場合、この待ち時間を「第１待ち時間」（例えば、フルスピードで端末装置２がデータブロックを配信サーバ１から引き出す場合、“０”（ゼロ）時間となる。つまり、端末装置２が要求を出せる最大の速度（ＣＰＵの動作速度に依存））として上記第１転送速度になるように制御し、バッファ量が再生可能バッファ量５３以上であり、かつ、当該再生可能バッファ量より多い予め設定された設定バッファ量５４未満の場合、当該待ち時間を「第２待ち時間」（第１待ち時間より長い）として上記第２転送速度になるように制御し、バッファ量が設定バッファ量５４以上の場合、当該待ち時間を「第３待ち時間」（第２待ち時間より長い）として上記第３転送速度になるように制御するようになっている。
【００７０】
例えば、図１３の例には、配信サーバへの要求タイミングを示しているが、“Ａ”の期間では、第１待ち時間により定まる時間間隔“Ｔ１”で配信サーバへのデータブロックの要求がなされており、“Ｂ”の期間では、第２待ち時間により定まる時間間隔“Ｔ２”で配信サーバへのデータブロックの要求がなされており、“Ｃ”の期間では、第３待ち時間により定まる時間間隔“Ｔ３”で配信サーバへのデータブロックの要求がなされている。このように、要求タイミングの時間間隔を変えることによってバッファメモリ２２に蓄積される速さを調整することができる。
【００７１】
なお、図１０に示すステップＳ５７〜ステップＳ６３までの処理は、図６に示すステップＳ１５〜ステップＳ２１までの処理と同様であるので重複する説明を省略する。
【００７２】
次に、第２待ち時間での要求処理においては、図１１に示すように、制御部２９は、先ず、配信サーバ１に対してｉ番目のデータブロックを要求し（ステップＳ６５）、続いて、データブロックの番号ｉを“１”インクリメントし（ステップＳ６６）、続いて、配信サーバ１から最後のデータパケットを受信したか否かを判別する（ステップＳ６７）。最後のデータパケットを受信していない場合には（ステップＳ６７：Ｎ）、制御部２９は、第１実施形態と同様、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３未満又は設定バッファ量５４以上になったか否かを判別し（ステップＳ６８）、再生可能バッファ量５３未満又は設定バッファ量５４以上になっていない場合には（ステップＳ６８：Ｎ）、上述した第２待ち時間が経過した後（ステップＳ６９）、ステップＳ６５に戻り、次のデータブロックを配信サーバ１に対して要求する。
【００７３】
なお、図１１に示すステップＳ７０〜ステップＳ７２までの処理は、図７に示すステップＳ２６〜ステップＳ２８までの処理と同様であるので重複する説明を省略する。
【００７４】
次に、第３待ち時間での要求処理においては、図１２に示すように、制御部２９は、先ず、配信サーバ１に対してｉ番目のデータブロックを要求し（ステップＳ７５）、続いて、データブロックの番号ｉを“１”インクリメントし（ステップＳ７６）、続いて、配信サーバ１から最後のデータパケットを受信したか否かを判別する（ステップＳ７７）。最後のデータパケットを受信していない場合には（ステップＳ７７：Ｎ）、制御部２９は、第１実施形態と同様、バッファメモリ２２におけるバッファ量が設定バッファ量５４未満になったか否かを判別し（ステップＳ７８）、設定バッファ量５４未満になっていない場合には（ステップＳ７８：Ｎ）、上述した第３待ち時間が経過した後（ステップＳ７９）、ステップＳ７５に戻り、次のデータブロックを配信サーバ１に対して要求する。
【００７５】
なお、図１２に示すステップＳ８０〜ステップＳ８２までの処理は、図８に示すステップＳ３４〜ステップＳ３６までの処理と同様であるので重複する説明を省略する。
【００７６】
以上説明したように上記第２実施形態によっても、第１実施形態と同様の効果を有することができることに加え、例えば、配信サーバと端末装置の性能が大きく違う場合に、端末装置からの要求が配信サーバに到達してからデータを転送してもらうので、端末装置側でのデータの取りこぼしがなくなるという効果がある（つまり、端末装置の性能に合わせたデータ転送が可能）。
【００７７】
なお、上記第２実施形態においては、データブロックのサイズ（データ量）を固定とし、要求タイミングの時間間隔を可変としたが、別の例として、要求タイミングの時間間隔を固定とし、データブロックのサイズ（データ量）を可変として制御するように構成しても良い。
【００７８】
（ＩＩＩ）第３実施形態
次に、第３実施形態におけるコンテンツ配信システムについて説明する。
【００７９】
図１４は、第３実施形態、後述する第４及び第５実施形態におけるコンテンツ配信システムの概要構成例を示す図である。
【００８０】
上記第１及び第２実施形態においては、１つの配信サーバ１からコンテンツデータが端末装置２に配信される形態について説明したが、第３実施形態では、図１４に示すように、複数（ここでは、３つ）の配信サーバ１Ａ，１Ｂ，１Ｃの夫々から一のコンテンツデータが分割されたデータブロックが端末装置２に配信（分散ストリーミング配信）される形態について説明する。なお、第３実施形態における配信サーバ１Ａ，１Ｂ，１Ｃ、及び端末装置２の構成及び機能は第１実施形態における配信サーバ１及び端末装置２と基本的には同様であるので、重複した説明は省略する。
【００８１】
配信サーバ１Ａ，１Ｂ，１Ｃは、夫々、コンテンツデータ（データパケット）の転送速度が相互に異なっており、この３つの配信サーバの中で、転送速度は、配信サーバ１Ａが１番速く、配信サーバ１Ｂは配信サーバ１Ａよりは遅いが配信サーバ１Ｃよりは速く、配信サーバ１Ｃは１番遅くなっている。また、これらの配信サーバ１Ａ，１Ｂ，１Ｃは、同一のコンテンツデータを有している。
【００８２】
一方、端末装置２における速度制御手段としての制御部２９は、コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、接続する配信サーバの数を変えるように当該各配信サーバ１Ａ，１Ｂ，１Ｃとの接続を制御する。つまり、制御すべき転送速度となるように、配信サーバ１Ａ〜１Ｃの接続数が変えられる。
【００８３】
この転送速度制御について図４を用いて説明すると、例えば、“Ａ”の期間では、３つの配信サーバ１Ａ，１Ｂ及び１Ｃから夫々最も速い転送速度（例えば、端末装置２から見た全体の転送速度が第１転送速度になる）でデータパケットが配信されるように制御され、“Ｂ”の期間では、コンテンツデータの転送速度が端末装置２から見て第２転送速度になるように２つの配信サーバ１Ｂ及び１Ｃから夫々、データパケットが配信されるように制御され、“Ｃ”の期間では、コンテンツデータの転送速度が第３転送速度になるように１つの配信サーバ１Ｃからデータパケットが配信されるように制御される。
【００８４】
次に、図１５乃至図２０等を参照して、第３実施形態におけるコンテンツ配信システムの動作について説明する。
【００８５】
図１５乃至図１９は、第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートであり、図２０は、端末装置２から配信サーバ１Ａ乃至１Ｃへのデータブロックの要求タイミングの一例を示す図である。
【００８６】
図１５に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、複数の配信サーバ、例えば３つの配信サーバ１Ａ，１Ｂ及び１Ｃの夫々に対して接続要求を行う（ステップＳ１０１）。当該接続要求に対して、配信サーバ１Ａ，１Ｂ及び１Ｃは、夫々、所定の認証処理を実行し、良好である場合には、接続了解を示す情報を端末装置２に対して返信する。
【００８７】
接続が了解された場合、制御部２９は、配信サーバ１Ａ，１Ｂ及び１Ｃとの間の接続確立処理を行い（ステップＳ１０２）、次いで、夫々の配信サーバに対してコンテンツデータの配信要求を行う（ステップＳ１０３）。当該配信要求に対して、配信サーバ１Ａ，１Ｂ及び１Ｃでは、要求されたコンテンツデータの配信準備を行うことになる。
【００８８】
次いで、制御部２９は、コンテンツデータを構成するデータブロックの番号ｉの初期値として“０”を設定（ｉ＝０に設定）する（ステップＳ１０４）。
【００８９】
次いで、制御部２９は、第２実施形態と同様、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ１０５）、再生可能バッファ量５３未満である場合には（ステップＳ１０５：Ｌ）、ステップＳ１０６に示す第１待ち時間での要求処理（図１６）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ１０５：Ｍ）、ステップＳ１０７に示す第２待ち時間での要求処理（図１７）に移行し、設定バッファ量５４以上である場合には（ステップＳ１０５：Ｈ）、ステップＳ１０８に示す第３待ち時間での要求処理（図１８）に移行する。
【００９０】
第１待ち時間での要求処理においては、図１６に示すように、制御部２９は、配信サーバ１Ａの接続処理を行う（ステップＳ１１１）。当該配信サーバ１Ａの接続処理においては、図１９（Ａ）に示すように、制御部２９は、配信サーバ１Ａは既に接続済であるか否か判別し（ステップＳ１５５）、接続済である（例えば、図１５に示す処理の開始直後は接続済となっている）場合には（ステップＳ１５５：Ｙ）、図１６の処理に戻る。一方、接続済でない場合（ステップＳ１５５：Ｎ）には、制御部２９は、複数の配信サーバ１Ａに対して接続要求を行い（ステップＳ１５６）、続いて、配信サーバ１Ａとの間の接続確立処理を行い（ステップＳ１５７）、続いて、配信サーバ１Ａに対してコンテンツデータの配信要求を行い（ステップＳ１５８）、図１６の処理に戻る。
【００９１】
次いで、図１６に示すステップＳ１１２では、制御部２９は、配信サーバ１Ｂの接続処理（図１９（Ｂ））を行う。当該配信サーバ１Ｂの接続処理は、配信サーバ１Ａの接続処理と同様であるので、説明を省略する。
【００９２】
次いで、制御部２９は、アイドル中の配信サーバ（つまり、配信サーバ１Ａ乃至１Ｃのうち、データブロックの配信準備が完了している配信サーバ）に対してｉ番目のデータブロックを要求し（ステップＳ１１３）、続いて、データブロックの番号ｉを“１”インクリメントする（ステップＳ１１４）。アイドル中の配信サーバが複数ある場合には、アイドル時間が長い配信サーバへ要求を出す方法や、転送速度の速い配信サーバへｉ番目のデータブロックを要求を出す方法が考えられる。また、アイドル中の配信サーバが存在しない場合は、接続している配信サーバのいずれかがアイドル状態になるまで待つこととなる。
【００９３】
次いで、制御部２９は、何れかの配信サーバから最後のデータパケットを受信したか否かを判別し（ステップＳ１１５）、最後のデータパケットを受信していない場合には（ステップＳ１１５：Ｎ）、第２実施形態と同様、受信されたデータパケットに基づいてネットワーク８のジッタを計測する（ステップＳ１１６）。
【００９４】
次いで、制御部２９は、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になったか否かを判別し（ステップＳ１１７）、再生可能バッファ量５３以上になっていない場合には（ステップＳ１１７：Ｎ）、第２実施形態と同様、第１待ち時間が経過した後（ステップＳ１１８）、ステップＳ１１３に戻り、次のデータブロックをアイドル中の配信サーバに対して要求する。
【００９５】
こうして、再生可能バッファ量５３以上になるまで、データブロックの要求処理は繰り返されるが、このとき、制御部２９は、例えば、図２０に示すように、処理能力が高い順（つまり、配信サーバ１Ｃ、配信サーバ１Ｂ、配信サーバ１Ａの順に高くなる）にデータブロックの要求間隔を短くするように制御する（なお、図２０中の逆三角印内の番号は、データブロックの要求の順序を示している）。
【００９６】
図２０の例では、第１待ち時間で転送する時間において、第１待ち時間をゼロとしており、ステップＳ１１３からループして戻ってくるまでの時間分だけ遅延がある。つまり、データブロックの配信（転送）が終わった配信サーバへすぐに次のデータブロックの要求が行われる。再生可能バッファ量以上になると第２待ち時間の処理へ移り、第２待ち時間の間隔で配信サーバへ要求がなされる。なお、第３待ち時間の場合も同様である。
【００９７】
なお、図１６に示すステップＳ１１９〜ステップＳ１２２までの処理は、図６に示すステップＳ１５〜ステップＳ２１までの処理と同様であるので重複する説明を省略する。
【００９８】
次いで、ステップＳ１２１の処理後、制御部２９は、配信サーバ１Ａとの接続を切り（ステップＳ１２３）、図１５の処理に戻る。
【００９９】
また、制御部２９が最後のデータパケットを受信した場合には（ステップＳ１１５：Ｙ）、制御部２９は、接続している全ての配信サーバとの接続を切り（ステップＳ１２４）、ステップＳ１２５等を経て、当該処理を終了する。
【０１００】
第２待ち時間での要求処理においては、図１７に示すように、制御部２９は、ステップＳ１１２と同様、配信サーバ１Ｂの接続処理を行う（ステップＳ１３１）。
【０１０１】
次いで、制御部２９は、アイドル中の配信サーバ（つまり、配信サーバ１Ａ及び１Ｂのうち、データブロックの配信準備が完了している配信サーバ）に対してｉ番目のデータブロックを要求し（ステップＳ１３２）、続いて、データブロックの番号ｉを“１”インクリメントする（ステップＳ１３３）。
【０１０２】
次いで、制御部２９は、最後のデータパケットを受信したか否かを判別し（ステップＳ１３４）、最後のデータパケットを受信していない場合には（ステップＳ１３４：Ｎ）、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３未満又は設定バッファ量５４以上になったか否かを判別し（ステップＳ１３５）、再生可能バッファ量５３未満又は設定バッファ量５４以上になっていない場合には（ステップＳ１３５：Ｎ）、第２実施形態と同様、上述した第２待ち時間が経過した後（ステップＳ１３６）、ステップＳ１３２に戻り、次のデータブロックをアイドル中の配信サーバに対して要求する。
【０１０３】
また、制御部２９が最後のデータパケットを受信した場合には（ステップＳ１３４：Ｙ）、制御部２９は、接続している全ての配信サーバとの接続を切り（ステップＳ１３８）、ステップＳ１２５等を経て、当該処理を終了する。
【０１０４】
なお、図１８に示す第３待ち時間での要求処理は、図１２に示す第３待ち時間での要求処理と同様であるので、重複した説明を省略する。
【０１０５】
以上説明したように上記第３実施形態によれば、第２実施形態と同様の効果を有することに加え、例えば他の配信サーバに比べ転送速度の速い配信サーバを多くの端末装置で効率良く利用することができる。また、第３実施形態のように、配信サーバの接続数を次第に減らしていく方法は、同じコンテンツデータを持つ配信サーバが少ない場合に有効である。
【０１０６】
なお、上記第３実施形態においては、転送速度が相互に異なる複数の配信サーバを例にとって説明したがこれに限定されるものではなく、例えば、コンテンツ配信システムが、相互に同一の転送速度を有する複数の配信サーバからなる配信サーバ群であって、当該転送速度が相互に異なる複数の配信サーバ群を備え、複数の配信サーバ群から一のコンテンツデータが分割されて夫々端末装置２に配信されるようにし、端末装置２の制御部２９が、上記転送速度を変更するタイミングで、接続する配信サーバ群の数を変えるように各配信サーバ群との接続を制御するようにしても良い。
【０１０７】
図２１は、転送速度が相互に異なる３つの配信サーバ群を備えるコンテンツ配信システムの概要構成例を示す図である。図２１の例では、転送速度が最も速い配信サーバ群１Ｄと、転送速度が普通の配信サーバ群１Ｅと、転送速度が最も遅い配信サーバ群１Ｆと、が示されており、夫々の配信サーバ群１Ｄ〜１Ｆは、相互に同一の転送速度を有する３つの配信サーバを備えている。このような構成において、制御すべき転送速度となるように、例えば図１５乃至図１９の処理によって、配信サーバ群１Ｄ〜１Ｆの接続数が変えられる（例えば、図１５乃至図１９の処理において、配信サーバ１Ａが配信サーバ群１Ｄに、配信サーバ１Ｂが配信サーバ群１Ｅに、配信サーバ１Ｃが配信サーバ群１Ｆに、夫々対応する）。このように構成すれば、配信サーバ群のうちの１つの配信サーバが機能停止（ダウン）したときでも、その影響を受けることなくコンテンツデータを再生出力することができる。
【０１０８】
（ＩＶ）第４実施形態
次に、第４実施形態におけるコンテンツ配信システムについて説明する。
【０１０９】
第４実施形態では、図１４に示す複数（ここでは、３つ）の配信サーバ１Ａ，１Ｂ，１Ｃとの接続が順次切り換えられ、コンテンツデータが端末装置２に配信される形態について説明する。
【０１１０】
なお、第４実施形態における配信サーバ１Ａ，１Ｂ，１Ｃ、及び端末装置２の構成及び機能は第１実施形態における配信サーバ１及び端末装置２と基本的には同様であるので、重複した説明は省略する。
【０１１１】
また、第４実施形態においても、第３実施形態と同様、配信サーバ１Ａ，１Ｂ，１Ｃは、夫々、コンテンツデータ（データパケット）の転送速度が相互に異なっており、この３つの配信サーバの中で、転送速度は、配信サーバ１Ａが１番速く、配信サーバ１Ｂは配信サーバ１Ａよりは遅いが配信サーバ１Ｃよりは速く、配信サーバ１Ｃは１番遅くなっている。これらの配信サーバ１Ａ，１Ｂ，１Ｃは、同一のコンテンツデータを有している。
【０１１２】
一方、端末装置２における速度制御手段としての制御部２９は、コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、配信サーバの接続を切り換えるように制御する。
【０１１３】
この転送速度制御について図４を用いて説明すると、例えば、“Ａ”の期間では、転送速度の最も速い配信サーバ１Ａから第１転送速度（配信サーバ１Ａにおいて最も速い速度（フルスピード））でデータパケットが配信されるように制御され、“Ａ”の期間と“Ｂ”の期間との境界で配信サーバ１Ａから配信サーバ１Ｂに切り換えられ、“Ｂ”の期間では、転送速度が普通の配信サーバ１Ｂから第２転送速度でデータパケットが配信されるように制御され、“Ｂ”の期間と“Ｃ”の期間との境界で配信サーバ１Ｂから配信サーバ１Ｃに切り換えられ、“Ｃ”の期間では、転送速度の最も遅い配信サーバ１Ｃから第３転送速度でデータパケットが配信されるように制御される。
【０１１４】
次に、図２２乃至図２６等を参照して、第４実施形態におけるコンテンツ配信システムの動作について説明する。
【０１１５】
図２２乃至図２６は、第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【０１１６】
図２２に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ１７１）、再生可能バッファ量５３未満である場合には（ステップＳ１７１：Ｌ）、ステップＳ１７２に示す第１転送速度での要求処理（図２３）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ１７１：Ｍ）、ステップＳ１７３に示す第２転送速度での要求処理（図２４）に移行し、設定バッファ量５４以上である場合には（ステップＳ１７１：Ｈ）、ステップＳ１７４に示す第３転送速度での要求処理（図２５）に移行する。
【０１１７】
第１転送速度での要求処理においては、図２３に示すように、制御部２９は、配信サーバ１Ａの接続処理を行う（ステップＳ１８１）。当該配信サーバ１Ａの接続処理においては、図２６（Ａ）に示すように、制御部２９は、転送速度の最も速い配信サーバ１Ａに対して接続要求を行い（ステップＳ２１５）、続いて、配信サーバ１Ａとの間の接続確立処理を行い（ステップＳ２１６）、続いて、配信サーバ１Ａに対してコンテンツデータの配信要求を行う（ステップＳ２１７）。
【０１１８】
次いで、制御部２９は、配信サーバ１Ａ以外の接続している配信サーバが有るか否かを判別し（ステップＳ２１８）、有る場合には（ステップＳ２１８：Ｙ）、配信サーバ１Ａ以外の配信サーバとの接続を切り（ステップＳ２１９）、図２３の処理に戻る。
【０１１９】
なお、図２３に示すステップＳ１８２〜ステップＳ１９２までの処理は、図６に示すステップＳ１１〜ステップＳ２１までの処理と同様であるので重複する説明を省略する。
【０１２０】
次に、第２転送速度での要求処理においては、図２４に示すように、制御部２９は、配信サーバ１Ｂの接続処理を行う（ステップＳ１９５）。当該配信サーバ１Ｂの接続処理においては、図２６（Ｂ）に示すように、制御部２９は、配信サーバを切り換えるべく、転送速度の最も速い配信サーバ１Ｂに対して接続要求を行い（ステップＳ２２１）、続いて、配信サーバ１Ｂとの間の接続確立処理を行い（ステップＳ２２２）、続いて、配信サーバ１Ｂに対してコンテンツデータの配信要求を行い（ステップＳ２２３）、配信サーバ１Ｂ以外の配信サーバとの接続を切り（ステップＳ２２４）、図２４の処理に戻る。
【０１２１】
なお、図２４に示すステップＳ１９６〜ステップＳ２０１までの処理は、図７に示すステップＳ２３〜ステップＳ２８までの処理と同様であるので重複する説明を省略する。
【０１２２】
次に、第３転送速度での要求処理においては、図２５に示すように、制御部２９は、配信サーバ１Ｃの接続処理を行う（ステップＳ２０５）。当該配信サーバ１Ｃの接続処理においては、図２６（Ｃ）に示すように、制御部２９は、配信サーバを切り換えるべく、転送速度の最も速い配信サーバ１Ｃに対して接続要求を行い（ステップＳ２２６）、続いて、配信サーバ１Ｃとの間の接続確立処理を行い（ステップＳ２２７）、続いて、配信サーバ１Ｃに対してコンテンツデータの配信要求を行い（ステップＳ２２８）、配信サーバ１Ｃ以外の配信サーバとの接続を切り（ステップＳ２２））、図２５の処理に戻る。
【０１２３】
なお、図２５に示すステップＳ２０６〜ステップＳ２１１までの処理は、図８に示すステップＳ３１〜ステップＳ３６までの処理と同様であるので重複する説明を省略する。
【０１２４】
以上説明したように上記第４実施形態によれば、第１実施形態と同様の効果を有することに加え、例えば他の配信サーバに比べ転送速度の速い配信サーバを多くの端末装置で効率良く利用することができる。
【０１２５】
なお、上記第４実施形態においては、転送速度が相互に異なる複数の配信サーバを例にとって説明したがこれに限定されるものではなく、第３実施形態と同様、例えば、コンテンツ配信システムが、相互に同一の転送速度を有する複数の配信サーバからなる配信サーバ群であって、転送速度が相互に異なる複数の配信サーバ群（例えば、図２１に示すように）を備えるようにし、端末装置２の制御部２９が、上記転送速度を変更するタイミングで、当該転送速度が異なる配信サーバ群に接続を切り換える（例えば、図２２乃至図２６の処理において、配信サーバ群１Ｄ→配信サーバ群１Ｅ→配信サーバ群１Ｆの順に切り換えられる）。このように構成すれば、配信サーバ群のうちの１つの配信サーバが機能停止（ダウン）したときでも、その影響を受けることなくコンテンツデータを再生出力することができる。
【０１２６】
（Ｖ）第５実施形態
次に、第５実施形態におけるコンテンツ配信システムについて説明する。
【０１２７】
第５実施形態では、第４実施形態と同様、図１４に示す複数（ここでは、３つ）の配信サーバ１Ａ，１Ｂ，１Ｃとの接続が順次切り換えられ、コンテンツデータが端末装置２に配信される形態であるが、第５実施形態では、第１〜第３転送速度が端末装置２の要求タイミングで決まるクライアント主導型の形態（第２実施形態と同様）について、図２６乃至図３０等を参照して説明する。なお、第５実施形態における配信サーバ１Ａ，１Ｂ，１Ｃ、及び端末装置２の構成及び機能は第１実施形態における配信サーバ１及び端末装置２と基本的には同様であるので、重複した説明は省略する。
【０１２８】
図２７乃至図３０は、第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【０１２９】
図２７に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、コンテンツデータを構成するデータブロックの番号ｉの初期値として“０”を設定（ｉ＝０に設定）する（ステップＳ２３１）。
【０１３０】
次いで、制御部２９は、第２実施形態と同様、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ２３２）、再生可能バッファ量５３未満である場合には（ステップＳ２３２：Ｌ）、ステップＳ２３３に示す第１待ち時間での要求処理（図２８）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ２３２：Ｍ）、ステップＳ２３４に示す第２待ち時間での要求処理（図２９）に移行し、設定バッファ量５４以上である場合には（ステップＳ２３２：Ｈ）、ステップＳ２３５に示す第３待ち時間での要求処理（図３０）に移行する。
【０１３１】
第１待ち時間での要求処理においては、図２８に示すように、制御部２９は、配信サーバ１Ａの接続処理（第４実施形態と同様、図２６（Ａ）の処理）を行う（ステップＳ２４１）。
【０１３２】
なお、図２８に示すステップＳ２４２〜ステップＳ２５４までの処理は、図１０に示すステップＳ５１〜ステップＳ６３までの処理と同様であるので重複する説明を省略する。
【０１３３】
次に、第２転送速度での要求処理においては、図２９に示すように、制御部２９は、配信サーバ１Ｂの接続処理（第４実施形態と同様、図２６（Ｂ）の処理）を行う（ステップＳ２５６）。
【０１３４】
なお、図２９に示すステップＳ２５７〜ステップＳ２６４までの処理は、図１１に示すステップＳ６５〜ステップＳ７２までの処理と同様であるので重複する説明を省略する。
【０１３５】
次に、第３転送速度での要求処理においては、図３０に示すように、制御部２９は、配信サーバ１Ｃの接続処理（第４実施形態と同様、図２６（Ｃ）の処理）を行う（ステップＳ２７１）。
【０１３６】
なお、図３０に示すステップＳ２７２〜ステップＳ２７９までの処理は、図１２に示すステップＳ７５〜ステップＳ８２までの処理と同様であるので重複する説明を省略する。
【０１３７】
以上説明したように上記第５実施形態によっても、第４実施形態と同様の効果を有することができる。
【０１３８】
なお、上記第１乃至第５実施形態においては、本発明を、サーバ−クライアント型のコンテンツ配信システムに対して適用したが、これに限定されるものではなく、ピアツーピア（Peer to Peer（P2P））型のコンテンツ配信システムに対して適用しても良い。ピアツーピア型のコンテンツ配信システムでは、各ピア（ノード）が上述した配信サーバと端末装置としての機能を有することになる。このようなピアツーピア型のコンテンツ配信システムでは、各ノードの配信速度（転送速度）等の能力に差があるので、本発明を適用し、上述したように転送速度を段階的に変更するように制御することは特に有効である。
【０１３９】
また、配信サーバを最上位として複数のノードが複数の階層を形成しつつ通信回線を介してツリー状に接続されたツリー構造ネットワークを有し、配信サーバにより配信されたコンテンツデータが上位階層のノードから下位階層のノードに順次転送されていくようなツリー型コンテンツ配信システムに対しても本発明を適用可能である。この場合、コンテンツデータの配信が開始される際ばかりでなく、コンテンツデータを自ノードに対して転送する直近の上位階層のノードが当該ツリー構造ネットワークから脱退（例えば、電源断等による）したことによって、当該自ノードが他の上位階層のノードに再接続してコンテンツデータの転送を受ける際にも、本発明を適用し、コンテンツデータの再生出力速度以上の範囲において、バッファ量に応じて上記転送速度を段階的に変更（減速）するようにすれば、有効である。
【０１４０】
なお、上記実施形態では、再生可能バッファ量５３未満のとき第１転送速度、再生可能バッファ量５３以上設定バッファ量５４未満のとき第２転送速度、設定バッファ量５４以上のとき第３転送速度にしていたが、再生可能バッファ量５３以下のとき第１転送速度、再生可能バッファ量５３より多くかつ設定バッファ量５４以下のとき第２転送速度、設定バッファ量５４より多いとき第３転送速度にしてもよい。また、再生可能バッファ量５３未満のとき第１転送速度、再生可能バッファ量５３以上かつ設定バッファ量５４以下のとき第２転送速度、設定バッファ量５４より多いとき第３転送速度にしてもよい。また、再生可能バッファ量５３以下のとき第１転送速度、再生可能バッファ量５３より多くかつ設定バッファ量５４未満のとき第２転送速度、設定バッファ量５４以上のとき第３転送速度にしてもよい。なお、本発明における速度制御手段は、バッファメモリにおけるバッファ量に応じて、コンテンツデータの転送速度（配信速度）を、再生出力速度より速い第１転送速度と、第１転送速度より遅く、且つ、再生出力速度より速い第２転送速度と、再生出力速度に追従する第３転送速度と、に切り換えるように制御するものであって、どのバッファ量になったときに転送速度を切り換えるのかに特に限定されるものではない。
【図面の簡単な説明】
【０１４１】
【図１】第１実施形態におけるコンテンツ配信システムの概要構成例を示す図である。
【図２】配信サーバの概要構成例を示すブロック図である。
【図３】端末装置の概要構成例を示すブロック図である。
【図４】コンテンツデータの転送速度が変更される様子を示す概念図である。
【図５】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図６】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図７】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図８】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図９】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１０】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１１】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１２】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１３】端末装置２から配信サーバ１へのデータブロックの要求タイミングの一例を示す図である。
【図１４】第３実施形態、後述する第４及び第５実施形態におけるコンテンツ配信システムの概要構成例を示す図である。
【図１５】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１６】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１７】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１８】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１９】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２０】端末装置２から配信サーバ１Ａ乃至１Ｃへのデータブロックの要求タイミングの一例を示す図である。
【図２１】転送速度が相互に異なる３つの配信サーバ群を備えるコンテンツ配信システムの概要構成例を示す図である。
【図２２】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２３】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２４】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２５】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２６】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２７】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２８】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２９】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図３０】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【符号の説明】
【０１４２】
１，１Ａ，１Ｂ，１Ｃ 配信サーバ
２ 端末装置
３ ネットワーク
１１ 記憶部
１２ エンコーダ部
１３ 通信部
１４ 制御部
１５ バス
２１ 記憶部
２２ バッファメモリ
２３ デコーダ部
２４ 映像処理部
２５ 表示部
２６ 音声処理部
２７ スピーカ
２８ 通信部
２９ 制御部
３０ 入力部
３１ バス
【技術分野】
【０００１】
本発明は、コンテンツデータ等の配信情報を例えばストリーミング方式で配信する配信元装置と、当該配信情報の配信を受ける配信先装置と、を備える配信システム等の技術分野に関する。
【背景技術】
【０００２】
この種の配信システムにおいて、配信元装置である配信サーバからストリーミング方式で配信先装置である例えばクライアントにコンテンツデータが配信される場合、当該クライアントでは、ある程度のデータがバッファメモリに貯まった（蓄積された）時点で、コンテンツデータの再生が開始され、バッファメモリには、常に一定のデータが蓄積されるようになっている（例えば、特許文献１参照）。これは、配信元装置と、配信先装置とを接続する通信回線の伝送速度の変動の影響を吸収するためである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−１６９０８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の配信システムでは、通信回線が混雑しているような場合、バッファメモリにデータを蓄積するのに時間がかかり、コンテンツデータの再生が開始されるまで時間がかかってしまい、ユーザにとって好ましくない。特に、ストリーミングのチャンネルが多くある場合、ユーザは最初にいろいろなチャンネルを視聴してから一つのチャンネルに落ち着く場合が想定されるが、このような場合に、毎回十分なデータ量までバッファメモリに蓄積（バッファリング）することは、ユーザにとっての利便性が良くない。
【０００５】
一方で、バッファメモリに蓄積するデータ量を少なくすると、再生までの時間は短くなるが、伝送速度の変動の影響を受けやすく、再生が停止してしまうという問題が生じる。
【０００６】
本発明は、以上の問題等に鑑みてなされたものであり、通信回線の伝送速度の変動の影響を受けることなく、配信された配信情報の再生までの時間を短縮することが可能な配信速度制御装置、配信システム、配信速度制御方法、及び配信速度制御用プログラムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する前記配信速度制御装置において、前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御手段と、を備え、前記速度制御手段は、前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする。
【０００８】
この発明によれば、配信先装置に配信された配信情報の当該配信先装置における再生出力速度以上の範囲において、当該配信情報の蓄積量に基づき配信速度を変更する速度制御を行うように構成したので、通信回線の伝送速度の変動の影響を受けることなく、配信された配信情報の再生までの時間を短縮することができる。また、蓄積手段の蓄積量が第１蓄積量より少ない場合、配信速度が、再生出力速度より速い第１配信速度になるように制御し、蓄積量が第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、上記配信速度が、第１配信速度より遅く、且つ、再生出力速度より速い第２配信速度になるように制御し、更に、蓄積量が第２蓄積量以上の場合、配信速度が前記再生出力速度に追従する第３配信速度になるように制御するように構成したので、第１配信速度で配信情報を配信する時間を短くすることができ、したがって、配信元装置への負担を小さくすることができる。
【０００９】
また、請求項２に記載の発明は、請求項１に記載の配信速度制御装置において、前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始させる再生制御手段を備えることを特徴とする。
【００１０】
また、請求項３に記載の発明は、請求項２に記載の配信速度制御装置において、前記速度制御手段は、前記第２配信速度を、前記配信元装置と前記配信先装置とを接続する通信回線における伝送速度の変動を相殺するように設定することを特徴とする。
【００１１】
また、請求項４に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムにおいて、請求項１から３のいずれか一項に記載の配信速度制御装置を、備えることを特徴とする。
【００１２】
また、請求項５に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置の配信速度制御方法において、前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御工程を含み、前記速度制御工程は、前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする。
【００１３】
また、請求項６に記載の発明は、請求項５に記載の配信速度制御方法において、前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始することを特徴とする。
【００１４】
また、請求項７に記載の発明は、配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置に含まれるコンピュータを、請求項１から３のいずれか一項に記載の配信速度制御装置として機能させることを特徴とする。
【００１５】
この発明によれば、第１配信速度で配信情報を配信する時間を短くすることができ、したがって、配信元装置への負担を小さくすることができる。また、他の配信元装置に比べ配信速度の速い配信元装置を多くの配信先装置で効率良く利用することができる。さらに、他の配信元装置群に比べ配信速度の速い配信元装置群を多くの配信先装置で効率良く利用することができ、また、配信元装置群のうちの１つの配信元装置が機能停止（ダウン）したときでも、その影響を受けることなく配信情報を再生出力することができる。
【発明の効果】
【００１６】
本発明によれば、配信先装置に配信された配信情報の当該配信先装置における再生出力速度以上の範囲において、当該配信情報の蓄積量に基づき配信速度を変更する速度制御を行うように構成したので、通信回線の伝送速度の変動の影響を受けることなく、配信された配信情報の再生までの時間を短縮することができる。
【発明を実施するための形態】
【００１７】
以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する各実施形態は、コンテンツ配信システムに対して本発明を適用した場合の実施形態である。
【００１８】
（Ｉ）第１実施形態
先ず、本発明の第１実施形態におけるコンテンツ配信システムについて説明する。
【００１９】
始めに、図１乃至図３を参照して、第１実施形態におけるコンテンツ配信システムの構成及び機能について説明する。
【００２０】
図１は、第１実施形態におけるコンテンツ配信システムの概要構成例を示す図であり、図２は、配信サーバの概要構成例を示すブロック図であり、図３は、端末装置の概要構成例を示すブロック図である。
【００２１】
図１に示すように、配信システムとしてのコンテンツ配信システムは、配信されるべき配信情報としてのコンテンツ（例えば映画や楽曲等のコンテンツ）データを配信する配信元装置としての配信サーバ１と、当該コンテンツデータの配信を受ける配信先装置としての端末装置（クライアント）２と、を備えて構成されており、配信サーバ１と端末装置２には、夫々ＩＰ（Internet Protocol）アドレスが割り当てられており、これらはインターネット等のネットワーク３を介して相互に接続されている。
【００２２】
配信サーバ１は、図２に示すように、各種データ及びプログラム，更にはコンテンツデータ等を記憶（格納）するＨＤＤ（Hard Disc Drive）等から構成された記憶部１１と、当該コンテンツデータに含まれる映像情報（ビデオデータ）及び音声情報（オーディオデータ）等をエンコード（データ圧縮や暗号化等）するエンコーダ部１２と、ネットワーク３を通じて端末装置２との間の通信制御を行うための通信部１３と、ＣＰＵ（Central Processing Unit） ，作業用ＲＡＭ（Random-Access Memory），各種データ及びプログラムを記憶するＲＯＭ（Read-Only Memory）等から構成された制御部１４と、を備えて構成され、これらの各構成要素はバス１５を介して相互に接続されている。
【００２３】
制御部１４は、ＣＰＵが記憶部１１等に記憶されたプログラムを読み出して実行することにより、配信サーバ１全体を統括制御し、端末装置２からの要求に応じて、コンテンツデータの配信制御を行う。具体的には、制御部１４は、エンコーダ部１２によりエンコードされたコンテンツデータを、所定のデータ量に分割して連続する複数のデータパケットを生成し、これをデータストリームとして、端末装置２から要求された配信速度（以下、「転送速度」という）で通信部１３等を通じて端末装置２に配信（ストリーミング配信）するようになっている。なお、各データパケットには、そのコンテンツの先頭から連続するパケット番号が付与されている。
【００２４】
端末装置２は、図３に示すように、各種データ及びプログラム等を記憶するＨＤＤ等から構成された記憶部２１と、配信サーバ１からのコンテンツデータを一時的に蓄積（記憶）する蓄積手段としてのバッファメモリ２２と、バッファメモリ２２からのコンテンツデータに含まれる映像情報及び音声情報等をデコード（データ伸張や復号化等）して再生するデコーダ部２３と、当該再生された映像情報等に対して所定の描画処理を施し映像信号として出力する映像処理部２４と、当該映像処理部２４から出力された映像信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部２５と、上記再生された音声情報をアナログ音声信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部２６と、当該音声処理部２６から出力された音声信号を音波として出力するスピーカ２７と、ネットワーク３を通じて配信サーバ１との間の通信制御を行うための通信部２８と、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部２９と、ユーザ（視聴者）からの指示（例えば、再生出力指示、設定指示等）を入力し制御部２９に対してその指示信号を与える入力部（例えば、マウス、キーボード、操作パネル、或いはリモコン等）３０を備えて構成され、記憶部２１、バッファメモリ２２、デコーダ部２３、通信部２８、制御部２９、及び入力部３０はバス３１を介して相互に接続されている。なお、端末装置２としては、例えば、ＳＴＢ（Set Top Box）やパーソナルコンピュータが適用可能である。
【００２５】
バッファメモリ２２は、制御部２９の制御下、例えばＦＩＦＯ（First In First Out）形式のリングバッファメモリから構成されており、受信ポインタにより示される記憶領域に通信部２８を通じて受信されたコンテンツデータを一時的に蓄積し、再生ポインタにより示される記憶領域に格納されているコンテンツデータをバス３１を介してデコーダ部２３に出力するようになっている。
【００２６】
制御部２９は、ＣＰＵが記憶部２１等に記憶されたプログラム（本発明の配信速度制御用プログラムを含む）を読み出して実行することにより、端末装置２全体を統括制御し、かつ、再生制御手段及び速度制御手段等として機能する。なお、配信速度制御用プログラムは、例えば、ネットワーク３上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしてもよい。
【００２７】
再生制御手段としての制御部２９は、バッファメモリ２２におけるコンテンツデータの再生出力（つまり、デコーダ部２３、映像処理部２４、及び音声処理部２６等による再生出力）を制御するようになっており、バッファメモリ２２におけるコンテンツデータの蓄積量（以下、「バッファ量」という）が、当該コンテンツデータの再生出力を開始することが可能となる最小のバッファ量である再生可能バッファ量（本発明における第１蓄積量に対応）５３（例えば、例えば音声情報の場合、例えば１オーディオフレーム分のデータ量、映像情報の場合、例えば１フレーム（ピクチャ）分のデータ量、言い変えれば、デコーダ部２３が必要とする最小のデータ量）となったとき、当該コンテンツデータの再生出力を開始させる。
【００２８】
また、速度制御手段としての制御部２９は、配信サーバ１と協働（連携）して、バッファメモリ２２におけるコンテンツデータのバッファ量に基づき配信サーバ１から端末装置２へのコンテンツデータの転送速度を制御するようになっており、当該コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、上記コンテンツデータの再生出力速度以上の範囲において、上記転送速度を変更する制御を行う。
【００２９】
ここで、図４を参照して、制御部２９におけるコンテンツデータの転送速度制御について詳しく説明する。
【００３０】
図４は、コンテンツデータの転送速度が変更（この例では、２段階の変更）される様子を示す概念図である。なお、図４の例において、縦軸がデータ量（ｋbyte）を、横軸が時間（ｔ）を夫々示しており、また、線５１の傾きが転送速度（第１〜第３転送速度）を、線５２の傾きが再生出力速度を示している。また、任意の時間ｔにおける線５１と線５２との間のデータ量がバッファ量（つまり、バッファメモリ２２に蓄積されているコンテンツデータの蓄積量）を示している。
【００３１】
図４の例では、制御部２９は、コンテンツデータのバッファ量が再生可能バッファ量５３より少ない場合、転送速度が再生出力速度より速い第１転送速度（最も速い速度（フルスピード））になるように（図４の“Ａ”の期間）制御し、バッファ量が再生可能バッファ量５３以上であり、かつ、当該再生可能バッファ量より多いで予め設定された設定バッファ量（本発明における第２蓄積量に対応）５４より少ない場合、転送速度が上記第１転送速度より遅く、かつ、再生出力速度より速い第２転送速度になるように（図４の“Ｂ”の期間）制御し、更に、バッファ量が設定バッファ量５４以上の場合、転送速度が再生出力速度に追従する第３転送速度（言い換えれば、デコーダ部２３のデータ消費速度）になるように（図４の“Ｃ”の期間）制御している。つまり、制御部２９は、バッファメモリ２２におけるバッファ量に応じて、配信速度を、コンテンツデータの再生出力速度より速い第１配信速度と、第１配信速度より遅く、且つ、再生出力速度より速い第２配信速度と、再生出力速度に追従する第３配信速度と、に切り換えるように制御するようになっている。
【００３２】
ここで、転送速度は、配信サーバ１側の処理能力、端末装置２側の処理能力、及びネットワーク３経路の帯域幅（バンド幅）の３つの要素で決まるものであるため、第１転送速度（最も速い速度（フルスピード））とは、これらの３つの要素が考慮された上で可能な限り速い（つまり、これらの３つの要素のうちでボトルネックとなる箇所の速度で頭打ちとならない範囲で制御可能）ということを意味する。
【００３３】
また、設定バッファ量５４は、例えばネットワーク３のジッタ（つまり、配信サーバ１と端末装置２とを接続する通信回線における転送速度（伝送速度）の変動、言い換えれば、データパケットの到着時間のずれ（変位））が考慮されて設定されるものであり、コンテンツデータの再生出力が当該ジッタに影響されない（つまり、当該変動により再生出力が途切れない）バッファ量である。図４の“Ｃ”の期間では、転送速度が第３転送速度となって再生出力速度に追従することにより、設定バッファ量５４が維持されている。また、バッファメモリ２２におけるバッファ量が設定バッファ量５４に到達するまでの図４の“Ｂ”の期間では、転送速度は再生出力速度よりも速い第２配信速度になっているが、この第２転送速度は、上記ネットワークのジッタ（転送速度の変動）を相殺するように設定されるものであり、再生出力速度（言い換えれば、データ消費速度）＋調整速度“ａ”（この値は、ネットワークのジッタに応じて決定される）の転送速度となる。
【００３４】
次に、図５乃至図８等を参照して、第１実施形態におけるコンテンツ配信システムの動作について説明する。
【００３５】
図５乃至図８は、第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【００３６】
図５に示す処理は、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、配信サーバ１に対して接続要求（つまり、配信サーバ１に対して接続要求を示す情報を送信）を行う（ステップＳ１）。当該接続要求に対して、配信サーバ１は、所定の認証処理を実行し、良好である場合には、接続了解を示す情報を端末装置２に対して返信する。
【００３７】
接続が了解された場合、制御部２９は、配信サーバ１との間の接続確立処理を行い（ステップＳ２）、次いで、コンテンツデータの配信要求を行う（ステップＳ３）。当該配信要求に対して、配信サーバ１では、要求されたコンテンツデータの配信準備を行うことになる。
【００３８】
次いで、制御部２９は、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ４）、再生可能バッファ量５３未満である場合には（ステップＳ４：Ｌ）、ステップＳ５に示す第１転送速度での要求処理（図６）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ４：Ｍ）、ステップＳ６に示す第２転送速度での要求処理（図７）に移行し、設定バッファ量５４以上である場合には（ステップＳ４：Ｈ）、ステップＳ７に示す第３転送速度での要求処理（図８）に移行する。なお、ユーザが初めてコンテンツの要求指示を行った場合等、未だバッファメモリ２２にデータが蓄積されていない初期の段階では、第１転送速度での要求処理に移行されることになる。
【００３９】
第１転送速度での要求処理においては、図６に示すように、制御部２９は、先ず、配信サーバ１に対して第１転送速度（例えば、４００ｋｂｐｓ（bit per second）程度）での要求（つまり、配信サーバ１に対して第１転送速度でコンテンツデータに係るデータパケットを配信する要求を示す情報を送信）を行う（ステップＳ１１）。当該要求に対して、配信サーバ１は、転送速度を第１転送速度に設定し、当該第１転送速度でデータパケットを端末装置２に配信する（なお、配信サーバ１は、端末装置２から次の要求が来るまで当該第１転送速度で複数のデータパケットを順次送り続ける）ことになり、当該データパケットは、端末装置２の通信部２８を通じて受信され、バッファメモリ２２に蓄積されることになる。
【００４０】
次いで、制御部２９は、配信サーバ１から最後のデータパケットを受信したか否かを判別し（ステップＳ１２）、受信した場合には（ステップＳ１２：Ｙ）、当該配信サーバ１との接続を切り（ステップＳ１９）、バッファメモリ２２に未再生のコンテンツデータが蓄積されているか否かを判別し（ステップＳ２０）、蓄積されている場合（ステップＳ２０：Ｙ）には、バッファメモリ２２における残りのコンテンツデータを再生出力させ（ステップＳ２１）、当該処理を終了する。
【００４１】
一方、最後のデータパケットを受信していない場合には（ステップＳ１２：Ｎ）、制御部２９は、受信されたデータパケットに基づいてネットワーク８のジッタを計測する（ステップＳ１３）。
【００４２】
次いで、制御部２９は、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になったか（言い換えれば、到達したか）否かを判別し（ステップＳ１４）、再生可能バッファ量５３以上になっていない場合には（ステップＳ１４：Ｎ）、ステップＳ１２に戻り、上記と同様の処理を行う。
【００４３】
こうして、ネットワーク８のジッタは、例えば、再生可能バッファ量５３に到達するまでの間の所定時間における各データパケットの到着時間差の平均値、或いは標準偏差によって求められる。
【００４４】
そして、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になった場合には（ステップＳ１４：Ｙ）、制御部２９は、デコーダ部２３等に対して再生開始指令を与える（ステップＳ１５）。これにより、バッファメモリ２２に蓄積されたコンテンツデータの再生出力が開始される。
【００４５】
次いで、制御部２９は、上記ステップＳ１３における計測によって求められたジッタが所定値（例えば、通常許容できるジッタの最大値）よりも大きいか否かを判別し（ステップＳ１６）、当該所定値よりも大きくない場合には（ステップＳ１６：Ｎ）、設定バッファ量５４を規定バッファ量に設定し、かつ、調整速度“ａ”を規定速度に設定し（ステップＳ１８）、図５に示すステップＳ４の処理に戻る。一方、ジッタが所定値よりも大きい場合には（ステップＳ１６：Ｙ）、制御部２９は、設定バッファ量５４を規定バッファ量より大きいバッファ量（例えば、ジッタの大きさに比例した値）に設定し、かつ、調整速度“ａ”を規定速度より大きい速度（例えば、ジッタの大きさに比例した値、つまり、ジッタが大きければバッファ量を増やす）に設定し（ステップＳ１７）、図５に示すステップＳ４の処理に戻る。
【００４６】
次に、第２転送速度での要求処理においては、図７に示すように、制御部２９は、上記配信サーバ１に対して第２転送速度（再生出力速度＋上記設定された調整速度“ａ”。例えば、ジッタが所定値よりも大きくない場合、１５０ｋｂｐｓ程度、ジッタが所定値よりも大きい場合、２００ｋｂｐｓ程度）での要求（転送速度を変更するタイミング）を行う（ステップＳ２３）。当該要求に対して、配信サーバ１は、転送速度を第２転送速度に変更設定し、当該第２転送速度でコンテンツデータに係るデータパケットを端末装置２に配信することになる。
【００４７】
次いで、制御部２９は、配信サーバ１から最後のデータパケットを受信したか否かを判別し（ステップＳ２４）、受信した場合には（ステップＳ２４：Ｙ）、当該配信サーバ１との接続を切り（ステップＳ２６）、バッファメモリ２２に未再生のコンテンツデータが蓄積されている場合（ステップＳ２７：Ｙ）には、バッファメモリ２２における残りのコンテンツデータを再生出力させ（ステップＳ２８）、当該処理を終了する。
【００４８】
一方、最後のデータパケットを受信していない場合には（ステップＳ２４：Ｎ）、制御部２９は、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３未満又は設定バッファ量５４以上（つまり、再生可能バッファ量５３以上設定バッファ量５４以下の範囲外になった）になったか否かを判別し（ステップＳ２５）、再生可能バッファ量５３未満又は設定バッファ量５４以上になっていない場合には（ステップＳ２５：Ｎ）、ステップＳ２４に戻り、上記と同様の処理を行う。
【００４９】
一方、再生可能バッファ量５３未満又は設定バッファ量５４以上になった場合には（ステップＳ２５：Ｙ）、図５に示すステップＳ４の処理に戻る。
【００５０】
なお、データパケットが正常に配信され、バッファメモリ２２に蓄積されていけば、バッファ量が設定バッファ量５４に到達することになるが、例えば、配信サーバ１側、或いは、ネットワーク３経路上における何らかの原因によりデータパケットの配信が滞ることが生じれば、再生可能バッファ量５３未満になる場合もありうる。このような場合にも、当該処理は適切に対応することができる。
【００５１】
次に、第３転送速度での要求処理においては、図８に示すように、制御部２９は、上記配信サーバ１に対して第３転送速度（再生出力速度に追従する速度。例えば、１００ｋｂｐｓ程度）での要求（転送速度を変更するタイミング）を行う（ステップＳ３１）。当該要求に対して、配信サーバ１は、転送速度を第３転送速度に変更設定し、当該第３転送速度でコンテンツデータに係るデータパケットを端末装置２に配信することになる。
【００５２】
次いで、制御部２９は、配信サーバ１から最後のデータパケットを受信したか否かを判別し（ステップＳ３２）、受信した場合には（ステップＳ３２：Ｙ）、当該配信サーバ１との接続を切り（ステップＳ３４）、バッファメモリ２２に未再生のコンテンツデータが蓄積されている場合（ステップＳ３５：Ｙ）には、バッファメモリ２２における残りのコンテンツデータを再生出力させ（ステップＳ３６）、当該処理を終了する。
【００５３】
一方、最後のデータパケットを受信していない場合には（ステップＳ３２：Ｎ）、制御部２９は、バッファメモリ２２におけるバッファ量が設定バッファ量５４未満になったか否かを判別し（ステップＳ３３）、設定バッファ量５４未満になっていない場合には（ステップＳ３３：Ｎ）、ステップＳ３２に戻り、上記と同様の処理を行う。
【００５４】
一方、設定バッファ量５４未満になった場合には（ステップＳ３３：Ｙ）、図５に示すステップＳ４の処理に戻る。
【００５５】
以上説明したように上記第１実施形態によれば、バッファメモリ２２に蓄積されるバッファ量が再生可能バッファ量になるまで第１転送速度（フルスピード）でコンテンツデータを配信し（図４の“Ａ”の期間）、その後、上記バッファ量がネットワーク３のジッタが考慮された設定バッファ量になるまで第２転送速度（再生出力速度＋調整速度“ａ”）でコンテンツデータを配信し（図４の“Ｂ”の期間）、その後、第３転送速度（再生出力速度に追従する速度）でコンテンツデータを配信する（図４の“Ｃ”の期間）というように、上記コンテンツデータの再生出力速度以上の範囲において、バッファ量に応じて上記転送速度を段階的に変更するようにしたので、ネットワーク３のジッタの影響を受けることなく、配信されたコンテンツデータの再生までの時間を短縮することができる。また、図４の“Ａ”の期間において、配信サーバ１がフルスピードでデータパケットを転送（配信）する時間を短くできるので、配信サーバ１への負担を小さくすることができる。
【００５６】
特に、ストリーミングのチャンネルが多くある場合、ユーザは最初にいろいろなチャンネルを視聴してから一つのチャンネルに落ち着く場合が想定されるが、このような場合に、毎回十分なバッファ量までバッファリングするという無駄を省き、迅速に再生開始できるので、ユーザにとっての利便性を向上させることができる。
【００５７】
なお、上記実施形態においては、コンテンツデータの再生出力速度以上の範囲において、上記転送速度を２段階に変更（減速）する例を示したが、これに限定されるものではなく２段階より多く段階的に変更するように構成しても良い。例えば、図４の“Ｂ”の期間において、第２配信速度を複数段階で変化させたり、２次曲線的に変化させるように構成しても良い。
【００５８】
（ＩＩ）第２実施形態
次に、第２実施形態におけるコンテンツ配信システムについて説明する。
【００５９】
上記第１実施形態においては、第１〜第３転送速度は、端末装置２からの要求に応じて配信サーバ１によって設定されるサーバ主導型の形態について説明したが、第２実施形態では、第１〜第３転送速度が端末装置２の要求タイミングで決まるクライアント主導型の形態について、図９乃至図１３等を参照して説明する。なお、第２実施形態における配信サーバ１及び端末装置２の構成及び機能は第１実施形態と基本的には同様であるので、重複した説明は省略する。
【００６０】
図９乃至図１２は、第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートであり、図１３は、端末装置２から配信サーバ１へのデータブロックの要求タイミングの一例を示す図である。
【００６１】
図９に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始される。なお、図９に示すステップＳ４１〜ステップＳ４３までの処理は、図５に示すステップＳ１〜ステップＳ３までの処理と同様であるので重複する説明を省略する。
【００６２】
次に、図９のステップＳ４４では、制御部２９は、コンテンツデータを構成するデータブロックの番号ｉの初期値として“０”を設定（ｉ＝０に設定）する。
【００６３】
ここで、データブロックとは、配信サーバ１側でコンテンツデータがブロック単位（任意のデータ量（例えば数ｋｂｙｔｅ〜数Ｍｂｙｔｅ））に分割されたものであり、夫々のデータブロックに対して例えば連続する固有の番号が付与される。端末装置２は、このデータブロックの番号を指定して配信サーバ１に配信要求することになる。なお、このデータブロックは、更に、複数のデータパケットに分割されて配信される。
【００６４】
次いで、制御部２９は、第１実施形態と同様、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ４５）、再生可能バッファ量５３未満である場合には（ステップＳ４５：Ｌ）、ステップＳ４６に示す第１待ち時間での要求処理（図１０）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ４５：Ｍ）、ステップＳ４７に示す第２待ち時間での要求処理（図１１）に移行し、設定バッファ量５４以上である場合には（ステップＳ４５：Ｈ）、ステップＳ４８に示す第３待ち時間での要求処理（図１２）に移行する。
【００６５】
第１待ち時間での要求処理においては、図１０に示すように、制御部２９は、先ず、配信サーバ１に対してｉ番目のデータブロックを要求（つまり、配信サーバ１に対してｉ番目のデータブロックを配信する要求を示す情報を送信）する（ステップＳ５１）。当該要求に対して、配信サーバ１は、所定の転送速度でデータブロックに係るデータパケットを端末装置２に配信することになり、当該データパケットは、端末装置２の通信部２８を通じて受信され、バッファメモリ２２に蓄積されることになる。
【００６６】
次いで、制御部２９は、データブロックの番号ｉを“１”インクリメントし（ステップＳ５２）、続いて、配信サーバ１から最後のデータパケットを受信したか否かを判別する（ステップＳ５３）。最後のデータパケットを受信していない場合には（ステップＳ５３：Ｎ）、制御部２９は、第１実施形態と同様、受信されたデータパケットに基づいてネットワーク８のジッタを計測し（ステップＳ５４）、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になったか否かを判別する（ステップＳ５５）。
【００６７】
そして、再生可能バッファ量５３以上になっていない場合には（ステップＳ５５：Ｎ）、制御部２９は、第１待ち時間が経過した後（ステップＳ５６）、ステップＳ５１に戻り、次のデータブロック（ステップＳ５２でインクリメントされたｉ番目のデータブロック）を配信サーバ１に対して要求する。
【００６８】
ここで、「待ち時間」は、前回のデータブロックを要求したタイミングからの経過時間を規定するものであり、上記ステップＳ５６では、制御部２９が時計を監視して次の要求タイミングの時刻になるのを待つことになる。これにより、端末装置２のデータブロックの要求タイミングが決まり、複数の要求タイミングの時間間隔によって転送速度が定まることになる。
【００６９】
そして、第２実施形態においては、コンテンツデータのバッファ量が再生可能バッファ量５３より少ない場合、この待ち時間を「第１待ち時間」（例えば、フルスピードで端末装置２がデータブロックを配信サーバ１から引き出す場合、“０”（ゼロ）時間となる。つまり、端末装置２が要求を出せる最大の速度（ＣＰＵの動作速度に依存））として上記第１転送速度になるように制御し、バッファ量が再生可能バッファ量５３以上であり、かつ、当該再生可能バッファ量より多い予め設定された設定バッファ量５４未満の場合、当該待ち時間を「第２待ち時間」（第１待ち時間より長い）として上記第２転送速度になるように制御し、バッファ量が設定バッファ量５４以上の場合、当該待ち時間を「第３待ち時間」（第２待ち時間より長い）として上記第３転送速度になるように制御するようになっている。
【００７０】
例えば、図１３の例には、配信サーバへの要求タイミングを示しているが、“Ａ”の期間では、第１待ち時間により定まる時間間隔“Ｔ１”で配信サーバへのデータブロックの要求がなされており、“Ｂ”の期間では、第２待ち時間により定まる時間間隔“Ｔ２”で配信サーバへのデータブロックの要求がなされており、“Ｃ”の期間では、第３待ち時間により定まる時間間隔“Ｔ３”で配信サーバへのデータブロックの要求がなされている。このように、要求タイミングの時間間隔を変えることによってバッファメモリ２２に蓄積される速さを調整することができる。
【００７１】
なお、図１０に示すステップＳ５７〜ステップＳ６３までの処理は、図６に示すステップＳ１５〜ステップＳ２１までの処理と同様であるので重複する説明を省略する。
【００７２】
次に、第２待ち時間での要求処理においては、図１１に示すように、制御部２９は、先ず、配信サーバ１に対してｉ番目のデータブロックを要求し（ステップＳ６５）、続いて、データブロックの番号ｉを“１”インクリメントし（ステップＳ６６）、続いて、配信サーバ１から最後のデータパケットを受信したか否かを判別する（ステップＳ６７）。最後のデータパケットを受信していない場合には（ステップＳ６７：Ｎ）、制御部２９は、第１実施形態と同様、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３未満又は設定バッファ量５４以上になったか否かを判別し（ステップＳ６８）、再生可能バッファ量５３未満又は設定バッファ量５４以上になっていない場合には（ステップＳ６８：Ｎ）、上述した第２待ち時間が経過した後（ステップＳ６９）、ステップＳ６５に戻り、次のデータブロックを配信サーバ１に対して要求する。
【００７３】
なお、図１１に示すステップＳ７０〜ステップＳ７２までの処理は、図７に示すステップＳ２６〜ステップＳ２８までの処理と同様であるので重複する説明を省略する。
【００７４】
次に、第３待ち時間での要求処理においては、図１２に示すように、制御部２９は、先ず、配信サーバ１に対してｉ番目のデータブロックを要求し（ステップＳ７５）、続いて、データブロックの番号ｉを“１”インクリメントし（ステップＳ７６）、続いて、配信サーバ１から最後のデータパケットを受信したか否かを判別する（ステップＳ７７）。最後のデータパケットを受信していない場合には（ステップＳ７７：Ｎ）、制御部２９は、第１実施形態と同様、バッファメモリ２２におけるバッファ量が設定バッファ量５４未満になったか否かを判別し（ステップＳ７８）、設定バッファ量５４未満になっていない場合には（ステップＳ７８：Ｎ）、上述した第３待ち時間が経過した後（ステップＳ７９）、ステップＳ７５に戻り、次のデータブロックを配信サーバ１に対して要求する。
【００７５】
なお、図１２に示すステップＳ８０〜ステップＳ８２までの処理は、図８に示すステップＳ３４〜ステップＳ３６までの処理と同様であるので重複する説明を省略する。
【００７６】
以上説明したように上記第２実施形態によっても、第１実施形態と同様の効果を有することができることに加え、例えば、配信サーバと端末装置の性能が大きく違う場合に、端末装置からの要求が配信サーバに到達してからデータを転送してもらうので、端末装置側でのデータの取りこぼしがなくなるという効果がある（つまり、端末装置の性能に合わせたデータ転送が可能）。
【００７７】
なお、上記第２実施形態においては、データブロックのサイズ（データ量）を固定とし、要求タイミングの時間間隔を可変としたが、別の例として、要求タイミングの時間間隔を固定とし、データブロックのサイズ（データ量）を可変として制御するように構成しても良い。
【００７８】
（ＩＩＩ）第３実施形態
次に、第３実施形態におけるコンテンツ配信システムについて説明する。
【００７９】
図１４は、第３実施形態、後述する第４及び第５実施形態におけるコンテンツ配信システムの概要構成例を示す図である。
【００８０】
上記第１及び第２実施形態においては、１つの配信サーバ１からコンテンツデータが端末装置２に配信される形態について説明したが、第３実施形態では、図１４に示すように、複数（ここでは、３つ）の配信サーバ１Ａ，１Ｂ，１Ｃの夫々から一のコンテンツデータが分割されたデータブロックが端末装置２に配信（分散ストリーミング配信）される形態について説明する。なお、第３実施形態における配信サーバ１Ａ，１Ｂ，１Ｃ、及び端末装置２の構成及び機能は第１実施形態における配信サーバ１及び端末装置２と基本的には同様であるので、重複した説明は省略する。
【００８１】
配信サーバ１Ａ，１Ｂ，１Ｃは、夫々、コンテンツデータ（データパケット）の転送速度が相互に異なっており、この３つの配信サーバの中で、転送速度は、配信サーバ１Ａが１番速く、配信サーバ１Ｂは配信サーバ１Ａよりは遅いが配信サーバ１Ｃよりは速く、配信サーバ１Ｃは１番遅くなっている。また、これらの配信サーバ１Ａ，１Ｂ，１Ｃは、同一のコンテンツデータを有している。
【００８２】
一方、端末装置２における速度制御手段としての制御部２９は、コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、接続する配信サーバの数を変えるように当該各配信サーバ１Ａ，１Ｂ，１Ｃとの接続を制御する。つまり、制御すべき転送速度となるように、配信サーバ１Ａ〜１Ｃの接続数が変えられる。
【００８３】
この転送速度制御について図４を用いて説明すると、例えば、“Ａ”の期間では、３つの配信サーバ１Ａ，１Ｂ及び１Ｃから夫々最も速い転送速度（例えば、端末装置２から見た全体の転送速度が第１転送速度になる）でデータパケットが配信されるように制御され、“Ｂ”の期間では、コンテンツデータの転送速度が端末装置２から見て第２転送速度になるように２つの配信サーバ１Ｂ及び１Ｃから夫々、データパケットが配信されるように制御され、“Ｃ”の期間では、コンテンツデータの転送速度が第３転送速度になるように１つの配信サーバ１Ｃからデータパケットが配信されるように制御される。
【００８４】
次に、図１５乃至図２０等を参照して、第３実施形態におけるコンテンツ配信システムの動作について説明する。
【００８５】
図１５乃至図１９は、第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートであり、図２０は、端末装置２から配信サーバ１Ａ乃至１Ｃへのデータブロックの要求タイミングの一例を示す図である。
【００８６】
図１５に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、複数の配信サーバ、例えば３つの配信サーバ１Ａ，１Ｂ及び１Ｃの夫々に対して接続要求を行う（ステップＳ１０１）。当該接続要求に対して、配信サーバ１Ａ，１Ｂ及び１Ｃは、夫々、所定の認証処理を実行し、良好である場合には、接続了解を示す情報を端末装置２に対して返信する。
【００８７】
接続が了解された場合、制御部２９は、配信サーバ１Ａ，１Ｂ及び１Ｃとの間の接続確立処理を行い（ステップＳ１０２）、次いで、夫々の配信サーバに対してコンテンツデータの配信要求を行う（ステップＳ１０３）。当該配信要求に対して、配信サーバ１Ａ，１Ｂ及び１Ｃでは、要求されたコンテンツデータの配信準備を行うことになる。
【００８８】
次いで、制御部２９は、コンテンツデータを構成するデータブロックの番号ｉの初期値として“０”を設定（ｉ＝０に設定）する（ステップＳ１０４）。
【００８９】
次いで、制御部２９は、第２実施形態と同様、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ１０５）、再生可能バッファ量５３未満である場合には（ステップＳ１０５：Ｌ）、ステップＳ１０６に示す第１待ち時間での要求処理（図１６）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ１０５：Ｍ）、ステップＳ１０７に示す第２待ち時間での要求処理（図１７）に移行し、設定バッファ量５４以上である場合には（ステップＳ１０５：Ｈ）、ステップＳ１０８に示す第３待ち時間での要求処理（図１８）に移行する。
【００９０】
第１待ち時間での要求処理においては、図１６に示すように、制御部２９は、配信サーバ１Ａの接続処理を行う（ステップＳ１１１）。当該配信サーバ１Ａの接続処理においては、図１９（Ａ）に示すように、制御部２９は、配信サーバ１Ａは既に接続済であるか否か判別し（ステップＳ１５５）、接続済である（例えば、図１５に示す処理の開始直後は接続済となっている）場合には（ステップＳ１５５：Ｙ）、図１６の処理に戻る。一方、接続済でない場合（ステップＳ１５５：Ｎ）には、制御部２９は、複数の配信サーバ１Ａに対して接続要求を行い（ステップＳ１５６）、続いて、配信サーバ１Ａとの間の接続確立処理を行い（ステップＳ１５７）、続いて、配信サーバ１Ａに対してコンテンツデータの配信要求を行い（ステップＳ１５８）、図１６の処理に戻る。
【００９１】
次いで、図１６に示すステップＳ１１２では、制御部２９は、配信サーバ１Ｂの接続処理（図１９（Ｂ））を行う。当該配信サーバ１Ｂの接続処理は、配信サーバ１Ａの接続処理と同様であるので、説明を省略する。
【００９２】
次いで、制御部２９は、アイドル中の配信サーバ（つまり、配信サーバ１Ａ乃至１Ｃのうち、データブロックの配信準備が完了している配信サーバ）に対してｉ番目のデータブロックを要求し（ステップＳ１１３）、続いて、データブロックの番号ｉを“１”インクリメントする（ステップＳ１１４）。アイドル中の配信サーバが複数ある場合には、アイドル時間が長い配信サーバへ要求を出す方法や、転送速度の速い配信サーバへｉ番目のデータブロックを要求を出す方法が考えられる。また、アイドル中の配信サーバが存在しない場合は、接続している配信サーバのいずれかがアイドル状態になるまで待つこととなる。
【００９３】
次いで、制御部２９は、何れかの配信サーバから最後のデータパケットを受信したか否かを判別し（ステップＳ１１５）、最後のデータパケットを受信していない場合には（ステップＳ１１５：Ｎ）、第２実施形態と同様、受信されたデータパケットに基づいてネットワーク８のジッタを計測する（ステップＳ１１６）。
【００９４】
次いで、制御部２９は、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３以上になったか否かを判別し（ステップＳ１１７）、再生可能バッファ量５３以上になっていない場合には（ステップＳ１１７：Ｎ）、第２実施形態と同様、第１待ち時間が経過した後（ステップＳ１１８）、ステップＳ１１３に戻り、次のデータブロックをアイドル中の配信サーバに対して要求する。
【００９５】
こうして、再生可能バッファ量５３以上になるまで、データブロックの要求処理は繰り返されるが、このとき、制御部２９は、例えば、図２０に示すように、処理能力が高い順（つまり、配信サーバ１Ｃ、配信サーバ１Ｂ、配信サーバ１Ａの順に高くなる）にデータブロックの要求間隔を短くするように制御する（なお、図２０中の逆三角印内の番号は、データブロックの要求の順序を示している）。
【００９６】
図２０の例では、第１待ち時間で転送する時間において、第１待ち時間をゼロとしており、ステップＳ１１３からループして戻ってくるまでの時間分だけ遅延がある。つまり、データブロックの配信（転送）が終わった配信サーバへすぐに次のデータブロックの要求が行われる。再生可能バッファ量以上になると第２待ち時間の処理へ移り、第２待ち時間の間隔で配信サーバへ要求がなされる。なお、第３待ち時間の場合も同様である。
【００９７】
なお、図１６に示すステップＳ１１９〜ステップＳ１２２までの処理は、図６に示すステップＳ１５〜ステップＳ２１までの処理と同様であるので重複する説明を省略する。
【００９８】
次いで、ステップＳ１２１の処理後、制御部２９は、配信サーバ１Ａとの接続を切り（ステップＳ１２３）、図１５の処理に戻る。
【００９９】
また、制御部２９が最後のデータパケットを受信した場合には（ステップＳ１１５：Ｙ）、制御部２９は、接続している全ての配信サーバとの接続を切り（ステップＳ１２４）、ステップＳ１２５等を経て、当該処理を終了する。
【０１００】
第２待ち時間での要求処理においては、図１７に示すように、制御部２９は、ステップＳ１１２と同様、配信サーバ１Ｂの接続処理を行う（ステップＳ１３１）。
【０１０１】
次いで、制御部２９は、アイドル中の配信サーバ（つまり、配信サーバ１Ａ及び１Ｂのうち、データブロックの配信準備が完了している配信サーバ）に対してｉ番目のデータブロックを要求し（ステップＳ１３２）、続いて、データブロックの番号ｉを“１”インクリメントする（ステップＳ１３３）。
【０１０２】
次いで、制御部２９は、最後のデータパケットを受信したか否かを判別し（ステップＳ１３４）、最後のデータパケットを受信していない場合には（ステップＳ１３４：Ｎ）、バッファメモリ２２におけるバッファ量が再生可能バッファ量５３未満又は設定バッファ量５４以上になったか否かを判別し（ステップＳ１３５）、再生可能バッファ量５３未満又は設定バッファ量５４以上になっていない場合には（ステップＳ１３５：Ｎ）、第２実施形態と同様、上述した第２待ち時間が経過した後（ステップＳ１３６）、ステップＳ１３２に戻り、次のデータブロックをアイドル中の配信サーバに対して要求する。
【０１０３】
また、制御部２９が最後のデータパケットを受信した場合には（ステップＳ１３４：Ｙ）、制御部２９は、接続している全ての配信サーバとの接続を切り（ステップＳ１３８）、ステップＳ１２５等を経て、当該処理を終了する。
【０１０４】
なお、図１８に示す第３待ち時間での要求処理は、図１２に示す第３待ち時間での要求処理と同様であるので、重複した説明を省略する。
【０１０５】
以上説明したように上記第３実施形態によれば、第２実施形態と同様の効果を有することに加え、例えば他の配信サーバに比べ転送速度の速い配信サーバを多くの端末装置で効率良く利用することができる。また、第３実施形態のように、配信サーバの接続数を次第に減らしていく方法は、同じコンテンツデータを持つ配信サーバが少ない場合に有効である。
【０１０６】
なお、上記第３実施形態においては、転送速度が相互に異なる複数の配信サーバを例にとって説明したがこれに限定されるものではなく、例えば、コンテンツ配信システムが、相互に同一の転送速度を有する複数の配信サーバからなる配信サーバ群であって、当該転送速度が相互に異なる複数の配信サーバ群を備え、複数の配信サーバ群から一のコンテンツデータが分割されて夫々端末装置２に配信されるようにし、端末装置２の制御部２９が、上記転送速度を変更するタイミングで、接続する配信サーバ群の数を変えるように各配信サーバ群との接続を制御するようにしても良い。
【０１０７】
図２１は、転送速度が相互に異なる３つの配信サーバ群を備えるコンテンツ配信システムの概要構成例を示す図である。図２１の例では、転送速度が最も速い配信サーバ群１Ｄと、転送速度が普通の配信サーバ群１Ｅと、転送速度が最も遅い配信サーバ群１Ｆと、が示されており、夫々の配信サーバ群１Ｄ〜１Ｆは、相互に同一の転送速度を有する３つの配信サーバを備えている。このような構成において、制御すべき転送速度となるように、例えば図１５乃至図１９の処理によって、配信サーバ群１Ｄ〜１Ｆの接続数が変えられる（例えば、図１５乃至図１９の処理において、配信サーバ１Ａが配信サーバ群１Ｄに、配信サーバ１Ｂが配信サーバ群１Ｅに、配信サーバ１Ｃが配信サーバ群１Ｆに、夫々対応する）。このように構成すれば、配信サーバ群のうちの１つの配信サーバが機能停止（ダウン）したときでも、その影響を受けることなくコンテンツデータを再生出力することができる。
【０１０８】
（ＩＶ）第４実施形態
次に、第４実施形態におけるコンテンツ配信システムについて説明する。
【０１０９】
第４実施形態では、図１４に示す複数（ここでは、３つ）の配信サーバ１Ａ，１Ｂ，１Ｃとの接続が順次切り換えられ、コンテンツデータが端末装置２に配信される形態について説明する。
【０１１０】
なお、第４実施形態における配信サーバ１Ａ，１Ｂ，１Ｃ、及び端末装置２の構成及び機能は第１実施形態における配信サーバ１及び端末装置２と基本的には同様であるので、重複した説明は省略する。
【０１１１】
また、第４実施形態においても、第３実施形態と同様、配信サーバ１Ａ，１Ｂ，１Ｃは、夫々、コンテンツデータ（データパケット）の転送速度が相互に異なっており、この３つの配信サーバの中で、転送速度は、配信サーバ１Ａが１番速く、配信サーバ１Ｂは配信サーバ１Ａよりは遅いが配信サーバ１Ｃよりは速く、配信サーバ１Ｃは１番遅くなっている。これらの配信サーバ１Ａ，１Ｂ，１Ｃは、同一のコンテンツデータを有している。
【０１１２】
一方、端末装置２における速度制御手段としての制御部２９は、コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、配信サーバの接続を切り換えるように制御する。
【０１１３】
この転送速度制御について図４を用いて説明すると、例えば、“Ａ”の期間では、転送速度の最も速い配信サーバ１Ａから第１転送速度（配信サーバ１Ａにおいて最も速い速度（フルスピード））でデータパケットが配信されるように制御され、“Ａ”の期間と“Ｂ”の期間との境界で配信サーバ１Ａから配信サーバ１Ｂに切り換えられ、“Ｂ”の期間では、転送速度が普通の配信サーバ１Ｂから第２転送速度でデータパケットが配信されるように制御され、“Ｂ”の期間と“Ｃ”の期間との境界で配信サーバ１Ｂから配信サーバ１Ｃに切り換えられ、“Ｃ”の期間では、転送速度の最も遅い配信サーバ１Ｃから第３転送速度でデータパケットが配信されるように制御される。
【０１１４】
次に、図２２乃至図２６等を参照して、第４実施形態におけるコンテンツ配信システムの動作について説明する。
【０１１５】
図２２乃至図２６は、第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【０１１６】
図２２に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ１７１）、再生可能バッファ量５３未満である場合には（ステップＳ１７１：Ｌ）、ステップＳ１７２に示す第１転送速度での要求処理（図２３）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ１７１：Ｍ）、ステップＳ１７３に示す第２転送速度での要求処理（図２４）に移行し、設定バッファ量５４以上である場合には（ステップＳ１７１：Ｈ）、ステップＳ１７４に示す第３転送速度での要求処理（図２５）に移行する。
【０１１７】
第１転送速度での要求処理においては、図２３に示すように、制御部２９は、配信サーバ１Ａの接続処理を行う（ステップＳ１８１）。当該配信サーバ１Ａの接続処理においては、図２６（Ａ）に示すように、制御部２９は、転送速度の最も速い配信サーバ１Ａに対して接続要求を行い（ステップＳ２１５）、続いて、配信サーバ１Ａとの間の接続確立処理を行い（ステップＳ２１６）、続いて、配信サーバ１Ａに対してコンテンツデータの配信要求を行う（ステップＳ２１７）。
【０１１８】
次いで、制御部２９は、配信サーバ１Ａ以外の接続している配信サーバが有るか否かを判別し（ステップＳ２１８）、有る場合には（ステップＳ２１８：Ｙ）、配信サーバ１Ａ以外の配信サーバとの接続を切り（ステップＳ２１９）、図２３の処理に戻る。
【０１１９】
なお、図２３に示すステップＳ１８２〜ステップＳ１９２までの処理は、図６に示すステップＳ１１〜ステップＳ２１までの処理と同様であるので重複する説明を省略する。
【０１２０】
次に、第２転送速度での要求処理においては、図２４に示すように、制御部２９は、配信サーバ１Ｂの接続処理を行う（ステップＳ１９５）。当該配信サーバ１Ｂの接続処理においては、図２６（Ｂ）に示すように、制御部２９は、配信サーバを切り換えるべく、転送速度の最も速い配信サーバ１Ｂに対して接続要求を行い（ステップＳ２２１）、続いて、配信サーバ１Ｂとの間の接続確立処理を行い（ステップＳ２２２）、続いて、配信サーバ１Ｂに対してコンテンツデータの配信要求を行い（ステップＳ２２３）、配信サーバ１Ｂ以外の配信サーバとの接続を切り（ステップＳ２２４）、図２４の処理に戻る。
【０１２１】
なお、図２４に示すステップＳ１９６〜ステップＳ２０１までの処理は、図７に示すステップＳ２３〜ステップＳ２８までの処理と同様であるので重複する説明を省略する。
【０１２２】
次に、第３転送速度での要求処理においては、図２５に示すように、制御部２９は、配信サーバ１Ｃの接続処理を行う（ステップＳ２０５）。当該配信サーバ１Ｃの接続処理においては、図２６（Ｃ）に示すように、制御部２９は、配信サーバを切り換えるべく、転送速度の最も速い配信サーバ１Ｃに対して接続要求を行い（ステップＳ２２６）、続いて、配信サーバ１Ｃとの間の接続確立処理を行い（ステップＳ２２７）、続いて、配信サーバ１Ｃに対してコンテンツデータの配信要求を行い（ステップＳ２２８）、配信サーバ１Ｃ以外の配信サーバとの接続を切り（ステップＳ２２））、図２５の処理に戻る。
【０１２３】
なお、図２５に示すステップＳ２０６〜ステップＳ２１１までの処理は、図８に示すステップＳ３１〜ステップＳ３６までの処理と同様であるので重複する説明を省略する。
【０１２４】
以上説明したように上記第４実施形態によれば、第１実施形態と同様の効果を有することに加え、例えば他の配信サーバに比べ転送速度の速い配信サーバを多くの端末装置で効率良く利用することができる。
【０１２５】
なお、上記第４実施形態においては、転送速度が相互に異なる複数の配信サーバを例にとって説明したがこれに限定されるものではなく、第３実施形態と同様、例えば、コンテンツ配信システムが、相互に同一の転送速度を有する複数の配信サーバからなる配信サーバ群であって、転送速度が相互に異なる複数の配信サーバ群（例えば、図２１に示すように）を備えるようにし、端末装置２の制御部２９が、上記転送速度を変更するタイミングで、当該転送速度が異なる配信サーバ群に接続を切り換える（例えば、図２２乃至図２６の処理において、配信サーバ群１Ｄ→配信サーバ群１Ｅ→配信サーバ群１Ｆの順に切り換えられる）。このように構成すれば、配信サーバ群のうちの１つの配信サーバが機能停止（ダウン）したときでも、その影響を受けることなくコンテンツデータを再生出力することができる。
【０１２６】
（Ｖ）第５実施形態
次に、第５実施形態におけるコンテンツ配信システムについて説明する。
【０１２７】
第５実施形態では、第４実施形態と同様、図１４に示す複数（ここでは、３つ）の配信サーバ１Ａ，１Ｂ，１Ｃとの接続が順次切り換えられ、コンテンツデータが端末装置２に配信される形態であるが、第５実施形態では、第１〜第３転送速度が端末装置２の要求タイミングで決まるクライアント主導型の形態（第２実施形態と同様）について、図２６乃至図３０等を参照して説明する。なお、第５実施形態における配信サーバ１Ａ，１Ｂ，１Ｃ、及び端末装置２の構成及び機能は第１実施形態における配信サーバ１及び端末装置２と基本的には同様であるので、重複した説明は省略する。
【０１２８】
図２７乃至図３０は、第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【０１２９】
図２７に示す処理は、第１実施形態と同様、例えばユーザから入力部３０を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部２９は、コンテンツデータを構成するデータブロックの番号ｉの初期値として“０”を設定（ｉ＝０に設定）する（ステップＳ２３１）。
【０１３０】
次いで、制御部２９は、第２実施形態と同様、バッファメモリ２２における現在のバッファ量を確認し（ステップＳ２３２）、再生可能バッファ量５３未満である場合には（ステップＳ２３２：Ｌ）、ステップＳ２３３に示す第１待ち時間での要求処理（図２８）に移行し、再生可能バッファ量５３以上設定バッファ量５４未満である場合には（ステップＳ２３２：Ｍ）、ステップＳ２３４に示す第２待ち時間での要求処理（図２９）に移行し、設定バッファ量５４以上である場合には（ステップＳ２３２：Ｈ）、ステップＳ２３５に示す第３待ち時間での要求処理（図３０）に移行する。
【０１３１】
第１待ち時間での要求処理においては、図２８に示すように、制御部２９は、配信サーバ１Ａの接続処理（第４実施形態と同様、図２６（Ａ）の処理）を行う（ステップＳ２４１）。
【０１３２】
なお、図２８に示すステップＳ２４２〜ステップＳ２５４までの処理は、図１０に示すステップＳ５１〜ステップＳ６３までの処理と同様であるので重複する説明を省略する。
【０１３３】
次に、第２転送速度での要求処理においては、図２９に示すように、制御部２９は、配信サーバ１Ｂの接続処理（第４実施形態と同様、図２６（Ｂ）の処理）を行う（ステップＳ２５６）。
【０１３４】
なお、図２９に示すステップＳ２５７〜ステップＳ２６４までの処理は、図１１に示すステップＳ６５〜ステップＳ７２までの処理と同様であるので重複する説明を省略する。
【０１３５】
次に、第３転送速度での要求処理においては、図３０に示すように、制御部２９は、配信サーバ１Ｃの接続処理（第４実施形態と同様、図２６（Ｃ）の処理）を行う（ステップＳ２７１）。
【０１３６】
なお、図３０に示すステップＳ２７２〜ステップＳ２７９までの処理は、図１２に示すステップＳ７５〜ステップＳ８２までの処理と同様であるので重複する説明を省略する。
【０１３７】
以上説明したように上記第５実施形態によっても、第４実施形態と同様の効果を有することができる。
【０１３８】
なお、上記第１乃至第５実施形態においては、本発明を、サーバ−クライアント型のコンテンツ配信システムに対して適用したが、これに限定されるものではなく、ピアツーピア（Peer to Peer（P2P））型のコンテンツ配信システムに対して適用しても良い。ピアツーピア型のコンテンツ配信システムでは、各ピア（ノード）が上述した配信サーバと端末装置としての機能を有することになる。このようなピアツーピア型のコンテンツ配信システムでは、各ノードの配信速度（転送速度）等の能力に差があるので、本発明を適用し、上述したように転送速度を段階的に変更するように制御することは特に有効である。
【０１３９】
また、配信サーバを最上位として複数のノードが複数の階層を形成しつつ通信回線を介してツリー状に接続されたツリー構造ネットワークを有し、配信サーバにより配信されたコンテンツデータが上位階層のノードから下位階層のノードに順次転送されていくようなツリー型コンテンツ配信システムに対しても本発明を適用可能である。この場合、コンテンツデータの配信が開始される際ばかりでなく、コンテンツデータを自ノードに対して転送する直近の上位階層のノードが当該ツリー構造ネットワークから脱退（例えば、電源断等による）したことによって、当該自ノードが他の上位階層のノードに再接続してコンテンツデータの転送を受ける際にも、本発明を適用し、コンテンツデータの再生出力速度以上の範囲において、バッファ量に応じて上記転送速度を段階的に変更（減速）するようにすれば、有効である。
【０１４０】
なお、上記実施形態では、再生可能バッファ量５３未満のとき第１転送速度、再生可能バッファ量５３以上設定バッファ量５４未満のとき第２転送速度、設定バッファ量５４以上のとき第３転送速度にしていたが、再生可能バッファ量５３以下のとき第１転送速度、再生可能バッファ量５３より多くかつ設定バッファ量５４以下のとき第２転送速度、設定バッファ量５４より多いとき第３転送速度にしてもよい。また、再生可能バッファ量５３未満のとき第１転送速度、再生可能バッファ量５３以上かつ設定バッファ量５４以下のとき第２転送速度、設定バッファ量５４より多いとき第３転送速度にしてもよい。また、再生可能バッファ量５３以下のとき第１転送速度、再生可能バッファ量５３より多くかつ設定バッファ量５４未満のとき第２転送速度、設定バッファ量５４以上のとき第３転送速度にしてもよい。なお、本発明における速度制御手段は、バッファメモリにおけるバッファ量に応じて、コンテンツデータの転送速度（配信速度）を、再生出力速度より速い第１転送速度と、第１転送速度より遅く、且つ、再生出力速度より速い第２転送速度と、再生出力速度に追従する第３転送速度と、に切り換えるように制御するものであって、どのバッファ量になったときに転送速度を切り換えるのかに特に限定されるものではない。
【図面の簡単な説明】
【０１４１】
【図１】第１実施形態におけるコンテンツ配信システムの概要構成例を示す図である。
【図２】配信サーバの概要構成例を示すブロック図である。
【図３】端末装置の概要構成例を示すブロック図である。
【図４】コンテンツデータの転送速度が変更される様子を示す概念図である。
【図５】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図６】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図７】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図８】第１実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図９】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１０】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１１】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１２】第２実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１３】端末装置２から配信サーバ１へのデータブロックの要求タイミングの一例を示す図である。
【図１４】第３実施形態、後述する第４及び第５実施形態におけるコンテンツ配信システムの概要構成例を示す図である。
【図１５】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１６】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１７】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１８】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図１９】第３実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２０】端末装置２から配信サーバ１Ａ乃至１Ｃへのデータブロックの要求タイミングの一例を示す図である。
【図２１】転送速度が相互に異なる３つの配信サーバ群を備えるコンテンツ配信システムの概要構成例を示す図である。
【図２２】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２３】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２４】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２５】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２６】第４実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２７】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２８】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図２９】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【図３０】第５実施形態のコンテンツデータ配信の際における端末装置２の制御部２９の処理を示すフローチャートである。
【符号の説明】
【０１４２】
１，１Ａ，１Ｂ，１Ｃ 配信サーバ
２ 端末装置
３ ネットワーク
１１ 記憶部
１２ エンコーダ部
１３ 通信部
１４ 制御部
１５ バス
２１ 記憶部
２２ バッファメモリ
２３ デコーダ部
２４ 映像処理部
２５ 表示部
２６ 音声処理部
２７ スピーカ
２８ 通信部
２９ 制御部
３０ 入力部
３１ バス
【特許請求の範囲】
【請求項１】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する前記配信速度制御装置において、
前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御手段を備え、
前記速度制御手段は、
前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、
前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、
更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする配信速度制御装置。
【請求項２】
請求項１に記載の配信速度制御装置において、
前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始させる再生制御手段を備えることを特徴とする配信速度制御装置。
【請求項３】
請求項２に記載の配信速度制御装置において、
前記速度制御手段は、前記第２配信速度を、前記配信元装置と前記配信先装置とを接続する通信回線における伝送速度の変動を相殺するように設定することを特徴とする配信速度制御装置。
【請求項４】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムにおいて、請求項１から３のいずれか一項に記載の配信速度制御装置を、
備えることを特徴とする配信システム。
【請求項５】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置の配信速度制御方法において、
前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御工程を含み、
前記速度制御工程は、
前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、
前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、
更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする配信速度制御方法。
【請求項６】
請求項５に記載の配信速度制御方法において
前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始することを特徴とする配信速度制御方法。
【請求項７】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置に含まれるコンピュータを、請求項１から３のいずれか一項に記載の配信速度制御装置として機能させることを特徴とする配信速度制御用プログラム。
【請求項１】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する前記配信速度制御装置において、
前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御手段を備え、
前記速度制御手段は、
前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、
前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、
更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする配信速度制御装置。
【請求項２】
請求項１に記載の配信速度制御装置において、
前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始させる再生制御手段を備えることを特徴とする配信速度制御装置。
【請求項３】
請求項２に記載の配信速度制御装置において、
前記速度制御手段は、前記第２配信速度を、前記配信元装置と前記配信先装置とを接続する通信回線における伝送速度の変動を相殺するように設定することを特徴とする配信速度制御装置。
【請求項４】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムにおいて、請求項１から３のいずれか一項に記載の配信速度制御装置を、
備えることを特徴とする配信システム。
【請求項５】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置の配信速度制御方法において、
前記蓄積手段における前記配信情報の蓄積量に基づく前記配信速度を変更するタイミングで、前記配信先装置に配信された前記配信情報の当該配信先装置における再生出力速度以上の範囲において、前記配信速度を変更する速度制御工程を含み、
前記速度制御工程は、
前記蓄積量が前記第１蓄積量より少ない場合、前記配信速度が、前記再生出力速度より速い第１配信速度になるように制御し、
前記蓄積量が前記第１蓄積量以上であり、且つ、当該第１蓄積量より多い予め設定された第２蓄積量より少ない場合、前記配信速度が、前記第１配信速度より遅く、且つ、前記再生出力速度より速い第２配信速度になるように制御し、
更に、前記蓄積量が前記第２蓄積量以上の場合、前記配信速度が前記再生出力速度に追従する第３配信速度になるように制御することを特徴とする配信速度制御方法。
【請求項６】
請求項５に記載の配信速度制御方法において
前記配信先装置は、前記蓄積手段における前記蓄積量が第１蓄積量となったとき、当該配信情報の再生出力を開始することを特徴とする配信速度制御方法。
【請求項７】
配信されるべき配信情報を配信する配信元装置と、前記配信情報の配信を受ける配信先装置であって前記配信された配信情報を一時的に蓄積する蓄積手段を備える配信先装置と、を備える配信システムに含まれ、前記配信元装置から前記配信先装置への前記配信情報の配信速度を制御する配信速度制御装置に含まれるコンピュータを、請求項１から３のいずれか一項に記載の配信速度制御装置として機能させることを特徴とする配信速度制御用プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【公開番号】特開２０１０−８８１３７（Ｐ２０１０−８８１３７Ａ）
【公開日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願番号】特願２０１０−８４９８（Ｐ２０１０−８４９８）
【出願日】平成２２年１月１８日（２０１０．１．１８）
【分割の表示】特願２００５−１０２４０９（Ｐ２００５−１０２４０９）の分割
【原出願日】平成１７年３月３１日（２００５．３．３１）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【出願人】（３９６００４８３３）株式会社エクシング (394)
【出願人】（３０１０２１５３３）独立行政法人産業技術総合研究所 (6,529)
【Ｆターム（参考）】
【公開日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願日】平成２２年１月１８日（２０１０．１．１８）
【分割の表示】特願２００５−１０２４０９（Ｐ２００５−１０２４０９）の分割
【原出願日】平成１７年３月３１日（２００５．３．３１）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【出願人】（３９６００４８３３）株式会社エクシング (394)
【出願人】（３０１０２１５３３）独立行政法人産業技術総合研究所 (6,529)
【Ｆターム（参考）】
[ Back to top ]