JP7027047B2 - 算出装置、算出方法及び算出プログラム - Google Patents

Description

本発明は、算出装置、算出方法及び算出プログラムに関する。

従来、インターネットを介して、資産管理に関するサービスが提供されている。ユーザは、このようなサービスに入出金を登録することで、収支を把握したり、長期的な貯蓄計画を立てたりすることができる。

例えば、資産管理に関する技術として、会計情報を取得することによって、収支の内容をひと目で把握することのできる資金表を作成する技術が知られている。また、収支データを携帯端末から取得し、取得した情報に基づいて家計管理のシミュレーションを行うことのできる技術が知られている。また、短期及び長期の支出入の予定を一括して表示することのできる電子通帳に関する技術が知られている。

特開２００５－１３５２９５号公報 特開２００７－２５７１４５号公報 特開２０１５－１２５５３１号公報

しかしながら、上記の従来技術では、資産管理に関する敷居を下げることは難しい。具体的には、上記の従来技術では、ユーザが収支を登録したり、予め収支が記録された会計情報を準備したりすることを要する。資産管理に慣れていないユーザにとってはこのような作業は負担が大きく、従来技術では、積極的に資産管理を行おうとする動機付けをユーザに与えることは難しい。

本願は、上記に鑑みてなされたものであって、資産管理に関する敷居を下げることができる算出装置、算出方法及び算出プログラムを提供することを目的とする。

本願に係る算出装置は、ネットワークを介して提供されるサービスにおけるユーザの利用状況を取得する取得部と、前記利用状況と当該利用状況から推定されるユーザの資産の変動との関係性を定義した定義データと、前記取得部によって取得された利用状況とに基づいて、当該ユーザの収支を推定する算出部と、を備え、前記取得部は、スケジュール管理に関するサービスの利用において、前記ユーザが登録したスケジュール情報を取得し、前記算出部は、前記スケジュール情報に基づいて、前記ユーザの収支を推定することを特徴とする。

実施形態の一態様によれば、資産管理に関する敷居を下げることができるという効果を奏する。

図１は、実施形態に係る算出処理の一例を示す図である。 図２は、実施形態に係る算出処理の一例を説明する図である。 図３は、実施形態に係る算出処理システムの構成例を示す図である。 図４は、実施形態に係る算出装置の構成例を示す図である。 図５は、実施形態に係る属性テーブルの一例を示す図である。 図６は、実施形態に係る利用状況テーブルの一例を示す図である。 図７は、実施形態に係る定義テーブルの一例を示す図である。 図８は、実施形態に係る学習テーブルの一例を示す図である。 図９は、実施形態に係るコンテンツ記憶部の一例を示す図である。 図１０は、実施形態に係るユーザ端末の構成例を示す図である。 図１１は、実施形態に係る処理手順を示すフローチャート（１）である。 図１２は、実施形態に係る処理手順を示すフローチャート（２）である。 図１３は、実施形態に係る処理手順を示すフローチャート（３）である。 図１４は、算出装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る算出装置、算出方法及び算出プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る算出装置、算出方法及び算出プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．算出処理の一例〕
まず、図１を用いて、実施形態に係る算出処理の一例について説明する。図１は、実施形態に係る算出処理の一例を示す図である。

図１に示す算出装置１００は、ネットワークを介して提供されるサービスにおけるユーザの利用状況を取得し、取得された利用状況と、当該利用状況から推定されるユーザの資産の変動との関係性に基づいて、ユーザの収支を算出するサーバ装置である。なお、実施形態では、サービスとして、インターネット等のネットワークを介して提供される種々のサービスを例として挙げる。例えば、サービスは、ウェブサイトを介して提供されるウェブサービスでもよいし、スマートフォン等にインストールされるアプリを介して提供されるサービスでもよい。

図１に示すサービスサーバ３０は、サービスをユーザに提供するサーバ装置である。例えば、サービスサーバ３０は、ウェブサービスを提供するウェブサーバである。一例として、サービスサーバ３０は、ユーザのスケジュールを管理するスケジュールサービス（いわゆるカレンダーサービスや、タスク管理サービス等）を提供する。また、サービスサーバ３０は、ポータルサービスや、検索サービスや、ショッピングサービスや、オークションサービスや、情報提供サービス（例えば地図情報サービスや、ナビゲーションサービスや、ニュースサービスや、天気予報サービス）等の各種サービスを提供してもよい。なお、図１での図示は省略しているが、実施形態に係るサービスサーバ３０は１台に限らず、複数台存在していてもよい。

図１に示すユーザ端末１０は、ユーザに利用されるスマートフォン等の情報処理端末である。また、図１に示すユーザＵ０１は、サービスサーバ３０から提供されるサービスを利用するユーザの一例である。図１に示す例では、ユーザ端末１０は、ユーザＵ０１によって利用されるものとする。なお、図１での図示は省略しているが、実施形態に係るユーザ端末１０は１台に限らず、複数台存在していてもよい。すなわち、ユーザＵ０１は、複数台のユーザ端末１０を所持していてもよい。なお、以下では、ユーザをユーザ端末１０と読み替える場合がある。例えば、「ユーザＵ０１がサービスサーバ３０にアクセスする」という記載は、実際には、「ユーザＵ０１が利用するユーザ端末１０がサービスサーバ３０にアクセスする」という状況を示す場合がある。

図１に示す例において、算出装置１００は、サービスにおけるユーザＵ０１の利用状況をサービスサーバ３０もしくはユーザ端末１０から取得し、取得した利用状況に基づいて、ユーザＵ０１の収支を算出する。例えば、算出装置１００は、ユーザ端末１０上で動作する収支管理アプリに係る処理を実行するサーバ装置であり、かかるアプリを介して、ユーザＵ０１の収支を管理する。すなわち、算出装置１００は、ユーザＵ０１の収支の管理において、ユーザＵ０１から収支の入力操作等を受け付けずとも、ユーザＵ０１が日常的に利用する各種サービスの利用状況に基づいて収支を算出することができる。言い換えれば、算出装置１００は、例えばユーザＵ０１が適切な収支の入力を行うことができなかったり、入力を怠ったりした場合であっても、日常のユーザＵ０１の行動から収支を管理することができる。このように、算出装置１００は、ユーザＵ０１の収支管理に関する手間を省かせることで、資産管理に関する敷居を下げることができる。以下、図１を用いて、算出装置１００による実施形態に係る算出処理の流れについて説明する。

まず、ユーザＵ０１は、ユーザ端末１０を介して、サービスサーバ３０から提供される各種サービスを利用する（ステップＳ１１）。例えば、ユーザＵ０１は、サービスサーバ３０が提供するスケジュールサービスを利用する。より具体的には、ユーザＵ０１は、サービスサーバ３０が提供するカレンダーアプリをユーザ端末１０にインストールし、カレンダーアプリによってスケジュールを管理するサービスを利用する。なお、ユーザＵ０１は、サービスサーバ３０から提供される他のサービスとして、飲食店や交通機関等を予約する予約サービスや、ショッピングサービスや、オークションサービス等を利用してもよい。

算出装置１００は、ユーザＵ０１がサービスを利用した際の、サービスにおける利用状況をユーザ端末１０から取得する（ステップＳ１２）。算出装置１００は、取得した利用状況を利用状況記憶部１２１に格納する。なお、算出装置１００は、サービスにおけるユーザＵ０１の利用状況をサービスサーバ３０から取得してもよい。

図１の例では、算出装置１００は、利用状況として、ユーザＵ０１がカレンダーアプリにおいて登録したスケジュール情報を取得したものとする。なお、実施形態において、サービスにおける利用状況には、サービスにおいてユーザＵ０１が採った行動に関するログ情報（行動履歴や利用履歴）のみならず、サービスを利用する際にユーザＵ０１が送受信した情報や、サービスを利用する際のユーザＵ０１のコンテキスト（context）に関する情報が含まれてもよい。また、サービスにおける利用状況には、サービスを利用するユーザＵ０１の属性情報（ユーザＵ０１の年齢や性別、居住地、職種、勤務先等）が含まれてもよい。

算出装置１００は、取得した利用状況に基づいて、ユーザＵ０１の収支を算出する（ステップＳ１３）。詳細は後述するが、算出装置１００は、利用状況と、当該利用状況から推定されるユーザの資産の変動との関係性を定義した定義データを算出情報記憶部１２５に保持する。例えば、算出装置１００は、算出装置１００の管理者等から入力を受け付けることにより取得した定義データを保持する。そして、算出装置１００は、定義データを参照し、取得した利用状況に対応した収支の額を算出する。

例えば、算出装置１００は、ユーザＵ０１がカレンダーアプリにおいて４時間分のアルバイトの予定を登録した、という利用状況を取得したものとする。この場合、算出装置１００は、アルバイトの１時間分の収支額が定義された定義データを参照する。そして、算出装置１００は、参照した定義データに基づいてユーザＵ０１が登録したアルバイトの４時間分の収支額を算出し、算出した額をアルバイトが行われる日における収支の額として登録する。具体的には、算出装置１００は、アルバイトの１時間分の収支額が「１０００円」の収入と定義されていた場合、アルバイトの４時間分の収支額を「４０００円」の収入と算出する。そして、算出装置１００は、ユーザＵ０１がアルバイトを行う予定日の収入額に「４０００円」を加算する。

そして、算出装置１００は、算出した収支をユーザＵ０１に送信する（ステップＳ１４）。なお、収支の算出や、算出した収支の結果情報は、例えば、算出装置１００が提供する収支管理アプリを介して行われてもよい。

ユーザＵ０１は、算出された結果を参照し、もし収支の額に相違がある場合には、修正した収支を算出装置１００に送信する（ステップＳ１５）。例えば、ユーザＵ０１は、「４０００円」と算出された収入額が、実際には「４４００円」である場合には、ステップＳ１４において送信された収支の額を「４４００円」に修正する。

算出装置１００は、ユーザＵ０１から修正した収支が送信された場合、収支の額を修正するとともに、修正結果を学習する（ステップＳ１６）。例えば、算出装置１００は、定義データに基づいて算出した額と、ユーザＵ０１が修正した収支の額との齟齬を学習する。具体的には、算出装置１００は、ユーザＵ０１のアルバイトの４時間分の収入は「４４００円」という修正結果に基づき、かかる結果をユーザＵ０１における正解データと学習する。例えば、算出装置１００は、ユーザＵ０１のアルバイトの１時間分の収支額は「４４００／４＝１１００円」の収入である、とする定義データを生成する。

このようにして、算出装置１００は、ユーザＵ０１がスケジュールを更新する度に、当該スケジュールに基づいて、収支の額を算出する。これにより、算出装置１００は、ユーザＵ０１から「Ｘ月Ｙ日に４４００円の収入を得た」といった具体的な数値の入力を受け付けることなく、ユーザＵ０１の収支を算出することができる。

また、算出装置１００は、ユーザからコンテンツ配信の要求を受け付けた場合、算出結果に基づいて、ユーザに配信するコンテンツであって、ユーザに適したコンテンツを抽出してもよい（ステップＳ１７）。実施形態において、コンテンツとは、例えば、収支管理アプリとともに表示される広告等である。例えば、算出装置１００は、ユーザＵ０１が、１時間分の収入として「１１００円」を得るようなアルバイトを行っていることを参照する。この場合、算出装置１００は、例えば、１時間分の収入として「１１００円」を超える額のアルバイトに関する求人募集広告を、コンテンツ記憶部１２９に格納されたコンテンツの中から抽出する。あるいは、算出装置１００は、ユーザＵ０１の収支の履歴を参照し、ユーザＵ０１に適した金融商品を勧める広告を抽出してもよい。

算出装置１００は、抽出したコンテンツをユーザ端末１０に配信する（ステップＳ１８）。これにより、算出装置１００は、ユーザＵ０１が興味関心を抱くと推定されるコンテンツを優先的に配信できるので、コンテンツの訴求効果を向上させることができる。

次に、図２を用いて、図１で説明した算出処理の流れについて、ユーザ端末１０上でのユーザＵ０１の操作に焦点を当てて説明する。図２は、実施形態に係る算出処理の一例を説明する図である。図２では、ユーザ端末１０が、サービスサーバ３０から提供されるスケジュールサービスや、算出装置１００から送信された収支に関する情報等を表示する例を示す。なお、図２の例では、スケジュールサービスがカレンダーアプリ６０により実現され、算出装置１００との情報の送受信が収支管理アプリ７０によって実現される例を示す。

図２に示すように、ユーザ端末１０は、カレンダーアプリ６０を画面に表示する。ユーザＵ０１は、スケジュールの日程や、時間や、行動の種別を入力し、スケジュール登録を行う。具体的には、ユーザＵ０１は、スケジュールの日程等の情報を入力し、指８０を用いて、「ＯＫ」と表示されたボタンをタッチする。かかる操作を受けて、ユーザ端末１０は、スケジュールの登録をサービスサーバ３０に送信する。また、ユーザ端末１０は、カレンダーアプリ６０に関する利用状況として、スケジュール情報を算出装置１００に送信する（ステップＳ２１）。

算出装置１００は、ユーザ端末１０から送信されたスケジュール情報に基づいて、当該スケジュールに関する収支の額を算出し、算出した結果をユーザ端末１０に送信する。ユーザ端末１０は、算出装置１００から算出結果を受信した場合に、収支管理アプリ７０を画面に表示する。

ユーザ端末１０は、算出装置１００から送信された算出結果を収支管理アプリ７０内に表示する。図２の例では、算出装置１００は、ユーザＵ０１のアルバイトによる収入額を「４０００円」と算出したとする。この場合、ユーザ端末１０は、算出装置１００が算出した収入額「４０００円」を画面に表示する。また、図２の例では、算出装置１００は、ユーザＵ０１がアルバイト先へ向かうための交通費（支出額）を「３００円」と算出したものとする。この場合、ユーザ端末１０は、算出装置１００が算出した支出額「３００円」を画面に表示する。

ユーザＵ０１は、表示された算出結果を修正する必要のない場合、指８０を用いて、「ＯＫ」と表示されたボタンをタッチする。一方、ユーザＵ０１は、算出結果を修正することを所望する場合、指８０を用いて、「修正」と表示された修正要求ボタン７２をタッチする。その後、ユーザ端末１０は、ユーザＵ０１から受け付けた修正（修正された収入額や支出額）を算出装置１００に送信する（ステップＳ２２）。

算出装置１００は、ユーザ端末１０から送信された修正結果を受けて、修正された収支の額をユーザ端末１０に送信する。ユーザ端末１０は、算出装置１００から受信した修正結果を収支管理アプリ７０内に表示する。ユーザＵ０１は、修正された結果に問題がなければ、指８０を用いて、「ＯＫ」と表示されたボタンをタッチする。一方、ユーザＵ０１は、さらに修正を所望する場合、指８０を用いて、「修正」と表示された修正要求ボタン７２をタッチする。かかる処理を繰り返し、算出装置１００は、ユーザＵ０１に最適化された算出を行うことができるよう学習を行う。

なお、図１及び図２で説明した処理において、算出装置１００は、ユーザＵ０１の属性を加味した算出を行ってもよい。例えば、図１及び図２で示したアルバイトの額等は、ユーザＵ０１の年齢や居住地等に応じて変動すると想定される。この場合、算出装置１００は、定義データに対して、属性情報に基づく調整処理を行った上で収支の算出を行ってもよい。例えば、算出装置１００は、定義された収支額に対して、属性情報に応じた所定の係数を乗算する等の調整を行ってもよい。

また、算出装置１００は、曜日や時間帯を加味した判定を行ってもよい。例えば、図１及び図２で示したアルバイトの額等は、曜日や時間帯に応じて変動すると想定される。具体的には、アルバイトの額等は、土曜日や日曜日の曜日や、深夜や早朝の時間帯では、他の曜日や時間帯と比較して高額になると想定される。この場合、算出装置１００は、定義データに対して、曜日や時間帯に基づく調整処理を行った上で収支の算出を行ってもよい。

なお、算出装置１００が算出する行動種別はアルバイトに限られない。算出装置１００は、例えば、種々の行動種別の定義データを保持し、かかる定義データに基づいて収支を算出する。例えば、算出装置１００は、スケジュール登録されるイベントごとに定義データを有する。例えば、算出装置１００は、飲み会やデートなどのイベントで発生すると想定される収支額を定義したデータを保持し、かかる定義に基づいて支出額を算出してもよい。

また、算出装置１００は、スケジュール情報に限らず、種々の利用状況に基づいて算出を行ってもよい。例えば、算出装置１００は、ユーザＵ０１がショッピングサイトやオークションサイトを利用して商品の取引を行った場合、取引額を収支額として算出してもよい。あるいは、算出装置１００は、ユーザＵ０１が予約サイトを利用して宿泊施設を予約した場合、予定される宿泊料金を宿泊予定日の支出額として算出してもよい。

また、算出装置１００は、カーナビサービスや、位置情報サービス等の利用状況に基づいて算出を行ってもよい。例えば、算出装置１００は、カーナビサービスで捕捉されるユーザＵ０１の位置情報の推移から、ユーザＵ０１が利用した高速道路の通行料を支出額として算出してもよい。また、算出装置１００は、位置情報サービスで捕捉されるユーザＵ０１の位置情報の推移から、交通機関を利用したことを推定し、交通機関に設定された交通費等を支出額として算出してもよい。

なお、算出装置１００は、上記のような位置情報の推移等を利用する場合、ユーザ端末１０の位置情報を定期的に取得してもよい。例えば、算出装置１００は、ユーザ端末１０が有するＧＰＳ（Global Positioning System）機能によって取得された位置情報を、サービスの利用中の所定時間ごと（例えば１分ごと）に取得する。なお、算出装置１００が取得する位置情報は、ＧＰＳ機能によって取得される位置情報に限られず、例えば、サービスにアクセスしたユーザ端末１０のＩＰアドレス等から推定される位置情報であってもよい。また、位置情報は、経度や緯度を示す具体的な数値であってもよいし、所定の地域を示す住所情報等であってもよい。この場合、算出装置１００は、例えば、位置情報と住所情報とを関連付けるための定義データベース等を参照し、取得した位置情報から住所情報を特定してもよい。

また、算出装置１００は、例えばＳＮＳ（Social Networking Service）の利用状況に基づいて、ユーザＵ０１とつながりのある他ユーザを特定してもよい。そして、算出装置１００は、ユーザＵ０１とつながりのある他ユーザに係る情報に基づいて、収支を算出してもよい。例えば、算出装置１００は、ユーザＵ０１とつながりのある他ユーザの誕生日には、ユーザＵ０１に一定の支出が発生するとする定義データを有するものとする。この場合、算出装置１００は、他ユーザがＳＮＳに登録している誕生日の情報を参照し、その誕生日において、定義された額をユーザＵ０１の支出額として算出する。

以上、図１及び図２を用いて説明してきたように、実施形態に係る算出装置１００は、ネットワークを介して提供されるサービスにおける、ユーザＵ０１の利用状況を取得する。そして、算出装置１００は、取得した利用状況と、当該利用状況から推定されるユーザＵ０１の資産の変動との関係性に基づいて、ユーザの収支を算出する。

このように、算出装置１００は、サービスにおける利用状況に基づいてユーザＵ０１の収支を算出するため、ユーザＵ０１が意識的に収支の額等の入力を行わずとも、ユーザＵ０１の日常的な行動に基づいて、ユーザＵ０１の収支管理を行うことができる。これにより、算出装置１００は、収支管理に関するユーザＵ０１の負担を下げることができるため、資産管理に関する敷居を下げることができる。以下、このような処理を行う算出装置１００、及び、算出装置１００を含む算出処理システム１の構成等について、図３以下を用いて詳細に説明する。

〔２．算出処理システムの構成〕
図３を用いて、実施形態に係る算出装置１００が含まれる算出処理システム１の構成について説明する。図３は、実施形態に係る算出処理システム１の構成例を示す図である。図３に例示するように、実施形態に係る算出処理システム１には、ユーザ端末１０と、サービスサーバ３０と、算出装置１００とが含まれる。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。なお、図３に示した算出処理システム１には、複数台のユーザ端末１０や、複数台のサービスサーバ３０が含まれてもよい。

ユーザ端末１０は、例えば、スマートフォンや、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣや、タブレット型端末や、携帯電話機、ＰＤＡ（Personal Digital Assistant）、ウェアラブルデバイス（Wearable Device）等の情報処理装置である。さらに、ユーザ端末１０には、情報処理機能を有する種々のスマート機器が含まれてもよい。例えば、ユーザ端末１０には、ＴＶ（Television）や設置型スピーカなどのスマート家電や、自動車などのスマートビークル（Smart vehicle）や、ドローン（drone）、家庭用ロボットなどが含まれてもよい。

ユーザ端末１０は、ユーザによる操作に従って、サービスサーバ３０にアクセスすることで、サービスサーバ３０から提供されるサービスコンテンツ（例えばウェブページ）を取得する。そして、ユーザ端末１０は、取得したサービスコンテンツを表示装置（例えば、液晶ディスプレイ）に表示する。なお、ユーザ端末１０は、インストールされたアプリ等を介してサービスサーバ３０にアクセスし、サービスを利用してもよい。また、ユーザ端末１０は、ユーザがサービスを利用する場合には、所定の情報を検知し、検知した情報をサービス側に送信してもよい。例えば、ユーザ端末１０は、ユーザが所定のサービスを利用する場合に、検知した位置情報をサービスサーバ３０に送信してもよい。

サービスサーバ３０は、ユーザ端末１０からアクセスされた場合に、各種サービスを提供するサーバ装置である。サービスサーバ３０は、例えば、ポータルサイト、ニュースサイト、天気予報サイト、ショッピングサイト、オークションサイト、ファイナンス（株価）サイト、路線検索サイト、地図提供サイト、旅行情報サイト、飲食店紹介サイト、飲食店等の予約サイト、ウェブブログ、ＳＮＳ（Social Networking Service）などに関する各種ウェブページを介して、各種サービスを提供する。あるいは、サービスサーバ３０は、アプリ等を介して各種サービスを提供する。

また、サービスサーバ３０は、サービスにおけるユーザの利用状況を取得する。例えば、サービスサーバ３０がスケジュールサービスを提供する場合には、ユーザが登録したスケジュール情報を取得する。また、例えば、サービスサーバ３０がポータルサイトに係るサービスを提供する場合には、サービスサーバ３０は、利用状況として、ユーザの登録情報（性別や年齢等の属性情報）や、ログイン時の位置情報等を取得する。また、サービスサーバ３０がショッピングサイトやオークションサイト等の購買に係るサービスを提供する場合には、サービスサーバ３０は、利用状況として、ユーザが商品を購入する頻度や購入価格等の情報を取得する。また、サービスサーバ３０は、上記以外のサービスにおいても、ユーザがサービスを利用するたびに、サービスにおける様々な利用状況を取得する。また、サービスサーバ３０は、サービスにおけるユーザの利用状況を算出装置１００に送信してもよい。

算出装置１００は、サービスにおけるユーザの利用状況と、当該利用状況から推定されるユーザの資産の変動との関係性に基づいて、ユーザの収支を算出するサーバ装置である。なお、算出装置１００は、ユーザにサービスを提供するサービスサーバ３０としての機能を兼ねていてもよい。例えば、算出装置１００は、ユーザにスケジュールサービスを提供し、当該スケジュールサービスにおける利用状況に基づいて、ユーザの収支を算出してもよい。

〔３．算出装置の構成〕
次に、図４を用いて、実施形態に係る算出装置１００の構成について説明する。図４は、実施形態に係る算出装置１００の構成例を示す図である。図４に示すように、算出装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、算出装置１００は、算出装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。かかる通信部１１０は、ネットワークＮと有線又は無線で接続され、ネットワークＮを介して、ユーザ端末１０や、サービスサーバ３０との間で情報の送受信を行う。

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

（利用状況記憶部１２１について）
利用状況記憶部１２１は、サービスにおける利用状況に関する情報を記憶する。図４に示すように、利用状況記憶部１２１は、情報を記憶するデータテーブルとして、属性テーブル１２２と、利用状況テーブル１２３とを有する。

（属性テーブル１２２について）
属性テーブル１２２は、サービスに登録されたユーザの属性情報を記憶する。図５に、実施形態に係る属性テーブル１２２の一例を示す。図５は、実施形態に係る属性テーブル１２２の一例を示す図である。図５に示した例では、属性テーブル１２２は、「ユーザＩＤ」、「性別」、「年齢」、「自宅位置」、「誕生日」、「職種」、「つながり情報」といった項目を有する。

「ユーザＩＤ」は、ユーザを識別する識別情報である。なお、ユーザＩＤは、ユーザが所有するユーザ端末１０を識別する識別情報と読み替えてもよい。また、本明細書中では、図５に示したような識別情報を参照符号として用いる場合がある。例えば、ユーザＩＤ「Ｕ０１」によって識別されるユーザを「ユーザＵ０１」と表記する場合がある。

「性別」は、ユーザの性別を示す。「年齢」は、ユーザの年齢を示す。「自宅位置」は、ユーザの自宅が所在する位置を示す。なお、「自宅位置」には、具体的な住所ではなく、ユーザの自宅に対応する位置情報（例えば、経度及び緯度）が記憶されてもよい。「誕生日」は、ユーザの誕生日を示す。「職種」は、ユーザの職種を示す。

「つながり情報」は、ユーザとつながりのある他ユーザの情報等を含む。図５では、つながり情報を「Ａ０１」のように概念的に表記しているが、実際には、つながり情報の項目には、ＳＮＳ上でユーザと友人関係にある他ユーザを識別する情報や、他ユーザの属性情報や、ユーザの家族の属性情報等が記憶される。

なお、算出装置１００は、上記のようなユーザの属性情報をサービスサーバ３０から取得してもよいし、ユーザ端末１０から収支管理アプリ７０への登録を受け付けた場合に取得してもよい。

すなわち、図５に示したデータの一例は、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１に関する属性情報を示している。また、ユーザＵ０１の性別は「男性」であり、年齢は「２０歳代」であり、自宅位置は「東京都・・・」であり、誕生日が「１９ＸＸ年Ｘ月Ｘ日」であり、職種は「学生」であり、つながり情報は「Ａ０１」であることを示している。

なお、属性テーブル１２２に記憶される属性情報は、必ずしも正確な情報でなくともよい。例えば、算出装置１００は、サービスの利用状況から推定される「推定性別」や「推定年齢」等を属性テーブル１２２に記憶してもよい。

（利用状況テーブル１２３について）
続いて、図６に、実施形態に係る利用状況テーブル１２３の一例を示す。図６は、実施形態に係る利用状況テーブル１２３の一例を示す図である。利用状況テーブル１２３は、サービスにおけるユーザの利用状況を記憶する。図６に示した例では、利用状況テーブル１２３は、「ユーザＩＤ」、「利用ログＩＤ」、「取得日時」、「サービス」、「情報種別」、「取得情報」といった項目を有する。

「ユーザＩＤ」は、図５に示した同様の項目と対応する。「利用ログＩＤ」は、ユーザがサービスを利用した行動履歴（ログ）を識別する識別情報を示す。「取得日時」は、ユーザの利用ログが取得された日時を示す。例えば、取得日時は、ユーザがサービスにスケジュールを登録した日時や、ユーザがショッピングを行った日時等である。このため、取得日時は、収支額の算出対象となる日程とは関係のない場合もある。例えば、スケジュール情報の場合、スケジュールが登録されたタイミングではなく、スケジュールとして登録された日程が、収支額の算出対象となる日程と関係を有する。

「サービス」は、ユーザが利用したサービスの種別を示す。「情報種別」は、利用状況として取得された情報の種別を示す。「取得情報」は、取得された利用状況の具体的な内容を示す。

すなわち、図６に示したデータの一例では、ユーザＵ０１のサービスにおけるログとして、利用ログＩＤ「Ｂ１１」で識別される利用ログＢ１１が記憶されていることを示している。また、利用ログＢ１１は、取得日時が「２０１７年５月６日 １５：００」であり、「スケジュール管理」に関するサービスにおけるログであり、利用状況として取得された情報種別は「スケジュール」であることを示している。また、その取得情報は「５月８日１１時００分～５月８日１５時００分において予定の登録が行われた」ことを示している。なお、図６では図示を省略しているが、取得情報には、より具体的な情報が含まれてもよい。例えば、上記の取得情報には、予定登録に係る行動がアルバイトであるといった具体的な情報が含まれてもよい。

（算出情報記憶部１２５について）
算出情報記憶部１２５は、実施形態に係る算出処理に関する情報を記憶する。図４に示すように、算出情報記憶部１２５は、情報を記憶するデータテーブルとして、定義テーブル１２６と、学習テーブル１２７とを含む。

（定義テーブル１２６について）
定義テーブル１２６は、サービスの利用状況と、当該利用状況から推定されるユーザの資産の変動との関係性を定義した定義データを記憶する。図７に、実施形態に係る定義テーブル１２６の一例を示す。図７は、実施形態に係る定義テーブル１２６の一例を示す図である。図７に示した例では、定義テーブル１２６は、「定義ＩＤ」、「情報種別」、「行動種別」、「収支」、「金額」、「調整データ」といった項目を有する。

「定義ＩＤ」は、各定義データを識別する識別情報を示す。「情報種別」は、図６に示した同一の項目に対応する。「行動種別」は、利用状況における具体的なユーザの行動の種別を示す。「収支」は、利用状況に対応した資産の変動が収入であるか支出であるかといった定義を示す。「金額」は、利用状況に対応する資産の変動における具体的な金額を示す。

「調整データ」は、定義された収支の別や金額等を調整するデータを示す。図７では、調整データを「Ｌ１１」のように概念的に表記しているが、実際には、調整データの項目には、属性情報や、曜日や時間帯に応じた金額の調整を行うための指標値等が記憶される。例えば、算出装置１００は、定義テーブル１２６において定義された金額と、調整データとして記憶される指標値とに基づいて、具体的なユーザの収支額を算出する。例えば、算出装置１００は、算出対象であるユーザが、「男性」で「２０歳代」で「東京都」に居住するという属性情報を有する場合、当該属性情報に対応した調整データに基づいて、収支の別を判定したり、金額を算出したりする。

すなわち、図７に示したデータの一例では、定義ＩＤ「Ｋ１１」で識別される定義Ｋ１１は、情報種別「スケジュール」で、行動種別「アルバイト」を定義するデータであることを示している。また、定義Ｋ１１は、当該行動における資産の変動は、収支が「収入」であり、金額が「１０００円／時間」であると定義することを示している。また、定義Ｋ１１は、調整データ「Ｌ１１」に基づいて、所定の調整が行われることを示している。

なお、定義テーブル１２６に定義された情報は、適宜、更新されてもよい。例えば、算出装置１００は、ユーザからの修正結果に基づき、定義されていた金額が時流に合わなくなったと判定する場合には、定義されていた金額や調整データを更新する。具体的には、算出装置１００は、所定の閾値を超える金額の修正を、所定の割合を超えるユーザから受け付けた場合に、定義されていた金額や調整データを更新する。

（学習テーブル１２７について）
続いて、図８に、実施形態に係る学習テーブル１２７の一例を示す。図８は、実施形態に係る学習テーブル１２７の一例を示す図である。学習テーブル１２７は、各ユーザについて収支を算出した履歴や、各ユーザから受け付けた修正に基づいて学習された結果情報等を記憶する。図８に示した例では、学習テーブル１２７は、「ユーザＩＤ」、「学習データＩＤ」、「算出調整」、「履歴情報」といった項目を有する。また、「履歴情報」の項目は、「曜日別」、「月別」といった小項目を有する。

「ユーザＩＤ」は、図５に示した同一の項目に対応する。「学習データＩＤ」は、学習データを識別する識別情報を示す。学習データは、例えば、ユーザごとに生成されるデータであり、例えば、ユーザから受け付けた修正に関する情報が含まれる。

「算出調整」は、学習データに基づいて算出結果の調整を行う内容を示す。例えば、算出装置１００は、過去にユーザから「アルバイト代」についての修正を受け付けた場合、修正された内容と「アルバイト代」という項目とを「算出調整」の項目に記憶する。そして、算出装置１００は、新たにアルバイト代を算出する機会が発生した場合には、学習データを参照して、アルバイト代に関する算出について所定の調整を行う。

「履歴情報」は、ユーザに対して算出処理を行った履歴に関する情報を示す。図８では、履歴情報を「Ｆ０１」や「Ｇ０１」のように概念的に表記しているが、実際には、履歴情報の項目には、ユーザに対して過去に算出処理を行った際の具体的な収支額や、修正結果等が記憶される。例えば、「曜日別」の項目には、特定の曜日における算出処理の結果や、特定の曜日における行動の修正結果等が記憶される。また、「月別」の項目には、特定の月における算出処理の結果や、特定の月における行動の修正結果等が記憶される。かかる情報を参照することで、算出装置１００は、例えば、ユーザが特定の曜日に支出が多いことや、特定の月に収入が多いこと等、ユーザの継続的な収支管理において有用な情報を得ることができる。算出装置１００は、かかる履歴情報に基づいて算出調整を行ってもよい。また、算出装置１００は、かかる履歴情報に基づいてコンテンツの配信処理を行ってもよい。このように、算出装置１００は、学習テーブル１２７に記憶される情報に基づいて、算出処理を各ユーザにパーソナライズできる。

すなわち、図８に示したデータの一例では、ユーザＵ０１に対して、学習データＩＤ「Ｅ０１」で識別される学習データＥ０１が記憶されていることを示している。また、学習データＥ０１は、算出調整を行う項目として「アルバイト代」や「飲み会代」や「デート代」等を設定していることを示している。また、ユーザＵ０１の算出における履歴情報として、曜日別の情報として「Ｆ０１」が記憶され、月別の情報として「Ｇ０１」が記憶されていることを示している。

（コンテンツ記憶部１２９について）
コンテンツ記憶部１２９は、コンテンツに関する情報を記憶する。図９に、実施形態に係るコンテンツ記憶部１２９の一例を示す。図９は、実施形態に係るコンテンツ記憶部１２９の一例を示す図である。図９に示すように、コンテンツ記憶部１２９は、「コンテンツＩＤ」、「ターゲット情報」といった項目を有する。

「コンテンツＩＤ」は、コンテンツを識別する識別情報を示す。「ターゲット情報」は、コンテンツを抽出する際に利用される情報であり、コンテンツを配信するターゲットについて設定された情報である。図９では、ターゲット情報を「Ｔ０１」のように概念的に表記しているが、実際には、ターゲット情報の項目には、ターゲットとなるユーザの属性情報や、収支に関する情報や、配信するタイミング等の種々の情報が記憶される。例えば、算出装置１００は、サービスにおけるユーザの利用状況や、ユーザの収支の動向や、ユーザの属性情報等が、ターゲット情報に設定された情報と一致するユーザに対して、当該ターゲット情報が設定されたコンテンツを優先的に配信する。

すなわち、図９に示したデータの一例では、コンテンツＩＤ「Ｃ０１」で識別されるコンテンツＣ０１には、ターゲット情報「Ｔ０１」が設定されていることを示している。

（制御部１３０について）
図４に戻って説明を続ける。制御部１３０は、例えば、コントローラ（controller）であり、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、算出装置１００内部の記憶装置に記憶されている各種プログラム（算出プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、コントローラであり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

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

（取得部１３１について）
取得部１３１は、各種情報を取得する。例えば、取得部１３１は、ネットワークを介して提供されるサービスにおける、ユーザの利用状況を取得する。具体的には、取得部１３１は、ユーザ端末１０を介して利用するウェブサービスにおける利用状況を取得する。なお、サービスはウェブサービスに限らず、例えば、ユーザ端末１０にインストールされたアプリケーションプログラム（以下、「アプリ」と表記する）を介して利用されるサービスであってもよい。

例えば、取得部１３１は、スケジュール管理に関するサービスの利用において、ユーザが登録したスケジュール情報を取得する。より具体的には、取得部１３１は、ユーザが登録したスケジュール情報におけるユーザの行動種別を取得する。例えば、取得部１３１は、予定されたユーザの行動が、アルバイトや、デートや、飲み会であるといった行動種別を取得する。

また、取得部１３１は、ユーザの位置情報を取得する。具体的には、取得部１３１は、地図サービス（位置情報サービス等）もしくはナビサービスを介して、ユーザの拠点となる位置を示す位置情報から、ユーザが移動したと推定される位置を示す位置情報までの推移を取得する。より具体的には、取得部１３１は、ユーザの自宅や勤務先からユーザが移動を行った場合の位置情報の推移を取得する。この場合、取得部１３１は、例えば、サービスに登録された情報（ユーザの住所情報や職種情報など）に基づいて、ユーザの自宅や勤務先等を特定し、特定された位置の位置情報を取得してもよい。また、取得部１３１は、ユーザが利用した高速道路の入口から出口までの位置情報の推移を取得してもよい。また、取得部１３１は、ユーザが利用したと推定される交通機関における、乗車駅から降車駅までの位置情報の推移を取得してもよい。

さらに、取得部１３１は、位置情報の推移に基づいて、ユーザが訪れた施設に関する情報、及びユーザが当該施設に滞在した滞在時間を取得してもよい。例えば、取得部１３１は、位置情報に基づいて、ユーザが遊園地を訪れたことや、遊園地で滞在した時間等を取得する。

なお、取得部１３１は、ユーザが利用するサービスによっては、より精度の高い位置情報の推移を取得することもできる。例えば、ユーザ端末１０においてカーナビアプリが実行されている場合には、取得部１３１は、カーナビアプリを提供するサービスサーバ３０や、カーナビアプリが実行されているユーザ端末１０から、ユーザの位置情報の推移を取得してもよい。

また、取得部１３１は、サービスにおける利用状況として、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約サービスにおける、ユーザの予約に関する情報を取得してもよい。

また、取得部１３１は、利用状況として、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの検索サービスにおける、ユーザの検索に関する情報を取得してもよい。

また、取得部１３１は、利用状況として、ユーザのショッピングサービスもしくはオークションサービスにおける取引情報を取得してもよい。なお、取得部１３１は、サービスの利用状況とともに、ユーザの属性情報等のユーザに関する情報を取得してもよい。

また、取得部１３１は、ユーザのイベント情報を取得してもよい。具体的には、取得部１３１は、イベント情報として、ユーザもしくはユーザの関係者の記念日に関する情報を取得する。例えば、取得部１３１は、スケジュールサービスにおけるユーザの誕生日の登録情報や、ＳＮＳにおいてつながりのある他ユーザの誕生日の登録情報等に基づいて、ユーザに発生すると想定されるイベント情報を取得する。

取得部１３１は、上記で例示した以外のサービスにおいても、ユーザの利用状況について適宜取得してもよい。取得部１３１は、取得した情報を利用状況記憶部１２１に格納する。

（算出部１３２について）
算出部１３２は、取得部１３１によって取得された利用状況と、当該利用状況から推定されるユーザの資産の変動との関係性に基づいて、ユーザの収支を算出する。

例えば、算出部１３２は、スケジュール情報に基づいてユーザの収支を算出する。具体的には、算出部１３２は、定義テーブル１２６を参照して、ユーザが登録したスケジュール情報におけるユーザの行動種別と、当該行動種別に係る収支や金額が定義された定義データに基づいて、ユーザの収支を算出する。

また、算出部１３２は、ユーザの位置情報に基づいてユーザの収支を算出してもよい。具体的には、算出部１３２は、位置情報の推移に基づいてユーザの収支を算出する。より具体的には、算出部１３２は、ユーザが訪れた施設に関する情報、及びユーザが当該施設に滞在した滞在時間に基づいて、ユーザの収支を算出する。

例えば、算出部１３２は、施設の入場料金や、施設に滞在したユーザの平均の支出額が記憶されたデータベース（例えば、定義テーブル１２６や、外部の情報データベース）を参照する。そして、算出部１３２は、ユーザから取得された位置情報からユーザの行動を推定し、ユーザが施設を利用したこと、ユーザが施設に滞在した時間等を推定する。そして、算出部１３２は、推定された行動に基づいてユーザの収支を算出する。

また、算出部１３２は、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約サービスにおける、ユーザの予約に関する情報に基づいて、ユーザの収支を算出してもよい。例えば、算出部１３２は、ユーザが予約した宿泊施設におけるユーザの利用料金の平均額が記憶されたデータベースを参照し、ユーザが宿泊施設を予約した日におけるユーザの支出額を算出する。

また、算出部１３２は、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの検索サービスにおける、ユーザの検索に関する情報に基づいて、ユーザの収支を算出してもよい。例えば、ユーザが、日程を指定するとともにある宿泊施設までの交通機関を検索していたとすると、当該ユーザは、当該日程において、交通機関を利用して宿泊施設まで移動する蓋然性が高い。この場合、算出部１３２は、ユーザが検索した交通機関を、当該日程においてユーザが利用すると推定して、当該日程における収支額を算出する。

また、算出部１３２は、ユーザのショッピングサービスもしくはオークションサービスにおける取引情報に基づいて、ユーザの収支を算出してもよい。例えば、算出部１３２は、サービスにおける取引額をユーザの収支額として算出する。

また、算出部１３２は、ユーザのイベント情報と資産の変動との関係性に基づいてユーザの収支を算出してもよい。例えば、算出部１３２は、イベント情報と資産の変動とに関する定義データに基づいて、イベントが発生した場合に生ずるユーザの資産の変動（すなわち、収入や支出）を参照する。そして、算出部１３２は、ユーザに発生したイベントに対応する収支額を算出する。

例えば、算出部１３２は、イベント情報として、ユーザもしくは当該ユーザの関係者の記念日に関する情報を取得した場合、かかる記念日に関する情報と、資産の変動との関係性に基づいて、ユーザの収支を算出する。具体的には、算出部１３２は、カレンダーアプリへのスケジュールの登録や、サービスへのＳＮＳへの投稿情報等に基づいて、ユーザの関係者の誕生日というイベントが発生することを参照する。そして、算出部１３２は、誕生日に対応する日付において、ユーザの所定の収支が発生することを算出する。例えば、算出部１３２は、ユーザの友人の誕生日であり、ユーザが２０歳代男性であれば、「１００００円」を支出する、といった定義データに基づいて、ユーザの収支を算出する。なお、イベント情報に対応付けられる収支額は、上記の例に関わらず、イベント情報の種類や、ユーザの属性情報等に基づいて、様々に定義されてよい。

算出部１３２は、上記したような利用状況を適宜組み合わせて算出処理を行ってもよい。例えば、算出部１３２は、対象の日時において、算出処理に用いることのできる利用状況が重複している場合には、重複した利用状況に対応する収支額を合計して、ユーザの収支を算出してもよい。

算出部１３２は、算出した収支額をユーザごとに対応付けて記憶部１２０内に格納する。また、算出部１３２は、算出した収支額を提供部１３３に送る。

（提供部１３３について）
提供部１３３は、算出部１３２によって算出された収支に関する情報をユーザに提供する。例えば、提供部１３３は、図２で示した収支管理アプリのようなプラットフォームを介して、算出された収支に関する情報をユーザに提供する。

（受付部１３４について）
受付部１３４は、提供部１３３によって提供された収支に対して、ユーザから修正要求を受け付ける。例えば、受付部１３４は、図２で示した収支管理アプリのようなプラットフォームを介して、算出された収支に関する修正要求をユーザから受け付ける。

なお、算出部１３２は、受付部１３４によって修正要求が受け付けられた場合に、修正要求に基づいて、ユーザの収支、及び、ユーザの収支を算出するために用いた定義を更新する。なお、算出部１３２は、定義データそのもの（例えば、ユーザ全体に影響を及ぼす定義データ）を修正してもよいし、ユーザごとの学習データを更新して、ユーザへのパーソナライズを行うことができるように定義を更新してもよい。また、算出部１３２は、修正結果について、ユーザ個人のみならず、ユーザと同等の属性情報（性別や年齢等）の他ユーザの算出処理に利用することができるよう、調整データを更新してもよい。

（配信部１３５について）
配信部１３５は、算出部１３２によって算出された収支に基づいて、ユーザにレコメンドするコンテンツを配信する。具体的には、配信部１３５は、ユーザが利用するウェブブラウザに表示される広告枠や、図２で示した収支管理アプリ内の広告枠等に、ユーザにレコメンドするコンテンツを配信する。

例えば、配信部１３５は、コンテンツ記憶部１２９を参照して、ユーザの収支に関する情報や、ユーザの属性情報との照合処理（マッチング）を行う。そして、配信部１３５は、照合処理の結果に基づいて、ユーザに対して配信するコンテンツを選択し、選択したコンテンツを配信する。すなわち、配信部１３５は、ユーザに対して訴求効果が高くなると推定されるコンテンツを当該ユーザに配信する。なお、上記のような照合処理について、配信部１３５は、種々の既知の広告配信手法を利用してもよい。

例えば、配信部１３５は、ユーザの収支に基づいて、ユーザに推奨される広告コンテンツをレコメンドとして配信する。また、配信部１３５は、ユーザの収支に基づいて、ユーザに推奨される金融商品等の情報をレコメンドとして配信してもよい。

なお、配信部１３５は、ユーザへのコンテンツ配信にあたり、収支情報に対するユーザの関心度合いを参照してもよい。収支情報に対するユーザの関心度合いは、例えば、ユーザが収支管理アプリを起動する頻度や、利用する頻度や、算出装置１００から提供された収支情報を修正する頻度等に基づいて算出される。例えば、収支情報に対する関心度合いが高いユーザほど、資産運用等の金融商品に関するコンテンツに対して関心を抱く可能性が高いと想定される。そこで、配信部１３５は、ユーザの収支情報に対する関心度合いを参照し、例えば、相対的に関心度合いの高いユーザに対して優先的に金融商品に関するコンテンツを配信するなどの調整を行ってもよい。

〔４．ユーザ端末の構成〕
次に、図１０を用いて、実施形態に係るユーザ端末１０の構成について説明する。図１０は、実施形態に係るユーザ端末１０の構成例を示す図である。図１０に示すように、ユーザ端末１０は、通信部１１と、入力部１２と、表示部１３と、検知部１４と、記憶部１５と、制御部１６とを有する。なお、ユーザ端末１０が有する各処理部の接続関係は、図１０に示した接続関係に限られず、他の接続関係であってもよい。

通信部１１は、ネットワークＮと有線又は無線で接続され、サービスサーバ３０や算出装置１００との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ等によって実現される。

入力部１２は、ユーザから各種操作を受け付ける入力装置である。例えば、入力部１２は、ユーザ端末１０に備えられた操作キー等によって実現される。また、入力部１２には、画像を撮影するための撮像装置（カメラ等）や、音声を集音する集音機器（マイク等）が含まれてもよい。

表示部１３は、各種情報を表示するための表示装置である。例えば、表示部１３は、液晶ディスプレイ等によって実現される。なお、ユーザ端末１０にタッチパネルが採用される場合には、入力部１２の一部と表示部１３とは一体化される。

検知部１４は、ユーザ端末１０に対する各種操作や、ユーザ端末１０の周囲の環境情報等を検知する。例えば、検知部１４は、各種情報を検知するセンサやアンテナにより実現される。具体的には、検知部１４は、ユーザ端末１０と接続されている機器に関する通信状況や、ユーザ端末１０の周囲の照度や騒音、ユーザ端末１０の物理的な動き、ユーザ端末１０の位置情報等を検知する。

例えば、検知部１４は、入力部１２に入力された情報に基づいて、ユーザの操作を検知する。すなわち、検知部１４は、入力部１２に画面をタッチする操作の入力があったことや、音声の入力があったこと等を検知する。また、検知部１４は、ユーザによって所定のアプリが起動されたことを検知してもよい。かかるアプリがユーザ端末１０内の撮像機能（例えば、カメラ）を動作させるアプリである場合、検知部１４は、ユーザによって撮像機能が利用されていることを検知する。また、検知部１４は、ユーザ端末１０内に備えられた加速度センサやジャイロセンサ等で検知されたデータに基づき、ユーザ端末１０自体が動かされているといった操作を検知してもよい。

また、検知部１４は、ユーザ端末１０の現在位置を検知する。具体的には、検知部１４は、ＧＰＳ（Global Positioning System）衛星から送出される電波を受信し、受信した電波に基づいてユーザ端末１０の現在位置を示す位置情報（例えば、緯度及び経度）を取得する。

なお、検知部１４は、ＧＰＳ以外の種々の手法により位置情報を取得してもよい。例えば、ユーザ端末１０が駅改札や商店等で使用される非接触型ＩＣカードと同等の機能を備えている場合（もしくは、ユーザ端末１０が非接触型ＩＣカードの履歴を読み取る機能を備えている場合）、ユーザ端末１０によって駅での乗車料金の決済等が行われた情報とともに、使用された位置が記録される。検知部１４は、かかる情報を検知し、位置情報として取得する。また、検知部１４は、ユーザ端末１０が特定のアクセスポイントと通信を行う際には、アクセスポイントから取得可能な位置情報を検知してもよい。また、位置情報は、ユーザ端末１０が備える光学式センサや、赤外線センサや、磁気センサ等によって取得されてもよい。

また、検知部１４は、ユーザ端末１０に接続される外部装置を検知する。例えば、検知部１４は、外部装置との相互の通信パケットのやり取りや、外部装置が発する信号等に基づいて、外部装置を検知する。具体的には、検知部１４は、外部装置が利用しているＷｉｆｉ（登録商標）やＢｌｕｅｔｏｏｔｈ（登録商標）等の電波を検知する。また、検知部１４は、外部装置と通信が確立する場合に、外部装置との接続の種類を検知してもよい。例えば、検知部１４は、外部装置と有線で接続されているか、無線通信で接続されているかを検知する。また、検知部１４は、無線通信で用いられている通信方式等を検知してもよい。また、検知部１４は、外部装置が発する電波を検知する電波センサや、電磁波を検知する電磁波センサ等によって取得される情報に基づいて、外部装置を検知してもよい。外部装置の一例は、ユーザ端末１０を利用するユーザが利用する他のデバイス（他のユーザ端末１０）であり、例えば、ウェアラブルデバイスや、設置型のＩｏＴ（Internet of Things）機器等である。

また、検知部１４は、ユーザ端末１０における環境を検知する。検知部１４は、ユーザ端末１０に備えられた各種センサや機能を利用し、環境に関する情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲の音を収集するマイクロフォンや、ユーザ端末１０の周囲の照度を検知する照度センサや、ユーザ端末１０の物理的な動きを検知する加速度センサ（又は、ジャイロセンサなど）や、ユーザ端末１０の周囲の湿度を検知する湿度センサや、ユーザ端末１０の所在位置における磁場を検知する地磁気センサ等を利用する。そして、検知部１４は、各種センサを用いて、種々の情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲における騒音レベルや、ユーザ端末１０の周囲がユーザの虹彩を撮像に適する照度であるか等を検知する。さらに、検知部１４は、カメラで撮影された写真や映像に基づいて周囲の環境情報を検知してもよい。

また、ユーザ端末１０は、検知部１４によって検知された情報に基づいて、ユーザ端末１０のコンテキストを示すコンテキスト情報を取得するようにしてもよい。上述のように、ユーザ端末１０は、内蔵された各種センサ（検知部１４）により、位置、加速度、温度、重力、回転（角速度）、照度、地磁気、圧力、近接、湿度、回転ベクトルといった、種々の物理量をコンテキスト情報として取得する。また、ユーザ端末１０は、内蔵する通信機能を利用して、各種装置との接続状況（例えば、通信の確立に関する情報や、利用している通信規格）などを、コンテキスト情報として取得してもよい。

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

サービス情報記憶部１５１は、例えば、ユーザが利用したサービスに関する情報を記憶する。具体的には、サービス情報記憶部１５１は、ユーザが利用したサービスにおける行動履歴（ログ）を記憶する。例えば、サービス情報記憶部１５１は、ユーザ端末１０内にインストールされたアプリの使用履歴を記憶する。なお、ユーザ端末１０は、例えば算出装置１００の指示に従い、一定時間ごとに、サービス情報記憶部１５１に記憶された情報を算出装置１００にアップロードするようにしてもよい。

制御部１６は、コントローラであり、例えば、ＣＰＵやＭＰＵ等によって、ユーザ端末１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１６は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

制御部１６は、ユーザ端末１０において行われる各種処理を制御する。図１０に示すように、制御部１６は、受信部１６１と、取得部１６２と、送信部１６３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。

受信部１６１は、各種情報を受信する。例えば、受信部１６１は、サービスサーバ３０や算出装置１００から送信される情報を受信する。また、受信部１６１は、検知部１４が検知する各種情報を受信する。

取得部１６２は、各種情報やデータを取得する。例えば、取得部１６２は、サービスサーバ３０にアクセスすることで、ユーザが閲覧を所望するサービスページ（例えばウェブページ）を取得する。また、取得部１６２は、アプリのダウンロードサイト等を介して、サービスの利用に用いるためのアプリに関する情報を取得する。

送信部１６３は、各種情報を送信する。例えば、送信部１６３は、検知部１４によって検知されたユーザ端末１０の利用状況に関する情報を、サービスサーバ３０や算出装置１００に送信する。また、送信部１６３は、記憶部１５等を参照し、ユーザ端末１０に蓄積されたサービスの利用状況に関する情報を算出装置１００に送信する。

〔５．処理手順〕
次に、図１１、図１２及び図１３を用いて、実施形態に係る算出装置１００による処理の手順について説明する。まず、図１１を用いて、収支の算出処理手順を説明する。図１１は、実施形態に係る処理手順を示すフローチャート（１）である。

図１１に示すように、算出装置１００は、サービスにおける利用状況を取得する（ステップＳ１０１）。そして、算出装置１００は、利用状況と、利用状況から推定されるユーザの資産の変動との関係性を参照する（ステップＳ１０２）。具体的には、算出装置１００は、定義テーブル１２６等を参照して、利用状況とユーザの資産の変動との関係性を取得する。

続けて、算出装置１００は、参照した情報に基づいて、利用状況に対応する収支を算出する（ステップＳ１０３）。そして、算出装置１００は、算出した収支額をユーザの収支情報に反映させる（ステップＳ１０４）。

次に、図１２を用いて、収支の修正に係る処理手順を説明する。図１２は、実施形態に係る処理手順を示すフローチャート（２）である。

算出装置１００は、ユーザに収支情報を提供する（ステップＳ２０１）。そして、算出装置１００は、収支の修正を受け付けたか否かを判定する（ステップＳ２０２）。修正を受け付けていない場合（ステップＳ２０２；Ｎｏ）、算出装置１００は、修正を受け付けるまで待機する。

一方、修正を受け付けた場合（ステップＳ２０２；Ｙｅｓ）、算出装置１００は、収支情報に修正を反映させる（ステップＳ２０３）。そして、算出装置１００は、修正を反映させた収支情報をユーザに提供する（ステップＳ２０４）。このとき、算出装置１００は、修正に基づく学習データを格納する（ステップＳ２０５）。なお、図２で示したように、算出装置１００は、ステップＳ２０４で修正を反映させた収支情報をユーザに提供した後に、さらにユーザからの修正を受け付けてもよい。

次に、図１３を用いて、コンテンツの配信処理手順を説明する。図１３は、実施形態に係る処理手順を示すフローチャート（３）である。

まず、算出装置１００は、コンテンツ配信の契機を得たか否かを判定する（ステップＳ３０１）。コンテンツ配信の契機とは、例えば、ユーザ端末１０においてコンテンツを表示する枠（広告枠等）が表示されることにより、コンテンツ配信の要求がユーザ端末１０から送信されること等をいう。コンテンツ配信の契機を得ていない場合（ステップＳ３０１；Ｎｏ）、算出装置１００は、コンテンツ配信の契機を得るまで待機する。

一方、コンテンツ配信の契機を得た場合（ステップＳ３０１；Ｙｅｓ）、算出装置１００は、ユーザの収支情報を参照する（ステップＳ３０２）。また、算出装置１００は、ユーザの属性情報を参照する（ステップＳ３０３）。また、算出装置１００は、収支情報に対するユーザの関心度合いを参照する（ステップＳ３０４）。

そして、算出装置１００は、コンテンツに設定されたターゲット情報と、ユーザの情報（例えば、ステップＳ３０２からステップＳ３０４において参照した情報）とを照合する（ステップＳ３０５）。

ここで、算出装置１００は、ユーザに配信するコンテンツとして、適するコンテンツが抽出されたか否かを判定する（ステップＳ３０６）。言い換えれば、算出装置１００は、ユーザにマッチングするようなコンテンツがコンテンツ記憶部１２９に保持されていたか否かを判定する。

コンテンツが抽出された場合（ステップＳ３０６；Ｙｅｓ）、算出装置１００は、抽出されたコンテンツをユーザに配信する（ステップＳ３０７）。

一方、ユーザにマッチングするコンテンツが抽出されない場合（ステップＳ３０６；Ｎｏ）、算出装置１００は、代替となるコンテンツが存在するか否かを判定する（ステップＳ３０８）。代替となるコンテンツとは、例えば、配信するターゲットが特に指定されていないような広告コンテンツ等である。

代替となるコンテンツが存在する場合（ステップＳ３０８；Ｙｅｓ）、算出装置１００は、代替となるコンテンツをユーザに配信する（ステップＳ３０９）。一方、代替となるコンテンツが存在しない場合（ステップＳ３０８；Ｎｏ）、算出装置１００は、コンテンツを配信せず、再びコンテンツの配信機会を得るまで待機する。なお、この場合、ユーザ端末１０に表示される広告枠は、例えば、算出装置１００以外の広告配信サーバから配信された広告コンテンツを表示したり、ブランク表示となったりする。

〔６．変形例〕
上述した算出装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、算出装置１００の他の実施形態について説明する。

〔６－１．他のユーザの情報の利用〕
上記実施形態では、算出装置１００がユーザから修正を受け付けることにより、各ユーザに関する学習を行い、算出処理をパーソナライズする例を説明した。ここで、算出装置１００は、個別のユーザから得た情報を当該ユーザの算出処理に反映するのみならず、他のユーザから得た情報を当該ユーザの算出処理に反映させてもよい。

例えば、算出装置１００は、サービスの利用状況として、ユーザの属性情報を取得する。そして、算出装置１００は、ユーザの属性情報に類似する属性情報を有する他のユーザの利用状況と、当該他のユーザの利用状況から推定される資産の変動との関係性に基づいて、ユーザの収支を算出してもよい。

例えば、算出装置１００は、図５で示したユーザＵ０１と同様に、２０歳代の男性で東京都在住の複数の他のユーザから、アルバイトに関する収支情報の修正を受け付けたものとする。そして、算出装置１００は、所定の閾値を超えるサンプル数が蓄積された場合に、受け付けた修正を定義データや、ユーザＵ０１の学習データに反映させる。具体的には、算出装置１００は、ユーザＵ０１が修正を行わずとも、比較的多数の他のユーザがアルバイト代を「１１００円／時間」であると修正している場合には、２０歳代の男性で東京都在住という属性情報を有するユーザＵ０１のアルバイト代も「１１００円／時間」であると推定する学習を行う。

このように、算出装置１００は、他のユーザから得た情報に基づいて、個々のユーザの収支を算出する処理を行ってもよい。これにより、算出装置１００は、個々のユーザから修正を受け付けずとも、他のユーザの情報による学習が進むにつれ、利用状況から収支を適切に算出することができるようになる。

〔６－２．サービスの特典に基づく算出〕
算出装置１００は、サービスの利用状況として、サービスの利用においてユーザが獲得した特典に関する情報を取得してもよい。この場合、算出装置１００は、特典と資産の変動との関係性に基づいてユーザの収支を算出する。

例えば、ユーザは、サービスの利用において、サービス側が提供するポイントサービス等の特典を獲得する場合がある。一般に、サービス側が提供するポイントサービスでは、ユーザが購入した商品の代金や、ユーザがサービスの対価として支払いを行った額に応じて、ユーザにポイントが付与される。このため、算出装置１００は、ユーザが獲得したポイントの情報を得た場合には、ポイント数に基づいて、ユーザの収支額を算出してもよい。

なお、算出装置１００は、ポイントに限らず、様々な特典に関する情報を取得してもよい。例えば、所定のウェブサイトにおいて、ユーザが１００００円以上の商品を購入した場合に、所定のアプリが使用可能になるような特典を提供しているものとする。そして、算出装置１００が、ある日時から、かかる所定のアプリをユーザが使用しているという利用状況をユーザ端末１０から取得したものとする。この場合、算出装置１００は、当該所定のアプリの使用が開始された日に、少なくともユーザに「１００００円」の支出が発生したと推定して、収支情報を算出してもよい。なお、算出装置１００は、算出処理の後にユーザから修正を受け付けた場合には、算出した収支情報に対して修正を反映させる。

〔６－３．種々の利用状況〕
算出装置１００は、上述した実施形態において例示した利用状況以外に、種々の利用状況を取得してもよい。

例えば、算出装置１００は、サービスにおける利用状況として、ユーザのＳＮＳへの書き込みや、ＳＮＳへの投稿情報を取得してもよい。そして、算出装置１００は、例えば、ＳＮＳへの書き込みや投稿情報から、ユーザのイベント情報の発生や具体的な収支情報を取得してもよい。

また、算出装置１００は、テキスト解析等を用いて、ＳＮＳへの書き込み等からスケジュール情報を取得してもよい。例えば、ＳＮＳの書き込みには、「２０日にＡＡＡ県に行っています」や、「１５日にはＢＢＢ県に行っていました」といったテキストが含まれる場合がある。算出装置１００は、形態素解析等を用いて、これらのテキストをスケジュール情報に変換し、これらのテキストに基づいてスケジュール情報を取得してもよい。さらに、算出装置１００は、解析して取得したスケジュール情報に基づいて、ユーザの収支を算出してもよい。具体的には、算出装置１００は、ＳＮＳに書き込みされた日程において、ユーザの自宅から推定される目的地までの交通費等をユーザの支出として算出してもよい。

また、算出装置１００は、サービスにおける利用状況として、天気情報サービスにおける検索履歴等を取得してもよい。例えば、ユーザが、ある日程について、自宅から離れた地域の天気について検索を行った場合、当該日程において、ユーザがその地域を訪れる可能性がある。この場合、算出装置１００は、当該日程において、ユーザの自宅から推定される目的地までの交通費等をユーザの支出として算出してもよい。

〔６－４．ユーザ端末〕
上記実施形態では、図１０を用いてユーザ端末１０の構成例を示したが、ユーザ端末１０は、図１０で示した構成を必ずしも全て有していなくてもよい。上述のように、ユーザ端末１０には、スマートフォンやタブレット端末のようなスマートデバイスのみならず、通信機能を有する眼鏡型端末や、あるいは、ユーザの心拍を記憶する心拍測定器など、種々のウェアラブルデバイスが含まれる。この場合、ユーザ端末１０は、必ずしもユーザの操作等の入力を受け付ける入力部１２を有さずとも、自動的にユーザのサービスにおける利用状況を取得し、取得した情報を通信ネットワークに送信する機能等を有する。すなわち、ユーザ端末１０は、いわゆるＩｏＴを実現するような、所定の通信機能を有するデバイスであれば、必ずしも図１０で示した構成を有していなくてもよい。

〔６－５．算出プログラム〕
上記実施形態では、算出装置１００が、利用状況と資産の変動との関係性に基づいてユーザの収支を算出する算出処理を行う例を示した。しかし、実施形態に係る算出処理は、算出装置１００のみならず、ユーザ端末１０によって行われてもよい。すなわち、実施形態に係る算出処理は、ユーザ端末１０上において本願に係る算出プログラムが実行されることによって実現されてもよい。

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

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

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（図３に示したネットワークＮに対応）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５００を介して他の機器へ送信する。

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

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

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

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

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図４に示した取得部１３１と、受付部１３４とは統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、ネットワークＮを介して、外部に備えられた所定の記憶装置に記憶されてもよい。

また、上記実施形態では、算出装置１００が、例えば、利用状況を取得する取得処理と、収支を算出する算出処理と、修正を受け付ける受付処理とを行う例を示した。しかし、上述した算出装置１００は、取得処理を行う取得装置と、算出処理を行う算出装置と、受付処理を行う受付装置とに分離されてもよい。この場合、取得装置は、少なくとも取得部１３１を有する。算出装置は、少なくとも算出部１３２を有する。受付装置は、少なくとも受付部１３４を有する。そして、上記の算出装置１００による処理は、取得装置と、算出装置と、受付装置との各装置を有する算出処理システム１によって実現される。

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

〔９．効果〕
上述してきたように、実施形態に係る算出装置１００は、取得部１３１と、算出部１３２とを有する。取得部１３１は、ネットワークを介して提供されるサービスにおける、ユーザの利用状況を取得する。算出部１３２は、取得部１３１によって取得された利用状況と、当該利用状況から推定されるユーザの資産の変動との関係性に基づいて、当該ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ユーザが意識的に収支の額等の入力を行わずとも、ユーザの日常的な行動に基づいて、ユーザの収支管理を行うことができる。これにより、算出装置１００は、収支管理に関するユーザの負担を下げることができるため、資産管理に関する敷居を下げることができる。

また、取得部１３１は、スケジュール管理に関するサービスの利用において、ユーザが登録したスケジュール情報を取得する。算出部１３２は、スケジュール情報に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ユーザのスケジュール情報に基づいて処理を行うため、ユーザが予定するスケジュールにおいて発生すると予測される収支を精度よく算出することができる。

また、取得部１３１は、ユーザが登録したスケジュール情報における当該ユーザの行動種別を取得する。算出部１３２は、ユーザの行動種別に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ユーザの行動ごとに収支を算出する。このため、算出装置１００は、スケジュールにおいて発生すると予測される収支をより詳細に算出することができる。

また、取得部１３１は、ユーザの位置情報を取得する。算出部１３２は、取得部１３１によって取得される位置情報の推移に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ユーザの位置情報の推移に基づいて処理を行うため、日常的な移動など、ユーザが特に意識することなく行う行動からも収支を算出することができる。

また、取得部１３１は、地図サービスもしくはナビサービスを介して、ユーザの拠点となる位置を示す位置情報から、当該ユーザが移動したと推定される位置を示す位置情報までの推移を取得する。算出部１３２は、位置情報の推移に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、サービスで取得される位置情報の推移に基づいて処理を行うことで、ユーザの行動等をより正確に捕捉することができるため、ユーザの収支を精度よく算出することができる。

また、取得部１３１は、位置情報の推移に基づいて、ユーザが訪れた施設に関する情報、及びユーザが当該施設に滞在した滞在時間を取得する。算出部１３２は、施設に関する情報及び滞在時間に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、施設の利用や滞在においてユーザが支払うと想定される費用等に基づいて、算出処理を行ってもよい。これにより、算出装置１００は、収支の算出の精度を向上させることができる。

また、取得部１３１は、利用状況として、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約サービスにおける、ユーザの予約に関する情報を取得する。算出部１３２は、ユーザの予約に関する情報に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ユーザが予約を行ったという利用状況に基づいてユーザの収支を算出する。すなわち、算出装置１００は、ユーザが予約サービスを利用したという状況だけで自動的にユーザの収支管理を行うため、ユーザの手間を減らすことができ、結果として、収支管理に関するユーザビリティを向上させることができる。

また、取得部１３１は、利用状況として、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの検索サービスにおける、ユーザの検索に関する情報を取得する。算出部１３２は、ユーザの検索に関する情報に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ユーザが検索を行ったという利用状況に基づいてユーザの収支を算出する。かかる構成によっても、算出装置１００は、収支管理に関するユーザビリティを向上させることができる。

また、取得部１３１は、利用状況として、ユーザのショッピングサービスもしくはオークションサービスにおける取引情報を取得する。算出部１３２は、ユーザの取引情報に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、直接収支に関係するような行動をユーザが行った場合には、その取引情報に基づいて収支を算出する。これにより、算出装置１００は、ユーザに手間を掛けさせず、かつ、収支の算出を正確に行うことができる。

また、取得部１３１は、ユーザの属性情報を取得する。算出部１３２は、ユーザの属性情報に類似する属性情報を有する他のユーザの利用状況と、当該他のユーザの利用状況から推定される資産の変動との関係性に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ユーザと類似する他のユーザにおける利用状況に基づいて、ユーザの収支を算出してもよい。これにより、算出装置１００は、ユーザが属する属性の平均的な収支に関する情報等を反映した処理を行うことができるので、算出する収支の額の正解率を向上させることができる。

また、取得部１３１は、ユーザのイベント情報を取得する。算出部１３２は、ユーザのイベント情報と資産の変動との関係性に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、イベント情報ごとに収支を算出してもよい。これにより、算出装置１００は、ユーザが特に意識せずとも、ユーザの日常的に発生しうるイベントを加味した収支管理を行うことができる。

また、取得部１３１は、イベント情報として、ユーザもしくは当該ユーザの関係者の記念日に関する情報を取得する。算出部１３２は、記念日に関する情報と資産の変動との関係性に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、誕生日等の記念日において発生する収支等を反映させた処理を行うことができる。このため、算出装置１００は、収支算出の精度を向上させることができる。

また、取得部１３１は、サービスの利用においてユーザが獲得した特典に関する情報を取得する。算出部１３２は、特典と資産の変動との関係性に基づいて、ユーザの収支を算出する。

このように、実施形態に係る算出装置１００は、ポイントサービス等の特典をユーザが得たことから逆算して、ユーザの収支を算出してもよい。このように、算出装置１００は、ユーザに関係する種々の情報に基づいて収支を推定するため、単なるサービスの利用状況のみならず、様々な観点からユーザの収支を算出することができる。

また、実施形態に係る算出装置１００は、算出部１３２によって算出された収支に関する情報をユーザに提供する提供部１３３と、提供部１３３によって提供された収支に対して、ユーザから修正要求を受け付ける受付部１３４と、をさらに備える。算出部１３２は、受付部１３４によって修正要求が受け付けられた場合に、当該修正要求に基づいて、ユーザの収支、及び、ユーザの収支を算出するために用いた定義を更新する。

このように、実施形態に係る算出装置１００は、ユーザから修正を受け付け、修正された情報を反映させた算出処理を行う。このため、算出装置１００は、ユーザごとにパーソナライズされた算出結果を提供することができる。

また、実施形態に係る算出装置１００は、算出部１３２によって算出された収支に基づいて、ユーザにレコメンドするコンテンツを配信する。

このように、実施形態に係る算出装置１００は、収支情報に基づいてコンテンツを配信することで、単に属性情報のみをターゲット情報とする場合と比較して、よりユーザが興味関心のあると推定されるコンテンツを配信することができる。

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

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

１ 算出処理システム
１０ ユーザ端末
３０ サービスサーバ
１００ 算出装置
１１０ 通信部
１２０ 記憶部
１２１ 利用状況記憶部
１２２ 属性テーブル
１２３ 利用状況テーブル
１２５ 算出情報記憶部
１２６ 定義テーブル
１２７ 学習テーブル
１２９ コンテンツ記憶部
１３０ 制御部
１３１ 取得部
１３２ 算出部
１３３ 提供部
１３４ 受付部
１３５ 配信部

Claims (16)

1. ネットワークを介して提供されるサービスにおけるユーザの利用状況を取得する取得部と、
   前記利用状況と当該利用状況から推定されるユーザの資産の変動との関係性を定義した定義データと、前記取得部によって取得された利用状況とに基づいて、当該ユーザの収支を推定する算出部と、
   を備え、
   前記取得部は、
   スケジュール管理に関するサービスの利用において、前記ユーザが登録したスケジュール情報を取得し、
   前記算出部は、
   前記スケジュール情報に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする算出装置。
2. 前記取得部は、
   前記ユーザが登録したスケジュール情報における当該ユーザの行動種別を取得し、
   前記算出部は、
   前記ユーザの行動種別に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする請求項１に記載の算出装置。
3. 前記取得部は、
   さらに、前記ユーザの位置情報を取得し、
   前記算出部は、
   前記取得部によって取得される位置情報の推移に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする請求項１又は２に記載の算出装置。
4. 前記取得部は、
   地図サービスもしくはナビサービスを介して、前記ユーザの拠点となる位置を示す位置情報から、当該ユーザが移動したと推定される位置を示す位置情報までの推移を取得し、
   前記算出部は、
   前記位置情報の推移に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする請求項３に記載の算出装置。
5. 前記取得部は、
   前記位置情報の推移に基づいて、前記ユーザが訪れた施設に関する情報、及び前記ユーザが当該施設に滞在した滞在時間を取得し、
   前記算出部は、
   前記施設に関する情報及び前記滞在時間に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする請求項４に記載の算出装置。
6. 前記取得部は、
   前記利用状況として、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約サービスにおける、前記ユーザの予約に関する情報を取得し、
   前記算出部は、
   前記ユーザの予約に関する情報に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする請求項１～５のいずれか一つに記載の算出装置。
7. 前記取得部は、
   前記利用状況として、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの検索サービスにおける、前記ユーザの検索に関する情報を取得し、
   前記算出部は、
   前記ユーザの検索に関する情報に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする請求項１～６のいずれか一つに記載の算出装置。
8. 前記取得部は、
   前記利用状況として、前記ユーザのショッピングサービスもしくはオークションサービスにおける取引情報を取得し、
   前記算出部は、
   前記ユーザの取引情報に基づいて、前記ユーザの収支を推定する、
   ことを特徴とする請求項１～７のいずれか一つに記載の算出装置。
9. 前記取得部は、
   前記ユーザの属性情報を取得し、
   前記算出部は、
   前記ユーザの属性情報に類似する属性情報を有する他のユーザにおける前記利用状況と、当該他のユーザの利用状況から推定される資産の変動との関係性に基づいて、当該ユーザの収支を推定する、
   ことを特徴とする請求項１～８のいずれか一つに記載の算出装置。
10. 前記取得部は、
    前記ユーザのイベント情報を取得し、
    前記算出部は、
    前記ユーザのイベント情報と資産の変動との関係性に基づいて、前記ユーザの収支を推定する、
    ことを特徴とする請求項１～９のいずれか一つに記載の算出装置。
11. 前記取得部は、
    前記イベント情報として、前記ユーザもしくは当該ユーザの関係者の記念日に関する情報を取得し、
    前記算出部は、
    前記記念日に関する情報と資産の変動との関係性に基づいて、前記ユーザの収支を推定する、
    ことを特徴とする請求項１０に記載の算出装置。
12. 前記取得部は、
    前記サービスの利用において前記ユーザが獲得した特典に関する情報を取得し、
    前記算出部は、
    前記特典と資産の変動との関係性に基づいて、前記ユーザの収支を推定する、
    ことを特徴とする請求項１～１１のいずれか一つに記載の算出装置。
13. 前記算出部によって算出された収支に関する情報を前記ユーザに提供する提供部と、
    前記提供部によって提供された収支に対して、前記ユーザから修正要求を受け付ける受付部と、
    をさらに備え、
    前記算出部は、
    前記受付部によって修正要求が受け付けられた場合に、当該修正要求に基づいて、前記ユーザの収支、及び、前記ユーザの収支を推定するために用いた定義を更新する、
    ことを特徴とする請求項１～１２のいずれか一つに記載の算出装置。
14. 前記算出部によって算出された収支に基づいて、前記ユーザにレコメンドするコンテンツを配信する配信部、
    をさらに備えることを特徴とする請求項１～１３のいずれか一つに記載の算出装置。
15. コンピュータが実行する算出方法であって、
    ネットワークを介して提供されるサービスにおけるユーザの利用状況を取得する取得工程と、
    前記利用状況と当該利用状況から推定されるユーザの資産の変動との関係性を定義した定義データと、前記取得工程によって取得された利用状況とに基づいて、当該ユーザの収支を推定する算出工程と、
    を含み、
    前記取得工程では、
    スケジュール管理に関するサービスの利用において、前記ユーザが登録したスケジュール情報を取得し、
    前記算出工程では、
    前記スケジュール情報に基づいて、前記ユーザの収支を推定する、
    ことを特徴とする算出方法。
16. ネットワークを介して提供されるサービスにおけるユーザの利用状況を取得する取得手順と、
    前記利用状況と当該利用状況から推定されるユーザの資産の変動との関係性を定義した定義データと、前記取得手順によって取得された利用状況とに基づいて、当該ユーザの収支を推定する算出手順と、
    をコンピュータに実行させ、
    前記取得手順では、
    スケジュール管理に関するサービスの利用において、前記ユーザが登録したスケジュール情報を取得し、
    前記算出手順では、
    前記スケジュール情報に基づいて、前記ユーザの収支を推定する、
    ことを特徴とする算出プログラム。

Images