JP2012175274A

JP2012175274A - コンテンツ配信システム、コンテンツ配信方法、ならびにコンテンツ配信システムに用いられるピア、アプリケーションサーバ及びキャッシュサーバ

Info

Publication number: JP2012175274A
Application number: JP2011033734A
Authority: JP
Inventors: Kei Fujimoto; 圭藤本; Takeshi Miyasaka; 武志宮坂; Koichi Genda; 浩一源田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2011-02-18
Filing date: 2011-02-18
Publication date: 2012-09-10

Abstract

【課題】事前にコンテンツを集約して配備する必要がなく、また、コンテンツ数や容量が増加したり、突発的に視聴数が増加した場合でも滞ることなくコンテンツを配信することができる。
【解決手段】コンテンツ配信システム１００に用いられるコンテンツ配信方法は、視聴数が少ない間は、同一のコンテンツのデータをキャッシュしている３つのピア１０からコンテンツのデータを同時配信することで、ピア１０相互間でコンテンツの配信を行い、視聴数が増加してきたら（上り帯域を圧迫してきたら）、当該コンテンツのデータをキャッシュサーバ３０に配備し、新しい視聴要求に対してキャッシュサーバ３０からピア１０にコンテンツのデータを配信する。
【選択図】図１

Description

本発明は、コンテンツのストリーミング配信を行うための、コンテンツ配信システム、コンテンツ配信方法、ならびにコンテンツ配信システムに用いられるピア、アプリケーションサーバ及びキャッシュサーバに関する。

コンテンツ配信方法として、「ＣＤＮ(Contents Delivery Network)コンテンツ配信方法」と「Ｐ２Ｐ(Peer to Peer)コンテンツ配信方法」とがある。

ＣＤＮコンテンツ配信方法は、コンテンツを配信サーバに配備しユーザ端末に配信する。そしてこのＣＤＮコンテンツ配信方法として、配信サーバを複数配備することで負荷分散を行う技術、コンテンツを先読みして端末側でバッファを蓄え、配信が滞った場合にバッファ対応時間内で配信サーバを切り替えることで信頼性を向上する技術、複数の配信サーバが同一のコンテンツを配信する多重配信を行うことで信頼性を向上する技術等が開示されている（例えば、非特許文献１参照）。

Ｐ２Ｐコンテンツ配信方法は、ユーザ端末(ピア)から他のユーザ端末にコンテンツを直接配信する。Ｐ２Ｐコンテンツ配信方法は、ユーザ端末(ピア)がコンテンツをキャッシュすることより配信ノードが増えるため、配信ノードにかかる負荷を分散させることができ、突発的な視聴数の増加に対応することができる（例えば、非特許文献２参照）。

また、コンテンツについて視聴数が少ない間はＣＤＮコンテンツ配信方法で配信し、視聴数が増加し、ピアにキャッシュが拡散してきた段階で、Ｐ２Ｐコンテンツ配信方法に切り替える、ＣＤＮコンテンツ配信方法とＰ２Ｐコンテンツ配信方法を併用する方法もある。このＣＤＮコンテンツ配信方法をＰ２Ｐコンテンツ配信方法に切り替えるコンテンツ配信方法を用いることにより、設備投資（配信サーバ増強）を抑制しつつ視聴数の増加に対応する技術が開示されている（例えば、非特許文献３参照）。

"ＣＤＮＷｅｂ負荷分散"、[online]、株式会社Ｊストリーム、[平成２３年２月１日検索]、インターネット、＜http://www.jstream.jp/service/pc/delivery/cdn/＞ "ｍｅｓｈＣａｓｔ"、[online]、ＮＥＣビッグローブ株式会社、[平成２３年２月１日検索]、インターネット、＜http://business.biglobe.ne.jp/streaming/service/meshcast.html＞ "ＢｉｔＴｏｒｒｅｎｔＤＮＡ"、[online]、BitTorrent,Inc.、[平成２３年２月１日検索]、インターネット、＜http://www.bittorrent.com/dna＞

しかしながら、ＣＤＮコンテンツ配信方法、Ｐ２Ｐコンテンツ配信方法、及びコンテンツについて視聴数が少ない間はＣＤＮコンテンツ配信方法で配信し、視聴数が増加し、ピアにキャッシュが拡散してきた段階で、Ｐ２Ｐコンテンツ配信方法に切り替えるコンテンツ配信方法には、種々の課題が存在する。以下、各コンテンツ配信方法の課題について説明する。

ＣＤＮコンテンツ配信方法には以下に示すような課題がある。
（課題1-1）
近年では、企業が配信する音楽や動画といったコンテンツに加え、携帯電話で撮影した動画といったユーザ投稿型のコンテンツが著しく増加しており、その容量も増大している。コンテンツを配信する配信サーバにそれら全てのコンテンツを配備するためには、必要となるサーバ能力や台数を大幅に増やさなくてはならない。そのため、将来は、全てのコンテンツを配信サーバに配備することが困難となり、一部のコンテンツをユーザ端末に配備することが想定される。

（課題1-2）
また、コンテンツは、口コミ、Twitter(登録商標)、テレビ等で紹介されることにより、突発的に視聴数が増加する可能性を持っている。ＣＤＮコンテンツ配信方法によるコンテンツの配信は、配信サーバの能力を向上させ、又は配信サーバの台数を増やすことで突発的な視聴数増加に対応可能だが、この対応にも限界がある。

（課題1-3）
また、ＣＤＮコンテンツ配信方法は、コンテンツを先読みしてユーザ端末側でバッファを蓄え、配信が滞った場合にバッファ対応時間内で配信サーバを切り替えることで信頼性を向上することが可能である。しかしながら、バッファを蓄えるために先読みダウンロードを行うため、再生ビットレートよりも大きな帯域を要し、バッファ対応時間内に代替サーバが見つからない場合は再生が滞ってしまう課題がある。また、複数の配信サーバが同一のコンテンツを配信する多重配信を行うことで信頼性を向上することが可能であるが、２重同時配信を行うとおよそ２倍の帯域を要す課題がある。

Ｐ２Ｐコンテンツ配信方法は、ユーザ端末(ピア)から直接コンテンツ配信を行うことが可能であり、突発的な視聴数増加に方式上対応可能であるが、以下に示すような課題がある。

（課題2-1）
Ｐ２Ｐコンテンツ配信方法では、ユーザ端末(ピア)は各々のユーザにより管理されているので、予期しないユーザ端末(ピア)の電源ＯＦＦ等により配信が滞り、再生が停止してしまう可能性がある。
課題2-1を解決するための従来技術として、視聴端末側でバッファを蓄えることにより、配信が滞った場合にも、バッファ対応時間内で新しい配信ノードを探しつなぎ替える技術がある。しかし、この技術は、バッファ対応時間内に新しい配信ノードにつなぎ替えることができない場合に、再生が停止してしまう課題がある。また、バッファを蓄えるために先読みダウンロードを行うため、再生ビットレートよりも大きい帯域を要す課題がある。

（課題2-2）
Ｐ２Ｐコンテンツ配信方法は、視聴数の増加により、上り帯域を圧迫する可能性がある。ここで、下り帯域よりも上り帯域の圧迫が問題となるのは、一般的なネットワークでは、下り帯域よりも上り帯域の容量を低く抑えているためである。

コンテンツについて視聴数が少ない間はＣＤＮコンテンツ配信方法で配信し、視聴数が増加し、ピアにキャッシュが拡散してきた段階で、Ｐ２Ｐコンテンツ配信方法に切り替えるコンテンツ配信方法は、以下に示すような課題がある。
（課題3-1）
ＣＤＮコンテンツ配信方法からＰ２Ｐコンテンツ配信方法に配信方法を切り替えるコンテンツ配信方法は、設備投資を抑制しつつ視聴数の増加に対応することができるが、このコンテンツ配信方法では、全てのコンテンツのデータを配信サーバに配備することを前提としており、コンテンツ数や容量の増加により、全てのコンテンツのデータを配信サーバに配備することが困難となる課題を解決することができない。

本発明は前記問題に鑑みてなされたものであり、事前にコンテンツを集約して配備する必要がなく、また、コンテンツ数や容量が増加したり、突発的に視聴数が増加した場合でも滞ることなくコンテンツを配信することができる、コンテンツ配信システム、コンテンツ配信方法、ならびにコンテンツ配信システムに用いられるピア、アプリケーションサーバ及びキャッシュサーバを提供することを課題とする。

前記課題を解決するために、本発明に係るコンテンツ配信システムは、複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムであって、前記ピアは、前記コンテンツのデータが記憶される第１のキャッシュ部と、前記コンテンツの視聴要求を前記アプリケーションサーバに送信する視聴要求部と、前記アプリケーションサーバから前記コンテンツの配信指示を受信すると、前記第１のキャッシュ部に記憶される前記コンテンツのデータを、所定サイズのフレームに分割し時系列順に連続番号を付したフレーム群とし、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータに分割する分割部と、前記分割部で分割した前記３種類のデータの内、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信する第１の配信部と、前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第１のキャッシュ部に復元したコンテンツのデータを記憶させる第１の統合部と、を備え、前記アプリケーションサーバは、前記コンテンツ毎に当該コンテンツのデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルと、前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定する切替判定部と、前記切替判定部が、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツのデータを記憶する前記ピアを３つ選択し、前記選択したピアのそれぞれを当該コンテンツの奇数フレームデータを配信する第１のピアと、当該コンテンツの偶数フレームデータを配信する第２のピアと、当該コンテンツのＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算する管理部と、前記切替判定部が、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替える切替部と、を備え前記キャッシュサーバは、前記コンテンツのデータが記憶される第２のキャッシュ部と、前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツのデータを記憶する前記ピアから当該コンテンツのデータを取得し、前記第２のキャッシュ部に前記取得した当該コンテンツのデータを記憶させる第２の統合部と、前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する第２の配信部と、を備える、ことを特徴とする。

また、本発明に係るコンテンツ配信方法は、複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムのコンテンツ配信方法であって、前記ピアは、前記コンテンツの視聴要求を前記アプリケーションサーバに送信し、前記アプリケーションサーバは、前記コンテンツ毎に当該コンテンツのデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルを備え、前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定し、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツのデータを記憶する前記ピアを３つ選択し、前記選択したピアのそれぞれを当該コンテンツの奇数フレームデータを配信する第１のピアと、当該コンテンツの偶数フレームデータを配信する第２のピアと、当該コンテンツのＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに前記配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算し、前記アプリケーションサーバにより決定された前記第1のピア、第２のピア、第３のピアのそれぞれは、前記コンテンツのデータが記憶される第１のキャッシュ部を備え、前記アプリケーションサーバから前記配信指示を受信すると、前記第１のキャッシュ部に記憶される前記コンテンツのデータを、所定サイズのフレームに分割し時系列順に連続番号を付したフレーム群とし、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータに分割し、分割した前記３種類のデータの内、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信し、前記視聴要求を送信した前記ピアは、前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第１のキャッシュ部に復元したコンテンツのデータを記憶し、前記アプリケーションサーバは、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替え、前記キャッシュサーバは、前記コンテンツのデータが記憶される第２のキャッシュ部を備え、前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツのデータを記憶する前記ピアから当該コンテンツのデータを取得し、前記第２のキャッシュ部に前記取得した当該コンテンツのデータを記憶し、前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する、ことを特徴とする。

このようにすることで、本発明に係るコンテンツ配信システム及びコンテンツ配信方法は、コンテンツの視聴数が少ない間は各ピア相互間でコンテンツの配信を行う。よって、本発明に係るコンテンツ配信システム及びコンテンツ配信方法によれば、事前にコンテンツを集約して配備する必要がなく、また、コンテンツの突発的な視聴数増加に対応可能である。

また、本発明に係るコンテンツ配信システム及びコンテンツ配信方法は、コンテンツの視聴に際して、コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータの３種類のデータが３つのピアから配信される(３重同時配信)。よって、本発明に係るコンテンツ配信システム及びコンテンツ配信方法によれば、コンテンツのデータを配信中のピアが突然に電源ＯＦＦされることにより、当該ピアからの配信が途絶えても、３ピアの内２ピアからの配信が継続する限りコンテンツのデータを復元することができるので、ユーザはコンテンツを滞ることなく視聴することができる。

また、本発明に係るコンテンツ配信システム及びコンテンツ配信方法は、３重同時配信のデータとして、オリジナルコンテンツのデータサイズと比較して０．５倍のデータサイズである奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータを用いる。よって、本発明に係るコンテンツ配信システム及びコンテンツ配信方法によれば、１対１でコンテンツを配信する非多重化配信に対し、およそ１．５倍のトラヒック増で約２倍の信頼性を得ることができる。

また、本発明に係るコンテンツ配信システム及びコンテンツ配信方法は、コンテンツの視聴数が少ない間は各ピア相互間でコンテンツの配信を行い、当該コンテンツの視聴数が増加してきたらキャッシュサーバを併用してコンテンツの配信を行う。よって、本発明に係るコンテンツ配信システム及びコンテンツ配信方法によれば、各ピア相互間でコンテンツの配信を行うことにより発生する上り帯域の圧迫を軽減することができる。

また、本発明に係るコンテンツ配信システムは、複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムであって、前記ピアは、前記コンテンツのデータが所定サイズのフレームに分割されて時系列順に連続番号が付されたフレーム群とされ、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータの内、何れか１種類が記憶される第１のキャッシュ部と、前記コンテンツの視聴要求を前記アプリケーションサーバに送信する視聴要求部と、前記アプリケーションサーバから前記コンテンツの配信指示を受信すると、前記第１のキャッシュ部に記憶される、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信する第１の配信部と、前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記受信した３種類のデータの内、何れか１種類を前記第１のキャッシュ部に記憶させる第１の統合部と、を備え、前記アプリケーションサーバは、前記コンテンツの前記奇数フレームデータ、前記偶数フレームデータ、前記ＸＯＲデータの何れか１種類のデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルと、前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定する切替判定部と、前記切替判定部が、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツの前記奇数フレームデータを記憶する前記ピア、当該コンテンツの前記偶数フレームデータを記憶する前記ピア、当該コンテンツの前記ＸＯＲデータを記憶する前記ピアをそれぞれ選択し、前記選択したピアのそれぞれを当該コンテンツの前記奇数フレームデータを配信する第１のピアと、当該コンテンツの前記偶数フレームデータを配信する第２のピアと、当該コンテンツの前記ＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算する管理部と、前記切替判定部が、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替える切替部と、を備え、前記キャッシュサーバは、前記コンテンツのデータが記憶される第２のキャッシュ部と、前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツの前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから取得し、前記取得した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第２のキャッシュ部に復元した当該コンテンツのデータを記憶させる第２の統合部と、
前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する第２の配信部と、を備える、ことを特徴とする。

また、本発明に係るコンテンツ配信方法は、複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムのコンテンツ配信方法であって、前記ピアは、前記コンテンツの視聴要求を前記アプリケーションサーバに送信し、前記アプリケーションサーバは、前記コンテンツのデータが所定サイズであるフレームに分割されて時系列順に連続番号が付されたフレーム群とされ、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータとの３種類のデータの内、何れか１種類が記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルを備え、前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定し、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツの前記奇数フレームデータを記憶する前記ピア、当該コンテンツの前記偶数フレームデータを記憶する前記ピア、当該コンテンツの前記ＸＯＲデータを記憶する前記ピアをそれぞれ選択し、前記選択したピアのそれぞれを当該コンテンツの前記奇数フレームデータを配信する第１のピアと、当該コンテンツの前記偶数フレームデータを配信する第２のピアと、当該コンテンツの前記ＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算し、前記アプリケーションサーバにより決定された前記第1のピア、第２のピア、第３のピアのそれぞれは、前記奇数フレームデータ、前記偶数フレームデータ、前記ＸＯＲデータの内、何れか１種類が記憶される第１のキャッシュ部を備え、前記第１のキャッシュ部に記憶される、何れか１種類の前記コンテンツのデータを前記アプリケーションサーバから配信指示を受信すると、前記視聴要求を送信した前記ピアに配信し、前記視聴要求を送信した前記ピアは、前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記受信した３種類のデータの内、何れか１種類を前記第１のキャッシュ部に記憶し、前記アプリケーションサーバは、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替え、前記キャッシュサーバは、前記コンテンツのデータが記憶される第２のキャッシュ部を備え、前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツの前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから取得し、前記取得した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第２のキャッシュ部に復元した当該コンテンツのデータを記憶し、前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する、ことを特徴とする。

このようにすることで、本発明に係るコンテンツ配信システム及びコンテンツ配信方法は、ユーザが管理する装置であるピアがコンテンツの一部のデータ(コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータのいずれか)を保持する。よって、本発明に係るコンテンツ配信システム及びコンテンツ配信方法によれば、コンテンツの２次配布等といったコンテンツの不正利用を難しくすることができる。

本発明に係るコンテンツ配信システム、コンテンツ配信方法、ならびにコンテンツ配信システムに用いられるピア、アプリケーションサーバ及びキャッシュサーバによれば、事前にコンテンツを集約して配備する必要がなく、また、コンテンツ数や容量が増加したり、突発的に視聴数が増加した場合でも滞ることなくコンテンツを配信することができる。

本実施形態に係るコンテンツ配信システムの構成図である。本実施形態に係るコンテンツ配信システムを構成するピアの構成図である。本実施形態に係るコンテンツ配信システムを構成するピアに格納されるキャッシュ管理テーブルの構成図である。本実施形態に係るコンテンツ配信システムを構成するピアが備える分割部の処理を説明するための図である。本実施形態に係るコンテンツ配信システムを構成するキャッシュサーバの構成図である。本実施形態に係るコンテンツ配信システムを構成するアプリケーションサーバ(ＡＳ)の構成図である。本実施形態に係るコンテンツ配信システムを構成するアプリケーションサーバ(ＡＳ)に格納される配信管理テーブルの構成図である。本実施形態に係るコンテンツ配信システムのコンテンツ公開処理を説明するための図である。本実施形態に係るコンテンツ配信システムのコンテンツ公開処理後の配信管理テーブル及びキャッシュ管理テーブルを説明するための図である。本実施形態に係るコンテンツ配信システムのコンテンツ視聴要求処理（１）を説明するための図である。本実施形態に係るコンテンツ配信システムのコンテンツ視聴要求処理（１）後の配信管理テーブル及びキャッシュ管理テーブルを説明するための図である。本実施形態に係るコンテンツ配信システムのコンテンツ視聴要求処理（２）を説明するための図である。本実施形態に係るコンテンツ配信システムのコンテンツ視聴要求処理（２）後の配信管理テーブル及びキャッシュ管理テーブルを説明するための図である。本実施形態に係るコンテンツ配信システムのコンテンツ視聴要求処理（３）を説明するための図である。本実施形態に係るコンテンツ配信システムのコンテンツ視聴要求処理（３）後の配信管理テーブル及びキャッシュ管理テーブルを説明するための図である。本実施形態に係るコンテンツ配信システムのキャッシュ削除処理を説明するための図である。本実施形態に係るコンテンツ配信システムのキャッシュ削除処理前後の配信管理テーブル及びキャッシュ管理テーブルを説明するための図である。本実施形態に係るコンテンツ配信システムのキャッシュサーバ併用処理（１）を説明するための図である。本実施形態に係るコンテンツ配信システムのキャッシュサーバ併用処理（２）を説明するための図である。

以下、図面を参照して、本発明の実施の形態につき詳細に説明する。
なお、各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。なお、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。

[文言の定義]
本明細書で用いられる文言を以下のように定義する。
「ユーザ」とは、コンテンツを視聴する者をいう。例えば、ピア１０がユーザ端末(例えば、ＰＣ(Personal Computer))である場合には、ユーザはユーザ端末の操作者であり、また、ピア１０がＨＧＷ(Home Gateway)である場合には、ユーザはＨＧＷの下流のホームネットワークに接続される図示しないテレビ、ＰＣ等の操作者である。

「コンテンツ」とは、リアルタイム性を有するコンテンツをいう。例えば、動画、音楽等が該当する。また、コンテンツの提供者が保有するコンテンツのことを、配信されたコンテンツと区別して「オリジナルコンテンツ」又は「オリジナル」と呼ぶ場合がある。
「コンテンツの公開」とは、ネットワーク９０上でコンテンツのストリーミング配信を可能にするためにＡＳ５０にコンテンツに関する情報を登録することをいう。

「キャッシュ」とは、コンテンツを視聴するために記憶部１２，３２（後記参照）に一時的に記憶すること、又は記憶されたコンテンツのデータそのものをいう。

≪コンテンツ配信システムの構成≫
＜概要＞
以下、図１を参照して、本実施形態に係るコンテンツ配信システムの構成について説明する。なお、図１は、本実施形態に係るコンテンツ配信システムの構成図である。

コンテンツ配信システム１００は、ピア１０Ａ，・・・,１０Ｘ，１０Ｙ，１０Ｚ（以下、まとめて「ピア１０」と呼ぶ場合がある）、キャッシュサーバ３０ａ，・・・，３０ｎ（以下、まとめて「キャッシュサーバ３０」と呼ぶ場合がある）、及びＡＳ５０がネットワーク９０を介して通信可能に接続されている。

コンテンツ配信システム１００は、原則として、ハイブリッド型Ｐ２Ｐ配信システムとして動作する。すなわち、ＡＳ５０は、ピア１０が何れのコンテンツをキャッシュしているかという情報を集約して持ち、ピア１０からの視聴要求に応じて、ピア１０のマッチングを行い、ピア１０同士でコンテンツの配信を行うように管理する。ピア１０は、コンテンツを再生すると共にキャッシュとして蓄え、新たな視聴要求に応じてコンテンツを配信する配信ノードとなる。ハイブリッド型Ｐ２Ｐ配信システムは、親から子、子から孫、孫から曾孫へとコンテンツを配信することで配信に要する負荷を分散し、突発的な視聴数増加に対応する。

このように、コンテンツ配信システム１００が、ハイブリッド型Ｐ２Ｐ配信システムとして動作すると、あるコンテンツを複数のピア１０が視聴する場合に、視聴しているピア１０の全てに同一のコンテンツがキャッシュされるので、時間の変化と共に複数のピア１０が同一のコンテンツをキャッシュするときがある。コンテンツ配信システム１００では、同一のコンテンツをキャッシュするピア１０の数に応じて配信方法を変える。

具体的には、同一のコンテンツを１つのピア１０がキャッシュしている場合には、その１つのピア１０からコンテンツを配信し(以下、「単独配信」と呼ぶ場合がある)、同一のコンテンツを２つのピア１０がキャッシュしている場合には、その２つのピア１０からコンテンツを同時配信し(以下、「２重同時配信」と呼ぶ場合がある)、同一のコンテンツを３つ以上のピア１０がキャッシュしている場合には、その３つ以上のピア１０の中から選択した３つのピア１０からコンテンツを同時配信する(以下、「３重同時配信」と呼ぶ場合がある)。なお、３重同時配信では、配信するデータとして、コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータを用いる。詳細は後記する。

また、コンテンツ配信システム１００が、ハイブリッド型Ｐ２Ｐ配信システムとして動作すると、コンテンツを視聴する場合に、配信先のピア１０の下り帯域に加えて、配信元のピア１０の上り帯域を使用して配信するので、コンテンツの視聴数が増えると配信元のピア１０の上り帯域を圧迫する可能性がある。

これに対して、キャッシュサーバ３０からコンテンツを配信する場合は、配信先のピア１０の下り帯域のみ使用し、配信元のピア１０の上り帯域は使用しない。また、キャッシュサーバ３０は、ピア１０に比べ電源がＯＦＦ等される可能性が格段に低いと想定されるため、ネットワークの信頼性が十分に確保される場合、コンテンツのデータを多重に配信する必要がないため、多重化によるトラヒックの増加も無い。

コンテンツ配信システム１００では、キャッシュサーバ３０からの配信の帯域使用効率の高さを鑑み、視聴数が少ない間はピア１０相互間でコンテンツの配信を行い、視聴数が増加してきたら（上り帯域を圧迫してきたら）、コンテンツをキャッシュサーバ３０に配備し、新しい視聴要求に対してキャッシュサーバ３０からコンテンツの配信を行う。また、視聴数が減った段階で、キャッシュサーバ３０からの配信を停止し、キャッシュサーバ３０から該当キャッシュを削除し、ピア１０相互間による配信に戻す。

＜ピア＞
ピア１０は、例えば、ＰＣ(Personal Computer)等のユーザ端末、ＨＧＷ(Home Gateway)等である。また、ピア１０には、ピアを一意に識別する識別情報であるピアＩＤが付与されている。図１では、ピアＩＤが「Ａ」のピアをピア１０Ａと、ピアＩＤが「Ｘ」のピアをピア１０Ｘと、ピアＩＤが「Ｙ」のピアをピア１０Ｙと、ピアＩＤが「Ｚ」のピアをピア１０Ｚと表記している。

図２を参照して、ピア１０の構成を説明する。ピア１０は、通信部１１、記憶部１２、及び制御部１５を備えて構成される。通信部１１は、ピア１０をネットワーク９０に接続する通信インタフェースである。

記憶部１２は、ＨＤＤ(Hard Disk Drive)等で構成される。記憶部１２には、コンテンツがキャッシュ(記憶)されるキャッシュ部１３が領域として確保され、キャッシュ部１３に格納されるコンテンツのコンテンツＩＤが格納されるキャッシュ管理テーブル１４が記憶されている。キャッシュ管理テーブル１４の構成を図３に示す。コンテンツＩＤ１４１は、ネットワーク９０内でコンテンツを一意に識別する識別情報である。コンテンツＩＤ１４１は、例えば、数桁の数字で構成される。コンテンツＩＤ１４１は、ピア１０が、コンテンツの公開要求を行った場合に、ＡＳ５０が当該コンテンツにコンテンツＩＤ１４１を割り振る。以下、コンテンツＩＤ１４１が「α」のコンテンツを、コンテンツαと呼ぶときがある。

図２に戻り、制御部１５は、ＣＰＵ(Central Processing Unit)、及びこれらの周辺回路等（いずれも図示せず）から構成される。また、制御部１５は、通信制御部１６、登録要求部１７、視聴要求部１８、分割部１９、配信部２０、統合部２１、及び削除部２２を含めて構成される。そして、この制御部１５は、記憶部１２に格納される図示しないプログラムをメモリ(不図示)に展開し、実行することにより実現される。
通信制御部１６は、通信部１１を介してキャッシュサーバ３０及びＡＳ５０との間でデータの送受信を行う。

登録要求部１７は、ユーザによりコンテンツが公開される場合に、ＡＳ５０に対して、ピア１０が有するオリジナルコンテンツをネットワーク９０上で公開することを要求する公開要求を送信する。登録要求部１７は、また、キャッシュ管理テーブル１４のコンテンツＩＤ１４１に公開したコンテンツＩＤを登録する。なお、コンテンツＩＤは、ＡＳ５０に対して送信した公開要求に対する応答として、公開要求を行ったコンテンツのコンテンツＩＤを受信するようにしてもよい。

視聴要求部１８は、ユーザによりコンテンツが視聴される場合に、ＡＳ５０に対して、ネットワーク９０上に公開されているコンテンツの配信を要求する視聴要求を送信する。ここで、公開要求を受けたコンテンツは、例えば、図示しないＷｅｂサーバを用いてネットワーク９０上で公開されている。

視聴要求部１８は、また、ＡＳ５０に対して送信した視聴要求に対する応答として、視聴要求を行ったコンテンツの配信元となるピアのピアＩＤと、ピアＩＤに対応したピアから配信されるコンテンツのデータの種類（以下、「データ種類」と呼ぶ場合がある）を受信する。コンテンツのデータ種類には、ＦＵＬＬデータ、奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータの４種類がある。ＦＵＬＬデータは、コンテンツ全体のデータである。なお、その他のデータ種類の詳細については、分割部１９で説明する。

ここで、視聴要求部１８が受信する配信元となるピアのピアＩＤの数は、配信方法により異なる。具体的には、視聴要求部１８は、単独配信の場合は１つのピアＩＤを受信し、２重同時配信の場合は２つのＩＤを受信し、３重同時配信の場合は３つのＩＤを受信する。

視聴要求部１８は、また、コンテンツの配信元となるピアのピアＩＤを受信した場合に、受信したピアＩＤを参照し、コンテンツの配信元となるピアに対して、コンテンツの配信を要求する配信要求を送信する。ここで、視聴要求部１８が配信要求を送信するピア１０の数は、視聴要求部１８が受信した配信元となるピアのピアＩＤの数に対応する。配信要求には、配信先となる自己のピアＩＤ、及び視聴要求に対する応答としてＡＳ５０から受信したデータ種類(ＦＵＬＬデータ、奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータの４種類)を設定する。

図４を参照して、本実施形態に係る分割部１９の処理について説明する。
分割部１９は、自身以外のピア１０から配信要求を受信した場合に、配信要求に設定されるデータ種類を参照し、データ種類に応じて異なる処理を行う。なお、キャッシュサーバ３０から後記する取得要求を受信した場合も同様である。
なお、データ種類が「ＦＵＬＬデータ」のときには、分割部１９は、分割処理を行わない。

まず、データ種類が「奇数フレームデータ」、「偶数フレームデータ」のときには、分割部１９は、キャッシュ部１３にキャッシュされるコンテンツのＦＵＬＬデータを所定サイズのフレーム７０ａ，７０ｂ，７０ｃ，７０ｄ，・・に分割し、時系列順に連続番号(例えば、昇順)を付したフレーム群７０とする。次に、分割部１９は、フレーム群７０の内、奇数番号のフレーム群である奇数フレームデータ７１と、偶数番号のフレーム群である偶数フレームデータ７２とに分割する。

次に、データ種類が「ＸＯＲデータ」のときには、分割部１９は、ＦＵＬＬデータの分割処理をした後に、奇数フレームデータ７１の内、時系列順に最初のフレーム７０ａと、偶数フレームデータ７２の内、時系列順に最初のフレーム７０ｂの排他的論理和であるＸＯＲフレーム８０ａｂを算出する。次に、分割部１９は、奇数フレームデータ７１の内、時系列順に２番目のフレーム７０ｃと、偶数フレームデータ７２の内、時系列順に２番目のフレーム７０ｄの排他的論理和(ＸＯＲ:exclusive or)であるＸＯＲフレーム８０ｃｄを算出する。以降、このように、分割部１９は、全てのフレームについて処理を行い、奇数フレームデータ７１と偶数フレームデータ７２との排他的論理和のフレーム群であるＸＯＲデータ８０を算出する。

配信部２０（第１の配信部）は、分割部１９がデータ種類に従った上記処理を行った後に、データ種類に応じて異なる処理を行う。
まず、データ種類が「ＦＵＬＬデータ」のときには、配信部２０は、コンテンツの配信先となるピアに対して、キャッシュ部１３にキャッシュされるコンテンツのＦＵＬＬデータを配信する。

データ種類が「奇数フレームデータ」のときには、配信部２０は、コンテンツの配信先となるピアに対して、キャッシュ部１３にキャッシュされるコンテンツを分割部１９が分割した内の奇数フレームデータ７１（図４参照）を配信する。

データ種類が「偶数フレームデータ」のときには、配信部２０は、コンテンツの配信先となるピアに対して、キャッシュ部１３にキャッシュされるコンテンツを分割部１９が分割した内の偶数フレームデータ７２（図４参照）を配信する。

そして、データ種類が「ＸＯＲデータ」のときには、配信部２０は、コンテンツの配信先となるピアに対して、キャッシュ部１３にキャッシュされるコンテンツを分割部１９が処理したＸＯＲデータ８０（図４参照）を配信する。

統合部２１（第１の統合部）は、配信方法により異なる処理を行う。
まず、コンテンツの配信方法が「単独配信」のときには、統合部２１は、１つの配信元のピア１０から、コンテンツのＦＵＬＬデータを受信する。そして、統合部２１は、受信したコンテンツのＦＵＬＬデータを再生すると共に、キャッシュ部１３にＦＵＬＬデータをキャッシュし、キャッシュ管理テーブル１４のコンテンツＩＤ１４１に受信したコンテンツのコンテンツＩＤを登録する。

また、コンテンツの配信方法が「２重同時配信」のときには、統合部２１は、異なる２つの配信元のピア１０から、コンテンツのＦＵＬＬデータを受信する。そして、統合部２１は、受信した２つのＦＵＬＬデータの内、いずれかを取捨選択し、取捨選択した一方のＦＵＬＬデータを再生すると共に、キャッシュ部１３にＦＵＬＬデータをキャッシュし、キャッシュ管理テーブル１４のコンテンツＩＤ１４１に受信したコンテンツのコンテンツＩＤを登録する。統合部２１は、異なる２つの配信元のピア１０の内、どちらかからの配信が滞った場合には、正常に配信されたＦＵＬＬデータを取捨選択する。

そして、コンテンツの配信方法が「３重同時配信」のときには、統合部２１は、異なる３つの配信元のピア１０から、異なるデータ種類の奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータを受信する。そして、統合部２１は、奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータの内、いずれか２種類を取捨選択し、取捨選択した２種類のデータをＦＵＬＬデータに統合(復元)して再生すると共に、キャッシュ部１３に統合(復元)したＦＵＬＬデータをキャッシュし、キャッシュ管理テーブル１４のコンテンツＩＤ１４１に受信したコンテンツのコンテンツＩＤを登録する。

具体的に、統合部２１は、奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータのすべてを受信した場合には、奇数フレームデータ、及び偶数フレームデータを取捨選択し、奇数フレームデータ、及び偶数フレームデータをマージすることでＦＵＬＬデータに統合(復元)する。一方、奇数フレームデータ、及び偶数フレームデータのどちらか一方の配信が滞った場合には、正常に配信された奇数フレームデータ又は偶数フレームデータと、ＸＯＲデータとを乗じることで配信が滞った奇数フレームデータ又は偶数フレームデータを算出する。そして、統合部２１は、算出した奇数フレームデータ又は偶数フレームデータと、正常に配信された奇数フレームデータ又は偶数フレームデータをマージすることでＦＵＬＬデータに統合(復元)する。

削除部２２は、ＡＳ５０から、キャッシュ部１３にキャッシュされているコンテンツの内、削除するコンテンツのコンテンツＩＤを指定した削除指示を受信する。削除部２２は、削除指示を受信した場合に、該当するコンテンツのデータをキャッシュ部１３から削除すると共に、キャッシュ管理テーブル１４のコンテンツＩＤ１４１から該当するコンテンツＩＤを削除する。そして、削除部２２は、ＡＳ５０に対して、削除指示を受けたコンテンツのデータの削除が完了したことを示す削除完了通知を送信する。

以上より、本実施形態に係るピア１０は、コンテンツの視聴に際して、コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータの３種類のデータを３つのピアから受信する(３重同時配信)。よって、本実施形態に係るピア１０によれば、コンテンツのデータを配信中のピア１０が突然に電源ＯＦＦされることにより、当該ピア１０からの配信が途絶えても、３ピアの内２ピアからの配信が継続する限り、コンテンツのデータを復元することができるので、ユーザはコンテンツを滞ることなく視聴することができる。

また、本実施形態に係るピア１０は、３重同時配信のデータとして、オリジナルコンテンツのデータサイズと比較して０．５倍のデータサイズである奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータを用いる。よって、本実施形態に係るピア１０によれば、１対１でコンテンツを配信する非多重化配信に対し、およそ１．５倍のトラヒック増で約２倍の信頼性を得ることができる。
以上で、ピア１０の説明を終了する。

＜キャッシュサーバ＞
キャッシュサーバ３０は、３つのピア１０から３重同時配信でコンテンツのデータを取得し、配信要求があったピア１０に対して単独配信でコンテンツのデータを配信する。その他の、コンテンツのデータを収集方法、及び配信方法については後記する変形例で説明する。

図５を参照して、本実施形態に係るキャッシュサーバ３０について説明する。キャッシュサーバ３０は、通信部３１、記憶部３２、及び制御部３５を備えて構成される。
通信部３１は、キャッシュサーバ３０をネットワーク９０に接続する通信インタフェースである。

記憶部３２は、ＨＤＤ(Hard Disk Drive)等で構成される。記憶部３２には、コンテンツがキャッシュ(記憶)されるキャッシュ部３３が領域として確保され、キャッシュ部３３に格納されるコンテンツのコンテンツＩＤが格納されるキャッシュ管理テーブル３４が記憶されている。ここで、キャッシュ管理テーブル３４の構成は、ピア１０に記憶されるキャッシュ管理テーブル１４の構成と同様なので、説明を省略する。

制御部３５は、ＣＰＵ(Central Processing Unit)、及びこれらの周辺回路等（いずれも図示せず）から構成される。制御部３５は、通信制御部３６、取得部３７、統合部３８、配信部３９、及び削除部４０を含んで構成される。そして、この制御部３５は、記憶部３２に格納される図示しないプログラムをメモリ(不図示)に展開し、実行することにより実現される。
通信制御部３６は、通信部３１を介してピア１０及びＡＳ５０との間でデータの送受信を行う。

取得部３７は、ＡＳ５０の決定によりキャッシュサーバ３０からコンテンツを配信することになった場合に、ＡＳ５０から、当該コンテンツのコンテンツＩＤと、当該コンテンツがキャッシュされる取得先となるピア１０のピアＩＤと、ピアＩＤに対応したピアから配信されるコンテンツのデータ種類とが設定された収集要求を受信する。取得部３７は、コンテンツのデータを３重同時配信で取得するので、収集要求には３つのピアＩＤと、３つのデータ種類(奇数フレームデータ、偶数フレームデータ、又はＸＯＲデータ)が設定されている。

取得部３７は、また、ＡＳ５０から収集要求を受信した場合に、収集要求に設定されたピアＩＤを参照し、コンテンツがキャッシュされる取得先のピア１０に対して、コンテンツの取得を要求する取得要求を送信する。ここで、取得部３７が取得要求を送信するピア１０の数は、収集要求に設定されているピアＩＤの数に対応して３つである。取得要求には、取得元となる自己のピアＩＤ、及びＡＳ５０から受信した３種類のデータ種類(奇数フレームデータ、偶数フレームデータ、又はＸＯＲデータ)を設定する。

統合部３８（第２の統合部）は、取得要求に対する応答として異なる３つの取得先のピア１０から、異なるデータ種類の奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータを受信する。そして、統合部３８は、奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータの内、いずれか２種類を取捨選択し、取捨選択した２種類のデータをＦＵＬＬデータに統合(復元)すると共に、キャッシュ部３３に統合(復元)したＦＵＬＬデータをキャッシュし、キャッシュ管理テーブル３４のコンテンツＩＤに受信したコンテンツのコンテンツＩＤを登録する。なお、受信データの取捨選択、及びＦＵＬＬデータの統合(復元)については、ピア１０が備える統合部２１の処理と同様なので説明を省略する。

配信部３９（第２の配信部）は、コンテンツの配信先となるピア１０から配信要求を受信した場合に、配信先となるピア１０に対して、統合部３８で統合されキャッシュ部３３にキャッシュされたコンテンツのＦＵＬＬデータを配信する(単独配信)。

削除部４０は、ＡＳ５０から、キャッシュ部３３にキャッシュされているコンテンツの内、削除するコンテンツのコンテンツＩＤを指定した削除指示を受信する。削除部４０は、削除指示を受信した場合に、該当するコンテンツのデータをキャッシュ部３３から削除すると共に、キャッシュ管理テーブル３４のコンテンツＩＤから該当するコンテンツＩＤを削除する。そして、削除部４０は、ＡＳ５０に対して、削除指示を受けたコンテンツのデータの削除が完了したことを示す削除完了通知を送信する。

以上より、本実施形態にキャッシュサーバ３０は、ＡＳ５０から収集要求を受信した場合に、収集要求に設定されている３つの取得先(ピア)に対してコンテンツの取得要求を送信し、その応答として、３つの取得先(ピア)から、異なるデータ種類の奇数フレームデータ、偶数フレームデータ、及びＸＯＲデータを受信し、受信した３種類のデータからコンテンツのＦＵＬＬデータを復元してキャッシュする。そして、ピア１０から視聴要求があった場合に、キャッシュしたコンテンツのＦＵＬＬデータを、当該コンテンツをキャッシュするピア１０に代わって視聴要求があったピア１０に配信する。よって、本実施形態に係るキャッシュサーバ３０によれば、各ピア相互間でコンテンツの配信を行うことにより発生する上り帯域の圧迫を軽減することができる。
以上で、キャッシュサーバ３０の説明を終了する。

＜ＡＳ(アプリケーションサーバ)＞
図６を参照して、本実施形態に係るＡＳ５０について説明する。ＡＳ５０は、通信部５１、記憶部５２、及び制御部５５を備えて構成される。通信部５１は、ＡＳ５０をネットワーク９０に接続する通信インタフェースである。

記憶部５２は、ＨＤＤ(Hard Disk Drive)等で構成される。記憶部５２には、コンテンツ毎に当該コンテンツがキャッシュされているピア１０の情報が配信管理テーブル５３として記憶されている。配信管理テーブル５３の詳細を図７に示す。

図７を参照して、配信管理テーブル５３の構成を説明する。
コンテンツＩＤ５３１は、ネットワーク９０内でコンテンツを一意に識別する識別情報である。コンテンツＩＤ５３１は、例えば、数桁の数字で構成される。
ピアＩＤ５３２は、ネットワーク９０内でピア１０を一意に識別する識別情報である。ピアＩＤ５３２は、例えば、ＩＰアドレス、電話番号、会員番号等が該当する。

キャッシュ保持期限５３３は、コンテンツがピア１０にキャッシュされる時間である。なお、オリジナルコンテンツを保持するピア１０には、キャッシュ保持期限５３３を設定しない（図７では「オリジナル」と表記）。
リソース提供者５３４は、コンテンツの配信元となるピア１０、及び配信元となるピア１０から配信されたデータのデータ種類である。図７では、データ種類は、()内に記載され、コンテンツのＦＵＬＬデータが配信された場合に「ＦＵＬＬ」と、奇数フレームデータが配信された場合に「奇数」と、偶数フレームデータが配信された場合に「偶数」と、ＸＯＲデータが配信された場合に「ＸＯＲ」と省略して記載している。また、オリジナルコンテンツを保持するピア１０には、配信元となるピア１０は存在しないので、データ種類のみ「オリジナル」と表記されている。例えば、ピアＩＤ５３２が「Ｘ」のピア１０Ｘは、ピアＩＤ５３２が「Ａ」のピア１０Ａからデータ種類が「ＦＵＬＬデータ」のコンテンツのデータが配信されていることを示している。

配信数５３５は、ピアＩＤ５３２に対応するピア１０が、該当コンテンツを配信している数である。
配信上限数５３６は、ピアＩＤ５３２に対応するピア１０が、該当コンテンツを配信可能な上限数である。配信上限数５３６には、例えば、ピア１０の処理能力に応じた最大同時配信数が設定される。

なお、配信管理テーブル５３のコンテンツＩＤ５３１に属するレコードの数は、当該コンテンツを視聴した(すなわち、当該コンテンツをキャッシュしている)ピア１０の数に対応する。

図６に戻り、制御部５５は、ＣＰＵ(Central Processing Unit)、及びこれらの周辺回路等（いずれも図示せず）から構成される。また、制御部５５は、通信制御部５６、登録部５７、管理部５８、切替判定部５９、切替部６０、及び削除指示部６１を含んで構成される。そして、この制御部５５は、記憶部５２に格納される図示しないプログラムをメモリ(不図示)に展開し、実行することにより実現される。
通信制御部５６は、通信部５１を介してピア１０及びキャッシュサーバ３０との間でデータの送受信を行う。

登録部５７は、ユーザによりコンテンツが公開される場合に、ピア１０から公開要求を受信する。また、登録部５７は、配信管理テーブル５３に公開するコンテンツの内容を登録する。なお、登録部５７は、公開要求を受けた当該コンテンツにコンテンツＩＤを割り振り、公開要求をしたピア１０に割り振ったコンテンツＩＤを送信するようにしてもよい。

具体的には、登録部５７は、公開要求に設定されていたコンテンツＩＤを、ピアＩＤ５３２に公開要求をしたピア１０のピアＩＤを、キャッシュ保持期限５３３及びリソース提供者５３４にオリジナルコンテンツである旨の情報を、配信数５３５に「０」を、配信上限数５３６に所定の値を書き込む。なお、登録部５７が、コンテンツＩＤを割り振る場合には、コンテンツＩＤ５３１に割り振ったコンテンツＩＤを書き込んでもよい。

管理部５８は、ユーザによりコンテンツが視聴される場合に、ピア１０から視聴要求を受信する。次に、管理部５８は、配信管理テーブル５３の内、視聴要求があったコンテンツの項目を参照することで配信可能なピア１０を抽出し、配信可能なピア１０の数に応じた処理を行う。配信可能であるか否かは、配信数５３５が配信上限数５３６よりも小さければそのピア１０は配信可能と判定し、配信数５３５が配信上限数５３６よりも小さくなければそのピア１０は配信不能と判定する。

次に、コンテンツを配信可能なピア１０の数が「１」の場合、「２」の場合、「３以上」の場合について説明する。

（コンテンツを配信可能なピア１０の数が「１」の場合）
管理部５８は、視聴要求をしたピア１０に対して、単独配信を行うことを決定すると共に、コンテンツのデータの配信の管理を行う。
具体的には、管理部５８は、配信管理テーブル５３の内、視聴要求があったコンテンツの項目を参照し、配信可能なピア１０を１つ抽出し、配信元となる１つのピア１０のピアＩＤ５３２を取得する。そして、管理部５８は、視聴要求をしたピア１０に対して、視聴要求に対する応答として、配信元となるピア１０のピアＩＤ５３２、及びデータ種類「ＦＵＬＬデータ」を設定した視聴要求応答を送信する。

また、管理部５８は、配信管理テーブル５３の内、視聴要求を受けたコンテンツに視聴要求があったピア１０の新たなレコードを作成し、ピアＩＤ５３２に視聴要求があったピア１０のピアＩＤを、キャッシュ保持期限５３３にキャッシュを保持する時間を、リソース提供者５３４に抽出した配信元となるピア１０のピアＩＤ及びデータ種類「ＦＵＬＬ」を、配信数５３５に「０」を、配信上限数５３６に所定の値を書き込む。また、管理部５８は、抽出した配信元となるピア１０に対応するレコードの配信数５３５に「１」を増加する。

（コンテンツを配信可能なピア１０の数が「２」の場合）
管理部５８は、視聴要求をしたピア１０に対して、２重同時配信を行うことを決定すると共に、コンテンツのデータの配信の管理を行う。
具体的には、管理部５８は、配信管理テーブル５３の内、視聴要求があったコンテンツの項目を参照し、配信可能なピア１０を２つ抽出し、配信元となる２つのピア１０のピアＩＤ５３２を取得する。そして、管理部５８は、視聴要求をしたピア１０に対して、視聴要求に対する応答として、配信元となる２つのピア１０のピアＩＤ５３２、及びデータ種類「ＦＵＬＬデータ」を設定した視聴要求応答を送信する。

また、管理部５８は、配信管理テーブル５３の内、視聴要求を受けたコンテンツに視聴要求があったピア１０の新たなレコードを作成し、ピアＩＤ５３２に視聴要求があったピア１０のピアＩＤを、キャッシュ保持期限５３３にキャッシュを保持する時間を、リソース提供者５３４に抽出した配信元となる２つのピア１０のピアＩＤ及びデータ種類「ＦＵＬＬ」を、配信数５３５に「０」を、配信上限数５３６に所定の値を書き込む。また、管理部５８は、抽出した配信元となる２つのピア１０に対応するレコードの配信数５３５に「１」を増加する。

（コンテンツを配信可能なピア１０の数が「３以上」の場合）
管理部５８は、視聴要求をしたピア１０に対して、３重同時配信を行うことを決定すると共に、コンテンツのデータの配信の管理を行う。
具体的には、管理部５８は、配信管理テーブル５３の内、視聴要求があったコンテンツの項目を参照し、配信可能なピア１０を３つ抽出し、配信元となる３つのピア１０のピアＩＤ５３２を取得する。そして、管理部５８は、視聴要求をしたピア１０に対して、視聴要求に対する応答として、配信元となる３つのピア１０のピアＩＤ５３２、及びデータ種類「奇数フレームデータ」、「偶数フレームデータ」、又は「ＸＯＲデータ」を設定した視聴要求応答を送信する。

また、管理部５８は、配信管理テーブル５３の内、視聴要求を受けたコンテンツに視聴要求があったピア１０の新たなレコードを作成し、ピアＩＤ５３２に視聴要求があったピア１０のピアＩＤを、キャッシュ保持期限５３３にキャッシュを保持する時間を、リソース提供者５３４に抽出した配信元となる３つのピア１０のピアＩＤ及びデータ種類「奇数」、「偶数」、又は「ＸＯＲ」を、配信数５３５に「０」を、配信上限数５３６に所定の値を書き込む。また、管理部５８は、抽出した配信元となる３つのピア１０に対応するレコードの配信数５３５に「１」を増加する。

切替判定部５９は、ピア１０から配信要求を受信した場合に、配信管理テーブル５３の内、配信要求があったコンテンツの配信数５３５をカウントし、配信数５３５が多い場合にキャッシュサーバ３０に当該コンテンツを格納し、キャッシュサーバ３０からピア１０へ当該コンテンツの単独配信を行うように決定する。ここで、配信数５３５が多い場合とは、コンテンツ配信システム１００の設計者等が定めた所定の閾値を配信数５３５が超えた場合、ネットワーク９０の帯域を管理している図示しないネットワーク機能(ネットワーク管理装置等)から、上り帯域が圧迫している旨の通知を受けた(信号を受信した)場合等が想定される。

また、切替判定部５９は、キャッシュサーバ３０から配信を行っているコンテンツについてピア１０から配信要求を受信した場合に、配信管理テーブル５３の内、配信要求があったコンテンツのキャッシュサーバ３０の配信数５３５をカウントし、配信数５３５が少ない場合にキャッシュサーバ３０からピア１０への当該コンテンツの単独配信を終了することを決定する。ここで、配信数５３５が少ない場合とは、コンテンツ配信システム１００の設計者等が定めた所定の閾値を配信数５３５が下回った場合等が想定される。

切替部６０は、切替判定部５９がキャッシュサーバ３０からピア１０へのコンテンツの単独配信を行うことを決定した場合、当該コンテンツの配信を行うキャッシュサーバ３０を選択する。ここで、キャッシュサーバ３０の選択は、キャッシュサーバ３０と当該コンテンツの配信先のピア１０とのネットワーク距離、キャッシュサーバ３０のリソース及び帯域の状況等を考慮し、適切なサーバをマッチングするとよい。なお、当該コンテンツが、既にキャッシュサーバ３０にキャッシュされている場合は、そのキャッシュサーバ３０を優先的に選択する。

また、切替部６０は、配信管理テーブル５３の内、キャッシュサーバ３０からの配信を決定したコンテンツの項目を参照し、配信可能なピア１０を３つ抽出し、コンテンツの取得先となる３つのピア１０のピアＩＤ５３２を取得する。そして、切替部６０は、選択したキャッシュサーバ３０に対して、コンテンツの取得先となる３つのピア１０のピアＩＤ５３２、及びデータ種類「奇数フレームデータ」、「偶数フレームデータ」、又は「ＸＯＲデータ」が設定された収集要求を送信する。ここで、キャッシュサーバ３０は、コンテンツのデータを３重同時配信で取得するので、収集要求には３つのピアＩＤと、３つのデータ種類(奇数フレームデータ、偶数フレームデータ、又はＸＯＲデータ)が設定されている。

また、切替部６０は、配信管理テーブル５３の内、キャッシュサーバ３０からの配信を決定したコンテンツにキャッシュサーバ３０の新たなレコードを作成し、ピアＩＤ５３２に選択したキャッシュサーバ３０のピアＩＤを、キャッシュ保持期限５３３にキャッシュを保持する時間を、リソース提供者５３４に抽出した配信元となる３つのピア１０のピアＩＤ及びデータ種類「奇数」、「偶数」、又は「ＸＯＲ」を、配信数５３５に「０」を、配信上限数５３６に所定の値を書き込む。また、管理部５８は、抽出した配信元となる３つのピア１０に対応するレコードの配信数５３５に「１」を増加する。

切替部６０は、キャッシュサーバ３０から配信を行っているコンテンツについて視聴要求をしたピア１０に対して、選択したキャッシュサーバ３０から単独配信を行うことを決定すると共に、コンテンツのデータの配信の管理を行う。
具体的には、切替部６０は、配信管理テーブル５３の内、視聴要求があったコンテンツの項目を参照し、選択したキャッシュサーバ３０を抽出し、配信元となる選択したキャッシュサーバ３０のピアＩＤ５３２を取得する。そして、切替部６０は、視聴要求をしたピア１０に対して、視聴要求に対する応答として、配信元となる選択したキャッシュサーバ３０のピアＩＤ５３２、及びデータ種類「ＦＵＬＬデータ」を送信する。

また、切替部６０は、配信管理テーブル５３の内、視聴要求を受けたコンテンツに視聴要求があったピア１０の新たなレコードを作成し、ピアＩＤ５３２に視聴要求があったピア１０のピアＩＤを、キャッシュ保持期限５３３にキャッシュを保持する時間を、リソース提供者５３４に抽出した配信元となる選択したキャッシュサーバ３０のピアＩＤ及びデータ種類「ＦＵＬＬ」を、配信数５３５に「０」を、配信上限数５３６に所定の値を書き込む。また、切替部６０は、配信元となる選択したキャッシュサーバ３０に対応するレコードの配信数５３５に「１」を増加する。

また、切替部６０は、切替判定部５９がキャッシュサーバ３０からピア１０へのコンテンツの単独配信を終了することを決定した場合、新たなピア１０から当該コンテンツの視聴要求がされてもキャッシュサーバ３０からの配信を行わないようにする。そして、切替部６０は、配信管理テーブル５３を参照し、キャッシュサーバ３０の配信数５３５が「０」になった時点で、配信管理テーブル５３からキャッシュサーバ３０の情報を削除する。

削除指示部６１は、配信管理テーブル５３のキャッシュ保持期限５３３が切れており、かつ、配信数５３５が「０」のコンテンツをキャッシュしているピア１０が存在するか否かを定期的に検査する。そして、削除指示部６１は、当該削除対象のコンテンツをキャッシュしているピア１０に対して、削除対象のコンテンツＩＤを設定した削除指示を送信する。

また、削除指示部６１は、ピア１０から、削除指示の応答として削除対象のコンテンツのデータの削除が完了したことを示す削除完了通知を受信する。削除指示部６１は、削除完了通知を受信した場合に、配信管理テーブル５３から、削除対象のコンテンツの項目を削除する。

以上より、本実施形態に係るＡＳ５０は、コンテンツの視聴に際して、コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータの３種類のデータが３つのピアから配信されるように管理する(３重同時配信)。よって、本実施形態に係るＡＳ５０によれば、コンテンツのデータを配信中のピアが突然に電源ＯＦＦされることにより、当該ピアからの配信が途絶えても、３ピアの内２ピアからの配信が継続する限りコンテンツのデータを視聴要求を送信したピアに復元させることができる。

また、本実施形態に係るＡＳ５０は、コンテンツの配信数が所定の閾値を超えない場合に各ピア相互間でコンテンツの配信を行い、配信数が所定の閾値を超える場合にキャッシュサーバを併用してコンテンツの配信を行うように管理する。よって、本実施形態に係るＡＳ５０によれば、各ピア相互間でコンテンツの配信を行うことにより発生する上り帯域の圧迫を軽減することができる。
以上で、ＡＳ５０の説明を終了し、本実施形態に係るコンテンツ配信システム１００の構成の説明を終了する。

≪コンテンツ配信システムの動作≫
＜概要＞
図８ないし図１８を参照して、本実施形態に係るコンテンツ配信システム１００の動作について説明する。
最初に、コンテンツが公開される場合の処理について図８及び図９を参照して説明する。次に、視聴要求に対するコンテンツのデータの単独配信の処理について図１０及び図１１を参照して説明する。次に、視聴要求に対するコンテンツのデータの２重同時配信の処理について図１２及び図１３を参照して説明する。次に、視聴要求に対するコンテンツのデータの３重同時配信の処理について図１４及び図１５を説明する。次に、キャッシュの削除処理について図１６及び図１７を参照して説明する。次に、ピア１０からキャッシュサーバ３０への配信元の切替処理について図１８を参照して説明する。

＜コンテンツが公開される場合の処理＞
図８及び図９を参照して、ピア１０Ａがコンテンツαを公開する場合の処理を説明する。
最初にピア１０Ａの登録要求部１７は、ＡＳ５０に対してコンテンツαの公開要求を送信する（ステップＳ１０１）。次に、ピア１０Ａからの公開要求を受信したＡＳ５０の登録部５７は、配信管理テーブル５３にコンテンツαに関する情報を登録する（ステップＳ１０２）。ステップＳ１０２の処理後の配信管理テーブル５３の状態を図９（ａ）に示す。

次に、ピア１０Ａは、自己が保有するコンテンツαのコンテンツＩＤをキャッシュ管理テーブル１４に登録する（ステップＳ１０３）。ステップＳ１０３の処理後のキャッシュ管理テーブル１４の状態を図９（ｂ）に示す。
以上で、コンテンツが公開される場合の処理の説明を終了する。

＜視聴要求に対するコンテンツのデータの単独配信の処理＞
図１０及び図１１を参照して、ピア１０Ａがコンテンツαを保有している状態で、ピア１０Ｂがコンテンツαの視聴要求をした場合の単独配信の処理を説明する。
ステップＳ１０３に続いて、ピア１０Ｂのユーザによりコンテンツαが視聴される場合、ピア１０Ｂの視聴要求部１８は、ＡＳ５０に対して、コンテンツαの視聴要求を送信する(ステップＳ２０１)。

次に、ピア１０Ｂからの視聴要求を受信したＡＳ５０の管理部５８は、図９（ａ）に示す状態の配信管理テーブル５３を参照し、コンテンツαの配信可能なピア１０Ａを抽出し、配信管理テーブル５３のコンテンツαの項目にピア１０Ｂに関する情報を登録すると共にピア１０Ａのレコードの配信数５３５に「１」を増加する（ステップＳ２０２）。ステップＳ２０２の処理後の配信管理テーブル５３の状態を図１１（ａ）に示す。

次に、ＡＳ５０の管理部５８は、ピア１０Ｂに対して、視聴要求の応答として視聴要求応答を送信する（ステップＳ２０３）。次に、視聴要求応答を受信したピア１０Ｂの視聴要求部１８は、ピア１０Ａに対して、配信要求を送信する（ステップＳ２０４）。次に、配信要求を受信したピア１０Ａの配信部２０は、ピア１０Ｂに対して、配信要求の応答としてコンテンツαのＦＵＬＬデータの配信を開始する（ステップＳ２０５）。

次に、ピア１０Ｂの統合部２１は、コンテンツαのＦＵＬＬデータを再生しながら、キャッシュ部１３にコンテンツαのＦＵＬＬデータをキャッシュする。また、ピア１０Ｂの統合部２１は、キャッシュ管理テーブル１４にコンテンツαに関する情報を登録する（ステップＳ２０６）。ステップＳ２０６の処理後のキャッシュ管理テーブル１４の状態を図１１（ｂ）に示す。
以上で、視聴要求に対するコンテンツのデータの単独配信の処理の説明を終了する。

＜視聴要求に対するコンテンツのデータの２重同時配信の処理＞
図１２及び図１３を参照して、ピア１０Ａ，１０Ｂがコンテンツαを保有又はキャッシュしている状態で、ピア１０Ｃがコンテンツαの視聴要求をした場合の２重同時配信の処理を説明する。
ステップＳ２０６に続いて、ピア１０Ｃのユーザによりコンテンツαが視聴される場合、ピア１０Ｃの視聴要求部１８は、ＡＳ５０に対して、コンテンツαの視聴要求を送信する(ステップＳ３０１)。

次に、ピア１０Ｃからの視聴要求を受信したＡＳ５０の管理部５８は、図１１（ａ）に示す状態の配信管理テーブル５３を参照し、コンテンツαの配信可能なピア１０Ａ，１０Ｂの２つを抽出し、配信管理テーブル５３のコンテンツαの項目にピア１０Ｃに関する情報を登録すると共にピア１０Ａ，１０Ｂのレコードの配信数５３５に「１」を増加する（ステップＳ３０２）。ステップＳ３０２の処理後の配信管理テーブル５３の状態を図１３（ａ）に示す。

次に、ＡＳ５０の管理部５８は、ピア１０Ｃに対して、視聴要求の応答として視聴要求応答を送信する（ステップＳ３０３）。次に、視聴要求応答を受信したピア１０Ｃの視聴要求部１８は、ピア１０Ａ，１０Ｂに対して、配信要求を送信する（ステップＳ３０４）。次に、配信要求を受信したピア１０Ａ，１０Ｂの配信部２０は、ピア１０Ｃに対して、配信要求の応答としてコンテンツαのＦＵＬＬデータの配信を開始する（ステップＳ３０５）。

次に、ピア１０Ｃの統合部２１は、ピア１０Ａ，１０Ｂのどちらか一方から配信されたコンテンツαのＦＵＬＬデータを再生しながら、キャッシュ部１３にコンテンツαのＦＵＬＬデータをキャッシュする。また、ピア１０Ｃの統合部２１は、キャッシュ管理テーブル１４にコンテンツαに関する情報を登録する（ステップＳ３０６）。ステップＳ３０６の処理後のキャッシュ管理テーブル１４の状態を図１３（ｂ）に示す。
以上で、視聴要求に対するコンテンツのデータの２重同時配信の処理の説明を終了する。

＜視聴要求に対するコンテンツのデータの３重同時配信の処理＞
図１４及び図１５を参照して、ピア１０Ａ，１０Ｂ，１０Ｃがコンテンツαを保有又はキャッシュしている状態で、ピア１０Ｄがコンテンツαの視聴要求をした場合の３重同時配信の処理を説明する。
ステップＳ３０６に続いて、ピア１０Ｄのユーザによりコンテンツαが視聴される場合、ピア１０Ｄの視聴要求部１８は、ＡＳ５０に対して、コンテンツαの視聴要求を送信する(ステップＳ４０１)。

次に、ピア１０Ｄからの視聴要求を受信したＡＳ５０の管理部５８は、図１３（ａ）に示す状態の配信管理テーブル５３を参照し、コンテンツαの配信可能なピア１０Ａ，１０Ｂ，１０Ｃの３つを抽出し、配信管理テーブル５３のコンテンツαの項目にピア１０Ｄに関する情報を登録すると共にピア１０Ａ，１０Ｂ，１０Ｃのレコードの配信数５３５に「１」を増加する（ステップＳ４０２）。ステップＳ４０２の処理後の配信管理テーブル５３の状態を図１５（ａ）に示す。なお、ＡＳ５０の管理部５８は、ピア１０Ａから奇数フレームデータを、ピア１０Ｂから偶数フレームデータを、ピア１０ＣからＸＯＲデータを配信するように決定したものとする。

次に、ＡＳ５０の管理部５８は、ピア１０Ｄに対して、視聴要求の応答として視聴要求応答を送信する（ステップＳ４０３）。次に、視聴要求応答を受信したピア１０Ｄの視聴要求部１８は、ピア１０Ａ，１０Ｂ，１０Ｃに対して、配信要求を送信する（ステップＳ４０４）。

次に、配信要求を受信したピア１０Ａの配信部２０は、ピア１０Ｄに対して、配信要求の応答としてコンテンツαの奇数フレームデータの配信を開始する。また、配信要求を受信したピア１０Ｂの配信部２０は、ピア１０Ｄに対して、配信要求の応答としてコンテンツαの偶数フレームデータの配信を開始する。また、配信要求を受信したピア１０Ｃの配信部２０は、ピア１０Ｄに対して、配信要求の応答としてコンテンツαのＸＯＲデータの配信を開始する（ステップＳ４０５）。

次に、ピア１０Ｄの統合部２１は、ピア１０Ａから受信した奇数フレームデータ、ピア１０Ｂから受信した偶数フレームデータ、ピア１０Ｃから受信したＸＯＲデータの中から２種類を取捨選択して、取捨選択した２種類からコンテンツαのＦＵＬＬデータを復元する（ステップＳ４０６）。

また、ピア１０Ｄの統合部２１は、復元したコンテンツαのＦＵＬＬデータを再生しながら、キャッシュ部１３にコンテンツαのＦＵＬＬデータをキャッシュする。また、ピア１０Ｄの統合部２１は、キャッシュ管理テーブル１４にコンテンツαに関する情報を登録する（ステップＳ４０７）。ステップＳ４０７の処理後のキャッシュ管理テーブル１４の状態を図１５（ｂ）に示す。
以上で、視聴要求に対するコンテンツのデータの３重同時配信の処理の説明を終了する。

＜キャッシュの削除処理＞
図１６及び図１７を参照して、ピア１０Ｂがキャッシュするコンテンツαのデータが削除対象の状態であるとして、キャッシュの削除処理を説明する。
ＡＳ５０の削除指示部６１は、定期的に配信管理テーブル５３を参照し、キャッシュ保持期限５３３が切れており、かつ、配信数５３５が「０」のコンテンツをキャッシュしているピア１０が存在するか否かを検査し、ピア１０Ｂがキャッシュするコンテンツαのデータが削除対象であることを検知する（ステップＳ５０１）。

次に、ＡＳ５０の削除指示部６１は、ピア１０Ｂに対してコンテンツαの削除指示を送信する（ステップＳ５０２）。次に、コンテンツαの削除指示を受信したピア１０Ｂの削除部２２は、コンテンツαのデータをキャッシュ部１３から削除すると共に、キャッシュ管理テーブル１４からコンテンツαの項目を削除する（ステップＳ５０３）。ステップＳ５０３の処理前のキャッシュ管理テーブル１４の状態を図１７（ｃ）に、ステップＳ５０３の処理後のキャッシュ管理テーブル１４の状態を図１７（ｄ）示す。

次に、ピア１０Ｂの削除部２２は、ＡＳ５０に対して、コンテンツαのデータの削除が完了したことを示す削除完了通知を送信する（ステップＳ５０４）。次に、ＡＳ５０の削除指示部６１は、ピア１０Ｂから削除指示の応答としてコンテンツαのデータの削除が完了したことを示す削除完了通知を受信する。そして、削除指示部６１は、配信管理テーブル５３から、コンテンツαの項目を削除する（ステップＳ５０５）。ステップＳ５０５の処理前の配信管理テーブル５３の状態を図１７（ａ）に、ステップＳ５０５の処理後の配信管理テーブル５３の状態を図１７（ｂ）示す。
以上で、キャッシュの削除処理の説明を終了する。

＜キャッシュサーバへの配信元の切替処理＞
図１８を参照して、多くのユーザがコンテンツαを視聴中のために、コンテンツαの配信数が所定の閾値を超え、ピア１０Ｚが新たにコンテンツαの視聴要求をした場合に、コンテンツαの配信元をキャッシュサーバ３０に切り替える切替処理を説明する。
ピア１０Ｚのユーザによりコンテンツαが視聴される場合、ピア１０Ｚの視聴要求部１８は、ＡＳ５０に対して、コンテンツαの視聴要求を送信する(ステップＳ６０１)。

次に、コンテンツαの視聴要求を受信したＡＳ５０の切替判定部５９は、配信管理テーブル５３の内、コンテンツαの配信数５３５をカウントし、コンテンツαの配信数が所定の閾値を超えたので、切替部６０は、キャッシュサーバ３０からピア１０Ｚへ当該コンテンツの単独配信を行うことを決定する（ステップＳ６０２）。

次に、切替部６０は、配信管理テーブル５３を参照し、コンテンツαの配信可能なピア１０Ａ，１０Ｘ，１０Ｙの３つを抽出し、配信管理テーブル５３のコンテンツαの項目にキャッシュサーバ３０に関する情報を登録すると共にピア１０Ａ，１０Ｘ，１０Ｙのレコードの配信数５３５に「１」を増加する。なお、ＡＳ５０の切替部６０は、ピア１０Ａから奇数フレームデータを、ピア１０Ｘから偶数フレームデータを、ピア１０ＹからＸＯＲデータを配信するように決定したものとする。次に、ＡＳ５０の切替部６０は、配信管理テーブル５３を参照し、配信管理テーブル５３のコンテンツαの項目にピア１０Ｚに関する情報を登録すると共にキャッシュサーバ３０のレコードの配信数５３５に「１」を増加する（ステップＳ６０３）。

次に、ＡＳ５０の切替部６０は、キャッシュサーバ３０に対して、収集要求を送信する（ステップＳ６０４）。次に、収集要求を受信したキャッシュサーバ３０の取得部３７は、ピア１０Ａ，１０Ｘ，１０Ｙに対して、取得要求を送信する（ステップＳ６０５）。

次に、取得要求を受信したピア１０Ａの配信部２０は、キャッシュサーバ３０に対して、取得要求の応答としてコンテンツαの奇数フレームデータの配信を開始する。また、取得要求を受信したピア１０Ｘの配信部２０は、キャッシュサーバ３０に対して、取得要求の応答としてコンテンツαの偶数フレームデータの配信を開始する。また、取得要求を受信したピア１０Ｙの配信部２０は、キャッシュサーバ３０に対して、取得要求の応答としてコンテンツαのＸＯＲデータの配信を開始する（ステップＳ６０６）。

次に、キャッシュサーバ３０の統合部３８は、ピア１０Ａから受信した奇数フレームデータ、ピア１０Ｘから受信した偶数フレームデータ、ピア１０Ｙから受信したＸＯＲデータの中から２種類を取捨選択して、取捨選択した２種類からコンテンツαのＦＵＬＬデータを復元する。また、キャッシュサーバ３０の統合部３８は、復元したコンテンツαのＦＵＬＬデータをキャッシュ部３３にキャッシュする。また、キャッシュサーバ３０の統合部３８は、キャッシュ管理テーブル３４にコンテンツαに関する情報を登録する（ステップＳ６０７）。

次に、ＡＳ５０の切替部６０は、配信管理テーブル５３を参照し、ピア１０Ｚに対して、視聴要求の応答として視聴要求応答を送信する（ステップＳ６０８）。次に、視聴要求応答を受信したピア１０Ｚの視聴要求部１８は、キャッシュサーバ３０に対して、配信要求を送信する（ステップＳ６０９）。次に、配信要求を受信したキャッシュサーバ３０の配信部３９は、ピア１０Ｚに対して、配信要求の応答としてコンテンツαのＦＵＬＬデータの配信を開始する（ステップＳ６１０）。

次に、ピア１０Ｚの統合部２１は、コンテンツαのＦＵＬＬデータを再生しながら、キャッシュ部１３にコンテンツαのＦＵＬＬデータをキャッシュする。また、ピア１０Ｚの統合部２１は、キャッシュ管理テーブル１４にコンテンツαに関する情報を登録する（ステップＳ６１１）。なお、キャッシュサーバ３０にあらかじめコンテンツαのデータがキャッシュされている場合、ステップＳ６０３〜ステップＳ６０７の処理は省略する。
以上で、キャッシュサーバ３０への配信元の切替処理の説明を終了する。

以上のように、本実施形態に係るコンテンツ配信システム１００は、コンテンツの視聴数が少ない間は各ピア相互間でコンテンツの配信を行う。よって、本発明に係るコンテンツ配信システム１００によれば、事前にコンテンツを集約して配備する必要がなく、また、コンテンツの突発的な視聴数増加に対応可能である。

また、本実施形態に係るコンテンツ配信システム１００は、コンテンツの視聴に際して、コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータの３種類のデータが３つのピアから配信される(３重同時配信)。よって、本実施形態に係るコンテンツ配信システム１００によれば、コンテンツのデータを配信中のピア１０が突然に電源ＯＦＦされることにより、当該ピア１０からの配信が途絶えても、３ピアの内２ピアからの配信が継続する限りコンテンツのデータを復元することができるので、ユーザは、コンテンツを滞ることなく視聴することができる。

また、本実施形態に係るコンテンツ配信システム１００は、３重同時配信のデータとして、オリジナルコンテンツのデータサイズと比較して０．５倍のデータサイズである奇数フレームデータ７１、偶数フレームデータ７２、及びＸＯＲデータ８０を用いる。よって、本実施形態に係るコンテンツ配信システム１００によれば、１対１でコンテンツを配信する非多重化配信に対し、およそ１．５倍のトラヒック増で約２倍の信頼性を得ることができる。

また、本実施形態に係るコンテンツ配信システム１００は、コンテンツの視聴数が少ない間は各ピア相互間でコンテンツの配信を行い、当該コンテンツの視聴数が増加してきたらキャッシュサーバを併用してコンテンツの配信を行う。よって、本実施形態に係るコンテンツ配信システム１００によれば、各ピア相互間でコンテンツの配信を行うことにより発生する上り帯域の圧迫を軽減することができる。

[変形例]
以上、本発明の実施形態について説明したが、本発明はこれに限定されるものではなく、その趣旨を変えない範囲で実施することができる。本実施形態の変形例を以下に示す。

＜変形例１＞
（ピア１０が備えるキャッシュ部１３へのコンテンツのキャッシュ方法）
本実施形態では、ピア１０は、コンテンツのＦＵＬＬデータをキャッシュ部１３にキャッシュしていたが、コンテンツの一部を保持する(コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータのいずれかのキャッシュを持つ)ようにすることもできる。これにより、１つのピア１０にコンテンツのＦＵＬＬデータを持つ場合に比べて、コンテンツデータの２次配布等のコンテンツの不正利用を難しくすることができる。

その場合、コンテンツを視聴する３台までのピア１０では、コンテンツの分割処理を行う必要があるが、その後は、ピア１０での分割処理を行わなくてもよい。また、コンテンツを最初に何らかの方法を用いて分割しておけば、ピア１０は、分割部１９を備えない構成とすることもできる。

なお、ＡＳ５０が格納する配信管理テーブル５３の項目として、コンテンツの奇数フレームデータ、偶数フレームデータ、ＸＯＲデータの何れか１種類のデータがキャッシュされているピア１０を示す情報を備えるようにする必要がある。
また、キャッシュサーバ３０のコンテンツデータの収集方法としては、３重同時配信を用いることになる。

＜変形例２＞
（キャッシュサーバ３０によるコンテンツのデータの収集方法、及び配信方法）
本実施形態では、キャッシュサーバ３０は、コンテンツのデータを、３重同時配信を用いて３つのピア１０から収集し、単独配信を用いて視聴要求のあったピア１０に配信していた。これ以外にも、キャッシュサーバ３０は、コンテンツのデータを、単独配信を用いて１つのピア１０から収集し、単独配信を用いて視聴要求のあったピア１０に配信するようにしてもよい。その場合の処理を、図１９を参照して説明する。

ステップＳ６０３に続いて、ＡＳ５０は、ピア１０Ａに対して、コンテンツαのＦＵＬＬデータのキャッシュサーバへの配信(アップロード)を要求する(ステップＳ７０４)。次に、ピア１０Ａは、キャッシュサーバに対してコンテンツαのＦＵＬＬデータを配信する（ステップＳ７０５）。続いて、キャッシュサーバ３０は、受信したコンテンツαのＦＵＬＬデータをキャッシュ部３３にキャッシュ(アップロード)する（ステップＳ７０６）。これで、キャッシュサーバ３０は、視聴要求のあったピア１０にコンテンツαを配信することができる。

また、図示を省略するが、キャッシュサーバ３０は、コンテンツのデータを、３重同時配信を用いて視聴要求のあったピア１０に配信することも可能である。例えば、キャッシュサーバ３０を３台配設し、１台目のキャッシュサーバにコンテンツの奇数フレームデータをキャッシュし、２台目のキャッシュサーバに偶数フレームデータをキャッシュし、３台目のキャッシュサーバにＸＯＲデータをキャッシュし、この３台のキャッシュサーバから視聴要求を送信したピア１０に対して、奇数フレームデータ、偶数フレームデータ、ＸＯＲデータを配信するようにする。

また、キャッシュサーバ３０を１台配設し、当該キャッシュサーバ３０には、奇数フレームデータ、偶数フレームデータ、ＸＯＲデータの何れか１種類のデータをキャッシュし、同一のコンテンツの奇数フレームデータ、及び偶数フレームデータをキャッシュするピア１０と協働して３重同時配信を行うことも可能である。

＜変形例３＞
（ＡＳ５０が備える切替判定部５９の判定方法）
本実施形態では、切替判定部５９は、コンテンツのデータの配信元をキャッシュサーバ３０に切り替えるタイミングとして、コンテンツの配信数が所定の閾値を超えているか否かを判定していた。これに対して、切替判定部５９は、図示しないネットワーク機能(ネットワーク管理装置等)から、上り帯域が圧迫している旨の通知を受けるまでは、コンテンツのデータの配信元をキャッシュサーバ３０に切り替える処理を行わないようにしてもよい。そして、切替判定部５９は、上り帯域が圧迫している旨の通知を受けた場合には、切替部６０は、例えば、以下の処理を行う。

切替部６０は、まず、視聴要求があったコンテンツの人気が高いか低いかについて配信管理テーブル５３の配信数を参照して判定する。配信数が多ければ(所定の閾値を超えた場合)人気が高いコンテンツだと判定し、配信数が少なければ(所定の閾値を超えない場合)人気が低いコンテンツだと判定する。次に、切替部６０は、人気が高いと判定したコンテンツについては、キャッシュサーバ３０からの配信に切り替える。配信数が多い(人気が高い)コンテンツは、それだけ、帯域を利用しているからである。一方、切替部６０は、人気が低いと判定したコンテンツについては、以下の何れかの処理を行う。

まず一つ目は、人気が低いと判定したコンテンツであっても、一様にキャッシュサーバ３０からの配信に切り替える処理を行う。二つ目は、上り帯域が圧迫している旨の通知を通信に支障をきたす段階で受信するのではなく、少し帯域に余裕がある段階で受信するようにし、人気が低いと判定したコンテンツについては、ピア１０相互間の配信を継続する処理を行う。三つ目は、人気が低いと判定したコンテンツについては、帯域の圧迫が回復するまで接続しない処理を行う。

＜変形例４＞
（コンテンツ配信システム１００を利用した課金処理）
ネットワーク９０のネットワーク事業者は、ユーザである視聴者に対し、コンテンツの視聴時間に応じた課金(時間課金)を行う場合がある。ここで、ネットワーク事業者は、ネットワーク９０で視聴されるコンテンツの提供者、及びネットワーク９０で用いるリソースの提供者に代わって料金回収の代行を行う。すなわち、ネットワーク事業者は、視聴者から時間課金で料金を徴収し、そのうちコンテンツの提供者に対してコンテンツの視聴時間に応じた報酬を、また、リソースの提供者に対してリソースの提供時間に応じたキャッシュバックを渡す。なお、ネットワーク事業者は、ネットワークの利用料を得る。

このことを具体的に説明すると、例えば、視聴者Ｃがコンテンツを１０分間視聴し、１００円をネットワーク事業者に支払ったとする。ネットワーク事業者は、視聴者Ｃから得た１００円のうち７０円を視聴時間に応じたコンテンツの報酬としてコンテンツの提供者Ａに渡す。また、ネットワーク事業者は、視聴者Ｃから得た１００円のうち１０円をリソースの提供時間に応じたキャッシュバックをリソース提供者Ｂに渡す。なお、ネットワーク事業者は、ネットワークの利用料として１００円のうち２０円を得る。

コンテンツ配信システム１００を用いてこのような時間課金を実現するために、ＡＳ５０が備える配信管理テーブル５３に、コンテンツの視聴開始時間、コンテンツの視聴終了時間、リソースの提供開始時間、及びリソースの提供終了時間を追加する構成とする。そして、ＡＳ５０の管理部５８は、例えば、コンテンツの視聴が開始された時点で開始時間をコンテンツの視聴開始時間及びリソースの提供開始時間に書き込み、視聴が終了した時点で終了時間をコンテンツの視聴終了時間、及びリソースの提供終了時間に書き込むようにする。なお、キャッシュ保持期限が切れて該当するテーブル項目を削除しても、これらの情報を失わないよう、退避して保持を行う。

＜変形例５＞
（コンテンツの配信方法）
本実施形態では、ＡＳ５０は、視聴要求があったピア１０に対して、配信元を通知し、配信先である視聴要求をしたピア１０から配信元に配信要求を送信していた。これ以外にも、ＡＳ５０が、配信元に対して、配信要求を送信し、配信元からいきなり配信先にコンテンツを配信するようにしてもよい。

＜変形例６＞
（キャッシュの管理方法）
本実施形態では、ＡＳ５０がピア１０にキャッシュするコンテンツの期限管理を行っていた（一元管理）。具体的には、ＡＳ５０に記憶されるキャッシュ管理テーブル５３にキャッシュ保持期限５３３を備える構成とし、削除指示部６１が、配信管理テーブル５３のキャッシュ保持期限５３３が切れており、かつ、配信数５３５が「０」のコンテンツをキャッシュしているピア１０が存在するか否かを定期的に検査し、削除対象のコンテンツをキャッシュしているピア１０に対してコンテンツの削除指示を行っていた。

このように、ＡＳ５０がピア１０にキャッシュされるコンテンツの一元管理を行うことで、ピア１０は、自身がキャッシュするコンテンツの期限管理を行う必要がなかった。そのため、ピア１０は、キャッシュ管理テーブル１４にキャッシュ保持期限の項目を備える必要がなく、キャッシュ管理テーブル１４の構成を簡素にすることができた。
一方、ＡＳ５０によるコンテンツの一元管理以外にも、ＡＳ５０とピア１０の両方で、当該ピア１０にキャッシュするコンテンツの期限管理を行うようにすることができる。

例えば、ピア１０に記憶されるキャッシュ管理テーブル１４にキャッシュ保持期限を備える構成とし、ピア１０の削除部２２が、自身がキャッシュするコンテンツの期限管理を行うようにする。
このように、ピア１０が自身にキャッシュするコンテンツの期限管理を行うことで、ＡＳ５０は、削除対象のコンテンツをキャッシュしているピア１０に対してコンテンツの削除指示を行う必要がなくなる。そのため、ＡＳ５０は、これらに関する一連の手順を省くことが可能になる。

１０ピア
１１通信部
１２記憶部
１３キャッシュ部（第１のキャッシュ部）
１４キャッシュ管理テーブル
１５制御部
１６通信制御部
１７登録要求部
１８視聴要求部
１９分割部
２０配信部（第１の配信部）
２１統合部（第１の統合部）
２２削除部
３０キャッシュサーバ
３１通信部
３２記憶部
３３キャッシュ部（第２のキャッシュ部）
３４キャッシュ管理テーブル
３５制御部
３６通信制御部
３７取得部
３８統合部（第２の統合部）
３９配信部（第２の配信部）
４０削除部
５０アプリケーションサーバ（ＡＳ）
５１通信部
５２記憶部
５３配信管理テーブル
５５制御部
５６通信制御部
５７登録部
５８管理部
５９切替判定部
６０切替部
６１削除指示部

Claims

複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムであって、
前記ピアは、
前記コンテンツのデータが記憶される第１のキャッシュ部と、
前記コンテンツの視聴要求を前記アプリケーションサーバに送信する視聴要求部と、
前記アプリケーションサーバから前記コンテンツの配信指示を受信すると、前記第１のキャッシュ部に記憶される前記コンテンツのデータを、所定サイズのフレームに分割し時系列順に連続番号を付したフレーム群とし、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータに分割する分割部と、
前記分割部で分割した前記３種類のデータの内、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信する第１の配信部と、
前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第１のキャッシュ部に復元したコンテンツのデータを記憶させる第１の統合部と、を備え、
前記アプリケーションサーバは、
前記コンテンツ毎に当該コンテンツのデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルと、
前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定する切替判定部と、
前記切替判定部が、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツのデータを記憶する前記ピアを３つ選択し、前記選択したピアのそれぞれを当該コンテンツの奇数フレームデータを配信する第１のピアと、当該コンテンツの偶数フレームデータを配信する第２のピアと、当該コンテンツのＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算する管理部と、
前記切替判定部が、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替える切替部と、を備え
前記キャッシュサーバは、
前記コンテンツのデータが記憶される第２のキャッシュ部と、
前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツのデータを記憶する前記ピアから当該コンテンツのデータを取得し、前記第２のキャッシュ部に前記取得した当該コンテンツのデータを記憶させる第２の統合部と、
前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する第２の配信部と、を備える、
ことを特徴とするコンテンツ配信システム。
複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムであって、
前記ピアは、
前記コンテンツのデータが所定サイズのフレームに分割されて時系列順に連続番号が付されたフレーム群とされ、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータの内、何れか１種類が記憶される第１のキャッシュ部と、
前記コンテンツの視聴要求を前記アプリケーションサーバに送信する視聴要求部と、
前記アプリケーションサーバから前記コンテンツの配信指示を受信すると、前記第１のキャッシュ部に記憶される、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信する第１の配信部と、
前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記受信した３種類のデータの内、何れか１種類を前記第１のキャッシュ部に記憶させる第１の統合部と、を備え、
前記アプリケーションサーバは、
前記コンテンツの前記奇数フレームデータ、前記偶数フレームデータ、前記ＸＯＲデータの何れか１種類のデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルと、
前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定する切替判定部と、
前記切替判定部が、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツの前記奇数フレームデータを記憶する前記ピア、当該コンテンツの前記偶数フレームデータを記憶する前記ピア、当該コンテンツの前記ＸＯＲデータを記憶する前記ピアをそれぞれ選択し、前記選択したピアのそれぞれを当該コンテンツの前記奇数フレームデータを配信する第１のピアと、当該コンテンツの前記偶数フレームデータを配信する第２のピアと、当該コンテンツの前記ＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算する管理部と、
前記切替判定部が、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替える切替部と、を備え、
前記キャッシュサーバは、
前記コンテンツのデータが記憶される第２のキャッシュ部と、
前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツの前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから取得し、前記取得した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第２のキャッシュ部に復元した当該コンテンツのデータを記憶させる第２の統合部と、
前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する第２の配信部と、を備える、
ことを特徴とするコンテンツ配信システム。
複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムのコンテンツ配信方法であって、
前記ピアは、
前記コンテンツの視聴要求を前記アプリケーションサーバに送信し、
前記アプリケーションサーバは、
前記コンテンツ毎に当該コンテンツのデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルを備え、
前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定し、
当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツのデータを記憶する前記ピアを３つ選択し、前記選択したピアのそれぞれを当該コンテンツの奇数フレームデータを配信する第１のピアと、当該コンテンツの偶数フレームデータを配信する第２のピアと、当該コンテンツのＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに前記配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算し、
前記アプリケーションサーバにより決定された前記第１のピア、第２のピア、第３のピアのそれぞれは、
前記コンテンツのデータが記憶される第１のキャッシュ部を備え、
前記アプリケーションサーバから前記配信指示を受信すると、前記第１のキャッシュ部に記憶される前記コンテンツのデータを、所定サイズのフレームに分割し時系列順に連続番号を付したフレーム群とし、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータに分割し、
分割した前記３種類のデータの内、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信し、
前記視聴要求を送信した前記ピアは、
前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第１のキャッシュ部に復元したコンテンツのデータを記憶し、
前記アプリケーションサーバは、
当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替え、
前記キャッシュサーバは、
前記コンテンツのデータが記憶される第２のキャッシュ部を備え、
前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツのデータを記憶する前記ピアから当該コンテンツのデータを取得し、前記第２のキャッシュ部に前記取得した当該コンテンツのデータを記憶し、
前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する、
ことを特徴とするコンテンツ配信方法。
複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムのコンテンツ配信方法であって、
前記ピアは、
前記コンテンツの視聴要求を前記アプリケーションサーバに送信し、
前記アプリケーションサーバは、
前記コンテンツのデータが所定サイズであるフレームに分割されて時系列順に連続番号が付されたフレーム群とされ、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータとの３種類のデータの内、何れか１種類が記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルを備え、
前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定し、
当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツの前記奇数フレームデータを記憶する前記ピア、当該コンテンツの前記偶数フレームデータを記憶する前記ピア、当該コンテンツの前記ＸＯＲデータを記憶する前記ピアをそれぞれ選択し、前記選択したピアのそれぞれを当該コンテンツの前記奇数フレームデータを配信する第１のピアと、当該コンテンツの前記偶数フレームデータを配信する第２のピアと、当該コンテンツの前記ＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算し、
前記アプリケーションサーバにより決定された前記第１のピア、第２のピア、第３のピアのそれぞれは、
前記奇数フレームデータ、前記偶数フレームデータ、前記ＸＯＲデータの内、何れか１種類が記憶される第１のキャッシュ部を備え、
前記第１のキャッシュ部に記憶される、何れか１種類の前記コンテンツのデータを前記アプリケーションサーバから配信指示を受信すると、前記視聴要求を送信した前記ピアに配信し、
前記視聴要求を送信した前記ピアは、
前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記受信した３種類のデータの内、何れか１種類を前記第１のキャッシュ部に記憶し、
前記アプリケーションサーバは、
当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替え、
前記キャッシュサーバは、
前記コンテンツのデータが記憶される第２のキャッシュ部を備え、
前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツの前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから取得し、前記取得した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第２のキャッシュ部に復元した当該コンテンツのデータを記憶し、
前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する、
ことを特徴とするコンテンツ配信方法。
複数のピアとアプリケーションサーバとがネットワークを介して接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムであって、
前記ピアは、
前記コンテンツのデータが記憶される第１のキャッシュ部と、
前記コンテンツの視聴要求を前記アプリケーションサーバに送信する視聴要求部と、
前記アプリケーションサーバから前記コンテンツの配信指示を受信すると、前記第１のキャッシュ部に記憶される前記コンテンツのデータを、所定サイズのフレームに分割し時系列順に連続番号を付したフレーム群とし、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータに分割する分割部と、
前記分割部で分割した前記３種類のデータの内、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信する第１の配信部と、
前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第１のキャッシュ部に復元したコンテンツのデータを記憶させる第１の統合部と、を備え、
前記アプリケーションサーバは、
前記コンテンツ毎に当該コンテンツのデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルと、
前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツのデータを記憶する前記ピアを３つ選択し、前記選択したピアのそれぞれを当該コンテンツの奇数フレームデータを配信する第１のピアと、当該コンテンツの偶数フレームデータを配信する第２のピアと、当該コンテンツのＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行う管理部と、を備える、
ことを特徴とするコンテンツ配信システム。
複数のピア、キャッシュサーバ、及びアプリケーションサーバがネットワークに接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムであって、
前記ピアは、
前記コンテンツのデータが記憶される第１のキャッシュ部と、
前記コンテンツの視聴要求を前記アプリケーションサーバに送信する視聴要求部と、
前記アプリケーションサーバから配信指示を受信すると、前記第１のキャッシュ部に記憶される前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信する第１の配信部と、
前記コンテンツのデータを受信し、前記第１のキャッシュ部に受信した前記コンテンツのデータを記憶させる第１の統合部と、を備え、
前記アプリケーションサーバは、
前記コンテンツ毎に当該コンテンツのデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルと、
前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定する切替判定部と、
前記切替判定部が、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツのデータを記憶する前記ピアを選択し、当該選択したピアに配信指示を行うと共に、前記配信管理テーブルの当該コンテンツの配信数を加算する管理部と、
前記切替判定部が、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替える切替部と、を備え
前記キャッシュサーバは、
前記コンテンツのデータが記憶される第２のキャッシュ部と、
前記アプリケーションサーバから前記配信指示を受信すると、前記配信数が所定の閾値を超えたコンテンツと同じコンテンツのデータを記憶する前記ピアから当該コンテンツのデータを取得し、前記第２のキャッシュ部に前記取得した当該コンテンツのデータを記憶させる第２の統合部と、
前記第２のキャッシュ部に記憶された前記コンテンツのデータを、前記視聴要求を送信した前記ピアに配信する第２の配信部と、を備える、
ことを特徴とするコンテンツ配信システム。
キャッシュサーバとアプリケーションサーバとにネットワークを介して接続され、コンテンツのデータの配信に際して、前記アプリケーションサーバに配信を要求することで、自身以外のピアから前記コンテンツのデータの配信を受ける前記ピアであって、
前記コンテンツのデータが記憶される第１のキャッシュ部と、
前記コンテンツの視聴要求を前記アプリケーションサーバに送信する視聴要求部と、
前記アプリケーションサーバから前記コンテンツの配信指示を受信すると、前記第１のキャッシュ部に記憶される前記コンテンツのデータを、所定サイズのフレームに分割し時系列順に連続番号を付したフレーム群とし、前記フレーム群の内、奇数番号のフレームのデータである奇数フレームデータと、偶数番号のフレームのデータである偶数フレームデータと、前記奇数フレームデータと前記偶数フレームデータとの排他的論理和であるＸＯＲデータと、の３種類のデータに分割する分割部と、
前記分割部で分割した前記３種類のデータの内、何れか１種類の前記コンテンツのデータを前記視聴要求を送信した前記ピアに配信する第１の配信部と、
前記奇数フレームデータと、前記偶数フレームデータと、前記ＸＯＲデータとを別々の前記ピアから受信し、前記受信した３種類のデータの内、少なくとも２種類のデータを統合して前記コンテンツのデータを視聴可能に復元し、前記第１のキャッシュ部に復元したコンテンツのデータを記憶させる第１の統合部と、
を備えることを特徴とするピア。
複数のピアとキャッシュサーバとにネットワークを介して接続され、コンテンツのデータの配信に際して、前記ピアからの配信の要求を受け付けるアプリケーションサーバであって、
前記コンテンツ毎に当該コンテンツのデータが記憶されている前記ピアを示す情報、及び当該コンテンツの配信数が記憶される配信管理テーブルと、
前記ピアから前記コンテンツの視聴要求を受け付けると、前記配信管理テーブルの前記視聴要求に示されるコンテンツの配信数を参照し、当該配信数が所定の閾値を超えるか否かを判定する切替判定部と、
前記切替判定部が、当該配信数が所定の閾値を超えていないと判定した場合に、前記配信管理テーブルを参照して、前記視聴要求に示されるコンテンツと同じコンテンツのデータを記憶する前記ピアを３つ選択し、前記選択したピアのそれぞれを当該コンテンツの奇数フレームデータを配信する第１のピアと、当該コンテンツの偶数フレームデータを配信する第２のピアと、当該コンテンツのＸＯＲデータを配信する第３のピアとして決定し、前記決定した当該第１のピア、当該第２のピア、当該第３のピアそれぞれに配信指示を行う共に、前記配信管理テーブルの当該コンテンツの配信数を加算する管理部と、
前記切替判定部が、当該配信数が所定の閾値を超えていると判定した場合に、当該コンテンツの当該視聴要求以後の視聴要求について、前記キャッシュサーバに配信指示をすることにより前記コンテンツのデータの配信元を前記キャッシュサーバに切り替える切替部と、
を備えることを特徴とするアプリケーションサーバ。
複数のピアとアプリケーションサーバとにネットワークを介して接続され、コンテンツのデータの配信に際して、前記ピアが前記アプリケーションサーバに配信を要求することで、前記ピア同士が前記コンテンツのデータの配信を直接行うコンテンツ配信システムに用いられるキャッシュサーバであって、
前記コンテンツのデータが記憶される第２のキャッシュ部と、
前記アプリケーションサーバからの前記ピア同士の配信から前記キャッシュサーバによる配信への切り替えを示す配信指示を受け、前記ピアが配信を要求したコンテンツと同じコンテンツのデータを記憶する前記ピアから当該コンテンツのデータを取得し、前記第２のキャッシュ部に前記取得した当該コンテンツのデータを記憶させる第２の統合部と、
前記アプリケーションサーバからの前記配信指示を受信すると、前記第２のキャッシュ部に記憶された前記コンテンツのデータを、当該コンテンツのデータの配信を要求した前記ピアに配信する第２の配信部と、
を備えることを特徴とするキャッシュサーバ。