(57)【要約】コンテンツ・プロバイダ（３０１−３０４）によって作成されたデジタルコンテンツを、共有ネットワークを介して、リクエスタ（２００）へ配信するシステムは、コンテンツ・プロバイダの代わりの役割を果たす中央機関（２０１−２０４）と、中央機関に登録されたレスポンダ（３００）と、を含む。レスポンダ（３００）がそのレスポンダのコンピュータに蓄積されたファイルに対応したコンテンツの要求（１）を受信したとき、コンテンツ購入情報データ（４）がリクエスタへ送信される。リクエスタは、中央機関でコンテンツを購入し、購入のプルーフ（１１）を受信する。この購入のプルーフがレスポンダへ送信されると、それに応じて、リクエスタは、要求されたコンテンツに対応したファイルを受信する。レスポンダは、コンテンツの配信に関与した報酬を中央機関から受け取る。
2004517411.tif 000002
【特許請求の範囲】
【請求項１】
共有ネットワーク（１１０）を介してデジタルコンテンツをリクエスタ（２００）へ配信するシステムであって、
中央機関（２０１−２０４）と、
該中央機関に登録され、該リクエスタから受信した購入のプルーフ（１１）と引き換えに、該コンテンツに対応したデータファイルを該リクエスタ（２００）へ配信する手段を備えているレスポンダ（３００）と、
を有し、
該中央機関は、
該レスポンダによって提示されたコンテンツに対する該リクエスタの代金支払のため該リクエスタと金融取引（９）を行い、購入のプルーフ（１０）を該リクエスタへ配信する手段と、
リクエスタによるコンテンツの購入と引き換えに該レスポンダに報酬を供与するレスポンダ補償手段と、
を含む、
ことを特徴とするシステム。
【請求項２】
請求項１記載のシステムを用いて共有ネットワーク（１１０）を介してデジタルコンテンツを配信する方法であって、
レスポンダ（３００）側で、
該共有ネットワークを介してリクエスタ（２００）から受信したデジタルコンテンツの要求（１）に応答して、中央機関（２０１−２０４）によって作成されたレスポンダ識別情報及び該中央機関を識別するデータを含むコンテンツ購入情報データ（４）を該リクエスタへ送信する手順（ａ）と、
該リクエスタ（２００）から、該中央機関によって渡された該デジタルコンテンツの購入のプルーフ（１１）を受信する手順（ｂ）と、
該リクエスタに該デジタルコンテンツに対応したデータファイルを供給する手順（ｃ）と、
該中央機関から該デジタルコンテンツの配信に対する報酬を受け取る手順（ｄ）と、
を有することを特徴とする方法。
【請求項３】
手順（ａ）の前に、該中央機関からレスポンダ識別情報を受信する手順を含む登録手順を更に有する、請求項２記載の方法。
【請求項４】
該登録手順は、
第１の中央機関マスター鍵（ＭＫＰＲ）及び該レスポンダ識別情報から導出された第１の対称暗号鍵（ＤＫＰＲ）を該中央機関から受信する手順を更に含む、
請求項３記載の方法。
【請求項５】
該登録手順は、
第２の中央機関マスター鍵（ＭＫＥＣ）及び該レスポンダ識別情報から導出された第２の対称暗号鍵（ＤＫＥＣ）を該中央機関から受信する手順を更に含む、
請求項４記載の方法。
【請求項６】
請求項１記載のシステムを用いて共有ネットワーク（１１０）を介してデジタルコンテンツを配信する方法であって、
リクエスタ（２００）側で、
該共有ネットワークを介して、デジタルコンテンツを要求する第１のメッセージ（１）を送信する手順（ｉ）と、
該コンテンツに対応したデータファイルを保持するレスポンダから、中央機関を識別するデータを含むコンテンツ購入情報データを受信する手順（ｊ）と、
該中央機関との金融取引（９）に応じて、該デジタルコンテンツの購入のプルーフ（１０）を受信する手順（ｋ）と、
該購入のプルーフを該レスポンダ（３００）へ送信する手順（ｌ）と、
該デジタルコンテンツに対応したデータファイルを受信する手順（ｍ）と、
を有することを特徴とする方法。
【請求項７】
該コンテンツ購入情報データは、該レスポンダが該中央機関から受信したコンテンツ価格データ（３）を含み、
該コンテンツ価格データは中央機関によってレスポンダ毎に定められている、請求項２又は６記載の方法。
【請求項８】
該コンテンツ購入情報データは、価格有効期限データを更に含む、請求項７記載の方法。
【請求項９】
該コンテンツ購入情報データは、該レスポンダが該中央機関から受信したコンテンツ価格データ（３）を含み、
該コンテンツ価格データは中央機関によってレスポンダ毎に定められ、
該コンテンツ価格データは、該第１の対称暗号鍵（ＤＫＰＲ）を使用して暗号化されたメッセージ（３）で送信される、
請求項４記載の方法。
【請求項１０】
該購入のプルーフは、対称セッション鍵（ＳＳＫ）を使用して暗号化されたメッセージ（１１）で送信され、
該対称セッション鍵（ＳＳＫ）は、中央機関によって、乱数値及び該第２の対称暗号鍵（ＤＫＥＣ）から導出され、
該乱数値は、暗号化された該購入のプルーフを含むメッセージ（１１）中の平文で送信される、
請求項５記載の方法。
【発明の詳細な説明】
【０００１】
［発明の分野］
本発明は、共有ネットワークを介してデジタルコンテンツを配信するシステム及び方法に関する。
【０００２】
［背景技術］
インターネットの利用の増加に伴って、ユーザがデジタルコンテンツの共有を申し込む分散共有ネットワークが次第に普及し始める。このようなシステムの例は、（Ｎａｐｓｔｅｒ社から提供される）ＮＡＰＳＴＥＲブラウザ及び通信システムか、又は、（Ｗａｇｏ．ｃｏｍ社から提供される）ＧＮＵＴＥＬＬＡ分散情報共有システムである。ＮＡＰＳＴＥＲのシステムでは、ユーザは、ＭＰ３ファイル（ＭＰ３圧縮フォーマットを使用して圧縮されたオーディオファイル）を交換することができる（ＭＰ３は、ムービング・ピクチャー・グループ・フェーズ１、オーディオ・レイヤ３を表す。）。
【０００３】
これらのシステムで直面する一つの問題は、コンテンツが通常はあるユーザから別のユーザへ無料で配信されることである。これらのシステムを支える配信プロトコルは、著作権のあるコンテンツの正当な管理を考慮に入れず、ユーザの善意だけを頼りにしている。その結果として、著作権侵害のレベルが高くなり、著作権を保有するコンテンツ・プロバイダは、これらの共有ネットワークの外に取り残され、自分が作成したコンテンツの配信に対する収益を受け取れないため、重大な損失を被る。
【０００４】
米国特許出願明細書ＵＳ−Ａ−６  ０２９  １４１号には、インターネットベースのソフトウェアシステム及び方法が開示され、このシステム及び方法によれば、「会員」と呼ばれるエンティティは、取引先のインターネット・サイトから販売される製品（例えば、書籍）を、手数料と引き換えに売りに出すことができる。しかし、このシステム及び方法は、セキュリティ対策を持たず、ハッカーからの攻撃（例えば、「本当の」会員の代わりに手数料を受け取る）を受けやすい。
【０００５】
したがって、本発明の目的は、著作権のあるコンテンツが無償配布されることが防止された分散共有システムを提供することである。本発明のもう一つの目的は、共有ネットワークを通じてコンテンツの安全な商品流通を可能にさせる安全な（セキュア）プロトコルを提案することである。
【０００６】
［発明の概要］
本発明は、共有ネットワークを介して、デジタルコンテンツをリクエスタへ配信するシステムに関する。このシステムは、中央機関と、中央機関に登録されたレスポンダと、を含み、レスポンダは、上記リクエスタから受信した購入のプルーフと引き換えに、上記コンテンツに対応したデータファイルをリクエスタへ配信する手段を有する。中央機関は、上記レスポンダによって提出されたコンテンツに対する上記リクエスタによる支払いのため上記リクエスタと金融取引を行い、購入のプルーフを上記リクエスタへ渡す手段と、リクエスタによるコンテンツの購入と引き換えに上記レスポンダに報酬を支払うレスポンダ補償手段と、を有する。
【０００７】
本発明は、更に、上記のシステムを用いて共有ネットワークを介してデジタルコンテンツを配信する方法に関する。この方法は、レスポンダ側で、
上記共有ネットワークを介してリクエスタから受信したデジタルコンテンツの要求に応答して、中央機関によって作成されたレスポンダ識別情報及び上記中央機関を識別するデータを含むコンテンツ購入情報データを上記リクエスタへ送信する手順（ａ）と、
上記リクエスタから、上記中央機関によって渡された上記デジタルコンテンツの購入のプルーフを受信する手順（ｂ）と、
上記リクエスタに上記デジタルコンテンツに対応したデータファイルを供給する手順（ｃ）と、
上記中央機関から上記デジタルコンテンツの配信に対する報酬を受け取る手順（ｄ）と、
を有する。
【０００８】
本発明は、更に、更に、上記のシステムを用いて共有ネットワークを介してデジタルコンテンツを配信する方法であって、リクエスタ側で、
上記共有ネットワークを介して、デジタルコンテンツを要求する第１のメッセージを送信する手順（ｉ）と、
上記コンテンツに対応したデータファイルを保持するレスポンダから、中央機関を識別するデータを含むコンテンツ購入情報データを受信する手順（ｊ）と、
上記中央機関との金融取引に応じて、上記デジタルコンテンツの購入のプルーフを受信する手順（ｋ）と、
上記購入のプルーフを上記レスポンダへ送信する手順（ｌ）と、
上記デジタルコンテンツに対応したデータファイルを受信する手順（ｍ）と、
を有する方法に関する。
【０００９】
本発明の様々な工夫及び効果と、本発明の好ましい形態は、添付図面を参照して説明される。添付図面は、本発明の範囲を例示することを目的とするものであって、本発明の範囲を限定するものではない。
【００１０】
［好ましい形態の説明］
本発明は、基礎となる情報共有システムには依存しないが、これらのシステムで使用される一部の仕組みは、本発明の詳細な説明を提示する前に理解されている必要がある。
【００１１】
図１は、情報共有システム１００の抽象モデルの説明図であり、ホスト１０１−１０６は、共有ネットワーク１１０を介して相互に連結されている。ホストは、コンピュータと、共有ネットワークを導入するために必要なメッセージを作成し処理するためにこのコンピュータ上で動かされる特定のソフトウェアの両方を表す。これらのホストにログオンしているユーザは、他のユーザと共有するため、デジタルコンテンツを格納するファイルを提出することができる。これらのファイルには、音楽ファイル、映像ファイル、画像ファイル、コンピュータプログラムファイルなどが含まれる。
【００１２】
例えば、ユーザがホスト１０１にログオンし、共有ネットワーク１１０上の特定のデジタルコンテンツの要求情報１２０を送信したとき、共有ネットワークに接続し、かつ、この要求に対応したファイルを保有するすべてのユーザは、応答情報１３０を送信することによって応答することが可能である。このような応答したユーザはレスポンダであり、一方、要求を送信したユーザはリクエスタである。
【００１３】
応答の受信後、リクエスタは、関心があるファイルを選択し、自分がログオンしているホストと、レスポンダがログオンしているホストとの間にピア・ツー・ピア方式の接続を設定することにより、これらのファイルをダウンロードすることができる。
【００１４】
共有ネットワークに接続している各ユーザは、リクエスタにもレスポンダにもなり得る。
【００１５】
図２ａから２ｃには、図１の情報共有システムに対応した共有ネットワーク・アーキテクチャの例が示されている。このネットワークでは、ホスト１  １０１は、ホスト２  １０２とホスト６  １０６とに接続され、ホスト２  １０２は、ホスト３  １０３と、ホスト４  １０４と、ホスト５  １０５とに接続されている。システムに加入している各ホストは、クライアント（要求を送信し、応答を待ち受けるプログラム）としての役割と、サーバ（要求に応答するプログラム）としての役割の両方の役割を果たす。
【００１６】
ネットワーク内の各ホスト１０１−１０６は、ネットワーク内の近隣ホストにメッセージを送信することができる。次に、メッセージを受信した各ホストは、このメッセージを近隣ホストへ転送し、その結果として、このメッセージは、メッセージの期限が切れるか、又は、ネットワークのすべてのホストがこのメッセージを受信するまで、ネットワーク内を伝搬する。
【００１７】
図２ａは、このようなルーティングシステムの説明図である。本例の場合、メッセージＭは、最初に、ホスト１  １０１によって、ピア・ホスト２  １０２とピア・ホスト６  １０６に送信される。次に、ホスト２  １０２は、このメッセージＭをピア・ホスト１０３、１０４及び１０５へ転送する。この時点で、ネットワークのすべてのホストは、メッセージＭを受信している。
【００１８】
図２ｂ及び２ｃは、要求／応答の仕組みの説明図である。図２ｂにおいて、ホスト１  １０１は、要求ＲＱをピア・ホスト１０２及び１０６へ送信する。要求ＲＱは、ネットワークのすべてのホストがその要求を受信するまで（或いは、要求の期限が切れるまで）転送される。本例では、ホスト４  １０４及びホスト６  １０６がこの要求ＲＱに対する応答ＲＳを与えることができる場合を考える。図２ｃでは、これらのホスト１０４及び１０６は、要求ＲＱとは逆向きにホスト１０１へ回送される応答ＲＳを送信する。この要求ＲＳがホスト１０１にログオンしているユーザによる特定のデジタルコンテンツの要求と一致している場合、ユーザは、応答ＲＳを送信したホスト１０４とホスト１０６の中から、デジタルコンテンツを格納しているファイルをダウンロードするホストを選択することができる。
【００１９】
次に、本発明の商業用分散共有システムと、このシステムにおいてデジタルコンテンツを配信する安全なプロトコルを詳述する。
【００２０】
このシステムは、従来の共有システムのアクタ（利用者）であるリクエスタとレスポンダを含む。リクエスタは、共有ネットワークにデジタルコンテンツを格納したファイルを要求するユーザを表し、レスポンダは、共有するためのファイルを提出し、リクエスタによって要求されたファイルを自分のコンピュータでローカル（局所的）に保持するユーザを表す。
【００２１】
勿論、上述のように、一人のユーザが、リクエスタとしての役割とリクエスタとしての役割を果たしてもよい。
【００２２】
従来技術による公知の共有システムに対して、本発明のシステムでは、リクエスタは、自分が受け取りたいコンテンツの代金を支払い、レスポンダは、リクエスタにコンテンツを提出し、リクエスタが後でそのコンテンツを購入したときに料金を受け取る。
【００２３】
そのため、本発明の共有システムには新しいタイプのアクタである中央機関が追加される。このエンティティは、コンテンツ・プロバイダに代わってコンテンツを販売する役割を担う第三者である。より詳細に説明すると、中央機関は、ネットワーク上で販売されるコンテンツに対する代金をリクエスタから集金する役割を担う。また、中央機関は、コンテンツを配信したレスポンダと、コンテンツを作成したコンテンツ・プロバイダの両方に金銭を分配する役割も担っている。
【００２４】
各中央機関は、音楽メジャー、書籍エディタ，ソフトウェア・エディタなどのような一つのコンテンツ・プロバイダ、若しくは、好ましくは、数件のコンテンツ・プロバイダのために働き、これらの特定のコンテンツ・プロバイダによって製造されたコンテンツを販売する役目を果たす。また、一つのコンテンツ・プロバイダは、その作成したコンテンツを共有ネットワーク上で販売するため、幾つかの中央機関と連携することができる。
【００２５】
購買活動は、中央機関と、共有ネットワーク上のレスポンダによって提出されたコンテンツの中で興味のあるコンテンツを見つけたリクエスタとの間で行われる。レスポンダは、コンテンツの配信に関与したことに対する報酬を後で受け取る。
【００２６】
しかし、共有ネットワーク上でコンテンツを配信し、コンテンツ・プロバイダのために働く中央機関から金銭を受け取ることができるようになる前に、すべての潜在的なレスポンダは、この中央機関に登録する必要がある。レスポンダが、同一の中央機関を使用していない数ヶ所のコンテンツ・プロバイダによって作成されたコンテンツ（著作権のあるファイル）を配信したい場合には、レスポンダは、共有するためのコンテンツを提出できるようになる前に、関係するすべての中央機関へ登録しなければならない。
【００２７】
登録処理は、幾つかの方式で、例えば、電子メールを用いて、若しくは、中央機関のウェブサイト上の登録ゾーンを用いて、実行される。登録処理の最後に、固有のレスポンダ識別情報が中央機関によってレスポンダに割り当てられ、このレスポンダ識別情報はレスポンダへ送信され、中央機関のデータベースに保存される。
【００２８】
レスポンダが中央機関に登録されると、レスポンダは、その中央機関が委託を受けているコンテンツ・プロバイダによって作成されたコンテンツを共有ネットワークに提出することが許可される。
【００２９】
図３は、共有ネットワークでコンテンツを配信する本発明の安全なプロトコルに関係するアクタと、このプロトコル中に交換されるメッセージの説明図である。
【００３０】
図３には、書籍エディタ３０１と、二つの音楽メジャー、即ち、第１音楽メジャー３０２及び第２音楽メジャー３０３と、ソフトウェア・エディタ３０４の４種類のコンテンツ・プロバイダが示されている。
【００３１】
また、図３には、４種類の中央機関が示されている。第１中央機関２０１は、書籍エディタ３０１の委託を受けて仕事をする。第２中央機関２０２は、第１音楽メジャー３０２の委託を受けて仕事をし、第３中央機関２０３は、第１音楽メジャー３０２と第２音楽メジャー３０３の両方の委託を受けて仕事をし、第４中央機関２０４は、ソフトウェア・エディタ３０３の委託を受けて仕事をする。コンテンツ・プロバイダと中央機関との間のリンクは、図３に実線で示されている。
【００３２】
コンテンツ・プロバイダの数、及び、中央機関の数は、関連がなく、各コンテンツ・プロバイダは、数個の中央機関と連携してもよい。同様に、各中央機関は、複数のコンテンツ・プロバイダから委託を受けてもよい。
【００３３】
実際上、以下の説明で使用される用語「中央機関」は、エンティティ自体（例えば、商人）と、後述のプロトコルを実施するため特定のソフトウェアが動かされているそのエンティティのコンピュータ若しくはサーバの両方を示す。
【００３４】
リクエスタ２００及びレスポンダ３００も図３に示されている。特定のコンテンツを探すために第１のメッセージを送信する前に、リクエスタ２００及びレスポンダ３００の両方が共有ネットワーク１１０に接続されていることを前提とする。接続の仕組みは、本発明の範囲には含まれず、基礎となる共有プロトコルを使用する。
【００３５】
以下で使用される用語「リクエスタ」及び「レスポンダ」は、共に、一方で、コンピュータと、共有ネットワークのホストを構成するそのコンピュータ上で動かされるソフトウェアを表し、他方で、共有ネットワーク上でデジタルコンテンツを探すためこのコンピュータを使用する自然人（リクエスタ）、若しくは、共有のためのデジタルコンテンツを格納した自分のファイルを提出するためこのコンピュータを使用する自然人（レスポンダ）を表す。勿論、既に説明した通り、同一の自然人とホストは、あるときにはリクエスタになり、あるときにはレスポンダになる。
【００３６】
図３には、共有ネットワーク１１０上でのデジタルコンテンツの検索及び購買中に上述のアクタによって交換されるメッセージがより詳細に示されている。
【００３７】
以下のデジタルコンテンツ配信プロトコルの説明中、リクエスタによって要求されたすべてのファイル（保護されたデジタルコンテンツを格納したファイル）は、レスポンダが登録されている第３中央機関２０３によって作成された場合を考える。勿論、レスポンダは、複数の中央機関によって作成されたファイルを配信してもよい。その場合には、レスポンダは、すべての中央機関に登録される必要があり、要求されたファイルに応じた正当な中央機関を取り出さなければならない。
【００３８】
次に、保護されたデジタルコンテンツを格納するファイルをレスポンダのコンピュータに作成するための考えられる実施形態を説明する。
【００３９】
音楽コンテンツの例に取り上げて説明するならば、レスポンダが第２音楽メジャー３０３によって製作された、数個の楽曲を含む、ＣＤ（コンパクトディスク）を購入している場合を想定する。このレスポンダがこれらの楽曲を潜在的なリクエスタと共有したい場合（そして、共有の報酬を受け取りたい場合）、レスポンダは、最初に、そのＣＤを自分のコンピュータのＣＤ若しくはＤＶＤ（デジタル多目的ディスク）プレーヤに挿入する。レスポンダは、自分のコンピュータで動かされる共有ネットワーク・ソフトウェアのユーザ・インタフェースを介して、共有用に提出したい楽曲を選択する。次に、第２音楽メジャー３０３を代行する中央機関（本例では、第３中央機関２０３）は、例えば、レスポンダが（ＣＤに添付された小冊子に表示されているような）第３中央機関２０３のウェブサイトのＵＲＬ（インターネット上でのファイル若しくはその他のリソースの場所を完全に指定する固有アドレスを規定するユニフォーム・リソース・ロケータ）を自分のコンピュータのウェブブラウザ画面で入力したとき、レスポンダからの連絡を受ける。
【００４０】
レスポンダが第３中央機関２０３に既に登録済みである場合、レスポンダは、共有ネットワークで配信したい楽曲を指定し、第３中央機関２０３から（例えば、圧縮フォーマットの楽曲を格納している）対応したファイルを受信する。
【００４１】
レスポンダが第３中央機関２０３に未登録である場合、レスポンダは、自分が共有用に提出したい楽曲に対応したファイルを受信する前に、上述のように、最初にこの中央機関に登録しなければならない。
【００４２】
次に、レスポンダのコンピュータで動かされる共有ネットワーク・ソフトウェアは、第３中央機関２０３から受信したファイルを、コンピュータの記憶媒体の特定の場所に蓄積する。
【００４３】
図３では、リクエスタ２００が共有ネットワーク１１０に問い合わせ（ステップ１で送信されたメッセージ「問い合わせ」）を送信したとき、ネットワークに接続されたあるユーザがリクエスタの要求を満たすファイルを保持するならば、リクエスタは応答を受信する。
【００４４】
図３では、レスポンダ３００は、リクエスタ２００によってステップ１において送信された問い合わせを満たすファイル（若しくは、複数のファイル）を局所的に保持している場合を想定する。ファイル（即ち、デジタルコンテンツ）が無料で入手可能である場合、従来技術の典型的なプロトコルが使用される。無料ででは入手不可能であり、ファイル（即ち、デジタルコンテンツ）が著作権保護されている場合、レスポンダは、そのファイルの価格に関する情報を局所的に保持している。この価格情報は、要求されたコンテンツを作成したコンテンツ・プロバイダ（本例では、第２音楽メジャー３０３）の代行を務める中央機関（本例では、第３中央機関２０３）によって予め配信された情報である。
【００４５】
しかし、この価格情報には有効期限があり、中央機関は、時間の経過と共にファイルの価格を変更することができる。レスポンダによって保持されている価格情報（又は、より詳細には、レスポンダのコンピュータの記憶媒体に記憶されている価格情報）の有効期限が切れている場合、レスポンダは、価格情報要求メッセージ２を送信することにより、リクエスタ２００によって要求された特定のファイルの新しい価格情報を第３中央機関２０３に要求する。
【００４６】
任意的である（レスポンダによって保存されたファイルの価格情報の有効期限が切れていない場合は送信されない）この価格情報要求メッセージ２は、図３では、本発明のプロトコルにおいて送信可能なすべての任意的なメッセージと同じように破線の矢印で示されている。
【００４７】
中央機関２０３が価格情報要求メッセージ２を受信したとき、中央機関２０３は、要求されたファイルに対する新しい価格情報を含む価格情報応答メッセージ３によって応答する。このメッセージには有効期限がある。尚、好ましくは、中央機関によって返信された価格情報はレスポンダの身元に依存する。実際上、一部のレスポンダは、著作権保護されたファイルの配信に積極的に参加し、ファイルをより低価格で販売することを中央機関との間で合意すること、及び／又は、価格差益により重大な関心を持つことがある。
【００４８】
レスポンダが問い合わせメッセージ１で要求されたデジタルコンテンツを格納したファイルの有効期限が切れていない価格情報を保持するとき、レスポンダは、リクエスタが好きなものを選んでファイルを購入する必要がある旨の情報を含む問い合わせヒットメッセージ４を送信する。この情報には、ファイル名、ファイルサイズ、ファイルの品質（例えば、音楽ファイルの場合の記録モード、ソフトウェアファイルの場合のバージョンなど）、価格、ファイルを購入できる中央機関の名前（又はＵＲＬ）、中央機関が受け付ける支払プロトコル、（中央機関によって作成され、上述の登録処理の最後にレスポンダへ付与された）レスポンダ識別情報が含まれる。
【００４９】
好ましい実施形態では、共有ネットワーク・ソフトウェアは、レスポンダが共有ネットワーク１１０に接続されているとき、レスポンダのコンピュータ上で常に動かされ、問い合わせヒットメッセージ４及び／又は価格情報要求メッセージ２は、（自然人としての）レスポンダの介入を要することなく、このソフトウェアによって自動的に作成される、
リクエスタは、共有ネットワークに接続された別々のレスポンダから数個の問い合わせヒットメッセージを受信することがある。問い合わせに対するこれらの応答の受信後に、リクエスタは、好きなものを選ぶことができる。例えば、リクエスタは、最良価格を選択し、価格と品質の間で折り合いをつけ、或いは、自分が特恵的契約をしている好ましい中央機関を選定することができる。
【００５０】
問い合わせメッセージ１及び問い合わせヒットメッセージ４は、（基礎となる共有システムに依存したルーティングの仕組みを用いて）共有ネットワーク１００を介してリクエスタ２００とレスポンダ３００の間で回送されるが、リクエスタが一つのレスポンダを選択した後には、リクエスタは、そのレスポンダとのポイント・ツー・ポイント通信に切り替わる。ポイント・ツー・ポイント通信（ピア・ツー・ピア通信としても知られている）は、図２ａ乃至２ｃを参照して説明した仕組みとは異なり、共有ネットワークの２台の識別されたホスト間でメッセージを交換する。
【００５１】
リクエスタとレスポンダの間で交換される後述の他のすべてのメッセージは、ポイント・ツー・ポイント方式メッセージである。
【００５２】
更に、リクエスタは、プレビュー要求メッセージ５をレスポンダへ送信することにより、ファイルのプレビューを任意的に要求する。この機能は、特に、著作権保護されたファイルの場合には興味深い。プレビューファイルは、例えば、音楽ファイルの場合には、短時間の音楽であり、ソフトウェアの場合には、デモンストレーション版であり、映像ファイルの場合には、ショートクリップである。
【００５３】
リクエスタ２００がプレビューを要求した場合、レスポンダ３００は、プレビューメッセージ６を用いて応答し、要求されたファイルのプレビューをリクエスタに送信する。
【００５４】
リクエスタ２００が著作権保護されたコンテンツを含む多数のファイルの購入を決定した場合（例えば、問い合わせが、一人の歌手のすべての楽曲を検索することであるならば、複数個のファイルがこの問い合わせに対応する）、リクエスタは、情報要求メッセージ７をレスポンダ３００へ送信することにより、任意的に優先価格を要求することが可能である。このメッセージの受信後、レスポンダ３００は、価格情報要求メッセージ２を中央機関２０３へ送信することにより、リクエスタ２００のための優先価格を要求し、中央機関２０３から価格情報応答メッセージ３を受信する。
【００５５】
次に、レスポンダは、情報応答メッセージ８で優先価格をリクエスタへ送信する。優先価格が中央機関によって認められなかった場合、このメッセージは空である。
【００５６】
好ましい一実施例において、価格情報要求メッセージ２及び情報応答メッセージ８は、リクエスタ側で動かされるソフトウェアによって自動的に作成される。
【００５７】
リクエスタ２００がレスポンダ３００から獲得した条件に満足した場合、リクエスタ２００は、問い合わせヒットメッセージ４と、任意的に情報応答メッセージ８に含まれる情報を使用して、要求したファイルの購入を行うことができる。好ましくは、この購入動作は、既存の支払基盤設備を手に入れるため、ワールド・ワイド・ウェブを使用する。リクエスタ２００は、（問い合わせヒットメッセージ４に格納された中央機関のＵＲＬを使用して）中央機関２０３に連絡を取り、中央機関と安全な金融取引９を実行する。この取引の期間中、リクエスタは、問い合わせヒットメッセージ４に収容されたあるデータ（例えば、レスポンダ識別情報のようなデータ）を送信する。この取引９の結果は、著作権保護されたファイルに対する中央機関２０３への支払である。
【００５８】
中央機関は、コンテンツ・プロバイダに対する支払と、ファイルの配信に参加したレスポンダ３００に対する支払を後で行うことができる。レスポンダへの支払は、登録処理中に中央機関によって開かれたレスポンダの口座へ入金することによって行われる。
【００５９】
金融取引９の最後に、中央機関２０３は、（支払チケットメッセージ１０で送信された）支払チケットをリクエスタ２００へ配信する。この支払チケットは、リクエスタがファイルの代金を支払ったことを証明する。この支払チケットは、購入されたファイルを配信したレスポンダ３００へ、支払チケット転送メッセージ１１として転送される。レスポンダ３００は、このメッセージ１１を受信すると、支払チケットの有効性を検証し、検証が成功した場合、レスポンダは、要求されたファイルをダウンロードするために必要なすべての情報を、ダウンロード情報メッセージ１２として、リクエスタへ送信することによって応答する。次に、リクエスタ２００は、購入ファイルのダウンロード動作１３を開始する。
【００６０】
上記のプロトコルで交換されたメッセージに含まれる一部のデータの機密性を考えると、これらのメッセージの伝送中にこれらのメッセージを起こり得る攻撃から保護することが必要である。
【００６１】
次に、本発明に従ってデジタルコンテンツを配信するシステムのセキュリティ必要性と、本発明の好ましい実施例においてセキュリティ必要性がどのようにして実現されるかを詳細に説明する。
【００６２】
説明中、以下の表記及び頭文字を使用する。
”，”は、連結演算子を表す。
”｛Ｍ｝＋”は、ｎがｎ＞０であるとき、メッセージＭのｎ回の繰り返しを表す。
”ＰＢＳＫ”は、署名検証公開鍵を表す。
”ＰＲＳＫ”は、署名秘密鍵を表す。
”ＳＫ”は、対称鍵を表す。
”ＭＫ”は、マスター対称鍵を表す。
”ＤＫ”は、導出された対称鍵を表す。
”ＳＳＫ”は、対称セッション鍵を表す。
”ＥＳＫ（Ｍ）”は、対称鍵ＳＫを使用したメッセージＭの対称暗号化を表す。
”ＳＰＲＳＫＡ（Ｍ）”は、Ａの署名秘密鍵ＰＲＳＫを使用したメッセージＭの署名を表す。
”Ｈ（Ｍ）”は、ハッシュ関数Ｈを使用したメッセージＭのハッシュ値を表す。
【００６３】
本発明のシステム及び方法を実施するため、好ましくは、以下の暗号アルゴリズムが使用される。
【００６４】
”ＡＥＳ”（次世代暗号標準）は対称暗号化に使用される。ＡＥＳ標準の詳細は、インターネット刊行物、ＮＩＳＴ， ”Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｅｆｆｏｒｔ”， ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｅｎｃｒｙｐｔｉｏｎ／ａｅｓ”と、ＤＡＥＭＥＮ Ｊ．とＲＩＪＭＥＮ Ｖ．の”Ｔｈｅ Ｒｉｊｎｄａｅｌ Ｂｌｏｃｋ Ｃｉｐｈｅｒ”， ＡＥＳ Ｐｒｏｐｏｓａｌ， ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｅｎｃｒｙｐｔｉｏｎ／ａｅｓ／ｒｉｊｎｄａｅｌ／Ｒｉｊｎｄａｅｌ．ｐｄｆに記載されている。
【００６５】
”ＲＳＡ”（リベスト（Ｒｉｖｅｓｔ）、シャミア（Ｓｈａｍｉｒ）、エーデルマン（Ａｄｌｅｍａｎ）は、このアルゴリズムの発案者）は、ハッシュ関数として”ＳＨＡ−１”を用いて、署名アルゴリズムとして使用される。このアルゴリズムは、インターネット刊行物：ＲＳＡ ＬＡＢＯＲＡＴＯＲＩＥＳ， ”ＰＫＣＳ ＃１ ｖ２．１： ＲＳＡ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄ”， Ｓｅｐｔｅｍｂｅｒ １９９９ （ｄｒａｆｔ ｓｔａｔｕｓ）， ｈｔｔｐ：／／ｗｗｗ．ｒｓａｌａｂｓ．ｃｏｍ／ｐｋｃｓ／ｐｋｃｓ−１に記載されている標準ＰＫＣＳ  ＃１  ｖ２．１に準拠して使用される。
【００６６】
”ＳＨＡ−１”はハッシュ関数Ｈとして使用される。ＳＨＡ−１関数に関する情報は、”Ｓｅｃｕｒｅ Ｈａｓｈ Ｓｔａｎｄａｒｄｓ”， ＮＩＳＴ， ＳＩＰＳ ＰＵＢ １８０−１， Ａｖｒｉｌ １９９５に記載されている。
【００６７】
本発明の好ましい実施例において、暗号鍵のサイズは、署名鍵の場合には１０２４ビットであり、対称鍵の場合には１２８ビットである。
【００６８】
最初に、システムは、リクエスタに対して、（ａ）匿名性と（ｂ）支払のセキュリティと（ｃ）購入のプルーフを保証しなければならない。
【００６９】
（ａ）匿名性とは、レスポンダはリクエスタの身元情報を知ることができない、ということである。レスポンダは、別々の買い入れをリンクすることができない。即ち、レスポンダは、二つの別個の買い入れが同一のリクエスタからの買い入れであるか否かを知ることできない。
【００７０】
この匿名性を保証するため、好ましい実施形態では、リクエスタの身元情報は、そのＩＰアドレスの背後に隠される（ＩＰは、インターネット・プロトコルである。）。殆どの場合に、このアドレスは、インターネット接続ごとに動的に割り当てられるので、レスポンダは二つの異なる要求を結びつけることができない。
【００７１】
（ｂ）支払のセキュリティとは、レスポンダが自分への支払が確実であることを確信することである。
【００７２】
支払のセキュリティは、例えば、ＳＥＴ（セキュア電子取引）、ＳＳＬ（セキュア・ソケット・レイヤ）、又は、小額決済プロトコルのような金融取引９で使用される支払プロトコル自体によって保証される。ＳＥＴに関する情報は、Ｌｏｖｅ Ｌ．， ”Ｓｅｃｕｒｅ Ｅｌｅｃｔｒｏｎｉｃ Ｔｒａｎｓａｃｔｉｏｎ： Ｉｎｔｒｏｄｕｃｔｉｏｎ ａｎｄ Ｔｅｃｈｎｉｃａｌ Ｒｅｆｅｒｅｎｃｅ”， Ａｒｔｅｃｈ Ｈｏｕｓｅ Ｐｕｂｌｉｓｈｅｒｓ， １９９８に記載されている。ＳＳＬは、インターネットで使用される周知の支払プロトコルである。
【００７３】
（ｃ）購入のプルーフとは、リクエスタが中央機関から取得した購入のプルーフ（即ち、メッセージ１０で受信した支払チケット）が有効であり、かつ、購入のプルーフによって購入したファイルを取得できることを確信することである。本人以外は、購入のプルーフを使用しない。更に、レスポンダは、レスポンダによってチェックすることもできるそのプルーフを検証することが可能である。
【００７４】
好ましい実施例において、購入のプルーフ、即ち、支払チケットは、その有効性を証明するため、リクエスタへ送信される前に、（後述するように署名秘密鍵ＰＲＳＫＣＡを使用して）中央機関によって署名される。署名付きの支払チケットは、好ましくは、購入されたコンテンツに関する情報と、レスポンダの身元に関する情報（即ち、問い合わせヒットメッセージ４でリクエスタによって受信されたレスポンダ識別情報）を含む。
【００７５】
その上、支払チケットメッセージ１０を横取りしたハッカーによって使用されることが無いように、支払チケットメッセージ（実際上、署名付きの支払チケット）は、リクエスタへ送信される前に、更に、中央機関によって暗号化される。支払チケットメッセージは、金融取引９の間に使用された支払プロトコルで既に使用され（或いは、作成され）、リクエスタと中央機関に共有されている鍵ＫＰＡＹを使用して暗号化される。例えば、ＳＥＴプロトコル及びＳＳＬプロトコルは、このような鍵を規定する。
【００７６】
更に、リクエスタとレスポンダの間における支払チケット転送メッセージ１１による支払チケットの伝送を保護するため、対称セッション鍵ＳＳＫが、支払チケット転送メッセージ１１の伝送用にリクエスタとレスポンダの間に暗号化チャネルを作成するために使用される。どのようにしてこの鍵ＳＳＫが中央機関によって作成され、リクエスタとレスポンダの双方によって共有されるかについては、後で詳述する。
【００７７】
システムは、更に、レスポンダに対して、（ａ）プライバシーと、（ｂ）値付けの適正と、（ｃ）支払の確約と、（ｄ）機密性と、（ｅ）購入品に対する制限を保証しなければならない。
【００７８】
（ａ）プライバシーとは、当該レスポンダ以外の者は、中央機関との間でなされた商業上の協定に関する情報（例えば、レスポンダ毎に異なる可能性のある価格、減額など）を取得できない、ということである。
【００７９】
このプライバシーを保証するため、好ましい実施形態では、価格情報応答メッセージ３は、レスポンダへ送信される前に、正当なレスポンダだけがその価格情報応答メッセージを復号化できるようにするため、中央機関によって暗号化される。好ましくは、価格情報応答メッセージは、レスポンダの登録処理中に中央機関によって作成され、（中央機関だけが知っている）マスター鍵ＭＫＰＲ及びレスポンダ識別情報から導出された対称暗号鍵ＤＫＰＲを用いて暗号化される。レスポンダ毎に別々であるこの対称暗号鍵ＤＫＰＲは、登録処理の最後で、レスポンダ識別情報と共に、中央機関によってレスポンダへ送信される。あるレスポンダが別のレスポンダの価格条件を知ろうとしても、暗号化された価格条件を受信し、暗号化された価格条件を復号化し得ない。
【００８０】
（ｂ）値付けの適正とは、レスポンダが、中央機関から価格情報応答メッセージ３として受信した価格情報は有効であり、この機関によって受諾されるであろうと確信しなければならない、ということである。
【００８１】
好ましい実施例では、価格情報は、価格情報応答メッセージ３としてレスポンダへ送信される前に、（署名秘密鍵ＰＲＳＫＣＡ）を使用して中央機関によって署名される。好ましくは、署名付き価格情報は、共有のため提出されたファイルに関するある種の情報、価格、価格の有効期限、レスポンダ識別情報、ファイルの品質に関する情報、中央機関によって承諾される支払モード、及び、中央機関のＵＲＬを含む。
【００８２】
（ｃ）支払の確約とは、当該レスポンダ以外のものは、中央機関からの支払を取得できない、ということである。
【００８３】
支払の確約は、好ましい実施形態では、購入のプルーフ（即ち、支払チケット）をレスポンダへ（支払チケット転送メッセージ１１として）提示することによって保証される。なぜならば、レスポンダ識別情報が中央機関によって作成されたそのプルーフ内に含まれているからである。
【００８４】
（ｄ）機密性とは、ダウンロード情報メッセージ１２としてリクエスタへ送信されたダウンロード情報、及び、ダウンロード動作１３中にダウンロードされるべきコンテンツは、リクエスタへの送信中に、秘密を保持されるべきである、ということである。
【００８５】
この機密性は、好ましい実施例では、レスポンダとリクエスタの間に暗号化チャネルが存在することによって保証される。この暗号化チャネルは、後述するように対称セッション鍵ＳＳＫによって作成される。
【００８６】
（ｅ）購入品に対する制限とは、リクエスタは、自分が購入したコンテンツ以外のものは一切レスポンダから獲得できないことが保証される、ということである。
【００８７】
好ましい実施形態では、レスポンダのコンピュータは、すべてのコンテンツ（即ち、レスポンダが共有ネットワーク上でコンテンツを配信する権利を取得したときに中央機関から受信したすべてのファイル）が暗号化形式（各コンテンツはそれぞれの適切な鍵Ｋｃｏｎｔｅｎｔによって暗号化されている）で入手可能な常駐ディレクトリを保持する。次に、レスポンダは、購入されたコンテンツの復号鍵Ｋｃｏｎｔｅｎｔを、ダウンロード情報メッセージ１２として、（暗号化チャネルを介して）リクエスタへ送信し、コンテンツ自体は、（鍵Ｋｃｏｎｔｅｎｔを使用した）暗号形式で、ダウンロード動作１３において、リクエスタへ送信される。コンテンツの完全な状態は、送信された暗号形式のコンテンツにコンテンツのハッシュ値を組み込むことによって獲得される。
【００８８】
別の解決手法では、レスポンダは、購入されたファイルが収容されるディレクトリを動的に作成する。このディレクトリは、ダウンロード動作１３が行われた後に破棄される。コンテンツは、暗号化チャネルを介してリクエスタへ送信する際に、レスポンダによって暗号化される必要がある。
【００８９】
最後に、このシステムは、中央機関に対して、支払の有効性（即ち、中央機関が受け取った支払が有効である旨）を保証しなければならない。この支払の有効性は、金融取引９で使用される支払プロトコルによって保証される。
【００９０】
本発明のプロトコルにおけるセキュリティを保証する上述の好ましい実施例を実現するため、後述のように、数個の暗号鍵を生成し、システムのアクタが共有する必要がある。
【００９１】
最初に、各中央機関は、価格と支払を認証（証明する）ため使用される署名秘密鍵ＰＲＳＫＣＡを保持する。関連した署名検証公開鍵ＰＢＳＫＣＡは、認証される必要がある。好ましい手法では、重い公開鍵インフラストラクチャーを構築することを回避するため、異なる中央機関の間での相互認証を使用することが提案される。リクエスタは、少なくとも一つの中央機関を信頼することが必要である。
【００９２】
更に、各中央機関は、２個のマスター対称鍵ＭＫＰＲ（価格情報応答メッセージ３による価格情報の伝送を保護するための鍵）とＭＫＥＣ（レスポンダとリクエスタの間に暗号化チャネルを構築するための鍵）を保有する。中央機関は、各レスポンダの登録時に、レスポンダのレスポンダ識別情報に加えて、２個の派生鍵、即ち、
ＤＫＰＲ＝ＥＭＫＰＲ（レスポンダ識別情報）
及び
ＤＫＥＣ＝ＥＭＫＥＣ（レスポンダ識別情報）
をレスポンダへ配信する。
【００９３】
レスポンダ側では、登録時に、２個の生成鍵ＤＫＰＲ及びＤＫＥＣを獲得しなければならない。また、レスポンダは、共有ネットワークを介して配信するコンテンツ毎に対称鍵Ｋｃｏｎｔｅｎｔを作成することが必要である。各コンテンツは、レスポンダの特定のディレクトリに、以下の形式、即ち、
ＥＫｃｏｎｔｅｎｔ（コンテンツ，Ｈ（コンテンツ））
の形式で保持される。
【００９４】
リクエスタ側では、予め専用鍵を用意する必要が無い。しかし、リクエスタは、金融取引９で使用された支払プロトコルで使用されるか、及び／又は、構築された鍵ＫＰＡＹを使用する。この鍵ＫＰＡＹは、中央機関とリクエスタの間で支払チケットメッセージ１０として伝送される支払チケットを暗号化するため使用される。
【００９５】
最後に、１個のセッション鍵ＳＳＫがコンテンツの購入毎に作成される。この鍵ＳＳＫは、リクエスタとレスポンダの間に暗号化チャネルを作成するため使用される。鍵ＳＳＫは、（レスポンダ識別情報がレスポンダへ送信された）金融取引９の後に、中央機関によって作成される。中央機関は、最初に乱数値Ｒを生成する。次に、中央機関は、
ＳＳＫ＝ＥＤＫＥＣ（Ｒ）
を計算する。鍵ＤＫＥＣは、マスター鍵ＭＫＥＣ及びレスポンダ識別情報から、中央機関によって、
ＤＫＥＣ＝ＥＭＫＥＣ（レスポンダ識別情報）
として再構成される。
【００９６】
セッション鍵ＳＳＫは、乱数値Ｒと共に、（鍵ＫＰＡＹを用いて暗号化された）支払チケットメッセージ１０として、リクエスタへ送信される。次に、リクエスタは、乱数値Ｒを、鍵ＤＫＥＣを用いて、
ＳＳＫ＝ＥＤＫＥＣ（Ｒ）
を計算することができるレスポンダへ送信する。最後に、リクエスタとレスポンダの双方は、同じセッション鍵ＳＳＫを共有するので、暗号化チャネルを構築することが可能である。
【００９７】
以下の説明では、図３に示されたプロトコルで交換されるメッセージ１乃至１３の内容をより詳細に記述する。この記述は、実現可能な一つの形態であり、本発明の範囲を制限するものとして理解されるべきではない。
【００９８】
１．問い合わせメッセージ１
このメッセージは、共有ネットワーク１１０内で特定のファイルを検索するためリクエスタによって送信される。この目的のため、リクエスタは、要求されたファイルを説明する検索基準をタイプ入力する。例えば、”ｂｒｉｔｎｅｙｓｐｅａｓ＊．ｍｐ３”検索基準は、リクエスタが、アーティストが”Ｂｒｉｔｎｅｙ Ｓｐｅａｒｓ”であるすべての共有ＭＰ３ファイルを探していることを表す。
【００９９】
詳細なメッセージフォーマットを表１に記載する。
【表１】
2004517411.tif 000003
【０１００】
２．価格情報要求メッセージ２
このメッセージは、共有用にレスポンダによって提出された著作権付きファイルの購入情報（価格、中央機関が許容する支払方式など）を要求するため、レスポンダによって中央機関へ送信される。実際上、レスポンダは、自分の著作権付き共有ファイルのすべてについての購入情報を局所的に保持する。しかし、この情報は、有効期限があるので、定期的に更新する必要がある。
【０１０１】
このメッセージは、手続き中の異なる時点で送信することができる。
【０１０２】
第一に、このメッセージは、レスポンダが共有用の著作権付きファイルを提出する前に、レスポンダによって送信され得る。その場合、レスポンダは、初期購入情報を取得するためこのメッセージを使用する。
【０１０３】
第二に、このメッセージは、レスポンダがリクエスタから情報要求メッセージ７を受信した後に、送信することができる。情報要求メッセージ７は、ある種の状況で（例えば、リクエスタが多数のファイルを購入することに決定したとき）、優先価格を得るためリクエスタによって使用される。
【０１０４】
更に、このメッセージは、レスポンダが局所的な購入情報の有効期限が切れたことを検出したときにいつでも送信することができる。
【０１０５】
この価格情報要求メッセージ２は、レスポンダ身元に関する情報も含む。実際上、レスポンダは、自分の価格差益及び／又はリクエスタに提案される優先価格について、中央機関とアウト・オブ・バンド方式で（個別に）交渉することができる。したがって、このメッセージ中にレスポンダ身元情報が存在するならば、中央機関はレスポンダに応じて適正な価格を提案することができる。
【０１０６】
詳細なメッセージフォーマットは表２に記載されている。
【表２】
2004517411.tif 000004
尚、購入情報要求フィールドは、価格情報要求メッセージ２の中に、（レスポンダが価格情報を要求した対象のファイル毎に１回ずつ）価格要求番号の回数だけ現れる。
【０１０７】
組（ファイルインデックス，ファイルサイズ，ファイル名，品質）は、レスポンダ側と中央機関側とで同一のファイルを一意に指定する。これにより、中央機関は、適正な価格をレスポンダへ与えることができるようになる。この目的のため、ファイルインデックスは、書籍の番号付け用のＩＳＢＮ（国際標準図書番号）と類似した仕組みを使用してもよい。
【０１０８】
３．価格情報応答メッセージ３
このメッセージは、中央機関によってレスポンダへ送信され、価格情報要求メッセージ２においてレスポンダによって要求された購入情報を含む。この購入情報は、問い合わせを送信し、レスポンダから応答を受信したリクエスタがダウンロードするファイルを選定するため必要とするすべての情報を含む。すべての提案された購入情報には有効期限があり、この情報がレスポンダによって受信されると、この情報は、有効期限が到来するまでレスポンダによって保持される必要がある。
【０１０９】
上述の通り、このメッセージは機密にされなければならない。メッセージに格納されたデータは、レスポンダへ送信される前に、対称鍵ＤＫＰＲを用いて暗号化される。
【０１１０】
詳細なメッセージフォーマットは表３に示されている。
【表３】
2004517411.tif 000005
【０１１１】
４．問い合わせヒットメッセージ４
このメッセージは、リクエスタから受信した問い合わせメッセージ１に応じてレスポンダによって送信される。レスポンダがリクエスタの要求に対応したファイルを局所的に保持する場合、レスポンダは、問い合わせヒットメッセージ４を用いて応答する。このメッセージは、リクエスタが選択を行うために必要なすべてのデータを含むべきである。
【０１１２】
この選択は、以下の幾つかの基準に基づいて行うことが可能である。
価格：リクエスタは、著作権付きファイルの価格を知ることが必要である。
価格・品質トレードオフ：リクエスタは、提案されたファイルの品質を知ることが必要である。したがって、品質指標は、商用分散共有システムによって提案されるべきである。
許容支払システム：リクエスタは、要求されたファイルの代金を提案された支払方式で支払うことができるかどうかを知る必要がある。
販売者名（即ち、中央機関名）：リクエスタは一部の販売者と優先的な関係を持つ場合がある。
【０１１３】
これらのすべてのデータは、最初に、対応したファイルの販売の役割を担う中央機関によって作成される。したがって、このメッセージの大部分は、価格情報応答メッセージ２から抽出される。
【０１１４】
更に、このメッセージは、個人レスポンダのウェブサイトＵＲＬを表現するオプショナルフィールドを提示するので、リクエスタは、レスポンダに関する個人情報を取得できる。このフィールドは、リクエスタがレスポンダは多数の興味深いファイルを保有していることを知った場合に有効である。自分のウェブサイトアドレスを与えることによって、レスポンダは、完全なファイルカタログ、電子メールサービス、チャットなどの付加価値サービスにアクセスするための方法をリクエスタに与える。
【０１１５】
詳細なメッセージフォーマットは表４に記載されている。
【表４】
2004517411.tif 000006
尚、署名付き購入情報フィールドは、問い合わせヒットメッセージ４中に、ヒット回数の回数だけ出現する（リクエスタの要求を満たすファイル毎に１回ずつ出現する。）。また、このメッセージ中にレスポンダによって与えられた価格は、対応したコンテンツを製作したコンテンツ・プロバイダのために働く中央機関によって課せられた価格である。レスポンダは、価格情報要求メッセージと価格情報応答メッセージのペアによって、これらの価格を知る。
【０１１６】
５．プレビュー要求メッセージ５
このオプショナルメッセージは、特定のファイルのプレビューを要求するためリクエスタによって送信される。このメッセージは、リクエスタが問い合わせヒットメッセージ４を受信すると送信される。レスポンダの提出したリストから特定のファイルを選択することにより、リクエスタは、このメッセージを送信することによってファイルのプレビューを受信することができる。
【０１１７】
尚、このメッセージは、ポイント・ツー・ポイント式メッセージであるため、共有ネットワーク１１０を行き来しない。この目的のため、このメッセージは、問い合わせヒットメッセージ４でレスポンダから受信したＩＰアドレスフィールドとポート番号フィールドを使用する。
【０１１８】
詳細なメッセージフォーマットは表５に記載されている。
【表５】
2004517411.tif 000007
【０１１９】
６．プレビューメッセージ６
このメッセージは、プレビュー要求メッセージ５でリクエスタによって要求されたプレビューを送信するため、レスポンダによって使用される。送信されたプレビューは、リクエスタのクライアント・ソフトウェアによって解釈されずに、後で適切なプレーヤで再生するため局所的に蓄積される。
【０１２０】
詳細なメッセージフォーマットは表６に記載されている。
【表６】
2004517411.tif 000008
【０１２１】
７．情報要求メッセージ７
このメッセージは、オプショナルであり、先に受信した問い合わせヒットメッセージ４から選択されたファイルの組に対する優先価格を受け取るため、リクエスタによって使用される。このメッセージは、典型的に、リクエスタが、このような優先価格を正当化する多数のファイルを購入したい場合に使用される。このメッセージを受信すると、レスポンダは、新たな価格情報を取得するため、新しい価格情報要求メッセージ２を中央機関へ送信する。
【０１２２】
問い合わせメッセージ１及び問い合わせヒットメッセージ２に対して、このメッセージは、問い合わせヒットメッセージ４に格納されているＩＰアドレスフィールド及びポート番号フィールドを使用して、ポイント・ツー・ポイント式接続を介して、レスポンダへ直接的に送信される。したがって、このメッセージは、共有ネットワーク１１０内を回送されない。
【０１２３】
詳細なメッセージフォーマットは表７に記載されている。
【表７】
2004517411.tif 000009
尚、要求ファイル情報フィールドは、情報要求メッセージ７の中に、情報要求数の回数だけ出現する（リクエスタが購入情報を要求したファイル毎に１回ずつ出現する。）。
【０１２４】
８．情報応答メッセージ８
このメッセージは、情報要求メッセージ７でリクエスタによって要求されたすべての購入情報を含む。更に、このメッセージは、個人的なレスポンダのウェブサイトＵＲＬを提示するので、リクエスタは、レスポンダに関する個人情報を得ることができる。このフィールドは、リクエスタがレスポンダは多数の興味深いファイルを保有していることを知った場合に有効である。自分のウェブサイトアドレスを与えることによって、レスポンダは、完全なファイルカタログ、電子メールサービス、チャットなどの付加価値サービスにアクセスするための方法をリクエスタに与える。
【０１２５】
情報要求メッセージ７と同様に、このメッセージは、共有ネットワーク１１０内を行き来することが無く、リクエスタへ著癖的に送信される。
【０１２６】
詳細なメッセージフォーマットは表８に記載されている。
【表８】
2004517411.tif 000010
尚、署名付き購入情報フィールドは、情報応答メッセージ８の中に、購入情報数の回数だけ出現する（リクエスタが購入情報を要求するファイル毎に１回ずつ出現する。）。理論的には（最良のケースでは）、購入情報数フィールドは、情報要求メッセージ７の情報要求数フィールドと同じ値をとる。しかし、うまく機能しないケースでは（例えば、中央機関が停止し、データベースが機能停止している場合など）、レスポンダは、あるファイルに関する購入情報を送信できない。この場合、
購入情報数＜情報要求数
となる。このメッセージ８を受信すると、リクエスタは、受信情報が自分の要求した情報と一致していることを検証する必要がある。検証に失敗した場合、適応的な動作がリクエスタによって行われる。合理的な動作は、一致しなかったすべての購入情報を読み飛ばすことであろう。
【０１２７】
９．金融取引９
このセクションには、特別なメッセージは扱われないが、一組のメッセージの結果として、要求されたファイルに対するリクエスタによる中央機関への支払が行われる。支払段階は、本発明の範囲に含まれないが、中央機関がサポートしている（例えば、ＳＥＴ、ＳＳＬ、小額決済プロトコルなどの）任意の支払プロトコル（即ち、問い合わせヒットメッセージ４及び情報応答メッセージ８で送信されたプロトコル）によって実現可能である。
【０１２８】
しかし、支払段階よりも先に、リクエスタが注文フォームと、許容された支払プロトコルのリストから選択した支払方式と、を提示する交渉段階が行われるべきである。この情報は、リクエスタによって前に受信された情報応答メッセージ又は問い合わせヒットメッセージから抽出される。
【０１２９】
次の表９には、リクエスタから中央機関へ送信された交渉メッセージが記載されている。
【表９】
2004517411.tif 000011
尚、署名付き購入情報フィールドは、交渉メッセージの中にファイル数の回数だけ出現する（リクエスタが購入したいファイル毎に１回ずつ出現する。）。金融取引を始める前に、中央機関は、署名付き購入情報フィールドに格納されている提示価格情報の有効性及びレスポンダ識別情報を検証する。検証が失敗した場合、取引は取り消される。
【０１３０】
１０．支払チケットメッセージ１０
このメッセージは、金融取引が完了すると、中央機関によってリクエスタへ配信される。
【０１３１】
詳細なメッセージフォーマットは表１０に記載されている。
【表１０】
2004517411.tif 000012
尚、取引情報フィールドは、支払チケットメッセージ１０の中に、取引数の回数だけ出現する（リクエスタが代金を支払ったファイル毎に１回ずつ出現する。）。
【０１３２】
１１．支払チケット転送メッセージ１１
このメッセージは、リクエスタが著作権付きファイルを購入したことを証明するため、リクエスタからレスポンダへ送信される。このメッセージは、支払チケットメッセージ１０と大体同じデータを格納する。
【０１３３】
詳細なメッセージフォーマットは表１１に記載されている。
【表１１】
2004517411.tif 000013
【０１３４】
１２．ダウンロード情報メッセージ１２
このメッセージは、レスポンダがリクエスタによるファイルの代金の支払を証明する支払チケット転送メッセージ１１を受信すると、レスポンダからリクエスタへ送信される。このメッセージにおいて、レスポンダは、リクエスタが購入したファイルのダウンロードを要求する先のＵＲＬを与える。簡単化のため、ダウンロード段階では、ＨＴＴＰプロトコルを使用することが提案される。したがって、ＨＴＴＰサーバは、ダウンロード情報メッセージ１２に収容されたＵＲＬで動かされるべきである。
【０１３５】
更に、ダウンロード段階を盗聴から保護するため、ダウンロードされるファイルは暗号化される。そのため、ダウンロード情報メッセージ１２は、元の購入ファイルを取り出すためリクエスタによって使用される復号鍵を含む。
【０１３６】
その上、この機能は、リクエスタが自分の購入したファイル以外のファイルをダウンロードすることを防止する。
【０１３７】
詳細なメッセージフォーアットは表１２に示されている。
【表１２】
2004517411.tif 000014
尚、このメッセージを受信すると、リクエスタは、受信したダウンロード情報の数が購入ファイルの数と一致することを検証すべきである。
【０１３８】
１３．ダウンロード動作１３
リクエスタがダウンロード情報メッセージ１２を受信すると、リクエスタは、ダウンロード段階１３を開始することができる。
【０１３９】
次の表１３は、リクエスタによってダウンロードされたコンテンツフォーマットの例を説明する。既に強調したように、このコンテンツは暗号化されているので、盗聴が阻止される。
【表１３】
2004517411.tif 000015
次に、レスポンダが共有ネットワークを介してデジタルコンテンツを配信したことに対しレスポンダに報酬を供与する好ましい方法を説明する。実際上、レスポンダによって配信されたコンテンツがリクエスタによって購入されるときには、レスポンダは、中央機関から対応した代金の支払を受け取るべきである。
【０１４０】
上述のように、共有ネットワークを介してデジタルコンテンツを配信したすべてのレスポンダは、配信に対する報酬を受けるため、少なくとも一つの中央機関に登録されていなければならない。レスポンダが同じ中央機関と連携していない種々のコンテンツ・プロバイダによって作成された著作権付きのコンテンツを提示する場合には、同じレスポンダは幾つかの中央機関に登録することができる。
【０１４１】
レスポンダに代金を支払う好ましい方法によれば、登録段階で各レスポンダの口座を開き、この口座をレスポンダ識別情報とリンクさせることが提案される。登録中に、レスポンダは、中央機関が勘定決済を行うために必要なすべての個人データ（名前、住所、銀行口座番号など）を中央機関に提供する。次に、定期的に、レスポンダが登録されている中央機関は勘定決済を行い、レスポンダへの支払がなされる。決済方法は、登録段階中に中央機関とレスポンダの間で協議されるべきであり、本発明の範囲には含まれない。
【０１４２】
著作権付きのコンテンツを購入する間に、中央機関は、金融取引９の交渉メッセージを受信すると、レスポンダの口座に貸方を記入する。既に、セクション９（金融取引９）で強調したように、このメッセージは、中央機関によって配布されたレスポンダ識別情報を含む。このようにして、中央機関は、レスポンダへの支払のために必要なすべてのデータを入手する。
【０１４３】
別の解決手法では、レスポンダは、リクエスタから（支払チケット転送メッセージ１１で）受信した支払チケットメッセージデータを支払を受けるため中央機関へ提示する。レスポンダは、支払チケットメッセージデータを受信すると、販売のプルーフとして支払チケットメッセージデータを保存する。一方、中央機関は、作成されたすべての支払チケットメッセージを保存している。次に、レスポンダがこれらのメッセージを各中央機関へ提示すると、中央機関は、レスポンダとの間でオンライン金融取引を実行する前に、メッセージの有効性を検証することが可能である。
【図面の簡単な説明】
【図１】
情報共有システムの原理説明図である。
【図２ａ】
共有ネットワーク・アーキテクチャの一例の説明図である。
【図２ｂ】
共有ネットワーク・アーキテクチャの一例の説明図である。
【図２ｃ】
共有ネットワーク・アーキテクチャの一例の説明図である。
【図３】
本発明に従って共有ネットワークを介してデジタルコンテンツを配信する好ましいプロトコルの説明図である。
【図１】
2004517411.tif 000016
【図２ａ】
2004517411.tif 000017
【図２ｂ】
2004517411.tif 000018
【図２ｃ】
2004517411.tif 000019
【図３】
2004517411.tif 000020
【国際公開パンフレット】
2004517411.tif 000021
2004517411.tif 000022
2004517411.tif 000023
2004517411.tif 000024
2004517411.tif 000025
2004517411.tif 000026
2004517411.tif 000027
2004517411.tif 000028
2004517411.tif 000029
2004517411.tif 000030
2004517411.tif 000031
2004517411.tif 000032
2004517411.tif 000033
2004517411.tif 000034
2004517411.tif 000035
2004517411.tif 000036
2004517411.tif 000037
2004517411.tif 000038
2004517411.tif 000039
2004517411.tif 000040
2004517411.tif 000041
2004517411.tif 000042
2004517411.tif 000043
2004517411.tif 000044
2004517411.tif 000045
2004517411.tif 000046
2004517411.tif 000047
2004517411.tif 000048
2004517411.tif 000049
2004517411.tif 000050
2004517411.tif 000051
2004517411.tif 000052
2004517411.tif 000053
2004517411.tif 000054
【国際公開パンフレット（コレクトバージョン）】
2004517411.tif 000055
2004517411.tif 000056
【手続補正書】
【提出日】平成15年4月7日(2003.4.7)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
リクエスタ（２００）によるコンテンツの代金支払のため該リクエスタと金融取引（９）を行う手段を含む中央機関（２０１−２０４）を有し、
共有ネットワーク（１１０）を介してデジタルコンテンツをリクエスタ（２００）へ配信するシステムであって、
該中央機関に登録され、該リクエスタから受信した購入のプルーフ（１１）と引き換えに、該リクエスタとのピア・ツー・ピア接続を使用して、コンテンツに対応したデータファイルを該リクエスタ（２００）へ配信する手段を備えているレスポンダ（３００）を更に有し、
該中央機関は、
購入のプルーフ（１０）を該リクエスタへ配信する手段と、
リクエスタによるコンテンツの購入と引き換えに該レスポンダに報酬を供与するレスポンダ補償手段と、
を更に含む、
ことを特徴とするシステム。
【国際調査報告】
2004517411.tif 000057
2004517411.tif 000058
2004517411.tif 000059