(57)【要約】  売手に対する買手の債務が支払処理システムの中で発行人によって買手に発行される口座を用いて支払われることができない場合に、売手および買手の一方または両方は口座により支払い可能な清算取引を行うように要請される。債務が口座を用いて支払うことができるならば、売手および買手に固有の下位口座が作成される。買手と売手の間の取引は、処理の前に債務を集計するオプションを含んで、下位口座を用いて処理することができる。下位口座の信用限度は集計した債務の額に合致するように設定できる。【選択図】図２
2010509699.tif 000002
【特許請求の範囲】
【請求項１】
取引ハンドラが支払処理システムの中の口座における１つの取引に係わる消費者および商人によって各々特徴づけられる複数の前記取引を処理する前記支払処理システムにおいて、発行人が前記口座を前記消費者に発行し、前記商人は、前記発行人に前記１つの取引のために前記消費者からの資金を支払うよう求める前記取引ハンドラによって処理するために、前記１つの取引をアクワイアラに提出し、そして前記発行人は、前記１つの取引のために前記商人に前記資金を支払うために前記アクワイアラに前記資金を転送する前記取引ハンドラに前記資金を転送するコンピュータにより実行される方法であって、
売手識別子を含む、売手に対する前記消費者の債務を受け取る段階と、
前記売手識別子を用いて、前記売手が前記支払処理システムの前記１人の商人であるどうかを決定する段階と、
前記売手が前記１人の商人でないとき、第１通知を前記消費者に宛てて、前記売手に前記支払処理システムの前記１人の商人になるよう依頼するように前記消費者に対して協力を求め、そして
前記売手が前記１人の商人であるとき、
第２通知を前記消費者に宛てて、前記消費者と前記１人の商人の間の清算取引を下位口座により支払い可能にするために、前記発行人に、前記口座内に、前記１人の商人に固有である前記下位口座を発行させるように前記商人に求め、
前記発行人が前記下位口座の指標を含む前記下位口座を発行したとの確認を受け取り、
前記下位口座の前記指標を含む、前記消費者と前記１人の商人の間の前記清算取引を受け取り、
前記清算取引が前記下位口座の前記指標を用いて前記下位口座による支払いが可能であることを確認し、そして
前記消費者と前記１人の商人の間の前記清算取引が前記下位口座による支払いが可能であることを前記発行人に通知する段階と、
を含む方法。
【請求項２】
前記対応するそれぞれの売手識別子を含む、複数の前記売手に対する前記消費者の複数の前記債務を受け取る段階と、そして
前記１人の商人である前記売手ごとに、
前記対応する売手識別子を用いて、各前記売手に対する前記消費者の複数の前記債務を集計する段階と、
前記消費者の集計された複数の前記債務を各前記売手と合致させるために、前記対応する下位口座の信用限度を設定する段階と、
第３通知を各前記売手に宛てて、前記消費者の集計された複数の前記債務を各前記売手と合致させる前記資金のために前記対応する下位口座により支払い可能な前記清算取引を各前記売手の前記対応するアクワイアラに提出することを各前記売手に要求する段階と、
をさらに含む請求項１に記載のコンピュータにより実行される方法。
【請求項３】
前記清算取引が決済され、清算されたとの表示を受け取る段階であって、決済され、清算された前記資金が各前記売り手に対する前記消費者の前記債務の第１部分のためのものであった段階と、
前記表示を受け取る前記段階に続いて、前記消費者の前記債務の第２部分を前記売手に合致させるために、前記対応する下位口座の信用限度を設定する段階と、
を前記１人の商人である前記売手に対して実行する段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
【請求項４】
前記売手に対する前記消費者の前記債務における未払金に合致する金額のための前記下位口座によって支払い可能である前記清算取引のために、前記消費者から前記１人の商人である前記売手へ前記資金を支払うことを前記発行人に要求する段階と、
前記未払金に合致する前記金額のための前記口座によって支払い可能である前記清算取引のために、前記消費者から前記１人の商人である前記売手へ前記資金を支払うことを前記発行人に要求する段階と、
前記未払金に合致する前記金額のための前記消費者から前記売手への小切手を提出することを第１金融機関に要求する段階と、
前記未払金に合致する前記金額のための前記消費者から前記売手への為替を提出することを第２金融機関に要求する段階と、
前記未払金に合致する前記金額のための前記消費者から前記売手へのＡＣＨ銀行口座振替を提出することを第３金融機関に要求する段階と、
のうちの少なくとも１つを行うことによって、前記売手に対する前記消費者の前記債務の支払いを容易にする段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
【請求項５】
前記金額を前記未払金と照合することによって、前記売手に対する前記消費者の前記債務の監査を行う段階をさらに含む請求項４に記載のコンピュータにより実行される方法。
【請求項６】
前記照合段階が、
前記金額と関連した第１注文書識別子と前記未払金と関連した第２注文書識別子、
前記金額と関連した第１請求書識別子と前記未払金と関連した第２請求書識別子、および
前記金額と前記未払金、
のうちの少なくとも１つが等しいことを決定する段階を含む請求項５に記載のコンピュータにより実行される方法。
【請求項７】
前記未払金、
前記金額、
前記第１注文書識別子、
前記第２注文書識別子、
前記第１請求書識別子、
前記第２請求書識別子、
前記第１注文書識別子が前記第２注文書識別子に等しかったかどうか、
前記第１請求書識別子が前記第２請求書識別子に等しかったかどうか、
前記金額が前記未払金に等しかったかどうか、および
それらの組み合わせ、
から成る群から選択される情報を含む前記監査の結果を前記消費者に送る段階をさらに含む請求項６に記載のコンピュータにより実行される方法。
【請求項８】
前記売手識別子、前記売手の説明、および前記売手が受け入れる支払タイプのうちの少なくとも１つ含む消費者プロフィールを前記消費者から受け取る段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
【請求項９】
前記売手が前記支払処理システムの１人の前記商人になったという通知を受け取る段階をさらに含む請求項１に記載のコンピュータにより実行される方法。
【請求項１０】
前記第１通知がさらに前記消費者に対して、前記消費者が前記売手に支払処理システムの前記１人の商人になるよう求めることを前記売手に知らせる許可を求める請求項１に記載のコンピュータにより実行される方法。
【請求項１１】
前記売手が前記支払処理システム内の前記１人の商人であるかどうか決定する段階が、
前記売手識別子を、前記売手が商人識別子を有する前記支払処理システム内の前記１人の商人であるかどうかを示す情報にリンクするサーバ・データベースに格納される前記売手の前記商人識別子と合致させる段階と、
前記売手が前記支払処理システム内の前記１人の商人であるかどうかを示す前記情報を、前記売手に対する前記消費者の前記債務から検索する段階と、
のうちの少なくとも１つを含む請求項１に記載のコンピュータにより実行される方法。
【請求項１２】
前記清算取引が前記下位口座により支払い可能であることを確認する前記段階が、前記消費者および前記１人の商人を前記受け取った清算取引のデータと合致させる段階を含む請求項１に記載のコンピュータにより実行される方法。
【請求項１３】
前記消費者と前記１人の商人の間の前記受け取った清算取引が前記売手に対する前記消費者の前記債務に関連している請求項１に記載のコンピュータにより実行される方法。
【請求項１４】
前記売手に対する前記消費者の前記債務が、手形、注文書、受取勘定、および納品書から成る群から選択される請求項１に記載のコンピュータにより実行される方法。
【請求項１５】
前記発行人に通知する前記段階後かつ前記清算取引が決済され、清算された後に、前記下位口座は、前記消費者と別の前記１人の商人の間の第２前記清算取引を前記下位口座によって支払い可能にするために、前記１人の商人から分離され、別の前記１人の商人に関連づけられる請求項１に記載のコンピュータにより実行される方法。
【請求項１６】
取引ハンドラが、発行者が消費者に発行した支払処理システムの中の口座における１つの取引に係わる前記消費者および商人によって各々特徴づけられる複数の前記取引を処理する前記支払処理システムにおいて、前記商人は、前記発行人に前記取引のために前記消費者からの資金を支払うよう求める前記取引ハンドラによって処理するために、前記取引をアクワイアラに提出し、そして前記発行人は、前記取引のために前記商人に前記資金を支払うために前記アクワイアラに前記資金を転送する前記取引ハンドラに前記資金を転送するコンピュータにより実行される方法であって、
複数の前記商人に対する前記消費者の複数の債務を受け取る段階であって、前記債務は各前記商人の商人識別子を含む段階と、
前記商人識別子の各々に対して、前記清算取引を下位口座により支払い可能にするために、前記発行人が、前記口座内に、前記対応する商人に固有の前記下位口座を発行するように前記消費者に求める第１通知を前記消費者に宛てる段階と、
各前記商人に対応する各前記下位口座に対して、
前記発行人が前記下位口座を発行したとの確認を受け取り、
各前記商人に対応する各債務を集計し、
各前記商人の前記集計した債務に対応する前記下位口座の信用限度を設定し、
前記清算取引とともに前記下位口座の指標を含むように前記商人に求める第２通知を前記商人に宛て、
前記清算取引に関連して前記下位口座の前記指標を受け取り、
前記清算取引が前記下位口座の前記指標を用いて前記下位口座による支払いが可能であることを確認し、そして
前記清算取引が前記下位口座による支払いが可能であることを前記発行人に通知する段階と、
を含む方法。
【請求項１７】
前記確認段階が、
サーバ・データベースに格納される第１消費者識別子と前記清算取引において受け取られる第２消費者識別子、
前記清算取引において受け取られる第２商人識別子と前記下位口座に対応する前記サーバ・データベースに格納される第３商人識別子、
を合致させることを含む請求項１６に記載の方法。
【請求項１８】
前記清算取引の前記資金の額を各前記商人の前記集計した債務と照合することによって、前記債務について監査を行う段階を含む請求項１６に記載の方法。
【請求項１９】
前記照合段階が、
前記債務と関連した第１注文書識別子と前記清算取引の中の第２注文書識別子、
１つの前記債務と関連した第１請求書識別子と前記清算取引の中の第２請求書識別子、および
資金の前記金額と前記債務の未払金、
のうちの少なくとも１つが等しいことを決定する段階を含む請求項１８に記載の方法。
【請求項２０】
取引ハンドラが支払処理システムの中の口座における１つの取引に係わる消費者および商人によって、各々特徴づけられる複数の前記取引を処理する前記支払処理システムにおいて、発行人が前記口座を前記消費者に発行し、前記商人は、前記発行人に前記１つの取引のために前記消費者からの資金を支払うよう求める前記取引ハンドラによって処理するために、前記１つの取引をアクワイアラに提出し、そして前記発行人は、前記１つの取引のために前記商人に前記資金を支払うために前記アクワイアラに前記資金を転送する前記取引ハンドラに前記資金を転送するコンピュータにより実行される方法であって、
買手のための買手識別子を含む、前記商人に対する前記買手の債務を受け取る段階と、
前記買手識別子を用いて、前記買手が前記支払処理システムの前記１人の消費者であるどうかを決定する段階と、
前記買手が前記１人の消費者でないとき、第１通知を前記商人に宛てて、前記買手に前記支払処理システムの前記１人の消費者になるよう依頼するために前記商人に対して協力を求め、そして
前記買手が前記１人の消費者であるとき、
第２通知を前記１人の消費者に宛てて、前記１人の消費者と前記商人の間の清算取引を下位口座により支払い可能にするために、前記発行人に、前記口座内に、前記商人に固有である前記下位口座を発行させるように前記１人の消費者に求め、
前記発行人が前記下位口座の指標を含む前記下位口座を発行したとの確認を受け取り、
前記下位口座の前記指標を含む、前記１人の消費者と前記商人の間の前記清算取引を受け取り、
前記清算取引が前記下位口座の前記指標を用いて前記下位口座による支払いが可能であることを確認し、そして
前記１人の消費者と前記商人の間の前記清算取引が前記下位口座による支払いが可能であることを前記発行人に通知する段階と、
を含む方法。
【請求項２１】
前記商人に対する複数の前記買手の複数の債務を受け取る段階であって、前記債務は前記対応する買手に固有の買手識別子を含む段階と、そして
前記１人の消費者である前記買手ごとに、
前記対応する買手識別子を用いて、前記商人に対する各前記買手の前記複数の債務を集計する段階と、
各前記買手の集計された複数の前記債務を前記商人と合致させるために、前記対応する下位口座の信用限度を設定する段階と、
第３通知を前記商人に宛てて、各前記買手の集計された複数の前記債務に合致する前記資金のために前記対応する下位口座により支払い可能な前記清算取引を前記アクワイアラに提出することを前記商人に要求する段階と、
をさらに含む請求項２０に記載のコンピュータにより実行される方法。
【請求項２２】
前記商人に対する前記買手の前記債務における未払金に合致する金額のための前記対応する下位口座によって、支払い可能である前記清算取引のために、１人の前記消費者である前記買手から前記商人へ前記資金を支払うことを前記発行人に要求する段階と、
前記未払金に合致する前記金額のための前記口座によって、支払い可能である前記清算取引のために、１人の前記消費者である前記買手から前記商人へ前記資金を支払うことを前記発行人に要求する段階と、
前記未払金に合致する前記金額のための前記買手から前記商人への小切手を提出することを第１金融機関に要求する段階と、
前記未払金に合致する前記金額のための前記買手から前記商人への為替を提出することを第２金融機関に要求する段階と、
前記未払金に合致する前記金額のための前記買手から前記商人へのＡＣＨ銀行口座振替を提出することを第３金融機関に要求する段階と、
前記未払金に合致する前記金額のための前記買手から前記商人への通貨転送を要請する金融機関の協同組合内の金融メッセージを提出することを第４金融機関に要求する段階と、
のうちの少なくとも１つを行うことによって、前記商人に対する前記買手の前記債務の支払いを容易にする段階をさらに含む請求項２０に記載のコンピュータにより実行される方法。
【請求項２３】
前記金額を前記未払金と照合することによって、前記商人に対する前記買手の前記債務の監査を行う段階をさらに含む請求項２２に記載のコンピュータにより実行される方法。
【請求項２４】
取引ハンドラが、支払処理システムの中の口座における１つの取引に係わる消費者および商人によって各々特徴づけられる複数の前記取引を処理する前記支払処理システムにおいて、コンピュータにより実行される方法であって、
複数の前記消費者によって、前記商人に対する複数の債務を受け取る段階であって、各前記債務は各前記消費者に固有の消費者識別子を含む段階と、
前記清算取引を下位口座により支払い可能にするために、前記消費者が前記発行人に前記商人に固有の、前記口座と関連する前記下位口座を発行させることを求める第１通知を各前記消費者に宛てる段階と、
各前記消費者に対応する各前記下位口座に対して、
各前記消費者に対応する前記債務を集計し、
各前記消費者の前記集計した債務に対応する前記下位口座の信用限度を設定し、
前記清算取引とともに前記下位口座の指標を含むように前記商人に求める第２通知を前記商人に宛て、
前記清算取引に関連して前記下位口座の前記指標を受け取り、
前記清算取引が前記下位口座の前記指標を用いて前記下位口座による支払いが可能であることを確認し、そして
前記清算取引が前記下位口座による支払いが可能であることを前記発行人に通知する段階と、
を含む方法。
【請求項２５】
各前記下位口座対して、前記清算取引のために支出される資金の金額を前記商人に対する各前記消費者の前記集計された債務と照合することによって、前記商人に対する前記複数の債務の監査を各前記消費者に対して行う段階をさらに含む請求項２４に記載のコンピュータにより実行される方法。
【請求項２６】
前記照合段階が、
前記債務のうちの１つと関連した第１注文書識別子と前記清算取引の中の第２注文書識別子、および
前記債務のうちの１つと関連した第１請求書識別子と前記清算取引の中の第２請求書識別子、
のうちの少なくとも１つを合致させることを含む請求項２５に記載のコンピュータにより実行される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
〔関連出願への相互参照〕
本出願は、「取引処理自動化」という名称の２００６年１１月１４日に出願の米国特許出願第６０／８６５，８３６号、および「支払処理システム債務転換通知」という名称の２００７年１１月７日に出願の米国特許出願第１１／９３６，４７５号に対する優先権およびそれの利益を請求し、それぞれの全内容は本願明細書に引用したものとする。
【０００２】
実施態様は、一般に支払の処理、より詳細には買手の売手に対する支払を自動的に処理して、送られた買手の売手に対する支払と買手の売手に対する支払の会計書類を照合することに関する。
【背景技術】
【０００３】
企業は、しばしば、さまざまな支払手段タイプによって、例えば、クレジット口座(credit account)、当座預金口座(checking account)、または自動決済機関(Automated Clearing House)（ＡＣＨ）銀行口座振替によって、他の企業との取引を処理する。例えば、買手は、買手が購入したい商品を開示している売手に対する注文書(purchase order)（ＰＯ）を有することができる。注文書は、契約上の義務または信用限度のような要因に応じて、それに関連したいくつかの支払タイプを有することができる。従って、買手は小切手を使用して特定の商品の代価を払う一方で、クレジットカードで他の商品の代価を払うことができる。同様に、複数の注文書は複数の支払タイプを有することがあり得る。
【０００４】
通常は、注文書または納品書(invoice)支払は人手で処理される。買手は支払勘定(accounts payable)ファイルを調べて、支払タイプに基づいて、例えば、売手に対して小切手を書くか、売手にクレジットカード払いを要求するか、または売手のための為替を準備できる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
支払のための支払タイプを人手で決定し、支払タイプを処理するさまざまなシステムのどれかを選び、そしてさまざまなシステムによる支払要求を普及させるプロセスは、追跡、照合、そして制御するのが煩雑になる場合がある。例えば、各注文書は別々に処理されて、複数の支払が或る時間帯に同じ買手になされるときに非効率を生じる場合がある。
【０００６】
いくつかの組織は、例えば単一の組織の支払勘定を格納することによって、組織内でデータを単一の統一システムに組み込む統合業務ソフト（ＥＲＰ）システムを通常は利用する。ＥＲＰシステムは買手の支払勘定または売手の受取勘定(accounts receivable)をまとめる際に役立つことができるが、ＥＲＰシステムはさまざまなシステムによる各支払いタイプを自動的に処理しないし、ＥＲＰは送られた支払を対応する納品書および／または注文書と自動的に照合することもしない。
【０００７】
さらに、いくつかの支払タイプは、買手または売手が社内で支払勘定または受取勘定を処理するときに、十分に活用されていない利点を有することがある。例えば、クレジット口座には、支払処理システムの中で、事業のオーナーに有益な可能性がある送金保証または条件つきインセンティブがある場合がある。支払処理システムが或る期間内に支払の送金を容易にするか、または売手の売上高を増加させる促進オプションを提供できるので、売手は支払処理システム内で口座になされる支払を好むことになる。買手が取引を行うときに口座を利用することによって、利益を受けることができるように、口座がロイヤルティプログラムの一部になるので、買手は口座になされる支払いを好むことになる。企業間取引において、ロイヤルティプログラムは、例えば、キャッシュバック、購入される商品のための保険金、またはマイレージサービスを受けるためのマイル数を含む場合がある。取引にたずさわる買手または売手が口座の取引を処理するためにその他の機能を知らなくてもよい、あるいは買手または売手がその他の選好を知ることができないので、これらの利点は十分に活用されないことになる。
【０００８】
買手から売手への支払義務の処理が自動化され得るシステムが必要である。これおよび他の問題は、個々に、そして集合的に、本願明細書において対処される。
【課題を解決するための手段】
【０００９】
買手と売手の間の支払の自動処理は、支払処理システムのために記載されているコンピュータで実行される方法で対処され、そこでは取引ハンドラは、支払処理システム内の口座の取引に係わる消費者および商人によって特徴づけられる取引を処理する。
【００１０】
１つのコンピュータ方法の実施態様では、消費者の売手に対する債務が受け取られ、売手識別子を含む。売手が支払処理システムの商人のうちの１人であるかどうかの決定が売手識別子を用いて行われる。売手が商人のうちの１人でない場合は、第１通知が消費者に宛てられて、売手に支払処理システムの商人の１人になるよう依頼するために消費者による協力を求める。売手が商人のうちの１人である場合は、第２通知が消費者に宛てられて、消費者と売手の間の清算取引を下位口座により支払い可能にするために、発行人に、口座内で、売手に固有である下位口座を発行させるように消費者に求める。発行人が商人のうちの１人である売手のための下位口座を発行したという確認が受け取られ、確認は下位口座の指標を含む。下位口座の指標を含む、消費者と売手（すなわち商人のうちの１人）の間の清算取引は受け取られる。清算取引は下位口座の指標を用いて下位口座により支払い可能であると確認される。発行人は下位口座により支払い可能である清算取引を通知される。
【００１１】
別の実施態様では、単一または数人の商人に対する消費者の少なくとも１つの債務が受け取られ、債務の各々は商人の各々の対応する商人識別子を含む。商人識別子の各々に対して、第１通知が消費者に宛てられて、清算取引を下位口座により支払い可能にするために、発行人に、口座内で、対応する商人に固有である下位口座を発行させるように消費者に求める。下位口座の各々に対して、発行人は下位口座を発行したとの確認が受け取られ、対応するそれぞれの商人に対する債務の各々が集計され、下位口座の信用限度が設定されて、集計された債務を対応する商人と合致させ、第２通知が対応する商人に宛てられて、清算取引とともに下位口座の指標を含む伝送を形成するように対応する商人に求める。清算取引とともに下位口座の指標は受け取られ、清算取引は下位口座の指標を用いて下位口座により支払い可能であるとして確認され、そして発行人は清算取引が下位口座により支払い可能であると通知される。代わりに、または組み合わせて、下位口座の信用限度は債務の一部に合致させて設定されることがある。下位口座の信用限度の設定は、例えば、清算取引の決済、下位口座の信用限度のための実施可能期間の完了、下位口座の口座サイクル、または下位口座の残高のような要因に基づくことができる。
【００１２】
さらに別の実施態様では、商人に対する買手の債務は受け取られ、そこでは債務は買手の買手識別子を含む。買手識別子を用いて、買手が支払処理システムの消費者のうちの１人であるかどうかの決定が行われる。買手が消費者の１人でない場合は、第１通知が商人に宛てられて、買手に支払処理システムの消費者の１人になるよう依頼するために商人に対して許可を求める。買手が消費者の１人である場合は、第２通知が消費者の１人に宛てられて、消費者の１人と商人の間の清算取引を下位口座により支払い可能にするために、発行人に、対応する口座内で、商人に固有である下位口座を発行させるように消費者の１人に求め、発行人は下位口座の指標を含む下位口座を発行したという確認が受け取られ、下位口座の指標を含む消費者の１人と商人の間の清算取引が受け取られ、清算取引は下位口座の指標を用いて下位口座により支払い可能であるとして確認され、そして発行人は消費者の１人と商人の間の清算取引が下位口座により支払い可能であると通知される。
【００１３】
さらに別の実施態様では、数人の消費者によって商人に借りられている債務が受け取られ、そこでは各債務は消費者の各々の対応する消費者識別子を含む。第１通知が消費者の各々に宛てられて、清算取引を下位口座により支払い可能にするために、対応する発行人に商人に固有である下位口座を発行させるように消費者の各々に求め、そこにおいて下位口座は口座と関連付けられる。下位口座の各々に対して、対応する消費者の商人に対する債務の各々が集計され、下位口座の信用限度が設定されて、対応する消費者の集計された債務を商人と合致させ、通知が対応する商人に宛てられて、清算取引とともに下位口座の指標を含む伝送を形成するように商人に求め、清算取引とともに下位口座の指標は受け取られ、清算取引は下位口座の指標を用いて下位口座により支払い可能であるとして確認され、そして発行人は清算取引が下位口座により支払い可能であると通知される。さらに、例えば、清算取引の決済、下位口座の信用限度のための実施可能期間の完了、下位口座の口座サイクル、および下位口座の残高のような要因に基づいて、下位口座の信用限度は債務の残りの未払い残高に合致するように調整されることができる。
【００１４】
実施態様は、図面を参照して以下に述べる詳細な説明によってより明らかになり、そこでは同じ要素には同じ参照番号がついている。
【図面の簡単な説明】
【００１５】
【図１】売手に対する買手の債務（例えば、金銭的負担の指標）が処理され得る例示的な方法を示す流れ図である。
【図２】売手に対する買手の債務が支払処理システムの口座を用いて処理され得る例示的な方法を示す流れ図である。
【図３】買手の売手に対する債務が処理され得る例示的な方法を示す流れ図である。
【図４】買手の売手に対する支払勘定が処理され得る例示的な方法のブロック図を示す。
【図５】図１、２、３、および４に示す例示的な方法が実行され得る例示的な支払処理システムのブロック図を示す。
【図６】買手の売手に対する債務を処理するための例示的なクライアント・サーバー環境を示すブロック・レベル図である。
【発明を実施するための形態】
【００１６】
一実施態様では、買手の売手に対する債務(debt)、例えば請求書(bill)または注文書などは自動的に処理される。債務を含んでいるファイルは解析されて、例えば小切手またはクレジットカードなどによって、債務を支払うことが可能になる支払タイプを決定する。支払タイプが支払処理システム（例えば、クレジット口座またはデビット口座）の口座以外である場合は、売手および買手の一方または両方は口座に支払える処理を行うように要請される。支払タイプが口座にある場合は、下位口座は売手および買手のために作成される。そして買手と売手の間の取引は、売手に対する買手の複数の債務を集計し、集計された債務の額の取引を下位口座により支払い可能に処理するか、債務を下位口座により支払い可能にするか、または債務の一部を下位口座により支払い可能にするというオプションを含めて、下位口座を用いて処理される。下位口座の信用限度は、集計された債務、債務、または債務の一部の額に合致するように設定することができる。代わりに、または組み合わせて、清算取引(future transaction)の決済(clearing)、下位口座の信用限度のための実施可能期間の完了、下位口座の口座サイクル、および下位口座の残高のような要因に基づいて、下位口座の信用限度は債務の残りの未払い残高に合致するように調整されることができる。
【００１７】
本願明細書において用いるように、買手は商品、サービス、または両方とも売手から賃貸するか、ライセンス供与されるか、または購入する人または主体である。売手は商品、サービス、または両方とも買手に賃貸するか、ライセンス供与するか、または販売する人または主体となる。買手または売手の各々は、企業間取引に係わる企業体または個人間取引に係わる個人となる。さらに、個人と企業間の取引または企業と個人間の取引も本願明細書において開示される。消費者は支払処理システムに口座を有する買手であり、そして商人は支払処理システムの口座により支払を受け取る売手である。支払処理システムは、取引ハンドラが支払処理システムの口座の取引のうちの１つに係わる消費者および商人によって、各々特徴づけられる多数の取引を処理するシステムである。支払処理システムにおいて、発行人は計算書を消費者に発行し、そして商人は、発行人に取引のための消費者から資金を支払うよう求める取引ハンドラによって、処理するために取引のうちの１つをアクワイアラ(acquirer)に提出する。発行人は、取引のための商人への資金を支払うためにアクワイアラに資金を送る取引ハンドラに資金を送る。支払処理システムのより詳細な説明について、支払い処理システムを以下に参照する。
【００１８】
図１および２を参照すると、２つの流れ図は売手に対する買手の少なくとも１つの債務が処理され得る例示的な方法を示している。
【００１９】
一実施態様では、買手の債務は消費者のうちの１人である買手のために処理される。プロセス１００のステップ１０２で、消費者が通常取引する複数の売手に関する情報を含む買手プロフィールは消費者から任意に受け取ることができる。情報は、売手ごとに、例えば、名前、住所、預金口座番号、売手識別子（例えば、売手コード）、売手の説明、売手に対する過去の支払総計、支払が売手に通常なされる日付を示している支払サイクル、売手と関連したアクワイアラの名前、売手が受け入れる支払形式、または売手のカテゴリーを含むことができる。
【００２０】
ステップ１０４で、売手のうちの少なくとも１人に対する消費者の債務は受け取られる。債務は、例えば、請求書、支払勘定文書、消費者のＥＲＰによって発生する電子支払勘定ファイル、注文書、または納品書でもよい。債務は、単一の売手の単一の請求書、単一の売手の複数の請求書、または複数の売手の複数の請求書に関するデータを含んでもよい。債務は、売手の各々に対して、債務が売手に起因するときの売手に対する未払金(amount owed)、売手識別子、買手識別子、または債務の各々が支払い可能になる支払タイプを含むことができる。
【００２１】
ステップ１０６で、売手の各々が商人のうちの１人であるかどうかの決定が行われる。債務が複数の未払金（例えば、複数の請求書）のためである場合は、決定は未払金の各々に対して行われる。
【００２２】
売手の各々に対して、対応する売手識別子は売手が商人のうちの１人であるかどうか決定するために用いることができる。債務において受け取られる売手識別子は、売手が支払処理システムの商人のうちの１人であるかどうかを示す情報を有する商人識別子にリンクするサーバ・データベースに格納されている売手のための商人識別子と合致することができる。例示のために、債務が売手識別子として「ＣＣＸＷＹＸ」を含み、そしてサーバ・データベースの売手の商人識別子が「ＣＣＸＷＹＸ」である場合は、合致があり、売手は商人のうちの１人である。マッチング方式の他の形は公知技術である。
【００２３】
売手が商人の１人であるかどうかを決定する別の手段は債務のデータを利用することである。前述のように、債務は売手によって受け入れられる支払タイプを含むことができる。例えば、債務は売手がクレジットカード払いを受け入れることを示すことができる。従って、売手が口座で支払いを受け取るので、売手は商人の１人である。債務の支払タイプは、売手が商人の１人であるかどうかを示す情報を有する商人識別子にリンクするサーバ・データベースのデータによって確認するか、または知ることができる。例えば、債務の支払タイプと、売手識別子と商人識別子の合致との間に不一致がある場合は、売手が商人の１人であるかどうかの決定は債務に示される支払タイプ以外のマッチングに基づくことがある。
【００２４】
売手が商人である場合に、プロセス１００は図２に示すプロセス２００のステップ２０１へジャンプする。その他の場合は、売手は商人の１人ではなく、ステップ１０８で、通知が消費者に宛てられて、売手に商人の１人になるよう依頼するために消費者に対して協力を求める。通知は、売手の名前、売手が口座での支払を現在受け入れないことを示す説明、売手が商人の１人になることの要請を消費者が承認するという要求、または商人の１人になることを売手に要請する方法に関する情報の要求を含むことができる。消費者の協力は売手に要請することに同意することでもよい。例えば、消費者は、商人の１人になることの利点を示す売手に送られる匿名のレターに同意することができ、あるいは、レターは匿名でなくてもよく、消費者には口座があって、売手に対する債務が口座を用いて払われるのを好むことを示すことができる。要請の他の形は当業者に周知である。
【００２５】
売手は、売手が商人の１人になりたいことを示すことができる。例えば、売手は要請を受け入れ、売手が口座での支払いを受け入れ始めることができると決定することができる。売手は、例えば、口座により支払い可能にされる資金を受け入れ始めるために、取引ハンドラまたはアクワイアラと法的拘束力のある契約を締結することができる。
【００２６】
売手が商人の１人になったという通知が受け取られることができる。例えば、取引ハンドラは、売手が商人の１人になった、そしてウェルズ・ファーゴ（Ｗｅｌｌｓ  Ｆａｒｇｏ）（登録商標）銀行が売手と関連したアクワイアラになったという通知を受け取ることができる。売手は、売手が受け入れる支払タイプの変更を反映するために売手のＥＲＰを更新することができるか、または取引を含む磁気ストライプ・フォーマット化された取引情報を含む伝送を形成できるソフトウェアを得ることのような、口座による支払いを処理することが可能な装備を得ることができる。ソフトウェアを用いて、売手は、取引通貨額、売手の名前、消費者の名前、取引の日付、伝送の日付、取引と関連した注文書の数、取引と関連した納品書の数、供される商品またはサービスの明細、または供される商品またはサービスの数量を含む取引情報を取引ハンドラへ転送するために、アクワイアラへ伝送できる。例えば、売手は口座による債務の支払いを要求する伝送を形成して、未払金および注文書の数を示すことができる。
【００２７】
売手が商人の１人でない場合は、債務は口座を使用せずに処理できる。例えば、伝送が形成されて、消費者の売手に対する債務に合致する値を有する、消費者から売手への小切手を提出すること、消費者の売手に対する債務に合致する値を有する、消費者から売手への為替を提出すること、または消費者の売手に対する債務に合致する値を有する、消費者から売手へのＡＣＨ銀行口座振替を提出することを銀行のような金融機関に要求できる。他の支払形式は当業者に周知である（例えば、トラベラーズ・チェック、直接銀行間振替、現金、または通貨価値を有するポイントのポイント振替）。例えば、金融メッセージが金融機関の協同組合内の金融メッセージング・サービスの会員（例えば、銀行、ブローカー・ディーラ、または投資顧問会社）の間で送られて、消費者の売手に対する債務に合致する値を有する、消費者から売手への振替を要求することができる。この種の協同組合の例は国際銀行間通信協会（ＳＷＩＦＴ）（登録商標）協同組合である。
【００２８】
金額を債務と合致させることは複数の方法で行うことができる。例えば、金額は対応する売手に対する債務における未払金の各々に等しくするか、金額は対応する売手に対する債務における未払金の少なくとも１つの各々の一部に等しくするか、金額は対応する売手に対する債務における未払金の総計に等しくするか、金額は複数の債務における対応する売手に対する複数の未払金の総計に等しくするか、金額は以前の債務の受領の後に受け取られた更新された債務に等しくするか、あるいは金額は債務における未払金プラス他の手数料、例えば、未払金で購入した商品の税金または送料および手数料などに等しくすることができる。
【００２９】
売手が商人の１人である場合は、売手および消費者に固有の、口座内の下位口座を開設することができる。売手の各々に対して、売手の各々に対する債務における未払金は集計され（例えば、時間のウインドウを通じて）、その後に対応する売手に対する集計された債務の清算取引を処理できる。さらに、監査が行われて、売手に対する清算取引および債務の送金された支払いの記録を照合できる。
【００３０】
図２のステップ２０２で、通知が消費者に宛てられて、消費者、および商人の１人である売手に固有である口座の下位口座を開設する。消費者、および商人の１人である売手の両方が清算取引に係わるときに清算取引が下位口座により支払い可能になるように、下位口座を開設するための通知は口座と関連した下位口座を発行するために消費者が消費者の発行人と連絡をとるように要求を示すことができる。例えば、下位口座が第１売手に対する消費者に発行される場合は、清算取引が消費者と第２売手の間にあるならば、清算取引は下位口座による支払い可能にすることはできない。
【００３１】
ステップ２０４で、消費者に固有であり、そして商人の１人である売手に固有である下位口座が発行人によって消費者に発行されたことを示す確認が受け取られる。確認は、消費者の名前、下位口座を発行した発行人の名前、下位口座の指標（例えば、下位口座番号）、商人の１人である売手の名前、または下位口座の信用限度を含むことができる。
【００３２】
ステップ２０６で、債務に（または複数の債務に）複数の未払金がある場合は、商人の１人である売手に対する未払金は集計される。例えば、債務は、ボーイング社である第１売手の１０通の請求書およびジェネラル・ミルス社である第２売手に対する８通の注文書を含むとする。ボーイング社の１０通の請求書の各々の未払金は集計されて、ボーイング社に対する未払金の総計に等しくすることができる。さらに、ゼネラル・ミルズ社に対する注文書の各々の未払金は集計されて、ゼネラル・ミルズ社に対する未払金の総計に等しくすることができる。
【００３３】
下位口座の信用限度は、債務、債務の一部、または商人の１人である売手に対する集計された未払金に合致するために設定され得る。例えば、アメリカン航空会社である消費者から受け取られる複数の債務は、１ヵ月の間にボーイング社から受け取られる請求書を含むとする。その月の未払金の総計の総計は５３０，０００ドル（米国）に等しいとする。ボーイング社に対するアメリカン航空会社の下位口座の信用限度は、前月のボーイング社に対する下位口座の信用限度であった５００，０００ドル（米国）から５５０，０００ドル（米国）へ増加されて、５３０，０００ドル（米国）の集計された未払金に合致することができる。集計された未払金に合致するために、信用限度は集計された未払金に等しいことが必要ではない。例えば、信用限度は、集計された未払金に反映されない口座になされることがある処理料金または他の手数料を考慮に入れて集計された未払金を超える割合であることができる。代わりに、または組み合わせて、信用限度は口座サイクルの間にゼロまたは他の値にリセットされてもよい。例えば、ボーイング社に対するアメリカン航空会社の信用限度は前月に５００，０００ドル（米国）に設定され、前月末にゼロにリセットされ、そして前月の後の月に二度目に５５０，０００ドル（米国）に設定されることがあり得る。
【００３４】
ステップ２０８で、通知が商人の１人である売手に任意に宛てられて、下位口座による支払いを要求する清算取引を提出し、そこでは清算取引は消費者および清算取引に係わっている商人の１人である売手によって特徴づけられる。清算取引は未払金または集計された未払金のためであってもよい。前の実施例を用いて例示するために、通知はボーイング社に宛てられて、ボーイング社が５３０，０００ドル（米国）またはアメリカン航空会社とボーイング社間のその他の清算取引に対して下位口座に請求できることを示すことになる。通知は、下位口座の指標、下位口座の指標の満期日、未払金、集計された未払金、清算取引が伝送されなければならない日付、未払金と関連した注文書の数、または未払金と関連した請求書の数を含むことができる。
【００３５】
ステップ２１０で、清算取引、例えば、未払金または集計された未払金に合致する資金の清算取引が任意に受け取られる。例えば、取引ハンドラは商人の１人である売手と関連したアクワイアラから清算取引を受け取ることができて、取引ハンドラは発行人に消費者からの未払金に合致する資金を支払うよう求めることができる。清算取引の伝送は、要求される資金の数量、下位口座の指標、売手に対する債務（または債務における未払金）と関連した注文書識別子（例えば、注文書の数）、または売手に対する債務（または債務における未払金）と関連した請求書識別子（例えば、請求書の数）を含むことができる。清算取引は磁気ストライプ・フォーマットであってもよい。
【００３６】
ステップ２１２で、確認が清算取引が下位口座によって支払い可能であるかどうかに関して任意に行われる。清算取引において受け取られる下位口座の指標は、サーバ・データベースに格納された複数の下位口座の複数の指標と比較されて、清算取引に係わる消費者および売手が下位口座に固有の消費者および売手に合致するかどうか決定できる。従って、発行人が下位口座をアップルコンピュータ株式会社（またはその系列会社）である売手のためにスターバックス・コーヒー会社（またはその系列会社）である消費者に発行する場合は、受け取った清算取引のデータが清算取引に係わる消費者および売手がそれぞれスターバックス・コーヒー会社（またはその系列会社）およびアップルコンピュータ株式会社（またはその系列会社）であることを示しているならば、清算取引は下位口座により支払い可能であるとして確認される。マッチング・アルゴリズムは、清算取引とサーバ・データベースのデータの間の合致を決定するために用いることができる。例えば、サーバ・データベースは会社およびその系列会社に関する情報を有することができる。例えば、下位口座がスターバックス・コーヒー会社に固有であり、そして清算取引がスターバックス・コーヒー会社の系列会社であるスターバックス・コーヒー・トレーディング会社とアップルコンピュータ株式会社の間にある場合は、マッチング・アルゴリズムは合致を返し、清算取引は下位口座によって、支払い可能であると確認される。
【００３７】
ステップ２１４で、発行人は清算取引が下位口座によって支払い可能であると通知される。発行人は、未払金、集計された未払金、売手の名前、消費者の名前、清算取引の日付、または清算取引のために消費者から資金を支払うことの要求を含む伝送により通知されることができる、そこでは発行人は、商人の１人である売手に資金を支払うために、アクワイアラに清算取引の資金を送る取引ハンドラに資金を送ることができる。
【００３８】
例えば、清算取引を提出するために通知を売手に宛てるステップ、清算取引を伝送で受信するステップ、または清算取引が下位口座によって支払い可能であることを確認するステップ無しで、発行人は、清算取引が下位口座によって支払い可能であると通知され得る。消費者および売手は、債務が、債務における未払金を下位口座によって支払い可能とする売手の意図の充分な示唆であることに合意することができる。発行人は所定の期間または所定の金額での清算取引を通知されることができる。例えば、消費者および売手は、売手に対する集計された未払金が各月の初めに、または債務における集計された未払金が５００ドル（米国）以上であるときはいつでも、発行人に清算取引を通知することにより処理されなければならないことに合意することができる。代わりに、または組み合わせて、消費者および売手は、発行人が債務が受け取られる時に債務における未払金に等しい資金の清算取引を通知されるように、売手に対する各債務は受け取られるときに処理されなければならないことに合意することができる。例えば、取引ハンドラは消費者のＥＲＰからの支払勘定ファイルである債務を断続的に受信できる。消費者および支払勘定ファイルに含まれる請求書を有する売手は、すべての請求書が取引ハンドラによって消費者のＥＲＰから支払勘定ファイルを受けると支払われることを前もって決めることができた。従って、この例では、請求書を含んでいる支払勘定ファイルを受け取ると、取引ハンドラは発行人への伝送を形成して、売手の請求書における未払金に等しい資金を支払うことを発行人に通知できる。
【００３９】
図２のステップ２１６で、債務の任意の監査が行われ得る。例えば、売手が商人の１人である場合に、監査は債務において未払金を有する口座を経て支出された資金を照合することにより行うことができる。照合は債務を有する清算取引の伝送において受け取られるマッチング・データを含むことができる。マッチングは、債務（または債務のうちの未払金）と関連した注文書の第２識別子とともに清算取引の伝送に含まれる注文書の第１識別子と、債務と関連した請求書の第２識別子とともに清算取引の伝送に含まれる請求書の第１識別子と、または債務とともに支出された資金の値との間の一致、例えば等価などを決定する段階を含むことができる。代わりに、または組み合わせて、債務の監査は、資金流通の決済（clearing）または清算(settling)プロセスの間に発行人から受け取られるか、またはアクワイアラから受け取られるデータを照合することにより行うことができる。例えば、発行人が取引ハンドラに資金を送るときに、送られた資金は、売手に対する消費者の債務における未払金と関連した注文書の指標と照合される注文書の指標を含むこともできる。
【００４０】
同様に、売手が商人の１人でない場合は、監査は、売手に提出される通貨額を消費者の債務の対応する売手に対する未払金と照合することにより行うことができる。例えば、消費者から売手への小切手の通貨額は、対応する売手に対する消費者の債務における未払金と照合されることがあり、消費者から売手への為替の通貨額は、対応する売手に対する消費者の債務における未払金と照合されることがあり、または消費者から売手へのＡＣＨ銀行口座振替の通貨額は、対応する売手に対する消費者の債務における未払金と照合されることがある。
【００４１】
監査の結果は、消費者、発行人、アクワイアラ、または売手に送信することができる。例えば、消費者は、対応する売手に各下位口座を経て支出される資金が消費者の債務において対応するそれぞれの売手に対する未払金に合致したように、消費者の債務の各々における未払金の全てが清算取引の受け取った伝送と照合されたことを示している報告を受け取ることができる。従って、監査の報告の情報は、未払金、金額、第１注文書識別子、第２注文書識別子、第１請求書識別子、第２請求書識別子、第１注文書識別子が第２注文書識別子に等価であったかどうか、第１請求書識別子が第２請求書識別子に等価であったかどうか、または金額が未払金に等価であったかどうかを含むことができる。
【００４２】
別の実施態様では、商人の各自である複数の売手に対する消費者の１人である買手の複数の債務が処理される。対応するそれぞれの商人識別子を含む複数の債務が受け取られる（ステップ１０４）。商人識別子の各々に対して、第１通知が消費者に宛てられて、清算取引を下位口座によって支払い可能にするために、発行人に対応する商人に固有である下位口座を発行してもらうように消費者に要求し、そこでは下位口座は支払処理システムの口座と関連している（ステップ２０２）。
【００４３】
下位口座ごとに、発行人が下位口座を発行したことを示す確認が受け取られる（ステップ２０４）。対応するそれぞれの商人に対する債務は集計され、そして下位口座の信用限度は集計された債務に合致するように設定される（ステップ２０６）。第２通知が対応する商人に送られて、清算取引と併せて下位口座の指標を含む伝送を形成するように対応する商人に求める（ステップ２０８）。下位口座の指標および清算取引を含む伝送が受け取られる（ステップ２１０）。清算取引は下位口座により支払い可能であるとして確認され（ステップ２１２）、発行人は、清算取引が下位口座により支払い可能であり（ステップ２１４）、そして監査が行われる（ステップ２１６）ことを通知される。
【００４４】
下位口座の信用限度は、債務の処理の間のいかなる時点でも、例えば図１および２に図示したように設定され得る。一実施態様では、下位口座の信用限度は、例えば清算取引がアクワイアラから受け取られる場合に清算取引で要求される資金の額に、または要求される資金の額と異なることがある、決済され、清算された清算取引の資金の第２額に合致するように設定され得る。代わりに、または組み合わせて、信用限度は下位口座の活性化期間で、または口座サイクルの別の時点で設定され得る。
【００４５】
例えば、取引の清算、信用限度の使用可能期間（例えば、信用限度を消費者が利用できる所定の期間）の完了、下位口座の口座サイクル内の時点または期間、あるいは下位口座の残高のような要因に基づいて、下位口座の信用限度は、清算取引が債務の一部について処理された後に未済である得る債務の残りの未払金に合致するように設定され得る。例えば、清算取引が処理され、清算された指標を受け取った後に、下位口座の信用限度は、債務の第２部分（例えば、消費者が１つの取引において、対応するそれぞれの商人に対する債務の全額を払わない場合に、対応するそれぞれの商人に対する残りの未払金）に合致する値に設定され得る。別の例では、清算取引が処理されて清算された後に、売手に対する消費者の債務のもう一方が受け取られる場合に、下位口座の信用限度は別の信用限度調整（例えば、信用限度の設定）に備えてゼロに設定され得る。
【００４６】
別の実施態様では、売手に対する少なくとも１人の買手の債務は商人の１人である売手のために処理される。図２および３を参照すると、債務は商人から受け取られ、買手が消費者の１人であるかどうかの決定が行われ、買手が消費者の１人でない場合は、買手は消費者の１人になることを求められ、買手が消費者の１人である場合は、通知が買手に宛てられて、買手および商人に固有の下位口座を開設する。商人に対する未払金は各買手ごとに集計されて、それに応じて処理することができる。
【００４７】
図３のステップ３０２で、商人は、商人が通常取引する複数の買手に関する情報を含む売手プロフィールを作成することができる。情報は、買手ごとに、買手の名前、買手の住所、買手の口座番号、買手識別子（例えば、買手コード）、買手の説明、商人に対する過去の未払金、支払が買手によって、通常なされる日付を示す支払サイクル、買手が支払い可能な支払いをする支払形式、買手と関連した発行人の名前、または買手のカテゴリーを含むことができる。
【００４８】
ステップ３０４で、買手のうちの少なくとも１人の商人に対する債務が受け取られる。債務は、例えば、請求書、受取勘定文書、商人のＥＲＰによって発生する電子受取勘定ファイル、注文書、または納品書でもよい。債務は、単一の買手に対する単一の請求書、単一の買手に対する複数の請求書、または複数の買手に対する複数の請求書に関するデータを含むことがあり得る。債務は、買手ごとに、債務が商人に起因する場合の商人に対する未払金、商人識別子、買手識別子、または債務が支払可能である支払タイプを含むことがあり得る。
【００４９】
ステップ３０６で、買手の各々が消費者の１人であるかどうかの決定が行われる。債務が複数の未払金（例えば、複数の請求書）に対してである場合は、決定は未払金の各々に対して行われ得る。
【００５０】
買手の各々に対して、対応する買手識別子は買手が消費者の１人であるかどうか決定するために用いることができる。債務において受け取られる買手識別子は、買手が支払処理システムの消費者の１人であるかどうかを示す情報に消費者識別子をリンクするサーバ・データベースに格納される買手のための消費者識別子に合致することができる。
【００５１】
買手が消費者の１人であるかどうか決定する別の手段は債務の中のデータを利用することである。債務は買手により利用される支払タイプを含むことができる。例えば、債務は買手がクレジットカード口座を有することを示すことができる。前の実施態様のように、債務は、買手が消費者の１人であるかどうかを示す情報に消費者識別子をリンクするサーバ・データベースのデータにより確認されるか、または知らされることができる。
【００５２】
買手がすでに支払処理システムの消費者である場合に、プロセス３００は終了し、図２に示すプロセス２００のステップ２０１へ移動する。さもなければ、ステップ３０８で、買手は消費者の１人でなく、そして通知が商人に宛てられて、買手に消費者の１人になるよう依頼するために商人に対して協力を求める。通知は、買手の名前、発行人が、現在まで、口座を買手に発行しなかったことを示す説明、買手が消費者の１人になることの要請を商人が承認するという要求、または消費者の１人になるように買手に求める方法に関する情報の要求を含むことができる。商人の協力は買手に要請することに同意することでもよく、例えば、匿名のレターまたは買手へのレターは、商人が口座を経て支出される資金を受け取って、商人に対する債務が口座を使用して払われるのを好むことを示すことができる。
【００５３】
買手は、買手が消費者の１人になりたいことを示すことができる。例えば、買手は要請を受け取り、発行人に口座を買手に発行してもらいたいと決定できる。買手は取引ハンドラまたは発行人と法的拘束力のある契約を締結して、例えば、口座を使用して資金を支払い始めることができる。
【００５４】
買手が消費者の１人になったという通知を受け取ることができる。買手は、買手が商人に対する未払金を支払うために使用する支払タイプの変更を反映するために買手のＥＲＰを更新し、または口座による支払を処理することが可能な装置またはソフトウェアを得ることができる。
【００５５】
前述のように、債務は口座を使用せずに処理できる。例えば、債務の未払金に合致する金額を有する小切手を買手から商人へ提出すること、債務の未払金に合致する金額を有する為替を買手から商人へ提出すること、債務に合致する金額を有するＡＣＨ銀行口座振替を買手から商人へ提出すること、または売手に対する消費者の債務に合致する金額を有する、消費者から売手への通貨送金を要請している金融機関の協同組合内の金融メッセージング・サービスを提出することという要求が、銀行のような金融機関に対して行われることがある。買手および商人は口座を使用せずに処理される債務を有することに同意することができた。例えば、買手は、取引ハンドラが買手から商人への小切手の提出を要求するために、取引ハンドラに買手の当座預金口座番号を与えることができた。
【００５６】
買手が消費者の１人である場合は、買手および商人に固有の、口座内の下位口座を開設することができる。商人に対する債務における未払金は消費者の１人である買手ごとに集計することが可能であり、債務における集計された未払金の清算取引は処理できる。さらに、監査は商人に対する清算取引および債務の送られた支払の記録を照合して行うことができる。
【００５７】
図２のステップ２０２で、通知が消費者の１人である買手に宛てられて、買手および商人に固有である、口座内の下位口座を開設する。商人および買手すなわち消費者の１人が清算取引に係わる場合に、清算取引が下位口座によって支払い可能にできるように、下位口座を開設する通知は、買手に、口座に関連して下位口座を発行するために買手の発行人と連絡をとることの要求を示すことができる。
【００５８】
ステップ２０４で、下位口座が発行されたとの確認が受け取られる。確認は、例えば、買手の名前、下位口座を発行した発行人の名前、下位口座の指標、商人の名前、または下位口座の信用限度を含むことができる。
【００５９】
ステップ２０６で、債務に複数の債務または複数の未払金がある場合は、商人に対する未払金は消費者の１人である各買手に対して集計される。前述のように、下位口座の信用限度は、売手に対する買手の債務、売手に対する買手の債務の一部、売手に対する買手の債務の中の未払金、売手に対する買手の債務の中の未払金の一部、または消費者の１人である買手による商人に対する集計された未払金に合致するように設定できる。
【００６０】
ステップ２０８で、通知が商人に任意に宛てられて、下位口座による支払を要求する清算取引を提出し、そこでは清算取引は消費者の１人である買手および清算取引に係わる商人によって特徴づけられる。清算取引は、例えば、未払金、未払金の一部、または集計された未払金のためである場合がある。通知は、下位口座の指標、下位口座の指標の満期日、未払金、集計された未払金、清算取引を伝えることができる日付、未払金と関連した注文書の番号、または未払金と関連した請求書の番号を含むことができる。
【００６１】
ステップ２１０で、未払金または集計された未払金に合致する資金の清算取引が任意に受け取られる。例えば、取引ハンドラは商人と関連したアクワイアラから清算取引を受け取ることが可能であり、取引ハンドラは発行人に消費者の１人である買手の未払金に合致する資金を支払うよう求めることができる。清算取引の伝送は、未払金の額、下位口座の指標、未払金と関連した注文書の番号、または未払金と関連した請求書の番号を含むことができる。前述のように、ステップ２１２で、清算取引が下位口座により支払可能であるかどうかの確認が行われ、ステップ２１４で、発行人は下位口座により支払可能である清算取引を通知される。さらに、前の実施態様のように、発行人は、清算取引を提出するために通知を商人に宛てるステップ、伝送の清算取引を受け取るステップ、または清算取引が下位口座により支払可能であることを確認するステップ無しに、清算取引を通知され得る。
【００６２】
図２を参照すると、ステップ２１６で、商人に対する各売手の債務が監査されて、商人が買手の各々による商人に対する債務における未払金の各々に対応する支払いを受け取ったかどうかを決定できる。
【００６３】
別の実施態様では、消費者の各自である複数の買手による商人の１人である売手に対する複数の債務が処理される。対応するそれぞれの消費者識別子を含む複数の債務が受け取られる（ステップ１０４）。消費者識別子の各々に対して、第１通知が対応する消費者に宛てられて、清算取引を下位口座により支払可能にするために、対応する発行人に対応する消費者に固有である下位口座を発行させることを対応する消費者に要求し、そこでは下位口座は支払処理システムの中の口座と関連している（ステップ２０２）。
【００６４】
下位口座ごとに、対応するそれぞれの消費者の債務は集計されて、下位口座の信用限度は集計された債務に合致するように設定される（ステップ２０６）。第２通知が商人に送られて、対応する消費者を有する清算取引と併せて下位口座の指標を含む伝送を形成するように商人に求める（ステップ２０８）。下位口座の指標および清算取引を含む伝送が受け取られる（ステップ２１０）。清算取引は下位口座により支払可能であるとして確認され（ステップ２１２）、そして発行人は清算取引が下位口座により支払可能であると通知される（ステップ２１４）。
【００６５】
下位口座は対応する売手から分離されて、清算取引が処理され、清算された後に別の売手に関連付けられることが可能である。例えば、清算取引が下位口座により支払可能であると発行人に通知した後に、そして清算取引に関係する売手が資金を支払われるように、清算取引が完了した後に、下位口座は支払われた売手から分離されて、消費者と下位口座により支払可能である売手の間の第２清算取引を行うために別の売手に関連付けられることが可能である。例えば、シアーズ・ホールディングス社（「シアーズ」）は、それが、「１２３４５」のような口座番号を有すると、ブラック＆デッカー社への支払いを決済できる下位口座を有することができる。ブラック＆デッカー社に対する未払金の資金を送金することに続いて、シアーズは、口座番号「１２３４５」を有する下位口座をブラック＆デッカー社から分離し、次に下位口座をゼネラルエレクトリック社である別の売手と関連付けることをシアーズの下位口座の発行人に要求できる。
【００６６】
図４を参照すると、さらに別の実施態様では、買手の支払勘定は方法４００で処理され、照合される。ステップ４０２で、複数の売手の支払勘定およびそれらの対応するそれぞれの注文書番号を有する買手の支払勘定ファイルが受け取られる。方法４００の残部は支払勘定ファイル内の売手ごとに実行される。問合せ４０４で、売手が支払処理システム内の口座による支払いを受け入れるかどうかの決定が行われる。例えば、サーバ・データベースは、支払勘定ファイル内の売手が商人の１人であるかどうか決定するためにアクセスされる。前述のように、売手識別子および商人識別子が合致する場合は、売手は口座による支払いが可能にされた支払いを受け入れる。問合せ４０４の決定が否である場合は、売手は口座による支払いが可能にされた支払いを受け入れず、そして支払勘定はステップ４０６で口座以外の手段により処理される。さらに、ステップ４０８で、買手は、売手が買手および売手に固有である口座と関連した仮想口座、例えば下位口座による支払いが可能にされた支払いを受け入れていないことを通知される。ステップ４１０で、仮想口座による支払いが可能にされた支払いを受け入れることを売手に求める買手からの承認が受け取られる。ステップ４１２で、売手は、買手と売手の間の清算取引のための仮想口座による支払いが可能にされた支払いを受け入れるように要請される。ステップ４１４で、サーバ・データベースは、売手が仮想口座による支払いが可能にされた支払いを受け入れるという変更を反映するために更新される。
【００６７】
問合せ４０４の決定がイエスである場合は、売手は口座による支払いが可能にされた支払いを受け入れ、そして第２問合せ、問合せ４１６が提起される。問合せ４１６で、支払タイプの支払勘定ファイル表示が決定される。支払勘定ファイル内の支払タイプが、売手が口座による支払いが可能にされた支払いを受け入れることを示さない場合は、ステップ４０６は支払勘定が口座を利用すること以外の手段により処理されることを示す。さらに、問合せ４１８で、売手が仮想口座による支払いが可能にされた支払いを受け入れるかどうかの決定が行われる。問合せ４１８が売手が仮想口座による支払いが可能にされた支払いを受け入れないことを示す場合は、買手はステップ４０８において、売手が仮想口座による支払いを受け入れないと通知され、（ステップ４１０）承認が売手に要請するために受け取られ、（ステップ４１２）売手は仮想口座による支払いが可能にされた支払いを受け入れることを要請され、そして（ステップ４１４）サーバ・データベースは売り手が口座による支払いが可能にされた支払いをすぐに受け入れることを反映するために更新される。
【００６８】
問合せ４１８の結果が、売手が仮想口座による支払いが可能にされた支払いを受け入れるということである場合は、ステップ４２０で、買手は、売手が仮想口座による支払いが可能にされた支払いを受け入れることを反映するために、支払勘定ファイル内の支払タイプを変更することを通知される。この実施態様では、サーバ・データベースに格納される支払タイプは支払勘定ファイルに含まれる支払タイプに勝つ。ステップ４１４で、サーバ・データベースは、売手が口座による支払いを受け入れることを反映するために更新される。
【００６９】
問合せ４１６の結果が、売手が口座による支払いが可能にされた支払いを受け入れるということである場合は、問合せ４２２が行われる。問合せ４２２において、売手が仮想口座によりなされる支払いを受け入れるかどうかの決定が行われる。問合せ４２２の結果が否である場合は、売手は仮想口座による支払いを受け入れず、そしてステップ４２４で、買手は、売手が口座による支払いが可能にされた支払いを受入れるが、仮想口座による支払いを受け入れなかったと通知される。ステップ４２６で、買手および売手に固有である仮想口座を作成するための承認が買手から受け取られる。ステップ４２８で、買手および売手に固有である仮想口座が作成される。さらに、サーバ・データベースの情報は、売手が仮想口座による支払いが可能にされた支払いを受け入れるという変更を反映するために更新される。
【００７０】
売手に対する買手の支払勘定は集計することができる。問合せ４２２が、売手が仮想口座による支払いが可能にされた支払いを受け入れることを示す場合は、ステップ４３０で、売手または買手の支払勘定は集計される。ステップ４３２で、仮想口座の信用限度は、売手に対する買手の集計された支払勘定に合致するように調整または設定される。問合せ４３４で、支払勘定の自動決済および自動清算が事前設定されたかどうかの決定が行われる。決済および清算が自動的に行われる場合は、ステップ４４０で、売手に対する買手の集計された支払勘定の額の清算取引は決済され、清算される。しかしながら、問合せ４３４が自動的な決済および清算が事前設定されなかったことを示す場合は、ステップ４３６で、売手は、集計された支払勘定の額の清算取引を含み、集計された額の決済および清算を要求し、そして注文書の関連指標を含む伝送を形成することを通知される。ステップ４３８で、注文書の関連指標を含む、集計された支払勘定の額の清算取引の伝送が売手から受け取られる。ステップ４４０で、集計された支払勘定の額の清算取引は決済されて清算される。
【００７１】
ステップ４４２で、受け取られた支払勘定ファイルおよび集計された支払勘定の清算取引は、前述の手段により監査される。ステップ４４４で、監査に関する報告は買手、売手、あるいは両方ともに送られる。
【００７２】
別の実施態様では、単一または数人の商人に対する消費者の単一またはいくつかの債務が受け取られ、そこでは債務の各々は商人の各々の対応する商人識別子を含む。商人識別子の各々に対して、第１通知が消費者に宛てられて、清算取引を下位口座により支払い可能にするために、発行人に、口座内に、対応する商人に固有である下位口座を発行させるように消費者に求める。下位口座の各々に対して、発行人が下位口座を発行したという確認が受け取られ、対応するそれぞれの商人に対する債務の各々は集計され、下位口座の信用限度は、対応する商人に対する集計された債務に合致して設定され、第２通知は対応する商人に宛てられて、清算取引と併せて下位口座の指標を含む伝送を形成するように対応する商人に求め、清算取引と併せて下位口座の指標は受け取られ、清算取引は下位口座の指標を用いて下位口座によって、支払い可能であるとして確認され、そして発行人は、清算取引が下位口座により支払い可能であると通知される。その後、取引決済、信用限度の使用可能期間の終了、口座サイクル、および勘定残高のような要因に基づいて、信用限度の更なる調整は残りの未済債務を反映するために行われ得る。対応するそれぞれの商人に対する消費者の単一またはいくつかの債務のための下位口座の使用の終了に続いて、下位口座は、例えば、指定された期間の後に別の商人に再利用できる。
【００７３】
支払処理システム
前述の説明のための背景的な情報として、支払システムの技術者によって容易に理解されるように、支払システムの支払取引のような取引は、それぞれ支払処理システムの構成要素であるいろいろな主体からの参加を含むことができる。例示的な支払処理システムは図５に支払処理システム５００として示されている。支払処理システム５００は、前記発行人のような発行人５０４、前記取引ハンドラのような取引ハンドラ５０６、前記アクワイアラのようなアクワイアラ５０８、前記商人のような商人５１０、および前記消費者のような消費者５０２を含む。アクワイアラ５０８および発行人５０４は取引ハンドラ５０６を通して通信できる。商人５１０は、アクワイアラ５０８、取引ハンドラ５０６、または発行人５０４と通信できる少なくとも１つのポイントオブサービス（ＰＯＳ）端末を利用できる。このように、ＰＯＳ端末は支払処理システム５００と通信動作を行う。
【００７４】
通常、取引は、商品またはサービスのための取引を開始するために、例えばコンピュータ端末または携帯用消費者向け装置５１２を用いることにより預金の口座番号を商人５１０に提示する消費者５０２から開始される。消費者５０２は個人または法人とすることができる。消費者５０２は、発行人５０４により発行される口座の口座名義人、例えば口座の共同名義口座名義人または法人口座にアクセスできる法人の従業員のような口座にアクセスできる人でもよい。携帯用消費者向け装置５１２は、支払カード、ギフトカード、スマートカード、スマートメディア、給与カード、保健医療カード、リストバンド、口座情報を含む機械可読媒体、キーチェーン装置（例えば、エクソンモービル社から市販されているＳＰＥＥＤＰＡＳＳ（登録商標）またはスーパーマーケット割引カード）、携帯電話、携帯情報端末、ポケットベル、社会保障カード、コンピュータ、アクセスカード、無線端末、またはトランスポンダを含むことがある。携帯用消費者向け装置５１２は、口座番号または口座名義人の名前のような情報を格納するために揮発性または非揮発性メモリを含むことがある。
【００７５】
商人５１０は、携帯用消費者向け装置５１２から口座の指標（例えば、預金の口座番号）のような口座情報を得るために、ＰＯＳ端末のような受入れポイント装置を使用できる。携帯用消費者向け装置５１２は、無線周波数を用いる非接触型システムのような任意の適切な電気、磁気、または光学的インタフェースシステム、磁場認識システム、または磁気ストライプ読取器のような接触型システムを含む機構を用いてＰＯＳ端末に接続できる。ＰＯＳ端末は取引許可要求を携帯用消費者向け装置５１２の発行人５０４に送信する。代わりに、または組み合わせて、携帯用消費者向け装置５１２は、発行人５０４、取引ハンドラ５０６、またはアクワイアラ５０８と通信できる。
【００７６】
発行人５０４は取引ハンドラ５０６を用いて取引を許可できる。許可は、発行人５０４、または、例えばビジネス・ルールを用いることにより、発行人５０４の命令に関連して取引を許可する、発行人５０４に代わっての取引ハンドラ５０６を含む。ビジネス・ルールは、取引ハンドラ５０６、消費者５０２、商人５１０、アクワイアラ５０８、発行人５０４、金融機関、またはそれらの組み合わせからの命令またはガイドラインを含むことができる。取引ハンドラ５０６は許可された取引のログまたは履歴を維持できる。一旦承認されると、商人５１０は許可を記録し、消費者５０２が商品またはサービスを受け取ることを可能にすることができる。
【００７７】
商人５１０は、その日の最後のような、とびとびの期間で、許可された取引のリストを支払処理システム５００のアクワイアラ５０８または他の構成要素に提出できる。取引ハンドラ５０６は、提出された許可された取引リストを許可された取引のそれ自体のログと比較できる。合致が見つかった場合は、取引ハンドラ５０６は、対応するアクワイアラ５０８からの許可取引額要求を各取引に関係する対応する発行人５０４へ送ることができる。一旦アクワイアラ５０８が発行人５０４から許可された取引額の支払いを受け取ると、それは支払いを商人５１０に手数料のような少ない取引コストで転送できる。取引が債務またはプリペイド・カードを含む場合は、アクワイアラ５０８は商人５１０に支払う前に頭金を待たないことを選ぶことができる。
【００７８】
前述のプロセスに断続的なステップがある場合があり、その幾つかは同時に起こる場合がある。例えば、アクワイアラ５０８は決済および清算プロセスを開始することが可能であり、それは取引の金額をアクワイアラ５０８に支払うことを可能にする。アクワイアラ５０８は、取引ハンドラ５０６から、取引が決済されて、清算されることを要求できる。決済は発行人５０４とアクワイアラ５０８の間での金融情報の交換を含み、清算は資金の交換を含む。
【００７９】
取引ハンドラ５０６は取引の決済および清算に関連してサービスを提供できる。例えば、クレジットを含む取引の決済および清算は取引の許可の後に行われ得る。取引の清算は、清算機関、例えば清算銀行などに預金のために、決済機関、例えば発行人決済銀行などから取引清算の金額を引き出す発行人５０４を含む。取引ハンドラ５０６は取引清算の金額をアクワイアラ決済銀行に預ける。対応するアクワイアラ５０８はアクワイアラ決済銀行から取引清算の金額を引き出す。通常、発行人５０４は発行人決済銀行を選び、取引ハンドラ５０６は清算銀行を選択し、そしてアクワイアラは決済銀行を選ぶ。取引がデビットを含むときに、決済は許可プロセスの間に行われ得る。このように、典型的取引は、決済および清算のための取引の処理を要求し、許可し、そして履行するためにさまざまな主体を含む。
【００８０】
実施態様が、ソフトウェア、ハードウェア、または両方の組合せを用いて、制御論理の形で、モジュールまたは集積化方式法であり得ることを理解すべきである。本願明細書において、開示される実施態様に関連して記載されている方法、プロセス、またはアルゴリズムのステップは、直接ハードウェアにおいて、プロセッサにより実行されるソフトウェアモジュールにおいて、または２つの組合せで実施され得る。
【００８１】
例えば、図６を参照すると、ブロック・レベル図は、売手に対する買手の債務を処理するための例示的なクライアント・サーバ環境を示している。サーバＳ（ｉ）６０２は、単一のサーバまたは地理的位置にわたって分散されたサーバ・ファームから成ることができる。サーバＳ（ｉ）６０２は、ＳＤＢ（Ｊ）６０４、例えばサーバ・データベースなどに接続されて通信できる。例えば、ＳＤＢ（Ｊ）６０４は複数のＳＤＢ（ｊ−Ｉ）６０４から成ることができる。サーバＳ（ｉ）６０２は、ネットワーク６０６を経由して少なくとも１つのクライアントＣ（ｋ）６０８に接続されて通信できる。ネットワーク６０６は、例えば、イーサネット（登録商標）ネットワーク、無線ネットワーク、ＬＡＮ、ＷＡＮ、グローバルエリア・ネットワーク、インターネット、ホームＰＮＡネットワーク、電力線通信ネットワーク、またはそれらの組み合わせでもよい。ネットワークは、ネットワーク・ノード、例えば、ブリッジ、ハブ、スイッチ、ルータ、またはネットワーク・インタフェース・カード（ＮＩＣ）などを相互接続するために、ハードウェア・ビルディング・ブロックを含むことができる。ビルディング・ブロックは、例えば、ガルバニック・ケーブル、マイクロ波中継装置、光ケーブルを経由して接続するか、または電波または電磁波などによって、無線で接続できる。
【００８２】
クライアントＣ（Ｉ）６０８は、クライアント・データベース、例えばＣＤＢ（Ｌ）６１０などに接続できる。ＣＤＢ（Ｌ）６１０は地理的に分散するか、または単一の位置にあることができる。
【００８３】
一実施態様では、取引ハンドラは、実行するときに図１〜４に示すステップを実施するコンピュータ実行コードの処理を容易にするために、サーバＳ（ｉ）６０２を利用できる。ＳＤＢ（Ｊ）６０４は、受け入れた債務、消費者識別子、商人識別子、受け入れた取引、および買手から売手への自動処理支払に関係する他のデータを格納できる。同様に、クライアントＣ（ｋ）６０８は情報を格納するためにＣＤＢ（Ｌ）６１０を利用できる。例えば、買手のＥＲＰは買手の支払勘定を格納するためにＣＤＢ（Ｌ）６１０と通信できる。
【００８４】
方法またはプロセスにおけるさまざまなステップまたは行為は、示される順序で実行するか、または別の順序で実行できる。さらに、１つ以上のプロセスまたは方法ステップは省略することができ、または１つ以上のプロセスまたは方法ステップは方法およびプロセスに加えられることが可能である。追加のステップ、ブロック、または動作は、方法およびプロセスの初め、最後、または介在既存要素に加えることができる。本願明細書に提供されている開示および教示に基づいて、当業者は他のやり方および／またはさまざまな実行のための方法を認めるはずである。
【００８５】
本願明細書に記載されている実施例および実施態様が例示するためのためであり、そしてそれを踏まえたさまざまな変更態様または変化が当業者に示唆されて、本出願の精神および範囲ならびに添付の特許請求の範囲の中に含まれると理解される。
【図１】
2010509699.tif 000003
【図２】
2010509699.tif 000004
【図３】
2010509699.tif 000005
【図４】
2010509699.tif 000006
【図５】
2010509699.tif 000007
【図６】
2010509699.tif 000008
【国際調査報告】
2010509699.tif 000009