(57)【要約】【課題】個人の信用度を適切に判定すること。【解決手段】本願に係る判定装置は、取得部と、判定部とを備える。取得部は、ユーザのネットワーク上における行動履歴を取得する。判定部は、取得部によって取得された行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する。例えば、判定装置は、取得部によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成し、生成されたモデルを利用して、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する。【選択図】図１
2018045573.tif 000002
【特許請求の範囲】
【請求項１】
ユーザのネットワーク上における行動履歴を取得する取得部と、
前記取得部によって取得された行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する判定部と、
を備えたことを特徴とする判定装置。
【請求項２】
前記取得部によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成する生成部、をさらに備え、
前記判定部は、
前記生成部によって生成されたモデルを利用して、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する、
ことを特徴とする請求項１に記載の判定装置。
【請求項３】
前記取得部は、
前記ネットワーク上における行動履歴として、前記ユーザが検索サービスに送信した検索クエリに関する情報、当該ユーザの所定のサービスページの閲覧履歴、又は、所定のサービスにおける当該ユーザの購買履歴の少なくともいずれか一つを取得し、
前記生成部は、
前記ユーザが検索サービスに送信した検索クエリに関する情報、当該ユーザの所定のサービスページの閲覧履歴、又は、所定のサービスにおける当該ユーザの購買履歴の少なくともいずれか一つに基づいて、前記モデルを生成する、
ことを特徴とする請求項２に記載の判定装置。
【請求項４】
前記生成部は、
前記所定の金融サービスを契約中のユーザであって、当該所定の金融サービスの利用率が所定の閾値よりも低いユーザの行動履歴に基づいて、前記モデルを生成する、
ことを特徴とする請求項３に記載の判定装置。
【請求項５】
前記生成部は、
前記所定の金融サービスのうち、所定のポイントをユーザに付与するシステムを有する金融サービスに関するモデルを生成する、
ことを特徴とする請求項２〜４のいずれか一つに記載の判定装置。
【請求項６】
前記生成部は、
サービス加入時に所定のポイントがユーザに付与されるシステムを有する前記金融サービスに関するモデルを生成する、
ことを特徴とする請求項５に記載の判定装置。
【請求項７】
前記取得部は、
前記行動履歴を取得したユーザの属性情報をさらに取得し、
前記生成部は、
前記ユーザの属性情報に基づいて前記モデルを生成する、
ことを特徴とする請求項２〜６のいずれか一つに記載の判定装置。
【請求項８】
前記取得部は、
前記ネットワーク上における行動履歴として、前記ユーザが利用するＳＮＳ（Social  Networking  Service）に関する情報を取得し、
前記生成部は、
前記ユーザが利用するＳＮＳに関する情報に基づいて、前記モデルを生成する、
ことを特徴とする請求項２〜７のいずれか一つに記載の判定装置。
【請求項９】
前記判定部は、
前記ユーザに対する信用度を判定するとともに、当該信用度に応じて、当該ユーザが前記所定の金融サービスを利用する場合のサービス内容を判定する、
ことを特徴とする請求項１〜８のいずれか一つに記載の判定装置。
【請求項１０】
前記判定部は、
前記所定の金融サービスを利用する場合のサービス内容として、当該所定の金融サービスにユーザが加入する場合の特典、当該所定の金融サービスをユーザが利用する場合の金利、又は、当該所定の金融サービスをユーザが利用する場合の融資額もしくは限度額、の少なくとも一つに関する内容を判定する、
ことを特徴とする請求項９に記載の判定装置。
【請求項１１】
前記判定部は、
前記ユーザに対する信用度を判定するとともに、当該信用度に応じて、当該ユーザに対して前記所定の金融サービスを宣伝するために掛けるコストを判定する、
ことを特徴とする請求項１〜１０のいずれか一つに記載の判定装置。
【請求項１２】
コンピュータが実行する判定方法であって、
ユーザのネットワーク上における行動履歴を取得する取得工程と、
前記取得工程によって取得された行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する判定工程と、
を含んだことを特徴とする判定方法。
【請求項１３】
ユーザのネットワーク上における行動履歴を取得する取得手順と、
前記取得手順によって取得された行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する判定手順と、
をコンピュータに実行させることを特徴とする判定プログラム。
【請求項１４】
ユーザのネットワーク上における行動履歴を取得する取得部と、
前記取得部によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成する生成部と、
を備えたことを特徴とする生成装置。
【請求項１５】
コンピュータが実行する判定方法であって、
ユーザのネットワーク上における行動履歴を取得する取得工程と、
前記取得工程によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成する生成工程と、
を含んだことを特徴とする生成方法。
【請求項１６】
ユーザのネットワーク上における行動履歴を取得する取得手順と、
前記取得手順によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成する生成手順と、
をコンピュータに実行させることを特徴とする生成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、判定装置、判定方法、判定プログラム、生成装置、生成方法及び生成プログラムに関する。
【背景技術】
【０００２】
近年、通信ネットワークの発達とともに、様々なサービスがネットワークを介して提供されている。ネットワークを介したサービスの一例として、企業や個人への融資や、クレジットカードの発行などの金融関係のサービスが挙げられる。
【０００３】
例えば、クレジットカードの決済に関する技術として、決済額の多寡に関わらず、携帯型情報処理装置及び店舗端末を用いてクレジットカード決済の与信審査を行うことができる与信審査システムが知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−２４６５８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の従来技術では、個人の信用度を適切に判定できない場合がある。具体的には、上記の従来技術は、発行されたクレジットカードに関するカード情報に基づいて与信を判定するため、例えば、個人に対してクレジットカードを新たに発行するにあたり当該個人の信用度を判定する場合などには、上記技術が適用できない場合がある。
【０００６】
本願は、上記に鑑みてなされたものであって、個人の信用度を適切に判定することができる判定装置、判定方法、判定プログラム、生成装置、生成方法及び生成プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願に係る判定装置は、ユーザのネットワーク上における行動履歴を取得する取得部と、前記取得部によって取得された行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する判定部と、を備えたことを特徴とする。
【発明の効果】
【０００８】
実施形態の一態様によれば、個人の信用度を適切に判定することができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施形態に係る判定処理の一例を示す図である。
【図２】図２は、実施形態に係る判定システムの構成例を示す図である。
【図３】図３は、実施形態に係る判定装置の構成例を示す図である。
【図４】図４は、実施形態に係るユーザ情報記憶部の一例を示す図である。
【図５】図５は、実施形態に係る属性情報テーブルの一例を示す図である。
【図６】図６は、実施形態に係る行動情報テーブルの一例を示す図である。
【図７】図７は、実施形態に係るモデル記憶部の一例を示す図である。
【図８】図８は、実施形態に係る条件情報記憶部の一例を示す図である。
【図９】図９は、実施形態に係る処理手順を示すフローチャート（１）である。
【図１０】図１０は、実施形態に係る処理手順を示すフローチャート（２）である。
【図１１】図１１は、判定装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。
【発明を実施するための形態】
【００１０】
以下に、本願に係る判定装置、判定方法、判定プログラム、生成装置、生成方法及び生成プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る判定装置、判定方法、判定プログラム、生成装置、生成方法及び生成プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【００１１】
〔１．実施形態に係る判定処理の一例〕
まず、図１を用いて、実施形態に係る判定処理の一例について説明する。図１は、実施形態に係る判定処理の一例を示す図である。図１では、判定装置１００が、ネットワークを介してユーザの情報を取得し、取得した情報に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する処理の一例を示す。
【００１２】
図１に示す判定装置１００は、処理対象とするユーザについて、所定の金融サービスに対する信用度を判定するサーバ装置である。判定装置１００は、ユーザが利用する端末から所定の情報を取得し、取得した情報に基づいて、ユーザの信用度を判定する処理を行う。
【００１３】
図１に示すユーザ端末１０１は、ユーザＵ０１によって利用される情報処理端末である。また、ユーザ端末１０２は、ユーザＵ０２によって利用される情報処理端末である。例えば、ユーザ端末１０１及び１０２は、スマートフォンやタブレット端末等によって実現される。なお、以下の説明において、ユーザ端末１０１及び１０２を区別する必要のないときは、総称してユーザ端末１０と表記する。また、以下の説明では、ユーザ端末をユーザと置き換えて表記する場合がある。例えば、「ユーザＵ０１が所定の情報を判定装置１００に送信する」と表記した場合、「ユーザＵ０１の操作に従うユーザ端末１０１が所定の情報を判定装置１００に送信する」ことを意味する場合がある。
【００１４】
実施形態において、判定装置１００は、ユーザ端末１０１及び１０２からユーザ情報を取得する。ユーザ情報とは、ユーザ端末１０１及び１０２に保持される情報であり、例えば、ユーザＵ０１及びユーザＵ０２のネットワーク上の行動履歴や、ユーザＵ０１及びユーザＵ０２の属性情報を含む。ネットワーク上の行動履歴とは、例えば、インターネット上においてユーザＵ０１又はユーザＵ０２が行った操作履歴である。具体的には、ネットワーク上の行動履歴とは、検索サービスにおいてユーザＵ０１又はユーザＵ０２が送信した検索クエリの履歴や、ウェブサイトの閲覧履歴や、ユーザＵ０１又はユーザＵ０２が利用するＳＮＳ（Social  Networking  Service）に記事や画像を投稿した履歴等を含む。また、属性情報とは、年齢や性別、居住地、年収、配偶者の有無といった、ユーザの属性を示す情報である。
【００１５】
図１の例では、判定装置１００は、所定の金融サービスを新たに利用しようとするユーザＵ０２の信用度を判定する。具体的には、判定装置１００は、クレジットカード（以下、単に「カード」と表記する場合がある）の新規発行をユーザＵ０２が申し込む場合に、当該クレジットカードの新規発行に関する審査におけるユーザＵ０２の信用度を判定する。
【００１６】
ここで、図１の例では、ユーザＵ０１は、ユーザＵ０２が申し込もうとするカードの発行を受け、既にカードに関するサービスを利用しているユーザであるとする。そして、ユーザＵ０１は、カードを積極的に利用しないユーザ、すなわち、サービスにとってのいわゆるネガティブユーザであるものとする。
【００１７】
例えば、カードサービスにおけるネガティブユーザには、カードの新規発行を受けたにもかかわらず、当該カードを買い物等に利用しないユーザが含まれる。例えば、カード会社は、カードの新規発行に際して、ユーザが現金の代わりに使用することのできるポイントを付与するといった特典を設けることがある。ネガティブユーザは、例えば、新規発行のポイントのみを受け取り、その後、受け取ったポイントを使用するのみで、発行されたカードは使用しないユーザ等である。なお、ネガティブユーザには、例えば、カード発行以外にも、保険などの金融サービスにおいて、見積もり依頼のみを申込んで特典を手に入れたり、カード切り替えの依頼やパンフレット送付の依頼のみを申込んで特典を手に入れたりするようなユーザも含まれる。
【００１８】
この場合、カード会社は、カード利用による収入を得られないばかりか、ポイント付与に関する費用、ユーザを加入させるために費やした広告宣伝費、カードの発行やカードの送付など、種々の費用を回収できないことになる。すなわち、金融サービスを提供する事業者は、ネガティブユーザを加入させることによって不利益を被る場合がある。
【００１９】
このため、金融サービスを提供する事業者にとっては、ネガティブユーザを加入させないこと、また、将来的にネガティブユーザになる可能性が高いユーザに対して宣伝広告費等を極力費やさないことが重要となる。すなわち、金融サービスを提供する事業者は、どのようなユーザがネガティブユーザとなりえるのかを判定し、ネガティブユーザとなる可能性の高いユーザと、ネガティブユーザにならない可能性の高いユーザとで対応を変えることが望ましい。
【００２０】
そこで、実施形態に係る判定装置１００は、サービスを既に利用しているユーザであって、ネガティブユーザであるユーザＵ０１の行動履歴と、サービスを現時点で利用していないユーザＵ０２の行動履歴とを比較することで、当該サービスに対するユーザＵ０２の信用度を判定する。より具体的には、判定装置１００は、ユーザＵ０２がユーザＵ０１と同じようにネガティブユーザになる可能性の高いユーザであるか否かを判定する。これにより、判定装置１００は、金融サービスのユーザ加入に関する処理を効率良く行うことができる。以下、かかる判定処理について、図１を用いて流れに沿って説明する。なお、図１の例では、説明を簡単にするため、判定装置１００自身が、カード発行に係る金融サービスを提供しているものとする。
【００２１】
図１に示す例において、判定装置１００は、ユーザ端末１０１からユーザＵ０１に関する情報を取得する（ステップＳ０１）。例えば、判定装置１００は、ユーザＵ０１に関する情報として、ユーザＵ０１の属性情報や、ユーザＵ０１のネットワーク上の行動履歴を取得する。判定装置１００は、ユーザに関する情報（以下、「ユーザ情報」と表記する場合がある）を記憶するユーザ情報記憶部１２１や、ユーザ情報記憶部１２１に含まれるデータテーブルである属性情報テーブル１２２や行動情報テーブル１２３に格納する。
【００２２】
なお、判定装置１００は、ユーザＵ０１のカード利用の状況から、予めユーザＵ０１をネガティブユーザと判定しているものとする。例えば、判定装置１００は、判定装置１００の管理者によって作成されたブラックリスト等の情報から、ユーザＵ０１をネガティブユーザと判定するものとする。
【００２３】
続いて、判定装置１００は、ユーザＵ０１を正例として、ネガティブユーザに関する機械学習を行う（ステップＳ０２）。すなわち、判定装置１００は、ユーザＵ０１を正例として、ユーザＵ０１に類似するユーザを判定するためのモデルを生成する。言い換えれば、判定装置１００は、ユーザＵ０１に類似すると判定されるユーザほど信用度を低く判定し、ユーザＵ０１に類似しないと判定されるユーザほど信用度を高く判定するようなモデルを生成する。
【００２４】
例えば、判定装置１００は、ユーザＵ０１の属性情報やネットワーク上の行動履歴と、新たにモデルに入力される属性情報やネットワーク上の行動履歴とが、どのくらい関係性を有するかといった指標値を出力するモデルを生成する。なお、図１での図示は省略するが、判定装置１００は、ユーザＵ０１のみならず、モデルが出力する指標値に一定の信頼性を与えるのに充分な所定サンプル量（例えば、２０００以上の数のユーザなど）を取得し、モデルを生成するものとする。
【００２５】
かかるモデルを利用することにより、判定装置１００は、新たにサービスを申し込んだユーザや、サービス加入を促す広告を判定する対象となるユーザの行動履歴に基づいて、当該ユーザがネガティブユーザになる可能性が高いか否かといった判定を行うことができる。すなわち、判定装置１００は、正例となるユーザが現時点で利用しているサービスにおいて、新たなユーザがネガティブユーザになる可能性が高いほど、当該新たなユーザの信用度を低く判定し、新たなユーザがネガティブユーザになる可能性が低いほど、当該新たなユーザの信用度を高く判定する。判定装置１００は、生成したモデルをモデル記憶部１２４に記憶する。
【００２６】
その後、判定装置１００は、ユーザ端末１０２から、ユーザＵ０２に関する情報を取得するものとする（ステップＳ０３）。例えば、判定装置１００は、ユーザ端末１０２からカードの新規発行の申し込みを受け付けたことを契機として、ユーザＵ０２に関する情報を取得する。なお、図１におけるユーザＵ０２に関する情報は、ユーザ情報記憶部１２１に入力され、かつ、モデル記憶部１２４にも入力されることを示している。
【００２７】
判定装置１００は、モデルを用いて、ユーザＵ０２の信用度を判定する（ステップＳ０４）。具体的には、判定装置１００は、ユーザＵ０２に関する情報をステップＳ０２で生成したモデルに入力する。そして、判定装置１００は、ユーザＵ０２に関する情報が、当該サービスにおいてネガティブユーザと判定されたユーザ群の情報と、どのくらい関係性を有するか（どのくらい類似しているか）といった情報を示す指標値を出力する。判定装置１００は、かかる指標値に基づいて、当該サービスにおけるユーザＵ０２の信用度を判定する。
【００２８】
そして、判定装置１００は、判定結果に基づいて、カード発行の審査に関する結果をユーザＵ０２に通知する（ステップＳ０５）。例えば、判定装置１００は、ユーザＵ０２の信用度が第１の閾値よりも高ければ、カード発行時のポイントを満額付与する条件で、ユーザＵ０２へのカード発行を許可する。あるいは、判定装置１００は、ユーザＵ０２の信用度が第１の閾値よりも低く第２の閾値よりも高ければ、カード発行は許可するものの、発行時のポイントを５割減額する条件に変更する。あるいは、判定装置１００は、ユーザＵ０２の信用度が第２の閾値よりも低ければ、カード発行を許可しないようにしてもよい。このように、判定装置１００は、ユーザＵ０２に対して判定した信用度に基づいて、種々の対応を採り得る。
【００２９】
このように、実施形態に係る判定装置１００は、ユーザＵ０１及びユーザＵ０２のネットワーク上における行動履歴を取得する。そして、判定装置１００は、取得されたユーザＵ０１及びユーザＵ０２の行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザＵ０２に対する信用度を判定する。
【００３０】
すなわち、実施形態に係る判定装置１００は、いわゆるネガティブユーザなど、実際に稼働しているサービスにおいて不利益となっているユーザの行動履歴を正例として、新たにサービスを利用しようとするユーザを判定する。一般に、金融サービスにおいては、サービスの申込み時点で申込み者の年収や勤務先等に基づいて審査を行う。しかし、例えばポイントのみを目的に多数のカードを契約するようなネガティブユーザを、年収や勤務先等で判断することは困難である。これに対して、判定装置１００は、ネットワーク上の行動履歴を判定要素とする。ここで、ネガティブユーザは、無償でポイントが付与されるサイトや、特典を得られる保険業者のサイト等を閲覧したり、そのようなサービスを検索していたりする可能性が高いと想定される。このため、判定装置１００によれば、例えばユーザＵ０１の行動履歴とユーザＵ０２の行動履歴とを比較することで、サービスに加入する前の時点において、新たにサービスに加入するユーザＵ０２が、将来的にネガティブユーザになる可能性が高いか否かを精度よく判定することができる。すなわち、判定装置１００は、金融サービスにおいて、個人の信用度を適切に判定することができる。
【００３１】
なお、図１の例において、判定装置１００は、ユーザ端末１０１及び１０２からユーザＵ０１及びユーザＵ０２のユーザ情報を取得することを示した。判定装置１００は、例えば、所定時間置きにユーザ端末１０１及び１０２をクロール（crawl）することにより、ユーザ情報を取得するようにしてもよい。また、判定装置１００は、ユーザ端末１０にインストールされたプログラム（例えば、スマートフォン専用のアプリ）を介して、ユーザ情報を継続的に取得するようにしてもよい。
【００３２】
〔２．判定システムの構成〕
次に、図２を用いて、実施形態に係る判定装置１００が含まれる判定システム１の構成について説明する。図２は、実施形態に係る判定システム１の構成例を示す図である。図２に例示するように、実施形態に係る判定システム１には、ユーザ端末１０と、ウェブサーバ３０と、判定装置１００とが含まれる。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。また、図２に示す判定システム１に含まれる各装置の数は図示したものに限られない。例えば、判定システム１には、複数台のユーザ端末１０や、ウェブサーバ３０が含まれてもよい。
【００３３】
ユーザ端末１０は、上述のように、スマートフォンを含む携帯電話機や、タブレット端末や、デスクトップ型ＰＣ（Personal  Computer）や、ノート型ＰＣや、ＰＤＡ（Personal  Digital  Assistant）等の情報処理端末である。また、ユーザ端末１０には、眼鏡型や時計型の情報処理端末であるウェアラブルデバイス（wearable  device）も含まれる。さらに、ユーザ端末１０には、ユーザ情報を判定装置１００に送信する情報処理機能を有する種々のスマート機器が含まれてもよい。例えば、ユーザ端末１０には、ＴＶ（Television）や冷蔵庫、掃除機などのスマート家電や、自動車などのスマートビークル（Smart  vehicle）や、ドローン（drone）、家庭用ロボットなどが含まれてもよい。
【００３４】
ウェブサーバ３０は、ウェブページ等のサービスページを配信するウェブサーバである。例えば、ウェブサーバ３０は、ポータルサイト、ニュースサイト、オークションサイト、天気予報サイト、ショッピングサイト、ファイナンス（株価）サイト、路線検索サイト、地図提供サイト、旅行サイト、飲食店紹介サイト、ＳＮＳサイト、ウェブブログなどに関連する各種情報を含むウェブページをユーザ端末１０に配信する。
【００３５】
ウェブサーバ３０によって配信されるウェブページは、例えば、ＨＴＭＬにより記述されたＨＴＭＬファイルや、ＸＭＬ（Extensible  Markup  Language）により記述されたＸＭＬファイル等により形成される。また、ウェブサーバ３０によって配信されるウェブページには、コンテンツ（広告）取得命令が含まれてもよい。例えば、ウェブページを形成するＨＴＭＬファイル等には、所定の広告サーバのＵＲＬ等が広告取得命令として記述される。この場合、ユーザ端末１０は、ＨＴＭＬファイル等に記述されているＵＲＬにアクセスすることで、所定の広告サーバから広告コンテンツを取得する。
【００３６】
判定装置１００は、上述のように、ユーザのネットワーク上における行動履歴のようなユーザ情報に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定するサーバ装置である。
【００３７】
〔３．実施形態に係る判定装置の構成〕
次に、図３を用いて、実施形態に係る判定装置１００の構成について説明する。図３は、実施形態に係る判定装置１００の構成例を示す図である。図３に示すように、判定装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、判定装置１００は、判定装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。
【００３８】
（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network  Interface  Card）等によって実現される。通信部１１０は、ネットワークＮと有線又は無線で接続され、ネットワークＮを介して、ユーザ端末１０やウェブサーバ３０との間で情報の送受信を行う。
【００３９】
（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ、フラッシュメモリ（Flash  Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図３に示すように、記憶部１２０は、ユーザ情報記憶部１２１と、モデル記憶部１２４と、条件情報記憶部１２５とを有する。
【００４０】
（ユーザ情報記憶部１２１について）
ユーザ情報記憶部１２１は、ユーザ情報を記憶する。ここで、図４に、実施形態に係るユーザ情報記憶部１２１の一例を示す。図４は、実施形態に係るユーザ情報記憶部１２１の一例を示す図である。図４に示した例では、ユーザ情報記憶部１２１は、「ユーザＩＤ」、「端末ＩＤ」、「ユーザ判定」、「属性情報」、「行動情報」といった項目を有する。
【００４１】
「ユーザＩＤ」は、ユーザを識別する識別情報を示す。「端末ＩＤ」は、ユーザが利用する端末を識別する情報を示す。なお、実施形態において、識別情報は、説明に用いる参照符号と一致するものとする。例えば、ユーザＩＤ「Ｕ０１」で識別されるユーザは、ユーザＵ０１を示す。また、端末ＩＤ「１０１」で識別される端末は、ユーザ端末１０１を示す。
【００４２】
「ユーザ判定」は、所定の金融サービスにおいて、ユーザに対して判定された情報を示す。一例として、ユーザ判定は、「ネガティブ」か「非ネガティブ」といった基準で示される。例えば、ユーザ判定の項目は、予め人為的に判定されユーザ情報として入力されてもよいし、後述するようなモデルによる判定結果に応じて、適宜、情報が入力されてもよい。また、判定処理が行われていないユーザに関しては、ユーザ判定の項目は空欄であってもよい。
【００４３】
「属性情報」は、ユーザの属性情報を示す。「行動情報」は、ユーザの行動情報を示す。なお、図４の例では、属性情報や行動情報を「Ａ０１」や「Ｂ０１」のような概念で示しているが、これらの項目には、ユーザの性別や年齢や居住地等の具体的な情報や、どのようなサイトを閲覧したかといった具体的な情報が記憶されてもよい。なお、これらの具体的な情報については、後述するデータテーブルに適宜記憶されるものとする。
【００４４】
すなわち、図４の一例では、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１は、端末ＩＤ「１０１」で識別されるユーザ端末１０１を使用していることを示している。また、所定の金融サービスに関するユーザＵ０１のユーザ判定は「ネガティブ」であり、ユーザＵ０１の属性情報は「Ａ０１」であり、行動情報は「Ｂ０１」であることを示している。
【００４５】
また、ユーザ情報記憶部１２１は、データテーブルとして、属性情報テーブル１２２と、行動情報テーブル１２３とを有する。
【００４６】
（属性情報テーブル１２２について）
属性情報テーブル１２２は、ユーザ情報のうち、ユーザの属性情報を記憶する。ここで、図５に、実施形態に係る属性情報テーブル１２２の一例を示す。図５は、実施形態に係る属性情報テーブル１２２の一例を示す図である。図５に示すように、属性情報テーブル１２２は、「ユーザＩＤ」、「端末ＩＤ」、「属性情報」、「性別」、「年齢」、「居住地」、「推定年収」といった項目を有する。
【００４７】
「ユーザＩＤ」及び「端末ＩＤ」は、図４で示した項目と同様である。「属性情報」は、ユーザの属性情報の内容を示す。「性別」は、ユーザの性別を示す。「年齢」は、ユーザの年齢を示す。なお、実施形態において、端末ＩＤは、属性情報の一つとして扱われてもよい。例えば、ユーザは、複数の端末装置を所有する場合がある。この場合、ユーザが所有する複数の端末装置を特定することで当該ユーザを特定できることから、これら端末装置を識別する識別情報を当該ユーザの属性情報として扱ってもよい。
【００４８】
「居住地」は、ユーザの居住地を示す。「推定年収」は、ユーザの推定年収を示す。なお、図５の例では、居住地や推定年収を「Ｅ０１」や「Ｆ０１」といった概念で示しているが、実際には、居住地の項目には、具体的なユーザの住所や、ネットワーク接続状況から推定されるユーザの居住地等が記憶される。また、年収の項目には、ユーザの購買履歴から推定されるユーザの具体的な年収の値等が記憶される。
【００４９】
すなわち、図５の一例では、ユーザ端末１０１を利用するユーザＵ０１の属性情報は、性別が「男性」で、年齢が「３０歳代」で、居住地が「Ｅ０１」で、推定年収が「Ｆ０１」であることを示している。なお、属性情報テーブル１２２には、ユーザの配偶者の有無や、ユーザの出身地や国籍等、種々の属性情報が記憶されてもよい。
【００５０】
（行動情報テーブル１２３について）
行動情報テーブル１２３は、ユーザ情報のうち、ユーザの行動情報（行動履歴）を記憶する。ここで、図６に、実施形態に係る行動情報テーブル１２３の一例を示す。図６は、実施形態に係る行動情報テーブル１２３の一例を示す図である。図６に示すように、行動情報テーブル１２３は、「ユーザＩＤ」、「行動情報」、「行動日時」、「行動種別」、「サイト」、「カード使用」、「ポイント使用」といった項目を有する。
【００５１】
「ユーザＩＤ」は、図４で示した項目と同様である。「行動情報」は、ユーザの行動情報の内容を示す。「行動日時」は、行動が行われた日時を示す。「行動種別」は、閲覧、購入、検索など、ユーザが採った行動の種別を示す。「サイト」は、行動において対象となったサイト（又は、アプリなどのサービスページ）を示す。
【００５２】
「カード使用」は、当該行動においてカードが使用されたか否かといった情報を示す。例えば、カード使用の項目は、ユーザＵ０１がショッピングサイトで商品を購入した際に、ユーザＵ０１が契約したカードが使用されたか否かという情報を示す。なお、カード使用の項目は、ユーザＵ０１が利用するサービスによって、種々の異なる情報が記憶されてもよい。例えば、ユーザＵ０１が利用する所定の金融サービスが、クレジットカードの契約ではなく、証券口座の契約であったとすると、カード使用の項目は、「証券口座の利用」のような項目の置き換えられてもよい。
【００５３】
「ポイント使用」は、当該行動においてポイントが使用されたか否かといった情報を示す。例えば、ポイント使用の項目は、ユーザＵ０１がショッピングサイトで商品を購入した際に、ユーザＵ０１が支払うべき対価のうち、どのくらいの割合がポイントで支払われたかといった情報を示す。
【００５４】
すなわち、図６の行動情報の一例では、ユーザＵ０１は、「２０１６年７月１５日１０：００」に、「ショッピングサイトＡＡＡ」で「商品購入」しており、ユーザＵ０１が契約しているカードは使用「なし」であり、ポイントが「１００％」使用されて会計が行われていることを示している。また、他の一例では、ユーザＵ０１は、「２０１６年８月２０日１１：００」に、「保険見積もりサイト」を「閲覧」していることを示している。また、他の一例では、ユーザＵ０１は、「２０１６年９月２５日８：００」に、「ショッピングサイトＢＢＢ」で「商品購入」しており、ユーザＵ０１が契約しているカードは使用「なし」であり、ポイントが「８０％」使用されて会計が行われていることを示している。
【００５５】
（モデル記憶部１２４について）
モデル記憶部１２４は、判定装置１００が生成したモデルに関する情報を記憶する。ここで、図７に、実施形態に係るモデル記憶部１２４の一例を示す。図７は、実施形態に係るモデル記憶部１２４の一例を示す図である。図７に示すように、モデル記憶部１２４は、「モデルＩＤ」、「学習データ」、「判定対象」、「判定結果」、「ユーザＩＤ」、「一致率」といった項目を有する。
【００５６】
「モデルＩＤ」は、モデルを識別する識別情報を示す。なお、モデルＩＤの項目には、識別情報のみならず、モデル自体のデータが含まれているものとする。「学習データ」は、モデルの生成に用いられたサンプルデータを示す。図７の例では、学習データを「Ｎ０１」のような概念で示しているが、実際には、学習データの項目には、モデルにおいて正例負例となる情報（例えば、所定のサービスにおいてネガティブユーザと判定されたユーザ群の各ユーザ情報や、ネガティブユーザと判定されていないユーザ群の各ユーザ情報等）や、モデル生成に用いられたサンプル数等の情報が記憶される。なお、学習データは、サンプルデータが判定装置１００に取得される度に更新されてもよい。
【００５７】
「判定対象」は、モデルがどのようなユーザを判定対象とするかといった内容を示す。「判定結果」は、モデルが所定のユーザに適用された場合の判定結果を示す。「ユーザＩＤ」は、ユーザを識別する識別情報を示す。「一致率」は、ユーザ情報が入力された場合にモデルから出力される結果であって、モデルが判定する正例との一致率を示す。一致率は、モデルが判定する正例との類似度を示す指標値と言い換えてもよい。
【００５８】
すなわち、図７の一例では、モデルＩＤ「Ｍ０１」によって識別されるモデルＭ０１は、学習データ「Ｎ０１」に基づいて生成された（学習された）モデルであり、判定対象は「カード未使用ユーザ」であることを示している。そして、モデルＭ０１にユーザＵ０２のユーザ情報が入力された場合に、ユーザＵ０２は、正例（図７の例ではカード未使用ユーザ、ずなわち、サービスにおけるネガティブユーザ）との一致率が「５８」（％）であると判定されたことを示している。
【００５９】
（条件情報記憶部１２５について）
条件情報記憶部１２５は、所定の金融サービスにおいて、新たにユーザが当該サービスに加入しようとする際の条件に関する情報を記憶する。ここで、図８に、実施形態に係る条件情報記憶部１２５の一例を示す。図８は、実施形態に係る条件情報記憶部１２５の一例を示す図である。図８に示すように、条件情報記憶部１２５は、「モデルＩＤ」、「条件ＩＤ」、「一致率」、「内容」といった項目を有する。
【００６０】
「モデルＩＤ」は、所定の金融サービスにおいて、新たにユーザが当該サービスに加入しようとする際の条件を判定するためのモデルを識別する識別情報を示す。なお、モデルＩＤは、図７で示した同様の項目に対応する。「条件ＩＤ」は、サービス加入に関して設定された条件を識別する識別情報を示す。
【００６１】
「一致率」は、モデルによって、新たにサービスに加入しようとするユーザを判定した際の一致率を示す。「内容」は、各条件における内容を示す。
【００６２】
すなわち、図８の一例では、モデルＭ０１によって判定されたユーザが一致率「０〜３０」である場合には、条件ＩＤ「Ｇ０１」で識別される条件Ｇ０１が適用され、その内容は「条件なし」であることを示している。また、モデルＭ０１によって判定されたユーザが一致率「３１〜５０」である場合には、条件Ｇ０２が適用され、その内容は「付与ポイント２割減少」であることを示している。これは、ユーザが当該サービスに加入する際には、通常のユーザに比べて付与されるポイントが２割減少されることを示している。また、モデルＭ０１によって判定されたユーザが一致率「５１〜７０」である場合には、条件Ｇ０３が適用され、その内容は「付与ポイント５割減少」であることを示している。また、モデルＭ０１によって判定されたユーザが一致率「７１〜１００」である場合には、条件Ｇ０４が適用され、その内容は「発行不許可」であることを示している。これは、一致率「７１〜１００」であるユーザはネガティブユーザになる可能性が高いため、クレジットカードの発行をサービス側が許可しない対応をとることを示している。
【００６３】
（制御部１３０について）
制御部１３０は、例えば、コントローラ（controller）であり、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）等によって、判定装置１００内部の記憶装置に記憶されている各種プログラム（判定プログラム又は生成プログラムの一例に相当）がＲＡＭ（Random  Access  Memory)を作業領域として実行されることにより実現される。また、制御部１３０は、コントローラであり、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路により実現される。
【００６４】
図３に示すように、制御部１３０は、取得部１３１と、生成部１３２と、判定部１３３と、決定部１３４と、送信部１３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。
【００６５】
（取得部１３１について）
取得部１３１は、各種情報を取得する。例えば、取得部１３１は、ユーザ端末１０からユーザ情報を取得する。具体的には、取得部１３１は、ユーザのネットワーク上における行動履歴を取得する。
【００６６】
例えば、取得部１３１は、ユーザのネットワーク上の行動履歴として、ユーザが検索サービスに送信した検索クエリに関する情報を取得する。より具体的には、取得部１３１は、送信した検索クエリが示す辞書的情報の類似性や、検索クエリが属するカテゴリやジャンルや、送信する検索クエリの頻度等に基づいて、ユーザがどのような検索クエリを頻繁に送信するかといった傾向を示す情報を取得する。言い換えれば、取得部１３１は、検索クエリの送信履歴から、ユーザの興味関心に関する情報を取得する。
【００６７】
また、取得部１３１は、ユーザのネットワーク上の行動履歴として、所定のサービスページをユーザが閲覧した履歴を取得する。具体的には、取得部１３１は、ユーザが閲覧したウェブサイトの履歴を取得する。この場合、取得部１３１は、ウェブサイトのカテゴリ（例えば、ニュースサイトや、ショッピングサイトや、株式情報サイトなど）別に履歴を取得し、ユーザがどのようなカテゴリのサイトを頻繁に閲覧するかといった傾向を示す情報を取得してもよい。言い換えれば、取得部１３１は、ウェブサイトの閲覧履歴から、ユーザの興味関心に関する情報を取得する。
【００６８】
また、取得部１３１は、ユーザのネットワーク上の行動履歴として、所定のサービスにおけるユーザの購買履歴を取得する。具体的には、取得部１３１は、ユーザがショッピングサイトやオークションサイトや旅行予約サイト等で商品や商材を購入した履歴や、購入した商品のカテゴリやジャンル、購買行動を行う頻度等を取得する。なお、取得部１３１は、ショッピングサイトにおいて使用されたカードの種類や、使用された通貨やポイントの種類や、ユーザが契約しているサービスに関する口座が支払いに利用されたか否か、支払いにおける不払いや遅延が生じなかったか等、種々の購買に関する情報を取得してもよい。言い換えれば、取得部１３１は、所定のサービスにおけるユーザの購買履歴から、ユーザがどのような購買行動を行っているかというユーザの特徴情報を取得する。
【００６９】
このように、取得部１３１は、ネットワーク上の行動履歴として、ユーザが検索サービスに送信した検索クエリに関する情報、ユーザの所定のサービスページの閲覧履歴、又は、所定のサービスにおけるユーザの購買履歴の少なくともいずれか一つを取得する。これに加え、取得部１３１は、ユーザ情報としてユーザの属性情報をさらに取得してもよい。すなわち、取得部１３１は、ユーザの性別や、年齢や、居住地や、推定年収等の属性情報を取得する。
【００７０】
取得部１３１は、取得した情報を、ユーザ情報記憶部１２１や、ユーザ情報記憶部１２１が有する各データテーブルに適宜記憶する。
【００７１】
（生成部１３２について）
生成部１３２は、取得部１３１によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成する。具体的には、生成部１３２は、ユーザが検索サービスに送信した検索クエリに関する情報、ユーザの所定のサービスページの閲覧履歴、又は、所定のサービスにおけるユーザの購買履歴の少なくともいずれか一つに基づいてモデルを生成する。
【００７２】
生成部１３２は、例えば、所定の金融サービスを契約中のユーザであって、所定の金融サービスの利用率が所定の閾値よりも低いユーザの行動履歴に基づいてモデルを生成する。すなわち、生成部１３２は、金融サービスにおけるいわゆるネガティブユーザの行動履歴を正例として、ネガティブユーザになりうる可能性の高いユーザを判定するためのモデルを生成する。
【００７３】
より具体的には、生成部１３２は、所定の金融サービスのうち、所定のポイントをユーザに付与するシステムを有する金融サービスに関するモデルを生成する。例えば、生成部１３２は、サービス加入時に所定のポイントがユーザに付与されるシステムを有する金融サービスに関するモデルを生成する。これにより、生成部１３２は、加入時の特典であるポイントの付与のみを受けて、その後、金融サービスをほぼ利用しなくなるユーザであるネガティブユーザを判定することのできるモデルを生成することができる。
【００７４】
例えば、生成部１３２は、ユーザの行動履歴を入力とし、当該行動履歴を有するユーザが正例（ネガティブユーザ）の行動履歴の傾向と一致する率を示す所定の指標値を出力するモデルを生成する。なお、モデルが出力する情報は、一致率に限定されず、例えば、ネガティブユーザに類似するか否かを「１」、「０」のようなバイナリで表示した結果を出力するモデルであってもよい。
【００７５】
例えば、生成部１３２は、「ユーザが当該サービスにおけるネガティブユーザである」という事象を機械学習における目的変数とし、ユーザの行動履歴（具体的には、行動履歴を構成する各々の特徴情報）を機械学習における説明変数とする。そして、生成部１３２は、目的変数と説明変数とを用いて、ユーザに対する判定結果とユーザ情報（ユーザの行動履歴）との関係性を示すモデルを生成する。
【００７６】
生成部１３２は、種々の説明変数を用いてモデルを生成する。上述のように、判定装置１００は、例えば判定装置１００の管理者や金融サービス事業者の判定に基づいて、どのような行動履歴を有するユーザが「ネガティブユーザ」と判定され、どのような行動履歴を有するユーザが「非ネガティブユーザ」と判定されたかという正解データ（サンプルデータ）を有する。生成部１３２は、これらのサンプルデータを学習することにより、あるユーザが「ネガティブユーザ」と判定された結果に対して寄与した説明変数を特定することで、モデルを生成することができる。言い換えれば、生成部１３２は、判定に寄与した説明変数の重み値が大きくなるようなモデルを生成することで、ある特徴情報を有する行動履歴が入力された場合に、当該行動履歴に対応するユーザが「ネガティブユーザ」であるか否か、を精度よく判定するモデルを生成することができる。
【００７７】
生成部１３２は、判定部１３３が判定要素とする情報、すなわち、取得部１３１によって取得されたユーザ情報について、あらゆる情報を用いてモデルを生成してよい。例えば、生成部１３２は、ユーザの検索クエリの傾向や、サイト閲覧履歴や、購買履歴等を、当該ユーザの特徴情報として利用する。
【００７８】
下記に、生成部１３２が生成するモデルの一例を説明する。なお、生成部１３２が生成するモデルに関する学習手法は、下記の例に限らず、種々の既知の機械学習の手法が採用されてもよい。
【００７９】
例えば、生成部１３２は、あるユーザが「ネガティブユーザ」と判定されたユーザであるか否かを示す事象と、ユーザの行動履歴との関係を示す式を生成する。さらに、生成部１３２は、ユーザの行動履歴における個々の特徴情報が、判定結果に対して、どのような重みを有するかを算出する。これにより、生成部１３２は、あるユーザが「ネガティブユーザ」と判定されるという事象に対して、ユーザの行動履歴に含まれる種々の特徴情報がどのくらい寄与するのかといった情報を得ることができる。例えば、生成部１３２は、下記式（１）を作成する。
【００８０】
ｙ（Ｕ０１）  ＝  ω１・ｘ１  ＋  ω２・ｘ２  ＋  ω３・ｘ３  ・・・＋  ωＮ・ｘＮ      ・・・（１）（Ｎは任意の数）
【００８１】
上記式（１）は、例えば、ユーザＵ０１に関して作成される式である。上記式（１）において、「ｙ（Ｕ０１）」は、ユーザＵ０１が「ネガティブユーザ」と判定されたか否かを示す。例えば、「ｙ（Ｕ０１）」は、ユーザＵ０１が「ネガティブユーザ」と判定されている場合には「１」が入力され、ユーザＵ０１が「非ネガティブユーザ」と判定されている場合には「０」が入力される。実施形態では、図４に示すように、ユーザＵ０１は「ネガティブユーザ」と判定されているため、「ｙ（Ｕ０１）」は「１」の値をとる。
【００８２】
また、上記式（１）において、「ｘ」は、ユーザＵ０１の行動履歴に含まれる各説明変数に対応する。例えば、上記式（１）における「ｘ１、ｘ２、ｘ３、・・・、ｘＮ」という説明変数は、検索クエリの送信履歴や、ウェブサイトの閲覧履歴や、ネット上での購買履歴等が該当する。例えば、ユーザＵ０１の行動履歴から、ユーザＵ０１が金融サービスにおける新規加入の宣伝のページを頻繁に閲覧していることや、購買時には契約しているカードを使用しないことや、付与されたポイントのみを用いて購買を行っていることや、ポイントが付与されるサービスサイトを頻繁に検索していることなど、ある傾向が見出せるとすると、それらの情報が説明変数として大きく寄与することとなる。すなわち、上記式（１）の右辺は、ユーザＵ０１の行動履歴に含まれる特徴情報に対応する。
【００８３】
上記式（１）において、「ω」は、「ｘ」の係数であり、所定の重み値を示す。具体的には、「ω１」は、「ｘ１」の重み値であり、「ω２」は、「ｘ２」の重み値であり、「ω３」は、「ｘ３」の重み値である。このように、上記式（１）は、行動履歴に含まれる特徴情報に対応する説明変数「ｘ」と、所定の重み値「ω」とを含む変数（例えば、「ω１・ｘ１」）を組合せることにより作成される。
【００８４】
例えば、上記式（１）において、仮に、「ｘ１」が「検索クエリの送信履歴」に対応し、「ｘ２」が「ウェブサイトの閲覧履歴」に対応し、「ｘ３」が「ネットワーク上の購買履歴」に対応する説明変数であるとする。この場合、ユーザＵ０１に対応する上記式（１）は、以下の式（２）のように表すことができる。
【００８５】
ｙ（Ａ０１、Ｕ０１）（＝  １）  ＝  ω１・（検索クエリの送信履歴）  ＋  ω２・（ウェブサイトの閲覧履歴）  ＋  ω３・（ネットワーク上の購買履歴）  ＋  ωＮ・ｘＮ      ・・・（２）
【００８６】
上記式（２）のような式を利用して、生成部１３２は、ユーザＵ０１のみならず、モデルに一定の信頼性を与える数のサンプルにおいて、判定結果と行動履歴との関係式を作成する。そして、これらの関係式を回帰分析すること等により重み値を算出し、判定結果とユーザの行動履歴との関係性を示すモデルを生成する。例えば、上記の学習を経て、検索クエリの送信履歴に関する重み値が他の説明変数に比べて大きくなる場合には、ウェブサイトの閲覧履歴やネットワーク上の購買履歴に比べて、検索クエリの送信履歴によって、あるユーザが「ネガティブユーザ」と判定されるユーザであるか否かを示す事象が判定されることになる。
【００８７】
なお、生成部１３２は、モデル生成のための式に代入可能なように、ユーザの行動履歴を正規化して指標値として入力するなど、既知の様々な手法を用いてモデルを生成するようにしてもよい。
【００８８】
また、上記の例では、説明を簡単にするため、「検索クエリの送信履歴」といった大まかな情報を示したが、実際には、種々のクエリごとに重み値が算出されてもよい。かかる処理によって、例えば、過去に「ボーナスポイント＋保険見積もり」や「ボーナスポイント＋クレジットカード」という検索クエリを送信しているユーザは、「ネガティブユーザ」と判定され易い傾向にあるユーザである、といったように、ユーザの行動が判定結果に与える影響を、より詳細に捉えることのできるモデルが生成される。
【００８９】
なお、生成部１３２は、ユーザの行動履歴とともに、ユーザの属性情報に基づいてモデルを生成してもよい。これにより、生成部１３２は、行動履歴が類似するユーザのみならず、属性情報の類似性や傾向に沿ってネガティブユーザになる可能性のあるユーザを判定することのできるモデルを生成することができる。
【００９０】
生成部１３２は、生成したモデルをモデル記憶部１２４に登録する。また、生成部１３２は、モデルを生成した後に、取得部１３１が新たなユーザ情報を取得した場合には、随時、モデルを更新してもよい。
【００９１】
（判定部１３３について）
判定部１３３は、取得部１３１によって取得された行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する。具体的には、判定部１３３は、生成部１３２によって生成されたモデルを利用して、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する。例えば、判定部１３３は、モデルから出力される指標値（例えば、正例との一致率）に基づいて、ユーザが所定の金融サービスにおいてどのくらい信用に値するユーザであるかを判定し、ユーザの信用度を判定することができる。
【００９２】
判定部１３３は、ユーザに対する信用度を判定するとともに、判定した信用度に応じて、ユーザが所定の金融サービスを利用する場合のサービス内容を判定してもよい。例えば、判定部１３３は、ユーザが所定の金融サービスを利用する場合のサービス内容として、所定の金融サービスにユーザが加入する場合の特典、所定の金融サービスをユーザが利用する場合の金利、又は、所定の金融サービスをユーザが利用する場合の融資額もしくは限度額、の少なくとも一つに関する内容を判定する。
【００９３】
具体的には、判定部１３３は、図８に示したように、判定された信用度（一致率）に応じて、所定の金融サービスにユーザが加入する場合の特典であるポイントの付与率を判定する。あるいは、判定部１３３は、例えばユーザがクレジットカードの契約や、自動車や住宅のローンを受ける金融サービスを利用する場合には、判定された信用度（一致率）に応じて、ユーザが利用する場合の金利や融資額、クレジットカードの利用限度額等を判定するようにしてもよい。
【００９４】
（決定部１３４について）
決定部１３４は、判定部１３３による判定結果に基づいて、ユーザ端末１０に通知する情報を決定する。例えば、決定部１３４は、所定のユーザに対して、判定部１３３によって所定のサービスに関する条件が判定された場合には、当該条件をユーザ端末１０に通知するよう決定する。
【００９５】
また、決定部１３４は、通知する情報の態様を決定する。例えば、決定部１３４は、ユーザが加入を申し込もうとしたサービスページに上記判定結果を通知する場合には、バナー広告やポップアップ表示によって上記判定結果を通知するよう、態様を決定する。
【００９６】
（送信部１３５について）
送信部１３５は、決定部１３４によって決定された通知内容をユーザ端末１０に送信する。例えば、送信部１３５は、ユーザ端末１０がウェブページを表示しており、また、当該ウェブページが金融サービスの申し込みに関するページであれば、当該ページにポップアップされる表示であって、ユーザに対する金融サービスの加入時の条件が表示される態様で、通知を送信する。
【００９７】
なお、送信部１３５は、判定装置１００からユーザ端末１０に直接的に通知を送信せずに、所定の送信サーバを介して、通知を送信してもよい。この場合、送信部１３５は、所定の送信サーバを制御することにより、ユーザ端末１０へ通知の送信を実行させる。
【００９８】
また、送信部１３５は、ウェブページのバナー広告や、メール広告や、プッシュ通知や、ウェブページに表示されるレコメンドなど、種々の種別に対応させて通知を送信するようにしてもよい。
【００９９】
〔４．実施形態に係る処理手順〕
次に、図９及び図１０を用いて、実施形態に係る判定装置１００による処理の手順について説明する。まず、図９を用いて、実施形態に係る生成処理の手順について説明する。図９は、実施形態に係る処理手順を示すフローチャート（１）である。
【０１００】
図９に示すように、取得部１３１は、ユーザ端末１０からユーザ情報を取得したか否かを判定する（ステップ１０１）。取得部１３１は、ユーザ情報を取得していない場合（ステップＳ１０１；Ｎｏ）、取得するまで待機する。
【０１０１】
一方、ユーザ情報を取得した場合（ステップＳ１０１；Ｙｅｓ）、一方、端末情報を取得した場合（ステップＳ１０１；Ｙｅｓ）、取得部１３１は、取得したユーザ情報をユーザ情報記憶部１２１に格納し、蓄積する（ステップＳ１０２）。
【０１０２】
そして、生成部１３２は、モデル生成のために充分なデータ量が蓄積されたか否かを判定する（ステップＳ１０３）。例えば、生成部１３２は、モデルの出力結果について一定の信頼性を与えるだけの充分な量（すなわち、統計的に有意とみなされる数。例えば、判定対象のうちの１％を満たす数など）のユーザ情報が蓄積されたかを判定する。そして、充分なデータ量が蓄積されていない場合（ステップＳ１０３；Ｎｏ）、取得部１３１は、ユーザ情報を取得する処理を継続する（ステップＳ１０１）。
【０１０３】
一方、充分なデータ量が蓄積された場合（ステップＳ１０３；Ｙｅｓ）、生成部１３２は、取得されたユーザ情報に基づいてモデルを生成する（ステップＳ１０４）。そして、生成部１３２は、生成したモデルをモデル記憶部１２４に登録する（ステップＳ１０５）。
【０１０４】
次に、図１０を用いて、実施形態に係る判定処理の手順について説明する。図１０は、実施形態に係る処理手順を示すフローチャート（２）である。
【０１０５】
図１０に示すように、取得部１３１は、ユーザ端末１０から新たなユーザ情報を取得したか否かを判定する（ステップＳ２０１）。取得部１３１は、ユーザ情報を取得していない場合（ステップＳ２０１；Ｎｏ）、取得するまで待機する。
【０１０６】
一方、ユーザ情報を取得した場合（ステップＳ２０１；Ｙｅｓ）、判定部１３３は、ユーザ情報を生成部１３２が生成したモデルに入力する（ステップＳ２０２）。そして、判定部１３３は、ユーザの信用度を判定する（ステップＳ２０３）。
【０１０７】
続いて、決定部１３４は、判定部１３３によって判定された結果に基づいて、信用度に応じた条件であって、ユーザ端末１０に送信する条件を決定する（ステップＳ２０４）。送信部１３５は、決定した条件に関する通知をユーザ端末１０に送信する（ステップＳ２０５）。
【０１０８】
〔５．変形例〕
上述した判定装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、実施形態の変形例について説明する。
【０１０９】
〔５−１．ユーザ獲得コストの判定〕
上記実施形態では、判定装置１００が、ユーザが新規に金融サービスに加入する際の信用度を判定する例を示した。ここで、判定装置１００は、ユーザが新規に金融サービスに加入する際の条件のみならず、ユーザを新規に獲得しようとする宣伝活動など、その他の状況における信用度や条件を判定するようにしてもよい。
【０１１０】
すなわち、判定装置１００は、ユーザに対する信用度を判定するとともに、判定した信用度に応じて、ユーザに対して所定の金融サービスを宣伝するために掛けるコストを判定してもよい。
【０１１１】
例えば、ある金融サービスにおいて、サービスへの加入を促すバナー広告等の広告宣伝費について、１ユーザあたりに掛けるコストが決まっているものとする。ここで、判定装置１００が、広告等のコンテンツの判定対象となっているユーザについて、各ユーザの信用度を判定する。そして、判定装置１００は、判定した信用度に応じて、１ユーザあたりに掛けるコストを新たに決定するようにしてもよい。
【０１１２】
すなわち、金融サービスにとっては、将来的にネガティブユーザになるようなユーザについては、広告宣伝費などのコストを極力抑えることが望ましい。このため、判定装置１００は、信用度が低いユーザに対しては広告宣伝費等のコストを抑えるとともに、信用度が高いユーザ（例えば、ネガティブユーザと異なる行動傾向が強いユーザ）に対しては広告宣伝費等のコストを他のユーザよりも掛けるなどの調整を行う。これにより、判定装置１００は、宣伝における費用対効果を向上させることができる。
【０１１３】
また、この場合、判定装置１００は、ネガティブユーザを正例としてモデルを生成するのではなく、特にサービスに貢献度の高いユーザであるポジティブユーザを正例としてモデルを生成してもよい。そして、判定装置１００は、ポジティブユーザとの一致率の高いユーザに対して、他のユーザよりも多額の広告宣伝費を掛けるような調整を行ってもよい。
【０１１４】
〔５−２．コンテンツ配信〕
判定装置１００は、判定した信用度に応じて、所定のコンテンツを配信するようにしてもよい。例えば、判定装置１００は、ユーザの信用度に応じて、加入時の特典を優遇することを示した広告や、金融サービスの加入を勧めるレコメンド等をユーザ端末１０に配信するようにしてもよい。
【０１１５】
〔５−３．ユーザ情報の利用〕
上記実施形態では、判定装置１００は、ユーザの特徴情報として、ユーザの検索クエリに関する情報や、ネットワーク上の閲覧履歴や購買履歴等を用いることを説明した。ここで、判定装置１００は、ユーザの特徴を示す情報であれば、あらゆる情報を用いて、ユーザの信用度を判定してもよい。言い換えれば、判定装置１００は、ユーザの特徴を表すことのできる情報を用いてモデルを生成してもよい。
【０１１６】
例えば、判定装置１００は、ユーザが利用するＳＮＳに関する情報を取得してもよい。具体的には、判定装置１００は、ユーザからＳＮＳに投稿された比較的新しい記事の内容（例えば、いわゆるタイムラインに表示される記事の内容）、ユーザからＳＮＳに投稿された画像数、ＳＮＳ上において関係性を有するユーザ数（例えば、友達数）の少なくともいずれか一つを取得する。
【０１１７】
より具体的には、判定装置１００は、ユーザからＳＮＳに投稿された記事のテキストデータに含まれる単語の傾向を取得する。これにより、判定装置１００は、ユーザが興味関心を有する事象に関する情報を取得する。あるいは、判定装置１００は、ＳＮＳに投稿された画像数や画像の内容、ＳＮＳ上において関係性を有するユーザ、すなわち、ＳＮＳ上においてつながりを有するユーザ数（例えば、友人の数やフォロワーの数）を取得する。これにより、判定装置１００は、ユーザがどのような日常生活を送っているかを示す情報を取得する。
【０１１８】
そして、判定装置１００は、取得したＳＮＳに関する情報を含めてモデルを生成し、生成したモデルに基づいてユーザの信用度を判定する。このように、判定装置１００は、ユーザの特徴を示す種々の情報に基づいて信用度を判定できるため、多様な観点から判定処理を行うことができる。
【０１１９】
〔５−４．画像認識〕
また、判定装置１００は、ＳＮＳに関する情報として、ユーザが投稿する画像数のみならず、画像認識等によって画像が示す内容に基づいて処理を行ってもよい。
【０１２０】
例えば、判定装置１００は、ユーザが投稿した画像の内容そのものに基づいて、いずれのユーザがネガティブユーザと同様の傾向を有するかを判定してもよい。例えば、判定装置１００は、ユーザがＳＮＳにアップしている画像のうち、画像に写っている人物、風景、内容、ジャンル、カテゴリ、画質等に基づいて、ユーザがどのような日常生活を送っているかを特徴情報として抽出し、抽出した情報を特徴情報としてモデルを生成してもよい。これにより、判定装置１００は、ユーザの特徴を示す種々の情報に基づいて信用度を判定できるため、多様な観点から判定処理を行うことができる。
【０１２１】
〔６．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【０１２２】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図３に示した判定部１３３と、決定部１３４とは統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、ネットワークＮを介して、外部に備えられた記憶装置に記憶されてもよい。
【０１２３】
また、例えば、上記実施形態では、判定装置１００が、ユーザ端末１０のユーザ情報を取得する取得処理と、信用度を推定する判定処理とを行う例を示した。しかし、上述した判定装置１００は、取得処理を行う取得装置と、判定処理を行う判定装置とに分離されてもよい。この場合、取得装置は、取得部１３１を少なくとも有する。判定装置は、判定部１３３を少なくとも有する。この場合、実施形態に係る判定装置１００による処理は、取得装置と、判定装置といった各装置を含む判定システム１によって実現される。
【０１２４】
また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【０１２５】
〔７．ハードウェア構成〕
上述してきた実施形態に係る判定装置１００やユーザ端末１０は、例えば図１１に示すような構成のコンピュータ１０００によって実現される。以下、判定装置１００を例に挙げて説明する。図１１は、判定装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。
【０１２６】
ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に記憶されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を記憶する。
【０１２７】
ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（図２に示したネットワークＮに対応）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５００を介して他の機器へ送信する。
【０１２８】
ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。
【０１２９】
メディアインターフェイス１７００は、記録媒体１８００に記憶されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital  Versatile  Disc）、ＰＤ（Phase  change  rewritable  Disk）等の光学記録媒体、ＭＯ（Magneto-Optical  disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【０１３０】
例えば、コンピュータ１０００が実施形態に係る判定装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。
【０１３１】
〔８．効果〕
上述してきたように、実施形態に係る判定装置１００は、取得部１３１と、判定部１３３とを有する。取得部１３１は、ユーザのネットワーク上における行動履歴を取得する。判定部１３３は、取得部１３１によって取得された行動履歴に基づいて、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する。
【０１３２】
このように、実施形態に係る判定装置１００は、ユーザの行動履歴を判定要素として金融サービスに関するユーザの信用度を判定する。すなわち、判定装置１００は、ユーザのネットワーク上の行動履歴に基づいてユーザの特徴を捉え、所定の金融サービスにとって優良なユーザであるか否かを判定する。これにより、判定装置１００は、サービスを利用する前の具体的な結果（例えば、ユーザがどのくらいサービスを利用してくれるか）を得なくとも、将来的なユーザのサービスに対する貢献度を測ることができるため、金融サービスにおける個人の信用度を適切に判定することができる。
【０１３３】
また、実施形態に係る判定装置１００は、取得部１３１によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成する。判定部１３３は、生成部１３２によって生成されたモデルを利用して、新たに所定の金融サービスを利用しようとするユーザに対する信用度を判定する。
【０１３４】
このように、実施形態に係る判定装置１００は、判定処理に用いるユーザモデルを生成し、生成したモデルを利用してユーザを判定する。これにより、判定装置１００は、処理の効率化を図るとともに、判定処理の精度を向上させることができる。
【０１３５】
また、取得部１３１は、ネットワーク上における行動履歴として、ユーザが検索サービスに送信した検索クエリに関する情報、ユーザの所定のサービスページの閲覧履歴、又は、所定のサービスにおけるユーザの購買履歴の少なくともいずれか一つを取得する。生成部１３２は、ユーザが検索サービスに送信した検索クエリに関する情報、ユーザの所定のサービスページの閲覧履歴、又は、所定のサービスにおけるユーザの購買履歴の少なくともいずれか一つに基づいて、モデルを生成する。
【０１３６】
このように、実施形態に係る判定装置１００は、ユーザが送信した検索クエリ等に関する情報を用いて判定処理を行う。上述のように、ユーザが送信する検索クエリや閲覧履歴や行動履歴等は、そのユーザの興味関心を具体的に表現するものといえる。かかる情報を判定処理に用いることにより、判定装置１００は、ユーザの傾向をより正確に捉えることができる。
【０１３７】
また、生成部１３２は、所定の金融サービスを契約中のユーザであって、所定の金融サービスの利用率が所定の閾値よりも低いユーザの行動履歴に基づいてモデルを生成する。
【０１３８】
このように、実施形態に係る判定装置１００は、実際に稼働している金融サービスにおいてサービスの利用率が所定の閾値よりも低いユーザ、いわゆるネガティブユーザを正例又は負例としてモデルを生成するようにしてもよい。これにより、判定装置１００は、サービスに貢献しないユーザを的確に判定することのできるモデルを生成することができる。
【０１３９】
また、生成部１３２は、所定の金融サービスのうち、所定のポイントをユーザに付与するシステムを有する金融サービスに関するモデルを生成する。
【０１４０】
このように、実施形態に係る判定装置１００は、ポイント制度のあるサービスにおいてユーザを判定するモデルを生成する。一般に、ポイント制度のような仮想通貨システムがある場合、仮想通貨の利用のみを目的とするネガティブユーザが発生しやすい。判定装置１００は、このようなシステムにおけるネガティブユーザを抽出することのできるモデルを生成することで、ネガティブユーザを排除し、適切なサービスの運用を行うことができる。
【０１４１】
また、生成部１３２は、サービス加入時に所定のポイントがユーザに付与されるシステムを有する金融サービスに関するモデルを生成する。
【０１４２】
このように、実施形態に係る判定装置１００は、加入時の特典として、ポイント付与制度のあるサービスにおいてユーザを判定するモデルを生成する。一般に、加入時の特典があるサービスでは、特典のみを目的とするネガティブユーザが発生しやすい。判定装置１００は、このようなシステムにおけるネガティブユーザを抽出することのできるモデルを生成することで、ネガティブユーザを排除し、適切なサービスの運用を行うことができる。
【０１４３】
また、取得部１３１は、行動履歴を取得したユーザの属性情報をさらに取得する。生成部１３２は、ユーザの属性情報に基づいてモデルを生成する。
【０１４４】
このように、実施形態に係る判定装置１００は、ユーザの行動履歴のみならず、ユーザの属性情報の類似性を用いて生成処理を行ってもよい。これにより、判定装置１００は、判定処理の精度を向上させることができる。
【０１４５】
また、取得部１３１は、ネットワーク上における行動履歴として、ユーザが利用するＳＮＳ（Social  Networking  Service）に関する情報を取得する。生成部１３２は、ユーザが利用するＳＮＳに関する情報に基づいて、モデルを生成する。
【０１４６】
このように、実施形態に係る判定装置１００は、ユーザが利用するＳＮＳに関する情報を利用してモデルを生成してもよい。ＳＮＳには、ユーザが日々の生活の中で興味を持ったり、ユーザが行動したりした結果を記録としてアップロードされるため、ＳＮＳに保持される情報は、そのユーザの特徴を示す情報となりうる。このようなユーザの特徴を示す情報をモデル生成に用いることにより、判定装置１００は、ユーザの信用度を判定する処理の精度を向上させることができる。
【０１４７】
また、判定部１３３は、ユーザに対する信用度を判定するとともに、信用度に応じて、ユーザが所定の金融サービスを利用する場合のサービス内容を判定する。
【０１４８】
このように、実施形態に係る判定装置１００は、信用度に応じて、サービス内容（条件）を判定してもよい。これにより、判定装置１００は、ネガティブユーザとなる可能性のあるユーザであっても、諸条件に応じて加入を認めるなど、柔軟な対応を採ることができる。
【０１４９】
また、判定部１３３は、所定の金融サービスを利用する場合のサービス内容として、所定の金融サービスにユーザが加入する場合の特典、所定の金融サービスをユーザが利用する場合の金利、又は、所定の金融サービスをユーザが利用する場合の融資額もしくは限度額、の少なくとも一つに関する内容を判定する。
【０１５０】
このように、実施形態に係る判定装置１００は、信用度に応じたサービス内容（条件）をより詳細に判定してもよい。これにより、判定装置１００は、ネガティブユーザとなる可能性のあるユーザに対しては、ある程度の信用が得られるまでやや厳しい条件とする一方で、信用のあるユーザに対しては優遇された条件を提示するなど、柔軟な対応を採ることができる。
【０１５１】
また、判定部１３３は、ユーザに対する信用度を判定するとともに、信用度に応じて、ユーザに対して所定の金融サービスを宣伝するために掛けるコストを判定する。
【０１５２】
このように、実施形態に係る判定装置１００は、ユーザの信用度に応じて宣伝広告費を調整するなどの処理を行ってもよい。これにより、判定装置１００は、獲得した際に利益をもたらすユーザの獲得に対して適切なコストを掛けることができるため、費用対効果を向上させることができる。
【０１５３】
なお、実施形態に係る判定装置１００は、モデル生成処理を行う生成装置として機能してもよい。この場合、生成装置は、少なくとも、取得部１３１と、生成部１３２とを有する。取得部１３１は、ユーザのネットワーク上における行動履歴を取得する。生成部１３２は、取得部１３１によって取得された行動履歴に基づいて、所定の金融サービスを利用するユーザを審査するためのモデルを生成する。
【０１５４】
このように、生成装置は、ユーザの行動履歴に基づきユーザをモデリングすることで、所定の金融サービスを利用するユーザを審査することを可能とする。例えば、生成装置によれば、どのような行動履歴を有するユーザであれば、サービスにとって優良なユーザであるかを推定することのできるモデルを生成することができる。これにより、生成装置は、金融サービスにおける個人の信用度を適切に判定することができる。
【０１５５】
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【０１５６】
また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。
【符号の説明】
【０１５７】
１  判定システム
１０  ユーザ端末
３０  ウェブサーバ
１００  判定装置
１１０  通信部
１２０  記憶部
１２１  ユーザ情報記憶部
１２２  属性情報テーブル
１２３  行動情報テーブル
１２４  モデル記憶部
１２５  条件情報記憶部
１３０  制御部
１３１  取得部
１３２  生成部
１３３  判定部
１３４  決定部
１３５  送信部
【図１】
2018045573.tif 000003
【図２】
2018045573.tif 000004
【図３】
2018045573.tif 000005
【図４】
2018045573.tif 000006
【図５】
2018045573.tif 000007
【図６】
2018045573.tif 000008
【図７】
2018045573.tif 000009
【図８】
2018045573.tif 000010
【図９】
2018045573.tif 000011
【図１０】
2018045573.tif 000012
【図１１】
2018045573.tif 000013