JP7366116B2

JP7366116B2 - 残高連携システム、残高連携方法、及びプログラム

Info

Publication number: JP7366116B2
Application number: JP2021214580A
Authority: JP
Inventors: 寿朗井山
Original assignee: Rakuten Group Inc
Current assignee: Rakuten Group Inc
Priority date: 2021-12-28
Filing date: 2021-12-28
Publication date: 2023-10-20
Anticipated expiration: 2041-12-28
Also published as: TWI839044B; TW202334875A; JP2023098074A

Description

本開示は、残高連携システム、残高連携方法、及びプログラムに関する。

従来、電子マネー等の決済手段を利用した決済サービスと、銀行等の口座を利用した金融サービスと、を連携させる技術が知られている。例えば、特許文献１には、ユーザの実口座から仮想口座に振り込まれた金額を、事業者の親口座を経由して、ユーザの電子マネーにチャージする技術が記載されている。例えば、特許文献２には、管理口座からバリュー口座に送金することによって電子マネーにチャージし、バリュー口座の残高を電子マネーとして利用させる技術が記載されている。

例えば、特許文献３には、銀行ホストの利用者口座情報をコピーすることによって、ミラー口座情報を生成して電子マネーサーバに記録し、ユーザが電子マネーを利用する場合に、電子マネーサーバのミラー口座情報の残高を減少させ、当該残高の減少を銀行ホストの利用者口座情報に反映する技術が記載されている。例えば、特許文献４には、ユーザの口座の残高を、第１口座及び第２口座に分けて管理し、第１口座及び第２口座の中から、決済で利用する口座を選択する技術が記載されている。

特許第５１４１１５８号公報特開２０２１－５１７４２号公報特開平１１－３０６２６３号公報特開２０２０－１０７２１７号公報

上記のような技術では、決済手段の残高と、口座の残高と、の連携を高めるほど、ユーザの利便性も高まると考えられる。しかしながら、特許文献１の技術は、実口座から仮想口座に振り込まれた金額が電子マネーにチャージされるだけであり、電子マネーの残高と、口座の残高と、が十分に連携するものではない。特許文献２の技術は、バリュー口座の残高をカードから利用できるものにすぎず、電子マネー等の決済手段の残高と、管理口座又はバリュー口座の残高と、が十分に連携するものではない。

特許文献３の技術は、電子マネーとして利用されたミラー口座情報の残高の減少分が銀行ホストの利用者口座情報に反映されるものにすぎないので、電子マネーの残高を増やすためには、銀行の利用者口座に振り込みをしたり、ＡＴＭから利用者口座に現金を入金したりする必要がある。特許文献４の技術は、そもそも電子マネーの残高と、口座の残高と、が連携するものではない。このため、従来の技術では、電子マネー等の決済手段の残高と、銀行等の口座の残高と、が十分に連携するものではなかった。

本開示の目的の１つは、決済手段の残高と、口座の残高と、を十分に連携させることによって、ユーザの利便性を高めることである。

本開示に係る残高連携システムは、決済手段の残高である決済手段残高を増加させるための増加要求を受け付ける増加要求受付部と、前記増加要求が受け付けられた場合に、前記決済手段と連携する口座の残高である口座残高を増加させる口座残高増加部と、前記決済手段残高を減少させるための減少要求を受け付ける減少要求受付部と、前記減少要求が受け付けられた場合に、前記口座残高を減少させる口座残高減少部と、を含む。

本開示によれば、決済手段の残高と、口座の残高と、を十分に連携させることによって、ユーザの利便性が高まる。

残高連携システムの全体構成の一例を示す図である。ユーザ端末に表示される画面の一例を示す図である。第１実施形態における残高連携の一例を示す図である。第１実施形態の残高連携システムで実現される機能の一例を示す機能ブロック図である。決済データベースの一例を示す図である。口座データベースの一例を示す図である。第１実施形態の残高連携システムで実行される処理の一例を示す図である。第１実施形態の残高連携システムで実行される処理の一例を示す図である。第２実施形態における残高連携の一例を示す図である。第２実施形態の残高連携システムで実現される機能の一例を示す図である。第２実施形態の残高連携システムで実行される処理の一例を示す図である。変形例における機能ブロックの一例を示す図である。変形例２の概要を示す図である。

［１．第１実施形態］
本開示に係る残高連携システムの実施形態の一例である第１実施形態を説明する。

［１．第１実施形態］
図１は、残高連携システムの全体構成の一例を示す図である。残高連携システムＳは、電子マネーサーバ１０、銀行サーバ２０、及びユーザ端末３０を含む。これらは、インターネット又はＬＡＮ等のネットワークＮに接続可能である。残高連携システムＳは、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。

電子マネーサーバ１０は、決済事業者のサーバコンピュータである。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

銀行サーバ２０は、銀行のサーバコンピュータである。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

ユーザ端末３０は、ユーザのコンピュータである。例えば、ユーザ端末３０は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。制御部３１、記憶部３２、及び通信部３３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部３４は、タッチパネル等の入力デバイスである。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイである。

なお、電子マネーサーバ１０、銀行サーバ２０、及びユーザ端末３０の各々に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。また、情報記憶媒体に記憶されたプログラムが、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）を介して供給されてもよい。

［１－２．残高連携システムの概要］
第１実施形態では、ユーザが、ユーザ端末３０にインストールされた決済アプリから、決済サービスを利用する場合を例に挙げる。決済サービスで利用可能な決済手段は、任意の種類であってよい。例えば、電子マネー、ポイント、クレジットカード、デビットカード、銀行口座、ウォレット、又は暗号資産が決済手段に相当してもよい。決済手段は、支払手段と呼ばれることもある。バーコード又は二次元コードといったコードが決済手段に相当することもある。決済手段は、電子決済で利用される何らかの手段であればよい。電子決済は、キャッシュレス決済と呼ばれることもある。

図２は、ユーザ端末３０に表示される画面の一例を示す図である。例えば、ユーザ端末３０の決済アプリが起動すると、決済アプリのトップ画面Ｇ１が表示部３５に表示される。トップ画面Ｇ１には、決済サービスにおいてユーザを識別可能なコードＩＤを含むコードＣ１０が表示される。コードＩＤは、ユーザが決済サービスにログインするためのユーザＩＤとは異なる情報である。例えば、コードＩＤは、決済アプリが起動するたびに更新される。

図２の例では、バーコード及び二次元コードの両方がコードＣ１０として表示される場合を示しているが、コードＣ１０自体は、任意のコードであってよい。例えば、バーコード又は二次元コードの何れか一方のみがコードＣ１０として表示されてもよい。例えば、ユーザが訪れた店舗の端末でコードＣ１０が読み取られると、ユーザが支払元として設定した決済手段に基づいて、決済処理が実行される。

第１実施形態では、支払元が電子マネーである場合を例に挙げる。図２の例では、決済サービス「ＡＡＡペイ」で利用可能なオンライン型の電子マネー「ＡＡＡキャッシュ」が支払元として設定されている。例えば、店舗の端末でコードＣ１０が読み取られると、電子マネーの残高が所定の額だけ減少し、決済が完了する。コードＣ１０は、店舗の端末以外にも、自動販売機等の任意の端末で読み取り可能である。

なお、決済アプリで利用可能な決済方法は、コードＣ１０を利用する方法に限られない。例えば、店舗に掲示されたコードをユーザ端末３０で読み取る決済方法、店舗の端末に表示されたコードをユーザ端末３０で読み取る決済方法、ユーザ端末３０に対する操作のみで完結する決済方法、又は無線通信可能な端末にユーザ端末３０をかざす決済方法といった任意の方法を利用可能である。また、電子マネーは、決済アプリ以外にも、電子商取引サービス又はフリーマーケットサービスといったオンライン上の任意のサービスで利用可能である。オンライン上のサービスで電子マネーが利用される場合には、決済アプリが利用されなくてもよい。

例えば、ユーザがボタンＢ１１を選択すると、電子マネーのメニューＭ１３が表示部３５に表示される。第１実施形態では、電子マネーの残高として、プレミアム型の残高と、基本型の残高と、の２種類が存在する場合を例に挙げる。メニューＭ１３には、プレミアム型の残高、基本型の残高、及びこれらの合計が表示される。以降、プレミアム型の残高と、基本型の残高と、を区別しない時は、単に電子マネー残高という。

プレミアム型の残高は、第１の種類の電子マネー残高である。プレミアム型の残高は、任意の目的で利用可能である。第１実施形態では、店舗等における支払で利用する目的（以降、支払目的）、他のユーザに残高の一部又は全部を送る目的（以降、送り目的）、及びユーザの口座に出金する目的（以降、出金目的）で、プレミアム型の残高を利用可能な場合を例に挙げる。第１実施形態では、プレミアム型の残高は、基本型の残高よりも優先的に利用されるものとする。

プレミアム型の残高は、任意のチャージ方法でチャージ可能である。第１実施形態では、オンラインフリーマーケットサービスの売上金を利用したチャージ方法（以降、売上金チャージ）、暗号資産を利用したチャージ方法（以降、暗号資産チャージ）、又は金融機関の口座を利用したチャージ方法（以降、口座チャージ）で、プレミアム型の残高をチャージ可能な場合を例に挙げる。

なお、クレジットカードのショッピング枠の現金化を防止するために、出金目的で利用可能なプレミアム型の残高は、ショッピング枠を利用したチャージ方法（以降、ショッピングチャージ）ではチャージできないものとする。一方で、クレジットカードのキャッシング枠は、現金の借入を目的としたものである。このため、プレミアム型の残高は、キャッシング枠を利用したチャージ方法（以降、キャッシングチャージ）でチャージできるようにしてもよい。

基本型の残高は、第２の種類の電子マネー残高である。基本型の残高は、任意の目的で利用可能である。第１実施形態では、支払目的及び送り目的で、基本型の残高を利用可能な場合を例に挙げる。基本型の残高は、出金目的では利用できない。このため、第１実施形態では、プレミアム型の残高の方が、より多くの目的で利用可能であり、利便性が高いものとする。基本型の残高は、任意のチャージ方法でチャージ可能である。第１実施形態では、ショッピング枠チャージで、基本型の残高をチャージ可能な場合を例に挙げる。なお、ユーザが基本型の残高を他のユーザに送った場合、他のユーザは、基本型の残高として受け取るので、当該受け取った残高を出金目的では利用できないようになっている。

例えば、ユーザは、メニューＭ１３から、電子マネーに関する各種操作をすることができる。例えば、ユーザがボタンＢ１４を選択すると、電子マネーを他のユーザに送ることができる。ユーザがボタンＢ１５を選択すると、電子マネーにチャージできる。ユーザがボタンＢ１６を選択すると、プレミアム型の残高の全部又は一部を出金できる。ユーザがボタンＢ１７を選択すると、プレミアム型の残高と、銀行における口座の残高である口座残高と、を連携できる。以降、これらの残高が連携することを、残高連携という。

第１実施形態では、ユーザは、銀行に口座を開設済みであるものとする。更に、ユーザは、ユーザ端末３０にインストールされた銀行アプリから、金融サービスを利用可能であるものとする。例えば、ユーザは、銀行アプリから、口座残高の確認、過去の取引における明細の確認、振込の実行、公共料金等の払込、又はローン申込といった種々の金融サービスを利用できる。決済アプリは、銀行アプリとの連携が可能である。

例えば、ユーザがボタンＢ１７を選択すると、銀行アプリが起動し、認証画面Ｇ２が表示部３５に表示される。決済アプリは、バックグラウンドに移行する。ユーザが、金融サービスにおけるユーザＩＤ及びパスワードを入力フォームＦ２０に入力してボタンＢ２１を選択すると、銀行サーバ２０による認証が実行される。認証自体は、生体認証等の種々の方法を利用可能である。銀行サーバ２０がユーザの正当性を確認すると、決済アプリがフォアグラウンドに戻り、残高連携が完了したことを示す完了画面Ｇ３が表示部３５に表示される。銀行アプリは、終了してもよいし、バックグラウンドに移行してもよい。

図３は、第１実施形態における残高連携の一例を示す図である。例えば、トップ画面Ｇ１には、電子マネーの残高を示す領域に、残高連携中であることを示すメッセージが表示される。図３の例では、電子マネーの残高を表示しないようにしているが、残高連携が完了した後は、電子マネーの残高として、基本型の残高と、口座残高と、の合計が表示されてもよいし、基本型の残高と、口座残高と、が別々に表示されてもよい。

第１実施形態では、残高連携が完了すると、プレミアム型の残高がユーザの口座に自動入金される。例えば、プレミアム型の残高が３５００円分存在する状態で残高連携が完了すると、この３５００円分が連携先の口座に自動入金される。電子マネーを口座に自動入金する方法自体は、種々の出金方法を適用可能である。残高連携前の口座残高を１２０００００円とすると、自動入金により、口座残高は１２０３５００円になる。プレミアム型の残高は、全て自動入金されたので、０円になる。

例えば、図３の状態で、ユーザがプレミアム型の残高に１０００円分のチャージをしたとする。この場合、プレミアム型の残高は、０円から１０００円に増加する。その直後に、プレミアム型の残高の全額である１０００円が、連携先の口座に自動入金される。このため、プレミアム型の残高は、一瞬だけ１０００円になるが、すぐに０円に減少する。口座の残高は、１２０３５００円から１２０４５００円に増加する。

例えば、図３の状態で、ユーザが、他のユーザから２０００円分のプレミアム型の残高を受け取ったとする。この場合、プレミアム型の残高は、０円から２０００円に増加する。その直後に、プレミアム型の残高の全額である２０００円が、連携先の口座に自動入金される。このため、プレミアム型の残高は、一瞬だけ２０００円になるが、すぐに０円に減少する。口座の残高は、１２０３５００円から１２０５５００円に増加する。

例えば、図３の状態で、ユーザが店舗のＰＯＳ端末にコードＣ１０を読み取らせて、３０００円の買い物をしたとする。更に、プレミアム型の残高は、基本型の残高よりも優先的に利用されるものとする。３０００円分の支払でプレミアム型の残高が優先的に利用されるが、残高連携後は、プレミアム型の残高は０円になるので、連携先の口座の口座残高からプレミアム型の残高に３０００円分が自動チャージされる。このため、口座の残高は、１２０３５００円から１２００５００円に減少する。プレミアム型の残高は、一瞬だけ０円から３０００円に増加した後に、この３０００円分がすぐに支払に利用されて０円に減少する。

例えば、図３の状態で、ユーザが、他のユーザに４０００円分のプレミアム型の残高を送ったとする。残高連携後は、プレミアム型の残高は０円になるので、口座残高からプレミアム型の残高に４０００円分が自動チャージされる。このため、口座の残高は、１２０３５００円から１１９９５００円に減少する。プレミアム型の残高は、一瞬だけ０円から４０００円に増加した後に、この４０００円分がすぐに他のユーザに送られて０円に減少する。

以上のように、第１実施形態の残高連携システムＳでは、残高連携により、プレミアム型の残高と、口座の残高と、を十分に連携させることによって、ユーザの利便性を高めるようになっている。以降、第１実施形態の詳細を説明する。

［１－３．第１実施形態の残高連携システムで実現される機能］
図４は、第１実施形態の残高連携システムＳで実現される機能の一例を示す機能ブロック図である。

［１－３－１．電子マネーサーバで実現される機能］
データ記憶部１００は、記憶部１２を主として実現される。増加要求受付部１０１、電子マネー残高増加部１０２、口座残高増加部１０３、減少要求受付部１０４、電子マネー残高減少部１０５、及び口座残高減少部１０６は、制御部１１を主として実現される。

［データ記憶部］
データ記憶部１００は、ユーザに決済サービスを提供するために必要なデータを記憶する。例えば、データ記憶部１００は、決済データベースＤＢ１を記憶する。

図５は、決済データベースＤＢ１の一例を示す図である。図５に示すように、決済データベースＤＢ１は、決済サービスにおけるユーザに関する情報が格納されたデータベースである。例えば、決済データベースＤＢ１には、ユーザＩＤ、パスワード、氏名、コードＩＤ、有効期限、支払元情報、カード情報、電子マネー情報、及び連携情報が格納される。決済データベースＤＢ１に格納される情報は、ユーザに関する任意の情報であってよく、図５の例に限られない。例えば、決済データベースＤＢ１には、電子マネーの利用履歴又はチャージ履歴が格納されてもよい。

ユーザＩＤは、ユーザを識別可能なユーザ識別情報の一例である。ユーザ識別情報は、任意の情報であってよく、例えば、ユーザアカウントと呼ばれる情報、メールアドレス、又は電話番号であってもよい。例えば、ユーザ識別情報は、文字、数字、その他の記号、又はこれらの組み合わせである。ユーザＩＤ及びパスワードは、決済サービスにログインするために利用される。

第１実施形態では、ユーザＩＤだけではなく、コードＩＤもユーザを識別可能な情報なので、コードＩＤもユーザ識別情報に相当する。コードＣ１０には、何らかのユーザ識別情報が含まれるようにすればよい。コードＣ１０には、コードＩＤではなく、ユーザＩＤ等の他のユーザ識別情報が含まれてもよい。有効期限は、コードＩＤが発行されてから所定時間後の時点である。コードＩＤには、有効期限が設定されなくてもよい。

支払元情報は、支払元として設定された決済手段を識別可能な情報である。例えば、支払元として電子マネーが設定された場合、支払元情報は、電子マネーを識別可能な電子マネーＩＤであってもよい。例えば、支払元としてクレジットカードが設定された場合、支払元情報は、クレジットカードのカード番号であってもよい。カード情報は、ユーザのクレジットカードに関する情報である。例えば、カード情報は、カード番号、有効期限、及び名義人を含む。ユーザは、複数のクレジットカードを登録可能である。

電子マネー情報は、ユーザの電子マネーに関する情報である。例えば、電子マネー情報は、電子マネー残高を示す情報を含む。第１実施形態では、プレミアム型の残高と、基本型の残高と、が存在するので、電子マネー情報には、これらの残高が示される。連携情報は、残高連携に関する情報である。例えば、連携情報は、連携先の口座の金融機関コード、支店名、口座番号、及び名義人を示す。連携情報は、連携先の口座を識別可能であればよく、口座番号だけを示してもよいし、金融サービスにおけるユーザＩＤを示してもよい。残高連携をしていないユーザについては、連携情報が格納されないものとする。

［増加要求受付部］
増加要求受付部１０１は、電子マネーの残高である電子マネー残高を増加させるための増加要求を受け付ける。第１実施形態では、決済手段の一例として電子マネーを説明するので、電子マネー残高は、決済手段残高の一例である。このため、電子マネーについて説明している箇所は、決済手段と読み替えることができる。電子マネー残高について説明している箇所は、決済手段残高と読み替えることができる。

第１実施形態では、特にプレミアム型の残高の詳細を説明するので、プレミアム型の電子マネーについて説明している箇所は、決済手段と読み替えることができる。プレミアム型の残高について説明している箇所は、決済手段残高と読み替えることができる。決済手段は、残高の概念を有する他の決済手段であってもよい。例えば、決済手段は、ポイントであってもよい。ポイントが決済手段に相当する場合、ポイント残高が決済手段残高に相当する。例えば、電子マネーとは呼ばれずに、決済サービスの独自の名前で呼ばれる決済手段であってもよい。

増加要求は、所定の形式のデータが送信されることによって行われる。増加要求は、任意の情報を含むことができる。例えば、増加要求は、増加対象となる電子マネーを識別可能な電子マネー識別情報と、電子マネー残高を増加させる額と、を含む。増加要求は、他の情報を含んでもよく、例えば、複数の方法で電子マネー残高を増加できる場合には、この方法を識別可能な情報が増加要求に含まれてもよい。

第１実施形態では、コードＩＤが電子マネー識別情報に相当する場合を説明するが、電子マネー識別情報は、コードＩＤ以外の任意の情報であってよい。例えば、電子マネー識別情報は、ユーザＩＤであってもよいし、コードＩＤ及びユーザＩＤ以外のユーザ識別情報であってもよい。例えば、電子マネー識別情報は、ユーザ識別情報とは異なる情報であってもよく、電子マネーを識別可能な電子マネーＩＤであってもよい。

第１実施形態では、ユーザ端末３０から増加要求が送信される場合を説明するが、増加要求は、任意のコンピュータによって送信可能である。例えば、店舗に配置されたＰＯＳ端末又はチャージ端末からのチャージを可能とする場合には、ＰＯＳ端末又はチャージ端末から増加要求が送信されてもよい。例えば、電子商取引サービス又はオンラインフリーマーケットサービスといった任意のサービスを利用した特典（ギフト）として、電子マネーが付与される場合には、このサービスのサーバコンピュータから増加要求が送信されてもよい。

例えば、ユーザがボタンＢ１５を選択した場合に、ユーザ端末３０から電子マネーサーバ１０に送信されるチャージ要求は、増加要求の一例である。このため、チャージ要求について説明している箇所は、増加要求と読み替えることができる。チャージ要求は、電子マネーにチャージするための要求である。

第１実施形態では、プレミアム型の残高と、基本型の残高と、の２つの電子マネー残高に対するチャージのうち、主に、プレミアム型の残高に対するチャージについて説明する。例えば、チャージ要求には、チャージ対象の電子マネーを識別可能な電子マネー識別情報と、ユーザが指定したチャージ額と、が含まれている。第１実施形態では、複数のチャージ方法が用意されているので、チャージ要求には、チャージ方法を識別可能なチャージ方法識別情報も含まれているものとする。チャージ方法が１種類しか存在しない場合には、チャージ要求には、チャージ方法識別情報が含まれていなくてもよい。

例えば、ユーザが他のユーザから送られたプレミアム型の残高を受け取る操作をした場合に、ユーザ端末３０から電子マネーサーバ１０に送信される受取要求も、増加要求の一例である。このため、受取要求について説明している箇所は、増加要求と読み替えることができる。受取要求は、他のユーザから送られたプレミアム型の残高を受け取るための要求である。

第１実施形態では、プレミアム型の残高と、基本型の残高と、の２つの電子マネー残高に対するチャージのうち、主に、プレミアム型の残高の受け取りについて説明する。例えば、受取要求には、他のユーザから送られたプレミアム型の残高を識別可能な情報が含まれている。他のユーザから送られたプレミアム型の残高に関する情報は、決済データベースＤＢ１に格納されているものとする。

なお、増加要求は、電子マネー残高を増加させるための何らかの要求であればよく、チャージ要求及び受取要求に限られない。例えば、何らかの特典としてプレミアム型の残高が贈られる場合には、特典を受け取るための要求が増加要求に相当してもよい。

［電子マネー残高増加部］
電子マネー残高増加部１０２は、増加要求が受け付けられた場合に、電子マネー残高を増加させる。電子マネー残高を増加させるとは、決済データベースＤＢ１に格納された電子マネー残高を、現在の数値よりも大きくすることである。電子マネー残高増加部１０２は、増加要求に応じた増加分だけ、電子マネー残高を増加させる。第１実施形態では、電子マネー残高増加部１０２は、プレミアム型の残高と、基本型の残高と、の両方を増加可能である。これらの増加を区別しない時は、単に電子マネー残高の増加と記載する。

例えば、チャージ要求が増加要求に相当する場合、電子マネー残高増加部１０２は、チャージ処理を実行することによって、電子マネー残高を増加させる。チャージ処理自体は、公知の処理を利用可能である。例えば、電対マネー残高増加部は、増加要求に含まれる電子マネー識別情報が示す電子マネーの残高を、増加要求に含まれるチャージ方法情報が示すチャージ方法で、増加要求に含まれるチャージ額だけ増加させる。

例えば、受取要求が増加要求に相当する場合、電子マネー残高増加部１０２は、受取処理を実行することによって、電子マネー残高を増加させる。受取処理自体は、公知の処理を利用可能である。例えば、電対マネー残高増加部は、受取要求に含まれる情報に基づいて、対象となる電子マネー及び受取額を特定し、当該特定された電子マネーの残高を、受取額だけ増加させる。他の増加要求が受け付けられた場合にも、電子マネー残高増加部１０２は、他の増加要求に基づいて、電子マネー残高を増加させるようにすればよい。

［口座残高増加部］
口座残高増加部１０３は、増加要求が受け付けられた場合に、電子マネーと連携する口座の残高である口座残高を増加させる。第１実施形態では、口座残高増加部１０３は、残高連携が完了し、かつ、プレミアム型の残高の増加要求が受け付けられた場合に、口座残高を増加させる。口座残高増加部１０３は、増加要求により指示されたプレミアム型の残高の増加分と同じ額だけ、口座残高を増加させる。口座残高を書き換える処理自体は、銀行サーバ２０によって実行されるので、口座残高増加部１０３は、銀行サーバ２０に対し、口座残高を増加させるための要求を送信することによって、口座残高を増加させる。電子マネーサーバ１０及び銀行サーバ２０の協働により、口座残高が増加する。

口座残高増加部１０３が銀行サーバ２０に送信する要求は、所定の形式のデータが送信されることによって行われるようにすればよい。例えば、この要求には、増加対象となる口座を識別可能な口座識別情報と、口座残高の増加額と、が含まれてもよい。第１実施形態では、支店名及び口座番号が口座識別情報に相当する場合を説明するが、口座を識別可能な他の情報が口座識別情報に相当してもよい。例えば、決済サービスにおけるユーザＩＤ、又は、金融サービスにおけるユーザＩＤが口座識別情報に相当してもよい。口座残高増加部１０３は、プレミアム型の残高の増加要求が示す増加分と同じ額だけ口座残高を増加することを、銀行サーバ２０に要求する。

第１実施形態では、プレミアム型の残高がいったん増加した後に口座への自動入金が行われるので、口座残高増加部１０３は、増加要求受付部１０１が受け付けた増加要求に応じた額を、プレミアム型の電子マネーから口座に自動的に入金することによって、口座残高を増加させる。口座残高増加部１０３は、電子マネー残高増加部１０２により増加したプレミアム型の残高に基づいて、口座残高を増加させる。口座残高増加部１０３は、プレミアム型の残高を、口座残高への自動入金額だけ減少させる。このため、口座残高増加部１０３は、プレミアム型の残高を増加前の額に戻すことになる。プレミアム型の残高を戻す処理は、後述の電子マネー残高減少部１０５により実行されてもよい。電子マネーを口座に入金する方法自体は、公知の方法を利用可能である。

なお、口座残高増加部１０３は、プレミアム型の残高をいったん増加させることなく、口座への自動入金を実行してもよい。この場合、増加要求受付部１０１が増加要求を受け付けた後に、電子マネー残高増加部１０２の処理は実行されない。口座残高増加部１０３は、増加要求が受け付けられた場合に、当該増加要求が示す増加分だけ口座残高を増加することを、銀行サーバ２０に要求すればよい。

［減少要求受付部］
減少要求受付部１０４は、電子マネー残高を減少させるための減少要求を受け付ける。減少要求は、所定の形式のデータが送信されることによって行われる。減少要求は、任意の情報を含むことができる。例えば、減少要求は、減少対象となる電子マネーを識別可能な電子マネー識別情報と、電子マネー残高を減少させる額と、を含む。電子マネー識別情報は、先述した通りである。

第１実施形態では、店舗のＰＯＳ端末又はユーザ端末３０から減少要求が送信される場合を説明するが、減少要求は、任意のコンピュータによって送信可能である。例えば、自動販売機に対する電子マネーの利用を可能とする場合には、自動販売機から減少要求が送信されてもよい。例えば、電子商取引サービス又はオンラインフリーマーケットサービスといった任意のサービスで電子マネーを利用可能な場合には、このサービスのサーバコンピュータから減少要求が送信されてもよい。

例えば、ユーザがコードＣ１０をＰＯＳ端末に読み取らせた場合に、ＰＯＳ端末から電子マネーサーバ１０に送信される支払要求は、減少要求の一例である。このため、支払要求について説明している箇所は、減少要求と読み替えることができる。支払要求は、電子マネーを利用して支払をするための要求である。第１実施形態では、プレミアム型の残高と、基本型の残高と、の２つの電子マネー残高の決済のうち、主に、プレミアム型の残高の決済について説明する。基本型の残高の決済は、公知の処理を利用可能である。例えば、支払要求には、店舗ＩＤ、端末ＩＤ、コードＩＤ、及び利用額が含まれているものとする。店舗ＩＤは、店舗を識別可能な情報である。端末ＩＤは、ＰＯＳ端末を識別可能な情報である。

例えば、ユーザが他のユーザにプレミアム型の残高を送る操作をした場合に、ユーザ端末３０から電子マネーサーバ１０に送信される送り要求も、減少要求の一例である。このため、送り要求について説明している箇所は、減少要求と読み替えることができる。送り要求は、他のユーザにプレミアム型の残高を送るための要求である。送り要求には、コードＩＤ、相手のユーザを識別可能な何らかのユーザ識別情報、及び送り額が含まれているものとする。

なお、減少要求は、電子マネー残高を減少させるための何らかの要求であればよく、支払要求及び送り要求に限られない。例えば、ユーザが電子マネーを自身の口座に出金するための要求が減少要求に相当してもよい。この口座は、残高連携した口座以外の他の口座であってもよい。

［電子マネー残高減少部］
電子マネー残高減少部１０５は、減少要求が受け付けられた場合に、電子マネー残高を減少させる。電子マネー残高を減少させるとは、決済データベースＤＢ１に格納された電子マネー残高を、現在の数値よりも小さくすることである。電子マネー残高減少部１０５は、減少要求に応じた減少分だけ、電子マネー残高を減少させる。第１実施形態では、電子マネー残高減少部１０５は、プレミアム型の残高と、基本型の残高と、の両方を減少可能である。これらの減少を区別しない時は、単に電子マネー残高の減少と記載する。

例えば、支払要求が減少要求に相当する場合、電子マネー残高減少部１０５は、決済処理を実行することによって、電子マネー残高を減少させる。決済処理自体は、公知の処理を利用可能である。例えば、電対マネー残高減少部は、支払要求に含まれるコードＩＤに関連付けられた電子マネーの残高を、支払要求に含まれる支払額だけ減少させる。

例えば、送り要求が減少要求に相当する場合、電子マネー残高減少部１０５は、送り処理を実行することによって、電子マネー残高を減少させる。送り処理自体は、公知の処理を利用可能である。例えば、電対マネー残高減少部は、送り要求に含まれる情報に基づいて、対象となる電子マネーを特定し、当該特定された電子マネーの残高を、送り額だけ減少させる。他の減少要求が受け付けられた場合にも、電子マネー残高減少部１０５は、他の減少要求に基づいて、電子マネー残高を減少させるようにすればよい。

［口座残高減少部］
口座残高減少部１０６は、減少要求が受け付けられた場合に、口座残高を減少させる。第１実施形態では、口座残高減少部１０６は、残高連携が完了し、かつ、プレミアム型の残高の減少要求が受け付けられた場合に、口座残高を減少させる。口座残高減少部１０６は、減少要求により指示されたプレミアム型の残高の減少分と同じ額だけ、口座残高を減少させる。口座残高を書き換える処理自体は、銀行サーバ２０によって実行されるので、口座残高減少部１０６は、銀行サーバ２０に対し、口座残高を減少させるための要求を送信することによって、口座残高を減少させる。電子マネーサーバ１０及び銀行サーバ２０の協働により、口座残高が減少する。

口座残高減少部１０６が銀行サーバ２０に送信する要求は、所定の形式のデータが送信されることによって行われるようにすればよい。例えば、この要求には、減少対象となる口座を識別可能な口座識別情報と、口座残高の減少額と、が含まれてもよい。口座残高減少部１０６は、プレミアム型の残高の減少要求が示す減少分と同じ額だけ口座残高を減少することを、銀行サーバ２０に要求する。

第１実施形態では、プレミアム型の残高が自動チャージされた後に減少するので、口座残高減少部１０６は、減少要求に応じた額を、口座からプレミアム型の電子マネーに自動的にチャージすることによって、口座残高を減少させる。電子マネーを自動的にチャージする方法自体は、公知の方法を利用可能である。自動的なチャージは、口座残高減少部１０６ではなく、電子マネー残高増加部１０２により実行されてもよい。

なお、第１実施形態では、プレミアム型の残高が増加した後に、決済処理等が実行される場合を説明するが、プレミアム型の残高を増加させることなく、決済処理等が実行されてもよい。この場合、減少要求受付部１０４が減少要求を受け付けた後に、プレミアム型の電子マネーを自動的にチャージする処理は実行されない。銀行サーバ２０から口座残高の減少が完了した通知が受信された場合に、プレミアム型の残高が増加することなく決済処理等が実行されてもよい。

［１－３－２．銀行サーバで実現される機能］
データ記憶部２００は、記憶部２２を主として実現される。口座残高増加部２０１及び口座残高減少部２０２は、制御部２１を主として実現される。

[データ記憶部]
データ記憶部２００は、ユーザに金融サービスを提供するために必要なデータを記憶する。例えば、データ記憶部２００は、口座データベースＤＢ２を記憶する。

図６は、口座データベースＤＢ２の一例を示す図である。図６に示すように、口座データベースＤＢ２は、金融サービスにおけるユーザに関する情報が格納されたデータベースである。例えば、口座データベースＤＢ２には、ユーザＩＤ、パスワード、氏名、支店名、口座番号、名義人、口座残高、及び連携情報が格納される。口座データベースＤＢ２に格納される情報は、ユーザに関する任意の情報であってよく、図６の例に限られない。例えば、口座データベースＤＢ２には、口座の取引履歴が格納されてもよい。

第１実施形態では、決済サービスのユーザＩＤと、金融サービスのユーザＩＤと、が異なる場合を説明するが、これらは共通であってもよい。同様に、決済サービスのパスワードと、金融サービスのパスワードと、が異なる場合を説明するが、これらは共通であってもよい。連携情報は、残高連携に関する情報である。例えば、連携情報は、口座が連携する電子マネーを保有するユーザの決済サービスにおけるユーザＩＤを含む。連携情報は、口座と連携する電子マネーを識別可能な情報を含めばよい。例えば、連携情報は、決済サービスにおけるユーザＩＤではなく、電子マネーＩＤ又はコードＩＤといった他の情報を含んでもよいし、残高連携用に生成された識別情報を含んでもよい。

［口座残高増加部］
口座残高増加部２０１は、増加要求受付部１０１により増加要求が受け付けられた場合に、電子マネーと連携する口座の残高である口座残高を増加させる。第１実施形態では、電子マネーサーバ１０から銀行サーバ２０に対し、口座残高を増加させるための要求が行われるので、口座残高増加部２０１は、この要求に基づいて、口座残高を増加させる。例えば、口座残高増加部２０１は、口座データベースＤＢ２を参照し、要求に含まれる口座識別情報が示す口座の口座残高を、要求が示す増加分だけ増加させる。

第１実施形態では、プレミアム型の電子マネーから口座への自動入金が実行されるので、口座残高増加部２０１は、増加要求に応じた額を、プレミアム型の電子マネーから口座に自動的に入金することによって、口座残高を増加させる。口座残高増加部２０１は、自動入金によって減少するプレミアム型の残高の減少分だけ、口座残高が増加するように、プレミアム型の残高と連携する口座残高を増加させる。口座残高増加部２０１は、口座残高の増加が完了した場合に、電子マネーサーバ１０に対し、その旨を示す通知を送信する。口座残高増加部２０１は、口座に対する振込等の他の行為が行われた場合にも、口座残高を増加可能である。

［口座残高減少部］
口座残高減少部２０２は、減少要求受付部１０４により減少要求が受け付けられた場合に、口座残高を減少させる。第１実施形態では、電子マネーサーバ１０から銀行サーバ２０に対し、口座残高を減少させるための要求が行われるので、口座残高減少部２０２は、この要求に基づいて、口座残高を減少させる。例えば、口座残高減少部２０２は、口座データベースＤＢ２を参照し、要求に含まれる口座識別情報が示す口座の口座残高を、要求が示す減少分だけ減少させる。

第１実施形態では、口座からプレミアム型の電子マネーへの自動チャージが実行されるので、口座残高減少部２０２は、減少要求に応じた額を、口座からプレミアム型の電子マネーに自動的にチャージすることによって、口座残高を減少させる。口座残高減少部２０２は、自動チャージによって増加するプレミアム型の残高の増加分だけ、口座残高が減少するように、プレミアム型の残高と連携する口座残高を減少させる。口座残高減少部２０２は、口座残高の減少が完了した場合に、電子マネーサーバ１０に対し、その旨を示す通知を送信する。口座残高減少部２０２は、口座からの出金等の他の行為が行われた場合にも、口座残高を減少可能である。

［１－３－３．ユーザ端末で実現される機能］
データ記憶部３００は、記憶部３２を主として実現される。表示制御部３０１及び操作受付部３０２は、制御部３１を主として実現される。

[データ記憶部]
データ記憶部３００は、ユーザが決済サービス及び金融サービスの各々を利用するために必要なデータを記憶する。例えば、データ記憶部３００は、決済アプリ、コードＩＤ、及び銀行アプリを記憶する。ユーザ端末３０は、電子マネーサーバ１０により発行されたコードＩＤを受信して自身のデータ記憶部３００に記録する。ユーザ端末３０は、コードＩＤの有効期限も受信した場合には、有効期限も自身のデータ記憶部３００に記録する。

［表示制御部］
表示制御部３０１は、任意の画面を表示部３５に表示させる。例えば、表示制御部３０１は、決済アプリ及び銀行アプリの少なくとも一方に基づいて、図２及び図３で説明した画面を表示部３５に表示させる。各画面は、ブラウザ上で表示されてもよい。

［操作受付部］
操作受付部３０２は、ユーザによる任意の操作を受け付ける。例えば、操作受付部３０２は、図２及び図３で説明した画面に対する操作を受け付ける。

［１－４．第１実施形態の残高連携システムで実行される処理］
図７及び図８は、第１実施形態の残高連携システムＳで実行される処理の一例を示す図である。この処理は、制御部１１，２１，３１がそれぞれ記憶部１２，２２，３２に記憶されたプログラムに従って動作することによって実行される。図７及び図８では、残高連携システムＳで実行される処理のうち、主に、残高連携後の処理について示している。ユーザは、残高連携の手続を済ませているものとする。

図７のように、ユーザ端末３０は、決済アプリを起動させ、電子マネーサーバ１０との間で、決済サービスにログインするためのログイン処理を実行する（Ｓ１００）。Ｓ１００では、決済サービスにおけるユーザＩＤ及びパスワードの入力が要求されてもよいし、過去に決済サービスにログインしたことを示す情報をユーザ端末３０に記憶されておき、当該情報に基づいて、決済サービスにおけるユーザＩＤ及びパスワードの入力が要求されないようにしてもよい。

決済サービスへのログインが成功すると、ユーザ端末３０は、トップ画面Ｇ１を表示部３５に表示させる（Ｓ１０１）。ユーザは、決済サービスを利用するための各種操作を行う（Ｓ１０２）。ここでは、店舗のＰＯＳ端末等にコードＣ１０を読み取らせて支払をするための支払操作、ボタンＢ１４を選択してプレミアム型の残高を送るための送り操作、ボタンＢ１５を選択してプレミアム型の残高にチャージするためのチャージ操作、又は他のユーザから送られたプレミアム型の残高を受け取るための受け取り操作の何れかが行われるものとする。基本型の残高に対する操作等の他の操作が行われた場合には、当該他の操作に応じた処理が実行されて本処理は終了する。

ユーザが支払操作をした場合（Ｓ１０２；支払操作）、電子マネーサーバ１０は、コードＣ１０を読み取ったＰＯＳ端末等から支払要求を受信する（Ｓ１０３）。電子マネーサーバ１０は、支払要求に含まれるコードＩＤに基づいて、どのユーザに対応する支払要求なのかを特定できる。

電子マネーサーバ１０は、決済データベースＤＢ１に基づいて、電子マネーが支払元として設定されており、かつ、残高連携済みのユーザであることを特定すると、銀行サーバ２０に対し、プレミアム型の残高に自動的にチャージするための要求である自動チャージ要求を送信する（Ｓ１０４）。自動チャージ要求には、決済サービスにおけるユーザＩＤと、支払要求に含まれる利用額と同じチャージ額と、が含まれる。なお、Ｓ１０４において、電子マネー以外の決済手段が支払元として設定されている場合、又は、残高連携済みのユーザではないことが特定された場合には、従来の方法と同様にして決済処理が実行され、本処理は終了する。

銀行サーバ２０は、自動チャージ要求を受信すると（Ｓ１０５）、電子マネーサーバ１０との間で、口座残高を利用してプレミアム型の残高にチャージするための自動チャージ処理を実行する（Ｓ１０６）。Ｓ１０６では、銀行サーバ２０は、自動チャージ要求に含まれるユーザＩＤを含む連携情報が格納されたレコードを特定する。銀行サーバ２０は、当該レコードに格納された口座残高を、自動チャージ要求に含まれるチャージ額だけ減少させる。銀行サーバ２０は、電子マネーサーバ１０に対し、口座残高の減少が完了したことを示す減少完了通知を送信する。電子マネーサーバ１０は、減少完了通知を受信すると、プレミアム型の残高をチャージ額だけ増加させる。なお、口座残高がチャージ額よりも少ない場合には、エラーとなり本処理は終了する。

Ｓ１０６の自動チャージ処理が実行されると、電子マネーサーバ１０は、プレミアム型の残高に基づいて、決済処理を実行し（Ｓ１０７）、本処理は終了する。Ｓ１０７では、電子マネーサーバ１０は、決済データベースＤＢ１に格納されたプレミアム型の残高を、Ｓ１０３で受信した支払要求に含まれる利用額だけ減少させる。決済処理自体は、公知の処理を利用可能である。

Ｓ１０２において、ユーザが送り操作をした場合（Ｓ１０２；送り操作）、ユーザ端末３０は、電子マネーサーバ１０に対し、送り要求を送信し（Ｓ１０８）、電子マネーサーバ１０は、ユーザ端末３０から送り要求を受信する（Ｓ１０９）。電子マネーサーバ１０は、送り要求に含まれるコードＩＤに基づいて、どのユーザに対応する送り要求なのかを特定できる。

電子マネーサーバ１０は、決済データベースＤＢ１に基づいて、残高連携済みのユーザであることを特定すると、銀行サーバ２０に対し、自動チャージ要求を送信する（Ｓ１１０）。Ｓ１１０の自動チャージ要求は、Ｓ１０４の自動チャージ要求と同様である。Ｓ１１０の自動チャージ要求に含まれるチャージ額は、ユーザが指定した送り額と同じである。なお、Ｓ１１０において、残高連携済みのユーザではないことが特定された場合には、従来の方法と同様にして送り処理が実行され、本処理は終了する。

銀行サーバ２０は、自動チャージ要求を受信すると（Ｓ１１１）、電子マネーサーバ１０との間で、自動チャージ処理を実行する（Ｓ１１２）。Ｓ１１２の自動チャージ処理は、Ｓ１０６の自動チャージ処理と同様である。Ｓ１１２の自動チャージ処理が実行されると、電子マネーサーバ１０は、プレミアム型の残高に基づいて、送り処理を実行し（Ｓ１１３）、本処理は終了する。Ｓ１１３では、電子マネーサーバ１０は、決済データベースＤＢ１に格納されたプレミアム型の残高を、Ｓ１０９で受信した送り要求に含まれる送り額だけ減少させる。送り処理自体は、公知の処理を利用可能である。

Ｓ１０２において、ユーザがチャージ操作をした場合（Ｓ１０２；チャージ操作）、図８に移り、ユーザ端末３０は、電子マネーサーバ１０に対し、チャージ要求を送信し（Ｓ１１４）、電子マネーサーバ１０は、ユーザ端末３０からチャージ要求を受信する（Ｓ１１５）。電子マネーサーバ１０は、チャージ要求に含まれるコードＩＤに基づいて、どのユーザに対応するチャージ要求なのかを特定できる。

電子マネーサーバ１０は、Ｓ１１５で受信したチャージ要求に基づいて、プレミアム型の残高に対するチャージ処理を実行する（Ｓ１１６）。Ｓ１１６では、電子マネーサーバ１０は、チャージ要求に含まれるチャージ方法情報を参照し、ユーザが指定したチャージ方法を特定する。電子マネーサーバ１０は、ユーザが指定したチャージ方法で、チャージ要求に含まれるチャージ額だけチャージされるように、プレミアム型の残高に対するチャージ処理を実行する。Ｓ１１６におけるチャージ処理自体は、公知のチャージ処理であってよい。なお、Ｓ１１５で基本型の残高のチャージ要求が受信された場合には、基本型の残高に対するチャージ処理が実行され、本処理は終了する。

電子マネーサーバ１０は、決済データベースＤＢ１に基づいて、残高連携済みのユーザであることを特定すると、銀行サーバ２０に対し、自動入金要求を送信する（Ｓ１１７）。自動入金要求には、決済サービスにおけるユーザＩＤと、チャージ要求に含まれるチャージ額と同じ入金額と、が含まれる。なお、Ｓ１１７において、残高連携済みのユーザではないことが特定された場合には、自動入金要求は送信されない。

銀行サーバ２０は、自動入金要求を受信すると（Ｓ１１８）、電子マネーサーバ１０との間で、自動入金処理を実行し（Ｓ１１９）、本処理は終了する。Ｓ１１９では、銀行サーバ２０は、自動入金要求に含まれるユーザＩＤを含む連携情報が格納されたレコードを特定する。銀行サーバ２０は、当該レコードに格納された口座残高を、自動入金要求に含まれる入金額だけ増加させる。銀行サーバ２０は、電子マネーサーバ１０に対し、口座残高の増加が完了したことを示す増加完了通知を送信する。電子マネーサーバ１０は、増加完了通知を受信すると、プレミアム型の残高を入金額だけ減少させる。

Ｓ１０２において、ユーザが受取操作をした場合（Ｓ１０２；受取操作）、図８に移り、ユーザ端末３０は、電子マネーサーバ１０に対し、受取要求を送信し（Ｓ１２０）、電子マネーサーバ１０は、ユーザ端末３０から受取要求を受信する（Ｓ１２１）。電子マネーサーバ１０は、受取要求に含まれるコードＩＤに基づいて、どのユーザに対応する受取要求なのかを特定できる。

電子マネーサーバ１０は、Ｓ１２１で受信した受取要求に基づいて、プレミアム型の残高に対する受取処理を実行する（Ｓ１２２）。Ｓ１２２では、電子マネーサーバ１０は、受取要求に含まれる情報を参照し、ユーザが受け取る受取額を特定する。電子マネーサーバ１０は、ユーザが受け取る受取額だけチャージされるように、プレミアム型の残高に対するチャージ処理を実行する。Ｓ１２２における受取処理自体は、公知のチャージ処理であってよい。なお、Ｓ１２１で基本型の残高の受取要求が受信された場合には、基本型の残高に対する受取処理が実行され、本処理は終了する。

電子マネーサーバ１０は、決済データベースＤＢ１に基づいて、残高連携済みのユーザであることを特定すると、銀行サーバ２０に対し、自動入金要求を送信する（Ｓ１２３）。自動入金要求には、決済サービスにおけるユーザＩＤと、受取要求に含まれる受取額と同じ入金額と、が含まれる。なお、Ｓ１２３において、残高連携済みのユーザではないことが特定された場合には、自動入金要求は送信されない。

銀行サーバ２０は、自動入金要求を受信すると（Ｓ１２４）、電子マネーサーバ１０との間で、自動入金処理を実行し（Ｓ１２５）、本処理は終了する。Ｓ１２５の自動入金処理は、Ｓ１１９の自動入金処理と同様である。

第１実施形態の残高連携システムＳによれば、プレミアム型の残高を増加させるための増加要求が受け付けられた場合に、プレミアム型の残高と連携する口座残高を増加させる。残高連携システムＳは、プレミアム型の残高を減少させるための減少要求が受け付けられた場合に、プレミアム型の残高と連携する口座残高を減少させる。これにより、プレミアム型の残高と、口座残高と、を十分に連携させることができるので、ユーザの利便性が高まる。例えば、ユーザが支払操作をした場合に、より多くの資金がある口座残高を減少させることによって、プレミアム型の残高を利用した決済処理を実行できるので、ユーザの利便性が高まる。例えば、ユーザが送り操作をした場合に、より多くの資金がある口座残高を減少させることによって、プレミアム型の残高を利用した送り処理を実行できるので、ユーザの利便性が高まる。例えば、ユーザがチャージ操作をした場合に、プレミアム型の残高からの出金操作をしなくても、連携先の口座を増加させることができるので、ユーザの利便性が高まる。例えば、ユーザが受取操作をした場合に、プレミアム型の残高からの出金操作をしなくても、連携先の口座を増加させることができるので、ユーザの利便性が高まる。ユーザの利便性が高まることにより、電子マネーの利用を促進し、口座残高の利用を促進することもできる。プレミアム型の残高を口座残高に移行することによって、本来は金利が発生しないプレミアム型の残高分についても金利を発生させることができる。プレミアム型の残高を口座残高に移行することにより、プレミアム型の残高を実質的に０円にすることができるので、未達債務及び滞留規制を回避できる。例えば、ユーザの勤務先がユーザの給与を電子マネーとして払いやすくなるので、給与デジタル払いを実現しやすくなる。

また、残高連携システムＳは、増加要求に応じた額を、電子マネーから口座に自動的に入金することによって、口座残高を増加させる。残高連携システムＳは、減少要求に応じた額を、口座から電子マネーに自動的にチャージすることによって、口座残高を減少させる。自動入金処理及び自動チャージ処理によって残高連携を実現し、ユーザの利便性が高まる。

［２．第２実施形態］
第１実施形態では、プレミアム型の残高から口座残高への自動入金と、口座残高からプレミアム型の残高への自動チャージと、が実行されることによって、残高連携が実現される場合を例に挙げた。第２実施形態では、プレミアム型の残高と、口座残高と、が互いに同期することによって、残高連携が実現される場合を例に挙げる。第２実施形態では、第１実施形態と同様の構成については説明を省略する。

図９は、第２実施形態における残高連携の一例を示す図である。第２実施形態では、プレミアム型の残高として、精算用の残高と、連携用の残高と、の２つが存在するものとする。精算用の残高は、ユーザが保有する資産としての残高である。第２実施形態では、精算用の残高は、０円で固定されるものとする。このため、ユーザは、事実上の資産としては、プレミアム型の残高を保有していないことになる。

連携用の残高は、電子マネーと口座が連携するための仮想的な残高である。連携用の残高は、事実上の資産ではない。連携用の残高は、口座残高と連携するための数値的なデータにすぎない。連携用の残高は、口座残高と同期が行われる。このため、原則として、連携用の残高と、口座残高と、は互いに一致する。図９の例では、連携用の残高は、口座残高と同じ１２０３５００円になる。ただし、ユーザは、１２０３５００円分の電子マネーと、１２０３５００円の現金と、の両方を保有しているのではなく（即ち、ユーザの資産が２４０７０００円というわけではなく）、ユーザが保有する資産としては、口座残高である１２０３５００円の現金だけである。

例えば、図９の状態で、ユーザがボタンＢ１５を選択し、プレミアム型の残高に１０００円分チャージしたとする。プレミアム型の連携用の残高は、１２０４５００円に増加する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が１２０４５００円に増加する。この場合、プレミアム型の精算用の残高は、０円のまま変わらないものとするが、同期が取られるまでは、精算用の残高がチャージ処理によって１０００円になり、同期が取られた後に、精算用の残高が０円に戻ってもよい。

例えば、図９の状態で、ユーザが、他のユーザから２０００円分のプレミアム型の残高を受け取ったとする。プレミアム型の連携用の残高は、１２０５５００円に増加する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が１２０５５００円に増加する。この場合、プレミアム型の精算用の残高は、０円のまま変わらないものとするが、同期が取られるまでは、精算用の残高が受取処理によって２０００円になり、同期が取られた後に、精算用の残高が０円に戻ってもよい。

例えば、図９の状態で、ユーザが店舗のＰＯＳ端末にコードＣ１０を読み取らせて、３０００円の買い物をしたとする。プレミアム型の連携用の残高は、１２００５００円に減少する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が１２００５００円に減少する。この場合、プレミアム型の精算用の残高は、０円のまま変わらないものとするが、同期が取られるまでは、精算用の残高が決済処理によってマイナス３０００円になり、同期が取られた後に、精算用の残高が０円に戻ってもよい。

例えば、図９の状態で、ユーザが、他のユーザに４０００円分のプレミアム型の残高を送ったとする。プレミアム型の連携用の残高は、１１９９５００円に減少する。その後、口座残高がプレミアム型の連携用の残高に合うように同期されて、口座残高が１１９９５００円に減少する。この場合、プレミアム型の精算用の残高は、０円のまま変わらないものとするが、同期が取られるまでは、精算用の残高が決済処理によってマイナス４０００円になり、同期が取られた後に、精算用の残高が０円に戻ってもよい。

なお、ユーザの口座残高が何らかの理由で増減した場合には、当該増減された口座残高に合うように、プレミアム型の連携用の残高が同期される。例えば、ユーザがＡＴＭから口座の現金を引き出した場合には、口座残高が減少するので、減少後の口座残高に合うように、プレミアム型の連携用の残高が同期される。例えば、ユーザの勤務先が口座に給与を振り込んだ場合には、口座残高が増加するので、増加後の口座残高に合うように、プレミアム型の連携用の残高が同期される。

以上のように、第２実施形態の残高連携システムＳでは、プレミアム型の残高と、口座の残高と、を同期させることによって、残高連携を実現するようになっている。以降、第２実施形態の詳細を説明する。

［２－１．第２実施形態の残高連携システムで実現される機能］
図１０は、第２実施形態の残高連携システムＳで実現される機能の一例を示す図である。同期部１０７は、制御部１１を主として実現される。同期部１０７は、口座残高増加部１０３及び口座残高減少部１０６を含む。同期部２０３は、制御部２１を主として実現される。同期部２０３は、口座残高増加部２０１及び口座残高減少部２０２を含む。

第２実施形態の決済データベースＤＢ１には、電子マネー残高の更新日時が電子マネー情報に含まれているものとする。電子マネーサーバ１０は、電子マネー残高を更新すると、現在日時が更新日時として電子マネー情報に含まれるように、決済データベースＤＢ１を更新する。第２実施形態でも、プレミアム型の残高と、基本型の残高と、が存在するので、電子マネー情報には、プレミアム型の残高の更新日時と、基本型の残高の更新日時と、が含まれる。第２実施形態の電子マネー情報は、プレミアム型の残高として、精算用の残高と、連携用の残高と、を含む。第２実施形態では、精算用の残高が０円で固定されているので、電子マネー情報は、精算用の残高の更新日時ではなく、連携用の残高の更新日時を含む。

第２実施形態の口座データベースＤＢ２には、口座残高の更新日時が格納されているものとする。銀行サーバ２０は、口座残高を更新すると、現在日時が更新日時として当該口座残高に関連付けられるように、口座データベースＤＢ２を更新する。口座残高は、残高連携以外にも増減することがあるので、この場合にも、口座残高の更新日時が口座データベースＤＢ２に格納される。例えば、ユーザがＡＴＭから現金を引き出したり、ユーザの給与振込が行われたりした場合には、口座残高が更新されるので、更新日時が口座データベースＤＢ２に格納される。

［電子マネーサーバ及び銀行サーバの同期部］
同期部１０７，２０３は、電子マネー残高及び口座残高を同期させる。同期とは、電子マネー残高及び口座残高を一致させることである。電子マネーサーバ１０の同期部１０７と、銀行サーバ２０の同期部２０３と、が協働することによって、同期が実現される。同期では、電子マネー残高に口座残高が合う（口座残高だけが変わる）第１パターン、口座残高に電子マネー残高が合う（電子マネー残高だけが変わる）第２パターン、電子マネー残高と口座残高の何れも変わらない第３パターン、及び電子マネー残高と口座残高の両方が変わる第４パターンの４パターンが存在する。ここでは、プレミアム型の残高のうちの連携用の残高を、単に電子マネー残高という。

第２実施形態では、同期部１０７，２０３は、第１パターン～第４パターンの何れかの同期を実行する。電子マネー残高及び口座残高の同期自体は、種々のデータ同期手法を利用可能である。例えば、同期部１０７は、銀行サーバ２０に対し、電子マネー残高と、電子マネー残高の更新日時と、を送信する。同期部２０３は、電子マネーサーバ１０に対し、口座残高と、口座残高の更新日時と、を送信する。同期部１０７，２０３は、互いにこれの情報を送りあい、何れのパターンであるかを特定し、同期を実行する。ここでは、一定時間ごとに、同期が実行される場合を説明する。この一定時間は、任意の長さであってよく、例えば、数秒以内であってもよいし、それ以上の時間間隔であってもよい。

例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新され、かつ、口座残高が更新されていない場合には、第１パターンになる。この場合、同期部１０７，２０３は、互いに協働して、口座残高が電子マネー残高と同じ値になるように、口座残高を更新する。例えば、同期部１０７は、銀行サーバ２０から口座残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、電子マネー残高を変えない。同期部２０３は、電子マネーサーバ１０から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、電子マネーサーバ１０から受信した電子マネー残高と一致するように、口座残高を更新する。

例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新されておらず、かつ、口座残高が更新された場合には、第２パターンになる。この場合、同期部１０７，２０３は、互いに協働して、電子マネー残高が口座残高と同じ値になるように、電子マネー残高を更新する。例えば、同期部１０７は、銀行サーバ２０から口座残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、銀行サーバ２０から受信した口座残高と一致するように、電子マネー残高を更新する。同期部２０３は、電子マネーサーバ１０から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、口座残高を変えない。

例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新されておらず、かつ、口座残高も更新されていない場合には、第３パターンになる。この場合、同期部１０７，２０３は、互いに協働して、電子マネー残高及び口座残高が変わらないようにする。例えば、同期部１０７は、銀行サーバ２０から口座残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、電子マネー残高を変えない。同期部２０３は、電子マネーサーバ１０から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも前の更新日時であることを検知すると、口座残高を変えない。

例えば、前回同期が取られてから現時点までの間に、電子マネー残高が更新され、かつ、口座残高も更新された場合には、第４パターンになる。この場合、同期部１０７，２０３は、互いに協働して、電子マネー残高及び口座残高の両方が変わるようにする。例えば、同期部１０７は、銀行サーバ２０から口座残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、前回の同期時からの口座残高の変化量だけ、電子マネー残高を変える。前回の同期時の口座残高は、決済データベースＤＢ１に保持されていてもよいし、銀行サーバ２０から電子マネーサーバ１０に送信されてもよい。口座残高の変化量が銀行サーバ２０から電子マネーサーバ１０に送信されてもよい。同期部２０３は、電子マネーサーバ１０から電子マネー残高の更新日時を取得し、前回同期が取られた日時よりも後の更新日時であることを検知すると、前回の同期時からの電子マネー残高の変化量だけ、口座残高を変える。前回の同期時の口座残高は、口座データベースＤＢ２に保持されていてもよいし、電子マネーサーバ１０から銀行サーバ２０に送信されてもよい。電子マネー残高の変化量が電子マネーサーバ１０から銀行サーバ２０に送信されてもよい。

例えば、第１パターン又は第４パターンでは、第２同期部１０７の口座残高増加部１０３は、電子マネー残高増加部１０２により増加した電子マネー残高を、口座残高に同期させることによって、口座残高を増加させることがある。同様に、第１パターン又は第４パターンでは、同期部１０７の口座残高減少部１０６は、電子マネー残高減少部１０５により減少した電子マネー残高を、口座残高に同期させることによって、口座残高を減少させることがある。このため、第１パターン又は第４パターンにおける同期は、口座残高増加部１０３又は口座残高減少部１０６の処理の一例である。

第２実施形態では、同期部１０７，２０３は、所定の同期条件が満たされた場合に、電子マネー残高及び口座残高を同期させる。同期条件は、同期するか否かの基準となる条件である。第２実施形態では、定期的に同期が取られる場合を説明する。同期条件が満たされたか否かは、同期部１０７，２０３の両方によって判定されてもよいし、同期部１０７，２０３の何れか一方が判定して他方に通知してもよい。同期条件が満たされるまでは、同期は行われず、同期条件が満たされた場合に同期が行われる。

なお、同期条件は、任意の条件であってよく、第２実施形態のような時間的な条件に限られない。例えば、電子マネー残高又は口座残高の何れか一方が更新されることが同期条件になってもよい。この場合、定期的に同期が取られるのではなく、電子マネー残高又は口座残高の何れかが更新されるたびに同期が取られる。電子マネー残高及び口座残高の両方が同時に更新された場合には、第４パターンのように同期が取られるようにすればよい。同期条件は、ユーザが何らかの操作を行うといった他の条件であってもよい。

第２実施形態では、プレミアム型の電子マネーは、精算用の電子マネー残高と、連携用の電子マネー残高と、を有する。先述したように、第２実施形態では、精算用の電子マネー残高は、０円で固定されていてもよい。電子マネー残高増加部１０２は、精算用の電子マネー残高は増加させずに、連携用の電子マネー残高を増加させる。電子マネー残高減少部１０５は、精算用の電子マネー残高は減少させずに、連携用の電子マネー残高を減少させる。同期部１０７は、連携用の電子マネー残高と、口座残高と、を同期させる。

［２－２．第２実施形態の残高連携システムで実現される処理］
図１１は、第２実施形態の残高連携システムＳで実行される処理の一例を示す図である。図１１の処理は、先述した４つのパターンのうち、主に第１パターンに関する処理である。第１実施形態で説明した図７の処理と同様に、ユーザは、残高連携の手続を完了しているものとする。また、第１実施形態と同様に、プレミアム型の残高に対する処理について説明する。

図１１のＳ２００～Ｓ２０３の処理は、Ｓ１００～Ｓ１０３の処理と同様である。電子マネーサーバ１０は、決済データベースＤＢ１に基づいて、電子マネーが支払元として設定されており、かつ、残高連携済みのユーザであることを特定すると、連携用の残高が店舗等における支払額だけ減少するように、決済処理を実行する（Ｓ２０４）。その後、電子マネーサーバ１０及び銀行サーバ２０の間で、同期処理が実行され（Ｓ２０５）、本処理は終了する。この場合、決済処理により連携用の残高が減少しているので、同期処理により、減少した連携用の残高に合うように、口座残高が減少する。

Ｓ２０２において、ユーザが送り操作をした場合（Ｓ２０２；送り操作）、Ｓ１０８及びＳ１０９の処理と同様のＳ２０６及びＳ２０７の処理が実行される。電子マネーサーバ１０は、決済データベースＤＢ１に基づいて、残高連携済みのユーザであることを特定すると、連携用の残高が他のユーザへの送り額だけ減少するように、送り処理を実行する（Ｓ２０８）。その後、Ｓ２０５の同期処理が実行され、本処理は終了する。この場合、送り処理により連携用の残高が減少しているので、同期処理により、減少した連携用の残高に合うように、口座残高が減少する。

Ｓ２０２において、ユーザがチャージ操作をした場合（Ｓ２０２；チャージ操作）、Ｓ１１４及びＳ１１５の処理と同様のＳ２０９及びＳ２１０の処理が実行される。電子マネーサーバ１０は、残高連携済みのユーザであることを特定すると、連携用の残高がチャージ額だけ増加するように、チャージ処理を実行する（Ｓ２１１）。その後、Ｓ２０５の同期処理が実行され、本処理は終了する。この場合、チャージ処理により連携用の残高が増加しているので、同期処理により、増加した連携用の残高に合うように、口座残高が増加する。

Ｓ２０２において、ユーザが受取操作をした場合（Ｓ２０２；受取操作）、Ｓ１２０及びＳ１２１の処理と同様のＳ２１２及びＳ２１３の処理が実行される。電子マネーサーバ１０は、残高連携済みのユーザであることを特定すると、連携用の残高が受取額だけ増加するように、受取処理を実行する（Ｓ２１４）。その後、Ｓ２０５の同期処理が実行され、本処理は終了する。この場合、受取処理により連携用の残高が増加しているので、同期処理により、増加した連携用の残高に合うように、口座残高が増加する。

なお、第２実施形態では、決済処理、送り処理、チャージ処理、及び受取処理が実行された後に、同期処理が実行される場合を説明したが、同期処理が実行された後に、決済処理、送り処理、チャージ処理、及び受取処理が実行されてもよい。特に、決済処理及び送り処理のように、連携用の残高が減少する処理については、同時に口座残高からの引出又は振込が行われるとユーザの資金が足りなくなることがあるので、同期処理によってユーザの資金が足りることが確認された後に、決済処理及び送り処理が実行されてもよい。同様に、口座残高からの引出又は振込が行われる場合も同様に、同期処理が実行された後に、口座残高からの引出又は振込が行われてもよい。

第２実施形態によれば、チャージ処理又は受取処理により増加した電子マネー残高を、口座残高に同期させることによって、口座残高を増加させる。決済処理又は送り処理により減少した電子マネー残高を、口座残高に同期させることによって、口座残高を減少させる。同期処理によって、プレミアム型の残高と、口座残高と、を十分に連携させることができるので、ユーザの利便性が高まる。更に、第１実施形態で説明したような自動入金及び自動チャージが必要無くなるので、決済処理等の各処理の完了までに要する時間を短くすることができる。

第２実施形態の残高連携システムＳは、精算用の電子マネー残高は増加させずに、連携用の電子マネー残高を増加させる。残高連携システムＳは、精算用の電子マネー残高は減少させずに、連携用の電子マネー残高を減少させる。残高連携システムＳは、連携用の電子マネー残高と、口座残高と、を同期させる。これにより、第１実施形態と同様に、本来は金利が発生しないプレミアム型の残高分についても金利を発生させることができ、かつ、未達債務及び滞留規制を回避しやすくなる。

第２実施形態の残高連携システムＳは、精算用の電子マネー残高は、０円で固定されている。これにより、より多くの資金を口座に移すことができるので、より多くの金利を得ることができ、かつ、未達債務及び滞留規制をより回避しやすくなる。

［３．変形例］
なお、本開示は、以上に説明した第１実施形態及び第２実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。以降説明する変形例では、第２実施形態のように、電子マネー残高及び口座残高が同期する場合を例に挙げるが、第１実施形態のように、電子マネーから口座への自動入金と、口座から電子マネーへの自動チャージと、が行われる場合にも、同様の変形例を適用可能である。

図１２は、変形例における機能ブロックの一例を示す図である。第１制限部１０８、指定受付部１０９、手数料発生部１１０、表示制御部１１１、及び上限設定部１１２は、制御部１１を主として実現される。第２制限部２０４、増加要求受付部２０５、関連付け部２０６、及び口座残高移動部２０７は、制御部２１を主として実現される。

［３－１．変形例１］
例えば、第２実施形態の残高連携システムＳにおいて、通信障害等の何らかの障害によって、電子マネー残高及び口座残高が同期されない可能性がある。この場合、ユーザが、電子マネーを利用した直後に口座残高を全額引き出したとすると、ユーザが本来所有する資産よりも多くの額を引き出せることになる。このため、電子マネー残高及び口座残高が同期されなかった場合に、電子マネー残高及び口座残高の少なくとも一方の利用が制限されてもよい。以降、電子マネー残高及び口座残高の両方の利用が制限される場合を例に挙げる。

変形例１の電子マネーサーバ１０及び銀行サーバ２０は、同期条件が満たされた場合に、同期が行われたか否かを判定する。例えば、電子マネーサーバ１０及び銀行サーバ２０は、同期条件が満たされた場合に、互いの通信が可能か否かを判定する。この判定方法自体は、通信障害の発生有無を判定可能な公知の方法を利用可能である。電子マネーサーバ１０及び銀行サーバ２０は、互いの通信が可能ではないと判定した場合に、同期が行われなかったと判定する。例えば、電子マネーサーバ１０及び銀行サーバ２０は、互いの通信自体は可能であるが、第２実施形態で説明した同期の処理が最後まで完了しなかった場合にも、同期が行われなかったと判定する。

変形例１の残高連携システムＳは、第１制限部１０８及び第２制限部２０４を含む。第１制限部１０８は、同期条件が満たされても同期が行われなかった場合に、電子マネー残高の利用を制限する。電子マネー残高の利用を制限するとは、電子マネー残高の全部又は一部を利用できないようにすることである。例えば、電子マネー残高が減少しないようにすることは、電子マネー残高の利用を制限することに相当する。例えば、電子マネー残高の減少自体は許可するが、減少量が閾値以下になる範囲で許可することは、利用を制限することに相当する。他にも例えば、電子マネー残高を利用可能な回数を閾値未満にすること、電子マネー残高を利用可能な総額を閾値未満にすることが、電子マネー残高の利用を制限することに相当してもよい。

変形例１では、第１制限部１０８が、電子マネー残高を所定の範囲内でのみ利用できるように制限する場合を説明する。この範囲は、任意の値を設定可能である。電子マネーの利用を許可する範囲の設定は、決済サービスの管理者によって行われてもよいし、ユーザが自分で指定してもよい。例えば、第１制限部１０８は、数千円程度の少額の決済処理又は送り処理であれば許可するが、それ以上の高額の決済処理又は送り処理については許可しない。第１制限部１０８は、電子マネー残高を一切利用できないように制限してもよい。

第２制限部２０４は、同期条件が満たされても同期が行われなかった場合に、口座残高の利用を制限する。口座残高の利用を制限するとは、口座残高の全部又は一部を利用できないようにすることである。例えば、口座残高が減少しないようにすることは、口座残高の利用を制限することに相当する。例えば、口座残高の減少自体は許可するが、減少量が閾値以下になる範囲で許可することは、利用を制限することに相当する。他にも例えば、口座残高を利用可能な回数を閾値未満にすること、口座残高を利用可能な総額を閾値未満にすることが、口座残高の利用を制限することに相当してもよい。

変形例１では、第２制限部２０４が、口座残高を所定の範囲内でのみ利用できるように制限する場合を説明する。例えば、第２制限部２０４は、数千円程度の範囲内の振込又は引出であれば許可するが、それ以上の振込又は引出については許可しない。この範囲は、任意の値を設定可能である。口座の利用を許可する範囲の設定は、金融サービスの管理者によって行われてもよいし、ユーザが自分で指定してもよい。第２制限部２０４は、口座残高を一切利用できないように制限してもよい。

なお、残高連携システムＳは、第２制限部２０４を含まなくてもよい。この場合、電子マネー残高及び口座残高のうち、利用が制限されるのは、電子マネー残高のみとなる。逆に、残高連携システムＳは、第１制限部１０８を含まなくてもよい。この場合、電子マネー残高及び口座残高のうち、利用が制限されるのは、口座残高のみとなる。変形例１の残高連携システムＳは、第１制限部１０８及び第２制限部２０４の少なくとも一方を含み、通信障害等が発生した場合に、電子マネー残高及び口座残高の少なくとも一方の利用を制限すればよい。

変形例１の残高連携システムＳは、同期条件が満たされても同期が行われなかった場合に、電子マネー残高及び口座残高の少なくとも一方の利用を制限する。これにより、電子マネー残高及び口座残高の少なくとも一方が不当に利用されるといったことを防止できる。例えば、ユーザが電子マネー残高を利用した直後に、電子マネー残高及び口座残高が同期していないにもかかわらず、口座残高が全額引き出されるといったことを防止できる。逆に、ユーザが口座残高を利用した直後に、電子マネー残高及び口座残高が同期していないにもかかわらず、電子マネー残高の全額を支払で利用するといったことを防止できる。

［３－２．変形例２］
例えば、ユーザが銀行に口座を開設していない場合には、ユーザに、電子マネー専用の振込入金口座を開設してもらうようにしてもよい。振込入金口座は、いわゆる仮想口座（仮口座）であり、通常の口座（実口座）とは異なる。振込入金口座は、残高が０円で固定されている。振込入金口座を開設するための手順は、通常の口座を開設する手順と同様であってもよいが、変形例２では、通常の口座よりも簡易的であるものとする。例えば、ユーザがプレミアム型の利用を開始する際に、決済サービスでｅＫＹＣと呼ばれる本人確認が行われた場合には、決済サービスにおける本人確認の結果が流用されてもよい。

図１３は、変形例２の概要を示す図である。変形例２では、電子マネーと連携する口座は、複数のユーザに共通の親口座である。親口座の名義人は、複数のユーザに共通である。変形例２では、親口座の名義人が電子マネーの事業者である「ＡＡＡキャッシュ株式会社」であるものとするが、親口座の名義人は、他の名義人であってもよい。変形例２では、親口座が、電子マネーの管理者の法人支店である「ＡＡＡキャッシュ支店」に開設されている場合を説明するが、親口座は、任意の支店に開設可能である。例えば、他のユーザの実口座が開設されている支店と同じ支店に、親口座が開設されてもよい。

親口座には、複数のユーザの各々に関連付けられた、当該ユーザの電子マネー残高を増加させるための振込入金口座が関連付けられている。このため、親口座と、振込入金口座と、は１対多で対応する。１つの親口座には、任意の数の振込入金口座を関連付けることができる。例えば、数個～数十個程度の振込入金口座が親口座に関連付けられてもよいし、それ以上の振込入金口座が親口座に関連付けられてもよい。変形例２では、振込入金口座が、いわゆる仮想口座であり、残高が０円で固定されているものとするが、振込入金口座は、１円以上の残高を有することができてもよい。

変形例２では、銀行サーバ２０は、増加要求受付部２０５を含む。増加要求の意味は、第１実施形態で説明した通りであるが、変形例２では、振込入金口座に対する入金が電子マネーの増加要求に相当する。増加要求受付部２０５は、振込入金口座に対する振込要求を、増加要求として受け付ける。振込要求は、振込入金口座に対する振込をするための要求である。振込要求自体は、公知の金融サービスで利用されている要求であってよい。例えば、振込要求は、振込先の金融機関、支店名、口座番号、名義人、及び振込額を含む。振込額は、プレミアム型の残高に対するチャージ額に相当する。振込入金口座は、他のユーザからの振込を受け付けてもよい。この場合、振込額は、ユーザに対するプレミアム型の残高の送り額に相当する。

口座残高増加部２０１は、振込要求が受け付けられた場合に、振込入金口座から親口座に自動的に入金することによって、親口座を増加させる。変形例２では、振込入金口座の残高が０円で固定されているので、口座残高増加部２０１は、振込入金口座の残高を増加させることなく、振込入金口座から親口座への入金を実行する。振込入金口座の残高は、一時的に増加してもよい。この場合、口座残高増加部２０１は、振込入金口座の残高を振込額だけ増加させた直後に、振込入金口座から親口座への入金を実行すればよい。

変形例２の親口座の口座残高は、複数のユーザに共通の共通残高である。このため、親口座の共通残高は、複数のユーザの各々の個別残高の合計である。図１３の例では、ユーザＸ，Ｙ，Ｚの３人の振込入金口座が親口座に関連付けられている。ユーザＸが自身の振込入金口座に３００００円を入金し、ユーザＹが自身の振込入金口座に２００００円を入金し、ユーザＺが自身の振込入金口座に１００００円を入金したとする。この場合、親口座には、ユーザＸ～Ｚによる入金の総額である６００００円が親口座の共通残高になる。

親口座には、ユーザごとの個別残高が関連付けられている。図１３の例では、データ記憶部２００に記憶された個別残高データベースＤＢ３に、ユーザごとの個別残高が格納されている。例えば、親口座の共通残高である６００００円のうち、ユーザＸの個別残高が３００００円であることが、個別残高データベースＤＢ３に示される。親口座の共通残高である６００００円のうち、ユーザＹの個別残高が２００００円であることが、個別残高データベースＤＢ３に示される。親口座の共通残高である６００００円のうち、ユーザＺの個別残高が１００００円であることが、個別残高データベースＤＢ３に示される。個別残高データベースＤＢ３には、個々のユーザのユーザ識別情報と、このユーザの個別残高と、が関連付けられている。

口座残高増加部２０１は、増加要求が受け付けられた場合に、共通残高及び個別残高を増加させる。例えば、口座残高増加部２０１は、あるユーザの振込入金口座に対する入金が増加要求として行われた場合に、この入金の額だけ、この振込入金口座に関連付けられた親口座の共通残高と、このユーザの個別残高と、の両方を増加させる。口座残高増加部２０１は、あるユーザのプレミアム型のチャージ又は受取が発生した場合も、このユーザに関連付けられた親口座の共通残高と、このユーザの個別残高と、の両方を増加させる。

口座残高減少部２０２は、減少要求が受け付けられた場合に、共通残高及び個別残高を減少させる。変形例２では、振込入金口座しか保有していないユーザは、親口座からの出金はできないものとする。このため、口座残高減少部２０２は、あるユーザのプレミアム型の支払又は送りが発生した場合に、減少要求に応じた額だけ、このユーザに関連付けられた親口座の共通残高と、このユーザの個別残高と、の両方を減少させる。

変形例２の残高連携システムＳは、親口座には、複数のユーザの各々の振込入金口座が関連付けられており、振込入金口座に対する振込要求が、増加要求として受け付けられる。残高連携システムＳは、振込要求が受け付けられた場合に、振込入金口座から親口座に自動的に入金することによって、親口座を増加させる。これにより、ユーザが振込入金口座を利用して手軽に電子マネーのチャージをすることができる。例えば、ユーザの勤務先の給与を振込入金口座に入金してもらえば、すぐに電子マネーとして利用することができるので、実質的に給与デジタル払いを実現できる。

また、残高連携システムＳは、増加要求が受け付けられた場合に、共通残高及び個別残高を増加させ、減少要求が受け付けられた場合に、共通残高及び個別残高が減少させる。これにより、複数のユーザに共通の親口座にしたとしても、個々のユーザの個別残高を正確に管理できる。

［３－３．変形例３］
例えば、変形例２において、同じ親口座のユーザ間で電子マネーが送られる場合には、親口座の共通残高が変更されずに、電子マネーを送る側のユーザの個別残高と、電子マネーを受け取る側のユーザの個別残高と、が変更される。図１３の例において、ユーザＸが、ユーザＺに対し、２０００円分のプレミアム型の残高を送ったとする。この場合、親口座の共通残高は、６００００円のまま変化しない。個別残高データベースＤＢ３におけるユーザＸの個別残高が３００００円から２８０００円に減少する。個別残高データベースＤＢ３におけるユーザＺの個別残高が１００００円から１２０００円に増加する。

変形例３では、親口座が同じユーザ間でプレミアム型の残高が送られた場合には、親口座の共通残高は変化せずに、電子マネーを送る側のユーザの個別残高が減少し、かつ、電子マネーを受け取る側のユーザの個別残高が増加する。口座残高減少部２０２は、口座残高減少部１０６と協働して、電子マネーを送る側のユーザの個別残高を、送り要求に応じた送り額だけ減少させる。口座残高増加部２０１は、口座残高増加部１０３と協働して、電子マネーを受け取る側のユーザの個別残高を、送り要求に応じた送り額だけ増加させる。電子マネーサーバ１０内で実行される処理と、電子マネーサーバ１０及び銀行サーバ２０の間で実行される処理と、は第１実施形態又は第２実施形態で説明した通りである。

変形例３の残高連携システムＳは、同じ親口座のユーザ間で電子マネーが送られる場合には、親口座の残高を変更せずに、電子マネーを送る側のユーザの個別残高と、電子マネーを受け取る側のユーザの個別残高と、を変更する。これにより、親口座から他の口座への振込が発生せず、個別残高データベースＤＢ３を更新すれば済むため、銀行サーバ２０の負荷を軽減できる。

［３－４．変形例４］
例えば、減少要求受付部１０４は、店舗で電子マネーが利用される場合に、減少要求を受け付けてもよい。この減少要求は、第１実施形態及び第２実施形態で説明した支払要求である。店舗は、決済サービスのユーザの１人であり、決済処理により支払われた電子マネーの残高は、店舗が保有する電子マネーの残高に移動してもよい。店舗の電子マネー残高は、店舗を利用したユーザの電子マネー残高の減少分だけ増加する。店舗は、親口座とは別の店舗用親口座に関連付けられていてもよい。店舗が保有する電子マネーの仕組みは、第１実施形態、第２実施形態、及び変形例１～３で説明したものと同様であってよい。

変形例４では、ユーザの親口座と、店舗用親口座と、は金融機関、支店、及び名義人が同じであるものとする。例えば、店舗用親口座も「ＢＢＢ銀行」の「ＡＡＡキャッシュ支店」に開設されている。店舗用親口座の名義人も「ＡＡＡキャッシュ株式会社」であるものとする。変形例４の口座残高減少部１０６は、減少要求が受け付けられた場合に、親口座から店舗用親口座への振替を行うことによって、口座残高を減少させる。金融機関、支店、及び名義人が同じため、振替扱いによって、店舗への支払が完了することになる。振替の処理自体は、公知の処理を利用可能である。

例えば、図１３の例において、ユーザＸが店舗で支払操作をして３０００円分の買い物をしたとする。この場合、ユーザＸの親口座の共通残高が６００００円から５７０００円に減少し、個別残高データベースＤＢ３におけるユーザＸの個別残高が３００００円から２７０００円に減少する。図１３には示さない店舗用親口座の残高は、３０００円分増加する。複数の店舗に共通の店舗用親口座とする場合、店舗用親口座にも個別残高データベースＤＢ３が関連付けられており、店舗ごとの個別残高が格納されている。この場合、ユーザによる支払を受けた店舗の個別残高が３０００円分増加する。

変形例４の残高連携システムＳは、ユーザの親口座と、店舗用親口座と、は金融機関、支店、及び名義人が同じなので、減少要求が受け付けられた場合に、親口座から店舗用親口座への振替を行うことによって、口座残高を減少させる。これにより、振込手数料を発生させることなく、店舗への支払が可能になる。

［３－５．変形例５］
例えば、ユーザが、変形例２で説明した振込入金口座を開設した後に、銀行に実口座を開設することがある。この場合、ユーザが新たに開設した実口座の口座残高と、ユーザの電子マネー残高と、が連携するようにしてもよい。即ち、ユーザがそれまで利用していた振込入金口座及び親口座ではなく、ユーザが新たに開設した実口座が残高連携で利用されるようにしてもよい。

変形例５の残高連携システムＳは、ユーザが実口座を開設した場合に、当該ユーザの電子マネーと、振込入金口座及び親口座と、の関連付けを解除し、かつ、当該ユーザの電子マネーと、当該ユーザの実口座と、を関連付ける関連付け部２０６を更に含む。変形例２で説明したように、ユーザが振込入金口座を利用する場合には、口座データベースＤＢ２に、ユーザの振込入金口座、親口座、及びユーザの電子マネー識別情報（図６の例では、連携情報が示すユーザＩＤ）が関連付けられているものとする。

変形例５では、関連付け部２０６は、口座データベースＤＢ２における、振込入金口座及び親口座と、ユーザの電子マネー識別情報と、の関連付けを解除する。例えば、関連付け部２０６は、振込入金口座及び親口座の情報を口座データベースＤＢ２から削除する。関連付け部２０６は、ユーザが新たに作成した実口座の支店、口座番号、名義人、及び口座残高が、振込入金口座に代えて口座データベースＤＢ２に格納する。

関連付け部２０６による処理が実行された後は、実口座を開設したユーザの電子マネーと、振込入金口座及び親口座と、が連携する状態から、当該ユーザの電子マネーと、当該ユーザの実口座と、が連携する状態に変わる。即ち、変形例２のような状態から、第１実施形態又は第２実施形態のような状態に変わる。連携する口座が変わった後の処理は、第１実施形態又は第２実施形態で説明した通りである。

変形例５の残高連携システムＳは、ユーザが実口座を開設した場合に、当該ユーザの電子マネーと、振込入金口座及び親口座と、の関連付けを解除し、かつ、当該ユーザの電子マネーと、当該ユーザの実口座と、を関連付ける。これにより、ユーザが実口座を開設した後は、口座残高の引き出しが可能な実口座を電子マネーと連携させることができるので、ユーザの利便性が高まる。

［３－６．変形例６］
例えば、変形例５のように、ユーザが実口座を開設した場合には、親口座に存在したユーザの資金が、新たに開設された実口座に移動されるようにしてもよい。変形例６の残高連携システムＳは、親口座の口座残高のうち、実口座を開設したユーザの分を、当該実口座に移動させる口座残高移動部２０７を更に含む。口座残高移動部２０７は、親口座の口座残高のうち、実口座を開設したユーザの残高分を、新たに開設された実口座に移動させる。図１３の例において、ユーザＸが実口座を開設したとすると、親口座の口座残高のうちの３００００円分は、ユーザＸの資金なので、口座残高移動部２０７は、この３００００円分をユーザＸの実口座に移動させる。資金の移動自体は、振込によって行われるようにすればよい。ユーザの実口座が開設されたことは、金融サービスの管理者による操作によって特定されるようにすればよい。

変形例６の残高連携システムＳは、親口座の口座残高のうち、実口座を開設したユーザの分を、当該実口座に移動させる。これにより、ユーザが自身で振込の操作をする必要がなく、かつ、ユーザの資金が無駄にならないので、ユーザの利便性が高まる。

［３－７．変形例７］
例えば、口座残高は、閾値を超えた分のプレミアム型の残高と連携してもよい。この閾値は、従来のプレミアム型の残高のように電子マネーを利用する分である。変形例７以降の変形例では、変形例２～６で説明した振込入金口座を前提としなくてもよい。

口座残高増加部１０３は、増加要求が受け付けられた場合に、閾値を超えた分に基づいて、口座残高を増加させる。例えば、第１実施形態のように残高連携をする場合、プレミアム型の残高が全て口座残高に自動入金されるのではなく、ある閾値を超えた分だけが自動入金される。この閾値の範囲内では、プレミアム型の残高が残ることになる。例えば、この閾値を１００００円として、１３０００円のチャージが発生したとする。この場合、口座残高増加部１０３は、１００００円を超えた３０００円分を、連携先の口座残高に自動入金する。１３０００円のチャージのうちの１００００円分は、プレミアム型の残高として残る。

口座残高減少部１０３は、減少要求が受け付けられた場合に、閾値を超えた分に基づいて、口座残高を減少させる。例えば、第１実施形態のように残高連携をする場合、支払額又は送り額の全てがプレミアム型の残高に自動チャージされるのではなく、ある閾値を超えた分だけが自動入金される。上記の例において、プレミアム型の残高が１００００円分残ったとする。この場合に、ユーザが１５００００円分の支払をする場合、口座残高減少部１０３は、閾値である１００００円を超えた５０００円分が自動チャージされるので、連携先の口座残高を５０００円減少させる。

第２実施形態のように残高連携をする場合、閾値を超えない範囲のプレミアム型の残高は、精算用の残高として決済サービスに保持される。例えば、精算用の残高が０円であり、この閾値を１００００円として、１３０００円のチャージが発生したとする。この場合、精算用の残高が１００００円になり、口座残高増加部１０３は、１００００円を超えた３０００円分だけ、連携用の残高に増加させる。連携用の残高が同期する処理は、第２実施形態と同様である。上記の例において、ユーザが１５００００円分の支払をする場合、口座残高減少部１０３は、閾値である１００００円を超えた５０００円分が利用されるように、連携用の残高を減少させる。その後、第２実施形態で説明したように、連携用の残高に合うように口座残高が変更される。

変形例７の残高連携システムＳは、増加要求が受け付けられた場合に、口座残高と連携する電子マネー残高の一部に基づいて、口座残高を増加させる。残高連携システムＳは、減少要求が受け付けられた場合に、口座残高と連携する電子マネー残高の一部に基づいて、口座残高を減少させる。これにより、口座残高と連携させたくない残高分は、通常のプレミアム型の残高として利用できるようになるので、ユーザの利便性が高まる。

［３－８．変形例８］
例えば、残高連携システムＳは、電子マネーのユーザによる、変形例７で説明した閾値に関する指定を受け付ける指定受付部１０９を更に含んでもよい。ユーザにより指定された閾値は、決済データベースＤＢ１に格納されるものとする。プレミアム型の残高のうち、ユーザにより指定された閾値を超えた範囲で口座残高と連携する。ユーザが閾値を決める点で変形例７とは異なるが、他の点については、変形例７と同様である。

変形例８の残高連携システムＳは、電子マネーのユーザによる、残高連携をさせない分の閾値に関する指定を受け付ける。これにより、プレミアム型の残高のうち、ユーザが所望する額だけは残高連携せずに、通常のプレミアム型の残高として残すことができるので、ユーザの利便性が高まる。プレミアム型の残高として残っている分については、支払時の自動チャージ処理が発生しないので、決済完了を高速化できる。

［３－９．変形例９］
例えば、残高連携システムは、口座残高増加部１０３により口座残高が増加する場合には所定の手数料を発生させず、電子マネーのユーザにより、電子マネー残高からの出金が指示された場合に、手数料を発生させる手数料発生部１１０を更に含んでもよい。手数料を発生させる方法自体は、公知の処理を利用可能である。例えば、手数料発生部１１０は、電子マネー残高から手数料分が減少することによって、手数料を発生させる。手数料は、固定値であってもよいし、出金額に応じた値であってもよい。第１実施形態のような自動入金が発生したり、第２実施形態のような同期が行われて口座残高が増えたりしたとしても、手数料発生部１１０は、残高連携の場合には手数料を発生させない。

変形例９の残高連携システムＳは、口座残高増加部１０３により口座残高が増加する場合には所定の手数料を発生させず、電子マネーのユーザにより、電子マネー残高からの出金が指示された場合に、手数料を発生させる。これにより、残高連携の場合には手数料が発生しないので、ユーザに残高連携をさせる動機付けを与えることができる。

［３－１０．変形例１０］
例えば、第１実施形態及び第２実施形態で説明したように、電子マネー残高は、０円で固定されている場合に、残高連携システムＳは、口座残高に基づいて、電子マネーのユーザのユーザ端末３０に、電子マネー残高に関する残高情報を表示させる表示制御部１１１を更に含んでもよい。残高情報は、電子マネー残高を識別可能な情報である。例えば、図２のトップ画面Ｇ１のような数値であってもよいし、テキスト又はアイコン等の他の情報であってもよい。第１実施形態のように残高連携を行う場合にも、プレミアム型の残高は、チャージ後すぐに自動入金されたり、自動チャージ後すぐに利用されたりするので、実質的に０円で固定されているということができる。このため、第１実施形態のように残高連携を行う場合と、第２実施形態のように残高連携を行う場合と、の何れの場合にも、表示制御部１１１による残高情報の表示が可能である。

例えば、表示制御部１１１は、銀行サーバ２０から、連携先の口座残高を取得する。表示制御部１１１は、ユーザの口座残高を、プレミアム型の残高としてユーザ端末３０に表示させる。例えば、表示制御部１１１は、プレミアム型の残高が０円だったとしても、ユーザの口座残高（例えば、１００００００円）をプレミアム型の残高としてユーザ端末３０に表示させる。表示制御部１１１は、ユーザの口座残高と、基本型の残高と、の合計をユーザ端末３０に表示させてもよい。変形例１０では、表示制御部１１１が電子マネーサーバ１０において実現されるので、表示制御部１１１は、残高情報を表示させるためのデータをユーザ端末３０に送信することによって、残高情報をユーザ端末３０に表示させる。

変形例１０の残高連携システムＳは、口座残高に基づいて、電子マネーのユーザのユーザ端末に、電子マネー残高に関する残高情報を表示させる。これにより、連携中のプレミアム型の残高をどの程度利用できるかをユーザが容易に把握できるようになる。

［３－１１．変形例１１］
例えば、変形例１０のように残高情報を表示させる場合に、残高連携システムＳは、残高情報として表示させる額の上限を設定する上限設定部１１２を更に含んでもよい。ユーザにより指定された上限は、決済データベースＤＢ１に格納されるものとする。表示制御部１１１は、上限の範囲内で、ユーザ端末に残高情報を表示させる。例えば、図３のように、口座残高が１２０３５００円だったとして、ユーザが上限として１００００円を指定したとする。この場合、表示制御部１１１は、プレミアム型の残高として利用可能な資金が１２０３５００円存在するにもかかわらず、プレミアム型の残高として１００００円をユーザ端末３０に表示される。他にも例えば、表示制御部１１１は、「残高１００００円以上」といったように、口座残高の詳細を他人に知られないようにして、かつ、１００００円以上の残高が利用可能なことをユーザに通知するように、プレミアム型の残高を表示させてもよい。

変形例１１の残高連携システムＳは、残高情報として表示させる額の上限を設定し、上限の範囲内で、ユーザ端末に残高情報を表示させる。これにより、口座残高のようなプライベートな情報が他人に知られることを防止できる。

［３－１２．変形例１２］
例えば、第１実施形態及び第２実施形態で説明した電子マネーは、口座残高と連携可能なプレミアム型の残高と、基本型の残高と、を有する。基本型の残高は、プレミアム型の残高とは異なる他の残高の一例である。口座残高減少部１０６は、減少要求が受け付けられた場合に、所定の上限の範囲内で、口座残高を減少させてもよい。上限を超える額の減少要求が受け付けられた場合には、上限を超える分については、他の電子マネー残高が減少してもよい。

例えば、上限を１００００円として、ユーザが店舗で１３０００円分の支払操作をしたとする。この場合、上限の１００００円分は、第１実施形態又は第２実施形態と同様にして決済処理が実行される。残りの３０００円分については、基本型の残高から支払が行われるようにしてもよい。基本型の残高を利用した支払自体は、公知の処理を利用すればよい。上限は、ユーザにより指定されてもよいし、予め定められた固定値であってもよい。

変形例１２の残高連携システムＳは、減少要求が受け付けられた場合に、所定の上限の範囲内で、口座残高を減少させ、上限を超える額の減少要求が受け付けられた場合には、上限を超える分については、基本型の残高が減少する。これにより、残高連携させる上限額を設定できるので、ユーザの利便性が高まる。

［３－１３．その他変形例］
例えば、上記説明した変形例を組み合わせてもよい。

例えば、残高連携する口座の一例として銀行の口座を説明したが、銀行以外の金融機関の口座と、電子マネーと、が連携してもよい。他にも例えば、証券会社の口座と、電子マネーと、が連携してもよい。例えば、ユーザが決済アプリから決済サービスを利用する場合を説明したが、決済サービスを提供する媒体は、任意の媒体であってよく、決済アプリに限られない。例えば、ユーザ端末３０のブラウザ、ユーザ端末３０のＩＣチップ、又はユーザが所有するＩＣカードを利用して決済サービスが提供されてもよい。

例えば、残高連携システムＳは、電子マネーサーバ１０だけを含んでもよい。この場合、銀行サーバ２０及びユーザ端末３０は、残高連携システムＳの外部に存在してもよい。例えば、残高連携システムＳは、銀行サーバ２０だけを含んでもよい。この場合、電子マネーサーバ１０及びユーザ端末３０は、残高連携システムＳの外部に存在してもよい。例えば、電子マネーサーバ１０で実現されるものとして説明した機能は、銀行サーバ２０又は他のサーバコンピュータで実現されてもよい。銀行サーバ２０で実現されるものとして説明した機能は、電子マネーサーバ１０又は他のサーバコンピュータで実現されてもよい。例えば、電子マネーサーバ１０又は銀行サーバ２０で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。各機能は、少なくとも１つのコンピュータで実現されるようにすればよい。

Ｓ残高連携システム、Ｎネットワーク、１０電子マネーサーバ、１１，２１，３１制御部、１２，２２，３２記憶部、１３，２３，３３通信部、２０銀行サーバ、３０ユーザ端末、３４操作部、３５表示部、Ｇ１トップ画面、Ｇ２認証画面、Ｇ３完了画面、１００データ記憶部、１０１増加要求受付部、１０２電子マネー残高増加部、１０３口座残高増加部、１０４減少要求受付部、１０５電子マネー残高減少部、１０６口座残高減少部、１０７同期部、１０８第１制限部、１０９指定受付部、１１０手数料発生部、１１１表示制御部、１１２上限設定部、２００データ記憶部、２０１口座残高増加部、２０２口座残高減少部、２０３同期部、２０４第２制限部、２０５増加要求受付部、２０６関連付け部、２０７口座残高移動部、３００データ記憶部、３０１表示制御部、３０２操作受付部、Ｂ１１，Ｂ１４，Ｂ１５，Ｂ１６，Ｂ１７，Ｂ２１ボタン、Ｃ１０コード、ＤＢ１決済データベース、ＤＢ２口座データベース、ＤＢ３個別残高データベース、Ｆ２０入力フォーム、Ｍ１３メニュー。

Claims

決済サービスの決済サーバで管理される０円で固定された精算用の決済手段残高と、前記決済サーバで管理される連携用の決済手段残高と、を有する決済手段の増加要求を受け付ける増加要求受付部と、
前記増加要求が受け付けられた場合に、前記精算用の決済手段残高は０円のまま増加させずに、前記連携用の決済手段残高を増加させる決済手段残高増加部と、
前記決済手段の減少要求を受け付ける減少要求受付部と、
前記減少要求が受け付けられた場合に、前記精算用の決済手段残高は０円のまま減少させずに、前記連携用の決済手段残高を減少させる決済手段残高減少部と、
前記増加要求が受け付けられた場合に、前記決済手段残高増加部により増加した前記連携用の決済手段残高を、前記決済手段と連携する口座の残高であって金融機関サービスの金融機関サーバで管理される口座残高に同期させることによって、前記口座残高を増加させ、前記減少要求が受け付けられた場合に、前記決済手段残高減少部により減少した前記連携用の決済手段残高を、前記口座残高に同期させることによって、前記口座残高を減少させる同期部と、
を含む残高連携システム。
前記同期部は、所定の同期条件が満たされた場合に、前記連携用の決済手段残高及び前記口座残高を同期させ、
前記残高連携システムは、
前記同期条件が満たされても同期が行われなかった場合に、前記連携用の決済手段残高及び前記精算用の決済手段残高の利用を制限する第１制限部と、
前記同期条件が満たされても同期が行われなかった場合に、前記口座残高の利用を制限する第２制限部と、
の少なくとも一方を更に含む請求項１に記載の残高連携システム。
決済手段の残高である決済手段残高を増加させるための振込入金口座に対する振込要求を受け付ける振込要求受付部と、
前記振込要求が受け付けられた場合に、前記振込入金口座から、前記決済手段と連携し、複数のユーザに共通であり、前記複数のユーザの各々の前記振込入金口座が関連付けられた親口座に自動的に入金することによって、前記親口座の残高である口座残高を増加させる口座残高増加部と、
前記決済手段残高を減少させるための減少要求を受け付ける減少要求受付部と、
前記減少要求が受け付けられた場合に、前記口座残高を減少させる口座残高減少部と、
を含む残高連携システム。
前記口座残高増加部は、前記決済手段残高を増加させるための増加要求に応じた額を、前記決済手段から前記親口座に自動的に入金することによって、前記口座残高を増加させ、
前記口座残高減少部は、前記減少要求に応じた額を、前記親口座から前記決済手段に自動的にチャージすることによって、前記口座残高を減少させる、
請求項３に記載の残高連携システム。
前記親口座の前記口座残高は、前記複数のユーザに共通の共通残高であり、
前記親口座には、前記ユーザごとの個別残高が関連付けられており、
前記共通残高は、前記複数のユーザの各々の前記個別残高の合計であり、
前記口座残高増加部は、前記振込要求が受け付けられた場合に、前記共通残高及び前記個別残高を増加させ、
前記口座残高減少部は、前記減少要求が受け付けられた場合に、前記共通残高及び前記個別残高を減少させる、
請求項３又は４に記載の残高連携システム。
同じ前記親口座の前記ユーザ間で前記決済手段が送られる場合には、前記親口座の残高が変更されずに、前記決済手段を送る側のユーザの前記個別残高と、前記決済手段を受け取る側のユーザの前記個別残高と、が変更される、
請求項５に記載の残高連携システム。
前記減少要求受付部は、店舗で前記決済手段が利用される場合に、前記減少要求を受け付け、
前記店舗は、前記親口座とは別の店舗用親口座に関連付けられており、
前記親口座と、前記店舗用親口座と、は金融機関、支店、及び名義人が同じであり、
前記口座残高減少部は、前記減少要求が受け付けられた場合に、前記親口座から前記店舗用親口座への振替を行うことによって、前記口座残高を減少させる、
請求項５又は６の何れかに記載の残高連携システム。
前記振込入金口座は、仮想口座であり、
前記残高連携システムは、
前記ユーザが実口座を開設した場合に、当該ユーザの前記決済手段と、前記振込入金口座及び前記親口座と、の関連付けを解除し、かつ、当該ユーザの前記決済手段と、当該ユーザの前記実口座と、を関連付ける関連付け部を更に含み、
前記関連付け部による処理が実行された後は、前記実口座を開設した前記ユーザの決済手段と、前記振込入金口座及び前記親口座と、が連携する状態から、当該ユーザの決済手段と、当該ユーザの前記実口座と、が連携する状態に変わる、
請求項３～７の何れかに記載の残高連携システム。
前記残高連携システムは、前記親口座の前記口座残高のうち、前記実口座を開設した前記ユーザの分を、当該実口座に移動させる口座残高移動部を更に含む、
請求項８に記載の残高連携システム。
前記口座残高は、閾値を超えた分の前記決済手段残高と連携し、
前記口座残高は、前記閾値を超えた分に基づいて増加し、
前記口座残高は、前記閾値を超えた分に基づいて減少する、
請求項３～９の何れかに記載の残高連携システム。
前記残高連携システムは、前記決済手段のユーザによる、前記閾値に関する指定を受け付ける指定受付部を更に含む、
請求項１０に記載の残高連携システム。
前記残高連携システムは、前記残高連携システムにより前記口座残高が増加する場合には所定の手数料を発生させず、前記決済手段のユーザにより、前記決済手段残高からの出金が指示された場合に、前記手数料を発生させる手数料発生部を更に含む、
請求項３～１１の何れかに記載の残高連携システム。
前記決済手段残高は、０円で固定されており、
前記残高連携システムは、前記口座残高に基づいて、前記決済手段のユーザのユーザ端末に、前記決済手段残高に関する残高情報を表示させる表示制御部を更に含む、
請求項３～１２の何れかに記載の残高連携システム。
前記残高連携システムは、前記残高情報として表示させる額の上限を設定する上限設定部を更に含み、
前記表示制御部は、前記上限の範囲内で、前記ユーザ端末に前記残高情報を表示させる、
請求項１３に記載の残高連携システム。
前記決済手段は、前記口座残高と連携可能な前記決済手段残高と、他の決済手段残高と、を有し、
前記口座残高は、前記減少要求が受け付けられた場合に、所定の上限の範囲内で減少し、
前記上限を超える額の前記減少要求が受け付けられた場合には、前記上限を超える分については、前記他の決済手段残高が減少する、
請求項３～１４の何れかに記載の残高連携システム。
コンピュータが、
決済サービスの決済サーバで管理される０円で固定され精算用の決済手段残高と、前記決済サーバで管理される連携用の決済手段残高と、を有する決済手段の増加要求を受け付ける増加要求受付ステップと、
前記増加要求が受け付けられた場合に、前記精算用の決済手段残高は０円のまま増加させずに、前記連携用の決済手段残高を増加させる決済手段残高増加ステップと、
前記決済手段の減少要求を受け付ける減少要求受付ステップと、
前記減少要求が受け付けられた場合に、前記精算用の決済手段残高は０円のまま減少させずに、前記連携用の決済手段残高を減少させる決済手段残高減少ステップと、
前記増加要求が受け付けられた場合に、前記決済手段残高増加ステップにより増加した前記連携用の決済手段残高を、前記決済手段と連携する口座の残高であって金融機関サービスの金融機関サーバで管理される口座残高に同期させることによって、前記口座残高を増加させ、前記減少要求が受け付けられた場合に、前記決済手段残高減少ステップにより減少した前記連携用の決済手段残高を、前記口座残高に同期させることによって、前記口座残高を減少させる同期ステップと、
を実行する残高連携方法。
コンピュータが、
決済手段の残高である決済手段残高を増加させるための振込入金口座に対する振込要求を受け付ける振込要求受付ステップと、
前記振込要求が受け付けられた場合に、前記振込入金口座から、前記決済手段と連携し、複数のユーザに共通であり、前記複数のユーザの各々の前記振込入金口座が関連付けられた親口座に自動的に入金することによって、前記親口座の残高である口座残高を増加させる口座残高増加ステップと、
前記決済手段残高を減少させるための減少要求を受け付ける減少要求受付ステップと、
前記減少要求が受け付けられた場合に、前記口座残高を減少させる口座残高減少ステップと、
を実行する残高連携方法。
決済サービスの決済サーバで管理される０円で固定され精算用の決済手段残高と、前記決済サーバで管理される連携用の決済手段残高と、を有する決済手段の増加要求を受け付ける増加要求受付部、
前記増加要求が受け付けられた場合に、前記精算用の決済手段残高は０円のまま増加させずに、前記連携用の決済手段残高を増加させる決済手段残高増加部、
前記決済手段の減少要求を受け付ける減少要求受付部、
前記減少要求が受け付けられた場合に、前記精算用の決済手段残高は０円のまま減少させずに、前記連携用の決済手段残高を減少させる決済手段残高減少部、
前記増加要求が受け付けられた場合に、前記決済手段残高増加部により増加した前記連携用の決済手段残高を、前記決済手段と連携する口座の残高であって金融機関サービスの金融機関サーバで管理される口座残高に同期させることによって、前記口座残高を増加させ、前記減少要求が受け付けられた場合に、前記決済手段残高減少部により減少した前記連携用の決済手段残高を、前記口座残高に同期させることによって、前記口座残高を減少させる同期部、
としてコンピュータを機能させるためのプログラム。
決済手段の残高である決済手段残高を増加させるための振込入金口座に対する振込要求を受け付ける振込要求受付部、
前記振込要求が受け付けられた場合に、前記振込入金口座から、前記決済手段と連携し、複数のユーザに共通であり、前記複数のユーザの各々の前記振込入金口座が関連付けられた親口座に自動的に入金することによって、前記親口座の残高である口座残高を増加させる口座残高増加部、
前記決済手段残高を減少させるための減少要求を受け付ける減少要求受付部、
前記減少要求が受け付けられた場合に、前記口座残高を減少させる口座残高減少部、
としてコンピュータを機能させるためのプログラム。