JP2018101284A - 口座管理システム、口座管理方法および口座管理プログラム - Google Patents

Abstract

【課題】ユーザに対して無理なく効率的に貯蓄させること。
【解決手段】本願にかかる口座管理システムは、取得部と、蓄積部とを有する。取得部は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。蓄積部は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす場合に、過去口座情報と、現在口座情報とに基づく金額を所定の口座へ蓄積する。
【選択図】図３

Description

本発明は、口座管理システム、口座管理方法および口座管理プログラムに関する。

近年、インターネットの飛躍的な普及に伴い、インターネットを介したサービスが盛んに行われている。この一例として、金融取引サービスがある。

例えば、引用文献１には、預金者の預金口座から預金を引き出し自動的に貯蓄を行う技術が開示されている。

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

しかしながら、上記の従来技術では、ユーザに対して無理なく効率的に貯蓄させることができるとは限らない。例えば、上記の従来技術では、預金者の口座に対して入金または出金の取引要求があった際に、預金口座の残高を調べる。そして、預金口座の残高に予め預金者によって設定された所定の桁以下の端数がある場合はその端数を、預金残高に所定の桁以下の端数がない場合には預金口座の残高に予め設定された所定の割合を乗じることで生成した端数を、預金者の指定した積立口座に資金移動する。

このように、上記の従来技術では、入出金の取引要求があった場合に、預金者による設定情報に基づく端数金額を預金口座の残高から積立口座に資金移動するため、例えば、出金により預金口座の残高が切迫してしまった場合でも、そこから端数金額が資金移動される可能性がある。したがって、上記の従来技術では、必ずしもユーザに対して無理なく効率的に貯蓄させることができるとは限らない。

本願は、上記に鑑みてなされたものであって、ユーザに対して無理なく効率的に貯蓄させることができる口座管理システムを提供することを目的とする。

本願にかかる口座管理システムは、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する取得部と、前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす場合に、前記過去口座情報と、前記現在口座情報とに基づく金額を所定の口座へ蓄積する蓄積部とを有することを特徴とする。

実施形態の一態様によれば、ユーザに対して無理なく効率的に貯蓄させることができるといった効果を奏する。

図１は、実施形態にかかる蓄積処理の一例を示す図である。 図２は、実施形態にかかる全体システムの構成例を示す図である。 図３は、実施形態にかかる管理サーバの構成例を示す図である。 図４は、実施形態にかかるユーザ情報記憶部の一例を示す図である。 図５は、実施形態にかかる入出金情報記憶部の一例を示す図である。 図６は、実施形態にかかる電子マネーサーバの構成例を示す図である。 図７は、実施形態にかかる蓄積情報記憶部の一例を示す図である。 図８は、実施形態にかかる口座管理システムによる蓄積処理手順を示すフローチャートである。 図９は、管理サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願にかかる口座管理システム、口座管理方法および口座管理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ説明する。なお、この実施形態により本願にかかる口座管理システム、口座管理方法および口座管理プログラムが限定されるものではない。また、以下の実施形態において、同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．蓄積処理〕
まず、図１を用いて、実施形態にかかる蓄積処理であって貯蓄対象金額を蓄積する蓄積処理の一例について説明する。図１は、実施形態にかかる蓄積処理の一例を示す図である。実施形態にかかる蓄積処理は、図１に示す口座管理システム１００によって行われる。

まず、図１に示すシステム構成について説明する。図１に示す全ての装置を含む全体システム１について説明する。全体システム１は、端末装置１０と、カード会社サーバ３０_１と、銀行サーバ３０_２と、管理サーバ２００と、電子マネーサーバ３００とを含む。端末装置１０、カード会社サーバ３０_１、銀行サーバ３０_２、管理サーバ２００、電子マネーサーバ３００は、ネットワークを介して有線または無線により通信可能に接続される。なお、図１に示す全体システム１には、複数台の端末装置１０や、複数台のカード会社サーバ３０_１や、複数台の銀行サーバ３０_２や、複数台の管理サーバ２００や、複数台の電子マネーサーバ３００が含まれてもよい。

また、図１に示すように、全体システム１に含まれる管理サーバ２００と、電子マネーサーバ３００とから構成されるシステムを口座管理システム１００とする。実施形態にかかる蓄積処理は、この口座管理システム１００によって行われる。また、管理サーバ２００と、電子マネーサーバ３００とは、管理会社Ｔ（以下、単に「会社Ｔ」と表記する）によって管理されるものとする。

ここで、実施形態にかかる蓄積処理は、管理サーバ２００の機能と、電子マネーサーバ３００の機能とを有する一台の装置によって行われてもよい。かかる場合、口座管理システム１００は、例えば、口座管理装置１００と見なすことができる。

次に、全体システム１および口座管理システム１００に含まれる各装置について説明する。端末装置１０は、ユーザによって利用される端末装置であり、例えば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）等である。例えば、端末装置１０は、管理サーバ２００から受け付けた情報を表示画面Ｄに表示する。また、端末装置１０は、ユーザ操作に従って、所定の情報を電子マネーサーバ３００に送信する。

カード会社サーバ３０_１は、クレジットカード管理および運営を行っている各カード会社に属するサーバ装置である。例えば、カード会社サーバ３０_１は、対応するクレジットカードの利用履歴（利用明細）として、カード利用による支払金額、支払対象（購入商品等）、支払先（商品が購入された店舗等）を、ユーザ毎に取引年月日に対応付けて記憶している。また、カード会社サーバ３０_１は、例えば、ログインＩＤおよびクレジットカード暗証番号を用いてアクセスしてきたユーザに対して、当該ユーザの利用明細を提示する。なお、図１では、一台のカード会社サーバ３０_１を例示しているが、実際には、カード会社サーバ３０_１は、例えば、カード会社毎に存在する。

銀行サーバ３０_２は、銀行に属するサーバ装置である。例えば、銀行サーバ３０_２は、銀行窓口やＡＴＭを利用した入出金である利用履歴や現在の口座情報（例えば、口座残高）を、ユーザ毎に取引年月日に対応付けて記憶している。なお、図１では、一台の銀行サーバ３０_２を例示しているが、実際には、銀行サーバ３０_２は、例えば、銀行毎に存在する。

ここで、実施形態にかかる口座管理システム１００は、例えば、ユーザの日々の生活費ではなく、生活費以外に余った資金、すなわちユーザが自由に使うことのできる資金である「余剰金」をうまく貯蓄させることで、ユーザが資産をより増やすことができるように蓄積処理を行うものである。このような余剰金を貯蓄に回すのであれば、ユーザが生活費を圧迫させられることが無いため、ユーザの貯蓄意欲が高まると考えられる。したがって、口座管理システム１００は、ユーザの余剰金に着目した蓄積処理を行う。

具体的には、管理サーバ２００は、貯蓄処理の対象となるユーザ（対象ユーザ）について、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得し、過去口座情報と現在口座情報とを比較する。そして、管理サーバ２００は、比較によって得られた比較結果が所定の条件を満たす場合に、過去口座情報と現在口座情報とに基づく金額を貯金するよう対象ユーザに提案する。

そして、電子マネーサーバ３００は、提案に対する対象ユーザの承諾が得られた場合に、過去口座情報と現在口座情報とに基づく金額を対象ユーザの口座に蓄積する、すなわち対象ユーザの口座に貯蓄する。例えば、電子マネーサーバ３００は、対象ユーザの銀行口座から、過去口座情報と現在口座情報とに基づく金額分の資金を抽出し、その資金を電子マネーとして自装置内の電子マネー口座に蓄積する。

さて、ここからは、口座管理システム１００による蓄積処理について具体的に説明する。まず、会社Ｔは、ユーザに対して有料サービス、有料コンテンツ、ショッピングサービス等を提供している。このため、会社Ｔは、支払いや報酬の受け取りを簡便にするために、これらのコンテンツを利用しようとするユーザから事前に、クレジットカードや銀行口座に関する情報の登録を受け付けている。このようなことから、管理サーバ２００は、例えば、ユーザのクレジットカードや銀行口座に関する情報を適宜取得することができる。

例えば、管理サーバ２００が、ユーザからクレジットカードや銀行口座に関する情報の登録を受け付けてもよいし、会社Ｔの他のサーバ装置に登録されたものを取得してもよい。また、このようなことから、管理サーバ２００は、クレジットカードや銀行口座に関する情報を登録している各ユーザについて、クレジットカードに対応するサーバ装置や、銀行に対応するサーバ装置を特定することができる。

以下、ユーザＵ１を例に挙げて説明する。なお、ユーザＵ１以外の他のユーザについても同様の処理が行われる。まず、図１では、管理サーバ２００は、ユーザＵ１が有するクレジットカードに対応するサーバ装置がカード会社サーバ３０_１であり、ユーザＵ１が利用している銀行に対応するサーバ装置が銀行サーバ３０_２であることを特定している例を示す。

このような状態において、管理サーバ２００は、カード会社サーバ３０_１および銀行サーバ３０_２から、ユーザの入金および出金に関する入出金データを取得する（ステップＳ１）。入金データとは、例えば、ユーザの銀行口座に振り込まれた金額、すなわち預入金額に関する情報を示す。出金データとは、例えば、引き出しやカード利用によりユーザの銀行口座に貯蓄されている資金から支払われた支払金額に関する情報を示す。

例えば、管理サーバ２００は、カード会社サーバ３０_１からユーザＵ１のカード利用に関する履歴情報を出金データとして取得する。例えば、管理サーバ２００は、定期的にカード会社サーバ３０_１にアクセスし、カードが利用された年月日である取引年月日、カード利用による支払金額、何に対してカード利用されたかを示す概要情報を含む履歴情報を出金データとして取得する。そして、管理サーバ２００は、出金データを入出金情報記憶部２２２に格納する。

また、管理サーバ２００は、銀行サーバ３０_２からユーザＵ１の銀行利用による入出金に関する履歴情報を入出金データとして取得する。例えば、管理サーバ２００は、定期的に銀行サーバ３０_２にアクセスし、銀行利用により入出金が行われた年月日である取引年月日、銀行口座に振り込まれた預入金額、銀行利用により支払った支払金額、銀行利用による預入および支払に関する概要情報を含む履歴情報を入出金データとして取得する。そして、管理サーバ２００は、入出金データを入出金情報記憶部２２２に格納する。

図１に示すように、管理サーバ２００は、入出金情報記憶部２２２を有する。入出金情報記憶部２２２は、管理サーバ２００によって取得された入出金データを記憶する記憶部である。図１の例では、入出金情報記憶部２２２は、「ユーザＩＤ」、「取引年月日」、「預入金額」、「支払金額」、「概要」、「残高」といった項目を有する。

例えば、入出金情報記憶部２２２は、ユーザＩＤ「Ｕ１」に、取引年月日「２８−０９−２４」、預入金額「２５０，０００円」、概要「給与、Ｓ株式会社」、残高「７５０，０００円」を対応付けて記憶している。これは、「平成２８年９月２４日」においてユーザＵ１の口座に「２５０，０００円」が振り込まれたことにより、この時点での口座残高が「７５０，０００円」となった例を示す。また、振り込まれた「２５０，０００円」の概要は「Ｓ株式会社からの給与振込」である例を示す。

また、入出金情報記憶部２２２は、ユーザＩＤ「Ｕ１」に、取引年月日「２８−０９−２５」、支払金額「１５，０００円」、概要「カード、公共料金」、残高「７３５，０００円」を対応付けて記憶している。これは、「平成２８年９月２５日」においてユーザＵ１の口座から「１５，０００円」が引き落とされたことにより、この時点での口座残高が「７３５，０００円」となった例を示す。また、引き落とされた「１５，０００円」の概要は「カード利用による公共料金支払」である例を示す。

ここで、実施形態にかかる口座管理システム１００は、毎月２３日に蓄積処理を行うものとする。例えば、口座管理システム１００は、現在が「１１月２３日」であるか否かを判定し、「１１月２３日」であることを特定したとする。かかる場合、管理サーバ２００は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを比較する（ステップＳ２）。蓄積処理に含まれる比較処理について具体的に説明する。

管理サーバ２００は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。例えば、管理サーバ２００は、過去口座情報として現在月より過去のいずれかの月の口座残高と、現在口座情報として現在月の口座残高とを入出金情報記憶部２２２から取得する。本実施形態では、現在月より過去のいずれかの月は、現在月より１ヵ月前の月であるもとする。

したがって、管理サーバ２００は、図１の例では、ユーザＵ１の過去口座情報として「平成２８年１０月２３日」時点（先月）における口座残高「７５５，０００円」を取得する。図１の例では、「平成２８年１０月２４日」時点における口座残高が「１，００５，０００円」であるため、「平成２８年１０月２３日」時点における口座残高は「７５５，０００円」である。また、図１の例では、管理サーバ２００は、ユーザＵ１の現在口座情報として「平成２８年１１月２３日」時点（現在月）における口座残高「７５８，０００円」を取得する。

次に、管理サーバ２００は、過去口座情報である先月の口座残高「７５５，０００円」と、現在口座情報である現在月の口座残高「７５８，０００円」とを比較し、比較結果が所定の条件を満たすか否かを判定する。ここで、所定の条件は、「現在月の口座残高が先月の口座残高より多いこと」であるものとする。かかる場合、管理サーバ２００は、現在月の口座残高「７５８，０００円」が、先月の口座残高「７５５，０００円」より多いことから、比較結果が所定の条件「現在月の口座残高が先月の口座残高より多いこと」を満たすと判定する。

このように、比較処理により比較結果が所定の条件を満たすと判定すると、管理サーバ２００は、現在月の口座残高と先月の口座残高との差額である「３，０００円」を貯金するよう提案する提案情報をユーザＵ１に通知する（ステップＳ３）。より具体的には、管理サーバ２００は、上記のような提案情報を含むコンテンツＣであって当該提案情報に承諾することをユーザから受け付け可能なコンテンツＣを、ユーザＵ１の操作に拘わらず通知する（プッシュ通知）。

そして、端末装置１０は、管理サーバ２００から受信したコンテンツＣを表示画面Ｄに表示する。図１では、表示画面Ｄに表示されたコンテンツＣの一例を示す。コンテンツＣには、「１１月２４日は給料日です。残高（３，０００円）を貯金しませんか？」といった提案情報が含まれる。ここで、表示される残高「３，０００円」は、比較処理で算出された差額「３，０００円」である。つまり、管理サーバ２００は、現在のユーザＵ１の口座残高全額「７５８，０００円」のうちの一部の残高であって、現在月の口座残高と先月の口座残高との差額に相当する残高「３，０００円」を貯金するよう提案する。

また、コンテンツＣには、「貯金する」が表示されたボタンＢが含まれる。電子マネーサーバ３００は、ボタンＢが押下された場合に、提案情報に承諾することをユーザから受け付ける。例えば、ユーザＵ１は、「３，０００円」の貯金に承諾する場合には、ボタンＢを押下する。これにより、ユーザＵ１は、ワンタッチで貯金を行うことができる。例えば、端末装置１０がスマートフォンでる場合には、ユーザＵ１は、ワンタップで貯金を行うことができる。また、端末装置１０がＰＣである場合には、ユーザＵ１は、ワンクリックで貯金を行うことができる。

ここで、ユーザＵ１によってボタンＢが押下されたとする。つまり、ユーザＵ１が「３，０００円」を貯金することに承諾したとする。かかる場合、端末装置１０は、貯蓄に承諾する旨の情報として、ユーザＩＤと貯蓄対象金額「３，０００円」を含む承諾情報を電子マネーサーバ３００に送信する（ステップＳ４）。

電子マネーサーバ３００は、承諾情報を受信すると、承諾情報に含まれるユーザＩＤからユーザＵ１の利用している銀行に対応するサーバ装置を特定する。図１の例では、電子マネーサーバ３００は、このサーバ装置が銀行サーバ３０_２であることを特定する。

そして、電子マネーサーバ３００は、銀行サーバ３０_２のユーザＵ１の口座から貯蓄対象金額「３，０００円」分の資金を取得し、取得した「３，０００円」を蓄積情報記憶部３２１に蓄積する（ステップＳ５）。例えば、電子マネーサーバ３００は、取得した「３，０００円」を電子マネーに変換し、蓄積情報記憶部３２１に蓄積する。

図１の例では、蓄積情報記憶部３２１は、「ユーザＩＤ」、「貯蓄日」、「貯蓄額」、「合計貯蓄額」といった項目を有する。このため、電子マネーサーバ３００は、ユーザＩＤ「Ｕ１」に、貯蓄日「平成２８年１１月２３日」、貯蓄額「３，０００円」、合計貯蓄額「５，０００円」を記憶する。また、このようなことから蓄積情報記憶部３２１は、電子マネー口座に相当する。

以上、蓄積処理について説明してきた。上記の通り、口座管理システム１００は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。そして、口座管理システム１００は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす場合に、過去口座情報と、現在口座情報とに基づく金額を所定の口座へ蓄積する。

図１の例では、口座管理システム１００は、現在月の口座残高が先月の口座残高より多い場合に、現在月の口座残高と先月の口座残高との差額を貯金しないか提案する。例えば、口座管理システム１００は、一般的な給料日が毎月２４日であるとすると、その前日に提案を行う。そして、ユーザの承諾が得られた場合に、口座管理システム１００は、その残高をユーザの口座（電子マネー口座）に蓄積する。

ここで、現在月の口座残高が先月の口座残高より多い場合、現在月の口座残高と先月の口座残高との差額は、ユーザにとって自由に使うことのできる資金と考えられる。実施形態にかかる口座管理システム１００は、このような差額を貯金するよう提案することにより、ユーザに対して無理なく効率的に貯蓄させることができる。また、図１で説明したように、給料日を毎月２４日とすると、口座管理システム１００は、その前日に提案も含めた一連の蓄積処理を行うため、例えば、残高を貯金に回しても翌日には給料が支給されるといった安心感からより効果的に貯蓄させることができる。

さて、図１では図示しないが、口座管理システム１００は、蓄積情報記憶部３２１に蓄積された貯蓄額（合計貯蓄額）が所定額を超えたユーザに対して、所定の金融商品、例えば、投資信託を提案してもよい。蓄積情報記憶部３２１に蓄積された資金は、ユーザが比較的自由に使うことのできるお金が蓄積されたものであるため、ユーザは気軽に投資信託により資金を増やすことができる。

〔２．システムの構成〕
次に、図２を用いて、実施形態にかかる全体システム１の構成について説明する。図２は、実施形態にかかる全体システム１の構成例を示す図である。図２に示すように、全体システム１には、端末装置１０と、カード会社サーバ３０_１と、銀行サーバ３０_２と、管理サーバ２００と、電子マネーサーバ３００とが含まれる。端末装置１０と、カード会社サーバ３０_１と、銀行サーバ３０_２と、管理サーバ２００と、電子マネーサーバ３００とは、ネットワークＮを介して、有線または無線により通信可能に接続される。

なお、図２に示した全体システム１には、複数台の端末装置１０、複数台のカード会社サーバ３０_１、複数台の銀行サーバ３０_２、複数台の管理サーバ２００、複数台の電子マネーサーバ３００が含まれてよい。例えば、カード会社サーバ３０_１は、カード会社毎に存在する。また、銀行サーバ３０_２は、銀行毎に存在する。なお、以下の実施形態では、カード会社サーバ３０_１、および、銀行サーバ３０_２を区別する必要が無い場合には、これらを総称して「金融機関サーバ３０」と表記することにする。

また、全体システム１に含まれる口座管理システム１００は、管理サーバ２００と、電子マネーサーバ３００とを含む。しかしながら、管理サーバ２００と、電子マネーサーバ３００を統合して一台の装置として構成されてもよい。

〔３．管理サーバの構成〕
次に、図３を用いて、実施形態にかかる管理サーバ２００について説明する。図３は、実施形態にかかる管理サーバ２００の構成例を示す図である。図３に示すように、管理サーバ２００は、通信部２１０と、記憶部２２０と、制御部２３０とを有する。

（通信部２１０について）
通信部２１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部２１０は、ネットワークＮと有線または無線で接続され、例えば、端末装置１０、金融機関サーバ３０、電子マネーサーバ３００との間で情報の送受信を行う。

（記憶部２２０について）
記憶部２２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部２２０は、ユーザ情報記憶部２２１と、入出金情報記憶部２２２とを有する。

（ユーザ情報記憶部２２１について）
ユーザ情報記憶部２２１は、ユーザに関する各種情報を記憶する記憶部である。図１で説明したように、会社Ｔは、コンテンツを利用しようとするユーザから事前に、クレジットカードや銀行口座に関する情報の登録を受け付けている。例えば、ユーザ情報記憶部２２１は、このとき、クレジットカードや銀行口座に関する情報とともに受け付けられたユーザに関する各種情報を記憶する。

ここで、図４に実施形態にかかるユーザ情報記憶部２２１の一例を示す。図４の例では、ユーザ情報記憶部１２１は、「ユーザＩＤ」、「住所」、「氏名」、「年齢」、「性別」、「年収」、「家族構成」といった項目を有する。

「ユーザＩＤ」は、ユーザまたはユーザの端末装置１０を識別するための識別情報を示す。「住所」は、対応するユーザの居住地を示す。「氏名」は、対応するユーザの氏名を示す。「年齢」は、対応するユーザの年齢を示す。「性別」は、対応するユーザの性別を示す。「年収」は、対応するユーザの年収を示す。「家族構成」は、対応するユーザの家族構成を示す。

すなわち、図４の例では、ユーザＩＤ「Ｕ１」によって識別されるユーザは、住所「ＡＤＤ１」、氏名「ＮＡ１」、年齢「４０歳」、性別「男」、年収「５５０万」、家族構成「妻と子１人」である例を示す。

なお、図示しないが、ユーザ情報記憶部２２１は、クレジットカードや銀行口座に関する情報も記憶してよい。また、管理サーバ２００は、必ずしもユーザ情報記憶部２２１を有する必要はない。例えば、ユーザに関する各種情報や、クレジットカードおよび銀行口座に関する情報が、管理サーバ２００以外の所定のサーバ装置によって管理されている場合には、管理サーバ２００は、適宜、所定のサーバ装置にアクセスし、必要な情報を参照するだけでもよい。

（入出金情報記憶部２２２について）
入出金情報記憶部２２２は、ユーザによる入出金に関する情報を記憶する記憶部である。例えば、入出金情報記憶部２２２は、カード利用による支払いの履歴情報を出金データとして記憶する。また、入出金情報記憶部２２２は、銀行利用による収支の履歴情報を入金および出金データとして記憶する。例えば、入出金情報記憶部２２２は、銀行口座に振り込まれた金額、すなわち預入金額に関する履歴情報を入金データとして記憶する。また、入出金情報記憶部２２２は、銀行利用により残高から支払われた支払金額に関する履歴情報を出金データとして記憶する。

ここで、図５に実施形態にかかる入出金情報記憶部２２２の一例を示す。図５の例では、入出金情報記憶部１２２は「ユーザＩＤ」、「取引年月日」、「預入金額」、「支払金額」、「概要」、「残高」といった項目を有する。なお、図５に示す入出金情報記憶部１２２は、図１に示したものに対応する。

「ユーザＩＤ」は、ユーザまたはユーザの端末装置１０を識別するための識別情報を示す。「取引年月日」は、カード利用または銀行利用により金融取引（例えば、自口座への入金や、自口座からの支払い等）が行われた年月日を示す。「預入金額」は、ユーザの銀行口座に入金された金額を示す。「支払金額」は、ユーザの銀行口座から支払われた金額を示す。例えば、「支払金額」は、銀行窓口やＡＴＭ利用によりユーザの銀行口座から直接的に支払われた（他の銀行口座への送金等も含む）金額や、カード利用によりユーザの銀行口座から間接的に支払われた金額を示す。

「概要」は、対応する「預入金額」および「支払金額」がどのような内容であるかを簡潔に説明する説明文を示す。「残高」は、対応する「取引年月日」の時点において口座に残されている金額を示す。

例えば、入出金情報記憶部２２２は、ユーザＩＤ「Ｕ１」に、取引年月日「２８−０９−２４」、預入金額「２５０，０００円」、概要「給与、Ｓ株式会社」、残高「７５０，０００円」を対応付けて記憶している。これは、「平成２８年９月２４日」においてユーザＵ１の口座に「２５０，０００円」が振り込まれたことにより、この時点での口座残高が「７５０，０００円」となった例を示す。また、振り込まれた「２５０，０００円」の概要は「Ｓ株式会社からの給与振込」である例を示す。

また、入出金情報記憶部２２２は、ユーザＩＤ「Ｕ１」に、取引年月日「２８−０９−２５」、支払金額「１５，０００円」、概要「カード、公共料金」、残高「７３５，０００円」を対応付けて記憶している。これは、「平成２８年９月２５日」においてユーザＵ１の口座から「１５，０００円」が引き落とされたことにより、この時点での口座残高が「７３５，０００円」となった例を示す。また、引き落とされた「１５，０００円」の概要は「カード利用による公共料金支払」である例を示す。

図３に戻り、制御部２３０は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、管理サーバ２００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部２３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部２３０は、取得部２３１と、判定部２３２と、比較部２３３と、通知部２３４とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部２３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部２３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

（取得部２３１について）
取得部２３１は、金融機関サーバ３０から入金および出金に関する入出金データを取得する。例えば、取得部２３１は、金融機関サーバ３０に定期的にアクセスし、入出金データを取得する。この点について一例を示す。

例えば、取得部２３１は、ユーザ情報記憶部２２１を参照し、ユーザ情報記憶部２２１に登録されているユーザ、すなわち蓄積処理の対象となるユーザ（対象ユーザ）が利用しているクレジットカードや銀行を特定する。また、取得部２３１は、特定したクレジットカードに対応する金融機関サーバ３０を特定する。また、取得部２３１は、特定した銀行に対応する金融機関サーバ３０を特定する。図１では、取得部２３１が、対象ユーザのうちユーザＵ１の利用するクレジットカードに対応する金融機関サーバ３０がカード会社サーバ３０_１であることを特定した例を示す。また、取得部２３１が、ユーザＵ１の利用する銀行に対応する金融機関サーバ３０が銀行サーバ３０_２であることを特定した例を示す。

このように取得部２３１は、対象ユーザに対応する金融機関を特定したうえで、特定した金融機関サーバ３０に定期的にアクセスする。そして、取得部２３１は、金融機関サーバ３０から入出金データを取得し、取得した入出金データを入出金情報記憶部２２２に格納する。

また、取得部２３１は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。例えば、取得部２３１は、後述する判定部２３２により蓄積処理を行うタイミングであると判定された場合に、各対象ユーザの過去口座情報と現在口座情報とを入出金情報記憶部２２２から取得する。

（判定部２３２について）
判定部２３２は、処理を行うタイミングであるか否かを判定する。具体的には、判定部２３２は、対象ユーザへの提案情報の通知を含めた一連の蓄積処理を開始するタイミングであるか否かを判定する。

例えば、所定の期日において、過去口座情報と現在口座情報とを比較し、比較結果が所定の条件を満たす場合に、その所定の期日に提案情報をユーザに通知するよう予め設定されているとする。ここで、所定の期日とは、毎月の所定の期日であるものとする。より具体的には、毎月の所定の期日とは、定期的な入金が行われる日の前日であるものとする。例えば、定期的な入金が行われる日を給料が支給される日（毎月２４日）とすると、判定部２３２は、現在がその前日の２３日であるか否かを判定する。そして、判定部２３２は、２３日であると判定した場合に、取得部２３１に対して蓄積処理を開始するよう指示する。具体的には、判定部２３２は、過去口座情報と現在口座情報とを取得するよう指示する。

また、毎月の所定の期日とは、定期的な出金が行われた後の日であるものとする。例えば、定期的な出金が行われる日を公共料金請求日とすると、判定部２３２は、現在が公共料金請求日の翌日であるか否かを判定する。そして、判定部２３２は、翌日であると判定した場合に、取得部２３１に対して蓄積処理を開始するよう指示する。具体的には、判定部２３２は、過去口座情報と現在口座情報とを取得するよう指示する。

（比較部２３３について）
比較部２３３は、取得部２３１により過去口座情報と現在口座情報とが取得された場合に、過去口座情報と現在口座情報とを比較する比較処理を行う。例えば、比較部２３３は、対象ユーザそれぞれについて、過去口座情報と現在口座情報とを比較し、比較結果が所定の条件を満たすか否かを判定するといった比較処理を行う。なお、本実施形態では、比較対象として、過去口座情報と現在口座情報とをいずれに設定するかによって処理を複数のパターンに分類することができる。後ほどパターン毎の蓄積処理について詳しく説明する。

（通知部２３４について）
通知部２３４は、比較部２３３によって比較結果が所定の条件を満たすと判定された場合に、過去口座情報と現在口座情報とに基づく金額を貯金するよう提案する提案情報を対象ユーザに通知する。例えば、通知部２３４は、提案情報を含むコンテンツであって当該提案情報に承諾することを対象ユーザから受け付け可能なコンテンツを、対象ユーザの操作に拘わらず対象ユーザに通知する。

このようなコンテンツの一例として、図１ではコンテンツＣを例示した。つまり、通知部２３４は、ユーザが提案情報に承諾した場合、ワンタッチで貯金させることができるようなボタン（図１の例では、ボタンＢ）と、過去口座情報と現在口座情報とに基づく金額（図１の例では、３，０００円）を貯金するよう提案する提案情報とを含むコンテンツを、対象ユーザの端末装置１０にプッシュ通知する。

さて、以下では、比較対象毎にパターン分けし、各パターンでの蓄積処理について説明する。第１のパターンは、過去口座情報を現在月より過去のいずれかの月の口座残高とし、現在口座情報を現在月の口座残高とした場合における処理である。第２のパターンは、過去口座情報を現在月より過去のいずれかの月の収入額とし、現在口座情報を現在月の収入額とした場合における処理である。第３のパターンは、過去口座情報を現在月より過去のいずれかの月の公共料金請求額とし、現在口座情報を現在月の公共料金請求額とした場合における処理である。

（第１のパターン）
まず、第１のパターンについて説明する。第１のパターンは、図１で説明した例をより詳細に説明するものである。第１のパターンでは、取得部２３１は、過去口座情報として過去のいずれかの時点における口座残高と、現在口座情報として現時点における口座残高を取得する。そして、比較部２３３は、過去のいずれかの時点における口座残高と、現時点における口座残高とを比較し、比較結果が所定の条件を満たすか否かを判定する。また、通知部２３４は、過去のいずれかの時点における口座残高と、現時点における口座残高との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における口座残高と、現時点における口座残高とに基づく金額を貯金するよう提案する提案情報を通知する。そして、提案情報にユーザが承諾した場合に、後述する蓄積部３３２は、この金額を蓄積する。この点について一例を示す。

例えば、取得部２３１は、過去口座情報として現在月より過去のいずれかの月の口座残高と、現在口座情報として現在月の口座残高とを取得する。そして、比較部２３３は、現在月より過去のいずれかの月の口座残高と、現在月の口座残高とを比較し、比較結果が所定の条件を満たすか否かを判定する。例えば、比較部２３３は、現在月より過去のいずれかの月の口座残高と、現在月の口座残高とを比較し、「現在月の口座残高が現在月より過去のいずれかの月の口座残高より多いこと」といった所定の条件を満たすか否かを判定する。

そして、比較部２３３は、所定の条件を満たすと判定すると、現在月より過去のいずれかの月の口座残高と、現在月の口座残高とに基づく金額を算出する。例えば、比較部２３３は、現在月の口座残高と現在月より過去のいずれかの月の口座残高との差額を算出し、算出した差額を通知部２３４に出力する。

通知部２３４は、所定の条件を満たすと判定されたことにより現在月の口座残高と現在月より過去のいずれかの月の口座残高との差額を受信すると、その差額を貯金するよう提案する提案情報を対象ユーザに通知する。

このような第１のパターンの処理について、図１の例を用いて説明する。なお、本実施形態では、過去のいずれかの月を現在月に対する１ヶ月前の月（先月）であるものとする。また、現在月は、１１月であるものとする。また、対象ユーザをユーザＵ１とする。

まず、判定部２３２は、提案情報の通知を含めた一連の蓄積処理を開始するタイミングとして、現在が定期的な入金が行われる日の前日であるか否かを判定するものとする。具体的には、判定部２３２は、現在日が給料が支給される日（毎月２４日）の前日である２３日であるか否かを判定する。例えば、判定部２３２は、現在日が１１月２３日であると判定すると、取得部２３１に対して取得を行うよう指示する。

取得部２３１は、判定部２３２からの指示を受信すると、ユーザＵ１の過去口座情報として「平成２８年１０月２３日」時点（先月）における口座残高「７５５，０００円」を取得する。また、取得部２３１は、ユーザＵ１の現在口座情報として「平成２８年１１月２３日」時点（現在月）における口座残高「７５８，０００円」を取得する。

次に、比較部２３３は、過去口座情報である先月の口座残高「７５５，０００円」と、現在口座情報である現在月の口座残高「７５８，０００円」とを比較し、所定の条件「現在月の口座残高が先月の口座残高より多いこと」を満たすか否かを判定する。かかる場合、比較部２３３は、比較結果が所定の条件を満たすと判定する。

このように、比較結果が所定の条件を満たすと判定すると、比較部２３３は、現在月の口座残高と先月の口座残高との差額「３，０００円」を算出し、算出した差額「３，０００円」を通知部２３４に出力する。

そして、通知部２３４は、差額「３，０００円」を貯金するよう提案する提案情報をユーザＵ１に通知する。例えば、通知部２３４は、図１に示すように、「１１月２４日は給料日です。残高（３，０００円）を貯金しませんか？」といった提案情報と、押下することにより貯金させることができるボタンＢを含むコンテンツＣを作成する。そして、通知部２３４は、作成したコンテンツＣをユーザＵ１の端末装置１０に配信する。

このように、実施形態にかかる口座管理システム１００は、現在月の口座残高が先月の口座残高より多い場合に、現在月の口座残高と先月の口座残高との差額を貯金しないか提案する。これにより、口座管理システム１００は、ユーザが自由に使うことができると考えられる余剰金を効果的に貯蓄させることができる。

（第２のパターン）
次に、第２のパターンについて説明する。第２のパターンでは、取得部２３１は、過去口座情報として過去のいずれかの時点における収入額と、現在口座情報として現時点における収入額を取得する。そして、比較部２３３は、過去のいずれかの時点における収入額と、現時点における収入額とを比較し、比較結果が所定の条件を満たすか否かを判定する。また、通知部２３４は、過去のいずれかの時点における収入額と、現時点における収入額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における収入額と、現時点における収入額とに基づく金額を貯金するよう提案する提案情報を通知する。そして、提案情報にユーザが承諾した場合に、後述する蓄積部３３２は、この金額を蓄積する。この点について一例を示す。

例えば、取得部２３１は、過去口座情報として現在月より過去のいずれかの月の収入額と、現在口座情報として現在月の収入額とを取得する。そして、比較部２３３は、現在月より過去のいずれかの月の収入額と、現在月の収入額とを比較し、比較結果が所定の条件を満たすか否かを判定する。例えば、比較部２３３は、現在月より過去のいずれかの月の収入額と、現在月の収入額とを比較し、「現在月の収入額が現在月より過去のいずれかの月の収入額より多いこと」といった所定の条件を満たすか否かを判定する。

そして、比較部２３３は、所定の条件を満たすと判定すると、現在月より過去のいずれかの月の収入額と、現在月の収入額とに基づく金額を算出する。例えば、比較部２３３は、現在月の収入額と現在月より過去のいずれかの月の収入額との差額を算出し、算出した差額を通知部２３４に出力する。

通知部２３４は、所定の条件を満たすと判定されたことにより現在月の収入額と現在月より過去のいずれかの月の収入額との差額を受信すると、その差額を貯金するよう提案する提案情報を対象ユーザに通知する。

このような第２のパターンの処理について、一例を用いて説明する。なお、第２のパターンでも、現在月より過去のいずれかの月を現在月に対する１ヶ月前の月（先月）であるものとする。また、収入額は、給与額であるものとする。また、現在月は、１１月であるものとする。また、対象ユーザをユーザＵ１とする。

まず、判定部２３２は、提案情報の通知を含めた一連の蓄積処理を開始するタイミングとして、現在が定期的な入金が行われた時点より後であるか否かを判定するものとする。具体的には、判定部２３２は、現在日が給料が支給される日（毎月２４日）の翌日である２５日であるか否かを判定する。例えば、判定部２３２は、現在日が１１月２５日であると判定すると、取得部２３１に対して取得を行うよう指示する。

ここで、定期的な入金が行われた時点より後に処理を開始するタイミングが設定されるのは、定期的な入金を給与の支給とすると、判定部２３２は、給与が支給された後でないと現在月の給与額を特定することができないためである。

取得部２３１は、判定部２３２からの指示を受信すると、ユーザＵ１の過去口座情報として「平成２８年１０月２４日」時点（先月）における給与額を取得する。ここでは、取得部２３１は、「平成２８年１０月２４日」時点（先月）における給与額「２５０，０００円」を取得したとする。また、取得部２３１は、ユーザＵ１の現在口座情報として「平成２８年１１月２５日」時点（現在月）における給与額を取得する。ここでは、取得部２３１は、「平成２８年１１月２５日」時点（現在月）における給与額「２６０，０００円」を取得したとする。

次に、比較部２３３は、過去口座情報である先月の給与額「２５０，０００円」と、現在口座情報である現在月の給与額「２６０，０００円」とを比較し、所定の条件「現在月の給与額が先月の給与より多いこと」を満たすか否かを判定する。かかる場合、比較部２３３は、比較結果が所定の条件を満たすと判定する。

このように、比較結果が所定の条件を満たすと判定すると、比較部２３３は、現在月の給与額と先月の給与額との差額「１０，０００円」を算出し、算出した差額「１０，０００円」を通知部２３４に出力する。

そして、通知部２３４は、差額「１０，０００円」を貯金するよう提案する提案情報をユーザＵ１に通知する。例えば、通知部２３４は、「給与増加分（１０，０００円）を貯金しませんか？」といった提案情報と、押下することにより貯金させることができるボタンＢを含むコンテンツＣを作成する。そして、通知部２３４は、作成したコンテンツＣをユーザＵ１の端末装置１０に配信する。

このように、実施形態にかかる口座管理システム１００は、現在月の給与額が先月の給与額より多い場合に、現在月の給与額と先月の給与額との差額を貯金しないか提案する。つまり、口座管理システム１００は、例えば、昇給や転職によりユーザの収入が増加したと考えられるタイミングで貯金を提案するため、給与が増えた分ユーザが確保できる余剰金を効果的に貯蓄させることができる。

さて、上記例では、比較対象を先月の給与額、および、現在月の給与額として処理を行う例を示した。しかしながら、取得部２３１は、現在月より過去のいずれかの月の収入額として過去数ヶ月分の給与額と、現在月の給与額を取得してもよい。かかる場合、比較部２３３は、例えば、過去数ヶ月分の給与額を平均した過去平均給与額と、現在月の給与額とを比較し、所定の条件「現在月の給与額が過去平均給与額より多いこと」を満たすか否かを判定する。そして、比較部２３３は、比較結果が所定の条件を満たすと判定すると、現在月の給与額と先月の過去平均給与額との差額を算出し、算出した差額を通知部２３４に出力する。

（第３のパターン）
次に、第３のパターンについて説明する。第３のパターンでは、取得部２３１は、過去口座情報として過去のいずれかの時点における定期的な出金額と、現在口座情報として現時点における定期的な出金額を取得する。そして、比較部２３３は、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額とを比較し、比較結果が所定の条件を満たすか否かを判定する。また、通知部２３４は、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額とに基づく金額を貯金するよう提案する提案情報を通知する。そして、提案情報にユーザが承諾した場合に、後述する蓄積部３３２は、この金額を蓄積する。この点について一例を示す。

例えば、取得部２３１は、過去口座情報として現在月より過去のいずれかの月の公共料金請求額と、現在口座情報として現在月の公共料金請求額とを取得する。そして、比較部２３３は、現在月より過去のいずれかの月の公共料金請求額と、現在月の公共料金請求額とを比較し、比較結果が所定の条件を満たすか否かを判定する。例えば、比較部２３３は、現在月より過去のいずれかの月の公共料金請求額と、現在月の公共料金請求額とを比較し、「現在月の公共料金請求額が現在月より過去のいずれかの月の公共料金請求額より少ないこと」といった所定の条件を満たすか否かを判定する。

そして、比較部２３３は、所定の条件を満たすと判定すると、現在月より過去のいずれかの月の公共料金請求額と、現在月の公共料金請求額とに基づく金額を算出する。例えば、比較部２３３は、現在月の公共料金請求額と現在月より過去のいずれかの月の公共料金請求額との差額を算出し、算出した差額を通知部２３４に出力する。

通知部２３４は、所定の条件を満たすと判定されたことにより現在月の公共料金請求額と現在月より過去のいずれかの月の公共料金請求額との差額を受信すると、その差額を貯金するよう提案する提案情報を対象ユーザに通知する。

このような第３のパターンの処理について、一例を用いて説明する。なお、第３のパターンでも、過去のいずれかの月を現在月に対する１ヶ月前の月（先月）であるものとする。また、現在月は、１１月であるものとする。また、対象ユーザをユーザＵ１とする。

まず、判定部２３２は、提案情報の通知を含めた一連の蓄積処理を開始するタイミングとして、現在が定期的な出金として、公共料金請求が確定した時点より後であるか否かを判定するものとする。具体的には、判定部２３２は、現在日が毎月の公共料金請求（便宜上、毎月２５日とする）の翌日である２６日であるか否かを判定する。例えば、判定部２３２は、現在日が１１月２６日であると判定すると、取得部２３１に対して取得を行うよう指示する。

取得部２３１は、判定部２３２からの指示を受信すると、ユーザＵ１の過去口座情報として「平成２８年１０月２５日」時点（先月）における公共料金請求額を取得する。ここでは、取得部２３１は、「平成２８年１０月２５日」時点（先月）における公共料金請求額「１３，０００円」を取得したとする。また、取得部２３１は、ユーザＵ１の現在口座情報として「平成２８年１１月２５日」時点（現在月）における公共料金請求額を取得する。ここでは、取得部２３１は、「平成２８年１１月２５日」時点（現在月）における公共料金請求額「１０，０００円」を取得したとする。

次に、比較部２３３は、過去口座情報である先月の公共料金請求額「１３，０００円」と、現在口座情報である現在月の公共料金請求額「１０，０００円」とを比較し、所定の条件「現在月の公共料金請求額が先月の公共料金請求額より少ないこと」を満たすか否かを判定する。かかる場合、比較部２３３は、比較結果が所定の条件を満たすと判定する。

このように、比較結果が所定の条件を満たすと判定すると、比較部２３３は、現在月の公共料金請求額と先月の公共料金請求額との差額「３，０００円」を算出し、算出した差額「３，０００円」を通知部２３４に出力する。

そして、通知部２３４は、差額「３，０００円」を貯金するよう提案する提案情報をユーザＵ１に通知する。例えば、通知部２３４は、「公共料金請求額減少分（３，０００円）を貯金しませんか？」といった提案情報と、押下することにより貯金させることができるボタンＢを含むコンテンツＣを作成する。そして、通知部２３４は、作成したコンテンツＣをユーザＵ１の端末装置１０に配信する。

このように、実施形態にかかる口座管理システム１００は、現在月の公共料金請求額が先月の公共料金請求額より少ない場合に、現在月の公共料金請求額と先月の公共料金請求額との差額を貯金しないか提案する。つまり、口座管理システム１００は、公共料金が節約できた分を貯金するよう提案することで、節約によって確保できた余剰金を効果的に貯蓄させることができる。

なお、第３のパターンでも平均額を用いてもよい。具体的には、取得部２３１は、現在月より過去のいずれかの月の公共料金請求額として過去数ヶ月分の公共料金請求額と、現在月の公共料金請求額を取得してもよい。かかる場合、比較部２３３は、例えば、過去数ヶ月分の公共料金請求額を平均した過去平均公共料金請求額と、現在月の公共料金請求額とを比較し、所定の条件「現在月の公共料金請求額が過去平均公共料金請求額より少ないこと」を満たすか否かを判定する。そして、比較部２３３は、比較結果が所定の条件を満たすと判定すると、現在月の公共料金請求額と過去平均公共料金請求額との差額を算出し、算出した差額を通知部２３４に出力する。

なお、上記例では、定期的な出金額の一例として公共料金請求額を用いて説明した。しかしながら、定期的な出金額は、公共料金請求額に限定されるものではなく、例えば、電話料金請求額等であってもよい。

〔４．電子マネーサーバの構成〕
次に、図６を用いて、実施形態にかかる電子マネーサーバ３００について説明する。図６は、実施形態にかかる電子マネーサーバ３００の構成例を示す図である。図６に示すように、電子マネーサーバ３００は、通信部３１０と、記憶部３２０と、制御部３３０とを有する。

（通信部３１０について）
通信部３１０は、例えば、ＮＩＣ等によって実現される。そして、通信部３１０は、ネットワークＮと有線または無線で接続され、例えば、端末装置１０、金融機関サーバ３０、管理サーバ２００との間で情報の送受信を行う。

（記憶部３２０について）
記憶部３２０は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部３２０は、蓄積情報記憶部３２１を有する。

（蓄積情報記憶部３２１について）
蓄積情報記憶部３２１は、管理サーバ２００の通知部２３４によって通知された提案情報に対する対象ユーザの応答に応じて、貯蓄対象金額を蓄積する記憶部である。ここで、貯蓄対象金額とは、通知部２３４により提案された金額（過去口座情報と現在口座情報とに基づく金額）である。

ここで、図７に実施形態にかかる蓄積情報記憶部３２１の一例を示す。図７の例では、蓄積情報記憶部３２１は、「ユーザＩＤ」、「貯蓄日」、「貯蓄額」、「合計貯蓄額」といった項目を有する。なお、図７の蓄積情報記憶部３２１では、上記第１のパターンで示した処理が行われた場合の情報を記憶する例を示す。

「ユーザＩＤ」は、ユーザまたはユーザの端末装置１０を識別するための識別情報を示す。「貯蓄日」は、蓄積情報記憶部３２１への蓄積が行われた日付を示す。「貯蓄額」は、対応する「貯蓄日」において蓄積された金額を示す。「合計貯蓄額」は、対応する「貯蓄日」の時点において、これまでに蓄積された「貯蓄額」の合計を示す。

すなわち、図７の例では、ユーザＵ１が、貯蓄日「平成２８年１１月２３日」において、提案情報に対して承諾することにより「３，０００円」を貯蓄した例を示す。また、貯蓄日「平成２８年１１月２３日」の時点で、ユーザＵ１が、合計「５，０００円」を貯蓄している例を示す。

（制御部３３０について）
図６に戻り、制御部３３０は、ＣＰＵやＭＰＵ等によって、電子マネーサーバ３００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部３３０は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図６に示すように、制御部３３０は、受信部３３１と、蓄積部３３２と、送信部３３３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部３３０の内部構成は、図６に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部３３０が有する各処理部の接続関係は、図６に示した接続関係に限られず、他の接続関係であってもよい。

（受信部３３１について）
受信部３３１は、通知部２３４によって対象ユーザに通知された提案情報に対して、対象ユーザが承諾したことを示す承諾情報を対象ユーザの端末装置１０から受信する受信部である。

図１の例を用いて説明すると、ユーザＵ１によってボタンＢが押下された場合、すなわち、ユーザＵ１が「３，０００円」を貯金することに承諾した場合、端末装置１０は、貯蓄に承諾する旨の情報として、ユーザＩＤ「Ｕ１」と貯蓄対象金額「３，０００円」を含む承諾情報を電子マネーサーバ３００に送信する。受信部３３１は、このようにして送信された承諾情報を受信する。

（蓄積部３３２について）
蓄積部３３２は、比較部２３３によって過去口座情報と現在口座情報との比較結果が所定の条件を満たすと判定された場合に、過去口座情報と現在口座情報とに基づく金額を所定の口座へ蓄積する。具体的には、蓄積部３３２は、比較部２３３によって過去口座情報と現在口座情報との比較結果が所定の条件を満たすと判定されたことにより通知部２３４によって通知された提案情報に対する対象ユーザの承諾が得られた場合に、過去口座情報と現在口座情報とに基づく金額を対象ユーザの口座へ蓄積する。この点について、図１の例（第１のパターン）を用いて説明する。

蓄積部３３２は、ユーザＩＤ「Ｕ１」と貯蓄対象金額「３，０００円」を含む承諾情報が受信されると、ユーザＵ１の利用している銀行に対応するサーバ装置を特定する。図１の例では、蓄積部３３２は、このサーバ装置が銀行サーバ３０_２であることを特定する。そして、蓄積部３３２は、銀行サーバ３０_２のユーザＵ１の口座から貯蓄対象金額「３，０００円」を取得し、取得した「３，０００円」を蓄積情報記憶部３２１に蓄積する。例えば、蓄積部３３２は、取得した「３，０００円」を電子マネーに変換し、蓄積情報記憶部３２１に蓄積する。なお、第２のパターンや第３のパターンが示す処理が行われた場合であっても、蓄積部３３２によって行われる処理に違いは無いため説明を省略する。

（送信部３３３について）
送信部３３３は、蓄積情報記憶部３２１の「合計貯蓄額」を監視し、「合計貯蓄額」が所定額に達した場合に、その旨を管理サーバ２００の通知部２３４に送信する。後述するが、かかる処理は、通知部２３４によって金融商品の提案が行われるようにするためのものである。

〔５．処理手順〕
次に、図８を用いて、実施形態にかかる口座管理システム１００が実行する蓄積処理の手順について説明する。図８は、実施形態にかかる口座管理システム１００による蓄積処理手順を示すフローチャートである。口座管理システム１００は、管理サーバ２００と電子マネーサーバ３００とを有する。管理サーバ２００の取得部２３１は、定期的に金融機関サーバ３０から入出金データを取得し、入出金情報記憶部２３２を更新しているものとする。なお、金融機関サーバ３０から入出金データを取得する処理は、取得部２３１以外の処理部によって行われてもよい。

まず、管理サーバ２００の判定部２３２は、提案情報の通知を行うタイミングであるか否かを判定する（ステップＳ１０１）。例えば、判定部２３２は、現在が定期的な入金（毎月の給与振込）が行われる日の前日であるか否かを判定する。判定部２３２は、提案情報の通知を行うタイミングでない場合（ステップＳ１０１；Ｎｏ）は、提案情報の通知を行うタイミングとなるまで待機する。

一方、取得部２３１は、判定部２３２により提案情報の通知を行うタイミングであると判定されると（ステップＳ１０１；Ｙｅｓ）、入出金情報記憶部２２２から対象ユーザの過去口座情報と現在口座情報とを取得する（ステップＳ１０２）。例えば、取得部２３１は、過去口座情報として先月の口座残高と、現在口座情報として現在月の口座残高とを取得する。

次に、比較部２３３は、過去口座情報と現在口座情報とを比較し、比較結果が所定の条件を満たすか否かを判定する（ステップＳ１０３）。例えば、比較部２３３は、先月の口座残高と現在月の口座残高とを比較し、所定の条件「現在月の口座残高が先月の口座残高より多いこと」を満たすか否かを判定する。

比較部２３３は、比較結果が所定の条件を満たさないと判定した場合には（ステップＳ１０３；Ｎｏ）、処理を終了する。一方、通知部２３４は、比較結果が所定の条件を満たすと判定された場合には（ステップＳ１０３；Ｙｅｓ）、過去口座情報と現在口座情報とに基づく金額を貯金するよう対象ユーザに対して提案する（ステップＳ１０４）。例えば、比較部２３３は、現在月の口座残高と先月の口座残高との差額を貯金するよう対象ユーザに対して提案する。

次に、電子マネーサーバ３００の受信部３３１は、対象ユーザが提案情報に対して承諾したか否かを判定する（ステップＳ１０５）。例えば、受信部３３１は、過去口座情報と現在口座情報とに基づく金額を含む承諾情報を対象ユーザの端末装置１０から受信した場合に、対象ユーザが提案情報に対して承諾したと判定する。

受信部３３１は、対象ユーザが提案情報に対して承諾しないと判定した場合には（ステップＳ１０５；Ｎｏ）、処理を終了する。一方、蓄積部３３２は、対象ユーザが提案情報に対して承諾したと判定された場合には（ステップＳ１０５；Ｙｅｓ）、対象ユーザの銀行口座から貯蓄対象金額を取得する（ステップＳ１０６）。そして、蓄積部３３２は、取得した貯蓄対象金額を対象ユーザの電子マネー口座に蓄積する（ステップＳ１０７）。

〔６．変形例〕
上記実施形態にかかる口座管理システム１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、口座管理システム１００の他の実施形態について説明する。

〔６−１．利用頻度の高い口座から情報取得〕
上記実施形態では、対象ユーザに利用されている銀行は１つであり、取得部２３１は、その銀行に対応する銀行サーバ３０_２から取得された入出金データが記憶される入出金情報記憶部２２２から過去口座情報と現在口座情報とを取得する例を示した。しかしながら、ユーザによっては、複数の銀行口座を有しており、それぞれの口座を会社Ｔに対して登録している場合がある。かかる場合、取得部２３１は、以下の処理を行ってよい。

具体的には、取得部２３１は、ユーザの有する銀行口座のうち、断続的な取引に用いられている銀行口座を特定する。そして、取得部２３１は、特定した銀行口座の入出金データを入出金情報記憶部２２２に格納することで、入出金情報記憶部２２２から過去口座情報と現在口座情報とを取得する。この点について、一例を用いて説明する。

例えば、取得部２３１は、ユーザＵ２が２つの異なる銀行それぞれに１つずつ口座を有していることにより、各銀行に対応するサーバ装置として銀行サーバ３０_２および銀行サーバ３０_３を特定したとする。かかる場合、取得部２３１は、銀行サーバ３０_２および銀行サーバ３０_３においてユーザＵ２の取引履歴を参照し、取引頻度のより高い口座に対応するサーバを特定する。例えば、取得部２３１は、取引頻度のより高い口座に対応するサーバが銀行サーバ３０_２であると特定したとすると、銀行サーバ３０_２から定期的に入出金データを取得し、入出金情報記憶部２２２に格納する。

これにより、取得部２３１は、断続的な取引に用いられている、すなわち利用頻度がより高いと特定された口座における過去口座情報と現在口座情報とを取得する。また、このような過去口座情報と現在口座情報とがこれまで説明してきた蓄積処理に用いられる。このため、口座管理システム１００は、ユーザがあまり利用していないと考えられる口座における入出金データを用いて、蓄積処理を行ってしまうといった無駄な処理を行ってしまうことを防止することができる。また、口座管理システム１００は、利用頻度の高い口座における入出金データを用いて、蓄積処理を行うことができるため、高精度な提案を行うことができる。

〔６−２．金融商品の案内通知（１）〕
また、管理サーバ２００の通知部２３４は、金融商品の購入を提案する案内情報を対象ユーザに通知してもよい。具体的には、通知部２３４は、蓄積部３３２により蓄積された合計貯蓄額に基づいて、対象ユーザに金融商品の案内情報を通知する。例えば、通知部２３４は、蓄積部３３２により蓄積された合計貯蓄額が所定額に達した対象ユーザに金融商品の案内情報を通知する。

例えば、電子マネーサーバ３００の送信部３３３は、蓄積情報記憶部３２１の「合計貯蓄額」を監視し、「合計貯蓄額」が所定額に達した場合に、そのユーザのユーザＩＤを通知部２３４に送信する。これにより、例えば、通知部２３４は、ユーザＵ１の「合計貯蓄額」が所定額に達したことを認識すると、ユーザＵ１に金融商品の購入を提案する案内情報を通知する。

一例を示すと、通知部２３４は、「あなたの電子マネーが「５万円」になりました。以下の金融商品を購入することができます」といった案内テキストとともに、例えば、投資信託、株式、保険等の金融商品が一覧表示されるコンテンツを作成する。そして、通知部２３４は、作成したコンテンツをユーザＵ１の端末装置１０に配信する。

ここで、「合計貯蓄額」は、ユーザが比較的自由に使うことのできるお金が蓄積された資金である。このため、「合計貯蓄額」を利用した金融商品の購入を提案することで、口座管理システム１００は、ユーザに対してより気軽に金融商品を購入させることができるため、効果的にユーザの資金を増やすことができる。

〔６−３．金融商品の案内通知（２）〕
また、通知部２３４は、ユーザの有する口座のうち、断続的な取引に用いられていないと特定された口座において所定期間、所定額以上の金額が貯蓄されている場合には、当該ユーザに金融商品の案内情報を通知してもよい。

変形例６−１では、取得部２３１が、ユーザが複数の銀行口座を有している場合、その銀行口座のうち断続的な取引に用いられている口座、すなわちより利用頻度の高い口座を特定し、特定したより利用頻度の高い口座の入出金データで入出金情報記憶部２２２を構築する例を示した。また、このような入出金情報記憶部２２２から過去口座情報と現在口座情報を取得することで、蓄積処理が行われることを示した。

ここで、取得部２３１は、断続的な取引に用いられていない、すなわち利用頻度の低い銀行口座も自ずと特定することになる。したがって、通知部２３４は、利用頻度の低い銀行口座が特定された場合、かかる銀行口座において所定期間、所定額以上の金額が貯蓄されているか否かを判定する。所定期間や所定額は、予め任意に設定されて良いものである。

そして、通知部２３４は、利用頻度の低い銀行口座において所定期間、所定額以上の金額が貯蓄されていると判定した場合、その銀行口座を有する対象ユーザに金融商品の案内情報を通知する。ここで、利用頻度は低いが所定期間、所定額以上の金額が貯蓄されている口座は、貯蓄専用に設けられた口座であり、こういった口座に貯蓄されている資金は、日常の生活費等には利用されていない可能性が高い。また、このような口座を所有しているユーザは、貯蓄意欲が高いといえる。したがって、実施形態にかかる口座管理システム１００は、金融商品を案内することで、金融商品を効果的に購入させることができるとともに、ユーザの資金をより増やすことができる。

〔６−４．自動で貯蓄〕
ユーザによっては、例えば、毎月の収入があったとしてもその月のうちに口座残高の全額を消費してしまったり、口座残高の全額を消費せずとも、毎月振込みが行われる直前には残高がわずか「例えば、５００円以下」しか残らないといった場合がある。このようなユーザに対しては、上述してきた差額を算出できなかったり、差額が算出できたとしても数円、あるいは、数十円といったもので、差額を貯蓄するよう提案することが困難な場合がある。

そこで、通知部２３４は、銀行口座の残高が所定額より少ないユーザに対して、月々所定額を自動で貯金させることができるサービスを提案してもよい。例えば、通知部２３４は、入出金情報記憶部２２２を参照し、例えば、所定の期間（例えば、半年間）、銀行口座の残高が所定額（例えば、５００円）より少ないユーザを特定する。そして、通知部２３４は、「毎月、残高から「１，０００円」を自動貯金するサービスをご提供」といった案内情報と、サービス提供を受けることに承諾するボタンとを含むコンテンツを作成する。そして、通知部２３４は、作成したコンテンツを特定したユーザの端末装置１０に配信する。

これにより、実施形態にかかる口座管理システム１００は、残高が少なくまとまった資金をつくることが困難であると考えられるユーザに対して、まとまった資金をつくることができるようなきっかけを与えることができる。

〔６−５．他のユーザとの比較〕
上記実施形態では、口座管理システム１００が、対象ユーザそれぞれについて、当該対象ユーザの過去口座情報と現在口座情報とを取得し、過去口座情報と現在口座情報との比較結果が所定の条件を満たす場合に通知を行う例を示した。しかし、口座管理システム１００は、対象ユーザの口座情報と、当該対象ユーザとは異なる他のユーザであって当該対象ユーザと同一属性のユーザの口座情報とを取得し、これらの口座情報を比較した比較結果が所定の条件を満たす場合に通知を行ってもよい。

ここで、対象ユーザをユーザＵ１としてより具体的に説明する。例えば、取得部２３１は、ユーザＵ１とは異なる他のユーザであってユーザＵ１と同一属性のユーザを特定する。例えば、属性を年代とすると、取得部２３１は、ユーザ情報記憶部２２１を参照し、ユーザＵ１と同年代のユーザを特定する。ここでは、取得部２３１は、ユーザＵ１と同年代のユーザとしてユーザＵ２を特定したとする。

次に、取得部２３１は、ユーザＵ１の現在の口座情報である現在口座情報（「現在口座情報Ａ」とする）と、ユーザＵ２の現在の口座情報である現在口座情報（「現在口座情報Ｂ」とする）とを入出金情報記憶部２２２から取得する。例えば、取得部２３１は、現在口座情報ＡとしてユーザＵ１の現在月の口座残高を取得する。また、取得部２３１は、現在口座情報ＢとしてユーザＵ２の現在月の口座残高を取得する。

かかる場合、比較部２３３は、ユーザＵ１の現在月の口座残高がユーザＵ２の現在月の口座残高より高いか否かを判定し、高いと判定した場合には、ユーザＵ１の現在月の口座残高がユーザＵ２の現在月の口座残高との差額（「現在口座情報Ａ」と「現在口座情報Ｂ」とに基づく金額）を通知部２３４に出力する。そして、通知部２３４は、比較部２３３から受信した差額を貯金するよう提案する提案情報をユーザＵ１に対して通知する。

また、蓄積部３３２は、提案情報に対するユーザＵ１の承諾が得られた場合には、差額分の資金をユーザＵ１の銀行口座から取得し、電子マネー口座（蓄積情報記憶部３２１）に蓄積する。

このように、口座管理システム１００は、対象ユーザの口座残高が同一属性の他のユーザの口座残高より高い場合、高い残高を有している分を貯金させることができるため、効果的に貯蓄させることができる。また、例えば、通知部２３４が、「あなたは同年代のユーザよりも多くの残金を有しています。そんなあなたは貯蓄でさらに資金を増やしませんか？」といった同属性のユーザとの比較結果を知らせるような提案情報とすることで、効果的に貯蓄させることができる。

また、上記例では、説明を簡単にするために、対象ユーザと同一属性のユーザとして１人のユーザを特定した例を示した。しかしながら、取得部２３１は、例えば、対象ユーザと同一属性のユーザを複数人特定し、特定したユーザそれぞれの現在月の口座残高を取得してもよい。これにより、比較部２３３は、対象ユーザと同一属性のユーザそれぞれの現在月の口座残高を平均した平均残高と、対象ユーザの現在月の口座残高とを比較し、また、通知部２４４は、対象ユーザの現在月の口座残高が平均残高より高い場合に、対象ユーザの現在月の口座残高と平均残高との差額を貯金するよう提案する。

また、かかる変形例では、上述した第１のパターンに沿った処理（比較対象が口座残高）を示したが、第２のパターンに沿った処理（比較対象が給与額）や、第３のパターンに沿った処理（比較対象が公共料金請求額）であってもよい。

〔６−６．貯蓄対象金額について〕
上記実施形態では、通知部２３４が、過去口座情報と現在口座情報との比較結果が所定の条件を満たす場合に、過去口座情報と現在口座情報とに基づく金額を所定の口座へ貯金するよう提案する提案情報をユーザに通知する例を示した。具体的には、通知部２３４が、過去口座情報と現在口座情報とに基づく金額として、現在月の口座残高と先月の口座残高との差額、現在月の収入額と先月の収入額との差額、あるいは、現在月の公共料金請求額と先月の公共料金請求額との差額を貯金するよう提案する例を示した。

ここで、このような差額（特に、現在月の口座残高と先月の口座残高との差額）が電子マネー口座への貯蓄に回された場合、ユーザの銀行口座には資金が蓄積されていかないことが考えられる。したがって、通知部２３４は、差額に対する所定割合分の金額を貯金するよう提案してもよい。また、通知部２３４は、差額に応じた所定割合分の金額を貯金するよう提案してもよい。

一例を示すと、例えば、現在月の口座残高と先月の口座残高との差額が「３，０００円」である場合には、通知部２３４は、差額「３，０００円」に対する５０％の「１，５００円」を貯金するよう提案する。また、例えば、現在月の口座残高と先月の口座残高との差額が「１５，０００円」である場合には、通知部２３４は、差額「１５，０００円」に対する３０％の「４，５００円」を貯金するよう提案する。

これにより、口座管理システム１００は、ユーザの銀行口座にお金が貯まらなくなるといったことを防止することができる。なお、上記例では、差額が高いほど差額に対する割合が低くなる例を示したが、差額が高いほど差額に対する割合を高くしてもよい。

〔７．ハードウェア構成〕
また、上述してきた各実施形態にかかる管理サーバ２００および電子マネーサーバ３００は、例えば図９に示すような構成のコンピュータ１０００によって実現される。以下、管理サーバ２００を例に挙げて説明する。図９は、管理サーバ２００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、通信網５０を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５０を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを、入出力インターフェイス１６００を介して出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態にかかる管理サーバ２００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部２３０の機能を実現する。また、ＨＤＤ１４００には、記憶部２２０内のデータが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを、記録媒体１８００から読み取って実行するが、他の例として、他の装置から、通信網５０を介してこれらのプログラムを取得してもよい。

また、例えば、コンピュータ１０００が実施形態にかかる電子マネーサーバ３００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部３３０の機能を実現する。

〔８．その他〕
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上述してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔９．効果〕
実施形態にかかる口座管理理ステム１００は、取得部２３１と、蓄積部３３２とを有する。取得部２３１は、過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する。蓄積部３３２は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす場合に、過去口座情報と、現在口座情報とに基づく金額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、ユーザに対して無理なく効率的に貯蓄させることができる。

実施形態にかかる口座管理理ステム１００は、通知部２３４を有する。通知部２３４は、比較結果が所定の条件を満たす場合に、過去口座情報と、現在口座情報とに基づく金額を所定の口座へ貯金するよう提案する提案情報をユーザに通知する。そして、蓄積部３３２は、提案情報に対するユーザの承諾が得られた場合に、金額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、ユーザに対して無理なく効率的に貯蓄させることができる。

また、通知部２３４は、提案情報を含むコンテンツであって当該提案情報に承諾することを前記ユーザから受け付け可能なコンテンツを、ユーザの操作に拘わらずユーザに通知する。そして、蓄積部３３２は、コンテンツを介して、提案情報に対するユーザの承諾が受け付られた場合に、金額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、ワンタッチで手軽に貯金させることができるため、効率的に貯蓄させることができる。

また、取得部２３１は、過去口座情報として過去のいずれかの時点における口座残高と、現在口座情報として現時点における口座残高を取得する。そして、蓄積部３３２は、過去のいずれかの時点における口座残高と、現時点における口座残高との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における口座残高と、現時点における口座残高とに基づく金額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、ユーザが自由に使うことができると考えられる余剰金を効果的に貯蓄させることができる。

また、蓄積部３３２は、所定の条件として、現時点における口座残高が前記過去のいずれかの時点における口座残高より多い場合に、現時点における口座残高と過去のいずれかの時点における口座残高との差額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、ユーザが自由に使うことができると考えられる余剰金を効果的に貯蓄させることができる。

また、取得部２３１は、過去口座情報として過去のいずれかの時点における収入額と、現在口座情報として現時点における収入額とを取得する。そして、蓄積部３３２は、過去のいずれかの時点における収入額と、現時点における収入額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における収入額と、現時点における収入額とに基づく金額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、昇給や転職によりユーザの収入が増加したと考えられる場合に貯金させることができるため、収入が増えた分ユーザが確保できる余剰金を効果的に貯蓄させることができる。

また、蓄積部３３２は、所定の条件として、現時点における収入額が過去のいずれかの時点における収入額より多い場合に、現時点における収入額と過去のいずれかの時点における収入額との差額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、昇給や転職によりユーザの収入が増加したと考えられる場合に貯金させることができるため、収入が増えた分ユーザが確保できる余剰金を効果的に貯蓄させることができる。

また、取得部２３１は、過去口座情報として過去のいずれかの時点における定期的な出金額と、現在口座情報として現時点における定期的な出金額とを取得する。そして、蓄積部３３２は、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額との比較結果が所定の条件を満たす場合に、過去のいずれかの時点における定期的な出金額と、現時点における定期的な出金額とに基づく金額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、例えば、節約によって確保できたと考えられる余剰金を効果的に貯金させることができる。

蓄積部３３２は、所定の条件として、現時点における定期的な出金額が過去のいずれかの時点における定期的な出金額より少ない場合に、現時点における定期的な出金額と過去のいずれかの時点における定期的な出金額との差額を所定の口座へ蓄積する。

これにより、実施形態にかかる口座管理理ステム１００は、例えば、節約によって確保できたと考えられる余剰金を効果的に貯蓄させることができる。

また、通知部２３４は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす場合に、所定のタイミングで提案情報をユーザに通知する。

これにより、実施形態にかかる口座管理理ステム１００は、例えば、ユーザが貯金することをより決断し易いタイミングで通知を行うことができる。

また、通知部２３４は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす月の所定の期日に提案情報をユーザに通知する。

これにより、実施形態にかかる口座管理理ステム１００は、例えば、ユーザが貯金することをより決断し易いタイミングで通知を行うことができる。

また、通知部２３４は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす月において定期的な出金が行われた後に提案情報をユーザに通知する。

これにより、実施形態にかかる口座管理理ステム１００は、ユーザに対して余剰金が生まれたことが確定できるタイミングで通知を行うことができるため、効果的に貯金させることができる。

また、通知部２３４は、過去口座情報と、現在口座情報との比較結果が所定の条件を満たす月において定期的な入金が行われる前に提案情報をユーザに通知する。

これにより、実施形態にかかる口座管理理ステム１００は、例えば、給料日前に通知を行うことができるため、貯金してもすぐに給料が支給されるため資金には困らないといった安心感を与えることができるため、効果的に貯金させることができる。

また、通知部２３４は、蓄積部３３２により蓄積された貯蓄金額に基づいて、ユーザに金融商品の案内情報を通知する。

これにより、実施形態にかかる口座管理理ステム１００は、ユーザに対してより気軽に金融商品を購入させることができるため、効果的にユーザの資金を増やすことができる。

通知部２３４は、ユーザの有する口座のうち、断続的な取引に用いられていないと特定された口座において所定期間、所定額以上の金額が貯蓄されている場合には、当該ユーザに金融商品の案内情報を通知する。

これにより、実施形態にかかる口座管理理ステム１００は、例えば、資金を貯め込んでいると考えられるユーザに対して金融商品を案内することで、金融商品を効果的に購入させることができるとともに、ユーザの資金をより増やすことができる。

取得部２３１は、ユーザの有する口座のうち、断続的な取引に用いられていると特定された口座における過去口座情報と、現在口座情報とを取得する。

これにより、実施形態にかかる口座管理理ステム１００は、ユーザがあまり利用していないと考えられる口座における入出金データを用いて、蓄積処理を行ってしまうといった無駄な処理を行ってしまうことを防止することができる。

以上、本願の実施形態をいくつかの図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 全体システム
１０ 端末装置
３０ 金融機関サーバ
１００ 口座管理システム
２００ 管理サーバ
２２２ 入出金情報記憶部
２３０ 制御部
２３１ 取得部
２３２ 判定部
２３３ 比較部
２３４ 通知部
３００ 電子マネーサーバ
３２１ 蓄積情報記憶部
３３０ 制御部
３３２ 蓄積部

Claims (18)

1. 過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する取得部と、
   前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす場合に、前記過去口座情報と、前記現在口座情報とに基づく金額を所定の口座へ蓄積する蓄積部と
   を有することを特徴とする口座管理システム。
2. 前記比較結果が所定の条件を満たす場合に、前記過去口座情報と、前記現在口座情報とに基づく金額を所定の口座へ貯金するよう提案する提案情報をユーザに通知する通知部をさらに有し、
   前記蓄積部は、前記提案情報に対するユーザの承諾が得られた場合に、前記金額を所定の口座へ蓄積する
   ことを特徴とする請求項１に記載の口座管理システム。
3. 前記通知部は、前記提案情報を含むコンテンツであって当該提案情報に承諾することを前記ユーザから受け付け可能なコンテンツを、前記ユーザの操作に拘わらずユーザに通知し、
   前記蓄積部は、前記コンテンツを介して、前記提案情報に対するユーザの承諾が受け付られた場合に、前記金額を所定の口座へ蓄積する
   ことを特徴とする請求項２に記載の口座管理システム。
4. 前記取得部は、過去口座情報として過去のいずれかの時点における口座残高と、前記現在口座情報として現時点における口座残高を取得し、
   前記蓄積部は、前記過去のいずれかの時点における口座残高と、前記現時点における口座残高との比較結果が所定の条件を満たす場合に、前記過去のいずれかの時点における口座残高と、前記現時点における口座残高とに基づく金額を所定の口座へ蓄積する
   ことを特徴とする請求項１〜３のいずれか１つに記載の口座管理システム。
5. 前記蓄積部は、前記所定の条件として、前記現時点における口座残高が前記過去のいずれかの時点における口座残高より多い場合に、前記現時点における口座残高と前記過去のいずれかの時点における口座残高との差額を所定の口座へ蓄積する
   ことを特徴とする請求項４に記載の口座管理システム。
6. 前記取得部は、過去口座情報として過去のいずれかの時点における収入額と、現在口座情報として現時点における収入額とを取得し、
   前記蓄積部は、前記過去のいずれかの時点における収入額と、前記現時点における収入額との比較結果が所定の条件を満たす場合に、前記過去のいずれかの時点における収入額と、前記現時点における収入額とに基づく金額を所定の口座へ蓄積する
   ことを特徴とする請求項１〜３のいずれか１つに記載の口座管理システム。
7. 前記蓄積部は、前記所定の条件として、前記現時点における収入額が前記過去のいずれかの時点における収入額より多い場合に、前記現時点における収入額と前記過去のいずれかの時点における収入額との差額を所定の口座へ蓄積する
   ことを特徴とする請求項６に記載の口座管理システム。
8. 前記取得部は、過去口座情報として過去のいずれかの時点における定期的な出金額と、現在口座情報として現時点における定期的な出金額とを取得し、
   前記蓄積部は、前記過去のいずれかの時点における定期的な出金額と、前記現時点における定期的な出金額との比較結果が所定の条件を満たす場合に、前記過去のいずれかの時点における定期的な出金額と、前記現時点における定期的な出金額とに基づく金額を所定の口座へ蓄積する
   ことを特徴とする請求項１〜３のいずれか１つに記載の口座管理システム。
9. 前記蓄積部は、前記所定の条件として、前記現時点における定期的な出金額が前記過去のいずれかの時点における定期的な出金額より少ない場合に、前記現時点における定期的な出金額と前記過去のいずれかの時点における定期的な出金額との差額を所定の口座へ蓄積する
   ことを特徴とする請求項８に記載の口座管理システム。
10. 前記通知部は、前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす場合に、所定のタイミングで前記提案情報をユーザに通知する
    ことを特徴とする請求項２または３に記載の口座管理システム。
11. 前記通知部は、前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす月の所定の期日に前記提案情報をユーザに通知する
    ことを特徴とする請求項１０に記載の口座管理システム。
12. 前記通知部は、前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす月において定期的な出金が行われた後に前記提案情報をユーザに通知する
    ことを特徴とする請求項１０または１１に記載の口座管理システム。
13. 前記通知部は、前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす月において定期的な入金が行われる前に前記提案情報をユーザに通知する
    ことを特徴とする請求項１０または１１に記載の口座管理システム。
14. 前記通知部は、前記蓄積部により蓄積された貯蓄金額に基づいて、ユーザに金融商品の案内情報を通知する
    ことを特徴とする請求項２、３、１０〜１３のいずれか１つに記載の口座管理システム。
15. 前記通知部は、ユーザの有する口座のうち、断続的な取引に用いられていないと特定された口座において所定期間、所定額以上の金額が貯蓄されている場合には、当該ユーザに金融商品の案内情報を通知する
    ことを特徴とする請求項１４に記載の口座管理システム。
16. 前記取得部は、ユーザの有する口座のうち、断続的な取引に用いられていると特定された口座における前記過去口座情報と、前記現在口座情報とを取得する
    ことを特徴とする請求項１〜１５のいずれか１つに記載の口座管理システム。
17. 口座管理システムで実行される口座管理方法であって、
    過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する取得工程と、
    前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす場合に、前記過去口座情報と、前記現在口座情報とに基づく金額を所定の口座へ蓄積する蓄積工程と
    を含んだことを特徴とする口座管理方法。
18. 過去の所定の時点における口座情報である過去口座情報と、現在の口座情報である現在口座情報とを取得する取得工程と、
    前記過去口座情報と、前記現在口座情報との比較結果が所定の条件を満たす場合に、前記過去口座情報と、前記現在口座情報とに基づく金額を所定の口座へ蓄積する蓄積工程と
    をコンピュータに実行させることを特徴とする口座管理プログラム。

Images