以下に、本願にかかる口座管理システム、口座管理方法および口座管理プログラムを実施するための形態(以下、「実施形態」と呼ぶ)について図面を参照しつつ説明する。なお、この実施形態により本願にかかる口座管理システム、口座管理方法および口座管理プログラムが限定されるものではない。また、以下の実施形態において、同一の部位には同一の符号を付し、重複する説明は省略される。
〔1.蓄積処理〕
まず、図1を用いて、実施形態にかかる蓄積処理であって貯蓄対象金額を蓄積する蓄積処理の一例について説明する。図1は、実施形態にかかる蓄積処理の一例を示す図である。実施形態にかかる蓄積処理は、図1に示す口座管理システム100によって行われる。
まず、図1に示すシステム構成について説明する。図1に示す全ての装置を含む全体システム1について説明する。全体システム1は、端末装置10と、カード会社サーバ301と、銀行サーバ302と、管理サーバ200と、電子マネーサーバ300とを含む。端末装置10、カード会社サーバ301、銀行サーバ302、管理サーバ200、電子マネーサーバ300は、ネットワークを介して有線または無線により通信可能に接続される。なお、図1に示す全体システム1には、複数台の端末装置10や、複数台のカード会社サーバ301や、複数台の銀行サーバ302や、複数台の管理サーバ200や、複数台の電子マネーサーバ300が含まれてもよい。
また、図1に示すように、全体システム1に含まれる管理サーバ200と、電子マネーサーバ300とから構成されるシステムを口座管理システム100とする。実施形態にかかる蓄積処理は、この口座管理システム100によって行われる。また、管理サーバ200と、電子マネーサーバ300とは、管理会社T(以下、単に「会社T」と表記する)によって管理されるものとする。
ここで、実施形態にかかる蓄積処理は、管理サーバ200の機能と、電子マネーサーバ300の機能とを有する一台の装置によって行われてもよい。かかる場合、口座管理システム100は、例えば、口座管理装置100と見なすことができる。
次に、全体システム1および口座管理システム100に含まれる各装置について説明する。端末装置10は、ユーザによって利用される端末装置であり、例えば、スマートフォンや、タブレット型端末や、ノート型PC(Personal Computer)や、デスクトップPCや、携帯電話機や、PDA(Personal Digital Assistant)等である。例えば、端末装置10は、管理サーバ200から受け付けた情報を表示画面Dに表示する。また、端末装置10は、ユーザ操作に従って、所定の情報を電子マネーサーバ300に送信する。
カード会社サーバ301は、クレジットカード管理および運営を行っている各カード会社に属するサーバ装置である。例えば、カード会社サーバ301は、対応するクレジットカードの利用履歴(利用明細)として、カード利用による支払金額、支払対象(購入商品等)、支払先(商品が購入された店舗等)を、ユーザ毎に取引年月日に対応付けて記憶している。また、カード会社サーバ301は、例えば、ログインIDおよびクレジットカード暗証番号を用いてアクセスしてきたユーザに対して、当該ユーザの利用明細を提示する。なお、図1では、一台のカード会社サーバ301を例示しているが、実際には、カード会社サーバ301は、例えば、カード会社毎に存在する。
銀行サーバ302は、銀行に属するサーバ装置である。例えば、銀行サーバ302は、銀行窓口やATMを利用した入出金である利用履歴や現在の口座情報(例えば、口座残高)を、ユーザ毎に取引年月日に対応付けて記憶している。なお、図1では、一台の銀行サーバ302を例示しているが、実際には、銀行サーバ302は、例えば、銀行毎に存在する。
ここで、実施形態にかかる口座管理システム100は、例えば、ユーザの日々の生活費ではなく、生活費以外に余った資金、すなわちユーザが自由に使うことのできる資金である「余剰金」をうまく貯蓄させることで、ユーザが資産をより増やすことができるように蓄積処理を行うものである。このような余剰金を貯蓄に回すのであれば、ユーザが生活費を圧迫させられることが無いため、ユーザの貯蓄意欲が高まると考えられる。したがって、口座管理システム100は、ユーザの余剰金に着目した蓄積処理を行う。
具体的には、管理サーバ200は、貯蓄処理の対象となるユーザ(対象ユーザ)について、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得し、過去口座情報と現在口座情報とを比較する。そして、管理サーバ200は、比較によって得られた比較結果が所定の条件を満たす場合に、過去口座情報と現在口座情報とに基づく金額を貯金するよう対象ユーザに提案する。
そして、電子マネーサーバ300は、提案に対する対象ユーザの承諾が得られた場合に、過去口座情報と現在口座情報とに基づく金額を対象ユーザの口座に蓄積する、すなわち対象ユーザの口座に貯蓄する。例えば、電子マネーサーバ300は、対象ユーザの銀行口座から、過去口座情報と現在口座情報とに基づく金額分の資金を抽出し、その資金を電子マネーとして自装置内の電子マネー口座に蓄積する。
さて、ここからは、口座管理システム100による蓄積処理について具体的に説明する。まず、会社Tは、ユーザに対して有料サービス、有料コンテンツ、ショッピングサービス等を提供している。このため、会社Tは、支払いや報酬の受け取りを簡便にするために、これらのコンテンツを利用しようとするユーザから事前に、クレジットカードや銀行口座に関する情報の登録を受け付けている。このようなことから、管理サーバ200は、例えば、ユーザのクレジットカードや銀行口座に関する情報を適宜取得することができる。
例えば、管理サーバ200が、ユーザからクレジットカードや銀行口座に関する情報の登録を受け付けてもよいし、会社Tの他のサーバ装置に登録されたものを取得してもよい。また、このようなことから、管理サーバ200は、クレジットカードや銀行口座に関する情報を登録している各ユーザについて、クレジットカードに対応するサーバ装置や、銀行に対応するサーバ装置を特定することができる。
以下、ユーザU1を例に挙げて説明する。なお、ユーザU1以外の他のユーザについても同様の処理が行われる。まず、図1では、管理サーバ200は、ユーザU1が有するクレジットカードに対応するサーバ装置がカード会社サーバ301であり、ユーザU1が利用している銀行に対応するサーバ装置が銀行サーバ302であることを特定している例を示す。
このような状態において、管理サーバ200は、カード会社サーバ301および銀行サーバ302から、ユーザの入金および出金に関する入出金データを取得する(ステップS1)。入金データとは、例えば、ユーザの銀行口座に振り込まれた金額、すなわち預入金額に関する情報を示す。出金データとは、例えば、引き出しやカード利用によりユーザの銀行口座に貯蓄されている資金から支払われた支払金額に関する情報を示す。
例えば、管理サーバ200は、カード会社サーバ301からユーザU1のカード利用に関する履歴情報を出金データとして取得する。例えば、管理サーバ200は、定期的にカード会社サーバ301にアクセスし、カードが利用された年月日である取引年月日、カード利用による支払金額、何に対してカード利用されたかを示す概要情報を含む履歴情報を出金データとして取得する。そして、管理サーバ200は、出金データを入出金情報記憶部222に格納する。
また、管理サーバ200は、銀行サーバ302からユーザU1の銀行利用による入出金に関する履歴情報を入出金データとして取得する。例えば、管理サーバ200は、定期的に銀行サーバ302にアクセスし、銀行利用により入出金が行われた年月日である取引年月日、銀行口座に振り込まれた預入金額、銀行利用により支払った支払金額、銀行利用による預入および支払に関する概要情報を含む履歴情報を入出金データとして取得する。そして、管理サーバ200は、入出金データを入出金情報記憶部222に格納する。
図1に示すように、管理サーバ200は、入出金情報記憶部222を有する。入出金情報記憶部222は、管理サーバ200によって取得された入出金データを記憶する記憶部である。図1の例では、入出金情報記憶部222は、「ユーザID」、「取引年月日」、「預入金額」、「支払金額」、「概要」、「残高」といった項目を有する。
例えば、入出金情報記憶部222は、ユーザID「U1」に、取引年月日「28−09−24」、預入金額「250,000円」、概要「給与、S株式会社」、残高「750,000円」を対応付けて記憶している。これは、「平成28年9月24日」においてユーザU1の口座に「250,000円」が振り込まれたことにより、この時点での口座残高が「750,000円」となった例を示す。また、振り込まれた「250,000円」の概要は「S株式会社からの給与振込」である例を示す。
また、入出金情報記憶部222は、ユーザID「U1」に、取引年月日「28−09−25」、支払金額「15,000円」、概要「カード、公共料金」、残高「735,000円」を対応付けて記憶している。これは、「平成28年9月25日」においてユーザU1の口座から「15,000円」が引き落とされたことにより、この時点での口座残高が「735,000円」となった例を示す。また、引き落とされた「15,000円」の概要は「カード利用による公共料金支払」である例を示す。
ここで、実施形態にかかる口座管理システム100は、毎月23日に蓄積処理を行うものとする。例えば、口座管理システム100は、現在が「11月23日」であるか否かを判定し、「11月23日」であることを特定したとする。かかる場合、管理サーバ200は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを比較する(ステップS2)。蓄積処理に含まれる比較処理について具体的に説明する。
管理サーバ200は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。例えば、管理サーバ200は、過去口座情報として現在月より過去のいずれかの月の口座残高と、現在口座情報として現在月の口座残高とを入出金情報記憶部222から取得する。本実施形態では、現在月より過去のいずれかの月は、現在月より1ヵ月前の月であるもとする。
したがって、管理サーバ200は、図1の例では、ユーザU1の過去口座情報として「平成28年10月23日」時点(先月)における口座残高「755,000円」を取得する。図1の例では、「平成28年10月24日」時点における口座残高が「1,005,000円」であるため、「平成28年10月23日」時点における口座残高は「755,000円」である。また、図1の例では、管理サーバ200は、ユーザU1の現在口座情報として「平成28年11月23日」時点(現在月)における口座残高「758,000円」を取得する。
次に、管理サーバ200は、過去口座情報である先月の口座残高「755,000円」と、現在口座情報である現在月の口座残高「758,000円」とを比較し、比較結果が所定の条件を満たすか否かを判定する。ここで、所定の条件は、「現在月の口座残高が先月の口座残高より多いこと」であるものとする。かかる場合、管理サーバ200は、現在月の口座残高「758,000円」が、先月の口座残高「755,000円」より多いことから、比較結果が所定の条件「現在月の口座残高が先月の口座残高より多いこと」を満たすと判定する。
このように、比較処理により比較結果が所定の条件を満たすと判定すると、管理サーバ200は、現在月の口座残高と先月の口座残高との差額である「3,000円」を貯金するよう提案する提案情報をユーザU1に通知する(ステップS3)。より具体的には、管理サーバ200は、上記のような提案情報を含むコンテンツCであって当該提案情報に承諾することをユーザから受け付け可能なコンテンツCを、ユーザU1の操作に拘わらず通知する(プッシュ通知)。
そして、端末装置10は、管理サーバ200から受信したコンテンツCを表示画面Dに表示する。図1では、表示画面Dに表示されたコンテンツCの一例を示す。コンテンツCには、「11月24日は給料日です。残高(3,000円)を貯金しませんか?」といった提案情報が含まれる。ここで、表示される残高「3,000円」は、比較処理で算出された差額「3,000円」である。つまり、管理サーバ200は、現在のユーザU1の口座残高全額「758,000円」のうちの一部の残高であって、現在月の口座残高と先月の口座残高との差額に相当する残高「3,000円」を貯金するよう提案する。
また、コンテンツCには、「貯金する」が表示されたボタンBが含まれる。電子マネーサーバ300は、ボタンBが押下された場合に、提案情報に承諾することをユーザから受け付ける。例えば、ユーザU1は、「3,000円」の貯金に承諾する場合には、ボタンBを押下する。これにより、ユーザU1は、ワンタッチで貯金を行うことができる。例えば、端末装置10がスマートフォンでる場合には、ユーザU1は、ワンタップで貯金を行うことができる。また、端末装置10がPCである場合には、ユーザU1は、ワンクリックで貯金を行うことができる。
ここで、ユーザU1によってボタンBが押下されたとする。つまり、ユーザU1が「3,000円」を貯金することに承諾したとする。かかる場合、端末装置10は、貯蓄に承諾する旨の情報として、ユーザIDと貯蓄対象金額「3,000円」を含む承諾情報を電子マネーサーバ300に送信する(ステップS4)。
電子マネーサーバ300は、承諾情報を受信すると、承諾情報に含まれるユーザIDからユーザU1の利用している銀行に対応するサーバ装置を特定する。図1の例では、電子マネーサーバ300は、このサーバ装置が銀行サーバ302であることを特定する。
そして、電子マネーサーバ300は、銀行サーバ302のユーザU1の口座から貯蓄対象金額「3,000円」分の資金を取得し、取得した「3,000円」を蓄積情報記憶部321に蓄積する(ステップS5)。例えば、電子マネーサーバ300は、取得した「3,000円」を電子マネーに変換し、蓄積情報記憶部321に蓄積する。
図1の例では、蓄積情報記憶部321は、「ユーザID」、「貯蓄日」、「貯蓄額」、「合計貯蓄額」といった項目を有する。このため、電子マネーサーバ300は、ユーザID「U1」に、貯蓄日「平成28年11月23日」、貯蓄額「3,000円」、合計貯蓄額「5,000円」を記憶する。また、このようなことから蓄積情報記憶部321は、電子マネー口座に相当する。
以上、蓄積処理について説明してきた。上記の通り、口座管理システム100は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。そして、口座管理システム100は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす場合に、過去口座情報と、現在口座情報とに基づく金額を所定の口座へ蓄積する。
図1の例では、口座管理システム100は、現在月の口座残高が先月の口座残高より多い場合に、現在月の口座残高と先月の口座残高との差額を貯金しないか提案する。例えば、口座管理システム100は、一般的な給料日が毎月24日であるとすると、その前日に提案を行う。そして、ユーザの承諾が得られた場合に、口座管理システム100は、その残高をユーザの口座(電子マネー口座)に蓄積する。
ここで、現在月の口座残高が先月の口座残高より多い場合、現在月の口座残高と先月の口座残高との差額は、ユーザにとって自由に使うことのできる資金と考えられる。実施形態にかかる口座管理システム100は、このような差額を貯金するよう提案することにより、ユーザに対して無理なく効率的に貯蓄させることができる。また、図1で説明したように、給料日を毎月24日とすると、口座管理システム100は、その前日に提案も含めた一連の蓄積処理を行うため、例えば、残高を貯金に回しても翌日には給料が支給されるといった安心感からより効果的に貯蓄させることができる。
さて、図1では図示しないが、口座管理システム100は、蓄積情報記憶部321に蓄積された貯蓄額(合計貯蓄額)が所定額を超えたユーザに対して、所定の金融商品、例えば、投資信託を提案してもよい。蓄積情報記憶部321に蓄積された資金は、ユーザが比較的自由に使うことのできるお金が蓄積されたものであるため、ユーザは気軽に投資信託により資金を増やすことができる。
〔2.システムの構成〕
次に、図2を用いて、実施形態にかかる全体システム1の構成について説明する。図2は、実施形態にかかる全体システム1の構成例を示す図である。図2に示すように、全体システム1には、端末装置10と、カード会社サーバ301と、銀行サーバ302と、管理サーバ200と、電子マネーサーバ300とが含まれる。端末装置10と、カード会社サーバ301と、銀行サーバ302と、管理サーバ200と、電子マネーサーバ300とは、ネットワークNを介して、有線または無線により通信可能に接続される。
なお、図2に示した全体システム1には、複数台の端末装置10、複数台のカード会社サーバ301、複数台の銀行サーバ302、複数台の管理サーバ200、複数台の電子マネーサーバ300が含まれてよい。例えば、カード会社サーバ301は、カード会社毎に存在する。また、銀行サーバ302は、銀行毎に存在する。なお、以下の実施形態では、カード会社サーバ301、および、銀行サーバ302を区別する必要が無い場合には、これらを総称して「金融機関サーバ30」と表記することにする。
また、全体システム1に含まれる口座管理システム100は、管理サーバ200と、電子マネーサーバ300とを含む。しかしながら、管理サーバ200と、電子マネーサーバ300を統合して一台の装置として構成されてもよい。
〔3.管理サーバの構成〕
次に、図3を用いて、実施形態にかかる管理サーバ200について説明する。図3は、実施形態にかかる管理サーバ200の構成例を示す図である。図3に示すように、管理サーバ200は、通信部210と、記憶部220と、制御部230とを有する。
(通信部210について)
通信部210は、例えば、NIC(Network Interface Card)等によって実現される。そして、通信部210は、ネットワークNと有線または無線で接続され、例えば、端末装置10、金融機関サーバ30、電子マネーサーバ300との間で情報の送受信を行う。
(記憶部220について)
記憶部220は、例えば、RAM(Random Access Memory)、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部220は、ユーザ情報記憶部221と、入出金情報記憶部222とを有する。
(ユーザ情報記憶部221について)
ユーザ情報記憶部221は、ユーザに関する各種情報を記憶する記憶部である。図1で説明したように、会社Tは、コンテンツを利用しようとするユーザから事前に、クレジットカードや銀行口座に関する情報の登録を受け付けている。例えば、ユーザ情報記憶部221は、このとき、クレジットカードや銀行口座に関する情報とともに受け付けられたユーザに関する各種情報を記憶する。
ここで、図4に実施形態にかかるユーザ情報記憶部221の一例を示す。図4の例では、ユーザ情報記憶部121は、「ユーザID」、「住所」、「氏名」、「年齢」、「性別」、「年収」、「家族構成」といった項目を有する。
「ユーザID」は、ユーザまたはユーザの端末装置10を識別するための識別情報を示す。「住所」は、対応するユーザの居住地を示す。「氏名」は、対応するユーザの氏名を示す。「年齢」は、対応するユーザの年齢を示す。「性別」は、対応するユーザの性別を示す。「年収」は、対応するユーザの年収を示す。「家族構成」は、対応するユーザの家族構成を示す。
すなわち、図4の例では、ユーザID「U1」によって識別されるユーザは、住所「ADD1」、氏名「NA1」、年齢「40歳」、性別「男」、年収「550万」、家族構成「妻と子1人」である例を示す。
なお、図示しないが、ユーザ情報記憶部221は、クレジットカードや銀行口座に関する情報も記憶してよい。また、管理サーバ200は、必ずしもユーザ情報記憶部221を有する必要はない。例えば、ユーザに関する各種情報や、クレジットカードおよび銀行口座に関する情報が、管理サーバ200以外の所定のサーバ装置によって管理されている場合には、管理サーバ200は、適宜、所定のサーバ装置にアクセスし、必要な情報を参照するだけでもよい。
(入出金情報記憶部222について)
入出金情報記憶部222は、ユーザによる入出金に関する情報を記憶する記憶部である。例えば、入出金情報記憶部222は、カード利用による支払いの履歴情報を出金データとして記憶する。また、入出金情報記憶部222は、銀行利用による収支の履歴情報を入金および出金データとして記憶する。例えば、入出金情報記憶部222は、銀行口座に振り込まれた金額、すなわち預入金額に関する履歴情報を入金データとして記憶する。また、入出金情報記憶部222は、銀行利用により残高から支払われた支払金額に関する履歴情報を出金データとして記憶する。
ここで、図5に実施形態にかかる入出金情報記憶部222の一例を示す。図5の例では、入出金情報記憶部122は「ユーザID」、「取引年月日」、「預入金額」、「支払金額」、「概要」、「残高」といった項目を有する。なお、図5に示す入出金情報記憶部122は、図1に示したものに対応する。
「ユーザID」は、ユーザまたはユーザの端末装置10を識別するための識別情報を示す。「取引年月日」は、カード利用または銀行利用により金融取引(例えば、自口座への入金や、自口座からの支払い等)が行われた年月日を示す。「預入金額」は、ユーザの銀行口座に入金された金額を示す。「支払金額」は、ユーザの銀行口座から支払われた金額を示す。例えば、「支払金額」は、銀行窓口やATM利用によりユーザの銀行口座から直接的に支払われた(他の銀行口座への送金等も含む)金額や、カード利用によりユーザの銀行口座から間接的に支払われた金額を示す。
「概要」は、対応する「預入金額」および「支払金額」がどのような内容であるかを簡潔に説明する説明文を示す。「残高」は、対応する「取引年月日」の時点において口座に残されている金額を示す。
例えば、入出金情報記憶部222は、ユーザID「U1」に、取引年月日「28−09−24」、預入金額「250,000円」、概要「給与、S株式会社」、残高「750,000円」を対応付けて記憶している。これは、「平成28年9月24日」においてユーザU1の口座に「250,000円」が振り込まれたことにより、この時点での口座残高が「750,000円」となった例を示す。また、振り込まれた「250,000円」の概要は「S株式会社からの給与振込」である例を示す。
また、入出金情報記憶部222は、ユーザID「U1」に、取引年月日「28−09−25」、支払金額「15,000円」、概要「カード、公共料金」、残高「735,000円」を対応付けて記憶している。これは、「平成28年9月25日」においてユーザU1の口座から「15,000円」が引き落とされたことにより、この時点での口座残高が「735,000円」となった例を示す。また、引き落とされた「15,000円」の概要は「カード利用による公共料金支払」である例を示す。
図3に戻り、制御部230は、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、管理サーバ200内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部230は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
図3に示すように、制御部230は、取得部231と、判定部232と、比較部233と、通知部234とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部230の内部構成は、図3に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部230が有する各処理部の接続関係は、図3に示した接続関係に限られず、他の接続関係であってもよい。
(取得部231について)
取得部231は、金融機関サーバ30から入金および出金に関する入出金データを取得する。例えば、取得部231は、金融機関サーバ30に定期的にアクセスし、入出金データを取得する。この点について一例を示す。
例えば、取得部231は、ユーザ情報記憶部221を参照し、ユーザ情報記憶部221に登録されているユーザ、すなわち蓄積処理の対象となるユーザ(対象ユーザ)が利用しているクレジットカードや銀行を特定する。また、取得部231は、特定したクレジットカードに対応する金融機関サーバ30を特定する。また、取得部231は、特定した銀行に対応する金融機関サーバ30を特定する。図1では、取得部231が、対象ユーザのうちユーザU1の利用するクレジットカードに対応する金融機関サーバ30がカード会社サーバ301であることを特定した例を示す。また、取得部231が、ユーザU1の利用する銀行に対応する金融機関サーバ30が銀行サーバ302であることを特定した例を示す。
このように取得部231は、対象ユーザに対応する金融機関を特定したうえで、特定した金融機関サーバ30に定期的にアクセスする。そして、取得部231は、金融機関サーバ30から入出金データを取得し、取得した入出金データを入出金情報記憶部222に格納する。
また、取得部231は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。例えば、取得部231は、後述する判定部232により蓄積処理を行うタイミングであると判定された場合に、各対象ユーザの過去口座情報と現在口座情報とを入出金情報記憶部222から取得する。
(判定部232について)
判定部232は、処理を行うタイミングであるか否かを判定する。具体的には、判定部232は、対象ユーザへの提案情報の通知を含めた一連の蓄積処理を開始するタイミングであるか否かを判定する。
例えば、所定の期日において、過去口座情報と現在口座情報とを比較し、比較結果が所定の条件を満たす場合に、その所定の期日に提案情報をユーザに通知するよう予め設定されているとする。ここで、所定の期日とは、毎月の所定の期日であるものとする。より具体的には、毎月の所定の期日とは、定期的な入金が行われる日の前日であるものとする。例えば、定期的な入金が行われる日を給料が支給される日(毎月24日)とすると、判定部232は、現在がその前日の23日であるか否かを判定する。そして、判定部232は、23日であると判定した場合に、取得部231に対して蓄積処理を開始するよう指示する。具体的には、判定部232は、過去口座情報と現在口座情報とを取得するよう指示する。
また、毎月の所定の期日とは、定期的な出金が行われた後の日であるものとする。例えば、定期的な出金が行われる日を公共料金請求日とすると、判定部232は、現在が公共料金請求日の翌日であるか否かを判定する。そして、判定部232は、翌日であると判定した場合に、取得部231に対して蓄積処理を開始するよう指示する。具体的には、判定部232は、過去口座情報と現在口座情報とを取得するよう指示する。
(比較部233について)
比較部233は、取得部231により過去口座情報と現在口座情報とが取得された場合に、過去口座情報と現在口座情報とを比較する比較処理を行う。例えば、比較部233は、対象ユーザそれぞれについて、過去口座情報と現在口座情報とを比較し、比較結果が所定の条件を満たすか否かを判定するといった比較処理を行う。なお、本実施形態では、比較対象として、過去口座情報と現在口座情報とをいずれに設定するかによって処理を複数のパターンに分類することができる。後ほどパターン毎の蓄積処理について詳しく説明する。
(通知部234について)
通知部234は、比較部233によって比較結果が所定の条件を満たすと判定された場合に、過去口座情報と現在口座情報とに基づく金額を貯金するよう提案する提案情報を対象ユーザに通知する。例えば、通知部234は、提案情報を含むコンテンツであって当該提案情報に承諾することを対象ユーザから受け付け可能なコンテンツを、対象ユーザの操作に拘わらず対象ユーザに通知する。
このようなコンテンツの一例として、図1ではコンテンツCを例示した。つまり、通知部234は、ユーザが提案情報に承諾した場合、ワンタッチで貯金させることができるようなボタン(図1の例では、ボタンB)と、過去口座情報と現在口座情報とに基づく金額(図1の例では、3,000円)を貯金するよう提案する提案情報とを含むコンテンツを、対象ユーザの端末装置10にプッシュ通知する。
さて、以下では、比較対象毎にパターン分けし、各パターンでの蓄積処理について説明する。第1のパターンは、過去口座情報を現在月より過去のいずれかの月の口座残高とし、現在口座情報を現在月の口座残高とした場合における処理である。第2のパターンは、過去口座情報を現在月より過去のいずれかの月の収入額とし、現在口座情報を現在月の収入額とした場合における処理である。第3のパターンは、過去口座情報を現在月より過去のいずれかの月の公共料金請求額とし、現在口座情報を現在月の公共料金請求額とした場合における処理である。
(第1のパターン)
まず、第1のパターンについて説明する。第1のパターンは、図1で説明した例をより詳細に説明するものである。第1のパターンでは、取得部231は、過去口座情報として過去のいずれかの時点における口座残高と、現在口座情報として現時点における口座残高を取得する。そして、比較部233は、過去のいずれかの時点における口座残高と、現時点における口座残高とを比較し、比較結果が所定の条件を満たすか否かを判定する。また、通知部234は、過去のいずれかの時点における口座残高と、現時点における口座残高との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における口座残高と、現時点における口座残高とに基づく金額を貯金するよう提案する提案情報を通知する。そして、提案情報にユーザが承諾した場合に、後述する蓄積部332は、この金額を蓄積する。この点について一例を示す。
例えば、取得部231は、過去口座情報として現在月より過去のいずれかの月の口座残高と、現在口座情報として現在月の口座残高とを取得する。そして、比較部233は、現在月より過去のいずれかの月の口座残高と、現在月の口座残高とを比較し、比較結果が所定の条件を満たすか否かを判定する。例えば、比較部233は、現在月より過去のいずれかの月の口座残高と、現在月の口座残高とを比較し、「現在月の口座残高が現在月より過去のいずれかの月の口座残高より多いこと」といった所定の条件を満たすか否かを判定する。
そして、比較部233は、所定の条件を満たすと判定すると、現在月より過去のいずれかの月の口座残高と、現在月の口座残高とに基づく金額を算出する。例えば、比較部233は、現在月の口座残高と現在月より過去のいずれかの月の口座残高との差額を算出し、算出した差額を通知部234に出力する。
通知部234は、所定の条件を満たすと判定されたことにより現在月の口座残高と現在月より過去のいずれかの月の口座残高との差額を受信すると、その差額を貯金するよう提案する提案情報を対象ユーザに通知する。
このような第1のパターンの処理について、図1の例を用いて説明する。なお、本実施形態では、過去のいずれかの月を現在月に対する1ヶ月前の月(先月)であるものとする。また、現在月は、11月であるものとする。また、対象ユーザをユーザU1とする。
まず、判定部232は、提案情報の通知を含めた一連の蓄積処理を開始するタイミングとして、現在が定期的な入金が行われる日の前日であるか否かを判定するものとする。具体的には、判定部232は、現在日が給料が支給される日(毎月24日)の前日である23日であるか否かを判定する。例えば、判定部232は、現在日が11月23日であると判定すると、取得部231に対して取得を行うよう指示する。
取得部231は、判定部232からの指示を受信すると、ユーザU1の過去口座情報として「平成28年10月23日」時点(先月)における口座残高「755,000円」を取得する。また、取得部231は、ユーザU1の現在口座情報として「平成28年11月23日」時点(現在月)における口座残高「758,000円」を取得する。
次に、比較部233は、過去口座情報である先月の口座残高「755,000円」と、現在口座情報である現在月の口座残高「758,000円」とを比較し、所定の条件「現在月の口座残高が先月の口座残高より多いこと」を満たすか否かを判定する。かかる場合、比較部233は、比較結果が所定の条件を満たすと判定する。
このように、比較結果が所定の条件を満たすと判定すると、比較部233は、現在月の口座残高と先月の口座残高との差額「3,000円」を算出し、算出した差額「3,000円」を通知部234に出力する。
そして、通知部234は、差額「3,000円」を貯金するよう提案する提案情報をユーザU1に通知する。例えば、通知部234は、図1に示すように、「11月24日は給料日です。残高(3,000円)を貯金しませんか?」といった提案情報と、押下することにより貯金させることができるボタンBを含むコンテンツCを作成する。そして、通知部234は、作成したコンテンツCをユーザU1の端末装置10に配信する。
このように、実施形態にかかる口座管理システム100は、現在月の口座残高が先月の口座残高より多い場合に、現在月の口座残高と先月の口座残高との差額を貯金しないか提案する。これにより、口座管理システム100は、ユーザが自由に使うことができると考えられる余剰金を効果的に貯蓄させることができる。
(第2のパターン)
次に、第2のパターンについて説明する。第2のパターンでは、取得部231は、過去口座情報として過去のいずれかの時点における収入額と、現在口座情報として現時点における収入額を取得する。そして、比較部233は、過去のいずれかの時点における収入額と、現時点における収入額とを比較し、比較結果が所定の条件を満たすか否かを判定する。また、通知部234は、過去のいずれかの時点における収入額と、現時点における収入額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における収入額と、現時点における収入額とに基づく金額を貯金するよう提案する提案情報を通知する。そして、提案情報にユーザが承諾した場合に、後述する蓄積部332は、この金額を蓄積する。この点について一例を示す。
例えば、取得部231は、過去口座情報として現在月より過去のいずれかの月の収入額と、現在口座情報として現在月の収入額とを取得する。そして、比較部233は、現在月より過去のいずれかの月の収入額と、現在月の収入額とを比較し、比較結果が所定の条件を満たすか否かを判定する。例えば、比較部233は、現在月より過去のいずれかの月の収入額と、現在月の収入額とを比較し、「現在月の収入額が現在月より過去のいずれかの月の収入額より多いこと」といった所定の条件を満たすか否かを判定する。
そして、比較部233は、所定の条件を満たすと判定すると、現在月より過去のいずれかの月の収入額と、現在月の収入額とに基づく金額を算出する。例えば、比較部233は、現在月の収入額と現在月より過去のいずれかの月の収入額との差額を算出し、算出した差額を通知部234に出力する。
通知部234は、所定の条件を満たすと判定されたことにより現在月の収入額と現在月より過去のいずれかの月の収入額との差額を受信すると、その差額を貯金するよう提案する提案情報を対象ユーザに通知する。
このような第2のパターンの処理について、一例を用いて説明する。なお、第2のパターンでも、現在月より過去のいずれかの月を現在月に対する1ヶ月前の月(先月)であるものとする。また、収入額は、給与額であるものとする。また、現在月は、11月であるものとする。また、対象ユーザをユーザU1とする。
まず、判定部232は、提案情報の通知を含めた一連の蓄積処理を開始するタイミングとして、現在が定期的な入金が行われた時点より後であるか否かを判定するものとする。具体的には、判定部232は、現在日が給料が支給される日(毎月24日)の翌日である25日であるか否かを判定する。例えば、判定部232は、現在日が11月25日であると判定すると、取得部231に対して取得を行うよう指示する。
ここで、定期的な入金が行われた時点より後に処理を開始するタイミングが設定されるのは、定期的な入金を給与の支給とすると、判定部232は、給与が支給された後でないと現在月の給与額を特定することができないためである。
取得部231は、判定部232からの指示を受信すると、ユーザU1の過去口座情報として「平成28年10月24日」時点(先月)における給与額を取得する。ここでは、取得部231は、「平成28年10月24日」時点(先月)における給与額「250,000円」を取得したとする。また、取得部231は、ユーザU1の現在口座情報として「平成28年11月25日」時点(現在月)における給与額を取得する。ここでは、取得部231は、「平成28年11月25日」時点(現在月)における給与額「260,000円」を取得したとする。
次に、比較部233は、過去口座情報である先月の給与額「250,000円」と、現在口座情報である現在月の給与額「260,000円」とを比較し、所定の条件「現在月の給与額が先月の給与より多いこと」を満たすか否かを判定する。かかる場合、比較部233は、比較結果が所定の条件を満たすと判定する。
このように、比較結果が所定の条件を満たすと判定すると、比較部233は、現在月の給与額と先月の給与額との差額「10,000円」を算出し、算出した差額「10,000円」を通知部234に出力する。
そして、通知部234は、差額「10,000円」を貯金するよう提案する提案情報をユーザU1に通知する。例えば、通知部234は、「給与増加分(10,000円)を貯金しませんか?」といった提案情報と、押下することにより貯金させることができるボタンBを含むコンテンツCを作成する。そして、通知部234は、作成したコンテンツCをユーザU1の端末装置10に配信する。
このように、実施形態にかかる口座管理システム100は、現在月の給与額が先月の給与額より多い場合に、現在月の給与額と先月の給与額との差額を貯金しないか提案する。つまり、口座管理システム100は、例えば、昇給や転職によりユーザの収入が増加したと考えられるタイミングで貯金を提案するため、給与が増えた分ユーザが確保できる余剰金を効果的に貯蓄させることができる。
さて、上記例では、比較対象を先月の給与額、および、現在月の給与額として処理を行う例を示した。しかしながら、取得部231は、現在月より過去のいずれかの月の収入額として過去数ヶ月分の給与額と、現在月の給与額を取得してもよい。かかる場合、比較部233は、例えば、過去数ヶ月分の給与額を平均した過去平均給与額と、現在月の給与額とを比較し、所定の条件「現在月の給与額が過去平均給与額より多いこと」を満たすか否かを判定する。そして、比較部233は、比較結果が所定の条件を満たすと判定すると、現在月の給与額と先月の過去平均給与額との差額を算出し、算出した差額を通知部234に出力する。
(第3のパターン)
次に、第3のパターンについて説明する。第3のパターンでは、取得部231は、過去口座情報として過去のいずれかの時点における定期的な出金額と、現在口座情報として現時点における定期的な出金額を取得する。そして、比較部233は、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額とを比較し、比較結果が所定の条件を満たすか否かを判定する。また、通知部234は、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額とに基づく金額を貯金するよう提案する提案情報を通知する。そして、提案情報にユーザが承諾した場合に、後述する蓄積部332は、この金額を蓄積する。この点について一例を示す。
例えば、取得部231は、過去口座情報として現在月より過去のいずれかの月の公共料金請求額と、現在口座情報として現在月の公共料金請求額とを取得する。そして、比較部233は、現在月より過去のいずれかの月の公共料金請求額と、現在月の公共料金請求額とを比較し、比較結果が所定の条件を満たすか否かを判定する。例えば、比較部233は、現在月より過去のいずれかの月の公共料金請求額と、現在月の公共料金請求額とを比較し、「現在月の公共料金請求額が現在月より過去のいずれかの月の公共料金請求額より少ないこと」といった所定の条件を満たすか否かを判定する。
そして、比較部233は、所定の条件を満たすと判定すると、現在月より過去のいずれかの月の公共料金請求額と、現在月の公共料金請求額とに基づく金額を算出する。例えば、比較部233は、現在月の公共料金請求額と現在月より過去のいずれかの月の公共料金請求額との差額を算出し、算出した差額を通知部234に出力する。
通知部234は、所定の条件を満たすと判定されたことにより現在月の公共料金請求額と現在月より過去のいずれかの月の公共料金請求額との差額を受信すると、その差額を貯金するよう提案する提案情報を対象ユーザに通知する。
このような第3のパターンの処理について、一例を用いて説明する。なお、第3のパターンでも、過去のいずれかの月を現在月に対する1ヶ月前の月(先月)であるものとする。また、現在月は、11月であるものとする。また、対象ユーザをユーザU1とする。
まず、判定部232は、提案情報の通知を含めた一連の蓄積処理を開始するタイミングとして、現在が定期的な出金として、公共料金請求が確定した時点より後であるか否かを判定するものとする。具体的には、判定部232は、現在日が毎月の公共料金請求(便宜上、毎月25日とする)の翌日である26日であるか否かを判定する。例えば、判定部232は、現在日が11月26日であると判定すると、取得部231に対して取得を行うよう指示する。
取得部231は、判定部232からの指示を受信すると、ユーザU1の過去口座情報として「平成28年10月25日」時点(先月)における公共料金請求額を取得する。ここでは、取得部231は、「平成28年10月25日」時点(先月)における公共料金請求額「13,000円」を取得したとする。また、取得部231は、ユーザU1の現在口座情報として「平成28年11月25日」時点(現在月)における公共料金請求額を取得する。ここでは、取得部231は、「平成28年11月25日」時点(現在月)における公共料金請求額「10,000円」を取得したとする。
次に、比較部233は、過去口座情報である先月の公共料金請求額「13,000円」と、現在口座情報である現在月の公共料金請求額「10,000円」とを比較し、所定の条件「現在月の公共料金請求額が先月の公共料金請求額より少ないこと」を満たすか否かを判定する。かかる場合、比較部233は、比較結果が所定の条件を満たすと判定する。
このように、比較結果が所定の条件を満たすと判定すると、比較部233は、現在月の公共料金請求額と先月の公共料金請求額との差額「3,000円」を算出し、算出した差額「3,000円」を通知部234に出力する。
そして、通知部234は、差額「3,000円」を貯金するよう提案する提案情報をユーザU1に通知する。例えば、通知部234は、「公共料金請求額減少分(3,000円)を貯金しませんか?」といった提案情報と、押下することにより貯金させることができるボタンBを含むコンテンツCを作成する。そして、通知部234は、作成したコンテンツCをユーザU1の端末装置10に配信する。
このように、実施形態にかかる口座管理システム100は、現在月の公共料金請求額が先月の公共料金請求額より少ない場合に、現在月の公共料金請求額と先月の公共料金請求額との差額を貯金しないか提案する。つまり、口座管理システム100は、公共料金が節約できた分を貯金するよう提案することで、節約によって確保できた余剰金を効果的に貯蓄させることができる。
なお、第3のパターンでも平均額を用いてもよい。具体的には、取得部231は、現在月より過去のいずれかの月の公共料金請求額として過去数ヶ月分の公共料金請求額と、現在月の公共料金請求額を取得してもよい。かかる場合、比較部233は、例えば、過去数ヶ月分の公共料金請求額を平均した過去平均公共料金請求額と、現在月の公共料金請求額とを比較し、所定の条件「現在月の公共料金請求額が過去平均公共料金請求額より少ないこと」を満たすか否かを判定する。そして、比較部233は、比較結果が所定の条件を満たすと判定すると、現在月の公共料金請求額と過去平均公共料金請求額との差額を算出し、算出した差額を通知部234に出力する。
なお、上記例では、定期的な出金額の一例として公共料金請求額を用いて説明した。しかしながら、定期的な出金額は、公共料金請求額に限定されるものではなく、例えば、電話料金請求額等であってもよい。
〔4.電子マネーサーバの構成〕
次に、図6を用いて、実施形態にかかる電子マネーサーバ300について説明する。図6は、実施形態にかかる電子マネーサーバ300の構成例を示す図である。図6に示すように、電子マネーサーバ300は、通信部310と、記憶部320と、制御部330とを有する。
(通信部310について)
通信部310は、例えば、NIC等によって実現される。そして、通信部310は、ネットワークNと有線または無線で接続され、例えば、端末装置10、金融機関サーバ30、管理サーバ200との間で情報の送受信を行う。
(記憶部320について)
記憶部320は、例えば、RAM、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部320は、蓄積情報記憶部321を有する。
(蓄積情報記憶部321について)
蓄積情報記憶部321は、管理サーバ200の通知部234によって通知された提案情報に対する対象ユーザの応答に応じて、貯蓄対象金額を蓄積する記憶部である。ここで、貯蓄対象金額とは、通知部234により提案された金額(過去口座情報と現在口座情報とに基づく金額)である。
ここで、図7に実施形態にかかる蓄積情報記憶部321の一例を示す。図7の例では、蓄積情報記憶部321は、「ユーザID」、「貯蓄日」、「貯蓄額」、「合計貯蓄額」といった項目を有する。なお、図7の蓄積情報記憶部321では、上記第1のパターンで示した処理が行われた場合の情報を記憶する例を示す。
「ユーザID」は、ユーザまたはユーザの端末装置10を識別するための識別情報を示す。「貯蓄日」は、蓄積情報記憶部321への蓄積が行われた日付を示す。「貯蓄額」は、対応する「貯蓄日」において蓄積された金額を示す。「合計貯蓄額」は、対応する「貯蓄日」の時点において、これまでに蓄積された「貯蓄額」の合計を示す。
すなわち、図7の例では、ユーザU1が、貯蓄日「平成28年11月23日」において、提案情報に対して承諾することにより「3,000円」を貯蓄した例を示す。また、貯蓄日「平成28年11月23日」の時点で、ユーザU1が、合計「5,000円」を貯蓄している例を示す。
(制御部330について)
図6に戻り、制御部330は、CPUやMPU等によって、電子マネーサーバ300内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部330は、例えば、ASICやFPGA等の集積回路により実現される。
図6に示すように、制御部330は、受信部331と、蓄積部332と、送信部333とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部330の内部構成は、図6に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部330が有する各処理部の接続関係は、図6に示した接続関係に限られず、他の接続関係であってもよい。
(受信部331について)
受信部331は、通知部234によって対象ユーザに通知された提案情報に対して、対象ユーザが承諾したことを示す承諾情報を対象ユーザの端末装置10から受信する受信部である。
図1の例を用いて説明すると、ユーザU1によってボタンBが押下された場合、すなわち、ユーザU1が「3,000円」を貯金することに承諾した場合、端末装置10は、貯蓄に承諾する旨の情報として、ユーザID「U1」と貯蓄対象金額「3,000円」を含む承諾情報を電子マネーサーバ300に送信する。受信部331は、このようにして送信された承諾情報を受信する。
(蓄積部332について)
蓄積部332は、比較部233によって過去口座情報と現在口座情報との比較結果が所定の条件を満たすと判定された場合に、過去口座情報と現在口座情報とに基づく金額を所定の口座へ蓄積する。具体的には、蓄積部332は、比較部233によって過去口座情報と現在口座情報との比較結果が所定の条件を満たすと判定されたことにより通知部234によって通知された提案情報に対する対象ユーザの承諾が得られた場合に、過去口座情報と現在口座情報とに基づく金額を対象ユーザの口座へ蓄積する。この点について、図1の例(第1のパターン)を用いて説明する。
蓄積部332は、ユーザID「U1」と貯蓄対象金額「3,000円」を含む承諾情報が受信されると、ユーザU1の利用している銀行に対応するサーバ装置を特定する。図1の例では、蓄積部332は、このサーバ装置が銀行サーバ302であることを特定する。そして、蓄積部332は、銀行サーバ302のユーザU1の口座から貯蓄対象金額「3,000円」を取得し、取得した「3,000円」を蓄積情報記憶部321に蓄積する。例えば、蓄積部332は、取得した「3,000円」を電子マネーに変換し、蓄積情報記憶部321に蓄積する。なお、第2のパターンや第3のパターンが示す処理が行われた場合であっても、蓄積部332によって行われる処理に違いは無いため説明を省略する。
(送信部333について)
送信部333は、蓄積情報記憶部321の「合計貯蓄額」を監視し、「合計貯蓄額」が所定額に達した場合に、その旨を管理サーバ200の通知部234に送信する。後述するが、かかる処理は、通知部234によって金融商品の提案が行われるようにするためのものである。
〔5.処理手順〕
次に、図8を用いて、実施形態にかかる口座管理システム100が実行する蓄積処理の手順について説明する。図8は、実施形態にかかる口座管理システム100による蓄積処理手順を示すフローチャートである。口座管理システム100は、管理サーバ200と電子マネーサーバ300とを有する。管理サーバ200の取得部231は、定期的に金融機関サーバ30から入出金データを取得し、入出金情報記憶部232を更新しているものとする。なお、金融機関サーバ30から入出金データを取得する処理は、取得部231以外の処理部によって行われてもよい。
まず、管理サーバ200の判定部232は、提案情報の通知を行うタイミングであるか否かを判定する(ステップS101)。例えば、判定部232は、現在が定期的な入金(毎月の給与振込)が行われる日の前日であるか否かを判定する。判定部232は、提案情報の通知を行うタイミングでない場合(ステップS101;No)は、提案情報の通知を行うタイミングとなるまで待機する。
一方、取得部231は、判定部232により提案情報の通知を行うタイミングであると判定されると(ステップS101;Yes)、入出金情報記憶部222から対象ユーザの過去口座情報と現在口座情報とを取得する(ステップS102)。例えば、取得部231は、過去口座情報として先月の口座残高と、現在口座情報として現在月の口座残高とを取得する。
次に、比較部233は、過去口座情報と現在口座情報とを比較し、比較結果が所定の条件を満たすか否かを判定する(ステップS103)。例えば、比較部233は、先月の口座残高と現在月の口座残高とを比較し、所定の条件「現在月の口座残高が先月の口座残高より多いこと」を満たすか否かを判定する。
比較部233は、比較結果が所定の条件を満たさないと判定した場合には(ステップS103;No)、処理を終了する。一方、通知部234は、比較結果が所定の条件を満たすと判定された場合には(ステップS103;Yes)、過去口座情報と現在口座情報とに基づく金額を貯金するよう対象ユーザに対して提案する(ステップS104)。例えば、比較部233は、現在月の口座残高と先月の口座残高との差額を貯金するよう対象ユーザに対して提案する。
次に、電子マネーサーバ300の受信部331は、対象ユーザが提案情報に対して承諾したか否かを判定する(ステップS105)。例えば、受信部331は、過去口座情報と現在口座情報とに基づく金額を含む承諾情報を対象ユーザの端末装置10から受信した場合に、対象ユーザが提案情報に対して承諾したと判定する。
受信部331は、対象ユーザが提案情報に対して承諾しないと判定した場合には(ステップS105;No)、処理を終了する。一方、蓄積部332は、対象ユーザが提案情報に対して承諾したと判定された場合には(ステップS105;Yes)、対象ユーザの銀行口座から貯蓄対象金額を取得する(ステップS106)。そして、蓄積部332は、取得した貯蓄対象金額を対象ユーザの電子マネー口座に蓄積する(ステップS107)。
〔6.変形例〕
上記実施形態にかかる口座管理システム100は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、口座管理システム100の他の実施形態について説明する。
〔6−1.利用頻度の高い口座から情報取得〕
上記実施形態では、対象ユーザに利用されている銀行は1つであり、取得部231は、その銀行に対応する銀行サーバ302から取得された入出金データが記憶される入出金情報記憶部222から過去口座情報と現在口座情報とを取得する例を示した。しかしながら、ユーザによっては、複数の銀行口座を有しており、それぞれの口座を会社Tに対して登録している場合がある。かかる場合、取得部231は、以下の処理を行ってよい。
具体的には、取得部231は、ユーザの有する銀行口座のうち、断続的な取引に用いられている銀行口座を特定する。そして、取得部231は、特定した銀行口座の入出金データを入出金情報記憶部222に格納することで、入出金情報記憶部222から過去口座情報と現在口座情報とを取得する。この点について、一例を用いて説明する。
例えば、取得部231は、ユーザU2が2つの異なる銀行それぞれに1つずつ口座を有していることにより、各銀行に対応するサーバ装置として銀行サーバ302および銀行サーバ303を特定したとする。かかる場合、取得部231は、銀行サーバ302および銀行サーバ303においてユーザU2の取引履歴を参照し、取引頻度のより高い口座に対応するサーバを特定する。例えば、取得部231は、取引頻度のより高い口座に対応するサーバが銀行サーバ302であると特定したとすると、銀行サーバ302から定期的に入出金データを取得し、入出金情報記憶部222に格納する。
これにより、取得部231は、断続的な取引に用いられている、すなわち利用頻度がより高いと特定された口座における過去口座情報と現在口座情報とを取得する。また、このような過去口座情報と現在口座情報とがこれまで説明してきた蓄積処理に用いられる。このため、口座管理システム100は、ユーザがあまり利用していないと考えられる口座における入出金データを用いて、蓄積処理を行ってしまうといった無駄な処理を行ってしまうことを防止することができる。また、口座管理システム100は、利用頻度の高い口座における入出金データを用いて、蓄積処理を行うことができるため、高精度な提案を行うことができる。
〔6−2.金融商品の案内通知(1)〕
また、管理サーバ200の通知部234は、金融商品の購入を提案する案内情報を対象ユーザに通知してもよい。具体的には、通知部234は、蓄積部332により蓄積された合計貯蓄額に基づいて、対象ユーザに金融商品の案内情報を通知する。例えば、通知部234は、蓄積部332により蓄積された合計貯蓄額が所定額に達した対象ユーザに金融商品の案内情報を通知する。
例えば、電子マネーサーバ300の送信部333は、蓄積情報記憶部321の「合計貯蓄額」を監視し、「合計貯蓄額」が所定額に達した場合に、そのユーザのユーザIDを通知部234に送信する。これにより、例えば、通知部234は、ユーザU1の「合計貯蓄額」が所定額に達したことを認識すると、ユーザU1に金融商品の購入を提案する案内情報を通知する。
一例を示すと、通知部234は、「あなたの電子マネーが「5万円」になりました。以下の金融商品を購入することができます」といった案内テキストとともに、例えば、投資信託、株式、保険等の金融商品が一覧表示されるコンテンツを作成する。そして、通知部234は、作成したコンテンツをユーザU1の端末装置10に配信する。
ここで、「合計貯蓄額」は、ユーザが比較的自由に使うことのできるお金が蓄積された資金である。このため、「合計貯蓄額」を利用した金融商品の購入を提案することで、口座管理システム100は、ユーザに対してより気軽に金融商品を購入させることができるため、効果的にユーザの資金を増やすことができる。
〔6−3.金融商品の案内通知(2)〕
また、通知部234は、ユーザの有する口座のうち、断続的な取引に用いられていないと特定された口座において所定期間、所定額以上の金額が貯蓄されている場合には、当該ユーザに金融商品の案内情報を通知してもよい。
変形例6−1では、取得部231が、ユーザが複数の銀行口座を有している場合、その銀行口座のうち断続的な取引に用いられている口座、すなわちより利用頻度の高い口座を特定し、特定したより利用頻度の高い口座の入出金データで入出金情報記憶部222を構築する例を示した。また、このような入出金情報記憶部222から過去口座情報と現在口座情報を取得することで、蓄積処理が行われることを示した。
ここで、取得部231は、断続的な取引に用いられていない、すなわち利用頻度の低い銀行口座も自ずと特定することになる。したがって、通知部234は、利用頻度の低い銀行口座が特定された場合、かかる銀行口座において所定期間、所定額以上の金額が貯蓄されているか否かを判定する。所定期間や所定額は、予め任意に設定されて良いものである。
そして、通知部234は、利用頻度の低い銀行口座において所定期間、所定額以上の金額が貯蓄されていると判定した場合、その銀行口座を有する対象ユーザに金融商品の案内情報を通知する。ここで、利用頻度は低いが所定期間、所定額以上の金額が貯蓄されている口座は、貯蓄専用に設けられた口座であり、こういった口座に貯蓄されている資金は、日常の生活費等には利用されていない可能性が高い。また、このような口座を所有しているユーザは、貯蓄意欲が高いといえる。したがって、実施形態にかかる口座管理システム100は、金融商品を案内することで、金融商品を効果的に購入させることができるとともに、ユーザの資金をより増やすことができる。
〔6−4.自動で貯蓄〕
ユーザによっては、例えば、毎月の収入があったとしてもその月のうちに口座残高の全額を消費してしまったり、口座残高の全額を消費せずとも、毎月振込みが行われる直前には残高がわずか「例えば、500円以下」しか残らないといった場合がある。このようなユーザに対しては、上述してきた差額を算出できなかったり、差額が算出できたとしても数円、あるいは、数十円といったもので、差額を貯蓄するよう提案することが困難な場合がある。
そこで、通知部234は、銀行口座の残高が所定額より少ないユーザに対して、月々所定額を自動で貯金させることができるサービスを提案してもよい。例えば、通知部234は、入出金情報記憶部222を参照し、例えば、所定の期間(例えば、半年間)、銀行口座の残高が所定額(例えば、500円)より少ないユーザを特定する。そして、通知部234は、「毎月、残高から「1,000円」を自動貯金するサービスをご提供」といった案内情報と、サービス提供を受けることに承諾するボタンとを含むコンテンツを作成する。そして、通知部234は、作成したコンテンツを特定したユーザの端末装置10に配信する。
これにより、実施形態にかかる口座管理システム100は、残高が少なくまとまった資金をつくることが困難であると考えられるユーザに対して、まとまった資金をつくることができるようなきっかけを与えることができる。
〔6−5.他のユーザとの比較〕
上記実施形態では、口座管理システム100が、対象ユーザそれぞれについて、当該対象ユーザの過去口座情報と現在口座情報とを取得し、過去口座情報と現在口座情報との比較結果が所定の条件を満たす場合に通知を行う例を示した。しかし、口座管理システム100は、対象ユーザの口座情報と、当該対象ユーザとは異なる他のユーザであって当該対象ユーザと同一属性のユーザの口座情報とを取得し、これらの口座情報を比較した比較結果が所定の条件を満たす場合に通知を行ってもよい。
ここで、対象ユーザをユーザU1としてより具体的に説明する。例えば、取得部231は、ユーザU1とは異なる他のユーザであってユーザU1と同一属性のユーザを特定する。例えば、属性を年代とすると、取得部231は、ユーザ情報記憶部221を参照し、ユーザU1と同年代のユーザを特定する。ここでは、取得部231は、ユーザU1と同年代のユーザとしてユーザU2を特定したとする。
次に、取得部231は、ユーザU1の現在の口座情報である現在口座情報(「現在口座情報A」とする)と、ユーザU2の現在の口座情報である現在口座情報(「現在口座情報B」とする)とを入出金情報記憶部222から取得する。例えば、取得部231は、現在口座情報AとしてユーザU1の現在月の口座残高を取得する。また、取得部231は、現在口座情報BとしてユーザU2の現在月の口座残高を取得する。
かかる場合、比較部233は、ユーザU1の現在月の口座残高がユーザU2の現在月の口座残高より高いか否かを判定し、高いと判定した場合には、ユーザU1の現在月の口座残高がユーザU2の現在月の口座残高との差額(「現在口座情報A」と「現在口座情報B」とに基づく金額)を通知部234に出力する。そして、通知部234は、比較部233から受信した差額を貯金するよう提案する提案情報をユーザU1に対して通知する。
また、蓄積部332は、提案情報に対するユーザU1の承諾が得られた場合には、差額分の資金をユーザU1の銀行口座から取得し、電子マネー口座(蓄積情報記憶部321)に蓄積する。
このように、口座管理システム100は、対象ユーザの口座残高が同一属性の他のユーザの口座残高より高い場合、高い残高を有している分を貯金させることができるため、効果的に貯蓄させることができる。また、例えば、通知部234が、「あなたは同年代のユーザよりも多くの残金を有しています。そんなあなたは貯蓄でさらに資金を増やしませんか?」といった同属性のユーザとの比較結果を知らせるような提案情報とすることで、効果的に貯蓄させることができる。
また、上記例では、説明を簡単にするために、対象ユーザと同一属性のユーザとして1人のユーザを特定した例を示した。しかしながら、取得部231は、例えば、対象ユーザと同一属性のユーザを複数人特定し、特定したユーザそれぞれの現在月の口座残高を取得してもよい。これにより、比較部233は、対象ユーザと同一属性のユーザそれぞれの現在月の口座残高を平均した平均残高と、対象ユーザの現在月の口座残高とを比較し、また、通知部244は、対象ユーザの現在月の口座残高が平均残高より高い場合に、対象ユーザの現在月の口座残高と平均残高との差額を貯金するよう提案する。
また、かかる変形例では、上述した第1のパターンに沿った処理(比較対象が口座残高)を示したが、第2のパターンに沿った処理(比較対象が給与額)や、第3のパターンに沿った処理(比較対象が公共料金請求額)であってもよい。
〔6−6.貯蓄対象金額について〕
上記実施形態では、通知部234が、過去口座情報と現在口座情報との比較結果が所定の条件を満たす場合に、過去口座情報と現在口座情報とに基づく金額を所定の口座へ貯金するよう提案する提案情報をユーザに通知する例を示した。具体的には、通知部234が、過去口座情報と現在口座情報とに基づく金額として、現在月の口座残高と先月の口座残高との差額、現在月の収入額と先月の収入額との差額、あるいは、現在月の公共料金請求額と先月の公共料金請求額との差額を貯金するよう提案する例を示した。
ここで、このような差額(特に、現在月の口座残高と先月の口座残高との差額)が電子マネー口座への貯蓄に回された場合、ユーザの銀行口座には資金が蓄積されていかないことが考えられる。したがって、通知部234は、差額に対する所定割合分の金額を貯金するよう提案してもよい。また、通知部234は、差額に応じた所定割合分の金額を貯金するよう提案してもよい。
一例を示すと、例えば、現在月の口座残高と先月の口座残高との差額が「3,000円」である場合には、通知部234は、差額「3,000円」に対する50%の「1,500円」を貯金するよう提案する。また、例えば、現在月の口座残高と先月の口座残高との差額が「15,000円」である場合には、通知部234は、差額「15,000円」に対する30%の「4,500円」を貯金するよう提案する。
これにより、口座管理システム100は、ユーザの銀行口座にお金が貯まらなくなるといったことを防止することができる。なお、上記例では、差額が高いほど差額に対する割合が低くなる例を示したが、差額が高いほど差額に対する割合を高くしてもよい。
〔7.ハードウェア構成〕
また、上述してきた各実施形態にかかる管理サーバ200および電子マネーサーバ300は、例えば図9に示すような構成のコンピュータ1000によって実現される。以下、管理サーバ200を例に挙げて説明する。図9は、管理サーバ200の機能を実現するコンピュータ1000の一例を示すハードウェア構成図である。コンピュータ1000は、CPU1100、RAM1200、ROM1300、HDD1400、通信インターフェイス(I/F)1500、入出力インターフェイス(I/F)1600、及びメディアインターフェイス(I/F)1700を有する。
CPU1100は、ROM1300又はHDD1400に格納されたプログラムに基づいて動作し、各部の制御を行う。ROM1300は、コンピュータ1000の起動時にCPU1100によって実行されるブートプログラムや、コンピュータ1000のハードウェアに依存するプログラム等を格納する。
HDD1400は、CPU1100によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス1500は、通信網50を介して他の機器からデータを受信してCPU1100へ送り、CPU1100が生成したデータを、通信網50を介して他の機器へ送信する。
CPU1100は、入出力インターフェイス1600を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。CPU1100は、入出力インターフェイス1600を介して、入力装置からデータを取得する。また、CPU1100は、生成したデータを、入出力インターフェイス1600を介して出力装置へ出力する。
メディアインターフェイス1700は、記録媒体1800に格納されたプログラム又はデータを読み取り、RAM1200を介してCPU1100に提供する。CPU1100は、かかるプログラムを、メディアインターフェイス1700を介して記録媒体1800からRAM1200上にロードし、ロードしたプログラムを実行する。記録媒体1800は、例えばDVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
例えば、コンピュータ1000が実施形態にかかる管理サーバ200として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部230の機能を実現する。また、HDD1400には、記憶部220内のデータが格納される。コンピュータ1000のCPU1100は、これらのプログラムを、記録媒体1800から読み取って実行するが、他の例として、他の装置から、通信網50を介してこれらのプログラムを取得してもよい。
また、例えば、コンピュータ1000が実施形態にかかる電子マネーサーバ300として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部330の機能を実現する。
〔8.その他〕
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上述してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
〔9.効果〕
実施形態にかかる口座管理理ステム100は、取得部231と、蓄積部332とを有する。取得部231は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。蓄積部332は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす場合に、過去口座情報と、現在口座情報とに基づく金額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、ユーザに対して無理なく効率的に貯蓄させることができる。
実施形態にかかる口座管理理ステム100は、通知部234を有する。通知部234は、比較結果が所定の条件を満たす場合に、過去口座情報と、現在口座情報とに基づく金額を所定の口座へ貯金するよう提案する提案情報をユーザに通知する。そして、蓄積部332は、提案情報に対するユーザの承諾が得られた場合に、金額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、ユーザに対して無理なく効率的に貯蓄させることができる。
また、通知部234は、提案情報を含むコンテンツであって当該提案情報に承諾することを前記ユーザから受け付け可能なコンテンツを、ユーザの操作に拘わらずユーザに通知する。そして、蓄積部332は、コンテンツを介して、提案情報に対するユーザの承諾が受け付られた場合に、金額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、ワンタッチで手軽に貯金させることができるため、効率的に貯蓄させることができる。
また、取得部231は、過去口座情報として過去のいずれかの時点における口座残高と、現在口座情報として現時点における口座残高を取得する。そして、蓄積部332は、過去のいずれかの時点における口座残高と、現時点における口座残高との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における口座残高と、現時点における口座残高とに基づく金額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、ユーザが自由に使うことができると考えられる余剰金を効果的に貯蓄させることができる。
また、蓄積部332は、所定の条件として、現時点における口座残高が前記過去のいずれかの時点における口座残高より多い場合に、現時点における口座残高と過去のいずれかの時点における口座残高との差額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、ユーザが自由に使うことができると考えられる余剰金を効果的に貯蓄させることができる。
また、取得部231は、過去口座情報として過去のいずれかの時点における収入額と、現在口座情報として現時点における収入額とを取得する。そして、蓄積部332は、過去のいずれかの時点における収入額と、現時点における収入額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における収入額と、現時点における収入額とに基づく金額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、昇給や転職によりユーザの収入が増加したと考えられる場合に貯金させることができるため、収入が増えた分ユーザが確保できる余剰金を効果的に貯蓄させることができる。
また、蓄積部332は、所定の条件として、現時点における収入額が過去のいずれかの時点における収入額より多い場合に、現時点における収入額と過去のいずれかの時点における収入額との差額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、昇給や転職によりユーザの収入が増加したと考えられる場合に貯金させることができるため、収入が増えた分ユーザが確保できる余剰金を効果的に貯蓄させることができる。
また、取得部231は、過去口座情報として過去のいずれかの時点における定期的な出金額と、現在口座情報として現時点における定期的な出金額とを取得する。そして、蓄積部332は、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額とに基づく金額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、例えば、節約によって確保できたと考えられる余剰金を効果的に貯金させることができる。
蓄積部332は、所定の条件として、現時点における定期的な出金額が過去のいずれかの時点における定期的な出金額より少ない場合に、現時点における定期的な出金額と過去のいずれかの時点における定期的な出金額との差額を所定の口座へ蓄積する。
これにより、実施形態にかかる口座管理理ステム100は、例えば、節約によって確保できたと考えられる余剰金を効果的に貯蓄させることができる。
また、通知部234は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす場合に、所定のタイミングで提案情報をユーザに通知する。
これにより、実施形態にかかる口座管理理ステム100は、例えば、ユーザが貯金することをより決断し易いタイミングで通知を行うことができる。
また、通知部234は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす月の所定の期日に提案情報をユーザに通知する。
これにより、実施形態にかかる口座管理理ステム100は、例えば、ユーザが貯金することをより決断し易いタイミングで通知を行うことができる。
また、通知部234は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす月において定期的な出金が行われた後に提案情報をユーザに通知する。
これにより、実施形態にかかる口座管理理ステム100は、ユーザに対して余剰金が生まれたことが確定できるタイミングで通知を行うことができるため、効果的に貯金させることができる。
また、通知部234は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす月において定期的な入金が行われる前に提案情報をユーザに通知する。
これにより、実施形態にかかる口座管理理ステム100は、例えば、給料日前に通知を行うことができるため、貯金してもすぐに給料が支給されるため資金には困らないといった安心感を与えることができるため、効果的に貯金させることができる。
また、通知部234は、蓄積部332により蓄積された貯蓄金額に基づいて、ユーザに金融商品の案内情報を通知する。
これにより、実施形態にかかる口座管理理ステム100は、ユーザに対してより気軽に金融商品を購入させることができるため、効果的にユーザの資金を増やすことができる。
通知部234は、ユーザの有する口座のうち、断続的な取引に用いられていないと特定された口座において所定期間、所定額以上の金額が貯蓄されている場合には、当該ユーザに金融商品の案内情報を通知する。
これにより、実施形態にかかる口座管理理ステム100は、例えば、資金を貯め込んでいると考えられるユーザに対して金融商品を案内することで、金融商品を効果的に購入させることができるとともに、ユーザの資金をより増やすことができる。
取得部231は、ユーザの有する口座のうち、断続的な取引に用いられていると特定された口座における過去口座情報と、現在口座情報とを取得する。
これにより、実施形態にかかる口座管理理ステム100は、ユーザがあまり利用していないと考えられる口座における入出金データを用いて、蓄積処理を行ってしまうといった無駄な処理を行ってしまうことを防止することができる。
以上、本願の実施形態をいくつかの図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
また、上述してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。