JP2009535992A - Ｄｒｍトランスレーションのシステムおよび方法 - Google Patents

Abstract

ＤＲＭトランスレーションの技術は、第１デジタルコンテンツを第２デジタルコンテンツに変換する。この技術に従ったシステムの例は、第１デジタルフォーマットでコード化された第１デジタル・コンテンツ・ユニットと第１デジタル著作権管理（ＤＲＭ）により保護された使用権を提供するサーバを備える。更にシステムは、第１デジタル・コンテンツ・ユニットを第２デジタルフォーマットでコード化され第２ＤＲＭにより使用権が保護された第２デジタル・コンテンツ・ユニットへと変換可能なトランスレータを備える。

Description

デジタル著作権管理（ＤＲＭ）は、デジタルコンテンツの消費者とデジタルコンテンツのプロバイダとの間での利用契約の支援を目的とした技術分野である。これらの契約を支援するために様々な異なる手段が用いられている。

デジタルコンテンツの利用のために契約が締結されると、デジタルコンテンツとともに使用許諾契約書（ライセンスアグリーメント）がパッケージされる。デジタルコンテンツのライセンスは、ときにｅチケットと呼ばれる。ライセンスには、どのような利用規約が含まれ、プロバイダとユーザとの間で合意されたかに関わる情報が含まれることもある。このライセンス情報は、通常特定のＤＲＭとともに機能するように設計され、特定のＤＲＭとコンパチブルなシステムでのコンテンツの利用、あるいはライセンスに含まれる利用規約が取り除かれて履行できなくなることを効果的に制限する。

以下の実施形態とそれらの目的は、代表例、例示を意図したシステム、ツール、方法と組み合わせて記述され説明されるもので、範囲を限定するものではない。様々な実施形態において、上述の問題は軽減されあるいは除去されるが、他の実施形態は別の改良に向けられている。

ＤＲＭトランスレーションの技術は、第１デジタルコンテンツを第２デジタルコンテンツに変換する。この技術に従ったシステムの例は、第１デジタルフォーマットでコード化された第１デジタル・コンテンツ・ユニットと第１デジタル著作権管理（ＤＲＭ）により保護された使用権を提供するサーバを備える。更にシステムは、第１デジタル・コンテンツ・ユニットを第２デジタルフォーマットでコード化され第２ＤＲＭにより使用権が保護された第２デジタル・コンテンツ・ユニットへと変換可能なトランスレータを備える。

トランスレータは、コンテンツデータを別のフォーマットへと変換するように構成されていてもよい。またトランスレータは、不必要な転送を防止できるように、コンテンツデータをローカルにキャッシュしてもよい。

ＤＲＭトランスレータは、ライセンス情報を変換し、必要とあれば、ペイロードを現在コンパチブルなものから別のＤＲＭでの使用に合わせてフォーマットする。それはまた、コンテンツが正規なものであることの信頼性を向上するためのデジタル認証シグネチャをベリファイするように構成されてもよい。トランスレータは、ペイロードがそれらのレジティマシに従ってユーザによって簡単にベリファイできるようにデジタル・サイン・ペイロードとして構成されていてもよい。

本発明の実施形態は、図面に示される。しかし、実施形態と図面は、限定的なものではなく例示的なもので、それらは本発明を例示的に提示する。

以下の説明では、本発明の実施形態の十分な理解を与えるために幾つかの特定の具体的な構成が提示される。しかし、当業者であれば、１つ以上のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組み合わせにより、本発明を実施することが可能であることが理解されるであろう。また別の例では、様々な実施形態における本発明の側面を覆い隠すことがないように、周知の具体的構成は、図示または詳細に説明されていない。

図１Ａは、ＤＲＭトランスレーション内のデータフローの一例を概念的に示す。システム１００は、サーバ１０２からトランスレータ１０４、ユーザ１０６への情報の可能な流れを示す。図１Ａは、データがＤＲＭトランスレーションをどのように流れるかを示す一例である。他の例については図２〜５を参照して後述される。

図１Ａの例では、サーバ１０２は図においてａ（ｘ）として表されるペイロードを提供し、ここで“ａ”は第１のＤＲＭとコンパチブルなライセンスデータを表し、“ｘ”はコンテンツデータを表す。ペイロードについては、図１０を参照して後述され、ある実施形態では、ライセンスデータおよびコンテンツデータ以外のものも含まれる。ライセンスデータは、例えばメディアに関する情報やメディアと関連付けられたユーセッジパラメータ（例えば、アクセス権）を含む。別の実施形態では、例えば正規のライセンスの存在のみでＤＲＭ内のコンテンツデータの使用権を示し、ユーセッジのパラメータを含むライセンスデータの必要性は除去される。ライセンスデータは、個々のＤＲＭや多数のＤＲＭとコンパチブルであってもよい。１つの実施形態では、ライセンスデータは特定のＤＲＭでの利用のためにフォーマットされていてもよい。別の実施形態では、ライセンスは多数のＤＲＭとコンパチブルとなるようにフォーマットされているかもしれない。ライセンスデータは、セキュリティのために、周知のあるいは手頃な方法で暗号化されていてもよい。

コンテンツデータは、周知のあるいは手頃なフォーマットで提供されてもよく、例えば周知のあるいは手頃な種類の情報である。コンテンツデータの幾つかの例は、ビデオゲーム、ムービー、音楽などである。音楽フォーマットの幾つかの例は、ＭＰ３、ＡＡＣ、ＷＭＡ、ＯＧＧなどである。コンテンツデータの一部あるいは全ては、セキュリティのために暗号化されていてもよく、ライセンスデータには、暗号化されたコンテンツデータを解読可能とする暗号化キーが含まれていてもよい。暗号化は周知のあるいは手頃などのような方法で行われてもよい。トランスレータは、例えば、暗号化キーを用いて暗号化されたデータを新しいフォーマットに変換するように構成することも可能である。

図１Ａの例では、トランスレータ１０４は、ライセンス情報“ａ”をライセンス情報“ｂ”に変換する。ここで、“ｂ”は“ａ”に相当するが別のＤＲＭにコンパチブルなライセンスデータである。ペイロードは、ライセンスデータ内の使用権を今まで通り維持しつつ別のＤＲＭでの利用においてコンパチブルとされる。この例では、ライセンスデータ“ａ”はライセンスデータ“ｂ”で置き換えられるが、置き換えは必須ではない。例えば、“ｂ”は、これまで通りライセンス“ａ”を含んでいてもよいが、オリジナルに追加される第２のあるいは任意の数の付加的なライセンスを含んでいてもよい。必要であれば、多数のＤＲＭシステムとコンパチブルな多数のライセンスが含まれてもよい。

トランスレーションの前後でライセンスに関連付けられた利用制限は、常に同じとは限らず、互いに殆どあるいは全く関係がなくともよい。例えば、第１のＤＲＭでの販売のために当初エンコードされた歌を含むデジタルコンテンツが、第２のＤＲＭでサブスクリプションモデルに変換されてもよい。したがって、第１のＤＲＭは、ビジネスロジックの定義に従って第２のＤＲＭに置き換えられ得る。

異なるＤＲＭへのユーセッジパラメータの変換は、常に「ロスレス」トランスファであるとは限らず、これは変換元、変換先の個々のＤＲＭに依存することを意味し、必ずしも契約規定の全てをトランスファできない可能性がある。このような場合、トランスレータは使用権の「ロッシー」トランスファを行うように構成されてもよい。ロッシートランスファの一例は、１つのＤＲＭにおけるコンテンツデータが４０時間の利用であり、別のＤＲＭの時間制限が日数としてのみ認識される場合、個々の具体的な実施に即して制限は、時間制限を切り上げて２日にするか、あるいは切り捨てて１日するように構成されてもよい。

図１Ａの例において、ユーザ１０６は、１つのＤＲＭシステムにおいてコンテンツデータを利用できる任意のエンティティ（実在物）である。ユーザとして可能なのは例えば、ポータブルミュージックプレイヤ、ムービープレイヤ、ゲームプレイヤであり、このときコンテンツデータは、それぞれ音楽、ムービー、ビデオゲームなどである。情報のトランスファは、周知のあるいは手頃な方法によるものであってもよく、いつかの例は、ＬＡＮ、インターネットダウンロード、店舗内のキオスクなどからの転送を通して利用できるコンポーネントである。

図１Ａは、ユーザ１０６、トランスレータ１０４、サーバ１０２を独立したコンポーネントとして示すが、これは例示を目的としたものである。各々は論理上あるいは物理的に同じデバイスに設けられていてもよい。例えば、サーバ１０２、トランスレータ１０４、ユーザ１０６は、全て１台のデバイスに搭載されたコンポーネントであってもよく、また何れかの組み合わせが１台のデバイスに搭載されていてもよい。

デジタルコンテンツが購入されるホストと、コンテンツ使用権の所有者が再生に利用しようと望むプレーヤとの違いから通常適用の必要性が生じる。例えば、ユーザは、ソースであるデジタルコンテンツＣ．ａ（ｘ）をウェブサイトＸから購入する。デジタルコンテンツＣは、デジタルフォーマット．ａでコード化され、使用権はＤＲＭｘにより保護される（同時に支配される）。例えばＤＲＭｙおよびデジタルフォーマット．ｂを採用するプレーヤ（ソフトウェアあるいはハードウェア）を用いてＣを再生する場合など、権利をＣに対して行使するには、コンテンツＣがプレーヤで再生され得る前に、Ｃ．ａ（ｘ）はターゲットであるＣ．ｂ（ｙ）にトランスレートされるためにＤＲＭトランスレータを通る必要がある。なお．ａは．ｂと同じであってもよい。

ＤＲＭトランスレータは、上述された「ｅチケットトランスレーション」を可能にするプログラムである。２つのＤＲＭの間が完全にコンパチブルではないという潜在的な可能性から、このトランスレーションは、トランスレータが最大の努力を行った後であっても数学的にロスレスではないかもしれない。ＤＲＭトランスレータは、ＤＲＭが行うべく、悪意ある攻撃と動作環境においける改変から保護されている必要がある。

図１Ｂは、コンテンツデータ“Ｘ_１”がコンテンツデータ“Ｘ_２”へと変換される点を除いて図１Ａと同様である。この例では、ライセンスデータが図１Ａを参照して説明されたように変換されることに加え、コンテンツデータがユーザ１０６とコンパチブルな別のフォーマットへと変換される。この一例は、ＭＰ３でのオーディオファイルのＡＡＣフォーマットへの変換である。図１Ａを参照して説明で示されたように、暗号化されたコンテンツデータは、ライセンスが暗号化キーを含む場合に利用できる。ある種の実施形態では、トランスレータは暗号化されたコンテンツを別の暗号化されたフォーマットに変換することができ、ライセンスデータに新しいキーを含ませることができる。

コンテンツデータの別のフォーマットへの変換は、ユーザ１０６にとって必要であれば自動的に開始でき、あるいはマニュアル入力で開始できる。コンテンツデータの自動変換の一例は、サーバ１０２にとってコンパチブルなフォーマットを検出し、それに従ってデータを変換するようにトランスレータに要求を発信する。ある種の実施形態では、例えば２者の間のコミュニケーションで要求されるバンド幅を低減する目的で、変換されたコンテンツデータがトランスレータ１０４において既にキャッシュされていてもよい。更なる例では、コンテンツデータは、ユーザ１０６とコンパチブルなフォーマットに変換された後でトランスレータ１０４に対してローカルに自動的にキャッシュされてもよく、それによりサーバ１０２とトランスレータ１０４の間における後続するコンテンツデータの転送におけるコンテンツデータの転送の必要性を除去する。ある種の実施形態では、キャッシュされたコンテンツデータがローカルに保存される時間の長さをマニュアルで設定でき、あるいは例えばトランスレータ１０４に含まれるロジックにより自動的に計算することができる。

またトランスレータ１０４は、ペイロードを１つのファイルから多数のファイルへ、または多数のペイロードを１組のペイロードあるいは複数のペイロードの複数のファイルを複数のペイロードへ変換するように構成することもできる。変換は特定の種類のファイルに対して自動的に行われるように設定することも、マニュアルで行うように設定することもできる。１つのファイルを多数のペイロードに変換する一例は、ダウンロードにおいてムービーが１つのデータユニットとすることができないほど大きい場合である。トランスレータ１０４は、ムービーの各部に対応するペイロードを含んだ多数のパケットとして送信できるように、ムービーを多数のブロックに分解するかもしれない。

図２は、ＤＲＭシステム２００におけるデータフローの一例を示す。システム２００は、サーバ２０２、トランスレータ２０４、ユーザ２０６を備える。図２の例では、トランスレータ２０４は独立したコンポーネントとして示されるが、サーバ２０２の一部としてロジック上あるいは物理的に含まれていてもよい。この例では、トランスレータ２０４は、ライセンスデータが現在コンパチブルであるものとは別のＤＲＭとコンパチブルとなるようにライセンスデータを変換する。コンテンツデータは、必要であれば別のフォーマットに変換することもできる。ある種の実施形態では、トランスレータ２０４は、コンテンツ・データ・ファイルをキャッシュして、サーバ２０２からトランスレータ２０４へ転送される必要がないようにする。加えて、トランスレータ２０４は、後続する転送の必要がないようにコンテンツデータが最初に受信されたときにコンテンツデータを変換し、その後変換されたコンテンツデータをキャッシュしてもよい。

図２の例では、例示的に４つのトランザクションが、ユーザ２０６へのあるいはからの矢印として描かれる。図３の例では、トランスファは個別・単独の転送として示されるが、ある種の実施形態では、マルチプルトランスファ、オーバーラッピングトランスファ、マルチ・ディレクショナル・トランスファであるかもしれない。トランスファ１は、ユーザ２０６からサーバ２０２への転送である。トランスファ２は、サーバ２０２からユーザ２０６への転送である。トランスファ３は、ユーザ２０６からトランスレータ２０４への転送である。トランスファ４は、トランスレータ２０４からユーザ２０６への転送である。トランスファは、異なるオーダーで発生するかもしれず、複数のサブトランスファに分解されるもしれず、あるいは異なるトランスファのタイミングがオーバーラップするかもしれない。

図２の例では、トランスファ１は、例えばユーザ２０６がコンテンツデータを利用するためのリクエストを送信したものであるかもしれない。リクエストには、ユーザ２０６がどのような利用規約を求めているかが含まれていてもよく、あるいは利用規約はリクエストのコンテキストから自動的に予測されてもよい。利用規約が、トランスファから如何に予測されるかは、例えば、ユーザ２０６のアイデンティティ、過去の購買行動、あるいは他のオプションが示されていない場合にはデフォルトのオプションである。別の例では、トランスファ１は、全般的なコンテンツリクエストで、必要となる付加的な情報を集めるために追加の複数のトランスファが利用されるかもしれない。

図２の例では、トランスファ２は、例えばユーザ２０６に送信されるライセンスとコンテンツデータであるかもしれない。図１Ａおよび図１Ｂを参照して説明されたように、ライセンスデータは、例えば周知あるいは手頃なＤＲＭとコンパチブルであって、コンテンツデータは、例えば周知あるいは手頃なフォーマットに従っている。例示的な実施形態では、コンテンツデータは、暗号化フォーマットで提供される。別の例示的な実施形態では、コンテンツデータとライセンスデータは両者ともに暗号化されている。ペイロードに暗号化データが含まれる場合、ライセンスデータは、利用されるコンテンツデータを復号するのに使用される暗号化コンテンツデータのキーを含んでいてもよい。

図２の例では、トランスファ３は、例えばユーザ２０６によるペイロードの変換リクエストであるかもしれない。ある種の実施形態では、このトランスファは連続したサブトランスファに分解されるかもしれず、部分的な情報がトランスレータ２０４に送信される。トランスファは、もし必要なものがそれだけであるのであれば、ライセンスデータのみを含むものであってもよく、あるいはトランスファは、ライセンスデータとコンテンツデータを含んでいてもよい。また、例えば変換処理を開始するのにデータの全てが必要とされない場合には、トランスファ３はトランスファ２とオーバーラップしていてもよい。トランスファ４には、例えば変換されたペイロードのユーザ２０６への転送が含まれる。

ある実施形態では、トランスレータは、ユーザによるペイロードの獲得に当たり、自動的に実行されるように構成されている。ある種の実施形態では、ペイロードの獲得においてサーバに送られるデータが、どのＤＲＭに対してペイロードをコンパチブルとするかを決定するのに利用される。ある種の実施形態では、トランスレータは、コンテンツデータの利用を意図したユーザによって自動的に実行される；ユーザはトランスレータを例えば、どのＤＲＭをどれに対し、ペイロードをコンパチブルとし、かつ／またはコンテンツデータを別のフォーマットに変換するかを決定することによりトランスレータをコントロールする。ある種の実施形態では、トランスレータは、１つのペイロードを複数のペイロードに、複数のペイロードを１つのペイロードに、あるいは第１の複数のペイロードを第２の複数のペイロードにすることができるように構成される。

図３は、ＤＲＭシステム３００内でのデータフローの一例を示す。図３はサーバ３０２からトランスレータ３０４へと送信されるデータを示す。またユーザ３０６は、例えば、彼らがどのＤＲＭを使用しているか、あるいは更に、例えば、彼らがどのフォーマットのコンテンツデータを好むかを規定する。ある種の実施形態では、この情報はトランスファのコンテキストから自動的に推測される。

図３の例では、ユーザ３０６は、コンテンツデータのリクエストをサーバ３０２へと送信できる。これに応答して（あるいは代わりにある任意のまたは所定の時点で）、サーバ３０２は、ペイロードを第１フォーマットからユーザ３０６のＤＲＭとコンパチブルな第２フォーマットへと変換するようにトランスレータ３０４にリクエストを送信してもよい。トランスレータ３０４は、変換された情報をサーバ３０２へと返すことができ、サーバ３０２はユーザ３０６へ変換された情報を転送する。

図４は、ＤＲＭシステム４００内のデータフローの一例を示す。トランスファは、図１を参照して上で説明されたものと同様に行われる。図４の例では、ユーザ４０６は、サーバ４０２へコンテンツデータのリクエストを送信する。説明の便宜上、コンテンツデータを含むペイロードはユーザ４０６がリクエストしたＤＲＭ内にはなく、情報はトランスレータ４０４へと転送される。トランスレータ４０４は、ペイロードをリクエストされた方法で変換し、変換された情報をユーザ４０６へと送信する。

図５は、ＤＲＭシステム５００内でのデータフローの一例を示す。トランスファは、図１を参照して上で説明されたものと同様に行われる。図５の例では、別のＤＲＭを用いているユーザ５０６−１とユーザ５０６−２（以後集合的にはユーザ５０６として参照する）が存在する。ユーザ５０６−１はコンテンツデータをリクエストし、コンテンツデータを含むペイロードを受信する。ユーザ５０６−１は、ペイロードをユーザ５０６−２へと送信する。ここでユーザ５０６−２は、説明の便宜上、例えばユーザ５０６−１と同じＤＲＭを実行していないことからコンテンツデータを利用できない。ユーザ５０６−２は、トランスレータ５０４へとペイロードを送信可能であり、ペイロードは、ユーザ５０６−２で実行されているＤＲＭとコンパチブルにすることができ、コンパチブルなペイロードがユーザ５０６−２へと戻される。

図６は、ライセンスデータをユーザのＤＲＭとコンパチブルなフォーマットへと変換する方法のフローチャート６００である。この方法や他の方法は、一連のブロックとディシジョンポイントによって示される。しかし、これらの方法におけるブロックとディシジョンポイントは、順番を変えたり、あるいは適切な並列処理にアレンジしたりすることもできる。

図６の例では、フローチャート６００は、ユーザがリクエストを送信するブロック６０２からスタートする。リクエストには、例えば、ペイロードを第１ＤＲＭとコンパチブルなフォーマットから第２ＤＲＭとコンパチブルなフォーマットへと変換するリクエストが含まれるかもしれない。例えば、リクエストには、コンテンツデータを別のフォーマットへ変換する要求が含まれるかもしれない。リクエストは、ライセンスデータと、可能でもし適切であればコンテンツデータを含んでもよく、あるいは代替的に、ライセンスデータかつ／またはコンテンツデータは、リクエストされた変換を行えるかが判定された後で、トランスレータへと転送されてもよい。トランスレータは、例えば、ライセンスデータをＤＲＭの多様な組み合わせに対してコンパチブルとなるように構成されてもよい。

図６の例では、フローチャート６００は、コンテンツデータ、ライセンスデータ、あるいは他のペイロードが正しいフォーマットであるか否かを判定するディシジョンポイント６０４まで続く。既にペイロードが正しいフォーマットであれば（６０４−Ｙ）、フローチャート６００は終了する。別の実施形態では、フローチャート６００は、リクエストと関連付けられたＤＲＭが認知されず、あるいは不明の場合、変換は法律（例えば著作権法）に違反するかもしれず、あるいはライセンスは原型が損なわれたか、ある他の欠陥が存在するかもしれない。別の実施形態では、コンテンツデータは、異なる複数のフォーマットに変換されるかもしれない。これらの実施形態では、コンテンツの変換が可能であるか否かもまたチェックされる。

図６の例では、ペイロードが正しいフォーマットでないと判定されると（６０４−Ｎ）、フローチャート６００は、ペイロードが適正なＤＲＭとコンパチブルとなるようにトランスレートされるブロック６０６へと続く。トランスレーションは、限定的では無く例示的に、新しいライセンスデータの取り替えのみを伴うかもしれない。しかし、ＤＲＭによっては、コンテンツデータを含むペイロードを部分的あるいは全面的に再フォーマットすることが好ましいかもしれない。ある種の実施形態では、コンテンツデータは更に別のフォーマットに変換される。

図７は、トランスレータシステム７００の一例を示す。図７の例において、システム７００は、メモリ７０４、プロセッサ７０８、そして入力／出力コミュニケーションポート７１０を備える。図７の例では、メモリ７０４は、モジュール７０２とトランスレーションデータベース７０６を備える。プロセッサ７０８は、周知の、あるいはｘ８６ベース、パワーＰＣ、ＳＰＡＲＣ、ＡＲＭなどの手頃な種類のものであってもよい。メモリ７０４は、周知のあるいは手頃な種類あるいはフォーマットであってもよく、メインメモリ、キャッシュメモリ、２次記憶など如何なる形式のものを含み、あるいは周知のあるいは手頃な形式のメモリの組み合わせであってもよい。プロセッサ７０８とメモリ７０４は、プロセッサ７０８がメモリ内のプログラムモジュール７０２を実行することができ、またトランスレーションデータベース７０６にアクセスすることができるように連結されている。入力／出力コミュニケーションポートは、周知、手頃な如何なる形式のものであってもよい。コミュニケーションポートの幾つかの具体例は、ラジオ無線、ＵＳＢ接続、イーサーネット接続、ファイヤーワイヤなどである。

図７の例では、作動中、プロセッサ７０８は図８を参照して後述されるようにモジュール７０２を実行する。実行時、モジュール７０２は、第１ＤＲＭとコンパチブルなペイロードを第２ＤＲＭとコンパチブルなペイロードへと変換することができる。この例では、モジュール７０２は、変換を行うのにトランスレーションデータベース７０６内の情報を利用する。入力／出力ポートは、リクエストを受信し、変換された部分を例えばユーザに送信する。別の実施形態では、メモリ７０４は、キャッシュされたコンテンツデータを持っているかもしれず、これはコンテンツデータが初めての変換された後にキャッシュされるか、あるいは外部エンティティ（装置）によって保存される。キャッシュされたコンテンツデータは、周知あるいは手頃な、限定的ではなく例示的に、データベースへの保存を含む任意の方法で保存される。

図８は、トランスレーションシステム、限定的ではなく例示的に、システム７００（図７）などのトランスレーションモジュール間における情報の流れの一例を模式的に示す。図８は、コンバージョンライブラリ８０２とモジュール８１０を含むシステム８００を示す。モジュール８１０は、シグネチャ・チェッキング・モジュール８１２、ライセンス・パーシング・モジュール８１４、ライセンス・コンバージョン・モジュール８１６、ライセンス・フォーマティング・モジュール８１８、およびライセンス・サインナー・モジュール８２０を備える。この構成は単なる一例であり、モジュールが組み合わせられ、あるいは取り除かれ、あるいは追加された他の形態も可能である。

図８の例では、作動中、シグネチャ・チェッキング・モジュール８１２は、ライセンスデータにおけるデジタルシグネチャの妥当性（バリディティ）を検証（ベリファイ）する。非限定的な実施形態では、ベリフィケーションはトランスレータに対してローカルに行われる。別の実施形態では、外部ソースがデジタルシグネチャの妥当性を保証するためにコンタクトされる。全てのペイロードがデジタルシグネチャを必ずしも含んでいる必要はない；これは、ペイロードがコンパチブルとなるＤＲＭに依存するかもしれないし、しないかもしれない。デジタルシグネチャが不正な場合には、異なる複数のアクションが可能であり、一例としてはリクエストされた変換を拒否し、あるいは同じコンテンツデータをもつ正規にサインされたペイロードを提供できるサーバへのリンクを提供する。

ある種の実施形態では、デジタル・シグネチャ・スキームは、パブリックキー暗号法を使用する。パブリックキー暗号法では、各ユーザは一対のキーを持つ：１つはパブリックで１つはプライベートである。パブリックキーは無償で配布されるが、プライベートキーは公表されずに秘密にされる。この技術は周知であり、ここで説明される技術とともに様々な周知のあるいは手頃な実施例を利用することが可能である。

一例としてのデジタル・シグネチャ・スキームは３つのアルゴリズムからなる：キー生成アルゴリズム、署名アルゴリズム、そしてベリフィケーションアルゴリズム。

ある種の実施形態では、デジタルシグネチャはパブリックキーを用いてベリファイされる。シグネチャがベリファイされると、署名アルゴリズムはシグネチャを偽造するのを難しいように設計されていることから、トランスレータは、メッセージがパブリックキーと関連付けられたサーバからのものであると十分に確信できる。

図８の例では、ライセンス・パーサ・モジュール８１４は、ライセンスデータからユーセッジ情報を取り除く。非限定的な実施形態として、ライセンス・パーサ・モジュール８１４は、ユーセッジ情報のロケーションを特定するかもしれないコンバージョンライブラリ８０２内の情報を利用してどのようにライセンスを解読（パース）するか決定する。ライセンス情報を解読（パース）するためのコンバージョンライブラリ８０２の利用は、非限定的な実施形態によるものである；他の可能な実施形態ではライブラリは利用されない。ライブラリが利用されない実施形態では、ライセンス・パーサ・モジュール８１４は、例えばライブラリにコンタクトすることなくライセンス情報を解読（パース）するようにプログラムされている。

図８の例では、ライセンス・コンバージョン・モジュール８１６は、ユーセッジパラメータを第２ＤＲＭによって利用できる形式にする。ユーセッジパラメータが変換された形式は、第２ＤＲＭと直ちにコンパチブルであってもなくともよい。パラメータの形式が第２ＤＲＭによって利用できる情報は、コンバージョンライブラリ８０２に含まれる。ライセンス・パーサ・モジュール８１４と同様に、ライブラリの利用は選択的であり、コンバータはライブラリを調べることなく変換するようにプログラムされていてもよい。ある実施形態では、第１ＤＲＭはコンテンツデータを１日利用されると規定するかもしれないが、第２ＤＲＭは時間単位の利用制限のみを期待するかもしれない。このような実施形態では、ライセンス・コンバージョン・モジュール８１６は、１日を２４時間に変換するであろう。

図８の例では、ライセンス・フォーマッティング・モジュール８１８は、変換されたユーセッジパラメータを、ライセンス・コンバージョン・モジュール８１４から提供された情報を用いて第２ＤＲＭとコンパチブルなライセンスを生成するためにフォーマットする。ライセンス・フォーマッティング・モジュール８１８は、どのように変換されたパラメータを第２ＤＲＭとコンパチブルな形式にフォーマットするかについての情報をコンバージョンライブラリ８０２から検索する。別の実施形態では、ライブラリは選択的であって、ライセンス・フォーマッティング・モジュール８１８は、変換されたパラメータをフォーマットするように既にプログラムされているかもしれない。ライセンス・フォーマッティング・モジュール８１８は、ペイロードをリクエストされたＤＲＭとコンパチブルにするようにリクエストされた場合に、ライセンスを超えてペイロードの全てをフォーマットするように更に構成されていてもよいが、そうでなくともよい。

図８の例では、ライセンス署名モジュール８２０は、限定的にではなく例示的に上述された方法、あるいは周知のそして手頃な代替的な任意の方法で、キー生成アルゴリズムを用いてペイロードにデジタルに署名する。非限定的な実施形態では、ライセンス署名モジュール８２０は、ライセンスデータに認証シグネチャを追加することができる。これは、限定的にではなく例示的に上述された方法、あるいは周知のそして手頃な代替的な任意の方法などのパブリック・キー・システムを用いて実現できる。全てのライセンスがデジタルに署名されている必要はなく、ある場合には、実施形態、構成、かつ／または、どのＤＲＭへ、あるいは、どのＤＲＭからライセンスが変換されるかに依存してもよい。

図８の例では、コンバージョンライブラリ８０２は、特定のＤＲＭとコンパチブルなライセンスをどのように解析するか、パラメータをどのように特定のＤＲＭとコンパチブルな形式に変換するか、そして特定のＤＲＭがどのライセンス形式を要求するかについての情報を備えていてもよい。コンバージョンライブラリ８０２は、随意的であり、トランスレータ８００の作動に必要であるかもしれないし、必要でないかもしれない。ある実施形態では、新たな変換情報がＤＲＭの変換のためのコンバージョンライブラリ８０６に追加されるかもしれず、あるいはライブラリに存在する情報がアップデートできる。例えば、特定のＤＲＭの仕様が変わると、ライブラリはこれらの変更を考慮した新たな情報にアップデートできる。

図９は、ペイロード変換のための方法の一例のフローチャート９００を示す。フローチャート９００は、ペイロードを変換するリクエストを受信するブロック９０２で開始する。このリクエストがどのような情報を含むかは、実施されている形態に依存し、限定的ではなく例示的に、ライセンス、全ペイロード、支払い情報などリクエストされたもののみを含むであろう。

図９の例では、フローチャート９００は、ディシジョンポイント９０４へと続き、ペイロードに関連付けられたシグネチャが正規のものであるか否かが判定される。周知のあるいは手頃などのようなデジタルシグネチャが使用されてもよい。ペイロードにデジタルシグネチャは必ずしも必要ではない。シグネチャがない場合には、ペイロードは、実施されている形態、かつ／またはトランザクションの状態に従って、受け入れられ、あるいは拒絶される。ペイロードと関連付けられたシグネチャが正規なものでないときには、フローチャート９００は終了する。別の実施形態では、追加的なアクションとして、同じデジタルコンテンツを含む正規に署名されたペイロードが得られるロケーションにユーザを振り向けるユーザへのノーティフィケーションや、コンテンツオーナのノーティフィケーションを含んでいてもよい。それ以外の場合、フローチャート９００はディシジョンポイント９０６へと続く。

ディシジョンポイント９０６では、ライセンスがリクエストされた方法で変換できるか否かが判定される。例えば図６を参照して前述されたように、ペイロードを変換できない理由が存在する可能性がある。ペイロードが変換できないときには、フローチャート９００は終了する。それ以外の場合には、フローチャート９００はブロック９０８へと続く。

ブロック９０８では、ライセンスデータがユーセッジのパラメータへと解析される。ユーセッジのパラメータは、ペイロードがコンパチブルであるＤＲＭに依存する。ユーセッジのパラメータは、例えば、特定のコンテンツデータに対して適用される契約条項を記述しているかもしれない。ある種の実施形態では、ユーセッジのパラメータが存在せず、正規のライセンスの存在がコンテンツデータの使用権を示す。

ブロック９１０では、ライセンスに含まれる暗号化キーを用いてコンテンツデータが復号される。これは、一例に過ぎず、周知のあるいは手頃な暗号化／復号化技術が用いられるであろう。

ブロック９１２では、コンテンツデータがリクエストされたフォーマットに変換される。ある実施形態では、コンテンツデータが既に要求されるフォーマットであれば、データの変換は必要とされない。別の状況では、コンテンツデータは既に要求されたフォーマットでローカルにキャッシュされているかもしれず、変換を必要とせずにこのコピーが利用されるかもしれない。

ブロック９１４では、ライセンスは別のＤＲＭとコンパチブルな形式にトランスレートされる。ＤＲＭ間のロスレスな変換は常に可能なわけではなく、ときには、ライセンスに含まれる情報が、コンパチブルなライセンスが新たなＤＲＭで取らなければならないフォームから失われる。ある実施形態では、ライセンスデータのロスを低減してロッシートランスファの影響を低減するために近似やロジックが用いられる。ロッシートランスファの一例は、１つのＤＲＭにおいてコンテンツデータが４０時間利用されることとなっていて、コンテンツが利用されるＤＲＭでは、コンテンツは日数に基づいてのみ時間制限を認識するとき、制限は時間制限を２日に切り上げ、あるいは１日に切り下げるように丸めるように構成されてもよい。多くに状況において、変換はロスレスであり、第１ＤＲＭに含まれる全ての情報は、第２ＤＲＭにおいても適用される。

ブロック９１６では、ライセンスはリクエストされたＤＲＭとともに利用できるようにフォーマットされる。ある実施形態では、例えば、ライセンスデータが既にＤＲＭとコンパチブルであれば、フォーマットは必要ない。別の実施形態では、フォーマットはライセンスデータ以外にも要求され、全てのペイロードがリクエストされたＤＲＭとコンパチブルになるようにフォーマットされる必要があるかもしれない。

ブロック９１８では、ペイロードは認証シグネチャを用いてデジタルに署名される。デジタル認証シグネチャの例は、図８を参照して、限定的にではなく例示的に説明される。

図１０Ａおよび図１０Ｂは、ペイロード１０００とパケット１０５０の一例を図式的に表す。可能な実施形態では、ペイロードは分割され、図１０Ｂの例にパケット１０５０として示されるパケットとして転送される。このような実施形態では、幾つかの、あるいは全てのパケットが送信先で受領されると、ペイロードと関連付けられた各パケットを用いてファイルを生成するようにパケットが結合される。このような実施形態では、パケットは、パケットをルーティングするためのヘッダ情報、およびそれらが結合される方法を特定するためのヘッダ情報を一般に含む。

図１０Ａの例では、ペイロード１０００はライセンスデータ１００２とコンテンツデータ１００４を含む。コンテンツデータ１００４は、図１Ａを参照して限定的ではなく例示的に説明されたように、暗号化され、あるいは暗号化されず、または部分的に暗号化されていてもよい。コンテンツデータ１００４は、例えば使用権に従う任意のメディアであり、音楽、ビデオゲーム、ムービー、電子図書などが含まれる。またコンテンツは、図１Ａを参照して限定的ではなく例示的に説明されたように、周知あるいは手頃などのようなフォーマットであってもよい。

図１０Ａの例では、ライセンスデータ１００２は、ユーセッジルール１００８、コンテンツデータ１０１０のための暗号化キー、そして電子シグネチャ１０１２を含む。これは単に一例であり、ライセンスは、図１０Ａの例に示されたものよりも多い、あるいは少ない、または異なる情報の組み合わせを含んでいてもよい。ユーセッジルール１００８は、例えばコンパチブルなＤＲＭの下におけるコンテンツデータ１００４の利用のためのルールである。ユーセッジルール１００８は、このＤＲＭによって規定されるかもしれないが、されないかもしれない。実施形態および／または実施例によっては、特定のライセンス内にユーセッジルールが全くないかもしれない。例えば、正規のライセンスの存在は、コンテンツデータの許可された使用法（ユーセッジ）を示すのに適切であり得る。代替的に、コンテンツデータ１００４がどのように、何処で、何時使用できるかについての具体的な情報がライセンスデータ１００２に記録されてもよい。

図１０Ａの例では、暗号化キー１０１０は、暗号化されたコンテンツデータを復号化するためのキーであるかもしれない。１つの暗号化キーのみが示されるが、他の実施形態では、コンテンツデータのため多数のキーがあってもなくともよい。更にある実施形態では、暗号化キー自身が、ある種の方法で暗号化されており、使用される前に暗号化されていない状態にする必要があるかもしれない。

図１０Ａの例では、シグネチャ１０１２は、コンテンツデータ１００４が正規なものであることを示すためにペイロード１０００の製作者によって残されたデータを含む。データはコピーするのが難しく、指定されたソースからのデータで、例えば偽造されたものでないこと証明することを意図したものである。シグネチャ１０１２は、ライセンスデータ１００２内に含まれた状態で示されるが、これは一例に過ぎず、それはペイロード１０００の何処に含まれていてもよく、あるいは希な実施の形態では、パケット１０５０のヘッダ内であってすらよい。デジタルシグネチャを生成するには、様々な適用可能な方法があり、その中の１つは限定的ではなく例示的に上記図８を参照して説明された。

ここで使用される、用語「実施形態」は、限定的ではなく例示的な説明を行うための実施形態を意味する。

当業者であれば前述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定するものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の要旨と範囲に含まれることを意図している。したがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこのような全ての変更、置き換え、均等物を含むことを意図している。

ＤＲＭトランスレーション内のデータフローの一例を概念的に示す。 ＤＲＭトランスレーション内のデータフローの一例を概念的に示す。 ＤＲＭシステム内のデータフローの一例を示す。 ＤＲＭシステム内のデータフローの一例を示す。 ＤＲＭシステム内のデータフローの一例を示す。 ＤＲＭシステム内のデータフローの一例を示す。 ライセンスデータをユーザのＤＲＭとコンパチブルなフォーマットに変換するための方法のフローチャートを示す。 トランスレータシステムの一例を示す。 トランスレータシステムにおけるトランスレーションモジュール間の情報の流れの一例を図式的に示す。 ペイロードトランスレーションのための方法の一例のフローチャートを示す。 ペイロードの一例の図式的な代表図である。

Claims (23)

1. コンテンツＣが第１デジタルフォーマット．ａでコード化され、使用権がユーセッジパラメータを含む第１デジタル著作権管理（ＤＲＭ）ｘによって保護される第１デジタル・コンテンツ・ユニットＣ．ａ（ｘ）を提供可能なサーバと；
   コンテンツが第２デジタルフォーマット．ｂでコード化され、使用権が第２ＤＲＭ、ｙによって保護される第２デジタル・コンテンツ・ユニットＣ．ｂ（ｙ）に前記第１デジタル・コンテンツ・ユニットを変換可能なトランスレータとを備え；
   作動時、前記サーバは前記第１デジタル・コンテンツ・ユニットを提供し、前記トランスレータは前記第１デジタル・コンテンツ・ユニットを第２デジタル・コンテンツ・ユニットに変換し、前記コンテンツが前記第２デジタル・コンテンツ・ユニットとコンパチブルなプレーヤにおいて実行される
   ことを特徴とするシステム。
2. 作動時、前記トランスレータは、多数の第１デジタル・コンテンツ・ユニットＣ．ａ１（ｘ１）〜Ｃ．ａＮ（ｘＮ）を前記第２デジタル・コンテンツ・ユニットに変換することを特徴とする請求項１に記載のシステム。
3. 作動時、前記トランスレータは、前記第１デジタル・コンテンツ・ユニットを多数の第２デジタル・コンテンツ・ユニットＣ．ｂ１（ｙ１）〜Ｃ．ｂＮ（ｙＮ）に変換することを特徴とする請求項１に記載のシステム。
4. 作動時、前記トランスレータは、多数の第１デジタル・コンテンツ・ユニットＣ．ａ１（ｘ１）〜Ｃ．ａＮ（ｘＮ）を多数の第２デジタル・コンテンツ・ユニットＣ．ｂ１（ｙ１）〜Ｃ．ｂＮ（ｙＮ）に変換することを特徴とする請求項１に記載のシステム。
5. 作動時、前記トランスレータは、ユーザによって手動で起動されることを特徴とする請求項１に記載のシステム。
6. 作動時、前記トランスレータは、前記サーバからの前記第１デジタル・コンテンツ・ユニットの取得に基づいてユーザデバイスにより起動されることを特徴とする請求項１に記載のシステム。
7. 作動時、前記コンテンツと関連付けられた購入データは、前記第２ＤＲＭとコンパチブルなコンテンツの作成に使用されることを特徴とする請求項１に記載のシステム。
8. 作動時、前記コンテンツと関連付けられた購入データは、前記コンテンツが提供されたロケーションにおいて、関連付けられたｅコマーストランザクション内に、前記コンテンツの完結とともに、あるいは前記ｅコマーストランザクションが終了した後で埋め込まれることを特徴とする請求項１に記載のシステム。
9. 作動時、購入トランザクションデータ、関連付けられたトランザクションデータ、第１デジタル・コンテンツ・ユニット・データの種類、第２デジタル・コンテンツ・ユニット・データの種類、前記第１デジタル・コンテンツ・ユニットを変換するのに適切な第２デジタル・コンテンツ・ユニットの検索に関連付けられたデータ、前記第２デジタル・コンテンツ・ユニットとコンパチブルな前記コンテンツのプレーヤに関連付けられたデータからなる群から選択されるデータによって前記トランスレータがガイドされることを特徴とする請求項１に記載のシステム。
10. 前記コンテンツデータが、ユーザとコンパチブルなフォーマットに変換された後で、前記トランスレータに対してローカルにキャッシュされることを特徴とする請求項１に記載のシステム。
11. 少なくとも前記コンテンツデータのいくらかは暗号化され、ライセンスデータが暗号化キーを含み、前記トランスレータが暗号化されたコンテンツデータを前記暗号化キーを用いて別のフォーマットに変換することができることを特徴とする請求項１に記載のシステム。
12. 前記第１ＤＲＭのユーセッジパラメータが、ビジネスロジックにしたがって、新しいユーセッジパラメータによって置き換えられることを特徴とする請求項１に記載のシステム。
13. 第１ＤＲＭとコンパチブルなライセンスデータとコンテンツデータとを含むデジタルミディアムを受信し、
    第２ＤＲＭとコンパチブルとなるようにライセンスデータをトランスレートし、
    前記デジタルメディアムにトラスレートされたライセンスデータを付加し、
    前記トランスレートされたライセンスデータを含む前記デジタルミディアムを送信する
    ことを特徴とする方法。
14. 前記デジタルミディアムが認証シグネチャを含み、更に
    正規であるか前記認証シグネチャをチェックし、
    不正であれば前記ライセンスデータをトランスレートしないままにする
    ことを特徴とする請求項１３に記載の方法。
15. 更に、トランスレーションが前記ライセンスデータをサポートするかを判定するためにライセンスデータをチェックすることを特徴とする請求項１３に記載の方法。
16. 更に、前記ライセンスデータからユーセッジパラメータを作成し、前記ユーセッジパラメータはソースのライセンスフォーマットの詳細を知ることなくトランスレートできるフォーマットで記述されることを特徴とする請求項１３に記載の方法。
17. ライセンスデータの前記トランスレーションがロッシーであり、ライセンスデータのロスを低減するために近似が用いられることを特徴とする請求項１３に記載の方法。
18. プロセッサ、
    前記プロセッサに連結されたメモリを備え、前記メモリは前記プロセッサにより実行可能なプログラムモジュールを保存し、
    前記メモリが、
    ライセンスデータをユーセッジのパラメータに変化させられるライセンス・パーシング・モジュールと、
    前記ユーセッジのパラメータをＤＲＭとコンパチブルなライセンスデータに作り変えるライセンス・コンバージョン・モジュールと、
    第１ＤＲＭとコンパチブルな前記ライセンスデータ内に記録された使用権を第２ＤＲＭとコンパチブルなライセンスデータに再コード化できるライセンス・フォーマッティング・モジュールと
    を備えることを特徴とするシステム。
19. 前記メモリが、ライセンス認証シグネチャが正規であるかベリファイできるシグネチャ・チェッキング・モジュールを更に備えることを特徴とする請求項１８に記載のシステム。
20. 前記メモリが、前記ライセンスデータに認証シグニチャを付加することができる署名モジュールを更に備えることを特徴とする請求項１８に記載のシステム。
21. 前記メモリが、前記ライセンス・コンバージョン・モジュールにより使用されるトランスレーションデータを含むライブラリを更に備えることを特徴とする請求項１８に記載のシステム。
22. 前記メモリが、前記ライセンス・コンバージョン・モジュールにより使用されるトランスレーションデータを含むライブラリを更に備え、作動時、前記ライブラリが新しいトランスレーションデータでアップデートされることを特徴とする請求項１８に記載のシステム。
23. 前記ライセンス・コンバージョン・モジュールが、前記第２ＤＲＭとコンパチブルなライセンスデータのロッシーな生成における使用権のロスを低減するように構成され、前記第２ＤＲＭが前記ライセンスデータに記録された全ての使用権を実施できず、使用権の情報のロスを低減するために情報が近似あるいは省略されることを特徴とする請求項１８に記載のシステム。

Images