(57)【要約】【課題】資金移動の回数を少なくしつつ、ユーザの資金運用の承諾を得やすくすること。【解決手段】支払額取得部２０１は、商取引における支払額を取得する。差額算出部２０２は、取得された支払額とその支払額を切り上げた額との差額を算出する。差額取得部２０３は、算出された差額を取得する。承諾要求部２０６は、第１の期間になされた１以上の商取引における差額を資金運用に充てることについての承諾をユーザに要求する。資金移動時期判断部２０９は、第１の期間を複数含む第２の期間が経過すると、資金運用の承諾を得られた差額の累積額を第１の口座から第２の口座に移動する移動時期になったと判断する。移動指示処理実行部２１０は、その累積額の移動を指示する移動指示処理を実行する。【選択図】図４
2018097831.tif 000002
【特許請求の範囲】
【請求項１】
商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部と
を備える情報処理装置。
【請求項２】
前記蓄積部は、前記支払額と当該支払額を切り上げた額との差額を前記金額として蓄積する
請求項１に記載の情報処理装置。
【請求項３】
前記承諾の撤回を受け付ける受付部を備え、
前記実行部は、前記承諾が得られてから前記処理を実行する前に当該承諾の撤回が受け付けられた場合、当該承諾が撤回された前記金額を前記累積額から減じて前記処理を実行する
請求項１又は２に記載の情報処理装置。
【請求項４】
前記蓄積部は、前記累積額を前記第１の口座から前記第２の口座へ移動する際に必要な手続きが完了する前になされた商取引における前記金額を蓄積し、
前記実行部は、前記手続きが完了した後に前記処理を実行する
請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
前記承諾要求部は、前記手続きが完了する前に前記要求を行う
請求項４に記載の情報処理装置。
【請求項６】
前記第１の期間は、蓄積された前記金額の累積額が閾値未満になっている期間である  請求項１から５のいずれか１項に記載の情報処理装置。
【請求項７】
前記ユーザに関する関連情報を取得する関連情報取得部を備え、
前記閾値として、取得された前記関連情報に応じた値が用いられる
請求項６に記載の情報処理装置。
【請求項８】
前記ユーザに関する関連情報を取得する関連情報取得部を備え、
前記承諾要求部は、取得された前記関連情報に応じた期間が前記第１の期間として経過するごとに前記要求を行う
請求項１から７のいずれか１項に記載の情報処理装置。
【請求項９】
前記ユーザに関する関連情報を取得する関連情報取得部を備え、
前記実行部は、取得された前記関連情報に応じた期間が前記第２の期間として経過すると、前記処理を実行する
請求項１から８のいずれか１項に記載の情報処理装置。
【請求項１０】
前記承諾要求部は、前記支払額に基づき算出される金額のうち、所定の条件を満たす商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求する
請求項１から９のいずれか１項に記載の情報処理装置。
【請求項１１】
前記所定の条件は、購入対象、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である場合に満たされる
請求項１０に記載の情報処理装置。
【請求項１２】
前記承諾要求部は、購入対象、購入先及び決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する
請求項１１に記載の情報処理装置。
【請求項１３】
前記承諾要求部は、前記所定の条件を満たす商取引が予め定められた期間に行われた場合に、当該商取引について算出された金額を、当該期間以外に行われた商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する
請求項１０から１２のいずれか１項に記載の情報処理装置。
【請求項１４】
商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額を、当該累積額の集金を代行する事業者に通知する通知部と
を備える情報処理装置。
【請求項１５】
ユーザが受け取った受取額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前に受け取った１以上の受取額における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部と
を備える情報処理装置。
【請求項１６】
請求項１から１５のいずれか１項に記載の情報処理装置と、
前記情報処理装置から前記金額を資金運用に充てることについての承諾を要求された場合に当該要求を表示する表示部と、当該要求が表示されて前記資金運用を承諾する操作が行われた場合にその旨を前記情報処理装置に通知する通知部とを備えるユーザ端末と
を備える情報処理システム。
【請求項１７】
ユーザ端末を、
商取引における支払額に基づき算出される金額を資金運用に充てることについて承諾し又は拒否する操作を受け付ける受付部と、
受け付けられた前記操作の結果を通知する通知部と、
前記資金運用を承諾する操作が受け付けられた場合、当該資金運用に充てられる資金の情報を記憶する記憶部
として機能させるためのプログラム。
【請求項１８】
情報処理装置が、商取引における支払額に基づき算出される金額を蓄積するステップと、
情報処理装置が、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求するステップと、
情報処理装置が、前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行するステップと
を備える情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザに資金を活用してもらうための技術に関する。
【背景技術】
【０００２】
ユーザに資金を活用してもらうための技術がある。例えば特許文献１には、釣り銭とこの釣り銭を受け取るべき者に関するデータを登録しておき、投資サーバが、ＡＴＭ端末などから投資を行う旨の情報を受信するとこの情報に基づいて投資関連運用事業者側システムにアクセスし、投資関連運用事業者側システムが所定の投資処理を行う技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−１７８１９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ユーザの資金運用は、ユーザの承諾を得たうえで、ユーザの口座に入っている資金をしかるべき別の口座（投資事業者の口座等）に移してから行われることが一般的である。しかし、口座間で資金を移動させると手数料が発生するので、資金の移動はなるべく少ないことが望ましい。かといって移動させる額が大きくなると、資金運用に対する心理的な抵抗がユーザに生じやすくなる。
そこで、本発明は、資金移動の回数を少なくしつつ、ユーザの資金運用の承諾を得やすくすることを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するために、本発明は、商取引における支払額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部とを備える情報処理装置を提供する。
【０００６】
また、前記蓄積部は、前記支払額と当該支払額を切り上げた額との差額を前記金額として蓄積してもよい。
さらに、前記承諾の撤回を受け付ける受付部を備え、前記実行部は、前記承諾が得られてから前記処理を実行する前に当該承諾の撤回が受け付けられた場合、当該承諾が撤回された前記金額を前記累積額から減じて前記処理を実行してもよい。
【０００７】
また、前記蓄積部は、前記累積額を前記第１の口座から前記第２の口座へ移動する際に必要な手続きが完了する前になされた商取引における前記金額を蓄積し、前記実行部は、前記手続きが完了した後に前記処理を実行してもよい。
さらに、前記承諾要求部は、前記手続きが完了する前に前記要求を行ってもよい。
また、前記第１の期間は、蓄積された前記金額の累積額が閾値未満になっている期間であってもよい。
【０００８】
また、前記ユーザに関する関連情報を取得する関連情報取得部を備え、前記閾値として、取得された前記関連情報に応じた値が用いられてもよい。
さらに、前記ユーザに関する関連情報を取得する関連情報取得部を備え、前記承諾要求部は、取得された前記関連情報に応じた期間が前記第１の期間として経過するごとに前記要求を行ってもよい。
また、前記ユーザに関する関連情報を取得する関連情報取得部を備え、前記実行部は、取得された前記関連情報に応じた期間が前記第２の期間として経過すると、前記処理を実行してもよい。
【０００９】
また、前記承諾要求部は、前記支払額に基づき算出される金額のうち、所定の条件を満たす商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求してもよい。
さらに、前記所定の条件は、購入対象、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である場合に満たされてもよい。
【００１０】
また、前記承諾要求部は、購入対象、購入先及び決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求してもよい。
さらに、前記承諾要求部は、前記所定の条件を満たす商取引が予め定められた期間に行われた場合に、当該商取引について算出された金額を、当該期間以外に行われた商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求してもよい。
【００１１】
また、本発明は、商取引における支払額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額を、当該累積額の集金を代行する事業者に通知する通知部とを備える情報処理装置を提供する。
【００１２】
また、本発明は、ユーザが受け取った受取額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前に受け取った１以上の受取額における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部とを備える情報処理装置を提供する。
【００１３】
また、本発明は、上記の情報処理装置と、前記情報処理装置から前記金額を資金運用に充てることについての承諾を要求された場合に当該要求を表示する表示部と、当該要求が表示されて前記資金運用を承諾する操作が行われた場合にその旨を前記情報処理装置に通知する通知部とを備えるユーザ端末とを備える情報処理システムを提供する。
【００１４】
また、本発明は、ユーザ端末を、商取引における支払額に基づき算出される金額を資金運用に充てることについて承諾し又は拒否する操作を受け付ける受付部と、受け付けられた前記操作の結果を通知する通知部と、前記資金運用を承諾する操作が受け付けられた場合、当該資金運用に充てられる資金の情報を記憶する記憶部として機能させるためのプログラムを提供する。
【００１５】
また、本発明は、情報処理装置が、商取引における支払額に基づき算出される金額を蓄積するステップと、情報処理装置が、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求するステップと、情報処理装置が、前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行するステップとを備える情報処理方法を提供する。
【発明の効果】
【００１６】
本発明によれば、資金移動の回数を少なくしつつ、ユーザの資金運用の承諾を得やすくすることができる。
【図面の簡単な説明】
【００１７】
【図１】実施例に係る資金運用支援システムの全体構成を表す図
【図２】家計簿サーバ装置及び資金運用支援サーバ装置のハードウェア構成を表す図
【図３】ユーザ端末のハードウェア構成を表す図
【図４】資金運用支援システムが実現する機能構成を表す図
【図５】蓄積されている差額の一例を表す図
【図６】表示された承諾要求の一例を表す図
【図７】表示された差額の履歴の一例を表す図
【図８】蓄積処理における各装置の動作手順の一例を表す図
【図９】運用支援処理における各装置の動作手順の一例を表す図
【図１０】変形例の資金運用支援システムが実現する機能構成を表す図
【図１１】変形例のユーザ端末が実現する機能構成を表す図
【図１２】変形例の資金運用支援サーバ装置が実現する機能構成の一例を表す図
【図１３】第１閾値テーブルの一例を表す図
【図１４】第１の期間テーブルの一例を表す図
【図１５】第２の期間テーブルの一例を表す図
【図１６】変形例の資金運用支援システムが実現する機能構成の一例を表す図
【図１７】変形例で蓄積されている差額の一例を表す図
【図１８】表示された承諾要求の一例を表す図
【図１９】変形例の資金運用支援サーバ装置が実現する機能構成の一例を表す図
【発明を実施するための形態】
【００１８】
以下、本発明の具体的な実施例について説明するが、本発明は、その技術的思想に含まれるものであれば種々変形、変更することが可能であり、以下の実施例に限定されるものではない。
【００１９】
［１］実施例
図１は実施例に係る資金運用支援システム１の全体構成を表す。資金運用支援システム１は、商取引においてユーザがお金を支払った際に生じるお釣りを資金運用に充てることを支援するシステムである。ここでいうユーザは、お釣りを資金運用に充てるお釣り運用サービスを利用するユーザであり、資金運用支援システム１において登録されているユーザである。資金運用支援システム１は、このお釣り運用サービスを提供する事業者が中心となって運用されている。
【００２０】
資金運用とは、利益を得る目的で資金を運用することであり、具体的には、株式、ＦＸ（Foreign Exchange：外国為替証拠金取引）、債券、投資信託、不動産、先物、金相場、預金及び外貨預金等を行うことである。
【００２１】
商取引におけるお金の支払いとは、例えば店舗等で商品を購入する際に行われる支払いであるが、それ以外にも、電車の切符の購入、病院での治療費の支払い、光熱費や通信費のような毎月の使用料金の支払い及び住宅ローンのような分割払い等も含められる。なお、お釣り運用サービスとは関係なくユーザ自身が独自に行った資金運用のための支払い（例えばユーザが証券会社の金融商品を独自に購入する際に行う支払い）も、前述した「商取引におけるお金の支払い」に含めてもよい。
【００２２】
これらの支払いの中には、クレジットカード、電子マネーで及び口座からの引き落とし等により１円単位で支払うため通常はお釣りが生じないものがあるが、お釣り運用サービスは、それらの支払いについても、仮に現金で１００円単位や１０００円単位で支払われたとしたら生じると想定されるお釣りを資金運用に充てるという条件でユーザに提供されているものとする。
【００２３】
資金運用支援システム１は、ネットワーク２と、決済代行サーバ３と、銀行サーバ４と、銀行サーバ５と、資金運用サーバ装置６と、家計簿サーバ装置１０と、資金運用支援サーバ装置２０と、ユーザ端末３０とを備える。ネットワーク２は、移動体通信網及びインターネット等を含む通信システムであり、自システムに接続される装置同士のデータのやり取りを仲介する。ネットワーク２には、ユーザ端末３０以外の各装置が有線通信で接続されており、ユーザ端末３０が無線通信で接続されている。なお、ネットワーク２との接続は有線通信及び無線通信のどちらでもよい。
【００２４】
決済代行サーバ３は、取引で発生する決済処理を代行する決済代行会社が運用するサーバである。銀行サーバ４及び銀行サーバ５は、銀行の口座を管理する（詳細には口座に収められているお金を管理する）サーバであり、口座への入金処理及び口座からの出金処理を行う。本実施例では、銀行サーバ４は、ユーザが利用する銀行でユーザの利用可能なお金が収められた口座を管理するサーバであり、銀行サーバ５は、資金運用会社が利用する銀行で資金運用会社の口座を管理するサーバであるものとする。
【００２５】
ここでいう「ユーザの利用可能なお金」とは、お釣り運用サービスにおいて運用される資金の元手となり得るお金のことである。ユーザの利用可能なお金が収められた口座は、ユーザが開設した口座に限らない。例えばユーザが利用する証券会社、通信事業者、電力会社、ガス会社、決済代行会社、通信販売会社及びＣ２Ｃ（Consumer to Consumer）サービス会社等が利用する、ユーザが支払ったお金を収めるための口座であってもよい。また、ポイントサービスを提供している事業者がユーザに付与したポイントに相当するお金を収めている口座であってもよい。
【００２６】
各事業者との取り決めにより、ユーザがそれらの口座に支払額以上のお金を収めておくことで、余ったお金を資金運用に充てることができる。それらの場合、事業者の口座を保有する銀行の銀行サーバ、又は、各事業者がその口座を管理するために設けたサーバが、ユーザの利用可能なお金が収められた口座を管理するサーバとして用いられる。資金運用サーバ装置６は、銀行サーバ５が管理する口座の資金を運用する処理及び運用実態を資金運用支援サーバ装置２０に提供する処理等を実行する。
【００２７】
家計簿サーバ装置１０は、ユーザの家計情報を蓄積する装置である。家計情報には、少なくともユーザの支出を示す支出情報が含まれる。支出情報は、食費、被服費、娯楽費、医療費、交際費、教育費、車両費、光熱費及び住居費等を示す情報である。これらの支出には、厳密には家族などユーザと家計をともにする者の支出も含まれているが、本実施例では、そのような支出もユーザの支出として捉えるものとする。家計簿サーバ装置１０は、これらの支出情報を、ユーザ端末３０から取得したり、金融機関が提供する個人向けサイト（ユーザの口座を用いた取引の履歴が掲載されたサイト。例えばインターネットバンキングのサイト）から取得したりする。
【００２８】
資金運用支援サーバ装置２０は、お釣り運用サービスをユーザに提供するための処理を行う情報処理装置である。資金運用支援サーバ装置２０は、家計簿サーバ装置１０から支出情報を取得する処理、お釣りを算出する処理、お釣りを資金運用に充てることの承諾をユーザに要求する処理、及び、承諾が得られたお釣りと同等の金額をユーザの口座から資金運用用の口座に移すための処理等を行う。
【００２９】
ユーザ端末３０は、ユーザが利用する端末装置であり、例えばスマートフォン、タブレット端末又はパーソナルコンピュータ等である。ユーザ端末３０は、家計簿サーバ装置１０にアクセスする操作（ユーザＩＤ（Identification）、パスワードの入力操作）の受け付け、ユーザの家計情報（特に支出情報）の入力操作の受付、蓄積された家計情報の表示、資金運用支援サーバ装置２０からの上記要求の表示、その要求に対して承諾・拒否のいずれかを回答する操作の受け付け、及び、回答結果の通知処理等を行う。
【００３０】
図２は家計簿サーバ装置１０及び資金運用支援サーバ装置２０のハードウェア構成を表す。これらの装置は、いずれも、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信装置１４と、入力装置１５と、出力装置１６とを備えるコンピュータである。プロセッサ１１は、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１１は、周辺装置とのインターフェース、制御装置、演算装置及びレジスタ等を含む中央処理装置（ＣＰＵ：Central Processing Unit）を備える。
【００３１】
プロセッサ１１は、プログラム（プログラムコード）、ソフトウェアモジュール及びデータ等を、ストレージ１３や通信装置１４からメモリ１２に読み出し、これらに従って各種の処理を実行する。メモリ１２は、コンピュータが読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）及びＲＡＭ（Random Access Memory）等である。
【００３２】
ストレージ１３は、コンピュータが読み取り可能な記録媒体であり、例えば、ハードディスクドライブ、フレキシブルディスク及びフラッシュメモリ等である。ストレージ１３は、補助記憶装置と呼ばれてもよい。通信装置１４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。
【００３３】
入力装置１５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、ＬＥＤランプなど）である。なお、入力装置１５及び出力装置１６は、一体となった構成（例えば、タッチスクリーン）であってもよい。
【００３４】
なお、一切の物理的な入力を待たず自律的かつ定期的に実行される処理（いわゆるバッチ処理）がこの入力に置き換わってもよいし、ユーザ端末３０がＧＰＳ（Global Positioning System）等の測位手段を備えている場合に、特定の位置が測定されたときに実行される処理がこの入力に置き換わってもよい。また、ワイヤレスネットワークに接続された物理ボタンが用いられてもよい（この物理ボタンを押すと貯まっているお釣りを資金運用に充てることの承諾を一括で行うなど）。また、上記のハードウェア構成は、仮想化されたリソースで提供されてもよい（各サーバ装置がクラウドコンピューティングシステム上に構築される場合など）。
【００３５】
図３はユーザ端末３０のハードウェア構成を表す。ユーザ端末３０は、プロセッサ３１と、メモリ３２と、ストレージ３３と、通信装置３４と、入力装置３５と、出力装置３６と、撮像装置３７とを備えるコンピュータである。プロセッサ３１から出力装置３６までは、図２に表す同名の各装置と共通するハードウェアである。撮像装置３７は、レンズ及び撮像素子等を備え、レンズから入射する光が表す周囲の人物や光景を撮影する。撮像装置３７は、撮影した画像を示す画像データをプロセッサ３１に供給する。
【００３６】
資金運用支援システム１が備える各装置のプロセッサがプログラムを実行して各部を制御することで、以下に述べる機能が実現される。
図４は資金運用支援システム１が実現する機能構成を表す。家計簿サーバ装置１０は、収入情報取得部１０１と、支出情報取得部１０２と、家計情報蓄積部１０３とを備える。
【００３７】
資金運用支援サーバ装置２０は、支払額取得部２０１と、差額算出部２０２と、差額取得部２０３と、差額蓄積部２０４と、要求時期判断部２０５と、承諾要求部２０６と、承諾可否受付部２０７と、撤回受付部２０８と、資金移動時期判断部２０９と、移動指示処理実行部２１０とを備える。ユーザ端末３０は、レシート読取部３０１と、支出情報送信部３０２と、承諾要求表示部３０３と、承諾可否操作受付部３０４と、承諾可否通知部３０５と、履歴表示部３０６と、撤回操作受付部３０７と、撤回通知部３０８とを備える。
【００３８】
家計簿サーバ装置１０の収入情報取得部１０１は、ユーザの収入情報を取得する。本実施例では、口座の取引履歴を掲載した個人向けサイトへのアクセスに用いる情報（ＵＲＬ（Uniform Resource Locator）、ユーザＩＤ、パスワード等）を家計簿サーバ装置１０にユーザが予め登録しておく。
【００３９】
個人向けサイトでは、取引日、取引の種類（カード引き出し、カード預け入れ、振り込み及び引き落とし等）、取引先及び取引金額等の取引履歴が掲載されている。収入情報取得部１０１は、登録された情報を用いてユーザの取引履歴を読み出し、入金を示す取引履歴のうち決められた項目（「給料」及び「賞与」等）のものを、ユーザの収入情報として取得する。収入情報取得部１０１は、取得した収入情報を、ユーザのユーザＩＤとともに家計情報蓄積部１０３に供給する。
【００４０】
このユーザＩＤは、資金運用支援システム１で割り当てられているものであり、個人向けサイトへのアクセス用のユーザＩＤ及び家計簿サーバ装置１０にアクセスするためのユーザＩＤとは通常は異なっている。ただし、お釣り運用サービスを提供する事業者が家計簿サーバ装置１０も運用する場合やユーザ自身がユーザＩＤを決定する方法が採用されている場合などに、共通のユーザＩＤが用いられてもよい。
【００４１】
家計簿サーバ装置１０の支出情報取得部１０２は、ユーザの支出情報を取得する。支出情報取得部１０２は、例えば、上記の個人向けサイトから取引履歴を読み出し、出金を示す取引履歴のうち決められた項目（「引き落し」及び「振り込み」等）のものを、ユーザの支出情報として取得する。また、支出情報取得部１０２は、ユーザ端末３０から次のように送信されてくる情報を支出情報として取得する。
【００４２】
ユーザ端末３０のレシート読取部３０１は、自装置の撮像手段（撮像装置３７）でレシートを撮影することで、そのレシートに記載された支出情報を読み取る。レシート読取部３０１は、レシートに含まれるテキストのパターン（「領収証」、「合計」、「お預り」及び「お釣り」等）を予め記憶しておき、撮影した画像に写ったテキストを認識してそれらのパターンが含まれている場合にレシートが撮影されていると判断する。レシート読取部３０１は、この判断を行うと、撮影されているレシートに記載されている日時、商品名、価格、価格の合計、消費税額、支払額及びお釣り等を支出情報として読み取る。レシート読取部３０１は、読み取った支出情報を支出情報送信部３０２に供給する。なお、この画像認識プロセスは、外部装置に対して画像データを送信し、その外部装置により読み取られた文字情報をユーザ端末３０に返却することにより実現されてもよい。
【００４３】
支出情報送信部３０２は、家計簿サーバ装置１０の宛先（ＩＰ（Internet Protocol）アドレス等）を記憶しておき、供給された支出情報をその宛先（すなわち家計簿サーバ装置１０）に送信する。支出情報取得部１０２は、こうして送信されてきたレシートから読み取られた支出情報を取得する。支出情報取得部１０２は、上記のとおり取得した支出情報を、ユーザのユーザＩＤとともに家計情報蓄積部１０３に供給する。
【００４４】
家計簿サーバ装置１０の家計情報蓄積部１０３は、上記のとおり取得された収入情報及び支出情報をユーザの家計情報として蓄積する。家計情報蓄積部１０３は、供給された収入情報及び支出情報を、ともに供給されたユーザＩＤに対応付けて記憶することでこの蓄積を行う。以上で述べた収入情報及び支出情報の取得及び蓄積は定期的に（例えば毎日。支出情報についてはユーザがレシートを撮影する操作を行ったときにも）行われ、なるべく新しい家計情報が蓄積されるようになっている。
【００４５】
資金運用支援サーバ装置２０の支払額取得部２０１は、上述した商取引における支払額を記憶する記憶装置からその支払額を取得する。商取引における支払額は、支出情報が示す出金の金額及びレシートに記載された価格の合計と消費税額を合わせた金額等によって表される。支払額取得部２０１は、その支出情報を記憶する家計簿サーバ装置１０（本実施例における記憶装置）に支出情報を要求する。家計簿サーバ装置１０の家計情報蓄積部１０３は、この要求を受け取ると、蓄積している支出情報及びそれに対応付けたユーザＩＤを資金運用支援サーバ装置２０に送信する。
【００４６】
このとき、家計情報蓄積部１０３は、今までに資金運用支援サーバ装置２０に送信したことがない支出情報（つまり前回支出情報を送信した後に新たに蓄積された支出情報）を送信する。支払額取得部２０１は、送信されてきた支出情報及びユーザＩＤを受け取ることで、そのユーザＩＤのユーザが商取引の際に支払った支払額を取得する。支払額取得部２０１は、取得した支払額を示す支出情報を対応するユーザＩＤ（その額を支払ったユーザのユーザＩＤ）に対応付けて差額算出部２０２に供給する。
【００４７】
差額算出部２０２は、支払額取得部２０１により取得された支払額とその支払額を切り上げた額との差額を算出する。差額算出部２０２は、例えばユーザによってお釣り運用サービスの利用開始時に設定された単位（５０円単位、１００円単位、５００円単位又は１０００円単位等）で支払額を切り上げる。この切り上げ単位は、お釣り運用サービスの利用開始後も変更可能である。
【００４８】
差額算出部２０２は、支払額が３２５円の場合に、切り上げ単位として１００円単位が設定されている場合、３２５円を１００円単位で切り上げた４００円から３２５円を減算して得られる７５円を差額として算出し、切り上げ単位として５０円単位が設定されている場合、３２５円を５０円単位で切り上げた３５０円から３２５円を減算して得られる２５円を差額として算出する。差額算出部２０２は、こうして算出した差額を対応するユーザＩＤ（その差額が算出される支払いを行ったユーザのユーザＩＤ）及び支出情報に対応付けて差額取得部２０３に供給する。
【００４９】
差額取得部２０３は、商取引における支払額とその支払額を切り上げた額との差額を取得する。差額取得部２０３は、本実施例では、差額取得部２０３により算出された差額を取得する。差額取得部２０３は、取得した差額を、その差額に対応付けて供給されたユーザＩＤ及び支出情報とともに差額蓄積部２０４に供給する。差額蓄積部２０４は、差額取得部２０３により取得された差額を、対応するユーザＩＤ等に対応付けて記憶する。差額蓄積部２０４は本発明の「蓄積部」の一例である。
【００５０】
図５は蓄積されている差額の一例を表す。図５の例では、差額蓄積部２０４は、ユーザＩＤと、支払日と、差額と、差額ＩＤと、ステータスとを対応付けて記憶している。支払日は、差額が算出された支払額の商取引が行われた日を表し、支出情報により示される。差額ＩＤは、各差額を識別する情報である。ステータスは、蓄積されている差額を資金運用に充てることについての承諾をユーザに要求した場合に承諾が得られた状況、又は、拒否された状況を表す。
【００５１】
また、ステータスは、承諾要求がまだなされていない未要求の状況、又は、承諾された後に口座の移動まで済んでいる移動済みの状況を表す。図５の例では、支払日が１２／２２から１２／３１までの差額には「移動済み」という状況が、支払日が１／１から１／７までの差額には「拒否」という状況が、支払日が１／８から１／１４までの差額には「承諾」という状況が、支払日が１／１５から１／２１までの差額には「未要求」という状況がそれぞれ対応付けられている。
【００５２】
この承諾要求及び口座の移動についてはこの後で詳しく説明する。以上で述べた支払額の取得から差額の蓄積までの動作は定期的に（例えば毎日）行われ、なるべく最新の商取引における差額が蓄積されるようになっている。本実施例では、説明を分かり易くするために、毎日その日に行われた商取引における差額が差額取得部２０３によって取得され、差額蓄積部２０４に蓄積されるものとする。
【００５３】
資金運用支援サーバ装置２０の要求時期判断部２０５は、前述した承諾要求を行う時期、すなわち、差額蓄積部２０４に蓄積されている差額を資金運用に充てることについての承諾をユーザに要求する要求時期になったか否かを判断する。要求時期判断部２０５は、承諾を要求する相手となる要求先ユーザが定めた基準日から定められた第１の期間が経過するごとに、要求時期になったと判断する。
【００５４】
本実施例では、基準日として月初めの日が定められ、第１の期間として１週間、又は、月末最後の期間が１週間に満たない場合は、その前週と合わせた期間を第１の期間とする。つまり、第１の期間は、１週間又は１週間＋月末の数日間である。この定め方をすれば、どの月も４回の第１の期間を含むことになる。例えば１月であれば、月初めの１／１（１月１日）が基準日となり、１／１から１／７まで、１／８から１／１４まで、１／１５から１／２１まで、１／２２から１／３１までという４回の第１の期間が定められる。
【００５５】
要求時期判断部２０５は、第１の期間が経過した次の日になったときに要求時期になったと判断する。例えば上記の４回の第１の期間については、１／８、１／１５、１／２２及び２／１になったときに要求時期になったと判断する。要求時期判断部２０５は、要求時期になったと判断すると、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうちステータスが「未要求」であるものを、対応する差額ＩＤ及び支払日とともに差額蓄積部２０４から読み出し、要求先ユーザのユーザＩＤとともに承諾要求部２０６に供給する。
【００５６】
承諾要求部２０６は、第１の期間が経過するごとに、その第１の期間になされた１以上の商取引における差額を資金運用に充てることについての承諾をユーザに要求する。例えば、ユーザ端末３０の承諾要求表示部３０３が、自機能を実現するためのプログラムが起動されたとき又は定期的に、自装置を利用するユーザのユーザＩＤを資金運用支援サーバ装置２０に送信するとともに、表示すべき承諾要求が有るか否かを資金運用支援サーバ装置２０に問い合わせる。
【００５７】
承諾要求部２０６は、要求時期判断部２０５から供給されたユーザＩＤとユーザ端末３０から送信されてきたユーザＩＤとが一致する場合、そのユーザＩＤとともに供給された差額、差額ＩＤ及び支払日を用いて、例えばそれらの差額を資金運用に充てることについての承諾を要求する旨を表す文字列と、供給された差額ＩＤ、差額及び支払日とを示す要求データを生成する。承諾要求部２０６は、生成した要求データを、問い合わせ元のユーザ端末３０に対して送信する。承諾要求部２０６は、この要求データをユーザ端末３０に送信することで、資金運用の承諾をユーザに要求する。
【００５８】
以上のとおり、本実施例では、ユーザ端末３０からの問い合わせを受けて資金運用の承諾が要求されるという、いわゆるプル型での承諾要求が行われる。なお、これに限らず、ユーザ端末３０からの問い合わせがなくても、要求時期判断部２０５により第１の期間が経過したと判断されたときに、承諾要求部２０６が資金運用の承諾を要求するという、いわゆるプッシュ型での承諾要求が行われてもよい。
【００５９】
ユーザ端末３０の承諾要求表示部３０３は、資金運用支援サーバ装置２０から差額を資金運用に充てることについての承諾を要求された場合に、その承諾要求を表示する。承諾要求表示部３０３は本発明の「表示部」の一例である。承諾要求表示部３０３は、資金運用支援サーバ装置２０から送信された要求データを受け取ると、その要求データが示す文字列等を、資金運用支援サーバ装置２０からの承諾要求としてアプリ画面又はウェブブラウザの画面に表示する。
【００６０】
図６は表示された承諾要求の一例を表す。図６の例では、承諾要求表示部３０３は、「Ａさんに以下のお釣りの資金運用が提案されました。」という文字列と、商取引の支払日と、その商取引における差額と、選択された差額の合計金額（この例では「１４６８円」）とを示す文字列とを、承諾要求Ａ１として出力装置３６のディスプレイに表示している。また、承諾要求表示部３０３は、「選択したものを承諾」と書かれた承諾ボタンＢ１と、拒否ボタンＢ２と、全選択ボタンＢ３と、複数の個別選択ボタンＢ４（「○」は選択することを示し、「×」は選択しないことを示す）とを表示している。
【００６１】
承諾要求表示部３０３は、これらのボタンの表示領域を示す情報を承諾可否操作受付部３０４に供給する。承諾可否操作受付部３０４は、承諾要求に対する承諾の可否を示すユーザの操作を受け付ける。承諾可否操作受付部３０４は、承諾ボタンＢ１をタップする操作（マウスでクリックする操作でもよい）を、選択された差額の合計金額として表示されている資金の資金運用をユーザが承諾する操作として受け付け、拒否ボタンＢ２をタップする操作を、ユーザが資金運用を拒否する操作として受け付ける。
【００６２】
また、承諾可否操作受付部３０４は、全選択ボタンＢ３をタップする操作を、資金運用に充てる資金として全ての差額を選択する操作として受け付け、個別選択ボタンＢ４をタップする操作を、各差額の選択の有無を切り替える操作（タップする度に「○」と「×」が切り替わる）として受け付ける。承諾可否操作受付部３０４は本発明の「受付部」の一例である。承諾可否操作受付部３０４は、受け付けた操作結果を示す操作結果情報を承諾可否通知部３０５に供給する。
【００６３】
操作結果情報は、例えば、選択された差額の差額ＩＤ、選択されなかった差額の差額ＩＤ及び選択された差額の合計金額を示す情報である。なお、拒否ボタンＢ２が操作された場合には、選択された状態の差額があったとしても、全ての差額の差額ＩＤが選択されなかった差額の差額ＩＤとして示され、且つ、合計金額として０円が示される操作結果情報が承諾可否通知部３０５に供給される。
【００６４】
承諾可否通知部３０５は、承諾可否操作受付部３０４による操作結果を資金運用支援サーバ装置２０に通知する。承諾可否通知部３０５は、資金運用支援サーバ装置２０の宛先を示す宛先情報（ＩＰアドレス等）を予め記憶しておく。承諾可否通知部３０５は、承諾可否操作受付部３０４から操作結果情報が供給されると、供給された操作結果情報と、自装置のユーザのユーザＩＤとを対応付けた操作結果データを、記憶している宛先情報が示す宛先（つまり資金運用支援サーバ装置２０）に送信する。
【００６５】
承諾可否通知部３０５は、この操作結果データを送信することで、資金運用支援サーバ装置２０に対して、承諾要求が表示されて資金運用を承諾する操作が行われた場合にはその操作結果データが示す合計金額の資金運用が承諾された旨を通知し、資金運用を拒否する操作が行われた場合にはその旨を通知する。承諾可否通知部３０５は本発明の「通知部」の一例である。
【００６６】
また、承諾可否通知部３０５は、こうして資金運用を承諾又は拒否した差額の履歴が後から確認できるように、操作結果データ及びその操作結果データの送信日時を互いに対応付けて記憶しておく。この操作結果データは、資金運用を承諾する操作が受け付けられた場合におけるその資金運用に充てられる資金を示す情報である。承諾可否通知部３０５は本発明の「記憶部」の一例である。
【００６７】
承諾可否通知部３０５は、例えば、操作結果データを受信した際の資金運用支援サーバ装置２０のローカル時間（世界標準時からの時差により算出される日時、日本なら＋９時間）を、操作結果データの送信日時として記憶する。これにより、ユーザ端末３０が海外から資金運用支援サーバ装置２０にアクセスする場合でも、日本時間で送信日時が記憶される。
【００６８】
資金運用支援サーバ装置２０の承諾可否受付部２０７は、承諾要求部２０６が要求した承諾の可否を受け付ける。承諾可否受付部２０７は、ユーザ端末３０から送信されてきた操作結果データを受け取ると、その操作結果データが１円以上の合計金額を示す場合には、その操作結果データが示す合計金額による資金運用が承諾されたことを受け付け、その操作結果データが合計金額として０円を示す場合には、資金運用が拒否されたことを受け付ける。
【００６９】
承諾可否受付部２０７は、承諾の可否を受け付けると、差額蓄積部２０４に対して、操作結果データが示すユーザＩＤ及び差額ＩＤに対応付けられている差額のステータスを受け付けた承諾の可否のとおりに変更するよう指示する。差額蓄積部２０４は、この指示を受け取ると、指示されたとおりに、承諾要求がされた差額のステータスを「未要求」から「承諾」又は「拒否」に変更する。
【００７０】
ユーザ端末３０の履歴表示部３０６は、過去に資金運用が承諾された差額の履歴を表示する。履歴表示部３０６は、承諾された差額の履歴を表示する操作がユーザにより行われると、記憶されている操作結果データ及びその操作結果データの送信日時を承諾可否通知部３０５から取得する。なお、本実施例では、拒否された差額の履歴を表示する操作は用意されておらず、一度拒否された差額の履歴は表示されないものとする。履歴表示部３０６は、取得した操作結果データが示す差額ＩＤの差額と、それらの差額の合計金額と、その合計金額の資金運用が過去（操作結果データの送信日時）に承諾された旨を示す文字列とを前述した差額の履歴として表示する。
【００７１】
図７は表示された差額の履歴の一例を表す。図６の例では、履歴表示部３０６は、「以下のお釣りの資金運用を１／２２に承諾しています。」という文字列と、商取引の支払日と、その商取引における差額と、選択された差額の合計金額（この例では「１４６８円」）とを示す文字列とを、差額の履歴Ｃ１として出力装置３６のディスプレイに表示している。また、承諾要求表示部３０３は、複数の個別選択ボタンＢ４と、変更の反映ボタンＢ５と、承諾の撤回ボタンＢ６とを表示している。
【００７２】
履歴表示部３０６は、各ボタンの表示領域を示す情報と取得した操作結果データとを撤回操作受付部３０７に供給する。撤回操作受付部３０７は、過去に行った資金運用の承諾の撤回を示すユーザの撤回操作を受け付ける。撤回操作受付部３０７は、承諾の撤回ボタンＢ６をタップする操作が行われると、その操作を、全ての差額についての承諾を撤回する撤回操作として受け付ける。
【００７３】
また、撤回操作受付部３０７は、個別選択ボタンＢ４をタップする操作を、図６の例と同様に各差額の選択の有無を切り替える操作として受け付け、その操作により或る差額について選択の有無を「○」から「×」に切り替えた後に変更の反映ボタンＢ５をタップする操作を、その差額についての承諾を撤回する撤回操作として受け付ける。撤回操作受付部３０７は、いずれかの撤回操作を受け付けると、承諾が撤回された差額の差額ＩＤを撤回通知部３０８に供給する。
【００７４】
撤回通知部３０８は、撤回操作受付部３０７から差額ＩＤが供給されると、それらの差額ＩＤの差額について資金運用の承諾が撤回された旨を資金運用支援サーバ装置２０に通知する。撤回通知部３０８は、供給された差額ＩＤと承諾が撤回された旨と自装置のユーザのユーザＩＤとを示す撤回通知データを資金運用支援サーバ装置２０に送信することでこの通知を行う。
【００７５】
資金運用支援サーバ装置２０の撤回受付部２０８は、撤回通知部３０８から通知された資金運用の承諾の撤回を受け付ける。撤回受付部２０８は本発明の「受付部」の一例である。撤回受付部２０８は、ユーザ端末３０から送信されてきた撤回通知データを受け取ると、承諾の撤回がされたものと判断し、その撤回通知データが示すユーザＩＤ及び差額ＩＤに対応付けられている差額のステータスを承諾から拒否に変更するよう差額蓄積部２０４に指示する。差額蓄積部２０４は、この指示を受け取ると、指示されたとおりに、それらの差額のステータスを「承諾」から「拒否」に変更する。
【００７６】
資金運用支援サーバ装置２０の資金移動時期判断部２０９は、資金運用の承諾を得られた差額の累積額を第１の口座から第２の口座に移動する移動時期を判断する。第１の口座は、ユーザの資金が収められている口座であり、例えばユーザ名義の普通口座である。なお、第１の口座は、それに限らず、上述したユーザが利用可能なお金が収められた口座（証券会社、通信事業者及びポイントサービス事業者等の口座）であればよい。本実施例では、図１に表す銀行サーバ４が第１の口座のお金を管理している。第２の口座は、ユーザが承諾した資金運用を行う際に資金を収めておく口座であり、例えば資金運用会社の口座である。本実施例では、図１に表す銀行サーバ５が第２の口座のお金を管理している。
【００７７】
資金移動時期判断部２０９は、上述した基準日（要求先ユーザが定めた日。資金運用支援サーバ装置２０のローカル時間で判断される）から、上述した第１の期間を複数含む第２の期間が経過すると、移動時期になったと判断する。本実施例では、上述したようにどの月も４回の第１の期間を含むように基準日及び第１の期間が定められており、それら４回の第１の期間を含む期間を第２の期間として定めるものとする。この定め方をすれば、１月から１２月までの各月がそれぞれ第２の期間となる。
【００７８】
資金移動時期判断部２０９は、第２の期間が終了してから、最後の第１の期間についての資金運用の承諾のために設けられた期間が経過したときに、資金移動時期になったと判断する。例えば承諾のための期間を３日間とすると、資金移動時期判断部２０９は、１／３１に第２の期間が終了し、２／１から２／３までの３日間が経過した次の日である２／４になったときに、資金移動時期になったと判断する。
【００７９】
資金移動時期判断部２０９は、資金移動時期になったと判断すると、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうち、ステータスが「承諾」であるものを差額ＩＤとともに差額蓄積部２０４から読み出し、読み出した差額及び差額ＩＤを要求先ユーザのユーザＩＤとともに移動指示処理実行部２１０に供給する。
【００８０】
移動指示処理実行部２１０は、上述した第２の期間が経過すると、承諾を得られた差額の累積額の前述した第１の口座から第２の口座への移動を指示する移動指示処理を実行する。移動指示処理実行部２１０は本発明の「実行部」の一例である。ここでいう承諾を得られた差額には、承諾が撤回された差額は含まれない。つまり、移動指示処理実行部２１０は、承諾が得られてから移動指示処理を実行する前にその承諾の撤回が撤回受付部２０８により受け付けられた場合、その承諾が撤回された差額を累積額から減じて移動指示処理を実行する。
【００８１】
移動指示処理実行部２１０は、資金移動時期判断部２０９から資金運用が承諾された差額及び差額ＩＤが供給されると、その差額を合計した金額を累積額として算出する。移動指示処理実行部２１０は、算出した累積額と同じ額をユーザの口座から資金運用会社の口座に移動させることを要求する要求データを図１に表す決済代行サーバ３に送信する処理を、移動指示処理として実行する。
【００８２】
決済代行サーバ３は、この要求データを受け取ると、ユーザの口座を管理する銀行サーバ４に対してそのユーザの口座から銀行サーバ５が管理する資金運用会社の口座に対して累積額と同じ額を移動させるよう要求する。銀行サーバ４がこの要求に基づいて累積額と同じ額をユーザの口座から資金運用会社の口座に振り込む処理を行い、銀行サーバ５が振り込まれた金額を資金運用会社の口座に入金する処理を行うことで、資金の移動が完了する。
【００８３】
なお、要求データの送信先、すなわち、口座間の資金の移動の要求先は、決済代行サーバ３ではなく銀行サーバ４であってもよいし、プリペイドカード、ポイントエクスチェンジ及び携帯キャリア決済代行等の決済機関であってもよい。要するに、資金運用のために口座間の資金の移動がなされれば、要求先がどこであってもよい。また、結果として口座間の資金の移動がなされれば、移動指示処理実行部２１０は、どのような処理を移動指示処理（差額の累積額の第１の口座から第２の口座への移動を指示する処理）として実行してもよい。
【００８４】
以上のとおりユーザが承諾した差額の累積額が資金運用会社の口座に入金されることで、その累積額のユーザの資金の運用が開始される。移動指示処理実行部２１０は、移動指示処理を実行すると、累積額を算出した差額の差額ＩＤに対応付けられたステータスを「移動済み」に変更するよう差額蓄積部２０４に指示する。差額蓄積部２０４は、この指示を受け取ると、指示された差額ＩＤのステータスを「移動済み」に変更する。これにより、一度資金運用に充てられた差額については再度承諾が要求されないようになっている。
【００８５】
資金運用支援システム１が備える各装置は、上記の構成に基づいて、支払額とその支払額を切り上げた額との差額を蓄積する蓄積処理と、蓄積された差額のうちユーザが承諾した分を資金運用に充てることを支援する運用支援処理とを行う。
図８は蓄積処理における各装置の動作手順の一例を表す。この動作手順は、例えば、ユーザがユーザ端末３０でレシートを撮影することを契機に開始される。まず、ユーザ端末３０（レシート読取部３０１）は、レシートに記載された支出情報を読み取る（ステップＳ１１）。
【００８６】
次に、ユーザ端末３０（支出情報送信部３０２）は、読み取られた支出情報を家計簿サーバ装置１０に送信する（ステップＳ１２）。家計簿サーバ装置１０（支出情報取得部１０２）は、送信されてきたユーザの支出情報を取得する（ステップＳ１３）。次に、家計簿サーバ装置１０（家計情報蓄積部１０３）は、取得された支出情報をユーザの家計情報として蓄積する（ステップＳ１４）。
【００８７】
次に、資金運用支援サーバ装置２０（支払額取得部２０１）は、商取引における支払額を示す支出情報を記憶する家計簿サーバ装置１０にその支出情報を要求する（ステップＳ２１）。家計簿サーバ装置１０（家計情報蓄積部１０３）は、この要求を受け取ると、蓄積している支出情報を読み出し（ステップＳ２２）、資金運用支援サーバ装置２０に送信する（ステップＳ２３）。資金運用支援サーバ装置２０（支払額取得部２０１）は、送信されてきた支出情報が示す支払額を取得する（ステップＳ２４）。
【００８８】
次に、資金運用支援サーバ装置２０（差額算出部２０２）は、取得された支払額とその支払額を切り上げた額との差額を算出する（ステップＳ２５）。続いて、資金運用支援サーバ装置２０（差額取得部２０３）は、算出された差額を取得する（ステップＳ２６）。次に、資金運用支援サーバ装置２０（差額蓄積部２０４）は、取得された差額を、対応するユーザＩＤ等に対応付けて蓄積する（ステップＳ２７）。
【００８９】
図９は運用支援処理における各装置の動作手順の一例を表す。この動作手順は、上述した承諾要求の時期になることを契機に開始される。まず、資金運用支援サーバ装置２０（要求時期判断部２０５）は、上述した第１の期間が経過して次の日になったときに承諾要求を行う時期（要求時期）になったと判断する（ステップＳ３１）。次に、資金運用支援サーバ装置２０（承諾要求部２０６）は、第１の期間になされた１以上の商取引における差額を資金運用に充てることについての承諾をユーザに要求する（ステップＳ３２）。
【００９０】
ユーザ端末３０（承諾要求表示部３０３）は、資金運用支援サーバ装置２０から要求された承諾要求を表示する（ステップＳ３３）。次に、ユーザ端末３０（承諾可否操作受付部３０４）は、承諾要求に対する承諾の可否を示すユーザの操作を受け付ける（ステップＳ３４）。続いて、ユーザ端末３０（承諾可否通知部３０５）は、ステップＳ３４での操作結果を資金運用支援サーバ装置２０に通知する（ステップＳ３５）。
【００９１】
資金運用支援サーバ装置２０（承諾可否受付部２０７）は、ステップＳ３２で要求した承諾の可否を受け付ける（ステップＳ３６）。そして、資金運用支援サーバ装置２０（差額蓄積部２０４）は、受け付けられた承諾の可否を、蓄積している差額のステータスに反映する（ステップＳ３７）。具体的には、資金運用支援サーバ装置２０（差額蓄積部２０４）は、承諾された場合には差額のステータスを「承諾」に変更し、拒否された場合には差額のステータスを「拒否」に変更する。
【００９２】
その後、ユーザによる表示操作に基づいて、ユーザ端末３０（履歴表示部３０６）は、過去に資金運用が承諾された差額の履歴を表示する（ステップＳ４１）。次に、ユーザ端末３０（撤回操作受付部３０７）は、表示された承諾の撤回を示すユーザの撤回操作を受け付ける（ステップＳ４２）。続いて、ユーザ端末３０（撤回通知部３０８）は、資金運用の承諾が撤回された旨を資金運用支援サーバ装置２０に通知する（ステップＳ４３）。資金運用支援サーバ装置２０（撤回受付部２０８）は、ユーザ端末３０から通知された資金運用の承諾の撤回を受け付ける（ステップＳ４４）。
【００９３】
次に、資金運用支援サーバ装置２０（差額蓄積部２０４）は、受け付けられた承諾の撤回を、蓄積している差額のステータスに反映する（ステップＳ４５）。具体的には、資金運用支援サーバ装置２０（差額蓄積部２０４）は、承諾が撤回された差額のステータスを「承諾」から「拒否」に変更する。その後、資金運用支援サーバ装置２０（資金移動時期判断部２０９）は、第１の期間を複数含む第２の期間が経過すると、資金運用の承諾を得られた差額の累積額を第１の口座から第２の口座に移動する移動時期になったと判断する（ステップＳ５１）。
【００９４】
次に、資金運用支援サーバ装置２０（移動指示処理実行部２１０）は、前述した累積額の移動を指示する移動指示処理を実行する（ステップＳ５２）。そして、資金運用支援サーバ装置２０（差額蓄積部２０４）は、移動指示処理が行われたことを、蓄積している差額のステータスに反映する（ステップＳ５３）。具体的には、資金運用支援サーバ装置２０（差額蓄積部２０４）は、移動指示処理が行われた差額のステータスを「承諾」から「移動済み」に変更する。
【００９５】
移動指示処理が実行されて口座から資金が移動すると手数料が発生するので、移動指示処理の回数は少ない方が望ましい。一方で、移動させる資金の金額が大きくなると、資金運用に対する心理的な抵抗がユーザに生じやすくなる。本実施例では、第１の期間が経過するごとに承諾要求が行われ、第１の期間を複数含む第２の期間が経過すると移動指示処理が実行される。これにより、承諾要求をする度に資金を移動する場合に比べて資金移動の回数を少なくしている。
【００９６】
また、資金移動の際にしか承諾要求をしない場合に比べて１度の承諾要求を行う差額の累積額を低く抑えている。このように、本実施例によれば、資金移動の回数を少なくしつつ、ユーザの資金運用の承諾を得やすくすることができる。また、本実施例では、承諾要求が行われてから資金が実際に移動するまでタイムラグがあるため、資金運用を止めたいと思い直した場合に、承諾を撤回することができる。特に、第２の期間に含まれる複数の第１の期間のうちの早い方の期間ほど、そのタイムラグが長いので、資金運用について考え直す時間を長くとることができる。
【００９７】
［２］変形例
上述した実施例は本発明の実施の一例に過ぎず、以下のように変形させてもよい。また、実施例及び各変形例は、必要に応じて組み合わせて実施してもよい。
【００９８】
［２−１］支払額の取得方法
資金運用支援サーバ装置２０の支払額取得部２０１は、実施例とは異なる方法で支払額を取得してもよい。支払額取得部２０１は、例えば、家計簿サーバ装置１０の支出情報取得部１０２と同じ方法（個人向けサイトから取引履歴を読み出す方法及びレシートに記載された支出情報を取得する方法）で支払額を取得してもよい。
【００９９】
また、支払額取得部２０１は、家計簿サーバ装置１０以外にも、販売店が利用しているＰＯＳ（Point Of Sale）システムや通信販売事業者の販売管理システム、クレジットカード及び電子マネー等の電子決済システムなど、ユーザの支払額を保持しているシステムから支払額を取得してもよい（ユーザ及び各事業者と支払額の取得について合意されているものとする）。
【０１００】
［２−２］個人向けサイト
ユーザの収入情報及び支出情報の取得先となる個人向けサイトは、上述した金融機関が提供するサイトに限らない。他にも、クレジットカードのサービスを展開する事業者が提供する利用履歴が掲載されたサイト、ロイヤリティポイントのサービスを展開する事業者が提供するポイント履歴が掲載されたサイト、電子マネーサービスを展開する事業者が提供する利用履歴が掲載されたサイト、及び、アグリゲーションサービス（異なるサービスの情報を集約して表示するサービス）を展開する事業者が提供する利用履歴及びポイント履歴等が掲載されたサイト等が用いられてもよい。
【０１０１】
［２−３］資金運用の選択肢
承諾要求部２０６は、ユーザに差額の資金運用について承諾を要求する際に、資金の運用方法の選択肢を提供してもよい。例えば、承諾要求部２０６は、ローリスクローリターンの運用方法と、ハイリスクハイリターンの運用方法と、リスクもリターンもそれらの中間の運用方法とを選択肢として提供する。この場合、ユーザは、資金運用の承諾及び拒否の操作に加え、承諾する場合には、運用方法の選択肢のうちのいずれかを選択する操作を行う。
【０１０２】
また、移動指示処理実行部２１０は、選択された運用方法を提供する運用会社の口座に資金を移動させる処理を移動指示処理として実行する。これにより、運用方法の選択肢がない場合に比べて、資金運用の自由度を高くすることができる。なお、これらの選択肢は、ユーザが明示的に変更しない限り意図せず変更されることがないものとしてもよい。これにより、資金運用におけるリスクレベルがユーザの知らない間に高まることを防ぐことができる。
【０１０３】
［２−４］資金運用に必要な手続き
資金運用を行うためにはユーザの資金をユーザの口座から運用会社が指定する口座に移動することになるが、そのためには運用会社が指定する金融機関の口座を開設する等の手続きが必要になる場合がある。以下ではそのように資金運用の前提となる、差額の累積額を第１の口座から第２の口座へ移動する際に必要な手続きのことを「運用前提手続き」という。
【０１０４】
資金運用支援システム１においては、実施例で述べたように承諾要求が行われてから資金が実際に移動するまでタイムラグがあるので、それを利用して、運用前提手続きが完了する前の商取引における差額であっても、運用前提手続きが完了した後に、それを用いた資金運用ができるようにしてもよい。本変形例では、支払額取得部２０１が、運用前提手続きが完了する前になされた商取引における支払額を取得し、差額算出部２０２が、そうして取得された支払額から差額を算出する。
【０１０５】
差額取得部２０３は、こうして算出された差額、すなわち、運用前提手続きが完了する前になされた商取引における差額を取得する。差額取得部２０３がこの差額を取得することで、移動指示処理の対象となる差額の累積額には、運用前提手続きが完了する前になされた商取引における差額が含まれることになる。また、運用前提手続きが第１の期間が経過しても完了していなければ、承諾要求部２０６は、運用前提手続きが完了する前に上述した承諾要求を行う。
【０１０６】
一方、移動指示処理実行部２１０は、運用前提手続きが完了する前には移動指示処理を実行しても資金の移動を行うことができないので、運用前提手続きが完了した後に移動指示処理を実行する。具体的には、例えば運用前提手続きが完了する前に資金移動時期が来た場合、移動指示処理実行部２１０は、資金移動を要求する要求データを決済代行サーバ３に送信する処理を移動指示処理として実行する。
【０１０７】
しかし、運用前提手続きが完了しておらず例えば必要な口座が開設されていないので、決済代行サーバ３は資金移動を完了することができず、その旨を資金運用支援サーバ装置２０に通知してくる。移動指示処理実行部２１０は、この通知を受け取ると、一定期間（例えば１日）が経過してから再度要求データを送信する。移動指示処理実行部２１０がこうして通知が送られてくる度に要求データを送信し直すことで、運用前提手続きが完了したときには、送信した要求データに基づいて資金の移動が行われる。
【０１０８】
移動指示処理実行部２１０は、このようにして運用前提手続きが完了した後に移動指示処理を実行する。本変形例によれば、運用前提手続きが完了する前になされた商取引における差額も運用に充てることができる。また、運用前提手続きが完了する前であっても、ユーザに差額を資金運用に充てることを承諾するか否かについて意思確認を行うことができる。
【０１０９】
［２−５］差額の蓄積時期
実施例では、毎日その日に行われた商取引における差額が差額取得部２０３によって取得されて差額蓄積部２０４に蓄積されるものとしたが、これに限らず、商取引が行われてから、その商取引における差額が蓄積されるまでに何日か経過する場合がある。その場合、例えば１回目の第１の期間に行われた商取引における差額についての承諾要求が、２回目以降の第１の期間になってから行われるということが起こり得る。
【０１１０】
実施例では、承諾要求部２０６は、第１の期間が経過するごとに、その第１の期間になされた１以上の商取引における差額についての承諾をユーザに要求したが、前述のとおり差額の蓄積までに時間を要する場合には、第１の期間が経過するごとに、その第１の期間の満了以前（つまり、その第１の期間とそれよりも前の第１の期間の両方を含む期間）になされた１以上の商取引における差額を資金運用に充てることについての承諾をユーザに要求することになる。
【０１１１】
ここでいう「第１の期間の満了以前」には、現在の第２の期間よりも前の第２の期間も含まれる。つまり、第１の期間が経過するごとに承諾要求が行われるのは、その第１の期間に新たに差額取得部２０３によって取得された差額の資金運用についてであって、差額が算出される商取引が行われた時期は、いつであってもよい。
【０１１２】
［２−６］拒否の撤回
実施例では、一度承諾した資金運用を撤回して拒否することができたが、反対に、一度拒否した資金運用を撤回して承諾することができてもよい。その場合、例えば、履歴表示部３０６が、過去に資金運用が拒否された差額の履歴を表示して、撤回操作受付部３０７が、過去に行った資金運用の拒否の撤回を示すユーザの撤回操作を受け付け、拒否が撤回された差額の差額ＩＤを撤回通知部３０８に供給する。
【０１１３】
次に、撤回通知部３０８が、供給された差額ＩＤの差額について資金運用の拒否が撤回された旨を資金運用支援サーバ装置２０に通知し、資金運用支援サーバ装置２０の撤回受付部２０８が、通知された資金運用の拒否の撤回を受け付け、差額蓄積部２０４が、拒否が撤回された差額のステータスを「拒否」から「承諾」に変更する。これにより、拒否が撤回された差額も加えた累積額について移動指示処理が実行され、資金運用に充てられることになる。
【０１１４】
［２−７］拒否された差額の再承諾要求
実施例では、一度資金運用に充てることが拒否された差額については、承諾要求が行われなかったが、再度承諾要求が行われてもよい。この場合、資金運用支援サーバ装置２０の要求時期判断部２０５が、要求時期になったと判断すると、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうち、ステータスが「未要求」及び「拒否」であるものを、対応する差額ＩＤとともに差額蓄積部２０４から読み出し、要求先ユーザのユーザＩＤとともに承諾要求部２０６に供給する。
【０１１５】
承諾要求部２０６は、例えば実施例と同様に要求データを生成して送信する。なお、それだと差額の合計金額が当然ながら大きくなるので、承諾要求部２０６は、「未要求」の差額の合計金額と、「拒否」された差額の合計金額とについて別々に承諾を要求してもよい。その場合、ユーザ端末３０の承諾要求表示部３０３は、２つの合計金額についてそれぞれ承諾ボタン及び拒否ボタンを表示して、ユーザがそれぞれについて承諾及び拒否を選べるようにする。資金運用支援サーバ装置２０の移動指示処理実行部２１０は、そうして資金運用の承諾を得られた差額の累積額について移動指示処理を実行する。本変形例によれば、資金運用の承諾を得る機会を増やすことができる。
【０１１６】
［２−８］資金移動時期における承諾の再要求
実施例では、資金移動時期になると、最後の第１の期間における差額について承諾が要求された後に移動指示処理が実行されたが、その他の第１の期間における差額についても、再度承諾が要求されてもよい。
【０１１７】
本変形例では、資金移動時期判断部２０９が、資金移動時期になったと判断すると、支払日が第２の期間に含まれる差額のうちステータスが「承諾」となっている差額の差額ＩＤを差額蓄積部２０４から読み出して要求先ユーザのユーザＩＤとともに承諾要求部２０６に供給する。承諾要求部２０６は、供給された差額ＩＤの差額を資金運用に充てることについての承諾を再度要求する旨を表す文字列と、その差額ＩＤに対応付けられている差額及び支払日とを示す要求データを生成してユーザ端末３０に送信する。
【０１１８】
ユーザ端末３０の承諾要求表示部３０３は、受け取った要求データが示す差額、すなわち支払日が第２の期間に含まれ且つ過去に資金運用を承諾した差額を図６に表す例と同様に表示して、全ての差額の資金運用を再度承諾するか、承諾する差額を選択し直すか、全ての差額の資金運用を拒否するかをユーザに選ばせる。このように第２の期間が経過したときに再度承諾を要求することで、この要求を行わない場合に比べて、ユーザに自分の意思が尊重されているとより強く感じさせ、満足度を向上させることができる。
【０１１９】
［２−９］資金の運用状況
ユーザが資金運用に充てることを承諾した資金の運用状況がユーザ端末で閲覧可能となっていてもよい。この場合、資金運用サーバ装置６が資金の運用状況を例えば資金運用支援サーバ装置２０を介してユーザ端末３０に提供し、ユーザ端末３０が提供された運用状況を表示する。提供される運用状況には、例えば、日々の株価等の動きに合わせて表示される運用資金のパフォーマンス、運用を継続した場合の将来の資金形成プロジェクション及び日々のトランザクションデータ等が含まれる。
【０１２０】
［２−１０］各部を実現する装置
図４等に表す各機能を実現する装置は、それらの図に表された装置に限らない。例えば家計簿サーバ装置１０及び資金運用支援サーバ装置２０が備える各機能を１台の装置が実現してもよいし、それらの各機能を３以上の装置がそれぞれ分担して実現してもよい。
【０１２１】
図１０は本変形例の資金運用支援システムが実現する機能構成の一例を表す。図１０では、家計簿サーバ装置１０ａ及び資金運用支援サーバ装置２０ａを備える資金運用支援システム１ａが表されている。家計簿サーバ装置１０ａは、図４に表す各部に加えて支払額取得部２０１及び差額算出部２０２を備える。資金運用支援サーバ装置２０ａは、図４に表す各部のうち、支払額取得部２０１及び差額算出部２０２以外の各部を備える。この場合、家計簿サーバ装置１０ａが蓄積した家計情報から支払額を取得し、差額を算出する。資金運用支援サーバ装置２０ａは、家計簿サーバ装置１０ａから算出された差額を取得する。
【０１２２】
図１１は本変形例のユーザ端末が実現する機能構成の一例を表す。図１１では、図４においてユーザ端末３０が備える各部に加え、資金運用支援サーバ装置２０が備える各部を備えるユーザ端末３０ｂが表されている。この場合、ユーザ端末３０ｂが、自装置を利用するユーザの支払額を取得して、差額の算出から承諾要求、承諾可否の受け付け、撤回の受け付け及び移動指示処理等を行う情報処理装置として用いられる。要するに、資金運用支援システム全体としてこれらの機能が実現されていれば、資金運用支援システムが何台の装置を備えていてもよい。
【０１２３】
［２−１１］第１の期間及び第２の期間
第１の期間は、上述した期間（１週間又は１週間＋月末の数日間）に限らない。例えば、１週間より短い期間又は長い期間であってもよいし、常に一定の期間であってもよい。第１の期間を一定にする場合、第２の期間は、実施例のように各月の期間にすることはできない（月によって日数が異なるため）。その場合は第１の期間を１週間とするなら例えば４週間を第２の期間とするというように、第２の期間を定めることになる。
【０１２４】
また、第１の期間が取得される差額に応じて変化してもよい。例えば、第１の期間は、差額取得部２０３により取得された差額の累積額が第１閾値未満になっている期間である。この場合、要求時期判断部２０５は、基準日の開始時には累積額を０として、差額取得部２０３により差額が取得される度にそれを加算して累積額を算出する。要求時期判断部２０５は、算出した累積額が第１閾値以上になった場合、基準日からその前日までを第１の期間として、第１の期間が経過した次の日、すなわち累積額が第１閾値以上になった日に要求時期になったと判断する。
【０１２５】
このように要求時期が判断されることで、承諾要求部２０６により承諾が要求される差額の合計金額は、第１閾値未満の金額となる。第１閾値としては、資金運用に対する心理的な抵抗がユーザに生じにくいと想定される金額（例えばアンケート等で調査した金額）が用いられるとよい。そうすることで、常にその金額よりも小さい金額について資金運用の承諾がユーザに要求されることになり、それ以上の金額の承諾が要求される場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。
【０１２６】
なお、上記第１閾値として、ユーザごとに異なる値が用いられるようにしてもよい。そのためのパラメータとして、例えば、登録されたユーザのプロファイル情報（性別、年代、居住地、趣味等）及び資金運用サーバ装置６から提供される資金の運用状況（パフォーマンス、資金形成プロジェクション、トランザクションデータ等）等のユーザ関連情報（ユーザに関する情報）が用いられる。
【０１２７】
図１２は本変形例の資金運用支援サーバ装置が実現する機能構成の一例を表す。図１２では、図４において資金運用支援サーバ装置２０が備える各部に加え、ユーザ関連情報取得部２１１と、ユーザ関連情報蓄積部２１２とを備える資金運用支援サーバ装置２０ｃが表されている。ユーザ関連情報取得部２１１は、例えば自装置の記憶手段からは資金運用支援システムにおいて登録されているユーザのプロファイル情報を取得し、図１に表す資金運用サーバ装置６から資金の運用状況を取得する。ユーザ関連情報取得部２１１は取得したユーザ関連情報をユーザ関連情報蓄積部２１２に供給する。
【０１２８】
ユーザ関連情報蓄積部２１２は、供給されたユーザ関連情報を、その情報が関連するユーザのユーザＩＤに対応付けて蓄積する。要求時期判断部２０５は、差額取得部２０３により取得された或るユーザの差額を加算して累積額を算出すると、そのユーザのユーザＩＤに対応付けて蓄積されているユーザ関連情報をユーザ関連情報蓄積部２１２から読み出す。要求時期判断部２０５は、算出した累積額が、読み出したユーザ関連情報に応じた第１閾値以上になった場合に、第１の期間が経過したと判断する。この判断は例えばユーザ関連情報と第１閾値とを対応付けた第１閾値テーブルを用いて行われる。
【０１２９】
図１３は第１閾値テーブルの一例を表す。図１３では、ユーザ関連情報として「Ａ１１未満」、「Ａ１１以上Ａ１２未満」、「Ａ１２以上」（Ａ１１＜Ａ１２）という運用額と、「Ｂ１１」、「Ｂ１２」、「Ｂ１３」（Ｂ１１＜Ｂ１２＜Ｂ１３）という第１閾値とが対応付けられている。要求時期判断部２０５は、例えば、ユーザ関連情報として読み出した運用額が「Ａ１１未満」であれば「Ｂ１１」を第１閾値として用いて、その運用額が「Ａ１２以上」であれば「Ｂ１３」を第１閾値として用いる。
【０１３０】
本変形例では、以上のとおり、ユーザ関連情報取得部２１１により取得されたユーザ関連情報に応じた値が第１閾値として用いられる。図１３に表す第１閾値テーブルを用いた場合、要求時期判断部２０５は、運用額が大きいユーザほど大きな第１閾値を用いることになる。一般に、運用額が大きいユーザほど、資金運用に積極的であり、資金運用に充てることを承諾しやすい金額も大きくなりやすい。一方で、第１閾値を小さくするほど、第１の期間が短くなり、頻繁に承諾要求が行われることになる。
【０１３１】
運用額が大きいユーザは、そのように頻繁に承諾要求を受け取るよりは、１回当たりの金額を大きくしてでも承諾要求の頻度が少ない方が煩わしくなくて気分よく承諾できる傾向になる。反対に、運用額が小さいユーザは、１回当たりの金額が大きいと承諾しにくくなるので、多少煩わしくても第１の期間を短くして１回当たりの金額を小さくした方が承諾しやすい傾向になる。本変形例では、上記の第１閾値を用いることで、ユーザの運用額に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、第１閾値が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。
【０１３２】
上述した累積額で第１の期間の長さを決める例において、第２の期間は、例えば決められた回数の第１の期間を含む期間とする。その場合、累積額が早く増えるほど第１の期間、第２の期間とも短くなる。また、上記例において、第２の期間を一定の期間としてもよい（第２の期間が終了したときには、第１の期間もその時点での累積額にかかわらず終了する）。その場合、累積額が早く増えるほど第２の期間に含まれる第１の期間の数が多くなる。
【０１３３】
上述したいずれの例においても、第２の期間には複数の第１の期間が含まれており、第２の期間が終了すると、最後の第１の期間も終了し、次の第２の期間は、次の第１の期間と同じタイミングで開始される。第１の期間及び第２の期間は、７日間など１日単位で定められてもよいし、週単位、月単位、時間単位又は分単位等、どのような時間の単位で定められてもよい。
【０１３４】
また、前述したユーザ関連情報に応じて第１の期間及び第２の期間をユーザごとに異ならせてもよい。例えば、承諾要求部２０６が、ユーザ関連情報取得部２１１により取得されたユーザ関連情報に応じた期間が第１の期間として経過するごとに承諾要求を行ってもよい。この場合、要求時期判断部２０５は、第１の期間が経過したか否かの判断を、例えばユーザ関連情報と第１の期間とを対応付けた第１の期間テーブルを用いて行う。
【０１３５】
図１４は第１の期間テーブルの一例を表す。図１４では、ユーザ関連情報として「Ｃ１１未満」、「Ｃ１１以上Ｃ１２未満」、「Ｃ１２以上」（Ｃ１１＜Ｃ１２）という承諾回数と、「Ｄ１１」、「Ｄ１２」、「Ｄ１３」（Ｄ１１＜Ｄ１２＜Ｄ１３）という第１の期間とが対応付けられている。承諾回数とは、お釣り運用サービスにおいてこれまでに資金運用を承諾した回数である。要求時期判断部２０５は、例えば、ユーザ関連情報として読み出した承諾回数が「Ｃ１１未満」であれば「Ｄ１１」を第１の期間として用いて、その承諾回数が「Ｃ１２以上」であれば「Ｄ１３」を第１の期間として用いる。
【０１３６】
資金運用の承諾のしやすさについていうと、承諾回数が多いユーザは、資金運用に積極的なので、上述した運用額が大きいユーザと同じ傾向になり、承諾回数が少ないユーザは、資金運用に消極的なので、上述した運用額が小さいユーザと同じ傾向になる。本変形例では、上記の第１の期間を用いることで、ユーザの承諾回数に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、第１の期間が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。
【０１３７】
また、例えば、移動指示処理実行部２１０が、ユーザ関連情報取得部２１１により取得されたユーザ関連情報に応じた期間が第２の期間として経過すると、移動指示処理を実行してもよい。この場合、資金移動時期判断部２０９は、第２の期間が経過したか否かの判断を、例えばユーザ関連情報と第２の期間とを対応付けた第２の期間テーブルを用いて行う。
【０１３８】
図１５は第２の期間テーブルの一例を表す。図１５では、ユーザ関連情報として「２０代以下」、「３０代、４０代」、「５０代以上」という年代と、「Ｆ１１」、「Ｆ１２」、「Ｆ１３」（Ｆ１１＜Ｆ１２＜Ｆ１３）という第２の期間とが対応付けられている。資金移動時期判断部２０９は、例えば、ユーザ関連情報として読み出したユーザの年代が「２０代」であれば「Ｆ１１」を第２の期間として用いて、その年代が「５０代以上」であれば「Ｆ１３」を第２の期間として用いる。
【０１３９】
第２の期間が長いほど、第２の期間が経過した後に口座から移動する資金の金額が大きくなりやすい。そのため、収入が多いユーザほど、資金運用に積極的になりやすい。資金運用の承諾のしやすさについていえば、年代が高いユーザは、収入が多いので資金運用に積極的になりやすく上述した運用額が大きいユーザと同じ傾向になり、年代が低いユーザは、収入が少ないので資金運用に消極的になりやすく上述した運用額が小さいユーザと同じ傾向になる。本変形例では、上記の第２の期間を用いることで、ユーザの年代に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、第２の期間が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。
【０１４０】
なお、図１３、図１４、図１５の例で述べたパラメータとして用いられるユーザ関連情報（運用額、承諾回数、年代）は、これらに限らず、他のユーザ関連情報（利益額、利益率、拒否回数、職業等）が用いられてもよい。いずれの場合も、資金運用への積極性と相関があるユーザ関連情報が用いられることで、ユーザのその積極性に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、各期間が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。
【０１４１】
また、ユーザ関連情報に応じた第１閾値、第１の期間及び第２の期間を用いた場合の資金運用の承諾率（例えば全差額の件数のうち資金運用を承諾された差額の件数の割合）を取得して、承諾率が目標値よりも低い場合には、ユーザ関連情報との相関性を変化させてもよい。例えば図１３の例であれば、要求時期判断部２０５は、取得した承諾率が目標値よりも低い場合には、運用額の閾値であるＡ１１及びＡ１２の値を大きくし、又は小さくして、承諾率が目標値よりも高くなる場合の値を求める。また、運用額の閾値ではなく、第１閾値の値を変化させてもよいし、それらの両方の値を変化させてもよい。要求時期判断部２０５が図１４に表す各値を求める場合も、資金移動時期判断部２０９が図１５に表す各値を求める場合も同様である。
【０１４２】
また、第１の期間として、ユーザ端末３０がプログラムを起動させたときに満了する期間が用いられてもよい。ユーザ端末３０は、ユーザの操作によりプログラムを起動させてもよいし、本体の電源が投入されたときにプログラムを起動させてもよい。ここでいうプログラムは、図４に表す各部を実現するためのプログラムであり、例えばお釣り運用サービスを提供する事業者が提供するアプリケーションプログラムである。この場合、ユーザ端末３０は、プログラムを起動すると、その旨を資金運用支援サーバ装置２０に通知する。資金運用支援サーバ装置２０の要求時期判断部２０５は、この通知を受け取ると、第１の期間が満了し、承諾要求を行う時期になったと判断する。こうして、承諾要求部２０６は、ユーザ端末３０がプログラムを起動させる度に、すなわち第１の期間が経過するごとに承諾をユーザに要求する。
【０１４３】
［２−１２］受取額
実施例では、ユーザがお金を支払ったときの金額（支払額）とそれを切り上げた額との差額が資金運用の対象であったが、これに限らず、例えば、ユーザがお金を受け取ったときの受取額とそれを切り下げた額との差額（いわゆる端数）を資金運用の対象としてもよい。ユーザが受け取るお金には、例えば、ユーザの給料、ユーザが保有する株式の配当金、及び、ユーザが保有する不動産の賃貸料等が含まれる。
【０１４４】
この場合、差額取得部２０３は、ユーザが受け取った受取額とその受取額を切り下げた額との差額を取得する。承諾要求部２０６は、第１の期間が経過するごとに、その第１の期間の満了以前に受け取った１以上の受取額における差額を資金運用に充てることについての承諾をユーザに要求する。以降は、実施例と同様に承諾の可否の受け付け及び移動指示処理等が行われる。本変形例では、ユーザが受け取ったお金についても、その切り下げ額との差額を資金運用に充てることができる。
【０１４５】
［２−１３］取得する金額
差額取得部２０３は、上記の各例では、支払額については切り上げ額との差額を取得し、受取額については切り下げ額との差額を取得したが、これに限らない。差額取得部２０３は、支払額について切り下げ額との差額を取得してもよいし、受取額について切り上げ額との差額を取得してもよい。また、差額取得部２０３は、上記の支払額又は受取額に特定の値（例えば３％）を乗じた金額を取得してもよい。
【０１４６】
また、差額取得部２０３は、特定の支出項目の支払額に対してユーザが設定した目標値と支払額との差額を取得してもよい。この場合、ユーザは、例えば毎月の電気代及び生活費等の目標値を設定しておく。差額取得部２０３は、目標値が設定された支出項目の支払額がその目標値を下回った場合に、目標値と支払額との差額を取得する。これにより、ユーザが節約するほど運用する資金が増える一方、どれだけ運用資金が増えても上記支出項目については目標値を超える支出は生じない。これにより、ユーザは資金運用のために予期せぬ支出が生じるという心配をすることなく資金運用を行うことができる。
【０１４７】
また、差額取得部２０３は、特定の収入項目の受取額に対してユーザが設定した目標値と受取額との差額を取得してもよい。この場合、ユーザは、例えば月収（残業等で変動する）及び株式配当等の目標値を設定しておく。差額取得部２０３は、目標値が設定された収入項目の受取額がその目標値を上回った場合に、目標値と支払額との差額を取得する。これにより、ユーザは目標値に相当する収入を確保したうえで資金運用を行うことができる。
【０１４８】
要するに、差額取得部２０３は、商取引における支払額に基づき算出される金額（切り上げ額との差額、切り下げ額との差額、特定の値を乗じた額及び目標値との差額等）を取得するか、ユーザが受け取った受取額に基づき算出される金額（こちらも切り上げ額との差額、切り下げ額との差額、特定の値を乗じた額及び目標値との差額等）を取得するものであればよい。
【０１４９】
［２−１３］差額の絞り込み
実施例では、ユーザが行った支払いに基づいて算出された全ての差額について資金運用の承諾が要求されたが、これに限らない。例えば、特定の店舗で商品を購入した場合の差額に絞り込んでもよい。また、特定の決済方法で決済した場合の差額に絞り込んでもよいし、特定の商品を購入した場合の差額に絞り込んでもよい。
【０１５０】
図１６は本変形例の資金運用支援サーバ装置２０ｄが実現する機能構成の一例を表す。資金運用支援サーバ装置２０ｄは、図４に表す各部に加え、商取引関連情報取得部２１３と、差額判別部２１４とを備える。本変形例では、家計簿サーバ装置１０の家計情報蓄積部１０３が、店舗名（チェーン店の名称等）及び購入に用いた決済方法の名称（クレジットカード会社名又は電子マネーの名称等）を含む支出情報を蓄積する。店舗名は、商取引において購入された商品の購入先を示す情報であり、決済方法の名称は、商取引において用いられた決済手段を示す情報である。
【０１５１】
家計簿サーバ装置１０は、店舗名及び決済方法の名称を、上述した個人向けサイトや、レシートからそれらの情報を読み取ったユーザ端末３０から取得する。なお、これらの方法で店舗名や決済方法の名称が取得できない場合は、家計簿サーバ装置１０は、例えば店舗で利用されているＰＯＳシステムや決済サービスを提供する事業者の電子決済システムから店舗名や決済方法の名称を取得してもよい。支払額取得部２０１は、実施例で述べたように家計簿サーバ装置１０から支出情報及びユーザＩＤを受け取ることで、そのユーザＩＤのユーザが商取引の際に支払った支払額を取得する。支払額取得部２０１は、受け取った支出情報及びユーザＩＤを商取引関連情報取得部２１３に供給する。
【０１５２】
商取引関連情報取得部２１３は、ユーザの商取引に関連する情報を取得する機能であり、例えば、前述した購入先及び決済方法の名称を商取引の関連情報として取得する。商取引関連情報取得部２１３は、支払額取得部２０１から支出情報及びユーザＩＤを受け取ることで、その支出情報が示す店舗名及び決済方法の名称を、そのユーザＩＤのユーザが行った商取引における購入先及び決済手段として取得する。商取引関連情報取得部２１３は、取得した商取引の関連情報を示す支出情報を、対応するユーザＩＤとともに差額判別部２１４に供給する。差額判別部２１４には、差額取得部２０３からも、取得した差額とそれに対応するユーザＩＤ及び支出情報とが供給される。
【０１５３】
差額判別部２１４は、差額算出部２０２により支払額に基づき算出された差額のうち、所定の条件を満たす商取引についての差額を判別する。差額判別部２１４は、商取引における購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である場合に、その商取引が所定の条件を満たすと判断する。本変形例では、例えば、事業者αが運営する店舗が特定の購入先であり、事業者βが提供する決済サービスが特定の決済手段であるものとする。
【０１５４】
差額判別部２１４は、差額が供給されると、その差額と同じユーザＩＤに対応付けて供給された商取引の関連情報が示す店舗名及び決済方法の名称が、事業者αが運営する店舗名又は事業者βが提供する決済サービスの名称である場合、その差額が所定の条件を満たす商取引についての差額だと判別し、そうでない場合、その差額が所定の条件を満たす商取引についての差額ではないと判別する。差額判別部２１４は、供給された差額、ユーザＩＤ及び支出情報を、判別結果とともに差額蓄積部２０４に供給する。
【０１５５】
差額蓄積部２０４は、差額判別部２１４から供給された差額、ユーザＩＤ及び判別結果を、差額ＩＤ及びともに供給された支出情報が示す支払日に対応付けて記憶する。
図１７は本変形例で蓄積されている差額の一例を表す。図１７の例では、差額蓄積部２０４は、ユーザＩＤと、支払日と、差額と、差額ＩＤと、運用対象フラグと、ステータスとを対応付けて記憶している。
【０１５６】
運用対象フラグは、差額判別部２１４による判別結果を示す情報である。この例では、所定の条件を満たす商取引についての差額であると判別された差額には「対象」という運用対象フラグが対応付けられ、所定の条件を満たす商取引についての差額ではないと判別された差額には「対象外」という運用対象フラグが対応付けられている。「対象」という運用対象フラグは、ユーザの承諾が得られれば（又は既に承諾が得られていて）運用の対象にする差額であることを意味し、「対象外」という運用対象フラグは、その差額は運用の対象ではなく、ユーザへの承諾の要求もされないことを意味している。
【０１５７】
差額蓄積部２０４は、運用対象フラグが「対象外」である差額については、ステータスも「対象外」として記憶する。要求時期判断部２０５は、要求時期になったと判断すると、実施例と同様に、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうち、ステータスが「未要求」であるものを読み出して承諾要求部２０６に供給する。このとき、ステータスが「対象外」である差額は読み出されない。そのため、運用対象フラグが「対象」である差額のうちステータスが「未要求」であるものだけが、要求時期判断部２０５によって読み出されて承諾要求部２０６に供給される。
【０１５８】
承諾要求部２０６は、こうして供給された差額を資金運用に充てることについての承諾をユーザに要求する。つまり、承諾要求部２０６は、支払額に基づき算出される差額のうち、所定の条件を満たす商取引についての差額を資金運用に充てることについての承諾をユーザに要求する。詳細には、承諾要求部２０６は、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である商取引の支払額に基づき算出される差額を、所定の条件を満たす商取引についての差額として、その差額についての承諾の要求を行う。
【０１５９】
以上のとおり、本変形例では、ユーザが行った支払いに基づいて算出された全ての差額ではなく、特定の購入先で商品を購入した支払いの差額と、特定の決済手段を用いた支払いの差額に絞り込んで、資金運用の承諾が要求される。これにより、それら特定の購入先及び決済手段を利用する動機をユーザに生じさせ、全ての差額について承諾を要求する場合に比べて、それら特定の購入先及び決済手段が利用されやすいようにすることができる。
【０１６０】
なお、所定の条件は上記のものに限らない。例えば、差額判別部２１４は、商取引における購入対象が予め定められた特定の商品である場合に、その商取引が所定の条件を満たすと判断してもよい。ここでいう特定の商品とは、個別の商品であってもよいし、特定の事業者が提供する商品群であってもよい。以下では事業者γが提供する商品を特定の商品とする。この場合、例えば支出情報が示す商品名に基づいて、購入対象が予め定められた特定の商品であるか否かが判断される。この判断が行われると、全ての差額について承諾を要求する場合に比べて、特定の商品が購入されやすいようにすることができる。
【０１６１】
また、差額判別部２１４は、商取引における購入先、決済手段及び購入対象という各事項のうち、いずれか１つの事項だけを所定の条件の判断に用いてもよいし、２以上の事項を所定の条件の判断に用いてもよい。また、家計簿サーバ装置１０に店舗名や決済方法の名称を示す支出情報が蓄積されていない場合は、商取引関連情報取得部２１３が、例えばその店舗で利用されているＰＯＳシステムや決済サービスを提供する事業者の電子決済システムから、各ユーザの商取引が行われた店舗名や決済方法の名称をユーザの商取引に関連する情報として取得すればよい。
【０１６２】
また、図１６の例では、所定の条件を満たす商取引についての差額を判別したが、これに限らず、例えば、支払額取得部２０１が、所定の条件を満たす商取引についての支払額だけを取得してもよい。支払額取得部２０１は、例えば、受け取った支出情報に基づいて、差額判別部２１４と同様に、その支出情報が示す支払いが行われた商取引が所定の条件を満たすか否かを判断すればよい。この場合、差額蓄積部２０４には、商取引が所定の条件を満たす差額だけが蓄積される。
【０１６３】
その結果、承諾要求部２０６は、上記の例と同様に、支払額に基づき算出される差額のうち、所定の条件を満たす商取引についての差額を資金運用に充てることについての承諾をユーザに要求することになる。要するに、最終的に承諾要求部２０６が所定の条件を満たす商取引についての差額を資金運用に充てることについての承諾をユーザに要求することになっていれば、商取引が所定の条件を満たすか否かの判断がどこで行われてもよい。
【０１６４】
［２−１４］有利な条件での運用
上述した差額の絞り込みが行われる場合に、追加の条件が満たされると、その条件が満たされない場合に比べて有利な条件での資金運用がユーザに提示されてもよい。追加の条件としては、例えば、商取引が予め定められた期間に行われた場合に満たされる条件が用いられる。
【０１６５】
本変形例では、例えば商取引における上述した特定の事項（特定の購入先、特定の決済手段、特定の購入対象）に関係する事業者（店舗を運営する事業者、決済サービスを提供する事業者、商品を提供する事業者等）が、特定の期間をキャンペーン期間として定めている。そのように特定の事項について特定の期間が定められている場合に、承諾要求部２０６は、それら特定の事項に関連する商取引が、その特定の事項について定められた特定の期間に行われた場合は、その期間以外に商取引が行われたときに比べて有利な条件で差額を資金運用に充てることについての承諾をユーザに要求する。
【０１６６】
ここでいう特定の事項に関連する商取引とは、特定の購入先で行われた商取引、特定の決済手段が用いられた商取引、又は、特定の購入対象が購入された商取引等である。また、有利な条件での資金運用とは、例えば、資金運用のための手数料の割引や運用する資金の増額、格付けが特定のレベルより高い金融商品の活用、手続きの短縮、手続きの期限の緩和など、ユーザが金銭的又は時間的な利益を得られる条件を適用して行われる資金運用のことをいう。承諾要求部２０６は、上記の商取引が特定の期間に行われた場合は、有利な条件で差額を資金運用に充てることを表す文字列と、差額ＩＤ、差額及び支払日とを示す要求データを生成してユーザ端末３０に送信する。
【０１６７】
図１８は表示された承諾要求の一例を表す。図１８の例では、承諾要求表示部３０３は、選択された差額の「合計金額」（この例では１１８３円）の他、「キャンペーン対象金額」（この例では４２３円）と、「キャンペーン対象金額については資金が１０％増額されます！」という文字列とを、要求データが示す承諾要求Ａ２１として表示している。また、承諾要求表示部３０３は、全選択ボタンＢ３の他に、「キャンペーン対象を全て選択」と書かれた選択ボタンＢ７を表示している。
【０１６８】
選択ボタンＢ７を押す操作が行われた場合、「キャンペーン対象金額」のうち選択されていないものがあれば、それらが選択される。この選択ボタンＢ７を表示することで、キャンペーン対象金額の選択漏れがなくなるようにしている。本変形例では、このように承諾要求Ａ２１が表示されることで、前述した有利な条件で差額を資金運用に充てることについての承諾がユーザに要求される。これにより、この要求が行われない場合に比べて、資金運用をより積極的に行う動機をユーザに生じさせ、前述した特定の事項に関連する商取引を増加させることができる。
【０１６９】
なお、特定の期間は、特定の事項（例えば特定の店舗や特定の決済手段）について定められているものに限らない。例えば、承諾要求部２０６は、所定の条件を満たす商取引が予め定められた期間に行われた場合に、その商取引について算出された金額を、所定の期間以外に行われた商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求してもよい。この場合、所定の期間において、特定の店舗又は特定の決済手段等のいずれかを用いて所定の条件を満たしさえすれば、有利な条件での資金運用を行うことができる。
【０１７０】
なお、追加の条件は上述した特定の期間に限らない。承諾要求部２０６は、上述した購入対象、購入先及び決済手段のうち２以上の事項が前述した特定の事項である商取引について算出された金額を、この商取引以外の所定の条件を満たす商取引（つまり１つの事項だけが特定の事項である商取引）に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求してもよい。具体的には、承諾要求部２０６は、例えばユーザが特定の購入先である事業者αが運営する店舗で、特定の決済手段である事業者βが提供する決済サービスを用いて商品を購入した場合に、その商取引について算出された差額を有利な条件で資金運用に充てることについての承諾をユーザに要求する。
【０１７１】
他にも、承諾要求部２０６は、ユーザが、特定の購入先である事業者αが運営する店舗で特定の商品である事業者γが提供する商品を購入した場合や、特定の決済手段である事業者βが提供する決済サービスを用いて特定の商品である事業者γが提供する商品を購入した場合に、それらの商取引について算出された差額を有利な条件で資金運用に充てることについての承諾をユーザに要求する。これにより、この要求が行われない場合に比べて、資金運用をより積極的に行う動機をユーザに生じさせ、２以上の特定の事項に関連する商取引を増加させることができる。
【０１７２】
［２−１５］差額の集金方法
実施例では、移動指示処理実行部２１０が移動指示処理を実行することで、承諾を得られた差額の累積額が第１の口座から集金され、第２の口座に移動したが、差額の累積額の集金方法はこれに限らない。例えば、ユーザからの集金を代行する事業者に委託して差額の累積額を集金してもよい。集金を代行する事業者とは、例えば、通信事業者や電力会社、クレジットカード会社、保険会社など、本業でユーザから集金を行っている事業者である。
【０１７３】
図１９は本変形例の資金運用支援サーバ装置２０ｅが実現する機能構成の一例を表す。資金運用支援サーバ装置２０ｅは、図４に表す移動指示処理実行部２１０に代えて、集金情報通知部２１５を備える。集金情報通知部２１５は、移動指示処理実行部２１０と同様に、第１の期間を複数含む第２の期間が経過すると、差額の累積額を算出する。集金情報通知部２１５は、算出した累積額を示す情報を、ユーザの口座から集金する（引き落とす）金額を示す集金情報として生成する。
【０１７４】
集金情報通知部２１５は、生成した集金情報を、予め記憶しておいた集金の代行事業者について定められた宛先に送信する。この宛先は、代行事業者が運用する集金のための処理を行う集金処理装置であってもよいし、その集金処理装置を含むシステムの外部とのインターフェースとなっている装置であってもよい。この宛先に送信された集金情報は、集金処理装置により受け取られて、集金処理装置が、ユーザの口座から差額の累積額を引き落とす処理を行う。
【０１７５】
本変形例では、集金の代行事業者は、上述した通信事業者や電力会社などのように、本業の集金を定期的に（例えば毎月）行っているものとする。そこで、集金処理装置は、本業で集金する金額に差額の累積額を加算した金額をユーザの口座から引き落とす処理を行う。集金処理装置は、こうして引き落とした金額をまずは自身を運用する事業者の口座に移動させる。続いて、集金処理装置は、事業者の口座から差額の累積額を資金運用会社の口座に移動させる（振り込む）処理を行う。これらの処理により、各ユーザの口座から差額の累積額が資金運用会社の口座に移動する。
【０１７６】
本変形例では、以上のとおり、集金情報通知部２１５が、第１の期間を複数含む第２の期間が経過すると、ユーザにより承諾を得られた差額の累積額を、その累積額の集金を代行する事業者に通知する。集金情報通知部２１５は本発明の「通知部」の一例である。実施例のように各ユーザの資金が収められている第１の口座から第２の口座（資金運用会社の口座）に累積額を移動させる場合、第１の口座の数だけ口座移動の手数料が発生する。
【０１７７】
これに対し、本変形例では、集金を代行する事業者が通信事業者や電力会社などのように定期的にユーザから集金を行っている事業者の場合、上記のとおりその集金の金額に累積額を加算して集金することになる。その場合、集金を代行する事業者にとっては、ユーザの口座から累積額を引き落とす際に発生する手数料は変化せず、自身の口座から資金運用会社の口座への振り込み手数料だけが新たに発生する。
【０１７８】
そのため、第１の口座の数だけ口座移動の手数料が発生する場合に比べて、銀行に支払う手数料が大きく減少するので、減少した手数料の範囲で集金の代行事業者に代行の手数料を支払えば、お釣り運用サービスに係る費用を削減することができる。なお、本変形例においては、集金を代行する事業者の口座には、ユーザから集金した累積額、すなわち上述したユーザが利用可能なお金が収められている。つまり、この口座を管理する銀行サーバは、図１に表す銀行サーバ４に相当することになる。
【０１７９】
そこで、移動指示処理実行部２１０が、例えば前述した集金処理装置に対して、集金を代行する事業者の口座を第１の口座とし、資金運用会社の口座を第２の口座として、第１の口座から第２の口座への移動を指示する移動指示処理を実行してもよい。集金処理装置は、この指示を受け取ると、第１の口座から第２の口座へ移動する累積額をユーザの口座から引き落とし、第１の口座である事業者の口座に移動してから、その累積額を第２の口座に移動する処理を行う。集金情報通知部２１５による通知を行うか、移動指示処理実行部２１０が移動指示処理を行うかは、集金を代行する事業者側のシステムが処理しやすい方が選ばれればよい。
【０１８０】
［２−１６］発明のカテゴリ
本発明は、資金運用支援サーバ装置、ユーザ端末及び家計簿サーバ装置のような情報処理装置の他、それらの装置を備える資金運用支援システムのような情報処理システムとしても捉えられる。また、本発明は、各装置が実施する処理を実現するための情報処理方法としても捉えられる。その場合、各処理を実現する主体となる情報処理装置は複数に分かれていてもよい。また、各装置を制御するコンピュータを機能させるためのプログラムとしても捉えられる。このプログラムは、それを記憶させた光ディスク等の記録媒体の形態で提供されてもよいし、インターネット等のネットワークを介してコンピュータにダウンロードさせ、それをインストールして利用可能にするなどの形態で提供されてもよい。
【符号の説明】
【０１８１】
１…資金運用支援システム、１０…家計簿サーバ装置、１０１…収入情報取得部、１０２…支出情報取得部、１０３…家計情報蓄積部、２０…資金運用支援サーバ装置、２０１…支払額取得部、２０２…差額算出部、２０３…差額取得部、２０４…差額蓄積部、２０５…要求時期判断部、２０６…承諾要求部、２０７…承諾可否受付部、２０８…撤回受付部、２０９…資金移動時期判断部、２１０…移動指示処理実行部、２１１…ユーザ関連情報取得部、２１２…ユーザ関連情報蓄積部、２１３…商取引関連情報取得部、２１４…差額判別部、２１５…移動情報通知部、３０…ユーザ端末、３０１…レシート読取部、３０２…支出情報送信部、３０３…承諾要求表示部、３０４…承諾可否操作受付部、３０５…承諾可否通知部、３０６…履歴表示部、３０７…撤回操作受付部、３０８…撤回通知部。
【図１】
2018097831.tif 000003
【図２】
2018097831.tif 000004
【図３】
2018097831.tif 000005
【図４】
2018097831.tif 000006
【図５】
2018097831.tif 000007
【図６】
2018097831.tif 000008
【図７】
2018097831.tif 000009
【図８】
2018097831.tif 000010
【図９】
2018097831.tif 000011
【図１０】
2018097831.tif 000012
【図１１】
2018097831.tif 000013
【図１２】
2018097831.tif 000014
【図１３】
2018097831.tif 000015
【図１４】
2018097831.tif 000016
【図１５】
2018097831.tif 000017
【図１６】
2018097831.tif 000018
【図１７】
2018097831.tif 000019
【図１８】
2018097831.tif 000020
【図１９】
2018097831.tif 000021
【手続補正書】
【提出日】平成29年7月25日(2017.7.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部と
を備える情報処理装置。
【請求項２】
前記蓄積部は、前記支払額と当該支払額を切り上げた額との差額を前記金額として蓄積する
請求項１に記載の情報処理装置。
【請求項３】
前記承諾の撤回を受け付ける受付部を備え、
前記実行部は、前記承諾が得られてから前記第２の期間が経過して前記処理を実行する前に当該承諾の撤回が受け付けられた場合、当該承諾が撤回された前記金額を前記累積額から減じて前記処理を実行する
請求項１又は２に記載の情報処理装置。
【請求項４】
前記蓄積部は、前記累積額を前記第１の口座から前記第２の口座へ移動する際に必要な手続きが完了する前になされた商取引における前記金額を蓄積し、
前記実行部は、前記手続きが完了した後に前記処理を実行する
請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
前記承諾要求部は、前記手続きが完了する前に前記要求を行う
請求項４に記載の情報処理装置。
【請求項６】
前記第１の期間は、蓄積された前記金額の累積額が閾値未満になっている期間である
請求項１から５のいずれか１項に記載の情報処理装置。
【請求項７】
前記ユーザに関する関連情報を取得する関連情報取得部を備え、
前記閾値として、取得された前記関連情報に応じた値が用いられる
請求項６に記載の情報処理装置。
【請求項８】
前記ユーザに関する関連情報を取得する関連情報取得部を備え、
前記承諾要求部は、取得された前記関連情報に応じた期間が前記第１の期間として経過するごとに前記要求を行う
請求項１から７のいずれか１項に記載の情報処理装置。
【請求項９】
前記ユーザに関する関連情報を取得する関連情報取得部を備え、
前記実行部は、取得された前記関連情報に応じて予め長さが定められる期間が前記第２の期間として経過すると、前記処理を実行する
請求項１から８のいずれか１項に記載の情報処理装置。
【請求項１０】
前記承諾要求部は、前記支払額に基づき算出される金額のうち、所定の条件を満たす商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求する
請求項１から９のいずれか１項に記載の情報処理装置。
【請求項１１】
前記所定の条件は、購入対象、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である場合に満たされる
請求項１０に記載の情報処理装置。
【請求項１２】
前記承諾要求部は、購入対象、購入先及び決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する
請求項１１に記載の情報処理装置。
【請求項１３】
商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額を、当該累積額の集金を代行する事業者に通知する通知部と
を備える情報処理装置。
【請求項１４】
ユーザが受け取った受取額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前に受け取った１以上の受取額における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部と
を備える情報処理装置。
【請求項１５】
請求項１から１４のいずれか１項に記載の情報処理装置と、
前記情報処理装置から前記金額を資金運用に充てることについての承諾を要求された場合に当該要求を表示する表示部と、当該要求が表示されて前記資金運用を承諾する操作が行われた場合にその旨を前記情報処理装置に通知する通知部とを備えるユーザ端末と
を備える情報処理システム。
【請求項１６】
商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部であって、当該金額のうち、所定の条件を満たす商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求し、当該商取引が予め定められた期間に行われた場合には、当該商取引について算出された金額を、当該期間以外に行われた商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部と
を備える情報処理装置。
【請求項１７】
請求項１６に記載の情報処理装置と、
前記情報処理装置から前記金額を資金運用に充てることについての承諾を要求された場合に当該要求を表示する表示部と、当該要求が表示されて前記資金運用を承諾する操作が行われた場合にその旨を前記情報処理装置に通知する通知部とを備えるユーザ端末と
を備える情報処理システム。
【請求項１８】
情報処理装置が、商取引における支払額に基づき算出される金額を蓄積するステップと、
情報処理装置が、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求するステップと、
情報処理装置が、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行するステップと
を備える情報処理方法。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
上記目的を達成するために、本発明は、商取引における支払額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部とを備える情報処理装置を提供する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
また、前記蓄積部は、前記支払額と当該支払額を切り上げた額との差額を前記金額として蓄積してもよい。
さらに、前記承諾の撤回を受け付ける受付部を備え、前記実行部は、前記承諾が得られてから前記第２の期間が経過して前記処理を実行する前に当該承諾の撤回が受け付けられた場合、当該承諾が撤回された前記金額を前記累積額から減じて前記処理を実行してもよい。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
また、前記ユーザに関する関連情報を取得する関連情報取得部を備え、前記閾値として、取得された前記関連情報に応じた値が用いられてもよい。
さらに、前記ユーザに関する関連情報を取得する関連情報取得部を備え、前記承諾要求部は、取得された前記関連情報に応じた期間が前記第１の期間として経過するごとに前記要求を行ってもよい。
また、前記ユーザに関する関連情報を取得する関連情報取得部を備え、前記実行部は、取得された前記関連情報に応じて予め長さが定められる期間が前記第２の期間として経過すると、前記処理を実行してもよい。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
また、前記承諾要求部は、購入対象、購入先及び決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求してもよい。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
また、本発明は、商取引における支払額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額を、当該累積額の集金を代行する事業者に通知する通知部とを備える情報処理装置を提供する。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
また、本発明は、ユーザが受け取った受取額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前に受け取った１以上の受取額における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部とを備える情報処理装置を提供する。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
また、本発明は、  商取引における支払額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部であって、当該金額のうち、所定の条件を満たす商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求し、当該商取引が予め定められた期間に行われた場合には、当該商取引について算出された金額を、当該期間以外に行われた商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部とを備える情報処理装置を提供する。
また、本発明は、上記の情報処理装置と、前記情報処理装置から前記金額を資金運用に充てることについての承諾を要求された場合に当該要求を表示する表示部と、当該要求が表示されて前記資金運用を承諾する操作が行われた場合にその旨を前記情報処理装置に通知する通知部とを備えるユーザ端末とを備える情報処理システムを提供する。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
また、本発明は、情報処理装置が、商取引における支払額に基づき算出される金額を蓄積するステップと、情報処理装置が、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求するステップと、情報処理装置が、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行するステップとを備える情報処理方法を提供する。
【手続補正書】
【提出日】平成29年11月15日(2017.11.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部であって、前記支払額に基づき算出される金額のうち、購入対象、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である商取引を所定の条件を満たす商取引として当該商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求し、購入対象、購入先又は決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部と
を備える情報処理装置。
【請求項２】
商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部であって、当該金額のうち、所定の条件を満たす商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求し、当該商取引が予め定められた期間に行われた場合には、当該商取引について算出された金額を、当該期間以外に行われた商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する承諾要求部と、
前記第１の期間を複数含む第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部と
を備える情報処理装置。
【請求項３】
請求項２に記載の情報処理装置と、
前記情報処理装置から前記金額を資金運用に充てることについての承諾を要求された場合に当該要求を表示する表示部と、当該要求が表示されて前記資金運用を承諾する操作が行われた場合にその旨を前記情報処理装置に通知する通知部とを備えるユーザ端末と
を備える情報処理システム。
【請求項４】
情報処理装置が、商取引における支払額に基づき算出される金額を蓄積するステップと、
情報処理装置が、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求するステップであって、前記支払額に基づき算出される金額のうち、購入対象、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である商取引を所定の条件を満たす商取引として当該商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求し、購入対象、購入先又は決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求するステップと、
情報処理装置が、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行するステップと
を備える情報処理方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
上記目的を達成するために、本発明は、商取引における支払額に基づき算出される金額を蓄積する蓄積部と、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求する承諾要求部であって、前記支払額に基づき算出される金額のうち、購入対象、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である商取引を所定の条件を満たす商取引として当該商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求し、購入対象、購入先又は決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する承諾要求部と、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行する実行部とを備える情報処理装置を提供する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】削除
【補正の内容】
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】削除
【補正の内容】
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】削除
【補正の内容】
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】削除
【補正の内容】
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】削除
【補正の内容】
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】削除
【補正の内容】
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】削除
【補正の内容】
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】削除
【補正の内容】
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
また、本発明は、情報処理装置が、商取引における支払額に基づき算出される金額を蓄積するステップと、情報処理装置が、第１の期間が経過するごとに、当該第１の期間の満了以前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾をユーザに要求するステップであって、前記支払額に基づき算出される金額のうち、購入対象、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である商取引を所定の条件を満たす商取引として当該商取引についての前記金額を資金運用に充てることについての承諾をユーザに要求し、購入対象、購入先又は決済手段のうち２以上の事項が前記特定の事項である商取引について算出された金額を、当該商取引以外の前記所定の条件を満たす商取引に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求するステップと、情報処理装置が、前記第１の期間を複数含み且つ予め長さが定められる第２の期間が経過すると、前記承諾を得られた前記金額の累積額の第１の口座から第２の口座への移動を指示する処理を実行するステップとを備える情報処理方法を提供する。