JP6854191B2 - 情報処理装置 - Google Patents

Description

本発明は、融資条件を決定するための技術に関する。

銀行等の金融機関においては、例えば顧客の年収や金融機関との取引状況等に基づいて、顧客に対する融資条件を決めている。例えば特許文献１の記載された仕組みでは、顧客情報に基づいて顧客の年収を推定し、その年収に基づいて顧客に対する推奨与信枠を決定する。さらに、この推奨与信枠に対して、顧客の世帯情報（例えば、夫婦の年齢差や子供の人数）、居住情報（例えば、居住する都道府県の情報）、及び、今後必要な教育費用に基づいて算出した与信額を加算して、最終的な推奨与信枠を決定している。

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

適正な融資条件を決めるためには、顧客の収入に関する状況のみならず、その顧客の支出に関する状況も考慮することが望ましい。そこで、本発明は、ユーザの支出に関する状況に応じて融資条件を決めることを目的とする。

本発明は、ユーザの支出に関する支出情報を取得する取得部と、前記取得部により取得された支出情報を、支出の必要性が相対的に高い支出に関する第１支出情報と、支出の必要性が相対的に低い支出に関する第２支出情報とに分類する分類部と、必要性が相対的に高い支出と必要性が相対的に低い支出との比率と、融資条件とを対応付けて記憶した記憶部の記憶内容を参照して、前記分類部により分類された前記第１支出情報と前記第２支出情報との比率に基づいて、前記ユーザに対する融資条件を決定する決定部とを備えることを特徴とする情報処理装置を提供する。

前記分類部は、支出項目ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶した記憶部を備え、当該記憶部に記憶されている内容に基づいて前記第１支出情報又は前記第２支出情報に分類するようにしてもよい。

前記分類部が備える前記記憶部は、支出項目及び支出金額ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶しているようにしてもよい。

各々の前記支出項目における支出金額が前記第１支出情報又は前記第２支出情報のいずれであるかが、共通する属性のユーザ群の支出金額の平均に基づいて決められているようにしてもよい。

前記分類部が備える前記記憶部は、ユーザ属性及び支出項目ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶しているようにしてもよい。

前記ユーザ属性には、当該ユーザが利用登録しているサービスの利用実績が含まれるようにしてもよい。

前記ユーザ属性には、当該ユーザについて測位された位置に関する属性が含まれるようにしてもよい。

前記分類部が備える前記記憶部は、支出時期及び支出項目ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶しているようにしてもよい。

本発明によれば、ユーザの支出状況に応じた融資条件を決めることができる。

本発明の一実施形態に係る融資管理システム１の概要を例示するブロック図。 本発明の一実施形態に係る融資管理サーバ装置１００のハードウェア構成を例示するブロック図。 支出情報ＤＢの一例を示す図。 支出要否判定条件の一例を示す図。 融資金利決定条件の一例を示す図。 融資管理サーバ装置１００の機能構成を例示するブロック図。 融資管理サーバ装置１００の動作を示すフローチャート。

［構成］
図１は、本発明の一実施形態に係る融資管理システム１の概要を例示するブロック図である。融資管理システム１は、ユーザに対する融資に関する管理を行う融資管理サーバ装置１００と、ユーザによって操作される通信装置２００と、ユーザの収入、支出及び資産に関する情報を管理する家計簿サイトを運営する家計簿サーバ装置３００とを備えている。これらの装置１００〜３００は、ネットワーク９００によって相互に通信可能となるように接続されている。ネットワーク９００は、無線通信ネットワーク又は有線通信ネットワークを含む。通信装置２００は、例えばスマートホン、タブレット又はパーソナルコンピュータ等のコンピュータ装置である。通信装置２００は、例えばスマートホンであれば、ネットワーク９００の無線基地局と例えばＬＴＥ（Long Term Evolution）等の通信規格の無線通信を行って、融資管理サーバ装置１００及び家計簿サーバ装置３００との間でデータ通信を行う。

家計簿サーバ装置３００は、いわゆるクラウド型の家計簿サービスを提供するコンピュータ装置である。家計簿サーバ装置３００は、例えばユーザが口座を保有する銀行やユーザが契約しているクレジット会社のＷＥＢサイトに代行ログインしてユーザの口座における入金、出金及び残高に関する情報を取得したり、ユーザが利用登録しているショッピングＷＥＢサイトと連携してユーザの買い物に関する情報を取得したり、或いは、通信装置２００と連携してユーザが店舗で買い物したときに受け取ったレシートを光学的に読み取った結果を取得する等の方法により、ユーザの入出金及び資産に関する様々な情報を取得し、これを蓄積する。家計簿サーバ装置３００は、取得した情報を解析することで、家計簿を作成したり、他のユーザがなににいくら使っているかというような統計処理を行ったり、ユーザの口座や財布の残高を計算したりして、その結果を通信装置２００に送信し、表示させる。

図２は、融資管理サーバ装置１００のハードウェア構成を例示するブロック図である。融資管理サーバ装置１００は、本発明に係る情報処理装置の一例であり、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、補助記憶装置１０４、及び通信ＩＦ１０５を有するコンピュータ装置である。ＣＰＵ１０１は、各種の演算を行うプロセッサである。ＲＡＭ１０３は、ＣＰＵ１０１がプログラムを実行する際のワークエリアとして機能する揮発性メモリある。ＲＯＭ１０２は、例えば融資管理サーバ装置１００の起動に用いられるプログラム及びデータを記憶した不揮発性メモリである。補助記憶装置１０４は、例えばＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）等の不揮発性の記憶装置であり、融資管理サーバ装置１００において用いられるプログラム及びデータを記憶する。ＣＰＵ１０１がこのプログラムを実行することにより、融資管理サーバ装置１００において後述する図６に示される機能が実現される。通信ＩＦ１０５は、所定の通信規格に従ってネットワーク９００を介した通信を行う。

補助記憶装置１０４は、融資管理サーバ装置１００が家計簿サーバ装置３００から取得した情報、本実施形態では少なくともユーザの支出に関する支出情報を記憶する。図３は、補助記憶装置１０４に記憶される支出情報データベース（以下、データベースをＤＢという）を例示する図である。図３に示すように、補助記憶装置１０４に記憶される支出情報ＤＢにおいては、各ユーザを識別するユーザＩＤ、各ユーザ属性であるユーザ属性、各ユーザが金銭を支出した支出日時、その支出により購入した商品又はサービスを所定の基準で分類した支出項目、及びその支出金額が対応付けられている。ユーザ属性は、例えばユーザの性別、年齢、住所、趣味乃至興味、家族に関する情報、及び、年収や資産に関する情報が含まれる。これらのユーザ属性は融資管理サーバ装置１００が家計簿サーバ装置３００から取得したものであってもよいし、ユーザから融資管理サーバ装置１００に予め届け出られたものであってもよい。

支出項目は、その支出の属性乃至性格を意味しており、本実施形態では、上位の大項目及び下位の小項目という２階層の構成となっている。大項目は、例えば、食費、水道光熱費、通信費、遊興費、交通費、美容費、医療費、被服費、生活雑貨・日用品費、教育費、交際費、住宅費、保険費、社会保険費、税金等を含む。例えば大項目である遊興費に属する小項目は、外食、レジャー、映画、書籍雑誌、飲み会、その他遊興費等を含む。また、大項目である通信費に属する小項目は、携帯電話、固定電話、インターネット、郵便・宅配便、その他通信費等を含む。

また、補助記憶装置１０４は、ユーザの支出にどの程度の必要性があったのか、つまり支出の要否の程度を判定するための支出要否判定条件を記憶している。図４は支出要否判定条件の一例である。ここでは、支出分類として、前述した支出項目群のうち、支出の必要性が相対的に高いもの（必要支出項目という）と、支出の必要性が相対的に低いもの（不要支出項目という）とを定義する。なお、「不要支出項目」という用語における「不要」とは、支出する必要性が相対的に低いという程度の意味であり、その支出が完全に不要であるという意味ではない。

この必要支出項目及び不要支出項目は、前述した支出項目の大項目又は小項目ごとに定義される。さらに、１つの支出項目のうち、或る基準額以内は必要支出項目であるが、その基準額を超えると不要支出項目となる場合もある。例えば小項目として上記に例示したもののうち、遊興費という大項目に属する小項目群は、外食及び書籍雑誌という小項目を除いて、支出金額に関わらず不要支出項目である。ただし、外食は、１ヶ月に３０００円以内であれば必要支出項目であり、１ヶ月に３０００円を超えると、その超過額が不要支出項目となる。また、書籍雑誌は、１ヶ月に２０００円以内であれば必要支出項目であるが、１ヶ月に２０００円を超えると、その超過額が不要支出項目となる。また、通信費という大項目に属する小項目群は、携帯電話という小項目を除いて、必要支出項目である。ただし、携帯電話は、１ヶ月に１２０００円以内であれば必要支出項目であるが、１ヶ月に１２０００円を超えると、その超過額が不要支出項目となる。

ここで、各支出項目の基準額は、本システムを利用するユーザ群が各支出項目に支出した金額の平均値に基づいて決められている。図４の例で言うと、例えば全ユーザの１ヶ月あたりの外食の平均値は３０００円であるし、例えば全ユーザの１ヶ月あたりの携帯電話の支払いの平均値は１２０００円である。前述したように、各ユーザがなににいくら使っているかというような家計簿サーバ装置３００の統計処理は周知なので、この統計処理の結果に基づいて決められた基準額が支出要否判定条件として用いられる。また、融資管理サーバ装置１００自身が、支出情報ＤＢの内容に基づいて上記のような統計処理を行って基準額を求め、支出要否判定条件として用いてもよい。

また、補助記憶装置１０４は、ユーザに対する融資条件の１つである融資利率を決定するための融資金利判定条件を記憶している。図５は融資金利判定条件の一例である。融資金利判定条件においては、１のユーザの不要支出項目の支出金額の総額（不要支出金額という）を必要支出項目の支出金額の総額（必要支出金額という）で除算した値と、そのユーザに対する基準融資金利とが対応付けられている。不要支出金額／必要支出金額は、ユーザの支出における傾向（ここではユーザの支出における不要支出の傾向）を表すパラメータであるから、以下、支出傾向パラメータという。この支出傾向パラメータの値が大きいほど、支出の必要性が相対的に高いものに対する支出の必要性が相対的に低いものの割合が大きいから、ユーザの消費行動は浪費の傾向にあると考えられる。ここで、融資を受けたユーザの浪費傾向と、そのユーザによる返済が滞る危険性（以下、信用リスクという）の大きさは相関関係にあるとの前提で、浪費傾向が認められるほど信用リスクが大きくなると想定する。そして、その信用リスクの増大に見合うように基準融資金利を高くしている。一方、支出傾向パラメータの値が小さいほど、ユーザの消費行動が節約の傾向にあると言える。よって、節約傾向が認められるほど信用リスクが小さくなると想定して基準融資金利を低くしている。なお、これら支出傾向パラメータの具体的な値及び基準融資金利の具体的な値は、融資する側（つまり融資管理サーバ装置１００の運営者）によって任意に決められる。

図６は、融資管理サーバ装置１００の機能構成を例示するブロック図である。取得部１１は融資管理サーバ装置１００の通信ＩＦ１０５によって実現され、分類部１２は融資管理サーバ装置１００のＣＰＵ１０１及び補助記憶装置１０４によって実現され、記憶部１３は融資管理サーバ装置１００の補助記憶装置１０４によって実現され、決定部１４は融資管理サーバ装置１００のＣＰＵ１０１及び補助記憶装置１０４によって実現され、提示部１５は融資管理サーバ装置１００の通信ＩＦ１０５によって実現される。

取得部１１は、ユーザの支出に関する支出情報を、例えば家計簿サーバ装置３００から取得する。分類部１２は、取得部１１により取得された支出情報を、支出の必要性が相対的に高い支出に関する必要支出情報（本発明に係る第１支出情報）と、支出の必要性が相対的に低い支出に関する不要支出情報（本発明に係る第２支出情報）とに分類する。この分類部１２は、支出項目ごとにその支出が必要支出情報又は不要支出情報のいずれであるかを記憶した記憶部１３を備えており、その記憶部１３に記憶されている内容に基づいて、ユーザの支出情報を必要支出情報又は不要支出情報に分類する。記憶部１３は、支出項目及び支出金額ごとに必要支出情報又は不要支出情報のいずれであるかを記憶している。決定部１４は、分類部１２により分類された結果に基づいて、ユーザに対する融資条件（ここでは融資金利）を決定する。提示部１５は、決定部１４により決定された融資条件を例えば通信装置２００に送信する等して、ユーザに提示する。

［動作］
図７は、融資管理サーバ装置１００の動作を例示するフローチャートである。図７において、例えばユーザから融資申し込みがある等して融資条件を決定する時期が到来すると、融資管理サーバ装置１００の取得部１１は、融資条件決定対象となるユーザのユーザＩＤに対応する支出情報を家計簿サーバ装置３００から取得し、補助記憶装置１０４内の支出情報ＤＢに記憶する（ステップＳ１１）。この支出情報は例えば過去１２か月分とか過去６か月分等の、過去の所定期間におけるユーザの支出に関する情報である。

次に、融資管理サーバ装置１００の分類部１２は、記憶部１３に記憶されている支出要否判定条件に基づいて、上記支出情報を必要支出情報（第１支出情報）と不要支出情報（第２支出情報）とに分類する（ステップＳ１２）。

次に、融資管理サーバ装置１００の決定部１４は、分類部１２により分類された結果に基づいて、支出傾向パラメータ（つまり不要支出情報／必要支出情報）の値を算出し、融資金利判定条件に従って基準融資金利を特定する。そして、決定部１４は、この基準融資金利に対して必要に応じた加減算を行い（例えばユーザの年収や資産に基づく優遇金利幅を減算する等）、ユーザに対する最終的な融資金利を含む融資条件を決定する（ステップＳ１３）。

そして、融資管理サーバ装置１００の提示部１５は、決定した融資条件を例えば通信装置２００に送信する等して、ユーザに提示する（ステップＳ１４）。

本実施形態によれば、ユーザの支出に関して、支出の必要性が相対的に高い必要支出項目と支出の必要性が相対的に低い不要支出項目とに分類し、これら両者の関係に基づいて融資条件を決めることが可能となる。このとき、必要支出項目及び不要支出項目を支出項目ごとに定義し、さらに、１つの支出項目において基準額を基準として必要支出項目であるか不要支出項目であるかを定義するので、支出の必要性についてよりきめ細やかに分類することができる。

［変形例］
本発明は上述の実施形態に限定されるものではなく、種々の変形実施が可能である。以下、変形例をいくつか説明する。以下の変形例のうち２つ以上のものが組み合わせて用いられてもよい。

［変形例１］
融資管理サーバ装置１００が支出項目を必要支出項目及び不要支出項目に分類するための支出要否判定条件は、全ユーザについて共通の内容ではなく、或る条件に応じて異ならせてもよい。例えば支出要否判定条件がユーザ属性ごとに異なっていてもよい。ユーザの趣味や興味に応じて支出要否判定条件を異ならせる場合には、例えば映画という支出項目は、映画が趣味であるユーザについては必要支出項目とし、映画が趣味でないユーザについては不要支出項目とする。或いは、映画が趣味であるユーザと映画が趣味でないユーザとで、必要支出項目及び不要支出項目を分類するときの基準額を変えるようにしてもよい。つまり、映画が趣味であるユーザの基準額は映画が趣味でないユーザの基準額よりも高い。また、例えば外食の基準額は、独身男性で年収Ｘ１〜Ｘ２のユーザと、既婚男性で扶養家族Ｙ人で年収Ｘ３〜Ｘ４のユーザとで異ならせるというような例も考えられる。つまり、融資管理サーバ装置１００の記憶部１３は、ユーザ属性及び支出項目ごとに必要支出項目及び不要支出項目のいずれであるかを記憶していることになる。

ユーザ属性に応じて支出要否判定条件を異ならせる場合、そのユーザ属性にはユーザが利用登録しているサービスの利用実績が含まれてもよい。一般に、何らかの有料のサービス（例えば有料の動画配信サービスやプロバイダによるインターネット接続サービス等）を申し込んでいるにもかかわらずそのサービスの利用頻度が少ないユーザは消費行動が浪費の傾向にあると考えることができる。なぜなら、サービスを受けるために支払っている費用を十分に活用していないからである。これを考慮して、支出要否判定条件は、サービスの利用実績が多いユーザについての支出要否判定条件と、サービスの利用実績が少ないユーザについて支出要否判定条件とを含んでおり、前者の支出要否判定条件は後者の支出要否判定条件よりも、同じような支出であっても必要支出項目と判定されやすくする。例えば、前者の支出要否判定条件においては、後者の支出要否判定条件よりも、基準額が高い。融資管理サーバ装置１００は、上記のようなサービスをユーザに提供する装置から、ユーザによるサービスの利用実績に関する情報を取得し、上記のような支出要否判定条件を用いて必要支出項目及び不要支出項目の分類を行う。

ユーザ属性に応じて支出要否判定条件を異ならせる場合、そのユーザ属性にはユーザについて測位された位置に関する属性が含まれてもよい。例えばユーザ属性に住所や勤務先、さらにはその勤務先における残業時間等が含まれている場合、通信装置２００が実装する測位機能によって定期的に測位された位置とユーザの住所や勤務先とを比較し、ユーザによって届け出られた住所や勤務先、その勤務先における残業時間にどの程度信頼性があるかを判断して、その判断結果を支出要否判定条件に反映させてもよい。この場合、支出要否判定条件は、住所や勤務先、残業時間等の場所に関する属性の信頼性が高いユーザについての支出要否判定条件と、住所や勤務先、残業時間等の場所に関する属性の信頼性が低いユーザについての支出要否判定条件とを含んでおり、前者の支出要否判定条件は後者の支出要否判定条件よりも、同じような支出であっても必要支出項目と判定されやすくする。例えば、前者の支出要否判定条件においては、後者の支出要否判定条件よりも、基準額が高い。

［変形例２］
支出要否判定条件が時期に応じて異なっていてもよい。例えば夏季休暇や年末年始休暇がある時期においてはレジャーという支出項目を必要支出項目とし、それ以外の時期はレジャーという支出項目を不要支出項目とする。或いは、必要支出項目及び不要支出項目を分類するときの基準額を変えるようにしてもよい。つまり、夏季休暇や年末年始休暇がある時期におけるレジャーという支出項目の基準額は、夏季休暇や年末年始休暇がない時期におけるレジャーという支出項目の基準額よりも高い。

［変形例３］
支出要否判定条件がユーザの所在場所に応じて異なっていてもよい。例えば寒い地域においては水道光熱費という支出項目の基準額を高くし、温かい地域においては水道光熱費という支出項目の基準額を低くしてもよい。

［変形例４］
例えば或る支出情報について、図４に例示した支出要否判定条件に含まれないような名称の支出項目が指定されているような場合、その支出情報を必要支出項目又は不要支出項目に分類することができないが、そのような場合には、その支出情報を不要支出項目に分類するようにしてもよい。

［変形例５］
図７のステップＳ１３にて決定する融資条件は、融資金利のほか、融資金額、返済期間、返済方法、融資に関して利用可能なポイント等の、融資に関する条件の全てを含み得る。この場合、前述した支出傾向パラメータが貸し倒れリスクの低いことを意味するほど融資条件は緩和され、ユーザにとって有利になる。融資条件が緩和されると、例えば融資金額は多く、返済期間は長く、返済方法は負担が少なく、ポイントは多くなる。また、融資管理サーバ装置１００は、ユーザに対してはじめて融資を開始するときの融資条件を上記実施形態の手順で決定してもよいし、既に行われている融資においてその融資中に融資条件を変えるときに上記実施形態の手順で融資条件を再決定してもよい。

［変形例６］
実施形態において、基準融資金利は、不要支出金額／必要支出金額という数式で算出される支出傾向パラメータの値に応じて決められていたが、次のような決め方であってもよい。例えば、支出傾向パラメータ＝必要支出金額／不要支出金額として、支出傾向パラメータの値が大きいほど基準融資金利を小さくしてもよい。また、支出傾向パラメータ＝不要支出金額／（必要支出金額＋不要支出金額）として、支出傾向パラメータの値が小さいほど基準融資金利を小さくしてもよい。また、支出傾向パラメータ＝（必要支出金額＋不要支出金額）／不要支出金額の値として、支出傾向パラメータの値が大きいほど基準融資金利を小さくしてもよい。要するに、不要支出金額と必要支出金額との関係が、ユーザの消費行動が浪費の傾向にあると考えられる場合には、基準融資金利を高くする。
また、融資の目的に応じて、基準融資金利を異ならせてもよい。例えば融資の目的が遊興目的なら基準融資金利を高くし、融資の目的が教育等の将来の投資目的なら基準融資金利を低くする。
さらに、図７のステップＳ１２において不要支出金額であると分類された不要支出項目と、融資の目的との関連度に応じて、基準融資金利を変動させてもよい。例えば食費が不要支出項目と判定された場合に、融資の目的がその食費と関連度が高い「食費の補充」という目的であった場合には、基準融資金利を高くするということが考えられる。また、図７のステップＳ１２において必要支出金額であると分類された必要支出項目と、融資の目的との関連度に応じて、基準融資金利を変動させてもよい。例えば食費が必要支出項目と判定された場合に、融資の目的がその食費と関連度が高い「食費の補充」という目的であった場合には、基準融資金利を低くするということが考えられる。

［変形例７］
実施形態において、融資管理サーバ装置１００の取得部１１は支出情報を家計簿サーバ装置３００から取得していたが、支出情報の取得方法はこれに限らない。融資管理サーバ装置１００の取得部１１は、例えばユーザが利用するショッピングＷＥＢサイトや金融機関のＷＥＢサイトから支出情報を取得してもよいし、ユーザによって通信装置１００等に入力された支出情報をその通信装置１００等から取得するようにしてもよい。

［そのほかの変形例］
上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。例えば本発明に係る融資管理サーバ装置は、実施形態で説明したようにそれぞれの機能の全てを一体に備えた装置によっても実現可能であるし、それぞれの装置の機能を、さらに複数の装置に分散して実装した形態であってもよい。

本明細書で説明した各態様／実施形態は、ＬＴＥ（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）」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。本明細書で利用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及び／又はプリント電気接続を利用することにより、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギー等の電磁エネルギーを利用することにより、互いに「接続」又は「結合」されると考えることができる。

本発明は、融資管理サーバ装置１００が行う情報処理方法、或いは、融資管理サーバ装置１００としてコンピュータを機能させるためのプログラムといった形態でも実施が可能である。かかるプログラムは、光ディスク等の記憶媒体に記憶した形態で提供されたり、インターネット等のネットワークを介して、コンピュータにダウンロードさせ、これをインストールして利用可能にする等の形態で提供されたりすることが可能である。このプログラムは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか又は他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能等を意味するよう広く解釈されるべきである。

１…融資管理システム、１００…融資管理サーバ装置、１１…取得部、１２…分類部、１３…記憶部、１４…決定部、１５…提示部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…補助記憶装置、１０５…通信ＩＦ、２００…通信装置、３００…家計簿サーバ装置、９００…ネットワーク。

Claims (8)

1. ユーザの支出に関する支出情報を取得する取得部と、
   前記取得部により取得された支出情報を、支出の必要性が相対的に高い支出に関する第１支出情報と、支出の必要性が相対的に低い支出に関する第２支出情報とに分類する分類部と、
   必要性が相対的に高い支出と必要性が相対的に低い支出との比率と、融資条件とを対応付けて記憶した記憶部の記憶内容を参照して、前記分類部により分類された前記第１支出情報と前記第２支出情報との比率に基づいて、前記ユーザに対する融資条件を決定する決定部と
   を備えることを特徴とする情報処理装置。
2. 前記分類部は、支出項目ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶した記憶部を備え、当該記憶部に記憶されている内容に基づいて前記第１支出情報又は前記第２支出情報に分類する
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記分類部が備える前記記憶部は、支出項目及び支出金額ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶している
   ことを特徴とする請求項２記載の情報処理装置。
4. 各々の前記支出項目における支出金額が前記第１支出情報又は前記第２支出情報のいずれであるかが、共通する属性のユーザ群の支出金額の平均に基づいて決められている
   ことを特徴とする請求項３記載の情報処理装置。
5. 前記分類部が備える前記記憶部は、ユーザ属性及び支出項目ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶している
   ことを特徴とする請求項２〜４のいずれかに記載の情報処理装置。
6. 前記ユーザ属性には、当該ユーザが利用登録しているサービスの利用実績が含まれる
   ことを特徴とする請求項５に記載の情報処理装置。
7. 前記ユーザ属性には、当該ユーザについて測位された位置に関する属性が含まれる
   ことを特徴とする請求項５又は６に記載の情報処理装置。
8. 前記分類部が備える前記記憶部は、支出時期及び支出項目ごとに当該支出が前記第１支出情報又は前記第２支出情報のいずれであるかを記憶している
   ことを特徴とする請求項２〜７のいずれかに記載の情報処理装置。

Images