JP2008504612A - ペイメント処理方法システム - Google Patents

Abstract

ペイメント処理システムは、消費者と業者の間のスモール・トランザクションに関連する費用データを集約する１つのトランザクション・プロセッサを含む。トランザクション・プロセッサは、集約された費用データを表すデータを、業者に関連する承継銀行エンティティに送信する。また、システムは、各個人のスモール・トランザクションを表すデータを記憶する別の１つのトランザクション・プロセッサも含む。記憶されたデータは、業者に関連する１又は複数の銀行エンティティによってアクセス可能である。

Description

関連出願
本願は、（ａ）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は所定の業者における所定の消費者に対する購入の間の時間の金額である。業者における消費者の購入行動は、金額と中間到着時間の順序、即ち、Ｐ₁．．．Ｔ₂．．．Ｐ₂．．．Ｔ₃．．．Ｐ₃．．．Ｔ₄．．．Ｐ₄．．．Ｔ₅．．．Ｐ₅として閲覧できる。

集約は、交換分類と、マクロ認証とマクロ取り込み／マクロ決済の間のタイミングを最適化することによって既存の「集約ウィンドウ」の内部にマイクロ・トランザクションを更に入力する利益の間のトレードオフを実質的に最適化する。更に、集約は、交換の等級を下げることの潜在的な費用上の影響に対する集約の利益を実質的に最適化する。

付録Ｇを参照すると、集約を制御するために業者が設定できるパラメータを記述する表が提供される。ペイメント処理システム１０は、業者によって設定されたパラメータの制御のもとで、トランザクション−トランザクションに基づいて集約を実質的に最適化する。取り合わせの中には、これらのパラメータが複雑であると考えられるものもあるが、ユーザに集約パラメータの理解を学習、又は取得することを要求することなく、デフォルト設定は実質的に最適化された集約結果を提供する。一般に、ペイメント処理システム１０は、会社のコンプライアンス・ガイドラインの範囲内で動作する集約を実行し、会社規則に準拠する単一業者集約を維持する。

図８を参照すると、集約を通して、ペイメント処理システム５２は、多くの消費者、業者、及び／又はペイメント提供者の全体にわたる低額トランザクションを集約する。ペイメント処理システム５２は、安全なペイメント処理システムを維持しながら、大容量のマイクロ・ペイメント処理をペイメント・ネットワーク・コアからスモール・トランザクション・プロセッサ５４，５６、消費者口座プロセッサ５８、及びマイクロ・ペイメント・プロセッサ６０の様な分散されたプロセッサに移動させることによって、トランザクション集約を拡張する。

ペイメント処理システム５２は、セキュア集中制御を維持しながら、ペイメント処理の大規模配布を可能にする暗号化セキュア選択（ＣＳＳ）モジュールを含む。この配置では、ＣＳＳモジュールがシステム動作を２つのレイヤに分離する。第１レイヤは、業者を有する消費者マイクロ・ペイメント・トランザクションがスモール・トランザクション・プロセッサ（例えば、スモール・トランザクション・プロセッサ５４）に記録される、分散されたリアルタイム・マイクロ・ペイメント処理レイヤである。第２レイヤは、マクロ・ペイメント、及び非リアルタイムで動作し、既存のペイメント・ネットワークとインターフェースする分散された制御レイヤである。

一般に、マイクロ・ペイメントとマクロ・ペイメント・レイヤが通信する。例えば、リアルタイム・トランザクションを制御する方針は、スモール・トランザクション・プロセッサに関連するマイクロ・ペイメント・レイヤによって（必要に応じて）フェッチされ、そのレイヤによってキャッシュされる。例えば、これらの方針は、リアルタイム不正手段チェックの間に、複数のマイクロ・ペイメント・トランザクションを認証する。一般に、マイクロ・ペイメント・レイヤは、マクロ・ペイメント・レイヤの後方の要約決済情報と通信するが、しかし、詳細なマイクロ・ペイメント記録は、費用が減少されたスモール・トランザクション・プロセッサに記憶される。

セキュリティ制御を強化するために、ペイメント処理システム５２は、暗号化セキュア選択モジュールに基づいて監査プロトコルを実施する。このプロトコルを使用して、マクロ・ペイメント・レイヤは詳細なマイクロ・トランザクションのスモール・サブセットを試験でき、適切なペイメント処理が全てのマイクロ・トランザクションで発生したことを確実に保証する。これは、費用低減を提供しながら、セキュリティを維持する。

ペイメント処理システム５２は、拡大縮小が容易で極めて安全な動作のために設計される。認証の対象、及びシステムの内部で認証の対象が行う動作の役割は、注意深く分割される。取り合わせの中には、構成要素が共用の公開鍵に基づく確認システムによって確認されるものもある。送信されて記憶されるときに、機密を保持するように指定される情報は暗号化され、確認する必要がある情報は、ディジタル的に署名される。システムは信用情報を厳重に管理し、その使用を制限し、信用情報は、軽快な破棄プロセスを用いて取り消し可能である。

ペイメント・ネットワーク・センタから分散されたスモール・トランザクション・プロセッサ（例えば、スモール・トランザクション・プロセッサ５４，５６）に計算を移動させることによって、暗号化セキュア選択プロセスは、費用的優位を提供する。一般に、ペイメント・システムの中心においてペイメントを処理することは、実質的な中央コンピューティング、及び更に高価な通信基盤を必要とする。スモール・トランザクション・プロセッサにおけるペイメント処理は、実質的に余り高価でない汎用ハードウェアで実行され、通信は電子商取引ウェブサイトに対してローカルである。暗号化セキュア選択モジュールを用いて、ペイメント処理システム５２は、多数のトランザクションを更に安い費用で扱うことが出来る低価格で拡大縮小が容易な集約基盤を提供する。

一般に、業者は、顧客と対話するレベルであるマイクロ・トランザクション・レベルにおいてビジネスを管理する。ペイメント処理システム５２は、一群のマクロ・レベル・トランザクションの観点から基金が業者へ流れるように、第三者ペイメント・ネットワーク対話を最適化することを試みる。システムの決済・調停レイヤは、基金の流れを一群のマクロ・トランザクションから個人のマイクロ・トランザクションへマッピングする。決済レイヤは、部分的な決済を含む種々の要因を扱うことができ、例えば、 Visa が決済されたトランザクションのサブセットを支払い、 American Express がペイメントを保留する。また、口座引き落とし拒否も扱われ、例えば、発行銀行が、特定の消費者の苦情に関連する業者を有する口座引き落とし拒否プロセスを開始する。扱われる別の１つの要因は、業者のグループの間の基金を承継銀行レベルとスモール・トランザクション・プロセッサのレベルの両方において分割することである。

図４に戻ると、スモール・トランザクション・プロセッサ１２は監査・制御モジュール６２を含み、ペイメント処理システム１０が組織によって運用される中央ペイメント処理システムに関連する規則を遵守することを保証する。組織は、殆ど全てのペイメントが信頼される 「第三者プロセッサ」によって検査されることを前提とするコンプライアンス規則を定める。従来のシステムの中には比較的大きな割合のマクロ・トランザクションを検査することが出来るものもあるが、もし従来のシステムが大きな割合のマイクロ・トランザクションを検査する必要があれば、マイクロ・トランザクション処理の費用はマクロ・トランザクション処理の費用と同じであり、業者はスモール・トランザクション・マーケットに入ることが出来ない。

監査・制御モジュール６２は、監査人が全てのマイクロ・トランザクションを検査する必要なしに、高レベルの信頼度をマイクロ・トランザクション処理コンプライアンスで提供する。監査・制御モジュール６２は、2002年04月17日に出願の特許協力条約（ＰＣＴ）出願PCT/US02/12189に記載のような暗号化セキュア選択の技術を実施する。PCT/US02/12189の写しが、付録Ｈで提供される。暗号化セキュア選択は、マイクロ・トランザクションのサブセットが、全体の組に対する結果を確実に推定することを可能にする方法で監査されることを可能にする。監査・制御モジュール６２は、僅かな費用で広範なコンプライアンスを監視する利益を提供し、スモール・トランザクション・プロセッサ１２において仕事の約９５％を行い、他において仕事の約５％を行う。

種々の問題が、監査・制御モジュール６２によってチェックされる。例えば、モジュールは、決済バッチが請求金額の合計になるか、全ての請求されたトランザクションが認証されたか、又はバッチに重複が存在しないかをチェックする。更に、監査・制御モジュール６２は、交換クラスによって要求される様に、適切な程度のＡＶＳ一致、ＣＶＶ一致、 Visa によって検証された一致が各マイクロ・トランザクションに存在するかを決定する。交換クラスによって設計される様な範囲内の認証、取り込み、及び決済の間のタイミングの様な他の問題が、チェックされる。監査・制御モジュール６２は拡張可能であり、将来的に他の問題がチェックされることを可能にする。

図９を参照すると、タイムスタンプされた公開鍵署名を用いて署名することによって業者がトランザクションにコミットするとき、監査に対する初期条件が確立される。公開鍵署名は、計算的に高価である。マークル木の技術は、Ｎ個の公開鍵署名とＮ個のセキュアな一方向ハッシュのバッチを、１個の公開鍵署名、２＊Ｎ−１個のハッシュ、及びハッシュサイズ＊ｌｇＮより多いバイト／メッセージと交換する。

図を参照すると、この実施例では、業者によってディジタル的に署名されるトランザクションを実証するマークル木６４（Ｎ＝８）が示される。例えば、Ｔ₀₁₀、及びＳＩＧ_m（Ｔ₀₁₀）は、マークル木ｖ₀₁₁，ｖ₀₀，ｖ₁，ｖの木構造中のハッシュ値のチェーンに加えて、同じトランザクションＴ₀₁₀、及びマークル木ＳＩＧ_m（ｖ）のルートのディジタル署名と同等である。受信者は、ＳＩＧ_m（ｖ）、及びｖ＝Ｈ（Ｈ（Ｈ（ｖ₀₀，Ｈ（Ｔ₀₁₀），ｖ₀₁₁）），ｖ₁）であることをチェックでき、ｖ＝Ｈ（Ｈ（Ｈ（ｖ₀₀，Ｈ（Ｔ₀₁₀），ｖ₀₁₁）），ｖ₁）であることは、業者がディジタル署名ＳＩＧ_m（Ｔ₀₁₀）を生成できたことを証明する。即ち、もし業者がマークル木署名を生成できたら、業者はＴ₀₁₀の様な特定のトランザクションにも直接署名できた。マークル木技術は、１つの署名ＳＩＧ_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）を入力することによって、顧客サービスＧＵＩ８８が示される。この実施例では、明細書８６に含まれる複数の業者のリスト、及び対応する小計をＧＵＩ８８は示す。業者の１つの関連する特定のリンクを選択することによって、その業者に関連する個々のトランザクションのリストが示される。

以上、本発明の好ましい実施例について図示し記載したが、特許請求の範囲によって定められる本発明の範囲から逸脱することなしに種々の変形および変更がなし得ることは、当業者には明らかであろう。

大規模ペイメント・システムを表すブロック図である。 トランザクション費用を減少させるための、図１に示される大規模ペイメント・システム内部のプロセッサの分布のブロック図である。 分散されたプロセッサを含むサーバの位置を表すブロック図である。 分散されたプロセッサに含まれる機能モジュールを表すブロック図である。 分散されたプロセッサに含まれる機能モジュールを表すブロック図である。 低額トランザクションに関連する動作を表す流れ図である。 分散されたプロセッサの間で実行される、単一の業者に関連する動作を表すブロック図である。 分散されたプロセッサの間で実行される、複数の業者に関連する動作を表すブロック図である。 マークル木(Merkle tree)を表すブロック図である。 分散された各プロセッサに含まれるルータを表すブロック図である。 分散されたプロセッサのノードを表すブロック図である。 請求書の一部、及びグラフィカル・ユーザ・インターフェースである。 トランザクション明細を提供するグラフィカル・ユーザ・インターフェースである。 個々のトランザクションを識別するグラフィカル・ユーザ・インターフェースである。 顧客サービスに関連するグラフィカル・ユーザ・インターフェースである。 顧客からのサービス要求を受信することに関連するグラフィカル・ユーザ・インターフェースである。 サービス提供者に対する顧客要求を表すグラフィカル・ユーザ・インターフェースである。 集約された低額トランザクション情報を表すグラフィカル・ユーザ・インターフェースである。

符号の説明

１０，５２ ペイメント処理システム
１２、４４，４６，５４，５６ スモール・トランザクション・プロセッサ
１４，２０，２２ サーバ
２４，５０，６０ マイクロ・ペイメント・プロセッサ
２６ 分散処理エンジン
２８ 拡張可能なマーク付け言語（ＸＭＬ）ＡＰＩ
３０，６６ トランザクション・ルータ
３２ 集約構成要素
３４ トランザクションの決済と調停を補助する構成要素
３６ セキュリティを提供する構成要素
３８ ペイメント構成要素
４０ 流れ図
４２ ブロック図
４８，５８ 消費者口座プロセッサ
６２ 監査・制御モジュールスモール・トランザクション・プロセッサ
６４ マークル木
６８ 処理ノード
７０ 負荷平衡器

Claims (36)

1. ペイメント処理システムであって、
   消費者と業者の間の低額販売トランザクションに関連する費用データを集約する様に構成され、前記集約された費用データを前記業者に関連する承継銀行エンティティに送信する様に構成された第１トランザクション・プロセッサ、及び
   各個人の低額販売トランザクションを表すデータを記憶する様に構成され、前記記憶されたデータが、前記業者に関連する少なくとも１つの銀行エンティティによってアクセス可能である第２トランザクション・プロセッサを含むことを特徴とする、ペイメント処理システム。
2. 前記第２トランザクション・プロセッサが、前記消費者と前記業者から離れて配置される、請求項１に記載のペイメント処理システム。
3. 前記第１トランザクション・プロセッサが、前記業者と少なくとも２つの消費者の間の低額販売トランザクションに関連する費用データを集約する様に更に構成される、請求項１に記載のペイメント処理システム。
4. 前記第１トランザクション・プロセッサが、少なくとも２つの業者に関連する低額販売トランザクションに関連する費用データを集約する様に更に構成され、前記業者が同じ銀行エンティティに関連する、請求項１に記載のペイメント処理システム。
5. 前記消費者が前記業者に、前記低額販売トランザクションに対して、使用毎支払に基づいて支払う、請求項１に記載のペイメント処理システム。
6. 前記消費者が前記業者に、前記低額販売トランザクションに対して、プリペイドに基づいて支払う請求項１に記載のペイメント処理システム。
7. 前記消費者が前記業者に、前記低額販売トランザクションに対して、予約に基づいて支払う、請求項１に記載のペイメント処理システム。
8. 前記消費者が前記業者に、前記低額販売トランザクションに対して、ポストペイドに基づいて支払う請求項１に記載のペイメント処理システム。
9. 前記記憶されたデータが、各個人の低額販売トランザクションは、前記承継銀行エンティティによってアクセス可能であることを示す、請求項１に記載のペイメント処理システム。
10. 前記記憶されたデータが、各個人の低額販売トランザクションは、前記消費者に関連する発行銀行エンティティによってアクセス可能であることを示す、請求項１に記載のペイメント処理システム。
11. 前記記憶されたデータが、各個人の低額販売トランザクションは、前記消費者によってアクセス可能であることを示す、請求項１に記載のペイメント処理システム。
12. 顧客サービスを提供するために、前記第１トランザクション・プロセッサが、消費者要求を前記第２トランザクション・プロセッサに向ける様に更に構成される、請求項１に記載のペイメント処理システム。
13. 前記第１トランザクション・プロセッサが、前記消費者に関連する発行銀行エンティティに配置される、請求項１に記載のペイメント処理システム。
14. ペイメントの残高調整を、少なくとも１つの前記低額販売トランザクションで追跡する様に構成される第３トランザクション・プロセッサを更に含む、請求項１に記載のペイメント処理システム。
15. 前記第３トランザクション・プロセッサが、承継銀行エンティティに配置される、請求項１４に記載のペイメント処理システム。
16. 集約費用データを第三者のためのフォーマットに変換する様に構成される第４トランザクション・プロセッサを更に含む、請求項１に記載のペイメント処理システム。
17. 前記第４トランザクション・プロセッサが、前記第１トランザクション・プロセッサを含むサーバに配置される、請求項１６に記載のペイメント処理システム。
18. 各個人の低額販売トランザクションを表す前記記憶されたデータが、少なくとも１つの前記トランザクションに関連する口座番号の一方向ハッシュを含む、請求項１に記載のペイメント処理システム。
19. 前記記憶されたデータが暗号化される、請求項１に記載のペイメント処理システム。
20. 少なくとも１つの前記低額販売トランザクションが、キオスク装置で発生する、請求項１に記載のペイメント処理システム。
21. 第３トランザクション・プロセッサが、前記消費者と第２業者の間の低額販売トランザクションに関連する費用データを集約する様に構成される、請求項１に記載のペイメント処理システム。
22. 前記業者が前記消費者に優遇措置を提供して、前記業者との将来のトランザクションを促進する、請求項１に記載のペイメント処理システム。
23. ペイメントを処理する方法であって、
    第１消費者と第１業者の間の第１低額販売トランザクションを表すデータを受信し、
    第１低額販売トランザクションの費用、及び第２低額販売トランザクションの費用を、前記消費者と前記業者の間で集約し、
    前記業者に関連する少なくとも１つの銀行エンティティによって前記データがアクセス可能であるように、前記第１低額販売トランザクションに関連するデータを記憶し、及び
    集約費用を表すデータを、前記業者に関連する承継銀行エンティティに送信する諸ステップを含む方法。
24. 前記第１消費者に関連する低額販売トランザクションの費用、及び第２消費者に関連する低額販売トランザクションの費用を集約することを更に含む、請求項２３に記載の方法。
25. 前記第１業者に関連する低額トランザクションの費用、及び第２業者に関連する低額販売トランザクションの費用を集約し、前記第１業者と前記第２業者が前記承継銀行エンティティに関連する、請求項２３に記載の方法。
26. 前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記承継銀行エンティティによってアクセス可能である、請求項２３に記載の方法。
27. 前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者に関連する発行銀行エンティティによってアクセス可能である、請求項２３に記載の方法。
28. 前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者によってアクセス可能である、請求項２３に記載の方法。
29. 前記第１低額販売トランザクションに関連するデータを記憶することは、前記第１低額販売トランザクションに関連する口座番号に一方向ハッシュを適用することを含む、請求項２１に記載の方法。
30. 記憶された複数の命令を有するコンピュータ読み取り可能な媒体に常駐するコンピュータ・プログラム・プロダクトであって、プロセッサによって実行されるときに、プロセッサに以下のことをさせる、即ち、
    第１消費者と第１業者の間の第１低額販売トランザクションを表すデータを受信し、
    前記第１低額販売トランザクションの費用、及び第２低額販売トランザクションの費用を、前記消費者と前記業者の間で集約し、
    前記業者に関連する少なくとも１つの銀行エンティティによってアクセス可能な様に、前記第１低額販売トランザクションに関連するデータを記憶し、及び
    前記集約費用を表すデータを、前記業者に関連する承継銀行エンティティにに送信する諸ステップを含むコンピュータ・プログラム・プロダクト。
31. 前記第１消費者に関連する低額販売トランザクションの費用、及び第２消費者に関連する低額販売トランザクションの費用を集約することを更に含む、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
32. 前記第１業者に関連する低額トランザクションの費用、及び第２業者に関連する低額販売トランザクションの費用を集約し、前記第１と前記第２業者が前記承継銀行エンティティに関連することを更に含む請求項３０に記載の、コンピュータ・プログラム・プロダクト。
33. 前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記承継銀行エンティティによってアクセス可能である、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
34. 前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者に関連する発行銀行エンティティによってアクセス可能である、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
35. 前記第１低額販売トランザクションに関連する前記記憶されたデータが、前記消費者によってアクセス可能である、請求項３０に記載の、コンピュータ・プログラム・プロダクト。
36. 前記第１低額販売トランザクションに関連するデータを記憶することは、前記第１低額販売トランザクションに関連する口座番号に一方向ハッシュを適用することを含む、請求項３０に記載の、コンピュータ・プログラム・プロダクト。

Images