JP4824204B2

JP4824204B2 - 代金支払いシステム、代金支払い方法、代金請求用端末および代金支払いのための銀行のコンピュータシステム

Info

Publication number: JP4824204B2
Application number: JP2001175842A
Authority: JP
Inventors: 俊良板東
Original assignee: Sumitomo Mitsui Banking Corp
Current assignee: Sumitomo Mitsui Banking Corp
Priority date: 2001-06-11
Filing date: 2001-06-11
Publication date: 2011-11-30
Anticipated expiration: 2021-06-11
Also published as: JP2002366858A

Description

【０００１】
【発明の属する技術分野】
本発明は、オンラインで代金の支払いを行う代金支払いシステム、代金支払い方法、代金請求用端末および代金支払いのための銀行のコンピュータシステムに関する。
【０００２】
【従来の技術】
従来、ネット上で行われる商取引に連動してオンラインで支払う方法はいくつか報告されている。
【０００３】
一方、ネット外で行われる一般の商取引に伴う支払いは、通常、支払人は支払先から送られた請求書に基づいて、支払いを行う。この場合、オンラインで代金の支払いを行う方法としては、銀行のＡＴＭ端末や支払い人の端末を使用して支払人が支払い先の銀行口座に代金を振り込む方法が一般的である。この方法では、支払い先から紙の形態の請求書が支払人に送られ、請求書に記載された内容に基づいて支払人は、ＡＴＭ端末等に対して、支払金額、支払い先の口座番号、支払い先の口座名、支払人の名前等の支払いのために必要な各種情報を入力する。
【０００４】
また、コンビニのような、代金回収代行業者のところに請求書を持参し、現金で支払う。
【０００５】
また、支払い先（代金請求）の企業のコンピュータで作成した電子データの形態の請求情報を、支払人の端末の表示画面で確認して、支払人が自己の端末装置から、支払い先（代金請求）の企業等を介して、支払い人の銀行口座から代金を支払うように指示する代金支払いシステムもいくつか提案されている（金融情報システム、Ｎｏ．２３１２０００．７）。
【０００６】
上記文献で紹介されているシステムを図１９〜図２１に示す。
【０００７】
図１９に示すダイレクト・システム（Ｄｉｒｅｃｔシステム）は、購入者（代金支払人）は自分の端末から請求企業のシステムに請求書情報の確認と代金の支払い指図を送信する。請求企業のシステムから請求企業の取引金融機関のシステムを介して代金の引き落とし指図が購入者の取引金融機関に送られて、購入者の取引金融機関のシステムから請求企業の取引金融機関のシステムに対して入金処理が行われる。
【０００８】
図２０に示すサービス・プロバイダ・コンソリデーション・システム（ＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒＣｏｎｓｏｌｉｄａｔｉｏｎＳｙｓｔｅｍ）では、複数の購入者の端末から請求書情報の確認と支払い指図、複数の請求企業からは請求書情報を取りまとめるコンソリデーションシステム（ＣｏｎｓｏｌｉｄａｔｉｏｎＳｙｓｔｅｍ）が設けられており、コンソリデーションシステムから請求企業の取引金融機関のシステムに引き落とし指図が送られる。請求企業の取引金融機関のシステムと購入者の取引金融機関のシステムとの間で、口座引き落とし請求と入金処理が行われる。
【０００９】
図２１に示すカスタマ・コンソリデーション・システム（ＣｕｓｔｏｍｅｒＣｏｎｓｏｌｉｄａｔｉｏｎＳｙｓｔｅｍ）は購入者の端末がＰＦＭという特殊なプログラムを使用し、請求企業のシステムから送られる請求書情報を保管する。購入者の端末から決済サービス提供者に支払い指図が送られて、購入者の取引金融機関のシステムから請求企業の取引金融機関のシステムに対して入金処理がなされる。
【００１０】
【発明が解決しようとする課題】
代金の請求書が紙の形態で送られ、銀行のＡＴＭや代金支払人の端末から代金の支払い指示を代金支払人の取引金融機関の（コンピュータ）システムに送信する場合に、代金支払人は、請求書に記載された支払金額、支払い先の銀行口座のある銀行名、支払い先の銀行口座の預金科目、支払い先の銀行口座の口座番号、支払い先の銀行口座の口座名と支払い人自身の名前等をキーボードから入力しなければならない。
【００１１】
代金の支払い案件が多いほど代金支払人の情報入力作業は大変な労力となる。
【００１２】
また、銀行振込での支払いにおいては、振込手数料を差し引いて振り込む等により請求した金額以外の金額で支払われることがある。支払額が請求額に比べて不足すれば、請求した企業にとって受取額が減少するだけでなく、不足額について再度請求する等の作業も必要となり、新たにコストが発生する。
【００１３】
また、銀行振込での支払いにおいては、振込期限を設定することはできないので、期限を過ぎての支払いを受付けたくない場合も、支払いを行うことができるので、支払いを受けた企業では、受け取った資金を返却しなければならなず、そのための新たな作業負担が発生する。
【００１４】
また、支払いを受ける企業は、一定期日よりも早く支払えば支払金額を値引きすることにして、早く代金回収をしたいこともあるが、現状そのような機能を有する支払いシステムはない。
【００１５】
また、コンビニ等の代金回収代行業者を利用して支払う場合は、上記の支払い人の入力負担や支払金額不足の問題はなくなるが、支払い人は現金等の支払手段を、コンビニ等に持参しなければならない。
【００１６】
また、請求情報を予め請求企業のサーバー等に登録しておき、この請求明細を支払い人が端末から確認して支払い指図を出す方法では、支払い時における支払い人の入力負担は軽減できるが、請求明細を検索するためのシステムや支払い指図を支払い人の取引金融機関のシステムに取り次ぐシステムが必要であり、支払い操作をするときにこれらのシステムが稼動していないと支払い人は支払いを行うことができない。
【００１７】
そこで、本発明の目的は、代金支払人の情報入力作業の労力を低減することができ、請求企業にとって支払額が請求額と異なる金額となることを防止することができ、支払い人にとって現金等の支払手段を持ち歩くことを防止することができ、支払い人が支払い操作を行うときに、少なくとも支払い人の使用する端末と通信ネットワークと支払い人の取引金融機関のシステムが稼動していればいつでも支払いを行うことがきる代金支払いシステム、代金支払い方法、代金請求用端末および代金支払いのための銀行のコンピュータシステムを提供することにある。
【００１８】
【課題を解決するための手段】
このような目的を達成するために、本発明では複数の代金の支払い人が使用する複数の代金支払い用端末と、複数の代金の支払い先が使用する複数の代金請求用端末と、前記複数の代金支払い用端末の１つからの代金の支払い要求を受け付け、代金の支払い処理を行う銀行のコンピュータシステムとを有する代金支払いシステムであって、支払人を示す支払人情報、支払い先を示す支払い先情報および前記銀行のコンピュータシステムの通信アドレスを少なくとも含む代金請求情報を前記代金請求用端末から前記代金支払い用端末に送信し、前記代金支払い用端末は、当該送信された代金請求情報を表示可能であり、前記代金支払人からの前記銀行のコンピュータシステムへの接続要求を受け付け、当該接続要求に応じて前記代金請求用端末から送信された通信アドレスを使用して前記銀行のコンピュータシステムに接続し、前記請求用端末から送信された支払い人情報および支払い先情報を自動送信することを特徴とする代金支払いシステムが提供される。
【００１９】
本発明によれば、前記代金請求情報は電子メールの形態で送信され、前記通信アドレスはＵＲＬの形態で表され、前記支払人情報および支払い先情報はパラメータで、前記ＵＲＬの中に組み込まれる。
【００２０】
本発明によれば、前記代金支払い用端末から前記銀行のコンピュータシステムに対して、前記ＵＲＬが送信され、該銀行のコンピュータシステムは、前記支払い用端末と接続すると共に、送信されたＵＲＬの中から前記支払い人情報および支払い先情報を取り込む。
【００２１】
本発明によれば、前記代金支払い用端末が前記銀行のコンピュータシステムに接続された後、銀行のコンピュータシステムからは、代金支払いに関連する情報を入力するための画面情報が送信されてもよい。
【００２２】
本発明によれば、前記支払人情報を検証するための認証情報が該支払い人情報に付加または組み込まれ、前記銀行のコンピュータシステムは、前記送信された認証情報により前記支払人情報を検証してもよい。
【００２３】
本発明によれば、前記代金請求情報の中には支払い金額を示す支払い金額情報が含まれ、前記代金支払い用端末を介して支払い金額情報が前記銀行のコンピュータシステムに送信されてもよい。
【００２４】
本発明によれば、前記支払い金額情報を検証するための認証情報が該支払い金額情報に付加または組み込まれ、銀行のコンピュータシステムは、前記送信された認証情報により前記支払い金額情報を検証してもよい。
【００２５】
本発明によれば、前記代金請求情報の中には支払期限を示す支払期限情報が含まれ、前記代金支払い用端末を介して支払期限情報が前記銀行のコンピュータシステムに送信され、前記銀行のコンピュータは支払期限情報に基づき支払い可否を決定してもよい。
【００２６】
本発明によれば、前記銀行のコンピュータシステムは、支払金額を支払処理日に応じて決定してもよい。
【００２７】
本発明によれば、前記複数の代金支払い用端末の各々からは前記銀行のコンピュータシステムに対して、支払い人と支払い先を特定した支払いに関する照会が可能であってもよい。
【００２８】
本発明によれば、複数の代金の支払い人が使用する複数の代金支払い用端末と、該複数の代金支払い用端末の１つからの代金の支払い要求を受け付け、代金の支払い処理を実行する銀行のコンピュータシステムとを有する代金支払いシステムであって、少なくとも支払い人を示す支払い人情報および支払い先を示す支払い先情報を含む１つの支払いコードが記載された紙形態の請求書が前記支払い先から前記支払い人に送られ、前記支払人により前記支払いコードと前記銀行に保有する支払い人の預金口座からの出金の指示が前記複数の代金支払い用端末の１つから入力され、当該入力された支払いコードと前記銀行に保有する支払い人の預金口座からの出金の指示を代金支払い用端末から前記銀行のコンピュータシステムに送信し、前記銀行のコンピュータシステムは、送信された支払いコードと前記銀行に保有する支払い人の預金口座からの出金の指示に基づいて代金の支払い処理を実行することを特徴とする代金支払いシステムが提供される。
【００２９】
本発明によれば、前記支払い人情報は、支払い人そのものを示すコードと、該コードを検証するための検証コードとを有し、該検証コードに基づき前記銀行のコンピュータシステムは前記送信された支払い人そのものを示すコードを検証してもよい。
【００３０】
本発明によれば、前記支払いコードは支払金額を検証するための検証コードを含み、該検証コードに基づき前記銀行のコンピュータシステムは、前記送信された前記銀行に保有する支払い人の預金口座からの出金の指示に含まれる支払金額を検証してもよい。
【００３１】
【発明の実施の形態】
以下、本発明の実施形態について、図面を参照しつつ詳細に説明する。
【００３２】
（第１の実施形態）
図１は本発明第１の実施形態としての代金収納システムのシステム構成の一例を示す。第１の実施形態では、紙の形態の請求書が代金支払い先（請求企業）から代金支払人に対して送られる。この請求書に後述の支払いコードが記載されており、この支払いコードを使用して支払人は自己の端末から自己の取引銀行のコンピュータシステムに支払い指図を行うことに新規特徴がある。
【００３３】
本実施形態の代金収納システムは、ユーザ端末１００と、銀行システム２００と、企業システム３００とを有し、これら装置がインターネットなどの通信ネットワーク５００に接続されている。
【００３４】
ユーザ端末１００は、請求書に対する代金の支払を行おうとするユーザが使用する端末であり、通信ネットワーク５００を介して銀行システム２００に支払代金の支払を指示することのできる端末であれば、ユーザ個人が所有する端末でも、銀行の店舗など特定の場所に設置された端末でもよい。ユーザ端末１００の機器としては、ウェブ情報（ＨＴＭＬ文書などのマークアップランゲージ文書により規定される情報）を閲覧可能なブラウザソフトウェア（例えば、マイクロソフト社のインターネットエクスプローラ（登録商標）、ネットスケープ・コミュニケーション社のネットスケープ(登録商標)等）を搭載した市販のパーソナルコンピュータ、ＰＤＡ（Personal Data Assistance）等の情報処理装置や、電話機、無線呼出端末、ＰＨＳ端末、移動体通信端末のいずれも使用することができる。特に、移動体通信端末は、電子メール機能やインターネットへのアクセス機能を有する端末であってもよい（例えば、株式会社エヌ・ティ・ティ・ドコモ社が提供するｉモード（サービス名）端末等）。
【００３５】
銀行システム２００は、ＡＴＭ２１５などを有する営業店システム２１０及び銀行のコンピュータシステム（以下「銀行コンピュータセンタ」と略記する）２２０とを有する。銀行コンピュータセンタ２２０は、通信ネットワーク５００を介し、外部との情報の送受信について通信制御を行う通信制御装置２３０と、後述する代金収納プログラム及び該代金収納プログラムで必要とされる支払コードなどの各種データを格納するサーバ２４０とを備える。銀行システム２００は、さらに顧客の銀行口座に関する情報（以後、口座と略記することがある）、たとえば、預金残高、預金がおこなわれた日付、その金額、引き出しが行われた日付、その金額等を記憶する記憶装置を有する。記憶装置内にはさらに、支払い要求をうけた代金を預かる一時預かり口座に関する情報（後述）を記憶する記憶領域も設けられている。
【００３６】
サーバ２４０は、主制御部（以下「ＣＰＵ」という）と、ハードディスクと、ＲＡＭと、ディスプレイとを備える。ＣＰＵは、後述する代金収納プログラムを実行して、ユーザの保有口座から支払代金相当の金額を出金し、請求書発行企業の保有口座に入金するなどの処理を行う。ハードディスクは、図１３に示すようなＣＰＵの実行する代金収納プログラム、代金収納システムの利用につき銀行と契約を締結した企業に付与した企業コード、検証数値生成ロジック、ユーザの保有口座の残高を操作する際に必要となる暗証番号等を記憶する。ハードディスクの代わりに、フレキシブルディスクや光磁気ディスク等であってもよい。ＲＡＭは、ＣＰＵが代金収納プログラムを実行する際の入出力データを一時記憶する。ディスプレイは、ＣＰＵの実行した代金収納プログラムの処理結果などを銀行がモニタするために利用される。
【００３７】
このように構成されたサーバ２４０は、ユーザからの指示に基づいてユーザの保有口座から支払金額を出金し、銀行の預かり口座に保持した後、請求書を発行した企業の保有口座に入金する機能を有する。
【００３８】
企業システム３００は、請求書を発行した代金受取人の使用するコンピュータまたは処理装置であり、通信ネットワーク５００を介して銀行システム２００から、請求代金の支払があった旨の収納済み連絡を受信する。企業システム３００としては、ホストコンピュータのほか、ウェブ情報（ＨＴＭＬ文書などのマークアップランゲージ文書により規定される情報）を閲覧可能なブラウザソフトウェア（例えば、マイクロソフト社のインターネットエクスプローラ（登録商標）、ネットスケープ・コミュニケーション社のネットスケープ(登録商標)等）を搭載した市販のパーソナルコンピュータ、ＰＤＡ（Personal Data Assistance）等の情報処理装置や、電話、無線呼出端末、ＰＨＳ端末、移動体通信端末のいずれであってもよい。
【００３９】
通信ネットワーク５００は、ユーザ端末１００と銀行システム２００と企業システム３００とを相互に接続する。通信ネットワーク５００としては、例えば、インターネット、イントラネット、ＬＡＮ（Local Area Network）、一般公衆電話網（アナログ／デジタルの双方を含む）、ＰＤＣ／ＰＤＣ―Ｐ／Ｗ−ＣＤＭＡ方式等の移動体通信回線交換網／移動体通信パケット交換網、無線呼出網、ＰＨＳ網、及び衛星通信網等のうちのいずれかの通信ネットワークを使用することができる。
【００４０】
図２に、ユーザ端末１００としてパーソナルコンピュータを利用し、代金収納システムを通じて請求代金の支払を行う場合における処理の流れの一例を示す。
【００４１】
処理（１）
まず、企業は、商品を購入したり、あるいはサービスの提供を受けたユーザに対し請求書を発行し、請求金額と、後述する支払コードとをユーザに通知する。
【００４２】
処理（２）
ユーザは、請求書を受け取ると、ユーザ端末１００から通信ネットワーク５００を介して銀行システム２００に対し、請求書発行企業に対する代金の支払について、代金収納システムを利用して行いたい旨の利用要求を発信する。ユーザ端末１００から要求を受け付けると、銀行システム２００のサーバ２４０は、ユーザ端末１００に対し、図４に示すような支払内容入力画面用の情報を送信する。支払内容入力画面(図４)には、請求代金金額である支払金額を入力する支払金額入力欄４ａと、上記処理(１)で企業から送付された請求書に記載されている支払コードを入力する支払コード入力欄４ｂとが設けられているので、ユーザは、ここに支払金額と支払コードとを入力し、「確認」ボタン４ｃを操作することにより、銀行システム２００に対し支払内容通知を発信する。
【００４３】
ユーザ端末１００から支払内容通知を受け付けると、銀行システム２００内のサーバ２４０は図１５に示す手順に沿って支払内容の妥当性のチェックを行う。そして支払内容の妥当性を確認すると、サーバ２４０は支払い金額を決定し、妥当性チェックの中でデータベースから読み出した企業名と入力された支払金額と支払期限がある場合は支払期限と入力された支払コードをハードディスクに保存し、ユーザ端末１００に対し、図５に示すような支払／照会選択画面用の情報を送信する。この場合の支払い金額の決定は、オプション項目で値引基準日と値引後請求金額がついており、支払い処理日が支払期限より前の場合は、値引後請求金額を支払い金額とする。
【００４４】
支払／照会選択画面（図５）には、「支払」を選択するボタン５ａと「照会」を選択するボタン５ｂが設けられているので、ユーザは支払の時には「支払」のボタン（５ａ）を、照会の時には「照会」のボタン（５ｂ）を操作することで、銀行システム２００に支払指示または照会指示を発信する。
【００４５】
支払指示を受け取ったときには、銀行システム２００内のサーバ２４０は、ハードディスクに保存した企業名と支払金額と支払期限がある場合は支払期限と支払コードとを読み出し、支払処理日が支払期限を越えていない場合は支払内容確認画面（図６）用の情報にセットしてユーザ端末１００に対し送信する。
【００４６】
支払内容確認画面にはユーザが出金を行う出金口座番号を入力する出金口座番号入力欄６ａと該出金口座から出金する際に必要となる暗証番号を入力する暗証番号入力欄６ｂが設けられており、ユーザは表示された支払内容確認画面の表示内容に問題がなければ出金口座番号と暗証番号をそれぞれの欄に入力して「確認」ボタン６ｃを操作して、ユーザ端末１００から銀行システム２００内のサーバ２４０に出金指示を送信する。
【００４７】
処理（３）
銀行システム２００は、上述の処理(２)でユーザ端末１００から出金指示を受け取ると、ユーザの指定する出金口座の暗証番号が一致し該出金口座の残高が支払金額以上にあれば、該出金口座から支払金額を出金する。出金した支払金額は、即時に、例えば別段預金のような銀行内の預かり口座に振り替える。
【００４８】
処理（４）
支払代金の収納処理を実行したときは、照会に備え、収納明細データベースに代金収納済情報を記録する。該収納明細データベース（図１０参照）には企業コードと支払人コードと支払金額と支払日と企業名を記録しておく。
【００４９】
処理（５）
銀行内の預かり口座にユーザの指定する出金口座から出金した支払代金を付け替えると、銀行システム２００から、請求書を発行した企業の企業システム３００に対し、請求した代金が収納されたことを通知する。この収納済連絡は、支払金額振替の都度行うこととしても、１日に１回乃至複数回行うこととしてもよい。
【００５０】
処理(６)
銀行の預かり口座で支払代金を保持した場合は銀行システム２００内では、日次、あるいは週次等の一定期間ごとに預かり口座内でユーザの指定する出金口座から出金した支払金額を保持しているか否かをチェックする。保持している場合、銀行システム２００内の預かり口座から請求書発行企業の口座へ、保持している支払金額を入金する。請求書発行企業の口座への入金は、銀行預かり口座への支払金額振替の都度行うこととしても、１日に１回乃至複数回行うこととしても、何日かに１回行うこととしてもよい。また、請求書発行企業の口座が他行にある場合は、振込にて入金することとしてもよい。
【００５１】
ユーザの所有する端末で上記支払を行った場合は、領収書が発行されないのでユーザにとっては支払が終了したかどうか確認したいニーズがありえる。そのためには図３のような照会処理を設けることができる。
【００５２】
処理（７）
ユーザは、まず、ユーザ端末１００から通信ネットワーク５００を介して銀行システム２００に対し、請求書発行企業に対する代金の支払に関する照会について、代金収納システムを利用して行いたい旨の利用要求を発信する。ユーザ端末１００から利用要求を受け付けると、銀行システム２００のサーバ２４０は、ユーザ端末１００に対し、図４に示すような支払内容入力画面用の情報を送信する。支払内容入力画面(図４)には、請求代金金額である支払金額を入力する支払金額入力欄４ａと、上記処理(１)で企業から送付された請求書に記載されている支払コードを入力する支払コード入力欄４ｂとが設けられているので、ユーザは、ここに支払金額と支払コードとを入力し、「確認」ボタン４ｃを操作することにより、銀行システム２００に対し支払内容通知を発信する。
【００５３】
ユーザ端末１００から支払内容通知を受けつけると、銀行システム２００内のサーバ２４０は図１５に示す手順に沿って支払内容の妥当性のチェックを行う。そして支払内容の妥当性を確認すると、サーバ２４０は妥当性チェックの中でデータベースから読み出した企業名と支払コードから抽出した支払金額と入力された支払コードをハードディスクに保存し、ユーザ端末１００に対し、図５に示すような支払／照会選択画面用の情報を送信する。
【００５４】
支払／照会選択画面（図５）には、「支払」を選択するボタン５ａと「照会」を選択するボタン５ｂが設けられているので、ユーザは「照会」のボタン（５ｂ）を操作することで、銀行システム２００に支照会指示を発信する。
【００５５】
処理（８）
照会指示を受け取ると、銀行システム２００内のサーバ２４０は、収納明細データベースを検索し、該支払コードの代金収納済情報が記録されているかを調べ、該支払コードに対応する代金収納情報が記録されていた場合は、該収納明細データベースから支払先と支払金額と支払日を読み出し、「支払済み」の文言とともに支払済返信画面（図７）にセットしユーザ端末１００に送信する。収納明細データベース検索の結果、該支払コードに対応する代金収納済情報が記録されていなかった場合は、該支払コードを「支払未済」の文言とともに支払未済返信画面（図８）にセットしユーザ端末１００に送信する。
【００５６】
次に、図１２を参照して、ユーザ端末１００の動作について説明する。
【００５７】
ユーザは、銀行システム２００に対しユーザ端末１００から利用要求を発信する（Ｓ１００）。
【００５８】
請求書が紙で送られ、利用要求発信の際に支払コードをパラメータの形で同時に送信しない場合（後述の第２の実施形態の送信形態ではない場合）は、銀行システム２００からユーザ端末１００に、支払内容入力画面用の情報が送信されてくるので、ユーザ端末１００が、支払内容入力画面用の情報を受信すると（Ｓ１１０がＹＥＳ判定）、ユーザ端末１００のＣＰＵは、上述した支払内容入力画面（図４）を表示画面上に表示する（Ｓ１１１）。支払内容入力画面（図４）上には、請求代金金額である支払金額を入力する支払金額入力欄４ａと、企業から送付された請求書に記載されている支払コードを入力する支払コード入力欄４ｂとが設けられているので、ユーザは、キーボードを使用して、ここに支払金額と支払コードとを入力し、「確認」ボタン４ｃを操作することにより、銀行システム２００に対し支払内容通知を発信する（Ｓ１１２）。
【００５９】
請求書が電子メールで送られた場合は、請求電子メール上に表示されたハイパーリンクを操作することで支払金額を含む支払コードをパラメータとして利用要求と一緒に送信する。この場合は、銀行システム２００から支払内容入力画面用の情報は送られない。
【００６０】
次にユーザ端末１００が銀行システム２００から支払／照会選択画面用の情報を受信すると（Ｓ１２０がＹＥＳ判定）、ユーザ端末１００のＣＰＵは、上述した支払／照会選択画面（図５）を表示画面上に表示する（Ｓ１２１）。支払／照会選択画面(図５)には、支払を行う場合に選択する「支払」ボタン５ａと、照会を行う場合に選択する「照会」ボタン５ｂが設けられているので、ユーザは自分が行いたい処理に応じていずれかのボタンを操作することにより、銀行システム２００に対して支払指示または照会指示を発信する（Ｓ１２２）。
【００６１】
支払指示を発信した場合は、次にユーザ端末１００は銀行システム２００から支払内容確認画面用の情報を受信するので、ユーザ端末１００のＣＰＵは、支払内容確認画面（図６）を表示画面上に表示する（Ｓ１３０→Ｓ１３１）。支払内容確認画面（図６）上には、支払先と支払金額と支払コードの支払内容の表示と出金口座を特定するための出金口座番号入力欄６ａと出金承認のための暗証番号を入力する暗証番号入力欄６ｂが設けられているので、ユーザは、表示された支払内容に問題がなければ出金口座番号欄と暗証番号入欄に出金口座番号と暗証番号を入力し、「確認」ボタン６ｃを操作することにより、銀行システム２００に対し出金指示を発信する（Ｓ１３２）。
【００６２】
照会指示を発信した場合は、次にユーザ端末１００は銀行システム２００から通知した支払内容に該当する支払が終了したかどうかにより支払済返信画面用の情報または支払未済返信画面用の情報を受信するので（Ｓ１４０がＹＥＳ判定またはＳ１５０がＹＥＳ判定）、支払済返信画面用の情報を受信した場合は、ユーザ端末１００のＣＰＵは、上述した支払済返信画面（図７）を表示画面上に表示する。支払済返信画面（図７）上には、「支払済」である旨の文言と支払先と支払金額と支払日の内容が表示されているので、ユーザは、表示された支払内容を確認後「閉じる」のボタン７ａを操作して処理を終了する（Ｓ１４１→エンド）。
【００６３】
一方、ユーザ端末１００が、支払未済返信画面用の情報を受信すると、ユーザ端末１００のＣＰＵは、上述した支払未済返信画面（図８）を表示画面上に表示する（Ｓ１５０→Ｓ１５１）。支払未済返信画面（図８）上には、「支払未済」である旨の文言と支払コードが表示されているので、ユーザは、表示された支払内容を確認後「閉じる」のボタン８ａを操作して処理を終了する（Ｓ１５１→エンド）。
【００６４】
次に、図１３を参照して、銀行システム２００内のサーバ２４０の動作について説明する。
【００６５】
ユーザの端末からの要求に応じてユーザ端末１００に対して図４の支払い内容入力画面用の情報（ＨＴＭＬ文書）を送信する（Ｓ２００→Ｓ２０１）。
【００６６】
続いて、ユーザ端末１００から支払内容通知を受け取ると、サーバ２４０のＣＰＵは、図１５の手順に従い支払内容の妥当性チェックを行い（Ｓ２１０→Ｓ２１１）、妥当と判断された場合は、支払い金額を決定し、妥当性チェックの中でデータベースから読み出した企業名と入力された支払金額と支払期限がある場合は支払期限と入力された支払コードをハードディスクに保存し、ユーザ端末１００に対し、図５に示すような支払／照会選択画面用の情報を送信する（Ｓ２１２→Ｓ２１３→Ｓ２１４→Ｓ２１５）。この場合の支払い金額の決定は、オプション項目で値引基準日と値引後請求金額がついており、支払い処理日が支払期限より前の場合は、値引後請求金額を支払い金額とする。妥当と判断されなかった場合はパラメータの内容が不適当であり、収納処理を行えないことをユーザ端末１００に返信する（Ｓ２１２→Ｓ２１６）。
【００６７】
次に支払指示を受け取ると銀行システム２００内のサーバ２４０は、ハードディスクに保存した企業名と支払金額と支払期限がある場合は支払期限と支払コードとを読み出し、支払処理日が支払期限を越えていない場合は支払内容確認画面（図６）用の情報にセットしてユーザ端末１００に対し送信する（Ｓ２２０→Ｓ２２１→Ｓ２２５→Ｓ２２６→Ｓ２２７）。支払い処理日が支払い処理日を越えている場合は収納処理できないことをユーザ端末１００に返信する（Ｓ２２８）。
【００６８】
続いて出金指示を受け取ると銀行システム２００は、ユーザの指定する出金口座の暗証番号が一致し該出金口座の残高が支払金額以上にあれば、該出金口座から支払金額を出金する（Ｓ２３０→Ｓ２３１→Ｓ２３２）。出金した支払金額は、即時に、例えば別段預金のような銀行内の預かり口座に振り替える（Ｓ２３３）。
【００６９】
そして、照会に備え、サーバ２４０上の収納明細データベースに代金収納済情報を記録する（Ｓ２３４）。該収納明細データベース（図１０参照）には企業コードと支払人コードと支払金額と支払日と企業名を記録しておく。
【００７０】
銀行内の預かり口座にユーザの指定する出金口座から出金した支払代金を付け替えると、銀行システム２００から、請求書を発行した企業の企業システム３００に対し、請求した代金が収納されたことを通知する（Ｓ２３５）。この収納済連絡は、支払金額振替の都度行うこととしても、１日に１回または複数回行うこととしてもよい。
【００７１】
銀行の預かり口座で支払代金を保持した場合は銀行システム２００内では、日次、あるいは週次等の一定期間ごとに預かり口座内でユーザの指定する出金口座から出金した支払金額を保持しているか否かをチェックする。保持している場合、銀行システム２００内の預かり口座から請求書発行企業の口座へ、保持している支払金額を入金する（Ｓ２３６）。請求書発行企業の口座への入金は、銀行預かり口座への支払金額振替の都度行うこととしても、１日に１回乃至複数回行うこととしても、何日かに１回行うこととしてもよい。また、請求書発行企業の口座が他行にある場合は、振込にて入金することとしてもよい。
【００７２】
ユーザ端末１００に対し、支払／照会選択画面用の情報を送信したあと、支払指示ではなく照会指示を受け取った場合は、銀行システム２００内のサーバ２４０は、収納明細データベースを検索し（Ｓ２２０→Ｓ２２１→Ｓ２２２）、該支払コードの代金収納済情報が記録されているかを調べ（Ｓ２２３）、該支払コードに対応する代金収納情報が記録されていた場合は、該収納明細データベースから支払先と支払金額と支払日を読み出し、「支払済み」の文言とともに支払済返信画面（図７）にセットしユーザ端末１００に送信する（Ｓ２２３→Ｓ２２４）。収納明細データベース検索の結果、該支払コードに対応する代金収納済情報が記録されていなかった場合は、該支払コードを「支払未済」の文言とともに支払未済返信画面（図８）にセットしユーザ端末１００に送信する（Ｓ２２３→Ｓ２２９）。
【００７３】
次に、図１５を参照して、紙ベースで請求書を受けた場合における上記処理(２)において銀行システム２００内のサーバ２４０の行う、妥当性チェックの手順について説明する。なお、図１５の説明に先立って、代金収納システムを利用した支払代金の支払時に必要となる支払コードについて説明する。請求書を発行する企業は、ユーザに請求書を送付する際、以下に述べる支払コードをユーザごとに生成し、ユーザに請求する金額などの情報とともに請求書上に記載し、ユーザに通知する。
【００７４】
支払コードは、企業コードと、支払人コードと、支払人コードの検証数値と、支払金額の検証数値とを含むコードをいう。
【００７５】
企業コードとは、請求代金の回収にあたり、代金収納システムを利用することにつき、銀行と契約を締結した企業に対して銀行から固有に付与されるコードをいう。企業コードは、例えば企業の希望する複数個のアルファベットと、銀行が与える３文字程度の付加文字によって生成することが考えられる。
【００７６】
銀行と契約を締結した企業が例えばガス会社であり、そのガス会社から銀行に、企業コードのヘダー部に３桁のアルファベット「ｇａｓ」を希望し、銀行が「ｘｙｚ」を付加文字として与えた場合には、そのガス会社の企業コードは「ｇａｓ−ｘｙｚ」となる。銀行は、この企業コードを企業コードデータベースに保存する。そのレイアウトは図９に示す。
【００７７】
支払人コードとは、代金の受取人である請求書発行企業から請求された金額の支払いを行うユーザに対し、請求書発行企業が付与するコードである。支払人コードとしては、例えば８桁程度の数字によって生成することが考えられる。支払人コードに８桁程度の数字を使用することで、一億人程度のユーザへの対応が可能となる。支払人コードとしては、例えば、「１２３４５６７８」である。ここでは例として８桁としたが、ハイフン（−）等の文字をセパレーション文字として使用することにより、桁数は請求書発行企業が任意に選ぶことができる。請求先企業毎に桁数が違ってもよいし、また同じ請求書発行企業で支払人毎に桁数が違ってもよい。
【００７８】
検証数値とは、上記処理(２)において触れた支払内容の妥当性チェックの際に必要となる数値であり、上述した支払人コード、ユーザへの請求金額などの情報を、受取人である請求書発行企業に対し銀行が交付した検証数値ロジックを用いて数桁程度の数字に数値化したものをいう。検証数値ロジックはいろいろなものが考えられるが、一般的には、検証したい元のコードの各桁の数値に各桁毎に予め定めた重み数値を掛け合わせたものを合計し、その結果をある基準数で割った余りを利用することが多い。検証数値ロジックを用いて支払人コード「１２３４５６７８」を数値化した場合は、検証数値が「３４」、ユーザへの請求金額「５０００円」を数値化した場合には検証数値が「５６」、などとなる。
【００７９】
支払人コード「１２３４５６７８」を持つユーザに対して、企業コード「ｇａｓ−ｘｙｚ」をもつ受取人が、ガス料金「５０００円」を請求した場合の支払コードは以下の通りとなる。支払人コードの検証数値を「３４」、請求金額の検証数値を「５６」として、支払コードを、企業コード、支払人コード、支払人コードの検証数値、請求金額の検証数値の順に格納することとすると、請求書に記載される支払コードは、「ｇａｓ−ｘｙｚ−１２３４５６７８−３４−５６」となる。
【００８０】
更に、オプション項目として、支払期限、値引基準日、値引後請求金額の情報をもつこともできる。
【００８１】
これらはオプション項目であり、常にあるとは限らないので、その存在を示すために識別用符号を用いることが考えられる。例えば、支払期限は頭に“ｄ”をつけて年付日を表示することが考えられる。この場合、２００１年７月３１日はｄ０１０７３１と表示される。同様に値引基準日と値引後請求金額は頭に“ｃ”をつけて表示することが考えられる。２００１年６月３０日までに支払う場合は４８００円にすると言う場合は、それぞれｃ０１０６３０、ｃ４８００と表示される。したがって、前述のガス料金の支払いにおいて、支払期限が２００１年７月３１日で、２００１年６月３０日までに支払う場合は４８００円になるという場合は、支払いコードは「ｇａｓ−ｘｙｚ−１２３４５６７８−３４−５６−ｄ０１０７３１−ｃ４８００−ｃ０１０６３０」となる。また、値引条件は同一で支払期限がない場合は、支払いコードは「ｇａｓ−ｘｙｚ−１２３４５６７８−３４−５６−ｃ４８００−ｃ０１０６３０」となる。
【００８２】
次に、図１５を使用して、サーバ２４０の行う、妥当性チェックの手順について説明する。ユーザ端末１００からの利用要求を受けつけると、サーバ２４０内のハードディスクに格納する代金収納プログラムが起動する。これにより、ＣＰＵは、以下の処理を行う。
【００８３】
ユーザ端末１００上に表示された支払内容入力画面(図４)から入力された支払コードを受け付けると（Ｓ５００）、ＣＰＵは、支払コードの中から企業コードと支払人コードと支払人コードの検証数値と請求金額の検証数値と、支払期限、値引基準日、値引後請求金額のオプション項目がある場合は、これらのオプション項目を取り出し、ＲＡＭに記憶する（Ｓ５１０）。ハイフン（−）等のセパレーション文字、並びにオプション項目については識別符号（“ｄ”、“ｃ”）を識別することにより、各コードの取り出しは容易に行うことができる。企業コードは該企業と契約時に決定し企業コードデータベース上に保存してあるので、該企業コードデータベースを検索することにより（Ｓ５２０）、企業コードの妥当性をチェックを行う（Ｓ５３０）。
【００８４】
支払内容入力画面(図４)では支払金額も一緒に入力されるので、企業コードが企業コードデータベースに登録されている場合、ＣＰＵは、支払人コード、支払金額の各数値に検証数値ロジックを施し、それぞれの検証数値を算出する（Ｓ５４０→Ｓ５５０）。
【００８５】
そして算出した検証数値と、支払コードから取り出した検証数値とを比較し、両者の一致を確認する（Ｓ５６０）。一致する場合には、ユーザ端末１００からの支払指示の妥当性が確認されたことになる。一致しない場合は、ユーザ端末１００からの支払指示の妥当性は否認されたことになり、ユーザは、代金収納システムを利用して請求書に対する支払を行うことができないこととなる。
【００８６】
（第２の実施形態）
第２の実施形態では、全体のシステム構成は、図１の第１の実施形態と同様である。
【００８７】
第２の実施形態の場合、ユーザ端末１００は、電子メールが受信できる端末であり、一般的には請求書に対する代金の支払を行おうとするユーザが所有するパソコンや携帯電話等の移動体通信端末（例えば、株式会社エヌ・ティ・ティ・ドコモ社が提供するｉモード（サービス名）端末等）を想定している。
【００８８】
また、このユーザ端末１００では、電子メールに埋め込まれたＵＲＬのハイパーリンクに対応できる機能がついていることを想定している。
【００８９】
銀行システム２００は、代金収納サービス用のＵＲＬを持ち、インターネットを通じ、ユーザから代金収納サービスの要求を受け、一連の処理が行えることを想定している。
【００９０】
企業システム３００は、ユーザ端末１００に電子メールを送信できるシステムであることを想定している。
【００９１】
処理の流れは図２の第１の実施形態とほぼ同様であるので、以下、請求書を紙ベースで送る場合と、電子メールで送る場合の相違点を図２の処理の流れに沿って説明する。
【００９２】
処理（１）
企業は、商品を購入したり、あるいはサービスの提供を受けたユーザに対し、請求金額と、後述する支払コードとを電子メール（以下、請求電子メールという）で通知する（図１１）。この請求電子メールには、銀行システム２００における代金収納サービスのサイトのＵＲＬを、支払コードをパラメータとして付した形で埋め込んでおく（１１ａ）。
【００９３】
ＵＲＬ上への表示の仕方は、例えば「？」以下の部分に支払コードを記載すればよい。ＵＲＬへのパラメータのセット方法には他にもいろいろあるのでそのいずれの方法を採用しても良い。ＵＲＬのアドレス部分は、銀行システム２００における代金収納サービスのサイトのアドレスである。
【００９４】
この支払コードは、紙ベースの請求書に記載された場合の支払コードと同一でもよいが、この例においては、支払コード内に支払金額も埋め込んだ形にしている。理由は、紙ベースの請求書の場合は、支払コードをユーザが手で入力しなければならず、支払金額を支払コードに含めず別入力としても全体の入力工数は増えないので、別入力として支払意思確認の効果を明確にするためである。それに対し、請求電子メールの場合は、ハイパーリンクを操作するだけでパラメータの情報が自動的に銀行システムに伝えられるため、ユーザの入力負担をできるだけ少なくするために請求書発行企業側でセットできる情報はすべて支払コードの中に表示するようにしたからである。
【００９５】
処理（２）
次に、ユーザは、ユーザ端末１００で請求電子メールを受け取ると、該請求電子メール内に埋め込まれたハイパーリンクのＵＲＬを操作することにより、通信ネットワーク５００を介して銀行システム２００に対し、請求書発行企業に対する代金の支払について、代金収納システムを利用して行いたい旨の利用要求を発信する。ユーザ端末１００がハイパーリンクに対応した端末であると、予めこのＵＲＬには銀行システム２００における代金収納サービスのサイトのアドレスがセットされているので、このハイパーリンクを操作することにより、前記の利用要求は自動的に発信される。
【００９６】
ユーザ端末１００から利用要求を受け付けると、銀行システム２００のサーバ２４０は、要求メッセージの中からＵＲＬの中に付されたパラメータを受け取る。このパラメータには支払コードが示されており、該支払コードは、企業コード、支払人コード、支払金額、支払人コードの検証数値、支払金額の検証数値から構成されているので、図１６の手順に従いこれらの妥当性のチェックを行う。そして支払コードの妥当性を確認すると、サーバ２４０は支払い金額を決定し、妥当性チェックの中でデータベースから読み出した企業名と入力された支払金額と支払期限がある場合は支払期限と入力された支払コードをハードディスクに保存し、ユーザ端末１００に対し、図５に示すような支払／照会選択画面用の情報を送信する。この場合の支払い金額の決定は、オプション項目で値引基準日と値引後請求金額がついており、支払い処理日が支払期限より前の場合は、値引後請求金額を支払い金額とする。
【００９７】
ユーザ端末１００が支払／照会選択画面を受け取った後の処理は先に説明した第１の実施形態の紙ベースの請求書のケースと同様である。
【００９８】
ユーザが通知された支払コードにおける支払済否を照会する場合は、図３のような処理の流れとなる。
【００９９】
処理（７）
ユーザは、ユーザ端末１００で受け取った請求電子メールのハイパーリンクを操作することで、通信ネットワーク５００を介して銀行システム２００に対し、代金収納システムの利用要求を発信する。
【０１００】
ユーザ端末１００から利用要求を受け付けると、銀行システム２００のサーバ２４０は、要求メッセージの中からＵＲＬの中に付されたパラメータを受け取る。このパラメータには支払コードが示されており、該支払コードは、企業コード、支払人コード、支払金額、支払人コードの検証数値、支払金額の検証数値から構成されているので、図１６の手順に従いこれらの妥当性のチェックを行う。そして支払コードの妥当性を確認すると、サーバ２４０は妥当性チェックの中でデータベースから読み出した企業名と支払コードから抽出した支払金額と入力された支払コードをハードディスクに保存し、ユーザ端末１００に対し、図５に示すような支払／照会選択画面用の情報を送信する。
【０１０１】
ユーザ端末１００が支払／照会選択画面を受け取った後の処理は先に説明した第１の実施形態の紙ベースの請求書のケースと同様である。
【０１０２】
請求電子メールにおいて、支払コードは支払金額も含むものとしているので、上記のガス会社の例では請求電子メールに記載される支払コードは、「ｇａｓ−ｘｙｚ−１２３４５６７８−３４−５６−５０００」となる。
【０１０３】
したがって、支払金額の取り出し方法以外は紙ベースの請求書の場合と同じであるので説明を省略する。
【０１０４】
ユーザ端末１００の処理手順は図１２の処理手順とほぼ同様とすることができるが、この形態では、電子メールのハイパーリンクのＵＲＬの操作で、Ｓ１００の利用要求発信処理が行われ、支払いコード（支払人自身のコード、検証コード、支払い先コード等）がユーザ端末１００から自動送信される。したがって、この場合は、支払内容入力画面用の情報がサーバ２４０から送られて来ることはなく、Ｓ１１０でＹＥＳになることはないので、Ｓ１１１〜Ｓ１１２の処理は行われない。
【０１０５】
この形態におけるサーバ２４０の処理手順を図１４に示す。図１４の処理手順において、第１の実施形態の図１３と同じ処理には同一の符号を付しており、重複的な説明を省略し、相違点を説明する。
【０１０６】
ユーザ端末１００から利用要求を受けつけると（Ｓ２００がＹＥＳ判定）、サーバ２４０のＣＰＵは、図１６の手順に従いパラメータの妥当性チェックを行い（Ｓ２０２）、妥当と判断された場合は、妥当性チェックの中でデータベースから読み出した企業名と支払コードから抽出した支払金額と入力された支払コードをハードディスクに保存し、ユーザ端末１００に対し、図５に示すような支払／照会選択画面用の情報を送信する（Ｓ２０３→Ｓ２０４→Ｓ２０５）。妥当と判断されなかった場合はパラメータの内容が不適当であり、収納処理を行えないことをユーザ端末１００に返信する（Ｓ２０３→Ｓ２０６）。
【０１０７】
第２の実施形態の銀行システム２００内のサーバ２４０の検証のための処理手順を図１６に示す。図１６において第１の実施形態の図１５と同様の処理には同一の符号を付している。第２の実施形態ではＳ５００に代わってＳ５０１の処理が、Ｓ５１０に代わってＳ５１１の処理がそれぞれ追加されている。
【０１０８】
第２の実施形態では、支払いコードは支払内容通知画面ではなく、利用要求と同時にハイパーリンクのパラメータとして受け取ることと、支払いコードの中には紙形態の請求書の場合に受け取った支払いコードとは異なり、支払い金額も含まれているのでＳ５０１とＳ５１１ではその対応を行う。支払い金額の抽出方法が異なるだけでその後の検証処理は図１５の紙形態の場合と同様であるので説明を省略する。
【０１０９】
（第３の実施形態）
第１の実施形態では、ユーザは、紙の形態の請求書に記載された支払いコードを使用して、支払人および支払い先を銀行のコンピュータシステム２００に通知（入力）する例であった。第２の実施形態は、請求先から送られる電子メールのハイパーリンク（ＵＲＬ）を使用して、支払いコードおよび支払い金額をユーザ端末１００から銀行のコンピュータ２００に自動入力する例であった。
【０１１０】
第１の実施形態と第２の実施形態を併用することで第３の実施形態を実施することができる。この場合には、銀行のコンピュータシステム２００のサーバ２４０が以下の処理を実行する。
【０１１１】
ユーザ端末１００から送られるＵＲＬ情報に支払いコードに関するパラメータが付加されているか否かを判定し、支払いコードが付加されている場合には第２の実施形態によるユーザ端末の情報送信と判定し、パラメータによる支払いコード等の入力処理を実行する。そうでない場合には、ＵＲＬで指示されるＨＴＭＬ文書、図４の表示画面用のＨＴＭＬ文書をユーザ端末１００に送信する。
【０１１２】
次に、他の実施形態について説明する。
【０１１３】
(１)上述した実施形態においては、紙ベースの請求書においては支払コードを、企業の希望する複数個アルファベットと銀行が与える３文字程度の付加文字からなる企業コード、８桁程度の数字からなる支払人コード、支払人コードと支払金額に対するそれぞれ２桁程度の数字からなる検証数値がハイフン（−）により区切られる例を、また電子メールの請求書については更に支払金額を含める例を説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、各企業におけるユーザ数や支払の目的などに鑑み、桁数を変更することが考えられる。また、紙ベースの請求書において支払コードに支払金額を含めることや電子メールの請求書において支払コードに支払金額を含めないことも考えられる。
【０１１４】
(２)上述した実施形態においては、１つの支払コードを用いて代金収納を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、支払コードをいくつかに分割し、短い支払コードをユーザに入力させるようにすることも考えられる。例えば上述した実施形態における「ｇａｓ−ｘｙｚ−１２３４５６７８−３４−５６」という１８桁の支払コードを２つに分け、一方の支払コードを企業コード「ｇａｓ−ｘｙｚ」とし、もう一方の支払コードに支払人コードと、支払コードと請求金額のそれぞれの検証数値とを含めて「１２３４５６７８-３４−５６」とし、これら２つの支払コードを個々にユーザに入力させることも考えられる。１８桁もの長い支払コードを１度にユーザに入力させることにより生じる誤入力を防ぐためである。この際、支払コードをいくつに分割するか、分割してできたそれぞれの短い支払コードにどのような情報を含め、ユーザに入力させることとするか等については、様々な変形が考えられることはいうまでもない。
【０１１５】
(３)また、上述した実施形態においては、ユーザ端末１００からの支払内容及び出金指示の入力として、支払金額、支払コード、出金口座の指定、出金口座の暗証番号の順にユーザに入力させる場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、この入力順を変更し、出金口座の指定、支払金額、支払コード、暗証番号の順にユーザに入力させることとしてもよい。さらに、支払コードの中に支払金額を含む場合には、再度支払代金金額を入力させることをせず、銀行システム２００からユーザ端末１００の表示画面に支払金額情報を表示させ、ユーザに金額を確認させることにより、支払金額の入力を行わせることも考えられる。また、支払者が自己のパーソナルコンピュータ等で入力を行う場合には、あらかじめ銀行と契約を結んで、通信のための暗証番号等を取り決めておく必要があるが、その際交付した契約番号のようなものを入力することで、出金口座の指定を省略したり、複数口座保有する場合はその口座番号を一覧で表示し選択させたりすることもできる。また、上述した実施形態においては、このようなサービスを行う支店、及び預金科目を限定してあることを前提として、ユーザ端末１００からの出金指示の入力として、出金口座の指定は、出金口座番号のみの入力を行うことで可能とした。しかし、本発明はこの場合に限定されるものではない。他の実施形態においては支店、及び預金科目を限定せず、ユーザ端末１００から都度指定できるようにすることも考えられる。その場合、出金口座の指定は、出金口座のある支店番号、出金口座預金科目、出金口座番号の３つの入力で行うことになる。
【０１１６】
このように、支払コードや出金口座を特定する情報など、支払内容、出金指示に必要な情報を銀行システム２００に伝えることができれば、これら情報をユーザ端末１００から入力する際の入力手順を入れ替えてユーザに入力させたり、入力する項目を増やしたり、選択方式として入力する方法を変えたりすることも考えられる。
【０１１７】
(４)上述した実施形態においては、支払内容を入力する手段として、支払金額入力欄４ａと、支払コード入力欄４ｂとを１つの画面に備えた支払内容入力画面(図４)を用いる場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、支払内容を入力する手段を複数の入力画面で構成し、ユーザに入力させることとしてもよい。例えば、まず支払金額入力欄だけを備えた画面から支払金額を入力させ、ユーザに入力内容の確認をさせた後に、ユーザ端末１００に支払コードを入力する画面を表示させ、支払コードを入力させることとすることができる。
【０１１８】
(５)上述した実施形態においては、ユーザ端末１００から銀行システム２００に支払内容通知、出金指示を行い、支払代金の支払を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、銀行システム２００内におけるＡＴＭ端末２１５から、ユーザが、銀行コンピュータセンタ２２０に支払内容通知、出金指示を行うことも考えられる。この場合、ＡＴＭ端末２１５の表示画面に、支払内容入力画面(図４)のような画面を表示して支払内容の入力を、支払内容確認画面(図６)のような画面を表示して出金指示の入力をそれぞれ行わせることが考えられる。またＡＴＭを利用する場合には、キャッシュカードを挿入することで、出金口座番号の入力を省略することもできる。
【０１１９】
(６)上述した実施形態においては、ユーザの指定する出金口座から支払金額を出金し、銀行がその金額を一旦、預かり口座に入金し、その後請求書発行企業の保有口座にその金額を入金することにより、請求書発行企業に対する支払を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、ユーザが、ＡＴＭ端末２１５を操作することによりＡＴＭ端末２１５から支払金額相当の現金を入金し、請求書発行企業に対する支払を行うことも考えられる。
【０１２０】
(７)上述した実施形態においては、ユーザの指定する出金口座から支払金額を出金し、銀行がその金額を一旦、預かり口座に入金し、その後請求書発行企業の保有口座にその金額を入金することにより、請求書発行企業に対する支払を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、ユーザの指定する出金口座から支払金額を出金し、その金額を請求書発行企業の保有口座に直接入金することも考えられる。
【０１２１】
(８)上述した実施形態においては、代金収納システムを利用してユーザが請求代金の支払を行う際に、支払内容入力画面(図４)のような画面から、ユーザが、請求書上に記載された支払金額や支払コードの入力を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、ユーザに送付する請求書上に、支払金額や支払コードを示すバーコードやピクセルコードを記載し、バーコードやピクセルコードを読み取ることのできる読取装置を備えたユーザ端末１００でバーコードやピクセルコードの読み取りを行わせることにより、支払金額や支払コードの入力を簡素化することも考えられる。
【０１２２】
(９)上述した実施形態においては、あらかじめユーザの元に送付されてきた請求書上に記載された支払コードなどの情報をもとに請求書発行企業に対する支払を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施形態においては、例えば、デビットカードを用いた商品代金の支払の代替手段として、代金収納システムを利用することも考えられる。
【０１２３】
具体的には、図１７に示すような手順が考えられる。まず、ユーザへ商品を販売するにあたって、商品の販売を行う販売店の店頭などで、ユーザに対し支払コードを生成する(Ｐ１)。ユーザは、支払コードを元に、販売店の店頭等において、ユーザの保持する移動体通信端末等のユーザ端末１００を利用して、銀行システム２００に対し、利用要求、支払内容通知、支払指示、出金指示等を行う(Ｐ２)。銀行システム２００は、ユーザ端末１００から受け付けた利用要求、支払内容通知、支払指示、出金指示等に基づいて、ユーザの指定する出金口座から商品代金を出金し、銀行内の預かり口座に振り替えを行う(Ｐ３)。一方、販売店のコンピュータ４００は、銀行システム２００に対し、同一の支払コードに基づいて、利用要求、支払内容通知、照会指示を行う（Ｐ４）ことで、ユーザからの支払が完了したかどうかを知ることができる。これらを予めパラメータ付のハイパーリンクしておくことで、支払内容通知を省略できるため、更に簡単に支払済否を確認できる。支払済みであることが確認できれば、販売店はユーザに商品を引渡す(Ｐ５)。銀行システム２００内では、適宜、銀行内の預かり口座から商品代金金額相当を、販売店の保有する口座に入金する(Ｐ６)。
【０１２４】
このようにすることにより、販売店の店頭にデビットカード決済用の端末を置かなくてもデビットカードによる支払と同様、銀行での決済可否に関する情報を入手することができるので、現金を所持していないユーザに対して、商品を販売あるいはサービスを提供することができる。また、出金口座に関する情報や暗証番号など、全ての出金に関する情報を、ユーザ自身が保持する端末を利用してユーザ自身が入力すれば足りることから、暗証番号などの情報が外部に漏れることを防ぐことができる。さらに、販売店側に設置されたデビットカード決済用の端末にデビットカードを差し込む事により生じるカード情報の漏洩も防ぐことができる。
【０１２５】
(１０)代金引替による通信販売などに、代金収納システムを利用した支払方法を利用し、ユーザが商品代金を支払済みである旨を確認した後に商品の引渡しを行うことも考えられる。具体的には、図１８に示すような手順が考えられる。まず、ユーザへ商品を配達するにあたって、運送会社の配送センタなどで生成しておいた支払コードを商品代金の請求書とともに商品配達時にユーザに提示する(Ｑ１)。
【０１２６】
ユーザは、支払コードを元に、自宅にある電話などのユーザ端末１００を利用して、銀行システム２００に対し、利用要求、支払内容通知、支払指示、出金指示等を行う(Ｑ２)。銀行システム２００は、ユーザ端末１００から受け付けた利用要求、支払内容通知、支払指示、出金指示等に基づいて、ユーザの指定する出金口座から商品代金を出金し、銀行内の預かり口座に振り替えを行う(Ｑ３)。商品の配達を行う配達者は、銀行システム２００に対し、同一の支払コードに基づいて、利用要求、支払内容通知、照会指示を行う（Ｑ４）ことで、ユーザからの支払が完了したかどうかを知ることができる。ユーザが商品代金を支払済みであることについての確認をした配達者は、その後、ユーザに商品を引渡す(Ｑ５)。銀行システム２００内では、適宜、銀行内の預かり口座から配達商品の代金金額相当を、運送会社の保有する口座に入金する(Ｑ６)。このようにすることにより、ユーザは手元に現金を保持していなくても配達された商品を受け取ることができ、配送業者は、現金の授受に関する作業から開放されることができる。
【０１２７】
（１１）上述の実施形態では、企業コードをアルファベット、支払い人コードと各検証数値を数字として説明したが、本発明はこの場合に限定されるものではない。企業コード、支払い人コード、各検証数値ともコンピュータで使用可能な文字であればどのような文字を使うこととしても良い。
【０１２８】
（１２）上述の実施形態では、各検証数値の桁数を２桁として説明したが、本発明はこの場合に限定されるものではない。各検証数値の桁数を１桁、または３桁以上とすることとしても良い。
【０１２９】
（１３）上述の第２の実施形態において、電子メール中に記載されるＵＲＬのパラメータは請求先の端末で暗号化し、銀行のコンピュータシステムのサーバが、上記パラメータを受信した時に、復号化してもよい。
【０１３０】
以上、説明したように、本実施形態では、電話やインターネット、移動体通信端末等を介して、ユーザの指定する口座から支払金額を出金し、請求書発行企業に対する請求金額の支払を行うこととしているので、ユーザは、請求書と必要な額の現金とを持って銀行の窓口やコンビニエンスストアの店頭などに実際に出向くことなく、代金受取者への代金の支払を、現金を所持していなくても、例えば自宅などから行うことができる。また、銀行が支払われた代金を預かり口座に預かった時点で代金収納済情報を記録して、企業に収納済連絡をしたり収納済みとして照会に答えることとしているので、従来の振込処理のように支払い処理が完了するのに一定の時間を要することなく、ユーザの口座から請求金額を出金した時点で支払が完了したこととなり、処理時間が原因で生じるトラブルの発生を防ぐことができる。
【０１３１】
また、支払金額と支払人コードとを確認した後に、ユーザの指定する出金口座から請求金額を出金し、請求書を発行した企業の口座に入金することとしているため、入金に際しては支払人を特定することができ、かつ、請求代金以外の入金を排除することができる。これにより、例えば、公共料金や各種検定料等の減額をすることのできない金額の回収を望む企業にあっては、請求した金額以外の金額による入金を受け付けなくても済むことができるので、従来のように、請求金額以外の入金を抽出し、不足金額についての再請求を行うような事務作業を回避でき、事務負担を軽減することができる。
【０１３２】
以上の説明の中で、支払い人が使用する代金支払い用端末、代金の支払い先が使用する代金請求用端末、代金の支払い処理を行う銀行のコンピュータシステムは、それぞれ、支払い人の処理を代行する者が使用する代金支払い用端末、代金の支払い先の処理を代行する者が使用する代金請求用端末、代金の支払い処理を行う銀行の処理を代行する者のコンピュータシステムを含めるものとする。
【０１３３】
【発明の効果】
以上、説明したように、本発明によれば、代金支払い用端末では請求用端末から送信された代金請求情報を表示可能であり、代金支払人からの銀行のコンピュータシステムへの接続要求を受け付け、当該接続要求に応じて前記代金請求用端末から送信された通信アドレスを使用して前記銀行のコンピュータシステムに接続し、請求用端末から送信された支払い人情報および支払い先情報を自動送信するので、代金支払人および支払い先に関する情報を文字で手入力する必要はない。
【０１３４】
本発明によれば、代金請求情報は電子メールの形態で送信され、通信アドレスはＵＲＬの形態で表され、支払人情報および支払い先情報はパラメータで、ＵＲＬの中に組み込まれるので、ハイパーリンク等の機能を使用して代金支払い用端末と銀行のコンピュータシステムを自動接続することができる。
【０１３５】
本発明によれば、代金支払い用端末から銀行のコンピュータシステムに対して、ＵＲＬが送信され、銀行のコンピュータシステムは、支払い用端末と接続すると共に、送信されたＵＲＬの中から支払い人情報および支払い先情報を取り込むので、既存のホームページ（ＨＴＭＬ文書）提供用のソフトウェアを使用して支払い人情報および支払い先情報を受信することができる。
【０１３６】
本発明によれば、代金支払い用端末が銀行のコンピュータシステムに接続された後、銀行のコンピュータシステムからは、代金支払いに関連する情報を入力するための画面情報が送信されるので、ユーザはその画面情報により表示された案内情報にしたがって、出金口座番号等各種の情報を入力することができる。
【０１３７】
本発明によれば、支払人情報を検証するための認証情報が該支払い人情報に付加または組み込まれ、銀行のコンピュータシステムは、送信された認証情報により支払人情報を検証するので、不正な送信情報を排除することができる。
【０１３８】
本発明によれば、代金請求情報の中には支払い金額を示す支払い金額情報が含まれ、代金支払い用端末を介して支払い金額情報が前記銀行のコンピュータシステムに送信されるので、支払い金額の手入力操作をなくすことができる。
【０１３９】
本発明によれば、支払い金額情報を検証するための認証情報が該支払い金額情報に付加または組み込まれ、銀行のコンピュータシステムは、送信された認証情報により前記支払い金額情報を検証するので、請求金額以外の支払いを排除することができる。
【０１４０】
本発明によれば、複数の代金支払い用端末の各々からは銀行のコンピュータシステムに対して、個々の支払いに関する照会が可能であるので、代金支払いの確認を支払人や支払い先が行うことができる。
【０１４１】
本発明によれば、少なくとも支払い人を示す支払人コードおよび支払い先を示す支払い先コードが記載された紙形態の請求書が前記支払い先から前記支払い人に送られ、支払人は、支払い先コードを入力するだけでよく、支払い先の口座に関する情報を入力する必要がないので、支払人の手入力操作が低減する。
【０１４２】
本発明によれば、支払人コードは、支払い人そのものを示すコードと、該コードを検証するための検証コードとを有し、該検証コードに基づき銀行のコンピュータシステムは送信された支払い人そのものを示すコードを検証するので、不正な送信情報を排除することができる。
【図面の簡単な説明】
【図１】本発明第１の実施形態のシステム構成を示すブロック図である。
【図２】本発明第１の実施形態の処理内容を示す説明図である。
【図３】本発明第２の実施形態の処理内容を示す説明図である。
【図４】支払いに関連する情報を入力するための画面の内容を示す説明図である。
【図５】支払いに関連する情報を入力するための画面の内容を示す説明図である。
【図６】支払いに関連する情報を入力するための画面の内容を示す説明図である。
【図７】支払いに関連する情報を入力するための画面の内容を示す説明図である。
【図８】支払いに関連する情報を入力するための画面の内容を示す説明図である。
【図９】収納明細ベースに登録される企業コードおよび企業名の一例を示す説明図である。
【図１０】収納明細ベースに登録される支払人コード等の一例を示す説明図である。
【図１１】本発明第２の実施形態の電子メールの内容を示す説明図である。
【図１２】本発明第１の実施形態のユーザ端末の処理手順を示すフローチャートである。
【図１３】第１の実施形態のサーバの処理手順を示すフローチャートである。
【図１４】第２の実施形態のサーバの処理手順を示すフローチャートである。
【図１５】第１の実施形態のサーバの検証処理の詳細を示すフローチャートである。
【図１６】第２の実施形態のサーバの検証処理の詳細を示すフローチャートである。
【図１７】他の実施形態の支払い処理の内容を示す説明図である。
【図１８】他の実施形態の支払い処理の内容を示す説明図である。
【図１９】従来の代金支払いシステムを示すブロック図である。
【図２０】従来の他の代金支払いシステムを示すブロック図である。
【図２１】従来の他の代金支払いシステムを示すブロック図である。
【符号の説明】
１００ユーザ端末
２００銀行システム
２４０サーバ
３００企業のコンピュータ

Claims

複数の代金の支払い人が使用する複数の代金支払い用端末と、複数の代金の支払い先が使用する複数の代金請求用端末と、前記複数の代金支払い用端末の１つからの代金の支払い要求を受け付け、代金の支払い処理を行う銀行のコンピュータシステムとを有する代金支払いシステムであって、
支払人を示す支払人情報、支払い先を示す支払い先情報および前記銀行のコンピュータシステムの通信アドレスを少なくとも含む代金請求情報を前記代金請求用端末から前記代金支払い用端末に送信し、
前記代金支払い用端末は、当該送信された代金請求情報を表示可能であり、前記代金支払人からの前記銀行のコンピュータシステムへの接続要求を受け付け、
当該接続要求に応じて前記代金請求用端末から送信された通信アドレスを使用して前記銀行のコンピュータシステムに接続し、前記請求用端末から送信された支払い人情報および支払い先情報を自動送信し、
前記代金請求情報は電子メールの形態で送信され、前記通信アドレスはＵＲＬの形態で表され、前記支払人情報および支払い先情報はパラメータで、前記ＵＲＬの中に組み込まれ、前記代金支払い用端末から前記銀行のコンピュータシステムに対して、前記ＵＲＬが送信され、該銀行のコンピュータシステムは、前記支払い用端末と接続すると共に、送信されたＵＲＬの中から前記支払い人情報および支払い先情報を取り込むことを特徴とする代金支払いシステム。
請求項１に記載の代金支払いシステムにおいて、前記代金支払い用端末が前記銀行のコンピュータシステムに接続された後、
銀行のコンピュータシステムからは、代金支払いに関連する情報を入力するための画面情報が送信されることを特徴とする代金支払いシステム。
請求項１または２に記載の代金支払いシステムにおいて、前記支払人情報を検証するための認証情報が該支払い人情報に付加または組み込まれ、前記銀行のコンピュータシステムは、前記送信された認証情報により前記支払人情報を検証することを特徴とする代金支払いシステム。
請求項１〜３のいずれかに記載の代金支払いシステムにおいて、前記代金請求情報の中には支払い金額を示す支払い金額情報が含まれ、前記代金支払い用端末を介して支払い金額情報が前記銀行のコンピュータシステムに送信されることを特徴とする代金支払いシステム。
請求項４に記載の代金支払いシステムにおいて、前記支払い金額情報を検証するための認証情報が該支払い金額情報に付加または組み込まれ、銀行のコンピュータシステムは、前記送信された認証情報により前記支払い金額情報を検証することを特徴とする代金支払いシステム。
請求項１〜５のいずれかに記載の代金支払いシステムにおいて、前記代金請求情報の中には支払期限を示す支払期限情報が含まれ、前記代金支払い用端末を介して支払期限情報が前記銀行のコンピュータシステムに送信され、前記銀行のコンピュータは、前記送信された支払期限情報に基づき支払い可否を決定することを特徴とする代金支払いシステム。
請求項１〜６のいずれかに記載の代金支払いシステムにおいて、前記代金請求情報の中には値引基準日を示す値引基準日情報と値引後支払金額を示す値引後支払金額情報が含まれ、前記代金支払い用端末を介して値引基準日情報と値引後支払金額情報が前記銀行のコンピュータシステムに送信され、前記銀行のコンピュータシステムは、支払処理日と前記送信された値引基準日情報と前記送信された値引後支払金額情報に基づき支払金額を決定することを特徴とする代金支払いシステム。
請求項１〜７のいずれかに記載の代金支払いシステムにおいて、前記複数の代金支払い用端末の各々からは前記銀行のコンピュータシステムに対して、支払い人と支払い先を特定した支払いに関する照会が可能であることを特徴とする代金支払いシステム。
複数の代金の支払い人が使用する複数の代金支払い用端末と、複数の代金の支払い先が使用する複数の代金請求用端末と、前記複数の代金支払い用端末の１つからの代金の支払い要求を受け付け、代金の支払い処理を行う銀行のコンピュータシステムとを有する代金支払いシステムで実行される代金支払い方法であって、支払い人を示す支払い人情報、支払い先を示す支払い先情報および前記銀行のコンピュータシステムの通信アドレスを少なくとも含む代金請求情報を前記代金請求用端末から前記代金支払い用端末に送信し、前記代金支払い用端末は、当該送信された代金請求情報を表示可能であり、前記代金支払い人からの前記銀行のコンピュータシステムへの接続要求を受け付け、当該接続要求に応じて前記代金請求用端末から送信された通信アドレスを使用して前記銀行のコンピュータシステムに接続し、前記請求用端末から送信された支払い人情報および支払い先情報を自動送信し、
前記代金請求情報は電子メールの形態で送信され、前記通信アドレスはＵＲＬの形態で表され、前記支払人情報および支払い先情報はパラメータで、前記ＵＲＬの中に組み込まれ、前記代金支払い用端末から前記銀行のコンピュータシステムに対して、前記ＵＲＬが送信され、該銀行のコンピュータシステムは、前記支払い用端末と接続すると共に、送信されたＵＲＬの中から前記支払い人情報および支払い先情報を取り込むことを特徴とする代金支払い方法。
請求項９に記載の代金支払い方法において、前記代金支払い用端末が前記銀行のコンピュータシステムに接続された後、銀行のコンピュータシステムからは、代金支払いに関連する情報を入力するための画面情報が送信されることを特徴とする代金支払い方法。
請求項９または１０に記載の代金支払い方法において、前記支払人情報を検証するための認証情報が該支払い人情報に付加または組み込まれ、前記銀行のコンピュータシステムは、前記送信された認証情報により前記支払い人情報を検証することを特徴とする代金支払い方法。
請求項９〜１１のいずれかに記載の代金支払い方法において、前記代金請求情報の中には支払い金額を示す支払い金額情報が含まれ、前記代金支払い用端末を介して支払い金額情報が前記銀行のコンピュータシステムに送信されることを特徴とする代金支払い方法。
請求項１２に記載の代金支払い方法において、前記支払い金額情報を検証するための認証情報が該支払い金額情報に付加または組み込まれ、銀行のコンピュータシステムは、前記送信された認証情報により前記支払い金額情報を検証することを特徴とする代金支払い方法。
請求項９〜１３のいずれかに記載の代金支払い方法において、前記代金請求情報の中には支払期限を示す支払期限情報が含まれ、前記代金支払い用端末を介して支払期限情報が前記銀行のコンピュータシステムに送信され、前記銀行のコンピュータは前記送信された支払期限情報に基づき支払い可否を決定することを特徴とする代金支払い方法。
請求項９〜１４のいずれかに記載の代金支払い方法において、前記代金請求情報の中には値引基準日を示す値引基準日情報と値引後支払金額を示す値引後支払金額情報が含まれ、前記代金支払い用端末を介して値引基準日情報と値引後支払金額情報が前記銀行のコンピュータシステムに送信され、前記銀行のコンピュータシステムは、支払処理日と前記送信された値引基準日情報と前記送信された値引後支払金額情報に基づき支払金額を決定することを特徴とする代金支払い方法。
請求項９〜１５のいずれかに記載の代金支払い方法において、前記複数の代金支払い用端末の各々からは前記銀行のコンピュータシステムに対して、支払い人と支払い先を特定した支払いに関する照会が可能であることを特徴とする代金支払い方法。