通信ネットワークの端末間におけるデジタルデータの使用制御
本発明は、通信ネットワークのコンテンツ制御端末（ＵＥ１）と関連付けられたコンテンツ・データ・オブジェクト（４）を使用する制御装置の制御とサポートとに関するものであり、コンテンツ・データ・オブジェクト（４）を使用するために要求されるコンテンツ・データ・オブジェクト（４）と関連付けられたデジタル権利データ・オブジェクト（７）を取得するために、コンテンツ受信端末（ＵＥ２）からの要求（５）を受信するステップと、コンテンツ制御端末（ＵＥ１）からコンテンツ受信端末（ＵＥ２）へのデジタル権利データ・オブジェクト（７）の伝送を開始するステップと、当該コンテンツの受信端末（ＵＥ２）につながる制御支援サーバ（ＣＳ、ＣＳ２）とを開示するものである。本発明は、デジタル権利データ・オブジェクト（７）の生成と、デジタル権利データ・オブジェクト（７）をコンテンツ受信端末（ＵＥ２）へ送信するための通知（６）の受信と、コンテンツ受信端末（ＵＥ２）及び当該コンテンツ受信端末（ＵＥ２）につながるコンテンツ制御端末（ＵＥ１）へのデジタル権利データ・オブジェクト（７）の送信とを行うための対応する方法をさらに開示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタル権利の管理によるデジタルデータの使用制御に関するものである。
【背景技術】
【０００２】
パーソナルコンピュータ、ラップトップコンピュータ、あるいは移動電話機のようなユーザ端末は、コンピュータや電話装置などの専用デバイスから莫大な数のサービスを提供するいわゆるマルチメディアデバイスへと発展しつつある。従来の電話サービスに加えて、ウェブの閲覧、マルチメディア・メッセージ交換サービス（ＭＭＳ）、ＭＰ３による音楽の再生、ビデオストリーミング及びモバイル機器によるモバイルゲーム（mobile gaming）などのデータサービスを提供する移動電話機が既に利用可能となっている。さらに、一体型カメラ又は装着可能なカメラの導入によって、このようなユーザ装置はピクチャファイルとビデオファイルの少なくともいずれかのファイルを作成し、かつ、管理することが可能である。したがって、ユーザ自身のデジタルデータの作成及び管理機能の増加に伴って、ユーザ装置間でこのようなデータの交換を行いたいという願望が高まってきている。
【０００３】
効果的な保護手段を用いることなく、デジタルデータはいずれの受け手によっても広範に使用することが可能であり、例えば、コピーと、修正と、任意の別の受け手への配信とのうちの少なくともいずれかが行われる。したがって、受け手へ配信するデジタルデータを一定の様式の（defined）不正使用から保護したいという要望が存在する。このような保護を行うために、マルチメディアデータの保護と、データの使用制御とを意味する、いわゆるデジタル権利管理（ＤＲＭ）技術が策定されている。
【０００４】
このようなＤＲＭ技術のうちの１つが、オープンモバイルアライアンス（ＯＭＡ）（移動通信ネットワーク内でＤＲＭを取り扱う移動通信分野の標準化団体）によって提案されている。オープンモバイルアライアンスは、一連のオープン標準規格（ウェブアドレスｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇで入手可能）を開発している。本明細書では、「ＯＭＡデジタル権利管理Ｖ１．０」という名称の標準規格は、以下においてＯＭＡ ＤＲＭ１．０と呼ぶことにする。また、「ＯＭＡデジタル権利管理Ｖ２．０」という名称の別の標準規格は、以下においてＯＭＡ ＤＲＭ２．０と呼ぶことにする。これらの標準規格はコンテンツ所有者及びサービスプロバイダから配信されるデータの保護に焦点を合わせたものであり、受信コンテンツの不正使用から実際に受け手側ユーザを防ぐものである。ＯＭＡ ＤＲＭ２．０は、ＯＭＡ ＤＲＭ１．０の拡張と考えることができ、ユーザ装置とプロバイダ間での交換情報の保護を取り扱うものである。
【０００５】
ＯＭＡ ＤＲＭ１．０はコンテンツ・データ・オブジェクトと権利とを関連付ける機能を提供する（この機能は、ダウンロード済みのコンテンツが別のユーザへ転送されたり、コピーされたりすることを防ぐものであり、転送ロックとも呼ばれる）。この機能は、権利オブジェクトをコンテンツオブジェクトに直接組み込む（組み込み配信モード）か、最初にコンテンツオブジェクトを配信し、次いで、関連する権利オブジェクトを送信する（分離配信モード）かのいずれかを行うことによって達成することが可能である。
【０００６】
分離配信（ＳＤ）の場合、一般に、（メディアオブジェクトなどの）コンテンツは（ＤＲＭコンテンツフォーマット（ＤＣＦ）に変えられて）、いわゆる拡張暗号化規格（ＡＥＳ）に準拠する対称暗号化技術などを用いて暗号化による保護が行われる。コンテンツの提供や取得のために必要な復号化鍵は、取得済みコンテンツに対する使用権についての規定も含む権利オブジェクトの中に置かれている。このような使用権は、（「再生」、「表示」、「実行」、「印刷」などの）許可と、（「カウント」、「日時」、「間隔」などの）制約条件とを含むことが可能であり、この使用権は、コンテンツの処理に関して何が受け手側に許されているかを表現するものである。したがって、この権利オブジェクトは関連するコンテンツの消費量を規定するものとなる。
【０００７】
技術的に言えば、与えられた権利の範囲内でのコンテンツの使用は、ユーザ装置の内部でＤＲＭエージェントが実現されることにより保証される。ＤＲＭコンテンツが装置によって受信されるとすぐに、ＤＲＭエージェントは関連する使用権を実施して、ユーザによる不正な転送、あるいは、ＤＲＭコンテンツや権利の変更が行われないようにする。ＯＭＡ ＤＲＭ標準、特にＯＭＡ ＤＲＭ１．０は相当数の最新の移動電話機によってサポートされている。
【０００８】
ＯＭＡ ＤＲＭ標準は、コンテンツプロバイダが、古典的クライアント・サーバアーキテクチャに基づいて、当該プロバイダのコンテンツの配信及び消費の制御を行うことが可能となるように規定されてはいるが、コンテンツプロバイダはピア・ツー・ピアレベルで端末間でのコンテンツの使用を制御することを考慮していない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
デジタル権利管理の改善を図ることが本発明の目的である。
【課題を解決するための手段】
【００１０】
この目的は独立請求項によって達成される。好適な実施形態が従属クレームに記載されている。
【００１１】
通信ネットワークの１つ又は複数のサーバによって、コンテンツデータの交換の制御、管理、サポートのうちの少なくともいずれかを行うことができるようにしながら、ピア・ツー・ピア（Ｐ２Ｐ）レベルで、すなわち、（中間ネットワークノードやサーバにおいて制御データの使用や変更を行うことなく）通信ネットワークのユーザ装置又は端末間において、対応する制御データの交換を行うことによりデジタルデータの使用制御を可能にすることが本発明の着想である。換言すれば、（コンテンツを作成したピアと、コンテンツの使用と配信とを行う権利を有するピアの少なくともいずれかのピアのような）コンテンツ所有ピアが、受け手側ピアによる当該コンテンツの使用を直接制御することが可能となる。
【００１２】
ピア又は端末の各々は、パーソナルコンピュータ、ラップトップ、移動電話機、又はスマートフォン等であってもよい。端末は、伝送部と、処理部と、メッセージを送信する送信部と、メッセージを受信する受信部と、を備えることができる。（いくつかの別の部と連携する）処理部は、コンテンツの取得と、コンテンツの１つ以上の使用制限と１つ以上の使用許可とのうちの少なくともいずれかを受信装置において指定する少なくとも１つ以上の使用権の設定と、１つ以上の規定された使用権のための完全性保護情報の生成と、コンテンツ暗号鍵を用いるコンテンツの暗号化と、のうちの少なくともいずれかに対して適合され得る。コンテンツデータの例として、写真、ビデオ、オーディオ、テキストファイル、又はこのようなファイルの任意の組み合わせがある。コンテンツ・データ・オブジェクトは、生成済みのコンテンツを或る一定のデータ構造の中へ埋め込むことによって、コンテンツ制御端末又は装置自体により生成され得る。上記とは別に、コンテンツ・データ・オブジェクトは、端末や、コンテンツ制御端末と関連付けられた任意の装置（同じユーザの装置など）によって生成することも可能である。
【００１３】
別の実施形態では、（第１のユーザ装置、又は送信用ユーザ装置とも呼ばれる。）コンテンツ制御端末は、デジタルコンテンツデータを含むコンテンツ・データ・オブジェクトと、コンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトとの双方を生成する。この場合、デジタル権利データ・オブジェクトは、（第２のユーザ装置、又は受信用ユーザ装置とも呼ばれる）コンテンツ受信端末においてコンテンツ・データ・オブジェクトを使用するように要求される。デジタル権利データ・オブジェクトには、コンテンツに関して受信側ユーザに与えられる権利の規定が含まれる。簡単な例では、権利オブジェクトは、別の制限をまったく伴うことなくコンテンツ・データ・オブジェクトを復号する復号化鍵を含んでもよい。この例では、コンテンツ制御端末のユーザは要求側ユーザがコンテンツの使用を許可されているか、否かの判定を行い、この判定に応じて、判定が肯定であれば、単にデジタル権利データ・オブジェクトを提供する。別の例では、この権利オブジェクトは、第２のユーザ装置によって付加されるべき１つ又は複数の使用上の規定を含んでもよい。
【００１４】
本実施形態はユーザ端末による直接の使用制御を可能にするものである。支援サーバは任意のサポート用として用いられる。但し、ユーザは、十分に信頼のおけるものではないと考えられるような上記サーバに対する制御を放棄することはない。こうすることによって、デジタルメディアデータのいずれの発行者又は著作権保有者も、直接的にかつ透過的にこのデータの使用を制御することが可能となる。
【００１５】
別の実施形態では制御支援サーバが提供される。これに加えて、このサーバは、コンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトの取得要求をコンテンツ受信端末の要求側ユーザから受信する（上記オブジェクトは以下で説明するような手段などの任意の手段によって以前に受信されたものであってもよい）。この要求の受信に応答して、上記サーバは、例えば、コンテンツ制御端末へ要求通知を直接送信することによって、データオブジェクトコンテンツ制御端末からコンテンツ受信端末へデジタル権利の伝送を開始する。
【００１６】
別の実施形態では、受信装置によって受信されるコンテンツ・データ・オブジェクトには、デジタル権利データ・オブジェクトの取得要求を送信するためにコンタクトすべき制御支援サーバのアドレスに関する情報が含まれる。
【００１７】
別の実施形態では、コンテンツ制御端末は、コンテンツ受信端末によるコンテンツオブジェクトのダウンロードを許可したり、容易にしたりするために（すなわち、リンク情報又はアドレス情報を提供するために）、このような情報を含むダウンロード記述をコンテンツ受信端末へ送信する。このような情報はコンテンツデータのタイプ（種別）、サイズ及び符号化についての記載をさらに含んでもよい。
【００１８】
別の実施形態では、支援サーバによって受信される要求には、電話番号のような、コンタクトすべきコンテンツ制御端末のアドレス情報と、要求されたデジタル権利データ・オブジェクトを特定する情報とが含まれ、これによって、コンテンツ制御端末はコンテンツ・データ・オブジェクトと関連付けられた適切なデジタル権利データ・オブジェクトをコンテンツ受信装置に提供することが可能となる。
【００１９】
別の実施形態では、支援サーバによって受信される要求には、例えば、受信側装置の電話番号、（氏名などの）ユーザＩＤのような、受信側装置に関するさらなる情報をネットワークから取り出すために支援サーバによって用いられる受信側装置のＩＰアドレスなどの受信側装置に関する情報が含まれる。この情報は、例えば要求に付加されてコンテンツ制御端末へ転送される。当該制御端末において上記情報を利用して、相手側装置とコンタクトするか、この情報（の複数部分）をユーザに表示するかの少なくともいずれかを行うことができる。
【００２０】
別の実施形態では、コンテンツ制御端末から受信したコンテンツ・データ・オブジェクトの格納又は管理を行うサーバがコンテンツのダウンロード要求を受信して、コンテンツ・データ・オブジェクトをコンテンツ受信端末へ送信する（上記サーバは、制御支援サーバと同じサーバであってもよいが、上記とは別に任意の異なるサーバであってもよい）。このダウンロード要求は、コンテンツ受信端末自体から、コンテンツ制御端末から、あるいは、送信側ユーザ又は受信側ユーザと関連付けられた他の任意のユーザ装置から受信されるようにしてもよい。この実施形態は、例えば、必ずしも安全なネットワークの一部であるとはかぎらない広帯域ネットワークノードを介する広帯域通信チャネルの使用を可能にするものである。このようにして、ピア間において安全な（但しおそらく狭帯域の）直接通信チャネル（ＳＭＳ又はＭＭＳなど）を介してコンテンツ全体を配信する必要なく、コンテンツの安全なピア・ツー・ピア制御が提供されることになる。
【００２１】
別の実施形態では、上述のように制御支援サーバに対応するコンテンツ受信装置のコンテンツ・データ・オブジェクトの使用を制御するコンテンツ制御用ユーザ端末が提供される。上記に加えて、この端末は、デジタル権利データ・オブジェクトを生成するステップと、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信するための通知を受信するステップと、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信するステップとを実行する。
【００２２】
別の実施形態では、コンテンツは、コンテンツ制御端末によって又はコンテンツ制御端末と関連付けられた装置によって暗号化される。これに対応して、コンテンツ制御端末は、いわゆる拡張暗号化規格（ＡＥＳ）に準拠する左右対称暗号化方式を用いて、コンテンツ受信端末において使用すべきコンテンツを復号するために、対応する復号化鍵をデジタル権利データ・オブジェクトの中へ挿入する。
【００２３】
別の実施形態では、暗号化済みコンテンツは受信装置の安全な環境においてコンテンツ暗号鍵を用いて復号される。安全な環境とは、ユーザ装置により設けられたハードウェアセキュリティモジュールと、ユーザ装置上で作動されるセキュリティアプリケーションとのうちの少なくともいずれかであってもよい。このセキュリティアプリケーションは、当該コンテンツに対して規定された使用権に従うユーザ装置用のコンテンツの使用を保護するものである。規定された使用権と一致しないコンテンツの使用は受信装置において許可されない。例えば、コンテンツ又は該コンテンツの（複数の）部分は、使用権によって許可されていない場合、安全な環境の中から転送され得ない。
【００２４】
別の実施形態では、上述のような制御メカニズムはＯＭＡ ＤＲＭ１．０において規定されている機能及びメッセージをベースとする。これによってＯＭＡ ＤＲＭ１．０の分離配信が拡げられることになる。これによって、（デジタル権利管理（ＤＲＭ）コンテンツフォーマット（ＤＣＦ）として符号化される）コンテンツ・データ・オブジェクトの受信時に、コンテンツ・データ・オブジェクトの中に符号化された情報を用いて、関連する権利オブジェクトの取得を開始する受け手側端末として任意のＯＭＡ ＤＲＭ１．０対応装置の使用が可能となる。
【００２５】
別の実施形態では、デジタル権利データ・オブジェクトの中へ挿入された復号化鍵を暗号化して、このオブジェクトのいずれの悪用も防止するように意図される。この暗号化はコンテンツ受信装置の公開鍵によって実行されるものであってもよい。
【００２６】
別の実施形態では、コンテンツ受信端末の公開鍵は、この端末に関するパブリック情報（電話番号や電子メールアドレスなど）に基づいて生成される。この実施形態は、データの暗号化と認証の少なくともいずれかが暗号の証明書の交換を全く必要としないという利点を有するものとなる。
【００２７】
別の実施形態では、コンテンツ制御端末と関連付けられたコンテンツ・データ・オブジェクトの使用制御をサポートする制御支援サーバは、コンテンツ・データ・オブジェクトの使用に必要なコンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトの取得要求をコンテンツ受信端末から受信する受信機と、コンテンツ制御端末からコンテンツ受信端末へのデジタル権利データ・オブジェクトの伝送を開始する（端末に接続された送信機などの）開始手段とを備える（但し、「関連付けられた」とは（コンテンツデータに関連するいわゆる著作権又は使用権を認可する権利などの）コンテンツ制御端末のユーザが（或る一定の）使用権を有していると考え得る場合を指す）。
【００２８】
別の実施形態では、コンテンツ受信端末によって受信されるべきコンテンツ・データ・オブジェクトの使用を制御するコンテンツ制御端末は、コンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトを生成する生成装置と、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信する旨の通知を受信する受信機と、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信する送信機と、を備える。
【００２９】
本発明はまた、ユーザ装置及び受信装置のそれぞれの処理部により処理されたとき、上述のような方法を実行するソフトウェアコード部分を含むコンピュータプログラムにも関する。コンピュータプログラムはコンピュータ可読媒体に格納することができる。コンピュータ可読媒体は、ユーザ装置又は受信装置内の永久メモリあるいは書換可能メモリであってもよいし、あるいは外部に配置してもよい。それぞれのコンピュータプログラムは、例えば一連の信号の形でケーブルや無線リンクを介してユーザ装置又は受信装置へ転送され得る。
【００３０】
以下において、十分な、かつ、完全な理解を当業者に提供するために本発明の詳細な実施形態について説明する。しかし、これらの実施形態は例示的なものであり、本発明の限定を意図するものではない。
【図面の簡単な説明】
【００３１】
【図１ａ】コンテンツの使用制御装置のための第１の実施形態の一例を示し、コンテンツ制御端末と、受信装置と、コンテンツサーバとの間での例示のメッセージを示す図である。
【図１ｂ】図１に対応する例示のプロトコルシーケンスを示す図である。
【図２】コンテンツの使用制御装置のための第２の実施形態の一例を示す図である。
【図３】コンテンツの使用制御装置のための第３の実施形態の一例を示す図である。
【発明を実施するための形態】
【００３２】
図１ａは、送信側ユーザ装置又は第１のユーザ装置ＵＥ１とも呼ばれるコンテンツ制御用ユーザ装置と、受け手側ユーザ装置又は第２のユーザ装置ＵＥ２とも呼ばれるコンテンツ受信端末と、第１のサーバＣＳ１とを備えたコンテンツの使用制御装置の一例を示す図である。第１のユーザ装置ＵＥ１は、例えば、写真用カメラのような、ユーザ装置ＵＥ１と関連付けられるか、当該ＵＥ１に接続されるか、当該ＵＥ１内に組み込まれた装置から、任意の外部又は内部のローカルな記憶装置から得られるデジタルコンテンツを受信し、対応するコンテンツオブジェクトを生成し、関連付けられた権利オブジェクトを第１及び第２のユーザ装置ＵＥ１とＵＥ２の間で直接交換しながら、第１のサーバＣＳ１を介して上記オブジェクトを第２のユーザ装置ＵＥ２へ伝送する。
【００３３】
第１のユーザ装置ＵＥ１と、第２のユーザ装置ＵＥ２と、第１のサーバＣＳ１との間におけるメッセージ交換を示す例として、以下のステップが挙げられる：
− 第１のステップにおいて、第１のユーザ装置ＵＥ１は１番目のメッセージ１を受信する。上記とは別に、第１のユーザ装置ＵＥ１は一体型カメラによってコンテンツ自体を生成するようにしてもよい。第１のユーザ装置ＵＥ１は、ＤＲＭコンテンツフォーマット（ＤＣＦ）オブジェクト及び関連付けられた権利オブジェクト（ＲＯ）を生成する。さらに、ＤＣＦを指し示すリンクを含むいわゆるダウンロード記述子（ＤＤ）が生成されるようにしてもよい。
【００３４】
− 第２のステップにおいて、２番目のメッセージ２を送信することによって、第１のユーザ装置ＵＥ１はＤＣＦとＤＤとを第１のサーバＣＳ１にアップロードする。上記とは別に、ＣＳ１によってＤＣＦ又はＤＤへのリンクを生成すると共に、このステップの範囲内でＤＣＦ又はＤＤを第１のユーザ装置ＵＥ１へ返送することができる。
【００３５】
− 第３のステップにおいて、第１のユーザ装置ＵＥ１は、例えばショート・メッセージ・サービス（ＳＭＳ）によるメッセージによって、ＤＣＦ又はＤＤへのリンクを含む有線通信と無線通信の両方で３番目のメッセージ３を第２のユーザ装置ＵＥ２へ送信する。
【００３６】
− 第４のステップにおいて、第２のユーザ装置ＵＥ２は、４番目のメッセージ４と共にＤＣＦを取得するために、ＤＤによって又は直接リンクによって第１のサーバＣＳ１とコンタクトを行う。
【００３７】
− 第５のステップにおいて、第２のユーザ装置ＵＥ２は、例えば（いわゆるＤＣＦの「権利発行者」フィールド内などのような）ＤＣＦ内で指定されたユニフォームリソースロケータ（ＵＲＬ）を用いることによって、ＤＣＦと関連付けられたＲＯを要求するために５番目のメッセージ５を第１のサーバＣＳ１から送信する。
【００３８】
− 第６のステップにおいて、サーバＣＳ１は、例えばＳＭＳテキストメッセージ毎に、６番目のメッセージ６と共に第１のユーザ装置ＵＥ１へ上記要求を転送する。また、サーバＣＳ１は、第２のすなわち受信用ユーザ装置ＵＥ２に関する情報（装置ＵＥ２の電話番号など）をさらに転送又は追加することができる。
【００３９】
− 第７のステップにおいて、第１のユーザ装置ＵＥ１は、例えばＲＯを中に含むＷＡＰのプッシュＳＭＳによって、要求されたＲＯを７番目のメッセージ７と共に第２のユーザ装置ＵＥ２へ送信する。
【００４０】
すでに第１のステップ内において関連付けられたＲＯを生成するステップとは別に、上記オブジェクトは、第７のステップまでに、例えば第６のステップと共に又は第６のステップの後に生成されてもよい。ＲＯにおける権利は、ステップ６などにおいて以前のメッセージで得られた情報に従属するものであってもよい。さらに、ユーザは、（コンテンツへのアクセス許可を与えるように求めるＵＥ１のディスプレイに現れるウィンドウなどによって）前のステップで受信した情報を提示する入力を求められる場合もある。
【００４１】
第１のユーザ装置ＵＥ１内におけるコンテンツ制御は、第１のユーザ装置ＵＥ１に内蔵されているコンテンツ制御用エージェントによってサポートされてもよい。例えば、このコンテンツ制御は第１のユーザ装置のＣＰＵによって制御されるプログラムとして実現される。また、以下において、このプログラムはＤＲＭプログラムとも呼ばれる。このプログラムは、ユーザによるデジタルコンテンツの選択を特にサポートすることが可能であり、このデジタルコンテンツは、以下において任意の知覚可能な（可聴の、可視の、オーディオビジュアルな、又は読み取り可能な）ドキュメントであってもよいマルチメディアコンテンツと呼ばれる場合もある。上記プログラムにおけるマルチメディアコンテンツは１つ又は複数の写真、映画、音声又は音楽ファイル、テキスト文書、又はこれらの任意の組み合わせなどであってもよい。
【００４２】
コンテンツの受信後又は選択後あるいはコンテンツの受信又は選択と連携して、第１のユーザ装置ＵＥ１のユーザは、第２のユーザ装置ＵＥ２のユーザに関して、コンテンツに対する使用権を手動で規定してもよい。上記とは別に、例えば（複数の）特定グループの受け手側ユーザに対して個々に規定される上記のような規定はデフォルト値を用いて自動的に実行することも可能である。上記使用権は１つ又は複数の使用制限と使用許可の少なくともいずれか又は許可と制約との任意の組み合わせを含んでもよい。許容使用権の例として以下のものが挙げられる：閲覧、再生、転送、複製、印刷、コピー、修正、及び同期。許容使用権の例として以下のものが挙げられる：規定された目的バインディング（Purpose Binding）、時間的制約、及び許可された使用の回数制限。「表示」、「再生」又は「実行」は（ビデオコンテンツの画面上での表示又は装置の再生あるいはスピーカによるオーディオコンテンツの再生などの）コンテンツの消費を行えるように受け手側ユーザに権利（使用権利）を割り当て、「転送」はコンテンツを別の装置へ転送するように、「印刷」は装置からのコンテンツをプリンタ側でプリントアウトするように、あるいは「エクスポート」はコンテンツを別の装置へ送信するように受け手側ユーザに権利を割り当てる。この場合、コンテンツはエクスポート用装置以外の別の手段によって保護されてもよい。
【００４３】
「目的バインディング」を用いて、指定された目的又は特定のアプリケーションに従ってコンテンツの使用を限定することが可能となる。例えば、使用コンテンツに対して課金を行うことが可能になるが、他の目的のために「目的バインディング」が用いられることはない。「時間的制約」は、コンテンツの使用時間又は使用時間の間隔を限定するために用いることができる。さらに、コンテンツの使用回数は「カウント」によって限定してもよい。
【００４４】
次に図１ｂを参照しながら、メッセージ２〜７のシーケンス図によって図１ａで解説したステップについて説明する。これらのステップはＯＭＡ ＤＲＭ１．０用として特に調整されたものである。
【００４５】
− マルチメディアコンテンツの受信又は選択（ＳｅｌｅｃｔＣｏｎｔｅｎｔ）を行い、このコンテンツに対する使用権の規定（ＤｅｆｉｎｅＲｉｇｈｔｓ）を行った後、ＤＲＭプログラムはＤＣＦ及び関連するＲＯ（及びおそらくＤＤ）を生成する（ＧｅｎｅｒａｔｅＤＲＭ）。
【００４６】
− 第１のユーザ装置ＵＥ１のＤＲＭプログラムは、２番目のメッセージ２を送信する（ＵｐｌｏａｄＤＣＦ）ことによって、ＤＣＦ（及びＤＤ）を第１のサーバＣＳ１にアップロードする（ＵｐｌｏａｄＤＲＭ）。第１のサーバＣＳ１はこのメッセージを処理し（ＨａｎｄｌｅＵｐｌｏａｄＤＲＭ）、ＤＣＦ（及びＤＤ）をセーブする。
【００４７】
− 第１のユーザ装置ＵＥ１のＤＲＭプログラムは、３番目のメッセージ３を送信する（ＳｅｎｄＬｉｎｋ）ことによってＤＣＦ（又はＤＤ）へのリンクを第２のユーザ装置ＵＥ２へ送信する（ＳｅｎｄＵＲＬ）。
【００４８】
− 第２のユーザ装置ＵＥ２は４番目のメッセージ４を送信することによって、（直接的か又はＤＤによるかのいずれかによって）ＤＣＦを取得し、第１のサーバＣＳ１に指示をアップロードする（ｇｅｔＤＣＦ又はＧｅｔＤＤ）。この第１のサーバＣＳ１は、上記４番目のメッセージ４と共にＤＣＦを第２のユーザ装置ＵＥ２へ順次送信する（ＳｅｎｄＤＣＦ）か、ＤＤを順次送信し（ＳｅｎｄＤＤ）、指示をダウンロードする。第２のユーザ装置ＵＥ２がＤＤを取得した場合、ユーザ装置ＵＥ２はＤＤによってＤＣＦをダウンロードする（例えばＤＣＦへのリンクを含む）。
【００４９】
− ＤＣＦの「権利発行者」フィールドに指定されているＵＲＬを用いて、ＤＲＭエージェントは５番目のメッセージ５を第１のサーバＣＳ１へ送信することによってＲＯを要求する（ＲｅｑｕｅｓｔＲＯ）。
【００５０】
− 第１のサーバＣＳ１は、５番目のメッセージ５（ＲｅｑｕｅｓｔＲＯ）を処理し（ＨａｎｄｌｅＲｅｑｕｅｓｔＲＯ）、６番目のメッセージ６を第１のユーザ装置ＵＥ１へ送信する（ＦｏｒｗａｒｄＲｅｑｕｅｓｔＲＯ）ことによってＲＯ要求を第１のユーザ装置ＵＥ１へ転送する（ＦｏｒｗａｒｄＲＯ）。上記の解説によれば、第１のサーバＣＳ１は、さらに受信側装置ＵＥ２に関する情報を送信してもよい。
【００５１】
− 第１のユーザ装置ＵＥ１のＤＲＭプログラムは、６番目のメッセージ（ＦｏｒｗａｒｄＲｅｑｕｅｓｔＲＯ）を処理し（ＨａｎｄｌｅＲｅｑｕｅｓｔＲＯ）、７番目のメッセージ７を第２のユーザ装置ＵＥ２へ送信する（ＳｅｎｄＲＯ）ことによって第２のユーザ装置ＵＥ２へＲＯをプッシュする（ＰｕｓｈＲＯ）。第２のユーザ装置ＵＥ２のＤＲＭエージェントはこのメッセージを処理し、ＤＣＦに対する使用権を実施する。
【００５２】
上述のパラメータについての説明
ＲＯＩＤ（デジタル権利データ・オブジェクトの識別子）：受け手側ユーザＵＥ２のアドレスを含み得るＲＯの（ランダムな）ＩＤ（電話番号など）。例えば、ＲＯＩＤ：＝ＲｅｃｉｐｉｅｎｔＡｄｄｒｅｓｓ：ＲａｎｄｏｍＮｕｍｂｅｒ
ＲｅｑｕｅｓｔＲＯＩＤ：（連結によって電話番号及びＲＯＩＤからＲｅｑｕｅｓｔＲＯＩＤを構成することにより）第１のユーザのアドレスにマッチされ得る。例えば、ＲｅｑｕｅｓｔＲＯＩＤ：＝ＳｅｎｄｅｒＡｄｄｒｅｓｓ：ＲＯＩＤ
ＤＣＦ：ＯＭＡ ＤＲＭ１．０（ＤＲＭコンテンツフォーマット仕様）に規定されていように暗号化済みのコンテンツを中に含むＤＲＭコンテンツフォーマット。「ヘッダ」フィールドの「権利発行者」エレメントは第１のサーバＣＳ１を指すＵＲＩを含む。さらに、ＵＲＩはＲＯＩＤ又は要求ＲＯＩＤに関する情報若しくはＲＯＩＤ又は要求ＲＯＩＤへの参照を含んでもよい。
【００５３】
ＤＤ：ＤＣＦと関連付けられたダウンロード記述子
ＤＤＵＲＬ：第１のサーバＣＳ１上のアップロードＤＤのＵＲＬ
メッセージ例
ＵｐｌｏａｄＤＣＦ：ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバへＤＣＦをアップロードするためのＨＴＴＰ／ＰＯＳＴ要求
→ パラメータ：ＤＣＦ
ＳｅｎｄＬｉｎｋ：ＤＣＦのＵＲＬを中に含むＳＭＳ
→ パラメータ：ＤＣＦＵＲＬ
ＧｅｔＤＣＦ：ＤＣＦをダウンロードするためのＨＴＴＰ／ＧＥＴ要求
→ パラメータ：ＤＣＦＵＲＬ
ＳｅｎｄＤＣＦ：ＤＣＦを中に含むＨＴＴＰレスポンス
→ パラメータ：ＤＣＦ
ＲｅｑｕｅｓｔＲＯ：ＲＯを要求するＨＴＴＰ／ＧＥＴ要求
→ パラメータ：ＲｅｑｕｅｓｔＲＯＩＤ
Ｆｏｒｗａｒｄ ＲｅｑｕｅｓｔＲＯ：送信機の電話番号へ送信されたＳＭＳ
→ パラメータ：ＲＯＩＤ
ＳｅｎｄＲＯ：ＲＯを中に含むＷＡＰプッシュＳＭＳ
→ パラメータ：ＲＯ
受信側ユーザ装置ＵＥ２を参照してわかるように、もし装置ＵＥ２がＯＭＡ ＤＲＭ１．０をサポートしていれば、特定の実装構成は不要となる。ＧｅｔＤＤ及びＳｅｎｄＤＤ（第４のステップ）の機能は、例えば、ＳｅｎｄＬｉｎｋメッセージ（ＳＭＳ）の中に含まれているＤＣＦ又はＤＤのＵＲＬを用いて、又は、いわゆるＷＡＰプッシュ法によって単に受け手側ユーザのインターネットを介したブラウジングから結果として生じることになる。ＲｅｑｕｅｓｔＲＯを送信する機能（第５のステップ）はＯＭＡ ＤＲＭ１．０に従うＤＲＭエージェントによってすでに実装されている。
【００５４】
図２はコンテンツの使用制御装置のための第２の実施形態例を示す。図１ａに追加して、別のユーザ装置ＵＥ１’が示されているが、このユーザ装置は第１のユーザ装置ＵＥ１の同じユーザと関連付けられた装置である。このような別のユーザ装置は、（例えばインターネットを介して、及びＨＴＴＰによって）第１のサーバと通信することが可能なパーソナルコンピュータ又は他の任意のコンピュータ装置であってもよい。図１ａの第１のステップに対応するステップにおいて、デジタルデータは（メッセージ１’と共に）上記別のユーザ装置ＵＥ１’へ送信される。上記とは別に、このデータは装置の内部で生成されたものであってもよいため、このステップを省くことが可能である。図１ａのステップ２に対応する次のステップにおいて、上記別のユーザ装置ＵＥ’は第１のサーバへ送信すべきＤＣＦオブジェクトを生成する。これらの別のステップは図１ａで上述したようなステップ３〜７と同様に実行され得る。
【００５５】
第１のユーザ装置ＵＥ１及び上記別のユーザ装置ＵＥ１’は、制御情報を交換するために（ブルートゥースや赤外線接続などの）ローカルなインタフェースによって接続されてもよい。上記別のユーザ装置ＵＥ’が権利オブジェクトも生成した場合、このインタフェースを使用して、権利オブジェクトを第１のユーザ装置ＵＥ１へ伝えるようにすることも可能である。
【００５６】
図３はコンテンツの使用制御を行うための第３の実施形態例を示す。第１のサーバＣＳ１の代わりに、第１のサーバＣＳ１のタスクを共有する、第２のサーバ（又はＤＲＭ支援サーバ）ＣＳ２及び第３のサーバ（又はコンテンツ管理用サーバ）ＣＳ３が示されている。第２のサーバＣＳ２がコンテンツオブジェクトの使用制御をサポートする機能を含む一方で、第３のサーバＣＳ３は、（例えばコンテンツのアップロード、格納及びダウンロードを管理することによって）送信側ユーザから受信側ユーザへのコンテンツオブジェクトの送信を管理する機能を有する。上記に加えて、図１ａの第２のステップに対応するステップにおいて、第１のユーザ装置ＵＥ１は、（図３に示す例に従ってコンテンツデータを自動的に生成した）ＤＣＦ（及びＤＤ）を第２の代替メッセージ２”の送信によって第３のサーバＣＳ３へアップロードする。第１のユーザ装置ＵＥ１から第２のユーザ装置ＵＥ２へ３番目のメッセージ３を送信するステップを有する次のステップは同様のままのステップであってもよい。図１ａの第４のステップに対応する次のステップにおいて、第２のユーザ装置ＵＥ２は（例えば第３のサーバへのリンクを含むＤＤによって）第３のサーバＣＳ３にコンタクトして、代替の４番目のメッセージ４”と共にＤＣＦを取得する。これらの別のステップは図１ａで上述したようなステップ３〜７と同様に実行することが可能である。
【００５７】
代替例において、第１のユーザ装置ＵＥ１から別の受信装置ＵＥ２へさらに配信すべきコンテンツを受信する中間ユーザ装置を設けるようにしてもよい。このような配信はスーパー配信法と呼ばれる場合もある。この代替例は、第３のサーバＣＳ３を中間ユーザ装置によって確実に置き換えることによって図３に示されているように第３の実施形態例として実現され得る。この場合、第１のユーザ装置ＵＥ１は、第２の代替メッセージ２”を送信することによって中間ユーザ装置にＤＣＦをアップロードする。図３のステップ３及び４の代わりに、第２のユーザ装置ＵＥ２に通知を行い、かつ、ブルートゥース、赤外線、ＭＭＳ又はＷＬＡＮなどによって、中間装置から第２のユーザ装置ＵＥ２へＤＣＦの転送を行う別の手段を用いてもよい。これらの別のステップは上述したようなステップ５〜７と同様に実行され得る。
【００５８】
上記に開示した実施形態は、ユーザが、例えば上述のようなＯＭＡ ＤＲＭ１．０による分離配信保護に基づいて（移動電話機などの）そのユーザ機器を介して任意のサイズのコンテンツの使用を制御できるようにするものである。
【００５９】
ベースとしてＯＭＡ ＤＲＭ１．０を用いる場合、もし受信側装置がＯＭＡ ＤＲＭ１．０に対応したものであれば受信装置側において修正を行う必要はない。したがって、ＯＭＡ ＤＲＭ１．０の使用が可能な任意の装置（したがって最近の移動電話機のほとんど）は保護されたコンテンツデータ及び使用権データを個別に受信して、コンテンツの使用権を実施することが可能となる。
【００６０】
送信装置側においては、送信側装置内のソフトウェアの修正により追加機能の実現が可能となる。したがって、ＯＭＡ ＤＲＭ１．０を修正する必要なく本発明の実施形態の使用が可能となる。
【００６１】
或る一定レベルのセキュリティを提供するために、第１のユーザ装置ＵＥ１の内部においてコンテンツの暗号化を行うことができる。上述したように、ＤＲＭにより保護されたメディアオブジェクトを提供するために、ユーザは、暗号化されたコンテンツファイル自体と、復号化鍵と権利についての記述を中に含む関連付けられたＲＯとの双方を必要とする。また、達成すべき信頼性のレベルに応じて（捕捉、補正などの）悪用からＲＯを保護する目的が存在する場合もある。上記に加えて安全なチャネルを介してＲＯを伝送するようにしてもよい。上記とは別に、又は、上記に加えて、ＲＯに対して整合性を保護するようにしてもよい。
【００６２】
ＯＭＡ ＤＲＭ２．０は、証明書の使用による信頼性関係の確立によってＲＯの安全な配信を提案するものである。この点に関して、ＯＭＡ ＤＲＭ２．０は公開鍵インフラストラクチャ（ＰＫＩ）を必要とする。公開鍵及び対応する秘密鍵がシステム内の個々のエンティティに対して供給される。公開鍵は認証局（ＣＡ）によって署名された証明書の内部にカプセル化される。信用のおけるオンライン証明書状態プロトコル（ＯＣＳＰ）応答装置が証明書の有効性をチェックし、かつ、証明書の状態（良好、撤回又は不明）を示す。保護されたコンテンツは、追加の保護を必要とすることなく、（例えば無線、ＷＬＡＮ、取り外し可能媒体などの）任意の手段によって装置へ配信されることができる。ＯＭＡ ＤＲＭ１．０の場合と同様、ＯＭＡ ＤＲＭ２．０はピア・ツー・ピア制御メカニズムを扱わない。ピア・ツー・ピアネットワーク（Ｐ２Ｐ）では、個々のピアはクライアントとサーバの双方として機能する。移動通信ネットワークにおけるＰ２Ｐ通信用としてＯＭＡ ＤＲＭ２．０を考えるとき、個々の移動電話機はＤＲＭコンテンツの送受信を行う（すなわちＤＲＭエージェント及び権利発行者として機能する）ことができなければならない。
【００６３】
権利オブジェクトの交換のためにＯＭＡ ＤＲＭ２．０によって提案されているような公開鍵暗号法は、送信者側へ与えられる受信者側の公開鍵に関する事前の知識に依存する。通常、秘密鍵は証明書の中に（例えばＯＭＡ ＤＲＭ２．０によって提案されている権利オブジェクト取得プロトコルＲＯＡＰなどの中に）埋め込まれていて、初期登録段の間に交換される。ピア・ツー・ピアシナリオでは、証明書の交換は必ずしも可能ではない。特に、メッセージを送信しなければならない時点において受信側ピアがオフラインになっている場合には、証明書の交換は可能ではない。このケースでは、受信側装置の公開鍵に関する知識なしで、メッセージをネットワークに格納してもよいが、送信側装置は受信側装置へ送信すべき権利オブジェクトを保護することはできなくなる。
【００６４】
上記に提案されているような証明書ベースの暗号法の代替例として、いわゆるＩＤベースのデジタル権利の管理（ＩＢ−ＤＲＭ）が提案されている。この権利管理システムはＯＭＡ ＤＲＭ２．０をベースとすることが可能であるが、ＩＤベースの公開鍵暗号法（ＩＤ−ＰＫ）に依拠している。ＩＤ−ＰＫ方式では、公開鍵は、電子メールアドレス、電話番号又はＳＩＰ−ＵＲＩのようなパブリックＩＤなどの公開情報から導き出される。その結果、データ又は認証の暗号化は事前の証明書の交換を必要としない。ＩＤベースの暗号化は例えば双線形ペアリングを用いて楕円曲線暗号化方式を使用して実現され得る。Ｃ． Ｇｅｎｔｒｙ及びＡ． Ｓｉｌｖｅｒｂｅｒｇによる論文「階層型ＩＤベースの暗号化方式」（暗号化方式並びに情報セキュリティの理論及び応用に関する第８回国際会議会報：暗号化方式の進歩ｐ．５４８〜５６６、２００２年）によれば、階層型ＩＤベースの暗号化は、従来のＰＫＩ ＤＲＭシステムの場合と同様，ＩＢ−ＤＲＭに対してツリー構造アーキテクチャを生成し、このアーキテクチャによってシステムのセキュリティとスケーラビリティとが提供される。さらに、鍵がＩＤストリングから導き出されるので鍵管理が容易化されることになる。ＩＢ−ＤＲＭシステムでは、権利オブジェクト（ＲＯ）はワンパスプロトコルを用いて受け手へ配信され得る。証明書の事前の交換を行う必要はなく、認証と認可とは分離して行うことができる。ＩＢ−ＤＲＭは、メッセージ（すなわちＲＯ）をネットワークのどこかに格納できるようになっているプッシュモードで用いるように設計されているのでＰ２Ｐネットワークにとって好適である。
【００６５】
ＩＢＥを用いるＤＲＭ保護は以下のステップを含んでもよい。
【００６６】
１．基本暗号パラメータが生成され、次いで、これらのパラメータは、信頼のおける認証機関（ＴＡ）によって（部分的に）公開される。もし複数のＴＡがシステム内に存在していれば階層の形でこれらのパラメータを編成してもよい。
【００６７】
２．個々の通信相手はそのそれぞれのＴＡから自分の秘密鍵を取得する。鍵は製造工程中安全なチャネルを用いて又はトランスポート層セキュリティ（ＴＬＳ）を用いて転送されなければならない。
【００６８】
３．送信側装置において、コンテンツの暗号化が行われ、このコンテンツの使用権が規定される。少なくともコンテンツの暗号化のために用いられる鍵は受信装置の公開鍵を用いて暗号化される。公開鍵は、以上説明したようなＩＤベースの公開鍵暗号方式を用いて、（例えば電話番号、電子メールアドレスなどの）受け手の或るパブリックＩＤ及びＴＡによって公開されているシステムパラメータから導き出される。上記暗号化された鍵及び規定された使用権は、整合性の保護又は送信側装置のＩＤベースの署名が行われたＲＯの中へ埋め込まれる。
【００６９】
４．コンテンツと使用権の双方は受信側装置へ配信される（このステップ中に盗聴を防止する追加の保護を行う必要はない）。
【００７０】
５．受信装置は、ＲＯの真正性を検証し、暗号化済みコンテンツを順次復号するために使用できる鍵の復号化を行う。
【００７１】
オプションとして、上記のステップ３とステップ５の少なくともいずれかのステップにおいて、送信側装置と受信側装置の少なくともいずれかの装置の鍵の有効性をチェックすることができる。
【００７２】
上記に提案されたようなＩＢ−ＤＲＭシステムに対してＯＭＡ ＤＲＭ２．０と同様のセキュリティレベルが提供されるが、このセキュリティレベルよりもさらに多くの柔軟性と単純さが提供される。特に、唯一のメッセージ交換によってＩＤベースの権利オブジェクト取得プロトコルＲＯＡＰの実行が可能となる。実際には、例えばエンティティが信頼のおけるものであるか否かを判定する専用ノードにコンタクトすることによって認証と認可とをいつでも分離して行うことが可能となる。ＩＤベースのＲＯＡＰは、プッシュモードで使用されるように設計されているのでＰ２Ｐネットワークに適している。このことは、受け手側ピアが送信側ピアからコンテンツを要求する必要がないことを意味し、これは一般的な使用例である（一般に、受け手側ピアは、ピアがメッセージを送信したいと思っていることを認知さえしていない場合もある）。さらに、その後ピアは唯一のメッセージが交換されるので、オンライン状態である必要はない。
【技術分野】
【０００１】
本発明は、デジタル権利の管理によるデジタルデータの使用制御に関するものである。
【背景技術】
【０００２】
パーソナルコンピュータ、ラップトップコンピュータ、あるいは移動電話機のようなユーザ端末は、コンピュータや電話装置などの専用デバイスから莫大な数のサービスを提供するいわゆるマルチメディアデバイスへと発展しつつある。従来の電話サービスに加えて、ウェブの閲覧、マルチメディア・メッセージ交換サービス（ＭＭＳ）、ＭＰ３による音楽の再生、ビデオストリーミング及びモバイル機器によるモバイルゲーム（mobile gaming）などのデータサービスを提供する移動電話機が既に利用可能となっている。さらに、一体型カメラ又は装着可能なカメラの導入によって、このようなユーザ装置はピクチャファイルとビデオファイルの少なくともいずれかのファイルを作成し、かつ、管理することが可能である。したがって、ユーザ自身のデジタルデータの作成及び管理機能の増加に伴って、ユーザ装置間でこのようなデータの交換を行いたいという願望が高まってきている。
【０００３】
効果的な保護手段を用いることなく、デジタルデータはいずれの受け手によっても広範に使用することが可能であり、例えば、コピーと、修正と、任意の別の受け手への配信とのうちの少なくともいずれかが行われる。したがって、受け手へ配信するデジタルデータを一定の様式の（defined）不正使用から保護したいという要望が存在する。このような保護を行うために、マルチメディアデータの保護と、データの使用制御とを意味する、いわゆるデジタル権利管理（ＤＲＭ）技術が策定されている。
【０００４】
このようなＤＲＭ技術のうちの１つが、オープンモバイルアライアンス（ＯＭＡ）（移動通信ネットワーク内でＤＲＭを取り扱う移動通信分野の標準化団体）によって提案されている。オープンモバイルアライアンスは、一連のオープン標準規格（ウェブアドレスｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇで入手可能）を開発している。本明細書では、「ＯＭＡデジタル権利管理Ｖ１．０」という名称の標準規格は、以下においてＯＭＡ ＤＲＭ１．０と呼ぶことにする。また、「ＯＭＡデジタル権利管理Ｖ２．０」という名称の別の標準規格は、以下においてＯＭＡ ＤＲＭ２．０と呼ぶことにする。これらの標準規格はコンテンツ所有者及びサービスプロバイダから配信されるデータの保護に焦点を合わせたものであり、受信コンテンツの不正使用から実際に受け手側ユーザを防ぐものである。ＯＭＡ ＤＲＭ２．０は、ＯＭＡ ＤＲＭ１．０の拡張と考えることができ、ユーザ装置とプロバイダ間での交換情報の保護を取り扱うものである。
【０００５】
ＯＭＡ ＤＲＭ１．０はコンテンツ・データ・オブジェクトと権利とを関連付ける機能を提供する（この機能は、ダウンロード済みのコンテンツが別のユーザへ転送されたり、コピーされたりすることを防ぐものであり、転送ロックとも呼ばれる）。この機能は、権利オブジェクトをコンテンツオブジェクトに直接組み込む（組み込み配信モード）か、最初にコンテンツオブジェクトを配信し、次いで、関連する権利オブジェクトを送信する（分離配信モード）かのいずれかを行うことによって達成することが可能である。
【０００６】
分離配信（ＳＤ）の場合、一般に、（メディアオブジェクトなどの）コンテンツは（ＤＲＭコンテンツフォーマット（ＤＣＦ）に変えられて）、いわゆる拡張暗号化規格（ＡＥＳ）に準拠する対称暗号化技術などを用いて暗号化による保護が行われる。コンテンツの提供や取得のために必要な復号化鍵は、取得済みコンテンツに対する使用権についての規定も含む権利オブジェクトの中に置かれている。このような使用権は、（「再生」、「表示」、「実行」、「印刷」などの）許可と、（「カウント」、「日時」、「間隔」などの）制約条件とを含むことが可能であり、この使用権は、コンテンツの処理に関して何が受け手側に許されているかを表現するものである。したがって、この権利オブジェクトは関連するコンテンツの消費量を規定するものとなる。
【０００７】
技術的に言えば、与えられた権利の範囲内でのコンテンツの使用は、ユーザ装置の内部でＤＲＭエージェントが実現されることにより保証される。ＤＲＭコンテンツが装置によって受信されるとすぐに、ＤＲＭエージェントは関連する使用権を実施して、ユーザによる不正な転送、あるいは、ＤＲＭコンテンツや権利の変更が行われないようにする。ＯＭＡ ＤＲＭ標準、特にＯＭＡ ＤＲＭ１．０は相当数の最新の移動電話機によってサポートされている。
【０００８】
ＯＭＡ ＤＲＭ標準は、コンテンツプロバイダが、古典的クライアント・サーバアーキテクチャに基づいて、当該プロバイダのコンテンツの配信及び消費の制御を行うことが可能となるように規定されてはいるが、コンテンツプロバイダはピア・ツー・ピアレベルで端末間でのコンテンツの使用を制御することを考慮していない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
デジタル権利管理の改善を図ることが本発明の目的である。
【課題を解決するための手段】
【００１０】
この目的は独立請求項によって達成される。好適な実施形態が従属クレームに記載されている。
【００１１】
通信ネットワークの１つ又は複数のサーバによって、コンテンツデータの交換の制御、管理、サポートのうちの少なくともいずれかを行うことができるようにしながら、ピア・ツー・ピア（Ｐ２Ｐ）レベルで、すなわち、（中間ネットワークノードやサーバにおいて制御データの使用や変更を行うことなく）通信ネットワークのユーザ装置又は端末間において、対応する制御データの交換を行うことによりデジタルデータの使用制御を可能にすることが本発明の着想である。換言すれば、（コンテンツを作成したピアと、コンテンツの使用と配信とを行う権利を有するピアの少なくともいずれかのピアのような）コンテンツ所有ピアが、受け手側ピアによる当該コンテンツの使用を直接制御することが可能となる。
【００１２】
ピア又は端末の各々は、パーソナルコンピュータ、ラップトップ、移動電話機、又はスマートフォン等であってもよい。端末は、伝送部と、処理部と、メッセージを送信する送信部と、メッセージを受信する受信部と、を備えることができる。（いくつかの別の部と連携する）処理部は、コンテンツの取得と、コンテンツの１つ以上の使用制限と１つ以上の使用許可とのうちの少なくともいずれかを受信装置において指定する少なくとも１つ以上の使用権の設定と、１つ以上の規定された使用権のための完全性保護情報の生成と、コンテンツ暗号鍵を用いるコンテンツの暗号化と、のうちの少なくともいずれかに対して適合され得る。コンテンツデータの例として、写真、ビデオ、オーディオ、テキストファイル、又はこのようなファイルの任意の組み合わせがある。コンテンツ・データ・オブジェクトは、生成済みのコンテンツを或る一定のデータ構造の中へ埋め込むことによって、コンテンツ制御端末又は装置自体により生成され得る。上記とは別に、コンテンツ・データ・オブジェクトは、端末や、コンテンツ制御端末と関連付けられた任意の装置（同じユーザの装置など）によって生成することも可能である。
【００１３】
別の実施形態では、（第１のユーザ装置、又は送信用ユーザ装置とも呼ばれる。）コンテンツ制御端末は、デジタルコンテンツデータを含むコンテンツ・データ・オブジェクトと、コンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトとの双方を生成する。この場合、デジタル権利データ・オブジェクトは、（第２のユーザ装置、又は受信用ユーザ装置とも呼ばれる）コンテンツ受信端末においてコンテンツ・データ・オブジェクトを使用するように要求される。デジタル権利データ・オブジェクトには、コンテンツに関して受信側ユーザに与えられる権利の規定が含まれる。簡単な例では、権利オブジェクトは、別の制限をまったく伴うことなくコンテンツ・データ・オブジェクトを復号する復号化鍵を含んでもよい。この例では、コンテンツ制御端末のユーザは要求側ユーザがコンテンツの使用を許可されているか、否かの判定を行い、この判定に応じて、判定が肯定であれば、単にデジタル権利データ・オブジェクトを提供する。別の例では、この権利オブジェクトは、第２のユーザ装置によって付加されるべき１つ又は複数の使用上の規定を含んでもよい。
【００１４】
本実施形態はユーザ端末による直接の使用制御を可能にするものである。支援サーバは任意のサポート用として用いられる。但し、ユーザは、十分に信頼のおけるものではないと考えられるような上記サーバに対する制御を放棄することはない。こうすることによって、デジタルメディアデータのいずれの発行者又は著作権保有者も、直接的にかつ透過的にこのデータの使用を制御することが可能となる。
【００１５】
別の実施形態では制御支援サーバが提供される。これに加えて、このサーバは、コンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトの取得要求をコンテンツ受信端末の要求側ユーザから受信する（上記オブジェクトは以下で説明するような手段などの任意の手段によって以前に受信されたものであってもよい）。この要求の受信に応答して、上記サーバは、例えば、コンテンツ制御端末へ要求通知を直接送信することによって、データオブジェクトコンテンツ制御端末からコンテンツ受信端末へデジタル権利の伝送を開始する。
【００１６】
別の実施形態では、受信装置によって受信されるコンテンツ・データ・オブジェクトには、デジタル権利データ・オブジェクトの取得要求を送信するためにコンタクトすべき制御支援サーバのアドレスに関する情報が含まれる。
【００１７】
別の実施形態では、コンテンツ制御端末は、コンテンツ受信端末によるコンテンツオブジェクトのダウンロードを許可したり、容易にしたりするために（すなわち、リンク情報又はアドレス情報を提供するために）、このような情報を含むダウンロード記述をコンテンツ受信端末へ送信する。このような情報はコンテンツデータのタイプ（種別）、サイズ及び符号化についての記載をさらに含んでもよい。
【００１８】
別の実施形態では、支援サーバによって受信される要求には、電話番号のような、コンタクトすべきコンテンツ制御端末のアドレス情報と、要求されたデジタル権利データ・オブジェクトを特定する情報とが含まれ、これによって、コンテンツ制御端末はコンテンツ・データ・オブジェクトと関連付けられた適切なデジタル権利データ・オブジェクトをコンテンツ受信装置に提供することが可能となる。
【００１９】
別の実施形態では、支援サーバによって受信される要求には、例えば、受信側装置の電話番号、（氏名などの）ユーザＩＤのような、受信側装置に関するさらなる情報をネットワークから取り出すために支援サーバによって用いられる受信側装置のＩＰアドレスなどの受信側装置に関する情報が含まれる。この情報は、例えば要求に付加されてコンテンツ制御端末へ転送される。当該制御端末において上記情報を利用して、相手側装置とコンタクトするか、この情報（の複数部分）をユーザに表示するかの少なくともいずれかを行うことができる。
【００２０】
別の実施形態では、コンテンツ制御端末から受信したコンテンツ・データ・オブジェクトの格納又は管理を行うサーバがコンテンツのダウンロード要求を受信して、コンテンツ・データ・オブジェクトをコンテンツ受信端末へ送信する（上記サーバは、制御支援サーバと同じサーバであってもよいが、上記とは別に任意の異なるサーバであってもよい）。このダウンロード要求は、コンテンツ受信端末自体から、コンテンツ制御端末から、あるいは、送信側ユーザ又は受信側ユーザと関連付けられた他の任意のユーザ装置から受信されるようにしてもよい。この実施形態は、例えば、必ずしも安全なネットワークの一部であるとはかぎらない広帯域ネットワークノードを介する広帯域通信チャネルの使用を可能にするものである。このようにして、ピア間において安全な（但しおそらく狭帯域の）直接通信チャネル（ＳＭＳ又はＭＭＳなど）を介してコンテンツ全体を配信する必要なく、コンテンツの安全なピア・ツー・ピア制御が提供されることになる。
【００２１】
別の実施形態では、上述のように制御支援サーバに対応するコンテンツ受信装置のコンテンツ・データ・オブジェクトの使用を制御するコンテンツ制御用ユーザ端末が提供される。上記に加えて、この端末は、デジタル権利データ・オブジェクトを生成するステップと、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信するための通知を受信するステップと、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信するステップとを実行する。
【００２２】
別の実施形態では、コンテンツは、コンテンツ制御端末によって又はコンテンツ制御端末と関連付けられた装置によって暗号化される。これに対応して、コンテンツ制御端末は、いわゆる拡張暗号化規格（ＡＥＳ）に準拠する左右対称暗号化方式を用いて、コンテンツ受信端末において使用すべきコンテンツを復号するために、対応する復号化鍵をデジタル権利データ・オブジェクトの中へ挿入する。
【００２３】
別の実施形態では、暗号化済みコンテンツは受信装置の安全な環境においてコンテンツ暗号鍵を用いて復号される。安全な環境とは、ユーザ装置により設けられたハードウェアセキュリティモジュールと、ユーザ装置上で作動されるセキュリティアプリケーションとのうちの少なくともいずれかであってもよい。このセキュリティアプリケーションは、当該コンテンツに対して規定された使用権に従うユーザ装置用のコンテンツの使用を保護するものである。規定された使用権と一致しないコンテンツの使用は受信装置において許可されない。例えば、コンテンツ又は該コンテンツの（複数の）部分は、使用権によって許可されていない場合、安全な環境の中から転送され得ない。
【００２４】
別の実施形態では、上述のような制御メカニズムはＯＭＡ ＤＲＭ１．０において規定されている機能及びメッセージをベースとする。これによってＯＭＡ ＤＲＭ１．０の分離配信が拡げられることになる。これによって、（デジタル権利管理（ＤＲＭ）コンテンツフォーマット（ＤＣＦ）として符号化される）コンテンツ・データ・オブジェクトの受信時に、コンテンツ・データ・オブジェクトの中に符号化された情報を用いて、関連する権利オブジェクトの取得を開始する受け手側端末として任意のＯＭＡ ＤＲＭ１．０対応装置の使用が可能となる。
【００２５】
別の実施形態では、デジタル権利データ・オブジェクトの中へ挿入された復号化鍵を暗号化して、このオブジェクトのいずれの悪用も防止するように意図される。この暗号化はコンテンツ受信装置の公開鍵によって実行されるものであってもよい。
【００２６】
別の実施形態では、コンテンツ受信端末の公開鍵は、この端末に関するパブリック情報（電話番号や電子メールアドレスなど）に基づいて生成される。この実施形態は、データの暗号化と認証の少なくともいずれかが暗号の証明書の交換を全く必要としないという利点を有するものとなる。
【００２７】
別の実施形態では、コンテンツ制御端末と関連付けられたコンテンツ・データ・オブジェクトの使用制御をサポートする制御支援サーバは、コンテンツ・データ・オブジェクトの使用に必要なコンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトの取得要求をコンテンツ受信端末から受信する受信機と、コンテンツ制御端末からコンテンツ受信端末へのデジタル権利データ・オブジェクトの伝送を開始する（端末に接続された送信機などの）開始手段とを備える（但し、「関連付けられた」とは（コンテンツデータに関連するいわゆる著作権又は使用権を認可する権利などの）コンテンツ制御端末のユーザが（或る一定の）使用権を有していると考え得る場合を指す）。
【００２８】
別の実施形態では、コンテンツ受信端末によって受信されるべきコンテンツ・データ・オブジェクトの使用を制御するコンテンツ制御端末は、コンテンツ・データ・オブジェクトと関連付けられたデジタル権利データ・オブジェクトを生成する生成装置と、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信する旨の通知を受信する受信機と、デジタル権利データ・オブジェクトをコンテンツ受信端末へ送信する送信機と、を備える。
【００２９】
本発明はまた、ユーザ装置及び受信装置のそれぞれの処理部により処理されたとき、上述のような方法を実行するソフトウェアコード部分を含むコンピュータプログラムにも関する。コンピュータプログラムはコンピュータ可読媒体に格納することができる。コンピュータ可読媒体は、ユーザ装置又は受信装置内の永久メモリあるいは書換可能メモリであってもよいし、あるいは外部に配置してもよい。それぞれのコンピュータプログラムは、例えば一連の信号の形でケーブルや無線リンクを介してユーザ装置又は受信装置へ転送され得る。
【００３０】
以下において、十分な、かつ、完全な理解を当業者に提供するために本発明の詳細な実施形態について説明する。しかし、これらの実施形態は例示的なものであり、本発明の限定を意図するものではない。
【図面の簡単な説明】
【００３１】
【図１ａ】コンテンツの使用制御装置のための第１の実施形態の一例を示し、コンテンツ制御端末と、受信装置と、コンテンツサーバとの間での例示のメッセージを示す図である。
【図１ｂ】図１に対応する例示のプロトコルシーケンスを示す図である。
【図２】コンテンツの使用制御装置のための第２の実施形態の一例を示す図である。
【図３】コンテンツの使用制御装置のための第３の実施形態の一例を示す図である。
【発明を実施するための形態】
【００３２】
図１ａは、送信側ユーザ装置又は第１のユーザ装置ＵＥ１とも呼ばれるコンテンツ制御用ユーザ装置と、受け手側ユーザ装置又は第２のユーザ装置ＵＥ２とも呼ばれるコンテンツ受信端末と、第１のサーバＣＳ１とを備えたコンテンツの使用制御装置の一例を示す図である。第１のユーザ装置ＵＥ１は、例えば、写真用カメラのような、ユーザ装置ＵＥ１と関連付けられるか、当該ＵＥ１に接続されるか、当該ＵＥ１内に組み込まれた装置から、任意の外部又は内部のローカルな記憶装置から得られるデジタルコンテンツを受信し、対応するコンテンツオブジェクトを生成し、関連付けられた権利オブジェクトを第１及び第２のユーザ装置ＵＥ１とＵＥ２の間で直接交換しながら、第１のサーバＣＳ１を介して上記オブジェクトを第２のユーザ装置ＵＥ２へ伝送する。
【００３３】
第１のユーザ装置ＵＥ１と、第２のユーザ装置ＵＥ２と、第１のサーバＣＳ１との間におけるメッセージ交換を示す例として、以下のステップが挙げられる：
− 第１のステップにおいて、第１のユーザ装置ＵＥ１は１番目のメッセージ１を受信する。上記とは別に、第１のユーザ装置ＵＥ１は一体型カメラによってコンテンツ自体を生成するようにしてもよい。第１のユーザ装置ＵＥ１は、ＤＲＭコンテンツフォーマット（ＤＣＦ）オブジェクト及び関連付けられた権利オブジェクト（ＲＯ）を生成する。さらに、ＤＣＦを指し示すリンクを含むいわゆるダウンロード記述子（ＤＤ）が生成されるようにしてもよい。
【００３４】
− 第２のステップにおいて、２番目のメッセージ２を送信することによって、第１のユーザ装置ＵＥ１はＤＣＦとＤＤとを第１のサーバＣＳ１にアップロードする。上記とは別に、ＣＳ１によってＤＣＦ又はＤＤへのリンクを生成すると共に、このステップの範囲内でＤＣＦ又はＤＤを第１のユーザ装置ＵＥ１へ返送することができる。
【００３５】
− 第３のステップにおいて、第１のユーザ装置ＵＥ１は、例えばショート・メッセージ・サービス（ＳＭＳ）によるメッセージによって、ＤＣＦ又はＤＤへのリンクを含む有線通信と無線通信の両方で３番目のメッセージ３を第２のユーザ装置ＵＥ２へ送信する。
【００３６】
− 第４のステップにおいて、第２のユーザ装置ＵＥ２は、４番目のメッセージ４と共にＤＣＦを取得するために、ＤＤによって又は直接リンクによって第１のサーバＣＳ１とコンタクトを行う。
【００３７】
− 第５のステップにおいて、第２のユーザ装置ＵＥ２は、例えば（いわゆるＤＣＦの「権利発行者」フィールド内などのような）ＤＣＦ内で指定されたユニフォームリソースロケータ（ＵＲＬ）を用いることによって、ＤＣＦと関連付けられたＲＯを要求するために５番目のメッセージ５を第１のサーバＣＳ１から送信する。
【００３８】
− 第６のステップにおいて、サーバＣＳ１は、例えばＳＭＳテキストメッセージ毎に、６番目のメッセージ６と共に第１のユーザ装置ＵＥ１へ上記要求を転送する。また、サーバＣＳ１は、第２のすなわち受信用ユーザ装置ＵＥ２に関する情報（装置ＵＥ２の電話番号など）をさらに転送又は追加することができる。
【００３９】
− 第７のステップにおいて、第１のユーザ装置ＵＥ１は、例えばＲＯを中に含むＷＡＰのプッシュＳＭＳによって、要求されたＲＯを７番目のメッセージ７と共に第２のユーザ装置ＵＥ２へ送信する。
【００４０】
すでに第１のステップ内において関連付けられたＲＯを生成するステップとは別に、上記オブジェクトは、第７のステップまでに、例えば第６のステップと共に又は第６のステップの後に生成されてもよい。ＲＯにおける権利は、ステップ６などにおいて以前のメッセージで得られた情報に従属するものであってもよい。さらに、ユーザは、（コンテンツへのアクセス許可を与えるように求めるＵＥ１のディスプレイに現れるウィンドウなどによって）前のステップで受信した情報を提示する入力を求められる場合もある。
【００４１】
第１のユーザ装置ＵＥ１内におけるコンテンツ制御は、第１のユーザ装置ＵＥ１に内蔵されているコンテンツ制御用エージェントによってサポートされてもよい。例えば、このコンテンツ制御は第１のユーザ装置のＣＰＵによって制御されるプログラムとして実現される。また、以下において、このプログラムはＤＲＭプログラムとも呼ばれる。このプログラムは、ユーザによるデジタルコンテンツの選択を特にサポートすることが可能であり、このデジタルコンテンツは、以下において任意の知覚可能な（可聴の、可視の、オーディオビジュアルな、又は読み取り可能な）ドキュメントであってもよいマルチメディアコンテンツと呼ばれる場合もある。上記プログラムにおけるマルチメディアコンテンツは１つ又は複数の写真、映画、音声又は音楽ファイル、テキスト文書、又はこれらの任意の組み合わせなどであってもよい。
【００４２】
コンテンツの受信後又は選択後あるいはコンテンツの受信又は選択と連携して、第１のユーザ装置ＵＥ１のユーザは、第２のユーザ装置ＵＥ２のユーザに関して、コンテンツに対する使用権を手動で規定してもよい。上記とは別に、例えば（複数の）特定グループの受け手側ユーザに対して個々に規定される上記のような規定はデフォルト値を用いて自動的に実行することも可能である。上記使用権は１つ又は複数の使用制限と使用許可の少なくともいずれか又は許可と制約との任意の組み合わせを含んでもよい。許容使用権の例として以下のものが挙げられる：閲覧、再生、転送、複製、印刷、コピー、修正、及び同期。許容使用権の例として以下のものが挙げられる：規定された目的バインディング（Purpose Binding）、時間的制約、及び許可された使用の回数制限。「表示」、「再生」又は「実行」は（ビデオコンテンツの画面上での表示又は装置の再生あるいはスピーカによるオーディオコンテンツの再生などの）コンテンツの消費を行えるように受け手側ユーザに権利（使用権利）を割り当て、「転送」はコンテンツを別の装置へ転送するように、「印刷」は装置からのコンテンツをプリンタ側でプリントアウトするように、あるいは「エクスポート」はコンテンツを別の装置へ送信するように受け手側ユーザに権利を割り当てる。この場合、コンテンツはエクスポート用装置以外の別の手段によって保護されてもよい。
【００４３】
「目的バインディング」を用いて、指定された目的又は特定のアプリケーションに従ってコンテンツの使用を限定することが可能となる。例えば、使用コンテンツに対して課金を行うことが可能になるが、他の目的のために「目的バインディング」が用いられることはない。「時間的制約」は、コンテンツの使用時間又は使用時間の間隔を限定するために用いることができる。さらに、コンテンツの使用回数は「カウント」によって限定してもよい。
【００４４】
次に図１ｂを参照しながら、メッセージ２〜７のシーケンス図によって図１ａで解説したステップについて説明する。これらのステップはＯＭＡ ＤＲＭ１．０用として特に調整されたものである。
【００４５】
− マルチメディアコンテンツの受信又は選択（ＳｅｌｅｃｔＣｏｎｔｅｎｔ）を行い、このコンテンツに対する使用権の規定（ＤｅｆｉｎｅＲｉｇｈｔｓ）を行った後、ＤＲＭプログラムはＤＣＦ及び関連するＲＯ（及びおそらくＤＤ）を生成する（ＧｅｎｅｒａｔｅＤＲＭ）。
【００４６】
− 第１のユーザ装置ＵＥ１のＤＲＭプログラムは、２番目のメッセージ２を送信する（ＵｐｌｏａｄＤＣＦ）ことによって、ＤＣＦ（及びＤＤ）を第１のサーバＣＳ１にアップロードする（ＵｐｌｏａｄＤＲＭ）。第１のサーバＣＳ１はこのメッセージを処理し（ＨａｎｄｌｅＵｐｌｏａｄＤＲＭ）、ＤＣＦ（及びＤＤ）をセーブする。
【００４７】
− 第１のユーザ装置ＵＥ１のＤＲＭプログラムは、３番目のメッセージ３を送信する（ＳｅｎｄＬｉｎｋ）ことによってＤＣＦ（又はＤＤ）へのリンクを第２のユーザ装置ＵＥ２へ送信する（ＳｅｎｄＵＲＬ）。
【００４８】
− 第２のユーザ装置ＵＥ２は４番目のメッセージ４を送信することによって、（直接的か又はＤＤによるかのいずれかによって）ＤＣＦを取得し、第１のサーバＣＳ１に指示をアップロードする（ｇｅｔＤＣＦ又はＧｅｔＤＤ）。この第１のサーバＣＳ１は、上記４番目のメッセージ４と共にＤＣＦを第２のユーザ装置ＵＥ２へ順次送信する（ＳｅｎｄＤＣＦ）か、ＤＤを順次送信し（ＳｅｎｄＤＤ）、指示をダウンロードする。第２のユーザ装置ＵＥ２がＤＤを取得した場合、ユーザ装置ＵＥ２はＤＤによってＤＣＦをダウンロードする（例えばＤＣＦへのリンクを含む）。
【００４９】
− ＤＣＦの「権利発行者」フィールドに指定されているＵＲＬを用いて、ＤＲＭエージェントは５番目のメッセージ５を第１のサーバＣＳ１へ送信することによってＲＯを要求する（ＲｅｑｕｅｓｔＲＯ）。
【００５０】
− 第１のサーバＣＳ１は、５番目のメッセージ５（ＲｅｑｕｅｓｔＲＯ）を処理し（ＨａｎｄｌｅＲｅｑｕｅｓｔＲＯ）、６番目のメッセージ６を第１のユーザ装置ＵＥ１へ送信する（ＦｏｒｗａｒｄＲｅｑｕｅｓｔＲＯ）ことによってＲＯ要求を第１のユーザ装置ＵＥ１へ転送する（ＦｏｒｗａｒｄＲＯ）。上記の解説によれば、第１のサーバＣＳ１は、さらに受信側装置ＵＥ２に関する情報を送信してもよい。
【００５１】
− 第１のユーザ装置ＵＥ１のＤＲＭプログラムは、６番目のメッセージ（ＦｏｒｗａｒｄＲｅｑｕｅｓｔＲＯ）を処理し（ＨａｎｄｌｅＲｅｑｕｅｓｔＲＯ）、７番目のメッセージ７を第２のユーザ装置ＵＥ２へ送信する（ＳｅｎｄＲＯ）ことによって第２のユーザ装置ＵＥ２へＲＯをプッシュする（ＰｕｓｈＲＯ）。第２のユーザ装置ＵＥ２のＤＲＭエージェントはこのメッセージを処理し、ＤＣＦに対する使用権を実施する。
【００５２】
上述のパラメータについての説明
ＲＯＩＤ（デジタル権利データ・オブジェクトの識別子）：受け手側ユーザＵＥ２のアドレスを含み得るＲＯの（ランダムな）ＩＤ（電話番号など）。例えば、ＲＯＩＤ：＝ＲｅｃｉｐｉｅｎｔＡｄｄｒｅｓｓ：ＲａｎｄｏｍＮｕｍｂｅｒ
ＲｅｑｕｅｓｔＲＯＩＤ：（連結によって電話番号及びＲＯＩＤからＲｅｑｕｅｓｔＲＯＩＤを構成することにより）第１のユーザのアドレスにマッチされ得る。例えば、ＲｅｑｕｅｓｔＲＯＩＤ：＝ＳｅｎｄｅｒＡｄｄｒｅｓｓ：ＲＯＩＤ
ＤＣＦ：ＯＭＡ ＤＲＭ１．０（ＤＲＭコンテンツフォーマット仕様）に規定されていように暗号化済みのコンテンツを中に含むＤＲＭコンテンツフォーマット。「ヘッダ」フィールドの「権利発行者」エレメントは第１のサーバＣＳ１を指すＵＲＩを含む。さらに、ＵＲＩはＲＯＩＤ又は要求ＲＯＩＤに関する情報若しくはＲＯＩＤ又は要求ＲＯＩＤへの参照を含んでもよい。
【００５３】
ＤＤ：ＤＣＦと関連付けられたダウンロード記述子
ＤＤＵＲＬ：第１のサーバＣＳ１上のアップロードＤＤのＵＲＬ
メッセージ例
ＵｐｌｏａｄＤＣＦ：ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバへＤＣＦをアップロードするためのＨＴＴＰ／ＰＯＳＴ要求
→ パラメータ：ＤＣＦ
ＳｅｎｄＬｉｎｋ：ＤＣＦのＵＲＬを中に含むＳＭＳ
→ パラメータ：ＤＣＦＵＲＬ
ＧｅｔＤＣＦ：ＤＣＦをダウンロードするためのＨＴＴＰ／ＧＥＴ要求
→ パラメータ：ＤＣＦＵＲＬ
ＳｅｎｄＤＣＦ：ＤＣＦを中に含むＨＴＴＰレスポンス
→ パラメータ：ＤＣＦ
ＲｅｑｕｅｓｔＲＯ：ＲＯを要求するＨＴＴＰ／ＧＥＴ要求
→ パラメータ：ＲｅｑｕｅｓｔＲＯＩＤ
Ｆｏｒｗａｒｄ ＲｅｑｕｅｓｔＲＯ：送信機の電話番号へ送信されたＳＭＳ
→ パラメータ：ＲＯＩＤ
ＳｅｎｄＲＯ：ＲＯを中に含むＷＡＰプッシュＳＭＳ
→ パラメータ：ＲＯ
受信側ユーザ装置ＵＥ２を参照してわかるように、もし装置ＵＥ２がＯＭＡ ＤＲＭ１．０をサポートしていれば、特定の実装構成は不要となる。ＧｅｔＤＤ及びＳｅｎｄＤＤ（第４のステップ）の機能は、例えば、ＳｅｎｄＬｉｎｋメッセージ（ＳＭＳ）の中に含まれているＤＣＦ又はＤＤのＵＲＬを用いて、又は、いわゆるＷＡＰプッシュ法によって単に受け手側ユーザのインターネットを介したブラウジングから結果として生じることになる。ＲｅｑｕｅｓｔＲＯを送信する機能（第５のステップ）はＯＭＡ ＤＲＭ１．０に従うＤＲＭエージェントによってすでに実装されている。
【００５４】
図２はコンテンツの使用制御装置のための第２の実施形態例を示す。図１ａに追加して、別のユーザ装置ＵＥ１’が示されているが、このユーザ装置は第１のユーザ装置ＵＥ１の同じユーザと関連付けられた装置である。このような別のユーザ装置は、（例えばインターネットを介して、及びＨＴＴＰによって）第１のサーバと通信することが可能なパーソナルコンピュータ又は他の任意のコンピュータ装置であってもよい。図１ａの第１のステップに対応するステップにおいて、デジタルデータは（メッセージ１’と共に）上記別のユーザ装置ＵＥ１’へ送信される。上記とは別に、このデータは装置の内部で生成されたものであってもよいため、このステップを省くことが可能である。図１ａのステップ２に対応する次のステップにおいて、上記別のユーザ装置ＵＥ’は第１のサーバへ送信すべきＤＣＦオブジェクトを生成する。これらの別のステップは図１ａで上述したようなステップ３〜７と同様に実行され得る。
【００５５】
第１のユーザ装置ＵＥ１及び上記別のユーザ装置ＵＥ１’は、制御情報を交換するために（ブルートゥースや赤外線接続などの）ローカルなインタフェースによって接続されてもよい。上記別のユーザ装置ＵＥ’が権利オブジェクトも生成した場合、このインタフェースを使用して、権利オブジェクトを第１のユーザ装置ＵＥ１へ伝えるようにすることも可能である。
【００５６】
図３はコンテンツの使用制御を行うための第３の実施形態例を示す。第１のサーバＣＳ１の代わりに、第１のサーバＣＳ１のタスクを共有する、第２のサーバ（又はＤＲＭ支援サーバ）ＣＳ２及び第３のサーバ（又はコンテンツ管理用サーバ）ＣＳ３が示されている。第２のサーバＣＳ２がコンテンツオブジェクトの使用制御をサポートする機能を含む一方で、第３のサーバＣＳ３は、（例えばコンテンツのアップロード、格納及びダウンロードを管理することによって）送信側ユーザから受信側ユーザへのコンテンツオブジェクトの送信を管理する機能を有する。上記に加えて、図１ａの第２のステップに対応するステップにおいて、第１のユーザ装置ＵＥ１は、（図３に示す例に従ってコンテンツデータを自動的に生成した）ＤＣＦ（及びＤＤ）を第２の代替メッセージ２”の送信によって第３のサーバＣＳ３へアップロードする。第１のユーザ装置ＵＥ１から第２のユーザ装置ＵＥ２へ３番目のメッセージ３を送信するステップを有する次のステップは同様のままのステップであってもよい。図１ａの第４のステップに対応する次のステップにおいて、第２のユーザ装置ＵＥ２は（例えば第３のサーバへのリンクを含むＤＤによって）第３のサーバＣＳ３にコンタクトして、代替の４番目のメッセージ４”と共にＤＣＦを取得する。これらの別のステップは図１ａで上述したようなステップ３〜７と同様に実行することが可能である。
【００５７】
代替例において、第１のユーザ装置ＵＥ１から別の受信装置ＵＥ２へさらに配信すべきコンテンツを受信する中間ユーザ装置を設けるようにしてもよい。このような配信はスーパー配信法と呼ばれる場合もある。この代替例は、第３のサーバＣＳ３を中間ユーザ装置によって確実に置き換えることによって図３に示されているように第３の実施形態例として実現され得る。この場合、第１のユーザ装置ＵＥ１は、第２の代替メッセージ２”を送信することによって中間ユーザ装置にＤＣＦをアップロードする。図３のステップ３及び４の代わりに、第２のユーザ装置ＵＥ２に通知を行い、かつ、ブルートゥース、赤外線、ＭＭＳ又はＷＬＡＮなどによって、中間装置から第２のユーザ装置ＵＥ２へＤＣＦの転送を行う別の手段を用いてもよい。これらの別のステップは上述したようなステップ５〜７と同様に実行され得る。
【００５８】
上記に開示した実施形態は、ユーザが、例えば上述のようなＯＭＡ ＤＲＭ１．０による分離配信保護に基づいて（移動電話機などの）そのユーザ機器を介して任意のサイズのコンテンツの使用を制御できるようにするものである。
【００５９】
ベースとしてＯＭＡ ＤＲＭ１．０を用いる場合、もし受信側装置がＯＭＡ ＤＲＭ１．０に対応したものであれば受信装置側において修正を行う必要はない。したがって、ＯＭＡ ＤＲＭ１．０の使用が可能な任意の装置（したがって最近の移動電話機のほとんど）は保護されたコンテンツデータ及び使用権データを個別に受信して、コンテンツの使用権を実施することが可能となる。
【００６０】
送信装置側においては、送信側装置内のソフトウェアの修正により追加機能の実現が可能となる。したがって、ＯＭＡ ＤＲＭ１．０を修正する必要なく本発明の実施形態の使用が可能となる。
【００６１】
或る一定レベルのセキュリティを提供するために、第１のユーザ装置ＵＥ１の内部においてコンテンツの暗号化を行うことができる。上述したように、ＤＲＭにより保護されたメディアオブジェクトを提供するために、ユーザは、暗号化されたコンテンツファイル自体と、復号化鍵と権利についての記述を中に含む関連付けられたＲＯとの双方を必要とする。また、達成すべき信頼性のレベルに応じて（捕捉、補正などの）悪用からＲＯを保護する目的が存在する場合もある。上記に加えて安全なチャネルを介してＲＯを伝送するようにしてもよい。上記とは別に、又は、上記に加えて、ＲＯに対して整合性を保護するようにしてもよい。
【００６２】
ＯＭＡ ＤＲＭ２．０は、証明書の使用による信頼性関係の確立によってＲＯの安全な配信を提案するものである。この点に関して、ＯＭＡ ＤＲＭ２．０は公開鍵インフラストラクチャ（ＰＫＩ）を必要とする。公開鍵及び対応する秘密鍵がシステム内の個々のエンティティに対して供給される。公開鍵は認証局（ＣＡ）によって署名された証明書の内部にカプセル化される。信用のおけるオンライン証明書状態プロトコル（ＯＣＳＰ）応答装置が証明書の有効性をチェックし、かつ、証明書の状態（良好、撤回又は不明）を示す。保護されたコンテンツは、追加の保護を必要とすることなく、（例えば無線、ＷＬＡＮ、取り外し可能媒体などの）任意の手段によって装置へ配信されることができる。ＯＭＡ ＤＲＭ１．０の場合と同様、ＯＭＡ ＤＲＭ２．０はピア・ツー・ピア制御メカニズムを扱わない。ピア・ツー・ピアネットワーク（Ｐ２Ｐ）では、個々のピアはクライアントとサーバの双方として機能する。移動通信ネットワークにおけるＰ２Ｐ通信用としてＯＭＡ ＤＲＭ２．０を考えるとき、個々の移動電話機はＤＲＭコンテンツの送受信を行う（すなわちＤＲＭエージェント及び権利発行者として機能する）ことができなければならない。
【００６３】
権利オブジェクトの交換のためにＯＭＡ ＤＲＭ２．０によって提案されているような公開鍵暗号法は、送信者側へ与えられる受信者側の公開鍵に関する事前の知識に依存する。通常、秘密鍵は証明書の中に（例えばＯＭＡ ＤＲＭ２．０によって提案されている権利オブジェクト取得プロトコルＲＯＡＰなどの中に）埋め込まれていて、初期登録段の間に交換される。ピア・ツー・ピアシナリオでは、証明書の交換は必ずしも可能ではない。特に、メッセージを送信しなければならない時点において受信側ピアがオフラインになっている場合には、証明書の交換は可能ではない。このケースでは、受信側装置の公開鍵に関する知識なしで、メッセージをネットワークに格納してもよいが、送信側装置は受信側装置へ送信すべき権利オブジェクトを保護することはできなくなる。
【００６４】
上記に提案されているような証明書ベースの暗号法の代替例として、いわゆるＩＤベースのデジタル権利の管理（ＩＢ−ＤＲＭ）が提案されている。この権利管理システムはＯＭＡ ＤＲＭ２．０をベースとすることが可能であるが、ＩＤベースの公開鍵暗号法（ＩＤ−ＰＫ）に依拠している。ＩＤ−ＰＫ方式では、公開鍵は、電子メールアドレス、電話番号又はＳＩＰ−ＵＲＩのようなパブリックＩＤなどの公開情報から導き出される。その結果、データ又は認証の暗号化は事前の証明書の交換を必要としない。ＩＤベースの暗号化は例えば双線形ペアリングを用いて楕円曲線暗号化方式を使用して実現され得る。Ｃ． Ｇｅｎｔｒｙ及びＡ． Ｓｉｌｖｅｒｂｅｒｇによる論文「階層型ＩＤベースの暗号化方式」（暗号化方式並びに情報セキュリティの理論及び応用に関する第８回国際会議会報：暗号化方式の進歩ｐ．５４８〜５６６、２００２年）によれば、階層型ＩＤベースの暗号化は、従来のＰＫＩ ＤＲＭシステムの場合と同様，ＩＢ−ＤＲＭに対してツリー構造アーキテクチャを生成し、このアーキテクチャによってシステムのセキュリティとスケーラビリティとが提供される。さらに、鍵がＩＤストリングから導き出されるので鍵管理が容易化されることになる。ＩＢ−ＤＲＭシステムでは、権利オブジェクト（ＲＯ）はワンパスプロトコルを用いて受け手へ配信され得る。証明書の事前の交換を行う必要はなく、認証と認可とは分離して行うことができる。ＩＢ−ＤＲＭは、メッセージ（すなわちＲＯ）をネットワークのどこかに格納できるようになっているプッシュモードで用いるように設計されているのでＰ２Ｐネットワークにとって好適である。
【００６５】
ＩＢＥを用いるＤＲＭ保護は以下のステップを含んでもよい。
【００６６】
１．基本暗号パラメータが生成され、次いで、これらのパラメータは、信頼のおける認証機関（ＴＡ）によって（部分的に）公開される。もし複数のＴＡがシステム内に存在していれば階層の形でこれらのパラメータを編成してもよい。
【００６７】
２．個々の通信相手はそのそれぞれのＴＡから自分の秘密鍵を取得する。鍵は製造工程中安全なチャネルを用いて又はトランスポート層セキュリティ（ＴＬＳ）を用いて転送されなければならない。
【００６８】
３．送信側装置において、コンテンツの暗号化が行われ、このコンテンツの使用権が規定される。少なくともコンテンツの暗号化のために用いられる鍵は受信装置の公開鍵を用いて暗号化される。公開鍵は、以上説明したようなＩＤベースの公開鍵暗号方式を用いて、（例えば電話番号、電子メールアドレスなどの）受け手の或るパブリックＩＤ及びＴＡによって公開されているシステムパラメータから導き出される。上記暗号化された鍵及び規定された使用権は、整合性の保護又は送信側装置のＩＤベースの署名が行われたＲＯの中へ埋め込まれる。
【００６９】
４．コンテンツと使用権の双方は受信側装置へ配信される（このステップ中に盗聴を防止する追加の保護を行う必要はない）。
【００７０】
５．受信装置は、ＲＯの真正性を検証し、暗号化済みコンテンツを順次復号するために使用できる鍵の復号化を行う。
【００７１】
オプションとして、上記のステップ３とステップ５の少なくともいずれかのステップにおいて、送信側装置と受信側装置の少なくともいずれかの装置の鍵の有効性をチェックすることができる。
【００７２】
上記に提案されたようなＩＢ−ＤＲＭシステムに対してＯＭＡ ＤＲＭ２．０と同様のセキュリティレベルが提供されるが、このセキュリティレベルよりもさらに多くの柔軟性と単純さが提供される。特に、唯一のメッセージ交換によってＩＤベースの権利オブジェクト取得プロトコルＲＯＡＰの実行が可能となる。実際には、例えばエンティティが信頼のおけるものであるか否かを判定する専用ノードにコンタクトすることによって認証と認可とをいつでも分離して行うことが可能となる。ＩＤベースのＲＯＡＰは、プッシュモードで使用されるように設計されているのでＰ２Ｐネットワークに適している。このことは、受け手側ピアが送信側ピアからコンテンツを要求する必要がないことを意味し、これは一般的な使用例である（一般に、受け手側ピアは、ピアがメッセージを送信したいと思っていることを認知さえしていない場合もある）。さらに、その後ピアは唯一のメッセージが交換されるので、オンライン状態である必要はない。
【特許請求の範囲】
【請求項１】
通信ネットワークのコンテンツ制御端末（ＵＥ１）に関連付けられているコンテンツ・データ・オブジェクト（４）の使用の制御を支援する方法であって、
前記コンテンツ・データ・オブジェクト（４）を使用するために、取得されている前記コンテンツ・データ・オブジェクト（４）に関連付けられたデジタル権利データ・オブジェクト（７）を取得するコンテンツ受信端末（ＵＥ２）からの要求（５）受信するステップと、
前記コンテンツ制御端末（ＵＥ１）から前記コンテンツ受信端末（ＵＥ２）へ前記デジタル権利データ・オブジェクト（７）の送信を開始するステップと
を含むことを特徴とする方法。
【請求項２】
前記コンテンツ受信端末（ＵＥ２）によって受信される前記コンテンツ・データ・オブジェクト（４）は、前記デジタル権利データ・オブジェクト（７）を取得する前記要求（５）を送信するために接続される制御支援サーバ（ＣＳ１，ＣＳ２）のアドレスに関する情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記要求（５）の受信に応じて、前記コンテンツ制御端末（ＵＥ１）から前記コンテンツ受信端末（ＵＥ２）へ前記デジタル権利データ・オブジェクト（７）の送信を開始するために、前記コンテンツ制御端末（ＵＥ１）への要求通知（６）を送信するステップをさらに含むことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記要求（５）は、電話番号を示す前記コンテンツ制御端末（ＵＥ１）のアドレスの情報と、要求された前記デジタル権利データ・オブジェクト（７）の識別子とを含み、
前記要求通知（６）は、前記アドレスを使用することによって前記コンテンツ制御端末（ＵＥ１）へ送信される前記識別子を含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記要求（５）に含まれる情報から、前記コンテンツ受信端末（ＵＥ２）を示す電話番号又はＩＰアドレスを示すアドレス情報を取り出すステップと、
前記コンテンツ制御端末（ＵＥ１）が前記コンテンツ受信端末（ＵＥ２）へ接続できるように、前記取り出したアドレス情報を前記要求通知に挿入するステップと
をさらに含むことを特徴とする請求項３又は４に記載の方法。
【請求項６】
前記コンテンツ受信端末（ＵＥ２）へ前記コンテンツ・データ・オブジェクト（４）を送信するためのコンテンツ・ダウンロード要求（４）を受信するステップと、
前記コンテンツ・データ・オブジェクトを前記コンテンツ受信端末（ＵＥ２）へ送信するステップと
をさらに含むことを特徴とする請求項１乃至５の何れか１項に記載の方法。
【請求項７】
前記コンテンツ・ダウンロード要求（４）は、前記コンテンツ制御端末（ＵＥ１）、前記コンテンツ受信端末（ＵＥ２）、及び前記コンテンツ制御端末（ＵＥ１）に関連付けられたデバイス（ＵＥ１’）の何れか１つから受信されることを特徴とする請求項６に記載の方法。
【請求項８】
少なくとも、前記要求（５）は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従って生成され、要求通知（６）は、ショート・メッセージ・サービス（ＳＭＳ）に従って１つ以上のメッセージとして生成されることを特徴とする請求項１乃至７の何れか１項に記載の方法。
【請求項９】
請求項１乃至８の何れか１項に記載の方法を実行するための制御支援サーバ（ＣＳ１，ＣＳ２）。
【請求項１０】
コンテンツ受信端末（ＵＥ２）のコンテンツ・データ・オブジェクト（４）の使用を制御する方法であって、
前記コンテンツ・データ・オブジェクト（４）に関連付けられ、前記コンテンツ・データ・オブジェクト（４）のコンテンツを使用するために必要とされる、デジタル権利データ・オブジェクト（７）を生成するステップと、
前記デジタル権利データ・オブジェクト（７）を前記コンテンツ受信端末（ＵＥ２）へ送信する通知（６）を受信するステップと、
前記デジタル権利データ・オブジェクト（７）を前記コンテンツ受信端末（ＵＥ２）へ送信するステップと
を含むことを特徴とする方法。
【請求項１１】
前記デジタル権利データ・オブジェクト（７）内に定義された使用権利は、目的バインディング、時間的制約、及び許可された最大使用回数の少なくとも１つを含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記コンテンツ受信端末（ＵＥ２）において前記コンテンツ・データ・オブジェクト（４）を復号化するために使用されるべく、前記デジタル権利データ・オブジェクト（７）へ復号化鍵を埋め込むステップをさらに含むことを特徴とする請求項１０又は１１に記載の方法。
【請求項１３】
前記デジタル権利データ・オブジェクト（７）へ埋め込まれるべき前記コンテンツ受信端末（ＵＥ２）の公開鍵と共に前記復号化鍵を暗号化するステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記コンテンツ受信端末（ＵＥ２）の前記公開鍵は、前記コンテンツ受信端末（ＵＥ２）の電話番号又は電子メールアドレスを示すアドレスに基づいて生成されることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記コンテンツ受信端末（ＵＥ２）が適切なサーバ（ＣＳ１，ＣＳ３）から前記コンテンツ・データ・オブジェクト（４）をダウンロードすることを可能にするか又は支援する情報を含む、前記コンテンツ受信端末（ＵＥ２）へ送信するべきダウンロード情報（３）を生成するステップをさらに含むことを特徴とする請求項１０乃至１４の何れか１項に記載の方法。
【請求項１６】
前記ダウンロード情報は、前記コンテンツ・データ・オブジェクト（４）へのリンク情報、前記コンテンツ・データ・オブジェクト（４）をダウンロードするために接続されるサーバ（ＣＳ１，ＣＳ３）のアドレス情報、前記コンテンツ・データ・オブジェクト（４）のサイズに関する情報、及び、多目的インターネットメール拡張（ＭＩＭＥ種別）などの前記コンテンツ・データ・オブジェクトの種別を特定する種別情報の少なくとも１つを含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
請求項１０乃至１６の何れか１項に記載の方法を実行するための、コンテンツ受信端末（ＵＥ２）によって受信されるべきコンテンツ・データ・オブジェクト（４）使用を制御するためのコンテンツ制御端末（ＵＥ１）。
【請求項１８】
ユーザデバイス（ＵＥ１）の処理部へロード可能なコンピュータプログラムであって、請求項１０乃至１６の何れか１項に記載の方法を実行するためのコンピュータプログラム。
【請求項１９】
サーバ（ＣＳ１，ＣＳ２）の処理部へロード可能なコンピュータプログラムであって、請求項１乃至８の何れか１項に記載の方法を実行するためのコンピュータプログラム。
【請求項１】
通信ネットワークのコンテンツ制御端末（ＵＥ１）に関連付けられているコンテンツ・データ・オブジェクト（４）の使用の制御を支援する方法であって、
前記コンテンツ・データ・オブジェクト（４）を使用するために、取得されている前記コンテンツ・データ・オブジェクト（４）に関連付けられたデジタル権利データ・オブジェクト（７）を取得するコンテンツ受信端末（ＵＥ２）からの要求（５）受信するステップと、
前記コンテンツ制御端末（ＵＥ１）から前記コンテンツ受信端末（ＵＥ２）へ前記デジタル権利データ・オブジェクト（７）の送信を開始するステップと
を含むことを特徴とする方法。
【請求項２】
前記コンテンツ受信端末（ＵＥ２）によって受信される前記コンテンツ・データ・オブジェクト（４）は、前記デジタル権利データ・オブジェクト（７）を取得する前記要求（５）を送信するために接続される制御支援サーバ（ＣＳ１，ＣＳ２）のアドレスに関する情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記要求（５）の受信に応じて、前記コンテンツ制御端末（ＵＥ１）から前記コンテンツ受信端末（ＵＥ２）へ前記デジタル権利データ・オブジェクト（７）の送信を開始するために、前記コンテンツ制御端末（ＵＥ１）への要求通知（６）を送信するステップをさらに含むことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記要求（５）は、電話番号を示す前記コンテンツ制御端末（ＵＥ１）のアドレスの情報と、要求された前記デジタル権利データ・オブジェクト（７）の識別子とを含み、
前記要求通知（６）は、前記アドレスを使用することによって前記コンテンツ制御端末（ＵＥ１）へ送信される前記識別子を含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記要求（５）に含まれる情報から、前記コンテンツ受信端末（ＵＥ２）を示す電話番号又はＩＰアドレスを示すアドレス情報を取り出すステップと、
前記コンテンツ制御端末（ＵＥ１）が前記コンテンツ受信端末（ＵＥ２）へ接続できるように、前記取り出したアドレス情報を前記要求通知に挿入するステップと
をさらに含むことを特徴とする請求項３又は４に記載の方法。
【請求項６】
前記コンテンツ受信端末（ＵＥ２）へ前記コンテンツ・データ・オブジェクト（４）を送信するためのコンテンツ・ダウンロード要求（４）を受信するステップと、
前記コンテンツ・データ・オブジェクトを前記コンテンツ受信端末（ＵＥ２）へ送信するステップと
をさらに含むことを特徴とする請求項１乃至５の何れか１項に記載の方法。
【請求項７】
前記コンテンツ・ダウンロード要求（４）は、前記コンテンツ制御端末（ＵＥ１）、前記コンテンツ受信端末（ＵＥ２）、及び前記コンテンツ制御端末（ＵＥ１）に関連付けられたデバイス（ＵＥ１’）の何れか１つから受信されることを特徴とする請求項６に記載の方法。
【請求項８】
少なくとも、前記要求（５）は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従って生成され、要求通知（６）は、ショート・メッセージ・サービス（ＳＭＳ）に従って１つ以上のメッセージとして生成されることを特徴とする請求項１乃至７の何れか１項に記載の方法。
【請求項９】
請求項１乃至８の何れか１項に記載の方法を実行するための制御支援サーバ（ＣＳ１，ＣＳ２）。
【請求項１０】
コンテンツ受信端末（ＵＥ２）のコンテンツ・データ・オブジェクト（４）の使用を制御する方法であって、
前記コンテンツ・データ・オブジェクト（４）に関連付けられ、前記コンテンツ・データ・オブジェクト（４）のコンテンツを使用するために必要とされる、デジタル権利データ・オブジェクト（７）を生成するステップと、
前記デジタル権利データ・オブジェクト（７）を前記コンテンツ受信端末（ＵＥ２）へ送信する通知（６）を受信するステップと、
前記デジタル権利データ・オブジェクト（７）を前記コンテンツ受信端末（ＵＥ２）へ送信するステップと
を含むことを特徴とする方法。
【請求項１１】
前記デジタル権利データ・オブジェクト（７）内に定義された使用権利は、目的バインディング、時間的制約、及び許可された最大使用回数の少なくとも１つを含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記コンテンツ受信端末（ＵＥ２）において前記コンテンツ・データ・オブジェクト（４）を復号化するために使用されるべく、前記デジタル権利データ・オブジェクト（７）へ復号化鍵を埋め込むステップをさらに含むことを特徴とする請求項１０又は１１に記載の方法。
【請求項１３】
前記デジタル権利データ・オブジェクト（７）へ埋め込まれるべき前記コンテンツ受信端末（ＵＥ２）の公開鍵と共に前記復号化鍵を暗号化するステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記コンテンツ受信端末（ＵＥ２）の前記公開鍵は、前記コンテンツ受信端末（ＵＥ２）の電話番号又は電子メールアドレスを示すアドレスに基づいて生成されることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記コンテンツ受信端末（ＵＥ２）が適切なサーバ（ＣＳ１，ＣＳ３）から前記コンテンツ・データ・オブジェクト（４）をダウンロードすることを可能にするか又は支援する情報を含む、前記コンテンツ受信端末（ＵＥ２）へ送信するべきダウンロード情報（３）を生成するステップをさらに含むことを特徴とする請求項１０乃至１４の何れか１項に記載の方法。
【請求項１６】
前記ダウンロード情報は、前記コンテンツ・データ・オブジェクト（４）へのリンク情報、前記コンテンツ・データ・オブジェクト（４）をダウンロードするために接続されるサーバ（ＣＳ１，ＣＳ３）のアドレス情報、前記コンテンツ・データ・オブジェクト（４）のサイズに関する情報、及び、多目的インターネットメール拡張（ＭＩＭＥ種別）などの前記コンテンツ・データ・オブジェクトの種別を特定する種別情報の少なくとも１つを含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
請求項１０乃至１６の何れか１項に記載の方法を実行するための、コンテンツ受信端末（ＵＥ２）によって受信されるべきコンテンツ・データ・オブジェクト（４）使用を制御するためのコンテンツ制御端末（ＵＥ１）。
【請求項１８】
ユーザデバイス（ＵＥ１）の処理部へロード可能なコンピュータプログラムであって、請求項１０乃至１６の何れか１項に記載の方法を実行するためのコンピュータプログラム。
【請求項１９】
サーバ（ＣＳ１，ＣＳ２）の処理部へロード可能なコンピュータプログラムであって、請求項１乃至８の何れか１項に記載の方法を実行するためのコンピュータプログラム。
【図１ａ】
【図１ｂ】
【図２】
【図３】
【図１ｂ】
【図２】
【図３】
【公表番号】特表２０１１−５０５６４０（Ｐ２０１１−５０５６４０Ａ）
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２０１０−５３６３８５（Ｐ２０１０−５３６３８５）
【出願日】平成２０年８月１１日（２００８．８．１１）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０６０５０４
【国際公開番号】ＷＯ２００９／０７１３４９
【国際公開日】平成２１年６月１１日（２００９．６．１１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２０年８月１１日（２００８．８．１１）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０６０５０４
【国際公開番号】ＷＯ２００９／０７１３４９
【国際公開日】平成２１年６月１１日（２００９．６．１１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]