JP2004527051A - マイクロペイメント・トランザクションのための方法およびシステム - Google Patents

マイクロペイメント・トランザクションのための方法およびシステム Download PDF

Info

Publication number
JP2004527051A
JP2004527051A JP2002586109A JP2002586109A JP2004527051A JP 2004527051 A JP2004527051 A JP 2004527051A JP 2002586109 A JP2002586109 A JP 2002586109A JP 2002586109 A JP2002586109 A JP 2002586109A JP 2004527051 A JP2004527051 A JP 2004527051A
Authority
JP
Japan
Prior art keywords
party
transaction
check
satisfies
receive
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002586109A
Other languages
English (en)
Inventor
エル．リベスト ロナルド
ミカーリ シルヴィオ
Original Assignee
マサチューセッツ・インスティテュート・オブ・テクノロジー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by マサチューセッツ・インスティテュート・オブ・テクノロジー filed Critical マサチューセッツ・インスティテュート・オブ・テクノロジー
Publication of JP2004527051A publication Critical patent/JP2004527051A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/042—Payment circuits characterized in that the payment protocol involves at least one cheque
    • G06Q20/0425—Payment circuits characterized in that the payment protocol involves at least one cheque the cheque being electronic only
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本発明は確率的マイクロペイメント方式に関し、確率的マイクロペイメント方式は、ユーザＵ（または他の支払人、以降は「Ｕ」または「ユーザ」と呼ぶ）が、業者（または他の受取人、以降は「Ｍ」または「業者」と呼ぶ）への支払いを少なくとも１つのトランザクションＴに対して確立することを可能にする。一般に、本発明の方式はどのような値のＴVにも適用できるが、Ｔは非常に小さな額ＴVを有する。本発明のマイクロペイメント方式は、そのようなマイクロペイメントを処理することに要するコストを最小化し、それによりシステムの効率を著しく向上させる。

Description

【技術分野】
【０００１】
本発明は確率的マイクロペイメント方式に関し、確率的マイクロペイメント方式は、ユーザＵ（または他の支払人、以降は「Ｕ」または「ユーザ」と呼ぶ）が、業者（または他の受取人、以降は「Ｍ」または「業者」と呼ぶ）への支払いを少なくとも１つのトランザクションＴに対して確立することを可能にする。一般に、本発明の方式はどのような値のＴVにも適用できるが、Ｔは非常に小さな額ＴVを有する。本発明のマイクロペイメント方式は、そのようなマイクロペイメントを処理することに要するコストを最小化し、それによりシステムの効率を著しく向上させる。また、多数の追加的長所が、以下に記載のように提案される。
【背景技術】
【０００２】
電子商取引システムの発達は、電子ネットワーク間で行われる金銭取引の数の急増をもたらした。マイクロペイメントは、オンライン少額サービス（例えば、情報検索サービス）に融資するための便利な方法を提供することにより、電子商取引トランザクションの新しい形態を可能にする。マイクロペイメントは、非常に小さな額（場合によっては、１ペニーの何分の１）を有するが、非常に大量に行われる。実施例として、情報サービス業者は、サービスに対して少額ずつ請求することを望む。マイクロペイメントは、訪問した各ウェブページ、またはユーザに流された音楽またはビデオの１分ごとの時間に対する支払いをするために使用される。
【０００３】
電子マネー支払い方式の単純な形態は、電子小切手である。電子小切手は、（手書きの署名ではなく）ディジタル署名された小切手から成る。ディジタル署名は、小切手の受取人が署名した関係者の信頼性、および小切手の内容（例えば、小切手の日付および金額）の保全性の両方を確認することを可能にする。公開鍵暗号方式の文献は、ディジタル署名（例えば、“A method for obtaining digital signatures and public-key cryptosystems,” Rivest, R.L., Shamir, A., and Adleman, L.A., Communications of the ACM, Vol. 21, No. 2, 1978, S. 120-126 に記載されたＲＳＡ方式）を実施するための多くの方法を提供する。周知のように、公開鍵暗号方式における各関係者は固有の鍵ペアを使用する。各ペアは、公開鍵および対応する秘密鍵を含む。公開鍵は一般に公開されているが、対応する秘密鍵は所有者のみが知っていて利用可能であり、所有者は秘密鍵を守って秘密のままにする。秘密鍵を対応する公開鍵の知識または発見から導出することは、コンピュータで実行可能ではない。従って、一般に公開されている公開鍵を作成することは、適合する秘密鍵のセキュリティを脅かさない。秘密鍵は所有者以外の誰かが決して利用できないので、公開鍵暗号方式は、秘密鍵が異なる関係者の中で共有されるシステムと比較して強化されたセキュリティを享受する。
【０００４】
公開鍵暗号方式では、メッセージを秘密裏に送りたい差出人が受取人の公開鍵を入手し、受取人の公開鍵を使用してメッセージを暗号化する。暗号化されたメッセージを受け取るとすぐ、受取人は適合する自分の秘密鍵を使用して暗号化されたメッセージを複合化し、元のメッセージを読む。適合する秘密鍵を利用することなしに、暗号化されたメッセージを復号化することはコンピュータで実行不可能である。
【０００５】
公開鍵ディジタル署名方式では、メッセージの署名者は、自分の秘密鍵をメッセージに適用することによって自分のディジタル署名を生成する。従って、結果として生成されたディジタル署名は、メッセージ、およびディジタル署名を生成するために使用される特定の秘密鍵の両方に対して固有である。メッセージとディジタル署名を所有する誰もが、署名者の公開鍵を使用してディジタル署名の信頼性を確かめられる。
【０００６】
また、ハッシュ関数が、多くの公開鍵ディジタル署名方式で使用される。ハッシュ関数は、（メッセージに適用されるとき）メッセージのディジタル「指紋」を固定長を一般に有する「ハッシュ値」の形式で生成するアルゴリズムである。「一方向衝突防止性」（またはセキュア）ハッシュ関数は、元のメッセージを自分のハッシュ値から導出すること、または同じハッシュ値を有する２つのメッセージを見出すことさえコンピュータで実行不可能なハッシュ関数である。従って、メッセージのハッシュは、メッセージに対する識別「指紋」としてうまく機能する。何故ならば、もし（たとえ僅かでも）何らかの変更をメッセージに加えたら、異なるハッシュ値を用いて何時でもメッセージを得るからである。
【０００７】
「ハッシュと署名」方法では、ディジタル署名方式においてハッシュ関数を使用することが一般的である。ディジタル署名をこの方法で生成するために、メッセージの差出人はハッシュ関数をメッセージに適用し、従って、ディジタル指紋またはハッシュ値をメッセージに対して計算する。次に、差出人は自分の秘密鍵をハッシュ値に適用し、そのメッセージに対する自分のディジタル署名を得る。
【０００８】
ディジタル署名の信頼性、およびメッセージの内容の保全性は、差出人の公開鍵、および署名を生成するのに使用されたハッシュ関数を使用して確認できる。受取人は、メッセージが差出人によって確かに署名されたことをメッセージに対するハッシュ値を再計算することにより確認でき、次にこのハッシュ値と差出人の公開鍵を入力とする確認手続きを適用する。確認手続きは、例えば、差出人の公開鍵を解読鍵として使用すること、もし解読がメッセージの再計算されたハッシュ値をもたらせば、署名が正当であるとして受け入れることと述べている。もし確認がうまくいけば、受取人は差出人が実際にメッセージに署名したこと、および署名されていたのでメッセージが改竄されなかったことを確信する。
【０００９】
一般的な電子小切手支払方式では、ディジタル署名を（トランザクションを識別する）データに提供することにより、ユーザは業者にトランザクションを支払う。データは、数ある中で、ユーザ、ユーザの銀行口座番号、業者、支払われる金額、トランザクションの時間、および／または購入された情報、サービス、または商品を識別する。一般に、業者は、ユーザから受け取った電子小切手を、小切手を銀行へ送ることによって預ける。
【００１０】
電子小切手方式のディジタル署名機能は、ディジタル証明書によりサポートされる。ディジタル証明書は、特定の個人が証明書の中で与えられた公開鍵に対応する秘密鍵を保有することを主張する最も一般的な電子文書である。換言すれば、証明書は鍵ペアを特定の関係者と関連付ける。証明書はそれ自体が信用ある機関によりディジタル署名されるので、ディジタル証明書は指定された関係者が証明書に記載された公開鍵を確かに所有していること、および指定された関係者が対応する秘密鍵を排他的に管理することの証明として通常は信用される。また、ディジタル証明書は、関係者が電子マネー支払いに署名する、または他の特定の行為を行う権限を与えられていることも主張する。
【００１１】
電子小切手のディジタル署名を確認したあと、銀行は適切な金額を業者の貸方に記入し、適切な金額をユーザの借方に記入する。また、銀行は、任意のトランザクション手数料または他の手数料も請求する。
【００１２】
電子マネー支払いシステム（特に、マイクロペイメント・システム）は、多くの課題に直面する。マイクロペイメントについての根本的な問題は、マイクロペイメントに対する銀行の処理コストという点にある。しばしば、マイクロペイメント・トランザクションを取り扱う銀行に対するコストは、マイクロペイメント自体の価値の数倍になる。例えば、クレジットカード・トランザクションの処理は通常は約２５セント掛かるが、典型的なマイクロペイメントは約１セント以下の価値である。従って、マイクロペイメントをサポートするためには格段の効率を必要とし、さもなければ、支払いの仕組みのコストが、支払いの価値を上回る。
【００１３】
従って、マイクロペイメント方式は、多数の低額な支払いを少数の高額な支払いに集約することにより、銀行の処理コストを減らそうとする。多様な集約戦略が利用可能である。マイクロペイメント方式の幾つかは、セッションレベル集約 (session-level aggregation) を有し、所定の「セッション」の間のユーザと業者の間の全支払いが、より高額な単一の支払いに集約される。もう１つの戦略はグローバル集約 (global aggregation) であり、支払いが全てのユーザ／業者ペアにわたって集約される。グローバル集約は、優れた柔軟性と大きなコスト削減をもたらす。
【００１４】
多数のマイクロペイメント方式が当該技術分野で既知であり、調査が文献（例えば、“Digital Cash: Commerce on the Net,”Peter Wayner, Academic Press, 1996 ）に見出される。現在知られているマイクロペイメント方式は（“PayWord and MicroMint: Two simple micropayment schemes,”Ronald L. Rivest and Adi Shamir, Fourth Cambridge Workshop on Security Protocols, Springer Verlag Apr. 1996 に記載される）「PayWord」、および（“Electronic Lottery Tickets as Micropayments,”Ronald L. Rivest, in Proceedings of Financial Cryptography '97, vol. 1318 of Lecture Notes in Computer Science, pp. 307-314, Springer 1997 に記載される）「電子抽選 (electronic lottery) 方式」を含む。他の既知であるマイクロペイメント方式は、（Manasse 他の“MicroMint”by Rivest and Shamir による）「Millicent」、（Anderson による）「NetCard」、Jutla と Yung による「PayTree」、Hauser 他の「MicroiKP」、 Jarecki と Odlyzko による確率的ポーリング方式、 Wheeler による「transactions using bets」の提案、 Pedersen による類似の提案、および Lipton と Ostrovsky による効率的な coin-flipping によるマイクロペイメントの関連する提案を含むが、限定はされない。Jarecki/Odlyzko の確率的ポーリング方式は、１９９９年１２月７日に Stanislaw Jarecki と Andrew M. Odlyzko に発行された米国特許第5,999,919号（“Efficient Micropayment System”）に開示される。
【００１５】
PayWord は、公開鍵ディジタル署名方式および一方向ハッシュ関数に基づくマイクロペイメント・システムである。 PayWord システムでは、ユーザは銀行からディジタル証明書を受け取り、ディジタル証明書はユーザに一連のハッシュ値、または「payword」ｗiを作成する権限を与える。これらの payword は、業者により銀行から金銭的に償還できる。以下の関係により、ｉ番目の payword はｉ＋１番目の payword に関連付けられる。
ｗi＝ｈ（ｗi+1）,
ここで、ｈは一方向ハッシュ関数である。従って、ｗi+1をｈ（ｗi+1）から導出することは、コンピュータで実行不可能である。ｉ＋１番目の payword ｗi+1は、業者によりｉ番目の payword ｗiを使用して、ハッシュ演算ｈをｗi+1に施すことによって確認できる。 PayWord 方式では、ユーザが一連のハッシュ値ｗ0，ｗ1，．．．，ｗnを計算し、ルートｗ0の自分のディジタル署名を業者へ送ることにより全体にコミットする。その後、ユーザは、 payword を連続して順番に明らかにすること（ｗ1, ｗ2，．．．，ｗi，．．．）により、業者への連続する各支払いを行う。一連の連続する値の各々は、その値が一連の payword の前の値をハッシュしたことをチェックするためにそ、の値にハッシュ関数を作用させることにより業者によって確認できる。
【００１６】
PayWord は、業者が買い手の支払いを都合よく集約することを可能にする。ｋマイクロペイメントが行われた後、もし業者が（総合すれば）ｋマイクロペイメントが十分な額のマイクロペイメントを構成すると考えたら、業者はｋセント（または、各マイクロペイメントを表す他の適切な通貨単位）に対して銀行に単一の預金を行う。業者は、銀行にたった２つの値（ｗk、およびｗ0のユーザ署名）を知らせる。銀行はｗ0のユーザ署名を確認し、ハッシュ関数をｋ回ｗkに作用させ、この演算が確かにｗ0を生成することを確認する。確認の後、銀行は業者の口座にｋセントを振り込み、ユーザの口座にｋセントを請求し、他のトランザクション手数料を任意に請求する。
【００１７】
PayWord は、業者が異なるユーザのマイクロペイメントを集約できないという短所がある。これは、 PayWord では、各ユーザは自分のハッシュ値鎖を業者との間に確立しなければならず、異なるハッシュ値鎖はマージできないからである。また、他の多くのマイクロペイメントの提案（例えば、Millicent ）も、異なるユーザ／業者ペアにわたるマイクロペイメントを集約できないという問題がある。即ち、 PayWord は、セッションレベル集約だけを提供し、グローバル集約を提供しない。
【００１８】
Rivest による電子抽選方式は、トランザクション・コストを削減できるように、マイクロペイメントを集約するためのもう１つの方法を提供する。この方式は、各マイクロペイメントに対する選択率 (selection rate) 、または選択確率 (selection probability) ｓ（０＜ｓ＜１）に基づき、平均して、全ての１／ｓマイクロペイメントの中の１つだけが、実際の支払いに対して選択される。選択率ｓは既知であり、予測可能であり、一定である。業者に提示される各マイクロペイメントに対して、業者は最初に一連の PayWord のルートｗ0のユーザ署名を確認し、ｋ回ハッシュされたら提供されたハッシュ値ｗkが確かにｗ0を生成することを確認する。もし、そうなら、業者はユーザからのマイクロペイメントを受領する。次に業者は、マイクロペイメントが銀行で預金に対して選択されるべきか否かを決定するために、ユーザとの予め定められたインタラクションプロトコル (interaction protocol) を通過する。選択されない小切手は預金できず、従って、業者にとって無価値である。従って、選択されない小切手は、業者によって廃棄される。（インタラクションプロトコルを通して）選択されたマイクロペイメントだけが、支払いを受けるために、業者によって銀行へ実際に提示される。この方法では、銀行は各々および全てのマイクロペイメントを処理する必要はなく、平均して、１／ｓマイクロペイメントの１つを処理するだけである。それにより、銀行の処理コストは大きく削減される。このプロセスを業者に対して公平にするために、選択された各マイクロペイメントに対して、業者は元々指定されたマイクロペイメント金額の１／ｓ倍の金額を稼ぐ。換言すれば、銀行は業者にマイクロペイメントの額面価格の１／ｓ倍に「拡大された」金額を支払う。
【００１９】
その長所にもかかわらず、電子抽選方式は、特定のマイクロペイメントが預金に対して選択されるべきか否かを決定するために、ユーザと業者が各マイクロペイメントと対話しなければならない欠点を有する。この要求が電子マネー支払いシステムを相当に減速させ、場合によっては、この方式を実行不能にする。
【００２０】
上記理由により、非対話型マイクロペイメント方法およびシステムに対する必要性が存在し、非対話型マイクロペイメント方法およびシステムはマイクロペイメントのグローバル集約を可能にして銀行処理コストを最小化するが、同時にマイクロペイメント選択プロセスではユーザと業者の対話を必要としない。
【００２１】
加えて、時間の制約をマイクロペイメント・システムに取り入れることが好ましい。例えば、銀行から支払いを受けるために、業者に支払い可能な小切手（即ち、預金に対して適切に選択されるマイクロペイメント）を銀行へ適当な期間内に預けることを要求する時間の制約をマイクロペイメント・システムに含むことは好都合である。即ち、この方法では、トランザクションに対する可能な支出が支払い口座にもう無いとき、ユーザは余りに遅く請求されない。また、このタイプの制約は、小切手Ｃの時間情報が正確であることを確認するため業者に追加の報奨金を与え、それによりシステムのセキュリティを向上させる。
【００２２】
確率的マイクロペイメント方式で特有のもう１つの問題は、（選択プロセスにおけるユーザと業者の対話が原因の非効率を除いて）ユーザが実際の支出額より多く請求されることに対するリスクである。確率的マイクロペイメント方式のユーザは、場合によっては、不運により、実際の支出額より多く支払わなければならない確率（たとえ小さくても）に対処しなければならない。そのような出来事は希であり、そのように希な出来事の相対的効果は、行われたマイクロペイメントの数と共に劇的に減少する。それにもかかわらず、（僅かではあるが）余計に請求されることの可能性は、この方式が広く普及することへの大きな障害を構成する。これは、一般のユーザがリスク管理に慣れていないからである。
【００２３】
上記理由により、マイクロペイメント方法およびシステムに対して、銀行処理コストを最小化するだけでなく、ユーザが決して実際の支出額より多く請求されないことを保証する必要がある。
【００２４】
最後に、効率を向上させようとするマイクロペイメント・システムは、業者による支払いに対して選択され、支払いの総数の小さな部分だけを一般に構成する支払いに対して、一般に銀行に行動させる。しかし、そのようなマイクロペイメント・システムは、支払い選択プロセスへの柔軟性または管理を銀行に提供しない。そのような管理は、リスク管理において銀行に好都合である。
【００２５】
従って、選択プロセスにおけるユーザと業者の対話の必要性を解消し、支払い過ぎのリスクをユーザから銀行または業者へ移すだけでなく、銀行に支払い選択プロセスへの柔軟性および管理を提供するマイクロペイメント方式が利用可能になることが望ましい。
【特許文献１】
米国仮出願第６０／２８７，２５１号明細書
【特許文献２】
米国仮出願第６０／３０６，２５７号明細書
【特許文献３】
米国仮出願第６０／３４４，２０５号明細書
【発明の開示】
【発明が解決しようとする課題】
【００２６】
本発明の第１の実施例では、（小切手を受け取るとすぐにユーザと対話することなく）小切手が支払いに対して選択されるべきか否かを業者が決定することを可能にするマイクロペイメント・プロトコルが提示される。従来技術の確率的マイクロペイメント方式とは異なり、この実施例のマイクロペイメント・プロトコルは、支払い能力の決定が対話的選択プロトコルが業者とユーザの間で発生するまで遅らされることを必要としない。
【００２７】
本発明の第２の実施例では、本発明のマイクロペイメント方式が時間の制約をシステムに取り入れ、時間の制約を特別な方法で使用する。小切手が支払いに対して選択されるために、これら時間の制約は、トランザクションの時間および／または日付に関する情報が小切手上に提供されること、および小切手上の時間情報が所定の基準を満たすことを必要とする。
【００２８】
本発明の第３の実施例では、選択的預金プロトコルが提示され、選択的預金プロトコルはユーザが実際の支出額より多く請求されるリスクを解消する。
【００２９】
最後に、本発明の第４の実施例は遅延選択プロトコルを特徴とし、遅延選択プロトコルは銀行（または、他の第三者、またはブローカー、以降は「銀行」と呼ぶ）に支払いプロセスへの管理および柔軟性を提供する。
【００３０】
本発明の第１の実施例によるマイクロペイメント方式では、Ｔに関係するデータ列Ｃを生成するために、ユーザＵはトランザクションＴに関係するレコードを使用する。Ｃは、ユーザの秘密鍵を使用して、Ｔに対するディジタル署名を生成することにより署名された電子小切手である。ユーザは、業者に小切手Ｃを受け取らせる。Ｃを受け取るとすぐ、業者はＣをユーザが実質的に予測できない項目Ｖに関連付ける。業者は、ＶをＣに関連付けるために、業者にだけ既知の秘密情報ＳＩを使用する。実施例として、Ｖは、（ＳＩＧM（Ｃ）により示され、業者の秘密署名鍵を使用して公開鍵ディジタル署名方式で業者により生成される）Ｃに対する業者のディジタル署名でもよい。
【００３１】
次に、業者は、ＶがプロパティＰを満たすか否かをを決定する。好ましい形態では、プロパティＰは、所定の小切手Ｃが支払いに対して選択される確率ｓ（０＜ｓ＜１）に関連付けられる。もし業者が電子小切手Ｃから導出された項目ＶがプロパティＰを満たしていないと決定したら、業者は単に小切手Ｃを廃棄し、銀行は小切手Ｃを調べない。もし業者が項目Ｖ（例えば、ＳＩＧM（Ｃ））がプロパティＰを確かに満たしていると決定したら、業者はＶがＰを満たすか否かを銀行に確認させる情報Ｉを銀行に受け取らせる。例えば、Ｉは、業者のディジタル署名方式のための（Ｖを生成するために使用される業者の秘密鍵に対応する）業者の公開鍵かもしれない（または、業者の公開鍵を含むかもしれない）。Ｉを受け取るとすぐ、銀行は、ＶがプロパティＰを満たすか否かをを独自に確認することに着手する。もし銀行が、ＶはプロパティＰを確かに満たすと確認したら、銀行は業者（または、業者、ユーザ、もしくは銀行以外の第四者）に金額Ａを受け取らせる。一般に、金額ＡはＴVより多く、１つの形態では、ＴVと確率ｓの逆数の積に関連付けられる。金額Ａは、Ａ＝［ＴV＊１／ｓ］により与えられる。
【００３２】
（本発明の第１の実施例による）トランザクションＴに対する支払いを確立するためのシステムは、第一者（ユーザ、または他の関係者）、第二者（業者、または他の関係者）、第三者（銀行、または他の関係者）、および第四者の間で電子データを伝送するための通信チャネルを含む。システムは、Ｔから導出されたデータ列Ｃを入力して記憶するための（第一者により機能する）手段を含む。更に、システムは、（Ｃの少なくとも一部分に関連付けられ第一者が実質的に予測できない）項目Ｖを入力して記憶するための（第二者により機能してＣに応答する）手段を含む。システムは、ＶがプロパティＰを満たすか否かを決定するための（第二者により機能する）手段を含む。更に、システムは、ＶがＰを満たすことを第三者に確認させる情報Ｉを第三者に受け取らせるための（ＶがＰを満たすときに第二者により選択的に機能する）手段を含む。更に、システムは、第四者に金額Ａを受け取らせるための（ＶがＰを満たすときに第三者により選択的に機能する）手段を含む。
【００３３】
本発明の第２の実施例では、時間の制約が、上記の非対話型マイクロペイメント・プロトコルに取り入れられる。この実施例では、ユーザは、一部分が時間ｔによって特徴付けられるトランザクションＴに対して業者への支払いを確立できる。一般に、時間ｔは、トランザクションＴが発生する時間および／または日付を示す。ユーザは、Ｔに関連付けられるデータ列Ｃを生成する。この実施例では、ＣはＴの時間ｔに関する情報を含まなければならない。ユーザは、業者にＣ、または情報をｔに含むＣの少なくとも一部分を受け取らせる。業者は、Ｃ（または、受け取ったＣの一部分）をユーザが実質的に予測できない項目Ｖに関連付ける。項目Ｖは、Ｃの時間情報の関数（例えば、時間情報を含むＣの少なくとも一部分の（業者の秘密鍵を使用して生成された）業者のディジタル署名）である。また、ＶはＧ（Ｃ）のディジタル署名である。ここで、Ｇ（Ｃ）は、Ｃの関数（または、Ｃを使用するアルゴリズム）を意味する。 例えば、Ｇ（Ｃ）は、Ｃの時間／日付情報（例えば、Ｃの厳密に同じ時間／日付情報、もしくは「集められた」時間／日付情報）、またはＣが参照するトランザクションＴの時間／日付情報を戻す関数である。次に業者は、ＶがプロパティＰを満たすか否かを決定する。もしＶがＰを確かに満たせば、時間ｔ'に業者は、ＶがＰを満たすか否かを銀行に確認させる（例えば、Ｖを生成するために使用された業者の秘密鍵に対応する業者の公開鍵を含む）情報Ｉを銀行に受け取らせる。
【００３４】
本発明の第２の実施例では、銀行が第四者に金額Ａを受け取らせるために、ｔ'−ｔは所定の時間間隔より小さくなければならない。ＶがＰを満たすという要求に加えて、これがもう１つの要求である。換言すれば、（トランザクションＴが発生した）時間ｔに関する情報を含む支払い可能な小切手を業者が提示する場合にのみ銀行は業者の口座の貸方に記入し、時間ｔは所定の期限内である。例えば、もしトランザクションＴが日付ｉに発生したら、業者は対応する小切手Ｃを日付ｉが終わるまでに、または日付ｉ＋１までに、または日付ｉ＋ｎ（ｎは所定の整数）までに預金することを要求される。従って、プロトコル中の時間の制約は、適時な預金を要求する。適時な預金を要求することは、ユーザが余りに遅く請求されることはないことを保証することにより利益を提供し、銀行が他の形態のリスク（例えば、実際より前の日付が付いている小切手から生じるリスク）を管理することを可能にする。
【００３５】
本発明の第３の実施例では、選択的預金プロトコルが提示されて、ユーザが実際の支出額より多く請求されることは決してないことを保証する。基本的な確率的支払い方式により、１または複数の各トランザクションＴi（ｉ＝１，．．．，ｎ）に対して、ユーザは（銀行がトランザクション（例えば、Ｔi）を処理するのに必要なコストのほんの一部の価値しかないかもしれない）額面価格ＴＶiを有する小切手／マイクロペイメントＣiを得る。
【００３６】
本発明の第３の実施例では、各小切手Ｃiは、（好ましくは１から始まる）漸進的なシリアル番号Ｓiを含む。ユーザにより導出された小切手の時間順連続物では、シリアル番号Ｓiが他の小切手に対する小切手Ｃiの位置を表すのが好ましい。第３の実施例では、ユーザに対する借方金額の合計が、ユーザが実際に使った金額の合計（便宜上、ＴＶaggで表す）より決して多くならないことが保証される。一般に、ユーザが自分のｉ番目の小切手を書くとき、合計金額ＴＶaggは小切手の合計金額により与えられる。即ち、
ＴＶagg＝ＴＶ1＋ＴＶ2＋．．．＋ＴＶiである。
【００３７】
例えば、もしＣiが支払い可能であることが分かった第１の小切手であり、Ｄiが対応する借方金額であれば、本発明の第３の実施例で開示されるマイクロペイメント方式は、ＤiがＴＶagg＝ＴＶ1＋ＴＶ2＋．．．＋ＴＶiを越えないようにする。この保証は、銀行が業者から受け取った小切手のシリアル番号を監視するプロトコルを通して達成される。ユーザの借方に記入する前に、銀行は支払いが行われた（順番に並べられた一連の小切手の中の）最後の小切手のシリアル番号Ｓmaxを決定しなければならない。全ての実施例では、全てのトランザクションはＴＶと等価である。この場合、もしＣiが次の支払い可能な小切手なら、銀行は金額Ｄi＝（Ｓi−Ｓmax)＊ＴＶをユーザの借方に記入する。従って、金額Ｄiは最後の支払いが行われてからユーザが書いた小切手の数にだけ依存し、借方金額の合計はＳi＊ＴＶを越えないことが保証される。
【００３８】
最後に、本発明の第４の実施例では遅延選択プロトコルが提示され、遅延選択プロトコルは銀行に支払いプロセスへのより優れた管理および柔軟性を提供する。本発明の前記実施例のように、ユーザは（各々が値ＴＶiを有する）データ列または「小切手」Ｃiを１または複数の各トランザクションＴi（ｉ＝１，．．．，ｎ）に対して導出し、業者にＣiを受け取らせる。
【００３９】
本発明の第４の実施例では、業者は受け取った小切手Ｃiのグループをｍ個のリストＬk（ここで、ｋ＝１，．．．，ｍ）へ一意に関連付ける。各リストＬkはデータ列Ｃk 1，．．．，Ｃk lkを含み、ここでｌkは所定のリストＬkの小切手の総数を表す。従って、もしｎがｍ個のリスト全ての小切手の総数なら、Σm k=1ｌk＝ｎである。
【００４０】
業者は、コミットメントＣＭkを各Ｌkに対して計算することにより、ｍ個のリストＬk（ｋ＝１，．．．，ｍ）にコミットする。コミットメントＣＭkハッシュ値Ｈ（Ｌk）であることが好ましく、ここでＨは一方向ハッシュ関数である。業者は銀行にコミットメントＣＭk（ｋ＝１，．．．，ｍ）を受け取らせる。
【００４１】
ＣＭk（ｋ＝１，．．．，ｍ）を受け取るとすぐ、銀行は本発明の第４の実施例で開示された遅延選択プロトコルをｉ1，ｉ2，．．．ｉrを表す１または複数の整数インデックスを選択することにより実行する。ｒの値は任意であり、銀行次第である。銀行は、業者に選択されたインデックスｉ1，ｉ2，．．．，ｉrを受け取らせる。
【００４２】
選択されたインデックスｉ1，ｉ2，．．．，ｉrの受け取りに対する応答では、業者はデ・コミット(de-commit)ＣＭi1，ＣＭi2，．．．，ＣＭirし、それによりＬi1，．．．，Ｌirを第三者（例えば、銀行）に明らかにする。第五者（銀行、または銀行以外のエンティティ）は、第四者（業者、または業者以外のエンティティ）に掛売金額ＣＲを受け取らせる。第五者は、借方金額Ｄをユーザの借方に記入する。
【００４３】
掛売金額ＣＲはＶkに関係するのが好ましく、ここでＶkは所定のリストＬkに含まれる全ての小切手の合計値、即ち、
Ｖk＝ＴＶk 1＋．．．＋ＴＶkｌkを表す。
掛売金額ＣＲは、ｍ個のリスト全てに含まれる全ての小切手の合計値、即ち、
ＣＲ＝Ｖ1＋．．．＋Ｖk＋．．．＋Ｖm＝Σm k=1Ｖkにより与えられる。
この場合、コミットメントＣＭiがリストに提供されるときに、値Ｖiに対するコミットメントが銀行に提供される。インデックスを指定することにより銀行がいくつかのリストを選択した後に、全ての値Ｖiがデ・コミットされる。
【００４４】
或いは、掛売金額ＣＲは、インデックスが銀行により選択されたリストに丁度含まれる全ての小切手の合計値に関連付けられる。銀行は小切手のｒ／ｍの部分だけを見ていることを反映するために、この掛売金額ＣＲは、スケールファクタ（例えば、ｍ／ｒ（ここで、ｍは整数、ｒは上記を参照のこと）により上記合計金額に関連付けられる。
【００４５】
対応する借方金額Ｄは、複数の方法の１つで導出される。Ｄを導出するための方法の選択は、ＣＲを計算するための方法に関連付けられる（または、関連付けられない）。例えば、値Ｄは合計値
Ｖi1＋Ｖi2＋．．．＋Ｖirに関連付けられ、
前記合計値は、インデックスが銀行によって選択され業者へ転送されるインデックスと一致するリストに含まれる全ての小切手の合計値であり、例えばファクタ（例えば、ｍ／ｒ）により変倍された合計の値である。または、値Ｄは掛売金額ＣＲから導出され、例えば、掛売金額ＣＲに等しい。または、値Ｄは、選択されたリストに含まれる小切手のシリアル番号から（前記の方法で）導出できる。大部分のアプリケーションでは、多数の個別ユーザが存在し、各ユーザが請求される金額は、小切手に選択されたリストのユーザにより書かれた何らかの形に依存する。各ユーザＵに対する借方金額ＤUを計算するための好ましい方法は、ユーザＵにより書かれた小切手のシリアル番号に基づく方法を使用することである。
【発明の効果】
【００４６】
本発明では、方法とシステムが提示され、マイクロペイメント方式の効率と柔軟性を向上させる。
【００４７】
本発明では、マイクロペイメント・システムは少なくとも第一者、第二者、および第三者を含む。本発明の１形態では、第一者は支払人（例えば、買い手、またはユーザ）を表す。第二者は、受取人（例えば、商品の業者、またはサービスの供給業者）を表す。第三者は、ブローカー、または銀行を表す。また、追加の関係者も含まれる。いくつかの状況では、単一のエンティティが複数の関係者の役割（例えば、第二者と第三者の両方の役割）を果たす。実施例は、ユーザがマイクロペイメントを自分の銀行に行いたい状況である。或いは、単一のエンティティが第二者と第四者の両方の役割を果たす。
【００４８】
後で、参照を簡単にするために、用語「ユーザ」が「第一者」を意味するように、用語「業者」が「第二者」を意味するように、用語「銀行」が第三者ブローカーを意味するように、それぞれ使用する。しかし、第一者がユーザでも、第二者（業者）でも、第三者（ブローカー、または銀行）でもある必要がないことは理解されるべきである。
【００４９】
最後に、追加の関係者も、本発明によるマイクロペイメント方式に含まれる。例えば、第三者は、（ことによると、第二者と協同して）第四者に支払いを受け取らせる。例えば、第一者は料金所を通過する自動車運転者の支払い装置であり、第二者は料金所装置であり、第三者は自動車運転者の銀行であり、第四者はエンティティ徴収装置である。この場合、自動車運転者はマイクロペイメントを料金所装置で提出し、もし正しい条件が発生すれば、支払いが自動車運転者の銀行により料金徴収エンティティに対して行われる。もう１つの実施例として、第五者が含まれ、第三者が第五者に実際の支払いを第四者または第二者に対して行わせる。例えば、先の実施例について詳しく述べると、第三者は支払い装置の製造業者、エンティティ管理業者、または貸し出し業者であり、第五者は自動車運転者の銀行であり、自動車運転者の銀行は最終的に第四者に支払う。 同じ第五者、または、第三者もしくはもう１人の第六者が、利益のために、第一者またはもう１人の関係者の借方に実際に記入する。
【実施例１】
【００５０】
Ｉ．非対話型マイクロペイメント方式
本発明の第１の実施例では、マイクロペイメント方式が提示され、所定の支払いが選択されるべきか否かを決定するために、マイクロペイメント方式は業者がユーザと対話する必要性を解消する。この実施例では、ユーザが支払いを行うことを望むとき、ユーザは電子文書または「小切手」を生成し、業者に小切手を受け取らせる。この実施例では、小切手を受け取るとすぐ、業者は小切手が銀行に対する提示のために選択されるべきか否かを決定でき、ユーザの口座の借方への適切な記入、および業者の口座への貸方への記入が行える。業者は、そのような決定をユーザと対話することなく行える。従来技術の電子抽選マイクロペイメント方式の場合とは異なり、そのような決定を、対話的選択プロトコルがユーザと業者の間で発生するまで遅らせる必要はない。この方法で、マイクロペイメントの効率は著しく向上する。
【００５１】
本発明の第１の実施例では、トランザクションＴ（または、一連のトランザクションＴ）のために、一般にユーザは業者に支払う必要がない。一般に、トランザクションは、非常に小さい（例えば１セント、または１セントの何分の１）トランザクション値ＴVにより特徴付けられる。従って、もし銀行が単一のトランザクション毎に対して支払いを処理しようとしたら、銀行はトランザクション値自体よりはるかに大きい処理コストを負う。
【００５２】
図１は、本発明の第１の実施例によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図である。ユーザが支払いを本発明によるマイクロペイメント方式で行いたいとき、ユーザはデータ列または「電子小切手」Ｃを生成し、Ｃを業者へ送るか、さもなければ業者にＣを受け取らせる。一般に、小切手Ｃは、トランザクションのレコードＴから導出される。例えば、小切手Ｃは、トランザクションに対するディジタル署名ＳＩＧU（Ｔ）をユーザの秘密鍵を使用してつくり出すことにより生成され、ユーザによるこの署名は業者により確認される。ユーザ署名ＳＩＧU（Ｔ）は、この確認を進めることを可能にするＴについての十分な情報を含む（または、伴う）。また、ユーザは、自分のディジタル署名（例えば、Ｕのディジタル署名を確認するのに使用されるＵの公開鍵を指定するディジタル証明書）の確認を可能にするディジタル証明書を業者に受け取らせる（または、Ｃに取り入れる）。各小切手Ｃは、支払いに対して選択される確率または選択率ｓ（０＜ｓ＜１）を有する。
【００５３】
業者は、ユーザが実質的に予測できない項目Ｖ（例えば、業者の秘密鍵を使用して生成されたＣに対するディジタル署名）を小切手Ｃに関連付ける。次に業者は、ＶがプロパティＰを満たすか否かを決定する。本発明の好ましい実施例では、ＶがＰを満たす確率は選択率ｓと等しい。もし業者がＶがＰを確かに満たすことを見出せば、業者は銀行がＶがＰを満たすか否かを確認することを可能にする情報Ｉを銀行に受け取らせる。さもなければ、業者は小切手Ｃを廃棄する。Ｉを受け取るとすぐ、銀行は（もし存在するなら）小切手Ｃのユーザ署名を確認し、もし署名が確認されなければ小切手を廃棄する。銀行は、他のテスト（例えば、銀行のユーザの口座のステータスに関するテスト（例えば、口座がまだ優良な状態（例えば、適切なユーザのディジタル証明書が無効にされたか否か）であるか否かを決定する））を行い、もしそのようなテストに不合格であれば、銀行は小切手を引き受けない選択をする。次に銀行はＶがＰを確かに満たすことを確認し、ＶがＰを満たす場合にのみ、業者に総額を受け取らせる。
【００５４】
本発明のマイクロペイメント方式の各要素をより詳細に参照すると、本発明で支払いをもたらす「トランザクション」は、ユーザが業者に支払いを行わなければならない広範囲の考えられる状況をカバーする。例えば、ユーザは、サービス、情報、または商品を購入するために業者に支払いを行う。或いは、ユーザは、何ら購入することなく（例えば、業者に寄付するために）業者に支払いを行う。一般的なトランザクションＴの実施例は、（限定されないが）ユーザが情報提供ウェブサイトを訪問すること、１ページ毎のウェブページ（訪問された各ウェブページが単一のトランザクションＴを表す）、または１分毎のユーザにストリーミングされたオーディオ／ビデオ素材（ストリーミングされたオーディオ／ビデオ素材の各分が単一のトランザクションＴを表す）を含む。
【００５５】
トランザクションのレコードＴは、トランザクションの記述的詳細を含むデータ列である。例えば、レコードＴは、以下のうちの１または複数を指定する。即ち、支払われる金額、（もし存在するなら）購入される商品の説明、ユーザおよび／または業者の識別、ユーザおよび／または業者の公開鍵、ユーザおよび／または業者に対するディジタル証明書、トランザクションの日付および時間、関係する第三者（例えば、銀行、または金融サービス業者）の識別、およびユーザの口座を識別するために必要な追加情報である。以下では、トランザクションは、トランザクションを表すレコードＴという用語で表す。即ち、用語「トランザクションＴ」は、トランザクションを表すレコードＴを表すために使用される。
【００５６】
一般に、ユーザにより導出されたデータ列Ｃは電子小切手（支払指図とも呼ばれる）を表し、電子小切手はトランザクションに対する所定の金額を支払うユーザによるコミットメントを含む。一般に、小切手Ｃの名目上の額面価格は、トランザクションＴに対するトランザクション値ＴVである。また、他の情報も、小切手Ｃに含まれる。例えば、ＣはトランザクションＴ（もしくは、トランザクションＴの少なくとも一部）、またはトランザクションＴの表示を含む。本発明の好ましい実施例では、データ列、または電子小切手Ｃ（もしくは、Ｃの少なくとも一部分）が認証される。認証は、（従来技術で既知の）多様な方法により得られる。例えば、小切手Ｃはディジタル署名、もしくはメッセージ認証コードを通して、または認証されたセッションの中で送信されることに基づいて認証される。例えばユーザの要求があるとすぐ、小切手Ｃは、ユーザ以外の関係者（または、ユーザの代理）により認証される。この方法の認証は、ユーザが匿名の購入を行うことを希望する状況で特に有用である。また、当該技術分野で既知の他の認証方式も本発明の範囲内である。
【００５７】
小切手Ｃを生成するとき、ユーザは（ユーザには既知であるが業者には既知でない）秘密情報を使用する。一般に、この秘密情報を知らない者にとって、小切手Ｃを生成することはコンピュータで実行不可能である。本発明の好ましい実施例では、小切手Ｃを生成するプロセスは、公開鍵ディジタル署名システムでのユーザによるディジタル署名の生成を含み、Ｃを生成するためにユーザにより使用される秘密情報は、このシステムでのユーザの秘密署名鍵である。この実施例では、データ列Ｃは、このシステムのトランザクションＴのユーザのディジタル署名（都合よく、ＳＩＧU（Ｔ）と表記される）を含む。ＳＩＧU（Ｔ）は、ユーザの秘密鍵を使用してユーザにより生成される。ユーザは、自分のディジタル署名を生成するために、当該技術分野で既知のディジタル署名方式の１つを使用する。より詳細には、ユーザのディジタル署名方式は、（限定されないが）以下を含む。即ち、決定論的署名方式、無作為化された署名方式、個人情報に基づく署名方式（以上、 Shamir による提案）、オンライン署名方式、オフライン署名方式、および指定された verifier 方式である。また、データ列Ｃも、他の情報（例えば、トランザクションＴについての情報）を含む。
【００５８】
電子小切手Ｃを生成したら、ユーザは業者にＣを受け取らせる。ユーザが業者にＣを受け取らせる多様な方法が存在する。ユーザは小切手Ｃを業者へ単に送るだけでもよい。或いは、ユーザはもう１人の関係者に小切手Ｃを業者へ送ることを頼んでもよい。異なる部分で別の時間に、ユーザは業者に小切手Ｃを受け取らせるか、または小切手Ｃにアクセスさせてもよい。例えば、トランザクションＴが発生する前に、早い時間に、ユーザは業者にユーザの公開鍵を受け取らせるか、またはユーザの公開鍵にアクセスさせてもよい。次に、後の時間に、ユーザは業者にＣ（もしくは、Ｃの一部分）のユーザのディジタル署名、またはＴ（もしくは、Ｔの一部）に関係する数量を受け取らせるか、またはアクセスさせる。
【００５９】
業者は、小切手Ｃが受け取り可能か否か（即ち、小切手Ｃが実際にユーザにより署名されたか否か）、および小切手Ｃの内容が本物かつ完全であるか否かを決定する。これを達成するために、業者は小切手Ｃを生成したユーザに固有の公開確認情報を調べる。このユーザに固有の公開確認情報は、例えば、Ｃを生成するためにユーザが使用した秘密鍵に対応するユーザの公開鍵、またはより一般には、ユーザがマイクロペイメントを行う権限を与えられていること（従って、ユーザのマイクロペイメントは引き受けられるであろうこと）を証明するディジタル証明書である。同じディジタル証明書が両方の目的のため、即ち、ユーザがマイクロペイメントを行う権限を与えられていること、および所定の公開鍵がマイクロペイメント小切手の自分のディジタル署名を確認するために使用されるべきことを表示するために使用できる。業者は、小切手Ｃのディジタル署名が本物であること、即ち、ユーザにより確かに生成されたことを確認するためにユーザの公開鍵を使用する。もしユーザが個人情報に基づくディジタル署名方式を利用するなら、公開確認情報はユーザの個人情報の明細を含む。そのようなユーザに固有の公開確認情報は、ユーザから直接的に業者によって得られる。そのような公開確認情報は、ディジタル証明書から、またはユーザに関して公に利用可能な情報（例えば、公開鍵の刊行された登録簿）から、または小切手Ｃ（または、小切手Ｃの一部）に関係するユーザにより送信された情報から業者によって交互に得られる。「ユーザに固有の公開確認情報」は一般大衆にとって利用可能である必要はなく、業者と銀行にとってだけ利用可能である必要がある。
【００６０】
業者は、入手したユーザに固有の公開確認情報の信頼性をチェックするステップに入る。これらのステップは、（限定されないが）ディジタル署名またはユーザに固有の公開確認情報に関する他の認証情報を確認すること、ディジタル証明書の署名を確認すること、ディジタル証明書の有効期限をチェックすること、およびディジタル証明書が廃棄されたか否かを決定することを含む。また、業者は、ディジタル証明書からユーザが電子小切手Ｃを書く権限を確かに与えられたことを確認し、これは、例えば、小切手の金額、口座番号、シリアル番号、または小切手Ｃの他の情報をさらに含む。
【００６１】
業者は、入手した全ての小切手Ｃをユーザが実質的に予測できない項目Ｖに関連付ける。例えば、項目Ｖはユーザが実質的に予測できない。何故ならば、項目ＶはユーザにとってＣから導出することはコンピュータで実行可能であるからである。即ち、ユーザは、項目Ｖの値を導出するために金額の実行不可能な計算を行う必要がない。本発明の１実施例では、項目Ｖは業者に既知の（しかし、ユーザには既知でない）秘密情報ＳＩを使用してＣから都合よく導出できるだけである。１実施例では、秘密情報ＳＩは、公開鍵ディジタル署名方式の業者の秘密鍵である。
【００６２】
１つの形態では、業者によりＣに関連付けられた項目Ｖは、Ｃに対する業者のディジタル署名（便宜上、ＳＩＧM（Ｃ）で表す）であり、業者によって公開鍵ディジタル署名方式の業者の秘密鍵を使用して生成される。業者により使用されるディジタル署名方式は、Ｃを生成するためにユーザにより使用されたのと同じ署名方式である必要はなく、ユーザ署名方式と異なる署名方式である確率が高い。この状況では、もしＣがＳＩＧU（Ｔ）と等しければ（または、ＳＩＧU（Ｔ）を含めば）、項目ＶはＶ＝ＳＩＧM（Ｃ）により与えられる。従って、ＳＩＧM（Ｃ）はユーザに予測不可能な数量である。何故ならば、ユーザは業者の秘密署名鍵を決して知ることが出来ないからである。従って、たとえユーザが自分が望む何らかの方法（例えば、特定のトランザクションＴを選択すること）で小切手Ｃを管理しても、ユーザに関する限りＳＩＧM（Ｃ）は本質的に「ランダム」である。本発明のもう１つの形態では、Ｖは秘密ＭＡＣ鍵を使用して業者により計算されたＭＡＣ（メッセージ認証コード）値であり、このＭＡＣ鍵は業者と銀行には既知であるがユーザには既知でない。本発明のいくつかの形態では、Ｃの業者の署名はＣの一部分だけ（例えば、Ｃの日付または時間、Ｃに含まれるランダムな列、もしくはＣに含まれるシリアル番号）の業者の署名もしくはＭＡＣ、またはＣに関連する数量を含むように構成される。
【００６３】
項目Ｖを計算するステップは、ユーザからＣを受け取るステップへ時間的に続く必要は必ずしもない。例えば、項目Ｖは、トランザクションＴに関する日付情報の業者のディジタル署名でもよい。業者は、このディジタル署名をＣを受け取る前に既に計算済みである。
【００６４】
本発明の実施例では、業者は選択手続きを、受け取った小切手のどれが支払いに対して「選択」されるべきかを決定するために使用する。業者は「選択された」小切手だけを銀行へ送り、選択されなかった小切手は銀行へ送らない。ユーザが小切手を生成した時間に小切手が業者により選択される否かを決定することは、ユーザにとってコンピュータで実行可能ではない。ユーザが結局はそのような選択手続きについて学ぶ確率が高いが、実際、ユーザは、業者が選択プロセスを使用すること、およびユーザの小切手のほんの一部を銀行へ送ることを意識していても意識していなくてもよい。
【００６５】
選択手続きの一部として、業者は、Ｃに関連付けられた項目ＶがプロパティＰを満たすか否かを決定する。本発明の好ましい実施例では、小切手Ｃが支払いに対して選択されるか否かについての決定は、ＶがＰを満たすか否か次第である。
【００６６】
好ましい形態では、業者に使用される選択手続きは、（選択された各小切手に対して）その選択率、または支払いに対して選択される「確率」を推定することが可能であるような手続きである。より詳細には、選択手続きは、全ての小切手の固定部分を選択するために推定される手続きである。この場合、プロパティＰは定数ｓ（０＜ｓ＜１）に関連付けられ、ｓは所定のマイクロペイメントが実際の支払いに対して選択される確率であり、この確率ｓは一定かつ既知である。或いは、ＶはＰを、データ列Ｃ（もしくは、その一部）、レコードＴ（もしくは、その一部）、またはデータ列ＣとレコードＴの組合せから決定できる確率で満たしてもよい。換言すれば、選択される小切手の一部は、小切手Ｃユーザにより供給されたパラメータに依存する。例えば、それは小切手の金額に依存する。或いは、値ｓは、ユーザの公開鍵をユーザに結び付けるユーザのディジタル証明書の内部で指定される。或いは、プロパティＰは、項目Ｖの値の一定部分を保持することを保証される。或いは、プロパティＰは、Ｖのある部分Ｆに対して保持することを保証され、ここで部分Ｆはデータ列Ｃから、レコードＴから、ＣとＴの一部から、またはＣとＴの組合せから決定できる。或いは、業者は、ｓおよび／またはプロパティＰを決定するために使用できる銀行から情報を得る。
【００６７】
プロパティＰは、事前に（即ち、トランザクションＴが発生し、小切手ＣがＴから導出される前に）指定されてもよい。そのようなプロパティＰの実施例は、「ｘより小さい数に対応するＶの最後の１０ビット（ここで、ｘは定数）」である。或いは、プロパティＰは、トランザクションＴ、小切手Ｃ、またはそれらの組合せの中で指定される（または、得られる）。そのようなプロパティＰの実施例は、「Ｃの最後の１０ビットに対応する数より小さい数に対応するＶの最後の１０ビット」である。選択率ｓが決定される方法は上記方法の組合せ、または当業者には明らかな上記方法の変形を含む。
【００６８】
１つの形態では、ＶがＰを満たすか否かを決定するために、業者は業者にだけ既知の秘密情報ＳＩを使用してもよい。そのような秘密情報ＳＩは、例えば、公開鍵ディジタル署名方式の業者の秘密鍵、公開鍵暗号システムの業者の秘密鍵、または公開鍵ディジタル暗号化方式の業者の秘密鍵を含む。業者のディジタル署名アルゴリズムは、決定性であることが好ましい。
【００６９】
本発明の１実施例では、プロパティＰは次の形態を取る。
Ｆ（Ｖ）＝Ｆ（ＳＩＧM（Ｃ））＜ｓ （１）
ここで、Ｆ（ ）は、入力として任意のビット列を取り出力として０と１の間の１つの数字を戻す公開関数を表し、sは０より大きく１より小さい定数であって、マイクロペイメント方式に対する選択率（即ち、支払いに対して所定の小切手Ｃが選択される確率）を表す（または、少なくとも決定する）。１実施例として、Ｆは２進入力列Ｖに「０」と「．」を前に付加し、２進数としての結果を解釈することにより作用する。この実施例では、もしＶが入力列「０１１」なら、ＦはＶに作用して「０．０１１」をもたらし、「０．０１１」は１０進分数３／８として解釈される。上記のように、ＳＩＧM（Ｃ）は本質的にランダム（予測不可能な）数字なので、Ｆ（ＳＩＧM（Ｃ））も、０と１の間のランダムで十分に長い数字である。従って、Ｆ（ＳＩＧM（Ｃ））は率ｓより小さく、従って、プロパティＰは、ユーザが業者に受け取らせた全ての小切手Ｃの小数部ｓに対して本質的に満たされる。もう１つの実施例では、関数Ｆはハッシュ関数、または他の決定性関数を入力に最初適用し、既に述べたように「０」と「．」を前に付加することにより続行し、結果を２進数として解釈する。もう１つの実施例では、プロパティＰは次の形態を取る。
Ｆ(Ｖ)=Ｆ（ＳＩＧM（Ｇ（Ｃ）））＜ｓ （１'）
ここで、Ｇ（ ）は、データ列を生成するために小切手に適用される関数を表す。例えば、関数Ｇは、小切手Ｃのシリアル番号をただ戻すだけである。
【００７０】
小切手が支払いに対して選択されるべきか否かを決定するために業者がユーザと対話する必要がないことは、強調されるべきである。プロパティＰが方程式（１）により決定される場合、業者が小切手Ｃが払い可能か否かをすぐ決定できることは容易に分かり、業者は自分の秘密署名鍵を使用してＦ（ＳＩＧM（Ｃ））を容易に評価でき、Ｆ（ＳＩＧM（Ｃ））を選択率ｓと比較できる。Ｆ（ＳＩＧM（Ｃ））がユーザが実質的に予測できないことは極めて重要であり、また、十分正確な数字でなければならない。実用的に適度な選択率（例えば、１／１２８、または１／１０２４）に対して、ＳＩＧM（Ｃ）およびＦ（ＳＩＧM（Ｃ））は１０ビット長で十分である。その代わり、一般的なディジタル署名は、数百ビット長であり、従って、過剰を表す。
【００７１】
本発明のこの実施例では、いったん業者自身が項目Ｖ（例えば、ＳＩＧM（Ｃ））はプロパティＰを満たさないと決定したら、業者は銀行を情報Ｉにアクセスさせ、情報Ｉは銀行もＶがＰを満たすか否かを確認することを可能にする。本発明の典型的な実施例では、情報ＩはＳＩＧM（Ｃ）を生成するために使用された秘密鍵に対応する業者の公開鍵、またはその公開鍵に対する業者の証明書を含む。また、情報Ｉも、Ｃの業者のディジタル署名（即ち、Ｖ、またはＳＩＧM（Ｃ））を含む。小切手Ｃがさらに発生する前に、業者は情報Ｉの一部が銀行によりアクセスされるようにする。例えば、業者は銀行に過去の自らの証明書を与え、銀行はそれを記憶する。もし業者が電子小切手Ｃから導出された項目ＶはプロパティＰを満たさないと決定したら、業者は単に小切手Ｃを廃棄する。銀行は、小切手Ｃを決して見ない。しかし、もし小切手が適切に作られたら、たとえ支払いに対して選択されなくても、業者はユーザに小切手が買おうとしていた商品／サービスを今まで通り普通に供給する。（Ｃに関連付けられた）ＶがプロパティＰを満たすそれら小切手Ｃだけが業者による支払いに対して選択されて、銀行に転送される。従って、銀行は、ユーザにより行われたマイクロペイメントの一部に対してのみ働かされる。
【００７２】
銀行は、ユーザにより作り出され業者により受け取られた小切手の小数部ｓを見るだけなので、支払い金額の調整は、「見当たらない」（選択されない）小切手の（少なくとも大体の）値を説明するように行われる必要がある。そのような調整を行うことへの１アプローチでは、預金のために銀行へ転送される各小切手は、小切手Ｃの名目上の額面価格ＴVの１／ｓ倍の値を有する「マイクロペイメント」になる。ｓが可変であるとき、適切なｓはＣを選択するために使用される手続きに関連するｓである。例えば、もしｓが１／１０００で、トランザクション値ＴVが１セントならば、平均して１０００マイクロペイメントの中から１つだけが支払いに対して選択され、１０００マイクロペイメントの中の９９９が廃棄される。１０００セント（または、１０ドル）の支払いが、選択されたマイクロペイメントに対して行われる。この方法で、単一処理コストだけが１０００マイクロペイメントの各々に対して負わされ、（平均して）処理コストにおける大きな節約という結果になる。
【００７３】
業者から受け取った各小切手Ｃに対して、銀行は小切手Ｃが支払いに対して確かに選択されたか否かを情報Ｉ（例えば、業者のディジタル署名方式の業者の公開鍵）を使用して確認する。換言すれば、業者から受け取った各小切手Ｃに対して、銀行もＶがプロパティＰを満たすか否かを情報Ｉを使用して確認する。もし銀行がＶはプロパティＰを確かに満たすことを確認したら、銀行は業者（または、指定された業者以外の第四者、ユーザ、もしくは銀行）にマイクロペイメントの値に対応する総額を受け取らせる。一般に、銀行はユーザの口座から業者の口座（または、指定された第四者の口座）へ支払いが行われるようにする。
【００７４】
銀行は、任意におよび／または自らの方針により、特定の状況下（例えば、ユーザの口座が滞っているとき、ユーザの証明書が無効なとき、または業者もしくユーザが何らかの詐欺を企てた疑いがあるとき）で小切手に対する支払いを拒否できる。例えば、銀行は、もし業者が同じ小切手を２回提出したら、支払いが最大１回行われることを保証するステップを取る。銀行は、以前に手続きされた小切手に支払うことを拒否できる。また、銀行は、ユーザが小切手を賄うために十分な資金を自分の口座へ預金するまで、支払いに対する小切手を保持する選択も出来る。
【００７５】
本発明の第１の実施例で開示されるマイクロペイメント方式は４つの関係者（第一者、第二者、第三者、および第四者）を含み、４つの関係者全ては完全に別である。実施例として、第一者は料金所を通過するユーザであり、第二者は料金所の装置であり、第三者はユーザの銀行であり、および第四者は高速道路所有者である。或いは、第一者は歌をダウンロードするユーザであり、第二者は歌のプロバイダであり、第三者はユーザの銀行であり、および第四者は音楽ディストリビュータである。或いは、第三者は第一者（即ち、ユーザ）の銀行であり、および第四者は第二者（即ち、業者）の銀行である。この場合、第二者の利益のために、第二者はユーザの銀行に第二者の銀行への支払いを行わせる。また、（第一者、第二者、第三者、および第四者以外の）追加の関係者も、本発明のマイクロペイメント方式に含まれる。例えば、第一者（ユーザ）は小切手Ｃを第二者へ送り、第二者は（もし、プロパティＰがＶに対して有効であれば）項目Ｖをユーザの銀行である第三者へ転送する装置である。ユーザの銀行（第三者）は第四者に支払い、第五者である受益者の利益に対して、第四者は受益者の銀行である。
【００７６】
支払いの金額は、小切手の名目上の額面価格（ＴV）と小切手が支払いに対して選択される推定確率ｓの両方に依存する。（ユーザの口座から業者の口座への）支払いの金額は、（小切手が選択される推定確率ｓの逆数(１／ｓ)を乗ぜられ、銀行がユーザと業者にそれぞれ請求する適切な銀行手数料で調整された）小切手の名目上の額面価格により与えられる。
【００７７】
上記のように、マイクロペイメント方式は、低額商品（例えば、ウェブ記事、またはウェブページ）の購入を可能にするために非常に有用である。従来技術では、ユーザが低額商品を購入することを可能にするために、加入法が広く使われてきた。例えば、ウェブサービスに加入することにより、ユーザは基本的に多くの将来の低額トランザクションを単一のマイクロペイメントに集約する。しかし、このやり方は、ユーザにとって最適ではない。何故ならば、もしユーザが現在特定の商品に興味があるが、将来の商品を欲すること（または、アクセスする必要があること）を確信してなければ、加入の価格はユーザが払う気がある価格以上だからからである。その結果、業者はいくつかの取り引きを失うかもしれない。何故ならば、ユーザは加入（即ち、マイクロペイメントを「前もって」作成すること）を購入しないことにしてもよく、所望する商品を断念してもよいからである。
【００７８】
本発明の第１の実施例で開示されたように、確率的マイクロペイメント方式は、加入と個々の取り引きを橋渡しする方法で、次のように拡張される。業者は、ユーザに２つのオプションを提供する。即ち、１）ユーザが多くの商品を所定の時間間隔の中で得ることを可能にする加入（例えば、加入は、買い手に業者の全てのウェブページへのアクセスを１年間にわたって提供する）、および２）アラカルトな個々の商品である。ユーザは、その申告価格ＴVにより個々の商品を単体で買うことを決めてもよい。ユーザは業者にＴVの額面価格を有する確率的小切手で支払い、業者はユーザに所望する商品を提供する。しかし、もし確率的小切手が選択されたら、小切手は業者にはるかに高い金銭的価値を実際には受け取らせる。例えば、個々の小切手が支払いに対して選択される確率が１／１０００である場合、Ａ＝ＴV＊１／ｓ（ここで、ｓ＝１／１０００）である。業者に受け取られる金額Ａは、業者の加入サービスのコストを超える。この場合、ユーザは加入権を無料で得ることにより報われる。もし加入のコストがＡより高ければ、ユーザはＡを業者から加入権を購入するコストに対するクレジットとして得ることにより報われる。
【００７９】
加入と個々の取り引きを橋渡しする上記の方法は、いくつかの追加的報奨をユーザに提供する。簡単にするだけのために、全ての商品は同じコスト（例えば、１セント）を有すること、１０ドル掛かること、および確率的小切手は１セントの額面価格を有するが、支払いに対して選択されたら、（潜在的方式で選択される確率は１／１０００なので）実際にはユーザに１０ドル費やさせることを仮定する。ユーザは、自分の小切手のうち平均して１０００に１つだけが支払い可能になること、実際に１０ドル払うとき、加入権を無料で入手できることが分かる。従って、ある意味で、ユーザは加入権を購入すべきか否か、または商品をアラカルトに選ぶべきか否かを決めることは決してない。ユーザは、アラカルトなままでもよい。何故ならば、ユーザは商品を無料で得るか、または商品に対して支払いを行うが、見返りに加入権を無料で有するかの何れかになるからである。この方法では、たとえユーザが１セントの購入を１０００回行うすっと以前に１０ドル支払わされても、マイクロペイメント方式はユーザに対して常に公平で魅力的である。また、プロセスも、業者にとって魅力的である。何故ならば、他の方法では、どんな方法でも業者は加入権を買うとは考えられない顧客を失うからである。また、もしユーザが取引する価値が十分あると考え出したと業者が感じたら、業者は、加入権の割り当てられたコストを含むように額面価格ＴVを１ビット以上に調整できる。
【００８０】
図２は、トランザクションＴに対する支払いを本発明の１実施例により確立するためのマイクロペイメント・システム１００の構成要素を示す略ブロック図である。システム１００は、ユーザ、業者、および銀行が電子データを送信すること、および彼らの間での支払いさえ可能にする通信手段１１０を含む。電子データは、電子小切手を表すデータ列、またはメッセージを表す列を含む。１実施例では、通信手段１１０がリモート・サーバへのアクセスを可能にする。通信手段１１０は、モデム、および（限定されないが、ネットワーク・インターフェースカードを含む）当該技術分野で既知の１または複数のネットワーク・インターフェース装置を含む。通信手段１１０は、異なるネットワーク・ノード間のデータ転送を可能にするバス（例えば、アドレスバス１１４、およびデータバス１１５）を含む。
【００８１】
また、システム１００は第１処理手段１０５、および第２処理手段１０６も含む。第１および第２処理手段はコンピュータシステム（例えば、 DOS または Windows オペレーティングシステムを動作させるディジタルコンピュータ）であり、アドレスバス１１４とデータバス１１５に接続される。各処理手段１０５，１０６は、データを記憶するための記憶手段１２１、データを入力するための入力手段１２２、およびシステム命令を実行する中央処理装置（ＣＰＵ）１２３を一般に含む。記憶手段１２１は、コンピュータメモリ、データ記憶装置（例えば、ハードディスク）、ＣＤ−ＲＯＭ、および同様のものを含む。入力手段１２２は、当該技術分野で既知の入力装置（例えば、従来のキーボード）である。
【００８２】
第１処理手段１０５は、トランザクションＴに関するデータ列Ｃを導出し、入力し、記憶するために第一者によって機能する。第２処理手段１０６は第二者によって動作させられ、項目ＶをＣの少なくとも一部分に関連付けるためにＣに応答する。また、第２処理手段１０６も、ＶがプロパティＰを満たすか否かを決定するために機能する。例えば、１組の命令は第２処理手段１０６のＣＰＵ１２３に入力され、ＣＰＵにＣ（または、Ｃの一部分）に関連付けられた項目Ｖを導出させ、およびＣＰＵ１２３にＶがプロパティＰを満たすか否かを決定させる。これは、次のステップがＣＰＵ１２３により実行される（即ち、第三者がＶがＰを満たすか否かを確認することを可能にする情報Ｉの第三者（銀行）への転送の命令）ために満たされなければならない必要条件である。ＣＰＵ１２３は、情報Ｉを第三者へ送信するために、ＶがＰを満たすときに選択的に機能するようにプログラムされる。
【００８３】
また、システム１００は、第四者に総額を受け取らせるために、（ＶがＰを満たすときに第三者により選択的に機能する）手段１４０も含む。また、手段１４０はコンピュータシステムであり、第四者への支払いの転送を命令するために、ＶがＰを満たすときに選択的に機能するようにプログラムできるＣＰＵを有する。
【００８４】
要約すると、本発明の第１の実施例で開示されるマイクロペイメント方式は、処理コストを最小化し、ユーザと業者の対話の必要性を解消し、相対的に大きな数のマイクロペイメントが発生する期間にわたってほぼ正しい期待値を各関係者が支払うか、または受け取ることを可能にする。
【実施例２】
【００８５】
ＩＩ．時間の制約を含むマイクロペイメント・システム
異なる変形が、上記第１の実施例で提示される非対話型フレームワークの中で可能である。より詳細には、本発明の第２の実施例では、時間の制約が取り入れられる。先の節に記載されるように、マイクロペイメント方式は、業者が支払い可能な小切手をいつでも預けることを可能にする。しかし、多くの場合、時間情報が適切なトランザクションが発生した時間から所定の時間間隔内に提示された小切手であることを示す支払い可能な（即ち、適切に選択された）小切手を業者が提示するまで、業者の口座を信用することを拒否する能力を有することは、銀行にとって有利である。
【００８６】
本発明の第２の実施例では、一部分が時間ｔによって特徴付けられるトランザクションＴに対する支払いをユーザが確立することを可能にするマイクロペイメント方式が提示される。一般に、時間ｔは、トランザクションＴが発生した時間および／または日付を表す。図３は、本発明の第２の実施例によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図である。ユーザはデータ列をＴから、または電子小切手ＣをトランザクションＴから導出する。第２の実施例では、小切手Ｃ（または、Ｃが参照するトランザクションＴ）は、トランザクションＴの時間ｔに関する情報ＩＮを含まなければならない。
【００８７】
ユーザは、業者にＩＮを含むＣの少なくとも一部分を受け取らせる。Ｃの一部分を受け取るとすぐ、業者はＣをユーザが実質的に予測できない項目Ｖに関連付ける。本発明のこの実施例では、実質的に予測できない項目Ｖは、Ｔの時間ｔで定義される。例えば、Ｖは公開ディジタル署名方式で業者の秘密鍵を使用して生成され、ＳＩＧM（Ｃ）（即ち、情報をｔに含むＣ（または、Ｃの一部分）に対する業者のディジタル署名）により与えられる。後者の場合、より正確にはＶ=ＳＩＧM（Ｇ（Ｃ））であり、ここで、ＧはＣについての時間情報を戻すＣの関数である。
【００８８】
また、パラメータｓ、および 関数Ｆ，Ｇは、Ｖが満たすべきプロパティＰを決定するためにマイクロペイメント方式でも使用できる。パラメータｓ、および関数Ｆ，Ｇが指定される方法、ならびにプロパティＰが指定される方法は、前節で記載されたｓ，Ｆ，およびＰを指定する方法に類似の方法で変化してよい。例えば、小切手Ｃ（または、Ｃが参照するトランザクションＴ）は、Ｃに関連する適切な値Ｖと一緒に使用されるプロパティＰを直接的に指定できる。例えば、関数ＦはプロパティＰを決定でき、Ｐは以下により与えられる。即ち、
Ｆ（Ｖ）＝Ｆ（ＳＩＧM（Ｃ））＜ｓ
ここで、ｓは０と１の間の１つの数字であり、この方式の支払いに対して所定の小切手Ｃが選択される確率を表す。
【００８９】
本発明の第２の実施例では、業者の署名は、Ｃの全てに適用されるより、Ｃの関数Ｇに適用されるだけである。即ち、プロパティＰ以下により与えられる。
Ｆ（Ｖ）＝Ｆ（ＳＩＧM（Ｇ（Ｃ）））＜ｓ
重ねて、関数Ｇは複数の方法の１つで指定できる。例えば、関数Ｇは一定でもよく、Ｃにより指定されてもよく、対応するトランザクションＴにより指定されてもよく、（例えば、業者、またはユーザの）証明書により指定されてもよく、または銀行に提供された他の情報で指定されてもよい。
【００９０】
特に有用な関数Ｇは、Ｃの時間情報ＩＮを戻す関数である。この方法で、（ユーザが実質的に予測できない）項目Ｖは主にトランザクションＴの時間ｔの関数であり、従って、プロパティＰは、主にトランザクションＴの時間ｔに依存する。Ｇにより抽出された時間情報はｔに関連付けられるが、ｔと一致する必要はないことに注意すべきである。例えば、ｔはＴの日付、時、および分を指定するが、Ｇは異なる細分性を有する時間表示を戻す。例えば、Ｇはｔ自体を指定できるが、日付（もしくは日、および分ではない時）またはｔの後の時までである。本発明の第２の実施例では、業者に署名される値Ｇ（Ｃ）は、時間情報を含むように常に構成されるべきである。
【００９１】
ＶがＰを満たすこと（これが真である場合）、および小切手が他のテストをパスすること（例えば、もし存在するなら、ユーザ署名が有効である）を決定した後、時間ｔ'に業者はＴの時間ｔに関する情報ＩＮの全て（または一部）を銀行に受け取らせる。業者は、Ｃの全て（または、ＩＮを含む小切手Ｃの少なくとも一部）を銀行に提示する。また、業者は、銀行に（銀行がＶがＰを満たすことを独自に確認することを可能にする）情報Ｉを受け取らせる。業者は、Ｖが計算される前に、銀行にＩの一部を受け取らせることが出来る。ＩＮの適切な部分を受け取った後、銀行はｔ'（即ち、業者が小切手を銀行に提示した時間）がｔに十分近いか否かを決定できる。もし経過時間｜ｔ'−ｔ｜が予め定められた時間より大きければ、銀行は小切手Ｃを廃棄する。また、他の条件（例えば、小切手Ｃのユーザ署名が確認されないとき、ユーザの口座が滞っているとき、またはユーザおよび／または業者に詐欺の疑いがあるとき、など）が有効なら、銀行は支払いを任意に（または自らの方針により）拒絶するか遅らせることができる。
【００９２】
Ｉを使用して、銀行はＶがＰを満たすことを独自に確認する。ＶがＰを確かに満たし、（例えば、｜ｔ'−ｔ｜が所定の時間間隔より小さいという）全ての他のテストがパスした場合にのみ、銀行は業者（または、他の第四者）に総額を受け取らせる。予め定められた時間間隔は、例えば、１日、１週間、または所定の数時間である。
【００９３】
１実施例として、もし小切手Ｃが参照するトランザクションＴが日付ｉに発生したら、マイクロペイメント・システムは、日付ｉの終わり、または日付ｉ＋１の終わり、または日付ｉ＋ｎの終わりまでに業者が小切手を預けることを要求する（ここで、ｎは、業者が預金することを約束した日数を表す整数である）。このタイプの要求は追加の報奨金を与えて業者に受け取った小切手の時間の正確さを確認させ、受け取った小切手の時間の正確さは、追加のセキュリティ上の利益を業者に提供する。
【００９４】
１つの形態では、もしｔ1はユーザが業者にＩＮを含むＣの一部分を受け取らせる時間を表すなら、時間ｔ1が定められた時間の制約の範囲内でなければ、業者は手続きを断る。そのような場合、業者は注文された「商品」（例えば、品物、サービス、または情報）を提供することを断れる。また、適時な預金は、ユーザが余りに遅く（即ち、可能な支出がユーザの支払い口座にもはや無いとき）請求されることはないことを保証する。
【００９５】
Ｇ（Ｃ）をより詳細に参照すると、Ｇ（Ｃ）はＣ（または、Ｃが参照するトランザクションＴ）の日付および／または時間情報を戻す関数である。例えば、もし日付が２００１．０１．０１なら、ＶはＳＩＧM（２００１．０１．０１）から成る。もし業者がその日付に署名したことがなければ、これは、ユーザが実質的に予測できない。この場合、Ｖが満たさなければならないプロパティＰは、ＳＩＧM（２００１．０１．０１）またはＦ（ＳＩＧM（２００１．０１．０１））を、Ｃ、Ｃの一部分、Ｃの関数、または予め指定された定数と比較することを含む。例えば、そのようなプロパティＰの１つは次のように定式化される。即ち、ＳＩＧM（２００１．０１．０１）の選択されたｍビット部分列は、Ｃの選択されたｍビット部分列と一致するか？
【００９６】
ＶをＣに関連付ける上記の方法は多数の長所を有することが銘記されるべきである。より詳細には、業者はＳＩＧM（２００１．０１．０１）を、２００１年１月１日にユーザからＣを受け取る前に計算できる。従って、いったんその日にＣが受け取られたら、Ｐが必要とされるプロパティＰを満たすか否かを業者はもっと素早く確認できる。例えば、もしＰがＦ（ＳＩＧM（２００１．０１．０１））＜ｓ（ｓは定数）から成れば、ＰはＶだけに依存し、さもなければ小切手に依存しない。従って、業者は２００１年１月１日の前でさえＰが今回限り有効であるか否かを決定できる。もしＰが確かに有効なら、業者は（それ以上確認することなく）その日に受け取った全ての小切手を支払いのために銀行へ転送できる。もしＰが有効でないなら、業者は（それ以上確認することなく）その日に受け取った全ての小切手を廃棄する。この方法で、業者が実行する署名の数は最小化される。
【００９７】
或いは、プロパティＰは、ｍビット（例えば、１０ビット）のＳＩＧM（２００１．０１．０１）が、ユーザがＣに含む所定の１０ビット列と一致するか否かを含む。この場合、プロパティはＶと小切手Ｃの両方に依存するが、Ｐが有効か否か決定することは殆ど直ぐである。実際、ディジタル署名の計算はより複雑であうが、業者はＳＩＧM（２００１．０１．０１）を２００１年１月１日、またはそれ以前に１回だけ計算する必要があり、署名（または、署名のｍビット）を記憶する。この方法で、小切手毎に要求される業者の労力は、２つの１０ビット列の些細な比較だけから成る。これは、業者が銀行に（小切手が受け取られる前でさえ支払いに対して所定の小切手が選択されることを銀行が独自に確認することを可能にする）情報Ｉの全てを受け取らせることを可能にする。例えば、業者はＳＩＧM（２００１．０１．０１）を２００１年１月１日の始め（または、それ以前）に送信し、次に２００１年１月１日に関する全ての小切手を銀行へ送る。しかし、便利ではあるが、これは業者にとって賢明ではない。何故ならば、もし悪意のユーザが２００１年１月１日の間にＳＩＧM（２００１．０１．０１）を手中に収めたら、悪意のユーザは支払いに対して決して選択されない小切手をその日に書けるからである。このアプローチの（当業者には明らかな）多くの変形（例えば、１日の代わりに１時間の時間細分性を使用する）が存在する。
【００９８】
１つの形態では、本発明の第２の実施例は、小切手Ｃの時間／日付情報を使用して、一連の値ＶＬiを導出することにより、業者が（ユーザが実質的に予測できない）項目を関連付けることを可能にする。業者は、一連の時間ｔi（ｉ＝１，．．．，ｎ）に関連付けられた一連の値ＶＬiを導出し、ｔiの少なくとも１つは、トランザクションＴの時間ｔに所定の方法で関連付けられる。例えば、少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、｜ｔ−ｔm｜が、予め定められた値（例えば、１日）より小さい。或いは、少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、ｔ−ｔm（または、ｔm−ｔ）は正であり、１日を越えない。ユーザは業者に、（トランザクションＴの時間ｔに関する情報を含む）Ｃの少なくとも一部分を受け取らせる。
【００９９】
次に、業者は、プロパティＰがＣの一部分と値ＶＬmの間で、またはＣの一部分と（ｔmに関連する値ＶＬmに依存する）数量Ｑの間で有効であるか否かを決定する。もし、そうなら、業者は銀行に（銀行が、プロパティＰが満たされていることを確認することを可能にする）情報Ｉを受け取らせ、銀行が適切な貸方および借方を行えるようにする。
【０１００】
１つの形態では、Ｃの日付情報を使用して、一連のハッシュ値を生成することにより、業者は（ユーザが実質的に予測できない）項目Ｖを各小切手Ｃに関連付ける。この形態では、業者は一連の値を生成する。
ｗ0，ｗ1，．．．，ｗn
ここで、ｗi＝ｈ（ｗi+1）であり、ｈは一方向関数であり、およびｗ0を自分の公開ファイルに入力するか、ディジタル的に署名するか、さもなければ公開する。従って、業者は、ｗi+1をｉ番目の日付／時間単位に関連付ける。たとえ業者が先の時間単位に関連する全ての商品を明らかにしても、関連する項目ｗi+1は予測不可能である。最初のｉ項目は時間単位ｉで公開されるが、ｗi+1は実質的に予測できない。何故ならば、ｗi＝ｈ（ｗi+1）を知るだけではｗi+1を計算できないからである。業者が時間／日付情報ｉを有する小切手Ｃに関連付ける予測不可能な項目Ｖは、ｗi+1（即ち、時間／日付情報のｉ番目の hash inverse ）である。次に、プロパティＰが多様な方法で定式化される。１実施例として、もしｗiの最初の１０ビットがＣの選択された１０ビットと等しければ、プロパティＰは満たされる。情報Ｉ＝ｗiを単に公開するだけで、業者は銀行にプロパティＰが有効か否かを確認させることが出来る。銀行はｗiをｉ回ハッシングし、結果が業者のｗ0と一致するか否かを見ることによりｗiを確認でき、次にＰが有効か否かを確認する。
【０１０１】
もし業者が小切手の日付／時間情報に関連付けられた予測不可能な項目Ｖを使用したら、業者は廃棄した小切手、および所定の日付／時間単位の間にクレジットに対して除外した小切手についての情報を隠した方がよいことを銘記すべきである。さもなければ、悪意のユーザは時期尚早に値Ｖを発見し、例えば、選択されないことが分かっている小切手を生成することにより、この情報を自分に有利に使用するかもしれない。業者は、所定の日付／時間単位の「選択された」支払い可能な小切手の全てを除外し、全ての選択された小切手を銀行へ最後の日付／時間単位に送るのが好ましい。この方法では、たとえ悪意の銀行でも、ユーザと共謀して業者から搾取することは出来ない。また、スマートカード、携帯電話、またはどの小切手が支払いに対して選択されるかを決定するために多様な小切手をユーザが自由に生成およびテストすることを困難または不可能にする他の装置を利用することをユーザに要求することにより、セキュリティも向上した。
【実施例３】
【０１０２】
ＩＩＩ．ユーザのリスクを解消する選択的デポジット・プロトコルを含むマイクロペイメント・システム
ユーザが前もって知らず、支払いに対して選択される小切手を管理しない確率的支払い方式の特色を示す。本発明の実施例では、これまで記載したように、ユーザは実際の支出額を超える金額（即ち、ユーザが書いた小切手の総計を超える金額）を借方に付けられることがある。従来の確率的支払い方式では、もし小切手Ｃiが確率ｓで支払い可能であると選択されたら、一般にユーザはトランザクション値ＴＶi以上を借方に付けられ、多くの 確率的方式では、一例としてユーザは金額（ＴＶi＊１／ｓ）を借方に付けられる。従って、もし各トランザクションＴiが同じ値ＴＶi＝ＴＶを有し、不運により（１つより多い）２つ以上のユーザの最初の１／ｓ小切手が支払い可能になれば、ユーザは実際の使った金額の少なくとも２倍の金額を借方に付けられる。ｓが大きいとき、これはユーザのおよそ４分の１に対して起こることが予想される。
【０１０３】
本発明の第３の実施例では、選択的デポジット・プロトコルが開示され、選択的デポジット・プロトコルは、ユーザリスクの問題（即ち、不運により、ユーザが実際に書いた小切手の合計値より多くユーザが請求される可能性）を解決する。ユーザリスクの問題は、確率的マイクロペイメント方式（例えば、 Rivest の 電子抽選方式、および前節で開示されたマイクロペイメント・システム）に固有のものである。例えば、確率的方式に対する選択率ｓは１／１０００でもよいが、不運により、支払いに対してユーザの最初の１０００の中の（１より大きい）５の支払いが選択されることがある。ユーザが余計に請求される確率は小さく、ユーザリスクの相対的効果は行われたマイクロペイメントの数と共に劇的に減少するが、ユーザリスクは、確率的マイクロペイメント方式が広く普及することへの大きな障害を構成する。これは、大きな組織（例えば、銀行）とは異なり、一般のユーザがリスク管理に慣れていないからである。従って、以下に記載される第３の実施例の方式が、潜在的確率支払い方式を改善する。
【０１０４】
図４は、ユーザの支払い過ぎに対するリスクを解消する選択的デポジット・プロトコルを含む本発明によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図である。この実施例では、トランザクションの一連のＴi（ｉ＝１，．．．，ｎ）に対する支払いをユーザに可能にさせる方法およびシステムを開示する。一般に、各トランザクションＴiは、非常に小さい（例えば、１セント、または１セントの何分の１）トランザクション値ＴＶiにより特徴付けられる。従って、もし銀行が単一のトランザクションＴi毎に処理しようとしたら、銀行はトランザクション値ＴＶi自体よりはるかに大きい処理コストを負う。
【０１０５】
従って、確率的マイクロペイメント方式（例えば、 Rivest の抽選方式、または前節で開示された方式の１つ）が、各Ｔiに対して小切手／マイクロペイメントＣiを生成するためにユーザに使用でき、Ｃiは業者にトランザクションＴiに対する支払いとして送られる。次に、０より大きく１より小さい確率で、Ｃiは支払いに対して選択されるか否かが、ユーザと業者の対話による Rivest の抽選方式で、または非対話的に業者だけによる前節で記載された方式での何れかで決定される。
【０１０６】
図４を見て分かるように、各Ｃi（ｉ＝１，．．．，ｎ）に対して、ユーザは業者にＣiを受け取らせる。業者が受け取る各Ｃiに対して、潜在的確率方式により、どの小切手が支払いに対して選択されるかをユーザが前もって予測できない方法で、業者はＣiは選択されるか（即ち、支払い可能か）否かを決定する。例えば、潜在的確率方式は上記第Ｉ節に記載された方式でもよく、その場合、項目ＶiをＣiに関連付けること、およびＶiがプロパティＰiを満たすか否かを決定することにより、業者は支払い能力を決定する。業者は他の条件（例えば、Ｃiのユーザ署名は有効か否か、小切手の金額は大きすぎないか、など）できるだけチェックし、これらの条件のいくつかはユーザの証明書で指定される。もし業者がＣiは支払い可能でないと決定したら、業者はＣiを廃棄する。もし業者がＣiが支払い可能であると決定したら、業者は銀行に情報Ｉiを受け取らせ、情報Ｉiは銀行に選択された小切手Ｃiは支払い可能であるということを確認させる。銀行はＩiを使用して、Ｃiは支払い可能であるということを確認する。Ｃiが支払い可能である場合にのみ、銀行は業者に掛売金額ＣＲiを受け取らせ、ユーザの借方に金額Ｄiを付ける。
【０１０７】
本発明の第３の実施例では、Ｄiは、ユーザの借方に付けられた合計金額Ｄ＝Ｄ1＋Ｄ2＋．．．＋Ｄiがユーザが書いた小切手の合計金額Ｔagg＝ＴＶ1＋ＴＶ2＋．．．＋ＴＶiを超えない位のものであることを銀行は保証しなければならない。換言すれば、整数ｉ（１≦ｉ≦ｎ）に対するｉトランザクションにユーザが関係した後にユーザの借方に付けられた合計金額は、ユーザが業者から購入したトランザクションＴ1，．．．，Ｔiの合計値を決して超えてはならない。
【０１０８】
好ましい形態では、Ｄ＝Ｄ1＋Ｄ2＋．．．＋ＤiがＴaggより大きくないことを、小切手からのシリアル番号を使用して保証する方法で、銀行はＤiを決定する。この形態では、潜在的確率支払い方式でユーザにより生成された複数の小切手Ｃi（ｉ＝１，．．．，ｎ）の各々は、シリアル番号Ｓiを含む。これらシリアル番号Ｓiは、１から始まる連続する整数であることが好ましい。また、ｉ番目のシリアル番号は、他のトランザクション（Ｔ1，．．．，Ｔi-1、およびＴi+1，．．．，Ｔn）ならびに他の小切手（Ｃ1，．．．，Ｃi-1、およびＣi+1，．．．，Ｃn）に対するトランザクションＴiおよび小切手Ｃiの時間順を表すのが好ましい。
【０１０９】
シリアル番号Ｓiは、トランザクションＴiおよび／または小切手Ｃiに関連付けられるインデックスｉの表示を提供する。しかし、順序付けられているが連続していないシリアル番号も使用できる。例えば、所定の番号Ｐの後に。ｉ番目の小切手をｉ番目の素数に関連付けてもよい。簡単にするために、各トランザクションＴiが同じトランザクション値ＴＶ=ＴＶiを有する場合が最初に記載される。また、後でより詳細に論じるように、第３の実施例も、トランザクションＴiが異なる値ＴＶiを有する場合を含む。
【０１１０】
銀行（または、もう１つの第五者）は、支払いに対して選択されてきた小切手のシリアル番号を監視する。支払い可能な小切手Ｃiの借方金額Ｄiを決定するために、第三者／第五者は値Ｓmaxを使用し、Ｓmaxは、支払いに対してこれまで提示された最新の小切手に載るシリアル番号を表す。シリアル番号が１から始まって順番に使用される場合、値Ｓmaxはゼロに初期化される。小切手のシリアル番号は連続的に順序付けられるので、Ｓmaxは支払いに対して以前に提供されてきた小切手に載る最大のシリアル番号である。また、シリアル番号の連続的順序のために、Ｓmaxは、現在支払い可能な小切手Ｃiのシリアル番号Ｓiより小さくない。図４に示されるように、ユーザはこの小切手に対して（例えば、第五者により）ある金額を借方に付けられる。
Ｄi＝（Ｓi−Ｓmax）＊ＴＶ （１）
要するに、ユーザが自分が書いた小切手の全てに対して借方に付けられた合計金額ＤはＳi＊ＴＶである。もし不連続なシリアル番号が使用されたら、Ｄi＝＃（Ｓi−Ｓmax）＊ＴＶを定義でき、ここで＃（Ｓi−Ｓmax）は、ＳiとＳmax（Ｓiは含むが、Ｓmaxは含まない）の間のシリアル番号の数を表す。
【０１１１】
金額Ｄ＝Ｄ1＋Ｄ2＋．．．＋Ｄmaxは、ユーザが発行してきた全ての小切手の合計値を表す。ｉ番目の小切手が発行された後にＤはｉ＊ＴＶを決して超えないので、従って、ユーザが支払い過ぎるリスクは解消される。将来のマイクロペイメントを処理するために、銀行はＳmaxの値をＳiにリセットする。上記で説明したように、Ｓiは、支払い可能であると銀行により見出された最新の小切手である。また、数式（１）も、最終的にユーザに請求される金額はどの小切手が最終的に支払い可能になるかには依存せず、ユーザが書いてきた小切手の数にだけ依存することを示す。最終的に、ユーザは、各ユーザが書いた小切手に対する適正な金額を請求される。
【０１１２】
第五者は第四者（業者、または業者以外のエンティティ）に掛売金額ＣＲiを受け取らせ、一般に掛売金額ＣＲiは次のように与えられる。
ＣＲi＝ＴＶ＊（１／ｓ） （２）
もし潜在的確率支払い方式の選択率ｓが存在したら、本発明の方法およびシステムでも、多数のマイクロペイメントにわたって平均するとき、全ての１／ｓ小切手のうち１つだけが支払いに対して選択されるようになる。従って、掛売金額は業者に対しても公平である。何故ならば、掛売金額は１／ｓ小切手の完全に集約された値であり、多数のマイクロペイメントにわたって平均されるとき、業者は正しい金額を最終的に受け取るからである。しかし、結果的な方式はユーザに対してさらに公平である。何故ならば、支払い過ぎのリスクがユーザから銀行へ移されるからである。例えば、もし選択率がｓ＝１／１０００で、業者が１，０００マイクロペイメントを扱えば、各々は１セントの価値があり、これら１，０００の支払いのうち１つだけが選択されることが予想されるが、選択された１つは業者に１／ｓ＝１０００セント（または、１０ドル）を受け取らせる。もし（１，０００マイクロペイメントのうち）複数のマイクロペイメントが選択されたら、不運により銀行は１０ドルを１回より多く支払わなければならない。上記のシリアル番号借方記入方式により、この小切手と支払いに対して選択された以前の全ての小切手の支払いをまかなうために、ユーザが合計で十分な金額を支払うまで業者への小切手に対する支払いを遅らせることにより、銀行はリスクを業者へ移すことを選択できる。
【０１１３】
本発明の第３の実施例では、ユーザは、ユーザが小切手を銀行のユーザの口座に基づいて書く権限を与える銀行から証明書を得ることが好ましい。この証明書はユーザの公開鍵を指定し、他の情報（例えば、ユーザが使用する権限を与えられた最大シリアル番号、および／または（もし、小切手が可変値を有してもよいなら）小切手の最大金額）も指定する。ユーザはこの証明書を自分が書いた各小切手と一緒に送るか、またはこの証明書だけを、最近証明書を送っていない業者に供給する。業者にユーザ証明書を一定の時間にわたって受け取らせることにより、バンド幅の節約が得られる。
【０１１４】
本発明のこの実施例のもう１つの変形では、ユーザが使用する権限を与えられた最大シリアル番号Ｙは、一連のＹマイクロペイメントの権限を特定の業者に与える長さＹのハッシュ・チェーンのルートを PayWord 証明書がしてする方法と類似の方法で、長さＹのハッシュ・チェーンを使用して指定される。しかし、この場合、許可されたシリアル番号を有する小切手は、どの業者に書かれてもよい。ユーザは業者に証明書、およびハッシュ・チェーンのｉ番目の要素を提供し、自分がシリアル番号ｉを有する小切手を書く権限を与えられていることを証明できる。（ハッシュ・チェーンのｉ番目の要素は、連続的にｉ回ハッシュされるとき、ハッシュ・チェーンのルートを発生するハッシュ・チェーンの要素であるように定義される。）
【０１１５】
また、業者はディジタル証明書も有し、支払いプロトコルの間にユーザがディジタル証明書を得られるか得られないかは、どのバージョンのプロトコルが発行されたかによる。もし支払いプロトコルが確かに非対話型であれば、ユーザはこの証明書を得ることが困難である。他方では、この証明書は支払いプロトコルに不可欠ではない。例えば、ユーザの小切手は「この小切手は、業者の公開鍵に対して有効な証明書と共に預けられたときだけ有効である。」という形式のステートメント（または、同様のもの）を含むことができ、小切手を預けるときに、業者は銀行に自分の証明書を提供できる。
【０１１６】
いくつかの理由のために、支払い過ぎのリスクをユーザから銀行（または、業者）へ移すことが好ましい。第１に、小切手が選択されることが、１／ｓ回のうち１回より著しく頻繁である確率は小さい。従って、銀行による支払い過ぎは、希にしか起こらない。何れにしても、そのような支払い過ぎの各金額はきわめて小さい。また、そのような変形をカバーするために、銀行は、例えば、口座を開くときに固定手数料（例えば、１／ｓに比例する手数料）を各ユーザに請求する戦略を採用できる。適度な金額を支払い過ぎる小さなリスクは個々のユーザを悩ませたり、例えば、本発明で開示される確率的マイクロペイメント方式に申し込むことをユーザに躊躇させるが、一般にそのようなリスクは銀行を困らせない。それは、銀行が重大なリスクを管理することに慣れているからである。１実施例として、銀行により日常的に管理されるリスクは、債務者がローンで債務不履行になるリスクである。従って、リスクを受容して管理することにより利益を得る支払いシステムをサポートすることに、銀行は制度的に適している。
【０１１７】
同様に、一般に業者は多数のトランザクションを管理することに慣れており、各トランザクションは関連するリスク（例えば、商品が返品されるリスク、またはユーザの支払いが実現されないリスク）を有する。従って、マイクロペイメント方式でリスクを受容することは、業者も受け入れ可能である。従って、銀行と業者は、例えば、支払いをカバーするのに十分な資金をユーザの口座が含むまで、支払いに対して選択されたマイクロペイメント小切手は実際には業者に支払われないということに同意する。支払いに対して選択された各小切手は、（上記のシリアル番号方式により決定される）ユーザの支払いがこの小切手と前にキューに入れられた全ての小切手を十分カバーするまで、銀行で「保留キュー(queue)」の中に保持される。
【０１１８】
第２に、支払い過ぎの確率は、長期的には次第に少なくなる。即ち、銀行が徴収するトランザクション毎の少額手数料（どれくらい少額かは問題ではない）が存在する限り、マイクロペイメント・トランザクションの数が増加するとリスクは減少する。従って、銀行にとっては支払い過ぎの確率は通常のユーザに対する確率と比較して小さい。何故ならば、一般に銀行は、単一のユーザと比較してはるかに大量のトランザクションを経験するからである。
【０１１９】
ユーザによる支払い過ぎのリスクを解消することに加えて、本発明の第３の実施例は、銀行が不正行為集団を罰すること、または実質的なダメージを引き起こす前に不正行為集団をシステムから一掃することが出来るようにする。以下でより詳細に説明するように、銀行が悪意のユーザおよび／または悪意の業者に不正行為をさせないようにすることを可能にするいくつかの特徴を本発明は含む。例えば、もし銀行が新しい小切手が前に処理した小切手と同じシリアル番号を有することに気付いたら、もし新しい小切手のシリアル番号と時間が前に処理した小切手に対して異常があれば、もし小切手の金額が多すぎたら、またはもし他の銀行が定めた条件が発生したら、銀行は小切手を引き受けることを拒絶できる。銀行はユーザに罰金を科すことさえでき、および／または（適切であると思われる）他の処罰行為を取ることもできる。例えば、ユーザの支払い可能な小切手が上記の問題を起こせば、例えば、もし証明書が使用されたら、証明書を無効にすることにより銀行は統計値を保持し、システムから追い出すことが出来る。例えば、もし小切手が矛盾する番号および／または日付を付けられたら、またはもし小切手が予想以上に頻繁に払い出される小切手のユーザに属せば、小切手は廃棄されてもよい。同様に、銀行は、不正を働く業者（例えば、前記の問題のある小切手、または統計的に予想されるより頻繁に払い出される小切手を支払いに対して受け取る業者）をシステムから追い出す。
【０１２０】
本発明の第３の実施例では、ユーザはシリアル番号を順番に、かつ繰り返すことなく使用することを要求される。例えば、シリアル番号１は第１の小切手に対して使用されるべきであり、シリアル番号２は第２の小切手に対して使用されるべきである。上記のように、この方法でユーザは請求されるべき額より多く請求されることは決してない。一般に、所定の時間において、最後の支払い可能な小切手の後で、支払いに対して選択されない追加のトランザクションに対する少数の追加小切手をユーザは書く。従って、少なくともしばらくの間、ユーザは実際に使った額より少なく借方に記入され、場合によっては、即ち、最新の小切手が実際に支払い可能なときに、借方につけられるべき正確な金額を借方に付けられる。
【０１２１】
しかし、実際の支出額より少ない金額が借方に付けられる方法を見付けるために、不正直なユーザはシリアル番号にイタズラしようとする。１つの方法は、シリアル番号を１回より多く再使用することである。もし不正直なユーザがこれをやれば、数量Ｓi−Ｓmax（従って、（Ｓi-Ｓmax）*ＴＶによって与えられる金額）が真の値と比較して減少する。しかし、この種の不正行為はあまり有用でない。何故ならば、もし支払い可能な小切手が前に処理した小切手と同じシリアル番号を有することに銀行が気付けば、そのような不正行為を防止するために考えられた懲罰的手段を銀行は取れるからである。例えば、もし銀行が重複するシリアル番号と支払い可能な小切手の中で遭遇したら、銀行は不正行為ユーザの借方に高額の金額を付ける権限を与えられており、この方法での不正行為はユーザにとって逆効果である。
【０１２２】
本発明の第３の実施例で開示されるマイクロペイメント方式では、ユーザは自分の小切手のどれが支払い可能になるかは予測できず、従って、管理できないことを銘記すべきである。従って、同じシリアル番号を有する２つの小切手を生成する各時間には、２つの小切手の両方が支払い可能になるチャンスが（たとえ小さくても）ある。不正行為を捕らえられることに対するペナルティは、不正行為により得ることを希望するものの補償より十分高く設定できる。
【０１２３】
不正行為のいくつかの形態は、小切手の「back-dating」、および同様のものを含む。従って、同じユーザからの２つの小切手ＣおよびＣ'に対して、Ｃのシリアル番号はＣ'のシリアル番号より小さいか、Ｃの日付／時間はＣ'の日付／時間より前かを業者と銀行がチェックすることは重要である。
【０１２４】
もしユーザが自分の小切手のどれが支払い可能になるかを（支払いトランザクションのすぐ後に）業者から聞かされなければ、不正行為を行うユーザを捕らえるための上記メカニズムはよりうまく働く。実際、この観点から、どの小切手が支払い可能になったかについてユーザを出来るだけ無知なままにしておくことが好ましい。基本的に、実際にユーザはユーザが何枚の小切手を書いたかを正確に監視でき、従って、公正な借方を疑うことはない。しかし、もし疑いが生じたら、借方に付けられた金額の証明（支払い可能な小切手のシリアル番号を含む）を提示することが好ましい。
【０１２５】
もし支払いに対する小切手Ｃiを選択するための基準が単にシリアル番号Ｓiに依存するなら、不正行為ユーザを探し出して追い出すための上記メカニズムは改善される。この方法で、もし小切手が支払い可能なら、不正行為により同じシリアル番号で生成される他の小切手も支払い可能である。例えば、もし潜在的確率支払いシステムが前節で開示されたものなら、いつ小切手が支払い可能であるかを（プロパティＰを経由して）決定するために使用される（ユーザが予測不可能な）数量Ｖiは、（業者の署名Ｃi全体よりもユーザの口座番号、および／または名前と一緒に）単に業者の署名Ｓiだけで構成できる。
【０１２６】
ユーザが少なく支払おうと試みるもう１つの方法は、使用した回数とは合わない順番でシリアル番号を使用することである。例えば、いったん悪意のユーザがＳ100が支払い可能な小切手の一番小さいシリアル番号であることを確信したら、使用する小切手が支払いに対して選択されないことを確実にし、同時に同じシリアル番号を２回使用して捕らえられることを恐れないように、悪意のユーザはシリアル番号Ｓ1からＳ99までを再使用することを計画する。しかし、この種の作戦計画についてさえ、悪意のユーザは捕らえられるチャンスをまだ有する。その理由は、もし悪意のユーザが後で（即ち、Ｃ100を使用した後で）１と９９の間のシリアル番号を再使用したら、支払い可能になることからの違法チェックを悪意のユーザは防止できないからである。これは現実的な確率で発生し、もし発生したら、小切手Ｃ100は時間ｔ100を有するトランザクションＴ100に関して支払い可能であったこと、および時間がｔ100より後のトランザクションに対するＳ100より小さいシリアル番号を有する小切手をユーザが後で生成したことに銀行は気付く。重ねて、銀行による制裁が、この方法による不正行為をユーザにとって逆効果にする。この種のスクリーニング・メカニズムを円滑に働かせるために、各小切手が支払いを行ったトランザクションの時間を表示し、間違った時間を表示する小切手を（選択プロセスが始まる前に）業者が無効であるとして無視することが好ましい。
【０１２７】
この対不正行為戦略を上手くサポートするために、銀行は業者に、（実施例として）小切手のシリアル番号にだけ依存する構成要素、および時間にだけ依存する構成要素の両方を含むように設計された選択手続きを使用することを要求する。もう１つの構成要素は小切手全体に依存する。基本的に、２つ以上の選択プロセスが存在し、もしそれらの中の１つの結果が小切手が選択されると決定したら、小切手は選択される。そのような変形は、当業者には明らかである。
【０１２８】
Ｕ'により署名された小切手、およびＭ'により提供された商品／サービス／情報に対する支払いが常に支払い可能であるように、悪意のユーザＵ'は悪意の業者Ｍ'と共謀する。この方法では、簡単にするために、各支払い値は１セントであり、Ｕ'はちょうど１セントだけ銀行によって常に借方に付けられており、Ｍ'は１／ｓセント（即ち、もしｓ＝１／１０００なら１０ドル）だけ常に支払われると仮定する。Ｕ'とＭ'は違法な手続きを分担し、もしＵ'が（多分、仮名で）業者の振りをすれば、確かにＵ'はＭ'と一致する。
【０１２９】
それにもかかわらず、Ｕ'とＭ'は控え目な違法利益を得るだけである。もしＵ'とＭ'が（上記の方法を数回繰り返すことにより）違法利益を増やそうとしたら、Ｕ'とＭ'はシステムから追い出される確率が高い。特に、もしＭ'が合法利益もシステムで得ているなら、これは高くつく。追い出されたユーザと業者がシステムに戻るのは容易でない。例えば、新しい個人情報の元で、もしシステムに最初から入るのに必要な価格（例えば、初期証明書を得るための価格）が十分高価なら、この違法行為は殆ど引き合わない。この違法行為はユーザに負の利益をもたらし、違法行為に含まれるコストは銀行によって容易に吸収される。
【０１３０】
何れにせよ、この種の不正行為は、第一者に安全なハードウェアを使用させることにより解消される。例えば、この変更できない構成要素は、新しい小切手が生成される各時間に適切に増加するシリアル番号に対して寄与し、秘密署名鍵を安全に守り、および新しい小切手の署名構成要素を生成する。従って、もし悪意のユーザが共犯の業者に対して支払い可能な小切手を生成しようとしたら、全ての試み毎に悪意のユーザはシリアル番号も増加させなければならない。従って、いったん支払い可能な小切手が生成されたら、業者は所定の金額を支払われるが、ユーザも対応する適切な金額を借方に付けられる。関係者がこの開示の何れを使用しても、および／または使用することを要求されても、安全なハードウェアがオペレーションの少なくとも一部を実行することを銘記すべきである。より詳細には、そのような安全なハードウェアは、スマートカードまたは携帯電話に含まれる。
【０１３１】
不正をしないユーザが悪意に見える小さな可能性が存在する。何故ならば、ｎ枚の小切手を書いた後、ｎ枚の小切手のうちｎ＊ｓより著しく多くが単に偶然により支払い可能になったからである。この場合、不正をしないユーザは追い出されるかもしれない。適切なパラメータ設定により、そのようなユーザは殆どいなくなる。加えて、意図せずに銀行に損失を与えたこれらのユーザに伝達することも可能である。例えば、銀行はユーザに、異常に多数の小切手が支払い可能であることが分かったことを明らかにする情報、および何故そんなに多くの小切手が実際に支払い可能であったかを説明する情報を提供できる。その結果、これらのユーザは、異なる条件で（例えば、実際に使った金額より多くの金額を借方に付けられるリスクをユーザが負う確率的支払いシステムのユーザとして）マイクロペイメント・システムに留まることを受け入れるかもしれない。そのような遷移は、ユーザと銀行の間の元の合意に自動的な特徴として取り入れられるかもしれない。
【０１３２】
上記のように、この小切手（および、支払いに対して選択されたユーザからの以前の全ての小切手）をカバーするのに十分な資金を銀行がユーザから受け取るまでの時間まで、支払いに対して選択された小切手の支払いを遅らせることにより、銀行は統計的変化に関するリスクのいくらか（および、ユーザ不正行為に関するリスクのいくらか）を業者へ移す。ユーザが書いた小切手の数により、銀行は資金をユーザから組織的に受け取り、銀行は小切手を支払いに対して選択された業者から本発明によって上記のように受け取る。ユーザが不正をせず、小切手をしばしば書くとき、業者はこの方式では銀行からの支払いを長く待たなくてもよい。また、もし銀行が業者に各小切手の全額を支払わず、僅かに割引した金額を支払えば、ユーザ支払いの割合が銀行支出の割合をいくらか超えるとき、一般にユーザの口座は支払い済み（または、殆ど支払い済み）になるべきである。この場合、業者は直ぐに（または、短い遅延の後に）支払いを期待できる。この方法で業者にリスクを移すことは、銀行に詐欺を働く努力で共謀することを企てることをユーザと業者に思い止まらせる特に効果的な方法である。何故ならば、支払いに対して選択されたユーザの小切手に対して行われた支出が、ユーザからの受け取りを超えるリスクを、銀行はもはや仮定しないからである。もしこの変化が取り入れられたらユーザの証明書にユーザの口座に関連する「保留、未払い」小切手の合計値を表示することは銀行にとって有用であり、もしこの金額が過大であるようなら、業者はユーザの小切手を受け取ることを断る。
【０１３３】
また、本発明の第３の実施例の方法およびシステムも、均一な固定トランザクション値を持たないマイクロペイメントを扱うことを可能にする。１つの方法は、ｖ枚の１セント小切手の束とし明確にｖセントの価値がある小切手を、連続するシリアル番号を用いて扱うためのものである。より効率的な方法は、ユーザが、（単一のシリアル番号により特徴付けられる代わりに）シリアル番号区間［Ｓ，Ｓ＋ｖ−１］（両方の端点ＳとＳ＋ｖ−１を含む）により特徴付けられる単一の小切手を書くことである。もしこの小切手が支払い可能になれば、ユーザはＳ＋ｖ−１−Ｓmaxセントだけ借方に付けられ、新しいＳmaxがＳ＋ｖ−１になる。
【０１３４】
本発明の第３の実施例では、値が変化する小切手がサポートされるとき、小切手が支払い可能であると決定されるプロセスは小切手の値に依存する。即ち、単一の選択確率ｓの代わりに、０より大きい各整数ｖに対する選択確率ｓvが存在し、これらの確率は異なってもよい。手続きは単純な「階段関数」の形態を使用し、もしｖが１００より小さければ、ｖセントに対する小切手は確率１／１００で支払い可能であり、もしｖが１００以上なら、確率１である。代わりに「傾斜関数 (ramp function)」も使用できる。もしｖが多くても１０００なら、小切手は確率ｖ／１０００で支払い可能であり、もしｖが少なくとも１０００なら、確率１で支払い可能である。しかし、この方式の使用は、銀行が種々の形態の詐欺を検出する能力と不都合に相互作用するので、慎重に使用すべきである。例えば、今まで業者に支払われてきた金額を銀行が容易に予測することはもはや出来ず、所定の最大シリアル番号だけが分かる。この理由のために、選択確率を固定したままにすることが望ましい。この方向では、銀行にとって魅力的な１つのアプローチは、ユーザに２つ以上の証明書を発行することであり、各証明書は許可されたシリアル番号の組、最大支払いサイズ、および選択確率ｓを指定する。基本的に、ユーザは１組の別個の「小切手帳」を有し、各々が自らのパラメータ、限度、および選択確率ｓを有する。
【０１３５】
不等トランザクション値の場合をより詳細に参照すると、本発明の第３の実施例はユーザが支払いを複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔnと確立することを可能にし、各トランザクションＴiは整数インデックスｉとトランザクション値ＴＶiにより部分的に特徴付けられ、ここで各Ｔiは等しい値である必要はないが、各ＴＶiは共通の単価ＵＶの積として特徴付けられる。例えば、ＵＶは１セントである。この場合、各データ列Ｃiは、整数インデックスｉ、およびＴiの値ＴＶiの情報を含む。情報は、その小切手に対する「初期シリアル番号」と「最終シリアル番号」から成る１組の値（Ｓi，Ｓi＋ｖi−１）の形態を取る。１とｎの間の全てのｉに対して、Ｓiは、連続的に順序付けられ、他のデータ列に対するＣiの位置を順番に並べられたデータ列Ｃj（ｊ＝１，．．．，ｎ）で表す漸進的なシリアル番号である。ｖiはｉに依存する整数であり、Ｔiの値ＴＶiを表し、ｖi＝ＴＶi／（ＵＶ）で与えられる。
【０１３６】
受け取った小切手Ｃj（１≦ｊ≦ｎ）から、ユーザが前もってどの小切手Ｃjが支払い可能であると選択されるか予測することを妨げる方法で支払い可能なものを業者は選択する。１つの形態では、業者は第Ｉ節に記載された方法（即ち、項目Ｖj（例えば、業者の秘密鍵を使用して生成されたＣjの業者のディジタル署名）を（ユーザが実質的に予測できない）Ｃjに関連付ける）を使用できる。業者は、第三者を選択された小切手Ｃjが支払い可能であることを確認できるようにする情報Ｉjを第三者に受け取らせる。Ｉjの受け取りに対する応答では、第三者は、選択された小切手Ｃjが確かに支払い可能であることを確認する。Ｃjが支払い可能である場合にのみ（および、もし他の条件も同様に満たされたら）、第五者がＳmaxとｖmaxの値を決定する。ここで、ｍａｘは整数（１≦ｍａｘ＜ｉ≦ｎ）であり、ｖmax＝ＴＶmax／（ＵＶ）である。Ｓmaxは、支払いに対して今まで選択された小切手の最大最終シリアル番号を表す。次に、第五者は、（受取人であり、業者かもう１人の関係者である）第四者に掛売金額ＣＲを受け取らせる。第五者は第一者に、Ｄiに関連する借方金額を借方に付けさせる。ここで、Ｄiは以下で与えられる。即ち、
（Ｓi＋ｖi−1−Ｓmax）＊ＵＶである。
次に、Ｓmaxが、Ｓi＋ｖi−１に設定される。
【０１３７】
不正行為の場合、不均一なトランザクション値が捕らえられ、固定トランザクション値の場合と類似した方法を使用して処理される。例えば、２つの支払い可能な小切手（１つは１セントに対するものであり、ＳとＳ＋ｖ−１の間のシリアル番号Ｓ'により特徴付けられ、もう１つはｖセントに対するものであり、シリアル番号区間［Ｓ，Ｓ＋ｖ−１］により特徴付けられる）は、この場合には不正行為の証明と考えられる。大きすぎる値ｖに対する小切手は許可されない（即ち、支払いを常に拒絶される）。さもなければ、悪意のユーザが支払いシステムに参加でき、大きな金額に対する単一の小切手を書け、もし小切手が支払いに対して選択されなかったことが判明したら、第２の小切手を決して生成しない。また、この問題は、口座を開設するとき「入会費」を各ユーザに請求することにより処理でき、そのような入会費は、そのユーザに対して予測される極大「浮動 (float)」をカバーするくらい十分に多額である。ここで、「浮動」は、ユーザが書いてきたが銀行は見てこなかった小切手の予想される極大である。本発明のいくつかの形態に対して、この浮動はユーザが書いた小切手の最大サイズとして計算でき、小切手が支払いに対して選択される確率の逆数倍される。また、上記のように、支払いに対して選択された小切手への支払いを、この小切手（および、支払いに対して選択された（ユーザにより書かれた、以前の）小切手）をカバーするためにユーザから十分な資金を銀行が受け取るまで遅らせることにより、銀行は不正行為を思い止まらせる。
【０１３８】
１つの形態では、（ユーザが実際の支出額より多く請求されることは決してないことを保証する）第３の実施例の方法およびシステムは、第Ｉ節で記載された基本的な確率的支払い方式を用いて実施できる。この場合、トランザクションＴi（ｉ＝１，．．．，ｎ）に対する小切手Ｃiを受け取るとすぐ、業者は小切手Ｃiを（ユーザが実質的に予測できない）項目Ｖi（例えば、ＣiまたはＣの一部分iに対する（業者の秘密鍵を使用して生成された）業者のディジタル署名、ＳＩＧM（Ｃi））に関連付ける。次に、業者は、Ｖiが特定のプロパティＰiを満たすか否かを確認する。例えば
Ｆ（ＳＩＧM（Ｃi））＜ｓ （３）
である。
ここで、Ｆはビット列に作用し、０と１の間の１つの数字を戻す関数であり、ｓは選択率（０＜ｓ＜１）である。
【０１３９】
もし業者がＶiがＰiを確かに満たすことを見出せば、業者は銀行に、ＶiがＰiを満たすか否かを銀行が確認することを可能にする情報Ｉi（例えば、Ｖiを生成するために使用された業者の秘密鍵に対応する業者の公開鍵）を受け取らせる。もしＶiがＰiを満たさなければ、業者は小切手Ｃiを廃棄する。ＶiがＰiを確かに満たすこと（および、Ｖiが銀行の裁量で決定される他の条件を満たすこと）を銀行が見出した場合のみ、（銀行、または銀行以外のエンティティである）第五者は（業者、または業者以外のエンティティである）第四者に掛売金額ＣＲiを受け取らせる。また、第五者は、ユーザの借方に借方金額Ｄiを付けさせる。
【０１４０】
第３の実施例では、ユーザに請求される金額Ｄiは、業者（または、他の エンティティ）に受け取られる金額ＣＲiと同じである必要はない。しかし、第３の実施例の方法は、選択的デポジット・プロトコルを含むことにより、それ自体を潜在的確率支払い方式と区別し、選択的デポジット・プロトコルは、ユーザが借方に付けられる金額Ｄiは、ユーザが小切手を書くことにより実際に使った金額よりも総計で多いことは決してないことを保証する。より詳細には、選択的デポジット・プロトコルは、借方に付けられた金額が、対応するトランザクション値より合計で常に大きくないことを保証する。換言すれば、ユーザは、実際の支出額より多く請求されることは決してないことを保証される。
【０１４１】
図５は、トランザクションＴiに対する支払いを本発明の１実施例により確立するためのマイクロペイメント・システム２００の構成要素を示す略ブロック図である。システム２００は、ユーザ、業者、および銀行が電子データを送信すること、および彼らの間での支払いさえ可能にする通信手段２１０を含む。電子データは、電子小切手を表すデータ列、またはメッセージを表す列を含む。１実施例では、通信手段２１０がリモート・サーバへのアクセスを可能にする。通信手段２１０は、モデム、および（限定されないが、ネットワーク・インターフェースカードを含む）当該技術分野で既知の１または複数のネットワーク・インターフェース装置を含む。異なるネットワーク・ノード間のデータ転送を可能にするように、１または複数のバス（例えば、アドレスバス２１４、およびデータバス２１５）が提供される。
【０１４２】
また、システム２００は第１処理手段２０５、および第２処理手段２０６も含む。第１および第２処理手段はコンピュータシステム（例えば、 DOS または Windows オペレーティングシステムを動作させるディジタルコンピュータ）であり、アドレスバス２１４とデータバス２１５に接続される。各処理手段２０５，２０６は、データを記憶するための記憶手段２２１、データを入力するための入力手段２２２、およびシステム命令を実行する中央処理装置（ＣＰＵ）２２３を一般に含む。記憶手段２２１は、コンピュータメモリ、データ記憶装置（例えば、ハードディスク）、ＣＤ−ＲＯＭ、および同様のものを含む。入力手段２２２は、当該技術分野で既知の入力装置（例えば、従来のキーボード）である。
【０１４３】
第１処理手段２０５は、トランザクションＴi（ｉ＝１，．．．，ｎ）に関するデータ列Ｃiを導出し、入力し、記憶するためにユーザによって動作させられ、小切手Ｃj（ｊ＝１，．．．，ｎ）の他の小切手に対する小切手Ｃiの位置をきちんとした順番で表す漸進的なシリアル番号Ｓiをデータ列Ｃiに含む。第２処理手段１０６は業者によって動作させられ、項目ＶiをＣiに関連付けるためにＣiに応答する。また、第２処理手段２０６も、ＶiがプロパティＰiを満たすか否かを決定するために機能する。例えば、１組の命令は第２処理手段２０６のＣＰＵ２２３に入力され、ＣＰＵにＣi（または、Ｃiの一部分）に関連付けられた項目Ｖiを導出させ、ＣＰＵ２２３にＶiがプロパティＰiを満たすか否かを決定させる。これは、次のステップが第２処理手段２０６のＣＰＵ２２３により実行される（即ち、銀行がＶiがＰiを満たすか否かを確認することを可能にする情報Ｉiの銀行への転送の命令）ために満たされなければならない必要条件である。処理手段２０６のＣＰＵ２２３は、情報Ｉiを銀行へ送信するために、ＶiがＰiを満たすときに選択的に機能するようにプログラムされる。
【０１４４】
また、システム２００は、（業者、またはもう１人のエンティティである）第四者に総額を受け取らせるために、（ＶiがＰiを満たすときに銀行（または、もう１人の五者）により選択的に機能する）手段２４０も含む。また、手段２４０はコンピュータシステムであり、ＶiがＰiを満たすときに選択的に機能するようにプログラムされたＣＰＵを有し、
１）Ｓmax（Ｓmaxは、支払いが行われた最後の小切手のシリアル番号であり、従って、支払いのために銀行に提示された小切手の最大シリアル番号である）の値を決定し、
２）第四者への金額ＣＲの支払いの転送を命令し、および
３）ユーザの借方に金額Ｄを記入させる。
【０１４５】
要約すると、本発明の第３の実施例のマイクロペイメント・システムおよび方法は、ユーザが実際の支出額より多く請求されることは決してないことを保証するための機構を提供する。この方法で、第３の実施例で提示されたシステムおよび方法はユーザの受け入れを著しく向上させ、ユーザの受け入れはマイクロペイメント方式の幅広い支持に影響する大きな要因である。
【実施例４】
【０１４６】
ＩＶ．銀行により管理される遅延選択プロトコルを含むマイクロペイメント・システム
本発明の第４の実施例は、遅延選択プロトコルを含む確率的マイクロペイメント方式を開示し、遅延選択プロトコルでは支払い選択プロセスは、１または複数の小切手へのコミットメントを銀行が業者から受け取るまで遅延される。そのような遅延選択プロトコルを実施する複数の方法が存在する。第１の（および、好ましい）方法は、以下のようである。即ち、ユーザが（マイクロペイメント・トランザクションＴから導出される）データ列（または、「電子小切手」Ｃ）を生成し、トランザクションの時間ｔの適切な表示を提供し、ユーザが支払いを行いたいときに、Ｃを業者に送信する。業者は（１または複数のユーザから所定の時間間隔（例えば、所定の日）で受け取った）小切手Ｃi（ｉ＝１，．．．，ｎ）をｍ個のリストＬk（ｋ＝１，．．．，ｍ）にグループ化する。ここで、ｍは任意であるが、例えば１／ｓに等しい整数であり、ｓは所望する選択確率である。各リストは、ｍ個の相互に排他的なプロパティＰ1，．．，Ｐmの１つを厳密に満たす全ての小切手から成ることが好ましい。例えば、もしｍ＝１０２４なら、各リストＬk（ｋ＝１，．．．，ｍ）は、その日に受け取った全ての小切手を含み、小切手は決定性ハッシュ関数Ｈによってハッシュされ、最初の１０ビットが整数ｋ−１の１０ビット２進展開である値を生成する。各リストＬk（ｋ＝１，．．．，ｍ）は、ｌk個の小切手Ｃk 1，．．．，Ｃkｌkを含み、ここで、ｌkはリストＬkのデータ列の数を表す。ｍ個のリスト全体が足されるとき、ｌkは受け取った小切手の総数ｎまで自然に足される。即ち、
ｌ1＋．．．＋ｌk＋．．．＋ｌm＝ｎである。
業者は、Ｌkに対するコミットメントＣＭkを計算することにより各リストＬkにコミットし、銀行にＣＭk（ｋ＝１，．．．，ｍ）を受け取らせる。
【０１４７】
当該技術分野で既知なように、コミットメント方式は、メッセージの内容を明かすことなく、このメッセージにコミットしながら、１人の関係者がメッセージをもう１人の関係者に配布することを可能にするプロトコルである。このプロトコルは、関係者が「鍵を掛けた箱」の中のメッセージを配布するプロセスをエミュレートすることを可能にし、それにより送信する関係者（今の場合、業者）は、受信する関係者（今の場合、銀行）が箱の中のメッセージについて何か知ることを、受信する関係者が箱の鍵を与えられる将来の時間まで防止できる。受信する関係者は（受信する側では）、受信する関係者が既に受信した後に、送信する関係者が箱の中のメッセージを変更することを防止できる。一般に、コミットメント方式は２つのフェーズから成る。第１のフェーズ（コミットメント・フェーズ）は、鍵を掛けた箱の配布をシミュレートする。このフェーズが終わるとき、受信する関係者はメッセージをまだ知らないが、送信する関係者はメッセージをもう変更できない。第２のフェーズ（デ・コミットメント・フェーズ）は、鍵の配布をシミュレートする。今、受信する関係者はメッセージを見ることができ、鍵を開けた箱の中のメッセージが確かに送信する関係者がコミットしたメッセージであることを確認できる。
【０１４８】
好ましい形態では、Ｌkに対するコミットメントＣＭkはハッシュ値Ｈ（Ｌk）であり、ここでＨは一方向衝突防止性ハッシュ関数である。従って、ＬkをＣＭkから導出することはコンピュータで実行不可能であり、Ｈ（Ｌ1 k）＝Ｈ（Ｌ2 k）であるような２つの異なる列Ｌ1 kとＬ2 kを生成することもコンピュータで実行不可能である。
【０１４９】
本発明の第４の実施例で開示される遅延選択プロトコルでは、特定の小切手Ｃiが支払いに対して選択されるべきか否かを決定するための支払い選択プロセスが、リストＬkに対する業者のコミットメントＣＭk（ｋ＝１，．．．，ｍ）を銀行が受け取るまで遅延される。これは、本発明の第４の実施例に記載されるマイクロペイメント方式を際立たせる特徴である。ＣＭk（ｋ＝１，．．．，ｍ）を受け取るとすぐ、銀行は１とｍの間の１つのインデックスｋを業者とユーザが予測不可能な方法で選択する。例えば、銀行は問題の日付にディジタル的に署名でき（例えば、２００１．０１．０１）、最初の１０ビットの選択のために、この署名を使用する。最初の１０ビットが抽出される前に、この署名はハッシュされることができる。銀行の署名は公開（例えば、ウェブに投函）でき、ｋがその日に銀行によって選択されたインデックスであることを確かに確認できる。選択されたインデックスｋは、支払いインデックスである。業者は、ＣＭkを小切手 Ｌkの元のリストにデ・コミットすることにより応答する。或いは、銀行はインデックスｋを、リストＬkに対する業者のコミットメントＣＭk（ｋ＝１，．．．，ｍ）の関数として計算できる。例えば、ｋはＣＭ1，．．．，ＣＭm、またはＨ（ＣＭ1，．．．，ＣＭm）の 銀行の署名から抽出できる。ここで、Ｈは、所定の関数ｆに対する一方向ハッシュ関数、またはｆ（ＣＭ1，．．．，ＣＭm）である。
【０１５０】
次に銀行は、全てが適切かを検査する。例えば、銀行は、デ・コミットされたリストの小切手が確かに問題の日付に関連すること、重複する小切手がリストに存在しないこと、リストの中の全ての小切手がプロパティＰkを満たすこと、（もし存在するなら）ユーザ署名が有効であること、などを確認する。もし、これらの条件のどれかが満たされなければ、銀行は業者（例えば、ユーザが同じシリアル番号の２枚の小切手に署名したことを銀行が発見した場合はユーザ）に対して罰金を科すか他の懲罰的手段を取る。さもなければ、銀行は業者にＬkの小切手の合計値のｍ倍を支払う。代わりに、もし検査されたリストが検査をパスしたら、銀行は業者に全リストの全ての小切手の合計金額を支払う。また、もしユーザの口座がこれら小切手をカバーするには不十分な資金を有したら、これら支払いのいくらかは前記のように遅延される。
【０１５１】
次に、小切手がＬkに属するユーザが、幾つかの中の１つの方法で借方に記入される。例えば、これらのユーザは、（第１の実施例のように）または（第３の実施例のように）選択された小切手のシリアル番号により、選択された小切手の額面価格をｍ回だけ借方に記入できる。銀行はセキュリティを実行するか、または従来の実施例で想像される方法で処罰を提供する。また、銀行は業者に追加のリストをデ・コミットして、全て適切であることを確認するか、または複数の支払いインデックスを選択することを依頼する。後者の場合、銀行は業者にＬkの小切手のｍ／ｒ倍を支払う。ここで、ｒは支払いに対して選択されたリストの数である。この場合、選択確率は、１／ｍではなくｒ／ｍである。或いは、銀行は２つ以上のリストを検査し、全リストの全ての小切手に関係する合計金額を業者に支払う。
【０１５２】
コミットメントは、本発明の範囲内で再帰的に使用できることを銘記すべきである。例えば、銀行にリストＬk（ｋ＝１，．．．，ｍ）に対するｍ個のコミットメントＣＭk（ｋ＝１，．．．，ｍ）を送るより、業者は銀行にこれらｍ個のコミットメントに対するコミットメントを送ることができる。実施例として、業者は銀行に単一の値Ｃ＝Ｈ（ＣＭ1，．．．，ＣＭm）を送信する。ここで、Ｈは一方向ハッシュ関数である。銀行が１（または複数の）インデックスｋを選択した後、ＣＭkが何であったかを明らかにするように最初に業者はＣをデ・コミットし、次に（既に述べたように）小切手の対応するリストを明らかにすることによりＣＭkデ・コミットする。例えば、もしＣ＝Ｈ（ＣＭ1，．．．，ＣＭm）なら、ｍ個全てのコミットメントＣＭ1，．．．，ＣＭmを明らかにすることにより業者はＣＭkに対する正しい値を明らかにする。銀行はこれらｍ個の値を一方向ハッシュして同じ値Ｃ＝Ｈ（ＣＭ1，．．．，ＣＭm）が生成されることをチェックし、次にｋ番目のコミットメントを回収してＣＭkを分離する。もちろん、業者も、銀行へ単一のコミットメントＣではなく複数のコミットメントを送信することによりｍ個のコミットメントＣＭ1，．．．，ＣＭmにコミットできる。例えば、業者は第１のコミットメントをＣＭ1，．．．，ＣＭ10へ送り、第２のコミットメントをＣＭ10，．．．，ＣＭ20へ送ることが出来る。
【０１５３】
一般に、単一の値Ｖ（例えば、一方向ハッシュ関数Ｈに対してＶ＝ｈ（Ｖ1，．．．，Ｖm））を用いてｍ個の値Ｖ1，．．．，Ｖmにコミットするために、全てのＶ1，．．．，Ｖnを明らかに／送信して、Ｖiだけをデ・コミットしなければならない。もしｍが非常に大きくおよび／またはＶiが非常に大きければ、これは実行不可能である。本発明のシステムで使用されるコミットメントのための特に便利な方法は、一般化された Merkle tree である。「一般化された Merkle tree 」は、他の全ての値をデ・コミットすることなく、そのような値の中の１つだけをデ・コミットすることを可能にするｍ個の値に対するコミットメントを意味する。
【０１５４】
一般化された Merkle tree の特別な場合が、 Merkle による米国特許第4,309,569号に記載される Merkle tree コミットメント方式として既知であり、言及することにより本明細書に取り込まれる。 Merkle tree を実施するための１つの方法は、コミットされるべき値を無向グラフＧのノードに記憶することであり、無向グラフＧのエッジのいくつかが非周期（および、一般に tree 状の）（好ましくは、Ｇと同じノードを持つ）部分グラフＧ'を生成するように方向付けられ、１または複数の潜在的一方向ハッシュ関数を使用して（例えば、潜在的一方向ハッシュ関数に基づく可換な一方向ハッシュを使用することにより）そのノードのＧ'に降順で記憶された値、および潜在的な追加の値にも依存する値を各ノードに記憶する。この方法では、圧倒的確率で、潜在的一方向ハッシュ関数の１つの不一致が見付からない限り、少なくとも１つまたは複数の元の値を変化させることが、Ｇ'の１または複数のルートノードに記憶された値も変化させる。この方法を使用して、ルートノードに記憶された値が、グラフのノードに記憶された元の値へのコミットメントを構成する。加えて、コミットされている種々の値がグラフの何処に記憶されるかについての（銀行により後でチェックされる）いくつかの制約が存在する。何れにせよ、一般化された Merkle tree を使用して、業者はＣＭ1，．．．，ＣＭmにコミットできる。また、コミットメントＣＭkは、Ｌkを一般化された Merkle tree でハッシングすることにより生成される。一般化された Merkle tree の使用は、コミットメントが使用される本発明のどんな側面でも起こり得る。
【０１５５】
業者は銀行に（１または複数のコミットメントＣにより自身がコミットされているかも知れない）コミットメント値ＣＭ1，．．．，ＣＭm、リストＬ1，．．．，Ｌmについての他の数量（例えば、これら各リストの合計金額、またはこれら各リストの小切手の数）を送信することが有用であると分かることを銘記する。これら他の数量は、コミットメントの他に伝達される。例えば、業者は銀行にＣＭ1，．．．，ＣＭmおよびＱ1，．．．，Ｑmを送信する。ＱiはＬiの数量を「平文で」表す。実施例として、これは、銀行がデ・コミットメントなしに各リストの合計金額を査定することを可能にする。
【０１５６】
遅延選択プロトコルを含む確率的マイクロペイメント方式を実施するための他の関連する方法が存在する。これらの方法では、支払い選択プロセスは、業者が複数のユーザから受け取った１または複数の小切手へのコミットメントを銀行が業者から受け取るまで遅延される。次に、銀行は、コミットされた小切手のどれが支払い可能であるかを公平かつ確率的に決定する。また、本発明の第４の実施例の遅延選択プロトコルも、不正行為集団が実質的なダメージを引き起こす前に、銀行が不正行為集団を処罰する／削除することを可能にする。
【０１５７】
図６は、本発明の第４の実施例によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図である。ユーザはマイクロペイメント・トランザクションＴから生成されたデータ列、または「電子小切手」Ｃをつくり出し、支払いを行いたいときにＣを業者へ送信する。本発明の図示される実施例では、複数のトランザクションＴi（ｉ＝１，．．．，ｎ）が含まれる。（１人または複数の）ユーザは各トランザクションＴiに対する小切手Ｃiを導出し、業者に小切手Ｃi（ｉ＝１，．．．，ｎ）を受け取らせる。
【０１５８】
業者は（ユーザから受け取った）小切手Ｃi（ｉ＝１，．．．，ｎ）をｍ個のリストＬkにグループ分けする。ここで、ｋ＝１，．．．，ｍである。各リストＬk（ｋ＝１，．．．，ｍ）はｌkおよびデータ列Ｃk 1，．．．，Ｃkｌkを含む。ここで、ｌkは所定のリストＬk中のデータ列の数を表す。個のリストにわたって加算するとき、ｌkは自然に受け取った小切手の総数ｎになる。即ち、
ｌ1＋．．．＋ｌk＋．．．＋ｌm＝ｎである。
次に、業者は、ＬkにコミットメントＣＭkすることにより各リストＬkにコミットし、銀行に各ｋ（即ち、ｋ＝１，．．．，ｍ）に対するＣＭkを受け取らせる。
【０１５９】
小切手をリストにグループ化することは、業者と銀行が同意した特定の規則に従って行われる。例えば、小切手ＣはリストＬiに配置される。ここで、ｉはＣの関数として（例えば、Ｃのシリアル番号を使用することにより、Ｃから数ビットを抽出することにより、またはＣのハッシュから数ビットを抽出することにより）計算される。
【０１６０】
各トランザクションＴiは、トランザクション値ＴＶiにより特徴付けられることが好ましい。また、各データ列Ｃiは、Ｃiが導出されるトランザクションＴiのトランザクション値ＴＶiを表すデータを含むことが好ましい。従って、業者は各リストＬkに対する合計金額Ｖkを決定できる。ここで、Ｖkは以下の式により与えられる。即ち、
Ｖk＝ＴＶk 1＋．．．＋ＴＶkｌkである。
換言すれば、Ｖkは、リストＬkの全データ列Ｃk 1，．．．，Ｃkｌkの合計値を表す。この場合、業者も値Ｌkへのコミットに加えて、値Ｖkへ任意にコミットする。即ち、業者は、値（Ｖ1，Ｖ2，．．．，Ｖm）のリストへの追加のコミットメントＣＶ＝Ｈ（Ｖ1，Ｖ2，．．．，Ｖm）を提供する。ここで、Ｈは一方向ハッシュ関数である。従って、ＣＶをデ・コミットすることにより、業者はリスト（Ｖ1，Ｖ2，．．．，Ｖm）を明らかにする。
【０１６１】
第４の実施例で開示された遅延選択プロトコルでは、（特定の 小切手Ｃiが支払いに対して選択されたか否かを決定するための）支払い選択プロセスは、銀行がリストＬkへの業者のコミットメントＣＭk（ｋ＝１，．．．，ｍ）を受け取るまで、および（もし、このオプションが選択されたら）銀行が値ＶkへのコミットメントＣＶを受け取るまで遅延される。この遅延は、第４の実施例に記載されたマイクロペイメント方式の特色である。ＣＭk（ｋ＝１，．．．，ｍ）（および、任意のコミットメントＣＶ）を受け取るとすぐ、銀行はｉ1，ｉ2，．．．．，ｉrを表す１または複数の整数を選択し、業者に選択されたインデックスｉ1，ｉ2，．．．．，ｉrを受け取らせる。本発明の第４の実施例では、整数インデックスｉ1，．．．，irの銀行による選択は、小切手が支払いに対して選択されるか否かを決定する選択プロセスを表す。
【０１６２】
ｒの値は任意であり、銀行次第であることを銘記する。より多くの未遂の詐欺行為が発生するとき、または特定の業者への容疑が存在するとき、さらに大きな値のｒが使用される。場合によっては、銀行は業者に全てのコミットメントをデ・コミットすること（即ち、ｒ＝ｍを選択すること）さえ要求できる。そのようなユーザを後で統計上の証拠に基づいて追い出すよりも、２枚の小切手を同じユーザから同じシリアル番号で受け取る機会を得るために、ｒ＞１を選択することを推奨する。
【０１６３】
インデックスｉ1，ｉ2，．．．．，ｉrを受け取るとすぐ、業者はインデックスが受け取ったインデックスｉ1，ｉ2，．．．．，ｉrに対応するそれらのコミットメントＣＭkをデ・コミットする。換言すれば、業者はＣＭi1，ＣＭi2，．．．，ＣＭirをデ・コミットする。即ち、業者は銀行に各ＣＭi1，ＣＭi2，．．．，ＣＭirに対するデ・コミット列を受け取らせる。それにより、もし各ＣＭk＝Ｈ（Ｌk）なら、業者は銀行にＬi1，Ｌi2，．．．，Ｌirを明らかにする。もしコミットメントＣＶが予め銀行に与えられていたら、業者は銀行にリスト（Ｖ1，．．．，Ｖr）を明らかにする。インデックスが銀行が選択した特定のインデックスと一致するそれらリストに対して、銀行はリストに含まれるデータ列（従って、対応する集約トランザクション値も同様に）を見ることができる。もしＣＶが同様にデ・コミットされたら、銀行は（選択されたリストだけでなく）全リストに対する業者の要求された集約トランザクション値を見る。銀行はデ・コミットされたリストに対する集約トランザクション値を再計算でき、業者の側の不正行為をチェックするために、これらの値をＣＶのデ・コミットメントと比較できる。また、そのようなチェックは、各リストがそのリストに含まれるのが適切な小切手だけを含むことをチェックすること、および複数のリストに現れる小切手をチェックすることも含む。
【０１６４】
本発明の第４の実施例で開示されるマイクロペイメント方法およびシステムの最後のステップとして、第五者（銀行、または銀行以外のエンティティ）は支払いプロセスを実行する。即ち、第四者（業者、または業者以外のエンティティ）に掛売金額ＣＲを受け取らせる。場合によっては、そのような行動は一定の条件が満たされる（例えば、小切手の生成に関係する口座に十分な資金が存在する）まで遅延される。また、第五者は、小切手が１または複数の選択されたリストＬi1，Ｌi2，．．．，Ｌirに属する各ユーザの借方に借方金額Ｄを付ける。
【０１６５】
好ましい形態では、業者（または、他の第四者エンティティ）に受け取られる掛売金額ＣＲは、ｍ個のリスト全てに含まれる全ての小切手の合計値Ｖであることが好ましい。即ち、
ＣＲ＝Ｖ＝Ｖ1＋．．．＋Ｖk＋．．．＋Ｖmである。
ＣＲを決定するこの方法を実施するために、ＣＲがＣＲのデ・コミットメントの値から計算できるように、任意のコミットメントＣＶが使用されるべきである。従って、銀行（または、他の第五者）により業者へ支払われる金額ＣＲは、業者により受け取られ、ｍ個のリストＬk（ｋ＝１，．．．，ｍ）にグループ化された全ての小切手の完全に集約された値である。
【０１６６】
本発明の１形態では、ユーザＵに請求される借方金額ＤUは、インデックスが銀行により選択されたインデックスに対応するリストに含まれる全てのユーザの小切手の合計値に関係する値により与えられる。例えば、値ＤUは、この合計金額を数量ｍ／ｒ（選択確率ｓ＝ｒ／ｍの逆数）倍することにより決定される。即ち、
ＤU＝（Ｖi1 U＋Ｖi2 U＋．．．＋Ｖir U）＊（ｍ／ｒ）である。
ここで、Ｖk Uは、Ｌkに含まれるユーザＵの小切手の合計金額である。
【０１６７】
本発明の第４の実施例のもう１つの形態では、各小切手Ｃiは情報をシリアル番号Ｓiに含む。Ｓiは、（各ユーザに対して）小切手を生成するユーザにより発行され、連続的に順序付けられた１から始まる漸進的なシリアル番号デあり、他のデータ列に対するデータ列Ｃiの位置を、（そのユーザからの）データ列Ｃiのきちんとした順番で表すことが好ましい。また、Ｓiは、この業者と一緒にユーザが参加した他のトランザクションＴ1，．．．，Ｔi-1，およびＴi+1，．．．，Ｔnに対するトランザクションＴiの時間の順序を表すことが好ましい。
【０１６８】
本発明のこの形態では、借方金額ＤUは、銀行により支払いに対して選択されたそれらリストに含まれる各小切手のシリアル番号Ｓiを使用して決定される。各トランザクションＴiが等しい値ＴＶを有する場合、単一の小切手Ｃiに対応する借方金額は以下により表される。即ち、
（ＳＮi−Ｓmax,U）＊ＴＶである。
ここで、Ｓmax,Uは、今まで処理され支払いに対して選択されたＣiを生成するユーザＵからの最新の小切手上に現れるシリアル番号を意味する。より詳細な説明は前節IIIで、ユーザが実際の支出額より多く請求されることに対するリスクを解消するために小切手上のシリアル番号の使用に関して記載された。換言すれば、第４の実施例でいったん小切手のｒリストが支払いに対して選択されたら、適切な選択確率はｒ／ｍと仮定して、小切手が本発明の第３の実施例で処理された方法と類似の方法で小切手は個々に処理される。
【０１６９】
図７は、複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立するためのシステム３００を示し、各Ｔiは値ＴＶiを有する。システム３００は、ユーザ、業者、銀行、および第四者の間でデータを伝達するための通信手段を含む。また、システム３００は、第１処理手段３１０、第２処理手段３２０、第３処理手段３３０、および第４処理手段３４０を含む。一般に、４個の全処理手段は、データを記憶するための記憶手段３５１、データを入力するための入力手段３５２、およびシステム命令を実行するＣＰＵ３５３を含む。
【０１７０】
第１処理手段３１０は、各Ｔiに対するデータ列Ｃi（１＜ｉ＜ｎ）を導出し、入力し、記憶するためにユーザによって動作させられる。第２処理手段３２０は業者によって動作させられ、前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループをｍ個のリストＬk（ｋ＝１，．．．，ｍ）へ一意に関連付けるため、および前記リストＬk（ｋ＝１，．．．，ｍ）を入力して記憶するためにＣi（ｉ＝１，．．．ｎ）の受け取りに応答する。各リストＬkはデータ列Ｃk 1，．．．，Ｃkｌkを含み、Σm k=1ｌk＝ｎである。さらに、第２処理手段は、各Ｌkに対するコミットメントＣＭkを計算し、コミットメントＣＭk（ｋ＝１，．．．，ｍ）を入力して記憶するために業者によって動作させられる。
【０１７１】
コミットメントＣＭkを受け取るとすぐ、ｉ1，ｉ2，．．．．，ｉrを表す１または複数の整数を選択し、第二者にインデックスｉ1，ｉ2，．．．．，ｉrを受け取らせるために、第３処理手段３３０は銀行によって動作させられる。ここで、全てのｒに対して、１≦ｉr≦ｍである。インデックスｉ1，ｉ2，．．．．，ｉrを受け取るとすぐ、ＣＭをデ・コミットするために第４処理手段３４０は業者によって動作させられ、それによりＬi1，．．．，Ｌirを銀行に明らかにする。
【０１７２】
システム３００は手段３７０を含み、ユーザの借方に借方金額Ｄを付け、第四者に掛売金額ＣＲを受け取らせるために、Ｌi1，．．．，Ｌirが明らかになるとすぐ、第三者によって動作させられる。
【０１７３】
本発明の各実施例では、不正使用できないハードウェア（例えば、携帯電話のスマートカード、またはプロセッサ）が使用されてセキュリティを提供する。
【０１７４】
要約すると、本発明では、１）支払い選択プロセスでユーザと業者の対話の必要性を除去し、２）時間の制約をシステムに取り込み、３）ユーザに過剰請求するリスクを除去する選択的デポジット・プロトコルを提供し、４）銀行に支払いプロセスへの柔軟性および管理を影響する遅延選択プロトコルを提供する方法とシステムが開示された。
【０１７５】
本発明は特定の好ましい実施例を参照して図示され記載されてきたが、本発明の精神および範囲から逸脱することなく種々の変更をなし得ることは当業者には明らかである。
【図面の簡単な説明】
【０１７６】
【図１】本発明の第１の実施例によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図である。
【図２】本発明の第１の実施例によるトランザクションに対する支払いを確立するためのマイクロペイメント・システムの構成要素を示す略ブロック図である。
【図３】本発明の第２の実施例によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図である。
【図４】本発明の第３の実施例によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図であり、ユーザが実際の支出額より多く請求されることに対するリスクを解消する選択的預金プロトコルを含む。
【図５】本発明の第３の実施例によるトランザクションに対する支払いを確立するためのマイクロペイメント・システムの構成要素を示す略ブロック図である。
【図６】本発明の第４の実施例によるマイクロペイメント・トランザクションのための方法の概要を示す流れ図である。
【図７】本発明の第４の実施例によるトランザクションに対する支払いを確立するためのマイクロペイメント・システムの構成要素を示す略ブロック図である。
【符号の説明】
【０１７７】
１００ システム
１０５ 第１処理手段
１０６ 第２処理手段
１１０ 通信手段
１１４ アドレスバス
１１５ データバス
１２１ 記憶手段
１２２ 入力手段
１４０ 手段
２００ システム
２０５ 第１処理手段
２０６ 第２処理手段
２１０ 通信手段
２１４ アドレスバス
２１５ データバス
２２１ 記憶手段
２２２ 入力手段
２４０ 手段
３００ システム
３１０ 第１処理手段
３２０ 第２処理手段
３３０ 第３処理手段
３４０ 第４処理手段
３５１ 記憶手段
３５２ 入力手段
３７０ 手段

Claims (117)

  1. トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者がＴからＴに関連するデータ列Ｃを導出し、第二者に前記データ列Ｃの少なくとも一部を受け取らせ、
    Ｂ．前記第二者が前記Ｃの少なくとも一部を項目Ｖに関連付け、Ｖは前記第一者が実質的に予測不能であり、
    Ｃ．前記第二者がＶがプロパティＰを満たすか否かを決定し、もしそうなら、第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを前記第二者が前記第三者に受け取らせ、
    Ｄ．Ｉを受け取るとすぐ、前記第三者がＶが前記プロパティＰを満たすか否かを確認し、および
    Ｅ．Ｖが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせる諸ステップから成る方法。
  2. 前記データ列Ｃの少なくとも一部が認証されることを特徴とする、請求項１に記載の方法。
  3. 前記第二者がＶがプロパティＰを満たすか否かを決定するステップが、前記第二者と前記第一者の対話を必要としないことを特徴とする、請求項１に記載の方法。
  4. 前記データ列の一部が前記第一者に代わって第五者により認証されることを特徴とする、請求項２に記載の方法。
  5. 前記第一者が前記データ列ＣをＴから導出するステップが、前記第一者の秘密鍵を使用して、前記第一者がディジタル署名をＴの少なくとも一部に対して生成するステップを含むことを特徴とする、請求項１に記載の方法。
  6. 前記第一者の前記ディジタル署名が、
    （ａ）決定論的署名、
    （ｂ）無作為化された署名、
    （ｃ）オフライン署名、
    （ｄ）オンライン署名、および
    （ｅ）個人情報に基づく署名の少なくとも１つから成ることを特徴とする、請求項５に記載の方法。
  7. 前記第二者が前記項目ＶをＣに関連付けるステップが、前記第二者の秘密鍵を使用して、前記第二者がディジタル署名をＣの少なくとも一部に対して生成するステップを含むことを特徴とする、請求項１に記載の方法。
  8. 前記第二者の前記ディジタル署名が決定論的署名であることを特徴とする、請求項７に記載の方法。
  9. 前記データ列Ｃ、
    ｉ）前記第一者の秘密鍵を使用して計算される、前記トランザクションＴの少なくとも一部に対するディジタル署名
    ｉｉ）前記第一者の秘密鍵を使用して計算されるメッセージ認証コード値、および
    ｉｉｉ）電子小切手の少なくとも１つから成ることを特徴とする、請求項１に記載の方法。
  10. 前記項目Ｖが、
    ａ）前記第二者の秘密鍵を使用して計算される、Ｃに対するディジタル署名、および
    ｂ）前記第二者に既知の秘密鍵を使用して計算されるメッセージ認証コード値の少なくとも１つから成ることを特徴とする、請求項１に記載の方法。
  11. 前記第二者が前記第三者に前記情報Ｉを受け取らせるステップが、
    ａ）前記第二者がＩを前記第三者に送信すること、
    ｂ）前記第二者が第五者にIを前記第三者に送信することを頼むこと、および
    ｃ）前記第二者がＩをファイルに書き込み、前記第三者がＩを前記ファイルから回収することの少なくとも１つを含むことを特徴とする、請求項１に記載の方法。
  12. Ｃを受け取った後に、前記第二者が前記Ｃの信頼性と保全性をチェックするステップをさらに含むことを特徴とする、請求項１に記載の方法。
  13. Ｃの信頼性と保全性をチェックするために、前記第二者が前記第一者に関する公開確認情報を使用することを特徴とする、請求項１２に記載の方法。
  14. 前記公開確認情報が、公開鍵ディジタル署名方式で前記第一者の秘密鍵に対応する前記第一者の公開鍵を含むことを特徴とする、請求項１３に記載の方法。
  15. 前記第二者が前記公開確認情報を使用するステップが、
    （ａ）前記第二者が、前記公開確認情報を前記第一者から得ること、
    （ｂ）前記第二者が、前記公開確認情報を前記データ列Ｃに関連して前記第一者により伝達された情報から得ること、
    （ｃ）前記第二者が、前記公開確認情報をディジタル証明書から得ること、および
    （ｄ）前記第二者が、前記公開確認情報を公然と利用可能な前記第一者についての情報から得ることの少なくとも１つを含むことを特徴とする、請求項１３に記載の方法。
  16. 前記第二者と前記第四者が同一であることを特徴とする、請求項１に記載の方法。
  17. 前記第二者と前記第三者が同一であることを特徴とする、請求項１に記載の方法。
  18. Ｆ（Ｖ）＜ｓである場合のみ（ここで、Ｆは関数、ｓは定数である）、ＶがＰを満たすことを特徴とする、請求項１に記載の方法。
  19. ０＜ｓ＜１であることを特徴とする、請求項１８に記載の方法。
  20. Ｆが任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数であることを特徴とする、請求項１８に記載の方法。
  21. 前記トランザクションＴが部分的にトランザクション値ＴVにより特徴付けられることを特徴とする、請求項１に記載の方法。
  22. 前記第四者により受け取られる前記金額はＴVより大きいことを特徴とする、請求項２１に記載の方法。
  23. 前記トランザクションＴが部分的にトランザクション値ＴVにより特徴付けられ、前記第四者により受け取られる前記金額が（ＴV＊１／ｓ）に等しいことを特徴とする、請求項２０に記載の方法。
  24. （ａ）前記項目Ｖが、前記データ列Ｃに関する前記第二者の前記ディジタル署名を含み、および
    （ｂ）もしＦ（Ｖ）＜ｓなら、Ｖが前記プロパティＰを満たす（ここで、Ｆは任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数である）ことを特徴とする、請求項１に記載の方法。
  25. 前記データ列Ｃが情報をＴに含み、前記情報が、
    ａ）前記第一者の個人情報、
    ｂ）前記トランザクションの時間、および
    ｃ）前記トランザクションの日付の少なくとも１つを含むことを特徴とする、請求項１に記載の方法。
  26. トランザクション値ＴVを有するトランザクションＴに対してユーザＵが業者Ｍへの支払いを確立するための方法であって、
    Ａ．前記ユーザが第１のディジタル署名方式に対して公開鍵と対応する秘密鍵を確立し、Ｔからデータ列Ｃ＝ＳＩＧU（Ｔ）を導出してＣを含む電子小切手を生成し（ここで、ＳＩＧU（Ｔ）は、前記第１のディジタル署名方式の前記トランザクションＴに対するユーザＵの前記ディジタル署名を表す）、
    Ｂ．前記ユーザが前記業者に前記データ列Ｃを受け取らせ、
    Ｃ．前記業者が第２のディジタル署名方式に対して公開鍵と対応する秘密鍵を確立し、前記データ列Ｃを項目Ｖ＝ＳＩＧM（Ｃ）に関連付け（ここで、ＳＩＧM（Ｃ）は、前記第２のディジタル署名方式の前記データ列Ｃに対する前記業者Ｍの前記ディジタル署名を表す）、
    Ｄ．前記業者が値Ｆ（Ｖ）＝Ｆ（ＳＩＧM（Ｃ））を計算し（ここで、Ｆは任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数である）、
    Ｅ．前記業者はＦ（ＳＩＧM（Ｃ））を定数ｓと比較してＦ（Ｖ）＜ｓであるか否かを決定し、もしそうなら、銀行に前記業者の前記公開鍵を入手させ、
    Ｆ．前記銀行が、前記業者の前記公開鍵を使用してＦ（ＳＩＧM（Ｃ））＜ｓであることを確認し、および
    Ｇ．Ｆ（ＳＩＧM（Ｃ））＜ｓである場合にのみ、前記銀行が前記業者に金額Ａ＝［ＴV＊１／ｓ］を受け取らせる諸ステップから成り、
    ここで、ｓは０より大きく１より小さい定数であり、前記電子小切手が前記銀行への提示に選択される確率を表す。
  27. トランザクションＴに対する支払いを確立するためのシステムであって、
    Ａ．第一者、第二者、第三者、および第四者の間でデータを伝達するための通信手段、
    Ｂ．Ｔに関するデータ列Ｃを導出し、入力し、記憶するために第一者により動作させられる第１処理手段、
    Ｃ．項目Ｖを with Ｃの少なくとも一部に関連付け、ＶがプロパティＰを満たすか否かを決定するために第二者により動作させられる第２処理手段、
    （ここで、Ｖは前記第一者が実質的に予測不能）
    Ｄ．第三者に前記第三者がＶがＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせるために、ＶがＰを満たすとき、前記第二者により選択的に動作させられる手段、および
    Ｅ．第四者に金額Ａを受け取らせるために、ＶがＰを満たすとき、前記第三者により選択的に動作させられる手段から成ることを特徴とするシステム。
  28. トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者が第二者からデータ列Ｃの少なくとも一部を受け取り（ここで、前記データ列ＣはＴに関連付けられ）、
    Ｂ．前記第一者が、前記Ｃの少なくとも一部を項目Ｖに関連付け（ここで、Ｖは前記第二者が実質的に予測不能であり）、および
    Ｃ．前記第一者がＶがプロパティＰを満たすか否かを決定し、そうである場合にのみ、前記第一者が第三者に前記第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせ、それによりＶがＰを満たすことを確認したらすぐ、前記第三者が四者に金額Ａを受け取らせることを可能にする諸ステップから成ることを特徴とする方法。
  29. トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者が、第二者から前記第一者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取り、
    ここで、前記項目Ｖは、第三者によりＴから導出されたデータ列Ｃの少なくとも一部に関連付けられ、および
    ここで、Ｖは前記第三者が実質的に予測不能であり、
    Ｂ．Ｉを受け取るとすぐ、前記第一者はＶが前記プロパティＰを満たすか否かを確認し、および
    Ｃ．Ｖが前記プロパティＰを満たす場合にのみ、前記第一者が第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
  30. 時間ｔにより部分的に特徴付けられるトランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者が、ＴからＴに関するデータ列Ｃを導出し（ここで、Ｃは前記時間ｔに関する情報ＩＮを含み）、
    Ｂ．前記第一者が、第二者に前記データ列Ｃの少なくとも一部を受け取らせ（ここで、前記Ｃの少なくとも一部は情報ＩＮを含み）、
    Ｃ．前記第二者が、前記Ｃの少なくとも一部を項目Ｖに関連付け（ここで、Ｖは前記第一者が実質的に予測不能であり）、
    Ｄ．前記第二者がＶがプロパティＰを満たすか否かを決定し、もしそうなら、前記第二者は時間ｔ'で第三者に情報ＩＮ、および前記第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせ、
    Ｅ．Ｉを受け取るとすぐ、前記第三者はＶが前記プロパティＰを満たすか否かを決定し、および
    Ｆ．前記第三者は
    ａ）Ｖが前記プロパティＰを満たし、および
    ｂ）｜ｔ'−ｔ｜が予め定められた時間間隔より小さい場合にのみ第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
  31. 前記予め定められた時間間隔｜ｔ'−ｔ｜がｎ日であり、ｎがゼロでない１から７の整数であることを特徴とする、請求項３０に記載の方法。
  32. 前記予め定められた時間間隔｜ｔ'−ｔ｜が少なくともｍ時間であり、ｍがゼロではない１から２０の整数であることを特徴とする、請求項３０に記載の方法。
  33. 前記第一者がステップＢで前記第二者にＣの一部分を時刻ｔ1＞ｔで受け取らせ、｜ｔ1−ｔ｜が予め定められた値より小さくない限り、前記第二者はＴに対する支払いとしてＣを受け取ることを拒否することを特徴とする、請求項３０に記載の方法。
  34. 前記データ列Ｃが、前記第一者の秘密鍵を使用して生成された、Ｔの少なくとも一部に対するディジタル署名から成ることを特徴とする、請求項３０に記載の方法。
  35. ＶがＰを満たす場合にのみ、ＶがＣの少なくとも一部と一致することを特徴とする、請求項３０に記載の方法。
  36. 前記プロパティＰがＶに依存するが、Ｃには依存しないことを特徴とする、請求項３０に記載の方法。
  37. Ｆ（Ｖ）＜ｓである場合のみ（ここで、Ｆは関数、ｓは定数であり、０＜ｓ＜１である）、ＶがＰを満たすことを特徴とする、請求項３０に記載の方法。
  38. 前記関数Ｆの値Ｆ（Ｖ）は、前記第一者が実質的に予測不能であることを特徴とする、請求項３７に記載の方法。
  39. 前記関数Ｆと前記定数ｓの少なくとも１つがＣで指定されることを特徴とする、請求項３７に記載の方法。
  40. Ｆが
    （ａ）固定公開関数、
    （ｂ）任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数の１つであることを特徴とする、請求項３７に記載の方法。
  41. Ｖが、前記第二者の秘密鍵を使用して計算され、ＳＩＧM（Ｃ）と表される、Ｃに対するディジタル署名を含むことを特徴とする、請求項３０に記載の方法。
  42. もし全てのｉ（ｉ＝１，．．．ｎ）に対して、前記トランザクションＴＳiが時間ＴＳiにより部分的に特徴付けられ、｜ＴＳi−ｔ｜が予め定められた値より小さければ、前記第四者が前記金額を受け取るステップの後、前記第三者が前記第一者に、前記第二者により提供される１または複数のトランザクションＴＳi（ｉ＝１，．．．，ｎ）への無料加入権を受け取らせるステップをさらに含むことを特徴とする、請求項３０に記載の方法。
  43. 前記項目Ｖが
    ａ）Ｔに関係してＣに含まれる日付情報、
    ｂ）Ｃに含まれるシリアル番号、
    ｃ）Ｃに含まれる文字列、
    ｄ）Ｃのランダム文字列部分、および
    ｅ）Ｃに依存する数量の少なくとも１つに対するディジタル署名を含み、
    Ｖが前記第二者の秘密鍵を使用して計算され、ＳＩＧMと表されることを特徴とする、請求項３０に記載の方法。
  44. 前記項目ＶがＧ（Ｃ）のディジタル署名を含み、Ｇは関数とアルゴリズムの少なくとも１つを表すことを特徴とする、請求項３０に記載の方法。
  45. ＶがＰを満たす場合にのみ、Ｆ（Ｖ）＝Ｆ（ＳＩＧM（Ｇ（Ｃ）））＜ｓであり、ここでＦは関数を表し、ｓは定数であって０＜ｓ＜１であり、値Ｆ（Ｖ）は前記第一者が実質的に予測不能であることを特徴とする、請求項４４に記載の方法。
  46. Ｇ（Ｃ）がＴとＣの少なくとも１つの中で指定されることを特徴とする、請求項４４に記載の方法。
  47. Ｇ（Ｃ）が
    （ａ）Ｔの部分列、
    （ｂ）前記トランザクションＴの前記時間ｔに関する情報Ｆ、
    （ｃ）前記トランザクションＴが発生した日付に関する情報、および
    （ｄ）前記第一者により選択された文字列Ｗの少なくとも１つを含むことを特徴とする、請求項４４に記載の方法。
  48. 前記文字列ＷがＴに対して一意であり、アト・ランダムに選択されることを特徴とする、請求項４７に記載の方法。
  49. Ｖ＝ＳＩＧM（Ｇ（Ｃ））が、前記Ｃの少なくとも一部を受け取る前に前記第二者によって計算されるように適応されることを特徴とする、請求項４７に記載の方法。
  50. もしＶ＝ＳＩＧM（Ｇ（Ｃ））の少なくとも数ビットがＣの少なくとも数ビットと一致したら、前記プロパティＰが満たされることを特徴とする、請求項４４に記載の方法。
  51. もしＶ＝ＳＩＧM（Ｇ（Ｃ））の選択されたｍビット列がＣの選択されたｍビット列と一致したら、前記プロパティＰが満たされる（ここで、ｍは予め定められた正の整数）ことを特徴とする、請求項４４に記載の方法。
  52. ｍが１０であることを特徴とする、請求項５１に記載の方法。
  53. トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者がＴからＴに関するデータ列Ｃを導出し、第二者に前記データ列Ｃの少なくとも一部を受け取らせ、
    Ｂ．前記第二者が、プロパティＰが前記Ｃの少なくとも一部とＣに依存する数量Ｑの間に有効であるか否かを決定し（Ｑは前記第一者が実質的に予測不能であり）、もしそうなら、前記第二者は第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
    Ｃ．Ｉを受け取るとすぐ、前記第三者は前記プロパティＰが満たされるか否かを決定し、および
    Ｄ．前記プロパティＰが前記Ｃの少なくとも一部とＱで有効であることを確認したらすぐ、前記第三者は第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
  54. 前記数量ＱはＧ（Ｃ）と表され、Ｇは関数とアルゴリズムの少なくとも１つであることを特徴とする、請求項５３に記載の方法。
  55. Ｇ（Ｃ）は、情報を
    ａ）前記トランザクションＴが発生する時間ｔ、および
    ｂ）前記トランザクションＴが発生する日付ｄの少なくとも１つに含むことを特徴とする、請求項５４に記載の方法。
  56. 前記プロパティＰが有効である場合にのみ、Ｃの少なくとも数ビットがＳＩＧM（Ｇ（Ｃ））の少なくとも数ビットと等しく、ＳＩＧM（Ｇ（Ｃ））はＧ（Ｃ）に対する前記ディジタル署名を表し、前記第二者の秘密鍵を使用して生成されることを特徴とする、請求項５５に記載の方法。
  57. 時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者がＴからＴに関するデータ列Ｃを導出し、
    Ｂ．第二者が、一連の時間ｔi（ｉ＝１，．．．，ｎ）に関連する一連の値ＶＬiを導出し、少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、｜ｔ−ｔm｜が予め定められた値より小さく、
    Ｃ．前記第一者が前記第二者に前記データ列Ｃの少なくとも一部を受け取らせ、前記一部は前記トランザクションＴの時間ｔに関する情報を含み、
    Ｄ．前記第二者は、プロパティＰがＣの一部分とｔmに関連する前記値ＶＬmの１つの間で有効であるか否かを決定し、数量ＱはＶＬmに依存し、
    Ｅ．もしＰが有効なら、前記第二者は第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
    Ｆ．Ｉを受け取るとすぐ、前記第三者はＱがＰを満たすか否かを決定し、および
    Ｇ.Ｑが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせることを特徴とする方法。
  58. 前記数量ＱがＱ＝Ｆ（ＳＩＧM（Ｖm））により与えられ、Ｆは関数を表し、ＳＩＧM（Ｖm）は、前記第二者の秘密鍵を使用して生成されたＶmのディジタル署名を表すことを特徴とする、請求項５７に記載の方法。
  59. トランザクションＴにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者が、ＴからＴに関するデータ列Ｃを導出し、Ｃはｔに関する情報を含み、
    Ｂ．第二者が、一連の時間単位ｔi（ｉ＝１，．．．，ｎ）に関連付けられる一連の値Ｖiを導出し、
    隣接する時間単位ｔi+1とｔiの各ペアが、時間間隔Δｔi＝ｔi+1−ｔiを定め、および
    少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、前記時間ｔは時間間隔Δｔmの範囲内であり、
    Ｃ．前記時間間隔Δｔmのはじめには、前記第二者がＶmに関連する値Ｑmを導出し、Ｑmは前記第一者は実質的に予測不能であり、
    Ｄ．前記時間間隔Δｔmの間に、
    ａ）前記第一者が前記第二者にＣの少なくとも一部を受け取らせ、
    ｂ）前記第二者が、プロパティＰがＣの一部分とＱmの間で有効であるか否かを決定し、もしそうなら、前記第二者は第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
    Ｅ．Ｉを受け取るとすぐ、前記第三者はＱがＰを満たすか否かを決定し、および
    Ｆ．Ｑが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせることを特徴とする方法。
  60. ステップＣがステップＢの前に発生し、前記プロパティＰが満たされる場合にのみ、Ｑの少なくとも数ビットがＣの少なくとも数ビットと一致することを特徴とする、請求項５９に記載の方法。
  61. ＱiがＱi＝Ｆ（ＳＩＧM（Ｖi））により与えられ、Ｆが関数を表し、ＳＩＧM（Ｖi）が、前記第二者の秘密鍵を使用して生成される、Ｖiのディジタル署名を表すことを特徴とする、請求項５９に記載の方法。
  62. 全てのｉ＝１，．．．，ｎに対して、時間間隔Δｔi＝｜ｔi+1−ｔi｜が予め定められた時間間隔であることを特徴とする、請求項５９に記載の方法。
  63. 前記予め定められた定数が１日であることを特徴とする、請求項６２に記載の方法。
  64. 時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者が、ＴをＴに関するデータ列Ｃから導出し、Ｃはｔに関する情報Ｆを含み、
    Ｂ．第二者が、一連の時間の値ｔi（ｉ＝０, 1, ... , n）に関連する一連の値ｘi（ｉ＝０，１，．．．，ｎ）を導出し、ｘ0を公開し、
    ｘi＝Ｈ（ｘi+1）（ｉ＝０，１，．．．，ｎ−１）であって、Ｈは一方向ハッシュ関数であり、
    隣接する時間の値ｔi+1とｔiの各ペアは、時間間隔Δｔiｔi+1−ｔiを定め、および
    少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、前記時間ｔは時間間隔Δｔmであり、
    Ｃ．前記時間間隔Δｔmの間に、前記第一者が前記第二者にＣの少なくとも一部を受け取らせ、前記一部はＦを含み、
    Ｄ．前記時間間隔Δｔmの間に、前記第二者がプロパティＰはＱmとＣの一部分の間で有効であるか否かを決定し、もしそうなら、前記第二者が第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
    Ｅ．Ｉを受け取るとすぐ、前記第三者がＱmはＰを満たすか否かを決定し、および
    Ｆ．Ｑが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
  65. 前記第二者がｘ0を公開するステップが、
    ａ）ｘ0を公開ファイルに配置すること、および
    ｂ）前記第二者の秘密鍵を使用してｘ0にディジタル署名し、対応する公開鍵を公開ディレクトリに配置することの少なくとも１つを含むことを特徴とする、請求項６４に記載の方法。
  66. 前記時間間隔Δｔi＝ｔi+1−ｔiが予め定められた定数（ｉ＝１，．．．，ｎ）であることを特徴とする、請求項６４に記載の方法。
  67. 時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するためのシステムであって、
    Ａ．第一者、第二者、第三者、および第四者の間でデータを伝達するための通信手段、
    Ｂ．Ｔに関するデータ列Ｃを導出し、入力し、記憶するために、第一者による動作させられる第１処理手段（ここで、Ｃは時間ｔに関する情報Ｆを含む）、
    Ｃ．項目ＶをＣの少なくとも一部に関連付け、ＶがプロパティＰを満たすか否かを決定するために、第二者により動作させられてＣに応答する第２処理手段、
    （ここで、Ｖは前記第一者が実質的に予測不能）
    Ｄ．ＶがＰを満たすとき、第三者にＦ、および前記第三者が、
    ａ）ＶがＰを満たすか否か、および
    ｂ）｜ｔ'−ｔ｜が予め定められた値より小さいことを確認することを可能にする情報Ｉを受け取らせるために、前記第二者により選択的に動作させられる手段、
    Ｅ．ＶがＰを満たすとき、および｜ｔ'−ｔ｜が予め定められた値より小さいときに、第四者に金額Ａを受け取らせるために、前記第三者により選択的に動作させられる手段から成ることを特徴とするシステム。
  68. 時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者が、第二者から時間ｔ'に前記第一者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取り、
    前記項目Ｖは、第三者によりＴから導出され、ｔに関する情報を含むデータ列Ｃの少なくとも一部と関連付けられ、および
    Ｖは、前記第三者が実質的に予測不能であり、
    Ｂ．Ｉを受け取るとすぐ、前記第一者がＶが前記プロパティＰを満たすか否かを確認し、および
    Ｃ．前記第一者は、
    ａ）Ｖが前記プロパティＰを満たし、および
    ｂ）｜ｔ'−ｔ｜が予め定められた値より小さい場合にのみ、第四者に金額Ａを受け取らせることを特徴とするシステム。
  69. 時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
    Ａ．第一者が第二者からデータ列Ｃの少なくとも一部を受け取り、前記データ列ＣはＴに関連し、Ｃの一部分は情報をｔに含み、
    Ｂ．前記第一者が前記Ｃの少なくとも一部を項目Ｖに関連付け、Ｖは前記第二者が実質的に予測不能であり、および
    Ｃ．前記第一者がＶがプロパティＰを満たすか否かを決定し、もしそうなら、時間ｔ'に前記第一者が第三者に前記第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせ、それにより前記第三者が
    ａ）ＶがＰを満たし、および
    ｂ）｜ｔ'−ｔ｜が予め定められた値より小さい場合にのみ、第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
  70. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立するための方法であって、インデックスｉ（１＜ｉ＜ｎ）が各Ｔiに関連付けられ、各トランザクションＴiがトランザクション値ＴＶiにより部分的に特徴付けられ、
    Ａ．第一者が確率的支払い方式を使用して小切手Ｃiを各トランザクションＴiに対して生成し、第二者に前記Ｃiを受け取らせ、Ｃiは前記インデックスｉの表示を含み、
    Ｂ．前記第二者が、支払い可能な前記小切手Ｃj（１≦ｊ≦ｎ）を、前記第一者がどの小切手Ｃjが支払い可能に選択されるか前もって予測することを防ぐ方法で選択し、
    Ｃ．前記第二者が、前記第三者が選択された小切手Ｃjが支払い可能であることを確認することを可能にする情報Ｉjを第三者に受け取らせ、
    Ｄ．Ｉjの受け取りに応答して、前記第三者が、選択された小切手Ｃjが支払い可能であることを確認し、および
    Ｅ．Ｃjが支払い可能である場合にのみ、第五者が第四者に売掛金額ＣＲjを受け取らせ、前記第一者の借方に借方金額Ｄjを付け、全インデックスｊ（１＜ｊ＜ｎ）に対して、および支払い可能な小切手のどの部分に対しても、Ｄ＝Ｄ1＋Ｄ2＋．．．＋ＤjがＴＶagg＝ＴＶ1＋ＴＶ2＋．．．+ＴＶjより大きくならないようにする。
  71. 各借方金額Ｄjが、ＴＶjとＣj（１＜ｊ＜ｎ）の１つにより少なくとも部分的に決定されることを特徴とする、請求項７０に記載の方法。
  72. 各借方金額Ｄjが、Ｔjに関連付けられる前記インデックスｊに依存することを特徴とする、請求項７０に記載の方法。
  73. 各借方金額Ｄjも前の借方金額Ｄk（１≦ｋ＜ｊ≦ｎ）の少なくとも１つに依存し、前のインデックスｌ（１≦ｌ＜ｊ≦ｎ）に対して借方金額Ｄlが付けられることを特徴とする、請求項７２に記載の方法。
  74. 前記第五者が、前記インデックスｊの表示を支払いに対して選択された各小切手Ｃjに対して記憶させるステップをさらに含むことを特徴とする、請求項７０に記載の方法。
  75. 支払い可能な小切手Ｃjの各借方金額Ｄjが、支払い可能であることが分かった前の小切手の一番後で記憶されたインデックスｋに依存することを特徴とする、請求項７４に記載の方法。
  76. 前記第二者が前記第三者に前記情報Ｉを受け取らせるステップが、
    ａ）前記第二者がＩjを前記第三者に送信すること、
    ｂ）前記第二者が第五者にIjを前記第三者に送信することを頼むこと、および
    ｃ）前記第二者がＩjをファイルに書き込み、前記第三者がＩjを前記ファイルから回収することの少なくとも１つを含むことを特徴とする、請求項７０に記載の方法。
  77. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立するための方法であって、インデックスｉ（１＜ｉ＜ｎ）が各Ｔiに関連付けられ、各トランザクションＴiがトランザクション値ＴＶiにより部分的に特徴付けられ、
    Ａ．第一者が各トランザクションＴiからＴiに関連するデータ列Ｃiを導出し、第二者に前記データ列Ｃiを受け取らせ、
    Ｂ．前記第二者が各データ列Ｃiを項目Ｖiに関連付け、Ｖiは前記第一者が実質的に予測不能であり、
    Ｃ．前記第二者がＶiはプロパティＰiを満たすか否かを決定し、もしそうなら、前記第二者が前記第三者がＶiは前記プロパティＰiを満たすか否かを決定することを可能にする情報Ｉiを第三者に受け取らせ、
    Ｄ．Ｉiに応答して、前記第三者がＶiは前記プロパティＰiを満たすか否かを決定し、および
    Ｅ．Ｖiが前記プロパティＰiを満たす場合にのみ、第五者が第四者に売掛金額ＣＲiを受け取らせ、前記第一者の借方に借方金額Ｄiを付け、
    前記借方金額Ｄiは前記売掛金額ＣＲi以下であることを特徴とする方法。
  78. Ｄ1＋Ｄ2＋．．．＋Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶ1＋ＴＶ2＋．．．＋ＴＶi以下であることを特徴とする、請求項７７に記載の方法。
  79. 各借方金額Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶiとＣiの１つにより少なくとも部分的に決定されることを特徴とする、請求項７７に記載の方法。
  80. 各データ列Ｃiが、Ｔiに関連する前記インデックスｉの表示を含むことを特徴とする、請求項７７に記載の方法。
  81. 各借方金額Ｄiが、Ｔiに関連する前記インデックスｉに依存することを特徴とする、請求項８０に記載の方法。
  82. 各借方金額Ｄiも、借方金額Ｄjと借方金額Ｄkが借方に付けられる前のインデックスｋの少なくとも１つに依存することを特徴とする、請求項８１に記載の方法。
  83. Ｄ1＋Ｄ2＋．．．＋Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶ1＋ＴＶ2＋．．．＋ＴＶi以下であることを特徴とする、請求項８２に記載の方法。
  84. ＶiがＰiを満たすときはいつも、前記第五者が情報ＳＮiを各データ列Ｃiに対して記憶させるステップをさらに含むことを特徴とする、請求項７７に記載の方法。
  85. ＳＮiは、前記第一者により導出された順番に並べられたデータ列にある他のデータ列Ｃ1，．．．，Ｃi-1およびＣi+1，．．．，Ｃnに対する前記データ列Ｃiの順番を表す漸進的シリアル番号であることを特徴とする、請求項８４に記載の方法。
  86. 各借方金額ＤiがＳＮiを使用して決定されることを特徴とする、請求項８４に記載の方法。
  87. Ｄ1＋Ｄ2＋．．．＋Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶ1＋ＴＶ2＋．．．＋ＴＶi以下であることを特徴とする、請求項８４に記載の方法。
  88. 各借方金額ＤiがＳＮiを使用して決定されることを特徴とする、請求項８４に記載の方法。
  89. 複数の同じ値のトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対して支払うための方法であって、各々が値ＴＶを有し、
    Ａ．第一者が各トランザクションＴiからＴiに関するデータ列Ｃiを導出し、第二者に前記データ列Ｃiを受け取らせ、
    ここで、各データ列Ｃiは漸進的シリアル番号Ｓiから成り、前記シリアル番号Ｓiは1から順番に始まり、データ列Ｃj（ｊ＝１，．．．，ｎ）の他のデータ列に対するＣiの位置を表し、
    Ｂ．前記第二者がＣiを項目Ｖiに関連付け、Ｖiは前記第一者が実質的に予測不能であり、
    Ｃ．前記第二者が、プロパティＰiはＣiとＶiの間で有効であるか否かを決定し、もしそうなら、前記第二者が、前記第三者がＶiはＰiを満たすか否かを確認することを可能にする情報Ｉiを第三者に受け取らせ、
    Ｄ．前記第三者がＶiはＰiを満たすか否かを確認し、ＶiがＰiを満たす場合にのみ、
    ａ）第五者がＳmaxの値を決定し、ここで、ＳmaxはＣkに含まれるシリアル番号Ｓkの最大値を表し、
    ｉ）１＜ｋ＜ｎ
    ii）Ｃkは、Ｃiを受け取る前に第二者により受け取られ、
    iii）前記第三者は、ＶkがＰkを満たすことを確認し、および
    iv）前記第一者はゼロでないＤkを借方に付けられ、
    ｂ）前記第五者は第四者に売掛金額ＣＲを受け取らせ、および
    ｃ）前記第五者は前記第一者の借方に借方金額Ｄiを付け、Ｄiは（Ｓi−Ｓmax）＊ＴＶにより与えられる諸ステップから成ることを特徴とする方法。
  90. ＶiがＰiを満たす場合にのみＦ（Ｖi）＜ｓであり、ｓは数値であり、Ｆはビット文字列に作用して数値を戻す関数であることを特徴とする、請求項８９に記載の方法。
  91. 前記第四者により受け取られる前記売掛金額ＣＲがＴＶおよび１／ｓに比例することを特徴とする、請求項９０に記載の方法。
  92. Ｆはビット文字列に作用して０と１の間の数値を出力する関数であり、ｓは０と１の間の数値であることを特徴とする、請求項９０に記載の方法。
  93. トランザクション値ＴＶi（ｉ＝１，．．．，ｎ）を有する複数のトランザクションＴi（ｉ＝１，．．．，ｎ）に対してユーザＵが業者Ｍへの支払いを確立する方法であって、
    Ａ．前記ユーザＵが第１のディジタル署名方式に対する公開鍵と対応する秘密鍵を確立し、各Ｔiからデータ列Ｃi＝ＳＩＧU（Ｔi）を導出し、Ｃiとシリアル番号Ｓiを含む電子小切手ＣＨiを生成し、
    ここで、ＳＩＧU（Ｔi）は、前記第１のディジタル署名方式の前記トランザクションＴiに対する前記ユーザＵiの前記ディジタル署名を表し、
    ここで、Ｓiは、前記第一者により導出された順番に並べられたデータ列Ｃj（ｊ＝１，．．．，ｎ）の他のデータ列に対する前記データ列Ｃiの順番を表す漸進的シリアル番号であり、
    Ｂ．前記ユーザＵは、前記業者ＭにＣiとＳiを含む前記電子小切手ＣＨiを受け取らせ、
    Ｃ．前記業者Ｍは第２のディジタル署名方式に対する公開鍵と対応する秘密鍵を確立し、前記データ列Ｃiを項目Ｖi＝ＳＩＧM（Ｃi）に関連付け（ここで、ＳＩＧM（Ｃi）は、前記第２のディジタル署名方式の前記データ列Ｃiに対する前記業者Ｍの前記ディジタル署名を表し）、
    Ｄ．前記業者Ｍが値Ｆ（Ｖi）=Ｆ（ＳＩＧM（Ｃi））を計算し（ここで、Ｆは任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数である）、
    Ｅ．前記業者ＭがＦ（ＳＩＧM（Ｃi））を定数ｓ（０＜ｓ＜１）と比較して、Ｆ（Ｖi）＜ｓであるか否かを決定し、もしそうなら、銀行に前記業者Ｍの前記公開鍵を入手させ、
    Ｆ．前記銀行は、前記業者の公開鍵を使用してＦ（ＳＩＧM（Ｃi））＜ｓであることを確認し、および
    Ｇ．Ｆ（ＳＩＧM（Ｃi））＜ｓである場合にのみ、
    ａ）第五者がＳmaxの値を決定し（ここで、Ｓmaxは、支払いが行われた、順番に並べられた前記ＣＨjに含まれる最大のシリアル番号Ｓjを表す）、
    ｂ）前記第五者が第四者に売掛金額ＣＲを受け取らせ、および
    ｃ）前記第五者が前記第一者の借方に借方金額Ｄiを記入させる諸ステップから成る方法。
  94. 全てのｉ＝１，．．．，ｎに対してＴＶi＝ＴＶであるように各トランザクションＴi（ｉ＝１，．．．，ｎ）が同じ値であり、Ｄiが
    Ｄi＝（Ｓi−Ｓmax）＊ＴＶにより与えられ、
    およびＣＲが
    ＣＲ＝ＴＶ＊（１／ｓ）により与えられことを特徴とする、請求項９３に記載の方法。
  95. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立するためのシステムであって、インデックスｉ（１＜ｉ＜ｎ）が各Ｔiに関連付けられ、各トランザクションＴiが部分的にトランザクション値ＴＶiにより特徴付けられ、
    Ａ．第一者、第二者、第三者、および第四者の間でデータを伝達するための通信手段、
    Ｂ．データ列Ｃi（１≦ｉ≦ｎ）を導出し、入力し、記憶するために第一者により作動させられる第１処理手段（ここで、ＣiはトランザクションＴiに関連付けられ、および
    Ｃiは、小切手Ｃj（ｊ＝１，．．．，ｎ）の他の小切手に対する小切手Ｃiの位置を表す漸進的シリアル番号Ｓiを含み）
    Ｃ．項目ＶiをＣiの少なくとも一部に関連付け、ＶiがプロパティＰiを満たすか否かを決定するために、Ｃiに応答して第二者により作動させられる第２処理手段（ここで、Ｖiは前記第一者が実質的に予測不能であり、
    ＶiがＰiを満たすとき、前記第三者がＶiがＰiを満たすか否かを決定することを可能にする情報Ｉiを第三者に受け取らせるために、前記第２処理手段は前記第二者により選択的に動作させられる）
    Ｄ．Ｓmaxの値を決定し、第四者に金額ＣＲiを受け取らせ、前記第一者の借方にＤiを付けるために、ＶiがＰiを満たすとき前記第三者により選択的に動作させられる手段（ここで、全てのインデックスｉ（１＜ｉ＜ｎ）に対して、Ｄ1＋Ｄ2＋．．．＋ＤiはＴＶ1＋ＴＶ2＋．．．＋ＴＶiより大きくない）から成ることを特徴とするシステム。
  96. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、インデックスｉ（１＜ｉ＜ｎ）が各Ｔiに関連付けられ、各トランザクションＴiが部分的にトランザクション値ＴＶiにより特徴付けられ、
    Ａ．第一者が、第二者から各Ｔiに対するデータ列Ｃiの少なくとも一部を受け取り、各データ列Ｃiが確率的支払い方式を使用してＴiから生成され、各Ｃiが前記インデックスｉの表示を含み、
    Ｂ．前記第一者が、前記第一者がどの小切手Ｃjが支払い可能に選択されるかを前もって予測できない方法で支払い可能な小切手Ｃj（１≦ｊ≦ｎ）を選択し、
    Ｃ．各選択された小切手Ｃjに対して、前記第一者が、前記第三者が選択された小切手Ｃjが確かに支払い可能であることを確認することを可能にする情報Ｉjを第三者にに受け取らせ、それによりＣjが支払い可能であることを確認したらすぐ、前記第三者が第四者に売掛金額ＣＲjをを受け取らせ、前記第二者の借方に借方金額Ｄjを付け、全てのインデックスｊ（１≦ｊ≦ｎ）、および支払い可能な小切手Ｃjの選択に対して、Ｄ＝Ｄ1＋Ｄ2＋．．．＋ＤjがＴＶagg＝ＴＶ1＋ＴＶ2＋．．．＋ＴＶjより大きくない諸ステップから成ることを特徴とする方法。
  97. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、インデックスｉ（１＜ｉ＜ｎ）が各Ｔiに関連付けられ、各トランザクションＴiが部分的にトランザクション値ＴＶiにより特徴付けられ、対応するデータ列Ｃiにより表され、
    Ａ．第一者が、前記第一者が小切手Ｃjが支払い可能であることを確認することを可能にする情報Ｉjを第二者から受け取り、
    wherein 前記小切手Ｃjは、前記複数のトランザクションＴi（ｉ＝１，．．．，ｎ）の１つに対応するものから第三者により導出された複数の小切手Ｃi（ｉ＝１，．．．，ｎ）から前記第二者により選択され、および
    前記小切手Ｃjの選択は、前記第三者が実質的に予測不能であり、
    Ｂ．Ｉjを受け取るとすぐ、前記第一者がＣjが確かに支払い可能であるかを確認し、および
    Ｃ．前記第一者が第四者に売掛金額ＣＲiを受け取らせ、前記第三者の借方に借方金額Ｄiを付ける諸ステップから成ることを特徴とする方法。
  98. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、各トランザクションＴiが部分的に単位値ＵＶの整数倍であるトランザクション値ＴＶiにより特徴付けられ、
    Ａ．第一者が、各トランザクションＴiからＴiに対応するデータ列Ｃiを導出し、第二者にＣiを受け取らせ、
    ここで、各データ列Ｃiは、情報を前記整数インデックスｉ、および Ｔiの前記値ＴＶiにベクトル（Ｓi，Ｓi＋ｖi−１）の形式で含み、
    全てのｉ（１＜ｉ＜ｎ）に対して、Ｓiは、順番に並んだ、データ列Ｃj（ｊ＝１，．．．，ｎ）の他のデータ列に対するＣiの位置を表す漸進的シリアル番号であり、および
    ｖiはｉに依存する１つの整数であって、Ｔiの値ＴＶiを表し、ｖi＝ＴＶi／（ＵＶ）により与えられ、
    Ｂ．前記第二者が、支払い可能である前記小切手Ｃj（１≦ｊ≦ｎ）を、前記第一者がどの小切手Ｃjが支払い可能になるかを前もって予測することを防ぐ方法で選択し、
    Ｃ．前記第二者が、前記第三者が選択された小切手Ｃjが支払い可能であることを確認することを可能にする情報Ｉjを第三者に受け取らせ、
    Ｄ．Ｉjの受け取りに応答して、前記第三者が、選択された小切手Ｃjが支払い可能であることを確認し、
    Ｅ．Ｃjが支払い可能である場合にのみ、
    ａ）第五者が、Ｓmaxの値を決定し、
    ここで、ｍａｘは is １つの整数（例えば、１≦ｍａｘ＜ｉ≦ｎ）であり、ｖmax＝ＴＶmax／（ＵＶ）であり、および
    ここで、Ｓmaxは、Ｃkに含まれるシリアル番号Ｓk（１≦ｋ＜ｎ）の最大値を表し、
    ｉ）Ｃkは、Ｃiを受け取る前に前記第二者により受け取られ、および
    ii）前記第三者が、ＶkはＰkを満たすことを確認し、および
    iii）前記第一者が、ゼロではない金額Ｄkを借方に付けられ、および
    ｂ）前記第五者が、第四者に売掛金額ＣＲを受け取らせ、および
    ｃ）前記第五者が、前記第一者の借方に借方金額Ｄiを付け、Ｄiが（Ｓi＋ｖi−１−Ｓmax）＊ＵＶにより与えられる諸ステップから成ることを特徴とする方法。
  99. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立するための方法であって、インデックスｉ（１＜ｉ＜ｎ）が各Ｔiに関連付けられ、各トランザクションＴiが部分的に単位値ＵＶの整数倍であるトランザクション値ＴＶiにより特徴付けられ、
    Ａ．第一者が、各トランザクションＴiからＴiに対応するデータ列Ｃiを導出し、第二者にＣiを受け取らせ、
    ここで、各データ列Ｃiは、情報を前記整数インデックスｉに、およびＴiの前記値ＴＶiをベクトル（Ｓi，Ｓi＋ｖi−１）の形式で含み、;
    全てのｉ（１＜ｉ＜ｎ）に対して、Ｓiは、順番に並んだ、データ列Ｃj（ｊ＝１，．．．，ｎ）の他のデータ列に対するＣiの位置を表す漸進的シリアル番号であり、および
    ここで、ｖiはｉに依存する１つの整数であり、Ｔiの値ＴＶiを表し、ｖi＝ＴＶi／（ＵＶ）により与えられ、
    Ｂ．前記第二者がＣiを項目Ｖiに関連付け、Ｖiは前記第一者が実質的に予測不能であり、
    Ｃ．前記第二者が、プロパティＰiはＣiとＶiの間で有効であるか否かを決定し、もしそうなら、前記第二者が、前記第三者がＶiはＰiを満たすか否かを確認することを可能にする情報Ｉiを第三者に受け取らせ、
    Ｄ．前記第三者が、ＶiはＰiを満たすか否かを確認し、
    および、ＶiがＰiを満たす場合にのみ、
    ａ）第五者が、Ｓmaxの値を決定し、
    ここで、ｍａｘは１つの整数（例えば、１≦ｍａｘ＜ｉ≦ｎ）であり、ｖmax＝ＴＶmax／（ＵＶ）であり、および
    Ｓmaxは、Ｃkに含まれるシリアル番号Ｓk（１≦ｋ＜ｎ）の最大値を表し、
    ｉ Ｃkは、Ｃiを受け取る前に前記第二者により受け取られ、
    ii）前記第三者が、ＶkはＰkを満たすことを確認し、
    iii）前記第一者が、ゼロではない金額Ｄkを借方に付けられ、および
    ｂ）前記第五者が、第四者に売掛金額ＣＲを受け取らせ、および
    ｃ）前記第五者が、前記第一者の借方に借方金額Ｄiを付け、Ｄiは（Ｓi＋ｖi−１−Ｓmax）＊ＵＶにより与えられる諸ステップから成ることを特徴とする方法。
  100. 複数のｎトランザクションＴi（ｉ＝１，．．．，ｎ）に対する支払いを確立する方法であって、各トランザクションＴiは値ＴＶiを有し、
    ａ．第一者が各ＴiからＴiに関連するデータ列Ｃiを導出し、第二者に前記データ列Ｃiを受け取らせ、
    ｂ．前記第二者は、前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループをｍ個のリストＬk（ｋ＝１，．．．，ｍ）へ一意に関連付け、
    ここで、各リストＬkは、データ列Ｃk 1，．．．，Ｃkｌkを含み、
    Σm k=1ｌk＝ｎであり、
    ｃ．各Ｌkに対するコミットメントＣＭkを計算し、第三者にＣＭk（ｋ＝１，．．．，ｍ）を受け取らせることにより、前記第二者がＬk（ｋ＝１，．．．，ｍ）にコミットし、
    ｄ．ＣＭk（ｋ＝１，．．．，ｍ）の受け取りに応答して、前記第三者が１または複数の整数インデックスｉ1，ｉ2，．．．，ｉrを選択し、前記第二者に前記インデックスｉ1，ｉ2，．．．，ｉr（１≦ｉr≦ｍ）を受け取らせ
    ｅ．前記インデックスｉ1，ｉ2，．．．，ｉrの受け取りに応答して、前記第二者がＣＭi1，ＣＭi2．．．ＣＭirをデ・コミットし、それによりＬi1，．．．，Ｌirを前記第三者に明らかにし、および
    ｆ．第五者が第四者に売掛金額ＣＲを受け取らせ、前記第一者の借方に借方金額Ｄを付ける諸ステップから成ることを特徴とする方法。
  101. Ｌkに対する前記コミットメントＣＭkはハッシュ値Ｈ（Ｌk）であり、Ｈは一方向ハッシュ関数であることを特徴とする、請求項１００に記載の方法。
  102. 各データ列Ｃiが、前記トランザクション値ＴＶiを表す１または複数のビットを含むことを特徴とする、請求項１００に記載の方法。
  103. 前記第二者が各リストＬkを対応する値Ｖkに関連付け、ＶkはリストＬkの全てのデータ列Ｃk 1，．．．，Ｃkｌkの集約値を表し、ＶkはＶk＝ＴＶk 1＋．．．＋ＴＶkｌkにより与えられるステップをステップ（ｂ）の後にさらに含むことを特徴とする、請求項１０２に記載の方法。
  104. 前記第二者が、値（Ｖ1，．．．，Ｖm）のリストに対するコミットメントＣＶを計算し、
    前記コミットメントＣＶは、前記第二者を（Ｖ1，．．．，Ｖm）にコミットさせ、
    ＣＶはハッシュ値Ｈ（Ｖ1，．．．，Ｖm）であり、および
    Ｈは一方向ハッシュ関数であり、ＣＶをデ・コミットすることにより、前記第二者が reveals （Ｖ1，．．．，Ｖm）を前記第三者に明らかにするステップをステップ（ｃ）の後にさらに含むことを特徴とする、請求項１０３に記載の方法。
  105. 前記第四者により受け取られた前記売掛金額ＣＲは、
    Ｖ＝Ｖ1＋...＋Ｖk＋．．．＋Ｖm＝Σm k=1Ｖkにより与えられることを特徴とする、請求項１００に記載の方法。
  106. 前記借方金額Ｄは、
    スケール因子を掛けられたＤ＝Ｖi1＋Ｖi2＋．．．＋Ｖirにより与えられることを特徴とする、請求項１００に記載の方法。
  107. 前記スケール因子がｍ／ｒであることを特徴とする、請求項１０６に記載の方法。
  108. 前記各データ列Ｃiが１つの整数ＳＮiを表す情報を含み、ＳＮiは１から始まる漸進的シリアル番号であり、前記シリアル番号ＳＮiは、前記複数のｎトランザクションＴi（ｉ＝１，．．．，ｎ）の他のトランザクションＴ1，．．．，Ｔi-1およびＴi+1，．．．，Ｔnに対する前記トランザクションＴiの時間の順序を表すことを特徴とする、請求項１００に記載の方法。
  109. 前記第一者が前記データ列ＣiをＴiから導出するステップが、前記第一者が前記第一者の秘密鍵を使用してＴの少なくとも一部iに対するディジタル署名を生成するステップを含むことを特徴とする、請求項１００に記載の方法。
  110. Ｃiの少なくとも一部が認証されることを特徴とする、請求項１００に記載の方法。
  111. Ｃiが、
    ａ）Ｔの少なくとも一部に対するディジタル署名、
    ｂ）メッセージ認証コード、および
    ｃ）電子小切手の少なくとも１つを含むことを特徴とする、請求項１００に記載の方法。
  112. 前記第五者と前記第三者が同じであることを特徴とする、請求項１００に記載の方法。
  113. 前記第二者、前記第三者、および前記第五者が同じであることを特徴とする、請求項１００に記載の方法。
  114. 前記第二者と前記第三者が同じであることを特徴とする、請求項１００に記載の方法。
  115. 複数のｎトランザクションＴ1，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、各トランザクションＴiは値ＴＶiを有し、
    Ａ．各Ｔiに対して、第一者が第二者からＴiから導出されたデータ列Ｃiを受け取り、
    Ｂ．前記第一者が、前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループをｍ個のリストＬk（ｋ＝１，．．．，ｍ）に一意に関連付け、
    ここで、各リストＬkはデータ列Ｃk 1，．．．，Ｃkｌkを含み、および
    Σm k=1ｌk＝ｎであり、
    Ｃ．前記第一者が、各Ｌkに対するコミットメントＣＭkを計算することによりＬk（ｋ＝１，．．．，ｍ）にコミットし、第三者にＣＭk（ｋ＝１，．．．，ｍ）を受け取らせ、それにより前記第三者が１または複数の整数インデックスｉ1，ｉ2，．．．，ｉr（１≦ｉr≦ｍ）を選択することを可能にし、
    Ｄ．前記インデックスｉ1，ｉ2，．．．，ｉrを受け取るとすぐ、前記第一者がＣＭi1，ＣＭi2．．．ＣＭirをデ・コミットし、それによりＬi1，．．．，Ｌirを前記第三者に明らかにし、前記第三者が第四者に売掛金額ＣＲを受け取らせ、前記第二者の借方に借方金額Ｄを付けることを可能にする諸ステップから成ることを特徴とする方法。
  116. 複数のｎトランザクションＴ1，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、各トランザクションＴiは値ＴＶiを有し、Ｔiから導出される対応するデータ列Ｃiにより表され、前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループがｍ個のリストＬk（ｋ＝１，．．．，ｍ）に一意に関連付けられ、各リストＬkはデータ列Ｃk 1，．．．，Ｃkｌk（Σm k=1ｌk＝ｎ）を含み、
    Ａ．第一者が、第二者から各ｍ個のリストＬk（ｋ＝１，．．．，ｍ）に対するコミットメントＣＭkを受け取り、
    Ｂ．ＣＭk（ｋ＝１，．．．，ｍ）を受け取るとすぐ、前記第一者が１または複数の整数インデックスｉ1，ｉ2，．．．ｉr（１≦ｉr≦ｍ）を選択し、前記第二者に前記インデックスｉ1，ｉ2，．．．，ｉrを受け取らせ、それにより前記第二者がＣＭi1，ＣＭi2．．．ＣＭirをデ・コミットしてＬi1，．．．，Ｌirを to 前記第一者に明らかにすることを可能にし、
    Ｃ．前記第一者が第三者に売掛金額ＣＲを受け取らせ、第四者の借方に借方金額Ｄを付ける諸ステップから成ることを特徴とする方法。
  117. 複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立するためのシステムであって、各Ｔiは値ＴＶiを有し、
    Ａ．第一者、第二者、第三者、および第四者の間でデータを伝達するための通信手段、
    Ｂ．各Ｔiに対するデータ列Ｃi（１≦ｉ≦ｎ）を導出し、入力し、記憶するために第一者により動作させられる第１処理手段、
    Ｃ．前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループをｍ個のリストＬk（ｋ＝１，．．．，ｍ）へ一意に関連付け、前記リストＬk（ｋ＝１，．．，ｍ）を入力し記憶するために、Ｃi（ｉ＝１，．．．ｎ）の受け取りに応答して第二者により動作させられる第２処理手段、
    （ここで、各リストＬkはデータ列Ｃk 1，．．．，Ｃkｌkを含み、
    Σm k=1ｌk＝ｎであり、
    各Ｌkに対するコミットメントＣＭkを計算し、前記コミットメントＣＭk（ｋ＝１，．．．，ｍ）を入力して記憶するために、記第２処理手段は前記第二者により動作させられ、）
    Ｄ．前記コミットメントＣＭkを受け取るとすぐ、１または複数の整数インデックスｉ1，ｉ2，．．．，ｉrを選択し、前記第二者に前記インデックスｉ1，ｉ2，．．．，ｉr（１≦ｉr≦ｍ）を受け取らせるために前記第三者により動作させられる第３処理手段、
    Ｅ．前記インデックスｉ1，ｉ2，．．．，ｉrを受け取るとすぐ、ＣＭをデ・コミットするために前記第二者により動作させられ、それにより前記第三者に明らかにする第４処理手段、および
    Ｆ．Ｌi1，．．．，Ｌirを受け取るとすぐ、前記第一者の借方に借方金額Ｄを付け、第四者に売掛金額ＣＲを受け取らせるために前記第三者により動作させられる手段から成ることを特徴とするシステム。
JP2002586109A 2001-04-27 2002-04-17 マイクロペイメント・トランザクションのための方法およびシステム Pending JP2004527051A (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US28725101P 2001-04-27 2001-04-27
US30625701P 2001-07-18 2001-07-18
US34420501P 2001-12-26 2001-12-26
PCT/US2002/012189 WO2002088874A2 (en) 2001-04-27 2002-04-17 Method and system for micropayment transactions

Publications (1)

Publication Number Publication Date
JP2004527051A true JP2004527051A (ja) 2004-09-02

Family

ID=27403687

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002586109A Pending JP2004527051A (ja) 2001-04-27 2002-04-17 マイクロペイメント・トランザクションのための方法およびシステム

Country Status (6)

Country Link
US (2) US20040199475A1 (ja)
EP (1) EP1410289A4 (ja)
JP (1) JP2004527051A (ja)
CN (1) CN1535440A (ja)
CA (1) CA2445573A1 (ja)
WO (1) WO2002088874A2 (ja)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2445573A1 (en) * 2001-04-27 2002-11-07 Massachusetts Institute Of Technology Method and system for micropayment transactions
KR20040002928A (ko) * 2001-05-31 2004-01-07 인터내셔널 비지네스 머신즈 코포레이션 소액지불 시스템
US7152048B1 (en) * 2002-02-07 2006-12-19 Oracle International Corporation Memphis: multiple electronic money payment highlevel integrated security
US20110202565A1 (en) * 2002-12-31 2011-08-18 American Express Travel Related Services Company, Inc. Method and system for implementing and managing an enterprise identity management for distributed security in a computer system
US20060149671A1 (en) * 2004-06-25 2006-07-06 Robert Nix Payment processing method and system
US7665658B2 (en) * 2005-06-07 2010-02-23 First Data Corporation Dynamic aggregation of payment transactions
US20070078764A1 (en) * 2005-10-04 2007-04-05 International Business Machines Corporation Scalable lazy payment capture in online commerce systems
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US20070168297A1 (en) * 2006-01-18 2007-07-19 Cheng Siu L Efficient method and system for secure business-to-business transaction
US8300798B1 (en) 2006-04-03 2012-10-30 Wai Wu Intelligent communication routing system and method
US20080040261A1 (en) * 2006-04-24 2008-02-14 Robert Nix Systems and methods for implementing financial transactions
CN101569132B (zh) * 2006-11-07 2013-04-17 安全第一公司 用于分发数据和保护数据安全的系统和方法
US8521650B2 (en) 2007-02-26 2013-08-27 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US8087060B2 (en) * 2007-03-16 2011-12-27 James Mark Norman Chaining information card selectors
US8151324B2 (en) 2007-03-16 2012-04-03 Lloyd Leon Burch Remotable information cards
US20090249430A1 (en) * 2008-03-25 2009-10-01 Novell, Inc. Claim category handling
US20090228885A1 (en) * 2008-03-07 2009-09-10 Novell, Inc. System and method for using workflows with information cards
US20090070263A1 (en) * 2007-09-12 2009-03-12 Wachovia Corporation Peer to peer fund transfer
US20090070262A1 (en) * 2007-09-12 2009-03-12 Ebay Inc. Ach-enabled micropayments
US20090198619A1 (en) * 2008-02-06 2009-08-06 Motorola, Inc. Aggregated hash-chain micropayment system
US20090205035A1 (en) * 2008-02-11 2009-08-13 Novell, Inc. Info card selector reception of identity provider based data pertaining to info cards
US8468576B2 (en) 2008-02-11 2013-06-18 Apple Inc. System and method for application-integrated information card selection
US8079069B2 (en) * 2008-03-24 2011-12-13 Oracle International Corporation Cardspace history validator
US8561172B2 (en) * 2008-08-29 2013-10-15 Novell Intellectual Property Holdings, Inc. System and method for virtual information cards
US8083135B2 (en) 2009-01-12 2011-12-27 Novell, Inc. Information card overlay
US8632003B2 (en) 2009-01-27 2014-01-21 Novell, Inc. Multiple persona information cards
US7917437B1 (en) * 2009-12-31 2011-03-29 Marcelo Glasberg Method for avoiding intermediated payment aggregation
US20130085944A1 (en) * 2011-09-29 2013-04-04 Pacid Technologies, Llc System and method for application security
JP5911415B2 (ja) * 2012-12-05 2016-04-27 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 割り勘による支払いを支援するシステム及び方法
EP3140979A4 (en) * 2014-05-09 2017-12-27 Veritaseum Inc. Devices, systems, and methods for facilitating low trust and zero trust value transfers
MX2017008339A (es) * 2014-12-22 2018-11-09 Neustifter Manfred Pagos de flujo continuo.
CN107533700A (zh) * 2015-02-17 2018-01-02 西尔维奥·米卡利 验证电子交易
US11049090B2 (en) * 2015-03-11 2021-06-29 Paypal, Inc. NFC application registry for enhanced mobile transactions and payments
CN105634739B (zh) * 2015-04-21 2019-03-22 宇龙计算机通信科技(深圳)有限公司 支付请求的处理方法、支付请求的处理装置和终端
CN112541757A (zh) * 2016-05-04 2021-03-23 阿尔戈兰德有限责任公司 使区块链系统的第一实体能向其它实体证明的方法
RU2020119312A (ru) * 2017-12-19 2022-01-20 Алгорэнд Инк. Быстрые и стойкие к разделению цепочки блоков
CN109872142B (zh) * 2019-02-21 2023-04-11 派欧云计算(上海)有限公司 一种基于可信第三方的数字资产交易方法及其存储介质
US11580514B1 (en) * 2020-06-05 2023-02-14 Block, Inc. Reduced friction for merchant interactions
US11477654B1 (en) 2022-05-31 2022-10-18 Starlogik Ip Llc Access controlling network architectures and systems, having cellular network components and elements modified to host access controlling schemas designed to transform and/or facilitate cellular communication signals in accordance with novel cellular communications protocols with multi-part multi-functional address signaling, and methods for use thereof
US11432154B1 (en) 2021-12-31 2022-08-30 Ari Kahn Cellular systems having elements modified for access control based on expectation data records in accordance with novel cellular communications protocols and network architectures utilizing cellular network hosted access controlling schemas, and methods for use thereof
US11533619B1 (en) 2022-05-22 2022-12-20 Starkeys Llc Access controlling network architectures utilizing novel cellular signaled access control and machine-learning techniques to identify, rank modify and/or control automated programmable entities (such as robots/bots) and their visual schemas, and methods for use thereof
US11564266B1 (en) 2022-07-11 2023-01-24 Starkeys Llc Permission-based controlling network architectures and systems, having cellular network components and elements modified to host permission controlling schemas designed to facilitates electronic peer-to-peer communication sessions methods for use thereof
US11388601B1 (en) 2021-12-31 2022-07-12 Ari Kahn Cellular systems having elements modified to transform and/or operate cellular communication signals in accordance with novel cellular communications protocols and network architectures utilizing cellular network hosted access controlling schemas, and methods for use thereof
US11516666B1 (en) 2022-05-22 2022-11-29 Starkeys Llc Access controlling network architectures utilizing cellular signaled access control to restricted services with expected keys in accordance with novel communications protocols, and methods for use thereof
US11748721B1 (en) * 2022-03-14 2023-09-05 Andre Temnorod Procuring and presenting deposit transaction details

Family Cites Families (106)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5218637A (en) * 1987-09-07 1993-06-08 L'etat Francais Represente Par Le Ministre Des Postes, Des Telecommunications Et De L'espace Method of transferring a secret, by the exchange of two certificates between two microcomputers which establish reciprocal authorization
US4868877A (en) * 1988-02-12 1989-09-19 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
EP0383985A1 (de) * 1989-02-24 1990-08-29 Claus Peter Prof. Dr. Schnorr Verfahren zur Identifikation von Teilnehmern sowie zur Generierung und Verifikation von elektronischen Unterschriften in einem Datenaustauschsystem
US5231668A (en) * 1991-07-26 1993-07-27 The United States Of America, As Represented By The Secretary Of Commerce Digital signature algorithm
DE4310099C2 (de) * 1993-03-23 1997-09-04 Mannesmann Ag Einrichtung zur Identifizierung von Wegstrecken
US5794207A (en) * 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
US5530232A (en) * 1993-12-22 1996-06-25 Datamark Services, Inc. Multi-application data card
US5578808A (en) * 1993-12-22 1996-11-26 Datamark Services, Inc. Data card that can be used for transactions involving separate card issuers
US5420926A (en) * 1994-01-05 1995-05-30 At&T Corp. Anonymous credit card transactions
US5821871A (en) * 1994-01-27 1998-10-13 Sc-Info+Inno Technologie Informationen+Innovationen Gmbh Cc Authentication method
US5557516A (en) * 1994-02-04 1996-09-17 Mastercard International System and method for conducting cashless transactions
US5606617A (en) * 1994-10-14 1997-02-25 Brands; Stefanus A. Secret-key certificates
US6134326A (en) * 1996-11-18 2000-10-17 Bankers Trust Corporation Simultaneous electronic transactions
CA2215969C (en) 1995-03-21 2002-10-08 Maritz Inc. Debit card system and method for implementing incentive award program
US5761305A (en) * 1995-04-21 1998-06-02 Certicom Corporation Key agreement and transport protocol with implicit signatures
US6324525B1 (en) * 1996-06-17 2001-11-27 Hewlett-Packard Company Settlement of aggregated electronic transactions over a network
FR2751104B1 (fr) * 1996-07-11 1998-12-31 Stoffel Laurent Procede de controle de transactions securisees independantes utilisant un dispositif physique unique
JP2000515649A (ja) * 1996-08-07 2000-11-21 バンカーズ・トラスト・コーポレーション 見ることができ信頼できる当事者による同時性電子トランザクション
US5850443A (en) * 1996-08-15 1998-12-15 Entrust Technologies, Ltd. Key management system for mixed-trust environments
US7020638B1 (en) * 1996-11-18 2006-03-28 Microsoft Corporation System and method for flexible micropayment of low value electronic assets
US6021399A (en) * 1996-11-25 2000-02-01 Xerox Corporation Space efficient method of verifying electronic payments
US5903652A (en) * 1996-11-25 1999-05-11 Microsoft Corporation System and apparatus for monitoring secure information in a computer network
EP0917327B1 (en) * 1996-12-13 2002-07-24 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Method and system for performing electronic money transactions
US5999919A (en) * 1997-02-26 1999-12-07 At&T Efficient micropayment system
US5999625A (en) * 1997-02-27 1999-12-07 International Business Machines Corporation Method for electronic payment system with issuer control
US6341273B1 (en) * 1997-03-26 2002-01-22 British Telecommunications Public Limited Company Electronic coin stick with potential for future added value
FR2763451B1 (fr) * 1997-05-13 1999-06-18 France Telecom Procede d'identification a cle publique utilisant deux fonctions de hachage
US6000608A (en) * 1997-07-10 1999-12-14 Dorf; Robert E. Multifunction card system
US6049786A (en) * 1997-07-22 2000-04-11 Unisys Corporation Electronic bill presentment and payment system which deters cheating by employing hashes and digital signatures
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
EP0936805A1 (en) * 1998-02-12 1999-08-18 Hewlett-Packard Company Document transfer systems
US6108644A (en) * 1998-02-19 2000-08-22 At&T Corp. System and method for electronic transactions
DE69832535D1 (de) * 1998-03-18 2005-12-29 Kent Ridge Digital Labs Singap Verfahren zum austausch digitaler daten
US6055508A (en) * 1998-06-05 2000-04-25 Yeda Research And Development Co. Ltd. Method for secure accounting and auditing on a communications network
US6222914B1 (en) * 1998-09-02 2001-04-24 Mcmullin John L. System and method for administration of an incentive award system having a delayed award payment using a credit instrument
GB2343763B (en) * 1998-09-04 2003-05-21 Shell Services Internat Ltd Data processing system
US6327570B1 (en) * 1998-11-06 2001-12-04 Dian Stevens Personal business service system and method
US6032136A (en) * 1998-11-17 2000-02-29 First Usa Bank, N.A. Customer activated multi-value (CAM) card
EP1018844A1 (en) * 1999-01-08 2000-07-12 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Communication network
US6529885B1 (en) * 1999-03-18 2003-03-04 Oracle Corporation Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
US7742943B2 (en) * 1999-06-23 2010-06-22 Signature Systems Llc Method and system for issuing, aggregating and redeeming merchant loyalty points with an acquiring bank
US6594640B1 (en) * 1999-06-23 2003-07-15 Richard Postrel System for electronic barter, trading and redeeming points accumulated in frequent use reward programs
US7765124B2 (en) * 1999-06-23 2010-07-27 Signature Systems Llc Method and system for issuing, aggregating and redeeming merchant rewards with an issuing bank
US7769630B2 (en) * 1999-06-23 2010-08-03 Signature Systems Llc Method and system for issuing, aggregating and redeeming rewards based on merchant transactions
EP1204940A4 (en) * 1999-07-29 2004-11-03 Privacash Com Inc METHOD AND SYSTEM FOR PROCESSING ANONYMOUS PURCHASE ON THE INTERNET
US6779114B1 (en) * 1999-08-19 2004-08-17 Cloakware Corporation Tamper resistant software-control flow encoding
US20050027610A1 (en) 1999-08-26 2005-02-03 Wharton Brian K. Electronic commerce systems and methods providing unified checkout steps
US7742967B1 (en) * 1999-10-01 2010-06-22 Cardinalcommerce Corporation Secure and efficient payment processing system
AU4508001A (en) * 1999-11-29 2001-06-18 Microsoft Corporation System and method for flexible micropayment of low value electronic assets
US20010032139A1 (en) * 1999-12-03 2001-10-18 Debonnett Allison P. Cybermoney network; a seamless internet commercial and investment bank account connectivity interface for payment and settlement of goods and services purchased via the internet
US7172112B2 (en) * 2000-01-21 2007-02-06 American Express Travel Related Services Company, Inc. Public/private dual card system and method
US7163145B2 (en) * 2000-01-21 2007-01-16 American Express Travel Related Services Co., Inc. Geographic area multiple service card system
US6612487B2 (en) * 2000-02-14 2003-09-02 Mas Inco Corporation Method and system for account activation
AU2001249340A1 (en) * 2000-03-23 2001-10-03 Ali Habib Unified communications and commerce systems and methods, and device therefore
US20020027610A1 (en) * 2000-03-27 2002-03-07 Hong Jiang Method and apparatus for de-interlacing video images
AU7182701A (en) * 2000-07-06 2002-01-21 David Paul Felsher Information record infrastructure, system and method
AU2001280058A1 (en) * 2000-08-11 2002-02-25 Cardis International Intertrust N.V System and method for micropayment in electronic commerce
US6754640B2 (en) * 2000-10-30 2004-06-22 William O. Bozeman Universal positive pay match, authentication, authorization, settlement and clearing system
US7228292B2 (en) * 2000-11-16 2007-06-05 First Data Corporation Card-based system and method for issuing negotiable instruments
US20060149686A1 (en) * 2000-11-30 2006-07-06 Allison Debonnett Method of payment and settlement of goods and services via the INTERNET
US6631849B2 (en) * 2000-12-06 2003-10-14 Bank One, Delaware, National Association Selectable multi-purpose card
US6985873B2 (en) * 2001-01-18 2006-01-10 First Usa Bank, N.A. System and method for administering a brokerage rebate card program
US20030144907A1 (en) * 2001-03-05 2003-07-31 American Express Travel Related Services Company, Inc. System and method for administering incentive offers
US20020128917A1 (en) 2001-03-06 2002-09-12 Electronic Data Systems Corporation Method and apparatus for processing financial transactions
AU2002247375B2 (en) * 2001-03-19 2008-02-07 Mastercard International Incorporated Method and system for making small payments using a payment card
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US7404080B2 (en) * 2001-04-16 2008-07-22 Bjorn Markus Jakobsson Methods and apparatus for efficient computation of one-way chains in cryptographic applications
CA2445573A1 (en) * 2001-04-27 2002-11-07 Massachusetts Institute Of Technology Method and system for micropayment transactions
EP1271434A1 (en) 2001-06-11 2003-01-02 CMG Finance B.V. Method and system for payment
US7119659B2 (en) * 2001-07-10 2006-10-10 American Express Travel Related Services Company, Inc. Systems and methods for providing a RF transaction device for use in a private label transaction
US7021531B2 (en) * 2001-07-13 2006-04-04 Yves De Myttenaere Payment device
US7668776B1 (en) * 2002-01-07 2010-02-23 First Data Corporation Systems and methods for selective use of risk models to predict financial risk
US7372952B1 (en) * 2002-03-07 2008-05-13 Wai Wu Telephony control system with intelligent call routing
US7386503B2 (en) * 2002-06-18 2008-06-10 First Data Corporation Profitability evaluation in transaction decision
US8762236B1 (en) * 2002-07-15 2014-06-24 Paymentech, Llc System and apparatus for transaction data format and function verification
US8412623B2 (en) * 2002-07-15 2013-04-02 Citicorp Credit Services, Inc. Method and system for a multi-purpose transactional platform
CA2436319C (en) * 2002-08-02 2014-05-13 Calin A. Sandru Payment validation network
US6920611B1 (en) * 2002-11-25 2005-07-19 Visa U.S.A., Inc. Method and system for implementing a loyalty merchant component
CA2457507A1 (en) * 2003-02-14 2004-08-14 Jonathan Kepecs Use of limited identification on point-of-sale systems
US20040193485A1 (en) * 2003-03-28 2004-09-30 Noel Ilberg Small business/retailer/merchant loyalty program
US7475807B2 (en) * 2003-10-24 2009-01-13 De La Rue International Limited Method and apparatus for processing checks
US7287689B2 (en) * 2003-12-09 2007-10-30 First Data Corporation Systems and methods for assessing the risk of a financial transaction using authenticating marks
US7610407B2 (en) * 2003-12-11 2009-10-27 Hewlett-Packard Development Company, L.P. Method for exchanging information between at least two participants via at least one intermediary to limit disclosure between the participants
US20070038515A1 (en) * 2004-03-01 2007-02-15 Signature Systems Llc Method and system for issuing, aggregating and redeeming merchant reward points with a credit card network
US7191939B2 (en) * 2004-03-12 2007-03-20 American Express Travel Related Services Company, Inc. Systems, methods, and devices for selling transaction instruments via web-based tool
US7954698B1 (en) * 2004-06-02 2011-06-07 Pliha Robert K System and method for matching customers to financial products, services, and incentives based on bank account transaction activity
US20060149671A1 (en) * 2004-06-25 2006-07-06 Robert Nix Payment processing method and system
US8027918B2 (en) 2004-08-30 2011-09-27 Google Inc. Micro-payment system architecture
US8091784B1 (en) * 2005-03-09 2012-01-10 Diebold, Incorporated Banking system controlled responsive to data bearing records
EP1732034A1 (en) * 2005-06-06 2006-12-13 First Data Corporation System and method for authorizing electronic payment transactions
US20070063024A1 (en) * 2005-09-21 2007-03-22 Plastyc Inc. Dual macro- and micro-payment card system
US7725403B2 (en) * 2005-12-30 2010-05-25 Ebay Inc. Method and system to verify a transaction
US8300798B1 (en) * 2006-04-03 2012-10-30 Wai Wu Intelligent communication routing system and method
US20080040261A1 (en) * 2006-04-24 2008-02-14 Robert Nix Systems and methods for implementing financial transactions
US20070267479A1 (en) * 2006-05-16 2007-11-22 Chockstone, Inc. Systems and methods for implementing parking transactions and other financial transactions
WO2007141779A2 (en) * 2006-06-08 2007-12-13 Amram Peled Computer based credit card
US20080314977A1 (en) * 2006-06-08 2008-12-25 American Express Travel Related Services Company, Inc. Method, System, and Computer Program Product for Customer-Level Data Verification
US9195985B2 (en) * 2006-06-08 2015-11-24 Iii Holdings 1, Llc Method, system, and computer program product for customer-level data verification
US8025220B2 (en) * 2006-11-10 2011-09-27 Fair Isaac Corporation Cardholder localization based on transaction data
US8082446B1 (en) * 2006-11-30 2011-12-20 Media Sourcery, Inc. System and method for non-repudiation within a public key infrastructure
JP2009258860A (ja) * 2008-04-14 2009-11-05 Sony Corp 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム
JP5451540B2 (ja) * 2009-10-16 2014-03-26 日立オムロンターミナルソリューションズ株式会社 生体認証装置および生体認証方法
US8296232B2 (en) * 2010-04-30 2012-10-23 Visa International Service Association Systems and methods for screening payment transactions
US8136724B1 (en) * 2011-06-24 2012-03-20 American Express Travel Related Services Company, Inc. Systems and methods for gesture-based interaction with computer systems
JP5652556B2 (ja) * 2011-11-18 2015-01-14 富士通株式会社 通信ノード、通信制御方法、および通信ノードの制御プログラム
US8777104B1 (en) * 2013-11-26 2014-07-15 Square, Inc. Detecting a malfunctioning device using sensors

Also Published As

Publication number Publication date
WO2002088874A2 (en) 2002-11-07
US20040199475A1 (en) 2004-10-07
WO2002088874A3 (en) 2004-02-12
CA2445573A1 (en) 2002-11-07
EP1410289A2 (en) 2004-04-21
CN1535440A (zh) 2004-10-06
EP1410289A4 (en) 2004-12-22
US20100241569A1 (en) 2010-09-23
US8983874B2 (en) 2015-03-17

Similar Documents

Publication Publication Date Title
US8983874B2 (en) Method and system for micropayment transactions
AU2005259948A1 (en) Payment processing method and system
Manasse The Millicent Protocols for Electronic Commerce.
JP2023179799A (ja) ブロックチェーンベースのトークナイゼーションを用いた交換
WO2017223303A1 (en) Determining exchange item compliance in an exchange item marketplace network
CN101010690A (zh) 支付处理方法和系统
Poutanen et al. NetCents: A Lightweight Protocol for Secure Micropayments.
JPH0981634A (ja) ネットワーク課金方法
US20230196354A1 (en) Authorizing replacement of a security parameter associated with one or more exchange items
KR20030029607A (ko) 마이크로지불 트랜젝션을 관리하는 시스템 및 방법 및이에 대응하는 고객용 단말기 및 판매인용 단말기
JP2018088076A (ja) 決済システム、情報処理装置、決済方法、プログラム
US20230125124A1 (en) Obtaining conditions data for utilizing an exchange item
AU2004208331A2 (en) Micropayment processing method and system
Dai et al. Comparing and contrasting micro-payment models for E-commerce systems
WO2008098163A2 (en) Method to facilitate confidential network sales
Sadeghi et al. Electronic payment systems
KR102540618B1 (ko) 블록체인을 이용한 문서증명방식의 분할방식 매출채권 팩토링서비스 처리방법
Herzberg Micropayments
AU2002254649A1 (en) Method and system for micropayment transactions
US20080201260A1 (en) Internet micro payments system
Fram et al. Altered states: electronic commerce and owning the means of value exchange
Kardan et al. A lightweight buyer’s trust model for micropayment systems
Poutanen NetCents protocol for inexpensive Internet payments
Cummins A Secure Payment Protocol
Lucas Improvements in Probabilistic Micropayment Schemes

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050418

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080221

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20080514

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20080514

RD13 Notification of appointment of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7433

Effective date: 20080514

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20080514

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20080618

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20081014