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

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

Info

Publication number
JP5918995B2
JP5918995B2 JP2011286340A JP2011286340A JP5918995B2 JP 5918995 B2 JP5918995 B2 JP 5918995B2 JP 2011286340 A JP2011286340 A JP 2011286340A JP 2011286340 A JP2011286340 A JP 2011286340A JP 5918995 B2 JP5918995 B2 JP 5918995B2
Authority
JP
Japan
Prior art keywords
user
information
account
bank
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011286340A
Other languages
English (en)
Other versions
JP2013134708A (ja
Inventor
瑶子 三田
瑶子 三田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sumitomo Mitsui Banking Corp
Original Assignee
Sumitomo Mitsui Banking Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sumitomo Mitsui Banking Corp filed Critical Sumitomo Mitsui Banking Corp
Priority to JP2011286340A priority Critical patent/JP5918995B2/ja
Publication of JP2013134708A publication Critical patent/JP2013134708A/ja
Application granted granted Critical
Publication of JP5918995B2 publication Critical patent/JP5918995B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

あるユーザから他のユーザへの現金の支払いを処理する支払処理方法およびその支払処理に用いるサーバに関し、例えば、インターネット上で商品の販売、サービスの提供等を行っている販売者・提供者に対して前記商品又はサービスの購入を行う購入者が現金を支払う場合の支払処理方法およびその支払処理に用いるサーバに関する。
従来から、現実の店舗における商品やサービスに対する対価の支払いは、現金、クレジットカード、デビットカード決済機能付きのキャッシュカード等により行われている。また、近年では、インターネット上での商品の販売やサービスの提供がより広まってきており、その現金支払方法として、クレジットカード決済、コンビニエンスストアや郵便局での決済等が使われている。
具体例として、商品を購入する者がPC(パーソナルコンピュータ)を使ってインターネット上の商品販売サイトにアクセスし、購入した商品の代金支払方法としてクレジットカード決済を選択すると、前記PCの画面にクレジットカードのカード番号、有効期限、セキュリティーコード等を入力する画面が表示される。そして、商品の購入者がカード番号等の情報を入力して画面上の支払ボタンを操作すると、当該入力情報および商品の代金額が商品販売サイトのサーバに送信されると共に、前記商品販売サイトのサーバが前記入力情報に基づいてカード会社に前記カード情報の認証を行う。そして、前記カード情報が認証されると、前記カード会社から前記商品販売サイトの運営会社に前記商品の代金が支払われる。
また、インターネット上での商品購入の決済にデビットカード決済機能付きのキャッシュカードが用いられることもあった。この場合、商品を購入する者がデビットカード決済を選択すると、前記PCの画面にキャッシュカードのカード番号、届出の暗証番号等を入力する画面が表示される。そして、商品の購入者がカード番号等の情報を入力して画面上の支払ボタンを操作すると、入力情報および商品の代金額が商品販売サイトのサーバに送信されると共に、前記商品販売サイトのサーバが前記入力情報に基づいて当該キャッシュカードを発行した銀行のサーバに認証を行う。当該銀行のサーバで前記入力情報が認証されると、前記代金額が前記購入者の銀行口座から引き落とされると共に、前記代金額が前記商品販売サイトの運営会社に支払われる。
特開2008−264529号公報 特開2011−118563号公報
前述のように、店舗に出掛ける必要がなく、カード番号等の情報の入力だけで代金の支払いを行うことができるので、利用者にとってインターネット上の商品販売サイトやサービス提供サイトは大変便利である。このため、インターネット上において商品販売やサービス提供を行う業者が近年さらに増えてきている。
しかしながら、クレジットカードやキャッシュカードのカード番号等の情報をインターネット経由で送信することは、その情報の漏洩を招来することなので、情報漏洩を恐れてクレジットカードやキャッシュカードを使用しない者もいる。特に、キャッシュカードのカード情報が他人に悪用されると、カードの持ち主の銀行口座から直接に現金が引き出され、他の引き落とし、例えば住宅ローンの引き落とし等に影響を与える場合がある。このため、銀行口座に直接関連するキャッシュカードのカード番号等の取り扱いは、クレジットカードのカード番号等に比べてより厳重にする必要があると言える。
一方、デビットカード決済は、実際に銀行口座にある残高の範囲内で支払いをするものである。また、商品の代金額が購入者の銀行口座の残高から引き落とされ、その代金額が前記商品販売サイトの運営会社に支払われるものである。このため、代金支払いの流れがシンプルであり、代金の支払経路において代金未収のリスクを抱える者を無くすことが可能である。
これに対し、クレジットカード決済の場合は、購入者の信用の範囲内でクレジットカード会社が商品の購入代金を肩代わりするので、クレジットカード会社が代金の支払経路において代金未収のリスクを抱える者となる。そして、前記リスクが前記商品販売サイトの運営会社が支払う手数料に反映される場合もあり、購入者がクレジットカード会社に支払いを行う際の金利に反映される場合もある。このため、支払経路におけるリスクがある分だけ前記商品販売サイトの運営会社と購入者の双方の金銭的負担が増える可能性がある。
本発明は、このような課題を解決するためになされたもので、代金の支払経路において発生する代金未収のリスクを無くすことが可能であり、しかもカード情報等の漏洩による被害のリスクも軽減することのできる支払処理方法およびその支払処理に用いる銀行サーバを提供することにある。
上記目的を達成するため、本発明の主要な観点によれば、第1ユーザが有する第1の端末と、第2ユーザが有する第2の端末と、前記第1の端末および前記第2の端末と通信回線を介して通信可能な銀行のサーバとを用いて、前記第1ユーザから第2ユーザへの現金の支払いを処理する支払処理方法であって、前記銀行のサーバは顧客マスタを有するものであり、この顧客マスタは、前記第1ユーザの名義とメールアドレスとを含む第1ユーザ情報と、前記第1ユーザが前記銀行に有する第1ユーザ用銀行口座の口座情報と、前記第1ユーザについて前記メールアドレスを使った送金を行うか否かの送金契約に関する情報とを対応付けて格納すると共に、前記第2ユーザの名義を含む第2ユーザ情報と、前記第2ユーザが所定の銀行に有する第2ユーザ用銀行口座の口座情報と、前記第2ユーザについて前記メールアドレスを使った送金を受け取る受金契約に関する情報とを対応付けて格納しているものであり、この方法は、前記第1の端末が、前記メールアドレスを前記第2の端末に送信する工程を行い、前記第2の端末が、前記第1の端末から受信した前記メールアドレスと、前記第1ユーザが支払うべき支払額と、前記第2ユーザ情報や前記第2ユーザ用銀行口座の口座情報に関する第2ユーザ特定情報とを前記銀行サーバに送信する工程を行い、前記銀行サーバが、前記第2の端末から受信した前記メールアドレスおよび前記第2ユーザ特定情報を前記顧客マスタに照会し、前記メールアドレスに対応している前記第1ユーザについて前記送金契約の有無を判断すると共に、前記第2ユーザについて前記受金契約の有無を判断する契約有無判断工程と、前記契約有無判断工程で前記第1ユーザおよび前記第2ユーザについて前記契約が有ると判断されると前記第1ユーザの前記メールアドレスにメールを送信するメール送信工程であって、前記メールは、前記第2ユーザから前記支払額の要求があったことを通知すると共に、前記第1ユーザ情報や前記第1ユーザ用銀行口座の口座情報に関する第1ユーザ特定情報の送信を要求するものである、前記メール送信工程と、前記第1のユーザから前記第1ユーザ特定情報を受信すると、前記第1ユーザ特定情報が前記顧客マスタ中の前記第1ユーザ情報および/又は前記第1ユーザ用銀行口座の口座情報と対応しているか否かを判断する第1ユーザ情報判断工程と、前記第1ユーザ情報判断工程で対応していると判断されると、前記第1ユーザ用銀行口座から前記第2ユーザ用銀行口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う送金処理工程とを行うことを特徴とする支払処理方法が提供される。
また、本発明の他の主要な観点によれば、第1ユーザが有する第1の端末および第2ユーザが有する第2の端末と通信回線を介して通信可能であり、前記第1ユーザから第2ユーザへの現金の支払いを処理する銀行サーバであって、前記第1ユーザの名義とメールアドレスとを含む第1ユーザ情報と、前記第1ユーザが前記銀行に有する第1ユーザ用銀行口座の口座情報と、前記第1ユーザについて前記メールアドレスを使った送金を行うか否かの送金契約に関する情報とを対応付けて格納すると共に、前記第2ユーザの名義を含む第2ユーザ情報と、前記第2ユーザが所定の銀行に有する第2ユーザ用銀行口座の口座情報と、前記第2ユーザについて前記メールアドレスを使った送金を受け取る受金契約に関する情報とを対応付けて格納している顧客マスタと、前記第2の端末が第1の端末から受け取り送信する前記第1ユーザの前記メールアドレスを受信すると共に、受信した前記メールアドレスを前記顧客マスタに照会し、前記メールアドレスに対応している前記第1ユーザについて前記送金契約の有無を判断する第1ユーザ契約有無判断手段と、前記第2の端末が送信する情報であって前記第2ユーザ情報や前記第2ユーザ用銀行口座の口座情報に関する第2ユーザ特定情報を受信し、受信した前記第2ユーザ特定情報について前記受金契約の有無を判断する第2ユーザ契約有無判断工程と、前記第1および第2ユーザ契約判断手段で前記第1ユーザおよび前記第2ユーザについて前記契約が有ると判断されると前記第1ユーザの前記メールアドレスにメールを送信するメール送信手段であって、前記メールは、前記第2ユーザから前記支払額の要求があったことを通知すると共に、前記第1ユーザ情報や前記第1ユーザ用銀行口座の口座情報に関する第1ユーザ特定情報の送信を要求するものである、前記メール送信手段と、前記第1のユーザから前記第1ユーザ特定情報を受信すると、前記第1ユーザ特定情報が前記顧客マスタ中の前記第1ユーザ情報および/又は前記第1ユーザ用銀行口座の口座情報と対応しているか否かを判断する第1ユーザ情報判断手段と、前記第1ユーザ情報判断手段で対応していると判断されると、前記第1ユーザ用銀行口座から前記第2ユーザ用銀行口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う送金処理手段とを有することを特徴とする銀行サーバが提供される。
例えば、本発明では、第1ユーザが購入者であり、第2ユーザがインターネット上の商品販売サイトで商品を販売する販売者である場合、前記購入者が有する第1の端末から前記販売者が有する第2の端末に購入者のメールアドレスが送信され、そのメールアドレスが第2の端末から銀行のサーバに送信される。この時、第2の端末からは、前記購入者が支払うべき支払額と、前記販売者を特定できる第2ユーザ特定情報も送信される。一方、銀行のサーバでは、受信した前記購入者のメールアドレスおよび第2ユーザ特定情報を顧客マスタに照会し、前記購入者および前記販売者について送金契約や受金契約の有無を判断する。そして、双方とも契約があると判断されると、銀行のサーバは前記購入者のメールアドレスにメールを送信する。このメールでは、前記販売者から前記支払額の支払要求があったことを前記購入者に通知し、その支払承認と、前記購入者を特定することのできる情報、例えば前記銀行における口座番号等を含む第1ユーザ特定情報の送信を前記購入者に要求する。そして、銀行のサーバは、受信した第1ユーザ特定情報が顧客マスタ中の前記購入者の情報及び/又は前記購入者の銀行口座の口座情報と対応しているか否かを判断し、対応していると判断されると、前記購入者の銀行口座から前記販売者の銀行口座への前記支払額に対応した額の送金処理を行う。
このように、前記購入者から前記販売者に前記購入者のカード情報、銀行口座の情報等を送信することなく、前記購入者から前記販売者に現金の支払いを行うことができるので、代金の支払時にカード情報や銀行口座の情報等の漏洩を防止することができる。
また、銀行のサーバは、受信した第1ユーザ特定情報が顧客マスタ中の前記購入者の情報及び/又は前記購入者の銀行口座の口座情報と対応していると判断されると、前記購入者の銀行口座から前記販売者の銀行口座への前記支払額に対応した額の送金処理を行うので、前記販売者は即時又は比較的短期間で前記支払額に対応した現金を受け取ることができる。また、購入者の銀行口座から販売者の銀行口座に直接的に現金の支払いが行われるので、代金の支払経路において代金未収となる者が発生するリスクを無くすことができる。
また、本発明の実施形態によれば、前記第1の端末は、前記第1ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであり、前記第1ユーザ情報判断工程では、前記第1ユーザ特定情報の少なくとも一部として前記暗号化口座情報を受信し復号化することを特徴とする支払処理方法が提供される。
また、本発明の他の実施形態によれば、前記第1の端末は、前記第1ユーザ用銀行口座の口座情報に関する情報を暗号化した暗号化口座情報を格納しているものであり、前記銀行サーバは、前記暗号化口座情報を復号化するための秘密鍵を格納しているものであると共に、前記顧客マスタに前記第1ユーザのパスワードを格納しているものであり、前記メール送信工程では、前記第1ユーザ特定情報の送信の要求として、前記第1ユーザが特定のURLにアクセスすることを要求すると共に、前記第1ユーザが前記第1の端末によって前記特定のURLにアクセスすると、前記第1の端末の表示装置に前記第1ユーザ特定情報の入力および送信を要求する入力画面を表示させ、前記第1ユーザ情報判断工程では、前記第1ユーザが前記入力画面に入力し前記第1の端末から送信される、前記第1ユーザ特定情報の一部としての前記暗号化口座情報を受信する第1の処理と、前記第1の処理で受信した前記暗号化口座情報を復号化すると共に、復号化した口座情報が前記顧客マスタ中の前記第1ユーザ用銀行口座の口座情報と対応しているか否かを判断する第2の処理と、前記第2の処理で対応していると判断されると、前記入力画面において前記第1ユーザ特定情報の他の部分として前記パスワードの送信を要求する第3の処理と、前記第1ユーザが前記入力画面に入力し前記第1の端末から送信される前記パスワードを受信する第4の処理と、前記第4の処理で受信した前記パスワードが前記顧客マスタ中に格納されている前記第1ユーザの前記パスワードと対応しているか否かを判断する第5の処理とを行うことを特徴とする支払処理方法が提供される。
また、本発明のさらに他の実施形態によれば、前記銀行サーバが、前記メール送信工程の後、前記第1ユーザから前記支払承認と前記第1ユーザ特定情報を受信する迄に所定の時間が経過したことを判断する経過時間判断工程と、前記経過時間判断工程で前記所定の時間が経過したと判断されると、前記第1ユーザによる前記支払額の支払いが不成立となったことを前記メールアドレスに通知する支払不成立メール送信工程とをさらに行い、前記送金処理工程では、前記第1ユーザ情報判断工程で対応していると判断されると共に、前記経過時間判断工程で前記所定の時間が経過していない場合に、前記送金処理を行うことを特徴とする支払処理方法が提供される。
また、本発明のさらに他の実施形態によれば、前記銀行サーバが、前記送金処理工程が行われた後に、前記送金処理後の前記第1ユーザ用銀行口座の口座情報を含む処理完了通知を前記メールアドレスに送信する口座情報送信工程を行うことを特徴とする支払処理方法が提供される。
また、本発明のさらに他の実施形態によれば、前記銀行サーバが、前記送金処理工程が行われた後に、前記送金処理後の前記第1ユーザ用銀行口座の口座情報を前記第1の端末の前記表示装置に表示させる口座情報表示工程を行うことを特徴とする支払処理方法が提供される。
本発明によれば、例えば購入者の銀行口座から販売者の銀行口座に直接的に代金分の現金が送金されるので、購入者から販売者への代金の支払経路において代金未収となる者が発生せず、代金未収となるリスクに対する前記購入者又は前記販売者の金銭的負担を取り除くことができる。また、カード情報等の漏洩による被害のリスクも低減されるので、前記購入者はインターネット上における支払いをより安全に行うことができる。
なお、この発明の更なる他の特徴と顕著な効果は次の発明を実施するための最良の形態の項に記載された実施形態及び図面を参照することによって当業者に理解される。
本発明の第一実施形態に係る支払処理システムの概略構成を示す図 銀行サーバの概略構成を示す図 顧客マスタの例 第1の端末および銀行サーバにおける処理を示すフローチャート 第1の端末の表示装置の表示画面の例 第1の端末、第2の端末および銀行サーバにおける処理を示すフローチャート 販売情報の例 支払処理データの例 第1の端末、第2の端末および銀行サーバにおける処理を示すフローチャート 第1の端末の表示装置の表示画面の例
以下、本発明の実施形態を図面に基づき説明する。
図1は本発明の第1実施形態に係る現金支払システムの概略構成を示す図である。この現金支払システムは、第1ユーザ(商品やサービスの購入者)が有する第1の端末100と、第2ユーザ(商品の販売者やサービスの提供者)が有する第2の端末200と、ある銀行に備えられ、第1の端末100および第2の端末200と通信回線を介して通信可能な銀行サーバ300とを有する。第1および第2の端末100,200はデスクトップ型やラップトップ型のパーソナルコンピュータ(PC)であっても良く、サーバ端末であっても良く、携帯情報端末(PDA)やPCと同等の機能を備えた携帯電話であっても良く、他の公知のコンピュータ装置であっても良い。本実施形態では第1の端末100はPCと同等の機能を備えた携帯電話であり、第2の端末200はインターネット上の商品販売サイトを提供するサーバ端末である。
第1の端末100はCPU、RAM等のコンピュータとしての通常の構成を備えている。また、第1の端末100は、液晶ディスプレイ等の表示装置110と、移動電話網やインターネット網等を使った通信用の通信プロトコルスタックとが含まれた通信インターフェースを有する通信部120と、前記銀行に第1ユーザが有する銀行口座の口座情報を格納している口座情報格納部130と、プログラムを格納するためのプログラム格納部140とを有する。プログラム格納部140には、第1の端末100に所定の動作を行わせる第1ユーザ情報送信処理部141が格納されている。第1ユーザ情報送信処理部141の機能については第1の端末100、第2の端末200および銀行サーバ300が行う処理の例(図4、図6参照)に沿って以下に説明する。
第2の端末200はCPU、RAM等のコンピュータとしての通常の構成を備えている。また、第2の端末200は、コネクタと、インターネット網等を使った通信用の通信プロトコルスタックとが含まれた通信インターフェースを有する通信部210と、口座情報格納部220と、各種プログラムを格納するためのプログラム格納部230と、販売情報格納部240とを有する。プログラム格納部230には、コンピュータにそれぞれ所定の動作を行わせる販売用画面表示処理部231、決済画面表示処理部232、決済要求送信処理部233、販売情報格納処理部234とが格納されている。これらの機能については第1の端末100、第2の端末200および銀行サーバ300が行う処理の例(図4、図6参照)に沿って以下に説明する。
図2は本実施形態の銀行サーバ300の概略構成を示す図である。この銀行サーバ300は、CPU310と、RAM320と、液晶ディスプレイ等の表示装置330と、コネクタと、インターネット網等を使った通信用の通信プロトコルスタックとが含まれた通信インターフェースを有する通信部340と、顧客マスタ351を格納している顧客マスタ格納部350と、口座データ格納部360と、それぞれ銀行サーバ300に所定の動作を行わせる各種プログラムを格納するためのプログラム格納部370と、e−mailを使った支払処理のデータを格納するための支払処理データ格納部380とを有する。顧客マスタ351は、例えば図3に示すように、この銀行における顧客情報(名義、住所、電話番号等のユーザ情報)を支店コード、口座番号等と対応付けて格納しているものである。本実施形態では、顧客マスタ格納部350と口座データ格納部360は勘定系システムの一部である。顧客マスタ351は、e−mailアドレスを使った支払いおよびその支払いの受け取りを行うか否かの契約についての情報を格納している。例えば、第1ユーザはe−mailアドレスを使った支払いを行う契約(送金契約)を有し、第2ユーザはe−mailアドレスを使った受け取りを行う契約(受金契約)を有し、ユーザCは前記送金契約および前記受金契約を有する。口座データ格納部360は、口座番号ごとに口座残高や銀行取引の履歴を格納するものである。
この銀行サーバ300は、プログラム格納部370に、コンピュータにそれぞれ所定の動作を行わせる口座開設処理部371と、契約有無判断処理部372と、メール送信処理部373と、情報入力画面提供処理部374と、第1ユーザ情報判断処理部375と、残額判断処理部376と、送金処理部377と、経過時間判断処理部378とが格納されている。これらの機能については第1の端末100、第2の端末200および銀行サーバ300が行う処理の例(図4、図6参照)に沿って以下に説明する。
ここで、第1ユーザは、この銀行で銀行口座を開設する際や、開設後の任意の時に、前記送金契約や前記受金契約をすることができる。例として、第1ユーザがこの銀行で銀行口座を開設する場合の処理について図4のフローチャートに沿って説明する。
先ず、第1ユーザが第1の端末100により銀行サーバ300が提供するウェッブページにアクセスし、口座開設の要求を行うと(ステップS1)、銀行サーバ300の口座開設処理部371および第1の端末100のブラウザソフト等により、第1の端末100の表示装置110に口座開設用の画面が表示される(ステップS2)。この口座開設用の画面は口座開設に必要な情報の入力および送信をユーザに求めるものである。第1ユーザが前記口座開設用の画面に名義、住所、電話番号等の個人情報を入力し送信すると(ステップS3)、銀行サーバ300が前記個人情報を受け付け、顧客マスタ格納部350やその他の格納部に格納する(ステップS4)。続いて、銀行サーバ300が口座開設処理部371により、第1の端末100の表示装置110に図5に示すような本願の現金支払サービスの契約の要否と、契約をする場合はパスワードを入力する契約設定画面を表示させる(ステップS5)。この契約設定画面では、前記送金契約をするか否かおよび前記受金契約を行うか否かをユーザが入力するようになっている。本実施形態では、第1ユーザは、何れか一方だけ契約すること、両方とも契約すること、又は両方とも契約しないことを選択できる。第1ユーザが前記送金契約をすることについて前記契約選択画面で入力しパスワードと共に送信すると(ステップS6)、銀行サーバ300が前記情報を受け付け、顧客マスタ格納部350やその他の格納部に格納する(ステップS7)。
続いて、銀行は第1ユーザに本人確認書類の写しの送付、暗証番号の設定等を求める書類を郵送等で送り、第1ユーザは本人確認書類の写しや暗証番号を記載した書類等を銀行に送る。銀行において前記本人確認書類を用いた本人確認が完了し、その結果と前記暗証番号が銀行サーバ300に入力されると(ステップS8)、銀行サーバ300は第1ユーザに対して銀行口座を開設し、口座番号を設定する(ステップS9)。そして、銀行サーバ300は、顧客マスタ351に、前記個人情報と、この個人情報に紐付けて支店コード、口座番号、暗証番号、前記契約の有無の情報、前記パスワード等を格納する(ステップS10)。
続いて、銀行サーバ300は、口座開設処理部371により、第1ユーザの銀行口座の口座情報(支店コード、口座番号等)を暗号化した暗号化口座情報を作成すると共に(ステップS11)、その暗号化口座情報を第1の端末100に送信し(ステップS12)、第1の端末100は受信した暗号化口座情報を口座情報格納部130に格納する(ステップS13)。若しくは、銀行側で前記暗号化口座情報を記録媒体に格納した後、その記録媒体を第1ユーザに郵送し、第1ユーザが前記記録媒体内の暗号化口座情報を第1の端末100の口座情報格納部130に格納する場合もある。さらに他の方法として、銀行サーバ300が第1の端末100に口座情報を暗号化するためのアプリケーション等を提供し、そのアプリケーションを用いて第1の端末100が口座情報を暗号化し、第1の端末100が暗号化口座情報を口座情報格納部130に格納する場合もある。一方、銀行サーバ300は前記暗号化口座情報を復号化するための秘密鍵を顧客マスタ格納部350等に格納している。この秘密鍵を銀行サーバ300のみが有していることが好ましい。
インターネット上の商品販売サイトを運営する販売者としての第2ユーザも、この銀行で銀行口座を開設する際や、開設後の任意の時に、前記送金契約や前記受金契約をすることができ、この場合も前述のステップS1〜S13と類似した処理が行われることになる。ここで、銀行サーバ300の顧客マスタ351は、第2ユーザの情報と共に、第2ユーザが運営する商品販売サイトの情報を格納することも可能である。
続いて、第1ユーザが第1の端末100を使って第2ユーザが運営するインターネット上の商品販売サイトにアクセスし、商品Zを購入しその代金を支払う場合について、図6のフローチャートに沿って説明する。
先ず、第1ユーザが第1の端末100により前記商品販売サイトにアクセスし商品販売用画面の表示を要求すると(ステップS21)、第2の端末200の販売用画面表示処理部231および第1の端末100のブラウザソフト等により、第1の端末100の表示装置110に商品販売サイトの画面が表示される(ステップS22)。第1ユーザが商品Zの購入を決定し、第1の端末100上で商品Zを購入するための操作を行うことにより、商品Zの購入意思が第2の端末200に送信されると(ステップS23)、第2の端末200の決済画面表示処理部232および第1の端末100のブラウザソフト等により、第1の端末100の表示装置110に商品Zを購入するために第1ユーザが支払うべき支払額が表示されると共に、決済方法を選択させる決済方法選択画面が表示される(ステップS24)。例えば、表示装置110に、クレジットカード決済、コンビニエンスストアや郵便局での決済、本願の決済の何れかを選択させる画面が表示される。
ステップS24で本願の決済が選択されると、そのことが第2の端末200に送信され(ステップS25)、決済画面表示処理部232および第1の端末100のブラウザソフト等により、第1の端末100の表示装置110に第1ユーザのメールアドレスの入力および送信を要求するメールアドレス要求画面が表示される(ステップS26)。第1ユーザがメールアドレスを入力して第2の端末200に送信すると(ステップS27)、第2の端末200は、決済要求送信処理部233により、受信した第1ユーザのメールアドレスと、前記支払額と、商品Zの販売者である第2ユーザを特定するために必要な第2ユーザ特定情報とを銀行サーバ300に送信する(ステップS28)。なお、第2ユーザ特定情報として、第2ユーザのユーザ情報(第2ユーザの電話番号等の情報や前記商品販売サイトに関する情報)や第2ユーザの銀行口座の口座情報に関する情報(前記暗号化口座情報であっても良い)が送信される。
ここで、第2の端末200では、本願の決済での支払いが行われる場合、前記販売情報格納処理部234により、商品販売サイトで販売された商品についての請求額(前記支払額又は前記支払額から所定の手数料を差し引いた額)と、その請求額が入金される口座の口座情報と、支払う者(購入者)のメールアドレスとを対応付けた販売情報を作成し(図7参照)、その販売情報を販売情報格納部240に格納する。
続いて、銀行サーバ300は、契約有無判断部372により、前記第2の端末200から受信した第1ユーザのメールアドレスを顧客マスタ351に照会し、このメールアドレスに対応している第1ユーザについて前記送金契約の有無を判断する(ステップS29)。また、銀行サーバ300は、契約有無判断部372により、前記第2の端末から受信した第2ユーザの第2ユーザ特定情報を顧客マスタ351に照会し、第2ユーザについて前記受金契約の有無を判断する(ステップS30)。
続いて、ステップS29およびS30で第1および第2ユーザ双方の契約があると判断されると、銀行サーバ300は、支払処理データ格納部380に、図8に示すような支払処理データを作成する。また、銀行サーバ300は、メール送信処理部273により、第1ユーザの前記メールアドレスにメールを送信する(ステップS31)。このメールは、第2ユーザから商品Zの購入につき前記支払額の要求があったことを通知し、当該支払額の支払承認と、購入者である第1ユーザを特定するために第1ユーザ特定情報の送信とを要求するものである。前記支払承認は明示的なものであっても良く、第1ユーザが前記第1ユーザ特定情報を送信したことをもって支払を承認したとみなすことも可能である。第1ユーザ特定情報としては、第1ユーザのユーザ情報(前記個人情報等の情報)や第1ユーザの銀行口座の口座情報に関する情報(前記暗号化口座情報であっても良い)の送信が要求される。本実施形態では、第1ユーザ特定情報として、第1ユーザの前記暗号化口座情報のメールでの送信が要求される。この時、前記メールは、前記情報を前記銀行が有する特定のメールアドレスに送信することを第1ユーザに要求するか、前記メールに対して返信することを要求する。
第1ユーザは、ステップS31で銀行サーバ300から上記メールを受信すると、第1の端末100の口座情報格納部130に格納されている暗号化口座情報をメールで銀行サーバ300に送信し(ステップS32)、銀行サーバ300は、第1ユーザ情報判断処理部375により、第1ユーザから受信した暗号化口座情報を前記秘密鍵によって復号化し、復号化した口座情報が顧客マスタ351に格納されている第1ユーザの口座情報と対応しているか否かを判断する(ステップS33)。ここで、第1ユーザ情報判断処理部375は、ステップS32によって送信されるメールの内容を自動的に確認し、その中に前記暗号化口座情報が含まれている場合、ステップS33を自動的に行うようになっている。続いて、銀行サーバ300は、残額判断処理部376により、第1ユーザの口座残高が前記支払額以上であるか否かを判断する(ステップ34)。
続いて、ステップS33で対応していると判断され、ステップS34で残高があると判断されると、銀行サーバ300は、メール送信処理部273により、第1ユーザの前記メールアドレスにメールをさらに送信する(ステップS35)。このメールは、第1ユーザに更なる第1ユーザ特定情報として前記パスワードの送信を要求するものであり、このメールにはパスワードを入力する画面を表示するためのURLが記載されている。第1ユーザがメールに記載されたURLにアクセスすると(ステップS36)、銀行サーバ300の情報入力画面提供処理部374および第1ユーザの端末のブラウザソフト等により、第1ユーザの端末に前記パスワードを入力および送信するための画面が表示される(ステップS37)。第1ユーザが前記パスワードの入力および送信を行うと(ステップS38)、銀行サーバ300は第1ユーザ情報判断処理部375により、送信された前記パスワードが顧客マスタ351に格納されている第1ユーザのパスワードと対応しているか否かを判断する(ステップS39)。
続いて、ステップS33およびS39で対応していると判断され、ステップS34で残高があると判断されると、銀行サーバ300は、前記第1ユーザの口座から第2ユーザの口座への前記支払額又は前記支払額から所定の手数料を差し引いた額の送金処理を行う(ステップS40)。具体的には、前記第1ユーザの口座から前記支払額を減額し、前記第2ユーザの口座を前記支払額又は前記支払額から前記所定の手数料を差し引いた額だけ増額する。
続いて、銀行サーバ300は、送金処理が終了したことを、顧客マスタ351に登録されている第2ユーザのメールアドレスにメール送信する(ステップS41)。このメールの内容には、前記支払額と、支払日と、支払者のメールアドレス、つまり第1ユーザのメールアドレスが含まれている。第2の端末200の販売情報格納処理部234は第2ユーザの前記メールアドレス宛のメールの内容を全て自動的に確認するように設定されており、その内容に、販売情報格納部230に格納されている各販売情報の請求額(支払額)および購入者メールアドレスに対応するものがある場合、図7に示すように、その販売情報の支払完了受信日の欄にメールの受信日を格納する。
一方、銀行サーバ300は、送金処理が終了したことと、送金処理後の第1ユーザの口座情報を、顧客マスタ351に登録されている第1ユーザのメールアドレスにもメール送信する(ステップS42)。これにより、第1ユーザは支払いが完了したことや、支払いの後の口座残高等を即座に知ることができる。尚、このメールの内容にURLを含め、第1ユーザがこのURLにアクセスすると、銀行サーバ300および第1の端末100のブラウザソフト等により第1の端末100の表示装置110に第1ユーザの口座情報が表示されるように構成することも可能である。
尚、銀行サーバ300は、経過時間判断処理部378により、ステップS31やステップS35においてメールを送信する際に、メールを送信した日と、それに対する保留期限を設定し、それらを支払処理データ格納部380の支払処理データに追加する。そして、銀行サーバ300は、経過時間判断処理部378により、前記ステップS31や前記ステップS35においてメールを送信した後に、前記ステップS32の暗号化口座情報の送信や、前記ステップS36以降が行われない状態で、前記保留期限が経過した場合、当該支払処理を不成立扱いとする。また、不成立になったことと、その支払処理の支払額、購入者である第1ユーザのメールアドレス等を販売者である第2ユーザおよび購入者である第1ユーザにメール送信する。この第1ユーザおよび第2ユーザへのメール送信に用いるメールアドレスとして、顧客マスタ351に格納されているものを用いることが可能である。また、第2の端末200は販売情報格納処理部234によって第2ユーザの前記メールアドレス宛のメールの内容を全て自動的に確認するように設定されており、その内容に、販売情報格納部230に格納されている各販売情報の請求額(支払額)および購入者メールアドレスに対応するものがある場合、その販売情報に支払いが不成立である旨を格納する。そして、ある支払処理が不成立扱いとなった場合は、その支払処理についてステップS33以降の処理又はステップS37以降の処理は行われない。
このように、本実施形態によれば、購入者である第1ユーザが有する第1の端末100から販売者である第2ユーザが有する第2の端末200に第1ユーザのメールアドレスが送信され、そのメールアドレスが第2の端末200から銀行サーバ300に送信される。この時、第2の端末200からは、第1ユーザが支払うべき支払額と、販売者である第2ユーザを特定できる第2ユーザ特定情報も送信される。一方、銀行サーバ300では、受信した第1ユーザのメールアドレスおよび第2ユーザ特定情報を顧客マスタ351に照会し、購入者である第1ユーザおよび販売者である第2ユーザについて送金契約や受金契約の有無を判断する。そして、双方とも契約があると判断されると、銀行サーバ300は購入者である第1ユーザのメールアドレスにメールを送信する。このメールでは、販売者である第2ユーザから前記支払額の支払要求があったことを第1ユーザに通知し、その支払承認と、購入者である第1ユーザを特定することのできる情報、例えばこの銀行における口座番号等を含む第1ユーザ特定情報の送信を第1ユーザに要求する。そして、銀行サーバ300は、受信した第1ユーザ特定情報が顧客マスタ351中の第1ユーザの情報及び/又は第1ユーザの銀行口座の口座情報と対応しているか否かを判断し、対応していると判断されると、購入者である第1ユーザの銀行口座から販売者である第2ユーザの銀行口座への前記支払額に対応した額の送金処理を行う。
このように、購入者である第1ユーザから販売者である第2ユーザに第1ユーザのカード情報、銀行口座の情報等を送信することなく、第1ユーザから第2ユーザに現金の支払いを行うことができるので、代金の支払時にカード情報や銀行口座の情報等の漏洩を防止することができる。
また、銀行サーバ300は、受信した第1ユーザ特定情報が顧客マスタ351中の第1ユーザの情報及び/又は第1ユーザの銀行口座の口座情報と対応していると判断されると、第1ユーザの銀行口座から第2ユーザの銀行口座への前記支払額に対応した額の送金処理を行うので、販売者である第2ユーザは即時又は比較的短期間で前記支払額に対応した現金を受け取ることができる。また、第1ユーザの銀行口座から第2ユーザの銀行口座に直接的に現金の支払いが行われるので、代金の支払経路において代金未収となる者が発生するリスクを無くすことができる。
このように、購入者である第1ユーザの銀行口座から販売者である第2ユーザの銀行口座に直接的に代金分の現金が送金されるので、購入者から販売者への代金の支払経路において代金未収となる者が発生せず、代金未収となるリスクに対する購入者又は販売者の金銭的負担を取り除くことができる。また、カード情報等の漏洩による被害のリスクも低減されるので、購入者はインターネット上における支払いをより安全に行うことができる。
また、本実施形態では、前記第1の端末100は、第1ユーザの銀行口座の口座情報を暗号化した暗号化口座情報を格納しているものである。また、銀行サーバ300は、前記暗号化口座情報を復号化するための秘密鍵を格納しているものである。そして、前記ステップS32では、第1ユーザは第1の端末100に格納されている暗号化口座情報を銀行サーバ300に送信し、前記ステップS33では、銀行サーバ300が第1ユーザを特定するための第1ユーザ特定情報として前記暗号化口座情報を受信し復号化する。このように、第1ユーザは第1の端末100に格納されている暗号化口座情報を銀行サーバ300に送信するだけで良いので、支払いの度に口座情報を入力する必要が無くなり、第1ユーザは支払いを容易且つスムーズに行うことができる。また、口座情報が暗号化されているので、口座情報の悪用を防止することができる。さらに、口座情報が暗号化されているので、本実施形態のステップS32にように第1の端末100から銀行サーバ300に電子メールで口座情報を送信することができる。ここで、携帯情報端末(PDA)や携帯電話はPCと比較して入力に時間や手間がかかることが多い。このため、携帯情報端末や携帯電話を用いてインターネット上の商品販売サイト等の代金を支払う者にとって、銀行サーバ300からメールを受信し、それに対して暗号化口座情報をメールで銀行サーバ300に送信する本願の構成を採用することは、口座情報をいちいち入力するのに比べて大幅に手間が削減されることになる。
また、本実施形態では、銀行サーバ300が、前記ステップS31や前記ステップS35でメールを送信した後に、前記ステップS32の暗号化口座情報の送信や、前記ステップS36以降が行われない状態で、所定の保留期限が経過した場合、当該支払処理を不成立扱いとする。また、不成立になったことと、その支払処理の支払額、購入者である第1ユーザのメールアドレス等を販売者である第2ユーザおよび購入者である第1ユーザにメール送信する。本実施形態では、銀行サーバ300が第1ユーザに第1ユーザ特定情報を求めるにあたり、第1ユーザにメールを送信するようにしているので、第1ユーザのメールの確認頻度によってはいつまでも支払処理が未払いのまま滞留する可能性があるが、前記保留期限が経過すると支払処理が不成立となることから、支払処理が未払いのまま滞留することが防止される。
また、本実施形態では、ステップS41において、送金処理が終了したことが顧客マスタ351に登録されている第2ユーザのメールアドレスにメール送信される。そして、このメールの内容には、前記支払額と、支払日と、支払者のメールアドレス、つまり第1ユーザのメールアドレスが含まれている。また、第2の端末200の販売情報格納処理部234は第2ユーザの前記メールアドレス宛のメールの内容を全て自動的に確認する機能を有しており、そのメールの内容に、販売情報格納部230に格納されている各販売情報の請求額(支払額)および購入者メールアドレスに対応するものがある場合、図7に示すように、その販売情報の支払完了受信日の欄にメールの受信日を格納する。このように、第2の端末200でも、第1ユーザのメールアドレスをキーとして販売情報の管理が行われることが可能となる。また、第2の端末200には第1ユーザの口座情報が送信されることがないので、口座情報の悪用を防止することもできる。
以下、本発明の第2実施形態に係る現金支払システムを説明する。第1実施形態では、第1ユーザ特定情報としての暗号化口座情報がメールで送信される構成となっていたが、第2実施形態では、銀行サーバ300の情報入力画面提供処理部374により第1の端末100に第1ユーザ特定情報を入力および送信を要求する入力画面を表示させ、その入力画面への入力および送信をもって銀行サーバ300が第1ユーザ特定情報を受信する構成となっている。また、第1実施形態では、第2ユーザが前記銀行で銀行口座を開設し、この銀行口座に第1ユーザからの支払いが行われるようになっていたが、第2実施形態では、第2ユーザは他の銀行にも銀行口座を有しており、当該他の銀行の銀行口座に第1ユーザからの支払いが行われる。その他の構成は第1実施形態と同様である。
本実施形態において、第1ユーザが第1の端末100を使って第2ユーザが運営するインターネット上の商品販売サイトにアクセスし、商品Zを購入しその代金を支払う場合について、図9のフローチャートに沿って説明する。
ステップS51〜S57は第1実施形態のステップS21〜27と同様である。ステップS57に続いて、第2の端末200は、決済要求送信処理部233により、受信した第1ユーザのメールアドレスと、前記支払額と、商品Zの販売者である第2ユーザを特定するために必要な第2ユーザ特定情報とを銀行サーバ300に送信する(ステップS58)。第2ユーザ特定情報としては、第2ユーザのユーザ情報(第2ユーザの電話番号等の情報や前記商品販売サイトに関する情報)や第2ユーザの銀行口座の口座情報に関する情報(前記暗号化口座情報であっても良い)が送信される。本実施形態の第2ユーザの銀行口座は、銀行サーバ300が設けられた銀行ではなく、他の銀行に設けられた第2ユーザの銀行口座である。従って、前記暗号化口座情報や、顧客マスタ351に格納されている第2ユーザの口座情報も、前記他の銀行のものとなる。なお、顧客マスタ351が第2ユーザの他の銀行の口座情報を格納していない場合もあり得る。この場合、ステップS58において、第2の端末200は第2ユーザが前記他の銀行に有する銀行口座の口座情報を銀行サーバ300に送信する必要がある。
ステップS59およびS60は第1実施形態のステップS29および30と同様である。続いて、銀行サーバ300は、メール送信処理部273により、第1ユーザの前記メールアドレスにメールを送信する(ステップS61)。このメールは、第2ユーザから商品Zの購入につき前記支払額の要求があったことを通知し、当該支払額の支払承認と、購入者である第1ユーザを特定するために第1ユーザ特定情報の送信とを要求するものである。前記支払承認は明示的なものであっても良く、第1ユーザが前記第1ユーザ特定情報を送信したことをもって支払を承認したとみなすことも可能である。第1ユーザ特定情報としては、第1ユーザのユーザ情報(前記個人情報等の情報)や第1ユーザの銀行口座の口座情報に関する情報(前記暗号化口座情報であっても良い)の送信が要求される。本実施形態では、第1ユーザ特定情報として、第1ユーザの前記暗号化口座情報のメールでの送信が要求される。前記メールにはURLが含まれており、このメールはURLにアクセスして第1ユーザ特定情報を入力および送信することを要求するものである。
第1ユーザは、ステップS61で銀行サーバ300から上記メールを受信すると、メールに含まれているURLにアクセスし(ステップS62)、これに対し、銀行サーバ300の情報入力画面提供処理部374および第1の端末100のブラウザソフト等により、第1の端末100に第1ユーザ特定情報を入力および送信するための画面(図10参照)が表示される(ステップS63)。第1ユーザが上記入力および送信を行うと(ステップS64)、銀行サーバ300は、第1ユーザ情報判断処理部375により、第1ユーザから受信した暗号化口座情報を前記秘密鍵によって復号化し、復号化した口座情報が顧客マスタ351に格納されている第1ユーザの口座情報と対応しているか否かを判断する(ステップS65)。続いて、銀行サーバ300は、残額判断処理部376により、第1ユーザの口座残高が前記支払額以上であるか否かを判断する(ステップ66)。
続いて、ステップS65で対応していると判断され、ステップS66で残高があると判断されると、銀行サーバ300の情報入力画面提供処理部374および第1の端末100のブラウザソフト等により、第1の端末100に更なる第1ユーザ特定情報としてパスワードの入力および送信を要求する画面が表示される(ステップS67)。ステップS68〜S72は第1実施形態のステップS38〜S42と同様である。
第2実施形態の場合でも、購入者である第1ユーザから販売者である第2ユーザに第1ユーザのカード情報、銀行口座の情報等を送信することなく、第1ユーザから第2ユーザに現金の支払いを行うことができるので、代金の支払時にカード情報や銀行口座の情報等の漏洩を防止することができる。
また、銀行サーバ300は、受信した第1ユーザ特定情報が顧客マスタ351中の第1ユーザの情報及び/又は第1ユーザの銀行口座の口座情報と対応していると判断されると、第1ユーザの銀行口座から第2ユーザの銀行口座への前記支払額に対応した額の送金処理を行うので、販売者である第2ユーザは即時又は比較的短期間で前記支払額に対応した現金を受け取ることができる。また、第1ユーザの銀行口座から第2ユーザの銀行口座に直接的に現金の支払いが行われるので、代金の支払経路において代金未収となる者が発生するリスクを無くすことができる。
また、購入者である第1ユーザの銀行口座から販売者である第2ユーザの銀行口座に直接的に代金分の現金が送金されるので、購入者から販売者への代金の支払経路において代金未収となる者が発生せず、代金未収となるリスクに対する購入者又は販売者の金銭的負担を取り除くことができる。また、カード情報等の漏洩による被害のリスクも低減されるので、購入者はインターネット上における支払いをより安全に行うことができる。
前記第1および第2実施形態では、ステップS38やS68で第1ユーザがパスワードを送信する構成を採用しているが、第1および第2実施形態でステップS33、S34、S65、S66の確認がされた段階でステップS40およびS70の送金処理が行われるように構成することも可能である。
尚、この発明は上記一実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。
100…第1の端末、110…表示装置、120…通信部、130…口座情報格納部、140…プログラム格納部、141…第1ユーザ情報送信処理部、200…第2の端末、210…通信部、220…口座情報格納部、230…プログラム格納部、231…販売用画面表示処理部、232…決済画面表示処理部、233…決済要求送信処理部、234…販売情報格納部、240…販売情報格納部、300…銀行サーバ、310…CPU、320…RAM、330…表示装置、340…通信部、350…顧客マスタ格納部、351…顧客マスタ、360…口座データ格納部、370…プログラム格納部、371…口座開設処理部、372…契約有無判断処理部、373…メール送信処理部、374…情報入力画面提供処理部、375…第1ユーザ情報判断処理部、376…残額判断処理部、377…送金処理部、378…経過時間判断処理部。

Claims (12)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011286340A JP5918995B2 (ja) 2011-12-27 2011-12-27 支払処理方法およびその支払処理に用いる銀行サーバ

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011286340A JP5918995B2 (ja) 2011-12-27 2011-12-27 支払処理方法およびその支払処理に用いる銀行サーバ

Publications (2)

Publication Number Publication Date
JP2013134708A JP2013134708A (ja) 2013-07-08
JP5918995B2 true JP5918995B2 (ja) 2016-05-18

Family

ID=48911333

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011286340A Active JP5918995B2 (ja) 2011-12-27 2011-12-27 支払処理方法およびその支払処理に用いる銀行サーバ

Country Status (1)

Country Link
JP (1) JP5918995B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016140476A1 (ko) * 2015-03-03 2016-09-09 김봉세 암호화 데이터를 복호화하기 위한 장치 및 그 방법

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0690399A3 (en) * 1994-06-30 1997-05-02 Tandem Computers Inc Remote controlled financial transaction system
JP2001357214A (ja) * 2000-06-12 2001-12-26 Ntt Comware Corp 仮想銀行における送金方法ならびにシステムおよび同方法がプログラムされ記録された記録媒体
JP2003085467A (ja) * 2001-07-03 2003-03-20 Yukio Hasegawa 取引決済システム、取引決済システムにおける商品販売サーバ及び取引決済処理プログラム
JP4404518B2 (ja) * 2002-04-17 2010-01-27 日本電気株式会社 送金システム、送金方法および送金プログラム
US7856384B1 (en) * 2004-07-14 2010-12-21 Yahoo! Inc. Systems and methods for providing security in international money exchanges
JP2006259854A (ja) * 2005-03-15 2006-09-28 Bank Of Tokyo-Mitsubishi Ufj Ltd サーバ装置および決済方法
JP5139715B2 (ja) * 2006-04-25 2013-02-06 Kddi株式会社 携帯電話を利用した金融取引サービス方法および金融取引サービスシステム
CN101615274A (zh) * 2008-06-25 2009-12-30 阿里巴巴集团控股有限公司 利用通信终端进行支付的方法及***
KR20110056561A (ko) * 2008-09-30 2011-05-30 애플 인크. 피어 대 피어 금융 트랜잭션 장치들 및 방법들

Also Published As

Publication number Publication date
JP2013134708A (ja) 2013-07-08

Similar Documents

Publication Publication Date Title
US7797237B2 (en) Electronic financial transaction system and method providing real-time authentication service through wire/wireless communication network
US9317841B2 (en) Method and system for facilitating online payments based on an established payment agreement
US10825016B2 (en) Electronic bearer bond online transaction and card system and method thereof
JP4869923B2 (ja) オンライン支払を容易にするためのシステム及び方法
US20150199658A1 (en) System and method for electronic payment, and server, communication terminal and program therefor
US20080114684A1 (en) Termination of transactions
JP2009507279A (ja) 安全なインターネット電子商取引方式
JP2010519661A (ja) 購入者と販売者との間の購入を促進させる方法およびシステム
KR20040099751A (ko) 조건부 거래에 따른 전자결제 방법 및 전자결제 서버
KR20200006708A (ko) 가상화폐를 이용한 결제 시스템
US20120233021A1 (en) Online Transaction System
KR20010090032A (ko) 온라인 직접 결제 시스템 및 그 방법
JP4676058B2 (ja) 電子決済システム、代金決済方法、決済サーバ
JP5918995B2 (ja) 支払処理方法およびその支払処理に用いる銀行サーバ
JP5097310B2 (ja) 商品購入代金の決済システム及びその方法
JP2002251530A (ja) デジタルコンテンツ販売システムおよびデジタルコンテンツ販売方法
KR100476660B1 (ko) 유무선 통신망을 이용한 실시간 인증의 전자금융거래서비스방법 및 서비스 시스템
KR20060124375A (ko) 거래 시스템 및 이 시스템을 통한 사용자 인증 방법
JP4570450B2 (ja) 金融機関サーバ及びこのサーバによる振込処理方法
KR20170082997A (ko) 펌 뱅킹시 자금 이체방법 및 그 방법을 이용한 자금이체 시스템
KR20020064473A (ko) 전자지갑과 통합된 전자 지불 보증 서비스 시스템 및 그방법
JP2006107114A (ja) 決済方法、決済システム、決済用プログラム
JP2002222380A (ja) ショッピング決済代行方法
KR20170032109A (ko) 펌 뱅킹시 자금 이체방법 및 그 방법을 이용한 자금이체 시스템
KR100444372B1 (ko) 전자 상거래 시스템에서 대금 결제 시스템 및 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140704

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150306

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150602

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150730

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160329

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160411

R150 Certificate of patent or registration of utility model

Ref document number: 5918995

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250