DRMトランスレーションのシステムおよび方法
DRMトランスレーションの技術は、第1デジタルコンテンツを第2デジタルコンテンツに変換する。この技術に従ったシステムの例は、第1デジタルフォーマットでコード化された第1デジタル・コンテンツ・ユニットと第1デジタル著作権管理(DRM)により保護された使用権を提供するサーバを備える。更にシステムは、第1デジタル・コンテンツ・ユニットを第2デジタルフォーマットでコード化され第2DRMにより使用権が保護された第2デジタル・コンテンツ・ユニットへと変換可能なトランスレータを備える。
【発明の詳細な説明】
【背景技術】
【0001】
デジタル著作権管理(DRM)は、デジタルコンテンツの消費者とデジタルコンテンツのプロバイダとの間での利用契約の支援を目的とした技術分野である。これらの契約を支援するために様々な異なる手段が用いられている。
【0002】
デジタルコンテンツの利用のために契約が締結されると、デジタルコンテンツとともに使用許諾契約書(ライセンスアグリーメント)がパッケージされる。デジタルコンテンツのライセンスは、ときにeチケットと呼ばれる。ライセンスには、どのような利用規約が含まれ、プロバイダとユーザとの間で合意されたかに関わる情報が含まれることもある。このライセンス情報は、通常特定のDRMとともに機能するように設計され、特定のDRMとコンパチブルなシステムでのコンテンツの利用、あるいはライセンスに含まれる利用規約が取り除かれて履行できなくなることを効果的に制限する。
【発明の開示】
【発明が解決しようとする課題】
【0003】
以下の実施形態とそれらの目的は、代表例、例示を意図したシステム、ツール、方法と組み合わせて記述され説明されるもので、範囲を限定するものではない。様々な実施形態において、上述の問題は軽減されあるいは除去されるが、他の実施形態は別の改良に向けられている。
【0004】
DRMトランスレーションの技術は、第1デジタルコンテンツを第2デジタルコンテンツに変換する。この技術に従ったシステムの例は、第1デジタルフォーマットでコード化された第1デジタル・コンテンツ・ユニットと第1デジタル著作権管理(DRM)により保護された使用権を提供するサーバを備える。更にシステムは、第1デジタル・コンテンツ・ユニットを第2デジタルフォーマットでコード化され第2DRMにより使用権が保護された第2デジタル・コンテンツ・ユニットへと変換可能なトランスレータを備える。
【0005】
トランスレータは、コンテンツデータを別のフォーマットへと変換するように構成されていてもよい。またトランスレータは、不必要な転送を防止できるように、コンテンツデータをローカルにキャッシュしてもよい。
【0006】
DRMトランスレータは、ライセンス情報を変換し、必要とあれば、ペイロードを現在コンパチブルなものから別のDRMでの使用に合わせてフォーマットする。それはまた、コンテンツが正規なものであることの信頼性を向上するためのデジタル認証シグネチャをベリファイするように構成されてもよい。トランスレータは、ペイロードがそれらのレジティマシに従ってユーザによって簡単にベリファイできるようにデジタル・サイン・ペイロードとして構成されていてもよい。
【0007】
本発明の実施形態は、図面に示される。しかし、実施形態と図面は、限定的なものではなく例示的なもので、それらは本発明を例示的に提示する。
【発明を実施するための最良の形態】
【0008】
以下の説明では、本発明の実施形態の十分な理解を与えるために幾つかの特定の具体的な構成が提示される。しかし、当業者であれば、1つ以上のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組み合わせにより、本発明を実施することが可能であることが理解されるであろう。また別の例では、様々な実施形態における本発明の側面を覆い隠すことがないように、周知の具体的構成は、図示または詳細に説明されていない。
【0009】
図1Aは、DRMトランスレーション内のデータフローの一例を概念的に示す。システム100は、サーバ102からトランスレータ104、ユーザ106への情報の可能な流れを示す。図1Aは、データがDRMトランスレーションをどのように流れるかを示す一例である。他の例については図2〜5を参照して後述される。
【0010】
図1Aの例では、サーバ102は図においてa(x)として表されるペイロードを提供し、ここで“a”は第1のDRMとコンパチブルなライセンスデータを表し、“x”はコンテンツデータを表す。ペイロードについては、図10を参照して後述され、ある実施形態では、ライセンスデータおよびコンテンツデータ以外のものも含まれる。ライセンスデータは、例えばメディアに関する情報やメディアと関連付けられたユーセッジパラメータ(例えば、アクセス権)を含む。別の実施形態では、例えば正規のライセンスの存在のみでDRM内のコンテンツデータの使用権を示し、ユーセッジのパラメータを含むライセンスデータの必要性は除去される。ライセンスデータは、個々のDRMや多数のDRMとコンパチブルであってもよい。1つの実施形態では、ライセンスデータは特定のDRMでの利用のためにフォーマットされていてもよい。別の実施形態では、ライセンスは多数のDRMとコンパチブルとなるようにフォーマットされているかもしれない。ライセンスデータは、セキュリティのために、周知のあるいは手頃な方法で暗号化されていてもよい。
【0011】
コンテンツデータは、周知のあるいは手頃なフォーマットで提供されてもよく、例えば周知のあるいは手頃な種類の情報である。コンテンツデータの幾つかの例は、ビデオゲーム、ムービー、音楽などである。音楽フォーマットの幾つかの例は、MP3、AAC、WMA、OGGなどである。コンテンツデータの一部あるいは全ては、セキュリティのために暗号化されていてもよく、ライセンスデータには、暗号化されたコンテンツデータを解読可能とする暗号化キーが含まれていてもよい。暗号化は周知のあるいは手頃などのような方法で行われてもよい。トランスレータは、例えば、暗号化キーを用いて暗号化されたデータを新しいフォーマットに変換するように構成することも可能である。
【0012】
図1Aの例では、トランスレータ104は、ライセンス情報“a”をライセンス情報“b”に変換する。ここで、“b”は“a”に相当するが別のDRMにコンパチブルなライセンスデータである。ペイロードは、ライセンスデータ内の使用権を今まで通り維持しつつ別のDRMでの利用においてコンパチブルとされる。この例では、ライセンスデータ“a”はライセンスデータ“b”で置き換えられるが、置き換えは必須ではない。例えば、“b”は、これまで通りライセンス“a”を含んでいてもよいが、オリジナルに追加される第2のあるいは任意の数の付加的なライセンスを含んでいてもよい。必要であれば、多数のDRMシステムとコンパチブルな多数のライセンスが含まれてもよい。
【0013】
トランスレーションの前後でライセンスに関連付けられた利用制限は、常に同じとは限らず、互いに殆どあるいは全く関係がなくともよい。例えば、第1のDRMでの販売のために当初エンコードされた歌を含むデジタルコンテンツが、第2のDRMでサブスクリプションモデルに変換されてもよい。したがって、第1のDRMは、ビジネスロジックの定義に従って第2のDRMに置き換えられ得る。
【0014】
異なるDRMへのユーセッジパラメータの変換は、常に「ロスレス」トランスファであるとは限らず、これは変換元、変換先の個々のDRMに依存することを意味し、必ずしも契約規定の全てをトランスファできない可能性がある。このような場合、トランスレータは使用権の「ロッシー」トランスファを行うように構成されてもよい。ロッシートランスファの一例は、1つのDRMにおけるコンテンツデータが40時間の利用であり、別のDRMの時間制限が日数としてのみ認識される場合、個々の具体的な実施に即して制限は、時間制限を切り上げて2日にするか、あるいは切り捨てて1日するように構成されてもよい。
【0015】
図1Aの例において、ユーザ106は、1つのDRMシステムにおいてコンテンツデータを利用できる任意のエンティティ(実在物)である。ユーザとして可能なのは例えば、ポータブルミュージックプレイヤ、ムービープレイヤ、ゲームプレイヤであり、このときコンテンツデータは、それぞれ音楽、ムービー、ビデオゲームなどである。情報のトランスファは、周知のあるいは手頃な方法によるものであってもよく、いつかの例は、LAN、インターネットダウンロード、店舗内のキオスクなどからの転送を通して利用できるコンポーネントである。
【0016】
図1Aは、ユーザ106、トランスレータ104、サーバ102を独立したコンポーネントとして示すが、これは例示を目的としたものである。各々は論理上あるいは物理的に同じデバイスに設けられていてもよい。例えば、サーバ102、トランスレータ104、ユーザ106は、全て1台のデバイスに搭載されたコンポーネントであってもよく、また何れかの組み合わせが1台のデバイスに搭載されていてもよい。
【0017】
デジタルコンテンツが購入されるホストと、コンテンツ使用権の所有者が再生に利用しようと望むプレーヤとの違いから通常適用の必要性が生じる。例えば、ユーザは、ソースであるデジタルコンテンツC.a(x)をウェブサイトXから購入する。デジタルコンテンツCは、デジタルフォーマット.aでコード化され、使用権はDRMxにより保護される(同時に支配される)。例えばDRMyおよびデジタルフォーマット.bを採用するプレーヤ(ソフトウェアあるいはハードウェア)を用いてCを再生する場合など、権利をCに対して行使するには、コンテンツCがプレーヤで再生され得る前に、C.a(x)はターゲットであるC.b(y)にトランスレートされるためにDRMトランスレータを通る必要がある。なお.aは.bと同じであってもよい。
【0018】
DRMトランスレータは、上述された「eチケットトランスレーション」を可能にするプログラムである。2つのDRMの間が完全にコンパチブルではないという潜在的な可能性から、このトランスレーションは、トランスレータが最大の努力を行った後であっても数学的にロスレスではないかもしれない。DRMトランスレータは、DRMが行うべく、悪意ある攻撃と動作環境においける改変から保護されている必要がある。
【0019】
図1Bは、コンテンツデータ“X1”がコンテンツデータ“X2”へと変換される点を除いて図1Aと同様である。この例では、ライセンスデータが図1Aを参照して説明されたように変換されることに加え、コンテンツデータがユーザ106とコンパチブルな別のフォーマットへと変換される。この一例は、MP3でのオーディオファイルのAACフォーマットへの変換である。図1Aを参照して説明で示されたように、暗号化されたコンテンツデータは、ライセンスが暗号化キーを含む場合に利用できる。ある種の実施形態では、トランスレータは暗号化されたコンテンツを別の暗号化されたフォーマットに変換することができ、ライセンスデータに新しいキーを含ませることができる。
【0020】
コンテンツデータの別のフォーマットへの変換は、ユーザ106にとって必要であれば自動的に開始でき、あるいはマニュアル入力で開始できる。コンテンツデータの自動変換の一例は、サーバ102にとってコンパチブルなフォーマットを検出し、それに従ってデータを変換するようにトランスレータに要求を発信する。ある種の実施形態では、例えば2者の間のコミュニケーションで要求されるバンド幅を低減する目的で、変換されたコンテンツデータがトランスレータ104において既にキャッシュされていてもよい。更なる例では、コンテンツデータは、ユーザ106とコンパチブルなフォーマットに変換された後でトランスレータ104に対してローカルに自動的にキャッシュされてもよく、それによりサーバ102とトランスレータ104の間における後続するコンテンツデータの転送におけるコンテンツデータの転送の必要性を除去する。ある種の実施形態では、キャッシュされたコンテンツデータがローカルに保存される時間の長さをマニュアルで設定でき、あるいは例えばトランスレータ104に含まれるロジックにより自動的に計算することができる。
【0021】
またトランスレータ104は、ペイロードを1つのファイルから多数のファイルへ、または多数のペイロードを1組のペイロードあるいは複数のペイロードの複数のファイルを複数のペイロードへ変換するように構成することもできる。変換は特定の種類のファイルに対して自動的に行われるように設定することも、マニュアルで行うように設定することもできる。1つのファイルを多数のペイロードに変換する一例は、ダウンロードにおいてムービーが1つのデータユニットとすることができないほど大きい場合である。トランスレータ104は、ムービーの各部に対応するペイロードを含んだ多数のパケットとして送信できるように、ムービーを多数のブロックに分解するかもしれない。
【0022】
図2は、DRMシステム200におけるデータフローの一例を示す。システム200は、サーバ202、トランスレータ204、ユーザ206を備える。図2の例では、トランスレータ204は独立したコンポーネントとして示されるが、サーバ202の一部としてロジック上あるいは物理的に含まれていてもよい。この例では、トランスレータ204は、ライセンスデータが現在コンパチブルであるものとは別のDRMとコンパチブルとなるようにライセンスデータを変換する。コンテンツデータは、必要であれば別のフォーマットに変換することもできる。ある種の実施形態では、トランスレータ204は、コンテンツ・データ・ファイルをキャッシュして、サーバ202からトランスレータ204へ転送される必要がないようにする。加えて、トランスレータ204は、後続する転送の必要がないようにコンテンツデータが最初に受信されたときにコンテンツデータを変換し、その後変換されたコンテンツデータをキャッシュしてもよい。
【0023】
図2の例では、例示的に4つのトランザクションが、ユーザ206へのあるいはからの矢印として描かれる。図3の例では、トランスファは個別・単独の転送として示されるが、ある種の実施形態では、マルチプルトランスファ、オーバーラッピングトランスファ、マルチ・ディレクショナル・トランスファであるかもしれない。トランスファ1は、ユーザ206からサーバ202への転送である。トランスファ2は、サーバ202からユーザ206への転送である。トランスファ3は、ユーザ206からトランスレータ204への転送である。トランスファ4は、トランスレータ204からユーザ206への転送である。トランスファは、異なるオーダーで発生するかもしれず、複数のサブトランスファに分解されるもしれず、あるいは異なるトランスファのタイミングがオーバーラップするかもしれない。
【0024】
図2の例では、トランスファ1は、例えばユーザ206がコンテンツデータを利用するためのリクエストを送信したものであるかもしれない。リクエストには、ユーザ206がどのような利用規約を求めているかが含まれていてもよく、あるいは利用規約はリクエストのコンテキストから自動的に予測されてもよい。利用規約が、トランスファから如何に予測されるかは、例えば、ユーザ206のアイデンティティ、過去の購買行動、あるいは他のオプションが示されていない場合にはデフォルトのオプションである。別の例では、トランスファ1は、全般的なコンテンツリクエストで、必要となる付加的な情報を集めるために追加の複数のトランスファが利用されるかもしれない。
【0025】
図2の例では、トランスファ2は、例えばユーザ206に送信されるライセンスとコンテンツデータであるかもしれない。図1Aおよび図1Bを参照して説明されたように、ライセンスデータは、例えば周知あるいは手頃なDRMとコンパチブルであって、コンテンツデータは、例えば周知あるいは手頃なフォーマットに従っている。例示的な実施形態では、コンテンツデータは、暗号化フォーマットで提供される。別の例示的な実施形態では、コンテンツデータとライセンスデータは両者ともに暗号化されている。ペイロードに暗号化データが含まれる場合、ライセンスデータは、利用されるコンテンツデータを復号するのに使用される暗号化コンテンツデータのキーを含んでいてもよい。
【0026】
図2の例では、トランスファ3は、例えばユーザ206によるペイロードの変換リクエストであるかもしれない。ある種の実施形態では、このトランスファは連続したサブトランスファに分解されるかもしれず、部分的な情報がトランスレータ204に送信される。トランスファは、もし必要なものがそれだけであるのであれば、ライセンスデータのみを含むものであってもよく、あるいはトランスファは、ライセンスデータとコンテンツデータを含んでいてもよい。また、例えば変換処理を開始するのにデータの全てが必要とされない場合には、トランスファ3はトランスファ2とオーバーラップしていてもよい。トランスファ4には、例えば変換されたペイロードのユーザ206への転送が含まれる。
【0027】
ある実施形態では、トランスレータは、ユーザによるペイロードの獲得に当たり、自動的に実行されるように構成されている。ある種の実施形態では、ペイロードの獲得においてサーバに送られるデータが、どのDRMに対してペイロードをコンパチブルとするかを決定するのに利用される。ある種の実施形態では、トランスレータは、コンテンツデータの利用を意図したユーザによって自動的に実行される;ユーザはトランスレータを例えば、どのDRMをどれに対し、ペイロードをコンパチブルとし、かつ/またはコンテンツデータを別のフォーマットに変換するかを決定することによりトランスレータをコントロールする。ある種の実施形態では、トランスレータは、1つのペイロードを複数のペイロードに、複数のペイロードを1つのペイロードに、あるいは第1の複数のペイロードを第2の複数のペイロードにすることができるように構成される。
【0028】
図3は、DRMシステム300内でのデータフローの一例を示す。図3はサーバ302からトランスレータ304へと送信されるデータを示す。またユーザ306は、例えば、彼らがどのDRMを使用しているか、あるいは更に、例えば、彼らがどのフォーマットのコンテンツデータを好むかを規定する。ある種の実施形態では、この情報はトランスファのコンテキストから自動的に推測される。
【0029】
図3の例では、ユーザ306は、コンテンツデータのリクエストをサーバ302へと送信できる。これに応答して(あるいは代わりにある任意のまたは所定の時点で)、サーバ302は、ペイロードを第1フォーマットからユーザ306のDRMとコンパチブルな第2フォーマットへと変換するようにトランスレータ304にリクエストを送信してもよい。トランスレータ304は、変換された情報をサーバ302へと返すことができ、サーバ302はユーザ306へ変換された情報を転送する。
【0030】
図4は、DRMシステム400内のデータフローの一例を示す。トランスファは、図1を参照して上で説明されたものと同様に行われる。図4の例では、ユーザ406は、サーバ402へコンテンツデータのリクエストを送信する。説明の便宜上、コンテンツデータを含むペイロードはユーザ406がリクエストしたDRM内にはなく、情報はトランスレータ404へと転送される。トランスレータ404は、ペイロードをリクエストされた方法で変換し、変換された情報をユーザ406へと送信する。
【0031】
図5は、DRMシステム500内でのデータフローの一例を示す。トランスファは、図1を参照して上で説明されたものと同様に行われる。図5の例では、別のDRMを用いているユーザ506−1とユーザ506−2(以後集合的にはユーザ506として参照する)が存在する。ユーザ506−1はコンテンツデータをリクエストし、コンテンツデータを含むペイロードを受信する。ユーザ506−1は、ペイロードをユーザ506−2へと送信する。ここでユーザ506−2は、説明の便宜上、例えばユーザ506−1と同じDRMを実行していないことからコンテンツデータを利用できない。ユーザ506−2は、トランスレータ504へとペイロードを送信可能であり、ペイロードは、ユーザ506−2で実行されているDRMとコンパチブルにすることができ、コンパチブルなペイロードがユーザ506−2へと戻される。
【0032】
図6は、ライセンスデータをユーザのDRMとコンパチブルなフォーマットへと変換する方法のフローチャート600である。この方法や他の方法は、一連のブロックとディシジョンポイントによって示される。しかし、これらの方法におけるブロックとディシジョンポイントは、順番を変えたり、あるいは適切な並列処理にアレンジしたりすることもできる。
【0033】
図6の例では、フローチャート600は、ユーザがリクエストを送信するブロック602からスタートする。リクエストには、例えば、ペイロードを第1DRMとコンパチブルなフォーマットから第2DRMとコンパチブルなフォーマットへと変換するリクエストが含まれるかもしれない。例えば、リクエストには、コンテンツデータを別のフォーマットへ変換する要求が含まれるかもしれない。リクエストは、ライセンスデータと、可能でもし適切であればコンテンツデータを含んでもよく、あるいは代替的に、ライセンスデータかつ/またはコンテンツデータは、リクエストされた変換を行えるかが判定された後で、トランスレータへと転送されてもよい。トランスレータは、例えば、ライセンスデータをDRMの多様な組み合わせに対してコンパチブルとなるように構成されてもよい。
【0034】
図6の例では、フローチャート600は、コンテンツデータ、ライセンスデータ、あるいは他のペイロードが正しいフォーマットであるか否かを判定するディシジョンポイント604まで続く。既にペイロードが正しいフォーマットであれば(604−Y)、フローチャート600は終了する。別の実施形態では、フローチャート600は、リクエストと関連付けられたDRMが認知されず、あるいは不明の場合、変換は法律(例えば著作権法)に違反するかもしれず、あるいはライセンスは原型が損なわれたか、ある他の欠陥が存在するかもしれない。別の実施形態では、コンテンツデータは、異なる複数のフォーマットに変換されるかもしれない。これらの実施形態では、コンテンツの変換が可能であるか否かもまたチェックされる。
【0035】
図6の例では、ペイロードが正しいフォーマットでないと判定されると(604−N)、フローチャート600は、ペイロードが適正なDRMとコンパチブルとなるようにトランスレートされるブロック606へと続く。トランスレーションは、限定的では無く例示的に、新しいライセンスデータの取り替えのみを伴うかもしれない。しかし、DRMによっては、コンテンツデータを含むペイロードを部分的あるいは全面的に再フォーマットすることが好ましいかもしれない。ある種の実施形態では、コンテンツデータは更に別のフォーマットに変換される。
【0036】
図7は、トランスレータシステム700の一例を示す。図7の例において、システム700は、メモリ704、プロセッサ708、そして入力/出力コミュニケーションポート710を備える。図7の例では、メモリ704は、モジュール702とトランスレーションデータベース706を備える。プロセッサ708は、周知の、あるいはx86ベース、パワーPC、SPARC、ARMなどの手頃な種類のものであってもよい。メモリ704は、周知のあるいは手頃な種類あるいはフォーマットであってもよく、メインメモリ、キャッシュメモリ、2次記憶など如何なる形式のものを含み、あるいは周知のあるいは手頃な形式のメモリの組み合わせであってもよい。プロセッサ708とメモリ704は、プロセッサ708がメモリ内のプログラムモジュール702を実行することができ、またトランスレーションデータベース706にアクセスすることができるように連結されている。入力/出力コミュニケーションポートは、周知、手頃な如何なる形式のものであってもよい。コミュニケーションポートの幾つかの具体例は、ラジオ無線、USB接続、イーサーネット接続、ファイヤーワイヤなどである。
【0037】
図7の例では、作動中、プロセッサ708は図8を参照して後述されるようにモジュール702を実行する。実行時、モジュール702は、第1DRMとコンパチブルなペイロードを第2DRMとコンパチブルなペイロードへと変換することができる。この例では、モジュール702は、変換を行うのにトランスレーションデータベース706内の情報を利用する。入力/出力ポートは、リクエストを受信し、変換された部分を例えばユーザに送信する。別の実施形態では、メモリ704は、キャッシュされたコンテンツデータを持っているかもしれず、これはコンテンツデータが初めての変換された後にキャッシュされるか、あるいは外部エンティティ(装置)によって保存される。キャッシュされたコンテンツデータは、周知あるいは手頃な、限定的ではなく例示的に、データベースへの保存を含む任意の方法で保存される。
【0038】
図8は、トランスレーションシステム、限定的ではなく例示的に、システム700(図7)などのトランスレーションモジュール間における情報の流れの一例を模式的に示す。図8は、コンバージョンライブラリ802とモジュール810を含むシステム800を示す。モジュール810は、シグネチャ・チェッキング・モジュール812、ライセンス・パーシング・モジュール814、ライセンス・コンバージョン・モジュール816、ライセンス・フォーマティング・モジュール818、およびライセンス・サインナー・モジュール820を備える。この構成は単なる一例であり、モジュールが組み合わせられ、あるいは取り除かれ、あるいは追加された他の形態も可能である。
【0039】
図8の例では、作動中、シグネチャ・チェッキング・モジュール812は、ライセンスデータにおけるデジタルシグネチャの妥当性(バリディティ)を検証(ベリファイ)する。非限定的な実施形態では、ベリフィケーションはトランスレータに対してローカルに行われる。別の実施形態では、外部ソースがデジタルシグネチャの妥当性を保証するためにコンタクトされる。全てのペイロードがデジタルシグネチャを必ずしも含んでいる必要はない;これは、ペイロードがコンパチブルとなるDRMに依存するかもしれないし、しないかもしれない。デジタルシグネチャが不正な場合には、異なる複数のアクションが可能であり、一例としてはリクエストされた変換を拒否し、あるいは同じコンテンツデータをもつ正規にサインされたペイロードを提供できるサーバへのリンクを提供する。
【0040】
ある種の実施形態では、デジタル・シグネチャ・スキームは、パブリックキー暗号法を使用する。パブリックキー暗号法では、各ユーザは一対のキーを持つ:1つはパブリックで1つはプライベートである。パブリックキーは無償で配布されるが、プライベートキーは公表されずに秘密にされる。この技術は周知であり、ここで説明される技術とともに様々な周知のあるいは手頃な実施例を利用することが可能である。
【0041】
一例としてのデジタル・シグネチャ・スキームは3つのアルゴリズムからなる:キー生成アルゴリズム、署名アルゴリズム、そしてベリフィケーションアルゴリズム。
【0042】
ある種の実施形態では、デジタルシグネチャはパブリックキーを用いてベリファイされる。シグネチャがベリファイされると、署名アルゴリズムはシグネチャを偽造するのを難しいように設計されていることから、トランスレータは、メッセージがパブリックキーと関連付けられたサーバからのものであると十分に確信できる。
【0043】
図8の例では、ライセンス・パーサ・モジュール814は、ライセンスデータからユーセッジ情報を取り除く。非限定的な実施形態として、ライセンス・パーサ・モジュール814は、ユーセッジ情報のロケーションを特定するかもしれないコンバージョンライブラリ802内の情報を利用してどのようにライセンスを解読(パース)するか決定する。ライセンス情報を解読(パース)するためのコンバージョンライブラリ802の利用は、非限定的な実施形態によるものである;他の可能な実施形態ではライブラリは利用されない。ライブラリが利用されない実施形態では、ライセンス・パーサ・モジュール814は、例えばライブラリにコンタクトすることなくライセンス情報を解読(パース)するようにプログラムされている。
【0044】
図8の例では、ライセンス・コンバージョン・モジュール816は、ユーセッジパラメータを第2DRMによって利用できる形式にする。ユーセッジパラメータが変換された形式は、第2DRMと直ちにコンパチブルであってもなくともよい。パラメータの形式が第2DRMによって利用できる情報は、コンバージョンライブラリ802に含まれる。ライセンス・パーサ・モジュール814と同様に、ライブラリの利用は選択的であり、コンバータはライブラリを調べることなく変換するようにプログラムされていてもよい。ある実施形態では、第1DRMはコンテンツデータを1日利用されると規定するかもしれないが、第2DRMは時間単位の利用制限のみを期待するかもしれない。このような実施形態では、ライセンス・コンバージョン・モジュール816は、1日を24時間に変換するであろう。
【0045】
図8の例では、ライセンス・フォーマッティング・モジュール818は、変換されたユーセッジパラメータを、ライセンス・コンバージョン・モジュール814から提供された情報を用いて第2DRMとコンパチブルなライセンスを生成するためにフォーマットする。ライセンス・フォーマッティング・モジュール818は、どのように変換されたパラメータを第2DRMとコンパチブルな形式にフォーマットするかについての情報をコンバージョンライブラリ802から検索する。別の実施形態では、ライブラリは選択的であって、ライセンス・フォーマッティング・モジュール818は、変換されたパラメータをフォーマットするように既にプログラムされているかもしれない。ライセンス・フォーマッティング・モジュール818は、ペイロードをリクエストされたDRMとコンパチブルにするようにリクエストされた場合に、ライセンスを超えてペイロードの全てをフォーマットするように更に構成されていてもよいが、そうでなくともよい。
【0046】
図8の例では、ライセンス署名モジュール820は、限定的にではなく例示的に上述された方法、あるいは周知のそして手頃な代替的な任意の方法で、キー生成アルゴリズムを用いてペイロードにデジタルに署名する。非限定的な実施形態では、ライセンス署名モジュール820は、ライセンスデータに認証シグネチャを追加することができる。これは、限定的にではなく例示的に上述された方法、あるいは周知のそして手頃な代替的な任意の方法などのパブリック・キー・システムを用いて実現できる。全てのライセンスがデジタルに署名されている必要はなく、ある場合には、実施形態、構成、かつ/または、どのDRMへ、あるいは、どのDRMからライセンスが変換されるかに依存してもよい。
【0047】
図8の例では、コンバージョンライブラリ802は、特定のDRMとコンパチブルなライセンスをどのように解析するか、パラメータをどのように特定のDRMとコンパチブルな形式に変換するか、そして特定のDRMがどのライセンス形式を要求するかについての情報を備えていてもよい。コンバージョンライブラリ802は、随意的であり、トランスレータ800の作動に必要であるかもしれないし、必要でないかもしれない。ある実施形態では、新たな変換情報がDRMの変換のためのコンバージョンライブラリ806に追加されるかもしれず、あるいはライブラリに存在する情報がアップデートできる。例えば、特定のDRMの仕様が変わると、ライブラリはこれらの変更を考慮した新たな情報にアップデートできる。
【0048】
図9は、ペイロード変換のための方法の一例のフローチャート900を示す。フローチャート900は、ペイロードを変換するリクエストを受信するブロック902で開始する。このリクエストがどのような情報を含むかは、実施されている形態に依存し、限定的ではなく例示的に、ライセンス、全ペイロード、支払い情報などリクエストされたもののみを含むであろう。
【0049】
図9の例では、フローチャート900は、ディシジョンポイント904へと続き、ペイロードに関連付けられたシグネチャが正規のものであるか否かが判定される。周知のあるいは手頃などのようなデジタルシグネチャが使用されてもよい。ペイロードにデジタルシグネチャは必ずしも必要ではない。シグネチャがない場合には、ペイロードは、実施されている形態、かつ/またはトランザクションの状態に従って、受け入れられ、あるいは拒絶される。ペイロードと関連付けられたシグネチャが正規なものでないときには、フローチャート900は終了する。別の実施形態では、追加的なアクションとして、同じデジタルコンテンツを含む正規に署名されたペイロードが得られるロケーションにユーザを振り向けるユーザへのノーティフィケーションや、コンテンツオーナのノーティフィケーションを含んでいてもよい。それ以外の場合、フローチャート900はディシジョンポイント906へと続く。
【0050】
ディシジョンポイント906では、ライセンスがリクエストされた方法で変換できるか否かが判定される。例えば図6を参照して前述されたように、ペイロードを変換できない理由が存在する可能性がある。ペイロードが変換できないときには、フローチャート900は終了する。それ以外の場合には、フローチャート900はブロック908へと続く。
【0051】
ブロック908では、ライセンスデータがユーセッジのパラメータへと解析される。ユーセッジのパラメータは、ペイロードがコンパチブルであるDRMに依存する。ユーセッジのパラメータは、例えば、特定のコンテンツデータに対して適用される契約条項を記述しているかもしれない。ある種の実施形態では、ユーセッジのパラメータが存在せず、正規のライセンスの存在がコンテンツデータの使用権を示す。
【0052】
ブロック910では、ライセンスに含まれる暗号化キーを用いてコンテンツデータが復号される。これは、一例に過ぎず、周知のあるいは手頃な暗号化/復号化技術が用いられるであろう。
【0053】
ブロック912では、コンテンツデータがリクエストされたフォーマットに変換される。ある実施形態では、コンテンツデータが既に要求されるフォーマットであれば、データの変換は必要とされない。別の状況では、コンテンツデータは既に要求されたフォーマットでローカルにキャッシュされているかもしれず、変換を必要とせずにこのコピーが利用されるかもしれない。
【0054】
ブロック914では、ライセンスは別のDRMとコンパチブルな形式にトランスレートされる。DRM間のロスレスな変換は常に可能なわけではなく、ときには、ライセンスに含まれる情報が、コンパチブルなライセンスが新たなDRMで取らなければならないフォームから失われる。ある実施形態では、ライセンスデータのロスを低減してロッシートランスファの影響を低減するために近似やロジックが用いられる。ロッシートランスファの一例は、1つのDRMにおいてコンテンツデータが40時間利用されることとなっていて、コンテンツが利用されるDRMでは、コンテンツは日数に基づいてのみ時間制限を認識するとき、制限は時間制限を2日に切り上げ、あるいは1日に切り下げるように丸めるように構成されてもよい。多くに状況において、変換はロスレスであり、第1DRMに含まれる全ての情報は、第2DRMにおいても適用される。
【0055】
ブロック916では、ライセンスはリクエストされたDRMとともに利用できるようにフォーマットされる。ある実施形態では、例えば、ライセンスデータが既にDRMとコンパチブルであれば、フォーマットは必要ない。別の実施形態では、フォーマットはライセンスデータ以外にも要求され、全てのペイロードがリクエストされたDRMとコンパチブルになるようにフォーマットされる必要があるかもしれない。
【0056】
ブロック918では、ペイロードは認証シグネチャを用いてデジタルに署名される。デジタル認証シグネチャの例は、図8を参照して、限定的にではなく例示的に説明される。
【0057】
図10Aおよび図10Bは、ペイロード1000とパケット1050の一例を図式的に表す。可能な実施形態では、ペイロードは分割され、図10Bの例にパケット1050として示されるパケットとして転送される。このような実施形態では、幾つかの、あるいは全てのパケットが送信先で受領されると、ペイロードと関連付けられた各パケットを用いてファイルを生成するようにパケットが結合される。このような実施形態では、パケットは、パケットをルーティングするためのヘッダ情報、およびそれらが結合される方法を特定するためのヘッダ情報を一般に含む。
【0058】
図10Aの例では、ペイロード1000はライセンスデータ1002とコンテンツデータ1004を含む。コンテンツデータ1004は、図1Aを参照して限定的ではなく例示的に説明されたように、暗号化され、あるいは暗号化されず、または部分的に暗号化されていてもよい。コンテンツデータ1004は、例えば使用権に従う任意のメディアであり、音楽、ビデオゲーム、ムービー、電子図書などが含まれる。またコンテンツは、図1Aを参照して限定的ではなく例示的に説明されたように、周知あるいは手頃などのようなフォーマットであってもよい。
【0059】
図10Aの例では、ライセンスデータ1002は、ユーセッジルール1008、コンテンツデータ1010のための暗号化キー、そして電子シグネチャ1012を含む。これは単に一例であり、ライセンスは、図10Aの例に示されたものよりも多い、あるいは少ない、または異なる情報の組み合わせを含んでいてもよい。ユーセッジルール1008は、例えばコンパチブルなDRMの下におけるコンテンツデータ1004の利用のためのルールである。ユーセッジルール1008は、このDRMによって規定されるかもしれないが、されないかもしれない。実施形態および/または実施例によっては、特定のライセンス内にユーセッジルールが全くないかもしれない。例えば、正規のライセンスの存在は、コンテンツデータの許可された使用法(ユーセッジ)を示すのに適切であり得る。代替的に、コンテンツデータ1004がどのように、何処で、何時使用できるかについての具体的な情報がライセンスデータ1002に記録されてもよい。
【0060】
図10Aの例では、暗号化キー1010は、暗号化されたコンテンツデータを復号化するためのキーであるかもしれない。1つの暗号化キーのみが示されるが、他の実施形態では、コンテンツデータのため多数のキーがあってもなくともよい。更にある実施形態では、暗号化キー自身が、ある種の方法で暗号化されており、使用される前に暗号化されていない状態にする必要があるかもしれない。
【0061】
図10Aの例では、シグネチャ1012は、コンテンツデータ1004が正規なものであることを示すためにペイロード1000の製作者によって残されたデータを含む。データはコピーするのが難しく、指定されたソースからのデータで、例えば偽造されたものでないこと証明することを意図したものである。シグネチャ1012は、ライセンスデータ1002内に含まれた状態で示されるが、これは一例に過ぎず、それはペイロード1000の何処に含まれていてもよく、あるいは希な実施の形態では、パケット1050のヘッダ内であってすらよい。デジタルシグネチャを生成するには、様々な適用可能な方法があり、その中の1つは限定的ではなく例示的に上記図8を参照して説明された。
【0062】
ここで使用される、用語「実施形態」は、限定的ではなく例示的な説明を行うための実施形態を意味する。
【0063】
当業者であれば前述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定するものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の要旨と範囲に含まれることを意図している。したがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこのような全ての変更、置き換え、均等物を含むことを意図している。
【図面の簡単な説明】
【0064】
【図1A】DRMトランスレーション内のデータフローの一例を概念的に示す。
【図1B】DRMトランスレーション内のデータフローの一例を概念的に示す。
【図2】DRMシステム内のデータフローの一例を示す。
【図3】DRMシステム内のデータフローの一例を示す。
【図4】DRMシステム内のデータフローの一例を示す。
【図5】DRMシステム内のデータフローの一例を示す。
【図6】ライセンスデータをユーザのDRMとコンパチブルなフォーマットに変換するための方法のフローチャートを示す。
【図7】トランスレータシステムの一例を示す。
【図8】トランスレータシステムにおけるトランスレーションモジュール間の情報の流れの一例を図式的に示す。
【図9】ペイロードトランスレーションのための方法の一例のフローチャートを示す。
【図10A】ペイロードの一例の図式的な代表図である。
【図10B】
【背景技術】
【0001】
デジタル著作権管理(DRM)は、デジタルコンテンツの消費者とデジタルコンテンツのプロバイダとの間での利用契約の支援を目的とした技術分野である。これらの契約を支援するために様々な異なる手段が用いられている。
【0002】
デジタルコンテンツの利用のために契約が締結されると、デジタルコンテンツとともに使用許諾契約書(ライセンスアグリーメント)がパッケージされる。デジタルコンテンツのライセンスは、ときにeチケットと呼ばれる。ライセンスには、どのような利用規約が含まれ、プロバイダとユーザとの間で合意されたかに関わる情報が含まれることもある。このライセンス情報は、通常特定のDRMとともに機能するように設計され、特定のDRMとコンパチブルなシステムでのコンテンツの利用、あるいはライセンスに含まれる利用規約が取り除かれて履行できなくなることを効果的に制限する。
【発明の開示】
【発明が解決しようとする課題】
【0003】
以下の実施形態とそれらの目的は、代表例、例示を意図したシステム、ツール、方法と組み合わせて記述され説明されるもので、範囲を限定するものではない。様々な実施形態において、上述の問題は軽減されあるいは除去されるが、他の実施形態は別の改良に向けられている。
【0004】
DRMトランスレーションの技術は、第1デジタルコンテンツを第2デジタルコンテンツに変換する。この技術に従ったシステムの例は、第1デジタルフォーマットでコード化された第1デジタル・コンテンツ・ユニットと第1デジタル著作権管理(DRM)により保護された使用権を提供するサーバを備える。更にシステムは、第1デジタル・コンテンツ・ユニットを第2デジタルフォーマットでコード化され第2DRMにより使用権が保護された第2デジタル・コンテンツ・ユニットへと変換可能なトランスレータを備える。
【0005】
トランスレータは、コンテンツデータを別のフォーマットへと変換するように構成されていてもよい。またトランスレータは、不必要な転送を防止できるように、コンテンツデータをローカルにキャッシュしてもよい。
【0006】
DRMトランスレータは、ライセンス情報を変換し、必要とあれば、ペイロードを現在コンパチブルなものから別のDRMでの使用に合わせてフォーマットする。それはまた、コンテンツが正規なものであることの信頼性を向上するためのデジタル認証シグネチャをベリファイするように構成されてもよい。トランスレータは、ペイロードがそれらのレジティマシに従ってユーザによって簡単にベリファイできるようにデジタル・サイン・ペイロードとして構成されていてもよい。
【0007】
本発明の実施形態は、図面に示される。しかし、実施形態と図面は、限定的なものではなく例示的なもので、それらは本発明を例示的に提示する。
【発明を実施するための最良の形態】
【0008】
以下の説明では、本発明の実施形態の十分な理解を与えるために幾つかの特定の具体的な構成が提示される。しかし、当業者であれば、1つ以上のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組み合わせにより、本発明を実施することが可能であることが理解されるであろう。また別の例では、様々な実施形態における本発明の側面を覆い隠すことがないように、周知の具体的構成は、図示または詳細に説明されていない。
【0009】
図1Aは、DRMトランスレーション内のデータフローの一例を概念的に示す。システム100は、サーバ102からトランスレータ104、ユーザ106への情報の可能な流れを示す。図1Aは、データがDRMトランスレーションをどのように流れるかを示す一例である。他の例については図2〜5を参照して後述される。
【0010】
図1Aの例では、サーバ102は図においてa(x)として表されるペイロードを提供し、ここで“a”は第1のDRMとコンパチブルなライセンスデータを表し、“x”はコンテンツデータを表す。ペイロードについては、図10を参照して後述され、ある実施形態では、ライセンスデータおよびコンテンツデータ以外のものも含まれる。ライセンスデータは、例えばメディアに関する情報やメディアと関連付けられたユーセッジパラメータ(例えば、アクセス権)を含む。別の実施形態では、例えば正規のライセンスの存在のみでDRM内のコンテンツデータの使用権を示し、ユーセッジのパラメータを含むライセンスデータの必要性は除去される。ライセンスデータは、個々のDRMや多数のDRMとコンパチブルであってもよい。1つの実施形態では、ライセンスデータは特定のDRMでの利用のためにフォーマットされていてもよい。別の実施形態では、ライセンスは多数のDRMとコンパチブルとなるようにフォーマットされているかもしれない。ライセンスデータは、セキュリティのために、周知のあるいは手頃な方法で暗号化されていてもよい。
【0011】
コンテンツデータは、周知のあるいは手頃なフォーマットで提供されてもよく、例えば周知のあるいは手頃な種類の情報である。コンテンツデータの幾つかの例は、ビデオゲーム、ムービー、音楽などである。音楽フォーマットの幾つかの例は、MP3、AAC、WMA、OGGなどである。コンテンツデータの一部あるいは全ては、セキュリティのために暗号化されていてもよく、ライセンスデータには、暗号化されたコンテンツデータを解読可能とする暗号化キーが含まれていてもよい。暗号化は周知のあるいは手頃などのような方法で行われてもよい。トランスレータは、例えば、暗号化キーを用いて暗号化されたデータを新しいフォーマットに変換するように構成することも可能である。
【0012】
図1Aの例では、トランスレータ104は、ライセンス情報“a”をライセンス情報“b”に変換する。ここで、“b”は“a”に相当するが別のDRMにコンパチブルなライセンスデータである。ペイロードは、ライセンスデータ内の使用権を今まで通り維持しつつ別のDRMでの利用においてコンパチブルとされる。この例では、ライセンスデータ“a”はライセンスデータ“b”で置き換えられるが、置き換えは必須ではない。例えば、“b”は、これまで通りライセンス“a”を含んでいてもよいが、オリジナルに追加される第2のあるいは任意の数の付加的なライセンスを含んでいてもよい。必要であれば、多数のDRMシステムとコンパチブルな多数のライセンスが含まれてもよい。
【0013】
トランスレーションの前後でライセンスに関連付けられた利用制限は、常に同じとは限らず、互いに殆どあるいは全く関係がなくともよい。例えば、第1のDRMでの販売のために当初エンコードされた歌を含むデジタルコンテンツが、第2のDRMでサブスクリプションモデルに変換されてもよい。したがって、第1のDRMは、ビジネスロジックの定義に従って第2のDRMに置き換えられ得る。
【0014】
異なるDRMへのユーセッジパラメータの変換は、常に「ロスレス」トランスファであるとは限らず、これは変換元、変換先の個々のDRMに依存することを意味し、必ずしも契約規定の全てをトランスファできない可能性がある。このような場合、トランスレータは使用権の「ロッシー」トランスファを行うように構成されてもよい。ロッシートランスファの一例は、1つのDRMにおけるコンテンツデータが40時間の利用であり、別のDRMの時間制限が日数としてのみ認識される場合、個々の具体的な実施に即して制限は、時間制限を切り上げて2日にするか、あるいは切り捨てて1日するように構成されてもよい。
【0015】
図1Aの例において、ユーザ106は、1つのDRMシステムにおいてコンテンツデータを利用できる任意のエンティティ(実在物)である。ユーザとして可能なのは例えば、ポータブルミュージックプレイヤ、ムービープレイヤ、ゲームプレイヤであり、このときコンテンツデータは、それぞれ音楽、ムービー、ビデオゲームなどである。情報のトランスファは、周知のあるいは手頃な方法によるものであってもよく、いつかの例は、LAN、インターネットダウンロード、店舗内のキオスクなどからの転送を通して利用できるコンポーネントである。
【0016】
図1Aは、ユーザ106、トランスレータ104、サーバ102を独立したコンポーネントとして示すが、これは例示を目的としたものである。各々は論理上あるいは物理的に同じデバイスに設けられていてもよい。例えば、サーバ102、トランスレータ104、ユーザ106は、全て1台のデバイスに搭載されたコンポーネントであってもよく、また何れかの組み合わせが1台のデバイスに搭載されていてもよい。
【0017】
デジタルコンテンツが購入されるホストと、コンテンツ使用権の所有者が再生に利用しようと望むプレーヤとの違いから通常適用の必要性が生じる。例えば、ユーザは、ソースであるデジタルコンテンツC.a(x)をウェブサイトXから購入する。デジタルコンテンツCは、デジタルフォーマット.aでコード化され、使用権はDRMxにより保護される(同時に支配される)。例えばDRMyおよびデジタルフォーマット.bを採用するプレーヤ(ソフトウェアあるいはハードウェア)を用いてCを再生する場合など、権利をCに対して行使するには、コンテンツCがプレーヤで再生され得る前に、C.a(x)はターゲットであるC.b(y)にトランスレートされるためにDRMトランスレータを通る必要がある。なお.aは.bと同じであってもよい。
【0018】
DRMトランスレータは、上述された「eチケットトランスレーション」を可能にするプログラムである。2つのDRMの間が完全にコンパチブルではないという潜在的な可能性から、このトランスレーションは、トランスレータが最大の努力を行った後であっても数学的にロスレスではないかもしれない。DRMトランスレータは、DRMが行うべく、悪意ある攻撃と動作環境においける改変から保護されている必要がある。
【0019】
図1Bは、コンテンツデータ“X1”がコンテンツデータ“X2”へと変換される点を除いて図1Aと同様である。この例では、ライセンスデータが図1Aを参照して説明されたように変換されることに加え、コンテンツデータがユーザ106とコンパチブルな別のフォーマットへと変換される。この一例は、MP3でのオーディオファイルのAACフォーマットへの変換である。図1Aを参照して説明で示されたように、暗号化されたコンテンツデータは、ライセンスが暗号化キーを含む場合に利用できる。ある種の実施形態では、トランスレータは暗号化されたコンテンツを別の暗号化されたフォーマットに変換することができ、ライセンスデータに新しいキーを含ませることができる。
【0020】
コンテンツデータの別のフォーマットへの変換は、ユーザ106にとって必要であれば自動的に開始でき、あるいはマニュアル入力で開始できる。コンテンツデータの自動変換の一例は、サーバ102にとってコンパチブルなフォーマットを検出し、それに従ってデータを変換するようにトランスレータに要求を発信する。ある種の実施形態では、例えば2者の間のコミュニケーションで要求されるバンド幅を低減する目的で、変換されたコンテンツデータがトランスレータ104において既にキャッシュされていてもよい。更なる例では、コンテンツデータは、ユーザ106とコンパチブルなフォーマットに変換された後でトランスレータ104に対してローカルに自動的にキャッシュされてもよく、それによりサーバ102とトランスレータ104の間における後続するコンテンツデータの転送におけるコンテンツデータの転送の必要性を除去する。ある種の実施形態では、キャッシュされたコンテンツデータがローカルに保存される時間の長さをマニュアルで設定でき、あるいは例えばトランスレータ104に含まれるロジックにより自動的に計算することができる。
【0021】
またトランスレータ104は、ペイロードを1つのファイルから多数のファイルへ、または多数のペイロードを1組のペイロードあるいは複数のペイロードの複数のファイルを複数のペイロードへ変換するように構成することもできる。変換は特定の種類のファイルに対して自動的に行われるように設定することも、マニュアルで行うように設定することもできる。1つのファイルを多数のペイロードに変換する一例は、ダウンロードにおいてムービーが1つのデータユニットとすることができないほど大きい場合である。トランスレータ104は、ムービーの各部に対応するペイロードを含んだ多数のパケットとして送信できるように、ムービーを多数のブロックに分解するかもしれない。
【0022】
図2は、DRMシステム200におけるデータフローの一例を示す。システム200は、サーバ202、トランスレータ204、ユーザ206を備える。図2の例では、トランスレータ204は独立したコンポーネントとして示されるが、サーバ202の一部としてロジック上あるいは物理的に含まれていてもよい。この例では、トランスレータ204は、ライセンスデータが現在コンパチブルであるものとは別のDRMとコンパチブルとなるようにライセンスデータを変換する。コンテンツデータは、必要であれば別のフォーマットに変換することもできる。ある種の実施形態では、トランスレータ204は、コンテンツ・データ・ファイルをキャッシュして、サーバ202からトランスレータ204へ転送される必要がないようにする。加えて、トランスレータ204は、後続する転送の必要がないようにコンテンツデータが最初に受信されたときにコンテンツデータを変換し、その後変換されたコンテンツデータをキャッシュしてもよい。
【0023】
図2の例では、例示的に4つのトランザクションが、ユーザ206へのあるいはからの矢印として描かれる。図3の例では、トランスファは個別・単独の転送として示されるが、ある種の実施形態では、マルチプルトランスファ、オーバーラッピングトランスファ、マルチ・ディレクショナル・トランスファであるかもしれない。トランスファ1は、ユーザ206からサーバ202への転送である。トランスファ2は、サーバ202からユーザ206への転送である。トランスファ3は、ユーザ206からトランスレータ204への転送である。トランスファ4は、トランスレータ204からユーザ206への転送である。トランスファは、異なるオーダーで発生するかもしれず、複数のサブトランスファに分解されるもしれず、あるいは異なるトランスファのタイミングがオーバーラップするかもしれない。
【0024】
図2の例では、トランスファ1は、例えばユーザ206がコンテンツデータを利用するためのリクエストを送信したものであるかもしれない。リクエストには、ユーザ206がどのような利用規約を求めているかが含まれていてもよく、あるいは利用規約はリクエストのコンテキストから自動的に予測されてもよい。利用規約が、トランスファから如何に予測されるかは、例えば、ユーザ206のアイデンティティ、過去の購買行動、あるいは他のオプションが示されていない場合にはデフォルトのオプションである。別の例では、トランスファ1は、全般的なコンテンツリクエストで、必要となる付加的な情報を集めるために追加の複数のトランスファが利用されるかもしれない。
【0025】
図2の例では、トランスファ2は、例えばユーザ206に送信されるライセンスとコンテンツデータであるかもしれない。図1Aおよび図1Bを参照して説明されたように、ライセンスデータは、例えば周知あるいは手頃なDRMとコンパチブルであって、コンテンツデータは、例えば周知あるいは手頃なフォーマットに従っている。例示的な実施形態では、コンテンツデータは、暗号化フォーマットで提供される。別の例示的な実施形態では、コンテンツデータとライセンスデータは両者ともに暗号化されている。ペイロードに暗号化データが含まれる場合、ライセンスデータは、利用されるコンテンツデータを復号するのに使用される暗号化コンテンツデータのキーを含んでいてもよい。
【0026】
図2の例では、トランスファ3は、例えばユーザ206によるペイロードの変換リクエストであるかもしれない。ある種の実施形態では、このトランスファは連続したサブトランスファに分解されるかもしれず、部分的な情報がトランスレータ204に送信される。トランスファは、もし必要なものがそれだけであるのであれば、ライセンスデータのみを含むものであってもよく、あるいはトランスファは、ライセンスデータとコンテンツデータを含んでいてもよい。また、例えば変換処理を開始するのにデータの全てが必要とされない場合には、トランスファ3はトランスファ2とオーバーラップしていてもよい。トランスファ4には、例えば変換されたペイロードのユーザ206への転送が含まれる。
【0027】
ある実施形態では、トランスレータは、ユーザによるペイロードの獲得に当たり、自動的に実行されるように構成されている。ある種の実施形態では、ペイロードの獲得においてサーバに送られるデータが、どのDRMに対してペイロードをコンパチブルとするかを決定するのに利用される。ある種の実施形態では、トランスレータは、コンテンツデータの利用を意図したユーザによって自動的に実行される;ユーザはトランスレータを例えば、どのDRMをどれに対し、ペイロードをコンパチブルとし、かつ/またはコンテンツデータを別のフォーマットに変換するかを決定することによりトランスレータをコントロールする。ある種の実施形態では、トランスレータは、1つのペイロードを複数のペイロードに、複数のペイロードを1つのペイロードに、あるいは第1の複数のペイロードを第2の複数のペイロードにすることができるように構成される。
【0028】
図3は、DRMシステム300内でのデータフローの一例を示す。図3はサーバ302からトランスレータ304へと送信されるデータを示す。またユーザ306は、例えば、彼らがどのDRMを使用しているか、あるいは更に、例えば、彼らがどのフォーマットのコンテンツデータを好むかを規定する。ある種の実施形態では、この情報はトランスファのコンテキストから自動的に推測される。
【0029】
図3の例では、ユーザ306は、コンテンツデータのリクエストをサーバ302へと送信できる。これに応答して(あるいは代わりにある任意のまたは所定の時点で)、サーバ302は、ペイロードを第1フォーマットからユーザ306のDRMとコンパチブルな第2フォーマットへと変換するようにトランスレータ304にリクエストを送信してもよい。トランスレータ304は、変換された情報をサーバ302へと返すことができ、サーバ302はユーザ306へ変換された情報を転送する。
【0030】
図4は、DRMシステム400内のデータフローの一例を示す。トランスファは、図1を参照して上で説明されたものと同様に行われる。図4の例では、ユーザ406は、サーバ402へコンテンツデータのリクエストを送信する。説明の便宜上、コンテンツデータを含むペイロードはユーザ406がリクエストしたDRM内にはなく、情報はトランスレータ404へと転送される。トランスレータ404は、ペイロードをリクエストされた方法で変換し、変換された情報をユーザ406へと送信する。
【0031】
図5は、DRMシステム500内でのデータフローの一例を示す。トランスファは、図1を参照して上で説明されたものと同様に行われる。図5の例では、別のDRMを用いているユーザ506−1とユーザ506−2(以後集合的にはユーザ506として参照する)が存在する。ユーザ506−1はコンテンツデータをリクエストし、コンテンツデータを含むペイロードを受信する。ユーザ506−1は、ペイロードをユーザ506−2へと送信する。ここでユーザ506−2は、説明の便宜上、例えばユーザ506−1と同じDRMを実行していないことからコンテンツデータを利用できない。ユーザ506−2は、トランスレータ504へとペイロードを送信可能であり、ペイロードは、ユーザ506−2で実行されているDRMとコンパチブルにすることができ、コンパチブルなペイロードがユーザ506−2へと戻される。
【0032】
図6は、ライセンスデータをユーザのDRMとコンパチブルなフォーマットへと変換する方法のフローチャート600である。この方法や他の方法は、一連のブロックとディシジョンポイントによって示される。しかし、これらの方法におけるブロックとディシジョンポイントは、順番を変えたり、あるいは適切な並列処理にアレンジしたりすることもできる。
【0033】
図6の例では、フローチャート600は、ユーザがリクエストを送信するブロック602からスタートする。リクエストには、例えば、ペイロードを第1DRMとコンパチブルなフォーマットから第2DRMとコンパチブルなフォーマットへと変換するリクエストが含まれるかもしれない。例えば、リクエストには、コンテンツデータを別のフォーマットへ変換する要求が含まれるかもしれない。リクエストは、ライセンスデータと、可能でもし適切であればコンテンツデータを含んでもよく、あるいは代替的に、ライセンスデータかつ/またはコンテンツデータは、リクエストされた変換を行えるかが判定された後で、トランスレータへと転送されてもよい。トランスレータは、例えば、ライセンスデータをDRMの多様な組み合わせに対してコンパチブルとなるように構成されてもよい。
【0034】
図6の例では、フローチャート600は、コンテンツデータ、ライセンスデータ、あるいは他のペイロードが正しいフォーマットであるか否かを判定するディシジョンポイント604まで続く。既にペイロードが正しいフォーマットであれば(604−Y)、フローチャート600は終了する。別の実施形態では、フローチャート600は、リクエストと関連付けられたDRMが認知されず、あるいは不明の場合、変換は法律(例えば著作権法)に違反するかもしれず、あるいはライセンスは原型が損なわれたか、ある他の欠陥が存在するかもしれない。別の実施形態では、コンテンツデータは、異なる複数のフォーマットに変換されるかもしれない。これらの実施形態では、コンテンツの変換が可能であるか否かもまたチェックされる。
【0035】
図6の例では、ペイロードが正しいフォーマットでないと判定されると(604−N)、フローチャート600は、ペイロードが適正なDRMとコンパチブルとなるようにトランスレートされるブロック606へと続く。トランスレーションは、限定的では無く例示的に、新しいライセンスデータの取り替えのみを伴うかもしれない。しかし、DRMによっては、コンテンツデータを含むペイロードを部分的あるいは全面的に再フォーマットすることが好ましいかもしれない。ある種の実施形態では、コンテンツデータは更に別のフォーマットに変換される。
【0036】
図7は、トランスレータシステム700の一例を示す。図7の例において、システム700は、メモリ704、プロセッサ708、そして入力/出力コミュニケーションポート710を備える。図7の例では、メモリ704は、モジュール702とトランスレーションデータベース706を備える。プロセッサ708は、周知の、あるいはx86ベース、パワーPC、SPARC、ARMなどの手頃な種類のものであってもよい。メモリ704は、周知のあるいは手頃な種類あるいはフォーマットであってもよく、メインメモリ、キャッシュメモリ、2次記憶など如何なる形式のものを含み、あるいは周知のあるいは手頃な形式のメモリの組み合わせであってもよい。プロセッサ708とメモリ704は、プロセッサ708がメモリ内のプログラムモジュール702を実行することができ、またトランスレーションデータベース706にアクセスすることができるように連結されている。入力/出力コミュニケーションポートは、周知、手頃な如何なる形式のものであってもよい。コミュニケーションポートの幾つかの具体例は、ラジオ無線、USB接続、イーサーネット接続、ファイヤーワイヤなどである。
【0037】
図7の例では、作動中、プロセッサ708は図8を参照して後述されるようにモジュール702を実行する。実行時、モジュール702は、第1DRMとコンパチブルなペイロードを第2DRMとコンパチブルなペイロードへと変換することができる。この例では、モジュール702は、変換を行うのにトランスレーションデータベース706内の情報を利用する。入力/出力ポートは、リクエストを受信し、変換された部分を例えばユーザに送信する。別の実施形態では、メモリ704は、キャッシュされたコンテンツデータを持っているかもしれず、これはコンテンツデータが初めての変換された後にキャッシュされるか、あるいは外部エンティティ(装置)によって保存される。キャッシュされたコンテンツデータは、周知あるいは手頃な、限定的ではなく例示的に、データベースへの保存を含む任意の方法で保存される。
【0038】
図8は、トランスレーションシステム、限定的ではなく例示的に、システム700(図7)などのトランスレーションモジュール間における情報の流れの一例を模式的に示す。図8は、コンバージョンライブラリ802とモジュール810を含むシステム800を示す。モジュール810は、シグネチャ・チェッキング・モジュール812、ライセンス・パーシング・モジュール814、ライセンス・コンバージョン・モジュール816、ライセンス・フォーマティング・モジュール818、およびライセンス・サインナー・モジュール820を備える。この構成は単なる一例であり、モジュールが組み合わせられ、あるいは取り除かれ、あるいは追加された他の形態も可能である。
【0039】
図8の例では、作動中、シグネチャ・チェッキング・モジュール812は、ライセンスデータにおけるデジタルシグネチャの妥当性(バリディティ)を検証(ベリファイ)する。非限定的な実施形態では、ベリフィケーションはトランスレータに対してローカルに行われる。別の実施形態では、外部ソースがデジタルシグネチャの妥当性を保証するためにコンタクトされる。全てのペイロードがデジタルシグネチャを必ずしも含んでいる必要はない;これは、ペイロードがコンパチブルとなるDRMに依存するかもしれないし、しないかもしれない。デジタルシグネチャが不正な場合には、異なる複数のアクションが可能であり、一例としてはリクエストされた変換を拒否し、あるいは同じコンテンツデータをもつ正規にサインされたペイロードを提供できるサーバへのリンクを提供する。
【0040】
ある種の実施形態では、デジタル・シグネチャ・スキームは、パブリックキー暗号法を使用する。パブリックキー暗号法では、各ユーザは一対のキーを持つ:1つはパブリックで1つはプライベートである。パブリックキーは無償で配布されるが、プライベートキーは公表されずに秘密にされる。この技術は周知であり、ここで説明される技術とともに様々な周知のあるいは手頃な実施例を利用することが可能である。
【0041】
一例としてのデジタル・シグネチャ・スキームは3つのアルゴリズムからなる:キー生成アルゴリズム、署名アルゴリズム、そしてベリフィケーションアルゴリズム。
【0042】
ある種の実施形態では、デジタルシグネチャはパブリックキーを用いてベリファイされる。シグネチャがベリファイされると、署名アルゴリズムはシグネチャを偽造するのを難しいように設計されていることから、トランスレータは、メッセージがパブリックキーと関連付けられたサーバからのものであると十分に確信できる。
【0043】
図8の例では、ライセンス・パーサ・モジュール814は、ライセンスデータからユーセッジ情報を取り除く。非限定的な実施形態として、ライセンス・パーサ・モジュール814は、ユーセッジ情報のロケーションを特定するかもしれないコンバージョンライブラリ802内の情報を利用してどのようにライセンスを解読(パース)するか決定する。ライセンス情報を解読(パース)するためのコンバージョンライブラリ802の利用は、非限定的な実施形態によるものである;他の可能な実施形態ではライブラリは利用されない。ライブラリが利用されない実施形態では、ライセンス・パーサ・モジュール814は、例えばライブラリにコンタクトすることなくライセンス情報を解読(パース)するようにプログラムされている。
【0044】
図8の例では、ライセンス・コンバージョン・モジュール816は、ユーセッジパラメータを第2DRMによって利用できる形式にする。ユーセッジパラメータが変換された形式は、第2DRMと直ちにコンパチブルであってもなくともよい。パラメータの形式が第2DRMによって利用できる情報は、コンバージョンライブラリ802に含まれる。ライセンス・パーサ・モジュール814と同様に、ライブラリの利用は選択的であり、コンバータはライブラリを調べることなく変換するようにプログラムされていてもよい。ある実施形態では、第1DRMはコンテンツデータを1日利用されると規定するかもしれないが、第2DRMは時間単位の利用制限のみを期待するかもしれない。このような実施形態では、ライセンス・コンバージョン・モジュール816は、1日を24時間に変換するであろう。
【0045】
図8の例では、ライセンス・フォーマッティング・モジュール818は、変換されたユーセッジパラメータを、ライセンス・コンバージョン・モジュール814から提供された情報を用いて第2DRMとコンパチブルなライセンスを生成するためにフォーマットする。ライセンス・フォーマッティング・モジュール818は、どのように変換されたパラメータを第2DRMとコンパチブルな形式にフォーマットするかについての情報をコンバージョンライブラリ802から検索する。別の実施形態では、ライブラリは選択的であって、ライセンス・フォーマッティング・モジュール818は、変換されたパラメータをフォーマットするように既にプログラムされているかもしれない。ライセンス・フォーマッティング・モジュール818は、ペイロードをリクエストされたDRMとコンパチブルにするようにリクエストされた場合に、ライセンスを超えてペイロードの全てをフォーマットするように更に構成されていてもよいが、そうでなくともよい。
【0046】
図8の例では、ライセンス署名モジュール820は、限定的にではなく例示的に上述された方法、あるいは周知のそして手頃な代替的な任意の方法で、キー生成アルゴリズムを用いてペイロードにデジタルに署名する。非限定的な実施形態では、ライセンス署名モジュール820は、ライセンスデータに認証シグネチャを追加することができる。これは、限定的にではなく例示的に上述された方法、あるいは周知のそして手頃な代替的な任意の方法などのパブリック・キー・システムを用いて実現できる。全てのライセンスがデジタルに署名されている必要はなく、ある場合には、実施形態、構成、かつ/または、どのDRMへ、あるいは、どのDRMからライセンスが変換されるかに依存してもよい。
【0047】
図8の例では、コンバージョンライブラリ802は、特定のDRMとコンパチブルなライセンスをどのように解析するか、パラメータをどのように特定のDRMとコンパチブルな形式に変換するか、そして特定のDRMがどのライセンス形式を要求するかについての情報を備えていてもよい。コンバージョンライブラリ802は、随意的であり、トランスレータ800の作動に必要であるかもしれないし、必要でないかもしれない。ある実施形態では、新たな変換情報がDRMの変換のためのコンバージョンライブラリ806に追加されるかもしれず、あるいはライブラリに存在する情報がアップデートできる。例えば、特定のDRMの仕様が変わると、ライブラリはこれらの変更を考慮した新たな情報にアップデートできる。
【0048】
図9は、ペイロード変換のための方法の一例のフローチャート900を示す。フローチャート900は、ペイロードを変換するリクエストを受信するブロック902で開始する。このリクエストがどのような情報を含むかは、実施されている形態に依存し、限定的ではなく例示的に、ライセンス、全ペイロード、支払い情報などリクエストされたもののみを含むであろう。
【0049】
図9の例では、フローチャート900は、ディシジョンポイント904へと続き、ペイロードに関連付けられたシグネチャが正規のものであるか否かが判定される。周知のあるいは手頃などのようなデジタルシグネチャが使用されてもよい。ペイロードにデジタルシグネチャは必ずしも必要ではない。シグネチャがない場合には、ペイロードは、実施されている形態、かつ/またはトランザクションの状態に従って、受け入れられ、あるいは拒絶される。ペイロードと関連付けられたシグネチャが正規なものでないときには、フローチャート900は終了する。別の実施形態では、追加的なアクションとして、同じデジタルコンテンツを含む正規に署名されたペイロードが得られるロケーションにユーザを振り向けるユーザへのノーティフィケーションや、コンテンツオーナのノーティフィケーションを含んでいてもよい。それ以外の場合、フローチャート900はディシジョンポイント906へと続く。
【0050】
ディシジョンポイント906では、ライセンスがリクエストされた方法で変換できるか否かが判定される。例えば図6を参照して前述されたように、ペイロードを変換できない理由が存在する可能性がある。ペイロードが変換できないときには、フローチャート900は終了する。それ以外の場合には、フローチャート900はブロック908へと続く。
【0051】
ブロック908では、ライセンスデータがユーセッジのパラメータへと解析される。ユーセッジのパラメータは、ペイロードがコンパチブルであるDRMに依存する。ユーセッジのパラメータは、例えば、特定のコンテンツデータに対して適用される契約条項を記述しているかもしれない。ある種の実施形態では、ユーセッジのパラメータが存在せず、正規のライセンスの存在がコンテンツデータの使用権を示す。
【0052】
ブロック910では、ライセンスに含まれる暗号化キーを用いてコンテンツデータが復号される。これは、一例に過ぎず、周知のあるいは手頃な暗号化/復号化技術が用いられるであろう。
【0053】
ブロック912では、コンテンツデータがリクエストされたフォーマットに変換される。ある実施形態では、コンテンツデータが既に要求されるフォーマットであれば、データの変換は必要とされない。別の状況では、コンテンツデータは既に要求されたフォーマットでローカルにキャッシュされているかもしれず、変換を必要とせずにこのコピーが利用されるかもしれない。
【0054】
ブロック914では、ライセンスは別のDRMとコンパチブルな形式にトランスレートされる。DRM間のロスレスな変換は常に可能なわけではなく、ときには、ライセンスに含まれる情報が、コンパチブルなライセンスが新たなDRMで取らなければならないフォームから失われる。ある実施形態では、ライセンスデータのロスを低減してロッシートランスファの影響を低減するために近似やロジックが用いられる。ロッシートランスファの一例は、1つのDRMにおいてコンテンツデータが40時間利用されることとなっていて、コンテンツが利用されるDRMでは、コンテンツは日数に基づいてのみ時間制限を認識するとき、制限は時間制限を2日に切り上げ、あるいは1日に切り下げるように丸めるように構成されてもよい。多くに状況において、変換はロスレスであり、第1DRMに含まれる全ての情報は、第2DRMにおいても適用される。
【0055】
ブロック916では、ライセンスはリクエストされたDRMとともに利用できるようにフォーマットされる。ある実施形態では、例えば、ライセンスデータが既にDRMとコンパチブルであれば、フォーマットは必要ない。別の実施形態では、フォーマットはライセンスデータ以外にも要求され、全てのペイロードがリクエストされたDRMとコンパチブルになるようにフォーマットされる必要があるかもしれない。
【0056】
ブロック918では、ペイロードは認証シグネチャを用いてデジタルに署名される。デジタル認証シグネチャの例は、図8を参照して、限定的にではなく例示的に説明される。
【0057】
図10Aおよび図10Bは、ペイロード1000とパケット1050の一例を図式的に表す。可能な実施形態では、ペイロードは分割され、図10Bの例にパケット1050として示されるパケットとして転送される。このような実施形態では、幾つかの、あるいは全てのパケットが送信先で受領されると、ペイロードと関連付けられた各パケットを用いてファイルを生成するようにパケットが結合される。このような実施形態では、パケットは、パケットをルーティングするためのヘッダ情報、およびそれらが結合される方法を特定するためのヘッダ情報を一般に含む。
【0058】
図10Aの例では、ペイロード1000はライセンスデータ1002とコンテンツデータ1004を含む。コンテンツデータ1004は、図1Aを参照して限定的ではなく例示的に説明されたように、暗号化され、あるいは暗号化されず、または部分的に暗号化されていてもよい。コンテンツデータ1004は、例えば使用権に従う任意のメディアであり、音楽、ビデオゲーム、ムービー、電子図書などが含まれる。またコンテンツは、図1Aを参照して限定的ではなく例示的に説明されたように、周知あるいは手頃などのようなフォーマットであってもよい。
【0059】
図10Aの例では、ライセンスデータ1002は、ユーセッジルール1008、コンテンツデータ1010のための暗号化キー、そして電子シグネチャ1012を含む。これは単に一例であり、ライセンスは、図10Aの例に示されたものよりも多い、あるいは少ない、または異なる情報の組み合わせを含んでいてもよい。ユーセッジルール1008は、例えばコンパチブルなDRMの下におけるコンテンツデータ1004の利用のためのルールである。ユーセッジルール1008は、このDRMによって規定されるかもしれないが、されないかもしれない。実施形態および/または実施例によっては、特定のライセンス内にユーセッジルールが全くないかもしれない。例えば、正規のライセンスの存在は、コンテンツデータの許可された使用法(ユーセッジ)を示すのに適切であり得る。代替的に、コンテンツデータ1004がどのように、何処で、何時使用できるかについての具体的な情報がライセンスデータ1002に記録されてもよい。
【0060】
図10Aの例では、暗号化キー1010は、暗号化されたコンテンツデータを復号化するためのキーであるかもしれない。1つの暗号化キーのみが示されるが、他の実施形態では、コンテンツデータのため多数のキーがあってもなくともよい。更にある実施形態では、暗号化キー自身が、ある種の方法で暗号化されており、使用される前に暗号化されていない状態にする必要があるかもしれない。
【0061】
図10Aの例では、シグネチャ1012は、コンテンツデータ1004が正規なものであることを示すためにペイロード1000の製作者によって残されたデータを含む。データはコピーするのが難しく、指定されたソースからのデータで、例えば偽造されたものでないこと証明することを意図したものである。シグネチャ1012は、ライセンスデータ1002内に含まれた状態で示されるが、これは一例に過ぎず、それはペイロード1000の何処に含まれていてもよく、あるいは希な実施の形態では、パケット1050のヘッダ内であってすらよい。デジタルシグネチャを生成するには、様々な適用可能な方法があり、その中の1つは限定的ではなく例示的に上記図8を参照して説明された。
【0062】
ここで使用される、用語「実施形態」は、限定的ではなく例示的な説明を行うための実施形態を意味する。
【0063】
当業者であれば前述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定するものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の要旨と範囲に含まれることを意図している。したがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこのような全ての変更、置き換え、均等物を含むことを意図している。
【図面の簡単な説明】
【0064】
【図1A】DRMトランスレーション内のデータフローの一例を概念的に示す。
【図1B】DRMトランスレーション内のデータフローの一例を概念的に示す。
【図2】DRMシステム内のデータフローの一例を示す。
【図3】DRMシステム内のデータフローの一例を示す。
【図4】DRMシステム内のデータフローの一例を示す。
【図5】DRMシステム内のデータフローの一例を示す。
【図6】ライセンスデータをユーザのDRMとコンパチブルなフォーマットに変換するための方法のフローチャートを示す。
【図7】トランスレータシステムの一例を示す。
【図8】トランスレータシステムにおけるトランスレーションモジュール間の情報の流れの一例を図式的に示す。
【図9】ペイロードトランスレーションのための方法の一例のフローチャートを示す。
【図10A】ペイロードの一例の図式的な代表図である。
【図10B】
【特許請求の範囲】
【請求項1】
コンテンツCが第1デジタルフォーマット.aでコード化され、使用権がユーセッジパラメータを含む第1デジタル著作権管理(DRM)xによって保護される第1デジタル・コンテンツ・ユニットC.a(x)を提供可能なサーバと;
コンテンツが第2デジタルフォーマット.bでコード化され、使用権が第2DRM、yによって保護される第2デジタル・コンテンツ・ユニットC.b(y)に前記第1デジタル・コンテンツ・ユニットを変換可能なトランスレータとを備え;
作動時、前記サーバは前記第1デジタル・コンテンツ・ユニットを提供し、前記トランスレータは前記第1デジタル・コンテンツ・ユニットを第2デジタル・コンテンツ・ユニットに変換し、前記コンテンツが前記第2デジタル・コンテンツ・ユニットとコンパチブルなプレーヤにおいて実行される
ことを特徴とするシステム。
【請求項2】
作動時、前記トランスレータは、多数の第1デジタル・コンテンツ・ユニットC.a1(x1)〜C.aN(xN)を前記第2デジタル・コンテンツ・ユニットに変換することを特徴とする請求項1に記載のシステム。
【請求項3】
作動時、前記トランスレータは、前記第1デジタル・コンテンツ・ユニットを多数の第2デジタル・コンテンツ・ユニットC.b1(y1)〜C.bN(yN)に変換することを特徴とする請求項1に記載のシステム。
【請求項4】
作動時、前記トランスレータは、多数の第1デジタル・コンテンツ・ユニットC.a1(x1)〜C.aN(xN)を多数の第2デジタル・コンテンツ・ユニットC.b1(y1)〜C.bN(yN)に変換することを特徴とする請求項1に記載のシステム。
【請求項5】
作動時、前記トランスレータは、ユーザによって手動で起動されることを特徴とする請求項1に記載のシステム。
【請求項6】
作動時、前記トランスレータは、前記サーバからの前記第1デジタル・コンテンツ・ユニットの取得に基づいてユーザデバイスにより起動されることを特徴とする請求項1に記載のシステム。
【請求項7】
作動時、前記コンテンツと関連付けられた購入データは、前記第2DRMとコンパチブルなコンテンツの作成に使用されることを特徴とする請求項1に記載のシステム。
【請求項8】
作動時、前記コンテンツと関連付けられた購入データは、前記コンテンツが提供されたロケーションにおいて、関連付けられたeコマーストランザクション内に、前記コンテンツの完結とともに、あるいは前記eコマーストランザクションが終了した後で埋め込まれることを特徴とする請求項1に記載のシステム。
【請求項9】
作動時、購入トランザクションデータ、関連付けられたトランザクションデータ、第1デジタル・コンテンツ・ユニット・データの種類、第2デジタル・コンテンツ・ユニット・データの種類、前記第1デジタル・コンテンツ・ユニットを変換するのに適切な第2デジタル・コンテンツ・ユニットの検索に関連付けられたデータ、前記第2デジタル・コンテンツ・ユニットとコンパチブルな前記コンテンツのプレーヤに関連付けられたデータからなる群から選択されるデータによって前記トランスレータがガイドされることを特徴とする請求項1に記載のシステム。
【請求項10】
前記コンテンツデータが、ユーザとコンパチブルなフォーマットに変換された後で、前記トランスレータに対してローカルにキャッシュされることを特徴とする請求項1に記載のシステム。
【請求項11】
少なくとも前記コンテンツデータのいくらかは暗号化され、ライセンスデータが暗号化キーを含み、前記トランスレータが暗号化されたコンテンツデータを前記暗号化キーを用いて別のフォーマットに変換することができることを特徴とする請求項1に記載のシステム。
【請求項12】
前記第1DRMのユーセッジパラメータが、ビジネスロジックにしたがって、新しいユーセッジパラメータによって置き換えられることを特徴とする請求項1に記載のシステム。
【請求項13】
第1DRMとコンパチブルなライセンスデータとコンテンツデータとを含むデジタルミディアムを受信し、
第2DRMとコンパチブルとなるようにライセンスデータをトランスレートし、
前記デジタルメディアムにトラスレートされたライセンスデータを付加し、
前記トランスレートされたライセンスデータを含む前記デジタルミディアムを送信する
ことを特徴とする方法。
【請求項14】
前記デジタルミディアムが認証シグネチャを含み、更に
正規であるか前記認証シグネチャをチェックし、
不正であれば前記ライセンスデータをトランスレートしないままにする
ことを特徴とする請求項13に記載の方法。
【請求項15】
更に、トランスレーションが前記ライセンスデータをサポートするかを判定するためにライセンスデータをチェックすることを特徴とする請求項13に記載の方法。
【請求項16】
更に、前記ライセンスデータからユーセッジパラメータを作成し、前記ユーセッジパラメータはソースのライセンスフォーマットの詳細を知ることなくトランスレートできるフォーマットで記述されることを特徴とする請求項13に記載の方法。
【請求項17】
ライセンスデータの前記トランスレーションがロッシーであり、ライセンスデータのロスを低減するために近似が用いられることを特徴とする請求項13に記載の方法。
【請求項18】
プロセッサ、
前記プロセッサに連結されたメモリを備え、前記メモリは前記プロセッサにより実行可能なプログラムモジュールを保存し、
前記メモリが、
ライセンスデータをユーセッジのパラメータに変化させられるライセンス・パーシング・モジュールと、
前記ユーセッジのパラメータをDRMとコンパチブルなライセンスデータに作り変えるライセンス・コンバージョン・モジュールと、
第1DRMとコンパチブルな前記ライセンスデータ内に記録された使用権を第2DRMとコンパチブルなライセンスデータに再コード化できるライセンス・フォーマッティング・モジュールと
を備えることを特徴とするシステム。
【請求項19】
前記メモリが、ライセンス認証シグネチャが正規であるかベリファイできるシグネチャ・チェッキング・モジュールを更に備えることを特徴とする請求項18に記載のシステム。
【請求項20】
前記メモリが、前記ライセンスデータに認証シグニチャを付加することができる署名モジュールを更に備えることを特徴とする請求項18に記載のシステム。
【請求項21】
前記メモリが、前記ライセンス・コンバージョン・モジュールにより使用されるトランスレーションデータを含むライブラリを更に備えることを特徴とする請求項18に記載のシステム。
【請求項22】
前記メモリが、前記ライセンス・コンバージョン・モジュールにより使用されるトランスレーションデータを含むライブラリを更に備え、作動時、前記ライブラリが新しいトランスレーションデータでアップデートされることを特徴とする請求項18に記載のシステム。
【請求項23】
前記ライセンス・コンバージョン・モジュールが、前記第2DRMとコンパチブルなライセンスデータのロッシーな生成における使用権のロスを低減するように構成され、前記第2DRMが前記ライセンスデータに記録された全ての使用権を実施できず、使用権の情報のロスを低減するために情報が近似あるいは省略されることを特徴とする請求項18に記載のシステム。
【請求項1】
コンテンツCが第1デジタルフォーマット.aでコード化され、使用権がユーセッジパラメータを含む第1デジタル著作権管理(DRM)xによって保護される第1デジタル・コンテンツ・ユニットC.a(x)を提供可能なサーバと;
コンテンツが第2デジタルフォーマット.bでコード化され、使用権が第2DRM、yによって保護される第2デジタル・コンテンツ・ユニットC.b(y)に前記第1デジタル・コンテンツ・ユニットを変換可能なトランスレータとを備え;
作動時、前記サーバは前記第1デジタル・コンテンツ・ユニットを提供し、前記トランスレータは前記第1デジタル・コンテンツ・ユニットを第2デジタル・コンテンツ・ユニットに変換し、前記コンテンツが前記第2デジタル・コンテンツ・ユニットとコンパチブルなプレーヤにおいて実行される
ことを特徴とするシステム。
【請求項2】
作動時、前記トランスレータは、多数の第1デジタル・コンテンツ・ユニットC.a1(x1)〜C.aN(xN)を前記第2デジタル・コンテンツ・ユニットに変換することを特徴とする請求項1に記載のシステム。
【請求項3】
作動時、前記トランスレータは、前記第1デジタル・コンテンツ・ユニットを多数の第2デジタル・コンテンツ・ユニットC.b1(y1)〜C.bN(yN)に変換することを特徴とする請求項1に記載のシステム。
【請求項4】
作動時、前記トランスレータは、多数の第1デジタル・コンテンツ・ユニットC.a1(x1)〜C.aN(xN)を多数の第2デジタル・コンテンツ・ユニットC.b1(y1)〜C.bN(yN)に変換することを特徴とする請求項1に記載のシステム。
【請求項5】
作動時、前記トランスレータは、ユーザによって手動で起動されることを特徴とする請求項1に記載のシステム。
【請求項6】
作動時、前記トランスレータは、前記サーバからの前記第1デジタル・コンテンツ・ユニットの取得に基づいてユーザデバイスにより起動されることを特徴とする請求項1に記載のシステム。
【請求項7】
作動時、前記コンテンツと関連付けられた購入データは、前記第2DRMとコンパチブルなコンテンツの作成に使用されることを特徴とする請求項1に記載のシステム。
【請求項8】
作動時、前記コンテンツと関連付けられた購入データは、前記コンテンツが提供されたロケーションにおいて、関連付けられたeコマーストランザクション内に、前記コンテンツの完結とともに、あるいは前記eコマーストランザクションが終了した後で埋め込まれることを特徴とする請求項1に記載のシステム。
【請求項9】
作動時、購入トランザクションデータ、関連付けられたトランザクションデータ、第1デジタル・コンテンツ・ユニット・データの種類、第2デジタル・コンテンツ・ユニット・データの種類、前記第1デジタル・コンテンツ・ユニットを変換するのに適切な第2デジタル・コンテンツ・ユニットの検索に関連付けられたデータ、前記第2デジタル・コンテンツ・ユニットとコンパチブルな前記コンテンツのプレーヤに関連付けられたデータからなる群から選択されるデータによって前記トランスレータがガイドされることを特徴とする請求項1に記載のシステム。
【請求項10】
前記コンテンツデータが、ユーザとコンパチブルなフォーマットに変換された後で、前記トランスレータに対してローカルにキャッシュされることを特徴とする請求項1に記載のシステム。
【請求項11】
少なくとも前記コンテンツデータのいくらかは暗号化され、ライセンスデータが暗号化キーを含み、前記トランスレータが暗号化されたコンテンツデータを前記暗号化キーを用いて別のフォーマットに変換することができることを特徴とする請求項1に記載のシステム。
【請求項12】
前記第1DRMのユーセッジパラメータが、ビジネスロジックにしたがって、新しいユーセッジパラメータによって置き換えられることを特徴とする請求項1に記載のシステム。
【請求項13】
第1DRMとコンパチブルなライセンスデータとコンテンツデータとを含むデジタルミディアムを受信し、
第2DRMとコンパチブルとなるようにライセンスデータをトランスレートし、
前記デジタルメディアムにトラスレートされたライセンスデータを付加し、
前記トランスレートされたライセンスデータを含む前記デジタルミディアムを送信する
ことを特徴とする方法。
【請求項14】
前記デジタルミディアムが認証シグネチャを含み、更に
正規であるか前記認証シグネチャをチェックし、
不正であれば前記ライセンスデータをトランスレートしないままにする
ことを特徴とする請求項13に記載の方法。
【請求項15】
更に、トランスレーションが前記ライセンスデータをサポートするかを判定するためにライセンスデータをチェックすることを特徴とする請求項13に記載の方法。
【請求項16】
更に、前記ライセンスデータからユーセッジパラメータを作成し、前記ユーセッジパラメータはソースのライセンスフォーマットの詳細を知ることなくトランスレートできるフォーマットで記述されることを特徴とする請求項13に記載の方法。
【請求項17】
ライセンスデータの前記トランスレーションがロッシーであり、ライセンスデータのロスを低減するために近似が用いられることを特徴とする請求項13に記載の方法。
【請求項18】
プロセッサ、
前記プロセッサに連結されたメモリを備え、前記メモリは前記プロセッサにより実行可能なプログラムモジュールを保存し、
前記メモリが、
ライセンスデータをユーセッジのパラメータに変化させられるライセンス・パーシング・モジュールと、
前記ユーセッジのパラメータをDRMとコンパチブルなライセンスデータに作り変えるライセンス・コンバージョン・モジュールと、
第1DRMとコンパチブルな前記ライセンスデータ内に記録された使用権を第2DRMとコンパチブルなライセンスデータに再コード化できるライセンス・フォーマッティング・モジュールと
を備えることを特徴とするシステム。
【請求項19】
前記メモリが、ライセンス認証シグネチャが正規であるかベリファイできるシグネチャ・チェッキング・モジュールを更に備えることを特徴とする請求項18に記載のシステム。
【請求項20】
前記メモリが、前記ライセンスデータに認証シグニチャを付加することができる署名モジュールを更に備えることを特徴とする請求項18に記載のシステム。
【請求項21】
前記メモリが、前記ライセンス・コンバージョン・モジュールにより使用されるトランスレーションデータを含むライブラリを更に備えることを特徴とする請求項18に記載のシステム。
【請求項22】
前記メモリが、前記ライセンス・コンバージョン・モジュールにより使用されるトランスレーションデータを含むライブラリを更に備え、作動時、前記ライブラリが新しいトランスレーションデータでアップデートされることを特徴とする請求項18に記載のシステム。
【請求項23】
前記ライセンス・コンバージョン・モジュールが、前記第2DRMとコンパチブルなライセンスデータのロッシーな生成における使用権のロスを低減するように構成され、前記第2DRMが前記ライセンスデータに記録された全ての使用権を実施できず、使用権の情報のロスを低減するために情報が近似あるいは省略されることを特徴とする請求項18に記載のシステム。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10A】
【図10B】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10A】
【図10B】
【公表番号】特表2009−535992(P2009−535992A)
【公表日】平成21年10月1日(2009.10.1)
【国際特許分類】
【出願番号】特願2009−509677(P2009−509677)
【出願日】平成19年5月1日(2007.5.1)
【国際出願番号】PCT/US2007/010601
【国際公開番号】WO2008/039246
【国際公開日】平成20年4月3日(2008.4.3)
【出願人】(505286718)ブロードオン コミュニケーションズ コーポレーション (8)
【氏名又は名称原語表記】BroadOn Communications Corp.
【Fターム(参考)】
【公表日】平成21年10月1日(2009.10.1)
【国際特許分類】
【出願日】平成19年5月1日(2007.5.1)
【国際出願番号】PCT/US2007/010601
【国際公開番号】WO2008/039246
【国際公開日】平成20年4月3日(2008.4.3)
【出願人】(505286718)ブロードオン コミュニケーションズ コーポレーション (8)
【氏名又は名称原語表記】BroadOn Communications Corp.
【Fターム(参考)】
[ Back to top ]