(57)【要約】  ペイメント処理システムは、消費者と業者の間のスモール・トランザクションに関連する費用データを集約する１つのトランザクション・プロセッサを含む。トランザクション・プロセッサは、集約された費用データを表すデータを、業者に関連する承継銀行エンティティに送信する。また、システムは、各個人のスモール・トランザクションを表すデータを記憶する別の１つのトランザクション・プロセッサも含む。記憶されたデータは、業者に関連する１又は複数の銀行エンティティによってアクセス可能である。
2008504612.tif 000002
【特許請求の範囲】
【請求項１】
ペイメント処理システムであって、
消費者と業者の間の低額販売トランザクションに関連する費用データを集約する様に構成され、前記集約された費用データを前記業者に関連する承継銀行エンティティに送信する様に構成された第１トランザクション・プロセッサ、及び
各個人の低額販売トランザクションを表すデータを記憶する様に構成され、前記記憶されたデータが、前記業者に関連する少なくとも１つの銀行エンティティによってアクセス可能である第２トランザクション・プロセッサを含むことを特徴とする、ペイメント処理システム。
【請求項２】
前記第２トランザクション・プロセッサが、前記消費者と前記業者から離れて配置される、請求項１に記載のペイメント処理システム。
【請求項３】
前記第１トランザクション・プロセッサが、前記業者と少なくとも２つの消費者の間の低額販売トランザクションに関連する費用データを集約する様に更に構成される、請求項１に記載のペイメント処理システム。
【請求項４】
前記第１トランザクション・プロセッサが、少なくとも２つの業者に関連する低額販売トランザクションに関連する費用データを集約する様に更に構成され、前記業者が同じ銀行エンティティに関連する、請求項１に記載のペイメント処理システム。
【請求項５】
前記消費者が前記業者に、前記低額販売トランザクションに対して、使用毎支払に基づいて支払う、請求項１に記載のペイメント処理システム。
【請求項６】
前記消費者が前記業者に、前記低額販売トランザクションに対して、プリペイドに基づいて支払う請求項１に記載のペイメント処理システム。
【請求項７】
前記消費者が前記業者に、前記低額販売トランザクションに対して、予約に基づいて支払う、請求項１に記載のペイメント処理システム。
【請求項８】
前記消費者が前記業者に、前記低額販売トランザクションに対して、ポストペイドに基づいて支払う請求項１に記載のペイメント処理システム。
【請求項９】
前記記憶されたデータが、各個人の低額販売トランザクションは、前記承継銀行エンティティによってアクセス可能であることを示す、請求項１に記載のペイメント処理システム。
【請求項１０】
前記記憶されたデータが、各個人の低額販売トランザクションは、前記消費者に関連する発行銀行エンティティによってアクセス可能であることを示す、請求項１に記載のペイメント処理システム。
【請求項１１】
前記記憶されたデータが、各個人の低額販売トランザクションは、前記消費者によってアクセス可能であることを示す、請求項１に記載のペイメント処理システム。
【請求項１２】
顧客サービスを提供するために、前記第１トランザクション・プロセッサが、消費者要求を前記第２トランザクション・プロセッサに向ける様に更に構成される、請求項１に記載のペイメント処理システム。
【請求項１３】
前記第１トランザクション・プロセッサが、前記消費者に関連する発行銀行エンティティに配置される、請求項１に記載のペイメント処理システム。
【請求項１４】
ペイメントの残高調整を、少なくとも１つの前記低額販売トランザクションで追跡する様に構成される第３トランザクション・プロセッサを更に含む、請求項１に記載のペイメント処理システム。
【請求項１５】
前記第３トランザクション・プロセッサが、承継銀行エンティティに配置される、請求項１４に記載のペイメント処理システム。
【請求項１６】
集約費用データを第三者のためのフォーマットに変換する様に構成される第４トランザクション・プロセッサを更に含む、請求項１に記載のペイメント処理システム。
【請求項１７】
前記第４トランザクション・プロセッサが、前記第１トランザクション・プロセッサを含むサーバに配置される、請求項１６に記載のペイメント処理システム。
【請求項１８】
各個人の低額販売トランザクションを表す前記記憶されたデータが、少なくとも１つの前記トランザクションに関連する口座番号の一方向ハッシュを含む、請求項１に記載のペイメント処理システム。
【請求項１９】
前記記憶されたデータが暗号化される、請求項１に記載のペイメント処理システム。
【請求項２０】
少なくとも１つの前記低額販売トランザクションが、キオスク装置で発生する、請求項１に記載のペイメント処理システム。
【請求項２１】
第３トランザクション・プロセッサが、前記消費者と第２業者の間の低額販売トランザクションに関連する費用データを集約する様に構成される、請求項１に記載のペイメント処理システム。
【請求項２２】
前記業者が前記消費者に優遇措置を提供して、前記業者との将来のトランザクションを促進する、請求項１に記載のペイメント処理システム。
【請求項２３】
ペイメントを処理する方法であって、
第１消費者と第１業者の間の第１低額販売トランザクションを表すデータを受信し、
第１低額販売トランザクションの費用、及び第２低額販売トランザクションの費用を、前記消費者と前記業者の間で集約し、
前記業者に関連する少なくとも１つの銀行エンティティによって前記データがアクセス可能であるように、前記第１低額販売トランザクションに関連するデータを記憶し、及び
集約費用を表すデータを、前記業者に関連する承継銀行エンティティに送信する諸ステップを含む方法。
【請求項２４】
前記第１消費者に関連する低額販売トランザクションの費用、及び第２消費者に関連する低額販売トランザクションの費用を集約することを更に含む、請求項２３に記載の方法。
【請求項２５】
前記第１業者に関連する低額トランザクションの費用、及び第２業者に関連する低額販売トランザクションの費用を集約し、前記第１業者と前記第２業者が前記承継銀行エンティティに関連する、請求項２３に記載の方法。
【請求項２６】
前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記承継銀行エンティティによってアクセス可能である、請求項２３に記載の方法。
【請求項２７】
前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者に関連する発行銀行エンティティによってアクセス可能である、請求項２３に記載の方法。
【請求項２８】
前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者によってアクセス可能である、請求項２３に記載の方法。
【請求項２９】
前記第１低額販売トランザクションに関連するデータを記憶することは、前記第１低額販売トランザクションに関連する口座番号に一方向ハッシュを適用することを含む、請求項２１に記載の方法。
【請求項３０】
記憶された複数の命令を有するコンピュータ読み取り可能な媒体に常駐するコンピュータ・プログラム・プロダクトであって、プロセッサによって実行されるときに、プロセッサに以下のことをさせる、即ち、
第１消費者と第１業者の間の第１低額販売トランザクションを表すデータを受信し、
前記第１低額販売トランザクションの費用、及び第２低額販売トランザクションの費用を、前記消費者と前記業者の間で集約し、
前記業者に関連する少なくとも１つの銀行エンティティによってアクセス可能な様に、前記第１低額販売トランザクションに関連するデータを記憶し、及び
前記集約費用を表すデータを、前記業者に関連する承継銀行エンティティにに送信する諸ステップを含むコンピュータ・プログラム・プロダクト。
【請求項３１】
前記第１消費者に関連する低額販売トランザクションの費用、及び第２消費者に関連する低額販売トランザクションの費用を集約することを更に含む、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
【請求項３２】
前記第１業者に関連する低額トランザクションの費用、及び第２業者に関連する低額販売トランザクションの費用を集約し、前記第１と前記第２業者が前記承継銀行エンティティに関連することを更に含む請求項３０に記載の、コンピュータ・プログラム・プロダクト。
【請求項３３】
前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記承継銀行エンティティによってアクセス可能である、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
【請求項３４】
前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者に関連する発行銀行エンティティによってアクセス可能である、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
【請求項３５】
前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者によってアクセス可能である、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
【請求項３６】
前記第１低額販売トランザクションに関連するデータを記憶することは、前記第１低額販売トランザクションに関連する口座番号に一方向ハッシュを適用することを含む、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、（ａ）2004年06月25日に出願の「Small Payment Gateway Method and System」と題された米国特許仮出願第60/583,010号、（ｂ）2005年02月01日に出願の「Edge Process for Small Transaction Method and System」と題された米国特許仮出願第60/648,789号の優先権の利益を主張する。
【０００２】
本発明はペイメントの処理に関し、更に詳細には、トランザクション費用を減少させるための少額購入の処理に関する。
【背景技術】
【０００３】
クレジットカード、及びデビッドカードの導入、並びに市場におけるそれらの使用の増加により、業界動向はこれらの手段が更に多くの消費者の好む物になってきたことを示す。2003年には、初めて、現金、又は小切手に基づく支払い方法よりも電子ペイメント方法を使用して消費者が支払いを行った。調査により、３７００万人より多いアメリカ人が５ドル又はそれ以下に対してカードを用いて店頭（ＰＯＳ）購入を行い、オンライン・コンテンツをカードを用いて買うアメリカ人の数が４００万〜１４００万まで1年もたたないうちに増えたことが分かった。加えて、高周波識別（ＲＦＩＤ）技術に基づく非接触型ペイメントカードが開発中であり、これら消費者トレンドを加速する。
【０００４】
物理的ＰＯＳ、ディジタル、及びモバイル・マーケットにおけるスモール・ペイメントの量は、驚異的なペースで加速されている。米国では５ドルより小さい現金ペイメントが１兆３０００億ドル以上存在し、ディジタル・ペイメントは２０％より大きい年複利成長率（ＣＡＧＲ）で３０億ドルを超え、モバイル・ペイメントは１００％より大きいＣＡＧＲで５億ドルを超え、世界中の機会は更に大きい。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
実質的な業者の興味はスモール・ペイメント・ビジネスモデルにあるが、潜在的な問題がスモール・ペイメントに基づく利益の多いビジネスの価値創出を妨げる。例えば、高いトランザクション処理費用は、営業収益性に悪影響を与える。一般的なトランザクション処理費用は、０．２５ドル＋トランザクションの２％である。１ドルの低額トランザクションに対して、トランザクション処理費用は０．２７ドル、又はトランザクションの２７％である。これは、業者にとって利益の多いビジネスをサポートするための実質的なトランザクション費用である。金融業界ソースの中には、トランザクションに対する全部の取扱手数料が０．２０ドル〜０．４０ドルであり、金融業界は１０ドル未満のお金をトランザクションで失うと報じるものもある。
【０００６】
トランザクション費用に加えて、顧客サポート費用が収入と利益に実質的な影響を有する。従来の顧客サービス費用は、電話サポートに対しては一般に５ドル〜１０ドル／インシデントであり、口座引き落とし拒否になるペイメント関連のサポートに対しては１５ドル〜３０ドル／インシデントである。上質な顧客サポートを提供することはビジネスを開発し成長させる重要部分であるが、高い顧客サポート費用は収益性を減少させる。
【０００７】
顧客獲得費用は、生涯顧客の価値と関連しない。業者は、顧客を引き付けて繋ぎ止めるための著しいマーケティング費を負担する。例えば、ファーストフード・レストランに対しては顧客毎の宣伝費は２ドル〜４ドルの範囲であり、インターネット・ビジネスに対しては顧客毎に２０ドル〜４０ドルの範囲である。これらの問題を抑制するため、頻繁な消費者購入を確立する柔軟で費用対効果が大きい方法に業者は興味がある。例えば、業者は、人を引き付ける新しい製品とサービスを生産し、簡単に方針を実施し、総合的なロイヤルティと報償プログラムを確立するか、又は目標を定めたプロモーションを（時には、第三者の提携先と一緒に）を開始する。
【課題を解決するための手段】
【０００８】
本発明の１側面によると、ペイメント処理システムは、消費者と業者の間のスモール・トランザクションに関連する費用データを集約する１つのトランザクション・プロセッサを含む。トランザクション・プロセッサは、集約された費用データを表すデータを、業者に関連する承継銀行エンティティに送信する。また、システムは、各個人のスモール・トランザクションを表すデータを記憶する別の１つのトランザクション・プロセッサも含む。記憶されたデータは、業者に関連する１又は複数の銀行エンティティによってアクセス可能である。
【０００９】
１実施例では、第２トランザクション・プロセッサは、消費者と業者から離れて配置される。第１トランザクション・プロセッサは、種々のタイプの集約を実行する。例えば、プロセッサは、業者と少なくとも２人の消費者の間のスモール・トランザクションに関する費用データを集約するか、又は２又は３以上の業者に関するスモール・トランザクションに関する費用データを集約する。種々のペイメント技法が、業者と消費者の間で実施される。例えば、消費者は、使用毎支払制、プリペイド制、予約制、ポストペイド制、又は他の類似の制度に基づくスモール・トランザクションに対して、業者に支払う。各個人のスモール・トランザクションを表す記憶データは、承継銀行エンティティ、又は消費者に関連する発行銀行エンティティのような種々の銀行エンティティによってアクセス可能である。また、各個人のスモール・トランザクションを表す記憶されたデータは、消費者によってもアクセス可能である。顧客サービスを提供するために、第１トランザクション・プロセッサは、消費者要求を、顧客サービスを提供するための第２トランザクション・プロセッサに向ける。各プロセッサは、種々の位置に配置できる。例えば、第１トランザクション・プロセッサは、消費者に関連する発行銀行エンティティに配置できる。ペイメント処理システムは、ペイメントの残高調整をスモール・トランザクションの少なくとも１つで追跡する第３トランザクション・プロセッサを更に含む。この第３トランザクション・プロセッサは、承継銀行エンティティに配置される。また、システムは、集約費用データを第三者のためのフォーマットに変換する第４トランザクション・プロセッサも含む。この第４トランザクション・プロセッサは、第１トランザクション・プロセッサを含むサーバに配置される。セキュリティ技法が、ペイメント処理システムに含まれる。例えば、各個人のスモール・トランザクションを表す記憶されたデータは、１又は複数のトランザクションに関連する口座番号の一方向ハッシュを含む。それに対応して、記憶されたデータはアクセスのために暗号化できる。１又は複数のスモール・トランザクションは、キオスク装置で発生する。また、ペイメント処理システムは、消費者と別の１つの業者の間のスモール・トランザクションに関連する費用データを集約する第３トランザクション・プロセッサも含む。実施例の中には、業者が消費者に優遇措置を提供して、業者との将来のトランザクションを促進するものもある。
【００１０】
本発明の別の１つの側面によると、ペイメントを処理する方法は、消費者と業者の間の１スモール・トランザクションを表すデータを受信することを含む。また、上記方法は、スモール・トランザクションの費用、及び消費者と業者の間の別の１つのスモール・トランザクションの費用を集約することも含む。更に、データが業者に関連する１又は複数の銀行エンティティによってアクセス可能な様に、上記方法は、各スモール・トランザクションに関連するデータを記憶することも含む。また、上記方法は、集約費用を表すデータを、業者に関連する承継銀行エンティティに送信することも含む。
【００１１】
１実施例では、上記方法は、消費者に関連するスモール・トランザクションの費用、及び別の１つの消費者に関連するスモール・トランザクションの費用を集約することも含む。更に、上記方法は、１業者に関連する低額トランザクションの費用、及び別の１つの業者に関連するスモール・トランザクションの費用を集約することを含み、両方の業者は承継銀行エンティティに関連する。
【００１２】
本発明の別の１つの側面によると、コンピュータ読み取り可能な媒体に記憶されたコンピュータ・プログラムは、プロセッサによって実行されるときに、消費者と業者の間のスモール・トランザクションを表すデータをプロセッサに受信させる命令を有する。追加命令は、プロセッサに、スモール・トランザクションの費用、及び消費者と業者の間の別の１つのスモール・トランザクションの費用を集約させる。データが業者に関連する１又は複数の銀行エンティティによってアクセス可能な様に、命令も、プロセッサに、各スモール・トランザクションに関連するデータを記憶させる。また、命令は、プロセッサに、集約費用を表すデータを業者に関連する承継銀行エンティティに送信させる。
【００１３】
１実施例では、コンピュータ・プログラムは、１消費者に関連するスモール・トランザクションの費用、及び別の１消費者に関連するスモール・トランザクションの費用を集約するための追加命令を含む。また、命令は、１業者に関する低額トランザクションの費用、及び別の１業者に関するスモール・トランザクションの費用を集約するためにも含まれる。
【００１４】
本発明の追加の利点、及び側面が当業者に対して以下の詳細な説明から容易に明らかになり、本発明を実施するために考察される最良の形態の図示だけによって、本発明の実施例が示され、記載される。記載される様に、本発明は他の、及び異なる実施例の余地があり、その詳細は本発明の精神から逸脱することなく種々の明白な項目の変更を受ける。従って、図面、及び詳細な説明は例示と考えられ、限定を意図するものではない。
【発明を実施するための最良の形態】
【００１５】
図１を参照すると、少額購入のトランザクション費用を実質的に減少させる大規模ペイメント処理システム１０が示される。これは、商品、及び／又はサービスを業者から購入する消費者を含む実施例を示す。承継銀行として既知の金融機関は、ペイメントを受け取るための口座を業者に提供する。発行銀行として既知の別の１つの金融機関は、消費者に電子ペイメントを行うための手段（例えば、クレジットカード、デビットカード、プリペイドカード、等）を提供する。カード・ネットワークとしても既知の組織が、発行銀行と承継銀行の間の関係を管理する。取り合わせの中には、プロセッサとして既知の第三者が、業者、承継銀行、発行銀行、及び組織の間のトランザクションを管理するものもある。この議論を通して、金融サービス機関（即ち、承継銀行、発行銀行、組織、及びプロセッサ）をＦＳＩと称する。
【００１６】
業者、承継銀行、発行銀行、プロセッサ、及び組織がスモール・ペイメントを利用することを可能にするスモール・ペイメント・アプリケーションを生成して配布することによって、クレジットカードに対する消費者の信用と好みを普及させ、デビッドカードが活用される。そのために、スモール・トランザクション・プロセッサ１２が、業者と通信するサーバ１４で実行される。ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせで実施されるスモール・トランザクション・プロセッサ１２は、既存のペイメント基盤を拡張することによってスモール・トランザクション処理に対する収入と利益を実質的に最適化する様に設計される。
【００１７】
取り合わせの中には、スモール・トランザクション・プロセッサ１２が、スモール・ペイメントを介して業者、承継銀行、発行銀行、プロセッサ、及び組織が成長し発展することを可能にする拡張可能なトランザクション処理プラットフォームであるものもある。スモール・ペイメントを効率的かつ経済的に運用することによって、スモール・トランザクション・プロセッサ１２は、関連する購入を集約することにより少額購入のトランザクション費用を実質的に減少させる。また、スモール・トランザクション・プロセッサ１２は、消費者が好みのペイメント手段（例えば、クレジットカード、デビットカード、等）を用いて購入を行うことを可能にする。ディジタル、モバイル、及び物理的ＰＯＳ環境の何れかで機能させることによって、スモール・トランザクション・プロセッサ１２の動作が、消費者の購入経験に目に見える変化なしに、クレジットカード・ゲートウェイとして業者の購入経験と連続的に統合する。その動作を通して、業者は、潜在的ビジネスモデル、即ち、使用毎支払、プリペイド、予約、及びポストペイドの組み合わせを通して顧客と収益性の高い関係を構築するツールを提供される。また、スモール・トランザクション・プロセッサ１２も、総合的な請求書提示、及び紛争解決を通して顧客満足を向上させ、顧客サービス費用を減少させる。トランザクション費用を減少させることに加えて、スモール・トランザクション・プロセッサ１２の使用が、費用対効果が大きいロイヤルティ、促進、及び不正手段管理技術をスモール・ペイメント市場にもたらす。
【００１８】
スモール・トランザクション・プロセッサ１２は、ペイメント処理システム１０に含まれる種々の関係者に利益を提供する。例えば、一般に消費者は、柔軟に購入することを欲する。消費者は、購入の時に、何を買うか、どの様に支払うか管理することを欲する。しかし、業者は、スモール・ペイメントに対するカード使用に頻繁に制限を加え、結局、消費者が所望する利便性を提供しない。業者は、消費者が商品、及び／又はサービスを買うのを簡単にすることを欲する。更に小さなトランザクションがなければ、カード処理、及び顧客サービス費用が、全部ではないが、業者の利益の多くを浸食する。消費者が少額商品に対して好みのクレジットカード、又はデビットカードを使用するとき、業者の収益は消えてなくなる。
【００１９】
スモール・トランザクション・プロセッサ１２は、消費者には実質的に見えないで動作する。消費者は、ソフトウェアをダウンロードし、口座を作るか予め預金し、又は購入のために最低額を支出する必要はない。しかし、消費者は、トランザクションをオンラインで比較的素早く再表示する。消費者に対して、ペイメント処理システム１０は、既に所有する信頼される好ましいペイメント機構（カード）を使用して、消費者が少額購入を行うことを可能にする。種々のタイプのビジネスモデル（例えば、使用毎支払、プリペイド、予約、又はポストペイド）を使用することによって、少額ディジタル、モバイル、及び物理的ＰＯＳ商品、及びサービスへ容易にアクセスし、購入することを、システムは消費者に提供する。
【００２０】
加えて、業者は、消費者に所望する商品と利便性を提供することを欲する。柔軟なペイメント選択肢を提供することによって、ペイメント処理システム１０は利便性を提供する。また、業者は全ての購入に対して幅広いペイメント選択枝を提供したいが、まだ高価なトランザクション処理料金、及び顧客サービス料金は、少額のクレジットカード、及びデビットカード購入で業者が利益を得ることを妨げる。
【００２１】
ペイメント処理システム１０は、スモール・ペイメントに対して収益性の高いトランザクションを可能にする。システムは、スモール・ペイメント、及びマイクロ・ペイメントに関連する２つの著しい費用、即ち、トランザクション処理費用、及び顧客サービス費用を減少させる。ペイメント処理システム１０は、集約技法を用いてトランザクション費用に取り組む。業者がスモール・ペイメントを集約し、集約設定を変更して調製することを可能にすることによって、システムは効率を上げる。１つの取り合わせでは、ペイメント処理システム１０の一部は（インターネットを介して）オンラインで実施される。その種の取り合わせでは、自動化された顧客サービスが提供されて、各顧客サービスを比較的低い費用で配信する。また、ペイメント処理システム１０は、業者が消費者受け入れを最適化するビジネスモデルを作ることも可能にする。
【００２２】
業者に対して、ペイメント処理システム１０は、業者が、少額商品と少額サービスを介して、トップライン（収入）とボトムライン（利益）の両方を成長させることを補助する。また、システムは、サポートすること、例えば、使用毎支払、予約、プリペイド、及びポストペイド・ペイメント方式によって、ビジネスモデル柔軟性も提供する。加えて、業者は、費用効率の高い顧客セルフケアの費用と顧客満足を提供される。
【００２３】
承継銀行、及びペイメント・プロセッサは、業者、及び顧客に必要を満たす書品を提供することに関心があり、全部のトランザクション量を増加させる。しかし、一般に、承継銀行、及びプロセッサは、スモール・ペイメントに対する費用対効果が大きい解決策を業者に提供してこなかった。従来のペイメント処理に関連する不相応に高い固定費と変動費が、業者の利益マージンに悪い影響を与える。代わりの方法、例えば、プリペイドカードの使用、又は最小購入高の実施、は、経済的、又は時間的阻害要因を消費者に課す。
【００２４】
スモール・トランザクション・プロセッサ１２を組み込むことによって、プロセッサ、及び承継銀行は収益性の高い新しいビジネスモデルを業者に対して可能にする。業者は好ましいペイメント手段（クレジットカード、及びデビッドカード）をスモール・トランザクション、及びマイクロ・トランザクションに対して受け入れて、高い収益性を維持する。システムを流れるトランザクションの新しいクラスを用いて、処理量は増大し、それと共に、承継銀行、及びプロセッサに対する収入も増大する。一般に、スモール・トランザクション・プロセッサ１２は、既存の処理システム、及びプロセッサ業者のシステムに組み込まれる。承継銀行、及びプロセッサに対して、ペイメント処理システム１０はトランザクション流を増加させ、それが収入と利益の両方をもたらす。
【００２５】
発行銀行は、自社のカード所有者が取引を行うときはいつも、自社のカードが「財布の１番上」であることを欲する。少額購入がなければ、高い処理費用、及び顧客サービス費用は、クレジットカード、及びデビッドカードをディジタル的、及び物理的の両方で業者が受け入れる意欲を削ぐ。その結果、発行銀行は、現金、及び代替ペイメント・システムに対する市場占有率を失う。
【００２６】
ペイメント処理システム１０の機能性を用いて、発行銀行のカード所有者は、少額商品を購入するために現金の代わりにカードを使用する利便性が増大したことを歓迎する。購入プロセスは違和感なく、迅速で、口座登録を必要としない。集約機能性を有するペイメント処理システム１０は、スモール・ペイメントに対する発行銀行の顧客サービス費用を減少させる。従来のシステムの中には、リアルタイム顧客サービス応答が、特に利益の少ないスモール・ペイメントに対して、最高１０ドル／インシデントの費用が掛かるものもある。スモール・ペイメントに対してその種の高価な顧客サービスを維持することは、無意味である。ペイメント処理システム１０は、スモール・ペイメントに対して特に設計されたオンライン顧客セルフサービスを提供し、オンライン顧客セルフサービスは、各サービスを比較的低い費用で提供する。発行銀行に対して、ペイメント処理システム１０は、費やす現金と小切手をカードに変換し、それによってトランザクション流を増加させる。スモール・トランザクションは消費者が取引する頻度を増加させ、「財布の１番上」市場占有率の利益を消費者が使用するカードにもたらす。ペイメント処理システム１０は、オンライン顧客セルフケアを用いて費用を減少させる。加えて、集約の経済的側面の中には、スモール・ペイメント指向の発行物、例えば、非接触型ペイメントカード、を業者が発行する障害を除去するものもある。
【００２７】
一般に、トランザクション処理に対する現在の標準的な料金体系は、収益性の高いスモール・ペイメント、及びマイクロ・ペイメントの実現性を阻止する。反応がなければ、カード・ネットワークは、少額ディジタル商品に対して急速に拡大する市場の一部を失う。
【００２８】
ペイメント処理システム１０は、カード所有者／業者が、低額商品に対して現金の代わりにカード・ペイメントを行うこと／受け入れることを可能にする。購入プロセスは違和感なく、比較的迅速なままで、（たとえあったとしても）最小限の口座登録しか必要としないので、消費者は利便性の増大を歓迎する。ペイメント処理システム１０は、スモール・ペイメントに対する顧客サービス費用を減少させることによって、カード会員を支援する。一般に、従来のリアルタイム顧客サービス応答料金、及び口座引き落とし拒否料金は、特に利益の少ないスモール・ペイメントに対して非常に費用が掛かる。対照的に、ペイメント処理システム１０は、直感的なオンライン顧客セルフサービスを、特にスモール・ペイメントに対して提供し、オンライン顧客セルフサービスは、各顧客サービスを比較的低い費用で配信する様に設計される。
【００２９】
ペイメント処理システム１０は、低額の現金ペイメントと小切手ペイメントをカード・ペイメントに変換することによって、トランザクション流を増加させる。また、システムは、競合するペイメント形態からのエントリに対して、カード・ペイメント・システムを防御する。更に、収益性の高いスモール・ペイメントが、カード・ネットワークの内部で実現される。
【００３０】
図２を参照すると、スモール・トランザクション・プロセッサ１２は、ペイメント処理システム１０の中で単一のグループによって所有され運用されるソフトウェア・プロダクトとして配置されるか、又は外注されたサービスとして複数のグループ複数のグループによって使用される。
【００３１】
一般に、スモール・トランザクション・プロセッサ１２は、業者からペイメント処理システム１０にペイメントを移動させるためのスモール・ペイメント・ゲートウェイを提供する能力を含む。また、オンライン顧客セルフサービスは、独立して、又は前から存在する業者サービス・インターフェースの中で実施されるペイメント処理システム１０によって提供される。また、ペイメント処理システム１０は、消費者口座プロセッサ１６、及び集約計算（例えば、単一の業者からの集約トランザクション）を補助する業者口座プロセッサ１８も含む。加えて、プロセッサ１２，１６，１８は、集約パラメータを調節する機能を提供し、トランザクション費用、交換品質、現金収支、リスク費用、及び顧客サービスを業者が実質的に最適化することを可能にする。また、１又は複数のプロセッサ１２，１６，１８も、発行銀行を通して集約を実行するための技術を含む。
【００３２】
ペイメント処理システム１０の設計の柔軟性は、大量のトランザクション銀行業務、及び処理環境での実施を賄う。例えば、業者口座プロセッサ１８は、承継銀行に対する業者口座サービス、及びそれらのプロセッサを提供するように設計される。また、消費者口座プロセッサ１８は、発行銀行に対するサービス機能性、及びそれらのプロセッサも含む。また、ペイメント処理システム１０は、費用対効果が大きい、安全な分散監査を通して、ＦＳＩが分散処理全体を保守することを可能にするように構築される。
【００３３】
ペイメント処理システム１０の設計は、拡張性、信頼性、及びセキュリティの様な設計思想を扱う。例えば、スモール・トランザクション・プロセッサ１２は、スモール・トランザクション経済の実質的な部分を扱うために、１千以上のスケール因子で設計される。拡張性に加えて、複数レベルのセキュリティが、システム内部、及びシステム外部両方のセキュリティ問題を扱うためにペイメント処理システム１０の内部で実施される。拡張可能な設計を実施することによって、追加の機能性が後で組み込まれ、業者と消費者の関心事を扱う。
【００３４】
図３を参照すると、１つの例示的配置、スモール・トランザクション・プロセッサ１２、消費者口座プロセッサ１６、及び業者口座プロセッサ１８が、各サーバ１４，２０，２２に含まれる。この配置では、サーバ１４，２０，２２が、発行銀行、承継銀行、及び業者の外部の位置の各々が配置される。しかし、他の配置では、サーバ、及びプロセッサは他の場所に配置される。更に、この配置では、以下で詳細に記載されるマイクロ・ペイメント・プロセッサ２４が、サーバ１４で実行される。
【００３５】
スモール・トランザクション・プロセッサ１２はマイクロ・トランザクションを処理して、トランザクションを認証し、取り込み、販売し、貸方に記入し、無効にするための従来のペイメントカード・ゲートウェイ・インターフェースを提供する。スモール・トランザクション・プロセッサ１２は、業者財務管理、ペイメント調停、顧客サービス、及びマーケティング管理のためのマイクロ・トランザクション・データを記憶する。また、スモール・トランザクション・プロセッサ１２は、消費者に詳細なセルフサービス・インターフェースを提供する。スモール・トランザクション・プロセッサ１２は、業者の位置で実行されるように設計されるか、又は、図示されるように、スモール・トランザクション・プロセッサは、業者、業者のグループ、又はＦＳＩの代わりに第三者プロセッサによって実行される。
【００３６】
消費者口座プロセッサ１６は、１組の消費者口座のためのスモール・トランザクションを、更に大きなトランザクションに集約する。消費者口座プロセッサ１６は、消費者セルフサービスのための初期インターフェースであって、消費者をセルフサービスのための適切なスモール・トランザクション・プロセッサに向かわせる顧客サービスのためのシングル・サインオン・ポータルを提供する。この配置では、消費者口座プロセッサ１６は、発行銀行におけるサーバ２０で実行される。代わりに、消費者口座プロセッサ１６は、業者のグループ、又はＦＳＩのための第三者プロセッサにおけるサーバで実行される。
【００３７】
業者口座プロセッサ１８は、（ラージ・トランザクションを生成するために各々が集約する）各個人のスモール・トランザクションに対するラージ・トランザクションのためのペイメントを調停する。業者口座プロセッサ１８は、銀行業の集約された決済システムと業者の個々の決済システムの間のインターフェースを提供する。上記の他のプロセッサと同様に、業者口座プロセッサ１８は、任意のタイプのＦＳＩの代わりに第三者プロセッサによって実行される。しかし、この図示された実施例では、業者口座プロセッサ１８は、承継銀行に配置されたサーバ２２で実行される。
【００３８】
マイクロ・ペイメント・プロセッサ２４は、消費者口座プロセッサ１６、及び業者口座プロセッサ１８を、ラージ・ペイメントを処理する第三者ペイメント・プロセッサにインターフェースする。このインターフェースを提供するために、マイクロ・ペイメント・プロセッサ２４は、データとメッセージを、第三者ペイメント・プロセッサによって使用される１又は複数のフォーマットに変換する。例えば、 First Data, Paymentech, Vital, 等の様な第三者ペイメント・プロセッサに対する変換が実施される。この特定の配置では、マイクロ・ペイメント・プロセッサ２４は、スモール・トランザクション・プロセッサ１２を実行するサーバ１４で実行される。しかし、配置の中には、マイクロ・ペイメント・プロセッサ２４が、別の１つの位置（例えば、業者の位置）のサーバで実行されるものもある。
【００３９】
図４を参照すると、スモール・トランザクション・プロセッサ１２、消費者口座プロセッサ１６、業者口座プロセッサ１８、及びマイクロ・ペイメント・プロセッサ２４によって提供される機能性のいくつかを示すブロック図が示される。この特定の実施例では、各プロセッサはいくつかの類似の構成要素を含む。特に、プロセッサ１２，１６，１８，２４の各々は、トランザクション処理のための分散処理アプリケーションプログラム・インターフェース（ＡＰＩ）を実施するエンジン構成要素を含む。加えて、各プロセッサは、ユーザ・インターフェース、及びトランザクション・データを提示してシステムの相互使用を可能にする通知ＡＰＩ構成要素を含む。
【００４０】
図５を参照すると、図４に示されるプロセッサ１２，１６，１８，２４の各々に含まれる分散処理エンジン２６を表すブロック図が示される。分散処理エンジン２６は、拡張可能なマーク付け言語（ＸＭＬ）ＡＰＩ２８、及び他のプロセッサへの／からのメッセージ／データを送信／受信するための分散されたトランザクション・ルータ３０を含む。また、分散処理エンジン２６は、少量の低額トランザクションを集約するための集約構成要素３２も含む。集約構成要素３２は、種々のタイプの集約の計算を補助する。例えば、低額トランザクションは、消費者基準で集約される。発行銀行を補助するために、低額トランザクションは１又は複数の業者に基づいて集約される。また、分散処理エンジン２６は、個々のトランザクション、及び／又は集約されたトランザクションの決済と調停を補助する構成要素３４も含む。加えて、エンジン２６は、監査トランザクションを補助し、トランザクション、及びトランザクションに関連するデータ（例えば、クレジットカード番号、口座番号、等）にセキュリティを提供する構成要素３６を含む。
【００４１】
上記の構成要素に加えて、スモール・トランザクション・プロセッサ１２に組み込まれた分散処理エンジンは、追加の構成要素を含む。例えば、個別のペイメント構成要素３８が、ペイメントを行うための異なる技法をユーザに提供するために含まれる。例えば、ユーザは、プリペイメント、予約、ポストペイメント、利用時払い、及び／又はペイメント・システムに基づくロイヤルティのようなペイメント技法から選択できる。スモール・トランザクション・プロセッサ１２に加えて、ペイメント処理システム１０の中の他のプロセッサも追加の構成要素を含む。例えば、消費者口座プロセッサ１６は、消費者がペイメント処理システム１０にアクセスすることを可能にする構成要素を含む。アクセスを提供することによって、消費者は適切なスモール・トランザクション・プロセッサに誘導され、１又は複数のトランザクションを検討する。
【００４２】
スモール・トランザクション・プロセッサ１２は、たとえあったとしても、消費者の購入経験における実質的に僅かな変化で、業者の購入経験にペイメントカード・ゲートウェイとして組み込まれる。業者の購入経験のある時点で、トランザクションは、ペイメントカード・ゲートウェイ・インターフェースに認証、及び決済（又は、拒否）のために提示される。ＸＭＬペイメントカード・ゲートウェイＡＰＩが指し示されるとき、業者は類似のペイメントカード・トランザクション情報を送信し、実質的にリアルタイムでマイクロ・ペイメント認証、及び決済（又は、拒否）を受信する。消費者の購入経験に対する明白な違いは、実質的に存在しない。
【００４３】
ペイメントカード・ゲートウェイとして、スモール・トランザクション・プロセッサ１２は、種々のタイプのビジネスモデルに対するペイメントを扱うことが出来る。例えば、ペイメント処理システム１０は、消費者が好みのペイメント手段（例えば、Paypal 等の様なペイメント仲介を通すクレジットカード、デビットカード）を用いて購入を行うことを可能にする。更に、ペイメント処理システム１０はスモール・トランザクションに対する効率的な処理を独自に提供するが、システムは任意のサイズのトランザクションも処理することが出来る。
【００４４】
プロセッサ１２，１６，１８，２４を介して、ペイメント処理システム１０は、ＡＶＳ，ＣＶＶ２チェック、不正手段チェック、及び３Ｄ−セキュア妥当性確認の様なマクロ・ペイメント・トランザクション検証プロセスの情報をマイクロ・ペイメント認証制御流れに伝える。一般に、この情報を処理し、特定の顧客が取引を許可されるべきか否かについての業者レベルの決定を行う業者ソフトウェアが、類似の方法で機能を継続する。
【００４５】
ペイメント処理システム１０は、従来のプロダクション・ペイメントカード・システムの「レールを拡張」し、今日のプロダクション・ペイメントカード・システムとの完全な互換性を維持しながら、リアルタイム・マイクロ・ペイメント・トランザクション処理をネットワーク・エッジへ実質的に移動させる、オープンで導入が容易な技術を提供する。
【００４６】
ペイメント処理システム１０は、電子ペイメント・トランザクションを種々のタイプのクライアント・ソフトウェア・システムから受信する。例えば、トランザクションは、有人の商業的物理的な世界の店頭で動作するＰＯＳ装置から受信され、カード存在トランザクションを既存のペイメント・カード・ネットワークに送り込むように設計される。無人の商業的物理的世界の店頭で動作し、カード存在トランザクションも伝達するキオスク装置は、電子ペイメント・トランザクションを提供する。キオスク装置は、随行する出納係からのサポートが殆ど、又は全くなしに消費者と直接対話するように設計されているので、一般に、これらの装置は、（ＰＯＳ装置と比較して）洗練されたグラフィカル・ユーザ・インターフェースをサポートする。また、ペイメント処理システム１０は、電子ペイメント・トランザクションもカード不在トランザクションを伝達するインターネット・ウェブサイト、又はウェブページ（又は、他のタイプの電子商取引システム）から受信する。カード存在、及びカード不在トランザクションの混在を伝達するモバイル商業アプリケーションに対するモバイル・インターフェースが、トランザクションを提供する。
【００４７】
各タイプの上記クライアントに対して、業者アプリケーションをペイメント処理システム１０にインターフェースするための種々のアーキテクチャが存在する。例えば、クライアント側カスタマイズに対して、クライアントをペイメント処理システム１０に適合させるビジネス・ロジックは、クライアント・サーバ、又は業者に関連するサーバでコード化される。クライアントをペイメント処理システム１０に適合させるビジネス・ロジックは、クライアントとシステムを制御する第三者の間に配置される介入サーバで実施される。クライアントをペイメント処理システムに適合させるビジネス・ロジックは、業者プラグインを介したペイメント処理システムに対するサーバ側モジュール（例えば、プラグイン・モジュール）として実施される。また、ペイメント処理システム１０に含まれる１又は複数のプロセッサ１２，１６，１８，２４は、既存のペイメント・プロセッサのシステムにユーザに意識させないで組み込まれる。その種の組み込みは、前から存在するペイメント・プロセッサを既に使用中の業者のシステムに対して最小限の変化（又は、実質的な無変化）を含む。一般に、ペイメント処理システム１０に含まれる各タイプのＡＰＩは、１又は複数のこれらアプローチを含む。
【００４８】
一般に、ペイメント処理システム１０によって提供される個別のペイメント選択は、４つのタイプのペイメントモデル、即ち、使用毎支払、プリペイド、予約、及びポストペイドを実施する。ペイメント処理システム１０は、これらモデルの各々を単一のトランザクション処理プラットフォームでサポートする。また、ペイメント処理システム１０は、１又は複数のモデルの元で業者が同時に動作する混合モデルもサポートし、消費者は、好ましい購入方法を動的に選択する。
【００４９】
個別のペイメント選択は、ビジネスの内部でペイメントとして受け取る１組の「口座タイプ」を定める能力を業者に提供する。口座タイプは業者に特有であって、例えば、１業者はプリペイド口座を通話時間に対して定め、別の１つの業者は予約口座をダウンロードされた音楽に対して定める。口座タイプは潜在的な「ユニット・タイプ」を有し、潜在的な「ユニット・タイプ」は、このタイプ、例えば、米ドル、通話時間（分）、ゲーム時間（分）、又はキャンディーバーの口座の残高のユニット・タイプである。ユニット・タイプの拡張可能な組は、ロイヤルティ流通の実施を可能にする。
【００５０】
一般に、口座タイプのインスタンスである口座は消費者に所有され、「手段」によって支援される。手段は消費者を識別するために機能し、口座へのアクセスを認証するための基本的基盤である。手段の実施例は、クレジットカード、デビットカード、ギフトカード、ＲＦＩＤスマートカード、ＲＦＩＤモバイル・トークン、又はウェブサイト口座識別子を含む。手段はシステムのマクロ・ペイメント基金のソースであり、実際のところ、この口座に対して消費者を識別する唯一のトークンである。消費者はログイン（名，パスワード）を任意に有することが出来、そのログインを１又は複数の手段、及び手段に関連する口座に関連付けることが出来る。付録Ａを参照すると、各口座に含まれる１組の典型的な情報が示される。
【００５１】
図６を参照すると、個別のペイメント選択を記述し、業者とスモール・トランザクション・プロセッサ１２の間の以下のＡＰＩレベルの対話を含む一連の動作を流れ図４０が示す。一般的なトランザクションを開始するために、消費者は手段を業者に対して提示する。業者は、手段をスモール・トランザクション・プロセッサ１２に渡す。スモール・トランザクション・プロセッサ１２は手段を確認し、手段に関連する個別のペイメント・プロファイルを戻す。プロファイルは、新しい口座が手段プロファイルへ如何にして加えられるかを定めるパラメータに加えて、手段と連動するように定められた口座の拡張可能リストを記述する。
【００５２】
業者は、消費者の好みと業者が定めたビジネスモデルに特化された、ペイメント経験を消費者に提示するためのプロファイルの情報を使用する。消費者は、購入トランザクションを所望するように完了し、業者は、選択されたペイメント口座によって決定されたように消費者からの基金を取り込む。一般に、ＡＰＩは、標準的なペイメントカード・トランザクションに対応する単一口座購入のような２つのスタイルの対話をサポートする。加えて、混合、複数口座、購入がサポートされる。例えば、複数口座購入は、米ドル・トランザクションをロイヤルティ・ポイント更新と、又は日本円トランザクションを無料コーヒー更新を組み合わせる。
【００５３】
一般に、ペイメント口座の各々は、購入ＡＰＩの共通の組をサポートする。これは、業者がトランザクションを消費者ペイメント選択と独立した方法でコード化することを可能にする。一般的な購入要求のリストが、付録Ｂに示される。
【００５４】
「使用毎支払」モデルでは、消費者は、完了した各トランザクションに対して支払う。使用毎支払モデルは比較的高い取り率を消費者に提供するので、業者の視点から、このモデルは有利である。このモデルの単純な項目は、消費者が業者のプロダクトを試すことを奨励し、業者のプロダクトに対するユニット・バリュー・ポイント確立を提供する。しかし、使用毎支払モデルは、業者に対する課題も含む。例えば、もし消費者が「少量」の顧客なら、その関係は収益性の低いことが多い。トランザクション費用は比較的高く、関係は匿名であることが多い。ＡＰＩ購入要求に加えて、使用毎支払口座に対して、ペイメント処理システムは、（付録Ｃに記載される）２つの追加要求もサポートする。
【００５５】
「プリペイド」モデルでは、消費者は１組のトランザクションを予め購入する。消費者は２以上のトランザクションを業者に委ね、初期コミットメントを超過することが多いので、業者の視点から、このモデルは有利である。消費者は予め支払をしているので、クレジットを消費者に拡張するリスクは減少する。プリペイドは、数量割引、ギフトカード、１０代のための口座、及び残高ゼロに至ることを提供するものを含む宣伝活動のためのプラットフォームを提供する。加えて、プリペイド追加金額は、多くのマイクロ・トランザクションにわたってトランザクション費用を割賦償還するように調整できる。長所に加えて、プリペイド・モデルは、業者に対する課題も提起する。例えば、使用毎支払に対して取り率を下げることは、使用毎支払を相殺するための実質的な販売努力を必要とする。別の１つの潜在的課題は、数量割引の様な動機付けを提供する必要性である。ブランドの付いたプリペイドカードを発行する費用は、実質的に、カード発行に対して２〜３ドル、並びに店頭における課金は、1店頭のカード・ラックへの分配に対して１５〜４０％、トランザクション費用毎に２％、及び顧客サポート費用である。請求されていないプリペイド基金の状態を課された喪失の様な新たに発生する規制を満たす費用は、別の１つの課題である。付録Ｄに記載されるように、購入要求に加えて、前納口座が追加要求をサポートする。
【００５６】
「予約」モデルでは、消費者は、特定の時間枠のために１組のトランザクションを予め購入するためにコミットする。業者の視点から、このモデルの長所の中には、予約によって購入することに対する消費者合意が、（業者と消費者の更に深い関係をもたらし得る）業者に対する深いレベルのコミットメントを示すことを含むものもある。また、消費者は、業者に対する収入の何度も繰り返すソースにもなる。クレジットを消費者に拡張するリスクは、減少する。
【００５７】
また、予約モデルは、業者に対する課題も含む。例えば、継続的な経済的コミットメントは、取り率を下げる。取り率を押し上げるために、業者はプロダクト提供への実質的な割引に訴える。予約ビジネスモデルは、全てのプロダクト・タイプに適用可能である。付録Ｄに示されるように、予約口座は、追加のタイプの要求に加えて、使用毎支払要求によってサポートされる要求を使用する。
【００５８】
「ポストペイド」モデル、又は「課金」モデルでは、ペイメントを予め確保することなく、業者は消費者トランザクションを受け入れる。ペイメントを確保するよりも、業者はトランザクションに対して消費者に定期的に課金する。業者の視点から、消費者は自由に消費することが多く、多数のトランザクションを業者と行うので、このモデルは有利である。消費者は、業者に対する収入の何度も繰り返すソースになる。モデルは、消費者が自分の口座を優良な資産状態に維持することに意欲的であることを業者が期待するサービス提供（例えば、住居の電話、又は電力サービス）に適合される。
【００５９】
業者に対するポストペイド課題は、不払いの実質的なリスクを有する大きなクレジット・リスクを業者が負うことを含む。しかし、ポストペイド課金期間を比較的短く維持することによってリスクは軽減される。加えて、モデルは、多くの製品カテゴリに対しては機能しない。ポストペイド口座は、付録Ｅにリストされる追加要求を含む、使用毎支払要求によってサポートされる全ての要求をサポートする。更に、付録Ｆは、購入ＡＰＩと口座ＡＰＩによって使用される種々の引き数を表す。
【００６０】
図７を参照すると、スモール・トランザクション・プロセッサ４４，４６、消費者口座プロセッサ４８、及びペイメント処理システム１０の実施例に含まれるマイクロ・ペイメント・プロセッサ５０の対話を図示するブロック図４２が示される。上記のように、比較的低額のトランザクションを１つの大きなトランザクションに集約することは、トランザクション費用を減少させる技法を提供する。一般に、トランザクション集約は、多くの小さなマイクロ・トランザクションを１つの大きなマクロ・トランザクションに変化させることを含む。集約することによって、マクロ・トランザクションを処理することに関連する固定費は、複数のマイクロ・トランザクションに分散できる。図に示されるように、各トランザクションは、業者によって経験される３つのフェーズを通して示される。即ち、認証(auth)は、カード所有者ペイメント信用情報をチェックし、トランザクションに対して要求される基金を確保し、取り込み(capt)は、カード所有者を有するトランザクション、及びペイメントによって起動されたトランザクションに対する金融機関と調和する最終決済メッセージを完了させる。
【００６１】
この実施例では、スモール・トランザクション・プロセッサ４４，４６は、業者のシステムからのマイクロ・トランザクションを認証し、販売し、貸し方に記入し、無効にするペイメントカードのストリームを受信する。しかし、他の配置では、スモール・トランザクション・プロセッサ４４，４６は、複数の業者からマイクロ・トランザクションを受信する。各スモール・トランザクション・プロセッサ４４，４６は特定のペイメントカードに関連する消費者口座プロセッサ４８と協働して、マイクロ・トランザクションを更に少数のマクロ・トランザクションに集約する。次に、消費者口座プロセッサ４８がマクロ・ペイメント・プロセッサ５０を使用して、ラージ・トランザクションを表すデータを第三者ペイメント・ネットワークに送信する。この特定の配置では、業者口座プロセッサは、リアルタイム・トランザクション流に含まれない。
【００６２】
トランザクション集約の費用便益を実証する図示された実施例のように、上記トランザクションの順序が、０．９９ドル課金に対して５つのマイクロ・トランザクションだけ利益を上げたと仮定する。もしマクロ・トランザクション・レベルにおけるトランザクション処理料金がゲートウェイに対して０．１０ドル、承継銀行に対して０．１０ドル、及び交換に対して０．１０ドル＋２％であれば、５つの０．９９ドルのマクロ・トランザクションは料金に１．６０ドルを、又はトランザクション金額の３２％を要求する。対照的に、もし５つのトランザクションが０．０５ドル／トランザクションを課金するペイメント処理システムを提供したら、５つのマイクロ・トランザクションに対する総料金は０．５５ドル、又はトランザクション金額の１１％であり、１．０５ドル、又は２１％を節約する。
【００６３】
集約エンジンを組み込むプロセッサ４４，４６，４８，５０を実施することによって、スモール・トランザクション・ビジネスモデルを可能にする１組の方針が実施される。集約を実施することにより、トランザクション費用を減少させることによって業者収益性はは増加する。しかし、費用を最小化するだけよりも、取り合わせの中には、いくつかの要因を均衡させる方法で集約が実施されるのものある。例えば、（集約時間を増加させることによって）トランザクション費用を減少させることの間のトレードオフを含む要因は、現金収支遅延、及び不正手段リスク回避の様な均衡した他の要因である。これらの要因（例えば、基金、及び不正手段率に対する業者の費用の会計）の間のトレードオフを実質的に最適化することによって、実質的な悪影響（例えば、現金収支遅延を減少させること、リスクの高いトランザクションに曝されること、顧客サービス費用が増加すること、等）なしに集約が提供される。
【００６４】
一般に、 Visa 及び MasterCard の様な組織が自社メンバの承継銀行に自社メンバの発行銀行へ支払うことを要求する課金は、交換分類によって変化する。交換分類は、多くの規則を含む。 Visa 及び MasterCard は、種々の率、及び規則を有する少なくとも８０以上の交換クラスを定める。交換分類はトランザクション−トランザクションに基づいて割り当てられ、多くの要因によって決定される。例えば、業者に関係する要因の中には、業者ビジネス・カテゴリ（ＭＣＣコード）を含むものもあり、業者はカード存在ビジネス、又はカード不在トランザクション・ビジネスを有し、カード不在ビジネスは郵便注文／電話注文、又は電子商取引であり、無人の売り場が存在し、及び／又は組織はこれを特別な率に値する「新興」マーケットとして考えている。別の１つの分類要因は、使用される消費者ペイメント手段（例えば、クレジット、デビット、デビット、法人、購入、特別にブランドの付いたカード、ＥＢＴカード、外国の発行人からのカード、等）に関する。また、トランザクション−トランザクションの時間細目も要因である。例えば、有効なカードを機械に通すこと、署名、又は署名デビット対ＰＩＮデビットが存在するか、ＡＶＳ適合、ＣＶＶ適合、又は Visa/Secure によって検証されたコード適合が存在するか、所定の間隔に対して充分に小さいトランザクションが存在するか、及び／又はトランザクションに対する１ドル事前認証が存在するかである。同様に、トランザクションのポスト・トランザクション詳細も要因である。例えば、認証と取り込みの間、取り込みと決済の間、又は認証と決済の間の経過時間は、取り込み金額に等しい認証金額であるか、又は顧客サービス電話番号、若しくは決済において提供されたウェブサイト・アドレスの様な詳細である。
【００６５】
もし業者の「最善」交換分類の要求の全てが満たされたら、一般にトランザクションは「完全適格」と呼ばれる。もし交換分類の要求か満たされなければ、トランザクションは新しい「中位適格」交換クラス（現在は、 Visa EIRF 又は MasterCard Merit 1 の何れかである）に格下げされる。もし中位適格クラスの要求が満たされなければ、トランザクションは「不的確」（現在は、 Visa Standard 又は MasterCard Standard）に等級を落とされる。交換クラスの中には、中位適格格下げクラスを有するものもある（例えば、もしトランザクションの唯一の欠点がトラック・スワイプを失うことであれば、 MasterCard Key Entry に等級を下げることは、 Merit 1 の前に行われる）。
【００６６】
業者の完全適格な交換カテゴリは、集約を補助する１組の入力である。一般に、単一品目ビジネスの業者は、単一の交換分類を有する。一般に、これらの営業品目は異なる業者口座を有するが、更に複雑なビジネスを行う業者は、営業品目が伝達するトランザクションによって複数の分類を有する。各ビジネスが集約の間に使用される別々のプロファイルを維持することを可能にすることによって、ペイメント処理システム１０の集約能力は複雑なビジネスを受け入れることが出来る。
【００６７】
集約の費用的長所は、消費者の購入行動の２つの基本的な尺度、即ち、いくらで買うか、及びどれ位の頻度で買うかによって管理される。購入金額はＰiとして表され、Ｐiは消費者が各購入に費やした金額であり、購入の中間到着時間はＴiとして表され、Ｔiは所定の業者における所定の消費者に対する購入の間の時間の金額である。業者における消費者の購入行動は、金額と中間到着時間の順序、即ち、Ｐ1．．．Ｔ2．．．Ｐ2．．．Ｔ3．．．Ｐ3．．．Ｔ4．．．Ｐ4．．．Ｔ5．．．Ｐ5として閲覧できる。
【００６８】
集約は、交換分類と、マクロ認証とマクロ取り込み／マクロ決済の間のタイミングを最適化することによって既存の「集約ウィンドウ」の内部にマイクロ・トランザクションを更に入力する利益の間のトレードオフを実質的に最適化する。更に、集約は、交換の等級を下げることの潜在的な費用上の影響に対する集約の利益を実質的に最適化する。
【００６９】
付録Ｇを参照すると、集約を制御するために業者が設定できるパラメータを記述する表が提供される。ペイメント処理システム１０は、業者によって設定されたパラメータの制御のもとで、トランザクション−トランザクションに基づいて集約を実質的に最適化する。取り合わせの中には、これらのパラメータが複雑であると考えられるものもあるが、ユーザに集約パラメータの理解を学習、又は取得することを要求することなく、デフォルト設定は実質的に最適化された集約結果を提供する。一般に、ペイメント処理システム１０は、会社のコンプライアンス・ガイドラインの範囲内で動作する集約を実行し、会社規則に準拠する単一業者集約を維持する。
【００７０】
図８を参照すると、集約を通して、ペイメント処理システム５２は、多くの消費者、業者、及び／又はペイメント提供者の全体にわたる低額トランザクションを集約する。ペイメント処理システム５２は、安全なペイメント処理システムを維持しながら、大容量のマイクロ・ペイメント処理をペイメント・ネットワーク・コアからスモール・トランザクション・プロセッサ５４，５６、消費者口座プロセッサ５８、及びマイクロ・ペイメント・プロセッサ６０の様な分散されたプロセッサに移動させることによって、トランザクション集約を拡張する。
【００７１】
ペイメント処理システム５２は、セキュア集中制御を維持しながら、ペイメント処理の大規模配布を可能にする暗号化セキュア選択（ＣＳＳ）モジュールを含む。この配置では、ＣＳＳモジュールがシステム動作を２つのレイヤに分離する。第１レイヤは、業者を有する消費者マイクロ・ペイメント・トランザクションがスモール・トランザクション・プロセッサ（例えば、スモール・トランザクション・プロセッサ５４）に記録される、分散されたリアルタイム・マイクロ・ペイメント処理レイヤである。第２レイヤは、マクロ・ペイメント、及び非リアルタイムで動作し、既存のペイメント・ネットワークとインターフェースする分散された制御レイヤである。
【００７２】
一般に、マイクロ・ペイメントとマクロ・ペイメント・レイヤが通信する。例えば、リアルタイム・トランザクションを制御する方針は、スモール・トランザクション・プロセッサに関連するマイクロ・ペイメント・レイヤによって（必要に応じて）フェッチされ、そのレイヤによってキャッシュされる。例えば、これらの方針は、リアルタイム不正手段チェックの間に、複数のマイクロ・ペイメント・トランザクションを認証する。一般に、マイクロ・ペイメント・レイヤは、マクロ・ペイメント・レイヤの後方の要約決済情報と通信するが、しかし、詳細なマイクロ・ペイメント記録は、費用が減少されたスモール・トランザクション・プロセッサに記憶される。
【００７３】
セキュリティ制御を強化するために、ペイメント処理システム５２は、暗号化セキュア選択モジュールに基づいて監査プロトコルを実施する。このプロトコルを使用して、マクロ・ペイメント・レイヤは詳細なマイクロ・トランザクションのスモール・サブセットを試験でき、適切なペイメント処理が全てのマイクロ・トランザクションで発生したことを確実に保証する。これは、費用低減を提供しながら、セキュリティを維持する。
【００７４】
ペイメント処理システム５２は、拡大縮小が容易で極めて安全な動作のために設計される。認証の対象、及びシステムの内部で認証の対象が行う動作の役割は、注意深く分割される。取り合わせの中には、構成要素が共用の公開鍵に基づく確認システムによって確認されるものもある。送信されて記憶されるときに、機密を保持するように指定される情報は暗号化され、確認する必要がある情報は、ディジタル的に署名される。システムは信用情報を厳重に管理し、その使用を制限し、信用情報は、軽快な破棄プロセスを用いて取り消し可能である。
【００７５】
ペイメント・ネットワーク・センタから分散されたスモール・トランザクション・プロセッサ（例えば、スモール・トランザクション・プロセッサ５４，５６）に計算を移動させることによって、暗号化セキュア選択プロセスは、費用的優位を提供する。一般に、ペイメント・システムの中心においてペイメントを処理することは、実質的な中央コンピューティング、及び更に高価な通信基盤を必要とする。スモール・トランザクション・プロセッサにおけるペイメント処理は、実質的に余り高価でない汎用ハードウェアで実行され、通信は電子商取引ウェブサイトに対してローカルである。暗号化セキュア選択モジュールを用いて、ペイメント処理システム５２は、多数のトランザクションを更に安い費用で扱うことが出来る低価格で拡大縮小が容易な集約基盤を提供する。
【００７６】
一般に、業者は、顧客と対話するレベルであるマイクロ・トランザクション・レベルにおいてビジネスを管理する。ペイメント処理システム５２は、一群のマクロ・レベル・トランザクションの観点から基金が業者へ流れるように、第三者ペイメント・ネットワーク対話を最適化することを試みる。システムの決済・調停レイヤは、基金の流れを一群のマクロ・トランザクションから個人のマイクロ・トランザクションへマッピングする。決済レイヤは、部分的な決済を含む種々の要因を扱うことができ、例えば、 Visa が決済されたトランザクションのサブセットを支払い、 American Express がペイメントを保留する。また、口座引き落とし拒否も扱われ、例えば、発行銀行が、特定の消費者の苦情に関連する業者を有する口座引き落とし拒否プロセスを開始する。扱われる別の１つの要因は、業者のグループの間の基金を承継銀行レベルとスモール・トランザクション・プロセッサのレベルの両方において分割することである。
【００７７】
図４に戻ると、スモール・トランザクション・プロセッサ１２は監査・制御モジュール６２を含み、ペイメント処理システム１０が組織によって運用される中央ペイメント処理システムに関連する規則を遵守することを保証する。組織は、殆ど全てのペイメントが信頼される 「第三者プロセッサ」によって検査されることを前提とするコンプライアンス規則を定める。従来のシステムの中には比較的大きな割合のマクロ・トランザクションを検査することが出来るものもあるが、もし従来のシステムが大きな割合のマイクロ・トランザクションを検査する必要があれば、マイクロ・トランザクション処理の費用はマクロ・トランザクション処理の費用と同じであり、業者はスモール・トランザクション・マーケットに入ることが出来ない。
【００７８】
監査・制御モジュール６２は、監査人が全てのマイクロ・トランザクションを検査する必要なしに、高レベルの信頼度をマイクロ・トランザクション処理コンプライアンスで提供する。監査・制御モジュール６２は、2002年04月17日に出願の特許協力条約（ＰＣＴ）出願PCT/US02/12189に記載のような暗号化セキュア選択の技術を実施する。PCT/US02/12189の写しが、付録Ｈで提供される。暗号化セキュア選択は、マイクロ・トランザクションのサブセットが、全体の組に対する結果を確実に推定することを可能にする方法で監査されることを可能にする。監査・制御モジュール６２は、僅かな費用で広範なコンプライアンスを監視する利益を提供し、スモール・トランザクション・プロセッサ１２において仕事の約９５％を行い、他において仕事の約５％を行う。
【００７９】
種々の問題が、監査・制御モジュール６２によってチェックされる。例えば、モジュールは、決済バッチが請求金額の合計になるか、全ての請求されたトランザクションが認証されたか、又はバッチに重複が存在しないかをチェックする。更に、監査・制御モジュール６２は、交換クラスによって要求される様に、適切な程度のＡＶＳ一致、ＣＶＶ一致、 Visa によって検証された一致が各マイクロ・トランザクションに存在するかを決定する。交換クラスによって設計される様な範囲内の認証、取り込み、及び決済の間のタイミングの様な他の問題が、チェックされる。監査・制御モジュール６２は拡張可能であり、将来的に他の問題がチェックされることを可能にする。
【００８０】
図９を参照すると、タイムスタンプされた公開鍵署名を用いて署名することによって業者がトランザクションにコミットするとき、監査に対する初期条件が確立される。公開鍵署名は、計算的に高価である。マークル木の技術は、Ｎ個の公開鍵署名とＮ個のセキュアな一方向ハッシュのバッチを、１個の公開鍵署名、２＊Ｎ−１個のハッシュ、及びハッシュサイズ＊ｌｇＮより多いバイト／メッセージと交換する。
【００８１】
図を参照すると、この実施例では、業者によってディジタル的に署名されるトランザクションを実証するマークル木６４（Ｎ＝８）が示される。例えば、Ｔ010、及びＳＩＧm（Ｔ010）は、マークル木ｖ011，ｖ00，ｖ1，ｖの木構造中のハッシュ値のチェーンに加えて、同じトランザクションＴ010、及びマークル木ＳＩＧm（ｖ）のルートのディジタル署名と同等である。受信者は、ＳＩＧm（ｖ）、及びｖ＝Ｈ（Ｈ（Ｈ（ｖ00，Ｈ（Ｔ010），ｖ011）），ｖ1）であることをチェックでき、ｖ＝Ｈ（Ｈ（Ｈ（ｖ00，Ｈ（Ｔ010），ｖ011）），ｖ1）であることは、業者がディジタル署名ＳＩＧm（Ｔ010）を生成できたことを証明する。即ち、もし業者がマークル木署名を生成できたら、業者はＴ010の様な特定のトランザクションにも直接署名できた。マークル木技術は、１つの署名ＳＩＧm（ｖ）を木のＮ個の項目全体で共有し、暗号的にセキュアなハッシュＨは計算が公開鍵署名よりも実質的に安価なので、計算費用はＮ個の要因だけ概ね減少する。
【００８２】
一般に、マークル木技術は、一群のサイズＮにおける署名のバッチ処理を必要とする。ペイメント処理システム１０は、マイクロ・トランザクションをその集約、及び決済技法の一部として一括するので、アプリケーション挙動の変更なしに、その技術はそれらのコンテキストへ自然に適用される。マークル木の各マイクロ・トランザクションの署名は、木の他の要素をフェッチすることなく、個々にチェックされる。この技術は公開鍵署名の数を実質的に減少させるが、非対称暗号法の信用拡張性の長所のほぼ全てを維持する。
【００８３】
スモール・トランザクション・プロセッサ１２を起点として、マイクロ・トランザクションＴの取り込み時において、スモール・トランザクション・プロセッサは、各ビットが｛０，１｝から一様に得られる長さｎのランダムなビット列Ｒを発生する。スモール・トランザクション・プロセッサ１２は、ペア（Ｔ，Ｒ）をマークル木計算マークル木リーフ署名Ｈj（Ｔ,Ｒ）に加える。定期的に、スモール・トランザクション・プロセッサ１２における業者のマイクロ・トランザクションが決済され、消費者口座プロセッサ１６と業者口座プロセッサ１８によって発生された決済タイムスタンプＳを用いてタイムスタンプされ、業者の公開鍵署名を用いてマークル木のルートに署名することによってマークル木全体が発生してコミットされる。決済総計に加えて、トップレベルのマークル木署名ＳＩＧm（ｖ）が、消費者口座プロセッサ１６と業者口座プロセッサ１８に送信される。この署名はバッチ中のマイクロ・トランザクションの各々にコミットし、将来の監査のためにそれらを実質的に「ロック」する。
【００８４】
消費者口座プロセッサ１６、又は業者口座プロセッサ１８による後続の監査は、監査質問（例えば、特定の日の Visa カード・トランザクションの合計金額は？）に対して答えるためにスモール・トランザクション・プロセッサ１２に要求を送信する何れかのプロセッサを含む。要求に加えて、消費者口座プロセッサ１６、及び／又は業者口座プロセッサ１８は、スモール・トランザクション・プロセッサ計算結果の正当性の証明としてスモール・トランザクション・プロセッサ１２によって戻されるべきマイクロ・トランザクション監査セットの断片を指定する。消費者口座プロセッサ１６、及び／又は業者口座プロセッサ１８は、各トランザクションに関連するランダムなビット列Ｒに適用される選択基準の組（マスク，一致）のリストを供給することによって、このセットを指定する。選択基準マスク及び一致は長さｎのビット列であり、もしマスクを有するＲのビット・レベル「AND」が、リスト中の任意の基準に対する一致と等しければ、マイクロ・トランザクションは戻される。この機構は、監査の真理を支持する監査されたマイクロ・トランザクションの断片の選択を可能にし、ここで、ｐは、バイナリ断片として表されるｐ中の１に対応する１ビットの数を有するマスクの順序を選択することによって任意に近似される。
【００８５】
スモール・トランザクション・プロセッサ１２は監査要求を実行し、各マイクロ・トランザクションをプロセッサにおいて試験すること、例えば、特定の日の Visa カード・トランザクションの合計、によって正確な答えを監査質問に返す。回答に加えて、スモール・トランザクション・プロセッサ１２は、選択基準と適合するマイクロ・トランザクションのサブセットを返し、このサブセットは、スモール・トランザクション・プロセッサが支給する回答に対する証明として機能する。
【００８６】
消費者口座プロセッサ１６、及び／又は業者口座プロセッサ１８は、スモール・トランザクション・プロセッサ１２の結果を（ａ）これらのトランザクションがペイメント処理システム１０に以前提出されたものと同じであることを保証するために、返されたマイクロ・トランザクションでマークル署名を検証すること、及び（ｂ）要因Ｖｐによって監査されたセット中の結果をステップアップし、これらの結果がスモール・トランザクション・プロセッサ２０によって返された正確な結果に近いか否かをテストすることによって検証する。もしステップアップされた監査結果が充分に近くないと判定されたら、消費者口座プロセッサ１６、及び／又は業者口座プロセッサ１８は監査を繰り返し、新しい選択基準を有する同じ要求を下達する。このプロセスは、消費者口座プロセッサ１６、及び／又は業者口座プロセッサ１８が満たされるまで、又はスモール・トランザクション・プロセッサ１２が完全に監査されたに違いないと決定するまで繰り返される。正直な業者に対して、統計値は、消費者口座プロセッサ１６、及び／又は業者口座プロセッサ１８が、妥当な時間の範囲内の部分的な監査で満たされることを保証する。
【００８７】
ペイメント処理システム１０は、拡大縮小が容易で極めて安全な動作のために設計される。認証の対象、及びシステムの内部で認証の対象が行う動作の役割は、注意深く分割される。 Trust Federation 構成要素は、ペイメント処理システム１０に対する分散された証明機関である。証明機関は公開鍵、又は他の技術を使用して、割り当てられた役割のシステムの各構成要素をペイメント処理システム１０の内部で認証する。構成要素が、共用の公開鍵に基づく確認システムによって確認されるものもある。一般に、送信、及び記憶されるときに、機密を維持する必要がある情報は暗号化される。それに対応して、管理境界にわたって認証されることが必要な情報はディジタル的に署名されて、監査可能である。ペイメント処理システム１０は信用情報を制御し、その使用を制限し、一般に、全ての信用情報は、軽快な破棄プロセスを用いて取り消し可能である。
【００８８】
一般に、ペイメント処理システム１０は、口座番号、ＣＶＶコード、 Track-1、 又は Track-2 データをスモール・トランザクション・プロセッサ１２、消費者口座プロセッサ１６、又は業者口座プロセッサ１８に記憶しない。むしろ、口座番号の一方向ハッシュはデータベースに記憶される。また、一方向ハッシュも、トランザクション集約に対する基準として使用される。ペイメント処理システム１０では、口座番号は、ＡＵＴＨトランザクションの間（又は、ＳＡＬＥトランザクションのＡＵＴＨフェーズの間）に、ほぼリアルタイムで使用される。もしＡＵＴＨが成功したら、以降のマクロ・ペイメント・システム対話に対しては口座番号は要求されず、後続の取り込み、クレジット、又は無効化は、適用された特定のＡＵＴＨを指定するＡＵＴＨを有する、返ってきたＲＦＩＤを使用する。もしＡＵＴＨが何らかの理由で失敗したら、システムのＡＵＴＨプロトコルは呼び出し元に口座番号を再び提供して、新しいＡＵＴＨを試みることを要求する。
【００８９】
一般に、ペイメント処理システム１０中のサーバは、口座番号、ＣＶＶコード、 Track-1、 又は Track-2 データを記憶装置に記憶しない。加えて、一般に、このデータはデータベースに書き込まれず、サーバのログファイルに平文で書き出されることもない。取り合わせの中には、口座番号と有効期限の暗号的にセキュアな一方向ハッシュ機能に対してトランザクションを適合させることによって、ペイメント処理システム１０がトランザクションを集約するものもある。ハッシュを計算するための技法は、ＳＨＡ−１暗号的にセキュアなメッセージ・ダイジェスト機能の様な機能を実施する。
【００９０】
業者顧客サービス目的のために、ペイメント処理システム１０は、口座番号の最後の４桁を平文で保持する。顧客サービス・レップは最後の４桁を閲覧し、それらの桁、及び他のトランザクション特性と適合するトランザクションを検索する。また、ペイメント処理システム１０も、業者顧客サービスがトランザクションを検索することを、クレジットカード番号の正確な一致によって可能にする。一般に、口座番号は記憶されず、一方向ハッシュから上手く修復できないので、内部では、その種のデータベース・ルックアップは、口座番号の一方向ハッシュに基づく。
【００９１】
ペイメント処理システム１０のマクロ・ペイメント・プロセッサ２４は、スモール・ペイメント処理サービスを第三者ペイメント・プロセッサにＭＰＰプラグインを介して適合させる。第三者ペイメント・プロセッサがＡＵＴＨとＣＡＰＴをサポートし、ＡＵＴＨとＣＡＰＴによってＡＵＴＨ時間においてのみ口座番号が示されるとき、ＭＰＰプラグインはスモール・トランザクション・プロセッサ１２、及び消費者口座プロセッサ１６の様に働く。特に、口座番号はＡＵＴＨの間はペイメント・プロセッサへ安全に通過させられ、一般に記憶装置の中には保持されない。しかし、第三者ペイメント・プロセッサの中には、口座番号が各ＣＡＰＴ対話に表示される必要があるものもある。その種のプロセッサをサポートするために、プロセッサに対するＭＰＰプラグインは口座番号と有効期限をＡＵＴＨ時間において暗号化し、復号化されたカード番号と有効期限を取り込み時間、又はクレジット時間に示す。
【００９２】
取り合わせの中には、暗号化と鍵管理が、ｎ暗号ｎシールドの様なハードウェア・セキュリティ・モジュールを使用して実行されるものもある。また、システムは、ＡＥＳ−１２８の様な強力な暗号も使用する。一般に、暗号化されたカード番号は一定期間だけ保持され、一定期間はＡＵＴＨとＣＡＰＴの間のウィンドウとして定められる。現在のクレジットカード規則は、このウィンドウを約７〜３０日に定める。その期間の後、ペイメント処理システム１０は、暗号化された口座情報を削除する。鍵は、ハードウェア・セキュリティ・モジュールによって提供されるような安全機構を使用して管理される。ハードウェア・セキュリティ・モジュールは、マルチレイヤ・セキュリティ、及び安全な鍵管理プロセスを提供する。
【００９３】
一般に、スモール・ペイメントは、比較的低価格なポイントで比較的大量に発生する。ペイメント処理システム１０は拡大縮小が極めて容易で、数千の高度に分散されたスモール・トランザクション・プロセッサ、消費者口座プロセッサ、業者口座プロセッサ、マイクロ・ペイメント・プロセッサ、発行銀行サーバ、承継銀行サーバ、等を含む様に拡大縮小される。また、ペイメント処理システム１０は１０００倍より大きな拡張性に調整され、拡張性はますます増加する。例えば、１０〜２０倍のスケール因子が、更に大きなスケール因子（例えば、１００〜２００倍、１０００〜２０００倍、等）にシステムを調整する前に実施される。
【００９４】
拡大縮小を通して、ペイメント処理システム１０は、ユーザに意識させないで、トランザクション処理プロセスを数千の分散されたサーバに分割することが出来る。この分割は、複数のレベルで行われる。例えば、機能的分割では、ペイメント処理システム１０は、別々のサーバで安全かつ効率的に実行できる様に、トランザクション処理の異なる側面を分離する様に設計される。マイクロ・トランザクション処理は、集約されたマクロ・トランザクションの処理から分離される。同様に、マイクロ・トランザクション通知は、マクロ・トランザクション通知から分離される。暗号化される必要があるカード所有者データに対する長期のアクセスを必要とするシステム機能は、アクセスを必要としない機能から分離される。アーキテクチャは、顧客サービス目的の消費者の安全確認を、顧客サービス・データを含むマイクロ・トランザクション記録から分離する。
【００９５】
組織の境界分割に対して、ペイメント処理システム１０のアーキテクチャは、ペイメント・エコシステムを構成する別個の組織の間の境界を考慮する。これらの組織は、（複数の位置を有する）業者、承継銀行、承継銀行のプロセッサ、発行銀行、発行銀行のためのプロセッサ、及び各トランザクションを別の１つのトランザクションからは秘密にしておきたい組織を含む。
【００９６】
負荷分割のために、一般に１消費者のトランザクションは、別の１つの消費者のトランザクションとは独立であり、多くの目的のために、特定のペイメント手段のトランザクションは、別の１つのトランザクションと独立である。個人のペイメント手段は比較的少ないトランザクションを有する傾向があるので、個人の消費者のトランザクションのリアルタイム処理に対する要求が実質的であり、異なる消費者のトランザクションの間に大量の潜在的並列性が存在する。一般に、業者は、自社のビジネスに関連するトランザクションの総合的な閲覧を必要とし、これは著しい量のトランザクションを示す。一般に、業者は、自社のビジネスについての時宜を得た早い情報を所望するが、ハードなリアルタイム情報に対する限定された要求が存在する傾向がある。
【００９７】
図１０を参照すると、取り合わせの中には、負荷分割を実施する構成要素が分散されたトランザクション・ルータ６６であるものもある。一般に、ペイメント処理システム１０の殆どの機能モジュール（例えば、スモール・トランザクション・プロセッサ、消費者口座プロセッサ、業者口座プロセッサ、等）は、１又は複数の内蔵ルータ構成要素を含む。ルータは、入って来る／出て行く全てのメッセージ・トラフィックを試験する。
【００９８】
ルータ６６はＸＭＬメッセージの早い検査の様な種々のメッセージ動作を実行し、どのノードが要求、等を処理すべきかを決定する。１実施例では、ＡＵＴＨメッセージが、ペイメントカード番号、及び業者によって分割される。カード番号、及び業者識別子をＡＵＴＨの中で発見した後、ルータ６６は関連するルーティング・テーブルを試験して、この要求を適切に扱う特定のサーバを発見する。別の１つの実施例では、ＣＡＰＴメッセージは、ＡＵＴＨと一致したときに返された参照ＩＤによって分割される。次に、ルーティング・テーブルが使用されて、参照ＩＤを適切なサーバにマッピングする。
【００９９】
メッセージの追加のアプリケーション・レベル解析が、トランザクションが別の１つの位置で扱われるべきであるということを明らかにする状況が存在する。その場合、トランザクションが再ルーティングされ、ルータ６６が新しい経路を決定する。配置の中には、殆どの時間、トランザクションが適切にルーティングされる（例えば、９９％が適切なルーティング率）様に、ルーティングが適合されるものもある。
【０１００】
また、ルータ６６は、フォルト・トレラントで、ルーティング・セットから出る／に入るノードを扱う。ルータ６６は電源が入っている予備のノードを管理し、失敗したノードを別の１つのノードと比較的短い期間（例えば、１秒、又は２秒）の範囲内で潜在的に交換する。
【０１０１】
また、ルータ６６は、地理的かつ機能的分割も特定のサービスに関連する１組のドメイン名を管理することによって扱う。ドメイン名を管理することによって、それらのドメイン名にマッピングされる更に大きなセットのＩＰアドレスの間のトラフィックをルータ６６が軽減する。
【０１０２】
図１１を参照すると、負荷平衡器（ＬＢ）７０を含む、１つの模範的な負荷分割された処理ノード６８が示される。この配置では、負荷平衡器７０は、「ダム」ＨＴＴＰ負荷平行を提供する従来のＨＴＴＰ／ＳＳＬ負荷平衡器である。この配置では、スモール・トランザクション・プロセッサ、又は消費者口座プロセッサを含むノードは、トランザクション・ルータを介して接続され、アプリケーション・レベル・ルーティングを実行する。個人のスモール・トランザクション・プロセッサ、又は消費者口座プロセッサ・データベースは、特定のエンジン・トランザクションに依存して、ペイメントカード番号、業者口座識別子、及び／又は業者参照識別子によって最初は分割される。
【０１０３】
一般に、スモール・トランザクション・プロセッサ、及び／又は消費者口座プロセッサ通知、及び顧客セルフサービス・ノードは、殆どリアルタイムでアクセスされる共通データベースから実行する。スモール・トランザクション・プロセッサ、及び消費者口座プロセッサ通知負荷は、ペイメントカード番号、及び／又は業者によって分割される。しかし、この通知は、低い優先度で割り当てられる。
【０１０４】
一般に、ペイメント処理システム１０を実施する組織は、システムの中で自社の従業員に特別な役割を割り当てる。例えば、管理は店内（又は、他の事業所）の全ての運営に責任があるが、主にユーザの管理に使用される。一般に、これらのユーザの１人だけが、店毎に存在する。顧客サービス部門は、業者サービスについての購入と苦情を扱うユーザを含む。ユーザは、指定されたデータベース中の顧客サービス紛争を開始して解決する。財務部門は、店の口座の状況を常に把握するユーザを含み、トランザクション、決済、及びペイメントを変更して追跡する。また、このユーザは、ペイメント記録を店の銀行口座と一致させる。
【０１０５】
また、個人に加えて、（ソフトウェア、ハードウェア、又はソフトウェアとハードウェアに組み合わせによって実施される）特定のプロセスも、特定の動作を実行するために組織によって割り当てられる。例えば、トランザクションＡＰＩは、トランザクション要求ドキュメントをスモール・ペイメント・ゲートウェイに送信するために実施される。各要求ＸＭＬドキュメントには、どの業者ＳＤＫクライアントがトランザクションのソースであるかを特定する信用情報が存在する。
【０１０６】
別の１つの割り当て可能なプロセスは、データ・クェリをスモール・ペイメント・ゲートウェイ・データベースに送信するために実施されるクェリＡＰＩである。一般に、クェリＡＰＩインターフェースは、業者ビジネス・システムをペイメント処理システムと統合するために使用される。この割り当て可能なプロセスからの各ＸＭＬ要求は、特定の業者アプリケーションを指定する。更に別の１つの 割り当て可能なプロセスは、サーバ構成と業者アプリケーション管理ドキュメントをスモール・ペイメント・ゲートウェイに送信するために実施される管理ＡＰＩである。この割り当て可能なプロセスからの各ＸＭＬ要求は、特定の業者アプリケーション、及び ペイメントの調停、又は集約設定の調整の様な業者アプリケーションで実行される動作を指定する。
【０１０７】
システムと対話するために、ユーザ・インターフェースが提供される。これらのユーザ・インターフェースは、要約レポート表示、トランザクション詳細閲覧、及びクェリ・トランザクションの様なトランザクション機能を対話形式で補助する。また、ユーザ・インターフェースは、決済要約レポート、クェリ決済、及び決済詳細閲覧の様な決済機能も補助する。また、ペイメントに関連する機能も、１又は複数のユーザ・インターフェースを用いて補助される。例えば、ペイメント要約レポート、ペイメント・クェリ、ペイメント詳細閲覧、及び残高調整ペイメントに関する動作が提供される。
【０１０８】
また、ユーザ・インターフェースは、顧客サービス要約レポート、紛争／サービス・メッセージ・ワークフロー、紛争／サービス・メッセージ・セット閲覧、又は紛争／サービス・メッセージ・クェリの様な顧客サービス・メッセージを提供することを補助する。また、口座管理動作も補助され、口座レポートを生成し、新しい口座タイプを生成して管理し、アクティブな口座を問い合わせ、及び口座詳細を閲覧する。基本的なユーザ家計も、ユーザ・インターフェースを用いて提供される。例えば、ユーザ口座ログイン機能、ユーザ口座プロファイル管理機能、ユーザ・サブ口座管理機能、監査ユーザ活動、等である。
【０１０９】
一般に、クェリＡＰＩは、業者プログラム・アクセスを、ユーザ・インターフェースを通して利用可能な同じ情報に与える。業者とＦＳＩインターフェースが、データ・クェリとシステム管理を、柔軟な対話フレームワークを通して実施する。このフレームワークは、ＨＴＴＰＡＰＩを通したウェブブラウザ、及びプログラムＸＭＬを含む複数の技法を介して、共通クェリと管理コードへのシステム・アクセスを可能にする。
【０１１０】
一般に、これらのＡＰＩは、クェリ実施、及びデータ管理実施を含むビジネス・ロジック構成要素を含む。また、ＡＰＩは、ワークフローを構成する有用な構成要素、並びにデータベース・アクセス（例えば、オブジェクト指向データ・アクセス、及びリレーショナル・データベース管理システム・アクセス）、及びデータベース移植性を可能にするデータ・アクセス・インターフェースも含む。
【０１１１】
利益の多いビジネスを低額トランザクション・ストリームで運用することは、著しい圧力をビジネス活動の多くの側面にもたらす。例えば、顧客サービス対話は５〜１０ドル／インシデントの費用が掛かり、多くのビジネスでは、全部の顧客サービス負担は、平均０．５０ドル／トランザクション以上であり得る。ペイメント処理システム１０は、費用を減少させる、消費者セルフサービスに基づくスモール・トランザクション・プロセッサを実施する。加えて、ペイメント処理システム１０は、業者の店における各購入を詳細に記載するオンライン請求書を示す。オンライン・セルフサービスの総合的な請求書提示、及び紛争解決を通して顧客満足を向上させ、顧客サービス費用を減少させる。
【０１１２】
業者の制御のもとで、請求書の内部の各マイクロ・トランザクションは、問題（例えば、購入したが謝って削除した歌の再ダウンロード）を解決することが出来る自動化された紛争解決ソフトウェア・ウィザードを含む。また、ウィザードは、他の問題に関連する情報を訂正し、解決のために情報を業者の顧客サービス社員に転送する。加えて、業者の制御のもとで、トランザクションと争う消費者の履歴によって変化する方針でクレジットを発行することによって、ウィザードは問題を解決する。
【０１１３】
取り合わせの中には、ペイメント処理システム１０が、１又は複数の消費者口座プロセッサ、及びスモール・トランザクション・プロセッサとインターフェースする、消費者のためのインターフェースを実施するものもある。スモール・トランザクション・プロセッサに関連するインターフェースは、消費者がトランザクション記録を閲覧すること紛争を開始して解決すること、及び業者によって定められた経済的手段口座を管理して生成することを可能にする。
【０１１４】
図１２を参照すると、ペイメント処理システム１０は、セキュリティをウェブに基づく顧客セルフサービスに提供するための種々の技法を実施する。例えば、安全なログインは、アクセスを得るために使用されるプリントされたクレジットカード明細書の情報を要求することによって提供される。別の１つの安全な実施例では、業者に関連するウェブに基づくアプリケーションによってログインが制御される。
【０１１５】
例えば、プリントされた明細書７２の情報を用いてログインするために、消費者は自分のクレジットカード明細書を見る。課金項目上の業者の名前の隣に、８個、又は９個の文字列識別子が提供される。この実施例では、文字列「Z12A7B2G」が、「MYSTORE」からの２６．４１ドルの課金に含まれる。グラフィカル・ユーザ・インターフェース（ＧＵＩ）７４にログインするために、クレジットカード・ユーザによってこの文字列は使用される。特に、ウェブに基づくインターフェースに対して自己を識別するために、この文字列が「ログイン番号」とラベルを付けられたフィールドに入力される。加えて、トランザクション金額が、「トランザクション合計」とラベルを付けられたフィールドに入力される。この実施例では、課金２６．４１ドルが「トランザクション合計」に入力され、「go」とラベルを付けられたグラフィカル・ボタンが選択される。
【０１１６】
類似の方法で、消費者口座プロセッサに関連するグラフィカル・ユーザ・インターフェースは、消費者が関連情報にアクセスすることを可能にする。ＧＵＩ７４と同様に、プリントされた明細書からの情報を使用して、消費者は安全に識別される。プリントされた明細書からの文字列、及びトランザクション合計に加えて、アクセスを得るために他の情報も使用される。例えば、アクセスを安全に提供するために、トランザクション日付、消費者クレジットカード番号の最後の４桁、又は他の類似のタイプの情報が使用される。
【０１１７】
消費者は、種々のポータルを通してアクセスを得る。例えば、消費者は、自分のコンピュータ・システム（又は、携帯電話、携帯用情報機器（ＰＤＡ）、等の様な他のディジタル装置）を通してアクセスを得る。代わりに、業者のシステムを通して、顧客もログインする。
【０１１８】
状況の中には、業者が既に消費者を認証して、消費者アクセスをマイクロ・トランザクション課金記録に更に確認することなく与えたいものもある。ペイメント処理システム１０は、業者が消費者に渡せる、時間を限られた請求書提示信用情報を作り出すＡＰＩを介して、このアクセスをサポートする。この信用情報は「料金ＵＲＬ」であり、自分のマイクロ・トランザクション課金活動を消費者に示すための時間の特定の金額に対して有効である。（消費者選択、又は業者が強制するブラウザ転送の何れかによって）料金ＵＲＬにアクセスすることは、消費者によるそれ以上の確認を要求することなく、消費者に特定の課金を示す。
【０１１９】
一般に、料金ＵＲＬは、限られた時間（一般に、３０分以下）だけ有効である。もし料金ＵＲＬの期限が切れて、業者による消費者の確認の期限が切れてなければ、消費者に追加の時間を与えることを業者システムに尋ねることによって料金ＵＲＬをリフレッシュする機構が存在する。もし消費者が業者によってもはや認証されていなければ、消費者は再ログインして、新しい料金ＵＲＬを獲得する。
【０１２０】
図１３を参照すると、アクセスを得たら直ぐに、マクロ・トランザクションに集約されたマイクロ・トランザクションのリストを含むＧＵＩ７６を消費者は示される。各マイクロ・トランザクションは、追加情報を得るためにユーザが選択可能である。
【０１２１】
図１４を参照すると、模範的なＧＵＩ７８は、ＧＵＩ７６に含まれる品目から選択されたマイクロ・トランザクションに関連する追加情報を示す。
【０１２２】
業者の制御のもとで、請求書の内部の各マイクロ・トランザクションは、ユーザに関係する問題（例えば、購入したが謝って削除した歌の再ダウンロード）を解決する自動化された紛争解決ウィザードを含む。また、ウィザードは、他の問題に関係する情報を訂正し、解決のために情報を業者の顧客サービス社員に転送する。加えて、ウィザードは、クレジットを消費者に発行することによって問題を解決する。問題を解決するための方針は業者によって制御され、ペイメント処理システム１０に含まれる対不正手段技術によって駆動される。
【０１２３】
図１５〜図１７を参照すると、一連のＧＵＩ８０，８２，８４が、一般的なユーザ対話を示す。図１５を参照すると、消費者は「顧客サポート要求」リンクを選択しており、業者によって定められた様にＧＵＩ８０の潜在的購入のリストに示される。図１６を参照すると、この実施例では、「この歌を紛失しました」リンクを選択することによって、ＧＵＩ８２が示されて、ユーザが顧客サポートで交換の要求を送信することを可能にする。図１７を参照すると、（おそらく、業者に関係する）顧客サポート人が、ＧＵＩ８２を介して識別される問題に関連するＧＵＩ８４を介して要求を示される。顧客サポート人は、要求に関連する問題を解決する。解決すると直ぐに、電子メールが消費者に送信される。加えて、消費者のオンライン請求書が更新される。
【０１２４】
図１８を参照すると、もしトランザクションが単一の業者に対して集約されたら、対応するマクロ・トランザクションの内部のマイクロ・トランザクションが、同じ業者に関連する。それらのトランザクションは、業者の名前で請求される。上記のように、マイクロ・トランザクションは、業者のグループ全体で集約される。それで、消費者と複数の業者の間のマイクロ・トランザクションが集約される。加えて、単一の業者と消費者の間で取り引きされる複数のマイクロ・トランザクションが集約される。これらの複数のマイクロ・トランザクションを集約することによって、異なる業者に関連する集約されたトランザクションを消費者は示される。例えば、プリントされた明細書８６に示される様に、「SmallTab.com」、又は「銀行スモール・ペイメント・サービス」の様な第三者を介して、消費者に関連するマイクロ・トランザクションの集約に基づいて複数の業者がランク付けされる。
【０１２５】
複数の業者にわたって集約データを提供することに加えて、第三者ウェブサイトにアクセスするために使用される識別番号を明細書８６も含む。例えば、ウェブサイト（例えば、 http://smalltab.com）にアクセスすること、及び識別番号（例えば、1875766）を入力することによって、顧客サービスＧＵＩ８８が示される。この実施例では、明細書８６に含まれる複数の業者のリスト、及び対応する小計をＧＵＩ８８は示す。業者の１つの関連する特定のリンクを選択することによって、その業者に関連する個々のトランザクションのリストが示される。
【０１２６】
以上、本発明の好ましい実施例について図示し記載したが、特許請求の範囲によって定められる本発明の範囲から逸脱することなしに種々の変形および変更がなし得ることは、当業者には明らかであろう。
2008504612.tif 000003
2008504612.tif 000004
2008504612.tif 000005
2008504612.tif 000006
2008504612.tif 000007
2008504612.tif 000008
2008504612.tif 000009
2008504612.tif 000010
2008504612.tif 000011
2008504612.tif 000012
2008504612.tif 000013
2008504612.tif 000014
2008504612.tif 000015
2008504612.tif 000016
2008504612.tif 000017
2008504612.tif 000018
2008504612.tif 000019
2008504612.tif 000020
2008504612.tif 000021
2008504612.tif 000022
2008504612.tif 000023
2008504612.tif 000024
2008504612.tif 000025
2008504612.tif 000026
2008504612.tif 000027
2008504612.tif 000028
2008504612.tif 000029
2008504612.tif 000030
2008504612.tif 000031
2008504612.tif 000032
2008504612.tif 000033
2008504612.tif 000034
2008504612.tif 000035
2008504612.tif 000036
2008504612.tif 000037
2008504612.tif 000038
2008504612.tif 000039
2008504612.tif 000040
2008504612.tif 000041
2008504612.tif 000042
2008504612.tif 000043
2008504612.tif 000044
2008504612.tif 000045
2008504612.tif 000046
2008504612.tif 000047
2008504612.tif 000048
2008504612.tif 000049
2008504612.tif 000050
2008504612.tif 000051
2008504612.tif 000052
2008504612.tif 000053
2008504612.tif 000054
2008504612.tif 000055
2008504612.tif 000056
2008504612.tif 000057
2008504612.tif 000058
2008504612.tif 000059
2008504612.tif 000060
2008504612.tif 000061
2008504612.tif 000062
2008504612.tif 000063
2008504612.tif 000064
2008504612.tif 000065
2008504612.tif 000066
2008504612.tif 000067
2008504612.tif 000068
2008504612.tif 000069
2008504612.tif 000070
2008504612.tif 000071
2008504612.tif 000072
2008504612.tif 000073
2008504612.tif 000074
2008504612.tif 000075
2008504612.tif 000076
2008504612.tif 000077
2008504612.tif 000078
2008504612.tif 000079
2008504612.tif 000080
2008504612.tif 000081
2008504612.tif 000082
2008504612.tif 000083
2008504612.tif 000084
2008504612.tif 000085
2008504612.tif 000086
2008504612.tif 000087
2008504612.tif 000088
2008504612.tif 000089
2008504612.tif 000090
2008504612.tif 000091
2008504612.tif 000092
2008504612.tif 000093
2008504612.tif 000094
2008504612.tif 000095
【図面の簡単な説明】
【０１２７】
【図１】大規模ペイメント・システムを表すブロック図である。
【図２】トランザクション費用を減少させるための、図１に示される大規模ペイメント・システム内部のプロセッサの分布のブロック図である。
【図３】分散されたプロセッサを含むサーバの位置を表すブロック図である。
【図４】分散されたプロセッサに含まれる機能モジュールを表すブロック図である。
【図５】分散されたプロセッサに含まれる機能モジュールを表すブロック図である。
【図６】低額トランザクションに関連する動作を表す流れ図である。
【図７】分散されたプロセッサの間で実行される、単一の業者に関連する動作を表すブロック図である。
【図８】分散されたプロセッサの間で実行される、複数の業者に関連する動作を表すブロック図である。
【図９】マークル木(Merkle tree)を表すブロック図である。
【図１０】分散された各プロセッサに含まれるルータを表すブロック図である。
【図１１】分散されたプロセッサのノードを表すブロック図である。
【図１２】請求書の一部、及びグラフィカル・ユーザ・インターフェースである。
【図１３】トランザクション明細を提供するグラフィカル・ユーザ・インターフェースである。
【図１４】個々のトランザクションを識別するグラフィカル・ユーザ・インターフェースである。
【図１５】顧客サービスに関連するグラフィカル・ユーザ・インターフェースである。
【図１６】顧客からのサービス要求を受信することに関連するグラフィカル・ユーザ・インターフェースである。
【図１７】サービス提供者に対する顧客要求を表すグラフィカル・ユーザ・インターフェースである。
【図１８】集約された低額トランザクション情報を表すグラフィカル・ユーザ・インターフェースである。
【符号の説明】
【０１２８】
１０，５２    ペイメント処理システム
１２、４４，４６，５４，５６    スモール・トランザクション・プロセッサ
１４，２０，２２    サーバ
２４，５０，６０    マイクロ・ペイメント・プロセッサ
２６    分散処理エンジン
２８    拡張可能なマーク付け言語（ＸＭＬ）ＡＰＩ
３０，６６    トランザクション・ルータ
３２    集約構成要素
３４    トランザクションの決済と調停を補助する構成要素
３６    セキュリティを提供する構成要素
３８    ペイメント構成要素
４０    流れ図
４２    ブロック図
４８，５８    消費者口座プロセッサ
６２    監査・制御モジュールスモール・トランザクション・プロセッサ
６４    マークル木
６８    処理ノード
７０    負荷平衡器
【図１】
2008504612.tif 000096
【図２】
2008504612.tif 000097
【図３】
2008504612.tif 000098
【図４】
2008504612.tif 000099
【図５】
2008504612.tif 000100
【図６】
2008504612.tif 000101
【図７】
2008504612.tif 000102
【図８】
2008504612.tif 000103
【図９】
2008504612.tif 000104
【図１０】
2008504612.tif 000105
【図１１】
2008504612.tif 000106
【図１２】
2008504612.tif 000107
【図１３】
2008504612.tif 000108
【図１４】
2008504612.tif 000109
【図１５】
2008504612.tif 000110
【図１６】
2008504612.tif 000111
【図１７】
2008504612.tif 000112
【図１８】
2008504612.tif 000113
【手続補正書】
【提出日】平成19年4月27日(2007.4.27)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０１２６
【補正方法】変更
【補正の内容】
【０１２６】
以上、本発明の好ましい実施例について図示し記載したが、特許請求の範囲によって定められる本発明の範囲から逸脱することなしに種々の変形および変更がなし得ることは、当業者には明らかであろう。
付録
2008504612.tif 000114
2008504612.tif 000115
2008504612.tif 000116
2008504612.tif 000117
2008504612.tif 000118
2008504612.tif 000119
2008504612.tif 000120
2008504612.tif 000121
2008504612.tif 000122
付録Ｈ
ＰＣＴ出願  ＵＳ０２／１２１８９
マイクロペイメント・トランザクションのための方法およびシステム
関連出願の相互参照
本出願は、１）米国仮出願第６０／２８７，２５１号（“Method and System For Micropayment Transactions”、2001年4月27日出願）、２）米国仮出願第６０／３０６，２５７号（“Method and System For Micropayment Transactions”、2001年7月18日出願）、３）米国仮出願第６０／３４４，２０５号（“Method and System For Micropayment Transactions”、2001年12月26日出願）の、優先権の利益を主張するものである。これらの仮出願の開示は、この参照によりここに組み込まれる。
背景技術
電子商取引システムの発達は、電子ネットワーク間で行われる金銭取引の数の急増をもたらした。マイクロペイメントは、オンライン少額サービス（例えば、情報検索サービス）に融資するための便利な方法を提供することにより、電子商取引トランザクションの新しい形態を可能にする。マイクロペイメントは、非常に小さな額（場合によっては、１ペニーの何分の１）を有するが、非常に大量に行われる。実施例として、情報サービス業者は、サービスに対して少額ずつ請求することを望む。マイクロペイメントは、訪問した各ウェブページ、またはユーザに流された音楽またはビデオの１分ごとの時間に対する支払いをするために使用される。
電子マネー支払い方式の単純な形態は、電子小切手である。電子小切手は、（手書きの署名ではなく）ディジタル署名された小切手から成る。ディジタル署名は、小切手の受取人が署名した関係者の信頼性、および小切手の内容（例えば、小切手の日付および金額）の保全性の両方を確認することを可能にする。公開鍵暗号方式の文献は、ディジタル署名（例えば、“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) を通過する。選択されない小切手は預金できず、従って、業者にとって無価値である。従って、選択されない小切手は、業者によって廃棄される。（インタラクションプロトコルを通して）選択されたマイクロペイメントだけが、支払いを受けるために、業者によって銀行へ実際に提示される。この方法では、銀行は各々および全てのマイクロペイメントを処理する必要はなく、平均して、１／ｓマイクロペイメントの１つを処理するだけである。それにより、銀行の処理コストは大きく削減される。このプロセスを業者に対して公平にするために、選択された各マイクロペイメントに対して、業者は元々指定されたマイクロペイメント金額の１／ｓ倍の金額を稼ぐ。換言すれば、銀行は業者にマイクロペイメントの額面価格の１／ｓ倍に「拡大された」金額を支払う。
その長所にもかかわらず、電子抽選方式は、特定のマイクロペイメントが預金に対して選択されるべきか否かを決定するために、ユーザと業者が各マイクロペイメントと対話しなければならない欠点を有する。この要求が電子マネー支払いシステムを相当に減速させ、場合によっては、この方式を実行不能にする。
上記理由により、非対話型マイクロペイメント方法およびシステムに対する必要性が存在し、非対話型マイクロペイメント方法およびシステムはマイクロペイメントのグローバル集約を可能にして銀行処理コストを最小化するが、同時にマイクロペイメント選択プロセスではユーザと業者の対話を必要としない。
加えて、時間の制約をマイクロペイメント・システムに取り入れることが好ましい。例えば、銀行から支払いを受けるために、業者に支払い可能な小切手（即ち、預金に対して適切に選択されるマイクロペイメント）を銀行へ適当な期間内に預けることを要求する時間の制約をマイクロペイメント・システムに含むことは好都合である。即ち、この方法では、トランザクションに対する可能な支出が支払い口座にもう無いとき、ユーザは余りに遅く請求されない。また、このタイプの制約は、小切手Ｃの時間情報が正確であることを確認するため業者に追加の報奨金を与え、それによりシステムのセキュリティを向上させる。
確率的マイクロペイメント方式で特有のもう１つの問題は、（選択プロセスにおけるユーザと業者の対話が原因の非効率を除いて）ユーザが実際の支出額より多く請求されることに対するリスクである。確率的マイクロペイメント方式のユーザは、場合によっては、不運により、実際の支出額より多く支払わなければならない確率（たとえ小さくても）に対処しなければならない。そのような出来事は希であり、そのように希な出来事の相対的効果は、行われたマイクロペイメントの数と共に劇的に減少する。それにもかかわらず、（僅かではあるが）余計に請求されることの可能性は、この方式が広く普及することへの大きな障害を構成する。これは、一般のユーザがリスク管理に慣れていないからである。
上記理由により、マイクロペイメント方法およびシステムに対して、銀行処理コストを最小化するだけでなく、ユーザが決して実際の支出額より多く請求されないことを保証する必要がある。
最後に、効率を向上させようとするマイクロペイメント・システムは、業者による支払いに対して選択され、支払いの総数の小さな部分だけを一般に構成する支払いに対して、一般に銀行に行動させる。しかし、そのようなマイクロペイメント・システムは、支払い選択プロセスへの柔軟性または管理を銀行に提供しない。そのような管理は、リスク管理において銀行に好都合である。
従って、選択プロセスにおけるユーザと業者の対話の必要性を解消し、支払い過ぎのリスクをユーザから銀行または業者へ移すだけでなく、銀行に支払い選択プロセスへの柔軟性および管理を提供するマイクロペイメント方式が利用可能になることが望ましい。
発明の要約
本発明は確率的マイクロペイメント方式に関し、確率的マイクロペイメント方式は、ユーザＵ（または他の支払人、以降は「Ｕ」または「ユーザ」と呼ぶ）が、業者（または他の受取人、以降は「Ｍ」または「業者」と呼ぶ）への支払いを少なくとも１つのトランザクションＴに対して確立することを可能にする。一般に、本発明の方式はどのような値のＴVにも適用できるが、Ｔは非常に小さな額ＴVを有する。本発明のマイクロペイメント方式は、そのようなマイクロペイメントを処理することに要するコストを最小化し、それによりシステムの効率を著しく向上させる。また、多数の追加的長所が、以下に記載のように提案される。
本発明の第１の実施例では、（小切手を受け取るとすぐにユーザと対話することなく）小切手が支払いに対して選択されるべきか否かを業者が決定することを可能にするマイクロペイメント・プロトコルが提示される。従来技術の確率的マイクロペイメント方式とは異なり、この実施例のマイクロペイメント・プロトコルは、支払い能力の決定が対話的選択プロトコルが業者とユーザの間で発生するまで遅らされることを必要としない。
本発明の第２の実施例では、本発明のマイクロペイメント方式が時間の制約をシステムに取り入れ、時間の制約を特別な方法で使用する。小切手が支払いに対して選択されるために、これら時間の制約は、トランザクションの時間および／または日付に関する情報が小切手上に提供されること、および小切手上の時間情報が所定の基準を満たすことを必要とする。
本発明の第３の実施例では、選択的預金プロトコルが提示され、選択的預金プロトコルはユーザが実際の支出額より多く請求されるリスクを解消する。
最後に、本発明の第４の実施例は遅延選択プロトコルを特徴とし、遅延選択プロトコルは銀行（または、他の第三者、またはブローカー、以降は「銀行」と呼ぶ）に支払いプロセスへの管理および柔軟性を提供する。
本発明の第１の実施例によるマイクロペイメント方式では、Ｔに関係するデータ列Ｃを生成するために、ユーザＵはトランザクションＴに関係するレコードを使用する。Ｃは、ユーザの秘密鍵を使用して、Ｔに対するディジタル署名を生成することにより署名された電子小切手である。ユーザは、業者に小切手Ｃを受け取らせる。Ｃを受け取るとすぐ、業者はＣをユーザが実質的に予測できない項目Ｖに関連付ける。業者は、ＶをＣに関連付けるために、業者にだけ既知の秘密情報ＳＩを使用する。実施例として、Ｖは、（ＳＩＧ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はデータ列Ｃk1，．．．，Ｃklkを含み、ここでｌkは所定のリストＬkの小切手の総数を表す。従って、もしｎがｍ個のリスト全ての小切手の総数なら、Σmk=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＝ＴＶk1＋．．．＋ＴＶkｌkを表す。
掛売金額ＣＲは、ｍ個のリスト全てに含まれる全ての小切手の合計値、即ち、
ＣＲ＝Ｖ1＋．．．＋Ｖk＋．．．＋Ｖm＝Σmk=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個の小切手Ｃk1，．．．，Ｃkｌkを含み、ここで、ｌkはリストＬkのデータ列の数を表す。ｍ個のリスト全体が足されるとき、ｌkは受け取った小切手の総数ｎまで自然に足される。即ち、
ｌ1＋．．．＋ｌk＋．．．＋ｌm＝ｎである。
業者は、Ｌkに対するコミットメントＣＭkを計算することにより各リストＬkにコミットし、銀行にＣＭk（ｋ＝１，．．．，ｍ）を受け取らせる。
当該技術分野で既知なように、コミットメント方式は、メッセージの内容を明かすことなく、このメッセージにコミットしながら、１人の関係者がメッセージをもう１人の関係者に配布することを可能にするプロトコルである。このプロトコルは、関係者が「鍵を掛けた箱」の中のメッセージを配布するプロセスをエミュレートすることを可能にし、それにより送信する関係者（今の場合、業者）は、受信する関係者（今の場合、銀行）が箱の中のメッセージについて何か知ることを、受信する関係者が箱の鍵を与えられる将来の時間まで防止できる。受信する関係者は（受信する側では）、受信する関係者が既に受信した後に、送信する関係者が箱の中のメッセージを変更することを防止できる。一般に、コミットメント方式は２つのフェーズから成る。第１のフェーズ（コミットメント・フェーズ）は、鍵を掛けた箱の配布をシミュレートする。このフェーズが終わるとき、受信する関係者はメッセージをまだ知らないが、送信する関係者はメッセージをもう変更できない。第２のフェーズ（デ・コミットメント・フェーズ）は、鍵の配布をシミュレートする。今、受信する関係者はメッセージを見ることができ、鍵を開けた箱の中のメッセージが確かに送信する関係者がコミットしたメッセージであることを確認できる。
好ましい形態では、Ｌkに対するコミットメントＣＭkはハッシュ値Ｈ（Ｌk）であり、ここでＨは一方向衝突防止性ハッシュ関数である。従って、ＬkをＣＭkから導出することはコンピュータで実行不可能であり、Ｈ（Ｌ1k）＝Ｈ（Ｌ2k）であるような２つの異なる列Ｌ1kとＬ2kを生成することもコンピュータで実行不可能である。
本発明の第４の実施例で開示される遅延選択プロトコルでは、特定の小切手Ｃ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およびデータ列Ｃk1，．．．，Ｃkｌkを含む。ここで、ｌkは所定のリストＬk中のデータ列の数を表す。個のリストにわたって加算するとき、ｌkは自然に受け取った小切手の総数ｎになる。即ち、
ｌ1＋．．．＋ｌk＋．．．＋ｌm＝ｎである。
次に、業者は、ＬkにコミットメントＣＭkすることにより各リストＬkにコミットし、銀行に各ｋ（即ち、ｋ＝１，．．．，ｍ）に対するＣＭkを受け取らせる。
小切手をリストにグループ化することは、業者と銀行が同意した特定の規則に従って行われる。例えば、小切手ＣはリストＬiに配置される。ここで、ｉはＣの関数として（例えば、Ｃのシリアル番号を使用することにより、Ｃから数ビットを抽出することにより、またはＣのハッシュから数ビットを抽出することにより）計算される。
各トランザクションＴiは、トランザクション値ＴＶiにより特徴付けられることが好ましい。また、各データ列Ｃiは、Ｃiが導出されるトランザクションＴiのトランザクション値ＴＶiを表すデータを含むことが好ましい。従って、業者は各リストＬkに対する合計金額Ｖkを決定できる。ここで、Ｖkは以下の式により与えられる。即ち、
Ｖk＝ＴＶk1＋．．．＋ＴＶkｌkである。
換言すれば、Ｖkは、リストＬkの全データ列Ｃk1，．．．，Ｃ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＝（Ｖi1U＋Ｖi2U＋．．．＋ＶirU）＊（ｍ／ｒ）である。
ここで、ＶkUは、Ｌ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はデータ列Ｃk1，．．．，Ｃkｌkを含み、Σmk=1ｌk＝ｎである。さらに、第２処理手段は、各Ｌkに対するコミットメントＣＭkを計算し、コミットメントＣＭk（ｋ＝１，．．．，ｍ）を入力して記憶するために業者によって動作させられる。
コミットメントＣＭkを受け取るとすぐ、ｉ1，ｉ2，．．．．，ｉrを表す１または複数の整数を選択し、第二者にインデックスｉ1，ｉ2，．．．．，ｉrを受け取らせるために、第３処理手段３３０は銀行によって動作させられる。ここで、全てのｒに対して、１≦ｉr≦ｍである。インデックスｉ1，ｉ2，．．．．，ｉrを受け取るとすぐ、ＣＭをデ・コミットするために第４処理手段３４０は業者によって動作させられ、それによりＬi1，．．．，Ｌirを銀行に明らかにする。
システム３００は手段３７０を含み、ユーザの借方に借方金額Ｄを付け、第四者に掛売金額ＣＲを受け取らせるために、Ｌi1，．．．，Ｌirが明らかになるとすぐ、第三者によって動作させられる。
本発明の各実施例では、不正使用できないハードウェア（例えば、携帯電話のスマートカード、またはプロセッサ）が使用されてセキュリティを提供する。
要約すると、本発明では、１）支払い選択プロセスでユーザと業者の対話の必要性を除去し、２）時間の制約をシステムに取り込み、３）ユーザに過剰請求するリスクを除去する選択的デポジット・プロトコルを提供し、４）銀行に支払いプロセスへの柔軟性および管理を影響する遅延選択プロトコルを提供する方法とシステムが開示された。
本発明は特定の好ましい実施例を参照して図示され記載されてきたが、本発明の精神および範囲から逸脱することなく種々の変更をなし得ることは当業者には明らかである。
特許請求の範囲
［請求項１］  トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者がＴからＴに関連するデータ列Ｃを導出し、第二者に前記データ列Ｃの少なくとも一部を受け取らせ、
Ｂ．前記第二者が前記Ｃの少なくとも一部を項目Ｖに関連付け、Ｖは前記第一者が実質的に予測不能であり、
Ｃ．前記第二者がＶがプロパティＰを満たすか否かを決定し、もしそうなら、第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを前記第二者が前記第三者に受け取らせ、
Ｄ．Ｉを受け取るとすぐ、前記第三者がＶが前記プロパティＰを満たすか否かを確認し、および
Ｅ．Ｖが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせる諸ステップから成る方法。
［請求項２］  前記データ列Ｃの少なくとも一部が認証されることを特徴とする、請求項１に記載の方法。
［請求項３］  前記第二者がＶがプロパティＰを満たすか否かを決定するステップが、前記第二者と前記第一者の対話を必要としないことを特徴とする、請求項１に記載の方法。
［請求項４］  前記データ列の一部が前記第一者に代わって第五者により認証されることを特徴とする、請求項２に記載の方法。
［請求項５］  前記第一者が前記データ列ＣをＴから導出するステップが、前記第一者の秘密鍵を使用して、前記第一者がディジタル署名をＴの少なくとも一部に対して生成するステップを含むことを特徴とする、請求項１に記載の方法。
［請求項６］  前記第一者の前記ディジタル署名が、
（ａ）決定論的署名、
（ｂ）無作為化された署名、
（ｃ）オフライン署名、
（ｄ）オンライン署名、および
（ｅ）個人情報に基づく署名の少なくとも１つから成ることを特徴とする、請求項５に記載の方法。
［請求項７］  前記第二者が前記項目ＶをＣに関連付けるステップが、前記第二者の秘密鍵を使用して、前記第二者がディジタル署名をＣの少なくとも一部に対して生成するステップを含むことを特徴とする、請求項１に記載の方法。
［請求項８］  前記第二者の前記ディジタル署名が決定論的署名であることを特徴とする、請求項７に記載の方法。
［請求項９］  前記データ列Ｃ、
ｉ）前記第一者の秘密鍵を使用して計算される、前記トランザクションＴの少なくとも一部に対するディジタル署名
ｉｉ）前記第一者の秘密鍵を使用して計算されるメッセージ認証コード値、および
ｉｉｉ）電子小切手の少なくとも１つから成ることを特徴とする、請求項１に記載の方法。
［請求項１０］  前記項目Ｖが、
ａ）前記第二者の秘密鍵を使用して計算される、Ｃに対するディジタル署名、および
ｂ）前記第二者に既知の秘密鍵を使用して計算されるメッセージ認証コード値の少なくとも１つから成ることを特徴とする、請求項１に記載の方法。
［請求項１１］  前記第二者が前記第三者に前記情報Ｉを受け取らせるステップが、
ａ）前記第二者がＩを前記第三者に送信すること、
ｂ）前記第二者が第五者にIを前記第三者に送信することを頼むこと、および
ｃ）前記第二者がＩをファイルに書き込み、前記第三者がＩを前記ファイルから回収することの少なくとも１つを含むことを特徴とする、請求項１に記載の方法。
［請求項１２］  Ｃを受け取った後に、前記第二者が前記Ｃの信頼性と保全性をチェックするステップをさらに含むことを特徴とする、請求項１に記載の方法。
［請求項１３］  Ｃの信頼性と保全性をチェックするために、前記第二者が前記第一者に関する公開確認情報を使用することを特徴とする、請求項１２に記載の方法。
［請求項１４］  前記公開確認情報が、公開鍵ディジタル署名方式で前記第一者の秘密鍵に対応する前記第一者の公開鍵を含むことを特徴とする、請求項１３に記載の方法。
［請求項１５］  前記第二者が前記公開確認情報を使用するステップが、
（ａ）前記第二者が、前記公開確認情報を前記第一者から得ること、
（ｂ）前記第二者が、前記公開確認情報を前記データ列Ｃに関連して前記第一者により伝達された情報から得ること、
（ｃ）前記第二者が、前記公開確認情報をディジタル証明書から得ること、および
（ｄ）前記第二者が、前記公開確認情報を公然と利用可能な前記第一者についての情報から得ることの少なくとも１つを含むことを特徴とする、請求項１３に記載の方法。
［請求項１６］  前記第二者と前記第四者が同一であることを特徴とする、請求項１に記載の方法。
［請求項１７］  前記第二者と前記第三者が同一であることを特徴とする、請求項１に記載の方法。
［請求項１８］  Ｆ（Ｖ）＜ｓである場合のみ（ここで、Ｆは関数、ｓは定数である）、ＶがＰを満たすことを特徴とする、請求項１に記載の方法。
［請求項１９］  ０＜ｓ＜１であることを特徴とする、請求項１８に記載の方法。
［請求項２０］  Ｆが任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数であることを特徴とする、請求項１８に記載の方法。
［請求項２１］  前記トランザクションＴが部分的にトランザクション値ＴVにより特徴付けられることを特徴とする、請求項１に記載の方法。
［請求項２２］  前記第四者により受け取られる前記金額はＴVより大きいことを特徴とする、請求項２１に記載の方法。
［請求項２３］  前記トランザクションＴが部分的にトランザクション値ＴVにより特徴付けられ、前記第四者により受け取られる前記金額が（ＴV＊１／ｓ）に等しいことを特徴とする、請求項２０に記載の方法。
［請求項２４］  
（ａ）前記項目Ｖが、前記データ列Ｃに関する前記第二者の前記ディジタル署名を含み、および
（ｂ）もしＦ（Ｖ）＜ｓなら、Ｖが前記プロパティＰを満たす（ここで、Ｆは任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数である）ことを特徴とする、請求項１に記載の方法。
［請求項２５］  前記データ列Ｃが情報をＴに含み、前記情報が、
ａ）前記第一者の個人情報、
ｂ）前記トランザクションの時間、および
ｃ）前記トランザクションの日付の少なくとも１つを含むことを特徴とする、請求項１に記載の方法。
［請求項２６］  トランザクション値ＴVを有するトランザクションＴに対してユーザＵが業者Ｍへの支払いを確立するための方法であって、
Ａ．前記ユーザが第１のディジタル署名方式に対して公開鍵と対応する秘密鍵を確立し、Ｔからデータ列Ｃ＝ＳＩＧU（Ｔ）を導出してＣを含む電子小切手を生成し（ここで、ＳＩＧU（Ｔ）は、前記第１のディジタル署名方式の前記トランザクションＴに対するユーザＵの前記ディジタル署名を表す）、
Ｂ．前記ユーザが前記業者に前記データ列Ｃを受け取らせ、
Ｃ．前記業者が第２のディジタル署名方式に対して公開鍵と対応する秘密鍵を確立し、前記データ列Ｃを項目Ｖ＝ＳＩＧM（Ｃ）に関連付け（ここで、ＳＩＧM（Ｃ）は、前記第２のディジタル署名方式の前記データ列Ｃに対する前記業者Ｍの前記ディジタル署名を表す）、
Ｄ．前記業者が値Ｆ（Ｖ）＝Ｆ（ＳＩＧM（Ｃ））を計算し（ここで、Ｆは任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数である）、
Ｅ．前記業者はＦ（ＳＩＧM（Ｃ））を定数ｓと比較してＦ（Ｖ）＜ｓであるか否かを決定し、もしそうなら、銀行に前記業者の前記公開鍵を入手させ、
Ｆ．前記銀行が、前記業者の前記公開鍵を使用してＦ（ＳＩＧM（Ｃ））＜ｓであることを確認し、および
Ｇ．Ｆ（ＳＩＧM（Ｃ））＜ｓである場合にのみ、前記銀行が前記業者に金額Ａ＝［ＴV＊１／ｓ］を受け取らせる諸ステップから成り、
ここで、ｓは０より大きく１より小さい定数であり、前記電子小切手が前記銀行への提示に選択される確率を表す。
［請求項２７］  トランザクションＴに対する支払いを確立するためのシステムであって、
Ａ．第一者、第二者、第三者、および第四者の間でデータを伝達するための通信手段、
Ｂ．Ｔに関するデータ列Ｃを導出し、入力し、記憶するために第一者により動作させられる第１処理手段、
Ｃ．項目Ｖを with Ｃの少なくとも一部に関連付け、ＶがプロパティＰを満たすか否かを決定するために第二者により動作させられる第２処理手段、
（ここで、Ｖは前記第一者が実質的に予測不能）
Ｄ．第三者に前記第三者がＶがＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせるために、ＶがＰを満たすとき、前記第二者により選択的に動作させられる手段、および
Ｅ．第四者に金額Ａを受け取らせるために、ＶがＰを満たすとき、前記第三者により選択的に動作させられる手段から成ることを特徴とするシステム。
［請求項２８］  トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者が第二者からデータ列Ｃの少なくとも一部を受け取り（ここで、前記データ列ＣはＴに関連付けられ）、
Ｂ．前記第一者が、前記Ｃの少なくとも一部を項目Ｖに関連付け（ここで、Ｖは前記第二者が実質的に予測不能であり）、および
Ｃ．前記第一者がＶがプロパティＰを満たすか否かを決定し、そうである場合にのみ、前記第一者が第三者に前記第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせ、それによりＶがＰを満たすことを確認したらすぐ、前記第三者が四者に金額Ａを受け取らせることを可能にする諸ステップから成ることを特徴とする方法。
［請求項２９］  トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者が、第二者から前記第一者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取り、
ここで、前記項目Ｖは、第三者によりＴから導出されたデータ列Ｃの少なくとも一部に関連付けられ、および
ここで、Ｖは前記第三者が実質的に予測不能であり、
Ｂ．Ｉを受け取るとすぐ、前記第一者はＶが前記プロパティＰを満たすか否かを確認し、および
Ｃ．Ｖが前記プロパティＰを満たす場合にのみ、前記第一者が第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
［請求項３０］  時間ｔにより部分的に特徴付けられるトランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者が、ＴからＴに関するデータ列Ｃを導出し（ここで、Ｃは前記時間ｔに関する情報ＩＮを含み）、
Ｂ．前記第一者が、第二者に前記データ列Ｃの少なくとも一部を受け取らせ（ここで、前記Ｃの少なくとも一部は情報ＩＮを含み）、
Ｃ．前記第二者が、前記Ｃの少なくとも一部を項目Ｖに関連付け（ここで、Ｖは前記第一者が実質的に予測不能であり）、
Ｄ．前記第二者がＶがプロパティＰを満たすか否かを決定し、もしそうなら、前記第二者は時間ｔ'で第三者に情報ＩＮ、および前記第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせ、
Ｅ．Ｉを受け取るとすぐ、前記第三者はＶが前記プロパティＰを満たすか否かを決定し、および
Ｆ．前記第三者は
ａ）Ｖが前記プロパティＰを満たし、および
ｂ）｜ｔ'−ｔ｜が予め定められた時間間隔より小さい場合にのみ第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
［請求項３１］  前記予め定められた時間間隔｜ｔ'−ｔ｜がｎ日であり、ｎがゼロでない１から７の整数であることを特徴とする、請求項３０に記載の方法。
［請求項３２］  前記予め定められた時間間隔｜ｔ'−ｔ｜が少なくともｍ時間であり、ｍがゼロではない１から２０の整数であることを特徴とする、請求項３０に記載の方法。
［請求項３３］  前記第一者がステップＢで前記第二者にＣの一部分を時刻ｔ1＞ｔで受け取らせ、｜ｔ1−ｔ｜が予め定められた値より小さくない限り、前記第二者はＴに対する支払いとしてＣを受け取ることを拒否することを特徴とする、請求項３０に記載の方法。
［請求項３４］  前記データ列Ｃが、前記第一者の秘密鍵を使用して生成された、Ｔの少なくとも一部に対するディジタル署名から成ることを特徴とする、請求項３０に記載の方法。
［請求項３５］  ＶがＰを満たす場合にのみ、ＶがＣの少なくとも一部と一致することを特徴とする、請求項３０に記載の方法。
［請求項３６］  前記プロパティＰがＶに依存するが、Ｃには依存しないことを特徴とする、請求項３０に記載の方法。
［請求項３７］  Ｆ（Ｖ）＜ｓである場合のみ（ここで、Ｆは関数、ｓは定数であり、０＜ｓ＜１である）、ＶがＰを満たすことを特徴とする、請求項３０に記載の方法。
［請求項３８］  前記関数Ｆの値Ｆ（Ｖ）は、前記第一者が実質的に予測不能であることを特徴とする、請求項３７に記載の方法。
［請求項３９］  前記関数Ｆと前記定数ｓの少なくとも１つがＣで指定されることを特徴とする、請求項３７に記載の方法。
［請求項４０］  Ｆが
（ａ）固定公開関数、
（ｂ）任意のビット列を入力とし、０より大きく１より小さい１つの数字を戻す公開関数の１つであることを特徴とする、請求項３７に記載の方法。
［請求項４１］  Ｖが、前記第二者の秘密鍵を使用して計算され、ＳＩＧM（Ｃ）と表される、Ｃに対するディジタル署名を含むことを特徴とする、請求項３０に記載の方法。
［請求項４２］  もし全てのｉ（ｉ＝１，．．．ｎ）に対して、前記トランザクションＴＳiが時間ＴＳiにより部分的に特徴付けられ、｜ＴＳi−ｔ｜が予め定められた値より小さければ、前記第四者が前記金額を受け取るステップの後、前記第三者が前記第一者に、前記第二者により提供される１または複数のトランザクションＴＳi（ｉ＝１，．．．，ｎ）への無料加入権を受け取らせるステップをさらに含むことを特徴とする、請求項３０に記載の方法。
［請求項４３］  前記項目Ｖが
ａ）Ｔに関係してＣに含まれる日付情報、
ｂ）Ｃに含まれるシリアル番号、
ｃ）Ｃに含まれる文字列、
ｄ）Ｃのランダム文字列部分、および
ｅ）Ｃに依存する数量の少なくとも１つに対するディジタル署名を含み、
Ｖが前記第二者の秘密鍵を使用して計算され、ＳＩＧMと表されることを特徴とする、請求項３０に記載の方法。
［請求項４４］  前記項目ＶがＧ（Ｃ）のディジタル署名を含み、Ｇは関数とアルゴリズムの少なくとも１つを表すことを特徴とする、請求項３０に記載の方法。
［請求項４５］  ＶがＰを満たす場合にのみ、Ｆ（Ｖ）＝Ｆ（ＳＩＧM（Ｇ（Ｃ）））＜ｓであり、ここでＦは関数を表し、ｓは定数であって０＜ｓ＜１であり、値Ｆ（Ｖ）は前記第一者が実質的に予測不能であることを特徴とする、請求項４４に記載の方法。
［請求項４６］  Ｇ（Ｃ）がＴとＣの少なくとも１つの中で指定されることを特徴とする、請求項４４に記載の方法。
［請求項４７］  Ｇ（Ｃ）が
（ａ）Ｔの部分列、
（ｂ）前記トランザクションＴの前記時間ｔに関する情報Ｆ、
（ｃ）前記トランザクションＴが発生した日付に関する情報、および
（ｄ）前記第一者により選択された文字列Ｗの少なくとも１つを含むことを特徴とする、請求項４４に記載の方法。
［請求項４８］  前記文字列ＷがＴに対して一意であり、アト・ランダムに選択されることを特徴とする、請求項４７に記載の方法。
［請求項４９］  Ｖ＝ＳＩＧM（Ｇ（Ｃ））が、前記Ｃの少なくとも一部を受け取る前に前記第二者によって計算されるように適応されることを特徴とする、請求項４７に記載の方法。
［請求項５０］  もしＶ＝ＳＩＧM（Ｇ（Ｃ））の少なくとも数ビットがＣの少なくとも数ビットと一致したら、前記プロパティＰが満たされることを特徴とする、請求項４４に記載の方法。
［請求項５１］  もしＶ＝ＳＩＧM（Ｇ（Ｃ））の選択されたｍビット列がＣの選択されたｍビット列と一致したら、前記プロパティＰが満たされる（ここで、ｍは予め定められた正の整数）ことを特徴とする、請求項４４に記載の方法。
［請求項５２］  ｍが１０であることを特徴とする、請求項５１に記載の方法。
［請求項５３］  トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者がＴからＴに関するデータ列Ｃを導出し、第二者に前記データ列Ｃの少なくとも一部を受け取らせ、
Ｂ．前記第二者が、プロパティＰが前記Ｃの少なくとも一部とＣに依存する数量Ｑの間に有効であるか否かを決定し（Ｑは前記第一者が実質的に予測不能であり）、もしそうなら、前記第二者は第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
Ｃ．Ｉを受け取るとすぐ、前記第三者は前記プロパティＰが満たされるか否かを決定し、および
Ｄ．前記プロパティＰが前記Ｃの少なくとも一部とＱで有効であることを確認したらすぐ、前記第三者は第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
［請求項５４］  前記数量ＱはＧ（Ｃ）と表され、Ｇは関数とアルゴリズムの少なくとも１つであることを特徴とする、請求項５３に記載の方法。
［請求項５５］  Ｇ（Ｃ）は、情報を
ａ）前記トランザクションＴが発生する時間ｔ、および
ｂ）前記トランザクションＴが発生する日付ｄの少なくとも１つに含むことを特徴とする、請求項５４に記載の方法。
［請求項５６］  前記プロパティＰが有効である場合にのみ、Ｃの少なくとも数ビットがＳＩＧM（Ｇ（Ｃ））の少なくとも数ビットと等しく、ＳＩＧM（Ｇ（Ｃ））はＧ（Ｃ）に対する前記ディジタル署名を表し、前記第二者の秘密鍵を使用して生成されることを特徴とする、請求項５５に記載の方法。
［請求項５７］  時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者がＴからＴに関するデータ列Ｃを導出し、
Ｂ．第二者が、一連の時間ｔi（ｉ＝１，．．．，ｎ）に関連する一連の値ＶＬiを導出し、少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、｜ｔ−ｔm｜が予め定められた値より小さく、
Ｃ．前記第一者が前記第二者に前記データ列Ｃの少なくとも一部を受け取らせ、前記一部は前記トランザクションＴの時間ｔに関する情報を含み、
Ｄ．前記第二者は、プロパティＰがＣの一部分とｔmに関連する前記値ＶＬmの１つの間で有効であるか否かを決定し、数量ＱはＶＬmに依存し、
Ｅ．もしＰが有効なら、前記第二者は第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
Ｆ．Ｉを受け取るとすぐ、前記第三者はＱがＰを満たすか否かを決定し、および
Ｇ.Ｑが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせることを特徴とする方法。
［請求項５８］  前記数量ＱがＱ＝Ｆ（ＳＩＧM（Ｖm））により与えられ、Ｆは関数を表し、ＳＩＧM（Ｖm）は、前記第二者の秘密鍵を使用して生成されたＶmのディジタル署名を表すことを特徴とする、請求項５７に記載の方法。
［請求項５９］  トランザクションＴにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者が、ＴからＴに関するデータ列Ｃを導出し、Ｃはｔに関する情報を含み、
Ｂ．第二者が、一連の時間単位ｔi（ｉ＝１，．．．，ｎ）に関連付けられる一連の値Ｖiを導出し、
隣接する時間単位ｔi+1とｔiの各ペアが、時間間隔Δｔi＝ｔi+1−ｔiを定め、および
少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、前記時間ｔは時間間隔Δｔmの範囲内であり、
Ｃ．前記時間間隔Δｔmのはじめには、前記第二者がＶmに関連する値Ｑmを導出し、Ｑmは前記第一者は実質的に予測不能であり、
Ｄ．前記時間間隔Δｔmの間に、
ａ）前記第一者が前記第二者にＣの少なくとも一部を受け取らせ、
ｂ）前記第二者が、プロパティＰがＣの一部分とＱmの間で有効であるか否かを決定し、もしそうなら、前記第二者は第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
Ｅ．Ｉを受け取るとすぐ、前記第三者はＱがＰを満たすか否かを決定し、および
Ｆ．Ｑが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせることを特徴とする方法。
［請求項６０］  ステップＣがステップＢの前に発生し、前記プロパティＰが満たされる場合にのみ、Ｑの少なくとも数ビットがＣの少なくとも数ビットと一致することを特徴とする、請求項５９に記載の方法。
［請求項６１］  ＱiがＱi＝Ｆ（ＳＩＧM（Ｖi））により与えられ、Ｆが関数を表し、ＳＩＧM（Ｖi）が、前記第二者の秘密鍵を使用して生成される、Ｖiのディジタル署名を表すことを特徴とする、請求項５９に記載の方法。
［請求項６２］  全てのｉ＝１，．．．，ｎに対して、時間間隔Δｔi＝｜ｔi+1−ｔi｜が予め定められた時間間隔であることを特徴とする、請求項５９に記載の方法。
［請求項６３］  前記予め定められた定数が１日であることを特徴とする、請求項６２に記載の方法。
［請求項６４］  時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者が、ＴをＴに関するデータ列Ｃから導出し、Ｃはｔに関する情報Ｆを含み、
Ｂ．第二者が、一連の時間の値ｔi （ｉ＝０, 1, ... , n）に関連する一連の値ｘi（ｉ＝０，１，．．．，ｎ）を導出し、ｘ0を公開し、
ｘi＝Ｈ（ｘi+1）（ｉ＝０，１，．．．，ｎ−１）であって、Ｈは一方向ハッシュ関数であり、
隣接する時間の値ｔi+1とｔiの各ペアは、時間間隔Δｔiｔi+1−ｔiを定め、および
少なくとも１つの整数ｍ（１＜ｍ＜ｎ）に対して、前記時間ｔは時間間隔Δｔmであり、
Ｃ．前記時間間隔Δｔmの間に、前記第一者が前記第二者にＣの少なくとも一部を受け取らせ、前記一部はＦを含み、
Ｄ．前記時間間隔Δｔmの間に、前記第二者がプロパティＰはＱmとＣの一部分の間で有効であるか否かを決定し、もしそうなら、前記第二者が第三者に前記第三者が前記プロパティＰが満たされているか否かを確認することを可能にする情報Ｉを受け取らせ、
Ｅ．Ｉを受け取るとすぐ、前記第三者がＱmはＰを満たすか否かを決定し、および
Ｆ．Ｑが前記プロパティＰを満たす場合にのみ、前記第三者が第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
［請求項６５］  前記第二者がｘ0を公開するステップが、
ａ）ｘ0を公開ファイルに配置すること、および
ｂ）前記第二者の秘密鍵を使用してｘ0にディジタル署名し、対応する公開鍵を公開ディレクトリに配置することの少なくとも１つを含むことを特徴とする、請求項６４に記載の方法。
［請求項６６］  前記時間間隔Δｔi＝ｔi+1−ｔiが予め定められた定数（ｉ＝１，．．．，ｎ）であることを特徴とする、請求項６４に記載の方法。
［請求項６７］  時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するためのシステムであって、
Ａ．第一者、第二者、第三者、および第四者の間でデータを伝達するための通信手段、
Ｂ．Ｔに関するデータ列Ｃを導出し、入力し、記憶するために、第一者による動作させられる第１処理手段（ここで、Ｃは時間ｔに関する情報Ｆを含む）、
Ｃ．項目ＶをＣの少なくとも一部に関連付け、ＶがプロパティＰを満たすか否かを決定するために、第二者により動作させられてＣに応答する第２処理手段、
（ここで、Ｖは前記第一者が実質的に予測不能）
Ｄ．ＶがＰを満たすとき、第三者にＦ、および前記第三者が、
ａ）ＶがＰを満たすか否か、および
ｂ）｜ｔ'−ｔ｜が予め定められた値より小さいことを確認することを可能にする情報Ｉを受け取らせるために、前記第二者により選択的に動作させられる手段、
Ｅ．ＶがＰを満たすとき、および｜ｔ'−ｔ｜が予め定められた値より小さいときに、第四者に金額Ａを受け取らせるために、前記第三者により選択的に動作させられる手段から成ることを特徴とするシステム。
［請求項６８］  時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者が、第二者から時間ｔ'に前記第一者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取り、
前記項目Ｖは、第三者によりＴから導出され、ｔに関する情報を含むデータ列Ｃの少なくとも一部と関連付けられ、および
Ｖは、前記第三者が実質的に予測不能であり、
Ｂ．Ｉを受け取るとすぐ、前記第一者がＶが前記プロパティＰを満たすか否かを確認し、および
Ｃ．前記第一者は、
ａ）Ｖが前記プロパティＰを満たし、および
ｂ）｜ｔ'−ｔ｜が予め定められた値より小さい場合にのみ、第四者に金額Ａを受け取らせることを特徴とするシステム。
［請求項６９］  時間ｔにより部分的に特徴付けられる、トランザクションＴに対する支払いを確立するための方法であって、
Ａ．第一者が第二者からデータ列Ｃの少なくとも一部を受け取り、前記データ列ＣはＴに関連し、Ｃの一部分は情報をｔに含み、
Ｂ．前記第一者が前記Ｃの少なくとも一部を項目Ｖに関連付け、Ｖは前記第二者が実質的に予測不能であり、および
Ｃ．前記第一者がＶがプロパティＰを満たすか否かを決定し、もしそうなら、時間ｔ'に前記第一者が第三者に前記第三者がＶが前記プロパティＰを満たすか否かを確認することを可能にする情報Ｉを受け取らせ、それにより前記第三者が
ａ）ＶがＰを満たし、および
ｂ）｜ｔ'−ｔ｜が予め定められた値より小さい場合にのみ、第四者に金額Ａを受け取らせる諸ステップから成ることを特徴とする方法。
［請求項７０］  複数のｎトランザクションＴ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より大きくならないようにする。
［請求項７１］  各借方金額Ｄjが、ＴＶjとＣj（１＜ｊ＜ｎ）の１つにより少なくとも部分的に決定されることを特徴とする、請求項７０に記載の方法。
［請求項７２］  各借方金額Ｄjが、Ｔjに関連付けられる前記インデックスｊに依存することを特徴とする、請求項７０に記載の方法。
［請求項７３］  各借方金額Ｄjも前の借方金額Ｄk（１≦ｋ＜ｊ≦ｎ）の少なくとも１つに依存し、前のインデックスｌ（１≦ｌ＜ｊ≦ｎ）に対して借方金額Ｄlが付けられることを特徴とする、請求項７２に記載の方法。
［請求項７４］  前記第五者が、前記インデックスｊの表示を支払いに対して選択された各小切手Ｃjに対して記憶させるステップをさらに含むことを特徴とする、請求項７０に記載の方法。
［請求項７５］  支払い可能な小切手Ｃjの各借方金額Ｄjが、支払い可能であることが分かった前の小切手の一番後で記憶されたインデックスｋに依存することを特徴とする、請求項７４に記載の方法。
［請求項７６］  前記第二者が前記第三者に前記情報Ｉを受け取らせるステップが、
ａ）前記第二者がＩjを前記第三者に送信すること、
ｂ）前記第二者が第五者にIjを前記第三者に送信することを頼むこと、および
ｃ）前記第二者がＩjをファイルに書き込み、前記第三者がＩjを前記ファイルから回収することの少なくとも１つを含むことを特徴とする、請求項７０に記載の方法。
［請求項７７］  複数のｎトランザクションＴ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以下であることを特徴とする方法。
［請求項７８］  Ｄ1＋Ｄ2＋．．．＋Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶ1＋ＴＶ2＋．．．＋ＴＶi以下であることを特徴とする、請求項７７に記載の方法。
［請求項７９］  各借方金額Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶiとＣiの１つにより少なくとも部分的に決定されることを特徴とする、請求項７７に記載の方法。
［請求項８０］  各データ列Ｃiが、Ｔiに関連する前記インデックスｉの表示を含むことを特徴とする、請求項７７に記載の方法。
［請求項８１］  各借方金額Ｄiが、Ｔiに関連する前記インデックスｉに依存することを特徴とする、請求項８０に記載の方法。
［請求項８２］  各借方金額Ｄiも、借方金額Ｄjと借方金額Ｄkが借方に付けられる前のインデックスｋの少なくとも１つに依存することを特徴とする、請求項８１に記載の方法。
［請求項８３］  Ｄ1＋Ｄ2＋．．．＋Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶ1＋ＴＶ2＋．．．＋ＴＶi以下であることを特徴とする、請求項８２に記載の方法。
［請求項８４］  ＶiがＰiを満たすときはいつも、前記第五者が情報ＳＮiを各データ列Ｃiに対して記憶させるステップをさらに含むことを特徴とする、請求項７７に記載の方法。
［請求項８５］  ＳＮiは、前記第一者により導出された順番に並べられたデータ列にある他のデータ列Ｃ1，．．．，Ｃi-1およびＣi+1，．．．，Ｃnに対する前記データ列Ｃiの順番を表す漸進的シリアル番号であることを特徴とする、請求項８４に記載の方法。
［請求項８６］  各借方金額ＤiがＳＮiを使用して決定されることを特徴とする、請求項８４に記載の方法。
［請求項８７］  Ｄ1＋Ｄ2＋．．．＋Ｄiが、全インデックスｉ（１＜ｉ＜ｎ）に対してＴＶ1＋ＴＶ2＋．．．＋ＴＶi以下であることを特徴とする、請求項８４に記載の方法。
［請求項８８］  各借方金額ＤiがＳＮiを使用して決定されることを特徴とする、請求項８４に記載の方法。
［請求項８９］  複数の同じ値のトランザクションＴ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）＊ＴＶにより与えられる諸ステップから成ることを特徴とする方法。
［請求項９０］  ＶiがＰiを満たす場合にのみＦ（Ｖi）＜ｓであり、ｓは数値であり、Ｆはビット文字列に作用して数値を戻す関数であることを特徴とする、請求項８９に記載の方法。
［請求項９１］  前記第四者により受け取られる前記売掛金額ＣＲがＴＶおよび１／ｓに比例することを特徴とする、請求項９０に記載の方法。
［請求項９２］  Ｆはビット文字列に作用して０と１の間の数値を出力する関数であり、ｓは０と１の間の数値であることを特徴とする、請求項９０に記載の方法。
［請求項９３］  トランザクション値ＴＶ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を記入させる諸ステップから成る方法。
［請求項９４］  全てのｉ＝１，．．．，ｎに対してＴＶi＝ＴＶであるように各トランザクションＴi（ｉ＝１，．．．，ｎ）が同じ値であり、Ｄiが
Ｄi＝（Ｓi−Ｓmax ）＊ＴＶにより与えられ、
およびＣＲが
ＣＲ＝ＴＶ＊（１／ｓ）により与えられことを特徴とする、請求項９３に記載の方法。
［請求項９５］  複数のｎトランザクションＴ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より大きくない）から成ることを特徴とするシステム。
［請求項９６］  複数のｎトランザクションＴ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より大きくない諸ステップから成ることを特徴とする方法。
［請求項９７］  複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、インデックスｉ（１＜ｉ＜ｎ）が各Ｔiに関連付けられ、各トランザクションＴiが部分的にトランザクション値ＴＶiにより特徴付けられ、対応するデータ列Ｃiにより表され、
Ａ．第一者が、前記第一者が小切手Ｃjが支払い可能であることを確認することを可能にする情報Ｉjを第二者から受け取り、
wherein 前記小切手Ｃjは、前記複数のトランザクションＴi（ｉ＝１，．．．，ｎ）の１つに対応するものから第三者により導出された複数の小切手Ｃi（ｉ＝１，．．．，ｎ）から前記第二者により選択され、および
前記小切手Ｃjの選択は、前記第三者が実質的に予測不能であり、
Ｂ．Ｉjを受け取るとすぐ、前記第一者がＣjが確かに支払い可能であるかを確認し、および
Ｃ．前記第一者が第四者に売掛金額ＣＲiを受け取らせ、前記第三者の借方に借方金額Ｄiを付ける諸ステップから成ることを特徴とする方法。
［請求項９８］  複数のｎトランザクションＴ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）＊ＵＶにより与えられる諸ステップから成ることを特徴とする方法。
［請求項９９］  複数のｎトランザクションＴ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）＊ＵＶにより与えられる諸ステップから成ることを特徴とする方法。
［請求項１００］  複数のｎトランザクションＴi（ｉ＝１，．．．，ｎ）に対する支払いを確立する方法であって、各トランザクションＴiは値ＴＶiを有し、
ａ．第一者が各ＴiからＴiに関連するデータ列Ｃiを導出し、第二者に前記データ列Ｃiを受け取らせ、
ｂ．前記第二者は、前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループをｍ個のリストＬk（ｋ＝１，．．．，ｍ）へ一意に関連付け、
ここで、各リストＬkは、データ列Ｃk1，．．．，Ｃkｌkを含み、
Σmk=1ｌk＝ｎであり、
ｃ．各Ｌkに対するコミットメントＣＭkを計算し、第三者にＣＭk（ｋ＝１，．．．，ｍ）を受け取らせることにより、前記第二者がＬk（ｋ＝１，．．．，ｍ）にコミットし、
ｄ．ＣＭk（ｋ＝１，．．．，ｍ）の受け取りに応答して、前記第三者が１または複数の整数インデックスｉ1，ｉ2，．．．，ｉrを選択し、前記第二者に前記インデックスｉ1，ｉ2，．．．，ｉr（１≦ｉr≦ｍ）を受け取らせ
ｅ．前記インデックスｉ1，ｉ2，．．．，ｉrの受け取りに応答して、前記第二者がＣＭi1，ＣＭi2．．．ＣＭirをデ・コミットし、それによりＬi1，．．．，Ｌirを前記第三者に明らかにし、および
ｆ．第五者が第四者に売掛金額ＣＲを受け取らせ、前記第一者の借方に借方金額Ｄを付ける諸ステップから成ることを特徴とする方法。
［請求項１０１］  Ｌkに対する前記コミットメントＣＭkはハッシュ値Ｈ（Ｌk）であり、Ｈは一方向ハッシュ関数であることを特徴とする、請求項１００に記載の方法。
［請求項１０２］  各データ列Ｃiが、前記トランザクション値ＴＶiを表す１または複数のビットを含むことを特徴とする、請求項１００に記載の方法。
［請求項１０３］  前記第二者が各リストＬkを対応する値Ｖkに関連付け、ＶkはリストＬkの全てのデータ列Ｃk1，．．．，Ｃkｌkの集約値を表し、ＶkはＶk＝ＴＶk1＋．．．＋ＴＶkｌkにより与えられるステップをステップ（ｂ）の後にさらに含むことを特徴とする、請求項１０２に記載の方法。
［請求項１０４］  前記第二者が、値（Ｖ1，．．．，Ｖm）のリストに対するコミットメントＣＶを計算し、
前記コミットメントＣＶは、前記第二者を（Ｖ1，．．．，Ｖm）にコミットさせ、
ＣＶはハッシュ値Ｈ（Ｖ1，．．．，Ｖm）であり、および
Ｈは一方向ハッシュ関数であり、ＣＶをデ・コミットすることにより、前記第二者が reveals （Ｖ1，．．．，Ｖm）を前記第三者に明らかにするステップをステップ（ｃ）の後にさらに含むことを特徴とする、請求項１０３に記載の方法。
［請求項１０５］  前記第四者により受け取られた前記売掛金額ＣＲは、
Ｖ＝Ｖ1＋...＋Ｖk＋．．．＋Ｖm＝Σmk=1 Ｖkにより与えられることを特徴とする、請求項１００に記載の方法。
［請求項１０６］  前記借方金額Ｄは、
スケール因子を掛けられたＤ＝Ｖi1＋Ｖi2＋．．．＋Ｖirにより与えられることを特徴とする、請求項１００に記載の方法。
［請求項１０７］  前記スケール因子がｍ／ｒであることを特徴とする、請求項１０６に記載の方法。
［請求項１０８］  前記各データ列Ｃiが１つの整数ＳＮiを表す情報を含み、ＳＮiは１から始まる漸進的シリアル番号であり、前記シリアル番号ＳＮiは、前記複数のｎトランザクションＴi（ｉ＝１，．．．，ｎ）の他のトランザクションＴ1，．．．，Ｔi-1およびＴi+1，．．．，Ｔnに対する前記トランザクションＴiの時間の順序を表すことを特徴とする、請求項１００に記載の方法。
［請求項１０９］  前記第一者が前記データ列ＣiをＴiから導出するステップが、前記第一者が前記第一者の秘密鍵を使用してＴの少なくとも一部iに対するディジタル署名を生成するステップを含むことを特徴とする、請求項１００に記載の方法。
［請求項１１０］  Ｃiの少なくとも一部が認証されることを特徴とする、請求項１００に記載の方法。
［請求項１１１］  Ｃiが、
ａ）Ｔの少なくとも一部に対するディジタル署名、
ｂ）メッセージ認証コード、および
ｃ）電子小切手の少なくとも１つを含むことを特徴とする、請求項１００に記載の方法。
［請求項１１２］  前記第五者と前記第三者が同じであることを特徴とする、請求項１００に記載の方法。
［請求項１１３］  前記第二者、前記第三者、および前記第五者が同じであることを特徴とする、請求項１００に記載の方法。
［請求項１１４］  前記第二者と前記第三者が同じであることを特徴とする、請求項１００に記載の方法。
［請求項１１５］  複数のｎトランザクションＴ1，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、各トランザクションＴiは値ＴＶiを有し、
Ａ．各Ｔiに対して、第一者が第二者からＴiから導出されたデータ列Ｃiを受け取り、
Ｂ．前記第一者が、前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループをｍ個のリストＬk（ｋ＝１，．．．，ｍ）に一意に関連付け、
ここで、各リストＬkはデータ列Ｃk1，．．．，Ｃkｌkを含み、および
Σmk=1ｌk＝ｎであり、
Ｃ．前記第一者が、各Ｌkに対するコミットメントＣＭkを計算することによりＬk（ｋ＝１，．．．，ｍ）にコミットし、第三者にＣＭk（ｋ＝１，．．．，ｍ）を受け取らせ、それにより前記第三者が１または複数の整数インデックスｉ1，ｉ2，．．．，ｉr（１≦ｉr≦ｍ）を選択することを可能にし、
Ｄ．前記インデックスｉ1，ｉ2，．．．，ｉrを受け取るとすぐ、前記第一者がＣＭi1，ＣＭi2．．．ＣＭirをデ・コミットし、それによりＬi1，．．．，Ｌirを前記第三者に明らかにし、前記第三者が第四者に売掛金額ＣＲを受け取らせ、前記第二者の借方に借方金額Ｄを付けることを可能にする諸ステップから成ることを特徴とする方法。
［請求項１１６］  複数のｎトランザクションＴ1，．．．，Ｔi，．．．，Ｔnに対する支払いを確立する方法であって、各トランザクションＴiは値ＴＶiを有し、Ｔiから導出される対応するデータ列Ｃiにより表され、前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループがｍ個のリストＬk（ｋ＝１，．．．，ｍ）に一意に関連付けられ、各リストＬkはデータ列Ｃk1，．．．，Ｃkｌk（Σmk=1ｌk＝ｎ）を含み、
Ａ．第一者が、第二者から各ｍ個のリストＬk（ｋ＝１，．．．，ｍ）に対するコミットメントＣＭkを受け取り、
Ｂ．ＣＭk（ｋ＝１，．．．，ｍ）を受け取るとすぐ、前記第一者が１または複数の整数インデックスｉ1，ｉ2，．．．ｉr（１≦ｉr≦ｍ）を選択し、前記第二者に前記インデックスｉ1，ｉ2，．．．，ｉrを受け取らせ、それにより前記第二者がＣＭi1，ＣＭi2．．．ＣＭirをデ・コミットしてＬi1，．．．，Ｌirを to 前記第一者に明らかにすることを可能にし、
Ｃ．前記第一者が第三者に売掛金額ＣＲを受け取らせ、第四者の借方に借方金額Ｄを付ける諸ステップから成ることを特徴とする方法。
［請求項１１７］  複数のｎトランザクションＴ1，Ｔ2，．．．，Ｔi，．．．，Ｔnに対する支払いを確立するためのシステムであって、各Ｔiは値ＴＶiを有し、
Ａ．第一者、第二者、第三者、および第四者の間でデータを伝達するための通信手段、
Ｂ．各Ｔiに対するデータ列Ｃi（１≦ｉ≦ｎ）を導出し、入力し、記憶するために第一者により動作させられる第１処理手段、
Ｃ．前記データ列Ｃi（ｉ＝１，．．．，ｎ）のグループをｍ個のリストＬk（ｋ＝１，．．．，ｍ）へ一意に関連付け、前記リストＬk（ｋ＝１，．．，ｍ）を入力し記憶するために、Ｃi（ｉ＝１，．．．ｎ）の受け取りに応答して第二者により動作させられる第２処理手段、
（ここで、各リストＬkはデータ列Ｃk1，．．．，Ｃkｌkを含み、
Σmk=1ｌk＝ｎであり、
各Ｌkに対するコミットメントＣＭkを計算し、前記コミットメントＣＭk（ｋ＝１，．．．，ｍ）を入力して記憶するために、記第２処理手段は前記第二者により動作させられ、）
Ｄ．前記コミットメントＣＭkを受け取るとすぐ、１または複数の整数インデックスｉ1，ｉ2，．．．，ｉrを選択し、前記第二者に前記インデックスｉ1，ｉ2，．．．，ｉr（１≦ｉr≦ｍ）を受け取らせるために前記第三者により動作させられる第３処理手段、
Ｅ．前記インデックスｉ1，ｉ2，．．．，ｉrを受け取るとすぐ、ＣＭをデ・コミットするために前記第二者により動作させられ、それにより前記第三者に明らかにする第４処理手段、および
Ｆ．Ｌi1，．．．，Ｌirを受け取るとすぐ、前記第一者の借方に借方金額Ｄを付け、第四者に売掛金額ＣＲを受け取らせるために前記第三者により動作させられる手段から成ることを特徴とするシステム。
［図１］
2008504612.tif 000123
［図２］
2008504612.tif 000124
［図３］
2008504612.tif 000125
［図４］
2008504612.tif 000126
［図５］
2008504612.tif 000127
［図６］
2008504612.tif 000128
［図７］
2008504612.tif 000129
【国際調査報告】
2008504612.tif 000130