(57)【要約】【解決手段】レガシーデバイス登録方法、データ伝送方法及びレガシーデバイス認証方法を提供する。レガシーデバイスのドメインへのアクセスを許容する仮想クライアントを用いることによってレガシーデバイスを登録するレガシーデバイス登録方法は、レガシーデバイスをドメインに登録することを要求するレガシーデバイスからレガシーデバイスの固有の情報を受信する段階と、レガシーデバイスの固有の情報を求めるために、ドメインに登録することができるレガシーデバイスの固有の情報を含む登録可能なレガシーデバイスのリストを探索する段階と、レガシーデバイスの固有の情報が登録可能なレガシーデバイスのリストに含まれるとき、ドメインを管理するドメインマネージャにレガシーデバイスの登録を要求し、レガシーデバイスの固有の情報が登録可能なレガシーデバイスのリストに含まれないとき、ドメインへのレガシーデバイスの登録を許可しない段階と、を有する。
2009529179.tif 000002
【特許請求の範囲】
【請求項１】
レガシーデバイスのドメインへのアクセスを許容する仮想クライアントを用いることによってレガシーデバイスを登録するレガシーデバイス登録方法であって、
前記レガシーデバイスをドメインに登録することを要求する前記レガシーデバイスから前記レガシーデバイスの固有の情報を受信する段階と、
前記レガシーデバイスの固有の情報を求めるために、前記ドメインに登録することができるレガシーデバイスの固有の情報を含む登録可能なレガシーデバイスのリストを探索する段階と、
前記レガシーデバイスの固有の情報が前記登録可能なレガシーデバイスのリストに含まれるとき、前記ドメインを管理するドメインマネージャに前記レガシーデバイスの登録を要求し、前記レガシーデバイスの固有の情報が前記登録可能なレガシーデバイスのリストに含まれないとき、前記ドメインへの前記レガシーデバイスの登録を許可しない段階と、を有することを特徴とするレガシーデバイス登録方法。
【請求項２】
前記レガシーデバイスをドメインに登録することを要求した後、前記レガシーデバイスのデバイス識別子を前記ドメインマネージャから受信する段階と、
受信したレガシーデバイスのデバイス識別子を前記レガシーデバイスの固有の情報に関連して格納する段階を更に有する請求項１に記載のレガシーデバイス登録方法。
【請求項３】
前記レガシーデバイスの固有の情報は、物理的構成情報及び論理的構成情報の少なくとも一方である請求項１に記載のレガシーデバイス登録方法。
【請求項４】
仮想クライアントにアクセスするレガシーデバイスからデータ伝送要求を受け取る段階と、
前記データの伝送に関与するエンティティの情報を収集する段階と、
収集したエンティティの情報を用いることによって、少なくとも二つのエンティティを含むチェーンを形成する段階と、
前記チェーンを介して複数のデータを伝送する段階と、
前記チェーンに含まれるエンティティの少なくとも一つから前記伝送されるデータの伝送状態を表すイベントメッセージを受信する段階と、を有することを特徴とするデータ伝送方法。
【請求項５】
前記レガシーデバイスの固有の情報及びユーザ情報の少なくとも一つは、前記仮想クライアントによって管理される請求項４に記載のデータ伝送方法。
【請求項６】
前記仮想クライアントは、前記レガシーデバイスの固有情報を求めるために登録可能なレガシーデバイスのリストを探索し、探索結果に基づいて前記レガシーデバイスのアクセスを許容する請求項４に記載のデータ伝送方法。
【請求項７】
仮想クライアントにアクセスするレガシーデバイスから少なくとも一つの送信先にデータを伝送することを要求するデータ伝送要求メッセージを受信する段階と、
前記データの伝送に関与するエンティティの情報を収集する段階と、
収集されたエンティティの情報に基づいて少なくとも二つのエンティティを含む複数のチェーンを形成し及び前記複数のチェーンを介して前記データを前記少なくとも一つの送信先に伝送する段階と、を有することを特徴とするデータ伝送方法。
【請求項８】
前記チェーンに含まれるエンティティから前記チェーンを介して伝送されるデータの伝送状態を表すイベントメッセージを受信する段階を更に含む請求項７に記載のデータ伝送方法。
【請求項９】
仮想クライアントを用いることによって、ドメインへのアクセスを要求するレガシーデバイスの固有の情報を受信する段階と、
仮想クライアントを用いることによって、受信したレガシーデバイスの固有の情報をドメインマネージャへ伝送し及び前記レガシーデバイスを認証することを前記ドメインマネージャに要求する段階と、
前記ドメインマネージャによって、前記伝送されたレガシーデバイスの固有の情報を用いることによって前記レガシーデバイスが前記ドメインに重複してアクセスするか否か決定し及び決定結果に基づいて前記レガシーデバイスを認証する段階と、を含むことを特徴とするレガシーデバイス認証方法。
【請求項１０】
前記仮想クライアントは、レガシーデバイスの固有の情報及びデバイス識別子を互いに対応させて格納する情報テーブルを管理する請求項９に記載のレガシーデバイス認証方法。
【請求項１１】
前記レガシーデバイスを認証することを前記ドメインマネージャに要求する段階は、
前記受信したレガシーデバイスの固有の情報を求めて前記仮想クライアントの情報テーブルを探索することによって受信したレガシーデバイスの固有の情報と同一のレガシーデバイスの固有の情報が存在するか否か決定する段階と、
受信したレガシーデバイスの固有の情報と同一のレガシーデバイスの固有の情報が存在するとき、前記レガシーデバイスを認証するようドメインマネージャに要求し、受信したレガシーデバイスの固有の情報と同一のレガシーデバイスの固有の情報が存在しないとき、新たなデバイス識別子を受信し、前記新たなデバイス識別子を前記情報テーブルに格納し、前記レガシーデバイスを認証するようドメインマネージャに要求する段階と、を有する請求項１０に記載のレガシーデバイス認証方法。
【請求項１２】
前記ドメインマネージャは、前記レガシーデバイスの固有の情報及び各デバイスに対するデバイス識別子を格納する情報テーブルを管理する請求項９に記載のレガシーデバイス認証方法。
【請求項１３】
前記レガシーデバイスを認証する段階は、
伝送されたレガシーデバイスの固有の情報を求めて前記ドメインマネージャの情報テーブルを探索することによって、前記レガシーデバイスが他のドメインにアクセスするか否か決定する段階と、
前記レガシーデバイスが他のドメインにアクセスするとき、前記レガシーデバイスへのアクセスを許可せず、前記レガシーデバイスが他のドメインにアクセスされないとき、前記レガシーデバイスの接続を許可する段階と、を有する請求項１２に記載のレガシーデバイス認証方法。
【請求項１４】
前記仮想クライアントを用いることによって、前記ドメインにアクセスを要求するレガシーデバイスのユーザ情報を受信する段階と、
前記仮想クライアントを用いることによって、受信したユーザ情報を前記ドメインマネージャに伝送する段階と、
伝送されたユーザ情報を用いることによって、ドメインにアクセスするユーザのレガシーデバイスの個数を探索し及び見つけた個数と前記ユーザに対して許容された前記レガシーデバイスのアクセス動作の制限回数とを比較する段階と、を更に有する請求項９に記載のレガシーデバイス認証方法。
【請求項１５】
前記仮想クライアントを用いることによって、前記ドメインにアクセスを要求するレガシーデバイスのユーザ情報を受信する段階と、
前記仮想クライアントを用いることによって、前記使用者情報をドメインマネージャに伝送し及び前記レガシーデバイスを認証することを前記ドメインマネージャに要求する段階と、
伝送されたユーザ情報を用いることによって、ドメインにアクセスするユーザのレガシーデバイスの個数を探索し及び見つけた個数と前記ユーザに対して許容された前記レガシーデバイスのアクセス動作の制限回数とを比較する段階と、
比較結果に基づいて前記レガシーデバイスが前記ドメインへのアクセスを許可されたか否かを認証する段階を有することを特徴とするレガシーデバイス認証方法。
【請求項１６】
ドメインを管理するドメイン管理エンティティと、
所定のレガシーデバイスを前記ドメインに登録する要求を受け取ると、前記特定レガシーデバイスの固有情報を抽出し、抽出した所定のレガシーデバイスの固有の情報の固有の情報を求めるために、ドメインに登録可能なレガシーデバイスの固有の情報を格納するデバイスリストを探索し、探索結果に基づいて、前記ドメインマネージャエンティティが前記所定のレガシーデバイスを登録するよう要求されているか否か決定する仮想クライアントと、を有することを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、レガシーデバイス登録方法、データ伝送方法及びレガシーデバイス認証方法に関し、更に詳しくは、レガシーデバイスの固有の情報を用いることによってレガシーデバイスをドメインに登録するレガシーデバイス登録方法、データ伝送方法及びそれに関連するレガシーデバイス認証方法に関する。
【背景技術】
【０００２】
一般に、デジタルコンテンツは、アナログコンテンツとは違って情報を損失することなく無限にコピーされるので、デジタルコンテンツは、違法コピー及び使用に容易にさらされる。この理由は、デジタルコンテンツのサービスを提供するために違法コピー及び使用からデジタルコンテンツを安全に保護することができるコンテンツ保護技術をサポートする必要があるからである。
【０００３】
デジタル著作権管理(ＤＲＭ)は、合法な権限を与えられたユーザのみにデジタルコンテンツの使用を許容する完全なデジタルコンテンツ保護技術である。ＤＲＭは、セキュリティ技術、ウォーターマーキング技術、耐タンパ性技術等を技術的に含むとしても、ＤＲＭは、技術というよりはむしろフレームワークを表す。
【０００４】
ＤＲＭは、コンテンツの違法コピー及び使用自体を根本的に防止することに重点を置く。ＤＲＭにおいて、デジタルコンテンツは、暗号化技術を用いることによってパッケージ形態の暗号化データに変換される。したがって、デジタルコンテンツが所定のユーザによって偶然に取得されたとしても、合法な認証プロセスなくデジタルコンテンツを使用することができない。
【０００５】
インターネットや移動体通信網のような有線／無線通信網を介して提供される大抵の合法なコンテンツサービスを、対応するコンテンツのサービスプロバイダ又はコンテンツプロバイダによって使用されるＤＲＭをサポートするＤＲＭデバイスによってのみ実行可能である。これは、ＤＲＭの技術的及びポリティカルな閉鎖特性に起因する。
【０００６】
一方、ＤＲＭの技術的及びポリティカルな閉鎖特性は、コンテンツの合法性を保障するという点で有利である。しかしながら、ユーザのコンテンツ使用を制限するという問題がある。この理由は、サービスプロバイダによって用いられるＤＲＭがインストールされたＤＲＭデバイス又はＤＲＭ使用ソフトウェアを個別に含む必要があるからであり、その結果、ユーザは、複数のサービスプロバイダによって提供されるデジタルコンテンツを使用する場合、契約、支払い、認証等を個別に行う必要がある。
【０００７】
上記問題は、デジタルコンテンツの流通機構の柔軟性を悪化させる。最終的には、上記問題によってデジタルコンテンツサービスに制限が生じる。
【０００８】
最近、閉鎖的なＤＲＭ構造が互換性のあるフレームワークを提供することが意図されている。異なる種類のＤＲＭを互いに適合できるようにするために、閉鎖的なＤＲＭ間の差を調整するＤＲＭ相互運用システムが要求されている。システム資源を定義し、定義されたシステム資源を生成して管理する動作モデルを提案することによって、ＤＲＭ相互運用システムを具現することができる。また、このようなＤＲＭ相互運用システムをサポートするために、定義されたシステム資源と動作モデルを用いる多様なシナリオを提案する必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、ドメインに登録することを所望するレガシーデバイスの固有の情報に基づいてレガシーデバイスを登録するか否かを決定するレガシーデバイス登録方法を提供する。
【００１０】
本発明は、レガシーデバイスから受信したデータの伝送要求に応答してデータを効率的に伝送するデータ伝送を提供する。
【００１１】
本発明は、レガシーデバイスの固有の情報又はユーザ情報を用いることによってレガシーデバイスを認証するレガシーデバイス認証方法も提供する。
【００１２】
本発明は、レガシーデバイスの固有の情報に基づいてレガシーデバイスを登録するか否かを決定するシステムも提供する。
【課題を解決するための手段】
【００１３】
本発明の一態様によれば、レガシーデバイスのドメインへのアクセスを許容する仮想クライアントを用いることによってレガシーデバイスを登録するレガシーデバイス登録方法であって、前記レガシーデバイスをドメインに登録することを要求する前記レガシーデバイスから前記レガシーデバイスの固有の情報を受信する段階と、前記レガシーデバイスの固有の情報を求めるために、前記ドメインに登録することができるレガシーデバイスの固有の情報を含む登録可能なレガシーデバイスのリストを探索する段階と、前記レガシーデバイスの固有の情報が前記登録可能なレガシーデバイスのリストに含まれるとき、前記ドメインを管理するドメインマネージャに前記レガシーデバイスの登録を要求し、前記レガシーデバイスの固有の情報が前記登録可能なレガシーデバイスのリストに含まれないとき、前記ドメインへの前記レガシーデバイスの登録を許可しない段階と、を有することを特徴とするレガシーデバイス登録方法を提供する。
【００１４】
本発明の上記態様において、レガシーデバイス登録方法は、前記レガシーデバイスをドメインに登録することを要求した後、前記レガシーデバイスのデバイス識別子を前記ドメインマネージャから受信する段階と、受信したレガシーデバイスのデバイス識別子を前記レガシーデバイスの固有の情報に関連して格納する段階を更に有することができる。
【００１５】
また、レガシーデバイスの固有の情報を、レガシーデバイスのメディアアクセス制御アドレス、ディスクボリュームＩＤ等とすることができる。
【００１６】
本発明の他の態様によれば、仮想クライアントにアクセスするレガシーデバイスからデータ伝送要求を受け取る段階と、前記データの伝送に関与するエンティティの情報を収集する段階と、収集したエンティティの情報を用いることによって、少なくとも二つのエンティティを含むチェーンを形成する段階と、前記チェーンを介して複数のデータを伝送する段階と、前記チェーンに含まれるエンティティの少なくとも一つから前記伝送されるデータの伝送状態を表すイベントメッセージを受信する段階と、を有することを特徴とするデータ伝送方法を提供する。
【００１７】
本発明の上記態様において、前記レガシーデバイスの固有の情報及びユーザ情報の少なくとも一つは、前記仮想クライアントによって管理される。また、前記仮想クライアントは、前記レガシーデバイスの固有情報を求めるために登録可能なレガシーデバイスのリストを探索し、探索結果に基づいて前記レガシーデバイスのアクセスを許容することができる。
【００１８】
本発明の他の態様によれば、仮想クライアントにアクセスするレガシーデバイスから少なくとも一つの送信先にデータを伝送することを要求するデータ伝送要求メッセージを受信する段階と、前記データの伝送に関与するエンティティの情報を収集する段階と、収集されたエンティティの情報に基づいて少なくとも二つのエンティティを含む複数のチェーンを形成し及び前記複数のチェーンを介して前記データを前記少なくとも一つの送信先に伝送する段階と、を有することを特徴とするデータ伝送方法を提供する。
【００１９】
本発明の他の態様によれば、仮想クライアントを用いることによって、ドメインへのアクセスを要求するレガシーデバイスの固有の情報を受信する段階と、仮想クライアントを用いることによって、受信したレガシーデバイスの固有の情報をドメインマネージャへ伝送し及び前記レガシーデバイスを認証することを前記ドメインマネージャに要求する段階と、前記ドメインマネージャによって、前記伝送されたレガシーデバイスの固有の情報を用いることによって前記レガシーデバイスが前記ドメインに重複してアクセスするか否か決定し及び決定結果に基づいて前記レガシーデバイスを認証する段階と、を含むことを特徴とするレガシーデバイス認証方法を提供する。
【００２０】
本発明の上記態様において、前記仮想クライアントは、レガシーデバイスの固有の情報及びデバイス識別子を互いに対応させて格納する情報テーブルを管理することができる。また、前記レガシーデバイスを認証することを前記ドメインマネージャに要求する段階は、前記受信したレガシーデバイスの固有の情報を求めて前記仮想クライアントの情報テーブルを探索することによって受信したレガシーデバイスの固有の情報と同一のレガシーデバイスの固有の情報が存在するか否か決定する段階と、受信したレガシーデバイスの固有の情報と同一のレガシーデバイスの固有の情報が存在するとき、前記レガシーデバイスを認証するようドメインマネージャに要求し、受信したレガシーデバイスの固有の情報と同一のレガシーデバイスの固有の情報が存在しないとき、新たなデバイス識別子を受信し、前記新たなデバイス識別子を前記情報テーブルに格納し、前記レガシーデバイスを認証するようドメインマネージャに要求する段階と、を有することができる。
【００２１】
また、前記ドメインマネージャは、前記レガシーデバイスの固有の情報及び各デバイスに対するデバイス識別子を格納する情報テーブルを管理することができる。この場合、前記レガシーデバイスを認証する段階は、伝送されたレガシーデバイスの固有の情報を求めて前記ドメインマネージャの情報テーブルを探索することによって、前記レガシーデバイスが他のドメインにアクセスするか否か決定する段階と、前記レガシーデバイスが他のドメインにアクセスするとき、前記レガシーデバイスへのアクセスを許可せず、前記レガシーデバイスが他のドメインにアクセスされないとき、前記レガシーデバイスの接続を許可する段階と、を有することができる。
【００２２】
本発明の他の態様によれば、前記仮想クライアントを用いることによって、前記ドメインにアクセスを要求するレガシーデバイスのユーザ情報を受信する段階と、前記仮想クライアントを用いることによって、前記使用者情報をドメインマネージャに伝送し及び前記レガシーデバイスを認証することを前記ドメインマネージャに要求する段階と、伝送されたユーザ情報を用いることによって、ドメインにアクセスするユーザのレガシーデバイスの個数を探索し及び見つけた個数と前記ユーザに対して許容された前記レガシーデバイスのアクセス動作の制限回数とを比較する段階と、比較結果に基づいて前記レガシーデバイスが前記ドメインへのアクセスを許可されたか否かを認証する段階を有することを特徴とするレガシーデバイス認証方法を提供する。
【００２３】
本発明の他の態様によれば、ドメインを管理するドメイン管理エンティティと、
所定のレガシーデバイスを前記ドメインに登録する要求を受け取ると、前記特定レガシーデバイスの固有情報を抽出し、抽出した所定のレガシーデバイスの固有の情報の固有の情報を求めるために、ドメインに登録可能なレガシーデバイスの固有の情報を格納するデバイスリストを探索し、探索結果に基づいて、前記ドメインマネージャエンティティが前記所定のレガシーデバイスを登録するよう要求されているか否か決定する仮想クライアントと、を有することを特徴とするシステムを提供する。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の好適な実施例を、添付図面を参照して詳細に説明する。添付図面を参照して典型的な実施例を明瞭に説明するために、特定の技術用語を用いる。しかしながら、本発明は、選択した特定の技術用語に限定されることはなく、特定の用語は、同様の目的を達成するために同様の方法で動作する全ての技術的な同義語を含む。
【００２５】
図１は、本発明の典型的な実施例によるＤＲＭ相互運用システムの概念及び主要機能を説明するためのブロック図である。
【００２６】
図１に示すように、ＤＲＭ相互運用システム１０００は、異なるＤＲＭ領域間でサービスを互いに適合させる。ＤＲＭ相互運用システム１０００は、データ相互運用制御機能ｆ１、データ相互運用機能ｆ２、状態表示機能ｆ３、ドメイン管理機能ｆ４等を実行することができる。
【００２７】
データ相互運用制御機能ｆ１は、データが互いに適合されるようにデータの相互運用性を制御する。このとき、データは、コンテンツ又はライセンスを表すことができる。具体的には、データ相互運用制御機能ｆ１は、コンテンツ相互運用制御機能ｆ１ａ及びライセンスデータ相互運用制御機能ｆ２ｂを有する。
【００２８】
データ相互運用機能ｆ２は、データ相互運用制御機能ｆ１の制御下でコンテンツ又はライセンスを適合することができる機能を表すことができる。例えば、データ相互運用機能ｆ２によれば、ＤＲＭ領域Ａに存在するシステムＡ又はデバイスＡのデータ、例えば、コンテンツ又はライセンスを、ＤＲＭ領域ＢのシステムＢ又はデバイスＢに提供することができる。ＤＲＭ領域ＢのシステムＢ又はデバイスＢのコンテンツ又はライセンスを、ＤＲＭ領域ＡのシステムＡ又はデバイスＡに提供することができる。具体的には、データ相互運用機能ｆ２は、コンテンツ相互運用機能ｆ２a及びライセンス相互運用機能ｆ２ｂを有することができる。
【００２９】
状態表示機能ｆ３は、ＤＲＭ相互運用システム１００の動作状態を表示する機能を表すことができる。例えば、状態表示機能ｆ３は、チャネル形成イベント機能ｆ３ａ、送信関連イベント機能ｆ３ｂ、変換関連イベント機能ｆ３ｃ等のようなイベント機能を有することができる。
【００３０】
ドメイン管理機能ｆ４は、クライアントを認証して管理するためにドメインを管理する機能を表すことができる。ドメイン管理機能ｆ４は、レファレンスポイントコントローラ登録/管理機能ｆ４ａ、レガシーデバイス管理機能ｆ４ｂ等を有することができる。
【００３１】
上記機能を実行するためのシステムの構成及び動作を、以下で詳細に説明する。
【００３２】
＊システムの構成及び動作＊
図２は、異なる種類のＤＲＭが互いに適合されるＤＲＭ相互運用システムの概略的な構成を示すブロック図である。
【００３３】
図２に示すように、ＤＲＭ相互運用システムは、クライアント部１０、認証及び管理部２０、処理制御部４０、コンテンツ処理部５０及びライセンス処理部３０を有することができる。
【００３４】
上述した各部を、少なくとも一つ以上のエンティティで構成することができる。このとき、エンティティは、所定の固有の機能を実行するソフトウェア又はハードウェアとして構成されたモジュール又はデバイスを表すことができる。各エンティティを、所定の単位機能を実行する一つ以上の単位機能モジュールの集合とすることができる。エンティティは、所定のインタフェースを介して他のエンティティとデータ通信を行うために所定の装置にインストールされる。また、エンティティが同一部に属するとしても、エンティティを、異なるデバイスにインストールし又は具現することができる。デバイスは、実行環境に従って異なることができる。
【００３５】
以下、各部に含まれるエンティティの機能及びエンティティ間のインタラクションを介した動作を説明するとともに、各部の特徴的な構造及び機能を説明する。
【００３６】
１．クライアント部の機能及び動作
クライアント部１０はクライアントを有することができる。クライアントは、ユーザが認証及び管理部２０並びに処理制御部４０と連携してＤＲＭ相互運用サービスを利用できるように各種機能を提供するエンティティである。
【００３７】
クライアントを、ユーザのデバイスに含めることができる。クライアントを有するデバイスは、クライアントデバイスと称される。
【００３８】
クライアント認証を認証及び管理部２０に要求することによって、クライアントを認証することができる。認証されたクライアントは、所定のエンティティを呼び出すことによって所定のデータ、例えば、所定のコンテンツ又はライセンスを所望の送信先に伝送するよう処理制御部４０に要求することができる。ここで、送信先を、所定のコンテンツ又はライセンスに適用されるＤＲＭと異なるＤＲＭがインストールされたデバイス又はソフトウェアシステム、例えば、ドメインに存在する他のクライアントデバイスとすることができる。
【００３９】
図３及び図４は、認証されたクライアントが処理制御部４０へデータ伝送を要求する例を示す。図３は、クライアントが処理制御部４０にコンテンツ伝送を要求する例を示しており、図４はクライアントが処理制御部４０にライセンス伝送を要求する例を示す。
【００４０】
図３に示すように、クライアントは、処理制御部４０のコンテンツ処理コントローラ４１にコンテンツの伝送を要求する。その後、コンテンツ処理コントローラ４１は、要求されたコンテンツを所望の送信先に伝送できるようにコンテンツ処理部５０を制御する。このとき、要求されたコンテンツのコンテンツフォーマット及びＤＲＭは、送信先によって要求されたコンテンツフォーマット及びＤＲＭと異なってもよい。コンテンツ処理部５０は、送信先によって要求された条件をコンテンツが満足するようにコンテンツを処理し、処理されたコンテンツを送信先に提供する。伝送及び処理手順を、図１８〜３４を参照しながら後に説明する。
【００４１】
また、図４に示すように、クライアントは、処理制御部４０のライセンス処理コントローラ４２にライセンスの伝送を要求する。その後、ライセンス処理コントローラ４２は、要求されたライセンスを所望の送信先に伝送できるようにライセンス処理部３０を制御する。このとき、要求されたライセンスのフォーマットは、送信先によって要求されたフォーマットと異なってもよい。ライセンス処理部３０は、送信先によって要求された条件を満足するように種々の特性を処理し、処理結果を送信先に提供する。ライセンスの処理及び伝送手順を、図３５を参照しながら後に説明する。
【００４２】
一方、クライアントは、クライアントの典型的な機能、例えば、コンテンツの使用(又は再生)機能、ユーザインタフェース機能等を備えてもよい。この場合、クライアントはコンテンツの消費の終点になることができる。
【００４３】
クライアントを正当なクライアントとして認識するとともに認証及び管理部２０によって管理する必要がある。上記プロセスを容易に実行するために、ＤＲＭ相互運用システムは、ドメインの概念を導入することができる。
【００４４】
ドメインは、ＤＲＭトラストフレームワークの基本単位である、ＤＲＭ相互運用システムが実際に適用される範囲を表す。ドメインを、許可されたデバイス又はシステムの集合によって構成することができる。例えば、ドメインは、許可されたクライアントデバイスの集合を含むことができる。この場合、ドメイン内のクライアントデバイスが異なるＤＲＭコンテンツを有するとしても、クライアントデバイスは、コンテンツを共有することができる。
【００４５】
２．認証及び管理部の機能及び動作
図５は、ドメインと、ドメインを構成するエンティティ及びエンティティ間の相関関係を示すブロック図である。図５は、クライアントの認証及び管理に関連するエンティティを示す。
【００４６】
図５を参照すると、ＤＲＭ相互運用システムは、ドメイン５を形成する。ドメイン５を、クライアントデバイス１２の物理的な位置を考慮して構成することができる。具体的には、ドメイン５は、所定の物理領域の許可されたクライアントデバイス１２によって構成される。一方、ドメイン５を、クライアントデバイス１２の物理的な位置を考慮することなく論理的に認証されたクライアントデバイスのみで構成することができる。
【００４７】
本説明において、これまで説明したように、クライアントデバイス１２の物理的な位置を考慮しながら所定のローカルエリアのクライアントデバイス１２によってドメインを構成するとしても、ネットワークエリアの所定のローカルエリア外のクライアントデバイスもドメインに加入する場合を例示する。しかしながら、これは実施の形態の一例である。本発明は、それに限定されない。
【００４８】
ドメイン５を構成するためにローカル環境が要求される。このとき、ローカル環境は、所定のローカルエリアのデバイスが互いにインタラクティブとなるように物理的なネットワークが用意された環境を表し、物理的なネットワークは、外部のネットワークとインタラクティブである。
【００４９】
ローカル環境を提供する一例としてホームネットワークシステムが存在する。通常、ホームネットワークシステムにおいて、家庭内の家電器機、各種センサ、セキュリティ装置等は、有線／無線ローカルネットワークを通じて互いにインタラクティブとなることができ、ホームゲートウェイのような通信ノードを介してインターネットのような外部ネットワークとなることができる。ローカル環境を、ホームネットワークシステムとともに二つ以上のインタラクティブネットワークデバイスによって構成することができる。
【００５０】
以下、ローカルエリアは、上述したローカル環境が用意された領域と仮定する。ローカルエリア内に複数のクライアントデバイス１２が存在することができる。クライアントデバイス１２内に含まれるクライアント３を、クライアント３を認証するよう認証及び管理部２０に要求することによって正当なクライアントとして認証することができる。認証されたクライアント３を有するデバイスは、クライアントデバイス１２となる。種々のＤＲＭコンテンツを、ライセンスによって許容される範囲のクライアントデバイス１２の間で用いることができる。
【００５１】
したがって、ユーザは、ユーザの家をローカルエリアに設定し、ユーザの家にある種々のＤＲＭを含むデバイスを用いることによってドメインを構成する。その後、デバイス間でコンテンツが共有され及び使用される。
【００５２】
しかしながら、ローカルエリアのクライアント３に加えて、外部ネットワークのクライアントにも認証を介してサービスが提供される。この場合、ネットワークで認証されたクライアントの状態をローカルエリアで認証されたクライアント３の状態と区分し、これらの状態を個別に管理する必要がある。このために、認証されたクライアントの状態を、リモート状態とローカル状態に区分するとともに管理することができる。
【００５３】
図５を参照すると、クライアント３を認証し及び管理する認証及び管理部２０は、ドメインマネージャ２２、ライセンスマネージャ２４及びレファレンスポイントコントローラ２６を有することができる。
【００５４】
ドメインマネージャ２２は、ドメイン５を管理するよう設計される。例えば、ドメインマネージャ２２は、ドメイン５を生成する機能、ドメイン５を破棄する機能、クライアントをドメイン５に関連付ける機能、クライアントをドメイン５から除去する機能、レファレンスポイントコントローラ２６を登録する機能等を実行することができる。
【００５５】
ドメインマネージャ２２は、ローカルエリア又はネットワークエリアのあらゆる位置に存在することができる。例えば、図５に示す例において、ドメインマネージャ２２は、ネットワークエリアに配置される。この場合、ドメインマネージャ２２は、レファレンスポイントコントローラ２６及びクライアント３と対話することができる。一方、ドメインマネージャをローカルエリアに配置することができる。この場合、ドメインマネージャは、レファレンスポイントコントローラ及びクライアントと対話するためにローカルエリアのデバイスに含まれる。
【００５６】
ライセンスマネージャ２４は、ユーザのライセンス情報を管理するよう設計される。例えば、ライセンスマネージャ２４は、ユーザのためのログイン機能を提供し、ライセンス情報を格納及び管理する典型的なオンラインサービスマネージャの機能を実行することができる。ライセンスマネージャ２４は、ユーザ名を生成する機能、ユーザ名を削除する機能、ライセンス情報をユーザ名に関連付ける機能、ライセンス情報を生成する機能、ライセンス情報を削除する機能等を実行することができる。
【００５７】
ライセンスマネージャ２４を、ネットワークエリア、例えば、サービスプロバイダのサーバに配置することができる。しかしながら、ライセンスマネージャ２４を、サービスプロバイダのサーバのようにネットワークエリアに配置することができる。ライセンスマネージャ２４はローカルエリアに存在することができる。すなわち、ドメインマネージャ２２及びライセンスマネージャ２４を、ローカルエリア又はネットワークエリアのあらゆる位置に配置することができる。
【００５８】
レファレンスポイントコントローラ２６は、所定のエンティティがローカルエリアに存在するか否かを確認し、エンティティがローカルエリアに配置されていることを検証するクレデンシャルを、検証されたエンティティに提供する。このために、レファレンスポイントコントローラ２６は、ローカルエリアの範囲を決定することができる。このとき、ローカルエリアを、物理的な距離、ホップ数、反応時間等を用いることによって決定することができる。
【００５９】
レファレンスポイントコントローラ２６は、クライアント３がローカルエリアに配置されているか否かをクライアント３の要求に従って確認する。クライアント３がローカルエリアに配置されていることが確認されると、リファレンスポイントコントローラ２６は、クライアント３がローカルエリアに配置されていることを検証するドメインクレデンシャルを提供することができる。ドメインクレデンシャルを、クライアント３がクライアント３の認証をドメインマネージャ２２に要求するときにドメインマネージャ２２に提供することができる。ドメインマネージャ２２は、クライアント３がローカルエリアに配置されていることを確認し、クライアント３を認証する。
【００６０】
また、ドメインマネージャ２２は、クライアント３がリモート状態であるかローカル状態であるかをドメインクレデンシャルに基づいて決定する。複数のクライアントがネットワークを介してドメインにアクセスするのを防止するとともにセキュリティを向上するために、ドメインマネージャ２２は、クライアント３の状態を認識することによって、リモート状態でドメインマネージャ２２にアクセスするクライアントの数を制限することができる。
【００６１】
レファレンスポイントコントローラ２６をローカルエリアに配置することができる。具体的には、レファレンスポイントコントローラ２６を、ローカルエリアに配置されたデバイスとして決定することができる。セットップバックスやデスクトップＰＣのような複数のコンピューティング資源を有するとともに移動性がないデバイスとしてレファレンスポイントコントローラ２６を決定するのが有利であるが、レファレンスポイントコントローラ２６を、移動性に優れたデバイスとして決定することができる。
【００６２】
レファレンスポイントコントローラ２６を、ドメインを最初に構成するときに所定の手続きに従って選択することができる。具体的には、ドメイン５を最初に構成するときに、ローカルエリアの範囲を決定するためにレファレンスポイントコントローラの機能を実行するデバイスを選択する。選択されたデバイスを、レファレンスポイントコントローラ２６として決定する必要がある。このとき、決定されたレファレンスポイントコントローラ２６は、ドメインマネージャ２２に登録される。その後、クライアント３は、レファレンスポイントコントローラ２６についてドメインマネージャ２２に問合せを行うことができる。
【００６３】
-レファレンスポイントコントローラの選択-
レファレンスポイントコントローラを選択する三つの方法がある。
ドメインに加入することを所望するデバイスが互いにデバイス情報を伝送し、デバイス情報を所定のアルゴリズムに従って比較し、最も適切なデバイスをレファレンスポイントコントローラとして選択する第１の方法が存在する。選択されたレファレンスポイントコントローラは、デバイスがリファレンスポイントコントローラとして選択されたことをドメインマネージャに報告する必要がある。その後、デバイスをドメインに登録する必要がある。
【００６４】
ドメインに登録することを所望するデバイスがデバイス情報をドメインマネージャに報告し、報告されたデバイス情報に基づいてドメイン管理エンティティがレファレンスポイントコントローラを選択する第２の方法が存在する。
【００６５】
レファレンスポイントコントローラを所定の情報によって選択する第３の方法が存在する。このとき、所定の情報を、アドミニストレータ又はユーザによって設定することができる。また、所定の情報は、任意に決定された情報を含むことができる。例えば、アドミニストレータ又はユーザがドメインマネージャに所定の情報を入力すると、ドメインマネージャは、所定の情報に基づいてレファレンスポイントコントローラを選択することができる。また、レファレンスポイントコントローラとして用いられるデバイスをアドミニストレータ又はユーザが直接選択できるようにすることによって、レファレンスポイントコントローラを確立することができる。
【００６６】
以下、上述した三つの方法を各々詳細に説明する。理解の便宜のために、レファレンスポイントコントローラを選択する上記第１の方法を、「例１-１」と称し、レファレンスポイントコントローラを選択する上記第２の方法を、「例１-２」と称し、レファレンスポイントコントローラを選択する上記第３の方法を、「例１-３」と称する。
【００６７】
<例１-１>
先ず、レファレンスポイントコントローラを選択する手順を説明する前に、ドメインペイロードデータユニット（ＤＰＤＵ）のデータフォーマットを定義する。ＤＰＤＵは、レファレンスポイントコントローラの選択時に各デバイスのデバイス情報を伝送するための規格化されたデータフォーマットである。
【００６８】
図６は、レファレンスポイントコントローラを選択するために必要なＤＰＤＵデータパケットのフォーマットの一例を示す。
【００６９】
図６を参照すると、ＤＰＤＵは、ドメインヘッダー及びドメインペイロードで構成される。
【００７０】
ドメインヘッダーは、デバイス能力識別子(以下、「ＤＣ-ＩＤ」と略する)と、ドメイン識別子(以下、「Ｄ-ＩＤ」と略する)と、デバイスエンティティ識別子(以下、「ＤＥ-ＩＤ」と略する)と、を含む。
【００７１】
ＤＣ-ＩＤは、デバイスの能力値を識別するのに用いられる情報である。このとき、能力値を、所定のアイテムに対するデバイスの能力を表示する情報、例えば、デバイスのエネルギー残量、ハードウェア仕様、ネットワーク接続速度、ネットワーキング能力、外部への移動可能性、システムの安定性、計算能力、資源消耗量等とすることができる。デバイスがドメインに入る前後に、任意の値を、アドミニストレータによって決定された所定の基準に従ってＤＣ−ＩＤに割り当て、又は対応する装置によって生成することができる。ＤＣ-ＩＤは、レファレンスポイントコントローラを選択するときに最も適切なデバイスを選択するための基準となる。
【００７２】
Ｄ-ＩＤは、デバイスの環境及び特性に従ってドメインを分類するための情報である。これまで説明したように、ドメインを、物理的な領域分類基準従って分類された領域又は論理的な認証サービスを経って分類された領域とすることができる。したがって、Ｄ-ＩＤは、物理的な領域に従ってドメインを分類する情報又は論理的なサービスに従ってドメインを分類する情報となる。
【００７３】
ＤＥ-ＩＤは、ドメインに属する別個のデバイスを識別するための情報である。
一方、ドメインペイロードは、一般データ及びエラーチェック情報を記録するためのフィールドである。このとき、一般データは、デバイス及びＤＲＭ信頼性システムの情報を表す。また、エラーチェック情報は、ＤＰＤＵパケットのエラーを確認するための情報を表すことができる。
【００７４】
これまで説明したように、ＤＰＤＵは、ドメインに加入したデバイスの能力を互いに区別する情報を含む。したがって、ＤＰＤＵがドメインのデバイス間で交換され、能力が互いに比較される。したがって、有能な装置を選択することができ、有能な装置をレファレンスポイントコントローラとして決定することができる。以下、上記プロセスを詳細に説明する。
【００７５】
図７は、ＤＰＤＵを用いることによってレファレンスポイントコントローラを自動的に選択する手順を示すフローチャートである。
【００７６】
図７を参照すると、手順が開始されると、ドメインに加入するデバイス(例えば、クライアントデバイス)は、ＤＣ-ＩＤ値Ｘ、Ｄ-ＩＤ値Ｙ及びＤＥ-ＩＤ値Ｚを所定の値に設定する(段階Ｓ１)。
【００７７】
このとき、ＤＣ-ＩＤ設定値は、所定の基準に従って割り当てられ又は対応するデバイスで生成される。二つの場合を、以下で個別に説明する。
【００７８】
１．ＤＣ-ＩＤ値が所定の基準に従ってアドミニストレータにより割り当てられる場合
アドミニストレータは、所定の管理装置を用いることによって各装置の能力情報を認識し、能力情報を所定の基準に従って能力値に変換し、能力値をデバイスのＤＣ−ＩＤ値に割り当てる。このとき、管理装置を、ドメインの所定のデバイス、他の通信可能な位置に配置されたデバイス又はネットワークエリアの所定のシステム(例えば、ドメインマネージャ)とすることができる。
【００７９】
例えば、ＤＣ-ＩＤ値を、エネルギー残量に基づいて決定する場合、アドミニストレータは、ドメインの各デバイスのバッテリー残量を確認し、バッテリー残量を、所定の基準に従って数値として表し、ＤＣ-ＩＤ値をデバイスに割り当てる。その後、デバイスのＤＣ-ＩＤ値が決定され、すなわち、デバイスＡのＤＣ−ＩＤ値を４とし、デバイスＢのＤＣ-ＩＤ値を８とし、デバイスＣのＤＣ-ＩＤを２とする。
【００８０】
２．ＤＣ-ＩＤ値が対応するデバイスを介して生成される場合
各デバイスは、能力情報を認識し、能力情報は、予め格納された情報に従って能力値に変換され、能力をＤＣ−ＩＤ値に設定する。
【００８１】
例えば、ＤＣ-ＩＤ値を、エネルギー残量に基づいて決定する場合、デバイスは、ドメインの各デバイスのバッテリー残量を確認し、バッテリー残量を、予め格納されたバッテリーエネルギー残量マッピングテーブルに従って数値として表し、ＤＣ-ＩＤ値を生成する。その後、デバイスのＤＣ-ＩＤ値が決定され、すなわち、デバイスＡのＤＣ−ＩＤ値を４とし、デバイスＢのＤＣ-ＩＤ値を８とし、デバイスＣのＤＣ-ＩＤを２とする。このとき、バッテリーエネルギー残量マッピングテーブルを、管理装置から受け取り、格納することができる。また、製品製造時にバッテリーエネルギー残量マッピングテーブルを格納することができる。
【００８２】
例 １-１において、バッテリー容量が大きくなるに従ってＤＣ-ＩＤ値を小さく設定すると仮定する。この場合、ＤＣ-ＩＤ値が小さくなるに従ってデバイスは高い能力を有する。しかしながら、本発明はこれに限定されない。バッテリー容量が小さくなるに従ってＤＣ-ＩＤ値を小さく設定することもできる。
【００８３】
また、上記デバイスの能力を、エネルギー残量に加えて、ハードウェア仕様、ネットワーク接続速度、ネットワーキング能力、外部への移動可能性、システムの安定性、計算能力、資源消耗量等によって構成することができる。ＤＣ-ＩＤ値を、簡単な数ではなく多様な形態の情報とすることができる。
【００８４】
一方、Ｄ-ＩＤは、デバイスが加入するドメインを表示するための固有の数又は情報データとして設定される。また、各デバイスのＤＥ-ＩＤ値は、デバイスを互いに区別するコードとして初期化される。Ｄ-ＩＤ値及びＤＥ-ＩＤ値を、アドミニストレータによって割り当てることができ、又は、対応する装置によって生成することができる。
【００８５】
これまで説明したように、各デバイスに対してＤＣ-ＩＤ及びＤ-ＩＤの設定が完了すれば、デバイスは、設定された情報を含むＤＰＤＵを隣接デバイスに順次にブロードキャストし又はマルチキャストする(段階Ｓ２)。
【００８６】
その後、デバイスは、他のデバイスから伝送されるＤＰＤＵを受信することができる(段階Ｓ３)。所定のデバイスがＤＰＤＵを受信すれば、対応するデバイスは、受信したＤＰＤＵのドメインヘッダーに含まれたＤＣ-ＩＤ値Ｖを抽出し(段階Ｓ４)、抽出したＤＣ−ＩＤ値を装置のＤＣ-ＩＤ値Ｘと比較する(段階Ｓ５)。一方、ＤＰＤＵを受信しなかった場合、設定された時間Ｔ１が経過したか否かを判断する(段階Ｓ１２)。Ｖは、他のデバイスから受信したＤＰＤＵのＤＣ-ＩＤ値を表す。ＤＰＤＵを送信するデバイスにおいて、ＤＣ-ＩＤ値をＸとすることができる。
【００８７】
ＤＣ-ＩＤ値の比較結果として、装置のＤＣ-ＩＤ値が、受信したＤＣ-ＩＤ値より小さい場合、デバイスは、受信したＤＣ-ＩＤ値を破棄する(段階Ｓ６)。この場合、この理由は、ＤＣ-ＩＤを受信するデバイスがＤＣ-ＩＤを送信するデバイスより大きいエネルギー容量すなわち高い機能を有するからである。
【００８８】
一方、ＤＣ-ＩＤ値の比較結果として、自分のＤＣ-ＩＤ値が、受信したＤＣ-ＩＤ値より大きい場合、デバイスは、受信したＤＰＤＵのドメインヘッダーに含まれたＤ-ＩＤ情報Ｗを抽出し(段階Ｓ７)、抽出したＤ−ＩＤ情報Ｗがそれ自体のＤ-ＩＤ情報Ｙと同一であるか否か検査する(段階Ｓ８)。受信したＤ-ＩＤ情報を検査することによって、レファレンスポイントコントローラを同一ドメインで一つずつ選択することができる。Ｗは、他のデバイスから受信したＤＰＤＵのＤ-ＩＤ値を表す。ＤＰＤＵを送信するデバイスにおいて、ＤＣ-ＩＤ値をＹとすることができる。
【００８９】
Ｄ-ＩＤの検査結果として、受信したＤ-ＩＤが自身のＤ-ＩＤと同一であるとき、デバイスは、ＤＰＤＵのブロードキャストを中止する(段階Ｓ９)。この理由は、高い能力値を有するデバイスが同一ドメインに配置されているからである。これは、デバイスがレファレンスポイントコントローラの選択で脱落したことを表す。
【００９０】
一方、上記Ｄ-ＩＤの検査結果として、受信したＤ-ＩＤが自身のＤ-ＩＤと異なるとき、デバイスは、受信したＤＰＤＵが他のドメインのデバイスから受信したＤＰＤＵであるとみなし、ＤＰＤＵを連続的にブロードキャストする。このとき、デバイスは、ＤＰＤＵを他のデバイスに伝送し、設定された時間Ｔ２を経過したか否か確認する(段階Ｓ１０)。
【００９１】
このとき、設定された時間Ｔ２以内にＤＰＤＵをこれ以上受信しない場合又はＤＣ−ＩＤがデバイスのＤＣ-ＩＤ値より少なく、かつ、Ｄ-ＩＤがデバイスのＤ−ＩＤと同一であるＤＰＤＵを受信しない場合、デバイスは、ドメインで最高能力を有する。したがって、デバイスは、一つのドメインを代表するレファレンスポイントコントローラとして選択される(段階Ｓ１１)。レファレンスポイントコントローラとして選択されたデバイスは、デバイスがレファレンスポイントコントローラとして選択されたことをドメインマネージャに報告する。ここでは、登録手順を、図１３を参照して説明する。
【００９２】
レファレンスポイントコントローラ機能を実行することができるソフトウェアを、レファレンスポイントコントローラとして選択されたデバイスにインストールすることができる。ソフトウェアは、ディスエーブル状態でデバイスに予めインストールされる。デバイスがレファレンスポイントコントローラとして選択されるとき、ソフトウェアは、ドメインマネージャの命令に従ってイネーブルされ及び確立される。また、ドメインマネージャ又は他のデバイスは、レファレンスポイントコントローラの機能を実行することができるソフトウェアを、選択されたデバイスにアップロードすることができる。レファレンスポイントコントローラを選択する手順に加わるドメインデバイスがレファレンスポイントコントローラの機能を実行する基本条件を満足すると仮定する。このとき、基本条件は、ディスエーブルされたソフトウェアが含まれること又はレファレンスポイントコントローラの機能を実行するソフトウェア仕様のハードウェアを満足することを表す。
【００９３】
これまで説明したように、レファレンスポイントコントローラの選択に関連した例 １-１によれば、デバイス間でＤＰＤＵデータパケットを交換することによって、最高能力のデバイスをリファレンスポイントコントローラとして選択することができる。ＤＣ-ＩＤを介した能力の設定、能力の比較等を、本発明の範囲を逸脱することなく変更することができる。
【００９４】
<例 １-２>
以下、レファレンスポイントコントローラ選択方法の他の例である例 １-２を説明する。
【００９５】
例 １-２のレファレンスポイントコントローラ選択方法において、ドメインに登録することを所望するデバイス(例えば、クライアントデバイス)は、デバイスのデバイス情報をドメインマネージャに報告し、ドメインマネージャは、報告されたデバイス情報に基づいてレファレンスポイントコントローラを選択する。このとき、デバイス情報は、デバイスが加入するドメインの情報、デバイスの能力の情報、デバイスの識別情報等を含むことができる。例えば、デバイス情報をＤＰＤＵとすることができる。
【００９６】
図８は、例 １-２に従ってレファレンスポイントコントローラを選択する方法を示すフローチャートである。
【００９７】
図８を参照すると、手順が開始されると、ドメインに加入するデバイスは、ＤＣ-ＩＤ値Ｘ、Ｄ-ＩＤ値Ｙ及びＤＥ-ＩＤ値Ｚを所定の値に設定する(段階Ｓ２０)。このとき、ＤＣ-ＩＤの設定値を、所定の基準に従って割り当て又は対応するデバイスによって生成する。
【００９８】
例えば、ＤＣ-ＩＤ値の基準がデバイスに内蔵された中央処理ユニット(ＣＰＵ)の仕様であるとき、各デバイスのＤＣ-ＩＤ値は、アドミニストレータによって割り当てられる。また、各デバイスのＤＣ-ＩＤ値は、生成された能力値として設定される。例えば、デバイスＡのＤＣ-ＩＤ値を４に設定し、デバイスＢのＤＣ-ＩＤ値を２に設定し、デバイスＣのＤＣ-ＩＤ値を３に設定し、デバイスＤのＤＣ-ＩＤ値を８に設定する。
【００９９】
このとき、ＣＰＵの仕様が高くなるに従ってＤＣ-ＩＤ値が小さくなると仮定する。具体的には、ＤＣ-ＩＤ値が小さくなるに従ってデバイスは高い能力を有する。しかしながら、本発明は、それに限定されない。バッテリー容量が少なくなるに従ってＤＣ-ＩＤ値が小さく設定されると仮定することもできる。また、実行環境に従って、ＣＰＵ以外のハードウェアの情報、エネルギー情報等を、多様な形態のデバイスの能力に適用することができる。
【０１００】
Ｄ-ＩＤは、デバイスが加入するドメインを表示するための固有の数又は情報データとして設定される。また、各デバイスのＤＥ-ＩＤ値は、デバイスを互いに区別するコードとして初期化される。Ｄ-ＩＤ値及びＤＥ-ＩＤ値を、アドミニストレータによって割り当てることができ、又は、対応する装置によって生成することができる。
【０１０１】
これまで説明したように、各デバイスに対してＤＣ-ＩＤ及びＤ-ＩＤの設定が完了すれば、デバイスは、設定された情報を含むＤＰＤＵをドメインマネージャに伝送する (段階Ｓ２１)。ＤＰＤＵを、所定の時間内に伝送することができる。ドメインマネージャは、所定の時間中にスタンバイ状態を維持する。所定の時間が超過したとき、ドメインマネージャは、これ以上ＤＰＤＵを受信しない。
【０１０２】
ドメインマネージャは、デバイスから受信したＤＰＤＵのドメインヘッダーに含まれるＤＣ-ＩＤ値を互いに比較し(段階Ｓ２２)、最小のＤＣ-ＩＤ値を有するデバイスすなわち最高能力を有するデバイスを抽出する(段階Ｓ２３)。最高能力を有するデバイスが抽出されると、ドメインマネージャは、デバイスのＤ-ＩＤを検査し(段階Ｓ２４)、Ｄ−ＩＤが新たに形成されるドメインのＩＤと同一であるか否か検査する。Ｄ−ＩＤが新たに形成されるドメインのＩＤと同一である場合、デバイスをレファレンスポイントコントローラとして選択する(段階Ｓ２５)。例 １-１で説明したように、レファレンスポイントコントローラの機能を、レファレンスポイントコントローラとして選択されたデバイスにインストールすることができる。
【０１０３】
Ｄ-ＩＤの検査の結果として、デバイスのＤ-ＩＤが新たに形成されるドメインのＩＤでない場合、対応するデバイス以外のデバイスのＤＣ-ＩＤ値を互いに比較し、最高能力を有するデバイスを検索する。最高能力を有するデバイスを、レファレンスポイントコントローラとして選択することができる。
【０１０４】
一方、上記例 １-２において、レファレンスポイントコントローラを、各デバイスの能力に基づいて選択する。レファレンスポイントコントローラを、能力に加えて、器所運情報との整合の程度、ユーザの設定等に基づいて選択することもできる。
【０１０５】
例えば、ドメインに登録することを所望するデバイスが、デバイスのハードウェア仕様の情報を含むデバイス情報をドメインマネージャに伝送するとき、ドメインマネージャは、伝送されたデバイス情報と所定の仕様情報とを比較することによって最適なデバイスを選択することができる。また、ドメインマネージャは、各デバイスから伝送されたデバイス情報のうちユーザによって予め決定されたデバイス情報と一致するデバイスをレファレンスポイントコントローラとして選択することができる。
【０１０６】
<例 １-３>
例 １-３に従ってレファレンスポイントコントローラを選択する方法において、レファレンスポイントコントローラは、アドミニストレータ若しくはユーザによって予め設定され又は任意に設定された設定情報に基づいてレファレンスポイントコントローラを選択する。例えば、アドミニストレータ又はユーザが設定情報をドメインマネージャに入力すると、ドメインマネージャは、設定情報に基づいてレファレンスポイントコントローラを選択することができる。アドミニストレータ又はユーザは、レファレンスポイントコントローラとしてユーザに用いられるデバイスを直接選択するとともにレファレンスポイントコントローラを確立することができる。したがって、例 １-３において、アドミニストレータ又はユーザによって所望されるデバイス又は任意のデバイスを、レファレンスポイントコントローラとして選択する。
【０１０７】
ドメインを最初に構成するときにローカルエリアの範囲を決定するレファレンスポイントコントローラを選択する方法を、例 １-１〜例 １-３によって説明した。レファレンスポイントコントローラを選択するとき、クライアントがローカル状態でドメインに加入するローカルエリアの範囲を、レファレンスポイントコントローラによって決定することができる。
【０１０８】
一方、ドメインマネージャ又はライセンスマネージャは、ローカルエリア又は外部ネットワークエリアのあらゆる位置に存在することができる。ドメインマネージャ又はライセンスが外部ネットワークに存在するとき、ドメインと信頼性のある情報のやりとりを行うセキュアな通信手段をサポートする必要である。
【０１０９】
一方、レファレンスポイントコントローラが、ローカルエリアでローカルエリアの範囲及び環境を決定するエンティティであるので、レファレンスポイントコントローラは、ドメインマネージャ又はライセンスマネージャとは違ってローカルエリアに存在する必要がある。このとき、レファレンスポイントコントローラは、レファレンスポイントコントローラが正常に動作することを確認するために周期的かつ連続的にドメインマネージャと情報信号のやりとりを行う。
【０１１０】
ドメインマネージャが、所定の時間中にレファレンスポイントコントローラから何らの情報信号を受信しないとき、これは、レファレンスポイントコントローラが正常に動作しないことを表す。具体的には、レファレンスポイントコントローラが動かなくなる。また、レファレンスポイントコントローラが外部の通信不能地域に入るときにも、レファレンスポイントコントローラが動かなくなる。
【０１１１】
この場合、ドメインに加入したローカルエリアのクライアントデバイスは、コンテンツを正常に使用できないことがある。実際には、レファレンスポイントコントローラを携帯電話、携帯端末（ＰＤＡ）等にインストールすることができるので、レファレンスポイントコントローラが外部の通信不能地域に入ることがある。この場合、レファレンスポイントコントローラが機能不全になることがある。
【０１１２】
したがって、本発明において、レファレンスポイントコントローラの機能不全に備える方法を開示する。先ず、レファレンスポイントコントローラ候補の概念が導入される。レファレンスポイントコントローラ候補は、レファレンスポイントコントローラが機能不全であるときにレファレンスポイントコントローラを置換するデバイスを表す。レファレンスポイントコントローラ候補を、ドメインを最初に構成したときに選択し又はドメインを構成した後にドメインマネージャに従って選択することができる。
【０１１３】
-レファレンスポイントコントローラ候補の選択及び動作-
レファレンスポイントコントローラ候補を選択する四つの方法がある。
【０１１４】
ドメインのデバイスのうちの現在のレファレンスポイントコントローラを除くデバイスがデバイス情報を互いにやりとりする第１の方法がある。デバイス情報は、所定のアルゴリズム、例えば、例 １-１で説明したアルゴリズムに基づいて互いに比較され、レファレンスポイントコントローラ候補が選択される。例えば、能力がデバイス間でやりとりされる。最高能力を有するデバイスが、レファレンスポイントコントローラ候補として選択される。選択されたレファレンスポイントコントローラ候補は、デバイスがレファレンスポイントコントローラ候補として選択されたことをドメインマネージャに報告する。
【０１１５】
上記例 １-２によるレファレンスポイントコントローラの選択と同様に、ドメインのデバイスがデバイスのデバイス情報(例えば、能力を含むＤＰＤＵ)をドメインマネージャに提供し、ドメインマネージャがデバイス情報に基づいてレファレンスポイントコントローラ候補を選択する第２の方法がある。
【０１１６】
ドメインのデバイスがデバイスのデバイス情報をレファレンスポイントコントローラに提供し、レファレンスポイントコントローラがレファレンスポイントコントローラ候補をデバイス情報に基づいて選択する第３の方法がある。この場合、レファレンスポイントコントローラ候補が選択されると、レファレンスポイントコントローラは、選択されたレファレンスポイントコントローラ候補の情報をドメインマネージャに報告する必要がある。
【０１１７】
レファレンスポイントコントローラ候補を所定の情報に基づいて選択する第４の方法がある。このとき、所定の情報をアドミニストレータ又はユーザによって設定することができる。所定の情報は、任意に設定された情報を含むことができる。
【０１１８】
以下、上記四つの方法を詳細に説明する。理解の便宜のために、レファレンスポイントコントローラ候補を選択する上記第１の方法を、例 ２-１と称する。レファレンスポイントコントローラ候補を選択する上記第２の方法を、例 ２-２と称する。レファレンスポイントコントローラ候補を選択する上記第３の方法を、例 ２-３と称する。レファレンスポイントコントローラ候補を選択する上記第４の方法を、例 ２-４と称する。
【０１１９】
<例 ２-１>
図９は、例 ２-１に従ってレファレンスポイントコントローラ候補を選択する手順を示すフローチャートである。図９は、デバイスの能力を用いることによってレファレンスポイントコントローラを自動的に選択する手順を示す。
【０１２０】
例 ２-１に従ってレファレンスポイントコントローラ候補を選択する手順を、レファレンスポイントコントローラを選択する手順を終了した後にドメインを構成するときに開始することができる。また、例 ２-１に従ってレファレンスポイントコントローラ候補を選択する手順を、ドメインを構成した後にいつでもドメインマネージャのようなエンティティの開始命令に従って開始することもできる。
【０１２１】
図９に示すように、プロスィージャを開始すると、ドメインのデバイスのうちのレファレンスポイントコントローラを除くデバイスがデバイス情報を設定する(段階Ｓ３０)。
【０１２２】
デバイス情報は、能力情報、ドメイン情報、デバイス識別情報等を含むことができる。ここで、能力情報は、デバイスのエネルギー残量、ハードウェア仕様、ネットワーク接続速度、外部への移動可能性、システムの安定性等の情報を含むことができる。また、能力情報は、ＤＣ-ＩＤの値のような数値であってもよい。また、能力情報は、多様な形態の情報であってもよい。
【０１２３】
各デバイスに対するデバイス情報(能力情報、ドメイン情報、デバイス識別情報)の設定が完了すると、デバイスは、設定された情報を規格化されたパケットで作成し、例えば、デバイスは、設定された情報をＤＰＤＵに挿入し、ＤＰＤＵを他のデバイスに順次にブロードキャスト又はマルチキャストする(段階Ｓ３１)。
【０１２４】
その後、各デバイスは、他のデバイスから伝送される規格化されたパケットを受信し(段階Ｓ３２)、受信したパケットに含まれる能力情報をデバイスの能力情報と比較し(段階Ｓ３３)、一方のデバイス（パケットを送信するデバイス又はパケットを受信するデバイス）を選択中に脱落させる(段階Ｓ３４)。
【０１２５】
例えば、パケットを受信するデバイスは、受信したパケットの能力情報とデバイスの能力情報とを比較する。受信したパケットの能力情報がデバイスの能力より高い場合、デバイスは、ＤＰＤＵのブロードキャストを中止する。すなわち、パケットを受信するデバイスが、レファレンスポイントコントローラ候補の選択中に脱落する。このとき、パケットを送信するデバイスが受信したパケットの情報からパケットを受信するデバイスと同一のドメインに存在するか否かを検査する手順も実行することができる。一方、受信したパケットの能力情報がデバイスの能力より低い場合、パケットを破棄する。すなわち、パケットを送信するデバイスをレファレンスポイントコントローラ候補の選択中に脱落させる。
【０１２６】
最終的には、最高能力を有するデバイスのみが上記手順を介して残る (段階Ｓ３５)。その後、残ったデバイスがレファレンスポイントコントローラ候補として選択される(段階Ｓ３６)。選択されたデバイスは、デバイスがレファレンスポイントコントローラ候補として選択されたことをドメインマネージャに報告する。
【０１２７】
ドメインマネージャは、選択したレファレンスポイントコントローラ候補の情報を管理する。レファレンスポイントコントローラにエラーが発生すると、レファレンスポイントコントローラ候補を新たなレファレンスポイントコントローラとして使用することができる。
【０１２８】
一方、複数のレファレンスポイントコントローラ候補を優先順位に従ってドメインマネージャに登録することができる。具体的には、第１のレファレンスポイントコントローラ候補を選択する手順を実行し、第１のレファレンスポイントコントローラ候補を登録する。第２のレファレンスポイントコントローラ候補を選択する手順を実行し、第２のレファレンスポイントコントローラ候補を登録する。上記手順を繰り返し実行し、所望の数のレファレンスポイントコントローラ候補を登録することができる。
【０１２９】
このように複数のレファレンスポイントコントローラ候補が登録されるとき、レファレンスポイントコントローラを優先順位に従って置換することができる。このとき、登録された複数のレファレンスポイントコントローラ候補は、レファレンスポイントコントローラ候補が正常に動作することを周期的に確認する必要がある。確認の手順を後に詳細に説明する。
【０１３０】
<例 ２-２>
例 ２-２に従ってレファレンスポイントコントローラ候補を選択する方法において、ドメインのデバイスは、デバイスのデバイス情報をドメインマネージャに報告し、ドメインマネージャは、報告されたデバイス情報に基づいてレファレンスポイントコントローラ候補を選択する。
【０１３１】
この方法は、例 １-２によるレファレンスポイントコントローラ選択の概念と類似する。例 １-２において、ドメインに加入するデバイスは、デバイスのデバイス情報をドメインマネージャに報告し、ドメインマネージャは、報告されたデバイス情報に基づいて最適なデバイスを選択し、選択したデバイスをレファレンスポイントコントローラとして登録する。
【０１３２】
例 ２-２において、レファレンスポイントコントローラ以外のドメインのデバイスは、デバイスのデバイス情報をドメインマネージャに提供し、ドメインマネージャは、報告されたデバイス情報に基づいて最適なデバイスを選択し、選択したデバイスをレファレンスポイントコントローラ候補として登録する。
【０１３３】
このとき、デバイス情報は、所定の基準に従ってデバイスの能力を表す能力情報を含むことができる。ドメインマネージャは、デバイスから提供される能力情報に基づいて能力の低くなる順序で優先順位をデバイスに割り当てることによってデバイスを登録することができる。
【０１３４】
例えば、ドメインマネージャは、各デバイスの能力情報に従って、レファレンスポイントコントローラを最初に置換することができる第１レファレンスポイントコントローラ候補、第２レファレンスポイントコントローラ候補及び第３レファレンスポイントコントローラ候補の順序で複数のレファレンスポイントコントローラ候補を選択し及び登録することができる。複数のレファレンスポイントコントローラ候補が登録されると、レファレンスポイントコントローラ候補は、割り当てられた優先順位でレファレンスポイントコントローラを置換することができる。
【０１３５】
一方、レファレンスポイントコントローラ候補を選択する手順を、レファレンスポイントコントローラを選択した後に実行することができる。レファレンスポイントコントローラ候補を、例 １-２で開示すレファレンスポイントコントローラを選択する手順を実行するときに実行環境に従って選択することができる。すなわち、第１レファレンスポイントコントローラ候補、第２レファレンスポイントコントローラ候補等を、レファレンスポイントコントローラを選択するときに選択する。例えば、ドメインに加入するデバイスは、ドメインを構成するときに能力情報をドメインマネージャに報告し、ドメインマネージャは、報告された能力に基づいて、レファレンスポイントコントローラ、第１レファレンスポイントコントローラ候補、第２レファレンスポイントコントローラ候補等を選択することができる。
【０１３６】
<例 ２-３>
例 ２-３に従ってレファレンスポイントコントローラ候補を選択する方法において、ドメインのデバイスは、デバイスのデバイス情報をレファレンスポイントコントローラに報告し、レファレンスポイントコントローラは、報告されたデバイス情報に基づいてレファレンスポイントコントローラ候補を選択する。
【０１３７】
例 ２-３に従ってレファレンスポイントコントローラ候補を選択する方法は、レファレンスポイントコントローラがレファレンスポイントコントローラ候補を選択する点を除いて例 ２-２に従ってレファレンスポイントコントローラ候補を選択する方法と実質的に同一である。
【０１３８】
レファレンスポイントコントローラに報告されるデバイス情報は、デバイスの能力を表す能力情報を含むことができる。レファレンスポイントコントローラは、デバイスから提供される能力情報に基づいて能力の低くなる順序で優先順位をデバイスに割り当てることによってデバイスを登録することができる。例えば、レファレンスポイントコントローラは、各デバイスの能力情報に従って、レファレンスポイントコントローラを最初に置換することができる第１レファレンスポイントコントローラ候補、第２レファレンスポイントコントローラ候補及び第３レファレンスポイントコントローラ候補の順序で複数のレファレンスポイントコントローラ候補を選択し及び登録することができる。複数のレファレンスポイントコントローラ候補が登録されると、レファレンスポイントコントローラ候補は、割り当てられた優先順位でレファレンスポイントコントローラを置換することができる。
【０１３９】
一方、レファレンスポイントコントローラ候補が選択されると、レファレンスポイントコントローラは、選択したレファレンスポイントコントローラ候補をドメインマネージャに登録する。また、複数のレファレンスポイントコントローラ候補が優先順位に従って選択されるときでも、レファレンスポイントコントローラは、選択履歴をドメインマネージャに報告する。したがって、レファレンスポイントコントローラが機能不全になり又は長時間通信不能領域に入るときでも、レファレンスポイントコントローラ候補は、レファレンスポイントコントローラを置換する。したがって、サービスが正常に提供される。
【０１４０】
<例 ２-４>
例 ２-４に従ってレファレンスポイントコントローラ候補を選択する方法において、レファレンスポイントコントローラ候補は、アドミニストレータ若しくはユーザによって予め設定され又は任意に設定された設定情報に基づいて選択される。例えば、アドミニストレータ又はユーザがドメインマネージャ又はレファレンスポイントコントローラに設定情報を入力すると、ドメインマネージャ又はレファレンスポイントコントローラは、設定情報に基づいてレファレンスポイントコントローラ候補を選択することができる。
【０１４１】
設定情報は、優先順位が割り当てられた複数のレファレンスポイントコントローラ候補の情報を含むことができる。具体的には、ドメインマネージャ又はレファレンスポイントコントローラは、設定情報に含まれる優先順位に従って複数のレファレンスポイントコントローラ候補を選択することができる。例えば、デバイスＡを、第１のレファレンスポイントコントローラ候補として選択するとともに登録し、デバイスＢを、第２のレファレンスポイントコントローラ候補として選択するとともに登録する。レファレンスポイントコントローラにエラーが発生すると、第１のレファレンスポイントコントローラ候補がレファレンスポイントコントローラを置換することができる。第１のレファレンスポイントコントローラ候補にエラーが発生すると、第２のレファレンスポイントコントローラ候補が第１のレファレンスポイントコントローラ候補を置換することができる。
【０１４２】
ドメインを構成するときにドメインマネージャがレファレンスポイントコントローラ候補を選択する場合、ドメインマネージャは、レファレンスポイントコントローラを選択すると同時にレファレンスポイントコントローラ候補を所定の優先順位に従って指定する。その後、レファレンスポイントコントローラが機能不全になると、柔軟かつ迅速にエラーに対処することができる。一方、レファレンスポイントコントローラを選択した後にレファレンスポイントコントローラがレファレンスポイントコントローラ候補を選択する場合、レファレンスポイントコントローラは、設定情報に基づいてレファレンスポイントコントローラを置換するために候補を指定することができる。
【０１４３】
一方、アドミニストレータ又はユーザは、ドメインマネージャ又はレファレンスポイントコントローラを用いることなくレファレンスポイントコントローラ候補として用いられるデバイスを直接選択することができる。この場合、選択されたレファレンスポイントコントローラ候補は、デバイスがレファレンスポイントコントローラ候補として選択されたことをドメインマネージャに報告する必要がある。
【０１４４】
レファレンスポイントコントローラ候補を選択する方法を、例 ２-１〜例 ２-４によって説明した。レファレンスポイントコントローラを選択する場合、レファレンスポイントコントローラにエラーが生じるときでも、レファレンスポイントコントローラ候補は、レファレンスポイントコントローラを置換することができる。また、複数のレファレンスポイントコントローラ候補を所定の優先順位によって設定することによって、ドメインのサービスに安定性及び柔軟性を確保することができる。
【０１４５】
レファレンスポイントコントローラ候補は、以下の機能を有することができる。
【０１４６】
１．レファレンスポイントコントローラの機能：例えば、所定のデバイスに対する近接測定、ドメインクレデンシャルの発行等。レファレンスポイントコントローラの機能は既に説明した。
【０１４７】
２．情報信号送受信機能：レファレンスポイントコントローラ候補は、レファレンスポイントコントローラ候補が正常に動作していることを知らせる情報信号を、所定のインタフェースを介してレファレンスポイントコントローラ等に送信する必要がある。
【０１４８】
３．未受信条件設定機能：情報信号の未受信を区別する条件を設定する機能。例えば、タイムアウト、カウントリミット、レンジリミット等を設定することができる。
【０１４９】
４．ドメインマネージャへの報告機能：ドメインマネージャとの通信のためにデータ構造とインタフェースをサポートする機能。
【０１５０】
５．ダウンロード機能：ドメインマネージャ又は所定のサービス端末からエンティティ(ソフトウェア)をダウンロードするためにインタフェースをサポートする機能。
【０１５１】
一方、レファレンスポイントコントローラは、レファレンスポイントコントローラがドメインマネージャ又は他のデバイスに対して正常に動作していることを周期的に確認する必要がある。また、レファレンスポイントコントローラ候補は、レファレンスポイントコントローラ候補がドメインマネージャ又は他のデバイスに対して正常に動作していることを周期的に確認する必要がある。この理由は、レファレンスポイントコントローラ候補にエラーが発生するときにレファレンスポイントコントローラ候補がレファレンスポイントコントローラを置換することができないためである。
【０１５２】
図１０は、レファレンスポイントコントローラ及びレファレンスポイントコントローラ候補間の情報信号伝送のための接続を示すブロック図である。
【０１５３】
図１０に示すように、指定された情報信号送信ルートａ、ｂ、ｃが、ドメイン６のレファレンスポイントコントローラ７０とレファレンスポイントコントローラ候補７１、７２との間に形成される。情報信号送信ルートａ、ｂ、ｃは、デバイスが正常に動作するか否かを確認するために情報信号を伝送するルートを表す。
【０１５４】
例えば、情報信号伝送ルートａ、ｂ、ｃにおいて、レファレンスポイントコントローラ７０は、第１レファレンスポイントコントローラ候補７１に情報信号を伝送し、第１レファレンスポイントコントローラ候補７１は、第２レファレンスポイントコントローラ候補７２に情報信号を伝送する。また、第２レファレンスポイントコントローラ候補７２は、レファレンスポイントコントローラ７０に情報信号を伝送する。このとき、第１レファレンスポイントコントローラ候補７１は、１番目の優先順位のレファレンスポイントコントローラ候補を表し、第２レファレンスポイントコントローラ候補７２とは、２番目の優先順位のレファレンスポイントコントローラ候補を表す。
【０１５５】
安全な通信手段又はチャネルを情報信号伝送ルートａ、ｂ、ｃに設ける必要がある。安全な通信手段又はチャネルを形成するために、多様な暗号化方式を用いることができる。例えば、公開鍵方式、予め鍵を共有する方式、ドメインマネージャが鍵に対する情報をデバイスに提供する方式等を用いることができる。また、コンテンツ処理コントローラは、コンテンツエクスポータ、コンテンツトランスフォーマ及びコンテンツインポータ間にセキュリティ認証チャネルを生成するときに鍵の情報を提供することができる。
【０１５６】
伝送信号は、情報信号を伝送するために情報信号伝送ルートａ、ｂ、ｃを介して周期的に伝送される。伝送信号は、レファレンスポイントコントローラ又はレファレンスポイントコントローラ候補が正常に動作していることを証明する役割を果たす。伝送信号は、ドメイン情報、デバイス識別情報、システム情報、タイムアウト情報等を含むことができる。
【０１５７】
ここで、タイムアウト情報は、情報信号を正常に受信したか否かを決定するためのタイムリミットに関する。
【０１５８】
例えば、情報信号をタイムリミット内にレファレンスポイントコントローラ７０から受信しないとき、第１レファレンスポイントコントローラ候補７１は、レファレンスポイントコントローラ７０にエラーが発生したと判断する。第１レファレンスポイントコントローラ候補７１は、レファレンスポイントコントローラ７０にエラーが発生したこと及び第１レファレンスポイントコントローラ７０がレファレンスコントローラ７０を置換することをドメインマネージャ６０に報告する。その後、第１レファレンスポイントコントローラ候補７１は、レファレンスポイントコントローラ７０の機能を実行する。
【０１５９】
このとき、第１レファレンスポイントコントローラ候補７１は、レファレンスポイントコントローラの機能実行に必要な情報及びツールをドメインマネージャ６０又は他の端末から受け取ることができる。例えば、第１レファレンスポイントコントローラ候補７１は、レファレンスポイントコントローラの機能を実行するソフトウェアをダウンロード及びインストールし、又はインストールされたディスエーブルなソフトウェアをイネーブルすることができる。
【０１６０】
他の例において、レファレンスポイントコントローラ７０が、タイムリミット内に第２レファレンスポイントコントローラ候補７２から情報信号を受信しないとき、レファレンスポイントコントローラ７０は、第２レファレンスポイントコントローラ候補７２にエラーが発生したと判断し、第２レファレンスポイントコントローラ候補７２にエラーが発生したことをドメインマネージャ６０に報告する。その後、第２レファレンスポイントコントローラ候補７２より下の優先順位を有するレファレンスポイントコントローラ候補、例えば、第３レファレンスポイントコントローラ候補(図示せず)が、第２レファレンスポイントコントローラ候補７２を置換することができる。レファレンスポイントコントローラ候補を選択する上記手順(例 ２-１〜例 ２-４)によって、優先順位を新たに再構成することができる。
【０１６１】
一方、図１０に示す例において、レファレンスポイントコントローラ７０及びレファレンスポイントコントローラ候補７１、７２間の情報信号伝送を介してデバイスにエラーが発生したか否かを判断している。本発明は、これに限定されない。図１１に示すように、レファレンスポイントコントローラ７０及びレファレンスポイントコントローラ候補７１、７２がｅ、ｆ、ｃルートを介して情報信号をドメインマネージャ６０に直接伝送することができる。他の例において、レファレンスポイントコントローラ７０は、情報信号をドメインマネージャ６０に直接伝送し、レファレンスポイントコントローラ候補７１、７２は、所定のルートを介して情報信号を互いに伝送することができる。すなわち、情報信号の伝送ルートを、実行環境に従って様々に変更することができる。
【０１６２】
これまで説明したように、レファレンスポイントコントローラ７０及びレファレンスポイントコントローラ候補７１、７２は、情報信号を用いることによってレファレンスポイントコントローラ７０及びレファレンスポイントコントローラ候補７１、７２が正常に動作しているか否かを周期的に確認する。レファレンスポイントコントローラ７０が置換され、又は、レファレンスポイントコントローラ候補７１、７２の優先順位を、情報信号を受信したか否かに応じて再構成することができる。
【０１６３】
一方、一つのレファレンスポイントコントローラによって決定されるローカルエリアの範囲は、ポリティカルな理由等によって物理的又は論理的に制限される。しかしながら、ユーザは、現在設定されたローカルエリアの範囲より更に拡張された範囲のコンテンツサービスを利用することを所望することができる。したがって、ローカルエリアの範囲の制限を維持しながらサービスエリアを拡張することができる方法が要求される。
【０１６４】
本発明において、レファレンスポイントコントローラプロキシの概念を導入する。レファレンスポイントコントローラプロキシは、レファレンスポイントコントローラの代わりにレファレンスポイントコントローラの機能を実行するデバイスを表す。レファレンスポイントコントローラプロキシは、ドメインを拡張するとき又はレファレンスポイントコントローラが一時的に外部に移動するときに必要とされる。
【０１６５】
-レファレンスポイントコントローラプロキシの選択及び動作-
図１２は、レファレンスポイントコントローラプロキシの概念を説明するためのブロック図である。図１２は、ドメインＡにドメインＡ'を追加した例を示す。
【０１６６】
図１２に示すように、ドメインＡ８６に加入することができるローカルエリアの範囲及び環境は、レファレンスポイントコントローラ８２によって決定される。サービスエリアが拡張され又はレファレンスポイントコントローラ８２が一時的にローカルエリアの外側に移動する場合、ドメインＡと同一の権限を有する拡張ドメイン、例えば、ドメインＡ'９６を生成する必要がある。
【０１６７】
ドメインＡ'９６に加入することができるローカルエリアの範囲及び環境を、レファレンスポイントコントローラプロキシ９２によって決定することができる。レファレンスポイントコントローラプロキシ９２は、ドメインＡ'９６でレファレンスポイントコントローラの機能を実行する。すなわち、レファレンスポイントコントローラプロキシ９２は、ドメインＡ'９６のレファレンスポイントである。ユーザは、ドメインＡ８６だけでなくドメインＡ'９６からもクライアントデバイス８４、９４を介してコンテンツサービスを受けることができる。
【０１６８】
レファレンスポイントコントローラプロキシ９２は、レファレンスポイントコントローラ及びレファレンスポイントコントローラ候補を選択する上記例で説明した手順を介して容易に選択される。すなわち、レファレンスポイントコントローラプロキシ９２を選択する方法は、以下の通りである。
【０１６９】
第１の方法において、ドメインＡ'９６に加入するデバイスがデバイス情報を互いにやり取りする。デバイス情報は、所定のアルゴリズム、例えば、例 １-１で説明したアルゴリズムに従って互いに比較される。レファレンスポイントコントローラプロキシ９２は、デバイス情報に基づいて選択される。例えば、能力がデバイス間でやり取りされる。最高能力を有するデバイスが、レファレンスポイントコントローラプロキシ９２として選択される。選択されたレファレンスポイントコントローラプロキシ９２は、デバイスがレファレンスポイントコントローラプロキシ９２として選択されたことをドメインマネージャ８０に報告する。
【０１７０】
第２の方法において、例 １-２に従ってレファレンスポイントコントローラを選択する概念と同様に、ドメインＡ'９６に加入するデバイスは、デバイスのデバイス情報(例えば、能力情報を含むＤＰＤＵ)をドメインマネージャ８０に提供し、ドメインマネージャ８０は、デバイス情報に基づいてレファレンスポイントコントローラプロキシ９２を選択する。
【０１７１】
第３の方法において、レファレンスポイントコントローラプロキシ９２を、アドミニストレータ若しくはユーザによって予め設定され又は任意に設定された設定情報に基づいて選択する。
【０１７２】
一方、レファレンスポイントコントローラプロキシ９２を選択するとき、レファレンスポイントコントローラプロキシ９２にエラーが発生する場合に備えるための候補を選択することができる。すなわち、レファレンスポイントコントローラプロキシ９２にエラーが発生するときにレファレンスポイントコントローラプロキシ９２を置換する候補を選択する。レファレンスポイントコントローラプロキシの候補を、たレファレンスポイントコントローラ候補を選択する上記手順を用いることによって容易に選択することができる。
【０１７３】
レファレンスポイントコントローラプロキシ９２の候補を選択する方法を、以下で説明する。
【０１７４】
第１の方法において、ドメインＡ'９６に加入するデバイスがデバイス情報を互いにやり取りする。デバイス情報は、所定のアルゴリズム、例えば、例 １-１で説明したアルゴリズムに従って互いに比較される。レファレンスポイントコントローラプロキシ９２及びレファレンスポイントコントローラプロキシ９２の候補は、デバイス情報に基づいて選択される。例えば、能力がデバイス間でやり取りされる。最高能力を有するデバイスが、レファレンスポイントコントローラプロキシ９２として選択される。次いで、レファレンスポイントコントローラプロキシ９２以外のデバイス間で能力をやり取りすることによって、レファレンスポイントコントローラプロキシの候補を選択する。レファレンスポイントコントローラプロキシの候補に優先順位が存在する。また、選択されたレファレンスポイントコントローラプロキシ９２及び選択されたレファレンスポイントコントローラプロキシ９２の候補は、装置がレファレンスポイントコントローラプロキシ９２及びレファレンスポイントコントローラプロキシ９２の候補として選択されたことをドメインマネージャ８０に報告する必要がある。
【０１７５】
第２の方法において、例 １-２に従ってレファレンスポイントコントローラを選択する概念と同様に、ドメインＡ'９６に加入するデバイスは、デバイスのデバイス情報(例えば、能力情報を含むＤＰＤＵ)をドメインマネージャ８０に提供し、ドメインマネージャ８０は、デバイス情報に基づいてレファレンスポイントコントローラプロキシ９２及びレファレンスポイントコントローラプロキシ９２の候補を選択する。このとき、レファレンスポイントコントローラプロキシ９２の候補に優先順位が存在する。
【０１７６】
第３の方法において、レファレンスポイントコントローラプロキシ９２及びレファレンスポイントコントローラプロキシ９２を優先順位に従って選択する。このとき、所定の情報を、アドミニストレータ又はユーザによって設定することができる。また、所定の情報は、任意に設定された情報を含むことができる。
【０１７７】
一方、レファレンスポイントコントローラプロキシ９２は、レファレンスポイントコントローラプロキシ９２が継続的かつ安定にサービスを提供していることをレファレンスポイントコントローラ８２に周期的に報告する必要がある。レファレンスポイントコントローラプロキシ９２は、所定の情報信号をレファレンスポイントコントローラ８２と周期的にやり取りする。所定の期間内に情報信号がやり取りされないとき、レファレンスポイントコントローラプロキシ９２が正常な状態ではない。したがって、ドメインＡ'９６を維持することができない。
【０１７８】
情報信号は、ドメインレファレンス情報、デバイス識別情報、タイムアウト情報、固有のシステム情報等を含むことができる。
【０１７９】
情報信号を、安全な通信手段又はチャネルが設けられた有線又は無線伝送路を介して伝送する必要がある。安全な通信手段又はチャネルを形成するために、多様な暗号化方法を用いることができる。例えば、公開鍵方法、予め鍵を共有する方法、ドメインマネージャが鍵の情報をデバイスに提供する方法等を用いることができる。また、情報信号を、レファレンスポイントコントローラとレファレンスポイントコントローラプロキシとの間だけでなく、レファレンスポイントコントローラとドメインマネージャとの間及びレファレンスポイントコントローラプロキシとドメインマネージャとの間でも継続的にやり取りすることできる。
【０１８０】
一方、ドメインＡ'９６をこれ以上維持する必要がないとき、ドメインＡ'９６を破棄する必要がある。この場合、情報信号を用いてドメインＡ'９６を破棄することができる。例えば、レファレンスポイントコントローラ８２又はドメインマネージャ８０は、レファレンスポイントコントローラプロキシ９２に情報信号を伝送するのを中止し又は破棄信号を伝送する。レファレンスポイントコントローラプロキシ９２が正常に動作しないので、レファレンスポイントコントローラプロキシ９２は破棄される。したがって、ドメインＡ'９６は自動に破棄される。
【０１８１】
-レファレンスポイントコントローラの登録-
以下、新たなレファレンスポイントコントローラを登録する手順を説明する。レファレンスポイントコントローラを登録する手順は、新たなドメインが生成されたとき又はレファレンスポイントコントローラを置換したときに実行することができる。
【０１８２】
図１３は、新たなレファレンスポイントコントローラを登録する手順を示すフローチャートである。
【０１８３】
図１３を参照すると、ドメインマネージャは、新たなレファレンスポイントコントローラとして登録されるデバイスからレファレンスポイントコントローラ認証要求を受信する。このとき、新たなレファレンスポイントコントローラとして登録されるデバイスを、レファレンスポイントコントローラを選択する上記手順から選択したデバイス、既存のレファレンスポイントコントローラを置換するレファレンスポイントコントローラ候補及びレファレンスポイントコントローラプロキシのうちのいずれか一つとすることができる。
【０１８４】
ドメインマネージャがレファレンスポイントコントローラ認証要求を受信すると、ドメインマネージャは、現存するレファレンスポイントコントローラメンバシップを無效化する。このとき、レファレンスポイントコントローラメンバシップは、レファレンスポイントコントローラが登録されるときにドメインマネージャによって生成される。レファレンスポイントコントローラメンバシップは、対応するエンティティがレファレンスポイントコントローラであることを確認する情報を表す。
【０１８５】
ドメインマネージャは、固有の新たなレファレンスポイントコントローラメンバシップを生成及び格納し、生成したレファレンスポイントコントローラメンバシップを、新たなレファレンスポイントコントローラメンバシップを提供することをドメインマネージャに要求するデバイスに転送する。このとき、ドメインマネージャは、レファレンスポイントコントローラメンバシップ及びドメインをペアで格納及び管理する。
【０１８６】
レファレンスポイントコントローラメンバシップを受信したデバイスは、レファレンスポイントコントローラメンバシップを格納する。デバイスは、レファレンスポイントコントローラとして登録される。格納されたレファレンスポイントコントローラメンバシップを、新たに登録されたレファレンスポイントコントローラが各種情報をドメインマネージャに提供し若しくは各種情報を提供することをドメインマネージャに要求するとき、又は、クライアントが認証されるときに、認証要素情報として用いることができる。また、レファレンスポイントコントローラメンバシップは、レファレンスポイントコントローラが維持される間に周期的に格納される。
【０１８７】
-クライアントを認証する方法-
以下、クライアントを認証する方法を説明する。図５を再び参照すると、クライアント３がドメイン５に加入するとき、ドメインマネージャ２２は、クライアント３に固有のクライアントメンバシップを生成する。クライアント３に与えられたクライアントメンバシップは、クライアントがドメイン５のメンバである限り継続的に格納される。クライアント３がドメイン５から脱退すると、ドメインマネージャ２２は、クライアントのクライアントメンバシップを所定の期間中に維持し、クライアントメンバシップを除去する。このとき、クライアント３がドメイン５から脱退するときでも、タイムアウト前に用いられたコンテンツは、所定の期間中に継続的に用いられる。所定の期間を、プロバイダのポリシーによって選択的に適用することができる。
【０１８８】
ドメイン５に加入するクライアント３がサービスを利用するために、クライアントは、クライアントが正常にドメイン５に加入したことを所定のエンティティに対して立証する必要がある。このために、クライアント３は、クライアント３を認証することをドメインマネージャ２２に要求する。クライアント３が、クライアント３を認証することをドメインマネージャ２２に要求するとき、クライアント３は、クリアクレデンシャル又はオートマティッククレデンシャルをドメインマネージャ２２に提出する必要がある。
【０１８９】
クリアクレデンシャルは、クライアント３に与えられたクライアントメンバシップ及びクリアドメインクレデンシャルを含む暗号化された情報である。このとき、クリアドメインクレデンシャルは、ドメイン５が生成されるときにドメインマネージャ２２によって生成される。ドメイン５を生成した後に、ドメインマネージャ２２は、生成したクリアドメインクレデンシャルを、ドメインを管理する各種トランザクションに適用する。
【０１９０】
オートマティッククレデンシャルは、レファレンスポイントコントローラメンバシップ及びクライアントメンバシップを含む暗号化された情報である。オートマティッククレデンシャルは、レファレンスポイントコントローラ２６によって提供されるドメインクレデンシャルを表すことができる。レファレンスポイントコントローラメンバシップは、レファレンスポイントコントローラ２６がドメイン５に登録されるときにドメインマネージャ２２によって生成される。レファレンスポイントコントローラメンバシップは、レファレンスポイントコントローラ２６が維持される間に継続的に格納される。オートマティッククレデンシャルは、クライアント３がローカルエリアに正常に存在するか否かについての情報であり、レファレンスポイントコントローラ２６によって保証される。したがって、ローカル状態のクライアント３は、オートマティッククレデンシャルを用いることができる。
【０１９１】
クライアント３が、クライアント３を認証することをドメインマネージャ２２に要求すると、ドメインマネージャ２２は、提出されたクレデンシャルが有效か否かを判別する。クライアント３がドメイン５に加入していないと判別されると、ドメインマネージャ２２はエラーを発生する。一方、クライアント３が正常にドメイン５に加入しているとき、ドメインマネージャ２２は、クライアント３を認証する。クライアント３は、許容された権限内でコンテンツを用いることができる。
【０１９２】
ドメインマネージャ２２は、クライアント３から提出された信任状がクリアクレデンシャルかオートマティッククレデンシャルかに応じてクライアント３がリモート状態かローカル状態かを認識し、クライアント３を管理する。既に説明したように、リモート状態は、クライアント３がローカルエリア外のネットワークエリアにアクセスする場合を表す。例えば、クライアント３は、インターネットを介してドメイン５にアクセスする。一方、ローカル状態は、クライアント３がローカルエリアに存在する場合を表す。レファレンスポイントコントローラ２６は、ホップ数を測定することによってローカル状態のクライアント３を検査することができる。クライアント３を、所定の手順を介してメンバとしてドメイン５に登録することできる。
【０１９３】
-レガシーデバイスの登録、認証及び管理-
クライアントデバイスに加えてレガシーデバイスもドメインにアクセスすることができる。このとき、レガシーデバイスは、ドメインのクライアントとして動作するエンティティが完全に搭載されていないデバイスを意味する。具体的には、クライアントの一部の機能のみを有するデバイス又はクライアントを含まないデバイスを、レガシーデバイスと称する。
【０１９４】
レガシーデバイスがドメインでサービスの提供を受けることができるようにするために、クライアント部は、レガシーデバイスのシステムへのアクセスを許容するアダプダ、すなわち、インタフェースエンティティを有する。インタフェースエンティティは、レガシーデバイスがクライアントデバイスと同等な機能を実行できるように各種機能を提供する必要がある。
【０１９５】
上記インタフェースエンティティを仮想クライアントと称する。仮想クライアントは、レガシーデバイスをシステムにリンクするのに必要なエンティティである。仮想クライアントは、レガシーデバイスとリンクしてクライアントデバイスのようなサービスをレガシーデバイスに提供することができる。具体的には、ドメインマネージャは、仮想クライアント及びレガシーデバイスのドメインへのアクセスを一つのクライアントのドメインへのアクセスとみなす。一つ以上のレガシーデバイスを仮想クライアントに接続することができる。
【０１９６】
仮想クライアント又はドメインマネージャは、レガシーデバイスの固有の情報を管理することができる。また、仮想クライアント又はドメインマネージャは、レガシーデバイスを用いるユーザの情報も管理する。
【０１９７】
図１４は、レガシーデバイスの固有の情報を管理する構造の一例を示す。
【０１９８】
図１４に示すように、レガシーデバイス２１０が、レガシーデバイス２１０によってアクセスすることを仮想クライアント２２０に要求すると、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏが仮想クライアントに提供される。このとき、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏは、レガシーデバイス２１０に固有のメディアアクセス制御アドレス、ディスクボリュームＩＤ等の固有の情報を表す。
【０１９９】
レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏは、レガシーデバイス２１０が仮想クライアントにアクセスを要求するときにアクセス要求メッセージの要求とともに仮想クライアント２２０に伝送することができる。また、仮想クライアント２２０は、レガシーデバイス２１０が仮想クライアントにアクセスを要求するときにレガシーデバイス２１０からレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを抽出することができる。
【０２００】
仮想クライアント２２０は、レガシーデバイス２１０から提供されるレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを格納及び管理することができる。このとき、図１４に示すように、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを、デバイス識別子ＬＤ−ｉｎｆｏに対応する情報テーブル２２２の形態で格納及び管理することができる。ここで、デバイス識別子ＬＤ−ｉｎｆｏは、レガシーデバイス２１０を識別するためのグローバル一意識別情報である。デバイス識別子ＬＤ−ｉｎｆｏを、ドメインマネージャ２４０によって割り当てることができる。
【０２０１】
ドメインマネージャ２４０は、デバイス識別子ＬＤ−ｉｎｆｏ及びデバイス識別子ＬＤ−ｉｎｆｏに対応するレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを各ドメインに対して格納及び管理する。例えば、図１４に示すように、ドメインマネージャ２４０は、ドメイン識別子Ｄ−ＩＤ、デバイス識別子ＬＤ−ｉｎｆｏ及びデバイス識別子ＬＤ−ｉｎｆｏに対応するレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを情報テーブル２４２の形態で格納及び管理することができる。このとき、ドメイン識別子Ｄ−ＩＤは、レガシーデバイス２１０によってアクセスされるドメインを識別する情報である。ドメイン識別子Ｄ−ＩＤは、仮想クライアント２２０が含まれるドメイン２００を識別する情報であってもよい。
【０２０２】
ドメインマネージャ２４０がデバイス識別子ＬＤ−ｉｎｆｏ及びデバイス識別子ＬＤ−ｉｎｆｏに対応するレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを管理するとき、ドメインマネージャ２４０は、レガシーデバイス２１０がレガシーデバイス２１０を認証することを他のドメインに重複して要求することを防止することができる。これは、以下説明するレガシーデバイスを認証する方法によって明確になる。
【０２０３】
図１５は、レガシーデバイス２１０を認証する手順を説明するフローチャートである。
【０２０４】
図１４及び図１５を参照すると、レガシーデバイス２１０が仮想クライアント２２０にアクセス要求するとき (段階Ｓ４１)、仮想クライアント２２０は、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏをレガシーデバイス２１０から受け取る(段階Ｓ４２)。次いで、仮想クライアント２２０は、仮想クライアント２２０に格納された情報テーブル２２２を検索し(段階Ｓ４３)、仮想クライアント２２０にアクセス要求するレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏと同一のレガシーデバイスの固有の情報が存在するか否かを決定する(段階Ｓ４４)。すなわち、レガシーデバイス２１０が予め登録されているか否かを決定する。
【０２０５】
このとき、仮想クライアント２２０にアクセス要求するレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏと同一のレガシーデバイスの固有の情報が存在する場合、レガシーデバイス２１０が仮想クライアント２２０に既に登録されているので、仮想クライアント２２０は、デバイス識別子ＬＤ−ｉｎｆｏを認証することドメインマネージャ２４０に要求する(段階Ｓ４６)。ドメインマネージャ２４０が、デバイス識別子ＬＤ−ｉｎｆｏを認証することを要求されると、デバイス識別子ＬＤ−ｉｎｆｏ及びレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏがドメインマネージャ２４０に提供される。
【０２０６】
一方、仮想クライアント２２０にアクセス要求するレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏと同一のレガシーデバイスの固有の情報が存在しないことを決定したとき、仮想クライアント２２０は、新たなデバイス識別子ＬＤ−ｉｎｆｏをドメインマネージャ２４０から受け取り、新たなデバイス識別子ＬＤ−ｉｎｆｏを情報テーブル２２２に格納する(段階Ｓ４５)。したがって、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏ及び新たに割り当てられたデバイス識別子ＬＤ−ｉｎｆｏが、情報テーブル２２２に同等に格納される。すなわち、レガシーデバイス２１０は、新たなデバイスとして登録される。
【０２０７】
レガシーデバイスを登録するために、仮想クライアント２２０又はドメインマネージャ２４０は、レガシーデバイス２１０の固有の情報を検査し、レガシーデバイス２１０が登録可能なデバイスであるか否か検査する。このとき、登録可能なデバイスは、ポリティカル又は技術的に許容されたデバイスを表す。例えば、サービスプロバイダ、他の権限、ドメインマネージャ等は、ドメインにアクセスすることができるレガシーデバイスの種類のリストを管理する。新たなレガシーデバイスを登録するとき、仮想クライアント又はドメインマネージャは、レガシーデバイスの種類のリストを検査し、許容されたデバイスにのみデバイス識別子を割り当てる。これを、図１７を参照して詳細に説明する。
【０２０８】
上記デバイス識別子ＬＤ−ｉｎｆｏが格納されるとき、仮想クライアント２２０は、デバイス識別子ＬＤ−ｉｎｆｏを認証することをドメインマネージャ２４０に要求する(段階Ｓ４６)。
【０２０９】
次に、ドメインマネージャ２４０は、認証要求に応答してデバイス識別子ＬＤ−ｉｎｆｏに対応するレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを考慮しながらデバイス識別子ＬＤ−ｉｎｆｏを認証する。具体的には、ドメインマネージャ２４０は、ドメインマネージャ２４０によって管理される情報テーブル２４２を検索し(段階Ｓ４７)、レガシーデバイス２１０が他のドメインにアクセスするか否かを決定する(段階Ｓ４８)。例えば、ドメインマネージャ２４０は、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏと同一のレガシーデバイスの固有の情報が現在認証されたか否かを決定する。
【０２１０】
レガシーデバイス２１０が他のドメインにアクセスしないとき、デバイス識別子ＬＤ−ｉｎｆｏがドメインへのアクセスが許容されたことを仮想クライアント２２０に報告する(段階Ｓ５０)。すなわち、レガシーデバイス２１０は、ドメインへのアクセスが許容される。したがって、レガシーデバイス２１０は、ドメイン２００にアクセスし、コンテンツを使用することができる。
【０２１１】
一方、レガシーデバイス２１０が他のドメインにアクセスするとき、レガシーデバイス２１０がドメインに重複してアクセスしようとしていることが決定される。決定結果は、仮想クライアント２２０に報告される(段階Ｓ４９)。すなわち、レガシーデバイス２１０は、ドメインへのアクセスが許容されない。したがって、レガシーデバイス２１０は、ドメイン２００にアクセスできない。
【０２１２】
これまで説明したように、仮想クライアント２２０及びドメインマネージャ２４０は、レガシーデバイス２１０の固有の情報を格納及び管理する。例えば、仮想クライアント２２０及びドメインマネージャ２４０は、レガシーデバイス２１０のデバイス認証を格納及び管理するのである。
【０２１３】
したがって、レガシーデバイス２１０が重複してドメイン２００にアクセスするのを防止することができる。したがって、レガシーデバイス２１０がコンテンツを違法に共有することを防止することができる。
【０２１４】
一方、仮想クライアント及びドメインマネージャは、レガシーデバイスの固有の情報に加えてレガシーデバイスを使用するユーザの情報を管理することができる。この場合、ユーザによって使用することができるレガシーデバイスの個数を制限することができる。
【０２１５】
図１６は、レガシーデバイスを使用するユーザの情報を管理するＤＲＭ相互運用システムの構造の一例を示す。
【０２１６】
図１６に示すように、レガシーデバイス２５１が、レガシーデバイス２５１を認証することをドメインに要求するために仮想クライアント２６０にアクセスするとき、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏ及びレガシーデバイス２５１のユーザ情報Ｕ−ｉｎｆｏが仮想クライアント２６０に提供される。このとき、レガシーデバイス２５１のユーザ情報Ｕ−ｉｎｆｏは、加入者識別モジュール情報、ユーザ認証情報、ユーザが入力する情報（例えば、ＩＤ、Ｐａｓｓｗｏｒｄ)等のレガシーデバイス２５１を使用するユーザを識別することができる固有の情報を表す。これは、ユーザのシステムログオン情報に対応することができる。これまで説明したように、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏは、レガシーデバイス２５１に固有のメディアアクセス制御アドレス、ディスクボリュームＩＤ等の固有の情報を表す。すなわち、レガシーデバイスの固有の情報は、物理情報又は論理情報を含む情報を表す。
【０２１７】
レガシーデバイス２５１が仮想クライアント２６０にアクセスを要求するとき、ユーザ情報Ｕ−ｉｎｆｏ及びレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを、アクセス要求メッセージと共に仮想クライアント２６０へ伝送することができる。また、レガシーデバイス２５１が仮想クライアント２６０にアクセスを要求するとき、仮想クライアント２６０は、ユーザ情報Ｕ−ｉｎｆｏ及びレガシーデバイスの固有の情報ＤＶ−ｉｎｆｏをレガシーデバイス２５１から抽出することができる。
【０２１８】
仮想クライアント２６０は、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏ、ユーザ情報Ｕ−ｉｎｆｏを格納及び管理する。このとき、図１６に示すように、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏ及びユーザ情報Ｕ−ｉｎｆｏを、ドメインマネージャ２７０によって提供されるデバイス識別子ＬＤ−ｉｎｆｏに対応する情報テーブル２６２の形態で格納及び管理することができる。
【０２１９】
ドメインマネージャ２７０は、デバイス識別子ＬＤ−ｉｎｆｏ、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏ及びユーザ情報Ｕ−ｉｎｆｏを各ドメインに対して格納及び管理する。具体的には、図１６に示すように、ドメインマネージャ２７０は、ドメイン識別子Ｄ−ＩＤ、デバイス識別子ＬＤ−ｉｎｆｏ、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏ及びユーザ情報Ｕ−ｉｎｆｏを情報テーブル２７２の形態で格納及び管理することができる。
【０２２０】
所定のレガシーデバイス２５１に対する認証要求が仮想クライアント２６０から伝送されるとき、ドメインマネージャ２７０は、レガシーデバイス２５１のユーザ情報Ｕ−ｉｎｆｏをドメインマネージャ２７０の情報テーブル２７２で探索することによって、レガシーデバイス２５１のユーザ情報Ｕ−ｉｎｆｏをアクセス許可認証に適用することができる。また、ドメインマネージャ２６０によるレガシーデバイス２５１管理を、一般的なクライアントデバイスにも適用することができる。
【０２２１】
例えば、レガシーデバイス２５１の個数を、上記ユーザ情報Ｕ−ｉｎｆｏを情報テーブル２７２で探索することによって抽出する。レガシーデバイス２５１の個数を、所定の制限個数と比較する。レガシーデバイス２５１の個数が所定の制限個数未満であるとき、認証を実行する。レガシーデバイス２５１の個数が所定の制限個数以上であるとき、認証を許可しない。したがって、ユーザのレガシーデバイスの総数を制限することができる。このとき、制限個数は、サービスプロバイダのポリシー又はユーザが支払った費用に従って決められる。
【０２２２】
これまで説明したように、レガシーデバイス２５１が認証されると、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏを探索することによってドメインが重複してアクセスされているか否かを決定する手順も実行することができる。すなわち、認証手順において、ドメインが重複してアクセスされているか否かを検査し、レガシーデバイスの固有の情報ＤＶ−ｉｎｆｏ及びユーザ情報Ｕ−ｉｎｆｏを使用することによってユーザに許容される制限個数を考慮する。一方、ドメインが重複してアクセスされているか否かを周期的に検査することもでき、各ユーザに対するレガシーデバイスの個数を、所定の周期に従って制限することができる。
【０２２３】
図１７は、レガシーデバイスをドメインに登録する手順を説明するためのフローチャートである。
【０２２４】
図１７を参照すると、新たなレガシーデバイスがドメインに加入するようアクセスすることを仮想クライアントに要求するとき(段階Ｓ５１)、レガシーデバイスの固有の情報が仮想クライアントに提供される。その後、仮想クライアントは、レガシーデバイスの固有の情報を介して仮想クライアントが新たなレガシーデバイスであることを認識し、登録可能なレガシーデバイスのリストを探索する(段階Ｓ５２)。登録可能なレガシーデバイスのリストは、ポリティカル又は技術的にサービスを提供することができるデバイスのオブジェクトを含む。リストを、仮想クライアントに予め格納することができる。また、リストを、ドメインマネージャ、サービスプロバイダのサーバ又は他のシステムによって提供することができる。
【０２２５】
仮想クライアントは、レガシーデバイスの固有の情報に基づいてリストを探索し、レガシーデバイスが登録であるか否かを決定する(段階Ｓ５３)。例えば、レガシーデバイスの固有の情報が上記リストに存在するか否かを決定する。このとき、レガシーデバイスの固有の情報がリストに存在する場合、仮想クライアントは、レガシーデバイスの登録をドメインマネージャに要求する。その後、ドメインマネージャは、固有のデバイス識別子を生成し、固有のデバイス識別子を仮想クライアントに伝送する(段階Ｓ５４)。一方、レガシーデバイスの固有情報がリストに存在しないとき、仮想クライアントは、レガシーデバイスの登録を許可せず、レガシーデバイスを登録することができるか否かの情報をレガシーデバイスに報告する (段階Ｓ５５)。
【０２２６】
以上、図５〜図１７を参照しながら、認証及び管理部によって実行することができる動作、例えば、クライアント部の機能、レファレンスポイントコントローラを選択する手順、レファレンスポイントコントローラの候補を選択する手順、レファレンスポイントコントローラにエラーが発生したときにレファレンスポイントコントローラ候補を用いることによってレファレンスポイントコントローラを置換する手順、レファレンスポイントコントローラプロキシを介してドメインを確張する手順、レファレンスポイントコントローラプロキシの候補を選択及び使用する手順、レファレンスポイントコントローラを登録する手順、クライアントを認証する手順、レガシーデバイスを登録、認証及び管理する手順等を説明した。
【０２２７】
３．処理制御部及びコンテンツ処理部の機能及び動作
認証及び管理部によってドメインが構成されるとき、ドメインの認証されたクライアント又は(仮想クライアントに接続された)レガシーデバイスは、ＤＲＭ相互運用サービスを利用することができる。このとき、レガシーデバイス及びレガシーデバイスに接続した仮想クライアントを一つのクライアントと見なすことができる。したがって、以下で言及するクライアントは、図２の説明で規定したクライアントに加えて、レガシーデバイスを仮想クライアントに接続することによって構成されるクライアントを含むことができる。
【０２２８】
認証されたクライアントは、一つ以上のコンテンツを伝送することを所定の送信先デバイスに要求することができる。このとき、送信先デバイスは、クライアントが所定のコンテンツを伝送することを所望するデバイス又はシステム、例えば、他のクライアントデバイス、所定のウェッブサーバ又はシステムを表す。
【０２２９】
コンテンツの伝送要求を処理制御部によって受信することができる。処理制御部は、クライアントの伝送要求に応答してコンテンツを伝送するようコンテンツ処理部を制御する。コンテンツ処理部は、処理制御部の制御の下で、伝送要求された一つ以上のコンテンツを送信元デバイスに伝送する。
【０２３０】
以下、処理制御部及びコンテンツ処理部によってコンテンツを伝送する手順を詳細に説明する。以下の説明において、ＤＲＭ相互運用システムにおけるコンテンツの伝送に関して四つの方法を例示する。理解の便宜のために、第１の方法を例 ３-１と称し、第２の方法を例 ３-２と称し、第３の方法を例 ３-３と称し、第４の方法を例 ３-４と称する。
【０２３１】
<例 ３-１> 
図１８は、処理制御部及びコンテンツ処理部の構成を示すブロック図である。図１８は、コンテンツを伝送する手順に関連するエンティティを示す。
【０２３２】
図１８に示すように、処理制御部４０は、コンテンツ処理コントローラ４１及びライセンス処理コントローラ４２を有する。ここで、ライセンス処理コントローラ４２がコンテンツの伝送に関連しないので、詳細な説明を後に行う。
【０２３３】
コンテンツ処理コントローラ４１は、クライアントからのコンテンツ伝送要求に従ってコンテンツを伝送するようコンテンツ処理部５０に要求するとともにコンテンツを伝送する手順を制御する役割を果たす。コンテンツ処理コントローラ４１は、ローカルエリア又はネットワークエリアのあらゆる場所に存在することができる。好適には、コンテンツ処理コントローラ４１は、ローカルエリアでドメインに加入する所定のデバイスに含めることができる。
【０２３４】
コンテンツ処理部５０は、複数のコンテンツハンドラを有する。コンテンツハンドラは、コンテンツの伝送及び処理に関連した機能を実行するエンティティを有することができる。コンテンツハンドラは、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３を有する。
【０２３５】
コンテンツエクスポータ５２は、コンテンツ処理コントローラ４１によって伝送するよう要求されたコンテンツをエクスポートすることによって、コンテンツをニュートラルコンテンツの形態でコンテンツトランスフォーマ５１又はコンテンツインポータ５３に伝送する機能を実行する。このとき、ニュートラルコンテンツは、所定のＤＲＭを用いることによって暗号化されないクリーンコンテンツを表すことができる。また、コンテンツ処理コントローラ４１によって要求されたコンテンツを、所定のＤＲＭを用いることによって暗号化されたコンテンツとすることができる。コンテンツエクスポータ５２は、要求されたコンテンツを解読し、解読したコンテンツをニュートラルコンテンツに変換し、変換されたコンテンツを伝送する。また、コンテンツエクスポータ５２は、予め解読されたニュートラルコンテンツを受信し、受信したコンテンツを伝送することもできる。
【０２３６】
コンテンツトランスフォーマ５１は、コンテンツエクスポータ５２から送信されたニュートラルコンテンツを受信し、ニュートラルフォーマットを、要求されたフォーマットに変換し、要求されたフォーマットのコンテンツをコンテンツインポータ５３に伝送する役割を果たす。このとき、要求されたフォーマットは、送信先デバイスＤＶ２によって要求されるフォーマットを表す。コンテンツトランスフォーマ５１は、ニュートラルコンテンツのフォーマット変換が必要なときだけ伝送に関与する。
【０２３７】
コンテンツインポータ５３は、コンテンツトランスフォーマ５１又はコンテンツエクスポータ５２から伝送されたニュートラルコンテンツを受信する役割を果たす。また、コンテンツインポータ５３は、受信したニュートラルコンテンツを送信先デバイスＤＶ２に提供することができる。また、コンテンツインポータ５３は、受信したニュートラルコンテンツを、送信先デバイスＤＶ２に適用されるＤＲＭに適切なフォーマットのコンテンツに暗号化し、暗号化したコンテンツを送信先デバイスＤＶ２に提供することができる。このとき、前者の場合、送信先デバイスＤＶ２は、コンテンツインポータ５３から送信されたニュートラルコンテンツを、送信先デバイスＤＶ２に適用されるＤＲＭに適切なフォーマットのコンテンツに暗号化し、コンテンツを使用する。後者の場合、コンテンツインポータ５３によって暗号化されたコンテンツが伝送されるので、送信先デバイスＤＶ２は、伝送されたコンテンツをそのまま使用することができる。
【０２３８】
図１９及び図２０は、コンテンツ処理コントローラ４１及びコンテンツハンドラの位置を説明するための例を示す。
【０２３９】
図１９及び図２０に示すように、コンテンツ処理コントローラ４１及びコンテンツハンドラ、すなわち、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３は、実行環境に従って多様な位置に配置される。
【０２４０】
先ず、図１９を参照すると、コンテンツエクスポータ５２を要求デバイスＤＶ１に含むことができる。コンテンツインポータ５３を送信先デバイスＤＶ２に含むことができる。また、コンテンツ処理コントローラ４１又はコンテンツトランスフォーマ５１を、要求デバイスＤＶ１及び送信先デバイスＤＶ２とは別の他のデバイスに含むことができる。
【０２４１】
ここで、上記要求デバイスＤＶ１及び送信先デバイスＤＶ２を規定する必要がある。
【０２４２】
要求デバイスＤＶ１は、コンテンツの伝送を要求するクライアントデバイスを表す。要求クライアントＲＣ１を要求デバイスＤＶ１に含むことができる。また、所定のＤＲＭを要求デバイスＤＶ１にインストールすることができる。すなわち、要求デバイスＤＶ１は、所定のＤＲＭが適用されるコンテンツを用いることができる。
【０２４３】
これまで説明したように、送信先デバイスＤＶ２は、要求クライアントＲＣ１によって要求されたコンテンツを伝送するクライアントデバイス又は所定のシステムを表す。送信先クライアントＲＣ２を送信先デバイスＤＶ２に含むことができる。また、送信先ＤＲＭを送信先デバイスＤＶ２にインストールすることができる。すなわち、送信先デバイスＤＶ２は、送信先ＤＲＭが適用されるコンテンツを使用することができる。
【０２４４】
図２０を参照すると、コンテンツ処理コントローラ４１及びコンテンツエクスポータ５２は要求デバイスＤＶ１に含まれ、コンテンツインポータ５３は送信先デバイスＤＶ２に含まれる。また、コンテンツトランスフォーマ５１は、他のデバイスに含まれる。
【０２４５】
これまで説明したように、コンテンツ処理コントローラ４１、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３を、多様な位置に配置することができる。コンテンツエクスポータ５２を要求デバイスＤＶ１に含むとともにコンテンツインポータ５３を送信先デバイスＤＶ２に含むのが、セキュリティの理由から有利である。
【０２４６】
したがって、以下、本発明を、図１９に示す構成を用いて説明する。しかしながら、本発明はこれに限定されるものではない。すなわち、コンテンツ処理コントローラ４１及びコンテンツハンドラを、実行環境に従って同一デバイスに含むことができる。選択的に、コンテンツ処理コントローラ４１及びコンテンツハンドラの一部を、実行環境に従って同一デバイスに含むことができる。選択的に、コンテンツ処理コントローラ４１及びコンテンツハンドラを、実行環境に従って別個のデバイスに含むことができる。
【０２４７】
以下、上記システムに基づいてコンテンツを伝送する手順を詳細に説明する。
図２１は、コンテンツ処理コントローラ４１及びコンテンツハンドラを用いることによってコンテンツを伝送する手順を示すフローチャートである。図２１は、要求デバイスＤＶ１に含まれる一つ以上のコンテンツを送信先である送信先デバイスＤＶ２に伝送する手順の例を示す。
【０２４８】
図２１に示すように、コンテンツを伝送するために、要求クライアントＲＣ１、コンテンツ処理コントローラ４１、複数のコンテンツハンドラ、例えば、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３が、互いに情報のやりとりを行うために要求される。
【０２４９】
先ず、要求クライアントＲＣ１は、一つ以上のコンテンツの伝送を要求するコンテンツ伝送要求メッセージをコンテンツ処理コントローラ４１に伝送する(段階Ｓ６０)。
【０２５０】
このとき、コンテンツ伝送要求メッセージは、伝送セッション識別子、コンテンツ識別子、送信元情報、送信先情報等を含む。また、コンテンツを受信する送信先のＤＲＭシステム情報を、オプションとしてコンテンツ伝送要求メッセージ含むことができる。
【０２５１】
コンテンツ識別子は、伝送要求されたコンテンツを識別する情報を表すことができる。伝送要求されたコンテンツが複数である場合、コンテンツを識別するコンテンツ識別子が複数存在することができる。
【０２５２】
伝送セッション識別子は、伝送セッションを独自に識別する識別子を表す。伝送セッション識別子を、所定の動作を実行するとき、例えば、コンテンツ伝送を取り消すとき又はコンテンツ伝送状態を更新するときにセッションを識別するのに用いることができる。
【０２５３】
送信元情報は、要求されたコンテンツがどこから伝送されるかを決定するのに用いられる。送信元情報は、要求デバイスＤＶ１のようなソースデバイス又はシステムを識別する識別子、伝送要求されたコンテンツファイルのフォーマットの情報等を含むことができる。
【０２５４】
送信先情報は、コンテンツが伝送要求された送信先である送信先デバイスＤＶ２を識別する情報を含む。送信先情報は、送信先を識別する送信先識別子、送信先によって要求されるファイルフォーマットの情報等を含む。送信先情報に含まれるファイルフォーマットの情報を、ファイルのフォーマットがコンテンツトランスフォーマ５１によって変換されるときに参照することができる。
【０２５５】
コンテンツ処理コントローラ４１は、コンテンツ送信メッセージに含まれる情報を以下のように使用することができる。このとき、コンテンツ処理コントローラ４１は、要求クライアントＲＣ１から受け取った情報をそのまま使用することができる。また、コンテンツ処理コントローラ４１は、要求クライアントＲＣ１から受け取った情報に対応する別個の情報を生成し、生成した情報を使用することができる。例えば、コンテンツ処理コントローラ４１は、要求クライアントＲＣ１から受け取った伝送セッション識別子及び複数のデータ識別子をそのまま使用することができる。また、コンテンツ処理コントローラ４１は、セッションに適切な伝送セッション識別子及び複数のデータ識別子を使用することができる。
【０２５６】
コンテンツ伝送要求メッセージを受信すると、コンテンツ処理コントローラ４１は、コンテンツハンドラの情報を収集し、コンテンツを送信できるか否か検査し、コンテンツを変換するコンテンツハンドラ、すなわち、コンテンツ変換チェーンを構成するコンテンツハンドラを決定する(段階Ｓ６１〜Ｓ６３)。
【０２５７】
例えば、コンテンツ処理コントローラ４１は、一つ以上のコンテンツエクスポータ５２、コンテンツインポータ５３及びコンテンツトランスフォーマ５１に能力についての問合せを行い、対応するエンティティから応答を受け取る。したがって、送信元装置、中間装置、送信先装置及びＤＲＭの能力を認識することができる。
【０２５８】
情報が収集されると、コンテンツ処理コントローラ４１は、収集された情報に基づいて要求されたコンテンツを伝送するか否かを決定する。すなわち、要求されたコンテンツ伝送をコンテンツハンドラが正常に伝送するか否か検査する。ここで、要求されたコンテンツのフォーマットと、システムのポリシーと、エンティティ間で実行することができるセキュリティ認証チャネルアルゴリズム情報とを考慮することができる。例えば、コンテンツトランスフォーマ５１が、収集されたコンテンツトランスフォーマ５１の能力に基づいて、コンテンツの要求されたコンテンツフォーマットのコンテンツへの変換をサポートすることができないとき、コンテンツを伝送することができない。コンテンツトランスフォーマ５１が、コンテンツの要求されたコンテンツフォーマットのコンテンツへの変換をサポートすることができるとき、コンテンツを伝送することができる。コンテンツ処理コントローラ４１は、上記要因を考慮することによってコンテンツを伝送するか否か決定することができる。
【０２５９】
コンテンツを伝送することが決定されると、コンテンツ処理コントローラ４１は、要求されたコンテンツの変換を效果的に実行することができるコンテンツハンドラ、例えば、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３を決定し、決定されたコンテンツハンドラを含むコンテンツ変換チェーンを構成するようコンテンツハンドラを制御する。すなわち、決定されたコンテンツハンドラは、コンテンツ変換チェーンが構成するよう制御される。
【０２６０】
コンテンツ変換チェーンに含まれるコンテンツハンドラを決定するとき、コンテンツ伝送コントローラは、コンテンツトランスフォーマ５１を含んでも含まなくてもよい。伝送されるコンテンツのフォーマットを変換する必要がある。しかしながら、伝送要求されたコンテンツのフォーマットが、送信先で要求されたコンテンツのフォーマットと同一であるとき、伝送されるコンテンツのフォーマットを変換する必要がない。
【０２６１】
したがって、要求されたコンテンツのフォーマットが、送信先で要求されたコンテンツのフォーマットと異なるとき、コンテンツ処理コントローラ４１は、コンテンツトランスフォーマ５１をコンテンツ変換チェーンに含むことを許可する。要求されたコンテンツのフォーマットが、送信先で要求されたコンテンツのフォーマットと同一であるとき、コンテンツ処理コントローラ４１は、コンテンツトランスフォーマ５１をコンテンツ変換チェーンに含むことを許可しない。ここで、コンテンツのフォーマット変換は、例えば、コデックス変換を表すことができる。
【０２６２】
例えば、要求されたコンテンツがＭＰＥＧ-２圧縮によって圧縮されるとき及び送信先で利用できるコンテンツのフォーマットがＭＰＥＧ-４であるとき、ＭＰＥＧ-２フォーマットのコンテンツを利用することができず、したがって、コンテンツトランスフォーマ５１を用いることによって、ＭＰＥＧ-２フォーマットをＭＰＥＧ-４フォーマットに変換する必要がある。
【０２６３】
例 ３-１において、要求されたコンテンツのフォーマットが送信先によって要求されたコンテンツのフォーマットと異なるためにコンテンツを変換する必要がある場合を説明する。この場合、コンテンツ変換チェーンは、コンテンツトランスフォーマ５１を含む必要がある。
【０２６４】
次いで、コンテンツ処理コントローラ４１は、コンテンツエクスポート要求、コンテンツ変換要求及びコンテンツインポート要求をそれぞれコンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３に送信する (段階Ｓ６７〜Ｓ６９)。上記要求は、要求される動作の実行をコンテンツハンドラに要求する制御メッセージをコンテンツハンドラに送信することによって実行される。
【０２６５】
コンテンツのエクスポートを要求する制御メッセージは、伝送セッション識別子、コンテンツ識別子、受信部情報等を含むことができる。受信部情報は、コンテンツエクスポータ５２がコンテンツをエクスポート及び伝送する受信部の情報を表すことができる。例 ３-１において、コンテンツ変換チェーンがコンテンツトランスフォーマ５１を有する場合を説明し、したがって、受信部情報は、コンテンツトランスフォーマ５１の識別情報を表す。しかしながら、コンテンツ変換チェーンがコンテンツトランスフォーマ５１を有しないとき、受信部情報は、コンテンツインポータ５３の識別情報を表すことができる。
【０２６６】
また、コンテンツ変換を要求する制御メッセージは、伝送セッション識別子、コンテンツ識別子、送信部情報、受信部情報、送信されるコンテンツのフォーマット情報、変換されたフォーマットの情報等を含むことができる。このとき、送信部情報及び受信部情報は、コンテンツを送信するエンティティ及びコンテンツを受信するエンティティを識別する情報を表すことができる。すなわち、送信部情報は、送信部であるコンテンツエクスポータ５２を識別する役割を果たし、受信部情報は、受信部であるコンテンツインポータ５３を識別する役割を果たす。
【０２６７】
コンテンツインポートを要求する制御メッセージは、伝送セッション識別子、コンテンツ識別子、送信部情報等を含むことができる。送信部情報は、コンテンツを伝送する送信部を識別する情報を表すことができる。例 ３-１において、コンテンツトランスフォーマ５１が存在する場合を説明し、したがって、送信元情報は、コンテンツトランスフォーマ５１の識別情報を表すことができる。コンテンツトランスフォーマ５１がコンテンツ変換チェーンに含まれないとき、コンテンツエクスポータ５２が送信部となる。コンテンツを受信することが要求されるとき、コンテンツを最終的に受信する受信部の情報は、送信先の情報及び送信先のＤＲＭシステム情報を含むことができる。
【０２６８】
また、コンテンツをエクスポートし、変換し及び受信することが要求されるとき、制御メッセージに含まれるコンテンツ識別子は、クライアントがコンテンツの伝送を要求するときに要求されたコンテンツ識別子と一致する。クライアントから伝送要求されたコンテンツが複数であるとき、コンテンツの伝送要求時に要求されたコンテンツの識別子は、コンテンツエクスポート要求情報、コンテンツ変換要求情報及びコンテンツインポート要求情報に含まれるコンテンツ識別子と同一である。
【０２６９】
これまで説明したように、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３がそれぞれ、コンテンツエクスポート要求、コンテンツ変換要求及びコンテンツインポート要求をコンテンツ処理コントローラ４１から受信するとき、セキュリティ認証チャネル(ＳＡＣ)が、コンテンツエクスポータ５２とコンテンツトランスフォーマ５１との間及びコンテンツトランスフォーマ５１とコンテンツインポータ５３との間に確立される(段階Ｓ７０)。このとき、ＴＣＰ/ＩＰの転送層に適用される転送層セキュリティのようなセキュリティ技術を、ＳＡＣに適用することができる。
【０２７０】
コンテンツエクスポータ５２は、コンテンツエクスポート要求に応答して、要求されたコンテンツを受信部であるコンテンツトランスフォーマ５１に安全に伝送できるようにするために、コンテンツトランスフォーマ５１とＳＡＣを確立する。また、コンテンツトランスフォーマ５１は、コンテンツ変換要求に応答して、コンテンツエクスポータ５２から伝送されたコンテンツを変換し、変換されたコンテンツをコンテンツインポータ５３に伝送するためにＳＡＣを確立する。一方、コンテンツインポータ５３は、コンテンツインポート要求に応答して、コンテンツトランスフォーマ５１から伝送されたコンテンツを送信先デバイスＤＶ２すなわちコンテンツ送信の終点に伝送するためにセキュリティ認証チャネルを確立することができる。これは、コンテンツインポータが送信先デバイスとは異なるデバイスにインストールされたときに更に有用である。
【０２７１】
したがって、コンテンツエクスポータ５２からコンテンツトランスフォーマ５１を経由してコンテンツインポータ５３に至る経路を構成するＳＡＣが確立される。また、コンテンツインポータ５３がコンテンツを最終的な終点まで提供するＳＡＣを、コンテンツインポータ５３から終点まで確立することができる。各コンテンツハンドラは、ＳＡＣが確立されたことをコンテンツ処理コントローラ４１に報告することができる(段階Ｓ７１〜Ｓ７３)。
【０２７２】
セキュリティ認証チャネルが確立されると、コンテンツがコンテンツエクスポータ５２から伝送され始める。このとき、互いに接続されたコンテンツハンドラ対(すなわち、コンテンツエクスポータ５２-コンテンツトランスフォーマ５１及びコンテンツトランスフォーマ５１-コンテンツインポータ５３)は、マルチ伝送プロトコルをサポートする。マルチ伝送プロトコルは、単一セッションでマルチコンテンツの伝送を可能にする役割を果たす。これは、可変フレームサイズをサポートすることができる。したがって、複数のコンテンツを単一セッションで伝送することができる。
【０２７３】
図２２は、マルチ伝送プロトコルを説明するための例を示す。
【０２７４】
図２２に示すように、単一セッションで複数のコンテンツを伝送することができる。各コンテンツのヘッダーにコンテンツインデックスが挿入される。コンテンツインデックスを、コンテンツを識別する所定のビット値(例えば、４ビット)とすることができる。コンテンツインデックスは、対応するセッションを介して伝送されるコンテンツを要求されたコンテンツに関連して互いに区分する因子である。また、コンテンツを互いに区分するためのコンテンツセパレータが、コンテンツの端部に挿入される。コンテンツセパレータを例えば、４ビットの“０”で構成することができる。
【０２７５】
コンテンツを、コンテンツの長さに従って複数のフレームに分割することができる。所定ビット(例えば４ビット)のフレームサイズがフレームヘッダに挿入される。データを運ぶフレームペイロードが、フレームサイズの位置の後方に配置される。一方、伝送の終了を表す転送処理の終わり（ＥＯＴ）が、セッションの最終部に挿入される。例えば、ＥＯＴを４ビットの１とすることができる。
【０２７６】
マルチ伝送プロトコルのサポートに従って、要求クライアントＲＣ１によって提供された伝送セッション識別子に対応する一つのセッションを介して複数のコンテンツを伝送することができる。上記伝送は、コンテンツエクスポータ５２から順次行われる。コンテンツエクスポータ５２は、要求されたコンテンツを、ＳＡＣを介してコンテンツトランスフォーマ５１に伝送する(段階Ｓ７４)。コンテンツトランスフォーマ５１は、コンテンツを受信し、送信先によって要求されたフォーマットへフォーマット変換を実行する(段階Ｓ７５)。フォーマット変換が実行された後、コンテンツトランスフォーマ５１は、変換されたコンテンツを、ＳＡＣを介してコンテンツインポータ５３に伝送する(段階Ｓ７６)。その後、コンテンツインポータ５３は、コンテンツを受信し、受信したコンテンツを送信先デバイスＤＶ２に提供する。
【０２７７】
コンテンツエクスポータ５２からコンテンツトランスフォーマ５１を経由してコンテンツインポータ５３に伝送されるコンテンツを、ニュートラルコンテンツとすることができる。ニュートラルコンテンツは、所定のＤＲＭを用いることによって暗号化されないクリーンコンテンツを表すことができる。コンテンツエクスポータ５２は、要求されたコンテンツをエクスポートし、エクスポートされたコンテンツをニュートラルコンテンツに変換し、ニュートラルコンテンツを伝送することができる。また、コンテンツエクスポータ５２は、予め変換されたニュートラルコンテンツをエクスポートし、ニュートラルコンテンツを伝送することができる。この手順を、要求されたコンテンツに適用されたＤＲＭによって指定されたポリシー又はエクスポート手順を考慮して実行することができる。
【０２７８】
また、コンテンツインポータ５３は、送信先デバイスに適用されたＤＲＭシステムによって指定されたポリシー又はインポート手順を考慮して、受信したニュートラルコンテンツを送信先デバイスに伝送することができる。例えば、ニュートラルコンテンツを、送信先ＤＲＭに適合するように暗号化するとともに送信先デバイスＤＶ２に提供することができる。また、受信したニュートラルコンテンツを、暗号化することなく送信先デバイスＤＶ２に提供することができる。
【０２７９】
一方、上記コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３は、コンテンツの伝送状態をコンテンツ処理コントローラ４１に報告することができる。このために、コンテンツ処理コントローラ４１は、コンテンツの伝送状態を提供することができる所定のイベントをサブスクライブする必要がある。所定のイベントを、コンテンツ伝送状態提供イベントと称する。
【０２８０】
コンテンツ処理コントローラ４１は、コンテンツのエクスポートを要求する前にコンテンツ伝送状態提供イベントのサブスクリプションを要求することができる(段階Ｓ６４〜Ｓ６６)。例えば、コンテンツ処理コントローラ４１は、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３にコンテンツ伝送状態イベントのサブスクリプションを要求することによって、対応するイベントをサブスクライブすることができる。
【０２８１】
コンテンツ伝送状態イベントをサブスクライブするとき、コンテンツ処理コントローラ４１は、コンテンツ伝送状態情報を含むイベントメッセージをプッシュ又はプル方式で受け取ることができる。このとき、プッシュ方式において、コンテンツハンドラは、コンテンツ伝送状態が変化する度に自動的に (コンテンツ伝送状態情報を含む)イベントメッセージをプッシュする。したがって、コンテンツ処理コントローラ４１は、自動的にコンテンツ伝送状態を受け取ることができる。プル方式において、コンテンツ処理コントローラ４１は、必要に応じてコンテンツハンドラからコンテンツ伝送状態情報を取得する。
【０２８２】
イベントをサブスクライブするとき、コンテンツ処理コントローラ４１は、プッシュ方式とプル方式のうちのいずれの方式でコンテンツ伝送状態情報が提供されるかをコンテンツハンドラに報告する。例 ３-１において、コンテンツ伝送状態がプッシュ方式でコンテンツ処理コントローラ４１に提供される例を説明する。
【０２８３】
コンテンツ伝送状態提供イベントをサブスクライブするとき、コンテンツ処理コントローラ４１は、コンテンツ伝送状態情報を含むイベントメッセージをコンテンツハンドラから受け取ることができる。このとき、伝送セッション識別子をイベントメッセージに含める必要がある。ここで、伝送セッション識別子は、コンテンツ伝送要求時に割り当てられた伝送セッション識別子と同一である。
【０２８４】
コンテンツの伝送を開始するとき、コンテンツエクスポータ５２は、コンテンツの伝送を開始したことを表すイベントメッセージをコンテンツ処理コントローラ４１に送信する。例えば、“Ｓｔａｒｔｅｄ”エレメントを含むイベントメッセージを伝送することができる。また、コンテンツが処理されていることを表すイベントメッセージを、コンテンツの伝送中に周期的にコンテンツ処理コントローラ４１に伝送することができる。例えば、“ＰｒｏｇｒｅｓｓＤｏｎｅ”エレメントを含むイベントメッセージを伝送することができる。コンテンツの伝送が完了すると、コンテンツエクスポータ５２は、コンテンツの伝送完了を表すイベントメッセージをコンテンツ処理コントローラ４１に伝送する。例えば、“Ｃｏｍｐｌｅｔｅｄ”エレメントを含むイベントメッセージを伝送することができる。また、開始手順、処理手順及び終了手順並びにコンテンツ又はライセンスを含むデータを送受信する手順の全てのイベント情報に基づく各手順に対し、イベントメッセージを生成し及び伝送する。
【０２８５】
コンテンツの伝送を開始するとき、コンテンツトランスフォーマ５１は、コンテンツの伝送を開始したことを表すイベントメッセージをコンテンツ処理コントローラ４１に送信する。例えば、“Ｓｔａｒｔｅｄ”エレメントを含むイベントメッセージを伝送することができる。また、コンテンツが処理されていることを表すイベントメッセージを、コンテンツの伝送中に周期的にコンテンツ処理コントローラ４１に伝送することができる。例えば、“ＰｒｏｇｒｅｓｓＤｏｎｅ”エレメントを含むイベントメッセージを伝送することができる。コンテンツの伝送が完了すると、コンテンツエクスポータ５２は、コンテンツの伝送完了を表すイベントメッセージをコンテンツ処理コントローラ４１に伝送する。例えば、“Ｃｏｍｐｌｅｔｅｄ”エレメントを含むイベントメッセージを伝送することができる。
【０２８６】
コンテンツの伝送を開始するとき、コンテンツインポータ５３は、コンテンツの伝送を開始したことを表すイベントメッセージをコンテンツ処理コントローラ４１に送信する。例えば、“Ｓｔａｒｔｅｄ”エレメントを含むイベントメッセージを伝送することができる。また、コンテンツが処理されていることを表すイベントメッセージを、コンテンツの伝送中に周期的にコンテンツ処理コントローラ４１に伝送することができる。例えば、“ＰｒｏｇｒｅｓｓＤｏｎｅ”エレメントを含むイベントメッセージを伝送することができる。コンテンツの伝送が完了すると、コンテンツエクスポータ５２は、コンテンツの伝送完了を表すイベントメッセージをコンテンツ処理コントローラ４１に伝送する。例えば、“Ｃｏｍｐｌｅｔｅｄ”エレメントを含むイベントメッセージを伝送することができる。
【０２８７】
伝送の開始を表すイベントメッセージをコンテンツエクスポータ５２から受信するとき、コンテンツ処理コントローラ４１は、伝送の開始に対応するイベントメッセージを要求クライアントＲＣ１に送信する。すなわち、コンテンツ処理コントローラ４１は、コンテンツの伝送を開始したことを報告する。また、コンテンツ処理コントローラ４１が、コンテンツを処理していることを報告するイベントメッセージを受信するとき、コンテンツ処理コントローラ４１は、コンテンツの処理に対応するイベントメッセージを要求クライアントＲＣ１に送信する。すなわち、コンテンツ処理コントローラ４１は、コンテンツが処理されていることを報告する。コンテンツ処理コントローラ４１が、伝送の完了を表すイベントメッセージをコンテンツインポータ５３から受信するとき、コンテンツ処理コントローラ４１は、伝送の完了に対応するイベントメッセージを要求クライアントＲＣ１に送信する。すなわち、コンテンツ処理コントローラ４１は、コンテンツの伝送を完了したことを報告する。上記イベントメッセージが要求クライアントＲＣ１にエクスポートされるとき、要求クライアントＲＣ１がコンテンツ伝送要求時に指定した伝送セッション識別子を含むイベントメッセージを伝送することができる。
【０２８８】
一方、コンテンツ処理コントローラ４１は、伝送されたコンテンツを個別に識別し、コンテンツの送信状態又は変換状態を報告する。伝送されたコンテンツをまとめて報告することもできる。換言すれば、コンテンツ処理コントローラ４１は、複数のコンテンツを伝送時間に基づいて区別し、コンテンツが伝送される度に伝送時間をクライアントに報告する。コンテンツが伝送された後、イベントをまとめて管理し、コンテンツ伝送状態を報告することもできる。また、コンテンツの識別を、コンテンツ識別情報を介して行う。上記手順を、ライセンスにも同様に適用することができる。ライセンスの場合、上記手順を、ライセンス処理コントローラによって実行することができる。
【０２８９】
要求クライアントＲＣ１は、上記方法を用いることによって、コンテンツの伝送を要求したセッションに対するコンテンツの伝送状態を認識することができる。ユーザインタフェース機能が要求クライアントＲＣ１に含まれるとき、要求クライアントＲＣ１は、数値又はグラフを用いることによって、コンテンツの伝送状態をユーザに報告することができる。
【０２９０】
また、複数のコンテンツを一つのセッションを介して伝送するとき、各コンテンツの伝送状態を認識することができる。したがって、セッションを介して伝送することが要求されたコンテンツの伝送状態は、順次認識される。
【０２９１】
一方、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及びコンテンツインポータ５３は、コンテンツの伝送中にＳＡＣに発生するエラーを認識することができる。この場合、エラーを見つけるコンテンツハンドラは、エラーが発生したことを表すイベントメッセージをコンテンツ処理コントローラ４１に伝送することができる。例えば、“Ｅｒｒｏｒ”又は“ＳＡＣ-Ｆａｉｌｕｒｅ”エレメントを含むイベントメッセージを伝送する。このとき、イベントメッセージは、必ず伝送セッション識別子を含む。
【０２９２】
所定のコンテンツハンドラからエラーが発生したことを表すイベントメッセージを受信するとき、コンテンツ処理コントローラ４１は、コンテンツの伝送に関与しているコンテンツハンドラに伝送の取り消しを要求する。送信の取り消しが要求されると、取り消された伝送セッションの伝送セッション識別子を提供する必要がある。また、コンテンツ処理コントローラ４１は、エラーが発生したことを表すイベントメッセージを要求クライアントＲＣ１に送信する。したがって、要求クライアントＲＣ１は、エラーが発生したことを認識することができる。一方、伝送の取り消し要求を受信したコンテンツハンドラは、セッションの伝送を取り消す。
【０２９３】
伝送の取り消しを要求クライアントＲＣ１によって開始することができる。この場合、要求クライアントＲＣ１は、コンテンツをコンテンツ処理プロセッサ４１に伝送することを要求するときに提供される伝送セッション識別子と同一の伝送セッション識別子を含む伝送取り消し要求を、コンテンツ処理コントローラ４１に伝送する。その後、コンテンツ処理コントローラ４１は、取り消し要求に応答して、伝送に関与するコンテンツハンドラに伝送取り消しを要求する。伝送取り消し要求を受信するコンテンツハンドラは、セッションの伝送を取り消す。
【０２９４】
一方、コンテンツ処理コントローラ４１は、コンテンツ伝送開始、コンテンツ伝送中、コンテンツ伝送完了、コンテンツ伝送エラー等のイベントメッセージの他にコンテンツ変換手順をモニタリングできるイベントをサブスクライブすることをコンテンツトランスフォーマ５１に要求することができ、かつ、コンテンツフォーマット変換開始、コンテンツフォーマット変換、コンテンツフォーマット変換完了、コンテンツフォーマット変換エラー等のイベントメッセージを受信することができる。選択的に、コンテンツ処理コントローラ４１は、所定の暗号化技術によってデータが変換されることを表すイベントのサブスクリプションを要求することができ、暗号化技術によるデータの変換開始”、 暗号化技術によるデータの変換中、暗号化技術によるデータの変換終了、暗号化技術によるデータの変換エラー等のイベントメッセージを受信することができる。選択的に、コンテンツ処理コントローラ４１は、ＳＡＣ形成手順を表すイベントのサブスクリプションを変換コンテンツハンドラに要求することができ、かつ、ＳＡＣの形成開始、ＳＡＣの形成、ＳＡＣの形成完了、ＳＡＣの形成エラー等のイベントメッセージを受信することができる。
【０２９５】
例 ３-１において、処理制御部のコンテンツ処理コントローラ１及びコンテンツ処理部のコンテンツハンドラによって一つのコンテンツ変換チェーンを構成する手順及び単一のセッションを介して単一コンテンツ又は複数コンテンツを伝送する手順を説明した。
【０２９６】
以下の例 ３-２において、要求クライアントＲＣ１からの要求に応答して複数のコンテンツ変換チェーンを構成するとともに複数セッションを介して単一コンテンツ又は複数コンテンツを伝送する手順を説明する。この場合、コンテンツを、コンテンツ伝送要求に応答して一つ以上の送信先に伝送することができる。
【０２９７】
<例 ３-２>
図２３は、例 ３-２によるコンテンツ伝送手順のシステムの構成を示すブロック図である。
【０２９８】
図２３を参照すると、要求デバイスＤＶ１、は要求クライアントＲＣ１及びコンテンツエクスポータ５２を有する。また、第１送信先デバイスＤＶ２−１は、第１コンテンツインポータ５３ａを有する。第２送信先デバイスＤＶ２−２は、第２コンテンツインポータ５３ｂを有する。コンテンツ処理コントローラ４１及びコンテンツトランスフォーマ５１は、要求デバイスＤＶ１又は送信先デバイスＤＶ２とは別個のデバイスに含まれる。
【０２９９】
図２４は、例 ３-２によるコンテンツ伝送手順を示すフローチャートである。図２４は、要求クライアントＲＣ１の要求に応答して、要求デバイスＤＶ１に含まれる一つ以上のコンテンツを送信先である第１送信先デバイスＤＶ２−１及び第２送信先デバイスＤＶ２−２に伝送する手順の例を示す。
【０３００】
図２４に示すように、要求クライアントＲＣ１は、要求デバイスＤＶ１に含まれる一つ以上のコンテンツを第１送信先デバイスＤＶ２−１及び第２送信先デバイスＤＶ２−２に伝送することを要求するコンテンツ伝送要求メッセージを、コンテンツ処理コントローラ４１に伝送する(段階Ｓ８１)。
【０３０１】
このとき、コンテンツ伝送要求メッセージは、少なくとも一つの伝送セッション識別子、コンテンツ識別子、送信元情報、送信先情報等を含む。また、コンテンツ伝送要求メッセージは、コンテンツを受信する送信先のＤＲＭシステム情報をオプションとして含むことができる。
【０３０２】
コンテンツ識別子は、伝送要求されたコンテンツを識別する情報を表すことができる。例 ３-２において、一つ以上のコンテンツが第１送信先デバイスＤＶ２−１及び第２送信先デバイスＤＶ２−２に伝送されるので、一つ以上のコンテンツ識別子が存在することができる。
【０３０３】
伝送セッション識別子は、伝送セッションを独自に識別する識別子を表す。例 ３-２において、要求された一つ以上のコンテンツを、第１送信先デバイスＤＶ２−１に伝送する必要があり、要求された一つ以上のコンテンツを、第２送信先デバイスＤＶ２−２に伝送する必要がある。したがって、伝送セッションは、二つの伝送セッションに分けられる。したがって、二つの伝送セッション識別子が存在することができる。例えば、第１伝送セッション識別子及び第２伝送セッション識別子が存在することができる。
【０３０４】
送信元情報は、要求されたコンテンツがどこから伝送されるかを決定する情報を表す。送信元情報は、要求デバイスＤＶ１のような送信元装置又はシステムを識別する識別子と、伝送要求されたコンテンツファイルのフォーマットの情報等を含むことができる。例 ３-２において、要求された一つ以上のコンテンツが要求デバイスＤＶ１に含まれるので、送信元情報は、要求デバイスＤＶ１の情報及びファイルフォーマットの情報を含むことができる。
【０３０５】
送信先情報は、伝送要求されたコンテンツが伝送される送信先である送信先デバイスＤＶ２を識別する情報を含む。送信先情報は、送信先を識別する送信先識別子、送信先によって要求されるファイルフォーマットの情報等を含むことができる。ファイルのフォーマット変換が実行されるとき、送信先情報に含まれるファイルフォーマットの情報を参照することができる。例 ３-２において、送信先情報は、第１送信先デバイスＤＶ２−１、第２送信先デバイスＤＶ２−２の情報及びフォーマット情報を含むことができる。
【０３０６】
コンテンツ伝送要求メッセージを受信するとき、コンテンツ処理コントローラ４１は、コンテンツハンドラの情報を収集する(段階Ｓ８２)。例えば、コンテンツ処理コントローラ４１は、一つ以上のコンテンツエクスポータ５２、コンテンツインポータ５３及びコンテンツトランスフォーマ５１に能力について問い合わせ、対応するエンティティから応答を得る。したがって、送信元、中間及び送信先のデバイス、システム及びＤＲＭの能力を認識することができる。
【０３０７】
情報が収集されるとき、コンテンツ処理コントローラ４１は、要求された一つ又は複数のコンテンツ伝送を実行するか否かを収集された情報に基づいて決定する(段階Ｓ８３)。すなわち、要求されたコンテンツ伝送をコンテンツハンドラが正常に伝送するか否か検査する。ここで、要求クライアントＲＣ１によって要求された二つの伝送セッションが満足されたか否かを決定する必要がある。
【０３０８】
コンテンツの伝送が決定されると、コンテンツ処理コントローラ４１は、要求されたコンテンツの変換を效果的に実行できるコンテンツハンドラを決定することによって、コンテンツ変換チェーンを構成するようコンテンツハンドラを制御する。例 ３-２において、要求されたコンテンツを第１送信先デバイスＤＶ２−１に伝送するための伝送セッションが、要求されたコンテンツを第２送信先デバイスＤＶ２−２に伝送するための伝送セッションと区分されるので、各伝送セッションを実行できる二つのコンテンツ変換チェーンが必要である。
【０３０９】
図２５は、一つ以上のコンテンツを第１送信先デバイスＤＶ２−１に伝送するための第１コンテンツ変換チェーンを示す。
【０３１０】
図２５に示すように、第１コンテンツ変換チェーンは、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及び第１コンテンツインポータ５３ａを含む。
【０３１１】
図２６は、一つ以上のコンテンツを第２送信先デバイスＤＶ２−２に伝送するための第２コンテンツ変換チェーンを示す。
【０３１２】
図２６に示すように、第２コンテンツ変換チェーンは、コンテンツエクスポータ５２及び第２コンテンツインポータ５３ｂを含む。
【０３１３】
このとき、第１コンテンツ変換チェーンは、コンテンツトランスフォーマ５１を含むが、第２コンテンツ変換チェーンは、コンテンツトランスフォーマ５１を含まない。要求された一つ以上のコンテンツのフォーマットが、第１送信先デバイスＤＶ２−１によって要求されるコンテンツのフォーマットと異なるので、コンテンツのフォーマット変換が必要である。一方、要求された一つ以上のコンテンツのフォーマットは、第２送信先デバイスＤＶ２−２によって要求されたコンテンツのフォーマットと同一である。
【０３１４】
コンテンツ処理コントローラ４１は、第１コンテンツ変換チェーンを構成するようコンテンツハンドラを制御する。第１伝送セッションが実行される。その後、コンテンツ処理コントローラ４１は、第２コンテンツ変換チェーンを構成するようコンテンツハンドラを制御する。第２伝送セッションが実行される。コンテンツ変換チェーンを構成する他の例において、単一セッションを繰り返し生成することができる。
【０３１５】
先ず、コンテンツ処理コントローラ４１は、コンテンツエクスポート要求、コンテンツ変換要求及びコンテンツインポート要求をそれぞれ、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及び第１コンテンツインポータ５３ａに伝送する(段階Ｓ８４)。上記要求は、制御メッセージをコンテンツハンドラに伝送することによって実行される。
【０３１６】
コンテンツエクスポートを要求するとき、コンテンツ処理コントローラ４１は、第１伝送セッション識別子、要求された一つ以上のコンテンツのコンテンツ識別子、受信部情報であるコンテンツトランスフォーマ５１の情報をコンテンツエクスポータ５２に提供することができる。
【０３１７】
また、コンテンツ変換を要求するとき、コンテンツ処理コントローラ４１は、第１伝送セッション識別子、要求された一つ以上のコンテンツのコンテンツ識別子、送信部情報であるコンテンツエクスポータ５２の情報、受信部情報であるコンテンツインポータ５３の情報、伝送される一つ以上のコンテンツのフォーマット及び変換されたフォーマットの情報等をコンテンツトランスフォーマ５１に提供することができる。
【０３１８】
コンテンツインポートを要求するとき、コンテンツ処理コントローラ４１は、第１伝送セッション識別子、要求された一つ以上のコンテンツのコンテンツ識別子、送信部であるコンテンツトランスフォーマ５１の情報等を第１コンテンツインポータ５３ａに提供することができる。また、コンテンツ処理コントローラ４１は、コンテンツを最終的に受信する受信部の情報及び送信先ＤＲＭシステムのＤＲＭ情報も提供することができる。ここで受信部の情報は、コンテンツの送信の終点、例えば、第１送信先デバイスＤＶ２−１に含まれる所定の格納エンティティ又はモジュールの情報を表すことができる。
【０３１９】
これまで説明したように、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及び第１コンテンツインポータ５３がそれぞれ、コンテンツエクスポート要求、コンテンツ変換要求及びコンテンツインポート要求をコンテンツ処理コントローラ４１から受け取るとき、第１コンテンツ変換チェーンを介してコンテンツを伝送するとともにイベントを受信する(段階Ｓ８５)。
【０３２０】
先ず、コンテンツエクスポータ５２とコンテンツトランスフォーマ５１との間及びコンテンツトランスフォーマ５１と第１コンテンツインポータ５３ａとの間にＳＡＣが確立される。また、第１コンテンツインポータ５３ａと第１送信先デバイスＤＶ２−１との間にもＳＡＣを確立することができる。ＳＡＣが確立されるとき、コンテンツエクスポータ５２は、コンテンツの伝送を開始する。このとき、コンテンツハンドラ対(すなわち、コンテンツエクスポータ５２-コンテンツトランスフォーマ５１及びコンテンツトランスフォーマ５１-コンテンツインポータ５３)は、上記マルチ伝送プロトコルをサポートする。したがって、複数のコンテンツを、一つのセッションを介して伝送することができる。
【０３２１】
複数のコンテンツを、マルチ伝送プロトコルのサポートに従って、要求クライアントＲＣ１によって提供され(又はコンテンツ処理コントローラ４１によって生成され)た第１伝送セッション識別子に対応する一つのセッションで伝送することができる。上記伝送は、コンテンツエクスポータ５２から順次実行される。コンテンツエクスポータ５２からコンテンツトランスフォーマ５１を経由してコンテンツインポータ５３に伝送されるコンテンツは、ニュートラルコンテンツの形態を有することができる。これまで説明したように、ニュートラルコンテンツは、所定のＤＲＭを用いることによって暗号化されないクリーンコンテンツを表すことができる。
【０３２２】
一方、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及び第１コンテンツインポータ５３ａは、コンテンツの伝送状態をコンテンツ処理コントローラ４１に報告することができる。このために、コンテンツ処理コントローラ４１は、コンテンツエクスポータ５２、コンテンツトランスフォーマ５１及び第１コンテンツインポータ５３ａにコンテンツ伝送状態イベントのサブスクリプションを要求し、イベントメッセージを受信する。イベントを例 ３-１で説明したので、イベントの詳細な説明を省略する。
【０３２３】
第１送信先デバイスＤＶ２−１へのコンテンツの伝送を完了するとき(段階Ｓ８６)、コンテンツ処理コントローラ４１は、コンテンツエクスポート要求及びコンテンツインポート要求をそれぞれ、第２コンテンツ変換チェーンに含まれるコンテンツエクスポータ５２及び第２コンテンツインポータ５３ｂに伝送する(段階Ｓ８７)。すなわち、二つのコンテンツ変換チェーンは、コンテンツ処理コントローラ４１の制御の下で伝送を順次実行する。当然、二つのコンテンツ変換チェーンを同時に生成し、コンテンツ処理コントローラの制御の下で二つのコンテンツ変換チェーンによって伝送が、実行される。
【０３２４】
コンテンツエクスポートを要求するとき、コンテンツ処理コントローラ４１は、第２伝送セッション識別子、要求された一つ以上コンテンツのコンテンツ識別子、受信部情報であるコンテンツインポータ５３の情報をコンテンツエクスポータ５２に提供することができる。また、コンテンツインポートを要求するとき、コンテンツ処理コントローラ４１は、第２伝送セッション識別子、要求された一つ以上のコンテンツのコンテンツ識別子、送信部であるコンテンツエクスポータ５２の情報等を第２コンテンツインポータ５３ｂに提供することができる。
【０３２５】
これまで説明したように、コンテンツエクスポータ５２及び第２コンテンツインポータ５３ｂがそれぞれコンテンツエクスポート要求及びコンテンツインポート要求をコンテンツ処理コントローラ４１から受け取るとき、第２コンテンツ変換チェーンを介してコンテンツの伝送が行われるとともにイベントの受け取りが行われる(段階Ｓ８８)。
【０３２６】
先ず、コンテンツエクスポータ５２と第２コンテンツインポータ５３ｂとの間にＳＡＣが確立される。ＳＡＣが確立されると、コンテンツエクスポータ５２は、コンテンツの伝送を開始する。このとき、コンテンツハンドラ対(すなわち、コンテンツエクスポータ５２-第２コンテンツインポータ５３ｂ)は、上記マルチ伝送プロトコルをサポートする。したがって、複数のコンテンツを、一つのセッションを介して伝送することができる。
【０３２７】
複数のコンテンツを、なマルチ伝送プロトコルのサポートに従って、要求クライアントＲＣ１によって提供され(又はコンテンツ処理コントローラ４１によって生成され)た第２伝送セッション識別子に対応する単一セッションを介して伝送することができる。上記伝送は、コンテンツエクスポータ５２から順次実行される。コンテンツエクスポータ５２から第２コンテンツインポータ５３ｂに伝送されるコンテンツは、ニュートラルコンテンツの形態を有する。これまで説明したように、ニュートラルコンテンツは、所定のＤＲＭを用いることによって暗号化されないクリーンコンテンツを表す。ニュートラルコンテンツが、第２送信先デバイスＤＶ２−２に含まれる第２コンテンツインポータ５３ｂに伝送されると、伝送を完了する(段階Ｓ８９)。
【０３２８】
一方、上記コンテンツエクスポータ５２及び第２コンテンツインポータ５３ｂは、コンテンツの伝送状態をコンテンツ処理コントローラ４１に報告することができる。このために、コンテンツ処理コントローラ４１は、コンテンツエクスポータ５２及び第２コンテンツインポータ５３ｂにコンテンツ伝送状態イベントのサブスクリプションを要求し、イベントメッセージを受信する。コンテンツ処理コントローラ４１は、各コンテンツの伝送状態を識別することができ、かつ、伝送状態情報を要求クライアントＲＣ１に提供することもできる。
【０３２９】
例 ３-２において、要求クライアントＲＣ１からの要求に従って複数個のコンテンツ変換チェーンを構成するとともにマルチセッションを介して単一コンテンツ又は複数コンテンツを伝送する手順を説明した。
【０３３０】
以下の例 ３-３において、要求クライアントＲＣ１によって要求されたコンテンツを、複数のコンテンツ変換チェーンを構成することによって単一の送信先に伝送する場合を説明する。例 ３-３において、二つのコンテンツ変換チェーンを構成する例を説明する。
【０３３１】
<例 ３-３>
図２７は、例 ３-３によるコンテンツ伝送手順のシステムの構成を示すブロック図である。
【０３３２】
図２７を参照すると、要求デバイスＤＶ１は、要求クライアントＲＣ１及びコンテンツエクスポータ５を有することができる。また、送信先デバイスＤＶ２は、コンテンツインポータ５３を有する。コンテンツ伝送コントローラ及びコンテンツトランスフォーマ５１を、要求デバイスＤＶ１又は送信先デバイスＤＶ２とは別個のデバイスに含むことができる。
【０３３３】
図２８は、例 ３-３によるコンテンツ伝送手順を示すフローチャートである。図２８は、要求クライアントＲＣ１の要求に応答して、要求デバイスＤＶ１に含まれる一つ以上のコンテンツを送信先である送信先デバイスＤＶ２に伝送する手順の例を示す。
【０３３４】
図２８を参照すると、先ず、要求クライアントＲＣ１は、コンテンツの伝送を要求するコンテンツ伝送要求メッセージを、コンテンツ処理コントローラ４１に伝送する(段階Ｓ１００)。このとき、コンテンツ伝送要求メッセージは、伝送セッション識別子、コンテンツ識別子、送信元情報、送信先情報等を含む。また、コンテンツ伝送要求メッセージは、コンテンツを受け取る送信先のＤＲＭシステム情報をオプションとして含むことができる。
【０３３５】
コンテンツ識別子は、伝送要求されたコンテンツを識別する情報を表すことができる。伝送要求されたコンテンツが複数であるとき、コンテンツを識別するコンテンツ識別子が複数存在することができる。
【０３３６】
伝送セッション識別子は、伝送セッションを独自に識別する識別子を表す。送信元情報は、要求されたコンテンツがどこから送信されるか決定する情報を表す。例 ３-３において、送信元情報は、要求デバイスＤＶ１の情報及びフォーマット情報を表すことができる。
【０３３７】
送信先情報は、要求されたコンテンツが伝送される送信先である送信先デバイスＤＶ２を識別する情報を含む。送信先情報は、送信先を識別する送信先識別子、送信先で要求されるファイルフォーマットの情報等を含むことができる。
【０３３８】
コンテンツ伝送要求メッセージを受信すると、コンテンツ処理コントローラ４１は、コンテンツハンドラの情報を収集し、コンテンツが伝送されるか否かを、収集された情報に基づいて決定する。コンテンツが伝送されることが決定されたとき、コンテンツ処理コントローラ４１は、伝送に関与するコンテンツハンドラを決定する(段階Ｓ１０１〜Ｓ１０３)。
【０３３９】
先ず、コンテンツ処理コントローラ４１は、一つ以上のコンテンツエクスポータ５２、コンテンツインポータ５３及びコンテンツトランスフォーマ５１に能力についての情報を問い合わせ、対応するエンティティから応答を得る。したがって、送信元、中間及び送信先のデバイス、システム及びＤＲＭの能力を認識することができる。
【０３４０】
情報が収集されると、コンテンツ処理コントローラ４１は、要求されたコンテンツを伝送するか否かを、収集された情報に基づいて決定する。すなわち、要求されたコンテンツをコンテンツハンドラが正常に伝送するか否かを検査する。ここで、要求されるコンテンツのフォーマット、システムのポリシー、エンティティ間で実行することができるセキュリティ認証チャネルアルゴリズム情報等を考慮することができる。
【０３４１】
コンテンツの伝送が決定されると、コンテンツ処理コントローラ４１は、コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１を決定し、コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１によって１次コンテンツ変換チェーンを構成するようコンテンツエクスポータ５２及びコンテンツトランスフォーマ５１を制御する。例 ３-３において、伝送要求されたコンテンツのフォーマットが送信先デバイスＤＶ２によって要求されるコンテンツのフォーマットと異なる例を説明する。したがって、コンテンツトランスフォーマ５１は、コンテンツ変換チェーンに含まれる必要がある。
【０３４２】
図２９は、コンテンツ処理コントローラ４１によって構成された１次コンテンツ変換チェーンの一例を示す。図２９を参照すると、１次コンテンツ変換チェーンは、コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１を含む。
【０３４３】
次いで、コンテンツ処理コントローラ４１は、コンテンツエクスポート要求及びコンテンツ変換要求をそれぞれ、１次コンテンツ変換チェーンに含まれたコンテンツエクスポータ５２及びコンテンツトランスフォーマ５１に送信する (段階Ｓ１０７、Ｓ１０８)。上記要求は、コンテンツハンドラに制御メッセージを伝送することによって行われる。
【０３４４】
コンテンツのエクスポートを要求するとき、コンテンツ処理コントローラ４１は、伝送セッション識別子、コンテンツ識別子、受信部であるコンテンツトランスフォーマ５１の情報等をコンテンツエクスポータ５２に提供することができる。また、コンテンツの変換を要求するとき、コンテンツ処理コントローラ４１は、伝送セッション識別子、コンテンツ識別子、送信部であるコンテンツエクスポータ５２の情報、受信部であるコンテンツインポータ５３の情報、要求されたコンテンツのフォーマット及び変換されたフォーマット情報等をコンテンツトランスフォーマ５１に提供することができる。
【０３４５】
これまで説明したように、コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１がそれぞれコンテンツエクスポート要求及びコンテンツ変換要求をコンテンツ処理コントローラ４１から受信すると、コンテンツエクスポータ５２とコンテンツトランスフォーマ５１との間にＳＡＣが確立される(段階Ｓ１０９)。コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１は、ＳＡＣが確立されたことをコンテンツ処理コントローラに報告することができる(段階Ｓ１１０及びＳ１１１)。
【０３４６】
ＳＡＣが確立されると、コンテンツエクスポータ５２は、コンテンツの伝送を開始する。このとき、各コンテンツハンドラ対(すなわち、コンテンツエクスポータ５２-コンテンツトランスフォーマ５１)はマルチ伝送プロトコルをサポートすることができる。これまで説明したように、マルチ伝送プロトコルは、単一セッションを介したマルチコンテンツの伝送を可能にする役割を果たす。要求されたコンテンツが複数であるとき、複数のコンテンツを、マルチ伝送プロトコルのサポートによって単一セッションを介して伝送することができる。
【０３４７】
上記伝送は、コンテンツエクスポータ５２から順次行われる。コンテンツエクスポータ５２は、要求されたコンテンツを、ＳＡＣを介してコンテンツトランスフォーマに伝送する。その後、コンテンツトランスフォーマ５１は、コンテンツのフォーマットを、要求されるフォーマットに変換する。
【０３４８】
コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１は、コンテンツの伝送状態又は変換状態をコンテンツ処理コントローラ４１に報告することができる。このために、コンテンツ処理コントローラ４１は、コンテンツのエクスポートを要求する前に所定のイベントの提供をコンテンツハンドラに要求することによって所定のイベントをサブスクライブする必要がある (段階Ｓ１０４〜Ｓ１０６)。
【０３４９】
所定のイベントは、コンテンツ伝送状態提供イベント及びコンテンツ変換状態提供イベントを含むことができる。これまで説明したように、伝送に関与するコンテンツハンドラは、コンテンツ伝送状態提供イベントを用いることによって、コンテンツの伝送開始、コンテンツの伝送、コンテンツの伝送完了、コンテンツの変換エラー等の状況をイベントメッセージとして報告することができるイベントである。
【０３５０】
コンテンツ変換状態提供イベントを、コンテンツトランスフォーマ５１によって実行することができる。コンテンツ処理コントローラ４１は、コンテンツ変換状態提供イベントの提供をコンテンツトランスフォーマ５１に要求することによって、コンテンツ変換状態提供イベントをサブスクライブすることができる。その後、コンテンツ処理コントローラ４１に、コンテンツの変換開始、コンテンツの変換、コンテンツの変換完了、コンテンツの変換エラー等の状況を提供することができる。
【０３５１】
コンテンツエクスポータ５２から伝送されたコンテンツがコンテンツトランスフォーマ５１に送信されると、コンテンツのフォーマット変換を完了するとき(段階Ｓ１１２)、コンテンツ処理コントローラ４１は、コンテンツトランスフォーマ５１及びコンテンツインポータ５３を有する２次コンテンツ変換チェーンを構成する必要がある。１次コンテンツ変換チェーン及び２次コンテンツ変換チェーンは、コンテンツ処理コントローラ４１の制御の下で順次動作する。
【０３５２】
図３０は、コンテンツ処理コントローラ４１によって構成される２次コンテンツ変換チェーンの一例を示す。
【０３５３】
図３０に示すように、２次コンテンツ変換チェーンは、コンテンツトランスフォーマ５１及びコンテンツインポータ５３を含む。コンテンツ処理コントローラ４１は、コンテンツ変換要求及びコンテンツインポート要求をそれぞれ、２次コンテンツ変換チェーンに含まれるコンテンツエクスポータ５２及びコンテンツトランスフォーマ５１に送信する(段階Ｓ１１３及びＳ１１４)。コンテンツトランスフォーマ５１とコンテンツインポータ５３との間にＳＡＣが確立される(段階Ｓ１１５)。このとき、コンテンツインポータ５３と送信先デバイスＤＶ２との間にＳＡＣを確立してもよい。
【０３５４】
コンテンツトランスフォーマ５１は、フォーマット変換されたコンテンツを、ＳＡＣを介してコンテンツインポータ５３に伝送する。その後、コンテンツインポータ５３は、送信されたコンテンツを受信する。コンテンツトランスフォーマ５１及びコンテンツインポータ５３は、コンテンツの伝送状態をコンテンツ処理コントローラ４１に報告することができる。コンテンツインポータ５３からコンテンツインポータ５３に伝送されるコンテンツは、ニュートラルコンテンツである。これまで説明したように、ニュートラルコンテンツは、所定のＤＲＭを用いることによって暗号化されないクリーンコンテンツを表す。
【０３５５】
例 ３-３において、二つのコンテンツ変換チェーンを構成することによって要求クライアントＲＣ１により要求されたコンテンツを単一の送信先へコンテンツを伝送する手順を説明した。
【０３５６】
以下の例 ３-４において、複数のコンテンツ変換チェーンを構成することによって要求クライアントＲＣ１により要求されたコンテンツを複数の送信先へコンテンツを伝送する場合を説明する。
【０３５７】
図３１は、例 ３-４によるコンテンツ伝送のシステムを示すブロック図である。
【０３５８】
図３１を参照すると、要求デバイスＤＶ１は、要求クライアントＲＣ１及びコンテンツエクスポータ５２を有することができる。また、第１送信先デバイスＤＶ２−１は、第１コンテンツインポータ５３ａを有する。第２送信先デバイスＤＶ２−２は、第２コンテンツインポータ５３ｂを有する。第３送信先デバイスＤＶ２−３は、第３コンテンツインポータ５３を有する。コンテンツ伝送コントローラ及びコンテンツトランスフォーマ５１を、要求デバイスＤＶ１又は送信先デバイスＤＶ２とは別個のデバイスに含むことができる。
【０３５９】
図３２は、例 ３-４によるコンテンツ伝送手順を示すフローチャートである。図３２は、要求クライアントＲＣ１の要求に応答して要求デバイスＤＶ１に含まれるコンテンツを三つの送信先である第１送信先デバイスＤＶ２−１、第２送信先デバイスＤＶ２−２及び第３送信先デバイスＤＶ２−３に伝送する手順の例を示す。
【０３６０】
図３２を参照すると、要求クライアントＲＣ１は、コンテンツの伝送を要求するコンテンツ伝送要求メッセージをコンテンツ処理コントローラ４１に伝送する(段階Ｓ１２１)。このとき、コンテンツ伝送要求メッセージは、伝送セッション識別子、コンテンツ識別子、送信元情報、送信先情報等を含む。また、コンテンツ伝送要求メッセージは、コンテンツを受信する送信先のＤＲＭシステム情報をオプションとして含むことができる。
【０３６１】
コンテンツ識別子は、伝送要求されたコンテンツを識別する情報を表すことができる。伝送要求されたコンテンツが複数である場合、コンテンツを識別するコンテンツ識別子が複数存在してもよい。
【０３６２】
伝送セッション識別子は、伝送セッションを独自に識別する識別子を表す。送信元情報は、要求されたコンテンツがどこから送信されるかを決定する情報を表す。例 ３-４において、送信元情報は、要求デバイスＤＶ１の情報及びフォーマット情報を含むことができる。
【０３６３】
送信先情報は、伝送要求されたコンテンツが伝送される送信先である送信先デバイスＤＶ２を識別する情報を含む。例 ３-４において、送信先情報は、第１送信先デバイスＤＶ２−１、第２送信先デバイスＤＶ２−２及び第３送信先デバイスＤＶ２−３の情報、送信先デバイスＤＶ２によって要求されるファイルフォーマット情報等を含むことができる。例 ３-４において、第１送信先デバイスＤＶ２−１、第２送信先デバイスＤＶ２−２及び第３送信先デバイスＤＶ２−３によって要求されるファイルフォーマットが同一であると仮定する。しかしながら、本発明はこれに限定されない。
【０３６４】
コンテンツ伝送要求メッセージを受信するとき、コンテンツ処理コントローラ４１は、コンテンツハンドラの情報を収集する(段階Ｓ１２２)。例えば、コンテンツ処理コントローラ４１は、一つ以上のコンテンツエクスポータ５２、コンテンツインポータ５３及びコンテンツトランスフォーマ５１に能力について問い合わせ、対応するエンティティから応答を得る。したがって、ソース、中間及び送信先のデバイス、システム及びＤＲＭの能力を認識することができる。
【０３６５】
情報が収集されるとき、コンテンツ処理コントローラ４１は、要求された一つ以上のコンテンツを伝送するか否かを、収集された情報に基づいて決定する(段階Ｓ１２３)。すなわち、要求されたコンテンツ伝送をコンテンツハンドラが正常に伝送するか否かを検査する。ここで、要求されるコンテンツのフォーマット、システムのポリシー、エンティティ間で実行することができるセキュリティ認証チャネルアルゴリズムの情報等を考慮することができる。
【０３６６】
コンテンツの伝送が決定されると、コンテンツ処理コントローラ４１は、コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１を有する１次コンテンツ変換チェーンを構成するようコンテンツエクスポータ５２及びコンテンツトランスフォーマ５１を制御する。例 ３-４において、伝送要求されたコンテンツのフォーマットが送信先デバイスＤＶ２で要求されるコンテンツのフォーマットと異なる場合の例を説明する。したがって、コンテンツトランスフォーマ５１は、コンテンツ変換チェーンに含まれる必要がある。この説明において、チェーンは、コンテンツ変換チェーンを構成する制御命令をクライアントから受信することによって構成される。しかしながら、発明はこれに限定されない。コンテンツ処理コントローラがチェーンを構成する制御命令を生成するとともにチェーンを構成する種々の実施の形態を考慮することができる。
【０３６７】
図３３は、コンテンツ処理コントローラ４１によって構成された１次コンテンツ変換チェーンの一例を示す。図３３を参照すると、１次コンテンツ変換チェーンは、コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１を含む。
【０３６８】
次いで、コンテンツ処理コントローラ４１は、コンテンツエクスポート要求及びコンテンツ変換要求をそれぞれ、次コンテンツ変換チェーンに含まれるコンテンツエクスポータ５２及びコンテンツトランスフォーマ５１に送信する(段階Ｓ１２４)。上記要求は、制御メッセージをコンテンツハンドラに送信することによって行われる。
【０３６９】
コンテンツのエクスポートを要求するとき、コンテンツ処理コントローラ４１は、伝送セッション識別子、コンテンツ識別子、受信部であるコンテンツトランスフォーマ５１の情報等をコンテンツエクスポータ５２に提供することができる。また、コンテンツの変換を要求すると、コンテンツ処理コントローラ４１は、伝送セッション識別子、コンテンツ識別子、送信部であるコンテンツエクスポータ５２の情報、受信部であるコンテンツインポータ５３の情報、要求されたコンテンツのコンテンツフォーマット及び変換されたフォーマットの情報等を提供することができる。
【０３７０】
これまで説明したように、コンテンツエクスポータ５２及びコンテンツインポータ５３が、コンテンツエクスポート要求及びコンテンツ変換要求をコンテンツ処理コントローラ４１から受信するとき、コンテンツエクスポータ５２とコンテンツトランスフォーマ５１との間にセキュリティ認証チャネルが確立される。
【０３７１】
セキュリティ認証チャネルが確立されるとき、コンテンツエクスポータ５２は、コンテンツの伝送を開始する(段階Ｓ１２５)。このとき、各コンテンツハンドラ対(すなわち、コンテンツエクスポータ５２-コンテンツトランスフォーマ５１)は、マルチ伝送プロトコルをサポートすることができる。マルチ伝送プロトコルがサポートされるので、複数のコンテンツの伝送が要求されるとき、複数のコンテンツを、シングルセッションを介して伝送することができる。
【０３７２】
上記送信は、コンテンツエクスポータ５２から順次実行される。コンテンツエクスポータ５２は、要求されたコンテンツを、ＳＡＣを介してコンテンツトランスフォーマ５１に伝送する。その後、コンテンツトランスフォーマ５１は、コンテンツのフォーマットを、送信先デバイスＤＶ２によって要求されるフォーマットに変換する(段階Ｓ１２６)。
【０３７３】
コンテンツエクスポータ５２及びコンテンツトランスフォーマ５１は、コンテンツの送信状態又は変換状態をコンテンツ処理コントローラ４１に報告することができる。このために、コンテンツ処理コントローラ４１は、コンテンツのエクスポートを要求する前に所定のイベントの提供をコンテンツハンドラに要求することによって所定のイベントをサブスクライブする必要がある。このとき、所定のイベントは、コンテンツ伝送状態提供イベント及びコンテンツ変換状態提供イベントを含むことができる。これを例 ３-３で説明したので、詳細な説明は省略する。
【０３７４】
コンテンツエクスポータ５２から伝送されたコンテンツがコンテンツトランスフォーマ５１に伝送され、コンテンツのフォーマット変換が完了したとき、コンテンツ処理コントローラ４１は、複数の送信先に対応する複数の２次コンテンツ変換チェーンを順次構成する。複数の２次コンテンツ変換チェーンは、第１の２次コンテンツ変換チェーン、第２の２次コンテンツ変換チェーン、第３の２次コンテンツ変換チェーンを含むことができる。ここで、第１の２次コンテンツ変換チェーン、第２の２次コンテンツ変換チェーン、第３の２次コンテンツ変換チェーンを、順次又は同時に構成することができる。また、コンテンツ変換チェーンを構成する方法は、開始点から送信先までチェーンを形成し、チェーンを繰り返し形成する方法(複数の単一チェーンは、例３-２で説明したようにして構成される。)又は（例３-３及び３-４で説明したように)変換回数に基づいてチェーンを区別することによってチェーンを個別に形成する方法を含むことができる。これら伝送セッション識別子を、クライアント、コンテンツ処理コントローラ４１又はコンテンツトランスフォーマ５１で生成することができる。
【０３７５】
図３４は、コンテンツ処理コントローラ４１によって誘導される第１の２次コンテンツ変換チェーン、第２の２次コンテンツ変換チェーン及び第３の２次コンテンツ変換チェーンの構成の一例を示す。
【０３７６】
図３４に示すように、第１の２次コンテンツ変換チェーンは、コンテンツトランスフォーマ５１及び第１コンテンツインポータ５３ａを含むことができる。コンテンツ変換コントローラは、コンテンツ変換要求及びコンテンツインポート要求をそれぞれコンテンツトランスフォーマ５１及び第１コンテンツインポータ５３ａに伝送する。コンテンツトランスフォーマ５１と第１コンテンツインポータ５３ａとの間にはＳＡＣが確立される。ＳＡＣが確立されると、コンテンツがコンテンツトランスフォーマ５１から第１コンテンツインポータ５３ａに伝送される(段階Ｓ１２７)。
【０３７７】
コンテンツが第１コンテンツインポータ５３ａに伝送されると、コンテンツ処理コントローラ４１は、第２の２次コンテンツ変換チェーンを構成する。このとき、第２の２次コンテンツ変換チェーンは、コンテンツトランスフォーマ５１及び第２コンテンツインポータ５３ｂを有することができる。コンテンツ変換コントローラは、コンテンツ変換要求及びコンテンツインポート要求をそれぞれコンテンツトランスフォーマ５１及び第２コンテンツインポータ５３ｂに伝送する。その後、コンテンツトランスフォーマ５１と第２コンテンツインポータ５３ｂとの間にＳＡＣが確立される。ＳＡＣが確立されると、コンテンツがコンテンツトランスフォーマ５１から第２コンテンツインポータ５３ｂに伝送される(段階Ｓ１２８)。
【０３７８】
コンテンツが第２コンテンツインポータ５３ｂに伝送されると、コンテンツ処理コントローラ４１は、第３の２次コンテンツ変換チェーンを構成する。このとき、第３の２次コンテンツ変換チェーンは、コンテンツトランスフォーマ５１及び第３コンテンツインポータ５３ｃを有することができる。コンテンツ変換コントローラは、コンテンツ変換要求及びコンテンツインポート要求をそれぞれコンテンツトランスフォーマ５１及び第３コンテンツインポータ５３ｃに伝送する。その後、コンテンツトランスフォーマ５１と第３コンテンツインポータ５３ｃとの間にＳＡＣが確立される。ＳＡＣが確立されると、コンテンツがコンテンツトランスフォーマ５１から第３コンテンツインポータ５３ｃに伝送される(段階Ｓ１２９)。
【０３７９】
一方、２次コンテンツ変換チェーンに含まれるコンテンツハンドラは、送信プロセスの進行によってコンテンツの伝送状態等を表すイベントメッセージをコンテンツ処理コントローラ４１に伝送することができる。上記イベントを、例 ３-１〜３-３で説明した。
【０３８０】
例 ３-４において、複数のコンテンツ変換チェーンを構成することにより要求クライアントＲＣ１によって要求されたコンテンツを複数の送信先デバイスＤＶ２に伝送する手順を説明した。例 ３-４によりコンテンツを伝送する方法において、コンテンツを複数の送信先にブロードキャストするとともに、送信資源の浪費を減少することができる。コンテンツを複数の送信先に送信するために実行されるコンテンツのフォーマット変換動作の回数を減少することができる。２次コンテンツ変換チェーンにエラーが発生したとしても、１次コンテンツ変換チェーンの動作は既に実行されており、したがって、２次コンテンツ変換チェーンのみ復元すればよい。
【０３８１】
４．処理制御部及びライセンス処理部の機能及び動作
一方、クライアント部の認証されたクライアントは、ライセンスの送信を処理制御部に要求することができる。例えば、第１ＤＲＭがインストールされた第１クライアントデバイス及び第２ＤＲＭがインストールされた第２クライアントデバイスが存在すると仮定する。ユーザが、上記第１クライアントデバイスに格納された第１ＤＲＭコンテンツを第２クライアントデバイスに伝送しようとするとき、第１クライアントは、コンテンツを伝送する上記手順を用いることによって、コンテンツを送信先である第２クライアントデバイスに伝送することができる。この場合、第２クライアントデバイスが、伝送されたコンテンツを使用しようとするとき、第２ＤＲＭに適切なライセンスが要求される。したがって、第１クライアントは、ライセンスの送信を要求する。
【０３８２】
図３５は、ライセンス伝送に関連するシステムの構成を示すブロック図である。
【０３８３】
図３５に示すように、処理制御部４０は、コンテンツ処理コントローラ４１及びライセンス処理コントローラ４２を含む。ここで、コンテンツ処理コントローラ４１は以前に説明した。コンテンツ処理コントローラ４１及びライセンス処理コントローラ４２を、ネットワークエリア又はローカルエリアのいずれの場所でも含むことができる。コンテンツ処理コントローラ４１及びライセンス処理コントローラ４２を、異なる領域に配置することができる。例えば、コンテンツ処理コントローラ４１を、ローカルエリアの所定のデバイスに含むことができる。ライセンス処理コントローラ４２を、ネットワークエリアのサービスプロバイダに含むことができる。コンテンツ処理コントローラ４１及びライセンス処理コントローラ４２の位置は限定されない。
【０３８４】
ライセンス処理コントローラ４２は、ライセンス伝送要求をクライアントから受信する。ライセンス伝送要求を受信すると、ライセンス処理コントローラ４２は、システムに含まれるエンティティの情報を収集することによって、伝送に関与するエンティティを決定すると共に、ライセンスを伝送することができるか否かを決定する。したがって、ライセンスが伝送されるチェーンを構成することができる。
【０３８５】
ライセンス処理コントローラ４２の他に認証及び管理部２０のライセンスマネージャ２４及びライセンス処理部３０のライセンスプロセッサ３２がライセンスの伝送に関与することができる。ライセンスの送信に関与するエンティティを、ネットワークエリア又はローカルエリアのいずれの場所でも含むことができる。伝送されるライセンス情報のセキュリティのためのＳＡＣを、必要に応じて所定のエンティティ間に確立することができる。
【０３８６】
ライセンス処理コントローラ４２は、所定のエンティティ、例えば、ライセンスマネージャ２４に一つ以上のニュートラルライセンスを要求し、一つ以上のニュートラルライセンスを受け取ることができる。ニュートラルライセンスは、多様なＤＲＭのライセンス情報を抽出することができる相互運用可能なニュートラルライセンス情報を表すことができる。ユーザが所定のＤＲＭコンテンツを購入するとき、ニュートラルライセンスを、ＤＲＭのライセンスを利用することによってライセンスマネージャに生成及び格納することができる。ニュートラルライセンス２４を、ライセンスマネージャ２４の他にドメインマネージャ又はレファレンスポイントコントローラに格納することができる。ライセンスを伝送する手順において、ニュートラルライセンスを提供するエンティティは、エクスポータの機能を実行することができる。
【０３８７】
ニュートラルライセンスは、一つ以上の関連のコンテンツ識別子、マネージャ情報、ライセンスを使用することができる主体の情報、権限の制限が記述された使用モデル等を含むことができる。
【０３８８】
ライセンス処理コントローラ４２は、提供されたニュートラルライセンスを用いることによって、実際に伝送される新たなニュートラルライセンスを生成する。このとき、コンテンツと主体との関係、送信先、主体のマッピング関係、リソースマッピング関係等の多様な情報を考慮することができる。
【０３８９】
ライセンス処理コントローラ４２によって生成されたニュートラルライセンスは、ライセンス処理部３０のライセンスプロセッサ３２に伝送される。ライセンスプロセッサ３２は、ライセンス処理コントローラ４２から受信したニュートラルライセンスを送信先のネイティブＤＲＭの受信部９００に伝送するエンティティである。このとき、ライセンスプロセッサ３２は、送信先のＤＲＭで規定した方法に従うことによって、受信したニュートラルライセンスを送信先のＤＲＭに適切なライセンスに変換し、変換されたライセンスをネイティブＤＲＭの受信部９００に提供することができる。また、ニュートラルライセンスをそのまま送信先のネイティブＤＲＭの受信部９００に提供することができる。この場合、ライセンス変換は、送信先のＤＲＭシステムで実行される。ライセンスプロセッサ及びネイティブＤＲＭの受信部はそれぞれ、トランスフォーマ及び受信部の機能を実行することができる。
【０３９０】
ライセンスの伝送に関与するエンティティは、ライセンスの伝送及び処理の手順を表すイベントメッセージをライセンス処理コントローラ４２に送信することができる。このために、ライセンス処理コントローラ４２は、ライセンス伝送状態イベントの提供を対応するエンティティに要求することによってライセンス伝送状態イベントにサブスクライブする必要がある。ライセンス処理コントローラ４２は、受信したイベントメッセージに対応する情報をクライアント３に提供することができる。また、ライセンス処理コントローラ４２は、ニュートラルライセンスの生成の手順、ニュートラルライセンスをライセンスマネージャ２４から提供する手順等の進行状態を表すイベントメッセージをクライアントに提供することができる。
【０３９１】
これまで、クライアント部１０、認証及び管理部２０、処理制御部４０、コンテンツ処理部５０及びライセンス処理部３０を有するＤＲＭ相互運用システムの主要機能を説明した。上述した説明において、本発明の典型的な実施の形態によるＤＲＭ相互運用システムは、クライアントからのデータ(コンテンツ又はライセンス)伝送要求に応答して、ニュートラルデータ(ニュートラルフォーマットコンテンツ又はニュートラルライセンス)を、送信先によって要求されるフォーマットに適合させ、ニュートラルデータを送信先に伝送することができる。
【０３９２】
５．単位エンティティの機能及びイベントを処理する手順
ＤＲＭ相互運用システムの各部、例えば、クライアント部１０、認証及び管理部２０、処理制御部４０、コンテンツ処理部５０及びライセンス処理部３０等は、一つ以上のエンティティによって構成される。このとき、エンティティは、固有の機能を実行するソフトウェア又はハードウェアとして構成されたモジュール又はデバイスを表すことができる。各エンティティを、所定のユニット機能を実行する一つ以上の単位機能モジュールによって構成することができる。エンティティは、所定のインタフェースを介して他のエンティティとデータ通信を行うために所定の装置にインストールされる。また、エンティティが同一部に属するとしても、エンティティを異なるデバイスにインストールすることができる。デバイスは、実行環境に従って異なることができる。
【０３９３】
ドメインが最初に構成されると、エンティティは、エンティティの存在を、エンティティが含まれる特定の環境の他のエンティティに報告することができる。このために、エンティティは、単位機能モジュールである構成情報プロバイダを有することができる。
【０３９４】
図３６は、エンティティに含まれる単位機能モジュール及び単位機能モジュールの機能を説明する例を示す。
【０３９５】
図３６に示すように、所定のエンティティ１１０は、固有の単位機能を実行する複数の単位機能モジュール１１１と、構成情報プロバイダ１１２とを有する。構成情報プロバイダ１１２は、他のエンティティである要求エンティティ１１４から構成情報を提供する要求に応答して所定のエンティティ１１０の構成情報を提供する必要がある。このとき、構成情報は、所定のエンティティ１１０に含まれる単位機能モジュール１１１の情報を含むことができる。
【０３９６】
また、構成情報変更イベントをサブスクライブするよう他のエンティティによって構成情報プロバイダ１１２に要求することができる。その後、構成情報プロバイダ１１２は、サブスクリプション要求が合法であるか否かを決定することによってサブスクリプションを許可し又は許可しない。このとき、構成情報変更イベントは、特定エンティティ１１０の構成情報を変更するときの所定のエンティティ１１０の構成情報の変更を含むイベントメッセージを表すことができる。
【０３９７】
構成情報変更イベントを、プッシュ又はプル方式で提供することができる。プッシュ方式において、構成情報プロバイダ１１２は、変更された構成情報を含むイベントメッセージを、イベントをサブスクライブする要求エンティティ１１４にプッシュする。プル方式において、イベントをサブスクライブする要求エンティティ１１４は、必要に応じて所定のエンティティ１１０の変更された構成情報を取得する。要求エンティティがイベントのサブスクリプションを要求するとき、イベントメッセージがプッシュ方式とプル方式のいずれよって伝送されたかが構成情報プロバイダ１１２に報告される。したがって、イベントメッセージがプッシュ方式とプル方式のいずれよって伝送されたかが設定される。
【０３９８】
構成情報変更イベントの他に、上記コンテンツ変換状態イベント、構成情報変換イベント等の多様なイベントが存在する。以下、エンティティ間でイベントを実行する手順を説明する。
【０３９９】
図３７は、認証された二つのエンティティ間でイベントを伝送する手順を説明する例を示す。
【０４００】
図３７に示すように、所定のイベントを実行するためにイベントサブスクライバ機能を有するエンティティ及びイベント発行機能を有するエンティティが存在する必要がある。以下、イベントサブスクライバ機能を有するエンティティをイベントサブスクリプションエンティティ１１７と称する。イベント発行機能を有するエンティティをイベント発行エンティティ１１９と称する。また、イベントはイベントタイトルを有することができる。イベントタイトルは、イベントがコンテンツ伝送状態イベント、構成情報変換イベント等のうちのどのイベントであるかを表す情報である。
【０４０１】
イベント発行エンティティ１１９は自身の固有の識別子を有する必要がある。この理由は、イベント発行エンティティ１１９によって実行されるイベントと同一タイトルを有するイベントを実行する他のイベントからイベント発行エンティティ１１９を区分するためである。イベント発行エンティティ１１９の固有の識別子は、イベント発行エンティティ１１９によって発行されたイベントメッセージの送信元を表す因子を含むことができる。
【０４０２】
特定なイベントをサブスクライブするために、イベントサブスクリプション「エンティティ１１７は、所定のイベントを発行するイベント発行エンティティ１１９にイベントのサブスクリプションを要求する必要がある。
【０４０３】
イベントのサブスクリプションを要求するとき、イベントサブスクリプションエンティティ１１７は、イベント発行エンティティ１１９がイベントサブスクリプションエンティティ１１７を識別することを許容する固有の識別子を提供する。また、イベントサブスクリプションエンティティ１１７は、イベント発行エンティティ１１９によって提供されるイベントがプッシュ方式とプル方式のいずれによって提供されるかをイベント発行エンティティ１１９に報告する必要がある。したがって、イベントがプッシュ方式とプル方式のいずれによって提供されるか設定される。このとき、プッシュ方式において、イベント発行エンティティ１１９は、イベント条件が発生する度に対応する情報を有するイベントメッセージをイベントサブスクリプションエンティティ１１７に自動的にプッシュする。一方、プル方式において、イベントサブスクリプションエンティティ１１７は、必要に応じてイベント発行エンティティ１１９を問い合わせるとともにイベントメッセージを取得する。
【０４０４】
また、イベントサブスクリプションエンティティ１１７は、イベントサブスクリプションＩＤ、期限切れ情報、提供されることが所望されるイベント情報の構造等をイベント発行エンティティ１１９に提供することができる。期限切れ情報は、イベントのサブスクリプション期限切れ値を表すことができる。例えば、期限切れ情報は、期限切れの日付、イベントのサブスクリプション期間等を含むことができる。期限切れ情報が提供されないとき、サブスクリプション期間は制限されない。
【０４０５】
イベント発行エンティティ１１９は、イベントサブスクリプション要求に応答して、イベントサブスクリプションが有効であるか否かを決定することによってサブスクリプションを許可し又は許可しない。このとき、サブスクリプションの許可を表す情報とサブスクリプションの不許可を表す情報を有する応答メッセージを、決定結果に応じてイベントサブスクリプションエンティティ１１７に伝送する。
【０４０６】
決定において、イベントサブスクリプションＩＤ、期限切れ情報等を考慮することができる。例えば、イベントのサブスクリプションを要求するときにイベントサブスクリプションＩＤがイベントサブスクリプションエンティティ１１７から提供される場合、イベント発行エンティティ１１９は、イベントサブスクリプションＩＤが有効であるか否か及びイベントサブスクリプションＩＤが期限切れであるか否か考慮することができる。このとき、イベントサブスクリプションエンティティ１１７によって提供されたイベントサブスクリプションＩＤが有効でない又は期限切れである場合、イベント発行エンティティ１１９は、サブスクリプションの不許可を表すメッセージをイベントサブスクリプションエンティティ１１７に伝送することができる。一方、イベントサブスクリプションエンティティ１１７によって提供されたイベントサブスクリプションＩＤが有效であるとともに期限切れでないとき、サブスクリプションＩＤ及びサブスクリプションＩＤの情報を用いることができる。また、イベントのサブスクリプションを要求するときにイベントサブスクリプションＩＤがイベントサブスクリプションエンティティ１１７によって提供されない場合、イベント発行エンティティ１１９は、新たなイベントサブスクリプションＩＤを提供することができる。
【０４０７】
一方、イベントサブスクリプションエンティティ１１７は、イベントの現在のサブスクリプションを取り消すことができる。このために、イベントサブスクリプションエンティティ１１７は、イベントの取り消しを表すメッセージをイベント発行エンティティ１１９に送信することができる。また、イベントサブスクリプションエンティティ１１７は、設定されたイベント提供方法を取り消すことによってイベントのサブスクリプションを中止することができる。例えば、イベントをサブスクライブするためにプッシュ方式又はプル方式として現在選択されているイベントを提供する方法において、プッシュ方式及びプル方式の選択が取り消される。
【０４０８】
これまで、エンティティ間の構成情報及びイベントの処理方法を説明した。上記方法を介して、特定の状況によりエンティティが互いに情報のやり取りを行うことができる。
【０４０９】
６．ドメイン管理方法及びインフラシステム
以下、ドメイン位置の移動を管理することができるドメイン管理方法及びインフラシステムを説明する。このために、ドメインを管理するドメインマネージャを用いることによって、ドメインの現在及び過去の位置を格納及び管理することができる。また、ドメインの位置の移動を、所定の制限に従って制限することができる。
【０４１０】
ＤＲＭ相互運用システムは、ドメイン位置の移動の情報を管理する。具体的には、ＤＲＭ相互運用システムは、ドメインの移動位置又は移動回数を制限する。ドメインの位置変動を検査することによってドメインが制限範囲から外れて形成されるとき、ＤＲＭ相互運用システムは、ドメインを破棄し又は別の動作を行う。
【０４１１】
以下、ドメインの位置移動情報を管理することができるドメイン管理方法を説明する。説明するドメイン管理方法の実施の形態は、ドメインの移動回数を制限する方法、ドメインの形成位置を制限する方法等を含むことができる。理解の便宜のために、前者を例 ４-１と称し、後者を例 ４-２と称する。また、例 ４-１及び例 ４-２のシステムの原理を図２に示す。
【０４１２】
<例 ４-１>
図３８は、例 ４-１によるドメイン管理方法を説明するフローチャートである。図３８は、ログイン情報に対応するドメインの移動許容回数Ｎａを設定する手順、ドメインの移動回数を検査する手順及びドメインの形成を制限する手順を示す。
【０４１３】
ドメインマネージャ２２は、ログイン情報に対応するドメイン移動許容回数Ｎａを格納する。ログイン情報をライセンスマネージャ２４によって提供することができる。ドメインマネージャ２２がログイン機能を提供することもできる。ドメイン移動許容回数Ｎａは、ユーザによって支払われた費用に依存することができる。回数の上限を、サービスプロバイダによってポリティカルに設定することができる。ドメイン移動許容回数Ｎａを、例えば、５、１０等に設定することができる。また、ドメインマネージャ２２は、ドメインの現在位置と過去位置を格納及び管理する。ドメインが移動すると、ドメインマネージャ２２は、移動回数を格納及び管理する。
【０４１４】
図３８を参照すると、ドメインマネージャ２２は、現在のドメイン５の位置を検査し(段階Ｓ１４０)、ドメインが移動した否か決定する(段階Ｓ１４１)。具体的には、現在のドメイン位置と以前の検査から得られたドメイン位置とを比較することによってドメインが移動したか否かを決定する。決定を、所定の周期ごとに実行することができる。選択的に、新たなドメインが形成される度に決定を行うことができる。選択的に、サービスプロバイダのモニタリングに応じて決定を任意に行うことができる。
【０４１５】
ドメイン５のレファレンスポイントコントローラ２６は、ドメイン５の位置の決定に関与することができる。このとき、レファレンスポイントコントローラ２６を、ローカルドメインの形成位置の基準点とすることができる。レファレンスポイントコントローラ２６を、ローカルエリアでドメイン５に加入した所定のデバイスに含むことができる。レファレンスポイントコントローラ２６は、ドメイン５内の情報、例えば、ドメイン５の位置の情報をドメインの他のクライアントデバイスの代表としてドメインマネージャ２２に報告する。
【０４１６】
一方、レファレンスポイントコントローラ２６は、ドメイン５の位置の決定に関与しなくてもよい。各デバイスは、ドメインマネージャ２２にアクセスすることによってドメインの位置の情報を提供することができる。すなわち、レファレンスポイントコントローラ２６は、ドメインの位置の決定に関与しても関与しなくてもよい。これは、実行環境に従った選択的な要因である。
【０４１７】
したがって、ドメイン５の位置は、ドメインのレファレンスポイントコントローラ２６の位置又は各デバイスの位置を表すことができる。一方、レファレンスポイントコントローラ２６を含むレファレンスポイントコントローラの選択回数を所定の回数に制限することによってセキュリティを向上することができる。また、ユーザは、レファレンスポイントコントローラ２６を介してログインすることができる。
【０４１８】
ドメインの位置を決定する方法を、以下説明する。
【０４１９】
第１の方法において、レファレンスポイントコントローラ２６のＩＰアドレスを用いることによってドメインの位置を決定することができる。この場合、第１の方法を、高速インターネットプロバイダが固定ＩＰを割り当てモデルで実施することができる。
【０４２０】
第２の方法において、レファレンスポイントコントローラ２６のＩＰサブネットアドレスを用いることによってドメインの位置を決定することができる。例えば、サブネットアドレスが、以前に検出されたサブネットアドレスと同一であるとき、ドメインが移動していないとみなされる。サブネットアドレスが変更されたとき及びＴＴＬが３ホップ以内にないとき、ドメインが移動したとみなされる。
【０４２１】
第３の方法において、ドメインがレファレンスポイントコントローラ２６の隣接領域に入るとき、レファレンスポイントコントローラ２６のメディアアクセス制御(ＭＡＣ)アドレスを利用することによってドメインの位置を認識する。例えば、高速インターネットプロバイダによって別個のレファレンスポイントコントローラとみなされるセットップボックスを家に設置するとき、セットトップボックスの周辺がドメインとして設定される。有線又は無線でセットップバックスに接続されたデバイスは、装置が所定のドメインに入っているものと認識される。したがって、デバイスの位置を指定することができる。
【０４２２】
第４の方法において、全地球測位システム(ＧＰＳ)を用いることによってドメインの位置を決定することができる。
【０４２３】
第５の方法において、携帯電話のような移動体端末の場合、ドメインのデバイスの位置を基地局によって決定することができる。
【０４２４】
一方、ドメインが移動すると、ドメインマネージャ２２は、ドメインの以前の移動回数を１増分し(段階Ｓ１４２)、ドメインのこれまで増分した移動総数Ｎを確認する(段階Ｓ１４３)。一方、ドメインが移動しないとき、現在形成されたドメイン５を維持する(段階Ｓ１４７)。
【０４２５】
次いで、ドメインマネージャ２２は、ドメインの現在の移動総数Ｎと、格納されたドメインの移動許容回数Ｎａとを比較する(段階Ｓ１４４)。比較結果として、ドメインの移動総数Ｎがドメインの移動許容回数Ｎａ以下である場合、ドメインマネージャ２２は現在のドメイン５を維持する(段階Ｓ１４７)。一方、ドメインの移動総数Ｎがドメインの移動許容回数Ｎａより大きい場合、ドメインマネージャ２２は、現在のドメインの使用を禁止する(段階Ｓ１４５)。
【０４２６】
次に、ドメインマネージャ２２は、現在のユーザに対するサービス停止の履歴を記録する(段階Ｓ１４６)。付加的に、ドメインマネージャは、ドメイン破棄の情報をサービスプロバイダに報告する。サービスプロバイダ又はドメインマネージャ２２は、ユーザに警告メッセージを伝送することができる。また、サービスプロバイダ又はドメインマネージャ２２は、消費者支払いシステムを介して新たなドメインログイン情報を購入するようユーザに促す。
【０４２７】
一方、ドメインの累積移動回数を、サービスプロバイダのポリシーに従って周期的にリセットすることができる。例えば、ドメインの移動回数を毎年リセットすることができる。
【０４２８】
<例 ４-２>
図３９は、例 ４-２によるドメイン管理方法を説明するためのフローチャートである。図３９は、ドメインの形成位置を検査することによってドメインの生成を制限する手順を示す。
【０４２９】
このために、ドメインマネージャ２２は、ログイン情報に対応するドメイン位置許容個数Ｍａを格納する。このドメイン位置許容個数Ｍａは、ユーザが支払った費用に依存する。個数の上限は、サービスプロバイダによってポリティカルに設定される。ドメイン位置許容個数Ｍａを、５、８等に設定することができる。また、ドメインマネージャ２２は、ドメインの現在及び過去位置を格納及び管理する。
【０４３０】
図３９を参照すると、ドメインマネージャ２２は、現在のドメイン位置を検査し(段階Ｓ１５０)、ドメイン５が移動したか否か決定する(段階Ｓ１５１)。具体的には、現在のドメイン位置と以前の検査から得られたドメイン位置とを比較することによってドメインが移動したか否かを決定する。決定を、所定の周期ごとに実行することができる。選択的に、新たなドメインが形成される度に決定を行うことができる。選択的に、サービスプロバイダのモニタリングに応じて決定を任意に行うことができる。
【０４３１】
これまで説明したように、レファレンスポイントコントローラ２６は、ドメイン５の位置の決定に関与しても関与しなくてもよい。ドメイン５の位置を、ＩＰアドレス、ＩＰサブネットアドレス、レファレンスポイントコントローラ２６のＭＡＣ情報、ＧＰＳ、移動通信情報等を用いることによって決定することができる。
【０４３２】
ドメインが移動しないとき、ドメインマネージャ２２は、現在のドメイン５を維持する(段階Ｓ１５８)。一方、ドメインが移動するとき、ドメインマネージャ２２は、ドメイン５の現在の位置と格納された以前のドメインの位置とを比較することによってドメインの現在の位置が新たな位置であるか否か決定する(段階Ｓ１５２)。
【０４３３】
ドメインの現在の位置が新たな位置ではない場合、ドメインマネージャ２２は現在のドメイン５を維持する(段階Ｓ１５８)。一方、ドメインの現在の位置が新たな位置である場合、ドメインマネージャ２２は、ドメインの現在の位置を格納する(段階Ｓ１５３)。
【０４３４】
次いで、ドメインマネージャ２２は、ドメイン５の現在の位置を含むドメイン形成位置の総数Ｍを取得し(段階Ｓ１５４)、取得した数Ｍと所定のドメイン位置許容個数Ｍａとを比較する(段階Ｓ１５５)。比較の結果、ドメイン形成位置の総数Ｍがドメイン位置許容個数Ｍａ以下であるとき、ドメインマネージャ２２は現在のドメイン５を維持する(段階Ｓ１５８)。一方、ドメイン形成位置の総数Ｍがドメイン位置許容個数Ｍａより大きい場合、ドメインマネージャ２２は、現在のドメイン５を破棄する(段階Ｓ１５６)。
【０４３５】
次に、ドメインマネージャ２２は、現在のユーザに対するサービス停止の履歴を記録する。付加的に、ドメインマネージャは、ドメイン破棄の情報をサービスプロバイダに報告する。サービスプロバイダ又はドメインマネージャ２２は、警告メッセージをユーザに伝送することもできる。
【０４３６】
これまで説明したように、例 ４-２において、ドメインマネージャ２２は、ドメインの形成位置に従ってドメインの形成を制限する。例えば、サービスプロバイダが４個のドメイン形成位置を許容すると、ドメインマネージャ２２は、ドメインの第１位置からドメインの４個の位置を自動的に記憶し、ドメインの次の形勢位置が許容された４個の位置から逸脱するか否か決定する。ドメインが、記憶された位置からのみ形成されるとき、ドメインが頻繁に移動するとしても、ドメインの移動は制限されない。また、ドメインが、記憶された４個の位置以外の位置に移動すると、ドメインマネージャ２２は、ドメインの形成を制限する。
【０４３７】
一方、ユーザの行動範囲を完全に変更した場合、例えば、ユーザが新しい家に引っ越しする場合、ドメインの位置がドメインの以前の位置に一致しないとき、ドメイン形成位置を、ドメインマネージャ２２によって最初に記憶されたドメイン形成位置以外に移動した位置に基づいて新たに格納する必要がある。この場合、ドメイン形成位置の情報を、ユーザの特別な要求に応答して新たにリセットすることができる。
【０４３８】
また、ドメイン形成位置の情報を、サービスプロバイダのポリシーによってリセットすることができる。この場合、リセット回数を制限することができる。例えば、ドメイン形成位置の情報のリセット回数を、１年に一回又は二回に制限することができる。一方、ドメイン形成位置の情報の変更を、ＩＰアドレスの変更に加えてサービスサブスクリプションコンテンツ及びサービスログイン情報を用いることによって定義することができる。
【０４３９】
これまで、ドメインマネージャ２２を介してドメインの現在及び過去の位置を格納及び管理し、所定の制限に基づいてドメインの移動回数を制限することができるドメイン管理方法を説明した。
【０４４０】
７．コンテンツの誤用及び汚染を防止する構成、動作及びシナリオ
ＤＲＭ相互運用システムを介する異種ＤＲＭ間のコンテンツ共有環境において信頼性のないコンテンツ、例えば、不適切なコンテンツ、汚染されたコンテンツ等が取り込まれるとき、ユーザ又はシステムに害が及ぼされることがある。害に対処することができるシステム及びシナリオが要求される。
【０４４１】
以下、外部から取り込まれたコンテンツが誤用されたか否か、汚染されたか否か、セキュリティ機能を適用したか否かを検査することによって適切な対策を講じることができるＤＲＭ相互運用システムを用いたコンテンツの処理方法を説明する。
【０４４２】
図４０は、異種のＤＲＭ間で相互運用することができる環境のシステムの構成を示すブロック図である。
【０４４３】
図４０に示すように、ＤＲＭ相互運用システム３４０は、所定のＤＲＭ領域、例えば、第１ＤＲＭ領域３２０及び第２ＤＲＭ領域３３０間が相互運用することができるようにＤＲＭ相互運用機能を提供する。図４０において、ＤＲＭ相互運用システムを用いることによって二つのＤＲＭ領域を相互運用する場合を説明する。本発明は、これに限定されない。ＤＲＭ相互運用システムを用いることによって、三つ以上のＤＲＭ領域を相互運用することができる。
【０４４４】
第１ＤＲＭ領域３２０は、第１サービスプロバイダ３２２によって用いられる第１ＤＲＭを使用するシステム又はデバイスを含むＤＲＭ保護領域を表すことができる。
【０４４５】
第１ＤＲＭ領域３２０は、第１ＤＲＭシステム３２３を有することができる。第１ＤＲＭシステム３２３は、第１コンテンツプロバイダ３２２によって提供されるソースコンテンツに第１ＤＲＭを適用することによって第１ＤＲＭコンテンツ及び第１ＤＲＭコンテンツを使用する権限情報である第１ライセンスを生成し、生成された第１ＤＲＭコンテンツ及び第１ライセンスを第１クライアントデバイス２１０に提供する役割を果たす。このとき、第１クライアントデバイス２１０は、第１ＤＲＭがインストールされたデバイスを表すことができる。したがって、第１クライアントデバイス２１０は、第１ライセンスによって許容される権限範囲で第１ＤＲＭコンテンツを用いることができる。また、図４０において、第１コンテンツプロバイダ３２５は、第１サービスプロバイダ３２２から切り離されている。しかしながら、本発明は、これに限定されない。第１コンテンツプロバイダ３２５を、第１サービスプロバイダ３２２と同一とすることができる。第１コンテンツプロバイダ３２５を第１サービスプロバイダ３２２に含むこともできる。
【０４４６】
第１ＤＲＭシステム３２３は、第１セキュリティシステム３２４と情報をやり取りすることができる。第１セキュリティシステム３２４は、第１ＤＲＭコンテンツにセキュリティ機能を適用するために用いられる。例えば、システムを、コンテンツを用いるユーザを追跡する追跡機能を提供するフィンガプリンティングシステム、著者の著作権を保護するウォーターマーキングシステム、コンテンツのウイルス汚染を検査し及び治療するアンチウイルスシステム、コンテンツの誤用の可能性を防止する誤用防止システム又は侵入検知システム（ＩＤＳ）とすることができる。
【０４４７】
第２ＤＲＭ領域３３０は、上記第１ＤＲＭ領域３２０のＤＲＭと異なるＤＲＭを用いる。すなわち、第２ＤＲＭ領域３３０は、第２サービスプロバイダ３３２によって用いられる第２ＤＲＭを使用するシステム又はデバイスを含むＤＲＭ保護領域を表すことができる。
【０４４８】
第２ＤＲＭ領域３３０は、第２ＤＲＭシステム３３３を有することができる。第２ＤＲＭシステム３３３は、第２コンテンツプロバイダ３３５によって提供されたソースコンテンツに第２ＤＲＭを適用することによって第２ＤＲＭコンテンツ及び第２ＤＲＭコンテンツを使用する権限情報である第２ライセンスを生成し、生成した第２ＤＲＭコンテンツ及び第２ライセンスを第２クライアントデバイス３３１に提供する役割を果たす。このとき、第２クライアントデバイス３３１は、第２ＤＲＭがインストールされたデバイスを表すことができる。したがって、第２クライアントデバイス３３１は、第２ライセンスによって許容される権限範囲で第２ＤＲＭコンテンツを用いることができる。図４０において、第２コンテンツプロバイダ３３５は、第２サービスプロバイダ３３２から切り離されている。しかしながら、本発明は、これは限定されない。第２コンテンツプロバイダ３３５を第２サービスプロバイダ３３２と同一にすることができる。第２コンテンツプロバイダ３３５を第２サービスプロバイダ３３２に含むことができる。
【０４４９】
第２ＤＲＭシステム３３３は、第２セキュリティシステム３３４とデータをやり取りすることができる。第２セキュリティシステム３３３は、第２ＤＲＭコンテンツにセキュリティ機能を適用するためのシステムである。例えば、システムを、ウォーターマーキングシステム、フィンガプリンティングシステム、アンチウイルスシステム、誤用防止システム又はＩＤＳとすることができる。
【０４５０】
図４１は、ＤＲＭ領域の詳細な構成を示すブロック図である。図４１に示すＤＲＭ領域の構成を、図４０に示す第１ＤＲＭ領域３２０又は第２ＤＲＭ領域３３０の構成に普通に適用することができる。
【０４５１】
図４１を参照すると、コンテンツプロバイダ３８０は、未加工データの形態又はウォーターマークのような所定のセキュリティ機能が適用されるコンテンツをＤＲＭシステム３７１に提供する。
【０４５２】
ＤＲＭシステム３７１のＤＲＭサーバ３７２は、暗号化モジュールを用いることによって提供されたコンテンツを暗号化し、コンテンツを暗号化するのに用いられる秘密鍵値及びライセンス情報を、暗号化されたコンテンツと共にクライアントデバイス３６０に伝送する。ライセンス情報をライセンスサーバ３７５によって提供することができる。暗号化されたコンテンツを受信するクライアントデバイス３６０のクライアントＤＲＭモジュール３６１は、暗号化されたコンテンツを解読することによってコンテンツを復元する。
【０４５３】
また、フィンガプリンティング情報を、クライアントデバイス３６０に伝送されるコンテンツに挿入することができる。フィンガプリンティング情報の挿入を、サービスプロバイダ３７０に含まれるフィンガプリンティングシステム３７６によって実行する。フィンガプリンティングシステム３７６は、フィンガプリンティングコード発生器３７７、インスペクタ３７８、フィンガプリンティングエンジン３７９等を有することができる。クライアントデバイス３６０のユーザを識別するフィンガプリンティング情報を、クライアントデバイス３６０に伝送されるコンテンツに挿入することができる。フィンガプリンティング情報の挿入を、クライアントデバイス３６０に含まれるフィンガプリンティングエンジンによって実行することができる。
【０４５４】
図４１において、フィンガプリンティング機能をコンテンツに適用する例を説明した。しかしながら、コンテンツに適用することができるセキュリティ機能を、上記ウォーターマーキング、アンチウイルス、誤用防止又はＩＤＳとすることができる。
【０４５５】
図４１及び４２に示すように、フィンガプリンティングシステム、ウォーターマーキングシステム、アンチウイルスシステム、誤用防止システム、ＩＤＳ等のセキュリティ機能をコンテンツに適用するセキュリティシステムを、ＤＲＭ領域のサービスプロバイダに設置することができる。また、セキュリティシステムを、ＤＲＭ相互運用システムに設置することもできる。
【０４５６】
図４２は、ＤＲＭ相互運用システムの構成を示すブロック図である。図４２は、ＤＲＭ相互運用システムが外部から取り込まれたコンテンツの信頼性を保障する機能を有する場合を示す。
【０４５７】
図４２に示すように、ＤＲＭ相互運用システムは、セキュリティシステム９及びコンテンツ信頼性管理部８を更に有することができる。これまで説明したように、セキュリティシステム９は、フィンガプリンティングシステム、ウォーターマーキングシステム、アンチウイルスシステム、誤用防止システム、ＩＤＳ等を表すことができる。セキュリティシステム９をＤＲＭ相互運用システム５００に含むことができる。ＤＲＭ相互運用システム５００は、他のセキュリティシステムと情報をやり取りすることができる。
【０４５８】
コンテンツ信頼性管理部８は、外部のネイティブＤＲＭ領域と情報をやり取りすることができ、コンテンツの信頼性を保障するための各種プロセスを有する。コンテンツの取り込みを外部から要求されると、コンテンツ信頼性管理部８のプロセスを自動的に実行することができる。プロセスを、処理制御部の要求に応答して実行することもできる。コンテンツ信頼性管理部８のプロセスを、以下のシナリオに従って説明する。
【０４５９】
以下、ＤＲＭ相互運用環境でコンテンツを伝送するとき、コンテンツの信頼性を保障することができるシナリオを説明する。このとき、ＤＲＭ相互運用環境において、コンテンツを、所定のＤＲＭ領域からＤＲＭ相互運用システムを経て対象のＤＲＭ領域に伝送することができる。
【０４６０】
先ず、以下の説明において、ＤＲＭコンテンツを送信するときに誤用防止ポリシーを適用することができるシナリオ、ＤＲＭが他のＤＲＭとの相互運用を許容されるときにウイルスによって汚染されたコンテンツが広まるのを防止することができるシナリオ、ＤＲＭが他のＤＲＭとの相互運用を許容されるときにウォーターマーキング機能を適用することができるシナリオ、ＤＲＭが他のＤＲＭとの相互運用を許容されるときにウォーターマーキング機能を適用することができる他のシナリオ、ＤＲＭが他のＤＲＭとの相互運用を許容されるときにフィンガプリンティング機能を適用することができるシナリオ、ＤＲＭが他のＤＲＭとの相互運用を許容されるときにフィンガプリンティング機能を適用することができる他のシナリオ、フィンガプリント情報が格納された情報と一致しないユーザがコンテンツの伝送を要求するときに用いられる処理シナリオを順に説明する。理解の便宜のために、第１のシナリオを例 ５-１と称し、第２のシナリオを例 ５-２と称し、第３のシナリオを例 ５-３と称し、第４のシナリオを例 ５-４と称し、第５のシナリオを例 ５-５と称し、第６のシナリオを例 ５-６と称し、第７のシナリオを例 ５-７と称する。
【０４６１】
<例 ５-１>
図４３は、例 ５-１によるＤＲＭ相互運用システムのコンテンツ処理方法を説明する機能ブロック図である。図４３は、ＤＲＭ相互運用環境においてＤＲＭコンテンツを伝送するときにコンテンツの誤用防止ポリシーを適用することができる手順を示す。
【０４６２】
誤用防止ポリシーは、ＤＲＭコンテンツが不適切に用いられる場合を防止するよう設計される。例えば、誤用防止ポリシーは、１９歳未満のユーザによって使用することができないアダルトコンテンツを未成年者が視聴するのを予め防止するポリシーを含む。
【０４６３】
図４３に示すように、ＤＲＭ相互運用システム５００は、第１ＤＲＭ領域に含まれる第１クライアントデバイス４１０から第２ＤＲＭ領域６００に含まれる第２クライアントデバイス６１０に所定のコンテンツを伝送することを要求するコンテンツ要求メッセージを受信する(段階Ｓ１７０)。コンテンツ伝送要求メッセージは、伝送要求されたコンテンツ、コンテンツを送信する送信部情報、コンテンツを受信する受信部情報等を含むことができる。このとき、要求されたコンテンツが、第１ＤＲＭ領域４００に含まれる第１クライアントデバイス４１０から伝送されるので、要求されたコンテンツは、第１ＤＲＭが適用されるコンテンツを表すことができる。
【０４６４】
コンテンツ伝送要求を受信すると、ＤＲＭ相互運用システム５００は、受信したコンテンツ伝送要求メッセージから送信部情報及び受信部情報を抽出する(段階Ｓ１７１)。次いで、ＤＲＭ相互運用システム５００は、抽出された送信部情報に対応する送信ユーザ情報を提供するよう第１ＤＲＭ領域４００の所定のエンティティに要求し(段階Ｓ１７２)、受信部情報に対応する受信ユーザ情報を提供するよう第２ＤＲＭ領域６００の所定のエンティティに要求する(段階Ｓ１７３)。
【０４６５】
このとき、第１ＤＲＭ領域４００の所定のエンティティを第１サービスプロバイダ４２０とすることができる。第２ＤＲＭ領域６００の所定のエンティティを第２サービスプロバイダ６２０とすることができる。その後、第１サービスプロバイダ４２０及び第２サービスプロバイダ６２０は、要求に応答して送信ユーザ情報及び受信ユーザ情報をＤＲＭ相互運用システム５００に提供する(段階Ｓ１７４、Ｓ１７５)。送信ユーザ情報及び受信ユーザ情報を、ＤＲＭ相互運用システム５００と各サービスプロバイダ４２０、６２０と間で要求及び応答をやり取りすることによって伝送することができる。
【０４６６】
送信ユーザ情報は、コンテンツを伝送する第１クライアントデバイス４１０のユーザ情報を表すことができる。また、受信ユーザ情報は、コンテンツを受信する第２クライアントデバイス６１０のユーザ情報を表すことができる。送信ユーザ情報及び受信ユーザ情報は、コンテンツ誤用防止ポリシーを適用する判断基準となるユーザの所定の情報、例えば、ユーザの年令情報を含むことができる。
【０４６７】
次いで、ＤＲＭ相互運用システム５００は、第１ＤＲＭ領域４００の所定のエンティティを要求し、例えば、コンテンツ情報を提供することを第１サービスプロバイダ４２０に要求する(段階Ｓ１７６)。第１サービスプロバイダ４２０は、要求に応答してコンテンツ情報を提供する(段階Ｓ１７７)。このとき、コンテンツ情報は、コンテンツ誤用防止のための制限情報を含むことができる。例えば、コンテンツ情報は、コンテンツを使用することができる年令制限の情報を含むことができる。
【０４６８】
次に、ＤＲＭ相互運用システム５００は、コンテンツ情報と送信及び受信ユーザ情報を比較及び分析することによってコンテンツの誤用の可能性を決定し(段階Ｓ１７８)、判断結果に依存して、コンテンツを第２クライアントデバイス６１０に伝送するか否かを、第１クライアントデバイス４１０に報告する(段階Ｓ１７９)。また、ＤＲＭ相互運用システム５００は、コンテンツを伝送するか否かを第２クライアントデバイス６１０に報告することができる。コンテンツの誤用の可能性は、ＤＲＭ相互運用システム５００又は外部の誤用防止システムによって決定される。
【０４６９】
例えば、コンテンツ情報に含まれる年令制限情報が１９歳未満が許可されないことを表し、送信ユーザの年令が１５歳であるとき、ＤＲＭ相互運用システム５００は、要求されたコンテンツが誤用である可能性があると決定し、コンテンツを伝送することができないことを表すメッセージを第１クライアントデバイス４１０に報告し、手順を中止する。
【０４７０】
一方、受信及び送信ユーザの年令が２４歳であるとき、ＤＲＭ相互運用システム５００は、要求されたコンテンツが誤用である可能性がないと決定し、コンテンツを正常に伝送することを表すメッセージを第１クライアントデバイス４１０に報告する。正常な伝送の報告後、ＤＲＭ相互運用システム５００は、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換し (段階Ｓ１８０)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ１８１)。
【０４７１】
コンテンツ誤用防止ポリシーを、ＤＲＭ相互運用システム５００及びサービスプロバイダ４２０、６２０に関連したＤＲＭプロバイダ(図示せず)の協議又は認可によって決定され及び許容することができる。また、第１ＤＲＭ領域４００、ＤＲＭ相互運用システム５００及び第２ＤＲＭ領域６００間の通信メッセージを、拡張マークアップ言語（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）又は一般的なデータのフォーマットで通信することができる。通信が行われるとき、新暗号規格（ＡＥＳ(Advanced Encryption Standard)）の１２８ビット以上のセキュリティチャネルを提供することができる。
【０４７２】
<例 ５-２>
図４４は、例 ５-２によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明する機能ブロック図である。図４４は、ＤＲＭが他のＤＲＭとの相互運用が許容されるときにウイルスによって汚染されたコンテンツが広まるのを防止する手順を示す。
【０４７３】
図４４に示すように、ＤＲＭ相互運用システム５００は、第１クライアントデバイス４１０から第２クライアントデバイス６１０に所定のコンテンツを伝送することを要求するコンテンツ伝送要求メッセージを受信する(段階Ｓ１９０)。コンテンツ伝送要求メッセージは、伝送要求されたコンテンツを含む。要求されたコンテンツが、第１ＤＲＭ領域４００に含まれる第１クライアントデバイス４１０から伝送されるので、コンテンツは、第１ＤＲＭが適用されたコンテンツを表す。
【０４７４】
コンテンツ伝送要求メッセージを受信すると、ＤＲＭ相互運用システム５００は、要求されたコンテンツを分析することによってコンテンツが汚染されたか否か決定する(段階Ｓ１９２)。決定結果に従って、ＤＲＭ相互運用システム５００は、コンテンツを第２クライアントデバイス６１０に伝送するか否か決定し、決定結果を第１クライアントデバイス４１０に報告する(段階Ｓ１９３)。このとき、ＤＲＭ相互運用システム５００は、決定結果を第２クライアントデバイス６１０にも報告することができる。
【０４７５】
例えば、ＤＲＭ相互運用システム５００は、要求されたコンテンツに対するウイルスチェックを実行する。コンテンツがウイルスに汚染されているとき、ＤＲＭ相互運用システム５００は、コンテンツを伝送することができないことを決定し、決定結果を表すメッセージを第１クライアントデバイス４１０に報告し、手順を中止する。この場合、第１クライアントデバイス４１０又は第１サービスプロバイダ４２０は、コンテンツからウイルスを取り除くことができる。次に、第１クライアントデバイス４１０は、コンテンツを再送信するようＤＲＭ相互運用システム５００に要求する。
【０４７６】
一方、要求されたコンテンツがウイルスに汚染されていない場合、ＤＲＭ相互運用システム５００は、コンテンツを正常に伝送すると決定し、決定結果を表すメッセージを第１クライアントデバイス４１０に報告する。
【０４７７】
次いで、ＤＲＭ相互運用システム５００は、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換するＤＲＭ変換を実行し (段階Ｓ１９３)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ１９４)。
【０４７８】
一方、ＤＲＭ相互運用システム５００は、コンテンツの汚染の可能性を決定する。コンテンツが汚染されているとき、ＤＲＭ相互運用システムは、コンテンツからウイルスを取り除き、コンテンツを正常に伝送することができる。この場合、ＤＲＭ相互運用システム５００は、コンテンツからウイルスを取り除くことができるツール若しくはシステムを有し、又はネットワークを介して接続された別個のアンチウイルスシステムにコンテンツからウイルスを取り除くよう要求することができる。また、コンテンツを汚染するウイルスの詳述及びクリーニング結果を第１クライアントデバイス４１０に報告することができる。
【０４７９】
<例 ５-３>
図４５は、例 ５-３によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明する機能ブロック図である。図４５は、ＤＲＭが他のＤＲＭとの相互運用が許容されるときにウォーターマーキング機能を適用することができる例を示す。
【０４８０】
図４５に示すように、ＤＲＭ相互運用システム５００は、第１クライアントデバイス４１０から第２クライアントデバイス６１０に所定のコンテンツの伝送を要求するコンテンツ伝送要求メッセージを受信する(段階Ｓ１９５)。コンテンツ伝送要求メッセージは、伝送要求されたコンテンツを含む。要求されたコンテンツが、第１ＤＲＭ領域４００に含まれる第１クライアントデバイス４１０から伝送されるので、コンテンツは、第１ＤＲＭが適用されたコンテンツを表す。
【０４８１】
コンテンツ伝送要求メッセージを受信すると、ＤＲＭ相互運用システム５００は、伝送要求されたコンテンツを分析することによってウォーターマークが挿入されているか否か決定する(段階Ｓ１９６)。ウォーターマークがコンテンツに挿入されているとき、ＤＲＭ相互運用システム５００は、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換するＤＲＭ変換を実行し (段階Ｓ２０１)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ２０２)。
【０４８２】
一方、要求されたコンテンツにウォーターマークが挿入されていない場合、ＤＲＭ相互運用システム５００は、第１ＤＲＭ領域４００の所定のエンティティ、例えば、第１サービスプロバイダ４２０にウォーターマーキングプロセスを要求する(段階Ｓ１９７)。具体的には、転送要求されたコンテンツにウォーターマークを挿入することを要求する。その後、ウォーターマーキングプロセスの実行が要求された第１サービスプロバイダ４２０は、伝送要求されたコンテンツにウォーターマークを挿入し(段階Ｓ１９８)、ＤＲＭ相互運用システム５００にコンテンツの伝送を再要求する(段階Ｓ１９９)。
【０４８３】
ＤＲＭ相互運用システム５００は、要求されたコンテンツにウォーターマークが挿入されたか否か検査し(段階Ｓ２００)、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換するＤＲＭ変換を実行し (段階Ｓ２０１)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ２０２)。
【０４８４】
一方、ウォーターマーキング機能を提供するエンジンが第１クライアントデバイス４１０に設置されているとき、ＤＲＭ相互運用システム５００は、第１クライアントデバイス４１０にウォーターマーキングプロセスの実行を要求することができる。このとき、第１クライアントデバイス４１０は、ウォーターマークを生成するための著作権情報の提供を第１サービスプロバイダ４２０又はコンテンツプロバイダに要求し、著作権情報を取得することができる。
【０４８５】
これまで、ＤＲＭが他のＤＲＭとの相互運用が許容されるときにウォーターマークを挿入する手順を、図４５を参照した説明した。図４５に示す手順を実行するために、ウォーターマーキング機能を提供するウォーターマーキングシステムを、第１ＤＲＭ領域４００の所定のエンティティに含む必要がある。一方、ウォーターマーキングシステムが第１ＤＲＭ領域４００の所定のエンティティに含まれないとき、ＤＲＭ相互運用システム５００は、ウォーターマーキングプロセスを実行し又は別個のウォーターマーキングシステムにウォーターマーキングプロセスを実行するよう要求することもできる。これらの場合を、図４６を参照して以下で説明する。
【０４８６】
<例 ５-４>
図４６は、例 ５-４によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明する機能ブロック図である。図４６は、ＤＲＭが他のＤＲＭとの相互運用が許容されるときにウォーターマーキング機能を適用することができる他の例を示す。
【０４８７】
図４６に示すように、ＤＲＭ相互運用システム５００は、第１クライアントデバイス４１０から第２クライアントデバイス６１０に所定のコンテンツの伝送を要求するコンテンツ伝送要求メッセージを受信する(段階Ｓ２１０)。コンテンツ伝送要求メッセージは、伝送要求されたコンテンツを含む。要求されたコンテンツが、第１ＤＲＭ領域４００に含まれる第１クライアントデバイス４１０から伝送されるので、コンテンツは、第１ＤＲＭが適用されたコンテンツを表す。
【０４８８】
コンテンツ伝送要求メッセージを受信すると、ＤＲＭ相互運用システム５００は、伝送要求されたコンテンツを分析することによってウォーターマークが挿入されているか否か決定する(段階Ｓ２１１)。ウォーターマークがコンテンツに挿入されているとき、ＤＲＭ相互運用システム５００は、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換するＤＲＭ変換を実行し (段階Ｓ２１５)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ２１６)。
【０４８９】
一方、要求されたコンテンツにウォーターマークが挿入されていない場合、ＤＲＭ相互運用システム５００は、要求されたコンテンツの著作権保持者の情報を提供するよう第１ＤＲＭ領域４００の所定のエンティティ、例えば、第１サービスプロバイダ４２０に要求する(段階Ｓ２１２)。具体的には、著作権保持者の情報をコンテンツプロバイダの情報とすることができる。この場合、ＤＲＭ相互運用システム５００は、著作権保持者の情報を第１サービスプロバイダ４２０に要求することができる。一方、ＤＲＭ相互運用システム５００は、著作権保持者の情報をコンテンツプロバイダに直接要求することもできる。例 ５-４において、著作権保持者の情報を第１サービスプロバイダ４２０によって提供すると仮定する。しかしながら、本発明は、これに限定されない。
【０４９０】
第１サービスプロバイダ４２０は、ＤＲＭ相互運用システム５００から伝送された著作権保持者の情報の要求に応答して、著作権保持者の情報をＤＲＭ相互運用システム５００に提供する(段階Ｓ２１３)。その後、ＤＲＭ相互運用システム５００は、ＤＲＭ相互運用システム５００によって提供された著作権保持者の情報を利用することによってウォーターマークを生成し、伝送要求されたコンテンツを暗号化し、生成されたウォーターマークをコンテンツに挿入するウォーターマーキングプロセスを実行する(段階Ｓ２１４)。このとき、ＤＲＭ相互運用システム５００は、ウォーターマーキングシステムを有することができ、ウォーターマーキングシステムを利用することができる。ＤＲＭ相互運用システム５００は、ネットワークに接続された別個のウォーターマーキングシステムに直接ウォーターマーキングを実行するよう要求することができる。
【０４９１】
ウォーターマーキングプロセスを完了すると、ＤＲＭ相互運用システム５００は、ＤＲＭ変換プロセスを実行する(段階Ｓ２１５)。具体的には、ライセンス情報とウォーターマークが挿入されたコンテンツに適用されるコンテンツ保護技術とが、対象のＤＲＭである第２ＤＲＭに変換される。次いで、ＤＲＭ相互運用システム５００は、変換されたコンテンツを第２クライアントデバイス６１０に伝送する(段階Ｓ２１６)。
【０４９２】
一方、ＤＲＭ相互運用システム５００は、別個のウォーターマーキングシステムのアドレス情報、例えば、ＵＲＬアドレスを第１クライアントデバイス４１０に提供することによってウォーターマーキングプロセスを実行することができる。この場合、第１クライアントデバイス４１０は、ウォーターマーキングプロセスに必要な著作権の情報を提供することを第１サービスプロバイダ４２０又はコンテンツプロバイダに直接要求することができる。ＤＲＭ相互運用システム５００は、第１サービスプロバイダ４２０によって提供された著作権の情報をＵＲＬアドレスと共に第１クライアントデバイス４１０に提供することができる。また、ＤＲＭ相互運用システム５００は、第１ＤＲＭ領域４００の第１サービスプロバイダ４２０又はコンテンツプロバイダに別個のウォーターマーキングシステムのＵＲＬアドレスを提供してウォーターマーキングを実行することができる。
【０４９３】
<例 ５-５>
図４７は、例 ５-５によりＤＲＭ相互運用システムによってコンテンツを処理する方法を説明する機能ブロック図である。図４７は、ＤＲＭが他のＤＲＭとの相互運用が許容されるときにフィンガプリンティング機能を適用することができる例を示す。
【０４９４】
図４７に示すように、ＤＲＭ相互運用システム５００は、第１クライアントデバイス４１０から第２クライアントデバイス６１０に所定のコンテンツの伝送を要求するコンテンツ伝送要求メッセージを受信する(段階Ｓ２２１)。コンテンツ伝送要求メッセージは、要求されたコンテンツを含む。要求されたコンテンツが、第１ＤＲＭ領域４００に含まれる第１クライアントデバイス４１０から伝送されるので、コンテンツは、第１ＤＲＭが適用されたコンテンツを表す。
【０４９５】
コンテンツ伝送要求メッセージを受信すると、ＤＲＭ相互運用システム５００は、伝送要求されたコンテンツを分析することによって第１クライアントデバイス４１０のユーザ情報に含まれるフィンガプリントがコンテンツに挿入されているか否か決定する(段階Ｓ２２２)。決定プロセスを、コンテンツ伝送要求を受信した直後又はＤＲＭ変換を実行する直前に実行することができる。
【０４９６】
フィンガプリントがコンテンツに正常に挿入されていると判断されると、ＤＲＭ相互運用システム５００は、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換するＤＲＭ変換を実行し (段階Ｓ２２７)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ２２８)。
【０４９７】
一方、伝送要求されたコンテンツにフィンガプリントが挿入されていないとき、ＤＲＭ相互運用システム５００は、フィンガプリンティング処理を実行するよう第１クライアントデバイス４１０に要求する(段階Ｓ２２３)。具体的には、第１クライアントデバイス４１０のユーザ情報を含むフィンガプリントは、伝送要求されたコンテンツに挿入するよう要求される。
【０４９８】
このとき、ＤＲＭ相互運用システムは、ＵＲＬトリガー又はバックチャネルを介して、フィンガプリンティングプロセスを実行するフィンガプリンティングエンジンを提供するのに必要なアドレス情報、例えば、ＵＲＬを第１クライアントデバイス４１０に提供することができる。フィンガプリンティングアルゴリズムが著しく多様であるので、ＤＲＭ相互運用システム５００は、全てのフィンガプリンティングアルゴリズムを格納し及び管理することができない。したがって、ＤＲＭ相互運用システム５００は、第１ＤＲＭ領域４００で用いられるアルゴリズムを有するフィンガプリンティングエンジンをダウンロードすることができるフィンガプリンティングシステムのアドレスを第１クライアントデバイス４１０に提供する必要がある。フィンガプリンティングシステムのアドレスを、ＤＲＭ相互運用システム５００と第１サービスプロバイダ４２０との間で要求及び応答をやり取りすることによって得ることができる。
【０４９９】
フィンガプリンティングシステムを第１サービスプロバイダ４２０に含むことができる。フィンガプリンティングシステムを、第１サービスプロバイダ４２０と情報をやり取りする所定のサーバとすることができる。しかしながら、フィンガプリンティング機能が第１ＤＲＭ領域４００に含まれないとき、第１サービスプロバイダ４２０はフィンガプリンティング機能を提供することができない。この場合、ＤＲＭ相互運用システム５００は、フィンガプリンティングエンジンを提供することができる個別のフィンガプリンティングシステムのアドレス情報を第１クライアントデバイスに提供することができる。また、所定のフィンガプリンティングエンジンが第１クライアントデバイス４１０にインストールされているとき、ＤＲＭ相互運用システム５００は、追加のアドレス情報を伝送しなくてもよく、インストールされたフィンガプリンティングエンジンを介してフィンガプリンティングプロセスを実行するようクライアントデバイス４１０に要求することができる。
【０５００】
フィンガプリンティング処理を実行するよう要求された第１クライアントデバイス４１０は、ＤＲＭ相互運用システム５００から受信したアドレス情報を用いてフィンガプリンティングエンジンをダウンロードすることによってフィンガプリンティングプロセスを実行し又はインストールされたフィンガプリンティングエンジンを利用することによってフィンガプリンティングプロセスを実行することができる(段階Ｓ２２４)。具体的には、ユーザ情報を含むフィンガプリンティング上記要求されたコンテンツに挿入される。
【０５０１】
次いで、第１クライアントデバイス４１０は、フィンガプリントが挿入されたコンテンツを第２クライアントデバイス６１０に伝送するようＤＲＭ相互運用システム５００に要求する(段階Ｓ２２５)。その後、ＤＲＭ相互運用システム５００は、要求されたコンテンツにフィンガプリントが挿入されたか否か検査し(段階Ｓ２２６)、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換するＤＲＭ変換を実行し (段階Ｓ２２７)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ２２８)。
【０５０２】
一方、図示してないが、ＤＲＭ相互運用システム５００は、コンテンツを受信する第２クライアントデバイス６１０にフィンガプリンティングプロセスを要求することができる。この場合、ＤＲＭ相互運用システム５００は、フィンガプリンティングプロセスを実行することができるフィンガプリンティングシステムのアドレス情報を第２クライアントデバイス６１０に提供することができる。このとき、フィンガプリンティングシステムのアドレス情報を、ＤＲＭ相互運用システム５００と第２サービスプロバイダ６１０との間で要求及び応答をやり取りすることによって取得することができる。また、第２サービスプロバイダ６１０がフィンガプリンティング機能を有しないとき、ＤＲＭ相互運用システム５００は、別個のフィンガプリンティングシステムのアドレスを提供することができる。
【０５０３】
<例 ５-６>
図４８は、例 ５-６によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明する機能ブロック図である。図４８は、ＤＲＭが他のＤＲＭとの相互運用が許容されるときにフィンガプリンティング機能を適用することができる他の例を示す。例 ５-６において、ＤＲＭ相互運用システムはフィンガプリンティングエンジンを有する。
【０５０４】
図４８に示すように、ＤＲＭ相互運用システム５００は、第１クライアントデバイス４１０から第２クライアントデバイス６１０に予定のコンテンツの伝送を要求するコンテンツ伝送要求メッセージを受信する(段階Ｓ２３０)。コンテンツ伝送要求メッセージは、伝送要求されたコンテンツを含む。要求されたコンテンツが、第１ＤＲＭ領域４００に含まれる第１クライアントデバイス４１０から伝送されるので、コンテンツは、第１ＤＲＭが適用されたコンテンツを表す。受信したコンテンツ伝送要求メッセージは、送受信ユーザ情報、すなわち、第１クライアントデバイス４１０及び第２クライアントデバイス６１０のユーザ情報が含まれる。
【０５０５】
次いで、ＤＲＭ相互運用システム５００は、伝送要求されたコンテンツを分析することによって第１クライアントデバイス４１０のユーザ情報に含まれるフィンガプリントがコンテンツに挿入されているか否か決定する(段階Ｓ２３１)。転送要求されたコンテンツにフィンガプリントが挿入されているとき、ＤＲＭ相互運用システム５００は、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とを第１ＤＲＭから第２ＤＲＭに変換するＤＲＭ変換を実行し (段階Ｓ２３３)、変換結果を第２クライアントデバイス６１０に伝送する(段階Ｓ２３４)。
【０５０６】
一方、伝送要求されたコンテンツにフィンガプリントが挿入されていないとき、ＤＲＭ相互運用システム５００は、ＤＲＭ相互運用システム５００に含まれるフィンガプリンティングエンジンを用いることによって、受信した第１クライアントデバイス４１０のユーザ情報を含むフィンガプリントを生成し、伝送要求されたコンテンツを暗号化し、生成したフィンガプリントをコンテンツに挿入するフィンガプリンティングプロセスを実行する(段階Ｓ２３２)。フィンガプリンティングエンジンは、キャッシュ形態でＤＲＭ相互運用システム５００の所定のデバイスに格納される。フィンガプリンティングエンジンは、フィンガプリンティングプロセスを実行するときに動作することができる。
【０５０７】
フィンガプリンティング実行段階(段階Ｓ２３３)が完了すると、ＤＲＭ相互運用システム５００はＤＲＭ変換プロセスを実行する(段階Ｓ２３３)。
【０５０８】
具体的には、ライセンス情報と要求されたコンテンツに適用されるデータ保護技術とが、対象のＤＲＭである第２ＤＲＭに変換される。次いで、ＤＲＭ相互運用システム５００は、変換されたコンテンツを第２クライアントデバイス６１０に伝送する(段階Ｓ２３４)。
【０５０９】
一方、ＤＲＭ相互運用システム５００は、コンテンツを受信する第２クライアントデバイス６１０の情報を含むフィンガプリントをコンテンツに挿入することができる。この場合、ＤＲＭ相互運用システム５００は、対応するフィンガプリンティングエンジンをキャッシュ形態で格納する必要がある。
【０５１０】
<例 ５-７>
図４９は、例 ５-７によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明する機能ブロック図である。図４９は、フィンガプリント情報がユーザ情報に一致しないユーザがコンテンツ伝送を要求するときにコンテンツフィンガプリント情報がユーザ情報に一致しないことをコンテンツを有し又は分配するシステムに報告する手順を示す。
【０５１１】
図４９に示すように、ＤＲＭ相互運用システム５００は、第１クライアントデバイス４１０から第２クライアントデバイス６１０に所定のコンテンツの伝送を要求するコンテンツ伝送要求メッセージを受信する(段階Ｓ２５０)。コンテンツ伝送要求メッセージは、送受信ユーザ情報、すなわち、第１クライアントデバイス４１０及び第２クライアントデバイス６１０のユーザ情報が受信される。また、伝送要求コンテンツにフィンガプリントが挿入されている。
【０５１２】
ＤＲＭ相互運用システム５００は、伝送要求されたコンテンツに挿入されたフィンガプリント情報に含まれるユーザ情報及び第１クライアントデバイス４１０のユーザ情報を比較及び分析する(段階Ｓ２５１)。フィンガプリントに含まれるユーザ情報と第１クライアントデバイス４１０のユーザ情報が一致しないエラーが発見されると(段階Ｓ２５２)、ＤＲＭ相互運用システム５００は、エラーが発生したことを第１クライアントデバイスに報告する(段階Ｓ２５４)。また、ＤＲＭ相互運用システム５００は、コンテンツの共有が認可されないことを表す不認可を第２クライアントデバイス６１０に伝送する(段階Ｓ２５３)。したがって、フィンガプリントが第１クライアントデバイス４１０のユーザ情報に一致しない違法コンテンツを伝送することができない。
【０５１３】
本発明を、特に本発明の典型的な実施の形態を参照しながら図示し及び説明したが、添付した請求の範囲によって規定したような本発明の範囲を逸脱することなく形態及び詳細の多様な変更を行うことができることは、当業者によって理解することができる。
【０５１４】
これまで説明したように、本発明の実施の形態によるＤＲＭ相互運用システムの多様な伝送形式のデータを提供することができる。具体的には、データを一つ以上の送信先に送信するためにマルチチェーンを構成することによってデータを効率的に伝送することができる。また、各チェーンを介して伝送されるデータの伝送状態を、イベントメッセージとして提供することができる。
【図面の簡単な説明】
【０５１５】
【図１】本発明の典型的な実施の形態によるＤＲＭ相互運用システムの概念及び主要機能を説明するブロック図である。
【図２】本発明の典型的な実施の形態によるＤＲＭ相互運用システムの線形的な構成を示すブロック図である。
【図３】クライアントが処理制御部にコンテンツ伝送を要求する例を示す図である。
【図４】クライアントが処理制御部にライセンス伝送を要求する例を示す図である。
【図５】ドメイン、ドメインを構成するエンティティ及びエンティティ間の相関を示すブロック図である。
【図６】レファレンスポイントコントローラを選択するのに必要なＤＰＤＵデータパケットのフォーマットの例を示す図である。
【図７】ＤＰＤＵを用いることによってレファレンスポイントコントローラを自動的に選択する手順を示すフローチャートである。
【図８】例 １-２によりレファレンスポイントコントローラを選択する方法を示すフローチャートである。
【図９】例 ２-１によりレファレンスポイントコントローラ候補を選択する方法を示すフローチャートである。
【図１０】レファレンスポイントコントローラとレファレンスポイントコントローラ候補との間で情報信号を伝送のための接続を示すブロック図である。
【図１１】典型的なドメインデバイスと典型的なドメイン候補デバイスが情報信号を伝送する例を示すブロック図である。
【図１２】レファレンスポイントコントローラプロキシの概念を説明するブロック図である。
【図１３】レファレンスポイントコントローラの登録の手順を説明するフローチャートである。
【図１４】レガシーデバイスの固有の情報を管理する構成の例を示す図である。
【図１５】レガシーデバイスを認証する手順を説明するフローチャートである。
【図１６】レガシーデバイスを使用するユーザの情報を管理するＤＲＭ相互運用システムの構成の例を示す図である。
【図１７】レガシーデバイスをドメインに登録する手順を説明するフローチャートである。
【図１８】処理制御部及びコンテンツ処理部の構成を示すブロック図である。
【図１９】コンテンツ処理コントローラ及びコンテンツハンドラの配置を説明する例を示す図である。
【図２０】コンテンツ処理コントローラ及びコンテンツハンドラの他の配置を説明する例を示す図である。
【図２１】コンテンツ処理コントローラ及びコンテンツハンドラを用いることによってコンテンツを伝送する手順を示すフローチャートである。
【図２２】マルチ伝送プロトコルを説明する例を示す図である。
【図２３】例 ３-２によりコンテンツ伝送手順のシステムの構成を示すブロック図である。
【図２４】例 ３-２によるコンテンツ伝送手順を示すフローチャートである。
【図２５】一つ以上のコンテンツを第１送信先デバイスに伝送する第１コンテンツ変換チェーンを示す図である。
【図２６】一つ以上のコンテンツを第２送信先デバイスに伝送する第２コンテンツ変換チェーンを示す図である。
【図２７】例 ３-３によるコンテンツ伝送手順のシステムの構成を示すブロック図である。
【図２８】例 ３-３によるコンテンツ伝送手順を示すフローチャートである。
【図２９】コンテンツ処理コントローラによって構成された１次コンテンツ変換チェーンの例を示す図である。
【図３０】コンテンツ処理コントローラによって構成された２次コンテンツ変換チェーンの例を示す図である。
【図３１】例 ３-４によるコンテンツ伝送のシステムを示すブロック図である。
【図３２】例 ３-４によるコンテンツ伝送手順を示すフローチャートである。
【図３３】コンテンツ処理コントローラによって構成された１次コンテンツ変換チェーンの例を示す図である。
【図３４】コンテンツ処理コントローラによって生じた第１の２次コンテンツ変換チェーン、第２の２次コンテンツ変換チェーン及び第３の２次コンテンツ変換チェーンの構成の例を示す図である。
【図３５】ライセンスの伝送に関連したシステムの構成を示すブロック図である。
【図３６】エンティティに含まれる単位機能モジュール及び単位機能モジュールの機能を説明する例を示す図である。
【図３７】認証された二つのエンティティ間でイベントを伝送する手順を説明する例を示す図である。
【図３８】例 ４-１によりドメインを管理する方法を説明するフローチャートである。
【図３９】例 ４-２によりドメインを管理する方法を説明するフローチャートである。
【図４０】異種のＤＲＭが相互運用する環境のシステムの構成を示すブロック図である。
【図４１】ＤＲＭ領域の詳細な構成を示すブロック図である。
【図４２】ＤＲＭ相互運用システムの構成を示すブロック図である。
【図４３】例 ５-１によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明するブロック図である。
【図４４】例 ５-２によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明するブロック図である。
【図４５】例 ５-３によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明するブロック図である。
【図４６】例 ５-４によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明するブロック図である。
【図４７】例 ５-５によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明するブロック図である。
【図４８】例 ５-６によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明するブロック図である。
【図４９】例 ５-７によりＤＲＭ相互運用システムを用いることによってコンテンツを処理する方法を説明するブロック図である。
【符号の説明】
【０５１６】
１０    クライアント部
２０    認証及び管理部
３０    ライセンス処理部
４０    処理制御部
４１    コンテンツ処理コントローラ
５０    コンテンツ処理部
５１    コンテンツトランスフォーマ
５２    コンテンツエクスポータ
５３    コンテンツインポータ
【図１】
2009529179.tif 000003
【図２】
2009529179.tif 000004
【図３】
2009529179.tif 000005
【図４】
2009529179.tif 000006
【図５】
2009529179.tif 000007
【図６】
2009529179.tif 000008
【図７】
2009529179.tif 000009
【図８】
2009529179.tif 000010
【図９】
2009529179.tif 000011
【図１０】
2009529179.tif 000012
【図１１】
2009529179.tif 000013
【図１２】
2009529179.tif 000014
【図１３】
2009529179.tif 000015
【図１４】
2009529179.tif 000016
【図１５】
2009529179.tif 000017
【図１６】
2009529179.tif 000018
【図１７】
2009529179.tif 000019
【図１８】
2009529179.tif 000020
【図１９】
2009529179.tif 000021
【図２０】
2009529179.tif 000022
【図２１】
2009529179.tif 000023
【図２２】
2009529179.tif 000024
【図２３】
2009529179.tif 000025
【図２４】
2009529179.tif 000026
【図２５】
2009529179.tif 000027
【図２６】
2009529179.tif 000028
【図２７】
2009529179.tif 000029
【図２８】
2009529179.tif 000030
【図２９】
2009529179.tif 000031
【図３０】
2009529179.tif 000032
【図３１】
2009529179.tif 000033
【図３２】
2009529179.tif 000034
【図３３】
2009529179.tif 000035
【図３４】
2009529179.tif 000036
【図３５】
2009529179.tif 000037
【図３６】
2009529179.tif 000038
【図３７】
2009529179.tif 000039
【図３８】
2009529179.tif 000040
【図３９】
2009529179.tif 000041
【図４０】
2009529179.tif 000042
【図４１】
2009529179.tif 000043
【図４２】
2009529179.tif 000044
【図４３】
2009529179.tif 000045
【図４４】
2009529179.tif 000046
【図４５】
2009529179.tif 000047
【図４６】
2009529179.tif 000048
【図４７】
2009529179.tif 000049
【図４８】
2009529179.tif 000050
【図４９】
2009529179.tif 000051
【手続補正書】
【提出日】平成21年5月20日(2009.5.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
仮想クライアントが、レガシーデバイスによる前記レガシーデバイスをドメインに登録する要求に応答して、前記レガシーデバイスを個別に識別するデータを、前記レガシーデバイスから受信する段階と、
前記仮想クライアントが、前記データを用いたデータベースへの問合せに基づいて、前記レガシーデバイスが登録可能であるか否かを決定する段階と、
前記仮想クライアントが、前記レガシーデバイスが登録可能であるか否かの決定に基づいて、ドメインマネージャに前記レガシーデバイスを登録させ又は登録させないようにする段階と、
を有することを特徴とするレガシーデバイス登録方法。
【請求項２】
前記レガシーデバイスを個別に識別するデータは、前記レガシーデバイスに関連した固有の情報を有する請求項１に記載のレガシーデバイス登録方法。
【請求項３】
前記データベースは、前記ドメインに登録可能なレガシーデバイスに関連した固有の情報を有する登録可能レガシーデバイスリストを有する請求項１に記載のレガシーデバイス登録方法。
【請求項４】
前記レガシーデバイスが登録可能であるか否かを決定する段階は、
前記仮想クライアントが、前記登録可能レガシーデバイスリストが前記レガシーデバイスに関連した固有の情報を含むか否かを決定する段階を有する請求項３に記載のレガシーデバイス登録方法。
【請求項５】
前記ドメインマネージャに前記レガシーデバイスを登録させ又は登録させないようにする段階は、
前記レガシーデバイスの固有の情報が前記登録可能レガシーデバイスリストに含まれる場合、前記仮想クライアントが前記ドメインマネージャに前記レガシーデバイスを登録させるようにする段階と、
前記レガシーデバイスの固有の情報が前記登録可能レガシーデバイスリストに含まれない場合、前記仮想クライアントが前記ドメインマネージャに前記レガシーデバイスを登録させないようにする段階と、
を有する請求項４に記載のレガシーデバイス登録方法。
【請求項６】
レガシーデバイスによる前記レガシーデバイスをドメインに登録する要求に応答して、前記レガシーデバイスを個別に識別するデータを前記レガシーデバイスから受信し、前記データを用いたデータベースへの問合せに基づいて、前記レガシーデバイスが登録可能であるか否かを決定する仮想クライアントと、
前記レガシーデバイスが登録可能であるか否かの決定に基づいて、前記仮想クライアントによって前記レガシーデバイスを登録され又は登録されないようにするドメインマネージャと、
を有することを特徴とするレガシーデバイス登録システム。
【請求項７】
前記レガシーデバイスを個別に識別するデータは、前記レガシーデバイスに関連した固有の情報を有する請求項６に記載のレガシーデバイス登録システム。
【請求項８】
前記データベースは、前記ドメインに登録可能なレガシーデバイスに関連した固有の情報を有する登録可能レガシーデバイスリストを有する請求項６に記載のレガシーデバイス登録システム。
【請求項９】
前記レガシーデバイスが登録可能であるか否かの決定は、
前記登録可能レガシーデバイスリストが前記レガシーデバイスに関連した固有の情報を含むか否かの前記仮想クライアントによる決定を有する請求項８に記載のレガシーデバイス登録システム。
【請求項１０】
前記ドメインマネージャに前記レガシーデバイスを登録させ又は登録させないようにすることは、
前記レガシーデバイスの固有の情報が前記登録可能レガシーデバイスリストに含まれる場合、前記仮想クライアントが前記ドメインマネージャに前記レガシーデバイスを登録させるようにすることと、
前記レガシーデバイスの固有の情報が前記登録可能レガシーデバイスリストに含まれない場合、前記仮想クライアントがドメインマネージャに前記レガシーデバイスを登録させないようにすることと、
を有する請求項９に記載のレガシーデバイス登録システム。
【請求項１１】
コンピュータによって読取り可能なレガシーデバイス登録プログラムであって、当該プログラムは、コンピュータによって、
仮想クライアントが、レガシーデバイスによる前記レガシーデバイスをドメインに登録する要求に応答して、前記レガシーデバイスを個別に識別するデータを、前記レガシーデバイスから受信する段階と、
前記仮想クライアントが、前記データを用いたデータベースへの問合せに基づいて、前記レガシーデバイスが登録可能であるか否かを決定する段階と、
前記仮想クライアントが、前記レガシーデバイスが登録可能であるか否かの決定に基づいて、ドメインマネージャに前記レガシーデバイスを登録させ又は登録させないようにする段階と、
を実行させることを特徴とするレガシーデバイス登録プログラム。
【請求項１２】
前記レガシーデバイスを個別に識別するデータは、前記レガシーデバイスに関連した固有の情報を有する請求項１１に記載のレガシーデバイス登録プログラム。
【請求項１３】
前記データベースは、前記ドメインに登録可能なレガシーデバイスに関連した固有の情報を有する登録可能レガシーデバイスリストを有する請求項１１に記載のレガシーデバイス登録プログラム。
【請求項１４】
前記レガシーデバイスが登録可能であるか否かを決定する段階は、
前記仮想クライアントが、前記登録可能レガシーデバイスリストが前記レガシーデバイスに関連した固有の情報を含むか否かを決定する段階を有する請求項１３に記載のレガシーデバイス登録プログラム。
【請求項１５】
前記ドメインマネージャに前記レガシーデバイスを登録させ又は登録させないようにする段階は、
前記レガシーデバイスの固有の情報が前記登録可能レガシーデバイスリストに含まれる場合、前記仮想クライアントが前記ドメインマネージャに前記レガシーデバイスを登録させるようにする段階と、
前記レガシーデバイスの固有の情報が前記登録可能レガシーデバイスリストに含まれない場合、前記仮想クライアントが前記ドメインマネージャに前記レガシーデバイスを登録させないようにする段階と、
を有する請求項１４に記載のレガシーデバイス登録プログラム。
【国際調査報告】
2009529179.tif 000052
2009529179.tif 000053