JPH09504634A - 電子請求支払いシステム - Google Patents

Abstract

(57)【要約】 参加消費者（１２）が、事前に設定された規則（１０４）に従って動作する支払いネットワーク（１０２）を介して参加請求者（１４）に請求額（３０）を支払う請求支払いシステム（第４図）。参加消費者（１２）は、金額および固有の請求者識別番号（１２０）を示す請求書（３）（紙／郵便の請求書、Ｅメールの通知、自動債務のための暗黙的な請求書）を参加請求者（１４）から受領する。消費者（１２）は、送金を許可するために、支払日、支払額、消費者の請求者（１４）との口座番号、資金源（２３２）、請求者（１４）の請求者識別番号を示す請求支払い命令（１２２）を直接、あるいはこれらのデータ要素を含む静的データを参照することによって参加銀行（１６）へ送信する（２）。次いで、銀行Ｃ（１６）は支払いネットワーク（１０２）へ支払いメッセージ（１２４）を発行し、支払いネットワーク（１０２）は、請求者参照番号を割り当て、支払いメッセージを請求者銀行（１８）へ転送する（２６８）。清算のために、消費者の銀行（１６）は消費者（１２）の口座の借方に記入し、支払いネットワーク（１０２）とのネット位置を指定される。同様に、請求者の銀行（１８）は、支払いネットワーク（１０２）からネット位置を受領し、請求者の当座預金（２６８）の貸方に記入する。消費者の銀行（１６）が破棄不能な支払いメッセージ（１２４）を送信することに合意している場合、保証支払いネットワーク（１０２）の場合には、消費者の銀行（１６）は、資金が良好でない場合に損失を被るリスクを冒すこと希望していないかぎり、資金が良好なものとなるまで取引を発行しない。

Description

【発明の詳細な説明】 電子請求支払いシステム 発明の背景 本発明は、消費者がその銀行、または銀行の代理店、またはノンバンク請求支 払いサービス・ビューローに、小売業者、サービス提供業者、消費者に支払うべ き額を請求するその他の請求者から請求された額を支払うよう命令できるように する電子請求支払いシステム（「請求支払い」）の分野に関する。 多数の消費者は、小切手によって公共事業会社、小売業者、サービス提供業者 （「請求者」）への支払いを行い、小数の消費者は非小切手手段を使用して請求 者への支払いを行う。「消費者」の語は、本明細書では主として、公共事業顧客 であるか、税金を支払う納税者であるか、ローンを支払う借り手であるかにかか わらず、請求額を支払う人または実休を指し、人であっても、企業実体であって もよい。本明細書では、消費者は「顧客」とは区別される。なぜなら、この語は 場合によっては、請求者がその銀行（「請求者銀行」）の顧客であり、消費者が その銀行（「消費者銀行」）の顧客であり、消費者がノンバンク請求支払いサー ビス・ビューローの顧客である可能性もあるという点で、請求支払いシステムの 多数の当事者を指すからである。混乱を避けるために、請求払い実体を「消費者 」と呼び、「請求者」は、支払いを受けるべき実体とする。 請求者は、多くの場合、各取引ごとに少額を請求し、封筒の開封、消費者の口 座番号のデータ取り込み、小切手額のＭＩＣＲ（磁気インキ文字認識）コード化 などの送金処理に対処するアテンダント・オーバヘッドを含め、多数の小切手を 処理する費用を負わなければならない。請求者は、項目を処理する費用が低くな るように、送金処理に関する多大な業務に着手しており、多くの場合、請求者に 対する支払いを処理し預かり、取り込んだ消費者データおよびＭＩＲコード化小 切手を請求者に供給し、請求者がそれを預かる「ロックボックス」業務を外注し ている。請求者が消費者の小切手と共に返送することを要求する支払いクーポン には多くの場合、クーポン上でのスキャンラインの設計および配置のために電子 的に取り込むことができる、データ・ライン（口座番号、請求額など）を備える スキャンラインが事前に印刷される。たとえば、必要な情報は、バー・コード、 あるいはその他の機械的または電子的に読取り可能な形態でクーポン上に提供す ることができる。このため、クーポンは今日の送金処理システムで重要な役割を 果たしている。 規模の経済性が与えられた場合、請求者は送金処理のコストを低減させる強い 動機を有し、さらに重要なことには、請求者は、「例外項目」のコストを低減さ せるこれよりもずっと強い動機を有する。例外項目とは、何らかの理由で、送金 を迅速に処理するために請求者によって所定の位置に配置された高度に自動化さ れた手順では処理できない支払いである。例外項目には、支払いクーポンなしで 受領された小切手、小切手なしで受領された支払いクーポン、対応するクーポン 上に示された額とは異なる額用の小切手、単一の小切手を含む封筒で受領された 複数の支払いクーポンが含まれる。典型的な支払いの取引を処理するコストは大 量の効率的な送金処理業務では取引当たり０．０９ドルないし０．１８ドルであ るが、例外項目の取引のコストは０．６５ドルないし１．５０ドルにもなる。 興味深いことに、消費者が請求支払いサービス・ビューロー、すなわち銀行ま たはノンバンク・サービス・ビューローを使用することなどの代替送金形態を試 みることを決定すると、そのような送金項目は通常、今日の大部分の請求者の例 外項目であるので、請求者のコストが大幅に増大する。請求支払いサービス・ビ ューローは請求支払いサービスを消費者に提供し、それによって消費者はサービ ス・ビューローに請求者に支払いを行うよう命令する。支払いの発送は通常、電 子的に行われるので、送金は通常の方法、すなわち請求者が提供した封筒に小切 手および支払いクーポンのみが入ったものとしては請求者に提供されない。その 代わり、請求者は通常、消費者の当座勘定上に振り出され、消費者の請求者との 口座番号と消費者の当座勘定番号をコード化するＭＩＣＲデータを示す、サービ ス・ビューローによって印刷された小切手を受領する。いくつかのケースでは、 サービス・ビューローが消費者から資金を得、次いで、小切手の額を消費者の請 求者との口座の貸方に記入する命令によってサービス・ビューローの口座上に振 り出された小切手を請求者に提供する。他のケースでは、支払いは電子振替であ り、消費者の会計情報が振替と共に含まれ、あるいはサービス・ビューローから 請求者に提供される複数の消費者からの支払いのリストに提示される。 いずれの場合も、このような取引は、支払いクーポンが提供されないので、請 求者の例外項目であり、したがって請求者に対する追加費用を必要とする。請求 者には残念なことに、電子支払い、およびサービス・ビューローの使用が普及し ており、支払いクーポンなしで電子支払いを効果的に処理する「非例外」機構を 使用しないかぎり、例外項目の割合が増加している。消費者の銀行が請求支払い サービス提供業者ではなく、あるいはサービス・ビューローと協力しない場合、 消費者の銀行がそれ自体に強制されるこのような例外的な取引に適応するように 小切手提示交換プロセスを修正しなければならないので、消費者の銀行のコスト も増大する。 同じ請求者に請求額を支払う、サービス・ビューロー自体のサービスの多数の 顧客を有することができる大規模な支払いサービス・ビューローを用いた場合、 その請求者は多くの場合、送金が単一の小切手の一部である消費者に関する口座 番号および額のリストと共に、多数の顧客用の１枚の小切手を受領する。請求者 は次いで、このリストを手作業で調べ、口座番号が正しいことを検証し、次いで このデータを請求者の会計システムに取り込まなければならない。したがって、 ますます多くの消費者がこの代替支払い手段を使用するようになった場合、例外 である送金の割合が増加し、取引当たりの平均コストが増大する。 提案された多数の請求支払いシステムでは、消費者および請求支払いシステム ・オペレータ以外の当事者のコストがほとんど、あるいはまったく考慮されてい ない。たとえば、米国特許第５２２０５０１号は、請求支払いシステム・オペレ ータが小型のテキスト・ディスプレイを有する電話を使用して消費者支払い指示 を取り込む請求支払いシステムについて詳しく説明している。このような消費者 請求支払い指令は、システムが操作する中央コンピュータへ送信され、中央コン ピュータは次いでＡＴＭネットワークを使用して、消費者のＡＴＭアクセス可能 当座勘定から支払い額分の資金を得る。システム・オペレータの口座に資金が取 り込まれた後、システムは、請求者にどのように支払うか、すなわち請求者の当 座勘定番号を使用する有線借方記入ネットワークか、それともチェック・アンド ・リストかを決定する。米国特許第５２２０５０１号のシステムは、システム・ オペレータ（すなわち消費者に対する請求支払いサービスのサービス提供業者） 、に非常に有益なものとして提供されるが、消費者、消費者の銀行、請求者に対 する望ましい効果がより低い。 米国特許第５２２０５０１号のシステムを用いた場合、システム・オペレータ が引き落としを行ってから、請求者への支払いを行うまでの間に倒産した場合に 消費者が損失を受ける恐れがある。システムは、請求者への支払いが命令される 数日または数週間前に消費者が識別した請求者に支払いを行うようにセットアッ プされているに過ぎないので、消費者は、以前のベンダには請求額を容易に支払 うことができない。これには２つの理由がある。第１に、消費者データ入力用の 米国特許第５２２０５０１号の装置は、請求者を登録するために請求者データを 入力するキーボードが複雑すぎるため、簡単な装置を必要とするユーザ向けのも のであり、実際には消費者は、おそらく名前および住所によって請求者を識別す る用紙をシステム・オペレータに提出する。システム・オペレータが誤った請求 者を識別する恐れがあり、かつ請求者が類似の名前と類似の住所の下で営業して いる可能性があるので、この識別は厳密なものではない。 上記システムによる各取引が請求者の例外項目であり、また、サービス・ビュ ーローが誤りを犯した場合、誤って課された支払いに関する苦情を訴える消費者 からの電話は請求者へくるので、請求者は米国特許第５２２０５０１号などのシ ステムを好まない。請求者は、メール・オーダー会社が前払いに対する料金を低 くし、小売店が現金払いに対する料金を低くするのとまったく同じように、追加 経費をカバーするためにサービス料金を追加しようとすることができるが、問題 は、請求者がどの送金が通常どおり行われ、どの送金が請求支払いサービスを介 して行われるかを知らないことである。例外項目のコストを消費者に移し、ある いは取引のコストを低減させる簡単な手段が必要である。そうすれば、消費者が 例外項目であることを主張する場合、請求者はそのコストを回復することができ 、消費者と請求者の両方の利益が満たされる。 請求者が消費者の銀行に借方記入要求を提出するための事前許可を消費者から 得ることや、例外項目を請求者の自動送金処理システムまたはロックボックスに よって処理できる形態として処理することを専門とするサービスなど、例外項目 の高コストに対するいくつかの他の解決策が提案されている。しかし、これらは 十分な解決策ではない。前者の解決策は、消費者の当座勘定からの資金の引き落 としに対する消費者の制御がほとんど与えられず、特定の消費者から特定の請求 者への再発支払いに有用であるに過ぎず、これに対して、後者は通常の送金処理 コストに追加コスト（ただし、通常、例外処理コストよりも低い）を加える。い くつかのケースでは、少額の再発支払いの場合、請求者の商品またはサービスが 消費者に提供される唯一の方法は、事前に許可された借方記入である。 下記で、従来技術で提案されたいくつかの請求支払いシステムまたは送金処理 システムについて説明するが、最初に請求支払いのある種の背景を提示する。話 しを簡単に、かつ明確にするために、本明細書では消費者の請求者との口座をＣ −Ｂ（「消費者−請求者」）口座と呼び、それによってこの取引を他の口座、す なわち、消費者の銀行との口座、請求者の銀行との口座などと区別する。大部分 のケースでは、請求者はＣ−Ｂ口座番号を使用して請求者の記録中で消費者を一 意に識別する。 しかし、行われる請求支払いは明白なものであり、あるいは取引の性質によっ て暗示することができるいくつかの共通要素を有する。第１の要素は提示であり 、請求者は、Ｃ−Ｂ口座番号および支払額を示す請求書を消費者に提示する。第 ２の共通要素は支払い許可であり、消費者は消費者の銀行が資金を消費者の口座 から請求者へ振り替えることを許可する何らかの行為を実行する（たとえば、小 切手または交渉可能な証書に署名する）。この要素は、（事前に許可された引き 落としの場合のように）提示の前後に発生することがあり、明白なものである必 要はない（小切手を供給することは、その小切手の額に対する暗黙的な許可であ る）。この要素はほぼ常に、消費者の当座勘定からの資金の引き落としや、消費 者のクレジット・カード口座または信用限度に対する額の登録など、消費者から 消費者の銀行への支払いを保証するための消費者の銀行による何らかの措置が伴 う。第３の共通要素は、資金が引き落とされたことの消費者への確認である。第 ４の共通要素は、Ｃ−Ｂ口座への支払いの貸方記入である。いくつかのケースで は、請求者は単に期限経過証書を送信することをやめることによって貸方記入を 肯定す る。 第１図ないし第３図は、この４つの共通要素をそれぞれの異なる方法で実施す る既存の請求支払いシステムのブロック図を示す。これらのブロック図では、参 加者は楕円形で示され、マテリアルの流れは、通常フローが発生する順序を大ざ っぱに示す番号付き矢印で示されている。矢印は、リンク、すなわち手形のフロ ーの物理的リンク、またはある地点から他の地点へのデータ通信チャネル、また はマテリアルを振り替えるその他の手段を具体的に表現したものである。フロー のいくつかの代替フローが存在する場合、代替フローは”２”や”２Ａ”など、 共通の番号とそれに付加された文字で示すことができる。「マテリアル」とは、 紙をベースとするもの（「郵便」）か、それとも電子転送媒体（Ｅメール、メッ セージ、パケットなど）であるか、それとも他の転送媒体であるかにかかわらず 、文書または情報、あるいはその両方を指す。大部分のケースでは、流れるマテ リアルは、マテリアルの発信元と宛先をリンクする矢印の近くに示されている。 第１図は、従来型の手形請求支払いシステム１０のブロック図であり、この場 合、請求者が請求書またはクーポン綴りを送り、消費者が小切手および支払いク ーポンを返信する。今日の大部分の請求支払いはこのように行われているので、 このような送金の証明・取り込みプロセスは、いわゆる「例外項目」の場合を除 いて、高度に自動化される。 請求支払いシステム１０では、参加者は、消費者Ｃ（１２）、請求者Ｂ（１４ ）と、消費者Ｃの銀行（銀行Ｃ）１６と、請求者Ｂの銀行（銀行Ｂ）１８と、任 意選択でロックボックス・オペレータ２０である。銀行Ｃは、消費者Ｃの当座勘 定２２および交換勘定２４を維持し、これに対して銀行Ｂは、消費者Ｂの当座勘 定２６および交換勘定２８を維持する。参加者間で交換するマテリアルは、請求 書３０と、小切手３４と支払いクーポン３６とを備える送金３２と、確定勘定書 ３８と、受取勘定（”Ａ／Ｒ”）データ・ファイル４０と、コード化小切手、す なわちＭＴＣＲコード化を含む小切手３４と、場合によっては資金不十分（”Ｎ ＳＦ”）通知４６とを含む。 請求支払いシステム１０中の参加者間の資料のフローは、請求者Ｂが消費者Ｃ への郵便を通じて請求書３０を送ったときに開始する（矢印１）。請求書３０は 、 Ｃ−Ｂ口座番号および請求額を示す。通常、消費者Ｃが保持すべき仕送り状部分 と返信すべき支払いクーポン部分に分割されている。それぞれに、Ｃ−Ｂ口座番 号および請求額が示されている。 消費者Ｃは、請求書３０を受信したことに応答して、請求者Ｂに送金書３２を 送る（矢印２）。送金書３２は、好ましくは請求者Ｂによって提供された返信封 筒に含まれる、銀行Ｃにある消費者Ｃの口座２２上に振り出された小切手３４と 、支払いクーポン３６とを含む。請求者Ｂは次いで、送金の額を小切手３４上に ＭＩＣＲコード化して、コード化小切手４４を作成し、小切手４４を預かり（矢 印３）、顧客Ｃの口座を請求者Ｂの顧客総勘定元帳（”Ｇ／Ｌ”）会計データベ ース４２の貸方に記入する。また、送金書３２がロックボックス・オペレータ２ ０に郵送され（矢印２Ａ）、ロックボックス・オペレータが送金書３２を開封し 、小切手３４をＭＩＣＲコード化してコード化小切手４４を作成し、Ｃ−Ｂ口座 番号および小切手額を電子的に取り込んでＡ／Ｒデータ・ファイル４０を作成す る。ロックボックス・オペレータ２０は次いで、Ａ／Ｒデータ・ファイル４０を 請求者Ｂへ送り、コード化小切手４４を銀行Ｂへ送り、請求者Ｂの口座２６の貸 方に記入させる（矢印３Ａ）。小切手４４は、消費者Ｃによって署名されるので 、銀行Ｂが小切手を銀行Ｃに提示した後に銀行Ｃが小切手の額を銀行Ｂに送るこ とが許可される。署名された小切手は、請求支払い取引の第２の共通要素、すな わち許可として働く。 コード化小切手４４がどのように銀行Ｂに到達するかにかかわらず、銀行Ｂは 次いで、銀行Ｃの口座上に振り出され銀行Ｂが受領した他の小切手と共に、小切 手４４を銀行Ｃに提示する（矢印４）。銀行Ｃは、小切手４４を受領すると、Ｃ の口座２２から小切手の額を引き落とし、この資金を銀行ＢにあるＢの口座に振 り替える（矢印５）。実際には、この資金振り替えは、場合によってはチェーン （話しを明確にするために省略してある）中の中間清算銀行によって、Ｃの口座 ２２から交換勘定２４へ、交換勘定２４から交換勘定２８へ、次いでＢの口座２ ６へと行われる。 小切手４４の額をカバーする資金がＣの口座２２になく、あるいはＣの口座が 封鎖されている場合、銀行Ｃが小切手を銀行Ｂに返し、銀行Ｂがその小切手を請 求者Ｂに返す。請求者Ｂは次いで、Ｇ／Ｌデータベース４２における消費者Ｃの Ｃ−Ｂ口座の貸方に記入する取引を破棄し、消費者Ｃからの支払いを再交渉する 必要がある。これらはすべて、請求者Ｂのかなりのコストを伴う。小切手４４が 清算される場合でも、小切手４４は請求者Ｂから銀行Ｂへ、銀行Ｂから銀行Ｃへ と物理的に移動しなければならないので、資金を請求者Ｂに提供するプロセスは 時間がかかる。もちろん、請求者Ｂが銀行Ｂに十分な信用等級を有する場合、銀 行Ｂは、小切手４４を受領した際に資金を交換勘定２８からＢの口座２６に移す ことができる。 小切手４４が交換された後ある時点で、請求者Ｂが、消費者ＣのＣ−Ｂ口座の 貸方への記入が行われるようにＧ／Ｌデータベース４２中の請求者ＢのＡ／Ｒ記 録も更新し、銀行Ｂが、小切手４４の額が引き落とされたことを確定勘定書３８ 上にリストし、あるいはキャンセル小切手４４を返送し、あるいはその両方を行 うことによって、小切手４４の額が引き落とされたことを消費者Ｃに確認する。 小切手が清算されない場合、請求者Ｂおよび取引のその他の当事者はこの支払い を終了する。 請求支払いシステム１０の１つの利益は、ほぼすべての請求者に関して、請求 者を登録する必要がないことである（消費者は事前の協定や待ち時間なしで請求 者に支払いを行うことができる）。しかし、請求支払いシステム１０には多数の 欠点が存在する。消費者Ｃは、請求者Ｂなど個別の請求者に支払いを個別に郵送 し追跡しなければならない。請求支払いシステム１０は、資金の可用性が確認さ れる前に矢印４に到達しなければならない。資金が確認できない場合、銀行Ｃ、 銀行Ｂ、請求者Ｂのコストで取引の進行を破棄しなければならない。そのような システムでは、振り替えのタイミングが、請求者Ｂがいつ送金書３２を受領し処 理するかと、銀行Ｂがいつ請求者Ｂから小切手４４を受領するかに依存するので 、消費者Ｃは資金がいつ振り替えられるかを制御することができない。 前述のシステムの変形例は、北ヨーロッパのいくつかの国で使用されているＧ ＩＲＯシステムである。ＧＩＲＯシステムは、政府または郵便システム、すなわ ち伝統的な金融サービス供給業者によって北ヨーロッパに導入された。ＧＩＲＯ システムでは、各請求支払人および各請求受取人にＧＩＲＯ番号を割り当てなけ ればならない。請求者は、支払いクーポン上の請求者ＧＩＲＯ番号と共に請求書 を送る。ＧＩＲＯ支払いクーポンのレイアウト、形状なども義務的なものであり 、したがって、消費者は各請求書ごとに類似のクーポンを受領する。消費者は、 請求書を受領した後、単にＧＩＲＯ番号を支払いクーポンに付加し、それに署名 する。したがって、支払いクーポンは小切手に類似の銀行証書としても働く。 支払いクーポンがすべて同様なものなので、ＧＩＲＯシステムにおける消費者 にとってこのシステムは好ましい。消費者は、支払いクーポンをＧＩＲＯ中央プ ロセッサまたは消費者自体の銀行へ郵送し、次いで、ＧＩＲＯ中央プロセッサま たは銀行は、そのクーポンを請求者ＧＩＲＯ番号によってソートし請求者に提出 する。支払いクーポンはすべて固定フォーマットなので、請求者が事前にクーポ ン上に印刷した支払い額を含め、機械読取り可能なフォーマットで容易にコード 化することができる。消費者がそのＧＩＲＯ番号を請求者に与える場合、請求者 はその番号を事前に支払いクーポンに印刷することもできる。すべてのクーポン が同様なものなので、銀行はそれらを小切手と同様に処理し規模の経済性を達成 することができる。 ＧＩＲＯシステムは、効率的な送金処理のための部分的な解決策となる可能性 はあるが、十分なものではない。さらに、北ヨーロッパでは、調和を図る必要が ある請求者が比較的少ないのに比べて、米国では、調和を図るべき請求者が多い ので、このシステムは米国には適していない。そのような国では、支払いシステ ムにおいて政府がより積極的な役割を果たすので、請求者が小数である場合でも 、請求者の調和を図りすべての請求者に請求書用に固定フォーマットを使用させ る方が容易である。また、米国の消費者は、当座預金をより容易に利用すること ができるので、そのようなシステムを必要とする可能性が低い。 請求者に関しては、依然として請求支払いシステム１０の問題がある。ただし 、小切手がクーポンであるので小切手またはクーポンがなくなる問題はそれほど 発生しない。請求者は依然として、手形の振替、清算されない小切手などに対処 しなければならない。また、システムが流動資金を供給されるので、請求支払い の当事者の、コストを他の当事者と釣り合わせようとする意識は低い。しかし、 米国では、１日の流動が請求支払いシステムの参加者にとって受け入れられない コ ストとなることがあり、そのため、競争レートが得られない。銀行は、ＧＩＲＯ サービスに対して料金を課さず、参加者のコストを低減する権限も、コストを最 適なコスト・アブソーバに移す権限も有さないので、消費者の銀行も請求者の銀 行も、他の銀行よりも低い料金を課し、したがってより大きなシェアを求めて競 争できるようにより効率的になるという動機を有さない。 第２図は、請求支払いシステム１０に対して消費者Ｃの側で必要とされる労力 を低減させるが、請求者に対するコストを増大させる代替請求支払いシステム５ ０のブロック図である。請求支払いシステム５０と請求支払いシステム１０との 間の差は、消費者Ｃが支払いを電子的に（あるいは非小切手手段によって）開始 することである。 請求支払い手段５０は、請求支払いシステム１０の参加者と同じ参加者のうち の大部分、すなわち、消費者Ｃと、銀行Ｃと、銀行Ｂと、場合によってはロック ボックス・オペレータ（第２図には図示せず）と、通常このシステムではプロア クティブな参加者でも、自発的な参加者でもない請求者Ｂとを含む。また、サー ビス・ビューローＳ（５２）および銀行Ｓ（５３）が参加者であり、サービス・ ビューローＳは、請求支払い命令を請求者に合致させるために使用されるサービ ス・データベース５４を維持する。参加者間で振り替えられるマテリアルには、 前例と同様な請求書３０と、請求支払い命令５６および関連する受領確認６６（ 共に電子的に送信される）と、登録パッケージ５７と、請求者確認５８と、小切 手６２を含む請求支払い６０（「チェック・アンド・リスト」）とが含まれる。 請求支払いシステム５０では、消費者Ｃは、空白小切手（volded check）とＣ に代わってＳが支払いを行うべき請求者のリストとを備えるサービス・ビューロ ーＳ登録パッケージ５７を送る（矢印１）ことによって請求支払いシステム５０ に登録される。Ｓは続いて、Ｃが実際にＢの顧客であることを検証する（矢印３ ）請求者確認５８を請求者Ｂへ送る（矢印２）。 請求支払いシステム１０（第１図）を用いた場合、消費者Ｃは、送金封筒およ び支払いクーポンによって適当な請求者を識別する。請求支払いシステム５０の サービス・ビューローＳは、送金封筒を利用することも支払いクーポンを利用す ることもできない。したがって、サービス・ビューローＳは、各請求支払い命令 ごとの正しい請求者を何らかの他の方法で識別しなければならない。通常、サー ビス・ビューローＳは請求者Ｂの名前、住所、電話番号、消費者Ｃの請求者Ｂと の口座番号（「Ｃ−Ｂ口座番号」）を消費者Ｃに求めることによってこれを行う 。銀行Ｃもサービス・ビューローＳも請求者Ｂとの会計関係を有することができ ないので、請求者Ｂの情報をサービス・データベース５４に登録するために使用 される登録パッケージ５７を消費者Ｃが作成する際の正確さに依存しなければな らない。通常、サービス・ビューローＳがこの情報を必要とするのは一度だけ、 すなわち請求者登録時に、この情報を、後で同じ請求者への支払いと共に使用で きるようにサービス・データベース５４に記憶するときだけである。もちろん、 この情報が変更された場合、サービス・データベース５４は古いものとなる。こ の情報が最初から誤っており、あるいは変更後に誤ったものとなった場合、サー ビス・ビューローＳは誤った実体へ資金を送る可能性がある。サービス・ビュー ローが多くの場合に、請求者識別の誤りを低減させるために行うことは、消費者 が、請求者を登録してから指定の期間にわたって請求者への支払いを行えないよ うにし、かつサービス・ビューローＳが、請求者確認メッセージ５８中の請求者 Ｂおよび請求者ＢとのＣ−Ｂ口座を確認できるようにすることである。 後のある時点で、消費者Ｃは請求書３０を受領し（矢印４）、請求支払い命令 ５６を開始する（矢印５）。請求支払い命令５６は、サービス・ビューローＳが 請求額３０を支払うためにＣの口座２２から資金を引き落とすための許可と、支 払い額（必ずしも請求書３０上の満期支払額ではない）と、支払日と、請求者Ｂ の受取人としての何らかの表示とを含む。サービス・ビューローＳは、請求支払 命令５６が受領された（矢印６）ことを示す受領確認６６によって応答する。消 費者Ｃは、自動金銭受け払い機（ＡＴＭ）、またはビデオ・タッチ・スクリーン 、またはスクリーン・フォン、または音声応答装置（ＶＲＵ）と対話する電話タ ッチトーン^TMパッド（ＴＴＰ）を介して、直接あるいは他のデータ・ネットワー クのパケットを通じて、パーソナル・コンピュータおよびモデムを使用すること など、いくつかの方法で請求支払命令５６を送信することができる。これがどの ように行われるかにかかわらず、サービス・ビューローＳは１つまたは複数の請 求支払い命令を消費者Ｃから受領する。これらの命令は、請求に関するある額を 支 払い、あるいは固定金額を定期的な間隔で支払うことを求める命令であってよい 。 消費者Ｃが請求支払い命令５６によって支払いを行いたい請求者が請求者Ｂで あることをサービス・ビューローＳが正しく識別し確認したと仮定すると、サー ビス・ビューローＳは次いで、送金をカバーする資金を確保した後、その資金を 請求者支払い６０として請求者Ｂへ送る（矢印１２）。請求支払いは、後述のい くつかの形を取ることができる。第２図には、当技術分野で一般的な「チェック ・アンド・リスト」が示されている。チェック・アンド・リストは、単一の支払 いと、サービス・ビューローＳの口座７０上に振り出された小切手６２とを備え 、単一の小切手に個別の送金が集計されたすべての消費者のリストを伴う。この リストは、合計で単一の小切手６２となるはずであるリストに含まれる各消費者 ごとのＣ−Ｂ口座番号および支払い額を示す。このプロセスは、サービス・ビュ ーローＳにある種の規模の経済性をもたらす。ただし、請求者Ｂに追加経費が課 される。いくつかのケースでは、請求者Ｂは、リストが小切手の額に合致するこ とを確認するためにリスト全休を検査する経費を許容するのではなく、その形の 支払いを拒絶する。 サービス・ビューローＳは、資金を確保するために、銀行Ｓ５３を介して、銀 行ＣにあるＣの口座２２上に振り出された小切手４４を清算する（矢印７ないし １１）。Ｓは次いで、支払い６０を請求者Ｂへ送る（矢印１２）。請求者Ｂは、 支払い６０を例外項目として処理し、請求支払いシステム１０とは異なり支払い クーポンではなく、リストからＧ／Ｌデータベース４２への登録を行わなければ ならない。請求者Ｂは、小切手６２を銀行Ｂに預け（矢印１３）、銀行Ｂは、銀 行Ｓおよび清算勘定７１を介してこの小切手を清算しＢの口座２６用の良好な資 金を得る（矢印１４ないし１７）。このサイクルは、請求支払い命令５６に入力 された額の資金がＣの口座２２から引き落とされたことを示す通知を消費者Ｃが 受領したときに完了する（矢印１８）。 請求支払い取引が終了した場合、銀行Ｃは、消費者Ｃへ確認（通常、報告３８ ）を送ることによって、取引が終了したことを確認する。しかし、何らかの理由 で取引を送り返すことが必要になることがある。サービス・ビューローＳは、消 費者Ｃによって提供された情報から請求者Ｂを識別できない場合、取引を破棄す る。 請求者Ｂが誤って確認され、あるいはサービス・ビューローによって提供された Ｃ−Ｂ口座番号が有効ではない場合、矢印１２の後で取引が破棄され、消費者Ｃ およびサービス・ビューローＳがかなり混乱し、請求者Ｂがコストを負う。いく つかのケースでは、請求者Ｂは取引を破棄しようとせず、その代わりに、消費者 Ｃが要求するまで資金を保持する。さらに、資金が良好なものでない場合は、請 求者Ｂに追加コストが課され、資金がサービス・ビューローＳを通過し、続いて Ｓが請求者Ｂへ資金を振り替える前に倒産した場合は消費者Ｃが損失を受ける可 能性がある。 請求支払いシステム５０は他の欠点を有する。たとえば、Ｃの口座２２からの 引き出しに対する許可は、支払い時に、あるいは将来の支払いのために事前に、 Ｃによって与えられる。サービス・ビューロＳが、要求を処理する時間を確保す るには、多くの場合、サービス・ビューロＳが支払いを処理することに合意する 数日の窓が必要である。このため、消費者Ｃは、この継続時間にわたって、口座 ２２に良好な資金を残しておくように求められる。 請求支払いシステム５０の他の問題は、サービス・ビューローＳが、どの請求 者に対してどの支払い方法を使用すべきかを決定しなければならないことである 。チェック・アンド・リスト手法は、請求者Ｂがその負担を負うことを拒絶する ため、あるいはその他の理由で、請求者Ｂには有効でないことがある。前述の請 求支払いプロセスは基本的に、支払いプロセスにおけるある当事者と次の当事者 との間の一連の双務的協定であり、終端間の協定はなく、したがってサービス・ ビューローＳと請求者Ｂなど２つの当事者間の協定が、資金を消費者から請求者 へ確実にかつ廉価に振り替えるうえで有効であることは保証されない。たとえば 、消費者Ｃはサービス・ビューローＳと協定を結ぶことができるが、サービス・ ビューローＳと銀行Ｃは依然として互いのことを知らない。サービス・ビューロ ーＳおよび銀行Ｃは一般に常に請求者Ｂのことを知らず、そのため、請求者Ｂへ の多数の異なる経路が存在する必要がある。 請求支払いシステム５０の消費者Ｃは、支払いが送られたことを示すサービス ・ビューローＳからの１つの確認と、取引が完了したことを示す銀行Ｃからの別 の確認と、場合によっては、請求者ＢがＧ／Ｌデータベース４２中の消費者Ｃの 口座の貸方に記入したことを確認する請求者Ｂからの第３の確認にも対処しなけ ればならない。消費者Ｃは、口座２２を十分に制御することもできない。サービ ス・ビューローＳが支払い情報および再発支払い情報しか維持せず、銀行Ｃがそ の情報を有さないので、サービス・ビューローＳがある情報を有し、銀行Ｃが残 りの情報を有するため、消費者Ｃは、資金源となった口座の状況の完全な報告を 提供するために１つの実体に依存することはできない。 今日では、第２図に示したシステムのいくつかの変形例が使用されている。一 変形例では、Ｓは請求支払い命令５６に応答して、Ｃの口座２２に振り出された 個別の小切手４４（署名なし−ファイル上の署名）を請求者Ｂへ送る。これは、 請求支払いシステム１０の場合と同様に清算される（第１図、矢印３ないし７） が、これらは例外項目なのでＢはこれらを一度に１つずつ処理しなければならな い。このため、小切手４４が、予想される支払い形式とは、クーポンがないとい う点が異なるに過ぎないので、Ｂが小切手４４の処理を拒絶する可能性は低減さ れる。したがって、請求者Ｂがチェック・アンド・リストを介するこの支払い形 態を拒絶する可能性は低く、請求者が、リストの帳尻が合わず、あるいは不良口 座番号を有するという問題を有する可能性は低い。 第２の変形例では、Ｓは、銀行Ｃからの小切手を銀行Ｓを介して清算してＳの 口座７０の貸方に記入するのではなく、銀行Ｓに自動手形交換所（”ＡＣＨ”） を介してＣの口座２２に借方記入要求を提出させる（第３図および添付の本文を 参照されたい）。第３の変形例では、Ｓは、矢印１２ないし１７（「チェック・ アンド・リスト」）の代わりに、ｉ）銀行ＳからＡＣＨへ、ＡＣＨから銀行Ｂへ 、銀行Ｂから請求者Ｂへ、またはｉｉ）マスタカードのＲＰＳ（送金処理システ ム）から銀行Ｂへ、銀行Ｂから請求者Ｂへのうちの一方の経路を通じてＡ／Ｒデ ータおよび貸方記入要求を請求者Ｂへ送信することができる。ＲＰＳは、本明細 書ではＡＣＨの代替策に過ぎない。第４の変形例、すなわち第２の変形例と第３ の変形例の組合せでは、Ｓは同時ＡＣＨ取引（借方勘定２２および貸方勘定２６ ）を送信する。 第３図は、通常、定期的な少額の支払いを予期する請求者に対して使用される 、他の請求支払いシステム８０のブロック図である。前述の請求支払いシステム と 比べると、それらがそのような取引を処理するようにセットアップされていると き、請求者は一般に請求支払いシステム８０の方を好む。 請求支払いシステム８０では、プロセスに対する請求者Ｂの制御が強化される ために請求者Ｂがより効率的な送金処理を行うが、消費者Ｃは通常、資金を引き 落とすための開放的な許可を請求者Ｂに与える必要があるので、関係がセットア ップされた後、請求支払い取引をほとんど制御できなくなる。さらに、請求支払 いシステム８０は、消費者との継続中の予想可能な関係を有さない請求者など、 すべてのタイプの請求者に妥当であるわけではない。 第３図は、空白小切手８４、借方記入通知８６、事前許可メッセージ８８、借 方記入要求メッセージ９０など、ＡＣＨ８１を含む参加者間で流れるいくつかの 新しい項目を導入するものである。請求支払いシステム８０では、請求者Ｂは追 加顧客データベース８２を維持する必要がある。 請求支払いシステム８０が適切に動作できるように、登録フェーズ（矢印１な いし４）および業務フェーズ（矢印５ないし１３）がある。登録フェーズでは、 消費者Ｃが請求者Ｂに空白小切手８４を与え、請求者Ｂが空白小切手を使用して 事前許可メッセージ８８を開始する。請求者Ｂが事前許可メッセージ８８を直接 提出することはＡＣＨ８１から許可されない。これは、銀行Ｂ、すなわちＡＣＨ 発信金融預託機関（ＯＦＤＩ）が関与してメッセージ８８を銀行Ｃ、すなわちＡ ＣＨ受信金融預託機関（ＲＦＤＩ）に提出しなければならないことを意味する。 事前許可メッセージ８８が銀行Ｃから受け入れられた後、銀行Ｃは、銀行Ｂが開 始した自動借方記入要求をＣの口座２２に登録することを受け入れる。業務フェ ーズでは、請求者Ｂがデータベース８２に問い合わせて、消費者Ｃが自動借方と して登録されているかどうかを判定する。そうである場合、請求者Ｂは任意選択 で、借方記入通知８６を消費者Ｃへ送信し、借方記入要求メッセージ９０を請求 者Ｂの銀行、すなわち銀行Ｂへ送信する。銀行Ｂは次いで、このメッセージをＡ ＣＨ８１を介して銀行Ｃへ送信し、銀行ＣはＣの口座２２の借方に記入し、資金 をＡＣＨを介してＢの口座２６へ振り返る。この振替は、銀行Ｃから消費者Ｃへ 送信される銀行報告３８上で消費者Ｃに対して確認される。このシステム８０で は、借方要求メッセージ９０は、数ある理由の中で、資金が不十分であることの 結果として矢印１０ないし１２に沿った流れがもたらされるために、銀行Ｃから 拒絶される可能性がある。 請求支払いシステム８０では消費者の制御が失われる。請求者Ｂが借方記入通 知８６を消費者Ｃに送信せず、あるいは借方記入通知８６に含まれる額とは異な る額を求める借方記入要求９０を開始した場合でも、取引を終了し請求者Ｂのエ ラーという結果を許容することはＣの責任である。Ｃの口座２２は、借方記入が 行われ、Ｃは取引の日付をほとんど、あるいはまったく制御できない。さらに、 Ｃと請求者Ｂとの間に紛争が発生した場合、口座２２を封鎖することを除いて、 請求者ＢがＣの口座２２から紛争中の額を取ることを妨げることは非常に困難で ある。 何人かの請求者は請求支払いシステム５０（第２図）よりも請求支払いシステ ム８０の方を好むが、それにもかかわらず、請求者Ｂが、システムを使用して各 顧客を登録し、許可、借方記入額、借方記入期間用の別々の顧客データベース８ ２を維持しなければならないので、請求支払いシステム８０には、高度に自動化 された請求支払いシステム１０（第１図）を超えるコストが必要である。 登録は、実際には請求支払いシステム１０（第１図）では必要ではないが、請 求支払いシステム５０（第２図）および請求支払いシステム８０（第３図）では 非常に大きな問題である。請求支払いシステム５０では、各消費者は、その請求 支払いサービス提供業者による登録プロセスに従わなければならない。消費者を 登録するには、消費者自体が、口座２２から資金を引き出すための許可をセット アップするために使用される空白小切手を請求支払いサービス提供業者に供給し なければならない。消費者は、特定の口座を使用して登録されるので、その口座 を容易に変更することはできず、まして、様々な支払い用の様々な口座の資金に よって支払いをカバーするよう命令することはできない。その代わりに、消費者 は、登録された口座を開いておく必要があり、請求額をカバーするための資金を 別々にその口座へ移動しなければならない。 請求支払いシステム５０を用いた場合、請求支払いサービス提供業者は、消費 者が支払いを要求する各請求者も、まだ登録していない場合は登録しなければな らない。請求者を登録するには、サービス提供業者がその請求者用の支払い手段 、 小切手を郵送するための請求者の位置などを識別しなければならない。 請求支払いシステム８０を用いた場合、消費者は、通常、空白小切手を各請求 者へ送ることによって、各請求者を別々に登録しなければならず、請求者も各消 費者を個別に登録しなければならない。システム５０でもシステム８０でも、消 費者は、消費者およびその消費者の請求者が完全に登録されるまで数日または数 週間だけ待たなければならない。 前述の欠点は、請求額を支払うための改良された手段が必要であることを示す ものである。 発明の概要 本発明によって、改良された請求支払いシステムが提供される。 本発明による請求支払いシステムの一実施態様では、参加している消費者は、 請求支払いネットワーク（下記では「支払いネットワーク」と呼ぶ）を使用して 参加している請求者に請求額を支払う。この場合、請求者は普遍的に識別され、 すべての参加者は１組のプロトコルに合意する。このプロトコルには、データ交 換プロトコルおよびメッセージ・プロトコルと、参加者の活動を拘束し指示する 業務規制とが含まれる。参加消費者は、額と、支払いネットワークに対して請求 者を識別する固有の請求者参照番号（”ＢＲＮ”）を示す請求書を参加請求者か ら受け取る（紙／郵便手形、Ｅメール通知、自動借方記入に関する暗黙的な請求 書など）。消費者は、送金を許可するために、（１）支払額、（２）資金源、（ ３）支払日、（４）消費者Ｃの請求者Ｂとの口座番号（Ｃ−Ｂ口座番号）、（５ ）請求者ＢのＢＲＮを示す取引を消費者の銀行（参加銀行）へ送信する。銀行Ｃ に記憶されている比較的静的な情報を指すポインタによって、これらの要素のう ちの１つまたは複数を表すことができる。たとえば、消費者Ｃは、常に２、３の 口座のうちの１つを資金源として使用する場合、どの口座かを示すポインタを提 供することができる。ポインタは、頻繁に支払いを受ける請求者用のＢＲＮおよ びＣ−Ｂ口座番号を指定する有用な方法でもある。ポインタを、指し示されるデ ータまで拡張することは、銀行Ｃが消費者Ｃに関する参照テーブルを維持するこ とによって行うことができる。 銀行Ｃは、消費者Ｃから請求支払い命令を受信し必要に応じてポインタを拡張 すると、次いで取引のＢＲＮから判定された銀行Ｂ（請求者の銀行）への支払い ネットワークに電子取引、支払いメッセージを発行する。支払いネットワークは 、ＶｉｓａＮｅｔ^(R)ネットワークなど既存のネットワークでよく、その場合、 銀行はそのコンピュータ・システムをＶｉｓａＮｅｔ^(R)アクセス・ポイント（ ＶＡＰ）装置を介して他の銀行にあるコンピュータ・システムに接続する。既存 のネットワークを使用すると、そのような請求支払いシステムの始動コストによ って、ＶｉｓａＮｅｔ^(R)ネットワークを介して行われる銀行カード取引など、 ネットワーク中の他のトラフィックをてこ入れすることができる。 ＢＲＮは、支払いネットワークのオペレータによって割り当てられる。清算の ために、銀行Ｃは、消費者Ｃによってその支払い用の資金源として指定された口 座の借方に記入し、支払いネットワークとのネット位置を指定される。同様に、 銀行Ｂは、支払いネットワークからネット位置を受け取り、請求者Ｂの当座勘定 の貸方に記入する。銀行Ｂのネット位置は、支払いネットワークを操作するコス トの資金を提供するための振替から支払いネットワークによって収集される少額 の処理手数料の場合を除いて、銀行Ｃのネット位置に等しく、かつ対向する。こ のネット位置は、支払いメッセージ額に等しくすることも、交換手数料、すなわ ち支払いネットワークと対話するコストと提供される支払いネットワーク・サー ビスからの収益との帳尻を合わせ、それによって必要に応じて容易にコストの帳 尻を合わせるために消費者銀行と請求者銀行との間で一方向または他の方向へ振 り替えられる手数料、または処理手数料、すなわち支払いネットワークの稼働コ ストの資金を提供するために使用される手数料をカバーするようにわずかにずら すこともできる。 支払いネットワークは外国為替を処理することもできる。たとえば、銀行Ｃは 、銀行Ｂが予期する通貨で支払いメッセージを送出し、銀行Ｃが指定した通貨で ネット位置を受領することができる。銀行Ｃの通貨は、特に銀行Ｃと銀行Ｂがそ れぞれの異なる国にある場合、銀行Ｂの通貨とは異なるものでよい。他の実施態 様では、銀行Ｃは、請求額を支払うための支払いメッセージをある通貨で送信し 、ネット位置を他の通貨で受領し、消費者からの資金を第３の通貨で得る。 銀行Ｃは、資金が良好なものとなるまで取引を発行しないか、あるいは資金が 良好でない場合に損失を被るリスクを冒す。銀行Ｂは、取引の受信時に、請求者 Ｂに資金をリリースし、支払いネットワークが銀行Ｃからの資金を銀行Ｂの借方 に記入することを確認する。支払いネットワークは、ある金額を銀行Ｃの清算勘 定から清算銀行にある銀行Ｂの清算勘定へ移す命令を発行することによってこれ を行うことができる。清算銀行は、商業銀行でよく、Ｆｅｄ−Ｗｉｒｅ取引の場 合は連邦準備銀行でよい。 代替実施態様では、支払いメッセージの後のある期間内に送信することを条件 として、支払い破棄メッセージを支払いメッセージの後に送信することが許可さ れる。この場合、銀行Ｃは、最初に資金を確保せずに支払いメッセージを送信す ることができる。特定の実施態様では、消費者は、ＡＴＭで紙を介し、あるいは ＰＣ、または電話キーパッド、またはスクリーン・テレフォン、またはパーソナ ル・ディジタル・アシスタント（”ＰＤＡ”）を介して、手動で取引を開始する 。 本明細書中の本発明の性質および利点のさらなる理解は、本明細書の残りの部 分および添付の図面を参考することによって実現することができる。 図面の簡単な説明 第１図は、郵便支払いに依存する請求支払いシステムのブロック図である。 第２図は、消費者が、顧客としてその消費者を有する請求支払いサービス・ビ ューローを使用して請求額を支払う請求支払いシステムのブロック図である。 第３図は、請求者が消費者の当座勘定から自動借方記入を開始する請求支払い システムのブロック図である。 第４図は、請求支払いの両側（消費者側および請求者側）が支払いネットワー クを介して調和を図られる、本発明による電子請求支払いシステムの実施形態の ブロック図である。 第５図は、第４図に示した汎用参照ファイルの図である。 第６図は、第４図に示した支払いネットワークをより詳しく表した図である。 第７図は、非保証支払いが、処理され、その後、消費者の口座の資金不十分（ ＮＳＦ）条件のために支払いネットワークを介して破棄される、第４図に示し た電子請求支払いシステムの実施形態のブロック図である。 第８図は、支払いネットワークが任意選択で受取勘定データを直接、請求者に 供給することを示す、第４図に示した電子請求支払いシステムの概略ブロック図 である。 第９図は、請求者銀行が本発明による電子請求支払いシステムの請求者を後援 するプロセスのフローチャートである。 第１０図は、請求者が、本発明による電子請求支払いシステムの消費者銀行に よって提供される請求支払いサービスに加入するプロセスのフローチャートであ る。 第１１図は、本発明による、参加消費者による参加請求者への請求支払い取引 のプロセスのフローチャートである。 第１２図は、消費者がその銀行と直接取引するのではなく、既存の資金ネット ワークを通じサービス・ビューローを介して取引が開始される、本発明による電 子請求支払いシステムの代替構成である。 好ましい実施形態の説明 第４図は、消費者が、資金精算用のバックボーンを形成する支払いネットワー クを介して請求者への支払いを行う請求支払いシステム１００のブロック図であ る。システム１００は、１つには支払いネットワーク・オペレータによって各参 加請求者に割り当てられる固有の識別子により、かつ参加者が事前に合意された プロトコルを遵守することによって利用可能となる。消費者および請求者は、こ の請求支払いシステムに参加するが、多数の消費者に直接対処する必要も、ある いは多数の請求者に直接対処する必要もない。実際には、消費者および請求者は 、その銀行またはその他の参加金融機関に対処するだけでよい。請求支払いシス テム１００は、消費者Ｃ（１２）と、請求者Ｂ（１４）と、消費者の銀行Ｃ（１ ６）と、請求者の銀行Ｂ（１８）と、支払いネットワーク１０２とを参加者とし て含む。銀行Ｃおよび銀行Ｂがある種のデータとメッセージの処理手段を含むこ と、及び銀行に言及することは、その組織だけでなく、その組織、または支払い ネットワークの銀行構成要素を操作するその組織のエージェントによって維持さ れる コンピュータ・システムへも言及していることを理解されたい。データとメッセ ージの処理にコンピュータ・システムを使用することの一例を挙げると、銀行Ｃ のデータ処理手段は、Ｃの口座２２、交換勘定２４、銀行Ｃによって維持される その他の口座の帳尻を合わせ、資金を制御し、一般に、消費者Ｃおよびその他の 消費者から受信された情報および命令を処理するために使用される。銀行Ｃのメ ッセージ処理手段は、銀行Ｃのデータ処理手段を消費者Ｃおよび支払いネットワ ーク１０２に接続し、その間をマテリアルが通過できるようにするために使用さ れる。銀行Ｃのメッセージ処理手段は、銀行Ｃに送られた郵便からデータを手動 であるいは自動的に取り込む手段と、発送する郵便を生成する手段とを含むこと もできる。請求支払いシステムの記述が、銀行（銀行Ｃまたは銀行Ｂ）がとる措 置を指す場合、この措置が、その銀行のデータ処理手段、またはその銀行のメッ セージ処理手段、またはその銀行に対する処理サービスを契約している第３の当 事者の処理手段によって実施され、場合によっては、（特に、消費者がこのサー ビスに加入している間と、消費者Ｃの請求支払いインタフェースが１対１インタ フェースである場合）人間の介入を必要とするステップも使用することを暗黙的 に意味する。銀行Ｃおよび銀行Ｂは、銀行の厳密な法的定義に整合する必要はな いが、支払いネットワーク・オペレータによって銀行Ｃまたは銀行Ｂ、あるいは その両方の役割を占めることができる任意の種類の金融機関であってよいことも 理解されたい。 参加者間で送られるマテリアルには、顧客送り状１２０と、請求支払い命令１ ２２と、支払いメッセージ１２４と、Ａ／Ｒデータ・ファイル４０と、振替命令 １３０とが含まれる。支払いネットワーク１０２は、清算サブシステム１０４と 、交換サブシステム１０６と、汎用請求者参照ファイル１０８とを含む。 システム１００では、各消費者は、請求額を支払うための１つまたは複数の口 座を維持する銀行（または、銀行Ｃへの資金を保証するその他の手段）を有し、 各請求者は、支払いを受領したい口座を維持する銀行を有する。消費者銀行およ び請求者銀行は、それぞれの異なる銀行である必要はないが、それにもかかわら ず別々に示されている。仮定上、消費者Ｃは、Ｃにとって好ましい、合意できる 価格での請求支払い命令１２２入力方法をＣに提供する銀行、すなわち銀行Ｃを 選択しており、請求者Ｂは、合意できる価格での請求者Ｂの所望のＡ／Ｒデータ ・ファイル４０受信フォーマットを請求者Ｂに提供する銀行、すなわち銀行Ｂを 選択している。仮定上、請求者Ｂの所望のフォーマットは、請求者Ｂが例外項目 処理のコストおよび発生を回避するために選択するフォーマットである。各請求 者には、固有の識別子、すなわち請求者参照番号またはＢＲＮが割り当てられる 。この番号は、ｎ個の数字を備え、ｎ番目の数字はモジュラス１０検査数字であ る。本明細書で説明する例では、ｎ＝９であり、”９１８−２７２−６４２”が 請求者ＢのＢＲＮとして使用される。非数値ＢＲＮも可能である。 請求者ＢのＢＲＮは、ＢからＣへ送られる請求書１２０上に現れる。請求書１ ２０は、請求者Ｂがこのシステムを介して電子支払いを受け入れ、かつ受け入れ ることができるこを示すもの（通常、支払いネットワーク・サービス・マーク） と、ＢのＢＲＮを示すものと、支払額と、場合によっては支払日と、ＣのＣ−Ｂ 口座番号も含む。請求者Ｂはもはや物理的クーポンを必要としないので、請求書 １２０は郵便送り状とまったく同じように容易にＥメール送り状とすることがで きる。 請求支払い命令１２２は、消費者Ｃから銀行Ｃへ送られるものとして示されて おり、手動、または郵便、または電話によって、あるいは電子的に送られる。し かし、電子的に送られる可能性が高い。命令１２２は、ＢのＢＲＮと、ＣのＣ− Ｂ口座番号と、金額と、所望の取引日と、資金源と、そのＢＲＮを有する請求者 に指定の金額を支払うための許可とを含む。より複雑な命令を用いる場合は、複 数の取引日または金額、あるいはその両方を用いることができる。消費者Ｃおよ び銀行Ｃは、支払いネットワーク規則のパラメータ内で、コンピュータ・ベース のシステムであるか、それとも電話ベースのシステムであるか、それともその他 のシステムであるかにかかわらず、このデータを与える任意の命令供給システム に自由に合意し、かつ資金を借方に記入するための許可を検証する手段に自由に 合意することができる。そのような１つの例は、銀行Ｃが静的データのテーブル を維持し、命令１２２の要素に、実際のデータではなくその静的データを指すポ インタが含まれ、したがって命令１２２の要素を入力するための簡単な手段が消 費者Ｃに提供されるシステムである。 支払いメッセージ１２４は、支払いネットワーク１０２を介して銀行Ｃから銀 行Ｂへ転送される。重要なこととして、メッセージ１２４はＢの口座番号２６、 すなわち資金の最終宛先を含まない。好ましい実施形態では、支払いネットワー クは口座２６の番号も知らない。請求者Ｂに対する他の利点は、請求者Ｂが、他 の当事者に変更を示す必要なしに銀行Ｂとの口座番号を変更できることである。 請求者Ｂに対する他の利点は、請求者Ｂの口座番号を知っているのが銀行Ｂだけ なので、その口座に対する借方記入を開始できるのが銀行Ｂだけであることであ る。消費者Ｃに対する１つの利点は、消費者が、他の参加支払いネットワークに よる電子請求支払いサービスに加入するだけで、他の当事者と追加協定を結ぶ必 要なしに、銀行を完全に変更し電子請求支払い送金を継続できることである。こ れは、それぞれ、消費者が前の関係を停止して新しい空白小切手を送出すること を必要とする、自動引き落とし支払いの変更、またはサービス・ビューローとの 関係の変更に必要な労力と比べて非常に好ましいものである。 支払いメッセージ１２４の内容は、妥当であるかどうか銀行Ｃによって検査さ れ、無効な支払いメッセージは、事前に定義されたエディットを満たさない場合 は銀行Ｃまたは支払いネットワーク１０２によって停止される。エディットとは 、どれが有効な取引であり、あるいはどれが有効な取引ではないかを定義するマ スクまたは１組の規則である。ある種のシステムでは、取引はエディットに合致 しない場合でも最後まで実行されるが、フラグによって、取引がエディット試験 で不合格になったことが示される。支払いネットワーク１０２が、第４図に示し たようなローカライズ・システムである必要はなく、参加銀行が請求者ファイル １０８をコピーし、あるいはそのファイルにアクセスできるＡＴＭネットワーク やＶｉｓａｎｅｔ^(R)ネットワークなどの分散システムによって実施できること を理解されたい。 メッセージ１２４は、銀行Ｃを識別するＢＩＤ（銀行ＩＤ）と、銀行Ｂを識別 するＢＩＤと、請求者Ｂを識別するＢＲＮと、消費者Ｃの請求者Ｂとの口座を識 別するＣ−Ｂ口座番号と、金額と、このメッセージが示す金額の支払いをカバー する良好な資金を銀行Ｃが提供することの暗黙的な保証とを含む。銀行ＢのＢＩ Ｄは、汎用請求者参照ファイル（ＵＢＦ）１０８またはそのコピーを参照テーブ ルとして使用することによって見つけられる。 メッセージ１２４は、実施態様に応じて、日付／時間スタンプと、メッセージ を他のすべてのメッセージと区別する固有のメッセージ識別子とを含むこともで きる。支払いメッセージは、参加者間で金融取引（サービス料金、消費者Ｃが、 請求者Ｂからの将来の送り状または銀行報告書３８上に表示したい消費者Ｃの内 部記述）または非金融メッセージ送信を実行するために、消費者Ｃと請求者Ｂと 銀行Ｃと銀行Ｂとの間で、合意されたフォーマットで転送すべき追加情報を含む こともできる。 Ａ／Ｒデータ・ファイル４０は、銀行Ｂから請求者Ｂへ、合意されたフォーマ ットで、合意されたタイミングで転送され、指定のデータ・フォーマットを有す るいかなる支払いメッセージ１２４が請求者のＢＲＮに対して銀行Ｂに受信され たかを示し、かつ、Ａ／Ｒデータ・ファイル４０は受信した各支払いメッセージ の個別の支払額およびＣ−Ｂ口座番号を含む。請求者Ｂおよび銀行Ｂは、それら の間で自由にＡ／Ｒデータ・ファイル４０をどのように請求者Ｂに提示すべきか を決定できるので、請求者Ｂは、消費者がどの参加銀行を使用するかにも、ある いは消費者が請求支払いプロセスを開始するためにどの機能を使用したかにもか かわらずに、参加者であるＢのすべての顧客に関して同様にＡ／Ｒデータ・ファ イル４０を受信するときに、かつて郵便によってすべての支払いが受領されたと きに請求者によって享受された規模の経済性を活用することができる。いくつか の支払いが通常の非例外項目の方法で到着した場合、請求者Ｂは、銀行Ｂが通常 の支払い方法に十分に類似した形式のファイル４０を提供することを協定するこ とができ、したがって、支払いネットワークの支払いは、請求者Ｂが参加者では なく、したがって支払い情報をどのように受信するかを制御できない従来技術と は異なり、例外項目にはならない。 支払いネットワーク１０２は、銀行請求者ファイル１０８を維持する。このフ ァイルは、ＢＲＮ当たり１つのレコードを有し、ある種の状況で消費者用に表示 すべき情報を参照し、ファイルのローカルに維持されているコピー１５８を更新 するために銀行Ｃによって使用される。第５図は、汎用請求者参照ファイル１０ ８の構造を示す。ファイル１０８では、請求者に関するレコードは請求者ＢＲＮ 、 すなわちファイルのキーによって検索される。各レコードは、キー（ＢＲＮ）と 、請求者銀行ＩＤ（ＢＩＤ）と、Ｃ−Ｂフォーマット・マスク（ＣＢＭＡＳＫ） と、（支払いプロセスまたは登録プロセス中に正しいＢＲＮが入力されたかどう かに関するフィードバックを消費者に提供するために）請求者の請求書と共に含 まれる支払いクーポン上に現れる請求者の名前および住所と、その他の有用な請 求者情報とを含む。請求者Ｂに関する特定のレコードは、ＢＲＮ９１８−２７２ −６４２を使用して見つけられる。ファイル１０８中の請求者Ｂのレコードは、 銀行ＢのＢＩＤおよび請求者Ｂに関するＣＢＭＡＳＫを示す。ＢＩＤは、この例 では”４９３２１７”であり、支払いメッセージの宛先銀行、この場合は銀行Ｂ を識別する。ＢＩＤによって、消費者Ｃは、どの銀行に支払いを送るべきかを知 る必要も、あるいはその銀行のどの口座の貸方に記入すべきかも知る必要もなく なる。ＢＲＮとＢＩＤの組合せを用いた場合、宛先銀行を識別することができ、 ＢＲＮを用いた場合、宛先銀行は、消費者および消費者の銀行が請求者Ｂの口座 番号を知ることがないように、専用ファイル、すなわち請求者口座番号（Ｂ−ａ ｃｃｔ）テーブル１４０（第６図参照）を使用することができる。この構成の１ つの利点は、銀行Ｂの外部では、請求者Ｂの口座番号が分からず、したがって銀 行Ｂおよび請求者Ｂ以外の誰かがその口座に対して引き落とし取引を実行できる 可能性が低くなることである。請求者のＢＲＮしか知らずに行うことができる請 求者Ｂの口座からの１種の引き出しは、非保証支払いを破棄できるようにする支 払いネットワークでのみ許可される支払い破棄メッセージであり、引き出しの影 響を受けるのは、前に発行された支払いメッセージだけである。しかし、支払い 破棄メッセージが支払いメッセージに結合される場合、適切にセットアップされ た支払いネットワークを使用してネット引き出しを行うことはできない（もちろ ん、請求者Ｂの口座は、破棄のための査定済みサービス手数料を得ることができ る）。 フィールドＣＢＭＡＳＫは、Ｃ−Ｂ口座番号フォーマットを検証するために使 用され、請求者ＢのＣ−Ｂ口座番号のフォーマットを識別する。たとえば、請求 者ＢがＶｉｓａ^(R)カード発行者である場合、請求者のＣＢＭＡＳＫは”４９３ ２＾＃＃＃＃＾＃＃＃＃＾＃＃＃Ｃ”であってよい。これは、有効な消費者のＶ ｉｓａ^(R)カード発行者との口座番号が”４９３２”で始まり、その後に４つの 数字（０ないし９）からなる３つの群と、任意選択の空間を示すカレット（”＾ ”）と、最後の数字が検査数字であることを示す”Ｃ”が続くことを示す。ＣＢ ＭＡＳＫフィールドは、許可済み口座番号、あるいは一連の口座番号または検査 数字を算出する手順を含むこともできる。一例としてＶｉｓａ^(R)カード発行者 を使用すると、ファイル１０８は、ＣＢＭＡＳＫが”＃＃＃−Ａ−＃＃ｘ”であ る公共事業会社用のレコードを含むこともできる。ここで、”Ａ”は、その位置 に文字が存在しなければならないことを示し、”ｘ”は、消費者を識別するうえ で最後の文字は重要ではなく、何でもよいことを示す。 第５図は、人間が容易に読み取り記憶する、スペーサを使用する形式のＢＲＭ を示す。ただし、データ・プロセッサは通常、スペーサを必要とせずにこのよう なＢＲＮを記憶し処理する。ＢＲＮの最後の数字は、モジュラス１０検査数字で あり、消費者が供給するＢＲＮのエラーを検出するために使用される。前述の表 記法を使用すると、ＢＲＮは形式＃＃＃−＃＃＃−＃＃Ｃと突き合わせて検査さ れ、その場合、Ｃはモジュラス１０検査数字として算出される。 ＵＢＦ１０８の変形例では、ＢＲＮの第１の数字は、特定の地理領域または請 求者の産業を示し、ＵＢＦ１０８は各領域または産業ごとの個別のファイルに細 分割される。これは、市場分離、または効率的なファイル記憶、または特殊な報 告要件用の手段として使用することができる。 第６図は、支払いネットワーク１０２およびその周辺のより詳細なブロック図 であり、支払いメッセージ１２４がどのように銀行Ｃから交換サブシステム１０ ６を介して銀行Ｂへ転送されるかを示す。交換サブシステム１０６は、支払いメ ッセージ１２４を記録し、消費者銀行から請求者銀行へ転送するために使用され る。消費者銀行と請求者銀行を分離する必要はなく、１つの銀行が請求者銀行と 消費者銀行の両方の必要な要素を提供する場合、その銀行が請求者銀行と消費者 銀行の両方であってよい。清算サブシステム１０４は、交換サブシステム１０６ に結合され、交換サブシステム１０６によって受信され処理される支払いメッセ ージに従って、銀行Ｃと銀行Ｂとの間、及び支払いネットワークに参加する他の すべての消費者銀行と請求者銀行との間で資金を振り替える（あるいは、単に資 金を得る）ために使用される。清算サブシステム１０４は、清算銀行１２８に振 替命令１３０を発行することによってこれを行う。 第６図に示した主要なブロックは、銀行Ｃ１６、銀行Ｂ１８、支払いネットワ ーク１０２、清算銀行１２８である。銀行Ｃは、ＵＢＦ（汎用請求者参照ファイ ル）コピー１５８および交換サブシステム１０６に結合されたパケット・アセン ブラ１６０と共に示されている。銀行Ｂは、交換サブシステム１０６と、請求者 口座番号（Ｂ−ａｃｃｔ）テーブル１４０と、銀行Ｂが消費者銀行であり、ある いは銀行ＢがＣ−Ｂ口座番号を個別に検査しようとする際に使用されるＵＢＦコ ピー１５８に結合されたパケット・ディスアセンブラ１６２と共に示されている 。支払いメッセージ１２４は、ＢＲＮ、Ｃ−Ｂ口座番号、金額、宛先ＢＩＤの４ つの構成要素と共に示されている。清算銀行１２８は、銀行Ｃ用の清算勘定１５ ４、銀行Ｂ用の清算勘定１５５、支払いネットワーク用の清算勘定１５２、銀行 Ｂおよび銀行Ｃ以外の銀行用の清算勘定を代表する清算勘定１５６の４つの勘定 と共に示されている。清算銀行１２８は、結果的に勘定１５２と勘定１５４と勘 定１５５と他の銀行用の他の勘定１５６との間で資金を振り替えさせる振替命令 １３０を受け入れるために清算サブシステム１０４に結合されるものとして示さ れている。勘定１５２、１５４、１５５、１５６は複数の勘定を備えることがで き、たとえば、各銀行は様々な通貨用の清算勘定を維持する。 交換サブシステム１０６は、支払いメッセージ１２４を運ぶ線および外国為替 モジュール１６６に結合された取引ロガー１６４と共に示されている。清算サブ システム１０４は、ネット位置清算プロセッサ１６８、および報告回線１７２に 結合された清算報告生成装置１７０と共に示されている。報告回線１７２は、必 要に応じて、ネット清算額に関するデータ、支払いメッセージに関する要約デー タ、通貨交換データを提供するために銀行１６、１８に結合される。非保証支払 いネットワーク・システムでは、交換サブシステムによって、支払いメッセージ の後にＮＳＦメッセージを送信し、前に送信した支払いメッセージを取り消すこ とができる。混合システムでは、ＵＢＦ１０８中のフラグが、どの請求者が非保 証支払いを受領することを希望し、どの請求者が保証支払いのみを受領すること を希望しているかを示し、銀行Ｃがそれに応じて支払いのリスクを査定すること ができる。 銀行Ｃは、パケット・アセンブラ１６０を使用して、支払いメッセージ１２４ が送出される前にメッセージ中のデータを検査する。銀行Ｃは、まだメッセージ １２４の額の資金が確保されていない場合には資金を確保し、資金が確保されて おらず請求者が保証支払いを予期している場合にはメッセージ１２４を送信する 前に取引を拒否する。パケット・アセンブラ１６０は、供給されたＢＲＮおよび Ｃ−Ｂ口座番号もＵＢＦコピー１５８と突き合わせて検査する。ファイル１５８ にＢＲＮがない場合、取引は拒否される。ＢＲＮが見つかったが、Ｃ−Ｂ口座番 号が、ＣＢＭＡＳＫによって設定された基準を満たさない場合、取引は拒否され 、したがって請求者Ｂまたは銀行Ｂが取引を拒否する経費が節約され、取引が無 効であることに関するより迅速な応答が銀行Ｃおよび消費者Ｃに与えられる。ま た、請求者Ｂは、ＣＢＭＡＳＫ試験で不合格となったメッセージを、そのメッセ ージがＣＢＭＡＳＫ試験で不合格となったことを示すものと共に請求者Ｂ自体へ 送信することを要求することができる。ＵＢＦコピー１５８は、銀行Ｂおよびそ の他の請求者銀行から送られるＵＢＦ１０８の更新の支払いネットワーク同報通 信によって常に更新される。 取引が銀行Ｃから許可された場合、メッセージ１２４は、支払いネットワーク １０２へ送信され、銀行Ｂによって受信される。多くの場合、メッセージのこの ような通過が取引全体である。取引は実際には銀行Ｃと銀行Ｂとの間で行われる が、資金振替に関する事前に合意されたプロトコルのために実際は消費者Ｃから 請求者Ｂへの振替である。 テーブル１４０は、ＢＲＮを使用して請求者の口座番号を参照できるようにＢ ＲＮおよび請求者口座番号を記憶する。テーブル１４０は、ファイル４０を請求 者Ｂへ転送するための所望のデータ転送プロトコルを示す情報を含むこともでき る。テーブル１４０は、銀行Ｂの外に存在する必要はない。 消費者は、請求支払いシステム１００を使用して、事前に各請求者と別々の協 定を結ぶ必要なしに、請求者によって提示された請求額を容易に、かつ迅速に、 かつ正確に支払うことができる。請求者は、請求支払い送金を迅速に、かつ従来 よりも廉価に受け入れ処理することができる。請求者は、顧客ベース中の個別の 各消費者ごとに対処する必要もなく、請求支払いシステム１００に接続すること を請求者の銀行と協定することができる。請求者は、請求支払いシステム１００ を使用して請求支払いを送金したい消費者に宣伝することができる好ましい電子 プロセスも有する。消費者銀行および請求者銀行は、請求支払いシステム１００ を使用して、銀行データ処理システムと顧客（消費者または請求者、あるいはそ の両方）との間にそれぞれの異なるインタフェースを自由に提供し、顧客の要件 および希望に応じて請求支払いを容易にすることができる。多くの消費者はそれ ぞれの異なるインタフェースを使用して請求支払い取引を消費者銀行の請求支払 い処理システムに挿入し、多くの請求者は必要なＡ／Ｒデータを請求者の銀行か ら各請求者ごとに異なるフォーマットで受信するが、請求支払い取引は、本発明 による新規の支払いネットワークを使用して消費者銀行から請求者銀行へ流れる ことができる。通常は、支払いネットワーク活動を規定する１組の規則に合意す る参加者として銀行および請求者を識別する記号または商標と共に、前述の装置 を用いた場合、良好な資金は、従来可能であったよりもずっと短い時間で、支払 いのずっと大きな保証と共に、消費者から請求へ流れることができる。 第７図は、第４図に示した電子請求支払いシステムの変形例のブロック図であ り、この場合、消費者の銀行は、支払いメッセージの後に支払い破棄メッセージ （ＮＳＦ通知４６として図示されている）を送信することを許可される。追加リ ンクが支払いシステム１００Ａの一部として示されている。このシステムでは、 消費者Ｃは、前述のように請求支払い命令１２２を発行するが、銀行Ｃは、非保 証支払いメッセージ１２５を支払いネットワーク１０２に発行し（矢印３）、そ のメッセージが銀行Ｂへ転送される（矢印４）。（メッセージ１２５が発生した ことを非例外項目の方法で請求者Ｂに通知する）非保証支払いレコード１２７が Ｂへ送信された（矢印７）後のある時点で、銀行Ｃは、消費者Ｃの口座が、前に 発行された非保証支払いメッセージ１２５の額をカバーするのに十分な資金を含 まないと判定する。したがって、銀行ＣはＮＳＦ通知４６を支払いネットワーク １０２に発行し（矢印８）、支払いネットワーク１０２はその通知を銀行Ｂおよ び請求者Ｂへ転送する（矢印９ないし１２）。その結果、前に発行された、銀行 ＢにあるＢの口座２６からの非保証支払い１２５と、Ｂの総勘定元帳４２から得 たレコード１２７の効果が破棄される。矢印３および８ならびに矢印４および１ ０は別々のリンクとして示されているが、多くの場合、支払いメッセージと、Ｎ ＳＦ通知４６などの支払い破棄メッセージに同じ経路が使用される。 第８図は、請求支払いシステムの代替構成１００Ｂであり、この場合、支払い ネットワーク・オペレータは支払いデータを直接、請求者に提供する。第８図は 、消費者Ｃと、銀行Ｃと、支払いネットワーク１０２と、銀行Ｂと、請求者Ｂと を含む請求支払いシステム１００Ｂを示す。請求者Ｂは消費者Ｃへ送り状１２０ を送り、消費者Ｃは請求支払い命令１２２を銀行Ｃへ送信し、銀行Ｃは支払いネ ットワーク１０２に支払いメッセージ１２４を発行する。支払いメッセージ１２ ４は銀行Ｂへ転送されるが、メッセージ１２４のＡ／Ｒデータ（データ、金額、 Ｃ−Ｂ口座番号）は銀行Ｂではなく直接、請求者Ｂへ転送され、請求者ＢのＧ／ Ｌデータベース４２を更新しするために使用される。いくつかのケースでは、デ ータをより早く得ることができる請求者Ｂ、もはやＡ／Ｒデータを維持し請求者 Ｂへ転送する必要のない銀行Ｂによってこの方法が好まれる。これは、高額請求 者向けの良好な代替策である。任意選択で、銀行Ｂは請求者ＢにＡ／Ｒ要約デー タ１２９を提供する。 第９図ないし第１１図は、前述の装置、または本明細書には例示していない他 の装置を使用して、消費者の請求者への請求支払いを容易にするための本発明に よるプロセスを説明するものである。第９図ないし第１１図のフローチャートに 記載したプロセスは、ある種の実施形態では、手動のデータ入力、または自動デ ータ取り込み、または参加者間の１対１の対話、または適切にプログラムされた コンピュータおよびコンピュータ・ネットワーク、あるいはそれらの組合せを使 用する。しかし、好ましい実施形態では、このプロセスの大部分のステップは、 コンピュータ、コンピュータ・ネットワーク、通信機器中のソフトウェア・ルー チンによって実行される。 第９図は、非参加請求者を参加請求者に変換するプロセスを説明するフローチ ャートである。参加請求者とは、顧客にある金額を請求し、少なくとも部分的に 本発明による電子請求支払いシステムを介して、この請求のための資金を収集す る実体である。 請求者が参加請求者となるプロセスは、論理ブロック２００で、請求者が参加 請求者銀行との当座勘定を開いたときに開始する。もちろん、請求者はすでにそ のような口座を有していてもよく、その場合、このステップをスキップすること ができる。参加請求者銀行とは、支払いネットワークのオペレータによって指定 された形式の消費者銀行からの支払いメッセージを支払いネットワークを介して 受け入れることに合意している銀行である。参加請求者銀行は、それ自体が後援 するすべての請求者を伴うすべての取引の正味金額（オリジナル、リターンなど ）に関して支払いネットワークが借方記入／貸方記入を行うことができる清算勘 定を維持することにも合意する。参加請求者銀行は、受信した支払いメッセージ の額の資金を請求者の口座に振り替え、請求者に割り当てられた固有のＢＲＮ（ 請求者参照番号）のみから請求者の口座番号を識別するために使用できる相互参 照テーブルをデータ処理システムに維持し、請求者に提供するサービスに関する 支払いネットワーク規則の条件を満たすことにも合意する。 銀行は、支払いネットワーク・オペレータとの協定の一部として、処理手数料 および交換手数料の条件に合意する。このように、交換手数料はコスト・バラン シング装置として働くことができる。これらの手数料は、消費者銀行によって支 払うことも、あるいは請求者銀行によって支払うことも、あるいはその両方によ って支払うこともでき、いくつかのケースでは、何らかの手数料が交換手数料の 形で消費者銀行または請求者銀行に支払われる。交換手数料を用いた場合、普通 なら一方の当事者にとって非経済的な取引が発生することがある。交換手数料は 、清算銀行に発行される振替命令に容易に収集される。すなわち、この振替命令 は、ある金額を消費者銀行の口座と、請求者銀行の口座と、支払いネットワーク の清算勘定との間で任意の方向へ移すことができる。 論理ブロック２０２で、請求者と請求者銀行は、Ａ／Ｒデータを効率的に（か つ通常は電子的に）請求者へ転送できるように請求者銀行へ送信される支払いメ ッセージに含まれるＡ／Ｒデータを転送するためのデータ転送プロトコルに合意 する。このステップは、請求者銀行のデータ処理システムと請求者のデータ処理 システムとの間に専用回線またはダイヤルアップ回線を接続することを含むこと ができる。また、請求者銀行は、請求者が直接、支払いネットワークに接続する ことを後援することができる。請求者と請求者銀行との間で合意されるプロトコ ルは、請求者へ転送すべきデータの構成、データを転送すべき周波数、請求者銀 行がデータを提供するために請求者から収集するサービス料金などの条件を含む ことができる。請求者は一般に、Ａ／Ｒデータが提供されることを予期するが、 請求者銀行が単に資金を預かりＡ／Ｒデータを提供しないことに請求者と請求者 銀行が合意することも可能である。そのような方法は、慈善集金に対する支払い に有用であることがある。この点で、請求者は、請求者銀行が、Ｃ−Ｂ口座番号 を、ＵＢＦ１０８に挿入しその後同報通信するために支払いネットワークへ送信 できるように、請求者に受け入れられるＣ−Ｂ口座番号を構成するものも請求者 銀行に示す。 請求者と請求者銀行がプロトコルに合意した後、論理ブロック２０４で、請求 者銀行は支払いネットワークに新しい請求者レコードを要求する。これに応答し て論理ブロック２０６で、支払いネットワークは、請求者に固有の新しい請求者 参照番号を発行する。代替プロセスでは、支払いネットワークが１組の番号を事 前に請求者銀行に割り当てておき、それらの番号から請求者のＢＲＮが得られる 。その場合、請求者銀行は、番号を要求するのではなく、１組の番号からＢＲＮ を活動化したことと、そのＢＲＮ用の受け入れられるＣ−Ｂ口座番号のフォーマ ットと、そのＢＲＮが所望の請求者のＢＲＮであることを検証するための、通常 支払いクーポン上に印刷される他の請求者固有データを支払いネットワークに通 知する。好ましい実施形態では、このプロセスはほぼ電子的に実施される。 論理ブロック２０８で、支払いネットワークは、新しい参加ＢＲＮおよび関係 するデータをすべての参加消費者銀行に発表／同報通信し、消費者による請求者 の検証とベンダＡ／Ｒデータの経路指定を使用可能とする。 最後に、論理ブロック２１０で、請求者は、具体的には請求書、および新しい サービスを発表する郵便物上で、ＢＲＮを顧客に対して識別し、次いで支払いネ ットワークの支払いを受け入れるようにセットアップされる。請求者はこの時点 で、支払いネットワーク・ベースの支払いを顧客に請求することもできる。 好ましい実施形態では、このプロセスは高度に自動化され、請求者にとって簡 単である。支払いネットワーク・システムが、現在Ｖｉｓａ^(R)システムに参加 しているのと同程度の数の参加銀行を有することが予想される。これはほぼすべ て の主要銀行を含むので、所与の請求者の銀行が参加銀行となる確率が高い。した がって、請求者は、その既存の銀行と共に支払いネットワーク・サービスと契約 し、ＢＲＮを受領し、そのＢＲＮ番号を発表するだけでよい。 第１０図に示したように、消費者が支払いネットワーク・システムを介して請 求額を支払えるようにする消費者銀行のサービスに加入するプロセスも、まった く同じように簡単である。論理ブロック２３０で、消費者は、参加消費者銀行と 共に電子請求支払いサービスに加入する。この場合も、消費者はすでに参加消費 者銀行に預金している可能性が極めて高い。そうでない場合、Ｖｉｓａ^(R)サー ビス・マークがＶｉｓａ^(R)カード発行者と、Ｖｉｓａ^(R)カードを支払い用に受 け入れている小売業者を識別するのとまったく同じように、広く知られているロ ゴまたはサービス・マークを使用することによって容易に参加消費者銀行を識別 することができる。 論理ブロック２３２で、消費者と消費者の銀行は、消費者Ｃが請求支払い命令 を開始しその料金を支払うよう銀行Ｃに命令できるようにするサービスの詳細に 合意する。銀行のサービスは、すべての可能なインタフェースを提供する必要が あるわけではなく、また消費者の主当座預金よりも多くの金額を支払う必要もな い。銀行は、それぞれの異なるインタフェースおよびサービスの変更を提供する ことによって顧客を求めて競争することができる。たとえば、消費者銀行は顧客 にソフトウェアを提供することができる。顧客は、そのソフトウェアを顧客のパ ーソナル・コンピュータ上で実行し、そのソフトウェアは、請求支払い命令をモ デムを介して、消費者銀行のデータ処理システムに接続されたモデムへ送信する ことができる。このような請求支払い命令は、請求額をただちに支払う命令、ま たは請求額を将来支払う命令、または再発請求額を定期的に支払う命令を含むこ とができる。他の可能なインタフェースは音声応答システムであり、この場合、 消費者は、消費者銀行用に維持された通信システムにダイヤルインし、尋ねられ る質問（「今、どの請求者に支払いを行いたいか」、「いくら支払いたいか」な ど）を聞き、消費者の電話上のキーを押すことによって応答する。消費者は、ビ ジュアル・ディスプレイを有する電話を使用することも、あるいは、消費者を消 費者の銀行またはＡＴＭに接続する消費者のケーブル・テレビジョン提供業者の サービスとして提供されるインタフェースなど、消費者のテレビジョンをインタ フェースとして使用するインタフェースを使用することもできる。おそらく、よ り非効率的ではあるが、銀行とのインタフェースを郵便を介してとることもでき 、この場合、消費者は請求支払い命令を消費者銀行へ郵送する。この代替策は、 通信が容易に利用できず、あるいは消費者が音声応答システムやコンピュータを 使用することに反対する地域での唯一の解決策とすることができる。 次に、論理ブロック２３４で、消費者は、支払いネットワークを使用して支払 いたい請求額のうちのどれが支払いネットワークを介して支払うことができるか を識別する。前記で示唆したように、請求者が指定のロゴを表示することによっ て支払いネットワーク・システムに参加することを識別し、消費者がロゴの意味 を知っている場合、消費者は参加請求者を容易に識別することができる。 第１１図は、参加消費者と参加請求者との間の本発明による請求支払いプロセ スのフローチャートである。論理ブロック２５０で、請求者は、郵便、またはＥ メール、またはその他の手段を介して消費者に請求書を送る。この請求書は、支 払額、請求者のＢＲＮ、支払日を示すものである。参加消費者は、請求額を支払 いネットワークを介して任意の参加請求者に支払うことができる。消費者および 請求者が支払いネットワーク・システムの参加者であり、請求者が、請求者自体 が支払いネットワークの支払いを受け入れることができ、かつ実際に受け入れる ことを示すものと、請求者のＢＲＮと、支払額と、支払日と、消費者のＣ−Ｂ口 座番号とを含む請求書を消費者へ送る場合、消費者は支払いネットワークを介し て容易に支払いを処理することができる。請求者参照番号は、汎用なので（それ ぞれの異なる銀行およびそれぞれの異なる消費者がすべて同じ番号を使用する） 、消費者が請求者に支払いを行いたいことを示す前に請求者に割り当てておくこ とができ、したがって請求者は、請求支払いサービスに加入した後最初に消費者 へ送られる請求書上にＢＲＮを含めることができる。多くの場合、消費者が請求 者を登録する必要はなく、必要がある場合、消費者は、銀行ＣによってＵＢＦレ コードから請求者のＢＲＮと共に収集される請求者情報のコピーを検討してその ＢＲＮが所望の請求者を指していることを検証し、消費者がポインタによって資 金源、またはＢＲＮ、またはＣ−Ｂ口座番号、あるいはそれらの組合せを選択で き るようにする静的データ・テーブルをセットアップするだけでよい。ポインタは 、「スピードダイヤル」が電話番号のより迅速なダイヤリングを行うのとまった く同じように、より迅速なデータ入力を行う。これに対して、他の請求支払いシ ステムでは、請求者の番号は、それぞれの異なる国ごとに異なるものでも、ある いはそれぞれの異なる請求支払いサービス提供業者ごとに異なるものでも、ある いは各消費者ごとに異なるものでもよい。 論理ブロック２５２で、消費者は消費者の銀行（銀行Ｃ）へ請求支払い命令を 送信する。この命令は、命令に示された日付に命令に示された額をＣの銀行Ｃと の口座の借方に記入し（あるいは、その他の方法で資金を確保し）、命令に示さ れたＢＲＮおよびＣ−Ｂ口座番号と共に資金を支払いネットワークへ送ることを 銀行Ｃに命令する。 論理ブロック２５４で、銀行Ｃは、取引用の資金が利用できるかどうかを検査 する。資金が利用できず、銀行Ｃが消費者との他の協定を有さない場合、フロー は論理ブロック２５６へ進み、請求支払い命令が拒否されたことが消費者に通知 される。重要なこととして、保証資金支払いネットワーク・システムでは、ある 命令が資金が不十分であるために停止される場合、それほど先へ進まないうちに 破棄される。もちろん、銀行Ｃは取引を継続し、後でそれを破棄しようとするこ とができるが、支払いネットワーク規則が、支払いメッセージが送出された後、 銀行Ｃがそのメッセージを破棄することはできなくなるようなものである場合、 このことが行われる可能性は低い。資金は通常、Ｃの口座から得られるが、協定 によって、銀行Ｃは資金を貯蓄勘定から得ることも、あるいは信用限度から得る ことも、あるいはクレジット・カード勘定から得ることも、あるいは消費者のそ の他の金融手段から得ることもできる。 資金が利用可能であり、あるいは銀行Ｃが資金に関するリスクを冒すことに合 意していると仮定すると、フローは、論理ブロック２５８へ進む。論理ブロック ２５８で、銀行ＣはそのＵＢＦ１５８のコピーを使用して請求者を確認し、ある いはデータを求める問い合わせメッセージを支払いネットワークへ送信する。い くつかのケースでは、請求者の確認は、所与のＢＲＮを含む命令が初めて要求さ れたときにしか行われず、銀行Ｃは消費者に代わって、確認された請求者のリス トを維持する。 次に、論理ブロック２６０で、銀行Ｃは支払い命令中のＢＲＮおよびＣ−Ｂ口 座番号が有効なものであるかどうかを検査する。ＢＲＮが有効なものではなく、 あるいはＣ−Ｂ口座番号が、ＢＲＮに関連する請求者に有効なものではない場合 、フローは論理ブロック２６２へ移り、命令が拒否され、そうでない場合、フロ ーは論理ブロック２６４へ進む。銀行Ｃが命令をＵＢＦコピーと突き合わせて検 査した場合でも、支払いネットワークは再び、その命令から形成された支払いメ ッセージを検査し、銀行Ｃが何らかの理由で誤って支払いメッセージを通過させ た場合にはメッセージを拒否する。 次に、論理ブロック２６４で、銀行Ｃは支払いネットワークに支払いメッセー ジを発行し、支払いネットワーク規則によって、支払額に責任を負う。資金が支 払いネットワークを介して銀行Ｃから銀行Ｂへ送られるので、消費者が損失を被 る可能性は非常に低い。もちろん、銀行Ｃが倒産する可能性があるが、ある金額 が銀行Ｃの制御の下である口座から他の口座へ移ったことは、支払いメッセージ が送信されなかった場合に消費者が資金を取り戻す能力には影響を及ぼさないは ずである。一方、支払いメッセージが送信された場合、支払いネットワーク規則 によって、宛先銀行は銀行Ｃから支払いメッセージを受け入れることに合意し、 請求者の口座の貸方に記入しなければならない。請求者は、消費者の請求者との 口座の貸方に記入しなければならない。消費者の資金を保持することができるサ ービス・ビューローを使用することと比べて、支払いネットワークはずっと安全 な請求支払い機構を消費者に提供する。 論理ブロック２６２で、支払いネットワークは、銀行Ｃの借方に支払いメッセ ージの額を記入し、銀行Ｂ（請求者の銀行）の貸方に同じ額を記入する。次いで 論理ブロック２６８で、銀行Ｂは請求者の口座の貸方に記入し、請求者は論理ブ ロック２７０で、消費者の請求者との口座の貸方に記入する。銀行Ｂは、他の検 証サービスを請求者Ｂに供給することもできる。その場合、請求者Ｂは妥当なＣ −Ｂ口座番号のリストを銀行Ｂに供給し、銀行Ｂはこのリストを使用して着信支 払いメッセージを検証し、無効なＣ−Ｂ口座番号を含むメッセージを返送する。 これは、単に口座番号が正しいフォーマットであるかどうかを調べるための検査 を行うよりも厳密な口座番号の検査である。 第１２図は、代替請求支払いシステム３００のブロック図であり、この場合、 消費者Ｃ３０２は、銀行Ｃに直接対処するのではなく、Ｖｉｓａｎｅｔ^(R)ネッ トワークなど既存の資金ネットワーク３１０を通じ、Ｃと銀行Ｃ３０４との間に 位置するサービス提供業者３１２を介して、請求支払い命令１２２を開始する（ 矢印１）。サービス提供業者３１２は、支払いメッセージ１２４の必要な検証を 行うことができるようにＵＢＦコピー１５８を維持する。サービス提供業者３１ ２は、Ｃの銀行ではなく、Ｖｉｓａｎｅｔ^(R)ネットワークを介した取引を使用 して銀行Ｃ３０４から良好な資金を確保する。これを行う１つの方法は、Ｃおよ び請求支払い取引１２２の額を識別するある形式のパスワードを含む顧客検証メ ッセージ３１８をＶｉｓａＮｅｔ^(R)ネットワーク３１０を介して発行し、許可 ３１６（矢印２ないし５）が支払いメッセージ１２４の送信（矢印６）と共に進 行するのを待つ。 サービス・ビューローＳは、銀行Ｃから許可３１６を受信した時点で、Ｖｉｓ ａＮｅｔ^(R)ネットワークを介して支払いメッセージ１２４を発行し（矢印６な いし７）、その結果、清算振替命令１３０が清算銀行１２８へ送信される（矢印 ８）。銀行Ｂ３０８によってＡ／Ｒデータ・ファイル４０２が請求者Ｂ３０６へ 転送される（矢印９）。 前記の説明は例示的なものであり、制限的なものではない。当業者には、この 開示を検討したときに本発明の多数の変形例が明らかになろう。単に一例を挙げ ると、サービス・ビューローは、請求支払いサービスを消費者または請求者に直 接には提供しないようにする銀行の代理人として、消費者と消費者銀行との間、 および請求者と請求者銀行との間に配置することができる。他の例を挙げると、 前記で参加者間で転送されるメッセージについて時には具体的に説明したが、メ ッセージは郵便形式、Ｅメール・メッセージ、電話音声応答セッションなどで相 互交換可能に実施することができる。さらに、前述の電子請求支払いシステムの 何人かの参加者を消費者銀行および請求者銀行と呼んでいるが、これらの参加者 は必ずしも銀行の法的定義に整合する必要はなく、消費者または請求者、あるい はその両方の口座を維持しかつ支払いネットワークに結合された貯蓄・貸付組合 、 貯蓄機関、クレジット・ユニオン、株式仲介業者などでよい。 したがって、本発明の範囲は、前記の説明に関して決定すべきものではなく、 添付の請求の範囲とその等価物の全範囲に関して決定すべきである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ)，ＡＭ， ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ ，ＨＵ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ， ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，Ｎ Ｌ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ ，ＳＩ，ＳＫ，ＴＪ，ＴＴ，ＵＡ，ＵＺ，ＶＮ (72)発明者 ホッジス，ロン アメリカ合衆国 94583 カリフォルニア 州・サン ラモン・ウッドビュー テラス ドライブ・180 (72)発明者 パーデュー，スティーブン・ダブリュ アメリカ合衆国 94019 カリフォルニア 州・ハーフ ムーン ベイ・ヴァルデズ アヴェニュ・327 (72)発明者 パワー，ウィリアム・エル アメリカ合衆国 94301 カリフォルニア 州・パロ アルト・エマーソン ストリー ト・1310

Claims (1)

1. 【特許請求の範囲】 １．消費者が消費者金融機関に請求者の請求額を支払うよう命令する請求支払 いシステムであって、 少なくとも請求者ＩＤを示すものと、支払うべき額と、貸方に記入すべき消費 者−請求者口座、すなわち消費者が請求者に負っている金額を判定するために請 求者によって維持される口座を示すものとを含む請求者支払い命令を消費者から 受け入れるようになされた消費者金融機関コンピュータとの消費者請求支払いイ ンタフェースと、 前記請求支払い命令に含まれる情報に基づき、少なくとも前記請求者ＩＤを示 すものと、前記支払うべき額と、前記消費者−請求者口座とを備える支払いメッ セージを生成するために前記消費者金融機関コンピュータに結合された支払いメ ッセージ生成手段と、 前記支払いメッセージに含まれる前記請求者ＩＤから前記支払いメッセージの 宛先を識別し、前記支払いメッセージ中の前記額に応じて消費者金融機関の口座 の借方に記入するための汎用請求者参照データ・ファイルを備える、前記支払い メッセージを送信するために前記支払い生成手段に結合された支払いネットワー クと、 前記支払いネットワークからの前記支払いメッセージを受け入れ、前記支払い メッセージ中の前記額に応じて請求者の口座の貸方に記入するために、前記支払 いネットワークおよび前記宛先にある請求者金融機関コンピュータに結合された 支払いメッセージ受け入れ手段と、 前記支払いメッセージに含まれる請求者データを処理し、前記支払いメッセー ジ額のクレジットを反映するように前記消費者−請求者口座を更新するために前 記請求者によって使用される形式で前記データを提供するために、前記支払いネ ットワークまたは前記支払いメッセージ受け入れ手段のうちの一方に結合された 請求者データ処理手段と を備えることを特徴とするシステム。 ２．前記汎用請求者参照データ・ファイルが消費者−請求者口座番号に関する 基準を含み、前記支払いメッセージ中の前記消費者−請求者口座番号が、前記基 準を満たす場合に妥当なものとみなされることを特徴とする請求項１に記載の装 置。 ３．ポインタを使用して、前記消費者金融機関コンピュータに記憶されている 消費者−請求者口座番号、または請求者ＩＤ、または資金源のうちの少なくとも １つを指すことを特徴とする請求項１に記載の装置。 ４．前記請求支払い命令がさらに、消費者が借方に記入することを許可された 口座のうちの資金源を示すものを備えることを特徴とする請求項１に記載の装置 。 ５．前記消費者金融機関および前記請求者金融機関が同じものであることを特 徴とする請求項１に記載の装置。 ６．所与の金融機関が、何人かの消費者に対しては消費者金融機関であり、何 人かの請求者に対しては請求者金融機関であることを特徴とする請求項１に記載 の装置。 ７．さらに、支払いメッセージの送信に応答して借方記入を受け入れるために 消費者から消費者金融機関への支払いを保証する手段を備えることを特徴とする 請求項１に記載の装置。 ８．前記保証手段が、消費者が当座預金、または貯蓄勘定、または信用限度の うちの少なくとも１つを十分に帳尻を合わせて維持することによって提供される ことを特徴とする請求項７に記載の装置。 ９．前記保証手段が、前記支払いネットワークへ支払いメッセージを送信する 前に消費者から資金を確保する手段であることを特徴とする請求項１に記載の装 置。 １０．資金を確保する前記手段が、消費者の口座の借方に記入し仮勘定の貸方 に記入する口座振替プログラムであることを特徴とする請求項９に記載の装置。 １１．さらに、前記請求支払い命令の額を消費者に負わせる許可を検証するた めに前記消費者金融機関コンピュータに結合された検証手段を備えることを特徴 とする請求項１に記載の装置。 １２．前記検証手段が、消費者が個人識別番号を入力できるようにする手段と 、前記入力された個人識別番号が消費者の所定の個人識別番号に合致するかどう か を検出する前記消費者金融機関コンピュータ中の手段とを備えることを特徴とす る請求項１１に記載の装置。 １３．前記検証手段が、消費者が、前記消費者金融機関コンピュータに結合さ れたカード読取り装置に機械読取り可能なカードを挿入できるようにする手段を 備え、妥当なカードを有することが許可の証拠であることを特徴とする請求項１ １に記載の装置。 １４．前記消費者金融機関コンピュータの機能が、サード・パーティ取引プロ セッサによって提供されることを特徴とする請求項１に記載の装置。 １５．前記支払いメッセージ額が、第１の通貨で呼称され、消費者金融機関の 借方に記入される前記額が、第２の通貨で呼称されることを特徴とする請求項１ に記載の装置。 １６．消費者金融機関に対する消費者の債務が、第３の通貨で呼称されること を特徴とする請求項１５に記載の装置。 １７．前記支払いメッセージ額が、消費者が指定した口座の借方に記入され、 前記支払いメッセージ額が、消費者金融機関の借方に記入され、前記支払いメッ セージ額が、前記請求者金融機関の貸方に記入されることを特徴とする請求項１ に記載の装置。 １８．サービス手数料も、消費者金融機関によって課されるサービス手数料と して、消費者が指定した前記口座の借方に記入されることを特徴とする請求項１ ７に記載の装置。 １９．消費者金融機関の借方に記入される前記額と前記請求者金融機関の貸方 に記入される前記額のうちの少なくとも一方が、支払いネットワーク処理手数料 によって調整されることを特徴とする請求項１７に記載の装置。 ２０．消費者金融機関の借方に記入される前記額および前記請求者金融機関の 貸方に記入される額が、交換を行うために前記支払いメッセージ額からオフセッ トされ、それによって消費者金融機関と前記請求者金融機関との間でコストの帳 尻が合わされることを特徴とする請求項１に記載の装置。 ２１．請求額を支払う方法であって、 選択された請求者に消費者が負っている、前記選択された請求者に支払うべき 額を判定するステップと、 固有の請求者ＩＤを示すことによって、前記選択された請求者を識別するステ ップと、 少なくとも前記額および前記請求者ＩＤを消費者金融機関に提供するステップ と、 そのデータ要素が少なくとも前記額と前記請求者ＩＤとを含むアウトバウンド 支払いメッセージを前記消費者金融機関から支払いネットワークへ送信するステ ップと、 前記アウトバウンド支払いメッセージの宛先である請求者金融機関を前記請求 者ＩＤから識別するステップと、 インバウンド支払いメッセージを前記支払いネットワークから前記請求者金融 機関へ送信するステップと、 前記請求者の前記請求者金融機関との口座の貸方に前記インバウンド支払いメ ッセージの前記額を記人するステップと、 少なくとも前記額と前記消費者−請求者口座番号とを含む前記インバウンド支 払いメッセージのデータを、前記請求者に提供するステップと を含むことを特徴とする方法。 ２２．さらに、前記消費者金融機関のために前記消費者から少なくとも資金の 保証を確保するステップを含むことを特徴とする請求項２１に記載の方法。 ２３．さらに、前記支払いメッセージが、前記消費者金融機関が最初に資金を 確保することなしに送信され、その後、前記消費者が資金を利用できなくなった 場合に、支払いメッセージを送信した後所定の時間内に前記消費者金融機関から 前記支払いネットワークへ支払い破棄メッセージを送信するステップを含むこと を特徴とする請求項２１に記載の方法。 ２４．前記請求者にデータを提供する前記ステップが、前記データの中間宛先 としての前記請求者金融機関コンピュータによって実行されることを特徴とする 請求項２１に記載の方法。 ２５．前記請求者にデータを提供する前記ステップが、前記支払いネットワー クと前記請求者との間の接続を介して実行されることを特徴とする請求項２１に 記載の方法。 ２６．前記インバウンド支払いメッセージを生成する前記ステップが実行され るのが、前記アウトバウンド中のデータが検証ステップで検証されたときだけで あることを特徴とする請求項２１に記載の方法。 ２７．さらに、 請求者参照ファイルを検査して、前記アウトバウンド支払いメッセージの前記 請求者ＩＤが活動請求者ＩＤであるかどうかを判定するステップと、 前記アウトバウンド支払いメッセージの前記請求者ＩＤが活動請求者ＩＤでは ないときに前記消費者金融機関へエラー・メッセージを送り返すステップとを含 む検証ステップを含むことを特徴とする請求項２１に記載の方法。 ２８．前記検証ステップがさらに、前記アウトバウンド支払いメッセージの前 記消費者−請求者口座番号を、各請求者ごとの前記請求者参照ファイルに記憶さ れている、妥当な口座番号に関する所定の基準と突き合わせて検査するステップ と、基準が満たされていない場合に、前記消費者金融機関へその旨のエラー・メ ッセージを送り返すステップとを含むことを特徴とする請求項２７に記載の方法 。 ２９．さらに、前記所定の基準が満たされていないときに、前記支払いネット ワークを介して送信される支払いメッセージに、前記所定の基準が満たされなか ったことを示すようにフラグ付けするステップを含むことを特徴とする請求項２ ８に記載の方法。 ３０．さらに、前記消費者金融機関と前記請求者金融機関との間でコストの帳 尻を合わせるために、前記支払いネットワークのオペレータへの処理手数料また は交換手数料のうちの少なくとも一方の振替が行われるように、前記消費者の口 座の借方に記入された前記額、前記消費者金融機関の借方に記入された前記額、 前記請求者金融機関の貸方に記入された前記額のうちの少なくとも１つを調整す るステップを含むことを特徴とする請求項２１に記載の方法。 ３１．前記データ要素の少なくとも１つが、前記消費者金融機関のコンピュー タによって記憶されているデータを指すポインタであり、前記消費者金融機関に よって前記ポインタが前記ポインタの指すデータで置き換えられることを特徴と する請求項２１に記載の方法。 ３２．さらに、新しい消費者−請求者口座番号を実施するために、前記消費者 によって提供された前記消費者−請求者口座番号を、前記請求者によって提供さ れた変換テーブルに従って変換するステップを含むことを特徴とする請求項２１ に記載の方法。 ３３．請求者から消費者への請求額を支払う方法であって、 請求支払い命令を発行する消費者の権限を検証するステップと、 少なくとも資金源と、各消費者ごとの請求者を識別する請求者ＩＤと、請求者 によって割り当てられた顧客−請求者口座番号と、支払い額を示すデータ要素を 備える、消費者からの前記請求支払い命令を消費者金融機関に受け入れるステッ プと、 前記請求支払い命令が保証されている場合、前記消費者金融機関のために前記 消費者から少なくとも資金の保証を確保するステップと、 少なくとも前記額と、前記消費者−請求者口座番号と、前記請求者ＩＤとを含 むアウトバウンド支払いメッセージを前記消費者金融機関から支払いネットワー クへ送信するステップと、 前記アウトバウンド支払いメッセージの宛先である請求者金融機関を前記請求 者ＩＤおよび請求者参照ファイルから識別するステップと、 インバウンド支払いメッセージを前記支払いネットワークから前記請求者金融 機関へ送信するステップと、 前記請求者の前記請求者金融機関との口座の貸方に、前記インバウンド支払い メッセージの前記額に対応する額を記入するステップと、 前記消費者金融機関の借方に、前記インバウンド支払いメッセージの前記額に 対応する額を記入するステップと、 少なくとも前記額と前記消費者−請求者口座番号とを含む前記インバウンド支 払いメッセージのデータを、前記請求者金融機関のコンピュータから提供するス テップと を含むことを特徴とする方法。 ３４．前記データ要素の少なくとも１つが、前記消費者金融機関のコンピュー タによって記憶されているデータを指すポインタであり、前記消費者金融機関に よって前記ポインタが前記ポインタの指すデータで置き換えられることを特徴と する請求項３３に記載の方法。 ３５．消費者が請求者に負っている請求額を支払うために資金を電子的に消費 者から請求者に振り替える支払いネットワークであって、 参加金融機関の取引プロセッサを結合する支払いネットワークと、 消費者によって発行された請求支払い命令に応答して、発信金融機関自体の取 引プロセッサから前記支払いネットワークへ支払いメッセージを発信し、前記支 払いメッセージが、各消費者、すなわち請求者の顧客が使用できるように請求者 に割り当てられた請求者ＩＤによって請求者を識別するものであり、前記請求者 ＩＤが、前記支払いネットワークを使用して請求者に支払いを行いたい消費者に 開示される、発信金融機関と、 前記支払いネットワークからの前記支払いメッセージを受信金融機関自体の取 引プロセッサで受信し、前記受信金融機関と請求者が共に前記請求者ＩＤから識 別できる、受信金融機関と、 前記支払いメッセージに含まれる額に対応する額を、前記発信金融機関の借方 に記入し、かつ前記受信金融機関の貸方に記入する手段と、 消費者の請求者との口座の貸方に、前記支払いメッセージに含まれる前記額を 記入する手段とを備えることを特徴とする支払いネットワーク。