JP6062863B2 - 効率的な検索を可能にするためのサーバに基づくメディアコンテンツ及びｌａｎに基づくメディアコンテンツを集約する方法及び装置 - Google Patents

Description

この出願は、2010年11月19日に出願された“METHOD FOR AGGREGATING SERVER BASED AND LAN BASED MEDIA DICTIONARY FOR EFFICIENT SEARCH”という題の米国仮出願第61/415,468号の優先権を主張し、この全内容を援用する。

本発明は、概してコンテンツ管理システムに関し、特に効率的な検索を可能にするために複数のソースからのメディア資産（media asset）のディレクトリを生成する方法及び装置に関する。

コンテンツ／データは、如何なる数の異なるデバイスに格納されてもよい。しかし、様々なデバイスを通じてこのようなコンテンツを共有することは、場合によっては、ローカルネットワーク接続されたデバイスを通じてコンテンツ／データを共有することに限られる可能性がある。例えば、ホームネットワークでコンテンツ／データを共有するDLNA（Digital Living Network Alliance）の構想は、単にローカルエリアネットワーク（LAN：local area network）に存在する資産（asset）に基づく。

しかし、しばしば、コンテンツ／データがLANの外部のサーバから利用可能及びダウンロード可能になることが望ましいことがある。例えば、営利団体は、プロバイダにとって収益を生じるトランザクションモデルで、LANにストリーミング又はダウンロードされ得るメディアに対してポータル（portal）を利用可能にする手段を望んでいる。LANの外部の複数のソースからのコンテンツ／データを一元管理する一般的な方法は、コンテンツ／データを共通データベースにインポートし、サーバに基づくデータをローカルシステムに入れるために複製を利用することを含む。しかし、この手法は、コンテンツ／データを複数のクライアントに複製するために多すぎるネットワーク帯域幅及びサーバ計算リソースが必要になるというサーバ側のスケーラビリティ問題を有する。更に、このような手法は、クライアントが大規模な記憶容量を維持管理することを必要とし、このことは、現在の消費者用デバイスではコスト及び人間工学の観点から実現可能ではない。

別の利用可能な手法は、クライアントがコンテンツ／データを検索するために複数のポータルを訪問して検索することを必要とする。このことは時間がかかり、非効率的である。

本発明の実施例は、効率的な検索を可能にするために複数のソースからのデータ資産のディレクトリを生成する方法及び装置を提供することにより、従来技術の欠点に対処する。

本発明の一実施例では、効率的な検索を可能にするために複数のソースからのデータ資産のディレクトリを生成する方法は、ローカル及び外部のコンテンツディレクトリサービスインスタンスを発見し、発見されたコンテンツディレクトリサービスインスタンスの少なくとも１つのコンテンツと、発見されたコンテンツディレクトリサービスインスタンスを介して利用可能なコンテンツを識別するメタデータとを共通データベースに格納し、ユーザが発見されたコンテンツディレクトリサービスインスタンスを通じてコンテンツを検索できるように、ユーザインタフェースを提供することを含む。

本発明の別の実施例では、効率的な検索を可能にするために複数のソースからのデータ資産のディレクトリを生成する装置が提供される。

本発明の別の実施例による効率的な検索のための遠隔及びローカルのメディアディレクトリを集約するシステムのハイレベルなブロック図 ２つのデバイスの部分的なデータセットのソート結果 本発明の実施例によるビデオコンテンツの検索結果を集約するために定義されたビューのハイレベルなブロック図 本発明の別の実施例によるビデオコンテンツの検索結果を集約するために定義されたビューのハイレベルなブロック図 本発明の実施例による効率的な検索の実行を可能にするためにローカル及び遠隔のソースからのコンテンツを集約する方法のフローチャート 本発明の実施例による効率的な検索を可能にするためにサーバに基づくメディアコンテンツ及び情報とLANに基づくメディアコンテンツ及び情報とを集約するCMSデバイス600のハイレベルなブロック図

本発明の教示は、添付図面と共に以下の詳細な説明を考慮することで容易に理解できる。

図面は本発明の概念を例示する目的であり、必ずしも本発明を示すための唯一の可能な構成ではないことが分かる。理解を容易にするために、図面に共通の同一の要素を示すために、可能な場合には同一の参照符号が使用されている。

本発明は、有利なことに、複数のソースからのデータ資産のディレクトリを生成し、ルールに基づいてこのような資産の任意選択の優先順序付けを可能にする方法及び装置を提供する。主にDLNA（Digital Living Network Alliance）コンテンツ管理システム及びDLNA/UPnP CDS（Content Directory Service）コンポーネントに関して本発明について説明するが、本発明の特定の実施例は、本発明の範囲を限定するものとして扱われるべきではない。有利なことに、本発明の概念がDLNA及びCDSコンポーネント以外の他のフォーマット及びプロキシを使用してコンテンツを管理する如何なる商用又は住宅用環境にも適用可能であることが、当業者に明らかになり、本発明の教示により分かる。

図面に示す様々な要素の機能は、専用ハードウェアと、適切なソフトウェアに関連してソフトウェアを実行可能なハードウェアとの使用を通じて提供されてもよい。プロセッサにより提供される場合、機能は、単一の専用プロセッサにより提供されてもよく、単一の共有プロセッサにより提供されてもよく、いくつかが共用可能な複数の個々のプロセッサにより提供されてもよい。更に、“プロセッサ”又は“コントローラ”という用語の明示的な使用は、専らソフトウェアを実行可能なハードウェアを示すように解釈されるべきではなく、非限定的に、デジタルシグナルプロセッサ（DSP：digital signal processor）ハードウェア、ソフトウェアを格納するための読み取り専用メモリ（ROM：read-only memory）、ランダムアクセスメモリ（RAM：random access memory）及び不揮発性記憶媒体を暗示的に含んでもよい。更に、本発明の原理、態様及び実施例並びにその特定の実施例についてここで記載する全ての記述は、その構造的な等価物と機能的な等価物との双方を含むことを意図する。更に、このような等価物は、現在知られている等価物と、将来的に開発される等価物（すなわち、構造に拘らず同じ機能を実行するように開発されたいずれかの要素）との双方を含むことを意図する。

従って、例えば、ここに示すブロック図は、本発明の原理を使用した例示的なシステムコンポーネント及び／又は回路の概念図を示していることが当業者に分かる。同様に、いずれかのフローチャート、フロー図、状態遷移図、擬似コード等は、実質的にコンピュータ可読媒体に表され、コンピュータ又はプロセッサが明示的に示されていても示されていなくても、コンピュータ又はプロセッサにより実行されてもよい様々な処理を表すことが分かる。

本発明の一実施例では、本発明のコンテンツ管理システム（CMS：Content Management System）は、ローカルデバイスと、ローカルデバイス及びLANで発見されたDLNA準拠のデバイスのメディアコンテンツ及びメタデータを検索して格納する機能を備えたDLNAコントロールポイント（DLNA control point）とを提供する。本発明の一実施例では、コンテンツモデルの各ソースは、DLNA/UPnP CDS（Content Directory Service）であり、CDSの実装のためにUPnP委員会により定義されたサービスをサポートする。これは、検索、ブラウズ、ソート、順序付け、イベント通知、格納、コピー、削除及びデータモデル化を含む。このような主な機能は、ContentDirectory:3 Service Template Version 1.01 specificationに定義されており、これは、http://www.upnp.orq/specs/av/UPnP-av-ContentDirectorv-v3-Service.pdfに存在する。

前述のような実施例では、本発明のCMSは、CDSインスタンスの集約器を提供する。これは、どのCDSインスタンスが集約に含まれるかを定義する論理ビュー（logical view）を通じてCDSインスタンスを管理する。CMSからのサービス（例えば、検索／クエリ）の要求は、これらの論理ビューを通じて実行され、CMSは、CMSサービスの消費者が単一の制御エンティティ及びクエリからの結果セットと論理的に動作しているように、ビューの各CDSとのインタフェースの詳細を扱う。

図１は、本発明の実施例による効率的な検索のために遠隔及びローカルのメディアディレクトリを集約するシステム100のハイレベルなブロック図を示している。図１のシステム100は、例示的に、コンテンツ管理システム（CMS：content management system）102と、ビューマネージャ104と、データマネージャ106と、コントロールポイント108と、任意選択のルール適用器110とを有する。図１のシステム100では、CMS102は、コンテンツの検索に関心のある消費者用コンポーネントに対してAPIを提示する。CMS102は、ビューを公開して生成するための管理インタフェースを提供する。CMS102は、許可された場合には、コンテンツメタデータのための検索、更新及び削除インタフェースを提供する。CMS102は、DLNA CDS機能をサポートするためのAPIを実装する。様々な実施例では、CMSは、結果を要求側クライアントに提示する前に、結果セットを処理するために任意選択のルールコンポーネントを呼び出す。すなわち、CMS102は、ルールに基づいて収集された資産の任意選択の優先順位付けを可能にする。

図１のシステム100の実施例では、ビューマネージャ104は、コンテンツ階層／ビューを生成して管理し、これらに検索及び更新要求を適用する。ビューマネージャ104は、ビュー定義で呼び出されたコンポーネントへの接続を確立し、コンテンツをクエリの結果セットに入れるために又は更新を適用するためにコンポーネントを使用する。ビューマネージャ104は、コンテンツプロバイダのコンテンツ管理の方策を判定するために、ビュー定義を使用する。

システム100のデータマネージャ106は、メタデータ及びコンテンツディレクトリを格納するために使用される永続的な記憶装置を検索及び更新するためのコンポーネントへの抽象化（abstraction）を提示する。

CMS102は、LAN内に存在するDLNAデバイスを発見するために、コントロールポイント108（例えば、DLNAコントロールポイント）に依存する。コントロールポイント108は、（前述のように）全ての知られたコンポーネントのための共通インタフェースを提供する。CMS102は、LAN内の他のCDSインタフェースを発見し、DLNAスタック及び外部DMS109を通じて発見されたデバイスへの制御及びデータインタフェースを実装するために、コントロールポイント108を使用する。

任意選択のルール適用器110は、クエリ結果セットのデータ操作を実装する。ルール適用器110は、クエリ結果セットで動作するためにCMS102により実装され、CMS102は、処理された結果をそのユーザに渡す。すなわち、前述のように、CMS102は、ルールに基づいて収集された資産の任意選択の優先順位付けを可能にする。本発明の別の実施例では、システムは、定義された複数のルール適用器を有してもよく、どのルール適用器が適用されるべきか及びルールが適用されるべき順序を定義するCMSビュー定義が、結果セットを生成するために使用される。結果の検索セットに適用されるルールは、検索結果の提示順序又はどのコンテンツ／メタデータをユーザに提示するかしないかについてのルールを含んでもよい。

図１のシステム100は、例示的に図１にCMS102内に存在する共通データベース103にメディア及びメタデータを追加するために、既知のコンポーネントのためのAPIを提供するローカルコンテンツマネージャ112を更に含んでもよい。ローカルコンテンツマネージャ112は、埋め込まれたメタデータを抽出し、共通データベースへの画像ファイル／サムネイルのキャッシュのようなサービスを実行するために、メディアファイルをスキャンすることができる。本発明の一実施例では、メタデータは、DIDL-Lite形式にマッピングされ、永続的な記憶及びビュー管理のためにデータマネージャ106に提示される。このような実施例では、データマネージャ106は、コンテンツを更新、挿入及び削除する要求を受信し、変更されたコンテンツについてキャッシュ管理を実行するためにローカルコンテンツAPIを使用する。

図１のシステム100は、EPG、カメラ、USBドライブ等のような外部コンテンツプロバイダ又はサービスからコンテンツ及びメタデータを受信してもよい。このようなコンテンツプロバイダは、コンテンツプロバイダ・プラグイン116を提供する。コンテンツプロバイダ・プラグイン116は、デバイス種別又はサービス（EPG、カメラ、USBドライブ等）についての特化した認識を提供する。一実施例では、コンテンツプロバイダ・プラグイン116は、そのデバイスのコンテンツメタデータをDIDL-Lite形式に抽象化し、永続的な管理のためにデータをデータマネージャ106に提示する。コンテンツプロバイダ・プラグイン116は、デバイスが取り外された場合にコンテンツ及びその関連するメタデータを“オフライン”としてマーキング（mark）し、デバイスが再び取り付けられた場合にキャッシュされたデータを再び有効にして更新する機能を提供する。これは、キャッシュされたデータのパージ機能を提供する。

図１のシステム100では、コンテンツ管理システム102は、その公開されたAPIを通じてクライアントから検索要求を受け付ける。既知のコンポーネントは、そのAPIを通じて直接CMS102にアクセスする。外部のUPnPユーザは、関連するローカルのデジタルメディアサーバ（DMS：digital media server）114及びCDSプロキシ115を通じてプロキシされたようにCMS102を見る。既知のコンポーネントは、コンテンツの異なるビューを選択することができる。ただし、UPnPクライアントは、ビューの概念を有さず、初期設定ビューにより定義されたように結果を見る。前述のように、既知のコンポーネント／デバイスは、コンテンツ及び／又はメタデータが既に中央／共通データベースに格納されているコンポーネント／デバイスである。

図１のシステム100では、本発明のシステムの様々な機能を例示及び公開する際の助けとなるため、CMS102、ビューマネージャ104、データマネージャ106及びローカルコンテンツマネージャ112は、別々のコンポーネントとして示されている。しかし、本発明の別の実施例では、コンポーネント（CMS102、ビューマネージャ104、データマネージャ106及びローカルコンテンツマネージャ112）の１つ又は全ての機能は、検討されている単一のデバイス（一実施例では、本発明のCMS102）に実装されてもよい。更に、図１のシステム100では、共通データベース103は例示的にCMS102に存在するが、本発明の別の実施例では、共通データベース103は、別々のコンポーネントを有してもよく、或いは、図１のシステム100の他のコンポーネントに統合されてもよい。

例えば、本発明の実施例では、CMS102は、LANに基づくコンテンツ及びサーバに基づくコンテンツの効率的な検索を可能にするために、コンテンツ及びメタデータを共通データベースに集約する。より具体的には、本発明の実施例では、本発明のCMSは、全てのローカル及び外部のCDSインスタンスを発見し、LANに基づくコンテンツ及びサーバに基づくコンテンツの効率的な検索を可能にするために、コンテンツ及びメタデータを共通データベースに集約する。本発明の様々な実施例では、図１のEPG120及びVOD122のようなローカルのCDSインスタンスは、API又は関連するローカルのデジタルメディアサーバ（DMS：digital media server）114を通じて直接発見されてもよい。更に、本発明の一実施例では、CMSは、コンテンツメディア及びメタデータへの実際のインタフェースを実装するコンテンツプロバイダのプラグインコンポーネント（図１のプラグイン116等）を使用して外部のCDSを発見してもよい。プラグインのいくつかの例は、プログラムデータベース（Program Database）と、記録マネージャ（Recording Manager）と、様々な外部サービスとを含んでもよい。各プラグインは、CMSがコード化する独自仕様のAPIを有しており、プラグインから抽出されたデータを変換し、例えば一実施例ではSQLiteを使用して（以下に詳細に説明する）、このような情報を共通データベースシステムに格納することは、CMSの役目である。

本発明の様々な実施例では、CMSとインタフェース接続できるコンポーネントは、このようなコンポーネントがDLNA要求に対して公開されたビューに含まれる場合には、UPnP検索及びブラウズのシンタックスを実装する。コンテンツプロバイダのプラグインに加えて、実施例では、CMSは、図１のコントロールポイント108のようなDLNAコントロールポイントのコンポーネント（ローカルで実行する）とインタフェース接続することにより、外部のCDSインスタンスを発見してもよい。CMSは、外部のCDSデバイスを発見するためにコントロールポイントのデータモデルを使用し、これらのデバイスと情報及びデータを交換するためにコントロールポイントのインタフェースを使用する。

CDSインスタンスを発見することに加えて、CMSは、発見されたコンテンツディレクトリサービスインスタンスの少なくとも１つのコンテンツと、発見されたコンテンツディレクトリサービスインスタンスを介して利用可能なコンテンツを識別するメタデータとを共通データベースに格納する。本発明の一実施例では、本発明の共通データベースは、XQueryに基づくアクセス機構へのインデックスを生成する機能を有するXMLデータベースを有する。例えば、一実施例では、共通データベースは、Berkeley DB又はeXist XMLデータベースを有してもよい。しかし、Berkeley DBの対策を使用することについてコストの問題が存在し、eXistはJava SDKの実装を必要とする。

従って、好ましい実施例では、共通データベースはSQLiteデータベースを有する。SQLiteデータベースに格納されるメタデータは、リレーショナルモデルに非シリアル化（de-serialize）される。これは、検索及び順序付け（並び替え）の要求をサポートするためにインデックスを使用する利点を提供する。これは、全体のデータセットのシリアルスキャンの必要性を回避する。

データ及びメタデータの遠隔に位置する（サーバに基づく）レポジトリを含むシステム（VODシステム等）では、データ及びメタデータは取り込まれず、結果セットは別々に収集され、ローカルに収集された結果とマージされなければならない。共通データベースに格納できないメタデータでは、本発明のCMSは、このようなコンテンツプロバイダへのプラグインを通じてメタデータをクエリ検索することができる。本発明の一実施例では、CMSは、プラグインが対応するAPIを有さない限り、このようなプラグインでのメタデータの更新、削除又は生成をサポートせず、プラグインから抽出されたこのようなメタデータは、本発明のCMSを使用して検索するクライアントに対して、“読み取り専用”オブジェクトとして提示される。

従って、本発明のクエリ方策は、異なるプロバイダからデータを収集する必要性を考慮し、データは、以下の本発明の様々な実施例に従ってマージ、ソート及び順序付けされる。しかし、このことが行われる場合、複雑性が取り入れられる。この理由は、通常のアクセス方法では、マージされる結果セットは、部分的な結果セットであり、このことは、マージされた結果が正確であることを確保するための処理ロジックを必要とする。抽出された結果セットをリストのレコード番号Yで始まるX個のレコードに制限することは、UPnP要求動作における通常のやり方である。これは、図２に示すように、ソート／グループ化の問題の可能性を生じる。

すなわち、図２は、２つのデバイスの部分的なデータセットのソート結果を示している。図２の例では、デバイス1及びデバイス2は、アーティスト名でソートされたコンテンツについてクエリ検索される。データの各要求は5個のレコードに制限される。各デバイスから返信された結果セットは、図２に示す垂直方向のシーケンスにより示される抽出の相対順序で、5個のアイテムにグループ化される。図２の実施例では、デバイス1及びデバイス2の結果セット1からのコンテンツが単純にマージされた場合、消費者に返信される第１の結果セットは正確になる。しかし、図２に示すように、第２の要求は、“A”で始まる用語のデバイス1の結果の繰り返しを生じ、全体の結果スキャンで混乱及び不正確なソート順序を生じる。

従って、本発明の様々な実施例では、CMSは、データの正確な順序が提示されることを確保するために、クエリにおける各デバイスからの十分なデータを引き出す。このことは、出力結果セットのカウント境界に到達するまで、又は返信された値が他のデバイスからの項目により先行されることが明らかになるまで、CMSが複数の要求をデバイスに送信し、データを抽出することを必要とする。

本発明の様々な実施例では、データの位置は、検索、ソート及びフィルタリング動作が実行される手法にかなりの性能の影響を有し、この手法のいくつかについて以下に説明する。

＜多数のコンテンツがローカルに格納される場合＞
以下のシーケンスは、システムが、CMSを実行するシステムにおいてローカルのSQLiteデータベースに格納された多数のメタデータを有するユースケースについて記載する。ただし、プラグインデバイス又は外部のCDSインスタンスのデータ項目の数は比較的小さい。クエリ要求が受信された場合、処理時間は以下により最小化される。
1)小さい結果セットを共通データベース（例えば、SQLiteデータベース）にマージする。
2)データベースでクエリを実行する。
3)ソート及びグループ化動作（SQLite、格納された手順、ビュー）を実行するためにデータベースを使用する
4)消費者に対して結果セットを繰り返すためにクエリハンドルを使用する。

このようにクエリを実行することは、データベースの実装の内部の多数の性能上の機能を使用する。データベースは、必要なメモリ及びディスクI/Oを最小化するためにキャッシュ技術及びインデックスを利用する。

別の実施例では、XQueryが代わりに（XMLデータベースをサポートせずに）使用されてもよい。しかし、全体のデータセットに対する線形検索が実行され、結果が結果セットにコピーされる。すなわち、本発明の一実施例では、ソート及び順序付けは、メモリに存在するデータからのXQueryで実行されてもよい。これは、大規模なデータセットでは高コストになるデータのシリアルスキャン及びメモリのコピーを生じる。この手法は、データがクエリ結果の繰り返しで明示的に呼ばれた場合にのみコピーされるようなベクトルツリーを生成するSQLiteクエリよりも効率的ではない。XQueryでは、その開いたファイルのためのOSキャッシュを除き、キャッシュは存在しない。更に、XQueryの使用は、結果セットのカスタマイズ化された繰り返し及びデータマージの管理が構築されることを必要とする。しかし、或る用途では、検索使用モデルは、結果セットにおけるレコード数を制限するため（以下に詳細に説明する）、これは容認可能なトレードオフになり得る。

＜多数のデータが外部に格納される場合＞
データがCMSインタンスから遠隔にあるデバイスに存在する場合、検索処理のコストは、外部デバイスにより生じる。すなわち、本発明の一実施例では、所望のデータがネットワークから収集された場合、XQuery/XPathで検索するのに適した形式で、メモリに配置される。検索のためのインデックスの使用を得るために、このデータをローカルコンテンツのまばらに存在するデータベースに挿入するコストは正当化されないことがある。外部の結果をメモリのローカルコンテンツとマージし、XQuery動作を実行することは、最速の所要時間を提供し得る。

＜ハイブリッドの方策＞
前述のユースケースにおけるSQL又はXQuery処理モデルから示される利点／コストの衝突を考慮して、本発明の一実施例では、構成又は選択され得るデータをクエリ検索して処理するためにハイブリッド手法が実装される。選択される構成は、分散型又は集中型データ記憶モデルになる。

例えば、集中型モデルでは、データ記憶インタフェースは、ローカルの既知のデバイスからの全てのメタデータを単一のデータベースに集約する。LANの未知のCDSサービスを発見し、これらのメタデータのインスタンスを複製し、データを同期させ続けるためにUPnPイベント通知モデルを使用する“レプリケータ（replicator）”が存在する。

コンテンツの在庫資産（inventory）が大きすぎて現実的にデータベースに取り込むことができないVODプロバイダのようなコンテンツプロバイダでは、CMSインスタンスは、データベースから抽出された結果セットを複製されないプロバイダから収集された結果とマージする。

分散型モデルでは、集中型データベースへのコンテンツの取り込みは存在しない。CMSは、LANで見つかった全てのCDSインスタンスをクエリ検索し、結果セットをそのローカルで管理されているメタデータとマージする。すなわち、CMSインスタンスは、その構成から、有しているコンテンツプロバイダのセットを判定する。分散型データモデルで動作している場合、コントロールポイントは、LANにおけるCDSインスタンスを発見し、CMSがアクセスできるコンテンツプロバイダを認識できるように、これらのインスタンスを公開する。VODインスタンスのような特定の内部コンポーネント及び記憶マネージャは、これらの存在を登録し、CMSは、管理しているCDSインスタンスとしてこれらを含める。各CDSインスタンスはコンテンツディレクトリサービスのUPnP APIをサポートするクエリプロセッサとして扱う。CMSは、（前述のように、更に以下に説明するように）ビューにより定義された階層を通じてCDSソースからの全てのデータの集約を管理する。CMSは、単一の“仮想”CDSを用いて全てのCDSインスタンスで構成された初期設定ビューを生成する。CMS消費者は、コンテンツを構成するビューを選択的に定義してもよい。

分散型及び集中型データモデルの間の唯一の違いは、CMSインスタンスが管理するCDSインスタンスを公開するコントロールポイントを有さない点にある。保持された全てのデータは、記憶マネージャを通じてアクセスされる。このことは、VODインスタンスのようにデータベースに保持されていないメタデータソースを除いて、全てのメタデータが中央レポジトリからクエリ検索されることを可能にする。このアーキテクチャは、LANに多数のCDSインスタンスが存在し、全てのメタデータを単一のデータベースに集約するのに適したリソースが存在する場合には、コンテンツをクエリ検索するのに効率的になる。

本発明の一実施例では、コントロールポイントは、レプリケータコンポーネントとインタフェース接続するように構成される。レプリケータは、外部DLNAデバイスからメタデータを取り込み、これを他のメタデータと共に共有データベースにマージする。これは、データベースを同期し続けるために、発見したDLNAデバイスでのコンテンツの変更についてのイベント通知に申し込む。レプリケータは、自分を既知のデバイスとして識別したDLNAデバイスを発見した場合、そのデバイスとのコンテンツ複製／イベント通知モデルに入らない。既知のデバイスは、既にメタデータが中央データベースに格納されたデバイスである。

本発明の様々な実施例によれば、コンテンツの検索及びブラウズは、ユーザにユーザインタフェースを提供することにより実現されてもよい。本発明の様々な実施例では、このようなユーザインタフェースは、コンテンツの１つ以上のビューのグラフィック表示を有する。本発明の一実施例によれば、ビューは、コンテンツの階層表示を有する。ビューは、コンテンツを提示するために使用されるグループ化及びソート基準を定義する。一実施例では、ビューの定義は、XMLシンタックスで表され、CMSは、管理しているビュー定義のレポジトリを保持する。ビューノードは、階層のその分岐についてのデータのソースが制御され得るように、特定のCDSインスタンスに関連付けられる。一実施例では、ビューノードは、項目がノードの子として含まれるべきであるか否かを判定するために、コンテンツメタデータを使用する条件付ロジックにより定義される。一実施例では、ビューは、CDSデバイスを内部で管理されたコンテンツのみに制限してもよく、ビューの別の実施例は、発見された外部のDLNAデバイスを含めてもよく、ビューの別の実施例は、電子番組ガイド（EPG：electronic program guide）又はビデオオンデマンド（VOD：video on demand）に制限してもよい。本発明の実施例によれば、ユーザは、動作しようとするビューをどのように構築するかを判定してもよく、動的にビューを変更してもよく、複数のビューで同時に動作してもよい。

図３は、本発明の実施例に従って、例えば検索結果からの集約されたビデオコンテンツを提示するように定義されたビューのハイレベルなブロック図を示している。図３のコンテンツは、プレミアム、EPG、PVR及び個人用のカテゴリに構成される。図３の実施例及び例では、プレミアムノードの下位階層のみが示されている。他のビデオノードのカテゴリは、同様の階層ノード又は全く異なる階層ノードを有するように定義されてもよい。

図３の例の本発明の実施例を説明する目的で、例示的に、プレミアムのカテゴリは、サーバに基づくアプリケーションから生じており、EPG及びPVRのカテゴリはローカルDMSから生じており、個人用のカテゴリは、公開された一般的なDMSを有するPCから生じているものとする。図３の例示的なビューは、コンテンツの物理ソースと、要求に対する更に最適な応答時間を可能にするその論理表示との間の関係を有する。図３では、どのように検索が実行されるコンテンツ階層の位置に基づいてコンテンツプロバイダが要求処理から削除されるかが、明らかに示されている。このような動作は、階層ノードの色コーディングを使用して図３に示されている。

図４は、本発明の別の実施例に従ってビデオコンテンツ検索結果を集約するように定義されたビューのハイレベルなブロック図を示している。図４のビューは、異なるソースからのコンテンツが階層においてマージされるため、構成において論理的である。例えば、“ジャンル”のカテゴリでは、VODプロバイダ、ローカルコンテンツ及び外部DMSからのコンテンツは、メタデータに従って階層的に生成される。“新着”及び“提案”のソースは、VODサーバのみであるため、これらのノードは、特にVODからコンテンツを受信し、決してカテゴリの結果を返信しないCDSインスタンスへの検索／ブラウズ要求を送信しないように定義される。図４の実施例では、同じ構成が写真及びオーディオのカテゴリに当てはまる。

論理ビューセグメントは、複数のCDSインスタンスからのデータを組み合わせた階層の部分である。例えば図４では、“ビデオ／ジャンル”ノードは、VOD、ローカル及び外部DMSソースからのコンテンツを組み合わせるため、論理的である。本発明の一実施例では、このようなセグメントは、変更を妨げるためにDLNA制限特性を自動的に割り当てられる。更に、ビューノードは、ビュー定義XMLで制限された通りに手動で定義されてもよい。例えば、図４の“新着”ノードは、VODサービスがこのようなデータについてクライアントから更新を受け付けない場合、制限されるものとして定義されてもよい。

CDSインスタンスから提示されたデータ要素が階層でスロットを有さないようにビューのルールを定義することが可能である点に留意すべきである。例えば、ジャンルのノード定義が“アクション”、“スリラー”等のような値の別個のリストへのコンテンツメタデータからの一致する値に基づき、コンテンツ項目がリストにないジャンルの値を有する場合、コンテンツ項目はビューに現れない。これが意図した動作ではない場合、ノードのルール仕様は、別個のルール内で考慮されていない項目についてのワイルドカード（wildcard）ノードを有するべきである。

本発明の実施例では、ビューにおいて３つの種類のコンテンツプロバイダが存在する。

1)常に利用可能なCMSにローカルに格納されたコンテンツ
2)サーバに基づくコンテンツ又は大きすぎて（VODが一例である）キャッシュできないコンテンツ
3)オンライン及びオフラインになる可能性があり、キャッシュ可能であるが、可用性の状態が考慮されなければならない外部デバイスにあるコンテンツ
本発明の一実施例では、ビューを定義する場合、コンテンツプロバイダは、実装されるキャッシュの種別に関して分類される。ビューが構成された場合、キャッシュ可能なコンテンツ及び階層が保持され、そのソースプロバイダと同期し続けるためにDLNAイベント通知が使用される。プロバイダがオフラインになり、オンラインに戻ると、キャッシュは再同期されなければならない。プロバイダがオフラインである間にそのキャッシュは保持されるが、オフラインとしてマーキングされ、検索又はブラウズに利用可能ではない。プロバイダがオフラインになり、決して戻らなくなると、そのキャッシュは時間効果及び／又は空間の考慮に基づいて削除される。本発明の一実施例では、オフラインのプロバイダについてキャッシュされたデータは、ネスト化されたセットモデルとして表されたコンテンツ階層ツリーであり、コンテンツを記述するメタデータは、階層ツリーで参照される。

本発明の様々な実施例では、検索は、一時的な寿命での結果セットを生成し、結果セットは最終的に破棄される。結果セットは、検索コンテキストインスタンス（Search Context Instance）と呼ばれる。一実施例では、検索コンテキストインスタンスの寿命は、最初の検索要求から、同じコントロールポイントから異なる検索要求が受信されるまでである。検索コンテキストインスタンスは、実際のコンテンツ項目のContentID値への参照を含み、データ自体は含まない。本発明の検索コンテキストインスタンスは、（前述のように）ビューにより定義された構成及びソートルール毎に検索要求から抽出された仮想コンテンツ識別子を構成する階層データモデルである。仮想コンテンツ識別子及び階層については以下に説明する。

或いは、コンポーネントは、検索コンテキストインスタンスを消滅から救い、繰り返し／ブラウズのために再び有効にし、コンポーネントが複数の検索要求を同時に管理することを可能にしてもよい。初期設定の検索コンテキストインスタンスの消滅機構は、標準的なDLNA CDS要求の場面の背後で生じる拡張ビー処理を管轄しない外部のUPnPコントロールポイントを考慮する。

例えば、図３の実施例に戻り、検索の開始点として“ビデオ”ノードを指定する検索要求が受信された場合、要求は、“VOD”プロバイダに送信される。この要求は、ビューのキャッシュに適用され、“ビデオ”ノードを検索の開始点として指定し、結果セットは、検索コンテキストインスタンスを構築するためにマージされる。各プロバイダから適切なコンテンツを収集することに関する課題は、仮想ツリーが前述のように正確に生成されることを確保するため、十分なコンテンツがキャッシュされないプロバイダから引き出せることを要求する。このことは、ビューセグメントを正確に生成するのに十分なデータを収集するために、所与のプロバイダが単一の検索要求の繰り返し毎に複数回クエリ検索されることを潜在的に生じる。

適切な結果が検索要求を満たすように収集された場合、項目（item）及びコンテナ（container）（一実施例では、DIDL-Lite項目及びコンテナ）のDOMが構築される。ルールコンポーネントが導入されている場合、DOMは、ルールプロセッサに送信される。ルール処理が完了すると、DOMは、要求側のコントロールポイントに送信される。検索要求は繰り返されるため、キャッシュされないプロバイダから受信した増大するデータは、検索インスタンスデータとマージされ、結果はその検索要求パラメータ毎にコントロールポイントに分配される。検索コンテキストインスタンスは、コンポーネントの指示毎又は同じコントロールポイントからの新たな検索要求の受信毎に破棄される。

図１に戻り、前述のように、CMS102は、LANに基づくコンテンツ及びサーバに基づくコンテンツの効率的な検索を可能にするために、コンテンツ及びメタデータを共通データベースに集約する。すなわち、前述のように、本発明のCMSは、LANに基づくコンテンツ及びサーバに基づくコンテンツの効率的な検索を可能にするために、全てのローカル及び外部のCDSインスタンスを発見し、コンテンツ及びメタデータを集約する。CMSは、その公開されたAPIを通じてクライアントから検索要求を受け付ける。既知のコンポーネントは、そのAPIを通じて直接CMSにアクセスする。外部のUPnPユーザは、関連するローカルのデジタルメディアサーバ（DMS：digital media server）を通じてプロキシされたようにCMSを見る。既知のコンポーネントは、コンテンツの異なるビューを選択することができる。ただし、UPnPクライアントは、ビューの概念を有さず、初期設定ビューにより定義されたように結果を見る。例えば、図１では、既知の消費者／クライアント142は、例えば図３及び図４で前述したように、提供されたユーザインタフェース（例えば、階層論理ツリー）を使用して、そのAPIを通じて検索要求をCMS102に直接的に提示する。或いは、未知の消費者／クライアント144は、提供されたユーザインタフェース（例えば、階層論理ツリー）を使用して、ローカルDMS146を介して検索要求をCMS102に提示する。

いずれの場合も、消費者から受信した検索要求は、消費者のビューに登録されて含まれる各CDSインスタンスに送信される。例えば、このような場合、それぞれの検索はCDSインスタンスにより個別に処理され、結果セットは、CMSにより管理されたコンテンツ及びメタデータデータベースから収集された結果と共に、単一のドキュメントオブジェクトモデル（DOM：document object model）に集約される。本発明の実施例では、個々のコンポーネントの実装に任せることにより、リソースの最も賢明な使用が実現される。このような実施例では、コンポーネントは、生成した結果セットが集約DOMに処理されるためにCMSにコピーされ、データ要求／繰り返しシーケンスにおいて検索処理を１回のみ適用する対策を実装すべきであり、クエリ検索を処理するためにできるだけリソース消費が最小化されるべきであることを認識している。

本発明の実施例では、CDSインスタンスから抽出されたデータは、DIDL-Lite準拠のXMLドキュメントである。各項目は、コンテンツプロバイダにより割り当てられた固有の識別子を有する。各プロバイダからの結果は、単一のデータセットに集約される。集約セットの各項目は、固有の識別子を有さなければならない。識別子は、コンテンツプロバイダにより項目に割り当てられた固有の識別子に戻って参照できる結果セットにおいて固有の識別子を維持するように仮想化される。

本発明の様々な実施例では、CMS消費者からの検索要求は、返信するレコード数を制限し、結果セットでの繰り返しを制限する。CMSは、コンテンツプロバイダに対して、その消費者により要求されたソート順に結果を提示するように指示する。検索動作と同様に、コンテンツプロバイダは、結果セットでのCMSの繰り返しの寿命において１回のみ結果セットでソートを実行する。CMSは、フェッチの繰り返し毎に、異なるコンテンツプロバイダからの結果をソートされたリストにマージする。

本発明の一実施例では、ビューの仕様はXMLドキュメントであり、処理ロジックは、XML階層を上から下及び左から右に追従する。データの要求は、コンテンツセグメントが宣言された階層の点において、宣言されたデータソースに送信される。構築されたクエリは、コンテンツ宣言について階層のそれぞれの先祖のノードで宣言された全ての一致する仕様を反映する。XMLがグループを指定する場合、これはDIDL-Liteコンテナとして扱われる。コンテナ名（タイトル）は‘名前’属性によってXMLで静的に宣言される。或いは、‘derivedName’属性が宣言された場合、コンテナ名は、グループについて指定された一致条件を満たすコンテンツ項目の指定の特性から抽出される。XMLがコンテンツセグメントを指定する場合、クエリが構築され、階層パスで宣言されたそれぞれのキャッシュされないデータソースに送信される。これらのクエリからの結果は、適用されるビュー仕様で指定された順序ルールを用いて結果セットに構成される。

ビュー階層テーブルは、コンテンツ宣言毎のコンテンツ項目の順序付けされたセットと、結果セットに挿入されるコンテンツ項目データとを取得するためにクエリ検索される。マージ及び順序付けがキャッシュされない階層でキャッシュされた階層からの結果である場合、集約の適切な順序が維持されることを確保するために、キャッシュされないデータソースへの更なるクエリ検索が必要になる可能性がある。構築された結果セットは、次の繰り返しの管理のために保持される。新たな検索要求が受信された場合、結果セットは破棄される。キャッシュされないデータソースにクエリを発行する場合、更なるオーバーヘッド及び遅延が存在する。キャッシュされないデータソースへの参照を、データを返信する階層の点に制限するために、ビュー定義において検討が行われるべきである。例えば、データソースがオーディオコンテンツのみを提供する場合、階層のルートでキャッシュされないデータソースを宣言することは非効率である。

図５は、本発明の実施例に従って効率的な検索の実行を可能にするためにローカル及び遠隔のソースからのコンテンツを集約する方法のフローチャートである。図５の方法500は、ステップ502で始まり、ステップ502の間に、全てのローカル及び外部のCDSインスタンスが発見される。例えば、前述のように、ローカル及び外部のCDSインスタンスの発見は、データ及び情報を交換するためのローカルのコンテンツディレクトリサービスデバイスとの直接の通信、データ及び情報を交換するためのローカルのデジタルメディアサーバを使用したローカルのコンテンツディレクトリサービスデバイスの識別、外部のコンテンツディレクトリサービスデバイスとデータ及び情報を交換するためのローカルのコントロールポイントのコンポーネントデータモデル及びコントロールポイントのインタフェースの使用、及びコンテンツプロバイダのプラグインデバイスのコンテンツ及びメタデータへのインタフェースを実装するためのコンテンツプロバイダのプラグインデバイスのAPIの使用のうち少なくとも１つを含んでもよい。次にこの方法500はステップ504に進む。

ステップ504において、発見されたCDSインスタンスの少なくとも１つのコンテンツ及び発見されたCDSインスタンスで利用可能なコンテンツを識別するメタデータは、共通データベースに格納される。前述のように、本発明の一実施例では、共通データベースは、検索を可能にするためのインデックスの使用を提供する非シリアル化されたデータベースを有する。次にこの方法500はステップ506に進む。

ステップ506において、ユーザが発見されたCDSインスタンスを通じてコンテンツを検索できるようにユーザインタフェースが提供される。前述のように、本発明の一実施例では、ユーザインタフェースは、階層ツリーの形式になってもよい論理ビューを含んでもよい。次にこの方法は任意選択のステップ508に進んでもよく、終了してもよい。

任意選択のステップ508において、クエリ結果セットのカスタムのデータ操作を実装するルールが、検索結果セットに適用される。本発明の一実施例では、このようなルールは、検索結果を検索要求者／ユーザに提示する前に適用される。次にこの方法500は終了してもよい。

図６は、本発明の実施例に従って効率的な検索を可能にするためのサーバに基づくメディアコンテンツ及び情報とLANに基づくメディアコンテンツ及び情報とを集約するCMSデバイス600のハイレベルなブロック図を示している。より具体的には、図６のCMSデバイス600は、例示的に、プロセッサ610と、制御プログラム、ファイル情報、格納されたメディア等を格納するメモリ620とを有する。CMSデバイス600は、電源、クロック回路、キャッシュメモリ等のような従来のサポート回路630と、メモリ620に格納されたソフトウェアルーチンを実行する際に支援する回路と共に協調動作する。従って、ここに記載のいくつかの処理ステップは、例えば、様々なステップを実行するようにCMSデバイス600と協調動作する回路として、ハードウェア内に実装されてもよいことを意図する。CMSデバイス600はまた、CMSデバイス600と通信する様々な機能要素とのインタフェースを形成する入出力回路640を含む。

ここでも同様に、図６のCMSデバイス600は、本発明に従って様々な制御機能を実行するようにプログラムされた汎用コンピュータとして示されているが、本発明は、例えばASIC（application specified integrated circuit）としてハードウェアに実装されてもよい。従って、ここに記載した処理ステップは、プロセッサにより実行されるソフトウェア、ハードウェア又はこれらの組み合わせで同等に実行されるものとして広く解釈されることを意図する。更に、図６のCMSデバイス600は別々のコンポーネントとして示されているが、ここに記載した本発明の概念及び実施例に従ったCMSデバイス600の機能は、セットトップボックス、パーソナルビデオレコーダ、デジタルビデオレコーダ又はコンテンツプロバイダのサーバ等のような既存のコンテンツ管理システムのコンポーネントに統合されてもよい。

効率的な検索を可能にするためにサーバに基づくメディアコンテンツ及び情報とLANに基づくメディアコンテンツ及び情報とを集約する方法及び装置の様々な実施例について説明したが（これらは例示的であり、非限定的でない）、前述の教示を鑑みて変更及び変形が当業者により行われてもよいことに留意すべきである。従って、本発明の範囲及び要旨内にある変更は、開示された本発明の特定の実施例において行われてもよいことが分かる。前述のものは、本発明の様々な実施例を対象としているが、本発明の他の実施例又は更なる実施例は、その基本的概念を逸脱することなく考案されてもよい。

Claims (15)

1. ローカル及び外部のコンテンツディレクトリサービスインスタンスを発見するステップと、
   発見されたコンテンツディレクトリサービスインスタンスを、構成において論理的なビューに集約するステップであり、異なるソースからのコンテンツがマージされるステップと、
   前記構成において論理的なビューの前記コンテンツディレクトリサービスインスタンスのそれぞれのコンポーネントへの接続を確立するステップと、
   前記構成において論理的なビューの前記コンテンツディレクトリサービスインスタンスを介して利用可能なコンテンツを識別するメタデータを共通データベースに格納するステップと、
   ユーザが前記共通データベースに格納された前記メタデータを使用して、前記コンテンツディレクトリサービスインスタンスのコンテンツを検索することができるユーザインタフェースを提供し、接続が確立されたコンポーネントから検索結果を受信し、検索結果を生成するために前記受信した検索結果のセットをマージするステップと
   を有し、
   前記共通データベースに格納できないコンテンツ及びメタデータは、前記検索中に別々にソートされて並び替えられる方法。
2. ローカルのコンテンツディレクトリサービスインスタンスを発見することは、データ及び情報を交換するために、ローカルのコンテンツディレクトリサービスデバイスと直接通信することを有する、請求項１に記載の方法。
3. ローカルのコンテンツディレクトリサービスインスタンスを発見することは、データ及び情報を交換するために、ローカルのデジタルメディアサーバを使用してローカルのコンテンツディレクトリサービスデバイスを識別することを有する、請求項１に記載の方法。
4. 外部のコンテンツディレクトリサービスインスタンスを発見することは、外部のコンテンツディレクトリサービスデバイスとデータ及び情報を交換するために、ローカルのコントロールポイントのコンポーネントデータモデル及びコントロールポイントのインタフェースを使用することを有する、請求項１に記載の方法。
5. 前記共通データベースは、検索を可能にするためのインデックスの使用を提供する非シリアル化されたデータベースを有する、請求項１に記載の方法。
6. 前記生成された検索結果及びローカル検索結果は、ソートされて並び替えられた、前記共通データベースに格納されたコンテンツ及びメタデータとマージされる、請求項１に記載の方法。
7. コンテンツプロバイダのプラグインを介して前記共通データベースに格納できないコンテンツ及びメタデータをクエリ検索するステップを有する、請求項１に記載の方法。
8. 前記構成において論理的なビューは、階層ツリー図を有する、請求項１に記載の方法。
9. プログラムルーチン及びデータを格納するメモリと、
   前記プログラムルーチンを実行するプロセッサと
   を有し、
   前記プロセッサは、前記プログラムルーチンを実行した場合、
   ローカル及び外部のコンテンツディレクトリサービスインスタンスを発見するステップと、
   発見されたコンテンツディレクトリサービスインスタンスを、構成において論理的なビューに集約するステップであり、異なるソースからのコンテンツがマージされるステップと、
   前記構成において論理的なビューの前記コンテンツディレクトリサービスインスタンスのそれぞれのコンポーネントへの接続を確立するステップと、
   前記構成において論理的なビューの前記コンテンツディレクトリサービスインスタンスを介して利用可能なコンテンツを識別するメタデータを共通データベースに格納するステップと、
   ユーザが前記共通データベースに格納された前記メタデータを使用して、前記コンテンツディレクトリサービスインスタンスを通じてコンテンツを検索できるように、ユーザインタフェースを提供し、接続が確立されたコンポーネントから検索結果を受信し、検索結果を生成するために前記検索結果のセットをマージするステップと
   を実行するように構成され、
   前記共通データベースに格納できないコンテンツ及びメタデータは、前記検索中に別々にソートされて並び替えられる装置。
10. 前記メモリは、共通データベースを有する、請求項９に記載の装置。
11. 前記共通データベースは、検索を可能にするためのインデックスの使用を提供する非シリアル化されたデータベースを有する、請求項１０に記載の装置。
12. 前記装置は、データ及び情報を交換するために、公開されたAPIを使用してローカルのコンテンツディレクトリサービスデバイスと直接通信する、請求項１０に記載の装置。
13. 前記装置は、ローカルのコンテンツディレクトリサービスインスタンスとデータ及び情報を交換するために、ローカルのデジタルメディアサーバと通信する、請求項１０に記載の装置。
14. 前記装置は、外部のコンテンツディレクトリサービスデバイスとデータ及び情報を交換するために、ローカルのコントロールポイントのコンポーネントデータモデル及びコントロールポイントのインタフェースを使用する、請求項１０に記載の装置。
15. 前記検索結果及びローカル検索結果は、ソートされて並び替えられた、前記共通データベースに格納されたコンテンツ及びメタデータとマージされる、請求項１０に記載の装置。

Images