(57)【特許請求の範囲】
【請求項１】
コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードから受信ノードへコンテンツを配信するコンテンツ配信方法であって、
受信ノードが、各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信するステップと、
各配信ノードが、受信ノードから該配信予約要求情報を受信するステップと、
各配信ノードが、少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づいて配信開始時刻と配信終了時刻とを決定するステップと、
各配信ノードが、該配信開始時刻を配信予約結果情報として受信ノードに送信するステップと、
受信ノードが、各配信ノードから該配信予約結果情報を受信するステップと、
受信ノードが、該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するステップと、
を具備するコンテンツ配信方法。
【請求項２】
コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードからコンテンツを受信する受信ノードとして機能する通信端末装置であって、
各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信する予約要求送信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づき各配信ノードにおいて決定された配信開始時刻を配信予約結果情報として各配信ノードから受信する予約結果受信手段と、
該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するブロック受信手段と、
を具備する通信端末装置。
【請求項３】
一定時間間隔で定期的に、又は、該配信開始時刻まで一定の時間となったときに、各配信ノードに対して予約通りに配信可能かの確認要求を行い、配信可能である旨の返答が得られなかった場合に、再度、他の配信ノードに対して、前記予約要求送信手段、前記予約結果受信手段及び前記ブロック受信手段を機能させる、請求項２に記載の通信端末装置。
【請求項４】
実際にブロックの受信が開始又は終了した時刻が該配信開始時刻又は該配信終了時刻よりも遅れた場合に、まだ受信されていないブロックについて、前記予約要求送信手段、前記予約結果受信手段及び前記ブロック受信手段を機能させる、請求項２に記載の通信端末装置。
【請求項５】
コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち割当てられたブロックを保持して受信ノードに配信する配信ノードとして機能する通信端末装置であって、
受信ノードからブロックの再生開始時刻を配信予約要求情報として受信する予約要求受信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づいて配信開始時刻と配信終了時刻とを決定する配信時刻決定手段と、
該配信開始時刻を配信予約結果情報として受信ノードに送信する予約結果送信手段と、
を具備する通信端末装置。
【請求項６】
前記配信時刻決定手段は、ブロックサイズをネットワーク帯域で除すことにより配信所要時間を算出するとともに通信遅延時間を測定し、該配信所要時間と該通信遅延時間と該再生開始時刻とに基づき算出される配信開始時刻及び配信終了時刻を該予約状況と照らし合わせ、最終的な配信開始時刻及び配信終了時刻又は配信不可を決定する、請求項５に記載の通信端末装置。
【請求項７】
前記配信時刻決定手段は、更に、受信ノードの優先順位表を備え、既に入っている予約に対応する受信ノードの優先順位と新たな予約要求に対応する受信ノードの優先順位とを比較し、後者の優先順位が高い場合、後者の受信ノードの予約要求を優先して受け付け、前者の受信ノードの予約を取り消す、請求項６に記載の通信端末装置。
【請求項８】
コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードからコンテンツを受信するために、コンピュータを、
各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信する予約要求送信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づき各配信ノードにおいて決定された配信開始時刻を配信予約結果情報として各配信ノードから受信する予約結果受信手段と、
該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するブロック受信手段と、
として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示技術は、ピアツーピア（peer to peer）システム（以下、Ｐ２Ｐシステムともいう。）等の利用者ノード間でデータ交換を行うコンピュータネットワークにおいて、各々割当てられたコンテンツブロックを保持する少なくとも一つの配信ノードから受信ノードへコンテンツを配信する方法、及びその配信ノード又は受信ノードとして機能する通信端末装置に関する。
【背景技術】
【０００２】
コンテンツ配信サービスが普及してきている。それらのサービスの多くは、サーバが直接クライアントから要求を受けて配信する仕組みで実現されている。一方、この方式では、クライアント（ユーザ）が増えるに従って、サーバの負荷が非常に高くなるという問題がある。そこで、ファイル共有システムのプロトコルである BitTorrent（ビットトレント・インコーポレイテッドの登録商標）等では、コンテンツを複数のブロックに分割し、そのブロックを利用者ノード上に分散して配置することで、サーバの負荷を減らす又は無くす仕組みが実現されている。
【０００３】
この方式では、クライアント（受信ノード）は、他の複数の利用者ノード（配信ノード）に対して、あるブロックを持っているかどうかを確認して、そのブロックを取得する、というプロセスを全てのブロックに対して行うことで、ダウンロードを実現している。そして、複数のノードから同時に別のブロックを受信することにより、高速化が図られる。また、よくダウンロードされるコンテンツのブロックを多くの利用者ノードに重複して持たせる等、利用者ノードに分散する方法を工夫することで、効率よくダウンロードすることを可能にする方法が実現されている（例えば、下記特許文献１参照）。
【０００４】
この方法は、ダウンロードを効率的かつ高速に行うことを可能にする一方で、一時期に大きなネットワーク帯域を使用することになる。これに対して、ストリーミングでは、ダウンロードと異なり、コンテンツを受信しながら再生を行うという動作をするため、受信ノードは、再生中にその時点で必要なデータ（現在再生中の部分）を持っている必要がある。しかし、一方で、早ければ早いほどいいというわけではなく、再生しようとしたときにデータがあれば十分である。ダウンロードの仕組みをそのままストリーミングに応用すると、受信が間に合わず再生が途切れてしまう場合や、不要に早く取得することで配信ノードが帯域を使用してしまって他のノードへの配信が非効率になる場合がある。
【０００５】
【特許文献１】特開２００６−０２５４０８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本開示技術は、上述した問題点に鑑みてなされたものであり、その目的は、コンテンツをブロックに分割し、複数のノードに分散することで、効率的にデータ交換を行うシステムにおいて、安定的なストリーミングを実現することができるコンテンツ配信方法及びその装置を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本開示技術の一つの面によれば、コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードから受信ノードへコンテンツを配信するコンテンツ配信方法であって、受信ノードが、各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信するステップと、各配信ノードが、受信ノードから該配信予約要求情報を受信するステップと、各配信ノードが、少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づいて配信開始時刻と配信終了時刻とを決定するステップと、各配信ノードが、該配信開始時刻と該配信終了時刻とを配信予約結果情報として受信ノードに送信するステップと、受信ノードが、各配信ノードから該配信予約結果情報を受信するステップと、受信ノードが、該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するステップと、を具備するコンテンツ配信方法が提供される。
【０００８】
さらに、本開示技術の他の面によれば、上述の方法において当該配信ノード又は受信ノードとして機能する通信端末装置と、コンピュータをその通信端末装置として機能させるためのプログラムと、が提供される。
【発明の効果】
【０００９】
開示の方法及び装置によれば、予約に関する処理により、ストリーミングの最中に、途切れたり、コンテンツの一部を取得することができなくなったりすることが減らされて、ストリーミングを安定化することができる。また、かかる安定化のための従来からの方法として、全てのコンテンツブロックを一旦キャッシュしてから再生するという方法や、複数の配信ノードから同時にブロックを受信することで出来る限り早くブロックを取得しキャッシュして再生するという方法もある。それらと比較して、開示の方法及び装置では、必要な時刻にブロックを取得することが実現される。したがって、複数の受信ノードが存在する場合に、ネットワーク帯域の利用が分散し、ネットワークの輻輳を避けることができる。
【発明を実施するための最良の形態】
【００１０】
以下、添付図面を参照して実施形態について説明する。図１は、本コンテンツ配信方法が実行されるコンピュータネットワーク上の通信システムの例を示すブロック図である。このシステムは、ピアツーピア（Ｐ２Ｐ）通信を行う。Ｐ２Ｐシステムでは、クライアントサーバシステム（client server system）と異なり、通常、あるノードすなわち通信端末装置がコンテンツを受信する側にも配信する側にもなる。便宜上、コンテンツを配信する側を配信ノード、コンテンツを受信する側を受信ノードと呼ぶ。
【００１１】
図１において、符号１１０はメタデータサーバ、符号１２０Ａ、１２０Ｂ及び１２０Ｃはそれぞれ第一、第二及び第三の配信ノード（任意の配信ノードを符号１２０で表す。）、符号１３０は受信ノード、をそれぞれ示す。これらの機器は、通常のパーソナルコンピュータ（以下、「ＰＣ」ともいう。）であり、ネットワーク１００を介して相互に結合されている。ネットワーク１００は、例えば、インターネットである。なお、これらの機器は、ＰＣに限られず、ネットワークに接続可能な家電機器であってもよい。
【００１２】
図２は、メタデータサーバ１１０、配信ノード１２０、又は受信ノード１３０としてのパーソナルコンピュータ（ＰＣ）の概略的ハードウェア構成を示す図である。同図に示されるように、ＰＣは、中央処理装置（ＣＰＵ：central processing unit）２０２、主記憶装置２０４、補助（外部）記憶装置２０６、ネットワークインタフェース部２０８、等を備える。ＣＰＵ ２０２は、バス２００を介して他の構成要素と接続され、主記憶装置２０４にロードされたプログラムを実行することにより、受信ノードや配信ノードとしての機能を実現する。
【００１３】
図３は、受信ノード１３０が配信ノード１２０Ａ、１２０Ｂ及び１２０Ｃからコンテンツブロックを取得して再生する時間経過を例示する図である。この例では、コンテンツが５個のブロックから形成される。そして、受信ノード１３０に対し、配信ノード１２０Ａはブロック３を配信し、配信ノード１２０Ｂはブロック２及びブロック４を配信し、配信ノード１２０Ｃはブロック１及びブロック５を配信する。
【００１４】
図３に示されるように、ブロック１〜５の各々は、受信ノード１３０における再生時点に必要となるデータが受信されていれば十分であることを考慮したタイミングで、配信ノード１２０Ａ、１２０Ｂ及び１２０Ｃから受信ノード１３０に配信されている。すなわち、再生時点より少し前に対応するデータが受信される。したがって、受信ノード１３０においてデータが再生前にキャッシュされている時間は短くなる。そして、配信ノード側の能力やネットワーク帯域に基づいて予測される配信所要時間（配信に要する時間）や通信遅延時間を考慮して、ブロック再生開始の一定時間前にブロックの取得が開始される。
【００１５】
図３に示される例では、ブロック１について、受信ノード１３０における再生所要時間と配信ノード１２０Ｃからの配信所要時間とは同一である。ブロック３については、再生所要時間よりも配信所要時間が短くなっている。ブロック５については、再生所要時間よりも配信所要時間が長くなっている。以上のようにネットワーク帯域の使用を一定化し且つストリーミングを安定化させるための実現方法について、以下、説明する。
【００１６】
図４は、配信ノード１２０及び受信ノード１３０の機能的構成を示す図である。同図に示されるように、受信ノード１３０は、その補助記憶装置内に、コンテンツメタデータ情報４０２、配信ノード情報４０４、ブロック再生時刻情報４０６、予約結果情報４０８、及びコンテンツバッファ４１０を持つ。更に、受信ノード１３０は、その処理機能として、情報管理部４２０、コンテンツ再生部４２２、配信予約部４２４、コンテンツ要求部４２６、コンテンツ受信部４２８、及びネットワーク送受信部４３０を持つ。
【００１７】
一方、配信ノード１２０は、その補助記憶装置内に、予約状況情報４５２、受信ノード優先度情報４５４、ブロック情報４５６、ネットワーク帯域情報４５８、及びコンテンツブロック４６０を持つ。更に、配信ノード１２０は、その処理機能として、情報管理部４７０、予約受信部４７２、コンテンツ配信部４７４、及びネットワーク送受信部４７６を持つ。
【００１８】
本実施形態では、コンテンツは、複数のブロックに分割され、複数のノードに分けて置かれている。そのため、一つのノードがコンテンツの全てを持っている場合に比較して、アクセスが集中しないという利点がある。配信ノードは、コンテンツのブロックを一部もっているだけの場合もあれば、全て持っている場合もありうる。受信ノードは、コンテンツ全体を再生しようとする場合、複数の配信ノードに分散されたブロックを集める必要がある。
【００１９】
受信ノード１３０内のコンテンツメタデータ情報４０２の例が図５に示される。受信ノード１３０は、同図に示されるように、コンテンツを構成するブロック単位に、ブロックを一意に識別するための情報（ブロックＩＤ）と、そのブロックがそのコンテンツ内でのどの部分に当たるか、つまりコンテンツのどの時点（コンテンツの最初からの相対時間で表される。）からどの時点までの部分にあたるかの情報と、をメタデータ４０２として持つ。そして、受信ノード１３０は、そのコンテンツメタデータ情報４０２と、各配信ノードのＩＰアドレスの情報である配信ノード情報４０４と、を持つ。
【００２０】
受信ノード１３０は、この配信ノード情報４０４を取得するために、メタデータ用のサーバすなわち図１に示されるメタデータサーバ１１０にアクセスする。配信ノード情報４０４は、例えば、ＸＭＬ（Extensible Markup Language）文書による、以下のような情報の通信により取得される。
【００２１】
<?xml version=“1.0”?>
<block id=“abc00001”>
<ip>192.168.100.1</ip>
<ip>192.168.100.2</ip>
</block>
<block id=“abc00002”>
<ip>192.168.100.2</ip>    （以下省略）
【００２２】
上記の例は、abc00001 なるＩＤを持つブロックが、192.168.100.1 なるＩＰアドレスを持つノードと、192.168.100.2 なるＩＰアドレスを持つノードとに保持されていることを表している。もちろん、情報の通信内容としては、上記に限られず、ＩＰアドレスだけでなくポートの情報を含めたり、暗号化して通信したりするなど、様々な方式を利用することができる。
【００２３】
受信ノード１３０は、また、コンテンツメタデータ情報４０２についても、通信により、メタデータサーバ１１０から取得する。例えば、前述の配信ノード情報４０４についての通信を拡張した、以下の通信が行われる。
【００２４】
<?xml version=“1.0”?>
<block id=“abc00001” starttime=“00:00:00” endtime=“00:01:00”>
<ip>192.168.100.1</ip>
<ip>192.168.100.2</ip>
</block>
<block id=“abc00002” starttime=“00:01:00” endtime=“00:02:00”>
<ip>192.168.100.2</ip>      (以下省略)
【００２５】
上記の例は、abc00001 なるＩＤを持つブロックがコンテンツ再生開始時から再生開始後１分経過時までのデータであり、abc00002 なるＩＤを持つブロックがコンテンツ再生開始後１分経過時から２分経過時までのデータであることを表している。本実施形態では、受信ノード１３０は、このようにメタデータ情報４０２及び配信ノード情報４０４を予め保持した状態で、ユーザからのコンテンツ再生要求を受ける。しかし、受信ノード１３０は、ユーザからの要求を受けた時点にこれらの情報を獲得するようにしてもよい。
【００２６】
図６は、受信ノード１３０内の配信予約部４２４の処理動作を示すフローチャートである。まず、配信予約部４２４は、ユーザからの指示を受けて、あるコンテンツを再生することを決定する（ステップ６０２）。ユーザからの指示ではなく、自動再生のような仕組みでもかまわない。
【００２７】
次いで、配信予約部４２４は、補助記憶装置から、情報管理部４２０を介して、当該コンテンツに係るメタデータ情報４０２及び配信ノード情報４０４を主記憶装置へと取り込む（ステップ６０４）。
【００２８】
次いで、配信予約部４２４は、コンテンツ再生開始時刻を決定する（ステップ６０６）。この時刻は、ユーザがコンテンツを再生しようとボタン等を押した時刻に、コンテンツのブロック数と配信ノード数とに応じた一定時間を加えることで算出される。かかる一定時間は、“予約に必要な時間×配信ノード数×ブロック数”によって算出される。ここで、予約に必要な時間は推測値とされ、他の値はメタデータ情報４０２及び配信ノード情報４０４から取得される。例えば、予約にかかる時間が０．１秒で、配信ノード数が１０、コンテンツのブロック数が６０とすると、0.1×10×60＝60 秒となる。したがって、ボタン等が押された時刻が 2007/10/29 10:00:00 とすると、再生開始時刻は 2007/10/29 10:01:00 となる。
【００２９】
次いで、配信予約部４２４は、メタデータ情報４０２と決定されたコンテンツ再生開始時刻とに基づいて、ブロックごとに必要となる時刻（ブロック再生開始時刻及びブロック再生終了時刻）を算出し、ブロック再生時刻情報４０６として記憶する（ステップ６０８）。そのブロック再生時刻情報４０６の例が図７に示される。
【００３０】
これ以降、配信予約部４２４は、配信ノード１２０に対する配信予約処理を行う。まず、配信予約部４２４は、全てのブロックについて配信ノードが確定したか否かを判定し（ステップ６１０）、確定した場合には処理を終了する。当初は次のステップに進むこととなる。
【００３１】
配信ノードが確定していないブロックがある場合、配信予約部４２４は、未だ配信ノードが確定していないブロックＩＤを一つ選択する（ステップ６１２）。
【００３２】
次いで、配信予約部４２４は、選択されたブロックＩＤを配信することができる配信ノードのＩＰアドレスから一つを選択する（ステップ６１４）。例えば、前述の例のように、192.168.0.1 と 192.168.0.2 との二つの配信ノードが abc00001 ブロックを持つ場合、abc00001 について、まず、192.168.0.1 のノードが選択される。192.168.0.1 のノードについて既に予約要求が行われ不成功になっている場合には、192.168.0.2 のノードが選択される。
【００３３】
次いで、配信予約部４２４は、ネットワーク送受信部４３０を介し、選択された配信ノードのＩＰアドレスに対して配信についての予約の要求を行う（ステップ６１６）。予約要求は、ブロック再生時刻情報４０６に基づいて、ブロックＩＤとブロック再生開始時刻とブロック再生終了時刻とを通知することで行われる。例えば、192.168.0.1 の配信ノードに対する予約要求の通信データは、次のとおりである。
【００３４】
<?xml version=“1.0”?>
<block action=“reserve” id=“abc00001” playstarttime=“2007/10/29 10:01:00” playendtime=“2007/10/29 10:02:00”/>
【００３５】
次いで、配信予約部４２４は、予約要求先の配信ノードから、予約結果として、配信開始時刻、又は、予約ができなかった旨のエラーを受信する（ステップ６１８）。例えば、ブロック abc00001 についての配信開始時刻を 2007/10/29 10:00:30 とする予約結果の返答データは、次のとおりである。
【００３６】
<?xml version=“1.0”?>
<block action=“reserved” id=“abc00001” sendstarttime=“2007/10/29 10:00:30”/>
【００３７】
次いで、配信予約部４２４は、予約要求先の配信ノードから、配信開始時刻が返却されたか、又はエラーが返却されたか、を判定する（ステップ６２０）。エラーが返却された場合、配信予約部４２４は、ステップ６１０に戻る。
【００３８】
一方、配信開始時刻が返却された場合、配信予約部４２４は、配信開始時刻と配信ノードＩＰアドレスとブロックＩＤとのセットを予約結果情報４０８として記憶する（ステップ６２２）。予約結果情報４０８の例が図８に示される。そして、配信予約部４２４の処理は、ステップ６１０に戻る。
【００３９】
かくして、配信予約部４２４は、全てのブロックの各々について、配信可能なノードが見つかるか又はなくなるまで、配信予約要求処理を繰り返す。全てのブロックについて予約が成功した場合、配信予約部４２４は予約を終了する。もし、予約が失敗した場合、すなわち、あるブロックについて全ての配信ノードかエラーを返却した場合、現在は再生が難しいということになる。そのため、配信予約部４２４は、しばらく待つ旨を示すメッセージを表示し、ユーザにやり直してもらうか、一定時間、待ってからやり直す。
【００４０】
図９は、配信ノード１２０内の予約受信部４７２の処理動作を示すフローチャートである。まず、予約受信部４７２は、ネットワーク送受信部４７６を介して、受信ノード１３０から、ブロックの配信についての予約の要求（ブロックＩＤ、ブロック再生開始時刻及びブロック再生終了時刻）を受信する（ステップ９０２）。
【００４１】
次いで、予約受信部４７２は、ブロックの配信に要する時間（配信所要時間）を算出する（ステップ９０４）。この算出は、次の式、
配信所要時間＝ブロックサイズ／ネットワーク帯域
に示されるように、ブロックのサイズをネットワーク帯域で除すことにより行われる。ブロックサイズ及びネットワーク帯域は、情報管理部４７０を介して、それぞれ、ブロック情報４５６及びネットワーク帯域情報４５８にアクセスすることで取得される。なお、ネットワーク帯域は、例えば、一定のデータをインターネット上のサーバとやりとりすることで調べる方法等の一般的な方法で測定される。ブロックのサイズは、配信ノード自身がブロックを所有しているため、容易に求められる。
【００４２】
次いで、予約受信部４７２は、配信ノード１２０と受信ノード１３０との間の通信遅延時間を計測する（ステップ９０６）。この計測は、例えば、“ping”（パケットが正しく届いて返答が行われるかの確認をする一般的なコマンド）を配信ノード側から受信ノード側に行い、それに要する時間を測定することで行われる。
【００４３】
次いで、予約受信部４７２は、ブロックの配信開始時刻及び配信終了時刻を算出する（ステップ９０８）。“再生終了時刻−配信所要時間−通信遅延時間≦再生開始時刻”が成立する場合、配信開始時刻は、
配信開始時刻＝再生終了時刻−配信所要時間−通信遅延時間
として求められ、一方、“再生終了時刻−配信所要時間−通信遅延時間＞再生開始時刻”が成立する場合、配信開始時刻は、
配信開始時刻＝再生開始時刻−通信遅延時間
として求められる。また、配信終了時刻は、
配信終了時刻＝配信開始時刻＋配信所要時間
として求められる。なお、配信所要時間又は通信遅延時間のいずれか一方のみに基づいてブロックの配信開始時刻及び配信終了時刻を決定するようにしてもよい。
【００４４】
次いで、予約受信部４７２は、情報管理部４７０を介して、現時点での最新の予約状況情報４５２を確認する（ステップ９１０）。予約状況情報４５２は、図１０に示されるように、配信開始時刻と配信終了時刻と受信ノードＩＰアドレスとからなる記録を集めたものである。
【００４５】
予約受信部４７２は、算出された配信時間に、既に予約が入っている場合、受信ノード優先度情報４５４を参照することにより、予約済みの受信ノードの優先度と今回の予約要求に係る受信ノードの優先度とを比較する（ステップ９１２）。受信ノード優先度情報４５４は、図１１に示されるように、ＩＰアドレス毎に優先順位を規定する情報である。Ｐ２Ｐシステムでは、配信するデータが多いノードほど受信時に優遇されるような実装がなされることが多い。本実施形態では、それを考慮して、ノードに優先度が付けられており、優先度が高いノードから予約要求がなされたときに、既に入っている予約は無効にされ、新たな予約要求が受け付けられる。
【００４６】
次いで、予約受信部４７２は、ステップ９１０及び９１２の結果、予約状況や受信ノード優先度に照らし、処理対象の予約要求に対して予約可能か否かを判断する（ステップ９１４）。予約可能な場合、予約受信部４７２は、予約結果として配信開始時刻を受信ノード１３０に返答する（ステップ９１６）とともに、その新しい予約情報を予約状況情報４５２に登録して（ステップ９１８）、処理を終了する。
【００４７】
一方、ステップ９１４において予約不能と判断される場合、予約受信部４７２は、配信開始時刻及び配信終了時刻を前倒しすることで予約が入っていない時間帯に配信することが可能か否かについての検討、すなわち配信可能な時間についての探索を行う（ステップ９２０）。配信可能な時間が存在する場合、予約受信部４７２は、ステップ９１６へと進む。一方、配信可能な時間が存在しない場合、予約受信部４７２は、受信ノード１３０にエラーを返答して（ステップ９２４）、処理を終了する。
【００４８】
図１２は、受信ノード１３０内のコンテンツ要求部４２６の処理動作を示すフローチャートである。まず、コンテンツ要求部４２６は、情報管理部４２０を介して補助記憶装置から予約結果情報４０８を主記憶装置へと取り込む（ステップ１２０２）。
【００４９】
次いで、コンテンツ要求部４２６は、現在時刻が、予約結果情報４０８に示される、いずれかの配信開始時刻になったか否かを判定する（ステップ１２０４）。現在時刻が配信開始時刻になっている場合、コンテンツ要求部４２６は、対応する配信ノードＩＰアドレスに対してブロックを要求し（ステップ１２０６）、ブロックの要求をしたことをコンテンツ受信部４２８に通知する（ステップ１２０８）。
【００５０】
また、コンテンツ要求部４２６は、現在時刻が、いずれかの配信開始時刻より一定時間前（例えば、１分前）の時刻になったか否かを判定する（ステップ１２１０）。その判定結果がＹＥＳの場合、コンテンツ要求部４２６は、該当する配信ノード１２０に対し、配信開始時刻に予約通りに配信可能かどうかの確認を行う（ステップ１２１２）。これは、配信開始時刻が返答されたにもかかわらず、その後、配信ノードの電源がオフされること等により、配信の開始ができなくなる場合があるためである。この確認については、例えば、以下のようなデータを通信し、返答を確認すればいい。
【００５１】
<?xml version=“1.0”?>
<block action=“confirm” id=“abc00001” sendtime=“2007/10/29 10:00:30”/>
【００５２】
エラーが返答された場合や通信できなかった場合、コンテンツ要求部４２６は、その旨を配信予約部４２４に通知する（ステップ１２１４及び１２１６）。配信予約部４２４は、ステップ６１２（図６）からの処理を再度行うことで、そのブロックのみ予約をやり直す。
【００５３】
コンテンツ要求部４２６は、全てのブロックについての配信要求を完了するまで、以上のステップを繰り返す（ステップ１２１８）。なお、配信ノードが予約通りに配信可能か否かの確認は、配信開始時刻まで一定の時間となった時刻に行うのではなく、一定時間間隔で定期的に行うようにしてもよい。
【００５４】
図１３は、受信ノード１３０内のコンテンツ受信部４２８の処理動作を示すフローチャートである。まず、コンテンツ要求部４２６からの通知を受けて、コンテンツ受信部４２８は、ネットワーク送受信部４３０を介して配信ノード１２０からブロックを受信し、コンテンツバッファ４１０に記録する処理を開始する（ステップ１３０２）。なお、記録されたコンテンツブロックは、コンテンツ再生部４２２による通常のストリーミング再生処理によって再生される。
【００５５】
次いで、コンテンツ受信部４２８は、情報管理部４２０を介して、当該ブロックに関するブロック再生時刻情報４０６（ブロック再生開始時刻及びブロック再生終了時刻）を取得する（ステップ１３０４）。そして、コンテンツ受信部４２８は、再生開始時刻までにブロックの受信を開始することができたか否かを判定する（ステップ１３０６）。予定通りブロック受信を開始することができた場合、コンテンツ受信部４２８は、ブロックの受信及びバッファへの記録を終了した（ステップ１３０８）後に、再生終了時刻までにブロックの受信を終了することができたか否かを判定する（ステップ１３１０）。
【００５６】
再生開始時刻までにブロックの受信を開始することができなかった場合、又は、再生終了時刻までにブロックの受信を終了することができなかった場合、コンテンツ受信部４２８は、その旨を配信予約部４２４に通知する（ステップ１３１２）。配信予約部４２４は、ステップ６１２（図６）からの処理を再度行うことで、未だ取得されていないブロックについて予約をやり直す。
【００５７】
例えば、別のノードがデータのやりとりを行った結果、通信しにくい状態になった場合等、ネットワーク帯域が何らかの原因で不足した場合、ブロックの受信が再生に間に合わない場合がある。その結果として、再生が遅れ、後続のブロックが予約された時刻より受信するのが遅くてもよくなったり、逆にネットワーク環境次第ではより早く受信する必要が発生したりすることが考えられる。本実施形態では、予定とのずれが起こった場合、再度、予約処理がやり直されて、そのような状態から抜け出すことができる。
【００５８】
図１４は、開示のコンテンツ配信方法によるネットワーク使用帯域の時間的変化を従来例と比較しつつ説明する図である。ライン１４０２は、コンテンツの複数ブロックを同時に迅速にダウンロードしてキャッシュするという第一の従来例の場合のネットワーク使用帯域の時間的変化である。この従来例では、迅速にコンテンツを取得しようとするため、ネットワーク使用帯域に偏りが生ずる。
【００５９】
また、ライン１４０４は、再生時刻に合わせて配信ノードに問い合わせてブロックを取得するという第二の従来例の場合のネットワーク使用帯域の時間的変化である。この従来例では、そのブロックを保持する配信ノードが他のノードに配信している等により配信不能となる場合があり、その場合には再生が途切れることとなる。
【００６０】
一方、ライン１４０６は、本開示技術の場合のネットワーク使用帯域の時間的変化である。本開示技術では、配信予約部４２４により、ストリーミングが可能かどうかについて事前に判定がなされる。さらに、予約受信部４７２により、配信時刻をずらすことが可能である。結果として、必要な時刻に安定的にブロックを取得することが実現される。また、複数の受信ノードが存在する場合に、ネットワーク帯域の利用が分散し、ネットワークの輻輳を避けることができる。
【００６１】
以上の実施形態に関し、以下の付記を開示する。
【００６２】
（付記１）  コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードから受信ノードへコンテンツを配信するコンテンツ配信方法であって、
受信ノードが、各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信するステップと、
各配信ノードが、受信ノードから該配信予約要求情報を受信するステップと、
各配信ノードが、少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づいて配信開始時刻と配信終了時刻とを決定するステップと、
各配信ノードが、該配信開始時刻と該配信終了時刻とを配信予約結果情報として受信ノードに送信するステップと、
受信ノードが、各配信ノードから該配信予約結果情報を受信するステップと、
受信ノードが、該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するステップと、
を具備するコンテンツ配信方法。
【００６３】
このような構成によれば、配信予約要求情報にしたがって事前に配信開始時刻と配信終了時刻を決定することができることで、受信ノードが要求するタイミングにあわせてブロックを供給することができ、受信ノードが必要以上に早くブロックを受信することがなくなり、ネットワークを流れるデータの平準化や受信ノード側のキャッシュ容量を小さくすることが可能となるなどの効果が期待される。
【００６４】
（付記２）  コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードと、コンテンツを受信する受信ノードと、を含むコンピュータネットワーク上の通信システムであって、受信ノードが、
各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信する予約要求送信手段、
を具備し、各配信ノードが、
受信ノードから該配信予約要求情報を受信する予約要求受信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づいて配信開始時刻と配信終了時刻とを決定する配信時刻決定手段と、
該配信開始時刻と該配信終了時刻とを配信予約結果情報として受信ノードに送信する予約結果送信手段と、
を具備し、受信ノードが、更に、
各配信ノードから該配信予約結果情報を受信する予約結果受信手段と、
該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するブロック受信手段と、
を具備する通信システム。
【００６５】
このような構成によれば、配信予約要求情報にしたがって事前に配信開始時刻と配信終了時刻を決定することができることで、受信ノードが要求するタイミングにあわせてブロックを供給することができ、受信ノードが必要以上に早くブロックを受信することがなくなり、ネットワークを流れるデータの平準化や受信ノード側のキャッシュ容量を小さくすることが可能となるなどの効果が期待される。
【００６６】
（付記３）  コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードからコンテンツを受信する受信ノードとして機能する通信端末装置であって、
各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信する予約要求送信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づき各配信ノードにおいて決定された配信開始時刻と配信終了時刻とを配信予約結果情報として各配信ノードから受信する予約結果受信手段と、
該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するブロック受信手段と、
を具備する通信端末装置。
【００６７】
このような構成によれば、配信予約要求情報にしたがって事前に配信開始時刻と配信終了時刻を決定することができることで、受信ノードが要求するタイミングにあわせてブロックを供給することができ、受信ノードが必要以上に早くブロックを受信することがなくなり、ネットワークを流れるデータの平準化や受信ノード側のキャッシュ容量を小さくすることが可能となるなどの効果が期待される。
【００６８】
（付記４）  一定時間間隔で定期的に、又は、該配信開始時刻まで一定の時間となったときに、各配信ノードに対して予約通りに配信可能かの確認要求を行い、配信可能である旨の返答が得られなかった場合に、再度、他の配信ノードに対して、前記予約要求送信手段、前記予約結果受信手段及び前記ブロック受信手段を機能させる、付記３に記載の通信端末装置。
【００６９】
このような構成によれば、確認要求を行い、確認の結果に基づいて予約要求送信を再度行うことにより、配信ノード側の状況変化等の要因により配信できなくなる場合にも対応することが可能となるなどの効果が期待される。
【００７０】
（付記５）  実際にブロックの受信が開始又は終了した時刻が該配信開始時刻又は該配信終了時刻よりも遅れた場合に、まだ受信されていないブロックについて、前記予約要求送信手段、前記予約結果受信手段及び前記ブロック受信手段を機能させる、付記３に記載の通信端末装置。
【００７１】
このような構成によれば、ブロックの受信が開始された時刻又は終了した時刻が、配信開始時刻又は配信終了時刻よりも遅れた場合は、ネットワーク等に状況の変化があったと推測し、予約要求をサイド送信することにより状況の変化が生じた場合にも柔軟に対応することが可能となるなどの効果が期待される。
【００７２】
（付記６）  コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち割当てられたブロックを保持して受信ノードに配信する配信ノードとして機能する通信端末装置であって、
受信ノードからブロックの再生開始時刻を配信予約要求情報として受信する予約要求受信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づいて配信開始時刻と配信終了時刻とを決定する配信時刻決定手段と、
該配信開始時刻と該配信終了時刻とを配信予約結果情報として受信ノードに送信する予約結果送信手段と、
を具備する通信端末装置。
【００７３】
このような構成によれば、配信ノードにおいて、配信予約要求情報にしたがって事前に配信開始時刻と配信終了時刻を決定することができることで、受信ノードが要求するタイミングにあわせてブロックを供給することができ、受信ノードが必要以上に早くブロックを受信することがなくなり、ネットワークを流れるデータの平準化や受信ノード側のキャッシュ容量を小さくすることが可能となるなどの効果が期待される。
【００７４】
（付記７）  前記配信時刻決定手段は、ブロックサイズをネットワーク帯域で除すことにより配信所要時間を算出するとともに通信遅延時間を測定し、該配信所要時間と該通信遅延時間と該再生開始時刻とに基づき算出される配信開始時刻及び配信終了時刻を該予約状況と照らし合わせ、最終的な配信開始時刻及び配信終了時刻又は配信不可を決定する、付記６に記載の通信端末装置。
【００７５】
このような構成によれば、配信所要時間と通信遅延時間を使用することで、配信開始時刻をより正確に算出することができ、配信が間に合わなくなりストリーミングが途切れるという可能性を低減させ、結果として、ストリーミングを途切れさせることなく最後まで安定して配信させることが可能となるなどの効果が期待される。
【００７６】
（付記８）  前記配信時刻決定手段は、更に、受信ノードの優先順位表を備え、既に入っている予約に対応する受信ノードの優先順位と新たな予約要求に対応する受信ノードの優先順位とを比較し、後者の優先順位が高い場合、後者の受信ノードの予約要求を優先して受け付け、前者の受信ノードの予約を取り消す、付記７に記載の通信端末装置。
【００７７】
このような構成によれば、優先順位表にしたがって複数の受信ノード間で予約を変更することにより、重要な受信ノードが途中でストリーミングが受けられなくなる可能性を低減し、結果として、ストリーミングを途切れさせること無く最後まで安定して配信させることが可能となるなどの効果が期待される。
【００７８】
（付記９）  コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち各々割当てられたブロックを保持する少なくとも一つの配信ノードからコンテンツを受信するために、コンピュータを、
各ブロックの再生開始時刻を配信予約要求情報として対応する各配信ノードに送信する予約要求送信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づき各配信ノードにおいて決定された配信開始時刻と配信終了時刻とを配信予約結果情報として各配信ノードから受信する予約結果受信手段と、
該配信予約結果情報に応じて各配信ノードにブロックを要求して受信するブロック受信手段と、
として機能させるプログラム。
【００７９】
このような構成によれば、配信予約要求情報にしたがって事前に配信開始時刻と配信終了時刻を決定することができることで、受信ノードが要求するタイミングにあわせてブロックを供給することができ、受信ノードが必要以上に早くブロックを受信することがなくなり、ネットワークを流れるデータの平準化や受信ノード側のキャッシュ容量を小さくすることが可能となるなどの効果が期待される。
【００８０】
（付記１０）  コンピュータネットワークにおいて、コンテンツを形成する複数のブロックのうち割当てられたブロックを保持して受信ノードに配信するために、コンピュータを、
受信ノードからブロックの再生開始時刻を配信予約要求情報として受信する予約要求受信手段と、
少なくとも該配信予約要求情報と予約状況とネットワーク帯域情報とに基づいて配信開始時刻と配信終了時刻とを決定する配信時刻決定手段と、
該配信開始時刻と該配信終了時刻とを配信予約結果情報として受信ノードに送信する予約結果送信手段と、
として機能させるプログラム。
【００８１】
このような構成によれば、配信予約要求情報にしたがって事前に配信開始時刻と配信終了時刻を決定することができることで、受信ノードが要求するタイミングにあわせてブロックを供給することができ、受信ノードが必要以上に早くブロックを受信することがなくなり、ネットワークを流れるデータの平準化や受信ノード側のキャッシュ容量を小さくすることが可能となるなどの効果が期待される。
【図面の簡単な説明】
【００８２】
【図１】本コンテンツ配信方法が適用されるコンピュータネットワーク上の通信システムの例を示すブロック図である。
【図２】メタデータサーバ、配信ノード又は受信ノードとしてのパーソナルコンピュータの概略的ハードウェア構成を示す図である。
【図３】受信ノードが配信ノードからコンテンツブロックを取得して再生する時間経過を例示する図である。
【図４】配信ノード及び受信ノードの機能的構成を示す図である。
【図５】受信ノード内のコンテンツメタデータ情報を例示する図である。
【図６】受信ノード内の配信予約部の処理動作を示すフローチャートである。
【図７】受信ノード内のブロック再生時刻情報を例示する図である。
【図８】受信ノード内の予約結果情報を例示する図である。
【図９】配信ノード内の予約受信部の処理動作を示すフローチャートである。
【図１０】配信ノード内の予約状況情報を例示する図である。
【図１１】配信ノード内の受信ノード優先度情報を例示する図である。
【図１２】受信ノード内のコンテンツ要求部の処理動作を示すフローチャートである。
【図１３】受信ノード内のコンテンツ受信部の処理動作を示すフローチャートである。
【図１４】開示のコンテンツ配信方法によるネットワーク使用帯域の時間的変化を従来例と比較しつつ説明する図である。
【符号の説明】
【００８３】
１００    ネットワーク
１１０    メタデータサーバ
１２０（１２０Ａ，１２０Ｂ，１２０Ｃ）    配信ノード
１３０    受信ノード
２００    バス
２０２    中央処理装置（ＣＰＵ）
２０４    主記憶装置
２０６    補助（外部）記憶装置
２０８    ネットワークインタフェース部
４０２    コンテンツメタデータ情報
４０４    配信ノード情報
４０６    ブロック再生時刻情報
４０８    予約結果情報
４１０    コンテンツバッファ
４２０    情報管理部
４２２    コンテンツ再生部
４２４    配信予約部
４２６    コンテンツ要求部
４２８    コンテンツ受信部
４３０    ネットワーク送受信部
４５２    予約状況情報
４５４    受信ノード優先度情報
４５６    ブロック情報
４５８    ネットワーク帯域情報
４６０    コンテンツブロック
４７０    情報管理部
４７２    予約受信部
４７４    コンテンツ配信部
４７６    ネットワーク送受信部
【図１】
0005223480.tif 000002
【図２】
0005223480.tif 000003
【図３】
0005223480.tif 000004
【図４】
0005223480.tif 000005
【図５】
0005223480.tif 000006
【図６】
0005223480.tif 000007
【図７】
0005223480.tif 000008
【図８】
0005223480.tif 000009
【図９】
0005223480.tif 000010
【図１０】
0005223480.tif 000011
【図１１】
0005223480.tif 000012
【図１２】
0005223480.tif 000013
【図１３】
0005223480.tif 000014
【図１４】
0005223480.tif 000015