JP5764100B2 - コンテンツ配信システムおよびコンテンツ配信方法 - Google Patents

Description

本発明は、コンテンツ配信システムおよびコンテンツ配信方法に関し、特にコンテンツ配信ネットワーク上のキャッシュサーバにおけるビデオコンテンツのキャッシュ管理技術に関する。

近年、インターネットにおいてビデオコンテンツ（動画のコンテンツ）によるトラヒックが急増している。このようなビデオコンテンツの配信技術として、CDN（Content Delivery Network）や、非特許文献１に開示されるようなHTTP（HyperText Transfer Protocol）を用いたビデオコンテンツのストリーミングが利用されている。CDNでは、コンテンツを高速かつ効率的に配信するために、オリジンサーバのコンテンツをネットワーク上に分散配置されているキャッシュサーバへ複製し、ユーザ端末から要求されたコンテンツがキャッシュサーバに保持されている場合は、オリジンサーバの代わりにキャッシュサーバからコンテンツを配信する。CDNでは、キャッシュサーバから配信することにより、オリジンサーバ負荷の低減、トラヒック削減によるネットワーク設備コストの削減、レスポンス時間短縮によるQoE（Quality of Experience）の向上を実現できる。ピーク時のオリジンサーバ-キャッシュサーバ間のトラヒック削減およびオリジンサーバの負荷低減をするためには、オフピーク時にキャッシュサーバへコンテンツを事前配信することが有効である。

R. Pantos, Ed., W. May, " HTTP Live Streaming" IETF Internet-Draft, March 2012.

特に大容量データである可能性が高いビデオコンテンツは、キャッシュヒットした（ユーザ端末から要求されたコンテンツがキャッシュサーバに保持されている）場合のトラヒック削減効果が高い。一方で、ビデオコンテンツは人気度のロングテール化や短期的な人気度の変動という特性があり、人気度の予測が困難である。そのため、キャッシュヒット率を向上させるためには多数のビデオコンテンツをキャッシュサーバのキャッシュに保持する必要があるが、キャッシュサーバ１台あたりのキャッシュ容量は限られている。

また、従来、コンテンツの事前キャッシュは一般的にコンテンツの全体データをキャッシュに保持するため、キャッシュに保持できるコンテンツの数が限られる。よって、キャッシュサーバのキャッシュヒット率が低下してしまう。さらに、近年広く利用されている無料や定額で映画やドラマが見放題のサービスでは、ユーザがビデオコンテンツの最初のみ視聴してやめる状況が頻繁に発生している。この場合、キャッシュに保持されている該当コンテンツの全体データのうち、視聴離脱した時間以降のデータは使用されないことになる。特に映画等の長時間のビデオコンテンツでは、視聴されないデータの割合が非常に大きくなり、キャッシュサーバのキャッシュ効率（キャッシュに保持されているコンテンツのデータのうち、実際にユーザ端末に視聴される割合）が低くなるという問題がある。そこで、本発明は前記した問題を解決し、コンテンツ配信システムのキャッシュサーバにおけるキャッシュ効率を向上させることを課題とする。

前記した課題を解決するため、本発明は、ユーザ端末からのリクエストに応じて動画のコンテンツを配信するキャッシュサーバと、前記コンテンツを前記キャッシュサーバへ配信するオリジンサーバとを備えるコンテンツ配信システムであって、前記オリジンサーバは、前記コンテンツと、前記コンテンツごとに前記コンテンツの属するコンテンツグループを示したコンテンツ情報テーブルと、前記コンテンツのコンテンツグループＧｘごとに、以下の式（１）で定義される視聴離脱率が所定の値αとなる前記コンテンツグループＧｘのコンテンツの再生時間Ｔ（Ｇｘ，α）を示した視聴離脱特性テーブルとを記憶するオリジンサーバ記憶部と、コンテンツの再生時間ｔ秒での視聴離脱率＝（当該コンテンツの再生開始時の視聴数―当該コンテンツの再生時間ｔ秒での視聴数）／（当該コンテンツの再生開始時の視聴数）…式（１）
前記視聴離脱特性テーブルおよび前記コンテンツ情報テーブルを参照して、前記コンテンツグループＧｘのコンテンツのデータのうち、先頭から前記再生時間Ｔ（Ｇｘ，α）を超えるまでのデータを前記キャッシュサーバへ配信するコンテンツ送信部とを備え、前記キャッシュサーバは、前記配信されたコンテンツのデータを記憶するキャッシュサーバ記憶部と、前記ユーザ端末からのリクエストに応じて前記コンテンツのデータを前記リクエストの送信元のユーザ端末へ配信するコンテンツ配信部と、前記ユーザ端末からリクエストされた前記コンテンツのデータが前記キャッシュサーバ記憶部にないとき、前記オリジンサーバへ前記コンテンツのデータの配信リクエストを送信するオリジンサーバ通信部とを備える。

このようにすることで、各キャッシュサーバにはユーザ端末が視聴する可能性が高い部分のコンテンツのデータが配信されることになる。これにより、キャッシュサーバにおけるキャッシュ効率を向上させることができる。なお、式（１）における「コンテンツの再生開始時の視聴数」は、コンテンツのアクセス数を用いる。また、「コンテンツの再生時間ｔ秒での視聴数」は、再生時間ｔ秒でコンテンツが視聴（再生）された回数を用いる。

また、本発明のコンテンツ配信システムの前記キャッシュサーバ記憶部は、さらに、コンテンツ管理テーブルを記憶し、前記キャッシュサーバは、さらに、前記オリジンサーバからの問い合わせに含まれる配信予定のコンテンツのデータのデータサイズに基づき、前記キャッシュサーバ記憶部に、前記オリジンサーバからのコンテンツのデータをキャッシュする空き容量があるか否かを判断するキャッシュ管理部と、前記コンテンツごとの、当該コンテンツの前記ユーザ端末への配信回数および前記ユーザ端末における再生完了数を前記コンテンツ管理テーブルに記録するコンテンツ再生記録部とを備え、前記オリジンサーバ通信部は、さらに、前記オリジンサーバから、前記キャッシュサーバ記憶部に、前記コンテンツのデータをキャッシュする空き容量があるか否かの問い合わせを受信した場合、前記問い合わせに含まれる配信予定のコンテンツのデータのデータサイズを前記キャッシュ管理部へ出力し、前記キャッシュ管理部により前記コンテンツのデータをキャッシュする空き容量があると判断されたとき、前記オリジンサーバへ前記コンテンツのデータの配信リクエストを送信し、前記キャッシュ管理部は、前記オリジンサーバからのコンテンツのデータをキャッシュする空き容量がないと判断した場合、削除対象データとして、前記コンテンツ管理テーブルを参照して、既に前記キャッシュサーバ記憶部に記憶されたコンテンツのうち、当該コンテンツの配信回数が少なくかつ再生完了数が少ないコンテンツから優先的に選択し、前記空き容量が確保できるまで、前記選択したコンテンツを削除する処理を繰り返す。

また、本発明のコンテンツ配信システムのキャッシュサーバにおける前記コンテンツ再生記録部は、さらに、前記コンテンツの再生中止があった場合、当該コンテンツのどのデータまで再生したかをキャッシュチャンク情報テーブルに記録し、前記キャッシュサーバ記憶部は、さらに、前記キャッシュチャンク情報テーブルを記憶し、前記キャッシュ管理部は、前記オリジンサーバからのコンテンツのデータをキャッシュする空き容量がないと判断した場合、削除対象データとして、前記コンテンツ管理テーブルおよび前記キャッシュチャンク情報テーブルを参照して、既に前記キャッシュサーバ記憶部に記憶されたコンテンツから、前記配信回数が０のコンテンツを探し、前記配信回数が０のコンテンツを削除しても、前記空き容量が確保できないとき、当該コンテンツの配信回数および再生完了数がより少ないコンテンツから優先的に選択し、前記選択したコンテンツのデータのうち、以下の式（２）で定義される再生開始からの離脱率が所定の閾値βを超えている時間以降の部分のデータを求め、前記空き容量が確保できるまで、前記求めたデータを削除する処理を繰り返す。
当該コンテンツの再生時間t秒での離脱率＝当該コンテンツの再生開始から再生時間t秒までの再生中止数／当該コンテンツの配信回数…式（２）

このように各キャッシュサーバは、キャッシュサーバ記憶部の空き容量が足りなくなったとき、自身が保持するコンテンツのデータのうち、視聴される可能性が低いデータを削除する。これにより、キャッシュサーバには、ユーザ端末により視聴される可能性がより高い部分のコンテンツのデータが保持されることになるので、キャッシュサーバのキャッシュ効率を向上させることができる。

また、本発明のコンテンツ配信システムにおける前記コンテンツ送信部および前記コンテンツ配信部は、前記コンテンツのデータを配信するとき、チャンク形式で配信する。

このようにオリジンサーバからキャッシュサーバへのコンテンツのデータ送信、および、キャッシュサーバからユーザ端末へのデータ配信において、チャンクを用いるので、キャッシュサーバやユーザ端末へどのデータまで配信したかや、後続データを配信する際には、どのデータ以降を配信すればよいか等を管理しやすくなる。

本発明によれば、オリジンサーバから事前にキャッシュサーバへコンテンツを配信するコンテンツ配信システムにおいて、キャッシュサーバのキャッシュ効率を向上させることができる。

本実施の形態のコンテンツ配信システムの概要を説明した図である。 コンテンツグループごとの視聴離脱特性を例示した図である。 図１のオリジンサーバのブロック構成図である。 図１のキャッシュサーバのブロック構成図である。 図１のコンテンツ配信システムの処理手順（オリジンサーバがキャッシュサーバへコンテンツ（コンテンツのチャンク）を配信する手順）を示した図である。 図１のコンテンツ配信システムの処理手順（ユーザ端末からのコンテンツ配信リクエストを受信したキャッシュサーバの処理手順）を示した図である。 図１のコンテンツ配信システムの処理手順（ユーザ端末がコンテンツの再生中止をしたときの処理手順）を示した図である。 図１のコンテンツ配信システムの処理手順（キャッシュサーバによるチャンク削除手順）を示した図である。

＜概要＞
以下、図面を用いて本発明の実施の形態を説明する。まず、本実施の形態のコンテンツ配信システムの概要を、図１を用いて説明する。なお、本実施の形態で扱うコンテンツは主に動画のコンテンツである。また、コンテンツはチャンク単位で送信や配信を行うものとするが、コンテンツの任意の個所で切断されたデータであってもよい。

図１に示すように、コンテンツ配信システムは、キャッシュサーバ２０へコンテンツを事前に配信しておくオリジンサーバ１０と、ユーザ端末３０からのリクエストに応じてコンテンツを配信するキャッシュサーバ２０とを備える。各サーバおよびユーザ端末３０の台数は、図１に示した台数に限定されない。オリジンサーバ１０とキャッシュサーバ２０とは連携しており、両サーバ間で高速データ転送するためのTCP（Transmission Control Protocol）高速化やファイル圧縮等の機能を装備していてもよい。

このオリジンサーバ１０は、予め測定した各コンテンツの視聴離脱率（後記する式（１）で定義）からコンテンツグループごとの視聴離脱特性を求めておく。コンテンツグループとは、同じコンテンツ属性を持つコンテンツ群をまとめたものをいう。視聴離脱特性の例を、図２に示す。再生時間ｔ秒での視聴離脱率は以下の式（１）で定義される。ここでの視聴数は、ユーザ端末３０でコンテンツを再生（視聴）する回数である。

コンテンツの再生時間ｔ秒での視聴離脱率＝（当該コンテンツの再生開始時の視聴数―当該コンテンツの再生時間ｔ秒での視聴数）／（当該コンテンツの再生開始時の視聴数）…式（１）

この視聴離脱特性から、コンテンツグループＧｘ（ｘ＝０，１，…）ごとに、視聴離脱率が所定の値α（αは適宜設定。例えば、０．９）となる再生時間Ｔ（Ｇｘ，α）を求めておく。例えば、コンテンツグループＧ０のコンテンツ群の視聴離脱率がαとなる再生時間は、図２のグラフのＴ（Ｇ０，α）に示す値であり、コンテンツグループＧ１のコンテンツ群の視聴離脱率がαとなる再生時間は、図２のグラフのＴ（Ｇ１，α）に示す値である。

そして、オリジンサーバ１０は、コンテンツグループＧｘのコンテンツ群についてＴ（Ｇｘ，α）までのコンテンツのデータ（チャンク）をキャッシュサーバ２０へ事前に配信しておく。

例えば、オリジンサーバ１０は、コンテンツグループＧｘのコンテンツについて、Ｔ（Ｇｘ，α）までのチャンクがチャンク番号３までであった場合、Ｔ（Ｇｘ，α）までのチャンク（つまり、チャンク番号１〜３のチャンク）をキャッシュサーバ２０へ配信しておく。このようにすることで、各キャッシュサーバ２０には、コンテンツを構成するチャンクのうち、ユーザ端末３０により視聴される可能性が高い時刻までのチャンクが保持されることになり、キャッシュサーバ２０のキャッシュ効率を向上させることができる。なお、事前配信されたデータ（チャンク）の後続データは、ユーザ端末３０から要求があったときにキャッシュサーバ２０からオリジンサーバ１０へ要求し、ユーザ端末３０へ配信される。

ここでキャッシュサーバ２０は、自身の保持するコンテンツそれぞれのアクセス数や再生完了数、チャンクごとの離脱率を記録しておく。なお、ここでの離脱率は以下の式（２）で定義される。

離脱率＝当該コンテンツの再生開始から当該チャンクまでの再生中止数の和／当該コンテンツのアクセス数（配信回数）…式（３）

そして、オリジンサーバ１０からコンテンツのデータを受信する場合において、キャッシュサーバ２０にそのデータを受信できるだけのキャッシュの空き容量がない場合、このキャッシュサーバ２０が保持するコンテンツのうち、コンテンツそれぞれのアクセス数や再生完了数、離脱率を基づき、コンテンツ（コンテンツのチャンク）を削除する。例えば、キャッシュサーバ２０はアクセス数が比較的少ないコンテンツや再生完了数が比較的少ないコンテンツを削除したり、離脱率がβ（βの値は適宜設定）となるチャンクより先のチャンクのデータを削除する。例えば、キャッシュサーバ２０において、コンテンツの離脱率がβとなるチャンクが、図１に例示するチャンク番号２のチャンクである場合、キャッシュサーバ２０のチャンク番号３以降のチャンクを削除する。そして、キャッシュサーバ２０は、オリジンサーバ１０からコンテンツのデータを受信する。このようにすることで、キャッシュサーバ２０のキャッシュ効率をさらに向上させることができる。

＜オリジンサーバ＞
次に、図３を用いて、オリジンサーバ１０を詳細に説明する。オリジンサーバ１０は、オリジンサーバ記憶部１５と、事前キャッシュ対象選択部１１と、コンテンツ送信部１２とを備える。破線で示した視聴離脱特性テーブル作成部１３は装備する場合としない場合とがあり、装備する場合について後記する。

事前キャッシュ対象選択部１１およびコンテンツ送信部１２は、オリジンサーバ１０の備えるＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。さらに、オリジンサーバ記憶部１５は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等の記憶媒体により実現される。なお、オリジンサーバ１０をプログラム実行処理により実現する場合、オリジンサーバ記憶部１５には、このオリジンサーバ１０の機能を実現するためのプログラムが格納される。

オリジンサーバ記憶部１５は、コンテンツ１５１と、視聴離脱特性テーブル１５２と、チャンク情報テーブル１５３と、コンテンツ情報テーブル１５４とを備える。

コンテンツ１５１は、動画等のコンテンツであり、事前に複数のチャンクに分割されているものとする。

視聴離脱特性テーブル（視聴離脱特性情報）１５２は、コンテンツグループごとに、当該コンテンツグループに属するコンテンツの視聴離脱率に基づいて求めたコンテンツグループごとの視聴離脱率がαになる再生時間Ｔ（Ｇｘ，α）を示した情報である（表１参照）。この情報は、各コンテンツグループのコンテンツの視聴離脱率（前記した図２参照）に基づき作成される。

なお、図２のコンテンツグループＧ２のように再生時間が所定値（図示省略）を超えても視聴離脱率がαより小さいコンテンツグループ、つまり、長時間の視聴が予測されるコンテンツグループのコンテンツに対しては、再生時間Ｔ（Ｇｘ，α）＝０とする。

チャンク情報テーブル１５３は、コンテンツグループのコンテンツごとに、そのコンテンツを構成する各チャンクに関する情報を示したものである。例えば、チャンク情報テーブル１５３は、表２に示すように、コンテンツごとに、そのコンテンツを構成するチャンクのチャンク番号と、そのチャンク番号のチャンクの再生時間長、データサイズ、URI（Uniform Resource Identifier）等が格納される。このチャンク情報テーブル１５３には、コンテンツを構成する先頭チャンクから時系列順にチャンクの情報が格納される。

コンテンツ情報テーブル１５４は、コンテンツごとに、当該コンテンツのコンテンツ名（コンテンツ識別情報）と、当該コンテンツを構成する全チャンク数と、当該コンテンツが属するコンテンツグループを示した情報である。

事前キャッシュ対象選択部１１は、視聴離脱特性テーブル１５２を参照して、各キャッシュサーバ２０へ事前配信しておくコンテンツのチャンクを選択する。ここで、事前キャッシュ対象選択部１１は、視聴離脱特性テーブル１５２、チャンク情報テーブル１５３およびコンテンツ情報テーブル１５４を参照して、各コンテンツのデータのうち、先頭から再生時間長の和がＴ（Ｇｘ，α）を超えるまでのチャンクをキャッシュサーバ２０へ事前配信するチャンクとして選択する。なお、事前キャッシュ対象選択部１１は、再生時間Ｔ（Ｇｘ，α）＝０のコンテンツグループ（つまり再生時間が所定値を超えても視聴離脱率がαより小さいコンテンツグループ）のコンテンツは全チャンクを事前配信するチャンクとして選択する。

コンテンツ送信部１２は、事前キャッシュ対象選択部１１により選択されたコンテンツのチャンク（事前キャッシュ対象チャンク）をキャッシュサーバ２０へ配信する。また、コンテンツ送信部１２は、キャッシュサーバ２０からリクエストされたコンテンツのチャンクを、オリジンサーバ記憶部１５から読み出し、配信する。なお、このコンテンツ送信部１２は、コンテンツのチャンク配信にあたり、キャッシュサーバ２０に対し、チャンクをキャッシュする空き容量があるか否かを問い合わせる。そして、コンテンツ送信部１２は、キャッシュサーバ２０から、空き容量がある旨の応答を得ると、コンテンツのチャンクを送信する。このとき、コンテンツ送信部１２は、コンテンツのチャンクとともに、当該チャンクのチャンク情報およびコンテンツ情報も、キャッシュサーバ２０へ送信する。チャンク情報は、チャンク情報テーブル１５３に格納された情報のうち、配信対象のコンテンツのチャンクに関する情報（例えば、チャンク番号、再生時間長、データサイズ、URI等）を読み出したものである。また、コンテンツ情報は、コンテンツ情報テーブル１５４に格納された情報のうち、配信対象のチャンクのコンテンツの情報（例えば、コンテンツの識別情報、全チャンク数等）を読み出したものである。

＜キャッシュサーバ＞
次に、図４を用いてキャッシュサーバ２０を詳細に説明する。キャッシュサーバ２０は、キャッシュサーバ記憶部２１と、オリジンサーバ通信部２２と、キャッシュ管理部２３と、リクエスト受信部２４と、コンテンツ配信部２５と、コンテンツ再生記録部２６とを備える。

また、オリジンサーバ通信部２２と、キャッシュ管理部２３と、リクエスト受信部２４と、コンテンツ配信部２５と、コンテンツ再生記録部２６とは、通信インタフェースおよびキャッシュサーバ２０の備えるＣＰＵによるプログラム実行処理や、専用回路等により実現される。さらに、キャッシュサーバ記憶部２１は、ＲＡＭ、ＲＯＭ、ＨＤＤ、フラッシュメモリ等の記憶媒体により実現される。なお、キャッシュサーバ２０をプログラム実行処理により実現する場合、キャッシュサーバ記憶部２１には、このキャッシュサーバ２０の機能を実現するためのプログラムが格納される。

キャッシュサーバ記憶部２１は、オリジンサーバ１０から送信されるコンテンツチャンク（コンテンツのチャンク）２１１と、キャッシュチャンク情報テーブル２１２と、コンテンツ管理テーブル２１３とを記憶する領域を備える。

コンテンツチャンク２１１は、前記したとおり、オリジンサーバ１０から配信されたコンテンツのチャンクである。

キャッシュチャンク情報テーブル２１２は、コンテンツチャンク２１１のチャンクごとに、当該チャンクのチャンク番号、再生時間長、データサイズ、URI、キャッシュ格納先（キャッシュサーバ記憶部２１における格納先）、再生中止数を示した情報である（表４参照）。このキャッシュチャンク情報テーブル２１２における、チャンク番号、再生時間長、データサイズおよびURIは、オリジンサーバ１０から受信したチャンク情報に示される情報を用いる。

コンテンツ管理テーブル２１３は、コンテンツチャンク２１１のコンテンツごとに、当該コンテンツのコンテンツ名（コンテンツ識別情報）と、当該コンテンツの全チャンク数、当該コンテンツの全チャンクのうち、キャッシュサーバ記憶部２１で保持するチャンク数（保持チャンク数）、当該コンテンツのオリジンサーバ１０からの受信日時と、当該コンテンツのアクセス数（ユーザ端末３０への配信回数）と、当該コンテンツの再生完了数（ユーザ端末３０が当該コンテンツの最後のチャンクまで受信した回数）とを示した情報である（表５参照）。コンテンツ管理テーブル２１３における、全チャンク数は、オリジンサーバ１０から受信したコンテンツ情報に示される情報を用いる。

オリジンサーバ通信部２２は、オリジンサーバ１０との通信を行う。このオリジンサーバ通信部２２は、オリジンサーバ１０からコンテンツのチャンク、このチャンクのチャンク情報およびコンテンツ情報を受信する。受信したコンテンツのチャンクは、キャッシュサーバ記憶部２１の所定領域に格納し、受信したチャンク情報は、キャッシュチャンク情報テーブル２１２に格納し、受信したコンテンツ情報は、コンテンツ管理テーブル２１３に格納する。このとき、オリジンサーバ通信部２２は、キャッシュチャンク情報テーブル２１２に、受信したチャンクのキャッシュ格納先を記録し、コンテンツ管理テーブル２１３に、コンテンツの受信日時を記録する。キャッシュチャンク情報テーブル２１２の再生中止数、コンテンツ管理テーブル２１３のアクセス数および再生完了数は、ともに初期値（０）とする。

また、オリジンサーバ通信部２２は、ユーザ端末３０へ配信するコンテンツのチャンクが足りなくなりそうになったとき、オリジンサーバ１０へこのコンテンツの後続チャンクの配信リクエストを送信する。例えば、オリジンサーバ通信部２２は、まず、オリジンサーバ１０からチャンク（事前キャッシュ対象チャンク）を受信すると、このチャンクをキャッシュ管理部２３（詳細は後記）経由で、キャッシュサーバ記憶部２１に格納する。その後、オリジンサーバ通信部２２は、ユーザ端末３０へコンテンツのチャンクを配信する場合において、キャッシュサーバ記憶部２１に格納される後続のチャンク数が所定の閾値（後続チャンク要求閾値）以下となったとき、オリジンサーバ１０に後続チャンクの配信リクエストを送信する。そして、オリジンサーバ通信部２２は、オリジンサーバ１０から受信した後続チャンクをキャッシュ管理部２３経由でキャッシュサーバ記憶部２１へ格納しておき、ユーザ端末３０から後続チャンクの配信に備える。なお、オリジンサーバ通信部２２は、コンテンツのチャンクの配信に先立ち、オリジンサーバ１０からコンテンツのチャンク配信の通知を受信する。このとき、オリジンサーバ通信部２２は、キャッシュ管理部２３に対し、オリジンサーバ１０からのコンテンツのチャンクのデータサイズを出力し、キャッシュサーバ記憶部２１に、このチャンクをキャッシュする（格納する）空き容量があるか否かを問い合わせる。そして、キャッシュ管理部２３においてコンテンツのチャンクをキャッシュする空き容量があると判断されたとき、オリジンサーバ通信部２２は、オリジンサーバ１０に対しコンテンツのチャンクの配信を依頼する。

キャッシュ管理部２３は、キャッシュサーバ記憶部２１内のコンテンツチャンク２１１や、コンテンツ管理テーブル２１３や、キャッシュチャンク情報テーブル２１２のデータを読み出したり、書き込んだり、削除したりする。このキャッシュ管理部２３は、オリジンサーバ１０からのコンテンツのチャンクを受信する場合において、キャッシュサーバ記憶部２１に、コンテンツのデータをキャッシュする空き容量があるか否かを判断する。ここで、空き容量がないと判断したとき、コンテンツチャンク２１１の一部を削除する。つまり、キャッシュ管理部２３は、コンテンツ管理テーブル２１３およびキャッシュチャンク情報テーブル２１２を参照して、削除対象データとして、コンテンツチャンク２１１のうち、アクセス数（配信回数）および再生完了数がより少ないコンテンツから優先的に選択し、この選択したコンテンツのチャンクのうち、再生開始からの離脱率が所定の閾値βを超えている時間以降の部分のチャンクを求める。そして、キャッシュ管理部２３は、この離脱率が所定の閾値βを超えている時間以降の部分のチャンクを、所定の（オリジンサーバ１０からのコンテンツのチャンクをキャッシュできるだけの）空き容量が確保できるまで削除する。そして、キャッシュ管理部２３は、削除したコンテンツ（コンテンツのチャンク）に関する情報を、キャッシュチャンク情報テーブル２１２（表４参照）およびコンテンツ管理テーブル２１３（表５参照）から削除および修正する。ここでのチャンクの削除手順の詳細は後記する。また、キャッシュ管理部２３は、コンテンツ管理テーブル２１３におけるアクセス数および再生完了数と、キャッシュチャンク情報テーブル２１２における再生中止数とを、所定期間ごとにクリアする。これは、キャッシュ管理部２３において、コンテンツのアクセス数および再生完了数や、チャンクの再生中止数が無限に大きくなってしまうのを防止するためである。

リクエスト受信部２４は、ユーザ端末３０からのコンテンツ（コンテンツのチャンク）の配信のリクエストを受信する。そして、リクエスト受信部２４は、コンテンツチャンク２１１に、リクエスト対象のコンテンツのチャンクがあるか否かを確認し、あればコンテンツ配信部２５に対しリクエスト対象のコンテンツの配信を行うよう指示する。一方、リクエスト対象のコンテンツのチャンクがないとき、リクエスト受信部２４はオリジンサーバ通信部２２に対し、リクエスト対象のコンテンツをオリジンサーバ１０から取得するよう指示する。そして、オリジンサーバ１０から取得されたコンテンツのチャンクは、コンテンツチャンク２１１に追加され、コンテンツ配信部２５により、リクエストの送信元のユーザ端末３０へ配信される。

コンテンツ配信部２５は、コンテンツの配信のリクエストの送信元のユーザ端末３０へコンテンツのチャンクを配信する。

コンテンツ再生記録部２６は、コンテンツごとに、当該コンテンツのユーザ端末３０への配信回数（ユーザ端末３０による当該コンテンツのアクセス数）およびユーザ端末３０における再生完了数をコンテンツ管理テーブル２１３に記録する。そして、コンテンツ再生記録部２６は、コンテンツの再生中止があった場合、当該コンテンツのどのデータ（チャンク）まで再生したかをキャッシュチャンク情報テーブル２１２に記録する。例えば、ユーザ端末３０がコンテンツkの配信を受け始めたことを確認すると、コンテンツ再生記録部２６は、コンテンツ管理テーブル２１３におけるコンテンツｋのアクセス数を１加算する。また、コンテンツ再生記録部２６は、ユーザ端末３０がこのコンテンツｋの最終チャンクまで受信したことを確認すると、コンテンツ管理テーブル２１３におけるコンテンツｋの再生完了数を１加算する。また、ユーザ端末３０がコンテンツｋのチャンク番号２の途中で再生を中止した場合、コンテンツ再生記録部２６は、キャッシュチャンク情報テーブル２１２におけるコンテンツｋのチャンク番号２の再生中止数を１加算する。

以上説明したコンテンツ配信システムによれば、キャッシュサーバ２０はユーザ端末３０により視聴される可能性が高い部分のコンテンツのチャンクを保持することになる。また、各キャッシュサーバ２０は、自身のキャッシュ容量（キャッシュサーバ記憶部２１の記憶容量）が足りなくなったとき、自身が保持するコンテンツのチャンクのうち、視聴される可能性が低いチャンクを削除する。これにより、キャッシュサーバ２０には、よりユーザ端末３０が視聴する可能性が高い部分のコンテンツのチャンクが保持されることになるので、キャッシュサーバ２０におけるキャッシュ効率を向上させることができる。

＜処理手順＞
次に、適宜図２〜図４を参照しつつ、図５〜図８を用いてコンテンツ配信システムの処理手順を説明する。

まず、図５を用いて、オリジンサーバ１０がキャッシュサーバ２０へコンテンツ（コンテンツのチャンク）を配信する手順を説明する。なお、このコンテンツの配信は、オリジンサーバ１０とキャッシュサーバ２０との間のトラヒック量が比較的少ない時間帯に行うことが好ましい。オリジンサーバ１０は、予め測定した各コンテンツの視聴離脱特性およびコンテンツ属性から、コンテンツグループごとの視聴離脱特性（図２参照）を求める（図５のＳ１）。そして、オリジンサーバ１０は、Ｓ１で求めた視聴離脱特性からコンテンツグループＧｘ（ｘ＝０，１，…）に対して視聴離脱率αとなる再生時間Ｔ（Ｇｘ，α）を求め（Ｓ２）、視聴離脱特性テーブル１５２（表１参照）に登録しておく（Ｓ３）。

オリジンサーバ１０の事前キャッシュ対象選択部１１（図３参照）は、視聴離脱特性テーブル１５２を参照して、コンテンツごとにどのチャンクまでキャッシュサーバ２０へ配信しておくか決定する（Ｓ４）。具体的には、事前キャッシュ対象選択部１１は、視聴離脱特性テーブル１５２を参照し、各コンテンツグループのコンテンツのＴ（Ｇｘ，α）を取得する。そして、事前キャッシュ対象選択部１１は、各コンテンツグループのコンテンツ（例えば、コンテンツｋ）のチャンク情報テーブル１５３を参照して、先頭チャンクからの再生時間長の和がＴ（Ｇｘ，α）を超えるチャンクまでを事前キャッシュ対象チャンクとして選択する。

そして、オリジンサーバ１０のコンテンツ送信部１２は、キャッシュサーバ２０へ空き容量（Ｓ４で選択した事前キャッシュ対象チャンク（配信予定のコンテンツのチャンク）を格納するための空き容量）の問い合わせを送信する（Ｓ５）。なお、コンテンツ送信部１２は、空き容量の問い合わせに事前キャッシュ対象チャンクのデータサイズを含めて送信する。

キャッシュサーバ２０のオリジンサーバ通信部２２（図４参照）は、この空き容量の問い合わせを受信すると、キャッシュ管理部２３に対しキャッシュサーバ記憶部２１に空き容量があるか否かを確認する（Ｓ６）。つまり、オリジンサーバ通信部２２は、オリジンサーバ１０から受信した空き容量の問い合わせに含まれる事前キャッシュ対象チャンクのデータサイズをキャッシュ管理部２３へ出力する。キャッシュ管理部２３は、出力された事前キャッシュ対象チャンクのデータサイズに基づき、キャッシュサーバ記憶部２１に事前キャッシュ対象チャンクを格納する空き容量があるか否かを確認する。キャッシュ管理部２３が、キャッシュ記憶部２１に空き容量がないと判断した場合（Ｓ６のＮｏ）、キャッシュ管理部２３はキャッシュサーバ記憶部２１のコンテンツチャンク２１１のうち、必要な空き容量をつくるために削除するチャンクを選択し、この選択したチャンクを削除する（Ｓ７）。そして、Ｓ８へ進む。このＳ７の処理の詳細は、後記する。

一方、キャッシュ管理部２３が、キャッシュサーバ記憶部２１に空き容量があると判断した場合（Ｓ６のＹｅｓ）、キャッシュサーバ２０のオリジンサーバ通信部２２は、キャッシュＯＫの応答をオリジンサーバ１０へ送信する（Ｓ８）。

キャッシュサーバ２０からキャッシュＯＫの応答を受信したオリジンサーバ１０のコンテンツ送信部１２は、Ｓ４で決定したチャンク（キャッシュ対象チャンク）と、このチャンクのチャンク情報およびキャッシュ対象チャンクのコンテンツ情報とを、オリジンサーバ記憶部１５から読み出し、キャッシュサーバ２０へ配信する（Ｓ９）。

キャッシュサーバ２０のオリジンサーバ通信部２２は、配信されたチャンクをキャッシュ管理部２３経由でキャッシュサーバ記憶部２１のコンテンツチャンク２１１に追加して格納する。また、オリジンサーバ通信部２２は、キャッシュ管理部２３経由で配信されたチャンク情報をキャッシュチャンク情報テーブル２１２に格納し、コンテンツ情報をコンテンツ管理テーブル２１３に格納する（Ｓ１０）。

このようにすることで、キャッシュサーバ２０には視聴離脱率αとなる再生時間Ｔ（Ｇｘ，α）までのコンテンツのチャンクが保持されることになる。

次に、図６を用いて、ユーザ端末３０からのコンテンツ配信リクエストを受信したキャッシュサーバ２０の処理手順を説明する。

ユーザ端末３０は、キャッシュサーバ２０へコンテンツ配信リクエストを送信する（Ｓ１１）。キャッシュサーバ２０のリクエスト受信部２４（図４参照）が、コンテンツ配信リクエストを受信すると、コンテンツ配信部２５は、コンテンツ管理テーブル２１３（表５参照）を参照して、リクエストされたコンテンツが登録されているか否かを確認する（Ｓ１２）。コンテンツが登録されていれば（Ｓ１３のＹｅｓ）、コンテンツ配信部２５は、コンテンツ配信リクエストの送信元のユーザ端末３０に対しコンテンツのチャンクの配信を開始する（Ｓ１４）。そして、Ｓ１５へ進む。

一方、Ｓ１３においてコンテンツの登録がなかったとき（Ｓ１３のＮｏ）、オリジンサーバ通信部２２はオリジンサーバ１０に対し、リクエストされたコンテンツのコンテンツリクエストを送信する（Ｓ３１）。そして、コンテンツリクエストを受信したオリジンサーバ１０のコンテンツ送信部１２は、リクエストされたコンテンツのチャンクを配信する（Ｓ３２）。そして、Ｓ１４へ進む。

Ｓ１４の後、キャッシュサーバ２０のコンテンツ再生記録部２６は、コンテンツ管理テーブル２１３（表５参照）における当該コンテンツのアクセス数を１加算する（Ｓ１５）。

そして、コンテンツ配信部２５は、キャッシュサーバ記憶部２１の当該コンテンツのコンテンツチャンク２１１のうち未配信のチャンク数が閾値（後続チャンク要求閾値）以下であるか否かを確認する(Ｓ１６）。つまり、キャッシュサーバ記憶部２１が保持するコンテンツのチャンクが残りわずかか否かを確認する。ここで、未配信のチャンク数が所定の閾値（後続チャンク要求閾値）以下であるとき（Ｓ１６のＹｅｓ）、コンテンツ配信部２５はオリジンサーバ通信部２２経由で、オリジンサーバ１０に対し、続きのチャンク（自身が保持するチャンクの後続チャンク）を要求する（Ｓ１７）。そして、Ｓ１８およびＳ２１へ進む。一方、未配信のチャンク数が所定の閾値（後続チャンク要求閾値）以下ではないとき（Ｓ１６のＮｏ）、Ｓ２１へ進む。

オリジンサーバ１０のコンテンツ送信部１２は、キャッシュサーバ２０からチャンクの要求（リクエスト）を受信すると、要求対象のチャンクをキャッシュサーバ２０へ配信し（Ｓ１８）、キャッシュサーバ２０のオリジンサーバ通信部２２は配信されたチャンクをキャッシュする（Ｓ１９）。つまり、オリジンサーバ通信部２２は、配信されたチャンクをキャッシュ管理部２３経由でキャッシュサーバ記憶部２１に格納する。そして、オリジンサーバ通信部２２はこのチャンクの格納先（キャッシュ格納先）をキャッシュチャンク情報テーブル２１２（表４参照）に登録する（Ｓ２０）。また、このときオリジンサーバ通信部２２は、配信されたチャンクのチャンク情報も、キャッシュチャンク情報テーブル２１２（表４参照）に登録する。そして、処理を終了する。

Ｓ２１において、キャッシュサーバ２０のコンテンツ配信部２５は、ユーザ端末３０からのチャンク要求を受け付けると（Ｓ２１のＹｅｓ）、ユーザ端末３０へチャンクを配信する（Ｓ２２）。そして、Ｓ２３へ進む。一方、コンテンツ配信部２５は、ユーザ端末３０からのチャンク要求がなければ（Ｓ２１のＮｏ）、Ｓ２１へ戻る。Ｓ２３において、キャッシュサーバ２０のキャッシュ管理部２３はコンテンツの最終チャンクまで配信したことを確認すると（Ｓ２３のＹｅｓ）、コンテンツ管理テーブル２１３（表５参照）における当該コンテンツの再生完了数を１加算する（Ｓ２４）。一方、まだコンテンツの最終チャンクまで配信していないとき（Ｓ２３のＮｏ）、Ｓ１６へ戻る。

このようにして、キャッシュサーバ２０はユーザ端末３０へコンテンツのチャンクの配信を行う。

次に、ユーザ端末３０がコンテンツの再生中止をしたときの処理手順を、図７を用いて説明する。ユーザ端末３０がコンテンツの再生中止をすると（Ｓ４１）、ユーザ端末３０はコンテンツの配信元であるキャッシュサーバ２０へ再生中止リクエストまたはセッション終了を通知する。

キャッシュサーバ２０のコンテンツ配信部２５（図４参照）は、ユーザ端末３０からの再生中止リクエストまたはセッション終了を受信、またはセッション断を検出すると、コンテンツの配信を中止する（Ｓ４２）。そして、コンテンツ再生記録部２６は、再生中止、セッション終了またはセッション断時に再生（配信）していたコンテンツのチャンクのチャンク番号を取得し、キャッシュチャンク情報テーブル２１２（表４参照）の該当するチャンク番号の再生中止数を１加算する（Ｓ４３）。

このようにすることで、キャッシュサーバ２０のキャッシュチャンク情報テーブル２１２には、各コンテンツのチャンクのうちどのチャンクまでユーザ端末３０により再生（受信）されたかが記録される。このキャッシュチャンク情報テーブル２１２の情報は、キャッシュ管理部２３がキャッシュサーバ記憶部２１の空き容量が少なくなったとき、優先的に削除するコンテンツチャンク２１１のチャンクを選択するときに参照される。

ここで、キャッシュサーバ２０にオリジンサーバ１０からのチャンクを格納するために必要な空き容量Ｓがないとき、キャッシュ管理部２３は、以下の手順により、空き容量Ｓを確保するまで、該当するチャンクをコンテンツチャンク２１１から削除する。このときの削除手順を、適宜図４を参照しつつ、図８を用いて説明する。なお、ここで用いるパラメータＮ１およびＮ２の初期値はそれぞれ所定の値Ｎ１ｉおよびＮ２ｉ（Ｎ１ｉ≧Ｎ２ｉ）とする。

キャッシュ管理部２３は、コンテンツ管理テーブル２１３（表５参照）およびキャッシュチャンク情報テーブル２１２（表４参照）を参照して、ユーザ端末３０へコンテンツ配信中（コンテンツ配信リクエスト受信〜配信終了までの間）ではなく、かつコンテンツ受信日時から所定時間以上経過しているコンテンツを対象に、優先的に削除するコンテンツのコンテンツチャンク２１１を選択する。まず、コンテンツ管理テーブル２１３およびキャッシュチャンク情報テーブル２１２を参照して、該当コンテンツのコンテンツチャンク２１１のうち、アクセス数＝０のコンテンツの合計チャンクデータ量Ｓ１を計算する（Ｓ５１）。ここで、Ｓ＞Ｓ１であれば（Ｓ５２のＹｅｓ）、該当するデータを削除し、（Ｓ―Ｓ１）をＳの値に設定して（Ｓ５３）、Ｓ５４へ進む。つまり、コンテンツのうち、ユーザ端末３０により一度も視聴されていないコンテンツがあればそのコンテンツを削除する。また、キャッシュサーバ２０が当該コンテンツを配信中か否かがわかるよう、例えばコンテンツ管理テーブル２１３（表５参照）に、当該コンテンツがコンテンツ配信リクエスト受信〜配信終了の間は、コンテンツ配信中フラグ（図示省略）をＯＮにしておく。これにより、キャッシュ管理部２３は、コンテンツ配信中のコンテンツを誤って削除してしまうことを防止できる。なお、以下、キャッシュ管理部２３が、コンテンツチャンク２１１のデータを削除するとき、コンテンツ管理テーブル２１３（表５参照）およびキャッシュチャンク情報テーブル２１２（表４参照）を参照して、ユーザ端末３０へコンテンツ配信中（コンテンツ配信リクエスト受信〜配信終了までの間）のコンテンツは削除対象外とする。

一方、Ｓ＞Ｓ１でなければ（Ｓ５２のＮｏ）、アクセス数＝０のコンテンツを削除する（Ｓ７０）。つまり、キャッシュ管理部２３は、アクセス数＝０のコンテンツのチャンクデータを、コンテンツ受信日時が古いコンテンツから順に削除し、0073-削除したチャンクデータ量をＳから引いた値をＳの値に設定し、Ｓが０以下になるまで、コンテンツ受信日時が古い順にコンテンツの削除を繰り返し、処理を終了する。

Ｓ５４において、キャッシュ管理部２３は、コンテンツ管理テーブル２１３およびキャッシュチャンク情報テーブル２１２を参照して、コンテンツのアクセス数がＮ１以下かつ再生完了数＝０を満たすコンテンツがあれば（Ｓ５４のＹｅｓ）、Ｓ５５の処理を行う。一方、コンテンツのアクセス数がＮ１以下かつ再生完了数＝０を満たすコンテンツがなければ（Ｓ５４のＮｏ）、Ｓ５８へ進む。Ｓ５８については後記する。

Ｓ５５において、キャッシュ管理部２３は、コンテンツ管理テーブル２１３およびキャッシュチャンク情報テーブル２１２を参照して、コンテンツのアクセス数がＮ１以下かつ再生完了数＝０を満たす各コンテンツについて離脱率がβ（所定の値）を超過するチャンク番号ｃを計算する。なお、ここでの離脱率は、当該コンテンツの再生開始から当該チャンクまでの再生中止数の和／当該コンテンツのアクセス数（配信回数）で定義される値である。そして、キャッシュ管理部２３は、すべての対象コンテンツについて、チャンク番号ｃ＋１以降のチャンクの合計データ量Ｓ２を計算し、該当するデータ（つまり、対象コンテンツのチャンク番号ｃ＋１以降のチャンク）を削除し、（Ｓ−Ｓ２）をＳの値に設定する（Ｓ５６）。

Ｓ５６の後、Ｓ＞０であれば（Ｓ５７のＹｅｓ）、Ｓ５８へ進む。一方、Ｓ＞０でなければ（Ｓ５７のＮｏ）、処理を終了する。

Ｓ５８において、キャッシュ管理部２３は、コンテンツ管理テーブル２１３を参照して、コンテンツのアクセス数がＮ１以下かつ再生完了数がＮ２以下を満たすコンテンツがあれば（Ｓ５８のＹｅｓ）、キャッシュ管理部２３は、コンテンツ管理テーブル２１３およびキャッシュチャンク情報テーブル２１２を参照して、各コンテンツについて離脱率がβ（所定の値）を超過するチャンク番号ｃを計算する（Ｓ５９）。一方、Ｓ５８において、コンテンツのアクセス数がＮ１以下かつ再生完了数がＮ２以下を満たすコンテンツがなければ（Ｓ５８のＮｏ）、Ｓ６２へ進む。

Ｓ５９の後、キャッシュ管理部２３は、キャッシュチャンク情報テーブル２１２を参照して、すべての対象コンテンツについて、チャンク番号ｃ＋１以降のチャンクの合計データ量Ｓ３を計算し、該当するデータ（つまり、対象コンテンツのチャンク番号ｃ＋１以降のチャンク）を削除し、（Ｓ−Ｓ３）をＳの値に設定する（Ｓ６０）。

Ｓ６０の後、Ｓ＞０であれば（Ｓ６１のＹｅｓ）、Ｓ６２へ進む。一方、Ｓ＞０でなければ（Ｓ６１のＮｏ）、処理を終了する。

Ｓ６２において、Ｎ１に所定の値Ａ１を加算した値がＮ１ｍａｘ（Ｎ１に設定された最大値）以下ではない場合（Ｓ６２のＮｏ）、キャッシュ管理部２３は、Ｎ２の値を所定の値Ａ２加算して（Ｓ６３）、Ｎ２≦Ｎ１であれば（Ｓ６４のＹｅｓ）、Ｓ５８へ進む。。Ｎ２≦Ｎ１でない場合（Ｓ６４のＮｏ）は、キャッシュ管理部２３は、Ｎ１ｍａｘの値を所定の値Ａ３加算し、Ｎ２の値をＮ２ｉに設定して（Ｓ６５）、Ｓ６２へ戻る。

一方、Ｓ６２において、Ｎ１＋Ａ１がＮ１ｍａｘ（Ｎ１に設定された最大値）以下の場合（Ｓ６２のＹｅｓ）、キャッシュ管理部２３は、Ｎ１の値をＡ１加算して（Ｓ６６）、Ｓ５４へ戻る。

このようにキャッシュサーバ２０は、キャッシュサーバ記憶部２１に空き容量を確保するとき、削除対象のデータとして、コンテンツチャンク２１１のうち、配信回数および再生完了数がより少ないコンテンツから優先的に選択する。そして、キャッシュサーバ２０は、この選択したコンテンツのチャンクのうち、離脱率（当該コンテンツの再生開始から当該チャンクまでの再生中止数の和／当該コンテンツのアクセス数（配信回数））が所定の閾値βを超えている時間以降のチャンクのデータを、オリジンサーバ１０からのコンテンツのデータをキャッシュする空き容量が確保できるまで削除する。これにより、キャッシュサーバ記憶部２１には、ユーザ端末３０により視聴（再生）される可能性が高いチャンクが残ることになるので、キャッシュサーバ２０のキャッシュ効率を向上させることができる。

なお、このような削除対象のデータの選択は、キャッシュサーバ２０のキャッシュ管理部２３が、オリジンサーバ１０から新たなコンテンツのチャンクの配信通知を受信したタイミングで行ってもよいし、チャンクの配信通知とは関係なく、事前に行っておいてもよい。

例えば、キャッシュ管理部２３は、所定期間ごとに、コンテンツ管理テーブル２１３（表５参照）に示される各コンテンツのアクセス数および再生完了数と、キャッシュチャンク情報テーブル２１２（表４参照）に示される各コンテンツのチャンクの再生中止数とを参照して、キャッシュサーバ記憶部２１における空き容量が不足した場合、どのチャンクから優先的に削除すべきかを示したリスト（キャッシュ削除リスト）を事前に作成しておく。

ここで、キャッシュ管理部２３は、優先的に削除すべきデータとして、（１）アクセス数ができるだけ少なく、（２）再生完了数ができるだけ少ないコンテンツを選択する。そして、選択したコンテンツを構成するチャンクのうち、（３）離脱率（当該コンテンツの再生開始から当該チャンクまでの再生中止数の和／当該コンテンツのアクセス数（配信回数））がβとなるチャンクより先のチャンク番号のチャンクを削除対象のチャンクとして選択する。つまり、キャッシュ管理部２３が優先的に削除すべきチャンクの選択にあたり、当該コンテンツの、（１）アクセス数の少なさ、（２）再生完了数の少なさ、（３）離脱率の高さという３つの条件を用いる。ここで、条件適用の優先順位は、例えば、（１）→（２）→（３）とする。

そして、キャッシュ管理部２３は、このようにしてキャッシュ削除リストを作成すると、キャッシュサーバ記憶部２１の所定領域に格納しておく。そして、キャッシュサーバ２０のオリジンサーバ通信部２２は、オリジンサーバ１０からの新たなコンテンツのチャンクを受信する場合において、キャッシュサーバ記憶部２１に空き容量が不足していた場合、このキャッシュ削除リストに示される優先順位に従い、新たなコンテンツのチャンクの分の空き容量を確保できるまで、キャッシュサーバ記憶部２１からチャンクの削除を行う。

このようにすることで、キャッシュサーバ２０は、キャッシュサーバ記憶部２１に新たなコンテンツのチャンクを格納するための空き容量が不足していた場合でも、すぐに空き容量を削除し、コンテンツのチャンクの受信に備えることができる。

なお、前記した実施の形態において、キャッシュサーバ２０が、オリジンサーバ１０に対する後続チャンクの要求時に用いる後続チャンク要求閾値は、各コンテンツについて共通の値を用いてもよいし、コンテンツごとに個別の値を用いるようにしてもよい。個別の値を用いる場合、各コンテンツの後続チャンク要求閾値は、コンテンツ管理テーブル２１３に設定される。

また、オリジンサーバ１０は、破線で示す視聴離脱特性テーブル作成部１３をさらに備えていてもよい。この視聴離脱特性テーブル作成部１３は、オリジンサーバ記憶部１５に格納されるコンテンツ１５１の各キャッシュサーバ２０への配信結果に基づき、コンテンツグループごとの視聴離脱特性を計算し、この計算した視聴離脱特性に基づき視聴離脱特性テーブル１５２を作成する。そして、視聴離脱特性テーブル作成部１３は、所定期間ごとに、各キャッシュサーバ２０へのコンテンツの配信結果に基づき、視聴離脱特性テーブル１５２を更新する。例えば、オリジンサーバ１０がキャッシュサーバ２０からのリクエストに応じてコンテンツのチャンクを配信したとき、コンテンツ情報テーブル１５４に、どのコンテンツについてどのチャンクまで配信したかを記録しておく。そして、視聴離脱特性テーブル作成部１５３は、このコンテンツのチャンクの配信結果に基づき、視聴離脱特性テーブル１５２を作成したり、更新したりする。このようにすることで、視聴離脱特性テーブル１５２にはオリジンサーバ１０からキャッシュサーバ２０へのコンテンツの配信結果を反映させることができる。

１０ オリジンサーバ
１１ 事前キャッシュ対象選択部
１２ コンテンツ送信部
１３ 視聴離脱特性テーブル作成部
１５ オリジンサーバ記憶部
２０ キャッシュサーバ
２１ キャッシュサーバ記憶部
２２ オリジンサーバ通信部
２３ キャッシュ管理部
２４ リクエスト受信部
２５ コンテンツ配信部
２６ コンテンツ再生記録部
３０ ユーザ端末
１５１ コンテンツ
１５２ 視聴離脱特性テーブル
１５３ チャンク情報テーブル
１５４ コンテンツ情報テーブル
２１１ コンテンツチャンク
２１２ キャッシュチャンク情報テーブル
２１３ コンテンツ管理テーブル

Claims (5)

1. ユーザ端末からのリクエストに応じて動画のコンテンツを配信するキャッシュサーバと、前記コンテンツを前記キャッシュサーバへ配信するオリジンサーバとを備えるコンテンツ配信システムであって、
   前記オリジンサーバは、
   前記コンテンツと、前記コンテンツごとに前記コンテンツの属するコンテンツグループを示したコンテンツ情報テーブルと、前記コンテンツのコンテンツグループＧｘごとに、以下の式（１）で定義される視聴離脱率が所定の値αとなる前記コンテンツグループＧｘのコンテンツの再生時間Ｔ（Ｇｘ，α）を示した視聴離脱特性テーブルとを記憶するオリジンサーバ記憶部と、
   コンテンツの再生時間ｔ秒での視聴離脱率＝（当該コンテンツの再生開始時の視聴数―当該コンテンツの再生時間ｔ秒での視聴数）／（当該コンテンツの再生開始時の視聴数）…式（１）
   前記視聴離脱特性テーブルおよび前記コンテンツ情報テーブルを参照して、前記コンテンツグループＧｘのコンテンツのデータのうち、先頭から前記再生時間Ｔ（Ｇｘ，α）を超えるまでのデータを前記キャッシュサーバへ配信するコンテンツ送信部とを備え、
   前記キャッシュサーバは、
   前記配信されたコンテンツのデータを記憶するキャッシュサーバ記憶部と、
   前記ユーザ端末からのリクエストに応じて前記コンテンツのデータを前記リクエストの送信元のユーザ端末へ配信するコンテンツ配信部と、
   前記ユーザ端末からリクエストされた前記コンテンツのデータが前記キャッシュサーバ記憶部にないとき、前記オリジンサーバへ前記コンテンツのデータの配信リクエストを送信するオリジンサーバ通信部とを備えることを特徴とするコンテンツ配信システム。
2. 前記キャッシュサーバ記憶部は、さらに、
   コンテンツ管理テーブルを記憶し、
   前記キャッシュサーバは、さらに、
   前記オリジンサーバからの問い合わせに含まれる配信予定のコンテンツのデータのデータサイズに基づき、前記キャッシュサーバ記憶部に、前記オリジンサーバからのコンテンツのデータをキャッシュする空き容量があるか否かを判断するキャッシュ管理部と、
   前記コンテンツごとの、当該コンテンツの前記ユーザ端末への配信回数および前記ユーザ端末における再生完了数を前記コンテンツ管理テーブルに記録するコンテンツ再生記録部とを備え、
   前記オリジンサーバ通信部は、さらに、
   前記オリジンサーバから、前記キャッシュサーバ記憶部に、前記コンテンツのデータをキャッシュする空き容量があるか否かの問い合わせを受信した場合、前記問い合わせに含まれる配信予定のコンテンツのデータのデータサイズを前記キャッシュ管理部へ出力し、前記キャッシュ管理部により前記コンテンツのデータをキャッシュする空き容量があると判断されたとき、前記オリジンサーバへ前記コンテンツのデータの配信リクエストを送信し、
   前記キャッシュ管理部は、
   前記オリジンサーバからのコンテンツのデータをキャッシュする空き容量がないと判断した場合、削除対象データとして、前記コンテンツ管理テーブルを参照して、既に前記キャッシュサーバ記憶部に記憶されたコンテンツのうち、当該コンテンツの配信回数が少なくかつ再生完了数が少ないコンテンツから優先的に選択し、前記空き容量が確保できるまで、前記選択したコンテンツを削除する処理を繰り返すことを特徴とする請求項１に記載のコンテンツ配信システム。
3. 前記コンテンツ再生記録部は、さらに、
   前記コンテンツの再生中止があった場合、当該コンテンツのどのデータまで再生したかをキャッシュチャンク情報テーブルに記録し、
   前記キャッシュサーバ記憶部は、さらに、
   前記キャッシュチャンク情報テーブルを記憶し、
   前記キャッシュ管理部は、
   前記オリジンサーバからのコンテンツのデータをキャッシュする空き容量がないと判断した場合、削除対象データとして、前記コンテンツ管理テーブルおよび前記キャッシュチャンク情報テーブルを参照して、既に前記キャッシュサーバ記憶部に記憶されたコンテンツから、前記配信回数が０のコンテンツを探し、前記配信回数が０のコンテンツを削除しても、前記空き容量が確保できないとき、当該コンテンツの配信回数および再生完了数がより少ないコンテンツから優先的に選択し、前記選択したコンテンツのデータのうち、以下の式（２）で定義される再生開始からの離脱率が所定の閾値βを超えている時間以降の部分のデータを求め、前記空き容量が確保できるまで、前記求めたデータを削除する処理を繰り返すことを特徴とする請求項２に記載のコンテンツ配信システム。
   当該コンテンツの再生時間t秒での離脱率＝当該コンテンツの再生開始から再生時間t秒までの再生中止数／当該コンテンツの配信回数…式（２）
4. 前記コンテンツ送信部および前記コンテンツ配信部は、前記コンテンツのデータを配信するとき、チャンク形式で配信することを特徴とする請求項１ないし請求項３のいずれか１項に記載のコンテンツ配信システム。
5. ユーザ端末からのリクエストに応じて動画のコンテンツを配信するキャッシュサーバと、前記コンテンツを前記キャッシュサーバへ配信するオリジンサーバとを備えるコンテンツ配信システムにおけるコンテンツ配信方法であって、
   前記コンテンツと、前記コンテンツごとに前記コンテンツの属するコンテンツグループを示したコンテンツ情報テーブルと、前記コンテンツのコンテンツグループＧｘごとに、以下の式（１）で定義される視聴離脱率が所定の値αとなる前記コンテンツグループＧｘのコンテンツの再生時間Ｔ（Ｇｘ，α）を示した視聴離脱特性テーブルとを記憶するオリジンサーバ記憶部を備える前記オリジンサーバが、
   コンテンツの再生時間ｔ秒での視聴離脱率＝（当該コンテンツの再生開始時の視聴数―当該コンテンツの再生時間ｔ秒での視聴数）／（当該コンテンツの再生開始時の視聴数）…式（１）
   前記視聴離脱特性テーブルおよび前記コンテンツ情報テーブルを参照して、前記コンテンツグループＧｘのコンテンツのデータのうち、先頭から前記再生時間Ｔ（Ｇｘ，α）を超えるまでのデータを前記キャッシュサーバへ配信するステップを実行し、
   前記キャッシュサーバは、
   前記配信されたコンテンツのデータをキャッシュサーバ記憶部に記憶するステップと、
   前記ユーザ端末からのリクエストに応じて前記コンテンツのデータを前記リクエストの送信元のユーザ端末へ配信するステップとを実行し、
   前記ユーザ端末からリクエストされた前記コンテンツのデータが前記キャッシュサーバ記憶部にないとき、前記オリジンサーバへ前記コンテンツのデータの配信リクエストを送信するステップを実行することを特徴とするコンテンツ配信方法。

Images