JP6748174B2 - 金融商品提案装置 - Google Patents

Description

本発明は、ユーザ情報を用いて金融商品を提供する金融商品提案装置に関する。

下記特許文献１には、ユーザのリスクに基づいて適切な保険をユーザに提案する保険加入支援サーバが記載されている。

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

上記特許文献１に記載の技術では、予めどのリスクに対して、どの保険に加入すべきか予め定義されている。したがって、多種多様なリスクの組合せに対する適切な保険の組合せを全て網羅することは困難である。これは保険以外の他の金融商品を提案する際にも同様のことがいえる。

そこで、上述の問題を解決するために、本発明は、金融商品の組合せを全て網羅することなく適切な金融商品をユーザに提案することができる金融商品提案装置を提供することを目的とする。

本発明の金融商品提案装置は、リスクごとの金融商品の組合せを示す保険情報に基づいて、入力されたリスクに対応する金融商品の組合せを出力する提案モデルを構築する学習部と、ユーザの行動または属性を示すユーザ情報に基づいて、当該ユーザの行動または属性に対するリスクを示すリスク値を算出するリスク算出部と、前記ユーザのリスク値を前記提案モデルに入力することで、前記ユーザに対する金融商品の組合せを導出する導出部と、前記金融商品の組合せを示す提案金融商品情報を前記ユーザに提供する提供部と、を備え、前記提案モデルは、前記提供部により提供された提案金融商品情報に対する前記ユーザからの修正情報によって更新される前記リスクごとの金融商品の組合せに基づいて、前記学習部により再構築され、前記ユーザおよび他のユーザに対する金融商品の組合せを導出する際に使用される。

この発明によれば、提案モデルに基づいてユーザにとって適切な保険の組合せを提案することができる。そして、この提案モデルは提案した保険に対するユーザからのフィードバックに応じて再構築されるため、保険会社のみならず、他の保険加入者である他のユーザの動向に応じた適切な提案モデルを構築することができ、それに応じた保険の提案をすることができる。

本発明によると、金融商品の組合せを全て網羅することなく適切な金融商品をユーザに提案することができる。

本実施形態の保険提案サーバ１００を含んだ提案システムのシステム構成図を示す。 保険提案サーバ１００の機能を示すブロック図である。 保険提案サーバ１００における提案モデルを構築するときの処理を示すフローチャートである。 提案モデルを構築または学習したときの模式図である。 リスク算出部１０２の動作を示すフローチャートである。 リスク算出処理を模式的に示した模式図である。 保険提案サーバ１００における保険提案動作を示すフローチャートである。 提案モデルを使った保険の提案および保険データベース１０３の更新処理を模式的に示した図である。 ユーザ端末２００における、提案保険情報を含む表示画面例を示す。 他の加入者情報欄を加えた提案保険情報を含む表示画面例を示す。 類似する保険同士を関連付けた提案保険情報を含む表示画面例を示す。 本開示の一実施の形態に係る保険提案サーバ１００およびユーザ端末２００のハードウェア構成の一例を示す図である

添付図面を参照しながら本発明の実施形態を説明する。可能な場合には、同一の部分には同一の符号を付して、重複する説明を省略する。

図１は、本実施形態の保険提案サーバ１００を含んだ提案システムのシステム構成図を示す。図１に示される通り、この提案システムは、保険提案サーバ１００、ユーザ端末２００、およびユーザ情報データベース３００を含んで構成されている。保険提案サーバ１００は、後述する通り、金融商品提案装置として機能する。保険提案サーバ１００は、ユーザ情報データベース３００とアクセスすることによって、ユーザ情報を取得し、ユーザごとのリスクを算出する。そして、そのリスクに基づいて提案モデルを構築・学習して、提案保険（または提案金融商品）をユーザ端末２００に提供することができる。

ユーザ端末２００は、保険提案サーバ１００に対して、保険の提案の依頼および提案された保険の評価を行う装置である。例えば、このユーザ端末２００は、携帯電話またはスマートフォンである。なお、本実施形態においては、保険提案について説明しているが、これに限るものではなく、株式、債券など他の金融商品についても適用することができる。その場合、リスク管理などのパラメータをそれぞれの金融商品に適したものにする必要がある。

つぎに保険提案サーバ１００の機能構成について説明する。図２は、保険提案サーバ１００の機能を示すブロック図である。図２に示される通り、保険提案サーバ１００は、ユーザ情報収集部１０１（ユーザ情報取得部）、リスク算出部１０２、保険データベース１０３（金融商品データベース）、リスクデータベース１０４、提案モデル学習部１０５、提案モデルデータベース１０６、依頼受付部１０７、保険提案処理部１０８（予測部、金融商品情報取得部）、保険提示部１０９（提供部）、および保険ＤＢ更新部１１０（更新部）を含んで構成されている。以下、各構成について説明する。

ユーザ情報収集部１０１は、所定のタイミングまたは保険提案サーバ１００の運営者による指示したがって、ユーザ情報データベース３００からユーザ情報を収集する部分である。ユーザ情報は、例えば、ユーザ端末２００の位置情報、サービス利用情報、そのユーザの属性（性別、年代、など）である。

リスク算出部１０２は、ユーザ情報からユーザごとのリスクを算出する部分である。リスクは、ユーザの危険度を示す。ユーザがある行動をする頻度が多い場合には、その行動に対して危険度が増すことが一般的である。

例えば、リスク算出部１０２は、位置情報に基づいて、レジャー施設に所定回数行くと判断する場合には、その頻度に応じて、旅行リスクを算出する。また、位置情報に基づいて病院に行く回数に応じて、健康リスクを算出する。また、位置情報から自動車を運転していると判断する場合には、その運転頻度または運転距離などに基づいて交通リスクを算出する。アンケートまたはユーザの属性などに基づいて住宅を購入したか否かに基づいて住宅リスクを算出する。また、購入時期からの経過時間に応じて住宅リスクを算出してもよい。上記各リスクは、頻度をそのままリスク値としてもよいし、正規化などの処理をしてもよい。また、上記リスクは一例であり、そのほか様々なユーザ情報を用いて、様々な種類のリスクを算出することができる。

なお、リスク算出部１０２は、機械学習により構築されたリスクモデルを用いて、ユーザごとのリスクを算出するようにしてもよい。例えばリスクモデルは、ユーザ状態を入力とし、そのユーザ情報ごとに生じたリスクを教師信号として、構築されたモデルである。

保険データベース１０３は、初期状態においては、保険会社によって定義された、リスクと制約条件とに対する加入すべき保険の定型の組み合わせである定型保険情報を記憶する部分である。この定型保険情報は、全てのパターンを網羅されていなくても良い。さらに、更新処理によって、実際に保険に加入しているユーザのリスク、制約条件、およびその加入している保険の組み合わせである加入保険情報を合わせて記憶している。加入保険情報は、後述する通り、保険ＤＢ更新部１１０により適宜追加または更新される。制約条件とは、ユーザが保険に対して支払うことができる上限金であったり、保険に対する補償方針（補償内容がバランス型、アクティブ型など）などを示す情報である。

リスクデータベース１０４は、リスク算出部１０２によりユーザ情報から算出されたリスク情報を記憶する部分である。例えば、リスク情報として、旅行リスク、病気リスク、交通リスク、住宅リスクなどがあげられる。例えば、旅行リスクは、ユーザの旅行頻度が大きい場合には、そのリスクは高い数値となる。

提案モデル学習部１０５は、保険データベース１０３を参照して、機械学習をするための提案モデルを構築する部分である。初期状態では、提案モデル学習部１０５は、定型保険情報に基づいて提案モデルを構築する。その後、ユーザが契約した保険を示す加入保険情報をも考慮して提案モデルは学習される。この提案モデルは、一般的な機械学習を可能にするものであり、例として、入力層、一または複数の中間層（隠れ層）、および出力層からなるニューラルネットワークで構築されている。保険データベース１０３の定型保険情報および加入保険情報などを用いて誤差逆伝搬法を用いて、各層に設定されている重み係数を修正することで提案モデルは構築され、また更新（学習）される。

本実施形態においては、入力層からリスク情報、制約条件が入力され、出力層から各種保険の組み合わせが出力される。学習に際しては、各種保険の組み合わせが教師信号となり、誤差逆伝播法を使って学習処理がなされる。

提案モデルデータベース１０６は、一般的な機械学習を可能にするための入力層、一または複数の中間層（隠れ層）、および出力層からなるニューラルネットワークで構築されているモデルを記憶する部分である。なお、提案モデルデータベース１０６は、ニューラルネットワークに限定されるものではなく、他の形態の学習モデル、例えばサポートベクターマシンなどを用いたものでであってもよい。

依頼受付部１０７は、ユーザ端末２００から保険提案の依頼を受け付ける部分である。この依頼には、ユーザＩＤおよび制約条件が含まれている。なお、制約条件は必須ではない。

保険提案処理部１０８は、依頼受付部１０７により受け付けられたユーザＩＤをキーにして、リスクデータベース１０４から、当該ユーザのリスク情報を取得する。さらに、保険提案処理部１０８は、提案モデルデータベース１０６から提案モデルを取得し、リスク情報、制約条件および提案モデルから、保険の組み合わせを推定する。なお、制約条件は必須ではない。保険の組み合わせは、あらかじめ定めた保険の組み合わせに対して、その評価値を付すことで表現される。例えば、予め定めた保険の組合せとして、Ａ保険からＤ保険があるとし、各保険の評価値は０から１の間で表現されるものとする。提案モデルを経て、Ａ保険は０．８、Ｂ保険は０．４の評価値が算出されたとすると、０．５以上が適正な保険であるとした場合には、Ａ保険に肯定的な情報を付与することで提案対象とし、Ｂ保険に否定的な情報を付すことで提案しない対象とする。Ｃ保険、Ｄ保険も同様とする。

保険提示部１０９は、保険提案処理部１０８が取得した保険の組み合わせである提案保険情報を含んだ保険画面データを生成して、ユーザ端末２００に送信する部分である。そして、保険提示部１０９は、提案保険情報に対して、ユーザから保険ごとにその可否を受け付ける。提案された保険に対して否定的な指示であったり、逆に提案されなかった保険に対して肯定的な指示があった場合には、その指示を保険ＤＢ更新部１１０に受け渡す。

保険ＤＢ更新部１１０は、保険提示部１０９から受けとった各提案保険に対する可否情報に基づいて、保険データベース１０３を更新する部分である。また、保険ＤＢ更新部１１０は、保険データベース１０３に更新処理を行うとともに、契約のための情報を生成し、契約情報サーバ（図示せず）に対して契約処理を行う。契約情報サーバでは、保険情報を登録することにより契約が完了したことになる。なお、契約に際してはユーザに対して、契約の意思を確認することとしてもよい。

つぎに、このように構成された保険提案サーバ１００の動作について説明する。図３は、保険提案サーバ１００における提案モデルを構築するときの処理を示すフローチャートである。提案モデル学習部１０５は、保険データベース１０３からリスク情報、制約条件、および保険組み合わせを取得する（Ｓ１０１）。

提案モデル学習部１０５は、リスク情報および制約条件が入力とし、保険組み合わせが教師信号として、誤差逆伝播処理を行うことにより、学習処理を行う（Ｓ１０２）。なお、学習処理としては、サポートベクターマシンなど他のモデルを用いる場合にはそのモデルに応じた処理に従って行われる。

提案モデル学習部１０５は、提案モデルを構築して、提案モデルデータベース１０６に記憶する（Ｓ１０３）。これらからなる処理は、所定のタイミングまたはその指示にしたがって行われる。

なお、初期時においては、保険データベース１０３には、保険会社が定義した定型保険が登録されている。これら学習処理または保険加入が進むと、実際に加入された加入保険が、保険データベース１０３に登録され、それら定型保険および加入保険を用いて提案モデルが構築される。

図４は、提案モデルを構築または学習したときの模式図である。図４に示される通り、保険データベース１０３からリスク情報、制約条件、および保険組み合わせが取得されている。図４の例では、リスク情報として、旅行リスク、病気リスク、交通リスク、住宅リスクの項目があげられる。それぞれ数値が示されており、どの程度のリスクであるかを示している。初期状態では、保険会社により、リスク情報の数値を変えたリスクパターンと、制約条件とが入力として定義されており、それらに合わせた保険の組み合わせが教師信号として定義されている。これら情報を用いて学習処理を行うことで提案モデルが構築される。

提案される保険の組合せでは、加入すべき保険には、肯定的情報として○が付与され、加入する必要がない保険には、否定的情報として×が付与されている。学習モデルを構築する上では、例えば、肯定的情報を１とし、否定的情報を０として、学習処理を行うことになる。

つぎに、リスクデータベース１０４を構築または更新するときの処理について説明する。図５は、リスク算出部１０２の動作を示すフローチャートである。リスク算出部１０２は、所定のタイミングまたは保険提案サーバ１００の運営者の指示に従って、ユーザ情報データベース３００からユーザ情報を収集する（Ｓ２０１）。リスク算出部１０２は、収集したユーザ情報に基づいて、各ユーザのリスクを算出する（Ｓ２０２）。そして、リスク算出部１０２は、リスクデータベース１０４を構築または更新する（Ｓ２０３）。

上記のリスク算出処理は、定期的または運営者の指示に従って行われ、ユーザの最新のリスク状況が管理される。

図６は、リスク算出処理を模式的に示した模式図である。図６に示されるとおり、ユーザ情報データベース３００から取り出されたユーザ情報は、リスク算出部１０２のリスク判定処理に従って、リスク情報が算出される。そして、リスク情報は、リスクデータベース１０４に、各ユーザＩＤに対応付けて記憶される。図６においては、複数のユーザそれぞれのユーザ情報からそれぞれのユーザのリスク情報が算出されているが、一のユーザのリスク情報のみを算出してもよい。

つぎに、提案モデルを用いた保険提案処理について説明する。図７は、保険提案サーバ１００における保険提案動作を示すフローチャートである。依頼受付部１０７は、ユーザ端末２００から保険提案の依頼（ユーザＩＤおよび制約条件を含む）を受け付ける（Ｓ３０１）。保険提案処理部１０８は、保険提案の依頼に含まれているユーザＩＤをキーにしてリスクデータベース１０４から当該ユーザのリスク情報を取得する（Ｓ３０２）。

そして、保険提案処理部１０８は、リスク情報、制約条件および提案モデルを用いて、一または複数の保険の組合せを推定し、保険提示部１０９は、ユーザ端末２００に対して、保険の組合せを示す提案保険情報を送信する（Ｓ３０３）。ここでは、保険提案処理部１０８が、一または複数の保険の組合せとして、提案モデルの出力層から出力された各数値を、各保険の評価値として取得し、保険提示部１０９がその評価値を保険ごとに対応付けた情報を提案保険情報として送信する。その際、その評価値が閾値以上である場合には、提案対象であることを示す肯定的な情報（すなわち○）で表現し、その評価値が閾値未満である場合には、提案対象ではないことを示す否定的な情報（すなわち×）で表現してもよい。

保険提示部１０９は、ユーザ端末２００から、提案された各保険に対して、修正するかまたは了承するかを示す修正情報を受け付ける（Ｓ３０４）。保険ＤＢ更新部１１０は、修正情報に基づいて、保険データベース１０３を更新する（Ｓ３０５）。

図８を用いて、この提案モデルを使った保険の提案および保険データベース１０３の更新処理を模式的に説明する。

図８（ａ）においては、ユーザＩＤ：Ｕ１（以降ユーザＵ１と称す）のリスク情報および制約条件が、依頼受付部１０７により受け付けられる。保険提案処理部１０８は、これを提案モデルに入力し、保険の組合せを示す提案保険情報を推定する。図８（ａ）において、予め定められた保険の組合せとして、Ａ保険、Ｂ保険、Ｃ保険、Ｄ保険の組合せが定義されており、そのうち、Ａ保険およびＢ保険が肯定的な情報で示され、Ｃ保険およびＤ保険は否定的な情報で示されている。肯定的な情報は、ユーザに対して適切な保険であることを示し、否定的な情報は、適切な保険ではないことを示す。

なお、肯定的または否定的な情報で表現することにかえて、提案モデルの出力層の値をそのまま出力してもよい。その場合、ユーザは、出力層の値（評価値）をそのまま見ることができ、提案内容の違いを数値で判断することができる。例えば、Ｂ保険は評価値０．６であり、Ｃ保険は評価値０．５であったとした場合、保険会社（または本システムの運営者）が定義した閾値によって、Ｂ保険に肯定的情報を付与したが、ユーザにとっては、Ｃ保険もＢ保険に遜色がない保険と判断することができる。評価値をユーザに提示することで、ユーザが加入する保険に対する評価をしやすくなる。

ユーザは、提案された保険の組合せを受け入れる場合には、ユーザ端末２００を操作することによりユーザ端末２００から、了承の旨を保険提案サーバ１００に送信する。修正する場合には、その修正した情報（○または１で修正）をユーザ端末２００に入力し、その修正情報（○に修正された場合は１となる）を保険提案サーバ１００に送信する。

図８（ａ）においては、ユーザは、Ｂ保険よりＣ保険の方が適切であると考え（処理Ｐ１）、Ｂ保険を否定的とし、Ｃ保険を肯定的とした修正情報をユーザ端末２００に登録し（修正Ｐ２）、ユーザ端末２００は、その修正情報を保険提案サーバ１００（保険提示部１０９）に送信する。

図８（ｂ）に示されるとおり、保険ＤＢ更新部１１０は、ユーザＵ１のリスク情報、制約条件に加え、修正情報（修正Ｐ２）の保険の組合せを、保険データベース１０３に登録することで、ユーザＵ１の保険データベースを更新する（処理Ｐ３）。

図８において、保険組合せは、肯定的情報として○で、否定的情報として×で示した。ユーザ端末２００は、ユーザから修正情報を受け付ける際に、肯定的情報から否定的情報に修正する場合には、その評価値を０に修正し、否定的情報から肯定的情報に修正する場合には、１に修正する。なお、０または１に限定するものではなく、その評価値が肯定的または否定的な情報となるよう閾値に基づいて修正してもよい。

図９は、ユーザ端末２００における、提案保険情報を含む表示画面例を示す。図９に示される保険画面を構成するデータを保険提案サーバ１００（保険提示部１０９）はユーザ端末２００に送信し、ユーザ端末２００は、このデータを受信して、保険画面を表示する。

保険画面Ｇは、加入者（依頼したユーザ）の氏名欄Ｇ１、現在の加入している保険金額欄Ｇ２、リスクチャート欄Ｇ３、加入保険情報欄Ｋ、提案保険情報欄Ｔを含んでいる。

氏名欄Ｇ１および保険金額欄Ｇ２は、保険会社が所有する契約者データベース（図示せず）に登録されている保険の加入者の氏名およびその加入者が加入している保険金額を表示する部分である。これら情報は、保険提案サーバ１００が、契約者データベースにアクセスすることで取得される。

リスクチャート欄Ｇ３は、ユーザの危険度を示すリスクチャートＲ１と、提案している保険がカバーするリスクチャートＲ２と、現在加入している保険がカバーしているリスクチャートＲ３と、を示す。このように現在加入中の保険のカバー範囲、提案中の保険のカバー範囲が重ね合わせて、対比可能な形で表示される。なお、リスクチャートＧ３は、必須ではなく、いずれのチャートがあればよいし、必ずしも必要な項目ではない。

提案している保険および加入している保険のそれぞれがカバーする範囲）について、その補償対象および補償金額などに基づいて、ユーザのリスクのカテゴリのそれぞれに対して、カバーの度合いを示すパラメータ（またはベクトルで表現してもよい）が、予め設定されており、そのパラメータに基づいてカバーの範囲が定められる。

例えば、生命保険を例に説明すると、その保障額、補償内容（病気・事故補償など）に基づいて、リスクのカテゴリ：健康に対してパラメータが設定されている。このパラメータに基づいて、カバー範囲が定められ、ユーザのリスクチャートに合成される。なお、複数の生命保険に加入している場合には、そのパラメータが加算されてもよいし、よりカバーの範囲が広い生命保険だけを採用してもよい。このパラメータは、ユーザのリスクと対比可能に調整された値である。このカバー範囲を算出する処理は、保険提案処理部１０８により行われる。

加入保険情報欄Ｋは、氏名欄Ｇ１に記載のユーザが加入している保険の組合せを表示する部分である。この加入保険情報欄Ｋは、さらに保険欄Ｋ１と保険の加入の有無を示す欄Ｋ２を含む。図９においては、Ａ保険からＤ保険のそれぞれにおいて加入・未加入が表示されている。

提案保険情報欄Ｔは、保険提案サーバ１００が提案した提案保険を表示する提案保険欄Ｔ１と、その評価値を表示する評価値欄Ｔ２を含む。なお、図９では、評価値欄Ｔ２には、評価値が表示されているが、これに限らず、評価値に基づいた肯定的情報、または否定的情報を示す符号で表現してもよい。

ユーザ端末２００のユーザは、この画面を見ながら、提案保険欄Ｔ１に記載の各保険から加入を継続するか、または変更するかなどを決めることができる。

つぎに、保険提案処理部１０８における変形例について説明する。上記実施形態においては、保険提案処理部１０８は、依頼者であるユーザに対して提案モデルを使って得た適切な保険の組合せを提示した。さらに加えて、そのユーザと、リスクが似ている他のユーザが加入した保険の組合せをあわせて提示することもできる。

例えば、保険提案処理部１０８は、リスクデータベース１０４から、ユーザのリスクと相関の高い、一または複数の他のユーザのユーザＩＤを取得する。そして、保険提案処理部１０８は、そのユーザＩＤを用いて保険データベース１０３を参照し、その他のユーザが加入している保険の組合せを取得する。保険提示部１０９は、ユーザに対して保険の組合せを提示するとともに、取得した他のユーザが加入している保険の組合せを提示することができる。

なお、保険提示部１０９は、複数の他のユーザの保険の組合せを全て提示してもよいし、保険提案処理部１０８は、加入している保険に対応付けられている評価値の平均値を算出し、保険提示部１０９は、その平均値をユーザに提示してもよい。評価値の平均値は、加入を１、未加入を０として計算することができる。

さらに、保険提示部１０９は、ユーザに提案した提案保険、またはユーザが加入している保険に加入している別のユーザのリスクを提示しても良い。すなわち、保険提案処理部１０８は、提案した保険または加入している保険の組合せをキーにして、別のユーザＩＤを、保険データベース１０３から取得し、そのユーザのリスクをリスクデータベース１０４から取得する。保険提示部１０９は、そのリスクをユーザに提示することができる。これによって、ユーザのフィードバックのしやすさ向上に繋がる。なお、保険提案処理部１０８は、他のユーザが加入している保険の情報を、保険データベース１０３または、そのほかの全ユーザの保険の管理をしているデータベースから取得できる。また、提案した保険の情報についてはは、ユーザごとに、提案保険内容の履歴を記憶するデータベース（図示せず）を用意しておき、そのデータベースから必要な情報を取得することもできる。

保険データベースには、加入保険情報として、「ユーザのリスクに対する保険の組み合わせ」が記録されているため、例えば「Ａ保険に入っている全ユーザのリスクの平均値」を出したい場合でも、保険データベース１０３だけでもリスクが取得可能であり、リスクデータベース１０４へのアクセスは不要である。

図１０を用いて、ユーザ端末２００の表示画面を示す。図１０は、保険画面Ｇに、他の加入者情報欄Ｓを加えた保険画面Ｇ１０を示す。

他の加入者情報欄Ｓは、他のユーザが加入可能な保険欄Ｓ１およびその加入の有無を示す欄Ｓ２を含む。上述したとおり、保険提案サーバ１００（保険提案処理部１０８）が、リスクデータベース１０４を参照して、ユーザのリスク情報と類似するリスク情報を有する他のユーザおよびその加入保険情報を取得することができる。なお、ここでは個人を特定しないようにすることがよい。また、他のユーザを複数取得し、加入・未加入の平均値をとるようにしてもよい。

さらに加えて、保険提案処理部１０８は、各保険同士の類似度を事前に計算または設定しておき、保険提示部１０９は、ユーザが対比しやすいように、類似する保険同士を枠でくくるなどした保険画面を生成してもよい。類似度の計算については、事前に保険ごとに特徴ベクトルが付与されおり、その特徴ベクトルに基づいて類似度の計算が行われる、などが考えられる。類似度に代えて、事前に定めた各保険のカテゴリごとに表示するようにしてもよい。

図１１は、その具体例を示すユーザ端末２００の表示画面例である。ここでは、図９等における加入保険情報欄Ｋを、さらに相互に類似している保険同士を関連付けた画面としている。図１１では、例えば生命保険情報欄Ｋ１０、自動車保険情報欄Ｋ２０のカテゴリを作っておき、その中で加入保険を示している。例えば、図１１においては、Ａ１保険とＡ２保険とは同じカテゴリである生命保険であると定義されている。提案保険についても同様であり、提案生命保険情報欄Ｔ１０、提案自動車保険欄Ｔ２０等を表示しており、それぞれＡ１保険、Ａ２保険のように関連する保険が対応付けられている。

これら同じカテゴリは、事前に保険提案サーバ１００の運営者により定義されるか、または保険ごとに割当てられた特徴ベクトルに基づいて定義されることになる。

ユーザは、この提案保険を見ることにより、同じカテゴリ内の保険でいずれを選択すべきか、判断することができる。

つぎに、本実施形態の保険提案サーバ１００の作用効果について説明する。本実施形態の保険提案サーバ１００は、ユーザの生活状態に対するリスクごとに、保険の組合せを記憶する保険データベース１０３と、当該保険データベースに基づいて構築された提案モデルとを記憶する提案モデルデータベース１０６と、依頼者であるユーザのユーザ情報に基づいて、当該ユーザのリスクを算出するリスク算出部１０２と、ユーザのリスクおよび提案モデルに基づいて、ユーザに対する保険の組合せを予測する保険提案処理部１０８と、保険の組合せを示す提案保険情報（金融商品に対しては提案金融保険情報に相当）をユーザに提供する保険提示部１０９と、提案保険情報に対するユーザからの指示に基づいて保険データベースを更新する保険ＤＢ更新部１１０と、を備え、提案モデルは、保険ＤＢ更新部１１０により更新された保険データベース１０３に基づいて、再構築され、ユーザおよび他のユーザに対する保険の組合せを予測する際に使用される。

この保険提案サーバ１００によれば、提案モデルに基づいてユーザにとって適切な保険の組合せを提案することができる。そして、この提案モデルは提案した保険に対するユーザからのフィードバックに応じて再構築されるため、保険会社のみならず、他の保険加入者である他のユーザの動向に応じた適切な提案モデルを構築することができ、それに応じた保険の提案をすることができる。

また、保険提案サーバ１００において、提案モデルは、リスクに加えて、ユーザの保険に対する制約を定めた制約条件に基づいて構築されており、保険提案処理部１０８は、さらに制約条件を考慮して保険の組合せを予測する。

一般的に、保険に加入する際において、月々に支払うことができる上限金額および保険の補償方針（費用対効果にバランスがとれているもの、死亡保障が手厚いものなど）などの制約条件を考慮する必要がある。本保険提案サーバ１００においては、制約条件を考慮して提案モデルが構築されていることから、ユーザにとって、より適切な保険を提案することができる。

また、保険提案サーバ１００において、ユーザのユーザ情報を取得するユーザ情報収集部１０１をさらに備え、リスク算出部１０２は、ユーザ情報収集部１０１により取得されたユーザ情報からリスクを算出する。

この保険提案サーバ１００によれば、ユーザ情報を利用して、ユーザのリスクを算出することができる。例えば、ユーザ情報とは、年齢、性別などのいわゆるユーザ属性のほか、位置情報があり、これに基づいてユーザの旅行の頻度などを把握することができる。したがって、これに基づいてリスクを判断することで、ユーザの生活状況に応じた適切な保険を提案することができる。

また、保険提案サーバ１００において、保険提示部１０９は、提案保険情報を、保険ごとにその妥当性を示す評価値を含めて提供する。

この保険提案サーバ１００によれば、提案モデルから出力される評価値をユーザに提示することができる。ユーザは、その評価値を参考に、提案された保険の可否を判断することができる。

また、保険提案サーバ１００において、保険提示部１０９は、ユーザが現に加入している保険を示す加入保険情報（金融商品一般に対しては購入金融商品情報に相当）を、提案保険情報と対比可能にして提供する。なお、保険を含めて一般的な金融商品を指す場合には、すでに購入済みの購入金融商品と称する。

この保険提案サーバ１００によれば、ユーザは、その加入保険情報を参考に、提案された保険の可否を判断することができる。

また、保険提案サーバ１００において、保険提示部１０９は、ユーザのリスクを示すリスク情報を、提案保険情報と対比可能にして提供する。

この保険提案サーバ１００によれば、ユーザは、リスク情報を参考に、提案された保険の可否を判断することができる。

また、この保険提案サーバ１００において、提案モデルデータベース１０６の提案モデルおよび／またはリスクデータベース１０４は、予め定めた条件に従って更新されており、保険提案処理部１０８は、ユーザからの依頼に基づいて条件に応じた提案モデルおよびリスクデータベースを利用する。

この保険提案サーバ１００によれば、予め定めた条件にしたがって更新された提案モデルおよびリスクに基づいてユーザに保険の提案を行うことができる。予め定めた条件とは、例えば、予め定めた年月日に更新する、などである。これにより、常に最新の提案モデルが構築され、ユーザにより適切な保険を提案することができる。

そのほか、保険提案サーバ１００は、季節ごとのリスクおよび提案モデルを構築または更新しておいてもよい。例えば、リスク算出部１０２は、夏の季節（例えば、７月-８月の期間）のユーザ情報を用いてリスクを算出しておき、提案モデル学習部１０５は、それに応じて提案モデルを構築する。そして、保険提案サーバ１００は、季節に応じた提案モデルおよびリスク情報を用いた保険提案処理を行ってもよい。その際、ユーザは保険提案の依頼時に、時期・季節を指定するか、または保険提案サーバ１００が依頼を受けた時期・季節に基づいて、季節を特定する。

また、この保険提案サーバ１００において、保険提案処理部１０８（金融商品情報取得部）は、ユーザのリスク情報に基づいて、他のユーザが加入している保険の組合せを示す他の加入保険情報を保険データベースから取得し、保険提示部１０９は、取得された他の加入保険情報を、ユーザの提案保険情報とともに提供する。

これにより、例えば、ユーザは、リスクが似た他のユーザの加入保険情報と対比しながら、提案保険情報を見て判断することができる。これによって、より自分に適したと考える保険を選択することができる。

以上の通り、本実施形態においては、生命保険、損害保険、傷害保険などの保険を例に説明したが、これに限るものではない。例えば、その他の金融商品にも適用することが考えられる。例えば、どのような債券・株式に投資するか、ユーザの生活状態に応じて適切な投資先を提案することができる。

上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。

機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、割り振り（assigning）などがあるが、これらに限られない。たとえば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting unit）や送信機（transmitter）と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。

例えば、本開示の一実施の形態における保険提案サーバ１００およびユーザ端末２００などは、本開示の保険提案方法の処理を行うコンピュータとして機能してもよい。図１２は、本開示の一実施の形態に係る保険提案サーバ１００およびユーザ端末２００のハードウェア構成の一例を示す図である。上述の保険提案サーバ１００およびユーザ端末２００は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。保険提案サーバ１００およびユーザ端末２００のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

保険提案サーバ１００およびユーザ端末２００における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１００１が演算を行い、通信装置１００４による通信を制御したり、メモリ１００２及びストレージ１００３におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）によって構成されてもよい。例えば、上述のリスク算出部１０２、提案モデル学習部１０５、保険提案処理部１０８、保険ＤＢ更新部１１０などは、プロセッサ１００１によって実現されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール、データなどを、ストレージ１００３及び通信装置１００４の少なくとも一方からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、保険提案サーバ１００のリスク算出部１０２等は、メモリ１００２に格納され、プロセッサ１００１において動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１によって実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つによって構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本開示の一実施の形態に係る保険提案方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つによって構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及びストレージ１００３の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置１００４は、例えば周波数分割複信（ＦＤＤ：Frequency Division Duplex）及び時分割複信（ＴＤＤ：Time Division Duplex）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。例えば、上述のユーザ情報収集部１０１、保険提示部１０９などは、通信装置１００４によって実現されてもよい。ユーザ情報収集部１０１と、保険提示部１０９とは、物理的に、または論理的に分離または合体された実装がなされてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１、メモリ１００２などの各装置は、情報を通信するためのバス１００７によって接続される。バス１００７は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。

また、保険提案サーバ１００およびユーザ端末２００は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。

情報の通知は、本開示において説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、報知情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。

本開示において説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ（4th generation mobile communication system）、５Ｇ（5th generation mobile communication system）、ＦＲＡ（Future Radio Access）、ＮＲ（new Radio）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ（登録商標））、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及びこれらに基づいて拡張された次世代システムの少なくとも一つに適用されてもよい。また、複数のシステムが組み合わされて（例えば、ＬＴＥ及びＬＴＥ−Ａの少なくとも一方と５Ｇとの組み合わせ等）適用されてもよい。

本開示において説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。

入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

本開示において説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：Digital Subscriber Line）など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。

本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及びシンボルの少なくとも一方は信号（シグナリング）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ：Component Carrier）は、キャリア周波数、セル、周波数キャリアなどと呼ばれてもよい。

本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。

また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースはインデックスによって指示されるものであってもよい。

上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的な名称ではない。

本開示においては、「移動局（ＭＳ：Mobile Station）」、「ユーザ端末（user terminal）」、「ユーザ装置（ＵＥ：User Equipment）」、「端末」などの用語は、互換的に使用され得る。

ユーザ端末は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、又はいくつかの他の適切な用語で呼ばれる場合もある。

基地局及び移動局の少なくとも一方は、送信装置、受信装置、通信装置などと呼ばれてもよい。なお、基地局及び移動局の少なくとも一方は、移動体に搭載されたデバイス、移動体自体などであってもよい。当該移動体は、乗り物（例えば、車、飛行機など）であってもよいし、無人で動く移動体（例えば、ドローン、自動運転車など）であってもよいし、ロボット（有人型又は無人型）であってもよい。なお、基地局及び移動局の少なくとも一方は、必ずしも通信動作時に移動しない装置も含む。例えば、基地局及び移動局の少なくとも一方は、センサなどのＩｏＴ（Internet of Things）機器であってもよい。

本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up、search、inquiry)（例えば、テーブル、データベース又は別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、「みなす（considering）」などで読み替えられてもよい。

「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」又は「結合」されると考えることができる。

本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

本開示において、「含む（include）」、「含んでいる（including）」及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。

本開示において、例えば、英語でのa, an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。

本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。

１００…保険提案サーバ、２００…ユーザ端末、３００…ユーザ情報データベース、１０１…ユーザ情報収集部、１０２…リスク算出部、１０３…保険データベース、１０４…リスクデータベース、１０５…提案モデル学習部、１０６…提案モデルデータベース、１０７…依頼受付部、１０８…保険提案処理部、１０９…保険提示部、１１０…保険ＤＢ更新部。

Claims (10)

1. リスクごとの金融商品の組合せを示す保険情報に基づいて、入力されたリスクに対応する金融商品の組合せを出力する提案モデルを構築する学習部と、
   ユーザの行動または属性を示すユーザ情報に基づいて、当該ユーザの行動または属性に対するリスクを示すリスク値を算出するリスク算出部と、
   前記ユーザのリスク値を前記提案モデルに入力することで、前記ユーザに対する金融商品の組合せを導出する導出部と、
   前記金融商品の組合せを示す提案金融商品情報を前記ユーザに提供する提供部と、
   を備え、
   前記提案モデルは、前記提供部により提供された提案金融商品情報に対する前記ユーザからの修正情報によって更新される前記リスクごとの金融商品の組合せに基づいて、前記学習部により再構築され、前記ユーザおよび他のユーザに対する金融商品の組合せを導出する際に使用される、
   金融商品提案装置。
2. 前記提案モデルは、前記リスクに加えて、前記ユーザの前記金融商品に対する制約を定めた制約条件に対応する金融商品の組み合わせを出力するように構築されており、
   前記導出部は、さらに前記制約条件を前記提案モデルに入力して、金融商品の組合せを導出する、
   請求項１に記載の金融商品提案装置。
3. リスクごとの金融商品の組合せを記憶する金融商品データベースを記憶する記憶部と、 前記提案金融商品情報に対する前記ユーザからの指示に基づいて金融商品データベースを更新する更新部をさらに備え、
   前記提案モデルは、前記金融商品データベースに基づいて構築される、請求項１または２に記載の金融商品提案装置。
4. 前記導出部は、前記提案モデルから出力され、前記組合せを導出する際に使用される出力値を、金融商品の妥当性を示す評価値として取得し、
   前記導出部は、前記提案金融商品情報に、金融商品ごとにその妥当性を示す評価値を含めて提供する、請求項１〜３のいずれか一項に記載の金融商品提案装置。
5. 前記提供部は、前記ユーザが現に購入している金融商品を示す購入金融商品情報を、前記提案金融商品情報と対比可能にして提供する、請求項１〜４のいずれか一項に記載の金融商品提案装置。
6. 前記提供部は、前記ユーザのリスクを示すリスク情報を、前記提案金融商品情報と対比可能にして提供する、請求項１〜５のいずれか一項に記載の金融商品提案装置。
7. 前記提供部は、前記提案金融商品情報がカバーする範囲、および前記ユーザが現に購入している金融商品を示す購入金融商品情報がカバーする範囲の少なくとも一方を、前記ユーザのリスクを示すリスク情報と対比可能にして提供する、請求項１〜６のいずれか一項に記載の金融商品提案装置。
8. 前記提案モデルおよび／または前記リスクは、予め定めた条件に従って更新または算出されており、前記導出部は、前記ユーザからの依頼に基づいて、前記提案モデルおよび前記リスクを利用する、請求項１〜７のいずれか一項に記載の金融商品提案装置。
9. 前記ユーザのリスク情報に基づいて、任意のユーザが加入している金融商品の組合せを示す他の購入金融商品情報を前記金融商品データベースから取得する金融商品情報取得部をさらに備え、
   前記提供部は、前記金融商品情報取得部により取得された前記他の購入金融商品情報を、前記ユーザの提案金融商品情報とともに提供する、請求項３に記載の金融商品提案装置。
10. ユーザごとのリスクを記憶するリスクデータベースをさらに備え、
    前記ユーザに提案した金融商品の組合せまたは当該ユーザが有している金融商品の組合せに基づいて、当該金融商品の組合せを有する他のユーザを選択し、前記リスクデータベースから当該他のユーザのリスクを取得するリスク取得部をさらに備え、
    前記提供部は、当該他のユーザのリスクを、前記ユーザの提案金融商品とともに提供する、請求項１〜９のいずれか一項に記載の金融商品提案装置。

Images