JP4591612B1 - 決済処理方法及び装置 - Google Patents

Abstract

【課題】決済不履行の連鎖を防止しつつ決済手数料を可能な限り削減する。
【解決手段】決済要求を、出金元から決済センタへの資金移動についての前タスクと決済センタから入金先への資金移動についての後タスクに分離して、前タスクが処理されないと後タスクを処理しないようにする。これによって決済不履行の連鎖を防止することができる。なお、処理可能となった後タスクについては前タスクと一緒に処理でき、上記出金元と上記入金先が同じであればタスクの集約を行うことができる。よって集約によって決済額及び決済回数の削減が期待できる。さらに、決済センタの銀行口座を各銀行に設けて同一行内振込にすれば決済手数料の削減も行うことができる。
【選択図】図２

Description

本発明は、決済処理技術に関する。

図１に示すように、ユーザＡ乃至Ｃ間で各種支払いが発生する場合に、同一銀行（例えば銀行Ａ）内に口座があれば比較的安い手数料で送金することができる。ユーザＤ乃至Ｆ間で各種支払いが発生する場合においても同様に、同一銀行（例えば銀行Ｂ）内に口座があれば比較的安い手数料で送金することができる。しかしながら、例えばユーザＢからユーザＤ、ユーザＣからユーザＦのように、異なる銀行間で送金を行う場合には、高い手数料を支払わなければならない。

近年インターネット上で商品販売の店舗を開き、顧客からの注文を受け付け、宅配便にて商品を届けるようなネット販売が広く行われるようになっており、その際の決済には、クレジットカードや、銀行振込、代引きなど様々な手法が用いられている。しかしながら、クレジットカードは手数料が高く店舗側の負担が大きい。また、銀行振込の場合、店舗の口座が同一銀行内に存在すればよいが、異なる銀行の口座に振込を行わなければならない場合には上で述べたように高い手数料を顧客が負担しなければならない。代引きの場合にも、手数料が高く、店舗又は顧客がその手数料を負担しなければならない。

このような決済に関しては様々な従来技術が存在している。例えば、特開平１１−３３７４号公報には、その従来技術として以下のようなシステムが存在しているとしている。すなわち、集中決済システムにより、グループ内でネットワークを介して債権・債務をネッティングし、財務効率の向上を図る。より具体的には、まず、グループ各社が請求、支払い関連のデータをオンラインあるいはメイルボックスによりネットワークに載せ、取引相手の会社宛に伝送する。相手会社は内容を確認し、決済確定データである支払いデータを仲介機関に送る。仲介機関は各社から同様に送られてきたデータを集計し、ネッティングし、その清算尻データを各社に送るとともに、金融機関にもネッティング後のデータを送り、金融機関に設けられた仲介機関の専用口座と各社の口座間で清算尻の付け替えを行う。最終的にはグループ各社が金融機関から入出金通知を受け取ることによってグループ企業間の支払いが完了する。

これに対して、特開平１１−３３７４号公報では、単に債権・債務情報を交換してそれに基づいてのみネッティングを行っているに過ぎないため、現時点の支払側の債務が大きくなりすぎていても構わずネッティングを行って清算尻データを算出し、これに基づいて支払いを行う恐れがある、としている。特に、本公報では、「集中決済システムの場合では、参加者の決済不履行が他の参加者に連鎖的に波及する。つまり、ネットワークに参加している企業の支払い額が高額になると、清算尻データが大きくなり決済不履行となり、グループ内のネッティングのメカニズムが壊れることになる。」と指摘しており、これを避けるために、支払側企業の支払データ受発信装置が債務データである決済確定データを仲介機関のネッティング処理実行部に転送し、ネッティング処理実行部が決済確定データと予め仲介機関の閾値格納装置に格納してある閾値と仲介機関のネッティング情報格納装置に格納してある精算尻データからネッティング処理を行うか判定し、取引の当事者である支払側と受取側の両方に実際にネッティング処理を実行したか否かを知らせる、としている。しかしながら、根本的に決済不履行の連鎖を防止しているわけではない。

また、特開平１１−３１６７９０号公報では、従来の振込送金では大部分が他行振込となるため手数料が自行振込に比べて割高になるといった事態が生じており、また手数料を軽減するため自行振込にするには取引する金融機関の数が膨大となり、手続や管理が複雑化するという問題点を指摘している。そして、これを解決するために、本公報に係る振込送金システムは、振込送金委託者からの少なくとも受取人と被仕向金融機関の情報を含んだ振込送金依頼データを取得する手段と、取得した振込送金依頼データの有効性を判定する手段と、有効性判定手段により有効と判定された振込送金依頼データに含まれる被仕向金融機関に基いて、仕向金融機関を決定する手段と、仕向金融機関決定手段により決定された仕向金融機関に対して受取人の口座のある被仕向金融機関への振込送金実行の指示データを作成する手段と、実行指示データ作成手段により作成された実行指示データを仕向金融機関に対して送信する手段とを有する。この公報記載の技術では、手数料の軽減という観点から、各振込について可能な限り自行振込に変換するような構成を示しており、振込回数の削減はなされていない。

また、特開２００４−２７２４６９号公報には、ネッティングの対象となる複数の取引に対する料金回収の保証を予め一括して取得し、複数の取引をまとめて決済することにより、決済にかかるサーバ処理の負荷を軽減する技術が開示されている。具体的には、ネッティング対象期間における最初の支払い依頼をユーザの端末から受信したときに、金融機関が保証する与信額を与信額記憶領域に格納し、ユーザの端末から受信した支払い依頼の金額を、与信額記憶領域に加算または減算して、残高を書き換える。そして、ネッティング対象期間の経過後に、与信額記憶領域の残高を与信額から差し引いた金額を算出し、差し引いた金額を決済するために、金融機関のサーバに決済金額を通知するものである。この技術では、与信が難しく、結局のところ与信がうまくいかない場合には決済不履行が発生し、その連鎖を招くことになりかねない。

さらに、特開２００２−３２９１５５号公報には、単に２社間の相殺決済処理のみならず、３社以上の所定の関係にある企業間の相殺決済をコンピュータによって自動的に行い、決済のための送金手数料を軽減して様々な事務処理の効率化を図るための技術が開示されている。具体的には、ネットワークを通じて相互に商取引を実行する、複数の取引部門から閲覧できるデータファイルを保持したサーバを設け、このサーバでは、相互に商取引を実行する複数の取引部門の、全ての相互取引にかかわる取引額を記録した受発注履歴と、記録された所定期間の取引額を参照して、全ての取引部門相互間の上記所定期間の債務額と債権額の累積値を計算する一次決済処理を実行し、この一時決済処理の結果を利用して、上記全ての取引部門を含む系全体を仮想取引先としたときの、この仮想取引先に対する各取引部門の債務額または債権額を計算する二次決済処理を実行した結果を記録した相殺履歴と、上記仮想取引先に対して債務を負ういずれかの取引部門から、上記仮想取引先に対して債権を持ついずれかの取引部門に対して、自己の債務額の範囲で送金をする送金額を決定する処理を実行した結果を記録した振込先決定履歴と、各部門の上記送金額を含む相殺処理の承認処理結果を記録した承認履歴とを保持するものである。しかしながら、この技術では必ずしも決済の手間を削減できない場合があり、さらに決済不履行が発生すると、その影響が波及するおそれがある。

また、特開２００２−２１５８９３号公報には、顧客が取引毎にそれぞれの取引銀行に対して送金手続を行う場合に、顧客は手数料を送金毎に払う必要があり、送金に伴う事務的負荷及び送金手数料の負担が大きいという問題に着目している。そして、顧客端末は送金を希望する旨及び送金額を含む情報を送信する。送金管理システムは顧客端末から上記した情報を受信すると、送金先を確認し、通知部を用いて入金先を顧客端末に通知する。ここで通知される送金先は第１口座である。顧客端末は、送金管理システムから入金先の通知を受けると入金先を表示する。そして顧客端末は、入金が済んだ場合にその旨を知らせる通知を送金管理システムに送信する。そして送金管理システムは、通知を受けた入金が実際に行われたかどうかを、自己が管理する口座である第１口座に確認する。送金管理システムは、入金を確認すると送金データベースに所定のデータを格納する。そして、送金管理システムは送金元変換部を用いて送金元を送金元口座から第２口座に変換する。そして分類部により同一期間に分類された送金のうち、第２口座から送金先口座への送金が他にあるかどうかを確認する。第２口座から送金先口座への送金が他にあった場合、送金管理システムは、送金合成部、削減額算出部、およびコスト設定部を用いて送金を合成し、送金を合成する旨を顧客端末に通知する。ここで、通知される情報には、送金合成による手数料削減額とコストとの比較結果の他、送金合成により送金日が顧客が指定した送金日と異なった場合には、その旨も含まれる。そして、顧客端末は送金合成通知を表示し、顧客が送金合成を確認して了承すると確認通知を送信する。送金管理システムは、顧客端末から確認通知を受信すると、指示部を用いて第２口座に送金を指示する。基本的に、本公報の技術では、同一の顧客について送金合成を行うようになっており、決済不履行の波及はないが、決済不履行の波及について考察されているわけではない。また、同一顧客についてのみ送金合成を行うので、全体としての手数料削減効果は大きくない。

特開平１１−３３７４号公報 特開平１１−３１６７９０号公報 特開２００４−２７２４６９号公報 特開２００２−３２９１５５号公報 特開２００２−２１５８９３号公報

以上述べたように、送金元と送金先の間に仲介機関を設けて決済を行うようなシステムは存在しているが、そのようなシステムにおいて決済不履行の連鎖を防止するような根本的な対策は施されていない。また、結果的に決済不履行の連鎖を防止できているものはあるが、手数料削減効果がその分限られてしまっている。

従って、本発明の目的は、決済不履行の連鎖を防止しつつ決済手数料を可能な限り削減するための技術を提供することである。

本発明に係る決済処理方法は、（Ａ）１又は複数の出金元及び金額と１又は複数の入金先及び金額とを含む支払要求及び請求要求を、顧客端末から受信し、要求データ格納部に格納するステップと、（Ｂ）要求データ格納部に格納されている支払要求及び請求要求を、出金サイドである１の出金元から入金サイドである決済センタへ第１の処理日に資金移動させる１又は複数の第１のタスクと出金サイドである決済センタから入金サイドである１の入金先へ資金移動させる１又は複数の第２のタスクに分解し、１又は複数の第１のタスクのデータと１又は複数の第２のタスクのデータとを含むジョブデータをジョブデータ格納部に格納するステップと、（Ｃ）ジョブデータ格納部に格納されているジョブデータのうち処理基準日が処理日として設定されている第１のタスク及び第２のタスクを抽出し、出金サイドと入金サイドとの組み合わせが同一である第１のタスク及び第２のタスクの資金移動の金額を集約して、バンドル識別子と出金サイドの識別データと入金サイドの識別データと集約決済金額と集約された第１及び第２のタスクの識別子とを含むバンドルデータを生成し、バンドルデータ格納部に格納するステップと、（Ｄ）バンドルデータ格納部に格納されているバンドルデータに基づく決済依頼を金融機関コンピュータに出力するステップと、（Ｅ）金融機関コンピュータから決済依頼の処理結果を受信した場合、当該決済依頼の処理結果を、バンドルデータ格納部に格納されており且つ当該決済依頼の処理結果に係るバンドルデータに反映させるステップと、（Ｆ）処理結果が決済成功を表しているバンドルデータに含まれるタスクの識別子に第１のタスクの識別子が含まれている場合には、ジョブデータ格納部に格納されているジョブデータのうち当該第１のタスクに対応する第２のタスクのデータに第２の処理日を設定するステップとを含む。

（Ｂ）を実施することによって、支払要求及び請求要求とを決済センタへの資金移動についての第１のタスクと、決済センタからの資金移動についての第２のタスクとに分解される。決済不履行の連鎖を防止するためには、このように分解を実施した上で、決済センタへの支払に相当する第１のタスクを優先して処理することが必要である。従って、第１のタスクについては第１の処理日を（Ｂ）において設定すると共に、第２のタスクについては、（Ｆ）において対応する第１のタスクについて決済成功が確認されれば第２の処理日を設定する。さらに、（Ｃ）において、処理基準日が処理日として設定されている第１のタスク及び第２のタスクであって、出金サイドと入金サイドとの組み合わせが同一である第１のタスク及び第２のタスクを集約することで、効果的に決済回数を削減して決済手数料を削減できるようになる。なお、決済センタの口座を各銀行に設けておくことにより、同一銀行内における振込で対処可能となり、手数料削減効果が高くなる。

また、本決済処理方法は、処理結果が決済不成功を表しているバンドルデータに含まれるタスクの識別子に第１のタスクの識別子が含まれている場合には、ジョブデータ格納部に格納されている第１のタスクのデータに処理実施日より後の第３の処理日を設定するステップと、処理結果が決済不成功を表しているバンドルデータに含まれる出金サイドの識別データに対応する顧客宛に決済不成功を表す警告を出力するステップとをさらに含むようにしてもよい。第１のタスクについて決済不成功が確認される場合には、第１のタスクについては、再度決済を行うため処理日を後日（すなわち第３の処理日）に変更して、出金サイドの顧客に警告を行うものである。一度でも失敗した場合には、当該第１のタスクについては再度決済を行わないようにしても良い。なお、どのような場合においても、第１のタスクについて決済が失敗した場合には、対応する第２のタスクについては処理日の設定は行わない。これによって決済不履行の連鎖を防止できる。

さらに、第１のタスクのデータが、出金サイドの識別データと入金サイドの識別データと正の金額と第１の処理日とを含むようにしてもよい。その際には、第２のタスクのデータが、入金サイドの識別データと出金サイドの識別データと負の金額と対応する第１のタスクについて決済成功が登録されている場合には第２の処理日とを含むようにしてもよい。このようにすれば、（Ｃ）の処理が容易になる。なお、第１及び第２のタスクのデータには、当該タスクについて決済依頼の処理結果を受信した場合には処理結果が含まれるようにしてもよい。これによって、問題を後に特定しやすくなる。

なお、処理基準日が、処理実施日である場合には、処理結果が決済不成功を表しているバンドルデータに含まれるタスクの識別子に第２のタスクの識別子が含まれている場合には、ジョブデータ格納部に格納されている第２のタスクのデータに処理実施日より後の第４の処理日を設定するようにしてもよい。一方、処理基準日が、処理実施日以前の日である場合には、処理結果が決済不成功を表しているバンドルデータに含まれるタスクの識別子に第２のタスクの識別子が含まれている場合には、ジョブデータ格納部に格納されている第２のタスクのデータに設定されている第２の処理日を維持する又は処理実施日より後の第４の処理日を設定するようにしてもよい。これによって、後に（Ｃ）で決済不成功に係る第２のタスクを再度集約できるようになる。なお、第２のタスクについて決済不成功というのは、共に集約された第１のタスクの影響を受けたものであり、基本的には実施して問題ないのないタスクである。従って、処理基準日の定義に従って処理日を変更する又は維持することによって、後の（Ｃ）の処理で適切に処理されるようになる。

なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、決済不履行の連鎖を防止しつつ決済手数料を可能な限り削減することができるようになる。

図１は、従来技術を説明するための図である。 図２は、本発明の実施の形態を説明するための概要図である。 図３（ａ）乃至（ｃ）は、本実施の形態の概要を説明するための図である。 図４（ａ）乃至（ｄ）は、本実施の形態の概要を説明するための図である。 図５は、本実施の形態におけるシステム概要図である。 図６は、決済センタサーバの機能ブロック図である。 図７は、ユーザデータ格納部に格納されるデータの一例を示す図である。 図８は、本実施の形態における処理フローを示す図である。 図９（ａ）乃至（ｄ）は、支払要求及び請求要求の一例を示す図である。 図１０（ａ）乃至（ｄ）は、ジョブデータの一例を示す図である。 図１１は、バンドル処理部によって抽出されるタスクデータの一例を示す図である。 図１２は、バンドル処理部による集約を説明するための図である。 図１３は、バンドルテーブル格納部に格納されるデータの一例を示す図である。 図１４は、決済テーブル格納部に格納されるデータの一例を示す図である。 図１５は、全銀協ファイルフォーマットを示す図である。 図１６は、全銀協ファイルフォーマットを示す図である。 図１７は、本実施の形態における処理フローを示す図である。 図１８は、決済結果データの一例を示す図である。 図１９は、決済結果データに基づき修正した後のバンドルデータの一例を示す図である。 図２０（ａ）乃至（ｄ）は、ジョブテーブル更新部により更新処理を実施した後のジョブデータの一例を示す図である。 図２１は、本実施の形態における処理フローを示す図である。 図２２は、図１９の後にバンドル処理部によって抽出されるタスクデータの一例を示す図である。 図２３は、バンドル処理部による集約を説明するための図である。 図２４は、バンドルテーブル格納部に格納されるデータの一例を示す図である。 図２５は、決済テーブル格納部に格納されるデータの一例を示す図である。 図２６は、決済結果データの一例を示す図である。 図２７は、バンドルテーブル格納部に格納されるデータの一例を示す図である。 図２８（ａ）乃至（ｄ）は、ジョブテーブル更新部により更新処理を実施した後のジョブデータの一例を示す図である。 図２９は、コンピュータの機能ブロック図である。

図２に、本発明の実施の形態における資金移動の模式図を示す。図２に示すように、本実施の形態では、例えば銀行Ａに口座を有する参加ユーザＡ乃至Ｃは、たとえ銀行Ｂ等の他の銀行の口座との資金移動であっても、銀行Ａ内の決済センタの口座との間で資金移動を行う。同様に、銀行Ｂに口座を有する参加ユーザＤ乃至Ｆは、たとえ銀行Ａ等の他の銀行の口座との資金移動であっても、銀行Ｂ内の決済センタの口座との間で資金移動を行う。このようにすることによって、銀行間振込を可能な限りなくすことができ決済手数料を削減することができる。なお、例えば銀行Ａの決済センタの口座と銀行Ｂの決済センタの口座との間で資金移動が必要となる場合もある。これは、一方の口座に資金が貯まってしまい、他方の口座で残高が不足する場合が生じ得るためである。このような決済センタの口座間の資金移動については、何らかの監視手段を用意して別途処理するものとし、本実施の形態では触れないものとする。

なお、場合によっては、参加ユーザＧの口座が、決済センタの口座のない銀行Ｃにある場合もある。このような場合には、例外として例えば銀行Ａの決済センタの口座との間で資金移動を実施する。本実施の形態は、このような例外を許容するものではあるが、原則としては、同一銀行内に設けられる決済センタの口座と参加ユーザの口座間で資金移動を実施するものとする。

さらに、本実施の形態では、単純な振込、すなわち自らの出金元口座から相手先の入金先口座への資金移動だけではなく、請求、すなわち他人の出金元口座から自らの入金先口座への資金移動をも処理できるようにする。

そして、例えば図３（ａ）に示すように、ユーザＡからユーザＢへのａ円の支払とユーザＡからユーザＣからのｂ円の支払とユーザＡからユーザＤへのｃ円の支払とがユーザＡから要求され、ユーザＣからユーザＥに対するｄ円の請求とユーザＣからユーザＦに対するｅ円の請求とユーザＣからユーザＧに対するｆ円の請求とがユーザＣから要求されるものとする。

本実施の形態では、ユーザから決済センタへの資金移動についての前タスクと、決済センタからユーザへの資金移動についての後タスクとに分解する。この分解によって生成される前タスクが処理されない場合には対応する後タスクを処理しないという条件を採用することによって、決済不履行の連鎖を防止できるようになる。

例えば、図３（ａ）に示したような要求が存在する場合には、図３（ｂ）に示すように、ユーザＡから決済センタへのａ円の資金移動についての前タスクと、ユーザＡから決済センタへのｂ円の資金移動についての前タスクと、ユーザＡから決済センタへのｃ円の資金移動についての前タスクと、ユーザＥから決済センタへのｄ円の資金移動についての前タスクと、ユーザＦから決済センタへのｅ円の資金移動についての前タスクと、ユーザＧから決済センタへのｆ円の資金移動についての前タスクとが生成される。

これに対して、図３（ｃ）に示すように、決済センタからユーザＢへのａ円の資金移動についての後タスクと、決済センタからユーザＣへのｂ円の資金移動についての後タスクと、決済センタからユーザＤへのｃ円の資金移動についての後タスクと、決済センタからユーザＣへのｄ円の資金移動についての後タスクと、決済センタからユーザＣへのｅ円の資金移動についての後タスクと、決済センタからユーザＣへのｆ円の資金移動についての後タスクとが生成される。

なお、図３（ｂ）に示した前タスクは、図３（ａ）の支払を３つのジョブ単位としてみなした場合に生成されるものであり、１つのジョブ単位として生成する場合にはユーザＡから決済センタへの（ａ＋ｂ＋ｃ）円の資金移動についての前タスクが１つ生成される。同様に、図３（ｃ）に示した後タスクは、図３（ａ）の請求を３つのジョブ単位としてみなした場合に生成されるものであり、１つのジョブ単位として生成する場合には決済センタからユーザＣへの（ｄ＋ｅ＋ｆ）円の資金移動についての後タスクが１つ生成される。後に述べる詳細な説明では後者を採用するが、このように細分化した形でタスクを生成すれば、決済不履行の場合に留め置かれるタスクが少なくなるという利点がある。一方、保持すべきデータの量は増加するので、いずれを採用するかは、運用において決めればよい。

この後、上で述べたように前タスクを優先して処理する。但し、対応する前タスクが正常に決済できていれば後タスクも処理できる。図３の例では、同じユーザと決済センタとの組み合わせに係る前タスクを集約する。具体的には、図４（ａ）に示すように、ユーザＡから決済センタへの資金移動についての前タスクを全てまとめると、ユーザＡから決済センタへの（ａ＋ｂ＋ｃ）円の資金移動についてのバンドルデータを生成する。なお、ユーザＥ乃至Ｇから決済センタへの資金移動についての前タスクについては集約できないので、個別にバンドルデータを生成する。このバンドルデータに基づき、各銀行に対して振込処理を実施させる。

図４（ａ）に示すようなバンドルデータに基づく決済処理が正常に完了すれば、図３の例では、同じユーザと決済センタとの組み合わせに係る後タスクを集約する。この段階で、後から受信した要求についての前タスクが存在すればいっしょに集約する。具体的には、図４（ｂ）に示すように、決済センタからユーザＣへの（ｂ＋ｄ＋ｅ＋ｆ）円の資金移動についてのバンドルデータを生成する。なお、決済センタからユーザＢ及びＤへの資金移動についての後タスクについては集約できないので、個別にバンドルデータを生成する。このバンドルデータに基づき、各銀行に振込処理を実施させる。

このようにすれば、決済不履行の連鎖を防止しつつ、可能な限りタスクを集約することで、決済手数料が抑制されるようになる。

なお、ユーザＦから決済センタへのｅ円の資金移動についてのバンドルデータに基づく決済処理が失敗した場合には、対応する後タスクである、決済センタからユーザＣへのｅ円の資金移動についての後タスクについては集約の対象外となる。この場合、図４（ｃ）に示すように、図４（ｂ）の２番目のバンドルデータに代わり、決済センタからユーザＣへの（ｂ＋ｄ＋ｆ）円の資金移動についてのバンドルデータとなる。なお、上で述べたように、決済センタからユーザＣへの資金移動についての後タスクが、完全に１つとなっている場合には、図４（ｄ）に示すように、図４（ｂ）の２番目のバンドルデータに代わり、決済センタからユーザＣへのｃ円の資金移動についてのバンドルデータが生成される。このバンドルデータに基づき、各銀行に振込処理を実施させる。

以上のような基本的な動作を具体的に実現するためのシステムについて、以下説明する。

図５に、本実施の形態に係るシステムの概要を示す。図５に示すように、インターネットその他のコンピュータネットワーク１には、本実施の形態において主要な処理を実施する決済センタサーバ３と、複数のユーザ端末Ａ乃至Ｄと、複数の銀行Ｅ乃至Ｇの銀行サーバＥ乃至Ｇとが接続されている。銀行サーバＥ乃至Ｇは、例えば現在銀行において用いられているコンピュータで問題ないので、これ以上述べない。数も任意である。また、ユーザ端末Ａ乃至Ｄは、例えばＷｅｂブラウザなどのアプリケーション・プログラムが実行されているパーソナルコンピュータであり、特別な機能は不要であるのでこれ以上述べない。数も任意である。但し、端末装置ではなく、決済用のサーバであってもよい。この場合には、以下で述べるようなデータを決済センタサーバ３に送信するような機能を有していればよい。また、コンピュータネットワーク１については、例えば決済センタサーバ３とユーザ端末Ａ乃至Ｄを接続するネットワークと、決済センタサーバ３と銀行サーバＥ乃至Ｇを接続するネットワークとに分離される場合もある。

次に決済センタサーバ３の構成を図６に示す。決済センタサーバ３は、ユーザ端末Ａ乃至Ｄから支払要求及び請求要求を受信する要求受信部３１と、要求受信部３１が受信した要求データを格納する要求データ格納部３２と、ユーザについてのデータを格納するユーザデータ格納部３４と、ユーザデータ格納部３４及び要求データ格納部３２に格納されているデータを用いて前タスク及び後タスクのデータを生成する処理を実施するアンバンドル処理部３３と、アンバンドル処理部３３の処理結果を格納するジョブテーブル格納部３６と、ユーザデータ格納部３４とジョブテーブル格納部３６とに格納されているデータを用いてユーザに対して決済確認を行う確認処理部３５と、ユーザデータ格納部３４とジョブテーブル格納部３６とに格納されているデータを用いて決済処理可能なタスクのデータを集約するバンドル処理を実施するバンドル処理部３８と、バンドル処理部３８によって生成されたバンドルデータを格納するバンドルテーブル格納部３９と、バンドルテーブル格納部３９に格納されているデータを用いてバンドル処理部３８によって生成され且つ銀行サーバＥ乃至Ｇに送信するためのデータを格納する決済テーブル格納部４０と、決済テーブル格納部４０に格納されているデータを銀行サーバＥ乃至Ｇに送信し且つ銀行サーバＥ乃至Ｇから決済処理の処理結果を受信してバンドルテーブル格納部３９に当該処理結果を反映させる銀行サーバインタフェース部４１と、バンドルテーブル格納部３９とユーザデータ格納部３４と要求データ格納部３２とに格納されているデータを用いてジョブテーブルの更新を行うジョブテーブル更新部３７とを有する。

なお、ジョブテーブル更新部３７は、銀行サーバインタフェース部４１及びバンドル処理部３８と連携して処理を実施する。

ユーザデータ格納部３４には、例えば図７に示すようなデータが格納されている。図７の例では、ユーザ毎に、ユーザＩＤと、ユーザ名と、銀行口座のデータと、メールアドレスと、不履行カウンタと、格付とが登録されるようになっている。不履行カウンタは、決済処理が失敗した回数をカウントするためのカウンタであり、この不履行カウンタの値に応じて格付が決定される。格付は、例えば、前タスクが完了した後後タスクが実施されるまでの期間を決定するため等に用いる。このほか、決済センタが管理すべきユーザのデータが格納される。

次に、図８乃至図２８を用いて図５及び図６に示したシステムの処理内容について説明する。まず、例えばユーザＡがユーザ端末Ａを操作して、ユーザ端末Ａに支払要求又は請求要求を決済センタサーバ３へ送信させる。支払要求は、出金元のユーザＩＤと出金日と出金金額とを含む出金データと、入金先のユーザＩＤと入金日と入金金額とを含む入金データを１又は複数セット含む。また、請求要求は、入金先のユーザＩＤと入金日と入金金額とを含む入金データと、出金元のユーザＩＤと出金日と出金金額とを含む出金データを１又は複数セット含む。

以下の説明を分かりやすくするように、図９（ａ）乃至（ｄ）のような支払要求及び請求要求について処理するものとする。図９（ａ）の支払要求では、出金元のユーザＩＤが「Ａ」であり、出金日が「２００９年４月１日」であり、出金金額が「７万円」であり、入金先のユーザＩＤが「Ｃ」であり、入金日が「２００９年４月３日」であり、入金金額が「７万円」である。図９（ｂ）の支払要求では、出金元のユーザＩＤが「Ｃ」であり、出金日が「２００９年４月１日」であり、出金金額が「１５万円」であり、入金先のユーザＩＤが「Ａ」であり、入金日が「２００９年４月３日」であり、入金金額が「４万円」であり、入金先のユーザＩＤが「Ｂ」であり、入金日が「２００９年４月３日」であり、入金金額が「５万円」であり、入金先のユーザＩＤが「Ｄ」であり、入金日が「２００９年４月３日」であり、入金金額が「６万円」である。

図９（ｃ）の請求要求では、入金先のユーザＩＤが「Ｄ」であり、入金日が「２００９年４月６日」であり、入金金額が「８万円」であり、出金元のユーザＩＤが「Ｃ」であり、出金日が「２００９年４月３日」であり、出金金額が「８万円」である。図９（ｄ）の請求要求では、入金先のユーザＩＤが「Ｂ」であり、入金日が「２００９年４月３日」であり、入金金額が「６万円」であり、出金元のユーザＩＤが「Ａ」であり、出金日が「２００９年４月１日」であり、出金金額が「１万円」であり、出金元のユーザＩＤが「Ｃ」であり、出金日が「２００９年４月１日」であり、出金金額が「２万円」であり、出金元のユーザＩＤが「Ｄ」であり、出金日が「２００９年４月１日」であり、出金金額が「３万円」である。

決済センタサーバ３の要求受信部３１は、例えばユーザ端末Ａから支払要求又は請求要求を受信し、要求データ格納部３２に格納する（図８：ステップＳ１）。この段階で各要求に対してジョブ番号を発行して登録すると共に、要求元ユーザ端末に通知するようにしても良い。そして、アンバンドル処理部３３は、要求データ格納部３２に格納されている支払要求又は請求要求のジョブデータを生成し、ジョブテーブル格納部３６に格納する（ステップＳ３）。図９に示した支払要求及び請求要求に対応するジョブデータの例を図１０に示す。

図１０（ａ）が、図９（ａ）に示した支払要求に対応するジョブデータである。図１０（ａ）のジョブデータは、シリアルに付与されるジョブ番号「３」と、生成される前タスクの数「１」と、生成される後タスクの数「１」と、前タスクのデータと、後タスクのデータとを含む。シリアルに付されるジョブ番号については、要求データ格納部３２に格納されている対応要求データにも同じ番号を登録しておく。図９（ａ）の場合には、決済センタへの資金移動についての前タスクが１つと、決済センタからの資金移動についての後タスクが１つ生成される。前タスクのデータ及び後タスクのデータのフォーマットは基本的に共通で、番号と、依頼日と、口座情報１と、口座情報２と、金額と、処理実施日と、結果とを含むようになっている。本実施の形態では、前タスクでも後タスクでも口座情報２には「センタ」（決済センタ）を設定するようにして、前タスクでは金額に正の値を設定し、後タスクでは金額に負の値を設定する。これによって、前タスクと後タスクを後のバンドル処理で集約する場合に、集約できるタスクを簡単に特定でき且つ金額についても単に加算すれば良くなる。また、前タスクと後タスクは対応関係があるので、前タスク番号と後タスク番号とで対応関係が判別できるようにしている。例えば、前タスク番号は、ジョブ番号＋Ｂ＋タスク番号で表され、後タスクは、ジョブ番号＋Ａ＋タスク番号で表される。すなわち、同一ジョブ番号であれば「Ａ」と「Ｂ」とで対応関係が分かる。図１０（ａ）の例では、前タスク番号は「３Ｂ１」であり、後タスク番号「３Ａ１」となる。また、前タスクの依頼日については、要求に含まれる依頼日をそのまま設定する。但し、アンバンドル処理部３３が、要求受信日から所定日後というように自動設定するようにしても良い。後タスクの依頼日については、対応する前タスクが正常に実行されないと決定できないので、適切な将来の日（図１０では３０００年）を設定する。前タスクの口座情報１には、要求における出金元のユーザＩＤ（又はアンバンドル処理部３３がユーザデータ格納部３４から読み出した銀行口座情報）を設定する。後タスクの口座情報１には、要求における入金先のユーザＩＤ（又は銀行口座情報）を設定する。

図９（ｂ）の支払要求に対応するジョブデータを図１０（ｂ）に示す。図９（ｂ）から分かるように、決済センタへの資金移動についての前タスクは１つであり、決済センタからの資金移動についての後タスクは３件である。前タスクのデータ構成及び後タスクのデータ構成については図１０（ａ）と同様である。前タスクの前タスク番号は、ジョブ番号が「２」であるので、「２Ｂ１」であり、後タスクの後タスク番号は、「２Ａ１」「２Ａ２」「２Ａ３」となる。

同様に、図９（ｃ）の請求要求に対応するジョブデータを図１０（ｃ）に示す。図９（ｃ）から分かるように、決済センタへの資金移動についての前タスクは１つであり、決済センタからの資金移動についての後タスクも１件である。前タスクのデータ構成及び後タスクのデータ構成については図１０（ａ）と同様である。前タスクの前タスク番号は、ジョブ番号が「４」であるので、「４Ｂ１」であり、後タスクの後タスク番号は、「４Ａ１」となる。

なお、請求要求については、当該請求要求が、被請求側の承認済みでなければ処理してはならない。請求側又は被請求側が被請求側から承認を得た後に、決済センタサーバ３に請求要求を送信するという運用が確立している場合には決済センタサーバ３で特別な処理は不要である。決済センタサーバ３で被請求側の承認を得た後に処理する場合には、例えば前タスクの依頼日に請求要求に含まれる依頼日を登録することなく、例えば「要承認」を表すデータを登録しておく。そうすれば、確認処理部３５が、新規にジョブテーブル格納部３６に登録された前タスクのデータに含まれる「依頼日」を確認して、「要承認」を表すデータを特定した場合には、「口座情報１」のデータから承認依頼先ユーザのメールアドレスを特定し、前タスクの金額と後タスクの「口座情報１」から特定される請求元ユーザ名及びユーザＩＤとジョブ番号とを含む確認メールを送信する。なお、要求データ格納部３２にアクセスして、出金「依頼日」を確認メールに含めるようにしても良い。承認依頼先ユーザは、ユーザ端末を操作して、確認メールに基づき承認する場合には例えば決済センタサーバ３の確認処理部３５にアクセスし、承認を登録する。確認処理部３５は、承認の登録を受け付けた場合には、該当するジョブの前タスクの依頼日に、例えば承認登録日から所定日後の日付を登録する。請求要求に含まれる出金「依頼日」に間に合う場合には、当該出金「依頼日」を登録するようにしても良い。一方、拒否する場合には、ユーザ端末を操作して、決済センタサーバ３の確認処理部３５にアクセスし、拒否を登録する。確認処理部３５は、拒否の登録を受け付けた場合には、該当するジョブの後タスクの「口座情報１」から特定される請求元ユーザＩＤでユーザデータ格納部３４を検索して対応するメールアドレスを特定し、ジョブ番号等を含む拒否通知をメールで送信する。さらに、当該請求元ユーザＩＤについてのレコードにおける不履行カウンタを所定の値だけインクリメントする。拒否されるような請求を登録した場合には、決済不履行と同様に問題があるためである。拒否されたジョブデータについては、この段階で削除するようにしてもよいが、前タスクの依頼日に日付が設定されない限り、処理されないので、このまま保持しておき、例えば該当する前タスクの「結果」に「拒否」データを登録しておき、後に参照するようにしても良い。実施日にも拒否日を登録しておくようにしても良い。

さらに、図９（ｄ）の請求要求に対応するジョブデータを図１０（ｄ）に示す。図９（ｄ）から分かるように、決済センタへの資金移動についての前タスクは３件であり、決済センタからの資金移動についての後タスクは１件である。前タスクのデータ構成及び後タスクのデータ構成については図１０（ａ）と同様である。前タスクの前タスク番号は、ジョブ番号が「１」であるので、「１Ｂ１」「１Ｂ２」「１Ｂ３」であり、後タスクの後タスク番号は、「１Ａ１」となる。承認に関する事項は、上で述べたとおりであり、前タスクの依頼日については、承認後に請求要求を受け取っている場合には、請求要求に含まれる依頼日を登録し、承認前に請求要求を受け取っている場合には、上で述べたように承認日から所定日数後の日付を登録する。可能な場合には出金「依頼日」を登録するようにしても良い。

請求要求についてのジョブデータであっても、支払要求についてのジョブデータと同様に、後タスクについては「依頼日」を最初はあり得ないような将来の値にするか登録しない。これによって、前タスクの優先性が担保される。

なお、図８においてステップＳ１及びＳ３は、以下の処理とは非同期に実施されるが、説明の都合上連結された処理フローとして説明されている。

図８の説明に戻って、バンドル処理部３８は、処理実施日を特定する（ステップＳ５）。例えば、システムの時計で現日付を処理実施日として特定する。そして、バンドル処理部３８は、依頼日が処理実施日以前となっているタスクデータを、ジョブテーブル格納部３６から抽出する（ステップＳ７）。図１０に示したようなデータがジョブテーブル格納部３６に格納されている場合であって、処理実施日が「２００９年４月１日」であれば、図１１に示すようなタスクデータが抽出される。図１０の例では、まだ後タスクには依頼日が設定されていないので、「４月１日」を依頼日とする前タスクだけが抽出される。すなわち、前タスク番号「１Ｂ１」「１Ｂ２」「１Ｂ３」「２Ｂ１」「３Ｂ１」のタスクデータである。なお、前タスク番号「４Ｂ１」の前タスクデータの依頼日は「４月３日」なので今回は抽出されない。

その後、バンドル処理部３８は、抽出されたタスクデータにおける「口座情報１」と「口座情報２」すなわち出金元と入金先との組み合わせ毎に（本実施の形態では実質的に「口座情報１」）、タスクデータを集約することによってバンドルデータを生成し、バンドルテーブル格納部３９に登録する（ステップＳ９）。同一口座間の入出金を集約して決済回数を減らすためである。これによって決済手数料の削減が図られる。図１１に示すようなタスクデータが抽出された場合には、図１２に示すように、タスクデータは分類される。すなわち、「口座情報１」が「Ａ」であるグループと、「口座情報１」が「Ｃ」であるグループと、「口座情報１」が「Ｄ」であるグループである。図１２から分かるように、同じグループのタスクデータで異なるのは、タスク番号と金額だけである。なお、依頼日も以下で述べるように異なる場合もあるが、ステップＳ９では大きな意味を有さない。金額については、単純に加算することによって集約される。図１２のグループ毎にタスクデータを集約すると、図１３に示すようなバンドルデータが生成される。図１３から分かるように、バンドルデータは、バンドル番号、依頼日、入金先又は出金元の口座情報１、決済センタを表す口座情報２、集約されたタスクの合計金額である金額、処理実施日、結果、集約されたタスク数、集約されたタスク番号を含む。バンドル番号は、例えば日付＋シリアル番号で構成される。タスク番号は、集約されたタスクの数だけ列挙される。

さらに、バンドル処理部３８は、ユーザデータ格納部３４に格納されているデータ及びバンドルテーブル格納部３９に新たに登録したバンドルデータから決済データを生成し、決済テーブル格納部４０に登録する（ステップＳ１１）。決済データについては、図１５（総合振込、給与振込、賞与振込に適用する場合）及び図１６（口座振替の場合）に示すような周知の全銀ファイルフォーマットに従ったデータである。また、決済データを模式的に示すと図１４に示すようなデータである。図１４の例では、依頼日に関連付けて、決済データの識別子（Ａｂｋなど）と振込データ（バンドル番号を含む）とのセットを１又は複数含むようになっている。バンドル番号は、図１５及び図１６に示すようにヘッダーレコードのダミー欄に含められる。振込データにおいてバンドルデータから抽出できないデータについては、ユーザデータ格納部３４に格納されているデータを用いる。なお、決済センタの口座番号については、入金先又は出金元の銀行と同じ銀行の口座を用いる。図１５及び図１６のようなデータの生成は周知であり、本実施の形態では、バンドル番号を含め、決済センタの口座番号を適切に選択することで生成可能であるため、これ以上述べない。

そして、銀行サーバインタフェース部４１は、決済テーブル格納部４０に登録されている、依頼日が現在日となっている決済データを読み出し、ネットワーク１を介して当該決済データが該当する銀行サーバ（仕向金融機関番号に対応する銀行の銀行サーバ）へ送信する（ステップＳ１３）。この部分も周知であるからこれ以上述べない。処理は、端子Ａを介して図１７の処理に移行する。

図１７の処理の説明に移行して、銀行サーバインタフェース部４１は、銀行サーバから決済結果データを受信し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１５）。例えば図１８のような決済結果データを受信する。図１８の例では、決済データの識別子と処理実施日と結果とを含む。図示していないが、バンドル番号を含む場合もある。

その後、銀行サーバインタフェース部４１は、バンドルテーブル格納部３９において当該決済結果データに該当するバンドルデータに処理実施日及び結果を登録する（ステップＳ１７）。該当するバンドルデータを特定するのは、例えば決済データの識別子で、決済テーブル格納部４０を検索してバンドル番号を特定するか、決済結果データに含まれるバンドル番号を用いる。図１８に示したような決済結果データの場合には、全件決済成功を示しているので、図１９に示すように、該当するバンドルデータの処理実施日に「４月１日」を登録すると共に、結果として成功を表す「１」を登録する。そして、銀行サーバインタフェース部４１は、ジョブテーブル更新部３７に決済結果データに係るバンドル番号及び処理実施日を通知する。

その後、ジョブテーブル更新部３７は、決済結果データに係るバンドル番号から、バンドルテーブル格納部３９において該当バンドルデータを特定すると共に、該当するタスク番号を特定し、ジョブテーブル格納部３６において該当タスク番号に係るタスクデータを特定し、当該タスクデータに処理実施日及び結果を登録する（ステップＳ１９）。図１９の例では、該当タスク番号は「１Ｂ１」「３Ｂ１」「１Ｂ２」「２Ｂ１」「１Ｂ３」であり全て処理実施日は「４月１日」で結果は成功である。従って、図２０に示すように、該当するタスクの処理実施日には「４月１日」が、結果には成功を表す「１」が登録される。なお、不成功である場合には、初回であれば結果は「△１」で、２回目は「△２」といったようにカウントアップされていく。

さらに、ジョブテーブル更新部３７は、未処理の該当タスクデータを１件特定し（ステップＳ２１）、結果が成功を示しているか判断する（ステップＳ２３）。成功している場合には、ジョブテーブル更新部３７は、当該タスクデータが前タスクについてのタスクデータであって同一ジョブデータの全ての前タスクの結果が成功であり且つ対応する後タスクの依頼日が未設定であるか確認し、この条件を満たしていれば対応する後タスクに依頼日を設定する（ステップＳ２５）。そして処理はステップＳ３５に移行する。

上の例では、前タスク「１Ｂ１」を処理する場合には、同一ジョブデータに含まれる他の前タスク「１Ｂ２」「１Ｂ３」も成功を表しており、図１９の前段階では対応する後タスク「１Ａ１」には依頼日が設定されていないので、ここで依頼日を設定する。なお、依頼日については、例えばジョブ番号で要求データ格納部３２を検索して、該当する要求データから後タスクのための依頼日を特定し、当該依頼日を設定するようにしても良い。また、処理実施日の所定日数後に設定しても良い。その際、例えばユーザデータ格納部３４に格納されている資金移動先のユーザの格付に応じた日数を所定日数として用いても良い。格付に応じた日数を、例えばユーザデータ格納部３４に例えばテーブル形式で保持しても良い。

なお、図２０の例では、「２Ｂ１」についても全ての前タスクが成功となっているので、対応する後タスク「２Ａ１」「２Ａ２」「２Ａ３」に依頼日を設定する。同様に「３Ｂ１」についても全ての前タスクが成功となっているので、対応する後タスク「３Ａ１」に依頼日を設定する。

一方、失敗を示している場合には、ジョブテーブル更新部３７は、複数回失敗しているか判断する（ステップＳ２７）。複数回失敗しているかどうかは、結果に「△２」が登録されているか否かで判断できる。初回の失敗であれば、ジョブテーブル更新部３７は、処理に係るタスクデータに新たな依頼日を設定する（ステップＳ２９）。例えば、旧依頼日に所定日数を加えた日付を新たな依頼日に設定する。所定日数は、上で述べたように出金元ユーザの格付に応じて設定しても良い。また、別途ユーザとの取り決めにて設定しても良い。さらに、前タスクと後タスクで異なる日を設定するようにしても良い。後タスクの失敗は、共に集約された前タスクの影響を受けたためであって、決済センタからの出金であるから基本的に問題ない。従って、例えば後タスクの依頼日については１営業日だけ遅らせるか又は特に変更しなくても良い。これはステップＳ７で処理実施日以前の依頼日が設定されていれば抽出されるためである。一方、前タスクについては上で述べたようにして依頼日を変更する。

そして、ジョブテーブル更新部３７は、処理に係るタスクデータに含まれる出金元ユーザのユーザＩＤでユーザデータ格納部３４から出金元ユーザのメールアドレスを読み出し、当該メールアドレス宛に、決済不成功を示す警告メールを送信する（ステップＳ３１）。出金元ユーザは、当該警告メールにて口座の残高を上げるための処置を実施する。この処理は、前タスクを処理している場合に実施される。そして処理はステップＳ３５に移行する。

一方、複数回失敗していると認められる場合には、ジョブテーブル更新部３７は、処理停止を該当するタスクデータに登録すると共に、処理に係るタスクデータに含まれる出金元ユーザのユーザＩＤでユーザデータ格納部３４から出金元ユーザのメールアドレスを読み出し、当該メールアドレス宛に、処理停止を通知する処理停止通知メールを送信する（ステップＳ３３）。例えば該当タスクデータの「依頼日」に処理停止通知を表すデータを登録するようにしても良い。また、処理停止通知メールについては、例えばジョブ番号などを含むようにしても良い。さらに、複数回失敗と初回失敗とを区別せずに処理しても良い。なお、この処理も前タスクを処理している場合に実施される。その後、処理はステップＳ３５に移行する。

ステップＳ３５では、ジョブテーブル更新部３７は、全ての該当タスクデータについて処理したか判断し、未処理の該当タスクデータが存在する場合にはステップＳ２１に戻り、全ての該当タスクデータについて処理した場合には端子Ｃを介して図２１の処理に移行する。

図２１の処理に移行して、決済センタサーバ３の管理者などから処理終了を指示されているなど処理終了すべき状態でなければ（ステップＳ３７：Ｎｏルート）、端子Ｂを介してステップＳ５に戻る。一方、処理終了すべき状態であれば（ステップＳ３７：Ｙｅｓルート）、処理を終了する。

以上のような処理を実施することにより、決済不履行の連鎖を防止しつつ可能な限り決済の回数を減少させることができる。また、決済センタがリスクを負うこともないので、決済センタの運営を非常に容易に行うことができるようになる。

なお、上で述べた具体例についてその後の処理について説明しておく。図２０のようなデータがジョブテーブル格納部３６に格納されている場合に、処理実施日が「４月３日」になると、図２２に示すようなタスクデータがバンドル処理部３８によって抽出される。ジョブ番号「１」乃至「３」のジョブデータについては後タスクのみが抽出され、ジョブ番号「４」のジョブデータについては前タスクのみが抽出される。

ここでバンドル処理部３８は、タスクデータの「口座情報１」が同じタスクデータを集約する。具体的には、図２３に示すように、後タスク番号「１Ａ１」及び「２Ａ２」のタスクデータは共に出金元又は入金先ユーザが「Ｂ」であるので集約される。同様に後タスク番号「３Ａ１」及び前タスク番号「４Ｂ１」のタスクデータは共に出金元又は入金先ユーザが「Ｃ」であるので集約される。後タスク番号「２Ａ１」及び「２Ａ３」のタスクデータについては集約されない。

そうすると、図２４に示すようなバンドルデータが生成される。バンドル番号「２００９０４０３００１」「２００９０４０３００２」及び「２００９０４０３００４」についてのバンドルデータは、後タスクのみから生成されているので、入金先ユーザへの入金についてのバンドルデータとなる。すなわち金額が負の値となる。一方、バンドル番号「２００９０４０３００３」のバンドルデータは、後タスクと前タスクとが集約されて生成されるので、後タスクの金額が前タスクより大きければユーザに対する入金についてのバンドルデータになり、後タスクの金額が前タスクの金額より小さければユーザからの出金についてのバンドルデータとなる。いずれにせよ金額の絶対値が小さくなるので、ネッティングと同様に決済金額を抑えることができるようになる。場合によっては、金額が「０」となる。金額が「０」になった場合には、決済データを生成する必要はないので、直ちに、該当するジョブデータの処理実施日に依頼日を設定すると共に、結果に成功を表す「１」を設定して良い。この場合には、バンドル処理部３８が、ジョブテーブル更新部３７に対してバンドル番号及び処理実施日を通知する。ジョブテーブル更新部３７は、例えば銀行サーバインタフェース部４１からの通知に応じて他の決済結果データに対する実施する処理と共に処理すればよい。

図２４に示すようなジョブデータが生成されると、図２５に示すような決済データが生成される。すなわち、依頼日「４月３日」に対応付けて、バンドル番号「２００９０４０３００１」「２００９０４０３００２」「２００９０４０３００３」及び「２００９０４０３００４」のいずれかを含む決済データが４件生成される。

そうして、決済データを銀行サーバに送信して、銀行サーバから図２６に示すような決済データを受信したものとする。図２６で分かるように、３番目の決済結果データについて決済不成功「ＮＧ」が発生している。３番目の決済データは、バンドル番号「２００９０４０３００３」であり、成功した他の決済結果データと共にバンドルデータに処理実施日及び結果が登録される。すなわち、図２７に示すようなバンドルデータに更新される。図２７では、バンドル番号「２００９０４０３００１」「２００９０４０３００２」「２００９０４０３００４」のバンドルデータについては、処理実施日「４月３日」及び結果「１」が登録される。しかしながら、バンドル番号「２００９０４０３００３」のバンドルデータについては、処理実施日「４月３日」については同じように登録されるが、結果については失敗を表す「△１」が登録される。影響があるのは、タスク番号「３Ａ１」及び「４Ｂ１」であることが分かる。

従ってジョブテーブル格納部３６に格納されているジョブデータは図２８に示すように更新される。図２８において決済不成功に係るタスクには丸が付加されている。後タスク番号「３Ａ１」である後タスクについては、前タスク番号「４Ｂ１」である前タスクの影響を受けたものであって、依頼日には４月３日の翌営業日（「＋１」で表している）が設定される。一方、問題となった前タスク（前タスク番号「４Ｂ１」）については、依頼日には４月３日のｎ日後が設定される。この間、ユーザＣは、資金を口座に入れておかなければならない。なお、前タスク番号「４Ｂ１」に対応する後タスク（後タスク番号「４Ａ１」）については、依頼日は変更されないので、決済不履行の連鎖が起こらないようになっている。

以上述べたように、本実施の形態では、決済センタへの資金移動についての前タスクと決済センタからの資金移動についての後タスクとに分離して、前タスクが実施されないと後タスクが実施できないようにしているため、決済不履行の連鎖が防止できるようになっている。よって、決済センタの立て替えはないので、決済センタにリスクが集中するような事態を避けることができる。

また、前タスクと処理できるようになった後タスクについては同じユーザについてのタスクであれば集約できるので決済回数の削減及び決済手数料の削減が可能となる。

本実施の形態は、企業間の決済だけではなく、個人と企業との間の決済についても適用可能である。例えば、インターネット上の仮想店舗でのショッピングでの決済も、クレジットカードを用いることができない場合でも本決済センタのサービスを用いるようにすれば、顧客側も自己の銀行口座から同一銀行内の振込で済むので振込手数料を削減できる。特に、近年銀行も個人顧客向けには同一銀行内の振込については手数料を無料化するサービスも採用しており、クレジットカード決済ができなくとも、振込手数料が無料化される場合には抵抗なくショッピングを行うことができる。さらに、店舗側もクレジットカード手数料を削減できるようになる。同様に、企業間取引で多数の決済が必要な場合には、大きな効果が見込める。

以上本発明の一実施の形態について説明したが本発明はこれに限定されるものではない。例えば、図６の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。また、処理フローについても処理結果が変わらなければ、処理順番を入れ替えたり、並列実行しても良い場合もある。

また、例えば図８のステップＳ７では、「処理実施日以前」をタスクデータの抽出条件としているが、依頼日の設定を適切に実施すれば「処理実施日」をタスクデータの抽出条件とすることができる。

また、実行された決済データの件数をユーザ毎にユーザデータ格納部３４に格納しておき、料金計算に用いるようにしても良い。

なお、ユーザ端末、銀行サーバ、決済センタサーバ３は、コンピュータ装置であって、図２９に示すように当該コンピュータ装置においては、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ）及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

３１ 要求受信部 ３２ 要求データ格納部
３３ アンバンドル処理部 ３４ ユーザデータ格納部
３５ 確認処理部 ３６ ジョブテーブル格納部
３７ ジョブテーブル更新部 ３８ バンドル処理部
３９ バンドルテーブル格納部 ４０ 決済テーブル格納部
４１ 銀行サーバインタフェース部

Claims (6)

1. 処理部を有するコンピュータにより実行される決済処理方法であって、
   前記処理部が、１又は複数の出金元及び金額と１又は複数の入金先及び金額とを含む支払要求及び請求要求を、顧客端末から受信し、要求データ格納部に格納するステップと、
   前記処理部が、前記要求データ格納部に格納されている前記支払要求及び前記請求要求を、出金サイドである１の前記出金元から入金サイドである決済センタへ第１の処理日に資金移動させる１又は複数の第１のタスクと前記出金サイドである前記決済センタから前記入金サイドである１の前記入金先へ資金移動させる１又は複数の第２のタスクに分解し、前記１又は複数の第１のタスクのデータと前記１又は複数の第２のタスクのデータとを含むジョブデータをジョブデータ格納部に格納するステップと、
   前記処理部が、前記ジョブデータ格納部に格納されている前記ジョブデータのうち処理基準日が処理日として設定されている前記第１のタスク及び前記第２のタスクを抽出し、前記出金サイドと前記入金サイドとの組み合わせが同一である前記第１のタスク及び前記第２のタスクの資金移動の金額を集約して、バンドル識別子と前記出金サイドの識別データと前記入金サイドの識別データと集約決済金額と集約された前記第１及び第２のタスクの識別子とを含むバンドルデータを生成し、バンドルデータ格納部に格納するステップと、
   前記処理部が、前記バンドルデータ格納部に格納されている前記バンドルデータに基づく決済依頼を金融機関コンピュータに出力するステップと、
   前記処理部が、前記金融機関コンピュータから前記決済依頼の処理結果を受信した場合、当該決済依頼の処理結果を、前記バンドルデータ格納部に格納されており且つ当該決済依頼の処理結果に係るバンドルデータに反映させるステップと、
   前記処理部が、前記処理結果が決済成功を表しているバンドルデータに含まれる前記タスクの識別子に前記第１のタスクの識別子が含まれている場合には、前記ジョブデータ格納部に格納されている前記ジョブデータのうち当該第１のタスクに対応する第２のタスクのデータに第２の処理日を設定するステップと、
   を含む決済処理方法。
2. 前記処理部が、前記処理結果が決済不成功を表しているバンドルデータに含まれる前記タスクの識別子に前記第１のタスクの識別子が含まれている場合には、前記ジョブデータ格納部に格納されている前記第１のタスクのデータに処理実施日より後の第３の処理日を設定するステップと、
   前記処理部が、前記処理結果が決済不成功を表しているバンドルデータに含まれる前記出金サイドの識別データに対応する顧客宛に決済不成功を表す警告を出力するステップと、
   をさらに含む請求項１記載の決済処理方法。
3. 前記第１のタスクのデータが、前記出金サイドの識別データと前記入金サイドの識別データと正の金額と前記第１の処理日とを含み、
   前記第２のタスクのデータが、前記入金サイドの識別データと前記出金サイドの識別データと負の金額と対応する前記第１のタスクについて決済成功が登録されている場合には前記第２の処理日とを含み、
   さらに、前記第１及び第２のタスクのデータには、当該タスクについて前記決済依頼の処理結果を受信した場合には処理結果が含まれる
   請求項１又は２記載の決済処理方法。
4. 前記処理基準日が、処理実施日である場合には、
   前記処理結果が決済不成功を表しているバンドルデータに含まれる前記タスクの識別子に前記第２のタスクの識別子が含まれている場合には、前記ジョブデータ格納部に格納されている前記第２のタスクのデータに前記処理実施日より後の第４の処理日を設定し、
   前記処理基準日が、前記処理実施日以前の日である場合には、
   前記処理結果が決済不成功を表しているバンドルデータに含まれる前記タスクの識別子に前記第２のタスクの識別子が含まれている場合には、前記ジョブデータ格納部に格納されている前記第２のタスクのデータに設定されている前記第２の処理日を維持する又は前記処理実施日より後の第４の処理日を設定する
   請求項２記載の決済処理方法。
5. 請求項１乃至４のいずれか１つ記載の決済処理方法をコンピュータにより実行させるためのプログラム。
6. １又は複数の出金元及び金額と１又は複数の入金先及び金額とを含む支払要求及び請求要求を、顧客端末から受信し、要求データ格納部に格納する要求受信手段と、
   前記要求データ格納部に格納されている前記支払要求及び前記請求要求を、出金サイドである１の前記出金元から入金サイドである決済センタへ第１の処理日で資金移動させる１又は複数の第１のタスクと前記出金サイドである前記決済センタから前記入金サイドである１の前記入金先へ資金移動させる１又は複数の第２のタスクに分解し、前記１又は複数の第１のタスクのデータと前記１又は複数の第２のタスクのデータとを含むジョブデータをジョブデータ格納部に格納するアンバインド処理手段と、
   前記ジョブデータ格納部に格納されている前記ジョブデータのうち処理基準日が処理日として設定されている前記第１のタスク及び前記第２のタスクを抽出し、前記出金サイドと前記入金サイドとの組み合わせが同一である前記第１のタスク及び前記第２のタスクの資金移動の金額を集約して、バンドル識別子と前記出金サイドの識別データと前記入金サイドの識別データと集約決済金額と集約された前記第１及び第２のタスクの識別子とを含むバンドルデータを生成し、バンドルデータ格納部に格納するバインド処理手段と、
   前記バンドルデータ格納部に格納されている前記バンドルデータに基づく決済依頼を金融機関コンピュータに出力する手段と、
   前記金融機関コンピュータから前記決済依頼の処理結果を受信した場合、当該決済依頼の処理結果を、前記バンドルデータ格納部に格納されており且つ当該決済依頼の処理結果に係るバンドルデータに反映させ、前記処理結果が決済成功を表しているバンドルデータに含まれる前記タスクの識別子に前記第１のタスクの識別子が含まれている場合には、前記ジョブデータ格納部に格納されている前記ジョブデータのうち当該第１のタスクに対応する第２のタスクのデータに第２の処理日を設定するバンドルデータ更新手段と、
   を有する決済処理装置。

Images