JP2010509699A5

JP2010509699A5 -

Info

Publication number: JP2010509699A5
Application number: JP2009537281A
Authority: JP
Filing date: 2007-11-08
Publication date: 2011-01-06
Anticipated expiration: 2027-11-08

Description

支払処理システム債務転換通知

〔関連出願への相互参照〕
本出願は、「取引処理自動化」という名称の２００６年１１月１４日に出願の米国特許出願第６０／８６５，８３６号、および「支払処理システム債務転換通知」という名称の２００７年１１月７日に出願の米国特許出願第１１／９３６，４７５号に対する優先権およびそれの利益を請求し、それぞれの全内容は本願明細書に引用したものとする。

実施態様は、一般に支払の処理、より詳細には買手の売手に対する支払を自動的に処理して、送られた買手の売手に対する支払と買手の売手に対する支払の会計書類を照合することに関する。

企業は、しばしば、さまざまな支払手段タイプによって、例えば、クレジット口座(credit account)、当座預金口座(checking account)、または自動決済機関(Automated Clearing House)（ＡＣＨ）銀行口座振替によって、他の企業との取引を処理する。例えば、買手は、買手が購入したい商品を開示している売手に対する注文書(purchase order)（ＰＯ）を有することができる。注文書は、契約上の義務または信用限度のような要因に応じて、それに関連したいくつかの支払タイプを有することができる。従って、買手は小切手を使用して特定の商品の代価を払う一方で、クレジットカードで他の商品の代価を払うことができる。同様に、複数の注文書は複数の支払タイプを有することがあり得る。

通常は、注文書または納品書(invoice)支払は人手で処理される。買手は支払勘定(accounts payable)ファイルを調べて、支払タイプに基づいて、例えば、売手に対して小切手を書くか、売手にクレジットカード払いを要求するか、または売手のための為替を準備できる。

支払のための支払タイプを人手で決定し、支払タイプを処理するさまざまなシステムのどれかを選び、そしてさまざまなシステムによる支払要求を普及させるプロセスは、追跡、照合、そして制御するのが煩雑になる場合がある。例えば、各注文書は別々に処理されて、複数の支払が或る時間帯に同じ買手になされるときに非効率を生じる場合がある。

いくつかの組織は、例えば単一の組織の支払勘定を格納することによって、組織内でデータを単一の統一システムに組み込む統合業務ソフト（ＥＲＰ）システムを通常は利用する。ＥＲＰシステムは買手の支払勘定または売手の受取勘定(accounts receivable)をまとめる際に役立つことができるが、ＥＲＰシステムはさまざまなシステムによる各支払いタイプを自動的に処理しないし、ＥＲＰは送られた支払を対応する納品書および／または注文書と自動的に照合することもしない。

さらに、いくつかの支払タイプは、買手または売手が社内で支払勘定または受取勘定を処理するときに、十分に活用されていない利点を有することがある。例えば、クレジット口座には、支払処理システムの中で、事業のオーナーに有益な可能性がある送金保証または条件つきインセンティブがある場合がある。支払処理システムが或る期間内に支払の送金を容易にするか、または売手の売上高を増加させる促進オプションを提供できるので、売手は支払処理システム内で口座になされる支払を好むことになる。買手が取引を行うときに口座を利用することによって、利益を受けることができるように、口座がロイヤルティプログラムの一部になるので、買手は口座になされる支払いを好むことになる。企業間取引において、ロイヤルティプログラムは、例えば、キャッシュバック、購入される商品のための保険金、またはマイレージサービスを受けるためのマイル数を含む場合がある。取引にたずさわる買手または売手が口座の取引を処理するためにその他の機能を知らなくてもよい、あるいは買手または売手がその他の選好を知ることができないので、これらの利点は十分に活用されないことになる。

買手から売手への支払義務の処理が自動化され得るシステムが必要である。これおよび他の問題は、個々に、そして集合的に、本願明細書において対処される。

買手と売手の間の支払の自動処理は、支払処理システムのために記載されているコンピュータで実行される方法で対処され、そこでは取引ハンドラは、支払処理システム内の口座の取引に係わる消費者および加盟店によって特徴づけられる取引を処理する。

１つのコンピュータ方法の実施態様では、消費者の売手に対する債務が受け取られ、売手識別子を含む。売手が支払処理システムの加盟店のうちの１つであるかどうかの決定が売手識別子を用いて行われる。売手が加盟店のうちの１つでない場合は、第１通知が消費者に宛てられて、売手に支払処理システムの加盟店の１つになるよう依頼するために消費者による協力を求める。売手が加盟店のうちの１つである場合は、第２通知が消費者に宛てられて、消費者と売手の間の清算取引を下位口座により支払い可能にするために、イシュアに、口座内で、売手に固有である下位口座を発行させるように消費者に求める。イシュアが加盟店のうちの１つである売手のための下位口座を発行したという確認が受け取られ、確認は下位口座の指標を含む。下位口座の指標を含む、消費者と売手（すなわち加盟店のうちの１つ）の間の清算取引は受け取られる。清算取引は下位口座の指標を用いて下位口座により支払い可能であると確認される。イシュアは下位口座により支払い可能である清算取引を通知される。

別の実施態様では、単一または数人の加盟店に対する消費者の少なくとも１つの債務が受け取られ、債務の各々は加盟店の各々の対応する加盟店識別子を含む。加盟店識別子の各々に対して、第１通知が消費者に宛てられて、清算取引を下位口座により支払い可能にするために、イシュアに、口座内で、対応する加盟店に固有である下位口座を発行させるように消費者に求める。下位口座の各々に対して、イシュアは下位口座を発行したとの確認が受け取られ、対応するそれぞれの加盟店に対する債務の各々が集計され、対応する加盟店に対する集計された債務と見合うように下位口座の信用限度が設定されて、第２通知が対応する加盟店に宛てられて、清算取引とともに下位口座の指標を含む伝送を形成するように対応する加盟店に求める。清算取引とともに下位口座の指標は受け取られ、清算取引は下位口座の指標を用いて下位口座により支払い可能であるとして確認され、そしてイシュアは清算取引が下位口座により支払い可能であると通知される。代わりに、または組み合わせて、下位口座の信用限度は債務の一部に見合うように設定されることがある。下位口座の信用限度の設定は、例えば、清算取引の決済、下位口座の信用限度のための実施可能期間の完了、下位口座の口座サイクル、または下位口座の残高のような要因に基づくことができる。

さらに別の実施態様では、加盟店に対する買手の債務は受け取られ、そこでは債務は買手の買手識別子を含む。買手識別子を用いて、買手が支払処理システムの消費者のうちの１人であるかどうかの決定が行われる。買手が消費者の１人でない場合は、第１通知が加盟店に宛てられて、買手に支払処理システムの消費者の１人になるよう依頼するために加盟店に対して許可を求める。買手が消費者の１人である場合は、第２通知が消費者の１人に宛てられて、消費者の１人と加盟店の間の清算取引を下位口座により支払い可能にするために、イシュアに、対応する口座内で、加盟店に固有である下位口座を発行させるように消費者の１人に求め、イシュアは下位口座の指標を含む下位口座を発行したという確認が受け取られ、下位口座の指標を含む消費者の１人と加盟店の間の清算取引が受け取られ、清算取引は下位口座の指標を用いて下位口座により支払い可能であるとして確認され、そしてイシュアは消費者の１人と加盟店の間の清算取引が下位口座により支払い可能であると通知される。

さらに別の実施態様では、数人の消費者によって加盟店に借りられている債務が受け取られ、そこでは各債務は消費者の各々の対応する消費者識別子を含む。第１通知が消費者の各々に宛てられて、清算取引を下位口座により支払い可能にするために、対応するイシュアに加盟店に固有である下位口座を発行させるように消費者の各々に求め、そこにおいて下位口座は口座と関連付けられる。下位口座の各々に対して、対応する消費者の加盟店に対する債務の各々が集計され、加盟店に対する対応する消費者の集計された債務に見合うように下位口座の信用限度が設定されて、通知が対応する加盟店に宛てられて、清算取引とともに下位口座の指標を含む伝送を形成するように加盟店に求め、清算取引とともに下位口座の指標は受け取られ、清算取引は下位口座の指標を用いて下位口座により支払い可能であるとして確認され、そしてイシュアは清算取引が下位口座により支払い可能であると通知される。さらに、例えば、清算取引の決済、下位口座の信用限度のための実施可能期間の完了、下位口座の口座サイクル、および下位口座の残高のような要因に基づいて、下位口座の信用限度は債務の残りの未払い残高に見合うように調整されることができる。

実施態様は、図面を参照して以下に述べる詳細な説明によってより明らかになり、そこでは同じ要素には同じ参照番号がついている。

売手に対する買手の債務（例えば、金銭的負担の指標）が処理され得る例示的な方法を示す流れ図である。売手に対する買手の債務が支払処理システムの口座を用いて処理され得る例示的な方法を示す流れ図である。買手の売手に対する債務が処理され得る例示的な方法を示す流れ図である。買手の売手に対する支払勘定が処理され得る例示的な方法のブロック図を示す。図１、２、３、および４に示す例示的な方法が実行され得る例示的な支払処理システムのブロック図を示す。買手の売手に対する債務を処理するための例示的なクライアント・サーバー環境を示すブロック・レベル図である。

一実施態様では、買手の売手に対する債務(debt)、例えば請求書(bill)または注文書などは自動的に処理される。債務を含んでいるファイルは解析されて、例えば小切手またはクレジットカードなどによって、債務を支払うことが可能になる支払タイプを決定する。支払タイプが支払処理システム（例えば、クレジット口座またはデビット口座）の口座以外である場合は、売手および買手の一方または両方は口座に支払える処理を行うように要請される。支払タイプが口座にある場合は、下位口座は売手および買手のために作成される。そして買手と売手の間の取引は、売手に対する買手の複数の債務を集計し、集計された債務の額の取引を下位口座により支払い可能に処理するか、債務を下位口座により支払い可能にするか、または債務の一部を下位口座により支払い可能にするというオプションを含めて、下位口座を用いて処理される。下位口座の信用限度は、集計された債務、債務、または債務の一部の額に見合うように設定することができる。代わりに、または組み合わせて、清算取引(future transaction)の決済(clearing)、下位口座の信用限度のための実施可能期間の完了、下位口座の口座サイクル、および下位口座の残高のような要因に基づいて、下位口座の信用限度は債務の残りの未払い残高に見合うように調整されることができる。

本願明細書において用いるように、買手は商品、サービス、または両方とも売手から賃貸するか、ライセンス供与されるか、または購入する人または主体である。売手は商品、サービス、または両方とも買手に賃貸するか、ライセンス供与するか、または販売する人または主体となる。買手または売手の各々は、企業間取引に係わる企業体または個人間取引に係わる個人となる。さらに、個人と企業間の取引または企業と個人間の取引も本願明細書において開示される。消費者は支払処理システムに口座を有する買手であり、そして加盟店は支払処理システムの口座により支払を受け取る売手である。支払処理システムは、取引ハンドラが支払処理システムの口座の取引のうちの１つに係わる消費者および加盟店によって、各々特徴づけられる多数の取引を処理するシステムである。支払処理システムにおいて、イシュアは計算書を消費者に発行し、そして加盟店は、イシュアに取引のための消費者から資金を支払うよう求める取引ハンドラによって、処理するために取引のうちの１つをアクワイアラ(acquirer)に提出する。イシュアは、取引のための加盟店への資金を支払うためにアクワイアラに資金を送る取引ハンドラに資金を送る。支払処理システムのより詳細な説明について、支払い処理システムを以下に参照する。

図１および２を参照すると、２つの流れ図は売手に対する買手の少なくとも１つの債務が処理され得る例示的な方法を示している。

一実施態様では、買手の債務は消費者のうちの１人である買手のために処理される。プロセス１００のステップ１０２で、消費者が通常取引する複数の売手に関する情報を含む買手プロフィールは消費者から任意に受け取ることができる。情報は、売手ごとに、例えば、名前、住所、預金口座番号、売手識別子（例えば、売手コード）、売手の説明、売手に対する過去の支払総計、支払が売手に通常なされる日付を示している支払サイクル、売手と関連したアクワイアラの名前、売手が受け入れる支払形式、または売手のカテゴリーを含むことができる。

ステップ１０４で、売手のうちの少なくとも１人に対する消費者の債務は受け取られる。債務は、例えば、請求書、支払勘定文書、消費者のＥＲＰによって発生する電子支払勘定ファイル、注文書、または納品書でもよい。債務は、単一の売手の単一の請求書、単一の売手の複数の請求書、または複数の売手の複数の請求書に関するデータを含んでもよい。債務は、売手の各々に対して、債務が売手に起因するときの売手に対する未払金(amount owed)、売手識別子、買手識別子、または債務の各々が支払い可能になる支払タイプを含むことができる。

ステップ１０６で、売手の各々が加盟店のうちの１つであるかどうかの決定が行われる。債務が複数の未払金（例えば、複数の請求書）のためである場合は、決定は未払金の各々に対して行われる。

売手の各々に対して、対応する売手識別子は売手が加盟店のうちの１つであるかどうか決定するために用いることができる。債務において受け取られる売手識別子は、売手が支払処理システムの加盟店のうちの１つであるかどうかを示す情報を有する加盟店識別子にリンクするサーバ・データベースに格納されている売手のための加盟店識別子と照合されることができる。例示のために、債務が売手識別子として「ＣＣＸＷＹＸ」を含み、そしてサーバ・データベースの売手の加盟店識別子が「ＣＣＸＷＹＸ」である場合は、合致があり、売手は加盟店のうちの１つである。マッチング方式の他の形は公知技術である。

売手が加盟店の１つであるかどうかを決定する別の手段は債務のデータを利用することである。前述のように、債務は売手によって受け入れられる支払タイプを含むことができる。例えば、債務は売手がクレジットカード払いを受け入れることを示すことができる。従って、売手が口座で支払いを受け取るので、売手は加盟店の１つである。債務の支払タイプは、売手が加盟店の１つであるかどうかを示す情報を有する加盟店識別子にリンクするサーバ・データベースのデータによって確認するか、または知ることができる。例えば、債務の支払タイプと、売手識別子と加盟店識別子の照合との間に不一致がある場合は、売手が加盟店の１つであるかどうかの決定は債務に示される支払タイプ以外の照合に基づくことがある。

売手が加盟店である場合に、プロセス１００は図２に示すプロセス２００のステップ２０１へジャンプする。その他の場合は、売手は加盟店の１つではなく、ステップ１０８で、通知が消費者に宛てられて、売手に加盟店の１つになるよう依頼するために消費者に対して協力を求める。通知は、売手の名前、売手が口座での支払を現在受け入れないことを示す説明、売手が加盟店の１つになることの要請を消費者が承認するという要求、または加盟店の１つになることを売手に要請する方法に関する情報の要求を含むことができる。消費者の協力は売手に要請することに同意することでもよい。例えば、消費者は、加盟店の１つになることの利点を示す売手に送られる匿名のレターに同意することができ、あるいは、レターは匿名でなくてもよく、消費者には口座があって、売手に対する債務が口座を用いて払われるのを好むことを示すことができる。要請の他の形は当業者に周知である。

売手は、売手が加盟店の１つになりたいことを示すことができる。例えば、売手は要請を受け入れ、売手が口座での支払いを受け入れ始めることができると決定することができる。売手は、例えば、口座により支払い可能にされる資金を受け入れ始めるために、取引ハンドラまたはアクワイアラと法的拘束力のある契約を締結することができる。

売手が加盟店の１つになったという通知が受け取られることができる。例えば、取引ハンドラは、売手が加盟店の１つになった、そしてウェルズ・ファーゴ（ＷｅｌｌｓＦａｒｇｏ）（登録商標）銀行が売手と関連したアクワイアラになったという通知を受け取ることができる。売手は、売手が受け入れる支払タイプの変更を反映するために売手のＥＲＰを更新することができるか、または取引を含む磁気ストライプ・フォーマット化された取引情報を含む伝送を形成できるソフトウェアを得ることのような、口座による支払いを処理することが可能な装備を得ることができる。ソフトウェアを用いて、売手は、取引通貨額、売手の名前、消費者の名前、取引の日付、伝送の日付、取引と関連した注文書の数、取引と関連した納品書の数、供される商品またはサービスの明細、または供される商品またはサービスの数量を含む取引情報を取引ハンドラへ転送するために、アクワイアラへ伝送できる。例えば、売手は口座による債務の支払いを要求する伝送を形成して、未払金および注文書の数を示すことができる。

売手が加盟店の１つでない場合は、債務は口座を使用せずに処理できる。例えば、伝送が形成されて、消費者の売手に対する債務に見合う値を有する、消費者から売手への小切手を提出すること、消費者の売手に対する債務に見合う値を有する、消費者から売手への為替を提出すること、または消費者の売手に対する債務に見合う値を有する、消費者から売手へのＡＣＨ銀行口座振替を提出することを銀行のような金融機関に要求できる。他の支払形式は当業者に周知である（例えば、トラベラーズ・チェック、直接銀行間振替、現金、または通貨価値を有するポイントのポイント振替）。例えば、金融メッセージが金融機関の協同組合内の金融メッセージング・サービスの会員（例えば、銀行、ブローカー・ディーラ、または投資顧問会社）の間で送られて、消費者の売手に対する債務に見合う値を有する、消費者から売手への振替を要求することができる。この種の協同組合の例は国際銀行間通信協会（ＳＷＩＦＴ）（登録商標）協同組合である。

金額を債務と見合うようにすることは複数の方法で行うことができる。例えば、金額は対応する売手に対する債務における未払金の各々に等しくするか、金額は対応する売手に対する債務における未払金の少なくとも１つの各々の一部に等しくするか、金額は対応する売手に対する債務における未払金の総計に等しくするか、金額は複数の債務における対応する売手に対する複数の未払金の総計に等しくするか、金額は以前の債務の受領の後に受け取られた更新された債務に等しくするか、あるいは金額は債務における未払金プラス他の手数料、例えば、未払金で購入した商品の税金または送料および手数料などに等しくすることができる。

売手が加盟店の１つである場合は、売手および消費者に固有の、口座内の下位口座を開設することができる。売手の各々に対して、売手の各々に対する債務における未払金は集計され（例えば、時間のウインドウを通じて）、その後に対応する売手に対する集計された債務の清算取引を処理できる。さらに、監査が行われて、売手に対する清算取引および債務の送金された支払いの記録を照合できる。

図２のステップ２０２で、通知が消費者に宛てられて、消費者、および加盟店の１つである売手に固有である口座の下位口座を開設する。消費者、および加盟店の１つである売手の両方が清算取引に係わるときに清算取引が下位口座により支払い可能になるように、下位口座を開設するための通知は口座と関連した下位口座を発行するために消費者が消費者のイシュアと連絡をとるように要求を示すことができる。例えば、下位口座が第１売手に対する消費者に発行される場合は、清算取引が消費者と第２売手の間にあるならば、清算取引は下位口座による支払い可能にすることはできない。

ステップ２０４で、消費者に固有であり、そして加盟店の１つである売手に固有である下位口座がイシュアによって消費者に発行されたことを示す確認が受け取られる。確認は、消費者の名前、下位口座を発行したイシュアの名前、下位口座の指標（例えば、下位口座番号）、加盟店の１つである売手の名前、または下位口座の信用限度を含むことができる。

ステップ２０６で、債務に（または複数の債務に）複数の未払金がある場合は、加盟店の１つである売手に対する未払金は集計される。例えば、債務は、ボーイング社である第１売手の１０通の請求書およびジェネラル・ミルス社である第２売手に対する８通の注文書を含むとする。ボーイング社の１０通の請求書の各々の未払金は集計されて、ボーイング社に対する未払金の総計に等しくすることができる。さらに、ゼネラル・ミルズ社に対する注文書の各々の未払金は集計されて、ゼネラル・ミルズ社に対する未払金の総計に等しくすることができる。

下位口座の信用限度は、債務、債務の一部、または加盟店の１つである売手に対する集計された未払金に見合うように設定され得る。例えば、アメリカン航空会社である消費者から受け取られる複数の債務は、１ヵ月の間にボーイング社から受け取られる請求書を含むとする。その月の未払金の総計の総計は５３０，０００ドル（米国）に等しいとする。ボーイング社に対するアメリカン航空会社の下位口座の信用限度は、前月のボーイング社に対する下位口座の信用限度であった５００，０００ドル（米国）から５５０，０００ドル（米国）へ増加されて、５３０，０００ドル（米国）の集計された未払金に見合うことができる。集計された未払金に見合うために、信用限度は集計された未払金に等しいことが必要ではない。例えば、信用限度は、集計された未払金に反映されない口座になされることがある処理料金または他の手数料を考慮に入れて集計された未払金を超える割合であることができる。代わりに、または組み合わせて、信用限度は口座サイクルの間にゼロまたは他の値にリセットされてもよい。例えば、ボーイング社に対するアメリカン航空会社の信用限度は前月に５００，０００ドル（米国）に設定され、前月末にゼロにリセットされ、そして前月の後の月に二度目に５５０，０００ドル（米国）に設定されることがあり得る。

ステップ２０８で、通知が加盟店の１つである売手に任意に宛てられて、下位口座による支払いを要求する清算取引を提出し、そこでは清算取引は消費者および清算取引に係わっている加盟店の１つである売手によって特徴づけられる。清算取引は未払金または集計された未払金のためであってもよい。前の実施例を用いて例示するために、通知はボーイング社に宛てられて、ボーイング社が５３０，０００ドル（米国）またはアメリカン航空会社とボーイング社間のその他の清算取引に対して下位口座に請求できることを示すことになる。通知は、下位口座の指標、下位口座の指標の満期日、未払金、集計された未払金、清算取引が伝送されなければならない日付、未払金と関連した注文書の数、または未払金と関連した請求書の数を含むことができる。

ステップ２１０で、清算取引、例えば、未払金または集計された未払金に見合う資金の清算取引が任意に受け取られる。例えば、取引ハンドラは加盟店の１つである売手と関連したアクワイアラから清算取引を受け取ることができて、取引ハンドラはイシュアに消費者からの未払金に見合う資金を支払うよう求めることができる。清算取引の伝送は、要求される資金の数量、下位口座の指標、売手に対する債務（または債務における未払金）と関連した注文書識別子（例えば、注文書の数）、または売手に対する債務（または債務における未払金）と関連した請求書識別子（例えば、請求書の数）を含むことができる。清算取引は磁気ストライプ・フォーマットであってもよい。

ステップ２１２で、確認が清算取引が下位口座によって支払い可能であるかどうかに関して任意に行われる。清算取引において受け取られる下位口座の指標は、サーバ・データベースに格納された複数の下位口座の複数の指標と比較されて、清算取引に係わる消費者および売手が下位口座に固有の消費者および売手に合致するかどうか決定できる。従って、イシュアが下位口座をアップルコンピュータ株式会社（またはその系列会社）である売手のためにスターバックス・コーヒー会社（またはその系列会社）である消費者に発行する場合は、受け取った清算取引のデータが清算取引に係わる消費者および売手がそれぞれスターバックス・コーヒー会社（またはその系列会社）およびアップルコンピュータ株式会社（またはその系列会社）であることを示しているならば、清算取引は下位口座により支払い可能であるとして確認される。マッチング・アルゴリズムは、清算取引とサーバ・データベースのデータの間の合致を決定するために用いることができる。例えば、サーバ・データベースは会社およびその系列会社に関する情報を有することができる。例えば、下位口座がスターバックス・コーヒー会社に固有であり、そして清算取引がスターバックス・コーヒー会社の系列会社であるスターバックス・コーヒー・トレーディング会社とアップルコンピュータ株式会社の間にある場合は、マッチング・アルゴリズムは合致を返し、清算取引は下位口座によって、支払い可能であると確認される。

ステップ２１４で、イシュアは清算取引が下位口座によって支払い可能であると通知される。イシュアは、未払金、集計された未払金、売手の名前、消費者の名前、清算取引の日付、または清算取引のために消費者から資金を支払うことの要求を含む伝送により通知されることができる、そこではイシュアは、加盟店の１つである売手に資金を支払うために、アクワイアラに清算取引の資金を送る取引ハンドラに資金を送ることができる。

例えば、清算取引を提出するために通知を売手に宛てるステップ、清算取引を伝送で受信するステップ、または清算取引が下位口座によって支払い可能であることを確認するステップ無しで、イシュアは、清算取引が下位口座によって支払い可能であると通知され得る。消費者および売手は、債務が、債務における未払金を下位口座によって支払い可能とする売手の意図の充分な示唆であることに合意することができる。イシュアは所定の期間または所定の金額での清算取引を通知されることができる。例えば、消費者および売手は、売手に対する集計された未払金が各月の初めに、または債務における集計された未払金が５００ドル（米国）以上であるときはいつでも、イシュアに清算取引を通知することにより処理されなければならないことに合意することができる。代わりに、または組み合わせて、消費者および売手は、イシュアが債務が受け取られる時に債務における未払金に等しい資金の清算取引を通知されるように、売手に対する各債務は受け取られるときに処理されなければならないことに合意することができる。例えば、取引ハンドラは消費者のＥＲＰからの支払勘定ファイルである債務を断続的に受信できる。消費者および支払勘定ファイルに含まれる請求書を有する売手は、すべての請求書が取引ハンドラによって消費者のＥＲＰから支払勘定ファイルを受けると支払われることを前もって決めることができた。従って、この例では、請求書を含んでいる支払勘定ファイルを受け取ると、取引ハンドラはイシュアへの伝送を形成して、売手の請求書における未払金に等しい資金を支払うことをイシュアに通知できる。

図２のステップ２１６で、債務の任意の監査が行われ得る。例えば、売手が加盟店の１つである場合に、監査は債務において未払金を有する口座を経て支出された資金を照合することにより行うことができる。照合は債務を有する清算取引の伝送において受け取られるマッチング・データを含むことができる。マッチングは、債務（または債務のうちの未払金）と関連した注文書の第２識別子とともに清算取引の伝送に含まれる注文書の第１識別子と、債務と関連した請求書の第２識別子とともに清算取引の伝送に含まれる請求書の第１識別子と、または債務とともに支出された資金の値との間の一致、例えば等価などを決定する段階を含むことができる。代わりに、または組み合わせて、債務の監査は、資金流通の決済（clearing）または清算(settling)プロセスの間にイシュアから受け取られるか、またはアクワイアラから受け取られるデータを照合することにより行うことができる。例えば、イシュアが取引ハンドラに資金を送るときに、送られた資金は、売手に対する消費者の債務における未払金と関連した注文書の指標と照合される注文書の指標を含むこともできる。

同様に、売手が加盟店の１つでない場合は、監査は、売手に提出される通貨額を消費者の債務の対応する売手に対する未払金と照合することにより行うことができる。例えば、消費者から売手への小切手の通貨額は、対応する売手に対する消費者の債務における未払金と照合されることがあり、消費者から売手への為替の通貨額は、対応する売手に対する消費者の債務における未払金と照合されることがあり、または消費者から売手へのＡＣＨ銀行口座振替の通貨額は、対応する売手に対する消費者の債務における未払金と照合されることがある。

監査の結果は、消費者、イシュア、アクワイアラ、または売手に送信することができる。例えば、消費者は、対応する売手に各下位口座を経て支出される資金が消費者の債務において対応するそれぞれの売手に対する未払金に合致したように、消費者の債務の各々における未払金の全てが清算取引の受け取った伝送と照合されたことを示している報告を受け取ることができる。従って、監査の報告の情報は、未払金、金額、第１注文書識別子、第２注文書識別子、第１請求書識別子、第２請求書識別子、第１注文書識別子が第２注文書識別子に等価であったかどうか、第１請求書識別子が第２請求書識別子に等価であったかどうか、または金額が未払金に等価であったかどうかを含むことができる。

別の実施態様では、加盟店の各自である複数の売手に対する消費者の１人である買手の複数の債務が処理される。対応するそれぞれの加盟店識別子を含む複数の債務が受け取られる（ステップ１０４）。加盟店識別子の各々に対して、第１通知が消費者に宛てられて、清算取引を下位口座によって支払い可能にするために、イシュアに対応する加盟店に固有である下位口座を発行してもらうように消費者に要求し、そこでは下位口座は支払処理システムの口座と関連している（ステップ２０２）。

下位口座ごとに、イシュアが下位口座を発行したことを示す確認が受け取られる（ステップ２０４）。対応するそれぞれの加盟店に対する債務は集計され、そして下位口座の信用限度は集計された債務に見合うように設定される（ステップ２０６）。第２通知が対応する加盟店に送られて、清算取引と併せて下位口座の指標を含む伝送を形成するように対応する加盟店に求める（ステップ２０８）。下位口座の指標および清算取引を含む伝送が受け取られる（ステップ２１０）。清算取引は下位口座により支払い可能であるとして確認され（ステップ２１２）、イシュアは、清算取引が下位口座により支払い可能であり（ステップ２１４）、そして監査が行われる（ステップ２１６）ことを通知される。

下位口座の信用限度は、債務の処理の間のいかなる時点でも、例えば図１および２に図示したように設定され得る。一実施態様では、下位口座の信用限度は、例えば清算取引がアクワイアラから受け取られる場合に清算取引で要求される資金の額に、または要求される資金の額と異なることがある、決済され、清算された清算取引の資金の第２額に見合うように設定され得る。代わりに、または組み合わせて、信用限度は下位口座の活性化期間で、または口座サイクルの別の時点で設定され得る。

例えば、取引の清算、信用限度の使用可能期間（例えば、信用限度を消費者が利用できる所定の期間）の完了、下位口座の口座サイクル内の時点または期間、あるいは下位口座の残高のような要因に基づいて、下位口座の信用限度は、清算取引が債務の一部について処理された後に未済である得る債務の残りの未払金に見合うように設定され得る。例えば、清算取引が処理され、清算された指標を受け取った後に、下位口座の信用限度は、債務の第２部分（例えば、消費者が１つの取引において、対応するそれぞれの加盟店に対する債務の全額を払わない場合に、対応するそれぞれの加盟店に対する残りの未払金）に見合う値に設定され得る。別の例では、清算取引が処理されて清算された後に、売手に対する消費者の債務のもう一方が受け取られる場合に、下位口座の信用限度は別の信用限度調整（例えば、信用限度の設定）に備えてゼロに設定され得る。

別の実施態様では、売手に対する少なくとも１人の買手の債務は加盟店の１つである売手のために処理される。図２および３を参照すると、債務は加盟店から受け取られ、買手が消費者の１人であるかどうかの決定が行われ、買手が消費者の１人でない場合は、買手は消費者の１人になることを求められ、買手が消費者の１人である場合は、通知が買手に宛てられて、買手および加盟店に固有の下位口座を開設する。加盟店に対する未払金は各買手ごとに集計されて、それに応じて処理することができる。

図３のステップ３０２で、加盟店は、加盟店が通常取引する複数の買手に関する情報を含む売手プロフィールを作成することができる。情報は、買手ごとに、買手の名前、買手の住所、買手の口座番号、買手識別子（例えば、買手コード）、買手の説明、加盟店に対する過去の未払金、支払が買手によって、通常なされる日付を示す支払サイクル、買手が支払い可能な支払いをする支払形式、買手と関連したイシュアの名前、または買手のカテゴリーを含むことができる。

ステップ３０４で、買手のうちの少なくとも１人の加盟店に対する債務が受け取られる。債務は、例えば、請求書、受取勘定文書、加盟店のＥＲＰによって発生する電子受取勘定ファイル、注文書、または納品書でもよい。債務は、単一の買手に対する単一の請求書、単一の買手に対する複数の請求書、または複数の買手に対する複数の請求書に関するデータを含むことがあり得る。債務は、買手ごとに、債務が加盟店に起因する場合の加盟店に対する未払金、加盟店識別子、買手識別子、または債務が支払可能である支払タイプを含むことがあり得る。

ステップ３０６で、買手の各々が消費者の１人であるかどうかの決定が行われる。債務が複数の未払金（例えば、複数の請求書）に対してである場合は、決定は未払金の各々に対して行われ得る。

買手の各々に対して、対応する買手識別子は買手が消費者の１人であるかどうか決定するために用いることができる。債務において受け取られる買手識別子は、買手が支払処理システムの消費者の１人であるかどうかを示す情報に消費者識別子をリンクするサーバ・データベースに格納される買手のための消費者識別子に照合されることができる。

買手が消費者の１人であるかどうか決定する別の手段は債務の中のデータを利用することである。債務は買手により利用される支払タイプを含むことができる。例えば、債務は買手がクレジットカード口座を有することを示すことができる。前の実施態様のように、債務は、買手が消費者の１人であるかどうかを示す情報に消費者識別子をリンクするサーバ・データベースのデータにより確認されるか、または知らされることができる。

買手がすでに支払処理システムの消費者である場合に、プロセス３００は終了し、図２に示すプロセス２００のステップ２０１へ移動する。さもなければ、ステップ３０８で、買手は消費者の１人でなく、そして通知が加盟店に宛てられて、買手に消費者の１人になるよう依頼するために加盟店に対して協力を求める。通知は、買手の名前、イシュアが、現在まで、口座を買手に発行しなかったことを示す説明、買手が消費者の１人になることの要請を加盟店が承認するという要求、または消費者の１人になるように買手に求める方法に関する情報の要求を含むことができる。加盟店の協力は買手に要請することに同意することでもよく、例えば、匿名のレターまたは買手へのレターは、加盟店が口座を経て支出される資金を受け取って、加盟店に対する債務が口座を使用して払われるのを好むことを示すことができる。

買手は、買手が消費者の１人になりたいことを示すことができる。例えば、買手は要請を受け取り、イシュアに口座を買手に発行してもらいたいと決定できる。買手は取引ハンドラまたはイシュアと法的拘束力のある契約を締結して、例えば、口座を使用して資金を支払い始めることができる。

買手が消費者の１人になったという通知を受け取ることができる。買手は、買手が加盟店に対する未払金を支払うために使用する支払タイプの変更を反映するために買手のＥＲＰを更新し、または口座による支払を処理することが可能な装置またはソフトウェアを得ることができる。

前述のように、債務は口座を使用せずに処理できる。例えば、債務の未払金に見合う金額を有する小切手を買手から加盟店へ提出すること、債務の未払金に見合う金額を有する為替を買手から加盟店へ提出すること、債務に見合う金額を有するＡＣＨ銀行口座振替を買手から加盟店へ提出すること、または売手に対する消費者の債務に見合う金額を有する、消費者から売手への通貨送金を要請している金融機関の協同組合内の金融メッセージング・サービスを提出することという要求が、銀行のような金融機関に対して行われることがある。買手および加盟店は口座を使用せずに処理される債務を有することに同意することができた。例えば、買手は、取引ハンドラが買手から加盟店への小切手の提出を要求するために、取引ハンドラに買手の当座預金口座番号を与えることができた。

買手が消費者の１人である場合は、買手および加盟店に固有の、口座内の下位口座を開設することができる。加盟店に対する債務における未払金は消費者の１人である買手ごとに集計することが可能であり、債務における集計された未払金の清算取引は処理できる。さらに、監査は加盟店に対する清算取引および債務の送られた支払の記録を照合して行うことができる。

図２のステップ２０２で、通知が消費者の１人である買手に宛てられて、買手および加盟店に固有である、口座内の下位口座を開設する。加盟店および買手すなわち消費者の１人が清算取引に係わる場合に、清算取引が下位口座によって支払い可能にできるように、下位口座を開設する通知は、買手に、口座に関連して下位口座を発行するために買手のイシュアと連絡をとることの要求を示すことができる。

ステップ２０４で、下位口座が発行されたとの確認が受け取られる。確認は、例えば、買手の名前、下位口座を発行したイシュアの名前、下位口座の指標、加盟店の名前、または下位口座の信用限度を含むことができる。

ステップ２０６で、債務に複数の債務または複数の未払金がある場合は、加盟店に対する未払金は消費者の１人である各買手に対して集計される。前述のように、下位口座の信用限度は、売手に対する買手の債務、売手に対する買手の債務の一部、売手に対する買手の債務の中の未払金、売手に対する買手の債務の中の未払金の一部、または消費者の１人である買手による加盟店に対する集計された未払金に見合うように設定できる。

ステップ２０８で、通知が加盟店に任意に宛てられて、下位口座による支払を要求する清算取引を提出し、そこでは清算取引は消費者の１人である買手および清算取引に係わる加盟店によって特徴づけられる。清算取引は、例えば、未払金、未払金の一部、または集計された未払金のためである場合がある。通知は、下位口座の指標、下位口座の指標の満期日、未払金、集計された未払金、清算取引を伝えることができる日付、未払金と関連した注文書の番号、または未払金と関連した請求書の番号を含むことができる。

ステップ２１０で、未払金または集計された未払金に見合う資金の清算取引が任意に受け取られる。例えば、取引ハンドラは加盟店と関連したアクワイアラから清算取引を受け取ることが可能であり、取引ハンドラはイシュアに消費者の１人である買手の未払金に見合う資金を支払うよう求めることができる。清算取引の伝送は、未払金の額、下位口座の指標、未払金と関連した注文書の番号、または未払金と関連した請求書の番号を含むことができる。前述のように、ステップ２１２で、清算取引が下位口座により支払可能であるかどうかの確認が行われ、ステップ２１４で、イシュアは下位口座により支払可能である清算取引を通知される。さらに、前の実施態様のように、イシュアは、清算取引を提出するために通知を加盟店に宛てるステップ、伝送の清算取引を受け取るステップ、または清算取引が下位口座により支払可能であることを確認するステップ無しに、清算取引を通知され得る。

図２を参照すると、ステップ２１６で、加盟店に対する各売手の債務が監査されて、加盟店が買手の各々による加盟店に対する債務における未払金の各々に対応する支払いを受け取ったかどうかを決定できる。

別の実施態様では、消費者の各自である複数の買手による加盟店の１つである売手に対する複数の債務が処理される。対応するそれぞれの消費者識別子を含む複数の債務が受け取られる（ステップ１０４）。消費者識別子の各々に対して、第１通知が対応する消費者に宛てられて、清算取引を下位口座により支払可能にするために、対応するイシュアに対応する消費者に固有である下位口座を発行させることを対応する消費者に要求し、そこでは下位口座は支払処理システムの中の口座と関連している（ステップ２０２）。

下位口座ごとに、対応するそれぞれの消費者の債務は集計されて、下位口座の信用限度は集計された債務に見合うように設定される（ステップ２０６）。第２通知が加盟店に送られて、対応する消費者を有する清算取引と併せて下位口座の指標を含む伝送を形成するように加盟店に求める（ステップ２０８）。下位口座の指標および清算取引を含む伝送が受け取られる（ステップ２１０）。清算取引は下位口座により支払可能であるとして確認され（ステップ２１２）、そしてイシュアは清算取引が下位口座により支払可能であると通知される（ステップ２１４）。

下位口座は対応する売手から分離されて、清算取引が処理され、清算された後に別の売手に関連付けられることが可能である。例えば、清算取引が下位口座により支払可能であるとイシュアに通知した後に、そして清算取引に関係する売手が資金を支払われるように、清算取引が完了した後に、下位口座は支払われた売手から分離されて、消費者と下位口座により支払可能である売手の間の第２清算取引を行うために別の売手に関連付けられることが可能である。例えば、シアーズ・ホールディングス社（「シアーズ」）は、それが、「１２３４５」のような口座番号を有すると、ブラック＆デッカー社への支払いを決済できる下位口座を有することができる。ブラック＆デッカー社に対する未払金の資金を送金することに続いて、シアーズは、口座番号「１２３４５」を有する下位口座をブラック＆デッカー社から分離し、次に下位口座をゼネラルエレクトリック社である別の売手と関連付けることをシアーズの下位口座のイシュアに要求できる。

図４を参照すると、さらに別の実施態様では、買手の支払勘定は方法４００で処理され、照合される。ステップ４０２で、複数の売手の支払勘定およびそれらの対応するそれぞれの注文書番号を有する買手の支払勘定ファイルが受け取られる。方法４００の残部は支払勘定ファイル内の売手ごとに実行される。問合せ４０４で、売手が支払処理システム内の口座による支払いを受け入れるかどうかの決定が行われる。例えば、サーバ・データベースは、支払勘定ファイル内の売手が加盟店の１つであるかどうか決定するためにアクセスされる。前述のように、売手識別子および加盟店識別子が合致する場合は、売手は口座による支払いが可能にされた支払いを受け入れる。問合せ４０４の決定が否である場合は、売手は口座による支払いが可能にされた支払いを受け入れず、そして支払勘定はステップ４０６で口座以外の手段により処理される。さらに、ステップ４０８で、買手は、売手が買手および売手に固有である口座と関連した仮想口座、例えば下位口座による支払いが可能にされた支払いを受け入れていないことを通知される。ステップ４１０で、仮想口座による支払いが可能にされた支払いを受け入れることを売手に求める買手からの承認が受け取られる。ステップ４１２で、売手は、買手と売手の間の清算取引のための仮想口座による支払いが可能にされた支払いを受け入れるように要請される。ステップ４１４で、サーバ・データベースは、売手が仮想口座による支払いが可能にされた支払いを受け入れるという変更を反映するために更新される。

問合せ４０４の決定がイエスである場合は、売手は口座による支払いが可能にされた支払いを受け入れ、そして第２問合せ、問合せ４１６が提起される。問合せ４１６で、支払タイプの支払勘定ファイル表示が決定される。支払勘定ファイル内の支払タイプが、売手が口座による支払いが可能にされた支払いを受け入れることを示さない場合は、ステップ４０６は支払勘定が口座を利用すること以外の手段により処理されることを示す。さらに、問合せ４１８で、売手が仮想口座による支払いが可能にされた支払いを受け入れるかどうかの決定が行われる。問合せ４１８が売手が仮想口座による支払いが可能にされた支払いを受け入れないことを示す場合は、買手はステップ４０８において、売手が仮想口座による支払いを受け入れないと通知され、（ステップ４１０）承認が売手に要請するために受け取られ、（ステップ４１２）売手は仮想口座による支払いが可能にされた支払いを受け入れることを要請され、そして（ステップ４１４）サーバ・データベースは売り手が口座による支払いが可能にされた支払いをすぐに受け入れることを反映するために更新される。

問合せ４１８の結果が、売手が仮想口座による支払いが可能にされた支払いを受け入れるということである場合は、ステップ４２０で、買手は、売手が仮想口座による支払いが可能にされた支払いを受け入れることを反映するために、支払勘定ファイル内の支払タイプを変更することを通知される。この実施態様では、サーバ・データベースに格納される支払タイプは支払勘定ファイルに含まれる支払タイプに勝つ。ステップ４１４で、サーバ・データベースは、売手が口座による支払いを受け入れることを反映するために更新される。

問合せ４１６の結果が、売手が口座による支払いが可能にされた支払いを受け入れるということである場合は、問合せ４２２が行われる。問合せ４２２において、売手が仮想口座によりなされる支払いを受け入れるかどうかの決定が行われる。問合せ４２２の結果が否である場合は、売手は仮想口座による支払いを受け入れず、そしてステップ４２４で、買手は、売手が口座による支払いが可能にされた支払いを受入れるが、仮想口座による支払いを受け入れなかったと通知される。ステップ４２６で、買手および売手に固有である仮想口座を作成するための承認が買手から受け取られる。ステップ４２８で、買手および売手に固有である仮想口座が作成される。さらに、サーバ・データベースの情報は、売手が仮想口座による支払いが可能にされた支払いを受け入れるという変更を反映するために更新される。

売手に対する買手の支払勘定は集計することができる。問合せ４２２が、売手が仮想口座による支払いが可能にされた支払いを受け入れることを示す場合は、ステップ４３０で、売手または買手の支払勘定は集計される。ステップ４３２で、仮想口座の信用限度は、売手に対する買手の集計された支払勘定に見合うように調整または設定される。問合せ４３４で、支払勘定の自動決済および自動清算が事前設定されたかどうかの決定が行われる。決済および清算が自動的に行われる場合は、ステップ４４０で、売手に対する買手の集計された支払勘定の額の清算取引は決済され、清算される。しかしながら、問合せ４３４が自動的な決済および清算が事前設定されなかったことを示す場合は、ステップ４３６で、売手は、集計された支払勘定の額の清算取引を含み、集計された額の決済および清算を要求し、そして注文書の関連指標を含む伝送を形成することを通知される。ステップ４３８で、注文書の関連指標を含む、集計された支払勘定の額の清算取引の伝送が売手から受け取られる。ステップ４４０で、集計された支払勘定の額の清算取引は決済されて清算される。

ステップ４４２で、受け取られた支払勘定ファイルおよび集計された支払勘定の清算取引は、前述の手段により監査される。ステップ４４４で、監査に関する報告は買手、売手、あるいは両方ともに送られる。

別の実施態様では、単一または数人の加盟店に対する消費者の単一またはいくつかの債務が受け取られ、そこでは債務の各々は加盟店の各々の対応する加盟店識別子を含む。加盟店識別子の各々に対して、第１通知が消費者に宛てられて、清算取引を下位口座により支払い可能にするために、イシュアに、口座内に、対応する加盟店に固有である下位口座を発行させるように消費者に求める。下位口座の各々に対して、イシュアが下位口座を発行したという確認が受け取られ、対応するそれぞれの加盟店に対する債務の各々は集計され、下位口座の信用限度は、対応する加盟店に対する集計された債務に見合うように設定され、第２通知は対応する加盟店に宛てられて、清算取引と併せて下位口座の指標を含む伝送を形成するように対応する加盟店に求め、清算取引と併せて下位口座の指標は受け取られ、清算取引は下位口座の指標を用いて下位口座によって、支払い可能であるとして確認され、そしてイシュアは、清算取引が下位口座により支払い可能であると通知される。その後、取引決済、信用限度の使用可能期間の終了、口座サイクル、および勘定残高のような要因に基づいて、信用限度の更なる調整は残りの未済債務を反映するために行われ得る。対応するそれぞれの加盟店に対する消費者の単一またはいくつかの債務のための下位口座の使用の終了に続いて、下位口座は、例えば、指定された期間の後に別の加盟店に再利用できる。

支払処理システム
前述の説明のための背景的な情報として、支払システムの技術者によって容易に理解されるように、支払システムの支払取引のような取引は、それぞれ支払処理システムの構成要素であるいろいろな主体からの参加を含むことができる。例示的な支払処理システムは図５に支払処理システム５００として示されている。支払処理システム５００は、前記イシュアのようなイシュア５０４、前記取引ハンドラのような取引ハンドラ５０６、前記アクワイアラのようなアクワイアラ５０８、前記加盟店のような加盟店５１０、および前記消費者のような消費者５０２を含む。アクワイアラ５０８およびイシュア５０４は取引ハンドラ５０６を通して通信できる。加盟店５１０は、アクワイアラ５０８、取引ハンドラ５０６、またはイシュア５０４と通信できる少なくとも１つのポイントオブサービス（ＰＯＳ）端末を利用できる。このように、ＰＯＳ端末は支払処理システム５００と通信動作を行う。

通常、取引は、商品またはサービスのための取引を開始するために、例えばコンピュータ端末または携帯用消費者向け装置５１２を用いることにより預金の口座番号を加盟店５１０に提示する消費者５０２から開始される。消費者５０２は個人または法人とすることができる。消費者５０２は、イシュア５０４により発行される口座の口座名義人、例えば口座の共同名義口座名義人または法人口座にアクセスできる法人の従業員のような口座にアクセスできる人でもよい。携帯用消費者向け装置５１２は、支払カード、ギフトカード、スマートカード、スマートメディア、給与カード、保健医療カード、リストバンド、口座情報を含む機械可読媒体、キーチェーン装置（例えば、エクソンモービル社から市販されているＳＰＥＥＤＰＡＳＳ（登録商標）またはスーパーマーケット割引カード）、携帯電話、携帯情報端末、ポケットベル、社会保障カード、コンピュータ、アクセスカード、無線端末、またはトランスポンダを含むことがある。携帯用消費者向け装置５１２は、口座番号または口座名義人の名前のような情報を格納するために揮発性または非揮発性メモリを含むことがある。

加盟店５１０は、携帯用消費者向け装置５１２から口座の指標（例えば、預金の口座番号）のような口座情報を得るために、ＰＯＳ端末のような受入れポイント装置を使用できる。携帯用消費者向け装置５１２は、無線周波数を用いる非接触型システムのような任意の適切な電気、磁気、または光学的インタフェースシステム、磁場認識システム、または磁気ストライプ読取器のような接触型システムを含む機構を用いてＰＯＳ端末に接続できる。ＰＯＳ端末は取引許可要求を携帯用消費者向け装置５１２のイシュア５０４に送信する。代わりに、または組み合わせて、携帯用消費者向け装置５１２は、イシュア５０４、取引ハンドラ５０６、またはアクワイアラ５０８と通信できる。

イシュア５０４は取引ハンドラ５０６を用いて取引を許可できる。許可は、イシュア５０４、または、例えばビジネス・ルールを用いることにより、イシュア５０４の命令に関連して取引を許可する、イシュア５０４に代わっての取引ハンドラ５０６を含む。ビジネス・ルールは、取引ハンドラ５０６、消費者５０２、加盟店５１０、アクワイアラ５０８、イシュア５０４、金融機関、またはそれらの組み合わせからの命令またはガイドラインを含むことができる。取引ハンドラ５０６は許可された取引のログまたは履歴を維持できる。一旦承認されると、加盟店５１０は許可を記録し、消費者５０２が商品またはサービスを受け取ることを可能にすることができる。

加盟店５１０は、その日の最後のような、とびとびの期間で、許可された取引のリストを支払処理システム５００のアクワイアラ５０８または他の構成要素に提出できる。取引ハンドラ５０６は、提出された許可された取引リストを許可された取引のそれ自体のログと比較できる。合致が見つかった場合は、取引ハンドラ５０６は、対応するアクワイアラ５０８からの許可取引額要求を各取引に関係する対応するイシュア５０４へ送ることができる。一旦アクワイアラ５０８がイシュア５０４から許可された取引額の支払いを受け取ると、それは支払いを加盟店５１０に手数料のような少ない取引コストで転送できる。取引が債務またはプリペイド・カードを含む場合は、アクワイアラ５０８は加盟店５１０に支払う前に頭金を待たないことを選ぶことができる。

前述のプロセスに断続的なステップがある場合があり、その幾つかは同時に起こる場合がある。例えば、アクワイアラ５０８は決済および清算プロセスを開始することが可能であり、それは取引の金額をアクワイアラ５０８に支払うことを可能にする。アクワイアラ５０８は、取引ハンドラ５０６から、取引が決済されて、清算されることを要求できる。決済はイシュア５０４とアクワイアラ５０８の間での金融情報の交換を含み、清算は資金の交換を含む。

取引ハンドラ５０６は取引の決済および清算に関連してサービスを提供できる。例えば、クレジットを含む取引の決済および清算は取引の許可の後に行われ得る。取引の清算は、清算機関、例えば清算銀行などに預金のために、決済機関、例えばイシュア決済銀行などから取引清算の金額を引き出すイシュア５０４を含む。取引ハンドラ５０６は取引清算の金額をアクワイアラ決済銀行に預ける。対応するアクワイアラ５０８はアクワイアラ決済銀行から取引清算の金額を引き出す。通常、イシュア５０４はイシュア決済銀行を選び、取引ハンドラ５０６は清算銀行を選択し、そしてアクワイアラは決済銀行を選ぶ。取引がデビットを含むときに、決済は許可プロセスの間に行われ得る。このように、典型的取引は、決済および清算のための取引の処理を要求し、許可し、そして履行するためにさまざまな主体を含む。

実施態様が、ソフトウェア、ハードウェア、または両方の組合せを用いて、制御論理の形で、モジュールまたは集積化方式法であり得ることを理解すべきである。本願明細書において、開示される実施態様に関連して記載されている方法、プロセス、またはアルゴリズムのステップは、直接ハードウェアにおいて、プロセッサにより実行されるソフトウェアモジュールにおいて、または２つの組合せで実施され得る。

例えば、図６を参照すると、ブロック・レベル図は、売手に対する買手の債務を処理するための例示的なクライアント・サーバ環境を示している。サーバＳ（ｉ）６０２は、単一のサーバまたは地理的位置にわたって分散されたサーバ・ファームから成ることができる。サーバＳ（ｉ）６０２は、ＳＤＢ（Ｊ）６０４、例えばサーバ・データベースなどに接続されて通信できる。例えば、ＳＤＢ（Ｊ）６０４は複数のＳＤＢ（ｊ−Ｉ）６０４から成ることができる。サーバＳ（ｉ）６０２は、ネットワーク６０６を経由して少なくとも１つのクライアントＣ（ｋ）６０８に接続されて通信できる。ネットワーク６０６は、例えば、イーサネット（登録商標）ネットワーク、無線ネットワーク、ＬＡＮ、ＷＡＮ、グローバルエリア・ネットワーク、インターネット、ホームＰＮＡネットワーク、電力線通信ネットワーク、またはそれらの組み合わせでもよい。ネットワークは、ネットワーク・ノード、例えば、ブリッジ、ハブ、スイッチ、ルータ、またはネットワーク・インタフェース・カード（ＮＩＣ）などを相互接続するために、ハードウェア・ビルディング・ブロックを含むことができる。ビルディング・ブロックは、例えば、ガルバニック・ケーブル、マイクロ波中継装置、光ケーブルを経由して接続するか、または電波または電磁波などによって、無線で接続できる。

クライアントＣ（Ｉ）６０８は、クライアント・データベース、例えばＣＤＢ（Ｌ）６１０などに接続できる。ＣＤＢ（Ｌ）６１０は地理的に分散するか、または単一の位置にあることができる。

一実施態様では、取引ハンドラは、実行するときに図１〜４に示すステップを実施するコンピュータ実行コードの処理を容易にするために、サーバＳ（ｉ）６０２を利用できる。ＳＤＢ（Ｊ）６０４は、受け入れた債務、消費者識別子、加盟店識別子、受け入れた取引、および買手から売手への自動処理支払に関係する他のデータを格納できる。同様に、クライアントＣ（ｋ）６０８は情報を格納するためにＣＤＢ（Ｌ）６１０を利用できる。例えば、買手のＥＲＰは買手の支払勘定を格納するためにＣＤＢ（Ｌ）６１０と通信できる。

方法またはプロセスにおけるさまざまなステップまたは行為は、示される順序で実行するか、または別の順序で実行できる。さらに、１つ以上のプロセスまたは方法ステップは省略することができ、または１つ以上のプロセスまたは方法ステップは方法およびプロセスに加えられることが可能である。追加のステップ、ブロック、または動作は、方法およびプロセスの初め、最後、または介在既存要素に加えることができる。本願明細書に提供されている開示および教示に基づいて、当業者は他のやり方および／またはさまざまな実行のための方法を認めるはずである。

本願明細書に記載されている実施例および実施態様が例示するためのためであり、そしてそれを踏まえたさまざまな変更態様または変化が当業者に示唆されて、本出願の精神および範囲ならびに添付の特許請求の範囲の中に含まれると理解される。

Claims

以下のステップの各々が、ソフトウエアを実行する１つ又はそれ以上のサーバを有し、１つ又はそれ以上のデータベースと通信する取引ハンドラによって実行されるコンピュータにより実行される方法であって、
取引ハンドラが支払処理システムの中の口座における１つの取引に係わる消費者および加盟店によって各々特徴づけられる複数の前記取引を処理する支払処理システムであって、イシュアが前記口座を前記消費者に発行し、前記加盟店は、前記イシュアに前記１つの取引のために前記消費者からの資金を支払うよう求める前記取引ハンドラによって処理するために、前記１つの取引をアクワイアラに提出し、そして前記イシュアは、前記１つの取引のために前記加盟店に前記資金を支払うために前記アクワイアラに前記資金を転送する前記取引ハンドラに前記資金を転送する支払処理システムにおいて、
前記消費者が債務を負っている売手に対する売手識別子を受け取る段階と、
前記売手識別子を用いて、前記売手が前記支払処理システムの１つの前記加盟店であるどうかを決定する段階と、
前記売手が１つの前記加盟店でないとき、第１通知を前記消費者に宛てて、前記売手に前記支払処理システムの１つの前記加盟店になるよう依頼するように前記消費者に対して協力を求め、そして
前記売手が１つの前記加盟店であるとき、
第２通知を前記消費者に宛てて、前記消費者と前記売手の間の清算取引を前記支払処理システムの中の下位口座により支払い可能にするために、前記イシュアに、前記口座内に、前記売手に固有である前記下位口座を発行させるように前記消費者に求め、
前記イシュアが前記下位口座の指標を含む前記下位口座を発行したとの確認を受け取り、
前記下位口座の前記指標を含む、前記消費者と前記売手の間の前記清算取引を受け取り、ここで、前記清算取引は、前記売手の前記アクワイアラから送られ、前記取引ハンドラによって受け取られ、そして
前記消費者と前記売手の間の前記清算取引が前記下位口座による支払いが可能であることを前記イシュアに通知する段階と、
を含む方法。
複数の前記売手に対する前記消費者の複数の前記債務のそれぞれに対して、
前記売手識別子を受け取る段階は、対応する、前記それぞれの売手に対する前記消費者の債務についてのデータ受け取る段階を更に含み、そして
前記売手識別子を用いて、前記売手が前記支払処理システムの１つの前記加盟店であるかどうかを決定する段階と、
１つの前記加盟店であると決定された前記売手ごとに、
前記売手識別子を用いて、前記売手に対する前記消費者の複数の前記債務を集計する段階と、
通知を前記イシュアに宛てて、前記集計された前記売手に対する前記消費者の複数の前記債務に見合うように、前記対応する下位口座の信用限度を設定することを前記イシュアに要求する段階と、
通知を前記売手に宛てて、前記集計された前記売手に対する前記消費者の複数の前記債務に見合う前記資金について、前記対応する下位口座により支払い可能な前記清算取引を前記売手の前記対応するアクワイアラに提出することを前記売手に要求する段階と、
をさらに含む請求項１に記載のコンピュータにより実行される方法。
前記清算取引が決済され、清算されたとのしるしを受け取り、ここで、決済され、清算された前記資金は、前記売手に対する前記消費者の前記債務の第１部分に対するものであった段階と、
前記しるしを受け取る前記段階に続いて、前記売手に対する前記消費者の前記債務の第２部分に見合うように、別の前記対応する下位口座の信用限度を設定することを前記イシュアに要求する段階と、
をさらに含む請求項２に記載のコンピュータにより実行される方法。
前記売手に対する前記消費者の前記債務における未払金に見合う金額について、前記下位口座によって支払い可能である前記清算取引のために、前記消費者から１つの前記加盟店であると決定された前記売手へ前記資金を支払うことを前記イシュアに要求する段階と、
前記未払金に見合う前記金額のための前記口座によって支払い可能である前記清算取引のために、前記消費者から１つの前記加盟店であると決定された前記売手へ前記資金を支払うことを前記イシュアに要求する段階と、
前記未払金に見合う前記金額について、前記消費者から前記売手への小切手を提出することを第１金融機関に要求する段階と、
前記未払金に見合う前記金額について、前記消費者から前記売手への為替を提出することを第２金融機関に要求する段階と、
前記未払金に見合う前記金額について、前記消費者から前記売手へのＡＣＨ銀行口座振替を提出することを第３金融機関に要求する段階と、
のうちの少なくとも１つを行うことによって、前記売手に対する前記消費者の前記債務の支払いを容易にする段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
前記金額を前記未払金と照合することによって、前記売手に対する前記消費者の前記債務の監査を行う段階をさらに含む請求項４に記載のコンピュータにより実行される方法。
前記照合する段階が、
前記金額と関連した第１注文書識別子と前記未払金と関連した第２注文書識別子、
前記金額と関連した第１請求書識別子と前記未払金と関連した第２請求書識別子、および
前記金額と前記未払金、
のうちの少なくとも１つが等しいことを決定する段階を含む請求項５に記載のコンピュータにより実行される方法。
前記未払金、
前記金額、
前記第１注文書識別子、
前記第２注文書識別子、
前記第１請求書識別子、
前記第２請求書識別子、
前記第１注文書識別子が前記第２注文書識別子に等しかったかどうか、
前記第１請求書識別子が前記第２請求書識別子に等しかったかどうか、
前記金額が前記未払金に等しかったかどうか、および
それらの組み合わせ、
から成る群から選択される情報を含む前記監査の結果を前記消費者に送る段階をさらに含む請求項６に記載のコンピュータにより実行される方法。
前記売手識別子、前記売手の説明、および前記売手が受け入れる支払タイプのうちの少なくとも１つ含む消費者プロフィールについてのデータを前記消費者から受け取る段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
前記売手が前記支払処理システムの１つの前記加盟店になったという通知を受け取る段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
前記第１通知がさらに前記消費者に対して、前記消費者が前記売手に支払処理システムの１つの前記加盟店になるよう求めることを前記売手に知らせる許可を求める請求項１に記載のコンピュータにより実行される方法。
前記売手が前記支払処理システム内の１つの前記加盟店であるかどうか決定する段階が、前記売手識別子を、前記支払処理システム内の１つの前記加盟店であるかどうかを示す情報と前記加盟店識別子とをリンクする、サーバ・データベースに格納される前記売手の前記加盟店識別子と照合する段階と、
前記売手が前記支払処理システム内の１つの前記加盟店であるかどうかを示す前記情報を、前記売手に対する前記消費者の前記債務から検索する段階と、
のうちの少なくとも１つを含む請求項１に記載のコンピュータにより実行される方法。
前記消費者および１つの前記加盟店を前記受け取った清算取引内のデータと照合することによって、前記清算取引が前記下位口座により支払い可能であることを確認する段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
前記消費者と１つの前記加盟店の間の前記受け取った清算取引が前記売手に対する前記消費者の前記債務に関連している請求項１に記載のコンピュータにより実行される方法。
前記売手に対する前記消費者の前記債務が、手形、注文書、受取勘定、および納品書から成る群から選択される請求項１に記載のコンピュータにより実行される方法。
取引ハンドラが支払処理システムの中の口座における１つの取引に係わる消費者および加盟店によって各々特徴づけられる複数の前記取引を処理する支払処理システムであって、イシュアが前記口座を前記消費者に発行し、前記加盟店は、前記イシュアに前記１つの取引のために前記消費者からの資金を支払うよう求める前記取引ハンドラによって処理するために、前記１つの取引をアクワイアラに提出し、そして前記イシュアは、前記取引のために前記加盟店に前記資金を支払うために前記アクワイアラに前記資金を転送する前記取引ハンドラに前記資金を転送する支払処理システムにおいて、以下のステップの各々が、ソフトウエアを実行する１つ又はそれ以上のサーバを有し、１つ又はそれ以上のデータベースと通信する取引ハンドラによって実行されるコンピュータにより実行される方法であって、
複数の前記加盟店に対する前記消費者の複数の債務を受け取る段階と、
前記加盟店と前記消費者の間の清算取引を下位口座により支払い可能にするために、前記イシュアが、前記口座内に、前記加盟店に固有の前記下位口座を発行するように前記消費者に求める第１通知を前記消費者に宛てる段階と、
前記イシュアが前記下位口座を発行したとの確認を受け取る段階と、
前記売手識別子を用いて、前記加盟店に対する債務を集計し、
前記集計された前記加盟店に対する債務に対応する前記下位口座の信用限度を前記イシュアに設定するように、前記イシュアに求める伝送を宛てる段階と、
前記清算取引に前記下位口座の指標を含めるように前記加盟店に求める第２通知を前記加盟店に宛てる段階と、
前記清算取引と共に前記下位口座の前記指標を受け取り、ここで前記前記清算取引と共の前記下位口座の前記指標は、前記加盟店のアクワイアラから送られ、前記取引ハンドラによって受け取られる段階と、
そして
前記清算取引が前記下位口座による支払いが可能であることを前記イシュアに通知する段階と、
を含む方法。
前記確認する段階が、
サーバ・データベースに格納される第１消費者識別子と前記清算取引において受け取られる第２消費者識別子を、かつ
前記清算取引において受け取られる第２加盟店識別子と前記下位口座に対応する前記サーバ・データベースに格納される第３加盟店識別子を、
照合することによって、前記清算取引が前記下位口座の前記指標を用いて前記下位口座による支払いが可能であることを確認する段階をさらに含む請求項１５に記載の方法。
前記清算取引の前記資金の額を前記加盟店の前記集計した債務と照合することによって、前記債務について監査を行う段階を含む請求項１５に記載の方法。
前記照合する段階が、
１つの前記債務と関連した第１注文書識別子と前記清算取引内の第２注文書識別子、
１つの前記債務と関連した第１請求書識別子と前記清算取引内の第２請求書識別子、および
資金の前記金額と前記債務の未払金、
のうちの少なくとも１つが等しいことを決定する段階を含む請求項１７に記載の方法。
取引ハンドラが支払処理システムの中の口座における１つの取引に係わる消費者および加盟店によって各々特徴づけられる複数の前記取引を処理する支払処理システムであって、イシュアが前記口座を前記消費者に発行し、前記加盟店は、前記イシュアに前記１つの取引のために前記消費者からの資金を支払うよう求める前記取引ハンドラによって処理するために、前記１つの取引をアクワイアラに提出し、そして前記イシュアは、前記１つの取引のために前記加盟店に前記資金を支払うために前記アクワイアラに前記資金を転送する前記取引ハンドラに前記資金を転送する支払処理システムにおいて、以下のステップの各々が、ソフトウエアを実行する１つ又はそれ以上のサーバを有し、１つ又はそれ以上のデータベースと通信する取引ハンドラによって実行されるコンピュータにより実行される方法であって、
前記加盟店に対して債務を負う買手の買手識別子を受け取る段階と、
前記買手識別子を用いて、前記買手が前記支払処理システム内の１人の前記消費者であるどうかを決定する段階と、
前記買手が１人の前記消費者でないと決定されたとき、第１通知を前記加盟店に宛てて、前記加盟店が前記買手に前記支払処理システムの１人の前記消費者になるよう依頼する許可を前記加盟店に求め、そして
前記買手が１人の前記消費者であると決定されたとき、
第２通知を前記買手に宛てて、前記買手と前記加盟店の間の清算取引を下位口座により支払い可能にするために、前記イシュアに、前記口座内に、前記加盟店に固有である前記下位口座を前記加盟店に発行させるように前記買手に求め、
前記イシュアが前記下位口座の指標を含む前記下位口座を発行したとの確認を受け取り、
前記下位口座の前記指標を含む、前記買手と前記加盟店の間の前記清算取引を受け取り、ここで前記清算取引は前記加盟店の前記アクワイアラから送られ、前記取引ハンドラによって受け取られ、そして
前記買手と前記加盟店の間の前記清算取引が前記下位口座による支払いが可能であることを前記イシュアに通知する段階と、
を含む方法。
前記加盟店に対する前記買手の複数の前記債務の各々に対して、
前記買手識別子を受け取る段階は、対応する、前記加盟店に対する前記買手の債務についてのデータを受け取る段階をさらに含み、そして
前記買手識別子を用いて、前記買手が前記支払処理システム内の１人の消費者であるかどうかを決定し、そして
１人の前記消費者であると決定された前記買手の各々に対して、
前記対応する買手識別子を用いて、前記加盟店に対する前記買手の前記複数の債務を集計する段階と、
前記集計された前記加盟店に対する前記買手の複数の前記債務に見合うように、前記対応する下位口座の信用限度を設定するように前記イシュアに求める段階と、そして
通知を前記加盟店に宛てて、前記集計された前記加盟店に対する前記各買手の複数の前記債務に見合う前記資金について、前記対応する下位口座により支払い可能な前記清算取引を前記アクワイアラに提出することを前記加盟店に要求する段階と、
をさらに含む請求項１９に記載のコンピュータにより実行される方法。
前記加盟店に対する前記買手の前記債務における未払金に見合う金額について、前記対応する下位口座によって、支払い可能である前記清算取引のために、１人の前記消費者であると決定された前記買手から前記加盟店へ前記資金を支払うことを前記イシュアに要求する段階と、
前記未払金に見合う前記金額のための前記口座によって、支払い可能である前記清算取引のために、１人の前記消費者であると決定された前記買手から前記加盟店へ前記資金を支払うことを前記イシュアに要求する段階と、
前記未払金に見合う前記金額について、前記買手から前記加盟店への小切手を提出することを第１金融機関に要求する段階と、
前記未払金に見合う前記金額について、前記買手から前記加盟店への為替を提出することを第２金融機関に要求する段階と、
前記未払金に見合う前記金額について、前記買手から前記加盟店へのＡＣＨ銀行口座振替を提出することを第３金融機関に要求する段階と、
前記未払金に見合う前記金額について、前記買手から前記加盟店への通貨転送を要請する金融機関の協同組合内の金融メッセージを提出することを第４金融機関に要求する段階と、
のうちの少なくとも１つを行うことによって、前記加盟店に対する前記買手の前記債務の支払いを容易にする段階をさらに含む請求項１９に記載のコンピュータにより実行される方法。
前記金額を前記未払金と照合することによって、前記加盟店に対する前記買手の前記債務の監査を行う段階をさらに含む請求項２１に記載のコンピュータにより実行される方法。
取引ハンドラが、イシュアによって消費者に発行された支払処理システムの中の口座における１つの取引に係わる前記消費者および加盟店によって各々特徴づけられる複数の前記取引を処理する支払処理システムであって、前記イシュアが、前記１つの取引のために前記加盟店に前記資金を支払うために前記アクワイアラに前記資金を転送する前記取引ハンドラに前記資金を転送する支払処理システムにおいて、以下のステップの各々が、ソフトウエアを実行する１つ又はそれ以上のサーバを有し、１つ又はそれ以上のデータベースと通信する取引ハンドラによって実行されるコンピュータにより実行される方法であって、
複数の前記消費者によって、前記加盟店に対する複数の債務を受け取る段階であって、各前記債務は各前記消費者に固有の消費者識別子を含む段階と、
第１通知を各前記消費者に宛てて、前記支払処理システム内の対応する前記下位口座により前記消費者と前記加盟店の間の前記清算取引を支払い可能にするために、前記消費者が前記イシュアに前記加盟店に固有の前記口座の前記下位口座を前記消費者に発行させることを求める段階と、
各前記消費者に対応する各前記下位口座に対して、
前記消費者識別子を用いて、各前記消費者に対応する前記債務を集計し、
前記集計された各前記消費者の債務に対応する前記下位口座の信用限度を設定するように前記イシュアに求める伝送を前記イシュアに宛て、
前記清算取引に前記下位口座の指標を含めるように前記加盟店に求める第２通知を前記加盟店に宛て、
前記清算取引と共に前記下位口座の前記指標を受け取り、ここで前記清算取引と共の前記下位口座の前記指標は、前記加盟店のアクワイアラから送られ、前記取引ハンドラにより受け取られ、
そして
前記清算取引が前記下位口座による支払いが可能であることを前記イシュアに通知する段階と、
を含む方法。
各前記下位口座に対して、前記清算取引のために支出される資金の金額を前記加盟店に対する各前記消費者の前記集計された債務と照合することによって、前記加盟店に対する前記複数の債務の監査を各前記消費者に対して行う段階をさらに含む請求項２３に記載のコンピュータにより実行される方法。
前記照合する段階が、
前記債務のうちの１つと関連した第１注文書識別子と前記清算取引の中の第２注文書識別子、および
前記債務のうちの１つと関連した第１請求書識別子と前記清算取引の中の第２請求書識別子、
のうちの少なくとも１つを照合する段階を含む請求項２４に記載のコンピュータにより実行される方法。
前記第１通知が、
前記売手の前記名前、
前記売手が現在前記口座での支払を受け入れていない旨の記述、
前記売手が前記加盟店の１つになるように要請することについて前記消費者が承認することの要求、および
前記売手が前記加盟店の１つになるように要請する仕方についての情報の要求、
の少なくとも１つを含み、
前記確認が、
前記消費者の前記名前、
前記下位口座を発行した前記イシュアの前記名前、
下位口座の番号、および
前記下位口座の信用限度、
の少なくとも１つを含む請求項１に記載のコンピュータにより実行される方法。
前記確認が、
前記消費者の前記名前、
前記下位口座を発行した前記イシュアの前記名前、
下位口座の番号、および
前記下位口座の信用限度、
の少なくとも１つを含む請求項１５に記載のコンピュータにより実行される方法。
前記第１通知が、
前記売手の前記名前、
前記売手が現在前記口座での支払を受け入れていない旨の記述、
前記売手が前記加盟店の１つになるように要請することについて前記消費者が承認することの要求、および
前記売手が前記加盟店の１つになるように要請する仕方についての情報の要求、
の少なくとも１つを含み、
前記確認が、
前記消費者の前記名前、
前記下位口座を発行した前記イシュアの前記名前、
下位口座の番号、および
前記下位口座の信用限度、
の少なくとも１つを含む請求項１９に記載のコンピュータにより実行される方法。