JP2009163704A - 分納処理方法及び装置、並びに決済処理方法 - Google Patents

Abstract

【課題】支払人の利便性を向上させ、支払人の支払い意思を尊重し、且つ不特定の支払人及び受取人に利用可能にする。
【解決手段】本発明では、支払人と銀行との間に第１の契約を行い、支払人の決済用口座に対応して１又は複数の引落番号を発行する。また、受取人と銀行との間に第２の契約を行い、受取人の決済用口座に対応して１又は複数の振込番号を発行する。そして、支払人が受取人から商品等を購入する際に、今回の取引で用いる引落番号を、受取人に通知する。受取人は、支払人から通知された引落番号と、今回の取引で用いる振込番号と、今回の取引に関する情報とを含む振込依頼を銀行に通知する。支払人は、銀行に行って、自己の引落番号についての振込依頼の内容を確認の上、問題なければ承認を指示する。これに応じて、支払人の決済用口座から受取人の決済用口座へ送金が行われる。
【選択図】図４

Description

本発明は、新たな決済方式に係る技術に関する。

例えば、特開２００２−２９７９１７号公報には、口座引落の予定日前にユーザに事前通知を行い、さらに、口座引落の予定日前に代金支払いを可能にするための技術が開示されている。具体的には、１または複数の口座振替請求がまとめられた自動引落予定明細を収納企業のサーバから受信するステップと、口座振替請求をユーザごとに、第１の記憶部に格納するステップと、第１の記憶部から読み出した口座振替請求の口座引落に関する情報と、ユーザの属性情報が格納された第２の記憶部から読み出したユーザの端末番号とから事前通知を作成するステップと、複数のユーザの事前通知をまとめた口座引落事前通知を情報配信企業のサーバに送付するステップとを含む。これによって、口座に残金のあるうちに振替を行いたいと希望するユーザの要求に応えることができるようになる。しかし、予め自動引落の契約を行った会社からの請求についての支払いに限定される。

また、特開２００６−２５９８５４号公報には、支払者および請求者の個人情報が守られ、かつ、人為的な決済の不備を防止するための技術が開示されている。具体的には、このサーバ装置は、請求者および支払者のうち少なくとも支払者の口座の情報を記憶する口座情報記憶手段と、口座情報記憶手段に記憶される支払者の口座の情報、および、この支払者と請求者の間の決済に関する情報を対応付けて記憶する決済情報記憶手段と、決済機能をもつ請求者の通信端末より送信された、実行対象の決済ごとに予め定め、かつ、請求者と支払者に共通の決済用認証情報が支払者の口座の情報と対応付けられて決済情報情報記憶手段に記憶されていることを認証した後に、請求者の通信端末から送信された、支払者に対する請求金額の情報、および、当該請求金額の入金用口座の情報を、決済用認証情報と対応付けて決済情報記憶手段に記憶する手段と、この決済用認証情報、および、これと対応付けられた請求金額の情報を支払者の通信端末に通知する通知手段と、通知手段により通知された情報で示された決済用認証情報と対応付けられた請求金額の決済の承認を、支払者の通信端末から得た場合に、決済用認証情報と対応付けられる支払者の口座、および、入金用口座の間で、決済用認証情報と対応付けられた請求金額の決済処理を行なう決済手段とを備える。口座情報の秘匿は可能となっているが、多彩な決済を可能とするような構成ではない。また、支払人の通信端末を用いており、チケット発行などには用いることができない。
特開２００２−２９７９１７号公報 特開２００６−２５９８５４号公報

例えばインターネット上のバーチャルショップや通常の通信販売で商品などを購入した場合の決済の方法としてはクレジットカードを使用する方法や、代金引換、銀行振込などが存在する。クレジットカードについては、必ずしも使用可能なわけではなく、代金引換は手数料が高額になる。銀行振込は、手数料は比較的安価であるが、初めて利用する場合には、支払先の銀行、口座番号及び口座名等を指定して手続きを行う必要があり、口座番号や口座名等を間違って指定してしまう等の問題も生じうる。自動引落という決済サービスも存在しているが、上で述べたように予め代金の受取人及び支払人との間に契約手続きが必要であって、不特定顧客向けの決済では利用しにくい。また、自動引落については、一度契約してしまうと、支払人の意図にかかわらず機械的に引落がなされ、予定外の引落によって残高不足になったり、支払人と受取人との契約終了後に誤請求がなされても、引落がなされてしまうという事態も生ずる。このように従来の決済方法には、特に支払人の利便性及び支払い意思の確認といった点において問題があった。

また、物品やサービスの代金を一括して支払うだけではなく、分割払いにしたり、税金や公共料金を分納（分割納付）する場合（本願ではまとめて分納と呼ぶことにする。）にも同様の問題があった。さらに、分納を採用する場合には、支払人側にはそれなりにメリットがあるが、徴収側は徴収の手間が多くかかるという問題もある。

従って、本発明の目的は、支払人の利便性を向上させ、支払人の支払い意思を尊重し、且つ不特定の支払人及び受取人に利用可能な新たな決済方式に係る技術を提供することである。

さらに、本発明の他の目的は、様々な料金の分納をも容易に実施できるようにするための技術を提供することである。

本発明では、支払人と銀行（他の金融機関を含むものとする）との間に第１の契約を行い、支払人の決済用口座に対応して１又は複数の引落番号を発行する。また、受取人と銀行との間に第２の契約を行い、受取人の決済用口座に対応して１又は複数の振込番号を発行する。そして、支払人が受取人から商品等を購入する際に、今回の取引で用いる引落番号を、受取人に通知する。受取人は、支払人から通知された引落番号と、今回の取引で用いる振込番号と、今回の取引に関する情報とを含む振込依頼を銀行に通知する。支払人は、銀行に行って、自己の引落番号についての振込依頼の内容を確認の上、問題なければ承認を指示する。これに応じて、支払人の決済用口座から受取人の決済用口座へ送金が行われる。このようにすれば、受取人の口座番号や口座名を指定する必要がないので支払人の利便性は向上しており、支払人の承認の元に決済を行っており、支払人及び受取人間に予め契約関係がなくても、銀行において引落類似の決済サービスを利用できるようになる。さらに、上で述べたようなスキームを応用すると、税金や公共料金を含む様々な料金の分納にも対応することができる。

具体的に、本発明の第１の態様に係る決済処理方法は、（Ａ）処理部により、第１のユーザからの利用請求に応じて、第１のユーザの決済用口座の口座番号に対応して１又は複数の振込番号を発行し、受取人テーブルに登録するステップと、（Ｂ）処理部により、第２のユーザからの利用請求に応じて、第２のユーザの決済用口座の口座番号に対応して１又は複数の引落番号を発行し、支払人テーブルに登録するステップと、（Ｃ）処理部により、第２のユーザの名称と、第２のユーザが第１のユーザに対して購入対象の購入申込を行ったことによって第２のユーザから第１のユーザへ通知される特定の引落番号と、第１のユーザの特定の振込番号と、金額と、購入対象に関するデータとを含む振込依頼に応じて、依頼番号を発行し、特定の引落番号及び依頼番号に対応して特定の振込番号と金額とを引落テーブルに登録し、特定の振込番号及び依頼番号に対応して第２のユーザの名称と特定の引落番号と金額と購入対象に関するデータとを振込テーブルに登録する振込依頼登録ステップと、（Ｄ）第２のユーザによって決済用口座の口座番号及び引落番号が指定された場合又は第２のユーザによって決済用口座の口座番号が指定され且つ支払人テーブルから決済用口座の口座番号に対応する引落番号が特定された場合、処理部により、引落テーブルから、指定又は特定された引落番号に対応する未承認の振込依頼に係るデータを抽出し、振込依頼についての承認確認リストを生成して出力するステップと、（Ｅ）処理部により、承認確認リストから選択された振込依頼を特定する、第２のユーザからの詳細表示要求に応じて、振込テーブルから、当該選択された振込依頼に係る振込番号及び当該選択された振込依頼の依頼番号に対応する金額と購入対象に関するデータとを抽出し、抽出されたデータを用いて第２のユーザに提示するための承認確認データを生成して出力するステップと、（Ｆ）処理部により、承認確認データに対する、第２のユーザからの承認指示に応じて、承認確認データに係る依頼番号及び当該依頼番号に係る振込番号に対応して振込テーブルにおいて承認結果を登録し、承認確認データに係る依頼番号及び指定又は特定された引落番号に対応して引落テーブルにおいて承認結果を登録し、承認確認データに係る依頼番号及び指定又は特定された引落番号を含む決済データを引落承認テーブルに格納する承認ステップと、（Ｇ）処理部により、引落承認テーブルに登録されている未決済の決済データについて、引落テーブルから決済データに含まれる依頼番号及び引落番号に対応する振込番号及び金額を特定し、支払人テーブルから引落番号に対応する決済用口座の口座番号を特定し、受取人テーブルから振込番号に対応する決済用口座の口座番号とを特定し、特定された金額について引落番号に対応する決済用口座から振込番号に対応する決済用口座への送金のための処理を実施する送金ステップとを含む。

このように、処理部により上で述べた具体的な処理を各種テーブルと協働して実施することにより、上で述べた課題を解決することができる。また、引落番号を用いることによって、口座番号を第１のユーザに提示することなく、さらに例えば管理のため引落番号を使い分けることもできるようになる。振込番号についても、管理のため使い分けることができる。また、振込テーブル及び引落テーブルとで振込依頼を管理することによって、それぞれの立場で承認結果などを管理することが容易にできるようになる。さらに、引落承認テーブルについても、送金ステップをフレキシブルに実施するのに有効である。

また、上で述べた支払人テーブルにおいて、引落番号に対応して、引落承認の要否という引落条件がさらに登録される場合もある。その場合には、支払人テーブルにおいて引落番号に対応して引落承認が不要という引落条件が登録されている場合、振込依頼登録ステップの完了に応じて承認ステップを実施するようにしてもよい。例えば信用のできる第１のユーザに対しては、わざわざ第２のユーザが再度承認することなく、送金を実施するものである。よって、第２のユーザの利便性が向上する。

さらに、上で述べたコンピュータ・システムが、第２のユーザが操作する現金自動預け払い機と接続されている場合もある。そして、承認ステップの後に、処理部により、承認確認データに係る購入対象に関するデータの少なくとも一部を、第２のユーザが操作する現金自動預け払い機に、レシート上に印字出力させるステップをさらに含むようにしてもよい。例えば購入対象がコンサートのチケットなどである場合には、レシートにチケットデータを印字することによって、別途チケットを郵送するなどの手数を削減することができる。また、ＡＴＭを有効利用して、チケット販売が行えるようになる。

さらに、上で述べた振込依頼登録ステップが、振込依頼に含まれる振込番号が、提携先の他の銀行における決済用口座の振込番号であることを示している場合、処理部により、他の銀行のコンピュータ・システムの受取人テーブルに登録されており且つ当該振込番号に対応する他の銀行の決済用口座の口座番号を上記他の銀行のコンピュータ・システムから取得し、依頼番号及び引落番号に対応して引落テーブルに登録するステップを含むようにしてもよい。また、送金ステップが、処理部により、引落承認テーブルに登録されている未決済の決済データについて、引落テーブルから上記決済データに含まれる依頼番号及び引落番号に対応するデータを読み出すステップと、読み出された上記データに含まれる振込番号が、他の銀行における決済用口座の振込番号である場合には、処理部により、支払人テーブルから引落番号に対応する決済用口座の口座番号を特定し、読み出された上記データに含まれる金額について引落番号に対応する決済用口座から、読み出された上記データに含まれる他の銀行の決済用口座の口座番号に係る口座への送金のための処理を実施するステップとを含むようにしてもよい。引落は通常同一銀行内で実施するものであるが、銀行が本方式を実施する上で提携していれば、他行にも送金を実施させることができるようになる。

また、支払人テーブルにおいて、引落番号に対応して、承認日からの引落日までの日数についての引落条件がさらに登録されるようにしてもよい。そのような場合には、上で述べた承認ステップが、処理部により、支払人テーブルから、指定又は特定された引落番号に対応する引落条件を抽出するステップと、処理部により、承認日と引落条件に含まれる日数から決済日を特定するステップと、処理部により、決済日に対応して、承認確認データに係る依頼番号及び指定又は特定された引落番号を含む決済データを引落承認テーブルに格納するステップとを含むようにしてもよい。このように、第２のユーザは、自らの資金予定に応じて引落条件を設定して、適切に決済日を設定することができるようになる。

さらに、本発明の第１の態様において、処理部により、承認確認データに対する、第２のユーザからの拒否指示又は購入無し指示に応じて、承認確認データに係る依頼番号及び当該依頼番号に係る振込番号に対応して振込テーブルにおいて拒否又は購入無しを表すデータを登録し、承認確認データに係る依頼番号及び指定又は特定された引落番号に対応して引落テーブルにおいて拒否又は購入無しを表すデータを登録し、承認確認データに係る依頼番号及び指定又は特定された引落番号を含む承認拒否データを引落承認拒否テーブルに格納するステップと、処理部により、振込テーブルにおいて、振込番号毎又は特定のユーザに関連する振込番号群毎に、購入無しを表すデータが登録されている振込依頼の数をカウントするステップと、処理部により、引落テーブルにおいて、引落番号毎又は特定の他のユーザに関連する引落番号群毎に、拒否を表すデータが登録されている振込依頼の数をカウントするステップとをさらに含むようにしてもよい。このようにすれば、購入していないのに振込依頼を出している問題ユーザや購入申込しているのに支払いを拒否する問題ユーザを特定することができるようになる。

本発明の第２の態様に係る決済処理方法は、（Ａ）処理部により、第１のユーザからの利用請求に応じて、第１のユーザの決済用口座の口座番号に対応して受取条件毎に振込番号を発行し、受取人テーブルに登録するステップと、（Ｂ）処理部により、第２のユーザからの利用請求に応じて、第２のユーザの決済用口座の口座番号に対応して１又は複数の引落番号を発行し、支払人テーブルに登録するステップと、（Ｃ）処理部により、第２のユーザの名称と、第２のユーザが第１のユーザに対して購入対象の購入申込を行ったことによって第２のユーザから第１のユーザへ通知される特定の引落番号と、第１のユーザの特定の振込番号と、金額と、購入対象に関するデータとを含む振込依頼に応じて、依頼番号を発行し、特定の引落番号及び依頼番号に対応して特定の振込番号と金額とを引落テーブルに登録し、特定の振込番号及び依頼番号に対応して第２のユーザの名称と特定の引落番号と金額と購入対象に関するデータとを振込テーブルに登録する振込依頼登録ステップと、（Ｄ）第２のユーザによって決済用口座の口座番号及び引落番号が指定された場合又は第２のユーザによって決済用口座の口座番号が指定され且つ支払人テーブルから決済用口座の口座番号に対応する引落番号が特定された場合、処理部により、引落テーブルから、指定又は特定された引落番号に対応する未承認の振込依頼に係るデータであって、当該データに含まれる振込番号に対応して受取人テーブルに登録されている受取条件を満たすデータを抽出し、振込依頼についての承認確認リストを生成して出力するステップと、（Ｅ）処理部により、承認確認リストから選択された振込依頼を特定する、第２のユーザからの詳細表示要求に応じて、振込テーブルから、当該選択された振込依頼に係る振込番号及び当該選択された振込依頼の依頼番号に対応する金額と購入対象に関するデータとを抽出し、抽出されたデータを用いて第２のユーザに提示するための承認確認データを生成して出力するステップと、（Ｆ）処理部により、承認確認データに対する、第２のユーザからの承認指示に応じて、承認確認データに係る依頼番号及び当該依頼番号に係る振込番号に対応して振込テーブルにおいて承認結果を登録し、承認確認データに係る依頼番号及び指定又は特定された引落番号に対応して引落テーブルにおいて承認結果を登録し、承認確認データに係る依頼番号及び指定又は特定された引落番号を含む決済データを引落承認テーブルに格納する承認ステップと、（Ｇ）処理部により、引落承認テーブルに登録されている未決済の決済データについて、引落テーブルから決済データに含まれる依頼番号及び引落番号に対応する振込番号及び金額を特定し、支払人テーブルから引落番号に対応する決済用口座の口座番号を特定し、受取人テーブルから振込番号に対応する決済用口座の口座番号とを特定し、特定された金額について引落番号に対応する決済用口座から振込番号に対応する決済用口座への送金のための処理を実施する送金ステップとを含む。

このように受取条件毎に振込番号を設定することによって、柔軟な決済を実施することができる。

本発明の第３の態様に係る分納処理方法は、（Ａ）処理部により、第１のユーザからの利用請求に応じて、第１のユーザの決済用口座の口座番号に対応して１又は複数の振込番号を発行し、受取人テーブルに登録するステップと、（Ｂ）処理部により、第２のユーザからの利用請求に応じて、第２のユーザの決済用口座の口座番号に対応して１又は複数の引落番号を発行し、支払人テーブルに登録するステップと、（Ｃ）処理部により、第２のユーザから第１のユーザへ通知された特定の引落番号と、第１のユーザの特定の振込番号と、１回分の請求金額と、総請求金額と、請求対象に関するデータとを含む分納徴収依頼に応じて、依頼番号を発行し、特定の引落番号及び依頼番号に対応して特定の振込番号と１回分の請求金額と総請求額とを含む第１の引落依頼内容データを引落テーブルに登録し、特定の振込番号及び依頼番号に対応して特定の引落番号と１回分の請求金額と総請求金額と請求対象に関するデータとを含む第１の振込依頼内容データを振込テーブルに登録する分割徴収依頼登録ステップと、（Ｄ）第２のユーザによって決済用口座の口座番号及び引落番号が指定された場合又は第２のユーザによって決済用口座の口座番号が指定され且つ支払人テーブルから決済用口座の口座番号に対応する引落番号が特定された場合、処理部により、引落テーブルから、指定又は特定された引落番号に対応する未承認の引落依頼内容データを抽出し、引落依頼内容データについての承認確認リストを生成して出力するステップと、（Ｅ）処理部により、承認確認リストから選択された引落依頼内容データを特定する、第２のユーザからの詳細表示要求に応じて、振込テーブルから、当該選択された引落依頼内容データに係る振込番号及び当該選択された引落依頼内容データの依頼番号に対応する１回分の請求金額と請求対象に関するデータとを抽出し、抽出されたデータを含む、第２のユーザに提示するための承認確認データを生成して出力するステップと、（Ｆ）処理部により、承認確認データに対する、第２のユーザからの承認指示に応じて、承認確認データに係る依頼番号及び当該依頼番号に係る振込番号に対応して振込テーブルにおいて承認結果を登録し、承認確認データに係る依頼番号及び指定又は特定された引落番号に対応して引落テーブルにおいて承認結果を登録し、承認確認データに係る依頼番号を含む、送金のためのデータを承認テーブルに格納する承認ステップと、（Ｇ）処理部により、承認確認データに対する、第２のユーザからの承認指示に応じて、承認確認データに係る依頼番号に関連付けられた第２の依頼番号を発行し、承認確認データに係る依頼番号に対応する第１の引落依頼内容データにおける総請求金額を当該総請求金額と承認された金額との差に置き換えた第２の引落依頼内容データを、承認確認データに係る引落番号及び第２の依頼番号に対応して引落テーブルに登録し、承認確認データに係る依頼番号に対応する第１の振込依頼内容データにおける総請求金額を当該総請求金額と上記承認された金額との差に置き換えた第２の振込依頼内容データを、承認確認データに係る振込番号及び第２の依頼番号に対応して振込テーブルに登録する自動データ生成ステップとを含む。

このような処理を実施することによって、納付毎に次の納付に必要なデータを自動生成することとなり、第１のユーザが何度も依頼を行う必要が無く、第１のユーザの省力化が可能となり、本サービスの利用が促進される。

また、本発明の第３の態様において、第２のユーザからの承認指示に、１回分の請求金額とは異なる金額が、第２のユーザによって承認された金額として含まれる場合、振込テーブルに登録される承認結果に承認された金額が含まれ、引落テーブルに登録される承認結果に承認された金額が含まれ、上記送金のためのデータに承認された金額が含まれるようにしてもよい。第２のユーザによって今回払える金額の指定があれば、それに従って金額を登録して、次回以降納付すべき残額も設定される。

さらに、本発明の第３の態様において、第１の引落依頼内容データ及び第１の振込依頼内容データが、請求期間を定めるためのデータを含むようにしてもよい。この場合、処理部により、振込テーブル又は引落テーブルにおいて請求期間経過後においても未承認の第１の振込依頼内容データ又は第１の引落依頼内容データを探索し、未承認の第１の振込依頼内容データ又は第１の引落依頼内容データが存在する場合には、当該第１の振込依頼内容データ又は当該第１の引落依頼内容データに係る依頼番号に関連付けられた第３の依頼番号を発行し、当該第１の引落依頼内容データにおける請求期間を定めるためのデータを次の請求期間を定めるためのデータに変更した第３の引落依頼内容データを、当該第１の引落依頼内容データに係る引落番号及び第３の依頼番号に対応して引落テーブルに登録し、当該第１の振込依頼内容データにおける請求期間を定めるためのデータを次の請求期間を定めるためのデータに変更した第３の振込依頼内容データを、当該第１の振込依頼内容データに係る振込番号及び第３の依頼番号に対応して振込テーブルに登録する第２自動データ生成ステップをさらに含むようにしてもよい。このようにすれば、各期限内に支払いがない場合にも、次の請求期間のためのデータを自動生成して、適切に納付状況を管理することができるようになる。このようにすれば、後に述べる延滞料などについても依頼内容データ及び承認結果に基づき算出できるようになる。

さらに、本発明の第３の態様において、受取人テーブルにおいて、第１のユーザの決済用口座の口座番号に対応して当該第１のユーザの格付が登録されるようにしてもよい。この場合、処理部により、承認テーブルに登録された上記送金のためのデータに含まれる依頼番号に対応する引落番号から支払人テーブルにおいて特定される第２のユーザの決済用口座から、上記承認された金額を出金するステップと、処理部により、承認テーブルに登録された送金のためのデータに含まれる依頼番号に対応する振込番号から受取人テーブルにおいて特定される第１のユーザの格付を特定し、格付と入金猶予日数との対応関係を保持する猶予日数テーブルから第１のユーザの格付に対応する入金猶予日数を特定し、送金のためのデータに含まれる依頼番号に対応する振込番号又は上記送金のためのデータに含まれる依頼番号に対応する振込番号から受取人テーブルにおいて特定される第１のユーザの決済用口座の口座番号と、特定された入金猶予日数と承認日とから得られる入金予定日と含む入金・送金予定データを入金・送金予定テーブルに登録するステップと、処理部により、入金・送金予定テーブルから、現在日が入金予定日であるデータを抽出し、当該データに従って第１のユーザの決済用口座に入金又は送金するステップとをさらに含むようにしてもよい。このようにすれば、格付に応じた入金猶予日数後に実質的な送金がなされることになり、資金効率を高めるため格付を高くするインセンティブが働く。また、何らかの問題（例えば倒産など）が発生した場合には、入金・送金処理を停止すれば、被害を少なくすることができる。

さらに、本発明の第３の態様において、処理部により、取引停止となったユーザを特定する情報を格納する取引停止リストに登録されたユーザに係る振込番号又は決済用口座の口座番号を支払人テーブルから抽出するステップと、処理部により、抽出された振込番号又は決済用口座の口座番号を含む入金・送金予定データを、入金・送金予定テーブルから、取引停止データ格納部に移動させるステップと、処理部により、抽出された振込番号を含む未承認の引落依頼内容データを、引落テーブルから、取引停止データ格納部に移動させるステップとをさらに含むようにしてもよい。このようにすれば、問題のある受取人への入金・送金を未然に阻止することができるようになる。

なお、本方法をコンピュータに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

本発明によれば、支払人の利便性を向上させ、支払人の支払い意思を尊重し、且つ不特定の支払人及び受取人に利用可能な新たな決済方式を導入することができるようになる。

また、本発明の他の側面によれば、様々な料金の分納をも容易に実施できるようになる。

［実施の形態１］
最初に、本発明の第１の実施の形態に係る決済サービスの概要を説明する。本決済サービスでは、商品などを販売する販売店１００と販売店１００から商品などを購入するユーザ２００とは、予め決済について契約を結んでおく必要はない。但し、図１に示すように、販売店１００は、銀行３００に対して、決済用口座のデータ等を含む、本決済サービスの利用申請を行い（ステップ（１））、銀行３００では、利用申請に係る決済口座に対して１又は複数の振込番号を発行して、販売店１００に通知する（ステップ（２））。

また、図２に示すように、図１の手続きとは非同期に、ユーザ２００は、銀行３００に対して、決済口座のデータ等を含む、本決済サービスの利用申請を行い（ステップ（３））、銀行３００では、利用申請に係る決済口座に対して１又は複数の引落番号を発行して、ユーザ２００に通知する（ステップ（４））。

その後、図３に示すように、ユーザ２００が、販売店１００から商品などを購入する際には、決済方法として本決済サービスを利用するのであれば、自己の引落番号を販売店１００に通知する（ステップ（５））。そうすると、販売店１００は、ユーザ２００から受け取った引落番号、今回使用する販売店１００の振込番号、販売に関するデータ（ユーザ２００のデータや商品等のデータ、さらにレシートへの印字データを含む）等を含む振込依頼を、銀行３００に対して通知する（ステップ（６））。振込依頼の通知自体は、オンラインで行っても良いし、ＦＡＸやメールなどの手段で行っても良い。銀行３００は、振込依頼をシステムに蓄積し、ユーザ２００の承認が必要な場合には、ユーザ２００による承認を待つ。

ユーザ２００は、例えば銀行３００の現金自動預け払い機（ＡＴＭ：Automated Teller Machine）に行き、認証を行った後に、特定の振込依頼の内容を確認し、当該特定の振込依頼について振込承認を与える（ステップ（７））。この段階にて、特定の振込依頼を拒否することも可能である。また、場合によって販売店１００から誤った振込依頼がある場合には、「購入無し」を登録することも可能である。銀行３００は、ユーザ２００から振込承認を受け取ると、振込依頼に含まれる印字データをレシートに印刷し、出力する（ステップ（８））。例えば、商品がチケットである場合には、レシートに、チケットデータ（座席データなど）を印字すれば、チケットそのものを別途郵送するなどの手間を省くことができるようになる。さらに、銀行３００は、振込承認を受けた振込依頼については、販売店１００の決済用口座もユーザ２００の決済用口座も銀行３００のものであれば、引落処理を実施し、販売店１００の決済用口座が銀行３００とは異なる提携先の銀行のものである場合には、振込処理を実施し、送金を実施する（ステップ（９））。さらに、銀行３００は、振込承認等（振込拒否や購入無しなどの指示も含む）を受けた振込依頼については、その結果を販売店１００に通知する（ステップ（１０））。

このような処理を行うことによって、予め引落のための契約を販売店１００とユーザ２００の間で行う必要はなく、不特定のユーザ間（オークションなどで生ずる個人間の場合も含む）で決済を行うことができるようになる。また、振込依頼が予め銀行３００に通知され、ユーザ２００は、販売店１００の口座番号や口座名を入力する必要はなく、承認や拒否を選択するだけでよいので、この点においてもユーザの手間は少なくなっている。さらに、個々の振込依頼について、ユーザ２００はその内容を判断してから承認や拒否を判断できるため、誤引落などを回避することができるようになる。

次に、図１乃至図３で説明した決済サービスにおいて用いられるコンピュータ・システムの一例を図４に示す。例えばインターネットなどのネットワーク１には、ユーザ２００が操作する例えばパーソナルコンピュータである１又は複数のユーザ端末５と、販売店１００が管理運営し且つ商品などを販売する処理を実施する１又は複数の販売店サーバ３と、本決済サービスを提供する銀行の１又は複数の銀行システム７とが接続されている。銀行システム７には、複数のＡＴＭ９（図４では９ａ乃至９ｃ）が接続されており、連携して処理を実施する。ＡＴＭ９は、通常のＡＴＭの機能を有し、さらに以下で述べるような処理を実施することができる。

通常の通信販売のように、ユーザ端末５を用いてオンラインで注文を行うことなく、電話で販売店１００に注文を行うようにしても良い。同様に、販売店サーバ３で、注文を受け付けたり、銀行システム７に振込依頼を送信せず、電話やＦＡＸで注文を受け付けたり、銀行システム７にもＦＡＸや電子メールなどで振込依頼を通知するようにしても良い。さらに、以下ではＡＴＭ９を用いて振込承認などを実施する例を説明するが、ユーザ端末５を用いて振込承認などを実施するようにしても良い。

図５に銀行システム７の機能ブロック図を示す。銀行システム７は、販売店１００からの利用申請についてのデータを登録する処理を実施する販売店登録部７２と、販売店登録部７２により登録されたデータを格納する受取人テーブル７６と、ユーザ２００からの利用申請についてのデータを登録する処理を実施するユーザ登録部７３と、ユーザ登録部７３により登録されたデータを格納する支払人テーブル７７と、受取人テーブル７６及び支払人テーブル７７を参照し、販売店１００から振込依頼を受け付け、受取人用のデータ及び支払人用のデータを生成する振込依頼受付部７１と、振込依頼受付部７１によって生成された受取人用のデータを格納する振込テーブル７４と、振込依頼受付部７１によって生成された支払人用のデータを格納する引落テーブル７５と、振込テーブル７４、引落テーブル７５、受取人テーブル７６及び支払人テーブル７７を参照し、ＡＴＭ９と連携して承認確認処理を実施する承認処理部７８と、ユーザ２００から承認を得られた場合に承認処理部７８の処理結果を格納する引落承認テーブル７９と、ユーザ２００から承認を得られなかった場合に承認処理部７８の処理結果を格納する引落承認拒否テーブル８０と、受取人テーブル７６、支払人テーブル７７、引落テーブル７５及び引落承認テーブル７９を参照して決済のための処理を実施する決済処理部８３と、決済処理部８３からの指示に応じて引落処理を実施する引落処理部８４と、決済処理部８３からの指示に応じて振込処理を実施する振込処理部８５と、振込テーブル７４及び引落テーブル７５に登録される承認結果を集計する処理を実施する集計処理部８１と、集計処理部８１の処理結果を格納する集計データ格納部８２とを有する。

次に、図６乃至図２９を用いて図４及び図５に示したシステムの処理内容を説明する。最初に、図６乃至図８を用いて、ユーザ２００から銀行３００への利用申請の際の処理について説明する。ユーザ登録部７３は、氏名、連絡先（住所、電話番号、メールアドレス等）、決済用口座番号等を含む口座データ、引落条件（引落通知の有無（事前／事後、及び要不要）、引落通知を行う場合の連絡先（メールアドレス、住所、ＦＡＸ番号など）、引落可否情報（無条件引落許可（引落承認の有無にかかわらず引落実施）、無条件引落禁止（引落承認の有無にかかわらず引落を実施しない。引落番号を使用後に変更する場合に設定する。）、引落承認要（承認時にのみ引落を実施））、引落日（承認日からｎ（０以上の整数）日経過後に引落を実施））などを含む利用申請を受け付け、例えばメインメモリなどの記憶装置に格納する（ステップＳ１）。なお、ユーザ登録部７３は、ＦＡＸで送られてきたデータを認識したり、電子メールのデータから抽出したり、例えばユーザ２００によって入力用のＷｅｂページに入力されたデータを取得したり、申請用紙で申請された場合にはオペレータが入力したデータを取得したり、といったように様々な形態で受け付ける。また、１の口座番号に対して引落番号を複数を複数発行することができ、複数の引落番号を発行する場合には、引落条件については引落番号の数だけ必要となる。

そして、ユーザ登録部７３は、利用申請で要求された数だけ引落番号を発行し、例えばメインメモリなどの記憶装置に格納する（ステップＳ３）。引落番号は、銀行コードを含むようにして、銀行を特定できるようにする。その後、氏名、連絡先、口座データ、引落条件（上記データに加え、有効期限（本決済サービスの利用期限））、引落番号を含む支払人データを支払人テーブル７７に登録する（ステップＳ５）。

図７に、支払人テーブル７７のデータ構造の概要を示す。図７に示すように、契約者として、各ユーザ（図７の例では利用者１乃至３）についてデータを格納するようになっている。図８に、各ユーザについてのデータの詳細構造を示す。図８では利用者３のデータ構造の具体例を示しており、利用者３を特定する氏名及び連絡先のデータに対応して決済用口座の口座番号（ここでは２つ）が登録されており、さらに各決済用口座の口座番号に対応して引落番号及び引落条件が１又は複数セット（図８では、２セットずつ）登録される。引落条件については、上で述べたように、有効期限（デフォルトのまま又は特に指定がある場合はその期限）、引落通知の有無及び事前／事後の別、引落通知の連絡先、引落可否情報、決済日といった条件が登録される。このように、引落番号毎に、引落条件を設定することができるので、ユーザ２００は、引落番号を、相手に応じて使い分けることができるようになる。なお、引落条件については、後に変更申請を行うことによって変更することができる。特に、後から販売店１００とのトラブルが発生したなどの理由で引落を行わないように設定する場合には、引落可否情報において、無条件引落禁止に設定すればよい。また、販売店１００が信頼できる場合には、引落可否情報において無条件引落許可に設定した引落番号を通知すれば、わざわざ承認手続きを実施することもなく、送金することができるようになる。

最後に、ユーザ登録部７３は、引落番号を含む登録完了通知を出力する（ステップＳ７）。ＦＡＸや電子メール、入力用Ｗｅｂページからの利用申請の場合には、ＦＡＸ、電子メール、出力用Ｗｅｂページによって、登録完了通知を出力する。紙の利用申請の場合には、例えば印刷して、郵便にてユーザ２００に送付する。

このようにすれば、ユーザ２００の最初の登録が完了する。

次に、図９乃至図１１を用いて、販売店１００から銀行３００への利用申請の際の処理について説明する。販売店登録部７２は、名称、連絡先（住所、電話番号、メールアドレス等）、決済用口座番号等を含む口座データ、引落条件（受取期間（ユーザ２００からの入金を待つ期間）、手数料の支払条件（受取人負担／支払人負担））などを含む利用申請を受け付け、例えばメインメモリなどの記憶装置に格納する（ステップＳ１１）。なお、販売店登録部７２は、ＦＡＸで送られてきたデータを認識したり、電子メールのデータから抽出したり、例えば販売店１００によって入力用のＷｅｂページに入力されたデータを取得したり、申請用紙で申請された場合にはオペレータが入力したデータを取得したり、といったように様々な形態で受け付ける。また、１の口座番号に対して振込番号を複数を複数発行することができ、複数の振込番号を発行する場合には、受取条件については振込番号の数だけ必要となる。

そして、販売店登録部７２は、利用申請で要求された数だけ振込番号を発行し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１３）。振込番号は、例えば銀行コードを含むようにして、銀行を特定できるようにする。その後、名称、連絡先、口座データ、受取条件（上記データに加え、有効期限（本決済サービスの利用期限））、振込番号を含む受取人データを受取人テーブル７６に登録する（ステップＳ１５）。

図１０に、受取人テーブル７６のデータ構造の概要を示す。図１０に示すように、契約者として、各法人ユーザ（図１０の例では法人１及び２、販売店Ａ。但し、法人に限定されるものではなく、個人ユーザであってもよい。）についてデータを格納するようになっている。図１１に、各法人ユーザについてのデータの詳細構造を示す。図１１では販売店Ａのデータ構造の具体例を示しており、販売店Ａを特定する名称及び連絡先のデータに対応して決済用口座の口座番号（ここでは２つ）が登録されており、さらに各決済用口座の口座番号に対応して振込番号及び受取条件が１又は複数セット（図１１では、２セットずつ）登録される。受取条件については、上で述べたように、有効期限（デフォルトのまま又は特に指定がある場合はその期限）、受取期間（受取開始日及び受取終了日）、手数料（販売店又はユーザ）が登録される。このように、振込番号毎に、受取条件を設定することができるので、販売店１００は、振込番号を、相手に応じて使い分けることができるようになる。なお、受取条件については、後に変更申請を行うことによって変更することができる。

最後に、販売店登録部７２は、振込番号を含む登録完了通知を出力する（ステップＳ１７）。ＦＡＸや電子メール、入力用Ｗｅｂページからの利用申請の場合には、ＦＡＸ、電子メール、出力用Ｗｅｂページによって、登録完了通知を出力する。紙の利用申請の場合には、例えば印刷して、郵便にて販売店１００に送付する。

このようにすれば、販売店１００の最初の登録が完了する。

次に、図１２を用いて、ユーザ２００がユーザ端末５を操作して、商品などを販売する販売店１００の販売店サーバ３に対して商品の購入を行う際の処理及び振込依頼を行う際の処理について説明する。なお、ここではオンラインショッピングの例を示すが、オンラインでない通信販売でも本実施の形態における決済サービスは利用可能である。

例えば、販売店サーバ３が、ユーザ端末５からの検索指示に応じて商品一覧ページ・データを生成してユーザ端末５に送信する。ユーザ端末５は、販売店サーバ３から商品一覧ページ・データを受信し、表示装置に商品一覧ページを表示する。これに対して、ユーザは、いずれかの商品を選択して、ショッピングカートに入れる指示を入力する。ユーザ端末５は、ユーザからの指示を受け付け、選択商品のショッピングカートへの投入指示を、販売店サーバ３に送信する。販売店サーバ３は、ユーザ端末５から、選択商品のショッピングカートへの投入指示を受信し、選択商品のデータをショッピングカートのデータ領域に登録する。そして、ショッピングカートへ投入した商品リストを含むページ・データを生成し、ユーザ端末５に送信する。ユーザ端末５は、販売店サーバ３からショッピングカートへ投入した商品リストを含むページ・データを受信し、表示装置に、ショッピングカートへ投入した商品リストを含むページを表示する。

この段階では、ショッピングを継続しても良いし、購入を中止するようにしても良いが、ここでは、ユーザ２００は、決済指示を入力したものとする。ユーザ端末５は、ユーザ２００による決済指示を受け付け、当該決済指示を販売店サーバ３に送信する（ステップＳ３１）。販売店サーバ３は、決済指示をユーザ端末５から受信し（ステップＳ３３）、決済データ入力ページ・データを生成してユーザ端末５に送信する（ステップＳ３５）。例えば、ショッピングカートに投入されている商品のデータを含み、以下で述べるデータの入力欄を含むページ・データが生成され送信される。

ユーザ端末５は、販売店サーバ３から決済データ入力ページ・データを受信し、表示装置に決済データ入力ページを表示する（ステップＳ３７）。ユーザは、ユーザ端末５を操作して、氏名、連絡先、引落番号等を含む決済データを入力する。ユーザ端末５は、ユーザから氏名、連絡先、引落番号等を含む決済データの入力を受け付け、販売店サーバ３に送信する（ステップＳ３９）。販売店サーバ３は、ユーザ端末５から、氏名、連絡先、引落番号等を含む決済データを受信し、図示しないデータベースに登録する（ステップＳ４１）。そして、受け付け完了通知を生成して、ユーザ端末５に送信する（ステップＳ４３）。

ユーザ端末５は、販売店サーバ３から受け付け完了通知を受信し、表示装置に表示する（ステップＳ４４）。これにて、ユーザ２００が行う手続きの第１段階は終了する。

一方、販売店サーバ３は、今回の決済で用いる振込番号、引落番号、ユーザ２００の氏名及び連絡先、レシート印字データ（購入商品データを含む）、通帳に印字する摘要文言のデータなどを含む振込データを生成し、例えばメインメモリなどの記憶装置に格納する（ステップＳ４５）。そして、当該振込データを含む振込要求を、引落番号から特定される銀行の銀行システム７に送信する（ステップＳ４７）。なお、ステップＳ４７については、ネットワーク１を介して直接銀行システム７に送信するのではなく、他の方法、例えばＦＡＸで出力したり、電子メールの形式で送信したり、郵送用に印字して出力するようにしても良い。

次に、図１２の後に銀行システム７で実行される処理について図１３乃至図１７を用いて説明する。銀行システム７の振込依頼受付部７１は、振込データを含む振込依頼を、販売店サーバ３から受信する（ステップＳ５１）。例えば、ＦＡＸや電子メールの形式で送信されてきた場合には、それらから必要なデータを抽出する。また、銀行に紙の形式で振込依頼が送付された場合には、オペレータなどによって入力される振込データを含む振込依頼を取得する。

そして、振込依頼受付部７１は、振込データに含まれるデータを支払人テーブル７７と照合する（ステップＳ５３）。具体的には、例えば振込データに含まれる今回の決済で用いる引落番号で支払人テーブルを検索し、該当するユーザ２００の氏名及び連絡先と、振込データに含まれるユーザ２００の氏名及び連絡先とを照合する。なお、一致しない場合には、これ以降の処理は行わない。振込依頼の送信元などにエラーを通知するようにしても良い。また、振込データに含まれる今回の決済で用いる振込番号が、他の提携銀行の振込番号である場合には、例えばネットワーク１を介して接続されている他の提携銀行の銀行システムに決済用口座の口座番号等のデータ要求を送信し、振込番号を他の提携銀行の銀行システムで確認してもらった上で、販売店名、連絡先、決済用口座の口座番号等を取得するようにする。

次に、振込依頼受付部７１は、この振込依頼に対して依頼番号を生成する（ステップＳ５４）。振込番号と引落番号の同一組み合わせの振込依頼が複数ある場合には、容易に振込依頼を識別できないので、依頼番号を導入する。そして、振込依頼に含まれる振込データを用いて振込テーブル７４にレコードを登録する（ステップＳ５５）。振込テーブル７４では、例えば図１４に示すようなデータ構造でデータを管理する。すなわち、振込番号毎に、依頼内容を登録するようになっており、ユーザ２００が承認等を行った場合には、その結果を依頼内容に対応して登録するようになっている。図１５に依頼内容と結果の詳細なデータ構造例を示す。依頼番号で特定される依頼内容には、購入者であるユーザ２００の氏名及び連絡先、引落番号、金額、振込依頼受領日、レシート印字データ、通帳記入の摘要文言が対応付けられている。さらに、依頼番号で特定される依頼内容には、結果のデータも対応付けられており、結果には、承認日、承認内容（承認、拒否、購入無し）が対応付けられている。

さらに、振込依頼受付部７１は、受取人テーブル７６の該当データ（振込番号に対応する販売店名、連絡先など）及び振込依頼に含まれる振込データを用いて引落テーブル７５にレコードを登録する（ステップＳ５７）。引落テーブル７５では、例えば図１６に示すようなデータ構造でデータを管理する。すなわち、引落番号毎に、依頼内容を登録するようになっており、ユーザ２００が承認などを行った場合には、その結果を依頼内容に対応して登録するようになっている。図１７に依頼内容と結果の詳細なデータ構造例を示す。依頼番号で特定される依頼内容には、販売店名、販売店の連絡先、振込番号、金額、振込依頼受領日、他の提携銀行の振込番号の場合には販売店の決済用口座の口座番号が対応付けられている。さらに、依頼番号で特定される依頼内容には、結果のデータも対応付けられており、結果には、承認日、承認内容（承認、拒否、購入無し）が対応付けられている。

ここまでで、ユーザ２００が振込依頼の承認を行う前の処理が完了する。

次に、図１８乃至図２４を用いて、ユーザ２００が、振込依頼について、承認、拒否、又は購入無しを登録する際の処理について説明する。ここでは、ユーザ２００は、銀行システム７に接続されているＡＴＭ９に出向いて、ＡＴＭ９を操作するものとする。

まず、ユーザ２００は、ＡＴＭ９の表示装置に表示されているメインメニュー（例えば図１９）のうち引落承認を選択する。ＡＴＭ９は、ユーザ２００から引落承認の選択入力を受け付け（ステップＳ６１）、キャッシュカードや通帳の挿入を促して、その後周知の認証処理を実施する（ステップＳ６３）。この際図示しない認証サーバにアクセスする場合もあるが、ここでは説明は省略する。また、認証は問題なく成功したものとする。

その後、ＡＴＭ９は、キャッシュカード等から読み取った口座番号を含む承認検索要求を生成して、銀行システム７に送信する（ステップＳ６５）。なお、ステップＳ６５より前に、承認を行う予定の引落番号の入力をユーザ２００に対して求め、口座番号と共に引落番号をも送信するようにしてもよい。

銀行システム７の承認処理部７８は、ＡＴＭ９から口座番号を含む承認検索要求を受信し、口座番号を例えばメインメモリなどの記憶装置に格納する（ステップＳ６７）。そして、口座番号で支払人テーブル７７を検索し、ユーザ２００に発行されている引落番号を特定する（ステップＳ６８）。承認検索要求に引落番号が含まれる場合には、ステップＳ６８はスキップされる。そして、引落テーブル７５から、ステップＳ６８で特定された引落番号に対応する振込依頼であって結果が登録されていない振込依頼のデータを抽出し、抽出された振込依頼に含まれる振込番号で受取人テーブル７６を検索して得られる受取条件に含まれる受取期間に該当する振込依頼を特定することによって、未承認且つ受取期間内の振込依頼を抽出する（ステップＳ６９）。

承認処理部７８は、抽出された振込依頼から、該当する振込依頼の販売店及び金額（引落テーブル７５からのデータ）を含む未承認リストを生成し、ＡＴＭ９に送信する（ステップＳ７１）。ＡＴＭ９は、銀行システム７から未承認リストを受信し、表示装置に表示する（ステップＳ７３）。例えば図２０のような表示画面が表示される。すなわち、抽出された振込依頼につき、販売店及び金額が列挙されており、内容照会ボタンも表示されている。ユーザ２００は、承認、拒否、購入無しを登録する対象となる振込依頼に対応する内容照会ボタンを押す。

ＡＴＭ９は、ユーザ２００からの承認対象の選択を受け付け、承認対象である振込依頼を特定するデータ（依頼番号又は依頼番号を特定するための識別子）を銀行システム７に送信する（ステップＳ７５）。銀行システム７の承認処理部７８は、ＡＴＭ９から、承認対象である振込依頼を特定するデータを受信し（ステップＳ７７）、承認対象の振込依頼の依頼番号を特定し、振込テーブル７４から当該依頼番号に対応する詳細データ（購入商品（レシート印字データに含まれるデータ）、購入日（振込依頼日）、金額など）を抽出する（ステップＳ７９）。そして、引落テーブル７５からの販売店名などを含む、承認対象の振込依頼の詳細データをＡＴＭ９に送信する（ステップＳ８１）。ＡＴＭ９は、銀行システム７から承認対象の振込依頼の詳細データを受信し、表示装置に表示する（ステップＳ８３）。そして処理は端子Ａ及びＢを介して図２２の処理に移行する。

ステップＳ８３では、例えば図２１に示すような画面が表示される。図２１の画面例では、支払先（販売店名）、ご購入品（レシート印字データに含まれるデータ）、ご購入日（振込依頼日）、金額が表示されるようになっており、承認ボタンと、拒否ボタンと、購入無しボタンとが選択可能になっている。ユーザ２００は、表示内容を確認し、承認、拒否、購入無しのいずれかを選択する。

図２２の処理の説明に移って、ＡＴＭ９は、承認、拒否、購入無しのいずれかの指示入力を受け付け、銀行システム７に送信する（ステップＳ８５）。銀行システム７の承認処理部７８は、ＡＴＭ９から承認、拒否、購入無しのいずれかの指示を受信し（ステップＳ８７）、承認が指示されたか判断する（ステップＳ８９）。承認が指示されている場合には、引落承認テーブル７９に承認対象の振込依頼のデータを登録する（ステップＳ９１）。ステップＳ９１では、承認対象の振込依頼に係る引落番号で支払人テーブル７７を検索し、引落条件に含まれる決済日のデータを抽出して、決済日を特定し、当該決済日に対応して振込依頼のデータ（例えば引落番号など）を引落承認テーブル７９に登録する。

引落承認テーブル７９は、例えば図２３に示すようなデータ構造を有する。具体的には、決済日（決済実施日）毎に、引落番号が対応付けられ、さらに引落番号に対応して、取引履歴（依頼番号）が対応付けられている。そして、取引履歴には、承認日時、承認内容（承認）及び引落結果（引落実施時に登録）が含まれる。

一方、承認が指示されていない場合には、引落承認拒否テーブル８０に、操作日に対応して振込依頼のデータ（例えば引落番号など）を登録する（ステップＳ９３）。引落承認拒否テーブル８０は、例えば図２４に示すようなデータ構造を有する。具体的には、操作日毎に、引落番号が対応付けられ、さらに引落番号に対応して、取引履歴（依頼番号）が対応付けられ、取引履歴には操作内容（拒否又は購入無し）が含まれる。

ステップＳ９１又はＳ９３の後に、承認処理部７８は、引落テーブル７５及び振込テーブル７４に結果を登録する（ステップＳ９５）。すなわち、引落番号及び依頼番号に対応して、結果（承認日及び承認内容）を、引落テーブル７５に登録し、振込番号及び依頼番号に対応して、結果（承認日及び承認内容）を、振込テーブル７４に登録する。

その後、承認処理部７８は、受け付け完了通知をＡＴＭ９に送信する（ステップＳ９７）。ＡＴＭ９は、銀行システム７から受け付け完了通知を受信し、表示装置に表示する（ステップＳ９９）。すなわち、承認等の処理が完了した旨を表示する。

また、ユーザ２００によって承認が指示されていれば、銀行システム７の承認処理部７８は、該当する振込依頼に係る振込番号と依頼番号に対応して振込テーブル７４に登録されているレシート印字データ及び摘要文言データ（通帳がある場合）を抽出し、ＡＴＭ９に送信する（ステップＳ１０１）。ＡＴＭ９は、銀行システム７からレシート印字データ及び摘要文言データを受信し、レシート印字データについてはレシートに印刷して出力し、摘要文言については通帳に記帳して通帳を出力する（ステップＳ１０３）。

さらに、承認処理部７８は、受取人テーブル７６を、該当する振込依頼の振込番号で検索して連絡先データ（例えば電子メールなど）を取得し、当該連絡先データを用いて承認結果通知を実施する（ステップＳ１０５）。例えば電子メール、場合によって結果を印字した紙を郵送したり、ＦＡＸで送信したりする。さらに、該当する振込依頼の引落番号で支払人テーブル７７を検索し、引落条件の引落通知の引落前連絡要否が要となっているか判断し、要であれば、連絡先（メールアドレスなど）に決済実施日などを通知する。

このような処理を実施することで、ユーザ２００は、銀行３００に通知されている各振込依頼について、引落の承認を行うか否かを判断することができるようになる。すなわち、自らの意思で、自らの決済用口座から資金を引き落とすか否かを指示することができる。さらに、通常の振込をするような手間は必要ない。

また、レシート印字データをチケットデータ（座席情報など）とすることによって、レシートをそのままチケット代わりにすることができるようになる。また、予約販売の引換券、クーポンなどとして用いることもできるようになる。

次に、決済を行う際の処理について図２５乃至図２７を用いて説明する。銀行システム７の決済処理部８３は、引落承認テーブル７９において決済実施日が処理日である未処理レコードを１つ取得し（ステップＳ１１１）、当該取得レコードに含まれる引落番号及び依頼番号で引落テーブル７５を検索して、該当する振込番号、金額及び決済口座用の口座番号データ（他行の場合）を特定する。上で述べたように、振込番号は銀行コードなどの銀行を特定するコードを含んでいるので、決済処理部８３は、振込番号から送金先が他行であるか判断する（ステップＳ１１３）。送金先が他行であれば、銀行コード、引落テーブル７５から読み出された送金先の決済用の口座番号及び支払人テーブル７７から引落番号で特定される支払人の決済用口座の口座番号を、振込処理部８５に通知して、周知の振込処理を実施させる（ステップＳ１１７）。周知の振込処理では、図２６に模式的に示したように、ユーザ２００の決済用口座から、引落テーブル７５から特定される金額を出金して、為替で受取人の決済用口座（他行）へ送金する。

一方、自行内の送金である場合には、決済処理部８３は、引落テーブル７５から読み出された振込番号で受取人テーブル７６を検索して決済用口座の口座番号を特定すると共に、取得レコードに含まれる引落番号で支払人テーブル７７を検索して決済用口座の口座番号を特定し、それらを引落処理部８４に通知し、周知の引落処理を実施させる（ステップＳ１１５）。周知の引落処理では、図２７に模式的に示したように、ユーザ２００の決済用口座から、引落テーブル７５から特定される金額を出金して、受取人の決済用口座へ入金する。

ステップＳ１１５又はＳ１１７の後に、決済処理部８３は、引落処理部８４又は振込処理部８５から処理結果を受け取り、引落承認テーブル７９の処理対象レコードに対して、処理結果を登録する（ステップＳ１１８）。また、取得レコードに含まれる引落番号で支払人テーブル７７を検索し、引落条件に含まれる引落通知の引落結果通知の要否を判断し、引落結果通知要であれば、連絡先（メールアドレスなど）に引落実施結果を通知する（ステップＳ１１９）。

その後、決済実施日が処理日である未処理のレコードが存在するか判断し（ステップＳ１２０）、未処理のレコードが存在している場合にはステップＳ１１１に戻り、未処理のレコードが存在しない場合には処理を終了させる。

以上のような処理を実施することによって、決済実施日に適切に送金処理が行われるようになる。

上で述べたように、支払人テーブル７７において引落番号に対応して登録される引落条件の可否情報に、「無条件引落許可」が登録されている場合がある。従って、例えば各営業日に、図２５の処理を実施する前に、無条件引落許可が引落条件として設定されている引落番号を特定すると共に、当該引落番号が登録されている振込依頼を特定して、自動承認処理を実施する。

具体的には、まず、銀行システム７の承認処理部７８は、無条件引落許可が引落条件として登録されている引落番号を支払人テーブル７７において特定し、当該引落番号から無条件引落許可に該当する振込依頼を引落テーブル７５から抽出する（図２８：ステップＳ１２１）。そして、抽出された振込依頼について、自動承認処理を実施する（ステップＳ１２３）。具体的には、図２２のステップＳ９１、Ｓ９５及びＳ１０５を実施する。決済実施日については、図２８の処理を実施した日とする。

このように図２８の処理を実施すれば、自動承認の場合にも適切に送金を行うことができるようになる。

なお、銀行システム７の承認処理部７８は、引落テーブル７５を検索して結果が登録されていない振込依頼を特定し、当該振込依頼に係る振込番号を特定し、当該振込番号から受取人テーブル７６を検索して該当する受取期間を特定する。そして、処理日及び振込依頼日から受取期間を経過しているか判断して、経過している場合には「拒否」と判断し、自動拒否処理として、図２２のステップＳ９３、Ｓ９５及びＳ１０５を実施する。これによって、未承認で放置された振込依頼について処理を行うことができるようになる。

次に、ユーザ２００と販売店１００の評価のための処理について図２９を用いて説明する。集計処理部８１は、引落テーブル７５において、引落番号毎に全振込依頼件数（結果が登録されている振込依頼の件数）及び拒否件数をカウントし、集計データ格納部８２に格納する（ステップＳ１３１）。また、支払人テーブル７７から同一支払人の引落番号を特定し、同一支払人について、全振込依頼件数及び拒否件数を集計して、集計データ格納部８２に格納する（ステップＳ１３３）。そして、引落番号毎及び支払人毎の拒否割合（＝拒否件数／全振込依頼件数）を算出し、集計データ格納部８２に格納する（ステップＳ１３５）。また、振込テーブル７４において、振込番号毎に全振込依頼件数（結果が登録されている振込依頼の件数）及び購入無しの件数をカウントし、集計データ格納部８２に格納する（ステップＳ１３７）。そして、受取人テーブル７６から同一受取人の振込番号を特定し、同一受取人について全振込依頼件数及び購入無し件数を集計し、集計データ格納部８２に格納する（ステップＳ１３９）。その後、振込番号毎及び受取人毎に購入無し割合（＝購入無し件数／全振込依頼件数）を算出し、集計データ格納部８２に格納する（ステップＳ１４１）。そして、管理人などの要求に応じて、集計データ格納部８２に格納されているデータを出力する（ステップＳ１４３）。

例えば管理人は、集計データ格納部８２に格納されているデータを基に、拒否件数又は拒否割合が所定の閾値以上のユーザ２００や、購入無し件数又は購入無し割合が所定の閾値以上の販売店１００を特定して、警告を行ったり、契約を解除するようにする。

これによって、不適切なユーザや販売店に改善を促したり、それらを排除して、送金が適切に実施されるようにする。なお、件数や割合に応じて、ユーザ２００や販売店１００を格付けしても良い。

［実施の形態２］
上で述べた第１の実施の形態であっても、公共料金（例えば、水道料、給食費や、公立病院の医療費など）や税金の一括納付は可能である。しかしながら、第１の実施の形態では、分納を実施するには、受取人である自治体などが、分納回数だけ振込依頼を生成して、金融機関に送付しなければならない。また、延滞料をさらに徴収するような場合にも受取人である自治体などに手間がかかる。特に、近年未納者や延滞者が非常に増加しており、このような未納者や延滞者からの徴収業務の効率化が望まれている。なお、サービスや物品の購入代金の分割支払いについても同様である。

さらに、第１の実施の形態では、不正を行ったり問題のある受取人（販売店など）についても、自動的に取引を停止したり、入金・送金を停止したりすることはできなかった。

以上のような問題を解決すべく、分納（公共料金や税金の分納に限定せず、他の分割払いも含む）にも対応可能なシステムを提供する。

まず、本発明の第２の実施の形態に係る分納の処理概要を図３０乃至図７３を用いて説明する。但し、第１の実施の形態における図１及び図２の手続きは完了しているものとする。また、図１及び図２の販売店１００は、第２の実施の形態における自治体６００に相当し、図１及び図２のユーザ２００は、第２の実施の形態における支払人７００に相当する。なお、自治体６００と銀行３００との契約には、適用すべき延滞料（又は分割払いの手数料。但しこれらは０％の場合もある）の利率、納付間隔（例えば１月ごと）なども含まれる。

まず、自治体６００と支払人７００とは、税金や公共料金などの分納を合意し、支払人７００は、決済に用いる引落番号を自治体７００に通知する（ステップ（１））。なお、合意においては、１回の納付金額又は納付回数、延滞料の利率などの合意も含まれる。そうすると、自治体６００は、振込依頼の代わりに、支払人７００のデータ（氏名など）及び引落番号、自治体の振込番号、分納内容データ（例えば「自動車税」など）、分納総額、１回の納付金額及び納付開始日を含む分納徴収依頼を１回のみ銀行３００に通知する（ステップ（２））。銀行３００は、分納徴収依頼に応じて、振込テーブルに、支払人７００のデータ、引落番号、初回分のデータ（請求開始日（納付開始日）、請求終了日（契約上の納付間隔後の日の前日）、請求額（１回の納付金額）、残額（分納総額））、依頼受領日、レシート印字内容（例えば「自動車税？円入金いただきました」。？は実際の承認金額。）、摘要文言（例えば自動車税分納）を登録し、引落テーブルに、自治体６００のデータ、振込番号、初回分のデータ、（請求開始日（納付日）、請求終了日（契約上の納付間隔後の日の前日）、請求額（１回の納付金額）、残額（分納総額））、依頼受領日などを登録する（ステップ（３））。

その後、支払人７００が、銀行３００のＡＴＭに行き、認証を行った後、該当する振込依頼及び分納徴収依頼のうち、特定の分納徴収依頼について支払承認を与える（ステップ（４））。以下でも述べるが、分納の場合には、１回の支払金額を変更することができる。銀行３００は、支払人７００からの支払承認を受け受けると、振込テーブルのレシート印字内容（例えば「自動車税３００００円入金いただきました」）を印字して、出力する（ステップ（５））。また、銀行３００は、振込テーブル及び引落テーブルに、支払承認の結果を登録する（ステップ（６））。そして、銀行３００は、以下で述べるような出金処理を実施する（ステップ（７））。自治体６００への入金・送金処理は、後に述べるように承認日から所定の猶予日後に行われる。さらに、銀行３００は、自治体６００に、回収結果を通知する（ステップ（８））。回収結果は、支払承認が行われる毎、及び納付間隔内に納付が行われなかったことを確認した場合に行われる。また、銀行３００は、完済するまで（残額が「０」での納付が行われるまで）、次回のための依頼内容データを自動的に生成し、振込テーブル及び引落テーブルに登録する（ステップ（９））。

このような処理を行うことによって、分納の場合でも、自治体６００は、１回だけ銀行３００に分納徴収依頼を送付することによって、適切に各回の分納の処理を銀行３００に実施させることができる。なお、本実施の形態でも分納以外の１回払いも可能であり、その点については、以下で詳細に説明する。

本実施の形態に係る決済サービスにおいて用いられるコンピュータ・システムの概要は第１の実施の形態におけるコンピュータ・システム（図４）と同様である。但し、自治体６００の場合には、販売店サーバ３の代わりに自治体サーバが用いられる。

このコンピュータ・システムに含まれる、本実施の形態に係る銀行システム７の機能ブロック図を図３２に示す。銀行システム７は、販売店１００又は自治体６００からの利用申請についてのデータを登録する処理を実施する販売店登録部５７２と、販売店登録部５７２により登録されたデータを格納する受取人テーブル５７６と、ユーザ２００又は支払人７００からの利用申請についてのデータを登録する処理を実施するユーザ登録部５７３と、ユーザ登録部５７３により登録されたデータを格納する支払人テーブル５７７と、受取人テーブル５７６及び支払人テーブル５７７を参照し、販売店１００又は自治体６００から振込依頼又は分納徴収依頼を受け付け、受取人用のデータ及び支払人用のデータを生成する振込依頼受付部５７１と、振込依頼受付部５７１によって生成された受取人用のデータを格納する振込テーブル５７４と、振込依頼受付部５７１によって生成された支払人用のデータを格納する引落テーブル５７５と、格付毎に入金猶予日数が登録されている入金・送金猶予日数テーブル５９０と、振込テーブル５７４、引落テーブル５７５、受取人テーブル５７６、支払人テーブル５７７及び入金・送金猶予日数テーブル５９０を参照し、ＡＴＭ９と連携して承認確認処理を実施する承認処理部５７８と、ユーザ２００又は支払人７００から承認を得られた場合に承認処理部５７８の処理結果を格納する承認テーブル５７９と、ユーザ２００又は支払人７００から承認を得られなかった場合に承認処理部５７８の処理結果を格納する承認拒否テーブル５８０と、受取人テーブル５７６、支払人テーブル５７７、引落テーブル５７５、承認テーブル５７９及び入金・送金猶予日数テーブル５９０を参照して出金のための処理を実施する出金処理部５８３と、出金処理部５８３によって実施された出金に対応して入金・送金を行うためのデータを格納する入金・送金予定テーブル５８４と、入金・送金予定テーブル５８４のデータに従って入金・送金処理を実施する入金・送金処理部５８５と、格付処理のためのデータを格納する格付処理用データ格納部５８２と、振込テーブル５７４と格付処理用データ格納部５８２と承認拒否テーブル５８０とを参照して受取人（販売店１００及び自治体６００）の格付を行うための処理を実施する格付処理部５８１と、格付処理部５８１又は管理者によって取引停止と判断された受取人についてのデータを格納する取引停止リスト５８８と、取引停止に係る依頼内容データ及び入金・送金予定データを登録する取引停止テーブル５８７と、受取人テーブル５７６のデータを用いて取引停止リスト５８８に登録されている受取人について引落テーブル５７５及び入金・送金予定テーブル５８４に登録されているデータを取引停止テーブル５８７に移動させる取引停止処理部５８６と、受取人テーブル５７６のデータを用いて分納の納付期間内における未納付を特定して必要な依頼内容データを生成して振込テーブル５７４及び引落テーブル５７５に登録する分納監視処理部５８９とを有する。

なお、格付処理部５８１によって決定された受取人の格付は、受取人テーブル５７６に登録される。

次に、図３３乃至図７３を用いて図４及び図３２に示したシステムの処理内容を説明する。なお、ユーザ２００又は支払人７００から銀行３００への利用申請の際の処理については、図６に示したとおりである。また、支払人テーブル５７７に登録されるデータの全体的なデータ構造は図７に示すとおりである。そして、図３３に、各ユーザ／支払人についてのデータの詳細構造を示す。図３３では利用者３のデータ構造の具体例を示しており、利用者３を特定する氏名及び連絡先のデータに対応して決済用口座の口座番号（ここでは２つ）が登録されており、さらに各決済用口座の口座番号に対応して引落番号及び引落条件が１又は複数セット（図３３では、２セットずつ）登録される。引落条件については、有効期限（デフォルトのまま又は特に指定がある場合はその期限）、引落通知の有無及び事前／事後の別、引落通知の連絡先、引落可否情報といった条件が登録される。このように、引落番号毎に、引落条件を設定することができるので、ユーザ２００／支払人７００は、引落番号を、相手に応じて使い分けることができるようになる。なお、引落条件については、後に変更申請を行うことによって変更することができる。特に、後から販売店１００とのトラブルが発生したなどの理由で引落を行わないように設定する場合には、引落可否情報において、無条件引落禁止に設定すればよい。また、販売店１００が信頼できる場合には、引落可否情報において無条件引落許可に設定した引落番号を通知すれば、わざわざ承認手続きを実施することもなく、送金することができるようになる。

また、販売店１００又は自治体６００から銀行３００への利用申請の際の処理については、図９に示したとおりである。また、受取人テーブル５７６に登録されるデータの全体的なデータ構造は図１０に示すとおりである。本実施の形態では、自治体６００も法人や販売店と同様に登録される。図３４に、各法人ユーザ又は自治体についてのデータの詳細構造を示す。図３４では販売店Ａのデータ構造の具体例を示しており、販売店Ａを特定する名称、連絡先のデータ、及び以下で述べる格付に対応して、決済用口座の口座番号（ここでは２つ）が登録されており、さらに各決済用口座の口座番号に対応して振込番号及び受取条件が１又は複数セット（図３４では、２セットずつ）登録される。受取条件については、上で述べたように、有効期限（デフォルトのまま又は特に指定がある場合はその期限）、手数料（販売店又はユーザ）が登録される。このように、振込番号毎に、受取条件を設定することができるので、販売店１００は、振込番号を、相手に応じて使い分けることができるようになる。なお、受取条件については、後に変更申請を行うことによって変更することができる。受取条件には他にも設定することができ、例えば分納の時の利率や納付間隔が含まれる場合もある。従って、以下で述べる分納に係る依頼内容データを生成する際には、受取条件を読み出して処理する場合もある。

決済用口座は、例えば、現実の店舗毎、インターネット上のショッピングサイト毎などに設定する。さらに、各決済用口座について複数の振込番号を設定できるが、例えば、商品保存が容易なもの（例えば衣類、家具等）については長めの有効期限を設定した振込番号を、生鮮食品などの商品保存が難しいものについては短めの有効期限を設定した振込番号を用意しておき、使い分けることも可能である。

このような前処理の後に、実際の販売及び振込依頼の銀行システム７への送信が、図１２を用いて説明したようにオンラインで実施される。また、第１の実施の形態と同様に、ＦＡＸや電子メールの形で振込依頼又は分納徴収依頼を銀行システム７に送信するようにしても良いし、紙の形態で銀行に送付するようにしても良い。自治体６００についても、例えば支払人７００との分納の契約（支払条件を含む）の写しなど銀行に送付するようにしても良い。また、別途自治体６００において分納徴収依頼のデータを作成して送信するようにしても良い。

なお、振込依頼は、今回の決済で用いる振込番号、ユーザ２００又は支払人７００から取得した引落番号、ユーザ２００又は支払人７００の氏名及び連絡先、請求期間を特定するためのデータ（請求開始日及び請求終了日。但し、空でも良いし、請求開始日のみを含むようにしても良い）、金額、レシート印字内容（購入商品データなどを含む）、通帳に印字する摘要文言等を含む。

分納徴収依頼は、今回の決済で用いる振込番号、ユーザ２００又は支払人７００から取得した引落番号、ユーザ２００又は支払人７００の氏名及び連絡先、１回目の請求期間を特定するためのデータ（１回目の納付の納付開始日及び納付終了日。但し、納付開始日だけでもよい）、１回目の支払金額、全納付金額、レシート印字内容（購入商品データ又は支払対象公共料金若しくは税金などを含む）、通帳に印字する摘要文言等を含む。

次に、図３５乃至図５９を用いて振込依頼及び分納徴収依頼に対して実施される処理について説明する。銀行システム７の振込依頼受付部５７１は、振込依頼又は分納徴収依頼を、販売店サーバ３等から受信する（ステップＳ２０１）。例えば、ＦＡＸや電子メールの形式で送信されてきた場合には、それらから必要なデータを抽出する。また、銀行に紙の形式で振込依頼又は分納徴収依頼が送付された場合には、オペレータなどによって入力される振込依頼又は分納徴収依頼を取得する。

そして、振込依頼受付部５７１は、振込依頼又は分納徴収依頼に含まれるデータを支払人テーブル５７７と照合する（ステップＳ２０３）。具体的には、例えば振込依頼又は分納徴収依頼に含まれる今回の決済で用いる引落番号で支払人テーブル５７７を検索し、該当するユーザ２００等の氏名及び連絡先と、振込依頼又は分納徴収依頼に含まれるユーザ２００等の氏名及び連絡先とを照合する。なお、一致しない場合には、これ以降の処理は行わない。振込依頼又は分納徴収依頼の送信元などにエラーを通知するようにしても良い。さらに、本実施の形態では、振込番号で受取人テーブル５７６を検索し、該当する販売店１００等の格付が、取引停止に該当するような格付であるか確認する。取引停止に該当するような格付である場合には、振込依頼又は分納徴収依頼の送信元などに取引停止を通知するようにしても良い。

また、振込依頼又は分納徴収依頼に含まれる今回の決済で用いる振込番号が、他の提携銀行の振込番号である場合には、例えばネットワーク１を介して接続されている他の提携銀行の銀行システムに決済用口座の口座番号等のデータ要求を送信し、振込番号を他の提携銀行の銀行システムで確認してもらった上で、販売店名、連絡先、決済用口座の口座番号等を取得するようにする。

次に、振込依頼受付部５７１は、この振込依頼又は分納徴収依頼に対して依頼番号を生成する（ステップＳ２０４）。振込番号と引落番号の同一組み合わせの振込依頼が複数ある場合には、容易に振込依頼を識別できないので、依頼番号を導入する。なお、依頼番号は、システム通番と、分納徴収依頼の場合の各分納を区別するための追番との組み合わせで構成される。

そして、振込依頼受付部５７１は、振込依頼又は分納徴収依頼を用いて振込テーブル５７４にレコードを登録する（ステップＳ２０５）。振込テーブル５７４では、例えば図３６に示すようなデータ構造でデータを管理する。すなわち、振込番号毎に、依頼内容を登録するようになっており、ユーザ２００が承認等を行った場合には、その結果を依頼内容に対応して登録するようになっている。図３６にも示すように、追番無しの依頼番号（例えば「００００１」）の依頼内容データは、振込依頼に応じて生成され、追番ありの依頼番号（例えば「００００２−１」及び「００００２−２」）の依頼内容データは、分納徴収依頼に応じて生成される。

図３７に依頼内容と結果の詳細なデータ構造例を示す。依頼内容データは、依頼番号と、購入者であるユーザ２００等の氏名及び連絡先、引落番号、請求開始日及び請求終了日、請求金額、残額、振込依頼受領日、レシート印字データ、通帳記入の摘要文言を含む。さらに、依頼内容データには、結果のデータも対応付けられており、結果には、承認日、承認内容（承認、拒否）及び承認金額が対応付けられている。

例えば、振込依頼に対応して生成される振込テーブル５７４の依頼内容データの一例を図３８に示す。購入者の氏名及び連絡先、引落番号、請求終了日及び請求終了日、請求金額、レシート印字内容及び通帳記入の摘要文言については、振込依頼に含まれるデータのままである。残額については、分納でない場合には必ず「０」に設定される。振込依頼受領日については、振込依頼を受信又は受け付けた日である。

また、分納徴収依頼に対応して生成される振込テーブル５７４の依頼内容データの一例を図３９に示す。購入者の氏名及び連絡先、引落番号、レシート印字内容及び通帳記入の摘要文言については、分納徴収依頼に含まれるデータそのままである。請求開始日及び請求終了日は、分納徴収依頼に含まれる１回目の請求開始日及び請求終了日であり、請求金額は、１回目の支払金額であり、残額は、全支払金額である。振込依頼受領日は、分割徴収依頼を受信若しくは受け付けた日である。これは延滞料を算出する際に用いる。

さらに、振込依頼受付部５７１は、受取人テーブル５７６の該当データ（振込番号に対応する販売店名、連絡先など）及び振込依頼又は分納徴収依頼を用いて引落テーブル５７５にレコードを登録する（ステップＳ２０７）。引落テーブル５７５では、例えば図４１に示すようなデータ構造でデータを管理する。すなわち、引落番号毎に、依頼内容データを登録するようになっており、ユーザ２００等が承認などを行った場合には、その結果を依頼内容データに対応して登録するようになっている。依頼番号の付与の仕方は上で述べたとおりである。

図４２に依頼内容データと結果の詳細なデータ構造例を示す。依頼内容データは、依頼番号販売店名、販売店の連絡先、振込番号、請求開始日及び請求終了日、請求金額、残額、振込依頼受領日、他の提携銀行の振込番号の場合には販売店の決済用口座の口座番号が対応付けられている。さらに、依頼内容データには、結果のデータも対応付けられており、結果には、承認日、承認内容（承認、拒否）、承認金額が対応付けられている。

図３９に対応する引落テーブル５７５の依頼内容データの一例を図４０に示す。販売店名並びに連絡先、及び決済口座情報を除けば、図３９に示した依頼内容データと同様のデータが保持される。

ここまでで、ユーザ２００等が振込依頼又は分割徴収依頼の承認を行う前の処理が完了する。

次に、図４３乃至図５９を用いて、ユーザ２００等が、振込依頼又は分納徴収依頼について、承認等を実施する際の処理について説明する。ここでは、ユーザ２００等は、銀行システム７に接続されているＡＴＭ９に出向いて、ＡＴＭ９を操作するものとする。

まず、ユーザ２００等は、ＡＴＭ９の表示装置に表示されているメインメニュー（例えば図１９）のうち引落承認を選択する。ＡＴＭ９は、ユーザ２００等から引落承認の選択入力を受け付け（ステップＳ２１１）、キャッシュカードや通帳の挿入を促して、その後周知の認証処理を実施する（ステップＳ２１３）。この際図示しない認証サーバにアクセスする場合もあるが、ここでは説明は省略する。また、認証は問題なく成功したものとする。

その後、ＡＴＭ９は、キャッシュカード等から読み取った口座番号を含む承認検索要求を生成して、銀行システム７に送信する（ステップＳ２１５）。なお、ステップＳ２１５より前に、承認を行う予定の引落番号の入力をユーザ２００等に対して求め、口座番号と共に引落番号をも送信するようにしてもよい。

銀行システム７の承認処理部５７８は、ＡＴＭ９から口座番号を含む承認検索要求を受信し、口座番号を例えばメインメモリなどの記憶装置に格納する（ステップＳ２１７）。そして、口座番号で支払人テーブル５７７を検索し、ユーザ２００等に発行されている引落番号を特定する（ステップＳ２１８）。承認検索要求に引落番号が含まれる場合には、ステップＳ２１８はスキップされる。そして、引落テーブル５７５から、ステップＳ２１８で特定された引落番号に対応する依頼内容データであって結果が登録されていない依頼内容データを抽出し、現在日が、抽出された依頼内容データに含まれる請求開始日から請求終了日で規定される請求期間内の依頼内容データを特定することによって、未承認且つ請求期間内の依頼内容データを抽出する（ステップＳ２１９）。

承認処理部５７８は、抽出された依頼内容データから、該当する依頼内容データの案件毎に、販売店、請求金額（１回分の請求金額）及び納入期限（請求終了日又は請求終了日−現在日で算出される残日数）を含む未承認リストを生成し、ＡＴＭ９に送信する（ステップＳ２２１）。ＡＴＭ９は、銀行システム７から未承認リストを受信し、表示装置に表示する（ステップＳ２２３）。例えば図４４のような表示画面が表示される。すなわち、抽出された依頼内容データの案件につき、販売店、金額及び納入期限（ここでは残日数）が列挙されており、内容照会ボタンも表示されている。このように納入期限を表示することによって督促効果が出る。なお、ユーザ２００等は、承認等を登録する対象となる依頼内容データに対応する内容照会ボタンを押す。

ＡＴＭ９は、ユーザ２００等からの承認対象の選択を受け付け、承認対象である依頼内容データを特定するデータ（依頼番号又は依頼番号を特定するための識別子）を銀行システム７に送信する（ステップＳ２２５）。銀行システム７の承認処理部５７８は、ＡＴＭ９から、承認対象である依頼内容データを特定するデータを受信し（ステップＳ２２７）、承認対象の依頼内容データの依頼番号を特定し、振込テーブル５７４から当該依頼番号に対応する詳細データ（購入商品（レシート印字データに含まれるデータ）、購入日（振込依頼日）、金額など）を抽出する（ステップＳ２２９）。そして、販売店名などを含む、承認対象の依頼内容データの詳細データをＡＴＭ９に送信する（ステップＳ２３１）。ＡＴＭ９は、銀行システム７から承認対象の依頼内容データの詳細データを受信し、表示装置に表示する（ステップＳ２３３）。そして処理は端子Ｃ及びＤを介して図４６の処理に移行する。

ステップＳ２３３では、例えば図４５に示すような画面が表示される。図４５の画面例では、支払先（販売店名又は自治体名）、ご購入品（レシート印字データに含まれるデータ）、ご購入日（振込依頼日）、金額（請求金額）が表示されるようになっており、分納ボタンと、戻るボタンとが選択可能となっている。図４５の例では、分納徴収依頼に係る依頼内容データを表示するものであって、分納徴収依頼の場合には、分納又は戻るしか選択できない。振込依頼の場合には、承認ボタンと、拒否ボタンと、戻るボタンとが選択可能になっており、いずれかを選択できる。

図４６の処理の説明に移行して、ＡＴＭ９は、ユーザ２００等からの指示入力を受け付け、銀行システム７に送信する（ステップＳ２３５）。本実施の形態では、指示入力は、承認、拒否、分納、戻るのいずれかになる。銀行システム７の承認処理部５７８は、ＡＴＭ９から指示入力を受信し（ステップＳ２３７）、分納が指示されたか判断する（ステップＳ２３９）。分納以外が指示された場合には、端子Ｅを介して図５６の処理に移行する。

一方、分納が指示された場合には、承認処理部５７８は、承認対象である依頼内容データに含まれる請求金額とレシート印字内容（購入商品。例えば「自動車税」）とから、規定通りの納付データを生成すると共に、金額変更範囲（所定の最低納入金額から残額まで）のデータを生成し、当該納付データ及び金額変更範囲データを含む分納金額指定データを生成し、ＡＴＭ９に送信する（ステップＳ２４１）。ＡＴＭ９は、分納金額指定データを受信し、表示装置に表示する（ステップＳ２４３）。例えば、図４７に示すような画面が表示される。具体的には、上段には、購入商品（自動車税）と、規定通りの請求金額と、その請求金額をそのまま支払う場合の承認ボタンとが表示され、下段には、上記金額変更範囲で金額を変更して支払承認を行うための金額入力欄及び承認ボタンが表示されている。ユーザ２００等は、上段の承認ボタンを押すか、下段の金額入力欄に金額を入力して承認ボタンを押す。

ＡＴＭ９は、ユーザ２００等からの指示に従って、金額及び承認指示を銀行システム７に送信する（ステップＳ２４５）。銀行システム７は、ＡＴＭ９から金額及び承認指示を受信し（ステップＳ２４７）、当該金額及び承認対象である依頼内容データ（引落テーブル５７５及び振込テーブル５７４の該当データ）並びに受取人テーブル５７６から、出金及び入金のためのデータを生成して承認テーブル５７９に登録する（ステップＳ２４９）。承認テーブル５７９のデータ構造の一例を図４８に示す。図４８の例では、承認日毎に、引落番号（振込テーブル５７４）に対応して、依頼番号（振込テーブル５７４又は引落テーブル５７５）、承認日時、指定された金額、受取人情報（受取人テーブル５７６からの、振込番号に対応する入金先口座情報及び受取人名（引落テーブル５７５））が登録されるようになっている。

そして、銀行システム７の承認処理部５７８は、受け付け完了通知をＡＴＭ９に送信する（ステップＳ２５１）。ＡＴＭ９は、銀行システム７から受け付け完了通知を受信し、表示装置に表示する（ステップＳ２５３）。すなわち、承認の処理が完了した旨を表示する。さらに、承認処理部５７８は、該当する依頼内容データに係る振込番号及び依頼番号に対応して振込テーブル５７４に登録されているレシート印字内容データ及び摘要文言データ（通帳がある場合）を抽出し、ＡＴＭ９に送信する（ステップＳ２５５）。ＡＴＭ９は、銀行システム７からレシート印字内容データ及び摘要文言データを受信し、レシート印字内容データについてはレシートに印刷して出力し、摘要文言については通帳に記帳して通帳を出力する（ステップＳ２５７）。処理はさらに端子Ｆを介して図４９の処理に移行する。

図４９の処理の説明に移行して、承認処理部５７８は、振込テーブル５７４及び引落テーブル５７５において、承認対象の依頼内容データに対応して、承認日、承認内容（承認）及び金額を含む結果を登録する（ステップＳ２５８）。さらに、承認処理部５７８は、承認対象の依頼内容データに対応して、現在の残額が０でなければ、次回分納のための依頼内容データを自動生成し、振込テーブル５７４及び引落テーブル５７５に登録する（ステップＳ２５９）。

例えば、図３９に示すような振込テーブル５７４の依頼内容データに対して、ユーザ２００等が請求金額通りの４００００円の支払いを承認した場合、ステップＳ２５７では図３９の結果データが登録される。図３９の例では、承認内容には「分納承認」、承認金額には「４００００円」が登録される。図４０の引落テーブル５７５についても同様のデータが結果データとして登録される。

ステップＳ２５９では、追番を１インクリメントした依頼番号００００２−２の依頼内容データを生成する。具体的には、請求開始日及び請求終了日を、設定されている納付間隔（例えば１月。振込番号に対応する受取条件の１つの場合もある。）だけずらす。さらに、新たな残額＝旧残額−承認金額に設定する。具体的には、図５０Ａに示すように、依頼番号が「００００２−２」となっており、請求開始日及び請求終了日は、図３９の請求開始日及び請求終了日から１月ずらされており、残額は８００００円（＝１２００００−４００００）と変更されている。引落テーブル５７５についても、同様の変更が加えられた依頼内容データ「００００２−２」が登録される。引落テーブル５７５についても図５０Ｂに示すように、上で述べたのと同様の変更が加えられた依頼内容データ「００００２−２」が登録される。

次に、図５０Ａに示すような振込テーブル５７４の依頼内容データに対して、ユーザ２００等が請求金額通りではなく３００００円の支払いを承認した場合、ステップＳ２５７では図５０Ａの結果データが登録される。図５０Ａの例では、承認内容には「分納承認」、承認金額には「３００００円」が登録される。図５０Ｂの引落テーブル５７５についても同様のデータが結果データとして登録される。

ステップＳ２５９では、さらに追番を１インクリメントした依頼番号００００２−３の依頼内容データを生成する。具体的には、請求開始日及び請求終了日を、設定されている納付間隔（例えば１月）だけずらす。さらに、新たな残額＝旧残額−承認金額に設定する。具体的には、図５１Ａに示すように、依頼番号が「００００２−３」となっており、請求開始日及び請求終了日は、図５０Ａの請求開始日及び請求終了日から１月ずらされており、残額は５００００円（＝８００００−３００００）と変更されている。引落テーブル５７５についても、同様の変更が加えられた依頼内容データ「００００２−３」が登録される。引落テーブル５７５についても図５１Ｂに示すように、上で述べたのと同様の変更が加えられた依頼内容データ「００００２−３」が登録される。

ここで、図５１Ａに示すような振込テーブル５７４の依頼内容データに対して、ユーザ２００等が支払承認を行わなかったとする。そうすると、ステップＳ２５７及びＳ２５９は実施されない。以下で述べる分納監視処理部５８９による処理が実施され、請求開始日から請求終了日までに支払承認が実施されなかった分納に係る依頼内容データを探索して、図５１Ａに示すような結果データを生成して登録する。すなわち、承認日は「−」であり、承認内容は「未納」であり、承認金額が「０」である。引落テーブル５７５についても、図５１Ｂに示すように、同様の結果データが登録される。

そして、さらに追番を１インクリメントした依頼番号００００２−４の依頼内容データを生成する。具体的には、請求開始日及び請求終了日を、設定されている納付間隔（例えば１月）だけずらす。さらに、新たな残額＝旧残額−承認金額に設定する。但し、承認金額が０なので残額＝旧残額となる。具体的には、図５２Ａに示すように、依頼番号が「００００２−４」となっており、請求開始日及び請求終了日は、図５１Ａの請求開始日及び請求終了日から１月ずらされており、残額は５００００円のままである。引落テーブル５７５についても、同様の変更が加えられた依頼内容データ「００００２−４」が登録される。引落テーブル５７５についても図５２Ｂに示すように、上で述べたのと同様の変更が加えられた依頼内容データ「００００２−４」が登録される。

その後、図５２Ａに示すような振込テーブル５７４の依頼内容データに対して、ユーザ２００等が請求金額通り４００００円の支払いを承認した場合、ステップＳ２５７では図５２Ａの結果データが登録される。図５２Ａの例では、承認内容には「分納承認」、承認金額には「４００００円」が登録される。図５２Ｂの引落テーブル５７５についても同様のデータが結果データとして登録される。

ステップＳ２５９では、さらに追番を１インクリメントした依頼番号００００２−５の依頼内容データを生成する。具体的には、請求開始日及び請求終了日を、設定されている納付間隔（例えば１月）だけずらす。さらに、新たな残額＝旧残額−承認金額に設定する。具体的には、図５３Ａに示すように、依頼番号が「００００２−５」となっており、請求開始日及び請求終了日は、図５２Ａの請求開始日及び請求終了日から１月ずらされており、残額は１００００円（＝５００００−４００００）と変更されている。残額≧１回あたりの請求金額であれば、請求金額を変更する必要はないが、今回残額１００００円で１回あたりの請求金額４００００円を下回る。従って、請求金額も１００００円に変更する必要がある。引落テーブル５７５についても、同様の変更が加えられた依頼内容データ「００００２−５」が登録される。引落テーブル５７５についても図５３Ｂに示すように、上で述べたのと同様の変更が加えられた依頼内容データ「００００２−５」が登録される。

その後、図５３Ａに示すような振込テーブル５７４の依頼内容データに対して、ユーザ２００が請求金額通り１００００円の支払いを承認した場合、ステップＳ２５７では図５３Ａの結果データが登録される。図５３Ａの例では、承認内容には「分納承認」、承認金額には「１００００円」が登録される。図５３Ｂの引落テーブル５７５についても同様のデータが結果データとして登録される。

ステップＳ２５９では、さらに追番を１インクリメントした依頼番号００００２−６の依頼内容データを生成する。なお、残額＝旧残額−承認金額＝０となる場合には、上で述べたような変更とは異なる変更を行って依頼内容データを生成する。具体的には、図５４Ａに示すように、請求開始日は、設定されている納付間隔だけずらすが、請求終了日については設定しない。また、残額は０に設定される。さらに、請求金額は、延滞料を算出して設定することになる。延滞料は、金額×利率×（延滞日数／３６５）で計算されるが、実際には納付毎に金額を変更して算出する。図３９のデータからは、延滞日数＝承認日（２００８／０６／１０）−請求開始日（２００８／０５／２５）＝１６であり、金額はその間の残高１２００００円となる。さらに、図５０Ａのデータからは、延滞日数＝承認日（２００８／０７／０７）−請求開始日（２００８／０６／２５）＝１２であり、金額はその間の残高８００００円となる。また、図５１Ａのデータからは、承認日がないので延滞日数＝３１日であり、金額はその間の残高５００００円である。さらに、図５２Ａのデータからは、延滞日数＝承認日（２００８／０８／２６）−請求開始日（２００８／０８／２５）＝１であり、金額はその間の残高５００００円である。また、図５３Ａのデータからは、延滞日数＝承認日（２００８／１０／２３）−請求開始日（２００８／０９／２５）＝２８であり、金額はその間の残高１００００円である。このように通番を共通とする依頼番号の全ての追番について延滞料を算出して合計した金額が合計の延滞料となり、これが最後の請求金額となる。引落テーブル５７５についても、同様の変更が加えられた依頼内容データ「００００２−６」が登録される。引落テーブル５７５についても図５４Ｂに示すように、上で述べたのと同様の変更が加えられた依頼内容データ「００００２−６」が登録される。

なお、本実施の形態では、分納に係る依頼内容データであっても、残額が「０」の場合には、分納として取り扱わない。これは、延滞料については金額を調整して納付できないようにするためであって、図４３のステップＳ２３１で、依頼番号が追番を含んでおり分納に係る依頼内容データについて詳細データを送信する場合であっても、ステップＳ２３３では、「分納」ボタンを選択できないようにして、「承認」ボタン及び「戻る」ボタンのみを選択できるようにする。そうすると、図４６のステップＳ２３９では、Ｎｏルートで端子Ｅ以降の処理を実施することになる。

図４９の処理の説明に戻って、承認処理部５７８は、回収結果を受取人（例えば自治体６００）に通知する（ステップＳ２６１）。例えば、ネットワークを介してデータを送信することもあれば、メールを送信しても良いし、データを印字して書類として送付してもよい。なお、回収結果は、例えば依頼内容データに対応して登録される結果データの内容を含む。但し、例えば承認金額が入金される日を算出して当該回収結果に含めるようにしても良い。

本実施の形態では、受取人に設定されている格付に応じて、承認日からの入金猶予日数が設定されている。これは、問題のある販売店などに早期に入金・送金することによる問題を回避することが目的であって、場合によっては送金を停止してユーザ２００等が回収できるようにするためである。入金・送金猶予日数テーブル５９０には、例えば図５５に示すようなデータが保持されている。図５５の例では、各格付に対して、銀行３００等が設定した猶予日数が登録されるようになっている。従って、受取人テーブル５７６から、承認対象の依頼内容データに係る振込番号に対応する受取人（販売店）の格付を読み出し、さらに入金・送金猶予日数テーブル５９０から当該格付に対応する猶予日数を読み出す。そして、承認日＋猶予日数によって、入金・送金日を算出する。

このような処理を実施することによって、本実施の形態では、自治体などの手間を削減して分納を取り扱うことができるようになる。

次に、図４６のステップＳ２３９で分納が選択されなかった場合の処理を図５６を用いて説明する。次に、承認処理部５７８は、ＡＴＭ９から受信した指示入力が「戻る」の指示であったか判断する（ステップＳ２７１）。「戻る」の指示であった場合には端子Ｇを介して図４３のステップＳ２２１に戻る。すなわち抽出依頼内容データの未承認リストを提示するようにする。

一方、「戻る」指示でない場合には、承認処理部５７８は、「承認」指示であるか判断する（ステップＳ２７３）。承認が指示されている場合には、承認対象の依頼内容データ（引落テーブル５７５及び振込テーブル５７４の該当データ）並びに受取人テーブル５７６から、出金及び入金のためのデータを生成して承認テーブル５７９に登録する（ステップＳ２７５）。承認テーブル５７９のデータ構造は、例えば図４８に示したとおりである。なお、承認でない場合には、端子Ｈを介して図５７の処理に移行する。

また、承認処理部５７８は、振込テーブル５７４及び引落テーブル５７５において、承認対象の依頼内容データに対応して、承認日、承認内容（承認）及び金額を含む結果を登録する（ステップＳ２７７）。

そして、承認処理部５７８は、受け付け完了通知をＡＴＭ９に送信する（ステップＳ２７９）。ＡＴＭ９は、銀行システム７から受け付け完了通知を受信し、表示装置に表示する（ステップＳ２８１）。すなわち、承認の処理が完了した旨を表示する。さらに、承認処理部５７８は、該当する依頼内容データに係る振込番号及び依頼番号に対応して振込テーブル５７４に登録されているレシート印字内容データ及び摘要文言データ（通帳がある場合）を抽出し、ＡＴＭ９に送信する（ステップＳ２８３）。ＡＴＭ９は、銀行システム７からレシート印字内容データ及び摘要文言データを受信し、レシート印字内容データについてはレシートに印刷して出力し、摘要文言については通帳に記帳して通帳を出力する（ステップＳ２８５）。

さらに、承認処理部５７８は、回収結果を受取人（例えば販売店）に通知する（ステップＳ２８７）。例えば、ネットワークを介してデータを送信することもあれば、メールを送信しても良いし、データを印字して書類として送付してもよい。例えば受取人テーブル５７６を、該当する依頼内容データの振込番号で検索して連絡先データ（メールアドレスやＩＰアドレス、郵送先など）を取得して行う。なお、回収結果は、例えば依頼内容データに対応して登録される結果データの内容を含む。但し、例えば承認金額が入金される日を算出して当該回収結果に含めるようにしても良い。入金される日の算出方法については、ステップＳ２６１で述べたとおりである。

さらに、承認処理部５７８は、該当する依頼内容データの引落番号で支払人テーブル５７７を検索し、引落条件の引落通知の引落前連絡要否が要となっているか判断し、要であれば、連絡先（メールアドレスなど）に決済実施日（承認日）などを通知する。

このような処理を実施することで、ユーザ２００等は、銀行３００に通知されている各振込依頼について、引落の承認を行うか否かを判断することができるようになる。すなわち、自らの意思で、自らの決済用口座から資金を引き落とすか否かを指示することができる。さらに、通常の振込をするような手間は必要ない。

また、レシート印字データをチケットデータ（座席情報など）とすることによって、レシートをそのままチケット代わりにすることができるようになる。また、予約販売の引換券、クーポンなどとして用いることもできるようになる。

一方、承認が指示されておらず拒否が指示されていると判断された場合の処理を図５７を用いて説明する。承認処理部５７８は、拒否事由選択データ（購入実績無し、金額相違、購入品相違、支払先相違）をＡＴＭ９に送信する（ステップＳ２９１）。ＡＴＭ９は、銀行システム７から拒否事由選択データを受信し、表示装置に表示する（ステップＳ２９３）。例えば図５８に示すような画面が表示される。図５８の画面例では、「購入実績無し」「金額相違」「購入品相違」「支払先相違」のいずれかの拒否事由を選択できるようになっている。ユーザ２００等は拒否事由ボタンのいずれかをクリックする。

ＡＴＭ９は、ユーザからの選択指示を受け付け、該当する選択拒否事由を銀行システム７に送信する（ステップＳ２９５）。銀行システム７の承認処理部５７８は、ＡＴＭ９から選択拒否事由を受信する（ステップＳ２９７）。そして、承認処理部５７８は、承認対象の依頼内容データに対応して、結果データを登録する（ステップＳ２９９）。結果データは、承認日として拒否指示日を、承認内容に拒否を、承認金額に０を含む。

さらに、承認処理部５７８は、承認拒否テーブル５８０に、操作日に対応して、承認拒否対象の依頼内容データに係る引落番号及び選択拒否事由を登録する（ステップＳ３０１）。承認拒否テーブル５８０は、例えば図５９に示すようなデータ構造を有する。具体的には、操作日毎に、引落番号が対応付けられ、さらに引落番号に対応して、依頼番号及び拒否事由が対応付けられる。

その後、承認処理部５７８は、受け付け完了通知をＡＴＭ９に送信する（ステップＳ３０３）。ＡＴＭ９は、銀行システム７から受け付け完了通知を受信し、表示装置に表示する（ステップＳ３０５）。すなわち、処理が完了した旨を表示する。

また、承認処理部５７８は、拒否通知を受取人（例えば販売店）に送付する（ステップＳ３０７）。例えば、ネットワークを介してデータを送信することもあれば、メールを送信しても良いし、データを印字して書類として送付してもよい。例えば受取人テーブル５７６を、該当する依頼内容データの振込番号で検索して連絡先データ（メールアドレスやＩＰアドレス、郵送先など）を取得して行う。なお、拒否通知は、例えば依頼内容データに対応して登録される結果データの内容及び選択拒否事由を含む。

このように、ユーザ２００等は問題のある振込依頼については、拒否事由を指摘して拒否することによって、不適切な出金を停止させることができる。

次に、図５１Ａ及び図５１Ｂの説明で触れた、分納監視処理部５８９の処理について図６０を用いて説明する。分納監視処理部５８９は、例えば毎日定期的に、振込テーブル５７４又は引落テーブル５７５から、分納に係る依頼内容データであって請求終了日までに支払承認を含む結果データが登録されていない依頼内容データを抽出する（ステップＳ３１１）。図５１Ａに示すような依頼内容データが抽出される。そして、支払い承認無しを表す結果データ（承認日「なし」、承認内容「未納」及び承認金額「０」）を、振込テーブル５７４及び引落テーブル５７５の該当する依頼内容データに対応して登録する（ステップＳ３１３）。図５１Ａ及び図５１Ｂに示す状態となる。

さらに、分納監視処理部５８９は、ステップＳ３１１で抽出された依頼内容データに含まれる振込番号で受取人テーブル５７６を検索し、該当する受取人の連絡先データ（例えば電子メールアドレス、ＩＰアドレス、郵送先など）を取得して、入金無しを表す回収結果を通知する（ステップＳ３１５）。ネットワークを介してデータを送信することもあれば、メールを送信しても良いし、データを印字して書類として送付してもよい。

また、分納監視処理部５８９は、依頼番号の追番を１インクリメントした同一内容の依頼内容データ（但し、上で述べたように請求開始日及び請求終了日については分納間隔だけずらす）を、振込テーブル５７４及び引落テーブル５７５に登録する（ステップＳ３１７）。

このような処理を実施することによって、分納について未納が発生しても必要となる依頼内容データを自動生成して、次の納付に備えることができる。

次に、図６１乃至図６６を用いて、決済についての処理について説明する。本実施の形態では、図６１に示すように、自行内送金の場合には、承認テーブル５７９に従ってユーザ決済口座から出金を行うが、直ぐに自行内の販売店決済口座に入金することなく、一旦入金・送金予定テーブル５８４に登録する。それから、販売店１００等の格付に応じて決定される入金日に、入金・送金予定テーブル５８４に従って販売店決済口座に入金する。一方、図６２に示すように、他行送金の場合には、承認テーブル５７９に従ってユーザ決済口座から出金を行うが、直ぐに他行における販売店決済口座に送金（為替）することなく、一旦入金・送金予定テーブル５８４に登録する。それから、販売店１００等の格付に応じて決定される入金日に、入金・送金予定テーブル５８４に従って他行の販売店決済口座に送金する。

まず、出金時の処理を図６３及び図６４を用いて説明する。なお、図６３の処理は、例えば定期的に実施するようにしても良いし、承認テーブル５７９にデータが追加される毎に実施するようにしても良い。出金処理部５８３は、承認テーブル５７９から未処理のレコード（図４８）を１つ抽出する（ステップＳ３２１）。そして、抽出レコード及び引落テーブル５７５に基づき支払人の決済用口座から出金処理を実施し、抽出レコードの依頼番号によって引落テーブル５７５から特定される振込番号で受取人テーブル５７６を検索して受取人の格付を特定し、当該受取人の格付に応じた猶予日数を入金・送金猶予日数テーブル５９０から抽出し、抽出レコード及び入金予定日（承認日＋猶予日数）を含むレコードを、入金・送金予定テーブル５８４に登録する（ステップＳ３２３）。出金処理（引落処理とも呼ぶ）では、抽出レコードに含まれる引落番号で支払人テーブル５７７を検索して、引落番号に対応する口座番号を抽出し、当該口座番号から抽出レコードに含まれる金額を出金する。

図６４に、入金・送金予定テーブル５８４のデータ構造例を示す。図６４の例では、出金が行われた案件毎に、引落番号を含む引落済データに対応して、入金予定日、受取人情報（入金先口座情報及び受取人名）及び金額が登録されるようになっている。

そして、出金処理部５８５は、未処理のレコードが存在するか判断し（ステップＳ３２５）、未処理のレコードが存在する場合にはステップＳ３２１に戻り、未処理のレコードが存在しない場合には、処理を終了する。

以上のような処理を実施することによって、入金・送金のスケジューリングが完了する。すなわち、受取人側の格付に応じて、入金予定日が設定されたレコードが入金・送金予定テーブル５８４に生成される。

上で述べたように、支払人テーブル５７７において引落番号に対応して登録される引落条件の可否情報に、「無条件引落許可」が登録されている場合がある。従って、例えば各営業日に、無条件引落許可が引落条件として設定されている引落番号を特定すると共に、当該引落番号が登録されている依頼内容データを特定して、自動承認処理を実施する。

具体的には、まず、銀行システム７の承認処理部５７８は、無条件引落許可が引落条件として登録されている引落番号を支払人テーブル５７７において特定し、当該引落番号から無条件引落許可に該当する依頼内容データを引落テーブル５７５から抽出する（図６５：ステップＳ３３１）。そして、抽出された依頼内容データについて、自動承認処理を実施する（ステップＳ３３３）。具体的には、図５６のステップＳ２７５、Ｓ２７７及びＳ２８７を実施する。

このような処理を実施すれば、自動承認の場合にも適切に承認テーブル５７９に登録されて、適切に送金を行うことができるようになる。

なお、銀行システム７の承認処理部５７８等は、引落テーブル５７５を検索して結果が登録されておらず、分納でない依頼内容データを特定し、当該依頼内容データに含まれる請求終了日を経過しているか判断する。経過している場合には「拒否」と判断し、自動拒否処理として、図５７のステップＳ２９９、Ｓ３０１及びＳ３０７を実施する。これによって、未承認で請求期間を経過しても放置された振込依頼についても放置することなく処理できるようになる。

次に、入金・送金についての処理について図６６を用いて説明する。入金・送金処理部５８５は、入金予定日が処理日（現在日）となっているレコードを入金・送金予定テーブル５８４から抽出する（ステップＳ３４１）。そして、未処理の抽出レコードを１つ特定する（ステップＳ３４３）。当該抽出レコードに含まれる受取人情報を、取引停止リスト５８８と照合する（ステップＳ３４５）。取引停止リスト５８８には、以下で示す処理において又は管理人によって取引停止と判断された受取人（すなわち販売店など）の情報が登録されており、例えば図６７に示すようなデータである。すなわち、取引停止受取人名と、決済口座番号の情報（振込番号を含むようにしても良い）とが対応して登録されている。

照合の結果、取引停止リスト５８８に抽出レコードの受取人情報と一致する情報が登録されているか判断し（ステップＳ３４７）、一致した情報が登録されている場合にはステップＳ３５１に移行する。一方、取引停止リスト５８８に抽出レコードの受取人情報と一致する情報が登録されていない場合には、入金・送金処理部８５は、抽出レコードに従って周知の入金・送金処理を実施する（ステップＳ３４９）。図６１及び図６２に模式的に示したように、受取人情報に含まれる口座に、承認金額の入金又は送金（為替）を行う。

そして、入金・送金処理部５８５は、全ての抽出レコードについて処理したか判断し（ステップＳ３５１）、未処理の抽出レコードが存在していればステップＳ３４３に戻る。一方、全ての抽出レコードについて処理した場合には、処理を終了する。

次に、取引停止リスト５８８に関係する取引停止処理について図６８及び図６９を用いて説明する。この処理は、取引停止となった受取人への入金又は送金を停止することによって、問題を未然に防止するための処理である。

まず、取引停止処理部５８６は、取引停止リスト５８８において新規取引停止受取人を特定する（ステップＳ３６１）。図３５の処理でも振込依頼又は分納徴収依頼を受信したした場合に、送信元の格付が取引停止格付でないかどうかを確認しているので、ここでは新規の取引停止受取人に限定している。新規か否かについては、例えば図６７に示すようなデータに加え、取引停止リスト５８８に加えた日時を登録することによって、前回処理実施日時より後に登録された受取人を特定できる。

そして、取引停止処理部５８６は、受取人テーブル５７６から、新規取引停止受取人の振込番号を全て特定する（ステップＳ３６３）。そして、引落テーブル５７５から、結果データが登録されておらず且つ特定された振込番号を含む依頼内容データを全て取引停止テーブル５８７に移動させる（ステップＳ３６５）。

さらに、取引停止処理部５８６は、受取人テーブル５７６から、新規取引停止受取人の決済口座を全て特定する（ステップＳ３６７）。そして、入金・送金予定テーブル５８４から、入金予定日が処理日（現在日）以降であって且つ特定された決済口座を含むデータを全て取引停止テーブル５８７に移動させる（ステップＳ３６９）。

取引停止テーブル５８７には、例えば図６９に示すようなデータが登録される。すなわち、引落テーブル５７５からのデータとして、上で述べた条件を満たす依頼内容データが登録され、入金・送金予定テーブル５８４からのデータとして、上で述べた条件を満たすデータが登録される。

このように取引停止になると、ステップＳ２１９で抽出されないのでユーザ２００等が承認を行ったり、ステップＳ３４１で抽出されないので入金・送金処理部５８５が入金・送金を行ったりできないようになる。すなわち、問題を発生させるおそれのある入金・送金を未然に防止できる。なお、取引停止テーブル５８７において入金・送金予定テーブル５８４から移動させたデータについての資金は、法的な手続きの中でユーザ２００等に返金する。

次に、受取人（販売店等）の格付処理について図７０乃至図７２を用いて説明する。格付は、入金・送金の猶予日数や取引停止を決定するために用いられる。

まず、格付処理部５８１は、受取人テーブル５７６において未処理の受取人を１人特定する（ステップＳ３７１）。また、受取人テーブル５７６において、特定された受取人の振込番号を全て特定する（ステップＳ３７３）。そして、振込テーブル５７４から、特定振込番号を含み且つ結果データにおける承認日が一定期間内（例えば直近１ヶ月など）である依頼番号をカウントすると共に、該当依頼番号について承認結果が「拒否」である依頼番号を抽出して、例えばメインメモリなどの記憶装置に格納する（ステップＳ３７５）。

さらに、格付処理部５８１は、未処理の抽出依頼番号を特定する（ステップＳ３７７）。そして、承認拒否テーブル５８０から、特定された抽出依頼番号に該当するレコードに含まれる拒否事由を特定し、該当拒否事由についてのカウンタの値を１インクリメントする（ステップＳ３７９）。上で述べた例では、拒否事由は、「購入実績無し」「金額相違」「購入品相違」「支払先相違」のいずれかであるので、それぞれについてカウンタを用意して、該当するカウンタの値を１インクリメントする。

そして、格付処理部５８１は、全ての抽出依頼番号について処理したか判断し（ステップＳ３８１）、未処理の抽出依頼番号が存在する場合にはステップＳ３７７に戻る。一方、全ての抽出依頼番号について処理した場合には、各拒否事由の事由点とカウント値の乗算結果を加算し、依頼番号の総件数で除することによって、トラブル指数を算出する（ステップＳ３８３）。例えば、格付処理用データ格納部５８２には、図７１に示すようなデータが登録されており、このデータから事由点を特定する。すなわち、各拒否事由について、事由点が設定されている。従って、「購入実績無し」の件数×ｒ１＋「金額相違」の件数×ｒ２＋「購入品相違」×ｒ３＋「支払先相違」×ｒ４を算出して、さらに依頼番号の総件数Ｄで除することによってトラブル指数が算出される。トラブル指数は、例えばメインメモリなどの記憶装置に格納される。処理は端子Ｊを介して図７２の処理に移行する。

そして、格付処理部５８１は、格付処理用データ格納部５８２に格納されているテーブル（図７３）から、トラブル指数に対応する格付を特定し（ステップＳ３８５）、受取人テーブル５７６に登録する（ステップＳ３８７）。例えば、図７３に示すような格付用のテーブルを用いる。図７３の例では、格付ＡからＺまで、そのトラブル指数の範囲が規定されている。範囲については、金融機関毎に設定可能である。なお、この例では格付Ｚが取引停止と規定されているが、他の格付でも取引停止にしてもよい。

そして、格付処理部５８１は、特定された格付が取引停止の格付であるか判断し（ステップＳ３８９）、該当する場合には、取引停止リスト５８８に登録する（ステップＳ３９１）。一方、該当しない場合にはステップＳ３９３に移行する。

その後、格付処理部５８１は、全ての受取人について処理したか判断する（ステップＳ３９３）。未処理の受取人が存在する場合には端子Ｋを介して図７０のステップＳ３７１に戻る。一方、全ての受取人について処理した場合には、処理を終了する。

以上述べたような処理を実施することによって、優良な販売店については入金が早く行われ資金効率が向上し、問題のある販売店については入金に猶予が与えられ、問題（あっ問えば倒産や犯罪）の発生を未然に防止することができるようになる。なお、格付は変更されたり、取引停止になったりした場合には、受取人に通知する。

このようにすれば、分納徴収依頼についても振込依頼についても取り扱うことができ、販売店１００や自治体６００、ユーザ２００や支払人７００の手間を削減することができるようになる。

なお、第２の実施の形態において、振込テーブル５７４及び引落テーブル５７５において、請求開始日及び請求終了日の設定を行っているが、例えば請求開始日だけを設定して、請求終了日については、請求開始日からの期間を設定したり、デフォルトの納付期間から得られる請求終了日を設定するようにしても良い。

さらに、第２の実施の形態において、分納の場合支払金額を変更できるような態様を示したが、変更できないようにすることも可能である。その場合、表示画面については図４７は不要となる。

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

さらに、上では述べていないが、銀行システム７には、支払人データや受取人データを後から修正したり、振込依頼を後から修正したりする機能も設けられる。

また、販売店という文言を用いたが、個人であっても良い。すなわち、個人のオークションでも利用可能である。

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

本発明の第１の実施の形態に係るサービスの第１段階を示す模式図である。 本発明の第１の実施の形態に係るサービスの第２段階を示す模式図である。 本発明の第１の実施の形態に係るサービスの第３段階を示す模式図である。 本発明の第１の実施の形態におけるシステム概要を示す図である。 銀行システムの機能ブロック図を示す図である。 ユーザからの利用申請を処理する際の処理フローを示す図である。 支払人テーブルのデータ構造を示す図である。 支払人テーブルの詳細データ構造を示す図である。 販売店からの利用申請を処理する際の処理フローを示す図である。 受取人テーブルのデータ構造を示す図である。 受取人テーブルの詳細データ構造を示す図である。 ユーザが販売店から商品等を購入する場合の処理の処理フローを示す図である。 振込依頼を受信した際の銀行システムにおける処理の処理フローを示す図である。 振込テーブルのデータ構造を示す図である。 振込テーブルの詳細データ構造を示す図である。 引落テーブルのデータ構造を示す図である。 引落テーブルの詳細データ構造を示す図である。 引落承認処理の処理フロー（第１部分）を示す図である。 ＡＴＭの表示画面例を示す図である。 ＡＴＭの表示画面例を示す図である。 ＡＴＭの表示画面例を示す図である。 引落承認処理の処理フロー（第２部分）を示す図である。 引落承認テーブルのデータ構造を示す図である。 引落承認拒否テーブルのデータ構造を示す図である。 決済処理の処理フローを示す図である。 振込処理の概要を示す図である。 引落処理の概要を示す図である。 無条件引落許可が引落条件に設定されている場合の処理を示す図である。 集計処理の処理フローを示す図である。 本発明の第２の実施の形態に係るサービスの第１段階を示す模式図である。 本発明の第２の実施の形態に係るサービスの第２段階を示す模式図である。 本発明の第２の実施の形態における銀行システムの機能ブロック図である。 第２の実施の形態における支払人テーブルの詳細データ構造を示す図である。 第２の実施の形態における受取人テーブルの詳細データ構造を示す図である。 振込依頼又は分納徴収依頼を受信した際の銀行システムにおける処理の処理フローを示す図である。 振込テーブルのデータ構造を示す図である。 振込テーブルの詳細データ構造を示す図である。 振込依頼を受信した場合に振込テーブルに登録されるデータの一例を示す図である。 振込テーブルにおける分納に係る依頼内容データの第１の例を示す図である。 引落テーブルにおける分納に係る依頼内容データの第１の例を示す図である。 引落テーブルのデータ構造を示す図である。 引落テーブルの詳細データ構造を示す図である。 承認処理の処理フロー（第１部分）を示す図である。 ＡＴＭの表示画面例を示す図である。 ＡＴＭの表示画面例を示す図である。 引落承認処理の処理フロー（第２部分）を示す図である。 ＡＴＭの表示画面例を示す図である。 承認テーブルのデータ構造を示す図である。 承認処理の処理フロー（第３部分）を示す図である。 振込テーブルにおける分納に係る依頼内容データの第２の例を示す図である。 引落テーブルにおける分納に係る依頼内容データの第２の例を示す図である。 振込テーブルにおける分納に係る依頼内容データの第３の例を示す図である。 引落テーブルにおける分納に係る依頼内容データの第３の例を示す図である。 振込テーブルにおける分納に係る依頼内容データの第４の例を示す図である。 引落テーブルにおける分納に係る依頼内容データの第４の例を示す図である。 振込テーブルにおける分納に係る依頼内容データの第５の例を示す図である。 引落テーブルにおける分納に係る依頼内容データの第５の例を示す図である。 振込テーブルにおける分納に係る依頼内容データの第６の例を示す図である。 引落テーブルにおける分納に係る依頼内容データの第６の例を示す図である。 入金・送金猶予日数テーブルのデータ例を示す図である。 承認処理の処理フロー（第４部分）を示す図である。 承認処理の処理フロー（第５部分）を示す図である。 ＡＴＭの表示画面例を示す図 承認拒否テーブルのデータ構造を表す図である。である。 分納監視処理の処理フローを示す図である。 第２の実施の形態における自行内振替処理の概念図である。 第２の実施の形態における他行振込処理の概念図である。 出金処理の処理フローを示す図である。 入金・送金予定テーブルのデータ構造の一例を示す図である。 自動承認を行う際の処理の処理フローを示す図である。 入金・送金処理の処理フローを示す図である。 取引停止テーブルのデータ構造を示す図である。 取引停止処理の処理フローを示す図である。 取引停止テーブルのデータ構造を示す図である。 格付処理の処理フロー（第１部分）を示す図である。 拒否事由と事由点の関係を表すテーブルの一例を示す図である。 格付処理の処理フロー（第２部分）を示す図である。 格付テーブルを示す図である。 コンピュータの機能ブロック図である。

符号の説明

１ ネットワーク ３ 販売店サーバ
５ ユーザ端末 ７ 銀行システム
９ａ，９ｂ，９ｃ ＡＴＭ
７１ 振込依頼受付部 ７２ 販売店登録部
７３ ユーザ登録部 ７４ 振込テーブル
７５ 引落テーブル ７６ 受取人テーブル
７７ 支払人テーブル ７８ 承認処理部
７９ 引落承認テーブル ８０ 引落承認拒否テーブル
８１ 集計処理部 ８２ 集計データ格納部
８３ 決済処理部 ８４ 引落処理部
８５ 振込処理部
５７１ 振込依頼受付部 ５７２ 販売店登録部
５７３ ユーザ登録部 ５７４ 振込テーブル
５７５ 引落テーブル ５７６ 受取人テーブル
５７７ 支払人テーブル ５７８ 承認処理部
５７９ 承認テーブル ５８０ 承認拒否テーブル
５８１ 格付処理部 ５８２ 格付処理用データ格納部
５８３ 出金処理部 ５８４ 入金・送金予定テーブル
５８５ 入金・送金処理部 ５８６ 取引停止処理部
５８７ 取引停止テーブル ５８８ 取引停止リスト
５８９ 分納監視処理部 ５９０ 入金・送金猶予日数テーブル

Claims (9)

1. 処理部を有するコンピュータ・システムにより実行される分納処理方法であって、
   前記処理部により、第１のユーザからの利用請求に応じて、前記第１のユーザの決済用口座の口座番号に対応して１又は複数の振込番号を発行し、受取人テーブルに登録するステップと、
   前記処理部により、第２のユーザからの利用請求に応じて、前記第２のユーザの決済用口座の口座番号に対応して１又は複数の引落番号を発行し、支払人テーブルに登録するステップと、
   前記処理部により、前記第２のユーザから前記第１のユーザへ通知された特定の引落番号と、前記第１のユーザの特定の振込番号と、１回分の請求金額と、総請求金額と、請求対象に関するデータとを含む分納徴収依頼に応じて、依頼番号を発行し、前記特定の引落番号及び前記依頼番号に対応して前記特定の振込番号と前記１回分の請求金額と前記総請求額とを含む第１の引落依頼内容データを引落テーブルに登録し、前記特定の振込番号及び前記依頼番号に対応して前記特定の引落番号と前記１回分の請求金額と前記総請求金額と前記請求対象に関するデータとを含む第１の振込依頼内容データを振込テーブルに登録する分割徴収依頼登録ステップと、
   前記第２のユーザによって前記決済用口座の口座番号及び引落番号が指定された場合又は前記第２のユーザによって前記決済用口座の口座番号が指定され且つ前記支払人テーブルから前記決済用口座の口座番号に対応する引落番号が特定された場合、前記処理部により、前記引落テーブルから、指定又は特定された前記引落番号に対応する未承認の前記引落依頼内容データを抽出し、前記引落依頼内容データについての承認確認リストを生成して出力するステップと、
   前記処理部により、前記承認確認リストから選択された引落依頼内容データを特定する、前記第２のユーザからの詳細表示要求に応じて、前記振込テーブルから、当該選択された引落依頼内容データに係る振込番号及び当該選択された引落依頼内容データの依頼番号に対応する前記１回分の請求金額と前記請求対象に関するデータとを抽出し、抽出されたデータを含む、前記第２のユーザに提示するための承認確認データを生成して出力するステップと、
   前記処理部により、前記承認確認データに対する、前記第２のユーザからの承認指示に応じて、前記承認確認データに係る前記依頼番号及び当該依頼番号に係る前記振込番号に対応して前記振込テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号及び指定又は特定された前記引落番号に対応して前記引落テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号を含む、送金のためのデータを承認テーブルに格納する承認ステップと、
   前記処理部により、前記承認確認データに対する、前記第２のユーザからの承認指示に応じて、前記承認確認データに係る前記依頼番号に関連付けられた第２の依頼番号を発行し、前記承認確認データに係る前記依頼番号に対応する前記第１の引落依頼内容データにおける前記総請求金額を当該総請求金額と承認された金額との差に置き換えた第２の引落依頼内容データを、前記承認確認データに係る前記引落番号及び前記第２の依頼番号に対応して前記引落テーブルに登録し、前記承認確認データに係る前記依頼番号に対応する前記第１の振込依頼内容データにおける前記総請求金額を当該総請求金額と前記承認された金額との差に置き換えた第２の振込依頼内容データを、前記承認確認データに係る前記振込番号及び前記第２の依頼番号に対応して前記振込テーブルに登録する自動データ生成ステップと、
   を含む分納処理方法。
2. 前記第２のユーザからの承認指示に、前記１回分の請求金額とは異なる金額が、前記第２のユーザによって承認された金額として含まれる場合、
   前記振込テーブルに登録される前記承認結果に前記承認された金額が含まれ、
   前記引落テーブルに登録される前記承認結果に前記承認された金額が含まれ、
   前記送金のためのデータに前記承認された金額が含まれる
   請求項１記載の分納処理方法。
3. 前記第１の引落依頼内容データ及び前記第１の振込依頼内容データが、請求期間を定めるためのデータを含み、
   前記処理部により、前記振込テーブル又は前記引落テーブルにおいて前記請求期間経過後においても未承認の前記第１の振込依頼内容データ又は前記第１の引落依頼内容データを探索し、未承認の前記第１の振込依頼内容データ又は前記第１の引落依頼内容データが存在する場合には、当該第１の振込依頼内容データ又は当該第１の引落依頼内容データに係る前記依頼番号に関連付けられた第３の依頼番号を発行し、当該第１の引落依頼内容データにおける前記請求期間を定めるためのデータを次の請求期間を定めるためのデータに変更した第３の引落依頼内容データを、当該第１の引落依頼内容データに係る前記引落番号及び前記第３の依頼番号に対応して前記引落テーブルに登録し、当該第１の振込依頼内容データにおける前記請求期間を定めるためのデータを前記次の請求期間を定めるためのデータに変更した第３の振込依頼内容データを、当該第１の振込依頼内容データに係る前記振込番号及び前記第３の依頼番号に対応して前記振込テーブルに登録する第２自動データ生成ステップ、
   をさらに含む請求項１記載の分納処理方法。
4. 前記受取人テーブルにおいて、前記第１のユーザの決済用口座の口座番号に対応して当該第１のユーザの格付が登録されており、
   前記処理部により、前記承認テーブルに登録された前記送金のためのデータに含まれる前記依頼番号に対応する前記引落番号から前記支払人テーブルにおいて特定される前記第２のユーザの決済用口座から、前記承認された金額を出金するステップと、
   前記処理部により、前記承認テーブルに登録された前記送金のためのデータに含まれる前記依頼番号に対応する前記振込番号から前記受取人テーブルにおいて特定される前記第１のユーザの格付を特定し、格付と入金猶予日数との対応関係を保持する猶予日数テーブルから前記第１のユーザの格付に対応する入金猶予日数を特定し、前記送金のためのデータに含まれる前記依頼番号に対応する前記振込番号又は前記送金のためのデータに含まれる前記依頼番号に対応する前記振込番号から前記受取人テーブルにおいて特定される前記第１のユーザの決済用口座の口座番号と、特定された前記入金猶予日数と承認日とから得られる入金予定日と含む入金・送金予定データを入金・送金予定テーブルに登録するステップと、
   前記処理部により、前記入金・送金予定テーブルから、現在日が前記入金予定日であるデータを抽出し、当該データに従って前記第１のユーザの決済用口座に入金又は送金するステップと、
   をさらに含む請求項１記載の分納処理方法。
5. 前記処理部により、取引停止となったユーザを特定する情報を格納する取引停止リストに登録されたユーザに係る振込番号又は前記決済用口座の口座番号を前記支払人テーブルから抽出するステップと、
   前記処理部により、抽出された振込番号又は前記決済用口座の口座番号を含む前記入金・送金予定データを、前記入金・送金予定テーブルから、取引停止データ格納部に移動させるステップと、
   前記処理部により、抽出された振込番号を含む未承認の前記引落依頼内容データを、前記引落テーブルから、前記取引停止データ格納部に移動させるステップと、
   をさらに含む請求項４記載の分納処理方法。
6. 処理部を有するコンピュータ・システムにより実行される決済処理方法であって、
   前記処理部により、第１のユーザからの利用請求に応じて、前記第１のユーザの決済用口座の口座番号に対応して１又は複数の振込番号を発行し、受取人テーブルに登録するステップと、
   前記処理部により、第２のユーザからの利用請求に応じて、前記第２のユーザの決済用口座の口座番号に対応して１又は複数の引落番号を発行し、支払人テーブルに登録するステップと、
   前記処理部により、前記第２のユーザの名称と、前記第２のユーザが前記第１のユーザに対して購入対象の購入申込を行ったことによって前記第２のユーザから前記第１のユーザへ通知される特定の引落番号と、前記第１のユーザの特定の振込番号と、金額と、前記購入対象に関するデータとを含む振込依頼に応じて、依頼番号を発行し、前記特定の引落番号及び前記依頼番号に対応して前記第２のユーザの名称と前記特定の振込番号と前記金額とを引落テーブルに登録し、前記特定の振込番号及び前記依頼番号に対応して前記特定の引落番号と前記金額と前記購入対象に関するデータとを振込テーブルに登録する振込依頼登録ステップと、
   前記第２のユーザによって前記決済用口座の口座番号及び引落番号が指定された場合又は前記第２のユーザによって前記決済用口座の口座番号が指定され且つ前記支払人テーブルから前記決済用口座の口座番号に対応する引落番号が特定された場合、前記処理部により、前記引落テーブルから、指定又は特定された前記引落番号に対応する未承認の前記振込依頼に係るデータを抽出し、前記振込依頼についての承認確認リストを生成して出力するステップと、
   前記処理部により、前記承認確認リストから選択された振込依頼を特定する、前記第２のユーザからの詳細表示要求に応じて、前記振込テーブルから、当該選択された振込依頼に係る振込番号及び当該選択された振込依頼の依頼番号に対応する前記金額と前記購入対象に関するデータとを抽出し、抽出されたデータを用いて前記第２のユーザに提示するための承認確認データを生成して出力するステップと、
   前記処理部により、前記承認確認データに対する、前記第２のユーザからの承認指示に応じて、前記承認確認データに係る前記依頼番号及び当該依頼番号に係る前記振込番号に対応して前記振込テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号及び指定又は特定された前記引落番号に対応して前記引落テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号及び指定又は特定された前記引落番号を含む決済データを引落承認テーブルに格納する承認ステップと、
   前記処理部により、前記引落承認テーブルに登録されている未決済の前記決済データについて、前記引落テーブルから前記決済データに含まれる前記依頼番号及び前記引落番号に対応する前記振込番号及び前記金額を特定し、前記支払人テーブルから前記引落番号に対応する決済用口座の口座番号を特定し、前記受取人テーブルから前記振込番号に対応する決済用口座の口座番号とを特定し、特定された前記金額について前記引落番号に対応する決済用口座から前記振込番号に対応する決済用口座への送金のための処理を実施する送金ステップと、
   を含む決済処理方法。
7. 処理部を有するコンピュータ・システムにより実行される決済処理方法であって、
   前記処理部により、第１のユーザからの利用請求に応じて、前記第１のユーザの決済用口座の口座番号に対応して受取条件毎に振込番号を発行し、受取人テーブルに登録するステップと、
   前記処理部により、第２のユーザからの利用請求に応じて、前記第２のユーザの決済用口座の口座番号に対応して１又は複数の引落番号を発行し、支払人テーブルに登録するステップと、
   前記処理部により、前記第２のユーザの名称と、前記第２のユーザが前記第１のユーザに対して購入対象の購入申込を行ったことによって前記第２のユーザから前記第１のユーザへ通知される特定の引落番号と、前記第１のユーザの特定の振込番号と、金額と、前記購入対象に関するデータとを含む振込依頼に応じて、依頼番号を発行し、前記特定の引落番号及び前記依頼番号に対応して前記特定の振込番号と前記金額とを引落テーブルに登録し、前記特定の振込番号及び前記依頼番号に対応して前記第２のユーザの名称と前記特定の引落番号と前記金額と前記購入対象に関するデータとを振込テーブルに登録する振込依頼登録ステップと、
   前記第２のユーザによって前記決済用口座の口座番号及び引落番号が指定された場合又は前記第２のユーザによって前記決済用口座の口座番号が指定され且つ前記支払人テーブルから前記決済用口座の口座番号に対応する引落番号が特定された場合、前記処理部により、前記引落テーブルから、指定又は特定された前記引落番号に対応する未承認の前記振込依頼に係るデータであって、当該データに含まれる前記振込番号に対応して前記受取人テーブルに登録されている前記受取条件を満たすデータを抽出し、前記振込依頼についての承認確認リストを生成して出力するステップと、
   前記処理部により、前記承認確認リストから選択された振込依頼を特定する、前記第２のユーザからの詳細表示要求に応じて、前記振込テーブルから、当該選択された振込依頼に係る振込番号及び当該選択された振込依頼の依頼番号に対応する前記金額と前記購入対象に関するデータとを抽出し、抽出されたデータを用いて前記第２のユーザに提示するための承認確認データを生成して出力するステップと、
   前記処理部により、前記承認確認データに対する、前記第２のユーザからの承認指示に応じて、前記承認確認データに係る前記依頼番号及び当該依頼番号に係る前記振込番号に対応して前記振込テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号及び指定又は特定された前記引落番号に対応して前記引落テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号及び指定又は特定された前記引落番号を含む決済データを引落承認テーブルに格納する承認ステップと、
   前記処理部により、前記引落承認テーブルに登録されている未決済の前記決済データについて、前記引落テーブルから前記決済データに含まれる前記依頼番号及び前記引落番号に対応する前記振込番号及び前記金額を特定し、前記支払人テーブルから前記引落番号に対応する決済用口座の口座番号を特定し、前記受取人テーブルから前記振込番号に対応する決済用口座の口座番号とを特定し、特定された前記金額について前記引落番号に対応する決済用口座から前記振込番号に対応する決済用口座への送金のための処理を実施する送金ステップと、
   を含む決済処理方法。
8. 請求項１乃至５のいずれか１つ記載の分納処理方法をコンピュータに実行させるためのプログラム。
9. 第１のユーザからの利用請求に応じて、前記第１のユーザの決済用口座の口座番号に対応して１又は複数の振込番号を発行し、受取人テーブルに登録する手段と、
   第２のユーザからの利用請求に応じて、前記第２のユーザの決済用口座の口座番号に対応して１又は複数の引落番号を発行し、支払人テーブルに登録する手段と、
   前記第２のユーザから前記第１のユーザへ通知された特定の引落番号と、前記第１のユーザの特定の振込番号と、１回分の請求金額と、総請求金額と、請求対象に関するデータとを含む分納徴収依頼に応じて、依頼番号を発行し、前記特定の引落番号及び前記依頼番号に対応して前記特定の振込番号と前記１回分の請求金額と前記総請求額とを含む第１の引落依頼内容データを引落テーブルに登録し、前記特定の振込番号及び前記依頼番号に対応して前記特定の引落番号と前記１回分の請求金額と前記総請求金額と前記請求対象に関するデータとを含む第１の振込依頼内容データを振込テーブルに登録する分割徴収依頼登録手段と、
   前記第２のユーザによって前記決済用口座の口座番号及び引落番号が指定された場合又は前記第２のユーザによって前記決済用口座の口座番号が指定され且つ前記支払人テーブルから前記決済用口座の口座番号に対応する引落番号が特定された場合、前記引落テーブルから、指定又は特定された前記引落番号に対応する未承認の前記引落依頼内容データを抽出し、前記引落依頼内容データについての承認確認リストを生成して出力する手段と、
   前記承認確認リストから選択された引落依頼内容データを特定する、前記第２のユーザからの詳細表示要求に応じて、前記振込テーブルから、当該選択された引落依頼内容データに係る振込番号及び当該選択された引落依頼内容データの依頼番号に対応する前記１回分の請求金額と前記請求対象に関するデータとを抽出し、抽出されたデータを含む、前記第２のユーザに提示するための承認確認データを生成して出力する手段と、
   前記承認確認データに対する、前記第２のユーザからの承認指示に応じて、前記承認確認データに係る前記依頼番号及び当該依頼番号に係る前記振込番号に対応して前記振込テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号及び指定又は特定された前記引落番号に対応して前記引落テーブルにおいて承認結果を登録し、前記承認確認データに係る前記依頼番号を含む、送金のためのデータを承認テーブルに格納する承認手段と、
   前記承認確認データに対する、前記第２のユーザからの承認指示に応じて、前記承認確認データに係る前記依頼番号に関連付けられた第２の依頼番号を発行し、前記承認確認データに係る前記依頼番号に対応する前記第１の引落依頼内容データにおける前記総請求金額を当該総請求金額と承認された金額との差に置き換えた第２の引落依頼内容データを、前記承認確認データに係る前記引落番号及び前記第２の依頼番号に対応して前記引落テーブルに登録し、前記承認確認データに係る前記依頼番号に対応する前記第１の振込依頼内容データにおける前記総請求金額を当該総請求金額と前記承認された金額との差に置き換えた第２の振込依頼内容データを、前記承認確認データに係る前記振込番号及び前記第２の依頼番号に対応して前記振込テーブルに登録する自動データ生成手段と、
   を有する分納処理装置。

Images