JP2017037571A - 情報処理システム、情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】ユーザの潜在資産を推定することが可能な、新規かつ改良された情報処理システム、情報処理装置、情報処理方法、及びプログラムを提供する。【解決手段】分析サーバ５０は、通信部５１と、制御部５２（利用履歴情報取得部）と、要否判定部５３と、潜在資産算出部５４と、セールス情報取得部５５とを備える。利用履歴情報取得部は、ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得する。要否判定部５３は、利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定する。潜在資産算出部５４は、要否判定部５３による判定結果に基づいて、ユーザの潜在資産を算出する。【選択図】図６

Description

本発明は、情報処理システム、情報処理装置、情報処理方法、及びプログラムに関する。

特許文献１〜４には、ユーザの消費活動に基づいて、各種の処理を行う技術を開示する。例えば、特許文献１に開示された技術では、ユーザの商品購入履歴及び現在位置に基づいて、ユーザの購買意欲を喚起させる可能性のある商品を選択し、その商品をユーザに通知する。特許文献２に開示された技術では、ユーザの投資パターンに基づいて、投資商品を選択し、その投資商品をユーザに提案する。特許文献３に開示された技術では、ユーザの商品毎の購入回数等に基づいて、広告情報を選択し、ユーザに提示する。特許文献４に開示された技術では、ユーザの購入履歴に基づいてユーザの嗜好を判断し、ユーザの嗜好に応じた広告情報をユーザに提示する。

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

しかし、特許文献１〜４に開示された技術では、ユーザの潜在資産に何ら着目していなかった。ここで、潜在資産とは、何らかの用途で使用された資産のうち、他の用途にも使用可能な資産である。例えば、家賃や光熱費として消費された資産は潜在資産となりえない可能性が高いが、趣味として消費された資産は潜在資産となる可能性が高い。このような潜在資産は、様々な用途への応用が期待できる。例えば、潜在資産に応じたセールス情報の提供を行うことが期待できる。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、ユーザの潜在資産を推定することが可能な、新規かつ改良された情報処理システム、情報処理装置、情報処理方法、及びプログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得する利用履歴情報取得部と、利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定する要否判定部と、要否判定部による判定結果に基づいて、ユーザの潜在資産を算出する潜在資産算出部と、を備えることを特徴とする、情報処理システムが提供される。

ここで、要否判定部は、利用履歴がユーザの日常生活に必要な消費活動を示すか否かを判定し、利用履歴がユーザの日常生活に必要な消費活動を示す場合には、利用履歴がユーザにとって必要な消費活動を示すと判定してもよい。

また、要否判定部は、ユーザに関するユーザ情報に基づいて、利用履歴がユーザにとって必要な消費活動であったか否かを判定してもよい。

また、ユーザ情報には、ユーザの家族構成が含まれ、要否判定部は、ユーザの家族構成に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定してもよい。

また、ユーザ情報には、ユーザの趣味が含まれ、要否判定部は、ユーザの趣味に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定してもよい。

また、ユーザ情報には、ユーザの収入が含まれ、要否判定部は、ユーザの収入に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定してもよい。

また、要否判定部は、利用履歴を、全てのユーザにとって必要な消費活動を示す第１の利用履歴と、ユーザごとに要否が異なる消費活動を示す第２の利用履歴とに区分し、ユーザ情報に基づいて、第２の利用履歴がユーザにとって必要な消費活動であったか否かを判定してもよい。

また、要否判定部は、ユーザにとって不要な消費活動を示す利用履歴を不要履歴に区分し、潜在資産算出部は、不要履歴が示す利用額に基づいて、潜在資産を算出してもよい。

また、潜在資産算出部は、不要履歴が示す利用額に第１の係数を乗じることで不要履歴が示す利用額を補正し、補正後の利用額に基づいて、潜在資産を算出してもよい。

また、要否判定部は、ユーザにとって必要な消費活動を示す利用履歴を必要履歴に区分し、潜在資産算出部は、必要履歴が示す利用額に第２の係数を乗じることで必要履歴が示す利用額を補正し、補正後の利用額に基づいて、潜在資産を算出してもよい。

また、潜在資産に基づいて、セールス情報を取得するセールス情報取得部と、セールス情報を提示する制御を行う提示制御部と、を備えてもよい。

また、セールス情報は、金融商品を示す金融商品情報であってもよい。

また、金融商品に対応可能な行員をユーザに通知するユーザ通知部を備えてもよい。

また、提示制御部は、金融商品に対応可能な行員に金融商品情報を提示する制御を行ってもよい。

本発明の他の観点によれば、ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得する利用履歴情報取得部と、利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定する要否判定部と、要否判定部による判定結果に基づいて、ユーザの潜在資産を算出する潜在資産算出部と、を備えることを特徴とする、情報処理装置が提供される。

本発明の他の観点によれば、ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得するステップと、利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定するステップと、判定の結果に基づいて、ユーザの潜在資産を算出するステップと、を備えることを特徴とする、情報処理方法が提供される。

本発明の他の観点によれば、コンピュータに、ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得する利用履歴情報取得機能と、利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定する要否判定機能と、要否判定機能による判定結果に基づいて、ユーザの潜在資産を算出する潜在資産算出機能と、を実現させることを特徴とする、プログラムが提供される。

本発明の上記観点によれば、ユーザのクレジットカードの利用履歴がユーザにとって必要な消費活動を示すか否かを判定し、その結果に基づいて、ユーザの潜在資産を算出することができる。

以上説明したように本発明によれば、ユーザの潜在資産を推定することができる。

本発明の実施形態に係る情報処理システムの全体構成を示すブロック図である。 受付端末の構成を示すブロック図である。 ユーザ情報管理サーバの構成を示すブロック図である。 利用明細管理サーバの構成を示すブロック図である。 行員管理サーバの構成を示すブロック図である。 分析サーバの構成を示すブロック図である。 窓口端末の構成を示すブロック図である。 情報処理システムによる処理の手順を示すシーケンス図である。 潜在資産算出処理の手順を示すフローチャートである。 ユーザ情報管理テーブルの一例を示す説明図である。 利用履歴管理テーブルの一例を示す説明図である。 行員管理テーブルの一例を示す説明図である。 全ユーザ用要否判定テーブルの一例を示す説明図である。 一部ユーザ用要否判定テーブルの一例を示す説明図である。 金融商品管理テーブルの一例を示す説明図である。 受付端末に表示される画像例を示す説明図である。 受付端末に表示される画像例を示す説明図である。 窓口端末に表示される画像例を示す説明図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

＜１．本発明者による検討＞
本発明者は、ユーザの潜在資産に着目した。ここで、潜在資産は、上述したように、何らかの用途で使用された資産のうち、他の用途にも使用可能な資産である。例えば、家賃や光熱費として消費された資産は潜在資産となりえない可能性が高いが、趣味として消費された資産は潜在資産となる可能性が高い。このような潜在資産は、様々な用途への応用が期待できる。例えば、潜在資産に応じたセールス情報の提供等が期待できる。

しかしながら、現状では、潜在資産に着目した技術は何ら提案されていなかった。そこで、本発明者は、潜在資産を算出する方法を検討し、この結果、クレジットカードの利用履歴に着目した。近年、クレジットカードは広く普及しており、利用可能な施設も幅広い。そして、クレジットカードを利用した場合、その利用履歴がクレジットカード会社等に蓄積される。利用履歴には、少なくとも、クレジットカードを用いて施設に支払った金額（いわゆる利用額）、施設名、施設の住所等が含まれる。したがって、利用履歴を見れば、クレジットカードがどのような用途で使用されたのかがわかる。そして、クレジットカードが家賃の支払に使用された場合、その支払に要した利用額は潜在資産とならない可能性が高い。一方で、クレジットカードが趣味のための支払に使用された場合、その支払に要した利用額は潜在資産となる可能性が高い。そこで、本発明者は、利用履歴に基づいて、潜在資産を算出することに想到した。そして、本発明者は、このような知見に基づいて、本実施形態に係る情報処理システム１に想到した。以下、本実施形態について詳細に説明する。

＜２．情報処理システムの構成＞
（２−１．全体構成）
まず、図１に基づいて、本実施形態に係る情報処理システム１の全体構成について説明する。情報処理システム１は、金融機関に設置されるシステムであり、受付端末１０と、ユーザ情報管理サーバ２０と、利用履歴管理サーバ３０と、行員管理サーバ４０と、分析サーバ５０（情報処理装置）と、窓口端末６０と、ネットワーク７０とを備える。

受付端末１０は、金融機関の店舗に一又は複数設置される端末であり、金融機関の店舗に来店したユーザによって操作される。ユーザ（本実施形態では金融機関の顧客）は、クレジット一体型のキャッシュカードを受付端末１０に挿入する。受付端末１０は、キャッシュカードからクレジットカード番号等を読み取って、分析サーバ５０に送信する。また、受付端末１０は、分析サーバ５０から金融商品情報（ユーザにおすすめの金融商品を示す情報）を取得する。受付端末１０は、金融商品情報に対応する行員情報を行員管理サーバ４０に要求する。受付端末１０は、行員管理サーバ４０から与えられた行員情報に基づいて、金融商品情報の送信先となる窓口端末６０を特定する。そして、受付端末１０は、特定された窓口端末６０に金融商品情報を送信する。受付端末１０は、金融商品情報を提示してもよい。さらに、受付端末１０は、窓口番号、受付番号等が記載されたチケットを発券する。窓口番号は、金融機関の窓口に設定された番号であり、受付番号は、金融機関がユーザの取引申請を受け付けた順番等を示す番号である。ユーザは、チケットが指定する窓口に向かう。

ユーザ情報管理サーバ２０は、例えば図１０に示すユーザ情報管理テーブルを記憶する。ユーザ情報管理テーブルは、一又は複数のユーザ情報からなるテーブルである。ユーザ情報管理サーバ２０は、分析サーバ５０からの要求に応じてユーザ情報を分析サーバ５０に送信する。

利用履歴管理サーバ３０は、例えば図１１に示す利用履歴管理テーブルを記憶する。利用履歴管理テーブルは、一又は複数の利用履歴情報からなるテーブルである。利用履歴管理サーバ３０は、分析サーバ５０からの要求に応じて利用履歴情報を分析サーバ５０に送信する。

行員管理サーバ４０は、例えば図１２に示す行員管理テーブルを記憶する。行員管理テーブルは、一又は複数の行員情報からなるテーブルである。行員管理サーバ４０は、受付端末１０からの要求に応じて行員情報を受付端末１０に送信する。

分析サーバ５０は、ユーザ情報及び利用履歴情報をユーザ情報管理サーバ２０及び利用履歴管理サーバ３０から取得する。そして、分析サーバ５０は、これらの情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定する。そして、分析サーバ５０は、利用履歴がユーザにとって必要な消費活動を示すと判定した場合、その利用履歴に対応する利用額を潜在資産としない。一方、分析サーバ５０は、利用履歴がユーザにとって不要な消費活動を示すと判断した場合、その利用履歴に対応する利用額を潜在資産とする。これにより、分析サーバ５０は、ユーザの潜在資産を算出する。さらに、分析サーバ５０は、潜在資産に応じた金融商品情報を選択する。分析サーバ５０は、金融商品情報を受付端末１０に送信する。

窓口端末６０は、金融機関の窓口を担当する行員（すなわち窓口担当行員）毎に用意される端末である。窓口端末６０は、窓口担当行員によって操作される。窓口端末６０は、金融商品情報を表示する。窓口担当行員は、窓口端末６０に表示された情報を参照しながら、ユーザに金融商品を説明する。

ネットワーク７０は、情報処理システム１を構成する各端末及びサーバ間を接続する。ネットワーク７０は有線ネットワークであっても、無線ネットワークであってもよい。

このように、本実施形態では、情報処理システム１は、ユーザ情報及び利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定する。そして、情報処理システム１は、判定結果に基づいて、ユーザの潜在資産を算出する。そして、情報処理システム１は、潜在資産に基づいて金融商品情報を選択し、窓口端末６０に提示する。したがって、情報処理システム１は、金融商品情報の選択に潜在資産を使用している。もちろん、潜在資産の用途はこの例には限られない。潜在資産の他の用途については後述する。

（２−２．受付端末の構成）
つぎに、図２に基づいて、受付端末１０の構成について説明する。受付端末１０は、入力操作部１１と、挿入部１２と、読取部１２ａと、発券部１３（ユーザ通知部）と、チケット排出部１３ａと、提示部１４と、通信部１５と、制御部１６とを備える。受付端末１０は、金融機関の店舗に一又は複数設置される。また、図示していないが、受付端末１０は、他の構成要素、例えば紙幣の投入、排出部等をさらに備えていても良い。

入力操作部１１は、ユーザによる入力操作を受け付けるものであり、例えばタッチパネル、テンキーなどである。入力操作部１１は、入力操作の内容に関する入力操作情報を制御部１６に出力する。

挿入部１２は、キャッシュカード及び通帳が挿入可能となっている。挿入部１２に挿入可能なキャッシュカードには、クレジット一体型のキャッシュカードが含まれる。ここで、クレジット一体型のキャッシュカードには、少なくとも、ユーザの氏名、クレジットカード番号、及び口座番号等のカード情報が含まれる。また、挿入部１２は、挿入部１２に挿入されたキャッシュカード及び通帳を排出することで、ユーザに返却する。

読取部１２ａは、挿入部１２に挿入されたキャッシュカードまたは通帳から各種の情報を読み取って、制御部１６に出力する。特に、挿入部１２にクレジット一体型のキャッシュカードが挿入された場合、クレジット一体型のキャッシュカードから上述したカード情報（ユーザの氏名、クレジットカード番号、口座番号を含む情報）を読み取る。

発券部１３は、各種情報（例えば上述した受付番号、窓口番号）等が記載されたチケットを発券する。提示部１４は、例えばディスプレイであり、各種画像情報を表示する。通信部１５は、ネットワーク７０に接続されており、情報処理システム１を構成する他の構成要素との間で通信を行う。

制御部１６は、受付端末１０内の各構成要素を制御する他、例えば、以下の処理を行う。まず、提示部１４に図１６に示す受付画像を表示させる。これに応じて、ユーザは、例えばクレジット一体型のキャッシュカードを挿入部１２に挿入する。読取部１２ａは、クレジット一体型のキャッシュカードからカード情報を読み取り、制御部１６に出力する。

そして、制御部１６は、図１７に示す来店目的選択画像を提示部１４に表示させる。来店目的選択画像には、来店目的が記載されたタッチボタンが複数表示されている。ユーザは、所望の来店目的が記載されたタッチボタンにタッチする。入力操作部１１は、タッチ操作に関する入力操作情報を制御部１６に出力する。制御部１６は、入力操作情報に基づいて、ユーザが選択した来店目的を認識する。そして、制御部１６は、ユーザが選択した来店目的に関する来店目的情報、及びカード情報を含むおすすめ商品要求情報を生成し、通信部１５に出力する。通信部１５は、おすすめ商品要求情報を分析サーバ５０に送信する。

これに応じて、通信部１５は、分析サーバ５０から金融商品情報を受信する。分析サーバ５０から送信される金融商品情報は、ユーザにおすすめする金融商品を示す。通信部１５は、金融商品情報を制御部１６に出力する。制御部１６は、金融商品情報を含む行員要求情報を生成し、通信部１５に出力する。なお、制御部１６は、金融商品情報を提示部１４に表示させても良い。通信部１５は、行員要求情報を行員管理サーバ４０に送信する。

これに応じて、通信部１５は、行員管理サーバ４０から行員情報を取得する。ここで、行員情報は、金融商品情報が示す金融商品に対応可能な行員を示す。制御部１６は、金融商品情報、ユーザの氏名、口座番号、受付番号、及び来店目的を含むおすすめ商品通知情報を生成する。さらに、制御部１６は、行員情報に含まれる窓口番号（担当窓口番号）に基づいて、おすすめ商品通知情報の送信先となる窓口端末６０を選択する。そして、制御部１６は、おすすめ商品通知情報を通信部１５に出力する。通信部１５は、おすすめ商品通知情報を制御部１６が選択した窓口端末６０に送信する。さらに、制御部１６は、図示しない受付番号管理サーバから受付番号を取得し、受付番号と、窓口番号とを含む発券情報を発券部１３に出力する。発券部１３は、発券情報が印刷されたチケットを発券する。チケット排出部１３ａは、チケットを排出する。ユーザは、チケットを受け取り、チケットが指定する窓口に向かう。

なお、受付端末１０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスク、タッチパネル、テンキー、ディスプレイ、読取装置、通信装置、及び発券装置などのハードウェア構成を有し、これらのハードウェア構成によって上述した機能が実現される。すなわち、ＲＯＭには、受付端末１０に、入力操作部１１と、挿入部１２と、読取部１２ａと、発券部１３と、チケット排出部１３ａと、提示部１４と、通信部１５と、制御部１６とを実現させるためのプログラムが記録される。ＣＰＵは、ＲＯＭに記録されたプログラムを読みだして実行する。あるいは、前述のプログラムの全部または一部をハードディスクに格納するようにしてもよい。以下の他の構成におけるＲＯＭについても同様である。

（２−３．ユーザ情報管理サーバの構成）
次に、図３及び図１０に基づいて、ユーザ情報管理サーバ２０の構成について説明する。ユーザ情報管理サーバ２０は、ユーザ情報管理データベース２１と、通信部２２と、制御部２３とを備える。ユーザ情報管理データベース２１は、ユーザ情報管理テーブルを記憶する。ユーザ情報管理テーブルは、一又は複数のユーザ情報からなるテーブルである。また、ユーザ情報は、ユーザの様々な属性を示す情報である。図１０にユーザ情報管理テーブルの一例を示す。この例では、ユーザ情報の属性は、口座番号、クレジットカード番号、氏名、性別、家族構成、職業、趣味、及び月々の月収となっている。これらの情報は、例えばユーザが金融機関で通帳等を作成する際にユーザから提供される。また、月々の月収に関しては、口座への入金履歴に基づいて算出されてもよい。もちろん、図１０に示すテーブルはあくまで一例であり、ユーザ情報の内容は図１０と異なっていてもよい。例えば、貯金額、休日等をユーザ情報に含めても良い。

通信部２２は、情報処理システム１の他の構成要素との間で通信を行う。制御部２３は、ユーザ情報管理サーバ２０の構成要素を制御する他、例えば以下の処理を行う。すなわち、分析サーバ５０は、ユーザ情報を要求する旨のユーザ属性要求情報をユーザ情報管理サーバ２０に送信する。ここで、分析サーバ５０が送信するユーザ属性要求情報には、ユーザの口座番号が含まれる。通信部２２は、ユーザ属性要求情報を受信して制御部２３に出力する。制御部２３は、ユーザ情報管理データベース２１からユーザ属性要求情報に対応するユーザ情報を取得する。そして、制御部２３は、ユーザ情報を通信部２２に出力し、通信部２２は、ユーザ情報を分析サーバ５０に送信する。

なお、ユーザ情報管理サーバ２０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスク、及び通信装置などのハードウェア構成を有し、これらのハードウェア構成によって上述した機能が実現される。すなわち、ＲＯＭには、ユーザ情報管理サーバ２０に、ユーザ情報管理データベース２１と、通信部２２と、制御部２３とを実現させるためのプログラムが記録される。ＣＰＵは、ＲＯＭに記録されたプログラムを読みだして実行する。

（２−４．利用履歴管理サーバの構成）
次に、図４及び図１１に基づいて、利用履歴管理サーバ３０の構成について説明する。利用履歴管理サーバ３０は、利用履歴管理データベース３１と、通信部３２と、制御部３３とを備える。利用履歴管理データベース３１は、利用履歴管理テーブルを記憶する。利用履歴管理テーブルは、一又は複数の利用履歴情報からなるテーブルである。図１１に利用履歴管理テーブルの一例を示す。この例では、利用履歴情報は、クレジットカード番号、利用日、支払先、利用費目、及び利用額で構成される。ここで、支払先は、ユーザがクレジットカードを使用した施設の種類を示す。支払先は、施設の名称であってもよい。利用費目は、クレジットカードで支払った金額、すなわち利用額の用途である。利用費目は、ユーザの消費活動を示すものであると言える。例えば、クレジットカードで通信会社に通信費を支払った場合、利用費目は「通信費」となる。これらの情報は、ユーザがクレジットカードを使用した施設から提供される情報から作成可能である。ユーザがクレジットカードを使用した施設から提供される情報には、施設名、施設の場所、利用日、利用額等が含まれるからである。もちろん、図１１に示すテーブルはあくまで一例であり、利用履歴情報の内容は図１１と異なっていてもよい。例えば、支払先は施設名であってもよい。

通信部３２は、情報処理システム１の他の構成要素との間で通信を行う。制御部３３は、利用履歴管理サーバ３０の構成要素を制御する他、例えば以下の処理を行う。すなわち、分析サーバ５０は、利用履歴情報を要求する旨の利用履歴要求情報を利用履歴管理サーバ３０に送信する。ここで、分析サーバ５０が送信する利用履歴要求情報には、クレジットカード番号が含まれる。通信部３２は、利用履歴要求情報を受信して制御部３３に出力する。制御部３３は、利用履歴管理データベース３１から利用履歴要求情報に対応する利用履歴情報を取得する。ここで、制御部３３は、過去１ヶ月分の利用履歴情報を取得する。そして、制御部３３は、利用履歴情報を通信部３２に出力し、通信部３２は、利用履歴情報を分析サーバ５０に送信する。

なお、利用履歴管理サーバ３０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスク、及び通信装置などのハードウェア構成を有し、これらのハードウェア構成によって上述した機能が実現される。すなわち、ＲＯＭには、利用履歴管理サーバ３０に、利用履歴管理データベース３１と、通信部３２と、制御部３３とを実現させるためのプログラムが記録される。ＣＰＵは、ＲＯＭに記録されたプログラムを読みだして実行する。

（２−５．行員管理サーバの構成）
次に、図５及び図１２に基づいて、行員管理サーバ４０の構成について説明する。行員管理サーバ４０は、行員管理データベース４１と、通信部４２と、制御部４３とを備える。行員管理データベース４１は、行員管理テーブルを記憶する。行員管理テーブルは、一又は複数の行員情報からなるテーブルである。図１２に行員管理テーブルの一例を示す。この例では、行員情報は、行員氏名、窓口番号（担当窓口番号）、及び担当可能業務で構成される。行員の担当可能業務が複数存在する場合、それらの担当可能業務は異なる列に格納される。もちろん、図１２に示すテーブルはあくまで一例であり、行員情報の内容は図１２と異なっていてもよい。例えば、行員情報には、ＶＩＰ対応可能か否かのＶＩＰ対応可否情報が含まれていても良い。この情報の用途は後述する。

通信部４２は、情報処理システム１の他の構成要素との間で通信を行う。制御部４３は、行員管理サーバ４０の構成要素を制御する他、例えば以下の処理を行う。すなわち、受付端末１０は、行員情報を要求する旨の行員要求情報を行員管理サーバ４０に送信する。ここで、受付端末１０が送信する行員要求情報には、金融商品情報が含まれる。通信部４２は、行員要求情報を受信して制御部４３に出力する。制御部４３は、行員管理データベース４１から要求情報に対応する行員情報を取得する。具体的には、制御部４３は、金融商品情報に対応する業務を特定し、この業務に対応可能な行員を示す行員情報を行員管理データベース４１から取得する。制御部４３は、行員情報を通信部４２に出力し、通信部４２は、利用履歴情報を受付端末１０に送信する。

なお、行員管理サーバ４０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスク、及び通信装置などのハードウェア構成を有し、これらのハードウェア構成によって上述した機能が実現される。すなわち、ＲＯＭには、行員管理サーバ４０に、行員管理データベース４１と、通信部４２と、制御部４３とを実現させるためのプログラムが記録される。ＣＰＵは、ＲＯＭに記録されたプログラムを読みだして実行する。

（２−６．分析サーバの構成）
次に、図６、図１３〜図１５に基づいて、分析サーバ５０の構成について説明する。分析サーバ５０は、通信部５１と、制御部５２（利用履歴情報取得部、）と、要否判定部５３と、潜在資産算出部５４と、セールス情報取得部５５とを備える。

通信部５１は、情報処理システム１の他の構成要素との間で通信を行う。制御部５２は、分析サーバ５０の構成要素を制御する他、例えば以下の処理を行う。すなわち、受付端末１０は、おすすめ商品要求情報を分析サーバ５０に送信する。ここで、受付端末１０が送信するおすすめ商品要求情報には、ユーザが選択した来店目的に関する来店目的情報、及びカード情報を含む。通信部５１は、おすすめ商品要求情報を受信して制御部５２に出力する。制御部５２は、おすすめ商品要求情報に基づいて、上述したユーザ属性要求情報と、利用履歴要求情報とを作成する。ユーザ属性要求情報には、ユーザの口座番号が含まれ、利用履歴要求情報には、クレジットカード番号が含まれる。そして、制御部５２は、これらの情報を通信部５１に出力する。通信部５１は、ユーザ属性要求情報をユーザ情報管理サーバ２０に送信し、利用履歴要求情報を利用履歴管理サーバ３０に送信する。通信部５１は、各サーバから送信されたユーザ情報及び利用履歴情報を制御部５２に出力する。制御部５２は、ユーザ情報及び利用履歴情報を要否判定部５３に出力する。また、制御部５２は、おすすめ商品要求情報をセールス情報取得部５５に出力する。

要否判定部５３は、ユーザ情報及び利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定する。ここで、本実施形態では、要否判定の基準をユーザの日常生活に設定する。ここで、ユーザの日常生活は、ユーザの衣食住環境を維持する活動、及び仕事上必要な活動を含む。したがって、日常生活には、趣味としての活動は含まれない。そして、要否判定部５３は、利用履歴がユーザの日常生活に必要な消費活動を示すか否かを判定する。そして、要否判定部５３は、利用履歴がユーザの日常生活に必要な消費活動を示す場合には、利用履歴がユーザにとって必要な消費活動を示すと判定する。一方、要否判定部５３は、利用履歴がユーザの日常生活に不要な消費活動を示すと判定した場合には、利用履歴がユーザにとって不要な消費活動を示すと判定する。ここで、ユーザの日常生活上必要な消費活動は、その消費活動に要した利用額を他の用途にほとんど（あるいは全く）使用できない消費活動となる。このような消費活動としては、例えば家賃や光熱費等が挙げられる。一方、ユーザにとって不要な消費活動は、その消費活動に要した利用額を他の用途に使用可能な消費活動となる。すなわち、ユーザにとって不要な消費活動は、その消費活動に要した利用額の全額が必ずしも不要とは言い切れないが、日常生活上必要とされる消費活動に比べて節約の余地が大きい消費活動となる。このような消費活動としては、例えば趣味上の活動が挙げられる。

ただし、何をもって「ユーザにとって必要な消費活動」と判断するかは任意であり、必ずしも上記の例に限られない。ユーザの趣味を重視するのであれば、趣味上の消費活動を「ユーザにとって必要な消費活動」と判断してもよい。

具体的には、要否判定部５３は、図１３に示す全ユーザ用要否判定テーブルを記憶する。ここで、全ユーザ用要否判定テーブルは、利用費目と、要否区分とで構成される。また、要否区分は、「全ての顧客にとって必要」という区分と、「ユーザ毎に要否が異なる」という区分とで構成される。なお、図１３に示す例では、一部の利用費目に対する要否区分しか示されていないが、全ユーザ用要否判定テーブルは、全ての利用費目と要否区分とを対応させて記録する。また、全ユーザ用要否判定テーブルに格納された要否区分は図１３の例に制限されない。例えば、飲食店に対する要否区分を「全ての顧客にとって必要」という区分に設定してもよい。また、家賃に対する要否区分を「ユーザ毎に要否が異なる」という区分に設定してもよい。例えば、１人暮らしのユーザは、実家で生活することも可能であるのにあえて１人暮らしをしている可能性がある。この場合、家賃は必ずしもユーザにとって必要であるとは言えない。

要否判定部５３は、利用履歴情報に含まれる利用費目と、全ユーザ用要否判定テーブルとに基づいて、利用履歴を、全ての顧客にとって必要な消費活動を示す第１の利用履歴と、顧客ごとに要否が異なる消費活動を示す第２の利用履歴とに区分する。

また、要否判定部５３は、図１４に示す一部ユーザ用要否判定テーブルを記憶する。一部ユーザ用要否判定テーブルは、利用費目と、要否判定条件と、要否区分とで構成される。一部ユーザ用要否判定テーブルにおける要否区分は、「必要」、「不要」、「判定不能（−）」のいずれかである。なお、図１４では、一部の利用費目に対する要否しか示されていないが、一部ユーザ用要否判定テーブルは、第２の利用履歴に対応する全ての利用費目を含む。

図１４に示す例によれば、「家族構成が独身かつ１人暮らし」という要否判定条件が満たされる場合、「飲食店」の利用費目（消費活動）は「必要」とされる。この場合、ユーザは、外食中心の生活になると想定されるからである。

また、「家族構成に１５歳以下の子供もしくは孫がいる」という要否判定条件が満たされる場合には、「娯楽施設」の利用費目（消費活動）は「必要」とされる。「娯楽施設」での消費活動は子供や孫の養育に必要であると想定されるからである。

したがって、要否判定部５３は、ユーザの家族構成に基づいて、第２の利用履歴がユーザにとって必要な消費であったか否かを判定することになる。

また、「月々の収入に対し、利用額の割合が３０％を超える」という要否判定条件が満たされる場合、すべての利用費目が「必要」とされる。このような利用費目は、ユーザの収入に比して高額であるため、ユーザにとって必要であると想定されるからである。

したがって、要否判定部５３は、ユーザの収入に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定することになる。

また、「職業と関連のある小売店からの購入」という要否判定条件が満たされる場合には、「通板／小売店」の利用費目（消費活動）が「必要」とされる。このような消費活動はユーザの業務上必要であると想定されるからである。例えば、ユーザの職業がコンピュータ関連であり、かつ、支払先がコンピュータパーツショップとなる場合、この要否判定条件が満たされることになる。なお、支払先がコンピュータパーツショップであるか否かを判定するためには、例えば、利用履歴情報に施設名を加えれば良い。

また、「趣味による利用」という要否判定条件が満たされる場合、すなわち、利用履歴が趣味上の消費活動を示す場合、全ての利用費目が「不要」とされる。趣味上の消費活動で支払われた利用額は節約可能と想定されるからである。なお、利用履歴が趣味上の消費活動を示すか否か判定する方法については特に制限されない。例えば、利用履歴が示す支払先とユーザの趣味とが関連しており、かつ、利用日がユーザの休日（例えば土日）となる場合、利用履歴は趣味上の消費活動を示す可能性が高い。ここで、趣味に関連する支払先とは、ユーザが趣味上の消費活動としてクレジットカードを使用する可能性の高い支払先を意味する。例えば、趣味が旅行となる場合、趣味に関連する支払先としては、航空会社、鉄道会社、旅行会社等が想定される。そして、このような利用履歴は、「不要」と判定される。なお、ゴルフ等の娯楽がユーザの職業上必要な場合がある（接待ゴルフ等）。このような利用費目は趣味としての消費活動から除外してもよい。

したがって、要否判定部５３は、ユーザの趣味に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定することになる。

なお、家賃に対する要否区分を「ユーザ毎に要否が異なる」という区分に設定した場合、「家族区制が独身かつ１人暮らし」という要否判定条件に対応する利用費目に「家賃」を追加する。そして、「家族区制が独身かつ１人暮らし」という要否判定条件及び「家賃」という利用費目に対応する要否区分は、「不要」となりうる。

要否判定部５３は、ユーザ情報と、利用履歴情報に含まれる利用費目と、一部ユーザ要否判定テーブルとに基づいて、第２の利用履歴がユーザにとって必要な消費活動を示すか否かを判定する。すなわち、要否判定部５３は、第２の利用履歴を、「必要」、「不要」、「判定不能」のいずれかに区分する。なお、要否判定部５３は、一部ユーザ用要否判定テーブルに列挙されるいずれの要否判定条件も満たされない場合、第２の利用履歴を「判定不能」に区分する。なお、第２の利用履歴が「判定不能」に区分された場合、第２の利用履歴に対応する利用額は潜在資産にカウントされる。もちろん、第２の利用履歴が「判定不能」に区分された場合、利用額を潜在資産にカウントしなくてもよい。

そして、要否判定部５３は、第１の利用履歴及び「必要」に区分された第２の利用履歴を、ユーザにとって必要な消費活動を示す必要履歴に区分する。また、要否判定部５３は、「不要」及び「判定不能」に区分された第２の利用履歴を、ユーザにとって不要な消費活動を示す不要履歴に区分する。そして、要否判定部５３は、判定結果に関する判定結果情報を潜在資産算出部５４に出力する。

潜在資産算出部５４は、判定結果情報に基づいて、潜在資産を算出する。具体的には、潜在資産算出部５４は、不要履歴に区分された利用履歴の利用額を積算することで、潜在資産を算出する。ここで、利用履歴管理サーバ３０は、過去１ヶ月分の利用履歴情報を分析サーバ５０に送信するので、潜在資産算出部５４は、過去１ヶ月分の潜在資産を算出することになる。もちろん、分析サーバ５０は、任意の期間の利用履歴情報を取得してもよい。この場合、潜在資産算出部５４は、その期間内の潜在資産を算出することになる。そして、潜在資産算出部５４は、潜在資産に関する潜在資産情報をセールス情報取得部５５に出力する。

セールス情報取得部５５は、図１５に示す金融商品管理テーブルを記憶する。金融商品管理テーブルは、来店目的と、金融商品名と、月々に必要な潜在資産の金額とを関連付けて記憶する。ここで、月々に必要な潜在資産の金額は、金額商品を購入し、維持するために必要な月々の支払額である。もちろん、図１５に示すテーブルはあくまで一例である。セールス情報取得部５５は、制御部５２から与えられたおすすめ商品要求情報と、潜在資産算出部５４から与えられた潜在資産情報と、図１５に示す金融商品管理テーブルとに基づいて、おすすめの金融商品を選択する。例えば、ユーザの来店目的が外貨預金であり、潜在資産が１００，０００円となる場合、セールス情報取得部５５は、金融商品として「ＣＣＣ」を選択する。そして、セールス情報取得部５５は、取得した金融商品に関する金融商品情報を生成し、制御部５２に出力する。

なお、分析サーバ５０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスク、及び通信装置などのハードウェア構成を有し、これらのハードウェア構成によって上述した機能が実現される。すなわち、ＲＯＭには、分析サーバ５０に、通信部５１と、制御部５２と、要否判定部５３と、潜在資産算出部５４と、セールス情報取得部５５とを実現させるためのプログラムが記録される。ＣＰＵは、ＲＯＭに記録されたプログラムを読みだして実行する。

（２−７．窓口端末の構成）
次に、図７及び図１８に基づいて、窓口端末６０の構成について説明する。窓口端末６０は、金融機関の店舗に設置される。また、窓口端末６０は、窓口担当行員毎に用意される。

窓口端末６０は、入力操作部６１と、提示部６２と、通信部６３と、制御部６４（提示制御部）とを備える。入力操作部６１は、窓口担当行員による入力操作を受け付けるものであり、例えばタッチパネル、キーボード、マウスなどである。入力操作部６１は、入力操作の内容に関する入力操作情報を制御部６４に出力する。提示部１４は、例えばディスプレイであり、各種画像情報を表示する。通信部６３は、ネットワーク７０に接続されており、情報処理システム１を構成する他の構成要素との間で通信を行う。

制御部６４は、窓口端末６０内の各構成要素を制御する他、例えば、以下の処理を行う。通信部６３は、おすすめ商品通知情報を受信し、制御部６４に出力する。制御部６４は、おすすめ商品通知情報を提示部６２に表示させる。表示例を図１８に示す。これにより、窓口担当行員は、どのようなユーザがどのような目的で来店したのかを容易に把握することができ、かつ、どのような金融商品を進めるべきかを容易に把握することができる。したがって、窓口担当行員は、ユーザとの取引をスムーズに開始することができ、かつ、取引時間を短くすることができる。また、窓口担当行員は、ユーザが所望する金融商品に対する専門性が高い。したがって、取引に関するユーザの満足度（いわゆる顧客満足度）を向上させることができる。なお、おすすめ商品通知情報は、画像表示以外の態様、例えば音声にて窓口担当行員に提示されてもよい。

なお、窓口端末６０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、タッチパネル、テンキー、キーボード、ディスプレイ、ハードディスク、及び通信装置などのハードウェア構成を有し、これらのハードウェア構成によって上述した機能が実現される。すなわち、ＲＯＭには、窓口端末６０に、入力操作部６１と、提示部６２と、通信部６３と、制御部６４とを実現させるためのプログラムが記録される。ＣＰＵは、ＲＯＭに記録されたプログラムを読みだして実行する。

＜３．情報処理システムによる処理の手順＞
次に、図８及び図９に基づいて、情報処理システム１による処理の手順について説明する。

図８に示すステップＳ１０において、制御部１６は、提示部１４に図１６に示す受付画像を表示させる。これに応じて、ユーザは、例えばクレジット一体型のキャッシュカードを挿入部１２に挿入する。

ステップＳ２０において、読取部１２ａは、クレジット一体型のキャッシュカードからカード情報を読みとり、制御部１６に出力する。ここで、カード情報には、少なくとも、ユーザの氏名、クレジットカード番号、及び口座番号等が含まれる。

ステップＳ３０において、制御部１６は、図１７に示す来店目的選択画像を提示部１４に表示させる。ユーザは、所望の来店目的が記載されたタッチボタンにタッチする。入力操作部１１は、タッチ操作に関する入力操作情報を制御部１６に出力する。制御部１６は、入力操作情報に基づいて、ユーザが選択した来店目的を認識する。

ステップＳ４０において、制御部１６は、ユーザが選択した来店目的に関する来店目的情報、及びカード情報を含むおすすめ商品要求情報を生成し、通信部１５に出力する。通信部１５は、おすすめ商品要求情報を分析サーバ５０に送信する。

ステップＳ５０において、分析サーバ５０の通信部５１は、おすすめ商品要求情報を受信して制御部５２に出力する。制御部５２は、おすすめ商品要求情報に基づいて、上述したユーザ属性要求情報と、利用履歴要求情報とを作成する。ユーザ属性要求情報には、ユーザの口座番号が含まれ、利用履歴要求情報には、クレジットカード番号が含まれる。そして、制御部５２は、これらの情報を通信部５１に出力する。通信部５１は、ユーザ属性要求情報をユーザ情報管理サーバ２０に送信し、利用履歴要求情報を利用履歴管理サーバ３０に送信する。

ユーザ情報管理サーバ２０は、上述した処理を行うことで、ユーザ情報を生成し、分析サーバ５０に送信する。また、利用履歴管理サーバ３０は、上述した処理を行うことで、利用履歴情報を生成し、分析サーバ５０に送信する。

通信部５１は、各サーバから送信されたユーザ情報及び利用履歴情報を制御部５２に出力する。制御部５２は、ユーザ情報及び利用履歴情報を要否判定部５３に出力する。また、制御部５２は、おすすめ商品要求情報をセールス情報取得部５５に出力する。

ステップＳ８０において、要否判定部５３及び潜在資産算出部５４は、図９に示す潜在資産算出処理を行う。すなわち、ステップＳ２００において、要否判定部５３は、利用履歴情報に含まれる利用費目と、図１３に示す全ユーザ用要否判定テーブルとに基づいて、利用履歴を、全ての顧客にとって必要な消費活動を示す第１の利用履歴と、顧客ごとに要否が異なる消費活動を示す第２の利用履歴とのいずれかに区分する。

要否判定部５３は、利用履歴を第１の利用履歴に区分した場合には、ステップＳ２１０に進み、利用履歴を第２の利用履歴に区分した場合には、ステップＳ２２０に進む。

ステップＳ２１０において、要否判定部５３は、ユーザにとって必要な消費活動を示す利用履歴（すなわち、第１の利用履歴、または「必要」に区分された第２の利用履歴）を必要履歴に区分する。そして、要否判定部５３は、判定結果に関する判定結果情報を潜在資産算出部５４に出力する。潜在資産算出部５４は、必要履歴が示す利用額を潜在資産にカウント（積算）しない。その後、潜在資産算出部５４はステップＳ２４０に進む。

ステップＳ２２０において、要否判定部５３は、ユーザ情報と、利用履歴情報に含まれる利用費目と、一部ユーザ要否判定テーブルとに基づいて、第２の利用履歴が処理対象のユーザにとって必要な消費活動を示すか否かを判定する。すなわち、要否判定部５３は、第２の利用履歴を、「必要」、「不要」、「判定不能」のいずれかに区分する。

そして、要否判定部５３は、第２の利用履歴を「必要」に区分した場合、ステップＳ２１０に進み、第２の利用履歴を「不要」または「判定不能」に区分した場合、ステップＳ２３０に進む。

ステップＳ２３０において、第２の利用履歴をユーザにとって不要な消費活動を示す不要履歴に区分する。そして、要否判定部５３は、判定結果に関する判定結果情報を潜在資産算出部５４に出力する。潜在資産算出部５４は、不要履歴に区分された利用履歴の利用額をカウント（積算）することで、潜在資産を算出（更新）する。その後、潜在資産算出部５４は、ステップＳ２４０に進む。

ステップＳ２４０において、要否判定部５３は、全ての利用履歴情報について要否判定を行ったか否かを判定する。要否判定部５３は、全ての利用履歴情報について要否判定を行ったと判定した場合には、潜在資産算出処理を終了する。一方、要否判定部５３は、要否判定を行っていない利用履歴情報が存在すると判定した場合には、ステップＳ２００に戻る。以上の処理により、潜在資産算出部５４は、潜在資産を算出する。

図８に示すステップＳ９０において、潜在資産算出部５４は、潜在資産情報をセールス情報取得部５５に出力する。セールス情報取得部５５は、制御部５２から与えられたおすすめ商品要求情報と、潜在資産算出部５４から与えられた潜在資産情報と、図１５に示す金融商品管理テーブルとに基づいて、おすすめの金融商品を選択する。そして、セールス情報取得部５５は、取得した金融商品に関する金融商品情報を生成し、制御部５２に出力する。制御部５２は、金融商品情報を通信部５１に出力し、通信部５１は、金融商品情報を受付端末１０に送信する。

ステップＳ１００において、通信部１５は、分析サーバ５０から金融商品情報を受信する。分析サーバ５０から送信される金融商品情報は、ユーザにおすすめする金融商品を示す。通信部１５は、金融商品情報を制御部１６に出力する。

ステップＳ１１０において、制御部１６は、金融商品情報を含む行員要求情報を生成し、通信部１５に出力する。なお、制御部１６は、金融商品情報を提示部１４に表示させても良い。通信部１５は、行員要求情報を行員管理サーバ４０に送信する。行員管理サーバ４０は、上述した処理を行うことで、行員情報を生成し、受付端末１０に送信する。そして、通信部１５は、行員管理サーバ４０から行員情報を取得する。ここで、行員情報は、金融商品情報が示す金融商品に対応可能な行員を示す。なお、この処理では、行員の選択を行員管理サーバ４０が行うが、行員の選択は受付端末１０側で行ってもよい。この場合、行員管理サーバ４０は、行員管理テーブルを受付端末１０に送信することとなる。

ステップＳ１２０において、制御部１６は、金融商品情報、ユーザの氏名、口座番号、受付番号、及び来店目的を含むおすすめ商品通知情報を生成する。さらに、制御部１６は、行員情報に含まれる窓口番号（担当窓口番号）に基づいて、おすすめ商品通知情報の送信先となる窓口端末６０を選択する。そして、制御部１６は、おすすめ商品通知情報を通信部１５に出力する。通信部１５は、おすすめ商品通知情報を制御部１６が選択した窓口端末６０に送信する。

ステップＳ１３０において、窓口端末６０の通信部６３は、おすすめ商品通知情報を受信し、制御部６４に出力する。制御部６４は、おすすめ商品通知情報を提示部６２に表示させる。表示例を図１８に示す。これにより、提示部６２は、金融商品に対応可能な行員に金融商品情報を通知する。したがって、窓口担当行員は、どのようなユーザがどのような目的で来店したのかを容易に把握することができ、かつ、どのような金融商品を進めるべきかを容易に把握することができる。したがって、窓口担当行員は、ユーザとの取引をスムーズに開始することができる。

ステップＳ１４０において、受付端末１０の制御部１６は、図示しない受付番号管理サーバから受付番号を取得し、受付番号と、窓口番号とを含む発券情報を発券部１３に出力する。発券部１３は、発券情報が印刷されたチケットを発券する。チケット排出部１３ａは、チケットを排出する。これにより、発券部１３は、金融商品に対応可能な行員をユーザに通知する。ユーザは、チケットを受け取り、チケットが指定する窓口に向かう。その後、ユーザは、窓口担当行員と取引を行う。

＜４．各種変形例＞
上述したように、行員管理テーブルには、行員情報として、ＶＩＰ対応可否情報を含めてもよい。この場合、ステップＳ１１０において、分析サーバ５０は、潜在資産情報を行員管理サーバ４０に送信する。一方、受付端末１０は、上記と同様に、行員要求情報を行員管理サーバ４０に出力する。行員管理サーバ４０の通信部４２は、これらの情報を制御部４３に出力する。そして、制御部４３は、潜在資産情報が示す潜在資産が極めて高額（例えば１００万円以上）となる場合には、窓口担当行員として、ＶＩＰ対応可能な行員を選択する。この場合、ユーザは、ＶＩＰ対応可能な行員の窓口に誘導されるので、取引に対するモチベーションが向上することが期待される。

また、上述した実施形態では、セールス情報として金融商品情報を提供したが、他の種類の商品情報を提供してもよいことはもちろんである。例えば、情報処理システム１は、潜在資産に応じた各種商品の広告情報をユーザに提供してもよい。この場合、情報処理システム１は、広告情報を受付端末１０の提示部１４に提示してもよいが、ユーザが携行する携帯端末（スマートフォン等）にメール送信してもよい。また、ユーザが携行する携帯端末に金融機関のアプリケーションがインストールされている場合、当該アプリケーションに対して広告情報を送信してもよい。広告情報は、ユーザの趣味に対応するものであってもよい。

さらに、上述した実施形態では、利用履歴が不要履歴に区分された場合、不要履歴が示す利用額の全額を潜在資産とした。しかしながら、必ずしも全額を潜在資産にしなくてもよい。例えば、潜在資産算出部５４は、不要履歴が示す利用額に第１の係数を乗じることで不要履歴が示す利用額を補正し、補正後の利用額に基づいて、潜在資産を算出してもよい。第１の係数は、０より大きく１未満の数値である。第１の係数は、全ての利用費目に対して一律であってもよく、利用費目毎に異なっていてもよい。また、第１の係数は、月々の収入と潜在資産（１ヶ月分）との比で決定されてもよい。すなわち、月々の収入に対して潜在資産が多い場合、第１の係数を低めとし、潜在資産を小さくしてもよい。この場合、潜在資産がユーザにとって必要な可能性が高いからである。また、ユーザの年齢が高いほど第１の係数を高くし、潜在資産を大きくしてもよい。年齢が高いほど、金額商品への興味が高くなると想定されるからである。係数は、ユーザからの要望などによって設定されてもよい。この変形例によれば、潜在資産をより柔軟に算出することができる。

また、上述した実施形態では、利用履歴が必要履歴に区分された場合、必要履歴が示す利用額の全額を潜在資産としない。しかしながら、必要履歴が示す利用額の一部を潜在資産としてもよい。具体的には、潜在資産算出部５４は、必要履歴が示す利用額に第２の係数を乗じることで必要履歴が示す利用額を補正し、補正後の利用額を潜在資産に積算してもよい。第２の係数は、０より大きく１未満の数値である。第２の係数は、第１の係数と同様の方法で調整されても良い。また、家族構成によって利用履歴が必要履歴とされた場合（図１４に示す一部ユーザ用要否判定テーブル参照）、家族構成に基づいて第２の係数が調整されても良い。例えば、利用費目が「娯楽施設」となる利用履歴が必要履歴とされた場合、子供の数が多いほど第２の係数を大きくしてもよい。子供の数が多いほど、「娯楽施設」で消費される金額が多くなると想定されるからである。また、第２の係数は第１の係数よりも小さくてもよい。必要履歴に対応する利用額は本来潜在資産とはならないものだからである。本変形例によれば、潜在資産をより柔軟に算出することができる。

また、金融機関以外の施設に情報処理システム１を導入してもよい。この場合、セールス情報は、その施設が提供する商品、サービスに関する情報となる。

また、潜在資産はセールス情報の提供以外の用途に使用されてもよい。このような例としては、例えば、潜在資産が多すぎるユーザに対して、消費を控える旨の注意喚起を行うサービス等が想定される。この場合、情報処理システム１は、当該サービスを提供する施設に設置される。

以上により、本実施形態によれば、情報処理システム１は、利用履歴情報に基づいて、利用履歴がユーザにとって必要な消費活動を示すか否かを判定し、その判定結果に基づいて、ユーザの潜在資産を算出する。したがって、情報処理システム１は、潜在資産を推定することができる。

さらに、情報処理システム１は、利用履歴がユーザの日常生活に必要な消費活動を示すか否かを判定し、利用履歴がユーザの日常生活に必要な消費活動を示す場合には、利用履歴がユーザにとって必要な消費活動を示すと判定する。したがって、情報処理システム１は、利用履歴がユーザにとって必要な消費活動を示すか否かをより正確に判定することができる。

さらに、情報処理システム１は、ユーザに関するユーザ情報に基づいて、利用履歴がユーザにとって必要な消費活動であったか否かを判定する。したがって、情報処理システム１は、利用履歴がユーザにとって必要な消費活動を示すか否かをより正確に判定することができる。

さらに、情報処理システム１は、ユーザの家族構成に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定する。したがって、情報処理システム１は、利用履歴がユーザにとって必要な消費活動を示すか否かをより正確に判定することができる。

さらに、情報処理システム１は、ユーザの趣味に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定する。したがって、情報処理システム１は、利用履歴がユーザにとって必要な消費活動を示すか否かをより正確に判定することができる。

さらに、情報処理システム１は、ユーザの収入に基づいて、利用履歴がユーザにとって必要な消費であったか否かを判定する。したがって、情報処理システム１は、利用履歴がユーザにとって必要な消費活動を示すか否かをより正確に判定することができる。

さらに、情報処理システム１は、利用履歴を、全てのユーザにとって必要な消費活動を示す第１の利用履歴と、ユーザごとに要否が異なる消費活動を示す第２の利用履歴とに区分し、ユーザ情報に基づいて、第２の利用履歴がユーザにとって必要な消費活動であったか否かを判定する。したがって、情報処理システム１は、利用履歴がユーザにとって必要な消費活動を示すか否かをより正確に判定することができる。

さらに、情報処理システム１は、ユーザにとって不要な消費活動を示す利用履歴を不要履歴に区分し、不要履歴が示す利用額に基づいて、潜在資産を算出する。したがって、情報処理システム１は、利用履歴がユーザにとって必要な消費活動を示すか否かをより正確に判定することができる。

また、情報処理システム１は、不要履歴が示す利用額に第１の係数を乗じることで不要履歴が示す利用額を補正し、補正後の利用額に基づいて、潜在資産を算出する。したがって、情報処理システム１は、より柔軟に潜在資産を算出することができる。

また、情報処理システム１は、必要履歴が示す利用額に第２の係数を乗じることで必要履歴が示す利用額を補正し、補正後の利用額に基づいて、潜在資産を算出する。したがって、情報処理システム１は、より柔軟に潜在資産を算出することができる。

また、情報処理システム１は、潜在資産に基づいて、セールス情報を取得し、提示するので、セールス情報の提供をより効果的に行うことができる。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

１ 情報処理システム
１０ 受付端末
２０ ユーザ情報管理サーバ
３０ 利用履歴管理サーバ
４０ 行員管理サーバ
５０ 分析サーバ
５１ 通信部
５２ 制御部
５３ 要否判定部
５４ 潜在資産算出部
５５ セールス情報取得部

Claims (17)

1. ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得する利用履歴情報取得部と、
   前記利用履歴情報に基づいて、前記利用履歴が前記ユーザにとって必要な消費活動を示すか否かを判定する要否判定部と、
   前記要否判定部による判定結果に基づいて、前記ユーザの潜在資産を算出する潜在資産算出部と、を備えることを特徴とする、情報処理システム。
2. 前記要否判定部は、前記利用履歴が前記ユーザの日常生活に必要な消費活動を示すか否かを判定し、前記利用履歴が前記ユーザの日常生活に必要な消費活動を示す場合には、前記利用履歴が前記ユーザにとって必要な消費活動を示すと判定することを特徴とする、請求項１記載の情報処理システム。
3. 前記要否判定部は、前記ユーザに関するユーザ情報に基づいて、前記利用履歴が前記ユーザにとって必要な消費活動であったか否かを判定することを特徴とする、請求項１または２記載の情報処理システム。
4. 前記ユーザ情報には、前記ユーザの家族構成が含まれ、
   前記要否判定部は、前記ユーザの家族構成に基づいて、前記利用履歴が前記ユーザにとって必要な消費であったか否かを判定する、請求項３記載の情報処理システム。
5. 前記ユーザ情報には、前記ユーザの趣味が含まれ、
   前記要否判定部は、前記ユーザの趣味に基づいて、前記利用履歴が前記ユーザにとって必要な消費であったか否かを判定する、請求項３または４記載の情報処理システム。
6. 前記ユーザ情報には、前記ユーザの収入が含まれ、
   前記要否判定部は、前記ユーザの収入に基づいて、前記利用履歴が前記ユーザにとって必要な消費であったか否かを判定する、請求項３〜５のいずれか１項に記載の情報処理システム。
7. 前記要否判定部は、前記利用履歴を、全てのユーザにとって必要な消費活動を示す第１の利用履歴と、ユーザごとに要否が異なる消費活動を示す第２の利用履歴とに区分し、前記ユーザ情報に基づいて、前記第２の利用履歴が前記ユーザにとって必要な消費活動であったか否かを判定することを特徴とする、請求項３〜６のいずれか１項に記載の情報処理システム。
8. 前記要否判定部は、前記ユーザにとって不要な消費活動を示す利用履歴を不要履歴に区分し、
   前記潜在資産算出部は、前記不要履歴が示す利用額に基づいて、前記潜在資産を算出することを特徴とする、請求項１〜７のいずれか１項に記載の情報処理システム。
9. 前記潜在資産算出部は、前記不要履歴が示す利用額に第１の係数を乗じることで前記不要履歴が示す利用額を補正し、補正後の利用額に基づいて、前記潜在資産を算出することを特徴とする、請求項８に記載の情報処理システム。
10. 前記要否判定部は、前記ユーザにとって必要な消費活動を示す利用履歴を必要履歴に区分し、
    前記潜在資産算出部は、前記必要履歴が示す利用額に第２の係数を乗じることで前記必要履歴が示す利用額を補正し、補正後の利用額に基づいて、前記潜在資産を算出することを特徴とする、請求項８または９に記載の情報処理システム。
11. 前記潜在資産に基づいて、セールス情報を取得するセールス情報取得部と、
    前記セールス情報を提示する制御を行う提示制御部と、を備えることを特徴とする、請求項１〜１０のいずれか１項に記載の情報処理システム。
12. 前記セールス情報は、金融商品を示す金融商品情報であることを特徴とする、請求項１１記載の情報処理システム。
13. 前記金融商品に対応可能な行員をユーザに通知するユーザ通知部を備えることを特徴とする、請求項１２記載の情報処理システム。
14. 前記提示制御部は、金融商品に対応可能な行員に前記金融商品情報を提示する制御を行うことを特徴とする、請求項１２または１３記載の情報処理システム。
15. ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得する利用履歴情報取得部と、
    前記利用履歴情報に基づいて、前記利用履歴が前記ユーザにとって必要な消費活動を示すか否かを判定する要否判定部と、
    前記要否判定部による判定結果に基づいて、前記ユーザの潜在資産を算出する潜在資産算出部と、を備えることを特徴とする、情報処理装置。
16. ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得するステップと、
    前記利用履歴情報に基づいて、前記利用履歴が前記ユーザにとって必要な消費活動を示すか否かを判定するステップと、
    前記判定の結果に基づいて、前記ユーザの潜在資産を算出するステップと、を備えることを特徴とする、情報処理方法。
17. コンピュータに、
    ユーザのクレジットカードの利用履歴に関する利用履歴情報を取得する利用履歴情報取得機能と、
    前記利用履歴情報に基づいて、前記利用履歴が前記ユーザにとって必要な消費活動を示すか否かを判定する要否判定機能と、
    前記要否判定機能による判定結果に基づいて、前記ユーザの潜在資産を算出する潜在資産算出機能と、を実現させることを特徴とする、プログラム。
    

Images