JP2009104381A - キャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法 - Google Patents

Abstract

【課題】将来的にアクセスの増加が見込まれるリッチコンテンツを効果的にキャッシュすること。
【解決手段】キャッシュ制御装置１０１は、任意のサイトに関するフィードを受信し、受信されたフィードの購読者数に基づいて、コンテンツサーバ１０３に格納されているコンテンツのうち、フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する。このとき、キャッシュが必要であると判断された場合、購読者のクライアント端末１０５−１〜１０５−ｎからリッチコンテンツの送信要求を受け付けるキャッシュサーバ１０４−１〜１０４−ｎに、そのリッチコンテンツのキャッシュ指示を送信する。
【選択図】図１

Description

この発明は、ネットワーク上で配信される映像、音楽などのコンテンツのキャッシュを制御するキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法に関する。

近年、ネットワーク上で動画像やフラッシュなどのコンテンツを配信するサービスが急速に拡大している。一方で、データ量の多いコンテンツを配信することによって、ネットワーク帯域の圧迫や配信サーバにかかる負荷の増大化を招き、サービスの品質を劣化させるという問題を引き起こしている。

そこで、インターネットサービスプロバイダ（ＩＳＰ）のネットワーク内にキャッシュサーバを配置し、そのキャッシュサーバにコンテンツを予めキャッシュする、または、あるユーザが視聴したコンテンツを別のユーザの視聴に備えてキャッシュするという手法がとられている。キャッシュサーバが効果的に利用されるためには、多くのユーザが視聴するコンテンツを正確に予測し、キャッシュサーバにキャッシュすることが必要となる。

従来、配信されるコンテンツのＵＲＬをリスト化した配信ＵＲＬリストに基づいて、コンテンツのキャッシュを制御する方式が開示されている（例えば、下記特許文献１参照。）。この配信ＵＲＬは、ウェブサイトのアクセスログに基づく予測、人間による分析、または、ポータルサイトにリンクされているウェブサイトをもとに作成される。

特開２００１−９２７４５号公報

しかしながら、上述した特許文献１に記載の従来技術によれば、動画共有サイトなどに投稿される一般のユーザが撮影した動画像などの自然発生的なコンテンツへのアクセスを正確に予測することは難しかった。例えば、投稿された動画像が芸能人のブログなどで紹介されることで、動画像に対するアクセスが急激に増加する場合がある。このような場合、動画像の配信サーバへのアクセスが集中してしまい、ネットワーク帯域の圧迫や配信サーバにかかる負荷の増大化を招き、サービスの品質を劣化させるという問題があった。

また、予測結果に基づいてキャッシュサーバにコンテンツをキャッシュしたとしても、そのコンテンツへのアクセスが集中する時間帯と、ネットワーク内の通信トラフィックが増大する時間帯とが重なった場合には、依然としてネットワーク帯域の圧迫を招いてしまい、サービスの品質を劣化させるという問題があった。

この発明は、上述した従来技術による問題点を解消するため、将来的にアクセスの増加が見込まれるコンテンツを効果的にキャッシュすることにより、通信品質の向上を図るキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法は、任意のサイトに関するフィードを受信し、受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、前記フィードから特定されるリッチコンテンツをキャッシュするか否かを判断し、キャッシュが必要であると判断された場合、前記購読者の端末装置から前記リッチコンテンツの送信要求を受け付ける第２のサーバに、前記リッチコンテンツのキャッシュ指示を送信することを要件とする。

このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法によれば、将来的にアクセスの増加が見込まれるリッチコンテンツを効果的にキャッシュすることができる。

また、キャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法は、前記端末装置に対する前記フィードの配信に先立って、前記リッチコンテンツのキャッシュ指示を前記第２のサーバに送信することとしてもよい。

このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法によれば、フィードから特定されるリッチコンテンツへの購読者からのアクセスが発生する前に、リッチコンテンツのキャッシュ指示を送信することができる。

また、キャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法は、前記端末装置が属するネットワーク内の通信トラフィックが増大する時間帯を特定するための混雑情報に基づいて、前記時間帯とは異なる他の時間帯に前記キャッシュ指示を前記第２のサーバに送信することとしてもよい。

このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法によれば、通信トラフィックが増大する時間帯を回避して、リッチコンテンツのキャッシュ指示を送信することができる。

また、キャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法は、前記フィードの購読者数が予め設定された閾値以上であった場合に、前記リッチコンテンツのキャッシュが必要であると判断することとしてもよい。

このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法によれば、フィードの購読者数に応じて、リッチコンテンツのキャッシュの要否を判断することができる。

また、キャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法は、前記フィードの購読者が利用するインターネットサービスプロバイダごとの購読者数に基づいて、前記購読者数が予め設定された閾値以上であった場合に、前記インターネットサービスプロバイダが運用する第２のサーバに対する前記リッチコンテンツのキャッシュが必要であると判断することとしてもよい。

このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法によれば、ＩＳＰごとのフィードの購読者数に応じて、ＩＳＰが運用するキャッシュサーバに対するリッチコンテンツのキャッシュの要否を判断することができる。

このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法によれば、将来的にアクセスの増加が見込まれるコンテンツを効果的にキャッシュすることにより、通信品質の向上を図ることができるという効果を奏する。

以下に添付図面を参照して、このキャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法の好適な実施の形態を詳細に説明する。

（コンテンツ配信システムのシステム構成）
まず、本実施の形態にかかるコンテンツ配信システムのシステム構成について説明する。図１は、本実施の形態にかかるコンテンツ配信システムのシステム構成図である。図１において、コンテンツ配信システム１００は、キャッシュ制御装置１０１と、ウェブサーバ１０２−１〜１０２−ｎと、コンテンツサーバ１０３と、キャッシュサーバ１０４−１〜１０４−ｎと、クライアント端末１０５−１〜１０５−ｎと、がインターネット、ＬＡＮ、ＷＡＮなどのネットワーク１１０を介して相互に交信可能に接続されている。

コンテンツ配信システム１００は、ネットワーク１１０上において、映像や音楽などのコンテンツをクライアント端末１０５−１〜１０５−ｎに配信するサービスを提供する。また、コンテンツ配信システム１００は、ウェブサイトの概要を表わすフィードを、フィードを購読するユーザ（以下、「購読者」という）のクライアント端末１０５−１〜１０５−ｎに配信する仕組みを備えている。

キャッシュ制御装置１０１は、キャッシュサーバ１０４−１〜１０４−ｎに対するリッチコンテンツのキャッシュを制御する機能を有するコンピュータ装置である。また、キャッシュ制御装置１０１は、ウェブサーバ１０２−１〜１０２−ｎからのフィードを受信し、そのフィードを購読者のクライアント端末１０５−１〜１０５−ｎに配信する機能を有する。

ウェブサーバ１０２−１〜１０２−ｎは、記憶部に格納されているコンテンツ（例えば、ＨＴＭＬ文書）からフィードを作成する機能を有するコンピュータ装置である。また、ウェブサーバ１０２−１〜１０２−ｎは、キャッシュ制御装置１０１からのリクエストに応じて、フィードをキャッシュ制御装置１０１に送信する機能を有する。

コンテンツサーバ１０３は、キャッシュサーバ１０４−１〜１０４−ｎからのリクエストに応じて、記憶部に格納されているリッチコンテンツをキャッシュサーバ１０４−１〜１０４−ｎに送信する機能を有するコンピュータ装置である。

キャッシュサーバ１０４−１〜１０４−ｎは、キャッシュ制御装置１０１からのキャッシュ指示に応じて、リッチコンテンツを後述するキャッシュＤＢ５２０（図５参照）にキャッシュする機能を有するコンピュータ装置である。具体的には、キャッシュ指示から特定されるリッチコンテンツの取得要求をコンテンツサーバ１０３に送信し、その結果、送信されてくるリッチコンテンツをキャッシュＤＢ５２０にキャッシュする。

ここでは、キャッシュサーバ１０４−１〜１０４−ｎは、インターネットサービスを提供するインターネットサービスプロバイダ（以下、「ＩＳＰ」という）ごとに用意されている。例えば、キャッシュサーバ１０４−１は、ＩＳＰ名が「ｍｉｆｔｙ」のＩＳＰが運用するサーバである。

クライアント端末１０５−１〜１０５−ｎは、キャッシュ制御装置１０１から配信されるフィードを受信する機能を有するコンピュータ装置である。これらクライアント端末１０５−１〜１０５−ｎは、契約しているＩＳＰが提供するインターネットサービスを利用することができる。

本実施の形態では、動画共有サイトなどに投稿される動画像などの自然発生的なコンテンツへのアクセスが増加するのを想定して、購読者数の多いフィードから特定されるリッチコンテンツを、予めキャッシュサーバ１０４−１〜１０４−ｎにキャッシュする。すなわち、将来的にアクセスの増加が見込まれるリッチコンテンツを効果的にキャッシュすることにより、ネットワーク帯域の圧迫を防ぐとともに、コンテンツサーバ１０３にかかる負荷を分散させて高品質なサービスの提供を実現する。

ここで、本実施の形態の概要を説明する。まず、ウェブサーバ１０２−１は、記憶部に格納されているウェブサイトに関するＨＴＭＬ文書からフィードを作成し、そのフィードをキャッシュ制御装置１０１に送信する（１）。このあと、キャッシュ制御装置１０１は、ウェブサーバ１０２−１からフィードを受信し、そのフィードの購読者数をＩＳＰごとに算出する。

このとき、ＩＳＰごとのフィードの購読者数が予め設定された閾値以上となった場合に、そのフィードから特定されるリッチコンテンツのキャッシュ指示をキャッシュサーバ１０４−１に送信する（２）。ここでは、ｍｉｆｔｙ（ＩＳＰ名）の購読者数が閾値以上となった場合を例に挙げて説明する。

キャッシュサーバ１０４−１は、キャッシュ制御装置１０１からのキャッシュ指示を受信すると、そのキャッシュ指示に含まれるリッチコンテンツのＵＲＬを指定して、コンテンツサーバ１０３に対してリッチコンテンツの取得要求を送信する（３）。

コンテンツサーバ１０３は、キャッシュサーバ１０４−１からリッチコンテンツの取得要求を受信すると、その取得要求に応じたリッチコンテンツを記憶部から抽出し、そのリッチコンテンツをキャッシュサーバ１０４−１に送信する（４）。この結果、キャッシュサーバ１０４−１は、コンテンツサーバ１０３からリッチコンテンツを受信し、そのリッチコンテンツをキャッシュする。

このあと、キャッシュ制御装置１０１は、購読者のクライアント端末１０５−１〜１０５−ｎにフィードを配信する（５）。なお、フィードの配信タイミングは、例えば、リッチコンテンツのキャッシュ指示を送信したあとでもよく、また、キャッシュサーバ１０４−１〜１０４−ｎからリッチコンテンツのキャッシュ完了通知を受信したあとでもよい。

（データベースの記憶内容）
つぎに、図１に示したコンピュータ装置が備えるデータベースの記憶内容について説明する。まず、キャッシュ制御装置１０１が備えるデータベースの記憶内容について説明する。図２は、キャッシュ制御装置が備えるデータベースの記憶内容を示す説明図である。図２において、キャッシュ制御装置１０１は、購読者情報ＤＢ２１０と、ＩＳＰ情報ＤＢ２２０と、混雑情報ＤＢ２３０と、を備えている。

（購読者情報ＤＢの記憶内容）
購読者情報ＤＢ２１０は、フィードを購読している購読者ごとの購読者情報２１０−１〜２１０−ｉを記憶している。具体的には、購読者情報２１０−１〜２１０−ｉは、購読者ごとに、購読者ＩＤ、ウェブサーバＵＲＬおよびＩＳＰ名に関する情報を有している。購読者ＩＤは、フィードの購読者を特定するための識別情報である。ウェブサーバＵＲＬは、フィードの作成元であるウェブサーバ１０２−１〜１０２−ｎのＵＲＬである。ＩＳＰ名は、購読者が契約しているＩＳＰの名称である。

ここで、購読者情報２１０−１を例に挙げると、購読者ＩＤ「ａｌｉｃｅ＠ｍｉｆｔｙ．ｃｏｍ」から特定される購読者が購読しているフィードの作成元であるウェブサーバ１０２−１〜１０２−ｎのＵＲＬ「ｈｔｔｐ：／／ｃｏｃｏｌｏｇ．ｍｉｆｔｙ．ｃｏｍ／ｒａｍｅｎ．ｈｔｍｌ」、および購読者が契約しているＩＳＰの名称「ｍｉｆｔｙ」が示されている。この購読者情報ＤＢ２１０の記憶内容は、フィードの購読者数の算出に利用される。

（ＩＳＰ情報ＤＢの記憶内容）
ＩＳＰ情報ＤＢ２２０は、ＩＳＰごとのＩＳＰ情報２２０−１〜２２０−ｊを記憶している。具体的には、ＩＳＰ情報２２０−１〜２２０−ｊは、ＩＳＰごとに、ＩＳＰ名、キャッシュサーバＵＲＬおよび必要購読者数に関する情報を有している。ＩＳＰ名は、ＩＳＰの名称である。キャッシュサーバＵＲＬは、ＩＳＰが運用するキャッシュサーバ１０４−１〜１０４−ｎのＵＲＬである。必要購読者数は、リッチコンテンツのキャッシュが必要となるフィードの購読者数である。

ここで、ＩＳＰ情報２２０−１を例に挙げると、ＩＳＰ名「ｍｉｆｔｙ」のＩＳＰが運用するキャッシュサーバ１０４−１のＵＲＬ「ｈｔｔｐ：／／ｍｉｆｔｙ．ｃｏｍ／ｃａｓｈ」、および必要購読者数「３」が示されている。このＩＳＰ情報ＤＢ２２０の記憶内容は、リッチコンテンツをキャッシュするか否かの判断に利用される。

（混雑情報ＤＢの記憶内容）
混雑情報ＤＢ２３０は、ネットワーク構造ごとの混雑情報２３０−１〜２３０−ｋを記憶している。具体的には、混雑情報２３０−１〜２３０−ｋは、ネットワーク構造ごとに、各ネットワーク内の通信トラフィックが増大する時間帯を特定するための情報を有している。ネットワーク構造とは、例えば、各ＩＳＰによって使用される通信網や配信サーバ（例えば、コンテンツサーバ１０３）によって使用される通信網である。

ここで、混雑情報２３０−１を例に挙げると、ＩＳＰ名「ｍｉｆｔｙ」のＩＳＰのネットワーク内の通信トラフィックが増大する時間帯「２０：００−２４：００」が示されている。この混雑情報ＤＢ２３０の記憶内容は、キャッシュ指示の送信タイミングの判断に利用される。

（キャッシュ情報ＤＢの記憶内容）
つぎに、コンテンツサーバ１０３が備えるデータベースの記憶内容について説明する。図３は、コンテンツサーバが備えるキャッシュ情報ＤＢの記憶内容を示す説明図である。図３において、キャッシュ情報ＤＢ３１０は、コンテンツごとのキャッシュ情報３１０−１〜３１０−ｍを記憶している。

具体的には、キャッシュ情報３１０−１〜３１０−ｍは、コンテンツごとに、コンテンツＩＤ、ＩＳＰ名およびキャッシュサーバＵＲＬに関する情報を有している。コンテンツＩＤは、コンテンツを特定するための識別情報である。ＩＳＰ名は、ＩＳＰの名称である。キャッシュサーバＵＲＬは、各ＩＳＰの運用するキャッシュサーバ１０４−１〜１０４−ｎにキャッシュされているリッチコンテンツのＵＲＬである。

ここで、キャッシュ情報３１０−１を例に挙げると、ＩＳＰ名「ｍｉｆｔｙ」のＩＳＰが運用するキャッシュサーバ１０４−１にキャッシュされているコンテンツＩＤ「ｘｘｘｘｘｘ」から特定されるリッチコンテンツのＵＲＬ「ｈｔｔｐ：／／ｍｉｆｔｙ．ｃｏｍ／ｃａｓｈ／ｘｘｘｘｘｘ」が示されている。

（コンピュータ装置のハードウェア構成）
つぎに、図１に示したコンピュータ装置（キャッシュ制御装置１０１、ウェブサーバ１０２−１〜１０２−ｎ、コンテンツサーバ１０３、キャッシュサーバ１０４−１〜１０４−ｎ、クライアント端末１０５−１〜１０５−ｎ）のハードウェア構成について説明する。図４は、この発明の実施の形態にかかるコンピュータ装置のハードウェア構成を示す説明図である。

図４において、コンピュータ装置は、コンピュータ本体４１０と、入力装置４２０と、出力装置４３０と、から構成されており、不図示のルータやモデムを介してＬＡＮ，ＷＡＮやインターネットなどのネットワーク１１０に接続可能である。

コンピュータ本体４１０は、ＣＰＵ，メモリ，インターフェースを有する。ＣＰＵは、コンピュータ装置の全体の制御を司る。メモリは、ＲＯＭ，ＲＡＭ，ＨＤ，光ディスク４１１，フラッシュメモリから構成される。メモリはＣＰＵのワークエリアとして使用される。

また、メモリには各種プログラムが格納されており、ＣＰＵからの命令に応じてロードされる。ＨＤおよび光ディスク４１１はディスクドライブによりデータのリード／ライトが制御される。また、光ディスク４１１およびフラッシュメモリはコンピュータ本体４１０に対し着脱自在である。インターフェースは、入力装置４２０からの入力、出力装置４３０への出力、ネットワーク１１０に対する送受信の制御をおこなう。

また、入力装置４２０としては、キーボード４２１、マウス４２２、スキャナ４２３などがある。キーボード４２１は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式であってもよい。マウス４２２は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。スキャナ４２３は、画像を光学的に読み取る。読み取られた画像は画像データとして取り込まれ、コンピュータ本体４１０内のメモリに格納される。なお、スキャナ４２３にＯＣＲ機能を持たせてもよい。

また、出力装置４３０としては、ディスプレイ４３１、プリンタ４３２、スピーカ４３３などがある。ディスプレイ４３１は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。また、プリンタ４３２は、画像データや文書データを印刷する。またスピーカ４３３は、効果音や読み上げ音などの音声を出力する。

（コンテンツ配信システムの機能的構成）
つぎに、図１に示したコンテンツ配信システム１００の機能的構成について説明する。図５は、コンテンツ配信システムの機能的構成を示すブロック図である。まず、キャッシュ制御装置１０１の機能的構成について説明する。図５において、キャッシュ制御装置１０１は、受信部５０１と、判断部５０２と、検出部５０３と、抽出部５０４と、送信部５０５と、配信部５０６と、を備えている。

これら各機能５０１〜５０６は、キャッシュ制御装置１０１の記憶部に記憶された当該機能５０１〜５０６に関するプログラムをＣＰＵに実行させることにより、または、入出力Ｉ／Ｆにより、当該機能を実現することができる。また、各機能５０１〜５０６からの出力データは上記記憶部に保持される。また、図５中矢印で示した接続先の機能は、接続元の機能からの出力データを記憶部から読み込んで、当該機能に関するプログラムをＣＰＵに実行させるものとする。

まず、受信部５０１は、任意のサイトに関するフィードを受信する機能を有する。具体的には、例えば、ウェブサーバ１０２−１〜１０２−ｎ（以下、「ウェブサーバ１０２」と表記）からフィードを受信する。フィードとは、ブログ（ウェブログ）やニュースサイトなどのウェブサイトの概要を表わす電子データ（例えば、ＸＭＬ文書）である。フィードを記述するフォーマットとしては、例えば、ＲＳＳ（Ｒｉｃｈ Ｓｉｔｅ Ｓｕｍｍａｒｙ）やＡｔｏｍなどがある。

一般的には、サイト内に配置されたフィードへのリンクを示すアイコンをユーザがクリックすることで、フィードリーダーに登録する。この結果、フィードリーダーが登録済みのフィードの更新を定期的に確認し、更新されたことをユーザに知らせる。つまり、ユーザは、所望のサイトをフィードリーダーに登録することにより、そのサイトの更新タイミングを知ることができる。

判断部５０２は、受信部５０１によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する機能を有する。購読者は、フィードを購読しているユーザである。第１のサーバは、例えば、コンテンツサーバ１０３である。なお、フィードの購読は、有償であっても無償であってもよい。

ここで、リッチコンテンツとは、例えば、映像や音楽などデータ量の多いコンテンツでもよく、また、ユーザからの高い関心が見込まれるスポーツ選手や芸能人などの有名人に関する記事が記述されたコンテンツでもよい。より具体的には、例えば、任意に設定されたデータ量を超えるコンテンツや、任意に設定されたキーワードを含むコンテンツなどである。また、特定の種別のコンテンツをリッチコンテンツとすることとしてもよい。

具体的には、判断部５０２は、フィードの購読者数が予め設定された閾値以上であった場合に、リッチコンテンツのキャッシュが必要であると判断することとしてもよい。この閾値は、任意に設定可能であり、例えば、図４に示したキーボード４２１やマウス４２２などの入力装置４２０をユーザが操作することで設定することとしてもよい。より具体的には、例えば、閾値は、図２に示したＩＳＰ情報ＤＢ２２０内に記憶されているＩＳＰごとの必要購読者数である。

この必要購読者数は、例えば、リッチコンテンツのダウンロード回数の期待値をもとに算定される。ここでは、リッチコンテンツのダウンロード回数の期待値が「１」を超えた場合に、リッチコンテンツのキャッシュが必要であると判断する。この期待値は、例えば、『リッチコンテンツのダウンロード回数の期待値＝フィードの購読者数×ウェブ参照率×ダウンロード率』から求めることができる。

ここで、ウェブ参照率は、フィードの購読者が、実際にウェブブラウザを利用してフィードの作成元であるウェブサーバ１０２のウェブコンテンツを参照する率である。また、ダウンロード率は、そのウェブコンテンツ上のリッチコンテンツへのリンクのクリック率である。例えば、ウェブ参照率が「０．５」、ダウンロード率が「０．４」であるとすると、フィードの購読者数が５人以上の場合に期待値が１を超えるため、上述した必要購読者数は「６」と設定される。

ここで、判断部５０２による判断処理を具体的に説明する。検出部５０３は、受信部５０１によって受信されたフィードの中から、フィードの作成元であるウェブサーバ１０２のＵＲＬを検出する機能を有する。図６は、フィードの具体例を示す説明図である。図６において、フィード６００は、ウェブサイトの概要を表わす電子データであり、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）言語で記述されている。

具体的には、フィード６００内の挿入位置６１０には、ウェブサイトの概要を表わすＨＴＭＬデータが挿入されている。また、挿入位置６２０には、フィード６００の作成元であるウェブサーバ１０２のＵＲＬが挿入されている。また、挿入位置６３０には、リッチコンテンツのＵＲＬが挿入されている。例えば、受信部５０１によってフィード６００が受信された場合、検出部５０３は、フィード６００の中から、挿入位置６２０に挿入されているウェブサーバ１０２のＵＲＬ「ｈｔｔｐ：／／ｃｏｃｏｌｏｇ．ｍｉｆｔｙ．ｃｏｍ／ｒａｍｅｎ．ｈｔｍｌ」を検出する。

また、検出部５０３は、受信部５０１によって受信されたフィードの中からリッチコンテンツのＵＲＬを検出する機能を有する。リッチコンテンツのＵＲＬとは、例えば、指定することでリッチコンテンツをダウンロードすることができるＵＲＬである。ここで、受信部５０１によってフィード６００が受信された場合、検出部５０３は、フィード６００の中から、挿入位置６３０に挿入されているリッチコンテンツのＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｗｅｔｕｂｅ．ｃｏｍ／ｖ／ｘｘｘｘｘ」を検出する。

より具体的には、例えば、検出部５０３は、挿入位置６３０に挿入されている『ｐａｒａｍ ｎａｍｅ＝“ｍｏｖｉｅ”』などの文字列からコンテンツの種別を判断し、その種別がリッチコンテンツとして予め設定された種別（例えば、“ｍｏｖｉｅ”）であった場合に、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｗｅｔｕｂｅ．ｃｏｍ／ｖ／ｘｘｘｘｘ」を検出することとしてもよい。

抽出部５０４は、フィードの作成元のＵＲＬと購読者ＩＤとを関連付けて記憶する購読者情報ＤＢ２１０の中から、検出部５０３によって検出されたウェブサーバ１０２のＵＲＬと関連付けて記憶されている購読者ＩＤを抽出する機能を有する。具体的には、例えば、購読者情報ＤＢ２１０の中から、検出部５０３によって検出されたウェブサーバ１０２のＵＲＬと関連付けて記憶されている購読者の購読者情報２１０−１〜２１０−ｎを抽出する。

判断部５０２は、抽出部５０４によって抽出された購読者ＩＤに基づいて、受信部５０１によって受信されたフィードの購読者数を判断する。具体的には、例えば、抽出部５０４によって購読者情報２１０−１〜２１０−４が抽出された場合、購読者情報２１０−１〜２１０−４に含まれる購読者ＩＤからフィードの購読者数は「４」と判断することとなる。

このあと、判断部５０２は、フィードの購読者数が予め設定された閾値以上であった場合に、リッチコンテンツのキャッシュが必要であると判断する。例えば、予め設定された閾値が「３」であった場合、上述した例ではフィードの購読者数が「４」のため、判断部５０２は、リッチコンテンツのキャッシュが必要であると判断する。

また、判断部５０２は、フィードの購読者が利用するＩＳＰごとの購読者数に基づいて、ＩＳＰごとの購読者数が予め設定された閾値以上であった場合に、ＩＳＰが運用する第２のサーバに対するリッチコンテンツのキャッシュが必要であると判断することとしてもよい。ＩＳＰごとの購読者数は、例えば、抽出部５０４によって抽出された抽出結果から判断することができる。

具体的には、例えば、抽出部５０４によって購読者情報２１０−１〜２１０−４が抽出された場合、購読者情報２１０−１〜２１０−４に含まれるＩＳＰ名からＩＳＰごとの購読者数を判断する。ここでは、購読者情報２１０−１〜２１０−４に含まれるＩＳＰ名（ｍｉｆｔｙ、ＧＩＯＮ）から、ＩＳＰ名「ｍｉｆｔｙ」のＩＳＰの購読者数「２」およびＩＳＰ名「ＧＩＯＮ」のＩＳＰの購読者数「２」を判断する。

このあと、判断部５０２は、ＩＳＰごとの購読者数が各ＩＳＰの必要購読者数以上であった場合に、そのＩＳＰが運用するキャッシュサーバ１０４−１〜１０４−ｎ（以下、「キャッシュサーバ１０４」と表記）に対するリッチコンテンツのキャッシュが必要であると判断する。ＩＳＰの必要購読者数は、例えば、ＩＳＰ情報ＤＢ２２０に記憶されているＩＳＰ情報２２０−１〜２２０−２から判断することができる。

具体的には、例えば、抽出部５０４は、購読者情報２１０−１〜２１０−４に含まれるＩＳＰ名に基づいて、ＩＳＰ情報ＤＢ２２０からＩＳＰ情報２２０−１〜２２０−２を抽出する。そして、判断部５０２は、抽出部５０４によって抽出されるＩＳＰ情報２２０−１〜２２０−２から、ＩＳＰごとの必要購読者数を判断する。

ここでは、ＩＳＰ情報２２０−１〜２２０−２から、ＩＳＰ名「ｍｉｆｔｙ」および「ＧＩＯＮ」のＩＳＰごとの必要購読者数は、「３」および「５」と判断される。この場合、判断部５０２は、ＩＳＰ名「ｍｉｆｔｙ」および「ＧＩＯＮ」のＩＳＰの購読者数がそれぞれ「２」であり、ともに必要購読者数未満となるため、リッチコンテンツのキャッシュは不要であると判断する。

なお、判断部５０２による判断処理は、検出部５０３によってフィードの中からリッチコンテンツのＵＲＬが検出されなかった場合には実行しないこととしてもよい。なぜなら、フィードが購読者に配信されたとしても、そのフィード配信が引き金となってデータ量の多いリッチコンテンツへのアクセスが発生する可能性は低いからである。

送信部５０５は、判断部５０２によってキャッシュが必要であると判断された場合、購読者の端末装置からリッチコンテンツの送信要求を受け付ける第２のサーバに、リッチコンテンツのキャッシュ指示を送信する機能を有する。キャッシュ指示とは、リッチコンテンツのＵＲＬを表わす電子データであり、例えば、フィード６００内の挿入位置６３０に挿入されたＵＲＬである。

また、このキャッシュ指示には、フィードの購読者数を表わす情報が含まれていてもよい。フィードの購読者数は、上述したように購読者情報２１０−１〜２１０−ｎから判断される。購読者の端末装置とは、例えば、クライアント端末１０５−１〜１０５−ｎ（以下、「クライアント端末１０５」と表記）である。リッチコンテンツの送信要求とは、例えば、フィードから特定されるリッチコンテンツのダウンロード要求である。

また、第２のサーバとは、例えば、購読者のクライアント端末１０５が属するネットワーク内のキャッシュサーバ１０４、より具体的には、購読者が契約しているＩＳＰが運用するキャッシュサーバ１０４である。図１に示した例では、クライアント端末１０５−１，１０５−２の購読者が契約しているＩＳＰ名「ｍｉｆｔｙ」のＩＳＰが運用するキャッシュサーバ１０４−１である。

また、送信部５０５は、端末装置に対するフィードの配信に先立って、リッチコンテンツのキャッシュ指示を第２のサーバに送信することとしてもよい。すなわち、購読者からリッチコンテンツへのアクセスが発生する前に、そのリッチコンテンツのキャッシュ指示を送信する。

また、送信部５０５は、端末装置が属するネットワーク内の通信トラフィックが増大する時間帯を特定するための混雑情報に基づいて、その時間帯とは異なる他の時間帯にキャッシュ指示を第２のサーバに送信することとしてもよい。すなわち、通信トラフィックが増大する時間帯を回避してリッチコンテンツのキャッシュ指示を送信することにより、ネットワーク帯域の圧迫などを防止する。

具体的には、例えば、抽出部５０４は、クライアント端末１０５が属するネットワーク内の混雑情報２３０−１〜２３０−ｋを混雑情報ＤＢ２３０から抽出する。送信部５０５は、抽出部５０４によって抽出された混雑情報２３０−１〜２３０−ｋから混雑時間帯を特定し、その時間帯とは異なる他の時間帯にキャッシュ指示をキャッシュサーバ１０４に送信する。

より具体的には、例えば、クライアント端末１０５−１が属するネットワーク内の混雑情報２３０−１が抽出された場合、その混雑情報２３０−１から特定される混雑時間帯「２０：００−２４：００」とは異なる他の時間帯にキャッシュ指示をキャッシュサーバ１０４−１に送信することとなる。

配信部５０６は、送信部５０５によってキャッシュ指示が送信された結果、購読者の端末装置にフィードを送信する機能を有する。フィードの配信先の購読者は、例えば、抽出部５０４によって購読者情報ＤＢ２１０の中から抽出された購読者情報２１０−１〜２１０−ｎから特定する。

また、配信部５０６は、送信部５０５によってキャッシュ指示を送信したキャッシュサーバ１０４から、リッチコンテンツのキャッシュが完了したことを表わす完了通知を受信した場合に、購読者の端末装置にフィードを送信することとしてもよい。これにより、購読者からリッチコンテンツへのアクセスが発生する前に、そのリッチコンテンツを確実にキャッシュすることができる。

つぎに、キャッシュサーバ１０４の機能的構成について説明する。図５において、キャッシュサーバ１０４は、受信部５１１と、送信部５１２と、抽出部５１３と、判定部５１４と、削除部５１５と、を備えている。

これら各機能５１１〜５１５は、キャッシュサーバ１０４の記憶部に記憶された当該機能５１１〜５１５に関するプログラムをＣＰＵに実行させることにより、または、入出力Ｉ／Ｆにより、当該機能を実現することができる。また、各機能５１１〜５１５からの出力データは上記記憶部に保持される。また、図５中矢印で示した接続先の機能は、接続元の機能からの出力データを記憶部から読み込んで、当該機能に関するプログラムをＣＰＵに実行させるものとする。

まず、受信部５１１は、フィードから特定されるリッチコンテンツのキャッシュを制御するキャッシュ制御装置１０１からリッチコンテンツのキャッシュ指示を受信する機能を有する。リッチコンテンツのキャッシュ指示は、例えば、リッチコンテンツのＵＲＬを含む電子データである。また、このキャッシュ指示には、フィードの購読者数を表わす情報が含まれていてもよい。

送信部５１２は、受信部５１１によってリッチコンテンツのキャッシュ指示が受信された場合、そのキャッシュ指示から特定されるリッチコンテンツが格納されている第１のサーバに、そのリッチコンテンツの取得要求を送信する機能を有する。具体的には、例えば、キャッシュ指示に含まれるリッチコンテンツのＵＲＬを指定して、リッチコンテンツの取得要求をコンテンツサーバ１０３に送信する。

また、受信部５１１は、送信部５１２によってリッチコンテンツの取得要求が送信された結果、第１のサーバからリッチコンテンツを受信する機能を有する。受信部５１１によって受信されたリッチコンテンツは、キャッシュＤＢ５２０にキャッシュされる。この結果、クライアント端末１０５は、キャッシュサーバ１０４からリッチコンテンツを取得することができる。

また、受信部５１１は、フィードの購読者の端末装置からリッチコンテンツの送信要求を受信する機能を有する。リッチコンテンツの送信要求とは、例えば、フィードから特定されるリッチコンテンツのコンテンツＩＤを表わす電子データである。

抽出部５１３は、受信部５１１によって受信された送信要求から特定されるリッチコンテンツを、キャッシュ済みのコンテンツ群（例えば、キャッシュＤＢ５２０）の中から抽出する機能を有する。また、送信部５１２は、抽出部５１３によって抽出されたリッチコンテンツを、送信要求の送信元の端末装置に送信する機能を有する。

判定部５１４は、送信部５１２によるリッチコンテンツの送信回数が所定回数以上となったか否かを判定する機能を有する。所定回数は、任意に設定可能である。具体的には、例えば、受信部５１１によって受信されたキャッシュ指示から特定されるフィードの購読者数を所定回数として設定することとしてもよい。

削除部５１５は、判定部５１４によってリッチコンテンツの送信回数が所定回数以上と判定された場合、キャッシュ済みのコンテンツ群のうち上記リッチコンテンツを削除する機能を有する。具体的には、例えば、リッチコンテンツの送信回数がフィードの購読者数以上と判定された場合に、キャッシュＤＢ５２０の中から上記リッチコンテンツを削除することとしてもよい。

また、送信部５１２は、削除部５１５によってキャッシュＤＢ５２０の中からリッチコンテンツが削除された場合、そのリッチコンテンツが削除されたことを表わす削除通知をコンテンツサーバ１０３に送信する。コンテンツサーバ１０３は、キャッシュサーバ１０４から削除通知を受信した場合、その削除通知から特定されるキャッシュ情報３１０−１〜３１０−ｍをキャッシュ情報ＤＢ３１０から削除する。

ここで、クライアント端末１０５がキャッシュサーバ１０４からリッチコンテンツを取得する一連の流れを説明する。まず、クライアント端末１０５は、キャッシュ制御装置１０１から配信されるフィードを受信する。具体的には、例えば、フィードの配信要求を定期的にキャッシュ制御装置１０１に送信し、その結果、キャッシュ制御装置１０１からフィードを受信する。

このあと、クライアント端末１０５は、ウェブブラウザを起動して、フィード内に挿入されているウェブサーバ１０２のＵＲＬを指定することでウェブサイトにアクセスする。このとき、リッチコンテンツへのリンクが含まれている場合、そのリンクをユーザがクリックすることで、リッチコンテンツを格納しているコンテンツサーバ１０３に接続することができる。

具体的には、例えば、リッチコンテンツを特定するコンテンツＩＤおよびクライアント端末１０５が属するＩＳＰを特定する契約ＩＳＰ情報が含まれたリクエストをクライアント端末１０５からコンテンツサーバ１０３に送信する。コンテンツサーバ１０３は、クライアント端末１０５からのリクエストを受信すると、コンテンツＩＤから特定されるリッチコンテンツのキャッシュの有無を判断する。

具体的には、例えば、図３に示したキャッシュ情報ＤＢ３１０に記憶されているキャッシュ情報３１０−１〜３１０−ｍに基づいて、契約ＩＳＰ情報から特定されるＩＳＰが運用するキャッシュサーバ１０４にコンテンツＩＤから特定されるリッチコンテンツがキャッシュされているか否かを判断する。例えば、契約ＩＳＰ情報から特定されるＩＳＰが「ｍｉｆｔｙ」であった場合、キャッシュ情報３１０−１に基づいて、リッチコンテンツがキャッシュされていることを判断することができる。

コンテンツサーバ１０３は、リッチコンテンツがキャッシュ済みであると判断された場合、契約ＩＳＰ情報から特定されるＩＳＰが運用するキャッシュサーバ１０４からリッチコンテンツを取得するためのＵＲＬが含まれた転送指示をクライアント端末１０５に送信する。具体的には、例えば、キャッシュ情報３１０−１から特定されるキャッシュサーバＵＲＬ「ｈｔｔｐ：／／ｍｉｆｔｙ．ｃｏｍ／ｃａｓｈ／ｘｘｘｘｘｘ」を含む転送指示をクライアント端末１０５に送信する。

このあと、クライアント端末１０５は、コンテンツサーバ１０３から転送指示を受信した場合、その転送指示に含まれているＵＲＬを指定することにより、リッチコンテンツの取得要求をキャッシュサーバ１０４に送信する。

キャッシュサーバ１０４は、クライアント端末１０５からの取得要求を受信した場合、その取得要求に応じたリッチコンテンツをキャッシュＤＢ５２０から抽出して、そのリッチコンテンツをクライアント端末１０５に送信する。この結果、クライアント端末１０５は、キャッシュサーバ１０４からリッチコンテンツを受信する。

このとき、キャッシュサーバ１０４は、クライアント端末１０５へのリッチコンテンツの送信回数をカウントし、そのカウント数がフィードの購読者数以上となった場合、そのリッチコンテンツをキャッシュＤＢ５２０の中から削除する。すなわち、キャッシュＤＢ５２０の中から将来的にアクセスの増加が見込まれなくなったリッチコンテンツを削除する。

なお、判定部５１４による判定処理および削除部５１５による削除処理は、ＩＳＰごとに実行することとしてもよい。すなわち、リッチコンテンツの送信回数がＩＳＰごとのフィードの購読者数以上となった場合に、そのＩＳＰが運用するキャッシュサーバ１０４にキャッシュされているリッチコンテンツを削除する。なお、ＩＳＰごとのフィードの購読者数を特定する情報は、例えば、リッチコンテンツのキャッシュ指示に含まれている。

（キャッシュ制御装置のキャッシュ制御処理手順）
つぎに、本実施の形態にかかるキャッシュ制御装置１０１のキャッシュ制御処理手順について説明する。図７は、本実施の形態にかかるキャッシュ制御装置のキャッシュ制御処理手順を示すフローチャートである。図７のフローチャートにおいて、まず、受信部５０１により、任意のサイトに関するフィードを受信したか否かを判断する（ステップＳ７０１）。

ここで、フィードを受信するのを待って（ステップＳ７０１：Ｎｏ）、受信した場合（ステップＳ７０１：Ｙｅｓ）、判断部５０２により、受信部５０１によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する判断処理を実行する（ステップＳ７０２）。

このあと、判断部５０２による判断結果からキャッシュの要否を判断し（ステップＳ７０３）、リッチコンテンツをキャッシュする必要がある場合（ステップＳ７０３：Ｙｅｓ）、送信部５０５により、フィードの購読者の端末装置からリッチコンテンツの送信要求を受け付ける第２のサーバに、該リッチコンテンツのキャッシュ指示を送信する送信処理を実行して（ステップＳ７０４）、本フローチャートによる一連の処理を終了する。また、ステップＳ７０３において、リッチコンテンツをキャッシュする必要がない場合（ステップＳ７０３：Ｎｏ）、ステップＳ７０１に戻り一連の処理を繰り返す。

これにより、将来的にアクセスの増加が見込まれるリッチコンテンツを効果的にキャッシュすることができる。

つぎに、図７に示したステップＳ７０２における判断処理の処理手順について説明する。図８は、判断処理の処理手順の一例を示すフローチャートである。図８のフローチャートにおいて、まず、検出部５０３により、図７に示したステップＳ７０１において受信されたフィードの中から、リッチコンテンツのＵＲＬを検出する（ステップＳ８０１）。

このあと、リッチコンテンツのＵＲＬが検出されたか否かを判断し（ステップＳ８０２）、リッチコンテンツのＵＲＬが検出された場合（ステップＳ８０２：Ｎｏ）、検出部５０３により、フィードの中から、フィードの作成元であるウェブサーバ１０２のＵＲＬを検出する（ステップＳ８０３）。

そして、抽出部５０４により、検出部５０３によって検出されたウェブサーバ１０２のＵＲＬと関連付けて記憶されている購読者ＩＤを購読者情報ＤＢ２１０の中から抽出する（ステップＳ８０４）。このあと、判断部５０２により、抽出部５０４によって抽出された購読者ＩＤに基づいて、フィードの購読者数を算出する（ステップＳ８０５）。

このあと、判断部５０２により、算出されたフィードの購読者数が予め設定された閾値以上か否かを判断する（ステップＳ８０６）。ここで、フィードの購読者数が閾値以上であった場合（ステップＳ８０６：Ｙｅｓ）、判断部５０２により、リッチコンテンツのキャッシュが必要であると判断して（ステップＳ８０７）、図７に示したステップＳ７０３に移行する。

また、ステップＳ８０２においてリッチコンテンツのＵＲＬが検出されなかった場合（ステップＳ８０２：Ｙｅｓ）、あるいは、ステップＳ８０６においてフィードの購読者数が予め設定された閾値未満であった場合（ステップＳ８０６：Ｎｏ）、判断部５０２により、リッチコンテンツのキャッシュが不要であると判断して（ステップＳ８０８）、図７に示したステップＳ７０３に移行する。

これにより、ＩＳＰごとのフィードの購読者数に応じて、ＩＳＰが運用するキャッシュサーバに対するリッチコンテンツのキャッシュの要否を判断することができる。

つぎに、図７に示したステップＳ７０４における送信処理の処理手順について説明する。図９は、送信処理の処理手順の一例を示すフローチャートである。図９のフローチャートにおいて、まず、抽出部５０４により、クライアント端末１０５が属するネットワーク内の混雑情報２３０−１〜２３０−ｋを混雑情報ＤＢ２３０から抽出する（ステップＳ９０１）。

このあと、現在時刻が、抽出された混雑情報２３０−１〜２３０−ｋから特定される混雑時間帯か否かを判断する（ステップＳ９０２）。ここで、混雑時間帯であった場合（ステップＳ９０２：Ｙｅｓ）、キャッシュ指示の送信スタンバイ状態に入る（ステップＳ９０３）。

ここで、混雑時間が経過するのを待って（ステップＳ９０４：Ｎｏ）、経過した場合（ステップＳ９０４：Ｙｅｓ）、送信スタンバイ状態から復帰して、送信部５０５により、リッチコンテンツのキャッシュ指示をキャッシュサーバ１０４に送信する（ステップＳ９０５）。また、ステップＳ９０２において、混雑時間帯ではなかった場合（ステップＳ９０２：Ｎｏ）、ステップＳ９０５に移行する。

これにより、通信トラフィックが増大する時間帯を回避して、リッチコンテンツのキャッシュ指示を送信することができる。

（キャッシュサーバの削除処理手順）
つぎに、本実施の形態にかかるキャッシュサーバ１０４のキャッシュ済みのリッチコンテンツの削除処理手順について説明する。図１０は、本実施の形態にかかるキャッシュサーバの削除処理手順の一例を示すフローチャートである。図１０のフローチャートにおいて、まず、受信部５１１により、フィードの購読者のクライアント端末１０５からリッチコンテンツの送信要求を受信したか否かを判断する（ステップＳ１００１）。

ここで、リッチコンテンツの送信要求を受信するのを待って（ステップＳ１００１：Ｎｏ）、受信した場合（ステップＳ１００１：Ｙｅｓ）、抽出部５１３により、受信部５１１によって受信された送信要求から特定されるリッチコンテンツをキャッシュＤＢ５２０の中から抽出する（ステップＳ１００２）。

このあと、送信部５１２により、抽出部５１３によって抽出されたリッチコンテンツを、送信要求の送信元のクライアント端末１０５に送信する（ステップＳ１００３）。ここで、送信部５１２によってリッチコンテンツが送信された結果、送信部５１２によるリッチコンテンツの送信回数をインクリメントする（ステップＳ１００４）。

このあと、判定部５１４により、送信部５１２によるリッチコンテンツの送信回数が購読者数以上となったか否かを判定する（ステップＳ１００５）。ここで、リッチコンテンツの送信回数が購読者数以上であった場合（ステップＳ１００５：Ｙｅｓ）、削除部５１５により、キャッシュＤＢ５２０の中から上記リッチコンテンツを削除する（ステップＳ１００６）。

最後に、送信部５１２により、キャッシュＤＢ５２０の中から上記リッチコンテンツを削除したことを表わす削除通知をコンテンツサーバ１０３に送信して（ステップＳ１００７）、本フローチャートによる一連の処理を終了する。また、ステップＳ１００５において、リッチコンテンツの送信回数が購読者数未満であった場合（ステップＳ１００５：Ｎｏ）、ステップＳ１００１に戻り一連の処理を繰り返す。

これにより、キャッシュＤＢ５２０の中から将来的にアクセスの増加が見込まれなくなったリッチコンテンツを削除することができる。

なお、本実施の形態では、キャッシュ制御装置１０１を、フィードを配信するコンピュータ装置に適用することとしたが、これに限らない。例えば、ＩＳＰごとに用意されるゲートウェイ装置にキャッシュ制御装置１０１を適用することとしてもよい。図１１は、コンテンツ配信システムの他のシステム構成を示す説明図である。

図１１において、コンテンツ配信システム１１００は、ゲートウェイ装置１１０１−１〜１１０１−ｎと、フィード配信サーバ１１０２と、ウェブサーバ１０２−１〜１０２−ｎと、コンテンツサーバ１０３と、キャッシュサーバ１０４−１〜１０４−ｎと、クライアント端末１０５−１〜１０５−ｎとがインターネット、ＬＡＮ、ＷＡＮなどのネットワーク１１０を介して相互に交信可能に接続されている。

ゲートウェイ装置１１０１−１〜１１０１−ｎは、キャッシュサーバ１０４−１〜１０４−ｎに対するリッチコンテンツのキャッシュを制御する機能を有するコンピュータ装置である。また、ゲートウェイ装置１１０１−１〜１１０１−ｎは、異なる媒体や通信プロトコルを使用するネットワーク間の通信を可能にする機能を有する。

フィード配信サーバ１１０２は、ウェブサーバ１０２−１〜１０２−ｎからのフィードを受信し、そのフィードを、ゲートウェイ装置１１０１−１〜１１０１−ｎまたは購読者のクライアント端末１０５−１〜１０５−ｎに配信する機能を有する。

ここでは、各ＩＳＰに属するクライアント端末１０５−１〜１０５−ｎの通信を管理するゲートウェイ装置１１０１−１〜１１０１−ｎにより、ＩＳＰごとのキャッシュ制御を実現する。これにより、複数のＩＳＰのネットワーク内のキャッシュ制御を一括しておこなう必要がなくなり、キャッシュ制御装置１０１にかかる負荷を軽減することができる。

具体的には、例えば、フィードの購読者数をＩＳＰごとに求める算出処理や、各ＩＳＰが運用するキャッシュサーバにリッチコンテンツのキャッシュ指示を送信する送信処理などが不要となる。

このように、本実施の形態によれば、フィードの購読者からのアクセスが発生する前に、将来的にアクセスの増加が見込まれるリッチコンテンツを効果的にキャッシュすることができる。具体的には、例えば、動画共有サイトなどに投稿されるコンテンツのような、将来的な視聴の動向を予測することが難しいコンテンツを効果的にキャッシュすることができる。

これにより、フィードから特定されるリッチコンテンツをキャッシュサーバ１０４からダウンロードすることができ、フィードの購読者によるリッチコンテンツの視聴時におけるコンテンツサーバ１０３の負荷を軽減させることができる。

また、通信トラフィックが増大する時間帯を回避して、リッチコンテンツのキャッシュ指示を送信することができる。これにより、フィード配信が引き金となって発生するリッチコンテンツへのアクセス時におけるネットワーク帯域の圧迫を防ぎ、コンテンツ配信システム１００，１１００内のネットワーク１１０の利用効率を向上させることができる。

また、フィードの購読者によるリッチコンテンツへのアクセス回数が購読者数相当となった場合に、そのリッチコンテンツをキャッシュＤＢ５２０の中から削除することができる。このように、将来的にアクセスの増加が見込まれなくなったリッチコンテンツをキャッシュＤＢ５２０の中から削除することにより、キャッシュＤＢ５２０の記憶領域の有効利用を図ることができる。

以上説明したように、キャッシュ制御プログラム、該プログラムを記録した記録媒体、キャッシュ制御装置、およびキャッシュ制御方法によれば、将来的にアクセスの増加が見込まれるコンテンツを効果的にキャッシュすることにより、通信品質の向上を図ることができる。

なお、本実施の形態で説明したキャッシュ制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネットなどのネットワークを介して配布することが可能な伝送媒体であってもよい。

以上の実施形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータを、
任意のサイトに関するフィードを受信する受信手段、
前記受信手段によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、前記フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する判断手段、
前記判断手段によってキャッシュが必要であると判断された場合、前記購読者の端末装置から前記リッチコンテンツの送信要求を受け付ける第２のサーバに、前記リッチコンテンツのキャッシュ指示を送信する送信手段、
として機能させることを特徴とするキャッシュ制御プログラム。

（付記２）前記送信手段は、
前記端末装置に対する前記フィードの配信に先立って、前記リッチコンテンツのキャッシュ指示を前記第２のサーバに送信することを特徴とする付記１に記載のキャッシュ制御プログラム。

（付記３）前記送信手段は、
前記端末装置が属するネットワーク内の通信トラフィックが増大する時間帯を特定するための混雑情報に基づいて、前記時間帯とは異なる他の時間帯に前記キャッシュ指示を前記第２のサーバに送信することを特徴とする付記１または２に記載のキャッシュ制御プログラム。

（付記４）前記判断手段は、
前記フィードの購読者数が予め設定された閾値以上であった場合に、前記リッチコンテンツのキャッシュが必要であると判断することを特徴とする付記１〜３のいずれか一つに記載のキャッシュ制御プログラム。

（付記５）前記判断手段は、
前記フィードの購読者が利用するインターネットサービスプロバイダごとの購読者数に基づいて、前記購読者数が予め設定された閾値以上であった場合に、前記インターネットサービスプロバイダが運用する第２のサーバに対する前記リッチコンテンツのキャッシュが必要であると判断することを特徴とする付記１〜４のいずれか一つに記載のキャッシュ制御プログラム。

（付記６）付記１〜５のいずれか一つに記載のキャッシュ制御プログラムを記録したコンピュータに読み取り可能な記録媒体。

（付記７）任意のサイトに関するフィードを受信する受信手段と、
前記受信手段によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、前記フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する判断手段と、
前記判断手段によってキャッシュが必要であると判断された場合、前記購読者の端末装置から前記リッチコンテンツの送信要求を受け付ける第２のサーバに、前記リッチコンテンツのキャッシュ指示を送信する送信手段と、
を備えることを特徴とするキャッシュ制御装置。

（付記８）任意のサイトに関するフィードを受信する受信工程と、
前記受信工程によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、前記フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する判断工程と、
前記判断工程によってキャッシュが必要であると判断された場合、前記購読者の端末装置から前記リッチコンテンツの送信要求を受け付ける第２のサーバに、前記リッチコンテンツのキャッシュ指示を送信する送信工程と、
を含んだことを特徴とするキャッシュ制御方法。

（付記９）任意のサイトに関するフィードから特定されるリッチコンテンツのキャッシュを制御するコンピュータ装置から、前記リッチコンテンツのキャッシュ指示を受信する受信手段と、
前記受信手段によって前記キャッシュ指示が受信された場合、当該キャッシュ指示から特定されるリッチコンテンツを格納するサーバに、前記リッチコンテンツの取得要求を送信する送信手段と、を備え、
前記受信手段は、
前記送信手段によって前記取得要求が送信された結果、前記サーバから前記リッチコンテンツを受信することを特徴とするキャッシュサーバ。

（付記１０）前記受信手段は、
前記フィードの購読者の端末装置から前記リッチコンテンツの送信要求を受信し、
前記送信手段は、
前記受信手段によって受信された送信要求から特定されるリッチコンテンツを前記端末装置に送信することを特徴とする付記９に記載のキャッシュサーバ。

（付記１１）前記送信手段による前記リッチコンテンツの送信回数が、前記受信手段によって受信されたキャッシュ指示から特定されるフィードの購読者数以上となったか否かを判定する判定手段と、
前記判定手段によって前記送信回数が前記フィードの購読者数以上と判定された場合、キャッシュ済みのコンテンツ群のうち前記リッチコンテンツを削除する削除手段と、を備えることを特徴とする付記１０に記載のキャッシュサーバ。

本実施の形態にかかるコンテンツ配信システムのシステム構成図である。 キャッシュ制御装置が備えるデータベースの記憶内容を示す説明図である。 コンテンツサーバが備えるキャッシュ情報ＤＢの記憶内容を示す説明図である。 この発明の実施の形態にかかるコンピュータ装置のハードウェア構成を示す説明図である。 コンテンツ配信システムの機能的構成を示すブロック図である。 フィードの具体例を示す説明図である。 本実施の形態にかかるキャッシュ制御装置のキャッシュ制御処理手順を示すフローチャートである。 判断処理の処理手順の一例を示すフローチャートである。 送信処理の処理手順の一例を示すフローチャートである。 本実施の形態にかかるキャッシュサーバの削除処理手順の一例を示すフローチャートである。 コンテンツ配信システムの他のシステム構成を示す説明図である。

符号の説明

１００，１１００ コンテンツ配信システム
１０１ キャッシュ制御装置
１０２，１０２−１〜１０２−ｎ ウェブサーバ
１０３ コンテンツサーバ
１０４，１０４−１〜１０４−ｎ キャッシュサーバ
１０５，１０５−１〜１０５−ｎ クライアント端末
２１０ 購読者情報ＤＢ
２１０−１〜２１０−ｉ 購読者情報
２２０ ＩＳＰ情報ＤＢ
２２０−１〜２２０−ｊ ＩＳＰ情報
２３０ 混雑情報ＤＢ
２３０−１〜２３０−ｋ 混雑情報
３１０ キャッシュ情報ＤＢ
３１０−１〜３１０−ｍ キャッシュ情報
５０１ 受信部
５０２ 判断部
５０３ 検出部
５０４ 抽出部
５０５ 送信部
５０６ 配信部
５１１ 受信部
５１２ 送信部
５１３ 抽出部
５１４ 判定部
５１５ 削除部
５２０ キャッシュＤＢ
６００ フィード
６１０，６２０，６３０ 挿入位置
１１０１−１〜１１０１−ｎ ゲートウェイ装置

Claims (8)

1. コンピュータを、
   任意のサイトに関するフィードを受信する受信手段、
   前記受信手段によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、前記フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する判断手段、
   前記判断手段によってキャッシュが必要であると判断された場合、前記購読者の端末装置から前記リッチコンテンツの送信要求を受け付ける第２のサーバに、前記リッチコンテンツのキャッシュ指示を送信する送信手段、
   として機能させることを特徴とするキャッシュ制御プログラム。
2. 前記送信手段は、
   前記端末装置に対する前記フィードの配信に先立って、前記リッチコンテンツのキャッシュ指示を前記第２のサーバに送信することを特徴とする請求項１に記載のキャッシュ制御プログラム。
3. 前記送信手段は、
   前記端末装置が属するネットワーク内の通信トラフィックが増大する時間帯を特定するための混雑情報に基づいて、前記時間帯とは異なる他の時間帯に前記キャッシュ指示を前記第２のサーバに送信することを特徴とする請求項１または２に記載のキャッシュ制御プログラム。
4. 前記判断手段は、
   前記フィードの購読者数が予め設定された閾値以上であった場合に、前記リッチコンテンツのキャッシュが必要であると判断することを特徴とする請求項１〜３のいずれか一つに記載のキャッシュ制御プログラム。
5. 前記判断手段は、
   前記フィードの購読者が利用するインターネットサービスプロバイダごとの購読者数に基づいて、前記購読者数が予め設定された閾値以上であった場合に、前記インターネットサービスプロバイダが運用する第２のサーバに対する前記リッチコンテンツのキャッシュが必要であると判断することを特徴とする請求項１〜４のいずれか一つに記載のキャッシュ制御プログラム。
6. 請求項１〜５のいずれか一つに記載のキャッシュ制御プログラムを記録したコンピュータに読み取り可能な記録媒体。
7. 任意のサイトに関するフィードを受信する受信手段と、
   前記受信手段によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、前記フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する判断手段と、
   前記判断手段によってキャッシュが必要であると判断された場合、前記購読者の端末装置から前記リッチコンテンツの送信要求を受け付ける第２のサーバに、前記リッチコンテンツのキャッシュ指示を送信する送信手段と、
   を備えることを特徴とするキャッシュ制御装置。
8. 任意のサイトに関するフィードを受信する受信工程と、
   前記受信工程によって受信されたフィードの購読者数に基づいて、第１のサーバに格納されているコンテンツのうち、前記フィードから特定されるリッチコンテンツをキャッシュするか否かを判断する判断工程と、
   前記判断工程によってキャッシュが必要であると判断された場合、前記購読者の端末装置から前記リッチコンテンツの送信要求を受け付ける第２のサーバに、前記リッチコンテンツのキャッシュ指示を送信する送信工程と、
   を含んだことを特徴とするキャッシュ制御方法。

Images