コンテンツキャッシュ装置、コンテンツキャッシュ方法およびコンピュータプログラム
【課題】保持すべき情報量を低減しつつ、過去に視聴した番組の再視聴を行うことを可能にする。
【解決手段】第1取得部は、ブックマーク指示に応じて、シナリオで定められているリソースを当該リソースの識別子に応じたロケーションから取得する。保持判断部は、取得されたリソースと同じ識別子かつ同じ構成をもつリソースがキャッシュ保持部に存在するときは、リソースと識別子と受付時刻情報をキャッシュ保持部から削除し、存在しないときは前記リソースとその識別子と、前記ブックマーク指示の受付時刻情報をキャッシュ保持部に格納する。再生指示を受けた第1シナリオに関して、第2取得部は、第1シナリオで指定されたリソースの識別子がキャッシュ保持部に存在するときは前記第1シナリオに対応付けられた受付時刻情報と前記リソースの識別子に応じてキャッシュ保持部から、存在しないときは前記リソースの識別子に応じたロケーションからリソースを取得する。
【解決手段】第1取得部は、ブックマーク指示に応じて、シナリオで定められているリソースを当該リソースの識別子に応じたロケーションから取得する。保持判断部は、取得されたリソースと同じ識別子かつ同じ構成をもつリソースがキャッシュ保持部に存在するときは、リソースと識別子と受付時刻情報をキャッシュ保持部から削除し、存在しないときは前記リソースとその識別子と、前記ブックマーク指示の受付時刻情報をキャッシュ保持部に格納する。再生指示を受けた第1シナリオに関して、第2取得部は、第1シナリオで指定されたリソースの識別子がキャッシュ保持部に存在するときは前記第1シナリオに対応付けられた受付時刻情報と前記リソースの識別子に応じてキャッシュ保持部から、存在しないときは前記リソースの識別子に応じたロケーションからリソースを取得する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、コンテンツキャッシュ装置、コンテンツキャッシュ方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
インターネット上の情報（Web リソース）を複数組み合わせたコンテンツを合成し、合成したコンテンツを番組として、ユーザに視聴させるコンテンツ合成装置が知られている。これはインターネット上の画像、テキスト、音声、動画などが存在し、それら元コンテンツを設計図に基づいてユーザが持つ端末が合成することを想定している。この時、この設計図をシナリオと呼ぶ。
【０００３】
ユーザが、端末で一度視聴したコンテンツを再度視聴する場合がある。一度ユーザが持つ端末で視聴した番組を、再度ユーザが見たい場合、どこかに情報を保持しておく必要がある。情報を保持する場所として、一般的には以下の3つの場合が考えられる。
（1）ユーザが持つ端末
（2）ユーザが持つ別の端末
（3）サーバ
【０００４】
（1）のユーザが持つ端末として、携帯端末が考えられる。この場合、端末が保持できる容量は少ないと考えられるため、ユーザが持つ端末に情報を保持することは考えにくい。
【０００５】
（2）のユーザが持つ別の端末として、例えば家庭内にあるテレビやホームサーバ、ユーザ自身が持つネットワーク上のサーバなどが考えられる。しかしながら、これらはユーザが保持しているとは必ずしも言えない。
【０００６】
（3）のサービスを提供するサーバが情報を保持する場合、多くのユーザに対して同一のサービスを行う必要がある。そのため、一人一人が保存する情報量が積算され、大量の情報を保持することになってしまう。この問題を解決するため、従来技術として、同じデータであれば異なるユーザ間であっても共有する、という手法が、提案されている。しかし、この手法では、少なくとも1つの情報は、家庭内や共同保有サーバといったユーザ近くに、保持しておく必要がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開2001-159998号公報
【特許文献２】特開2004-166189号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、保持すべき情報量を低減しつつ、過去に視聴した番組の再視聴を行うことを可能にするコンテンツキャッシュ装置、コンテンツキャッシュ方法およびコンピュータプログラムを提供する。
【課題を解決するための手段】
【０００９】
本発明の実施形態としてのコンテンツキャッシュ装置は、BM保存指示受信部と、ブックマーク履歴保持部と、第1取得部と、キャッシュ保持部と、保持判断部と、再生指示受信部、第2取得部と、マッシュアップ部と、出力部とを備える。
【００１０】
前記BM保存指示受信部は、それぞれ識別子を有する複数のリソースの合成方法を定めたシナリオのブックマーク指示を受け付ける。
【００１１】
前記ブックマーク履歴保持部は、前記ブックマーク指示がなされたシナリオを、前記BM保存指示受信部での前記ブックマーク指示の受付時刻情報に関連づけて、記憶する。
【００１２】
前記第1取得部は、前記シナリオで定められた前記リソースを、前記リソースの前記識別子に応じたロケーションから取得する。
【００１３】
前記キャッシュ保持部は、リソースと、前記リソースの識別子と、受付時刻情報とを関連づけて記憶する。
【００１４】
前記保持判断部は、前記第1取得部により取得されたリソースと同じ識別子かつ同じ構成をもつリソースが前記キャッシュ保持部に存在するときは、前記リソースと前記リソースの識別子と前記受付時刻情報とを前記キャッシュ保持部から削除し、存在しないときは、前記取得されたリソースと、前記取得されたリソースの識別子と、前記ブックマーク指示の前記受付時刻情報とを関連づけて、前記キャッシュ保持部に格納する。
【００１５】
前記再生指示受信部は、前記ブックマーク履歴保持部に保持されたシナリオのうちの1つである第1シナリオの再生指示を受け付ける。
【００１６】
前記第2取得部は、前記第1シナリオで指定されたリソースの識別子が前記キャッシュ保持部に存在するときは、前記第1シナリオに関連づけられた受付時刻情報と前記リソースの識別子に応じて、前記キャッシュ保持部から前記リソースを取得し、存在しないときは前記識別子に応じたロケーションから前記リソースを取得する。
【００１７】
前記マッシュアップ部は、前記第1シナリオの再生指示に応じて前記第2取得部で取得されたリソースを合成することにより、番組を生成する。
【００１８】
前記出力部は、前記番組を出力する。
【図面の簡単な説明】
【００１９】
【図１】本実施形態に係るコンテンツキャッシュ装置としてのWebリソースキャッシュ装置の構成を示す。
【図２】端末からBM 保存を指示されたときの図1の装置の動作を示す。
【図３】保持判断の動作フローを示す。
【図４】BM履歴を要求されたときの本装置の動作を示す。
【図５】BM再生を指示されたときの本装置の動作を示す。
【図６】BM履歴保持部が持つBM履歴のデータ例を示す。
【図７】キャッシュ保持部が持つデータの例を示す。
【発明を実施するための形態】
【００２０】
本実施形態の概要について説明する。本実施形態は、ある設計図に基づいてWeb 上に存在する画像、テキスト、音声、動画などの複数のWeb リソースを、ユーザが持つ端末が取得・加工し、一固まりのコンテンツとしてユーザに提示することを想定している。この時、Webリソースを取得・加工することをマッシュアップと呼び、マッシュアップを指示する設計図をシナリオと呼ぶ。また、マッシュアップによって作成されたコンテンツを「番組」と呼ぶ。番組とは、TV 放送の番組と同じく、テキスト・画像・音声・映像などを連続的に映しだすものだけではなく、テキストだけ、画像だけ、音声だけを映し出すもの、テキストを読み上げるもの、映像が自動的に移り変わるだけでなくユーザの入力を待つものなど、さまざま種類のコンテンツが考えられる。
【００２１】
このような端末を使用しているとき、ユーザは一度視聴した番組を再度視聴したい場合がある。ここで、再度視聴するために蓄えておくシナリオとWeb リソースの一セットを、ブックマーク(BM) と定義する。BMは、シナリオの他、画像、テキスト、音声、動画といった番組内で使用する、あるいはマッシュアップ過程で必要になる一連のWeb リソースを一つにまとめたものである。Web リソースとはURI で識別される単一の情報であり、BM は番組の再生に必要なシナリオと単一あるいは複数のWeb リソースをまとめたものである、という違いがある。
【００２２】
本実施形態で前提としているインターネット上のWeb リソースをユーザが持つ端末で合成し、提示するという構成では、インターネット上に元となるWeb コンテンツが存在している。従って、ユーザが番組を再度視聴したいと考えた場合には、元となるWeb リソースがインターネット上にまだ存在している可能性もあるし、もはや存在しない（消えるまたは変化している）場合もあり得る。
【００２３】
本実施形態では、インターネット上から消える、または変化する可能性が高いと判断した情報については、その情報をコンテンツキャッシュ装置（Webリソースキャッシュ装置）にキャッシュしておき、再視聴時には、キャッシュした情報を用いる。
【００２４】
一方、インターネット上に今後も存在する可能性が高いと判断したWebリソースについては、その情報をコンテンツキャッシュ装置に保持せずに、再視聴時に、再度、インターネット上から取得するようにする。つまり、ユーザがこの元となるWeb リソースを保持している必要はなく、番組を再度見たい場合は、再度インターネット上から取得すれば良い。
【００２５】
以上により、ユーザが持つ端末あるいはサーバが保持すべき情報量を低減できるとともに、必要なWebリソースの不存在によりBM が再生できなくなる可能性を低減させることができる。
【００２６】
以下、本実施形態について詳細に説明する。
【００２７】
図1に、本実施形態に係るコンテンツキャッシュ装置としてのWebリソースキャッシュ装置101の構成を示す。
【００２８】
図1のコンテンツキャッシュ装置は、BM保存指示受信部102、シナリオ保持部103、BM履歴保持部104、マッシュアップ部105、取得部（第1取得部、第2取得部）106、キャッシュ保持部107、保持判断部108および要求受信部（再生指示受信部、出力部）109を備える。なお第1取得部はBM保存指示（後述）時にWebリソースを取得し、第2取得部はシナリオ再生時にWebリソースを取得する機能をさすが、第1取得部と第2取得部は物理的に同一のデバイスであっても、別々のデバイスであってもかまわない。
【００２９】
BM保存指示受信部102は、端末Aと無線または有線により通信可能に構成される。要求受信部109は、端末Bと無線または有線により、通信可能に構成される。取得部106は、インターネット等のネットワーク301を介して、複数のサーバ201と通信可能に構成される。端末Aは、シナリオのブックマークを指示する端末であり、ユーザにより操作される。端末Bは、シナリオの再生を指示する端末であり、ユーザにより操作される。端末Bは、端末Aと同一装置であってもよいし、別の装置であってもよい。本コンテンツキャッシュ装置は、ユーザ宅内にサーバとして配置されてもよいし、インターネット上に配置されてもよい。
【００３０】
以下、図2〜図5のフローチャートを用いて、本装置が備える各ブロックの機能、および全体の動作を説明する。
【００３１】
図2に、本装置が端末AからBM 保存を指示されたときの動作を示す。
【００３２】
BM 保存指示受信部102は、ユーザが持つ端末Aから送られたBM 保存指示を受け取る(ステップS11)。このBM 保存指示の中には、シナリオを識別する識別子（シナリオ識別子）が格納されている。
【００３３】
識別子はURI などの文字列や数値で構成される。シナリオは、複数のWeb リソースのリソース(URI等)を指定し、当該複数のWebリソースの合成方法（再生方法）を定めている。
【００３４】
端末Aは、シナリオの再生中に、当該シナリオに対するBM保存指示を行ってもよいし、過去に再生したシナリオの一覧からシナリオを選択して、BM保存指示を行ってもよい。あるいはその他の方法でシナリオを指定し、BM保存指示を行ってもよい。
【００３５】
BM 保存指示受信部102は、BM 保存指示に格納されているシナリオ識別子を元に、シナリオ保持部103にシナリオを要求し、シナリオ保持部103からシナリオを取得する(ステップS12)。
【００３６】
本実施形態ではシナリオ保持部103は、本装置内に設けられているが、本装置と有線あるいは無線接続された場所や、インターネット301上にあっても良い。また、BM 保存指示受信部102内に、一定数のシナリオをあらかじめ保持しておき、シナリオ取得にかかる時間を軽減しても良い。
【００３７】
BM 保存指示受信部102は、BM保存を指示したユーザの識別子（ユーザ識別子）と、シナリオ識別子と、BM保存指示の受付時刻情報とを含めたBM 保存指示を、BM履歴保持部104に送る(ステップS13)。受付時刻情報は、BM保存指示がなされた時刻（BM保存指示時刻）、すなわちBM保存指示を受け付けた時刻を表す。ユーザ識別子は、BM保存指示と同時に取得してもよいし、ユーザ認証を行う場合などは、別途の認証の手続時に取得してもよい。
【００３８】
BM保存指示を受けたBM履歴保持部104は、ユーザ識別子と、シナリオ識別子と、BM保存指示時刻とを1セットにして、BM履歴として、保持する。
【００３９】
図6に、BM履歴保持部104が持つBM履歴のデータ例を示す。
【００４０】
BM履歴保持部104は、一定量のBM 履歴を保持可能である。図示の例では、BM履歴に再生回数も含めている。再生回数は、後述する端末Bからの再生指示に応じて再生されたシナリオの再生回数である。図示の時刻は、年・日時・時分・秒を含んでいるが、これらのすべてを含まなくてもよい。たとえば年を省略してもよい。
【００４１】
BM履歴保持部104は、BM 保存指示を受けてから一定時間が経過した場合、ユーザからの指示を受けた場合は、該当するデータを消去してもよい。また、保持可能な容量（記憶容量）を超えた場合に、データの一部を消去してもよい。消去するデータは、たとえばシナリオの再生回数、各シナリオのシナリオ間での再生回数の比率、またはBM保存指示時刻をもとに決定してもよい。または、ランダムに決定することも可能である。ユーザの保存指示があったデータ、再生回数が一定値以上のデータは、消去対象から除外してもよい。
【００４２】
BM 保存指示受信部102は、シナリオ保持部103から取得したシナリオ、および受付時刻情報（BM保存指示時刻）を、マッシュアップ部105に送る(ステップS14)。
【００４３】
マッシュアップ部105は、BM 保存指示受信部102から送られたシナリオに基づき、当該シナリオのマッシュアップに必要となるWebリソースを特定する (ステップS15)。マッシュアップ部105は、必要になるWeb リソース、すなわちシナリオで指定されたWebリソースの取得を指示した取得指示情報を、取得部106に送る(ステップS16)。取得指示情報には、取得を指示するWebリソースの識別子（ここではURI)、BM保存指示時刻等を含める。
【００４４】
取得部106は、マッシュアップ部105から指示されたWeb リソースを、当該Webリソースの識別子を元に、インターネット301上のWeb リソース保持サーバ201から取得することを試みる (ステップS17)。
【００４５】
Webリソース保持サーバ201から取得できなかったWebリソースについては、キャッシュ保持部107にキャッシュ取得要求を送る(ステップS20)。キャッシュ保持部107は、キャッシュされている該当するWeb リソース（たとえば同一識別子を有する、同一または最新のBM保存指示時刻が関連づけられたWebリソース）を取得部106に送る (ステップS21)。
【００４６】
外部から取得できず、キャッシュ保持部107にもキャッシュもないWebリソースについては、取得できなかった旨を、マッシュアップ部105に返す。この場合、マッシュアップ部105は、当該Webリソースが取得できなかった旨をユーザに提示しても良い。
【００４７】
なお、ステップS20、S21では、Webリソース保持サーバ201からWebリソースを取得できなかったときはキャッシュ保持部107からキャッシュの取得を試みているが、この処理は本質ではないため、省略することも可能である。この場合、取得できなかった旨を、マッシュアップ部105に返せばよい。
【００４８】
取得部106は、Web リソース保持サーバ201から取得したWeb リソースと、マッシュアップ部105から得た取得指示情報（BM保存指示時刻、Webリソース識別子等）を、保持判断部108に、一セットとして送る(ステップS19)。
【００４９】
このとき、取得部106は、取得したWebリソースのハッシュ値を計算し、ハッシュ値を保持判断部108に送っても良い。Webリソースのハッシュ値を送ることにより、後述するように、同一の識別子を持つWebリソースであっても、Web リソースの内容が変化したことを、高速に検知できる。
【００５０】
保持判断部108は、取得部106から送られてきたデータを元に、取得したWebリソースをキャッシュするかどうかを決定する(ステップS22)。
【００５１】
保持判断部108が保持すると決定した場合、当該Web リソース、その識別子、BM保存指示時刻をキャッシュ保持部107に送り(ステップS23)、キャッシュ保持部107は送られてきたWeb リソース、Webリソース識別子およびBM保存指示時刻を保持する(ステップS24)。このとき、キャッシュ保持部107にハッシュ値も送り、キャッシュ保持部107に当該ハッシュ値を保持してもよい。
【００５２】
図7にキャッシュ保持部107が持つデータの例を示す。1つの行が1つのレコードに対応する。この例では、Webリソース識別子、BM保存指示時刻、Webリソースのデータ（ビット）、Webリソースのハッシュ値を保持している。ハッシュ値が同一であるリソース同士は、互いに同一の構成（データ）を有することを意味する。キャッシュ保持部107に保持されているWebリソースは、単にキャッシュと称されることもある。同一の識別子を持つWeb リソースであっても、BM保存指示時刻が違う場合は、それぞれ別々に保持され得る。これにより、過去の特定時刻におけるWeb リソースを得ることができる。なお、当該Webリソースを利用するシナリオを識別し、再生頻度などそのシナリオに応じた判断を行うために、シナリオIDをキャッシュ保持部107に追加してもよい。
【００５３】
キャッシュ保持部107は、保持してから一定時間が経過した場合、該当するデータ（レコード）を消去してもよい。また、一定確率でキャッシュを削除する方法もある。この場合、この確率はユーザの設定、番組の内容、BM の再生率、BM の再生回数によって動的に変動しても良い。また、BM の再生に支障がない範囲のWeb リソースは優先的に削除しても良い。キャッシュ保持部107は、BM履歴保持部104でシナリオが消去された際、当該消去されたシナリオで用いられており、かつBM履歴保持部104で保持される他のシナリオで用いられない、リソースを消去してもよい。
【００５４】
保持判断部108が、保持しないと判断した場合、保持判断部108はキャッシュ保持部107にキャッシュの削除を指示し、(ステップS25)、キャッシュ保持部107はキャッシュおよびそれに関連づけられたWebリソース識別子、BM保存指示時刻、ハッシュ値等を、削除する(ステップS26)。キャッシュの削除指示のタイミングは、保持しないと判断した時点でもよいし、処理負荷を下げるために、後の別のタイミングでも構わない。
【００５５】
以下、ステップS22で行われる保持判断処理について、さらに詳細に説明する。
【００５６】
図3に、保持判断の動作フローを示す。
【００５７】
保持判断部108が、取得部106から、Web リソース（ハッシュ値が送られてきた場合は当該ハッシュ値）と、Web リソースの識別子と、取得指示情報に含まれるBM保存指示時刻とを受け取る（ステップS31）。
【００５８】
保持判断部108は、当該Web リソースと同じ識別子のリソースが、過去に要求されたことがあるかを、判断する（S32）。これは、当該Webリソースと同じ識別子が、キャッシュ保持部に保持されているか否かを確認することで行う。
【００５９】
今まで要求されたことがない判断したときは、当該Webリソースを、キャッシュ保持部107に保持させることを決定する（ステップS34）。キャッシュ保持部107は、当該Webリソースを、その識別子、BM保存指示時刻、およびハッシュ値とともに、保持する。
【００６０】
当該Web リソースと同じ識別子のリソースが過去に要求されたことがある場合は、以下のチェックを行う。
【００６１】
キャッシュ保持部107に保持されている同一識別子のWeb リソース（キャッシュ）の構成は、取得したWeb リソースと異なっているか否かを判断する（ステップS33）。すなわち両Webリソースのデータ（ビット）が一致するかを判断する。取得部106からWebリソースのハッシュ値が送られてきた場合は、データ同士の比較の代わりに、送られてきたハッシュ値と、キャッシュされているハッシュ値同士を比較することで、高速な判断が可能である。
【００６２】
ステップS33の判断において、取得したWebリソースと、保存されているWebリソース（キャッシュ）の構成が互いに異なる場合は、当該取得したWebリソースを、キャッシュ保持部107に保持させることを決定する（ステップS34）。キャッシュ保持部107は、当該Webリソースを、その識別子、BM保存指示時刻、およびハッシュ値とともに、保持する。
【００６３】
取得したWebリソースと、保存されているWebリソース（キャッシュ）の構成が互いに一致する場合は、当該キャッシュのBM保存指示時刻をチェックする（ステップS35）。
【００６４】
キャッシュの保存時刻が、対象とするBM保存指示時刻（取得部106から送られてきたBM保存指示時刻）の一定時間前よりも時間的に後の場合、すなわち、対象とするBM保存指示時刻と、キャッシュのBM保存指示時刻との時間差の大きさが閾値未満の場合、当該キャッシュとその関連データを削除するとともに、取得したWebリソースは保持しないことを決定する（ステップS36）。
【００６５】
ここで一定時間とは一ヶ月など比較的長期間を指す。複数回当該Web リソースの取得が指示され、その間にWebリソース保持サーバから得たWeb リソースが変化していない場合において、その間隔が短ければ、次にまた取得が指示されるまでの間隔が短く、かつ、Web リソースが異なっていない（すなわち同じである）ということが推定できるため、キャッシュを削除しても良いと判断する。
【００６６】
一方、キャッシュのBM指示保存時刻が、対象とするBM保存指示時刻の一定時間前よりも時間的にさらに前の場合、すなわち、対象とするBM保存指示時刻と、キャッシュのBM保存指示時刻との時間差の大きさが閾値以上の場合、当該キャッシュをそのまま保持し、取得したWebリソースを保持しないことを決定する（ステップS34）。これを第1の方式と呼ぶ。この際、代替方法として、当該キャッシュのBM指示保存時刻を、対象とするBM保存指示時刻に更新してもよい（第2の方式）。または、取得した対象とするBM保存指示時刻とWebリソースの識別子のみをキャッシュ保持部107に格納し、Webリソースのデータ本体（ビット）については、キャッシュのものを参照するようにしてもよい（第3の方式）。第3の方式の場合、キャッシュ保持部のテーブルに、参照すべきレコードのIDを参照するフィールドを追加すればよい。
【００６７】
第1の方式および第2の方式は、キャッシュ保持部の容量をできるだけ抑えたい場合に有効である。インターネット上の、あるリソースの内容（構成）が変化した後、そのリソースは元の内容には戻らない（もしくはその可能性が非常に少ない）前提では、キャッシュされていたBM保存指示時刻または対象とするBM保存指示時刻のシナリオを再生する際、指示時と同一内容の再生を行う可能性を非常に高めることができる。第3の方式は、第1および第2方式よりも若干、キャッシュ保持部107の容量を上昇させるが、より確実な再生を可能にする手法である。
【００６８】
以上、図2を用いて述べてきた説明は、BM 保存を指示された時の動作である。以下、BM 再生を行う場合の動作を記す。BM再生を行う場合、BM を再生したい端末(以下、端末B)が、本装置からBMM履歴（BMリスト）を取得し、再生するBMを指定する。
【００６９】
図4にBM履歴を要求された場合の本装置の動作を示す。
【００７０】
図5に、BM再生を指示されたときの本装置の動作を示す。
【００７１】
図4において、BM を再生したい端末(以下、端末B) は、まず要求受信部109に対して、BM 履歴の閲覧要求を送出する(ステップS41)。なお再生端末BはBM 保存指示を行った端末Aと同一でも構わないし、異なっていても構わない。これにより、例えば外出時に携帯端末から見ていたコンテンツをBM し、帰宅後に大画面テレビでより高精細な情報を続きから、あるいはもう一度楽しむことができる。
【００７２】
要求受信部109は、BM履歴保持部104に、BM 履歴の取得要求を送る (ステップS42)。
【００７３】
BM履歴保持部104は、要求受信部109に、BM 履歴を渡す(ステップS43)。BM 履歴には、BM が複数含まれている。
【００７４】
要求受信部109は、端末B に、BM 履歴を渡す(ステップS44)。端末Bは、このBM履歴をユーザに提示することで、どのBMを再生するか 、すなわちどのシナリオを再生するかを、ユーザに選択させる。再生するべく選択したシナリオは、第1シナリオに対応する。
【００７５】
図5において、ユーザにより再生するBM が指示されたとき、端末B は要求受信部109に、BM再生指示を送る(ステップS51)。
【００７６】
再生要求を受けた要求受信部109は、指定されたBMの受付時刻情報（BM保存指示時刻）とシナリオとを、マッシュアップ部105に送る(ステップS52)。
【００７７】
マッシュアップ部105が、シナリオのマッシュアップを行う。まず、シナリオで指定される、マッシュアップに必要なWeb リソースを特定し（ステップS53）、特定したWebリソースの取得要求を、取得部106に送る(ステップS54)。取得要求には、上記BM保存指示時刻と、取得したいWebリソースの識別子とが含まれる。
【００７８】
取得部106は、このBM保存指示時刻とWeb リソースの識別子を元に、キャッシュ保持部107に、キャッシュの取得要求を送る (ステップS55)。当該キャッシュの取得要求には、当該BM保存指示時刻と、当該Webリソースの識別子が含まれる。
【００７９】
キャッシュ保持部107は、当該Webリソースの識別子と同じ識別子が関連づけられ、かつ当該BM保存指示時刻と同じ時刻が関連づけられたキャッシュ（Web リソース）が存在するかを調べる（ステップS56）。存在する場合は、そのキャッシュを、取得部106に返し、取得部106は、さらに当該キャッシュをマッシュアップ部105に送る (ステップS57)。
【００８０】
このとき、図3のステップS34で第1の方式を用いた場合は、本ステップS56でキャッシュが存在しないと判断された場合、以下の処理を行っても良い。すなわち、当該Webリソースの識別子と同じ識別子に関連づけられたキャッシュが存在するかを調べ、存在する場合は、当該BM保存指示時刻に最も近い過去のキャッシュを、取得部106に返す。これは、第1の方式として、図3のステップS33で、同一構成であると判断された2つのWebリソースのうち、キャッシュ保持部107に元々存在したいた方をそのまま残し、他方（Webリソース保持サーバ201から取得したWebリソース）を削除したことによるものである。この第1の方式は、前述したように、インターネット上の、あるリソースの内容（構成）が変化した後、そのリソースは元の内容には戻る可能性は低い状況において有効である。ただし、元の内容に戻っても、動作に支障は生じない。なお、元の内容に戻る可能性がないという前提を設定し、第1の方式を採用するのであれば、図3のステップS33の判断では、同一識別子のWebリソース（キャッシュ）が複数、キャッシュ保持部107に存在するときは、対象となるBM保存指示時刻から時間的に最も近いWebリソースとのみ、同一か否かの比較を行ってもよい。
【００８１】
図3のステップS34で第2の方式を用いた場合も同様の考えで、本ステップS56でキャッシュが存在しないと判断された場合、当該Webリソースの識別子と同じ識別子に関連づけられたキャッシュが存在する場合は、当該BM保存指示時刻に最も近い将来のキャッシュを、取得部106に返すようにしてもよい。
【００８２】
一方、当該するキャッシュが存在しない場合、キャッシュ保持部107は、その旨を取得部106に返し、取得部106は、当該Webリソースの識別子をもとに、Web リソース保持サーバ201からWeb リソースの取得を試みる（S58）。なお、BM保存指示がなされたときにWeb リソースは少なくとも一度は取得されているため（図2のステップS17参照）、ここでキャッシュがない場合とは、保持判断部108がキャッシュを保持する必要がないと判断したWeb リソースであるということを示す（図2のステップS22、S25参照）。
【００８３】
取得部106は、Webリソースを取得できなかったときは、すなわちインターネット301上に当該Webリソースが存在しなかったときは、その旨をマッシュアップ部105に通知する（S58、S59）。
【００８４】
Webリソースを取得できたときは、取得部106は、取得したWebリソースを、マッシュアップ部105に送る（S58、S60）。
【００８５】
マッシュアップ部105は、取得部106から取得したWeb リソースを用いて、シナリオのマッシュアップを完成し、マッシュアップの結果である番組を、要求受信部109に返す(ステップS61)。取得できなかったWebリソースが存在する場合は、その部分には適当なリソースを配置してもよい。適当なリソースは、本装置に事前に記憶しておいてもよいし、ネットワーク上のサーバから任意の方法で取得してもよい。たとえば、類似情報を検索して利用したり、広告などの代わりのコンテンツを利用したりしても良い。
【００８６】
要求受信部109は、マッシュアップ部105から渡された番組を、端末B に送る(ステップS62)。
【００８７】
端末B は、要求受信部109から受けた番組を表示する（ステップS63）。これにより、BM 保存指示があった時点のシナリオを、端末B にて再生できる。
【００８８】
以上、本実施形態によれば、BM指示のなされたシナリオで定められたWebリソースのうち、後の再視聴時にもネットワーク上から取得できると判断でしたWebリソースについては本装置が保持しないようにしたことにより、従来よりも保持すべき情報量をさらに低減できる。
【００８９】
なお、本方式では、保持判断部108が保持しないと判断したWeb リソースが、インターネット上で消えた場合や変更された場合には、そのWeb リソースを取得できなくなり、BM 保存指示がされたシナリオと同じ番組を、合成できないこととなる。しかしながら、本実施形態は、このリスクをある程度許容することで、キャッシュ保持容量を軽減するものであり、キャッシュ装置の保持容量の削減に、大きく寄与するものと考えられる。
【００９０】
なお、本実施形態では、Web リソースはインターネット上のサーバに保持されているとしたが、その他同一端末内、ホームネットワークやLAN 上にあっても良い。また、Web リソースの識別子はURI を想定しているが、その他ファイルパスやIP アドレスなどであっても良い。
【００９１】
なお、上記の実施形態に示したWebリソースキャッシュ装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、当該装置における各要素は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、本装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、同装置内の保持部103，104、107は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
【００９２】
また、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【技術分野】
【０００１】
本発明の実施形態は、コンテンツキャッシュ装置、コンテンツキャッシュ方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
インターネット上の情報（Web リソース）を複数組み合わせたコンテンツを合成し、合成したコンテンツを番組として、ユーザに視聴させるコンテンツ合成装置が知られている。これはインターネット上の画像、テキスト、音声、動画などが存在し、それら元コンテンツを設計図に基づいてユーザが持つ端末が合成することを想定している。この時、この設計図をシナリオと呼ぶ。
【０００３】
ユーザが、端末で一度視聴したコンテンツを再度視聴する場合がある。一度ユーザが持つ端末で視聴した番組を、再度ユーザが見たい場合、どこかに情報を保持しておく必要がある。情報を保持する場所として、一般的には以下の3つの場合が考えられる。
（1）ユーザが持つ端末
（2）ユーザが持つ別の端末
（3）サーバ
【０００４】
（1）のユーザが持つ端末として、携帯端末が考えられる。この場合、端末が保持できる容量は少ないと考えられるため、ユーザが持つ端末に情報を保持することは考えにくい。
【０００５】
（2）のユーザが持つ別の端末として、例えば家庭内にあるテレビやホームサーバ、ユーザ自身が持つネットワーク上のサーバなどが考えられる。しかしながら、これらはユーザが保持しているとは必ずしも言えない。
【０００６】
（3）のサービスを提供するサーバが情報を保持する場合、多くのユーザに対して同一のサービスを行う必要がある。そのため、一人一人が保存する情報量が積算され、大量の情報を保持することになってしまう。この問題を解決するため、従来技術として、同じデータであれば異なるユーザ間であっても共有する、という手法が、提案されている。しかし、この手法では、少なくとも1つの情報は、家庭内や共同保有サーバといったユーザ近くに、保持しておく必要がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開2001-159998号公報
【特許文献２】特開2004-166189号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、保持すべき情報量を低減しつつ、過去に視聴した番組の再視聴を行うことを可能にするコンテンツキャッシュ装置、コンテンツキャッシュ方法およびコンピュータプログラムを提供する。
【課題を解決するための手段】
【０００９】
本発明の実施形態としてのコンテンツキャッシュ装置は、BM保存指示受信部と、ブックマーク履歴保持部と、第1取得部と、キャッシュ保持部と、保持判断部と、再生指示受信部、第2取得部と、マッシュアップ部と、出力部とを備える。
【００１０】
前記BM保存指示受信部は、それぞれ識別子を有する複数のリソースの合成方法を定めたシナリオのブックマーク指示を受け付ける。
【００１１】
前記ブックマーク履歴保持部は、前記ブックマーク指示がなされたシナリオを、前記BM保存指示受信部での前記ブックマーク指示の受付時刻情報に関連づけて、記憶する。
【００１２】
前記第1取得部は、前記シナリオで定められた前記リソースを、前記リソースの前記識別子に応じたロケーションから取得する。
【００１３】
前記キャッシュ保持部は、リソースと、前記リソースの識別子と、受付時刻情報とを関連づけて記憶する。
【００１４】
前記保持判断部は、前記第1取得部により取得されたリソースと同じ識別子かつ同じ構成をもつリソースが前記キャッシュ保持部に存在するときは、前記リソースと前記リソースの識別子と前記受付時刻情報とを前記キャッシュ保持部から削除し、存在しないときは、前記取得されたリソースと、前記取得されたリソースの識別子と、前記ブックマーク指示の前記受付時刻情報とを関連づけて、前記キャッシュ保持部に格納する。
【００１５】
前記再生指示受信部は、前記ブックマーク履歴保持部に保持されたシナリオのうちの1つである第1シナリオの再生指示を受け付ける。
【００１６】
前記第2取得部は、前記第1シナリオで指定されたリソースの識別子が前記キャッシュ保持部に存在するときは、前記第1シナリオに関連づけられた受付時刻情報と前記リソースの識別子に応じて、前記キャッシュ保持部から前記リソースを取得し、存在しないときは前記識別子に応じたロケーションから前記リソースを取得する。
【００１７】
前記マッシュアップ部は、前記第1シナリオの再生指示に応じて前記第2取得部で取得されたリソースを合成することにより、番組を生成する。
【００１８】
前記出力部は、前記番組を出力する。
【図面の簡単な説明】
【００１９】
【図１】本実施形態に係るコンテンツキャッシュ装置としてのWebリソースキャッシュ装置の構成を示す。
【図２】端末からBM 保存を指示されたときの図1の装置の動作を示す。
【図３】保持判断の動作フローを示す。
【図４】BM履歴を要求されたときの本装置の動作を示す。
【図５】BM再生を指示されたときの本装置の動作を示す。
【図６】BM履歴保持部が持つBM履歴のデータ例を示す。
【図７】キャッシュ保持部が持つデータの例を示す。
【発明を実施するための形態】
【００２０】
本実施形態の概要について説明する。本実施形態は、ある設計図に基づいてWeb 上に存在する画像、テキスト、音声、動画などの複数のWeb リソースを、ユーザが持つ端末が取得・加工し、一固まりのコンテンツとしてユーザに提示することを想定している。この時、Webリソースを取得・加工することをマッシュアップと呼び、マッシュアップを指示する設計図をシナリオと呼ぶ。また、マッシュアップによって作成されたコンテンツを「番組」と呼ぶ。番組とは、TV 放送の番組と同じく、テキスト・画像・音声・映像などを連続的に映しだすものだけではなく、テキストだけ、画像だけ、音声だけを映し出すもの、テキストを読み上げるもの、映像が自動的に移り変わるだけでなくユーザの入力を待つものなど、さまざま種類のコンテンツが考えられる。
【００２１】
このような端末を使用しているとき、ユーザは一度視聴した番組を再度視聴したい場合がある。ここで、再度視聴するために蓄えておくシナリオとWeb リソースの一セットを、ブックマーク(BM) と定義する。BMは、シナリオの他、画像、テキスト、音声、動画といった番組内で使用する、あるいはマッシュアップ過程で必要になる一連のWeb リソースを一つにまとめたものである。Web リソースとはURI で識別される単一の情報であり、BM は番組の再生に必要なシナリオと単一あるいは複数のWeb リソースをまとめたものである、という違いがある。
【００２２】
本実施形態で前提としているインターネット上のWeb リソースをユーザが持つ端末で合成し、提示するという構成では、インターネット上に元となるWeb コンテンツが存在している。従って、ユーザが番組を再度視聴したいと考えた場合には、元となるWeb リソースがインターネット上にまだ存在している可能性もあるし、もはや存在しない（消えるまたは変化している）場合もあり得る。
【００２３】
本実施形態では、インターネット上から消える、または変化する可能性が高いと判断した情報については、その情報をコンテンツキャッシュ装置（Webリソースキャッシュ装置）にキャッシュしておき、再視聴時には、キャッシュした情報を用いる。
【００２４】
一方、インターネット上に今後も存在する可能性が高いと判断したWebリソースについては、その情報をコンテンツキャッシュ装置に保持せずに、再視聴時に、再度、インターネット上から取得するようにする。つまり、ユーザがこの元となるWeb リソースを保持している必要はなく、番組を再度見たい場合は、再度インターネット上から取得すれば良い。
【００２５】
以上により、ユーザが持つ端末あるいはサーバが保持すべき情報量を低減できるとともに、必要なWebリソースの不存在によりBM が再生できなくなる可能性を低減させることができる。
【００２６】
以下、本実施形態について詳細に説明する。
【００２７】
図1に、本実施形態に係るコンテンツキャッシュ装置としてのWebリソースキャッシュ装置101の構成を示す。
【００２８】
図1のコンテンツキャッシュ装置は、BM保存指示受信部102、シナリオ保持部103、BM履歴保持部104、マッシュアップ部105、取得部（第1取得部、第2取得部）106、キャッシュ保持部107、保持判断部108および要求受信部（再生指示受信部、出力部）109を備える。なお第1取得部はBM保存指示（後述）時にWebリソースを取得し、第2取得部はシナリオ再生時にWebリソースを取得する機能をさすが、第1取得部と第2取得部は物理的に同一のデバイスであっても、別々のデバイスであってもかまわない。
【００２９】
BM保存指示受信部102は、端末Aと無線または有線により通信可能に構成される。要求受信部109は、端末Bと無線または有線により、通信可能に構成される。取得部106は、インターネット等のネットワーク301を介して、複数のサーバ201と通信可能に構成される。端末Aは、シナリオのブックマークを指示する端末であり、ユーザにより操作される。端末Bは、シナリオの再生を指示する端末であり、ユーザにより操作される。端末Bは、端末Aと同一装置であってもよいし、別の装置であってもよい。本コンテンツキャッシュ装置は、ユーザ宅内にサーバとして配置されてもよいし、インターネット上に配置されてもよい。
【００３０】
以下、図2〜図5のフローチャートを用いて、本装置が備える各ブロックの機能、および全体の動作を説明する。
【００３１】
図2に、本装置が端末AからBM 保存を指示されたときの動作を示す。
【００３２】
BM 保存指示受信部102は、ユーザが持つ端末Aから送られたBM 保存指示を受け取る(ステップS11)。このBM 保存指示の中には、シナリオを識別する識別子（シナリオ識別子）が格納されている。
【００３３】
識別子はURI などの文字列や数値で構成される。シナリオは、複数のWeb リソースのリソース(URI等)を指定し、当該複数のWebリソースの合成方法（再生方法）を定めている。
【００３４】
端末Aは、シナリオの再生中に、当該シナリオに対するBM保存指示を行ってもよいし、過去に再生したシナリオの一覧からシナリオを選択して、BM保存指示を行ってもよい。あるいはその他の方法でシナリオを指定し、BM保存指示を行ってもよい。
【００３５】
BM 保存指示受信部102は、BM 保存指示に格納されているシナリオ識別子を元に、シナリオ保持部103にシナリオを要求し、シナリオ保持部103からシナリオを取得する(ステップS12)。
【００３６】
本実施形態ではシナリオ保持部103は、本装置内に設けられているが、本装置と有線あるいは無線接続された場所や、インターネット301上にあっても良い。また、BM 保存指示受信部102内に、一定数のシナリオをあらかじめ保持しておき、シナリオ取得にかかる時間を軽減しても良い。
【００３７】
BM 保存指示受信部102は、BM保存を指示したユーザの識別子（ユーザ識別子）と、シナリオ識別子と、BM保存指示の受付時刻情報とを含めたBM 保存指示を、BM履歴保持部104に送る(ステップS13)。受付時刻情報は、BM保存指示がなされた時刻（BM保存指示時刻）、すなわちBM保存指示を受け付けた時刻を表す。ユーザ識別子は、BM保存指示と同時に取得してもよいし、ユーザ認証を行う場合などは、別途の認証の手続時に取得してもよい。
【００３８】
BM保存指示を受けたBM履歴保持部104は、ユーザ識別子と、シナリオ識別子と、BM保存指示時刻とを1セットにして、BM履歴として、保持する。
【００３９】
図6に、BM履歴保持部104が持つBM履歴のデータ例を示す。
【００４０】
BM履歴保持部104は、一定量のBM 履歴を保持可能である。図示の例では、BM履歴に再生回数も含めている。再生回数は、後述する端末Bからの再生指示に応じて再生されたシナリオの再生回数である。図示の時刻は、年・日時・時分・秒を含んでいるが、これらのすべてを含まなくてもよい。たとえば年を省略してもよい。
【００４１】
BM履歴保持部104は、BM 保存指示を受けてから一定時間が経過した場合、ユーザからの指示を受けた場合は、該当するデータを消去してもよい。また、保持可能な容量（記憶容量）を超えた場合に、データの一部を消去してもよい。消去するデータは、たとえばシナリオの再生回数、各シナリオのシナリオ間での再生回数の比率、またはBM保存指示時刻をもとに決定してもよい。または、ランダムに決定することも可能である。ユーザの保存指示があったデータ、再生回数が一定値以上のデータは、消去対象から除外してもよい。
【００４２】
BM 保存指示受信部102は、シナリオ保持部103から取得したシナリオ、および受付時刻情報（BM保存指示時刻）を、マッシュアップ部105に送る(ステップS14)。
【００４３】
マッシュアップ部105は、BM 保存指示受信部102から送られたシナリオに基づき、当該シナリオのマッシュアップに必要となるWebリソースを特定する (ステップS15)。マッシュアップ部105は、必要になるWeb リソース、すなわちシナリオで指定されたWebリソースの取得を指示した取得指示情報を、取得部106に送る(ステップS16)。取得指示情報には、取得を指示するWebリソースの識別子（ここではURI)、BM保存指示時刻等を含める。
【００４４】
取得部106は、マッシュアップ部105から指示されたWeb リソースを、当該Webリソースの識別子を元に、インターネット301上のWeb リソース保持サーバ201から取得することを試みる (ステップS17)。
【００４５】
Webリソース保持サーバ201から取得できなかったWebリソースについては、キャッシュ保持部107にキャッシュ取得要求を送る(ステップS20)。キャッシュ保持部107は、キャッシュされている該当するWeb リソース（たとえば同一識別子を有する、同一または最新のBM保存指示時刻が関連づけられたWebリソース）を取得部106に送る (ステップS21)。
【００４６】
外部から取得できず、キャッシュ保持部107にもキャッシュもないWebリソースについては、取得できなかった旨を、マッシュアップ部105に返す。この場合、マッシュアップ部105は、当該Webリソースが取得できなかった旨をユーザに提示しても良い。
【００４７】
なお、ステップS20、S21では、Webリソース保持サーバ201からWebリソースを取得できなかったときはキャッシュ保持部107からキャッシュの取得を試みているが、この処理は本質ではないため、省略することも可能である。この場合、取得できなかった旨を、マッシュアップ部105に返せばよい。
【００４８】
取得部106は、Web リソース保持サーバ201から取得したWeb リソースと、マッシュアップ部105から得た取得指示情報（BM保存指示時刻、Webリソース識別子等）を、保持判断部108に、一セットとして送る(ステップS19)。
【００４９】
このとき、取得部106は、取得したWebリソースのハッシュ値を計算し、ハッシュ値を保持判断部108に送っても良い。Webリソースのハッシュ値を送ることにより、後述するように、同一の識別子を持つWebリソースであっても、Web リソースの内容が変化したことを、高速に検知できる。
【００５０】
保持判断部108は、取得部106から送られてきたデータを元に、取得したWebリソースをキャッシュするかどうかを決定する(ステップS22)。
【００５１】
保持判断部108が保持すると決定した場合、当該Web リソース、その識別子、BM保存指示時刻をキャッシュ保持部107に送り(ステップS23)、キャッシュ保持部107は送られてきたWeb リソース、Webリソース識別子およびBM保存指示時刻を保持する(ステップS24)。このとき、キャッシュ保持部107にハッシュ値も送り、キャッシュ保持部107に当該ハッシュ値を保持してもよい。
【００５２】
図7にキャッシュ保持部107が持つデータの例を示す。1つの行が1つのレコードに対応する。この例では、Webリソース識別子、BM保存指示時刻、Webリソースのデータ（ビット）、Webリソースのハッシュ値を保持している。ハッシュ値が同一であるリソース同士は、互いに同一の構成（データ）を有することを意味する。キャッシュ保持部107に保持されているWebリソースは、単にキャッシュと称されることもある。同一の識別子を持つWeb リソースであっても、BM保存指示時刻が違う場合は、それぞれ別々に保持され得る。これにより、過去の特定時刻におけるWeb リソースを得ることができる。なお、当該Webリソースを利用するシナリオを識別し、再生頻度などそのシナリオに応じた判断を行うために、シナリオIDをキャッシュ保持部107に追加してもよい。
【００５３】
キャッシュ保持部107は、保持してから一定時間が経過した場合、該当するデータ（レコード）を消去してもよい。また、一定確率でキャッシュを削除する方法もある。この場合、この確率はユーザの設定、番組の内容、BM の再生率、BM の再生回数によって動的に変動しても良い。また、BM の再生に支障がない範囲のWeb リソースは優先的に削除しても良い。キャッシュ保持部107は、BM履歴保持部104でシナリオが消去された際、当該消去されたシナリオで用いられており、かつBM履歴保持部104で保持される他のシナリオで用いられない、リソースを消去してもよい。
【００５４】
保持判断部108が、保持しないと判断した場合、保持判断部108はキャッシュ保持部107にキャッシュの削除を指示し、(ステップS25)、キャッシュ保持部107はキャッシュおよびそれに関連づけられたWebリソース識別子、BM保存指示時刻、ハッシュ値等を、削除する(ステップS26)。キャッシュの削除指示のタイミングは、保持しないと判断した時点でもよいし、処理負荷を下げるために、後の別のタイミングでも構わない。
【００５５】
以下、ステップS22で行われる保持判断処理について、さらに詳細に説明する。
【００５６】
図3に、保持判断の動作フローを示す。
【００５７】
保持判断部108が、取得部106から、Web リソース（ハッシュ値が送られてきた場合は当該ハッシュ値）と、Web リソースの識別子と、取得指示情報に含まれるBM保存指示時刻とを受け取る（ステップS31）。
【００５８】
保持判断部108は、当該Web リソースと同じ識別子のリソースが、過去に要求されたことがあるかを、判断する（S32）。これは、当該Webリソースと同じ識別子が、キャッシュ保持部に保持されているか否かを確認することで行う。
【００５９】
今まで要求されたことがない判断したときは、当該Webリソースを、キャッシュ保持部107に保持させることを決定する（ステップS34）。キャッシュ保持部107は、当該Webリソースを、その識別子、BM保存指示時刻、およびハッシュ値とともに、保持する。
【００６０】
当該Web リソースと同じ識別子のリソースが過去に要求されたことがある場合は、以下のチェックを行う。
【００６１】
キャッシュ保持部107に保持されている同一識別子のWeb リソース（キャッシュ）の構成は、取得したWeb リソースと異なっているか否かを判断する（ステップS33）。すなわち両Webリソースのデータ（ビット）が一致するかを判断する。取得部106からWebリソースのハッシュ値が送られてきた場合は、データ同士の比較の代わりに、送られてきたハッシュ値と、キャッシュされているハッシュ値同士を比較することで、高速な判断が可能である。
【００６２】
ステップS33の判断において、取得したWebリソースと、保存されているWebリソース（キャッシュ）の構成が互いに異なる場合は、当該取得したWebリソースを、キャッシュ保持部107に保持させることを決定する（ステップS34）。キャッシュ保持部107は、当該Webリソースを、その識別子、BM保存指示時刻、およびハッシュ値とともに、保持する。
【００６３】
取得したWebリソースと、保存されているWebリソース（キャッシュ）の構成が互いに一致する場合は、当該キャッシュのBM保存指示時刻をチェックする（ステップS35）。
【００６４】
キャッシュの保存時刻が、対象とするBM保存指示時刻（取得部106から送られてきたBM保存指示時刻）の一定時間前よりも時間的に後の場合、すなわち、対象とするBM保存指示時刻と、キャッシュのBM保存指示時刻との時間差の大きさが閾値未満の場合、当該キャッシュとその関連データを削除するとともに、取得したWebリソースは保持しないことを決定する（ステップS36）。
【００６５】
ここで一定時間とは一ヶ月など比較的長期間を指す。複数回当該Web リソースの取得が指示され、その間にWebリソース保持サーバから得たWeb リソースが変化していない場合において、その間隔が短ければ、次にまた取得が指示されるまでの間隔が短く、かつ、Web リソースが異なっていない（すなわち同じである）ということが推定できるため、キャッシュを削除しても良いと判断する。
【００６６】
一方、キャッシュのBM指示保存時刻が、対象とするBM保存指示時刻の一定時間前よりも時間的にさらに前の場合、すなわち、対象とするBM保存指示時刻と、キャッシュのBM保存指示時刻との時間差の大きさが閾値以上の場合、当該キャッシュをそのまま保持し、取得したWebリソースを保持しないことを決定する（ステップS34）。これを第1の方式と呼ぶ。この際、代替方法として、当該キャッシュのBM指示保存時刻を、対象とするBM保存指示時刻に更新してもよい（第2の方式）。または、取得した対象とするBM保存指示時刻とWebリソースの識別子のみをキャッシュ保持部107に格納し、Webリソースのデータ本体（ビット）については、キャッシュのものを参照するようにしてもよい（第3の方式）。第3の方式の場合、キャッシュ保持部のテーブルに、参照すべきレコードのIDを参照するフィールドを追加すればよい。
【００６７】
第1の方式および第2の方式は、キャッシュ保持部の容量をできるだけ抑えたい場合に有効である。インターネット上の、あるリソースの内容（構成）が変化した後、そのリソースは元の内容には戻らない（もしくはその可能性が非常に少ない）前提では、キャッシュされていたBM保存指示時刻または対象とするBM保存指示時刻のシナリオを再生する際、指示時と同一内容の再生を行う可能性を非常に高めることができる。第3の方式は、第1および第2方式よりも若干、キャッシュ保持部107の容量を上昇させるが、より確実な再生を可能にする手法である。
【００６８】
以上、図2を用いて述べてきた説明は、BM 保存を指示された時の動作である。以下、BM 再生を行う場合の動作を記す。BM再生を行う場合、BM を再生したい端末(以下、端末B)が、本装置からBMM履歴（BMリスト）を取得し、再生するBMを指定する。
【００６９】
図4にBM履歴を要求された場合の本装置の動作を示す。
【００７０】
図5に、BM再生を指示されたときの本装置の動作を示す。
【００７１】
図4において、BM を再生したい端末(以下、端末B) は、まず要求受信部109に対して、BM 履歴の閲覧要求を送出する(ステップS41)。なお再生端末BはBM 保存指示を行った端末Aと同一でも構わないし、異なっていても構わない。これにより、例えば外出時に携帯端末から見ていたコンテンツをBM し、帰宅後に大画面テレビでより高精細な情報を続きから、あるいはもう一度楽しむことができる。
【００７２】
要求受信部109は、BM履歴保持部104に、BM 履歴の取得要求を送る (ステップS42)。
【００７３】
BM履歴保持部104は、要求受信部109に、BM 履歴を渡す(ステップS43)。BM 履歴には、BM が複数含まれている。
【００７４】
要求受信部109は、端末B に、BM 履歴を渡す(ステップS44)。端末Bは、このBM履歴をユーザに提示することで、どのBMを再生するか 、すなわちどのシナリオを再生するかを、ユーザに選択させる。再生するべく選択したシナリオは、第1シナリオに対応する。
【００７５】
図5において、ユーザにより再生するBM が指示されたとき、端末B は要求受信部109に、BM再生指示を送る(ステップS51)。
【００７６】
再生要求を受けた要求受信部109は、指定されたBMの受付時刻情報（BM保存指示時刻）とシナリオとを、マッシュアップ部105に送る(ステップS52)。
【００７７】
マッシュアップ部105が、シナリオのマッシュアップを行う。まず、シナリオで指定される、マッシュアップに必要なWeb リソースを特定し（ステップS53）、特定したWebリソースの取得要求を、取得部106に送る(ステップS54)。取得要求には、上記BM保存指示時刻と、取得したいWebリソースの識別子とが含まれる。
【００７８】
取得部106は、このBM保存指示時刻とWeb リソースの識別子を元に、キャッシュ保持部107に、キャッシュの取得要求を送る (ステップS55)。当該キャッシュの取得要求には、当該BM保存指示時刻と、当該Webリソースの識別子が含まれる。
【００７９】
キャッシュ保持部107は、当該Webリソースの識別子と同じ識別子が関連づけられ、かつ当該BM保存指示時刻と同じ時刻が関連づけられたキャッシュ（Web リソース）が存在するかを調べる（ステップS56）。存在する場合は、そのキャッシュを、取得部106に返し、取得部106は、さらに当該キャッシュをマッシュアップ部105に送る (ステップS57)。
【００８０】
このとき、図3のステップS34で第1の方式を用いた場合は、本ステップS56でキャッシュが存在しないと判断された場合、以下の処理を行っても良い。すなわち、当該Webリソースの識別子と同じ識別子に関連づけられたキャッシュが存在するかを調べ、存在する場合は、当該BM保存指示時刻に最も近い過去のキャッシュを、取得部106に返す。これは、第1の方式として、図3のステップS33で、同一構成であると判断された2つのWebリソースのうち、キャッシュ保持部107に元々存在したいた方をそのまま残し、他方（Webリソース保持サーバ201から取得したWebリソース）を削除したことによるものである。この第1の方式は、前述したように、インターネット上の、あるリソースの内容（構成）が変化した後、そのリソースは元の内容には戻る可能性は低い状況において有効である。ただし、元の内容に戻っても、動作に支障は生じない。なお、元の内容に戻る可能性がないという前提を設定し、第1の方式を採用するのであれば、図3のステップS33の判断では、同一識別子のWebリソース（キャッシュ）が複数、キャッシュ保持部107に存在するときは、対象となるBM保存指示時刻から時間的に最も近いWebリソースとのみ、同一か否かの比較を行ってもよい。
【００８１】
図3のステップS34で第2の方式を用いた場合も同様の考えで、本ステップS56でキャッシュが存在しないと判断された場合、当該Webリソースの識別子と同じ識別子に関連づけられたキャッシュが存在する場合は、当該BM保存指示時刻に最も近い将来のキャッシュを、取得部106に返すようにしてもよい。
【００８２】
一方、当該するキャッシュが存在しない場合、キャッシュ保持部107は、その旨を取得部106に返し、取得部106は、当該Webリソースの識別子をもとに、Web リソース保持サーバ201からWeb リソースの取得を試みる（S58）。なお、BM保存指示がなされたときにWeb リソースは少なくとも一度は取得されているため（図2のステップS17参照）、ここでキャッシュがない場合とは、保持判断部108がキャッシュを保持する必要がないと判断したWeb リソースであるということを示す（図2のステップS22、S25参照）。
【００８３】
取得部106は、Webリソースを取得できなかったときは、すなわちインターネット301上に当該Webリソースが存在しなかったときは、その旨をマッシュアップ部105に通知する（S58、S59）。
【００８４】
Webリソースを取得できたときは、取得部106は、取得したWebリソースを、マッシュアップ部105に送る（S58、S60）。
【００８５】
マッシュアップ部105は、取得部106から取得したWeb リソースを用いて、シナリオのマッシュアップを完成し、マッシュアップの結果である番組を、要求受信部109に返す(ステップS61)。取得できなかったWebリソースが存在する場合は、その部分には適当なリソースを配置してもよい。適当なリソースは、本装置に事前に記憶しておいてもよいし、ネットワーク上のサーバから任意の方法で取得してもよい。たとえば、類似情報を検索して利用したり、広告などの代わりのコンテンツを利用したりしても良い。
【００８６】
要求受信部109は、マッシュアップ部105から渡された番組を、端末B に送る(ステップS62)。
【００８７】
端末B は、要求受信部109から受けた番組を表示する（ステップS63）。これにより、BM 保存指示があった時点のシナリオを、端末B にて再生できる。
【００８８】
以上、本実施形態によれば、BM指示のなされたシナリオで定められたWebリソースのうち、後の再視聴時にもネットワーク上から取得できると判断でしたWebリソースについては本装置が保持しないようにしたことにより、従来よりも保持すべき情報量をさらに低減できる。
【００８９】
なお、本方式では、保持判断部108が保持しないと判断したWeb リソースが、インターネット上で消えた場合や変更された場合には、そのWeb リソースを取得できなくなり、BM 保存指示がされたシナリオと同じ番組を、合成できないこととなる。しかしながら、本実施形態は、このリスクをある程度許容することで、キャッシュ保持容量を軽減するものであり、キャッシュ装置の保持容量の削減に、大きく寄与するものと考えられる。
【００９０】
なお、本実施形態では、Web リソースはインターネット上のサーバに保持されているとしたが、その他同一端末内、ホームネットワークやLAN 上にあっても良い。また、Web リソースの識別子はURI を想定しているが、その他ファイルパスやIP アドレスなどであっても良い。
【００９１】
なお、上記の実施形態に示したWebリソースキャッシュ装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、当該装置における各要素は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、本装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、同装置内の保持部103，104、107は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
【００９２】
また、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【特許請求の範囲】
【請求項１】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるBM保存指示受信部と、
前記シナリオと、前記ブックマーク指示が受信された時刻に関連する第1受付時刻情報を、記憶するブックマーク履歴保持部と、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得する第1取得部と、
リソースと、対応する識別子と、前記リソースが記憶された時刻に関連する第2受付時刻情報とを関連づけて記憶するキャッシュ保持部と、
取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子と、前記事前に記憶されたリソースに関連する前記第2受付時刻情報を削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶するとともに、前記ブックマーク履歴保持部からの前記取得されたリソースに関連する前記第1受付時刻情報を、前記取得されたリソースに関連する前記第2受付時刻情報として記憶する、
評価部と、
前記ブックマーク履歴保持部に保持されたシナリオのうちの1つであり、それぞれ識別子に関連する複数のリソースに関連づけられた第1シナリオの再生指示を受け付ける、再生指示受信部と、
前記第1シナリオに関連する識別子について、前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するかを決定し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するときは、前記識別子に対応するリソースを前記キャッシュ保持部から取得し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在しないときは、前記第1シナリオに関連するリソースを、当該識別子に関連するロケーションから取得する、第2取得部と、
前記第1シナリオの再生指示に応じて前記第2取得部で取得されたリソースを合成することにより、番組を生成するマッシュアップ部と、
前記番組を出力する出力部と、
を備えたことを特徴とするコンテンツキャッシュ装置。
【請求項２】
前記評価部は、
前記キャッシュ保持部に存在すると決定した前記事前に記憶されたリソースに関連づけられた第2受付時刻情報と、前記事前に記憶されたリソースに関連する前記ブックマーク指示を受けた時刻に対応する第1受付時刻情報の時間差が閾値より大きい、小さいか、同じかを決定し、
前記時間差が前記閾値より小さいときは、前記キャッシュ保持部から前記事前に記憶されたリソースを削除し、
前記時間差が前記閾値以上のときは、前記事前に記憶されたリソースを削除しない
ことを特徴とする請求項1に記載のコンテンツキャッシュ装置。
【請求項３】
前記ブックマーク履歴保持部は、
前記シナリオ毎に、再生指示を受けた前記シナリオの再生回数を記憶し、
前記ブックマーク履歴保持部の記憶容量が一定値に達したとき、またはユーザ端末から消去指示を受けたとき、前記再生回数に応じて、前記シナリオを消去する
ことを特徴とする請求項1に記載のコンテンツキャッシュ装置。
【請求項４】
前記ブックマーク履歴保持部は、前記シナリオに対して前記第1受付時刻情報から一定時間経過したシナリオを消去する
ことを特徴とする請求項1に記載のコンテンツキャッシュ装置。
【請求項５】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオと、前記ブックマーク指示が受信された時刻に関連する第1受付時刻情報を、ブックマーク履歴保持部に記憶するステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、前記リソースが記憶された時刻に関連する第2受付時刻情報とを関連づけて記憶するキャッシュ保持部に基づき、取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ別のリソースがキャッシュ保持部にすでに存在するかどうかを決定し、
前記別のリソースが存在するときは、前記キャッシュ保持部から前記別のリソースと、前記別のリソースに関連する識別子と、前記別のリソースが前記キャッシュ保持部に記憶された時刻に関連する前記別のリソースに関連する第2受付時刻情報を削除し、
前記別のリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶するとともに、前記ブックマーク履歴保持部からの前記取得されたリソースに関連する前記第1受付時刻情報を、前記取得されたリソースに関連する第2受付時刻情報として記憶する、ステップと、
前記ブックマーク履歴保持部に保持されたシナリオのうちの1つであり、それぞれ識別子に関連する複数のリソースに関連づけられた第1シナリオの再生指示を受け付けるステップと、
前記第1シナリオに関連する識別子について、前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するかを決定し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するときは、前記識別子に対応するリソースを前記キャッシュ保持部から取得し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在しないときは、前記第1シナリオに関連するリソースを、当該識別子に関連するロケーションから取得する、ステップと、
前記第1シナリオの再生指示に応じて、取得されたリソースを合成することにより、番組を生成するステップと、
前記番組を出力する出力ステップと、
を備えたことを特徴とするコンテンツキャッシュ方法。
【請求項６】
前記キャッシュ保持部に存在すると決定した前記別のリソースに関連づけられた第2受付時刻情報と、前記別のリソースに関連する前記ブックマーク指示を受けた時刻に対応する第1受付時刻情報の時間差が閾値より大きい、小さいか、同じかを決定するステップと、
前記時間差が前記閾値より小さいときは、前記キャッシュ保持部から前記別のリソースを削除するステップと、
前記時間差が前記閾値以上のときは、前記別のリソースを削除しないステップと
をさらに備えたことを特徴とする請求項5に記載のコンテンツキャッシュ方法。
【請求項７】
前記シナリオ毎に、再生指示を受けた前記シナリオの再生回数を記憶するステップと、
前記ブックマーク履歴保持部の記憶容量が一定値に達したとき、またはユーザ端末から消去指示を受けたとき、前記再生回数に応じて、前記シナリオを消去するステップと
をさらに備えたことを特徴とする請求項5に記載のコンテンツキャッシュ方法。
【請求項８】
前記シナリオに対して前記第1受付時刻情報から一定時間経過したシナリオを消去するステップをさらに備えたことを特徴とする請求項5に記載のコンテンツキャッシュ方法。
【請求項９】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオと、前記ブックマーク指示が受信された時刻に関連する第1受付時刻情報を、ブックマーク履歴保持部に記憶するステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、前記リソースが記憶された時刻に関連する第2受付時刻情報とを関連づけて記憶するキャッシュ保持部に基づき、取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ別のリソースがキャッシュ保持部にすでに存在するかどうかを決定し、
前記別のリソースが存在するときは、前記キャッシュ保持部から前記別のリソースと、前記別のリソースに関連する識別子と、前記別のリソースが前記キャッシュ保持部に記憶された時刻に関連する前記別のリソースに関連する第2受付時刻情報を削除し、
前記別のリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶するとともに、前記ブックマーク履歴保持部からの前記取得されたリソースに関連する前記第1受付時刻情報を、前記取得されたリソースに関連する第2受付時刻情報として記憶する、ステップと、
前記ブックマーク履歴保持部に保持されたシナリオのうちの1つであり、それぞれ識別子に関連する複数のリソースに関連づけられた第1シナリオの再生指示を受け付けるステップと、
前記第1シナリオに関連する識別子について、前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するかを決定し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するときは、前記識別子に対応するリソースを前記キャッシュ保持部から取得し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在しないときは、前記第1シナリオに関連するリソースを、当該識別子に関連するロケーションから取得する、ステップと、
前記第1シナリオの再生指示に応じて、取得されたリソースを合成することにより、番組を生成するステップと、
前記番組を出力する出力ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項１０】
前記キャッシュ保持部に存在すると決定した前記別のリソースに関連づけられた第2受付時刻情報と、前記別のリソースに関連する前記ブックマーク指示を受けた時刻に対応する第1受付時刻情報の時間差が閾値より大きい、小さいか、同じかを決定するステップと、
前記時間差が前記閾値より小さいときは、前記キャッシュ保持部から前記別のリソースを削除するステップと、
前記時間差が前記閾値以上のときは、前記別のリソースを削除しないステップと
をさらにコンピュータに実行させることを特徴とする請求項9に記載のコンピュータプログラム。
【請求項１１】
前記シナリオ毎に、再生指示を受けた前記シナリオの再生回数を記憶するステップと、
前記ブックマーク履歴保持部の記憶容量が一定値に達したとき、またはユーザ端末から消去指示を受けたとき、前記再生回数に応じて、前記シナリオを消去するステップと
をさらにコンピュータに実行させることを特徴とする請求項9に記載のコンピュータプログラム。
【請求項１２】
前記シナリオに対して前記第1受付時刻情報から一定時間経過したシナリオを消去するステップ
をさらにコンピュータに実行させることを特徴とする請求項9に記載のコンピュータプログラム。
【請求項１３】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるBM保存指示受信部と、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得する第1取得部と、
リソースと、対応する識別子と、を関連づけて記憶するキャッシュ保持部と、
前記第1取得部により取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子とを削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶する、評価部と、
を備えたコンテンツキャッシュ装置。
【請求項１４】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、を関連づけて記憶するキャッシュ保持部に基づき、前記取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子とを削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶する、ステップと、
を備えたコンテンツキャッシュ方法。
【請求項１５】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、を関連づけて記憶するキャッシュ保持部に基づき、前記取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子とを削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶する、ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項１】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるBM保存指示受信部と、
前記シナリオと、前記ブックマーク指示が受信された時刻に関連する第1受付時刻情報を、記憶するブックマーク履歴保持部と、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得する第1取得部と、
リソースと、対応する識別子と、前記リソースが記憶された時刻に関連する第2受付時刻情報とを関連づけて記憶するキャッシュ保持部と、
取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子と、前記事前に記憶されたリソースに関連する前記第2受付時刻情報を削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶するとともに、前記ブックマーク履歴保持部からの前記取得されたリソースに関連する前記第1受付時刻情報を、前記取得されたリソースに関連する前記第2受付時刻情報として記憶する、
評価部と、
前記ブックマーク履歴保持部に保持されたシナリオのうちの1つであり、それぞれ識別子に関連する複数のリソースに関連づけられた第1シナリオの再生指示を受け付ける、再生指示受信部と、
前記第1シナリオに関連する識別子について、前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するかを決定し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するときは、前記識別子に対応するリソースを前記キャッシュ保持部から取得し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在しないときは、前記第1シナリオに関連するリソースを、当該識別子に関連するロケーションから取得する、第2取得部と、
前記第1シナリオの再生指示に応じて前記第2取得部で取得されたリソースを合成することにより、番組を生成するマッシュアップ部と、
前記番組を出力する出力部と、
を備えたことを特徴とするコンテンツキャッシュ装置。
【請求項２】
前記評価部は、
前記キャッシュ保持部に存在すると決定した前記事前に記憶されたリソースに関連づけられた第2受付時刻情報と、前記事前に記憶されたリソースに関連する前記ブックマーク指示を受けた時刻に対応する第1受付時刻情報の時間差が閾値より大きい、小さいか、同じかを決定し、
前記時間差が前記閾値より小さいときは、前記キャッシュ保持部から前記事前に記憶されたリソースを削除し、
前記時間差が前記閾値以上のときは、前記事前に記憶されたリソースを削除しない
ことを特徴とする請求項1に記載のコンテンツキャッシュ装置。
【請求項３】
前記ブックマーク履歴保持部は、
前記シナリオ毎に、再生指示を受けた前記シナリオの再生回数を記憶し、
前記ブックマーク履歴保持部の記憶容量が一定値に達したとき、またはユーザ端末から消去指示を受けたとき、前記再生回数に応じて、前記シナリオを消去する
ことを特徴とする請求項1に記載のコンテンツキャッシュ装置。
【請求項４】
前記ブックマーク履歴保持部は、前記シナリオに対して前記第1受付時刻情報から一定時間経過したシナリオを消去する
ことを特徴とする請求項1に記載のコンテンツキャッシュ装置。
【請求項５】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオと、前記ブックマーク指示が受信された時刻に関連する第1受付時刻情報を、ブックマーク履歴保持部に記憶するステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、前記リソースが記憶された時刻に関連する第2受付時刻情報とを関連づけて記憶するキャッシュ保持部に基づき、取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ別のリソースがキャッシュ保持部にすでに存在するかどうかを決定し、
前記別のリソースが存在するときは、前記キャッシュ保持部から前記別のリソースと、前記別のリソースに関連する識別子と、前記別のリソースが前記キャッシュ保持部に記憶された時刻に関連する前記別のリソースに関連する第2受付時刻情報を削除し、
前記別のリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶するとともに、前記ブックマーク履歴保持部からの前記取得されたリソースに関連する前記第1受付時刻情報を、前記取得されたリソースに関連する第2受付時刻情報として記憶する、ステップと、
前記ブックマーク履歴保持部に保持されたシナリオのうちの1つであり、それぞれ識別子に関連する複数のリソースに関連づけられた第1シナリオの再生指示を受け付けるステップと、
前記第1シナリオに関連する識別子について、前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するかを決定し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するときは、前記識別子に対応するリソースを前記キャッシュ保持部から取得し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在しないときは、前記第1シナリオに関連するリソースを、当該識別子に関連するロケーションから取得する、ステップと、
前記第1シナリオの再生指示に応じて、取得されたリソースを合成することにより、番組を生成するステップと、
前記番組を出力する出力ステップと、
を備えたことを特徴とするコンテンツキャッシュ方法。
【請求項６】
前記キャッシュ保持部に存在すると決定した前記別のリソースに関連づけられた第2受付時刻情報と、前記別のリソースに関連する前記ブックマーク指示を受けた時刻に対応する第1受付時刻情報の時間差が閾値より大きい、小さいか、同じかを決定するステップと、
前記時間差が前記閾値より小さいときは、前記キャッシュ保持部から前記別のリソースを削除するステップと、
前記時間差が前記閾値以上のときは、前記別のリソースを削除しないステップと
をさらに備えたことを特徴とする請求項5に記載のコンテンツキャッシュ方法。
【請求項７】
前記シナリオ毎に、再生指示を受けた前記シナリオの再生回数を記憶するステップと、
前記ブックマーク履歴保持部の記憶容量が一定値に達したとき、またはユーザ端末から消去指示を受けたとき、前記再生回数に応じて、前記シナリオを消去するステップと
をさらに備えたことを特徴とする請求項5に記載のコンテンツキャッシュ方法。
【請求項８】
前記シナリオに対して前記第1受付時刻情報から一定時間経過したシナリオを消去するステップをさらに備えたことを特徴とする請求項5に記載のコンテンツキャッシュ方法。
【請求項９】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオと、前記ブックマーク指示が受信された時刻に関連する第1受付時刻情報を、ブックマーク履歴保持部に記憶するステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、前記リソースが記憶された時刻に関連する第2受付時刻情報とを関連づけて記憶するキャッシュ保持部に基づき、取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ別のリソースがキャッシュ保持部にすでに存在するかどうかを決定し、
前記別のリソースが存在するときは、前記キャッシュ保持部から前記別のリソースと、前記別のリソースに関連する識別子と、前記別のリソースが前記キャッシュ保持部に記憶された時刻に関連する前記別のリソースに関連する第2受付時刻情報を削除し、
前記別のリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶するとともに、前記ブックマーク履歴保持部からの前記取得されたリソースに関連する前記第1受付時刻情報を、前記取得されたリソースに関連する第2受付時刻情報として記憶する、ステップと、
前記ブックマーク履歴保持部に保持されたシナリオのうちの1つであり、それぞれ識別子に関連する複数のリソースに関連づけられた第1シナリオの再生指示を受け付けるステップと、
前記第1シナリオに関連する識別子について、前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するかを決定し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在するときは、前記識別子に対応するリソースを前記キャッシュ保持部から取得し、
前記第1シナリオに関連する識別子が前記キャッシュ保持部に存在しないときは、前記第1シナリオに関連するリソースを、当該識別子に関連するロケーションから取得する、ステップと、
前記第1シナリオの再生指示に応じて、取得されたリソースを合成することにより、番組を生成するステップと、
前記番組を出力する出力ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項１０】
前記キャッシュ保持部に存在すると決定した前記別のリソースに関連づけられた第2受付時刻情報と、前記別のリソースに関連する前記ブックマーク指示を受けた時刻に対応する第1受付時刻情報の時間差が閾値より大きい、小さいか、同じかを決定するステップと、
前記時間差が前記閾値より小さいときは、前記キャッシュ保持部から前記別のリソースを削除するステップと、
前記時間差が前記閾値以上のときは、前記別のリソースを削除しないステップと
をさらにコンピュータに実行させることを特徴とする請求項9に記載のコンピュータプログラム。
【請求項１１】
前記シナリオ毎に、再生指示を受けた前記シナリオの再生回数を記憶するステップと、
前記ブックマーク履歴保持部の記憶容量が一定値に達したとき、またはユーザ端末から消去指示を受けたとき、前記再生回数に応じて、前記シナリオを消去するステップと
をさらにコンピュータに実行させることを特徴とする請求項9に記載のコンピュータプログラム。
【請求項１２】
前記シナリオに対して前記第1受付時刻情報から一定時間経過したシナリオを消去するステップ
をさらにコンピュータに実行させることを特徴とする請求項9に記載のコンピュータプログラム。
【請求項１３】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるBM保存指示受信部と、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得する第1取得部と、
リソースと、対応する識別子と、を関連づけて記憶するキャッシュ保持部と、
前記第1取得部により取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子とを削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶する、評価部と、
を備えたコンテンツキャッシュ装置。
【請求項１４】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、を関連づけて記憶するキャッシュ保持部に基づき、前記取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子とを削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶する、ステップと、
を備えたコンテンツキャッシュ方法。
【請求項１５】
それぞれ識別子に関連する複数のリソースに関連づけられたシナリオのブックマーク指示を受け付けるステップと、
前記シナリオに関連する前記リソースを、前記リソースに関連する前記識別子に応じたロケーションから取得するステップと、
リソースと、対応する識別子と、を関連づけて記憶するキャッシュ保持部に基づき、前記取得されたリソースについて、前記取得されたリソースと同じ識別子をもつ事前に記憶されたリソースが前記キャッシュ保持部に存在するかどうかを決定し、
前記事前に記憶されたリソースが存在するときは、前記キャッシュ保持部から前記事前に記憶されたリソースと、前記事前に記憶されたリソースに関連する識別子とを削除し、
前記事前に記憶されたリソースが存在しないときは、前記キャッシュ保持部に前記取得されたリソースと前記取得されたリソースに関連する識別子を記憶する、ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１２−１４１９６０（Ｐ２０１２−１４１９６０Ａ）
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【出願番号】特願２０１１−２６５８６９（Ｐ２０１１−２６５８６９）
【出願日】平成２３年１２月５日（２０１１．１２．５）
【分割の表示】特願２０１０−２９３８５４（Ｐ２０１０−２９３８５４）の分割
【原出願日】平成２２年１２月２８日（２０１０．１２．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【出願日】平成２３年１２月５日（２０１１．１２．５）
【分割の表示】特願２０１０−２９３８５４（Ｐ２０１０−２９３８５４）の分割
【原出願日】平成２２年１２月２８日（２０１０．１２．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]