(57)【要約】【課題】  多様な処理エンジン間において特定の方法で通信を容易にするための、シンタックスとセマンティクスを備えた汎用メッセージ構造を定義することにより、異なるアプリケーション用の異なるＭＰＥＧ−２１端末に最大限の柔軟性及び相互動作性を持たせて幅広く利用できるようにする。【解決手段】  定義されたメッセージＡＰＩを備えたＭＰＥＧ−２１端末又はＭＰＥＧ−２１モジュールを構築し、異なるベンダーから提供される異なる処理エンジンを特定の方法で共に動作させる。【選択図】      図１０
2005012777.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア・フレームワークに基づく信号を受信し、そこに含まれるデジタルアイテムの処理方法であって、
コンテンツ構成要素及びその構造が示されるデジタルアイテム宣言であるＤＩＤを処理するＤＩＤ処理ステップと、
前記ＤＩＤに含まれる基本動作を解釈し、デジタルアイテム方法であるＤＩＭにより処理するＤＩＭ処理ステップと、
次の処理ステップの内少なくともひとつの他の処理ステップ
１）  デジタルアイテム識別であるＤＩＩにより処理するＤＩＩ処理ステップ、
２）  権利記述言語であるＲＥＬにより処理するＲＥＬ処理ステップ、
３）  権利データ辞書であるＲＤＤにより処理するＲＤＤ処理ステップ、
４）  知的財産管理保護であるＩＰＭＰにより処理するＩＰＭＰ処理ステップ、
５）  デジタルアイテム適応であるＤＩＡにより処理するＤＩＡ処理ステップ、
６）  イベント報告であるＥＲにより処理するＥＲ処理ステップ、
とを有し、
ＤＩＤ処理ステップ、ＤＩＭ処理ステップ、他の処理ステップの内いずれか２つの処理ステップ間で直接データの送受信がなされることを特徴とする処理方法。
【請求項２】
上記各処理ステップにおいて、送信元と送信先を特定するメッセージであるＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識を用いることを特徴とする、請求項１に記載の処理方法。
【請求項３】
前記ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識は、送信用のＴｒａｎｓｍｉｔＴｙｐｅと、要請用のＲｅｑｕｅｓｔＴｙｐｅと、応答用のＲｅｓｐｏｎｓｅＴｙｐｅに分かれていることを特徴とする、請求項２に記載の処理方法。
【請求項４】
前記ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、ひとつのテーマに対し、ひとつのメッセージ識別子であるＭｓｇ＿ＩＤが含まれていることを特徴とする、請求項２に記載の処理方法。
【請求項５】
前記送信用のＴｒａｎｓｍｉｔＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、伝送及び交換される情報の種類を特定するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識を含むことを特徴とする、請求項３に記載の処理方法。
【請求項６】
前記要請用のＲｅｑｕｅｓｔＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、伝送及び交換される情報の種類を特定するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識を含むことを特徴とする、請求項３に記載の処理方法。
【請求項７】
前記応答用のＲｅｓｐｏｎｓｅＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、処理を停止させ、または実行させるＧｏＮｏＧｏ標識を含むことを特徴とする、請求項３に記載の処理方法。
【請求項８】
前記応答用のＲｅｓｐｏｎｓｅＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、追加情報を伝送するＩｎｆｏ標識を含むことを特徴とする、請求項３に記載の処理方法。
【請求項９】
マルチメディア・フレームワークに基づく信号を受信し、そこに含まれるデジタルアイテムの処理装置であって、
コンテンツ構成要素及びその構造が示されるデジタルアイテム宣言であるＤＩＤを処理するＤＩＤエンジンと、
前記ＤＩＤに含まれる基本動作を解釈し、デジタルアイテム方法であるＤＩＭにより処理するＤＩＭエンジンと、
次のエンジンの内少なくともひとつの他のエンジン
１）  デジタルアイテム識別であるＤＩＩにより処理するＤＩＩエンジン、
２）  権利記述言語であるＲＥＬにより処理するＲＥＬエンジン、
３）  権利データ辞書であるＲＤＤにより処理するＲＤＤエンジン、
４）  知的財産管理保護であるＩＰＭＰにより処理するＩＰＭＰエンジン、
５）  デジタルアイテム適応であるＤＩＡにより処理するＤＩＡエンジン、
６）  イベント報告であるＥＲにより処理するＥＲエンジン、
とを有し、
ＤＩＤエンジン、ＤＩＭエンジン、他のエンジンの内いずれか２つのエンジン間で直接データの送受信がなされることを特徴とする処理装置。
【請求項１０】
上記各エンジンにおいて、送信元と送信先を特定するメッセージであるＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識を用いることを特徴とする、請求項９に記載の処理装置。
【請求項１１】
前記ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識は、送信用のＴｒａｎｓｍｉｔＴｙｐｅと、要請用のＲｅｑｕｅｓｔＴｙｐｅと、応答用のＲｅｓｐｏｎｓｅＴｙｐｅに分かれていることを特徴とする、請求項１０に記載の処理装置。
【請求項１２】
前記ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、ひとつのテーマに対し、ひとつのメッセージ識別子であるＭｓｇ＿ＩＤが含まれていることを特徴とする、請求項１０に記載の処理装置。
【請求項１３】
前記送信用のＴｒａｎｓｍｉｔＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、伝送及び交換される情報の種類を特定するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識を含むことを特徴とする、請求項１１に記載の処理装置。
【請求項１４】
前記要請用のＲｅｑｕｅｓｔＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、伝送及び交換される情報の種類を特定するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識を含むことを特徴とする、請求項１１に記載の処理装置。
【請求項１５】
前記応答用のＲｅｓｐｏｎｓｅＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、処理を停止させ、または実行させるＧｏＮｏＧｏ標識を含むことを特徴とする、請求項１１に記載の処理装置。
【請求項１６】
前記応答用のＲｅｓｐｏｎｓｅＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、追加情報を伝送するＩｎｆｏ標識を含むことを特徴とする、請求項１１に記載の処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタルアイテムの処理方法および装置に関し、更に詳しくは、ユニバーサル・マルチメディア・アクセス・フレームワークにおいて存在し、フォーマットの異なるマルチメディア・リソースにアクセスするためにその内部が使用される様々なモジュールの処理を行うことができる、統一マルチメディア端末に関する。特に、多様な処理モジュール間の内部通信メカニズム及びフォーマットに関する。
【背景技術】
【０００２】
ＭＰＥＧ及びその他の標準化団体は、ビデオ、オーディオ、システム、通信プロトコル、コンテンツ表現、コンテンツ・パッケージング等に関して、ある場所から別の場所へのコンテンツの転送及び提供を効率的な方法で容易に行えるように、また大容量のコンテンツを限られたスペース内に容易に記憶できるようにするために、数多くの規格を制定してきた。
【０００３】
ユニバーサル・マルチメディア・アクセス・フレームワークは、複数のアプリケーション・ドメインにおける異なるカテゴリーのユーザによる、あらゆる種類のコンテンツの提供及び使用をサポートすることが可能な環境で、構築する必要がある。このようなフレームワークでは、共用ビジョン、つまりロードマップがそのアーキテクトによって理解され、確実に、メディア・リソースを提供するシステムが相互動作可能でトランザクションが簡単に行われることが要求される。このことは、コンテンツの提供、コンテンツのセキュリティー、権利管理、確実な支払い、及びこれらを可能にする技術に関するインフラストラクチャーの要件にも当てはまる。つまり、コンテンツ所有者、アーティスト、エンドユーザ、サービスプロバイダ、及びＣＥ製造業者の全ての人は、このフレームワークが各自の目的をサポートするものであることがわかる。
【０００４】
デジタルアイテム（ＤＩ：Ｄｉｇｉｔａｌ  Ｉｔｅｍ）とは、当該フレームワーク内における標準の表現、識別及び記述で構成されたデジタル対象物であると定義されている。この実体は、ＭＰＥＧ−２１のフレームワーク内での配信及びトランザクションの基本単位でもあり、その目的はＤＩの電子商取引を可能にすることである。このフレームワークに基づいて、既に入念に開発された、又は現在開発中の主要技術がいくつかある。例えば、デジタルアイテム宣言（ＤＩＤ：Ｄｉｇｉｔａｌ  Ｉｔｅｍ  Ｄｅｃｌａｒａｔｉｏｎ）は、その構成要素と構造（つまりリソースとメタデータ）という見地からマルチメディア・コンテンツを定義することを目的とした規格であり、ＤＩＤはＸＭＬで記述される。
【０００５】
ＤＩＤに加えて、デジタルアイテム識別（ＤＩＩ：Ｄｉｇｉｔａｌ  Ｉｔｅｍ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、デジタルアイテム適応（ＤＩＡ：Ｄｉｇｉｔａｌ  Ｉｔｅｍ  Ａｄａｐｔａｔｉｏｎ）、知的財産管理保護（ＩＰＭＰ：Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ  Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｐｒｏｔｅｃｔｉｏｎ）、権利記述言語（ＲＥＬ：Ｒｉｇｈｔｓ  Ｅｘｐｒｅｓｓｉｏｎ  Ｌａｎｇｕａｇｅ）／権利データ辞書（ＲＤＤ：Ｒｉｇｈｔｓ  Ｄａｔａ  Ｄｉｃｔｉｏｎａｒｙ）、及びイベント報告（ＥＲ：Ｅｖｅｎｔ  Ｒｅｐｏｒｔｉｎｇ）は、ＭＰＥＧ−２１を形成する重要な技術である。
【０００６】
いかなるトランザクションでも、当該トランザクションの対象を特定する必要性及びその手段がある。ＤＩＩは、独自にＤＩを特定し、ＩＳＢＮが書籍に対して行うのと同様の役割を果たす。
【０００７】
かつてコンテンツプロバイダやサービスプロバイダは、各自の顧客を熟知しており、また各自のコンテンツを配信する手段も熟知し、又はこれを制御してきた。同時に、消費者は、テレビ、映画、音楽等の、はっきりと分類されたサービスの意味を理解していた。しかし今日、我々のこのような確信は揺らいでいる。エンドユーザはかつてなく予測不能であり、同一のコンテンツが多様な提供システムによって届けられ、様々な異なる消費装置でこれらを楽しむことができる。ＤＩＡは、ＤＩが、ユーザ、ネットワーク及び装置のプロパティの具体的な特徴に最適になるよう、これをどのように適応させる（変形させる）べきかを記述する手段の提供を行う。ＤＩＡの仕様は、基本的な利用環境記述ツール、ＤＩリソース適応ツール、ＤＩＤ適応ツールを定義する。
【０００８】
ＤＩを管理し保護するＩＰＭＰのアーキテクチャは、ＤＩバリューチェーンのあらゆるメンバーによるＤＩの配信、管理、及び利用に関連する、権利、条件、結果及び責務（ＲＥＬ／ＲＤＤ情報）の記述と施行を提供する。ここでは、ＤＩに関わるＩＰＭＰをできるだけ詳細に記述する手段と、当該アーキテクチャを持つトラストの役割と、ＤＩ管理及び利用可能性が、委託された実体が保証する特定の基準を満たすことを主張する能力等の機能のための端末要件に支えられた相互動作性とを定義する必要がある。
【０００９】
ＥＲの目的は、あらゆる報告可能なイベントのパフォーマンスに関する測定基準とインターフェースを提供することである。マルチメディア・フレームワークでこれを標準化する必要性は、複数の端末とユーザーとの間、又は１つの端末内において、いかなる時点でも、ＤＩ及び／又はこれによって作動するプログラム、装置、端末内部モジュールに関するイベントを監視し、通信する必要性から発生している。
【００１０】
先行技術であるＩＳＯ／ＩＥＣ２１０００−２：ＭＰＥＧ−２１  ＤＩＤを図１に示し、ＤＩＤ（コンテンツ構成要素及びその構造）に静的ＩＰＭＰ記述子及びＤＩＡ記述子情報を含むことが可能である現状について述べる。ＤＩ宣言（モジュール１．１）は、いくつかの基本トランザクション単位ＤＩ（モジュール１．２、１．３、１．４）で構成され、プロバイダからユーザへ提供される。当該宣言内では、いくつかの重要なＩＰＭＰ記述子情報（モジュール１．５）及びＤＩＡ記述子情報（モジュール１．６）も、ＤＩトランザクションの保護及び適応に関するマルチメディア・フレームワークを支えるために伝送される。ＲＥＬ／ＲＤＤ記述子情報及びＥＲ記述子情報についても、同様の状況が当てはまる。
【００１１】
図２に、他の先行技術であるＩＳＯ／ＩＥＳ  ＪＴＣ１／ＳＣ２９／ＷＧ１１／Ｎ５６２１：ＭＰＥＧ−２１  ＤＩＰを示す。ここで、ＤＩＤエンジンはモジュール２．１に示されており、ＤＩＩエンジンはモジュール２．２に、ＩＰＭＰエンジンはモジュール２．３に、ＲＥＬエンジンはモジュール２．４に、ＲＤＤエンジンはモジュール２．５に、ＤＩＡエンジンはモジュール２．６に、ＥＲエンジンはモジュール２．７にそれぞれ示されている。ＤＩＤ、ＤＩＩ、ＩＰＭＰ、ＲＥＬ／ＲＤＤ、ＤＩＡ、ＥＲ等の異なる技術要素の処理に使用できるこれらの処理エンジンは、ＭＰＥＧ−２１の範囲内に一定の標準部分を伴って定義されている。
【００１２】
モジュール２．８における処理エンジンとデジタルアイテム方法エンジン（ＤＩＭＥ：Ｄｉｇｉｔａｌ  Ｉｔｅｍ  Ｍｅｔｈｏｄ  Ｅｎｇｉｎｅ）との間の関係、モジュール２．９におけるＤＩＭＥとユーザとの間の関係、またモジュール２．１０におけるＤＩＭＥとデジタルアイテム基本動作（ＤＩＢＯ：Ｄｉｇｉｔａｌ  Ｉｔｅｍ  Ｂａｓｅ  Ｏｐｅｒａｔｉｏｎｓ）との間に関係については、可能性を示しているに過ぎない。ＤＩＭＥとサブ処理エンジンとの間の実際の通信は、相互動作可能な情報伝送の駆動についてはまだ定義されていない。
【００１３】
更に、これらの処理エンジン間の関係は、まだ全く特定されていない。しかし、いかなるアプリケーションであっても、一方の処理エンジンから他方のエンジンへの通信は必要である。例えば、図１に示すように、ＤＩＤ記述はＩＰＭＰ記述子を含むが、ＤＩＤエンジンからＩＰＭＰエンジンを呼び出した方が、ＤＩＭエンジンに戻ってからＩＰＭＰエンジンを呼び出すよりも、より適切かつ迅速である。別の例として、ＤＩＡ記述子はＤＩＤ記述に含まれるが、ＤＩＤエンジンからＤＩＡエンジンを呼び出した方が、ＤＩＭエンジンに戻ってからＤＩＡエンジンを呼び出すよりも、より適切かつ迅速である。別のアプリケーションでは、ＩＰＭＰ記述はＲＥＬ記述子を含んでもよく、ＲＥＬ記述はＲＤＤ記述子を含んでもよい。またＤＩＩ記述がＥＲ記述子を含んでもよい。従って、これらのエンジンは全て、相互に通信可能な能力が必要である。この通信は、端末内通信とも呼ばれ、特に、他のエンジンによって処理されたあらゆる処理情報がＥＲエンジンへ又はＥＲエンジンから伝送されなければならないイベント報告処理については、このように呼ばれている。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明は、以下の問題を解決することを課題とする。
【００１５】
即ち、ＭＰＥＧ−２１で定義されるシステム構造は、先行技術に示されるように、処理シーケンスが固定された順序及びパターンを取らず次の行動を予測できない、多様なアプリケーションをカバーすることを目的としている。しかし、処理結果は一方のエンジンから他方のエンジンへと伝送しなければならず、またそれは、その時点におけるユーザのオンラインでの嗜好によって異なる場合もある。従って、これらの処理エンジンが相互に情報を転送できるよう、汎用通信メカニズムを設定し、定義する必要がある。
【００１６】
周知の通り、先行技術に示されるシステムは、多様な処理エンジン又はモジュールから構成されており、これらは同一のベンダーから提供されるものではない場合もある。しかし、このような多様なモジュール間で、情報を転送し共用しなければならない。これらの多様な処理モジュールを統合して規格に準拠する端末を構築する場合は、これらの処理エンジンが相互に情報を転送できるように、汎用通信メカニズムを設定し、定義する必要がある。
すなわち、従来の処理方法にあっては、中央制御エンジンであるＤＩＭエンジンを中心として、放射状に種々のエンジンにデータを送り、再びＤＩＭエンジンに戻され、続いて別のエンジンにデータが送り出されるような、ハブ型制御モードのみで処理されていた。
【００１７】
このような通信メカニズムは、情報の送信先又は発信元、そのメッセージへの応答、及び特定のフォーマットの情報本体を示す汎用構造を備える必要がある。
【課題を解決するための手段】
【００１８】
多様なＭＰＥＧ−２１モジュールで使用できる汎用メッセージ構造を備えた一連のメッセージを定義することにより、これらのモジュール間の通信を、ＭＰＥＧ−２１端末内で特定の方法で行うことができる。
【００１９】
基本メッセージ構造を使用し、内部ＭＰＥＧ−２１モジュール交渉メッセージ内で共通インフラストラクチャーを記述することにより、あらゆるタイプのメッセージによって容易に拡張することができる。
【００２０】
各送信メッセージにＩＤを割り当てて識別システムを構築することにより、いかなる応答メッセージも、同一ＩＤを持つメッセージへの応答であることが認識される。
【００２１】
モジュール名を使用して、ＭＰＥＧ−２１端末内でメッセージの送信側又は受信側を示すことにより、送信メッセージ又は応答メッセージのいずれについても、明確かつ直接的に行き先が示される。
【００２２】
異なるタイプのメッセージを使用して、現行メッセージが送信用か、要請用か、又は応答用かを示す。
【００２３】
拡張メッセージ構造にメッセージ情報本体を含めることにより、一方のモジュールから他方のモジュールへ送信／要請／応答されると思われる実際の情報を伝送する。
【００２４】
（作用）
ＭＰＥＧ−２１端末は、パーサを備えたＤＩＤモジュール、パーサを備えたＤＩＩモジュール、パーサを備えたＤＩＡモジュール、パーサを備えたＲＥＬ／ＲＤＤモジュール、パーサを備えたＩＰＭＰモジュール、パーサを備えたＥＲモジュール等の多様な処理モジュールで構成される。
【００２５】
ＤＩＤ文書はＭＰＥＧ−２１端末に提供され、パーサを備えたＤＩＤモジュールは、端末の入口ドアのような役割をしてＤＩＤ文書を開き、ＤＩＤ文書の処理を行う。
【００２６】
処理結果は、ユーザに直接提供されることもあれば、次の処理のために次のモジュールに伝送されることもある。後者の場合、メッセージは次のモジュールへ直接送信されるか、又は制御エンジンＤＩＭＥを介して送信されなければならない。ＤＩＭＥは中央ルータのようなものであり、異なる方法／動作を取り扱い、ユーザからの入力を受け取ると考えられる。このようなメッセージ構造は、メッセージＩＤと、送信側モジュールの名前と、受信側モジュールの名前と、メッセージ情報本体とから構成される。メッセージ受信側モジュールは、送信側モジュールに対して「ＧｏＮｏＧｏ」情報で応答し、送信側モジュールの処理を中止させるか、又は送信側モジュールに処理を行わせる。
【００２７】
中には、別のモジュールに自身が処理する情報を要請する動作を行うことができるモジュールもある。当該メッセージの受信側は、送信側が要請している実際のメッセージを応答する。
【００２８】
一方のモジュール内で処理が終了すると、他方のモジュールに別の情報を送信する必要がある場合があり、定義されたメッセージ構造に従って、同様の方法で一方のモジュールから他方のモジュールへと通信が継続される。
本発明の第１の観点は、マルチメディア・フレームワークに基づく信号を受信し、そこに含まれるデジタルアイテムの処理方法であって、
コンテンツ構成要素及びその構造が示されるデジタルアイテム宣言であるＤＩＤを処理するＤＩＤ処理ステップと、
前記ＤＩＤに含まれる基本動作を解釈し、デジタルアイテム方法であるＤＩＭにより処理するＤＩＭ処理ステップと、
次の処理ステップの内少なくともひとつの他の処理ステップ
１）  デジタルアイテム識別であるＤＩＩにより処理するＤＩＩ処理ステップ、
２）  権利記述言語であるＲＥＬにより処理するＲＥＬ処理ステップ、
３）  権利データ辞書であるＲＤＤにより処理するＲＤＤ処理ステップ、
４）  知的財産管理保護であるＩＰＭＰにより処理するＩＰＭＰ処理ステップ、
５）  デジタルアイテム適応であるＤＩＡにより処理するＤＩＡ処理ステップ、
６）  イベント報告であるＥＲにより処理するＥＲ処理ステップ、
とを有し、
ＤＩＤ処理ステップ、ＤＩＭ処理ステップ、他の処理ステップの内いずれか２つの処理ステップ間で直接データの送受信がなされることを特徴とする処理方法である。
本発明の第２の観点は、上記各処理ステップにおいて、送信元と送信先を特定するメッセージであるＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識を用いることを特徴とする、処理方法である。
本発明の第３の観点は、前記ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識は、送信用のＴｒａｎｓｍｉｔＴｙｐｅと、要請用のＲｅｑｕｅｓｔＴｙｐｅと、応答用のＲｅｓｐｏｎｓｅＴｙｐｅに分かれていることを特徴とする処理方法である。
本発明の第４の観点は、前記ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、ひとつのテーマに対し、ひとつのメッセージ識別子であるＭｓｇ＿ＩＤが含まれていることを特徴とする処理方法である。
本発明の第５の観点は、前記送信用のＴｒａｎｓｍｉｔＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、伝送及び交換される情報の種類を特定するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識を含むことを特徴とする処理方法である。
本発明の第６の観点は、前記要請用のＲｅｑｕｅｓｔＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、伝送及び交換される情報の種類を特定するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識を含むことを特徴とする処理方法である。
本発明の第７の観点は、前記応答用のＲｅｓｐｏｎｓｅＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、処理を停止させ、または実行させるＧｏＮｏＧｏ標識を含むことを特徴とする処理方法である。
本発明の第８の観点は、前記応答用のＲｅｓｐｏｎｓｅＴｙｐｅのＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識には、追加情報を伝送するＩｎｆｏ標識を含むことを特徴とする処理方法である。
【発明の効果】
【００２９】
中央制御エンジンであるＤＩＭを介さず処理がなされるから、処理の効率を上げることができる。
規格に準拠した様々な端末が、固定されたシーケンスの順序がなく行動が予測できない多様な種類のアプリケーションをカバーできるようにする、汎用メッセージ構造を定義することにより、多様な処理エンジン間の通信が相互に動作可能な方法で実現される。本発明により、ＭＰＥＧ−２１端末の柔軟性が高まり、より簡単かつ迅速な方法でデジタルアイテムを処理することが可能となる。
【００３０】
本発明のメッセージ構造は、端末内の複数の処理エンジン間においてあらゆる種類の情報を伝送するための、簡単かつ共通のものであり、異なる処理エンジン毎に特別なＡＰＩを定義するといった問題を解決することができる。
【発明を実施するための最良の形態】
【００３１】
図３は、ＭＰＥＧ−２１のフレームワーク内で、デジタルアイテム（ＤＩ）が、サーバ（プロバイダ）１０からユーザ（消費者）１２に配信される様子を説明する図である。ここで、デジタルアイテムは、音声、映像、及びＩＰＭＰデータ等のメディアコンテンツを含むコンテンツ部１４と、各々のメディアコンテンツのアドレスを含むヘッダ部１６とから成る。ＭＰＥＧ−２１のフレームワーク内では、通常、図３に示されるように、デジタルアイテムのヘッダ部１６が、コンテンツ部１４よりも先に、ユーザ１２に配信される。ユーザ１２は、デジタルアイテムのヘッダ部１６を先に受信し、サーバから提示される条件に同意する場合にのみ、パッケージ化されたコンテンツ部１４を受信することができる。
【００３２】
図５は、ＤＩＤ形式で記述されたデジタルアイテムのヘッド部１６に対応するＤＩＤドキュメントを示す図である。ＤＩＤドキュメントは、いくつかのデジタルアイテム２０，２２，２４を含む。また、それぞれのデジタルアイテム２０，２２，２４のリソース２６は、実際のデジタルコンテンツを所有する所有元のアドレスを含む。さらに、ＤＩＤドキュメントは、いくつかのＩＰＭＰ記述子情報（ステートメント）２８、及びＤＩＡ記述子情報（ステートメント）３０も含む。さらに、ＤＩＤドキュメントは、ＲＥＬ（Ｒｉｇｈｔｓ Ｅｘｐｒｅｓｓｉｏｎ Ｌａｎｇｕａｇｅ）／ＲＤＤ（Ｒｉｇｈｔｓ Ｄａｔａ Ｄｉｃｔｉｏｎａｒｙ）記述子情報、及びＥＲ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ）記述子情報（図示されない）等を含んでもよい。
【００３３】
ここで、ＤＩＤドキュメントは、図５の点線Ａに示されるように、デジタルアイテム方法（ＤＩＭ：Ｄｉｇｉｔａｌ Ｉｔｅｍ Ｍｅｔｈｏｄ）の記述を含む。このＤＩＭの記述は、ユーザがコンテンツに対して実行できるコンテンツの基本動作に含まれる基本処理（再生、複製、及び印刷等）を指定するものである。具体的に、図５のＤＩＭの記述は、「ユーザが、１００円支払えば、コンテンツを２回再生できる」ことを意味する。ユーザ（ＭＰＥＧ−２１端末）は、ＤＩＤドキュメントにおけるＩＰＭＰ記述子情報２８、及びＤＩＡ記述子情報３０等の記述に従って処理を行う。すなわち、ユーザは、１００円支払うことに同意した場合にのみ、図５のリソースに記述されたアドレスに存在するメディアコンテンツを再生することができる。
【００３４】
図４は、これまで説明したデジタルアイテムの送受信処理を示すフロー図である。まず、サーバ１０が、デジタルアイテムをデジタルアイテム宣言形式で記述する（ステップＳ１）。次に、サーバ１０が、デジタルアイテム宣言形式で記述されたデジタルアイテム（のヘッダ部１６）を、ユーザ（ＭＰＥＧ−２１端末）１２に配信（送信）する（ステップＳ２）。ユーザ１２は、サーバ１０から送信された、デジタルアイテム宣言形式で記述されたデジタルアイテム（のヘッダ部１６）を受信する（ステップＳ３）。
【００３５】
以下に、図５に示されるＤＩＤドキュメントを受信したときのユーザ１２（ＭＰＥＧ−２１端末）の処理について説明する。図６は、ＭＰＥＧ−２１端末１２のシステムの構成を示すブロック図である。図６に示されるように、ＭＰＥＧ−２１端末１２は、デコーダ４０、出力部４２、及びユーザ入力部４４を含む。デコーダ４０は、ＤＩＤパーサ４６を含むＤＩＤエンジン５０、ＤＩＭプレゼンタ５８を含むＤＩＭエンジン４８、ＤＩＩエンジン５１、ＩＰＭＰエンジン５２、ＲＥＬエンジン５３、ＲＤＤエンジン５４、ＤＩＡエンジン５５、ＥＲエンジン５６を含む。ＤＩＤエンジン５０は、ＤＩＭエンジン４８に接続されると共に、ＤＩＩエンジン５１、ＩＰＭＰエンジン５２、ＲＥＬエンジン５３、ＲＤＤエンジン５４、ＤＩＡエンジン５５、ＥＲエンジン５６にも接続される。ＤＩＭエンジン４８も同様に、ＤＩＩエンジン５１、ＩＰＭＰエンジン５２、ＲＥＬエンジン５３、ＲＤＤエンジン５４、ＤＩＡエンジン５５、ＥＲエンジン５６に接続される。更に、ＤＩＩエンジン５１、ＩＰＭＰエンジン５２、ＲＥＬエンジン５３、ＲＤＤエンジン５４、ＤＩＡエンジン５５、ＥＲエンジン５６は互いに接続されている。
【００３６】
図７は、ＤＩＤドキュメントを受け取ったときにＭＰＥＧ−２１端末１２が行う処理のフロー図である。図７に示されるように、まず、デコーダ４０のＤＩＤパーサ４６が、ＤＩＤ形式で記述されたデジタルアイテムの中身を解析する（ステップＳ１１）。ＤＩＤパーサ４６は、デジタルアイテムにおいてＤＩＭの記述が出現すると（＜ＵｓａｇｅＲｕｌｅ＞の記述が出現すると）、ＤＩＤドキュメントを、サブルーチンであるＤＩＭプレゼンタ５８に送る。次に、ＤＩＭプレゼンタ５８は、ＤＩＭの記述を解釈する（ステップＳ１２）。そして、ＤＩＭプレゼンタ５８は、ＤＩＭにより指定された基本処理のセマンティクスに従って、その基本処理を実行するために必要な値又はパラメータをユーザに要求すると同時に、その基本処理をユーザに提示する。ここでは、「ユーザから１００円支払うか否かを示す情報を取得する」というセマンティクスに従って、出力部４２を用いて、ユーザに、「１００円支払うか否か」の問いに答える値又はパラメータを要求する（ステップＳ１３）。例えば、出力部４２がディスプレイのとき、「１００円支払って再生しますか？」というメッセージが、ディスプレイに表示される。
【００３７】
ユーザは、ユーザ入力部４４を用いて、１００円支払うか否かという問いに対する答えを示す値又はパラメータを入力する。ＤＩＭプレゼンタ５８は、その値又はパラメータを取得する（ステップＳ１４）。ＤＩＭプレゼンタ５８は、取得した値又はパラメータに基づき、ユーザが１００円支払うか否かを判断する（ステップＳ１５）。ＤＩＭプレゼンタ５８は、ユーザが１００円支払うと判断する（例えば、取得した値又はパラメータが「ＴＲＵＥ」である）（ステップＳ１５）と、取得した値又はパラメータを、ＤＩＩエンジン５１、ＩＰＭＰエンジン５２、ＲＥＬエンジン５４、ＲＤＤエンジン５４、ＤＩＡエンジン５５，ＥＲエンジン５６に転送し、再生を続行する（ステップＳ１６）。一方、ユーザが１００円を支払わないと判断する（例えば、取得した値又はパラメータが「ＦＡＬＳＥ」である）（ステップＳ１５）と、ＤＩＭプレゼンタ５８は、取得した値又はパラメータを、ＤＩＩエンジン５０、ＩＰＭＰエンジン５２、ＲＥＬエンジン５３、ＲＤＤエンジン５４、ＤＩＡエンジン５５，ＥＲエンジン５６に転送し、再生を中止する（ステップＳ１７）。ここで、ＤＩＭプレゼンタ５８は、ステップＳ４において、ユーザから値又はパラメータを取得したとき、ユーザから特定の形式で入力された値又はパラメータを、ＤＩＭによって必要とされる指定された形式に変換することができる。つまり、ユーザから、１００円を支払うか否かを示す値又はパラメータを取得し、それを指定された形式に変換して、ＤＩＩエンジン５０等に転送することができる。
【００３８】
上述したように、ＤＩＤ形式で記述されたデジタルアイテムに、コンテンツの基本処理（例えば、再生、コピー、印刷）を指定するデジタルアイテム方法を追加することにより、サーバ側が、配信されたコンテンツをユーザがどのように処理するかまで指定することができる。よって、ユーザに配信されるコンテンツの著作権を十分に保護することができる。
【００３９】
なお、上述の説明では、デジタルアイテム２０，２２，２４のリソース２６が、実際のデジタルコンテンツを所有する所有元のアドレスを含むとしたが、各々のデジタルアイテムが、実際のデジタルコンテンツを含んでもよい。
【００４０】
再生が続行される場合、ＤＩＭプレゼンタ５８は、デジタルアイテムの記述に従って、サーバからコンテンツを取得するためのいくつかの準備処理（「再生」処理に付随する付随処理）を行う。図８は、ＤＩＭプレゼンタ５８が複数の準備処理を実行するときの処理を示すフロー図である。図８に示されるように、まず、ＤＩＭプレゼンタ５８は、ＤＩＡエンジン５５を呼び出し、デジタルアイテムのＤＩＡ記述とＭＰＥＧ−２１端末のＤＩＡ記述の適合を調べさせる（ＤＩＡ適合処理：ステップＳ２１）。これにより、ＭＰＥＧ−２１端末のデコーダの機能が、コンテンツに適合しているかどうかを調べる。図９は、ＤＩＭプレゼンタ５８が行うＤＩＡ適合処理のフロー図である。ＤＩＭプレゼンタ５８は、ＤＩＡ適合処理に関するＤＩＭの記述を解釈する（ステップＳ３２）。そして、ＤＩＭプレゼンタ５８は、ユーザ、インターネット上のリソース、又はＤＩＤドキュメントに、ＤＩＭにより指定されたＤＩＡ記述適合処理のセマンティクスに従って、そのＤＩＡ適合処理を実行するために必要な値又はパラメータを要求する（ステップＳ３３）。ＤＩＭプレゼンタ５８は、ユーザ、インターネット上のリソース、又はＤＩＤドキュメントから、必要な値又はパラメータを取得する（ステップＳ３４）と、ＤＩＡエンジン５５を呼び出し、取得した値又はパラメータを、ＤＩＡエンジン５５に転送して、ＤＩＡ適合処理を実行させる（ステップＳ３５）。ＤＩＡエンジン５５は、ＤＩＭプレゼンタ５８から転送された値又はパラメータを用いて、ＤＩＡ適合処理を行う。ＤＩＭプレゼンタ５８は、ＤＩＡエンジン５５から出力される信号により、２つのＤＩＡ記述が適合しないことを検知する（ＤＩＡエンジン５５から２つのＤＩＡ記述が適合しないことを示す信号を取得する）（ステップＳ２２）と、再生処理を中止する（図８，ステップＳ２３）。一方、ＤＩＡエンジン５５から出力される信号により、２つのＤＩＡ記述が適合していることを検知する（ＤＩＡエンジン５５から２つのＤＩＡ記述が適合したことを示す信号を取得する）（ステップＳ２２）と、ＤＩＭプレゼンタ５８は、ＩＰＭＰエンジン５２を呼び出して、ＩＰＭＰ処理を実行させる（ステップＳ２４）。ここで、ＤＩＭプレゼンタ５８は、ＤＩＡ適合処理と同様に、ＩＰＭＰ処理に必要な値又はパラメータを、ユーザ等から取得して、ＩＰＭＰエンジン５２に転送してもよい。ＩＰＭＰエンジン５２は、このＩＰＭＰ処理において、コンテンツがどんな方式で保護されているかを調べ、必要なＩＰＭＰツールを取得する。ＤＩＭプレゼンタ５８は、ＩＰＭＰエンジン５２から出力される信号により、ＩＰＭＰツールが取得できないことを検知する（ＩＰＭＰエンジン５２からＩＰＭＰツールが取得できないことを示す信号を取得する）（ステップＳ２５）と、再生処理を中止する（ステップＳ２３）。一方、ＤＩＭプレゼンタ５８が、ＩＰＭＰエンジン５２から出力される信号により、ＩＰＭＰツールが取得できることを検知する（ＩＰＭＰエンジン５２からＩＰＭＰツールを取得できることを示す信号を取得する）、すなわち、保護を解除できる場合には、ＤＩＭプレゼンタ５８は、次に、ＲＥＬエンジン５３を呼び出し、再生するための権利がそのユーザにあるか否かを調べさせる（ＲＥＬ処理：ステップＳ２６）。ここで、ＤＩＭプレゼンタ５８は、ＤＩＡ適合処理と同様に、ＲＥＬ処理に必要な値又はパラメータを、ユーザ等から取得して、ＲＥＬエンジン５３に転送してもよい。ＤＩＭプレゼンタ５８は、ＲＥＬエンジン５３から出力される信号により、再生するための権利（資格）がユーザにないことを検知する（ＲＥＬエンジン５３から再生するための権利がユーザにないことを示す信号を取得する）（ステップＳ２７）と、再生処理を中止する（ステップＳ２３）。一方、ＤＩＭプレゼンタ５８が、ＲＥＬエンジン５３から出力される信号により、再生するための権利がユーザにあることを検知する（ＲＥＬエンジン５３から再生するための権利がユーザにあることを示す信号を取得する）（ステップＳ２７）と、ＭＰＥＧ−２１端末は、サーバにコンテンツを要求し、サーバからコンテンツが提供される（ステップＳ２８）。なお、再生のための準備処理は、上述したものに限られない。もし、デジタルアイテムが保護されていないなら、ＩＰＭＰ処理は省略できる。また、ＩＰＭＰ処理が、ユーザに再生するための権利があるか否かを調べる処理を含む場合には、ＲＥＬ処理は省略できる。
【００４１】
さらに、各々の準備処理の順序は、上述したものに限られない。例えば、ＲＥＬ処理、ＤＩＡ適合、ＩＰＭＰ処理の順に行われてもよい。この順序は、ＤＩＤドキュメントにおけるＤＩＭの記述、例えば、各々の準備処理に関する記述が、どのような順序で存在するか等によって定められる。よって、サーバ側は、この準備処理の順序を自由に定めることができる。
【００４２】
ＤＩＭプレゼンタ５８は、ユーザとインタラクティブな関係にある。ユーザが１００円支払って再生することを選択した後、ＤＩＭプレゼンタ５８は、さらに、ＤＩＡ記述子情報（ステートメント）３０に記述されたＭＩＤの記述を解釈して、新たに別の処理（「再生」処理に付随する付随処理）を行うことができる。例えば、コンテンツが映像である場合、それは、表示サイズを決定する処理であってよい。ＤＩＭプレゼンタ５８は、表示サイズ決定処理の「ユーザから表示サイズを示す情報を取得する」というセマンティクスに基づき、ユーザに、表示サイズに関する値又はパラメータを要求してもよい。これは、例えば、ユーザに、複数の表示サイズの選択肢を提示することにより実現できる。ユーザがその選択肢の中から１つを選択すると、つまり、ＤＩＭプレゼンタ５８が、ユーザから、表示サイズに関する値又はパラメータを取得すると、ＤＩＭプレゼンタ５８は、取得した値又はパラメータを、ＤＩＡエンジン５０に転送する。または、ＤＩＭプレゼンタ５８は、取得した値又はパラメータを、ＤＩＤドキュメントにおけるＤＩＡ記述子情報３０の所定の位置に書き込み、そのＤＩＤドキュメントをＤＩＡエンジン５５に転送してもよい。
【００４３】
なお、上述の付随処理は基本動作に含まれるものであり、表示サイズを決定する処理に限られない。例えば、解像度を決定する処理等であってもよい。
本発明のデコーダ装置及び方法にあっては、ＤＩＭエンジン４８を中心として放射状にデータを送受信するハブ型制御モードと、ＤＩＭエンジン４８に戻さず、ＤＩＭエンジン４８に接続された周辺のエンジン５０−５６の間で直接データを送受信するラテラル型制御モードのいずれかの制御モードで動作可能である。
ハブ型制御モードの場合、処理されるデータは、ＤＩＭエンジン４８から周辺の一つのエンジン、たとえばＤＩＩエンジン５１に送り出され、ＤＩＩエンジン５１で処理され、処理されたデータは、再びＤＩＭエンジン４８に戻される。更に次の処理が必要であれば、データは、ＤＩＭエンジン４８から、次に処理がなされるエンジン、たとえばＩＰＭＰエンジン５２に送り出される。そして、ＩＰＭＰエンジン５２で処理されたデータは、再びＤＩＭエンジン４８に戻される。このように、ＤＩＭエンジン４８から種々のエンジン５０−５６のいずれかの目標エンジンに向かって放射状にデータが送信され、目標エンジンからＤＩＭエンジン４８に戻される。
ラテラル型制御モードの場合、処理されるデータは、エンジン４８、５０−５６の内、任意の２つのエンジン間でデータの送受信がなされる。この場合は、ＤＩＭエンジン４８の負担が軽減されると共に、データ処理の効率を上げることができる。次に説明するように、ラテラル型制御モードによりデータが処理される場合は、記述子のステートメントにおいて、予め決められたメッセージが用いられる。
【００４４】
ラテラル型制御モードについて更に説明する。
【００４５】
（異なるモジュール間でのメッセージ送信）
ＤＩＭエンジン４８は、ＩＳＯ／ＩＥＣ  ２１０００端末／フレームワークの全ての部分（モジュール）と相互作用する必要性がある。ＩＳＯ／ＩＥＣ  ２１０００端末の別の部分との情報交換は、ＭＰＥＧ−２１における汎用ＡＰＩとして定めることができる。情報を交換する唯一の方法は、ＩＳＯ／ＩＥＣ  ２１０００の端末の部分（モジュール）にメッセージを送信することである。
【００４６】
処理エンジンが異なれば、要求する情報も異なる。情報は、ＤＩＤモジュール内部に直接伝送することもできれば、異なるモジュール間で個別に伝送することもできる。例えば、ＩＰＭＰシステムモジュールはＩＰＭＰ情報を要求し、ＲＥＬモジュールは利用規則情報を、ＤＩＡモジュールはＤＩＡ記述情報をそれぞれ要求する。
【００４７】
図１０に示すように、異なるモジュール間で情報交換が必要とされる有益なシナリオがあり、その例として次のようなものが挙げられる。ＤＩＤモジュール５０は、コンテンツを特定した利用権利情報（３．１）をＲＥＬモジュール５３に転送する必要があり、ＲＥＬモジュール５３は当該利用権利を解析し、処理する。ＤＩＡ記述情報は、ＤＩＤモジュール５０からＤＩＡモジュール５５へ転送するよう要求され、当該情報は、ＤＩＤ内の実際に入力されるＤＩＡ記述と実際の端末間のＤＩＡ記述との比較に使用され、デジタルアイテム及び／又はメディア・リソースの適応が行われる。ＤＩＡモジュール５５は、ＤＩＡの突き合わせを行った結果これが一致しない場合は、ＤＩＭエンジン４８を介して「ＧｏＮｏＧｏ」情報（３．２）を含む応答メッセージを送信し、ＤＩＤモジュール５０を中止させる。ＤＩＩ内部のＤＩＩ識別情報（３．３）は、コンテンツを特定した利用権利の識別の持続的な関連付けを行うために、ＲＥＬモジュール５３に送信されることもある。
【００４８】
上記のような場合は、端末、ネットワーク及びユーザの嗜好に関するＤＩＡ記述、ＩＰＭＰツール記述用のＩＰＭＰ情報、コンテンツを特定した利用権利及び利用条件を含むＲＥＬ情報、特定アイテム用のＤＩＩ情報を交換しなければならない。必要な場合は、前記の情報に基づいて交渉が行われる。従って、このような情報を伝送するために、相互動作可能な交渉メカニズム及びメッセージを定義し、ＤＩＤエンジン５０、ＩＰＭＰエンジン５２、ＤＩＡエンジン５５等の異なる処理エンジン間の通信を容易にする必要がある。図１１に示すように、ここに定義するメッセージ構造を持つ交渉メカニズムに従うことにより、ユニバーサル・マルチメディア・アクセス端末を構築することができる。
【００４９】
図１１に示すようにメッセージベースの汎用ＡＰＩが様々な処理モジュール／エンジンを囲んで配置される。端末内の異なるモジュール間の通信は全て、モジュール４．１内のＭｓｇ−ＡＰＩを使用して行われる。
【００５０】
図１１に示すように、まずＤＩＤエンジン５０から、メッセージ（Ｍ１）はＲＥＬエンジン５３へと伝送され、メッセージ（Ｍ２）はＤＩＡエンジン５５へ、メッセージ（Ｍ３）はＥＲエンジン５６へ等、それぞれ伝送される。
【００５１】
ＲＥＬエンジン５３は、ＤＩＤエンジン５０からメッセージ（Ｍ１）を受信すると、これを処理してＩＰＭＰエンジン５２へと伝送し、メッセージ（Ｍ２）をＥＲエンジン５６へと伝送する。
【００５２】
ＩＰＭＰエンジン５２は、ＲＥＬエンジン５３からメッセージ（Ｍ１）を受信すると、これを処理し、ＥＲエンジン５６へと伝送する。
【００５３】
ＥＲエンジン５６は、様々な処理エンジンから全てのメッセージを受信し、イベント又は処理結果をログファイルに書き込む。また、別の処理エンジンにメッセージを送信する必要がある場合もある。
【００５４】
これらの処理エンジン又はモジュールには、図１０及び図１１に示すように、ＤＩＤエンジン５０、ＤＩＩエンジン５１、ＩＰＭＰエンジン５２、ＲＥＬエンジン５３、ＲＤＤエンジン５４、ＤＩＡエンジン５５、及びＥＲエンジン５６が含まれるが、これに限定されず、他のエンジンを含むこともできる。。
【００５５】
上記の設計はデータ主導型、すなわちラテラル型の処理であり、メッセージの伝送を助けるルータ的な主エンジンはない。また、各処理エンジンは、処理されるデータ自身によって呼び出される。
【００５６】
これに対し、ハブ型の設計を図１２に示す。当該設計では、メッセージは全て、様々な処理エンジンから、又は様々な処理エンジンへ、中央処理エンジンであるＤＩＭモジュール４８を介して転送される。
【００５７】
ここに示すＤＩＭエンジンには、この場合、二つの主な機能がある。
【００５８】
１）ＤＩＤエンジン⇔ＤＩＭエンジン⇔ユーザにおける基本動作
ＤＩＤ文書に含まれる、定義されたあらゆる基本動作又は方法を処理し、定義された基本動作又は方法に従ってユーザに提示し、ユーザが入力したユーザの選択肢／選択／嗜好を他の処理エンジンに転送する。
【００５９】
２）処理エンジン⇔ＤＩＭエンジン⇔処理エンジン
メッセージセンターとして、一方の処理エンジンから他方の処理エンジンへのメッセージ転送を支援し、処理エンジンへ送信する又は処理エンジンから受信するメッセージを制御し、各処理エンジンの主導権を握り当該エンジンに対して停止又は開始の機能を適用し、基本動作又は方法が定義されていない場合には処理エンジンとユーザとの間の情報交換を支援する。
【００６０】
図１３に、モジュール６．１のメッセージＡＰＩを備えて構成されたＭＰＥＧ−２１端末にＤＩＤ形式のＤＩＤドキュメント１６（図５に示したものと同じ）が提供された場合を示す。ＤＩＤエンジン５０は、ＤＩＤ文書１６を受信し、そこに含まれる多様な基本動作のメッセージに基づいて当該ＤＩの処理を行う。
【００６１】
ＤＩＭエンジン４８は主エンジンの役割を果たす。まず基本動作を受信して解釈し（ａ）、必要に応じてユーザに提示し（ｂ）、ユーザからの入力を回収し（ｃ）、該当する他の処理エンジン、例えばＤＩＩエンジン５１への送信（ｄ１）、ＲＥＬエンジン５３への送信（ｄ２）、ＩＰＭＰエンジン５２への送信（ｄ３）、ＤＩＡエンジン５５への送信（ｄ４）、ＥＲエンジン５６への送信（ｄ５）、またはその他の、プレーヤー、トランコーダー等の非標準処理エンジン６．４への送信（ｄ６）を行う。図１３に示されていないが、ＲＤＤエンジンも含むように構成してもよい。
【００６２】
情報は、本発明に定めるメッセージＡＰＩを使用して、一方の処理エンジンから他方の処理エンジンへと直接伝送するラテラル型制御モードによることも可能であり、また本発明に定めるメッセージＡＰＩを使用して、ＤＩＭエンジンを介して一方の処理エンジンから他方の処理エンジンへと伝送するハブ型制御モードによることも可能である。後者の場合、ＤＩＭエンジン４８の負担が増えることになるが、中央制御による利点が得られる。
【００６３】
モジュール６．４の処理エンジンは、ビデオプレーヤー、メディア・フォーマット・トランスコーダー等の非標準モジュールでもよい。非標準処理部をカバーするための拡張性は、汎用メッセージＡＰＩの現行の設計でサポートされている。
【００６４】
（汎用内部メッセージ）
本発明で定義する汎用内部メッセージは、ラテラル型制御モードを可能にするため、モジュールからモジュールへ（エンジンからエンジンへ）有益情報を転送することができる。ＤＩＭ（デジタルアイテム方法）処理エンジン４８は、一つの特別な処理エンジンであるとも考えられ、中央処理部として方法／オペレーションを処理することができる。ここで、接続されたモジュールが現在の端末において通信を行うことを可能にする一連の定義された方法又はオペレーションが定義され、存在すると仮定する。ＤＩＤエンジン、ＤＩＩエンジン、ＤＩＡエンジン、ＩＰＭＰエンジン、ＲＥＬ／ＲＤＤエンジン、及びＥＲエンジン等の他の処理エンジンは、それぞれＤＩＭエンジンから伝送された関連情報を処理することができるが、迅速かつ効率的な処理のためには、これらのエンジン間での直接的な情報通信が必要な場合もある。
【００６５】
汎用のＩｎｔｅｒｎａｌＭｅｓｓａｇｅＴｙｐｅのシンタックス及びセマンティクスを以下に示し、また、その構造を図１４に示す。
【００６６】
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="InternalMessage" type="BasicInternalMessageType">
<xs:annotation>
<xs:documentation>messages for information exchanging among modules</xs:documentation>
</xs:annotation>
</xs:element>
<!--#######################################    -->
<!--    Definition of Basic Internal Message                -->
<!--#######################################    -->
<xs:complexType name="BasicInternalMessageType">
<xs:sequence>
<xs:element name="Msg_ID" type="xs:nonNegativeInteger"/>
<xs:element name="SenderModule" type="xs:nonNegativeInteger"/>
<xs:element name="RecipientModule" type="xs:nonNegativeInteger"/>
</xs:sequence>
</xs:complexType>
<!--#######################################    -->
<!--    Definition of  Internal Transmit                         -->
<!--#######################################    -->
<xs:complexType name="TransmitType">
<xs:complexContent>
<xs:extension base="BasicInternalMessageType">
<xs:sequence>
<xs:element name="MessageInformation" type="MessageInformationType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--#######################################    -->
<!--    Definition of  Internal Request                         -->
<!--#######################################    -->
<xs:complexType name="RequestType">
<xs:complexContent>
<xs:extension base="BasicInternalMessageType">
<xs:sequence>
<xs:element name="InformationClass">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="IPMPInformation"/>
<xs:enumeration value="DIAInformation"/>
<xs:enumeration value="DIIInformation"/>
<xs:enumeration value="RightsInformation"/>
<xs:enumeration value="OtherInformation"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--##########################################    -->
<!--    Definition of Internal Response                                 -->
<!--##########################################    -->
<xs:complexType name="ResponseType">
<xs:complexContent>
<xs:extension base="BasicInternalMessageType">
<xs:choice>
<xs:element name="GoNoGo" type="GoNoGoType"/>
<xs:element name="MessageInformation" type="MessageInformationType"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--###################################    -->
<!--    Definition of MessageDescription             -->
<!--###################################    -->
<xs:complexType name="MessageInformationType">
<xs:sequence>
<xs:element name="InformationClass">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="IPMPInformation"/>
<xs:enumeration value="DIAInformation"/>
<xs:enumeration value="DIIInformation"/>
<xs:enumeration value="RightsInformation"/>
<xs:enumeration value="OtherInformation"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="InformationData" type="InformationDataType"/>
</xs:sequence>
</xs:complexType>
<!--##########################################    -->
<!--    Definition of Inner Module Information Data            -->
<!--##########################################    -->
<xs:complexType name="InformationDataType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="mimeType" type="xs:string"/>
</xs:complexType>
<!--##########################################    -->
<!--    Definition of GoNoGo                                -->
<!--##########################################    -->
<xs:complexType name="GoNoGoType">
<xs:simpleContent>
<xs:extension base="xs:boolean">
<xs:attribute name="Info" type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
【００６７】
図７は、ラテラル型制御モードに必要なメッセージ標識の種類が示されている。
（ＩｎｔｅｒｎａｌＭｅｓｓａｇｅスキーマ要素のセマンティクス）
７．１は、ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識を示す。このメッセージ標識は異なるモジュール間で情報を送るためのメッセージ標識である。ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識７．１の基本形は、ＢａｓｉｃＩｎｔｅｒｎａｌＭｅｓｓａｇｅＴｙｐｅ７．２である。ＩｎｔｅｒｎａｌＭｅｓｓａｇｅ標識は、送信用（ＴｒａｎｓｍｉｔＴｙｐｅ）、要請用（ＲｅｑｕｅｓｔＴｙｐｅ）及び応答用（ＲｅｓｐｏｎｓｅＴｙｐｅ）のメッセージ標識に分けることができる。
【００６８】
ＢａｓｉｃＩｎｔｅｒｎａｌＭｅｓｓａｇｅＴｙｐｅ７．２の標識は、内部モジュールの交渉メッセージにおける基本／共通情報を記述するものであり、Ｍｓｇ＿ＩＤ、ＳｅｎｄｅｒＭｏｄｕｌｅ、及びＲｅｃｉｐｉｅｎｔＭｏｄｕｌｅの要素を含む。
【００６９】
Ｍｓｇ＿ＩＤ標識は、メッセージ発信元（一つのモジュール）によって特定され、ひとつのテーマに対し、ひとつのメッセージ識別子が生成され、記述される。あるテーマを持ったメッセージに応答して送信されるメッセージは全て、同じメッセージ識別子が付けられる。
【００７０】
ＳｅｎｄｅｒＭｏｄｕｌｅ標識は、メッセージ発信元のモジュール識別子を記述する。
【００７１】
ＲｅｃｉｐｉｅｎｔＭｏｄｕｌｅ標識は、当該メッセージの受信側とされるモジュール識別子を記述する。
【００７２】
ＴｒａｎｓｍｉｔＴｙｐｅ７．３の標識は、送信する内部交渉メッセージを記述するものであり、ＢａｓｉｃＩｎｔｅｒｎａｌＭｅｓｓａｇｅＴｙｐｅに、ＭｅｓｓａｇｅＩｎｆｏｒｍａｔｉｏｎ７．４が加わったものである。
【００７３】
ＭｅｓｓａｇｅＩｎｆｏｒｍａｔｉｏｎ７．４標識は、モジュール間での伝送及び交換される情報を運ぶためのものであり、ＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ及びＩｎｆｏｒｍａｔｉｏｎＤａｔａを含む。
【００７４】
ＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識は、内部交渉メッセージで伝送される情報のタイプ、すなわち種類を記述する。この「Ｃｌａｓｓ」は、ＲｉｇｈｔｓＩｎｆｏｒｍａｔｉｏｎ、ＩＰＭＰＩｎｆｏｒｍａｔｉｏｎ、ＤＩＡＩｎｆｏｒｍａｔｉｏｎ、ＤＩＩＩｎｆｏｒｍａｔｉｏｎ、及びＯｔｈｅｒＩｎｆｏｒｍａｔｉｏｎのいずれかひとつを特定することができる。これらは異なる内部モジュールによって処理される様々な情報の伝送に使用される。
【００７５】
ＩｎｆｏｒｍａｔｉｏｎＤａｔａ標識は、実際の情報データを、適切に作成されたＸＭＬフラグメントを直接含むメッセージ・ペイロードとして記述する。ＩｎｆｏｒｍａｔｉｏｎＤａｔａ内に含まれる、このようなフラグメントのスキーマは、当該フラグメントのネームスペースによって識別される。
【００７６】
ＲｅｑｕｅｓｔＴｙｐｅ７．５の標識は、要請する内部交渉メッセージを記述するものであり、ＢａｓｉｃＩｎｔｅｒｎａｌＭｅｓｓａｇｅＴｙｐｅに、ＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ標識が加わったものである。ＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓは、ＭｅｓｓａｇｅＩｎｆｏｒｍａｔｉｏｎＴｙｐｅで定義されたものと同一のセマンティクスを有する。
【００７７】
ＲｅｓｐｏｎｓｅＴｙｐｅ７．６の標識は、応答する内部交渉メッセージを記述するものであり、ＢａｓｉｃＩｎｔｅｒｎａｌＭｅｓｓａｇｅＴｙｐｅに、更に、「ＧｏＮｏＧｏ」と「ＭｅｓｓａｇｅＩｎｆｏｒｍａｔｉｏｎ」という二つの要素を含む。「ＧｏＮｏＧｏ」要素は、送られてきた「Ｔｒａｎｓｍｉｔ」（送信）メッセージへの応答に使用され、「ＭｅｓｓａｇｅＩｎｆｏｒｍａｔｉｏｎ」要素は、送られてきた「Ｒｅｑｕｅｓｔ（要請）」メッセージへの応答に使用される。
【００７８】
ＧｏＮｏＧｏ７．７標識は、あるモジュールが、別のモジュールに処理を停止させる場合、又は別のモジュールに処理を行わせる場合に使用される。「Ｔｒｕｅ（真）」はメッセージ送信側がメッセージ受信側に「実行（ｇｏ）」を許可することを示し、「Ｆａｌｓｅ（偽）」は「不許可（ｄｉｓａｌｌｏｗ）」又は「不実行（ｎｏ−ｇｏ）」を示す。
【００７９】
Ｉｎｆｏ標識は、追加情報を伝送するための、「ＧｏＮｏＧｏ」要素のアトリビュートである。
【００８０】
モジュール間通信における、定義された内部メッセージの使用方法の例を以下に示す。以下の例では、ＭＰＥＧ−２１端末内の異なる処理エンジンに異なる整数を割り当て、限られたモジュール間の識別を簡単に表している。例えば、ＤＩＭエンジンは１、ＤＩＤエンジンは２、ＲＥＬエンジンは３、ＩＰＭＰエンジンは４、ＥＲエンジンは５、ＤＩＡエンジンは６の識別番号が割り当てられている。
【００８１】
まず、権利情報の送受信の例を示す。権利情報をＤＩＤモジュール５０からＲＥＬモジュール５３へ直接送信し、ＲＥＬモジュール５３は処理した後、当該情報を返信し、ＤＩＤモジュール５０は、次のステップに進む。
【００８２】
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="TransmitType">
<Msg_ID>001</Msg_ID>
<SenderModule>2</SenderModule>
<RecipientModule>3</RecipientModule>
<MessageInformation>
<InformationClass>RightsInformation</InformationClass>
<InformationData>
<PlayTimes>1</PlayTimes>
</InformationData>
</MessageInformation>
</InternalMessage>
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="ResponseType">
<Msg_ID>001</Msg_ID>
<SenderModule>3</SenderModule>
<RecipientModule>2</RecipientModule>
<GoNoGo>true</GoNoGo>
</InternalMessage>
【００８３】
次に、ＩＰＭＰツール情報の送受信の例を示す。ＩＰＭＰツール情報をＩＰＭＰエンジン５２からＥＲモジュール５６へ直接要請し、ＥＲモジュール５６は当該情報をＩＰＭＰエンジン５２に返信し、ＩＰＭＰエンジン５２は、さらなる処理を行う。
【００８４】
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="RequestType">
<Msg_ID>002</Msg_ID>
<SenderModule>4</SenderModule>
<RecipientModule>5</RecipientModule>
<InformationClass>IPMPInformation</InformationClass>
</InternalMessage>
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="ResponseType">
<Msg_ID>002</Msg_ID>
<SenderModule>5</SenderModule>
<RecipientModule>4</RecipientModule>
<MessageInformation>
<InformationClass>IPMPInformation</InformationClass>
<InformationData>
<IPMPToolList>
<ToolID>11</ToolID>
<ToolID>12</ToolID> 
</IPMPToolList>
</InformationData>
</MessageInformation>
</InternalMessage>
【００８５】
次に、ユーザから受けたユーザ特徴記述の送受信の例を示す。ユーザ特徴記述をＤＩＭエンジン４８からＤＩＡモジュール５５へ送信し、ＤＩＡモジュール５５は、処理した後、ＤＩＡ一致情報を返信してＤＩＭエンジン４８は、次のステップに進む。例えば、続いてＩＰＭＰ情報をＩＰＭＰエンジン５２に送信し、応答メッセージを受信して、ＤＩＭエンジンに「プレーヤー」モジュールを停止するよう通知する。
【００８６】
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="TransmitType">
<Msg_ID>003</Msg_ID>
<SenderModule>1</SenderModule>
<RecipientModule>6</RecipientModule>
<MessageInformation>
<InformationClass>DIAInformation</InformationClass>
<InformationData>
<DisplaySize>QCIF</DisplaySize>
</InformationData>
</MessageInformation>
</InternalMessage>
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="ResponseType">
<Msg_ID>003</Msg_ID>
<SenderModule>6</SenderModule>
<RecipientModule>1</RecipientModule>
<GoNoGo>true</GoNoGo>
</InternalMessage>
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="TransmitType">
<Msg_ID>004</Msg_ID>
<SenderModule>1</SenderModule>
<RecipientModule>4</RecipientModule>
<MessageInformation>
<InformationClass>IPMPInformation</InformationClass>
<InformationData>
<IPMPDescriptor>
<ToolID>13</ToolID>
<ControlPoint>Before</ControlPoint> 
</IPMPDescriptor>
</InformationData>
</MessageInformation>
</InternalMessage>
<InternalMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="InternalMessage.xsd" xsi:type="ResponseType">
<Msg_ID>004</Msg_ID>
<SenderModule>4</SenderModule>
<RecipientModule>1</RecipientModule>
<GoNoGo>false</GoNoGo>
</InternalMessage>
【００８７】
本発明は、その様々な態様から見て、以下のような構成を持つと考えられる。第１の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、
メッセージ構造を有する汎用メッセージＡＰＩを備えた端末を構築するステップと、
デジタルアイテム宣言（ＤＩＤ）エンジンと他の処理エンジンとを統合して前記端末を構築するステップであって、他の処理エンジンとしては、デジタルアイテム方法（ＤＩＭ）エンジン、デジタルアイテム識別（ＤＩＩ）エンジン、権利記述言語（ＲＥＬ）エンジン、権利データ辞書（ＲＤＤ）エンジン、知的財産管理保護（ＩＰＭＰ）エンジン、デジタルアイテム適応（ＤＩＡ）エンジン、イベント報告（ＥＲ）エンジン、及びいかなるプレーヤーとしても特定されないエンジン等が含まれるがこれらに限定されない、ステップと、
ＤＩＤ入力を、ＤＩＤパーサを備えた前記ＤＩＤエンジンで処理するステップと、
前記ＤＩＤ入力の各要素及び前記ＤＩＤ入力に含まれる基本動作を解釈するステップと、
前記基本動作に基づき、ＤＩＭエンジンを使用して、必要に応じて選択肢又は選択をユーザに提示するステップと、
ユーザから値又はパラメータを、あるいはＤＩＤ文書から指定地点を検索するステップと、
前記値又はパラメータを、前記メッセージ構造を使用して、一つの処理エンジンから直接又は中央制御ＤＩＭエンジンを介して特定の処理エンジンへ伝送するステップと、
特定の処理エンジンを呼び出して前記値又はパラメータに基づいて処理を行うステップと、
前記処理結果を、前記メッセージ構造を使用して、さらなる処理のために次の処理エンジンに伝送するステップと、
多様な処理の後、コンテンツ消費を完了するステップとを含む、通信方法である。
【００８８】
第２の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、
異なるベンダーから提供される可能性のある多様なモジュールで端末を形成するステップと、
メッセージ構造を有する汎用メッセージＡＰＩを備えた前記各モジュールを構築し、前記モジュールが前記メッセージＡＰＩに基づいて行われる通信を理解できるようにするステップと、
値、パラメータ、又はステータス等の情報を、前記メッセージＡＰＩを使用して一方のモジュールから他方のモジュールへ伝送するステップと、
前記伝送に対して処理結果又は関連情報を返信し、前記通信を完了するステップとを含む、通信方法である。
【００８９】
第３の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、
異なるベンダーから提供される可能性のある多様なモジュールで端末を形成するステップと、
メッセージ構造を有する汎用メッセージＡＰＩを備えた前記各モジュールを構築し、前記モジュールが前記メッセージＡＰＩに基づいて行われる通信を理解できるようにするステップと、
値、パラメータ、又はステータス等の情報を、前記メッセージＡＰＩを使用して一方のモジュールから他方のモジュールへ要請するステップと、
前記要請メッセージに対して要請された実際の情報を返信し、前記通信を完了するステップとを含む、通信方法である。
【００９０】
第４の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、請求項１、２及び３に記載のメッセージ構造が、
伝送、要請、応答、及び／又は第３の部分が定める他のメッセージタイプ等の多様なタイプのメッセージによって拡張可能な汎用メッセージ構造を含むステップと、
多様なタイプのメッセージによって伝送されるメッセージ情報を含むステップとを更に含む、通信方法である。
【００９１】
第５の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、請求項４に記載の汎用メッセージ構造が、
前記メッセージ構造において、各メッセージにメッセージＩＤを割り当て、応答メッセージも同一のＩＤを使用して当該メッセージに応答できるようにするステップと、
前記メッセージ構造において、処理モジュールの名前又は割り当てられた内部モジュール番号を送信側又は受信側として使用し、メッセージの発信元又は送信先のモジュールを示すステップとを更に含む、通信方法である。
【００９２】
第６の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、請求項４に記載のメッセージ情報本体が、伝送メッセージを使用して、当該情報を特定の処理エンジンに伝える又は当該情報を一方のモジュールから他方のモジュールに伝送する状況において、
情報の種類を、ＲｉｇｈｔｓＩｎｆｏｒｍａｔｉｏｎ、ＩＰＭＰＩｎｆｏｒｍａｔｉｏｎ、ＤＩＡＩｎｆｏｒｍａｔｉｏｎ、ＤＩＩＩｎｆｏｒｍａｔｉｏｎ、及びＯｔｈｅｒＩｎｆｏｒｍａｔｉｏｎの列挙で記述するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓを含むステップと、
前記値、パラメータ、又はステータス等の実際の情報データを、適切に作成されたＸＭＬフラグメントを直接含むメッセージ・ペイロードとして記述するＩｎｆｏｒｍａｔｉｏｎＤａｔａを含むステップとを更に含む、通信方法である。
【００９３】
第７の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、請求項４に記載のメッセージ情報本体が、請求項６に記載の伝送メッセージに対し応答メッセージを使用して応答する状況において、
「ＧｏＮｏＧｏ」要素を用いて他方のモジュールに処理を中止させる、又は他方のモジュールに処理を行わせるための前記処理結果を含むステップと、
いくつかの追加的な結果情報を伝える「Ｉｎｆｏ」要素を含むステップとを更に含む、通信方法である。
【００９４】
第８の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、請求項４に記載のメッセージ情報本体が、要請メッセージを用いて他方のモジュール又は処理エンジンから当該情報を入手する状況において、要請された情報の種類を、ＲｉｇｈｔｓＩｎｆｏｒｍａｔｉｏｎ、ＩＰＭＰＩｎｆｏｒｍａｔｉｏｎ、ＤＩＡＩｎｆｏｒｍａｔｉｏｎ、ＤＩＩＩｎｆｏｒｍａｔｉｏｎ、及びＯｔｈｅｒＩｎｆｏｒｍａｔｉｏｎの列挙で記述するＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓを更に含む、通信方法である。
【００９５】
第９の構成によると、本発明は、ユニバーサル・マルチメディア・アクセス・フレームワークにおける多様な処理モジュール間の通信方法であって、請求項４に記載のメッセージ情報本体が、応答メッセージを用いて請求項８に記載の当該要請メッセージに応答する状況において、
要請された情報の種類を、ＲｉｇｈｔｓＩｎｆｏｒｍａｔｉｏｎ、ＩＰＭＰＩｎｆｏｒｍａｔｉｏｎ、ＤＩＡＩｎｆｏｒｍａｔｉｏｎ、ＤＩＩＩｎｆｏｒｍａｔｉｏｎ、及びＯｔｈｅｒＩｎｆｏｒｍａｔｉｏｎの列挙で記述する、ＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓを含むステップと、
前記値、パラメータ、又はステータス等の要請された実際の情報データを、適切に作成されたＸＭＬフラグメントを直接含むメッセージ・ペイロードとして記述する、ＩｎｆｏｒｍａｔｉｏｎＤａｔａを含むステップとを更に含む、通信方法である。
【産業上の利用可能性】
【００９６】
本発明は、デジタルアイテムの処理方法および装置に利用可能である。
【図面の簡単な説明】
【００９７】
【図１】ＩＰＭＰ保護記述子及びＤＩＡ記述子が含まれるＤＩＤドキュメントの階層を示す図である。
【図２】ハブ型制御モードのみを有するデコーダの動作説明を示す図である。
【図３】デジタルアイテム（ＤＩ）が、サーバからユーザに配信される様子を説明する図である。
【図４】デジタルアイテムの送受信処理を示すフロー図である。
【図５】ＤＩＤ形式で記述されたデジタルアイテムのヘッド部に対応するＤＩＤドキュメントを示す図である。
【図６】ＭＰＥＧ−２１端末のシステムの構成を示すブロック図である。
【図７】ＤＩＤドキュメントを受け取ったときにＭＰＥＧ−２１端末が行う処理のフロー図である。
【図８】ＤＩＭプレゼンタが複数の準備処理を行うときの処理を示すフロー図である。
【図９】ＤＩＭプレゼンタが行うＤＩＡ適合処理のフロー図である。
【図１０】ＭＰＥＧ−２１端末内におけるモジュール間でのメッセージ転送を示す図である。
【図１１】処理エンジン間での直接メッセージ転送を行うためにＭＰＥＧ−２１端末内に構築された、汎用ＡＰＩとしてのメッセージを示す図である。
【図１２】ＭＰＥＧ−２１端末内における、ＤＩＭエンジンを介したメッセージ転送を示す図である。
【図１３】メッセージＡＰＩを備えたＭＰＥＧ−２１端末内における、処理エンジンを有するＤＩＭエンジン機能の詳細を示す図である。
【図１４】ＭＰＥＧ−２１端末内の異なるモジュール間で伝送されるメッセージング・インフラストラクチャを示す図である。
【図１】
2005012777.tif 000003
【図２】
2005012777.tif 000004
【図３】
2005012777.tif 000005
【図４】
2005012777.tif 000006
【図５】
2005012777.tif 000007
【図６】
2005012777.tif 000008
【図７】
2005012777.tif 000009
【図８】
2005012777.tif 000010
【図９】
2005012777.tif 000011
【図１０】
2005012777.tif 000012
【図１１】
2005012777.tif 000013
【図１２】
2005012777.tif 000014
【図１３】
2005012777.tif 000015
【図１４】
2005012777.tif 000016