JP2003517767A

JP2003517767A - 電子配布システム用のサーバとそれを操作するための方法

Info

Publication number: JP2003517767A
Application number: JP2001545935A
Authority: JP
Inventors: エー．デメロマルコ; ゼマンパベル; クリシュナスワミービネー; ディー．バイラムフランク
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1999-12-17
Filing date: 2000-12-13
Publication date: 2003-05-27
Also published as: EP1242855B1; ES2592903T3; WO2001044908A1; EP1242855A1; AU2260001A; US7047411B1

Abstract

(57)【要約】コンテンツ内の権利を配布し保護するデジタル管理システムのサーバアーキテクチャ。サーバアーキテクチャはコンテンツ項目を消費者に販売する小売サイト、小売サイトで販売しているコンテンツ品目を消費者に提供する履行サイト、高レベルのコピー防止機能を備えるコンテンツ項目を消費者読み取りデバイスで使用できるようにするアクティブ化サイトを含む。各小売サイトには、ＵＲＬ暗号化オブジェクトが備えられ、これにより、小売サイトと履行サイトの間で共有される秘密対称鍵に従って、小売サイトで販売するコンテンツの注文を処理するために履行サイトで必要とする情報を暗号化する。

Description

【発明の詳細な説明】

【０００１】（関連事例に対する相互参照）本出願は、どちらも１９９９年１２月１７日に提出された「Ｓｙｓｔｅｍｆ
ｏｒＤｉｓｔｒｉｂｕｔｉｎｇＣｏｎｔｅｎｔＨａｖｉｎｇＭｕｌｔｉ
ｌｅｖｅｌＳｅｃｕｒｉｔｙＰｒｏｔｅｃｔｉｏｎ」という名称の米国仮特
許出願第６０／１７２３１８号ならびに「ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄ
ｆｏｒＤｉｇｉｔａｌＲｉｇｈｔｓＭａｎａｇｅｍｅｎｔ」という名称
の米国仮特許出願第６０／１７２３１９号の有利性を請求するものである。

【０００２】（発明の分野）本発明は、一般に、コンピューティングの分野に関するものであり、より詳細
には、デジタル権利管理システム（ｄｉｇｉｔａｌｒｉｇｈｔｓｍａｎａｇ
ｅｍｅｎｔｓｙｓｔｅｍ）によるコンテンツ配布用にサーバを利用することに
関するものである。

【０００３】（発明の背景）コンピュータおよびパームサイズの電子デバイスの可用性および用途が広がる
につれて、文書を電子的に伝送および閲覧することが一般化してきた。インター
ネットのようなインフラストラクチャによる通信の向上に伴って、充実したサー
ビスおよびコンテンツをデバイスに提供する動きが極めて活発化している。提供
できるサービスおよびコンテンツとしては、ブックまたはテキスト資料のような
著作物が挙げられる。テキスト文書の電子配布は従来的なペーパコピーの配布よ
り高速かつ安価である。オーディオやビデオのようなテキスト以外のコンテンツ
に対しても同じ原理が適応し、そのようなコンテンツの電子配布は、一般に従来
的な媒体（例えば磁気テープまたは光ディスク）によるそのようなコンテンツの
配布より高速かつ安価である。しかし、電子配布の低コストおよび即時性は、電
子コンテンツを複写することの容易さと併せて、配布物の所有者の権利を保護す
るような配布管理の目的と矛盾する。

【０００４】電子文書が一当事者に伝送されると、電子文書における権利の所有者による承
認を得ることなく、またはしばしばその所有者がそのことを知ることもなく容易
に複写され、他人に配布されうる。この種の不正な文書配布は、著者またはコン
テンツ・プロバイダから権利使用料および／または所得を奪うおそれがある。現
行の多くの配布スキームに伴う問題は、所有権を保護するための規定が設けられ
ないことである。他のシステムは、所有権を保護することを試みているが、面倒
で柔軟性に欠け、購入者にとっての著作物の閲覧／読取り（あるいは、音楽やビ
デオなどのテキスト以外のコンテンツの場合は著作物の再生）が困難である。

【０００５】上記のことを鑑み、所有者の権利を保護しながら電子著作物を購入者に配布で
きる一方、柔軟で利用しやすい改良されたデジタル権利管理システムが必要であ
る。柔軟な機密保護レベルを提供するとともに、その購入者が各々のプラットホ
ームで電子コンテンツを閲覧／再生できるようにいくつかのクライアントプラッ
トフォーム上で動作可能なシステムも必要とされる。本発明のデジタル権利管理
システムは、コンテンツ所有者の知的財産を保護するとともに、著者または他の
コンテンツ所有者が彼らの創作努力に対する報酬を得ることを可能にしながら、
その保護機構によって購入者に過度な負担がかからないようにする上述の課題に
対する解決策を有利に提供する。

【０００６】（発明の概要）デジタル権利管理（「ＤＲＭ；（digital rights management）」）システム
で保護されたコンテンツを配布する操作をサポートするサーバのアーキテクチャ
を提供する。そのアーキテクチャは、アクティブ化サーバ構成（ａｃｔｉｖａｔ
ｉｏｎｓｅｒｖｅｒａｒｒａｎｇｅｍｅｎｔ）と配布サーバ構成（ｄｉｓｔ
ｒｉｂｕｔｉｏｎｓｅｒｖｅｒａｎａｎｇｅｍｅｎｔ）を含む。そのアーキ
テクチャは、不当な配布または保護コンテンツの不当な使用を防止するさまざま
なセキュリティ機能ならびにセキュリティ機能を実装するソフトウェアコンポー
ネントを含む。

【０００７】提供されたアーキテクチャに従って、無保護、ソース封印、個別封印（または
「登録」）、ソース署名および完全個人化（または「所有者限定」を含む複数の
レベルでコンテンツを保護することができる。「無保護」コンテンツは、暗号化
しない形式で配布される。「ソース封印」および「個別封印」コンテンツは暗号
化され、キーを検索することができないようにコンテンツに関連する特定の権利
管理データによって暗号で封印された暗号鍵がバンドルされ、権利管理データが
変更されたらこの鍵は、取り出せないようになっている。「ソース封印」と「個
別封印」との間の違いは、「個別封印」コンテンツは、正当な所有者に関係する
情報（たとえば、所有者の名称、クレジットカード番号、受領番号、または購入
取引のための取引ＩＤなど）を権利管理データ内に含み、コンテンツの実用コピ
ーからこの情報を削除できないようにすることで不当配布を検索を可能にする。
含まれる特定種類の情報は、コピーの小売店によって決定される。「署名」コン
テンツは、再生アプリケーションがその信憑性、またはその配布経路の信憑性を
検証できるように暗号で署名される。「完全個人化」コンテンツは、単に権利管
理情報で封印されただけでなく、アクティブ化サーバ構成で特定のクライアント
またはクライアント群だけに発行することにより、そのようなコンテンツの使用
を限られた数のインストールに限定する、「セキュアなリポジトリ」および「起
動認証」がなければアクセスできないように暗号化された解読鍵を備える暗号化
コンテンツである。

【０００８】アクティブ化サーバ構成には、１つまたは複数のサーバコンピューティングデ
バイスが備えられ、所定のクライアントデバイス上の「完全個人化」コンテンツ
にアクセスするためにコードとデータが必要な場合に、そのコードおよびデータ
をこれらのデバイスに送ることによりクライアント・コンピューティング・デバ
イスを「アクティブ化」する。一実施例では、「データ」は公開鍵と暗号化され
た秘密鍵を持つアクティブ化証明を含み、「コード」は暗号化された秘密鍵を復
号するのに必要な鍵を安全な方法で適用することによりアクティブ化証明内の秘
密鍵にアクセスするプログラム（たとえば、「安全なリポジトリ」）である。ア
クティブ化証明内の鍵のペアは認証可能な「ペルソナ（ｐｅｒｓｏｎａ）」と永
続的に関連付けられ、そのペルソナに対して個人化されているコンテンツを読み
出すように、他のペルソナに対して「完全個人化」されているコンテンツは読み
出さないように、デバイスを「アクティブ化」することができることが好ましい
。ここで使用しているように、「ペルソナ」はユーザに結び付けられる一意的な
識別子であり、帯域外プロセス（ｏｕｔ−ｏｆ−ｂａｎｄｐｒｏｃｅｓｓ）に
よって安全に認証でき、たとえば、セキュアソケットレイヤ（ＳＳＬ）上で使用
するＷｅｂブラウザでのユーザ名とパスワード形式は、このようなプロセスの一
実施例である。さらに、アクティブ化サーバ構成では、ペルソナと関連する認証
（ｃｒｅｄｅｎｔｉａｌ）（たとえば、ユーザ名とパスワード）を認証した後に
限り所定のアクティブ化証明（つまり、特定の鍵のペアを持つアクティブ化証明
）を用意することが好ましい。本発明の特徴によれば、特定のペルソナがアクテ
ィブ化できるデバイスの数は、率および／または数によって制限され（たとえば
、最初の９０日間５回アクティブ化し、その後、９０日の期間ごとにさらにアク
ティブ化し、最大１０回までアクティブ化を行う）、それにより、個人化された
コンテンツをレンダリングできるデバイスの無チェック配布を防止することがで
きる。この手法の一例として、証明書の公開鍵で暗号化された形式でファイルに
埋め込んだライセンス構造（ｌｉｃｅｎｓｅｃｏｎｓｔｒｕｃｔ）を介して対
称鍵自体を提供する場合に、保護されたコンテンツを、対称鍵で暗号化されたコ
ンテンツを含むファイルとして配布することで、アクティブ化証明を不可欠なも
のとし、ライセンスされたコンテンツを対話操作する前に安全なリポジトリを伴
うようにする。

【０００９】配布サーバ構成には、１つまたは複数の小売サーバと１つまたは複数の履行サ
イトが含まれる。小売サーバでは、保護コンテンツを販売する（または他の方法
で保護コンテンツを受け取るユーザを登録する）。履行サイトでは、小売サーバ
によって販売されている実際のコンテンツを提供する。小売サーバの事業者は、
履行サイトの事業者と異なるエンティティであってよく、それにより、小売業者
が単純に契約を交わすだけで保護コンテンツを販売することが可能になり、履行
サイトは小売業者が販売するコンテンツ提供する。これにより、小売業者は、コ
ンテンツを保管したり配布したりする手段に投資せずにコンテンツを販売できる
。一実施例では、小売業者および履行サイトは秘密（たとえば、暗号鍵）を合意
し、小売業者はサーバに、この秘密を使用してコンテンツを購入者に提供するた
めの暗号化された指令を作成するソフトウェアを搭載する。小売業者は、ＨＴＴ
Ｐ要求を購入者に提供することで（たとえば、「受領」または「確認」Ｗｅｂペ
ージのハイパーリンクとしてレンダリングされているＰＯＳＴ要求）購入者が自
分の購入を「履行」できるようにするが、ただし、ＨＴＴＰ要求は履行サイトの
アドレスと暗号化された命令を含む。あるレベルの個人化を必要とするコンテン
ツの場合、暗号化された命令に、個人化情報（たとえば、購入者の名前、または
、「完全個人化」コンテンツの場合、購入者のアクティブ化証明）を含めること
ができる。履行サイトは、購入者がリンクをクリックしたときに暗号化された命
令を受け取り、履行サイトは、共有の秘密情報を使用して、命令を復号し、それ
に従ってコンテンツを提供する。コンポーネントオブジェクトモデル（ＣＯＭ）
オブジェクトを、暗号化された命令を作成する小売業者に提供できる。

【００１０】履行サイトは、履行サーバに１つまたは複数の「ダウンロード」サーバおよび
コンテンツストアを加えたものとして編成できる。コンテンツストアは、消費者
に配布するコンテンツを格納する。履行サーバは、コンテンツ項目の物理的位置
や小売業者から受け取った命令を復号するのに必要な秘密情報（たとえば、暗号
鍵）などのコンテンツ注文の履行に関連する情報のデータベースを保持する。ダ
ウンロードサーバは、コンテンツをコンテンツの消費者／購入者に実際にダウン
ロードする作業およびコンテンツと関連する保護要件を満たすために必要なコン
テンツの準備を実行する（たとえば、ダウンロードサーバは、コンテンツの個人
化を実行できる）。各ダウンロードサーバはキャッシュを備えることができ、ダ
ウンロードサーバは、その項目のダウンロードを処理するためにダウンロードサ
ーバを最初に呼び出したときに（履行サーバデータベースで指定した場所に応じ
て）コンテンツストアからコンテンツ項目のコピーを取得し、ダウンロードサー
バは将来ダウンロードできるようにその項目をキャッシュに格納する。キャッシ
ュには、それに関連する制限がある場合があり、「最近最も使用していない」ア
ルゴリズムなどのアルゴリズムに基づいてキャッシュから項目を失効させる。ダ
ウンロードサーバはさらに、ログに記録するために、処理するダウンロードに関
する情報を履行サーバに提供することもできる。ダウンロードサーバは、この情
報をＭＩＣＲＯＳＯＦＴＭＥＳＳＡＧＥＱＵＥＵＥ（ＭＳＭＱ）などの非
同期メッセージ送受信機能を通じてメッセージの形式で伝達することができる。
履行サーバは、情報を「ロギングデータベース」内に情報を格納できる。さらに
、キャッシュに格納されているコンテンツ項目に影響を及ぼす履行サーバに格納
されている情報の更新が行われた場合、履行サーバはメッセージ送受信サービス
を使用して、メッセージをさまざまなダウンロードサーバに送信し、ダウンロー
ドサーバキャッシュ内の項目を無効化することを示す。

【００１１】本発明の他の特徴を以下に説明する。

【００１２】前述の概要、ならびに続く詳細な説明は、添付の図面を併用しながら読むとよ
り深く理解される。本発明を例示するために、図面のいくつかの図を通じて、同
様の参照番号で同様の部品を表しているが、本発明は開示された特定の方法およ
び手段に限定されないことが理解される。

【００１３】（発明の詳細な説明）本発明は、電子コンテンツの処理および配布のためのシステムであって、その
コンテンツを複数のレベルで保護することができるシステムに向けられる。電子
ブックの処理および配布に向けられる本発明の好ましい実施形態を説明するが、
本発明は電子ブックに限定されるものではなく、ビデオ、オーディオ、ソフトウ
ェア実行ファイル、データなどのあらゆるデジタルコンテンツを含むことができ
る。

【００１４】概要電子ブック業界の成功により、あらゆる種類のテキスト資料を取得するための
印象的かつ安全で親しみやすい経験を既存の書籍購入者に提供することが確実に
求められるようになる。このような資料としては、コピープロテクトをほとんど
必要としない「無料」または安価な資料から、包括的な権利保護を必要とする「
特選」電子ブックタイトル（ここでは「ｅＢｏｏｋ」）を挙げることができる。
印刷物に対する現行の配布および小売モデルから電子配布システムへの円滑な以
降を可能にするために、コピープロテクトを必要とする出版物に対する高レベル
のコピープロテクトを確保しながら、より低レベルの保護を必要とするタイトル
の配布をサポートするためのインフラストラクチャが存在しなければならない。

【００１５】本発明のデジタル権利管理（ＤＲＭ）およびデジタルアセットサーバ（ＤＡＳ
）システムは、そのようなインフラストラクチャを有利に提供する。本発明は、
ｅＢｏｏｋを購入するほうがｅＢｏｏｋを「盗む」（例えば不当に複写する）よ
り望ましいものとする。非嵌入ＤＲＭシステムは、著作権侵害リスクを最小限に
抑えながら、ｅＢｏｏｋの形式での販売／配布を増やすことによって著作権侵害
を補う可能性を高める。さらに、本発明は、低コストで迅速に配備することが可
能なシステムを小売店に提供する。

【００１６】ＤＲＭシステムの主たるユーザは、そのＤＲＭシステムを使用および／または
配備して、販売するコンテンツの合法性ならびにコピープロテクトを確保する出
版者および小売店である。そのＤＲＭシステムの典型的なユーザは、従来的な出
版者、「最先端の」出版者および「ハングリー著者」でありうる。従来的な出版
者は、印刷物出版業務からの歳入がｅＢｏｏｋの著作権侵害によって失われるこ
とについて懸念する可能性が大きい。最先端出版者は、必ずしも単発的な著作権
侵害を懸念せず、消費者が購入習慣を発展させるシステムにおいてｅＢｏｏｋ商
取引が最も効果を発揮することを理解しうる。それに対して、自分の著作物の販
売数に見合った収入を得ることになるハングリー著者は、帰属性（例えば著者の
名前が永遠に著作物に付随すること）により大きな関心を示す。

【００１７】以下により詳細に説明するが、本発明のＤＲＭシステムは著作物を保護するこ
とによってその目標を達成しながら、様々な「レベル」の保護をサポートするこ
とによって消費者による正当な利用を可能にする。最も低いレベル（レベル１）
では、コンテンツソースおよび／またはプロバイダは、ライセンスを含まない無
署名かつ無封印の（クリヤテキスト）ｅＢｏｏｋによる無保護を選択することが
できる。次のレベル（レベル２）の保護は、コンテンツが鍵で暗号化および封印
されたことを意味し、その封印はｅＢｏｏｋのタイトルのメタデータの暗号ハッ
シュを使用して行われ（以下参照）、コンテンツを解読するために鍵が必要とさ
れる「ソース封印」である。ソース封印は、メタデータに何らかの変更が加えら
れるとタイトルが使用不能になるため、タイトルを封印した後にコンテンツおよ
び付随するメタデータの改竄を防止するが、ソース封印は、タイトルのコピーの
認証を保証するものではない（すなわち、ソース封印は正当なコピーと不当なコ
ピーを区別するための機構を提供しない）。「ハングリー著者」の場合は、著者
の名前をメタデータに含めて永久にコンテンツに付随させることによって、「ハ
ングリー著者」の帰属目標を満たすことができる。次のレベルの保護（「レベル
３」）は、「個別封印」（または「登録」）である。「個別封印」タイトルは、
メタデータが合法的な購入者に関連する情報（例えばユーザの名称またはクレジ
ットカード番号、取引ＩＤ、または購入取引による受領番号など）を、タイトル
が封印されたときにこの情報を暗号でコンテンツに付随させるように含むｅＢｏ
ｏｋである。このレベルの保護は、不当なコピーの出所を検出することが容易で
あるために、人々がタイトルのコピーを配布するのを防ぐことになる（そして、
購入者に関連する情報を含めてメタデータに何らかの変更が加えられると、必要
な解読鍵を開封することが不可能になるか、または少なくともその可能性が極め
て低くなる）。

【００１８】次のレベルの保護（レベル４）は、「ソース署名」である。ソース署名ｅＢｏ
ｏｋは、（以下により詳細に論述するが、ＰＣ、ラップトップ、パーソナルデジ
タルアシスタント（ＰＤＡ）、ポケットＰＣまたは用途別読取りデバイスのよう
なコンピューティングデバイスによるｅＢｏｏｋの読取りを可能にするユーザア
プリケーションである）「リーダ」によって認証できるタイトルである。認証は
、３つの方法、すなわちｅＢｏｏｋタイトルが信用変換および暗号ツールによっ
て生成されたことを保証する「ツール署名」；やはりコピーのコンテンツ（所有
者は著者であっても著作権保有者であってもよい）の認証を保証するツール署名
ｅＢｏｏｋである「所有者署名」；ならびにそのプロバイダ（コンテンツの出版
者または小売店）の認証を実証するツール署名ｅＢｏｏｋである「プロバイダ署
名」で定められるのが好ましいといえる。「ツール」、所有者およびプロバイダ
は、情報のデジタル署名の作成および検証を促進するために、それぞれ独自の非
対称鍵対を有することができる。タイトルは、（例えばコピーの署名鎖を通じて
）タイトルの配布経路の認証を促進させるプロバイダ署名とソース署名の両方で
あってもよい。最強レベルの保護は、「完全個人化」または「所有者限定」（レ
ベル５）である。「完全個人化」タイトルは、特定のユーザに対して「起動」す
る認証済リーダアプリケーションによってのみ開封可能とすることで、ある人の
リーダ（または複数のリーダ）からその人に対して登録されていないリーダへの
タイトルの移植を防止する。本発明のリーダがレベル５で保護されたタイトルを
開くために、リーダを「起動」させなければならない（すなわち、リーダが内蔵
されるデバイスは、特定の人物に対する起動認証、およびセキュアリポジトリを
有していなければならない）。以下に図８を参照しながら起動の処理について詳
述する。

【００１９】本発明のシステムは、リーダとコンテンツプロバイダとコンテンツソースの間
で情報を共用するためのアーキテクチャ、その情報を用いて様々なレベルでタイ
トルを「封印する」方法、ならびにその情報を構成すべき方法を定めるものでも
ある。これらの選択の可用性は、どのコンテンツをどのユーザに（保護を適用す
る場合は）どの保護を用いて販売するかをコンテンツソースが選定することを可
能にする。リーダによる使用に向けてタイトルに署名および／または封印するた
めに特定の情報を利用することができ、適合可能なリーダ（レベル５の場合は特
定の人物に対して起動されるリーダでありうる）は、タイトルを開封し、ｅＢｏ
ｏｋの読取りを可能にすることができる。

【００２０】ｅＢｏｏｋファイル構造本発明のＤＲＭシステムでは、図１に示されている構造例など、ファイル構造
に組み込むことでコンテンツを保護する。図１を参照すると、ｅＢｏｏｋ１０
は、それ自身暗号化されたかつ／または封印された、鍵（「コンテンツ鍵」）で
暗号化されているブック（または電子コンテンツ）などのテキストであるコンテ
ンツ１６を含む。好ましい実施形態では、鍵は、メタデータ１２の暗号ハッシュ
で封印された、またはレベル５のタイトルの場合、ユーザのアクティブ化証明の
公開鍵で封印されている対称鍵１４Ａである。この鍵は、ｅＢｏｏｋファイル（
図内のＤＲＭストレージ１４）のサブストレージセクション内のまたはレベル５
タイトルの場合はライセンス内の別々のストリームとして格納される。（レベル
５タイトルの場合、コンテンツ鍵を別々のストリームとして格納する代わりに、
ストリーム１４Ａはライセンスを含み、これは、タイトルの購入後ユーザが行使
できる権利を定義した構造である。ライセンスを持つタイトルでは、コンテンツ
鍵はライセンス内に含まれる。）ＤＲＭストレージ１４には、さらに、ソースス
トリーム１４Ｂも含まれ、これは、出版社（またはその他のコンテンツソース）
の名前とともにブックプレートストリーム１４Ｃを含み、個別に封印された（レ
ベル３および／またはレベル５）タイトルについて、小売業者が提供する消費者
の名前を含む（たとえば、消費者のクレジットカード情報など、ｅＢｏｏｋ１
０を購入する商業トランザクションの一部として取得できる）。対称鍵１４Ｃを
暗号化かつ／または封印する暗号ハッシュを計算する方法（または鍵を封印する
このような暗号ハッシュを使用する方法）は、信頼できるコンテンツ作成ツール
および信頼できるレンダリングアプリケーションにのみ認識される「秘密情報」
であるのが好ましい。この方法でハッシュを使用すると、ｅＢｏｏｋ１０に付
属するメタデータ１２による改竄を難しくする／阻止することができる。このよ
うな方法がｅＢｏｏｋ１０に対する改竄の抵抗測定基準を備える限り、ｅＢｏ
ｏｋを「封印」するのにどの方法でも使用できることに注意されたい。

【００２１】本発明によれば、メタデータ１２は著作権タグを含むことができ、このタグで
コンテンツソース（たとえば、出版社）によりユーザまたは購入者に付与された
権利を説明する。このようなタグが存在している場合、クライアント（たとえば
、図４に示されているデバイス９０または９２）は、タグに含まれているテキス
トをユーザに表示できる。ｅＢｏｏｋに適用される著作権法をユーザに通告する
活動を用いて普通のユーザがｅＢｏｏｋをコピーしようとするのを思いとどまら
せることができることは理解されるであろう。

【００２２】ＤＲＭシステムアーキテクチャ図２に示すように、本発明を実施するための典型的なシステムは、プロセッサ
２１と、システムメモリ２２と、システムメモリ２２を含むさまざまなシステム
コンポーネントをプロセッサ２１に結合するシステムバス２３を含む従来のパー
ソナルコンピュータまたはネットワークサーバ２０などの形式の汎用コンピュー
タデバイスを含む。システムバス２３は、メモリバスまたはメモリコントローラ
、周辺バス、および各種バスアーキテクチャのいずれかを用いたローカルバスを
含むいくつかの種類のバス構造のいずれかでありうる。システムメモリは、読取
り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含
む。起動時などにパーソナルコンピュータ２０内の要素間で情報を転送するのに
役立つ基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）がＲＯＭ２４に
格納されている。パーソナルコンピュータまたはネットワークサーバ２０は、ハ
ードディスク（不図示）に対する読取りおよび書込みを行うためのハードディス
クドライブ２７、取外し可能磁気ディスク２９に対する読取りまたは書込みを行
うための磁気ディスクドライブ２８、ならびにＣＤ−ＲＯＭまたは他の光媒体の
ような取外し可能光ディスク３１に対する読取りまたは書込みを行うための光デ
ィスクドライブ３０をさらに含むことができる。ハードディスクドライブ２７、
磁気ディスクドライブ２８および光ディスクドライブ３０は、それぞれハードデ
ィスクドライブインターフェース３２、磁気ディスクドライブインターフェース
３３および光ドライブインターフェース３４によってシステムバス２３に接続さ
れる。ドライブ、およびそれらの関連するコンピュータ可読媒体は、コンピュー
タ可読命令、データ構造、プログラムモジュール、およびコンピュータまたはネ
ットワークサーバ２０用の他のデータの不揮発性記憶手段を提供する。ここに示
す例示的な環境ではハードディスク、取外し可能磁気ディスク２９および取外し
可能光ディスク３１が採用されているが、磁気カセット、フラッシュメモリカー
ド、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモ
リ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）などコンピュータによってアクセス
可能なデータを記憶できる他の種類のコンピュータ可読媒体も典型的な動作環境
に使用できることを当業者なら理解するはずである。

【００２３】オペレーティングシステム３５（例えばＷｉｎｄｏｗｓ（登録商標）２０００
、ＷｉｎｄｏｗｓＮＴ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）９５／
９８）、１つまたは複数のアプリケーションプログラム３６、他のプログラムモ
ジュール３７およびプログラムデータ３８を含めて、いくつかのプログラムモジ
ュールをハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４また
はＲＡＭ２５に記憶することができる。ユーザは、キーボード４０やポインティ
ングデバイス４２のような入力デバイスを介して、コマンドおよび情報をパーソ
ナルコンピュータ２０に入力することができる。他の入力デバイス（不図示）と
しては、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディス
ク、スキャナなどを挙げることができる。これらの入力デバイスおよび他の入力
デバイスは、システムバス２３に結合されるシリアルポートインターフェース４
６を介してプロセッサ２１にしばしば接続されるが、パラレルポート、ゲームポ
ート、ユニバーサルシリアルバス（ＵＳＢ）または１３９４高速シリアルポート
のような他のインターフェースによっても接続することができる。モニタ４７ま
たは他の種類の表示装置も、ビデオアダプタ４８のようなインターフェースを介
してシステムバス２３に接続される。モニタ４７に加えて、パーソナルコンピュ
ータは、典型的にはスピーカやプリンタのような他の周辺出力デバイス（不図示
）を含む。

【００２４】パーソナルコンピュータまたはネットワークサーバ２０は、リモートコンピュ
ータ４９のような１つまたは複数のリモートコンピュータに対する論理接続を用
いたネットワーク化環境で動作することができる。リモートコンピュータ４９は
、他のパーソナルコンピュータ、他のネットワークサーバ、ルータ、ネットワー
クＰＣ、ピアデバイスまたは他の共通ネットワークノードであってもよく、図２
にはメモリ記憶デバイス５０しか示されていないが、典型的にはパーソナルコン
ピュータ２０に対して上述した要素の多くまたはすべてを含む。図２に示される
論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワー
ク（ＷＡＮ）５２を含む。そのようなネットワーキング環境は、オフィス、企業
規模のコンピュータネットワーク、イントラネットおよびインターネットにおい
て一般化されている。

【００２５】ＬＡＮネットワーキング環境で使用される場合は、パーソナルコンピュータま
たはネットワークサーバ２０は、ネットワークインターフェースまたはアダプタ
５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング
環境で使用される場合は、パーソナルコンピュータまたはネットワークサーバ２
０は、典型的にはモデム５４、またはインターネットのような広域ネットワーク
５２での通信を確立するための他の手段を含む。モデム５４は、内部モデムであ
っても外部モデムであってもよく、シリアルポートインターフェース４６を介し
てシステムバス２３に接続される。ネットワーク化環境において、パーソナルコ
ンピュータまたはネットワークサーバ２０に対して示されたプログラムモジュー
ル、またはその一部をリモートメモリ記憶装置５０に記憶することができる。こ
こに示すネットワーク接続は例示的なもので、コンピュータ間の通信リンクを確
立する他の手段を使用できることが理解されるであろう。

【００２６】サーバアーキテクチャ図３を参照すると、本発明のＤＲＭシステムを実装する第１のサーバアーキテ
クチャ実施例７０が示されている。サーバアーキテクチャ７０は、たとえば、小
売／流通サイトで実装され配備される。本発明の一実施形態では、サーバアーキ
テクチャ７０のすべてのコンポーネントは、ｅＢｏｏｋ１０を小売し、かつｅ
Ｂｏｏｋｓ１０を実際に顧客の読み取りデバイスにダウンロードする作業を実行
する単一の当事者（たとえば、大規模電子書店）と関連付けられる。本発明の他
の実施形態では、書店サーバ７２およびＵＲＬ暗号化ＣＯＭオブジェクト７４は
一方の当事者（たとえば、ダウンロードを実行しないｅＢｏｏｋｓ１０の小売
業者）と関連付け、サーバアーキテクチャ７０の他のコンポーネントは第２の当
事者（たとえば、「履行ハウス」）と関連付け、第１の当事者が販売／小売する
ｅＢｏｏｋｓ１０のダウンロードを実行する。

【００２７】サーバアーキテクチャ７０によって提供される機能には、ソースｅＢｏｏｋの
暗号化、ターゲットリーダー形式への変換、ユーザに付与される権利を定義する
ライセンス構造の生成（レベル５タイトルで）、出版プロバイダによって規定さ
れている要件（たとえば、保護レベル）に基づくダウンロード前のコンテンツの
封印、およびｅＢｏｏｋタイトルのダウンロードなどがある。このサーバアーキ
テクチャは、さらにこの技術のユーザ（コンテンツプロバイダ、小売業者）がそ
のニーズに従ってシステムを拡張することができる柔軟な構成に対応する機能も
含む。これらの機能には、ファイルＩＤの物理的ファイル位置への動的解決（デ
ータベース検索による）、効率および性能を高めるための最もポピュラーなダウ
ンロードのメモリ内キャッシュ（キャッシュはたとえば最近最も使用していない
アルゴリズムの機能に基づいて項目を失効できる）、および遅延監査／報告およ
び／または請求目的のための各ダウンロードファイルの非同期ロギング（データ
ベースに対しても）がある。他の機能は、本発明によりサーバアーキテクチャ７
０によって実行できる。

【００２８】書店サーバ７２は、図２に示されているコンピュータ２０などのネットワーク
サーバ上に実装されたＭｉｃｒｏｓｏｆｔ（登録商標）ＩｎｔｅｒｎｅｔＩ
ｎｆｏｒｍａｔｉｏｎＳｅｒｖｅｒ（ＩＩＳ）サーバである。書店サーバ７２
は、Ｗｅｂブラウズソフトウェアを介してユーザと通信することができ（たとえ
ば、ＭＩＣＲＯＳＯＦＴＩＮＴＥＲＮＥＴＥＸＰＬＯＲＥＲブラウザやＮＥ
ＴＳＣＡＰＥＮＡＶＩＧＡＴＯＲブラウザを使用して表示できるＷｅｂページ
を提供することにより）。この通信を通じて、書店サーバ７２を使用すると、ユ
ーザはｅＢｏｏｋタイトルをショッピングし、小売業者との会員関係を確立し、
トランザクションの対価を支払い、購入証明ページ（サーバサイド受領書）にア
クセスすることができる。ＵＲＬ暗号化オブジェクト７４は、書店サーバ７２に
常駐することができる。ＵＲＬ暗号化オブジェクト７４は、書店サーバ７２上で
購入したｅＢｏｏｋ１０に関係するパラメータ・セットを暗号化する。ＵＲＬ
暗号化オブジェクト７４は、書店サーバ７２とＷｅｂコンテンツサーバ７６との
間で共有する秘密情報（たとえば、対称暗号鍵）を使用してこれらのパラメータ
を暗号化できる。たとえば、パラメータは、購入したｅＢｏｏｋの識別、購入者
の名前またはクレジットカード番号またはトランザクションＩＤ（たとえば、レ
ベル３または５のタイトルの場合）などの購入に関する情報、およびタイムスタ
ンプを含むことができる。当業者であれば、上記のパラメータは例であり、本発
明の趣旨と範囲から逸脱することなく異なるパラメータを使用できることは理解
されるであろう。暗号化パラメータは、Ｗｅｂコンテンツサーバ７６を指すＨＴ
ＴＰ要求に含めて、コンテンツサーバ７６が書店サーバ７２で行われた購入を履
行するようにできる。たとえば、ｅＢｏｏｋ１０が購入者によって選択された
後、書店サーバ７２はＰＯＳＴ要求と関連付けられたリンクを含むＷｅｂページ
を購入者の計算デバイスにアップロードでき、その場合、ＰＯＳＴ要求は「ｗｗ
ｗ．ｃｏｎｔｅｎｔ−ｐｒｏｖｉｄｅｒ．ｃｏｍ」などのコンテンツサーバを指
し、ＰＯＳＴの本体には暗号化されたパラメータが格納される。本発明の他の実
施形態では、Ｗｅｂページに用意されたリンクは、「ｈｔｔｐ：／／ｗｗｗ．ｃ
ｏｎｔｅｎｔ−ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｉｓａｐｉ／ｄｓ．ｄｌｌ？ａｃｔ
ｉｏｎ＝ｄｏｗｎｌｏａｄ＆ｖａｌｕｅ＝＜ｅｎｃｒｙｐｔｅｄｐａｒａｍｅ
ｔｅｒｓ＞」などのＧＥＴ要求と関連付けることができるが、この他の実施形態
は一部のブラウザではＵＲＬの許容可能サイズに制限があり（たとえば２キロバ
イト）、暗号化されたパラメータのサイズが制約されるという不利な点を有する
。どのタイプのＨＴＴＰ要求がリンクと関連付けられようと、ユーザはリンクを
たどってダウンロードを開始できる。パラメータは書店サーバ７２とコンテンツ
サーバ７６との間で共有される秘密情報で暗号化されているため、暗号化された
パラメータの発信元が合法的な書店サーバ７２である（たとえば、コンテンツサ
ーバ７６の事業者がダウンロードサービスを提供することに同意したもの）こと
をコンテンツサーバ７６側で検証することが可能である。タイムスタンプが含ま
れている場合、コンテンツサーバ７６はタイムスタンプを使用して、暗号化され
たパラメータが最近生成されたものであることを確認し、それにより、「再生攻
撃」に抵抗することができる（つまり、合法的に購入していないｅＢｏｏｋをダ
ウンロードしようとするユーザによるＨＴＴＰ要求の「スニフィング（ｓｎｉｆ
ｆｉｎｇ）」による）。ＵＲＬ暗号化オブジェクト７４は、サーバサイドＣＯＭ
オブジェクトとして実装するのが好ましく、またＡｃｔｉｖｅＳｅｒｖｅｒ
Ｐａｇｅｓ（ＡＳＰ）を介してインスタンス化するのが好ましい。

【００２９】コンテンツサーバ７６は、ネットワークサーバ（書店サーバ７２と異なるのが
好ましい）上に実装されたＩＩＳサーバであるのが好ましい。書店サーバ７２と
同様に、コンテンツサーバ７６は、図２に示されているコンピュータ２０などの
コンピュータに実装できる。ダウンロードサーバＩＳＡＰＩＥｘｔｅｎｓｉｏ
ｎ７８が提供されるが、これはコンテンツサーバ７６への受信要求を処理する
のが好ましいＩＩＳ拡張ＤＬＬである。ＩＳＡＰＩＤＬＬ７８は、ダウンロ
ード要求の妥当性を確認し、コンテンツストアのプラグインモジュール８８を介
してコンテンツストア８０から適切なｅＢｏｏｋファイル１０を取得し、個別に
コピーを封印し、ｅＢｏｏｋタイトル１０をエンドユーザに返し、非同期メッセ
ージ送受信モジュールを介して履行データベース８４にトランザクションのログ
を記録する役割を持つ。ＭＩＣＲＯＳＯＦＴＭｅｓｓａｇｅＱｕｅｕｅ（Ｍ
ＳＭＱ）独立のクライアント８６は、サーバアーキテクチャ７０（および図４に
示されている後述のサーバアーキテクチャ７０′）で使用できる非同期メッセー
ジ送受信モジュール例である。サーバ間メッセージ（ＭＳＭＱクライアント８６
）の非同期通信にはＭｉｃｒｏｓｏｆｔのＭＳＭＱ技術を使用することが好まし
いが、当業者であれば、蓄積交換メッセージ送受信技術を使用できることは理解
されるであろう。サーバアーキテクチャ７０（およびアーキテクチャ７０′）の
一態様によれば、リアルタイム通信を必要としないすべてのサーバ間メッセージ
送受信は非同期通信パイプラインを使用して実行するため、このような弾力的な
メッセージ送受信技術を使用して高度な信頼性および拡張性を実現することがで
きる。

【００３０】コンテンツストア８０は、大規模なネットワーク接続ファイルシステムまたは
データベース管理システム（または複数のこのようなファイルシステムまたはデ
ータベース管理システム）であるのが好ましい。コンテンツストア８０は、ｅＢ
ｏｏｋｓ１０の注文を履行するときにダウンロードサーバＩＳＡＰＩ７８に
より使用されるＬＩＴタイトル（ｅＢｏｏｋｓ１０）のリポジトリとして使用
される。コンテンツストア８０は、ダウンロードサーバＩＳＡＰＩ７８でによ
ってアクセスできるＵｎｉｖｅｒｓａｌＮａｍｉｎｇＣｏｎｖｅｎｔｉｏｎ
（ＵＮＣ）パスを公開するのが好ましい。セキュリティ上の理由から、コンテン
ツストア８０はファイアウォールの後に置き、インターネットに直接公開しない
ようにするのが好ましい。コンテンツ管理および暗号化ツール８２は、コンテン
ツをＬＩＴ形式（たとえば、ｅＢｏｋｋ１０）に変換する、コンテンツストア
８０上の各ｅＢｏｏｋタイトルを暗号化し封印するなどの機能を実行するコンポ
ーネントである。コンテンツ管理および暗号化ツール８２はさらに、コンテンツ
ストア８０上の各ＬＩＴファイルの物理的位置で履行データベース８４を更新し
、これは、履行データベース８４上の一意的ＩＤにマッピングされる。ツール８
２は、平文ソースファイル（ＬＩＴ、ＯＥＢ、ＨＴＭＬなど）を受け付け、ダウ
ンロードサーバＩＳＡＰＩ７８により後で取得するため、ソース封印されてい
る暗号化ＬＩＴファイル（たとえば、レベル２）を生成する。

【００３１】図４には、本発明による第２のサーバアーキテクチャ７０′が示されている。
サーバアーキテクチャ７０′は、分散モデルであり、３つのデータセンター、つ
まり小売サイト７１、ＤＲＭ＆履行サイト７３、およびアクティブ化サイト７５
を含む。サーバアーキテクチャ７０の場合と同様、コンテンツの小売およびコン
テンツ注文の履行を単一の当事者が実行することができ、あるいは第２の当事者
が第１の当事者によって販売されたｅＢｏｏｋ１０の注文を履行しながら第１
の当事者がｅＢｏｏｋｓ１０を小売することができる。この後者のシナリオで
は、小売サイト７１は第１の当事者と関連付けられ、ＤＲＭ＆履行サイト７３は
第２の当事者と関連付けられる。図４のアーキテクチャの範囲内で、すべてのＷ
ｅｂサーバベースのアプリケーションを仮想ＩＰアドレスの背後にクラスタ化し
、コンテンツサーバをデュアルホーム化（ｄｕａｌ−ｈｏｍｅｄ）するのが好ま
しい。アクティブ化サーバ９４は、アクティブ化証明をエンドユーザのペルソナ
に関連付けるためにＭＩＣＲＯＳＯＦＴ（登録商標）ＰＡＳＳＰＯＲＴ（ＴＭ）
会員システムに依存することが好ましいが、これについては後述する（ＰＡＳＳ
ＰＯＲＴはこの目的に使用できるネームスペース権限の例にすぎない）。

【００３２】サーバアーキテクチャ７０′のコンポーネントについて以下に簡単に説明する
。小売サイト７１と関連付けられている書店サーバ７２は、コンピュータ２０な
どのコンピュータに実装されているネットワークサーバである。書店サーバ７２
では、１１Ｓで動作しているＷＩＮＤＯＷＳ（登録商標）２０００Ａｄｖａｎ
ｃｅｄＳｅｒｖｅｒｓが稼動するのが好ましい。アーキテクチャ７０でのよう
に、これらのサーバは、ユーザがｅＢｏｏｋタイトルのショッピングなどのアク
ションを実行できる商業Ｗｅｂサイトのホストとなり、小売業者との会員関係を
確立し、その取引の対価を支払い、かつ／または購入ページの証明（サーバサイ
ド受領書）にアクセスする。ＵＲＬ暗号化オブジェクト７４は、小売業者サイト
７１に統合するために用意されている。サーバアーキテクチャ７０でのように、
サーバアーキテクチャ７０′のＵＲＬ暗号化オブジェクト７４を書店サーバ７２
上にインストールされているサーバサイドＣＯＭオブジェクトとして実装し、Ａ
ＳＰページを介してインスタンス化することができ、またｅＢｏｏｋ１０の購
入に関するパラメータを暗号化して、コンテンツサーバ７６が暗号化されたパラ
メータの妥当性を確認し、共有秘密情報（たとえば、パラメータを暗号化するた
めに使用する対称鍵）を介して小売業者を認証し、再生攻撃を回避し、エンドユ
ーザにダウンロードするコンテンツを判別する。

【００３３】コンテンツサーバ／ダウンロードサーバ７６は、ＩＩＳが稼動しているＷＩＮ
ＤＯＷＳ（登録商標）２０００ＡｄｖａｎｃｅｄＳｅｒｖｅｒｓであるのが
好ましい。コンテンツサーバ／ダウンロードサーバ７６は、ＤＡＳ履行アプリケ
ーションのコアコンポーネントのホストとなるが、これらはダウンロードサーバ
ＩＳＡＰＩ拡張７８、コンテンツストアプラグインモジュール８８、ライセンス
サーバモジュール７７、および履行パイプラインクライアント８６を含む。

【００３４】上記のように、ダウンロードサーバＩＳＡＰＩＥｘｔｅｎｓｉｏｎ７８は
、コンテンツサーバ７６への受信要求を処理するＩＩＳ拡張ＤＬＬであるのが好
ましい。これは、各ダウンロード要求の妥当性を確認し、個々にコピーを封印し
（必要なときに）、ｅＢｏｏｋｓの完全個人化（つまり、レベル５）コピーのラ
イセンスを要求し、ｅＢｏｏｋタイトルをエンドユーザに返し、ダウンロードト
ランザクションをロギングデータベース９１などのデータベースに記録する役割
を持つ。

【００３５】コンテンツストアプラグインモジュール８８は、ダウンロード要求に含まれる
パラメータ（たとえば、書籍ＩＤおよび書籍ＩＤタイプパラメータ）の組み合わ
せ（つまり、ＵＲＬにアタッチされた暗号化されたパラメータ）に基づき、ダウ
ンロードされるＬＩＴファイル（ｅＢｏｏｋ）のそれぞれのコンテンツストア８
８上の物理的位置を決定する責任のあるＤＬＬであるのが好ましい。プラグイン
モジュール８８はさらに、履行データベース８９から、ダウンロードしたサーバ
ＩＳＡＰＩ拡張ＤＬＬ７８をブートストラップするのに必要な構成情報（たと
えば、ライセンサの秘密鍵と公開鍵証明、小売業者サポート鍵およびその対称鍵
のリストなど）を取り出す。

【００３６】ライセンスサーバモジュール７７は、ダウンロードサーバＩＳＡＰＩ拡張ＤＬ
Ｌ７８のサブコンポーネントである。レベル５保護ＬＩＴファイルのライセン
スを生成し封印する役割を持つ。以下で詳しく述べるように、ライセンスはｅＢ
ｏｏｋタイトルの購入後ユーザが行使できる権利を定める構造である。ライセン
スサーバモジュール７７はさらに、ｅＢｏｏｋのダウンロード先のユーザのアク
ティブ化証明の妥当性を確認し、それぞれのライセンスに履行センタープロバイ
ダの秘密鍵で署名し、これにより後で、リーダー９０または９２がダウンロード
したＬＩＴファイルをこのようなリーダーでアクセスされたときに配布チャネル
を認証できるようにする。リーダーの例については、同時に出願された代理人事
件整理番号ＭＳＦＴ−０１２３で詳述されており、その全体を引用により本発明
に明示的に取り込んでいる。

【００３７】履行パイプラインクライアント８６は、ＭＩＣＲＯＳＯＦＴ（登録商標）Ｍｅ
ｓｓａｇｅＱｕｅｕｅ（ＭＳＭＱ）独立クライアントであるのが好ましく、
ＷＩＮＤＯＷＳ（登録商標）２０００Ｓｅｒｖｅｒ製品ファミリで利用できる
。このコンポーネントは、ダウンロードサーバＩＳＡＰＩ７８と履行データベ
ース８９との間の非同期通信パイプラインを実装する。ＩＳＡＰＩ７８は、各
コンテンツサーバ７６上でローカルのＭＳＭＱクライアント８６にポストされた
メッセージを介して各ダウンロードトランザクションをログに記録し、その後、
履行サーバ８４上でホストされている類似のＭＳＭＱクライアント８６に弾力性
のある形式でそのようなメッセージを蓄積転送する。このパイプラインはさらに
、ＩＳＡＰＩＲＡＭキャッシュ（コンテンツサーバ７６上に配置されている）
上のキャッシュされているエントリを無効化するためにも使用され、その際に、
ローカルでホストされているＭＳＭＱクライアントの同じ集まりを介して履行サ
ーバ８４からＩＳＡＰＩＤＬＬ７８にポストされるメッセージを使用する。

【００３８】サーバアーキテクチャ７０でのように、サーバアーキテクチャ７０′のコンテ
ンツストア８０は、大規模なネットワーク接続ファイルシステムまたはデータベ
ース管理システムであるのが好ましい。注文を履行するときにダウンロードサー
バＩＳＡＰＩ７８によって使用されるＬＩＴタイトルのリポジトリとして使用
される。このサーバでは、ＷＩＮＤＯＷＳ（登録商標）２０００Ａｄｖａｎｃ
ｅｄＳｅｒｖｅｒが稼動し、ダウンロードサーバＩＳＡＰＩＤＬＬによって
アクセスできるＵＮＣパスを公開するのが好ましい。これを行うには、ＤＡＳで
提供している設定アプリケーションを使用する。さらに、コンテンツストア８０
はファイアウォールの背後に置き、Ｗｅｂには公開しないことが好ましい。

【００３９】履行サーバ８４は、ＭＩＣＲＯＳＯＦＴ（登録商標）ＳＱＬ７．０（また
はそれ以降）が稼動するＷＩＮＤＯＷＳ（登録商標）２０００Ａｄｖａｎｃ
ｅｄＳｅｒｖｅｒであるのが好ましい。このサーバは、履行データベース８９
、ロギングデータベース９１、履行パイプラインクライアント８６、および履行
パイプラインＣＯＭオブジェクト８７のホストとなる。履行データベース８４は
、「書籍ＩＤ」と「書籍ＩＤタイプ」の組み合わせをコンテンツストア８０上の
各ＬＩＴファイルの物理的位置にマッピングするテーブルのホストとなる。デー
タベース８４はさらに、書籍タイトル、書籍著者、ＤＲＭ保護レベル、および／
または希望小売価格などの履行に必要と思われる各ＬＩＴファイルに関する情報
を含む。情報の完全な範囲は、各履行センター（たとえば、コンテンツサーバ７
６を運用するエンティティ）のビジネスルール／慣例により異なる場合があるが
、情報は上記の項目を含むのが好ましい。コンテンツ管理プロセスを設計する際
に履行センターで参照として使用できるサンプルエントリを追加するほかに、こ
のデータベースに必要なテーブルおよびストアドプロシージャを作成するコマン
ドラインスクリプトを用意することができる。

【００４０】ロギングデータベース９１を、ダウンロードサーバＩＳＡＰＩＤＬＬ７８
からの各ダウンロードトランザクションをログに記録するために使用する（適宜
後で請求／報告するため）。履行パイプラインクライアント８６は、上述のよう
にコンテンツダウンロードサーバ７６上に存在するＭＩＣＲＯＳＯＦＴ（登録商
標）ＭｅｓｓａｇｅＱｕｅｕｅ（ＭＳＭＱ）独立クライアントであるのが好
ましい。履行パイプラインオブジェクト８７は、受信メッセージがこのサーバ上
の受け入れキューに書き込まれるごとに履行サーバ８４上でホストされているＭ
ＳＭＱ独立クライアントによってトリガされるＣＯＭオブジェクトであるのが好
ましい。履行パイプラインオブジェクト８７は、各ＭＳＭＱメッセージからロギ
ング情報を取り出し、ロギングデータベース９１に書き込み、後でレポートスク
リプトにより使用できる。さらに、履行パイプラインオブジェクト８７は、履行
データベース８９の変更でトリガされ、ダウンロードサーバ７６上でホストされ
ているさまざまなＭＳＭＱ独立クライアント８６に更新／削除情報をプッシュす
る。

【００４１】コンテンツ管理ツール８２は、履行データベース８９に格納されている情報を
管理する役割を持つ。ＬＩＴファイルがコンテンツストア８０に追加されると、
このツールは適切なフィールドを履行データベース８９に書き込み（たとえば、
書籍ＩＤから物理位置へのマッピング）、コンテンツストアプラグインモジュー
ル８８が後で、要求されたＬＩＴファイルを見つけられるようにする。同様に、
変更が加えられた場合（たとえば、ＬＩＴファイルに対するＤＲＭレベルの変更
）、このツールは、履行センター内のコンテンツ管理業務を担当する人（つまり
コンテンツ管理者）がそれらのタスクを実行するためのインタフェースを備える
。

【００４２】履行センター７３は、標準ＩＩＳＣＯＭオブジェクトを介して、すべての関
連する情報を履行データベース８９に書き込み、受信ＬＩＴファイル（ソース封
印コピーとしてすでに暗号化されている）を、プロダクションコンテンツストア
８０のディレクトリ構造を模倣する、ステージングサーバ８３に置くＡＳＰペー
ジのセットを構築することで、コンテンツ管理のタスクを実行することができる
。そこから、ＬＩＴファイルは、たとえば、ＳｉｔｅＳｅｒｖｅｒ２０００
ＣｏｎｔｅｎｔＲｅｐｌｉｃａｔｉｏｎＳｅｒｖｅｒを使用してプロダク
ションコンテンツストアサーバに自動的にレプリケートされる。ステージングサ
ーバ８３は、ＤＡＳシステムを実装するのに必ずしも必要でないが、ＭＩＣＲＯ
ＳＯＦＴ（登録商標）のコンテンツレプリケーションサーバ（ＣＲＳ）などのツ
ールを使用してＬＩＴファイルを履行パートナのネットワークからプロダクショ
ンコンテンツストアサーバにレプリケートするのは好都合なアプローチである。

【００４３】アクティブ化サーバ９４は、各クライアントリーダー（たとえば、ＰＣリーダ
ー９０または専用読み取りデバイス９２）に一意的なセキュアリポジトリおよび
アクティブ化証明書を送る機能を実行する。セキュアリポジトリの例、その例を
実装するシステムと方法については、同時に出願された代理人事件整理番号ＭＳ
ＦＴ−０１２６で詳述されており、その全体を引用により本発明に明示的に取り
込んでいる。セキュアリポジトリおよびアクティブ化証明は、アクティブ化され
たリーダーをオンラインペルソナ（たとえば、ＭＩＣＲＯＳＯＦＴ（登録商標）
ＰＡＳＳＰＯＲＴ（商標）ＩＤ）と関連付け、ユーザが正当に購入したタイト
ルを自分が所有またはペルソナに対してアクティブ化したリーダーのすべてのイ
ンスタンス上で（ただし、非アクティブ化リーダー、またはそのペルソナに対し
てアクティブ化されていないリーダー上ではなく）読み取ることができるように
するが、同じユーザＩＤおよびパスワードを毎回使用してリーダーをアクティブ
化すると想定する。

【００４４】アクティブ化サーバ９４は、ＰＡＳＳＰＯＲＴオブジェクト９６およびアクテ
ィブ化サーバＩＳＡＰＩ拡張ＤＬＬ９８を含む。ＰＡＳＳＰＯＲＴオブジェク
ト９６は、たとえば、ｈｏｔｍａｉｌアカウント（またはその他のＰＡＳＳＰＯ
ＲＴ認証）を使用してエンドユーザを認証するＰＡＳＳＰＯＲＴ（商標）サーバ
に必要なインタフェースを実装する。本発明の態様によれば、このオブジェクト
は、アクティブ化証明を単一ＰＣの代わりにペルソナと関連付け、各ペルソナが
複数のリーダーを使用してレベル５のタイトルを読み取るようにすると都合がよ
い。レベル５タイトルを「ペルソナ」に結びつけることで単一のデバイスに束縛
されていた場合よりも幅広くレベル５タイトルを使用できることは理解されるで
あろうが、ＰＡＳＳＰＯＲＴサーバなどの確立されたネームスペース権限に関し
てペルソナを定義することもまた、ユーザがペルソナとして機能する任意のレベ
ルを使用することが許されている場合に他の手段で存在しうるレベル５タイトル
の無制約の使用を制限することを目標とするために使用される。ＰＡＳＳＰＯＲ
Ｔ認証の場合、特定のユーザに関するペルソナ情報はユーザのＰＡＳＳＰＯＲＴ
認証と関連付けられ、場合によっては、ユーザの電子メールアカウントから自分
のクレジットカード番号まである。したがって、ユーザは、自分のＰＡＳＳＰＯ
ＲＴＩＤとパスワードを大きなグループの人々と共有する可能性がなく、した
がって、必ず、リーダーがアクティブ化されるペルソナは真に、特定のユーザ（
または場合によっては、単一のＰＡＳＳＰＯＲＴアカウントを共有する家族）に
関連付けられる。ＰＡＳＳＰＯＲＴサーバは、この都合のよい機能を実現するこ
とができるネームプスペース権限例であるが、本発明の趣旨と範囲を逸脱するこ
となく他のネームスペース権限を使用できることは理解されるであろう。このよ
うな他の実施形態では、ＰＡＳＳＰＯＲＴオブジェクト９６は、他のネームスペ
ース権限と通信する異なるオブジェクトに置き換える。

【００４５】アクティブ化ＩＳＡＰＩ拡張ＤＬＬ９８は、フロントエンドアクティブ化サ
ーバ上のアクティブ化プロセスと関連するタスクを実行するが、このタスクは、
リーダークライアントによってアップロードされるハードウェアＩＤを受信し、
ハードウェアＩＤに基づく一意のマシンＩＤを作成し、セキュアリポジトリサー
バ１００に要求をポストし、セキュアリポジトリサーバ１００から受け取った各
一意のセキュアリポジトリに署名し、アクティブ化証明を生成し（オプションで
）暗号化し、アクティブ化データベース１０２を更新し、セキュアリポジトリお
よびアクティブ化証明をリーダークライアントの両方にダウンロードするステッ
プを含む。アクティブ化プロセスは、図８と関連してより具体的に後述する。

【００４６】セキュアリポジトリサーバ１００は、データセンター内のファイアウォールの
背後に配置されたスタンドアローンのサーバであるのが好ましい。これらは、ア
クティブ化されるリーダーごとに個人化されたセキュアリポジトリを生成するた
めにアクティブ化サーバ９４によってアクセスされる。これらのサーバは専用で
あるのが好ましく、またソケットインタフェースをアクティブ化サーバ９４に公
開するＷＩＮＤＯＷＳ（登録商標）２０００またはＷＩＮＤＯＷＳＮＴ（登
録商標）サービスを実行するのが好ましい。セキュアリポジトリサービスは、ポ
ストされた一意的なマシンＩＤおよびパスポートＩＤの組み合わせごとに異なる
実行可能ファイルをリンクする。個人化されたセキュアリポジトリを準備するタ
スクは、多くの場合、計算集約的である。したがって、好ましい実施形態では、
アクティブ化トラフィックの予想ボリュームを考慮し、セキュアリポジトリをリ
ーダーにリアルタイムで提供する十分な数のセキュアリポジトリサーバ１００が
ある。

【００４７】アクティブ化データベース１０２は、ＭＩＣＲＯＳＯＦＴ（登録商標）ＳＱＬ
７．０ベースのサーバで、リーダー９０または９２の各エンドユーザに関連する
アクティブ化情報を格納する（ＰＡＳＳＰＯＲＴ（商標）ＩＤに基づく）。こ
のような情報には、マシンＩＤ、アクティブ化されたリーダーの数、最初のアク
ティブ化の日付、各リーダーインストールに対する製品ＩＤ（ＰＩＤ）、ＰＡＳ
ＳＰＯＲＴ（商標）プロファイル情報などがある。この情報は、ユーザがシステ
ムを悪用しないようにする、ユーザがハードディスクドライブのクラッシュから
復旧するのを手助けする、ユーザがハードウェアアップグレード後も購入したコ
ンテンツを読み続けられるように支援するなどのために使用される。たとえば、
アクティブ化されたリーダーの数と特定のＰＡＳＳＰＯＲＴ認証と関連する第１
のアクティブ化の日付を使用して、アクティブ化の回数に制限を課すことができ
る（たとえば、最初のアクティブ化から最初の９０日以内に所定のペルソナに対
しアクティブ化を５回以内とし、追加アクティブ化をそれ以降９０日ごとに許可
し、アクティブ化を最高合計１０回までとする）。このような制限（または他の
タイプの制限）を課すことで、単一のペルソナに対しアクティブ化されているリ
ーダーの無チェック頒布を防止する効果が得られる（最悪の場合、レベル５タイ
トルが数百万台の読み取りデバイスで可読になり、それによって貴重なコンテン
ツの配布を制御するという目標を妨げることになる）。さらに、アクティブ化デ
ータベース１０２内の他の情報により、ユーザはハードウェアアップグレード後
も（または、ハードディスクのクラッシュ後）レベル５タイトルを使用すること
ができ、しかもタイトルやライセンスを再ダウンロードする必要がない。この場
合、ユーザが行うのは、同じＰＡＳＳＰＯＲＴ（商標）ＩＤでアップグレードさ
れた（または修復された）ハードウェア上でリーダーをアクティブ化することだ
けである。

【００４８】アクティブ化データベースサーバ１０２は、ファイアウォールの背後に置くの
が好ましく、セキュアリポジトリサーバが置かれている同じプライベートネット
ワーク上のフロントエンドアクティブ化ＩＩＳサーバからしかアクセスできない
ようにする。オフラインスクリプトを介してアクティブ化データベース１０２の
レプリカにアクセスし、毎日、毎週、毎月のアクティブ化回数、ＰＡＳＳＰＯＲ
Ｔ（商標）ＩＤによるアクティブ化の平均などに関するレポートを生成できる。

【００４９】受領インフラストラクチャ（Receipt Infrastructure）上で簡単に説明したように、本発明のサーバアーキテクチャは、ＵＲＬ暗号化
オブジェクト７４を含み、これがｅＢｏｏｋ１０の販売に関するいくつかのパ
ラメータを暗号化し、暗号化されたパラメータをＵＲＬに含めることができる。
以下は、ＵＲＬ暗号化オブジェクト７４の使用に関するさらに詳しい概要である
。

【００５０】ＵＲＬ暗号化オブジェクト７４を使用すると、実際にＬＩＴファイルを購入者
に提供するエンティティ（たとえば、履行センター）からｅＢｏｏｋｓの販売者
（たとえば、小売業者）を簡単に切り離せる。ＵＲＬ暗号化オブジェクト７４は
、秘密情報（たとえば、対称鍵７５）で購入したｅＢｏｏｋに関する情報を暗号
化することでこの機能を実行し、これを履行センターと小売業者との間で共有す
る。シナリオ例では、小売業者は履行センターとビジネス関係（たとえば、契約
）を交わし、それにより履行センターは実際にはｅＢｏｏｋｓの電子ストックま
たは多数の購入者にｅＢｏｏｋｓをダウンロードするために必要なサーバデバイ
スを持たない小売業者にコンテンツダウンロードサービスを提供することに同意
する。この関係の一部として、小売業者と履行センターは、秘密対称鍵７５につ
いて合意し、これを小売業者サイトのＵＲＬ暗号化オブジェクト７４と履行セン
ターサイトのＩＳＡＰＩ拡張ＤＬＬ７８で使用する。本質的に、小売業者は、
ＵＲＬ暗号化オブジェクト７４と秘密対称鍵７４を使用して、ｅＢｏｏｋの購入
に関する情報を暗号化し、この暗号化された情報をパラメータとして、履行セン
ターサイトを指しているＵＲＬに含める。その後ＵＲＬを購入者のブラウズソフ
トウェア上で「受領ページ」としてレンダリングするが、ただし、「受領」は履
行センターからダウンロードを呼び出すＵＲＬへのハイパーリンクである。ユー
ザがリンクをたどるときに、履行センターは暗号化されたパラメータを受け取り
、共有秘密対称鍵７５を使用してこれを復号する。パラメータは暗号化されてい
るため、小売業者と履行サイトとの間で交換する必要のある秘密情報は、購入者
のサイトに暗号化形式で安全に提供することができるが、それは、購入者が対称
鍵を知ることがないからである（また、おそらく、Ｗｅｂ上で密かに狙っている
人が対称鍵７５にアクセスできないからである）。さらに、履行センターで暗号
化された情報を復号し、ダウンロードに必要な情報を取得するときに、暗号化さ
れたパラメータを適切に作成するために必要な対称鍵７５を持つ小売業者はたぶ
んほかにいないので、情報の適切な復号により、「受領」を正当な小売業者によ
って生成されたものであると認証する。対称鍵７５はこのような通信を可能にす
るため小売業者と履行センターとの間で共有できる秘密情報のタイプの例に過ぎ
ないことに注意すべきである。他の実施形態では、非対称鍵ペアを使用できるか
、または小売業者および履行センターは秘密鍵なし暗号化方法について合意でき
る。

【００５１】図５は、ＵＲＬ暗号化オブジェクト７４を使用して暗号化されたパラメータを
作成することを示している。ＵＲＬ暗号化オブジェクト７４は、ダウンロードサ
ーバＩＳＡＰＩ７８と小売業者サーバ上のＵＲＬ暗号化オブジェクト７４との間
で共有される対称鍵７５（ＵＲＬ「秘密情報」）を使用してＵＲＬパラメータを
暗号化する。ホストされているシナリオでは、履行センターが多数の小売サイト
で販売しているＬＩＴファイルのダウンロード機能を提供している場合、履行セ
ンター７３と契約を交わすときに対称鍵７５を各小売業者に提供する。この対称
鍵７５は小売業者７１により一意的であることに注意することが重要である。履
行センター７３は、各小売業者の鍵を履行データベース８９に格納することがで
きる。ＵＲＬパラメータの暗号化に使用する対称鍵７５は、ＬＩＴファイルを暗
号化するためにコンテンツ管理および暗号化ツール８２によって生成された対称
鍵１４Ａと異なることに注意されたい。

【００５２】ＵＲＬ暗号化オブジェクト７４に対する単一のエクスポートされる方法（「Ｅ
ｎｃｒｙｐｔ（）」により、暗号化されたＵＲＬパラメータを作成する。Ｅｎｃ
ｒｙｐｔ（）メソッドは、ＵＲＬで使用する暗号化されたｂｌｏｂに取り込む以
下のパラメータを取る。

【００５３】ＴｒａｎｓａｃｔｉｏｎＩＤ−書店サイト７２上の各トランザクションを一意
に識別する文字列。

【００５４】ＢｏｏｋＩＤ−コンテンツストアのプラグインモジュール８８を介して適切な
ＬＩＴファイルを特定するためにダウンロードサーバ７６で使用する一意的な識
別子（履行データベース８４内のＢｏｏｋＩＤを検索する）。

【００５５】ＢｏｏｋＩＤＴｙｐｅ−ＩＤのタイプを識別する（たとえば、ＩＳＢＮ、ＤＯ
Ｉ、ＰＡＴＨなど）。ＵＲＬ暗号化オブジェクト７４は、このフィールド、また
はＩＤとの関係の妥当性を確認しないのが好ましい。ダウンロードサーバＩＳＡ
ＰＩ７８が後で、このフィールドをコンテンツストアプラグインモジュール８
８によって実行される検索への追加入力パラメータとして使用する。

【００５６】ＵｓｅｒＮａｍｅ−購入したｅＢｏｏｋの正当な所有者の名前を含む文字列。
この文字列は、商業取引に使用されるクレジットカード内にリストされている消
費者にマッピングするのが好ましいが、これは、ポリシーとして、履行センター
に従ってコンテンツソース（たとえば、出版社）側で設定するものとして残す。
この文字列は、タイトルを個別に封印する（つまり、ブックプレートを生成する
）ためにダウンロードサーバＩＳＡＰＩ７８によって後で使用される名前であ
る。個人化されたタイトル（たとえば、レベル３およびレベル５）はユーザの名
前をＬＩＴファイルに取り込み、その名前を復号鍵にバインドして、コンテンツ
の無許可配布の発信源を検出できることに注意されたい。したがって、購入者の
名前は、検証不可能なソース（ユーザ入力など）からではなく、信頼できるソー
ス（ユーザのクレジットカードなど）からのものであるのが好ましい。前記の例
では、名前をこのフィールドに挿入すると仮定したが、フィールドの実際の内容
は小売業者によって決定され、いかなる情報をも含めることができるが（たとえ
ば、クレジット番号、トランザクションＩＤ、受領ＩＤなど）、コピーの監視お
よび追跡を可能にする購入または購入者に関係する情報であるのが好ましい。

【００５７】ＰＡＳＳＰＯＲＴＩＤ−アクティブ化の際にユーザによって提供される、ユ
ーザと関連するペルソナＩＤ。このフィールドは、後で、コンテンツサーバによ
って使用され、アクティブ化証明内のアクティブ化ＩＤと比較される。ＰＡＳＳ
ＰＯＲＴＩＤはアクティブ化証明に含まれるが、そのＩＤは購入取引の際に書
店サーバ７２にアップロードされないことに注意されたい。むしろ、アクティブ
化プロセスは、ＰＡＳＳＰＯＲＴＩＤをアクティブ化証明に挿入するほかに、
ＰＡＳＳＰＯＲＴＩＤをユーザの計算デバイスのレジストリにも格納し、これ
は書店サーバ７２に提供されるＰＡＳＳＰＯＲＴＩＤのレジストリインスタン
スである。

【００５８】ＳｅｃｕｒｉｔｙＬｅｖｅｌ−この文字列は、この特定の出版が必要とするＤ
ＲＭのレベルを示す。これは、後で、数値に変換され、ダウンロードサーバＩＳ
ＡＰＩ７８によりタイトルのメタデータ１２にスタンプされる。

【００５９】オプションで、以下の入力パラメータも要求に含めることができる。

【００６０】Ｃｏｓｔ−タイトルが消費者に販売された瞬間にそのｅＢｏｏｋタイトルにつ
いて取引先（つまり小売業者７１）が支払った価格。

【００６１】ＭＳＲＰ−タイトルが販売された時点の出版社からの希望価格。

【００６２】Ｐｒｉｃｅ−ｅＢｏｏｋタイトルが販売された価格。これは、オプションパラ
メータであり、存在する場合は、ログに記録する目的で、場合によっては請求書
を作成する目的で、ダウンロードサーバーによって使用される。

【００６３】ＦｒｉｅｎｄｌｙＦｉｌｅＮａｍｅ−この文字列は、応答ＨＴＴＰヘッダを介
してダウンロードされるＬＩＴファイルのファイル名を設定するときにダウンロ
ードサーバによって使用される。

【００６４】ＣｕｓｔｏｍｅｒＩＤ−ｅＢｏｏｋタイトルを購入するエンドユーザの一意的
識別子。取引先（つまり、小売業者７１）は、履行センターから受け取るレポー
トの一部としてこの情報を必要とする場合がある。

【００６５】上記のパラメータリストは、拡張可能であり、制限またはＵＲＬ暗号化オブジ
ェクト７４によってサポートされる完全なセットと解釈すべきではない。ＵＲＬ
暗号化オブジェクト７４により渡された値のセット全体が暗号化され、呼び出し
側関数に返されるので、追加の属性値対が追加される。

【００６６】ＵＲＬ暗号化オブジェクト７４でタイムスタンプおよびバージョンを追加する
のが好ましい。タイムスタンプは、ＵＲＬ暗号化オブジェクト７４がインストー
ルされているローカルマシン上で１６０１（ＧＭＴシステム時間で）以降に渡さ
れたナノ秒数の表現を含むのが好ましい文字列である。この値は、存続時間（Ｔ
ＴＬ）を計算して再生攻撃（つまり、誰かがＵＲＬを盗んで再生し書籍をダウン
ロードする）を回避するためにダウンロードサーバによって使用される。バージ
ョンフィールドは、ＵＲＬ内の暗号化されたＢＬＯＢを作成したＵＲＬ暗号化オ
ブジェクト７４のバージョンを識別する非暗号化文字列である。

【００６７】小売業者７１がＵＲＬ暗号化オブジェクト７４から暗号化された文字列を取り
戻した後、小売業者７１は履行のためダウンロードサーバ７６を指しているＰＯ
ＳＴ要求を構築する。ＵＲＬ暗号化オブジェクト７４によって返された暗号化さ
れたｂｌｏｂは、各ＰＯＳＴの本文に含まれる。暗号化されたパラメータに加え
て、小売業者は、小売業者を識別するＲｅｔｉａｌＩＤをＵＲＬで提供する必要
がある場合がある。これは、複数の小売業者が単一のダウンロードサーバサイト
７６でサポートされている場合に解読のため着信要求を適切なＵＲＬ対称鍵７５
にマッピングするためにダウンロードサーバＩＳＡＰＩＤＬＬ７８によって
使用される。これは、オプションフィールドであり、用意されていない場合は、
履行サイト７３のダウンロードサーバＩＳＡＰＩＤＬＬ７８は後で、ＵＲＬ
の復号の設定時に用意されたそのデフォルト対称鍵７５を使用する。

【００６８】したがって、上に従って、次のようなＵＲＬ暗号化オブジェクトへの入力を想
定する。ＴｒａｎｓａｃｔｉｏｎＩｄ＝Ｒ６ＲＡＫＨＡＬ９ＴＳＩ２ＪＴＧ００ＱＰ９Ｅ
ＳＴＱ４＆ＢｏｏｋＩｄ＝０４４０２１１４５Ｘ＆ＢｏｏｋＩｄＴｙｐｅ＝Ｉ
ＳＢＮ＆Ｕｓｅｒｎａｍｅ＝Ｐａｖｅｌ＋Ｚｅｍａｎ＆ＳｅｃｕｒｉｔｙＬｅｖ
ｅｌ＝３

【００６９】暗号化ＣＯＭオブジェクト７４は、以下の暗号化ｂｌｏｂを返すことができる
。ＬＣｆｓＱＣＬｕＭｇ９ＵＺｔＷｘＩｄＹＴｆｗ％２ＢｚＭｔｊＸＡＮ％２Ｂｉ
ＵＯＹＨａｏｍｒＹ３ｙｄＸｈｗ３ｐ９ＴｌｗＺｕＨ％２ＢＦＥＨＴＥＰ６８７ＮｑＩ７ｗｂＭＭｗｎｂｔＨＡｋｌｊｋＫｈＫＳ％２Ｂ
ＹＫｗｇＨｊ７％２ＦＮｒ％２ＢｖＢＤＳＯＡＰｗｑＭｂｖＮ３ｓａＮＢｒＰｘＧ８ｓ１ｚｉＵｌｉＸ％２Ｆ％２ＢＳＳ％２Ｆｔｔ
Ａ％２Ｆ４ＧＺｊＲＭｏ５ｕＸＷＭ％２ＢＺｒ５ｄＹＨｋＳｆＷｆＢＢＣＯｉＨ７ｕＬＦｏ１ｙＩｚ８ＬＳＩ＝＆Ｖｅｒｓｉｏｎ＝１．０

【００７０】ＵＲＬ暗号化オブジェクト７４ＵＲＬは、暗号化されたｂｌｏｂをエンコー
ドし、ＡＮＳＩＵＲＬの必要なＨＴＴＰ標準に適合するようにする。ＵＲＬ暗
号化オブジェクト７４は、ＵｎｉｃｏｄｅとＵＴＦ−８文字列の両方を受け付け
、ＵｎｉｃｏｄｅからのＵＴＦ−８変換を内部で処理する。オプションで、ＵＲ
Ｌ暗号化オブジェクト７４は、実装されている場合にＵＴＦ−８を使用し、非Ｕ
ｎｉｃｏｄｅ入力で得られる暗号化されエスケープされたＢＬＯＢのサイズをほ
ぼ１／２に縮小する。ＵＲＬ暗号化オブジェクト７４は、このようなデータを暗
号化する前に暗号化対象のデータの暗号ハッシュ値を計算し、そのハッシュ値を
暗号化されエンコードされたデータ（たとえば、その前に）とともに含める。こ
のハッシュは、後で、ダウンロードサーバによる比較で使用し、小売サイトとダ
ウンロードサーバとの間で復号されたデータが改竄されていないことを検証する
ことができる。たとえば、完全なパラメータ（たとえば、ＰＯＳＴ要求の本文に
含める）は以下のようになる。

【００７１】ＶＡＬＵＥ＝″＆Ｈａｓｈ＝ｂＣｔ／ｘｎ４ｌｆＴＪｗ７ｃＰＱｊｓｔｇｅ＋６
Ｌｉｆｃ＝＆Ｄａｔａ＝ＺＡｙｂＰＫＷｌ２３ｄ２Ｏ＋．．．ｅｎｃｏｄｅｄ＿ｄａｔａ＿ｃｏｎｔｉｎｕｅｓ．．．ＭＳＳＤ
８Ｅｙｗ＝＝＆Ｖｅｒｓｉｏｎ＝１．５″

【００７２】ダウンロードサーバＩＳＡＰＩ７８は、ｅＢｏｏｋタイトルの個人化とエン
ドユーザへのダウンロードを受け持つ。また、ＵＲＬ暗号化オブジェクト７４に
よって生成される各ＵＲＬの構文解析と妥当性確認は、ダウンロードサーバＩＳ
ＡＰＩＤＬＬ７８によって実行される。これは、適切な対称鍵７５を使用し
てＵＲＬを復号する作業を含み、この鍵は、デフォルト鍵であるか、または小売
業者ＩＤが用意されている場合は、コンテンツストアプラグインモジュールを介
してデータベース検索の結果の文字列でよい。ダウンロードサーバＩＳＡＰＩ
ＤＬＬ７８はさらに、渡されたＵＲＬから好ましくはプラグインモジュールを
介してファイル共有の場所にＢｏｏｋＩＤとＢｏｏｋＩＤＴｙｐｅをマッピン
グする動作を解決する。プラグインモジュールは、履行データベースからその情
報を取り出して、コンテンツプロバイダが自分のマッピングデータベースと命名
規約ルールを追加できるようにする。

【００７３】ダウンロードサーバＩＳＡＰＩ７８はさらに、要求されたＬＩＴファイルの
ダウンロードに必要なＤＲＭ保護レベルも決定する。レベルは、ダウンロードさ
れるタイトルのＤＲＭレベルの履行データベース８９からの指示に基づいて決定
される。たとえば、小売業者によって作成されたＵＲＬにより履行データベース
内で指定されているのよりも低いＤＲＭレベルが定義された場合、エラーメッセ
ージが小売業者７１に返される。さらに、ＩＳＡＰＩはコンテンツストア８０か
らローカルメモリキャッシュにダウンロードするためにｅＢｏｏｋタイトルをフ
ェッチし、キャッシュされていなければ、ＩＩＳサーバ上にローカルでキャッシ
ュする前にＬＩＴファイルから対称鍵１４Ａ（図１を参照）をストリップし、後
で使用するためその鍵１４Ａをメモリにキャッシュする。

【００７４】ＤＲＭレベル３タイトルの場合、ダウンロードサーバＩＳＡＰＩ７８はＵＲ
Ｌ暗号化ｂｌｏｂからユーザの名前を別のストリームとしてＬＩＴファイルに挿
入し、この新しいストリームの内容でメタデータを再ハッシュし、新たに計算し
た暗号ハッシュで対称鍵１４Ａを封印し、新たに封印された対称鍵をダウンロー
ドできるようにＬＩＴファイルに再挿入する。ＤＲＭレベル５タイトルの場合、
ダウンロードサーバＩＳＡＰＩはライセンスＸＭＬ構造を生成し（上記のレベル
３アクションに加えて）、エンドユーザのアクティブ化証明からの公開鍵で対称
鍵を封印し、ライセンスをＬＩＴファイル内に埋め込む。

【００７５】ダウンロードサーバＩＳＡＰＩ７８はさらに、ＬＩＴファイルをエンドユー
ザにダウンロードし、ＬＩＴファイルの個人化時に使用した一時記憶領域を解放
し、各ダウンロード要求のログをＩＩＳサーバのローカルファイルまたはロギン
グデータベース９１に記録し、その際に、後述の非同期履行パイプラインを介す
る。これは、各ダウンロードサーバ７６上に常駐するローカルＭＳＭＱクライア
ントへのメッセージポストを介して実行できる。

【００７６】ダウンロードサーバＩＳＡＰＩ拡張ＤＬＬ７８は、「？ａｃｔｉｏｎ＝」パ
ラメータで定義された一組のコマンドに応答する。ダウンロードサーバＩＳＡＰ
Ｉ７８によってサポートされるアクションは、ダウンロードと検証の２つある
のが好ましい。ダウンロードアクションは、ＩＳＡＰＩ７８が図７に示されて
いるステップの後に続き、ｅＢｏｏｋタイトルをエンドユーザに返すコマンドで
ある。検証アクションを使用して、所定のＢｏｏｋＩＤがコンテンツストア８０
内に存在し、ダウンロードの用意ができていることをＩＳＡＰＩ７８が検証す
るよう要求する。_。最も一般的なコマンド（ダウンロード）は、次のＵＲＬの形
である。

【００７７】ｈｔｔｐ：／／ｃｏｎｔｅｎｔ−ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｉｓａｐｉ／ｄ
ｓ．ｄｌｌ？ａｃｔｉｏｎ＝ｄｏｗｎｌｏａｄ＆ｖａｌｕｅ＝．．．

【００７８】ＵＲＬ中の／ｉｓａｐｉ／パラメータは、ＩＳＡＰＩ７８をインストールし
た仮想ルートを示す。この例では、ＩＳＡＰＩ７８はｄｓ．ｄｌｌ（ダウンロ
ードサーバＤＬＬ）と呼ばれている。ＩＳＡＰＩ７８の名前の後にアクション
が続き、さらに、そのアクションを実行する関連するパラメータが続く（上の例
の「ｖａｌｕｅ」パラメータ）。この例では、関連パラメータはＵＲＬ暗号化Ｃ
ＯＭオブジェクト７４によって生成される暗号化ｂｌｏｂを含む。

【００７９】各ダウンロード要求は、ＰＯＳＴの本文に、小売業者サイト７１上のエラー処
理ページのＵＲＬを含む。ダウンロードサーバ７６は、エラーが発生した場合に
このＵＲＬを使用し、クライアントにそのページをリダイレクトし、その際にエ
ラーコードのタグをクエリー文字列内に入れる。エラーが発生した場合、小売業
者はＨＴＭＬＵＩ、サポート番号、電子メールリンク、またはトラブルシュー
ティング命令を送ることができる。本発明の一態様によれば、ダウンロードサー
バＩＳＡＰＩＤＬＬ７８はエラーをレンダリングするのではなく、むしろ、
ユーザをＰＯＳＴ要求から要求されたエラー処理ＵＲＬにリダイレクトするのが
好ましい。

【００８０】データセンター管理と操作性の観点から、ＩＳＡＰＩ７８はパフォーマンス
カウンタ（つまり、ＰｅｒｆＭｏｎカウンタ）とＷＩＮＤＯＷＳＮＴ（登録
商標）イベントを公開する。これらは、サーバコンポーネントのデータセンター
配備および管理のためのＷＩＮＤＯＷＳ（登録商標）２０００およびＷＩＮＤＯ
ＷＳＮＴ（登録商標）の代表的な操作上の慣例である。ＷＩＮＤＯＷＳ（登
録商標）２０００およびＷＩＮＤＯＷＳＮＴ（登録商標）イベントは、エラ
ーが発生するとログに記録される。ＩＳＡＰＩ７８によって好ましくは記録さ
れる重要なイベントとして、以下のものがある。

【００８１】ＦａｉｌｕｒｅｔｏＩｎｉｔｉａｌｉｚｅ（初期化できない）−構成およ
び／または必要な環境設定が見つからず、ＩＳＡＰＩがロードに失敗した。

【００８２】ＦａｉｌｕｒｅｔｏＣｏｎｎｅｃｔｔｏｔｈｅＣｏｎｔｅｎｔＳ
ｔｏｒｅ（コンテンツストアへの接続に失敗）−コンテンツストアプラグインモ
ジュールによって返されたＵＮＣパスが無効であるか、またはコンテンツストア
８０および／またはネットワークパスがダウンしている。いずれの場合も、ＩＳ
ＡＰＩはデータセンター事業者が適切な処置を講じることができるようにエラー
をログに記録する必要がある。

【００８３】ＩｌｌｅｇａｌＵＲＬＲｅｑｕｅｓｔ（不正なＵＲＬ要求）−このイベン
トは、ＵＲＬ要求が予期した形式に従っていないか、またはＩＳＡＰＩ７８と
ＵＲＬＣＯＭオブジェクト７４との理想的には間で共有される対称鍵７５によ
って暗号化されていない場合にログに記録する必要がある。理想的には監査でき
るように発信元ＩＰとともにイベントに関して完全なＵＲＬをポストしなければ
ならない。

【００８４】ＦａｉｌｕｒｅｔｏｌｏｃａｔｅａＬＩＴｆｉｌｅ（ＬＩＴファイ
ルを見つけられない）−要求に対するパスが無効であるか、またはＬＩＴファイ
ルがターゲット共有から欠落している。

【００８５】ＦａｉｌｕｒｅｔｏｃａｃｈｅＬＩＴｆｉｌｅ（ＬＩＴファイルをキ
ャッシュできない）−これは、ＩＳＡＰＩ７８をホストしているコンテンツサ
ーバ７６でメモリが不足した場合、あるいはコンテンツストア８０からファイル
を送信しているときにネットワーク問題が発生した場合に表示されることがある
。

【００８６】ＦａｉｌｕｒｅｔｏｃｒｅａｔｅＢｏｏｋｐｌａｔｅ（ブックプレート
を作成できない）−このイベントは、ＩＳＡＰＩ７８でタイトルの個別封印を
実行できないときにいつでもログに記録する必要がある。後でデバッグできるよ
うに、イベント自体にエラーの種類を含める必要がある。

【００８７】Ｆａｉｌｕｒｅｔｏｄｏｗｎｌｏａｄｔｉｔｌｅ（タイトルをダウンロ
ードできない）−このイベントは、ダウンロードが失敗した（タイムアウト、切
断など）ときにいつでもログに記録する必要がある。

【００８８】Ｓｔａｒｔｕｐ／Ｓｈｕｔｄｏｗｎｅｖｅｎｔｓ（スタートアップ／シャッ
トダウンイベント）−ＩＳＡＰＩ７８を（アン）ロードしたときにはいつでも
、適切な可視性が存在するように情報イベントをこの範囲でログに記録する必要
がある。ＩＳＡＰＩ７８がＩＩＳによってアンロードされ、データセンター事
業者がＩＩＳまたはＷＩＮＤＯＷＳＮＴ（登録商標）さえも再起動し、コン
テンツサーバ７６を完全動作状態に戻す必要がある場合がある。

【００８９】ダウンロードサーバＩＳＡＰＩ７８ではさらに、以下の性能カウンタを公開
するのが好ましい。

【００９０】Ｔｏｔａｌｄｏｗｎｌｏａｄｒｅｑｕｅｓｔｓ（全ダウンロード要求）−
サーバを最後に起動してから受け取った一意的な要求での測定。

【００９１】Ｔｏｔａｌｓｕｃｃｅｓｓｆｕｌｄｏｗｎｌｏａｄｓ（全成功ダウンロー
ド）−サーバを最後に起動してから履行された一意的な要求での測定。

【００９２】Ｄｏｗｎｌｏａｄｒｅｑｕｅｓｔｓ／ｓｅｃ（ダウンロード要求／秒）−一
意的受信要求数／秒。

【００９３】Ｓｕｃｃｅｓｓｆｕｌｄｏｗｎｌｏａｄｓ／ｓｅｃ（成功ダウンロード／秒
）−１秒当たり履行される一意的要求での測定。

【００９４】Ｐｅｎｄｉｎｇｄｏｗｎｌｏａｄｒｅｑｕｅｓｔｓ（保留ダウンロード要
求）−所定の時刻に処理されている要求の総数。

【００９５】Ｆａｉｌｅｄｄｏｗｎｌｏａｄｒｅｑｕｅｓｔｓ（失敗ダウンロード要求
）−サーバを最後に起動した以降の総失敗数。

【００９６】Ａｖｅｒａｇｅｒｅｑｕｅｓｔｐｒｏｃｅｓｓｉｎｇｔｉｍｅ（平均要
求処理時間）−ミリ秒単位で測定し、ＩＳＡＰＩが受信要求を処理するのに要す
る平均時間を反映する。

【００９７】Ｌａｓｔｒｅｑｕｅｓｔｐｒｏｃｅｓｓｉｎｇｔｉｍｅ（最終要求処理
時間）−ミリ秒単位で測定し、ＩＳＡＰＩで一番最近の要求を処理するのに要し
た時間を反映する。

【００９８】ＷＩＮＤＯＷＳＮＴ（登録商標）イベントとＰｅｒｆＭＯＮカウンタを組
み合わせると、既存のデータセンター監視および管理スイートのホストはシステ
ムの配備中にＩＳＡＰＩ７８を管理できる。

【００９９】非同期履行パイプライン非同期履行パイプラインは、ダウンロード要求のログをロギングデータベース
９１に非同期に記録し、ダウンロードサーバＩＳＡＰＩＤＬＬによるキャッシ
ュされたエントリを非同期に無効化する。非同期履行パイプラインサーバは、こ
れらのタスクを実行するのに、ＷＩＮＤＯＷＳ（登録商標）２０００のＭＩＣＲ
ＯＳＯＦＴ（登録商標）ＭｅｓｓａｇｅＱｕｅｕｅ（ＭＳＭＱ）コンポーネン
トにより提供されている既存の蓄積転送機能を活用する。

【０１００】履行パイプラインのアーキテクチャは図４および図６に示されている。履行パ
イプラインオブジェクト８７は、ＭＳＭＱトリガサービスによって実行され、ロ
ーカルＭＳＭＱクライアント８６の受け入れキュー内に受信メッセージが現れる
ごとにロギングデータベースに書き込む。履行パイプラインオブジェクト８７は
、ＣＯＭオブジェクトとして実装するのが好ましい。キャッシュ更新エージェン
ト８５は、履行データベース８９上で更新または削除操作が実行されるといつで
もＳＱＬトリガによって生成される関連実行ファイルを持つ。ダウンロードサー
バＩＳＡＰＩ拡張ＤＬＬ７８は、ローカルＭＳＭＱ独立クライアント８６との
間で読み書き双方を行う。

【０１０１】ロギング機能は、ロギングデータベース９１上で実行し、ダウンロードの各Ｐ
ＯＳＴ要求の本文上で渡されるすべてのパラメータを持続するのが好ましい。履
行パイプラインＣＯＭオブジェクト８７は、各個別ロギングメッセージが履行サ
ーバ８４上のローカルＭＳＭＱ独立クライアント８６の受け入れキュー内に入る
と、履行サーバ８４上でインスタンス化される。ロギングデータベース９１のス
キーマについて以下で詳述する。各ＰＯＳＴ要求の本文からダウンロードサーバ
７６への情報は、ＭＳＭＱメッセージ形式に変換され、履行サーバ８４上のロー
カルＭＳＭＱクライアント８６の受け入れキューにポストされる。

【０１０２】履行サーバ７６上のＭＳＭＱクライアント８６は、その後、このメッセージパ
ケットを選択し、ＭＳＭＱトリガサービスを介して、履行パイプラインＣＯＭオ
ブジェクト８７を呼び出し、メッセージをデータベース形式に変換し、ＣＯＭオ
ブジェクトからロギングデータベースの名前、場所、およびログイン認証を抽出
する履行サーバ８４上のデータソース名（ＤＳＮ）を介してデータベース内に書
き込む。

【０１０３】コンテンツ管理ツール８２が履行データベース８９の記録を更新かつ／または
削除すると、キャッシュ更新エージェント実行可能ファイル８５はＳＱＬサーバ
によってトリガされる（標準のＳＱＬ更新／削除トリガを使用する）。キャッシ
ュ更新エージェント８５は、履行パイプラインＣＯＭオブジェクト８７と似た機
能を実行するが、方向は反対である。履行データベース８９への更新および削除
オペレーションがフロントエンドダウンロードサーバＩＳＡＰＩＤＬＬ７８
へのキャッシュ更新を必要とするとすると、このエージェントはＭＳＭＱメッセ
ージを作成し、独立のＭＳＭＱクライアント８６を介してダウンロードサーバ７
６にポストする（履行サーバ８４は、インストールされているすべてのダウンロ
ードサーバ７６のリストを保持する必要がある）。

【０１０４】キャッシュ更新メッセージを受け取ると、ダウンロードサーバ７６のＭＳＭＱ
クライアント８６はＩＳＡＰＩ拡張ＤＬＬ７８上の関数を呼び出して、キャッ
シュを更新する。このアクションによりキャッシュエントリが削除される。次回
この特定の書籍ＩＤに対する要求を受け取ると、ダウンロードサーバ７６は再び
履行データベース８４にクエリーを実行し、新しいＬＩＴファイルおよび関連属
性でキャッシュを更新する。ダウンロードサーバ７６のキャッシュのサイズは、
物理的サーバ上の空きメモリの量によって決まる。ＩＳＡＰＩＤＬＬ７８で
はサーバ上の使用可能メモリの最大８０％まで割り当てることが好ましい。

【０１０５】ライセンス生成ライセンスはすべての署名および完全個人化タイトル（つまり、レベル５）の
ライセンスを生成することが好ましい。ソース発行も、ソース署名を構成するラ
イセンスを伴い、したがって消費者が購入するｅＢｏｏｋの信頼性が確認される
。ライセンスを委譲することができ、このライセンス連鎖は、出版プロバイダ（
つまり、著者と出版社）から始まり、購入消費者で終わるのが好ましい。本発明
によれば、権利は消費者ではなくライセンサによって委譲するのが好ましい。エ
ンドユーザライセンスは、通常、ダウンロード時に生成される。場合によっては
、小売業者は、ｅＢｏｏｋの正当な所有者を（個別封印の場合）ライセンスで指
名し、これを後で、消費者がｅＢｏｏｋを開いたときにＵＩを介して（リーダー
９０または９２の機能により）公開する。

【０１０６】図４および７を参照すると、ライセンス生成プロセスのプロセスフローが示さ
れている。ステップ１１０で、プロセスが開始し要求（たとえば、暗号化された
ＵＲＬｂｌｏｂで実現された要求）の属性について構文解析が行われる（ステ
ップ１１２）。要求がステップ１１４できちんと作成されている場合、その要求
がレベル５ライセンスに対するものかどうかが判別される（ステップ１１８）。
そうでなければ、ステップ１１６で、エラーが返され、プロセスが停止する。

【０１０７】ステップ１１８で、要求がレベル５ライセンスのものであると判別された場合
、ステップ１２０で、ユーザ原則が提供されたかどうかを判別する。提供されて
いる場合、ステップ１３０でその原則がローカルデータベースに存続する。そう
でなければ、ステップ１２２で、ユーザ原則をローカルデータベースから取り出
すことができるかどうか、判別される。そうでなければ、ステップ１２４で登録
サーバからフェッチされ、成功であれば（ステップ１２６）、ステップ１３０で
データはローカルデータベース内に保持される。ステップ１２６で登録サーバか
らのデータのフェッチ要求が失敗した場合、イベントがログに記録され（ステッ
プ１２８）、ステップ１４６でプロセスが終了する。

【０１０８】ステップ１２２で、ユーザ原則がローカルデータベースから取り出すことがで
きれば、ステップ１３２で処理が継続され、そこで、対称鍵が証明書からのユー
ザの公開鍵で暗号化される。ステップ１３２はさらに、ステップ１３０でユーザ
原則がローカルデータベース内に保持された後も実行される。処理がステップ１
３４に進み、そこで、ライセンスが個人化されているかどうかが判別される。ス
テップ１３４ではさらに、ステップ１１８でレベル５ライセンスの要求でないと
判別された場合に処理が継続する。

【０１０９】ステップ１３４でライセンスが個人化されると、ユーザの名前が正当な所有者
としてライセンスに記述される。ステップ１３６で処理が続行し、そこで、ライ
センスＸＭＬ構造がユーザの名前ありで完了し署名される。ステップ１３４で、
ライセンスは個人化されない場合、処理はステップ１３８で続き、ライセンスＸ
ＭＬ構造は（ユーザの名前なしで）完了し署名される。ステップ１４０で、ライ
センス生成が成功したかどうかが判別される。そうであれば、実行カウンタが更
新され、ライセンスＸＭＬファイルが返され（ステップ１４４）、そうでなけれ
ば、イベントがログに記録され、エラーが返される（ステップ１４２）。その後
処理がステップ１４６で完了する。

【０１１０】ダウンロードが履行センター７３で開始すると（つまり、ユーザが発注し、ダ
ウンロードするリンクをクリックする）、完全個人化タイトルの場合、ダウンロ
ードサーバＩＳＡＰＩＤＬＬ７８は、ライセンスモジュール７７に要求をポ
ストして、ダウンロードするｅＢｏｏｋタイトルの一意的なライセンスを生成す
る。ダウンロード要求ＵＲＬは、暗号化されたパラメータの一部として、ライセ
ンスモジュールが各ライセンスを個別に封印できるように情報を提供する必要が
ある。これらのパラメータは、レベル５のコピーについて、リーダーソフトウェ
アのアクティブ化時にエンドユーザにダウンロードされた暗号化されたアクティ
ブ化証明を含む。ライセンスされたｅＢｏｏｋは、必要なライセンスが存在し、
リーダーから利用できない限り開くことはできない。

【０１１１】ユーザがｅＢｏｏｋデバイスを購入するか、またはリーダーソフトウェア９０
、９２をインターネットからダウンロードした後、最初に起動するときにリーダ
ーをアクティブ化するよう奨励される（たとえば、ラップトップ／デスクトップ
リーダーアプリケーションのセットアップ直後）。アクティブ化により、リーダ
ーソフトウェアで、完全個人化レベル５保護コピーを購入できるようになる。リ
ーダーアクティブ化、エンドユーザの経験、およびクライアントサーバ対話操作
のプロセスフローについて説明する。

【０１１２】リーダー９０または９２を起動するごとに、アクティブ化されたかどうか確認
される。アクティブ化されていなければ、リーダーはダイアログボックスを表示
し、ユーザに、リーダーをアクティブ化しないと配布用の完全個人化を必要とす
るプレミアムタイトルを購入できないことを通知する。ユーザは、スタンドアロ
ーンのブラウザでショッピングしながら小売Ｗｅｂサイトからリーダーをアクテ
ィブ化するか、またはリーダーの「統合書店」機能の中からリーダーをアクティ
ブ化することができる（これにより、汎用ブラウズソフトウェアの代わりにリー
ダーソフトウェア自体を使用して書店サイトと通信できる）。さらに、リーダー
は、リーダーの統合書店機能の内側でショッピングしながらリーダーの取引先の
サイト内からアクティブ化できる。このアクティブ化シナリオは、たとえば、ユ
ーザがリーダーを最初に起動するときにアクティブ化することを望まず、アクテ
ィブ化を必要とする完全個人化（レベル５保護）タイトルを購入したい場合に発
生する。

【０１１３】ユーザが上のようにリーダーをアクティブ化することに同意したと仮定すると
、続くプロセスは、図４および８に関して説明されているように、以下のステッ
プを含む。

【０１１４】ステップ１５０で、リーダークライアントが開いて統合書店機能に入り、セキ
ュアソケットレイヤ（ＳＳＬ）を介して、アクティブ化サーバ９４に接続し、そ
こでユーザは、この例では、ＰＡＳＳＰＯＲＴ（商標）認証を使用してログイン
するよう勧められる（ステップ１５２）。ユーザがＰＡＳＳＰＯＲＴ（商標）ア
カウントを持っていない場合、そのためのサインアップへのリンクが表示される
（ステップ１５４）。アクティブ化サーバ９４へのＵＲＬは、ＳＳＬ接続を使用
してＡｃｔｉｖａｔｉｏｎＡｃｔｉｖｅＸコントロールにハードコーディング
し、サーバが真にアクティブ化サーバ９４であることをクライアントが保証でき
るようにする。

【０１１５】ユーザのＰＡＳＳＰＯＲＴ（商標）認証が証明されたら（ステップ１５６）、
ＰＡＳＳＰＯＲＴＡＰＩでユーザエイリアスと電子メールアドレスについてク
エリが実行される（ステップ１５８）。それ以降、ステップ１６０〜１６２で、
アクティブ化サーバ９４は、クライアントが一意的なハードウェアＩＤを（Ａｃ
ｔｉｖｅＸコントロールを介して）アップロードするよう要求する（たとえば、
上記のように、ユーザの計算デバイスを実質的に一意に識別するユーザの計算デ
バイス上のハードウェアコンポーネントから派生できる）。次に、ステップ１６
４で、これがリーダーに対する新しいアクティブ化であるかどうかを判別する（
前のアクティブ化の「回復」とは反対に）。

【０１１６】ステップ１６４でこれが新しいアクティブ化であると判断されたら、プロセス
はステップ１６８に進み、アクティブ化限界に達したかどうかを判別する。限界
に達している場合、エラーメッセージがステップ１７２で表示されるが、サポー
ト電話番号を含むのが好ましい。プロセスはステップ１９８で完了する。本発明
の機能によれば、ユーザに対し、実行できるアクティブ化回数を制限したり、実
行できる率を制限したりできる（つまり、所定のペルソナのもとで購入したレベ
ル５タイトルを読み込むためにいくつの異なるリーダーをアクティブ化できるか
）。図８の例では、ユーザは、リーダーを最初にアクティブ化してから９０日間
に５回アクティブ化できるように制限されている。これにより、ユーザは、自分
のリーダーをアクティブ化しながら、ＤＡＳシステムの悪用を防止できる。この
ような制限で防止できる悪用の例としては、ＰＡＳＳＰＯＲＴアカウントでｅＢ
ｏｏｋを購入し、数千人の会員がブッククラブのＰＡＳＳＰＯＲＴ認証でリーダ
ーをアクティブ化できるブッククラブがある。アクティブ化に対する制限ではさ
らに、時間の経過とともに追加アクティブ化を許可し、たとえば、最初の９０日
以降９０日期間ごとに１回アクティブ化し、最大合計１０回までのアクティブ化
を許可する。これらの制限は、単なる説明であることは理解されるであろうし、
また本発明の趣旨と範囲を逸脱することなくアクティブ化の制限を使用できる。

【０１１７】ユーザが最初の９０日以内に５つを超えるリーダーをアクティブ化していない
場合（あるいは、異なる適用可能なアクティブ化制限に達している）、アクティ
ブ化ページがユーザのデバイスに表示される（ステップ１７０）。ユーザがフォ
ームを返す場合、アクティブ化サーバは、フォームが完了しているかどうかを判
別し（ステップ１７４）、フォームが完了していない場合、プロセスはステップ
１７０に戻り、ユーザがフォームを完了するまでフォームを再表示する。次に、
ステップ１７６で、このアクティブ化が回復であるかどうかを判別する。回復で
ない場合、ユーザとリーダーに対し新しい記録を作成し、そのユーザに対してア
クティブ化されたリーダーの数を増分する（ステップ１８０）。生成前のセキュ
アリポジトリの鍵ペアをデータベースから取り出し（ステップ１８２）、アクテ
ィブ化証明も生成する（ステップ１８４）。アクティブ化鍵、ユーザＩＤ、およ
びマシンＩＤはステップ１８６でデータベース内に保持される。一実施例では、
各ユーザ（つまり、たとえばＰＡＳＳＰＯＲＴアカウントで識別されるようなペ
ルソナ）に、ユーザがアクティブ化するリーダーごとにアクティブ化証明で使用
されるアクティブ化鍵ペアを割り当て、その場合、レベル５タイトルの対称鍵１
４Ａは履行サイト７３によりそのユーザに対してタイトルを準備したときにアク
ティブ化鍵ペア内の公開鍵で暗号化される。その例をさらに精密化すると、各読
み取りデバイスには、一意的な鍵ペアが関連付けられている一意的な個人化セキ
ュアリポジトリが備えられ、そこで、所定のデバイスのアクティブ化証明に、セ
キュアリポジトリと関連する公開鍵で暗号化されたフォーム内の秘密鍵が含まれ
る。このようにして、レベル５タイトルを表示するために、セキュアリポジトリ
では秘密鍵を使用してアクティブ化証明の秘密鍵を復号し、その後、これを使用
してｅＢｏｏｋタイトルの対称鍵１４Ａを復号し、さらにこれを使用してｅＢｏ
ｏｋタイトルのコンテンツストリーム１６を復号するので、セキュアリポジトリ
とアクティブ化証明の両方が存在している必要がある。処理はステップ１８８で
継続する。

【０１１８】ステップ１７６で、このアクティブ化が回復であると判断された場合、（ステ
ップ１７８で）アクティブ化証明が、ステップ１８６で格納された情報とともに
生成され、処理はステップ１８８に続く。

【０１１９】ステップ１８８で、アクティブ化サーバは個人化したセキュアリポジトリ実行
可能ファイル（アップロードされたマシンＩＤに結び付けられている）とアクテ
ィブ化証明（ユーザのＰＡＳＳＰＯＲＴ（商標）ＩＤに結び付けられている）を
生成し電子署名する。セキュアリポジトリ実行可能ファイルおよびアクティブ化
証明をクライアントにダウンロードする（ステップ１８８および１９０）。アク
ティブ化証明は暗号化され（プライバシー上の理由から）、後で、クライアント
によって、ダウンロードサーバにアップロードされ、完全個人化コピー（レベル
５保護タイトル）の準備をする。ユーザのＰＡＳＳＰＯＲＴ（商標）ＩＤを暗号
化し、このダウンロードの一部としてＰＣレジストリ内にスタンプし、商業取引
時にアップロードできる。この手順により、ダウンロード用のＵＲＬに含まれる
ＰＡＳＳＰＯＲＴ（商標）ＩＤが必ず、Ｐｏｓｔの本文に含まれるアクティブ化
証明のと一致するようになる。

【０１２０】ステップ１９２で、ダウンロードが成功したかどうかが判別される。成功しな
い場合、イベントのログが記録され、ダウンロードを再度試みられる（ステップ
１９４および１９２）。ダウンロードが成功したばあい、ステップ１９６でユー
ザに対し「おめでとございますページ」が表示され、そのアクティブ化が完了し
ていることを通知する。「おめでとうございますページ」はさらに、このときに
販促用の無料書籍を回収するリンクを表示し、ユーザにリーダーをアクティブ化
してもらう手段とする。このリンクは、ＡｃｔｉｖａｔｉｏｎＡｃｔｉｖｅＸ
Ｃｏｎｔｒｏｌで公開しているメソッドを利用して、ユーザをリーダー上のラ
イブラリページに戻すことができる。プロセスはステップ１９８で完了する。

【０１２１】リーダーがアクティブ化サーバ９４に接続した後、サーバ９４がＡＳＰおよび
ＡＴＭＬページを介してユーザの経験全体を推進することが好ましい。これらの
ページは、標準の仕様に適合しているのが好ましく、用意されているスタイルガ
イドおよびＪａｖａ（登録商標）スクリプトのメソッドを使用して、リーダーの
ユーザインタフェースの「ルックアンドフィール」と一致した継ぎ目のない経験
を保証する。

【０１２２】オープンプラットフォームリーダー（たとえば、ＰＣにインストールされてい
るリーダーソフトウェアアプリケーション）のアクティブ化プロセスの一部は、
セキュアリポジトリ個人化および後のダウンロードである。同時に出願され、本
発明に全体を引用して取り込んでいる代理人事件整理番号ＭＳＦＴ０１２６で詳
細に説明されているように、オープンプラットフォーム（たとえば、ラップトッ
プおよびデスクトップコンピュータ）のリーダーの各インスタンスに対しセキュ
アリポジトリソフトウェアモジュールを個人化する役割を持つサーバコンポーネ
ント（たとえば、図４に示されているセキュアリポジトリサーバ１００）が用意
されている。一意的なセキュアリポジトリは、レベル５ＬＩＴファイルの開封
および復号、さらに復号されたレベル５コンテンツが制御されたシステムからエ
スケープしないようにするプロセスで使用される暗号鍵を隠し、特定のハードウ
ェアのインストールに対して個人化されているため、移植性に抵抗があり、破っ
た場合に、その個人化は異なるハードウェアにインストールされた異なるセキュ
アリポジトリで破るのと同じ手法を使用して抵抗する。

【０１２３】上記のように、ＤＲＭシステムの悪用に抵抗するステップの一態様では、特定
のユーザが単一のＰＡＳＳＰＯＲＴ（商標）ＩＤとともに設定されるアクティブ
化の回数を制限する。この数値が制限されていない場合、不正直なユーザは「パ
ブリックドメイン」のＰＡＳＳＰＯＲＴ認証にサインアップし、そのアカウント
の認証を購入したすべてｅＢｏｏｋとともに友人全員と共有できることになる（
さらに悪いのは、Ｗｅｂ上にポストするということである）。これは、「パブリ
ックドメイン」ＰＡＳＳＰＯＲＴ認証でリーダーをアクティブ化するユーザであ
ればその「パブリックドメイン」アカウントに対し個人化されているレベル５タ
イトルを読み出せるため著作権侵害の連鎖をたちまち生み出す。

【０１２４】したがって、本発明の特徴によれば、、同じＰＡＳＳＰＯＲＴ認証に対してリ
ーダーの無チェックの無制限のアクティブ化なしでユーザが所有する複数のデバ
イス（たとえば、ラップトップ、ＰｏｃｋｅｔＰＣ、ｅＢｏｏｋなど）でリーダ
ーをアクティブ化できるとともにハードウェアをアップグレードし、ハードディ
スクを再フォーマットするなどの操作を実行したときに新しいデバイスをアクテ
ィブ化できるアクティブ化「クオータ（quotas）」を設定するのが好ましい。ユ
ーザの行動に関する過去の経験から、合法的なユーザは１つのリーダー（または
少数のリーダー）を最初にアクティブ化し、その後、新しいリーダーをたまにア
クティブ化するが、新しいリーダーを毎日あるいは毎週のように頻繁にアクティ
ブ化することはありえない。悪用を防止しながらこうした合法的なアクティブ化
システムの使用を可能にするために、所定のユーザのアクティブ化回数（ＰＡＳ
ＳＰＯＲＴ（商標）ＩＤ）を定期的に、定義された最大値まで、増やす（たとえ
ば、最初に５回のアクティブ化）。ユーザが新しいデバイスをアクティブ化する
と、使用可能なアクティブ化のクオータは小さくなる。時間がたつうちに、この
数値は、たとえば、（最初のアクティブ化の日付から）９０日ごとに１回のアク
ティブ化の提案頻度で、数値が１０になるまで、増やす。このタイプの制限では
、ユーザは妥当な頻度でリーダーをアクティブ化（またはつまり、再フォーマッ
トしたハードディスクによりデバイス上の古いリーダーを再アクティブ化する）
し、著作権侵害によるシステムの悪用に抵抗する。

【０１２５】アクティブ化サーバ９４により、アクティブ化データベース１０２に、所定Ｐ
ＡＳＰＯＲＴ（商標）が日付スタンプとともに要求されたすべてのアクティブ化
のリストを格納することによりアクティブ化に対する制限を強制する。再アクテ
ィブ化要求を行った場合、マシンＩＤ（たとえば、セキュアリポジトリをリーダ
ーのホストとなっているを結合する一意的な番号）が同じである限りクオータは
影響を受けない（同じＰＣが再びアクティブ化されても盗難が生じないからであ
る）。

【０１２６】ｅＣｏｍｍｅｒｃｅプロセスフローｅＢｏｏｋタイトルを購入しオンラインで納入する基本プロセスの概要につい
て図９を参照しながら説明する。ユーザは、ブラウザまたは「書店ページ」また
はリーダー９０または９２を使用して、小売サイトが実装するメカニズムを介し
て書籍を選択する（ステップ２００）。ユーザは、支払いが必要であればタイト
ルの対価を支払う（ステップ２０２）。取引はステップ２０４で終了し、受領ペ
ージ（つまり、注文確認または「ありがとうございました」ページ）に購入した
各タイトルをダウンロードするためのリンク（ＰＯＳＴ要求）が表示される（つ
まり、コンテンツサーバ７６のアドレスを含むＵＲＬと、ＵＲＬ暗号化オブジェ
クト７４により作成された暗号化情報）。完全個人化コピー（レベル５）につい
ては、クライアント側スクリプトにより、ＰＯＳＴの本文に、アクティブ化証明
が書き込まれるが、その際に、必要なアクティブ化証明または関連情報を取得す
るリーダーによって実装されたＣＯＭオブジェクトを使用するのが好ましい。

【０１２７】ステップ２０６でリンクをどれかクリックすると、ブラウザがコンテンツサ
ーバ７６からダウンロードを開始する（ダウンロードサーバＩＳＡＰＩＤＬＬ
７８を介して）。個人化封印（ブックプレート（たとえば、レベル３））コピ
ーでは、ダウンロードサーバ７６は、消費者の名前をタイトルのメタデータに追
加し、ユーザの名前を含む、新しいメタデータから得られた新しい暗号ハッシュ
を使用して対称鍵１４Ａを再封印する。完全個人化コピー（レベル５）について
は、ブックプレートの作成に加えて、ライセンスを生成し、ＬＩＴファイルに埋
め込む。このライセンスには、アクティブ化証明内に公開鍵とともに「封印」さ
れているＬＩＴファイルを暗号化した対称鍵１４Ａを含む。ダウンロードが完了
すると（ステップ２０８）、ダウンロードサーバ７６は取引のログを記録し、ク
ライアント側では、リーダーが自動的に起動する（ステップ２１０）。タイトル
は、「ＭｙＬｉｂｒａｒｙ」フォルダに移動できる（たとえば、ＭＩＣＲＯＳ
ＯＦＴＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムの１つを使用し
ているＰＣ上で、このようなフォルダは、Ｃ：＼ＭｙＬｉｂｒａｒｙと呼ばれ、
ＬＩＴファイルの格納用に予約される）。ｅＢｏｏｋが開きカバーページを表示
し、正当な所有者の名前が著者名の下に表示される。

【０１２８】ｅＣｏｍｍｅｒｃｅプロセスは、さらにＤＡＳシステムのコンポーネントを特
に参照して、図１０で詳述する。ステップ１で、クライアント９０または９２は
、ダウンロードサーバＩＳＡＰＩＤＬＬ７８へのＰＯＳＴ要求を行う。この
ポスト要求の本文には、最低限、ＵＲＬ暗号化オブジェクト７４で生成される暗
号化されたＢＬＯＢが含まれる。完全個人化コピー（レベル５保護）については
、このポスト要求も、ＸＭＬライセンスを封印するときに必要なアクティブ化証
明が含まれる（以下参照）。

【０１２９】ステップ２で、ＩＳＡＰＩ７８は、ＰＯＳＴの本文から、ＵＲＬを復号する
ためにこの小売業者と関連付けられている対称鍵７５をフェッチするのに必要な
小売業者ＩＤを抽出する。次に、ダウンロード要求を復号し、妥当性の確認を行
う。要求が無効であり、かつ／または計算したＴＴＬが失効した場合（たとえば
、可能な再生攻撃）、ダウンロードサーバは、ブラウザを書店サイトにリダイレ
クトして戻す。書店サイト７１は常に、ＨＴＴＰＲＥＦＲＥＲＥＲサーバ変数
でカプセル化する。このステップで、オプションのわかりやすいファイル名を暗
号化ｂｌｏｂを介して提供できる。この文字列は、返されると、ＩＳＡＰＩによ
り、ＬＩＴタイトルをエンドユーザにダウンロードするときにファイル名として
使用される。

【０１３０】ステップ３で、ＩＳＡＰＩ７８はＢｏｏｋＩＤとＢｏｏｋＴｙｐｅをコンテ
ンツストアプラグインモジュールに渡し、メモリキャッシュエントリ（要求され
ているＬＩＴファイルがすでにダウンロードされている場合）または履行データ
ベース８９の検索に基づいてコンテンツストア上のＬＩＴファイルの物理的場所
を返す。

【０１３１】ステップ４で、ＢｏｏｋＩＤがＩＳＡＰＩ７８のローカルメモリキャッシ
ュ上に見つからない場合、ＬＩＴファイルをコンテンツストア８０から取り出し
、ＩＳＡＰＩのローカルメモリキャッシュにコピーする。ＩＳＡＰＩはＬＩＴフ
ァイルをローカルにキャッシュしたとき、対称鍵１４ＡからＬＩＴファイルをス
トリップし、別のキャッシュバケットに格納し、それぞれのＩＤでインデックス
付けし、セキュリティを高めることができる。

【０１３２】ステップ５で、ＩＳＡＰＩ７８はダウンロードするＬＩＴファイルに必要な
ＤＲＭレベルによる可能な以下のステップのうちの１つを実行する。

【０１３３】要求がＤＲＭレベル１ファイルのものであるか、またはＬＩＴファイルがコン
テンツストア８０に封印されているソースでない場合、ＩＳＡＰＩはエラーを返
し、適切なエラー条件（それぞれ、コンテンツストア内に無効な要求または無効
なタイトルがあること）を示すのが好ましい。

【０１３４】ソース封印（レベル２）タイトルの場合、ＩＳＡＰＩはファイルをエンドユー
ザに返し、何であれファイルに対し処理を行わない。これは、他の静的ファイル
をダウンロードするのと似ている。

【０１３５】個別封印タイトル（レベル３）では、ユーザの名前がＬＩＴファイル内の新し
いストリームに挿入され、メタデータにレベル３のスタンプが押され（リーダー
クライアント９０または９２で使用する）、新しいメタデータがハッシュされ、
ＬＩＴファイルを暗号化するために使用される対称鍵１４Ａが新しい暗号ハッシ
ュ値を計算して封印される。

【０１３６】完全個人化タイトル（レベル５）では、ＩＳＡＰＩ７８は、レベル３につい
て上記の機能を生成するほかに、ライセンスモジュール７７に要求をポストし、
ライセンスＸｒＭＬｂｌｏｂを生成し、履行センターの証明で署名し、エンド
ユーザのアクティブ化公開鍵で封印し、ＬＩＴファイルに埋め込むため返す。

【０１３７】レベル３と５の両方について、すべての処理は、ステップ４で作成した一時メ
モリ空間内で実行される。このメモリ空間については、後で、ダウンロード完了
時にＩＳＡＰＩによって破棄される。

【０１３８】ステップ６で、ＩＳＡＰＩＤＬＬはＬＩＴファイルをＩＩＳサーバ７６にダ
ウンロードのため返す。ステップ３で、コンテンツストアプラグインモジュール
が、「わかりやすい名前」の文字列を返した場合、この値は、ＨＴＴＰヘッダ内
で、ユーザのマシンに記録するファイル名として使用される。

【０１３９】ステップ７で、ＬＩＴファイルがＩＩＳによりＨＴＴＰを介してエンドユーザ
にダウンロードされる。ダウンロードが完了したら、ＩＩＳはＩＳＡＰＩＤＬ
Ｌ７８に呼び戻し、保留要求が履行され、接続が閉じたことを通知するＩＳＡ
ＰＩ７８は、ステップ５で使用されているすべての一時メモリをパージする。

【０１４０】ステップ８で、ＩＳＡＰＩＤＬＬ７８は、非同期履行パイプラインを（ロ
ーカルのＭＳＭＱ独立クライアント８６を介して）使用して取引のログをロギン
グデータベース９１に記録し、後で報告と請求に使用する。さらにこのパイプラ
インを使用して、ＩＳＡＰＩメモリ内のキャッシュエントリを無効化し、コンテ
ンツ管理ツール８２で実行されるコンテンツストア８０への修正により、ＩＳＡ
ＰＩがキャッシュデータを無効化し、プラグインモジュール８８に戻し（その後
コンテンツストア８０に）、無効化されたキャッシュエントリのＬＩＴファイル
を取り出す。

【０１４１】ｅＢｏｏｋタイトルがクライアントにダウンロードされた後（ステップ７の後
）、リーダークライアントを起動できる。これは、リーダーへのＬＩＴのファイ
ル拡張関連付けによって可能である。リーダーは、ファイルをローカルライブラ
リフォルダ（たとえば、「Ｃ：＼ＭｙＬｉｂｒａｒｙ」）に移動し、書籍を開い
てカバーページを表示すると、レベル３タイトルでは、著者名の下に所有者名が
明記されている。

【０１４２】コンテンツ管理機能ＤＲＭ環境内のコンテンツを安全にするステップの１つは、暗号化ツールで生
成された対称鍵１４Ａを使用してソースファイル（ＬＩＴファイル）の事前暗号
処理である。このプロセスにより、ダウンロードサーバ７６は各ＤＲＭレベルの
要件に応じて対称鍵１４Ａを封印することができる。履行センター７３は、既存
のコーディングおよびカタログ作成インフラストラクチャに応じてコンテンツス
トア８０に値を入力する役割を持つ。履行センター７３は、さらに、Ｂｏｏｋ
ＩＤ、ＢｏｏｋＩＤＴｙｐｅ、およびその関連するメタデータを、履行のた
めコンテンツプロバイダのサイトを指している書店をホストする小売業者に伝達
する役割も持つ。

【０１４３】本発明の特徴によれば、ダウンロードサーバ７６と履行センターのコンテンツ
ストアサーバ８０との間に独立の関係がある。小売業者７１によって提供される
ＵＲＬに付属するすべてのＢｏｏｋＩＤ／ＢｏｏｋＩＤＴｙｐｅペアは、
コンテンツストアプラグインモジュール８８を介してＬＩＴファイルへの物理的
パスに解決され、これを、それぞれの履行センター７３でカスタマイズできる。
これにより、コンテンツストアリポジトリだけでなくダウンロードサーバＩＳＡ
ＰＩＤＬＬ７８の柔軟性と拡張性が最大になる。

【０１４４】書店（小売業者）データベースに、特定のコンテンツプロバイダのデータセン
ターのＬＩＴファイルを管理するツールによって生成されたＢｏｏｋＩＤが初
期値として書き込まれる。このプロセスは、非同期に、小売業者７１とコンテン
ツサーバ７６をホストするコンテンツプロバイダ（履行センター）との間の契約
により、実行されると想定している。これらのＩＤは、（ＵＲＬの暗号化された
部分の中の）ＵＲＬを介してダウンロードサーバＩＳＡＰＩＤＬＬ７８に送
られる。

【０１４５】設計上の考慮事項ＤＡＳデータベースで使用しているさまざまなテーブルに対するスキーマの例
を以下で説明する。スキーマの例は、本発明を制限する目的のものと解釈すべき
でなく、他のスキーマも使用可能である。

【０１４６】履行データベース履行データベース例ではテーブルを３つ使用している。これらは、ダウンロー
ド要求を処理するのに必要なすべての情報、ＤＡＳのこの履行インストールを使
用してタイトルを履行できる小売業者に関するすべての情報を含むＤＡＳ＿Ｒｅ
ｇｉｓｔｅｒｅｄ＿Ｒｅｔａｉｌｅｒｓ、および各ＤＡＳインストールパートナ
についてＭｉｃｒｏｓｏｆｔによって提供される必要なライセンサライセンスを
含むＤＡＳ＿Ｌｉｃｅｎｓｏｒ＿Ｃｏｎｆｉｇを含むＤＡＳ＿Ｐｒｏｄｕｃｔテ
ーブルを含む。これらのテーブル間に関係は必要ないが、テーブル関係が必要な
場合、各テーブルの一意の識別子（プライマリキー）を使用する。

【０１４７】ＤＡＳ＿Ｐｒｏｄｕｃｔテーブル ( DASBookID_Path_Mapping_ID int not null IDENTITY(1,1), BookID varchar(256) not null, -- 例「0-201-6
3446-5」 BooklDType varchar(32) not null, -- 例「ISBN」 Title varchar(256) not null, -- 例「類人猿
ターザン」 Publisher varchar(256) not null, -- 例「バラン
タインブックス」 UNCPath varchar(256) not null, -- 例「\\Store
\tarzan.lit」 Price varchar(32) not null, -- 例「6.59」 PriceStructure varchar(32) not null, -- 例「小売」 Currency varchar(10) not null, -- 例「USD」 SecurityLevel varchar(32) not null, -- 例「5」 DateUpdated datetime null DEFAULT (getDate()), -- 行最終更新
時刻 DateCreated datetime null DEFAULT (getDate()) -- 行作成時刻
)

【０１４８】ＤＡＳ＿Ｒｅｇｉｓｔｅｒｅｄ小売業者テーブルこのテーブルには、小売業者ＩＤと履行のためＵＲＬを暗号化／復号するため
に使用する対称鍵７５を計算するときに使用する秘密文字列が格納される。各文
字列は、ＵＲＬＥｎｃｒｙｐｔＣＯＭオブジェクトをインストールするときに
小売業者によって使用される文字列と一致する必要があるが、それが各ダウンロ
ード要求を認証する方法だからである。

【０１４９】 ( DAS_Registered_Retailers_ID int not null IDENTITY (1,
1), retailerID varchar(256) not null, --例「小売
店−１１１−８８８」 retailerName varchar(256) not null, --例「バーン
ズ・アンド・ノーブル」 retailerDesc varchar(4096) not null, -- 例「書籍
小売店」 SharedSecret varchar(256) not null, -- 例「Makin
g_eBooks_Happen」 DateUpdated datetime null DEFAULT (getDate()), DateCreated datetime null DEFAULT (getDate()) )

【０１５０】ＤＡＳ＿Ｌｉｃｅｎｓｏｒ＿Ｃｏｎｆｉｇテーブルこのテーブルには、ダウンロードサーバのライセンスコンポーネントの構成情
報が格納される。サーバが起動すると、ライセンサの証明およびライセンサの秘
密鍵がこのテーブルから読み出され、それを使用して、ＬＩＴファイルに対する
レベル５ライセンスを生成する。この情報は、ＳＱＬサーバ上に格納するのが好
ましいが、それはデータが大きすぎてダウンロードサーバのローカルレジストリ
に格納できず、また普通のファイルに小売業者の秘密鍵を格納した場合小売業者
の秘密鍵が損なわれるおそれがあるというセキュリティ上の問題のためである。
また、ＤＡＳパートナは履行データベース８９内のこのテーブルを修正するだけ
でよく、すべてのダウンロードサーバは変更を選択し（非同期履行パイプライン
とメッセージ送受信コンポーネントを介して）、管理を簡素化するため、ダウン
ロードサーバ構成パラメータに変更を加えるのも容易である。

【０１５１】 ( DAS_Licensor_Config_ID int not null IDENTITY (1,1
), LicensorCertificate varchar(4096) not null, 署名実施許諾
者の証明 LicensorPrivateKey varbinary(350) not null, 実施許諾者の
秘密鍵の２進形態 DateUpdated datetime null DEFAULT (getDate()), DateCreated datetime null DEFAULT (getDate()) )

【０１５２】ロギングデータベースロギングデータベース９１を使用して、すべてのダウンロード要求を記録する
。ダウンロードサーバが要求を処理するときに、非同期履行パイプライン（ＭＩ
ＣＲＯＳＯＦＴ（登録商標）ＭｅｓｓａｇｅＱｕｅｕｅＳｅｒｖｅｒに基づ
く）を使用し、履行データベースサーバに常駐するＣＯＭオブジェクトを介して
、各メッセージをキューからＤＡＳ＿Ｌｏｇテーブルに書き込む。これにより、
ＤＡＳサイトはその履行状況を監査し、ダウンロードが何回実行されたか、いつ
行われたか、最もダウンロード頻度が高いタイトルは何かなどを判別する。この
テーブルはさらに、請求の目的にも使用できる。ロギングデータベースは、ダウ
ンロードされたタイトルからのすべての取引ログ記録を含む単一テーブル（ＤＡ
Ｓ＿Ｌｏｇ）を含む。

【０１５３】（ DAS_Log_ID int not null IDENTITY(1,1), BookId varchar(64) not null, -- 例「0-201-63446-5」 BookIdType varchar(32) not null, -- 例「ISBN」 SecurityLevel varchar(32) not null, -- 例「5」 NameOfFile varchar(256) not null, -- 例「Alice30.lit」 CustomerlD varchar(256) not null, -- 例「34235433」 UserName varchar(256) not null, -- 例「パーベル・ゼー
マン」 TransactionId varchar(256) not null, -- 例「123-456-789」 License varchar(4096) null, -- レベル５の内容の
み−ライセンスのテキスト RetailPrice varchar(32) null, -- 例「$6.59」 Cost varcher(32) null, -- 例「$5.59」 MSRP varcher(32) null, -- 例「$7.59」 DownloadAgent vauchar(256) null, -- 例「Mozzilla」 IPAdress varcher(32) null, -- 例「123.456.789.000
」 DateLogged Datetime null DEFAULD (getDate()) )

【０１５４】アクティブ化データベースアクティブ化データベース１０２は、リーダーをアクティブ化するために必要
なすべての情報と、さらに、アクティブ化サーバを動作させるための構成情報を
ホストする。アクティブ化データベースには５つのテーブルがある。Ｋｅｙ＿Ｐ
ａｉｒｓテーブルは、アクティブ化証明を生成するときに使用する鍵のペアを保
持する。Ｕｓｅｒｓテーブルは、鍵ペアＩＤ（Ｋｅｙ＿Ｐａｉｒｓテーブルへの
リンク）と最初のアクティブ化の日付とともに、アクティブ化された各ユーザの
ＰＡＳＳＰＯＲＴ（商標）認証をホストする。ＵｓｅｒＤｅｖｉｃｅｓは、すべ
てのユーザによってアクティブ化されるすべてのハードウェアＩＤ（つまり、マ
シンＩＤ）のリストである。どのマシンが参照されているかを識別するために、
このテーブルはＵｓｅｒＮｕｍ（Ｕｓｅｒｓテーブル上の各ユーザの内部表現）
とＭａｃｈＩＤ（計算されたマシンＩＤ）に対するプライマリキー制約を持つ。
ＫｅｙＰｔｒは、Ｋｅｙ＿Ｐａｉｒｓテーブルから使用される鍵ペアの数を追跡
する。さらに、次に使用可能な鍵ペアを指している。ＡＳ＿ＤＢ＿Ｃｏｎｆｉｇ
は、データベースおよびアクティブ化サーバ９４の構成要素を保持する。

【０１５５】Ｋｅｙ＿Ｐａｉｒｓテーブル ( ID_Key_Pair int not null UNIQUE IDENTITY (1,1), PublicKey KeyValue not null, PublicKeyXML KeyValue not null, PrivateKey KeyValue not null, BinaryPrivateKey BinKeyValue not null, AssignedToReader tinyint null DEFAULT(0), /* UsersDevices.ID_UsersDeviceへリンク
*/ DateAssigned smaildatetime null DEFAULT (NULL), DateCreated smalldatetime null DEFAULT (getDate()) )

【０１５６】 Users Table ( UserNum int not null UNIQUE IDENTITY (1,1), FullName varchar(60) null, Email varchar(60) null, UserId varchar(60) not null PRIMARY KEY, DateMade smalldatetime null DEFAULT (getDate()), ID_KeyPair int not null )

【０１５７】 UserDevices Table ( UsersDeviceNum int not null UNIQUE IDENTITY(1,1), MachId varchar(255) not null, UserNum int not null, DateRegistered smalldatetime null DEFAULT (getDate()), ID_KeyPair int not null, TimesRegistered int not DEFAULT(0), CONSTRAINT PC_UNQ PRIMARY KEY (UserNum, MachId) )

【０１５８】 KeyPtr Table ( NextKeyToUse int not null )

【０１５９】 AS_DB_Config Table ( /* 空き鍵の個数がこの数値を下回ったときに、スケジュールされたＧ
ｅｎＫｅｙジョブが鍵に追加されている */ MinKeysAvailable int not null, /* 最初にユーザがこの多数のＰＣをアクティブにできる */ ManPCperUser int not null, /* ユーザが上記の限界に達しても、最後のアクティブ化からこの期間
が経過している場合、ユーザはさらに１つ追加し、 */ GrantExtraPCPeriodInDays int not null, /* 同じＰＣを繰り返し再アクティブ化することによるＤＯＳ（denialo
f service；サービス拒否）攻撃を防止する。これは生成中の低い値（たとえば
３）に設定できるが、テストはそれを応力テストのために高に設定できる。 */ MaxSamePCregistrations int not null )

【０１６０】ＬＩＴファイルへのＤＲＭ格納すべてのＬＩＴファイルは、実際には小さなファイルシステムであり、格納要素
とその関連ストリームの集まりで構成される。すべてのＬＩＴファイルのルート
には、ＤＲＩＶＥの専用の格納オブジェクトがある。ＤＲＭ格納オブジェクトの
サブストリームは、ＬＩＴファイルを配布するＤＲＭレベルにより異なる。レベ
ル５保護ＬＩＴファイルでは、データストアに、ｅＢｏｏｋの実際のコンテンツ
が格納され、ＤＲＭＳｔｏｒａｇｅＳｔｏｒｅには、すべてのＤＲＩＶＥ固有
のバイナリデータが格納される。ＤＲＭＳｔｏｒａｇｅＳｔｏｒｅは、Ｖａｌ
ｉｄａｔｉｏｎＳｔｒｅａｍ、ＤＲＭＳｏｕｒｃｅ、およびＤＲＭＳｅａｌｅｄ
ストリーム（ソースおよび個別封印コピー用）を含む。完全個人化タイトルでは
、ＬＩＴファイルも、ライセンスストリームを含み、Ｅｎｄ−Ｕｓｅｒ−Ｌｉｃ
ｅｎｓｅ（ＥＵＬ）を含む。

【０１６１】ライセンスフォーマット完全個人化タイトルのダウンロード毎に使用される例示的なライセンスを以下
に示す。ライセンスは、対称鍵を開封して権利を行使するための要件を定めるの
に加えて、ユーザがタイトルを購入すると行使できる権利を定める構成体である
。ライセンスにおいて表すことが可能な「権利」の例としては、コンテンツの表
示（例えばテキストコンテンツの例では、ＰＣのモニタ上でのその読取り）、コ
ンテンツの印刷、またはコンテンツの一部のコピーおよび貼り付けが挙げられる
。その例示的なライセンスフォーマットは、本発明の範囲を制限することを意図
するものではなく、異なるフォーマットのライセンス情報を有するライセンスで
あるとして、より多くの情報またはより少ない情報を有するほかのライセンスも
可能であることがわかる。

【０１６２】ライセンスを表すのに選択される言語はＸＭＬで、ライセンスフォーマットは
拡張権利マーク付き言語（ＸｒＭＬ）規格に基づいているのが好ましい。これは
、使用権を柔軟に記述するのに好適なマーク付き言語である。ＸｒＭＬは高いイ
ンターオペラビリティに備えるとともに、これらのライセンスを生成して長期間
利用されるように管理するコンポーネントに対するあらゆる技術投資に対応する
ことにもなる。好ましい実施形態では、ライセンスに明記された者だけがライセ
ンスを授与される（すなわち、権利の授与が明記されていない場合は拒否される
）。しかし、拒否または修正がライセンスに明記されていなければ、デフォルト
の権利が想定されるなど、他の仕組みも可能であることを当業者なら理解するで
あろう。

【０１６３】コラプスドフォーマットにおけるトップレベルタグは以下の通りである。 <?xml version="1.0"?> <!DOCTYPE XrML SYSTEM "xrml.dtd"> - <XrML> - <BODY type="LICENSE" version="2.0"> <ISSUED>2000-01-27T15:30</ISSUED> + <DESCRIPTOR> -  -  -  + <WORK> ================================================== ====== Components of the book One chapter, and one image with digest value ================================================== ====== ================================================== ====== Usage rights of the book ================================================== ====== -  -  -  + <LICENSOR> -  -  -  + <LICENSEDPRINCIPALS> </BODY> -  - <!-- =============================================-- > + <SIGNATURE> </XrML>

【０１６４】上記のＸｒＭＬ構造の第一行は、ＸｒＭＬライセンスを作成するのに使用され
るＸＭＬ言語のバージョンを定める。第二行は、ＸＭＬファイルを解析するのに
使用されるＤＴＤファイルの名称を指定する。ＢＯＤＹタグは、ライセンスの種
類、ライセンスが生成されたときに使用されたＸｒＭＬ規格のバージョン、およ
びそれが発行されたときの日付を提示する。それは、ライセンス全体に対するメ
タタグで、以下のサブセクション、すなわちＷＯＲＫ、ＬＩＣＥＮＳＯＲ、ＬＩ
ＣＥＮＳＥＤＰＲＩＮＣＩＰＡＬＳおよびＳＩＧＮＴＵＲＥを有する。ＷＯＲＫ
は、使用権を含めて、ライセンスに関するすべての意味的情報を含む。このフィ
ールドのコンテンツ（タグを含む）は、ハッシュされ署名されたデータを構成す
る。ＬＩＣＥＮＳＯＲは、ライセンスを発行したエンティティ、通常は小売店に
関係する情報を含む。ＬＩＣＥＮＳＥＤＰＲＩＮＣＩＰＡＬＳは、ライセンスに
指定された使用権を行使するときに認証しなければならない一連の原理を含む。
ＳＩＧＮＡＴＵＲＥは、ＬＩＣＥＮＳＥＢＯＤＹのハッシュ／ダイジェスト、な
らびに使用されたアルゴリズムを含めて、ハッシュがどのようにして作成された
かに関する情報を含む。また、それは、ライセンスを発行するときにライセンサ
が名付けたアルゴリズムに従って暗号化されたＤＩＧＥＳＴを含む。ＤＩＧＥＳ
ＴおよびＳＩＧＮＡＴＵＲＥタグは、改善することができないようにしてライセ
ンス全体を検証するのに使用される認証情報を提示する。

【０１６５】ＢＯＤＹタグの構造ＸｒＭＬライセンス構成体の主要タグはＢＯＤＹタグで、以下のタグを含む。 - <BODY type="LICENSE" version="2.0"> <ISSUED>2000-01-27T15:30</ISSUED> - <DESCRIPTOR> - <OBJECT type="self-proving-EUL"> <ID type="MS-GUID">7BD394EA-C841-434d- A33F-5456D5E2AAAE</ID> </OBJECT> </DESCRIPTOR> -  -  - <WORK> - <OBJECT type="BOOK-LIT-FORMAT"> <ID type="ISBN">8374-39384-38472</ID> <NAME>A book of James</NAME> </OBJECT> <CREATOR type="author">James the first</CREATOR> <CREATOR type="author">James the second</CREATOR> - <OWNER> - <OBJECT type="Person"> <ID type="US-SSN">103-74-8843</ID> <NAME>Mike the man</NAME> <ADDRESS type="email">mike@man.com</ADDRE SS> </OBJECT> - <PUBLICKEY> <ALGORITHM>RSA-512</ALGORITHM> - <PARAMETER name="public exponent"> <VALUE encoding="integer32">65537</VAL UE> </PARAMETER> - <PARAMETER name="modulus"> <VALUE encoding="base64" size="512">u+aEb/WqgyO+aDjgYL xwrktqFDR4HZeIeR1g+G5vmKNZRt 9FH4ouePWz/AJYnn2NdxoJ6mcIIAQ Ve6Droj2fxA==</VALUE> </PARAMETER> </PUBLICKEY> </OWNER> -  -  -  -  - <PARTS> - <WORK> - <OBJECT type="Chapter"> <ID type="relative">0</ID> <NAME>Chapter 1</NAME> </OBJECT> </WORK> - <WORK> - <OBJECT type="Image"> <ID type="relative">1</ID> <NAME>Image 1:Photon Celebshots Dogs</NAME> </OBJECT> - <DIGEST sourcedata="LicensorMeta"> <ALGORITHM>SHA1</ALGORITHM> - <PARAMETER name="codingtype"> <VALUE encoding="string">surface- coding</VALUE> </PARAMETER> <VALUE encoding="base64" size="160">OtSrhD5GrzxMeFEm8q 4pQICKWHI=</VALUE> </DIGEST> </WORK> </PARTS> -  -  - <RIGHTSGROUP name="Main Rights"> <DESCRIPTION>Some desc</DESCRIPTION> - <BUNDLE> - <TIME> <FROM time="2000-01-27T15:30"/> <UNTIL time="2000-01-27T15:30"/> </TIME> - <ACCESS> - <PRINCIPAL sequence="2"> - <ENABLINGBITS type="sealed- des-key"> <VALUE encoding="base64" size="512">InHtn/t2dp3u +ZqLkbd7MKOK4xR4YdSX aEvuk2Loh9ZRJEcPzCw+x M7zbPrJb6ESj70+B2fWTcx xDD+6WUB/Lw==</VALU E> </ENABLINGBITS> </PRINCIPAL> </ACCESS> </BUNDLE> - <RIGHTSLIST> - <VIEW> - <ACCESS> - <PRINCIPAL sequence="2"> - <ENABLINGBITS type="sealed-des-key"> <VALUE encoding="base64" size="512">InHtn/t2d p3u+ZqLkbd7MKOK4x R4YdSXaEvuk2Loh9Z RJEcPzCw+xM7zbPrJb 6ESj70+B2fWTcxxDD +6WUB/Lw==</VAL UE> </ENABLINGBITS> </PRINCIPAL> <PRINCIPAL sequence="3"/> </ACCESS> - <ACCESS> - <PRINCIPAL type="licensor"> - <ENABLINGBITS type="sealed-des-key"> <VALUE encoding="base64" size="512">InHtn/t2d p3u+ZqLkbd7MKOK4x R4YdSXaEvuk2Loh9Z RJEcPzCw+xM7zbPrJb 6ESj70+B2fWTcxxDD +6WUB/Lw==</VAL UE> </ENABLINGBITS> </PRINCIPAL> </ACCESS> </VIEW> - <PRINT maxcount="5"> - <FEE> - <MONETARY> - <PERUSE value="5.00"> <CURRENCY iso- code="USD"/> </PERUSE> - <ACCOUNT> <ACCOUNTFROM id="BA-0234- 0928392"/> <HOUSE id="XYZ" uri="http://somehous e.com/payme.asp"/> </ACCOUNT> </MONETARY> </FEE> - <TRACK> <PROVIDERNAME>e- tracker</PROVIDERNAME> <PROVIDERID id="US1023" type="Tracker ID"/> - <PARAMETER name="tracking address"> <VALUE encoding="url">"http://so metrackingservice/trackm e.asp"></VALUE> </PARAMETER> - <PARAMETER name="tracking support address"> <VALUE encoding="url">"http://so metrackingservice/support me.asp"></VALUE> </PARAMETER> </TRACK> - <TERRITORY> <LOCATION country="us" state="CA"city="El Segundo" postalcode="90245"/> <LOCATION country="jp"/> </TERRITORY> </PRINT> </RIGHTSLIST> </RIGHTSGROUP> </WORK> -  -  -  - <LICENSOR> - <OBJECT type="Principal-Certificate"> <ID type="MS-GUID">7BD394EA-C841-434d- A33F-5456D5E2AAAE</ID> <NAME>Barnes and Noble</NAME> </OBJECT> - <PUBLICKEY> <ALGORITHM>RSA-512</ALGORITHM> - <PARAMETER name="public exponent"> <VALUE encoding="integer32">65537</VALUE> </PARAMETER> - <PARAMETER name="modulus"> <VALUE encoding="base64" size="512">u+aEb/WqgyO+aDjgYLxwrk tqFDR4HZeIeR1g+G5vmKNZRt9FH4oueP Wz/AJYnn2NdxoJ6mcIIAQVe6Droj2fxA= =</VALUE> </PARAMETER> </PUBLICKEY> </LICENSOR> -  -  - <LICENSEDPRINCIPALS> - <PRINCIPAL> - <OBJECT type="program"> <ID type="msprogid">XrML.interpreter</ID > <NAME>DRPL INTERPRETER</NAME> </OBJECT> - <AUTHENTICATOR type="drm-module- verifier"> <ID type="microsoft- progid">ms.drm.authenticode</ID> <NAME>DRMAuthenticode</NAME> - <AUTHENTICATIONCLASS> <VERSIONSPAN min="2.0"max="3.4" /> <VERSION>5.0</VERSION> <SECURITYLEVEL>5</SECURITYLE VEL> </AUTHENTICATIONCLASS> - <VERIFICATIONDATA type="signature- key"> - <PUBLICKEY> <ALGORITHM>RSA- 512</ALGORITHM> - <PARAMETER name="public exponent"> <VALUE encoding="integer32">65 537</VALUE> </PARAMETER> - <PARAMETER name="modulus"> <VALUE encoding="base64" size="512">u+aEb/Wqgy O+aDjgYLxwrktqFDR4HZe IeR1g+G5vmKNZRt9FH4o uePWz/AJYnn2NdxoJ6mcII AQVe6Droj2fxA==</VALU E> </PARAMETER> </PUBLICKEY> </VERIFICATIONDATA> </AUTHENTICATOR> </PRINCIPAL> - <PRINCIPAL> - <OBJECT type="MS Ebook Device"> <ID type="INTEL SN">Intel PII 92840- AA9-39849-00</ID> <NAME>Johns Computer</NAME> </OBJECT> - <AUTHENTICATOR type="drminternal- certverify-program"> <ID type="microsoft-progid">2323-2324- abcd-93al</ID> - <AUTHENTICATIONCLASS> <VERSION>1.x-2.5</VERSION> </AUTHENTICATIONCLASS> - <VERIFICATIONDATA type="authenticode- named-root"> - <PUBLICKEY> <ALGORITHM>RSA- 512</<ALGORITHM> - <PARAMETER name="public exponent"> <VALUE encoding="integer32">65 537</VALUE> </PARAMETER> - <PARAMETER name="modulus"> <VALUE encoding="base64" size="512">u+aEb/Wqgy O+aDjgYLxwrktqFDR4HZe IeR1g+G5vmKNZRt9FH4o uePWz/AJYnn2NdxoJ6mcII AQVe6Droj2fxA=</VALU E> </PARAMETER> </PUBLICKEY> </VERIFICATIONDATA> - <VERIFICATIONDATA> - <PARAMETER name="bbid"> <VALUE encoding="string">xxzzy</VAL UE> </PARAMETER> - <PUBLICKEY> <ALGORITHM>RSA- 512</ALGORITHM> - <PARAMETER name="public exponent"> <VALUE encoding="integer32">3< /VALUE> </PARAMETER> - <PARAMETER name="modulus"> <VALUE encoding="base64" size="90">33845URT2039 87==</VALUE> </PARAMETER> </PUBLICKEY> </VERIFICATIONDATA> </AUTHENTICATOR> </PRINCIPAL> - <PRINCIPAL> - <OBJECT tyep="application"> <ID type="MS PROG- ID">43984938476jshd</ID> <NAME>MS Book Reader 2.0</NAME> </OBJECT> - <AUTHENTICATOR type="drminternal-digest- program"> <ID type="microsoft-progid">2323-2324- abcd-93a1</ID> - <AUTHENTICATIONCLASS> <VERSION>1.x-2.5</VERSION> </AUTHENTICATIONCLASS> - <VERIFICATIONDATA type="authenticode- named-root"> - <DIGEST> <ALGORITHM>MD5</ALGORIT HM> <VALUE encoding="base64" size="90">bXIwYXNzd29yZA= =</VALUE> </DIGEST> </VERIFICATIONDATA> </AUTHENTICATOR> </PRINCIPAL> </LICENSEDPRINCIPALS> </BODY>

【０１６６】ライセンス認証前述のように、リーダーセキュアリポジトリは、ＳＩＧＮＡＴＵＲＥおよびＤ
ＩＧＥＳＴタグを介してライセンスを認証する。これは、表示されているコンテ
ンツが信用ソースからのものであることをクライアントソフトウェアが検証でき
るようにしている。これらのタグのより詳細な例を以下に提示する。

【０１６７】 -  - <SIGNATURE> - <DIGEST> <ALGORITHM>SHA1</ALGORITHM> - <PARAMETER name="codingtype"> <VALUE encoding="string">surface- coding</VALUE> </PARAMETER> <VALUE encoding="base64" size="160">OtSrhD5GrzxMeFEm8q4pQICKW HI=</VALUE> </DIGEST> <VALUE encoding="base64" size="512">A7qsNTFT2roeL6eP+IDQFwjIz5XSFBV +NBFOeNa7de+1D6n+MPJa3J7ki8Dmwmuu/pBciQ nJ4xGaqRZ5AYoWRQ==</VALUE> </SIGNATURE>

【０１６８】ＤＲＭシステムのコンテンツソースのシナリオソースコンテンツは、ＯｐｅｎｅＢｏｏｋ（「ＯＥＢ」）形式で配布するの
が好ましく、後で、小売業者が各ターゲットリーダーに合わせてカスタマイズす
る。ＯＥＢ形式は、「ＯｐｅｎｅＢｏｏｋ（商標）Ｐｕｂｌｉｃａｔｉｏｎ
Ｓｔｒｕｃｔｕｒｅ１．０」（１９９９年９月１６日付け）という表題の文書
で規定されており、ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｅｂｏｏｋ．ｏｒｇ／ｓｐ
ｅｃｉｆｉｃａｔｉｏｎ．ｈｔｍから入手でき、本発明では引用によりその全体
を取り込んでいる。

【０１６９】コンテンツソースのシナリオＤＲＭシステムのコンテキストにおいて、ｅＢｏｏｋのコンテンツソース（著
者および／または出版社）は、すぐに販売できるオープンの（つまり、未封印）
または封印されたコピーを提供することが期待されている。後述のサーバによっ
て配布するために、出版社は、最低限、ソースが封印されているコピーを提供す
る必要があるか、または別に、出版社がオプションで、取引先／販売店が履行の
ため暗号化し格納するソースＯＥＢ／ＨＴＭＬファイルを提供することができる
。コンテンツソースは、さらに、履行データベースに初期値入力するために取引
先／販売店によって使用される配布される各タイトルに関する取引先固有の情報
を提供する別のファイル（たとえば、ＸＭＬ、テキスト、データベーススクリプ
トなど）を提供することもできる。このような情報には、目的のＤＲＭレベル、
価格設定、ティーザなどを含めることもできる。

【０１７０】出版社と小売業者との間の信頼関係は技術ではなく契約で維持することが期待
されているので、一般に、出版社と取引先／販売店の間の暗号化および／または
封印タイトルには必要ない。このような関係は、単純な配布に対応する。しかし
、セキュリティを高めることが問題であれば、本発明では、出版社と取引先／販
売店の間で転送するときに暗号化できるタイトルを用意する。

【０１７１】本発明によれば、出版社は移植性のある大容量記憶媒体（ＣＤ、ＤＶＤなど）
、出版社または取引先／販売店サイトのいずれかでのセキュアＨＴＴＰＳ（ＳＳ
Ｌ）、出版社と取引先／販売店サイトの間での安全な専用ネットワーク接続のい
ずれかで配送することで、小売業者にコンテンツを配布することができる。

【０１７２】取引先／販売店のシナリオ複数の非制限配布シナリオについて説明する。これらのシナリオは、消費者へ
の販売の例として示すことを意図しており、本発明を制限する目的はなく、他の
シナリオも可能である。

【０１７３】ソース封印コピーの販売購入顧客がタイトルを選択した後、購入することを望み、注文を完了すること
に決め、取引先は既存の方法により注文を処理する（たとえば、クレジットカー
ドの妥当性確認、請求など）。この場合、ユーザは認証するか（顧客からの会員
記録を必要とするものの場合）または単に注文フォームに記入する必要がある。
取引先は、次に、受領書（電子購入証明書）を生成して購入顧客にダウンロード
する。上記のように、電子受領書は、ユーザが後でコンテンツサーバ７６を指し
ているＵＲＬなどのメカニズムを介して購入済みのタイトルをダウンロードする
ために必要なすべての情報を含むのが好ましく、ＵＲＬ暗号化オブジェクトで生
成された暗号化ＢＬＯＢを含む。ユーザが購入したタイトルをダウンロードする
ために電子受領書に記述されているＵＲＬをクリックすると、そのＵＲＬにリス
トされているサーバ（つまり、履行サーバまたはコンテンツサーバ）が参照タイ
トルを購入者にダウンロードする。コンテンツ／ダウンロードサーバ７６は、注
文が本当にタイトルをダウンロードしようとしているユーザが出したものである
ことを確認できる。

【０１７４】前述のように、ソース封印コピーは、出版社および／または著者の名前および
配布プロセスの一部として取引先に移譲されているその他の権利を消えないよう
にして書き込むことができる。取引先／販売店は、ツールを使用して、ツールに
用意されている対称鍵１４Ａでタイトルを暗号化する。これらの同じツールによ
り、タイトルのメタデータの暗号ハッシュで対称鍵１４Ａを暗号化し、タイトル
内の別のストリームに暗号化された対称鍵１４Ａを埋め込む。リーダーソフトウ
ェアがこれらのタイトルを開いたとき、ツールで使用しているのと同じアルゴリ
ズムを適用して、対称鍵を復号し、それを使用してコンテンツを復号する。この
方法で購入したタイトルはエンドユーザによって簡単に再配布することができる
（たとえば、ＬＩＴファイルをＷｅｂにポストしたり、磁気ディスク２９または
光ディスク３１に保存してディスクを他のユーザに送るなどする）ことに注意し
、また取引先はすべての受領書に不正配布に関する警告を記載するよう推奨する
。この方法で販売されたタイトルの所有者は、出版の一部として著作権情報を含
めるよう奨励される。

【０１７５】個別封印コピーの販売ソース封印コピーと同様に、個別封印コピー（たとえば、レベル３）は、小売
業者がメタデータでタイトルの正当な所有者を指定し、コンテンツの暗号化／復
号に使用する対称鍵１４Ａを所有者の名前を含む新しいメタデータの新しい暗号
ハッシュで封印する必要がある。これは、メタデータを変更しようとする試み（
たとえば、正当な所有者の名前を削除し正当な所有者がコピーを配布し検出をエ
スケープする）があると、間違った暗号ハッシュが得られるため対称鍵１４Ａを
開封する試みは失敗し、メタデータの改竄防止が行われて都合がよい。しかし、
署名なしおよび未封印のコピーのように、またソース封印コピーのように、これ
らのタイトルは前向きのコピー保護にはなっておらず、その代わりに、名前がコ
ピーにバインドされ、コピーの不正配布に従事するユーザを簡単に発見できると
いう抑止効果に依存することにより個別封印コピーで作品中の所有者の権利を保
護する。

【０１７６】シナリオでは、小売業者は一般に、消費者の名前をクレジットに記載されてい
るとおりに、受領（つまり購入証明）ページ／電子メールに記載されている各ダ
ウンロードＵＲＬ上のパラメータとして提供する。この情報は、メタデータにユ
ーザの名前を追加するために履行時にダウンロードサーバ７６によって使用され
る。クレジットカードと関連する名前の使用が好ましいのは、クレジットカード
が盗まれたと仮定すると、ユーザの名前の信頼できるソースであるからであって
、小売業者が提供する名前がたとえばユーザの入力に基づいている場合、ユーザ
がユーザの本当の名前をコピーにバインドするという目標に役立たない偽名を入
力する危険性が高まるからである。

【０１７７】署名コピーの販売署名コピー（たとえば、レベル４）は電子署名を含むタイトルであり、コンテ
ンツソース（著者および／または出版社）によってタイトルの生成時に提供され
ている。これは、ＬＩＴファイル（またはその一部）のデータに流通連鎖内のさ
まざまなエンティティが署名していることで、信頼できるコピーを提供するため
に使用するメカニズムである。レベル４は、他のレベルと組み合わせることがで
き、たとえば、ソース署名とレベル３またはレベル５の個人化のいずれかと組み
合わせ、信頼でき、コピー防止能力のある（またはレベル３コピー「抑止」の場
合）タイトルを作成することが可能である。

【０１７８】完全個人化コピーの販売完全個人化コピーは、履行時に取引先／販売店が常に、エンドユーザのアクテ
ィブ化証明内のエンドユーザの公開鍵に対称鍵１４Ａを暗号化することによりラ
イセンスを封印する必要があるという点で個別封印タイトルと異なる。公開鍵の
信頼性は、アクティブ化証明により証明され、これは、アクティブ化サーバ９４
によって署名される。取引先は、特定の消費者が完全個人化タイトルを最初に購
入したときに署名入りアクティブ化証明を要求できる。オプションにより、ユー
ザが会員でない、または取引先とその他の関係にない場合、取引先はすべての取
引でこのような証明を要求することができる。暗号化されたアクティブ化証明は
、ＤＲＭシステムのクライアントコンポーネントによって小売業者に送られ、こ
れをＷｅｂページでスクリプト化できる。この証明は、暗号化され、消費者のプ
ライバシーを保護するとともに、再生攻撃および／またはハッキングの危険性を
低減できる。取引先は暗号化されたアクティブ化証明を将来の取引のため自社サ
イトに保存することが好ましい。

【０１７９】完全個人化コピーとして販売されているタイトルは、購入消費者のリーダー上
でのみ開くことができ、オープンに配布することはできない。完全個人化タイト
ルを販売するプロセスの一部として、取引先はエンドユーザのリーダーがアクテ
ィブ化されているかどうかを検出するが、これはこのようなタイトルのダウンロ
ードには必須である。リーダーがアクティブ化されていないことを取引先が検出
した場合、取引先は完全個人化タイトルを開くにはアクティブ化が必要であるこ
とをリーダーに通知することができる。取引先が特定のユーザのアクティブ化証
明を格納していないと、そのユーザに対し完全個人化タイトルを提供することさ
え不可能になる。取引先がアクティブ化証明を格納する場合、たとえば、取引先
は、ユーザがタイトルを購入する際に使用するユーザのデバイスにインストール
されているリーダーがアクティブ化されていないことを検出でき、その場合、取
引先はタイトルをユーザに送ることができるが、ユーザに、そのデバイス上でタ
イトルを使用するには新しいデバイスをアクティブ化する必要があることを通知
することができる（もちろん、アクティブ化に対する適用すべき制限を条件とす
る）。

【０１８０】前述の例は単に説明を目的として提示したもので、どの点からしても本発明を
制限するものとして解釈されるべきではないことがわかる。様々な実施形態を参
照しながら本発明を説明したが、ここに用いられている用語は説明および例示に
ついての用語であって、制限についての用語ではないことが理解される。さらに
、ここでは特定の手段、材料および実施形態を参照しながら本発明を説明したが
、本発明はここに開示された特定のものに限定されるのではなく、添付の請求項
の範囲に含まれる機能的に同等のあらゆる構造、方法および用途に広げられる。
本明細書の教示の恩恵を受ける当業者は、それに対する多くの改造を成し遂げる
ことができ、本発明の範囲および主旨から逸脱することなくその態様に変更を加
えることができる。

【図面の簡単な説明】

【図１】電子ブック（ｅＢｏｏｋ）タイトルファイル形式の例である。

【図２】本発明の態様を実装するコンピューティング環境の例を示すブロック図である
。

【図３】本発明によるデジタル権利管理システムの態様を実装する第１のサーバアーキ
テクチャの実施形態のブロック図である。

【図４】本発明によるデジタル権利管理システムの態様を実装する第２のサーバアーキ
テクチャの実施形態のブロック図である。

【図５】本発明の態様によるコンテンツプロバイダサーバ内のいくつかの対話操作を示
すブロック図である。

【図６】本発明の態様による非同期履行パイプラインのコンポーネントを示すブロック
図である。

【図７】本発明の態様によるライセンスを生成するプロセスを示す流れ図である。

【図８】本発明の態様によるクライアントリーダーアクティブ化プロセスを示す流れ図
である。

【図９】本発明の態様によるｅＣｏｍｍｅｒｃｅの流れを示す流れ図およびブロック図
である。

【図１０】本発明の態様によるｅＣｏｍｍｅｒｃｅの流れを示す流れ図およびブロック図
である。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号０９／６０４，５４０ (32)優先日平成12年６月27日(2000．6．27) (33)優先権主張国米国（ＵＳ） (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者パベルゼマンアメリカ合衆国 98033 ワシントン州カークランドノースイースト 108 アベニュー 13116 (72)発明者ビネークリシュナスワミーアメリカ合衆国 98072 ワシントン州ウッディンビルノースイースト 142 プレイス 23319 (72)発明者フランクディー．バイラムアメリカ合衆国 98101 ワシントン州シアトルナンバー 1210 ウェスタンアベニュー 1200 Ｆターム(参考） 5C064 BA01 BC07 CA18 CB01 5J104 AA13 AA16 EA15 PA07 PA10

Claims

【特許請求の範囲】

【請求項１】第１の計算デバイスを使用してコンテンツ項目を第２の計算
デバイスに提供する方法であって、前記第１の計算デバイスで前記第２の計算デバイスからネットワークを介して
通信を受け取るステップであって、前記通信は暗号化情報を含み、前記通信はユ
ニバーサルレコードロケータに基づき前記第２の計算デバイスで開始し、前記ユ
ニバーサルレコードロケータは前記第１の計算デバイスのアドレスと前記暗号化
情報を含むステップと、秘密情報を使用して、前記暗号化情報の少なくとも一部を復号するステップで
あって、前記秘密情報を前記第１の計算デバイスと第３の計算デバイスとの間で
共有するステップと、前記電子コンテンツ項目を復号情報の少なくともいくつかに少なくとも一部は
基づき前記第２の計算デバイスに供給するステップとを備えたことを特徴とする方法。
【請求項２】前記復号情報の少なくとも一部を前記コンテンツ項目に含め
るステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】前記復号情報が前記第２の計算デバイスと関連するユーザに
関する個人情報を含み、前記コンテンツ項目に含まれる少なくなくとも一部の復
号情報は前記個人情報を含むことを特徴とする請求項２に記載の方法。
【請求項４】前記個人情報は名前、クレジットカード番号、または受領書
番号を含むことを特徴とする請求項３に記載の方法。
【請求項５】前記個人情報を使用して前記コンテンツ項目に含まれる少な
くとも一部のデータを封印するステップをさらに備えたことを特徴とする請求項
３に記載の方法。
【請求項６】前記復号情報が第１の暗号鍵を含み、前記コンテンツ項目が
第２の暗号鍵で復号可能な前記第２の暗号鍵とコンテンツを含み、前記の方法は
、前記第１の暗号鍵で前記第２の暗号鍵を暗号化するステップと、暗号化された第２の暗号鍵を前記コンテンツ項目に含めるステップとをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項７】前記暗号情報がタイムスタンプを含み、前記方法は、前記タ
イムスタンプに基づき、前記コンテンツ項目を提供できる時間が期限切れになっ
ていないことを判定するステップをさらに備えたことを特徴とする請求項１に記
載の方法。
【請求項８】前記暗号情報が前記暗号情報のハッシュとともに提供され、
前記ハッシュを前記情報を暗号化する前に計算し、前記方法は、前記ハッシュに
基づき、前記暗号化情報が改竄されたかどうかを判定するステップをさらに備え
たことを特徴とする請求項１に記載の方法。
【請求項９】前記コンテンツ項目に前記コンテンツ項目を使用するように
電子的に強制できるライセンスを含むステップをさらに備えたことを特徴とする
請求項１に記載の方法。
【請求項１０】前記ユニバーサルレコードロケータはＷｅｂページ上のリ
ンクの形で前記第３の計算デバイスによって前記第２の計算デバイスに提供され
、前記通信が前記リンクをたどる前記第２の計算デバイスのユーザによって開始
されることを特徴とする請求項１に記載の方法。
【請求項１１】前記秘密情報は暗号鍵を含むことを特徴とする請求項１に
記載の方法。
【請求項１２】前記暗号鍵は対称鍵を含むことを特徴とする請求項１１に
記載の方法。
【請求項１３】請求項１に記載の方法を実行するコンピュータ実行可能命
令を有することを特徴とするコンピュータ可読媒体。
【請求項１４】電子コンテンツを提供する方法であって、前記方法は、ネットワークを介して、通信を受け取るステップであって、前記通信がユニバ
ーサルレコードロケータを含み、第１の計算デバイスから発信し、前記ユニバー
サルレコードロケータが電子コンテンツ項目に関係する情報を備え、前記情報が
暗号化形式で前記ユニバーサルレコードロケータに含まれるステップと、前記暗号化情報を復号するステップと、前記電子コンテンツ項目を前記情報の少なくともいくつかに少なくとも一部は
基づき前記第１の計算デバイスに供給するステップとを備えたことを特徴とする方法。
【請求項１５】前記電子コンテンツ項目はテキストコンテンツを含むこと
を特徴とする請求項１４に記載の方法。
【請求項１６】前記電子コンテンツ項目はマルチメディアコンテンツを含
むことを特徴とする請求項１４に記載の方法。
【請求項１７】前記ユニバーサルレコードロケータは、前記電子コンテン
ツ項目の販売者によって前記第１の計算デバイスに提供されることを特徴とする
請求項１４に記載の方法。
【請求項１８】前記ユニバーサルレコードロケータはＷｅｂページ上のリ
ンクの形で前記第１の計算デバイスに提供され、前記Ｗｅｂページが前記第１の
計算デバイスから離れている第２の計算デバイスにより前記第１の計算デバイス
に提供されることを特徴とする請求項１４に記載の方法。
【請求項１９】前記情報が前記電気的コンテンツ項目の購入者に関連する
個人情報を含み、前記電子コンテンツ項目が前記個人情報を含むことを特徴とす
る請求項１４に記載の方法。
【請求項２０】前記個人情報は名前、クレジットカード番号、または受領
書番号を含むことを特徴とする請求項１９に記載の方法。
【請求項２１】記憶装置から非個人化コンテンツ項目を取り出すステップ
をさらに備え、前記コンテンツ項目は、第１の暗号鍵で復号可能な暗号化形式によるコンテンツと、メタデータと、前記メタデータで封印された前記第１の暗号鍵とを含み、前記方法は、前記第１の暗号鍵を開封するステップと、前記個人方法を前記メタデータに追加して、新しいメタデータを出力するステ
ップと、前記新規メタデータで前記第１の暗号鍵を再封印して、新規メタデータおよび
再封印された鍵を含む個人化コンテンツ項目を出力するステップとをさらに備え
、前記第１の計算デバイスに送られる前記コンテンツ項目が前記個人化コンテン
ツ項目を含むことを特徴とする請求項１９に記載の方法。
【請求項２２】前記情報が前記コンテンツ項目の購入者と関連する第２の
暗号鍵を含み、前記コンテンツ項目が第１の暗号鍵で復号可能なように暗号形式
のコンテンツを含み、前記の方法は、前記第２の暗号鍵で前記第１の暗号鍵を暗号化するステップと、結果の暗号化された第１の暗号鍵を前記コンテンツ項目に含めるステップとを
備えたことを特徴とする請求項１４に記載の方法。
【請求項２３】前記情報が前記コンテンツ項目の識別を含み、前記提供す
るステップは、前記コンテンツ項目の前記識別を使用し記憶デバイスに格納され
ている複数のコンテンツ項目から前記コンテンツ項目を取り出すことを含むこと
を特徴とする請求項１４に記載の方法。
【請求項２４】前記コンテンツ項目は非暗号化コンテンツを含むことを特
徴とする請求項１４に記載の方法。
【請求項２５】ライセンスを前記電子コンテンツ項目に含めるステップを
さらに備えたことを特徴とする請求項１４に記載の方法。
【請求項２６】請求項１４に記載の方法を実行するコンピュータ実行可能
命令を有することを特徴とするコンピュータ可読媒体。
【請求項２７】電子コンテンツ項目を提供する方法であって、前記方法は
、第１の計算デバイスから第１の暗号鍵を受け取るステップと、記憶装置から前記電子コンテンツ項目を取り出すステップであって、前記電子
コンテンツ項目が前記第２の暗号鍵とともに復号可能な暗号化コンテンツを含む
ステップと、前記第１の暗号鍵で前記第２の暗号鍵を暗号化して暗号化された暗号鍵を出力
するステップと、前記暗号化された暗号鍵を取り出した電子コンテンツ項目に含めるステップと
、前記暗号化された暗号鍵を含む取り出した電子コンテンツ項目を前記第１の計
算デバイスに送信するステップとを備えたことを特徴とする方法。
【請求項２８】前記第１の暗号鍵は前記第１の計算デバイスと関連する非
対称鍵ペアの公開鍵であることを特徴とする請求項２７に記載の方法。
【請求項２９】前記暗号化された暗号鍵を封印するステップをさらに備え
たことを特徴とする請求項２７に記載の方法。
【請求項３０】取り出した電子コンテンツ項目がメタデータを含み、前記
封印ステップは前記メタデータで暗号化された暗号鍵を封印するステップを含む
ことを特徴とする請求項２９に記載の方法。
【請求項３１】ユーザに関連する個人情報を前記メタデータに追加し、新
規メタデータを出力するステップをさらに備え、前記封印ステップは新規メタデ
ータと共に暗号化されたコンテンツを封印するステップを含むことを特徴とする
請求項３０に記載の方法。
【請求項３２】前記個人情報は名前、クレジットカード番号、または受領
書番号を含むことを特徴とする請求項３１に記載の方法。
【請求項３３】前記第１の暗号鍵を暗号化データの形式で受信し、前記方
法は前記暗号化されたデータを復号し、前記第１の暗号鍵を取得するステップを
備えたことを特徴とする請求項２７に記載の方法。
【請求項３４】前記暗号化されたデータが前記第１の計算デバイス上のユ
ニバーサルレコードロケータに含まれ、前記受信ステップは前記ユニバーサルレ
コードロケータに移動する前記第１の計算デバイス上でオペレータの結果として
実行されることを特徴とする請求項３３に記載の方法。
【請求項３５】前記ユニバーサルレコードロケータはＰＯＳＴ要求を含む
ことを特徴とする請求項３４に記載の方法。
【請求項３６】前記ユニバーサルレコードロケータはＧＥＴ要求を含むこ
とを特徴とする請求項３４に記載の方法。
【請求項３７】請求項２７に記載の方法を実行するコンピュータ実行可能
命令を有することを特徴とするコンピュータ可読媒体。
【請求項３８】コンテンツの無許可配布を防止する方法であって、前記方
法は、第１の計算デバイスから第１の通信を受け取るステップであって、前記第１の
通信が第１の暗号化された情報を含み、前記第１の通信が第１のユニバーサルレ
コードロケータに基づき前記第１の計算デバイスで開始し、前記第１のユニバー
サルレコードロケータが前記第１の計算デバイスのアドレスと前記第１の暗号化
された情報とを含み、前記第１の暗号化された情報が第１の時間情報を含むステ
ップと、前記第１の暗号化された情報を復号し、前記第１の時間情報を取り出すステッ
プと、前記第１の時間情報に基づき、有効期限が切れていないことを判定するステッ
プと、第１の電子コンテンツ項目を前記第１の計算デバイスに供給するステップとを備えたことを特徴とする方法。
【請求項３９】第２の計算デバイスから第２の通信を受け取るステップで
あって、前記第２の通信が第２の暗号化された情報を含み、前記第２の通信が第
２のユニバーサルレコードロケータに基づき前記第２の計算デバイスで開始し、
前記第２のユニバーサルレコードロケータが前記第１の計算デバイスのアドレス
と前記第２の暗号化された情報とを含み、前記第２の暗号化された情報が第２の
時間情報と第２の電子コンテンツ項目の識別とを含むステップと、前記第２の暗号化された情報を復号し、前記第２の時間情報を取り出すステッ
プと、前記第２の時間情報に基づき、有効期限が切れていることを判定するステップ
と、前記第２の計算デバイスに対する前記第２の電子コンテンツ項目を少なくとも
一時的に拒絶するステップとをさらに備えたことを特徴とする請求項３８に記載の方法。
【請求項４０】前記電子コンテンツ項目はテキスト情報を含むことを特徴
とする請求項３８に記載の方法。
【請求項４１】前記電子コンテンツ項目はマルチメディア作品を含むこと
を特徴とする請求項３８に記載の方法。
【請求項４２】前記第１の時間情報がタイムスタンプを含み、前記有効期
限が前記タイムスタンプで指定した時間の後の一定時間を含むことを特徴とする
請求項３８に記載の方法。
【請求項４３】前記タイムスタンプは前記第１の暗号化された情報を暗号
化した時刻を含むことを特徴とする請求項４２に記載の方法。
【請求項４４】前記第１のユニバーサルレコードロケータはＷｅｂページ
上のリンクの形で前記第２の計算デバイスによって前記第１の計算デバイスに提
供され、前記第１の通信が前記リンクをたどる前記第１の計算デバイスと関連す
るユーザによって開始されることを特徴とする請求項３８に記載の方法。
【請求項４５】請求項３８に記載の方法を実行するコンピュータ実行可能
命令を有することを特徴とするコンピュータ可読媒体。
【請求項４６】電子配布の方法であって、前記方法は、第１の当事者が第３の当事者から品目の注文を受けるステップと、前記第１の当事者が前記品目に関して情報を作成するステップと、前記第１の当事者が秘密情報とともに前記情報を暗号化し、暗号化された情報
を出力するステップであって、前記秘密情報を前記第１の当事者と第２の当事者
との間で共有するステップと、前記第１の当事者が前記第３の当事者にユニバーサルレコードロケータを送信
するステップであって、前記ユニバーサルレコードロケータが前記暗号化された
情報と前記第２の当事者と関連するサーバのネットワークアドレスとを含むステ
ップと、前記第２の当事者が前記暗号化された情報を含む送信を受け取るステップであ
って、前記送信が前記ユニバーサルレコードロケータに基づいて前記第３の当事
者によって作動されるステップと、前記第２の当事者が前記の秘密情報を使用して前記暗号化された情報を復号す
るステップと、前記第２の当事者が前記復号された情報に基づいて前記注文の履行増進に少な
くとも１つのアクションを実行するステップとを備えたことを特徴とする方法。
【請求項４７】前記第１の当事者が前記の項目を販売し、前記第２の当事
者が前記第１の当事者による前記販売品目を前記第３の当事者に提供することを
特徴とする請求項４６に記載の方法。
【請求項４８】前記品目が電子コンテンツを含み、前記注文の履行増進の
ための前記少なくとも１つのアクションが前記電子コンテンツを前記第３の当事
者に送信するステップを含むことを特徴とする請求項４６に記載の方法。
【請求項４９】前記秘密情報は暗号鍵を含むことを特徴とする請求項４６
に記載の方法。
【請求項５０】ユーザ向けに個人化したコンテンツ項目を提供する方法で
あって、前記方法は、記憶装置デバイスからコンテンツ項目を取り出すステップであって、前記コン
テンツ項目が、メタデータ、前記メタデータで封印された復号鍵、および前記復
号鍵で復号できる暗号化されたコンテンツを含むステップと、前記復号鍵を開封するステップと、前記ユーザに関連する少なくとも一部の個人情報を前記メタデータに追加し、
新しいメタデータを出力するステップと、前記復号鍵を前記新しいメタデータで再封印するステップとを備えたことを特徴とする方法。
【請求項５１】前記個人情報は名前、クレジットカード番号、または受領
書番号を含むことを特徴とする請求項５０に記載の方法。
【請求項５２】前記個人情報を含む暗号化されたデータを受け取るステッ
プと、前記暗号化されたデータを復号し、前記個人情報を取得するステップとをさらに備えたことを特徴とする請求項５０に記載の方法。
【請求項５３】前記復号鍵は対称鍵を含むことを特徴とする請求項５０に
記載の方法。
【請求項５４】請求項５０に記載の方法を実行するコンピュータ実行可能
命令を有することを特徴とするコンピュータ可読媒体。
【請求項５５】電子コンテンツをクライアントデバイスに配信するように
適合されているダウンロードサーバであって、電子コンテンツの受信要求の妥当性を確認する妥当性確認モジュールと、要求された電子コンテンツのダウンロードサーバ上の場所を判定するコンテン
ツストアモジュールと、電子コンテンツが受け取る保護のレベルを判定するセキュリティレベル判別モ
ジュールと、クライアントデバイスにダウンロードするために定められたセキュリティレベ
ルに従って電子コンテンツを封印する封印モジュールとを備えたことを特徴とするダウンロードサーバ。
【請求項５６】電子コンテンツをダウンロードするユーザの認証の妥当性
を確認し、電子コンテンツに関して権利を付与するユーザにライセンスを生成す
るライセンスモジュールをさらに備えたことを特徴とする請求項５５に記載のダ
ウンロードサーバ。
【請求項５７】前記セキュリティレベルを、前記電子コンテンツが暗号化されない第１のレベルと、前記電子コンテンツが、暗号化されたコンテンツ、前記暗号化されたコンテン
ツを復号する復号鍵、およびメタデータを含み、前記復号鍵を前記メタデータで
封印する第２のレベルと、前記電子コンテンツが、暗号化されたコンテンツ、前記暗号化されたコンテン
ツを復号する復号鍵、およびメタデータを含み、前記復号鍵を前記メタデータで
封印し、前記メタデータにユーザの個人情報が含まれる第３のレベルと、前記電子コンテンツがデジタル署名を含む第４のレベルと、前記電子コンテンツが、暗号化されたコンテンツ、前記暗号化されたコンテン
ツを復号する復号鍵、およびメタデータを含み、前記復号鍵をユーザと関連する
第１の暗号鍵で暗号化し、前記暗号化された復号鍵を前記メタデータで封印する
第５のレベルとからなるグループから選択することを特徴とする請求項５５に記載のダウンロードサーバ。
【請求項５８】電子コンテンツの前記受信要求が少なくとも一部の暗号化
情報を含み、前記妥当性確認モジュールが前記暗号化情報を復号することを特徴
とする請求項５５に記載のダウンロードサーバ。
【請求項５９】前記受信要求がユニバーサルレコードロケータに基づき、
前記ユニバーサルレコードロケータが前記少なくとも一部の暗号化情報と前記ダ
ウンロードサーバのアドレスとを含むことを特徴とする請求項５８に記載のダウ
ンロードサーバ。
【請求項６０】コンテンツの無許可配布を防止する方法であって、前記方
法は、第１の計算デバイスから第１の通信を受け取るステップであって、前記第１の
通信が第１の暗号化された情報を含み、前記第１の通信が第１のＨＴＴＰ要求に
基づき前記第１の計算デバイスで開始し、前記第１のＨＴＴＰ要求が前記第１の
計算デバイスのアドレスと前記第１の暗号化された情報とを含み、前記ＨＴＴＰ
要求が前記暗号化情報の暗号化の前に計算された前記第１の暗号化情報のハッシ
ュをさらに含むステップと、前記第１の暗号化情報を復号するステップと、計算したハッシュと復号された情報との比較結果に基づき、前記暗号化された
情報が改竄されていないことを判定するステップと、第１の電子コンテンツ項目を前記第１の計算デバイスに供給するステップとを備えたことを特徴とする方法。
【請求項６１】第２の計算デバイスから第２の通信を受け取るステップで
あって、前記第２の通信が第２の暗号化された情報を含み、前記第２の通信が第
２のＨＴＴＰ要求に基づき前記第２の計算デバイスで開始し、前記第２のＨＴＴ
Ｐ要求が前記第１の計算デバイスのアドレスと前記第２の暗号化された情報とを
含み、前記第２のＨＴＴＰ要求が前記第２の情報の暗号化の前に計算された前記
第２の暗号化情報のハッシュをさらに含み、前記第２の暗号化情報が第２の時間
情報と第２の電子コンテンツ項目の識別とを含むステップと、前記第２の暗号化情報を復号するステップと、前記第２の復号情報と前記第２の情報のハッシュとの比較結果に基づき、前記
第２の暗号化された情報が改竄されていないことを判定するステップと、前記第２の計算デバイスに対する前記第２の電子コンテンツ項目を少なくとも
一時的に拒絶するステップとを備えたことを特徴とする請求項６０に記載の方法。
【請求項６２】前記ＨＴＴＰ要求はＰＯＳＴ要求を含むことを特徴とする
請求項６０に記載の方法。
【請求項６３】前記ＨＴＴＰ要求はＧＥＴ要求を含むことを特徴とする請
求項６０に記載の方法。