JP2002041785A - 代行支払システム - Google Patents

Abstract

(57)【要約】 【課題】 大口の代行支払に好適なシステムを提供す
る。 【解決手段】 支払委託者の端末２０から、予め支払内
容を示す決済予定明細を受け取り、トランザクションＤ
Ｂ５１に登録しておく。端末２０では、登録された決済
予定明細を表示させて、代行支払の承認を与える。承認
された決済予定明細に基づきＲＴＧＳシステム６０から
日銀ネットシステム８０に対して代行支払が行なわれ
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、日本銀行が提供す
るＲＴＧＳ（即時決済）システムなどと接続して、顧客
の代行決済を行なう代行支払システムに関する。

【０００２】

【従来の技術】日本銀行では、当座預金等の即時決済
（ＲＴＧＳ）を行なうためにオンラインで決済ができる
コンピュータシステムの開発を発表し、実施を目指して
いる。これに関して民間の銀行でも、上記コンピュータ
と接続し、顧客に代わり、日銀のＲＴＧＳシステムと接
続して、代行決済を行なうＲＴＧＳ代行システムの開発
を余儀なくされている。

【０００３】

【発明が解決しようとする課題】この代行決済システム
としては、従来は代金の振込み、振替などを行うコンピ
ュータシステムが知られているが、即時決済は取り扱う
金額も大きく、そのコンピュータシステムをそのまま使
用するわけにはいかない。

【０００４】そこで、本発明の目的は、上述の点に鑑み
て、決済金額が大きい場合に適した代行支払システムを
提供することにある。

【０００５】

【課題を解決するための手段】このような目的を達成す
るために、請求項１の発明は、第１の銀行に対する支払
を代行する第２の銀行で、支払者の第１の端末から、支
払金額および第２の銀行での預金口座を示す決済予定明
細を受け付け、前記第１の銀行への支払に関連して、前
記支払者の預金口座から代行して支払った金額を引き落
とす決済代行システムにおいて、前記決済予定明細を前
記支払者の第１の端末から入力した後、該第１の端末か
ら前記決済予定明細の示す金額の前記第１の銀行に対す
る代行支払の承認を前記第１の支払者の端末から入力
し、当該入力された決済予定明細および代行支払の承認
を受け付ける通信手段と、前記支払者の預金口座の預金
情報を複数の支払者について記憶したデータベースと、
前記第１の銀行のコンピュータシステムと接続し、前記
決済予定明細に基づき代行支払に関する情報を入力する
ことにより前記第１の銀行に対する支払を行なう第２の
端末と前記第１の端末から代行支払の承認を前記通信手
段により受け付けた後、前記データベースの該当する預
金口座から代行支払金額を引き落とす情報処理手段とを
具えたことを特徴とする。

【０００６】請求項２の発明は、請求項１に記載の代行
支払システムにおいて、前記通信手段により代行支払の
承認を受け付けた後に手動または自動で前記第１の銀行
に対して前記代行支払に関する情報を前記第２の端末か
ら入力することを特徴とする。

【０００７】請求項３の発明は、請求項２に記載の代行
支払システムにおいて、前記データベースには、支払者
の預金口座には仮更新残高を記載する仮更新残高欄を有
しており、前記第１の銀行に対する代行支払の終了前ま
では、前記データベースの仮更新残高欄に代行支払金額
を引き落とした預金残高を記載することにより預金残高
を仮更新することを特徴とする。

【０００８】請求項４の発明は、請求項３に記載の代行
支払システムにおいて、前記第１の銀行に対する支払終
了後、手動または自動の指示で、前記仮更新残高欄に記
載された預金残高で、前記データベースの支払者の預金
残高記載欄の残高を更新することを特徴とする。

【０００９】請求項５の発明は、請求項３に記載の代行
支払システムにおいて、前記データベースの仮更新残高
記載欄に記載された残高を前記支払者の第１の端末で閲
覧可能であることを特徴とする。

【００１０】請求項６の発明は、請求項１に記載の代行
支払システムにおいて、前記第１の銀行に対する支払の
終了の旨を示す支払通知情報を入力する支払通知入力手
段とを具え、該支払通知入力手段から入力された支払通
知情報を前記通信手段を介して前記支払者の第１の端末
に対して通知することを特徴とする。

【００１１】請求項７の発明は、請求項１に記載の代行
支払システムにおいて、前記第２の銀行側の人間により
前記支払者から前記決済予定明細の形態で依頼された支
払についての第２の銀行側の支払承認を入力する支払承
認入力手段と、前記決済予定明細および前記第２の銀行
側の支払承認を互いに関連付けて表示する表示手段とを
さらに具えたことを特徴とする。

【００１２】請求項８の発明は、請求項１に記載の代行
支払システムにおいて、前記第１の銀行側からの支払終
了通知情報を入力する支払終了通知情報入力手段と当該
入力された支払通知情報と、前記決済予定明細の示す情
報とを同じ情報内容について照合する照合手段と、該照
合の結果、不一致の情報内容が合った場合には、その旨
を示すアンマッチ情報を前記支払者の端末に前記通信手
段を介して通知することを特徴とする。

【００１３】請求項９の発明は、請求項１に記載の代行
支払システムにおいて、前記決済予定明細の示す支払金
額について前記預金口座から引き落とし可能であるか否
の判定を行なう判定手段と、該判定の結果を出力する出
力手段をさらに具えたことを特徴とする。

【００１４】請求項１０の発明は、請求項１に記載の代
行支払システムにおいて、前記決済予定明細書の示す支
払先が前記第２の銀行に預金口座を有する場合には、前
記データベース上の前記支払者の預金口座から支払先の
預金口座に行内振替を行なうことを特徴とする。

【００１５】請求項１１の発明は、請求項１に記載の代
行支払システムにおいて、貸越に限度額を有する共有枠
が予め定められており、該共有枠の限度額以内で、複数
の支払者に対して前記支払に対する貸越が許容されるこ
とを特徴とする。

【００１６】請求項１２の発明は、請求項１に記載の代
行支払システムにおいて、前記支払者の第１の端末から
入力される決済予定明細には前記第１の銀行に対する決
済時刻の指示が含まれていることを特徴とする

【００１７】

【発明の実施の形態】以下、図面を参照して本発明の実
施形態を詳細に説明する。

【００１８】図１は本発明を適用した代行決済（支払代
行）システムを示す。図１において、１０は顧客（支払
委託者、以下、単に委託者と略記する）が独自に保有す
る社内処理システムである。

【００１９】２０は委託者側に設置されたクライアント
（以下、委託者端末２０と称す）であり、パーソナルコ
ンピューターやワークステーションなどの汎用のコンピ
ュータを使用することができる。委託者端末２０には決
済予定明細（後述）を入力したり、決済指図を指示した
り、決済状況を表示するための専用プログラムが搭載さ
れている。

【００２０】３０はフレームリレー網（以下、ＦＲ網３
０と称す）と呼ばれる通信回線網であり、複数の委託者
端末２０、後述するＤＢサーバ５０が接続される。

【００２１】４０は受託者側に設置されるクライアント
（以下、受託者端末４０と称す）であり、委託者端末２
０で装備される機能に加え、受託者が決済処理、貸越管
理等を行うための専用プログラムが搭載されている。

【００２２】５０は、決済明細管理、残高管理、貸越管
理等以下に述べる情報処理を行うためのデータベース
（ＤＢ）５１〜５４を内蔵するＤＢサーバである。

【００２３】５１〜５４は本発明のデータベースを構成
する個別データベースであり、データベース５１（以
下、トランザクションＤＢ５１と称す）は決済明細を管
理するプログラム（サーバ５０が実行）で使用する資金
情報を保存している。データベース５２（以下、残高Ｄ
Ｂ５２と称す）は委託者毎の資金（預金）残高情報、貸
越枠、仮更新残高をそれぞれの記載欄いわゆるフィール
ドに保存している。ここで、仮更新残高は、本実施形態
で初めて導入された新しい情報である。

【００２４】データベース５３（以下、共有枠ＤＢ５３
と称す）は委託者全体で使用する貸越枠（「共有枠」）
の使用状況を保存している。データベース５４（以下、
顧客ＤＢと称す）は委託者に関する会社情報、たとえ
ば、名称、住所、担当者名等を管理するため情報を保存
している。６０は受託銀行内に設置されるＲＴＧＳ決済
用システム（以下、ＲＴＧＳシステム６０と称す）であ
り、日本銀行（本発明の第１の銀行）の決済システム８
０（以下、日銀ネットシステム８０と称す、）と専用回
線７０（以下、日銀ネット専用回線７０）を介して接続
されており、資金決済情報の送受信、決済状況の管理を
行うためのプログラムが搭載されている。

【００２５】このようなシステム構成において、委託者
は委託者端末２０（本発明の第１の端末）を使用して図
２示すような表示画面に表示される決済予定入力画面１
０００で決済予定明細を入力する。その際、委託者の社
内システム１０で複数の決済予定明細をフロッピー（登
録商標）ディスクに排出して、クライアント２０に決済
予定明細を一括入力することも可能である。決済予定明
細には少なくとも、支払先の銀行およびその預金口座番
号、自己の預金口座番号、決済金額（支払金額）などが
含まれる。本実施形態では、さらに決済時刻を指示す
る。また、この画面には実際に日本銀行で再処理された
時刻が専用の表示欄に表示される。

【００２６】＜支払承認・仮残更新＞委託者が委託者端
末２０に入力した決済予定明細は、ＦＲ網３０を介して
ＤＢサーバ５０（本発明の通信手段および情報処理手段
として機能する）によりトランザクションＤＢ５１に格
納される。格納された決済予定明細は、受託者端末４０
に付属するプリンターから自動印刷される。受託銀行の
担当者は出力された明細を銀行内のＲＴＧＳシステム６
０に入力し、決済予定の管理を行う。

【００２７】支払委託者は、図２の画面で複数組の決済
予定明細を作成し、トランザクションデータベース５１
に登録することができる。また、登録された決済予定明
細（委託者の承認前）を委託者端末２０で閲覧すること
ができる。この閲覧画面を図３に示す。

【００２８】図３の画面は委託者端末２０に表示され
る、支払指図を行い、決済状況、（仮更新残高状況を表
示する画面を示す。この画面２０００では、図１の画面
で入力された決済明細複数組がリスト（表）の形態で表
示される。この画面に表示される残高情報は、委託者が
図３の「Refresh」ボタン２００２を押下することによ
り、残高ＤＢ５２で保存されている最新残高に更新され
る。また、この画面に表示される決済状況はトランザク
ションＤＢ５１で保存されている最新の状況をＤＢサー
バ５０から自動配信されて表示される。

【００２９】図３で表示される「支払可能残高」の範囲
内であれば、明細行に表示されている未決済の支払予定
をマウス等で選択して、「支払承認」ボタン２００１を
押下することにより、ＤＢサーバ５０に支払を指示する
ことができる。なお、「支払承認」ボタン２００１を押
下する人間は決済委託者側の責任者であることが望まし
い。

【００３０】本実施形態では、支払予定明細を予め銀行
側の決済代行システムに送っておき、後で、その支払予
定明細について承認を送信することで、委託者および代
行支払を行なう銀行側の大口の支払に対するセキュリテ
ィを確保する。

【００３１】このような画面を使用して支払承認が送信
された場合のサーバ５０は図６の処理を実行する。委託
者により図３の支払承認ボタン２００１が押下される
（図６のステップＳ５０１）と、残高ＤＢ５２の情報に
より該当金額の支払が可能かどうかの判定がなされる
（図６のステップＳ５０２）。判定がＹＥＳである場合
は、残高ＤＢ５２の「仮更新残高」が書き換えられ、該
当金額分だけ引き落としされる（図６のステップＳ５０
３）。仮残高引き落とし後、受託銀行端末４０に付属す
るプリンターから、該当のデータ明細のプルーフシート
（図６のステップＳ５０４）が自動出力されるので、受
託銀行の担当者はＲＴＧＳシステム（本発明の第２の端
末）６０を使用して日本銀行当座預金での資金決済を行
う。日銀ネットシステム８０での決済結果は、日銀ネッ
ト専用回線７０を介してＲＴＧＳシステム６０に還元さ
れるので、ＲＴＧＳシステム６０に表示される画面また
は、出力される帳票によってその結果を確認する（図６
のステップＳ５０５）。確認された結果に基づき受託端
末４０の画面より該当明細に対し図４の処理時刻入力ボ
タン３００１で日本銀行での決済時刻を入力し決済済み
の入力を行うことにより、トランザクションＤＢ５１が
決済済みに更新されるとともに、残高ＤＢ５２の本残が
更新される（図６のステップＳ５０６）。

【００３２】仮残高更新のステップＳ５０３と本残更新
のステップＳ５０６との間には、時間差が生じるため、
委託者は図２の残高照会・支払承認画面の「Refresh」
ボタンを押下して残高更新を行うことにより、支払承認
を行ったもののまだ日本銀行での決済が完了していない
金額、および支払予定明細が複数ある場合にあとどれだ
けの金額が支払可能であるかの判断を行うための「支払
可能残高」の把握を随時行うことが可能となる。

【００３３】＜アンマッチ入金処理の説明＞次に図７を
参照して入金処理について説明する。委託者が委託者端
末２０で行う決済予定データの送信と受託者が行うＲＴ
ＧＳシステム６０への予定データの入力までの処理は上
述した資金払いの処理フローと同様である。

【００３４】委託先への入金は、まず日銀ネットシステ
ム８０より日銀ネット専用回線７０を介して受託銀行の
ＲＴＧＳシステム６０に通知される。入金内容は受託銀
行の担当者がＲＴＧＳシステム６０の画面表示もしくは
出力帳票にて認知することができるので、その内容をも
とに、受託者端末４０にて図４の画面を表示させて該当
明細の有無を検索する（ステップＳ５１１）。トランザ
クションＤＢ５１に該当明細が存在すれば、受託者端末
４０に承認記帳を入力することにより、残高ＤＢ５２の
本残（従来の預金口座の残高、上述の仮更新残高とは別
個である点に注意）が更新される（図７のステップＳ５
１２）。

【００３５】委託者の入金予定未入力、入金予定入力相
違等の事由によりトランザクションＤＢ５１に該当（支
払金額等の明細項目の情報内容が一致）する決済予定明
細が存在しない場合には、ＲＴＧＳシステム６０に表示
された明細を、本発明のアンマッチ情報の一部として受
託者端末４０の画面４のアンマッチ処理ボタン３００２
を押下することにより入力しトランザクションＤＢ５１
に該当明細を作成する（図４のステップＳ５１３）。こ
こで作成された明細に対してはトランザクションＤＢ５
１内で自動的に「アンマッチフラグ」が付加され（図４
のステップＳ５１４）る。図３の画面のアンマッチのフ
ィールド欄の色が変わり、受託者端末にて入力された不
一致（アンマッチ）入金情報であることが判別できる。
本実施形態では、色の変化でアンマッチの通知を行な
う。

【００３６】アンマッチフラグが付された明細は、ＤＢ
サーバ５０から委託者端末２０に自動配信され、委託者
端末２０の残高照会・支払承認画面（図３参照）の明細
行に自動表示される（図７のステップＳ５１５）。その
際、図７の「Refresh」ボタン２００２の押下は不要で
あるので、委託者は画面表示の変化をみておくだけで、
自己の入金状況を容易に認知することが可能である。

【００３７】＜行内振替処理＞上述した処理は日銀ネッ
トシステム８０を使用した決済処理であるが、委託者か
ら送信される決済予定の中には、日銀ネットシステム８
０及びＲＴＧＳシステム６０を使用することなく、決済
処理を完了させることができる明細も存在する。即ち、
決済の当事者が委託者と受託銀行自身である場合、及び
同一の受託銀行に決済口座を有する委託者同士である場
合である（このような場合を以下、「行内振替」と称す
る）。

【００３８】行内振替に該当する処理を図８を用いて説
明する。

【００３９】委託者が委託者端末２０より決済予定を入
力し、ＦＲ網３０を介してトランザクションＤＢ５１に
明細が書き込まれる際、決済明細判定プログラムによ
り、予定明細の決済相手口座情報を識別して「行内振
替」対象の明細に対しては、「行内振替フラグ」を付加
する（図８のステップＳ５２１）。

【００４０】資金を支払う側の委託者が、委託者端末２
０の「支払承認・残高照会」画面（図２）にて、支払承
認記帳を行い、仮残更新が行われる際（前述、図６のス
テップＳ５０３）に、行内振替処理プログラム（ＤＢサ
ーバ５０が実行）により、トランザクションＤＢ５１に
保存されている入金側の決済予定明細の有無を検索（図
８のステップＳ５２２）し、該当の入金明細が存在すれ
ば、該当する入金側の決済予定明細に「入金確定」のフ
ラグを付与する（図８のステップＳ５２３）。

【００４１】なお、入金確定フラグが付された明細は、
ＤＢサーバ５０から入金側の委託者クライアント２０の
「残高照会・支払承認」画面に自動通知される。これに
より入金側の委託者は、当該入金が確実に履行されるこ
とを容易に認識できる。

【００４２】ステップＳ５２２の自動検索にて、該当の
入金明細がトランザクションＤＢ５１に存在しない場合
は、行内振替処理プログラムにより、支払承認された出
金明細をもとに入金明細がトランザクションＤＢ５１に
自動作成され（図８のステップＳ５２６）、入金確定フ
ラグが付されるとともに、ＤＢサーバ５０から入金側の
委託者クライアント２０の「残高照会・支払承認」画面
に自動通知される。

【００４３】受託銀行の担当者が、決済予定明細にて受
領した「決済予定時刻」に受託者端末４０の行内振替処
理画面（図６）で「振替処理」ボタンを押下することに
より（図８のステップＳ５２４）、該当する入金、出金
それぞれの明細が決済済みとなり、本残が更新される。
なお、同一の決済予定時刻に複数の決済予定明細が存在
する場合には、１回の振替処理により該当するすべての
明細が同時に決済済みとなるため、事務の効率化を図る
ことが可能となる。

【００４４】上述の実施形態に加え、次の形態を実施で
きる。

【００４５】（第１の他の形態） ＜共有枠管理＞資金支払の場合、図６のステップＳ５０
２で委託者の支払可能残高により、支払の可否が判定さ
れるが、その判定の際に受託銀行により「貸越」を許容
する場合がある。

【００４６】残高ＤＢ５２には、有担保、無担保での貸
越枠が受託者により設定される。貸越枠のうち、無担保
での貸越枠は、委託者全体で使用する枠として共有枠Ｄ
Ｂ５３で保存される「共有枠」の範囲内で運営されるも
のである。委託者毎の貸越枠と共有枠との関係を図９に
示す。委託者毎の貸越枠の使用状況及び全体での共有枠
の使用状況は、受託銀行クライアント４０で提供される
「残高照会・支払承認画面（受託者）」（図３参照）の
「Refresh」ボタン２００２を押下することにより、リ
アルタイムでの管理が可能になる。

【００４７】その処理要領を図９を用いて次に示す。

【００４８】委託者が委託者端末２０の「残高照会・支
払承認」画面より「支払承認」ボタン２００１を押下す
るとＤＢサーバ５０の残高ＤＢ５２の支払可能残高のう
ち、支払判定プログラムによりまず資金部分の残高がチ
ェックされる（図１０のステップＳ５３１）。資金残高
の判定がＮＯの場合残高ＤＢ５２の貸越枠の設定がある
委託者の場合は、残高ＤＢ５２の貸越枠の使用状況がチ
ェックされる（図１０のステップＳ５３２）。その際、
無担保貸越枠を使用する場合には、「共有枠」の使用状
況が合わせてチェックされる（図１０のステップＳ５３
３）。無担保貸越枠及び共有枠に余裕があれば（図１０
のステップＳ５３３で「余裕あり」の判定）、残高ＤＢ
５２の無担保貸越枠の仮残及び共有枠ＤＢ５３の共有枠
の使用残高がそれぞれ更新される。

【００４９】＜第２の他の形態＞本実施形態では、銀行
側のセキュリティを向上させるためにさらに、委託者側
から委託された決済予定明細で委託者の承認が行なわれ
た案件については銀行側の責任者が承認を与える。この
ための画面を図５に示す。責任者は、受託者端末４０か
ら図画面を呼び出す。図５の画面で検索条件を入力し
て、代行決済を承認すべき決済予定明細をトランザクシ
ョンＤＢ５１から取り出して受託端末４０に表示させ
る。表示された決済予定明細（図５では不図示）の中の
所望の明細をマウス等で選択した後、承認ボタン４００
１を操作する。この操作に応じて、トランザクションＤ
Ｂ５１上の決済予定明細に関連付けるためにこの明細内
の承認欄に承認の旨の情報がＤＢサーバ５０により書き
込まれる。また、銀行側では、トランザクションＤＢ５
１の決済予定明細を表示させるときにこの承認の有無を
表示させる。なお、委託者端末２０に対して銀行側の責
任者の承認の有無を表示させてもよいし、表示させない
ようにしてもよい。

【００５０】このようにして銀行側でも日銀システムへ
の代行決済について責任者が承認を与えることで、代行
支払に関するセキュリティを高めることができる。

【００５１】以上述べた実施形態の他に、さらに次の形
態を実施できる。 １）図１のフレームリレー網３０に変わり、周知の通信
ネットワークを使用することができる。 ２）上述の実施形態では、受託者端末４０とＲＴＧＳシ
ステムとの間はオフラインで情報転送を行なっている
が、オンラインで接続して情報転送を行なってもよい。
さらに上述のアンマッチの有無のための照合を、受託者
端末４０またはＤＢサーバ５０のいずれかで行なって、
アンマッチを委託者端末２０に通知してもよいこと勿論
である。

【００５２】

【発明の効果】以上、説明したように、請求項１の発明
によれば、予め代行支払に関する明細を支払者から受け
取っておき、その後、支払者の承認を受けることによ
り、情報入力の誤りや、不正行為を未然に阻止すること
ができる。また、決済予定明細と受付時点と承認受け取
り時点の間には時間差ができるので、その間に銀行側で
は、残高確認を行なうことができる。

【００５３】請求項２の発明によれば、支払者の承認を
得た後、第１の銀行に支払を行なうので、決済に関する
セキュリティが保たれる。

【００５４】請求項３の発明によれば、仮更新残高情報
をデータベースに設けることで、支払者が、決済予定明
細を入力した後、第１の銀行に支払を行なう前でも、支
払者は残りの預金算高を知ることができる。

【００５５】請求項４の発明によれば、第１の銀行に対
する支払が終了した後、支払者の預金残高が正式に更新
されるので、第１の銀行に対する支払にトラブルが生じ
た場合に、支払者の預金残高が影響を受けることはな
い。

【００５６】請求項５の発明によれば、支払者側の端末
で、仮更新残高が閲覧できるので、支払者が入力した決
済予定明細がただしく処理されているか、および、後ど
れくらい預金残高が残っているかを確認することができ
る。

【００５７】請求項６の発明によれば、支払の完了を同
じ支払者の（第１）の端末に通知するるので、郵便、Ｆ
ＡＸ等よりも情報伝達を早くすることができる。

【００５８】請求項７の発明によれば、銀行側で代行支
払に関する承認を与えることで、代行支払に関するセキ
ュリティ性が高まる。

【００５９】請求項８の発明によれば、第１の銀行への
支払と支払者からの代行支払の依頼との間の情報転送に
関する誤りを検出することができるので、代行支払に関
する信頼性を高めることができる。

【００６０】請求項９の発明によれば、支払者の残高不
足を検知して、出力することにより、残高不足状態での
代行支払が行なわれることはない。

【００６１】請求項１０の発明によれば、同一銀行内で
の決済に関しても請求項１の発明を利用することができ
る。

【００６２】請求項１１の発明によれば、複数の支払者
に対して限度はあるものの、貸越を行なうことができ
る。

【００６３】請求項１２の発明によれば、支払者は事前
に決予定明細を入力しても第２の銀行側に決済時刻の指
定を行うことができる。

【図面の簡単な説明】

【図１】本発明実施形態のシステム構成を示すブロック
図である。

【図２】委託者側の端末での決済予定明細の入力用画面
を示す説明図である。

【図３】委託者側の端末での残高照会、支払承認のため
の表示画面を示す説明図である。

【図４】受託者端末での表示画面の内容を示す説明図で
ある。

【図５】受託者端末での承認用画面の内容を示す説明図
である。

【図６】支払承認処理手順を示すフローチャートであ
る。

【図７】入金処理手順を示すフローチャートである。

【図８】行内振替処理手順を示すフローチャートであ
る。

【図９】貸越枠を説明するための説明図である。

【図１０】共有枠を説明するための説明図である。

【符号の説明】

１０：委託者側社内システム ２０：委託者端末 ３０：フレームリレー網 ４０：受託者端末 ５０：ＤＢサーバ ６０：ＲＴＧＳシステム ７０：日銀ネット専用回線 ８０：日銀ネットシステム ５１：トランザクションＤＢ ５２：残高ＤＢ ５３：共有枠ＤＢ ５４：顧客ＤＢ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 田中 隆寛 東京都千代田区九段南１丁目３番１号 株 式会社さくら銀行内 (72)発明者 川上 洋 東京都千代田区九段南１丁目３番１号 株 式会社さくら銀行内 (72)発明者 林 茂 東京都千代田区丸の内１丁目３番２号 株 式会社住友銀行東京本部ビル内 Ｆターム(参考） 5B055 BB11 CB09 CB15 EE02 EE05

Claims (12)

【特許請求の範囲】
1. 【請求項１】 第１の銀行に対する支払を代行する第２
   の銀行で、支払者の第１の端末から、支払金額および第
   ２の銀行での預金口座を示す決済予定明細を受け付け、
   前記第１の銀行への支払に関連して、前記支払者の預金
   口座から代行して支払った金額を引き落とす決済代行シ
   ステムにおいて、 前記決済予定明細を前記支払者の第１の端末から入力し
   た後、該第１の端末から前記決済予定明細の示す金額の
   前記第１の銀行に対する代行支払の承認を前記第１の支
   払者の端末から入力し、当該入力された決済予定明細お
   よび代行支払の承認を受け付ける通信手段と、 前記支払者の預金口座の預金情報を複数の支払者につい
   て記憶したデータベースと、 前記第１の銀行のコンピュータシステムと接続し、前記
   決済予定明細に基づき代行支払に関する情報を入力する
   ことにより前記第１の銀行に対する支払を行なう第２の
   端末と前記第１の端末から代行支払の承認を前記通信手
   段により受け付けた後、前記データベースの該当する預
   金口座から代行支払金額を引き落とす情報処理手段とを
   具えたことを特徴とする代行支払システム。
2. 【請求項２】 請求項１に記載の代行支払システムにお
   いて、前記通信手段により代行支払の承認を受け付けた
   後に手動または自動で前記第１の銀行に対して前記代行
   支払に関する情報を前記第２の端末から入力することを
   特徴とする代行支払システム。
3. 【請求項３】 請求項２に記載の代行支払システムにお
   いて、前記データベースには、支払者の預金口座には仮
   更新残高を記載する仮更新残高欄を有しており、前記第
   １の銀行に対する代行支払の終了前までは、前記データ
   ベースの仮更新残高欄に代行支払金額を引き落とした預
   金残高を記載することにより預金残高を仮更新すること
   を特徴とする代行支払システム。
4. 【請求項４】 請求項３に記載の代行支払システムにお
   いて、前記第１の銀行に対する支払終了後、手動または
   自動の指示で、前記仮更新残高欄に記載された預金残高
   で、前記データベースの支払者の預金残高記載欄の残高
   を更新することを特徴とする代行支払システム。
5. 【請求項５】 請求項３に記載の代行支払システムにお
   いて、前記データベースの仮更新残高記載欄に記載され
   た残高を前記支払者の第１の端末で閲覧可能であること
   を特徴とする代行支払システム。
6. 【請求項６】 請求項１に記載の代行支払システムにお
   いて、前記第１の銀行に対する支払の終了の旨を示す支
   払通知情報を入力する支払通知入力手段とを具え、該支
   払通知入力手段から入力された支払通知情報を前記通信
   手段を介して前記支払者の第１の端末に対して通知する
   ことを特徴とする代行支払システム。
7. 【請求項７】 請求項１に記載の代行支払システムにお
   いて、前記第２の銀行側の人間により前記支払者から前
   記決済予定明細の形態で依頼された支払についての第２
   の銀行側の支払承認を入力する支払承認入力手段と、前
   記決済予定明細および前記第２の銀行側の支払承認を互
   いに関連付けて表示する表示手段とをさらに具えたこと
   を特徴とする代行支払システム。
8. 【請求項８】 請求項１に記載の代行支払システムにお
   いて、前記第１の銀行側からの支払終了通知情報を入力
   する支払終了通知情報入力手段と当該入力された支払通
   知情報と、前記決済予定明細の示す情報とを同じ情報内
   容について照合する照合手段と、 該照合の結果、不一致の情報内容があった場合には、そ
   の旨を示すアンマッチ情報を前記支払者の端末に前記通
   信手段を介して通知することを特徴とする代行支払シス
   テム。
9. 【請求項９】 請求項１に記載の代行支払システムにお
   いて、前記決済予定明細の示す支払金額について前記預
   金口座から引き落とし可能であるか否の判定を行なう判
   定手段と、該判定の結果を出力する出力手段をさらに具
   えたことを特徴とする代行支払システム。
10. 【請求項１０】 請求項１に記載の代行支払システムに
    おいて、前記決済予定明細書の示す支払先が前記第２の
    銀行に預金口座を有する場合には、前記データベース上
    の前記支払者の預金口座から支払先の預金口座に行内振
    替を行なうことを特徴とする代行支払システム。
11. 【請求項１１】 請求項１に記載の代行支払システムに
    おいて、貸越に限度額を有する共有枠が予め定められて
    おり、該共有枠の限度額以内で、複数の支払者に対して
    前記支払に対する貸越が許容されることを特徴とする代
    行支払システム。
12. 【請求項１２】 請求項１に記載の代行支払システムに
    おいて、前記支払者の第１の端末から入力される決済予
    定明細には前記第１の銀行に対する決済時刻の指示が含
    まれていることを特徴とする代行支払システム。