(57)【特許請求の範囲】
【請求項１】
コンテンツを配布するディストリビュータ・サーバと、
前記ディストリビュータ・サーバから配布されるコンテンツを受取り、当該コンテンツに関連付けられる使用権を実施するユーザ装置と、
前記ユーザ装置によるコンテンツの使用に関わる料金の会計及び支払いを実施する信頼できるウェブサイトと、
前記ディストリビュータ・サーバ、前記ユーザ装置、及び、前記信頼できるウェブサイトをそれぞれ結合する通信ネットワークと、
を備えるコンテンツ配布システムであって、
前記信頼できるウェブサイトはセキュリティ・モジュールを前記ユーザ装置に提供するものであって、前記セキュリティ・モジュールは前記ユーザ装置に固有のものであり、前記ユーザ装置による使用権の実施の為に該ユーザ装置にインストールされるものであり、
前記ユーザ装置は、前記セキュリティ・モジュールにより保護されたレンダリングエンジンにより前記ディストリビュータ・サーバ上の処理ウェブサイトにログオンし、該処理ウェブサイトから要求コンテンツを得る為のトランザクションを開始するように構成され、
前記信頼できるウェブサイトは、前記セキュリティ・モジュールの前記コンテンツの使用に関わる料金の会計及び支払いに関するユーザ情報を記憶し、
前記処理ウェブサイトは、前記ログオンするユーザ装置を前記信頼できるウェブサイトに記憶される前記ユーザ情報に基付いて確認するように構成される、
コンテンツ配布システム。
【請求項２】
前記信頼できるウェブサイトが、料金の会計・支払い実施の複数のトランザクションを所定の期間に渡って統合するように機能するトランザクション・アグリゲータである、請求項１記載のコンテンツ配布システム。
【請求項３】
前記セキュリティ・モジュールは一対の公開鍵・秘密鍵を有する、請求項１記載のコンテンツ配布システム。
【請求項４】
前記信頼できるウェブサイトは前記一対の公開鍵・秘密鍵を使用して前記ユーザ装置を認証する、請求項１記載のコンテンツ配布システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はディジタルコンテンツの配布に係り、詳細には、インターネットウェブブラウザ等の標準アプリケーションプログラムのレンダリングエンジンとともに表示される被保護文書の配布を容易にするための方法及び装置に関する。
【背景技術】
【０００２】
インターネットは、ＴＣＰ／ＩＰ（転送制御プロトコル／インターネットプロトコル）として知られるプロトコルの標準スーツを実行させる種々のハードウェア通信リンクによって結合される、コンピュータの世界規模のネットワークである。最近数年間におけるインターネットの成長は爆発的であり、ＨＴＭＬ（ハイパーテキストマークアップ言語）表示及びＨＴＴＰ（ハイパーテキスト転送プロトコル）ナビゲーションの双方を可能にする（「ブラウザ」として周知の）ソフトウェアツールの広範囲に及ぶ使用によって、その大部分がさらに加速されている。ブラウザは、単純ＧＵＩ（グラフィカル・ユーザ・インタフェース）を使用してインターネット上での通信を可能にする。ブラウザは一般に、インターネット上のコンテンツにアクセスするために使用されるコンピュータ、即ち、クライアントコンピュータ上に存在する。ＨＴＴＰはＴＣＰ／ＩＰの上位層の構成要素であり、ＨＴＭＬとして周知の標準ページ記述言語や、より最近では、ＸＭＬ（拡張可能マークアップ言語）やＸＨＴＭＬ（拡張可能ハイパーテキストマークアップ言語）、及びＨＴＭＬのＸＭＬへの書式変更を用いて種々のフォーマットの文書へのアクセスをユーザに提供する。ＨＴＭＬ／ＨＴＴＰを用いたインターネット上のサーバの集合は、「ワールドワイドウェブ」又は単に「ウェブ」として知られている。
【０００３】
ＨＴＭＬ、ＸＨＴＭＬ、及び会話型（インタラクティブ）プログラミングプロトコルを介して、コンテンツの著作者は、インターネットウェブサーバ上でウェブページの形式にそのコンテンツを設定することによって、他者にもそのコンテンツが利用可能なようにすることができる。サーバへのネットワーク経路はＵＲＬ（ユニフォーム・リソース・ロケータ）によって識別され、一般に、ウェブブラウザを実行するクライアントは、ＵＲＬを用いてウェブサーバにアクセス可能である。ブラウザを実行するクライアントコンピュータは、周知の方法でＵＲＬ要求をインターネットを介してウェブに発行することによってウェブサーバ上に記憶されたウェブページの表示を要求することができる。
【０００４】
ウェブは標準プロトコル及び標準レンダリングエンジン、即ち、ブラウザのレンダリングエンジンを利用するので、ウェブは誰もがいつでもどこでも利用できること（ユビキタス）になる。ウェブの主要アプリケーションの１つは、文書形式のコンテンツの配布であった。「文書」は本明細書において使用されるように、通信文、書籍、雑誌、定期刊行物、新聞、その他の書類、ソフトウェア、写真及び他の画像、音声及びビデオクリップ、ならびにその他のマルチメディア・プレゼンテーションに限定されないが、これらを含む、配布又は転送の対象になる情報の単位である。文書は、記憶媒体上のディジタルデータとして紙に印刷された形式、又は、他の既知の方法で種々の媒体上に具体化されることもできる。
【０００５】
しかしながら、ディジタル文書、即ち、コンピュータによる読み取り可能な形式の文書の、電子手段及び、特にインターネットを介した広範囲にわたる配布を妨げる最も重要な問題の１つは、これらディジタル文書の配布及び使用の際にコンテンツ所有者の知的所有権の保護が現状では不十分であることである。この問題を解決するための取り組みは、「知的所有権管理（ＩＰＲＭ）」、「ディジタル所有権管理（ＤＰＲＭ）」、「知的財産管理（ＩＰＭ）」、「権利管理（ＲＭ）」、「電子著作権管理（ＥＣＭ）」、これらを総称して「ディジタル権利管理（ＤＲＭ）」と称される。
【０００６】
印刷された文書の世界では、作家によって作成された作品は通常、出版者に供与され、その作品の多数の複写を書式設定し印刷する。これら印刷物は流通業者によって本屋や他の小売販売店に送られ、そこから最終消費者によって購入される。複写品質が低いことと、印刷物の配布コストが高いことがほとんどの印刷物の無断コピーに対する抑止力となってきた一方、保護されていないディジタル文書を複写し、修正変更し、再配布することが、あまりに簡単に出来すぎる。従って、許可なしにそれらを複写し配布することをより困難にするため、ディジタル文書を保護する何らかの方法が必要である。
【０００７】
残念なことに、現在の汎用コンピューティング及び通信システム、たとえば、パーソナルコンピュータ、ワークステーション、及びローカルエリアネットワーク（ＬＡＮ）、イントラネット、インターネット等の通信ネットワーク上で接続される他の装置内で人々が電子文書の無断配布を行なうことを防止、即ち、阻止するのが困難であることは広く認識されている。無断コピーを防止するためにハードウェアに基づく解決法を付与する多くの試みが不成功であったことがわかっている。「ブロードバンド」通信技術（ＮＩＩ）の急増により、映画全編等のビデオファイルを含む大きな文書を電子的に配布することが更に好都合とされ、このようにして、文書の無許可配布に対し残りの抑止力が取り除かれることになる。したがって、ＤＲＭ技術は非常に有効になりつつある。
【０００８】
文書保護問題を解決しようとする試みに用いられる２つの基本的な方式は、安全なコンテナと信頼できるシステムである。「安全なコンテナ」（あるいは単に暗号化された文書）は、一組の許可条件が満たされ、一部の著作権期間が終了される（例えば、使用のための支払い）まで、文書の内容を暗号化状態にする方法を提供する。種々の条件及び期間が文書提供者によって確認された後で、その文書は明文の形式でユーザに公開される。ＩＢＭ（商標）及びインタートラスト（InterTrust's、商標）のデジボックス（Digibox）によるクリプトロープ（Cryptolope）等の商品はこの分類に入る。明らかに、安全なコンテナの手法は、不安定なチャネル上に配信する間に文書を保護することに解決法を提供するが、正当なユーザがクリア文書を取得し、コンテンツ所有者の知的所有権に違反してそれを使用し再配布することを防止するメカニズムの提供はしない。
【０００９】
暗号化メカニズムは一般に、公式に配布されて記憶され、最終的に、許可されたユーザによって個々に暗号解読、即ち、非暗号化される文書を暗号化（即ち、「暗号文」に）するために使用される。これは、不安定な媒体に文書を記憶させる際と同様、文書ディストリビュータからパブリックネットワーク上で許可されたユーザに文書を配信する際の基本的な保護形式を提供する。
【００１０】
「信頼できるシステム」手法では、システム全体が文書の無断使用及び無断配布を防止することに責任を持つ。信頼できるシステムを構築することは通常、安全なプロセッサ、安全な記憶装置、及び安全なレンダリング装置等の新しいハードウェアを導入することを必然的に伴なう。これはまた、信頼できるシステム上でラン（稼動）するすべてのソフトウェアアプリケーションが信頼できると証明されることを必要とする。改ざん防止の信頼できるシステムを構築することは、既存の技術に対する更なる実質的な挑戦である一方、現在の市場動向は、ブラウザを用いてウェブにアクセスするＰＣやワークステーション等の開放型の信頼性の低いシステムが著作権のある文書にアクセスするのに用いられる有力なシステムであることを示唆する。その意味では、普及されているオペレーティングシステム（例えば、ウィンドウズ（登録商標）、リナックス（商標）、ユニックス（ＵＮＩＸ（登録商標））、及びブラウザ等のレンダリングアプリケーションを備えたＰＣ及びワークステーション等の既存のコンピュータ環境は信頼できるシステムではなく、それらのアーキテクチャを大幅に変更させることなく信頼できる状態にすることはできない。当然、アーキテクチャの変更は、ウェブの主要目的、即ち、柔軟性及び互換性を無効化する。
【００１１】
米国特許第５，７１５，４０３号には、ディジタル文書の配布を制御するためのシステムが開示され、その開示コンテンツは参照によって本明細書に組み込まれる。各レンダリング装置は各自対応付けられるリポジトリを有する。使用権ラベルはディジタルコンテンツと対応付けられる。このラベルは、コンテンツの使用法を指定する使用権と、その使用法を行使するための先例となる条件を含む。さらに、米国特許第５，０５２，０４０号は、異なるユーザが同じファイルに対して特定の暗号化機能及び権利を有することが可能であるようにディジタルファイルの前に付けられるラベルの使用を開示している。
【００１２】
ウェブ上の文書の配布を制御するために２つの基本的な手法が採られている。第１の手法は、ユーザが受信料を支払った後にだけコンテンツへのアクセスが許可されるという申し込みに基づくサービスの使用である。しかしながら、いったん受信料が支払われ、文書がブラウザによってレンダリングされると、ユーザはその文書を複写し、印刷し、修正変更することができ、即ち、発行者による文書のすべての制御が失われる。
【００１３】
第２の手法は、発行者の権利を実施するように義務付けられる選択レンダリングエンジンによってのみ文書がレンダリングされ得るような所有権（を主張できる）フォーマットを利用することである。当然、この手法は、単一の所有権フォーマットの使用を必要とし、複数の公共フォーマットを結合する能力と、それに対応付けられるコンテンツの豊富さを維持できなくなる。また、この手法は、ユーザがそのコンピュータ上で取得されインストールされなければならない所有権レンダリングアプリケーションを使用することを要求するとともに、安全な方法でレンダリングされる各フォーマットごとのレンダリングアプリケーションの開発を必要とする。さらに、文書は非標準ツールを用いて生成又は変換されなければならない。
【００１４】
さらに、ウェブブラウザ等の標準レンダリングエンジンに対し機能性を付加することのできる種々の周知のメカニズムがある。例えば、ActiveXコントロール（ActiveX Control）は自動的にダウンロードされ、ウェブブラウザによって実行されることが可能である。ActiveXは、アプリケーションが情報を共有する方法についての規則の集合であり、ActiveXコントロールは、Ｃ、Ｃ＋＋、ビジュアルベーシック（Visual Basic）、及びJava（登録商標）（Java（登録商標））を含む種々のプログラミング言語において開発可能である。
【００１５】
ActiveXコントロールは、Java（登録商標）アプレットと類似している。しかしながら、Java（登録商標）アプレットとは異なり、ActiveXコントロールはウィンドウズ（登録商標）オペレーティングシステムに対し完全なアクセスを有する。マイクロソフト（商標）では、ブラウザがダウンロードする前にActiveXコントロールを識別し認証できるように登録システムを開発している。Java（登録商標）アプレットはすべてのプラットフォーム上でランすることができ、一方、ActiveXコントロールは現在のところウィンドウズ（登録商標）環境に限定されている。
【００１６】
ＶＢスクリプト（VBScript）と称されるスクリプト言語により、ウェブの著作者はＨＴＭＬ文書にインタラクティブ要素を組み込み、ActiveXコントロールのダウンロードやインストール、及びその他の機能を起動させることができる。現在、マイクロソフト社のウェブブラウザであるインターネット・エクスプローラ（商標）は、Java（登録商標）、Java（登録商標）スクリプト、及びActiveXをサポートし、一方、ネットスケープ社のナビゲータ（商標）のブラウザはJava（登録商標）及びJava（登録商標）スクリプトのみをサポートするが、そのプラグインはＶＢスクリプト及びActiveXのサポートを使用可能にできる。しかしながら、ブラウザ用の種々のプラグイン及びアドオン式ソフトウェアの利用可能性は、ユーザが体験することをさらに複雑にするとともに、ウェブ又は他のオープンネットワーク上で信頼できるＤＲＭシステムを実施する際に種々の問題を提起する。
【００１７】
ＶＹＯＵ．ＣＯＭは、ウェブ上に配布される文書における知的所有権を保護するためのシステムを開発している。このシステムは、ユーザのウェブブラウザに対するソフトウェアのプラグインを含む。プラグインは、文書が表示され転送される所有権を主張できるフォーマットのための所有権レンダリングエンジンを含む。従って、文書は所有権フォーマットに書式変更されなければならず、適切な最終表示フォーマット用のプラグイン・レンダリングエンジンが標準ブラウザレンダリングエンジンの代わりに使用される。この構成は各フォーマットごとにレンダリングエンジンが開発されることを必要とする。したがって、このシステムを実施することは困難であり、オープンアーキテクチャとしてのウェブの利点を維持できなくなる。
【００１８】
ウェブの拡散、及び文書配布におけるその有効性により、レンダリングエンジンの書き換えを必要とすることなくウェブブラウザ及びその他の標準レンダリングエンジンに対しＤＲＭ特徴を付加することが望ましいとされる。しかしながら、従来のＤＲＭ技術はウェブブラウザ及びその他の標準レンダリングエンジンとともに使用することに容易には適用されないが、これは、ウェブのオープンアーキテクチャに相反する、所有権フォーマット及びレンダリングエンジンを必要とするからである。これらのレンダリングエンジンとは無関係にウェブブラウザ等のアプリケーションプログラムを制御できないことが、配布ネットワーク上でＤＲＭ特徴を付加することを困難にしている。
【００１９】
ウェブ上でＤＲＭシステムを実現することに対して更に障害となるものは、所有権（を主張できる）文書、特に、所有権文書における限られた権利に対し支払われる料金が比較的少ないという事実である。例えば、多くの場合、所有権文書における限られた権利に対する料金は１米ドル未満である。このような場合、アクセス料金、取引手数料等を含むクレジットカード使用料を処理するのに対応付けられる費用は、文書料金全体と比べ相対的に高い。「マイクロトランザクション」としばしば称されるこのような比較的小さなトランザクションに対し、対応する「小額決済（マイクロペイメント）」、即ち、比較的少ない支払いに対するクレジットカードの使用は非実用的である。さらに、各クレジットカードのトランザクションが個々の料金として処理されるので、種々のトランザクションにおいて大容量の文書を購入する顧客は、クレジットカードのトランザクションに対し効率的でない多数の小さなトランザクションを生み出すことになる。
【００２０】
インターネット上でマイクロペイメント及びその他の支払いを処理するための種々の所有権を主張できる解決法が開発されている。例えば、CyberCash（商標）社、及びePayment Systems（商標）社はそれぞれこのような解決法を提示している。また、Intellicent（商標）では、マイクロペイメント用の特定の解決法を提示している。しかしながら、このような解決法はＤＲＭ環境において一体化されていない。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
ユーザ情報のプライバシーを保護しながら、トランザクションを管理し完了するための方法及びシステムが提供される。
【課題を解決するための手段】
【００２２】
本発明の１つの態様によれば、トランザクション・アグリゲータである信頼できるウェブサイトにユーザ情報を記憶するステップと、信頼できるウェブサイトは、一対の隠し公開鍵・秘密鍵で固有のセキュリティ・モジュールを生成し、セキュリティ・モジュールをユーザ装置に提供するステップであって、信頼できるウエブサイトのみがユーザの個人情報を有し、セキュリティ・モジュールはブラウザ又はサード・バーティー製レンダリング・アプリケーションの保護されたインスタンスを生成し、ブラウザ又はサード・バーティー製レンダリング・アプリケーションを回避するアクセス保護を実施して、ディストリビュータ・サーバから保護されたコンテンツを検索してレンダリングするよう指示する、該セキュリティ・モジュールを生成し、提供するステップと、ユーザ装置がディストリビュータ・サーバに記憶されている処理中のウェブサイトにログオンするステップと、ユーザ装置が処理中のウェブサイトからのトランザクションを要求するステップと、トランザクション・ウェブサイトが信頼できるウェブサイトを介してユーザを確認するステップと、ユーザ情報を処理中のウェブサイトに転送することなくユーザ装置と処理中のウェブサイトとの間でトランザクションを完了させるステップとを含むユーザ情報のプライバシーを保護しながら、トランザクションを管理し完了するための方法が提供される。
【発明を実施するための最良の形態】
【００２３】
本発明は好ましい実施の形態を参照して以下に説明される。本発明が種々様々な形式で具体化されることができ、その一部が示された実施の形態とは全く異なるものでもよいことは理解されるだろう。このため、本明細書に示された特定の構造上及び機能上の詳細は単に代表的なものにすぎず、本発明の範囲を限定しない。
【００２４】
図１は、ディジタル文書の電子配布のためのシステムのモデルを示したブロック図である。著作者１１０はオリジナルコンテンツ１１２を作成し、それを配布用のディストリビュータ１２０に送信する。本来、著作者１１０はコンテンツの作成者である。しかしながら、ここで用いられる「著作者」という表現は、作成者、所有者、編集者、又はコンテンツ若しくは実在物の１つのエージェント（例えば、発行者）を制御する他のエンティティである可能性がある。さらに、著作者１１０はディストリビュータ１２０等の別の関係者を必要とすることなく、文書を直接配布することができるので、著作者及びディストリビュータは同一エンティティであってもよい。しかしながら、図１に示される機能の分割がさらに効果的であり、これは、著作者１１０を配布の管理機能ではなく、コンテンツの作成に集中させることができるからである。さらに、このようなブレークダウンは、ディストリビュータ１２０をある数の著作者１１０と対応付けることによって規模の経済性を促進する。「文書」という表現は本明細書中で使用されるように、一般には、暗号化、フォーマット化等を含む、テキスト、オーディオ、又は他のデータ等のいかなるタイプのコンテンツをも指す。「コンテンツ」という表現は本明細書に使用されるように、一般には、文書の基礎となる情報を指す。しかしながら、これらの表現は重複し、したがって本明細書では交換可能に使用される。
【００２５】
ディストリビュータ１２０は、要求に応じてユーザ１３０に文書を配布する。代表的な電子配布モデルにおいて、コンテンツは暗号化形式の文書として配布される。ディストリビュータ１２０はランダムキーでそのコンテンツを暗号化し、ユーザ１３０に対応するパブリックキーでランダムキーを暗号化する。このようにして、暗号化された文書は特定のユーザ１３０に対してのみカストマイズされる。ユーザ１３０は、これらの個人用キーを用いてランダムキーを非暗号化し、それを用いて文章を非暗号化し表示させることができる。
【００２６】
文書料金の支払い（決済）は、ユーザ１３０及び特定の文書の表示を希望する他のユーザからの要求を収集するクリアリングハウス１５０を介して、ユーザ１３０からディストリビュータ１２０に送られる。クリアリングハウス１５０はさらに、支払い情報、例えば、デビット・トランザクション、クレジットカード・トランザクション、又は他の周知の電子支払い方式を収集し、その収集された支払いを支払いバッチとしてディストリビュータ１２０に転送する。もちろん、クリアリングハウス１５０は、上述のサービスに対する料金として支払いの共有を維持することもできる。ディストリビュータ１２０は配布サービスのためにクリアリングハウス１５０からのバッチ支払いの一部を維持し、著作者１１０に支払い（例えば、著作権使用料）を転送することができる。ディストリビュータ１２０は文書を配布する前に、単一の文書に対する大量のユーザ要求を待ち受けることがある。このような場合、単一の暗号化文書は要求中のユーザ１３０のすべてによる非暗号化のために作成可能である。
【００２７】
ユーザ１３０が文書を要求（又は使用）するたびに、会計メッセージが監査サーバ１４０に送信され、監査サーバ１４０はユーザ１３０による各要求がディストリビュータ１２０によって送信される文書と整合することを確実にする。会計情報は、直接的にディストリビュータ１２０から、監査サーバ１４０によって受信される。何か不一致があれば、レポートを介してクリアリングハウス１５０に伝送され、クリアリングハウス１５０はそれに応じてディストリビュータ１２０に対してなされる支払いバッチを調整することができる。この会計方式は、電子文書配布における不正行為の可能性を低減し、料金が結果としての使用期間又はその他の使用範囲に応じて変化する時間に依存した使用許可を処理することを示す。監査サーバ１４０及びクリアリングハウス１５０は結合された状態で、ある時間にわたって複数のトランザクションを統合し、ディストリビュータ１２０の会計オーバヘッドを低減するために適切な方法でディストリビュータ１２０に請求するように機能するトランザクション・アグリゲータ１６０としての働きをすることができる。図１に示された電子文書配布用のモデルは、本明細書に示された好ましい実施の形態による電子文書配布システムに適用可能である。さらに、コンテンツは上記したような使用権を含む可能性がある。
【００２８】
図２は、本発明の好ましい実施の形態による文書配布システムのコンピュータアーキテクチャの概略図である。上記のように、本発明は、クリアリングハウス及び監査サーバの使用等、料金の会計及び支払いを実施するための周知のモデルに関連して使用可能である。さらに、本発明は種々のコマース・モデルに関連して使用可能である。したがって、配布を監査し、支払いを実施し、文書を著作するための装置は本明細書には詳述されず、説明を簡単にするために好ましい実施形態の説明からは省略される。
【００２９】
図２に示されるように、ディジタルコンテンツ配布システム２００は、上述のディストリビュータ１２０に対応するディストリビュータ・サーバ２２０と、上述のユーザ１３０に対応するクライアントコンピュータ２３０と、を含む。サーバ２２０とクライアントコンピュータ２３０は、所望の機能を達成するためにプログラミングされた汎用コンピュータである。例えば、サーバ２２０は、ウィンドウズ（登録商標）ＮＴオペレーティングシステムを実行し、アパッチ（商標）等のＨＴＴＰサーバ・ソフトウェア２２６又は他のＨＴＴＰサーバを含む標準サーバ又はワークステーションである可能性がある。クライアント２３０は、ウィンドウズ（登録商標）オペレーティングシステムを実行するパーソナルコンピュータである。好ましい実施の形態において、サーバ２２０及びクライアント２３０は、インターネット、即ち、具体的には、ウェブ等の通信ネットワーク３００にそれぞれ結合される。したがって、クライアント２３０は、レンダリングエンジンを有する標準アプリケーションプログラムとしてブラウザ２３２を含む。ブラウザ２３２は、マイクロソフト社のインターネット・エクスプローラ（商標）又はネットスケープ・ナビゲータ（商標）等のＨＴＴＰコンプライアント・ブラウザであってもよい。本明細書で使用される「標準アプリケーションプログラム」という言葉は、文書作成、表示、編集等の、レンダリングエンジンを有するタスクを達成するように設計されたアプリケーションプログラムを指す。標準アプリケーションプログラムの例は、ワードプロセッサ、ウェブブラウザ、エディタ、ビューアー、スプレッドシートプログラム、データベースプログラム等を含む。
【００３０】
サーバ２２０は、複数の文書２２２を配布用にウェブページの形式で記憶している。文書２２２は、暗号化書式で記憶されることができる。本明細書で使用される「暗号化」という言葉は、非対称又は対称性暗号化アルゴリズム、スクランブル用アルゴリズム等の使用により、コンテンツのアクセス可能性が部分的又は完全に禁止されるメカニズムを指す。サーバ２２０はさらに、文書２２２、ユーザ、及び／又は支払い金額もしくはその他の条件のうちの特定の１つに対応付けられる使用権を記憶し管理するための、ソフトウェア形式のディジタル権利管理モジュール２２４を含む。権利管理モジュール２２４の他の機能は以下に詳述される。ディストリビュータ・サーバ２２０は、サーバファーム又はその他のコンピュータグループの一部である可能性があり、これは図２に示されるようにディストリビュータ・サーバ２２０'を含むこともある。
【００３１】
クライアント２３０はさらに、ユーザインタフェース（ＵＩ）モジュール２３４と接続モジュール２３６を有し、これらはそれぞれソフトウェアの形式で、ブラウザ２３２の修正変更を必要とすることなく、ブラウザ２３２に接続されるのに適している。例えば、ＵＩモジュール２３４及び接続モジュール２３６は、プラグインや、ActiveXコントロールの形式、あるいはブラウザ２３２のコードを修正変更することを必要とすることなくブラウザ２３２のレンダリングエンジンに対する接続を可能にする形式である可能性がある。結合された状態で、ＵＩモジュール２３４及び接続モジュール２３６は、以下に詳述されるセキュリティ・モジュールを構成する。セキュリティ・モジュール２３７はクライアントコンピュータ２３０中に存在するものとして示されるが、セキュリティ・モジュール２３７はクライアント側構成要素及びサーバ側構成要素を含む可能性があることが明らかになる。例えば、後述されるＤＲＭモジュール２２４はセキュリティ・モジュール２３７のサーバ側構成要素である可能性がある。
【００３２】
権利管理モジュール２２４は、使用権のラベルを記憶し、どの権利が各文書２２２に対応付けられるかを識別するサーバ側構成要素である。この使用権はさらに、文書２２２へのアクセスを要求するユーザの識別、クリアリングハウス等を介してのユーザによる支払い、及びその他の条件に基づいて変化する可能性がある。例えば、ユーザは周知のように、文書２２２を見るための料金や、同じ文書２２２を見て印刷するためのより高額な料金を支払う選択権を持つこともできる。権利管理モジュール２２４は、通信ネットワーク３００を介して、後述されるようにクライアント２３０の接続モジュール２３６に対して適切な権利のリストを文書とともに転送するように作動する。
【００３３】
接続モジュール２３６は、ＵＩモジュール２３４がブラウザ２３２に接続されていることを確認することによってクライアント２３０の環境の保全性を検証し、クライアント２３０のユーザ、即ち、コンテンツを要求する人間を識別し、文書と権利管理モジュール２２４によって送信される適切な権利のリストを検索し、適切な状況において、暗号化された検索済みの文書を非暗号化し、必要な署名及び／又はキーを作成する、クライアント側ソフトウェア構成要素である可能性がある。ＵＩモジュール２３４は、文書２２２のコンテンツにアクセスするためにユーザからの要求を監視し、接続モジュール２３６によって検索される権利のリストに基づいて要求を許可又は拒絶するクライアント側構成要素である可能性がある。さらに、ＵＩモジュール２３４は、オペレーティングシステムＡＰＩとインタフェースし、コマンド等を傍受しリダイレクトすることによって、以下に示した方法で権利のリストに基づいてブラウザ２３２の特定機能と、クライアント２３０のオペレーティングシステムを使用禁止にすることができる。接続モジュール２３６は、クライアント２３０の環境でランする工業標準レンダリングエンジンが、ＵＩモジュール２３４をバイパスするようにしてユーザを保護されたコンテンツにアクセスさせることを可能にするような方法で不正操作あるいは暗号漏えいを受けなかったことを確認する。
【００３４】
本発明は、標準クライアントソフトウェア、サーバソフトウェア、及びレンダリングエンジンを修正変更したり、除去したり、あるいはバイパスすることなく、ウェブ等の周知のクライアント／サーバ・ネットワークアーキテクチャに連結して実施可能である。権利管理モジュール２２４は、既存のサーバソフトウェア２２６と一緒にサーバ２２０にインストールされる。上述したように、権利管理モジュール２２４は、サーバ２２０に存在するか又は後でサーバ２２０に記憶される文書２２２に対しどの権利が対応付けられるかを識別する。例えば、権利管理モジュール２２４は、各文書２２２に対応付けられる種々の権利と、よく知られた方法によるユーザの同一性とユーザによる支払い等の他の変数と、を含む、プログラマブル・データベース、ルックアップテーブル等を有することができる。権利管理モジュール２２４はさらに、サーバ２２０のオペレーティングシステムＡＰＩとインタフェースして、サーバソフトウェア２２６を接続モジュール２３６及びＵＩモジュール２３４等のセキュリティモジュール２３７の適切な構成要素を有するクライアント２３０からの接続に応答させるにすぎない。また、権利管理モジュール２２４は後述されるデータベース２２５とのインタフェースとしての働きをする。
【００３５】
例えば、権利管理モジュール２３４がインストールされると、図３に示される手続きが実行される。ステッブ３０２では、新しいＤＲＭ開始ウェブページ、又は他のセキュア・インタフェース・ディスプレイが作成され、ＵＩモジュール２３４及び既存のサーバ開始ウェブページを参照する。ステップ３０４では、サーバ２２０上のウェブサイトの種々のウェブページがランダムラベルを有するディレクトリ、又は未知のディレクトリに置かれることができる。ステップ３０６において、権利管理モジュール２２４がこのディレクトリへのポインタを含むようにプログラミングされ、ステップ３０８では、権利管理モジュール２２４はこのディレクトリのＵＲＬを暗号化する。ステップ３１０では、ＤＲＭ開始ウェブページがＵＩモジュール２３５を参照するように修正変更され、接続モジュール２３６に対し、暗号化されたＵＲＬを非暗号化するように指示して、元の開始ページ及びウェブサイトの残りの部分に対するアクセスを可能にすることができる。クライアント２３０がＵＩモジュール２３４及び接続モジュール２３６を有していない場合、ＵＲＬは非暗号化することができず、このため、サーバ２２０上のウェブサイトにアクセスできない。
【００３６】
あるいは、接続モジュール２３６は署名を生成し、その署名をサーバ２２０へのＵＲＬ要求とともに、サーバ２２０に送信することができる。サーバ２２０上のウェブサイトへのアクセスは、署名が存在し有効である場合に認められるにすぎない。この代替例では、権利管理モジュール２２４が、署名の妥当性を検査するためのコードを含むことができる。
【００３７】
クライアントコンピュータ２３０のユーザが権利管理モジュール２２４を有するサーバ２２０にアクセスしようとする場合、権利管理モジュール２２４は、ＵＩモジュール２３４等のセキュリティモジュール２３７のすべての必要とされる構成要素が上述したようにクライアント２３０にインストールされるかどうかを確認する。そうでなければ、Java（登録商標）アプレット、ActiveXコントロール等の形式にあるＤＲＭ開始ウェブページにおける命令が、ブラウザ２３２に対し、以下に詳述される方法でＵＩモジュール２３４をダウンロードしインストールするように指示する。ダウンロードは、サーバ２２０、又は通信ネットワーク３００に結合される別のサーバからも実行可能である。このようなダウンロード及びインストールは従来のメカニズムを用いて周知の方法で実行可能であり、ユーザはインストールを許可し、インストール・ファイルをどこに記憶させるか等の他の必要な情報を入力するように指示されることができる。接続モジュール２３６は、ＵＩモジュール２３４とともに、ダウンロードされ、同時に又は別個のダウンロード／インストールプロセスを介してインストールされることができる。もちろん、ＵＩモジュール２３４がサーバ２３０上にインストールされていることが検出されると、そのインストールステップはスキップ可能である。ＵＩモジュール２３４がクライアント２３０にインストールされず、ユーザがこのようなインストールを許可しない場合、サーバ２２２上の文書へのアクセスは禁止されるか、又は自由に配布可能なものと特定される文書にのみ限定される。
【００３８】
上述したように、ＵＩモジュール２３４及び接続モジュール２３６は、ブラウザ２３２のコードを修正変更することなく、ブラウザ２３２に接続可能な形式にある。モジュールに関して本明細書で使用される「接続された」という言葉は、ブラウザ２３２のコードを修正変更することなくブラウザと組み合わされる又は結合される可能性のあるソフトウェアモジュールであることを指す。例えば、ＵＩモジュール２３４及び接続モジュール２３６は、ネットスケープ・ナビゲータ（商標）の場合はプラグインの形式であり、インターネット・エクスプローラ（商標）の場合はActiveXコントロールの形式である。このような構成要素を開発しインストールするためのメカニズムはよく知られている。
【００３９】
サーバ２２０上に記憶される、文書２２２の形式の保護コンテンツにアクセスするための手順は図４に示される。ステップ４０２では、ＤＲＭ開始ウェブページが周知の方法でＵＲＬを介してアクセスされる。ステップ４０４では、ＤＲＭ開始ウェブページがＵＩモジュール２３４を、元の開始ページ又は上記の方法の１つを用いてＤＲＡＭ開始ウェブページによって参照されるページに方向付ける。ステップ４０６において、ＵＩモジュール２３４は周知の技術を用いて、ブラウザ２３２のレンダリングエンジンの別のインスタンスを作成し、元の開始ウェブページをロードし、オペレーティングシステムに対しブラウザウィンドウにおいて新しいインスタンスを表示するように指示する。この新しいインスタンスはステップ４０８において、接続モジュール２３６を介してサーバ２２０からのコンテンツを検索するように、ＵＩモジュール２３４によって方向付けられる。言い換えれば、好ましい実施の形態において、ＵＩモジュール２３４がブラウザ２３２からのコマンドを遮断し、それらを接続モジュール２３６を介してリダイレクトする。ＵＩモジュール２３４は、以下に詳述されるように、その新しいインスタンスに対し接続モジュール２３６を介して安全な非同期プロトコルを利用するように指示することができる。このため、ＵＩ保護は有効化され、すべてのユーザインタフェース事象はステップ４１０において遮断され制御される。例えば、ユーザがブラウザ２３２の標準ユーザインタフェースを介して「印刷」又は「複写」コマンドを起動させる時、ＵＩモジュール２３４はその要求を遮断し、接続モジュール２３６によって受信された一組の権利が要求された機能を実行できるようにする場合、に応答を許可するにすぎない。
【００４０】
さらに具体的には、接続モジュール２３６がブラウザ２３２のレンダリングエンジンから要求を受信すると、接続モジュール２３６は、レンダリングエンジンがＵＩモジュール２３４によって保護されること、即ち、ＵＩモジュール２３４が接続されることを確認し、レンダリングエンジンが不正操作、又は暗号漏えいを受けなかったことを確認する。もしそうならば、接続モジュール２３６がサーバ２２０の権利管理モジュール２２４への接続を許可し、サーバ２２０上の元の開始ウェブページと、当該ウェブページ用のユーザの権利の集合を検索するための許可を取り決める。権利管理モジュール２２４は、サーバ２２０のサーバ・ソフトウェア２２６と、クライアント２３０の接続モジュール２３６との接続を開始する。この接続は、ＨＴＴＰやＨＴＴＰＳ、あるいは他の標準若しくは所有権を主張できる接続プロトコル等のプロトコルを用いて設定可能である。
【００４１】
要求された文書２２２は、サーバ２２０上で暗号化される場合、検索され、文書２２２を非暗号化にする接続モジュール２３６に転送され、非暗号化形式の文書を、文書に対応付けられる権利の集合とともに、ブラウザ２３２のレンダリングエンジンの新しいインスタンスに転送する。さらにもう一度、権利の集合の内容は、文書、ユーザの同一性、ユーザによる支払い、又はその他の適切なパラメータに基づいて決定されることもある。接続モジュール２３６は、上記のようにブラウザ２３６のレンダリングエンジンの新しいインスタンスを制御することによって、権利の集合に基づいてユーザに利用可能な機能を限定するＵＩモジュール２３４に対し権利の集合を伝送する。
【００４２】
文書の内容（コンテンツ）は、他のウェブページのどれもがそうであるように、ブラウザ２３２のウィンドウ内で目で見ることができる。しかしながら、ブラウザ２３２は、後述されるようにＵＩモジュール２３４又はセキュリティモジュール２３７の他の構成要素によって「ラップ」されるので、文書のウェブページへ直接アクセスすることができない。ＵＩモジュール２３４は、ブラウザ２３２が文書に対し権利の集合の範囲外で禁止された機能を実行しないようにする。
【００４３】
好ましい実施の形態は、ブラウザ、ワードプロセッサ、その他のアプリケーション又はディスプレイプログラム等の、アプリケーションプログラムの標準レンダリングエンジンを利用する。好ましい実施の形態では、アプリケーションとインタフェースをとり、アプリケーションと文書との間に位置して文書に対するアクセスを制御することによってこれを実現する。したがって、各文書フォーマットごとの個別の所有権を主張できるレンダリングエンジンは必要とされない。また、アプリケーションによってサポートされるデータフォーマットは、修正変更なく本発明によってサポートされる。好ましい実施の形態により、ＤＲＭシステムが、ＴＣＰ／ＩＰ、及びＨＴＭＬをレンダリングするブラウザの使用等の標準化されたものに適合可能とされることは理解できる。さらに、好ましい実施の形態が、ＤＲＭをユーザから見えない方法でシステムに適用可能とする種々の機能性を容易化する。文書配布システム２００の操作方法の数例は後述される。
【００４４】
第１の例において、クライアントコンピュータ２３０は当初、セキュリティモジュール２３７の必要な構成要素のすべてをインストールしているわけではない。図５に示されるように、クライアントコンピュータ２３０はステップ５０２において、１つ以上の文書２２２に対しディストリビュータ・サーバ２２０を要求する。ディストリビュータ・サーバ２２０はその要求を分析し、（セキュリティモジュール２３７の構成要素がクライアントコンピュータ２３０へロードされていないことを指示する）要求内の署名情報の欠如に基づいて、クライアントコンピュータ２３０に応答を送信してセキュリティモジュール２３７の必要な構成要素をロードする（ステップ５０４）。上述したように、セキュリティモジュール２３７はクライアントコンピュータ２３０における使用権を実施する機能がある。ステップ５０４において送信された応答は、コンテンツを要求するクライアントのタイプに特定である。クライアントコンピュータ２３０のクライアントソフトウェアがウェブブラウザである場合、例えば、ディストリビュータ・サーバ２２０が実行可能なソフトウェア構成要素を含むウェブページである応答を送信することになる。例えば、ソフトウェア構成要素は、Java（登録商標）スクリプト又はアクティブ・サーバ・ページ（Active Server Pages）等の標準形式であってもよい。さらに、応答、即ち、好ましい実施の形態におけるウェブページは、ステップ５０２で送信されたコンテンツの無署名の要求の複写を含む可能性がある。
【００４５】
クライアントコンピュータ２３０はウェブページを受信し、構成要素の複写を要求するために、ステップ５０６においてセキュリティモジュール２３７の構成要素をどこで取得するかに関する情報を含むソフトウェア構成要素を実行する。クライアントコンピュータ２３０は、ステップ５０８において、セキュリティモジュール２３７の構成要素を受信しインストールする。セキュリティモジュール２３７は、一例として上述されたメカニズムを用いて自動的にブラウザ２３２においてランを開始するように構成される。ステップ５１０では、セキュリティモジュール２３７が、同モジュール２３７を呼び出したウェブページに含まれるコンテンツ２２２に対する元の要求の複写を読み取り、ディジタルセキュリティ署名とともにディストリビュータ・サーバ２２０に対しその要求を再実行する。ステップ５１２では、ディストリビュータ・サーバ２２０が署名された要求を受信し、要求上の署名の妥当性を確認する。この要求はセキュリティモジュール２３７によって適切に署名されるので、ディストリビュータ・サーバ２２０は、文書のコンテンツ２２２に対応付けられる使用権及び使用条件にしたがって、ブラウザ２３２によるレンダリングのためにクライアントコンピュータ２３０にインストールされるセキュリティモジュール２３７に対し文書２２２を送付する。図５に示された方法は、ユーザが安全な方法でコンテンツ２２２をレンダリングする必要があるソフトウェアを途切れなく且つユーザが気付くことなくクライアントに提供するために、自動結合セキュリティ制御を提供する。セキュリティモジュール２３７は、クライアント環境が安全であることを確認するために、ステップ５０８において、レンダリングエンジン、又はクライアントコンピュータ２３０の他の構成要素を分析するように作動するソフトウェア・エージェントを含む可能性がある。セキュリティモジュール２３７は、このような確認をした後に、ステップ５１０において要求を再実行することができる。
【００４６】
図６は、好ましい実施の形態による操作の方法の別の例を示している。ステップ６０２において、セキュリティモジュール２３７は、ディストリビュータ・サーバ２２０からの文書２２２を検索するように指示される。この例では、文書２２２は「クリア・コンテンツ（明文のコンテンツ）」であり、言い換えれば、暗号化されず、又は隠ぺいされたり制限され、使用制約を何も持っていない。文書２２２はステップ６０４において、サーバ２２０によってセキュリティモジュール２３７に戻される。文書２２２が署名されてなかったり、暗号化されてなかったり、あるいは、セキュリティモジュール２３７によって処理される必要があるコンテンツとしてマーク付けされてないので、セキュリティモジュール２３７は同文書がもはや要求されていないことを認識する。ステップ６０６では、セキュリティモジュール２３７は、ブラウザ２３２がコンテンツの元の要求をサーバ２２０に直接送信することによって文書２２２を要求すべきであることをブラウザ２３２に通知する。セキュリティモジュール２３７は、ステップ６０８においてクライアントコンピュータ２３０のリソース（資源）を保存するために、それ自身を実行中の構成要素として除去し、即ち、非活動状態にする。ステップ６１０では、ブラウザ２３２は、当初セキュリティモジュール２３７によって送信された文書２２２の要求を再実行する。ディストリビュータ・サーバ２２０はステップ６１２で、文書２２２を直接ブラウザ２３２に転送する。
【００４７】
セキュリティを維持し使用権を行使するために、コンテンツへのすべての要求は最初、セキュリティモジュール２３７を介して行なわれる。しかしながら、要求がセキュリティを要求しないコンテンツを戻す時、セキュリティモジュール２３７はコンピュータリソースを利用するために、潜在的に不都合なものとなる。この例では、セキュリティ構成要素２３７が必要とされない場合、実行状態から移動される。
【００４８】
システム２００は、ＰＫＩ暗号化技術、又はその他の暗号化、サイファリング（ciphering）、若しくはウォータマーキング技術を使用することができる。もちろん、これらの技術では、コンテンツへの要求をするクライアントが許可されたユーザとして識別されることが必要とされる。ディジタル証書や署名は識別する目的のために使用可能である。言い換えれば、識別する目的のために使用される電子メッセージへの添付物はメッセージとともに送信される。ディジタル証書や署名の最も一般的な用途は、メッセージを送信するユーザが主張している本人であることを確認し、受信者に対して応答を符号化する手段、例えば、暗号化キーを付与することである。暗号化メッセージの送信を希望する個人は、認証局（ＣＡ）からのディジタル証書を申請することができる。認証局は、申し込み者の公開鍵（パブリックキー）及び他の種々の識別情報を含む暗号化ディジタル証書を発行する。認証局はその公開鍵を、例えば、インターネットを介して容易に利用できるようにする。暗号化メッセージの受信者は認証局の公開鍵を用いてメッセージに添付されたディジタル証書を復号化し、それを認証局により発行されたものとして確認し、送信者の公開鍵、及び証書内に含まれる識別情報を取得する。この情報によって、受信者は暗号化された応答を送信することができる。ディジタル証書の最も広範囲に使用される規格はＸ．５０９である。
【００４９】
この識別プロセスは、コンテンツが要求される各サーバにおいて繰り返される時に扱いにくい可能性がある。図７は、複数のサーバにおける識別手順が効率化される好ましい実施の形態による操作の方法の別の例を示している。
【００５０】
図７に示されるように、ステップ７０２では、クライアントコンピュータ２３０が、ディストリビュータ・サーバ２２０からの文書２２２を要求する。ＰＫＩ暗号化方式が使用されると仮定すれば、その要求は、クライアントコンピュータ２３０の秘密鍵（プライベートキー）で暗号化される「PrivateClient[request]」の形式である可能性がある。ディストリビュータ・サーバ２２０は要求の署名を見て、その要求が許可されたクライアントからでないことを認識し、クライアントコンピュータ２３０に戻される固有の「チャレンジ」トークンを生成する（ステップ７０４）。好ましい実施の形態では、チャレンジトークンは、ディストリビュータ・サーバ２２０の秘密鍵を用いて元の暗号化要求が再び暗号化される「PrivateServer[PrivateClient[request]」の形式であってもよい。
【００５１】
クライアントコンピュータ２３０は、ステップ７０６において、チャレンジを固有の方法で変換する、即ち、チャレンジトークンを署名することによってそのチャレンジトークンに応答する。例えば、その変換は、ディストリビュータ・サーバ２２０の秘密鍵によるチャレンジトークンの暗号化の形式をとる可能性がある。このような場合、変換は「PublicClient[PrivateServer[PrivateClient[request]]]の形式になる。クライアントコンピュータ２３０はステップ７０８において、変換されたチャレンジトークンでディストリビュータ・サーバ２２０への要求を再実行する。ディストリビュータ・サーバ２２０は、その変換を認識することによって、即ち、チャレンジトークンをそれ自身として認識することによってクライアントによる認証を設定し、要求された文書２２２を戻す（ステップ７１０）。
【００５２】
多くの場合、ディストリビュータ・サーバ２２０は、サーバファーム、又は上記のような関連コンピュータの他の集合の一部である。したがって、このセッションへの次の要求を取得するサーバが実際、「チャレンジ」トークンを生成した同じサーバであることを保証するものではない。例えば、次のセッション要求はディストリビュータ・サーバ２２０'によって受信されることもできる。クライアントコンピュータ２３０が同じチャレンジトークンを再使用する別の要求を送信し、その要求がディストリビュータ・サーバ２２０'によって受信される時（ステップ７１２）、ディストリビュータ・サーバ２２０'はチャレンジトークンの署名を探し、その署名がディストリビュータ・サーバ２２０'に所属することを見い出す（ステップ７１４）。ディストリビュータ・サーバ２２０がディストリビュータ・サーバ２２０'と信頼関係にあるので、ディストリビュータ・サーバ２２０'はディストリビュータ・サーバ２２０のチャレンジトークンを引き受けることになる。特に、ディストリビュータ・サーバ２２０'は、クライアントによって実行されるチャレンジトークンの変換を評価し、サーバ２２０をチャレンジトークンの作成者として識別することによってそのクライアントを認証する。ステップ７１６では、コンテンツ２２２'がディストリビュータ・サーバ２２０'からクライアントコンピュータ２３０に転送される。
【００５３】
この操作の方法では、他の関連サーバによってサポートされるトークンが、要求を受信するサーバによって引き受けられる。このプロセスを簡略化するために、鍵は再び交換されない。関連サーバとの前回の鍵交換の承認は、認証のプロセスを加速化するために関連サーバのグループにおける他のサーバに対し使用される。
【００５４】
上述したように、標準レンダリングエンジンの使用は、ＤＲＭシステムに対し著しく複雑な状態を示している。例えば、ブラウザをレンダリングエンジンとして使用する場合、標準ユーザインタフェースは複写及び印刷コマンド、及びＤＲＭシステムとは必ずしも互換性のない他のコマンドを含む。ウィンドウズ（登録商標）ＧＵＩ等の大部分のＧＵＩが使用禁止コマンドに対応するメニュー選択を影付け（シャドーイング）するようなコマンドを使用禁止にすることは周知である。しかしながら、これは多くの場合、複雑であり、欲求を抑える上で満足できるものではない。また、支払われる料金等の使用権及びその行使のための条件の選択などの、コンテンツ特有のメニュー選択を提供することは望ましい。さらに、コンテンツのベンダーが所有権を主張できるブランドが付いたユーザインタフェースや、他のベンダーと整合するユーザインタフェースを提示しようとすることもある。また、ある状況のもとで印刷ボタン等のメニュー選択を強調表示することも望ましい。
【００５５】
図８は、コンテンツ特有のツールバーをブラウザ２３２のユーザインタフェースとして表示可能とする好ましい実施の形態による操作の方法を示している。文書２２２は上記のように、レンダリングアプリケーション、即ち、好ましい実施の形態ではウェブページ、と互換性のある形式でディストリビュータ・サーバ２２０に記憶される。文書２２２は図９において詳細に示され、ソフトウェア構成要素２２０ａに対する参照Ａと、ブラウザのツールバーとＵＩ２２０ｂの記述に対する参照Ｂと、を含む。ソフトウェア構成要素２２０ａは、Java（登録商標）アプレット、ActiveXコントロール等の形式をとる可能性がある。コンテンツがレンダリングされると、ソフトウェア構成要素に対する参照がブラウザ、即ち、ActiveXコントロール、Java（登録商標）アプレットによって識別される。
【００５６】
図８を参照すると、ステップ８０２において、ブラウザ２３２は文書２２２を要求する。ブラウザ２３２は文書２２２をレンダリングしようと試み、参照Ａに従って、ソフトウェア構成要素２２０ａを実行する（ステップ８０４）。ソフトウェア構成要素２２０ａは、それを呼び出したコンテンツ２２２を見て、ステップ８０６においてツールバーとＵＩ２２０ｂの記述に対する参照Ｂを識別する。ソフトウェア構成要素２２０ａは、ステップ８０８において、記述２２０ｂに基づいてプラットフォーム／ブラウザ特有のツールバーとＵＩを構築するように作動する。ステップ８１０では、ソフトウェア構成要素２２０ａが、標準ブラウザＵＩ及びツールバーを削除又は隠ぺいし、それらをステップ８０８で構築されたものに置き換える。この操作方法により、ウェブサイト（この場合、サーバ２００用のディストリビュータ）がナビゲーションのモチーフ、見た目、及び外観を決定し、これにより、サイト、カスタマイズ・ボタン、色、パターン、アニメーション、メニュー、及びツールバーに対しユーザのブラウザを調整する。
【００５７】
図１０は、クライアント特有の又は更にはインスタンス特有のウォータマークがセキュリティ及びトラッキングの目的のためにコンテンツに適用可能である、好ましい実施の形態による操作の別の方法を示している。ディジタル「ウォータマーキング」の概念は一般に周知であり、コンテンツの所有者にグラフィックス及びこれらの作業に対する所有者の権利を識別するために使用できるオーディオ・ファイル内に情報を組み込ませることができる。「ディジタル・ウォータマーク（電子透かし）」という用語は、高品質レターヘッド及び一定のカレンシーに存在する従来のウォータマークから来ている。従来のウォータマークは一般に、リーダーから視覚的にはっきり見えないが、光にさらされると、製紙会社の名称又はロゴ、あるいはレターヘッドを用いたエンティティを明らかにする。同様に、ディジタル・ウォータマークはまた、品質を識別し、信憑性を保証する目的を果たす。ディジタル・ウォータマークを有するグラフィック又はオーディオファイルは、コンテンツの所有者に関する情報や、他の情報を含む可能性がある。ディジタル・ウォータマークは、例えば、コンテンツが無許可の方法で印刷されるような時、ある条件のもとでのみ知覚可能であることもある。グラフィック画像では、例えば、ディジタル・ウォータマークは画像を変更して、ウォータマークを組み込んだ当事者によって供給されるディジタル情報を提供する。ウォータマークは、スタンドアロン又はプラグインのソフトウェアで見られ、例えば、著作権の所有者又他は更に完全な著作権者情報にトレース可能な固有の識別コードを明らかにすることができる。
【００５８】
図１０に示されるように、クライアントコンピュータ２３０は通信チャネル３００上でディストリビュータ・サーバ２２０から文書２２２を要求する（ステップ１００２）。ディストリビュータ・サーバ２２０は文書２２２をセキュリティモジュール２３７に転送する（ステップ１００４）。セキュリティモジュール２３７に送られた文書２２２にはウォータマークが組み込まれていてもいなくてもよいものとする。ステップ１００６では、セキュリティモジュール２３７は、上述のような方法でレンダリングするために、文書２２２をレンダリングエンジンのインスタンス、好ましい実施の形態ではブラウザ２３２に転送する。セキュリティモジュール２３７は、レンダリングエンジンのインスタンスが使用するウィンドウにクライアント特有のウォータマークを適用するためにコンテンツ２２２をレンダリングするために使用されるレンダリングエンジンのインスタンスに関するインスタンス特有の情報を使用する。クライアント特有のウォータマークは、ウォータマーキングのための技術又はアルゴリズムを用いて適用可能である。さらに、クライアント特有のウォータマークは既存のウォータマークに付加して適用可能である。クライアント特有のウォータマークデータはいずれの方法で記憶又は生成することができる。
【００５９】
いずれの場合も、ウォータマークがクライアント上に付加されるので、そのクライアントに固有であり、したがって追跡可能である。ディストリビュータ・サーバ２２０は同一の文書２２２をすべてのクライアントに伝送することができる（したがって、サーバ側の性能の影響を最小限にする）。クライアントは、例えば、半透明なウィンドウを用いて、画像に固有のウォータマークを付加する。コンテンツの需要者がスクリーンキャプチャ又は別の無許可メカニズムを用いてコンテンツを取得する場合、取得されたコンテンツは、トラッキング及び実施する目的のためにそのユーザに固有のＩＤでウォータマーク付けされる。
【００６０】
図１１は、トランザクションの支払いが容易に統合される好ましい実施の形態による使用法を示している。ステップ１１０２において、クライアントコンピュータ２３０は、セキュリティモジュール２３７の必要な構成要素のインストールの前に、ディストリビュータ・サーバ２２０から文書２２２を要求する。ステップ１１０４では、ディストリビュータ・サーバ２２０がクライアントコンピュータ２３０に対し、文書２２２が保護され、クライアントコンピュータ２３０が文書２２２をレンダリングするためにセキュリティモジュール２３７を有する必要があることを通知し、そこでセキュリティモジュール２３７が取得できる。この場合、セキュリティモジュール２３７は、トランザクション・アグリゲータ１６０（図１参照）と対応付けられるコンピュータから取得できる。ステップ１１０６では、クライアントコンピュータ２３０は、トランザクション・アグリゲータ１６０と対応付けられるコンピュータでセッションをオープンすることによってトランザクション・アグリゲータ１６０からのセキュリティモジュール２３７の必要な構成要素を要求する。ステップ１１０８において、トランザクション・アグリゲータ１６０は、例えば、従来の方法でビリング（請求書作成）情報等を含む種々のユーザ情報を要求し収集する。
【００６１】
トランザクション・アグリゲータ１６０は、固有の隠し公開鍵／秘密鍵の対又はクライアントコンピュータ２３０の同一性を示すその他指標で固有のセキュリティモジュール２３７を生成し、ステップ１１１０においてセキュリティモジュール２３７をクライアントコンピュータ２３０に戻す。セキュリティモジュール２３７は、ブラウザ２３２の保護されたインスタンス、又は他の第三者のレンダリング・アプリケーションを作成し、その周辺でアクセス保護を実行し、ディストリビュータ・サーバ２２０からの保護されたコンテンツ２２２を検索しレンダリングするように指示する（ステップ１１１２）。ディストリビュータ・サーバ２２０は、セキュリティモジュール２３７によって保護されているレンダリングエンジンによって文書２２２が要求中であることを認識する。そして文書２２２を戻す。
【００６２】
保護されたレンダリングアプリケーション、例えば、セキュリティモジュール２３７が添付されたブラウザ２３２は、セキュリティモジュール２３７に、文書２２２をレンダリングしようとしていることを通知する。ステップ１１１４において、セキュリティモジュール２３７は、どのディジタル権利が文書２２２に対応付けられるかを分析し、トランザクション・アグリゲータ１６０に戻って適切な料金を記録する。トランザクション・アグリゲータ１６０は、この公開鍵／秘密鍵のインスタンスによってアクセスされるコンテンツの多くの形式に対して実行される多くの小さなトランザクションをトラッキングし、それらを定期的に金融機関又はセキュリティモジュール２３７におけるインデックスに対応付けられる相手方に対し単一の料金に統合する。
【００６３】
図１１の方法は、ユーザを新しいウェブサイトにログオンさせて、トランザクションを開始することを可能にする。ユーザの情報が信頼できるサイト（トランザクション・アグリゲータ１６０等）で既にファイル上にある場合、新しいウェブサイトがその信頼できるサイトにわたってユーザを確認する。信頼できるサイトはトランザクションのすべてを調整し、例えば月一回等の、定期的に適切なエンティティに対し結果を送信する。したがって、（しばしば小額料金の）トランザクションを処理する負担はディストリビュータ又はクレジットエージェンシー（信用調査機関）からアグリゲータにシフトされ、このことはトランザクションの全体コストを低減する。
【００６４】
新しいウェブサイトは、ユーザの詳細な情報を得る必要がなく、これはプライバシーの問題に対する懸念を低減する。さらに、新しいウェブサイトへのログインプロセスは簡略化される。ウェブサイトが信頼できるサイトに送信された匿名ＩＤのみを使用し、その信頼できるサイトのみがユーザの個人・信用情報を有するので、ユーザの情報はユーザが処理している新しいウェブサイトから保護される。
【００６５】
好ましい実施の形態による別の方法では、サーバ側の実行可能構成要素を必要とせずにセキュリティのためのディレクトリの不明化（obfuscation）が利用されている。図１２に示されるように、コンテンツの所有者、又は文書２２２に関心のある相手方は、ランダムな名称又は見付けるのが困難な名称によって、ディストリビュータ・サーバ２００上にサブディレクトリを作成して、ここが文書２２２の安全な場所としての役割を果たす（ステップ１２０２）。関係者は、セキュリティモジュール２３７に対する参照、及び文書２２２の新しい安全な場所の暗号化形式を有するウェブページを作成する（ステップ１２０４）。保護された文書２２２は、ステップ１２０６においてウェブページと置き換えられ、その保護された文書２２２は安全なディレクトリに移動される。
【００６６】
ステップ１２０８では、クライアントコンピュータ２３０は要求を発行して、上記の方法で元のディレクトリからの文書２２２を検索する。暗号化されたコンテンツの安全な場所を内部に有するセキュリティウェブページは要求された文書の代わりに戻される（ステップ１２１０）。セキュリティモジュール２３７は、ウェブページによって参照されたコンテンツの場所を暗号解読し、安全な場所からの文書２２２を要求する（ステップ１２１２）。このコンテンツは、保護されたレンダリングエンジンのインスタンス、例えば、好ましい実施の形態ではブラウザ２３２、を作成するセキュリティモジュール２３７に伝送され、文書２２２をレンダリングする（ステップ１２１４）。
【００６７】
上記の操作の方法では、サーバ側の実行可能構成要素を必要とせず、このため、適切な、但し、必ずしも最大限でないセキュリティを提供する低コストの方法である。この例では、コンテンツは、セキュリティの目的上、ランダム数（あるいは擬似ランダム数）によって決定されるアドレスを有する位置に記憶される。ユーザがトランザクションを開始する時、ユーザには暗号化形式の位置を有するＨＴＭＬページが提示される。セキュリティ構成要素がその位置を解読し、クライアントがその位置を決して見つけることはない。
【００６８】
図１３は、セキュリティのための相対アドレス指定を利用する好ましい実施の形態による操作の別の方法を示している。ステップ１３０２では、クライアントコンピュータ２３０のウェブブラウザ２３２がディストリビュータ・サーバ２２０からのコンテンツを要求する。ディストリビュータ・サーバ２２０はそのコンテンツ要求が適切なセキュリティモジュール２３７から来ていないことを（例えば、適切な署名の欠如によって）認識するので、クライアントコンピュータ２３０にセキュリティモジュール２３７の必要な構成要素をロードさせるように指示する（ステップ１３０４）。ステップ１３０６では、セキュリティモジュール２３７が、子（チャイルド）ＨＴＭＬレンダリングエンジン、即ち、ブラウザ２３２のインスタンス、をブラウザ２３２の既存のインスタンス内部で生じさせるので、子ＨＴＭＬレンダリングエンジンを完全に制御することができる。セキュリティモジュール２３７は子インスタンスに、通常のＨＴＴＰプロトコル及びアドレス指定を介する代わりにセキュリティモジュール２３７にインストールされた非同期プロトコルを介してコンテンツを検索するように指示する（ステップ１３０８）。例えば、非同期プロトコルは、安全で許可された通信チャネルを確立するために組み込まれたActiveXコントロールを備えたＨＴＭＬであってもよい。非同期プロトコルは、好ましくないか又は無許可のユーザからのアクセスを避けるためのフィルター技術を含む別のウェブサイトを介してコンテンツを検索するようにブラウザ２３２を方向付ける。ステップ１３１０では、文書２２２がレンダリングされる。
【００６９】
例えば、非同期プロトコルは、ユーザが要望されて許可されることを検証するために第三者に対しユーザのアドレスを送信することができる。非同期プロトコルは、ブラウザ２３２の子インスタンスに、指定された安全なウェブサイトを介して最上位ＨＴＭＬページを要求させることができる。最上位ページがロードした後で、子インスタンスはページの構成部分のすべてを検索するためにアドレスプレフィックスを使用することができる。保護されていないコンテンツは標準ＨＴＴＰを介して検索可能である。
【００７０】
一般に、セキュリティはレンダリングのためにＨＴＭＬに付与される。しかしながら、この例では、コンテンツは所有権を有する非同期プロトコルを用いて検索される。したがって、ＨＴＭＬレンダリングエンジンの単一のインスタンスはコンテンツの複合部分を「引き出す（プルする）」ために使用できる。一例として、標準ＨＴＭＬレンダリングは、内部にActiveXコントロールを含む開始ウェブページにアクセスするために使用可能である。このコントロールは、特定のサーバを介してコンテンツを検索し、サーバ側にアクセスし、フィルタリング技術等を含む、子レンダリングエンジンを生じさせる。ウェブページ（複合文書）が他のファイル及び画像に対し参照を有することに留意すべきである。従来、上位（ＨＴＭＬページ）のみが保護され、その参照先は保護されていなかった。しかしながら、この例では、要求が保証されたサーバを介して処理されるので、上位及びその参照がともに安全である。
【００７１】
図１４は好ましい実施の形態による操作の別の方法を示している。この方法は、プラグイン及びダイナミックリンク・ライブラリ（ＤＬＬ）等のコードが暗号漏えいセキュリティではないとして認証されなければ、該コードのレンダリンクエンジンへのローディングを禁止することによってセキュリティを提供する。この方法では、認証がダイナミックプロセスであり、認証されるとすぐにユーザが認証されたソフトウェアを使用することを許可すべきであると認識される。
【００７２】
ステップ１４０２では、クライアントコンピュータ２３０のセキュリティモジュール２３７は、レンダリングアプリケーション、即ち、好ましい実施の形態ではブラウザ２３２のインスタンスをロードする。ブラウザ２３２はＤＬＬ等の第三者のアドイン・プラグラムをロードするように要求する（ステップ１４０４）。セキュリティモジュール２３７はその要求を傍受し、信頼且つ認証された第三者のアドイン・プラグラムのリストを含むローカルデータベース２２５に問い合わせる（ステップ１４０６）。セキュリティモジュール２３７がロードしようとする第三者のプログラムを見付けられない場合、セキュリティモジュール２３７は信頼できるサーバにコンタクトして、ステップ１４０８で認証されている信頼できる第三者のプログラムのデータベースを更新する。第三者のプログラムが更新リスト内に見出されると、セキュリティモジュール２３７が第三者のプログラムをレンダリングエンジンへローディングすることを許可する（ステップ１４１０）。ステップ１４０６においてプログラムがデータベース２２５にリストアップされていることによって認証されると判断された場合、この方法は直接ステップ１４１０へ進む。ステップ１４０８においてプログラムが認証されているものとして更新されたデータベースにないと判断された場合、ローディングは禁止される（ステップ１４１２）。
【００７３】
レンダリングアプリケーションが実行可能コードをロードすることを要望する時はいつでも、それは暗号漏えいセキュリティを回避するために、承認（即ち、認証）される。セイキュリティ構成要素の出荷時に第三者の製品が認証される状態にない場合、セキュリティモジュールの承認されたリストに含まれることはできない。プログラムが後で承認される場合、プログラムの署名が、認証データベース、例えば、データベース２２５を更新して有するサーバにログオンすることによって更新されるリストと比較される。
【００７４】
図１５は、ビデオ形式又は他の大きなファイル形式にあるコンテンツの転送に好適な好ましい実施の形態による操作の方法を示している。データの一部のみを暗号化してセキュリティのレベルを依然として付与しながらオーバーヘッド及びデータ転送速度を低減することはよく知られている。しかしながら、図１５に示された方法において、データストリームの暗号化の割合は、ネットワーク待ち時間、接続速度、及びその他の要因に基づいて適応できる。ステップ１５０２において、文書２２２はクライアントコンピュータ２３０によって要求される。ディストリビュータ・サーバ２２０は、データベース、使用権、又は文書２２２に対応付けられる暗号化の他の表示を検査することによって使用する暗号化の割合を決定する。このような情報はディジタル権利マネジャーモジュール２に記憶されることができる。例えば、暗号化の表示は、暗号化が特定の割合よりも大きいか、又は特定の割合の範囲内にあるかを特定することができる。
【００７５】
ステップ１５０６では、ディストリビュータ・サーバ２２０が、文書２２２のファイルサイズ、ネットワーク待ち時間、通信速度等のデータ転送に関する種々の条件を周知の方法で監視する。ステップ１５０８において、ディストリビュータ・サーバ２２０がステップ１５０６で監視された条件及びステップ１５０４において決定された暗号化の量に基づいて文書２２２の一部を暗号化する。ステップ１５０６及び１５０８は、文書２２２のすべてが転送されるまで連続的又は繰り返して実施される。ステップ１５１０では、セキュリティモジュール２３７がコンテンツを解読し、それをレンダリングアプリケーション、即ち、好ましい実施の形態ではブラウザ２３２に伝送する。
【００７６】
データストリームの可変部分（割合）は暗号化が可能である。コンテンツデータは時間間隔又はバイトサイズに基づいて分割可能である。例えば、１０バイトが暗号化され、９０バイトは暗号化されない。暗号化の割合は適応性がある。即ち、異なった時間におけるデータファイルサイズ及びその他の条件に応じて、暗号化の割合はプロセスを加速化するために特定された値の範囲で変動することができる。
【００７７】
署名及び他のセキュリティ情報をＨＴＴＰ文書の本体に組み込むことは周知である。しかしながら、このような方法は特別なセキュリティタグを必要とし、セキュリティ情報が文書から解析されなければならないために管理するのが困難である。しかしながら、図１６に示された好ましい実施の形態による操作の方法は、セキュリティ情報を伝達するためにＨＴＭＬ文書のヘッダのみを使用することによってこの操作を簡略化する。
【００７８】
ステップ１６０２では、セキュリティモジュール２３７によって調整されるブラウザ２３２はディストリビュータ・サーバ２２０からの文書２２２を要求し、セキュリティモジュール２３７はディストリビュータ・サーバ２２０への標準ＨＴＴＰ又はＨＴＴＰＳ接続を開通させる。ステップ１６０４では、標準ＨＴＴＰサーバとしての働きをするディストリビュータ・サーバ２２０は、ダウンロードするために文書２２２を検索又は構築する。特に、ディジタル権利管理モジュール２２４又はディストリビュータ・サーバ２２０の別のセキュリティモジュール構成要素は、ＨＴＴＰ要求のヘッダに組み込まれたセキュリティ情報を分析することによって要求中のクライアントを認証し、標準ＨＴＴＰ応答を構築する。
【００７９】
ステップ１６０６では、ディストリビュータ・サーバ２２０がセキュリティ情報をＨＴＴＰ応答のヘッダに挿入する。例えば、署名等のセキュリティ情報は、以下に示すＨＴＭＬ文書における<Header>タグの属性であってもよい。
<Header>signature＝13490680486724869 MY BOOK<Header/>
【００８０】
上記の例では、ＨＴＭＬページのタイトルは「ＭＹ  ＢＯＯＫ」であり、標準ＨＴＭＬ規則に従ってレンダリングされる。署名はヘッダの属性としての数であり、レンダリングされないが、セキュリティの目的のために選別除去可能である。ステップ１６０８では、応答がクライアントコンピュータ２３０のセキュリティモジュール２３７に送信される。ステップ１６１０では、セキュリティモジュール２３７が応答ヘッダのセキュリティ情報を分析し、セキュリティ情報によって記述されるか、セキュリティ情報に対応付けられる使用権に従ってレンダリングするために、文書２２２のコンテンツをブラウザ２３２に送信する。
【００８１】
セキュリティ情報のすべてがヘッダに含まれるので、結果としてのＤＲＭシステムは侵入度が低下し、より管理し易くなる。また、新しいセキュリティタグ方式又はその他の詳細は不要である。セキュリティ構成要素はセキュリティ情報を得るために、ただヘッダを見て識別するだけでよい。
【００８２】
多くの場合、コンテンツ及び使用権は動的である。例えば、コンテンツは時間とともに変化し、使用権も時間とともに変化し、コンテンツへの要求がどこに由来しているかによっても左右されることがある。例えば、その文書がサイト内から、あるいは安全なコンピュータから要求される場合、会社は従業員に対しその文書を印刷又は保存させることを要望することがある。しかしながら、同じ文書をホームから要求する同じ従業員はその文書を見ることが許可されるだけである。図１７は、これらの問題をアドレスするためにアドレス及びＵＲＬフィルタリングをともに提供する、好ましい実施の形態による使用方法を示している。
【００８３】
ステップ１７０２において、セキュリティモジュール２３７を有するクライアントコンピュータ２３０は安全な文書２２２を要求する。ステップ１７０４では、ディストリビュータ・サーバ２２０がコンテンツ２２２の静的又は動的ソースから情報を収集し、周知の方法で応答を構築する。応答が構築された後で、セキュリティモジュール２３７のサーバ側構成要素は、ＵＲＬの正規表現を使用権にマップするデータベース２２５にアクセスする（ステップ１７０６）。セキュリティモジュール２３７のサーバ側構成要素は、データベース２２５におけるＵＲＬに対応する権利を選択することによって、要求のＵＲＬに基づく応答に対応付けられる権利を挿入する（ステップ１７０８）。この応答は、セキュリティモジュール２３７のクライアント側構成要素による制御のもとで、挿入された使用権に従って要求されたコンテンツ２２２のレンダリングのためにクライアントコンピュータ２３０に送信される。
【００８４】
ＵＲＬアドレス指定及びディレクトリ・アドレス指定がともに使用されるので、動的コンテンツ、及びこの次の要求ＵＲＬによって最適に識別されるコンテンツは適切に処理可能である。たとえＵＲＬがサーバ上に記憶されたファイルに到達するために使用されるとしても、ディストリビュータ・サーバ２２０上にファイルとして記憶されたコンテンツが無許可のユーザに伝送不能であるというハイレベルの信頼を提供するために、ディレクトリはフィルター処理される。両タイプのフィルターを使用することによって、コンテンツ所有者がどのコンテンツを保護すべきか、またどの程度保護すべきかを決定する時の柔軟性を備えている。さらに、セキュリティコンテンツをＨＴＭＬ文書のヘッダに置くことにより、動的コンテンツが容易に処理可能とされ、これは、コンテンツの本体がセキュリティのために修正変更される必要がなく、これにより、動的コンテンツが文書をオンザフライ（on the fly）で構築するために使用可能とするからである。
【００８５】
特に、インターネット又はその他のネットワーク上でコンテンツを配布する際に、しばしばコンテンツのレンダリングが直面する別の問題は、ユーザが適切なレンダリングアプリケーションを常に持っているとは限らないことである。例えば、ＰＤＦファイルをダウンロードする際に、コンテンツ提供者はユーザに対し、Adobe Acrobat Reader（アドビ・アクロバット・リーダ（商標））が要求されることを通告し、ソフトウェアをダウンロードするためにリンクを提供することがある。ユーザがソフトウェアをダウンロードしない場合、コンテンツをレンダリングすることはできない。しかしながら、ソフトウェアをダウンロードすることは、見る側における重要な動作、例えば、リンク上のクリック、ダウンロード用のディレクトリの選択、導入ソフトウェアの実行等を必要とする。多くの場合、ユーザは適切なレンダリングアプリケーションをインストールする厄介なプロセスを回避するためにコンテンツをダウンロードしないように選択することになる。ＤＲＭシステムにおいて、セキュリティ構成要素が新しくインストールされたレンダリングアプリケーションに接続されない場合、多数のレンダリングアプリケーションの必要性により、セキュリティ問題が提起される。
【００８６】
図１８は、ユーザから見えないように適切なレンダリングアプリケーションを提供するための使用法を示している。ステップ１８０２において、クライアントコンピュータ２３０は、ブラウザ２３２によるレンダリングが不能なファイルフォーマットの文書２２２を要求する。ステップ１８０４では、文書２２２は同じフォーマットのファイルとしてパッケージされるが、ＨＴＭＬファイルとして「偽装」される。例えば、ウィンドウズ（登録商標）オペレーティングシステムがファイル拡張子によってファイルタイプを識別する。このような場合、ファイル、例えば、ＰＤＦファイルは、クライアントコンピュータ２３０によるＨＴＭＬファイルとして識別される「ＨＴＭ」拡張子で命名されることができる。
【００８７】
ステップ１８０６では、ファイルはクライアントコンピュータ２３０にダウンロードされ、ユーザはクライアントコンピュータ２３０がＨＴＭＬファイルとして認識したファイルを「オープン」する。したがって、ブラウザ２３２はデフォルトＨＴＭＬビューアとして立ち上げられる。ステップ１８０８では、ブラウザ２３２はＨＴＭＬのレンダリングを開始し、ActiveXコントロール又はJava（登録商標）アプレットのような組み込み型アプリケーションに対する参照を見出す。ブラウザ組み込み型アプリケーションはブラウザ２３２に、参照されたアプリケーションがクライアントコンピュータ２３０にインストールされていないことを検出する（ステップ１８１０）。ブラウザは、ステップ１８１２においてアプリケーションをダウンロードするためにファイル内の参照に従い、アプリケーションは上記のように、クライアントコンピュータ２３０にインストールされ、セキュリティモジュール２３７に添付される。レンダリングアプリケーションとして使用されているアプリケーションは、セキュリティモジュール２３７によって方向付けられて、ＨＴＭＬファイル内からコンテンツを検索し、そのコンテンツをレンダリングする（ステップ１８１４）。
【００８８】
新しいファイルタイプ拡張子を配布することの欠点は、ユーザが相手方のデータファイルの１つを受信し、その要求を処理するアプリケーションが未登録である場合、ユーザがそのコンテンツで作業を続けられなかったり、手動で新しいアプリケーションをインストールしなければならないことである。しかしながら、新しいファイルタイプがＨＴＭＬファイル内部にパッケージされると、ウェブブラウザは、ＨＴＭＬファイルをロードし、自動的にそのコード（Java（登録商標）スクリプト等）を見出す。そのコードがクライアントプラットフォーム上の登録されたアプリケーションを認識した場合、含まれたデータをそのクライアントアプリケーションに送信する。データタイプを処理するアプリケーションが見つからない場合、ブラウザを呼出して、適切なレンダリングアプリケーションをダウンロードするサイトにナビゲートする。
【００８９】
インターネット等のネットワーク上にコンテンツを配布する際の別のセキュリティ問題は、ハッカーがメッセージを妨害し、暗号化ルーチンを「破壊」して保護されたコンテンツへのアクセスを取得する可能性があることである。しかしながら、暗号化を回避することにより、多くの場合、比較的長い時間（例えば、数秒）を必要とするのは、複雑なソフトウェアアルゴリズムを実行したり、乱数を生成する必要があるからである。図１９は、暗号化回避のリスクが短時間後に失効するトークンを生成することによって軽減される、好ましい実施の形態による操作の方法を示している。
【００９０】
ステップ１９０２において、クライアントコンピュータが安全なコンテンツ２２２を要求する。セキュリティモジュール２３７のサーバ側セキュリティ構成要素がクライアントコンピュータ２３０を認証していないと仮定して、ディストリビュータ・サーバ１２０は、タイムスタンプ（時刻表示）されたチャレンジトークンを生成する（ステップ１９０４）。クライアントコンピュータ２３０がそのトークンを受信し、その非固有の公開鍵／秘密鍵の対を使用して要求を追加しそれを周知の方法で署名し（ステップ１９０６）、その署名されたトークンをディストリビュータ・サーバ２２０に戻す。その署名されたトークンを受信すると、ディストリビュータ・サーバ２２０はクライアントコンピュータ２３０の署名を確認し、タイムスタンプを検査することによってそのトークンがいつ生成されたかをしらべる（ステップ１９０８）。そのトークンが所定時間、例えば、署名された方法で受信されるよりも０．５秒より以前に生成された場合、たとえ署名が正しくても、そのトークンはもはや有効ではなく、コンテンツ２２２へのアクセスが拒絶されることになる（ステップ１９１０）。
【００９１】
タイムスタンプは、署名がどの程度長く有効であるか（通常、適切な署名を許可し、暗号化の漏えいを許可しない非常に短い時間）、又は、署名が作成される時間を表示することができる。無許可の相手がそのメッセージを妨害し、後でそのメッセージを模倣しようとする場合、その署名は期限切れとなって有効ではない。
【００９２】
いずれのタイプの通信ハードウェア及びプロトコルを使用しても、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、直接コンピュータ接続等の通信ネットワーク上で本発明は実施可能である。種々のクライアント及びサーバに対し、いずれのタイプのハードウェア又はハードウェアの組み合わせも使用できる。したがって、本明細書において使用されるような「クライアント」及び「サーバ」という言葉は、いずれのタイプのコンピュータ装置又はデータ端末、例えば、パーソナルコンピュータ、ポータブルコンピュータ、ダムターミナル、小型軽量クライアント、手持ち式装置、無線電話、又はこれらの装置の組み合わせに言及することができる。種々のクライアント及びサーバは、単一の場所にある単一のコンピュータであったり、単一又は多数の場所にある多数のコンピュータである可能性がある。例えば、サーバは、スケーラビリティ（拡張性）を容易にするために種々の位置における共同配置設備に配置される複数の冗長コンピュータから構成されることもある。クライアント及びサーバの数はそれぞれどのような数でもよい。クライアントは物理的にサーバと同じハードウェア上に設置される可能性がある。
【００９３】
適切なサーバ又はクライアントソフトウェアであれば使用でき、何れの通信プロトコルもまた使用できる。無線周波数、赤外線、又は他の技術を用いた無線方式により、電気ケーブル、光ファイバ回線、又はその他の回線上で通信が実行できる。種々の情報はどのフォーマットでも記憶でき、従って、本明細書で使用される「データベース」という言葉は、データベースファイル、ルックアップ・テーブル等の情報の収集に言及する。文書は何れのタイプでもよく、テキスト、オーディオ情報、ビデオ情報、又は複数のタイプのコンテンツの組み合わせ等の何れのタイプのコンテンツも含むことができる。ソフトウェア構成要素として記載された上記本発明の一部はハードウェアとして実施することもできる。さらに、特定の機能ブロックが別個に、それぞれ独立して記載されているが、これらの機能ブロックは単一の汎用コンピュータ上で確立され実行されたり、さらには当該技術において認識されるようにサブ機能に分類されることもある。権利の集合は文書の使用を決定する１つ以上の権利又は規則であったり、適切な形式であったり、さらには、文書タイプ、ユーザの同一性、ユーザによる支払い等の種々のパラメータに基づくこともある。種々のソフトウェアモジュールはクライアント又はサーバ上に設置されることもある。例えば、セキュリティモジュールは、上記の種々の機能を実施するのに適切であるとしてサーバ側及び／又はクライアント側の１つ又は複数の構成要素を含むことがある。
【００９４】
本発明の好ましい実施の形態を上記で詳しく述べてきたが、本発明のその他の形式、代替例、変更例、及び変形等が同様に有効であり、当業者に理解できることを認識すべきである。その開示は本発明を特定の実施の形態に限定するためのものではなく、このような形式、代替例、変更例、及び変形等をすべて包含することを目的とする。したがって、本発明の正確な範囲は添付した請求項及び法的同等物によって定義される。
【図面の簡単な説明】
【００９５】
【図１】ＤＲＭ技術を用いた文書配布システムのブロック図である。
【図２】好ましい実施の形態によるＤＲＭシステムの概略図である。
【図３】サーバを保護されたクライアントにのみ応答させるための好ましい実施の形態による操作の方法を示すフローチャートである。
【図４】保護されたクライアントにアクセスするための好ましい実施の形態による操作の方法を示すフローチャートである。
【図５】セキュリティ・モジュールをインストールするための好ましい実施の形態による操作の方法を示すフローチャートである。
【図６】セキュリティ・モジュールを非活動状態にするための好ましい実施の形態による操作の方法を示すフローチャートである。
【図７】多数のサーバに対するクライアントの認証を容易にするための好ましい実施の形態による操作の方法を示すフローチャートである。
【図８】クライアントのユーザインタフェースを制御するサービスを可能にするための好ましい実施の形態による操作の方法を示すフローチャートである。
【図９】ユーザインタフェース構成要素に対し参照を有するコンテンツのブロック図である。
【図１０】クライアント特有のウォーターマークを付加するための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１１】トランザクション情報を統合（アグリゲート）するための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１２】アドレス不明化のための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１３】ＨＴＴＰ文書転送のための非同期式プロトコルを使用するための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１４】ソフトウェアの動的認証のための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１５】動的変数暗号化のための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１６】セキュリティ情報を文書に組み込むための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１７】要求中のＵＲＬに基づいて使用権を決定するための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１８】必要なレンダリングアプリケーションをダウンロードするための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１９】タイムスタンプ検証トークンのための好ましい実施の形態による操作の方法を示すフローチャートである。
【図１】
0004512119.tif 000002
【図２】
0004512119.tif 000003
【図３】
0004512119.tif 000004
【図４】
0004512119.tif 000005
【図５】
0004512119.tif 000006
【図６】
0004512119.tif 000007
【図７】
0004512119.tif 000008
【図８】
0004512119.tif 000009
【図９】
0004512119.tif 000010
【図１０】
0004512119.tif 000011
【図１１】
0004512119.tif 000012
【図１２】
0004512119.tif 000013
【図１３】
0004512119.tif 000014
【図１４】
0004512119.tif 000015
【図１５】
0004512119.tif 000016
【図１６】
0004512119.tif 000017
【図１７】
0004512119.tif 000018
【図１８】
0004512119.tif 000019
【図１９】
0004512119.tif 000020