(57)【要約】【解決手段】リソース伝送方法及び情報提供方法を提供する。デジタル著作権管理（ＤＲＭ）相互運用システムにおいて、リソース伝送方法は、少なくとも二つのハンドラを用いることによって伝送セッションでリソースを伝送する段階と、伝送セッションの識別情報及びリソースの伝送状態を表す情報を含むイベントメッセージをハンドラから受信する段階と、を有する。この場合、リソースの伝送状態を表す情報は、リソースを識別できるリソースインデックスと、前記リソースインデックスに対応するリソースの伝送状態情報と、を含む。したがって、リソースの伝送に関連した情報をイベント形態で容易に提供することができる。
2010510568.tif 000002
【特許請求の範囲】
【請求項１】
デジタル著作権管理（ＤＲＭ）相互運用システムでリソースを伝送するリソース伝送方法であって、
少なくとも二つのハンドラを用いることによって伝送セッションでリソースを伝送する段階と、
前記伝送セッションの識別情報及び前記リソースの伝送状態を表す情報を含むイベントメッセージを前記ハンドラから受信する段階と、を有し、
前記リソースの伝送状態を表す情報は、
リソースを識別できるリソースインデックスと、
前記リソースインデックスに対応するリソースの伝送状態情報と、を含むことを特徴とするリソース伝送方法。
【請求項２】
前記リソースは、少なくとも一つであり、前記イベントメッセージは、前記リソースの伝送状態を表す情報を少なくとも一つ含む請求項１に記載のリソース伝送方法。
【請求項３】
前記リソースを伝送する段階は、
前記リソースを送信先に伝送することを要求するメッセージを受信する段階と、
前記伝送を実行するために前記少なくとも二つのハンドラを含むチェーンを形成する段階と、
前記ハンドラの動作を要求するメッセージを前記ハンドラに伝送し及び前記伝送セッションでの前記リソースの伝送を許可する段階と、を有する請求項１に記載のリソース伝送方法。
【請求項４】
前記リソースを送信先に伝送することを要求する前記メッセージは、
前記伝送セッションを識別することができる伝送セッション情報と、
前記リソースを伝送する送信元を表す送信元情報と、
前記リソースが伝送される前記送信先を表す送信先情報と、を含む請求項３に記載のリソース伝送方法。
【請求項５】
前記少なくとも二つのハンドラは、
伝送要求されたリソースをエクスポートするリソースエクスポータと、
前記リソースエクスポータから伝送されるリソースを受信するリソースインポータと、を有する請求項３に記載のリソース伝送方法。
【請求項６】
前記少なくとも二つのハンドラは、
伝送要求されたリソースをエクスポートするリソースエクスポータと、
前記リソースエクスポータから伝送されたソースを前記送信先で要求するリソースフォーマットに変換し、変換されたリソースを伝送するリソーストランスフォーマと、
前記リソーストランスフォーマから伝送されたリソースを受信するリソースインポータと、を有する請求項３に記載のリソース伝送方法。
【請求項７】
前記リソースを送信先に伝送することを要求するメッセージはクライアントから受信され、
前記イベントメッセージの受信に応答してイベントメッセージを前記クライアントに伝送する段階を更に有する請求項３に記載のリソース伝送方法。
【請求項８】
前記イベントメッセージを受信することができるイベントのサブスクライブを前記ハンドラに要求することによって前記イベントにサブスクライブする段階を更に有する請求項１に記載のリソース伝送方法。
【請求項９】
複数のハンドラから情報を収集する段階と、
収集した情報に従って、要求された伝送を実行するか否か決定する段階と、を更に有する請求項１に記載のリソース伝送方法。
【請求項１０】
伝送セッションの識別情報及び少なくとも一つのリソースを識別することができる情報を含むメッセージを制御エンティティから受信する段階と、
受信した前記メッセージにより指定された受信エンティティを用いることによってセキュリティ認証チャネル（ＳＡＣ）を確立する段階と、
確立されたＳＡＣを介して前記少なくとも一つのリソースを伝送する段階と、
前記伝送セッションの識別情報及び前記リソースの伝送状態を表す情報を含むイベントメッセージを前記制御エンティティに伝送する段階と、を有することを特徴とする情報提供方法。
【請求項１１】
前記受信したメッセージは、リソースエクスポート要求メッセージ、リソース変換要求メッセージ及びリソースインポート要求メッセージのうちの少なくとも一つである請求項１０に記載の情報提供方法。
【請求項１２】
前記イベントメッセージを受信することができる特定イベントのサブスクリプションを要求する要求メッセージを制御エンティティから受信する段階と、
前記要求の有効性を決定し、前記要求が有効である場合、前記イベントのサブスクリプションが許可されていることを表す応答メッセージを前記制御エンティティに伝送する段階と、を更に有する請求項１０に記載の情報提供方法。
【請求項１３】
所定のイベントメッセージを受信することができるイベントのサブスクリプションを要求する要求メッセージを特定のエンティティから受信する段階と、
前記要求の有効性を決定し、前記要求が有効である場合、前記イベントのサブスクリプションが許可されていることを表す応答メッセージを前記制御エンティティに伝送する段階と、
前記イベントメッセージを前記特定のエンティティに伝送する段階と、を有し、
前記イベントメッセージは、各リソースの伝送状態の情報を含むリソース伝送状態イベントメッセージとニュートラルライセンスの更新されたコンテンツを含む更新ライセンスイベントメッセージのうちのいずれか一方であることを特徴とする情報提供方法。
【請求項１４】
前記イベントメッセージが前記ライセンスイベントメッセージであるとき、前記イベントメッセージは前記ニュートラルライセンスを含み、前記ニュートラルライセンスは、前記ニュートラルライセンスの変更部分を表す変更フィールド情報及び前記変更フィールド情報によって表された部分がどのように変更されたかを表す変更状態情報を含む請求項１３に記載の情報提供方法。
【請求項１５】
前記応答メッセージは、固有のサブスクリプション識別子を含む請求項１４に記載の情報提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース伝送方法及び情報提供方法に関する。更に詳しくは、本発明は、デジタル著作権管理（ＤＲＭ）相互運用環境でイベントを介して情報を容易に提供できる技術に関連したデータの伝送方法及び情報提供方法に関する。
【背景技術】
【０００２】
一般に、デジタル著作権管理（ＤＲＭ）は、デジタルリソースの違法コピー及び使用を未然に防止して適法な権限を有したユーザだけがデジタルリソースを使用することができるようにする一般的なリソース保護技術である。ＤＲＭは、デジタルリソースの生産及び分配の間中に総合的な保護体系を提供する。例えば、ＤＲＭは、暗号化技術を用いることによってデジタルリソースをパケット形態に暗号化されたデータに変換され、適法な認証手続きを経ることなくデジタルリソースを使用できないようにする。
【０００３】
多様なリソースサービスモデルと情報をやり取りすることによって、ＤＲＭは、信頼性があり、かつ、合法的なリソースサービスの基盤となっている。現在、実際には、サービスプロバイダは、それ自体のリソースを保護するために固有のＤＲＭを使用する。例えば、オンライン通信を介して音源を提供する音源サービスの場合、音源は、違法コピーを防止するために特定の暗号化パターンで暗号化され、したがって、音源を、対応するサービスプロバイダによって提供されたアプリケーションの使用によってのみ再生することができる。
【０００４】
しかしながら、ＤＲの技術的又はポリティカルな閉鎖性のために、相互運用は、異なるＤＲＭ間では一般的に不可能である。したがって、あるサービスプロバイダによって提供されるリソースを、他のサービスプロバイダによって提供されるアプリケーションによって使用することができない。これは、ＤＲＭリソースの汎用的な使用を実際に制限することによって合法的なコンテンツの市場の展開を妨げる重大な問題として指摘されている。
【０００５】
最近、上記問題に対処するために、閉鎖的なＤＲＭ構造が互いに適合するフレームワークを提供しようとする努力があり、その代表的な例がＤＲＭ相互運用システムである。ＤＲＭ相互運用システムを、リソース又はライセンスを交換して使用できるようにするために異なるＤＲＭを中間で制御するシステムとすることができる。
【０００６】
ＤＲＭ相互運用システムは、システムリソースを定義し、定義されたシステムリソースを生成及び管理する動作モデルを形成することによって実現される。特に、ＤＲＭ相互運用システムの実現の重大な要因が信頼性のあるクライアントの認証及び管理、効率的なリソース及びライセンスの伝送並びに効率的な情報管理を含むと考えられる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、ＤＲＭ相互運用環境において複数のリソースを単一の伝送セッションを用いて伝送し、各リソースの伝送状態をイベントを介して受けることができるリソース伝送方法を提供する。
【０００８】
本発明は、ＤＲＭ相互運用環境において複数のリソースを伝送するときに所定のイベントを介して各リソースの伝送状態の情報を提供することができる情報提供方法も提供する。
【０００９】
本発明は、リソース又はライセンスに関連した情報をイベントを介して特定のエンティティに提供することができる情報提供方法を提供することである。
【課題を解決するための手段】
【００１０】
本発明の一態様によれば、デジタル著作権管理（ＤＲＭ）相互運用システムでリソースを伝送するリソース伝送方法を提供する。リソース伝送方法は、少なくとも二つのハンドラを用いることによって伝送セッションでリソースを伝送する段階と、前記伝送セッションの識別情報及び前記リソースの伝送状態を表す情報を含むイベントメッセージを前記ハンドラから受信する段階と、を有する。この場合、前記リソースの伝送状態を表す情報は、リソースを識別できるリソースインデックスと、前記リソースインデックスに対応するリソースの伝送状態情報と、を含むことができる。また、前記リソースは、少なくとも一つとすることができ、前記イベントメッセージは、前記リソースの伝送状態を表す情報を少なくとも一つ含むことができる。
【００１１】
また、前記リソースを伝送する段階は、前記リソースを送信先に伝送することを要求するメッセージを受信する段階と、前記伝送を実行するために前記少なくとも二つのハンドラを含むチェーンを形成する段階と、前記ハンドラの動作を要求するメッセージを前記ハンドラに伝送し及び前記伝送セッションでの前記リソースの伝送を許可する段階と、を有することができる。
【００１２】
また、前記リソースを送信先に伝送することを要求する前記メッセージは、前記伝送セッションを識別することができる伝送セッション情報と、前記リソースを伝送する送信元を表す送信元情報と、前記リソースが伝送される前記送信先を表す送信先情報と、を含むことができる。
【００１３】
また、前記少なくとも二つのハンドラは、伝送要求されたリソースをエクスポートするリソースエクスポータと、前記リソースエクスポータから伝送されるリソースを受信するリソースインポータと、を有することができる。また、前記少なくとも二つのハンドラは、伝送要求されたリソースをエクスポートするリソースエクスポータと、前記リソースエクスポータから伝送されたソースを前記送信先で要求するリソースフォーマットに変換し、変換されたリソースを伝送するリソーストランスフォーマと、前記リソーストランスフォーマから伝送されたリソースを受信するリソースインポータと、を有することができる。
【００１４】
また、前記リソースを送信先に伝送することを要求するメッセージはクライアントから受信される。この場合、リソース伝送方法は、前記イベントメッセージの受信に応答してイベントメッセージを前記クライアントに伝送する段階を更に有することができる。
【００１５】
また、リソース伝送方法は、前記イベントメッセージを受信することができるイベントのサブスクライブを前記ハンドラに要求することによって前記イベントにサブスクライブする段階を更に有することができる。また、リソース伝送方法は、複数のハンドラから情報を収集する段階と、収集した情報に従って、要求された伝送を実行するか否か決定する段階と、を更に有することができる。
【００１６】
一方、本発明の他の態様によれば、情報提供方法を提供する。情報提供方法は、伝送セッションの識別情報及び少なくとも一つのリソースを識別することができる情報を含むメッセージを制御エンティティから受信する段階と、受信した前記メッセージにより指定された受信エンティティを用いることによってセキュリティ認証チャネル（ＳＡＣ）を確立する段階と、確立されたＳＡＣを介して前記少なくとも一つのリソースを伝送する段階と、前記伝送セッションの識別情報及び前記リソースの伝送状態を表す情報を含むイベントメッセージを前記制御エンティティに伝送する段階と、を有することができる。また、前記受信したメッセージは、リソースエクスポート要求メッセージ、リソース変換要求メッセージ及びリソースインポート要求メッセージのうちの少なくとも一つであることができる。
【００１７】
また、情報提供方法は、前記イベントメッセージを受信することができる特定イベントのサブスクリプションを要求する要求メッセージを制御エンティティから受信する段階と、前記要求の有効性を決定し、前記要求が有効である場合、前記イベントのサブスクリプションが許可されていることを表す応答メッセージを前記制御エンティティに伝送する段階と、を更に有することができる。
【００１８】
本発明の他の態様によれば、情報提供方法を提供する。情報提供方法は、所定のイベントメッセージを受信することができるイベントのサブスクリプションを要求する要求メッセージを特定のエンティティから受信する段階と、前記要求の有効性を決定し、前記要求が有効である場合、前記イベントのサブスクリプションが許可されていることを表す応答メッセージを前記制御エンティティに伝送する段階と、前記イベントメッセージを前記特定のエンティティに伝送する段階と、を有することができる。この場合、前記イベントメッセージは、各リソースの伝送状態の情報を含むリソース伝送状態イベントメッセージとニュートラルライセンスの更新されたコンテンツを含む更新ライセンスイベントメッセージのうちのいずれか一方とすることができる。
【００１９】
また、前記イベントメッセージが前記ライセンスイベントメッセージであるとき、前記イベントメッセージは前記ニュートラルライセンスを含み、前記ニュートラルライセンスは、前記ニュートラルライセンスの変更部分を表す変更フィールド情報及び前記変更フィールド情報によって表された部分がどのように変更されたかを表す変更状態情報を含むことができる。また、前記応答メッセージは、固有のサブスクリプション識別子を含むことができる。
【発明の効果】
【００２０】
本発明によれば、複数のリソースをデジタル著作権管理（ＤＲＭ）相互運用環境において単一の伝送セッションを用いて伝送するとき、各リソースの伝送状態の情報を特定のイベント形式で提供することができる。特に、各リソースの伝送状態の情報を一つのイベントメッセージを用いることによって提供することができるので、情報を更に効率的に提供することができる。また、ニュートラルライセンスの更新イベントが生じたとき、ニュートラルライセンスどこでどのように変更されたかを表す情報を提供することができ、これによって、ライセンス管理の便宜性を向上することができる。
【発明を実施するための最良の形態】
【００２１】
本発明の好適な実施の形態を、本発明を当業者によって容易に実施できるように添付図面を参照して以下で説明する。図示した本発明の好適な実施の形態を説明するに当り、明瞭のために特定の技術用語を用いる。しかしながら、本発明は、そのように選択された特定の用語に限定されることを意図するものではなく、特定の用語の各々は、同様の目的を達成するために同様の方法で動作するステップ又はアイテムに対する全ての技術的に等価な用語を含む。
【００２２】
図１は、異なる種類のＤＲＭが互いに適合されるＤＲＭ相互運用システムの概略的な構成を示すブロック図である。
【００２３】
図１に示すように、ＤＲＭ相互運用システムは、クライアント部１０、認証及び管理部２０、処理制御部４０、コンテンツ処理部５０及びライセンス処理部３０を有することができる。
【００２４】
上述した各部を、少なくとも一つ以上のエンティティで構成することができる。このとき、エンティティは、所定の固有の機能を実行するソフトウェア又はハードウェアとして構成されたモジュール又はデバイスを表すことができる。各エンティティを、所定の単位機能を実行する一つ以上の単位機能モジュールの集合とすることができる。エンティティは、所定のインタフェースを介して他のエンティティとデータ通信を行うために所定の装置にインストールされる。また、エンティティが同一部に属するとしても、エンティティを、異なるデバイスにインストールし又は具現することができる。デバイスは、実行環境に従って異なることができる。
【００２５】
クライアント部１０はクライアントを有することができる。クライアントは、ユーザが認証及び管理部２０並びに処理制御部４０と連携してＤＲＭ相互運用サービスを利用できるように各種機能を提供するエンティティである。クライアントを、ユーザのデバイスに含めることができる。クライアントを有するデバイスは、クライアントデバイスと称される。
【００２６】
クライアントは、認証及び管理部２０にクライアント認証を要求することができる。認証されたクライアントは、処理制御部４０の所定のエンティティを呼び出すことによってデータ（例えば、リソース又はライセンス）を所望の送信先に伝送するよう処理制御部４０に要求することができる。また、クライアントは、クライアントの典型的な機能、例えば、リソースを使用(又は再生)する機能、ユーザインターフェース機能等を有することができる。この場合、クライアントは、リソース消費の終点となることができる。
【００２７】
認証及び管理部２０の主要機能は、クライアントを認証し及び認証情報を管理することである。この機能を容易にするために、認証及び管理部２０はドメインの概念を用いることができる。
【００２８】
ドメインは、ＤＲＭ信頼体系の基本単位であり、ＤＲＭ相互運用システムが実質的に適用される範囲を表すことができる。ドメインを、許可されたデバイス又はシステムの集合で構成することができる。例えば、ドメインは、許可されたクライアントデバイスの集合を含むことができる。この場合、ドメインのクライアントデバイスが異なるＤＲＭリソースを有するとしても、クライアントデバイスは、リソースを互いに共有することができる。
【００２９】
図２は、ドメインと、ドメインを構成するエンティティ及びエンティティ間の相関関係を示すブロック図である。図２の説明は、クライアントの認証及び管理に関連するエンティティに焦点を合わせる。
【００３０】
図２を参照すると、ＤＲＭ相互運用システムは、ドメイン５を形成する。ドメイン５を、クライアント３がインストールされたクライアントデバイス１２の物理的な位置を考慮して構成することができる。例えば、ドメインは、特定の物理領域に存在する許可されたクライアントデバイス１２によって構成される。一方、ドメインを、クライアントデバイス１２の物理的な位置を考慮することなく論理的に認証されたクライアントデバイスのみで構成することができる。
【００３１】
本説明において、これまで説明したように、クライアントデバイス１２の物理的な位置を考慮しながら所定のローカルエリアのクライアントデバイス１２によってドメインを構成し、ネットワークエリアの所定のローカルエリア外のクライアントデバイスもドメインに加入することができる。しかしながら、これは実施の形態の一例である。本発明は、それに限定されない。
【００３２】
ドメイン５を構成するためにローカル環境が要求される。このとき、ローカル環境は、所定のローカルエリアのデバイスが互いにインタラクティブとなるように物理的なネットワークが用意された環境を表し、物理的なネットワークは、外部のネットワークとインタラクティブである。例えば、ローカル環境をホームネットワークシステムとすることができる。
【００３３】
以下説明するローカルエリアネットワークは、ローカル環境が形成された領域であると仮定する。例えば、ローカルエリアを、ホームネットワークシステムを搭載したユーザの家、少なくとも二つのデバイスをローカルネットワーキングを通じて接続することができる場所等とすることができる。さらに、ネットワークエリアは、有線／無線インターネットのようなワイドエリアネットワーク（ＷＡＮ）の領域と仮定する。
【００３４】
図２に示すように、クライアント３を認証し及び管理する認証及び管理部２０は、ドメインマネージャ２２、ライセンスマネージャ２４及びレファレンスポイントコントローラ２６を有することができる。
【００３５】
ドメインマネージャ２２は、ドメイン５を管理する機能を実行するエンティティである。例えば、ドメインマネージャ２２は、種々の機能、例えば、ドメイン５を生成する機能、ドメイン５を破棄する機能、クライアントをドメイン５に関連付ける機能、クライアントをドメイン５から除去する機能、レファレンスポイントコントローラ２６を登録する機能を実行することができる。
【００３６】
ドメインマネージャ２２は、ローカルエリア又はネットワークエリアのあらゆる位置に存在することができる。例えば、図２に示す例において、ドメインマネージャ２２は、ネットワークエリアに配置される。この場合、ドメインマネージャ２２は、インターネット等を介してレファレンスポイントコントローラ２６及びクライアント３と対話することができる。一方、ドメインマネージャ２２をローカルエリアに配置することができる。この場合、ドメインマネージャ２２は、ローカルエリアのデバイスに含まれる。
【００３７】
ライセンスマネージャ２４は、ユーザのライセンス情報を管理する。例えば、ライセンスマネージャ２４は、ユーザのためのログイン機能を提供し、ライセンス情報を格納及び管理する典型的なオンラインサービスマネージャの機能を実行することができる。ライセンスマネージャ２４は、ユーザ名を生成する機能、ユーザ名を削除する機能、ライセンス情報をユーザ名に関連付ける機能、ライセンス情報を生成する機能、ライセンス情報を削除する機能等を実行することができる。
【００３８】
ライセンスマネージャ２４を、ネットワークエリア、例えば、サービスプロバイダ側に配置することができる。しかしながら、ライセンスマネージャ２４の位置は、ネットワークエリアに限定されない。したがって、ライセンスマネージャ２４はローカルエリアに存在することができる。すなわち、ドメインマネージャ２２及びライセンスマネージャ２４を、ローカルエリア又はネットワークエリアのあらゆる位置に配置することができる。
【００３９】
レファレンスポイントコントローラ２６は、所定のエンティティ（例えば、クライアント）がローカルエリアに存在するか否かを確認し、エンティティがローカルエリアに配置されていることを検証するクレデンシャルを、検証されたエンティティに提供する。この機能のために、レファレンスポイントコントローラ２６は、ローカルエリアの範囲を決定することができる。ローカルエリアの範囲を、物理的な距離、ホップ数、反応時間等を用いることによって決定することができる。
【００４０】
レファレンスポイントコントローラ２６は、クライアント３がローカルエリアに配置されているか否かをクライアント３の要求に従って確認する。クライアント３がローカルエリアに適切に存在することが確認されると、リファレンスポイントコントローラ２６は、クライアント３がローカルエリアに配置されていることを検証するドメインクレデンシャルを提供することができる。ドメインクレデンシャルを、クライアント３がクライアント３の認証をドメインマネージャ２２に要求するときにドメインマネージャ２２に提供することができる。ドメインマネージャ２２は、受け取ったドメインクレデンシャルを読み出し、クライアント３がローカルエリアに適切に配置されていることを確認する。その後、ドメインマネージャ２２はクライアント３を認証することができる。当然、そのような方法に加えて、クライアント３を、典型的なユーザ情報又は認証を受け取ることによってドメインマネージャ２２により認証することができる。
【００４１】
レファレンスポイントコントローラ２６をローカルエリアに配置することができる。すなわち、レファレンスポイントコントローラ２６を、ローカルエリアに存在するデバイスに含むことができる。また、レファレンスポイントコントローラ２６を、ドメインが最初に構成されるときに所定のプロセスにより選択することができる。例えば、レファレンスポイントコントローラ２６を、ドメインマネージャ２２によって指定することができ、又はローカルエリアに存在するデバイス間でメッセージのやり取りを行うことによって自動的に選択することができる。
【００４２】
一方、処理制御部４０は、ドメイン５に認証されたクライアント３は、データ（すなわち、リソース又はライセンス）の伝送を処理制御部４０に要求し、処理制御部４０は、要求されたデータを伝送できるようにリソース処理部５０又はライセンス処理部３０を制御する。
【００４３】
図３は、リソースの伝送に用いられる処理制御部４０及びリソース処理部５０の詳細な構成を示すブロック図である。リソース伝送プロセスに関与するエンティティを図３に示す。
【００４４】
図３を参照すると、処理制御部４０は、リソース処理コントローラ４１及びライセンス処理コントローラ４２を有する。ライセンス処理コントローラ４２がリソースの伝送に関連しないので、詳細な説明を後に行う。
【００４５】
リソース処理コントローラ４１は、一つ以上のリソースを特定の送信先に伝送する要求をクライアント３から受け取る。リソース処理コントローラ４１は、受け取ったリソース伝送要求に従ってリソースを伝送するようリソース処理部５０を制御する。コンテンツ処理コントローラ４１は、ローカルエリア又はネットワークエリアのあらゆる場所に存在することができ、好適には、ローカルエリア内に存在するデバイスに存在する。
【００４６】
リソース処理部５０は、リソース処理コントローラ４１の制御の下でリソースを送信元から送信先に伝送する。リソース処理部５０は、複数のリソースハンドラを有する。リソースハンドラは、リソースの伝送及び処理に関連した機能を実行するエンティティを有することができる。リソースハンドラは、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３を有する。
【００４７】
リソースエクスポータ５２は、リソース処理コントローラ４１によって伝送するよう要求されたコンテンツをエクスポートし及びエクスポートされたリソースをニュートラルリソースの形態でリソーストランスフォーマ５１又はリソースインポータ５３に伝送する機能を実行することができる。ニュートラルリソースを、所定のＤＲＭを用いることによって暗号化されないクリーンリソースとすることができる。リソース処理コントローラ４１によって要求されたリソースを、所定のＤＲＭを用いることによって暗号化されたリソースとすることができる。リソースエクスポータ５２は、要求されたリソースを送信元から取り出し、リソースをニュートラルリソースに変換し、結果的に得られたリソースを伝送する。また、リソースエクスポータ５２は、送信元で解読されたニュートラルリソースを受信し、受信したニュートラルリソースを伝送することもできる。
【００４８】
リソーストランスフォーマ５１は、リソースエクスポータ５２から伝送されたニュートラルリソースを受信し、受信したニュートラルリソースを、要求されたフォーマットを有する信号に変換し、信号をリソースインポータ５３に伝送する。要求されたフォーマットを、送信先で要求されるフォーマットとすることができる。リソーストランスフォーマ５１は、ニュートラルリソースのフォーマット変換が必要なときだけ伝送に関与する。
【００４９】
リソースインポータ５３は、リソーストランスフォーマ５１又はリソースエクスポータ５２から伝送されたニュートラルリソースを受信し、受信したニュートラルコンテンツを送信先に提供する。この場合、リソースインポータ５３は、受信したニュートラルリソースを、暗号化することなく又は送信先に適用されるＤＲＭに適切なフォーマットを有するようにニュートラルリソースを暗号化した後に、送信先に提供することができる。前者の場合、送信先は、ニュートラルリソースがリソースインポータ５３に適用されるＤＲＭに適合するようそれ自体の機能を用いることによってニュートラルリソースを暗号化した後に、リソースインポータ５３から提供されたニュートラルリソースを用いることができる。後者の場合、ニュートラルリソースがリソースインポータ５３によって暗号化された状態で提供されるので、リソースインポータ５３は、暗号化することなくニュートラルリソースを用いることができる。
【００５０】
図４は、リソース処理コントローラ４１及びリソースハンドラ５１〜５３の配置の例を説明するブロック図である。
【００５１】
図４に示すように、リソースエクスポータ５２を要求デバイスＤＶ１に含むことができ、リソースインポータ５３を送信先デバイスＤＶ２に含むことができる。また、リソース処理コントローラ４１又はリソーストランスフォーマ５１を、要求デバイスＤＶ１及び送信先デバイスＤＶ２とは異なる他のデバイスに含むことができる。
【００５２】
要求デバイスＤＶ１を、リソースの伝送を要求するクライアントデバイスとすることができる。要求デバイスＤＶ１は、リソースの伝送を要求する要求クライアントＲＣ１を有することができる。特定のＤＲＭを要求デバイスＤＶ１にインストールすることができる。要求デバイスＤＶ１に格納されたリソースを伝送しようとするとき、要求デバイスＤＶ１は送信先としての役割を果たす。
【００５３】
送信先デバイスＤＶ２を、要求クライアントＲＣ１によって伝送要求されたリソースが伝送される送信先（例えば、クライアントデバイス又は特定のシステム）とすることができる。送信先デバイスＤＶ２は、送信先クライアントＲＣ２を有することができる。送信先ＤＲＭを送信先デバイスＤＶ２にインストールすることができる。送信先ＤＲＭは、要求デバイスＤＶ１に設けられたＤＲＭと同一であっても異なってもよい。
【００５４】
リソース処理コントローラ４１及びリソースハンドラ５１〜５３の配置を、例示のためにだけ図４に示す。したがって、リソース処理コントローラ４１及びリソースハンドラ５１〜５３を同一デバイスに含むことができ、これらの素子の一部を同一デバイスに含むことができ、又はこれらの素子の全てをそれぞれ別個のデバイスに含むことができる。例えば、リソース処理コントローラ４１を要求デバイスＤＶ１又は送信先デバイスＤＶ２に含むことができ、又は、リソーストランスフォーマ５１及びリソース処理コントローラ４１を同一デバイスに含むことができる。
【００５５】
このように、リソース処理コントローラ４１、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３は、位置的に特定のデバイスに限定されず、種々の位置に配置される。しかしながら、好適には、セキュリティのために、リソースエクスポータ５２を要求デバイスＤＶ１に含むことができ、リソースインポータ５３を送信先デバイスＤＶ２に含むことができる。したがって、以下、本発明を、図４の構成を用いることによって説明する。
【００５６】
図５は、リソース処理コントローラ４１及びリソースハンドラ５１〜５３を用いることによってリソースを伝送するプロセスを示す流れ図である。具体的には、図５は、要求デバイスＤＶ１に含まれる複数のリソースを送信先である送信先デバイスＤＶ２に伝送するプロセスの一例を示す。
【００５７】
図５を参照すると、要求クライアントＲＣ１は、複数のリソースの伝送を要求するリソース伝送要求メッセージをリソース処理コントローラ４１に伝送し、リソース処理コントローラ４１は、リソース伝送要求メッセージを受信する(段階Ｓ６０)。
【００５８】
この場合、リソース伝送要求メッセージは、伝送セッション識別子（ＩＤ）、リソースチェーン情報、送信元情報、送信先情報等を含むことができる。オプションとして、リソース伝送要求メッセージは、リソースを受信する送信先のＤＲＭシステム情報を更に含むことができる。
【００５９】
リソースチェーン情報を、伝送要求された複数のリソースを識別できる情報とすることができる。ここで、リソースチェーンを、一つ又は複数のリソースから構成されたリソースの組を意味する。本説明の一例として複数のリソースを伝送しているので、リソースチェーンに含まれるリソースの数は複数であると仮定する。しかしながら、本発明は、これに限定されない。したがって、伝送しようとするリソースが一つである場合、リソースチェーンは一つだけのリソースを含むことができる。リソースチェーン情報は、伝送要求されたリソースチェーンに含まれる各リソースを識別できる情報を含むことができる。
【００６０】
伝送セッションＩＤを、伝送セッションを独自に識別できる識別子とすることができる。伝送セッションＩＤは、特定の動作が実行されるとき、例えば、リソースの伝送が取り消されるとき又はリソース伝送状態を表すイベントメッセージを伝送するときに伝送セッションを識別するために用いられる。
【００６１】
送信元情報を、伝送要求された複数のリソースがどこから伝送されるかを識別することができる情報とすることができる。送信元情報は、ソースデバイス又はシステム(例えば、本実施の形態の要求デバイス)を識別することができる識別子、伝送要求されたリソースのファイルフォーマットの情報等を含むことができる。
【００６２】
送信先情報を、要求された複数のリソースが伝送される送信先(例えば、本実施の形態の送信先デバイス)を認識することができる情報とすることができる。送信先情報は、送信先を識別することができる送信先識別子、送信先に要求されるファイルフォーマットの情報等を含むことができる。送信先情報に含まれるファイルフォーマット情報は、フォーマットがリソーストランスフォーマ５１によって変換されるときに用いることができる。
【００６３】
リソース伝送要求メッセージを要求クライアントＲＣ１から受信すると、リソース処理コントローラ４１は、システムに配置されたリソースハンドラの情報を収集する(段階Ｓ６１、Ｓ６２、Ｓ６３)。例えば、リソース処理コントローラ４１は、少なくとも一つのリソースエクスポータ５２、リソースインポータ５３及びリソーストランスフォーマ５１に能力の問合せを行い、対応するエンティティから応答を受信する。したがって、これはリソースの伝送に関連するソース、中間及び送信先のデバイス、システム、ＤＲＭの能力情報を認識することができる。
【００６４】
情報が収集されると、リソース処理コントローラ４１は、収集した情報に基づいて要求されたリソースを伝送するか否か決定する。リソース処理コントローラ４１は、要求されるリソースのフォーマット、システムポリシー、エンティティ間で実行可能なセキュリティ認証チャネルアルゴリズム情報等を考慮することによって、要求されたリソースを伝送することができるか否か検査することができる。例えば、収集されたリソーストランスフォーマの能力が、リソースフォーマットから要求されるリソースフォーマットへの変換をサポートできない場合、リソースを伝送することができない。それに対し、要求されるリソースのフォーマットをサポートすることができるときには、リソースを伝送することができる。リソース処理コントローラ４１は、上述した事項を考慮することによってリソースを伝送するか否か決定することができる。
【００６５】
リソースが伝送されることが決定されると、リソース処理コントローラ４１は、要求されたプロセスを效果的に実行することができるリソースハンドラ５１〜５３から構成されたリソース変換チェーンを形成する。例えば、リソース処理コントローラ４１は、収集された情報に基づいて、要求されたリソース変換を效果的に実行することができるリソースハンドラ５１〜５３、例えば、リソースエクスポータ５２、リソーストランスフォーマ５１(任意)及びリソースインポータ５３を決定し、リソース変換チェーンを形成するようリソースハンドラ５１〜５３を制御する。
【００６６】
リソース変換チェーンは、リソーストランスフォーマ５１を含んでも含まなくてもよい。この理由は、伝送要求されたリソースのフォーマットが送信先で要求されるリソースのフォーマットと異なる場合、伝送されたリソースのフォーマットをリソーストランスフォーマ５１によって変換する必要があり、一方、伝送要求されたリソースのフォーマットが送信先で要求されるリソースのフォーマットと同一である場合、伝送されたリソースのフォーマットを変換する必要がないからである。
【００６７】
リソースのフォーマットの変換をコーデック変換とすることができる。例えば、要求されたリソースがＭＰＥＧ-２で圧縮され、かつ、送信先で用いることができるリソースのフォーマットがＭＰＥＧ-４である場合、ＭＰＥＧ-２フォーマットを有するリソースを送信先で使用することができない。したがって、ＭＰＥＧ-２リソースを、リソーストランスフォーマ５１を用いることによってＭＰＥＧ-４フォーマットに変換する必要がある。本説明において、要求されたリソースのフォーマットが送信先で要求されるリソースのフォーマットと異なり、したがって、リソースの変換が必要であると仮定する。この場合、リソース変換チェーンは、リソーストランスフォーマ５１を有する必要がある。
【００６８】
リソース処理コントローラ４１は、リソース変換チェーンに含まれるリソースハンドラ５１〜５３に動作制御メッセージを送る(段階Ｓ６７、Ｓ６８、Ｓ６９)。例えば、リソース処理コントローラ４１は、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３にそれぞれリソースエクスポート要求メッセージ、リソース変換要求メッセージ及びリソースインポート要求メッセージを送る。
【００６９】
リソースエクスポート要求メッセージは、伝送セッションＩＤ、リソースチェーン情報、受信部情報等を含むことができる。受信部情報を、リソースをエクスポートし及び伝送することができる受信部の情報を意味する。本説明において、リソース変換チェーンがリソーストランスフォーマ５１を含むので、受信部情報を、リソーストランスフォーマ５１の識別情報とすることができる。しかしながら、リソース変換チェーンがリソーストランスフォーマを含まない場合、受信部情報を、リソースインポータ５３の識別情報とすることができる。
【００７０】
リソース変換要求メッセージは、伝送セッションＩＤ、リソースチェーン情報、送信部情報、受信部情報、伝送されるリソースのフォーマット情報、変換されたフォーマットの情報等を含むことができる。送信部情報及び受信部情報を、リソースを送るエンティティ及びリソースを受信するエンティティを識別することができる情報とすることができる。すなわち、送信部情報を、リソースエクスポータ５２の識別情報とすることができ、受信部情報を、リソースインポータ５３の識別情報とすることができる。
【００７１】
リソースインポート要求メッセージは、伝送セッションＩＤ、リソースチェーン情報、送信部情報等を含むことができる。送信部情報を、リソースを伝送する送信部を識別できる情報とすることができる。本説明において、送信部情報を、リソーストランスフォーマ５１の識別情報とすることができる。しかしながら、リソーストランスフォーマ５１がリソースチェーンに存在しない場合、送信部情報を、リソースエクスポータ５２の情報とすることができる。リソースインポートを要求するとき、送信部情報を、リソースを最終的に受信する受信部の情報（送信先の情報）及び送信先のＤＲＭシステム情報を含むことができる。
【００７２】
上記動作制御メッセージ（すなわち、リソースエクスポート要求メッセージ、リソース変換要求メッセージ及びリソースインポート要求メッセージ）に含まれる伝送セッションＩＤは、以前に要求クライアントＲＣ１から受信したリソース伝送要求メッセージに含まれる伝送セッション識別子に対応する情報である。すなわち、動作制御メッセージに含まれる伝送セッション識別子は、リソース伝送要求メッセージに含まれる伝送セッション識別子と実質的に同一である。
【００７３】
動作制御メッセージに含まれるリソースチェーン情報は、要求クライアントＲＣ１から受信したリソース伝送要求メッセージに含まれるリソースチェーン情報に対応する情報である。したがって、リソースチェーン情報が複数のリソースの識別情報を含むので、リソースチェーン情報により識別される複数のリソースを、伝送セッションＩＤによって識別される一つの伝送セッション内で伝送することができる。
【００７４】
このように、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３がそれぞれリソースエクスポート要求メッセージ、リソース変換要求メッセージ及びリソースインポート要求メッセージをリソース処理コントローラ４１から受信するとき、リソースエクスポータ５２とリソーストランスフォーマ５１との間及びリソーストランスフォーマ５１とリソースインポータ５３との間にはセキュリティ認証チャネル(ＳＡＣ)が確立される(段階Ｓ７０)。この場合、トランスポート層セキュリティ（ＴＬＳ）のようなＴＣＰ/ＩＰトランスポート層に用いられるセキュリティ法を、ＳＡＣの確立に用いることができる。
【００７５】
リソースエクスポート要求メッセージに応答して、リソースエクスポータ５２は、伝送要求されたリソースを受信部すなわちリソーストランスフォーマ５１に安全に伝送できるようにリソーストランスフォーマ５１に対してＳＡＣを確立する。また、リソース変換要求に応答して、リソーストランスフォーマ５１は、リソースエクスポータ５２から伝送されるリソースを変換し、リソースをリソースインポータ５３に伝送するためのＳＡＣを確立する。一方、リソースインポート要求に応答して、リソースインポータ５３は、リソーストランスフォーマ５１から伝送されるリソースを送信先デバイスＤＶ２（すなわち、リソース伝送の終点）に伝送するためのＳＡＣを確立することもできる。これは、リソースインポータ５３が送信先デバイスＤＶ２とは異なるデバイスにインストールされたときに更に有用である。
【００７６】
したがって、リソースエクスポータ５２からリソーストランスフォーマ５１を経由したリソースインポータ５３までの経路に沿ってＳＡＣが確立される。さらに、リソースを終点まで提供するために、リソースインポータ５３は、リソースインポータ５３から終点までの経路の間にＳＡＣを確立することができる。各リソースハンドラは、ＳＡＣが完全に確立されたことをリソース処理コントローラ４１に報告する(段階Ｓ７１、Ｓ７２、Ｓ７３)。
【００７７】
ＳＡＣの設立を完了すると、リソースがリソースエクスポータ５２から伝送される(段階Ｓ７４)。この場合、結合されたリソースハンドラ対(すなわち、リソースエクスポータ５２-リソーストランスフォーマ５１及びリソーストランスフォーマ５１-リソースインポータ５３)は、マルチ伝送プロトコルをサポートする。マルチ伝送プロトコルによって、単一の伝送セッションでマルチリソースの伝送を可能にする。このプロトコルは、可変フレームサイズをサポートすることもできる。したがって、複数のリソースを、単一の伝送セッションで伝送することができる。
【００７８】
図６は、マルチ伝送プロトコルの例を示す。
【００７９】
図６に示すように、複数のリソースを単一の伝送セッションの伝送で伝送することができる。リソースインデックスが各リソースのヘッダに挿入される。リソースインデックスを、各リソースを識別する所定のビット値(例えば、４ビット)とすることができる。リソースインデックスは、要求されたリソースと関連付けることによって対応する伝送セッション中に伝送される各リソースを互いに区別するのに用いられる因子である。また、リソースセパレータが、リソースを識別するために各リソースの終わりに挿入される。例えば、リソースセパレータを４ビットの“０”で構成することができる。
【００８０】
各リソースを、長さに応じて複数のフレームに分割することができる。特定ビット(例えば、４ビット)のフレームサイズが各フレームのヘッダに挿入され、その後には、データを積載するフレームペイロードが続く。一方、転送処理の終わり（ＥＯＴ）が、伝送の終わりを表すために各セッションの最後に挿入される。ＥＯＴを、４ビットの“１”とすることができる。
【００８１】
マルチ伝送プロトコルがこれまで説明したようにしてサポートされているので、複数のリソースを、要求クライアントＲＣ１によって提供された伝送セッションＩＤに対応する一つの伝送セッションで送信することができる。このような伝送は、リソースエクスポータ５２から順次開始される。すなわち、リソースエクスポータ５２は、複数のリソースをＳＡＣを介しリソーストランスフォーマ５１に送信する(段階Ｓ７４)。リソーストランスフォーマ５１は、リソースを受信し、リソースが送信先で要求されるフォーマットを有するようにリソースを変換する(段階Ｓ７５)。リソースフォーマットが変換された後、リソーストランスフォーマ５１は、変換されたリソースを、ＳＡＣを介してリソースインポータ５３に伝送する(段階Ｓ７６)。その後、リソースインポータ５３は、変換されたリソースを受信し、受信したリソースを送信先デバイスＤＶ２に提供できる。
【００８２】
リソースエクスポータ５２からリソーストランスフォーマ５１を経由してリソースインポータ５３に伝送されるリソースを、ニュートラルリソースとすることができる。リソースエクスポータ５２は、要求された複数のリソースをエクスポートし、エクスポートされたリソースをニュートラルリソースに変換し、ニュートラルリソースを伝送することができる。リソースエクスポータ５２は、予め変換されたニュートラルリソースをエクスポートし、ニュートラルリソースを伝送することもできる。このプロセスを、要求されたリソースで用いられるＤＲＭシステムによって決定されるポリシー又はエクスポート手順を考慮することによって実行することができる。
【００８３】
リソースインポータ５３は、送信先デバイスＤＶ２で用いられるＤＲＭシステムによって決定されたポリシー又はインポート手順を考慮することによって、受信したニュートラルリソースを送信先デバイスＤＶ２に伝送することができる。例えば、受信したリソースを、送信先ＤＲＭに適合するように暗号化した後に送信先デバイスＤＶ２に提供することができる。受信したニュートラルリソースを、暗号化することなく送信先デバイスＤＶ２に伝送することもできる。
【００８４】
一方、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３は、リソース伝送状態をリソース処理コントローラ４１に報告することができる。このために、リソース処理コントローラ４１は、リソース伝送状態を受けることができるよう特定のイベントをサブスクライブする必要がある(段階Ｓ６４、Ｓ６５、Ｓ６６)。所定のイベントを、リソース伝送状態イベントと称する。
【００８５】
リソース処理コントローラ４１は、動作制御メッセージを送信前にリソース伝送状態イベントのサブスクリプションを要求することができる。例えば、リソース処理コントローラ４１は、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３にリソース伝送状態イベントのサブスクリプションを要求する。その後、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３は、要求の有効性を検査し、要求が有効である場合、イベントのサブスクリプションを許容する応答メッセージを送信する。しかしながら、要求が有効でない場合、イベントサブスクリプションが拒絶される。応答メッセージは、サブスクリプション識別子を含むことができる。したがって、リソース処理コントローラ４１は、リソース伝送状態イベントをサブスクライブすることができる。
【００８６】
リソース処理コントローラ４１はイベント加入エンティティであり、リソースハンドラ５１〜５３はイベント発行エンティティである。イベント加入エンティティを、情報を受け取るためにイベントをサブスクライブするエンティティとすることができる。イベント発行エンティティを、イベントメッセージをイベント加入エンティティに伝送するエンティティとすることができる。
【００８７】
リソース伝送状態イベントをサブスクライブすると、リソース処理コントローラ４１は、リソースの伝送状態の情報を含むリソース伝送状態情報イベントメッセージをプッシュ又はプル方式で受けることができる。プッシュ方式において、リソースハンドラは、リソースの伝送状態に変化が生じる度に (リソース伝送状態情報を含む)イベントメッセージを自動的にプッシュする。したがって、リソースの伝送状態をリソース処理コントローラ４１に自動的に提供することができる。プル方式において、リソース処理コントローラ４１は、必要なときにリソースハンドラからイベントメッセージを取り出す。
【００８８】
リソース伝送状態イベントのサブスクリプションを要求するとき、リソース処理コントローラ４１は、リソース伝送状態情報をプッシュ方式とプル方式のいずれによって受け取るかについての情報を、対応するリソースハンドラに提供する。本説明において、一例として、リソース処理コントローラ４１がプッシュ方式でリソース伝送状態情報イベントメッセージを受信することを説明する。
【００８９】
リソース伝送状態イベントをサブスクライブしたリソース処理コントローラ４１は、特定の伝送セッションで各リソースハンドラから伝送されたリソースの伝送状態情報を含むイベントメッセージを受信することができる。特に、複数のリソースが特定の伝送セッションで伝送されるとき、イベントメッセージは、複数のリソースの各々の伝送状態を表す情報を含むことができる。
【００９０】
図７は、リソース伝送状態情報を含むイベントメッセージの構成の一例を示す。複数のリソースが単一の伝送セッションで伝送されるとき、各リソースの伝送状態情報は、図７に示すようなイベントメッセージに含まれる。
【００９１】
図７を参照すると、リソース伝送状態情報を含むイベントメッセージを、単にＣＴＳＥと称する。ＣＴＳＥは、伝送セッション識別子(単にＴＳＩとも称する)及び複数の伝送状態リポート(単にＴＳＲとも称する)を含む。
【００９２】
ＴＳＩは、該当伝送セッションを識別する情報であり、要求クライアントＤＶ１から受信したリソース伝送要求メッセージ又はリソース処理コントローラ４１によって伝送された動作制御メッセージに含まれる伝送セッション識別子に対応する情報である。換言すれば、ＣＴＳＥに含まるＴＳＩは、リソース伝送要求メッセージ又は動作制御メッセージに含まれる伝送セッションＩＤと実質的に同一の情報である。
【００９３】
各ＴＳＲは、各リソースの伝送状態を表す情報である。ＴＳＲは複数のリソースの間で特定のリソースを識別することができるリソースインデックスを含む。これまで説明したように、リソースインデックスは、伝送要求された各リソースとの関連付けを行うことによって特定の伝送セッションで伝送された各リソースを識別することができる因子である。
【００９４】
また、ＴＳＲは、各リソースの伝送状態情報も含む。伝送状態情報は、リソースの伝送の開始を表すＳｔａｒｔｅｄエレメント、リソースの伝送の完了を表すＣｏｍｐｌｅｔｅｄエレメント、リソースの伝送エラーを表すＴｒａｎｓｆｅｒ-Ｅｒｒｏｒエレメント、リソースの伝送の継続を表すＰｒｏｇｒｅｓｓエレメント等を含むことができる。
【００９５】
したがって、複数のリソースが、リソースエクスポータ５２、リソーストランスフォーマ５１及びリソースインポータ５３で構成されたリソース変換チェーンを介して複数のリソースが伝送されるとき、リソース処理コントローラ４１は、各リソースの伝送状態の情報を受信することができる。後に説明するように、このような動作は、ライセンスにも同様に適用することもできる。ライセンスの場合、動作を、ライセンス処理コントローラ４２によって実行することができる。
【００９６】
表１は、リソース伝送状態情報を含む上記イベントメッセージの構造をスキーマ形態で示す。
【００９７】
【表１】
2010510568.tif 000003
【００９８】
表１を参照すると、リソース伝送状態情報を含むイベントメッセージ、すなわち、resource-transfer-status-event-typeは、ＴＩＳ（すなわち、transfer-session-idendtifier）及びＴＳＲ（すなわち、transfer-status-type）を含む。transfer-status-typeを、以下の表２に示すようなスキーマ形態で表現することができる。
【００９９】
【表２】
2010510568.tif 000004
【０１００】
表２を参照すると、ＴＳＲ（すなわち、transfer-status-type）は、リソースを識別するresource-index及びリソースの伝送状態情報であるtransfer-statusを含むことができる。
【０１０１】
リソース処理コントローラ４１は、リソース伝送状態情報を含む受信したイベントメッセージに応答して、特定のイベントメッセージを特定のクライアント、例えば、要求クライアントＲＣ１に伝送することもできる。この場合、要求クライアントＲＣ１は、リソース伝送状態情報を受信するためにリソース伝送状態イベントをサブスクライブするようリソース処理コントローラ４１に要求する必要がある。例えば、要求クライアントＲＣ１は、イベントにサブスクライブするために、リソース伝送要求のときにリソース処理コントローラ４１にリソース伝送状態イベントのサブスクライブを要求することができる。この場合、要求クライアントＲＣ１は、イベントサブスクリプションエンティティとなり、リソース処理コントローラ４１は、イベントの発行エンティティとなる。
【０１０２】
このようにして、要求クライアントＲＣ１は、伝送要求した各リソースの伝送状態を認識することができる。要求クライアントＲＣ１がユーザインターフェース機能を有する場合、要求クライアントＲＣ１は、リソース伝送状態の情報を数値又はグラフィック形態で提供することができる。特に、複数のリソースを一つの伝送セッションで伝送する場合、ユーザが各リソースの伝送状態を認識できるので、要求したリソースの伝送状態を順次認識することができる。
【０１０３】
一方、認証されたクライアントは、処理制御部にライセンスの伝送を要求することができる。例えば、第１ＤＲＭをインストールした第１クライアントデバイス及び第２ＤＲＭをインストールした第２クライアントデバイスが存在し、ユーザが、第１ＤＲＭリソースを使用するために、第１クライアントデバイスに格納された第１ＤＲＭリソースを第２クライアントデバイスに伝送しようとする場合、第１クライアントは、上記リソース伝送プロセスを用いることによって送信先（すなわち、第２クライアントデバイス）にリソースを伝送することができる。この場合、第２クライアントデバイスが、伝送されたリソースを使用しようとする場合、第２ＤＲＭに適合するイセンスが要求される。したがって、第１クライアントは、ライセンスの伝送を要求する必要がある。
【０１０４】
図８は、ライセンスの伝送に関連したシステムの構成を示すブロック図である。
【０１０５】
図８に示すように、処理制御部４０は、リソース処理コントローラ４１及びライセンス処理コントローラ４２を有する。リソース処理コントローラ４１は以前に説明した。リソース処理コントローラ４１及びライセンス処理コントローラ４２を、ローカルエリア又はネットワークエリアのあらゆる場所に設けることができる。リソース処理コントローラ４１及びライセンス処理コントローラ４２を、別個の領域に配置することができる。例えば、リソース処理コントローラ４１を、ローカルエリアの特定のデバイスに配置することができ、ライセンス処理コントローラ４２を、ネットワークエリアのサービスプロバイダ側に配置することができる。リソース処理コントローラ４１及びライセンス処理コントローラ４２は、特に位置的に制限されない。
【０１０６】
ライセンス処理コントローラ４２は、クライアント３からライセンス伝送要求を受信する。ライセンス伝送要求を受信すると、ライセンス処理コントローラ４２は、伝送に関与するエンティティを決定し又は伝送が可能であるか否か決定するために、システムに含まれるエンティティの情報を収集する。その後、ライセンスが伝送されるチェーンを、ライセンス処理コントローラ４２の制御の下で形成することができる。
【０１０７】
ライセンス処理コントローラ４２に加えて、ライセンスレジストリ２５及びライセンス処理部３０のライセンス処理子３２は、ライセンスの伝送に関与することができる。ライセンスの伝送に関与するエンティティを、ネットワークエリア又はローカルエリアのあらゆる場所に配置することができる。場合によっては、セキュリティを確保しながら伝送されるライセンス情報に対してセキュリティ認証チャネル（ＳＡＣ）を特定のエンティティ間に確立することができる。
【０１０８】
ライセンス処理コントローラ４２は、一つ以上のニュートラルライセンスを受信するために一つ以上のニュートラルライセンスを伝送するようライセンスレジストリ２５に要求することができる。ニュートラルライセンスは、多様なＤＲＭのライセンス情報を抽出するために用いることができる相互運用性のあるニュートラルライセンス情報を表すことができる。ニュートラルライセンスを、ユーザが所定のＤＲＭのリソースを購入するときにライセンスマネージャ２４により対応するＤＲＭのライセンスを用いることによって生成しその後、ニュートラルライセンスをライセンスレジストリ２５に格納することができる。ライセンスレジストリ２５は、ライセンスマネージャ２４、ドメインマネージャ２２又はレファレンスポイントコントローラ２６に存在することができる。場合によっては、ライセンスレジストリ２５は、クライアントデバイス１２に存在することができる。ライセンスの伝送中にニュートラルライセンスを提供するエンティティを、エクスポータの機能を実行するライセンスハンドラとみなすことができる。
【０１０９】
ニュートラルライセンスは、一つ以上のリソースチェーン情報、マネージャ情報、ライセンスを使用することができるプリンシパル情報、一つ以上のユーセージモデル情報等を含むことができる。ユーセージモデル情報を、リソースに対する使用権限が記述された情報とすることができる。
【０１１０】
ライセンス処理コントローラ４２は、提供されたニュートラルライセンスを用いることによって実際伝送する新たなニュートラルライセンスを生成する。リソースとリソースを使用するプリンシパルエンティティとの間の関係、送信先、リソースを使用するプリンシパルエンティティのマッピング関係、リソースマッピング関係等の多様な情報を考慮することができる。
【０１１１】
ライセンス処理コントローラ４２によって生成されたニュートラルライセンスは、ライセンス処理部３０のライセンス処理子３２に伝送される。ライセンス処理子３２は、ライセンス処理コントローラ４２から受信したニュートラルライセンスを送信先のネイティブＤＲＭの受信部９００に伝送するエンティティである。この場合、ライセンス処理子３２は、送信先のＤＲＭで規定した方法に従って、受信したニュートラルライセンスを、送信先のＤＲＭに適合するライセンスに変換し、変換されたライセンスをネイティブＤＲＭ受信部９００に提供することができる。ライセンス処理子３２は、変換を行うことなくニュートラルライセンスを送信先のネイティブＤＲＭ受信部９００に提供することもできる。後者の場合、ライセンス変換は、送信先のＤＲＭシステムそれ自体によって実行される。ライセンス処理子３２及びネイティブＤＲＭ受信部９００はそれぞれ、ライセンスコンバータの機能及びライセンス受信部の機能を実行する。
【０１１２】
ライセンスの伝送に関与するエンティティは、ライセンス伝送及び処理の進行状態を表すライセンス伝送状態イベントメッセージをライセンス処理コントローラ４２に送信することができる。このために、ライセンス処理コントローラ４２は、ライセンス伝送状態イベントの提供を関連のエンティティに要求することによってライセンス伝送状態イベントをサブスクライブする必要がある。ライセンス処理コントローラ４２は、受信したライセンス伝送状態イベントメッセージに対応する情報をクライアント１２に提供することができる。
【０１１３】
また、ライセンス伝送状態イベントメッセージを受信すると、ライセンス処理コントローラ４２は、ライセンス伝送状態イベントメッセージに対応するイベントメッセージをクライアント３に伝送することができる。このために、クライアント３は、ライセンス伝送状態イベントをサブスクライブするためにライセンス伝送状態イベントメッセージの伝送をライセンス処理コントローラ４２に要求する必要がある。
【０１１４】
一方、ニュートラルライセンスは、リソースの使用又はリソースの使用環境の変化に従ってコンテンツを変更する必要がある。例えば、ユーザがリソースを５回再生できる場合にユーザがリソースを現在まで２回再生した場合、ニュートラルライセンスのユーセージモデル情報も、リソースが２回再生されたことを考慮することによってリソースの再生権限を３回に更新する。また、ユーザが、特定のクライアントデバイスに格納されている５回再生可能なリソースを他のクライアントデバイスに送り、５回の再生権限のうち２回を有することを対応するクライアントに許容した場合、クライアントデバイスのリソース再生権限を３回再生に更新する必要がある。ニュートラルライセンスの情報更新を、更新ライセンスイベントを介して実行することができる。
【０１１５】
図９は、ライセンスレジストリとクライアントとの間で更新ライセンスイベントを実行するプロセスを説明する流れ図である。
【０１１６】
図９を参照すると、クライアント３は、ライセンスレジストリ２５に更新ライセンスイベントのサブスクリプションを要求する(段階Ｓ３１)。要求を受け取った後、ライセンスレジストリ２５は、サブスクリプション要求の有効性を決定する。サブスクリプション容共が有効である場合、ライセンスレジストリ２５は、登録を許可する応答メッセージを伝送する(段階Ｓ３２)。ここで、サブスクリプション要求が有効でない場合、イベントのサブスクリプションを拒否することができる。応答メッセージはサブスクライバ識別子を含むことができる。その後、クライアント１２は、イベントサブスクリプションエンティティとしての役割を果たし、ライセンスレジストリ２５は、イベント発行エンティティとしての役割を果たす(段階Ｓ３３)。
【０１１７】
その後、ニュートラルライセンスの情報が変更されるとき、ライセンスレジストリ２５は、変更情報を含む更新ライセンスイベントメッセージをクライアント１２に伝送する。その後、クライアント１２は、伝送された更新ライセンスイベントメッセージを読み取り、ニュートラルライセンスの情報が変更されたことを認識する。その後、クライアント１２は、ライセンス情報を更新できる。
【０１１８】
図１０は、更新ライセンスイベントメッセージの構成の一例を示す。
【０１１９】
図１０を参照すると、更新ライセンスイベントメッセージＵＬＥは、ニュートラルライセンスＫＴを含む。ニュートラルライセンスＫＴは、ニュートラルライセンスのどの部分がどのように変更されたかを表すために変更フィールド情報ＦＤ及び変更状態情報ＵＴを含む。
【０１２０】
変更フィールド情報ＦＤは、ニュートラルライセンスＫＴのどの部分が変更されたかを表す。変更フィールド情報ＦＤで規定することができるフィールド情報の例は、マネージャ情報、プリンシパル情報、リソース識別情報及びユーセージモデル情報を含むことができる。属性名がニュートラルライセンスＫＴの変更フィールド情報ＦＤに割り当てられる。例えば、変更フィールド情報ＦＤは‘field’の属性名を有することができる。
【０１２１】
変更状態情報ＵＴは、変更フィールド情報ＦＤによって表された部分がニュートラルライセンスＩＴにおいてどのように変更したかを表す。変更状態情報ＵＴによって表すことができる変更状態の例は、情報の追加(Added)、情報の削除(Removed)、情報の修正前(Modified-Old)及び情報の修正後(Modified-New)を含むことができる。特定の属性名を、ニュートラルライセンスＫＴの変更状態情報ＵＴに割り当てることができる。例えば、変更状態情報ＵＴは‘Update’の属性名を有することができる。
【０１２２】
例えば、更新ライセンスイベントメッセージに関して、特定のニュートラルライセンスが更新ライセンスイベントメッセージに含まれて、ニュートラルライセンスに含まれる‘field’の属性名を有する部分が‘Usage Model’を表し、‘Update’の属性名を有する部分が‘Modified-New’を表す場合、ニュートラルライセンスは、ユーセージモデルが更新された後に得られるニュートラルライセンスを表す。この場合、ニュートラルライセンスのユーセージモデルがリソースを５回再生する権限を有すると定義する場合、ユーセージモデルが現在リソースを５回再生できるとしても、リソースの再生回数は以前は５回よりも多いと推定することができる。
【０１２３】
このように、クライアント１２は、伝送される更新ライセンスイベントメッセージをライセンスレジストリ２５から受信することによって、クライアント１２は、ニュートラルライセンスが更新されたことを認識することができるようになる。図１０において、クライアント１２がイベント加入エンティティとしての役割を果たし、ライセンスレジストリ２５がイベント発行エンティティとしての役割を果たす。しかしながら、これは一例に過ぎず、本発明はこれに限定されない。したがって、更新ライセンスイベントをライセンスレジストリ間で実行することができる。
【０１２４】
これまで説明したように、ライセンスレジストリを、ライセンスマネージャ、ドメインマネージャ、レファレンスポイントコントローラ及びクライアントデバイスに含むことができる。すなわち、ライセンスレジストリを、ＤＲＭ相互運用システムに複数設けることができる。したがって、複数のライセンスレジストリがニュートラルライセンスの情報を共有するために、特定のライセンスレジストリに格納されたニュートラルライセンスの情報に変更がある場合、情報を更新するために対応する変更状態を他のライセンスレジストリに供給する必要がある。例えば、二つのライセンスレジスタがそれぞれサービスプロバイダ側のライセンスマネージャ及びユーザのクライアントデバイスに含まれる場合、ニュートラルライセンスの更新情報を、二つのライセンスレジスタが更新ライセンスイベントをサブスクライブした後に交換することができる。
【０１２５】
ＤＲＭ相互運用システムを最初に実現するとき、特定のエンティティに対して、他のエンティティからポリシー情報を提供することができる。例えば、ドメインマネージャがローカルエリアに配置されている場合、ドメインマネージャは、サービスプロバイダ側にインストールされた所定のエンティティからポリシー情報を受信する必要がある。この場合、所定のエンティティをポリシープロバイダとすることができる。ポリシープロバイダは、特定のエンティティの要求に従ってポリシー情報を提供するエンティティであり、ポリシープロバイダを、ネットワークエリア、例えば、サービスプロバイダ側に配置することができる。例えば、ポリシープロバイダを、単位機能モジュールの形態でライセンスマネージャに配置することができる。
【０１２６】
ポリシープロバイダは、特定のエンティティ（例えば、ドメインマネージャ）からの要求又は特定のイベントに応じてポリシー情報を提供することができる。
【０１２７】
図１１は、ポリシープロバイダが要求/応答を介してドメインマネージャにポリシー情報を提供するプロセスの例を示す。
【０１２８】
図１１を参照すると、ドメインマネージャ７２をローカルエリアに配置したとき、ポリシープロバイダ７０は、ドメインマネージャ７２を認識し、ドメインマネージャ７２に含まれる構成要素を評価するために構成情報を要求する(段階Ｓ８０)。ドメインマネージャ７２は、複数の単位機能モジュール、例えば、オーセンティケータ７６、プリンシパルマネージャ７５等を含むことができる。その後、構成情報の要求に応答して、ドメインマネージャ７２は、ドメイン７２の構成情報（例えば、オーセンティケータ７６及びプリンシパルマネージャ７５）の構成情報をポリシープロバイダ７０に伝送する(段階Ｓ８１)。
【０１２９】
構成情報を受信すると、ポリシープロバイダ７０は、提供された構成情報を読み取り、ポリシー情報値の設定が必要な単位機能モジュールを選択する。選択された単位機能モジュールからの要求に従って(段階Ｓ８２)、ポリシープロバイダ７０は、ポリシー情報を対応する単位機能モジュール(例えば、図１１のオーセンティケータ７６)に伝送する(段階Ｓ８３)。また、ドメインマネージャ７２からのポリシー要求がある場合(段階Ｓ８４)、ポリシープロバイダ７０は、要求に応答してポリシー情報をドメインマネージャ７２に伝送する(段階Ｓ８５)。
【０１３０】
一方、ポリシープロバイダ７０は、以下説明するように更新変更イベントを用いることによってポリシー情報を提供することもできる。
【０１３１】
図１２は、ポリシープロバイダがイベントを介してポリシー情報を提供するプロセスの一例を示す。
【０１３２】
図１２を参照すると、ドメインマネージャ７２を有するデバイスがローカルエリアに配置されるとき、ドメインマネージャ７２は、ポリシープロバイダ７０に更新変更イベントのサブスクリプションを要求する。更新変更イベントを、ポリシー情報が変更されるときにイベントメッセージを用いることによって変更されたポリシー情報を伝送するイベントとすることができる。ドメインマネージャ７２からのサブスクリプション要求に従って、ポリシープロバイダ７０は、イベントサブスクリプション要求の有効性を決定することによってサブスクリプションを許可する。したがって、ドメインマネージャ７２は、更新変更イベントをサブスクライブする(段階Ｓ９０)。この場合、ドメインマネージャ７２は、更新変更イベントの加入エンティティとしての役割を果たし、ポリシープロバイダ７０は、更新変更イベントの発行エンティティとしての役割を果たす。
【０１３３】
一方、ポリシープロバイダ７０は、構成変更ベントのサブスクリプションをドメインマネージャ７２に要求する。構成変更ベントを、イベント発行エンティティの構成情報(例えば、単位機能モジュールの情報等)が変更されるときにイベントメッセージを用いることによって構成情報を伝送するイベントを意味する。ドメインマネージャ７２は、ポリシープロバイダ７０からのイベントサブスクリプション要求の有効性を決定し、サブスクリプションを許可する。その後、ポリシープロバイダ７０は、構成変更ベントをサブスクライブする(段階Ｓ９１)。この場合、ポリシープロバイダ７０は、構成変更ベントの加入エンティティとしての役割を果たし、ドメインマネージャ７２は構成変更ベントの発行エンティティとしての役割を果たす。
【０１３４】
次いで、ドメインマネージャ７２は、ドメインマネージャ７２それ自体の構成情報（例えば、オーセンティケータ７６及びプリンシパルマネージャ７５の情報）を構成変更ベントメッセージを介してポリシープロバイダに伝送する(段階Ｓ９２)。ポリシープロバイダ７０は、受信した構成変更ベントメッセージを分析し、変更された構成情報に対応するポリシー情報を決定し、対応するポリシー情報を含む更新変更イベントメッセージをドメインマネージャ７２又はポリシー情報を必要とする単位機能モジュール(例えば、図１２のオーセンティケータ７６)に伝送する。
【０１３５】
本発明を、特に本発明の典型的な実施の形態を参照して図示し及び説明したが、添付した特許請求の範囲によって規定されたような本発明の範囲から逸脱することなく形態及び詳細の種々の変更を行うことができることは、当業者によって理解される。
【図面の簡単な説明】
【０１３６】
【図１】本発明の実施の形態によりリソース伝送方法等を実現するためのデジタル著作権管理（ＤＲＭ）相互運用システムのブロック図である。
【図２】ドメイン、ドメインを構成するためのエンティティ及びエンティティ間の相関を示すブロック図である。
【図３】リソースの伝送に用いられる処理制御部及びリソース処理部の詳細な構成を示すブロック図である。
【図４】リソース処理コントローラ及びリソースハンドラの配置の例を示すブロック図である。
【図５】リソース処理コントローラ及びリソースハンドラを用いることによってリソースを伝送するプロセスを示す流れ図である。
【図６】マルチ伝送プロトコルの例を説明する図である。
【図７】リソース伝送状態情報を含むイベントメッセージの構成の一例を示す図である。
【図８】ライセンスの伝送に関連したシステムの構成を示すブロック図である。
【図９】ライセンスレジストリとクライアントとの間の更新ライセンスイベントを実行するプロセスを示す流れ図である。
【図１０】更新ライセンスイベントメッセージの構成の一例を示す図である。
【図１１】ポリシープロバイダが要求/応答動作を介してポリシー情報をドメインマネージャに提供するプロセスの一例を示す図である。
【図１２】ポリシープロバイダがイベントを介してポリシー情報を提供するプロセスの一例を示す図である。
【符号の説明】
【０１３７】
ＤＶ１    要求デバイス
ＤＶ２    送信先デバイス
ＲＣ１    要求クライアント
ＲＣ２    送信先クライアント
４１    リソース伝送コントローラ
５１    リソーストランスフォーマ
５２    リソースエクスポータ
５３    リソースインポータ
【図１】
2010510568.tif 000005
【図２】
2010510568.tif 000006
【図３】
2010510568.tif 000007
【図４】
2010510568.tif 000008
【図５】
2010510568.tif 000009
【図６】
2010510568.tif 000010
【図７】
2010510568.tif 000011
【図８】
2010510568.tif 000012
【図９】
2010510568.tif 000013
【図１０】
2010510568.tif 000014
【図１１】
2010510568.tif 000015
【図１２】
2010510568.tif 000016
【手続補正書】
【提出日】平成21年5月18日(2009.5.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信元デバイス又は中間デバイスが、伝送ハンドラを用いることによって、少なくとも一つのリソースを伝送セッションで送信先デバイスに伝送する段階と、
コントローラが、状態情報と、前記伝送セッションを識別する識別情報と、を含むイベントメッセージを、前記伝送ハンドラから受信する段階と、
を有し、
前記状態情報は、前記リソースを識別するリソースインデックスと、前記リソースインデックスによって識別される前記リソースの伝送状態と、を含むことを特徴とするリソース伝送方法。
【請求項２】
前記イベントメッセージは、前記少なくとも一つのリソースに対応する前記状態情報の少なくとも一部を含む請求項１に記載のリソース伝送方法。
【請求項３】
前記少なくとも一つのリソースを伝送する段階は、
前記コントローラが、前記少なくとも一つのリソースを前記送信先デバイスに伝送することを要求する伝送要求メッセージを受信する段階と、
前記コントローラが、前記伝送を実行するために前記少なくとも二つのハンドラを含むチェーンを形成する段階と、
前記コントローラによって、前記送信元デバイス又は前記中間デバイスに、前記伝送セッションで前記少なくとも一つのリソースを前記送信先デバイスに伝送させる段階と、
を有する請求項１に記載のリソース伝送方法。
【請求項４】
前記伝送要求メッセージは、
前記伝送セッションを識別する伝送セッション情報と、
前記少なくとも一つのリソースを伝送する送信元デバイス又は中間デバイスを表す送信元情報と、
前記送信先デバイスを識別する送信先情報と、
を含む請求項３に記載のリソース伝送方法。
【請求項５】
伝送ハンドラを用いることによって、少なくとも一つのリソースを伝送セッションで伝送する送信元デバイス又は中間デバイスと、
前記少なくとも一つのリソースを受信する送信先デバイスと、
状態情報と、前記伝送セッションを識別する識別情報と、を含むイベントメッセージを、前記伝送ハンドラから受信するコントローラと、
を有し、
前記状態情報は、前記リソースを識別するリソースインデックスと、前記リソースインデックスによって識別される前記リソースの伝送状態と、を含むことを特徴とするリソース伝送システム。
【請求項６】
前記イベントメッセージは、前記少なくとも一つのリソースに対応する前記状態情報の少なくとも一部を含む請求項５に記載のリソース伝送システム。
【請求項７】
前記少なくとも一つのリソースの伝送は、
前記少なくとも一つのリソースを前記送信先デバイスに伝送することを要求する伝送要求メッセージの前記コントローラによる受信と、
前記伝送を実行するために前記少なくとも二つのハンドラを含むチェーンの前記コントローラによる形成と、
前記コントローラによって、前記送信元デバイス又は前記中間デバイスに、前記伝送セッションで前記少なくとも一つのリソースを前記送信先デバイスに伝送させることと、
を有する請求項５に記載のリソース伝送システム。
【請求項８】
前記伝送要求メッセージは、
前記伝送セッションを識別する伝送セッション情報と、
前記少なくとも一つのリソースを伝送する送信元デバイス又は中間デバイスを表す送信元情報と、
前記送信先デバイスを識別する送信先情報と、
を含む請求項７に記載のリソース伝送システム。
【請求項９】
コンピュータによって読取り可能なリソース伝送プログラムであって、当該プログラムは、コンピュータによって、
送信元デバイス又は中間デバイスが、伝送ハンドラを用いることによって、少なくとも一つのリソースを伝送セッションで送信先デバイスに伝送する段階と、
コントローラが、状態情報と、前記伝送セッションを識別する識別情報と、を含むイベントメッセージを、前記伝送ハンドラから受信する段階と、
を実行させ、
前記状態情報は、前記リソースを識別するリソースインデックスと、前記リソースインデックスによって識別される前記リソースの伝送状態と、を含むことを特徴とするリソース伝送プログラム。
【請求項１０】
前記イベントメッセージは、前記少なくとも一つのリソースに対応する前記状態情報の少なくとも一部を含む請求項９に記載のリソース伝送プログラム。
【請求項１１】
前記少なくとも一つのリソースを伝送する段階は、
前記コントローラが、前記少なくとも一つのリソースを前記送信先デバイスに伝送することを要求する伝送要求メッセージを受信する段階と、
前記コントローラが、前記伝送を実行するために前記少なくとも二つのハンドラを含むチェーンを形成する段階と、
前記コントローラによって、前記送信元デバイス又は前記中間デバイスに、前記伝送セッションで前記少なくとも一つのリソースを前記送信先デバイスに伝送させる段階と、
を有する請求項９に記載のリソース伝送プログラム。
【請求項１２】
前記伝送要求メッセージは、
前記伝送セッションを識別する伝送セッション情報と、
前記少なくとも一つのリソースを伝送する送信元デバイス又は中間デバイスを表す送信元情報と、
前記送信先デバイスを識別する送信先情報と、
を含む請求項１１に記載のリソース伝送プログラム。
【国際調査報告】
2010510568.tif 000017
2010510568.tif 000018