WO2004104829A1

WO2004104829A1 - デジタルアイテムの処理方法および装置

Info

Publication number: WO2004104829A1
Application number: PCT/JP2004/007229
Authority: WO
Inventors: Zhongyang Huang; Sheng Mei Shen; Ming Ji; Jing Liu; Takanori Senoh
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2003-05-23
Filing date: 2004-05-20
Publication date: 2004-12-02

Abstract

多様な処理エンジン間において特定の方法で通信を容易にするための、シンタックスとセマンティクスを備えた汎用メッセージ構造を定義することにより、異なるアプリケーション用の異なるＭＰＥＧ−２１端末に最大限の柔軟性及び相互動作性を持たせて幅広く利用できるようにする。定義されたメッセージＡＰＩを備えたＭＰＥＧ−２１端末又はＭＰＥＧ−２１モジュールを構築し、異なるベンダーから提供される異なる処理エンジンを特定の方法で共に動作させる。

Description

明細書デジタルアイテムの処理方法および装置技術分野

本発明は、デジタルアイテムの処理方法および装置に関し、更に詳しくは、ュ二バーサル .マルチメディア■アクセス ·フレームワークにおいて存在し、フォ一マツトの異なるマルチメディア · リソースにアクセスするためにその内部が使用される様々なモジュールの処理を行うことができる、統一マルチメディァ端末に関する。特に、多様な処理モジユー Λ ^間の内部通信メカニズム及びフォーマツトに関する。背景技術

M P E G及びその他の標準化団体は、ビデオ、オーディオ、システム、通信プロトコル、コンテンツ表現、コンテンツ 'パッケージング等に関して、ある場所力ら別の場所へのコンテンツの転送及び提供を効率的な方法で容易に行えるように、また大容量のコンテンツを限られたスペース内に容易に記憶できるようにするために、数多くの規格を制定してきた。

ユニバーサル .マルチメディア ·アクセス■フレームワークは、複数のアプリケーシヨン ' ドメインにおける異なるカテゴリーのユーザによる、あらゆる種類のコンテンツの提供及び使用をサポートすることが可能な環境で、構築する必要がある。このようなフレームワークでは、共用ビジョン、つまりロードマップがそのァーキテクトによって理解され、確実に、メディア · リソースを提供するシステムが相互動作可能でトランザクションが簡単に行われることが要求される。このことは、コンテンツの提供、コンテンツのセキュリティー、権利管理、確実な支払い、及びこれらを可能にする技術に関するインフラストラクチャ一の要件にも当てはまる。つまり、コンテンツ所有者、アーティスト、エンドユーザ、サ一ビスプロバイダ、及ぴ C E製造業者の全ての人は、このフレームワークが各自の目的をサポートするものであることがわかる。デジタルアイテム（D I ： D i g i t a 1 I t em) とは、当該フレームヮーク内における標準の表現、識別及び記述で構成されたデジタル対象物であると定義されている。この実体は、 MPEG— 21のフレームワーク内での配信及ぴトランザクションの基本単位でもあり、その目的は D Iの電子商取引を可能にすることである。このフレームワークに基づいて、既に入念に開発された、又は現在開発中の主要技術がいくつかある。例えば、デジタルアイテム宣言（D ID : D i g i t a l I t em De c l a r a t i o n) は、その構成要素と構造 (つまりリソースとメタデータ）という見地からマルチメディア■コンテンツを定義することを目的とした規格であり、 D I Dは XMLで記述される。

D I Dに加えて、デジタルアイテム識別 (D I I ： D i g i t a 1 I t em

I d e n t i f i c a t i on) 、デジタルアイテム適応 (D I A : D i g i t a 1 I t em Ad a p t a t i o n) 、知的財産管理保護 ( I PMP： I n t e l l e c t u a l P r o p e r t y Ma n a g eme n t a nd P r o t e c t i o n〉、権禾 [|記述 ggg- (REL : R i gh t s E r e s s i o n La n g u a g e) /権利データ辞書 (RDD： R i g h t s D a t a D i c t i o n a r y) , 及びィベント報告（ER : Ev e n t R e p o r t i n g) は、 MPEG— 21を形成する重要な技術である。

いかなるトランザクションでも、当該トランザクションの対象を特定する必要性及びその手段がある。 D I Iは、独自に D Iを特定し、 I SBNが書籍に対して行うのと同様の役割を果たす。

かってコンテンップロバイダゃサ一ビスプロバイダは、各自の顧客を熟知しており、また各自のコンテンツを配信する手段も熟知し、又はこれを制御してきた。同時に、消費者は、テレビ、映画、音楽等の、はっきりと分類されたサービスの意味を理解していた。し力し今日、我々のこのような確信は揺らいでいる。ェンドユーザはかってなく予測不能であり、同一のコンテンツが多様な提供システムによって届けられ、様々な異なる消費装置でこれらを楽しむことができる。 D I Aは、 D I力ユーザ、ネットワーク及び装置のプロパティの具体的な特徴に最適になるよう、これをどのように適応させる（変形させる）べきかを記述する手段の提供を行う。 D IAの仕様は、基本的な利用環境記述ツール、 D I リソース適応ツール、 D I D適応ツールを定義する。

D Iを管理し保護する I PMPのアーキテクチャは、 D Iバリューチェーンのあらゆるメンバーによる D Iの配信、管理、及び利用に関連する、権利、条件、結果及び責務（RELZRDD情報）の記述と施行を提供する。ここでは、 D I に関わる I PMPをできるだけ詳細に記述する手段と、当該アーキテクチャを持つトラストの役割と、 D I管理及び利用可能性が、委託された実体が保証する特定の基準を満たすことを主張する能力等の機能のための端末要件に支えられた相互動作†生とを定義する必要がある。

ERの目的は、あらゆる報告可能なイベントのパフォーマンスに関する測定基準とインターフェースを提供することである。マルチメディア 'フレームワークでこれを標準化する必要性は、複数の端末とユーザーとの間、又は 1つの端末内において、いかなる時点でも、 D I及び Z又はこれによつて作動するプログラム、装置、端末内部モジュールに関するイベントを監視し、通信する必要性から発生している。

先行技術である I SO/I EC 21000— 2 ： MPEG— 21 D I Dを図

1に示し、 D I D (コンテンツ構成要素及びその構造）に静的 I PMP記述子及び D I A記述子情報を含むことが可能である現状について述べる。 D I宣言（モジュール 1. 1 ) は、いくつかの基本トランザクション単位 D I (モジ.ュル 1. 2、 1. 3、 1. 4) で構成され、プロバイダからユーザへ提供される。当該宣言内では、いくつかの重要な I PMP記述子情報（モジュール 1. 5) 及び D I A記述子情報（モジュール 1. 6) も、 D I トランザクションの保護及び適応に関するマルチメディア ·フレームワークを支えるために伝送される。 RELZR DD記述子情報及び E R記述子情報についても、同様の状況が当てはまる。

図 2に、他の先行技術である I SO/I ES JTC 1/SC29 /WG 11 /N 5621 : MPEG- 21 D I Pを示す。ここで、 D I Dエンジンはモジユール 2. 1に示されており、 D I Iエンジンはモジュール 2. 2に、 I PMP エンジンはモジユーノレ 2. 3に、 RE Lエンジンはモジユーノレ 2. 4に、 RDD エンジンはモジユーノレ 2. 5に、 D I Aエンジンはモジユーノレ 2. 6に、 ERェンジンはモジュール 2. 7にそれぞれ示されている。 D I D、 D I I、 I PMP、 REL/RDD、 D IA、 E R等の異なる技術要素の処理に使用できるこれらの処理エンジンは、 MPEG— 21の範囲内に一定の標準部分を伴って定義されている。

モジュール 2. 8における処理エンジンとデジタルアイテム方法エンジン（D I ME： D i g i t a l I t em Me t ho d En g i n e) との間の関係、モジュール 2. 9における D IMEとユーザとの間の関係、またモジュール 2. 10における D I MEとデジタルアイテム基本動作（D I BO： D i g i t a 1 I t em Ba s e Op e r a t i o n s) との間に関係については、可能性を示しているに過ぎない。 D I MEとサブ処理エンジンとの間の実際の通信は、相互動作可能な情報伝送の駆動についてはまだ定義されていない。

更に、これらの処理エンジン間の関係は、まだ全く特定されていない。しかし、いかなるアプリケーションであっても、一方の処理エンジンから他方のエンジンへの通信は必要である。例えば、図 1に示すように、 D I D記述は I PMP記述子を含むが、 D I Dエンジンから I PMPエンジンを呼び出した方が、 D IMェンジンに戻ってから I PMPエンジンを呼び出すよりも、より適切かつ迅速である。別の例として、 D I A記述子は D I D記述に含まれるが、 D I Dエンジンから D I Aエンジンを呼び出した方が、 D I Mエンジンに戻ってから D I Aェンジンを呼び出すよりも、より適切かつ迅速である。別のアプリケーシヨンでは. I . PMP記述は R E L記述子を含んでもよく、 R E L記述は RDD記述子を含んでもよい。また D I I記述が ER記述子を含んでもよい。従って、これらのェンジンは全て、相互に通信可能な能力が必要である。この通信は、端末内通信とも呼ばれ、特に、他のエンジンによって処理されたあらゆる処理情報が ERエンジンへ又は ERエンジンから伝送されなければならないイベント報告処理については、このように呼ばれている。発明の開示

(発明が解決しようとする技術的課題）

本発明は、以下の問題を解決することを課題とする。

即ち、 MPEG— 21で定義されるシステム構造は、先行技術に示されるように、処理シーケンスが固定された順序及びパターンを取らず次の行動を予測できない、多様なアプリケーションをカバーすることを目的としている。し力し、処理結果は一方のエンジンから他方のェンジンへと伝送しなければならず、またそれは、その時点におけるユーザのオンラインでの嗜好によって異なる場合もある。従って、これらの処理エンジンが相互に情報を転送できるよう、汎用通信メカ- ズムを設定し、定義する必要がある。

周知の通り、先行技術に示されるシステムは、多様な処理エンジン又はモジュールから構成されており、これらは同一のベンダーから提供されるものではない場合もある。し力し、このような多様なモジュール間で、情報を転送し共用しなければならない。これらの多様な処理モジュールを統合して規格に準拠する端末を構築する場合は、これらの処理エンジンが相互に情報を転送できるように、汎用通信メカニズムを設定し、定義する必要がある。

すなわち、従来の処理方法にあっては、中央制御エンジンである D I Mェンジンを中心として、放射状に種々のエンジンにデータを送り、再び D I Mエンジンに戻され、続いて別のエンジンにデータが送り出されるような、ハブ型制御モードのみで処理されていた。

このような通信メカニズムは、情報の送信先又は発信元、そのメッセージへの応答、及び特定のフォーマットの情報本体を示す汎用構造を備える必要がある。 - (その解決方法）

多様な M P E G - 2 1モジュールで使用できる汎用メッセージ構造を備えた一連のメッセージを定義することにより、これらのモジュール間の通信を、 MP E G - 2 1端末内で特定の方法で行うことができる。

基本メッセージ構造を使用し、内部 MP E G - 2 1モジュール交渉メッセージ内で共通インフラストラクチャーを記述することにより、あらゆるタイプのメッセージによって容易に拡張することができる。

各送信メッセージに I Dを割り当てて識別システムを構築することにより、いかなる応答メッセージも、同一 I Dを持つメッセージへの応答であることが認識される。モジュール名を使用して、 MP E G— 2 1端末内でメッセージの送信側又は受信側を示すことにより、送信メッセージ又は応答メッセージのいずれについても、明確かつ直接的に行き先が示される。

異なるタイプのメッセージを使用して、現行メッセージが送信用か、要請用か、又は応答用かを示す。

拡張メッセージ構造にメッセージ情報本体を含めることにより、一方のモジュールから他方のモジュールへ送信 Z要請 Z応答されると思われる実際の情報を伝送する。

(作用）

M P E G— 2 1端末は、パーサを備えた D I Dモジュール、パーサを備えた D

I Iモジュール、パーサを備えた D I Aモジュール、パーサを備えた R E L/R D Dモジュール、パーサを備えた I PM Pモジュール、パーサを備えた E Rモジュール等の多様な処理モジュールで構成される。

D I D文書は MP E G— 2 1端末に提供され、パーサを備えた D I Dモジユーノレは、端末の入口ドアのような役割をして D I D文書を開き、 D I D文書の処理を行う。

処理結果は、ユーザに直接提供されることもあれば、次の処理のために次のモジュールに伝送されることもある。後者の場合、メッセージは次のモジュールへ. 直接送信されるカ又は制御エンジン D I MEを介して送信されなければならない。 D I MEは中央ルータのようなものであり、異なる方法 Z動作を取り扱い、ユーザからの入力を受け取ると考えられる。このようなメッセージ構造は、メッセージ I Dと、送信側モジュ一ルの名前と、受信側モジュ一ルの名前と、メッセージ情報本体とから構成される。メッセージ受信側モジュールは、送信側モジュールに対して「G o N o G o」情報で応答し、送信側モジュールの処理を中止させる力、又は送信側モジュールに処理を行わせる。

中には、別のモジュールに自身が処理する情報を要請する動作を行うことができるモジュールもある。当該メッセージの受信側は、送信側が要請している実際のメッセージを応答する。

一方のモジュール内で処理が終了すると、他方のモジュールに別の情報を送信する必要がある場合があり、定義されたメッセージ構造に従って、同様の方法で一方のモジュールから他方のモジュールへと通信が継続される。

本発明の第 1の観点は、マルチメディア 'フレームワークに基づく信号を受信し、そこに含まれるデジタルアイテムの処理方法であって、

コンテンッ構成要素及びその構造が示されるデジタルアイテム宣言である D I Dを処理する D I D処理ステップと、

前記 D I Dに含まれる基本動作を解釈し、デジタルアイテム方法である D IM により処理する D IM処理ステップと、

次の処理ステツプの内少なくともひとつの他の処理ステツプ

1) デジタルアイテム識別である D I Iにより処理する D I I処理ステツプ、

2) 権利記述言語である RELにより処理する R E L処理；

3) 権利データ辞書である RDDにより処理する RDD処理二

4) 知的財産管理保護である I PMPにより処理する I PMP処理ステツプ、

5) デジタルアイテム適応である D I Aにより処理する D I A処理ステツプ、

6) ィベント報告である E Rにより処理する E R処理ステップ、とを有し、

D ID処理ステップ、 D IM処理ステップ、他の処理ステップの内いずれか 2 つの処理ステップ間で直接データの送受信がなされることを特徴とする処理方法である。

本発明の第 2の観点は、上記各処理ステップにおいて、送信元と送信先を特定するメッセージである I n t e r n a lMe s s a g e標識を用いることを特徴とする、処理方法である。

本発明の第 3の観点は、前記 I n t e r n a lMe s s a g e標識は、送信用の T r a n sm i tTyp eと、要請用の R e q u e s tTy p eと、応答用の Re s p o n s e Ty p eに分かれていることを特徴とする処理方法である。本発明の第 4の観点は、前記 I n t e r n a lMe s s a g e標識には、ひとつのテーマに対し、ひとつのメッセージ識別子である Ms g— IDが含まれていることを特徴とする処理方法である。

本発明の第 5の観点は、前記送信用の T r a n smi tTy p eの I n t e r n a 1 Me s s a g e標識には、伝送及ぴ交換される情報の種類を特定する I n f o rma t i o nC l a s s標識を含むことを特徴とする処理方法である。本発明の第 6の観点は、前記要請用の R 6 (111 6 3 1：丁7 6の1 11 七 6 ]： 11 a 1 Me s s a g e標識には、伝送及び交換される情報の種類を特定する I n f o rma t i o nC l a s s標識を含むことを特徴とする処理方法である。

本発明の第 7の観点は、前記応答用の R e s p o n s eTyp eの I n t e r n a lMe s s a g e標識には、処理を停止させ、または実行させる G o N o G o標識を含むことを特徴とする処理方法である。

本発明の第 8の観点は、前記応答用の R e s p o n s eTy p eの I n t e r n a lMe s s a g e標識には、追加情報を伝送する I n f o標識を含むことを特徴とする処理方法である。

(従来技術より有効な効果）

中央制御エンジンである D IMを介さず処理がなされるから、処理の効率を上げることができる。 - .

規格に準拠した様々な端末が、固定されたシーケンスの順序がなく行動が予測できない多様な種類のアプリケーションをカバーできるようにする、汎用メッセージ構造を定義することにより、多様な処理エンジン間の通信が相互に動作可能な方法で実現される。本発明により、 MPEG— 21端末の柔軟性が高まり、より簡単かつ迅速な方法でデジタルアイテムを処理することが可能となる。

本発明のメッセージ構造は、端末内の複数の処理エンジン間においてあらゆる種類の情報を伝送するための、簡単かつ共通のものであり、異なる処理エンジン毎に特別な AP Iを定義するといつた問題を解決することができる。図面の簡単な説明

図 1は、 I P MP保護記述子及び D I A記述子が含まれる D I Dドキュメントの階層を示す図である。

図 2は、ハプ型制御モードのみを有するデコーダの動作説明を示す図である。図 3は、デジタルアイテム（D I) 1 サーバからユーザに配信される様子を説明する図である。

図 4は、デジタルアイテムの送受信処理を示すフロー図である。

図 5は、 D I D形式で記述されたデジタルアイテムのへッド部に対応する D I

Dドキュメントを示す図である。

図 6は、 MPEG— 21端末のシステムの構成を示すブロック図である。

図 7は、 D I Dドキュメントを受け取ったときに MPEG— 21端末が行う処理のフロー図である。

図 8は、 D IMプレゼンタが複数の準備処理を行うときの処理を示すフロー図である。

図 9は、 D IMプレゼンタが行う D I A適合処理のフロー図である。

図 10は、 MPEG— 21端末内におけるモジュール間でのメッセージ転送を示す図である。

図 11は、処理エンジン間での直接メッセージ転送を行うために MP EG— 2 1端末内に構築された、汎用 AP Iとしてのメッセージを示す図である。

図 12は、 MPEG— 21端末内における、 D IMエンジンを介したメッセー- ジ転送を示す図である。

図 13は、メッセージ AP Iを備えた MPEG— 21端末内における、処理ェンジンを有する D I Mエンジン機能の詳細を示す図である。

図 14は、 MP EG— 21端末内の異なるモジュール間で伝送されるメッセージング 'インフラストラクチャを示す図である。発明を実施するための最良の形態

図 3は、 MPEG— 21のフレームワーク内で、デジタルアイテム（D I) が、サーバ（プロバイダ） _{1 0}からユーザ（消費者） 12に配信される様子を説明する図である。ここで、デジタノレアィテムは、音声、映像、及び I PMPデータ等のメディアコンテンツを含むコンテンツ部 14と、各々のメディアコンテンツのァドレスを含むヘッダ部 16と力ら成る。 MP EG— 21のフレームワーク内では、通常、図 3に示されるように、デジタルアイテムのヘッダ部 16が、コンテンッ部 14よりも先に、ユーザ 12に配信される。ユーザ 12は、デジタルアイテムのヘッダ部 16を先に受信し、サーバから提示される条件に同意する場合にのみ、パッケージ化されたコンテンツ部 14を受信することができる。

図 5は、 D I D形式で記述されたデジタルアイテムのへッド部 16に対応する D I Dドキュメントを示す図である。 D IDドキュメントは、いくつかのデジタルアイテム 20， 22， 24を含む。また、それぞれのデジタルアイテム 20， 22, 24のリソース 26は、実際のデジタルコンテンツを所有する所有元のァドレスを含む。さらに、 D I Dドキュメントは、いくつかの I PMP記述子情報 (ステートメント） 28、及び D I A記述子情報（ステートメント） 30も含む。さらに、 D IDドキュメントは、 REL (R i g h t s Ex p r e s s i o n La ngua g e) DD (R i g h t s D t a D i c t i o n a r y; 記述子情報、及ぴ ER (Ev e n t Re p o r t) 記述子情報（図示されない）等を含んでもよい。

ここで、 D IDドキュメントは、図 5の点線 Aに示されるように、デジタルァィテム方法（D IM: D i g i t a l I t em Me t h o d) の記述を含む。この D IMの記述はユーザがコンテンツに対して実行できるコンテンツの基本動作に含まれる基本処理（再生、複製、及び印刷等）を指定するものである。具体的に、図 5の D IMの記述は、「ユーザが、 100円支払えば、コンテンツを 2回再生できる」ことを意味する。ユーザ（MP EG— 21端末）は、 D I Dドキュメントにおける I PMP記述子情報 28、及び D I A記述子情報 30等の記述に従って処理を行う。すなわち、ユーザは、 100円支払うことに同意した場合にのみ、図 5のリソースに記述されたァドレスに存在するメディアコンテンツを再生することができる。

図 4は、これまで説明したデジタルアイテムの送受信処理を示すフ口一図である。まず、サーバ 10力デジタルアイテムをデジタルアイテム宣言形式で記述する（ステップ S 1) 。次に、サーバ 10が、デジタ^^アイテム宣言形式で記述されたデジタルアイテム（のヘッダ部 16) を、ユーザ（MPEG— 21端末） 12に配信（送信）する（ステップ S 2) 。ユーザ 12は、サーバ 10から送信された、デジタルアイテム宣言形式で記述されたデジタルアイテム（のヘッダ部 16) を受信する（ステップ S 3) 。

以下に、図 5に示される D I Dドキュメントを受信したときのユーザ 12 (M PEG— 21端末）の処理について説明する。図 6は、 MPEG—21端末 12 のシステムの構成を示すブロック図である。図 6に示されるように、 MP EG— 21端末 12は、デコーダ 40、出力部 42、及びユーザ入力部 44を含む。デコーダ 40は、 D I Dパーサ 46を含む D I Dエンジン 50、 D IMプレゼンタ 58を含む D IMエンジン 48、 D I Iエンジン 51、 I PMPエンジン 52、 1 £1ェンジン53、 1 00ェンジン54、 D I Aエンジン 55、 ERエンジン

56を含む。 D IDエンジン 50は、 D IMエンジン 48に接続されると共に、 D I Iエンジン 51、 I PMPエンジン 52、 RELエンジン 53、 RDDェンジン 54、 D I Aエンジン 55、 ERエンジン 56にも接続される。 D IMェンジン 48も同様に、 D I Iエンジン 51、 1 ?1^?ェンジン52、 RELェンジン 53、 1 00ェンジン54、 D I Aエンジン 55、 ERエンジン 56に接続される。更に、 D I Iエンジン 51、 I PMPエンジン 52、 RELエンジン 53、 1¾00ェンジン54、 D I Aエンジン 55、 E Rエンジン 56は互いに接続されている。

図 7は、 D I Dドキュメントを受け取ったときに MPEG—21端末 12が行う処理のフロー図である。図 7に示されるように、まず、デコーダ 40の D ID パーサ 46力 D I D形式で記述されたデジタルアイテムの中身を解析する（ステツプ S 1 1) 。 D I Dパーサ 46は、デジタルアイテムにおいて D I Mの記述が出現すると（<U s a g e Ru 1 e >の記述が出現すると）、 D I Dドキュメントを、サブルーチンである D I Mプレゼンタ 58に送る。次に、 D IMプレゼンタ 58は、 D IMの記述を解釈する（ステップ S 12) 。そして、 D IMプレゼンタ 58は、 D IMにより指定された基本処理のセマンティクスに従って、その基本処理を実行するために必要な値又はパラメータをユーザに要求すると同時に、その基本処理をユーザに提示する。ここでは、「ユーザから 100円支払うカ否かを示す情報を取得する」というセマンティクスに従って、出力部 42を用いて、ユーザに、「 100円支払う力否か」の問いに答える値又はパラメータを要求する（ステップ S 13) 。例えば、出力部 42がディスプレイのとき、「1

00円支払って再生しますか？」というメッセージが、ディスプレイに表示される。

ユーザは、ユーザ入力部 44を用いて、 100円支払うか否かという問いに対する答えを示す値又はパラメータを入力する。 D IMプレゼンタ 58は、その値又はパラメータを取得する（ステップ S 14) 。 D IMプレゼンタ 58は、取得した値又はパラメータに基づき、ユーザが 100円支払うか否かを判断する（ステツプ S 15) 。 D IMプレゼンタ 58は、ユーザが 100円支払うと判断する (例えば、取得した値又はパラメータが「TRUE」である）（ステップ S 1

5) と、取得した値又はパラメータを、 D I Iエンジン 51、 I PMPエンジン 52、 RE Lエンジン 54、 RDDエンジン 54、 D I Aエンジン 55, ERェンジン 56に転送し、再生を続行する（ステップ S 16) 。一方、ユーザが 10 0円を支払わないと判断する（例えば、取得した値又はパラメータが「FALS E」である）（ステップ S I 5) と、 D IMプレゼンタ 58は、取得した値又はパラメータを、 D I Iエンジン 50、 I PMPエンジン 52、 RE Lエンジン 5 3、 1 00ェンジン54、 D I Aエンジン 55， E Rエンジン 56に転送し、再生を中止する (ステップ S 17) 。ここで、 D I Mプレゼンタ 58は、ステップ S 4において、ユーザから値又はパラメータを取得したとき、ユーザから特定の形式で入力された値又はパラメータを、 D IMによって必要とされる指定された形式に変換することができる。つまり、ユーザから、 100円を支払う力否かを示す値又はパラメータを取得し、それを指定された形式に変換して、 D I Iェンジン 50等に転送することができる。

上述したように、 D I D形式で記述されたデジタルアイテムに、コンテンツの基本処理（例えば、再生、コピー、印刷）を指定するデジタルアイテム方法を追加することにより、サーバ側が、配信されたコンテンツをユーザがどのように処理するかまで指定することができる。よって、ユーザに酉己信されるコンテンツの著作権を十分に保護することができる。

なお、上述の説明では、デジタルアイテム 20， 22, 24のリソース 26が、実際のデジタルコンテンツを所有する所有元のァドレスを含むとしたが、各々のデジタルアイテムが、実際のデジタルコンテンツを含んでもよい。

再生が続行される場合、 D IMプレゼンタ 58は、デジタルアイテムの記述に従って、サーバからコンテンツを取得するためのいくつかの準備処理 ( 「再生」処理に付随する付随処理）を行う。図 8は、 D I Mプレゼンタ 58が複数の準備処理を実行するときの処理を示すフロー図である。図 8に示されるように、まず、 D IMプレゼンタ 58は、 D I Aエンジン 55を呼び出し、デジタルアイテムの D I A記述と MP EG— 21端末の D I A記述の適合を調べさせる（D I A適合処理：ステップ S 21) 。これにより、 MP EG— 21端末のデコーダの機能力コンテンツに適合しているかどうかを調べる。図 9は、 D IMプレゼンタ 58が行う D I A適合処理のフロー図である。 D IMプレゼンタ 58は、 D I A適合処理に関する D IMの記述を解釈する（ステップ S 32) 。そして、 D IMプレゼンタ 58は、ユーザ、インターネット上のリソース、又は D I Dドキュメントに、 D IMにより指定された D I A記述適合処理のセマンティクスに従って、その D I A適合処理を実行するために必要な値又はパラメータを要求する（ステップ S

33) 。 D IMプレゼンタ 58は、ユーザ、インターネット上のリソース、又は D I Dドキュメントから、必要な値又はパラメータを取得する（ステップ S 3 4-) と、 D I Aエンジン 55-を呼び出し、取得した値又はパラメータを、 D I A エンジン 55に転送して、 D I A適合処理を実行させる（ステップ S 35) 。 D I Aエンジン 55は、 D IMプレゼンタ 58から転送された値又はパラメータを用いて、 D I A適合処理を行う。 D IMプレゼンタ 58は、 D I Aエンジン 55 から出力される信号により、 2つの D I A記述が適合しないことを検知する（D I Aエンジン 55から 2つの D I A記述が適合しないことを示す信号を取得する）（ステップ S 22) と、再生処理を中止する（図 8, ステップ S 23) 。一方、 D I Aエンジン 55から出力される信号により、 2つの D IA記述が適合していることを検知する（D I Aエンジン 55から 2つの D I A記述が適合したことを示す信号を取得する）（ステップ S 22) と、 D IMプレゼンタ 58は、 I PMPエンジン 52を呼び出して、 I PMP処理を実行させる（ステップ S 2 4) 。ここで、 D IMプレゼンタ 58は、 D I A適合処理と同様に、 I PMP処理に必要な値又はパラメータを、ユーザ等から取得して、 1 ?1^?ェンジン52 に転送してもよい。 1

ェンジン52は、この I PMP処理において、コンテンッがどんな方式で保護されているかを調べ、必要な I PMPツールを取得する。 D IMプレゼンタ 58は、 I PMPエンジン 52から出力される信号により、 I P MPツールが取得できないことを検知する（I PMPエンジン 52力ら I P

M Pツールが取得できないことを示す信号を取得する）（ステップ S 25 ) と、再生処理を中止する（ステップ S 23) 。一方、 D IMプレゼンタ 58力 I P MPエンジン 52から出力される信号により、 I PMPツールが取得できることを検知する（I PMPエンジン 52カゝら I PMPツールを取得できることを示す信号を取得する) 、すなわち、保護を解除できる場合には、 D IMプレゼンタ 5 8は、次に、 RELエンジン 53を呼び出し、再生するための権利がそのユーザにあるか否かを調べさせる（REL処理：ステップ S 26) 。ここで、 D IMプレゼンタ 58は、 D I A適合処理と同様に、 R E L処理に必要な値又はパラメ一タを、ユーザ等から取得して、 RELエンジン 53に転送してもよい。 D IMプレゼンタ 58は、 RELエンジン 53から出力される信号により、再生するための権利（資格）がユーザにないことを検知する（RELエンジン 53から再生するための権利がユーザにないことを示す信号を取得する）（ステップ S 27) と、再生処理を中止する（ステップ S 23) 。一方、 D I-Mプレゼンタ 58力 RE Lエンジン 53から出力される信号により、再生するための権利がユーザにあることを検知する（RELエンジン 53から再生するための権利がユーザにあることを示す信号を取得する）（ステップ S 27) と、 MPEG—21端末は、サーバにコンテンツを要求し、サーバからコンテンツが提供される（ステップ S 2 8) 。なお、再生のための準備処理は、上述したものに限られない。もし、デジタルアイテムが保護されていないなら、 I PMP処理は省略できる。また、 I P MP処理が、ユーザに再生するための権利がある力否かを調べる処理を含む場合には、 REL処理は省略できる。

さらに、各々の準備処理の順序は、上述したものに限られない。例えば、 RE L処理、 D IA適合、 I PMP処理の順に行われてもよい。この順序は、 D I D ドキュメントにおける D IMの記述、例えば、各々の準備処理に関する記述が、どのような順序で存在するか等によって定められる。よって、サーバ側は、この準備処理の順序を自由に定めることができる。

D I Mプレゼンタ 5 8は、ユーザとインタラクティブな関係にある。ユーザが 1 0 0円支払って再生することを選択した後、 D I Mプレゼンタ 5 8は、さらに、 D I A記述子情報（ステートメント） 3 0に記述された M I Dの記述を解釈して、新たに別の処理 ( 「再生」処理に付随する付随処理）を行うことができる。例えば、コンテンツが映像である場合、それは、表示サイズを決定する処理であってよい。 D I Mプレゼンタ 5 8は、表示サイズ決定処理の「ユーザから表示サイズを示す情報を取得する」というセマンティクスに基づき、ユーザに、表示サイズに関する値又はパラメータを要求してもよい。これは、例えば、ユーザに、複数の表示サイズの選択肢を提示することにより実現できる。ユーザがその選択肢の中から 1つを選択すると、つまり、 D I Mプレゼンタ 5 8が、ユーザから、表示サイズに関する値又はパラメータを取得すると、 D I Mプレゼンタ 5 8は、取得した値又はパラメータを、 D I Aエンジン 5 0に転送する。または、 D I Mプレゼンタ 5 8は、取得した値又はパラメータを、 D I Dドキュメントにおける D I A記述子情報 3 0の所定の位置に書き込み、その D I Dドキュメントを D I Aェンジン 5 5に転送してもよい。

なお、上述の付随処理は基本動作に含まれるものであり、表示サイズを決定する処理に限られない。例えば、解像度を決定する処理等であってもよい。

本発明のデコーダ装置及び方法にあっては、 D I Mエンジン 4 8を中心として放射状にデータを送受信するハブ型制御モードと、 D I Mエンジン 4 8に戻さず、 D I Mエンジン 4 8に接続された周辺のエンジン 5 0— 5 6の間で直接データを送受信するラテラル型制御モードのいずれかの制御モードで動作可能である。ハプ型制御モードの場合、処理されるデータは、 D I Mエンジン 4 8から周辺の一つのエンジン、たとえば D I Iエンジン 5 1に送り出され、 D I Iエンジン

5 1で処理され、処理されたデータは、再び D I Mエンジン 4 8に戻される。更に次の処理が必要であれば、データは、 D I Mエンジン 4 8から、次に処理がなされるエンジン、たとえば I PM Pエンジン 5 2に送り出される。そして、 I P MPエンジン 5 2で処理されたデータは、再び D I Mエンジン 4 8に戻される。このように、 D IMエンジン 48から種々のエンジン 50-56のいずれかの目標エンジンに向かって放射状にデータが送信され、目標エンジンから D IMェンジン 48に戻される。

ラテラル型制御モードの場合、処理されるデータは、エンジン 48、 50-5 6の内、任意の 2つのエンジン間でデータの送受信がなされる。この場合は、 D

IMエンジン 48の負担が軽減されると共に、データ処理の効率を上げることができる。次に説明するように、ラテラル型制御モードによりデータが処理される場合は、記述子のステートメントにおいて、予め決められたメッセージが用いられる。

ラテラル型制御モードについて更に説明する。

(異なるモジユー間でのメッセージ送信）

D IMエンジン 48は、 I SOZI EC 21000端末/フレームワークの全ての部分（モジュール）と相互作用する必要性がある。 I SO/I EC 21 000端末の別の部分との情報交換は、 MPEG— 21における汎用 AP Iとして定めることができる。情報を交換する唯一の方法は、 I SO/I EC 210 00の端末の部分（モジュール）にメッセージを送信することである。

処理エンジンが異なれば、要求する情報も異なる。情報は、 D IDモジュール内部に直接伝送することもできれば、異なるモジュール間で個別に伝送することもできる。例えば、 I PMPシステムモジュールは I PMP情報を要求し、 RE Lモジュールは利用規則情報を、 D I Aモジュールは D I A記述情報をそれぞれ要求する。

図 10に示すように、異なるモジュール間で情報交換が必要とされる有益なシナリオがあり、その例として次のようなものが挙げられる。 D IDモジュール 5 0は、コンテンツを特定した利用権利情報（3. 1) を RELモジュール 53に転送する必要があり、 R E Lモジュール 53は当該利用権利を解析し、処理する。 D I A記述情報は、 D I Dモジュール 50力、ら D I Aモジュール 55へ転送するよう要求され、当該情報は、 D I D内の実際に入力される D I A記述と実際の端末間の D I A記述との比較に使用され、デジタルアイテム及び/又はメディア · リソースの適応が行われる。 D I Aモジュール 55は、 D I Aの突き合わせを行つた結果これが一致しない場合は、 D IMエンジン 48を介して「GoNoG oj 情報 (3. 2) を含む応答メッセージを送信し、 D IDモジュール 50を中止させる。 D I I内部の D I I識別情報（3. 3) は、コンテンツを特定した利用権利の識別の持続的な関連付けを行うために、 RELモジュール 53に送信されることもある。

上記のような場合は、端末、ネットワーク及びユーザの嗜好に関する D I A記述、 I P M Pツール記述用の I P M P情報、コンテンッを特定した利用権利及び利用条件を含む REL情報、特定アイテム用の D I I情報を交換しなければならない。必要な場合は、前記の情報に基づいて交渉が行われる。従って、このような情報を伝送するために、相互動作可能な交渉メカニズム及びメッセージを定義し、 D IDエンジン 50、 1 ?]\ ェンジン52、 D I Aエンジン 55等の異なる処理エンジン間の通信を容易にする必要がある。図 11に示すように、ここに定義するメッセージ構造を持つ交渉メカニズムに従うことにより、ュニバーサル'マルチメディア ·アクセス端末を構築することができる。

図 11に示すようにメッセージベースの汎用 A P Iが様々な処理モジュール Z エンジンを囲んで配置される。端末内の異なるモジュール間の通信は全て、モジユール 4. 1内の Ms g—AP Iを使用して行われる。

図 1 1-に示すよう-に、まず D I Dエンジン 50から、メッセージ（Ml) は R ELエンジン 53へと伝送され、メッセージ（M2) は D I Aエンジン 55へ、メッセージ（M3) は ERエンジン 56へ等、それぞれ伝送される。

1 £ ェンジン53は、 D I Dエンジン 50からメッセージ（Ml) を受信すると、これを処理して I PMPエンジン 52へと伝送し、メッセージ（M2) を ERエンジン 56へと伝送する。

I PMPェンジン52は、 RELエンジン 53からメッセージ（Ml) を受信すると、これを処理し、 ERエンジン 56へと伝送する。

ERエンジン 56は、様々な処理エンジンから全てのメッセージを受信し、ィベント又は処理結果をログファイルに書き込む。また、別の処理エンジンにメッセージを送信する必要がある場合もある。

これらの処理エンジン又はモジュールには、図 10及び図 1 1に示すように、 D I Dエンジン 50、 D I Iエンジン 5 1、 I PMPエンジン 52、 RE Lェンジン 53、 1 00ェンジン54、 D I Aエンジン 55、及ぴ ERエンジン 56が含まれるが、これに限定されず、他のエンジンを含むこともできる。。

上記の設計はデータ主導型、すなわちラテラル型の処理であり、メッセージの伝送を助けるルータ的な主エンジンはない。また、各処理エンジンは、処理されるデータ自身によって呼び出される。

これに対し、ハブ型の設計を図 12に示す。当該設計では、メッセージは全て、様々な処理エンジンから、又は様々な処理エンジンへ、中央処理エンジンである D I Mモジュール 48を介して転送される。

ここに示す D IMエンジンには、この場合、二つの主な機能がある。

D D I Dエンジン^ D I Mエンジンユーザにおける基本動作

D I D文書に含まれる、定義されたあらゆる基本動作又は方法を処理し、定義された基本動作又は方法に従ってユーザに提示し、ユーザが入力したユーザの選択肢 Z選択 Z嗜好を他の処理ェンジンに転送する。

2) 処理エンジン D IMエンジン処理エンジン

メッセージセンターとして、一方の処理エンジンから他方の処理エンジンへのメッセージ転送を支援し、処理エンジンへ送信する又は処理エンジンから受信するメッセージを制御し、 ·各処理エンジンの主導権を握り当該エンジンに対して停止又は開始の機能を適用し、基本動作又は方法が定義されていない場合には処理エンジンとユーザとの間の情報交換を支援する。

図 13に、モジュール 6. 1のメッセージ AP Iを備えて構成された MP EG —21端末に D I D形式の D IDドキュメント 16 (図 5に示したものと同じ) が提供された場合を示す。 D IDエンジン 50は、 DID文書 16を受信し、そこに含まれる多様な基本動作のメッセージに基づいて当該 D Iの処理を行う。

D I Mエンジン 48は主エンジンの役割を果たす。まず基本動作を受信して解釈し（a) 、必要に応じてユーザに提示し（b) 、ユーザからの入力を回収し (c) 、該当する他の処理エンジン、例えば D I Iエンジン 51への送信（d 1) 、 RELエンジン 53への送信 (d 2) 、 I PMPエンジン 52への送信 (d 3) 、 D I Aエンジン 55への送信（d4) 、 E Rエンジン 56への送信 (d 5) 、またはその他の、プレーヤー、トランコーダ一等の非標準処理ェンジン 6. 4への送信 (d 6) を行う。図 13に示されていないが、 RDDエンジンも含むように構成してもよい。

情報は、本発明に定めるメッセージ A P Iを使用して、一方の処理エンジンから他方の処理工ンジンへと直接伝送するラテラル型制御モードによることも可能であり、また本発明に定めるメッセージ A P Iを使用して、 D IMエンジンを介して一方の処理ェンジンから他方の処理エンジンへと伝送するハブ型制御モードによることも可能である。後者の場合、 D IMエンジン 48の負担が増えることになるが、中央制御による利点が得られる。

モジュー^^ 6. 4の処理エンジンは、ビデオプレーヤー、メディア 'フォーマット ' トランスコーダ一等の非標準モジュールでもよい。非標準処理部をカバーするための拡張性は、汎用メッセージ AP Iの現行の設計でサポートされている。

(汎用内部メッセージ）

本発明で定義する汎用内部メッセージは、ラテラル型制御モードを可能にするため、モジュールからモジュールへ（エンジンからエンジンへ）有益情報を転送することができる。 D IM (デジタルアイテム方法）処理エンジン 48は、一つの特別な処理エンジンであるとも考えられ、中央処理部として方法 Zオペレーシヨンを処理することができる。ここで、接続されたモジュールが現在の端末において通信を行うことを可能にする一連の定義された方法又はオペレーションが定義され、存在すると仮定する。 D I Dエンジン、 D I Iエンジン、 D I Aェンジン、 I PMPエンジン、 REL/RDDエンジン、及ぴ ERエンジン等の他の処理エンジンは、それぞれ D IMエンジンから伝送された関連情報を処理することができるが、迅速かつ効率的な処理のためには、これらのエンジン間での直接的な情報通信が必要な場合もある。

汎用の I n t e r n a lMe s s a g eTyp eのシンタックス及びセマンテイクスを以下に示し、また、その構造を図 14に示す。

<xs:schema xmlns:xs="http://www. w3.org/2001/XMLSchema"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="lntemalMessage" type="BasiclnternalMessageType"> IS3

ο

pntcomlexce/x:os- <

nx:xtnio/seesv <

qnxuec/s:ee s < V

し

gr_Tlnfoi ioe lessae/ -v-_

gmxs: elea l tient menfiopvlealosse <

qunx:eecess <v

ntlme ee

_t/xo3tions: <>

dulumnti ioex: docetaons/s< V

gmxmation echdumn_raxs:ocetmaes fo Foi - amoationess <> ntx:nosa < o

plTseDe-.

x:numrinohrnfrseeato valuetelomation7v=" ω

a -lfol lationlaessv=="

ntei lasic一esseT

estT -v-- ustce t

n o

qeuence/xs:sv <

ypnaTe7 toDat ilnfeo --v=一--

GNGlntai -eOOxs:ee !e n <=-- x:hscoice <>

ygaTDeex:xnin basilntmalMesssetesoaseBcev <="-- pcnmlexote_1tx:oscv < o

用（R e s p o n s e Ty p e) のメッセージ標識に分けることができる。

B a s i c I n t e r n a lMe s s a g e Ty p e 7. 2の標識は、内部モジュールの交渉メッセージにおける基本/共通情報を記述するものであり、 M s g― I D、 S e n d e rMo d u l e、及ぴ R e c i p i e n tMo d u l eの要素を含む。

Ms g— I D標識は、メッセージ発信元（一つのモジュール）によって特定され、ひとつのテーマに対し、ひとつのメッセージ識別子が生成され、記述される。あるテーマを持ったメッセージに応答して送信されるメッセージは全て、同じメッセージ識別子が付けられる。

S e n d e r Mo du l e標識は、メッセージ発信元のモジュール識別子を記述する。

R e c i p i e n tMo d u 1 e標識は、当該メッセージの受信側とされるモジュール識別子を記述する。

T r a n sm i t Ty p e 7. 3の標識は、送信する内部交渉メッセージを記述するものであり、 B a s i c I n t e r n a lMe s s a g e Ty p eに、 M e s s a g e I n f o rma t i o n 7. 4力 ¾]口わったものである。

Me s s a g e l n f o rma t i o n 7. 4標識は、モジユーノレ間での伝送及び交換される情報を運ぶためのものであり、 I n f o r ma t i o n C 1 a s s及び I n f o rma t i o n D a t a ¾■含む。

I n f o rma t i o nC l a s s標識は、内部交渉メッセージで伝送される情報のタイプ、すなわち種類を記述する。この「C 1 a s s」は、 R i g h t s I n f o rma t i o n、 I PMP I n f o rma t i o n_N D I A I n f o r ma t i o n D I I I n f o rma t i o n、及ひ Ό t h e r l n f o rma t i o nのいずれかひとつを特定することができる。これらは異なる内部モジュールによつて処理される様々な情報の伝送に使用される。

I n f o rma t i o nD a t a標識は、実際の情報データを、適切に作成された XMLフラグメントを直接含むメッセージ ·ペイロードとして記述する。 I n f o rma t i o nD a t a内に含まれる、このようなフラグメントのスキーマは、当該フラグメントのネームスペースによって識別される。 Re qu e s tTy p e 7. 5の標識は、要請する内部交渉メッセージを記述するものであり、 B a s i c I n t e r n a lMe s s a g eTyp eに、 I n f o rma t i o nC l a s s標識がカロわったものである。 I n f o r ma t i o nし 1 a s sfま、 Me s s a g e I n f o rma t ι o n T y p eで疋されたものと同一のセマンティクスを有する。

Re s p o n s eTyp e 7. 6の標識は、応答する内部交渉メッセージを記述するものであり、 B a s i c I n t e r n a lMe s s a g eTy p eに、更に、「GoNoGo」と「Me s s a g e I n f o rma t i o n」とレヽっ二つの要素を含む。「GoNoGo」要素は、送られてきた「T r a n sm i t J (送信）メッセージへの応答に使用され、「Me s s a g e I n f o rma t i o n」要素は、送られてきた「R e q u e s t (要請）」メッセージへの応答に使用される。

G oNo Go 7. 7標識は、あるモジュールが、別のモジュールに処理を停止させる場合、又は別のモジュールに処理を行わせる場合に使用される。「Tr u e (真）」はメッセージ送信側がメッセージ受信側に「実行（g o) 」を許可することを示し、「F a 1 s e (偽）」は「不許可（ d i s a 1 1 o w；) 」又は「不実行 (n o-g o) 」を示す。

I n f .o標識は、追加情報を伝送するための、「G o N o G o.」要素のァトリビュートである。

モジュール間通信における、定義された内部メッセージの使用方法の例を以下に示す。以下の例では、 MP EG— 21端末内の異なる処理エンジンに異なる整数を割り当て、限られたモジュール間の識別を簡単に表している。例えば、 D I Mエンジンは 1、 D I Dエンジンは 2、 RELエンジンは 3、 I PMPエンジンは 4、 ERエンジンは 5、 D I Aエンジンは 6の識別番号が割り当てられている。まず、権利情報の送受信の例を示す。権利情報を D I Dモジュール 50から R

ELモジュール 53へ直接送信し、 RELモジュール 53は処理した後、当該情報を返信し、 D I Dモジュール 50は、次のステップに進む。

<Msg_ID>001く/ Msg— ID>

<lnformationClass>Rightslnformation</lnformationClass>

</lnformationData>

</Messagelnformation>

</lnternal Message>

<lnternalMessage xmlns:xsi="http：〃 www. w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="lnternalMessage.xsd"

xsi:type="ResponseType">

<Msg_ID>001く/ Msg— ID>

</lntemalMessage>

次に、 I P M Pツール情報の送受信の例を示す。 I P M Pツール情報を I P M Pエンジン 5 2から E Rモジユーノレ 5 6へ直接要請し、 E Rモジユーノレ 5 6は当該情報を I P M Pエンジン 5 2に返信し、 1 1^ ?ェンジン5 2は、さらなる処理を TTう。

<lntemalMessage xmlns:xsi=^Mhttp://www. w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaし ocation="lntemalMessage.xsd"

xsi:type="RequestType">

く Msg— ID>002く/ Msg— ID>

<lnformationClass>IPMPInformation</lnformationClass>

</lnternalMessage> <lnternalMessage xmlns:xsi="http://www. w3.org/2001 /XMLSchema-instance" xsi:noNamespaceSchemaし ocation="lnternalMessage.xsd"

xsi:type="ResponseType">

<Msg_ID>002</Msg_ID>

<lnformationClass>IPMPInformation</lnformationClass>

</IPMPToolList>

</lnformationData>

</Messagelnformation>

</lnternalMessage>

次に、ユーザから受けたユーザ特徴記述の送受信の例を示す。ユーザ特徴記述を D I Mエンジン 4 8から D I Aモジユーノレ 5 5へ送信し、 D I Aモジユーノレ 5 5は、処理した後、 D I A—致情報を返信して D I Mエンジン 4 8は、次のステップに進む。例えば、続いて I PM P情報を I P MPエンジン 5 2に送信し、応答メッセージを受信して、 D I Mエンジンに「プレーヤー」モジュールを停止するよう通知する。

<lntemalMessage xmlns:xsi="http：〃 www. w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="lnternalMessage.xsd"

xsi:type="TransmitType">

<ControlPoint>Before</ControlPoint>

</IPMPDescriptor>

</lnformationData>

</Messagelnformation>

</lnternal Message>

< Internal Message xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" xsiinoNamespaceSchemaLocation- 'Internal essage.xsd"

xsi:type="ResponseType">

<Msg_ID>004</Msg_ID>

<GoNoGo>false</GoNoGo>

</lnternalMessage>

本宪明は、その様々な態様から見て、以下のような構成を持つと考えられる。第 1の構成によると、本発明は、ユニバーサル 'マルチメディア ·アクセス ·フレームワークにおける多様な処理モジュール間の通信方法であって、

メッセージ構造を有する汎用メッセージ A P Iを備えた端末を構築するステツプと、

デジタルアイテム宣言（D I D) エンジンと他の処理エンジンとを統合して前記端末を構築するステップであって、他の処理エンジンとしては、デジタルアイテム方法（D I M) エンジン、デジタルアイテム識別（D I I ) エンジン、権利記述言語（R E L) エンジン、権利データ辞書 (R D D) エンジン、知的財産管理保護（I P M P ) エンジン、デジタルアイテム適応（D I A) エンジン、ィべント報告（E R) エンジン、及びいかなるプレーヤーとしても特定されないェンジン等が含まれるがこれらに限定されない、ステップと、

D I D入力を、 D I Dパーサを備えた前記 D I Dエンジンで処理するステップと、

前記 D I D入力の各要素及び前記 D I D入力に含まれる基本動作を解釈するステツプと、

前記基本動作に基づき、 D I Mエンジンを使用して、必要に応じて選択肢又は選択をユーザに提示するステップと、

ユーザから値又はパラメータを、あるいは D I D文書から指定地点を検索する前記値又はパラメータを、前記メッセージ構造を使用して、一つの処理ェンンから直接又は中央制御 D I Mエンジンを介して特定の処理エンジンへ伝送する特定の処理エンジンを呼び出して前記値又はパラメータに基づいて処理を行う前記処理結果を、前記メッセージ構造を使用して、さらなる処理のために次の処理工ンジンに伝送するステップと、

多様な処理の後、コンテンツ消費を完了するステップとを含む、通信方法である。

第 2の構成によると、本発明は、ユエバーサル 'マルチメディア 'アクセス ' フレームワークにおける多様な処理モジュール間の通信方法であって、

異なるベンダーから提供される可能性のある多様なモジュールで端末を形成するステップと、

メッセージ構造を有する汎用メッセージ A P Iを備えた前記各モジュールを構築し、前記モジュールが前記メッセージ A P Iに基づいて行われる通信を理解できるようにするステップと、

値、パラメータ、又はステータス等の情報を、前記メッセージ A P Iを使用して一方のモジュールから他方のモジユーノレへ伝送するステツプと、

前記伝送に対して処理結果又は関連情報を返信し、前記通信を完了するステツプとを含む、通信方法である。

第 3の構成によると、本発明は、ユニバーサル 'マルチメディア 'アクセス - フレームワークにおける多様な処理モジュール間の通信方法であって、異なるベンダーから提供される可能性のある多様なモジュールで端末を形成するステップと、

値、パラメータ、又はステータス等の情報を、前記メッセージ A P Iを使用して一方のモジュールから他方のモジュールへ要請するステップと、

前記要請メッセージに対して要請された実際の情報を返信し、前記通信を完了するステップとを含む、通信方法である。

第 4の構成によると、本発明は、ユニバーサル ·マルチメディア■アクセス ' フレームワークにおける多様な処理モジュール間の通信方法であって、請求項 1、 2及び 3に記載のメッセージ構造が、

伝送、要請、応答、及び/又は第 3の部分が定める他のメッセージタイプ等の多様なタイプのメッセージによって拡張可能な汎用メッセージ構造を含むステツプと、

多様なタイプのメッセージによって伝送されるメッセージ情報を含むステップとを更に含む、通信方法である。

第 5の構成によると、-本発明は、ユニバーサル-'マルチメディア 'アクセス -. フレームワークにおける多様な処理モジュール間の通信方法であって、請求項 4 に記載の汎用メッセージ構造が、

前記メッセージ構造において、各メッセージにメッセージ I Dを割り当て、応答メッセージも同一の I Dを使用して当該メッセージに応答できるようにするステツプと、

前記メッセージ構造において、処理モジュールの名前又は割り当てられた内部モジュール番号を送信側又は受信側として使用し、メッセージの発信元又は送信先のモジュールを示すステップとを更に含む、通信方法である。

第 6の構成によると、本発明は、ユニバーサル 'マルチメディア 'アクセス ' フレームワークにおける多様な処理モジュール間の通信方法であって、請求項 4 に記載のメッセージ情報本体が、伝送メッセージを使用して、当該情報を特定の処理工ンジンに伝える又は当該情報を一方のモジュールから他方のモジュールに伝送する状況において、

情報の種類を、 R i gh t s I n f o rma t i o n、 I PMP I n f o rm a t i o n、 D IAI n f o rma t i o n、 D I I I n f o rma t i o n、及ぴ O t h e r l n f o rma t i o nの列挙で記述する I n f o rma t i o nC 1 a s sを含むステップと、

前記値、パラメータ、又はステータス等の実際の情報データを、適切に作成された XMLフラグメントを直接含むメッセージ'ペイロードとして記述する I n f o rma t i o nDa t aを含むステップとを更に含む、通信方法である。第 7の構成によると、本発明は、ユニバーサル 'マノレチメディア 'アクセス - フレームワークにおける多様な処理モジュール間の通信方法であって、請求項 4 に記載のメッセージ情報本体が、請求項 6に記載の伝送メッセージに対し応答メッセージを使用して応答する状況において、

「GoNoGo」要素を用いて他方のモジュールに処理を中止させる、又は他方のモジュールに処理を行わせるための前記処理結果を含むステップと、いくつかの追加的な結果情報を伝える「I n f o」要素を含むステップとを更に含む、通信方法である。

第 8の構成によると、本発明は、ユニバーサル 'マノレチメディア -アクセス-' フレームワークにおける多様な処理モジュール間の通信方法であって、請求項 4 に記載のメッセージ情報本体が、要請メッセージを用いて他方のモジュール又は処理エンジンから当該情報を入手する状況において、要請された情報の種類を、

R i gh t s I n f o rma t i o n I PMP I n f o rma t i o n^ D I AI n f o rma t i o n、 D I I I n f o rma t i on、及ひ Ό t h e r I n f o rma t i o nの歹挙で記述する I n f o rma t i o nC l a s sを更に含む、通信方法である。

第 9の構成によると、本発明は、ユニバーサル'マルチメディア 'アクセス · フレームワークにおける多様な処理モジュール間の通信方法であって、請求項 4 に記載のメッセージ情報本体が、応答メッセージを用いて請求項 8に記載の当該要請メッセージに応答する状況において、要請された情報の種類を、 R i gh t s I n f o rma t i o n、 I PMP I n f o r m a t i on、 D IAI n f o rma t i o n、 D I I I n f o r m a t i o n、及び O t h e r I n f o rma t i o nの歹 lj挙で記述する、 I n ί o rma t i o nC l a s sを含むステップと、

前記値、パラメータ、又はステータス等の要請された実際の情報データを、適切に作成された XM Lフラグメントを直接含むメッセージ 'ペイロードとして記述する、 I n f o rma t i o nDa t aを含むステップとを更に含む、通信方法である。産業上の利用の可能十生

本発明は、デジタルアイテムの処理方法おょぴ装置に利用可能である。

Claims

請求の範囲

1. マルチメディア 'フレームワークに基づく信号を受信し、そこに含まれるデジタルァィテムの処理方法であって、

2) 権利記述言語である R E Lにより処理する R E L処理

3) 権利データ辞書である RDDにより処理する R D D処理

6) イベント報告である ERにより処理する ER処理ステップ、

とを有し、

D I D処理ステップ、 D IM処理ステップ、他の処理ステップの内いずれか 2 つの処理ステップ間で直接データの送受信がなされることを特徴とする処理方法。 2. 上記各処理ステップにおいて、送信元と送信先を特定するメッセージである I n t e r n a l Me s s a g e標識を用いることを特徴とする、請求項 1に記載の処理方法。

3. 前記 I n t e r n a lMe s s a g e標識は、送信用の T r a n s m i t Ty p eと、要請用の R e qu e s t Typ eと、応答用の R e s p o n s eT y p eに分かれていることを特徴とする、請求項 2に記載の処理方法。

4. 前記 I n t e r n a lMe s s a g e標識には、ひとつのテーマに対し、ひとつのメッセージ識別子である Ms g— I Dが含まれていることを特徴とする、請求項 2に記載の処理方法。

5. 前記送信用の T r a n s m i t Ty p eの I n t e r n a 1 Me s s a g e標識には、伝送及び交換される情報の種類を特定する I n f o rma t i o n C 1 a s s標識を含むことを特徴とする、請求項 3に記載の処理方法。

6. Wl gd要請用の R e q u e s tTy p eの I n t e r n a 1 M e s s a g e 標識には、伝送及び交換される情報の種類を特定する I n i o rma t i o nC 1 a s s標識を含むことを特徴とする、請求項 3に記載の処理方法。

7. 目 U cy心答用の R e s p o n s e Ty p eの I n t e r n a 1 M e s s a g e標識には、処理を停止させ、または実行させる GoNo Go標識を含むことを特徴とする、請求項 3に記載の処理方法。

8. 目 ij cy心答用の R e s p o n s e Ty p eの I n t e r n a 丄 Me s s a g e標識には、追加情報を伝送する I n f o標識を含むことを特徴とする、請求項 3に記載の処理方法。

9. マルチメディア■フレームワークに基づく信号を受信し、そこに含まれるデジタルアイテムの処理装置であって、

コンテンッ構成要素及びその構造が示されるデジタルアイテム宣言である D I

Dを処理する D I Dエンジンと、

前記 D I Dに含まれる基本動作を解釈し、デジタルアイテム方法である D IM により処理する D IMエンジンと、

次のエンジンの内少なくともひとつの他のエンジン

1) デジタルアイテム識別である D I Iにより処理する D I I

2) 権利記述言語である RELにより処理する RELエンジン、

3 ) 権利データ辞書である RDDにより処理する RDDエンジン、

4 ) 知的財産管理保護である I P M Pにより処理する I P M Pェン 5) デジタルアイテム適応である D I Aにより処理する D I Aエンジン、

6) イベント報告である ERにより処理する ERエンジン、

とを有し、

D I Dエンジン、 D IMエンジン、他のエンジンの内いずれか 2つのエンジン間で直接データの送受信がなされることを特徴とする処理装置。

10. 上記各エンジンにおいて、送信元と送信先を特定するメッセージである I n t e r n a lMe s s a g e標識を用いることを特徴とする、請求項 9に記載の処理装置。

11. 前記 I n t e r n a l Me s s a g e標識は、送信用の T r a n s m i t Ty p eと、要請用の R e q u e s tTyp eと、応答用の： R e s p o n s e

Ty eに分かれていることを特徴とする、請求項 10に記載の処理装置。

12. 前記 I n t e r n a lMe s s a g e標識には、ひとつのテーマに対し、ひとつのメッセージ識別子である Ms g__I Dが含まれていることを特徴とする、請求項 10に記載の処理装置。

13. 前記送信用の T r a n smi tTyp eの I n t e r n a lMe s s a g e標識には、伝送及び交換される情報の種類を特定する I n f o rma t i o nC 1 a s s標識を含むことを特徴とする、請求項 11に記載の処理装置。

14. 刖 d要請用の R e q u e s tTyp eの I n t e r n a 1 M e s s a g e標識には、伝送及び交換される情報の種類を特定する I n f o rma t i o n C 1 a s s標識を含むことを特徴とする、請求項 1 1に記載の処理装置。

15. 目 U CJ心答用の R e s p o n s eTyp eの I n t e r n a 1 M e s s a g e標識には、処理を停止させ、または実行させる GoNo Go標識を含むことを特徴とする、請求項 11に記載の処理装置。 .

16 · 目 ijgdJ心答用の R e s p on s eTyp eC I n t e r n a 1 M e s s a g e標識には、追加情報を伝送する I n f o標識を含むことを特徴とする、請求項 11に記載の処理装置。