JP2005122714A - デジタル・アイテム消費のためのファンクション・メタデータの更新方法 - Google Patents
デジタル・アイテム消費のためのファンクション・メタデータの更新方法 Download PDFInfo
- Publication number
- JP2005122714A JP2005122714A JP2004269721A JP2004269721A JP2005122714A JP 2005122714 A JP2005122714 A JP 2005122714A JP 2004269721 A JP2004269721 A JP 2004269721A JP 2004269721 A JP2004269721 A JP 2004269721A JP 2005122714 A JP2005122714 A JP 2005122714A
- Authority
- JP
- Japan
- Prior art keywords
- function metadata
- metadata
- digital item
- document
- function
- 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.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
【課題】 ユニバーサル・マルチメディア・アクセス・フレームワークにおいてＭＰＥＧ−２１のファンクション・メタデータを動的及び／または効率的に更新するメカニズムを提供する。
【解決手段】 デジタル・アイテムのファンクション・メタデータを更新する方法であって、前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信し、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信し、前記第１ＤＩＤ文書をＤＩＤパーサで処理し、前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出し、前記第２ＤＩＤ文書を前記ＤＩＤパーサで処理し、前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出し、前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得る。
【選択図】 図３
【解決手段】 デジタル・アイテムのファンクション・メタデータを更新する方法であって、前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信し、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信し、前記第１ＤＩＤ文書をＤＩＤパーサで処理し、前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出し、前記第２ＤＩＤ文書を前記ＤＩＤパーサで処理し、前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出し、前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得る。
【選択図】 図３
Description
本発明は、ユニバーサル・マルチメディア配信チェーンにおける多目的デジタル・アイテム（ＤＩ）消費に関し、特に、ＤＩマルチメディア・マテリアルへの制御されたアクセスをいつでも、どこからでも、どんなデバイスにおいてでも可能にするためにＭＰＥＧ−２１マルチメディア・フレームワークに定義された異なるファンクション・メタデータを更新する必要のあるようなアプリケーションに関する。
ＭＰＥＧ及び他の標準化組織は、ある場所から他の場所への効率的なコンテンツの転送及び配信、及び限定された空間におけるコンテンツの大容量記憶を容易にするために、ビデオ、オーディオ、システム、通信プロトコル、コンテンツ表現、コンテンツ・パッケージング他に関する多くの規格を作成してきた。最近は、多くのアプリケーション・ドメインにおける異なる範疇のユーザによる全てのコンテンツ・タイプの配信及び利用をサポートする能力のある環境でのユニバーサル・マルチメディア・アクセス・フレームワークを設定することに、より多くの努力が傾注されている。
ＭＰＥＧ−２１フレームワークの目的は、様々なテクニカル・エレメントがどう組み合わせられるかを記述して、異なるコミュニティで使用される広範なネットワーク及びデバイスに渡るマルチメディア・リソースのトランスペアレントな増補式利用を有効化するための展望を打ち出すことにある。このようなフレームワーク内で定義された規格表現、識別及び記述を有する構造化されたデジタル・オブジェクトであるデジタル・アイテム（ＤＩ）は、ＭＰＥＧ−２１フレームワーク内の互換、流通及びトランザクションの基本単位である。デジタル・アイテムは、マルチメディア・コンテンツをその構成要素及び構成に関して定義することを目的とするスタンダードである、デジタル・アイテム宣言（ＤＩＤ）によりＸＭＬを使用して宣言されかつ表現される。必須のメディア・リソース（デジタル化されたビデオ／サウンド・データ、デジタル画像等）に加えて、ＤＩＤは、全種類のファンクション・メタデータ（例えば、リソース・フォーマットを記述し、リソース保護スキームを特定し、リソースに識別名を与え、ユーザ・プレファレンスを規定する等のデータ）を包含するフレキシブルな構成について規定する。検索用ＤＩメディア・リソースに関する一般的な補充メタデータ（ＭＰＥＧ−７メタデータ等）に比べて、ファンクション・メタデータは、幾つかの特別な機能（識別、保護及びアダプテーション等）の実行をアシストし、かつＭＰＥＧ−２１フレームワークに基づくフレキシブルなメディア・リソース消費を提供することができる。
ＤＩＤテクノロジーの核心部分に加えて、他の主要なテクノロジーも既に幾つか詳細に開発され、もしくは開発中である。デジタル・アイテム識別（ＤＩＩ）、デジタル・アイテム・アダプテーション（ＤＩＡ）、知的財産の管理と保護（ＩＰＭＰ）、ＲＥＬ（権利表記言語）／ＲＤＤ（権利データ辞書）並びにＥＲ（イベント報告）は全て、デジタル・アイテムの使用法を大々的に活用するための重要なテクノロジーである。これらのテクノロジーによって定義された全てのファンクション・メタデータは、実際のメディア・リソース消費を援助すべくＤＩＤ文書に掲載することが可能である。
図１は、ＤＩＤ（メディア・リソースのコンポーネント及びその構成）が、メディア・リソースの配信、メディア・リソースの機密保護、権利の管理、支払いの確保及び消費を援助するテクノロジーを有効化することのできるＤＩＩ記述子、ＩＰＭＰ記述子、ＲＥＬ／ＲＤＤ記述子、ＤＩＡ記述子及びＥＲ記述子他を含むスタティック・メタデータを包含することが可能な、カレント状態を述べるＩＳＯ／ＩＥＣ ２１０００−２：ＭＰＥＧ−２１ ＤＩＤの先行技術を示したものである。幾つかの基本的なトランザクション単位ＤＩ（モジュール１．２、１．３、１．４）より成るＤＩＤ文書（モジュール１．１）はプロバイダからユーザへ配信されるが、幾つかの中間処理ピアを介して伝送される場合もある。ＤＩＤ文書の内部では、ＤＩのトランザクションの識別、保護及びアダプテーションに関してマルチメディア・フレームワークを援助するために、ＤＩＩ（モジュール１．５）、ＲＥＬ／ＲＤＤによるＩＰＭＰ（モジュール１．６）、ＤＩＡ（モジュール１．７）、ＥＲ（モジュール１．８）に関する幾つかの重要なファンクション・メタデータもまた伝送することができる。
図８は、図１のＤＩＤ文書１．１のエレメント構造を示す図である。ここで、ＤＩＤ文書１．１はコンテナとも呼ばれる。図８は、コンテナ１．１中に３つのデジタル・アイテム（ＤＩ）１．２〜１．４が含まれる場合を示しており、デジタル・アイテム１．２の中にＤＩＤヘッダ、ＤＩＩ記述子１．５、ＩＰＭＰ記述子１．６、ＤＩＡ記述子１．７、Event_Report記述子１．８、メディアリソース１．９が含まれる。他のデジタル・アイテム１．３，１．４の場合も必要な記述子による記述が含まれる。
注意：本図はＤＩＤ文書の極めて簡単なケースを示したものであり、実際のＤＩＤ構成はこれよりも複雑な要素（選択肢、選択、サブアイテム／コンポーネント他等）を包含して階層的なＤＩを表現することができる。
どんなトランザクションであっても、トランザクションのオブジェクトを識別する必要が存在し、かつそのための手段が存在する。ＤＩＩはＤＩを一意的に識別し、書籍に対するＩＳＢＮと同じ役割を果たす。例えば、モジュール１．５が示す「<dii:identifier>uri:1234567</dii:identifier>」は、第１のＤＩを識別する。
ＤＩＡは、ユーザ、ネットワーク及びデバイス・プロパティの固有の特徴に最も良く適合するためにはＤＩが如何に適応されなければならないかを記述する手段の提供に対応する。ＤＩＡ仕様は、基本的な使用環境記述メタデータ、ＤＩリソース・アダプテーション・メタデータ及びＤＩＤアダプテーション・メタデータを定義する。モジュール１．６には、ＤＩＡのｇＢＳＤ（汎用ビットストリーム構文記述子）による簡単な例が示されている。
ＤＩを管理し保護するＩＰＭＰのアーキテクチャは、ＤＩバリュー・チェーンの全メンバーによるＤＩの流通、管理及び利用に付随する権利、条件、帰結及び義務（ＲＥＬ／ＲＤＤ情報）の表現及び施行について規定する。ＤＩに付随するＩＰＭＰ、本アーキテクチャによる信頼の役割、及びＤＩの管理能力及び利用可能性が信用のあるエンティティによって保証された特定基準を満たしていると主張する能力等のファンクションに関するピア要件を支持する相互運用性については、これらを可能な限り明確に記述するための手段を定義する必要がある。ＲＥＬ使用規則によりモジュール１．７に表現されている必要なＩＰＭＰツール（透かし技術等）の関連情報は、第１のＤＩ消費に制約を与える。
ＥＲの目的は、報告可能な全てのイベントのパフォーマンスの測定基準及びインタフェースを提供することにある。マルチメディア・フレームワークによってこれを標準化する必要性は、ＤＩ及び／またはＤＩに関連して作動するプログラム、デバイス、ピアの内部モジュールに関するイベントをピア及びユーザ間で、または１つのピア内部で随時監視し、伝達する必要性から発生する。ＵＲＬサイトから検索される第１のＤＩの消費に関するＵｓａｇｅＲｅｐｏｒｔは、モジュール１．８に記述される。
ＩＳＯ／ＩＥＣ ２１０００フレームワークに定義されているピアは、デジタル・アイテムを規格に準拠して処理するデバイスまたはアプリケーションである。
ＤＩＤにおいて伝送されるメディア・リソースは、モジュール１．９に示されている。
ＤＩＤ自体を含む上述の多くのＭＰＥＧ−２１ファンクション・メタデータは全て、実ＤＩリソースによって配信され、かつ、これに密にリンクされて直接処理される、またはローカル・メタデータ・データベースに記憶されることが可能である。現行のＭＰＥＧ−２１フレームワークが規定するようなファンクション・メタデータの効率的及び／または動的な更新を必要とする利用ケースは、数多く存在する。また更新は、メディア・リソースのバリュー・チェーンに位置づけられるどのピアにおいても発生する可能性がある。例えば、利用環境の記述は送信中に修正され得る。終端間遅延のような単一の手段は、送信者とおそらくは複数の受信者との間の各リンクまたはノードで更新される。コンテンツのプロバイダは、履行される条件に基づいてＲＥＬの「再生」回数のような特定の値を周期的にリフレッシュすることがある。ＤＩＤ文書自体ですら、共用されるＤＩコンポーネントがＤＩユーザの一人によって修正されると、更新される必要がある。しかしながら、現行のＭＰＥＧ−２１フレームワークでは、ＤＩ関連のＭＰＥＧ−２１ファンクション・メタデータの更新に関するメカニズムは十分ではない。
本発明は、下記の問題点を解決しようとするものである。
ファンクション・メタデータ、即ちＤＩＤ、ＤＩＩ、ＤＩＡ、ＩＰＭＰ、ＲＥＬ／ＲＤＤ及びＥＲ他の記述は、メディア・リソースの消費をアシストする定義されたテクノロジーを有効化することができる。但し、ユニバーサル・マルチメディア・アクセス・フレームワークにおいてＭＰＥＧ−２１のファンクション・メタデータを動的及び／または効率的に更新するメカニズムが必要とされる。
ファンクション・メタデータ、即ちＤＩＤ、ＤＩＩ、ＤＩＡ、ＩＰＭＰ、ＲＥＬ／ＲＤＤ及びＥＲ他の記述は、メディア・リソースの消費をアシストする定義されたテクノロジーを有効化することができる。但し、ユニバーサル・マルチメディア・アクセス・フレームワークにおいてＭＰＥＧ−２１のファンクション・メタデータを動的及び／または効率的に更新するメカニズムが必要とされる。
このような更新メカニズムは、更新タイプ、更新コンテキスト情報及びＭＰＥＧ−２１更新メタデータ・ユニット・ペイロードの指定されたフォーマットによる表示を有する汎用構造を保有していなければならない。効率的な更新メカニズムの場合は、バイナリ・フォーマットの更新メタデータ・ユニットが使用されなければならない（ＭＰＥＧに定義されているＢｉＭ等）。
本発明に係るデジタル・アイテム消費のためのファンクション・メタデータの更新システムは、デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを端末に送信するサーバと、前記サーバから受信した前記第２ＤＩＤ文書に含まれる前記ファンクション・メタデータの更新ユニットを用いて前記ファンクション・メタデータを更新する端末とを備え、
前記サーバは、
前記デジタル・アイテムの前記ファンクション・メタデータを含む第１ＤＩＤ文書と、前記ファンクション・メタデータの更新箇所に関するファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを作成するＤＩＤ文書作成部と、
前記デジタル・アイテムと、前記デジタル・アイテムの第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記端末に送信する送信部と
を備え、
前記端末は、
前記デジタル・アイテムと、前記デジタル・アイテムの前記第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む前記第２ＤＩＤ文書とを前記サーバからに受信する受信部と
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するファンクション・メタデータ抽出部と、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出する更新モジュールと、
前記ファンクション・メタデータの更新ユニットに基づいて前記ファンクション・メタデータを更新する記述コンポーザと
を備えることを特徴とする。
前記サーバは、
前記デジタル・アイテムの前記ファンクション・メタデータを含む第１ＤＩＤ文書と、前記ファンクション・メタデータの更新箇所に関するファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを作成するＤＩＤ文書作成部と、
前記デジタル・アイテムと、前記デジタル・アイテムの第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記端末に送信する送信部と
を備え、
前記端末は、
前記デジタル・アイテムと、前記デジタル・アイテムの前記第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む前記第２ＤＩＤ文書とを前記サーバからに受信する受信部と
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するファンクション・メタデータ抽出部と、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出する更新モジュールと、
前記ファンクション・メタデータの更新ユニットに基づいて前記ファンクション・メタデータを更新する記述コンポーザと
を備えることを特徴とする。
また、上記システムにおけるサーバは、デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを端末に送信するサーバであって、
前記デジタル・アイテムの前記ファンクション・メタデータを含む第１ＤＩＤ文書と、前記ファンクション・メタデータの更新箇所に関するファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書を作成するＤＩＤ文書作成部と、
前記デジタル・アイテムと、前記デジタル・アイテムの第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記端末に送信する送信部と
を備えることを特徴とする。
前記デジタル・アイテムの前記ファンクション・メタデータを含む第１ＤＩＤ文書と、前記ファンクション・メタデータの更新箇所に関するファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書を作成するＤＩＤ文書作成部と、
前記デジタル・アイテムと、前記デジタル・アイテムの第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記端末に送信する送信部と
を備えることを特徴とする。
さらに、上記システムにおける端末は、デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記サーバから受信して、前記ファンクション・メタデータを更新する端末であって、
前記デジタル・アイテムと、前記デジタル・アイテムの前記第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む前記第２ＤＩＤ文書とを前記サーバからに受信する受信部と
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するファンクション・メタデータ抽出部と、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出する更新モジュールと、
前記ファンクション・メタデータの更新ユニットに基づいて前記ファンクション・メタデータを更新する記述コンポーザと
を備えることを特徴とする。
前記デジタル・アイテムと、前記デジタル・アイテムの前記第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む前記第２ＤＩＤ文書とを前記サーバからに受信する受信部と
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するファンクション・メタデータ抽出部と、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出する更新モジュールと、
前記ファンクション・メタデータの更新ユニットに基づいて前記ファンクション・メタデータを更新する記述コンポーザと
を備えることを特徴とする。
本発明に係るデジタル・アイテム消費のためのファンクション・メタデータを更新する方法は、デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記サーバから受信して、前記ファンクション・メタデータを更新する方法であって、
前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信するステップと、
前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信するステップと、
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するステップと、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出するステップと、
前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得るステップと
を含むことを特徴とする。
前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信するステップと、
前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信するステップと、
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するステップと、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出するステップと、
前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得るステップと
を含むことを特徴とする。
前記デジタル・アイテム消費のためのファンクション・メタデータの更新方法は、抽出した前記ファンクション・メタデータをメタデータ・データベースへ記憶するステップをさらに含んでもよい。
なお、前記デジタル・アイテム消費のためのファンクション・メタデータの更新方法を、その各ステップをコンピュータ上で実行させるデジタル・アイテム消費のためのファンクション・メタデータの更新用コンピュータ・プログラムとすることができる。さらに、上記デジタル・アイテム消費のためのファンクション・メタデータの更新用コンピュータ・プログラムをコンピュータ読み取り可能な記録媒体に格納してもよい。
また、本発明に係るデジタル・アイテムを処理する方法は、デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記サーバから受信して、前記ファンクション・メタデータを更新し、前記更新したファンクション・メタデータを用いて前記デジタル・アイテムを処理する方法であって、
前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信するステップと、
前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信するステップと、
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するステップと、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出するステップと、
前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得るステップと、
前記更新されたファンクション・メタデータに基づいて前記デジタル・アイテムを処理するステップと
を含むことを特徴とする。
前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信するステップと、
前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信するステップと、
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するステップと、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出するステップと、
前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得るステップと、
前記更新されたファンクション・メタデータに基づいて前記デジタル・アイテムを処理するステップと
を含むことを特徴とする。
また、前記デジタル・アイテムを処理するステップは、
ｉ）前記更新されたファンクション・メタデータに含まれる新たなＤＩＩ識別スキームを用いて前記デジタル・アイテムを識別するか、
ｉｉ）前記更新されたファンクション・メタデータに含まれる新たなＤＩＡ記述メタデータを用いて前記デジタル・アイテムを適応させるか、
ｉｉｉ）前記更新されたファンクション・メタデータに含まれる新規ＲＥＬ条件／使用規則をチェックし、かつ実行するか、
ｉｖ）前記更新されたファンクション・メタデータに含まれる新たなＩＰＭＰツール情報を基礎として前記デジタル・アイテムを復号化するか、
のｉ）〜ｉｖ）のうちの少なくとも一つを行うものであってもよい。
ｉ）前記更新されたファンクション・メタデータに含まれる新たなＤＩＩ識別スキームを用いて前記デジタル・アイテムを識別するか、
ｉｉ）前記更新されたファンクション・メタデータに含まれる新たなＤＩＡ記述メタデータを用いて前記デジタル・アイテムを適応させるか、
ｉｉｉ）前記更新されたファンクション・メタデータに含まれる新規ＲＥＬ条件／使用規則をチェックし、かつ実行するか、
ｉｖ）前記更新されたファンクション・メタデータに含まれる新たなＩＰＭＰツール情報を基礎として前記デジタル・アイテムを復号化するか、
のｉ）〜ｉｖ）のうちの少なくとも一つを行うものであってもよい。
なお、上記デジタル・アイテムの処理方法は、その各ステップをコンピュータ上で実行させるデジタル・アイテムの処理用コンピュータ・プログラムとすることができる。また、上記デジタル・アイテムの処理用コンピュータ・プログラムをコンピュータ読み取り可能な記録媒体に格納してもよい。
本発明の別の形態に係るユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法としては、記憶されたオリジナルのメタデータまたは最初に送信されたメタデータを中間ピアまたはエンドユーザ・ピアにおいて更新するために、コンテンツの制作／流通サイドで更新するファンクション・メタデータ・ユニットをパッケージし、かつこのようにして受信されたメタデータ・ユニットを処理することが規定された方法で実行され得るように、ＭＰＥＧ−２１メタデータのオーサリング・ツール及びＭＰＥＧ−２１ピア更新モジュールに使用される更新命令メカニズムを定義する手段である。
また、本発明の別の形態に係るユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法としては、ＭＰＥＧ−２１ファンクション・メタデータの更新に関する共通インフラを記述するための、ＸＭＬスキーマを使用する一般更新構成を定義する手段である。このような一般構成の内部において、異なるタイプのオペレーションを使用して、現行更新が記憶されたオリジナルのファンクション・メタデータまたは最初に送信されたファンクション・メタデータのｘｍｌツリー構造を挿入するためのものであるか、削除するためのものであるか、置換するためのものであるかを指示し、ＸＭＬパスを使用して更新オペレーションを必要とする正確なｘｍｌツリー・ノードを示す更新コンテキストを包含し、記憶されたオリジナルのファンクション・メタデータまたは最初に送信されたファンクション・メタデータを挿入／削除／置換するように想定された実ＭＰＥＧ−２１記述情報を伝送すべく更新構造に更新ペイロード・メタデータを包含する手段である。
本発明は、ピアが異なるコンテンツ配信チェーンのためのユニバーサル・メディア・アクセス・フレームワークの下で有効かつデジタル・メディア・リソースの再生を支援する多くのＭＰＥＧ−２１ファンクション・メタデータの更新を実装する際の問題点を解決する。本発明は、それらがＭＰＥＧ−２１関連メタデータの解釈及び表現について同一の更新メカニズムを基礎として構築されている限り、異なるコンテンツ配信チェーン内の異なるポイントに位置づけられた異なるピアに相互運用性を提供する。
相互運用性に加えて、本発明はまた、ＸＭＬスキーマ・テクノロジーを使用する異なるコンテンツ・プロバイダに対し、識別番号、使用規則、アダプテーション記述、ＩＰＭＰツール情報、イベント報告他を含むＭＰＥＧ−２１テクノロジーによってエネーブルされる全種類のファンクション・メタデータが同一の更新インストラクタ内に配置され得るようなより優れた柔軟性及び拡張性を供給する。
同時に、標準更新インストラクタ・スキーマ・アーキテクチャを基礎として構築された統合オーサリング・ツールは、コンテンツ制作者／配信業者またはエンドユーザに整然としたクリーンな更新構造を供給する。
（発明の作用）
コンテンツ製造サイド：
図２は、ＭＰＥＧ−２１ユニバーサル・マルチメディア・アクセス・システムにおけるコンテンツ製造サイドのＭＰＥＧ−２１ファンクション・メタデータ処理の一般手順を示す図である。
コンテンツ製造サイド：
図２は、ＭＰＥＧ−２１ユニバーサル・マルチメディア・アクセス・システムにおけるコンテンツ製造サイドのＭＰＥＧ−２１ファンクション・メタデータ処理の一般手順を示す図である。
コンテンツの制作（モジュール２．１）及びコンテンツの流通（モジュール２．２）を含むコンテンツ生成サイドでは、異なるメディア・リソースが従来のコード化技術を使用して符号化され、オリジナルのコーディング・フォーマットまたは後の処理（適応／暗号）フォーマットで表現される。
メタデータのオーサリング・ツール（モジュール２．３、２．４）は標準化された様々なＭＰＥＧ−２１テクノロジー（ＤＩＩ、ＩＰＭＰ、ＲＥＬ／ＲＤＤ、ＤＩＡ及びＥＲ）（モジュール２．５）を基礎として構築され、コンテンツの制作及び流通において下記の目的で使用される。
１）異なるメディア・リソースを識別するために世界の異なるＩＤスキームを使用してコンテンツのＩＤを生成する。
２）異なる権利、使用規則、ライセンス条件他に関するＲＥＬメタデータを構築する。その幾つかはオフラインで行われ、幾つかはユーザが申込をして支払いを行なった時点でリアルタイムに行われる。
３）ＩＰＭＰ制御情報及びＩＰＭＰツール記述を構築し、異なるメディア・リソースの保護及び消費に必要な異なるＩＰＭＰツール（透かし、ＡＥＳ、ＤＥＳ他）を示す。
４）メディア・リソースに関するリソース・アダプテーションＱｏＳ記述及びユニバーサル制約記述を生成する。
５）メディア・リソースに関する初期ＣｒｅａｔｉｎｇＲｅｐｏｒｔを生成する。
２）異なる権利、使用規則、ライセンス条件他に関するＲＥＬメタデータを構築する。その幾つかはオフラインで行われ、幾つかはユーザが申込をして支払いを行なった時点でリアルタイムに行われる。
３）ＩＰＭＰ制御情報及びＩＰＭＰツール記述を構築し、異なるメディア・リソースの保護及び消費に必要な異なるＩＰＭＰツール（透かし、ＡＥＳ、ＤＥＳ他）を示す。
４）メディア・リソースに関するリソース・アダプテーションＱｏＳ記述及びユニバーサル制約記述を生成する。
５）メディア・リソースに関する初期ＣｒｅａｔｉｎｇＲｅｐｏｒｔを生成する。
モジュール２．６には、コンテンツの所有者／配信業者の要件に基づいて初期ＭＰＥＧ−２１ＸＭＬファンクション・メタデータをすべて構築し、ＤＩＤテクノロジーを使用してこれらをＤＩＤで直接ストリーム化される、またはＵＲＬサイトに記憶される実メディア・リソースと共にパックされることが示されている。このようなファイル（ＤＩＤ文書）は、バイナリ・フォーマット（任意選択）に変換され、ＭＰＥＧ−２１の中間ピアまたはエンドユーザ・ピアに送信される。
ＭＰＥＧ−２１ファンクション・メタデータは、制作者及び配信業者のさらなる要件を基礎として常時かつ動的に変更されなければならない。モジュール２．７には、このような純粋な更新メタデータ・ユニットはまた、メタデータのオーサリング・ツール（モジュール２．４）の援助によりＤＩＤを使用して、但し追加の更新情報と共にパッケージされ得ることが示されている。パッケージされるこのさらなるＤＩＤは、初期のＤＩＤ（モジュール２．６）と共に同じチャネルで継続的に、または後に別の配信チャネルで送信されなければならない。
モジュール２．７はまた、メタデータ・オーサリング・ツール（モジュール２．４）の援助を得てＭＰＥＧ−２１のエンドユーザ（モジュール２．８、ＭＰＥＧ−２１ファンクション・メタデータを生成する特別なコンテンツ制作者）によっても生成することが可能である。例えば、所望のＭＰＥＧ−２１ファンクション・メタデータ更新手順が、たまたまある中間ピア（サーバ／プロキシ／ゲートウェイ等）において発生すると、エンドユーザ（モジュール２．８）は、更新するユーザ・プレファレンス記述（ＤＩＡ）を作成し、更新されるユーザ・プレファレンスを基礎としてアダプテーションを実行可能であるようなピアにその更新するユーザ・プレファレンス記述（ＤＩＡ）を送信することが可能であり、最終的にエンドユーザは、その制約付きの端末に関する適応されたメディア・リソースを得ることができる。
中間ピアまたはエンドユーザ・ピア・サイド：
図３は、ＭＰＥＧ−２１ユニバーサル・マルチメディア・アクセス・システムにおけるメディア・リソース消費を伴う場合または伴わない場合のＭＰＥＧ−２１ファンクション・メタデータ処理の汎用ピア構成を示す図である。
図３は、ＭＰＥＧ−２１ユニバーサル・マルチメディア・アクセス・システムにおけるメディア・リソース消費を伴う場合または伴わない場合のＭＰＥＧ−２１ファンクション・メタデータ処理の汎用ピア構成を示す図である。
ＤＩＤ文書は、ＭＰＥＧ−２１ファンクション・メタデータ（モジュール３．２）のみを含む場合であれ、実メディア・リソース（モジュール３．１）をも包含する場合であれ、ＭＰＥＧ−２１ピア（モジュール３．３）へ配信され、ＤＩＤパーサ（モジュール３．４）は、ピアにおいてフロントドアのように機能してＤＩＤ文書を開き、ＤＩＤ文書を処理する。ＤＩＤパーサは、ＤＩＤ文書を解析し、ファンクション・メタデータや、デジタル・アイテム、ディスクリプタ等の抽出処理を行うものである。
ＤＩＤパーサ以外にも、ＭＰＥＧ−２１ピアはまた他の様々な処理モジュールを伴って構築される。
ＤＩＤのパーシング結果からすると、メディア・リソース・リゾルバ（モジュール３．５）及びＭＰＥＧ−２１ファンクション・メタデータ・エクストラクタ（抽出部）（モジュール３．６）は、異なるＤＩの本質（メディア・リソースまたはメタデータ）を基礎とするその後の処理に必要な２つのモジュールである。メディア・リソース・リゾルバは、実メディア・ストリームをＤＩＤ文書でバインドされたデータから直接取り込むか、ウェブサイトからダウンロードすることができる。ファンクション・メタデータ・エクストラクタは、異なるエレメント（ＤＩＩ、ＤＩＡ、ＩＰＭＰ、ＲＥＬ／ＲＤＤ、ＥＲ）の個々のスキーマ・ヘッダを基礎としてＤＩＤ文書から全種類のＭＰＥＧ−２１関連初期記述を取得し、データベースの記憶装置（ローカル・サイトのモジュール３．１１または外部サイトのモジュール３．１２）へスキーマと共にこれら全てのメタデータを保存する、または直接ＭＰＥＧ−２１エレメント・プロセッサ／パーサへ送信して処理させることが可能である。
パーサを有するＭＰＥＧ−２１エレメント・プロセッサ（モジュール３．１０、これはＤＩＩ、ＤＩＡ、ＩＰＭＰ、ＲＥＬ／ＲＤＤ、ＥＲ他の別々のプロセッサを包含するが、本発明ではこれらを１つのエンティティ内に記述しなければならない）は、異なる標準構成、スキーマまたはアーキテクチャを基礎として全種類のファンクション・メタデータを解釈し、実メディア・リソースに直接作用してＤＩの前処理（モジュール３．９）を削除することができる。例えば、実メディア・リソースは、ＤＩＡ記述メタデータを基礎として（再度）適応され、詳細なＲＥＬ条件／使用規則に従ってチェックされかつ実行され、ＩＰＭＰツール情報を基礎として復号化（かつ再度暗号化）される。
次に、メディア・リソース・プレーヤ（モジュール３．８、中間ピアにおいて前処理が起こっている場合、このモジュールはない）は、デジタル・アイテム内のメディア・リソースを消費することができる。
ＤＩＤパーシングによる処理結果が更新スキーマ・ヘッダを基礎とする更新情報を含んでいるときは、これらのメタデータ結果は全て更新モジュール（３．７）へ直接転送されることが可能である。更新ＭＰＥＧ−２１ファンクション・メタデータ・ユニットは、更新オペレーション・コマンド及び更新コンテキストを基礎として、ピアの記憶されたオリジナルのファンクション・メタデータまたは送信された初期ファンクション・メタデータに関して運用される。
図４は、メタデータの更新手順のみを行う場合のサーバ／ゲートウェイまたはエンドユーザのピアにおける単純なハードウェアのブロック図である。ＤＩＤプロセッサ／パーサ（４．１）は異なるタイプのＤＩＤを受信し、パーシング結果を個々のモジュールに送出している。ファンクション・メタデータ・エクストラクタ（４．２）はオリジナルのファンクション・メタデータを取得し、それをメタデータ・データベースまたはメタデータ・バッファに保存することができる。更新モジュール（４．３）は、要求されたファンクション・メタデータの更新ユニット以外にも、更新コンテキスト及び更新コマンドを抽出する。次に、記述コンポーザ（４．４）は、上述のオリジナル・ファンクション・メタデータ、更新ファンクション・メタデータ、更新コンテキスト及び更新コマンドの全てを基礎にして更新されたファンクション・メタデータを生成することができる。
上記叙述には、更新ＭＰＥＧ−２１メタデータ・ユニットの構築方法、更新オペレーション命令の更新構成／スキーマ（構文と意味）の定義及び標準化方法、更新コンテキストと組み込まれるメタデータ・ユニット及び異なる更新エレメントが保有しなければならない関係性に関する更新命令メカニズムは詳述されていない。以下、実施例によりこれらを全て詳しく説明していく。
ＭＰＥＧ−２１ファンクション・メタデータの更新メカニズム
本明細書の（従来の技術）において、現行のマルチメディア・フレームワークでは未だ、多くのアプリケーション使用事例に対する識別、保護及びアダプテーション関連のメタデータを更新するメカニズムが提供されていない、という課題について簡単に言及した。以下、権利の記述に関するアプリケーションの具体例を示し、ファンクション・メタデータ更新メカニズムを定義する優位点を明らかにする。
本明細書の（従来の技術）において、現行のマルチメディア・フレームワークでは未だ、多くのアプリケーション使用事例に対する識別、保護及びアダプテーション関連のメタデータを更新するメカニズムが提供されていない、という課題について簡単に言及した。以下、権利の記述に関するアプリケーションの具体例を示し、ファンクション・メタデータ更新メカニズムを定義する優位点を明らかにする。
支払金を基礎とする利用限定デジタル・アイテム消費の使用事例
ユーザは、ＰＤＡを使用してデジタル・アイテム（ＤＩ）にアクセスし、支払金を基礎として曲を２回再生する。２回の再生が終わると、ユーザはそれ以上ＤＩを再生できない。ユーザはその「再生回数」の更新要求を送信し、同時にこうしたＤＩに対してＤＩ配信業者に（別のチャンネルで）さらにお金を支払う。するとユーザは、ユーザによる新たな支払金を基礎としてＤＩ配信業者から音楽再生の新規条件が受信された時点からＤＩをさらに再生することができる。
ユーザは、ＰＤＡを使用してデジタル・アイテム（ＤＩ）にアクセスし、支払金を基礎として曲を２回再生する。２回の再生が終わると、ユーザはそれ以上ＤＩを再生できない。ユーザはその「再生回数」の更新要求を送信し、同時にこうしたＤＩに対してＤＩ配信業者に（別のチャンネルで）さらにお金を支払う。するとユーザは、ユーザによる新たな支払金を基礎としてＤＩ配信業者から音楽再生の新規条件が受信された時点からＤＩをさらに再生することができる。
注意：条件（即ち、ＲＥＬのこの使用事例においてＤＩを再生できる回数）は、支払い等の他の条件遵守を基礎としてユーザとコンテンツ配信業者との間で更新されなければならない。また、ユーザは異なるデバイスを使用して同じＤＩにアクセスすることができるが、同じユーザに対する利用条件は常時更新され、かつ全デバイス間に事前に通知されなければならない。
ＤＩＤ文書（メディア・リソースなし）内部のＭＰＥＧ−２１ファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）は、送信者（コンテンツ制作者／配信業者またはエンドユーザ）のピアから入手可能であるようなＭＰＥＧ−２１更新ファンクション・メタデータ・ユニットを受信側のピア（中間またはエンドユーザ）へ伝え、記憶されたオリジナルのファンクション・メタデータまたは送信された初期ファンクション・メタデータに作用させるように働く。図５は、ＸＭＬスキーマを使用して更新ＭＰＥＧ−２１ファンクション・メタデータに関する共通インフラを記述する一般更新構成体であるＦＭＵＩを示している。ＤＩＤＬスキーマ・ヘッダ（５．１）によって表現されるＸＭＬ文書であるＤＩＤ文書（５．０）は、メタデータ（５．２）及びメディア・リソース（５．３）で構成される。ＦＭＵＩ（５．４）はさらに更新スキーマ・ヘッダ（５．５）により特別なメタデータとして処理され、コンテキストＤＩＤ（実メディア・リソースなし）内部へ伝送される。ＦＭＵＩ（５．４）の構成は、下記の通りである。
１）本発明では、ＭＰＥＧ−２１ファンクション・メタデータに基づいて実行されかつコンパクトに表現され得る専用の更新命令コマンド・セット（５．６）が定義される。命令セットは限定的であるため、制約付きのデバイスまたはカスタム・デバイス上でのサポートが容易である。さらに、これらのコマンドは特定の言語に縛られないため、選択された、または都合の良い任意の言語で実装されることが可能である。これらの更新命令コマンドは、削除、置換及び挿入の各コマンドで構成される。
２）所定のスキーマ文書におけるデータ・タイプを識別し、かつ更新命令コマンドが適用されるカレント記述ツリー内のロケーションを指示するファンクション・メタデータ更新命令コンテキスト（５．７）。
３）挿入される、または置換される実ファンクション・メタデータ更新ＸＭＬユニット、またはそのレファレンスの何れかを伝達するファンクション・メタデータ更新ユニット（５．８）（ＦＭＵＩにおいて削除コマンドが使用されるときは、本ユニットを包含してはならない）。
上述のように定義された構成パーツに基づいて、更新モジュールはＦＭＵＩからファンクション・メタデータ更新ユニットを分離し、対応する更新コマンド及びコンテキスト情報を送出する。ファンクション・メタデータ更新ユニットは、個々のファンクション・メタデータ・スキーマ・ヘッダ（５．９）を基礎として異なるＭＰＥＧ−２１エレメント（ＤＩＤ、ＤＩＩ、ＤＩＡ、ＩＰＭＰ、ＲＥＬ／ＲＤＤ、ＥＲ他）において定義されるパーサを通過し、実更新ユニット・データ本体（５．１０）を得る。
コンテキスト情報に援助された有効更新ユニットは、オリジナルのファンクション・メタデータ記述ツリーに作用し、これを組み換える。更新コマンド及びコンテキストは記述コンポーザによって処理され、記述コンポーザは、ファンクション・メタデータ更新ユニットまたはそのレファレンスをカレント記述ツリーの適切なノードに配置するか、この情報を含む再構成イベントをアプリケーションへ送信する。記述コンポーザによるカレント記述ツリーの実際の再構成は実装固有のものであり、即ちアプリケーションは、必要に応じて望ましくないエレメントを取り除く、もしくは無視するように記述コンポーザに命令する。このカレント記述ツリーのフォーマットに関する要件は存在せず、例えば、これは引き続きバイナリ表現であってもよい。
ＭＰＥＧ−２１ファンクション・メタデータ更新インストラクタの概観
ＦＭＵＩにおけるコマンドは、挿入、置換及び削除であり、これらは記憶されたカレント・ファンクション・メタデータまたは送信された初期ファンクション・メタデータの記述ツリー・ノードに直接作用する。図６は、これらを示したものである。挿入（６．１）はデフォルトで「追加」コマンドであり、ターゲット・ノード（「太い」点で示されている）の既存のチャイルド・ノード間のエレメントを追加する。追加されるエレメントの場所は明確に定義することが可能であり、カレント記述ツリー内に既に存在する第１のエレメントより前、他の２つのエレメント間または最終エレメントの後へエレメントを挿入できる。置換（６．２）は、ターゲット・ノードからのエレメントの交替を含む。図６では、「太線」が示すオリジナルのツリー構造が「薄い」ツリー構造に置換されている。カレント記述ツリー上の１つのノードに削除（６．３）が実行されると、幾つかの分岐を伴うアドレス可能ノード（「太い」点で示されている）が適宜除去される。
ＦＭＵＩにおけるコマンドは、挿入、置換及び削除であり、これらは記憶されたカレント・ファンクション・メタデータまたは送信された初期ファンクション・メタデータの記述ツリー・ノードに直接作用する。図６は、これらを示したものである。挿入（６．１）はデフォルトで「追加」コマンドであり、ターゲット・ノード（「太い」点で示されている）の既存のチャイルド・ノード間のエレメントを追加する。追加されるエレメントの場所は明確に定義することが可能であり、カレント記述ツリー内に既に存在する第１のエレメントより前、他の２つのエレメント間または最終エレメントの後へエレメントを挿入できる。置換（６．２）は、ターゲット・ノードからのエレメントの交替を含む。図６では、「太線」が示すオリジナルのツリー構造が「薄い」ツリー構造に置換されている。カレント記述ツリー上の１つのノードに削除（６．３）が実行されると、幾つかの分岐を伴うアドレス可能ノード（「太い」点で示されている）が適宜除去される。
ファンクション・メタデータの記述を介してナビゲートしていると、各ステップでエレメント名、インデックス及びおそらくはタイプ識別子により異なる可能パスが与えられる。こういった情報の連結は、Ｘパスで表現される。
効率的な送信及び帯域幅の節約の点からすると、必ずしもＭＰＥＧ−２１ファンクション・メタデータ全体を送信してオリジナルの記述ツリーまたは記憶されたファンクション・メタデータ・ツリーを更新する必要はない。ＭＰＥＧ−２１のファンクション・メタデータ更新ユニットは、コンテキスト情報の援助により実際の更新オペレーションのために使用されなければならない。
ＭＰＥＧ−２１ファンクション・メタデータ更新インストラクタの構文と意味
本発明において特定されるＦＭＵＩツールは、ＸＭＬスキーマのネームスペース（ＸＭＬスキーマ）及び対応するネームスペースを識別するスキーマ・ラッパが供給されることを想定している。
本発明において特定されるＦＭＵＩツールは、ＸＭＬスキーマのネームスペース（ＸＭＬスキーマ）及び対応するネームスペースを識別するスキーマ・ラッパが供給されることを想定している。
<schema targetNamespace="urn:mpeg:mpeg21:2003:01-FMUI"
xmlns="urn:mpeg:mpeg21:fmui:schema:2003"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
...the actual schema elements...
</schema>
以下、スキーマの定義をその意味と共に示す。
<!--####################################################### -->
<!--Definition of general MPEG-21 functionalMetadataUpdatingCommand -->
<!--####################################################### -->
<xs:complexType name="FMUIType">
<xs:sequence>
<xs:element name="UpdatingCommand" type="BasicUpdatingCommandType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="BasicUpdatingCommandType">
<xs:sequence>
<xs:element name="UpdatingContext">
<xs:complexType>
<xs:complexContent>
<xs:extension base="NodeFieldType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NodeFieldType">
<xs:attribute name="xpath" type="xs:anyURI" use="required"/>
</xs:complexType>
<!--####################################### -->
<!-- Definition of InsertUpdatingCommand -->
<!--####################################### -->
<xs:complexType name="InsertType">
<xs:complexContent>
<xs:extension base="BasicUpdatingCommandType">
<xs:sequence>
<xs:element name="UpdatingMetadataUnit" type="UpdatingMetadataUnitType"/>
</xs:sequence>
<xs:attribute name="position" default="lastChild">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="lastChild"/>
<xs:enumeration value="prevSibling"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--####################################### -->
<!-- Definition of ReplaceUpdatingCommand -->
<!--####################################### -->
<xs:complexType name="ReplaceType">
<xs:complexContent>
<xs:extension base="BasicUpdatingCommandType">
<xs:sequence>
<xs:element name="UpdatingMetadataUnit" type="UpdatingMetadataUnitType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--################################### -->
<!-- Definition of DeleteUpdatingCommand -->
<!--################################### -->
<xs:complexType name="DeleteType">
<xs:complexContent>
<xs:extension base="BasicUpdatingCommandType"/>
</xs:complexContent>
</xs:complexType>
<!--################################### -->
<!-- Definition of UpdatingMetadataUnit -->
<!--################################### -->
<xs:complexType name="UpdatingMetadataUnitType">
<xs:choice>
<xs:element name="Ref" type="xs:anyURI"/>
<xs:element name="UpdatingMetadataUnitData" type="UpdatingMetadataUnitDataType"/>
</xs:choice>
</xs:complexType>
<!--########################################## -->
<!-- Definition of UpdatingMetadataUnitData -->
<!--########################################## -->
<xs:complexType name="UpdatingMetadataUnitDataType" mixed="false">
<xs:sequence>
<xs:element name="RequiredSchema" minOccurs="0">
<xs:complexType>
<xs:attribute name="Name" type="xs:anyURI" use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="strict"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="strict"/>
</xs:complexType>
xmlns="urn:mpeg:mpeg21:fmui:schema:2003"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
...the actual schema elements...
</schema>
以下、スキーマの定義をその意味と共に示す。
<!--####################################################### -->
<!--Definition of general MPEG-21 functionalMetadataUpdatingCommand -->
<!--####################################################### -->
<xs:complexType name="FMUIType">
<xs:sequence>
<xs:element name="UpdatingCommand" type="BasicUpdatingCommandType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="BasicUpdatingCommandType">
<xs:sequence>
<xs:element name="UpdatingContext">
<xs:complexType>
<xs:complexContent>
<xs:extension base="NodeFieldType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NodeFieldType">
<xs:attribute name="xpath" type="xs:anyURI" use="required"/>
</xs:complexType>
<!--####################################### -->
<!-- Definition of InsertUpdatingCommand -->
<!--####################################### -->
<xs:complexType name="InsertType">
<xs:complexContent>
<xs:extension base="BasicUpdatingCommandType">
<xs:sequence>
<xs:element name="UpdatingMetadataUnit" type="UpdatingMetadataUnitType"/>
</xs:sequence>
<xs:attribute name="position" default="lastChild">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="lastChild"/>
<xs:enumeration value="prevSibling"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--####################################### -->
<!-- Definition of ReplaceUpdatingCommand -->
<!--####################################### -->
<xs:complexType name="ReplaceType">
<xs:complexContent>
<xs:extension base="BasicUpdatingCommandType">
<xs:sequence>
<xs:element name="UpdatingMetadataUnit" type="UpdatingMetadataUnitType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--################################### -->
<!-- Definition of DeleteUpdatingCommand -->
<!--################################### -->
<xs:complexType name="DeleteType">
<xs:complexContent>
<xs:extension base="BasicUpdatingCommandType"/>
</xs:complexContent>
</xs:complexType>
<!--################################### -->
<!-- Definition of UpdatingMetadataUnit -->
<!--################################### -->
<xs:complexType name="UpdatingMetadataUnitType">
<xs:choice>
<xs:element name="Ref" type="xs:anyURI"/>
<xs:element name="UpdatingMetadataUnitData" type="UpdatingMetadataUnitDataType"/>
</xs:choice>
</xs:complexType>
<!--########################################## -->
<!-- Definition of UpdatingMetadataUnitData -->
<!--########################################## -->
<xs:complexType name="UpdatingMetadataUnitDataType" mixed="false">
<xs:sequence>
<xs:element name="RequiredSchema" minOccurs="0">
<xs:complexType>
<xs:attribute name="Name" type="xs:anyURI" use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="strict"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="strict"/>
</xs:complexType>
上記ＸＭＬ表記における各記述子の意味と、その記述子内に記述する内容について以下の表１から表８において示す。
本発明の実施の形態に係るデジタル・アイテム消費のためのファンクション・メタデータの更新システムについて、上記図１から図６に加えて図７Ａ、図７Ｂ、図７Ｃ、図９及び図１０を用いて以下に説明する。
図７Ａは、図２及び図３に示すメディア・リソース７．４と、ファンクション・メタデータを含むＤＩＤ文書７．５と、ファンクション・メタデータの更新ユニットを含むＤＩＤ文書７．６とをコンテンツ製作側等のプロバイダ７．１からエンドユーザ７．２に送信する場合を示す図である。図７Ｂは、プロバイダ７．１とエンドユーザ７．２との間に中間者７．３を含む場合の第１の例を示す図である。図７Ｃは、プロバイダ７．１とエンドユーザ７．２との間に中間者７．３を含む場合の第２の例を示す図である。図７Ｂの場合には、中間者７．３でファンクション・メタデータの更新ユニットを含むＤＩＤ文書７．６を生成し、エンドユーザ７．２に送信する。図７Ｃの場合には、中間者７．３がファンクション・メタデータ７．５とその更新ユニット７．６とからファンクション・メタデータを更新し、更新されたファンクション・メタデータを含むＤＩＤ文書７．７をエンドユーザ７．２に送信する。
図９は、プロバイダ７．１（図７Ａ、図７Ｃの場合）又は中間者７．３（図７Ｂの場合）においてファンクション・メタデータの更新ユニットを含むＤＩＤ文書７．６を作成するフローチャートである。
ａ）まず、ファンクション・メタデータの変更を取得する（Ｓ０１）。例えば、ファンクション・メタデータを図６に示すようなツリー構造で示した場合、ツリーの所定の末端ノードに特定ノード以下の新たなツリーが挿入される場合（６．１）、所定ノード以下のツリーを特定ノード以下の新たなツリーで置換する場合（６．２）、所定ノード以下のツリーを削除する場合（６．３）がある。
ｂ）次に、ファンクション・メタデータの変更箇所を含むファンクション・メタデータの更新ユニット５．８を生成する（Ｓ０２）。上記変更箇所について、例えば、「挿入」の場合には"InsertType"に、挿入であることが記述され、「置換」の場合には、"ReplaceType"に置換であることが記述され、「削除」の場合には、"DeleteType"に削除であることが記述される。
ｃ）その後、ファンクション・メタデータの更新ユニット５．８を含むＤＩＤ文書７．６を作成する（Ｓ０３）。図５に示すように、上記更新ユニット５．８の他、更新スキーマのヘッダ５．５、更新オペレーション５．６，更新コンテキスト５．７ファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）５．４（符号５．２も同じ）を構成する。さらにこのＦＭＵＩ５．４の他、ＤＩＤＬスキーマのヘッダ５．１、メディア・リソース５．３とを含めてＤＩＤ文書５．０（図７Ａ，図７Ｂ、図７ＣではＤＩＤ文書７．６に対応する。）が構成される。
ｄ）ファンクション・メタデータの更新ユニットを含むＤＩＤ文書７．６を端末に送信する（Ｓ０４）。
図１０は、ファンクション・メタデータの更新を行うフローチャートである。以下の説明では、図７Ａのエンドユーザにおけるファンクション・メタデータの更新について説明するが、図７Ｂ，図７Ｃの場合についても適宜説明する。
ａ）エンドユーザ７．２は、オリジナルのファンクション・メタデータを含む第１ＤＩＤ文書をプロバイダ７．１から受信する（Ｓ１１）。なお、図７Ｂの場合にも、エンドユーザ７．２は、オリジナルのファンクション・メタデータを含む第１ＤＩＤ文書７．５をプロバイダ７．１から受信するが、図７Ｃの場合には、エンドユーザ７．２は、中間者で更新されたファンクション・メタデータを含むＤＩＤ文書７．７を受信する。図７Ｃの場合には、上記更新を中間者７．３で行う。
ｂ）エンドユーザ７．２は、ファンクション・メタデータの更新ユニット５．８を含む第２ＤＩＤ文書７．６をプロバイダ７．１から受信する（Ｓ１２）。なお、図７Ｂの場合には、エンドユーザ７．２は、中間者７．３から第２ＤＩＤ文書を受信する。図７Ｃの場合には、中間者７．３がプロバイダ７．１から第２ＤＩＤ文書７．６を受信する。
ｃ）受信した第１ＤＩＤ文書７．５をＤＩＤパーサで処理する（Ｓ１３）。
ｄ）第１ＤＩＤ文書７．５からオリジナルのファンクション・メタデータを抽出する（Ｓ１４）。
ｅ）受信した第２ＤＩＤ文書７．６をＤＩＤパーサで処理する（Ｓ１５）。
ｆ）第２ＤＩＤ文書７．６からファンクション・メタデータの更新ユニット５．８を抽出する（Ｓ１６）。
ｇ）さらに、更新ユニット５．８に基づいて、ファンクション・メタデータを更新する（Ｓ１７）。この場合、更新の方法が挿入、置換、削除のいずれであるかに応じてそれぞれに対応する更新コマンドを実行して、更新したファンクション・メタデータを生成する。
ｄ）第１ＤＩＤ文書７．５からオリジナルのファンクション・メタデータを抽出する（Ｓ１４）。
ｅ）受信した第２ＤＩＤ文書７．６をＤＩＤパーサで処理する（Ｓ１５）。
ｆ）第２ＤＩＤ文書７．６からファンクション・メタデータの更新ユニット５．８を抽出する（Ｓ１６）。
ｇ）さらに、更新ユニット５．８に基づいて、ファンクション・メタデータを更新する（Ｓ１７）。この場合、更新の方法が挿入、置換、削除のいずれであるかに応じてそれぞれに対応する更新コマンドを実行して、更新したファンクション・メタデータを生成する。
なお、図７Ｃのように、ファンクション・メタデータの更新をエンドユーザ７．２ではなくプロバイダ７．１とエンドユーザ７．２との間の中間者７．３が行う場合には、更新したファンクション・メタデータを含む第３ＤＩＤ文書７．７を作成し、その更新したファンクション・メタデータを含む第３ＤＩＤ文書７．７をエンドユーザ７．２に送信する。
なお、本発明は様々な実施の形態に示される以下の構成をとることができる。第１の構成によれば、ユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法であって、
ＤＩＤ（デジタル・アイテム宣言）と共に幾つかの処理モジュールを統合してサーバを構築するステップであって、他の処理モジュールは、限定されるものではないが、更新モジュールと、記述コンポーザと、メディア・リソース・リゾルバと、ファンクション・メタデータ・エクストラクタと、メタデータ・データベース記憶装置と、ＭＰＥＧ−２１エレメント・プロセッサ／パーサと、メディア・リソース・プリプロセッサ他とを含む、サーバを構築するステップと、
上記ＤＩＤプロセッサ／パーサによりＤＩＤ入力を処理し、上記ＤＩＤ入力のエレメントの各々を解釈しかつ関連結果を関連の処理モジュールへ回送するステップと、
送信されたオリジナルのデジタル・アイテム識別と、保護及びアダプテーション関連記述とを含むファンクション・メタデータを抽出してメタデータ・データベースへ記憶する、もしくはＭＰＥＧ−２１エレメント・プロセッサ／パーサへ直接送信するステップと、
その後の処理のためにＤＩＤでバインドされた実メディア・ストリームを形成する、またはＵＲＩからダウンロードするステップと、
上記サーバにおいて標準化されたスキーマを基礎として上記更新モジュールを構築し、受信されたコンテキストＤＩＤからファンクション・メタデータ・ユニット・インストラクタ・コンテナを抽出しかつ内部の更新コンテキスト情報と、更新コマンドと、伝達された更新メタデータ・ユニットとを上記サーバにおいて解釈するステップであって、既に標準化されたスキーマはファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である、ステップと、
記述コンポーザによる更新モジュールからの処理された結果を基礎として上記記憶された、または送信されたオリジナルのファンクション・メタデータを更新するステップと、
上記更新されたＭＰＥＧ−２１ファンクション・メタデータの援助によって上記実メディア・ストリームを処理するステップであって、即ち、新たなＤＩＩ識別スキームを基礎としてメディア・コンポーネントを（再度）識別し、新たなＤＩＡ記述メタデータを基礎として（再度）適応させ、詳細な新規ＲＥＬ条件／使用規則をチェックしかつ実行し、新たなＩＰＭＰツール情報他を基礎として復号化（かつ再暗号化）するステップと
を含む方法である。
ＤＩＤ（デジタル・アイテム宣言）と共に幾つかの処理モジュールを統合してサーバを構築するステップであって、他の処理モジュールは、限定されるものではないが、更新モジュールと、記述コンポーザと、メディア・リソース・リゾルバと、ファンクション・メタデータ・エクストラクタと、メタデータ・データベース記憶装置と、ＭＰＥＧ−２１エレメント・プロセッサ／パーサと、メディア・リソース・プリプロセッサ他とを含む、サーバを構築するステップと、
上記ＤＩＤプロセッサ／パーサによりＤＩＤ入力を処理し、上記ＤＩＤ入力のエレメントの各々を解釈しかつ関連結果を関連の処理モジュールへ回送するステップと、
送信されたオリジナルのデジタル・アイテム識別と、保護及びアダプテーション関連記述とを含むファンクション・メタデータを抽出してメタデータ・データベースへ記憶する、もしくはＭＰＥＧ−２１エレメント・プロセッサ／パーサへ直接送信するステップと、
その後の処理のためにＤＩＤでバインドされた実メディア・ストリームを形成する、またはＵＲＩからダウンロードするステップと、
上記サーバにおいて標準化されたスキーマを基礎として上記更新モジュールを構築し、受信されたコンテキストＤＩＤからファンクション・メタデータ・ユニット・インストラクタ・コンテナを抽出しかつ内部の更新コンテキスト情報と、更新コマンドと、伝達された更新メタデータ・ユニットとを上記サーバにおいて解釈するステップであって、既に標準化されたスキーマはファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である、ステップと、
記述コンポーザによる更新モジュールからの処理された結果を基礎として上記記憶された、または送信されたオリジナルのファンクション・メタデータを更新するステップと、
上記更新されたＭＰＥＧ−２１ファンクション・メタデータの援助によって上記実メディア・ストリームを処理するステップであって、即ち、新たなＤＩＩ識別スキームを基礎としてメディア・コンポーネントを（再度）識別し、新たなＤＩＡ記述メタデータを基礎として（再度）適応させ、詳細な新規ＲＥＬ条件／使用規則をチェックしかつ実行し、新たなＩＰＭＰツール情報他を基礎として復号化（かつ再暗号化）するステップと
を含む方法である。
第２の構成によれば、上記サーバが実行する全てのステップは中間のＳＴＢ、ゲートウェイ及びプロキシにも適用可能である前記ユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法である。
第３の構成によれば、ユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法であって、
ＤＩＤ（デジタル・アイテム宣言）と共に幾つかの処理モジュールを統合してエンドユーザ端末を構築するステップであって、他の処理モジュールは、以下のものに限定されるものではないが、更新モジュールと、記述コンポーザと、メディア・リソース・リゾルバと、ファンクション・メタデータ・エクストラクタと、メタデータ・データベース記憶装置と、ＭＰＥＧ−２１エレメント・プロセッサ／パーサと、メディア・リソース・プリプロセッサと、メディア・プレーヤ他とを含む、ステップと、
上記ＤＩＤプロセッサ／パーサによりＤＩＤ入力を処理し、上記ＤＩＤ入力のエレメントの各々を解釈しかつ関連結果を関連の処理モジュールへ回送するステップと、
送信されたオリジナルのデジタル・アイテム記述と、保護及びアダプテーション関連記述とを含むファンクション・メタデータを抽出してメタデータ・データベースへ記憶する、もしくはＭＰＥＧ−２１エレメント・プロセッサ／パーサへ直接送信するステップと、
その後の処理のためにＤＩＤでバインドされた実メディア・ストリームを形成する、またはＵＲＩからダウンロードするステップと、
上記エンドユーザ端末においてファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である標準化されたスキーマを基礎として上記更新モジュールを構築し、受信されたコンテキストＤＩＤからファンクション・メタデータ・ユニット・インストラクタ・コンテナを抽出しかつ内部の更新コンテキスト情報と、更新コマンドと、伝達された更新メタデータ・ユニットとを上記エンドユーザ端末において解釈するステップと、
記述コンポーザによる更新モジュールからの処理された結果を基礎として上記記憶された、または送信されたオリジナルのファンクション・メタデータを更新するステップと、
上記更新されたＭＰＥＧ−２１ファンクション・メタデータの援助によって上記実メディア・ストリームを処理するステップ、即ち、新たなＤＩＩ識別スキームを基礎としてメディア・コンポーネントを識別し、新たなＤＩＡ記述メタデータを基礎として適応させ、詳細な新規ＲＥＬ条件／使用規則をチェックしかつ実行し、新たなＩＰＭＰツール情報他を基礎として復号化するステップと、
上記エンドユーザ端末におけるメディア・プレーヤにより上記メディア・ストリームを消費するステップと
を含む方法である。
ＤＩＤ（デジタル・アイテム宣言）と共に幾つかの処理モジュールを統合してエンドユーザ端末を構築するステップであって、他の処理モジュールは、以下のものに限定されるものではないが、更新モジュールと、記述コンポーザと、メディア・リソース・リゾルバと、ファンクション・メタデータ・エクストラクタと、メタデータ・データベース記憶装置と、ＭＰＥＧ−２１エレメント・プロセッサ／パーサと、メディア・リソース・プリプロセッサと、メディア・プレーヤ他とを含む、ステップと、
上記ＤＩＤプロセッサ／パーサによりＤＩＤ入力を処理し、上記ＤＩＤ入力のエレメントの各々を解釈しかつ関連結果を関連の処理モジュールへ回送するステップと、
送信されたオリジナルのデジタル・アイテム記述と、保護及びアダプテーション関連記述とを含むファンクション・メタデータを抽出してメタデータ・データベースへ記憶する、もしくはＭＰＥＧ−２１エレメント・プロセッサ／パーサへ直接送信するステップと、
その後の処理のためにＤＩＤでバインドされた実メディア・ストリームを形成する、またはＵＲＩからダウンロードするステップと、
上記エンドユーザ端末においてファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である標準化されたスキーマを基礎として上記更新モジュールを構築し、受信されたコンテキストＤＩＤからファンクション・メタデータ・ユニット・インストラクタ・コンテナを抽出しかつ内部の更新コンテキスト情報と、更新コマンドと、伝達された更新メタデータ・ユニットとを上記エンドユーザ端末において解釈するステップと、
記述コンポーザによる更新モジュールからの処理された結果を基礎として上記記憶された、または送信されたオリジナルのファンクション・メタデータを更新するステップと、
上記更新されたＭＰＥＧ−２１ファンクション・メタデータの援助によって上記実メディア・ストリームを処理するステップ、即ち、新たなＤＩＩ識別スキームを基礎としてメディア・コンポーネントを識別し、新たなＤＩＡ記述メタデータを基礎として適応させ、詳細な新規ＲＥＬ条件／使用規則をチェックしかつ実行し、新たなＩＰＭＰツール情報他を基礎として復号化するステップと、
上記エンドユーザ端末におけるメディア・プレーヤにより上記メディア・ストリームを消費するステップと
を含む方法である。
第４の構成によれば、ユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法であって、
ファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である標準化されたスキーマを基礎としてメディア・リソース制作／配信ピアにおいて上記ピアが更新メタデータ・ユニットを簡単に、オフラインまたはリアルタイムで作成するために使用されるオーサリング・ツールを構築するステップと、
コンテンツのプロバイダ及び配信業者の要件を基礎としてＭＰＥＧ−２１ファンクション・メタデータの更新が要求されると、上記オーサリング・ツールを使用して更新コンテキストと、更新コマンドと、実更新メタデータ・ユニットとでＦＭＵＩコンテナを構成するステップと、
上記更新コンテナをＤＩＤ文書内に包含してコンテキスト・デジタル・アイテムを形成し、マルチメディア・リソースとの実際のコンテンツ・デジタル・アイテムの制御されたアクセスを達成するステップと、
上記ＤＩＤ文書を上記制作／配信ピアから受信側ピアへ送信し、記憶されたオリジナルのファンクション・メタデータまたは送信された初期ファンクション・メタデータに作用してこれを更新するステップと
を含む方法である。
ファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である標準化されたスキーマを基礎としてメディア・リソース制作／配信ピアにおいて上記ピアが更新メタデータ・ユニットを簡単に、オフラインまたはリアルタイムで作成するために使用されるオーサリング・ツールを構築するステップと、
コンテンツのプロバイダ及び配信業者の要件を基礎としてＭＰＥＧ−２１ファンクション・メタデータの更新が要求されると、上記オーサリング・ツールを使用して更新コンテキストと、更新コマンドと、実更新メタデータ・ユニットとでＦＭＵＩコンテナを構成するステップと、
上記更新コンテナをＤＩＤ文書内に包含してコンテキスト・デジタル・アイテムを形成し、マルチメディア・リソースとの実際のコンテンツ・デジタル・アイテムの制御されたアクセスを達成するステップと、
上記ＤＩＤ文書を上記制作／配信ピアから受信側ピアへ送信し、記憶されたオリジナルのファンクション・メタデータまたは送信された初期ファンクション・メタデータに作用してこれを更新するステップと
を含む方法である。
第５の構成によれば、ユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法であって、
ファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である標準化されたスキーマを基礎としてエンドユーザ端末において上記端末が更新メタデータ・ユニットを簡単に、オフラインまたはリアルタイムで作成するために使用されるオーサリング・ツールを構築するステップと、
エンドユーザのプレファレンスを基礎としてＭＰＥＧ−２１ファンクション・メタデータの更新が要求されると、上記オーサリング・ツールを使用して更新コンテキストと、更新コマンドと、実更新メタデータ・ユニットとでＦＭＵＩコンテナを構成するステップと、
上記更新コンテナをＤＩＤ文書内に包含してコンテキスト・デジタル・アイテムを形成し、マルチメディア・リソースとの実際のコンテンツ・デジタル・アイテムの制御されたアクセスを達成するステップと、
上記ＤＩＤ文書を上記エンドユーザ端末から受信側ピアへ送信し、記憶されたオリジナルのファンクション・メタデータまたは送信された初期ファンクション・メタデータに作用してこれを更新するステップと
を含む方法である。
ファンクション・メタデータ更新インストラクタ（ＦＭＵＩ）スキーマ及び言語である標準化されたスキーマを基礎としてエンドユーザ端末において上記端末が更新メタデータ・ユニットを簡単に、オフラインまたはリアルタイムで作成するために使用されるオーサリング・ツールを構築するステップと、
エンドユーザのプレファレンスを基礎としてＭＰＥＧ−２１ファンクション・メタデータの更新が要求されると、上記オーサリング・ツールを使用して更新コンテキストと、更新コマンドと、実更新メタデータ・ユニットとでＦＭＵＩコンテナを構成するステップと、
上記更新コンテナをＤＩＤ文書内に包含してコンテキスト・デジタル・アイテムを形成し、マルチメディア・リソースとの実際のコンテンツ・デジタル・アイテムの制御されたアクセスを達成するステップと、
上記ＤＩＤ文書を上記エンドユーザ端末から受信側ピアへ送信し、記憶されたオリジナルのファンクション・メタデータまたは送信された初期ファンクション・メタデータに作用してこれを更新するステップと
を含む方法である。
第６の構成によれば、記憶されたオリジナルのファンクション・メタデータまたは送信された初期ファンクション・メタデータを更新するために送信者ピアから上記受信側ピアへ送られる上記ＤＩＤ文書は、ＢｉＭのようなテクノロジーを使用してバイナリ形式で実装され効率的に送信されることが可能な請求項４または５記載のユニバーサル・マルチメディア・アクセス・フレームワークにおけるデジタル・アイテム消費のためのファンクション・メタデータの更新方法である。
なお、図３のピア構成の各機能ブロックは典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。例えば、メモリ以外の機能ブロックが１チップ化されていてもよい。ここではＬＳＩとして説明したが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されるものであってもよい。
また、集積回路化の手法はＬＳＩに限られるものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、そのような技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術等の適応等も可能性としてありうる。
また、各ブロックのうち、記憶装置（３．１１又は３．１２）は、１チップ化せずに別構成としてもよい。
上述の通り、本発明は好ましい実施形態により詳細に説明されているが、本発明はこれらに限定されるものではなく、以下の特許請求の範囲に記載された本発明の技術的範囲内において多くの好ましい変形例及び修正例が可能であることは当業者にとって自明なことであろう。
Claims (11)
- デジタル・アイテム消費のためのファンクション・メタデータの更新システムであって、デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを端末に送信するサーバと、前記サーバから受信した前記第２ＤＩＤ文書に含まれる前記ファンクション・メタデータの更新ユニットを用いて前記ファンクション・メタデータを更新する端末とを備え、
前記サーバは、
前記デジタル・アイテムの前記ファンクション・メタデータを含む第１ＤＩＤ文書と、前記ファンクション・メタデータの更新箇所に関するファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを作成するＤＩＤ文書作成部と、
前記デジタル・アイテムと、前記デジタル・アイテムの第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記端末に送信する送信部と
を備え、
前記端末は、
前記デジタル・アイテムと、前記デジタル・アイテムの前記第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む前記第２ＤＩＤ文書とを前記サーバからに受信する受信部と
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するファンクション・メタデータ抽出部と、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出する更新モジュールと、
前記ファンクション・メタデータの更新ユニットに基づいて前記ファンクション・メタデータを更新する記述コンポーザと
を備える
ことを特徴とするデジタル・アイテム消費のためのファンクション・メタデータの更新システム。 - デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを端末に送信するサーバであって、
前記デジタル・アイテムの前記ファンクション・メタデータを含む第１ＤＩＤ文書と、前記ファンクション・メタデータの更新箇所に関するファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書を作成するＤＩＤ文書作成部と、
前記デジタル・アイテムと、前記デジタル・アイテムの第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記端末に送信する送信部と
を備えることを特徴とするサーバ。 - デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記サーバから受信して、前記ファンクション・メタデータを更新する端末であって、
前記デジタル・アイテムと、前記デジタル・アイテムの前記第１ＤＩＤ文書と、前記ファンクション・メタデータの更新ユニットを含む前記第２ＤＩＤ文書とを前記サーバからに受信する受信部と
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するファンクション・メタデータ抽出部と、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出する更新モジュールと、
前記ファンクション・メタデータの更新ユニットに基づいて前記ファンクション・メタデータを更新する記述コンポーザと
を備えることを特徴とする端末。 - デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記サーバから受信して、前記ファンクション・メタデータを更新する方法であって、
前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信するステップと、
前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信するステップと、
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するステップと、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出するステップと、
前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得るステップと
を含むデジタル・アイテム消費のためのファンクション・メタデータの更新方法。 - 抽出した前記ファンクション・メタデータをメタデータ・データベースへ記憶するステップをさらに含むことを特徴とする請求項４に記載のデジタル・アイテム消費のためのファンクション・メタデータの更新方法。
- 請求項４又は５に記載のデジタル・アイテム消費のためのファンクション・メタデータの更新方法の各ステップをコンピュータ上で実行させるデジタル・アイテム消費のためのファンクション・メタデータの更新用コンピュータ・プログラム。
- 請求項６に記載のデジタル・アイテム消費のためのファンクション・メタデータの更新用コンピュータ・プログラムが記録されたことを特徴とするコンピュータ読み取り可能な記録媒体。
- デジタル・アイテムと、前記デジタル・アイテムのファンクション・メタデータの第１デジタル・アイテム宣言（ＤＩＤ）文書と、前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書とを前記サーバから受信して、前記ファンクション・メタデータを更新し、前記更新したファンクション・メタデータを用いて前記デジタル・アイテムを処理する方法であって、
前記デジタル・アイテムのファンクション・メタデータを含む第１ＤＩＤ文書をサーバから受信するステップと、
前記ファンクション・メタデータの更新ユニットを含む第２ＤＩＤ文書をサーバから受信するステップと、
前記第１ＤＩＤ文書から前記ファンクション・メタデータを抽出するステップと、
前記第２ＤＩＤ文書から前記ファンクション・メタデータの更新ユニットを抽出するステップと、
前記更新ユニットに基づいて、前記ファンクション・メタデータを更新して更新したファンクション・メタデータを得るステップと、
前記更新されたファンクション・メタデータに基づいて前記デジタル・アイテムを処理するステップと
を含むことを特徴とするデジタル・アイテムの処理方法。 - 前記デジタル・アイテムを処理するステップは、
ｉ）前記更新されたファンクション・メタデータに含まれる新たなＤＩＩ識別スキームを用いて前記デジタル・アイテムを識別するか、
ｉｉ）前記更新されたファンクション・メタデータに含まれる新たなＤＩＡ記述メタデータを用いて前記デジタル・アイテムを適応させるか、
ｉｉｉ）前記更新されたファンクション・メタデータに含まれる新規ＲＥＬ条件／使用規則をチェックし、かつ実行するか、
ｉｖ）前記更新されたファンクション・メタデータに含まれる新たなＩＰＭＰツール情報を基礎として前記デジタル・アイテムを復号化するか、
のｉ）〜ｉｖ）のうちの少なくとも一つを行うことを特徴とする請求項８に記載のデジタル・アイテムの処理方法。 - 請求項８又は９に記載のデジタル・アイテムの処理方法の各ステップをコンピュータ上で実行させるデジタル・アイテムの処理用コンピュータ・プログラム。
- 請求項１０に記載のデジタル・アイテムの処理用コンピュータ・プログラムが記録されたことを特徴とするコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004269721A JP2005122714A (ja) | 2003-09-19 | 2004-09-16 | デジタル・アイテム消費のためのファンクション・メタデータの更新方法 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003328125 | 2003-09-19 | ||
| JP2004269721A JP2005122714A (ja) | 2003-09-19 | 2004-09-16 | デジタル・アイテム消費のためのファンクション・メタデータの更新方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005122714A true JP2005122714A (ja) | 2005-05-12 |
Family
ID=34621859
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004269721A Pending JP2005122714A (ja) | 2003-09-19 | 2004-09-16 | デジタル・アイテム消費のためのファンクション・メタデータの更新方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005122714A (ja) |
-
2004
- 2004-09-16 JP JP2004269721A patent/JP2005122714A/ja active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Lugmayr et al. | Digital interactive TV and metadata | |
| JP4323323B2 (ja) | ディジタルアイテムの適合方法およびそのシステム | |
| US20040139023A1 (en) | Method for implementing mpeg-21 ipmp | |
| JP2003132173A (ja) | 電子メディア・コンテナ | |
| US20040093337A1 (en) | Unified rights management for ipmp system | |
| CN1331081C (zh) | 传送用于指定知识产权管理与保护工具的信息的方法 | |
| JP4447841B2 (ja) | Ｍｐｅｇ−２１アーキテクチャにおけるデジタル・アイテムに対するｉｐｍｐスキーム記述の方法 | |
| Rump | Can digital rights management be standardized? | |
| TW200407857A (en) | Digital video recorder and methods for digital recording | |
| KR20030008354A (ko) | 멀티미디어 컨텐츠 묘사 정의 방법 | |
| KR101351520B1 (ko) | 포렌식마크 삽입장치 및 방법 | |
| JP2005122714A (ja) | デジタル・アイテム消費のためのファンクション・メタデータの更新方法 | |
| WO2005029331A1 (ja) | デジタル・アイテム消費のためのファンクション・メタデータの更新方法 | |
| Burnett et al. | An Introduction to MPEG‐21 | |
| JP2003199063A (ja) | 知的財産管理・保護システムでの統合的権利管理 | |
| JP2004213353A (ja) | マルチメディアコンテンツの配信方法、再生方法、配信装置および再生装置 | |
| Carvalho et al. | A unified data model and system support for the context-aware access to multimedia content. | |
| WO2007006090A1 (en) | Systems and methods for use in transforming electronic information into a format | |
| JP2006059145A (ja) | フレキシブルｉｐｍｐ保護スキームによるデジタル・コンテンツの制御および保護のための方法および装置 | |
| Pereira et al. | Future MPEG developments | |
| Alliance | DRM Content Format V2. 0 | |
| Thomas-Kerr et al. | Enhancing interoperability via generic multimedia syntax translation | |
| Huang et al. | Management and protection of digital content with the flexible IPMP scheme: MPEG-21 IPMP | |
| KR100665308B1 (ko) | 엠펙-21 멀티미디어 프레임워크에서의 필요한 툴 서비스방법 및 그 시스템 | |
| Timmerer et al. | The semantics of mpeg-21 digital items revisited |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20061206 |