JP2010524126A - メディアの生成及び配布を行うための方法及びコンピュータプログラム - Google Patents

Abstract

メディアを生成及び配布する改善されたデータベースシステム及び方法は、外部の固有のIDを用いてアセットを集約可能にする。外部のIDを利用することは、実際のデータベースに関する如何なる予備知識もなしに、メディアアセット管理データベースのサーチが実行可能であるようにする。検索条件は、条件設定段階でサーチデータベースに取り込まれる一群のサーチ環境パラメータを規定し、これはサーチサービスにより使用され、問い合わせを生成、確認及び実行するためのインターフェースをクライアントアプリケーションに与える。

Description

本発明はネットワークを介してコンテンツを管理及び配布するシステム及び方法に関連する。特に、本発明は、メディアを生成及び配布する際、様々なアプリケーション間の同期及びメタデータの集約をサポート及び処理するシステムに関連する。

メディア産業界における、特定のアセット管理（資産管理、資源管理）の要請に対処する研究開発は、様々なレベルのワークフロー管理サポート機能を備えたメディアアセット管理（MAM: Media Asset Management）用のグローバルな手段を目指すことに収束しつつある。これらの対応策は次のようなものを含む：
１）プレイアウトオートメーションシステム（Playout Automation System）
今日、プレイアウトオートメーション技術は、スケジュールにしたがってビデオ及びオーディオのコンテンツを再生する装置をリアルタイムに制御する機能をもたらす。あるプレイアウト技術は、受信又は取込サーバにおいて及び保存の段階において、コンテンツの移動を行う要請に応じる。プレイアウトデバイスのプロバイダは、デバイスインターフェースに関する専門性（能力のあること）を見せてきたが、ワークフローエンジンをサポートすることにも発展しつつある。現在、プレイアウトオートメーションによる対応策（ソリューション）は、静的なワークフローを提案するものであり、コンフィギュレーションの段階でかなりの作業のやり直しが必要となってしまう。

２）文書アセット管理のプロバイダは、印刷媒体を提供しており、文書を管理する際の優位性を実証してきた。この種の多くのプロバイダは、マルチメディア環境に進出し、メディア産業に取り組みつつある。一般に、これらのプロバイダには、デバイスのリソースをリアルタイムで管理する能力に乏しく、彼らのオートメーション対応策は、ワークフローを限られた方法で管理する余裕しかない。

３）ビデオ編集システム
ビデオ編集システムを提供する幾つかの方法が存在し、その内の少なくとも１つはメディア産業に対する非線形ワークフローの対応策を導入しているが、それは静的な方法でワークフローを管理する機能を提供するに過ぎない（動的な方法ではない。）。

４）ITミドルウエアサプライヤ
概して、ITミドルウエアのプロバイダは、ワークフローを処理するトランザクションレイヤを管理するために、特殊なビジネスレイヤのアプリケーション及び関連するインフラストラクチャを提案している。実際、そのようなサプライヤはビジネスレイヤに着目しているので、彼らの対応策はユーザインターフェースを提供しないし、負荷バランスやサービス品質条件とともにリソースを制御できない。

本発明の課題は、改良されたメディア生成及び配布法をサポートするデータベースシステムを提供することである。

概して、好適実施例によれば、改良されたメディア生成及び配布法をサポートするデータベースシステムが提供される。データベースシステムは、編集決定リスト（EDL: Edit Decision List）、再生リスト（Play List）及びアセットに関する仮想エッセンス等の概念を使用する。さらに、データベースシステムは、アセットグループ（group of asset）の概念を使用し、アセットグループは、共通の処理が規定されるエンティティ階層において、複数のアセットをシステムが集約することを可能にする。

サーチエンジンに対応づけを行う本発明原理による実施例におけるデータベースシステムのブロック図。 本発明原理による実施例におけるサンプルデータプロバイダのデータベース例を示す図。 本発明原理による実施例におけるアセットグループを示す図。 本発明原理による実施例における仮想エッセンスを示す図。 本発明原理による実施例における仮想エッセンスを示す図。 固有のアセットIDをカプセル化する本発明原理による実施例におけるデータ集約方法を示す図。 本発明原理による実施例における検索方法の概要を示す図。 リレーショナルデータベースを使用する場合の本発明原理による実施例における検索条件の概念例を示す図。

一実施例によれば、メディアの生成及び配布をサポートする改善されたデータベースシステムを利用する方法が提供される。本方法は、各アセットに対応するアプリケーションの外部の特定の識別子を、アセット群各々の中にカプセル化するステップと、所与のアプリケーションについてのアセット群を、該アプリケーションに対する前記特定の識別子を使用して要求し、該特定の識別子に関するアセットを特定する要求ステップとを有する。

前記カプセル化するステップは、ある固有のIDを前記特定の識別子としてアセット各々に割り当てるステップと、各アセットに対する前記特定の識別子を使用して、メディアアセット管理データベースにアセットテーブルを形成するステップとを含んでもよい。該形成するステップは、前記特定の識別子を使用して、前記メディアアセット管理データベース内に仮想アセットアドレスを設定するステップを含んでもよい。

前記要求ステップは、1つ以上のサーチ環境パラメータを決定するステップと、決定したパラメータを、検索条件を構築する際にサーチデータベースに取り込むステップとを含んでもよい。1つ以上のサーチ環境パラメータを決定するステップは、各アセットに対応するメタデータの記述を特定するステップを含んでもよい。

別の実施例による方法は、ユーザの検索要求に応答して、少なくとも2つのデータソースからの検索結果の同期をとるステップと、前記ユーザの検索要求に応答して、検索条件を設定するステップと、前記少なくとも2つのデータソースからの同期させた検索結果を集約するステップであって、該集約は、アセット各々に対応するアプリケーション各々について固有の識別子を割り当てることを含む、ステップと、集約された検索結果を1つの検索結果として前記ユーザに提示するステップとを有する。前記の集約は、各アプリケーションについて割り当てられた固有の識別子をカプセル化することで、データベース内にアセットテーブルを形成することを含んでもよい。前記の設定は、検索条件に含まれるサーチ環境パラメータを決定することをさらに含んでもよい。該決定は、各アセットに関するメタデータの記述を特定することを含んでもよく、前記ユーザの検索要求は、前記検索条件を設定する際に前記メタデータの記述を利用して、あるデータベースについて動的に作成される。

別の実施例によれば、前記サーチ環境パラメータは、前記検索要求に応答して、前記検索条件の構築の際にサーチデータベースに取り込まれ、該検索要求を生成、確認（有効化）及び実行するインターフェースをクライアントアプリケーションに与える。

以下、1つ以上の実施例の詳細が添付図面と共に説明される。或る特定の方法で説明されるが、実施例は様々な方法で構築又は実現されてもよいことは明らかであろう。例えば、実施例は方法として実行されてもよいし、又は一群の処理を実行する装置、若しくは一群の処理を実行する命令を記憶する装置として実現されてもよい。他の形態や特徴は、明細書、図面及び特許請求の範囲の記載によりさらに明らかになるであろう。

図中、同様な参照番号は同様な要素を示す。

本発明原理によるデータベースシステムは、メディアの生成及び配布に関する様々なアプリケーションの中で、メタデータの集約又はアグリゲーション（aggregation）及び同期に関する問題に対処する。データベースシステムは、アセット抽象化（abstraction）において固有の識別子（UID）のカプセル化を許容することで、問題を解決する。

さらに、本発明原理によるデータベースシステムは、複数のソース（データベース、ファイル、サイト）から情報を効率的に検索及び集約することを可能にするサーチ方法をもたらす。本発明原理によるデータベースシステムの別の顕著な特徴は、僅かなコンフィギュレーション変更とともに、如何なるソースコードの変更も要求せずに、如何なるデータベースについてもサーチできることである。

放送環境及び撮影後の編集環境に現在配備されている設備（インフラストラクチャ）を改善するため、本発明原理によるデータベースシステムは、従来の方法では取り組まれていない特定の多くの問題に対処するメタデータをサポートする。例えば、本発明原理によるデータベースシステムは、仮想アセットアドレス（virtual asset address）をサポートする。

グローバルなメディアアセット管理（MAM）による解決策は、エッセンス及びメタデータを適切にパッケージにすることができず、その欠点は本データベースシステムにより克服される。本データベースシステムは、そのデータベースに存在しないメタデータをも処理できる。この問題については、本データベースシステムは、複数のIDを使用し、多数のアセットを管理する能力を或る論理エンティティに用意することで解決される。現在のデータベース検索法は、データベースシステムが理解できる所定の検索の構成（検索条件）（search configuration）にユーザが編集し直すことを要する。本発明原理によるデータベースシステムは、サーチエンジンへの対応付けが可能な外的な方法（external scheme）をユーザが定義できるようにする。

図1Aに示されるように、本発明原理によるデータベースシステムは、データプロバイダ10の概念を活用し、その概念に基づいて、一般的なソースからのデータは、メディアアセット管理（MAM）データベース内で公開され（published）、かつアセットや他のエンティティ（例えば、エッセンス及びグループ）に関連付けられることが可能である。図1Aに示されているように、公開されるデータの構造を特定することで、新たなデータプロバイダ12が動的に生成される。この説明は、公開される全てのメタデータフィールドを、各自の属性と共に包含し、属性は、とりわけ例えば、名前、形式（タイプ）、場所（ロケーション）、メタデータフィールドが検索可能であるか否か、順序付け可能であるか否か、暗号化されているか否か等を含む。個の情報は、メタデータ情報14として保存され、サーチ16のような他のサービスにより使用される。

図1Bは、サンプルデータプロバイダのデータベース例を示す。データプロバイダと、（ObjectID、ObjectTypeID）のような対で規定される要素（entity）との間には、暗黙の関連性がある。例えば、データプロバイダがアセットのデータを公開する場合、オブジェクトタイプID（ObjectTypeID）が、アセットタイプ（Asset type）に一意に識別され関連付けられることになる。プロパティ（Properties）のカラムは、メタカラム（meta-column）であり、データプロバイダのプロパティ（属性）の大部分を格納する。実際上、全てのデータプロバイダの構造は同じであり、唯一の相違はプロパティのカラムであり、これはデータプロバイダのタイプに応じて異なる。データベースは、プロパティのカラムに含まれる全ての動的なプロパティ関連情報を保存する。

従来のコンテンツ管理法と比較すると、本発明原理によるデータベースシステムは、処理ワークフローに着目したソリューションにより、コンテンツ及びアセットの管理を可能にし、以下の特徴を提供する：
＿ 動的なユーザインターフェースのタスクベース。各ユーザが、彼らのタスクを記述できるようにし、マニュアルにより又は自動的に、コンテンツとアセットをリンクする固有の方法により、彼らのタスクを実行するのに必要なリソースを使用できるようにする。

＿ 優れたMAM構造。この構造は、複雑なメディア作成環境でセントラル化されたサーチを管理するのに充分な程度の抽象化（アブストラクション）をもたらす。

＿ アセットの論理要素グループを管理する機能を備えたコンテンツアグノスティック（Content Agnostic）ソリューション。

ディジタルメディア製作の進展には、多くの複雑なデータを統合及び管理する必要がある。その結果、ディジタルデータを表現、集約及び管理する新たな技術が登場してきた。共通語（common vocabulary）の必要性は、データの命名、表現及び保存に関する標準化に至る。

ディジタルメディア管理の要旨はディジタルアセットの概念であり、概してこれは、あるメディアで公開可能であって所有者が使用権を有する値の要素（entity of value）として定義される。実用上、アセットは情報の単なる集まりであり、例えば、ディジタルアセットの場合、メタデータに加えてビデオやオーディオファイル（エッセンスとして言及される）に対するリファレンスを含むことが可能な枠組み（shell）である。当業者は、「メタデータ」の基本的な定義が、データに関するデータであることを認識している。

以下、本発明原理による概念及びフレームワークを説明する。本発明原理は、メディアアセット管理における言葉（vocabulary）を増補し、当該技術分野で通常遭遇する問題に対する解決策をもたらす。これら全ての解決策は、MAMシステムコアにおけるデータベースシステムを改善することで達成される。

アセットグループ
図1Cは、アセットグループ（Group of Asset）100を示す。アセットグループ100は、メタデータ及び処理が定義されている階層構成要素においてアセットを集約する手段を提供する。アセットグループ100は、複数のアセット102、104、又は一群のアセット106を含み、これらは全て管理要素（administrative entity）として処理される。例えば、各アセットは、(a)アセット102へのアクセスを指図する権利（権利情報）108、(b)アセットメタデータ110、(c)コンテンツ112、及び(d)エッセンス114等を含む。コンテンツ112は、メタデータ記述も含む。

アセットグループ100について、いくつもの処理があり得る。そのような処理は、特に、保存、転送及び削除を含む。実際上、エッセンスが特定のDVD内にある全てのアセットは、一緒にグループ化することが可能である。アセット106はその一例であり、アセット3、アセット4及びアセット5が一緒にグループ化されている。関連要素（relational entity）として、アセットグループ100は、自身に固有のIDを有し、関連するメタデータ及び特定の権利（情報）を有する。実施例の場合、各アセットは、システムにより発見又は生成された際に、関連するIDを有するべきである。

仮想エッセンスとしてのプレイリスト及び編集判定リスト（EDL）
アセットは多数のエッセンスに結び付けられることが可能であり、エッセンスは、アセットのコンテンツ又はコンテンツの一部を表現するものである。一般に、「原（raw）」メディアファイル、すなわち画像及び/又はオーディオを表現するバイトを含むファイルに言及する場合、「エッセンス（essence）」という用語が使用される。

図2A及び2Bは、編集及び送信/配布の環境におけるアセット例200、210をそれぞれ示す。

編集環境（図2A）の場合、（アセット200における）編集タスクの結果は、EDL202により表現可能であり、これは実際のエッセンス204に対するリファレンスを含む。EDLはあるプロセスにより実行可能であり、そのプロセスは、タスクの成果のエッセンス（原メディアファイル）を生成する。

同様に、送信/配布の環境の場合、複数のエッセンスが時系列に沿って置かれ、プレイリスト212として言及されている要素になる。

EDL及びプレイリストは仮想エッセンスとして言及され、アセット200及び210にそれぞれ関連付けられる。EDLは、1つ以上のメディアの中で一連のセグメント（セグメントのシーケンス）を指すポインタのリストである。そのようなメディアをエッセンスとして取り扱うことは、システム内の論理要素のように操作を簡易にする。典型例は、ワークフロープロセスのある地点において、適合性エンジン（conformance engine）により物理ファイルを生成するため又は承認の目的で、仮想ファイルをメディアプレーヤによりクリップとして閲覧する機能である。

外部の固有ID（UUID）によるデータの集約及び同期
上述したように、本発明原理によるデータベースシステムはあるフレームワークを提供し、外部の固有IDをアセット記述にカプセル化することでデータ集約機能を提供する。

図3は、本発明原理による実施例における集約プロセス300を示す。メディアアセット管理（MAM）システムのデータベース306は、様々なアプリケーション302-1、302-2、302-nについて外部のUUIDを関連付けることを許容する。同期サービス部304は、データソース302内のデータと、MAM内のセントラルデータベースとの対応関係（リンク）を管理する。或いは、サーチプロセスを高速化するため、データソース中のデータがMAMデータベース306に対応付けられてもよい。

図示の例の場合、MAMデータベース306はアセットテーブルを形成し、各ソース302からのデータは、アプリケーション各自のUUID各々をカプセル化することで集約される。例えば、ソース302は、関連するアセットを格納する外部データベースを表す。例えば、権利（情報）管理システムは、メインシステムと同じアセットを参照するが、２つのデータベースの間では、限られた数のメタデータしか共通していない。例えば、メインデータベースは、ビデオクリップ及び何らかの技術的なメタデータと共に映画を有しており、ある企業がその映画を放送する権利を未だ所有しているか否かが分かるように、権利管理システムのデータベースと同期している。

セントラル化されたサーチ
データ検索及びアセットの識別を最適化するため、本発明原理により、サーチ及び索引付けが改良される。サーチは、データベース又はファイルにおけるアセットに関する情報、及び地理的に離れた場所のサイトでさえ、そこにおけるアセットに関する情報の全てを包含する必要がある。さらに、メディアの製作及び分配における様々なシステム及びアプリケーションによる様々な要請に応じるため、サーチ結果は、様々なフォーマットで表現される必要がある。

図4は、本発明原理による実施例におけるサーチフレームワーク400を概略的に示す。クエリ信号又は問い合わせ（query）がサーチエンジン402において受信され、データベースサーチ404、ファイルサーチファイル406及び他のサイト408をそれぞれ介して、(a)MAMデータベース306、(b)1つ以上のファイルリポジトリ410、(c)1つ以上の異なるサイト412のような1個所以上にセントラル化又は転送される。応答は、ユーザに送られる前に、集約サービス部（アグリゲータサービス部）414により統合される。

サーチの性質や、適用される1つ以上のアルゴリズムに依存して、サーチエンジン402は、サービスインターフェースを介してサーチ機能を発揮する。データベースサーチ404は、メタデータ情報を使用して、特定のデータベースに対する問い合わせを動的に作成する。これは、データベース非依存性サーチ（Database agnostic search）と呼ばれる。なぜなら、いったんメタデータ情報が決定されると、如何なるデータベースにも適用可能になるからである。複数のソース(302)からのデータもデータベース非依存性サーチの対象と考えられる。なぜなら、そのデータは公開され、データベース同期サービス部304により同期が維持されるからである。ファイルサーチ機能部406は、ファイルシステム内の様々なタイプのファイルを探索可能にする。他のサイト408は、複数のサイトをサーチ可能にする。アグリゲータ部414は、全てのサーチからの応答を受信し、要求元に応答する前にそれらの結果を1つにまとめる。

サーチコンフィギュレーション
サーチの構造又は検索条件（サーチコンフィギュレーション）は、サーチ環境パラメータを決定し、サーチ環境パラメータは、そのサーチにおける表示、テーブル及びカラム（column）に関する情報を含んでもよい。この情報は、条件設定（コンフィギュレーション）の際にサーチデータベースに取り込まれ、サーチサービス部により使用され、問い合わせを生成、確認及び実行するためのインターフェースをクライアントアプリケーションに提供する。検索条件又はコンフィギュレーションは、コンテンツを如何にして探すかを決定する。

検索条件は、サーチサービスが実際のデータベースに無知であること（アグノスティックであること）を許容し、他の如何なるデータベースに対してもサービスの柔軟性及び応用可能性をもたらす。

表1：サーチコンフィギュレーションの具体例
表1は、一実施例によるサーチコンフィギュレーションの具体例を示す。スキームの要素（Scheme element）は、探索されるデータベースの構造を規定する。表中の要素は、そのテーブル（又は表示）における全てのカラムの記述に加えて、テーブルエイリアス（table alias）及びそのテーブルが動的であるか否か（すなわち、そのスキームが実行時に変更できるか否か）の情報を含む。サーチサービス部は、動的なテーブルの構造を監視し、サーチデータベースを更新し、必要に応じて関連する表示を作り直す。カラム要素は、カラムに関する属性を含む：
・名前（Name）：カラムの名称
・エイリアス（Alias）：カラムの表示名
・タイプ（Type）：カラムのSQLタイプ
・IsUnique:カラムが特有であるか否かを示す。固有のインデックスを伴うカラム又はプライマリキーである。

・IsFTSearchable：カラムがフルテキストのインデックスを有するか否かを示す。

・IsFilterable：我々がカラム上にフィルタを作成可能か否かを示す。

・IsSortable：我々がカラムについて分類可能であるか否かを示す。

この表現内容はデータベースにリレーショナル形式で格納可能である。図5は、このサーチコンフィギュレーション概念例をリレーショナルデータベース形式で示す。上述したように、検索条件はメタデータの記述に依存する。これは図5に示されており、データベース中の要素各々について、要素テーブル中に新たなレコードが生成されている。このテーブルの場合、我々は、名前、エイリアス、IsDynamic、IsView、IsDataProvider及びDescriptionを定義している。データベース中のプロパティ/カラムの各々について、カラムテーブル中に対応するカラムを有し、我々は、TableID、TypeID、名前、エイリアス、データタイプ、IsUnique、IsFtSchedule、IsFilterable、IsOrderable、IsEncrypted、IsDynamic及び記述（Description）を定義している。

本願で説明される実施例は、例えば、方法、プロセス、装置又はソフトウエアプログラムにより実現可能である。1つの実施形態により説明してきたが（例えば、方法としてのみ議論してきた場合もあるが）、説明された特徴は他の形態で実現されてもよい（例えば、装置やプログラムで実現されてもよい。）。装置は例えば適切なハードウエア、ソフトウエア及びファームウエアにより実現されてもよい。方法は例えばプロセッサ等のような装置の中で使用されてもよく、プロセッサとは、一般に、コンピュータ、マイクロプロセッサ、集積回路又はプログラム可能な論理装置を含む処理装置をいう。

さらに、本方法はプロセッサにより実行される命令によって実現されてもよい。そのような命令は、プロセッサが読取可能な媒体に格納可能であり、その媒体は、例えば、集積回路、ソフトウエアキャリア又は他のストレージ装置（例えば、ハードディスク、コンパクトディスケット、ランダムアクセスメモリ（RAM）又はリードオンリメモリ（ROM））等である。命令は、プロセッサ読取可能な媒体に物理的に実現されたアプリケーションプログラムを形成することができる。プロセッサは、例えばプロセスを実行する命令を有するプロセッサ読取可能な媒体を含んでもよいは、明白であろう。当業者に明らかであるように、本実施例は、例えば格納又は伝送可能な情報を運ぶ形式のフォーマットの信号を生成してもよい。その情報は、例えば、方法を実行するための命令や、何れかの実施形態で生成されたデータを含むことができる。そのような信号は、例えば電磁波（例えば、スペクトルの無線周波数部分を使用する信号）として又はベースバンド信号として形成可能である。信号生成（フォーマッティング）は、例えば、データストリームを符号化すること、符号化されたストリームをパケット化すること、及びパケット化されたストリームによりキャリアを変調すること等を含んでよい。信号が搬送する情報は、例えば、アナログ又はディジタル情報でもよい。信号は、周知のように、有線又は無線の多種多様なリンクを通じて伝送可能である。

以上、様々な実施形態が説明されてきた。しかしながら様々な変形例も可能なことが理解されるであろう。例えば、様々な実施例の要素は、結合され、補足され、修正され、或いは省略され、他の実施形態をもたらすことが可能である。さらに、他の構造及びプロセスが、説明されたものと置換可能であること、その結果の実施形態は、説明された実施形態に対して、少なくとも実質的に同様な方法で実質的に同じ機能を実行し、少なくとも実質的に同じ結果をもたらすことを、当業者は理解するであろう。したがって、これら及び他の実施形態は添付の特許請求の範囲内にある。

（関連出願）
本願は、35U.S.C.119(e)に基づいて西暦2007年4月13日付けで出願された米国仮特許出願第60/923,357号による優先的利益を享受し、該仮出願の内容は本願のリファレンスに組み入れられる。

Claims (17)

1. 各アセットに対応するアプリケーションの識別子を、少なくとも1つのアセットにカプセル化するステップと、
   所与のアプリケーションについての前記少なくとも1つのアセットを、前記アプリケーションに対する前記識別子を使用して要求し、該識別子に関する前記少なくとも1つのアセットを特定する要求ステップと
   を有する方法。
2. 前記カプセル化するステップは、ある固有のIDを前記識別子としてアセット各々に割り当てるステップを含む、請求項1記載の方法。
3. 前記カプセル化するステップは、各アセットに対する前記識別子を使用して、データベースにアセットテーブルを形成するステップを含む、請求項１記載の方法。
4. 前記要求ステップは、少なくとも1つのサーチ環境パラメータを決定するステップと、決定した少なくとも1つのパラメータを、検索条件を構築する際にサーチデータベースに取り込むステップとを含む、請求項1記載の方法。
5. 前記形成するステップは、前記識別子を使用して、前記データベース内に仮想アセットアドレスを設定するステップをさらに含む、請求項3記載の方法。
6. 前記少なくとも1つのサーチ環境パラメータを決定するステップは、前記少なくとも1つのアセットに対応するメタデータの記述を特定するステップを含む、請求項4記載の方法。
7. 前記少なくとも1つのアセットに関するメタデータを特定するステップをさらに含み、少なくとも1つの要求が、メタデータの記述を利用して、データベースについて動的に作成される、請求項1記載の方法。
8. ユーザの検索要求に応答して、少なくとも2つのデータソースからの検索結果の同期をとるステップと、
   前記ユーザの検索要求に応答して、検索条件を設定するステップと、
   前記少なくとも2つのデータソースからの同期させた検索結果を集約するステップであって、該集約は、アセット各々に対応するアプリケーション各々について固有の識別子を割り当てることを含む、ステップと、
   集約された検索結果を1つの検索結果として前記ユーザに提示するステップと
   を有する方法。
9. 各アプリケーションについて割り当てられた識別子をカプセル化することで、データベース内にアセットテーブルを形成するステップをさらに含む、請求項8記載の方法。
10. 前記の設定は、検索条件に含まれるサーチ環境パラメータを決定することをさら含む、請求項8記載の方法。
11. 前記検索要求に応答して、検索条件の設定の際、前記サーチ環境パラメータを検索データベースに取り込み、前記検索要求を生成、確認及び実行するインターフェースをクライアントアプリケーションに与えるステップをさらに有する請求項10記載の方法。
12. 前記の決定は、各アセットに関するメタデータの記述を特定することを含み、前記ユーザの検索要求は、前記検索条件を設定する際に前記メタデータの記述を利用して、データベースについて動的に作成される、請求項10記載の方法。
13. 前記の形成は、前記識別子を使用して仮想アセットアドレスを前記データベース内に設定することを含む、請求項9記載の方法。
14. コンピュータ読取可能な媒体に記録され、メディアを生成及び配布する環境で使用される方法を実行させるコンピュータ読取可能なプログラムコードを有するコンピュータプログラムであって、前記方法は、
    各アセットに対応するアプリケーションの識別子を、少なくとも1つのアセットにカプセル化するステップと、
    所与のアプリケーションについての前記少なくとも1つのアセットを、前記アプリケーションに対する前記識別子を使用して要求し、該識別子に関する前記少なくとも1つのアセットを特定する要求ステップと
    を有するコンピュータプログラム。
15. 前記カプセル化するステップは、ある固有のIDを前記識別子としてアセット各々に割り当てるステップを含む、請求項14記載のコンピュータプログラム。
16. 前記カプセル化するステップは、少なくとも1つのアセットに対する特定の識別子を使用して、メディアアセット管理データベースにアセットテーブルを形成するステップを含む、請求項14記載のコンピュータプログラム。
17. 前記要求ステップは、少なくとも1つのサーチ環境パラメータを決定するステップと、前記少なくとも1つのパラメータを、検索条件を構築する際にサーチデータベースに取り込むステップとを含む、請求項14記載のコンピュータプログラム。

Images