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

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

Info

Publication number
JP5238432B2
JP5238432B2 JP2008247924A JP2008247924A JP5238432B2 JP 5238432 B2 JP5238432 B2 JP 5238432B2 JP 2008247924 A JP2008247924 A JP 2008247924A JP 2008247924 A JP2008247924 A JP 2008247924A JP 5238432 B2 JP5238432 B2 JP 5238432B2
Authority
JP
Japan
Prior art keywords
metadata
search
service
content distribution
providing apparatus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008247924A
Other languages
English (en)
Other versions
JP2010079641A (ja
Inventor
江 祐 司 入
大 介 安次富
坂 直 紀 江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2008247924A priority Critical patent/JP5238432B2/ja
Priority to US12/561,803 priority patent/US8219556B2/en
Publication of JP2010079641A publication Critical patent/JP2010079641A/ja
Application granted granted Critical
Publication of JP5238432B2 publication Critical patent/JP5238432B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/48Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually

Description

本発明は、たとえばコンテンツのメタデータを効率的に収集して蓄積し、また蓄積(キャッシュ)したメタデータを効率的に更新するメタデータ収集装置ならびにその方法およびプログラムに関する。
近年、ブロードバンドの普及を背景として、IP(Internet Protocol)通信を利用したマルチメディアコンテンツ配信サービスが、様々な通信・サービス事業者によって運営されている。携帯用の低解像度の映像配信サービスからデジタルテレビ用のHD ( High Definition ) 品質の高解像度な映像配信サービスまで多種多様なサービスが提供されている。
マルチメディアコンテンツ配信サービスの一つとして、ユニキャストで映像配信するVoD ( Video On Demand ) 映像配信サービスがある。本サービスは、コンテンツの検索・選択のナビゲーションとして、ポータルサービスを利用するものとECG ( Electronic Content Guide )を利用するものとに大別できる。
ポータルサービスとはサービス事業者が提供するWEBブラウザにおいて、ナビゲーションを行うものであり、ユーザは各サービス事業者が提供しているポータルと呼ばれるWEBページにアクセスし、そこからユーザは所望のコンテンツを検索・選択し、映像ストリームを受信するというものである。ポータルサービスではコンテンツ検索等をすべてサーバ上で行い、その結果をユーザにWEBページ上でユーザに提示する。
一方、ECGは受信装置上のアプリケーションであり、メタデータと呼ばれる番組情報を取得し、ある数多のメタデータの中から所望のものを選択して、検索、表示、選択、視聴、購入のためのインターフェースをユーザに提供する。ECGを利用したサービスは、ナビゲーションに必要な核となるメタデータを予め受信装置上に蓄積して利用する形態をとる。このためECGを利用したサービスは、画像情報を含めたサイトの画面構成情報も取得しなければならないポータルサービスと比較して、高速に動作するという利点を持つ。その他、ECGを利用したサービスは、画面デザインを受信機側が決定できる、ブラウザでは実現できない受信機リモコンを利用した操作や画面遷移が可能となる、等の利点もある。さらには、ECGを利用したサービスでは、複数のサービスからメタデータを収集し、それらのメタデータをマージし、ユーザに提示することにより、マルチサービスナビゲーションの実現が可能である。このマルチサービスナビゲーションを実現する公知例として特許文献1に開示されたものがある。
特許文献1では、複数のメタデータ提供装置からのメタデータをメタデータ収集装置が予め収集及びキャッシュしておき、受信装置がメタデータ収集装置に対しメタデータ取得要求を行った際は、これらのメタデータ提供装置が保有するメタデータが統一的な形式で、受信装置に返却される。
特許文献1では、受信装置が要求したメタデータの更新が必要な場合、つまり、キャッシュしているメタデータとメタデータ提供装置で保持しているメタデータに齟齬がある場合、再度メタデータをメタデータ提供装置から取得する必要がある。そのため、頻繁にメタデータが更新されるサービスにおいては、キャッシュにヒットする確率が低くなり、再度メタデータ提供装置からメタデータを収集する必要が生じ、受信装置でのコンテンツ表示までに時間を要することになる問題がある。
また、特許文献1では、メタデータ収集装置をサーバサイドに配置する形態を想定しているため、宅内のHDDレコーダに蓄積されたコンテンツを検索対象とすることができない。さらには、メタデータ収集装置からすべてのメタデータを取得するため、ハードディスク、メモリの容量などに大きな制約のあるデジタルテレビなどのコンシューマ機器に適応できない。
特開2004−102767号公報
上述したように、サービスが提供するコンテンツ数が非常に多い場合には、すべてキャッシュすることはハードディスク、メモリの容量などに大きな制約のあるデジタルテレビなどのコンシューマ機器に適用することは困難である。また、コンテンツの更新が頻繁に行われるようなサービスでは、キャッシュのヒット率が低くなることで、メタデータ提供装置からメタデータを再取得する必要が発生し軽快な操作感が損なわれるという課題もある。
本発明は、コンテンツ配信サービス別にコンテンツのメタデータを効率的に収集および蓄積できるようにしたメタデータ収集装置ならびにその方法及びプログラムを提供する。
本発明の一態様としてのメタデータ収集装置は、1つ以上のコンテンツ配信サービスのそれぞれにより配信されるコンテンツのメタデータを保有する1つ以上のメタデータ提供装置からネットワークを介してメタデータを収集し蓄積するメタデータ収集装置であって、前記コンテンツ配信サービス毎にメタデータの蓄積方式を決定する蓄積方式決定手段と、前記コンテンツ配信サービス毎に決定された蓄積方式を記憶する蓄積方式記憶手段と、前記メタデータの蓄積方式としてメタデータを事前に蓄積する事前蓄積方式が決定された第1のコンテンツ配信サービスに関連するメタデータ提供装置に対して前記メタデータ提供装置が保有するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返される前記メタデータを取得するメタデータ取得処理手段と、前記メタデータ取得処理手段により取得されたメタデータを、前記第1のコンテンツ配信サービスに関連づけて記憶する第1のメタデータ記憶手段と、検索対象となるコンテンツ配信サービスである検索対象サービスと、コンテンツの検索条件とを入力する検索入力手段と、前記メタデータの蓄積方式として過去に検索された検索条件に対応するメタデータのみを蓄積する検索ベース蓄積方式が決定された第2のコンテンツ配信サービスについて、前記第2のコンテンツ配信サービスと、過去に検索された検索条件と、メタデータとを関連づけて記憶した第2のメタデータ記憶手段と、前記検索対象サービスの蓄積方式が前記事前蓄積方式のときは、前記第1のメタデータ記憶手段において前記検索対象サービスに関連するメタデータにおいて前記入力された検索条件に合致するメタデータを検索する第1の検索処理手段と、
前記検索対象サービスの蓄積方式が前記検索ベース蓄積方式であるとき、前記検索対象サービスと前記入力された検索条件との組が前記第2のメタデータ記憶手段に登録されているか否かを判定し、登録されているときは、前記検索対象サービスと前記入力された検索条件との組に対応するメタデータを前記第2のメタデータ記憶手段から取得し、登録されていないときは、前記検索対象サービスに関連するメタデータ提供装置に対し当該メタデータ提供装置が保有するメタデータのうち前記入力された検索条件に合致するメタデータの取得要求を送信し、前記取得要求に応答して前記メタデータ提供装置から返されるメタデータを取得し、取得したメタデータと前記入力された検索条件とを前記検索対象サービスに関連づけて前記第2のメタデータ記憶手段に蓄積する、第2の検索処理手段と、前記1または第2の検索処理手段により取得された前記メタデータを表示する検索結果表示手段とを備えたことを特徴とする。
本発明により、コンテンツ配信サービス別にコンテンツのメタデータを効率的に収集および蓄積できる。
図1は、本発明の一実施の形態に従ったコンテンツ配信システムの全体図である。
本発明の一実施形態としてのメタデータ収集装置101が複数のネットワーク1〜3に接続されている。各ネットワーク1〜3にはそれぞれ1つ以上のメタデータ提供装置102a〜102eが接続されている。
以下では、まずメタデータ提供装置102a〜102e、メタデータ収集装置101およびネットワーク1〜3の概要について説明し、その後、メタデータ収集装置101について詳しく説明する。
メタデータ提供装置102a〜102eは、それぞれ対応するコンテンツ配信サービスに関連するコンテンツのメタデータを提供する。メタデータとは、コンテンツ自体ではなく、そのコンテンツの属性情報を示すもので、コンテンツが映像データ、音声データ、WEBページ等である場合、そのメタデータは、たとえばタイトル(識別子)、詳細情報、作成日時、コンテンツ場所等である。なお、メタデータ記述形式は標準仕様であっても、各サービス独自の形式であってもよい。
メタデータ提供装置102a〜102eは、コンテンツ配信サービス事業者が運用するメタサーバや、HDDレコーダなどのコンテンツ保有機器や、メタデータ収集装置101に接続されているローカルストレージなどである。
コンテンツ配信サービスの一例を図12に示す。たとえばメタデータ提供装置102aは高品質VoDサービスが配信するコンテンツのメタデータを提供し、メタデータ提供装置102bは映像投稿サービスが配信するコンテンツのメタデータを提供する。このようにコンテンツ数が非常に多いサービスからコンテンツ数が限定されたサービスまで、多種多様なサービスがある。それらのサービスの違いとしては、以下のような違いがある。
・ 保有コンテンツ数が多い/少ない
・ 有料/無料
・ 宅内コンテンツ/外部ネットワーク上のコンテンツ
・ 更新頻度が少ない/多い
メタデータ収集装置101は、メタデータ提供装置102a〜102eからメタデータを収集および管理する装置である。メタデータ収集装置101は、たとえば、映像表示機能を備えているテレビやパーソナルコンピュータ(PC)等の機器、もしくは、該機器(テレビ、PCなど)の代わりにメタデータを収集管理する装置である。メタデータ収集装置101では、ECGアプリケーションといったメタデータ収集アプリケーションが起動しており、本アプリケーションがメタデータの収集管理を行う。本実施の形態では、メタデータ収集装置101のリソースを勘案した上で、メタデータを出来るだけ多くメタデータ収集装置101上に蓄積することで、メタデータ提供装置からのメタデータ収集に要する時間を軽減することを大きな特徴の1つとしている。これによりデジタルテレビ等のコンシューマ機器において、複数のコンテンツ配信サービスから映像コンテンツを検索し視聴するための、高速なナビゲーション機能を実現する。
複数のネットワーク1〜3はそれぞれ異なるネットワークである。異なるネットワークとは以下のようなネットワークである。
・ 異なるネットワーク事業者が運用する、異なるネットワーク
・ 同一ネットワーク事業者が運用する、異なるネットワーク
・ ローカルエリアネットワーク
異なるネットワーク事業者が運用する異なるネットワークとは、たとえば、ネットワーク事業者Aが運用しているネットワーク1とネットワーク事業者Bが運用しているネットワーク2のような場合である。このように物理的に異なるネットワークは、別々のネットワークとして扱う。
同一ネットワーク事業者が運用する異なるネットワークとは、同一のネットワーク事業者がサービス品質等に応じて、異なるネットワークとして運用しているネットワークのような場合である。たとえば、ネットワーク1は品質管理されたネットワークであり、ネットワーク2は品質管理されていないベストエフォートなネットワークの場合、または、ネットワーク1はIPv6ネットワークで、ネットワーク2はIPv4ネットワークである場合である。このように物理的もしくは論理的に異なるネットワークは、別々のネットワークとして扱う。
ローカルエリアネットワークとは、たとえば、家庭に閉じたホームネットワークなどである。このように、ホームネットワークと外部ネットワークは別々のネットワークとして扱う。
以下、メタデータ収集装置101について詳細に説明する。
図2はメタデータ収集装置の機能ブロック図である。各機能ブロックの説明を以下にそれぞれ示す。
[ユーザインターフェース部11]
ユーザインターフェース部11は、ユーザが所望のコンテンツを検索する際にコンテンツの検索条件および検索対象サービスを入力するための入力インターフェース、ならびに検索結果としてのコンテンツリスト(タイトル等のリスト)を表示する出力インターフェースを提供する。図10にコンテンツの検索条件および検索対象サービスを入力するコンテンツ検索画面の例を、図11に検索されたコンテンツのリストを含む検索結果表示画面の例を示す。ユーザインターフェース部11は、本発明の、検索条件および検索対象サービスを入力する検索入力手段、および検索条件および検索対象サービスに応じて取得されたメタデータを表す検索結果を表示する検索結果表示手段を含んでいる。
[ネットワークインターフェース部]
ネットワークインターフェース部20は、ネットワーク1〜3を介して、メタデータ提供装置102a〜102eと情報を送受信するためのインターフェース部である。具体的には、メタデータ提供装置102a〜102eに対するメタデータ取得要求パケットの送信、及びメタデータ提供装置102a〜102eからのメタデータパケットの受信を行うインターフェース部である。
[メタデータ形式統一部12]
メタデータ形式統一部12は、複数のメタデータ提供装置102a〜102eから収集したメタデータの形式を統一して、形式の統一されたメタデータをサービス・メタデータ情報蓄積部19に蓄積する。すなわち、メタデータ形式統一部12は、サービス毎に収集したメタデータを、メタデータ形式の違いを吸収して、サービス・メタデータ情報蓄積部19に蓄積する。
[端末・サーバ・ネットワーク負荷監視部13]
端末・サーバ・ネットワーク負荷監視部13は、メタデータ収集装置101のCPU負荷、メタデータ収集装置101で稼動している他のアプリケーションの状況、または、ネットワーク負荷やサーバ負荷などの外乱の影響を監視する。たとえば、他のアプリケーションの状況の監視としては、メタデータ収集によりその動作が大きな影響を受ける映像受信アプリケーションまたは映像表示アプリケーションなどの動作状況の監視がこれに相当する。
[メタデータ収集速度決定部14]
メタデータ収集速度決定部14は、上記負荷監視部13で監視されている各種負荷状況に応じて、メタデータ収集速度を決定する。ここでメタデータ収集速度は、1リクエスト当たりのメタデータ数、または単位時間当たりのメタデータ収集速度(たとえば、1分当たりのメタデータ取得数)である。以降では、メタデータ収集速度とは1リクエスト当たりのメタデータ収集数であるとする。
メタデータ収集速度決定部14は、以下の指標を基に、メタデータ収集速度を決定する。
(1)自端末のCPU負荷、他のアプリケーションの起動状況
(2)ネットワーク負荷
(3)サーバ負荷
これらの各種負荷に応じて、メタデータ収集速度をどのようにして決定するかを以下に示す。
(1)自端末のCPU負荷、他のアプリケーションの起動状況
自端末のCPU負荷が高い、もしくは他のアプリケーション(たとえば、映像受信アプリケーション、映像表示アプリケーション)が起動している場合は、メタデータ収集の影響で、起動中のアプリケーションに影響を及ぼすことが有り得るため、1リクエスト当たりのメタデータ取得数を減らす、もしくは少し時間が経ってから再取得する等により、時間をかけてメタデータを収集する。逆に、CPU負荷が低いもしくは他のアプリケーションが起動していない場合は、メタデータ収集における影響が小さいため、1リクエスト当たりのメタデータ収集数を増やして短時間でメタデータを収集する。
たとえば、映像表示アプリケーション起動中にはメタデータ収集速度を1リクエスト当たり5件とし、映像表示アプリケーション未起動中には、メタデータ収集速度を1リクエスト当たり100件とするなどである。そうすることで、メタデータ収集による影響が大きい映像表示アプリケーションに対する影響を最小限に抑えつつ、メタデータの収集を行うことが可能となる。
(2)ネットワーク負荷
使用可能なネットワーク帯域が少ない、パケットロスが頻繁に発生する、またはパケットのジッタが大きい場合には、ネットワーク負荷が高まっている可能性が高い。そのような状況で大量のメタデータを収集すると、輻輳が発生する等でさらに悪化する可能性がある。それを回避するために、使用可能なネットワーク帯域が少ない、パケットロスが頻繁に発生する、またはジッタが大きい等でネットワーク負荷が大きいと想定される場合は、1リクエスト当たりのメタデータ収集数を減らすもしくは少し時間が経ってから再取得する等により、時間をかけてメタデータを収集する。逆に、ネットワーク負荷が小さいと想定される場合は、1リクエスト当たりのメタデータ収集数を増やすことにより、短時間でメタデータを収集する。
(3)サーバ負荷
メタデータ提供装置からメタデータを収集する際、メタデータ提供装置の負荷はメタデータの収集に大きく影響する。たとえば、メタデータ提供装置の負荷が非常に高い場合、リクエストタイムアウトが発生し、メタデータの表示がそのリクエストタイムアウトに引きずられ遅くなってしまう等の問題が起きる。その問題を回避するために、メタデータ提供装置のレスポンス速度やメタデータ取得までの所要時間からメタデータ提供装置の負荷が高いと想定される場合は、1リクエスト当たりのメタデータ収集数を減らすもしくは少し時間が経ってから再取得する等により、時間をかけてメタデータを収集する。逆に、メタデータ提供装置の負荷が低いと想定される場合は、1リクエスト当たりのメタデータ収集数を増やすことで、短期間でメタデータを収集する。
以上に示したように、メタデータ収集速度決定部14では、(1)〜(3)に示した端末・サーバ・ネットワークの負荷を考慮しつつ、メタデータ収集速度を決定する。それにより、効率的にかつ他のアプリケーションに影響を与えることなく、メタデータ収集が可能となる。
[サービス・メタデータ情報蓄積部19]
サービス・メタデータ情報蓄積部19は、メタデータ提供装置102a〜102eから取得したメタデータを蓄積する。
またサービス・メタデータ情報蓄積部19は、図8 および図9 に示すようなサービス毎に設定されたサービス情報を蓄積する。サービス・メタデータ情報蓄積部19はたとえば、ハードディスクや不揮発性メモリにより構成される。
図8 および図9 に示されるサービス情報は以下の項目を含む。
・ 対応サービス数
・ 対応サービス名
・ キャッシュ方式
・ キャッシュ上限件数
・ メタデータ取得用情報
・ 登録クエリ数
・ 登録クエリ
・ 検索回数
・ 視聴回数
・ 推奨更新頻度(キャッシュ更新頻度)
・ 推奨更新時間(キャッシュ更新時間)
・ キャッシュ次更新日時
・ キャッシュ有効期間
・ キャッシュ削除日時
「対応サービス数」は、登録されたサービスの数を表しており、図8および図9の例では5つのサービスが登録されている。これら5つのサービスのうちの1つである映像投稿サービスが図8に、別の1つである高品質VoDサービスが図9に示されている。
「対応サービス名」は、登録されたサービスの名称を表す。すなわち、ECGのようなメタデータ収集アプリケーションで対応しているサービスの名称を表す。
「キャッシュ方式」は、後述するキャッシュ方式決定部(蓄積方式決定手段)15において決定したキャッシュ方式(蓄積方式)を表す。キャッシュ方式には、Query-based Caching Method(クエリベースキャッシュ方式)と、All Caching Method(全キャッシュ方式)とがある。簡単には、All Caching Method(全キャッシュ方式)は、サービスが保有(提供)しているメタデータを予めすべてキャッシュする方式、Query-based Caching Method(クエリベースキャッシュ方式)は、検索が行われるごとに、検索された検索条件(検索式)について、上位数件のみまたはすべてをキャッシュする方式である。Query-based Caching Method(クエリベースキャッシュ方式)は、本発明の検索ベース蓄積方式に対応し、All Caching Method(全キャッシュ方式)は本発明の事前蓄積方式に対応する。これらのキャッシュ方式の詳細については後述する。サービス・メタデータ情報蓄積部19においてキャッシュ方式を記憶する部分は、本発明の蓄積方式記憶手段に相当する。
「キャッシュ上限件数」は、Query-based Caching Method(クエリベースキャッシュ方式)の場合において、検索毎のキャッシュ件数の上限値を表し、この上限件数までメタデータを取得しキャッシュする。
「メタデータ取得用情報」は、メタデータ提供装置からメタデータを取得する際に必要となる情報である。たとえば、メタデータ提供装置が提供しているメタデータ取得用URLや、各サービスのメタデータを取得するためにECGアプリケーション等のメタデータ収集アプリケーションが用意しているメタデータ収集用APIなどが相当する。
「登録クエリ」は、過去に検索した検索条件である。ただし後述するように、キャッシュ方式がQuery-based Caching Method(クエリベースキャッシュ方式)の場合にのみ、検索した検索条件が登録クエリとして登録される。ここで検索条件は、ジャンルとキーワードの組み合わせであり、たとえば、“ジャンル:スポーツ、キーワード:テニス”などである。なお、これに限らず、プロモーション情報(お勧め、新着など)の組み合わせであってもよい。
「登録クエリ数」は、クエリベースキャッシュ方式の場合において、登録クエリの個数を表す。図8の例では、10個の登録クエリが登録されている。項目「登録クエリ」〜「キャッシュ削除日時」の組は登録クエリ毎に用意され、図8の例では登録クエリが10個存在するため、「登録クエリ」〜「キャッシュ削除日時」の組が10個用意される。ただし、全キャッシュ方式の場合は、登録クエリ数は固定的に「1」が設定される。
「検索回数」は、登録クエリもしくはサービス毎の検索回数を表す。キャッシュ方式がQuery-based Caching Method(クエリベースキャッシュ方式)では登録クエリ毎の検索回数、All Caching Method(全キャッシュ方式)ではサービス毎の検索回数を表す。
「視聴回数」は、登録クエリもしくはサービス毎の、該当するコンテンツの視聴回数を表す。たとえばある登録クエリに基づく検索で得られたメタデータからリンクを辿ってコンテンツを視聴した回数が合計でX回のとき、視聴回数はXとなる。
「推奨更新頻度」および「推奨更新時間」は、キャッシュの更新頻度および更新時間を表す。より詳細に、推奨更新頻度は最終更新日時から次更新日時までの間隔であり、推奨更新時間はキャッシュを更新する時間帯である。たとえば、「推奨更新頻度:1時間毎」、「推奨更新時間:AM10:00」等である。推奨更新時間および推奨更新頻度は、後述するキャッシュ更新頻度・時間決定部16で決定した値でもよいし、予めサービス・メタデータ情報蓄積部19に登録しておいてもよい。
「キャッシュ次更新日時」は、次にキャッシュを更新すべき日時であり、最終更新時間及び、上記推奨更新頻度と上記推奨更新時間から、後述するキャッシュ管理部18において決定する。
ここで、「推奨更新頻度」および「推奨更新時間」はたとえば本発明の更新条件に相当し、特に推奨更新頻度は、本発明のメタデータ記憶手段の更新頻度、推奨更新時間は、本発明のメタデータ記憶手段の更新時間帯に相当する。または、「キャッシュ次更新日時」が本発明の更新条件に相当する。後述する説明では、更新条件として、上記推奨更新頻度と上記推奨更新時間を反映した指標であるキャッシュ次更新日時を採用する。なお、本発明の更新条件は、キャッシュの更新の契機を定めたものであればなんでもよく、上記の「推奨更新頻度」、「推奨更新時間」、「キャッシュ次更新日時」に限定されるものではない。サービス・メタデータ蓄積部19において、全キャッシュ方式のサービスに対応する更新条件を記憶する部分は、第1の更新条件記憶手段に相当し、クエリベースキャッシュ方式のサービスに対応して登録クエリ毎に更新条件を記憶する部分は、第2の更新条件記憶手段に相当する。
「キャッシュ有効期間」は、キャッシュの有効期間であり、後述するキャッシュ更新頻度・時間決定部16において決定する。キャッシュ有効期間は、キャッシュ方式がQuery-based Caching Method(クエリベースキャッシュ方式)の場合にのみ設定される。キャッシュ有効期間はたとえば10日のように設定される。
「キャッシュ削除日時」は、最終更新日時と上記キャッシュ有効期間から、後述するキャッシュ管理部18において決定する。たとえば、最終更新時間が2008/04/03 AM10:00、キャッシュ有効期間が10日間の場合は、キャッシュ削除日時は2008/04/13 AM10:00となる。
上述したように、サービス・メタデータ情報蓄積部19は、メタデータを蓄積するが、メタデータは、キャッシュ方式が全キャッシュ方式のサービスについてはサービス単位で蓄積され、クエリベースキャッシュ方式のサービスについては、サービス毎に登録クエリ単位で記憶される。サービス単位でメタデータを記憶する部分は、本発明の第1のメタデータ記憶手段に相当し、登録クエリ単位でメタデータを記憶する部分は、本発明の第2のメタデータ記憶手段に相当する。
[キャッシュ方式決定部15]
キャッシュ方式決定部15は、サービス・メタデータ情報蓄積部19に登録された各サービスのそれぞれについてキャッシュ方式を決定する。ここで決定したキャッシュ方式は、キャッシュ管理部18を介して、サービス・メタデータ情報蓄積部19に登録される。キャッシュ方式は、たとえば以下に示す(1)および(2)のうちのいずれかの方式を選択する。
(1) All Caching Method(全キャッシュ方式)
本方式は、サービスが保有(提供)しているメタデータを予めすべてキャッシュする方式である。すべてのメタデータのキャッシュが完了すると、以後は差分のみを定期的に更新する。メタデータ更新はサービス・メタデータ情報蓄積部19で管理されているキャッシュ次更新日時に基づいて行われる。All Caching Method(全キャッシュ方式)は本発明の事前蓄積方式に対応する。
(2) Query-based Caching Method(クエリベースキャッシュ方式)
本方式は、サービスが保有(提供)するメタデータを予めキャッシュするのではなく、検索された検索条件(検索式)毎に、上位件数のみキャッシュする。上位件数は、サービス毎に決めておき、たとえば、500件のように決めておき、最大で上位件数(500件)分のメタデータを送るようにメタデータ提供装置に要求する。なお、メタデータ提供装置に、検索条件に合致するすべてのメタデータを送るよう要求し、送られたメタデータ数が上位件数を超えるときはこれらのメタデータの中から上位件数のメタデータのみを選択してもよい。この場合、選択基準は任意でよく、たとえば最初に取得した上位件数のメタデータでもよいし、メタデータに優先度が付されているような場合は、優先度の高いものから上位件数のメタデータを選択してもよい。
本方式では、最初の検索時のみメタデータ提供装置から検索条件に合致するメタデータを収集し、以後はその検索単位(すなわちクエリ単位)で定期的に更新タイミングで更新する。更新の際は、キャッシュを削除して登録クエリ(検索条件)毎のメタデータを上限件数まで再取得する。もしくは一度キャッシュをクリアしなくても、差分のみ取得が可能であれば、差分のみを再取得する。ただ、各登録クエリのキャッシュ件数はある上限件数までとする。
メタデータ更新(キャッシュ更新)はサービス・メタデータ情報蓄積部19に登録されているキャッシュ次更新日時に基づいて行われる。またキャッシュの削除は、サービス・メタデータ情報蓄積部19に登録されているキャッシュ削除日時に基づいて行われる。なお、本方式では、キャッシュの有効期間を設けて、その時間経過後は、キャッシュのクリアを行う。上記説明では、上位件数のメタデータのみをキャッシュするとしたが、検索条件に合致するすべてのメタデータをキャッシュするようにしてもよい。Query-based Caching Method(クエリベースキャッシュ方式)は本発明の検索ベース蓄積方式に相当する。
ここで、キャッシュ方式決定部15は、以下の(A)〜(C)のうちいずれかの指標に従ってキャッシュ方式を決定する。いずれの指標を用いる場合においても、サービス・メタデータ情報蓄積部19の容量、つまり、ハードディスクやメモリ容量を優先して、判断を行うものとする。
(A)Manual
ユーザがサービス毎にキャッシュ方式を決定する。たとえば、ポップアップを表示し、キャッシュ方式をユーザが決定する。
(B)Pre-Configure
サービス毎のキャッシュ方式について予め、サービス・メタデータ情報蓄積部19に登録しておく。たとえば、高品質VoD映像サービスではコンテンツ数が限られているため、All Caching Method(全キャッシュ方式)を登録し、映像投稿サービスではコンテンツ数が非常に多いのでQuery-based Caching Method(クエリベースキャッシュ方式)を登録しておく。
(C)Auto
サービス毎のキャッシュ方式について自動的に判断する。判断は以下のいずれかの判断基準に基づく。ただこれに限ったものではなく、キャッシュ方式を判断できる限り、どのような判断基準を用いてもよい。
・ サービスから総保有コンテンツ数(メタデータの総数)を取得可能であり、かつ、総コンテンツ数(総メタデータ数)がある閾値以下である場合は全キャッシュ方式を決定し、それ以外はクエリベースキャッシュ方式を決定する。上記ある閾値は、定量であってもいいし、ハードディスクの容量を基に決めてもいい。
・ サービス毎ではなく、ネットワーク単位でネットワークの種類または品質に応じてキャッシュ方式を判断する。たとえば、ホームネットワークや品質管理されたネットワーク上のメタデータ提供装置により提供されるサービスに対しては全キャッシュ方式を決定し、The Internet上のメタデータ提供装置により提供されるサービスに対してはクエリベースキャッシュ方式を決定する。また、DLNA(Digital Living Network Alliance)でコンテンツが配信されるネットワークでは全キャッシュ方式を決定し、それ以外のネットワークについてはクエリベースキャッシュ方式を決定する。
・ サービスの種類によりキャッシュ方式を判断する。たとえば、有料サービスは全キャッシュ方式を決定し、無料サービスはクエリベースキャッシュ方式を決定する。
・ メタデータの更新頻度によりキャッシュ方式を判断する。メタデータの更新頻度は、メタデータの総数にも密に連携するため、メタデータの更新頻度が少ないサービスはコンテンツ総数も少ないと見なす。たとえば、更新頻度が少ないサービスでは、キャッシュの更新があまりないので全キャッシュ方式を決定し、キャッシュの更新が頻繁であるサービスに関しては、クエリベースキャッシュ方式を決定する。
[キャッシュ更新頻度・時間決定部16]
キャッシュ更新頻度・時間決定部16は、キャッシュ管理部18からの指示により、キャッシュ方式に応じた更新単位(サービス単位または登録クエリ単位)で、キャッシュの推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定して、サービス・メタデータ情報蓄積部19に登録する。推奨更新頻度、推奨更新時間、キャッシュ有効期間は、キャッシュ更新頻度・時間決定部16で決定してもよいが、予めサービス毎に、サービス・メタデータ情報蓄積部19に登録しておいてもよい。推奨更新頻度は、本発明のメタデータ記憶手段の更新頻度に対応し、推奨更新時間は本発明のメタデータ記憶手段の更新時間帯に相当する。
キャッシュ更新単位はキャッシュ方式により異なり、All Caching Method(全キャッシュ方式)はサービス単位での更新となり、またQuery-based Caching Method(クエリベースキャッシュ方式)は登録クエリ単位での更新となる。また、キャッシュの削除は、キャッシュ方式がQuery-based Caching Method(クエリベースキャッシュ方式)の場合のみ行い、キャッシュの有効期間はQuery-based Caching Method(クエリベースキャッシュ方式)の場合のみ登録する。
キャッシュ更新頻度・時間決定部16は、以下のような方法により推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定する。
(A)推奨更新頻度
推奨更新頻度は、サービス・メタデータ情報蓄積部19に登録されている視聴回数または検索回数を基に決定する。視聴回数または検索回数が多いものに関しては、推奨更新頻度を高く設定し、逆に、視聴回数または検索回数が少ないものに関しては、推奨更新頻度を低く設定する。たとえば、“視聴回数が5回以下なら1日おき、6-10回なら12時間おき、11回以上なら6時間おき”のように視聴回数に応じて推奨更新頻度を決定する。キャッシュ更新頻度・時間決定部16を用いずに推奨更新頻度を予めサービス・メタデータ情報蓄積部19に登録しておいてもよい。この場合は、たとえば、ECGアプリケーション起動時にトップ画面に表示するコンテンツに関しては、常に最新の状態に保っておくことが望ましいので、そのようなコンテンツをもつサービス、またはそのようなコンテンツのメタデータに関連づけられた登録クエリは推奨更新頻度を高くしておく。
(B)推奨更新時間
推奨更新時間は、単位時間おきのメタデータ提供装置が提供するメタデータ数の増加数を基に決定する。たとえば、単位時間おきにメタデータ提供装置から総メタデータ数を取得し、総メタデータ数の増加の変動が“10時:10件、14時:10件、18時:20件、22時:100件”のような場合には、推奨更新時間は22時と決定する等である。
キャッシュ更新頻度・時間決定部16を利用せずに予めサービス・メタデータ情報蓄積部19に推奨更新時間を登録してもよい。この場合、ある特定の時間に頻繁に更新が行われることがわかっているサービスに関しては、その時間を推奨更新時間として登録しておく。たとえば、放送サービスのように日の変わり目にメタデータが更新されることが予め分かっている場合は、日の変わり目を推奨更新時間として登録する。
(C)キャッシュ有効期間
検索回数または視聴回数に応じて、キャッシュの有効期間を設定する。たとえば、“視聴回数が5回以下なら3日、6-10回なら10日、11回以上なら20日”といったように視聴回数または検索回数に応じてキャッシュの有効期間を決定する。
[メタデータ取得・更新要求部17]
メタデータ取得・更新要求部17は、キャッシュ管理部18からのメタデータ取得要求を受けて、メタデータ提供装置に対してメタデータの取得要求を行う。キャッシュ管理部18からは、メタデータ収集速度、取得メタデータ数、およびサービス情報(たとえばメタデータ取得用情報)が渡され、メタデータ取得・更新要求部17は、それに基づいてメタデータを取得する。メタデータ収集速度は、メタデータ提供装置にメタデータの取得要求を行う都度、取得するものとする。
たとえば、メタデータ収集速度:1リクエスト当たり100件、メタデータ取得数:500件、サービス情報:メタデータ提供装置のメタデータ取得URLが、メタデータ取得・更新要求部17に渡された場合における挙動の例を以下に示す。
最初のリクエストにおいて100件取得し、次のリクエストをメタデータ提供装置に要求する場合は、メタデータ収集速度を再度取得する。その際に、他のアプリケーションが起動した等でCPU負荷が急激に高まった等によりメタデータ収集速度が10件と変更された場合はその取得速度に応じてメタデータを取得する。以上の動作を繰り返し行うことで、メタデータ取得総数までメタデータを取得する。
[キャッシュ管理部18]
キャッシュ管理部18は、サービス・メタデータ情報蓄積部19に登録された各サービスについて、それぞれに対するキャッシュ方式が登録済みか否かを確認し、登録済みでないサービスについては、キャッシュ方式決定部15にキャッシュ方式の決定を要求し、キャッシュ方式決定部15により決定したキャッシュ方式をサービス・メタデータ情報蓄積部19に登録する。
キャッシュ管理部18は、全キャッシュ方式が登録されたサービスについては、初回のみ以下の処理を行う。すなわちキャッシュ管理部18は、該サービスに関連するメタデータ提供装置から、当該メタデータ提供装置が保有するすべてのメタデータを取得し、該サービスに関連づけてサービス・メタデータ情報蓄積部19に記憶する。この処理は、本発明のメタデータ取得処理手段の処理に相当し、キャッシュ管理部18はメタデータ取得処理手段を含む。
メタデータの取得要求の際は、メタデータ収集速度決定部14からメタデータ収集速度を取得してメタデータ取得・更新要求部17に検索対象サービスとともに指定する。
また、キャッシュ管理部18は、ユーザインターフェース部11から検索クエリ(検索条件と検索対象サービスとを指定したクエリ)があった場合は、検索対象サービスのキャッシュ方式を判定する。
全キャッシュ方式の場合は、検索対象サービスについてあらかじめ取得してあるメタデータにおいて、検索条件に合致するメタデータを検索し、発見したメタデータを、ユーザインターフェース部11を介して表示する。これは本発明の第1の検索処理手段の処理に相当する。
クエリベースキャッシュ方式の場合は、その検索クエリにおける検索条件に合致する登録クエリが存在するかどうかを判定し、存在する場合は、当該登録クエリに対応するメタデータをメタデータ・情報蓄積部19から取得し、ユーザインターフェース部11を介して表示する。検索条件に合致する登録クエリが存在しない場合は、メタデータ取得・更新要求部17にメタデータの取得要求を行い、取得したメタデータをユーザインターフェース部11を介して表示し、また検索対象サービスにおける検索条件(登録クエリ)と関連づけてサービス・メタデータ情報蓄積部19に格納する。これは本発明の第2の検索処理手段の処理に相当する。メタデータの取得要求の際は、検索対象サービス、検索条件、メタデータ収集数を指定するとともに、メタデータ収集速度決定部14からメタデータ収集速度を取得してメタデータ取得・更新要求部17に渡す。
なお、キャッシュ管理部18はユーザインターフェース部11を介して表示されたメタデータ(たとえばコンテンツリスト)において、あるメタデータの指定(あるコンテンツの指定)を受けたら、指定されたメタデータに対応するコンテンツを、該コンテンツを管理するコンテンツサーバ(メタデータ提供装置がコンテンツサーバの機能を有していても良い)からダウンロードし、コンテンツを処理するコンテンツ処理部(図示せず)に渡すようにしてもよい。この際、コンテンツサーバのアドレスは、たとえばメタデータに含まれている。
また、キャッシュ管理部18は、検索クエリがあった場合、メタデータを新規に取得した場合、またはキャッシュのメタデータを更新した場合等に、キャッシュ更新頻度・時間決定部16に対し、キャッシュの推奨更新頻度、推奨更新時間、キャッシュ有効期間の決定を指示する。そして決定された推奨更新頻度、推奨更新時間、キャッシュ有効期間をサービス・メタデータ情報蓄積部19に登録する。ただし、キャッシュ有効期間の決定および登録はクエリベースキャッシュ方式のサービスについてのみ行う。
また、キャッシュ管理部18は、推奨更新時間と推奨更新頻度、および最終更新日時からキャッシュ次更新日時を決定し、サービス・メタデータ情報蓄積部19に登録する。
また、キャッシュ管理部18は、キャッシュ有効期間、および最終更新日時からキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部19に登録する。キャッシュ次更新日時を決定する場合に、推奨更新頻度と推奨更新時間のうちどちらを優先してもかまわない。たとえば、最終更新時間:2008/04/03 PM4:00、推奨更新頻度:2日、推奨更新時間:AM3:00の場合は、キャッシュ次更新日時は2008/04/05 PM4:00としても、2008/04/05 AM3:00としてもよい。キャッシュ削除日時の決定は、クエリベースキャッシュ方式の場合にのみ行う。
また、キャッシュ管理部18は、サービス・メタデータ情報蓄積部19に管理されているサービス情報を定期的に監視し、キャッシュの更新・削除を行う。つまり、キャッシュ管理部18は、キャッシュ次更新日時(更新条件)およびキャッシュ削除日時を確認し、キャッシュ削除日時が経過したときはキャッシュを削除し、キャッシュ更新日時が経過したときは(更新条件が成立したときは)メタデータの更新処理を行う。ただし、キャッシュの削除は、クエリベースキャッシュ方式の場合にのみ行う。キャッシュ管理部18は、全キャッシュ方式のサービスについての更新条件の成立の有無を判定する第1の更新条件判定手段と、更新条件の成立したサービスについてメタデータを更新する第1の更新処理手段とを備えている。またキャッシュ管理部18は、クエリベースキャッシュ方式のサービスについて登録クエリ毎に更新条件の成立の有無を判定する第2の更新条件判定手段と、更新条件が成立した、サービスおよび登録クエリの組についてメタデータを更新する第2の更新処理手段とを備えている。
[動作シーケンス]
以下、図2のメタデータ収集装置101の動作シーケンスを
(1)メタデータ収集装置101の起動時
(2)キャッシュしてあるメタデータの更新タイミング
(3)ユーザ(インターフェース)からの検索クエリの発生
の3つに分けて説明する。
(1)メタデータ収集装置101の起動時
図3および図4はメタデータ収集装置101の起動時に行われる動作シーケンスを説明するフローチャートである。ここでメタデータ収集装置101の起動とはECGのようなメタデータ収集アプリケーションの起動のことである。
(初期起動時)
以下では、ECGアプリケーション起動時に、サービス・メタデータ情報蓄積部19にコンテンツのメタデータが全くキャッシュされていない場合のシーケンスについて、図3を用いて説明する。なお以降の説明では、一つのサービスに着目したシーケンスについて示すが、複数のサービスがある場合はこれらのシーケンスを並列に処理するか、あるいは、あるサービスが終了してから次のサービスについて処理すればよい。
ステップ1では、メタデータ収集装置101の起動を行う。つまり、ECGアプリケーションの起動を行う(S101)。
ステップ2では、サービス・メタデータ情報蓄積部19に格納されているサービス毎にキャッシュ方式が登録されているか確認を行う(S102)。すべてのサービスについてそれぞれキャッシュ方式が決定されている場合は(YES)、ステップ4に移動する。また、キャッシュ方式が登録されていないサービスがある場合は(NO)、ステップ3に移動する。
ステップ3では、キャッシュ方式決定部15において、サービス毎にキャッシュ方式を決定し、サービス・メタデータ情報蓄積部19に登録する(S103)。キャッシュ方式の決定は、前述した判断基準に基づき行う。キャッシュ方式は、All Caching Method(全キャッシュ方式)またはQuery-based Caching Method(クエリベースキャッシュ方式)を選択する。
ステップ4では、着目するサービスのキャッシュ方式がAll Caching Method(全キャッシュ方式)か否かを判断する(S104)。キャッシュ方式がAll Caching Method(全キャッシュ方式)の場合は、ステップ5に移動する。キャッシュ方式がQuery-based Caching Method(クエリベースキャッシュ方式)の場合は、処理を終了する。
ステップ5では、メタデータ収集速度決定部14において、メタデータの収集速度を決定する(S105)。
ステップ6では、キャッシュ管理部18はメタデータ取得・更新要求部17に対して、ステップ5で決定したメタデータ収集速度と、さらに収集メタデータ数、サービス情報(たとえばメタデータ取得用情報)とを送信し、メタデータ取得・更新要求部17はそれらの情報をもとに、メタデータ提供装置からメタデータを収集する(S106)。All Caching Method(全キャッシュ方式)のため、収集メタデータ数は、メタデータ提供装置が保有するすべてのメタデータである。なお、All Caching Method(全キャッシュ方式)の場合であっても、ハードディスク容量等に応じて、収集すべきメタデータ数を具体的に計算し、計算したメタデータ数のメタデータのみを収集するようにしてもよい。
ステップ7では、キャッシュ更新頻度・時間決定部16において、推奨更新頻度、推奨更新時間を決定し、サービス・メタデータ情報蓄積部19に登録する(S107)。
ステップ8では、キャッシュ管理部18において、推奨更新頻度および推奨更新時間を基にキャッシュ次更新日時を決定し、サービス・メタデータ情報蓄積部19に登録し(S108)、本シーケンスを終了する。
(2回目以降の起動時)
以下では、メタデータ収集装置101の2回目以降の起動時の動作シーケンスについて、図4を用いて説明する。ただしサービス・メタデータ情報蓄積部19にはサービス毎にキャッシュ方式は登録済みであるとし、また少なくともAll Caching Method(全キャッシュ方式)のサービスについてはキャッシュがすでに保存されているとする。本シーケンスは、メタデータ収集装置の起動とECGアプリケーションの起動が連動している場合についてであり、ECGアプリケーションが常に起動している(メタデータ収集装置の電源オフ時にもECGアプリケーションがバックグラウンドで起動している)場合は、本シーケンスには当てはまらない。なお、以降では一つのサービスに着目したシーケンスを説明するが、複数のサービスがある場合は、これらのシーケンスを並列に処理するか、あるいは、あるサービスが終了してから次のサービスの処理を行えばよい。
図4に示すように、ステップ1では、メタデータ収集装置101の起動を行う(S201)。つまり、ECGアプリケーションの起動を行う。
ステップ2では、Query-based Caching Method(クエリベースキャッシュ方式)のサービス毎に、サービス・メタデータ情報蓄積部19に登録されているキャッシュ削除日時を経過しているかどうか確認し(S202)、キャッシュ削除日時を経過していた場合は(YES)、キャッシュを削除し(S208)、本シーケンスを終了する。また、キャッシュ削除日時を経過していない場合は(NO)、ステップ3に進む。
ステップ3では、サービス毎に、サービス・メタデータ情報蓄積部19に登録されているキャッシュ更新日時を経過しているかどうか確認し(S203)、キャッシュ更新日時を経過していた場合は(YES)、ステップ4に進む。キャッシュ更新日時を経過していない場合(NO)、本シーケンスは終了する。
ステップ4では、メタデータ収集速度決定部14において、メタデータの収集速度を決定する(S204)。
ステップ5では、キャッシュ管理部18がメタデータ取得・更新要求部17に対して、ステップ4で決定したメタデータ収集速度と、さらに収集メタデータ数、サービス情報(たとえばメタデータ取得用情報)を送信し、メタデータ取得・更新要求部17はそれらの情報をもとに、メタデータ提供装置からメタデータの収集を行う(S205)。ただし収集メタデータ数の送信はクエリベースキャッシュ方式の場合についてのみ行う。メタデータ収集の際に、All Caching Method(全キャッシュ方式)の場合は差分のみを、Query-based Caching Method(クエリベースキャッシュ方式)の場合はキャッシュ管理部18から要求された収集メタデータ数(上位件数)のメタデータを、メタデータ提供装置から収集する。
ステップ6では、キャッシュ更新頻度・時間決定部16において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定し、サービス・メタデータ情報蓄積部19に登録する(S206)。ただし、有効期間についてはQuery-based Caching Method(クエリベースキャッシュ方式)の場合のみ決定および登録する。
ステップ7では、キャッシュ管理部18において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を基に、キャッシュ次更新日時とキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部19に登録し(S207)、本シーケンスを終了する。ただし、キャッシュ削除日時については、Query-based Caching Method(クエリベースキャッシュ方式)の場合のみ決定および登録する。
(2)キャッシュの更新・削除タイミング
次に、キャッシュの更新・削除タイミングにおける場合の動作シーケンスについて図5および図6を用いて説明する。以下ではある一つのサービスに着目したシーケンスを示すが、複数のサービスがある場合は、これらのシーケンスを並列に処理するか、あるいは、あるサービスが終了してから次のサービスの処理を行えばよい。
(キャッシュの更新タイミング)
図5はキャッシュの更新タイミングにおける動作シーケンスを説明するフローチャートである。
ステップ1では、着目するサービスにおいて、サービス・メタデータ情報蓄積部19に登録されているキャッシュ更新日時を確認する(S301)。着目するサービスのキャッシュ方式がQuery-based Caching Method(クエリベースキャッシュ方式)の場合は登録クエリ毎に更新日時を確認し、All Caching Method(全キャッシュ方式)の場合は1つのみ登録されている更新日時を確認する。
ステップ2では、ステップ1で取得したキャッシュ更新日時が現在時刻を経過しているかどうかを確認し(S302)、経過していない場合は(NO)、本シーケンスは終了する。一方、キャッシュ更新日時を経過している場合は(YES)、ステップ3に移動する。
ステップ3では、メタデータ取得・更新要求部17において、更新単位(クエリベースキャッシュ方式の場合は登録クエリまたは全キャッシュ方式の場合はサービス)毎にメタデータの更新があるかどうかをメタデータ提供装置に対して確認する(S303)。メタデータの更新がある場合はステップ4に移動し、更新がない場合はステップ7に移動する。
ステップ4では、メタデータ収集速度決定部14において、メタデータの収集速度を決定する(S404)。
ステップ5では、ステップ4で決定したメタデータ収集速度、および収集メタデータ数に従って、メタデータ提供装置からメタデータを収集し、収集したメタデータの形式をメタデータ形式統一部12で統一して、サービス・メタデータ情報蓄積部19に蓄積する(S305)。All Caching Method(全キャッシュ方式)の場合は、差分のみを取得し、取得した差分をサービス・メタデータ情報蓄積部19に追加する。この差分は、新たなコンテンツのメタデータのみならず、既に存在するコンテンツについてメタデータ提供装置側で更新されたメタデータも含む。後者の場合はサービス・メタデータ情報蓄積部19に元々存在する更新前のメタデータは上書きされる。Query-based Caching Method(クエリベースキャッシュ方式)の場合は、クエリ毎のキャッシュ上限件数のメタデータを取得し、サービス・メタデータ情報蓄積部19に蓄積する。取得したメタデータと同一コンテンツのメタデータがサービス・メタデータ情報蓄積部19に既に存在する場合は、既に存在していたメタデータは上書きされる。
ステップ6では、キャッシュ更新頻度・時間決定部16において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定し、サービス・メタデータ情報蓄積部19に登録する(S306)。ただし、有効期間についてはQuery-based Caching Method(クエリベースキャッシュ方式)の場合のみ決定および登録する。
ステップ7では、キャッシュ管理部18において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を基に、キャッシュ次更新日時とキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部19に登録し(S307)、本シーケンスを終了する。ただし、キャッシュ削除日時については、Query-based Caching Method(クエリベースキャッシュ方式)の場合のみ決定および登録する。
(キャッシュの削除タイミング)
図6はキャッシュの削除タイミングにおける動作シーケンスを説明するフローチャートである。本動作シーケンスは、Query-based Caching Method(クエリベースキャッシュ方式)のサービスについてのみ行う。
ステップ1では、サービス・メタデータ情報蓄積部19に登録されているキャッシュ削除日時を登録クエリ毎に確認する(S401)。
ステップ2では、ステップ1で取得したキャッシュ削除日時が現在時刻を経過しているかどうかを確認し(S402)、経過していない場合は(NO)、本シーケンスを終了する。一方、キャッシュ削除日時を経過している場合は(YES)、ステップ3に移動する。
ステップ3では、キャッシュ削除日時を経過している登録クエリに対応するキャッシュ(メタデータ)を削除し(S403)、本シーケンスを終了する。
(3)ユーザからの検索クエリの発生
次に、ユーザから検索クエリがあった場合における動作シーケンスについて、図7を用いて説明する。
図7は、ユーザから検索クエリが発生した場合における動作シーケンスを説明するフローチャートである。
ステップ1では、図10に示すような検索画面においてコンテンツの検索条件と、検索対象サービスとを指定する(S501)。図10の例では検索条件として、ジャンルがスポーツ、キーワードがテニスとして指定され、また、検索対象サービスとして高品質VoDサービスと映像投稿サービスとが指定されている。検索条件としては、ジャンル、キーワードの他に、お勧めコンテンツや新着コンテンツといったプロモーション情報などであってもよい。検索条件と検索対象サービスとを指定した検索クエリがユーザインターフェース部11からキャッシュ管理部18に送られる。
ステップ2では、キャッシュ管理部18が、ステップ1で受けた検索クエリを基に、サービス・メタデータ情報蓄積部19において、指定されたサービス毎に、キャッシュメモリ方式を判断し、All Cashing Method(全キャッシュ方式)の場合は無条件にステップ5に進み、Query-based Caching Method(クエリベースキャッシュ方式)の場合は、以下に従う。すなわち、その検索クエリに含まれる検索条件に合致する登録クエリがサービス・メタデータ情報蓄積部19に登録されているかどうかを判定し、登録されている場合は(S502のYES)ステップ5に進み、登録されていない場合は(S502のNO)ステップ3に進む。
たとえば、サービス・メタデータ情報蓄積部19に図8および図9のようなサービス情報が登録されている場合、高品質VoDサービスの場合は、All Cashing Method(全キャッシュ方式)のため、ステップ5に移動する。一方、映像投稿サービスではキャッシュとして“ジャンル:スポーツ、キーワード:テニス”といった登録クエリのみ記憶されており、したがって、この登録クエリと同一の検索条件が指定された場合はステップ5に移動し、この登録クエリと異なる検索条件が指定された場合は、ステップ3に移動する。
ステップ3では、メタデータ収集速度決定部14において、メタデータの収集速度を決定する(S503)。
ステップ4では、キャッシュ管理部18はメタデータ取得・更新要求部17に対して、ステップ3で決定したメタデータ収集速度と、さらに収集メタデータ数(上位件数)、サービス情報(たとえばメタデータ取得用情報)とを送信し、メタデータ取得・更新要求部17はそれらの情報をもとに、メタデータ提供装置からメタデータの収集を行う(S504)。
ここでメタデータの取得に際して、検索結果をなるべく早く提示するという観点から、上記収集メタデータ数のメタデータをすべて取得した後に次のステップ5に移動するのではなく、必要最低限数のメタデータを取得した時点でステップ5に移動してもよい。たとえば、図11のように1画面に表示可能なメタデータ数が5件で、キャッシュ管理部18から要求された収集メタデータ数が500件の場合は、画面の遷移も考慮して20件取得したら、ステップ5に進み、残りのメタデータ480件(=500-20)は、検索結果を表示した後に順次取得してもよい。
ステップ5では、キャッシュ更新頻度・時間決定部16において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を決定して、サービス・メタデータ情報蓄積部19に登録し(S505)、ステップ6に移動する。ただし、キャッシュ有効期間の決定はクエリベースキャッシュ方式のサービスについてのみ行う。
ステップ6では、キャッシュ管理部18において、推奨更新頻度、推奨更新時間、キャッシュ有効期間を基に、キャッシュ次更新日時とキャッシュ削除日時を決定し、サービス・メタデータ情報蓄積部19に登録する(S506)。ただし、キャッシュ削除日時の決定および登録は、Query-based Caching Method(クエリベースキャッシュ方式)のサービスについてのみ行う。
ステップ7では、検索対象となるすべてのサービスについて、サービス・メタデータ情報蓄積部19からメタデータを取得する(S507)。すなわち、Query-based Caching Method(クエリベースキャッシュ方式)のサービスについては、検索条件にマッチする登録クエリに対応付けられたメタデータをサービス・メタデータ情報蓄積部19から取得し、All Cashing Method(全キャッシュ方式)のサービスについては、検索条件に合致するメタデータをサービス・メタデータ情報蓄積部19から検出して取得する。そして、ユーザインターフェース部11はサービス・メタデータ情報蓄積部19から取得したメタデータをマージして表示する(S507)。表示されたメタデータの一例を図11に示す。ここでマージ方法はどのようなものを用いてもよく、たとえば、日付順や名前順に表示されるようなマージ方法を用いることができる。
以上のように、本発明の実施形態によれば以下の効果を得ることができる。
(1)サービス毎にそのサービスに適したメタデータのキャッシュ方式を選択することで、効率的なメタデータのキャッシュが可能となる。
(2)キャッシュされたメタデータの効率的な更新が可能となる。たとえば需要の高いコンテンツのメタデータは概ね最新の状態に保ち、需要の低いコンテンツのメタデータについては無意味な更新を防ぐことが可能となる。
(3)メタデータ収集による受信端末の他アプリケーションへの影響を最小限に抑えることが可能となる。また、ネットワーク負荷やメタサーバ負荷を考慮したメタデータ収集速度を設定することで、外乱による影響を最小限に抑えることが可能となる。
なお、このメタデータ収集装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、ユーザインターフェース部、キャッシュ方式決定部、キャッシュ管理部、メタデータ収集速度決定部、キャッシュ更新頻度・時間決定部、端末・サーバ・ネットワーク負荷監視部、メタデータ取得・更新要求部は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、メタデータ収集装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、サービス・メタデータ情報蓄積部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の実施形態に係わるコンテンツ配信システムの構成を示すブロック図。 本発明の実施形態に係わるメタデータ収集装置の構成を示すブロック図。 メタデータ収集装置の起動時における動作例を示すフローチャート。 メタデータ収集装置の起動時における他の動作例を示すフローチャート。 キャッシュされたメタデータの更新時における動作例を示すフローチャート。 キャッシュされたメタデータの削除時における動作例を示すフローチャート。 ユーザからのメタデータ取得要求が発生した時における動作を示すフローチャート。 サービス・メタデータ情報蓄積部に蓄積されたサービス情報の例を示す図。 サービス・メタデータ情報蓄積部に蓄積されたサービス情報の例を示す図。 コンテンツ検索画面の例を示す図。 検索結果表示画面の例を示す図。 サービス一覧の例を示す図。
符号の説明
1〜3:ネットワーク
101:メタデータ収集装置
102a〜102e:メタデータ提供装置
11:ユーザインターフェース部
12:メタデータ形式統一部
13:負荷監視部
14:メタデータ収集速度決定部
15:キャッシュ方式決定部
16:キャッシュ更新頻度・時間決定部
17:メタデータ取得・更新要求部
18:キャッシュ管理部
19:サービス・メタデータ情報蓄積部
20:ネットワークインターフェース

Claims (12)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008247924A JP5238432B2 (ja) 2008-09-26 2008-09-26 メタデータ収集装置、ならびにその方法およびプログラム
US12/561,803 US8219556B2 (en) 2008-09-26 2009-09-17 Metadata collecting device, method and computer readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008247924A JP5238432B2 (ja) 2008-09-26 2008-09-26 メタデータ収集装置、ならびにその方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2010079641A JP2010079641A (ja) 2010-04-08
JP5238432B2 true JP5238432B2 (ja) 2013-07-17

Family

ID=42058610

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008247924A Expired - Fee Related JP5238432B2 (ja) 2008-09-26 2008-09-26 メタデータ収集装置、ならびにその方法およびプログラム

Country Status (2)

Country Link
US (1) US8219556B2 (ja)
JP (1) JP5238432B2 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011033565A1 (ja) * 2009-09-17 2011-03-24 株式会社 東芝 メタデータ収集装置
KR101199703B1 (ko) * 2010-04-12 2012-11-08 한국전자통신연구원 디스커버리 메타데이터 접근을 위한 방법 및 장치
JP5557192B2 (ja) * 2010-08-18 2014-07-23 住友電工ネットワークス株式会社 コンテンツ受信装置、コンテンツ配信システム、及びプログラム
US9854055B2 (en) * 2011-02-28 2017-12-26 Nokia Technologies Oy Method and apparatus for providing proxy-based content discovery and delivery
JP5809433B2 (ja) * 2011-04-06 2015-11-10 株式会社日立国際電気 送出システムのスタンバイ指示方法
CN102812458A (zh) * 2011-08-10 2012-12-05 华为技术有限公司 文件系统的挂载方法、装置及系统
RU2015118580A (ru) * 2012-10-19 2016-12-10 Токусима Юниверсити НОВЫЙ ВЫСОКО ФУНКЦИОНАЛЬНЫЙ ФЕРМЕНТ, ИМЕЮЩИЙ МОДИФИЦИРОВАННУЮ СУБСТРАТНУЮ СПЕЦИФИЧНОСТЬ β-ГЕКСОЗАМИНИДАЗЫ ЧЕЛОВЕКА И ПРОЯВЛЯЮЩИЙ УСТОЙЧИВОСТЬ К ПРОТЕАЗЕ
US10204170B2 (en) 2012-12-21 2019-02-12 Highspot, Inc. News feed
WO2014144905A1 (en) * 2013-03-15 2014-09-18 Highspot, Inc. Interest graph-powered feed
US10055418B2 (en) 2014-03-14 2018-08-21 Highspot, Inc. Narrowing information search results for presentation to a user
US9710434B2 (en) 2013-12-10 2017-07-18 Highspot, Inc. Skim preview
US9984310B2 (en) 2015-01-23 2018-05-29 Highspot, Inc. Systems and methods for identifying semantically and visually related content
US20180060133A1 (en) * 2016-09-01 2018-03-01 Amazon Technologies, Inc. Event-driven resource pool management
CN112448979B (zh) * 2019-08-30 2022-09-13 贵州白山云科技股份有限公司 一种缓存信息的更新方法、装置及介质
US11573937B2 (en) 2020-10-09 2023-02-07 Bank Of America Corporation System and method for automatically resolving metadata structure discrepancies

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4025379B2 (ja) * 1996-09-17 2007-12-19 株式会社ニューズウオッチ 検索システム
JP2003122773A (ja) * 2001-10-16 2003-04-25 Victor Co Of Japan Ltd メタデータ検索システム
JP2004102767A (ja) * 2002-09-11 2004-04-02 Nippon Hoso Kyokai <Nhk> メタデータ収集分配システム、メタデータ収集サーバ、メタデータ収集方法、メタデータ収集プログラム、及びメタデータ収集プログラムを記録した記録媒体
JP2004206629A (ja) * 2002-12-26 2004-07-22 Hitachi Ltd 異種データソース統合検索サーバシステム
US20040187151A1 (en) * 2003-03-21 2004-09-23 Dunstan Robert A. Method, apparatus and system for managing recorded personal video recorder content
JP2007329553A (ja) * 2006-06-06 2007-12-20 Funai Electric Co Ltd パーソナルコンピュータ及びコンテンツ管理機器
US20080010497A1 (en) * 2006-06-12 2008-01-10 Curtis Duane Kronlund Selecting a Logging Method via Metadata
JP5145719B2 (ja) * 2007-01-30 2013-02-20 ソニー株式会社 メタデータ収集システム、コンテンツ管理サーバ、メタデータ収集装置、メタデータ収集方法およびプログラム
JP2008204198A (ja) * 2007-02-20 2008-09-04 Skyit Corp 情報提供システム、及び、情報提供プログラム
US20100063878A1 (en) * 2007-05-02 2010-03-11 Nds Limited Retrieving metadata

Also Published As

Publication number Publication date
JP2010079641A (ja) 2010-04-08
US20100082622A1 (en) 2010-04-01
US8219556B2 (en) 2012-07-10

Similar Documents

Publication Publication Date Title
JP5238432B2 (ja) メタデータ収集装置、ならびにその方法およびプログラム
US11343351B2 (en) Content distribution network supporting popularity-based caching
US8230474B2 (en) User specified parallel data fetching for optimized web access
JP5612676B2 (ja) メディアコンテンツ読出しシステム及び個人用仮想チャンネル
US8347334B2 (en) System and method of recording television content
US11405685B2 (en) Efficient insertion of media items in media streams
US20070199041A1 (en) Video systems and methods of using the same
JP2004501556A (ja) 選択的ルーティング
US9378284B2 (en) System and method for displaying images and videos found on the internet as a result of a search engine
JP2003535396A (ja) Qosベースのコンテンツ配信ネットワーク
JP2004509485A (ja) リバースコンテンツハーベスタ
JP2004509381A (ja) 自己発行ネットワークディレクトリ
KR20140044883A (ko) 전자 프로그램 가이드를 캐싱하기 위한 시스템 및 방법
JP5433700B2 (ja) メタデータ収集装置
US8396868B2 (en) Information processing apparatus and information processing method
JP2004514961A (ja) コンテンツのトラッキング
JP2004508613A (ja) コンテンツ交換部へのコンテンツオブジェクトのプリロード
JP2007518335A (ja) 番組コンテンツを探索する方法
JP2004508614A (ja) コンテンツマネージャ
US20100238943A1 (en) Communication channel switch
CN110933447B (zh) 基于小前端环的分布式视频服务架构
JP2004511117A (ja) クライアント側アドレスルーティング解析
JP4255060B2 (ja) 付随情報管理方法、その装置、そのプログラム及び該プログラムを記憶した媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110325

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121005

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121203

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130305

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130401

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160405

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees