[1.第1実施形態]
本開示に係る残高連携システムの実施形態の一例である第1実施形態を説明する。
[1.第1実施形態]
図1は、残高連携システムの全体構成の一例を示す図である。残高連携システムSは、電子マネーサーバ10、銀行サーバ20、及びユーザ端末30を含む。これらは、インターネット又はLAN等のネットワークNに接続可能である。残高連携システムSは、少なくとも1つのコンピュータを含めばよく、図1の例に限られない。
電子マネーサーバ10は、決済事業者のサーバコンピュータである。制御部11は、少なくとも1つのプロセッサを含む。記憶部12は、RAM等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部13は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。
銀行サーバ20は、銀行のサーバコンピュータである。制御部21、記憶部22、及び通信部23の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
ユーザ端末30は、ユーザのコンピュータである。例えば、ユーザ端末30は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。制御部31、記憶部32、及び通信部33の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。操作部34は、タッチパネル等の入力デバイスである。表示部35は、液晶ディスプレイ又は有機ELディスプレイである。
なお、電子マネーサーバ10、銀行サーバ20、及びユーザ端末30の各々に記憶されるプログラムは、ネットワークNを介して供給されてもよい。また、情報記憶媒体に記憶されたプログラムが、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)、又は、外部機器とデータの入出力をするための入出力部(例えば、USBポート)を介して供給されてもよい。
[1-2.残高連携システムの概要]
第1実施形態では、ユーザが、ユーザ端末30にインストールされた決済アプリから、決済サービスを利用する場合を例に挙げる。決済サービスで利用可能な決済手段は、任意の種類であってよい。例えば、電子マネー、ポイント、クレジットカード、デビットカード、銀行口座、ウォレット、又は暗号資産が決済手段に相当してもよい。決済手段は、支払手段と呼ばれることもある。バーコード又は二次元コードといったコードが決済手段に相当することもある。決済手段は、電子決済で利用される何らかの手段であればよい。電子決済は、キャッシュレス決済と呼ばれることもある。
図2は、ユーザ端末30に表示される画面の一例を示す図である。例えば、ユーザ端末30の決済アプリが起動すると、決済アプリのトップ画面G1が表示部35に表示される。トップ画面G1には、決済サービスにおいてユーザを識別可能なコードIDを含むコードC10が表示される。コードIDは、ユーザが決済サービスにログインするためのユーザIDとは異なる情報である。例えば、コードIDは、決済アプリが起動するたびに更新される。
図2の例では、バーコード及び二次元コードの両方がコードC10として表示される場合を示しているが、コードC10自体は、任意のコードであってよい。例えば、バーコード又は二次元コードの何れか一方のみがコードC10として表示されてもよい。例えば、ユーザが訪れた店舗の端末でコードC10が読み取られると、ユーザが支払元として設定した決済手段に基づいて、決済処理が実行される。
第1実施形態では、支払元が電子マネーである場合を例に挙げる。図2の例では、決済サービス「AAAペイ」で利用可能なオンライン型の電子マネー「AAAキャッシュ」が支払元として設定されている。例えば、店舗の端末でコードC10が読み取られると、電子マネーの残高が所定の額だけ減少し、決済が完了する。コードC10は、店舗の端末以外にも、自動販売機等の任意の端末で読み取り可能である。
なお、決済アプリで利用可能な決済方法は、コードC10を利用する方法に限られない。例えば、店舗に掲示されたコードをユーザ端末30で読み取る決済方法、店舗の端末に表示されたコードをユーザ端末30で読み取る決済方法、ユーザ端末30に対する操作のみで完結する決済方法、又は無線通信可能な端末にユーザ端末30をかざす決済方法といった任意の方法を利用可能である。また、電子マネーは、決済アプリ以外にも、電子商取引サービス又はフリーマーケットサービスといったオンライン上の任意のサービスで利用可能である。オンライン上のサービスで電子マネーが利用される場合には、決済アプリが利用されなくてもよい。
例えば、ユーザがボタンB11を選択すると、電子マネーのメニューM13が表示部35に表示される。第1実施形態では、電子マネーの残高として、プレミアム型の残高と、基本型の残高と、の2種類が存在する場合を例に挙げる。メニューM13には、プレミアム型の残高、基本型の残高、及びこれらの合計が表示される。以降、プレミアム型の残高と、基本型の残高と、を区別しない時は、単に電子マネー残高という。
プレミアム型の残高は、第1の種類の電子マネー残高である。プレミアム型の残高は、任意の目的で利用可能である。第1実施形態では、店舗等における支払で利用する目的(以降、支払目的)、他のユーザに残高の一部又は全部を送る目的(以降、送り目的)、及びユーザの口座に出金する目的(以降、出金目的)で、プレミアム型の残高を利用可能な場合を例に挙げる。第1実施形態では、プレミアム型の残高は、基本型の残高よりも優先的に利用されるものとする。
プレミアム型の残高は、任意のチャージ方法でチャージ可能である。第1実施形態では、オンラインフリーマーケットサービスの売上金を利用したチャージ方法(以降、売上金チャージ)、暗号資産を利用したチャージ方法(以降、暗号資産チャージ)、又は金融機関の口座を利用したチャージ方法(以降、口座チャージ)で、プレミアム型の残高をチャージ可能な場合を例に挙げる。
なお、クレジットカードのショッピング枠の現金化を防止するために、出金目的で利用可能なプレミアム型の残高は、ショッピング枠を利用したチャージ方法(以降、ショッピングチャージ)ではチャージできないものとする。一方で、クレジットカードのキャッシング枠は、現金の借入を目的としたものである。このため、プレミアム型の残高は、キャッシング枠を利用したチャージ方法(以降、キャッシングチャージ)でチャージできるようにしてもよい。
基本型の残高は、第2の種類の電子マネー残高である。基本型の残高は、任意の目的で利用可能である。第1実施形態では、支払目的及び送り目的で、基本型の残高を利用可能な場合を例に挙げる。基本型の残高は、出金目的では利用できない。このため、第1実施形態では、プレミアム型の残高の方が、より多くの目的で利用可能であり、利便性が高いものとする。基本型の残高は、任意のチャージ方法でチャージ可能である。第1実施形態では、ショッピング枠チャージで、基本型の残高をチャージ可能な場合を例に挙げる。なお、ユーザが基本型の残高を他のユーザに送った場合、他のユーザは、基本型の残高として受け取るので、当該受け取った残高を出金目的では利用できないようになっている。
例えば、ユーザは、メニューM13から、電子マネーに関する各種操作をすることができる。例えば、ユーザがボタンB14を選択すると、電子マネーを他のユーザに送ることができる。ユーザがボタンB15を選択すると、電子マネーにチャージできる。ユーザがボタンB16を選択すると、プレミアム型の残高の全部又は一部を出金できる。ユーザがボタンB17を選択すると、プレミアム型の残高と、銀行における口座の残高である口座残高と、を連携できる。以降、これらの残高が連携することを、残高連携という。
第1実施形態では、ユーザは、銀行に口座を開設済みであるものとする。更に、ユーザは、ユーザ端末30にインストールされた銀行アプリから、金融サービスを利用可能であるものとする。例えば、ユーザは、銀行アプリから、口座残高の確認、過去の取引における明細の確認、振込の実行、公共料金等の払込、又はローン申込といった種々の金融サービスを利用できる。決済アプリは、銀行アプリとの連携が可能である。
例えば、ユーザがボタンB17を選択すると、銀行アプリが起動し、認証画面G2が表示部35に表示される。決済アプリは、バックグラウンドに移行する。ユーザが、金融サービスにおけるユーザID及びパスワードを入力フォームF20に入力してボタンB21を選択すると、銀行サーバ20による認証が実行される。認証自体は、生体認証等の種々の方法を利用可能である。銀行サーバ20がユーザの正当性を確認すると、決済アプリがフォアグラウンドに戻り、残高連携が完了したことを示す完了画面G3が表示部35に表示される。銀行アプリは、終了してもよいし、バックグラウンドに移行してもよい。
図3は、第1実施形態における残高連携の一例を示す図である。例えば、トップ画面G1には、電子マネーの残高を示す領域に、残高連携中であることを示すメッセージが表示される。図3の例では、電子マネーの残高を表示しないようにしているが、残高連携が完了した後は、電子マネーの残高として、基本型の残高と、口座残高と、の合計が表示されてもよいし、基本型の残高と、口座残高と、が別々に表示されてもよい。
第1実施形態では、残高連携が完了すると、プレミアム型の残高がユーザの口座に自動入金される。例えば、プレミアム型の残高が3500円分存在する状態で残高連携が完了すると、この3500円分が連携先の口座に自動入金される。電子マネーを口座に自動入金する方法自体は、種々の出金方法を適用可能である。残高連携前の口座残高を1200000円とすると、自動入金により、口座残高は1203500円になる。プレミアム型の残高は、全て自動入金されたので、0円になる。
例えば、図3の状態で、ユーザがプレミアム型の残高に1000円分のチャージをしたとする。この場合、プレミアム型の残高は、0円から1000円に増加する。その直後に、プレミアム型の残高の全額である1000円が、連携先の口座に自動入金される。このため、プレミアム型の残高は、一瞬だけ1000円になるが、すぐに0円に減少する。口座の残高は、1203500円から1204500円に増加する。
例えば、図3の状態で、ユーザが、他のユーザから2000円分のプレミアム型の残高を受け取ったとする。この場合、プレミアム型の残高は、0円から2000円に増加する。その直後に、プレミアム型の残高の全額である2000円が、連携先の口座に自動入金される。このため、プレミアム型の残高は、一瞬だけ2000円になるが、すぐに0円に減少する。口座の残高は、1203500円から1205500円に増加する。
例えば、図3の状態で、ユーザが店舗のPOS端末にコードC10を読み取らせて、3000円の買い物をしたとする。更に、プレミアム型の残高は、基本型の残高よりも優先的に利用されるものとする。3000円分の支払でプレミアム型の残高が優先的に利用されるが、残高連携後は、プレミアム型の残高は0円になるので、連携先の口座の口座残高からプレミアム型の残高に3000円分が自動チャージされる。このため、口座の残高は、1203500円から1200500円に減少する。プレミアム型の残高は、一瞬だけ0円から3000円に増加した後に、この3000円分がすぐに支払に利用されて0円に減少する。
例えば、図3の状態で、ユーザが、他のユーザに4000円分のプレミアム型の残高を送ったとする。残高連携後は、プレミアム型の残高は0円になるので、口座残高からプレミアム型の残高に4000円分が自動チャージされる。このため、口座の残高は、1203500円から1199500円に減少する。プレミアム型の残高は、一瞬だけ0円から4000円に増加した後に、この4000円分がすぐに他のユーザに送られて0円に減少する。
以上のように、第1実施形態の残高連携システムSでは、残高連携により、プレミアム型の残高と、口座の残高と、を十分に連携させることによって、ユーザの利便性を高めるようになっている。以降、第1実施形態の詳細を説明する。
[1-3.第1実施形態の残高連携システムで実現される機能]
図4は、第1実施形態の残高連携システムSで実現される機能の一例を示す機能ブロック図である。
[1-3-1.電子マネーサーバで実現される機能]
データ記憶部100は、記憶部12を主として実現される。増加要求受付部101、電子マネー残高増加部102、口座残高増加部103、減少要求受付部104、電子マネー残高減少部105、及び口座残高減少部106は、制御部11を主として実現される。
[データ記憶部]
データ記憶部100は、ユーザに決済サービスを提供するために必要なデータを記憶する。例えば、データ記憶部100は、決済データベースDB1を記憶する。
図5は、決済データベースDB1の一例を示す図である。図5に示すように、決済データベースDB1は、決済サービスにおけるユーザに関する情報が格納されたデータベースである。例えば、決済データベースDB1には、ユーザID、パスワード、氏名、コードID、有効期限、支払元情報、カード情報、電子マネー情報、及び連携情報が格納される。決済データベースDB1に格納される情報は、ユーザに関する任意の情報であってよく、図5の例に限られない。例えば、決済データベースDB1には、電子マネーの利用履歴又はチャージ履歴が格納されてもよい。
ユーザIDは、ユーザを識別可能なユーザ識別情報の一例である。ユーザ識別情報は、任意の情報であってよく、例えば、ユーザアカウントと呼ばれる情報、メールアドレス、又は電話番号であってもよい。例えば、ユーザ識別情報は、文字、数字、その他の記号、又はこれらの組み合わせである。ユーザID及びパスワードは、決済サービスにログインするために利用される。
第1実施形態では、ユーザIDだけではなく、コードIDもユーザを識別可能な情報なので、コードIDもユーザ識別情報に相当する。コードC10には、何らかのユーザ識別情報が含まれるようにすればよい。コードC10には、コードIDではなく、ユーザID等の他のユーザ識別情報が含まれてもよい。有効期限は、コードIDが発行されてから所定時間後の時点である。コードIDには、有効期限が設定されなくてもよい。
支払元情報は、支払元として設定された決済手段を識別可能な情報である。例えば、支払元として電子マネーが設定された場合、支払元情報は、電子マネーを識別可能な電子マネーIDであってもよい。例えば、支払元としてクレジットカードが設定された場合、支払元情報は、クレジットカードのカード番号であってもよい。カード情報は、ユーザのクレジットカードに関する情報である。例えば、カード情報は、カード番号、有効期限、及び名義人を含む。ユーザは、複数のクレジットカードを登録可能である。
電子マネー情報は、ユーザの電子マネーに関する情報である。例えば、電子マネー情報は、電子マネー残高を示す情報を含む。第1実施形態では、プレミアム型の残高と、基本型の残高と、が存在するので、電子マネー情報には、これらの残高が示される。連携情報は、残高連携に関する情報である。例えば、連携情報は、連携先の口座の金融機関コード、支店名、口座番号、及び名義人を示す。連携情報は、連携先の口座を識別可能であればよく、口座番号だけを示してもよいし、金融サービスにおけるユーザIDを示してもよい。残高連携をしていないユーザについては、連携情報が格納されないものとする。
[増加要求受付部]
増加要求受付部101は、電子マネーの残高である電子マネー残高を増加させるための増加要求を受け付ける。第1実施形態では、決済手段の一例として電子マネーを説明するので、電子マネー残高は、決済手段残高の一例である。このため、電子マネーについて説明している箇所は、決済手段と読み替えることができる。電子マネー残高について説明している箇所は、決済手段残高と読み替えることができる。
第1実施形態では、特にプレミアム型の残高の詳細を説明するので、プレミアム型の電子マネーについて説明している箇所は、決済手段と読み替えることができる。プレミアム型の残高について説明している箇所は、決済手段残高と読み替えることができる。決済手段は、残高の概念を有する他の決済手段であってもよい。例えば、決済手段は、ポイントであってもよい。ポイントが決済手段に相当する場合、ポイント残高が決済手段残高に相当する。例えば、電子マネーとは呼ばれずに、決済サービスの独自の名前で呼ばれる決済手段であってもよい。
増加要求は、所定の形式のデータが送信されることによって行われる。増加要求は、任意の情報を含むことができる。例えば、増加要求は、増加対象となる電子マネーを識別可能な電子マネー識別情報と、電子マネー残高を増加させる額と、を含む。増加要求は、他の情報を含んでもよく、例えば、複数の方法で電子マネー残高を増加できる場合には、この方法を識別可能な情報が増加要求に含まれてもよい。
第1実施形態では、コードIDが電子マネー識別情報に相当する場合を説明するが、電子マネー識別情報は、コードID以外の任意の情報であってよい。例えば、電子マネー識別情報は、ユーザIDであってもよいし、コードID及びユーザID以外のユーザ識別情報であってもよい。例えば、電子マネー識別情報は、ユーザ識別情報とは異なる情報であってもよく、電子マネーを識別可能な電子マネーIDであってもよい。
第1実施形態では、ユーザ端末30から増加要求が送信される場合を説明するが、増加要求は、任意のコンピュータによって送信可能である。例えば、店舗に配置されたPOS端末又はチャージ端末からのチャージを可能とする場合には、POS端末又はチャージ端末から増加要求が送信されてもよい。例えば、電子商取引サービス又はオンラインフリーマーケットサービスといった任意のサービスを利用した特典(ギフト)として、電子マネーが付与される場合には、このサービスのサーバコンピュータから増加要求が送信されてもよい。
例えば、ユーザがボタンB15を選択した場合に、ユーザ端末30から電子マネーサーバ10に送信されるチャージ要求は、増加要求の一例である。このため、チャージ要求について説明している箇所は、増加要求と読み替えることができる。チャージ要求は、電子マネーにチャージするための要求である。
第1実施形態では、プレミアム型の残高と、基本型の残高と、の2つの電子マネー残高に対するチャージのうち、主に、プレミアム型の残高に対するチャージについて説明する。例えば、チャージ要求には、チャージ対象の電子マネーを識別可能な電子マネー識別情報と、ユーザが指定したチャージ額と、が含まれている。第1実施形態では、複数のチャージ方法が用意されているので、チャージ要求には、チャージ方法を識別可能なチャージ方法識別情報も含まれているものとする。チャージ方法が1種類しか存在しない場合には、チャージ要求には、チャージ方法識別情報が含まれていなくてもよい。
例えば、ユーザが他のユーザから送られたプレミアム型の残高を受け取る操作をした場合に、ユーザ端末30から電子マネーサーバ10に送信される受取要求も、増加要求の一例である。このため、受取要求について説明している箇所は、増加要求と読み替えることができる。受取要求は、他のユーザから送られたプレミアム型の残高を受け取るための要求である。
第1実施形態では、プレミアム型の残高と、基本型の残高と、の2つの電子マネー残高に対するチャージのうち、主に、プレミアム型の残高の受け取りについて説明する。例えば、受取要求には、他のユーザから送られたプレミアム型の残高を識別可能な情報が含まれている。他のユーザから送られたプレミアム型の残高に関する情報は、決済データベースDB1に格納されているものとする。
なお、増加要求は、電子マネー残高を増加させるための何らかの要求であればよく、チャージ要求及び受取要求に限られない。例えば、何らかの特典としてプレミアム型の残高が贈られる場合には、特典を受け取るための要求が増加要求に相当してもよい。
[電子マネー残高増加部]
電子マネー残高増加部102は、増加要求が受け付けられた場合に、電子マネー残高を増加させる。電子マネー残高を増加させるとは、決済データベースDB1に格納された電子マネー残高を、現在の数値よりも大きくすることである。電子マネー残高増加部102は、増加要求に応じた増加分だけ、電子マネー残高を増加させる。第1実施形態では、電子マネー残高増加部102は、プレミアム型の残高と、基本型の残高と、の両方を増加可能である。これらの増加を区別しない時は、単に電子マネー残高の増加と記載する。
例えば、チャージ要求が増加要求に相当する場合、電子マネー残高増加部102は、チャージ処理を実行することによって、電子マネー残高を増加させる。チャージ処理自体は、公知の処理を利用可能である。例えば、電対マネー残高増加部は、増加要求に含まれる電子マネー識別情報が示す電子マネーの残高を、増加要求に含まれるチャージ方法情報が示すチャージ方法で、増加要求に含まれるチャージ額だけ増加させる。
例えば、受取要求が増加要求に相当する場合、電子マネー残高増加部102は、受取処理を実行することによって、電子マネー残高を増加させる。受取処理自体は、公知の処理を利用可能である。例えば、電対マネー残高増加部は、受取要求に含まれる情報に基づいて、対象となる電子マネー及び受取額を特定し、当該特定された電子マネーの残高を、受取額だけ増加させる。他の増加要求が受け付けられた場合にも、電子マネー残高増加部102は、他の増加要求に基づいて、電子マネー残高を増加させるようにすればよい。
[口座残高増加部]
口座残高増加部103は、増加要求が受け付けられた場合に、電子マネーと連携する口座の残高である口座残高を増加させる。第1実施形態では、口座残高増加部103は、残高連携が完了し、かつ、プレミアム型の残高の増加要求が受け付けられた場合に、口座残高を増加させる。口座残高増加部103は、増加要求により指示されたプレミアム型の残高の増加分と同じ額だけ、口座残高を増加させる。口座残高を書き換える処理自体は、銀行サーバ20によって実行されるので、口座残高増加部103は、銀行サーバ20に対し、口座残高を増加させるための要求を送信することによって、口座残高を増加させる。電子マネーサーバ10及び銀行サーバ20の協働により、口座残高が増加する。
口座残高増加部103が銀行サーバ20に送信する要求は、所定の形式のデータが送信されることによって行われるようにすればよい。例えば、この要求には、増加対象となる口座を識別可能な口座識別情報と、口座残高の増加額と、が含まれてもよい。第1実施形態では、支店名及び口座番号が口座識別情報に相当する場合を説明するが、口座を識別可能な他の情報が口座識別情報に相当してもよい。例えば、決済サービスにおけるユーザID、又は、金融サービスにおけるユーザIDが口座識別情報に相当してもよい。口座残高増加部103は、プレミアム型の残高の増加要求が示す増加分と同じ額だけ口座残高を増加することを、銀行サーバ20に要求する。
第1実施形態では、プレミアム型の残高がいったん増加した後に口座への自動入金が行われるので、口座残高増加部103は、増加要求受付部101が受け付けた増加要求に応じた額を、プレミアム型の電子マネーから口座に自動的に入金することによって、口座残高を増加させる。口座残高増加部103は、電子マネー残高増加部102により増加したプレミアム型の残高に基づいて、口座残高を増加させる。口座残高増加部103は、プレミアム型の残高を、口座残高への自動入金額だけ減少させる。このため、口座残高増加部103は、プレミアム型の残高を増加前の額に戻すことになる。プレミアム型の残高を戻す処理は、後述の電子マネー残高減少部105により実行されてもよい。電子マネーを口座に入金する方法自体は、公知の方法を利用可能である。
なお、口座残高増加部103は、プレミアム型の残高をいったん増加させることなく、口座への自動入金を実行してもよい。この場合、増加要求受付部101が増加要求を受け付けた後に、電子マネー残高増加部102の処理は実行されない。口座残高増加部103は、増加要求が受け付けられた場合に、当該増加要求が示す増加分だけ口座残高を増加することを、銀行サーバ20に要求すればよい。
[減少要求受付部]
減少要求受付部104は、電子マネー残高を減少させるための減少要求を受け付ける。減少要求は、所定の形式のデータが送信されることによって行われる。減少要求は、任意の情報を含むことができる。例えば、減少要求は、減少対象となる電子マネーを識別可能な電子マネー識別情報と、電子マネー残高を減少させる額と、を含む。電子マネー識別情報は、先述した通りである。
第1実施形態では、店舗のPOS端末又はユーザ端末30から減少要求が送信される場合を説明するが、減少要求は、任意のコンピュータによって送信可能である。例えば、自動販売機に対する電子マネーの利用を可能とする場合には、自動販売機から減少要求が送信されてもよい。例えば、電子商取引サービス又はオンラインフリーマーケットサービスといった任意のサービスで電子マネーを利用可能な場合には、このサービスのサーバコンピュータから減少要求が送信されてもよい。
例えば、ユーザがコードC10をPOS端末に読み取らせた場合に、POS端末から電子マネーサーバ10に送信される支払要求は、減少要求の一例である。このため、支払要求について説明している箇所は、減少要求と読み替えることができる。支払要求は、電子マネーを利用して支払をするための要求である。第1実施形態では、プレミアム型の残高と、基本型の残高と、の2つの電子マネー残高の決済のうち、主に、プレミアム型の残高の決済について説明する。基本型の残高の決済は、公知の処理を利用可能である。例えば、支払要求には、店舗ID、端末ID、コードID、及び利用額が含まれているものとする。店舗IDは、店舗を識別可能な情報である。端末IDは、POS端末を識別可能な情報である。
例えば、ユーザが他のユーザにプレミアム型の残高を送る操作をした場合に、ユーザ端末30から電子マネーサーバ10に送信される送り要求も、減少要求の一例である。このため、送り要求について説明している箇所は、減少要求と読み替えることができる。送り要求は、他のユーザにプレミアム型の残高を送るための要求である。送り要求には、コードID、相手のユーザを識別可能な何らかのユーザ識別情報、及び送り額が含まれているものとする。
なお、減少要求は、電子マネー残高を減少させるための何らかの要求であればよく、支払要求及び送り要求に限られない。例えば、ユーザが電子マネーを自身の口座に出金するための要求が減少要求に相当してもよい。この口座は、残高連携した口座以外の他の口座であってもよい。
[電子マネー残高減少部]
電子マネー残高減少部105は、減少要求が受け付けられた場合に、電子マネー残高を減少させる。電子マネー残高を減少させるとは、決済データベースDB1に格納された電子マネー残高を、現在の数値よりも小さくすることである。電子マネー残高減少部105は、減少要求に応じた減少分だけ、電子マネー残高を減少させる。第1実施形態では、電子マネー残高減少部105は、プレミアム型の残高と、基本型の残高と、の両方を減少可能である。これらの減少を区別しない時は、単に電子マネー残高の減少と記載する。
例えば、支払要求が減少要求に相当する場合、電子マネー残高減少部105は、決済処理を実行することによって、電子マネー残高を減少させる。決済処理自体は、公知の処理を利用可能である。例えば、電対マネー残高減少部は、支払要求に含まれるコードIDに関連付けられた電子マネーの残高を、支払要求に含まれる支払額だけ減少させる。
例えば、送り要求が減少要求に相当する場合、電子マネー残高減少部105は、送り処理を実行することによって、電子マネー残高を減少させる。送り処理自体は、公知の処理を利用可能である。例えば、電対マネー残高減少部は、送り要求に含まれる情報に基づいて、対象となる電子マネーを特定し、当該特定された電子マネーの残高を、送り額だけ減少させる。他の減少要求が受け付けられた場合にも、電子マネー残高減少部105は、他の減少要求に基づいて、電子マネー残高を減少させるようにすればよい。
[口座残高減少部]
口座残高減少部106は、減少要求が受け付けられた場合に、口座残高を減少させる。第1実施形態では、口座残高減少部106は、残高連携が完了し、かつ、プレミアム型の残高の減少要求が受け付けられた場合に、口座残高を減少させる。口座残高減少部106は、減少要求により指示されたプレミアム型の残高の減少分と同じ額だけ、口座残高を減少させる。口座残高を書き換える処理自体は、銀行サーバ20によって実行されるので、口座残高減少部106は、銀行サーバ20に対し、口座残高を減少させるための要求を送信することによって、口座残高を減少させる。電子マネーサーバ10及び銀行サーバ20の協働により、口座残高が減少する。
口座残高減少部106が銀行サーバ20に送信する要求は、所定の形式のデータが送信されることによって行われるようにすればよい。例えば、この要求には、減少対象となる口座を識別可能な口座識別情報と、口座残高の減少額と、が含まれてもよい。口座残高減少部106は、プレミアム型の残高の減少要求が示す減少分と同じ額だけ口座残高を減少することを、銀行サーバ20に要求する。
第1実施形態では、プレミアム型の残高が自動チャージされた後に減少するので、口座残高減少部106は、減少要求に応じた額を、口座からプレミアム型の電子マネーに自動的にチャージすることによって、口座残高を減少させる。電子マネーを自動的にチャージする方法自体は、公知の方法を利用可能である。自動的なチャージは、口座残高減少部106ではなく、電子マネー残高増加部102により実行されてもよい。
なお、第1実施形態では、プレミアム型の残高が増加した後に、決済処理等が実行される場合を説明するが、プレミアム型の残高を増加させることなく、決済処理等が実行されてもよい。この場合、減少要求受付部104が減少要求を受け付けた後に、プレミアム型の電子マネーを自動的にチャージする処理は実行されない。銀行サーバ20から口座残高の減少が完了した通知が受信された場合に、プレミアム型の残高が増加することなく決済処理等が実行されてもよい。
[1-3-2.銀行サーバで実現される機能]
データ記憶部200は、記憶部22を主として実現される。口座残高増加部201及び口座残高減少部202は、制御部21を主として実現される。
[データ記憶部]
データ記憶部200は、ユーザに金融サービスを提供するために必要なデータを記憶する。例えば、データ記憶部200は、口座データベースDB2を記憶する。
図6は、口座データベースDB2の一例を示す図である。図6に示すように、口座データベースDB2は、金融サービスにおけるユーザに関する情報が格納されたデータベースである。例えば、口座データベースDB2には、ユーザID、パスワード、氏名、支店名、口座番号、名義人、口座残高、及び連携情報が格納される。口座データベースDB2に格納される情報は、ユーザに関する任意の情報であってよく、図6の例に限られない。例えば、口座データベースDB2には、口座の取引履歴が格納されてもよい。
第1実施形態では、決済サービスのユーザIDと、金融サービスのユーザIDと、が異なる場合を説明するが、これらは共通であってもよい。同様に、決済サービスのパスワードと、金融サービスのパスワードと、が異なる場合を説明するが、これらは共通であってもよい。連携情報は、残高連携に関する情報である。例えば、連携情報は、口座が連携する電子マネーを保有するユーザの決済サービスにおけるユーザIDを含む。連携情報は、口座と連携する電子マネーを識別可能な情報を含めばよい。例えば、連携情報は、決済サービスにおけるユーザIDではなく、電子マネーID又はコードIDといった他の情報を含んでもよいし、残高連携用に生成された識別情報を含んでもよい。
[口座残高増加部]
口座残高増加部201は、増加要求受付部101により増加要求が受け付けられた場合に、電子マネーと連携する口座の残高である口座残高を増加させる。第1実施形態では、電子マネーサーバ10から銀行サーバ20に対し、口座残高を増加させるための要求が行われるので、口座残高増加部201は、この要求に基づいて、口座残高を増加させる。例えば、口座残高増加部201は、口座データベースDB2を参照し、要求に含まれる口座識別情報が示す口座の口座残高を、要求が示す増加分だけ増加させる。
第1実施形態では、プレミアム型の電子マネーから口座への自動入金が実行されるので、口座残高増加部201は、増加要求に応じた額を、プレミアム型の電子マネーから口座に自動的に入金することによって、口座残高を増加させる。口座残高増加部201は、自動入金によって減少するプレミアム型の残高の減少分だけ、口座残高が増加するように、プレミアム型の残高と連携する口座残高を増加させる。口座残高増加部201は、口座残高の増加が完了した場合に、電子マネーサーバ10に対し、その旨を示す通知を送信する。口座残高増加部201は、口座に対する振込等の他の行為が行われた場合にも、口座残高を増加可能である。
[口座残高減少部]
口座残高減少部202は、減少要求受付部104により減少要求が受け付けられた場合に、口座残高を減少させる。第1実施形態では、電子マネーサーバ10から銀行サーバ20に対し、口座残高を減少させるための要求が行われるので、口座残高減少部202は、この要求に基づいて、口座残高を減少させる。例えば、口座残高減少部202は、口座データベースDB2を参照し、要求に含まれる口座識別情報が示す口座の口座残高を、要求が示す減少分だけ減少させる。
第1実施形態では、口座からプレミアム型の電子マネーへの自動チャージが実行されるので、口座残高減少部202は、減少要求に応じた額を、口座からプレミアム型の電子マネーに自動的にチャージすることによって、口座残高を減少させる。口座残高減少部202は、自動チャージによって増加するプレミアム型の残高の増加分だけ、口座残高が減少するように、プレミアム型の残高と連携する口座残高を減少させる。口座残高減少部202は、口座残高の減少が完了した場合に、電子マネーサーバ10に対し、その旨を示す通知を送信する。口座残高減少部202は、口座からの出金等の他の行為が行われた場合にも、口座残高を減少可能である。
[1-3-3.ユーザ端末で実現される機能]
データ記憶部300は、記憶部32を主として実現される。表示制御部301及び操作受付部302は、制御部31を主として実現される。
[データ記憶部]
データ記憶部300は、ユーザが決済サービス及び金融サービスの各々を利用するために必要なデータを記憶する。例えば、データ記憶部300は、決済アプリ、コードID、及び銀行アプリを記憶する。ユーザ端末30は、電子マネーサーバ10により発行されたコードIDを受信して自身のデータ記憶部300に記録する。ユーザ端末30は、コードIDの有効期限も受信した場合には、有効期限も自身のデータ記憶部300に記録する。
[表示制御部]
表示制御部301は、任意の画面を表示部35に表示させる。例えば、表示制御部301は、決済アプリ及び銀行アプリの少なくとも一方に基づいて、図2及び図3で説明した画面を表示部35に表示させる。各画面は、ブラウザ上で表示されてもよい。
[操作受付部]
操作受付部302は、ユーザによる任意の操作を受け付ける。例えば、操作受付部302は、図2及び図3で説明した画面に対する操作を受け付ける。
[1-4.第1実施形態の残高連携システムで実行される処理]
図7及び図8は、第1実施形態の残高連携システムSで実行される処理の一例を示す図である。この処理は、制御部11,21,31がそれぞれ記憶部12,22,32に記憶されたプログラムに従って動作することによって実行される。図7及び図8では、残高連携システムSで実行される処理のうち、主に、残高連携後の処理について示している。ユーザは、残高連携の手続を済ませているものとする。
図7のように、ユーザ端末30は、決済アプリを起動させ、電子マネーサーバ10との間で、決済サービスにログインするためのログイン処理を実行する(S100)。S100では、決済サービスにおけるユーザID及びパスワードの入力が要求されてもよいし、過去に決済サービスにログインしたことを示す情報をユーザ端末30に記憶されておき、当該情報に基づいて、決済サービスにおけるユーザID及びパスワードの入力が要求されないようにしてもよい。
決済サービスへのログインが成功すると、ユーザ端末30は、トップ画面G1を表示部35に表示させる(S101)。ユーザは、決済サービスを利用するための各種操作を行う(S102)。ここでは、店舗のPOS端末等にコードC10を読み取らせて支払をするための支払操作、ボタンB14を選択してプレミアム型の残高を送るための送り操作、ボタンB15を選択してプレミアム型の残高にチャージするためのチャージ操作、又は他のユーザから送られたプレミアム型の残高を受け取るための受け取り操作の何れかが行われるものとする。基本型の残高に対する操作等の他の操作が行われた場合には、当該他の操作に応じた処理が実行されて本処理は終了する。
ユーザが支払操作をした場合(S102;支払操作)、電子マネーサーバ10は、コードC10を読み取ったPOS端末等から支払要求を受信する(S103)。電子マネーサーバ10は、支払要求に含まれるコードIDに基づいて、どのユーザに対応する支払要求なのかを特定できる。
電子マネーサーバ10は、決済データベースDB1に基づいて、電子マネーが支払元として設定されており、かつ、残高連携済みのユーザであることを特定すると、銀行サーバ20に対し、プレミアム型の残高に自動的にチャージするための要求である自動チャージ要求を送信する(S104)。自動チャージ要求には、決済サービスにおけるユーザIDと、支払要求に含まれる利用額と同じチャージ額と、が含まれる。なお、S104において、電子マネー以外の決済手段が支払元として設定されている場合、又は、残高連携済みのユーザではないことが特定された場合には、従来の方法と同様にして決済処理が実行され、本処理は終了する。
銀行サーバ20は、自動チャージ要求を受信すると(S105)、電子マネーサーバ10との間で、口座残高を利用してプレミアム型の残高にチャージするための自動チャージ処理を実行する(S106)。S106では、銀行サーバ20は、自動チャージ要求に含まれるユーザIDを含む連携情報が格納されたレコードを特定する。銀行サーバ20は、当該レコードに格納された口座残高を、自動チャージ要求に含まれるチャージ額だけ減少させる。銀行サーバ20は、電子マネーサーバ10に対し、口座残高の減少が完了したことを示す減少完了通知を送信する。電子マネーサーバ10は、減少完了通知を受信すると、プレミアム型の残高をチャージ額だけ増加させる。なお、口座残高がチャージ額よりも少ない場合には、エラーとなり本処理は終了する。
S106の自動チャージ処理が実行されると、電子マネーサーバ10は、プレミアム型の残高に基づいて、決済処理を実行し(S107)、本処理は終了する。S107では、電子マネーサーバ10は、決済データベースDB1に格納されたプレミアム型の残高を、S103で受信した支払要求に含まれる利用額だけ減少させる。決済処理自体は、公知の処理を利用可能である。
S102において、ユーザが送り操作をした場合(S102;送り操作)、ユーザ端末30は、電子マネーサーバ10に対し、送り要求を送信し(S108)、電子マネーサーバ10は、ユーザ端末30から送り要求を受信する(S109)。電子マネーサーバ10は、送り要求に含まれるコードIDに基づいて、どのユーザに対応する送り要求なのかを特定できる。
電子マネーサーバ10は、決済データベースDB1に基づいて、残高連携済みのユーザであることを特定すると、銀行サーバ20に対し、自動チャージ要求を送信する(S110)。S110の自動チャージ要求は、S104の自動チャージ要求と同様である。S110の自動チャージ要求に含まれるチャージ額は、ユーザが指定した送り額と同じである。なお、S110において、残高連携済みのユーザではないことが特定された場合には、従来の方法と同様にして送り処理が実行され、本処理は終了する。
銀行サーバ20は、自動チャージ要求を受信すると(S111)、電子マネーサーバ10との間で、自動チャージ処理を実行する(S112)。S112の自動チャージ処理は、S106の自動チャージ処理と同様である。S112の自動チャージ処理が実行されると、電子マネーサーバ10は、プレミアム型の残高に基づいて、送り処理を実行し(S113)、本処理は終了する。S113では、電子マネーサーバ10は、決済データベースDB1に格納されたプレミアム型の残高を、S109で受信した送り要求に含まれる送り額だけ減少させる。送り処理自体は、公知の処理を利用可能である。
S102において、ユーザがチャージ操作をした場合(S102;チャージ操作)、図8に移り、ユーザ端末30は、電子マネーサーバ10に対し、チャージ要求を送信し(S114)、電子マネーサーバ10は、ユーザ端末30からチャージ要求を受信する(S115)。電子マネーサーバ10は、チャージ要求に含まれるコードIDに基づいて、どのユーザに対応するチャージ要求なのかを特定できる。
電子マネーサーバ10は、S115で受信したチャージ要求に基づいて、プレミアム型の残高に対するチャージ処理を実行する(S116)。S116では、電子マネーサーバ10は、チャージ要求に含まれるチャージ方法情報を参照し、ユーザが指定したチャージ方法を特定する。電子マネーサーバ10は、ユーザが指定したチャージ方法で、チャージ要求に含まれるチャージ額だけチャージされるように、プレミアム型の残高に対するチャージ処理を実行する。S116におけるチャージ処理自体は、公知のチャージ処理であってよい。なお、S115で基本型の残高のチャージ要求が受信された場合には、基本型の残高に対するチャージ処理が実行され、本処理は終了する。
電子マネーサーバ10は、決済データベースDB1に基づいて、残高連携済みのユーザであることを特定すると、銀行サーバ20に対し、自動入金要求を送信する(S117)。自動入金要求には、決済サービスにおけるユーザIDと、チャージ要求に含まれるチャージ額と同じ入金額と、が含まれる。なお、S117において、残高連携済みのユーザではないことが特定された場合には、自動入金要求は送信されない。
銀行サーバ20は、自動入金要求を受信すると(S118)、電子マネーサーバ10との間で、自動入金処理を実行し(S119)、本処理は終了する。S119では、銀行サーバ20は、自動入金要求に含まれるユーザIDを含む連携情報が格納されたレコードを特定する。銀行サーバ20は、当該レコードに格納された口座残高を、自動入金要求に含まれる入金額だけ増加させる。銀行サーバ20は、電子マネーサーバ10に対し、口座残高の増加が完了したことを示す増加完了通知を送信する。電子マネーサーバ10は、増加完了通知を受信すると、プレミアム型の残高を入金額だけ減少させる。
S102において、ユーザが受取操作をした場合(S102;受取操作)、図8に移り、ユーザ端末30は、電子マネーサーバ10に対し、受取要求を送信し(S120)、電子マネーサーバ10は、ユーザ端末30から受取要求を受信する(S121)。電子マネーサーバ10は、受取要求に含まれるコードIDに基づいて、どのユーザに対応する受取要求なのかを特定できる。
電子マネーサーバ10は、S121で受信した受取要求に基づいて、プレミアム型の残高に対する受取処理を実行する(S122)。S122では、電子マネーサーバ10は、受取要求に含まれる情報を参照し、ユーザが受け取る受取額を特定する。電子マネーサーバ10は、ユーザが受け取る受取額だけチャージされるように、プレミアム型の残高に対するチャージ処理を実行する。S122における受取処理自体は、公知のチャージ処理であってよい。なお、S121で基本型の残高の受取要求が受信された場合には、基本型の残高に対する受取処理が実行され、本処理は終了する。
電子マネーサーバ10は、決済データベースDB1に基づいて、残高連携済みのユーザであることを特定すると、銀行サーバ20に対し、自動入金要求を送信する(S123)。自動入金要求には、決済サービスにおけるユーザIDと、受取要求に含まれる受取額と同じ入金額と、が含まれる。なお、S123において、残高連携済みのユーザではないことが特定された場合には、自動入金要求は送信されない。
銀行サーバ20は、自動入金要求を受信すると(S124)、電子マネーサーバ10との間で、自動入金処理を実行し(S125)、本処理は終了する。S125の自動入金処理は、S119の自動入金処理と同様である。
第1実施形態の残高連携システムSによれば、プレミアム型の残高を増加させるための増加要求が受け付けられた場合に、プレミアム型の残高と連携する口座残高を増加させる。残高連携システムSは、プレミアム型の残高を減少させるための減少要求が受け付けられた場合に、プレミアム型の残高と連携する口座残高を減少させる。これにより、プレミアム型の残高と、口座残高と、を十分に連携させることができるので、ユーザの利便性が高まる。例えば、ユーザが支払操作をした場合に、より多くの資金がある口座残高を減少させることによって、プレミアム型の残高を利用した決済処理を実行できるので、ユーザの利便性が高まる。例えば、ユーザが送り操作をした場合に、より多くの資金がある口座残高を減少させることによって、プレミアム型の残高を利用した送り処理を実行できるので、ユーザの利便性が高まる。例えば、ユーザがチャージ操作をした場合に、プレミアム型の残高からの出金操作をしなくても、連携先の口座を増加させることができるので、ユーザの利便性が高まる。例えば、ユーザが受取操作をした場合に、プレミアム型の残高からの出金操作をしなくても、連携先の口座を増加させることができるので、ユーザの利便性が高まる。ユーザの利便性が高まることにより、電子マネーの利用を促進し、口座残高の利用を促進することもできる。プレミアム型の残高を口座残高に移行することによって、本来は金利が発生しないプレミアム型の残高分についても金利を発生させることができる。プレミアム型の残高を口座残高に移行することにより、プレミアム型の残高を実質的に0円にすることができるので、未達債務及び滞留規制を回避できる。例えば、ユーザの勤務先がユーザの給与を電子マネーとして払いやすくなるので、給与デジタル払いを実現しやすくなる。
また、残高連携システムSは、増加要求に応じた額を、電子マネーから口座に自動的に入金することによって、口座残高を増加させる。残高連携システムSは、減少要求に応じた額を、口座から電子マネーに自動的にチャージすることによって、口座残高を減少させる。自動入金処理及び自動チャージ処理によって残高連携を実現し、ユーザの利便性が高まる。
[2.第2実施形態]
第1実施形態では、プレミアム型の残高から口座残高への自動入金と、口座残高からプレミアム型の残高への自動チャージと、が実行されることによって、残高連携が実現される場合を例に挙げた。第2実施形態では、プレミアム型の残高と、口座残高と、が互いに同期することによって、残高連携が実現される場合を例に挙げる。第2実施形態では、第1実施形態と同様の構成については説明を省略する。
図9は、第2実施形態における残高連携の一例を示す図である。第2実施形態では、プレミアム型の残高として、精算用の残高と、連携用の残高と、の2つが存在するものとする。精算用の残高は、ユーザが保有する資産としての残高である。第2実施形態では、精算用の残高は、0円で固定されるものとする。このため、ユーザは、事実上の資産としては、プレミアム型の残高を保有していないことになる。
連携用の残高は、電子マネーと口座が連携するための仮想的な残高である。連携用の残高は、事実上の資産ではない。連携用の残高は、口座残高と連携するための数値的なデータにすぎない。連携用の残高は、口座残高と同期が行われる。このため、原則として、連携用の残高と、口座残高と、は互いに一致する。図9の例では、連携用の残高は、口座残高と同じ1203500円になる。ただし、ユーザは、1203500円分の電子マネーと、1203500円の現金と、の両方を保有しているのではなく(即ち、ユーザの資産が2407000円というわけではなく)、ユーザが保有する資産としては、口座残高である1203500円の現金だけである。
例えば、図9の状態で、ユーザがボタンB15を選択し、プレミアム型の残高に1000円分チャージしたとする。プレミアム型の連携用の残高は、1204500円に増加する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が1204500円に増加する。この場合、プレミアム型の精算用の残高は、0円のまま変わらないものとするが、同期が取られるまでは、精算用の残高がチャージ処理によって1000円になり、同期が取られた後に、精算用の残高が0円に戻ってもよい。
例えば、図9の状態で、ユーザが、他のユーザから2000円分のプレミアム型の残高を受け取ったとする。プレミアム型の連携用の残高は、1205500円に増加する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が1205500円に増加する。この場合、プレミアム型の精算用の残高は、0円のまま変わらないものとするが、同期が取られるまでは、精算用の残高が受取処理によって2000円になり、同期が取られた後に、精算用の残高が0円に戻ってもよい。
例えば、図9の状態で、ユーザが店舗のPOS端末にコードC10を読み取らせて、3000円の買い物をしたとする。プレミアム型の連携用の残高は、1200500円に減少する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が1200500円に減少する。この場合、プレミアム型の精算用の残高は、0円のまま変わらないものとするが、同期が取られるまでは、精算用の残高が決済処理によってマイナス3000円になり、同期が取られた後に、精算用の残高が0円に戻ってもよい。
例えば、図9の状態で、ユーザが、他のユーザに4000円分のプレミアム型の残高を送ったとする。プレミアム型の連携用の残高は、1199500円に減少する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が1199500円に減少する。この場合、プレミアム型の精算用の残高は、0円のまま変わらないものとするが、同期が取られるまでは、精算用の残高が決済処理によってマイナス4000円になり、同期が取られた後に、精算用の残高が0円に戻ってもよい。
なお、ユーザの口座残高が何らかの理由で増減した場合には、当該増減された口座残高に合うように、プレミアム型の連携用の残高が同期される。例えば、ユーザがATMから口座の現金を引き出した場合には、口座残高が減少するので、減少後の口座残高に合うように、プレミアム型の連携用の残高が同期される。例えば、ユーザの勤務先が口座に給与を振り込んだ場合には、口座残高が増加するので、増加後の口座残高に合うように、プレミアム型の連携用の残高が同期される。
以上のように、第2実施形態の残高連携システムSでは、プレミアム型の残高と、口座の残高と、を同期させることによって、残高連携を実現するようになっている。以降、第2実施形態の詳細を説明する。
[2-1.第2実施形態の残高連携システムで実現される機能]
図10は、第2実施形態の残高連携システムSで実現される機能の一例を示す図である。同期部107は、制御部11を主として実現される。同期部107は、口座残高増加部103及び口座残高減少部106を含む。同期部203は、制御部21を主として実現される。同期部203は、口座残高増加部201及び口座残高減少部202を含む。
第2実施形態の決済データベースDB1には、電子マネー残高の更新日時が電子マネー情報に含まれているものとする。電子マネーサーバ10は、電子マネー残高を更新すると、現在日時が更新日時として電子マネー情報に含まれるように、決済データベースDB1を更新する。第2実施形態でも、プレミアム型の残高と、基本型の残高と、が存在するので、電子マネー情報には、プレミアム型の残高の更新日時と、基本型の残高の更新日時と、が含まれる。第2実施形態の電子マネー情報は、プレミアム型の残高として、精算用の残高と、連携用の残高と、を含む。第2実施形態では、精算用の残高が0円で固定されているので、電子マネー情報は、精算用の残高の更新日時ではなく、連携用の残高の更新日時を含む。
第2実施形態の口座データベースDB2には、口座残高の更新日時が格納されているものとする。銀行サーバ20は、口座残高を更新すると、現在日時が更新日時として当該口座残高に関連付けられるように、口座データベースDB2を更新する。口座残高は、残高連携以外にも増減することがあるので、この場合にも、口座残高の更新日時が口座データベースDB2に格納される。例えば、ユーザがATMから現金を引き出したり、ユーザの給与振込が行われたりした場合には、口座残高が更新されるので、更新日時が口座データベースDB2に格納される。
[電子マネーサーバ及び銀行サーバの同期部]
同期部107,203は、電子マネー残高及び口座残高を同期させる。同期とは、電子マネー残高及び口座残高を一致させることである。電子マネーサーバ10の同期部107と、銀行サーバ20の同期部203と、が協働することによって、同期が実現される。同期では、電子マネー残高に口座残高が合う(口座残高だけが変わる)第1パターン、口座残高に電子マネー残高が合う(電子マネー残高だけが変わる)第2パターン、電子マネー残高と口座残高の何れも変わらない第3パターン、及び電子マネー残高と口座残高の両方が変わる第4パターンの4パターンが存在する。ここでは、プレミアム型の残高のうちの連携用の残高を、単に電子マネー残高という。
第2実施形態では、同期部107,203は、第1パターン~第4パターンの何れかの同期を実行する。電子マネー残高及び口座残高の同期自体は、種々のデータ同期手法を利用可能である。例えば、同期部107は、銀行サーバ20に対し、電子マネー残高と、電子マネー残高の更新日時と、を送信する。同期部203は、電子マネーサーバ10に対し、口座残高と、口座残高の更新日時と、を送信する。同期部107,203は、互いにこれの情報を送りあい、何れのパターンであるかを特定し、同期を実行する。ここでは、一定時間ごとに、同期が実行される場合を説明する。この一定時間は、任意の長さであってよく、例えば、数秒以内であってもよいし、それ以上の時間間隔であってもよい。
例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新され、かつ、口座残高が更新されていない場合には、第1パターンになる。この場合、同期部107,203は、互いに協働して、口座残高が電子マネー残高と同じ値になるように、口座残高を更新する。例えば、同期部107は、銀行サーバ20から口座残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、電子マネー残高を変えない。同期部203は、電子マネーサーバ10から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、電子マネーサーバ10から受信した電子マネー残高と一致するように、口座残高を更新する。
例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新されておらず、かつ、口座残高が更新された場合には、第2パターンになる。この場合、同期部107,203は、互いに協働して、電子マネー残高が口座残高と同じ値になるように、電子マネー残高を更新する。例えば、同期部107は、銀行サーバ20から口座残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、銀行サーバ20から受信した口座残高と一致するように、電子マネー残高を更新する。同期部203は、電子マネーサーバ10から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、口座残高を変えない。
例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新されておらず、かつ、口座残高も更新されていない場合には、第3パターンになる。この場合、同期部107,203は、互いに協働して、電子マネー残高及び口座残高が変わらないようにする。例えば、同期部107は、銀行サーバ20から口座残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、電子マネー残高を変えない。同期部203は、電子マネーサーバ10から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、口座残高を変えない。
例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新され、かつ、口座残高も更新された場合には、第4パターンになる。この場合、同期部107,203は、互いに協働して、電子マネー残高及び口座残高の両方が変わるようにする。例えば、同期部107は、銀行サーバ20から口座残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、前回の同期時からの口座残高の変化量だけ、電子マネー残高を変える。前回の同期時の口座残高は、決済データベースDB1に保持されていてもよいし、銀行サーバ20から電子マネーサーバ10に送信されてもよい。口座残高の変化量が銀行サーバ20から電子マネーサーバ10に送信されてもよい。同期部203は、電子マネーサーバ10から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、前回の同期時からの電子マネー残高の変化量だけ、口座残高を変える。前回の同期時の口座残高は、口座データベースDB2に保持されていてもよいし、電子マネーサーバ10から銀行サーバ20に送信されてもよい。電子マネー残高の変化量が電子マネーサーバ10から銀行サーバ20に送信されてもよい。
例えば、第1パターン又は第4パターンでは、第2同期部107の口座残高増加部103は、電子マネー残高増加部102により増加した電子マネー残高を、口座残高に同期させることによって、口座残高を増加させることがある。同様に、第1パターン又は第4パターンでは、同期部107の口座残高減少部106は、電子マネー残高減少部105により減少した電子マネー残高を、口座残高に同期させることによって、口座残高を減少させることがある。このため、第1パターン又は第4パターンにおける同期は、口座残高増加部103又は口座残高減少部106の処理の一例である。
第2実施形態では、同期部107,203は、所定の同期条件が満たされた場合に、電子マネー残高及び口座残高を同期させる。同期条件は、同期するか否かの基準となる条件である。第2実施形態では、定期的に同期が取られる場合を説明する。同期条件が満たされたか否かは、同期部107,203の両方によって判定されてもよいし、同期部107,203の何れか一方が判定して他方に通知してもよい。同期条件が満たされるまでは、同期は行われず、同期条件が満たされた場合に同期が行われる。
なお、同期条件は、任意の条件であってよく、第2実施形態のような時間的な条件に限られない。例えば、電子マネー残高又は口座残高の何れか一方が更新されることが同期条件になってもよい。この場合、定期的に同期が取られるのではなく、電子マネー残高又は口座残高の何れかが更新されるたびに同期が取られる。電子マネー残高及び口座残高の両方が同時に更新された場合には、第4パターンのように同期が取られるようにすればよい。同期条件は、ユーザが何らかの操作を行うといった他の条件であってもよい。
第2実施形態では、プレミアム型の電子マネーは、精算用の電子マネー残高と、連携用の電子マネー残高と、を有する。先述したように、第2実施形態では、精算用の電子マネー残高は、0円で固定されていてもよい。電子マネー残高増加部102は、精算用の電子マネー残高は増加させずに、連携用の電子マネー残高を増加させる。電子マネー残高減少部105は、精算用の電子マネー残高は減少させずに、連携用の電子マネー残高を減少させる。同期部107は、連携用の電子マネー残高と、口座残高と、を同期させる。
[2-2.第2実施形態の残高連携システムで実現される処理]
図11は、第2実施形態の残高連携システムSで実行される処理の一例を示す図である。図11の処理は、先述した4つのパターンのうち、主に第1パターンに関する処理である。第1実施形態で説明した図7の処理と同様に、ユーザは、残高連携の手続を完了しているものとする。また、第1実施形態と同様に、プレミアム型の残高に対する処理について説明する。
図11のS200~S203の処理は、S100~S103の処理と同様である。電子マネーサーバ10は、決済データベースDB1に基づいて、電子マネーが支払元として設定されており、かつ、残高連携済みのユーザであることを特定すると、連携用の残高が店舗等における支払額だけ減少するように、決済処理を実行する(S204)。その後、電子マネーサーバ10及び銀行サーバ20の間で、同期処理が実行され(S205)、本処理は終了する。この場合、決済処理により連携用の残高が減少しているので、同期処理により、減少した連携用の残高に合うように、口座残高が減少する。
S202において、ユーザが送り操作をした場合(S202;送り操作)、S108及びS109の処理と同様のS206及びS207の処理が実行される。電子マネーサーバ10は、決済データベースDB1に基づいて、残高連携済みのユーザであることを特定すると、連携用の残高が他のユーザへの送り額だけ減少するように、送り処理を実行する(S208)。その後、S205の同期処理が実行され、本処理は終了する。この場合、送り処理により連携用の残高が減少しているので、同期処理により、減少した連携用の残高に合うように、口座残高が減少する。
S202において、ユーザがチャージ操作をした場合(S202;チャージ操作)、S114及びS115の処理と同様のS209及びS210の処理が実行される。電子マネーサーバ10は、残高連携済みのユーザであることを特定すると、連携用の残高がチャージ額だけ増加するように、チャージ処理を実行する(S211)。その後、S205の同期処理が実行され、本処理は終了する。この場合、チャージ処理により連携用の残高が増加しているので、同期処理により、増加した連携用の残高に合うように、口座残高が増加する。
S202において、ユーザが受取操作をした場合(S202;受取操作)、S120及びS121の処理と同様のS212及びS213の処理が実行される。電子マネーサーバ10は、残高連携済みのユーザであることを特定すると、連携用の残高が受取額だけ増加するように、受取処理を実行する(S214)。その後、S205の同期処理が実行され、本処理は終了する。この場合、受取処理により連携用の残高が増加しているので、同期処理により、増加した連携用の残高に合うように、口座残高が増加する。
なお、第2実施形態では、決済処理、送り処理、チャージ処理、及び受取処理が実行された後に、同期処理が実行される場合を説明したが、同期処理が実行された後に、決済処理、送り処理、チャージ処理、及び受取処理が実行されてもよい。特に、決済処理及び送り処理のように、連携用の残高が減少する処理については、同時に口座残高からの引出又は振込が行われるとユーザの資金が足りなくなることがあるので、同期処理によってユーザの資金が足りることが確認された後に、決済処理及び送り処理が実行されてもよい。同様に、口座残高からの引出又は振込が行われる場合も同様に、同期処理が実行された後に、口座残高からの引出又は振込が行われてもよい。
第2実施形態によれば、チャージ処理又は受取処理により増加した電子マネー残高を、口座残高に同期させることによって、口座残高を増加させる。決済処理又は送り処理により減少した電子マネー残高を、口座残高に同期させることによって、口座残高を減少させる。同期処理によって、プレミアム型の残高と、口座残高と、を十分に連携させることができるので、ユーザの利便性が高まる。更に、第1実施形態で説明したような自動入金及び自動チャージが必要無くなるので、決済処理等の各処理の完了までに要する時間を短くすることができる。
第2実施形態の残高連携システムSは、精算用の電子マネー残高は増加させずに、連携用の電子マネー残高を増加させる。残高連携システムSは、精算用の電子マネー残高は減少させずに、連携用の電子マネー残高を減少させる。残高連携システムSは、連携用の電子マネー残高と、口座残高と、を同期させる。これにより、第1実施形態と同様に、本来は金利が発生しないプレミアム型の残高分についても金利を発生させることができ、かつ、未達債務及び滞留規制を回避しやすくなる。
第2実施形態の残高連携システムSは、精算用の電子マネー残高は、0円で固定されている。これにより、より多くの資金を口座に移すことができるので、より多くの金利を得ることができ、かつ、未達債務及び滞留規制をより回避しやすくなる。
[3.変形例]
なお、本開示は、以上に説明した第1実施形態及び第2実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。以降説明する変形例では、第2実施形態のように、電子マネー残高及び口座残高が同期する場合を例に挙げるが、第1実施形態のように、電子マネーから口座への自動入金と、口座から電子マネーへの自動チャージと、が行われる場合にも、同様の変形例を適用可能である。
図12は、変形例における機能ブロックの一例を示す図である。第1制限部108、指定受付部109、手数料発生部110、表示制御部111、及び上限設定部112は、制御部11を主として実現される。第2制限部204、増加要求受付部205、関連付け部206、及び口座残高移動部207は、制御部21を主として実現される。
[3-1.変形例1]
例えば、第2実施形態の残高連携システムSにおいて、通信障害等の何らかの障害によって、電子マネー残高及び口座残高が同期されない可能性がある。この場合、ユーザが、電子マネーを利用した直後に口座残高を全額引き出したとすると、ユーザが本来所有する資産よりも多くの額を引き出せることになる。このため、電子マネー残高及び口座残高が同期されなかった場合に、電子マネー残高及び口座残高の少なくとも一方の利用が制限されてもよい。以降、電子マネー残高及び口座残高の両方の利用が制限される場合を例に挙げる。
変形例1の電子マネーサーバ10及び銀行サーバ20は、同期条件が満たされた場合に、同期が行われたか否かを判定する。例えば、電子マネーサーバ10及び銀行サーバ20は、同期条件が満たされた場合に、互いの通信が可能か否かを判定する。この判定方法自体は、通信障害の発生有無を判定可能な公知の方法を利用可能である。電子マネーサーバ10及び銀行サーバ20は、互いの通信が可能ではないと判定した場合に、同期が行われなかったと判定する。例えば、電子マネーサーバ10及び銀行サーバ20は、互いの通信自体は可能であるが、第2実施形態で説明した同期の処理が最後まで完了しなかった場合にも、同期が行われなかったと判定する。
変形例1の残高連携システムSは、第1制限部108及び第2制限部204を含む。第1制限部108は、同期条件が満たされても同期が行われなかった場合に、電子マネー残高の利用を制限する。電子マネー残高の利用を制限するとは、電子マネー残高の全部又は一部を利用できないようにすることである。例えば、電子マネー残高が減少しないようにすることは、電子マネー残高の利用を制限することに相当する。例えば、電子マネー残高の減少自体は許可するが、減少量が閾値以下になる範囲で許可することは、利用を制限することに相当する。他にも例えば、電子マネー残高を利用可能な回数を閾値未満にすること、電子マネー残高を利用可能な総額を閾値未満にすることが、電子マネー残高の利用を制限することに相当してもよい。
変形例1では、第1制限部108が、電子マネー残高を所定の範囲内でのみ利用できるように制限する場合を説明する。この範囲は、任意の値を設定可能である。電子マネーの利用を許可する範囲の設定は、決済サービスの管理者によって行われてもよいし、ユーザが自分で指定してもよい。例えば、第1制限部108は、数千円程度の少額の決済処理又は送り処理であれば許可するが、それ以上の高額の決済処理又は送り処理については許可しない。第1制限部108は、電子マネー残高を一切利用できないように制限してもよい。
第2制限部204は、同期条件が満たされても同期が行われなかった場合に、口座残高の利用を制限する。口座残高の利用を制限するとは、口座残高の全部又は一部を利用できないようにすることである。例えば、口座残高が減少しないようにすることは、口座残高の利用を制限することに相当する。例えば、口座残高の減少自体は許可するが、減少量が閾値以下になる範囲で許可することは、利用を制限することに相当する。他にも例えば、口座残高を利用可能な回数を閾値未満にすること、口座残高を利用可能な総額を閾値未満にすることが、口座残高の利用を制限することに相当してもよい。
変形例1では、第2制限部204が、口座残高を所定の範囲内でのみ利用できるように制限する場合を説明する。例えば、第2制限部204は、数千円程度の範囲内の振込又は引出であれば許可するが、それ以上の振込又は引出については許可しない。この範囲は、任意の値を設定可能である。口座の利用を許可する範囲の設定は、金融サービスの管理者によって行われてもよいし、ユーザが自分で指定してもよい。第2制限部204は、口座残高を一切利用できないように制限してもよい。
なお、残高連携システムSは、第2制限部204を含まなくてもよい。この場合、電子マネー残高及び口座残高のうち、利用が制限されるのは、電子マネー残高のみとなる。逆に、残高連携システムSは、第1制限部108を含まなくてもよい。この場合、電子マネー残高及び口座残高のうち、利用が制限されるのは、口座残高のみとなる。変形例1の残高連携システムSは、第1制限部108及び第2制限部204の少なくとも一方を含み、通信障害等が発生した場合に、電子マネー残高及び口座残高の少なくとも一方の利用を制限すればよい。
変形例1の残高連携システムSは、同期条件が満たされても同期が行われなかった場合に、電子マネー残高及び口座残高の少なくとも一方の利用を制限する。これにより、電子マネー残高及び口座残高の少なくとも一方が不当に利用されるといったことを防止できる。例えば、ユーザが電子マネー残高を利用した直後に、電子マネー残高及び口座残高が同期していないにもかかわらず、口座残高が全額引き出されるといったことを防止できる。逆に、ユーザが口座残高を利用した直後に、電子マネー残高及び口座残高が同期していないにもかかわらず、電子マネー残高の全額を支払で利用するといったことを防止できる。
[3-2.変形例2]
例えば、ユーザが銀行に口座を開設していない場合には、ユーザに、電子マネー専用の振込入金口座を開設してもらうようにしてもよい。振込入金口座は、いわゆる仮想口座(仮口座)であり、通常の口座(実口座)とは異なる。振込入金口座は、残高が0円で固定されている。振込入金口座を開設するための手順は、通常の口座を開設する手順と同様であってもよいが、変形例2では、通常の口座よりも簡易的であるものとする。例えば、ユーザがプレミアム型の利用を開始する際に、決済サービスでeKYCと呼ばれる本人確認が行われた場合には、決済サービスにおける本人確認の結果が流用されてもよい。
図13は、変形例2の概要を示す図である。変形例2では、電子マネーと連携する口座は、複数のユーザに共通の親口座である。親口座の名義人は、複数のユーザに共通である。変形例2では、親口座の名義人が電子マネーの事業者である「AAAキャッシュ株式会社」であるものとするが、親口座の名義人は、他の名義人であってもよい。変形例2では、親口座が、電子マネーの管理者の法人支店である「AAAキャッシュ支店」に開設されている場合を説明するが、親口座は、任意の支店に開設可能である。例えば、他のユーザの実口座が開設されている支店と同じ支店に、親口座が開設されてもよい。
親口座には、複数のユーザの各々に関連付けられた、当該ユーザの電子マネー残高を増加させるための振込入金口座が関連付けられている。このため、親口座と、振込入金口座と、は1対多で対応する。1つの親口座には、任意の数の振込入金口座を関連付けることができる。例えば、数個~数十個程度の振込入金口座が親口座に関連付けられてもよいし、それ以上の振込入金口座が親口座に関連付けられてもよい。変形例2では、振込入金口座が、いわゆる仮想口座であり、残高が0円で固定されているものとするが、振込入金口座は、1円以上の残高を有することができてもよい。
変形例2では、銀行サーバ20は、増加要求受付部205を含む。増加要求の意味は、第1実施形態で説明した通りであるが、変形例2では、振込入金口座に対する入金が電子マネーの増加要求に相当する。増加要求受付部205は、振込入金口座に対する振込要求を、増加要求として受け付ける。振込要求は、振込入金口座に対する振込をするための要求である。振込要求自体は、公知の金融サービスで利用されている要求であってよい。例えば、振込要求は、振込先の金融機関、支店名、口座番号、名義人、及び振込額を含む。振込額は、プレミアム型の残高に対するチャージ額に相当する。振込入金口座は、他のユーザからの振込を受け付けてもよい。この場合、振込額は、ユーザに対するプレミアム型の残高の送り額に相当する。
口座残高増加部201は、振込要求が受け付けられた場合に、振込入金口座から親口座に自動的に入金することによって、親口座を増加させる。変形例2では、振込入金口座の残高が0円で固定されているので、口座残高増加部201は、振込入金口座の残高を増加させることなく、振込入金口座から親口座への入金を実行する。振込入金口座の残高は、一時的に増加してもよい。この場合、口座残高増加部201は、振込入金口座の残高を振込額だけ増加させた直後に、振込入金口座から親口座への入金を実行すればよい。
変形例2の親口座の口座残高は、複数のユーザに共通の共通残高である。このため、親口座の共通残高は、複数のユーザの各々の個別残高の合計である。図13の例では、ユーザX,Y,Zの3人の振込入金口座が親口座に関連付けられている。ユーザXが自身の振込入金口座に30000円を入金し、ユーザYが自身の振込入金口座に20000円を入金し、ユーザZが自身の振込入金口座に10000円を入金したとする。この場合、親口座には、ユーザX~Zによる入金の総額である60000円が親口座の共通残高になる。
親口座には、ユーザごとの個別残高が関連付けられている。図13の例では、データ記憶部200に記憶された個別残高データベースDB3に、ユーザごとの個別残高が格納されている。例えば、親口座の共通残高である60000円のうち、ユーザXの個別残高が30000円であることが、個別残高データベースDB3に示される。親口座の共通残高である60000円のうち、ユーザYの個別残高が20000円であることが、個別残高データベースDB3に示される。親口座の共通残高である60000円のうち、ユーザZの個別残高が10000円であることが、個別残高データベースDB3に示される。個別残高データベースDB3には、個々のユーザのユーザ識別情報と、このユーザの個別残高と、が関連付けられている。
口座残高増加部201は、増加要求が受け付けられた場合に、共通残高及び個別残高を増加させる。例えば、口座残高増加部201は、あるユーザの振込入金口座に対する入金が増加要求として行われた場合に、この入金の額だけ、この振込入金口座に関連付けられた親口座の共通残高と、このユーザの個別残高と、の両方を増加させる。口座残高増加部201は、あるユーザのプレミアム型のチャージ又は受取が発生した場合も、このユーザに関連付けられた親口座の共通残高と、このユーザの個別残高と、の両方を増加させる。
口座残高減少部202は、減少要求が受け付けられた場合に、共通残高及び個別残高を減少させる。変形例2では、振込入金口座しか保有していないユーザは、親口座からの出金はできないものとする。このため、口座残高減少部202は、あるユーザのプレミアム型の支払又は送りが発生した場合に、減少要求に応じた額だけ、このユーザに関連付けられた親口座の共通残高と、このユーザの個別残高と、の両方を減少させる。
変形例2の残高連携システムSは、親口座には、複数のユーザの各々の振込入金口座が関連付けられており、振込入金口座に対する振込要求が、増加要求として受け付けられる。残高連携システムSは、振込要求が受け付けられた場合に、振込入金口座から親口座に自動的に入金することによって、親口座を増加させる。これにより、ユーザが振込入金口座を利用して手軽に電子マネーのチャージをすることができる。例えば、ユーザの勤務先の給与を振込入金口座に入金してもらえば、すぐに電子マネーとして利用することができるので、実質的に給与デジタル払いを実現できる。
また、残高連携システムSは、増加要求が受け付けられた場合に、共通残高及び個別残高を増加させ、減少要求が受け付けられた場合に、共通残高及び個別残高が減少させる。これにより、複数のユーザに共通の親口座にしたとしても、個々のユーザの個別残高を正確に管理できる。
[3-3.変形例3]
例えば、変形例2において、同じ親口座のユーザ間で電子マネーが送られる場合には、親口座の共通残高が変更されずに、電子マネーを送る側のユーザの個別残高と、電子マネーを受け取る側のユーザの個別残高と、が変更される。図13の例において、ユーザXが、ユーザZに対し、2000円分のプレミアム型の残高を送ったとする。この場合、親口座の共通残高は、60000円のまま変化しない。個別残高データベースDB3におけるユーザXの個別残高が30000円から28000円に減少する。個別残高データベースDB3におけるユーザZの個別残高が10000円から12000円に増加する。
変形例3では、親口座が同じユーザ間でプレミアム型の残高が送られた場合には、親口座の共通残高は変化せずに、電子マネーを送る側のユーザの個別残高が減少し、かつ、電子マネーを受け取る側のユーザの個別残高が増加する。口座残高減少部202は、口座残高減少部106と協働して、電子マネーを送る側のユーザの個別残高を、送り要求に応じた送り額だけ減少させる。口座残高増加部201は、口座残高増加部103と協働して、電子マネーを受け取る側のユーザの個別残高を、送り要求に応じた送り額だけ増加させる。電子マネーサーバ10内で実行される処理と、電子マネーサーバ10及び銀行サーバ20の間で実行される処理と、は第1実施形態又は第2実施形態で説明した通りである。
変形例3の残高連携システムSは、同じ親口座のユーザ間で電子マネーが送られる場合には、親口座の残高を変更せずに、電子マネーを送る側のユーザの個別残高と、電子マネーを受け取る側のユーザの個別残高と、を変更する。これにより、親口座から他の口座への振込が発生せず、個別残高データベースDB3を更新すれば済むため、銀行サーバ20の負荷を軽減できる。
[3-4.変形例4]
例えば、減少要求受付部104は、店舗で電子マネーが利用される場合に、減少要求を受け付けてもよい。この減少要求は、第1実施形態及び第2実施形態で説明した支払要求である。店舗は、決済サービスのユーザの1人であり、決済処理により支払われた電子マネーの残高は、店舗が保有する電子マネーの残高に移動してもよい。店舗の電子マネー残高は、店舗を利用したユーザの電子マネー残高の減少分だけ増加する。店舗は、親口座とは別の店舗用親口座に関連付けられていてもよい。店舗が保有する電子マネーの仕組みは、第1実施形態、第2実施形態、及び変形例1~3で説明したものと同様であってよい。
変形例4では、ユーザの親口座と、店舗用親口座と、は金融機関、支店、及び名義人が同じであるものとする。例えば、店舗用親口座も「BBB銀行」の「AAAキャッシュ支店」に開設されている。店舗用親口座の名義人も「AAAキャッシュ株式会社」であるものとする。変形例4の口座残高減少部106は、減少要求が受け付けられた場合に、親口座から店舗用親口座への振替を行うことによって、口座残高を減少させる。金融機関、支店、及び名義人が同じため、振替扱いによって、店舗への支払が完了することになる。振替の処理自体は、公知の処理を利用可能である。
例えば、図13の例において、ユーザXが店舗で支払操作をして3000円分の買い物をしたとする。この場合、ユーザXの親口座の共通残高が60000円から57000円に減少し、個別残高データベースDB3におけるユーザXの個別残高が30000円から27000円に減少する。図13には示さない店舗用親口座の残高は、3000円分増加する。複数の店舗に共通の店舗用親口座とする場合、店舗用親口座にも個別残高データベースDB3が関連付けられており、店舗ごとの個別残高が格納されている。この場合、ユーザによる支払を受けた店舗の個別残高が3000円分増加する。
変形例4の残高連携システムSは、ユーザの親口座と、店舗用親口座と、は金融機関、支店、及び名義人が同じなので、減少要求が受け付けられた場合に、親口座から店舗用親口座への振替を行うことによって、口座残高を減少させる。これにより、振込手数料を発生させることなく、店舗への支払が可能になる。
[3-5.変形例5]
例えば、ユーザが、変形例2で説明した振込入金口座を開設した後に、銀行に実口座を開設することがある。この場合、ユーザが新たに開設した実口座の口座残高と、ユーザの電子マネー残高と、が連携するようにしてもよい。即ち、ユーザがそれまで利用していた振込入金口座及び親口座ではなく、ユーザが新たに開設した実口座が残高連携で利用されるようにしてもよい。
変形例5の残高連携システムSは、ユーザが実口座を開設した場合に、当該ユーザの電子マネーと、振込入金口座及び親口座と、の関連付けを解除し、かつ、当該ユーザの電子マネーと、当該ユーザの実口座と、を関連付ける関連付け部206を更に含む。変形例2で説明したように、ユーザが振込入金口座を利用する場合には、口座データベースDB2に、ユーザの振込入金口座、親口座、及びユーザの電子マネー識別情報(図6の例では、連携情報が示すユーザID)が関連付けられているものとする。
変形例5では、関連付け部206は、口座データベースDB2における、振込入金口座及び親口座と、ユーザの電子マネー識別情報と、の関連付けを解除する。例えば、関連付け部206は、振込入金口座及び親口座の情報を口座データベースDB2から削除する。関連付け部206は、ユーザが新たに作成した実口座の支店、口座番号、名義人、及び口座残高が、振込入金口座に代えて口座データベースDB2に格納する。
関連付け部206による処理が実行された後は、実口座を開設したユーザの電子マネーと、振込入金口座及び親口座と、が連携する状態から、当該ユーザの電子マネーと、当該ユーザの実口座と、が連携する状態に変わる。即ち、変形例2のような状態から、第1実施形態又は第2実施形態のような状態に変わる。連携する口座が変わった後の処理は、第1実施形態又は第2実施形態で説明した通りである。
変形例5の残高連携システムSは、ユーザが実口座を開設した場合に、当該ユーザの電子マネーと、振込入金口座及び親口座と、の関連付けを解除し、かつ、当該ユーザの電子マネーと、当該ユーザの実口座と、を関連付ける。これにより、ユーザが実口座を開設した後は、口座残高の引き出しが可能な実口座を電子マネーと連携させることができるので、ユーザの利便性が高まる。
[3-6.変形例6]
例えば、変形例5のように、ユーザが実口座を開設した場合には、親口座に存在したユーザの資金が、新たに開設された実口座に移動されるようにしてもよい。変形例6の残高連携システムSは、親口座の口座残高のうち、実口座を開設したユーザの分を、当該実口座に移動させる口座残高移動部207を更に含む。口座残高移動部207は、親口座の口座残高のうち、実口座を開設したユーザの残高分を、新たに開設された実口座に移動させる。図13の例において、ユーザXが実口座を開設したとすると、親口座の口座残高のうちの30000円分は、ユーザXの資金なので、口座残高移動部207は、この30000円分をユーザXの実口座に移動させる。資金の移動自体は、振込によって行われるようにすればよい。ユーザの実口座が開設されたことは、金融サービスの管理者による操作によって特定されるようにすればよい。
変形例6の残高連携システムSは、親口座の口座残高のうち、実口座を開設したユーザの分を、当該実口座に移動させる。これにより、ユーザが自身で振込の操作をする必要がなく、かつ、ユーザの資金が無駄にならないので、ユーザの利便性が高まる。
[3-7.変形例7]
例えば、口座残高は、閾値を超えた分のプレミアム型の残高と連携してもよい。この閾値は、従来のプレミアム型の残高のように電子マネーを利用する分である。変形例7以降の変形例では、変形例2~6で説明した振込入金口座を前提としなくてもよい。
口座残高増加部103は、増加要求が受け付けられた場合に、閾値を超えた分に基づいて、口座残高を増加させる。例えば、第1実施形態のように残高連携をする場合、プレミアム型の残高が全て口座残高に自動入金されるのではなく、ある閾値を超えた分だけが自動入金される。この閾値の範囲内では、プレミアム型の残高が残ることになる。例えば、この閾値を10000円として、13000円のチャージが発生したとする。この場合、口座残高増加部103は、10000円を超えた3000円分を、連携先の口座残高に自動入金する。13000円のチャージのうちの10000円分は、プレミアム型の残高として残る。
口座残高減少部103は、減少要求が受け付けられた場合に、閾値を超えた分に基づいて、口座残高を減少させる。例えば、第1実施形態のように残高連携をする場合、支払額又は送り額の全てがプレミアム型の残高に自動チャージされるのではなく、ある閾値を超えた分だけが自動入金される。上記の例において、プレミアム型の残高が10000円分残ったとする。この場合に、ユーザが150000円分の支払をする場合、口座残高減少部103は、閾値である10000円を超えた5000円分が自動チャージされるので、連携先の口座残高を5000円減少させる。
第2実施形態のように残高連携をする場合、閾値を超えない範囲のプレミアム型の残高は、精算用の残高として決済サービスに保持される。例えば、精算用の残高が0円であり、この閾値を10000円として、13000円のチャージが発生したとする。この場合、精算用の残高が10000円になり、口座残高増加部103は、10000円を超えた3000円分だけ、連携用の残高に増加させる。連携用の残高が同期する処理は、第2実施形態と同様である。上記の例において、ユーザが150000円分の支払をする場合、口座残高減少部103は、閾値である10000円を超えた5000円分が利用されるように、連携用の残高を減少させる。その後、第2実施形態で説明したように、連携用の残高に合うように口座残高が変更される。
変形例7の残高連携システムSは、増加要求が受け付けられた場合に、口座残高と連携する電子マネー残高の一部に基づいて、口座残高を増加させる。残高連携システムSは、減少要求が受け付けられた場合に、口座残高と連携する電子マネー残高の一部に基づいて、口座残高を減少させる。これにより、口座残高と連携させたくない残高分は、通常のプレミアム型の残高として利用できるようになるので、ユーザの利便性が高まる。
[3-8.変形例8]
例えば、残高連携システムSは、電子マネーのユーザによる、変形例7で説明した閾値に関する指定を受け付ける指定受付部109を更に含んでもよい。ユーザにより指定された閾値は、決済データベースDB1に格納されるものとする。プレミアム型の残高のうち、ユーザにより指定された閾値を超えた範囲で口座残高と連携する。ユーザが閾値を決める点で変形例7とは異なるが、他の点については、変形例7と同様である。
変形例8の残高連携システムSは、電子マネーのユーザによる、残高連携をさせない分の閾値に関する指定を受け付ける。これにより、プレミアム型の残高のうち、ユーザが所望する額だけは残高連携せずに、通常のプレミアム型の残高として残すことができるので、ユーザの利便性が高まる。プレミアム型の残高として残っている分については、支払時の自動チャージ処理が発生しないので、決済完了を高速化できる。
[3-9.変形例9]
例えば、残高連携システムは、口座残高増加部103により口座残高が増加する場合には所定の手数料を発生させず、電子マネーのユーザにより、電子マネー残高からの出金が指示された場合に、手数料を発生させる手数料発生部110を更に含んでもよい。手数料を発生させる方法自体は、公知の処理を利用可能である。例えば、手数料発生部110は、電子マネー残高から手数料分が減少することによって、手数料を発生させる。手数料は、固定値であってもよいし、出金額に応じた値であってもよい。第1実施形態のような自動入金が発生したり、第2実施形態のような同期が行われて口座残高が増えたりしたとしても、手数料発生部110は、残高連携の場合には手数料を発生させない。
変形例9の残高連携システムSは、口座残高増加部103により口座残高が増加する場合には所定の手数料を発生させず、電子マネーのユーザにより、電子マネー残高からの出金が指示された場合に、手数料を発生させる。これにより、残高連携の場合には手数料が発生しないので、ユーザに残高連携をさせる動機付けを与えることができる。
[3-10.変形例10]
例えば、第1実施形態及び第2実施形態で説明したように、電子マネー残高は、0円で固定されている場合に、残高連携システムSは、口座残高に基づいて、電子マネーのユーザのユーザ端末30に、電子マネー残高に関する残高情報を表示させる表示制御部111を更に含んでもよい。残高情報は、電子マネー残高を識別可能な情報である。例えば、図2のトップ画面G1のような数値であってもよいし、テキスト又はアイコン等の他の情報であってもよい。第1実施形態のように残高連携を行う場合にも、プレミアム型の残高は、チャージ後すぐに自動入金されたり、自動チャージ後すぐに利用されたりするので、実質的に0円で固定されているということができる。このため、第1実施形態のように残高連携を行う場合と、第2実施形態のように残高連携を行う場合と、の何れの場合にも、表示制御部111による残高情報の表示が可能である。
例えば、表示制御部111は、銀行サーバ20から、連携先の口座残高を取得する。表示制御部111は、ユーザの口座残高を、プレミアム型の残高としてユーザ端末30に表示させる。例えば、表示制御部111は、プレミアム型の残高が0円だったとしても、ユーザの口座残高(例えば、1000000円)をプレミアム型の残高としてユーザ端末30に表示させる。表示制御部111は、ユーザの口座残高と、基本型の残高と、の合計をユーザ端末30に表示させてもよい。変形例10では、表示制御部111が電子マネーサーバ10において実現されるので、表示制御部111は、残高情報を表示させるためのデータをユーザ端末30に送信することによって、残高情報をユーザ端末30に表示させる。
変形例10の残高連携システムSは、口座残高に基づいて、電子マネーのユーザのユーザ端末に、電子マネー残高に関する残高情報を表示させる。これにより、連携中のプレミアム型の残高をどの程度利用できるかをユーザが容易に把握できるようになる。
[3-11.変形例11]
例えば、変形例10のように残高情報を表示させる場合に、残高連携システムSは、残高情報として表示させる額の上限を設定する上限設定部112を更に含んでもよい。ユーザにより指定された上限は、決済データベースDB1に格納されるものとする。表示制御部111は、上限の範囲内で、ユーザ端末に残高情報を表示させる。例えば、図3のように、口座残高が1203500円だったとして、ユーザが上限として10000円を指定したとする。この場合、表示制御部111は、プレミアム型の残高として利用可能な資金が1203500円存在するにもかかわらず、プレミアム型の残高として10000円をユーザ端末30に表示される。他にも例えば、表示制御部111は、「残高10000円以上」といったように、口座残高の詳細を他人に知られないようにして、かつ、10000円以上の残高が利用可能なことをユーザに通知するように、プレミアム型の残高を表示させてもよい。
変形例11の残高連携システムSは、残高情報として表示させる額の上限を設定し、上限の範囲内で、ユーザ端末に残高情報を表示させる。これにより、口座残高のようなプライベートな情報が他人に知られることを防止できる。
[3-12.変形例12]
例えば、第1実施形態及び第2実施形態で説明した電子マネーは、口座残高と連携可能なプレミアム型の残高と、基本型の残高と、を有する。基本型の残高は、プレミアム型の残高とは異なる他の残高の一例である。口座残高減少部106は、減少要求が受け付けられた場合に、所定の上限の範囲内で、口座残高を減少させてもよい。上限を超える額の減少要求が受け付けられた場合には、上限を超える分については、他の電子マネー残高が減少してもよい。
例えば、上限を10000円として、ユーザが店舗で13000円分の支払操作をしたとする。この場合、上限の10000円分は、第1実施形態又は第2実施形態と同様にして決済処理が実行される。残りの3000円分については、基本型の残高から支払が行われるようにしてもよい。基本型の残高を利用した支払自体は、公知の処理を利用すればよい。上限は、ユーザにより指定されてもよいし、予め定められた固定値であってもよい。
変形例12の残高連携システムSは、減少要求が受け付けられた場合に、所定の上限の範囲内で、口座残高を減少させ、上限を超える額の減少要求が受け付けられた場合には、上限を超える分については、基本型の残高が減少する。これにより、残高連携させる上限額を設定できるので、ユーザの利便性が高まる。
[3-13.その他変形例]
例えば、上記説明した変形例を組み合わせてもよい。
例えば、残高連携する口座の一例として銀行の口座を説明したが、銀行以外の金融機関の口座と、電子マネーと、が連携してもよい。他にも例えば、証券会社の口座と、電子マネーと、が連携してもよい。例えば、ユーザが決済アプリから決済サービスを利用する場合を説明したが、決済サービスを提供する媒体は、任意の媒体であってよく、決済アプリに限られない。例えば、ユーザ端末30のブラウザ、ユーザ端末30のICチップ、又はユーザが所有するICカードを利用して決済サービスが提供されてもよい。
例えば、残高連携システムSは、電子マネーサーバ10だけを含んでもよい。この場合、銀行サーバ20及びユーザ端末30は、残高連携システムSの外部に存在してもよい。例えば、残高連携システムSは、銀行サーバ20だけを含んでもよい。この場合、電子マネーサーバ10及びユーザ端末30は、残高連携システムSの外部に存在してもよい。例えば、電子マネーサーバ10で実現されるものとして説明した機能は、銀行サーバ20又は他のサーバコンピュータで実現されてもよい。銀行サーバ20で実現されるものとして説明した機能は、電子マネーサーバ10又は他のサーバコンピュータで実現されてもよい。例えば、電子マネーサーバ10又は銀行サーバ20で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。各機能は、少なくとも1つのコンピュータで実現されるようにすればよい。