JP2013134708A

JP2013134708A - 支払処理方法およびその支払処理に用いる銀行サーバ

Info

Publication number: JP2013134708A
Application number: JP2011286340A
Authority: JP
Inventors: Yoko Mita; 瑶子三田
Original assignee: Sumitomo Mitsui Banking Corp
Current assignee: Sumitomo Mitsui Banking Corp
Priority date: 2011-12-27
Filing date: 2011-12-27
Publication date: 2013-07-08
Anticipated expiration: 2031-12-27
Also published as: JP5918995B2

Abstract

【課題】代金の支払経路において発生する代金未収のリスクを無くすことが可能であり、しかもカード情報等の漏洩による被害のリスクも軽減することのできる支払処理方法を提供する。
【解決手段】この支払処理方法では、購入者である第１ユーザが有する第１の端末１００から販売者である第２ユーザが有する第２の端末２００に第１ユーザのメールアドレスが送信され、そのメールアドレスが第２の端末２００から銀行サーバ３００に送信される。銀行サーバ３００は購入者である第１ユーザのメールアドレスにメールを送信し、第１ユーザの銀行における口座番号等を含む第１ユーザ特定情報の送信を第１ユーザに要求し、その情報が顧客マスタ３５１中の第１ユーザの情報及び／又は第１ユーザの銀行口座の口座情報と対応している場合、購入者である第１ユーザの銀行口座から販売者である第２ユーザの銀行口座への前記支払額に対応した額の送金処理を行う。
【選択図】図１

Description

あるユーザから他のユーザへの現金の支払いを処理する支払処理方法およびその支払処理に用いるサーバに関し、例えば、インターネット上で商品の販売、サービスの提供等を行っている販売者・提供者に対して前記商品又はサービスの購入を行う購入者が現金を支払う場合の支払処理方法およびその支払処理に用いるサーバに関する。

従来から、現実の店舗における商品やサービスに対する対価の支払いは、現金、クレジットカード、デビットカード決済機能付きのキャッシュカード等により行われている。また、近年では、インターネット上での商品の販売やサービスの提供がより広まってきており、その現金支払方法として、クレジットカード決済、コンビニエンスストアや郵便局での決済等が使われている。

具体例として、商品を購入する者がＰＣ（パーソナルコンピュータ）を使ってインターネット上の商品販売サイトにアクセスし、購入した商品の代金支払方法としてクレジットカード決済を選択すると、前記ＰＣの画面にクレジットカードのカード番号、有効期限、セキュリティーコード等を入力する画面が表示される。そして、商品の購入者がカード番号等の情報を入力して画面上の支払ボタンを操作すると、当該入力情報および商品の代金額が商品販売サイトのサーバに送信されると共に、前記商品販売サイトのサーバが前記入力情報に基づいてカード会社に前記カード情報の認証を行う。そして、前記カード情報が認証されると、前記カード会社から前記商品販売サイトの運営会社に前記商品の代金が支払われる。

また、インターネット上での商品購入の決済にデビットカード決済機能付きのキャッシュカードが用いられることもあった。この場合、商品を購入する者がデビットカード決済を選択すると、前記ＰＣの画面にキャッシュカードのカード番号、届出の暗証番号等を入力する画面が表示される。そして、商品の購入者がカード番号等の情報を入力して画面上の支払ボタンを操作すると、入力情報および商品の代金額が商品販売サイトのサーバに送信されると共に、前記商品販売サイトのサーバが前記入力情報に基づいて当該キャッシュカードを発行した銀行のサーバに認証を行う。当該銀行のサーバで前記入力情報が認証されると、前記代金額が前記購入者の銀行口座から引き落とされると共に、前記代金額が前記商品販売サイトの運営会社に支払われる。

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

前述のように、店舗に出掛ける必要がなく、カード番号等の情報の入力だけで代金の支払いを行うことができるので、利用者にとってインターネット上の商品販売サイトやサービス提供サイトは大変便利である。このため、インターネット上において商品販売やサービス提供を行う業者が近年さらに増えてきている。

しかしながら、クレジットカードやキャッシュカードのカード番号等の情報をインターネット経由で送信することは、その情報の漏洩を招来することなので、情報漏洩を恐れてクレジットカードやキャッシュカードを使用しない者もいる。特に、キャッシュカードのカード情報が他人に悪用されると、カードの持ち主の銀行口座から直接に現金が引き出され、他の引き落とし、例えば住宅ローンの引き落とし等に影響を与える場合がある。このため、銀行口座に直接関連するキャッシュカードのカード番号等の取り扱いは、クレジットカードのカード番号等に比べてより厳重にする必要があると言える。

一方、デビットカード決済は、実際に銀行口座にある残高の範囲内で支払いをするものである。また、商品の代金額が購入者の銀行口座の残高から引き落とされ、その代金額が前記商品販売サイトの運営会社に支払われるものである。このため、代金支払いの流れがシンプルであり、代金の支払経路において代金未収のリスクを抱える者を無くすことが可能である。

これに対し、クレジットカード決済の場合は、購入者の信用の範囲内でクレジットカード会社が商品の購入代金を肩代わりするので、クレジットカード会社が代金の支払経路において代金未収のリスクを抱える者となる。そして、前記リスクが前記商品販売サイトの運営会社が支払う手数料に反映される場合もあり、購入者がクレジットカード会社に支払いを行う際の金利に反映される場合もある。このため、支払経路におけるリスクがある分だけ前記商品販売サイトの運営会社と購入者の双方の金銭的負担が増える可能性がある。

本発明は、このような課題を解決するためになされたもので、代金の支払経路において発生する代金未収のリスクを無くすことが可能であり、しかもカード情報等の漏洩による被害のリスクも軽減することのできる支払処理方法およびその支払処理に用いる銀行サーバを提供することにある。

上記目的を達成するため、本発明の主要な観点によれば、第１ユーザが有する第１の端末と、第２ユーザが有する第２の端末と、前記第１の端末および前記第２の端末と通信回線を介して通信可能な銀行のサーバとを用いて、前記第１ユーザから第２ユーザへの現金の支払いを処理する支払処理方法であって、前記銀行のサーバは顧客マスタを有するものであり、この顧客マスタは、前記第１ユーザの名義とメールアドレスとを含む第１ユーザ情報と、前記第１ユーザが前記銀行に有する第１ユーザ用銀行口座の口座情報と、前記第１ユーザについて前記メールアドレスを使った送金を行うか否かの送金契約に関する情報とを対応付けて格納すると共に、前記第２ユーザの名義を含む第２ユーザ情報と、前記第２ユーザが所定の銀行に有する第２ユーザ用銀行口座の口座情報と、前記第２ユーザについて前記メールアドレスを使った送金を受け取る受金契約に関する情報とを対応付けて格納しているものであり、この方法は、前記第１の端末が、前記メールアドレスを前記第２の端末に送信する工程を行い、前記第２の端末が、前記第１の端末から受信した前記メールアドレスと、前記第１ユーザが支払うべき支払額と、前記第２ユーザ情報や前記第２ユーザ用銀行口座の口座情報に関する第２ユーザ特定情報とを前記銀行サーバに送信する工程を行い、前記銀行サーバが、前記第２の端末から受信した前記メールアドレスおよび前記第２ユーザ特定情報を前記顧客マスタに照会し、前記メールアドレスに対応している前記第１ユーザについて前記送金契約の有無を判断すると共に、前記第２ユーザについて前記受金契約の有無を判断する契約有無判断工程と、前記契約有無判断工程で前記第１ユーザおよび前記第２ユーザについて前記契約が有ると判断されると前記第１ユーザの前記メールアドレスにメールを送信するメール送信工程であって、前記メールは、前記第２ユーザから前記支払額の要求があったことを通知すると共に、前記第１ユーザ情報や前記第１ユーザ用銀行口座の口座情報に関する第１ユーザ特定情報の送信を要求するものである、前記メール送信工程と、前記第１のユーザから前記第１ユーザ特定情報を受信すると、前記第１ユーザ特定情報が前記顧客マスタ中の前記第１ユーザ情報および／又は前記第１ユーザ用銀行口座の口座情報と対応しているか否かを判断する第１ユーザ情報判断工程と、前記第１ユーザ情報判断工程で対応していると判断されると、前記第１ユーザ用銀行口座から前記第２ユーザ用銀行口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う送金処理工程とを行うことを特徴とする支払処理方法が提供される。

また、本発明の他の主要な観点によれば、第１ユーザが有する第１の端末および第２ユーザが有する第２の端末と通信回線を介して通信可能であり、前記第１ユーザから第２ユーザへの現金の支払いを処理する銀行サーバであって、前記第１ユーザの名義とメールアドレスとを含む第１ユーザ情報と、前記第１ユーザが前記銀行に有する第１ユーザ用銀行口座の口座情報と、前記第１ユーザについて前記メールアドレスを使った送金を行うか否かの送金契約に関する情報とを対応付けて格納すると共に、前記第２ユーザの名義を含む第２ユーザ情報と、前記第２ユーザが所定の銀行に有する第２ユーザ用銀行口座の口座情報と、前記第２ユーザについて前記メールアドレスを使った送金を受け取る受金契約に関する情報とを対応付けて格納している顧客マスタと、前記第２の端末が第１の端末から受け取り送信する前記第１ユーザの前記メールアドレスを受信すると共に、受信した前記メールアドレスを前記顧客マスタに照会し、前記メールアドレスに対応している前記第１ユーザについて前記送金契約の有無を判断する第１ユーザ契約有無判断手段と、前記第２の端末が送信する情報であって前記第２ユーザ情報や前記第２ユーザ用銀行口座の口座情報に関する第２ユーザ特定情報を受信し、受信した前記第２ユーザ特定情報について前記受金契約の有無を判断する第２ユーザ契約有無判断工程と、前記第１および第２ユーザ契約判断手段で前記第１ユーザおよび前記第２ユーザについて前記契約が有ると判断されると前記第１ユーザの前記メールアドレスにメールを送信するメール送信手段であって、前記メールは、前記第２ユーザから前記支払額の要求があったことを通知すると共に、前記第１ユーザ情報や前記第１ユーザ用銀行口座の口座情報に関する第１ユーザ特定情報の送信を要求するものである、前記メール送信手段と、前記第１のユーザから前記第１ユーザ特定情報を受信すると、前記第１ユーザ特定情報が前記顧客マスタ中の前記第１ユーザ情報および／又は前記第１ユーザ用銀行口座の口座情報と対応しているか否かを判断する第１ユーザ情報判断手段と、前記第１ユーザ情報判断手段で対応していると判断されると、前記第１ユーザ用銀行口座から前記第２ユーザ用銀行口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う送金処理手段とを有することを特徴とする銀行サーバが提供される。

例えば、本発明では、第１ユーザが購入者であり、第２ユーザがインターネット上の商品販売サイトで商品を販売する販売者である場合、前記購入者が有する第１の端末から前記販売者が有する第２の端末に購入者のメールアドレスが送信され、そのメールアドレスが第２の端末から銀行のサーバに送信される。この時、第２の端末からは、前記購入者が支払うべき支払額と、前記販売者を特定できる第２ユーザ特定情報も送信される。一方、銀行のサーバでは、受信した前記購入者のメールアドレスおよび第２ユーザ特定情報を顧客マスタに照会し、前記購入者および前記販売者について送金契約や受金契約の有無を判断する。そして、双方とも契約があると判断されると、銀行のサーバは前記購入者のメールアドレスにメールを送信する。このメールでは、前記販売者から前記支払額の支払要求があったことを前記購入者に通知し、その支払承認と、前記購入者を特定することのできる情報、例えば前記銀行における口座番号等を含む第１ユーザ特定情報の送信を前記購入者に要求する。そして、銀行のサーバは、受信した第１ユーザ特定情報が顧客マスタ中の前記購入者の情報及び／又は前記購入者の銀行口座の口座情報と対応しているか否かを判断し、対応していると判断されると、前記購入者の銀行口座から前記販売者の銀行口座への前記支払額に対応した額の送金処理を行う。

このように、前記購入者から前記販売者に前記購入者のカード情報、銀行口座の情報等を送信することなく、前記購入者から前記販売者に現金の支払いを行うことができるので、代金の支払時にカード情報や銀行口座の情報等の漏洩を防止することができる。

また、銀行のサーバは、受信した第１ユーザ特定情報が顧客マスタ中の前記購入者の情報及び／又は前記購入者の銀行口座の口座情報と対応していると判断されると、前記購入者の銀行口座から前記販売者の銀行口座への前記支払額に対応した額の送金処理を行うので、前記販売者は即時又は比較的短期間で前記支払額に対応した現金を受け取ることができる。また、購入者の銀行口座から販売者の銀行口座に直接的に現金の支払いが行われるので、代金の支払経路において代金未収となる者が発生するリスクを無くすことができる。

また、本発明の実施形態によれば、前記第１の端末は、前記第１ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであり、前記第１ユーザ情報判断工程では、前記第１ユーザ特定情報の少なくとも一部として前記暗号化口座情報を受信し復号化することを特徴とする支払処理方法が提供される。

また、本発明の他の実施形態によれば、前記第１の端末は、前記第１ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであると共に、前記顧客マスタに前記第１ユーザのパスワードを格納しているものであり、前記メール送信工程では、前記第１ユーザ特定情報の送信の要求として、前記第１ユーザが特定のＵＲＬにアクセスすることを要求すると共に、前記第１ユーザが前記第１の端末によって前記特定のＵＲＬにアクセスすると、前記第１の端末の表示装置に前記第１ユーザ特定情報の入力および送信を要求する入力画面を表示させ、前記第１ユーザ情報判断工程では、前記第１ユーザが前記入力画面に入力し前記第１の端末から送信される、前記第１ユーザ特定情報の一部としての前記暗号化口座情報を受信する第１の処理と、前記第１の処理で受信した前記暗号化口座情報を復号化すると共に、復号化した口座情報が前記顧客マスタ中の前記第１ユーザ用銀行口座の口座情報と対応しているか否かを判断する第２の処理と、前記第２の処理で対応していると判断されると、前記入力画面において前記第１ユーザ特定情報の他の部分として前記パスワードの送信を要求する第３の処理と、前記第１ユーザが前記入力画面に入力し前記第１の端末から送信される前記パスワードを受信する第４の処理と、前記第４の処理で受信した前記パスワードが前記顧客マスタ中に格納されている前記第１ユーザの前記パスワードと対応しているか否かを判断する第５の処理とを行うことを特徴とする支払処理方法が提供される。

また、本発明のさらに他の実施形態によれば、前記銀行サーバが、前記メール送信工程の後、前記第１ユーザから前記支払承認と前記第１ユーザ特定情報を受信する迄に所定の時間が経過したことを判断する経過時間判断工程と、前記経過時間判断工程で前記所定の時間が経過したと判断されると、前記第１ユーザによる前記支払額の支払いが不成立となったことを前記メールアドレスに通知する支払不成立メール送信工程とをさらに行い、前記送金処理工程では、前記第１ユーザ情報判断工程で対応していると判断されると共に、前記経過時間判断工程で前記所定の時間が経過していない場合に、前記送金処理を行うことを特徴とする支払処理方法が提供される。

また、本発明のさらに他の実施形態によれば、前記銀行サーバが、前記送金処理工程が行われた後に、前記送金処理後の前記第１ユーザ用銀行口座の口座情報を含む処理完了通知を前記メールアドレスに送信する口座情報送信工程を行うことを特徴とする支払処理方法が提供される。

また、本発明のさらに他の実施形態によれば、前記銀行サーバが、前記送金処理工程が行われた後に、前記送金処理後の前記第１ユーザ用銀行口座の口座情報を前記第１の端末の前記表示装置に表示させる口座情報表示工程を行うことを特徴とする支払処理方法が提供される。

本発明によれば、例えば購入者の銀行口座から販売者の銀行口座に直接的に代金分の現金が送金されるので、購入者から販売者への代金の支払経路において代金未収となる者が発生せず、代金未収となるリスクに対する前記購入者又は前記販売者の金銭的負担を取り除くことができる。また、カード情報等の漏洩による被害のリスクも低減されるので、前記購入者はインターネット上における支払いをより安全に行うことができる。

なお、この発明の更なる他の特徴と顕著な効果は次の発明を実施するための最良の形態の項に記載された実施形態及び図面を参照することによって当業者に理解される。

本発明の第一実施形態に係る支払処理システムの概略構成を示す図銀行サーバの概略構成を示す図顧客マスタの例第１の端末および銀行サーバにおける処理を示すフローチャート第１の端末の表示装置の表示画面の例第１の端末、第２の端末および銀行サーバにおける処理を示すフローチャート販売情報の例支払処理データの例第１の端末、第２の端末および銀行サーバにおける処理を示すフローチャート第１の端末の表示装置の表示画面の例

以下、本発明の実施形態を図面に基づき説明する。

図１は本発明の第１実施形態に係る現金支払システムの概略構成を示す図である。この現金支払システムは、第１ユーザ（商品やサービスの購入者）が有する第１の端末１００と、第２ユーザ（商品の販売者やサービスの提供者）が有する第２の端末２００と、ある銀行に備えられ、第１の端末１００および第２の端末２００と通信回線を介して通信可能な銀行サーバ３００とを有する。第１および第２の端末１００，２００はデスクトップ型やラップトップ型のパーソナルコンピュータ（ＰＣ）であっても良く、サーバ端末であっても良く、携帯情報端末（ＰＤＡ）やＰＣと同等の機能を備えた携帯電話であっても良く、他の公知のコンピュータ装置であっても良い。本実施形態では第１の端末１００はＰＣと同等の機能を備えた携帯電話であり、第２の端末２００はインターネット上の商品販売サイトを提供するサーバ端末である。

第１の端末１００はＣＰＵ、ＲＡＭ等のコンピュータとしての通常の構成を備えている。また、第１の端末１００は、液晶ディスプレイ等の表示装置１１０と、移動電話網やインターネット網等を使った通信用の通信プロトコルスタックとが含まれた通信インターフェースを有する通信部１２０と、前記銀行に第１ユーザが有する銀行口座の口座情報を格納している口座情報格納部１３０と、プログラムを格納するためのプログラム格納部１４０とを有する。プログラム格納部１４０には、第１の端末１００に所定の動作を行わせる第１ユーザ情報送信処理部１４１が格納されている。第１ユーザ情報送信処理部１４１の機能については第１の端末１００、第２の端末２００および銀行サーバ３００が行う処理の例（図４、図６参照）に沿って以下に説明する。

第２の端末２００はＣＰＵ、ＲＡＭ等のコンピュータとしての通常の構成を備えている。また、第２の端末２００は、コネクタと、インターネット網等を使った通信用の通信プロトコルスタックとが含まれた通信インターフェースを有する通信部２１０と、口座情報格納部２２０と、各種プログラムを格納するためのプログラム格納部２３０と、販売情報格納部２４０とを有する。プログラム格納部２３０には、コンピュータにそれぞれ所定の動作を行わせる販売用画面表示処理部２３１、決済画面表示処理部２３２、決済要求送信処理部２３３、販売情報格納処理部２３４とが格納されている。これらの機能については第１の端末１００、第２の端末２００および銀行サーバ３００が行う処理の例（図４、図６参照）に沿って以下に説明する。

図２は本実施形態の銀行サーバ３００の概略構成を示す図である。この銀行サーバ３００は、ＣＰＵ３１０と、ＲＡＭ３２０と、液晶ディスプレイ等の表示装置３３０と、コネクタと、インターネット網等を使った通信用の通信プロトコルスタックとが含まれた通信インターフェースを有する通信部３４０と、顧客マスタ３５１を格納している顧客マスタ格納部３５０と、口座データ格納部３６０と、それぞれ銀行サーバ３００に所定の動作を行わせる各種プログラムを格納するためのプログラム格納部３７０と、ｅ−ｍａｉｌを使った支払処理のデータを格納するための支払処理データ格納部３８０とを有する。顧客マスタ３５１は、例えば図３に示すように、この銀行における顧客情報（名義、住所、電話番号等のユーザ情報）を支店コード、口座番号等と対応付けて格納しているものである。本実施形態では、顧客マスタ格納部３５０と口座データ格納部３６０は勘定系システムの一部である。顧客マスタ３５１は、ｅ−ｍａｉｌアドレスを使った支払いおよびその支払いの受け取りを行うか否かの契約についての情報を格納している。例えば、第１ユーザはｅ−ｍａｉｌアドレスを使った支払いを行う契約（送金契約）を有し、第２ユーザはｅ−ｍａｉｌアドレスを使った受け取りを行う契約（受金契約）を有し、ユーザＣは前記送金契約および前記受金契約を有する。口座データ格納部３６０は、口座番号ごとに口座残高や銀行取引の履歴を格納するものである。

この銀行サーバ３００は、プログラム格納部３７０に、コンピュータにそれぞれ所定の動作を行わせる口座開設処理部３７１と、契約有無判断処理部３７２と、メール送信処理部３７３と、情報入力画面提供処理部３７４と、第１ユーザ情報判断処理部３７５と、残額判断処理部３７６と、送金処理部３７７と、経過時間判断処理部３７８とが格納されている。これらの機能については第１の端末１００、第２の端末２００および銀行サーバ３００が行う処理の例（図４、図６参照）に沿って以下に説明する。

ここで、第１ユーザは、この銀行で銀行口座を開設する際や、開設後の任意の時に、前記送金契約や前記受金契約をすることができる。例として、第１ユーザがこの銀行で銀行口座を開設する場合の処理について図４のフローチャートに沿って説明する。

先ず、第１ユーザが第１の端末１００により銀行サーバ３００が提供するウェッブページにアクセスし、口座開設の要求を行うと（ステップＳ１）、銀行サーバ３００の口座開設処理部３７１および第１の端末１００のブラウザソフト等により、第１の端末１００の表示装置１１０に口座開設用の画面が表示される（ステップＳ２）。この口座開設用の画面は口座開設に必要な情報の入力および送信をユーザに求めるものである。第１ユーザが前記口座開設用の画面に名義、住所、電話番号等の個人情報を入力し送信すると（ステップＳ３）、銀行サーバ３００が前記個人情報を受け付け、顧客マスタ格納部３５０やその他の格納部に格納する（ステップＳ４）。続いて、銀行サーバ３００が口座開設処理部３７１により、第１の端末１００の表示装置１１０に図５に示すような本願の現金支払サービスの契約の要否と、契約をする場合はパスワードを入力する契約設定画面を表示させる（ステップＳ５）。この契約設定画面では、前記送金契約をするか否かおよび前記受金契約を行うか否かをユーザが入力するようになっている。本実施形態では、第１ユーザは、何れか一方だけ契約すること、両方とも契約すること、又は両方とも契約しないことを選択できる。第１ユーザが前記送金契約をすることについて前記契約選択画面で入力しパスワードと共に送信すると（ステップＳ６）、銀行サーバ３００が前記情報を受け付け、顧客マスタ格納部３５０やその他の格納部に格納する（ステップＳ７）。

続いて、銀行は第１ユーザに本人確認書類の写しの送付、暗証番号の設定等を求める書類を郵送等で送り、第１ユーザは本人確認書類の写しや暗証番号を記載した書類等を銀行に送る。銀行において前記本人確認書類を用いた本人確認が完了し、その結果と前記暗証番号が銀行サーバ３００に入力されると（ステップＳ８）、銀行サーバ３００は第１ユーザに対して銀行口座を開設し、口座番号を設定する（ステップＳ９）。そして、銀行サーバ３００は、顧客マスタ３５１に、前記個人情報と、この個人情報に紐付けて支店コード、口座番号、暗証番号、前記契約の有無の情報、前記パスワード等を格納する（ステップＳ１０）。

続いて、銀行サーバ３００は、口座開設処理部３７１により、第１ユーザの銀行口座の口座情報（支店コード、口座番号等）を暗号化した暗号化口座情報を作成すると共に（ステップＳ１１）、その暗号化口座情報を第１の端末１００に送信し（ステップＳ１２）、第１の端末１００は受信した暗号化口座情報を口座情報格納部１３０に格納する（ステップＳ１３）。若しくは、銀行側で前記暗号化口座情報を記録媒体に格納した後、その記録媒体を第１ユーザに郵送し、第１ユーザが前記記録媒体内の暗号化口座情報を第１の端末１００の口座情報格納部１３０に格納する場合もある。さらに他の方法として、銀行サーバ３００が第１の端末１００に口座情報を暗号化するためのアプリケーション等を提供し、そのアプリケーションを用いて第１の端末１００が口座情報を暗号化し、第１の端末１００が暗号化口座情報を口座情報格納部１３０に格納する場合もある。一方、銀行サーバ３００は前記暗号化口座情報を復号化するための秘密鍵を顧客マスタ格納部３５０等に格納している。この秘密鍵を銀行サーバ３００のみが有していることが好ましい。

インターネット上の商品販売サイトを運営する販売者としての第２ユーザも、この銀行で銀行口座を開設する際や、開設後の任意の時に、前記送金契約や前記受金契約をすることができ、この場合も前述のステップＳ１〜Ｓ１３と類似した処理が行われることになる。ここで、銀行サーバ３００の顧客マスタ３５１は、第２ユーザの情報と共に、第２ユーザが運営する商品販売サイトの情報を格納することも可能である。

続いて、第１ユーザが第１の端末１００を使って第２ユーザが運営するインターネット上の商品販売サイトにアクセスし、商品Ｚを購入しその代金を支払う場合について、図６のフローチャートに沿って説明する。

先ず、第１ユーザが第１の端末１００により前記商品販売サイトにアクセスし商品販売用画面の表示を要求すると（ステップＳ２１）、第２の端末２００の販売用画面表示処理部２３１および第１の端末１００のブラウザソフト等により、第１の端末１００の表示装置１１０に商品販売サイトの画面が表示される（ステップＳ２２）。第１ユーザが商品Ｚの購入を決定し、第１の端末１００上で商品Ｚを購入するための操作を行うことにより、商品Ｚの購入意思が第２の端末２００に送信されると（ステップＳ２３）、第２の端末２００の決済画面表示処理部２３２および第１の端末１００のブラウザソフト等により、第１の端末１００の表示装置１１０に商品Ｚを購入するために第１ユーザが支払うべき支払額が表示されると共に、決済方法を選択させる決済方法選択画面が表示される（ステップＳ２４）。例えば、表示装置１１０に、クレジットカード決済、コンビニエンスストアや郵便局での決済、本願の決済の何れかを選択させる画面が表示される。

ステップＳ２４で本願の決済が選択されると、そのことが第２の端末２００に送信され（ステップＳ２５）、決済画面表示処理部２３２および第１の端末１００のブラウザソフト等により、第１の端末１００の表示装置１１０に第１ユーザのメールアドレスの入力および送信を要求するメールアドレス要求画面が表示される（ステップＳ２６）。第１ユーザがメールアドレスを入力して第２の端末２００に送信すると（ステップＳ２７）、第２の端末２００は、決済要求送信処理部２３３により、受信した第１ユーザのメールアドレスと、前記支払額と、商品Ｚの販売者である第２ユーザを特定するために必要な第２ユーザ特定情報とを銀行サーバ３００に送信する（ステップＳ２８）。なお、第２ユーザ特定情報として、第２ユーザのユーザ情報（第２ユーザの電話番号等の情報や前記商品販売サイトに関する情報）や第２ユーザの銀行口座の口座情報に関する情報（前記暗号化口座情報であっても良い）が送信される。

ここで、第２の端末２００では、本願の決済での支払いが行われる場合、前記販売情報格納処理部２３４により、商品販売サイトで販売された商品についての請求額（前記支払額又は前記支払額から所定の手数料を差し引いた額）と、その請求額が入金される口座の口座情報と、支払う者（購入者）のメールアドレスとを対応付けた販売情報を作成し（図７参照）、その販売情報を販売情報格納部２４０に格納する。

続いて、銀行サーバ３００は、契約有無判断部３７２により、前記第２の端末２００から受信した第１ユーザのメールアドレスを顧客マスタ３５１に照会し、このメールアドレスに対応している第１ユーザについて前記送金契約の有無を判断する（ステップＳ２９）。また、銀行サーバ３００は、契約有無判断部３７２により、前記第２の端末から受信した第２ユーザの第２ユーザ特定情報を顧客マスタ３５１に照会し、第２ユーザについて前記受金契約の有無を判断する（ステップＳ３０）。

続いて、ステップＳ２９およびＳ３０で第１および第２ユーザ双方の契約があると判断されると、銀行サーバ３００は、支払処理データ格納部３８０に、図８に示すような支払処理データを作成する。また、銀行サーバ３００は、メール送信処理部２７３により、第１ユーザの前記メールアドレスにメールを送信する（ステップＳ３１）。このメールは、第２ユーザから商品Ｚの購入につき前記支払額の要求があったことを通知し、当該支払額の支払承認と、購入者である第１ユーザを特定するために第１ユーザ特定情報の送信とを要求するものである。前記支払承認は明示的なものであっても良く、第１ユーザが前記第１ユーザ特定情報を送信したことをもって支払を承認したとみなすことも可能である。第１ユーザ特定情報としては、第１ユーザのユーザ情報（前記個人情報等の情報）や第１ユーザの銀行口座の口座情報に関する情報（前記暗号化口座情報であっても良い）の送信が要求される。本実施形態では、第１ユーザ特定情報として、第１ユーザの前記暗号化口座情報のメールでの送信が要求される。この時、前記メールは、前記情報を前記銀行が有する特定のメールアドレスに送信することを第１ユーザに要求するか、前記メールに対して返信することを要求する。

第１ユーザは、ステップＳ３１で銀行サーバ３００から上記メールを受信すると、第１の端末１００の口座情報格納部１３０に格納されている暗号化口座情報をメールで銀行サーバ３００に送信し（ステップＳ３２）、銀行サーバ３００は、第１ユーザ情報判断処理部３７５により、第１ユーザから受信した暗号化口座情報を前記秘密鍵によって復号化し、復号化した口座情報が顧客マスタ３５１に格納されている第１ユーザの口座情報と対応しているか否かを判断する（ステップＳ３３）。ここで、第１ユーザ情報判断処理部３７５は、ステップＳ３２によって送信されるメールの内容を自動的に確認し、その中に前記暗号化口座情報が含まれている場合、ステップＳ３３を自動的に行うようになっている。続いて、銀行サーバ３００は、残額判断処理部３７６により、第１ユーザの口座残高が前記支払額以上であるか否かを判断する（ステップ３４）。

続いて、ステップＳ３３で対応していると判断され、ステップＳ３４で残高があると判断されると、銀行サーバ３００は、メール送信処理部２７３により、第１ユーザの前記メールアドレスにメールをさらに送信する（ステップＳ３５）。このメールは、第１ユーザに更なる第１ユーザ特定情報として前記パスワードの送信を要求するものであり、このメールにはパスワードを入力する画面を表示するためのＵＲＬが記載されている。第１ユーザがメールに記載されたＵＲＬにアクセスすると（ステップＳ３６）、銀行サーバ３００の情報入力画面提供処理部３７４および第１ユーザの端末のブラウザソフト等により、第１ユーザの端末に前記パスワードを入力および送信するための画面が表示される（ステップＳ３７）。第１ユーザが前記パスワードの入力および送信を行うと（ステップＳ３８）、銀行サーバ３００は第１ユーザ情報判断処理部３７５により、送信された前記パスワードが顧客マスタ３５１に格納されている第１ユーザのパスワードと対応しているか否かを判断する（ステップＳ３９）。

続いて、ステップＳ３３およびＳ３９で対応していると判断され、ステップＳ３４で残高があると判断されると、銀行サーバ３００は、前記第１ユーザの口座から第２ユーザの口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う（ステップＳ４０）。具体的には、前記第１ユーザの口座から前記支払額を減額し、前記第２ユーザの口座を前記支払額又は前記支払額から前記所定の手数料を差し引いた額だけ増額する。

続いて、銀行サーバ３００は、送金処理が終了したことを、顧客マスタ３５１に登録されている第２ユーザのメールアドレスにメール送信する（ステップＳ４１）。このメールの内容には、前記支払額と、支払日と、支払者のメールアドレス、つまり第１ユーザのメールアドレスが含まれている。第２の端末２００の販売情報格納処理部２３４は第２ユーザの前記メールアドレス宛のメールの内容を全て自動的に確認するように設定されており、その内容に、販売情報格納部２３０に格納されている各販売情報の請求額（支払額）および購入者メールアドレスに対応するものがある場合、図７に示すように、その販売情報の支払完了受信日の欄にメールの受信日を格納する。

一方、銀行サーバ３００は、送金処理が終了したことと、送金処理後の第１ユーザの口座情報を、顧客マスタ３５１に登録されている第１ユーザのメールアドレスにもメール送信する（ステップＳ４２）。これにより、第１ユーザは支払いが完了したことや、支払いの後の口座残高等を即座に知ることができる。尚、このメールの内容にＵＲＬを含め、第１ユーザがこのＵＲＬにアクセスすると、銀行サーバ３００および第１の端末１００のブラウザソフト等により第１の端末１００の表示装置１１０に第１ユーザの口座情報が表示されるように構成することも可能である。

尚、銀行サーバ３００は、経過時間判断処理部３７８により、ステップＳ３１やステップＳ３５においてメールを送信する際に、メールを送信した日と、それに対する保留期限を設定し、それらを支払処理データ格納部３８０の支払処理データに追加する。そして、銀行サーバ３００は、経過時間判断処理部３７８により、前記ステップＳ３１や前記ステップＳ３５においてメールを送信した後に、前記ステップＳ３２の暗号化口座情報の送信や、前記ステップＳ３６以降が行われない状態で、前記保留期限が経過した場合、当該支払処理を不成立扱いとする。また、不成立になったことと、その支払処理の支払額、購入者である第１ユーザのメールアドレス等を販売者である第２ユーザおよび購入者である第１ユーザにメール送信する。この第１ユーザおよび第２ユーザへのメール送信に用いるメールアドレスとして、顧客マスタ３５１に格納されているものを用いることが可能である。また、第２の端末２００は販売情報格納処理部２３４によって第２ユーザの前記メールアドレス宛のメールの内容を全て自動的に確認するように設定されており、その内容に、販売情報格納部２３０に格納されている各販売情報の請求額（支払額）および購入者メールアドレスに対応するものがある場合、その販売情報に支払いが不成立である旨を格納する。そして、ある支払処理が不成立扱いとなった場合は、その支払処理についてステップＳ３３以降の処理又はステップＳ３７以降の処理は行われない。

このように、本実施形態によれば、購入者である第１ユーザが有する第１の端末１００から販売者である第２ユーザが有する第２の端末２００に第１ユーザのメールアドレスが送信され、そのメールアドレスが第２の端末２００から銀行サーバ３００に送信される。この時、第２の端末２００からは、第１ユーザが支払うべき支払額と、販売者である第２ユーザを特定できる第２ユーザ特定情報も送信される。一方、銀行サーバ３００では、受信した第１ユーザのメールアドレスおよび第２ユーザ特定情報を顧客マスタ３５１に照会し、購入者である第１ユーザおよび販売者である第２ユーザについて送金契約や受金契約の有無を判断する。そして、双方とも契約があると判断されると、銀行サーバ３００は購入者である第１ユーザのメールアドレスにメールを送信する。このメールでは、販売者である第２ユーザから前記支払額の支払要求があったことを第１ユーザに通知し、その支払承認と、購入者である第１ユーザを特定することのできる情報、例えばこの銀行における口座番号等を含む第１ユーザ特定情報の送信を第１ユーザに要求する。そして、銀行サーバ３００は、受信した第１ユーザ特定情報が顧客マスタ３５１中の第１ユーザの情報及び／又は第１ユーザの銀行口座の口座情報と対応しているか否かを判断し、対応していると判断されると、購入者である第１ユーザの銀行口座から販売者である第２ユーザの銀行口座への前記支払額に対応した額の送金処理を行う。

このように、購入者である第１ユーザから販売者である第２ユーザに第１ユーザのカード情報、銀行口座の情報等を送信することなく、第１ユーザから第２ユーザに現金の支払いを行うことができるので、代金の支払時にカード情報や銀行口座の情報等の漏洩を防止することができる。

また、銀行サーバ３００は、受信した第１ユーザ特定情報が顧客マスタ３５１中の第１ユーザの情報及び／又は第１ユーザの銀行口座の口座情報と対応していると判断されると、第１ユーザの銀行口座から第２ユーザの銀行口座への前記支払額に対応した額の送金処理を行うので、販売者である第２ユーザは即時又は比較的短期間で前記支払額に対応した現金を受け取ることができる。また、第１ユーザの銀行口座から第２ユーザの銀行口座に直接的に現金の支払いが行われるので、代金の支払経路において代金未収となる者が発生するリスクを無くすことができる。

このように、購入者である第１ユーザの銀行口座から販売者である第２ユーザの銀行口座に直接的に代金分の現金が送金されるので、購入者から販売者への代金の支払経路において代金未収となる者が発生せず、代金未収となるリスクに対する購入者又は販売者の金銭的負担を取り除くことができる。また、カード情報等の漏洩による被害のリスクも低減されるので、購入者はインターネット上における支払いをより安全に行うことができる。

また、本実施形態では、前記第１の端末１００は、第１ユーザの銀行口座の口座情報を暗号化した暗号化口座情報を格納しているものである。また、銀行サーバ３００は、前記暗号化口座情報を復号化するための秘密鍵を格納しているものである。そして、前記ステップＳ３２では、第１ユーザは第１の端末１００に格納されている暗号化口座情報を銀行サーバ３００に送信し、前記ステップＳ３３では、銀行サーバ３００が第１ユーザを特定するための第１ユーザ特定情報として前記暗号化口座情報を受信し復号化する。このように、第１ユーザは第１の端末１００に格納されている暗号化口座情報を銀行サーバ３００に送信するだけで良いので、支払いの度に口座情報を入力する必要が無くなり、第１ユーザは支払いを容易且つスムーズに行うことができる。また、口座情報が暗号化されているので、口座情報の悪用を防止することができる。さらに、口座情報が暗号化されているので、本実施形態のステップＳ３２にように第１の端末１００から銀行サーバ３００に電子メールで口座情報を送信することができる。ここで、携帯情報端末（ＰＤＡ）や携帯電話はＰＣと比較して入力に時間や手間がかかることが多い。このため、携帯情報端末や携帯電話を用いてインターネット上の商品販売サイト等の代金を支払う者にとって、銀行サーバ３００からメールを受信し、それに対して暗号化口座情報をメールで銀行サーバ３００に送信する本願の構成を採用することは、口座情報をいちいち入力するのに比べて大幅に手間が削減されることになる。

また、本実施形態では、銀行サーバ３００が、前記ステップＳ３１や前記ステップＳ３５でメールを送信した後に、前記ステップＳ３２の暗号化口座情報の送信や、前記ステップＳ３６以降が行われない状態で、所定の保留期限が経過した場合、当該支払処理を不成立扱いとする。また、不成立になったことと、その支払処理の支払額、購入者である第１ユーザのメールアドレス等を販売者である第２ユーザおよび購入者である第１ユーザにメール送信する。本実施形態では、銀行サーバ３００が第１ユーザに第１ユーザ特定情報を求めるにあたり、第１ユーザにメールを送信するようにしているので、第１ユーザのメールの確認頻度によってはいつまでも支払処理が未払いのまま滞留する可能性があるが、前記保留期限が経過すると支払処理が不成立となることから、支払処理が未払いのまま滞留することが防止される。

また、本実施形態では、ステップＳ４１において、送金処理が終了したことが顧客マスタ３５１に登録されている第２ユーザのメールアドレスにメール送信される。そして、このメールの内容には、前記支払額と、支払日と、支払者のメールアドレス、つまり第１ユーザのメールアドレスが含まれている。また、第２の端末２００の販売情報格納処理部２３４は第２ユーザの前記メールアドレス宛のメールの内容を全て自動的に確認する機能を有しており、そのメールの内容に、販売情報格納部２３０に格納されている各販売情報の請求額（支払額）および購入者メールアドレスに対応するものがある場合、図７に示すように、その販売情報の支払完了受信日の欄にメールの受信日を格納する。このように、第２の端末２００でも、第１ユーザのメールアドレスをキーとして販売情報の管理が行われることが可能となる。また、第２の端末２００には第１ユーザの口座情報が送信されることがないので、口座情報の悪用を防止することもできる。

以下、本発明の第２実施形態に係る現金支払システムを説明する。第１実施形態では、第１ユーザ特定情報としての暗号化口座情報がメールで送信される構成となっていたが、第２実施形態では、銀行サーバ３００の情報入力画面提供処理部３７４により第１の端末１００に第１ユーザ特定情報を入力および送信を要求する入力画面を表示させ、その入力画面への入力および送信をもって銀行サーバ３００が第１ユーザ特定情報を受信する構成となっている。また、第１実施形態では、第２ユーザが前記銀行で銀行口座を開設し、この銀行口座に第１ユーザからの支払いが行われるようになっていたが、第２実施形態では、第２ユーザは他の銀行にも銀行口座を有しており、当該他の銀行の銀行口座に第１ユーザからの支払いが行われる。その他の構成は第１実施形態と同様である。

本実施形態において、第１ユーザが第１の端末１００を使って第２ユーザが運営するインターネット上の商品販売サイトにアクセスし、商品Ｚを購入しその代金を支払う場合について、図９のフローチャートに沿って説明する。

ステップＳ５１〜Ｓ５７は第１実施形態のステップＳ２１〜２７と同様である。ステップＳ５７に続いて、第２の端末２００は、決済要求送信処理部２３３により、受信した第１ユーザのメールアドレスと、前記支払額と、商品Ｚの販売者である第２ユーザを特定するために必要な第２ユーザ特定情報とを銀行サーバ３００に送信する（ステップＳ５８）。第２ユーザ特定情報としては、第２ユーザのユーザ情報（第２ユーザの電話番号等の情報や前記商品販売サイトに関する情報）や第２ユーザの銀行口座の口座情報に関する情報（前記暗号化口座情報であっても良い）が送信される。本実施形態の第２ユーザの銀行口座は、銀行サーバ３００が設けられた銀行ではなく、他の銀行に設けられた第２ユーザの銀行口座である。従って、前記暗号化口座情報や、顧客マスタ３５１に格納されている第２ユーザの口座情報も、前記他の銀行のものとなる。なお、顧客マスタ３５１が第２ユーザの他の銀行の口座情報を格納していない場合もあり得る。この場合、ステップＳ５８において、第２の端末２００は第２ユーザが前記他の銀行に有する銀行口座の口座情報を銀行サーバ３００に送信する必要がある。

ステップＳ５９およびＳ６０は第１実施形態のステップＳ２９および３０と同様である。続いて、銀行サーバ３００は、メール送信処理部２７３により、第１ユーザの前記メールアドレスにメールを送信する（ステップＳ６１）。このメールは、第２ユーザから商品Ｚの購入につき前記支払額の要求があったことを通知し、当該支払額の支払承認と、購入者である第１ユーザを特定するために第１ユーザ特定情報の送信とを要求するものである。前記支払承認は明示的なものであっても良く、第１ユーザが前記第１ユーザ特定情報を送信したことをもって支払を承認したとみなすことも可能である。第１ユーザ特定情報としては、第１ユーザのユーザ情報（前記個人情報等の情報）や第１ユーザの銀行口座の口座情報に関する情報（前記暗号化口座情報であっても良い）の送信が要求される。本実施形態では、第１ユーザ特定情報として、第１ユーザの前記暗号化口座情報のメールでの送信が要求される。前記メールにはＵＲＬが含まれており、このメールはＵＲＬにアクセスして第１ユーザ特定情報を入力および送信することを要求するものである。

第１ユーザは、ステップＳ６１で銀行サーバ３００から上記メールを受信すると、メールに含まれているＵＲＬにアクセスし（ステップＳ６２）、これに対し、銀行サーバ３００の情報入力画面提供処理部３７４および第１の端末１００のブラウザソフト等により、第１の端末１００に第１ユーザ特定情報を入力および送信するための画面（図１０参照）が表示される（ステップＳ６３）。第１ユーザが上記入力および送信を行うと（ステップＳ６４）、銀行サーバ３００は、第１ユーザ情報判断処理部３７５により、第１ユーザから受信した暗号化口座情報を前記秘密鍵によって復号化し、復号化した口座情報が顧客マスタ３５１に格納されている第１ユーザの口座情報と対応しているか否かを判断する（ステップＳ６５）。続いて、銀行サーバ３００は、残額判断処理部３７６により、第１ユーザの口座残高が前記支払額以上であるか否かを判断する（ステップ６６）。

続いて、ステップＳ６５で対応していると判断され、ステップＳ６６で残高があると判断されると、銀行サーバ３００の情報入力画面提供処理部３７４および第１の端末１００のブラウザソフト等により、第１の端末１００に更なる第１ユーザ特定情報としてパスワードの入力および送信を要求する画面が表示される（ステップＳ６７）。ステップＳ６８〜Ｓ７２は第１実施形態のステップＳ３８〜Ｓ４２と同様である。

第２実施形態の場合でも、購入者である第１ユーザから販売者である第２ユーザに第１ユーザのカード情報、銀行口座の情報等を送信することなく、第１ユーザから第２ユーザに現金の支払いを行うことができるので、代金の支払時にカード情報や銀行口座の情報等の漏洩を防止することができる。

また、購入者である第１ユーザの銀行口座から販売者である第２ユーザの銀行口座に直接的に代金分の現金が送金されるので、購入者から販売者への代金の支払経路において代金未収となる者が発生せず、代金未収となるリスクに対する購入者又は販売者の金銭的負担を取り除くことができる。また、カード情報等の漏洩による被害のリスクも低減されるので、購入者はインターネット上における支払いをより安全に行うことができる。

前記第１および第２実施形態では、ステップＳ３８やＳ６８で第１ユーザがパスワードを送信する構成を採用しているが、第１および第２実施形態でステップＳ３３、Ｓ３４、Ｓ６５、Ｓ６６の確認がされた段階でステップＳ４０およびＳ７０の送金処理が行われるように構成することも可能である。

尚、この発明は上記一実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。

１００…第１の端末、１１０…表示装置、１２０…通信部、１３０…口座情報格納部、１４０…プログラム格納部、１４１…第１ユーザ情報送信処理部、２００…第２の端末、２１０…通信部、２２０…口座情報格納部、２３０…プログラム格納部、２３１…販売用画面表示処理部、２３２…決済画面表示処理部、２３３…決済要求送信処理部、２３４…販売情報格納部、２４０…販売情報格納部、３００…銀行サーバ、３１０…ＣＰＵ、３２０…ＲＡＭ、３３０…表示装置、３４０…通信部、３５０…顧客マスタ格納部、３５１…顧客マスタ、３６０…口座データ格納部、３７０…プログラム格納部、３７１…口座開設処理部、３７２…契約有無判断処理部、３７３…メール送信処理部、３７４…情報入力画面提供処理部、３７５…第１ユーザ情報判断処理部、３７６…残額判断処理部、３７７…送金処理部、３７８…経過時間判断処理部。

Claims

第１ユーザが有する第１の端末と、第２ユーザが有する第２の端末と、前記第１の端末および前記第２の端末と通信回線を介して通信可能な銀行のサーバとを用いて、前記第１ユーザから第２ユーザへの現金の支払いを処理する支払処理方法であって、
前記銀行のサーバは顧客マスタを有するものであり、この顧客マスタは、前記第１ユーザの名義とメールアドレスとを含む第１ユーザ情報と、前記第１ユーザが前記銀行に有する第１ユーザ用銀行口座の口座情報と、前記第１ユーザについて前記メールアドレスを使った送金を行うか否かの送金契約に関する情報とを対応付けて格納すると共に、前記第２ユーザの名義を含む第２ユーザ情報と、前記第２ユーザが所定の銀行に有する第２ユーザ用銀行口座の口座情報と、前記第２ユーザについて前記メールアドレスを使った送金を受け取る受金契約に関する情報とを対応付けて格納しているものであり、
この方法は、
前記第１の端末が、前記メールアドレスを前記第２の端末に送信する工程を行い、
前記第２の端末が、前記第１の端末から受信した前記メールアドレスと、前記第１ユーザが支払うべき支払額と、前記第２ユーザ情報や前記第２ユーザ用銀行口座の口座情報に関する第２ユーザ特定情報とを前記銀行サーバに送信する工程を行い、
前記銀行サーバが、
前記第２の端末から受信した前記メールアドレスおよび前記第２ユーザ特定情報を前記顧客マスタに照会し、前記メールアドレスに対応している前記第１ユーザについて前記送金契約の有無を判断すると共に、前記第２ユーザについて前記受金契約の有無を判断する契約有無判断工程と、
前記契約有無判断工程で前記第１ユーザおよび前記第２ユーザについて前記契約が有ると判断されると前記第１ユーザの前記メールアドレスにメールを送信するメール送信工程であって、前記メールは、前記第２ユーザから前記支払額の要求があったことを通知すると共に、前記第１ユーザ情報や前記第１ユーザ用銀行口座の口座情報に関する第１ユーザ特定情報の送信を要求するものである、前記メール送信工程と、
前記第１のユーザから前記第１ユーザ特定情報を受信すると、前記第１ユーザ特定情報が前記顧客マスタ中の前記第１ユーザ情報および／又は前記第１ユーザ用銀行口座の口座情報と対応しているか否かを判断する第１ユーザ情報判断工程と、
前記第１ユーザ情報判断工程で対応していると判断されると、前記第１ユーザ用銀行口座から前記第２ユーザ用銀行口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う送金処理工程と
を行う
ことを特徴とする支払処理方法。
請求項１記載の支払処理方法において、
前記第１の端末は、前記第１ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、
前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであり、
前記第１ユーザ情報判断工程では、前記第１ユーザ特定情報の少なくとも一部として前記暗号化口座情報を受信し復号化する
ことを特徴とする支払処理方法。
請求項１記載の支払処理方法において、
前記第１の端末は、前記第１ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、
前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであると共に、前記顧客マスタに前記第１ユーザのパスワードを格納しているものであり、
前記メール送信工程では、前記第１ユーザ特定情報の送信の要求として、前記第１ユーザが特定のＵＲＬにアクセスすることを要求すると共に、前記第１ユーザが前記第１の端末によって前記特定のＵＲＬにアクセスすると、前記第１の端末の表示装置に前記第１ユーザ特定情報の入力および送信を要求する入力画面を表示させ、
前記第１ユーザ情報判断工程では、
前記第１ユーザが前記入力画面に入力し前記第１の端末から送信される、前記第１ユーザ特定情報の一部としての前記暗号化口座情報を受信する第１の処理と、
前記第１の処理で受信した前記暗号化口座情報を復号化すると共に、復号化した口座情報が前記顧客マスタ中の前記第１ユーザ用銀行口座の口座情報と対応しているか否かを判断する第２の処理と、
前記第２の処理で対応していると判断されると、前記入力画面において前記第１ユーザ特定情報の他の部分として前記パスワードの送信を要求する第３の処理と、
前記第１ユーザが前記入力画面に入力し前記第１の端末から送信される前記パスワードを受信する第４の処理と、
前記第４の処理で受信した前記パスワードが前記顧客マスタ中に格納されている前記第１ユーザの前記パスワードと対応しているか否かを判断する第５の処理と
を行う
ことを特徴とする支払処理方法。
請求項１記載の支払処理方法において、
前記銀行サーバが、
前記メール送信工程の後、前記第１ユーザから前記支払承認と前記第１ユーザ特定情報を受信する迄に所定の時間が経過したことを判断する経過時間判断工程と、
前記経過時間判断工程で前記所定の時間が経過したと判断されると、前記第１ユーザによる前記支払額の支払いが不成立となったことを前記メールアドレスに通知する支払不成立メール送信工程と
をさらに行い、
前記送金処理工程では、前記第１ユーザ情報判断工程で対応していると判断されると共に、前記経過時間判断工程で前記所定の時間が経過していない場合に、前記送金処理を行う
ことを特徴とする支払処理方法。
請求項１記載の支払処理方法において、
前記銀行サーバが、前記送金処理工程が行われた後に、前記送金処理後の前記第１ユーザ用銀行口座の口座情報を含む処理完了通知を前記メールアドレスに送信する口座情報送信工程を行う
ことを特徴とする支払処理方法。
請求項１記載の支払処理方法において、
前記銀行サーバが、前記送金処理工程が行われた後に、前記送金処理後の前記第１ユーザ用銀行口座の口座情報を前記第１の端末の前記表示装置に表示させる口座情報表示工程を行う
ことを特徴とする支払処理方法。
第１ユーザが有する第１の端末および第２ユーザが有する第２の端末と通信回線を介して通信可能であり、前記第１ユーザから第２ユーザへの現金の支払いを処理する銀行サーバであって、
前記第１ユーザの名義とメールアドレスとを含む第１ユーザ情報と、前記第１ユーザが前記銀行に有する第１ユーザ用銀行口座の口座情報と、前記第１ユーザについて前記メールアドレスを使った送金を行うか否かの送金契約に関する情報とを対応付けて格納すると共に、前記第２ユーザの名義を含む第２ユーザ情報と、前記第２ユーザが所定の銀行に有する第２ユーザ用銀行口座の口座情報と、前記第２ユーザについて前記メールアドレスを使った送金を受け取る受金契約に関する情報とを対応付けて格納している顧客マスタと、
前記第２の端末が第１の端末から受け取り送信する前記第１ユーザの前記メールアドレスを受信すると共に、受信した前記メールアドレスを前記顧客マスタに照会し、前記メールアドレスに対応している前記第１ユーザについて前記送金契約の有無を判断する第１ユーザ契約有無判断手段と、
前記第２の端末が送信する情報であって前記第２ユーザ情報や前記第２ユーザ用銀行口座の口座情報に関する第２ユーザ特定情報を受信し、受信した前記第２ユーザ特定情報について前記受金契約の有無を判断する第２ユーザ契約有無判断工程と、
前記第１および第２ユーザ契約判断手段で前記第１ユーザおよび前記第２ユーザについて前記契約が有ると判断されると前記第１ユーザの前記メールアドレスにメールを送信するメール送信手段であって、前記メールは、前記第２ユーザから前記支払額の要求があったことを通知すると共に、前記第１ユーザ情報や前記第１ユーザ用銀行口座の口座情報に関する第１ユーザ特定情報の送信を要求するものである、前記メール送信手段と、
前記第１のユーザから前記第１ユーザ特定情報を受信すると、前記第１ユーザ特定情報が前記顧客マスタ中の前記第１ユーザ情報および／又は前記第１ユーザ用銀行口座の口座情報と対応しているか否かを判断する第１ユーザ情報判断手段と、
前記第１ユーザ情報判断手段で対応していると判断されると、前記第１ユーザ用銀行口座から前記第２ユーザ用銀行口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う送金処理手段と
を有する
ことを特徴とする銀行サーバ。
請求項７記載の銀行サーバにおいて、
前記第１の端末は、前記第１ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、
前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであり、
前記第１ユーザ情報判断手段は、前記第１ユーザ特定情報の少なくとも一部として前記暗号化口座情報を受信し復号化するものである
ことを特徴とする銀行サーバ。
請求項７記載の銀行サーバにおいて、
前記第１の端末は、前記第１ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、
前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであると共に、前記顧客マスタに前記第１ユーザのパスワードを格納しているものであり、
前記メール送信手段は、前記第１ユーザ特定情報の送信の要求として、前記第１ユーザが特定のＵＲＬにアクセスすることを要求すると共に、前記第１ユーザが前記第１の端末によって前記特定のＵＲＬにアクセスすると、前記第１の端末の表示装置に前記第１ユーザ特定情報の入力および送信を要求する入力画面を表示させるものであり、
前記第１ユーザ情報判断手段は、
前記第１ユーザが前記入力画面に入力し前記第１の端末から送信される、前記第１ユーザ特定情報の一部としての前記暗号化口座情報を受信する第１の処理と、
前記第１の処理で受信した前記暗号化口座情報を復号化すると共に復号化した口座情報が前記顧客マスタ中の前記第１ユーザ用銀行口座の口座情報と対応しているか否かを判断する第２の処理と、
前記第２の処理で対応していると判断されると、前記入力画面において前記第１ユーザ特定情報の他の部分として前記第１ユーザ用銀行口座のパスワードの入力および送信を要求する第３の処理と、
前記第１ユーザが前記入力画面に入力し前記第１の端末から送信される前記パスワードの情報を受信する第４の処理と、
前記第４の処理で受信した前記パスワードが前記顧客マスタ中に格納されている前記第１ユーザの前記パスワードと対応しているか否かを判断する第５の処理と
を行うものである
ことを特徴とする銀行サーバ。
請求項７記載の銀行サーバにおいて、
前記メール送信手段による前記メールの送信の後、前記第１ユーザから前記第１ユーザ特定情報を受信する迄に所定の時間が経過したことを判断する経過時間判断手段と、
前記経過時間判断手段で前記所定の時間が経過したと判断されると、前記第１ユーザによる前記支払額の支払いが不成立となったことを前記メールアドレスに通知する支払不成立メール送信手段と
をさらに有し、
前記送金処理手段では、前記第１ユーザ情報判断手段で対応していると判断されると共に、前記経過時間判断手段で前記所定の時間が経過していないと判断された場合に、前記送金処理を行う
ことを特徴とする銀行サーバ。
請求項７記載の銀行サーバにおいて、
前記送金処理手段による送信処理の後に、前記送金処理後の前記第１ユーザ用銀行口座の口座情報を含む処理完了通知を前記メールアドレスに送信する口座情報送信手段をさらに有する
ことを特徴とする銀行サーバ。
請求項７記載の銀行サーバにおいて、
前記送金処理手段による送信処理の後に、前記送金処理後の前記第１ユーザ用銀行口座の口座情報を前記第１の端末の前記表示装置に表示させる口座情報表示手段をさらに有する
ことを特徴とする銀行サーバ。