(57)【要約】【課題】ユーザの信用リスクの低下を促す。【解決手段】融資管理サーバ装置１００は、ユーザの信用リスクを小さくするための助言をユーザに提供し、その助言によってユーザの信用リスクが小さくなったか否かを判断する。そして、融資管理サーバ装置１００は、ユーザの信用リスクが小さくなったと判断された場合には、当該ユーザに特典を付与するための処理を行う。この特典は、例えば融資金利の低減や融資枠の増額など、ユーザに対する融資条件の緩和である。【選択図】図１
2018197984.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの信用リスクを小さくするための助言をユーザに提供する提供部と、
前記提供部によって提供された助言によって前記ユーザの信用リスクが小さくなったか否かを判断する判断部と、
前記ユーザの信用リスクが小さくなったと判断された場合には、当該ユーザに特典を付与するための処理を行う付与処理部と
を備えることを特徴とする情報処理装置。
【請求項２】
前記提供部は、ユーザの支出に関する助言を提供し、
前記付与処理部は、前記提供部により提供された助言に従ってなされた支出の削減の状況に応じた特典を付与する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記提供部は、ユーザの貯蓄に関する助言を提供し、
前記付与処理部は、前記提供部により提供された助言に従ってなされた貯蓄の増加の状況に応じた特典を付与する
ことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記付与処理部は、前記助言の種別ごとに、前記信用リスクの変化量と前記特典とを対応付けて記憶した記憶部を備え、前記助言の種別と前記信用リスクの変化量とに基づいて、ユーザに付与する特典を決める
ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
前記付与処理部は、前記ユーザの属性ごとに、前記信用リスクの変化量と前記特典とを対応付けて記憶した記憶部を備え、前記ユーザの属性と前記信用リスクの変化量とに基づいて、ユーザに付与する特典を決める
ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
【請求項６】
前記ユーザの信用リスクを推定するための情報を当該ユーザから取得する取得部を備え、
前記付与処理部は、前記取得部により取得された情報に基づいて推定した信用リスクが小さくなった場合には、当該ユーザに特典を付与する
ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
【請求項７】
前記付与処理部は、前記ユーザの信用リスクを推定するための情報の信頼度を特定し、特定した信頼度に基づいて前記信用リスクの変化量を算出する
ことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記特典は、前記ユーザに対する融資条件の緩和である
ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの信用リスクを低下させるための技術に関する。
【背景技術】
【０００２】
銀行等の金融機関においては、例えば顧客の年収や金融機関との取引状況等に基づいて、顧客に対する融資条件を決めている。例えば特許文献１の記載された仕組みでは、給与振込み利用であれば５０ポイント、公共料金の支払い利用であれば１種類に付き５ポイント、クレジットカード振込み口座利用であれば２０ポイント、年間平均残高が１０万円毎に１ポイントというように、口座の運用実績に応じて与信ポイントを付与し、すべての与信ポイントを加算して１０ポイントに付き１万円の与信枠に換算している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−３６３５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載された仕組みは、顧客と金融機関との取引状況が良好であるほど融資条件を緩和するものであるが、本来は、融資を受けたユーザによる返済が滞る危険性（以下、信用リスクという）が低下していくほど、そのユーザに対する融資条件を緩和するべきである。ユーザにとっても自身の信用リスクが低下して融資条件が緩和されれば、これは望ましいことである。
【０００５】
そこで、本発明は、ユーザの信用リスクの低下を促すための仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、ユーザの信用リスクを小さくするための助言をユーザに提供する提供部と、  前記提供部によって提供された助言によって前記ユーザの信用リスクが小さくなったか否かを判断する判断部と、前記ユーザの信用リスクが小さくなったと判断された場合には、当該ユーザに特典を付与するための処理を行う付与処理部とを備えることを特徴とする情報処理装置置を提供する。
【０００７】
前記付与処理部は、前記ユーザの属性ごとに、前記信用リスクの変化量と前記特典とを対応付けて記憶した記憶部を備え、前記ユーザの属性と前記信用リスクの変化量とに基づいて、ユーザに付与する特典を決めるようにしてもよい。
【０００８】
前記付与処理部は、前記助言の種別ごとに、前記信用リスクの変化量と前記特典とを対応付けて記憶した記憶部を備え、前記助言の種別と前記信用リスクの変化量とに基づいて、ユーザに付与する特典を決めるようにしてもよい。
【０００９】
前記提供部は、ユーザの支出に関する助言を提供し、前記付与処理部は、前記提供部により提供された助言に従ってなされた支出の削減の状況に応じた特典を付与するようにしてもよい。
【００１０】
前記提供部は、ユーザの貯蓄に関する助言を提供し、前記付与処理部は、前記提供部により提供された助言に従ってなされた貯蓄の増加の状況に応じた特典を付与するようにしてもよい。
【００１１】
前記ユーザの信用リスクを推定するための情報を当該ユーザから取得する取得部を備え、前記付与処理部は、前記取得部により取得された情報に基づいて推定した信用リスクが小さくなった場合には、当該ユーザに特典を付与するようにしてもよい。
【００１２】
前記付与処理部は、前記ユーザの信用リスクを推定するための情報の信頼度を特定し、特定した信頼度に基づいて前記信用リスクの変化量を算出するようにしてもよい。
【００１３】
前記特典は、前記ユーザに対する融資条件の緩和であってもよい。
【発明の効果】
【００１４】
本発明によれば、ユーザの信用リスクの低下を促すことができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態に係る融資管理システム１の概要を例示するブロック図。
【図２】本発明の一実施形態に係る融資管理サーバ装置１００のハードウェア構成を例示するブロック図。
【図３】支出情報ＤＢの一例を示す図。
【図４】支出要否判定条件の一例を示す図。
【図５】融資金利決定条件の一例を示す図。
【図６】助言ＤＢの一例を示す図。
【図７】融資管理サーバ装置１００の機能構成を例示するブロック図。
【図８】融資管理サーバ装置１００の動作を示すフローチャート。
【発明を実施するための形態】
【００１６】
［構成］
図１は、本発明の一実施形態に係る融資管理システム１の概要を例示するブロック図である。融資管理システム１は、ユーザに対する融資に関する管理を行う融資管理サーバ装置１００と、ユーザによって操作される通信装置２００と、ユーザの収入、支出及び資産に関する情報を管理する家計簿サイトを運営する家計簿サーバ装置３００とを備えている。これらの装置１００〜３００は、ネットワーク９００によって相互に通信可能となるように接続されている。ネットワーク９００は、無線通信ネットワーク又は有線通信ネットワークを含む。通信装置２００は、例えばスマートホン、タブレット又はパーソナルコンピュータ等のコンピュータ装置である。通信装置２００は、例えばスマートホンであれば、ネットワーク９００の無線基地局と例えばＬＴＥ（Long Term Evolution）等の通信規格の無線通信を行って、融資管理サーバ装置１００及び家計簿サーバ装置３００との間でデータ通信を行う。
【００１７】
家計簿サーバ装置３００は、いわゆるクラウド型の家計簿サービスを提供するコンピュータ装置である。家計簿サーバ装置３００は、例えばユーザが口座を保有する銀行やユーザが契約しているクレジット会社のＷＥＢサイトに代行ログインしてユーザの口座における入金、出金及び残高に関する情報を取得したり、ユーザが利用登録しているショッピングＷＥＢサイトと連携してユーザの買い物に関する情報を取得したり、或いは、通信装置２００と連携してユーザが店舗で買い物したときに受け取ったレシートを光学的に読み取った結果を取得する等の方法により、ユーザの入出金及び資産に関する様々な情報を取得し、これを蓄積する。家計簿サーバ装置３００は、取得した情報を解析することで、家計簿を作成したり、他のユーザがなににいくら使っているかというような統計処理を行ったり、ユーザの口座や財布の残高を計算したりして、その結果を通信装置２００に送信し、表示させる。
【００１８】
融資管理サーバ装置１００は、ユーザからの融資の申し込みに応じて融資条件を決定し、決定した融資条件を例えば図示せぬ融資システムに通知するなどの、融資を実行するための処理を行う。この融資が実行された後において、融資管理サーバ装置１００は、融資を受けたユーザによる返済が滞る危険性（以下、信用リスクという）を小さくするための助言をユーザに提供し、その助言によって信用リスクが小さくなったか否かを判断する。そして、融資管理サーバ装置１００は、助言によってユーザの信用リスクが小さくなったと判断された場合には、そのユーザに特典を付与するための処理を行う。この特典は、例えば融資金利の低減などの、ユーザに対する融資条件の緩和である。ユーザに特典を付与するための処理とは、融資管理サーバ装置１００が特典の内容を図示せぬ融資システムに通知して融資条件を緩和させることである。
【００１９】
図２は、融資管理サーバ装置１００のハードウェア構成を例示するブロック図である。融資管理サーバ装置１００は、本発明に係る情報処理装置の一例であり、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、補助記憶装置１０４、及び通信ＩＦ１０５を有するコンピュータ装置である。ＣＰＵ１０１は、各種の演算を行うプロセッサである。ＲＡＭ１０３は、ＣＰＵ１０１がプログラムを実行する際のワークエリアとして機能する揮発性メモリある。ＲＯＭ１０２は、例えば融資管理サーバ装置１００の起動に用いられるプログラム及びデータを記憶した不揮発性メモリである。補助記憶装置１０４は、例えばＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）等の不揮発性の記憶装置であり、融資管理サーバ装置１００において用いられるプログラム及びデータを記憶する。ＣＰＵ１０１がこのプログラムを実行することにより、融資管理サーバ装置１００において後述する図６に示される機能が実現される。通信ＩＦ１０５は、所定の通信規格に従ってネットワーク９００を介した通信を行う。
【００２０】
補助記憶装置１０４は、融資管理サーバ装置１００が家計簿サーバ装置３００から取得した情報、本実施形態では少なくともユーザの支出に関する支出情報を記憶する。図３は、補助記憶装置１０４に記憶される支出情報データベース（以下、データベースをＤＢという）を例示する図である。図３に示すように、補助記憶装置１０４に記憶される支出情報ＤＢにおいては、各ユーザを識別するユーザＩＤ、各ユーザ属性であるユーザ属性、各ユーザが金銭を支出した支出日時、その支出により購入した商品又はサービスを所定の基準で分類した支出項目、及びその支出金額が対応付けられている。ユーザ属性は、例えばユーザの性別、年齢、住所、趣味乃至興味、家族に関する情報、及び、年収や資産に関する情報が含まれる。これらのユーザ属性は融資管理サーバ装置１００が家計簿サーバ装置３００から取得したものであってもよいし、ユーザから融資管理サーバ装置１００に予め届け出られたものであってもよい。
【００２１】
支出項目は、その支出の属性乃至性格を意味しており、本実施形態では、上位の大項目及び下位の小項目という２階層の構成となっている。大項目は、例えば、食費、水道光熱費、通信費、遊興費、交通費、美容費、医療費、被服費、生活雑貨・日用品費、教育費、交際費、住宅費、保険費、社会保険費、税金等を含む。例えば大項目である遊興費に属する小項目は、外食、レジャー、映画、書籍雑誌、飲み会、その他遊興費等を含む。また、大項目である通信費に属する小項目は、携帯電話、固定電話、インターネット、郵便・宅配便、その他通信費等を含む。
【００２２】
また、補助記憶装置１０４は、ユーザの支出にどの程度の必要性があったのか、つまり支出の要否の程度を判定するための支出要否判定条件を記憶している。図４は支出要否判定条件の一例である。ここでは、支出分類として、前述した支出項目群のうち、支出の必要性が相対的に高いもの（必要支出項目という）と、支出の必要性が相対的に低いもの（不要支出項目という）とを定義する。なお、「不要支出項目」という用語における「不要」とは、支出する必要性が相対的に低いという程度の意味であり、その支出が完全に不要であるという意味ではない。
【００２３】
この必要支出項目及び不要支出項目は、前述した支出項目の大項目又は小項目ごとに定義される。さらに、１つの支出項目のうち、或る基準額以内は必要支出項目であるが、その基準額を超えると不要支出項目となる場合もある。例えば小項目として上記に例示したもののうち、遊興費という大項目に属する小項目群は、外食及び書籍雑誌という小項目を除いて、支出金額に関わらず不要支出項目である。ただし、外食は、１ヶ月に３０００円以内であれば必要支出項目であり、１ヶ月に３０００円を超えると、その超過額が不要支出項目となる。また、書籍雑誌は、１ヶ月に２０００円以内であれば必要支出項目であるが、１ヶ月に２０００円を超えると、その超過額が不要支出項目となる。また、通信費という大項目に属する小項目群は、携帯電話という小項目を除いて、必要支出項目である。ただし、携帯電話は、１ヶ月に１２０００円以内であれば必要支出項目であるが、１ヶ月に１２０００円を超えると、その超過額が不要支出項目となる。
【００２４】
ここで、各支出項目の基準額は、本システムを利用するユーザ群が各支出項目に支出した金額の平均値に基づいて決められている。図４の例で言うと、例えば全ユーザの１ヶ月あたりの外食の平均値は３０００円であるし、例えば全ユーザの１ヶ月あたりの携帯電話の支払いの平均値は１２０００円である。前述したように、各ユーザがなににいくら使っているかというような家計簿サーバ装置３００の統計処理は周知なので、この統計処理の結果に基づいて決められた基準額が支出要否判定条件として用いられる。また、融資管理サーバ装置１００自身が、支出情報ＤＢの内容に基づいて上記のような統計処理を行って基準額を求め、支出要否判定条件として用いてもよい。
【００２５】
また、補助記憶装置１０４は、ユーザに対する融資条件の１つである融資利率を決定するための融資金利判定条件を記憶している。図５は融資金利判定条件の一例である。融資金利判定条件においては、１のユーザの不要支出項目の支出金額の総額（不要支出金額という）を必要支出項目の支出金額の総額（必要支出金額という）で除算した値と、そのユーザに対する基準融資金利とが対応付けられている。不要支出金額／必要支出金額は、ユーザの支出における傾向（ここではユーザの支出における不要支出の傾向）を表すパラメータであるから、以下、支出傾向パラメータという。この支出傾向パラメータの値が大きいほど、支出の必要性が相対的に高いものに対する支出の必要性が相対的に低いものの割合が大きいから、ユーザの消費行動は浪費の傾向にあると考えられる。ここで、融資を受けたユーザの浪費傾向とそのユーザの信用リスクの大きさは相関関係にあるとの前提で、浪費傾向が認められるほど信用リスクが大きくなると想定する。そしてし、その信用リスクの増大に見合うように基準融資金利を高くしている。一方、支出傾向パラメータの値が小さいほど、ユーザの消費行動が節約の傾向にあると言える。よって、節約傾向が認められるほど信用リスクが小さくなると想定して基準融資金利を低くしている。なお、これら支出傾向パラメータの具体的な値及び基準融資金利の具体的な値は、融資する側（つまり融資管理サーバ装置１００の運営者）によって任意に決められる。
【００２６】
また、補助記憶装置１０４は、ユーザに対する助言を示す助言データを含む助言ＤＢを記憶している。図６は助言ＤＢの一例である。融資管理サーバ装置１００は、ユーザの支出の状況を解析することで、予め用意された複数の支出パターンのうちいずれに該当するかを判断する。図６において、解析結果パターンとして例示されたパターンＡ１、パターンＡ２・・・は、例えば食費が多いというように特定の支出項目の支出が平均値に比べて多いといったパターンや、給与日直後に支出が多いというように特定の時期に支出が平均値に比べて多いといったパターンや、ユーザ以外に家族が居ないのに水道光熱費が多いというようにユーザ属性との比較で特定の支出項目の支出が平均値に比べて多いといったパターンや、食費に対して外食費が多いというように特定の支出項目の支出が別の特定の支出項目の支出との対比において多いといったパターンなどである。
【００２７】
助言ＤＢにおいては、これらの解析結果パターンのそれぞれに対して、ユーザの信用リスクを小さくするための助言データが対応付けられている。例えば食費が多いという解析結果パターンに対しては、「他のユーザに比べて食費が多い傾向にあります」とか「食費を抑えましょう」というような種別の助言データが対応付けられている。また、例えば給与日直後に支出が多いという解析結果パターンに対しては、「他のユーザに比べて給与支給後の支出が多い傾向にあります」とか「給与支給後は節約に努めましょう」というような種別の助言データが対応付けられている。また、ユーザ以外に家族が居ないのに水道光熱費が多いというという解析結果パターンに対しては、「他のユーザに比べて水道光熱費の支出が多い傾向にあります」とか「水道光熱費の節約に努めましょう」というような種別の助言データが対応付けられている。また、食費に対して外食費が多いという解析結果パターンに対しては、「他のユーザに比べて外食の割合が高い傾向にあります」とか「もう少し自炊して節約に努めましょう」というような種別の助言データが対応付けられている。
【００２８】
それぞれの助言の種別に対しては、信用リスクの変化量（低下量）とユーザに対して与えられる特典とが対応付けられている。ここで、信用リスクの具体的な値を算出する方法は、融資を受けたユーザによる返済が滞る危険性を求める方法であれば、どのようなものを用いてもよい。信用リスクの値として、例えば前述した支出傾向パラメータの値そのものを用いてもよいし、また、既存の手法を用いて算出可能ないわゆる債務不履行率と呼ばれる値を用いてもよい。例えば、助言群Ａ１に対しては、信用リスクｘ％低下で融資金利ｙ％低下、という特典が対応づけられており、助言群Ａ２に対しては、信用リスクa％低下で融資金利ｂ％低下、という特典が対応づけられている。このように信用リスクの変化量とユーザへの特典との関係が異なるのは、ユーザにとって、助言群Ａ２に応じて信用リスクをａ％低下させることが、助言群Ａ１に応じて信用リスクをｘ％低下させることよりも難しいからである。例えば、前述した必要支出項目は不要支出項目よりもユーザにとって支出削減が難しいと考えられるから、信用リスク低下に対する特典の価値はより大きくなる。
【００２９】
図７は、融資管理サーバ装置１００の機能構成を例示するブロック図である。取得部１１は融資管理サーバ装置１００の通信ＩＦ１０５によって実現され、分類部１２は融資管理サーバ装置１００のＣＰＵ１０１及び補助記憶装置１０４によって実現され、決定部１３は融資管理サーバ装置１００のＣＰＵ１０１及び補助記憶装置１０４によって実現され、提供部１４は融資管理サーバ装置１００の通信ＩＦ１０５によって実現され、判断部１５は融資管理サーバ装置１００のＣＰＵ１０１及び補助記憶装置１０４によって実現され、付与処理部１６は融資管理サーバ装置１００のＣＰＵ１０１及び補助記憶装置１０４によって実現され、記憶部１７は融資管理サーバ装置１００の補助記憶装置１０４によって実現される。
【００３０】
取得部１１は、ユーザの支出に関する支出情報を、例えば家計簿サーバ装置３００から取得する。分類部１２は、支出項目ごとにその支出が必要支出情報又は不要支出情報のいずれであるかを記憶しており、取得部１１により取得された支出情報を、支出の必要性が相対的に高い支出に関する必要支出情報と、支出の必要性が相対的に低い支出に関する不要支出情報とに分類する。決定部１３は、分類部１２により分類された結果に基づいて、ユーザの信用リスクを求めて、ユーザに対する融資条件（ここでは融資金利）とユーザの信用リスクを小さくするための助言とを決定する。提供部１４は、決定部１３により決定された融資条件及び助言を例えば通信装置２００に送信する等して、ユーザに提供する。
【００３１】
判断部１５は、取得部１１により取得された支出情報に基づき、提供部１４によって提供された助言によってユーザの信用リスクが小さくなったか否かを判断する。付与処理部１６は、助言によってユーザの信用リスクが小さくなったと判断された場合には、ユーザに特典を付与するための処理を行う。記憶部１７は、助言の種別ごとに、信用リスクの変化量と特典とを対応付けて記憶しており、付与処理部１６は、提供された助言の種別と信用リスクの変化量とに基づいて、ユーザに付与する特典を決める。
【００３２】
［動作］
図８は、融資管理サーバ装置１００の動作を例示するフローチャートである。図８において、例えばユーザから融資申し込みがある等して融資条件を決定する時期が到来すると、融資管理サーバ装置１００の取得部１１は、融資条件決定対象となるユーザのユーザＩＤに対応する支出情報を家計簿サーバ装置３００から取得し、補助記憶装置１０４内の支出情報ＤＢに記憶する（ステップＳ１１）。この支出情報は例えば過去１２か月分とか過去６か月分等の、過去の所定期間におけるユーザの支出に関する情報である。
【００３３】
次に、融資管理サーバ装置１００の分類部１２は、記憶部１３に記憶されている支出要否判定条件に基づいて、上記支出情報を必要支出情報と不要支出情報とに分類する（ステップＳ１２）。
【００３４】
次に、融資管理サーバ装置１００の決定部１４は、分類部１２により分類された結果に基づいて、不要支出情報／必要支出情報の値を算出し、融資金利判定条件に従って上記ユーザの信用リスクを算出する（ステップＳ１３）。ここでは、支出情報が例えば過去１２か月分である場合には、１ヶ月ごとに信用リスクを算出してこれを平均化する。
【００３５】
次に、融資管理サーバ装置１００の判断部１５は、算出した信用リスクが前回の信用リスク算出からどのように変化したかを判断する（ステップＳ１４）。ステップＳ１３の処理がユーザから融資申し込みがあって最初の信用リスク算出の処理であれば、信用リスクの変化はないとみなす。信用リスクに変化が無い場合には、ユーザに対して特典は与えられない。
【００３６】
次に、融資管理サーバ装置１００の決定部１３は、融資金利判定条件に従って、算出した信用リスクに対応する基準融資金利を特定する。そして、決定部１３は、この基準融資金利に対して必要に応じた加減算を行い（例えばユーザの年収や資産に基づく優遇金利幅を減算する等）、ユーザに対する最終的な融資金利を含む融資条件を決定する。さらに、融資管理サーバ装置１００の決定部１４は、ユーザの支出情報に基づいてユーザの支出の状況を解析してその支出のパターンを求め、助言ＤＢにおいてそのパターンに対応する助言データを決定する（ステップＳ１５）。
【００３７】
そして、融資管理サーバ装置１００の提供部１４は、決定した融資条件及び助言データを例えば通信装置２００に送信する等して、ユーザに提示する（ステップＳ１６）。
【００３８】
例えばユーザに対する融資実行後に一定期間が経過するなどの、融資条件の見直し時期が到来すると、再びそのユーザについて図８の処理が開始される。融資管理サーバ装置１００の取得部１１は、上記ユーザのユーザＩＤに対応する支出情報を家計簿サーバ装置３００から取得し、補助記憶装置１０４内の支出情報ＤＢに記憶する（ステップＳ１１）。
【００３９】
次に、融資管理サーバ装置１００の分類部１２は、支出要否判定条件に基づいて上記支出情報を必要支出情報と不要支出情報とに分類する（ステップＳ１２）。次に、融資管理サーバ装置１００の決定部１４は、分類部１２により分類された結果に基づいて、不要支出情報／必要支出情報の値を算出し、融資金利判定条件に従って上記ユーザの信用リスクを算出する（ステップＳ１３）。
【００４０】
次に、融資管理サーバ装置１００の判断部１５は、算出した信用リスクが前回の信用リスク算出からどのように変化したかを判断する（ステップＳ１４）。ここで、例えば助言種別として助言群Ａ１をユーザに提供した結果、信用リスクが２×ｘ％低下した場合を想定すると、図６の例では信用リスクがｘ％で融資金利ｙ％低下だから、次回の融資金利見直しまでは前回融資金利から２×ｙ％低下させると判断する。ただし、この信用リスクの低下が助言群Ａ１によるものでなければ融資金利は低下させない。例えば前回判断した支出のパターンが食費が多いという結果に対して、「他のユーザに比べて食費が多い傾向にあります」とか「食費を抑えましょう」というような種別の助言データを提供した場合、食費の削減により信用リスクが低下した場合のみ、融資金利を低下させる。食費の削減により信用リスクが低下したのか否かは、食費の削減分以外の条件を全て同じにして、食費の削減がなされた前後の信用リスクを比較すれば判断可能である。
【００４１】
次に、融資管理サーバ装置１００の決定部１３は、上記の融資金利を含む融資条件、及び、ユーザの支出情報に基づいて新たに解析したユーザの支出パターンに対応する助言データを決定する（ステップＳ１５）。
【００４２】
そして、融資管理サーバ装置１００の提供部１４は、決定した融資条件及び助言データを例えば通信装置２００に送信する等して、ユーザに提示する（ステップＳ１６）。以降、上述したステップＳ１１〜Ｓ１６が融資された資金がユーザによって完済されるまで繰り返される。
【００４３】
本実施形態によれば、ユーザに対する助言に従ってユーザの信用リスクが低下すると、融資条件を緩和するので、ユーザに対して信用リスクの低下を促すことが可能となる。これにより、融資する側にとっては信用リスクに応じた適正な融資条件で融資を行うことができる。一方、融資を受けるユーザにとっては、適正な融資条件で融資を受けられることに加え、信用リスクを低下させるような節約あるいは貯蓄の行為を習慣化するなどのメリットがある。
【００４４】
［変形例］
本発明は上述の実施形態に限定されるものではなく、種々の変形実施が可能である。以下、変形例をいくつか説明する。以下の変形例のうち２つ以上のものが組み合わせて用いられてもよい。
［変形例１］
実施形態において、決定部１３は、ユーザの支出情報に基づいて信用リスクを決めていたが、この支出情報以外に、ユーザの貯蓄や資産に関する情報に基づいて信用リスクを決めてもよい。つまり、ユーザの貯蓄や資産が多いほど信用リスクは小さくなる傾向となる。
【００４５】
［変形例２］
実施形態において、付与処理部１６は、助言の種別ごとに決められた、信用リスクの変化量と特典との関係に基づいて、ユーザに付与する特典を決めていた。これを例えばユーザの属性ごとに決められた、信用リスクの変化量と特典との関係に基づいて、ユーザに付与する特典を決めてもよい。具体的には、記憶部１７はユーザの属性ごとに、信用リスクの変化量と特典とを対応付けて記憶する。例えば扶養家族が居ないという属性のユーザに対しては、信用リスクｐ％低下で融資金利ｑ％低下という特典が対応づけられており、扶養家族が居るという属性のユーザに対しては、信用リスクｐ％低下で融資金利１．５×ｑ％低下という特典が対応づけられている。このように信用リスクの変化量とユーザへの特典との関係が異なるのは、扶養家族が居るユーザにとって信用リスクをｐ％低下させることは、扶養家族が居ないユーザが信用リスクをｐ％低下させることよりも難しいからである。ユーザ属性として、上記の扶養家族の有無以外に、ユーザの性別、年齢、住所、趣味乃至興味、及び、年収や資産に関する情報を用いてもよい。
【００４６】
［変形例３］
実施形態では、提供部１４はユーザの支出に関する助言を提供し、付与処理部１６は、提供された助言に従ってなされた支出の削減の状況に応じた特典を付与していた。これ以外に、提供部１４は、ユーザの貯蓄に関する助言を提供し、付与処理部１６は、提供部１４により提供された助言に従ってなされた貯蓄の増加の状況に応じた特典を付与するようにしてもよい。例えば助言ＤＢにおいて、予め用意された複数の貯蓄パターンが助言データと対応づけられている。考え得る貯蓄パターンとしては、例えば同じ属性のユーザに比べて貯蓄が少ないであるとか、リスクの高い投資商品における貯蓄が多いとか、貯蓄先となる金融機関の数が少ないといった例が考えられる。これらに対応する助言データとしては、例えば同じ属性のユーザに比べて貯蓄が少ない場合には、「他のユーザに比べて貯蓄が少ない傾向にあります」とか「もう少し貯蓄しましょう」であるとか、リスクの高い投資商品における貯蓄が多い場合には「貯蓄のリスクが高いです」であるとか、貯蓄先となる金融機関の数が少ない場合には「資金運用する金融機関の数を増やしてリスク分散しましょう」であるといった例が考えられる。
【００４７】
［変形例４］
取得部１１は、ユーザの信用リスクを推定するための情報をユーザから取得し、付与処理部１６は、取得部１１により取得された上記情報に基づいて推定した信用リスクが小さくなった場合には、そのユーザに対し、上記情報提供の対価としての特典を付与するようにしてもよい。例えば取得部１１が家計簿サーバ装置３００等の装置からユーザの貯蓄額や資産を取得できない場合に、ユーザ自身が口座残高証明書などを提出するとか、金融機関のＷＢサイトにログインするための情報を提供するなどして、これによりユーザの貯蓄額や資産を確認して信用リスクが低下するということを確認できれば、付与処理部１６は、融資金利を低減するという特典を付与するようにしてもよい。
【００４８】
［変形例５］
さらに、付与処理部１６は、ユーザの信用リスクを推定するための情報の信頼度を特定し、特定した信頼度に基づいて信用リスクの変化量を算出するようにしてもよい。例えば取得部１１が家計簿サーバ装置３００等の装置からユーザの貯蓄額を取得できない場合にユーザが自身の貯蓄額を申請したとき、口座残高証明書などの信頼に足る証拠があれば信頼度は高いから信用リスクが大きく低減する。一方、例えばユーザの口頭や任意記入での申請であるとか、年収証明等のような直接的な証明ではないものが提出されたケースでは、信頼度は低いとみなし、信用リスクは低減しないか又はその低減量は少なくなる。
【００４９】
［変形例６］
ユーザに対する融資条件及びユーザに提供される特典は、融資金利のほか、融資金額、返済期間、返済方法、融資に関して利用可能なポイント等の、融資に関する条件の全てを含み得る。この場合、信用リスクが低いほど融資条件は緩和され、ユーザにとって有利になる。例えば融資金額は多く、返済期間は長く、返済方法は負担が少なく、ポイントは多くなる。また、融資管理サーバ装置１００は、ユーザに対してはじめて融資を開始するときの融資条件を上記実施形態の手順で決定してもよいし、既に行われている融資においてその融資中に融資条件を変えるときに上記実施形態の手順で融資条件を再決定してもよい。  また、特典は、ユーザに対する融資条件の緩和以外に、例えばユーザへの物品またはサービスのプレゼントであるとか、何らかの金銭的価値があるポイントの付与などであってもよい。
【００５０】
［変形例７］
融資管理サーバ装置１００が支出項目を必要支出項目及び不要支出項目に分類するための支出要否判定条件は、全ユーザについて共通の内容ではなく、或る条件に応じて異ならせてもよい。例えば支出要否判定条件がユーザ属性ごとに異なっていてもよい。ユーザの趣味や興味に応じて支出要否判定条件を異ならせる場合には、例えば映画という支出項目は、映画が趣味であるユーザについては必要支出項目とし、映画が趣味でないユーザについては不要支出項目とする。或いは、映画が趣味であるユーザと映画が趣味でないユーザとで、必要支出項目及び不要支出項目を分類するときの基準額を変えるようにしてもよい。つまり、映画が趣味であるユーザの基準額は映画が趣味でないユーザの基準額よりも高い。また、例えば外食の基準額は、独身男性で年収Ｘ１〜Ｘ２のユーザと、既婚男性で扶養家族Ｙ人で年収Ｘ３〜Ｘ４のユーザとで異ならせるというような例も考えられる。つまり、融資管理サーバ装置１００の記憶部１３は、ユーザ属性及び支出項目ごとに必要支出項目及び不要支出項目のいずれであるかを記憶していることになる。
【００５１】
ユーザ属性に応じて支出要否判定条件を異ならせる場合、そのユーザ属性にはユーザが利用登録しているサービスの利用実績が含まれてもよい。一般に、何らかの有料のサービス（例えば有料の動画配信サービスやプロバイダによるインターネット接続サービス等）を申し込んでいるにもかかわらずそのサービスの利用頻度が少ないユーザは消費行動が浪費の傾向にあると考えることができる。なぜなら、サービスを受けるために支払っている費用を十分に活用していないからである。これを考慮して、支出要否判定条件は、サービスの利用実績が多いユーザについての支出要否判定条件と、サービスの利用実績が少ないユーザについて支出要否判定条件とを含んでおり、前者の支出要否判定条件は後者の支出要否判定条件よりも、同じような支出であっても必要支出項目と判定されやすくする。例えば、前者の支出要否判定条件においては、後者の支出要否判定条件よりも、基準額が高い。融資管理サーバ装置１００は、上記のようなサービスをユーザに提供する装置から、ユーザによるサービスの利用実績に関する情報を取得し、上記のような支出要否判定条件を用いて必要支出項目及び不要支出項目の分類を行う。
【００５２】
ユーザ属性に応じて支出要否判定条件を異ならせる場合、そのユーザ属性にはユーザについて測位された位置に関する属性が含まれてもよい。例えばユーザ属性に住所や勤務先、さらにはその勤務先における残業時間等が含まれている場合、通信装置２００が実装する測位機能によって定期的に測位された位置とユーザの住所や勤務先とを比較し、ユーザによって届け出られた住所や勤務先、その勤務先における残業時間にどの程度信頼性があるかを判断して、その判断結果を支出要否判定条件に反映させてもよい。この場合、支出要否判定条件は、住所や勤務先、残業時間等の場所に関する属性の信頼性が高いユーザについての支出要否判定条件と、住所や勤務先、残業時間等の場所に関する属性の信頼性が低いユーザについての支出要否判定条件とを含んでおり、前者の支出要否判定条件は後者の支出要否判定条件よりも、同じような支出であっても必要支出項目と判定されやすくする。例えば、前者の支出要否判定条件においては、後者の支出要否判定条件よりも、基準額が高い。
【００５３】
［変形例８］
支出要否判定条件が時期に応じて異なっていてもよい。例えば夏季休暇や年末年始休暇がある時期においてはレジャーという支出項目を必要支出項目とし、それ以外の時期はレジャーという支出項目を不要支出項目とする。或いは、必要支出項目及び不要支出項目を分類するときの基準額を変えるようにしてもよい。つまり、夏季休暇や年末年始休暇がある時期におけるレジャーという支出項目の基準額は、夏季休暇や年末年始休暇がない時期におけるレジャーという支出項目の基準額よりも高い。
【００５４】
［変形例９］
支出要否判定条件がユーザの所在場所に応じて異なっていてもよい。例えば寒い地域においては水道光熱費という支出項目の基準額を高くし、温かい地域においては水道光熱費という支出項目の基準額を低くしてもよい。
【００５５】
［変形例１０］
例えば或る支出情報について、図４に例示した支出要否判定条件に含まれないような名称の支出項目が指定されているような場合、その或る支出情報項目をについて必要支出項目を必要支出項目又は及び不要支出項目に分類することができないが、そのような場合には、その支出情報項目を不要支出項目に分類するようにしてもよい。或
【００５６】
［変形例１１］
実施形態において、基準融資金利は、不要支出金額／必要支出金額という数式で算出される支出傾向パラメータの値に応じて決められていたが、次のような決め方であってもよい。例えば、支出傾向パラメータ＝必要支出金額／不要支出金額として、支出傾向パラメータの値が大きいほど基準融資金利を小さくしてもよい。また、支出傾向パラメータ＝不要支出金額／（必要支出金額＋不要支出金額）として、支出傾向パラメータの値が小さいほど基準融資金利を小さくしてもよい。また、支出傾向パラメータ＝（必要支出金額＋不要支出金額）／不要支出金額の値として、支出傾向パラメータの値が大きいほど基準融資金利を小さくしてもよい。要するに、不要支出金額と必要支出金額との関係が、ユーザの消費行動が浪費の傾向にあると考えられる場合には、基準融資金利を高くする。また、融資の目的に応じて、基準融資金利を異ならせてもよい。例えば融資の目的が遊興目的なら基準融資金利を高くし、融資の目的が教育等の将来の投資目的なら基準融資金利を低くする。
【００５７】
［変形例１２］
実施形態において、融資管理サーバ装置１００の取得部１１は支出情報を家計簿サーバ装置３００から取得していたが、支出情報の取得方法はこれに限らない。融資管理サーバ装置１００の取得部１１は、例えばユーザが利用するショッピングＷＥＢサイトや金融機関のＷＥＢサイトから支出情報を取得してもよいし、ユーザによって通信装置１００等に入力された支出情報をその通信装置１００等から取得するようにしてもよい。
【００５８】
［そのほかの変形例］
上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。例えば本発明に係る融資管理サーバ装置は、実施形態で説明したようにそれぞれの機能の全てを一体に備えた装置によっても実現可能であるし、それぞれの装置の機能を、さらに複数の装置に分散して実装した形態であってもよい。
【００５９】
本明細書で説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【００６０】
本明細書で説明した実施形態の処理手順は、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。本明細書で説明した実施形態又は変形例は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【００６１】
本明細書で利用する「システム」及び「ネットワーク」という用語は、互換的に利用される。
【００６２】
本明細書で利用する「判断（determining）」、「決定（determining）」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定（judging）、計算（calculating）、算出（computing）、処理（processing）、導出（deriving）、調査（investigating）、探索（looking up）（例えば、テーブル、データベース又は別のデータ構造での探索）、確認（ascertaining）した事を「判断」「決定」したとみなす事等を含み得る。また、「判断」、「決定」は、受信（receiving）（例えば、情報を受信すること）、送信（transmitting）（例えば、情報を送信すること）、入力（input）、出力（output）、アクセス（accessing）（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事等を含み得る。また、「判断」、「決定」は、解決（resolving）、選択（selecting）、選定（choosing）、確立（establishing）、比較（comparing）等した事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【００６３】
本明細書で利用する「に基づいて」「に応じて」という記載は、別段に明記されていない限り、「のみに基づいて」「のみに応じて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。「応じて」も同様である。また、「含む（including）」、「含んでいる（comprising）」、及びそれらの変形が、本明細書或いは特許請求の範囲で利用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。さらに、本明細書或いは特許請求の範囲において利用されている用語「又は（or）」は、排他的論理和ではないことが意図される。また、本開示の全体において、例えば、英語でのa, an, 及びtheのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
【００６４】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能等を意味するよう広く解釈されるべきである。また、ソフトウェア、命令等は、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）等の有線技術及び／又は赤外線、無線及びマイクロ波等の無線技術を利用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。
【００６５】
「接続された（connected）」、「結合された（coupled）」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。本明細書で利用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及び／又はプリント電気接続を利用することにより、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギー等の電磁エネルギーを利用することにより、互いに「接続」又は「結合」されると考えることができる。
【００６６】
本発明は、融資管理サーバ装置１００が行う情報処理方法、或いは、融資管理サーバ装置１００としてコンピュータを機能させるためのプログラムといった形態でも実施が可能である。かかるプログラムは、光ディスク等の記憶媒体に記憶した形態で提供されたり、インターネット等のネットワークを介して、コンピュータにダウンロードさせ、これをインストールして利用可能にする等の形態で提供されたりすることが可能である。このプログラムは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか又は他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能等を意味するよう広く解釈されるべきである。
【符号の説明】
【００６７】
１…融資管理システム、１００…融資管理サーバ装置、１１…取得部、１２…分類部、１３…決定部、１４…提供部、１５…判断部、１６…付与処理部、１７…記憶部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…補助記憶装置、１０５…通信ＩＦ、２００…通信装置、３００…家計簿サーバ装置、９００…ネットワーク。
【図１】
2018197984.tif 000003
【図２】
2018197984.tif 000004
【図３】
2018197984.tif 000005
【図４】
2018197984.tif 000006
【図５】
2018197984.tif 000007
【図６】
2018197984.tif 000008
【図７】
2018197984.tif 000009
【図８】
2018197984.tif 000010