JP2010079641A - メタデータ収集装置、ならびにその方法およびプログラム - Google Patents

Abstract

【課題】コンテンツ配信サービス別にコンテンツのメタデータを効率的に収集および蓄積する。
【解決手段】本発明の装置は、サービス毎にメタデータの蓄積方式を決定する手段と、事前蓄積方式が決定された第１のサービスについては事前にメタデータを取得し第１の記憶手段に記憶する手段と、コンテンツの検索条件と検索対象サービスとを指定する検索指定手段と、前記事前蓄積方式が指定されたとき指定内容に合致するメタデータを第１の記憶手段から検索し取得する手段と、前記検索ベース蓄積方式が指定されたとき指定内容に合致するメタデータを前記第２のメタデータ記憶手段から取得しそのようなメタデータが登録されていないときは指定内容に合致するメタデータを取得し前記第２の記憶手段に検索条件と検索対象サービスと関連づけて蓄積する手段と、取得された前記メタデータを表示する手段とを備える。
【選択図】図２

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ネットワークである場合である。このように物理的もしくは論理的に異なるネットワークは、別々のネットワークとして扱う。

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

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

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

［ユーザインターフェース部１１］
ユーザインターフェース部１１は、ユーザが所望のコンテンツを検索する際にコンテンツの検索条件および検索対象サービスを入力するための入力インターフェース、ならびに検索結果としてのコンテンツリスト（タイトル等のリスト）を表示する出力インターフェースを提供する。図10にコンテンツの検索条件および検索対象サービスを入力するコンテンツ検索画面の例を、図11に検索されたコンテンツのリストを含む検索結果表示画面の例を示す。ユーザインターフェース部１１は、本発明の、検索条件および検索対象サービスを入力する検索入力手段、および検索条件および検索対象サービスに応じて取得されたメタデータを表す検索結果を表示する検索結果表示手段を含んでいる。

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

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

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

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

メタデータ収集速度決定部１４は、以下の指標を基に、メタデータ収集速度を決定する。
（１）自端末のCPU負荷、他のアプリケーションの起動状況
（２）ネットワーク負荷
（３）サーバ負荷

これらの各種負荷に応じて、メタデータ収集速度をどのようにして決定するかを以下に示す。

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

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

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

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

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

［サービス・メタデータ情報蓄積部１９］
サービス・メタデータ情報蓄積部１９は、メタデータ提供装置１０２ａ〜１０２ｅから取得したメタデータを蓄積する。

またサービス・メタデータ情報蓄積部１９は、図8 および図9 に示すようなサービス毎に設定されたサービス情報を蓄積する。サービス・メタデータ情報蓄積部１９はたとえば、ハードディスクや不揮発性メモリにより構成される。

図8 および図9 に示されるサービス情報は以下の項目を含む。
・ 対応サービス数
・ 対応サービス名
・ キャッシュ方式
・ キャッシュ上限件数
・ メタデータ取得用情報
・ 登録クエリ数
・ 登録クエリ
・ 検索回数
・ 視聴回数
・ 推奨更新頻度（キャッシュ更新頻度）
・ 推奨更新時間（キャッシュ更新時間）
・ キャッシュ次更新日時
・ キャッシュ有効期間
・ キャッシュ削除日時

「対応サービス数」は、登録されたサービスの数を表しており、図８および図９の例では５つのサービスが登録されている。これら５つのサービスのうちの１つである映像投稿サービスが図８に、別の１つである高品質VoDサービスが図９に示されている。

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

「キャッシュ方式」は、後述するキャッシュ方式決定部（蓄積方式決定手段）１５において決定したキャッシュ方式（蓄積方式）を表す。キャッシュ方式には、Query-based Caching Method（クエリベースキャッシュ方式）と、All Caching Method（全キャッシュ方式）とがある。簡単には、All Caching Method（全キャッシュ方式）は、サービスが保有（提供）しているメタデータを予めすべてキャッシュする方式、Query-based Caching Method（クエリベースキャッシュ方式）は、検索が行われるごとに、検索された検索条件（検索式）について、上位数件のみまたはすべてをキャッシュする方式である。Query-based Caching Method（クエリベースキャッシュ方式）は、本発明の検索ベース蓄積方式に対応し、All Caching Method（全キャッシュ方式）は本発明の事前蓄積方式に対応する。これらのキャッシュ方式の詳細については後述する。サービス・メタデータ情報蓄積部１９においてキャッシュ方式を記憶する部分は、本発明の蓄積方式記憶手段に相当する。

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

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

「登録クエリ」は、過去に検索した検索条件である。ただし後述するように、キャッシュ方式がQuery-based 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（全キャッシュ方式）
本方式は、サービスが保有（提供）しているメタデータを予めすべてキャッシュする方式である。すべてのメタデータのキャッシュが完了すると、以後は差分のみを定期的に更新する。メタデータ更新はサービス・メタデータ情報蓄積部１９で管理されているキャッシュ次更新日時に基づいて行われる。All Caching Method（全キャッシュ方式）は本発明の事前蓄積方式に対応する。

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

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

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

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

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

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

（Ｃ）Auto
サービス毎のキャッシュ方式について自動的に判断する。判断は以下のいずれかの判断基準に基づく。ただこれに限ったものではなく、キャッシュ方式を判断できる限り、どのような判断基準を用いてもよい。
・ サービスから総保有コンテンツ数（メタデータの総数）を取得可能であり、かつ、総コンテンツ数（総メタデータ数）がある閾値以下である場合は全キャッシュ方式を決定し、それ以外はクエリベースキャッシュ方式を決定する。上記ある閾値は、定量であってもいいし、ハードディスクの容量を基に決めてもいい。
・ サービス毎ではなく、ネットワーク単位でネットワークの種類または品質に応じてキャッシュ方式を判断する。たとえば、ホームネットワークや品質管理されたネットワーク上のメタデータ提供装置により提供されるサービスに対しては全キャッシュ方式を決定し、The Internet上のメタデータ提供装置により提供されるサービスに対してはクエリベースキャッシュ方式を決定する。また、DLNA（Digital Living Network Alliance）でコンテンツが配信されるネットワークでは全キャッシュ方式を決定し、それ以外のネットワークについてはクエリベースキャッシュ方式を決定する。
・ サービスの種類によりキャッシュ方式を判断する。たとえば、有料サービスは全キャッシュ方式を決定し、無料サービスはクエリベースキャッシュ方式を決定する。
・ メタデータの更新頻度によりキャッシュ方式を判断する。メタデータの更新頻度は、メタデータの総数にも密に連携するため、メタデータの更新頻度が少ないサービスはコンテンツ総数も少ないと見なす。たとえば、更新頻度が少ないサービスでは、キャッシュの更新があまりないので全キャッシュ方式を決定し、キャッシュの更新が頻繁であるサービスに関しては、クエリベースキャッシュ方式を決定する。

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

キャッシュ更新単位はキャッシュ方式により異なり、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件と変更された場合はその取得速度に応じてメタデータを取得する。以上の動作を繰り返し行うことで、メタデータ取得総数までメタデータを取得する。

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

キャッシュ管理部１８は、全キャッシュ方式が登録されたサービスについては、初回のみ以下の処理を行う。すなわちキャッシュ管理部１８は、該サービスに関連するメタデータ提供装置から、当該メタデータ提供装置が保有するすべてのメタデータを取得し、該サービスに関連づけてサービス・メタデータ情報蓄積部１９に記憶する。この処理は、本発明のメタデータ取得処理手段の処理に相当し、キャッシュ管理部１８はメタデータ取得処理手段を含む。

メタデータの取得要求の際は、メタデータ収集速度決定部１４からメタデータ収集速度を取得してメタデータ取得・更新要求部１７に検索対象サービスとともに指定する。

また、キャッシュ管理部１８は、ユーザインターフェース部１１から検索クエリ（検索条件と検索対象サービスとを指定したクエリ）があった場合は、検索対象サービスのキャッシュ方式を判定する。

全キャッシュ方式の場合は、検索対象サービスについてあらかじめ取得してあるメタデータにおいて、検索条件に合致するメタデータを検索し、発見したメタデータを、ユーザインターフェース部１１を介して表示する。これは本発明の第１の検索処理手段の処理に相当する。

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

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

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

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

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

また、キャッシュ管理部１８は、サービス・メタデータ情報蓄積部１９に管理されているサービス情報を定期的に監視し、キャッシュの更新・削除を行う。つまり、キャッシュ管理部１８は、キャッシュ次更新日時（更新条件）およびキャッシュ削除日時を確認し、キャッシュ削除日時が経過したときはキャッシュを削除し、キャッシュ更新日時が経過したときは（更新条件が成立したときは）メタデータの更新処理を行う。ただし、キャッシュの削除は、クエリベースキャッシュ方式の場合にのみ行う。キャッシュ管理部１８は、全キャッシュ方式のサービスについての更新条件の成立の有無を判定する第１の更新条件判定手段と、更新条件の成立したサービスについてメタデータを更新する第１の更新処理手段とを備えている。またキャッシュ管理部１８は、クエリベースキャッシュ方式のサービスについて登録クエリ毎に更新条件の成立の有無を判定する第２の更新条件判定手段と、更新条件が成立した、サービスおよび登録クエリの組についてメタデータを更新する第２の更新処理手段とを備えている。

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

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

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

ステップ１では、メタデータ収集装置１０１の起動を行う。つまり、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では、キャッシュ管理部１８において、推奨更新頻度および推奨更新時間を基にキャッシュ次更新日時を決定し、サービス・メタデータ情報蓄積部１９に登録し（Ｓ１０８）、本シーケンスを終了する。

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

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

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

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

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

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

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

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

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

（キャッシュの更新タイミング）
図５はキャッシュの更新タイミングにおける動作シーケンスを説明するフローチャートである。

ステップ1では、着目するサービスにおいて、サービス・メタデータ情報蓄積部１９に登録されているキャッシュ更新日時を確認する（Ｓ３０１）。着目するサービスのキャッシュ方式がQuery-based Caching Method（クエリベースキャッシュ方式）の場合は登録クエリ毎に更新日時を確認し、All Caching Method（全キャッシュ方式）の場合は１つのみ登録されている更新日時を確認する。

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

ステップ3では、メタデータ取得・更新要求部１７において、更新単位（クエリベースキャッシュ方式の場合は登録クエリまたは全キャッシュ方式の場合はサービス）毎にメタデータの更新があるかどうかをメタデータ提供装置に対して確認する（Ｓ３０３）。メタデータの更新がある場合はステップ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では、図10に示すような検索画面においてコンテンツの検索条件と、検索対象サービスとを指定する（Ｓ５０１）。図10の例では検索条件として、ジャンルがスポーツ、キーワードがテニスとして指定され、また、検索対象サービスとして高品質VoDサービスと映像投稿サービスとが指定されている。検索条件としては、ジャンル、キーワードの他に、お勧めコンテンツや新着コンテンツといったプロモーション情報などであってもよい。検索条件と検索対象サービスとを指定した検索クエリがユーザインターフェース部１１からキャッシュ管理部１８に送られる。

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

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

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

ステップ4では、キャッシュ管理部１８はメタデータ取得・更新要求部１７に対して、ステップ3で決定したメタデータ収集速度と、さらに収集メタデータ数（上位件数）、サービス情報（たとえばメタデータ取得用情報）とを送信し、メタデータ取得・更新要求部１７はそれらの情報をもとに、メタデータ提供装置からメタデータの収集を行う（Ｓ５０４）。

ここでメタデータの取得に際して、検索結果をなるべく早く提示するという観点から、上記収集メタデータ数のメタデータをすべて取得した後に次のステップ5に移動するのではなく、必要最低限数のメタデータを取得した時点でステップ5に移動してもよい。たとえば、図11のように１画面に表示可能なメタデータ数が5件で、キャッシュ管理部１８から要求された収集メタデータ数が500件の場合は、画面の遷移も考慮して20件取得したら、ステップ5に進み、残りのメタデータ480件（=500-20）は、検索結果を表示した後に順次取得してもよい。

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

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

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

以上のように、本発明の実施形態によれば以下の効果を得ることができる。
（１）サービス毎にそのサービスに適したメタデータのキャッシュ方式を選択することで、効率的なメタデータのキャッシュが可能となる。
（２）キャッシュされたメタデータの効率的な更新が可能となる。たとえば需要の高いコンテンツのメタデータは概ね最新の状態に保ち、需要の低いコンテンツのメタデータについては無意味な更新を防ぐことが可能となる。
（３）メタデータ収集による受信端末の他アプリケーションへの影響を最小限に抑えることが可能となる。また、ネットワーク負荷やメタサーバ負荷を考慮したメタデータ収集速度を設定することで、外乱による影響を最小限に抑えることが可能となる。

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

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

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

符号の説明

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

Claims (11)

1. １つ以上のコンテンツ配信サービスのそれぞれにより配信されるコンテンツのメタデータを保有する１つ以上のメタデータ提供装置からネットワークを介してメタデータを収集し蓄積するメタデータ収集装置であって、
   前記コンテンツ配信サービス毎にメタデータの蓄積方式を決定する蓄積方式決定手段と、
   前記コンテンツ配信サービス毎に決定された蓄積方式を記憶する蓄積方式記憶手段と、
   前記メタデータの蓄積方式としてメタデータを事前に蓄積する事前蓄積方式が決定された第１のコンテンツ配信サービスに関連するメタデータ提供装置に対して前記メタデータ提供装置が保有するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返される前記メタデータを取得するメタデータ取得処理手段と、
   前記メタデータ取得処理手段により取得されたメタデータを、前記第１のコンテンツ配信サービスに関連づけて記憶する第１のメタデータ記憶手段と、
   検索対象となるコンテンツ配信サービスである検索対象サービスと、コンテンツの検索条件とを入力する検索入力手段と、
   前記メタデータの蓄積方式として過去に検索された検索条件に対応するメタデータのみを蓄積する検索ベース蓄積方式が決定された第２のコンテンツ配信サービスについて、前記第２のコンテンツ配信サービスと、過去に検索された検索条件と、メタデータとを関連づけて記憶した第２のメタデータ記憶手段と、
   前記検索対象サービスの蓄積方式が前記事前蓄積方式のときは、前記第１のメタデータ記憶手段において前記検索対象サービスに関連するメタデータにおいて前記入力された検索条件に合致するメタデータを検索する第１の検索処理手段と、
   前記検索対象サービスの蓄積方式が前記検索ベース蓄積方式であるとき、前記検索対象サービスと前記入力された検索条件との組が前記第２のメタデータ記憶手段に登録されているか否かを判定し、
   登録されているときは、前記検索対象サービスと前記入力された検索条件との組に対応するメタデータを前記第２のメタデータ記憶手段から取得し、
   登録されていないときは、前記検索対象サービスに関連するメタデータ提供装置に対し当該メタデータ提供装置が保有するメタデータのうち前記入力された検索条件に合致するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返されるメタデータを取得し、取得したメタデータと前記入力された検索条件とを前記検索対象サービスに関連づけて前記第２のメタデータ記憶手段に蓄積する、
   第２の検索処理手段と、
   前記１または第２の検索処理手段により取得された前記メタデータを表示する検索結果表示手段と、
   を備えたメタデータ収集装置。
2. 前記第１のコンテンツ配信サービス毎にメタデータの更新条件を記憶した第１の更新条件記憶手段と、
   前記第１の更新条件記憶手段における各前記更新条件の成立の有無を判定し、前記更新条件が成立した第１のコンテンツ配信サービスを特定する第１の更新条件判定手段と、
   前記特定された第１のコンテンツ配信サービスに関連するメタデータ提供装置が保有するメタデータの取得要求、または前記特定された第１のコンテンツ配信サービスに関連するメタデータ提供装置が保有するメタデータと前記第１のメタデータ記憶手段において前記特定された第１のコンテンツ配信サービスに関連するメタデータとの差分の取得要求を、当該メタデータ提供装置に送信し、前記取得要求に応答して当該メタデータ提供装置から返されるメタデータに基づき前記特定された第１のコンテンツ配信サービスに従って前記第１のメタデータ記憶手段の内容を更新する第１の更新処理手段と、
   を備えた請求項１に記載のメタデータ収集装置。
3. 前記第２のメタデータ記憶手段における前記第２のコンテンツ配信サービス毎かつ前記検索条件毎にメタデータの更新条件を記憶した第２の更新条件記憶手段と、
   前記第２の更新条件記憶手段における各前記更新条件の成立の有無を判定し、前記更新条件が成立した第２のコンテンツ配信サービスおよび検索条件の組を特定する第２の更新条件判定手段と、
   前記特定された第２のコンテンツ配信サービスに関連するメタデータ提供装置が保有するメタデータのうち前記特定された検索条件に合致するメタデータの取得要求、または前記特定された第２のコンテンツ配信サービスに関連するメタデータ提供装置が保有するメタデータと前記第２のメタデータ記憶手段において前記特定された組に対応するメタデータとの差分の取得要求を、前記特定された第２のコンテンツ配信サービスに対応するメタデータ提供装置に送信し、前記取得要求に応じて当該メタデータ提供装置から返されるメタデータに基づいて前記特定された第２のコンテンツ配信サービスと前記特定した検索条件に従って前記第２のメタデータ記憶手段の内容を更新する第２の更新処理手段とを備えたことを特徴とする請求項１または２に記載のメタデータ収集装置。
4. 各前記更新条件は、前記メタデータの更新頻度または更新時間帯またはこれらの両方を定めたことを特徴とする請求項２または３に記載のメタデータ収集装置。
5. 前記蓄積方式決定手段は、前記１つ以上のコンテンツ配信サービスのそれぞれに対する蓄積方式を、前記１つ以上のコンテンツ配信サービスのそれぞれに対応する前記メタデータ提供装置が接続されているネットワークの種類または品質
   、あるいは前記１つ以上のコンテンツのそれぞれの種類または特徴に基づいて決定することを特徴とする請求項１ないし４のいずれか一項に記載のメタデータ収集装置。
6. 前記蓄積方式決定手段は、各前記メタデータ提供装置が保有しているメタデータの個数情報を各前記メタデータ提供装置から取得し、保有しているメタデータの個数が閾値未満のメタデータ提供装置に関連する前記コンテンツ配信サービスについては前記事前蓄積方式を決定し、保有しているメタデータの個数が閾値以上のメタデータ提供装置については前記検索ベース蓄積方式を決定することを特徴とする請求項１ないし４のいずれか一項に記載のメタデータ収集装置。
7. 前記１つ以上のメタデータ提供装置はそれぞれ、保有するメタデータをある更新頻度で更新し、
   前記蓄積方式決定手段は、メタデータの更新頻度が閾値未満のメタデータ提供装置に対応するコンテンツ配信サービスについては前記事前蓄積方式を決定し、前記閾値以上のメタデータ提供装置に対応するコンテンツ配信サービスについては前記検索ベース蓄積方式を決定することを特徴とする請求項１ないし４のいずれか一項に記載のメタデータ収集装置。
8. 前記第２の検索処理手段により前記メタデータ提供装置から取得されたメタデータに対する有効期間を設定する有効期間設定手段と、
   設定した有効期間を、前記検索対象サービスおよび前記入力された検索条件と関連づけて記憶する有効期間記憶手段と、
   前記有効期間が経過した、コンテンツ配信サービスと検索条件との組に対応するメタデータを前記第２のメタデータ記憶手段から削除する削除手段と
   をさらに備えたことを特徴とする請求項１ないし７のいずれか一項に記載のメタデータ収集装置。
9. 前記有効期間設定手段は、前記メタデータに対応するコンテンツの視聴回数または検索回数に応じて前記有効期間を設定することを特徴とする請求項８に記載のメタデータ収集装置。
10. １つ以上のコンテンツ配信サービスのそれぞれにより配信されるコンテンツのメタデータを保有する１つ以上のメタデータ提供装置からネットワークを介してメタデータを収集し蓄積するコンピュータにおいて実行するメタデータ収集方法であって、
    前記コンテンツ配信サービス毎にメタデータの蓄積方式を決定する蓄積方式決定ステップと、
    前記コンテンツ配信サービス毎に決定された蓄積方式を記憶する蓄積方式記憶ステップと、
    前記メタデータの蓄積方式としてメタデータを事前に蓄積する事前蓄積方式が決定された第１のコンテンツ配信サービスに関連するメタデータ提供装置に対して前記メタデータ提供装置が保有するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返される前記メタデータを取得するメタデータ取得処理ステップと、
    前記メタデータ取得処理ステップにより取得されたメタデータを、前記第１のコンテンツ配信サービスに関連づけて第１のメタデータ記憶手段に記憶するステップと、
    検索対象となるコンテンツ配信サービスである検索対象サービスと コンテンツの検索条件とを入力する検索入力ステップと、
    前記メタデータの蓄積方式として過去に検索された検索条件に対応するメタデータのみを蓄積する検索ベース蓄積方式が決定された第２のコンテンツ配信サービスについて、前記第２のコンテンツ配信サービスと、過去に検索された検索条件と、メタデータとを関連づけて記憶した第２のメタデータ記憶手段にアクセスするステップと、
    前記検索対象サービスの蓄積方式が前記事前蓄積方式のときは、前記第１のメタデータ記憶手段において前記検索対象サービスに関連するメタデータにおいて前記入力された検索条件に合致するメタデータを検索する第１の検索処理ステップと、
    前記検索対象サービスの蓄積方式が前記検索ベース蓄積方式であるとき、前記検索対象サービスと前記入力された検索条件との組が前記第２のメタデータ記憶手段に登録されているか否かを判定し、
    登録されているときは、前記検索対象サービスと前記入力された検索条件との組に対応するメタデータを前記第２のメタデータ記憶手段から取得し、
    登録されていないときは、前記検索対象サービスに関連するメタデータ提供装置が保有するメタデータのうち前記入力された検索条件に合致するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返されるメタデータを取得し、取得したメタデータと前記入力された検索条件とを前記検索対象サービスに関連づけて前記第２のメタデータ記憶手段に蓄積する、
    第２の検索処理ステップと、
    前記１または第２の検索処理ステップにより取得された前記メタデータを表示する検索結果表示ステップと
    を備えたメタデータ収集方法。
11. １つ以上のコンテンツ配信サービスのそれぞれにより配信されるコンテンツのメタデータを保有する１つ以上のメタデータ提供装置からネットワークを介してメタデータを収集し蓄積するコンピュータにおいて実行するメタデータ収集プログラムであって、
    前記コンテンツ配信サービス毎にメタデータの蓄積方式を決定する蓄積方式決定ステップと、
    前記コンテンツ配信サービス毎に決定された蓄積方式を記憶する蓄積方式記憶ステップと、
    前記メタデータの蓄積方式としてメタデータを事前に蓄積する事前蓄積方式が決定された第１のコンテンツ配信サービスに関連するメタデータ提供装置に対して前記メタデータ提供装置が保有するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返される前記メタデータを取得するメタデータ取得処理ステップと、
    前記メタデータ取得処理ステップにより取得されたメタデータを、前記第１のコンテンツ配信サービスに関連づけて第１のメタデータ記憶手段に記憶するステップと、
    検索対象となるコンテンツ配信サービスである検索対象サービスと コンテンツの検索条件とを入力する検索入力ステップと、
    前記メタデータの蓄積方式として過去に検索された検索条件に対応するメタデータのみを蓄積する検索ベース蓄積方式が決定された第２のコンテンツ配信サービスについて、前記第２のコンテンツ配信サービスと、過去に検索された検索条件と、メタデータとを関連づけて記憶した第２のメタデータ記憶手段にアクセスするステップと、
    前記検索対象サービスの蓄積方式が前記事前蓄積方式のときは、前記第１のメタデータ記憶手段において前記検索対象サービスに関連するメタデータにおいて前記入力された検索条件に合致するメタデータを検索する第１の検索処理ステップと、
    前記検索対象サービスの蓄積方式が前記検索ベース蓄積方式であるとき、前記検索対象サービスと前記入力された検索条件との組が前記第２のメタデータ記憶手段に登録されているか否かを判定し、
    登録されているときは、前記検索対象サービスと前記入力された検索条件との組に対応するメタデータを前記第２のメタデータ記憶手段から取得し、
    登録されていないときは、前記検索対象サービスに関連するメタデータ提供装置が保有するメタデータのうち前記入力された検索条件に合致するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返されるメタデータを取得し、取得したメタデータと前記入力された検索条件とを前記検索対象サービスに関連づけて前記第２のメタデータ記憶手段に蓄積する、
    第２の検索処理ステップと、
    前記１または第２の検索処理ステップにより取得された前記メタデータを表示する検索結果表示ステップと
    を前記コンピュータに実行させるためのメタデータ収集プログラム。

Images