(57)【特許請求の範囲】
【請求項１】
複数のユーザ端末に配信されうるコンテンツを識別するコンテンツ識別情報に対応づけて、該コンテンツが属するジャンルが管理されるコンテンツ情報テーブルと、ユーザ端末に配信されたコンテンツのコンテンツ識別情報が管理される視聴テーブルとを用いて、記憶装置にいずれのコンテンツを蓄積すべきかを選別するコンテンツ管理方法であって、
コンピュータが、
ユーザ端末にコンテンツを配信する毎に、該コンテンツのコンテンツ識別情報を前記視聴テーブルに記録する視聴記録ステップと、
前記視聴テーブルに基づいて、ユーザ端末に配信された全配信回数を算出し、さらに、前記コンテンツ情報テーブルを参照して該視聴テーブルに管理されたコンテンツ識別情報の対応ジャンルを識別し、該視聴テーブルにおける各ジャンルの配信回数を算出することで、コンテンツのジャンルごとに、全配信回数に占める該ジャンルの配信回数の割合で示される視聴傾向を算出する視聴傾向算出ステップと、
前記算出された視聴傾向の多い順に決定される視聴傾向順位が所定の順位より低いジャンルを特定し、所定の削除量に対して該視聴傾向順位によって決定される所定割合を乗算した削除量にしたがって、該特定したジャンルに属するコンテンツを前記記憶装置から削除するコンテンツ削除ステップと、
を備え、
前記視聴傾向算出ステップにおいて、前記コンピュータは、ユーザ端末から要求された前記コンテンツのコンテンツ識別情報に対応づけて、該コンテンツが配信要求時に前記記憶装置に存在したか否かを示すヒット情報が管理されたヒット管理テーブルを参照し、ユーザ端末から要求された全コンテンツに対する該記憶装置に存在した旨のヒット情報を有するコンテンツの割合で示されるヒット率を算出し、該ヒット率が第１の所定値未満である場合に、前記視聴傾向を算出する
ことを特徴とするコンテンツ管理方法。
【請求項２】
前記視聴傾向算出ステップにおいて、前記コンピュータは、前記計算したヒット率が第１の所定値以上ならば、さらに、前記コンテンツ情報テーブルを参照して前記ヒット管理テーブルに管理されたコンテンツ識別情報の対応ジャンルを識別し、ジャンル毎のヒット率を該ヒット管理テーブルから算出し、いずれかのジャンルのヒット率が第２の所定値未満となる場合に、前記視聴傾向を算出する
ことを特徴とする請求項１記載のコンテンツ管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータネットワークを介して、映像などのコンテンツを配信するキャッシュサーバのコンテンツ管理技術に関する。
【０００２】
【従来の技術】
近年、インターネットなどのコンピュータネットワークを介して、映像などのコンテンツを配信する「ストリーミング配信サービス」が普及しつつある。ストリーミング配信サービスでは、１つの配信サーバのみでは、膨大な配信要求に対応できないことから、ユーザの近くに「キャッシュサーバ」を設置することが多い。キャッシュサーバは、配信サーバから事前配布されたオリジナルコンテンツのコピーを蓄積し、ユーザからの配信要求に応じて蓄積されたコピーコンテンツを配信する。そして、配信要求ごとにオリジナルコンテンツへアクセスするという無駄を回避し、レスポンスの向上とトラフィックの低減を図っている。
【０００３】
【発明が解決しようとする課題】
しかしながら、全てのキャッシュサーバに対して、一律同じコピーコンテンツが事前配布されていたので、その担当エリアによっては、キャッシュへのヒット率が低くなってしまい、キャッシュサーバが有効に活用されているとは言い難かった。
【０００４】
そこで、本発明は以上のような従来の問題点に鑑み、視聴状況に応じて、キャッシュサーバに蓄積されるコンテンツを動的に変更することで、キャッシュへのヒット率を向上させ、キャッシュサーバが有効に活用されるようにしたキャッシュサーバのコンテンツ管理技術を提供することを目的とする。
【０００５】
【課題を解決するための手段】
このため、本発明に係るキャッシュサーバのコンテンツ管理技術では、キャッシュサーバに蓄積された全コンテンツに対するヒット率が第１の所定値未満になったときに、コンテンツが属するジャンルごとの視聴傾向が低いジャンルに属するコンテンツをキャッシュサーバから削除すると共に、視聴傾向が高いジャンルに属するコンテンツをキャッシュサーバに事前配布することを特徴とする。
【０００６】
かかる構成によれば、キャッシュサーバに蓄積された全コンテンツに対するヒット率が低下したときには、各ジャンルごとの視聴傾向に応じて、視聴傾向の低いジャンルに属するコンテンツが削除される一方、視聴傾向の高いジャンルに属するコンテンツが事前配布される。このため、キャッシュサーバに蓄積されるコンテンツは、視聴傾向に応じて動的に入れ替えられることとなり、そのキャッシュへのヒット率が向上される。
【０００７】
また、全コンテンツに対するヒット率が第１の所定値以上であっても、キャッシュサーバに蓄積されたコンテンツが属するジャンルごとのヒット率が第２の所定値未満のジャンルに属するコンテンツをキャッシュサーバから削除すると共に、視聴傾向が高いジャンルに属するコンテンツをキャッシュサーバに事前配布するようにしてもよい。このとき、第２の所定値は、第１の所定値より小に設定されていることが望ましい。
【０００８】
かかる構成によれば、全コンテンツに対するヒット率が第１の所定値以上であっても、ジャンルごとのヒット率が第２の所定値未満のジャンルに属するコンテンツがキャッシュサーバから削除される。このため、第２の所定値を第１の所定値より小に設定することで、視聴率の高いコンテンツに影響を受け、視聴率の低いコンテンツがなかなか削除されないという不具合が回避される。
【０００９】
そして、キャッシュサーバからコンテンツを削除するときには、削除対象たるジャンルに属するコンテンツの中から、その優先度が下位のコンテンツを削除するようにすればよい。一方、キャッシュサーバにコンテンツを事前配布するときには、事前配布対象たるジャンルに属するコンテンツの中から、その優先度が高いコンテンツを事前配布するようにすればよい。このとき、優先度として、コンテンツの視聴率を用いることが望ましい。
【００１０】
かかる構成によれば、コンテンツの優先度に応じて、削除又は事前配布するコンテンツが決定されるので、キャッシュへのヒット率を効果的に向上させることができる。このとき、優先度として、コンテンツの視聴率を用いれば、実際の視聴状況を反映したコンテンツの入れ換えが行われる。
また、キャッシュサーバに蓄積されるコンテンツを入れ換えるときには、キャッシュサーバの容量の所定割合を入れ替えるようにすればよい。このとき、コンテンツの視聴傾向に応じて、入替容量を削除又は事前配布するジャンルに振り分けることが望ましい。
【００１１】
かかる構成によれば、キャッシュサーバに蓄積されるコンテンツの一定割合が入れ換えられることとなる。このため、入れ替えに要する時間が短縮され、エンドユーザに対するサービスの質の低下が抑制される。このとき、コンテンツの視聴傾向に応じて、入替容量を削除又は事前配布するジャンルに振り分けるようにすれば、視聴傾向を考慮した効果的なコンテンツの入れ替えが行われる。
【００１２】
【発明の実施の形態】
以下、添付された図面を参照して本発明を詳述する。
図１は、本発明を具現化したキャッシュサーバのコンテンツ管理装置（以下「コンテンツ管理装置」という）を備えた、ストリーミング配信システム（以下「配信システム」という）の一実施形態を示す。
【００１３】
配信システムは、インターネットなどのコンピュータネットワーク１０を介して相互接続される、１つのセンタ局２０と、所定エリア毎に設置されるローカル局３０と、エンドユーザのクライアント４０と、を含んで構成される。センタ局２０には、オリジナルコンテンツを蓄積する配信サーバ２０Ａが備えられる一方、ローカル局３０には、センタ局２０から配布されたオリジナルコンテンツのコピー（コピーコンテンツ）を蓄積するキャッシュサーバ３０Ａが備えられる。また、エンドユーザのクライアント４０には、コンテンツを視聴するためのプレーヤーがインストールされる。なお、配信サーバ２０Ａ，キャッシュサーバ３０Ａ及びクライアント４０は、少なくとも中央処理装置（ＣＰＵ）とメモリとを備えたコンピュータから構築され、メモリにロードされたプログラムにより、コンテンツ配信のための各種機能が実現される。
【００１４】
コンテンツ配信方式としては、「リダイレクション方式」と「キャッシュサーバ方式」とがある。リダイレクション方式とは、エンドユーザからのコンテンツ配信要求をセンタ局２０が受け付け、コンテンツの配信を最適なローカル局に振り分ける方式のことをいう。一方、キャッシュサーバ方式とは、エンドユーザからのコンテンツ配信要求をローカル局３０が受け付け、そのキャッシュサーバ３０Ａにコンテンツがなかったときには、センタ局２０からコンテンツの配布を受けた後、コンテンツを配信する方式のことをいう。
【００１５】
図２及び図３は、リダイレクション方式の配信システムにおいて、各ローカル局３０ごとに、エンドユーザの視聴情報を登録する構成及び手順を示す。センタ局２０には、図１の構成に加え、管理ＤＢ（データベース）２０Ｂ及びリダイレクタ２０Ｃが備えられる。なお、リダイレクタ２０Ｂは、少なくとも中央処理装置（ＣＰＵ）とメモリとを備えたコンピュータから構築され、メモリにロードされたプログラムにより、コンテンツ配信のための各種機能が実現される。
【００１６】
管理ＤＢ２０Ｂには、図４（Ａ）〜（Ｃ）に夫々示すように、加入者情報テーブルと、コンテンツ情報テーブルと、視聴情報テーブルと、が登録される。加入者情報テーブルは、同図（Ａ）に示すように、コンテンツ配信を受けるエンドユーザの加入者名と、所属するエリアを特定する所属ローカルエリアと、を含んで構成される。コンテンツ情報テーブルは、同図（Ｂ）に示すように、コンテンツ名と、その所属ジャンルと、ファイルサイズ（ＧＢ：Giga Bytes）と、コンテンツ長（分）と、を含んで構成される。視聴情報テーブルは、同図（Ｃ）に示すように、コンテンツ名と、視聴者名と、視聴開始時刻と、視聴終了時刻と、を含んで構成される。一方、リダイレクタ２０Ｃでは、エンドユーザからコンテンツ配信要求を受け付け、コンテンツの配信を最適なローカル局３０に振り分ける機能が奏される。
【００１７】
エンドユーザのクライアント４０からセンタ局２０のリダイレクタ２０Ｃに対して、ユーザ情報及びコンテンツ名を含んだ配信要求があると（手順(1)）、ユーザ情報及びコンテンツ名に基づいて、コンテンツ配信に最適な配信サーバが決定され、これがクライアント４０に通知される（手順(2)）。ここで、コンテンツ配信に最適な配信サーバとは、センタ局２０の配信サーバ２０Ａ又はローカル局３０のキャッシュサーバ３０Ａのどちらかのことを意味する。
【００１８】
そして、要求コンテンツがローカル局３０のキャッシュサーバ３０Ａにあれば、図３のＡに示すように、そのキャッシュサーバ３０Ａに対してコンテンツ要求がなされ（手順(3)）、そこからコンテンツの配信を受ける（手順(6)）。この際、キャッシュサーバ３０Ａからリダイレクタ２０Ｃに対して、視聴開始通知が送信される（手順(4)）。視聴開始通知を受け取ったリダイレクタ２０Ｃでは、視聴情報としてコンテンツ名，視聴者名，視聴開始時刻が取得され、管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(5)）。コンテンツの配信完了時には、キャッシュサーバ３０Ａからリダイレクタ２０Ｃに対して、視聴終了通知が送信される（手順(7)）。視聴終了通知を受け取ったリダイレクタ２０Ｃでは、視聴情報としての視聴終了時刻が取得され、これが管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(8)）。
【００１９】
一方、要求コンテンツがローカル局３０のキャッシュサーバ３０Ａになければ、同図Ｂに示すように、センタ局２０の配信サーバ２０Ａに対してコンテンツ要求がなされ（手順(3)）、そこからコンテンツの配信を受ける（手順(6)）。この際、配信サーバ２０Ａからリダイレクタ２０Ｃに対して、視聴開始通知が送信される（手順(4)）。視聴開始通知を受け取ったリダイレクタ２０Ｃでは、視聴情報としてコンテンツ名，視聴者名，視聴開始時刻が取得され、管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(5)）。コンテンツの配信完了時に、配信サーバ２０Ａからリダイレクタ２０Ｃに対して、視聴終了通知が送信される（手順(7)）。視聴終了通知を受け取ったリダイレクタ２０Ｃでは、視聴情報としての視聴終了時刻が取得され、これが管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(8)）。
【００２０】
エンドユーザによってコンテンツの配信の一時停止及び再開始が行われるときには、配信の完了及び開始と同様に扱い、コンテンツの配信の一時停止時に、キャッシュサーバ３０Ａ（あるいは配信サーバ２０Ａ）からリダイレクタ２０Ｃに対して、視聴終了通知が送信される（手順(7)）。視聴終了通知を受け取ったリダイレクタ２０Ｃでは、視聴情報としての視聴終了時刻が取得され、これが管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(8)）。コンテンツの配信再開始時には、改めてキャッシュサーバ３０Ａ（あるいは配信サーバ２０Ａ）からリダイレクタ２０Ｃに対して、視聴開始通知が送信される（手順(4)）。視聴開始通知を受け取ったリダイレクタ２０Ｃでは、視聴情報としてコンテンツ名，視聴者名，視聴開始時刻が取得され、管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(5)）。
【００２１】
図５及び図６は、キャッシュサーバ方式の配信システムにおいて、各ローカル局３０ごとに、エンドユーザの視聴情報を登録する構成及び手順を示す。ローカル局３０には、図１の構成に加え、管理ＤＢ３０Ｂが備えられる。なお、管理ＤＢ３０Ｂには、リダイレクション方式の配信システムと同様に、加入者情報テーブルと、コンテンツ情報テーブルと、視聴情報テーブルと、が登録される。
【００２２】
エンドユーザのクライアント４０からローカル局３０のキャッシュサーバ３０Ａに対して、ユーザ情報及びコンテンツ名を含んだ配信要求があると（手順(1)）、そこから視聴情報としてのコンテンツ名，視聴者名及び視聴開始時刻が取得される。そして、キャッシュサーバ３０Ａに要求コンテンツがなければ、図中点線で示すように、センタ局２０の配信サーバ２０Ａに対してコンテンツ要求がなされ、そこからコンテンツの配信を受ける。その後、視聴情報が管理ＤＢ３０Ｂの視聴情報テーブルに登録され（手順(2)）、クライアント４０に対してコンテンツが配信される（手順(3)）。
【００２３】
コンテンツの配信が完了すると、キャッシュサーバ３０Ａでは、視聴情報としての視聴終了時刻が取得され、これが管理ＤＢ３０Ｂの視聴情報テーブルに登録される（手順(4)）。
エンドユーザによってコンテンツの配信の一時停止及び再開始が行われるときには、配信の完了及び開始と同様に扱い、コンテンツの配信の一時停止時に、キャッシュサーバ３０Ａでは、視聴情報としての視聴終了時刻が取得され、これが管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(4)）。コンテンツの配信再開始時には、改めてキャッシュサーバ３０Ａでは、視聴情報としてコンテンツ名，視聴者名，視聴開始時刻が取得され、管理ＤＢ２０Ｂの視聴情報テーブルに登録される（手順(2)）。
【００２４】
このように、リダイレクション方式又はキャッシュサーバ方式の配信システムにおいて、エンドユーザに対してコンテンツの配信が行われるたびに、コンテンツ名，視聴者名，視聴開始時間及び視聴終了時間を含んで構成される視聴情報が登録される。そして、登録された視聴情報に基づいて、キャッシュへのヒット率が向上するように、キャッシュサーバ３０Ａのコンテンツが動的に変更される。ここで、「ヒット率」とは、エンドユーザからの要求コンテンツがキャッシュサーバ３０Ａにある確率のことをいう。従って、ヒット率が高ければ、キャッシュサーバ３０Ａが有効活用されていることとなる。
【００２５】
図７及び図８は、リダイレクション方式の配信システムにおいて、キャッシュサーバ３０Ａのコンテンツを動的に変更する構成及び手順を示す。センタ局２０には、図１の構成に加え、管理ＤＢ２０Ｂ，ヒット率管理サーバ２０Ｄ及び配布管理サーバ２０Ｅが備えられる。なお、ヒット率管理サーバ２０Ｄ及び配布管理サーバ２０Ｅは、少なくとも中央処理装置（ＣＰＵ）とメモリとを備えたコンピュータから構築され、メモリにロードされたプログラムにより、コンテンツ管理のための各種機構が実現される。但し、配信サーバ２０Ａに余裕があれば、ヒット率管理サーバ２０Ｄ及び配布管理サーバ２０Ｅの機能を兼備させ、構成の簡略化を図るようにしてもよい。
【００２６】
ヒット率管理サーバ２０Ｄでは、所定間隔（例えば、１時間）ごとにヒット率が算出され、これが所定値未満に低下すると、配布管理サーバ２０Ｅに対してヒット率低下通知が送信される（手順(1)）。ヒット率低下通知を受け取った配布管理サーバ２０Ｅでは、管理ＤＢ２０Ｂに対して視聴情報要求がなされ（手順(2)）、その視聴情報テーブルから視聴情報が取得される（手順(3)）。
【００２７】
配布管理サーバ２０Ｅでは、取得した視聴情報に基づいて、各ローカル局３０ごとに、エンドユーザの視聴傾向が算出される。ここで、「視聴傾向」とは、各ジャンルごとに、そこに属するコンテンツがどの程度視聴されているかを、全視聴に対する割合（％）で示した指標のことをいう。
そして、配布管理サーバ２０Ｅでは、視聴傾向の低いジャンルに属するコンテンツの中から、視聴率が低いコンテンツを削除すべく、削除対象たるコンテンツ名を含んだ削除要求が配信サーバ２０Ａに送信される（手順(4)）。削除要求を受け取った配信サーバ２０Ａでは、削除要求がローカル局３０のキャッシュサーバ３０Ａに転送される（手順(5)）。削除要求を受け取ったキャッシュサーバ３０Ａでは、そのストレージから削除要求に係るコンテンツが削除される。
【００２８】
また、配布管理サーバ２０Ｅでは、視聴傾向の高いジャンルに属するコンテンツの中から、視聴率が高いコンテンツを事前配布すべく、配布対象たるコンテンツ名を含んだ配布要求が配信サーバ２０Ａに送信される（手順(6)）。配布要求を受け取った配信サーバ２０Ａでは、配布要求に係るコンテンツがキャッシュサーバ３０Ａに事前配布される（手順(7)）。
【００２９】
図９及び図１０は、キャッシュサーバ方式の配信システムにおいて、キャッシュサーバ３０Ａのコンテンツを動的に変更する構成及び手順を示す。ローカル局３０には、図１の構成に加え、管理ＤＢ３０Ｂ，ヒット率管理サーバ３０Ｃ及び配布管理サーバ３０Ｄが備えられる。
ヒット率管理サーバ３０Ｃでは、所定間隔（例えば、１時間）ごとにヒット率が算出され、これが所定値未満に低下すると、配布管理サーバ３０Ｄに対してヒット率低下通知が送信される（手順(1)）。ヒット率低下通知を受け取った配布管理サーバ３０Ｄでは、管理ＤＢ３０Ｂに対して視聴情報要求がなされ（手順(2)）、その視聴情報テーブルから視聴情報が取得される（手順(3)）。
【００３０】
配布管理サーバ３０Ｄでは、取得した視聴情報に基づいて、各ローカル局３０ごとに、エンドユーザの視聴傾向が算出される。そして、視聴傾向の低いジャンルに属するコンテンツの中から、視聴率が低いコンテンツを削除すべく、削除対象たるコンテンツ名を含んだ削除要求がキャッシュサーバ３０Ａに送信される（手順(4)）。削除要求を受け取ったキャッシュサーバ３０Ａでは、そのストレージから削除要求に係るコンテンツが削除される。
【００３１】
また、配布管理サーバ３０Ｄでは、視聴傾向の高いジャンルに属するコンテンツの中から、視聴率が高いコンテンツを事前配布すべく、配布対象たるコンテンツ名を含んだ配布要求がキャッシュサーバ３０Ａに送信される（手順(5)）。配布要求を受け取ったキャッシュサーバ３０Ａでは、これをセンタ局２０の配信サーバ２０Ａに転送し（手順(6)）、配布要求に係るコンテンツを受け取る（手順(7)）。
【００３２】
以上説明したリダイレクション方式又はキャッシュサーバ方式の配信システムは、図１１〜図１３に示す処理によって動作する。なお、以下の説明では、説明の都合上、リダイレクション方式の配信システムの符号を用い、ヒット率判定に用いる所定値も例示としての値を用いることとする。
メインルーチンを示す図１１において、ステップ１（図では「Ｓ１」と略記する。以下同様）では、ヒット率管理サーバ２０Ｄにて所定間隔ごとに、各ローカル局３０におけるヒット率ｘ（％）が算出される。即ち、各ローカル局３０ごとに、管理ＤＢ２０Ｂのコンテンツ情報テーブル及び視聴情報テーブルが参照され、図１４に示すように、視聴要求に係るコンテンツ名，ファイルサイズ（ＧＢ），要求回数，合計ファイルサイズ（ＧＢ），キャッシュヒットの有無（○×）及びキャッシュヒットしたファイルサイズ（ＧＢ）が設定されたテーブルが作成される。そして、以下の計算式により、各ローカル局３０ごとのヒット率ｘが算出される。なお、図示の例では、ヒット率ｘ＝32,000÷80,000×100＝40（％）となる。ここで、ステップ１の処理が、夫々、第１のヒット率算出手段，ヒット率算出機能及びヒット率算出工程に該当する。
【００３３】
【数１】
0003999004.tif 000002
ステップ２では、ヒット率ｘが５０％未満であるか否かが判定される。そして、ヒット率ｘが５０％未満であればステップ３へと進み（Ｙｅｓ）、ヒット率ｘが５０％以上であればステップ６へと進む（Ｎｏ）。
【００３４】
ステップ３では、管理ＤＢ２０Ｂの視聴情報テーブルが参照され、各ローカル局３０における視聴情報が取得される。
ステップ４では、取得された視聴情報に基づいて、各ジャンルごとの視聴傾向が算出され、図１５に示すように、視聴傾向を降順にソートしたランキングテーブルが作成される。ここで、ステップ３及びステップ４の処理が、夫々、視聴傾向算出手段，視聴傾向算出機能及び視聴傾向算出工程に該当する。
【００３５】
ステップ５では、各ジャンルごとの視聴傾向に基づいて、キャッシュサーバ３０Ａから削除するコンテンツが属する削除対象ジャンルが選別される。即ち、図１５に示すランキングテーブルが参照され、例えば、視聴傾向が下位の５ジャンルが削除対象ジャンルとして選別される。図示の例では、削除対象ジャンルとして、アニメ，教育，料理，経済及び時代劇が選別される。このとき、削除対象ジャンルに属する全コンテンツを削除するのではなく、ローカル局３０のストレージ容量の所定割合を入れ替えるべく、下位１〜５位のジャンルから、例えば、入替容量の４０％，２５％，１５％，１０％及び１０％ずつ削除することが望ましい。ランキングテーブルの入替コンテンツ容量は、入替容量（＋；配布、−；削除）を示す。
【００３６】
ステップ６では、ヒット率管理サーバ２０Ｄにて、各ジャンルごとのヒット率ｙ（％）が算出される。即ち、各ローカル局３０ごとに、管理ＤＢ２０Ｂのコンテンツ情報テーブル及び視聴情報テーブルが参照され、図１６に示すように、視聴要求に係るコンテンツが属するジャンル名，要求コンテンツのファイルサイズ合計（ＧＢ）及びキャッシュヒットしたファイルサイズ（ＧＢ）が設定されたテーブルが作成される。そして、以下の計算式により、各ジャンルごとのヒット率ｙが算出される。なお、図示の例では、アニメのヒット率ｙ＝2,000÷10,000×100＝20（％）となる。ここで、ステップ６の処理が、第２のヒット率算出手段に該当する。
【００３７】
【数２】
0003999004.tif 000003
ステップ７では、各ジャンルごとのヒット率ｙに基づいて、キャッシュサーバ３０Ａから削除するコンテンツが属する削除対象ジャンルが選別される。即ち、ヒット率ｙが、例えば、３０％未満のジャンルが削除対象ジャンルとして選別される。図示の例では、削除対象ジャンルとして、アニメが選別される。このとき、削除対象ジャンルに属する全コンテンツを削除するのではなく、そのジャンルに属するコンテンツの所定割合（例えば、３０％）を削除することが望ましい。
【００３８】
ステップ８では、削除対象ジャンルがあるか否かが判定される。そして、削除対象ジャンルがあればステップ９へと進み（Ｙｅｓ）、削除対象ジャンルがなければ処理を終了する（Ｎｏ）。
ステップ９では、管理ＤＢ２０Ｂの視聴情報テーブルが参照され、各ローカル局３０における視聴情報が取得される。
【００３９】
ステップ１０では、取得された視聴情報に基づいて、各ジャンルごとの視聴傾向が算出され、図１５に示すように、視聴傾向を降順にソートしたランキングテーブルが作成される。ここで、ステップ９及びステップ１０の処理が、夫々、視聴傾向算出手段，視聴傾向算出機能及び視聴傾向算出工程に該当する。
ステップ１１では、選別された各削除対象ジャンルについて、コンテンツ削除処理を実行するサブルーチン（図１２参照）がコールされる。
【００４０】
ステップ１２では、各ジャンルごとの視聴傾向に基づいて、キャッシュサーバ３０Ａに事前配布するコンテンツが属する配布対象ジャンルが選別される。即ち、図１５に示すランキングテーブルが参照され、例えば、視聴傾向が上位の５ジャンルが配布対象ジャンルとして選別される。図示の例では、配布対象ジャンルとして、映画，スポーツ，ニュース，音楽及び旅行が選別される。このとき、配布対象ジャンルに属する全コンテンツを配布するのではなく、ローカル局３０のストレージ容量の所定割合を入れ替えるべく、上位１〜５位のジャンルから、例えば、入替容量の４０％，２５％，１５％，１０％及び１０％ずつ事前配布することが望ましい。
【００４１】
ステップ１３では、選別された各配布対象ジャンルについて、コンテンツ配布処理を実行するサブルーチン（図１３参照）がコールされる。
ここで、ステップ２，ステップ５，ステップ７，ステップ８，ステップ１１〜ステップ１３の一連の処理が、夫々、コンテンツ入替手段，コンテンツ入替機能及びコンテンツ入替工程に該当する。
【００４２】
図１２は、コンテンツ削除処理を実行するサブルーチンを示す。
ステップ２１では、管理ＤＢ２０Ｂが参照され、図１７に示すように、削除対象ジャンルにおける優先リストが取得される。優先リストは、コンテンツ名，視聴率（％）及びファイルサイズ（ＧＢ）を含んで構成され、各コンテンツの視聴率に応じて随時又は適宜更新される。ここで、視聴率は、次式により算出される。なお、優先リストに、ストリーミング配信サービスの運用者の意図などを反映させるようにしてもよい。
【００４３】
【数３】
0003999004.tif 000004
ステップ２２では、削除総量（ＧＢ）を示す変数ｚが０に初期化される。
ステップ２３では、削除総量ｚが削除容量以下であるか否かが判定される。ここで、削除容量としては、例えば、品川局のストレージ容量が１，０００ＧＢの場合、その３０％に相当する３００ＧＢに対して、順位に応じた入替コンテンツ容量（図１５参照）を乗算した値とする。なお、図示の例では、アニメの削除容量として、３００×０．４０＝１２０（ＧＢ）が用いられる。そして、削除総量ｚが削除容量以下であればステップ２４へと進み（Ｙｅｓ）、削除総量ｚが削除容量より大であればメインルーチンへ戻る（Ｎｏ）。
【００４４】
ステップ２４では、図１７に示す優先リストの最下位コンテンツから、コンテンツが順次削除される。即ち、最初の処理においては「セーラームーン」が、２回目の処理においては「ガンダム」が、３回目の処理においては「ちびまる子ちゃん」が、というように削除される。
ステップ２５では、現在の削除総量ｚに対して、次に削除するコンテンツのファイルサイズが加算された削除総量ｚが算出される。その後、ステップ２３へと戻り、次のコンテンツの削除処理が続行される。
【００４５】
図１３は、コンテンツ配布処理を実行するサブルーチンを示す。
ステップ３１では、管理ＤＢ２０Ｂが参照され、図１８に示すように、配布対象ジャンルにおける優先リストが取得される。
ステップ３２では、配布総量（ＧＢ）を示す変数ｚが０に初期化される。
ステップ３３では、現在の配布総量ｚに対して、次に配布しようとするコンテンツのファイルサイズが加算された配布総量ｚが算出される。即ち、図１８に示す優先リストを例にとると、最初の処理においては「ハリーポッター」のファイルサイズ４０（ＧＢ）が、２回目の処理においては「千と千尋の神隠し」のファイルサイズ３０（ＧＢ）が、というように加算される。
【００４６】
ステップ３４では、配布総量ｚが配布容量以下であるか否かが判定される。ここで、配布容量としては、例えば、品川局のストレージ容量が１，０００ＧＢの場合、その３０％に相当する３００ＧＢに対して、順位に応じた入替コンテンツ容量（図１５参照）を乗算した値とする。なお、図示の例では、映画の配布容量として、３００×０．４０＝１２０（ＧＢ）が用いられる。そして、配布総量ｚが配布容量以下であればステップ３５へと進み（Ｙｅｓ）、配布総量ｚが配布容量より大であればメインルーチンへ戻る（Ｎｏ）。
【００４７】
ステップ３５では、図１８に示す優先リストの最上位コンテンツから、コンテンツが順次配布される。即ち、最初の処理においては「ハリーポッター」が、２回目の処理においては「千と千尋の神隠し」が、３回目の処理においては「エピソード１」が、というように配布される。その後、ステップ３３へと戻り、次のコンテンツの配布処理が続行される。
【００４８】
以上説明した図１１〜図１３の処理によれば、各ローカル局３０において、全コンテンツに対するヒット率が低下したとき、又は、各ジャンルに対するヒット率が低下したときに、キャッシュサーバ３０Ａに蓄積されたコンテンツの一部が入れ替えられる。このとき、全コンテンツに対するヒット率の低下だけではなく、各ジャンルに対するヒット率の低下をコンテンツ入替契機とすることで、視聴率の高いコンテンツに影響を受け、視聴率の低いコンテンツがなかなか削除されないという不具合を回避することができる。
【００４９】
そして、コンテンツの一部を入れ替えるときには、全コンテンツに対するヒット率の低下を契機とする場合、各ジャンルごとの視聴傾向に応じて、視聴傾向の低いジャンルに属するコンテンツが削除される一方、視聴傾向の高いジャンルに属するコンテンツが事前配布される。このとき、視聴傾向の順位に応じて、削除又は事前配布されるコンテンツの容量が決定される。また、削除対象又は配布対象たるコンテンツは、そのジャンルにおける視聴率に応じて決定される。
【００５０】
各ジャンルに対するヒット率の低下を契機とする場合、ヒット率が所定値未満のジャンルに属するコンテンツが削除される一方、視聴傾向の高いジャンルが事前配布される。このとき、削除又は事前配布されるコンテンツの容量は、削除対象ジャンルに属するコンテンツの所定割合とすればよい。また、削除対象又は配布対象たるコンテンツは、全コンテンツに対するヒット率の低下を契機とする場合と同様に、そのジャンルにおける視聴率に応じて決定される。
【００５１】
従って、キャッシュサーバ３０Ａから視聴傾向又はヒット率及び視聴率が低いコンテンツが削除される一方、キャッシュサーバ３０Ａに視聴傾向及び視聴率が高いコンテンツが事前配布されることとなり、そのキャッシュへのヒット率を向上させることができる。そして、ヒット率の向上により、キャッシュサーバ３０Ａが最大限に活用され、レスポンスの向上とトラフィックの低減とが促進される。
【００５２】
このような機能を実現するプログラムを、例えば、磁気テープ，磁気ディスク，磁気ドラム，ＩＣカード，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等のコンピュータ読取可能な記録媒体に記録しておけば、本発明に係るコンテンツ管理プログラムを市場に流通させることができる。そして、かかる記録媒体を取得した者は、一般的なコンピュータシステムを利用して、本発明に係るコンテンツ管理装置を容易に構築することができる。
【００５３】
（付記１）コンテンツに対するヒット率を算出する第１のヒット率算出手段と、コンテンツの視聴情報に基づいて、コンテンツが属するジャンルごとの視聴傾向を算出する視聴傾向算出手段と、前記第１のヒット率算出手段により算出されたヒット率が第１の所定値未満になったときに、前記視聴傾向算出手段により算出された視聴傾向が低いジャンルに属するコンテンツを削除すると共に、視聴傾向が高いジャンルに属するコンテンツを事前配布するコンテンツ入替手段と、を含んで構成されたことを特徴とするコンテンツ管理装置。
【００５４】
（付記２）蓄積されたコンテンツが属するジャンルごとに、そのヒット率を算出する第２のヒット率算出手段を備え、前記コンテンツ入替手段は、前記第１のヒット率算出手段により算出されたヒット率が第１の所定値以上であっても、前記第２のヒット率算出手段により算出されたヒット率が第２の所定値未満のジャンルに属するコンテンツを削除すると共に、前記視聴傾向算出手段により算出された視聴傾向が高いジャンルに属するコンテンツを事前配布することを特徴とする付記１記載のコンテンツ管理装置。
【００５５】
（付記３）前記第２の所定値は、前記第１の所定値より小に設定されていることを特徴とする付記２記載のコンテンツ管理装置。
【００５６】
（付記４）前記コンテンツ入替手段は、削除対象たるジャンルに属するコンテンツの中から、その優先度が下位のコンテンツを削除することを特徴とする付記１〜付記３のいずれか１つに記載のコンテンツ管理装置。
【００５７】
（付記５）前記コンテンツ入替手段は、事前配布対象たるジャンルに属するコンテンツの中から、その優先度が高いコンテンツを事前配布することを特徴とする付記１〜付記４のいずれか１つに記載のコンテンツ管理装置。
【００５８】
（付記６）前記優先度は、コンテンツの視聴率であることを特徴とする付記４又は付記５に記載のコンテンツ管理装置。
【００５９】
（付記７）前記コンテンツ入替手段は、前記キャッシュサーバの容量の所定割合を入れ替えることを特徴とする付記１〜付記６のいずれか１つに記載のコンテンツ管理装置。
【００６０】
（付記８）前記コンテンツ入替手段は、前記視聴傾向に応じて、前記入替容量を削除又は事前配布するジャンルに割り振ることを特徴とする付記７記載のコンテンツ管理装置。
【００６１】
（付記９）コンテンツに対するヒット率を算出するヒット率算出機能と、コンテンツの視聴情報に基づいて、コンテンツが属するジャンルごとの視聴傾向を算出する視聴傾向算出機能と、前記ヒット率算出機能により算出されたヒット率が所定値未満になったときに、前記視聴傾向算出機能により算出された視聴傾向が低いジャンルに属するコンテンツを削除すると共に、視聴傾向が高いジャンルに属するコンテンツを事前配布するコンテンツ入替機能と、をコンピュータに実現させるためのコンテンツ管理プログラム。
【００６２】
（付記１０）コンテンツに対するヒット率を算出するヒット率算出機能と、コンテンツの視聴情報に基づいて、コンテンツが属するジャンルごとの視聴傾向を算出する視聴傾向算出機能と、前記ヒット率算出機能により算出されたヒット率が所定値未満になったときに、前記視聴傾向算出機能により算出された視聴傾向が低いジャンルに属するコンテンツを削除すると共に、視聴傾向が高いジャンルに属するコンテンツを事前配布するコンテンツ入替機能と、をコンピュータに実現させるためのコンテンツ管理プログラムを記録したコンピュータ読取可能な記録媒体。
【００６３】
（付記１１）コンテンツに対するヒット率を算出するヒット率算出工程と、コンテンツの視聴情報に基づいて、コンテンツが属するジャンルごとの視聴傾向を算出する視聴傾向算出工程と、前記ヒット率算出工程により算出されたヒット率が所定値未満になったときに、前記視聴傾向算出工程により算出された視聴傾向が低いジャンルに属するコンテンツを削除すると共に、視聴傾向が高いジャンルに属するコンテンツを事前配布するコンテンツ入替工程と、を備えたことを特徴とするコンテンツ管理方法。
【００６４】
【発明の効果】
以上説明したように、本発明に係るコンテンツ管理技術によれば、キャッシュサーバに蓄積された全コンテンツに対するヒット率が低下したときには、各ジャンルごとの視聴傾向に応じて、視聴傾向の低いジャンルに属するコンテンツが削除される一方、視聴傾向の高いジャンルに属するコンテンツが事前配布される。このため、キャッシュサーバに蓄積されるコンテンツは、視聴傾向に応じて動的に入れ替えられることとなり、そのキャッシュへのヒット率を向上させることができる。そして、ヒット率の向上により、キャッシュサーバが最大限に活用され、レスポンスの向上とトラフィックの低減とを促進することができる。
【図面の簡単な説明】
【図１】本発明に係るコンテンツ管理装置を備えた配信システムの構成図
【図２】リダイレクション方式により視聴情報を登録するための構成図
【図３】同上における視聴情報登録処理の概要図
【図４】管理ＤＢに登録されるテーブルを示し、（Ａ）は加入者情報テーブル、（Ｂ）はコンテンツ情報テーブル、（Ｃ）は視聴情報テーブルの説明図
【図５】キャッシュサーバ方式により視聴情報を登録するための構成図
【図６】同上における視聴情報登録処理の概要図
【図７】リダイレクション方式によりコンテンツを管理するための構成図
【図８】同上におけるコンテンツ管理処理の概要図
【図９】キャッシュサーバ方式によりコンテンツを管理するための構成図
【図１０】同上におけるコンテンツ管理処理の概要図
【図１１】コンテンツ管理処理を示すメインルーチンのフローチャート
【図１２】コンテンツ削除処理を示すサブルーチンのフローチャート
【図１３】コンテンツ配布処理を示すサブルーチンのフローチャート
【図１４】各ローカル局ごとのヒット率を演算するためのテーブルの説明図
【図１５】ランキングテーブルの説明図
【図１６】各ジャンルごとのヒット率を演算するためのテーブルの説明図
【図１７】削除対象ジャンルにおける優先リストの説明図
【図１８】配布対象ジャンルにおける優先リストの説明図
【符号の説明】
１０    コンピュータネットワーク
２０    センタ局
２０Ａ  配信サーバ
２０Ｂ  管理ＤＢ
２０Ｄ  ヒット率管理サーバ
２０Ｅ  配布管理サーバ
３０    ローカル局
３０Ａ  キャッシュサーバ
３０Ｂ  管理ＤＢ
３０Ｃ  ヒット率管理サーバ
３０Ｄ  配布管理サーバ
【図１】
0003999004.tif 000005
【図２】
0003999004.tif 000006
【図３】
0003999004.tif 000007
【図４】
0003999004.tif 000008
【図５】
0003999004.tif 000009
【図６】
0003999004.tif 000010
【図７】
0003999004.tif 000011
【図８】
0003999004.tif 000012
【図９】
0003999004.tif 000013
【図１０】
0003999004.tif 000014
【図１１】
0003999004.tif 000015
【図１２】
0003999004.tif 000016
【図１３】
0003999004.tif 000017
【図１４】
0003999004.tif 000018
【図１５】
0003999004.tif 000019
【図１６】
0003999004.tif 000020
【図１７】
0003999004.tif 000021
【図１８】
0003999004.tif 000022