JP6337224B1 - 情報処理装置 - Google Patents

Abstract

【課題】資金移動の回数を少なくしつつ、ユーザの資金運用の承諾を得やすくすること。【解決手段】支払額取得部２０１は、商取引における支払額を取得する。差額算出部２０２は、取得された支払額とその支払額を切り上げた額との差額を算出する。差額取得部２０３は、算出された差額を取得する。承諾取得部２２０は、ユーザにより所定の操作が行われた場合に、その操作が行われる前になされた１以上の商取引における上記の差額を資金として運用に充てるサービスを利用することについての承諾を取得する。資金移動時期判断部２０９は、所定の期間が経過すると、資金運用の承諾を得られた差額の累積額を第１の口座から第２の口座に移動する移動時期になったと判断する。移動指示処理実行部２１０は、その累積額の移動を指示する移動指示処理を実行する。【選択図】図４

Description

本発明は、ユーザに資金を活用してもらうための技術に関する。

ユーザに資金を活用してもらうための技術がある。例えば特許文献１には、釣り銭とこの釣り銭を受け取るべき者に関するデータを登録しておき、投資サーバが、ＡＴＭ端末などから投資を行う旨の情報を受信するとこの情報に基づいて投資関連運用事業者側システムにアクセスし、投資関連運用事業者側システムが所定の投資処理を行う技術が開示されている。

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

ユーザの資金運用は、ユーザの承諾を得たうえで、ユーザの口座に入っている資金をしかるべき別の口座（投資事業者の口座等）に移してから行われることが一般的である。しかし、口座間で資金を移動させると手数料が発生するので、資金の移動はなるべく少ないことが望ましい。かといって移動させる額が大きくなると、資金運用に対する心理的な抵抗がユーザに生じやすくなる。
そこで、本発明は、資金移動の回数を少なくしつつ、ユーザの資金運用の承諾を得やすくすることを目的とする。

上記目的を達成するために、本発明は、商取引における支払額に基づき算出される金額を蓄積する蓄積部と、ユーザにより所定の操作が行われる前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾を取得する承諾取得部であって、特定の事業者と特定の関連性を有する商取引の前記金額を資金運用に充てることについての第１承諾と、当該関連性を有しない商取引の前記金額を資金運用に充てることについての第２承諾とを取得する承諾取得部と、所定の期間が経過すると、前記承諾が取得された金額の累積額を第１の口座から第２の口座へ移動して資金運用に充てるための処理であって、当該承諾が前記第１承諾及び前記第２承諾のいずれであるかによって当該累積額を異なる条件で資金運用に充てるための別々の処理を実行する実行部とを備える情報処理装置を提供する。

また、前記承諾取得部は、特定の購入先で行われる商取引、特定の購入対象を購入する商取引、特定の決済手段で決済する商取引、特定のポイントが付与される商取引、特定のポイントが利用される商取引又は前記事業者が定めた特定の期間に行われる商取引の前記金額のみを資金運用の対象とするユーザの商取引を前記特定の関連性を有する商取引として前記承諾を取得してもよい。
さらに、前記承諾取得部は、特定の購入先で行われる商取引、特定の購入対象を購入する商取引、特定の決済手段で決済する商取引、特定のポイントが付与される商取引、特定のポイントが利用される商取引又は前記事業者が定めた特定の期間に行われる商取引を前記特定の関連性を有する商取引として前記承諾を取得してもよい。

また、前記特定の関連性を有する商取引には、支払額を現金で支払ったユーザの識別情報及び支払情報が前記事業者のシステムによって取得される商取引が含まれ、前記蓄積部は、前記事業者のシステムから取得される前記識別情報及び前記支払情報を蓄積し、前記承諾取得部は、蓄積された前記識別情報が示すユーザの、蓄積された前記支払情報から算出される前記金額についての前記承諾を取得してもよい。
さらに、前記承諾取得部は、前記特定の関連性を有する商取引について算出された金額のみを表示して前記第１承諾を要求する画面を示すデータをユーザ端末に送信し、当該ユーザ端末から返信された返信データが示す金額について前記第１承諾を取得してもよい。

また、前記承諾取得部は、前記特定の関連性を有する商取引について算出された金額を当該事業者が関連しない商取引について算出された金額と異なる態様で表示して前記承諾を要求する画面を示すデータをユーザ端末に送信し、当該ユーザ端末から返信された返信データが示す金額について前記第１承諾を取得してもよい。
さらに、前記所定の期間の経過前に行われた複数の商取引について蓄積された前記金額をそれぞれ示す金額情報をユーザ端末へ送信する送信部と、送信された前記金額情報が示す金額のうち資金運用に充てると選択された金額を示す選択金額情報を、前記ユーザ端末から受信する受信部とを備え、前記実行部は、受信された前記選択金額情報が示す前記選択された金額の累積額の前記移動を指示する処理を実行してもよい。

本発明によれば、資金移動の回数を少なくしつつ、ユーザの資金運用の承諾を得やすくすることができる。

実施例に係る資金運用支援システムの全体構成を表す図 家計簿サーバ装置及び資金運用支援サーバ装置のハードウェア構成を表す図 ユーザ端末のハードウェア構成を表す図 資金運用支援システムが実現する機能構成を表す図 蓄積されている差額の一例を表す図 表示された承諾要求の一例を表す図 表示された差額の履歴の一例を表す図 蓄積処理における各装置の動作手順の一例を表す図 運用支援処理における各装置の動作手順の一例を表す図 変形例の資金運用支援システムが実現する機能構成を表す図 変形例のユーザ端末が実現する機能構成を表す図 変形例の資金運用支援サーバ装置が実現する機能構成の一例を表す図 第１閾値テーブルの一例を表す図 第１の期間テーブルの一例を表す図 第２の期間テーブルの一例を表す図 変形例の資金運用支援サーバ装置が実現する機能構成の一例を表す図 変形例の資金運用支援システムが実現する機能構成の一例を表す図 変形例で蓄積されている差額の一例を表す図 表示された承諾要求の一例を表す図 表示された承諾要求の一例を表す図 表示された承諾要求の一例を表す図

以下、本発明の具体的な実施例について説明するが、本発明は、その技術的思想に含まれるものであれば種々変形、変更することが可能であり、以下の実施例に限定されるものではない。

［１］実施例
図１は実施例に係る資金運用支援システム１の全体構成を表す。資金運用支援システム１は、商取引においてユーザがお金を支払った際に生じるお釣りを資金運用に充てることを支援するシステムである。ここでいうユーザは、お釣りを資金運用に充てるお釣り運用サービスを利用するユーザであり、資金運用支援システム１において登録されているユーザである。資金運用支援システム１は、このお釣り運用サービスを提供する事業者が中心となって運用されている。

資金運用とは、利益を得る目的で資金を運用することであり、具体的には、株式、ＦＸ（Foreign Exchange：外国為替証拠金取引）、債券、投資信託、不動産、先物、金相場、預金及び外貨預金等を行うことである。また、仮想通貨（ビットコイン）の売買により資金が運用されてもよい。商取引におけるお金の支払いとは、例えば店舗等で商品を購入する際に行われる支払いであるが、それ以外にも、電車の切符の購入、病院での治療費の支払い、光熱費や通信費のような毎月の使用料金の支払い、住宅ローンのような分割払い及び本システムが支援する資金運用以外の資金運用での支払い等も含められる。つまり、商品には、例えば文房具のように物体として存在するもの以外に、運搬や治療のようなサービスも含まれる。

また、この支払には、ポイントサービスを利用するユーザがポイントを蓄積する際に行う支払い、蓄積されたポイントを利用する際の支払い及びそれら両方を兼ねた（ポイントの蓄積も利用も行う）支払いも含められる。ポイントサービスとは、ポイントサービス事業者が購入金額等に応じてユーザにポイントを付与し、付与したポイントで別の購入金額を充当したり商品と交換したりすることができるようにしたサービスのことである。

ユーザが行う支払いの方法（決済方法）は複数ある。例えばクレジットカード、電子マネー及び口座からの引き落し等の決済方法では１円単位で支払われるため通常はお釣りが生じないが、お釣り運用サービスは、それらの支払いについても仮に現金で１００円単位や１０００円単位で支払われたとしたら生じると想定されるお釣りを資金運用に充てるという条件でユーザに提供される。資金運用支援システム１においては、クレジットカード等の支払い情報は、それらの決済サービスを提供する事業者のシステムから後述する家計簿サーバ装置１０を介して取得される。

また、支払いが現金で行われた場合、支払った金額と購入額との差分がお釣りとしてユーザに支払われる。資金運用支援システム１においては、この現金決済で実際にユーザに支払われたお釣りの情報は、例えば後述するレシートを利用して取得される。また、ユーザがポイントサービスを利用していれば、現金決済であっても支払額を現金で支払ったユーザの識別情報（ユーザＩＤ（Identification）等）及び支払情報がポイントサービスの提供事業者のシステムによって取得されるので、そのシステムから商取引での支払額又はお釣りの金額を示す情報が取得される。

資金運用支援システム１は、ネットワーク２と、決済代行サーバ３と、銀行サーバ４と、銀行サーバ５と、資金運用サーバ装置６と、家計簿サーバ装置１０と、資金運用支援サーバ装置２０と、ユーザ端末３０とを備える。ネットワーク２は、移動体通信網及びインターネット等を含む通信システムであり、自システムに接続される装置同士のデータのやり取りを仲介する。ネットワーク２には、ユーザ端末３０以外の各装置が有線通信で接続されており、ユーザ端末３０が無線通信で接続されている。なお、ネットワーク２との接続は有線通信及び無線通信のどちらでもよい。

決済代行サーバ３は、取引で発生する決済処理を代行する決済代行会社が運用するサーバである。銀行サーバ４及び銀行サーバ５は、銀行の口座を管理する（詳細には口座に収められているお金を管理する）サーバであり、口座への入金処理及び口座からの出金処理を行う。本実施例では、銀行サーバ４は、ユーザが利用する銀行でユーザの利用可能なお金が収められた口座を管理するサーバであり、銀行サーバ５は、資金運用会社が利用する銀行で資金運用会社の口座を管理するサーバであるものとする。

ここでいう「ユーザの利用可能なお金」とは、お釣り運用サービスにおいて運用される資金の元手となり得るお金のことである。ユーザの利用可能なお金が収められた口座は、ユーザが開設した口座に限らない。例えばユーザが利用する証券会社、通信事業者、電力会社、ガス会社、決済代行会社、通信販売会社及びＣ２Ｃ（Consumer to Consumer）サービス会社等が利用する、ユーザが支払ったお金を収めるための口座であってもよい。また、サービスを提供している事業者がユーザに付与したポイントに相当するお金を収めている口座であってもよい。

各事業者との取り決めにより、ユーザがそれらの口座に支払額以上のお金を収めておくことで、余ったお金を資金運用に充てることができる。それらの場合、事業者の口座を保有する銀行の銀行サーバ、又は、各事業者がその口座を管理するために設けたサーバが、ユーザの利用可能なお金が収められた口座を管理するサーバとして用いられる。資金運用サーバ装置６は、銀行サーバ５が管理する口座の資金を運用する処理及び運用実態を資金運用支援サーバ装置２０に提供する処理等を実行する。

家計簿サーバ装置１０は、ユーザの家計情報を蓄積する装置である。家計情報には、少なくともユーザの支出を示す支出情報が含まれる。支出情報は、食費、被服費、娯楽費、医療費、交際費、教育費、車両費、光熱費及び住居費等を示す情報である。これらの支出には、厳密には家族などユーザと家計をともにする者の支出も含まれているが、本実施例では、そのような支出もユーザの支出として捉えるものとする。

家計簿サーバ装置１０は、これらの支出情報を、ユーザ端末３０から取得したり、金融機関又はポイントサービス事業者等が提供する個人向けサイト（ユーザの取引の履歴が掲載されたサイト。例えばインターネットバンキングのサイト又はポイント情報を提供するサイト）を提供するシステムから取得したりする。なお、家計簿サーバ装置１０は、金融機関又はポイントサービス事業者等のシステムから直接ＡＰＩ（Application Programming Interface）を通じて又はファイル形式で支出情報を取得してもよい。

資金運用支援サーバ装置２０は、お釣り運用サービスをユーザに提供するための処理を行う情報処理装置である。資金運用支援サーバ装置２０は、家計簿サーバ装置１０から支出情報を取得する処理、お釣りを算出する処理、お釣りを資金運用に充てることの承諾をユーザに要求する処理、及び、承諾が得られたお釣りと同等の金額をユーザの口座から資金運用用の口座に移すための処理等を行う。

ユーザ端末３０は、ユーザが利用する端末装置であり、例えばスマートフォン、タブレット端末又はパーソナルコンピュータ等である。ユーザ端末３０は、家計簿サーバ装置１０にアクセスする操作（ユーザＩＤ、パスワードの入力操作）の受け付け、ユーザの家計情報（特に支出情報）の入力操作の受付、蓄積された家計情報の表示、資金運用支援サーバ装置２０からの上記要求の表示、その要求に対して承諾・拒否のいずれかを回答する操作の受け付け、及び、回答結果の通知処理等を行う。

図２は家計簿サーバ装置１０及び資金運用支援サーバ装置２０のハードウェア構成を表す。これらの装置は、いずれも、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信装置１４と、入力装置１５と、出力装置１６とを備えるコンピュータである。プロセッサ１１は、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１１は、周辺装置とのインターフェース、制御装置、演算装置及びレジスタ等を含む中央処理装置（ＣＰＵ：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）システムや通信販売事業者の販売管理システム、クレジットカード及び電子マネー等の電子決済システム、ポイントサービスの提供事業者が利用しているポイントを管理するシステムなど、ユーザの支払額を保持しているシステムから支払額を取得してもよい（ユーザ及び各事業者と支払額の取得について合意されているものとする）。

［２−２］個人向けサイト
ユーザの収入情報及び支出情報の取得先となる個人向けサイトは、上述した金融機関及びポイントサービスの提供事業者が提供するサイトに限らない。他にも、クレジットカードのサービスを展開する事業者が提供する利用履歴が掲載されたサイト、電子マネーサービスを展開する事業者が提供する利用履歴が掲載されたサイト、及び、アグリゲーションサービス（異なるサービスの情報を集約して表示するサービス）を展開する事業者が提供する利用履歴及びポイント履歴等が掲載されたサイト等が用いられてもよい。

［２−３］資金運用の選択肢
承諾要求部２０６は、ユーザに差額の資金運用について承諾を要求する際に、資金の運用方法の選択肢を提供してもよい。例えば、承諾要求部２０６は、ローリスクローリターンの運用方法と、ハイリスクハイリターンの運用方法と、リスクもリターンもそれらの中間の運用方法とを選択肢として提供する。この場合、ユーザは、資金運用の承諾及び拒否の操作に加え、承諾する場合には、運用方法の選択肢のうちのいずれかを選択する操作を行う。

また、移動指示処理実行部２１０は、選択された運用方法を提供する運用会社の口座に資金を移動させる処理を移動指示処理として実行する。これにより、運用方法の選択肢がない場合に比べて、資金運用の自由度を高くすることができる。なお、これらの選択肢は、ユーザが明示的に変更しない限り意図せず変更されることがないものとしてもよい。これにより、資金運用におけるリスクレベルがユーザの知らない間に高まることを防ぐことができる。

［２−４］資金運用に必要な手続き
資金運用を行うためにはユーザの資金をユーザの口座から運用会社が指定する口座に移動することになるが、そのためには運用会社が指定する金融機関の口座を開設する等の手続きが必要になる場合がある。以下ではそのように資金運用の前提となる、差額の累積額を第１の口座から第２の口座へ移動する際に必要な手続きのことを「運用前提手続き」という。

資金運用支援システム１においては、実施例で述べたように承諾要求が行われてから資金が実際に移動するまでタイムラグがあるので、それを利用して、運用前提手続きが完了する前の商取引における差額であっても、運用前提手続きが完了した後に、それを用いた資金運用ができるようにしてもよい。本変形例では、支払額取得部２０１が、運用前提手続きが完了する前になされた商取引における支払額を取得し、差額算出部２０２が、そうして取得された支払額から差額を算出する。

差額取得部２０３は、こうして算出された差額、すなわち、運用前提手続きが完了する前になされた商取引における差額を取得する。差額取得部２０３がこの差額を取得することで、移動指示処理の対象となる差額の累積額には、運用前提手続きが完了する前になされた商取引における差額が含まれることになる。また、運用前提手続きが第１の期間が経過しても完了していなければ、承諾要求部２０６は、運用前提手続きが完了する前に上述した承諾要求（要求データの生成及び送信）を行う。

一方、移動指示処理実行部２１０は、運用前提手続きが完了する前には移動指示処理を実行しても資金の移動を行うことができないので、運用前提手続きが完了した後に移動指示処理を実行する。具体的には、例えば運用前提手続きが完了する前に資金移動時期が来た場合、移動指示処理実行部２１０は、資金移動を要求する要求データを決済代行サーバ３に送信する処理を移動指示処理として実行する。

しかし、運用前提手続きが完了しておらず例えば必要な口座が開設されていないので、決済代行サーバ３は資金移動を完了することができず、その旨を資金運用支援サーバ装置２０に通知してくる。移動指示処理実行部２１０は、この通知を受け取ると、一定期間（例えば１日）が経過してから再度要求データを送信する。移動指示処理実行部２１０がこうして通知が送られてくる度に要求データを送信し直すことで、運用前提手続きが完了したときには、送信した要求データに基づいて資金の移動が行われる。

移動指示処理実行部２１０は、このようにして運用前提手続きが完了した後に移動指示処理を実行する。本変形例によれば、運用前提手続きが完了する前になされた商取引における差額も運用に充てることができる。また、運用前提手続きが完了する前であっても、ユーザに差額を資金運用に充てることを承諾するか否かについて意思確認を行うことができる。

［２−５］差額の蓄積時期
実施例では、毎日その日に行われた商取引における差額が差額取得部２０３によって取得されて差額蓄積部２０４に蓄積されるものとしたが、これに限らない。なぜなら、商取引が行われてから、その商取引における差額が蓄積されるまでに何日か経過する場合があるからである。その場合、例えば１回目の第１の期間に行われた商取引における差額についての承諾要求が、２回目以降の第１の期間になってから行われるということが起こり得る。

実施例では、承諾要求部２０６は、第１の期間が経過するごとに、その第１の期間になされた１以上の商取引における差額についての承諾を要求する要求データを生成したが、前述のとおり差額の蓄積までに時間を要する場合には、第１の期間が経過するごとに、その第１の期間の満了以前（つまり、その第１の期間とそれよりも前の第１の期間の両方を含む期間）になされた１以上の商取引における差額を資金運用に充てることについての承諾を要求する要求データを生成することになる。

ここでいう「第１の期間の満了以前」には、現在の第２の期間よりも前の第２の期間も含まれる。つまり、第１の期間が経過するごとに要求データが生成されるのは、その第１の期間に新たに差額取得部２０３によって取得された差額の資金運用の承諾についてであって、差額が算出される商取引が行われた時期は、いつであってもよい。

［２−６］拒否の撤回
実施例では、一度承諾した資金運用を撤回して拒否することができたが、反対に、一度拒否した資金運用を撤回して承諾することができてもよい。その場合、例えば、履歴表示部３０６が、過去に資金運用が拒否された差額の履歴を表示して、撤回操作受付部３０７が、過去に行った資金運用の拒否の撤回を示すユーザの撤回操作を受け付け、拒否が撤回された差額の差額ＩＤを撤回通知部３０８に供給する。

次に、撤回通知部３０８が、供給された差額ＩＤの差額について資金運用の拒否が撤回された旨を資金運用支援サーバ装置２０に通知し、資金運用支援サーバ装置２０の撤回受付部２０８が、通知された資金運用の拒否の撤回を受け付け、差額蓄積部２０４が、拒否が撤回された差額のステータスを「拒否」から「承諾」に変更する。これにより、拒否が撤回された差額も加えた累積額について移動指示処理が実行され、資金運用に充てられることになる。

［２−７］拒否された差額の再承諾要求
実施例では、一度資金運用に充てることが拒否された差額については、承諾要求が行われなかったが、再度承諾要求が行われてもよい。この場合、資金運用支援サーバ装置２０の要求時期判断部２０５が、要求時期になったと判断すると、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうち、ステータスが「未要求」及び「拒否」であるものを、対応する差額ＩＤとともに差額蓄積部２０４から読み出し、要求先ユーザのユーザＩＤとともに承諾要求部２０６に供給する。

承諾要求部２０６は、例えば実施例と同様に要求データを生成して送信する。なお、それだと差額の合計金額が当然ながら大きくなるので、承諾要求部２０６は、「未要求」の差額の合計金額と、「拒否」された差額の合計金額とについて別々に承諾を要求してもよい。その場合、ユーザ端末３０の承諾要求表示部３０３は、２つの合計金額についてそれぞれ承諾ボタン及び拒否ボタンを表示して、ユーザがそれぞれについて承諾及び拒否を選べるようにする。資金運用支援サーバ装置２０の移動指示処理実行部２１０は、そうして資金運用の承諾を得られた差額の累積額について移動指示処理を実行する。本変形例によれば、資金運用の承諾を得る機会を増やすことができる。

［２−８］資金移動時期における承諾の再要求
実施例では、資金移動時期になると、最後の第１の期間における差額について承諾が要求された後に移動指示処理が実行されたが、その他の第１の期間における差額について既に承諾が得られている場合でも、最終的な確認のための承諾が要求されてもよい。

本変形例では、資金移動時期判断部２０９が、資金移動時期になったと判断すると、支払日が第２の期間に含まれる差額のうちステータスが「承諾」となっている差額の差額ＩＤを差額蓄積部２０４から読み出して要求先ユーザのユーザＩＤとともに承諾要求部２０６に供給する。承諾要求部２０６は、供給された差額ＩＤの差額を資金運用に充てることについての承諾を再度要求する旨を表す文字列と、その差額ＩＤに対応付けられている差額及び支払日とを示す要求データを生成してユーザ端末３０に送信する。

ユーザ端末３０の承諾要求表示部３０３は、受け取った要求データが示す差額、すなわち支払日が第２の期間に含まれ且つ過去に資金運用を承諾した差額を図６に表す例と同様に表示して、全ての差額の資金運用を再度承諾するか、承諾する差額を選択し直すか、全ての差額の資金運用を拒否するかをユーザに選ばせる。このように第２の期間が経過したときに再度承諾を要求することで、この要求を行わない場合に比べて、ユーザに自分の意思が尊重されているとより強く感じさせ、満足度を向上させることができる。

［２−９］資金の運用状況
ユーザが資金運用に充てることを承諾した資金の運用状況がユーザ端末で閲覧可能となっていてもよい。この場合、資金運用サーバ装置６が資金の運用状況を例えば資金運用支援サーバ装置２０を介してユーザ端末３０に提供し、ユーザ端末３０が提供された運用状況を表示する。提供される運用状況には、例えば、日々の株価等の動きに合わせて表示される運用資金のパフォーマンス、運用を継続した場合の将来の資金形成プロジェクション及び日々のトランザクションデータ等が含まれる。

［２−１０］承諾の取得方法
承諾取得部２２０は、実施例では承諾対象を選択する操作及び承諾ボタンＢ１を押す操作が行われた場合に承諾を取得したが、これに限らない。承諾取得部２２０は、例えば、お釣り運用サービス画面を開く操作が行われた場合に承諾を取得してもよい。その場合、ユーザ端末３０の承諾可否通知部３０５は、お釣り運用サービス画面を開く操作が行われると、その操作の前になされた商取引における差額を資金として運用に充てるサービスを利用することについて承諾する承諾データを資金運用支援サーバ装置２０に送信する。

承諾取得部２２０は、この承諾データを受け取ることで上記の承諾を取得する。これにより、承諾対象を１つ１つ選択する場合に比べて、差額を全て資金運用に充てる場合のユーザの手間を減らすことができる。また、例えば承諾対象を選択する操作を行う度に（承諾ボタンＢ１を押さなくても）選択された差額を承諾する承諾データが送信されてもよい。要するに、承諾取得部２２０は、ユーザの承諾を確認できる操作であれば、どのような操作が行われた場合に承諾を取得してもよい。

［２−１１］各部を実現する装置
図４等に表す各機能を実現する装置は、それらの図に表された装置に限らない。例えば家計簿サーバ装置１０及び資金運用支援サーバ装置２０が備える各機能を１台の装置が実現してもよいし、それらの各機能を３以上の装置がそれぞれ分担して実現してもよい。

図１０は本変形例の資金運用支援システムが実現する機能構成の一例を表す。図１０では、家計簿サーバ装置１０ａ及び資金運用支援サーバ装置２０ａを備える資金運用支援システム１ａが表されている。家計簿サーバ装置１０ａは、図４に表す各部に加えて支払額取得部２０１及び差額算出部２０２を備える。資金運用支援サーバ装置２０ａは、図４に表す各部のうち、支払額取得部２０１及び差額算出部２０２以外の各部を備える。この場合、家計簿サーバ装置１０ａが蓄積した家計情報から支払額を取得し、差額を算出する。資金運用支援サーバ装置２０ａは、家計簿サーバ装置１０ａから算出された差額を取得する。

図１１は本変形例のユーザ端末が実現する機能構成の一例を表す。図１１では、図４においてユーザ端末３０が備える各部に加え、資金運用支援サーバ装置２０が備える各部を備えるユーザ端末３０ｂが表されている。この場合、ユーザ端末３０ｂが、自装置を利用するユーザの支払額を取得して、差額の算出から承諾要求、承諾可否の受け付け、撤回の受け付け及び移動指示処理等を行う情報処理装置として用いられる。要するに、資金運用支援システム全体としてこれらの機能が実現されていれば、資金運用支援システムが何台の装置を備えていてもよい。

［２−１２］第１の期間及び第２の期間
第１の期間は、上述した期間（１日間）に限らない。例えば、１日間より短い期間又は長い期間であってもよいし、常に一定の期間であってもよい。また、第２の期間に含まれる第１の期間の数は実施例のように（毎月の日数と同じ数）一定でなくてもよいし、一定としてもよい。また、例えばプッシュ型の承諾要求が行われる場合に、取得される差額に応じて第１の期間を変化させてもよい。

例えば、第１の期間は、差額取得部２０３により取得された差額の累積額が第１閾値未満になっている期間である。この場合、要求時期判断部２０５は、基準日の開始時には累積額を０として、差額取得部２０３により差額が取得される度にそれを加算して累積額を算出する。要求時期判断部２０５は、算出した累積額が第１閾値以上になった場合、基準日からその前日までを第１の期間として、第１の期間が経過した次の日、すなわち累積額が第１閾値以上になった日に要求時期になったと判断する。

このように要求時期が判断されることで、承諾要求部２０６により承諾が要求される差額の合計金額は、第１閾値未満の金額となる。第１閾値としては、資金運用に対する心理的な抵抗がユーザに生じにくいと想定される金額（例えばアンケート等で調査した金額）が用いられるとよい。そうすることで、常にその金額よりも小さい金額について資金運用の承諾がユーザに要求されることになり、それ以上の金額の承諾が要求される場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。

なお、この方法だと、第２の期間が満了するまでに１回しか第１の期間が満了しない場合（第２の期間中に１回しか累積額が第１閾値に達しない場合）もあれば、１回も第１の期間が満了しない場合（第２の期間中に１回も累積額が第１閾値に達しない場合）もある。後者の場合は、承諾要求が１回も行われず、承諾を得られた金額が存在しないので、移動指示処理を実行することができない。一方、前者の場合は、承諾要求が１回は行われるので、移動指示処理実行部２１０が、第２の期間が経過すると、その１回の承諾要求で承諾を得られた差額の累積額について移動指示処理を実行する。

つまり、移動指示処理実行部２１０は、１以上の第１の期間を含み且つ予め長さが定められた第２の期間が経過すると、移動指示処理を実行する。これにより、第２の期間に１つでも第１の期間が含まれていれば、すなわち１度でもユーザへの承諾要求がなされれば、そこで承諾された差額の累積額が資金運用に充てられる。

なお、上記第１閾値として、ユーザごとに異なる値が用いられるようにしてもよい。そのためのパラメータとして、例えば、登録されたユーザのプロファイル情報（性別、年代、居住地、趣味等）及び資金運用サーバ装置６から提供される資金の運用状況（パフォーマンス、資金形成プロジェクション、トランザクションデータ等）等のユーザ関連情報（ユーザに関する情報）が用いられる。

図１２は本変形例の資金運用支援サーバ装置が実現する機能構成の一例を表す。図１２では、図４において資金運用支援サーバ装置２０が備える各部に加え、ユーザ関連情報取得部２１１と、ユーザ関連情報蓄積部２１２とを備える資金運用支援サーバ装置２０ｃが表されている。ユーザ関連情報取得部２１１は、例えば自装置の記憶手段からは資金運用支援システムにおいて登録されているユーザのプロファイル情報を取得し、図１に表す資金運用サーバ装置６から資金の運用状況を取得する。ユーザ関連情報取得部２１１は取得したユーザ関連情報をユーザ関連情報蓄積部２１２に供給する。

ユーザ関連情報蓄積部２１２は、供給されたユーザ関連情報を、その情報が関連するユーザのユーザＩＤに対応付けて蓄積する。要求時期判断部２０５は、差額取得部２０３により取得された或るユーザの差額を加算して累積額を算出すると、そのユーザのユーザＩＤに対応付けて蓄積されているユーザ関連情報をユーザ関連情報蓄積部２１２から読み出す。要求時期判断部２０５は、算出した累積額が、読み出したユーザ関連情報に応じた第１閾値以上になった場合に、第１の期間が経過したと判断する。この判断は例えばユーザ関連情報と第１閾値とを対応付けた第１閾値テーブルを用いて行われる。

図１３は第１閾値テーブルの一例を表す。図１３では、ユーザ関連情報として「Ａ１１未満」、「Ａ１１以上Ａ１２未満」、「Ａ１２以上」（Ａ１１＜Ａ１２）という運用額と、「Ｂ１１」、「Ｂ１２」、「Ｂ１３」（Ｂ１１＜Ｂ１２＜Ｂ１３）という第１閾値とが対応付けられている。要求時期判断部２０５は、例えば、ユーザ関連情報として読み出した運用額が「Ａ１１未満」であれば「Ｂ１１」を第１閾値として用いて、その運用額が「Ａ１２以上」であれば「Ｂ１３」を第１閾値として用いる。

本変形例では、以上のとおり、ユーザ関連情報取得部２１１により取得されたユーザ関連情報に応じた値が第１閾値として用いられる。図１３に表す第１閾値テーブルを用いた場合、要求時期判断部２０５は、運用額が大きいユーザほど大きな第１閾値を用いることになる。一般に、運用額が大きいユーザほど、資金運用に積極的であり、資金運用に充てることを承諾しやすい金額も大きくなりやすい。一方で、第１閾値を小さくするほど、第１の期間が短くなり、プッシュ型の場合は頻繁に承諾要求が行われることになる。

運用額が大きいユーザは、そのように頻繁に承諾要求を受け取るよりは、１回当たりの金額を大きくしてでも承諾要求の頻度が少ない方が煩わしくなくて気分よく承諾できる傾向になる。反対に、運用額が小さいユーザは、１回当たりの金額が大きいと承諾しにくくなるので、多少煩わしくても第１の期間を短くして１回当たりの金額を小さくした方が承諾しやすい傾向になる。本変形例では、上記の第１閾値を用いることで、ユーザの運用額に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、第１閾値が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。

上述した累積額で第１の期間の長さを決める例において、第２の期間は、例えば決められた回数の第１の期間を含む期間とする。その場合、累積額が早く増えるほど第１の期間、第２の期間とも短くなる。また、上記例において、第２の期間を一定の期間としてもよい（第２の期間が終了したときには、第１の期間もその時点での累積額にかかわらず終了する）。その場合、累積額が早く増えるほど第２の期間に含まれる第１の期間の数が多くなる。

上述したいずれの例においても、第２の期間には複数の第１の期間が含まれており、第２の期間が終了すると、最後の第１の期間も終了し、次の第２の期間は、次の第１の期間と同じタイミングで開始される。第１の期間及び第２の期間は、１日単位で定められてもよいし、週単位、月単位、時間単位又は分単位等、どのような時間の単位で定められてもよい。

また、前述したユーザ関連情報に応じて第１の期間（プッシュ型の承諾要求が行われる場合）及び第２の期間（プッシュ型・プル型の両方）をユーザごとに異ならせてもよい。例えば、承諾要求部２０６が、ユーザ関連情報取得部２１１により取得されたユーザ関連情報に応じて予め定められる期間が第１の期間として経過するごとに承諾要求を行ってもよい。この場合、要求時期判断部２０５は、第１の期間が経過したか否かの判断を、例えばユーザ関連情報と第１の期間とを対応付けた第１の期間テーブルを用いて行う。

図１４は第１の期間テーブルの一例を表す。図１４では、ユーザ関連情報として「Ｃ１１未満」、「Ｃ１１以上Ｃ１２未満」、「Ｃ１２以上」（Ｃ１１＜Ｃ１２）という承諾回数と、「Ｄ１１」、「Ｄ１２」、「Ｄ１３」（Ｄ１１＜Ｄ１２＜Ｄ１３）という第１の期間とが対応付けられている。承諾回数とは、お釣り運用サービスにおいてこれまでに資金運用を承諾した回数である。要求時期判断部２０５は、例えば、ユーザ関連情報として読み出した承諾回数が「Ｃ１１未満」であれば「Ｄ１１」を第１の期間として用いて、その承諾回数が「Ｃ１２以上」であれば「Ｄ１３」を第１の期間として用いる。

資金運用の承諾のしやすさについていうと、承諾回数が多いユーザは、資金運用に積極的なので、上述した運用額が大きいユーザと同じ傾向になり、承諾回数が少ないユーザは、資金運用に消極的なので、上述した運用額が小さいユーザと同じ傾向になる。本変形例では、上記の第１の期間を用いることで、ユーザの承諾回数に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、第１の期間が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。

また、例えば、移動指示処理実行部２１０が、ユーザ関連情報取得部２１１により取得されたユーザ関連情報に応じて予め定められる期間が第２の期間として経過すると、移動指示処理を実行してもよい。この場合、資金移動時期判断部２０９は、第２の期間が経過したか否かの判断を、例えばユーザ関連情報と第２の期間とを対応付けた第２の期間テーブルを用いて行う。

図１５は第２の期間テーブルの一例を表す。図１５では、ユーザ関連情報として「２０代以下」、「３０代、４０代」、「５０代以上」という年代と、「Ｆ１１」、「Ｆ１２」、「Ｆ１３」（Ｆ１１＜Ｆ１２＜Ｆ１３）という第２の期間とが対応付けられている。資金移動時期判断部２０９は、例えば、ユーザ関連情報として読み出したユーザの年代が「２０代」であれば「Ｆ１１」を第２の期間として用いて、その年代が「５０代以上」であれば「Ｆ１３」を第２の期間として用いる。

第２の期間が長いほど、第２の期間が経過した後に口座から移動する資金の金額が大きくなりやすい。そのため、収入が多いユーザほど、資金運用に積極的になりやすい。資金運用の承諾のしやすさについていえば、年代が高いユーザは、収入が多いので資金運用に積極的になりやすく上述した運用額が大きいユーザと同じ傾向になり、年代が低いユーザは、収入が少ないので資金運用に消極的になりやすく上述した運用額が小さいユーザと同じ傾向になる。本変形例では、上記の第２の期間を用いることで、ユーザの年代に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、第２の期間が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。

なお、図１３、図１４、図１５の例で述べたパラメータとして用いられるユーザ関連情報（運用額、承諾回数、年代）は、これらに限らず、他のユーザ関連情報（利益額、利益率、拒否回数、職業等）が用いられてもよい。いずれの場合も、資金運用への積極性と相関があるユーザ関連情報が用いられることで、ユーザのその積極性に応じてそれぞれ承諾しやすいタイミングで承諾要求が行われるので、各期間が固定されている場合に比べて、ユーザの資金運用の承諾を得やすくすることができる。

また、ユーザ関連情報に応じた第１閾値、第１の期間及び第２の期間を用いた場合の資金運用の承諾率（例えば全差額の件数のうち資金運用を承諾された差額の件数の割合）を取得して、承諾率が目標値よりも低い場合には、ユーザ関連情報との相関性を変化させてもよい。例えば図１３の例であれば、要求時期判断部２０５は、取得した承諾率が目標値よりも低い場合には、運用額の閾値であるＡ１１及びＡ１２の値を大きくし、又は小さくして、承諾率が目標値よりも高くなる場合の値を求める。また、運用額の閾値ではなく、第１閾値の値を変化させてもよいし、それらの両方の値を変化させてもよい。要求時期判断部２０５が図１４に表す各値を求める場合も、資金移動時期判断部２０９が図１５に表す各値を求める場合も同様である。

また、第１の期間として、ユーザ端末３０が特定のプログラムを起動させたときに満了する期間が用いられてもよい。ユーザ端末３０は、ユーザの操作によりそのプログラムを起動させてもよいし、本体の電源が投入されたときにプログラムを起動させてもよい。ここでいうプログラムは、図４に表す各部を実現するためのプログラムであり、例えばお釣り運用サービスを提供する事業者が提供するアプリケーションプログラムである。この場合、ユーザ端末３０は、プログラムを起動すると、その旨を資金運用支援サーバ装置２０に通知する。

資金運用支援サーバ装置２０の要求時期判断部２０５は、この通知を受け取ると、第１の期間が満了し、承諾要求を行う時期になったと判断する。こうして、承諾要求部２０６は、ユーザ端末３０がプログラムを起動させる度に、すなわち第１の期間が経過するごとに承諾をユーザに要求する。なお、第１の期間として、ユーザが特定の操作（例えば図６に表す承諾要求の画面を表示させる操作）を行ったときに満了する期間が用いられてもよい。その場合、上記アプリを起動した後も、例えば承諾要求の画面を表示させる操作を行う度に最新の差額に更新させることができる。

［２−１３］受取額
実施例では、ユーザがお金を支払ったときの金額（支払額）とそれを切り上げた額との差額が資金運用の対象であったが、これに限らず、例えば、ユーザがお金を受け取ったときの受取額とそれを切り下げた額との差額（いわゆる端数）を資金運用の対象としてもよい。ユーザが受け取るお金には、例えば、ユーザの給料、ユーザが保有する株式の配当金、及び、ユーザが保有する不動産の賃貸料等が含まれる。

この場合、差額取得部２０３は、ユーザが受け取った受取額とその受取額を切り下げた額との差額を取得する。承諾要求部２０６は、第１の期間が経過するごとに、その第１の期間の満了以前に受け取った１以上の受取額における差額を資金運用に充てることについての承諾をユーザに要求する。以降は、実施例と同様に承諾の可否の受け付け及び移動指示処理等が行われる。本変形例では、ユーザが受け取ったお金についても、その切り下げ額との差額を資金運用に充てることができる。

［２−１４］取得する差額
差額取得部２０３は、上記の各例では、支払額については切り上げ額との差額を取得し、受取額については切り下げ額との差額を取得したが、これに限らない。差額取得部２０３は、支払額について切り下げ額との差額を取得してもよいし、受取額について切り上げ額との差額を取得してもよい。また、差額取得部２０３は、上記の支払額又は受取額に特定の値（例えば３％）を乗じた差額を取得してもよい。

また、差額取得部２０３は、特定の支出項目の支払額に対してユーザが設定した目標値と支払額との差額を取得してもよい。この場合、ユーザは、例えば毎月の電気代及び生活費等の目標値を設定しておく。差額取得部２０３は、目標値が設定された支出項目の支払額がその目標値を下回った場合に、目標値と支払額との差額を取得する。これにより、ユーザが節約するほど運用する資金が増える一方、どれだけ運用資金が増えても上記支出項目については目標値を超える支出は生じない。これにより、ユーザは資金運用のために予期せぬ支出が生じるという心配をすることなく資金運用を行うことができる。

また、差額取得部２０３は、特定の収入項目の受取額に対してユーザが設定した目標値と受取額との差額を取得してもよい。この場合、ユーザは、例えば月収（残業等で変動する）及び株式配当等の目標値を設定しておく。差額取得部２０３は、目標値が設定された収入項目の受取額がその目標値を上回った場合に、目標値と支払額との差額を取得する。これにより、ユーザは目標値に相当する収入を確保したうえで資金運用を行うことができる。

要するに、差額取得部２０３は、商取引における支払額に基づき算出される差額（切り上げ額との差額、切り下げ額との差額、特定の値を乗じた額及び目標値との差額等）を取得するか、ユーザが受け取った受取額に基づき算出される差額（こちらも切り上げ額との差額、切り下げ額との差額、特定の値を乗じた額及び目標値との差額等）を取得するものであればよい。

［２−１５］差額の集金方法
実施例では、移動指示処理実行部２１０が移動指示処理を実行することで、承諾を得られた差額の累積額が第１の口座から集金され、第２の口座に移動したが、差額の累積額の集金方法はこれに限らない。例えば、ユーザからの集金を代行する事業者に委託して差額の累積額を集金してもよい。集金を代行する事業者とは、例えば、通信事業者や電力会社、クレジットカード会社、保険会社など、本業でユーザから集金を行っている事業者である。

図１６は本変形例の資金運用支援サーバ装置２０ｄが実現する機能構成の一例を表す。資金運用支援サーバ装置２０ｄは、図４に表す移動指示処理実行部２１０に代えて、集金情報通知部２１５を備える。集金情報通知部２１５は、移動指示処理実行部２１０と同様に、第１の期間を複数含む第２の期間が経過すると、差額の累積額を算出する。集金情報通知部２１５は、算出した累積額を示す情報を、ユーザの口座から集金する（引き落とす）金額を示す集金情報として生成する。

集金情報通知部２１５は、生成した集金情報を、予め記憶しておいた集金の代行事業者について定められた宛先に送信する。この宛先は、代行事業者が運用する集金のための処理を行う集金処理装置であってもよいし、その集金処理装置を含むシステムの外部とのインターフェースとなっている装置であってもよい。この宛先に送信された集金情報は、集金処理装置により受け取られて、集金処理装置が、ユーザの口座から差額の累積額を引き落とす処理を行う。

本変形例では、集金の代行事業者は、上述した通信事業者や電力会社などのように、本業の集金を定期的に（例えば毎月）行っているものとする。そこで、集金処理装置は、本業で集金する金額に差額の累積額を加算した金額をユーザの口座から引き落とす処理を行う。集金処理装置は、こうして引き落した金額をまずは自身を運用する事業者の口座に移動させる。続いて、集金処理装置は、事業者の口座から差額の累積額を資金運用会社の口座に移動させる（振り込む）処理を行う。これらの処理により、各ユーザの口座から差額の累積額が資金運用会社の口座に移動する。

本変形例では、以上のとおり、集金情報通知部２１５が、第１の期間を複数含む第２の期間が経過すると、ユーザにより承諾を得られた差額の累積額を、その累積額の集金を代行する事業者に通知する。集金情報通知部２１５は本発明の「通知部」の一例である。実施例のように各ユーザの資金が収められている第１の口座から第２の口座（資金運用会社の口座）に累積額を移動させる場合、第１の口座の数だけ口座移動の手数料が発生する。

これに対し、本変形例では、集金を代行する事業者が通信事業者や電力会社などのように定期的にユーザから集金を行っている事業者の場合、上記のとおりその集金の金額に累積額を加算して集金することになる。その場合、集金を代行する事業者にとっては、ユーザの口座から累積額を引き落とす際に発生する手数料は変化せず、自身の口座から資金運用会社の口座への振り込み手数料だけが新たに発生する。

そのため、第１の口座の数だけ口座移動の手数料が発生する場合に比べて、銀行に支払う手数料が大きく減少するので、減少した手数料の範囲で集金の代行事業者に代行の手数料を支払えば、お釣り運用サービスに係る費用を削減することができる。なお、本変形例においては、集金を代行する事業者の口座には、ユーザから集金した累積額、すなわち上述したユーザが利用可能なお金が収められている。つまり、この口座を管理する銀行サーバは、図１に表す銀行サーバ４に相当することになる。

そこで、移動指示処理実行部２１０が、例えば前述した集金処理装置に対して、集金を代行する事業者の口座を第１の口座とし、資金運用会社の口座を第２の口座として、第１の口座から第２の口座への移動を指示する移動指示処理を実行してもよい。集金処理装置は、この指示を受け取ると、第１の口座から第２の口座へ移動する累積額をユーザの口座から引き落し、第１の口座である事業者の口座に移動してから、その累積額を第２の口座に移動する処理を行う。集金情報通知部２１５による通知を行うか、移動指示処理実行部２１０が移動指示処理を行うかは、集金を代行する事業者側のシステムが処理しやすい方が選ばれればよい。

［２−１６］差額の絞り込み
実施例では、ユーザが行った支払いに基づいて算出された全ての差額について資金運用の承諾が要求されたが、これに限らない。例えば、特定の店舗で商品を購入した場合の差額に絞り込んでもよいし、特定の決済方法で決済した場合の差額に絞り込んでもよい。

図１７は本変形例の資金運用支援サーバ装置２０ｅが実現する機能構成の一例を表す。資金運用支援サーバ装置２０ｅは、図４に表す各部に加え、商取引関連情報取得部２１３と、差額判別部２１４とを備える。本変形例では、家計簿サーバ装置１０の家計情報蓄積部１０３が、店舗名（チェーン店の名称等）及び購入に用いた決済方法の名称（クレジットカード会社名又は電子マネーの名称等）を含む支出情報を蓄積する。店舗名は、商取引において購入された商品の購入先を示す情報であり、決済方法の名称は、商取引において用いられた決済手段を示す情報である。

家計簿サーバ装置１０は、店舗名及び決済方法の名称を、上述した個人向けサイトや、レシートからそれらの情報を読み取ったユーザ端末３０から取得する。なお、これらの方法で店舗名や決済方法の名称が取得できない場合は、家計簿サーバ装置１０は、例えば店舗で利用されているＰＯＳシステムや決済サービスを提供する事業者の電子決済システムから店舗名や決済方法の名称を取得してもよい。支払額取得部２０１は、実施例で述べたように家計簿サーバ装置１０から支出情報及びユーザＩＤを受け取ることで、そのユーザＩＤのユーザが商取引の際に支払った支払額を取得する。支払額取得部２０１は、受け取った支出情報及びユーザＩＤを商取引関連情報取得部２１３に供給する。

商取引関連情報取得部２１３は、ユーザの商取引に関連する情報を取得する機能であり、例えば、前述した購入先及び決済方法の名称を商取引の関連情報として取得する。商取引関連情報取得部２１３は、支払額取得部２０１から支出情報及びユーザＩＤを受け取ることで、その支出情報が示す店舗名及び決済方法の名称を、そのユーザＩＤのユーザが行った商取引における購入先及び決済手段として取得する。商取引関連情報取得部２１３は、取得した商取引の関連情報を示す支出情報を、対応するユーザＩＤとともに差額判別部２１４に供給する。差額判別部２１４には、差額取得部２０３からも、取得した差額とそれに対応するユーザＩＤ及び支出情報とが供給される。

差額判別部２１４は、差額算出部２０２により支払額に基づき算出された差額のうち、所定の条件を満たす商取引についての差額を判別する。差額判別部２１４は、商取引における購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である場合に、その商取引が所定の条件を満たすと判断する。本変形例では、例えば、事業者αが運営する店舗が特定の購入先であり、事業者βが提供する決済サービスが特定の決済手段であるものとする。

差額判別部２１４は、差額が供給されると、その差額と同じユーザＩＤに対応付けて供給された商取引の関連情報が示す店舗名及び決済方法の名称が、事業者αが運営する店舗名又は事業者βが提供する決済サービスの名称である場合、その差額が所定の条件を満たす商取引についての差額だと判別し、そうでない場合、その差額が所定の条件を満たす商取引についての差額ではないと判別する。差額判別部２１４は、供給された差額、ユーザＩＤ及び支出情報を、判別結果とともに差額蓄積部２０４に供給する。

差額蓄積部２０４は、差額判別部２１４から供給された差額、ユーザＩＤ及び判別結果を、差額ＩＤ及びともに供給された支出情報が示す支払日に対応付けて記憶する。
図１８は本変形例で蓄積されている差額の一例を表す。図１８の例では、差額蓄積部２０４は、ユーザＩＤと、支払日と、差額と、差額ＩＤと、運用対象フラグと、ステータスとを対応付けて記憶している。

運用対象フラグは、差額判別部２１４による判別結果を示す情報である。この例では、所定の条件を満たす商取引についての差額であると判別された差額には「対象」という運用対象フラグが対応付けられ、所定の条件を満たす商取引についての差額ではないと判別された差額には「対象外」という運用対象フラグが対応付けられている。「対象」という運用対象フラグは、ユーザの承諾が得られれば（又は既に承諾が得られていて）運用の対象にする差額であることを意味し、「対象外」という運用対象フラグは、その差額は運用の対象ではなく、ユーザへの承諾の要求もされないことを意味している。

差額蓄積部２０４は、運用対象フラグが「対象外」である差額については、ステータスも「対象外」として記憶する。要求時期判断部２０５は、要求時期になったと判断すると、実施例と同様に、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうち、ステータスが「未要求」であるものを読み出して承諾要求部２０６に供給する。このとき、ステータスが「対象外」である差額は読み出されない。そのため、運用対象フラグが「対象」である差額のうちステータスが「未要求」であるものだけが、要求時期判断部２０５によって読み出されて承諾要求部２０６に供給される。

承諾要求部２０６は、こうして供給された差額を資金運用に充てることについての承諾をユーザに要求する。つまり、承諾要求部２０６は、支払額に基づき算出される差額のうち、所定の条件を満たす商取引についての差額を資金運用に充てることについての承諾をユーザに要求する。詳細には、承諾要求部２０６は、購入先又は決済手段のうちの少なくとも１つの事項が予め定められた特定の事項である商取引の支払額に基づき算出される差額を、所定の条件を満たす商取引についての差額として、その差額についての承諾の要求を行う。

以上のとおり、本変形例では、ユーザが行った支払いに基づいて算出された全ての差額ではなく、特定の購入先で商品を購入した支払いの差額と、特定の決済手段を用いた支払いの差額に絞り込んで、資金運用の承諾が要求される。特定の購入先としては、例えば、特定の事業者が運営している店舗（実店舗及び通信販売店舗を含む）が用いられ、特定の決済手段としては、例えば、特定の事業者が行っている決済サービスが用いられる。

これらの店舗及び決済サービスが用いられた商取引は、特定の事業者と特定の関連性（店舗の運営者という関連性及び決済サービスの提供元という関連性）を有する商取引といえる。従って、承諾取得部２２０は、特定の事業者と特定の関連性を有する商取引（この例では特定の購入先で行われる商取引及び特定の決済手段で決済する商取引）について算出された差額のみを表示して承諾を要求する画面を示すデータをユーザ端末３０に送信し、そのユーザ端末３０から返信された返信データが示す差額について承諾を取得することになる。

以下では、特定の購入先で行われる商取引及び特定の決済手段で決済する商取引のように特定の事業者と特定の関連性を有する商取引のことを単に「特定商取引」という。これらの特定商取引による絞り込みを行うことで、特定の購入先及び決済手段を利用する動機をユーザに生じさせ、全ての差額について承諾を要求する場合に比べて、それら特定の購入先及び決済手段が利用されやすいようにすることができる。

なお、特定商取引は上記のものに限らない。例えば、差額判別部２１４は、特定の購入対象を購入する商取引を特定商取引と判断してもよい。ここでいう特定の購入対象とは、個別の商品であってもよいし、特定の事業者が提供する商品群であってもよい。以下では事業者γが提供する商品を特定の商品とする。この場合、例えば支出情報が示す商品名に基づいて、購入対象が予め定められた特定の購入対象であるか否かが判断される。この判断が行われると、全ての差額について承諾を要求する場合に比べて、特定の対象が購入されやすいようにすることができる。

また、差額判別部２１４は、商取引において特定のポイント（特定のポイントサービス事業者が提供するポイント）が付与される場合に、その商取引を特定商取引と判断してもよい。この場合、例えば支出情報が支出額とともに付与されたポイントの情報を示していれば、商取引関連情報取得部２１３が、そのポイントの情報を商取引の関連情報として取得する。そして、承諾取得部２２０は、特定のポイントが付与された商取引における差額に絞り込んで資金運用の承諾を取得する。

これにより、差額の絞り込みを行わずに承諾を取得する場合に比べて、特定のポイントが付与される商取引が利用されやすいようにすることができる。なお、ポイントの付与ではなく、特定のポイントが利用される商取引を特定商取引として差額の絞り込みが行われてもよい。その場合、承諾取得部２２０は、特定のポイントが利用される商取引における差額に絞り込んで資金運用の承諾を取得する。そうすることで、例えば商取引の支払額を全てポイントで支払うとポイントが付与されない場合があるが、その場合の差額も資金運用に充てることができる。

また、差額判別部２１４は、特定の事業者が定めた特定の期間（例えばキャンペーン期間）に行われる商取引を特定商取引と判断してもよい。この場合、商取引関連情報取得部２１３は、商取引が行われた日付情報を含む商取引の関連情報を取得する。そして、承諾取得部２２０は、前述した特定の期間を例えば特定の事業者のシステムから取得して予め記憶しておき、その期間に行われた商取引における差額に絞り込んで資金運用の承諾を取得する。

また、差額判別部２１４は、上述した６種類の特定商取引（特定の購入先で行われる商取引、特定の購入対象を購入する商取引、特定の決済手段で決済する商取引、特定のポイントが付与される商取引、特定のポイントが利用される商取引又は特定の事業者が定めた特定の期間に行われる商取引）のうち、いずれか１つの種類の特定商取引だけに絞り込みを行ってもよいし、２以上の種類の特定商取引に絞り込みを行ってもよい。また、差額判別部２１４は、２以上の種類の特定商取引に同時に当てはまる商取引（例えば特定の購入先で特定の購入対象を購入する商取引）に絞り込みを行ってもよい。

なお、家計簿サーバ装置１０に店舗名や決済方法の名称、付与又は利用されたポイントを示す支出情報が蓄積されていない場合は、商取引関連情報取得部２１３が、例えばその店舗で利用されているＰＯＳシステムや決済サービス、ポイントサービスを提供する事業者の電子決済システムから、各ユーザの商取引が行われた店舗名や決済方法、付与又は利用されたポイントの名称をユーザの商取引に関連する情報として取得すればよい。

また、図１７の例では、所定の条件を満たす商取引（例えば上述した特定商取引）についての差額を判別したが、これに限らず、例えば、支払額取得部２０１が、所定の条件を満たす商取引についての支払額だけを取得してもよい。支払額取得部２０１は、例えば、受け取った支出情報に基づいて、差額判別部２１４と同様に、その支出情報が示す支払いが行われた商取引が所定の条件を満たすか否かを判断すればよい。この場合、差額蓄積部２０４には、商取引が所定の条件を満たす差額だけが蓄積される。

その結果、承諾要求部２０６は、上記の例と同様に、支払額に基づき算出される差額のうち、所定の条件を満たす商取引についての差額を資金運用に充てることについての承諾をユーザに要求することになる。要するに、最終的に承諾要求部２０６が所定の条件を満たす商取引についての差額を資金運用に充てることについての承諾をユーザに要求することになっていれば、商取引が所定の条件を満たすか否かの判断がどこで行われてもよい。

［２−１７］有利な条件での資金運用
上述した差額の絞り込みが行われる場合に、追加の条件が満たされると、その条件が満たされない場合に比べて有利な条件での資金運用がユーザに提示されてもよい。追加の条件としては、例えば、上述した６種類の特定商取引のうち、絞り込みに用いられた商取引以外の種類の商取引が行われた場合に満たされる条件が用いられる。

例えば特定の購入先で行われる商取引で絞り込みが行われた場合に、そのうちの特定の事業者が定めた特定の期間に行われる商取引が行われた場合に満たされる条件が用いられる。本変形例では、絞り込みで用いられた特定の事業者（店舗を運営する事業者、決済サービスを提供する事業者、商品を提供する事業者、ポイントサービス事業者等）が、特定の期間をキャンペーン期間として定めている。その場合に、承諾要求部２０６は、上記のとおり絞り込まれた商取引が定められた特定の期間に行われた場合は、その期間以外に商取引が行われたときに比べて有利な条件で差額を資金運用に充てることについての承諾をユーザに要求する。

有利な条件での資金運用とは、例えば、資金運用のための手数料の割引や手数料の無償化、運用する資金の増額、格付けが特定のレベルより高い金融商品の活用、手続きの短縮、手続きの期限の緩和など、追加の条件が満たされない場合に比べてユーザが金銭的又は時間的な利益を得られる条件を適用して行われる資金運用のことをいう。承諾要求部２０６は、上記の商取引が特定の期間に行われた場合は、有利な条件で差額を資金運用に充てることを表す文字列と、差額ＩＤ、差額及び支払日とを示す要求データを生成してユーザ端末３０に送信する。

図１９は表示された承諾要求の一例を表す。図１９の例では、承諾要求表示部３０３は、選択された差額の「合計金額」（この例では１１８３円）の他、「キャンペーン対象金額」（この例では４２３円）と、「キャンペーン対象金額については資金が１０％増額されます！」という文字列とを、要求データが示す承諾要求Ａ２１として表示している。また、承諾要求表示部３０３は、全選択ボタンＢ３の他に、「キャンペーン対象を全て選択」と書かれた選択ボタンＢ７を表示している。

選択ボタンＢ７を押す操作が行われた場合、「キャンペーン対象金額」のうち選択されていないものがあれば、それらが選択される。この選択ボタンＢ７を表示することで、キャンペーン対象金額の選択漏れがなくなるようにしている。本変形例では、このように承諾要求Ａ２１が表示されることで、前述した有利な条件で差額を資金運用に充てることについての承諾が取得される。これにより、有利な条件の適用がない場合に比べて、上述した特定商取引を行う動機を高めて、その特定商取引について算出される差額の累積額を増加させることができる。

なお、図１９の例では、ユーザは、キャンペーン対象金額以外の金額についても承諾をすることができる。このように、承諾取得部２２０は、特定商取引の差額を資金運用に充てることについての第１承諾と、特定の事業者と特定の関連性を有しない商取引（図１９の例ではキャンペーン期間外に行われた商取引）の差額を資金運用に充てることについての第２承諾とを取得する。ここで、本変形例の移動指示処理実行部２１０は、承諾取得部２２０により承諾が取得された差額の累積額を第１の口座から第２の口座へ移動することに加えて、移動した累積額を資金運用に充てるための処理も行うものとする。

累積額を資金運用に充てるための処理とは、例えば、累積額に資金運用のための手数料を加算して第１の口座から第２の口座に移動させることを指示する処理である。有利な条件として手数料の割引や手数料の無償化が行われる場合、加算される手数料の金額（金額が０の場合を含む）が異なる処理が行われることになる。

また、本変形例において、資金運用を行う際に資金を収めておく口座である第２の口座として有利な条件用の口座及び通常の条件用の口座が開設されている場合があるものとする。その場合は、第１の承諾が得られた差額を有利な条件用の口座に移動させる指示処理と、第２の承諾が得られた差額を通常の条件用の口座に移動させる指示処理というように、累積額の移動先が異なる指示処理が行われる。

また、本変形例において、有利な条件でも通常の条件でも第２の口座は共通しており、資金運用事業者が第２の口座から第１の承諾が得られた差額と第２の承諾が得られた差額とをさらに別々に引き出して資金運用する場合があるものとする。その場合は、資金運用業者に第１の承諾が得られた差額及びそれらが収められた第２の口座を通知する通知処理と、資金運用業者に第２の承諾が得られた差額及びそれらが収められた第２の口座を通知する通知処理というように、異なる差額を通知する処理が行われる。

以上のとおり、本変形例の移動指示処理実行部２１０は、差額を資金運用に充てることについての承諾が第１承諾及び第２承諾のいずれであるかによって別々の処理を実行する。ここでいう別々の処理とは、第２承諾がされた差額の累積額を資金運用に充てるための処理と、第１承諾がされた差額の累積額を第２承諾がされた差額の累積額とは異なる条件で（より有利な条件で）資金運用に充てるための処理とのことであり、資金運用に充てる際の条件を異ならせるために前述した各例のように処理の内容が互いに異なる処理のことをいう。

なお、追加の条件は上述した特定の事業者が定めた特定の期間に限らない。承諾要求部２０６は、絞り込まれた商取引について算出された差額のうち、特定の事業者が定めた特定の期間を除く上述した５種類の特定商取引（特定の購入先で行われる商取引、特定の購入対象を購入する商取引、特定の決済手段で決済する商取引、特定のポイントが付与される商取引又は特定のポイントが利用される商取引）のうち、いずれかの種類の特定商取引について算出された差額を、それ以外の差額に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求してもよい。

具体的には、承諾要求部２０６は、例えば、ユーザが特定の購入先である事業者αが運営する店舗で商品を購入した場合、又は、特定の決済手段である事業者βが提供する決済サービスを用いて商品を購入した場合に、その商取引について算出された差額をそれ以外の差額に比べて有利な条件で資金運用に充てることについての承諾をユーザに要求する。その際に、差額によって条件が異なることを次のように表してもよい。

図２０は表示された要求画面の一例を表す。図２０の例では、承諾要求表示部３０３は、特定商取引についての差額を、それ以外の商取引についての差額と異なる態様で表した（囲み線の太さを異ならせた）要求画面Ｅ１を表示している。なお、適用される有利な条件については、例えば差額を選択することで切り替わった画面又は表示されたポップアップウィンドウに表示させるか、又は、予めユーザに提示しておけばよい。

図２０のように表示することで、全ての差額の表示態様を一律にする場合に比べて、有利な条件で資金運用に充てることが可能な差額を容易に把握することができる。なお、表示態様を異ならせる方法はこれに限らない。差額又は差額を含む枠の色又はフォント等を変えてもよい。また、差額以外に事業者の名称や支払総額の態様を変えることで資金運用の条件が異なることを把握させてもよい。

なお、図１９、図２０の例では、承諾取得部２２０は、上記の６種類の特定商取引のうちの１種類の特定商取引（図１９では特定の事業者が定めた特定の期間に行われる商取引、図２０では特定の購入先で行われる商取引又は特定の決済手段で決済する商取引）について算出された差額をそれ以外の差額に比べて有利な条件で資金運用に充てることについての承諾を取得したが、これに限らない。

承諾取得部２２０は、６種類の特定商取引のうちから２以上の種類の特定商取引が定められている場合に、定められた特定商取引のいずれか１つでも当てはまる商取引について算出された差額をそれら以外の差額（それら以外の種類の特定商取引について算出された差額）に比べて有利な条件で資金運用に充てることについての承諾を取得してもよい。具体的には、承諾取得部２２０は、例えば、特定の購入先で行われる商取引及び特定の決済手段で決済する商取引のいずれか１つでも当てはまる商取引について算出された差額をそれら以外の差額に比べて有利な条件で資金運用に充てることについての承諾を取得する。なお、２以上の種類の特定商取引の組み合わせはこれ以外でもよい。

また、承諾取得部２２０は、６種類の特定商取引のうちの２以上の種類に同時に当てはまる特定商取引について算出された差額をそれ以外の差額に比べて有利な条件で資金運用に充てることについての承諾を取得してもよい。具体的には、承諾取得部２２０は、例えば、特定の購入先で行われて且つ特定の決済手段で決済する商取引について算出された差額をそれら以外の差額に比べて有利な条件で資金運用に充てることについての承諾を取得する。なお、２以上の種類の特定商取引の組み合わせはこれ以外でもよい。

なお、図１９、図２０の例では、差額が絞り込まれたうえで承諾が取得されたが、これに限らず、差額の絞り込みを行わずに同様の承諾が取得されてもよい。その場合は、承諾取得部２２０は、単に蓄積された全ての差額について図１９、図２０の説明で述べたように承諾を取得すればよい。本変形例によれば、上述したいずれの場合でも、有利な条件の適用がない場合に比べて、特定の商取引（特定商取引）を行う動機を高めて、その商取引について算出される差額の累積額を増加させることができる。

［２−１８］お釣り運用サービスの種類
ユーザに提供されるお釣り運用サービスに複数の種類があってもよい。例えば、実施例で述べたように差額の絞り込みも有利な条件での資金運用も行わない一般サービスと、差額を絞り込み且つ絞り込んだ差額については一般サービスに比べて有利な条件で資金運用を行う特別サービスとが提供されてもよい。以下では一般サービスのユーザを一般ユーザといい、特別サービスのユーザを特別ユーザという。

なお、１人のユーザが一般サービス及び特別サービスの両方を利用する場合もあり得るが、その場合は、同じユーザでも一般サービスを利用する場合は一般ユーザとして扱われ、特別サービスを利用する場合は特別ユーザとして扱われるものとする。本変形例では、上述した特定の購入先で行われる商取引、特定の購入対象を購入する商取引、特定の決済手段で決済する商取引、特定のポイントが付与される商取引、特定のポイントが利用される商取引及び特定の事業者が定めた特定の期間に行われる商取引という６種類の商取引のうちの１以上の種類の商取引の差額への絞り込みが行われる。

本変形例では、これらの商取引自体だけでは、特定商取引として扱われず、特別ユーザがこれらの商取引を行った場合にのみ、特定商取引として扱われる。以下ではこれらの商取引を「特別サービスの対象商取引」という。これは、一般ユーザが特別サービスの対象商取引を行っても、その商取引の差額に絞り込みが行われるわけではないので、特定商取引として扱われないということである。つまり、本変形例では、商取引自体の属性（対象、期間、ポイントの有無等）だけではなく、それを行うユーザの属性（一般ユーザか特別ユーザか）によっても「特定の関連性」があるか否かが判断される。

従って、本変形例の承諾取得部２２０は、そのような特別サービスの対象商取引について算出される差額のみを資金運用の対象とするユーザ（つまり特別ユーザ）の商取引を、特定商取引として承諾（本変形例の第１承諾）を取得する。そして、承諾取得部２２０は、特別サービスの対象商取引について算出される差額以外も資金運用の対象とするユーザ（つまり一般ユーザ）の商取引は、特定の事業者と特定の関連性を有しない商取引として承諾（本変形例の第２承諾）を取得する。

本変形例の承諾要求部２０６は、一般ユーザのユーザ端末３０に対しては、実施例と同様の要求画面を示すデータを送信する。また、承諾要求部２０６は、特別ユーザのユーザ端末３０に対しては、例えば図２１に表す要求画面を示すデータを送信する。
図２１は表示された要求画面の一例を表す。図２１の例では、承諾要求表示部３０３は、「クレカβ（クレジットカード会社である事業者βの名称）」、「スーパーε」、「ζポイント」という商取引に関連する事業者又はその事業者が提供するポイントサービスの名称と、その商取引の支払総額と、算出された差額と、個別選択ボタンＢ４とを含む要求画面Ｅ２を表示している。

例えば１番上の行には、「クレカβ」という名称、「１０６７円」という支払総額、「３３円」という差額と、この差額が選択されていることを示す「○」という個別選択ボタンＢ４が表示されている。承諾要求表示部３０３は、特別サービスの対象商取引については、名称（この例では「クレカβ」、「ζポイント」）、支払総額、差額及び個別選択ボタンＢ４を表示して、それ以外の商取引（この例では「スーパーε」が関連する商取引）については名称及び支払総額のみを表示し、差額及び個別選択ボタンＢ４の欄には「−」を表示している。

また、承諾要求表示部３０３は、「合計金額」として、個別選択ボタンＢ４が「○」となっている差額を合計した金額を表示している。なお、承諾要求部２０６は、特別サービスの対象ではない商取引については事業者の名称及び支払総額も含まない要求画面を示すデータを送信してもよい（図２１の例では「スーパーε」の名称及び支払総額が表示されなくなる）。

いずれの場合も、特別サービスの対象商取引について算出された差額のみを表示することで、全ての差額を表示する場合に比べて、ユーザに自分が資金運用に充てることが可能な差額を容易に認識させることができる。また、特別サービスの対象ではない商取引の差額は選択できないようにしているので、特別ユーザによる特別サービスの対象ではない商取引の差額の誤選択を防止することができる。

本変形例でも、移動指示処理実行部２１０は、差額を資金運用に充てることについての承諾が第１承諾である（つまり特別ユーザの承諾である）場合には、その承諾が第２承諾である（つまり一般ユーザの承諾である）場合に比べて、承諾された差額の累積額をより有利な条件で資金運用に充てるための処理を実行する。これにより、複数サービスで資金運用の条件を一律にする場合に比べて、特定のサービス（この例では一般サービスよりも有利に資金運用を行うことができる特別サービス）のユーザを増やすことができる。本変形例の場合は、特別サービスのユーザが増えるので、特別サービスの対象商取引の増加に繋げることができる。

［２−１９］発明のカテゴリ
本発明は、資金運用支援サーバ装置、ユーザ端末及び家計簿サーバ装置のような情報処理装置の他、それらの装置を備える資金運用支援システムのような情報処理システムとしても捉えられる。また、本発明は、各装置が実施する処理を実現するための情報処理方法としても捉えられる。その場合、各処理を実現する主体となる情報処理装置は複数に分かれていてもよい。また、各装置を制御するコンピュータを機能させるためのプログラムとしても捉えられる。このプログラムは、それを記憶させた光ディスク等の記録媒体の形態で提供されてもよいし、インターネット等のネットワークを介してコンピュータにダウンロードさせ、それをインストールして利用可能にするなどの形態で提供されてもよい。

１…資金運用支援システム、１０…家計簿サーバ装置、１０１…収入情報取得部、１０２…支出情報取得部、１０３…家計情報蓄積部、２０…資金運用支援サーバ装置、２０１…支払額取得部、２０２…差額算出部、２０３…差額取得部、２０４…差額蓄積部、２０５…要求時期判断部、２０６…承諾要求部、２０７…承諾可否受付部、２０８…撤回受付部、２０９…資金移動時期判断部、２１０…移動指示処理実行部、２１１…ユーザ関連情報取得部、２１２…ユーザ関連情報蓄積部、２１３…商取引関連情報取得部、２１４…差額判別部、２１５…集金情報通知部、２２０…承諾取得部、３０…ユーザ端末、３０１…レシート読取部、３０２…支出情報送信部、３０３…承諾要求表示部、３０４…承諾可否操作受付部、３０５…承諾可否通知部、３０６…履歴表示部、３０７…撤回操作受付部、３０８…撤回通知部。

Claims (7)

1. 商取引における支払額に基づき算出される金額を蓄積する蓄積部と、
   ユーザにより所定の操作が行われる前になされた１以上の商取引における前記金額を資金運用に充てることについての承諾を取得する承諾取得部であって、特定の事業者と特定の関連性を有する商取引の前記金額を資金運用に充てることについての第１承諾と、当該関連性を有しない商取引の前記金額を資金運用に充てることについての第２承諾とを取得する承諾取得部と、
   所定の期間が経過すると、前記承諾が取得された金額の累積額を第１の口座から第２の口座へ移動して資金運用に充てるための処理であって、当該承諾が前記第１承諾及び前記第２承諾のいずれであるかによって当該累積額を異なる条件で資金運用に充てるための別々の処理を実行する実行部と
   を備える情報処理装置。
2. 前記承諾取得部は、特定の購入先で行われる商取引、特定の購入対象を購入する商取引、特定の決済手段で決済する商取引、特定のポイントが付与される商取引、特定のポイントが利用される商取引又は前記事業者が定めた特定の期間に行われる商取引の前記金額のみを資金運用の対象とするユーザの商取引を前記特定の関連性を有する商取引として前記承諾を取得する
   請求項１に記載の情報処理装置。
3. 前記承諾取得部は、特定の購入先で行われる商取引、特定の購入対象を購入する商取引、特定の決済手段で決済する商取引、特定のポイントが付与される商取引、特定のポイントが利用される商取引又は前記事業者が定めた特定の期間に行われる商取引を前記特定の関連性を有する商取引として前記承諾を取得する
   請求項１に記載の情報処理装置。
4. 前記特定の関連性を有する商取引には、支払額を現金で支払ったユーザの識別情報及び支払情報が前記事業者のシステムによって取得される商取引が含まれ、
   前記蓄積部は、前記事業者のシステムから取得される前記識別情報及び前記支払情報を蓄積し、
   前記承諾取得部は、蓄積された前記識別情報が示すユーザの、蓄積された前記支払情報から算出される前記金額についての前記承諾を取得する
   請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記承諾取得部は、前記特定の関連性を有する商取引について算出された金額のみを表示して前記第１承諾を要求する画面を示すデータをユーザ端末に送信し、当該ユーザ端末から返信された返信データが示す金額について前記第１承諾を取得する
   請求項２又は３に記載の情報処理装置。
6. 前記承諾取得部は、前記特定の関連性を有する商取引について算出された金額を当該事業者が関連しない商取引について算出された金額と異なる態様で表示して前記承諾を要求する画面を示すデータをユーザ端末に送信し、当該ユーザ端末から返信された返信データが示す金額について前記第１承諾を取得する
   請求項３に記載の情報処理装置。
7. 前記所定の期間の経過前に行われた複数の商取引について蓄積された前記金額をそれぞれ示す金額情報をユーザ端末へ送信する送信部と、
   送信された前記金額情報が示す金額のうち資金運用に充てると選択された金額を示す選択金額情報を、前記ユーザ端末から受信する受信部とを備え、
   前記実行部は、受信された前記選択金額情報が示す前記選択された金額の累積額の前記移動を指示する処理を実行する
   請求項１から６のいずれか１項に記載の情報処理装置。

Images