JP4156129B2 - 製品に対する調査情報を生成する装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、通信システムに関し、具体的には、インターネットまたはワールド・ワイド・ウェブ上で行われる通信に関する。本発明の具体的な用途は、金銭の支払を必要とする商品またはサービスの購入を伴うアプリケーションおよびサービスにある。
【０００２】
【従来の技術】
インターネット・ショッピング・モールでのオンライン・ショッピングなど、インターネット上の多数のアプリケーションおよびサービスは、商品およびサービスに対する買い手の支払能力に依存している。さらに、電子支払のない電子商取引の魅力は限られている。
【０００３】
iKP（1KP、2KPおよび3KPを表す）は、清算および認可に既存の金融ネットワークを使用する、消費者と商人の間のクレジット・カード・ベースの取引を実施するための保護された電子支払プロトコルの系列である（参照によって本明細書に組み込まれる、ベラーレ（M. Bellare）他著、「iKP - A Family of Secure Electronic Payment Protocols」、Proceedings of the First USENIX Workshop on Electronic Commerce、米国ニューヨーク州ニューヨーク、１９９５年６月１１日〜１２日、第８９ページ〜１０６ページを参照されたい）。iKPプロトコルは、公開鍵暗号に基づき、現在広範囲で使用されている周知のプロトコルであるSecure Electronic Transaction（SET）プロトコル（次に説明する）の先駆者である。
【０００４】
Secure Electronic Transaction（SET）プロトコルは、MasterCard社およびVISA社によって共同開発され、参照によって本明細書に組み込まれるhttp://www.mastercard.com/set/に記載されている。SETは、特に、既存のクレジット・カード・インフラストラクチャに基づく支払をサポートするように設計されている。SETでは、消費者と商人の両方の証明された口座IDと共に、ロックと鍵のシステムを使用する。客とオンライン・ストアの間で交換される情報の暗号化またはスクランブルの独自の処理を介して、SETは、便利、秘密かつ保護された支払処理を保証する。具体的に言うと、SETは、支払情報を秘密に保ち、送信されるデータのすべてについて暗号化を介して保全性を高め、カード保持者が商標付きの支払カード口座の合法的なユーザであることの認証を提供し、商人が取得機関（acquiring institution）との関係を介して商標付き支払カード取引を受け入れることができることの認証を提供する。SETプロトコルは、既存のクレジット・カードのインフラストラクチャおよび機構に基づく支払をサポートするように設計されているので、SETでの支払には、取引ごとにかなりの料金（通常は最低２０セント）が伴い、したがって、小額の支払には不適切である。
【０００５】
ハーツバーグ（Herzberg）およびヨチャイ（Yochai）は、MiniPayと称する小額または「マイクロ支払」のための支払機構を説明した（ハーツバーグ（Amir Herzberg）およびヨチャイ（Hilik Yochai）共著、「Mini-Pay: Charging per Click on the Web」、Sixth WWW Conference、Santa Clara、１９９７年４月を参照されたい）。この議事録は、参照によって本明細書に組み込まれる、インターネットのhttp://www6.nttlabs.com/HyperNews/get/PAPER99.htmlでも入手できる。MiniPayは、情報、ゲーム、ロード可能ソフトウェアなどのための小額の支払を必要とするアプリケーションおよびサービスに適している。MiniPayを介して購入される単一の項目を、定義済みの期間の間だけサイト全体にアクセスするための許可とすることもできる。その結果、買い手は、サイトへのアクセス権を獲得した後に、そのサイトを介して入手できる複数の追加のHTMLリンクに自由にアクセスできるようになる。売り手から買い手へHTMLページ内で送信される申し出に含まれるパラメータによって、申し出の詳細が説明されるはずである。MiniPayプロトコルは、特に、インターネット上で購入され、買い手に配送される情報またはサービスの支払のための手段を提供するために設計されている。
【０００６】
MiniPayプロトコルでは、インターネットのユーザが、たとえば新聞などの文書の電子的に記憶されたコピーを受信するなどの製品またはサービスに対する小額の支払を行う。ミニ支払とは、たとえば２５ドルを超えない支払など、小額の支払いである。ウェブ文書の場合、支払って実際の文書を見る前に、ユーザは、無料で、それを説明した要約、概要または販促資料を見ることができる。実際の文書を「見る」前に、ユーザは、支払を発行しなければならず、これは、「署名」すなわち、ユーザの秘密鍵を用いて電子ディジタル署名を用意することによって達成される。各ユーザは、ミニ支払を認可するのに使用することができる公開鍵／秘密鍵対を有する。要するに、ディジタル署名によって支払が認可される。署名が用意され、検証された後に、ユーザは、要求した情報を「見る」ことを許可される。MiniPayプロトコルは、電子的に記憶された情報にできる限り簡単に苦労せずにアクセスできるように設計された「ポイント・アンド・クリック」モデルに埋め込まれている。したがって、ユーザが「クリック」する（情報を「見る」ことを要求する）時に、MiniPayプロトコルが透過的に呼び出され、その結果、暗号処理の詳細は、ユーザから隠蔽される。
【０００７】
MiniPayプロトコルの短所は、実際のウェブ文書を「見る」前に、支払を行うことによって、ユーザが確約しなければならない点である。したがって、支払を行い、文書を「見る」ために「クリック」する前に、ユーザが、要求するウェブ文書についてより多くを知るための選択肢を有することが望ましい。
【０００８】
【発明が解決しようとする課題】
本発明の目的は、買い手が製品調査結果を受信できるようにする、電子支払システムを提供することである。
【０００９】
本発明のもう１つの目的は、クライアント・ブラウザを使用することによって、製品調査結果を便利に表示するための、電子支払システム内の手段を提供することである。
【００１０】
本発明のもう１つの目的は、買い手が、購入した製品に関する調査を受けることができる、電子支払システムを提供することである。
【００１１】
本発明のもう１つの目的は、クライアント・ブラウザを使用して、調査結果を便利に入力するための、電子支払システム内の手段を提供することである。
【００１２】
本発明のもう１つの目的は、買い手から評価者に送信される製品調査応答の保全性を保護するのに便利な手段を提供することである。
【００１３】
本発明のもう１つの目的は、有効な買い手を装ったハッカーによって評価者に送信された誤った製品調査応答を評価者が検出するのに便利な手段を提供することである。
【００１４】
本発明のもう１つの目的は、製品を購入したと主張する買い手が実際にその製品を購入したことを評価者が検証するのに便利な手段を提供することである。
【００１５】
本発明のもう１つの目的は、買い手が売り手から購入証明書を受け取るのに便利な手段を提供することである。
【００１６】
【課題を解決するための手段】
本発明は、買い手が、購入を行う前に製品評価情報を受信することができ、買い手が、購入した製品に関するコメントを提供できるようにするためにオンライン調査に参加できるようにする、MiniPayシステムなどの電子支払システムで製品調査情報を提供するための方法および装置に関する。本発明によれば、売り手に電子支払注文を送信することによって買い手が製品を購入する電子支払システムが、製品調査情報を提供するように機能強化される。追加の当事者である評価者は、以前に売り手から製品を購入した買い手から製品調査情報を集め、要求時に、将来なるであろう買い手に製品調査情報を提供する。
【００１７】
買い手から評価者に送信される調査応答と、評価者から買い手に送信される調査結果は、傍受や改竄の対象になる可能性がある。本発明は、とりわけ、買い手から評価者に送信される調査応答の保全性の問題に関する。
【００１８】
買い手から評価者に送信される調査応答は、たとえばアクティブ・ライン・アタック（active line attack）を実行する敵対者による、改竄の対象になる可能性がある。しかし、さらに深刻な脅威は、買い手を装い、誤った調査応答を評価者に送信するハッカーからもたらされる。これによって、調査結果を偏向させたり不正なものにし、したがって、信頼価値のないものにすることが簡単にできる。さらに、最終的には、評価者の信用が傷付けられ、失われる可能性もある。
【００１９】
本発明は、製品調査情報を提供する買い手が、売り手からその製品を実際に購入したことを評価者が検証できるようにするためのさまざまな方式を意図したものである。ある検証方式では、買い手が、ランダムに生成される秘密の値の一方向関数として認証コードを生成し、支払注文にその認証コードを含める。買い手は、後に調査情報を評価者に供給する時に、調査情報と共に秘密の値を含める。評価者は、買い手の支払請求システムに、取引を識別する情報と共に秘密の値を提示することによって、購入取引を検証する。買い手の支払請求システムは、売り手から受信した取引情報から認証コードを取り出し、一方向関数を使用して秘密の値から再生成されたコードと比較する。買い手の支払請求システムは、比較結果を評価者に通信し、評価者は、買い手と売り手の間の実際の取引に関連することが認証された場合に、その調査情報を使用する。
【００２０】
もう１つの検証方式では、評価者は、買い手の支払請求システムに取引識別情報だけを提示する。もう１つの検証方法では、売り手が、支払注文に署名し、署名された支払注文を購入証明書として買い手に返し、買い手は、その購入証明書を評価者に提示する。
【００２１】
本発明は、調査応答の保全性を保護し、調査応答が、問題の製品を実際に購入した買い手からのものであることを保証するための方法を提供する。その結果、買い手は、製品評価情報を受け取り、リアル・タイムで製品調査質問表に書きこむことができ、したがって、買い手に追加情報が提供され、これによって、製品購入に関して買い手がより多くの情報に基づくよりよい判断を行えるようになる。
【００２２】
本発明は、下で説明するように、データのプライバシと認証のために、対称鍵暗号と非対称鍵暗号を利用する。
【００２３】
以下ではソフトウェア実施例を説明する。しかし、一般に、本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせで実施することができる。
【００２４】
【発明の実施の形態】
本発明の電子支払システムの説明の前置きとして、まず従来のMiniPayシステムを説明する。図１を参照すると、通常のMiniPayシステムは、以下の５つの当事者からなる。
１．MiniPay Wallet（札入れ）として買い手の計算機上で走行するMiniPayソフトウェアである買い手１０。
２．オンライン・コンテンツ・プロバイダまたはオンライン・サービス・プロバイダである売り手（または商人）２０。
３．通常はインターネット・アクセス・プロバイダ（IAP）４０、電話会社（Telco、PTT）、金融処理業者（financial processor）である、買い手の支払請求システム。
４．通常は銀行またはインターネット・サービス・プロバイダ（ISP）３０である売り手の支払請求システム。
５．買い手の支払請求システムであるIAP４０を売り手の支払請求システムであるISP３０または銀行に接続する取引所（図示せず）。これは、通常は金融機関になる。
【００２５】
取引所がない当事者４．の場合に関して、MiniPayの基本プロトコルの流れは、次のように述べることができる。
１．買い手１０は、売り手２０に、通常の形でブラウザからサーバに送信される通常のGetURL（URL取得）メッセージにピギーバックして、署名されたMiniPay支払注文を送信する。この支払注文には、IAP４０から買い手１０に毎日供給される日次証明書も含まれる。売り手２０は、証明書のIAP４０の署名を検証し、これによって、買い手１０がIAP４０にきちんと会費を支払っていることを確認し、顧客（買い手１０）の公開鍵を知る。売り手２０は、顧客（買い手１０）の公開鍵を使用してMiniPay支払注文の署名を検証する。署名が正しいと検証された場合、売り手２０は、署名されたMiniPay支払注文を受け入れ、取引を完了する。そうでない場合には、MiniPay支払注文は受け入れられず、取引は拒絶される。
２．証明書には、IAP４０からのオンライン確認が必要になる前に買い手１０が行うことのできる１日あたりの購入の最高額を表すオフライン限度も含まれる。売り手２０が、この売り手２０でのその日の買い手１０による支出合計がオフライン限度を超えることに気付いた場合、売り手２０は、Extra-spending（超過支出）要求メッセージをIAP４０に送信することによって、IAP４０に連絡する。IAP４０は、Extra-spending要求の額を用いて買い手１０による既知の支出を更新し、もう一度問い合わせる前の追加支出額の承認または拒絶のいずれかを伴う電子署名付きのExtra-spending応答を送り返す。この署名は、公開鍵暗号を使用して達成される。
３．定期的に、または、受信した支払注文の数が多すぎる時に、売り手２０は、すべての買い手から受信した支払注文のすべてを集計し、単一の署名付き供託メッセージとしてISP３０に送信し、これが清算処理の開始を表す。
４．ISP３０は、すべての売り手からの支払注文を定期的に集計し、署名付き供託メッセージで対応するIAPに転送する。
５．毎日の終りに、または、翌日の最初の購入時に、買い手のwalletが、日次処理のためにIAP４０に連絡する。この処理では、IAP４０が、walletに、前日の購入に対する同意を確認する。具体的に言うと、IAP４０は、停電などが原因で売り手２０が供託できなかった購入があるかどうかを通知し、その結果、買い手１０のwalletの差引残高とIAP４０の差引残高が一致するようにする。IAP４０とwalletは、差引残高と購入額に互いに署名し、これによって、記録の一部を消去できるようにする。IAP４０の署名は、買い手のwalletが支払注文のそれぞれに付加する日次証明書としても働く。
【００２６】
上の動作１〜５は、当事者のそれぞれのMiniPayモジュールすなわち、買い手１０のwalletと、売り手２０、IAP４０およびISP３０のモジュール（図１を参照されたい）によって自動的に行われる。
【００２７】
MiniPayプロトコルでは、暗号が使用され、具体的には、公開鍵暗号が使用される。暗号システムは、データ処理の分野で周知である。一般に、このようなシステムは、暗号鍵を使用して平文入力ブロックに対して暗号化動作を実行して、暗号文出力ブロックを作る。暗号化されたメッセージの受信者は、非暗号化鍵を使用して対応する非暗号化動作を実行して、平文ブロックを回復する。
【００２８】
暗号システムは、２つの一般的な範疇に分類される。データ暗号化規格（DES）システムなどの対称暗号システム（秘密鍵暗号システム）では、メッセージの暗号化と非暗号化に同一の秘密鍵を使用する。DESシステムでは、独立に指定可能な５６ビットを有する鍵を使用して、６４ビットの平文ブロックを暗号文ブロックに変換し、逆変換する。
【００２９】
その一方で、非対称暗号システム（公開鍵暗号システム）では、暗号化と非暗号化に、お互いから簡単に導出することのできない異なる鍵を使用する。メッセージ受信を望む人は、対応する暗号鍵／非暗号化鍵対を生成する。暗号鍵は公開されるが、対応する非暗号化鍵は秘密に保たれる。この受信者との個人的な通信を望む人は、受信者の公開鍵を使用してメッセージを暗号化することができる。しかし、受信者だけが秘密鍵を有するので、この受信者でなけばメッセージを非暗号化することはできない。おそらく、最もよく知られている非対称暗号システムは、開発者であるリベスト（Rivest）、シャミル（Shamir）およびエドルマン（Adleman）にちなんで命名されたRSA暗号システムである。
【００３０】
非対称暗号アルゴリズムは、データ通信システム内でメッセージの出所を証明したり、メッセージのセキュリティまたは保全性を確保するのにも広く使用されている。このようなアルゴリズムはさまざまなタイプが存在するが、周知の変形の１つがRSAアルゴリズムである。公開鍵暗号とRSAアルゴリズムの全般的な紹介は、シュナイア（Schneier）著、「Applied Cryptography」、第２版、第４６１ページ〜５００ページ、Wiley刊、１９９６年に記載されている。これらのアルゴリズムは、より古い対称鍵アルゴリズムに対する明確な長所を有する。具体的に言うと、これらのアルゴリズムは、独立の第三者が中央の権威を参照せずに、メッセージを受信し、検証できるようにするために、鍵を公開または証明できるようにする能力を提供する。
【００３１】
データ通信における公開鍵暗号の使用の１例が、ディジタル署名の生成である。この技法の背後にある原理は、送信されるメッセージと署名するユーザとに依存する公開ディジタル値（署名）を作成し、受信側のユーザが、他の誰でもなく送信元のユーザだけがその署名値を作成でき、他の誰でもなくそのユーザがこのメッセージの署名値を作成したことを確認できるようにすることである。
【００３２】
このようなシステムでは、メッセージに署名する当事者は、対応する公開鍵が存在する秘密鍵を有する。公開鍵は入手可能であり、その結果、誰もが公開鍵を使用して、署名者が秘密鍵を使用して暗号化したデータを非暗号化することができるが、秘密鍵へのアクセス権がない者は、そのように暗号化されたデータを作成することができない。
【００３３】
通常、署名者は、別のメッセージが同一の値をもたらす可能性が極度に低い強いハッシュ・アルゴリズムを使用して、メッセージからハッシュ値を作る。この値を計算する手段は、周知であるが、同一の値をもたらす異なるメッセージを決定するための実現可能な方法は存在しない。署名者は、秘密鍵を使用してその値を暗号化し、メッセージと暗号化された値とを受信者に送信する。
【００３４】
受信者は、公開鍵を使用して値を非暗号化し、メッセージに対する計算によって同一の値が得られるかどうかを試験することができる。同一の値が得られる場合、同一の値をもたらす別のメッセージを計算するための実現可能な方法がないので、受信者は、このメッセージが署名されたメッセージであることを確信することができる。また、受信者は、秘密鍵へのアクセス権がない者は暗号化された値を作成できないので、署名者が実際にそのメッセージに署名したことを確信することができる。
【００３５】
いくつかの情況では、プライバシのため、ならびにメッセージに署名するために、公開鍵暗号を使用することが有利な場合がある。そのような場合には、この２つの異なる目的のために別々の鍵を使用することが賢明であり、一般に実践されている。したがって、１対の鍵（公開鍵と秘密鍵）を使用して、プライバシのためにメッセージを暗号化し、もう１対の鍵（公開鍵と秘密鍵）を使用して、メッセージに署名する。
【００３６】
MiniPayプロトコルで買い手１０とIAP４０が使用する公開鍵および秘密鍵は次の通りである。
１．買い手１０（以下ではBと呼称する）は、公開鍵／秘密鍵対（以下ではPUB_BおよびPRIV_Bと呼称する）を有する。買い手１０は、売り手に送信する支払注文への署名にPRIV_Bを使用し、売り手２０は、買い手１０から受信した、買い手が署名した支払注文の検証にPUB_Bを使用する。また、買い手１０は、自分の秘密鍵（PRIV_B）を使用して、自分のIAP４０に送信する、自分のwalletの差引残高と前日の購入の合計を含む日次メッセージに署名する。IAP４０は、買い手の公開鍵（PUB_B）を使用して、買い手１０から受信する、署名付きの日次メッセージを検証する。
２．IAP４０は、公開鍵／秘密鍵対を有する（以下ではPUB_IAPおよびPRIV_IAPと呼称する）。IAP４０は、それが発行する証明書に署名するのにPRIV_IAPを使用し、売り手２０は、IAP４０が発行した署名付きの証明書を検証するのにPUB_IAPを使用する。IAPが署名した証明書には、買い手１０の公開鍵（PUB_B）、買い手１０の口座番号（acct_B）および他の情報が含まれる。acct_Bは、買い手Bの身元を表す。このように署名された証明書によって、買い手１０の公開鍵（PUB_B）が彼の口座番号（acct_B）に結び付けられる。また、IAP４０は、IAP４０から売り手２０に送信されるExtra-spending応答メッセージへの署名にPRIV_IAPを使用する。売り手２０は、IAP４０から受信した署名付きのExtra-spending応答メッセージの検証にPUB_IAPを使用する。
３．売り手２０は、公開鍵／秘密鍵対（以下ではPUB_SおよびPRIV_Sと呼称する）を有する。売り手２０は、彼のISP３０に送信する供託メッセージへの署名にPRIV_Sを使用する。ISP３０は、売り手２０から受信した署名付き供託メッセージの検証にPUB_Sを使用する。供託メッセージは、集計された複数の支払注文を含む。
４．ISP３０は、公開鍵／秘密鍵対（以下ではPUB_ISPおよびPRIV_ISPと呼称する）を有する。ISP３０は、さまざまなIAPに送信する供託メッセージへの署名にPRIV_ISPを使用する。各IAP４０は、ISP３０から受信した署名付き供託メッセージの検証にPUB_ISPを使用する。
【００３７】
MiniPayプロトコルを実行する前に、買い手１０がその支払請求システム（IAP４０）の公開鍵と身元を知り、売り手２０がIAP４０とその支払請求システム（ISP３０）の公開鍵と身元を知ることが必要である。MiniPayプロトコルは、未知の鍵をオンラインで問い合わせる必要がないように設計されている。というのは、これが非効率的になるからである。これは、すべての２つの対等の支払請求サーバの間と、IAP４０から売り手２０に対して実行される定期的な公開鍵配布プロトコルの使用を介して達成される。
【００３８】
その一方で、買い手とIAPの公開鍵は、登録および経路指定プロトコル（下に示す）を使用して交換される。同様の形で、売り手２０とISP３０の公開鍵は、類似の登録および経路指定プロトコル（特に示さない）を使用して交換される。
【００３９】
本明細書で説明するMiniPayプロトコルでは、以下の表記を使用する。
１．署名：S_x(msg)は、メッセージmsgに対する当事者xによる署名を表す。たとえばRSAアルゴリズムなど、メッセージ回復の特性を有する署名アルゴリズムは仮定しない。したがって、MiniPayプロトコルでは、msgのうちで、受信者に知られていないか、受信者が計算できない部分は、受信者が署名を検証するために必要なすべての情報を有するようにするために、明文で送信される。
２．ハッシュ：H(msg)は、メッセージmsgの一方向ハッシュを表す。これは、誰でもmsgから簡単に計算できるが、msgについて何も知らせない。また、H(msg)=H(different_msg)になる異なるメッセージ（different_msg）を見つけることは非常に困難である。
【００４０】
MiniPayプロトコルは、次のように説明することができる。
【００４１】
登録および経路指定プロトコルは、IAP４０に関する口座を設定し、この口座に関連する公開鍵を証明するために、買い手１０によって使用される。登録および経路指定プロトコルは、IAP４０に買い手１０の公開鍵（PUB_B）を配布し、買い手１０にIAP４０の公開鍵（PUB_IAP）を配布するのに使用される。登録および経路指定プロトコルを、以下で説明する。
【００４２】
当初、買い手１０は、IAP４０からacct_Bと秘密のcode_Bを受信し、PUB_BとPRIV_Bを生成する。ここで、
１．acct_Bは、IAP４０によって割り当てられたBの口座識別子である。
２．code_Bは、IAP４０によって割り当てられた秘密の値であり、BがIAP４０に対して自分の身元を証明するために、Bによって使用される。
【００４３】
その後、Bは、IAP４０にReg_req、salt1、acct_B、PUB_B、timeおよびS_B(Reg_req, H(code_B, salt1, PUB_B, acct_B, time))を送信する。ここで、
１．Reg_reqは、そのメッセージが登録要求メッセージであることを示すフィールドである。
２．salt1には、買い手１０によって生成された乱数値または擬似乱数値（ランダマイザ）が格納され、推測（辞書）攻撃からcode_Bを保護するのに使用される。PUB_Bは、Ｂの公開検証鍵である。
３．acct_Bは、Ｂの口座識別子である。
４．PUB_Bは、Ｂの公開検証鍵である。
５．timeは、登録要求メッセージの日付と時刻を表す。
【００４４】
自己署名付きメッセージS_B(Reg_req, ...)によって、前にIAP４０から受信した秘密コードcode_Bを使用して、ユーザacct_BのためにPUB_Bが登録される。
【００４５】
IAP４０は、受信したacct_Bの値を使用してcode_Bを回復する。IAP４０は、回復されたcode_Bの値と、受信したsalt1、PUB_B、acct_Bおよびtimeの値を使用して、ハッシュ値H(code_B, salt1, PUB_B, acct_B, time)を計算する。その後、IAP４０は、値Reg_reqおよびH(code_B, salt1, PUB_B, acct_B, time)と共にBの公開検証鍵PUB_Bを使用して、署名S_B(Reg_req, H(code_B, salt1, PUB_B, acct_B, time))を検証する。署名を検証する処理は、具体的な署名アルゴリズムに依存し、このプロトコル自体の動作および機能に関して重要ではない。timeフィールドに正しい情報が含まれ、署名が有効であると判定された場合には、この登録要求メッセージと公開鍵（PUB_B）が受け入れられ、そうでない場合には、この登録要求メッセージが拒絶される。
【００４６】
その後、IAP４０は、Reg_res、OK/fail_code、salt2、acct_B、PUB_B、time、fees、PUB_IAPおよびS_IAP(Reg_res, OK/fail_code, acct_B, PUB_B, time, fees, H(code_B, salt2, PUB_IAP))をBに送信する。ここで、
１．Reg_resは、このメッセージが登録応答メッセージであることを示すフィールドである。
２．OK/fail_codeは、登録応答が受け入れられた（OK）か受け入れられなかった（Not OK）かを示すフィールドである。登録応答が受け入れられなかった場合には、OK/fail_codeフィールドに、失敗の理由を説明する失敗コードが格納される。
３．salt2には、IAP４０によって生成された乱数値または擬似乱数値（ランダマイザ）が格納され、推測（辞書）攻撃からcode_Bを保護するのに使用される。
４．acct_Bは、Bの口座識別子である。
５．PUB_Bは、Bの公開検証鍵である。
６．timeは、登録応答メッセージの日付と時刻を表す。
７．feesは、IAP４０が課す料金を指定し、買い手のwalletが売り手２０から送信されたコストに追加しなければならない額である。
８．PUB_IAPは、IAPの公開検証鍵である。
【００４７】
買い手１０は、以前に保存したcode_Bの値と、受信したsalt2およびPUB_IAPの値を使用して、ハッシュ値H(code_B, salt2, PUB_IAP)を計算する。その後、買い手１０は、IAPの公開検証鍵PUB_IAPを、値Reg_res、OK/fail_code、salt2、acct_B、PUB_B、time、feesおよびH(code_B, salt2, PUB_IAP)と共に使用して、署名S_IAP(Reg_res, OK/fail_code, acct_B, PUB_B, time, fees, H(code_B, salt2, PUB_IAP))を検証する。署名を検証する処理は、具体的な署名アルゴリズムに依存し、このプロトコル自体の動作および機能に関して重要ではない。OK/fail_codeフィールドで「OK」が示され、timeフィールドに正しい情報が含まれ、署名が有効と判定された場合には、この登録応答メッセージと公開鍵（PUB_IAP）が受け入れられ、そうでない場合には、登録応答メッセージが拒絶される。
【００４８】
日次買い手プロトコルは、毎日の始めに１回実行される。これによって、買い手のwalletにIAP４０からの日次証明書が供給され、前日の総差引残高が交換され、したがって、買い手１０とIAP４０が保存している取引のログを更新し、同期化することができる。日次買い手プロトコルを、以下で説明する。
【００４９】
Ｂは、まず、IAP４０に、Daily_req、balance、acct_B、timeおよびS_B(Daily_req, balance, acct_B, time)を送信する。このプロトコルは、毎日の始めに１回実行され、その目的は、IAP４０が買い手のwalletにIAP４０からの日次証明書を与える手段として働くことである。MiniPayプロトコルでは、買い手１０が毎日新しい証明書を有することが必要である。日次買い手プロトコルは、買い手１０が自分の公開鍵／秘密鍵対を変更し、新しい公開鍵PUB_Bの証明書を受け取るのに使用することもできる。その場合、IAP４０に送信される情報には、新しいPUB_Bと、新しいPUB_BがIAP４０に転送され、Bによって署名される情報に新しいPUB_Bが含まれることを示す、たとえばDaily_reqヘッダ内のフラグとが含まれる。どちらの場合でも、このプロトコル・データの署名には古い秘密鍵PRIV_Bが使用される。
１．Daily_reqは、このメッセージが日次要求メッセージであることを示すフィールドである。
２．balanceには、前日の終りの時点での買い手のwalletの差引残高が含まれる。
３．acct_Bは、Bの口座識別子である。
４．timeは、日次要求メッセージの日付と時刻を表す。
【００５０】
IAP４０は、受信したacct_Bの値を使用して、買い手１０を識別し、買い手の公開鍵PUB_Bを突き止める。その後、IAP４０は、買い手の公開検証鍵PUB_Bを、受信したDaily_req、balance、acct_Bおよびtimeの値と共に使用して、署名S_B(Daily_req, balance, acct_B, time)を検証する。署名を検証する処理は、具体的な署名アルゴリズムに依存し、このプロトコル自体の動作および機能に関して重要ではない。timeフィールドに正しい情報が含まれ、署名が有効であると判定された場合には、この日次要求メッセージが受け入れられ、IAP４０は新しい証明書を発行するが、そうでない場合には、この日次要求メッセージが拒絶される。
【００５１】
その後、IAP４０は、Bに、Daily_Certificate={Daily_res, OK/fail_code, acct_B, PUB_B, time, reco_offline_limit, total_lim, salt3, real_bal, S_IAP(Daily_res, OK/fail_code, acct_B, PUB_B, time, reco_offline_lim, H(total_lim, salt3, real_bal))}を送信する。
１．Daily_resフィールドは、このメッセージが日次応答メッセージであることを示す。
２．OK/fail_codeは、日次要求メッセージが受け入れられた（OK）か受け入れられなかった（Not OK）かを示すフィールドである。日次要求メッセージが受け入れられなかった場合には、OK/fail_codeに、失敗の理由を説明する失敗コードが格納される。
３．acct_Bは、Bの口座識別子である。
４．PUB_Bは、Bの公開検証鍵である。
５．timeは、日次応答メッセージの日付と時刻を表す。
６．reco_offline_limitには、売り手２０がオフライン限度として使用すべきであることをIAP４０が提案する、推奨オフライン限度が格納される。オフライン限度は、IAP４０からのオンライン確認が必要になる前に買い手１０が１日に購入できる最大額である。
７．total_limには、さまざまなシステム構成要素（ハードウェアおよびソフトウェア）によって課せられる、日次支出に対する総合限度が格納される。
８．salt3には、IAP４０によって生成された乱数値または擬似乱数値が格納され、推測（辞書）攻撃からtotal_limおよびreal_balを保護するのに使用される。
９．real_balには、IAP４０側の記録上の買い手１０の前日の差引残高が格納される。支払注文が失われた場合には、IAP４０の差引残高（real_bal）が買い手１０の差引残高より少なくなる場合があることに留意されたい。
【００５２】
買い手１０は、受信したtotal_lim、salt3およびreal_balの値を使用して、ハッシュ値H(total_lim, salt3, real_bal)を計算する。その後、買い手１０は、IAPの公開検証鍵PUB_IAPを、値Daily_res、OK/fail_code、acct_B、PUB_B、time、reco_offline_limおよびH(total_lim, salt3, real_bal)と共に使用して、署名S_IAP(Daily_res, OK/fail_code, acct_B, PUB_B, time, reco_offline_lim, H(total_lim, salt3, real_bal))を検証する。署名を検証する処理は、具体的な署名アルゴリズムに依存し、このプロトコル自体の動作および機能に関して重要ではない。OK/fail_codeフィールドで「OK」が示され、timeフィールドに正しい情報が含まれ、署名が有効であると判定された場合には、この日次応答メッセージが受け入れられ、証明書が受け入れられるが、そうでない場合には、この日次応答メッセージが拒絶され、証明書が拒絶される。
【００５３】
買い手１０がMiniPayプロトコルを使用することができるのは、登録および経路指定プロトコルを実行して公開鍵を登録し、日次買い手プロトコルを実行して有効な証明書を受信した後に限られる。その後、買い手１０は、新しい証明書を受信するために毎日の始めに日次買い手プロトコルを実行することによって、MiniPayプロトコルの使用を継続することができる。
【００５４】
支払注文には、日次証明書も含まれるが、この日次証明書は、IAP４０によって買い手１０に毎日与えられる。購入プロトコルを以下で説明する。
【００５５】
Bは、まず、以下の２つを売り手に送信する。
１．Daily_Certificate={Daily_res, OK/fail_code, acct_B, PUB_B, time, reco_offline_limit, total_lim, salt3, real_bal, S_IAP(Daily_res, OK/fail_code, acct_B, PUB_B, time, reco_offline_lim, H(total_lim, salt3, real_bal))}
２．Payment_Order={Order, amount, day_total, acct_B, time, URL, acct_S, S_B(Order, amount, day_total, acct_B, time, URL, acct_S)}.
【００５６】
walletは、買い手１０が購入の支払に十分な額を有する場合、すなわち、購入の額がwalletに保存されている現在の差引残高より少ない場合に限って、支払注文を送信する。
１．Daily_Certificateは、買い手１０がIAP４０から毎日受信する証明書である。
２．Orderは、このメッセージが支払注文メッセージであることを示す。
３．amountには、支払額が格納される。
４．day_totalには、この購入を含めて、その日のこの売り手２０での買い手１０による支出総額が格納される。
５．acct_Bは、Bの口座識別子である。
６．timeは、注文メッセージの日付と時刻を表す。
７．URLには、買い手１０によって購入される所望のHTMLページまたはサービスのURLが格納される。MiniPayプロトコルは、特にインターネット上で購入され、買い手１０に配布される情報の支払のための手段を提供するために設計されていることに留意されたい。
８．acct_Sは、売り手の口座識別子であり、コモン・ゲートウェイ・インターフェース（CGI）を使用して、売り手のHTTPサーバによって提供されるHTMLページから取得される。
【００５７】
売り手２０は、買い手１０がDaily_Certificateの検証に使用する手順（日次買い手プロトコルを参照されたい）と同一の手順を使用して、IAPの公開検証鍵PUB_IAPを用いてDaily_Certificateを検証する。Daily_Certificateが有効である場合には、証明書とBの公開鍵PUB_Bが受け入れられるが、そうでない場合には、証明書とBの公開鍵が拒絶される。
【００５８】
売り手２０は、Ｂの公開検証鍵PUB_Bを、値Order、amount、day_total、acct_B、time、URLおよびacct_Sと共に使用して、署名S_B(Order, amount, day_total, acct_B, time, URL, acct_S)を検証する。署名を検証する処理は、具体的な署名アルゴリズムに依存し、このプロトコル自体の動作および機能に関して重要ではない。署名が有効であると判定された場合には、次の整合性検査が実行され、そうでない場合には、この注文メッセージが拒絶される。
【００５９】
売り手２０は、ある値、たとえばamount、day_total、acct_B、timeおよびacct_Sの各フィールドに対して、整合性検査を実行することによって支払注文メッセージを検証する。署名された支払注文メッセージが有効であり、amountが所定の限度内である場合（すなわち、この日の売り手２０でのこの買い手１０の購入総額がオフライン限度より少ない場合）には、支払注文が受け入れられ、売り手２０は、要求された情報、ゲームまたはロード可能ソフトウェアの買い手１０への提供（ダウンロード）を許可するか、要求されたサービス（たとえば要求されたサイトへのアクセス）の買い手１０への提供を許可する。買い手１０の支出がこの日にこの売り手２０でオフライン限度を超えている場合には、売り手２０は、Extra-spendingプロトコルを実行して、IAP４０が取引の完了に必要な追加の額を承認するかどうかを判定し、承認された場合には売り手２０は支払注文を受け入れる。
【００６０】
MiniPay walletは、Netscapeプラグインを用いて便利に実施される（Netscapeプラグインの情報については、http://home.netscape.com/comprod/development_partners/plugin_api/index.htmlまたはオリファント（Zan Oliphant）著、「Programming Netscape Plug-Ins」、１９９６年、Sams.net刊、ISBN 1-57521-098-3またはブルーア（D. R. Brewer）著、「Netscape One Sourcebook」、米国ニューヨーク州John Wiley and Sons刊、１９９７年を参照されたい）。プラグインは、Netscape Navigatorウェブ・ブラウザの機能性を拡張することのできる、ＣまたはＣ＋＋で記述されたプログラムである。MiniPay walletプラグインは、ユーザ（買い手１０）によって導入される信頼されるコードである。MiniPay walletプラグインは、買い手の計算機または、おそらくはスマートカードに格納される、保護されたファイルへのアクセス権を有する。MiniPayのプラグイン・ソリューションは、Netscapeブラウザ（バージョン３以降）およびMicrosoft Internet Explorer（バージョン３）で良好に動作するが、本明細書に記載のソリューション方法は、Netscapeプラグインに基づく。
【００６１】
MiniPayは、ユーザが通常のブラウジング処理の一部として情報またはサービスを購入するように設計されている。ユーザは、異なる商人のための異なるハイパーリンク（URL）をクリックすることによってブラウジングし、このクリックが、ユーザのブラウザ（たとえばユーザのパーソナル・コンピュータ上で走行しているNetscapeブラウザ）による異なるHTMLページの表示をもたらす。商人のHTMLページは、通常は、提供の諸条件と共に、購入される情報またはサービスを提供する。販売される情報またはサービスは、商人のHTMLページのハイパーリンク（URL）を介して呼び出されると仮定する。MiniPayを使用する支払注文を使用可能にすることを熱望する商人（売り手２０）は、彼のHTMLページの既存のハイパーリンク（<A HREF=...>タグを介して実施される）を、適当な<EMBED>タグに置換しなければならない。すなわち、あるデータの列を、他の多少長いデータの列に置換することになる。
【００６２】
<EMBED>タグによって、次の項目が提供される。
１．ブラウザによってロードされるプラグイン（wallet）を指定する。
２．MiniPayリンク・ウィンドウのサイズを指定する。
３．MiniPayリンク・ウィンドウにプラグイン（wallet）によって表示される内容を指定する。
４．購入される項目を指すハイパーリンクを指定する。
５．購入される項目を指すハイパーリンクのコスト（たとえばセント単位）を指定する。
６．売り手２０の識別子（acct_S）を指定する。
７．売り手２０でのMiniPayのためのコモン・ゲートウェイ・インターフェース（CGI）の識別子を指定する。
８．MiniPayの導入に関する手順を含むページ（MiniPayプラグインが導入されていない場合にブラウザによって自動的に呼び出される）を指定する。
【００６３】
表示されるHTMLページのプラグイン内容は、内容を表示するために、特定のプラグインによってサポートされなければならないMultipurpose Internet Mail Extensions（MIME）ファイル・タイプを参照する。Netscape Navigator（ブラウザ）または互換ブラウザが、<EMBED>タグに遭遇した時には、そのブラウザは、その<EMBED>タグに対応する内容を表示するのに必要なプラグインが導入されていることを検証する。そうである場合には、ブラウザは、そのプラグインを呼び出して、EMBEDタグに対応するMIME内容を表示する。そうでない場合には、Netscape Navigator（ブラウザ）は、ポップアップ・ウィンドウを開き、ユーザが必要なプラグインをダウンロードし、導入できるようにする。一旦プラグインを導入したならば、毎回ダウンロードすることなくそのプラグインを繰り返し再利用することができる。
【００６４】
<EMBED>タグに含まれる情報を使用して、MiniPayプラグインは、ユーザがMiniPay支払注文を開始できるようにするのに必要なすべての情報を含むポップアップ・ウィンドウを表示する。このステップの理解は、本発明にとって重要ではない。
【００６５】
一般に、プラグインの長所は、HTMLページを設計する当事者が、プラグインを設計する必要がないことである。第三者によって設計されたプラグインは、他者によって設計されたHTMLページに簡単に統合することができる。その結果、各商人は、独自のMiniPay walletプラグインを設計し、提供する必要がなくなる。その代わりに、各商人は、自分のHTMLページに<EMBED>タグを設けることができ、このタグが、単一の第三者によって設計され、供給されるMiniPay walletプラグインを呼び出す。Netscapeは、使用可能なサードパーティ・プラグインの完全な登録簿を有する。これによって、商人がMiniPayを実施し、買い手にMiniPay機能を提供することが便利になる。
【００６６】
本発明では、上で説明した現在のMiniPayアーキテクチャが拡張され、変更されることを予期している。本発明の１実施例では、次の形でMiniPayアーキテクチャが拡張され、変更される。
１．評価者（下で説明する）がアーキテクチャ・モデルに追加される。
２．買い手が評価者から製品評価情報（調査結果）を受信することができるようにするために、買い手と評価者の間に新しいプロトコル・フローが追加される。
３．買い手が調査質問表に含まれる製品に関する質問に答える、すなわち、製品調査を受けることができるようにするために、買い手と評価者の間に新しいプロトコル・フローが追加される。
４．評価者が受信する完成した調査質問表が、調査質問表で評価される製品を購入した買い手から実際に来たものであることを評価者が検証できるようにするために、評価者とIAPの間に新しいプロトコル・フローが追加される。
５．MiniPay購入プロトコルの支払注文メッセージを変更して、いくつかの追加のデータ要素を含め、その結果、IAPが、IAPと評価者の間のプロトコル・フローが必要とする必要な情報を有するようにする。
【００６７】
買い手の署名鍵PRIV_Bを、MiniPay支払に直接には関係しない情報に署名するのに使用できるようにすることに、IAPが同意することも必要である。しかし、共通の統合化されたアーキテクチャ・モデルを使用することによって当事者が当事者個々の必要条件を解決する場合には、より単純な全体設計が可能である。
【００６８】
上で述べたように、従来のMiniPayシステムでは、IAPが、メッセージに署名するのに使用される公開鍵／秘密鍵対（PUB_IAP、PRIV_IAP）を有する。拡張MiniPayシステムでは、IAPは、鍵の暗号化に使用される公開鍵／秘密鍵対（PUB_IAP、PRIV_IAP）も有する。通常、鍵の暗号化に使用される鍵対は、署名に使用される鍵対とは異なるはずである。しかし、本発明は、この形に制限されるものではない。IAPは、署名と鍵の暗号化の両方に使用される１対の鍵を有することができ、また、署名用と鍵の暗号化用の２つの異なる鍵の対を有することもできる。鍵暗号化鍵対によって、評価者は、保護される情報が対称鍵（たとえばDES鍵）を用いて暗号化され、その対称鍵がIAPの公開鍵を用いて暗号化される、ハイブリッド暗号システムを使用することができるようになる。鍵暗号化公開鍵（PUB_IAP）は、証明機関によって署名された証明書に格納され、この証明書は、MiniPayまたは拡張MiniPayの一部ではない別のプロトコルを使用して評価者に送信される。評価者は、彼のシステムで初期設定された証明機関の公開鍵を有し、この鍵は、公開鍵PUB_IAPを含む証明書の検証に使用されると仮定する。
【００６９】
拡張MiniPayシステムでは、評価者は、鍵暗号化に使用される公開鍵／秘密鍵対（PUB_E、PRIV_E）を有する。この鍵対によって、買い手は、保護される情報が対称鍵（たとえばDES鍵）を用いて暗号化され、その対称鍵が評価者の公開鍵を用いて暗号化される、ハイブリッド暗号システムを使用することができるようになる。鍵暗号化公開鍵（PUB_E）は、証明機関によって署名された証明書に格納され、この証明書は、買い手によって要求された調査質問表と共に送信される。買い手は、彼のシステムで初期設定される証明機関の公開鍵を有し、この鍵は、公開鍵PUB_Eを含む証明書の検証に使用されると仮定する。
【００７０】
図２は、本発明に従って変更された、拡張MiniPayシステムを示すブロック図である。図２には、通常のMiniPayシステムの４つの構成要素（買い手１０、売り手２０、ISP３０およびIAP４０）と、１つの新しい構成要素（評価者５０）が含まれる。評価者５０は、調査データを収集し、配布する。購入を行う前に、買い手１０は、異なる製品の調査結果を受信することができる。また、製品を購入した後に、買い手１０は、調査を受けることができ、したがって、買い手は評価者５０に調査入力を提供することができる。
【００７１】
図３は、本発明を実施できる代表的なクライアント・サーバ・ネットワーク環境を示す図である。図３の環境には、以下の構成要素が含まれる。
１．買い手１０と表される、インターネットを介して情報またはサービスを購入するユーザ。
２．売り手２０と表される、販売のためにオンライン情報またはオンライン・サービスを提供する商人。
３．ISP３０と表される、通常は銀行またはインターネット・サービス・プロバイダ（ISP）である、売り手の支払請求システム。
４．IAP４０と表される、通常はインターネット・アクセス・プロバイダ（IAP）または電話会社（Telco、PTT）または金融処理業者（financial processor）である、買い手の支払請求システム。
５．評価者５０と表される、製品調査情報を収集し、調査結果をユーザ（または買い手）に配布する、サービス提供者。
【００７２】
好ましい実施例では、図３の構成要素は、インターネットに接続され、標準インターネット通信プロトコルを使用して通信することができる。図３の構成要素は、次の形で対話する。
【００７３】
ステップ６０で、買い手１０は、売り手２０に１つまたは複数のHTMLページを要求する。HTMLページには、販売のために提供される１つまたは複数の製品のリストが含まれる。各製品は、買い手１０がその製品（情報またはサービス）にアクセスするかこれを取得できるようにする、関連URLまたはハイパーリンクを有する。ステップ６１で、買い手１０は、要求したHTMLページを売り手２０から受信する。ステップ６２で、買い手１０は、評価者５０に１つまたは複数のHTMLページを要求する。このHTMLページには、１つまたは複数の製品の製品評価情報が含まれる。この製品評価情報は、評価者５０に送信された製品調査情報から導出される。ステップ６３で、買い手１０は、要求したHTMLページを評価者５０から受信する。
【００７４】
ステップ６４で、買い手１０は、売り手２０に支払注文メッセージを送信して、製品またはサービスを購入する。製品またはサービスは、売り手のHTMLページの１つの特定のURLによって識別される。ステップ６５で、買い手１０は、購入したHTMLページを売り手２０から受信する。
【００７５】
ステップ６６で、買い手１０は、買い手１０がオンラインで購入し、アクセスし、閲覧または使用した製品に関する意見を表すことができるように、評価者５０に製品調査質問表を要求する。買い手１０が後に使用するために購入した情報を自分のシステムにダウンロードした情況では、買い手１０は、売り手のHTMLページからリンクを介してオンラインで調査を受ける機会を有しないはずであることに留意されたい。その場合、買い手１０は、後程調査を受ける必要がある。ステップ６７で、買い手１０は、要求した製品調査質問表を受信する。
【００７６】
ステップ６８で、買い手１０は、完成した製品調査質問表を評価者５０に送信する。
【００７７】
ステップ６９で、売り手２０は、すべての買い手から受信した集計された支払注文をISP３０に送信する。ステップ７０で、ISP３０は、その売り手のすべてからの集計された支払注文を、適当な対応するIAP４０に送信する。
【００７８】
ステップ７２で、評価者５０は、ステップ６８で買い手１０から受信した完成した調査質問表が、完成した調査質問表で識別される製品を実際に購入した買い手によって提出されたことの証拠をIAP４０に要求する。ステップ７４で、評価者５０は、ステップ６８で評価者５０に完成した質問調査表を送信した買い手１０が、実際に、完成した質問調査表で識別される製品を購入した正当な買い手１０であることの証拠をIAP４０から受信する。
【００７９】
ステップ６０、６１、６５、６９および７０は、MiniPayアーキテクチャに存在するステップであり、ステップ６４は、MiniPayアーキテクチャから変更されたステップである。これらのステップは上で説明した。ステップ６２、６３、６６、６７、６８、７２および７４は、MiniPayプロトコルに追加された新規のステップであり、本発明の主題である。ステップ６２および６３は、評価者５０が、製品評価情報または調査結果を買い手に配布できるようにするステップである。ステップ６６、６７、６８、７２および７４は、評価者５０が、製品調査質問表を受信し、買い手から受信した製品調査質問表を検証できるようにするステップである。
【００８０】
図４は、変更されたMiniPay購入プロトコルを示すブロック図である。ステップ６４で、買い手１０は、Daily_Certificate７５と表される、買い手の日次証明書のコピーと、MPay_Order７６と表される支払注文を売り手２０に送信する。MPay_Order７６は、OldDataと、NewDataと、買い手の署名鍵PRIV_Bを使用してOldDataおよびNewDataの連結に対して計算される署名とからなる。OldDataは、上で説明した未変更のMiniPayプロトコルで通常の支払注文で送信されるデータを表す。OldDataには、データ要素Order、amount、day_total、acct_B、time、URLおよびacct_Sが含まれる（上を参照されたい）。NewDataは、変更された支払注文で送信される新規データを表し、以下のデータ要素からなる。
１．評価者５０が受信した完成した調査質問表が、完成した調査質問表で識別される製品を購入した買い手１０によって提出されたことを検証するためにIAP４０が使用する、Auth_Bと表される認証コード。
２．ID_Productと表される、購入された製品の名前または識別子。
【００８１】
受信時に、売り手２０は、買い手１０がDaily_Certificateの検証に使用した手順と同一の手順（日次買い手プロトコルを参照されたい）を使用して、IAPの公開検証鍵PUB_IAPを用いてDaily_Certificate７５を検証する。Daily_Certificateが有効である場合には、この証明書とBの公開鍵PUB_Bが受け入れられ、そうでない場合には、証明書とBの公開鍵が拒絶される。
【００８２】
その後、売り手２０は、
１．OldData={Order, amount, day_total, acct_B, time, URL, acct_S}
２．NewData={Auth_B, ID_Product}
という２つの値と共にBの公開検証鍵PUB_Bを使用して、署名S_B(OldData, NewData)を検証する。署名を検証する処理は、具体的な署名アルゴリズムに依存し、このプロトコル自体の動作および機能に関して重要ではない。署名が有効であると判定された場合、上の購入プロトコルで説明したように、OldDataに対して次の整合性検査が実行され、そうでない場合には、支払注文メッセージが拒絶される。
【００８３】
図５は、買い手１０が完成した調査質問表を評価者５０に送信できるようにする、調査プロトコルを示すブロック図である。ステップ６８で、買い手１０は、以下の４つのデータ要素を評価者５０に送信する。
１．評価者５０の公開鍵（PUB_E）を用いて暗号化されたデータ要素からなる暗号化された鍵ブロックPUB_E(Survey1, K1, K2, Rcode_B)７８。PUB_E(Survey1, K1, K2, Rcode_B)７８のデータ要素は次の通りである。
ａ．Survey1 この鍵ブロックが調査鍵ブロックであることを示すヘッダ。
ｂ．K1 ハッシュ・アルゴリズムを用いて計算されるメッセージ認証コード（MAC）であるHMAC（ベラーレ（M. Bellare）他著、「Keying Hash Functions for Message Authentication」、Advances in Cryptology - Crypto 96 Proceedings、Lecture Notes in Computer Science Vol. 1109、コブリッツ（N. Koblitz）編集、Springer-Verlag刊、１９９６年を参照されたい）を計算するのに使用される秘密鍵。
ｃ．K2 対称鍵暗号アルゴリズムを用いる暗号化に使用される秘密鍵。
ｄ．Rcode_B 買い手のシステムによってランダムに生成される秘密の符号語。
２．以下の要素を含むDataElements８０。
ａ．ID_IAP IAP４０の識別子。
ｂ．acct_B 買い手（B）の口座識別子。
ｃ．ID_Product 購入された製品の名前または識別子。
ｄ．Time ステップ６４で買い手１０が送信した支払注文に現れる日付と時刻。
３．ハッシュ・アルゴリズムと秘密鍵K1を使用して、すなわち、HMACアルゴリズムと鍵K1を使用して、survey_questionnaire_responses（調査質問表応答）に対して計算されるメッセージ認証コードを表すHMAC(K1,survey_questionnaire_responses)８２。HMACは、この応答が実際に買い手１０から発したものであり、変更されていないことを評価者５０に保証する保全性値として機能する。その代わりに、ディジタル署名などの他の手段を使用して、下で説明するように保全性値を生成することができる。
４．対称鍵暗号アルゴリズムを使用し、K2を用いて暗号化されたsurvey_questionnaire_responsesを表すK2(survey_questionnaire_responses)８４。
【００８４】
K2は、survey_questionnaire_responsesの暗号化に使用される。survey_questionnaire_responsesを暗号化することによって、買い手１０が自分の応答を秘密に保つことが可能になる。この暗号化ステップは、任意選択であり、買い手１０または評価者５０が応答をプライベートに保つことを明示的に希望する情況でのみ使用されるはずである。
【００８５】
K1は、survey_questionnaire_responsesに対するメッセージ認証コードを計算するのに使用される。HMACは、メッセージ認証コードの１種であるが、HMACはすばやく計算でき、高いセキュリティをもたらすので、これが好ましい。
【００８６】
この鍵ブロックは、２つの鍵K1およびK2の秘密性を保護し、ランダムに生成される符号語Rcode_Bの秘密性を保護するために暗号化される。Rcode_Bは、評価者５０が偽のsurvey_questionnaire_responsesを受け入れないようにするために秘密に保たれる。Rcode_Bは、調査プロトコル・メッセージ（図５）を検証するために使用可能な、評価者５０が有する唯一の値である。
【００８７】
図６は、調査調停プロトコルを示すブロック図である。この調査調停プロトコルによって、評価者５０は、受信した完成した調査質問表が、その完成した調査質問表で識別される製品を購入した買い手から実際に来たことを検証できる。
【００８８】
図６のステップ７２で、評価者５０は、以下のデータ要素からなるバッチ化された要求をIAP４０に送信する。
１．その要求を作成した評価者５０をIAP４０に知らせるための、評価者の識別子ID_Evaluator８５。
２．以下の要素からなる暗号化された鍵ブロックPUB_IAP(Survey2, K3, K4)８６。
ｉ．Survey2 この鍵ブロックが調査鍵ブロックであることを示すヘッダ。
ｉｉ．K3 対称鍵暗号アルゴリズムを用いる暗号化に使用される秘密鍵。
ｉｉｉ．K4 ハッシュ・アルゴリズムを用いて計算されるメッセージ認証コード（MAC）であるHMACの計算に使用される秘密鍵。
３．n項目のリスト{P1, P2, ..., Pn}からなるListOfClaimedPurchases８８。このリストの各項目Pには、以下のデータ要素が含まれる。
ｉ．acct_B 調査プロトコル（ステップ６６）で買い手１０から受信したacct_Bの値。
ｉｉ．ID_Product 調査プロトコル（ステップ６６）で買い手１０から受信したID_Productの値。
ｉｉｉ．time 調査プロトコル（ステップ６６）で買い手１０から受信したtimeの値。
ｉｖ．K3(Rcode_B) 調査プロトコル（ステップ６６）で買い手１０から受信した、鍵K3を用いて暗号化されたRcode_Bの値。
４．秘密鍵K4を使用して、完成したListOfClaimedPurchasesに対して計算されたHMAC(K4, ListOfClaimedPurchases)９０。
【００８９】
図６のステップ７４で、IAP４０は、以下のデータ要素からなるバッチ化された応答を評価者５０に送信する。
１．この応答を作成したIAP４０を評価者５０に知らせるための、IAP４０の識別子、ID_IAP９１。
２．n項目のリスト{R1, R2, ..., Rn}からなるResponseList９２。ここで、Rのそれぞれには、以下のデータ要素が含まれる。
ｉ．P={acct_B, ID_Product, time, K3(Rcode_B)}。IAP４０は、評価者５０から受信したPの値をエコー・バックする。
ｉｉ．OK/fail_code。ここで、OKは、acct_Bを有する買い手１０が、データ要素「time」で指定された日時にID_Productによって名前または識別子が与えられる製品を購入したことを示し、fail_codeは、買い手１０が指定された日時にその製品を購入したことをIAP４０が検証できなかったことを、失敗の説明と共に示す失敗コードである。
３．IAPの私有署名鍵PRIV_IAPを使用してデータ・ブロック(Survey3, ResponseList)に対して生成された署名、S_IAP(Survey3, ResponseList)９４。Survey3は、このデータ・ブロックが調査署名ブロックであることを示すヘッダである。
【００９０】
図３で説明した構成要素のネットワークでは、買い手１０がクライアントであり、売り手２０および評価者５０がサーバである。
【００９１】
図７は、インターネット１００に接続された買い手のシステム１０２を示すブロック図である。買い手のシステム１０２は、Netscape Navigatorブラウザなどのブラウザ１０４、調査プラグイン１０６およびMiniPay Walletプラグイン１０８からなる。
【００９２】
ブラウザ１０４は、ワールド・ワイド・ウェブまたはインターネットへのアクセスに使用される。ブラウザ１０４は、売り手のサーバまたは評価者のサーバのHTMLページまたはHTML文書にアクセスするのに使用される。ブラウザ１０４は、売り手のサーバまたは評価者のサーバとの対話にも使用される。
【００９３】
Universal Resource Locator（URL）と称する、インターネット上の情報へのポインタを与えられたブラウザは、その情報にアクセスするか、URLの内容に基づく形で動作する。ハイパーテキスト・ウェブ文書の場合、ブラウザは、HTTPプロトコルを使用してサーバと通信する。ブラウザがウェブからロードするページのそれぞれは、単独の文書である。この文書は、ハイパーテキスト・マークアップ言語（HTML）と称する言語で記述される。各HTMLページには、文書のテキスト、その構造、他の文書へのリンク、画像および他の媒体が含まれる。多数の異なるブラウザが入手可能であるが、最も人気があり広く使用されているブラウザの１つが、Netscape Navigatorブラウザである。
【００９４】
MiniPay Walletプラグイン１０８は、買い手のMiniPayシステムに要求されるいくつかの処理ステップを実行する。MiniPay Walletプラグイン１０８は、上で説明したMiniPay Walletプラグインを変更した版であり、本明細書に記載の変更された支払注文メッセージを準備するための余分な処理ステップを実行することができる。
【００９５】
調査プラグイン１０６は、本明細書に記載の調査システムの調査プロトコルを実施するのに必要な処理ステップを実行する。調査プラグイン１０６は、買い手のシステムが、完成した調査質問表を準備し、評価者５０に提出できるようにする。
【００９６】
MiniPay Walletプラグイン１０８と同様に、調査プラグイン１０６は、ユーザ（買い手１０）によって導入される、信頼されるコードである。また、MiniPay Walletプラグイン１０８と同様に、調査プラグイン１０６は、買い手の計算機またはおそらくはスマートカードに格納された、保護されたファイルへのアクセス権を有する。このプラグインの機構は、上で詳細に説明した。
【００９７】
MiniPayシステムと同様に、調査システムは、<EMBED>タグを利用する。この場合、商人は、買い手１０によって購入されるHTMLページのうちの１つ、好ましくは、買い手１０が、URLによってアドレス指定される購入される製品に関する表示または作業を完了した後に、見られ、簡単に認識される便利な場所にあるHTMLページに、調査システムの<EMBED>タグを置かなければならない。
【００９８】
この<EMBED>タグは、以下を提供する。
１．ブラウザがロードしなければならないプラグイン（調査プラグイン）を指定する。
２．調査リンク・ウィンドウのサイズを指定する。
３．調査リンク・ウィンドウ内にプラグイン（調査プラグイン）によって表示される内容を指定する。
４．調査質問表を指すハイパーリンクを指定する。
５．評価者５０の識別子（ID_Evaluator）を指定する。
６．評価者５０の調査システムのためのコモン・ゲートウェイ・インターフェース（CGI）スクリプトの識別子を指定する。
７．調査システムの導入に関する手順を含むページ（調査システム・プラグインが導入されていない場合にブラウザによって自動的に呼び出される）を指定する。
【００９９】
<EMBED>タグの使用法と機能は、上で詳細に説明した。
【０１００】
図８は、通常のインターネット・サーバ・システム１１０を示すブロック図であり、売り手のシステムと評価者のシステムを表す図である。インターネット・サーバ・システム１１０は、インターネット１００に接続されたウェブ・サーバ１１２からなり、ウェブ・サーバ１１２は、１つまたは複数のスクリプト１１４を呼び出すことができ、スクリプト１１４は、１つまたは複数の他のプログラム１１６を呼び出すことができる。
【０１０１】
ユーザが自分のブラウザでウェブ文書をポイントした時には、必ず、ブラウザがサーバと通信して、その文書を取得する。ウェブ・サーバは、HTTPプロトコルを使用して、ブラウザからのファイルの要求を聴取する。その後、ウェブ・サーバは、そのファイルと、そのファイルが参照する、それに含まれるすべての画像を配布する。ウェブ・サーバは、ブラウザから送り返されたコマンドを処理することもできる。
【０１０２】
ウェブ・サーバ１１２は、ブラウザからのURL要求を処理するプログラムである。要求されたURLのそれぞれが、スクリプト１１４を指す。各スクリプト１１４は、インターネット・サーバ・システム１１０上で走行するウェブ・サーバ１１２によって呼び出されるプログラムである。スクリプト１１４は、他のプログラム１１６を呼び出すこともできる。ひとまとめにすると、ウェブ・サーバ１１２、スクリプト１１４および他のプログラム１１６は、変更されたMiniPayシステムの売り手の部分および調査システムの評価者の部分によって要求される必要な計算ステップを実行することのできる、強力な組み合わせである。
【０１０３】
図９は、買い手１０によって実行される処理ステップの流れ図である。ステップ６０で、買い手のブラウザが、売り手２０にHTMLページのURLを要求する。ステップ６１で、買い手のブラウザが、売り手２０からHTMLページを受信する。
【０１０４】
ステップ２０２で、買い手のブラウザは、売り手２０から受信したHTMLページを表示し、買い手１０が購入を望む可能性がある、興味のある製品を見つける。このHTMLページには、製品の名前、製品の説明、MiniPay支払注文を開始するために買い手１０が「ポイント・アンド・クリック」することのできるMiniPayリンク（またはURL）が含まれる。このHTMLページには、興味のある製品に関する製品評価情報を得るために買い手１０が「ポイント・アンド・クリック」することのできるハイパーリンク（またはURL）も含まれる。
【０１０５】
ステップ２０４で、買い手１０は、興味のある製品の製品評価情報を得るために、ハイパーリンクをポイント・アンド・クリックする。ステップ６２で、買い手のブラウザは、評価者５０にHTMLページのURLを要求する、すなわち、買い手１０は、評価者のハイパーリンクをクリックすることによって、興味のある製品の調査結果を要求する。ステップ６３で、買い手のブラウザが、評価者５０からHTMLページを受信する。ステップ２０５で、買い手のブラウザが、評価者５０から受信したHTMLページを表示する。買い手１０は、その製品を購入するか否かを決定する際に、この製品評価情報を使用する。本発明の目的のために、買い手１０はその製品を購入することを決定すると仮定する。
【０１０６】
ステップ２０６で、買い手１０は、興味のある製品のMiniPayリンクをポイント・アンド・クリックし、これによって、MiniPayシステム・プロトコルが開始される。ステップ２０８で、買い手のシステムは、支払注文を用意する（図１３を参照されたい）。ステップ６４で、買い手のブラウザが、売り手２０に、購入するHTMLページを要求する。これには支払注文が含まれる。ステップ６５で、買い手のブラウザが、購入したHTMLページを売り手２０から受信する。
【０１０７】
ステップ２１０で、買い手のブラウザが、売り手２０から受信した購入したHTMLページを表示する。買い手１０が最初のHTMLページを受信すると、そのページに、他のHTMLページへの「フリー」ハイパーリンクが含まれる可能性がある。買い手１０は、購入契約の諸条件に従って、望む限りいつまでも、または、所定の時間制現に達するまで、購入したHTMLページの表示を継続することができる。購入されたHTMLページには、購入した製品に関する調査質問表に買い手１０が書き込めるようにするための調査リンクも含まれる。調査質問表の提出は任意選択であるが、本発明を説明する目的のために、買い手１０は調査質問表を提出することを決定したと仮定する。
【０１０８】
ステップ２１２で、買い手１０は、購入したHTMLページの調査リンクをポイント・アンド・クリックする。ステップ６６で、買い手のブラウザが、評価者５０に、調査質問表を含むHTMLページを要求する。ステップ６７で、買い手のブラウザが、評価者５０からの調査質問表と評価者の公開鍵PUB_Eを含む署名された証明書とを含むHTMLページを受信する。
【０１０９】
ステップ２１３で、買い手のシステムは、評価者の公開鍵PUB_Eを含む証明書を検証する。この証明書は、証明センターの公開鍵を用いて署名され、証明センターの公開鍵は、以前に買い手のwalletに格納されていると仮定する。署名を検証する処理は、具体的な署名アルゴリズムに依存し、公開鍵PUB_Eを使用するプロトコルの動作および機能に関して重要ではない。受信され、検証された公開鍵PUB_Eは、買い手のwalletに格納される。
【０１１０】
ステップ２１４で、買い手のブラウザは、評価者５０から受信したHTMLページを表示する。買い手１０は、調査質問表の質問に答え、調査を完了したことを示す。ステップ２１６で、買い手のシステムは、調査応答を用意する（図１４を参照されたい）。ステップ６８で、買い手のブラウザが、調査質問表に対する回答を含む調査応答を評価者５０に送信する。
【０１１１】
図１３は、図９のステップ２０８に関連する処理ステップの流れ図である。ステップ２２０で、買い手１０が、通常のMiniPayシステム動作（上で説明した）の一部として以前に受信され、買い手のwalletに格納された、daily_certificate、amount、day_totalおよびacct_BをMiniPay Walletプラグイン１０８から取得する。ステップ２２２で、買い手１０が、買い手のシステムの時刻機構から時刻を読み取る。これは、通常のMiniPayシステム動作の下で実行されるステップでもある。ステップ２２４で、買い手１０が、売り手のHTMLページの<EMBED>タグから、購入するHTMLページのURL、acct_SおよびID_Productを取得する。ID_Productは、MiniPayアーキテクチャではまだ定義されていないことに留意されたい。したがって、売り手のHTMLページのデータからID_Productを導出または取得できない場合には、ID_Productを売り手のHTMLページの<EMBED>タグに追加する必要がある。
【０１１２】
ステップ２２６で、買い手１０が、Rcode_Bをランダムに生成し、後に使用するためにwalletにRcode_Bを格納し、Rcode_Bおよび他のデータから認証コードAuth_Bを生成する。Auth_Bは秘密でない値であるが、Rcode_Bは秘密の値である。Rcode_Bおよび他のデータから認証コードAuth_Bを計算する方法は、下で完全に説明する。
【０１１３】
ステップ２２８で、パラメータ値「Order」、amount、day_total、acct_B、time、URLおよびacct_Sを連結することによって値OldDataを作成する。ステップ２３０で、パラメータ値Auth_BとID_Productを連結することによって値NewDataを作成する。ステップ２３２で、買い手の私有署名鍵PRIV_Bを用いてOldDataとNewDataの値に署名する。当技術分野で周知の動作である署名の処理は、具体的な署名アルゴリズムに依存し、本発明の動作および機能に関して重要ではない。
【０１１４】
ステップ２３４で、買い手１０が、その買い手１０に関するIAP４０の識別子であるID_IAPの値を取得する。ID_IAPは、買い手のwallet内で以前に初期設定された値である。ステップ２３６で、買い手１０が、値ID_IAP（ステップ２３４）、acct_B（ステップ２２０）、ID_Product（ステップ２２４）およびtime（ステップ２２２）を含むDataElements８０を作成し、DataElementsを買い手のwalletに格納する。
【０１１５】
図１４は、図９のステップ２１６に関連する処理ステップの流れ図である。ステップ２５０で、買い手１０が、前に格納された（図９のステップ２１３）公開鍵PUB_Eを買い手のwalletから取得する。ステップ２５２で、買い手１０が、鍵K1およびK2をランダムに生成する。ステップ２５４で、買い手１０が、前に図１３のステップ２２６で生成され、買い手のwalletに格納されたRcode_Bの値を取得する。ステップ２５６で、買い手１０が、公開鍵PUB_Eを用いてヘッダ「Survey1」、K1、K2およびRcode_Bを暗号化して、暗号化された値PUB_E(Survey1, K1, K2, Rcode_B)７８を作る。
【０１１６】
ステップ２５８で、買い手１０が、前に図１３のステップ２３６で作成され、買い手のwalletに格納されたDataElements８０={ID_IAP, acct_B, ID_Product, time}８０を買い手のwalletから取得する。ステップ２６０で、買い手１０が、HMACアルゴリズムと鍵K1を使用して、図９のステップ２１４で作った調査質問表応答に対するメッセージ認証コードHMAC(K1,survey_questionnaire_responses)８２を作成する。ステップ２６２で、買い手１０が、鍵K2を使用して調査質問表応答を暗号化して、暗号化された値K2(survey_questionnaire_responses)８４を作る。
【０１１７】
図１０は、売り手２０によって実行される処理ステップの流れ図である。ステップ６０で、売り手のサーバが、販売のために提供される売り手の製品を記述したHTMLページのURL要求を受信する。このHTMLページでは、各製品が関連するMiniPayリンクを有する。ステップ６１で、売り手のサーバが、要求されたHTMLページを買い手のブラウザに渡す。ステップ６４で、売り手のサーバが、支払注文と共に、購入されるHTMLページに関するURL要求を買い手１０から受信する。
【０１１８】
ステップ３０２で、売り手のシステムが、支払注文を検証し、処理する。変更されたMiniPayシステムでの変更された支払注文の検証と処理に用いられるステップは、基本的には上で説明した（未変更の）MiniPayシステムでの支払注文の検証と処理に用いられるステップと同一であるが、売り手のシステムが、OldDataだけではなくOldDataとNewDataからなるデータ（OldDataに含まれるデータの拡張とみなすこともできる）を処理しなければならず、売り手のシステムが、NewDataに含まれるID_ProductがOldDataのURLと一致する、すなわち、それぞれが同一の製品を指定していることも検証しなければならない点が異なる。
【０１１９】
ステップ６５で、売り手のサーバが、購入されたHTMLページを買い手のブラウザに渡す。
【０１２０】
図１１は、IAP４０によって実行される処理ステップの流れ図である。ステップ７２で、IAPのシステムが、評価者５０から購入証明書要求メッセージを受信する。評価者５０は、この購入証明書要求メッセージによって、それ含まれるリストの買い手が、購入したと主張する製品を実際に購入したことの検証を要求している。
【０１２１】
ステップ４０２で、IAPのシステムが、評価者５０から受信した入力を処理する（図１７を参照されたい）。この処理ステップによって失敗コードが返された場合には、この購入証明書要求が拒絶されたことを示す応答メッセージを評価者５０に送信する。そうでない場合には、処理はステップ４０４に進む。
【０１２２】
ステップ４０４で、IAPのシステムが、評価者５０への応答を用意する（図１８を参照されたい）。
【０１２３】
ステップ７４で、IAPのシステムが、評価者５０から受信した買い手のリストのうちで、購入したと主張する製品を実際に購入した買い手を示す購入証明書応答メッセージを評価者５０に送信する。
【０１２４】
図１７は、図１１のステップ４０２に関連する処理ステップの流れ図である。ステップ４２０で、IAP４０が、前に生成され、IAPのシステムに格納されたIAP４０の秘密鍵PRIV_IAPを取得する。ステップ４２２で、IAP４０が、鍵PRIV_IAPを用いて、受信したPUB_IAP(Survey2, K3, K4)８６の値を非暗号化して、Survey2、K3およびK4の値を回復する。ステップ４２４で、IAP４０は、ヘッダが「Survey2」であり、これが評価者５０からの有効な鍵調査鍵レコードであることが示されることを検証する。ヘッダが正しい場合には、IAP４０は処理を継続し、そうでない場合には停止する。ステップ４２６で、IAP４０は、HMACアルゴリズムと鍵K4を使用して、受信したListOfClaimedPurchases８８に対するメッセージ認証コードを計算する。ステップ４２８で、IAP４０は、等しいかどうかについて、計算したメッセージ認証コードと受信したHMAC(K4, ListOfClaimedPurchases)９０の値を比較する。これらの値が等しい場合には、IAP４０はOKを返す。そうでない場合には、適当なfail_codeを返す。
【０１２５】
図１８は、図１１のステップ４０４に関連する処理ステップの流れ図である。IAP４０は、さまざまなISPからバッチ化された日次供託を受信し、これらのISPは、さまざまな売り手からバッチ化された日次供託を受信すると仮定することに留意されたい。さらに、日次供託は、支払注文または同等もしくは類似の情報を含むデータ・レコードからなると仮定する。さらに、特定のIAP４０で買い手１０によって開始される支払注文のすべてについて、IAP４０が、少なくとも図１１のステップ４０４に関連する処理ステップを実行するのに十分な情報を受信し、記憶（定義済みの期間にわたって）すると仮定する。具体的に言うと、支払注文のそれぞれに対応する記憶された情報には、少なくとも、データ要素acct_B、ID_Product、timeおよびAuth_Bが含まれると仮定する。
【０１２６】
ステップ４４０で、IAP４０が、受信した鍵K3を取得する。ステップ４４２で、受信したListOfClaimedPurchases８８={P1, P2, ..., Pn}のP={acct_B, ID_Product, time, K3(Rcode_B)}のそれぞれについて、IAP４０が、暗号化された値K3(Rcode_B)を非暗号化して、平文値Rcode_Bを回復する。
【０１２７】
ステップ４４４で、受信したListOfClaimedPurchases８８={P1, P2, ..., Pn}のP={acct_B, ID_Product, time, K3(Rcode_B)}のそれぞれについて、IAP４０は、対応する値R={P, OK/fail_code}を作成し、そのようにして作成されたRの値を集めて、ResponseList９２={R1, R2, ..., Rn}を形成する。ここで、そのようにして作成されたRの値のそれぞれのOK/Fail_codeには、関連するRcode_Bが有効であるか否かに応じて「OK」またはfail_codeが格納される。Rcode_Bは、次の形でAuth_Bの対応する値に対して検証される。Pの値のそれぞれについて、パラメータacct_B、ID_Productおよびtimeを使用して、前記パラメータに対応する、前にIAPのシステムに格納された支払注文または同等のレコードを突き止める（上の注記を参照されたい）。パラメータacct_B、ID_Productおよびtimeは、支払注文レコードを一意に識別し、したがって、やはり同一の支払注文レコードに格納されるAuth_Bの値を一意に識別する。Rcode_Bの所与の値とそれに対応するAuth_Bの値について、Rcode_Bを検証する処理には、以下のステップが含まれる。
１．Rcode_Bと（おそらくは）他のデータ（other_data）に対して、関数ｆを使用して値f(Rcode_B, other_data)を計算する。
２．計算されたf(Rcode_B, other_data)の値がAuth_Bと等しい場合には、Rcode_Bが有効であり、そうでない場合には、Rcode_Bは無効である。
【０１２８】
当業者は、f(Rcode_B, other_data)の計算に使用することのできる関数fが多数存在し、おそらく多数の異なる種類のother_dataをこの計算に使用することができることを諒解するであろう。本発明では、f(Rcode_B, other_data)を計算する方法の１つを説明するが、当業者であれば、本発明がこの１つの方法に制限も束縛もされないことを諒解するであろう。
【０１２９】
ステップ４４６で、IAP４０は、署名に使用する秘密鍵PRIV_IAPを取得する。IAP４０は、署名用の１対の鍵と鍵暗号化用のもう１対の鍵を有するが、これらの鍵は、本発明では別々の対としてインデクシングされず、区別もされないことに留意されたい。ステップ４４８で、IAP４０は、ヘッダ「Survey3」とResponseList９２を含む署名レコードを形成し、秘密鍵PRIV_IAPを用いてこの署名レコードに署名して、署名S_IAP(Survey3, ResponseList)９４を作る。
【０１３０】
図１２は、評価者５０によって実行される処理ステップの流れ図である。ステップ６２で、評価者のサーバが、特定の製品の調査結果を含むHTMLページに関するURL要求を受信する。ステップ６３で、評価者のサーバが、要求されたHTMLページを買い手のブラウザに渡す。
【０１３１】
ステップ６６で、評価者のサーバが、調査質問表を含むHTMLページに関するURL要求を受信する。ステップ６７で、評価者のサーバが、評価者５０の公開鍵PUB_Eを含む署名された証明書と共に、要求されたHTMLページを買い手のブラウザに渡す。ステップ６８で、評価者のサーバが、調査質問表に対する回答を含む、買い手１０からの調査応答を受信する。
【０１３２】
ステップ５０２で、評価者のシステムは、買い手１０から受信した調査応答を処理し、IAP４０に対する購入証明書要求を用意する（図１５を参照されたい）。ステップ５０４では、後の時点で、評価者のシステムが、１人または複数の買い手から受信したおそらくは複数の調査質問表応答に関する購入証明書要求メッセージを用意する（図１６を参照されたい）。ステップ７２で、評価者のシステムが、IAP４０に購入証明書要求メッセージを送信し、そのメッセージに含まれるリストの買い手が、その買い手が購入したと主張する製品を実際に購入したことの検証を要求する。ステップ７４で、評価者のシステムは、購入証明書要求メッセージでIAP４０に送信された買い手のリストに含まれる買い手が、その買い手が購入したと主張する製品を購入したことを示す購入証明書応答メッセージを、IAP４０から受信する。ステップ５０６で、評価者のシステムは、有効な買い手から来た有効な調査応答である調査応答の指定を含む購入証明書応答メッセージを処理する（図１９を参照されたい）。ステップ５０８で、評価者のシステムが、有効な調査応答を使用して、製品評価情報を作成または更新する（本発明では説明しない）。
【０１３３】
図１５は、図１２のステップ５０２に関連する処理ステップの流れ図である。ステップ５２０で、評価者５０は、評価者の秘密鍵PRIV_Eを用いてPUB_E(Survey1, K1, K2, Rcode_B)７８を非暗号化して、値Survey1、K1、K2およびRcode_Bを取得する。ステップ５２２で、評価者５０は、受信したヘッダ「Survey1」が正しく、これが買い手１０によって用意された調査鍵ブロックであることが示されることを検証する。
【０１３４】
ステップ５２４で、評価者５０は、HMACアルゴリズムと受信した鍵K1を使用して、受信した調査質問表応答に対するHMACの値を計算する。ステップ５２６で、評価者５０は、等しいかどうかについて、受信したHMAC(K1, survey_questionnaire_responses)の値と計算したHMACの値を比較する。これらの値が等しい場合には、調査質問表応答は暫定的に受け入れられ、処理はステップ５２８に進むが、そうでない場合には、調査質問表応答が拒絶され、調査質問表応答のこれ以降の処理は停止する。
【０１３５】
ステップ５２８で、評価者５０は、受信した鍵K2を使用して、暗号化された調査質問表応答K2(survey_questionnaire_responses)を非暗号化する。ステップ５３０で、受信したacct_B、ID_Product、timeの値と、Rcode_Bの非暗号化された値と、非暗号化された調査質問表応答が、評価者のシステムで識別子がID_IAPであるIAP４０に対応するファイルの論理レコード（Sと表す）として格納される。調査質問表応答は、評価者５０がIAP４０から購入証明書応答を受信するまで処理されない。
【０１３６】
図１６は、図１２のステップ５０４に関連する処理ステップの流れ図である。ステップ５４０で、IAP４０のそれぞれについて、評価者５０は、ステップ５４２ないし５５０を介して調査質問表応答レコードS1, S2, ..., Snを処理する。各IAP４０は、異なる識別子ID_IAPを有し、これによって、前に図１５のステップ５３０で作成された保留中の調査質問表応答レコードを含むファイルがインデクシングされることに留意されたい。
【０１３７】
ステップ５４２で、IAP４０のそれぞれについて、評価者５０は、鍵K3およびK4をランダムに生成する。ステップ５４４で、IAP４０のそれぞれについて、評価者５０は、前に格納され、IAPの識別子（ID_IAP）によってインデクシングされる公開鍵PUB_IAPを評価者のシステムから取得する。評価者５０は、別の配布プロトコルを使用して、以前にIAP４０からPUB_IAPを取得していると仮定する。たとえば、評価者５０は、PUB_IAPを含み、評価者のシステムですでに使用可能な公開鍵を有する証明機関によって署名された証明書を、IAPに定期的に要求することができる。
【０１３８】
ステップ５４６で、IAP４０のそれぞれについて、評価者５０は、ヘッダ「Survey2」と鍵K3およびK4からなる調査鍵ブロックを作成し、この調査鍵ブロックをPUB_IAPを用いて暗号化して、暗号化された値PUB_IAP(Survey2, K3, K4)８６を作る。ステップ５４８で、IAP４０のそれぞれについて、評価者５０は、そのIAP４０の保留中の調査質問表応答レコードのファイルのレコードSのそれぞれについて（Sのそれぞれに、値acct_B、ID_Product、time、Rcode_Bおよび調査質問表応答が含まれる）、鍵K4を用いて値Rcode_Bを暗号化して暗号化された値K4(Rcode_B)を作り、値acct_B、ID_Product、timeおよびK4(Rcode_B)を含む新しいレコードPを作成し、Pの値をListOfClaimedPurchases８８と称するリストにグループ化する。ステップ５５０で、IAP４０のそれぞれについて、評価者５０は、HMACアルゴリズムと鍵K4を使用してListOfClaimedPurchases８８に対するメッセージ認証コードを計算して、HMAC(K4, ListOfClaimedPurchases)９０を作る。
【０１３９】
図１９は、図１２のステップ５０６に関連する処理ステップの流れ図である。ステップ５７０で、評価者５０は、前に別の配布プロトコルを使用して受信し、評価者のシステムに格納したIAPの公開検証鍵PUB_IAPを取得する。たとえば、評価者５０は、PUB_IAPを含み、評価者のシステムですでに使用可能になっている公開鍵を有する認証機関によって署名された証明書を、IAP４０に定期的に要求することができる。IAP４０は、署名用の１対の鍵と暗号化用のもう１対の鍵を有するが、これらの鍵は、本発明では別々の対としてインデクシングされず、区別もされないことに留意されたい。ステップ５７２で、評価者５０は、既知のヘッダ「Survey3」、受信したResponseList９２の値および公開鍵PUB_IAPを使用して、署名S_IAP(Survey3, ResponseList)９４を検証する。署名が有効な場合には、評価者５０はステップ５７４に進み、そうでない場合には、ResponseList９２を拒絶し、ステップ５７４に進まない。
【０１４０】
ステップ５７４で、評価者５０は、受信したID_IAPの値に対応するIAP４０の調査質問表応答レコードのファイルを突き止める。ステップ５７６で、ResponseList９２のRのそれぞれについて、評価者５０は、ID_IAPの突き止められた調査質問表応答レコードのファイルの対応する調査質問表応答レコードSを突き止め、RのOK/fail_codeの値に応じてレコードSを有効または無効にする。すなわち、評価者５０は、OK/fail_codeに値「OK」が含まれる場合にはレコードSを有効としてマークし、そうでない場合にはレコードSを無効としてマークする。
【０１４１】
Rcode_Bは、ランダムに生成される値である。Auth_Bは、Rcode_Bと、おそらくは他のデータ（other_data）から、次の関数fを使用して計算される。
Auth_B=f(Rcode_B, other_data)
ここで、fは、Auth_Bとother_dataの値に対して、「逆戻り」してRcode_Bを計算することが計算的に実現不能であるという特性を有する。
【０１４２】
しかし、Rcode_Bの長さが十分に長くない場合、攻撃者は、Rcode_Bの正しい値が推測されるまで試行錯誤を使用する「ワーク・フォワード（work forwards）」を行うことができる。これを達成するためには、攻撃者は、Rcode_Bの試行値を選択し、f(Rcode_B, other_data)を計算し、等しいかどうかに関してこの値をAuth_Bの所与の値と比較する。一致が見つかった場合、攻撃者は、Rcode_Bの正しい値を見つけたか、同様に機能する類似物を見つけている。Rcode_Bが十分に異なる可能な値を有するようにすることによって、敵対者がRcode_Bの正しい値を発見できなくすることが簡単にできる。１２８ビットまたは１８０ビットのRcode_Bは、推測攻撃を防ぐのに十分な長さである。
【０１４３】
この類似物の問題は、Auth_Bが十分な異なる可能な値を有しない時に発生する。たとえば、Auth_Bが１６ビットしかない場合、攻撃者は、f(Rcode_B, other_data)の計算値がAuth_Bと等しくなるRcode_Bの値を見つけるまでに、平均２^１６個のRcode_Bの試行値を選択するだけでよい。しかし、１２８ビットまたは１８０ビットのAuth_Bは、類似物が発見されないようにするのに十分な長さである。
【０１４４】
もう１つの潜在的に重要な問題が、Rcode_Bに対する辞書攻撃である。この場合、攻撃者は、Rcode_Bの試行値を選択し、対応するAuth_Bの値を計算し、この２つの値を次の形で辞書に格納する。
Rcode_B<1>, Auth_B<1>
Rcode_B<2>, Auth_B<2>
...
Rcode_B<n>, Auth_B<n>
【０１４５】
次に、攻撃者は、Auth_Bの実際の値を傍受し、一致するものを自分の辞書から探す。一致するものが見つかった場合、攻撃者は、対応するRcode_Bの値を即座に知る。辞書攻撃は、さまざまな方法で防ぐことができる。１つの方法は、単純にRcode_BとAuth_Bを十分に長くし、その結果、確率的な意味でも攻撃者が攻撃を実行するのに十分な大きさの辞書を作成できなくすることである。もう１つの方法は、たとえばRcode_Bに買い手１０の秘密でない識別子（ID）を連結したものからなる入力に対して計算されるハッシュ値としてAuth_Bを定義することなどによって、Auth_Bの計算に買い手固有のデータを含めることである。
【０１４６】
Rcode_BおよびAuth_Bの値は、評価者５０に調査質問表応答を送信した買い手１０が、引証された製品について、MiniPayを使用して売り手２０からその製品を実際に購入したことを評価者５０の代わりに働くIAP４０が判定するための手段として使用される。これは、次の形で達成される。買い手のシステムが支払注文を用意する時点で、そのシステムはRcode_Bをランダムに生成する。生成されたRcode_Bの値とother_dataが、f(Rcode_B, other_data)を計算するのに使用され、Auth_Bにはf(Rcode_B, other_data)と等しい値がセットされる。計算されたAuth_Bは、署名付きの支払注文の中に置かれ、この支払注文は、売り手２０、ISP３０を経て最終的にIAP４０に送信される。言い換えると、IAP４０は、最終的に買い手１０の支払注文でAuth_Bを得る。買い手のシステムは、Rcode_Bの値を保存し、その結果、買い手１０が購入した製品の調査を受ける時に、評価者５０に行く応答に、Rcode_Bの値も含まれるようになる。ただし、このRcode_Bは、評価者５０に既知の鍵を用いて暗号化される。評価者５０は、Rcode_Bを回復し、その後、IAP４０が問題の適当な支払注文を突き止めるのに十分な他の情報と共に、暗号化された形でRcode_BをIAP４０に送信する。IAP４０は、認証検査を実行して、受信したRcode_Bの値が正しいことを判定する。これを行うために、IAP４０は、f(Rcode_B, other_data)を再計算し、等しいかどうかに関して、突き止められた支払注文のAuth_Bの値と比較する。これらの値が一致する場合、IAP４０は、Rcode_Bの値が有効であることを示す応答を評価者５０に送信する。評価者５０は、購入を主張する製品に関する調査質問表応答を提出した買い手１０が、実際にその製品を購入したことを知る。この場合、評価者５０は、買い手１０から受信した調査質問表応答を信用し、有益に使用することができる。図１３のステップ２２６が、買い手１０がRcode_Bを生成し、Auth_Bを計算するステップである。図１８のステップ４４４が、IAP４０がAuth_Bに対してRcode_Bを検証するステップである。
【０１４７】
Auth_Bの計算に適した方法の１つが、Rcode_Bを鍵として使用して、買い手の口座番号（acct_B）に対してHMACを計算することである。この場合、関数fはHMACアルゴリズムになり、Rcode_Bは、HMAC計算に使用される秘密鍵になり、acct_Bは、HMAC計算への入力データになる。
【０１４８】
実際に、Auth_Bの計算に適した多数の可能な関数fが存在する。また、Auth_Bの計算に使用することのできる多数の可能な種類のother_dataが存在する。読者は、本発明がAuth_Bを計算するための１つの方法に制限されないことを諒解されたい。
【０１４９】
上で説明した、Rcode_BとAuth_Bを使用する方法は、調査質問表応答を提出する（調査を受ける）当事者が、その製品を購入した人物でもあることの証拠を提供するが、フールプルーフではない。本発明では、Rcode_Bは、評価者５０に対して買い手１０を認証し、その買い手１０が実際に調査質問表応答で主張される製品を購入したことを確証するためのパスワードとして使用される。したがって、このパスワードを知らなければ、購入されていない製品に対する調査質問表応答を受け入れるように評価者５０を欺くことはできない。しかし、このようなパスワード方式は、曖昧さにつながる可能性がある。たとえば、買い手１０が購入した製品１つの支払注文に対して複数の調査を受ける能力を有することを許容すべきか否かは明瞭でない。許容できない場合には、IAP４０は、そのような支払注文のそれぞれについて評価者からの要求を記録することができ、「購入証明書」の要求が、同一の支払に対して別の評価者５０によってすでに行われている情況で、評価者５０に通知することができる。もう１つの潜在的な問題は、パスワード（たとえばRcode_Bの値）を共用することができ、したがって、Rcode_Bの知識だけでは、調査を受ける実体が実際にその商品を購入した実体であることの否定不能な証拠がもたらされない。しかし、悪意のある実体による誤った調査情報の導入に対するある程度の保護は提供される。また、どの調査応答も、総合的な計算された統計に対してごくわずかな影響しか及ぼさない情況では、誤った調査情報の導入に対する適度な保護を提供することができる。
【０１５０】
Rcode_BとAuth_Bを使用する方法のほかに、調査を受ける買い手１０が主張する製品を実際に購入したことを評価者５０が検証できるようにする、他の方法が存在する。
【０１５１】
１つの方法では、買い手１０が、秘密鍵K1を使用して調査応答に対してHMACを計算するのではなく、買い手の秘密鍵PRIV_Bを用いて調査応答に署名する。買い手１０は、生成された署名S_B(survey_questionnaire_responses)、買い手のDaily_Certificate、PUB_E(Survey1, K2)、DataElements={ID_IAP, acct_B, ID_Product, time}およびK2(survey_questionnaire_responses)を評価者５０に提供する。評価者５０は、買い手１０の公開鍵証明（日次証明書と称する）を使用して、買い手１０の身元（acct_B）を判定する。買い手の公開鍵PUB_Bは、受信した署名S_B(survey_questionnaire_responses)の検証にも使用される。評価者５０は、acct_B、ID_Productおよびtimeからなる支払注文ロケータ・データをIAP４０に送信する。これによって、IAP４０は、支払注文を突き止め、その支払注文が、申し立てられた製品について、申し立てられた日時に、acct_Bの代わりに処理されたことを検証できるようになる。IAP４０は、対象の支払注文が存在するか否かに応じて、yes/noの回答を応答する。この方法の可能な長所は、買い手１０が、自分の私有署名鍵を別の当事者と共有しがちではないが、買い手１０が、Rcode_Bなどの１回限りのパスワードの共有に対してほとんど不安を感じないことである。
【０１５２】
もう１つの方法では、買い手１０は、survey_questionnaire_responsesと元の支払注文を連結したものに署名する。買い手１０は、生成された署名S_B(survey_questionnaire_responses, Payment_Order)、Payment_Order、PUB_Bを含むDaily_Certificate、PUB_E(Survey1, K2)、DataElements={ID_IAP}およびK2(survey_questionnaire_responses)を評価者５０に提供する。評価者５０は、買い手１０の公開鍵証明（日次証明書と称する）を使用して、買い手１０の身元（acct_B）を判定する。買い手の公開鍵PUB_Bは、受信した署名S_B(survey_questionnaire_responses, Payment_Order)の検証にも使用される。評価者５０は、IAP４０に買い手のPayment_Orderを送信する。これによって、IAP４０は、それと同等の支払注文を突き止め、その支払注文が、申し立てられた製品について、申し立てられた日時に、acct_Bの代わりに処理されたことを検証できるようになる。IAP４０は、対象の支払注文が存在するか否かに応じて、yes/noの回答を応答する。
【０１５３】
上の方法の変形では、評価者５０が、十分な支払注文ロケータ情報と共に、Payment_Order自体ではなくPayment_OrderのハッシュをIAP４０に送信し、その結果、IAP４０が、IAP側で格納されたPayment_Orderのコピーを突き止め、ハッシュし、結果のハッシュ値を受信したハッシュ値と比較して、同等の支払注文が、申し立てられた製品について、申し立てられた日時に、acct_Bの代わりに処理されたことを検証できるようにすることである。IAP４０は、対象の支払注文が存在するか否かに応じて、yes/noの回答を応答する。
【０１５４】
上の方法のもう１つの変形では、評価者５０が、十分な支払注文ロケータ情報を送信し、その結果、IAP４０が、IAP側で格納されたPayment_Orderのコピーを突き止められるようにすることである。しかし、この場合には、IAP４０は、Payment_Orderが見つかった場合にはそのPayment_Order自体を返し、そのような支払注文が見つからない場合には、無応答を返す。IAPが返したPayment_Orderが、買い手１０から受信したPayment_Orderと同一の値であるかどうかを判定するのは、評価者５０の作業であり、これらが同一の場合には、その調査質問表応答が受け入れられ、そうでない場合には、調査質問表応答は受け入れられない。
【０１５５】
もう１つの方法では、買い手１０が、Payment_Orderを保存し、調査質問表応答のコピー（おそらく暗号化される）、十分な支払注文ロケータ情報、Payment_Orderに対して計算されるハッシュ値および、買い手の秘密鍵PRIV_Bを用いて調査質問表応答とハッシュ値に対して計算される署名を評価者５０に送信する。評価者５０は、支払注文ロケータ情報をIAP４０に送信し、この支払注文ロケータ情報は、支払注文を突き止めるのに使用される。IAP４０は、支払注文または支払注文のハッシュを評価者５０に返し、このデータは、買い手１０から受信したハッシュ値が実際にIAP４０によって突き止められた支払注文に対して計算されたハッシュ値と一致することの検証に使用される。評価者５０は、調査質問表応答と支払注文のハッシュ値に対して生成された買い手の署名を検証し、他の必要な処理ステップを実行する。
【０１５６】
もう１つの方法では、IAP４０が、すべての支払注文のハッシュ値をサーバ・データベース内にポストし、このサーバ・データベースは、すべての評価者５０からアクセス可能であり、検索を容易にするためになんらかの論理形式（たとえば日付と時刻と商人による）で構成されている。サーバ・データベース内の項目は、買い手のID（acct_B）と、支払注文に対して計算されたハッシュ値からなる。これによって、異なる評価者が、買い手１０から受信した支払注文が実際に売り手２０によって処理され、清算のために転送されたことを検証するために、このデータベースを探索して、一致するハッシュ値を突き止めることが可能になる。
【０１５７】
本発明の代替実施例では、売り手２０が、買い手１０に「購入証明」領収証を与えて、買い手１０が後に、自分がその対象の商品を購入したことを証明できるようにする。「購入証明」領収証は、買い手１０が、対象の製品を購入したことを評価者５０に対して証明するための基礎になる。「購入証明」領収証は、電子商取引の世界で追加の利益をもたらすこともできる。たとえば、「購入証明」は、次の用途に使用することができる。
１．売り手または製造者からの「ロイヤリティ・ポイント」または割引の累算。
２．割引価格での次の購入（コンピュータ・ソフトウェア・ベンダは、一般に、製品の前のバージョンを購入した人物の場合に、安い値段で製品のアップグレードを販売する）。この場合、ユーザは、前の製品の「購入証明」を有する限り、完全な製品のもう１つのコピーを入手する。この場合、ベンダは、自社データベースで誰がその製品を購入したかを記録する必要がなくなる。ベンダは、各ユーザが保存し、必要な時に提示する「購入証明」を信頼する。
３．販売促進商品の提供（すなわち、商品パッケージの一部と引き換えに与えられる景品）。
４．あるウェブ・ページへの無料アクセス。言い換えると、通常ではアクセスできないものへのアクセスの許可。
【０１５８】
この代替実施例では、拡張MiniPayシステムのステップ７２および７４（図３）が削除され、ステップ６４、６５および６８が、以下のように変更される。
１．変更されたMiniPay購入プロトコル（図４）の変更されたステップ６４で、認証コード（Auth_B）が、MPay_Order７６のNewDataから削除される。評価者５０が、購入された製品を支払注文（単独）のURLから識別できる（Product_IDが不要である）場合には、NewDataのすべてを、変更されたMiniPay購入プロトコル（図４）の変更されたステップ６４のMPay_Order７６から削除することができる。
２．拡張MiniPayシステム（図３）の変更されたステップ６５で、売り手２０は、売り手の秘密鍵PRIV_Sを使用して、変更されたMPay_Order７６に対して生成されるディジタル署名と売り手の公開鍵PUB_Sを含む証明書からなる「購入証明」領収証を買い手１０に追加送信する。
３．調査プロトコル（図５）の変更されたステップ６８で、以下の情報が買い手１０から評価者５０に送信される。
ｉ．PUB_E(Survey1, K2)。
ｉｉ．買い手１０の公開鍵PUB_Bを含む、買い手のDaily_Certificate７５。
ｉｉｉ．OldData、変更されたNewDataおよびS_B(OldData, 変更されたNewData)からなる、変更されたMPay_Order７６。
ｉｖ．S_B(survey_questionnaire_responses)。これは、買い手の秘密鍵PRIV_Bを使用して調査質問表応答に対して生成されたディジタル署名である。
ｖ．PUB_Sを含む売り手の証明書。
ｖｉ．変更されたステップ６５で買い手１０が受信する、「購入証明」領収証=S_S(変更されたMPay_Order)。
ｖｉｉ．K2(survey_questionnaire_responses)８４。
【０１５９】
評価者５０は、調査プロトコル（図５）の変更された版の変更されたステップ６８で受信するデータに対して、以下の検証を実行する。Daily_Certificate７５を検証した後に、公開鍵PUB_Bを使用し、受信したOldDataおよびNewDataの値と受信し、非暗号化した調査質問表応答とを使用して、買い手の署名S_B(OldData, 変更されたNewData)とS_B(survey_questionnaire_responses)を検証する。調査質問表応答の暗号化は任意選択であり、したがって、暗号化が実行されない場合には、暗号化された鍵PUB_E(Survey1, K2)の送信を省略することができる。PUB_Sを含む証明書を検証した後に、公開鍵PUB_Sを使用し、変更されたMPay_Order７６の受信した値を使用して、「購入証明」領収証を検証、すなわち、売り手のディジタル署名S_S(変更されたMPay_Order)を検証する。３つの署名が正しく検証された場合、評価者５０は、以下の事項を知る。
１．受信した調査質問表応答が、有効（すなわち無変更）であり、元の支払注文に署名した買い手１０が、調査質問表応答を提出した買い手１０と同一人物である。この結論を引き出すためには、署名S_B(OldData, 変更されたNewData)およびS_B(survey_questionnaire_responses)の両方が有効でなければならない。２．調査質問表応答を提出する実体が、主張する製品を実際に購入した。「購入証明」領収証は、買い手１０がその製品を購入したことを証明する。変更されたMPay_Orderに対して生成された売り手の署名は、主張される変更されたMPay_Order７６が、売り手２０によって受け入れられ、処理された実際の支払注文であることを証明する。
【０１６０】
「購入証明」領収証に基づく代替実施例の主な長所は、評価者５０とIAP４０の間の対話が不要になる、すなわち、調査調停プロトコルが不要になることである。「購入証明」領収証があれば、評価者５０は、主張される製品に対する調査質問表応答を提出した買い手１０が、その製品を実際に購入したことを簡単に判定できる。これは、IAP４０の支援または参加なしに達成できる。この代替実施例の可能な短所は、売り手２０によるものと買い手１０によるものの２つの余分な署名計算が必要になることである。買い手１０による余分な署名の計算は、削除できる可能性がある。これは、評価者５０が買い手１０の身元を検証し、したがって、調査質問表応答を提出する当事者が、売り手２０に行く支払注文に署名したものと実際に同一の当事者であることを確認するための代替手段が存在する場合に可能になる。それが可能な場合には、PUB_Eを用いて秘密鍵K1を暗号化し、評価者５０に送信し、K1を使用して調査質問表応答に対するHMACを計算するという方法を使用することによって、調査質問表応答の保全性を仮定することができる。
【０１６１】
本発明の他の変形は、当業者には明白である。したがって、MiniPayシステムに対する拡張として本発明を説明してきたが、本発明は、MiniPayシステムに制限されず、同様に他の電子支払システムと共に使用することができる。さらに、HTTP転送プロトコルおよびHTML文書形式を使用するものとして本発明を説明してきたが、他のプロトコルおよび形式を、代替または追加のいずれかとして使用することができる。本発明のそれ以外の変形および変更は、当業者には明白である。
【図面の簡単な説明】
【図１】 MiniPayシステムを示すブロック図である。
【図２】拡張MiniPayシステムを示すブロック図である。
【図３】拡張MiniPayシステムを示すブロック図である。
【図４】変更されたMiniPay購入プロトコルを示すブロック図である。
【図５】調査プロトコルを示すブロック図である。
【図６】調査調停プロトコルを示すブロック図である
【図７】買い手のクライアント・システムを示すブロック図である。
【図８】売り手と評価者のサーバ・システムを示すブロック図である。
【図９】買い手によって実行される処理ステップの流れ図である。
【図１０】売り手によって実行される処理ステップの流れ図である。
【図１１】買い手の支払請求システムによって実行される処理ステップの流れ図である。
【図１２】評価者によって実行される処理ステップの流れ図である。
【図１３】図９のステップ２０８に関連する処理ステップの流れ図である。
【図１４】図９のステップ２１６に関連する処理ステップの流れ図である。
【図１５】図１２のステップ５０２に関連する処理ステップの流れ図である。
【図１６】図１２のステップ５０４に関連する処理ステップの流れ図である。
【図１７】図１１のステップ４０２に関連する処理ステップの流れ図である。
【図１８】図１１のステップ４０４に関連する処理ステップの流れ図である。
【図１９】図１２のステップ５０６に関連する処理ステップの流れ図である。
【符号の説明】
１０ 買い手
２０ 売り手
３０ インターネット・サービス・プロバイダ（ISP）
４０ インターネット・アクセス・プロバイダ（IAP）
５０ 評価者
１００ インターネット
１０２ 買い手のシステム
１０４ ブラウザ
１０６ 調査プラグイン
１０８ MiniPay Walletプラグイン
１１０ インターネット・サーバ・システム
１１２ ウェブ・サーバ
１１４ スクリプト
１１６ 他のプログラム

Claims (2)

1. 電子支払注文を買い手の装置から売り手の装置に送信することによって上記買い手が上記売り手から製品を購入する電子支払システムにおいて、
   上記買い手の装置および上記売り手の装置とは別個の評価者装置を備え、
   上記評価者装置が、
   上記売り手から製品を購入した買い手の装置からの応答に基づいて生成された製品調査情報を維持するデータベース手段と、
   上記売り手から上記製品を購入したと主張する未確認の買い手の装置から調査応答を受信し、さらにまた上記売り手のディジタル署名および上記未確認の買い手のディジタル署名を含む上記電子支払注文を当該未確認の買い手が実際に上記売り手から上記製品を購入したことの証拠となる偽造不能な購入証明として上記未確認の買い手の装置から受信する手段と、
   上記未確認の買い手が実際に上記売り手から上記製品を購入したかどうかを確認するために、上記購入証明に含まれる上記売り手のディジタル署名および上記未確認の買い手のディジタル署名を検証する手段と、
   上記未確認の買い手が実際に上記売り手から上記製品を購入したと確認される場合に限って、上記製品調査情報に上記調査応答を組み込む手段と
   を含む、上記製品に対する調査情報を生成する装置。
2. 電子支払注文を買い手の装置から売り手の装置に送信することによって上記買い手が上記売り手から製品を購入する電子支払システムにおいて、
   上記買い手の装置および上記売り手の装置とは別個の評価者装置を備え、
   上記評価者装置が、
   上記売り手から上記製品を実際に購入した買い手の装置からの応答に基づいて生成された製品調査情報を維持するデータベース手段と、
   上記売り手から上記製品を購入したと主張する未確認の買い手の装置から調査応答を受信し、さらにまた、秘密値から生成され、上記売り手の装置への上記電子支払注文に含まれる認証コードを上記売り手の装置から受信し、当該認証コードを生成するために用いられた秘密値を上記未確認の買い手の装置から受信する手段と、
   上記受信した秘密値から認証コードを再生成し且つ当該再生成された認証コードと上記受信した認証コードを比較することにより、上記未確認の買い手が実際に上記売り手から上記製品を購入したかどうかを確認する手段と、
   上記未確認の買い手が実際に上記売り手から上記製品を購入したと確認される場合に限って、上記製品調査情報に上記調査応答を組み込む手段と
   を含む、上記製品に対する調査情報を生成する装置。

Images