JP5433700B2 - メタデータ収集装置 - Google Patents

Description

本発明は、例えばコンテンツなどのメタデータを効率的に収集して蓄積し、また蓄積（キャッシュ）したメタデータを効率的に更新するメタデータ収集装置に関する。

近年、ブロードバンドの普及を背景として、IP（Internet Protocol）通信を利用したマルチメディアコンテンツ配信サービスが、様々な通信・サービス事業者によって運営されている。携帯用の低解像度の映像配信サービスからデジタルテレビ用のHD ( High Definition ) 品質の高解像度な映像配信サービスまで多種多様なサービスが提供されている。

マルチメディアコンテンツ配信サービスの一つとして、ユニキャストで映像を配信するVoD ( Video On Demand ) 映像配信サービスがある。本サービスは、コンテンツの検索・選択のナビゲーションとして、ポータルサービスを利用するものとECG ( Electronic Content Guide )を利用するものとに大別できる。

ポータルサービスとは、サービス事業者が提供するWEBブラウザにおいて、ナビゲーションを行うものである。ユーザは、各サービス事業者が提供しているポータルと呼ばれるWEBページにアクセスし、所望のコンテンツを検索・選択し、映像ストリームを受信するものである。ポータルサービスでは、コンテンツ検索等をすべてのサーバ上で行い、その結果をユーザにWEBページ上でユーザに提示する。

一方、ECGは受信装置上のアプリケーションであり、メタデータと呼ばれる番組情報を取得し、ある数多のメタデータの中から所望のものを選択して、検索、表示、選択、視聴、購入のためのインターフェースをユーザに提供する。ECGを利用したサービスは、ナビゲーションに必要な核となるメタデータを予め受信装置上に蓄積して利用する形態をとる。このため、ECGを利用したサービスは、ポータルサービスと比較して、高速に動作するという利点を持つ。何故ならば、ポータルサービスではサービスサイトの画面構成情報も取得しなければならないからである。その他、ECGを利用したサービスは、画面デザインを受信機側が決定でき、ブラウザでは実現できない受信機リモコンを利用した操作や画面遷移が可能となる、等の利点もある。さらには、ECGを利用したサービスでは、複数のサービスからメタデータを収集およびマージして、ユーザに提示することにより、マルチサービスナビゲーションの実現が可能である。このマルチサービスナビゲーションを実現する公知例として特許文献１に開示されたものがある。

特許文献１では、複数のメタデータ提供装置からのメタデータをメタデータ収集装置が予め収集及びキャッシュしておき、受信装置がメタデータ収集装置に対しメタデータ取得要求を行った際は、これらのメタデータ提供装置が保有するメタデータが統一的な形式で、受信装置に返却される。

特許文献１では、キャッシュしているメタデータとメタデータ提供装置で保持しているメタデータに齟齬がある場合、再度メタデータをメタデータ提供装置から取得する必要がある。そのため、頻繁にメタデータが更新されるサービスにおいては、キャッシュしているメタデータのヒット率が低くなる。したがって、再度、メタデータ提供装置からメタデータを収集する必要が生じ、受信装置でのコンテンツ表示までに時間を要することになる問題がある。

また、特許文献１では、メタデータ収集装置をサーバサイドに配置する形態を想定しているため、宅内のHDDレコーダに蓄積されたコンテンツを検索対象とすることができない。さらには、メタデータ収集装置からすべてのメタデータを取得するため、ハードディスク、メモリの容量などに大きな制約のあるデジタルテレビなどのコンシューマ機器に適応できないなどの問題がある。

特開２００４−１０２７６７号公報

上述したように、サービスが提供するコンテンツ数が非常に多い場合には、メタデータをすべてキャッシュすることはハードディスク、メモリの容量などに大きな制約のあるデジタルテレビなどのコンシューマ機器に適用することは困難である。また、コンテンツの更新が頻繁に行われるようなサービスでは、キャッシュのヒット率が低くなることで、メタデータ提供装置からメタデータを再取得する必要が発生し、軽快な操作感が損なわれるという課題もある。

本発明は、コンテンツ配信サービス別にコンテンツのメタデータを効率的に収集および蓄積できるようにしたメタデータ収集装置を提供することを目的とする。

上記目的を達成するために、本発明のメタデータ収集装置は、コンテンツ配信サービスから配信されるコンテンツとそのメタデータを保有するメタデータ提供装置から前記メタデータを取得し蓄積するメタデータ収集装置であって、前記メタデータを記憶する複数の蓄積方式の中から前記コンテンツ配信サービス毎の蓄積方式を決定し、前記蓄積方式は、検索条件により検索された前記メタデータを蓄積する検索ベース蓄積方式と、前記サービスが保有する前記メタデータの少なくとも一部を予め蓄積する事前蓄積方式とを含む、蓄積方式決定部と、前記メタデータの取得を開始する開始条件と、前記蓄積方式決定部により決定された蓄積方式に対応し、かつ、取得する前記メタデータを選択するための検索条件と、前記メタデータの取得を終了する終了条件とから決定され、前記蓄積方式と関連する蓄積方式情報を前記蓄積方式毎に記憶する記憶部と、前記コンテンツ配信サービス毎の前記蓄積方式に従って対応する前記メタデータを取得する取得部と、取得した前記メタデータを記憶する蓄積部と、を備えることを特徴とするメタデータ収集装置。

本発明により、コンテンツ配信サービス別にコンテンツのメタデータを効率的に収集および蓄積できる。

本発明の第１の実施形態に係わる係るメタデータ収集装置が適用されるコンテンツ配信システムの構成を示すブロック図。 同実施形態に係るメタデータ収集装置の構成を示すブロック図。 同実施形態に係るメタデータ収集装置の起動時における動作例を示すフローチャート。 同実施形態に係るメタデータ収集装置の起動時における他の動作例を示すフローチャート。 同実施形態に係るキャッシュされたメタデータの更新時における動作例を示すフローチャート。 同実施形態に係るキャッシュされたメタデータの削除時における動作例を示すフローチャート。 同実施形態に係るユーザからのメタデータ取得要求が発生した時における動作を示すフローチャート。 同実施形態に係るサービス・メタデータ情報蓄積部に蓄積されたサービス情報の例を示す図。 同実施形態に係るサービス・メタデータ情報蓄積部に蓄積されたサービス情報の例を示す図。 同実施形態に係るコンテンツ検索画面の例を示す図。 同実施形態に係る検索結果表示画面の例を示す図。 同実施形態に係るサービス一覧の例を示す図。 本発明の第２の実施形態に係るメタデータ収集装置の構成を示すブロック図。 同実施形態に係るメタデータ収集装置の起動時における動作例を示すフローチャート。 同実施形態に係るサービス・メタデータ情報蓄積部に蓄積されたサービス情報の例を示す図。 同実施形態に係るジャンル・キーワード登録情報蓄積部に蓄積されたジャンル・キーワード登録情報の例を示す図。 同実施形態に係るジャンル・キーワード変換情報蓄積部に蓄積されたジャンル・キーワード変換情報の例を示す図。

以下、図面を参照しながら本実施の形態について詳細に説明する。

（第１の実施形態）
図１は、本実施形態に係るメタデータ収集装置が適用されるコンテンツ配信システムの全体図である。

本発明の一実施形態としてのメタデータ収集装置１０１が複数のネットワーク１〜３に接続されている。各ネットワーク１〜３には、それぞれ１つ以上のメタデータ提供装置１０２ａ〜１０２ｅが接続されている。

以下では、まずメタデータ提供装置１０２ａ〜１０２ｅ、メタデータ収集装置１０１およびネットワーク１〜３の概要について説明し、その後、メタデータ収集装置１０１について詳しく説明する。

メタデータ提供装置１０２ａ〜１０２ｅは、それぞれ対応するコンテンツ配信サービスに関連するコンテンツのメタデータを提供する。メタデータとは、コンテンツ自体ではなく、そのコンテンツの属性情報を示すもので、コンテンツが映像データ、音声データ、ＷＥＢページ等である場合、そのメタデータは、例えばタイトル（識別子）、詳細情報、作成日時、コンテンツ場所等である。なお、メタデータ記述形式は標準仕様であっても、各サービス独自の形式であってもよい。

メタデータ提供装置１０２ａ〜１０２ｅは、コンテンツ配信サービス事業者が運用するメタサーバや、HDDレコーダなどのコンテンツ保有機器や、メタデータ収集装置１０１に接続されているローカルストレージなどである。

コンテンツ配信サービスの一例を図１２に示す。例えば、メタデータ提供装置１０２ａは高品質VoDサービスが配信するコンテンツのメタデータを提供し、メタデータ提供装置１０２ｂは映像投稿サービスが配信するコンテンツのメタデータを提供する。このように、コンテンツ数が非常に多いサービスからコンテンツ数が限定されたサービスまで、多種多様なサービスがある。それらのサービスの違いとしては、以下のような違いがある。

保有コンテンツ数が多い／少ない
有料／無料
宅内コンテンツ／外部ネットワーク上のコンテンツ
更新頻度が少ない／多い
メタデータ収集装置１０１は、メタデータ提供装置１０２ａ〜１０２ｅからメタデータを収集および管理する装置である。メタデータ収集装置１０１は、たとえば、映像表示機能を備えているテレビやパーソナルコンピュータ（PC）等の機器、もしくは、該機器（テレビ、PCなど）の代わりにメタデータを収集管理する装置である。メタデータ収集装置１０１では、ECGアプリケーションといったメタデータ収集アプリケーションが起動しており、本アプリケーションがメタデータの収集管理を行う。本実施形態では、メタデータを出来るだけ多くメタデータ収集装置１０１上に蓄積することで、メタデータ提供装置１０２ａ〜１０２ｅからのメタデータ収集に要する時間を軽減することを大きな特徴の１つとしている。これによりデジタルテレビ等のコンシューマ機器において、複数のコンテンツ配信サービスから映像コンテンツを検索し視聴するための、高速なナビゲーション機能を実現する。

複数のネットワーク１〜３は、それぞれ異なるネットワークである。異なるネットワークとは以下のようなネットワークである。

異なるネットワーク事業者が運用する、異なるネットワーク
同一ネットワーク事業者が運用する、異なるネットワーク
ローカルエリアネットワーク
異なるネットワーク事業者が運用する異なるネットワークとは、例えば、ネットワーク事業者Aが運用しているネットワーク1とネットワーク事業者Bが運用しているネットワーク2のような場合である。このように物理的に異なるネットワークは、別々のネットワークとして扱う。

同一ネットワーク事業者が運用する異なるネットワークとは、同一のネットワーク事業者がサービス品質等に応じて、異なるネットワークとして運用しているネットワークのような場合である。例えば、ネットワーク1は品質管理されたネットワークであり、ネットワーク2は品質管理されていないベストエフォートなネットワークの場合である。または、ネットワーク１はIPv6ネットワークで、ネットワーク2はIPv4ネットワークである場合であってもよい。このように、物理的もしくは論理的に異なるネットワークは、別々のネットワークとして扱う。

ローカルエリアネットワークとは、例えば、家庭に閉じたホームネットワークなどである。このように、ホームネットワークと外部ネットワークは別々のネットワークとして扱う。

以下、メタデータ収集装置１０１について詳細に説明する。

図２は、メタデータ収集装置の機能ブロック図である。各機能ブロックの説明を以下にそれぞれ示す。

本実施形態において、キャッシュ方式決定部１５は、メタデータを記憶するキャッシュ方式をサービス毎に決定する蓄積方式決定部である。サービス・メタデータ情報蓄積部１９は、メタデータの取得を開始する開始条件、取得するメタデータを選択するための検索条件、及びメタデータの取得を終了する終了条件をキャッシュ方式毎に記憶する記憶部であり、さらに、取得したメタデータを蓄積する蓄積部である。また、キャッシュ管理部１８とメタデータ取得・更新要求部１７は、前述した開始条件、検索条件、及び終了条件と、蓄積されたメタデータの更新を管理し、ネットワークからメタデータを取得する取得部である。

［ユーザインターフェース部１１］
ユーザインターフェース部１１は、ユーザが所望のコンテンツを検索する際にコンテンツの検索条件および検索対象サービスを入力するための入力インターフェースである。また、ユーザインターフェース部１１は、検索結果としてのコンテンツリスト（タイトル等のリスト）を表示する出力インターフェースを提供する。図１０は、コンテンツの検索条件および検索対象サービスを入力するコンテンツ検索画面の例を示す。図１１は、検索されたコンテンツのリストを含む検索結果表示画面の例を示す。

［ネットワークインターフェース部］
ネットワークインターフェース部２０は、ネットワーク１〜３を介して、メタデータ提供装置１０２ａ〜１０２ｅと情報を送受信するためのインターフェース部である。具体的には、メタデータ提供装置１０２ａ〜１０２ｅに対するメタデータ取得要求パケットの送信、及びメタデータ提供装置１０２ａ〜１０２ｅからのメタデータパケットの受信を行うインターフェース部である。

［メタデータ形式統一部１２］
メタデータ形式統一部１２は、複数のメタデータ提供装置１０２ａ〜１０２ｅから収集したメタデータの形式を統一して、形式の統一されたメタデータをサービス・メタデータ情報蓄積部１９に蓄積する。すなわち、メタデータ形式統一部１２は、サービス毎に収集したメタデータを、メタデータ形式の違いを吸収して、サービス・メタデータ情報蓄積部１９に蓄積する。

［端末・サーバ・ネットワーク負荷監視部１３］
端末・サーバ・ネットワーク負荷監視部１３は、メタデータ収集装置１０１のCPU負荷、メタデータ収集装置１０１で稼動している他のアプリケーションの状況、または、ネットワーク負荷やサーバ負荷などの外乱の影響を監視する。例えば、他のアプリケーションの状況の監視としては、メタデータの収集によりその動作が大きな影響を受ける映像受信アプリケーションまたは映像表示アプリケーションなどの動作状況の監視がこれに相当する。

［メタデータ収集速度決定部１４］
メタデータ収集速度決定部１４は、端末・サーバ・ネットワーク負荷監視部１３で監視されている各種負荷状況に応じて、メタデータ収集速度を決定する。ここでメタデータ収集速度は、1リクエスト当たりのメタデータ数、または単位時間当たりのメタデータ収集速度（例えば、1分当たりのメタデータ取得数）である。以降では、メタデータ収集速度とは１リクエスト当たりのメタデータ収集数であるとする。

メタデータ収集速度決定部１４は、以下の指標を基に、メタデータ収集速度を決定する。

（１）自端末のCPU負荷、他のアプリケーションの起動状況
（２）ネットワーク負荷
（３）サーバ負荷
これらの各種負荷に応じて、メタデータ収集速度をどのようにして決定するかを以下に示す。

（１）自端末のCPU負荷、他のアプリケーションの起動状況
自端末のCPU負荷が高い、もしくは他のアプリケーション（例えば、映像受信アプリケーション、映像表示アプリケーション）が起動している場合は、メタデータ収集の影響で、起動中のアプリケーションに影響を及ぼすことが有り得る。このため、１リクエスト当たりのメタデータ取得数を減らす、もしくは少し時間が経ってから再取得する等により、時間をかけてメタデータを収集する。逆に、CPU負荷が低い、もしくは他のアプリケーションが起動していない場合は、メタデータ収集における影響が小さいため、１リクエスト当たりのメタデータ収集数を増やして短時間でメタデータを収集する。

例えば、映像表示アプリケーション起動中にはメタデータ収集速度を1リクエスト当たり5件とする。或いは、映像表示アプリケーション未起動中には、メタデータ収集速度を1リクエスト当たり100件とする。そうすることで、メタデータ収集による影響が大きい映像表示アプリケーションに対する影響を最小限に抑えつつ、メタデータの収集を行うことが可能となる。

（２）ネットワーク負荷
使用可能なネットワーク帯域が少ない、パケットロスが頻繁に発生する、またはパケットのジッタが大きい場合には、ネットワーク負荷が高まっている可能性が高い。そのような状況で大量のメタデータを収集すると、輻輳が発生する等でさらに悪化する可能性がある。それを回避するために、使用可能なネットワーク帯域が少ない、パケットロスが頻繁に発生する、またはジッタが大きい等でネットワーク負荷が大きいなどと想定される場合は、１リクエスト当たりのメタデータ収集数を減らす。もしくは、少し時間が経ってから再取得する等により、時間をかけてメタデータを収集する。逆に、ネットワーク負荷が小さいと想定される場合は、１リクエスト当たりのメタデータ収集数を増やすことにより、短時間でメタデータを収集する。

（３）サーバ負荷
メタデータ収集装置１０１がメタデータ提供装置１０２ｎ(１０２ｎは、１０２ａ〜１０２ｅのいずれか１つ又は複数を示す)からメタデータを収集する際、メタデータ提供装置１０２ｎにおいて発生する処理遅延は、メタデータの収集速度に大きく影響する。例えば、メタデータ提供装置１０２ｎの負荷が非常に高い場合、メタデータ収集装置１０１からメタデータを要求してもメタデータ提供装置１０２ｎから応答が返ってこないために、リクエストタイムアウトが発生し、メタデータ収集装置１０１におけるメタデータの表示がそのリクエストタイムアウトに引きずられ遅くなってしまう等の問題が起きる。その問題を回避するために、メタデータ提供装置１０２ｎからレスポンス速度やメタデータが送信されるまでの所要時間から、メタデータ提供装置１０２ｎの負荷が高いと想定される場合は、１リクエスト当たりのメタデータ収集数を減らす。もしくは、少し時間が経ってから再取得する等により、時間をかけてメタデータを収集する。逆に、メタデータ提供装置１０２ｎの負荷が低いと想定される場合は、１リクエスト当たりのメタデータ収集数を増やすことで、短期間でメタデータを収集する。

以上に示したように、メタデータ収集速度決定部１４では、（１）〜（３）に示した端末，サーバ，ネットワークの負荷を考慮しつつ、メタデータの収集速度を決定する。それにより、効率的にかつ他のアプリケーションに影響を与えることなく、メタデータ収集が可能となる。

［サービス・メタデータ情報蓄積部（蓄積部、記憶部）１９］
サービス・メタデータ情報蓄積部１９は、メタデータ提供装置１０２ａ〜１０２ｅから取得したメタデータを蓄積する蓄積部である。また、サービス・メタデータ情報蓄積部１９は、図８および図９に示すようなサービス毎に設定されたサービス情報を蓄積する。以下に詳細を記すが、サービス情報には、キャッシュ方式決定部（蓄積方式決定部）１５において決定されたキャッシュ方式（蓄積方式）が含まれている。サービス・メタデータ情報蓄積部１９は、サービス毎にキャッシュ方式（蓄積方式）を記憶する記憶部としての役目も持つ。サービス・メタデータ情報蓄積部１９はたとえば、ハードディスクや不揮発性メモリにより構成される。図８および図９ に示すサービス情報は、以下の項目を含む。

対応サービス数
対応サービス名
キャッシュ方式
キャッシュ上限件数
メタデータ取得用情報
登録クエリ数
登録クエリ
検索回数
視聴回数
推奨更新頻度（キャッシュ更新頻度）
推奨更新時間（キャッシュ更新時間）
キャッシュ次更新日時
キャッシュ有効期間
キャッシュ削除日時
「対応サービス数」は、登録されたサービスの数を表しており、図８および図９の例では５つのサービスが登録されている。これら５つのサービスのうちの１つである「映像投稿サービス」が図８に、別の１つである「高品質VoDサービス」が図９に示されている。

「対応サービス名」は、登録されたサービスの名称を表す。すなわち、ECGのようなメタデータ収集アプリケーションで対応しているサービスの名称を表す。

「キャッシュ方式」は、後述するキャッシュ方式決定部（蓄積方式決定部）１５において決定したキャッシュ方式（蓄積方式）を表す。キャッシュ方式には、Query-based Caching Method（検索ベース蓄積方式）と、All Caching Method（事前蓄積方式）とがある。簡単には、All Caching Method（事前蓄積方式）は、サービスが保有（提供）しているメタデータを予めすべてキャッシュする方式である。Query-based Caching Method（検索ベース蓄積方式）は、検索が行われるごとに、検索された検索条件（検索式）について、上位数件のみまたはすべてをキャッシュする方式である。

「キャッシュ上限件数」は、Query-based Caching Method（検索ベース蓄積方式）の場合において、検索毎のキャッシュ件数の上限値を表し、この上限件数までメタデータを取得しキャッシュする。

「メタデータ取得用情報」は、メタデータ提供装置１０２ｎからメタデータを取得する際に必要となる情報である。たとえば、メタデータ提供装置１０２ｎが提供しているメタデータ取得用URLや、各サービスのメタデータを取得するためにECGアプリケーション等のメタデータ収集アプリケーションが用意しているメタデータ収集用APIなどが相当する。

「登録クエリ」は、過去に検索した検索条件である。ただし後述するように、キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）の場合にのみ、検索した検索条件が登録クエリとして登録される。ここで検索条件は、ジャンルとキーワードの組み合わせであり、たとえば、“ジャンル：スポーツ、キーワード：テニス”などである。なお、これに限らず、プロモーション情報（お勧め、新着など）の組み合わせであってもよい。

「登録クエリ数」は、Query-based Caching Method（検索ベース蓄積方式）の場合において、登録クエリの個数を表す。図８の例では、１０個の登録クエリが登録されている。項目「登録クエリ」〜「キャッシュ削除日時」の組は登録クエリ毎に用意され、図８の例では登録クエリが１０個存在するため、「登録クエリ」〜「キャッシュ削除日時」の組が１０個用意される。ただし、All Caching Method（事前蓄積方式）の場合は、登録クエリ数は固定的に「１」が設定される。

「検索回数」は、登録クエリもしくはサービス毎の検索回数を表す。キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）では登録クエリ毎の検索回数、All Caching Method（事前蓄積方式）ではサービス毎の検索回数を表す。

「視聴回数」は、登録クエリもしくはサービス毎の、該当するコンテンツの視聴回数を表す。例えば、ある登録クエリに基づく検索で得られたメタデータからリンクを辿ってコンテンツを視聴した回数が合計でＸ回のとき、視聴回数はＸとなる。

「推奨更新頻度」および「推奨更新時間」は、キャッシュの更新頻度および更新時間を表す。より詳細には、推奨更新頻度は最終更新日時から次更新日時までの間隔であり、推奨更新時間はキャッシュを更新する時間帯である。例えば、「推奨更新頻度：1時間毎」、「推奨更新時間：AM10:00」等である。推奨更新時間および推奨更新頻度は、後述するキャッシュ更新頻度・時間決定部１６で決定した値でもよいし、予めサービス・メタデータ情報蓄積部１９に登録しておいてもよい。

「キャッシュ次更新日時」は、次にキャッシュを更新すべき日時であり、最終更新時間及び、上記推奨更新頻度と上記推奨更新時間から、後述するキャッシュ管理部１８において決定する。

ここで、「推奨更新頻度」および「推奨更新時間」は本発明の更新条件に相当する。特に、推奨更新頻度は本発明の更新頻度に相当し、推奨更新時間は更新時間帯に相当する。または、「キャッシュ次更新日時」が本発明の更新条件に相当する。後述する説明では、更新条件として、上記推奨更新頻度と上記推奨更新時間を反映した指標であるキャッシュ次更新日時を採用する。なお、更新条件は、キャッシュの更新の契機を定めたものであれば、上記の「推奨更新頻度」、「推奨更新時間」、「キャッシュ次更新日時」に限定されるものではない。

「キャッシュ有効期間」は、キャッシュの有効期間であり、後述するキャッシュ更新頻度・時間決定部１６において決定する。キャッシュ有効期間は、キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）の場合にのみ設定される。キャッシュ有効期間はたとえば10日のように設定される。

「キャッシュ削除日時」は、最終更新日時と上記キャッシュ有効期間から、後述するキャッシュ管理部１８において決定する。たとえば、最終更新時間が2008/04/03 AM10:00、キャッシュ有効期間が10日間の場合は、キャッシュ削除日時は2008/04/13 AM10:00となる。

上述したように、サービス・メタデータ情報蓄積部１９に蓄積されるメタデータは、キャッシュ方式がAll Caching Method（事前蓄積方式）のサービスについてはサービス単位で蓄積され、Query-based Caching Method（検索ベース蓄積方式）のサービスについては、サービス毎に登録クエリ単位で記憶される。

［キャッシュ方式決定部（蓄積方式決定部）１５］
キャッシュ方式決定部（蓄積方式決定部）１５は、サービス・メタデータ情報蓄積部１９に登録された各サービスのそれぞれについてキャッシュ方式を決定する。ここで決定したキャッシュ方式は、キャッシュ管理部１８を介して、サービス・メタデータ情報蓄積部１９に登録される。キャッシュ方式は、例えば以下に示す（１）および（２）のうちのいずれかの方式を選択する。

（１）All Caching Method（事前蓄積方式）
本方式は、サービスが保有（提供）しているメタデータを予め全てキャッシュする方式である。全てのメタデータのキャッシュが完了すると、以後は差分のみを定期的に更新する。メタデータ更新は、サービス・メタデータ情報蓄積部１９で管理されているキャッシュ次更新日時に基づいて行われる。

（２）Query-based Caching Method（検索ベース蓄積方式）
本方式は、サービスが保有（提供）するメタデータを予めキャッシュするのではなく、検索された検索条件（検索式）毎に、上位件数のみキャッシュする。上位件数は、サービス毎に決めておき、たとえば、500件のように決めておき、最大で上位件数（500件）分のメタデータを送るようにメタデータ提供装置１０２ｎに要求する。なお、メタデータ提供装置１０２ｎに、検索条件に合致するすべてのメタデータを送るよう要求し、送られたメタデータ数が上位件数を超えるときはこれらのメタデータの中から上位件数のメタデータのみを選択してもよい。この場合、選択基準は任意でよく、例えば最初に取得した上位件数のメタデータでもよい。また、メタデータに優先度が付されているような場合は、優先度の高いものから上位件数のメタデータを選択してもよい。

本方式では、最初の検索時のみメタデータ提供装置１０２ｎから検索条件に合致するメタデータを収集し、以後はその検索単位（すなわちクエリ単位）で定期的に更新タイミングで更新する。更新の際は、キャッシュを削除して登録クエリ（検索条件）毎のメタデータを上限件数まで再取得する。もしくは、一度キャッシュをクリアしなくても、差分のみ取得が可能であれば、差分のみを再取得する。ただ、各登録クエリのキャッシュ件数はある上限件数までとする。

メタデータ更新（キャッシュ更新）は、サービス・メタデータ情報蓄積部１９に登録されているキャッシュ次更新日時に基づいて行われる。またキャッシュの削除は、サービス・メタデータ情報蓄積部１９に登録されているキャッシュ削除日時に基づいて行われる。なお、本方式では、キャッシュの有効期間を設けて、その時間経過後は、キャッシュのクリアを行う。上記説明では、上位件数のメタデータのみをキャッシュするとしたが、検索条件に合致する全てのメタデータをキャッシュするようにしてもよい。

ここで、キャッシュ方式決定部（蓄積方式決定部）１５は、以下の（Ａ）〜（Ｃ）のうちいずれかの指標に従ってキャッシュ方式を決定する。いずれの指標を用いる場合においても、サービス・メタデータ情報蓄積部１９の容量、つまり、ハードディスクやメモリ容量を優先して、判断を行うものとする。

（Ａ）Manual
ユーザが、サービス毎にキャッシュ方式を決定する。例えば、ポップアップを表示し、キャッシュ方式をユーザが決定する。

（Ｂ）Pre-Configure
サービス毎のキャッシュ方式について予め、サービス・メタデータ情報蓄積部１９に登録しておく。例えば、高品質VoD映像サービスではコンテンツ数が限られているため、All Caching Method（事前蓄積方式）を登録し、映像投稿サービスではコンテンツ数が非常に多いのでQuery-based Caching Method（検索ベース蓄積方式）を登録しておく。

（Ｃ）Auto
サービス毎のキャッシュ方式について自動的に判断する。判断は以下のいずれかの判断基準に基づく。ただし、これに限定されるものではなく、キャッシュ方式を判断できる限り、どのような判断基準を用いてもよい。

・サービスから総保有コンテンツ数（メタデータの総数）を取得可能であり、かつ、総コンテンツ数（総メタデータ数）がある閾値以下である場合は、All Caching Method（事前蓄積方式）を決定する。それ以外は、Query-based Caching Method（検索ベース蓄積方式）を決定する。閾値は、定量であってもよいし、ハードディスクの容量を基に決めてもよい。

・サービス毎ではなく、ネットワーク単位でネットワークの種類または品質に応じてキャッシュ方式を判断する。例えば、ホームネットワークや品質管理されたネットワーク上のメタデータ提供装置１０２ｎにより提供されるサービスに対しては、All Caching Method（事前蓄積方式）を決定する。インターネット上のメタデータ提供装置１０２ｎにより提供されるサービスに対しては、Query-based Caching Method（検索ベース蓄積方式）を決定する。また、DLNA（Digital Living Network Alliance）でコンテンツが配信されるネットワークでは、All Caching Method（事前蓄積方式）を決定し、それ以外のネットワークについてはQuery-based Caching Method（検索ベース蓄積方式）を決定する。

・サービスの種類によりキャッシュ方式を判断する。例えば、有料サービスはAll Caching Method（事前蓄積方式）を決定し、無料サービスはQuery-based Caching Method（検索ベース蓄積方式）を決定する。

・メタデータの更新頻度によりキャッシュ方式を判断する。メタデータの更新頻度は、メタデータの総数にも密に連携するため、メタデータの更新頻度が少ないサービスはコンテンツ総数も少ないと見なす。例えば、更新頻度が少ないサービスでは、キャッシュの更新があまりないのでAll Caching Method（事前蓄積方式）を決定し、キャッシュの更新が頻繁であるサービスに関しては、Query-based Caching Method（検索ベース蓄積方式）を決定する。

［キャッシュ更新頻度・時間決定部１６］
キャッシュ更新頻度・時間決定部１６は、キャッシュ管理部１８からの指示により、キャッシュ方式に応じた更新単位（サービス単位または登録クエリ単位）で、キャッシュの推奨更新頻度、推奨更新時間、およびキャッシュ有効期間を決定して、サービス・メタデータ情報蓄積部１９に登録する。推奨更新頻度、推奨更新時間、およびキャッシュ有効期間は、予めサービス毎に、サービス・メタデータ情報蓄積部１９に登録しておいてもよい。推奨更新頻度は本発明の更新頻度に対応し、推奨更新時間は本発明の更新時間帯に相当する。

キャッシュ更新単位はキャッシュ方式により異なり、All Caching Method（事前蓄積方式）はサービス単位での更新となり、またQuery-based Caching Method（検索ベース蓄積方式）は登録クエリ単位での更新となる。また、キャッシュの削除は、キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）の場合のみ行い、キャッシュの有効期間はQuery-based Caching Method（検索ベース蓄積方式）の場合のみ登録する。

キャッシュ更新頻度・時間決定部１６は、以下のような方法により推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定する。

（Ａ）推奨更新頻度
推奨更新頻度は、サービス・メタデータ情報蓄積部１９に登録されている視聴回数または検索回数を基に決定する。視聴回数または検索回数が多いものに関しては、推奨更新頻度を高く設定する。一方、視聴回数または検索回数が少ないものに関しては、推奨更新頻度を低く設定する。例えば、“視聴回数が5回以下なら1日毎に、6-10回なら12時間毎に、11回以上なら6時間毎に”のように視聴回数に応じて推奨更新頻度を決定する。キャッシュ更新頻度・時間決定部１６を用いずに、推奨更新頻度を予めサービス・メタデータ情報蓄積部１９に登録しておいてもよい。この場合は、例えば、ECGアプリケーション起動時にトップ画面に表示するコンテンツに関しては、常に最新の状態に保っておくことが望ましい。したがって、そうしたコンテンツを持つサービス、又はそのコンテンツのメタデータに関連づけられた登録クエリは、推奨更新頻度を高くしておく。

（Ｂ）推奨更新時間
推奨更新時間は、単位時間毎のメタデータ提供装置１０２ｎが提供するメタデータ数の増加数を基に決定する。例えば、単位時間毎にメタデータ提供装置１０２ｎから総メタデータ数を取得し、総メタデータ数の増加の変動が“10時：10件、14時：10件、18時：20件、22時：100件”のような場合には、推奨更新時間は22時と決定する等である。

キャッシュ更新頻度・時間決定部１６を利用せずに予めサービス・メタデータ情報蓄積部１９に推奨更新時間を登録してもよい。この場合、ある特定の時間に頻繁に更新が行われることが分かっているサービスに関しては、その時間を推奨更新時間として登録しておく。例えば、放送サービスのように、日の変わり目にメタデータが更新されることが予め分かっている場合は、日の変わり目を推奨更新時間として登録する。

（Ｃ）キャッシュ有効期間
検索回数または視聴回数に応じて、キャッシュの有効期間を設定する。例えば、“視聴回数が5回以下なら3日、6-10回なら10日、11回以上なら20日”のように視聴回数または検索回数に応じてキャッシュの有効期間を決定する。

［メタデータ取得・更新要求部（取得部）１７］
メタデータ取得・更新要求部１７は、キャッシュ管理部１８からのメタデータ取得要求を受けて、メタデータ提供装置１０２ｎに対してメタデータの取得要求を行う取得部である。また、メタデータを取得する開始条件、検索条件、終了条件などは後述するキャッシュ管理部１８が管理しており、管理部１８も取得部の一部の機能を受け持っている。キャッシュ管理部１８からは、メタデータ収集速度、取得メタデータ数、およびサービス情報（例えばメタデータ取得用情報）が供給され、メタデータ取得・更新要求部１７は、それに基づいてメタデータを取得する。

メタデータ収集速度は、メタデータ提供装置１０２ｎにメタデータの取得要求を行う都度、取得するものとする。例えば、メタデータ収集速度：1リクエスト当たり100件、メタデータ取得数：500件、サービス情報：メタデータ提供装置のメタデータ取得URLが、メタデータ取得・更新要求部１７に渡された場合における挙動の例を以下に示す。

最初のリクエストにおいて100件取得した後、次のリクエストをメタデータ提供装置１０２ｎに要求する場合は、メタデータ収集速度を再度取得する。その際に、CPU負荷が急激に高まった等の現象によりメタデータ収集速度が10件と変更された場合は、その取得速度に応じてメタデータを取得する。以上の動作を繰り返し行うことで、メタデータ取得総数までメタデータを取得する。

［キャッシュ管理部１８］
キャッシュ管理部１８は、主に、メタデータを取得するための開始条件、検索条件、終了条件や、サービス・メタデータ情報蓄積部（蓄積部）１１９の更新を管理し、前述のメタデータ取得・更新要求部１７とともに、取得部としての役目を果たす。以下に詳細を記す。

キャッシュ管理部１８は、サービス・メタデータ情報蓄積部１９に登録された各サービスについて、それぞれに対するキャッシュ方式が登録済みか否かを確認する。登録済みでないサービスについては、キャッシュ方式決定部１５にキャッシュ方式の決定を要求する。キャッシュ方式決定部１５により決定したキャッシュ方式をサービス・メタデータ情報蓄積部（記憶部）１９に登録する。

キャッシュ管理部１８は、All Caching Method（事前蓄積方式）が登録されたサービスについては、初回のみ以下の処理を行う。すなわち、キャッシュ管理部１８は、該サービスに関連するメタデータ提供装置１０２ｎから保有するすべてのメタデータを取得し、該サービスに関連づけてサービス・メタデータ情報蓄積部１９に記憶する。

メタデータの取得要求の際は、メタデータ収集速度決定部１４からメタデータ収集速度を取得してメタデータ取得・更新要求部１７に検索対象サービスとともに指定する。また、キャッシュ管理部１８は、ユーザインターフェース部１１から検索クエリ（検索条件と検索対象サービスとを指定したクエリ）があった場合は、検索対象サービスのキャッシュ方式を判定する。

All Caching Method（事前蓄積方式）の場合は、あらかじめ取得している検索対象サービスのメタデータに基づき検索条件に合致するメタデータを検索し、発見したメタデータをユーザインターフェース部１１を介して表示する。

Query-based Caching Method（検索ベース蓄積方式）の場合は、検索条件に合致する登録クエリが存在するかどうかを判定する。検索条件に合致する登録クエリが存在する場合は、当該登録クエリに対応するメタデータをメタデータ・情報蓄積部１９から取得し、ユーザインターフェース部１１を介して表示する。検索条件に合致する登録クエリが存在しない場合は、メタデータ取得・更新要求部１７にメタデータの取得要求を行い、取得したメタデータをユーザインターフェース部１１を介して表示する。また、取得したメタデータを検索対象サービスにおける検索条件（登録クエリ）と関連づけてサービス・メタデータ情報蓄積部１９に格納する。メタデータの取得要求の際は、検索対象サービス、検索条件、メタデータ収集数を指定するとともに、メタデータ収集速度決定部１４からメタデータ収集速度を取得してメタデータ取得・更新要求部１７に渡す。

なお、キャッシュ管理部１８は、ユーザインターフェース部１１を介して表示されたメタデータの中から特定のメタデータが指定（特定のコンテンツの指定）された場合、指定されたメタデータに対応するコンテンツを、該コンテンツを管理するコンテンツサーバ（メタデータ提供装置がコンテンツサーバの機能を有していても良い）からダウンロードし、コンテンツを処理するコンテンツ処理部（図示せず）に渡すようにしてもよい。この際、コンテンツサーバのアドレスは、たとえばメタデータに含まれている。

また、キャッシュ管理部１８は、検索クエリがあった場合、メタデータを新規に取得した場合、またはキャッシュのメタデータを更新した場合等に、キャッシュ更新頻度・時間決定部１６に対し、キャッシュの推奨更新頻度、推奨更新時間、キャッシュ有効期間の決定を指示する。そして、キャッシュ更新頻度・時間決定部１６により決定された推奨更新頻度、推奨更新時間、キャッシュ有効期間をサービス・メタデータ情報蓄積部１９に登録する。ただし、キャッシュ有効期間の決定および登録はQuery-based Caching Method（検索ベース蓄積方式）のサービスについてのみ行う。

また、キャッシュ管理部１８は、推奨更新時間と推奨更新頻度、および最終更新日時からキャッシュ次更新日時を決定し、サービス・メタデータ情報蓄積部１９に登録する。

また、キャッシュ管理部１８は、キャッシュ有効期間、および最終更新日時からキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部１９に登録する。キャッシュ次更新日時を決定する場合に、推奨更新頻度と推奨更新時間のうちどちらを優先してもかまわない。例えば、最終更新時間：2008/04/03 PM4:00、推奨更新頻度：2日、推奨更新時間：AM3:00の場合は、キャッシュ次更新日時は2008/04/05 PM4:00としても、又は2008/04/05 AM3:00としてもよい。キャッシュ削除日時の決定は、Query-based Caching Method（検索ベース蓄積方式）の場合にのみ行う。

また、キャッシュ管理部１８は、サービス・メタデータ情報蓄積部１９に管理されているサービス情報を定期的に監視し、キャッシュの更新・削除を行う。つまり、キャッシュ管理部１８は、キャッシュ次更新日時（更新条件）およびキャッシュ削除日時を確認し、キャッシュ削除日時が経過したときはキャッシュを削除し、キャッシュ更新日時が経過したときは（更新条件が成立したときは）メタデータの更新処理を行う。ただし、キャッシュの削除は、Query-based Caching Method（検索ベース蓄積方式）の場合にのみ行う。

［動作シーケンス］
以下、図２のメタデータ収集装置１０１の動作シーケンスを（１）メタデータ収集装置１０１の起動時、（２）キャッシュしてあるメタデータの更新タイミング、（３）ユーザ（インターフェース）からの検索クエリの発生の３つに分けて説明する。

（１）メタデータ収集装置１０１の起動時
図３および図４は、メタデータ収集装置１０１の起動時に行われる動作シーケンスを示すフローチャートである。ここで、メタデータ収集装置１０１の起動とはECGのようなメタデータ収集アプリケーションの起動のことである。

（初期起動時）
以下では、ECGアプリケーション起動時に、サービス・メタデータ情報蓄積部１９にコンテンツのメタデータが全くキャッシュされていない場合のシーケンスについて、図３を用いて説明する。なお以降の説明では、一つのサービスに着目したシーケンスについて示すが、複数のサービスがある場合はこれらのシーケンスを並列に処理するか、あるいは、あるサービスが終了してから次のサービスについて処理すればよい。

ステップ１では、メタデータ収集装置１０１の起動を行う。つまり、ECGアプリケーションの起動を行う（Ｓ１０１）。

ステップ2では、サービス・メタデータ情報蓄積部１９に格納されているサービス毎にキャッシュ方式が登録されているか確認を行う（Ｓ１０２）。全てのサービスについて、それぞれキャッシュ方式が決定されている場合は（ＹＥＳ）、ステップ4に進む。また、キャッシュ方式が登録されていないサービスがある場合は（ＮＯ）、ステップ3に進む。

ステップ3では、キャッシュ方式決定部１５において、サービス毎にキャッシュ方式を決定し、サービス・メタデータ情報蓄積部１９に登録する（Ｓ１０３）。キャッシュ方式の決定は、前述した判断基準に基づき行う。キャッシュ方式は、All Caching Method（事前蓄積方式）またはQuery-based Caching Method（検索ベース蓄積方式）を選択する。

ステップ4では、着目するサービスのキャッシュ方式がAll Caching Method（事前蓄積方式）か否かを判断する（Ｓ１０４）。キャッシュ方式がAll Caching Method（事前蓄積方式）の場合は、ステップ5に進む。キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）の場合は、処理を終了する。

ステップ5では、メタデータ収集速度決定部１４において、メタデータの収集速度を決定する（Ｓ１０５）。

ステップ6では、キャッシュ管理部１８は、メタデータ取得・更新要求部１７に対して、ステップ5で決定したメタデータ収集速度と、さらに収集メタデータ数、サービス情報（例えばメタデータ取得用情報）とを送信する。メタデータ取得・更新要求部１７は、それらの情報をもとに、メタデータ提供装置１０２ｎからメタデータを収集する（Ｓ１０６）。All Caching Method（事前蓄積方式）のため、収集メタデータ数は、メタデータ提供装置１０２ｎが保有するすべてのメタデータである。なお、All Caching Method（事前蓄積方式）の場合であっても、ハードディスク容量等に応じて、収集すべきメタデータ数を具体的に計算し、計算したメタデータ数のメタデータのみを収集するようにしてもよい。

ステップ7では、キャッシュ更新頻度・時間決定部１６において、推奨更新頻度、推奨更新時間を決定し、サービス・メタデータ情報蓄積部１９に登録する（Ｓ１０７）。

ステップ8では、キャッシュ管理部１８において、推奨更新頻度および推奨更新時間を基にキャッシュ次更新日時を決定し、サービス・メタデータ情報蓄積部１９に登録し（Ｓ１０８）、本シーケンスを終了する。

（２回目以降の起動時）
メタデータ収集装置１０１の２回目以降の起動時の動作シーケンスについて、図４を用いて説明する。ただし、サービス・メタデータ情報蓄積部１９にはサービス毎にキャッシュ方式は登録済みであるとする。また、少なくともAll Caching Method（事前蓄積方式）のサービスについてはキャッシュがすでに保存されているとする。本シーケンスは、メタデータ収集装置１０１の起動とECGアプリケーションの起動が連動している場合について開示している。ECGアプリケーションが常に起動している（メタデータ収集装置の電源オフ時にもECGアプリケーションがバックグラウンドで起動している）場合は、本シーケンスには当てはまらない。なお、以降では一つのサービスに着目したシーケンスを説明するが、複数のサービスがある場合は、これらのシーケンスを並列に処理する。あるいは、あるサービスが終了してから次のサービスの処理を行えばよい。

図４に示すように、ステップ１では、メタデータ収集装置１０１の起動を行う（Ｓ２０１）。つまり、ECGアプリケーションの起動を行う。

ステップ2では、Query-based Caching Method（検索ベース蓄積方式）のサービス毎に、サービス・メタデータ情報蓄積部１９に登録されているキャッシュ削除日時を経過しているかどうか確認する（Ｓ２０２）。キャッシュ削除日時を経過していた場合は（ＹＥＳ）、キャッシュを削除し（Ｓ２０８）、本シーケンスを終了する。また、キャッシュ削除日時を経過していない場合は（ＮＯ）、ステップ3に進む。

ステップ3では、サービス毎に、サービス・メタデータ情報蓄積部１９に登録されているキャッシュ更新日時を経過しているかどうか確認する（Ｓ２０３）。キャッシュ更新日時を経過していた場合は（ＹＥＳ）、ステップ4に進む。キャッシュ更新日時を経過していない場合（ＮＯ）、本シーケンスは終了する。

ステップ4では、メタデータ収集速度決定部１４において、メタデータの収集速度を決定する（Ｓ２０４）。

ステップ5では、キャッシュ管理部１８がメタデータ取得・更新要求部１７に対して、ステップ4で決定したメタデータ収集速度と、さらに収集メタデータ数、サービス情報（例えばメタデータ取得用情報）を送信する。メタデータ取得・更新要求部１７は、それらの情報をもとに、メタデータ提供装置１０２ｎからメタデータの収集を行う（Ｓ２０５）。ただし、収集メタデータ数の送信はQuery-based Caching Method（検索ベース蓄積方式）の場合についてのみ行う。メタデータ収集の際に、All Caching Method（事前蓄積方式）の場合は、差分のみを収集する。Query-based Caching Method（検索ベース蓄積方式）の場合は、キャッシュ管理部１８から要求された収集メタデータ数（上位件数）のメタデータを、メタデータ提供装置から収集する。

ステップ6では、キャッシュ更新頻度・時間決定部１６において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定し、サービス・メタデータ情報蓄積部１９に登録する（Ｓ２０６）。ただし、有効期間についてはQuery-based Caching Method（検索ベース蓄積方式）の場合のみ決定および登録する。

ステップ7では、キャッシュ管理部１８において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を基に、キャッシュ次更新日時とキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部１９に登録し（Ｓ２０７）、本シーケンスを終了する。ただし、キャッシュ削除日時については、Query-based Caching Method（検索ベース蓄積方式）の場合のみ決定および登録する。

（２）キャッシュの更新・削除タイミング
次に、キャッシュの更新・削除タイミングにおける場合の動作シーケンスについて図５および図６を用いて説明する。以下では、ある一つのサービスに着目したシーケンスを示すが、複数のサービスがある場合は、これらのシーケンスを並列に処理する。あるいは、あるサービスが終了してから次のサービスの処理を行えばよい。

（キャッシュの更新タイミング）
図５は、キャッシュの更新タイミングにおける動作シーケンスを示すフローチャートである。ステップ1では、着目するサービスにおいて、サービス・メタデータ情報蓄積部１９に登録されているキャッシュ更新日時を確認する（Ｓ３０１）。着目するサービスのキャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）の場合は、登録クエリ毎に更新日時を確認する。All Caching Method（事前蓄積方式）の場合は、１つのみ登録されている更新日時を確認する。

ステップ2では、ステップ1で取得したキャッシュ更新日時が現在時刻を経過しているかどうかを確認する（Ｓ３０２）。経過していない場合は（ＮＯ）、本シーケンスは終了する。一方、キャッシュ更新日時を経過している場合は（ＹＥＳ）、ステップ3に進む。

ステップ3では、メタデータ取得・更新要求部１７において、更新単位Query-based Caching Method（検索ベース蓄積方式）の場合は登録クエリまたはAll Caching Method（事前蓄積方式）の場合はサービス）毎にメタデータの更新があるかどうかをメタデータ提供装置に対して確認する（Ｓ３０３）。メタデータの更新がある場合は、ステップ4に進む。メタデータの更新がない場合はステップ7に進む。

ステップ4では、メタデータ収集速度決定部１４において、メタデータの収集速度を決定する（Ｓ３０４）。

ステップ5では、ステップ4で決定したメタデータ収集速度、および収集メタデータ数に従って、メタデータ提供装置１０２ｎからメタデータを収集する。収集したメタデータの形式をメタデータ形式統一部１２で統一して、サービス・メタデータ情報蓄積部１９に蓄積する（Ｓ３０５）。All Caching Method（事前蓄積方式）の場合は、差分のみを取得し、取得した差分をサービス・メタデータ情報蓄積部１９に追加する。この差分は、新たなコンテンツのメタデータのみならず、既に存在するコンテンツについてメタデータ提供装置側で更新されたメタデータも含む。後者の場合はサービス・メタデータ情報蓄積部１９に元々存在する更新前のメタデータは上書きされる。Query-based Caching Method（検索ベース蓄積方式）の場合は、クエリ毎のキャッシュ上限件数のメタデータを取得し、サービス・メタデータ情報蓄積部１９に蓄積する。取得したメタデータと同一コンテンツのメタデータがサービス・メタデータ情報蓄積部１９に既に存在する場合は、既に存在していたメタデータは上書きされる。

ステップ6では、キャッシュ更新頻度・時間決定部１６において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定し、サービス・メタデータ情報蓄積部１９に登録する（Ｓ３０６）。ただし、有効期間についてはQuery-based Caching Method（検索ベース蓄積方式）の場合のみ決定および登録する。

ステップ7では、キャッシュ管理部１８において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を基に、キャッシュ次更新日時とキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部１９に登録し（Ｓ３０７）、本シーケンスを終了する。ただし、キャッシュ削除日時については、Query-based Caching Method（検索ベース蓄積方式）の場合のみ決定および登録する。

（キャッシュの削除タイミング）
図６は、キャッシュの削除タイミングにおける動作シーケンスを示すフローチャートである。本動作シーケンスは、Query-based Caching Method（検索ベース蓄積方式）のサービスについてのみ行う。

ステップ1では、サービス・メタデータ情報蓄積部１９に登録されているキャッシュ削除日時を登録クエリ毎に確認する（Ｓ４０１）。

ステップ2では、ステップ1で取得したキャッシュ削除日時が現在時刻を経過しているかどうかを確認する（Ｓ４０２）。キャッシュ削除日時を経過していない場合は（ＮＯ）、本シーケンスを終了する。一方、キャッシュ削除日時を経過している場合は（ＹＥＳ）、ステップ3に移動する。

ステップ3では、キャッシュ削除日時を経過している登録クエリに対応するキャッシュ（メタデータ）を削除し（Ｓ４０３）、本シーケンスを終了する。

（３）ユーザからの検索クエリの発生
次に、ユーザから検索クエリがあった場合における動作シーケンスについて、図７を用いて説明する。

図７は、ユーザから検索クエリが発生した場合における動作シーケンスを示すフローチャートである。

ステップ1では、図１０に示すような検索画面においてコンテンツの検索条件と、検索対象サービスとを指定する（Ｓ５０１）。図１０の例では検索条件として、例えば「ジャンル」がスポーツ、「キーワード」がテニスとして指定され、また、「検索対象サービス」として高品質VoDサービスと映像投稿サービスとが指定されている。検索条件としては、「ジャンル」、「キーワード」の他に、お勧めコンテンツや新着コンテンツといったプロモーション情報などであってもよい。検索条件と検索対象サービスとを指定した検索クエリがユーザインターフェース部１１からキャッシュ管理部１８に送られる。

ステップ2では、キャッシュ管理部１８が、ステップ1で受けた検索クエリを基に、サービス・メタデータ情報蓄積部１９において、指定されたサービス毎に、キャッシュメモリ方式を判断し、All Cashing Method（事前蓄積方式）の場合は、無条件にステップ5に進む。Query-based Caching Method（検索ベース蓄積方式）の場合は、検索クエリに含まれる検索条件に合致する登録クエリがサービス・メタデータ情報蓄積部１９に登録されているかどうかを判定する。検索条件に合致する登録クエリが登録されている場合は（Ｓ５０２のＹＥＳ）ステップ5に進み、登録されていない場合は（Ｓ５０２のＮＯ）ステップ3に進む。

例えば、サービス・メタデータ情報蓄積部１９に図８および図９のようなサービス情報が登録されている場合、高品質VoDサービスの場合は、All Cashing Method（事前蓄積方式）のため、ステップ5に進む。一方、映像投稿サービスでは、キャッシュとして“ジャンル：スポーツ、キーワード：テニス”といった登録クエリのみ記憶されている。したがって、この登録クエリと同一の検索条件が指定された場合は、ステップ5に進み、この登録クエリと異なる検索条件が指定された場合は、ステップ3に進む。

ステップ3では、メタデータ収集速度決定部１４において、メタデータの収集速度を決定する（Ｓ５０３）。

ステップ4では、キャッシュ管理部１８は、メタデータ取得・更新要求部１７に対して、ステップ3で決定したメタデータ収集速度と、さらに収集メタデータ数（上位件数）、サービス情報（例えばメタデータ取得用情報）とを送信する。メタデータ取得・更新要求部１７は、それらの情報をもとに、メタデータ提供装置１０２ｎからメタデータの収集を行う（Ｓ５０４）。ここで、メタデータの取得に際して、検索結果をなるべく早く提示するという観点から、必要最低限数のメタデータを取得した時点でステップ5に移動してもよい。例えば、図１１のように１画面に表示可能なメタデータ数が5件で、キャッシュ管理部１８から要求された収集メタデータ数が500件の場合は、画面の遷移も考慮して20件取得したら、ステップ5に進む。残りのメタデータ480件（=500-20）は、検索結果を表示した後に順次取得してもよい。

ステップ5では、キャッシュ更新頻度・時間決定部１６において、推奨更新頻度、推奨更新時間、およびキャッシュ有効期間を決定して、サービス・メタデータ情報蓄積部１９に登録し（Ｓ５０５）、ステップ6に移動する。ただし、キャッシュ有効期間の決定はQuery-based Caching Method（検索ベース蓄積方式）のサービスについてのみ行う。

ステップ6では、キャッシュ管理部１８において、推奨更新頻度、推奨更新時間、およびキャッシュ有効期間を基に、キャッシュ次更新日時とキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部１９に登録する（Ｓ５０６）。ただし、キャッシュ削除日時の決定および登録は、Query-based Caching Method（検索ベース蓄積方式）のサービスについてのみ行う。

ステップ7では、検索対象となるすべてのサービスについて、サービス・メタデータ情報蓄積部１９からメタデータを取得する（Ｓ５０７）。すなわち、Query-based Caching Method（検索ベース蓄積方式）のサービスについては、検索条件にマッチする登録クエリに対応付けられたメタデータをサービス・メタデータ情報蓄積部１９から取得する。All Cashing Method（事前蓄積方式）のサービスについては、検索条件に合致するメタデータをサービス・メタデータ情報蓄積部１９から検出して取得する。そして、ユーザインターフェース部１１は、サービス・メタデータ情報蓄積部１９から取得したメタデータをマージして表示する（Ｓ５０７）。表示されたメタデータの一例を図１１に示す。ここでマージ方法は、指定した項目に従って表示するものであればよく、例えば、日付順や名前順に表示されるようなマージ方法を用いることができる。

以上のように、本発明の実施形態によれば以下の効果を得ることができる。

（１）サービス毎にそのサービスに適したメタデータのキャッシュ方式を選択することで、効率的なメタデータのキャッシュが可能となる。

（２）キャッシュされたメタデータの効率的な更新が可能となる。例えば需要の高いコンテンツのメタデータは概ね最新の状態に保ち、需要の低いコンテンツのメタデータについては無意味な更新を防ぐことが可能となる。

（３）メタデータ収集による受信端末の他アプリケーションへの影響を最小限に抑えることが可能となる。また、ネットワーク負荷やメタサーバ負荷を考慮したメタデータ収集速度を設定することで、外乱による影響を最小限に抑えることが可能となる。

なお、このメタデータ収集装置１０１は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、ユーザインターフェース部、キャッシュ方式決定部、キャッシュ管理部、メタデータ収集速度決定部、キャッシュ更新頻度・時間決定部、端末・サーバ・ネットワーク負荷監視部、メタデータ取得・更新要求部は、コンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、メタデータ収集装置１０１は、プログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、サービス・メタデータ情報蓄積部１０９は、コンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

（第２の実施形態）
第1の実施形態では、メタデータ収集装置１０１が、All Caching Method（事前蓄積方式）、Query-based Caching Method（検索ベース蓄積方式）の2種類の蓄積方式（以下、キャッシュ方式という）からいずれかを選択して使用する例を説明した。第２の実施形態では、メタデータ収集装置１０１におけるキャッシュ方式として、All Caching Method（事前蓄積方式）、Query-based Caching Method（検索ベース蓄積方式）、及びKeyword-based Caching Method （キーワードベース事前蓄積方式）を備え、メタデータ収集装置１０１が上記３種類のキャッシュ方式からいずれかを選択して使用するものである。以下の説明では、第1の実施形態と同様の説明は省略し、第1の実施形態と異なる点を中心に説明する。

本実施形態におけるコンテンツ配信システムは、第1の実施形態（図１）と同様である。

図１３は、本実施形態に係るメタデータ収集装置１０１’の構成を示すブロック図である。図１３に示す本実施形態におけるメタデータ収集装置１０１’は、第1の実施形態におけるメタデータ収集装置１０１（図２）と比べて、ジャンル・キーワード登録情報蓄積部１２１とジャンル・キーワード変換情報蓄積部１２２が新たに加わっている点が異なる。以下に、各機能ブロックの説明を記す。

なお、第1の実施形態と同様に、本実施形態においても、キャッシュ方式決定部１１５はメタデータを記憶するキャッシュ方式をサービス毎に決定する蓄積方式決定部である。また、サービス・メタデータ情報蓄積部１１９はメタデータの取得を開始する開始条件、取得するメタデータを選択するための検索条件、及びメタデータの取得を終了する終了条件をキャッシュ方式毎に記憶する記憶部であり、さらに、取得したメタデータを蓄積する蓄積部である。また、キャッシュ管理部１１８とメタデータ取得・更新要求部１７は、前述の開始条件、検索条件、及び終了条件と、蓄積されたメタデータの更新とを管理し、ネットワークからメタデータを取得する取得部である。

ユーザインターフェース部１１、メタデータ形式統一部１２、端末・サーバ・ネットワーク負荷管理部１３、メタデータ収集速度決定部１４、メタデータ取得・更新要求部１７、ネットワークインターフェース部２０は、第1の実施形態と同様である。キャッシュ方式決定部（蓄積方式決定部）１１５、キャッシュ更新頻度時間決定部１１６、キャッシュ管理部１１８、サービス・メタデータ情報蓄積部（蓄積部、記憶部）１１９、ジャンル・キーワード登録情報蓄積部１２１、ジャンル・キーワード変換情報蓄積部１２２は、第1の実施形態と異なる。したがって、これらの機能ブロックの説明を以下に記す。

［サービス・メタデータ情報蓄積部（蓄積部、記憶部）１１９］
サービス・メタデータ情報蓄積部１１９は、メタデータ提供装置１０２ａ〜１０２ｅから取得したメタデータを蓄積する蓄積部である。つまり、サービス・メタデータ情報蓄積部１１９は、サービス毎に設定されたサービス情報を蓄積する。また、サービス情報には、キャッシュ方式決定部（蓄積方式決定部）１１５において決定されたキャッシュ方式が含まれており、サービス・メタデータ情報蓄積部１１９はサービス毎にキャッシュ方式を記憶する記憶部としての役目も持つ。サービス・メタデータ情報蓄積部１１９は、例えばハードディスクや不揮発性メモリにより構成される。

サービス情報の例を、図８、図９、および図１５ に示す。サービス情報は、以下の項目を含む。ただし、キャッシュ方式によって、すべての項目を含むとは限らない。

対応サービス数
対応サービス名
キャッシュ方式
キャッシュ上限件数
メタデータ取得用情報
登録クエリ数
登録クエリ
蓄積キーワード・ジャンル数
蓄積キーワード
蓄積ジャンル
検索回数
視聴回数
推奨更新頻度（キャッシュ更新頻度）
推奨更新時間（キャッシュ更新時間）
キャッシュ次更新日時
キャッシュ有効期間
キャッシュ削除日時
上記サービス情報の項目のうち、第1の実施形態と異なる項目について、以下に説明する。

「キャッシュ方式」は、後述するキャッシュ方式決定部（蓄積方式決定部）１１５において決定したキャッシュ方式を表す。キャッシュ方式は以下のいずれかである。

Query-based Caching Method（検索ベース蓄積方式）
All Caching Method（事前蓄積方式）
Keyword-based Caching Method（キーワードベース事前蓄積方式）
All Caching Method（事前蓄積方式）は、サービスが保有しているメタデータを予めすべてキャッシュする方式である。Query-based Caching Method（検索ベース蓄積方式）は、検索が行われるごとに、検索された検索条件について、上位数件のみ又はすべてをキャッシュする方式である。Keyword-based Caching Method（キーワードベース事前蓄積方式）は、予めキャッシュするキーワードもしくはジャンルを指定して、そのキーワードもしくはジャンルに基づき予めコンテンツを取得する方式である。キーワード、ジャンルの指定方法は後述する。

「キャッシュ上限件数」は、Query-based Caching Method（検索ベース蓄積方式）の場合において、検索毎のキャッシュ件数の上限値を表し、この上限件数までメタデータを取得しキャッシュする。また、Keyword-based Caching Method （キーワードベース事前蓄積方式）の場合は、指定キーワード毎のキャッシュ件数の上限値を示し、この上限件数までメタデータを蓄積する。

「蓄積キーワード・ジャンル数」は、Keyword-based Caching Method （キーワードベース事前蓄積方式）において、事前にキャッシュしている蓄積キーワードと蓄積ジャンルの総数である。図１５に示すサービス情報の例では、１０組の蓄積キーワードと蓄積ジャンルのペアが登録されている。項目「蓄積キーワード」〜「キャッシュ削除日時」の組は、蓄積キーワードと蓄積ジャンルのペア毎に用意される。

「蓄積キーワード」は、事前に蓄積しているコンテンツのキーワードを示している。本項目は、キャッシュ方式がKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合にのみ、メタデータ提供装置１０２ｎ(１０２ｎは、１０２ａ〜１０２ｅのいずれか１つ又は複数を示す)から該当するメタデータを取得した時点で、キーワードが設定される。「蓄積キーワード」として登録するものは、キーワードに限らず、プロモーション情報（新着情報、おすすめ情報、など）でもよい。ここでキーワードの登録方法の具体例を以下に挙げる。

・初期化時から登録：装置の初期出荷時に予め、プレフィックスされたキーワードリストを登録する方法である。

・手動で登録：ユーザインターフェース１１から明示的に取得したいキーワードリストを指定する方法である。

・ネットワークを介してキーワードを取得し登録：ネットワーク上にあるキーワードリストを取得して、取得したキーワードを指定する方法である。例えば、最近話題になっているキーワード（ホットワード等）のリストを取得する、該サービスでの新着、人気コンテンツのキーワードを取得する、キーワードリストを記載したファイルを取得する等の方法がある。ただし、これらの方法に限らず、装置外からキーワードが取得可能であればどのような方法でも良い。

「蓄積ジャンル」は、事前に蓄積しているコンテンツのジャンルを示す。キャッシュ方式がKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合にのみ、コンテンツのジャンルが蓄積ジャンルに登録される。メタデータ収集装置１０１’が、メタデータ提供装置１０２ｎからメタデータを取得した時点で、該当ジャンルを登録するものとする。なお、ジャンル・キーワード変換情報を用いてジャンルをキーワードに展開して検索を行う場合は、その際の検索キーワードとジャンルを合わせて登録する。

「検索回数」は、蓄積キーワード、ジャンルもしくは登録クエリもしくはサービス毎の検索回数を表す。キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）では登録クエリ毎の検索回数を示し、All Caching Method（事前蓄積方式）ではサービス毎の検索回数を示し、Keyword-based Caching Method （キーワードベース事前蓄積方式）ではキーワード毎の検索回数を示す。

「キャッシュ有効期間」は、キャッシュの有効期間であり、後述するキャッシュ更新頻度・時間決定部１１６において決定する。キャッシュ有効期間は、キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合にのみ設定される。キャッシュ有効期間はたとえば10日のように設定される。

上述したように、サービス・メタデータ情報蓄積部１１９は、サービス情報（メタデータ）を蓄積する。メタデータは、キャッシュ方式がAll Caching Method（事前蓄積方式）のサービスについてはサービス単位で蓄積される。また、Query-based Caching Method（検索ベース蓄積方式）のサービスについては、サービス毎に登録クエリ単位で蓄積される。また、Keyword-based Caching Method（キーワードベース事前蓄積方式）では、サービス毎に登録キーワード単位で記憶される。

［ジャンル・キーワード登録情報蓄積部１２１］
ジャンル・キーワード登録情報蓄積部１２１は、サービス毎に設定されたジャンル・キーワード登録情報を蓄積する。ジャンル・キーワード登録情報は、予め蓄積するべきキーワードもしくはジャンルを設定する情報である。ジャンル・キーワード登録情報は、キャッシュ方式がKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合にのみ使用される。ジャンル・キーワード登録情報蓄積部１２１は、例えばハードディスクや不揮発性メモリにより構成される。図１６に、ジャンル・キーワード登録情報の例を示す。キーワード・ジャンル登録情報は、以下の項目を含む。

サービス名
ジャンルの設定可否
登録ジャンル数
登録ジャンル名
登録キーワード数
登録キーワード
「サービス名」は、登録されたサービスの名称を表す。

「ジャンルの設定可否」は、該当サービスにおいてジャンルを用いた検索の可否を示す。本項目が不可の場合は、後述するジャンル・キーワード変換情報に従って、ジャンルをキーワードに変換する。

「登録ジャンル数」は、登録されたジャンルの数を示す。

「登録ジャンル名」は、登録されたジャンルの名称を表す。図１６に示す例では、ジャンル名を「野球」という文字列で登録しているが、装置内で一意に判別できる数値（ジャンルコード）でもよい。

「登録キーワード数」は、登録されたキーワードの個数を示す。

「登録キーワード」は、登録されたキーワードを示す。

ジャンル・キーワード登録情報を、ジャンル・キーワード登録情報蓄積部１２１に設定する方法の具体例を以下に挙げる。

・初期出荷時に設定：機器の初期出荷時に、予めサービス毎のジャンル・キーワード登録情報を設定しておく方法である。

・手動で登録：ユーザインターフェース１１からジャンル・キーワード登録情報を設定する方法である。

・ネットワークを介してジャンル・キーワードを取得し登録：ネットワーク上にあるジャンル・キーワードリストを取得して、取得したジャンル・キーワードを指定する方法である。例えば、最近話題になっているジャンル・キーワード（ホットワード等）のリストを取得する、該サービスでの新着、人気コンテンツのジャンル・キーワードを取得する、ジャンル・キーワードリストを記載したファイルを取得する等の方法がある。ただし、これらの方法に限らず、装置外からジャンル・キーワードが取得可能であればどのような方法でも良い。

また、登録するものはジャンル・キーワードに限らず、プロモーション情報（新着情報、おすすめ情報、など）でもよい。

［ジャンル・キーワード変換情報蓄積部１２２］
ジャンル・キーワード変換情報蓄積部１２２は、ジャンルからキーワードに変換するために必要なジャンル・キーワード変換情報を蓄積する。ジャンルが検索条件に含めることが出来ない場合でも、サービスのメタデータを検索可能とするために、ジャンル・キーワード変換情報をジャンル・キーワード変換情報蓄積部１２２に保持する。ジャンル・キーワード変換情報蓄積部１２２は、例えばハードディスクや不揮発性メモリにより構成される。図１７に、ジャンル・キーワード変換情報の例を示す。ジャンル・キーワード変換情報は、以下の項目を含む。

ジャンル数
ジャンル名
キーワード数
キーワード
「ジャンル数」は、設定されたジャンルの数を示す。

「ジャンル名」は、設定されたジャンル名を示す。

「キーワード数」は、該当ジャンルに設定されたキーワードの数を示す。

「キーワード数」は、該当ジャンルに設定されたキーワード名を示す。

ジャンル・キーワード変換情報を、ジャンル・キーワード変換情報蓄積部１２２に設定する方法の具体例を以下に挙げる。

・初期出荷時に設定：初期出荷時に、ジャンルとキーワードの変換情報を登録しておく方法である。

・手動で登録：ユーザインターフェース部１１からジャンルとキーワードの変換情報を登録する方法である。

・ネットワークを介してジャンル・キーワード変換情報を取得し登録：例えば、ネットワーク上のサーバにジャンル・キーワード変換情報のファイルを設ける。メタデータ収集装置１０１’は、サーバからそのファイルを取得し、ジャンル・キーワード変換情報蓄積部１２２に設定する。ただし、この方法に限らず、装置外からジャンル・キーワード変換情報が取得可能であればどのような方法でも良い。

［キャッシュ方式決定部（蓄積方式決定部）１１５］
キャッシュ方式決定部（蓄積方式決定部）１１５は、サービス・メタデータ情報蓄積部１１９に登録された各サービスのそれぞれについてキャッシュ方式を決定する。ここで決定したキャッシュ方式は、キャッシュ管理部１８を介して、サービス・メタデータ情報蓄積部（記憶部）１１９に登録される。キャッシュ方式は、以下に示す（１）、（２）、（３）のうちのいずれかの方式を選択する。もしくは、（２）と（３）をともに選択してもよい。

（１）All Caching Method（事前蓄積方式）
第１の実施形態と同様であるため、説明を省略する。

（２）Query-based Caching Method（検索ベース蓄積方式）
第１の実施形態と同様であるため、説明を省略する。

（３）Keyword-based Caching Method （キーワードベース事前蓄積方式）
Keyword-based Caching Method（キーワードベース事前蓄積方式）は、サービスが保有（提供）するメタデータを予めすべてキャッシュするのではなく、ジャンル・キーワード登録情報蓄積部１２１で管理されているキーワード・ジャンル登録情報から取得したキーワード、および又はジャンル毎に上位件数のみをキャッシュする。上位件数は、サービス毎に決めておき（たとえば、500件）、最大で上位件数（500件）分のメタデータを送るようにメタデータ提供装置１０２ｎに要求する。なお、メタデータ提供装置１０２ｎに、検索条件に合致するすべてのメタデータを送るよう要求し、送られたメタデータ数が上位件数を超えるときは、これらのメタデータの中から上位件数のメタデータのみを選択してもよい。この場合、選択基準は任意でよい。たとえば最初に取得した上位件数のメタデータでもよいし、メタデータに優先度が付されているような場合は、優先度の高いものから上位件数のメタデータを選択してもよい。

Keyword-based Caching Method（キーワードベース事前蓄積方式）では、登録されたキーワードを基にサービス毎の検索式を作成し、メタデータ提供装置１０２ｎからメタデータを収集する。以後は、その検索式単位（すなわちキーワード、および又はジャンル単位）で定期的な更新タイミングで更新する。更新の際は、キャッシュを削除して登録クエリ（検索条件）毎のメタデータを上限件数まで再取得する。もしくは、一度キャッシュをクリアしなくても、差分のみ取得が可能であれば、差分のみを再取得する。ただ、各登録キーワード、ジャンルのキャッシュ件数はある上限件数までとする。

キャッシュ方式決定部（蓄積方式決定部）１１５は、以下の（Ａ）〜（Ｃ）のうちいずれかの指標に従ってキャッシュ方式を決定する。ただし、いずれの指標を用いる場合においても、サービス・メタデータ情報蓄積部１１９の容量（ハードディスクやメモリ容量）を考慮する。

（Ａ）Manual
ユーザがサービス毎にキャッシュ方式を決定する。たとえば、ポップアップを表示し、キャッシュ方式をユーザが決定する。

（Ｂ）Pre-Configure
あらかじめ、サービスに応じたキャッシュ方式を、サービス・メタデータ情報蓄積部１１９に登録しておく。たとえば、高品質VoD映像サービスではコンテンツ数が限られているため、All Caching Method（事前蓄積方式）を登録する。映像投稿サービスでは、コンテンツ数が非常に多いのでQuery-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）を登録しておく。

（Ｃ）Auto
使用するキャッシュ方式を自動的に選択する。判断は以下のいずれかの判断基準に基づく。ただし、これらの判断基準に限らず、キャッシュ方式を選択できればどのような判断基準を用いてもよい。

・サービスから総保有コンテンツ数（メタデータの総数）を取得可能であり、かつ、総コンテンツ数（総メタデータ数）がある閾値以下である場合はAll Caching Method（事前蓄積方式）を選択する。それ以外は、Query-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）、またはその両方式を選択する。上記の閾値は、定量でもよいし、ハードディスクの容量を基に定めてもよい。

・サービス毎ではなく、ネットワークの種類または品質に応じてキャッシュ方式を選択する。例えば、ホームネットワークや品質管理されたネットワーク上のメタデータ提供装置により提供されるサービスに対してはAll Caching Method（事前蓄積方式）を選択する。一方、Internet上のメタデータ提供装置により提供されるサービスに対しては、Query-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）、またはその両方式を選択する。また、DLNA（Digital Living Network Alliance）でコンテンツが配信されるネットワーク上のメタデータ提供装置により提供されるサービスに対しては、All Caching Method（事前蓄積方式）を選択する。それ以外のネットワークについては、Query-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）、またはその両方式を選択する。

・サービスの種類によりキャッシュ方式を選択する。例えば、有料サービスはAll Caching Method（事前蓄積方式）を選択する。一方、無料サービスはQuery-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）、またはその両方式を選択する。

・メタデータの更新頻度によりキャッシュ方式を選択する。メタデータの更新頻度は、メタデータの総数にも密に連携するため、メタデータの更新頻度が少ないサービスはコンテンツ総数も少ないと見なす。例えば、更新頻度が少ないサービスでは、キャッシュの更新があまりないのでAll Caching Method（事前蓄積方式）を選択する。一方、キャッシュの更新が頻繁であるサービスに関しては、Query-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）、またはその両方式を選択する。

［キャッシュ更新頻度・時間決定部１１６］
キャッシュ更新頻度・時間決定部１１６は、キャッシュ管理部１８からの指示により、キャッシュ方式に応じた更新単位（サービス単位、登録クエリ単位、登録キーワード単位、登録ジャンル単位）で、キャッシュの推奨更新頻度（更新頻度）、推奨更新時間（更新時間帯）、およびキャッシュ有効期間を決定する。そして、これらの情報を、サービス・メタデータ情報蓄積部１１９に登録する。キャッシュ更新頻度・時間決定部１１６における推奨更新頻度、推奨更新時間、およびキャッシュ有効期間の決定方法は、第1の実施形態と同様である。

キャッシュ更新単位はキャッシュ方式により異なり、All Caching Method（事前蓄積方式）はサービス単位で更新する。また、Query-based Caching Method（検索ベース蓄積方式）は登録クエリ単位で更新する。Keyword-based Caching Method （キーワードベース事前蓄積方式）は登録キーワード単位、もしくは登録ジャンル単位で更新する。

また、キャッシュの削除は、キャッシュ方式がQuery-based Caching Method（検索ベース蓄積方式）もしくはKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合のみ行う。従って、キャッシュの有効期間はQuery-based Caching Method（検索ベース蓄積方式）またはKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合のみサービス・メタデータ情報蓄積部１１９に登録される。

［キャッシュ管理部１１８］
キャッシュ管理部１１８は、主に、メタデータを取得するための開始条件、検索条件、終了条件といった蓄積方式情報や、サービス・メタデータ情報蓄積部（蓄積部）１１９に蓄積されたメタデータの更新を管理する。キャッシュ管理部１１８は、前述のメタデータ取得・更新要求部１７とともに、取得部としての役目を果たす。蓄積方式情報は、キャッシュ方式毎に定められている。例えば、All Caching Method（事前蓄積方式）の場合、開始条件は周期的に定められた時刻である。検索条件は、サービスが提供するすべてのコンテンツのメタデータを取得することを示す識別子もしくは検索式である。終了条件は、検索条件に従ってすべてのコンテンツのメタデータ取得の完了時である。

また、Query-based Caching Method（検索ベース蓄積方式）の場合、開始条件はユーザインターフェース１１からメタデータ取得要求を通知されたときである。検索条件は、あらかじめ定めた検索式である。終了条件は、検索式に合致するメタデータをあらかじめ定めた閾値の数まで取得完了したときである。

また、Keyword-based Caching Method （キーワードベース事前蓄積方式）の場合、開始条件は周期的に定められた時刻である。検索条件は、あらかじめ定めた検索式である。終了条件は、検索式に合致するメタデータをあらかじめ定めた閾値の数まで取得完了したときである。

これらの蓄積方式情報は、キャッシュ方式毎にサービス・メタデータ情報蓄積部１１９に格納されている。キャッシュ管理部１１８は、サービス・メタデータ情報蓄積部１１９からこれらの蓄積方式情報を取得し、メタデータ取得・更新要求部１７に通知する。

以下に、キャッシュ管理部の詳細を記す。

キャッシュ管理部１１８は、サービス・メタデータ情報蓄積部１１９に登録された各サービスについて、キャッシュ方式が登録済みか否かを確認する。登録済みでないサービスについては、キャッシュ管理部１１８からキャッシュ方式決定部（蓄積方式決定部）１１５にキャッシュ方式の決定を要求し、キャッシュ方式決定部（蓄積方式決定部）１１５により決定されたキャッシュ方式をサービス・メタデータ情報蓄積部（記憶部）１１９に登録する。

キャッシュ方式がAll Caching Method（事前蓄積方式）またはQuery-based Caching Method（検索ベース蓄積方式）の場合のキャッシュ管理部１１８の処理は、実施形態１と同様である。以下には、キャッシュ方式がKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合におけるキャッシュ管理部１１８の処理を記す。

キャッシュ管理部１１８は、メタデータ提供装置１０２ｎから、当該メタデータ提供装置１０２ｎが保有するすべてのメタデータを取得する。そして、取得したメタデータを、該サービスに関連づけてサービス・メタデータ情報蓄積部１１９に記憶する。特に初回起動時には、キャッシュ管理部１１８は、登録されたキーワードもしくはジャンルに該当するメタデータをメタデータ提供装置１０２ｎから取得する。そして、取得したメタデータを、サービス及びキーワードもしくはジャンルに関連づけてサービス・メタデータ情報蓄積部１１９に記憶する。ここで、ジャンルが登録されている場合は、ジャンル・キーワード変換情報を用いて、ジャンルから変換したキーワードに該当するメタデータをメタデータ提供装置１０２ｎから取得してもよい。その場合には、サービス・メタデータ情報蓄積部１１９に、ジャンルとキーワードを合わせて登録しておく。

キャッシュ管理部１１８がメタデータを取得する際、メタデータ収集速度決定部１４からメタデータ収集速度を取得してメタデータ取得・更新要求部１７に通知する。それとともに、キャッシュ管理部１１８は、検索対象サービス、検索条件、メタデータ収集数をメタデータ取得・更新要求部１７に通知する。また、キャッシュ管理部１１８は、ユーザインターフェース部１１から検索クエリ（検索条件と検索対象サービスとを指定したクエリ）があった場合は、検索対象サービスのキャッシュ方式を判定する。

また、キャッシュ管理部１１８は、メタデータの検索処理を行う。キャッシュ管理部１１８は、キャッシュ方式を判定した結果、Keyword-based Caching Method （キーワードベース事前蓄積方式）の場合は、その検索クエリにおける検索条件に合致する登録キーワード、ジャンルが存在するかどうかを判定する。検索条件に合致する登録キーワードが存在する場合は、当該登録キーワード、ジャンルに対応するメタデータをメタデータ・情報蓄積部１１９から取得し、ユーザインターフェース部１１を介して表示する。検索条件に合致する登録キーワードが存在しない場合は、メタデータ取得・更新要求部１７にメタデータの取得要求を行い、取得したメタデータをユーザインターフェース部１１を介して表示する。また、取得したメタデータを検索対象サービスにおける検索条件（登録クエリ）と関連づけてサービス・メタデータ情報蓄積部１１９に格納する。なお、検索条件にジャンルが指定された場合は、ジャンル・キーワード変換情報蓄積部１２２のジャンル・キーワード変換情報を参照し、ジャンルをキーワードに変換してメタデータ取得・更新要求部１７にメタデータの取得要求を行ってもよい。

また、キャッシュ管理部１１８は、検索クエリがあった場合、メタデータを新規に取得した場合、またはキャッシュのメタデータを更新した場合等に、キャッシュ更新頻度・時間決定部１１６に対し、キャッシュの推奨更新頻度、推奨更新時間、およびキャッシュ有効期間の計算を指示する。そして、計算された推奨更新頻度、推奨更新時間、およびキャッシュ有効期間をサービス・メタデータ情報蓄積部１１９に登録する。

また、キャッシュ管理部１１８は、推奨更新時間と推奨更新頻度、および最終更新日時からキャッシュ次更新日時を決定し、サービス・メタデータ情報蓄積部１１９に登録する。また、キャッシュ管理部１１８は、キャッシュ有効期間、および最終更新日時からキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部１１９に登録する。キャッシュ次更新日時を決定する場合に、推奨更新頻度と推奨更新時間のうちどちらを優先してもかまわない。たとえば、最終更新時間：2008/04/03 PM4:00、推奨更新頻度：2日、推奨更新時間：AM3:00の場合は、キャッシュ次更新日時は2008/04/05 PM4:00としても、2008/04/05 AM3:00としてもよい。

また、キャッシュ管理部１１８は、サービス・メタデータ情報蓄積部１１９に管理されているサービス情報を定期的に監視し、キャッシュの更新・削除を行う。つまり、キャッシュ管理部１１８は、キャッシュ次更新日時（更新条件）およびキャッシュ削除日時を確認し、キャッシュ削除日時が経過したときはキャッシュを削除し、キャッシュ更新日時が経過したときは（更新条件が成立したときは）メタデータの更新処理を行う。

［動作シーケンス］
以下、本実施形態に係るメタデータ収集装置１０１’において、キャッシュ方式がKeyword-based Caching Method （キーワードベース事前蓄積方式）である場合の、初回起動時の動作シーケンスを説明する。キャッシュ方式がAll Caching Method（事前蓄積方式）やAll Caching Method（事前蓄積方式）の場合の、メタデータ収集装置１０１’の動作シーケンスは、第1の実施形態と同様である。また、Keyword-based Caching Method （キーワードベース事前蓄積方式）における他の動作シーケンス（２回目以降の起動時の動作や、キャッシュの更新・削除のタイミング）は、第1の実施形態に記載のQuery-based Caching Method（検索ベース蓄積方式）と同様である。

図１４はメタデータ収集装置１０１’の初回起動時に行われる動作シーケンスを示すフローチャートである。ここでメタデータ収集装置１０１’の起動とはECGのようなメタデータ収集アプリケーションの起動のことである。

ステップ１では、メタデータ収集装置１０１’の起動を行う。つまり、ECGアプリケーションを起動する（Ｓ１４０１）。

ステップ2では、サービス・メタデータ情報蓄積部１１９に格納されているサービス毎にキャッシュ方式が登録されているか確認を行う（Ｓ１４０２）。各サービスについてキャッシュ方式が登録されている場合は（ＹＥＳ）、ステップ4に進む。また、キャッシュ方式が登録されていないサービスがある場合は（ＮＯ）、ステップ3に進む。

ステップ3では、キャッシュ方式決定部１１５において、サービス毎にキャッシュ方式を決定する。そして、決定したキャッシュ方式をサービス・メタデータ情報蓄積部１１９に登録する（Ｓ１４０３）。キャッシュ方式の決定は、前述した判断基準に基づき行う。ここでは、例えば、キャッシュ方式として、Keyword-based Caching Method （キーワードベース事前蓄積方式）を選択する。

ステップ4では、着目するサービスのキャッシュ方式がKeyword-based Caching Method （キーワードベース事前蓄積方式）であるか否かを判断する（Ｓ１４０４）。キャッシュ方式がKeyword-based Caching Method （キーワードベース事前蓄積方式）の場合は、ステップ5に進む。キャッシュ方式がそれ以外の場合は、第1の実施形態における図３のシーケンスのステップ4以降の動作に遷移する。

ステップ5では、メタデータ収集速度決定部１４において、メタデータの収集速度を決定する（Ｓ１４０５）。

ステップ6では、キーワード・ジャンル登録情報蓄積部１２１から登録されているサービス毎のジャンル、キーワードを取得する。ここで、ジャンルが設定不可のサービスの場合は、キーワード・ジャンル変換情報蓄積部１２２からジャンル・キーワード変換情報を取得し、該ジャンルをキーワードに変換する。（S１４０６）
ステップ７では、キャッシュ管理部１１８はメタデータ取得・更新要求部１７に対して、ステップ5で決定したメタデータ収集速度と、収集メタデータ数、サービス情報（例えばメタデータ取得用の開始条件、検索条件、終了条件など）及び、ステップ６で取得したキーワード、ジャンルとを送信する。メタデータ取得・更新要求部１７は、それらの情報をもとに、メタデータ提供装置１０２ｎからメタデータを収集する（Ｓ１４０７）。収集メタデータ数は、サービス・メタデータ情報蓄積部１１９に蓄積されているキーワード毎のキャッシュ上限件数である。なお、ステップ6で取得したキーワード、ジャンルの個数が多い場合は、ハードディスク容量等に応じて、収集すべきメタデータ数を計算し、計算したメタデータ数のメタデータのみを収集するようにしてもよい。

ステップ８では、キャッシュ更新頻度・時間決定部１１６において、推奨更新頻度、推奨更新時間を決定し、サービス・メタデータ情報蓄積部１１９に登録する（Ｓ１４０８）。

ステップ９では、キャッシュ管理部１１８において、推奨更新頻度および推奨更新時間を基にキャッシュ次更新日時を決定し、サービス・メタデータ情報蓄積部１１９に登録する（Ｓ１４０９）。その後、本シーケンスを終了する。

以上のように、本発明の実施形態によれば以下の効果を得ることができる。

（１）サービス毎に、そのサービスに適したメタデータのキャッシュ方式を選択することで、効率的なメタデータのキャッシュが可能となる。

（２）キャッシュされたメタデータの効率的な更新が可能となる。例えば需要の高いコンテンツのメタデータは概ね最新の状態に保ち、需要の低いコンテンツのメタデータについては無意味な更新を防ぐことが可能となる。

（３）メタデータ収集による受信端末の他アプリケーションへの影響を最小限に抑えることが可能となる。また、ネットワーク負荷やメタサーバ負荷を考慮したメタデータ収集速度を設定することで、外乱による影響を最小限に抑えることが可能となる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１〜３・・・ネットワーク
１０１・・・メタデータ収集装置
１０２ａ〜１０２ｅ・・・メタデータ提供装置
１１・・・ユーザインターフェース部
１２・・・メタデータ形式統一部
１３・・・負荷監視部
１４・・・メタデータ収集速度決定部
１５、１１５・・・キャッシュ方式決定部
１６、１１６・・・キャッシュ更新頻度・時間決定部
１７・・・メタデータ取得・更新要求部
１８、１１８・・・キャッシュ管理部
１９、１１９・・・サービス・メタデータ情報蓄積部
２０・・・ネットワークインターフェース
１２１・・・ジャンル・キーワード登録情報蓄積部
２２・・・ジャンル・キーワード変換情報蓄積部

Claims (10)

1. コンテンツ配信サービスから配信されるコンテンツとそのメタデータを保有するメタデータ提供装置から前記メタデータを取得し蓄積するメタデータ収集装置であって、
   前記メタデータを記憶する複数の蓄積方式の中から前記コンテンツ配信サービス毎の蓄積方式を決定し、前記蓄積方式は、検索条件により検索された前記メタデータを蓄積する検索ベース蓄積方式と、前記サービスが保有する前記メタデータの少なくとも一部を予め蓄積する事前蓄積方式とを含む、蓄積方式決定部と、
   前記メタデータの取得を開始する開始条件と、前記蓄積方式決定部により決定された蓄積方式に対応し、かつ、取得する前記メタデータを選択するための検索条件と、前記メタデータの取得を終了する終了条件とから決定され、前記蓄積方式と関連する蓄積方式情報を前記蓄積方式毎に記憶する記憶部と、
   前記コンテンツ配信サービス毎の前記蓄積方式に従って対応する前記メタデータを取得する取得部と、
   取得した前記メタデータを記憶する蓄積部と、
   を備えることを特徴とするメタデータ収集装置。
2. 前記検索条件は、特定のサービスが有するすべてのメタデータを示す識別情報、またはあらかじめ定めた検索式のいずれかであり、
   前記取得部は、前記検索条件が前記識別情報である場合には前記特定のサービスの前記メタデータをすべて取得し、前記検索条件が前記検索式である場合には前記検索式に合致する前記メタデータを取得する
   ことを特徴とする請求項１に記載のメタデータ収集装置。
3. 前記開始条件は、定期的にメタデータを取得するように定められる時刻、またはユーザからの前記メタデータの取得要求のいずれかであり、
   前記取得部は、前記開始条件が前記時刻である場合には前記時刻に到達したときに前記メタデータの取得を開始し、前記開始条件が前記取得要求である場合には前記取得要求が通知されたときに前記メタデータの取得を開始する
   ことを特徴とする請求項２に記載のメタデータ収集装置。
4. 前記終了条件は、あらかじめ定めた閾値、または特定のサービスが有するすべてのメタデータを示す識別情報のいずれかであり、
   前記取得部は、前記終了条件が前記閾値である場合には取得した前記メタデータの数が前記閾値と一致したときに前記メタデータの取得を終了し、前記終了条件が前記識別情報である場合には前記特定のサービスの前記メタデータをすべて取得したときに前記メタデータの取得を終了する
   ことを特徴とする請求項３に記載のメタデータ収集装置。
5. 前記記憶部は、前記蓄積部に蓄積されている前記メタデータの更新条件を前記サービス毎にさらに記憶し、
   前記取得部は、前記サービス毎に、前記蓄積部に蓄積されている前記メタデータのうち前記更新条件に合致する前記メタデータのすべて、または前記蓄積部に蓄積されている前記メタデータとネットワークが有する前記メタデータとの差分を取得する
   ことを特徴とする請求項４に記載のメタデータ収集装置。
6. 前記更新条件は、特定のサービスが有するすべてのメタデータを示す識別情報、またはあらかじめ定めた検索式のいずれかであり、
   前記取得部は、前記検索条件が前記識別情報である場合には前記特定のサービスの前記メタデータをすべて取得し、前記検索条件が前記検索式である場合には前記検索式に合致する前記メタデータを取得する
   ことを特徴とする請求項５に記載のメタデータ収集装置。
7. 前記更新条件には、更新頻度または更新時間帯をさらに含み、
   前記取得部は、少なくとも前記更新頻度または前記更新時間帯に従って前記メタデータを取得することを特徴とする請求項６に記載のメタデータ収集装置。
8. 前記蓄積方式決定部は、ネットワークの種類または品質の少なくともいずれか、もしくは前記サービスの種類または特徴の少なくと
   もいずれかに基づいて、前記蓄積方式を決定することを特徴とする請求項１に記載のメタデータ収集装置。
9. コンテンツ配信サービスから配信されるコンテンツとそのメタデータを保有するメタデータ提供装置から前記メタデータを取得し蓄積するメタデータ収集方法であって、
   検索条件により検索された前記メタデータを蓄積する検索ベース蓄積方式と前記サービスが保有する前記メタデータの少なくとも一部を予め蓄積する事前蓄積方式を含み、かつ、前記コンテンツ配信サービス毎の、蓄積方式情報を決定し、
   前記メタデータの取得を開始する開始条件と、決定された前記蓄積方式に対応し、かつ取得する前記メタデータを選択するための検索条件と、前記メタデータの取得を終了する終了条件とから決定され、前記蓄積方式に関連する蓄積方式情報を前記蓄積方式毎に記憶し、
   前記コンテンツ配信サービス毎の前記蓄積方式に従って対応する前記メタデータを取得し、
   取得した前記メタデータを記憶する
   を備えることを特徴とするメタデータ収集方法。
10. コンテンツ配信サービスにより配信されるコンテンツとそのメタデータを保有するメタデータ提供装置と、前記メタデータ提供装置から前記メタデータを取得し蓄積するメタデータ収集装置と備えたメタデータ提供・収集システムであって、
    前記メタデータ収集装置側において、
    検索条件により検索された前記メタデータを蓄積する検索ベース蓄積方式と前記サービスが保有する前記メタデータの少なくとも一部を予め蓄積する事前蓄積方式を含み、かつ、前記コンテンツ配信サービス毎の、蓄積方式情報を決定する蓄積方式決定部と、
    前記メタデータの取得を開始する開始条件と、前記蓄積方式決定部により決定された蓄積方式に対応し、かつ、取得する前記メタデータを選択するための検索条件と、前記メタデータの取得を終了する終了条件とから決定され、前記蓄積方式と関連する蓄積方式情報を前記蓄積方式毎に記憶する記憶部と、
    前記コンテンツ配信サービス毎の前記蓄積方式情報に従って対応する前記メタデータを取得する取得要求部と、を有し、
    前記メタデータ供給側において、
    前記メタデータ収集装置側の前記取得要求部から要求されたメタデータを供給する供給部を有し、
    前記供給部により供給されたメタデータを、前記メタデータ収集装置側で取得し、前記メタデータ収集装置側の蓄積部に記憶することを特徴とするメタデータ提供・収集システム。

Images