JP6923890B1 - 顧客ライフイベント検知装置 - Google Patents

Abstract

【課題】顧客個人毎のライフイベントを検知する。【解決手段】本発明に係る顧客ライフイベント検知装置は、顧客の取引記録に関する取引データを含む金融機関の保有データを取得する取得手段と、前記顧客の取引データに基づいて、該顧客のライフイベントの発生を検知する検知手段と、前記顧客のライフイベントを出力する出力手段と、を有する。【選択図】図３

Description

本発明は、顧客ライフイベント検知装置に関する。

近年、金融機関の間では顧客が必要とする金融商品を適切なタイミングで提案するＥＢＭ（イベントベースドマーケティング）に注目がされ始めている。ＥＢＭは、顧客（ターゲット）の属性情報や取引行動上の変化を顧客データベースから検知し、これを金融ニーズ発生の契機（イベント）であると予測して、顧客が求める金融商品の提案を実施するマーケティング手法である。

これに関する技術として、例えば特許文献１には、金融機関における顧客のトランザクションデータを取得する取得手段と、過去に金融商品を購入した時点における顧客の第１トランザクションデータと、現時点における当該顧客の第２トランザクションデータとの関連を判定する関連判定手段と、第１トランザクションデータと第２トランザクションデータとが関連すると判定された顧客を抽出する抽出手段と、抽出された顧客を出力する出力手段と、を有する営業支援装置が記載されている。本発明によれば、金融機関における顧客のトランザクションデータに着目し、過去と現時点でのトランザクションデータの関連性に基づいて所定の金融商品にニーズが見込める顧客を精度よく抽出するため、金融機関における効率的な営業活動を支援することができる。

特許第６５５６９６９号公報

ここで、顧客個人を一人の人間として捉えた時に、顧客個人は自身の生活をより豊かに過ごすため一生の間に、自動車、住宅、家具、家電などの耐久消費財、食品、日常品などの日常消費財、外食、教養娯楽、宝飾品などの非耐久財、旅行、宝飾品などラグジュアリーな嗜好性消費財、それらに関連する決済手段、ローン等の金融商品、資金の運用や資産形成に関する金融商品など、金融商品の枠を超えた様々な商品やサービスを企業から受容（購入）する。

しかしながら、このような商品及びサービスのマーケティング上、顧客個人がこのような商品・サービスを受容するライフイベントの発生タイミングは、顧客個人毎のライフプロファイルやライフステージなどによって人それぞれであるので、そのようなライフイベントの発生タイミングを捕捉するのが困難である。

本発明は、上記の点に鑑み提案されたものであり、一つの側面において、顧客個人毎のライフイベントを検知することを目的とする。

上記の課題を解決するため、本発明に係る営業支援装置は、顧客及び該顧客と非相続人の関係を有する家族顧客の取引記録に関する取引データと顧客属性情報とを含む金融機関の保有データを取得する取得手段と、前記顧客及び前記家族顧客の取引データと顧客属性情報とに基づいて、該顧客及び該家族顧客のプロファイルを作成する作成手段と、前記顧客及び前記家族顧客のプロファイルに基づいて前記家族顧客が所定額以上の金融資産を有する場合であって、現時点における前記家族顧客のプロファイルと所定の過去時点における前記家族顧客のプロファイルとの特定の変化に基づいて、生じた該特定の変化が満たした予兆検知条件と対応付けられた相続イベントの発生の予兆を検知する予兆検知手段と、前記予兆検知手段により検知された前記家族顧客が非相続人となる前記顧客の相続イベントの発生の予兆を示す情報を出力する出力手段と、を有する。

本発明の実施の形態によれば、一つの側面において、顧客個人毎のライフイベントを検知することができる。

本実施形態に係る営業支援システムのネットワーク構成例を示す図である。 本実施形態に係る管理サーバのハードウェア構成例を示す図である。 本実施形態に係る管理サーバのソフトウェア構成例を示す図である。 本実施形態に係る金融機関の商品・サービス情報の一例を示す。 本実施形態に係る顧客属性情報の一例を示す。 本実施形態に係る普通預金口座情報及び普通預金取引明細の一例を示す。 本実施形態に係るクレジットカード情報及びクレジットカード利用明細の一例を示す。 本実施形態に係る商品等契約情報の一例を示す。 本実施形態に係る交渉履歴情報の一例を示す。 本実施形態に係る営業支援システムの処理の流れを説明する図である。 本実施形態に係る顧客プロファイルの一例を示す。 本実施形態に係る顧客プロファイルに基づくライフイベントの検知例を示す。 本実施形態に係るライフイベント及びレコメンド商品の対応例を示す。 本実施形態に係る顧客プロファイル作成・更新処理を示すフローチャートである。 本実施形態に係る顧客ライフイベントの検知処理及びレコメンド商品の出力処理を示すフローチャート１である。 本実施形態に係る顧客ライフイベントの検知処理及びレコメンド商品の出力処理を示すフローチャート２である。 本応用例に係る顧客プロファイルと車の価格帯別車種との対応一覧表を示す。 本実施形態に係る顧客プロファイル予兆更新処理を示すフローチャートである。 本実施形態に係る顧客プロファイルの一例を示す。 本実施形態に係る顧客ライフイベントの予兆検知処理及びレコメンド商品の出力処理を示すフローチャートである。

本発明の実施の形態について、図面を参照しつつ詳細に説明する。
[実施形態１]
＜概要＞
我々個人は日々金融機関との取引を行いながら、各々が様々なライフ活動を行っている。その活動は、長期的スパンで金融機関における顧客個人の属性データや取引データの時系列変化として記録されており、本出願人は金融機関におけるその記録が顧客個人のライフステージやライフスタイルを反映しうることに着目した。

本発明においては、金融機関における顧客個人の属性データや取引データの記録に基づいて、顧客毎に顧客プロファイルを作成するとともに、顧客個人自身の新たなライフイベントの発生可能性が高いとされる場合に、顧客個人の当該ライフイベントを検知する。

また、新たなライフイベントの発生は生活が新たなライフステージに変化する転機・出発点でもあるため、そのライフイベントに応じた商品・サービス、つまりその人にとって新たに必要となる商品・サービスの需要が発生する機会である。例えば、一人の人間が学校を卒業し、就職すればはじめに預金口座開設やクレジットカード発行の需要が発生するし、結婚により新婚旅行、賃貸への引っ越しなどの需要が発生する。また、子供が生まれれば住宅購入、保険加入（生命保険や学資保険）、子供が成長するにつれ車の購入、夏になれば毎年家族旅行の需要が発生する。やがて相続や定年退職となれば、資金運用のための投資信託需要も発生しうる。

このように、長期的スパンで一人の顧客毎の顧客プロファイルに基づくライフイベントを検知することで、顧客個人の新たに始まるライフステージに応じて需要が見込まれる商品・サービスをそのタイミングと共に予測することが可能となる。以下、詳しく説明する。

＜システム構成＞
（ネットワーク構成）
図１Ａは、本実施形態に係る営業支援システムのネットワーク構成例を示す図である。図１Ａの営業支援システム１００は、金融機関システム１０、管理サーバ２０、加工ＤＢ３０、顧客プロファイルＤＢ４０、及び支援端末５０を含み、ネットワーク７０を介して接続されている。

金融機関システム１０は、銀行等の金融機関が保有する各種システム及びＤＢ（データベース）ある。金融機関システム１０は、例えば、普通預金や定期預金などの各種預金及び口座情報を管理する基幹システム、金融商品の販売情報を管理する販売管理システム、顧客毎の資産運用ニーズに応じた金融商品を提案するためのフロントコンプライアンスシステム、交渉履歴を管理する履歴システム（ＣＲＭ）、及び各システムに伴う各種ＤＢを含む。

管理サーバ２０は、金融機関の保有データ（加工ＤＢ３０の加工データ）に基づいて、金融機関の顧客毎に顧客プロファイルを作成する営業支援装置（情報処理装置）である。顧客プロファイルは、例えば顧客の年齢、家族構成、賃貸・持ち家、職業、勤め先など、顧客個人自身のライフプロファイルに係る情報を集約したものである。顧客毎に作成された顧客プロファイルは、顧客プロファイルＤＢ４０に蓄積される。なお顧客プロファイルは、その他に例えば、顧客プロフィール、金融機関における顧客属性情報についてデータ項目を更に増加させた拡張版の顧客属性情報、拡張版の顧客個人情報などとも呼ぶこともできる。

また管理サーバ２０は、金融機関の保有データのうち特に取引に関するデータ（取引記録データという）をウォッチしている。管理サーバ２０は、取引データに特定の取引が発生し、顧客プロファイルとも照らし合わせて、その取引データの発生が顧客個人自身のライフイベントの発生を示す／又は示している可能性が高い場合、顧客個人の当該ライフイベントを検知する。そして管理サーバ２０は、当該顧客に対して当該ライフイベントに応じた商品・サービス（以下レコメンド商品という）を出力する。

加工ＤＢ３０は、金融機関システム１０による運用中の各種ＤＢから、金融機関の保有データ（加工前のため生データと呼ぶ）を逐次取得し、管理サーバ２０が計算処理が容易な形式に、取得した生データを加工した加工データを蓄積したＤＢである。機械学習手法は、テキスト、時系列データといった生の入力データはそのまま扱えないことが多いため、このような非構造データについては変換処理をかけてベクトルに変換する。なお、生データと加工データとは形式の違いはあれデータの持つ内容・意味自体は同じである。

支援端末５０は、例えばＰＣ（パーソナル・コンピュータ）、スマートフォン、タブレット端末などであって、所定の担当者が使用するユーザ端末である。支援端末５０には、管理サーバ２０から所定のアプリケーション・プログラム、又はウェブブラウザ等が予めインストールされる。担当者は支援端末５０を用いて管理サーバ２０にアクセスし、顧客個人のライフイベントや当該ライフイベントに応じたレコメンド商品の情報を取得し表示する。また、特定のレコメンド商品として条件入力することで、レコメンド商品に対応するライフステージにある顧客のリストも表示可能である。

なお、本実施形態に係るレコメンド商品は、ライフイベントに需要が想定される商品・サービスであるため、金融機関の取り扱う金融商品に必ずしも限定されるものではなく、
顧客が迎える様々なライフイベントやライフステージとそれぞれ関連性が高い商品・サービス群である。例えば、顧客が就職した場合にはクレジットカード発行の需要が発生するし、結婚により新婚旅行、賃貸への引っ越しなどの需要が発生する。また、子供が生まれれば住宅購入に伴う住宅ローン、保険加入（生命保険や学資保険）、子供が成長するにつれ車の購入、夏になれば毎年家族旅行の需要が発生する。やがて相続や定年退職となれば、資金運用のための投資信託需要も発生しうる。

（ハードウェア構成）
図１Ｂは、本実施形態に係る管理サーバのハードウェア構成例を示す図である。図１Ｂに示されるように、管理サーバ２０は、ＣＰＵ（Central Processing Unit）２１、ＲＯＭ（Read Only Memory）２２、ＲＡＭ（Random Access Memory）２３、ＨＤＤ（Hard Disk Drive）２４、及び通信装置２５を有する。

ＣＰＵ２１は、各種プログラムの実行や演算処理を行う。ＲＯＭ２２は、起動時に必要なプログラムなどが記憶されている。ＲＡＭ２３は、ＣＰＵ２１での処理を一時的に記憶したり、データを記憶したりする作業エリアである。ＨＤＤ２４は、各種データ及びプログラムを格納する。通信装置２５は、ネットワーク７０を介して他装置との通信を行う。

（ソフトウェア構成）
図１Ｃは、本実施形態に係る管理サーバのソフトウェア構成例を示す図である。管理サーバ２０は、主な機能部として、データ取得部２０１、顧客プロファイル作成部２０２、ライフイベント検知部２０３、及びレコメンド商品出力部２０４を有する。

データ取得部２０１は、金融機関の保有データを取得する機能を有している。顧客プロファイル作成部２０２は、金融機関における顧客の保有データに基づいて、顧客のプロファイルを作成する機能を有している。ライフイベント検知部２０３は、顧客のプロファイルに基づいて、当該顧客のライフイベントの発生を検知する機能を有している。レコメンド商品出力部２０４は、顧客にライフイベントの発生が検知された場合、当該顧客向けに発生が検知されたライフイベントに応じた商品又はサービスを出力する機能を有している。レコメンド商品出力部２０４は、併せて又は別途に発生が検知されたライフイベントを出力してもよい。

なお、各機能部は、管理サーバ２０を構成するコンピュータのＣＰＵ、ＲＯＭ、ＲＡＭ等のハードウェア資源上で実行されるコンピュータプログラムによって実現されるものである。これらの機能部は、「手段」、「モジュール」、「ユニット」、又は「回路」に読替えてもよい。また、管理サーバ２０の各機能部は単一のサーバ装置のみにより実現されるのみならず、機能分散させてネットワーク７０上の複数の装置からなるシステムとして実現してもよい。

（金融機関の保有データ）
次に、金融機関の保有データの一例を示す。但し言うまでもなく、以下に示されるデータ項目はあくまで一例であり、その他のデータ項目があってもよい。

図２Ａは、本実施形態に係る金融機関の商品・サービス情報の一例を示す。金融機関の取り扱う商品及びサービスとして、大きく例えば、預金、決済、保険、ローン、信託・年金といった種類の商品・サービスがある。またこのうち預金系には、例えば普通預金、当座預金、定期預金、外貨預金などがある。決済系には、クレジットカード、デビット、コード決済、外国送金などがある。保険系には、生命保険、傷害保険、学資保険などがある。ローン系には、住宅ローン、マイカーローン、教育ローン、フリーローン、カードローンなどがある。信託・年金系には、投資信託、個人型確定拠出年金、ＮＩＳＡ（少額投資非課税制度）などがある。

図２Ｂは、本実施形態に係る顧客属性情報の一例を示す。顧客属性情報は、金融機関の有する顧客毎の個人属性情報であり、例えば口座開設時や商品・サービス契約時等に顧客からの申請に基づいて登録される。例えば顧客属性情報は、氏名、性別、生年月日、住所、職業、勤務先、年収、家族構成、家族口座番号（法定相続関係にある家族の保有する当行銀行口座番号）、持ち家有無などの情報を有している。

図２Ｃは、本実施形態に係る普通預金口座情報及び普通預金取引明細の一例を示す。金融機関の預金口座の種類は、図２Ａに示されるように預金系の商品・サービスとして例えば普通預金、当座預金、定期預金、外貨預金などがあるが、各々の預金口座につき、店番号、顧客番号、口座番号、名義人など基本口座情報と、預金口座の取引毎に記録される預金取引明細とがある。

ここで、普通預金取引明細を参照すると、特に「摘要」欄には、例えば、振込１（ＡＴＭ）、振込２（本支店、他行窓口）振込２（モバイルバンキング）、給与（支払い元名）、賞与（支払い元名）、出金１（当行ＡＴＭ）、出金２（他行ＡＴＭ）、出金３（社内ＣＤ）、口座振替（引き落とし先名）、公共料金（電気、ガス、水道、電話、放送受信料）、社会保険料（国民年金、国民健康保険）、税金（所得税、住民税）、手数料、利息、振替（自動つみたて定期）、電話投票（公営競技）、配当、分配金、ローン返済（ローン名）など、取引内容が具体的にテキスト記述される。

このように、預金取引明細（普通預金、当座預金、定期預金、及び外貨預金の預金取引明細を含む）は、特に顧客がいつ、何を、いくらで取引したかの情報を把握しうる情報となる。

図２Ｄは、本実施形態に係るクレジットカード情報及びクレジットカード利用明細の一例を示す。決済系の商品・サービスとしてクレジットカードやデビットカードなどがあるが、このうち一例としてクレジットカードの基本カード情報と、カードの利用毎に記録されるクレジットカード利用明細を示す。

ここで、クレジットカード利用明細を参照すると、特に「加盟店名（ご利用先）」欄には、具体的にクレジットカードを利用した加盟店名が記述される。また例えば「摘要」欄には、購入した商品やサービス、もしくは海外利用に関する情報、国名、現地通貨額・換算レート・換算日為替レート、割引額・還元額、年利（支払区分が分割・リボ・キャッシングの場合）など、利用内容が具体的にテキスト記述される。このように、クレジットカードなど決済手段の利用明細は、特に顧客がいつ、どこで、何を、いくらで利用（購入）したかの情報を把握しうる情報となる。

図２Ｅは、本実施形態に係る商品等契約情報の一例を示す。契約系の商品・サービスとして保険やローンなどがあるが、このうち二例として生命保険契約情報及び住宅ローン契約情報を示す。生命保険契約情報としては、店番号、顧客番号、商品名、契約日、契約期間、契約者、非保険者、受取人、保険金額などがある。住宅ローン契約情報としては、店番号、顧客番号、商品名、契約日、契約期間、契約者、連帯保証人、融資金額、利子などがある。商品等契約情報は、特に顧客がいつ、何を（どんな目的で）契約したかの情報を把握しうる情報となる。

資産運用系の商品・サービスとして投資信託、年金などがあるが、このうち投資信託については例えば投信口座情報、預り残高情報、及び分配金償還明細情報を有している（非図示）。

図２Ｆは、本実施形態に係る交渉履歴情報の一例を示す。金融機関システム１０（交渉履歴を管理する履歴システム）においては、顧客毎に営業担当者や金融機関窓口担当者が行った交渉履歴、アンケート履歴が記録される。つまり顧客と金融機関との間における過去の全交渉履歴が管理される。交渉履歴情報は、特に顧客のニーズ、興味、考え、家族構成、現在のライフステージ、将来のライフプランなどの情報を把握しうる情報となる。

ここで、上述の顧客属性情報（図２Ｂ）は、比較的静的で変化しにくい情報である。一方、預金口座の取引明細（図２Ｃ）や決済手段の利用明細（図２Ｄ）、商品等契約情報（図２Ｅ）及び交渉履歴情報（図２Ｆ）は、顧客が金融機関と日々の取引を行うに伴って発生するため比較的動的で変化・更新されやすい情報であり、いわば日々の「取引データ」（トランザクションデータともいう）ということができる。一般に取引データとは、企業の情報システムなどが扱うデータの種類の一つで、業務に伴って発生した出来事の詳細を記録したデータのことをいう。

よって、預金口座の取引明細、クレジットカードの利用明細のような金融機関の取引データは、顧客の金融サービスの利用に伴い発生した事項を記録したデータである。また、取引データは、顧客属性情報のように登録時からそれほど頻繁には情報の変化がない情報と比べて、比較的に日々の情報変化（更新頻度）が多いデータである。但し、更新頻度は個々の顧客単位でみれば、当該顧客の金融サービスの利用頻度に依存する面もあることから、具体的な更新頻度の多寡は問わない。

＜システム処理の流れ＞
図３は、本実施形態に係る営業支援システムの処理の流れを説明する図である。
（１）各種データの集約・名寄せ
管理サーバ２０は、金融機関システム１０による運用中の各種ＤＢから、金融機関の保有データ（生データ）を取得し、顧客毎にデータを集約し、名寄せし、管理サーバ２０が計算処理可能な形式にデータ加工し、加工データを加工ＤＢ３０に蓄積する。

また、管理サーバ２０は、所定の更新サイクル毎に同様の処理を実行し、加工ＤＢ３０の加工データを更新する。更新サイクルは、運用に応じて、例えば数秒〜数十秒毎、１分毎、数分〜数十分毎、１時間毎、数時間毎、１日毎、所定日毎など任意に設定することが可能であるが、更新間隔は短いほどよく、金融機関システム１０のＤＢ上の生データの更新とともにリアルタイムに更新されると望ましい。これにより、加工ＤＢ３０には、生データと加工データとは形式の違いはあるものの、上記更新間隔毎に金融機関システム１０のＤＢと同等のデータが保持される。

（２）顧客プロファイル作成・更新
次いで、管理サーバ２０は、加工ＤＢ３０の加工データ（金融機関の保有データ）を用いて金融機関の顧客毎に顧客プロファイルを作成・更新する。

図４は、本実施形態に係る顧客プロファイルの一例を示す。図４に示されるように顧客プロファイルは、顧客毎に例えば顧客ＩＤ、氏名、住所、生年月日、年齢、性別、家族構成（同居）、第一子生年月日、第二子生年月日、第一子学校、第二子学校、両親・親族、賃貸・持ち家、車、職業、勤め先、年収・・などのデータ項目を有する。

上述したように、顧客プロファイルは、金融機関の保有データに基づいて作成される。顧客プロファイルのうち、例えば、氏名、住所、生年月日、年齢、性別、家族構成、配偶者、賃貸・持ち家、職業、勤め先、年収などの基本情報は、口座開設時等に顧客からの申請に基づいて登録される顧客属性情報（図２Ｂ）の記録事項であるため、原則そのまま転記・記述される。

しかしながら、顧客属性情報は、逐次申請届けを提出している顧客を除けば、顧客プロファイル作成にあたり、必ずしも常に最新ではない場合も多い。つまり、顧客属性情報のデータ項目のうち不変な情報は氏名、生年月日、性別くらいであって、それ以外はその顧客のライフステージによって変化する情報であるから、口座開設時等の顧客属性情報のみからでは顧客プロファイルを最新の顧客状況に保つことができない。例えば、住所は移転により、家族構成は結婚や出産により、職業、勤め先、年収は転職により変化することがほとんどである。また、そもそも顧客からの申請記載事項でないものは、顧客属性情報のみからでは把握できない顧客プロファイル項目も存在する。例えば、子供の生年月日、学校、両親・親族、車などは、顧客属性情報のみから直接的には把握できない。従って、本実施形態に係る顧客プロファイル中、このようなデータ項目は、金融機関の保有データの全て、即ち顧客属性情報（図２Ｂ）に加え、預金口座の取引明細（図２Ｃ）、決算手段の利用明細（図２Ｄ）、商品等契約情報（図２Ｅ）、及び交渉履歴情報（図２Ｆ）を用いて、顧客プロファイル項目の情報を機械推論（以下単に推論という）することで、推論された情報を更新及び補充する。以下、具体的な顧客プロファイル項目の推論方法について説明する。

・顧客属性情報（図２Ｂ）
上述したように、顧客プロファイルのデータ項目中、氏名、住所、生年月日、年齢、性別、家族構成、賃貸・持ち家、職業、勤め先、年収などの基本情報については、顧客属性情報から原則そのまま転記・記述される。顧客から変更申請があった場合は、変更申請された顧客属性情報の記載事項に基づいて更新される。

・預金口座の取引明細（図２Ｃ）・決済手段の利用明細（図２Ｄ）
例えば、普通預金口座の取引明細において、顧客が公共料金（電気・ガス・水道料金等）の自動引き落とし払いをしていることが記録されている場合に、契約種別や料金額に基づいて賃貸か持ち家か否か、マンションか一軒家か否か、ひいては家族構成（料金額多寡から少なくとも単身か否か等）を推論しうる。また住宅ローンの自動引き落とし・家賃支払い自動引き落とし口座としていることが記録されている場合に、賃貸か持ち家か否かを推論しうる。また例えば、学習塾への支払い口座としていたり学校給食への支払い口座としていることが記録されている場合に、小学生、中学生等の子供がいることを推論しうる。

また例えば、給与振り込みの入金が記録されている場合に、年収、職業、勤務先を推論しうる。特に夏冬賞与の入金が記録されている場合には、会社員であることを推論しうる。また、出産一時金の入金が記録されている場合に、子供の出産を推論しうる。また、退職金や年金の入金が記録されている場合に、定年退職したことを推論しうる。

なお、このような推論と元となる記録記載は、例えば普通預金口座の場合、普通預金明細に含まれる「取引日」、「取引金額」、「摘要コード」、取引内容を示す「摘要」（テキスト情報）等から取得される。

また、クレジットカードの利用明細において、普通預金口座（預金取引情報）と同様に各種の支払いをしていることが記録されている場合はそれら記録から推論する。また、医療費や介護費の支払いが記録されている場合に、同居の高齢者がいることを推論しうる。

また、クレジットカードで購入した購入商品やサービスが記録されている場合、家族構成（利用店舗・購入商品に基づく）、年収（利用店舗・利用金額に基づく）、趣味（利用店舗・購入商品に基づく）、行動地域（利用店舗）など、顧客プロファイル中、様々なデータ項目の情報を推論しうる。

なお、このような推論と元となる記録記載は、例えば、クレジットカードの利用明細に含まれる「利用日」、「利用金額」、「加盟店名」、「加盟店番号」、「加盟店業種」、「摘要」（テキスト情報）等から取得される。

・商品等契約情報（図２Ｅ）
商品等契約情報は、その商品の契約目的そのものが顧客プロファイルを直接的に示す場合が多い。顧客が例えば生命保険を契約している場合に少なくとも残された家族がいる、住宅ローンを契約している場合に持ち家を保有している（賃貸ではない）、マイカーローンを契約している場合に車を保有している、学資保険や教育ローンを契約している場合に子供がいる、投資信託を契約している場合に余剰・余裕資金を有している、といったことを推論できる。

・交渉履歴情報（図２Ｆ）
上述したように、交渉履歴情報には、顧客毎に営業担当者や金融機関窓口担当者が行った交渉履歴（ヒアリング履歴）、アンケート履歴が記録される。顧客本人から直接得られた確度の高い交渉履歴情報を推論の元とし、顧客プロファイル中、データ項目の情報を推論しうる。例えば顧客の家族構成についての対話、将来的な住宅購入の希望（即ち現在は賃貸）、資産運用に関する相談（即ち現在は未運用）などの情報を把握しうる情報となる。

・期間経過情報（現在の年月日）
一定期間の経過を経ることにより、つまり基準日から月日が経過することに伴って自動的にデータ項目の情報を更新する。顧客プロファイル中、特に年齢（基準日は生年月日）、第一子学校（基準日は第一子生年月日）、第二子学校（基準日は第二子生年月日）といったデータ項目が対象である。

以上のように、顧客プロファイルを作成するに際し、顧客プロファイル中、金融機関の保有データのうち、顧客属性情報から一義的に特定できないデータ項目については、預金口座の取引明細・決済手段の利用明細、商品等契約情報、交渉履歴情報、及び期間経過情報に基づいてデータ項目の情報を推論することで、更新及び補充することができる。またこのように作成された顧客プロファイルにより、顧客個人毎のライフプロファイル又はライフステージを逐一捕捉することが可能である。

なお、顧客プロファイルのデータ項目を推論するにあたり、推論の元となる情報は必ずしも単一に限られない。例えば、普通預金取引明細において、学習塾への支払い口座としていたり学校給食への支払い口座としていることが記録され、同時にクレジットカード利用明細において学習机の購入明細が過去記録されており、同時に商品等契約において顧客が学資保険を契約している場合に子供がいるといったことを、複数の情報から高い確度で推論できる。

以下、推論の元となる情報に応じて推論されたデータ項目の確度が異なる事例を、確度の高い順に示す。
・確定推論
年齢：顧客属性情報の生年月日と期間経過情報（現在の年月日）
結婚：顧客属性情報の家族構成や世帯名寄せ
出産：学資保険の被契約者情報
住宅購入：住宅ローン申込
住宅売却：住宅ローン中途解約
・複合推論
高校入学：子供の年齢＋高校への入学金振込
定年退職：本人年齢＋退職金の振込入金＋給与振り込み消滅
転職：本人年齢＋退職金の振込入金＋給与振り込み消滅＋新規発生
・単一推論
結婚：ホテルでの高額クレジットカード利用
就職：給与振り込み発生
退職：給与振り込み消滅
高校入学：高校への入学金振込（子供の年齢は不明な場合）
なお言うまでもなく、本実施形態に係る顧客プロファイル中のデータ項目はあくまで一例であり、金融機関の保有データに基づいて作成が可能な限り（金融機関の保有データに基づいて確定及び推論が可能な限り）、様々な顧客プロファイルに係るデータ項目があってもよい。一方、個人情報保護の観点から、金融機関の保有データに基づいて作成可能であっても、顧客プロファイル中、非作成とするデータ項目があってもよい。

（３）顧客ライフイベントの検知及びレコメンド商品の出力
図５は、本実施形態に係る顧客プロファイルに基づくライフイベントの検知例を示す。図６は、本実施形態に係るライフイベント及びレコメンド商品の対応例を示す。

ライフイベントは、顧客人生において転機となる所定の出来事であって、生活が新たなライフステージに変化する出発点でもあることから、ライフイベントが発生したときは、当該ライフイベント（又はライフステージ）に応じた商品・サービスの需要が発生する機会である。図５に示されるように本実施形態に係る顧客ライフイベントは、例えば、就職、結婚、転職、出産、住宅購入、小学校入学、中学校入学、住宅買替、高校入学、大学入学、定年退職などがある。

例えば、顧客ライフイベントとして就職は新たな社会人生活の始まりであってクレジットカード発行の需要が発生するし、結婚により新婚旅行、賃貸への引っ越しなどの需要が発生する。また、子供が生まれれば住宅購入に伴う住宅ローン、保険加入（生命保険や学資保険）、子供が成長するにつれ車の購入、夏になれば毎年家族旅行の需要が発生する。やがて相続や定年退職となれば、資金運用のための投資信託需要も発生しうる。

従って、管理サーバ２０は、顧客毎に、顧客プロファイルに基づいて当該顧客に所定のライフイベントを検知した場合、当該顧客に対して当該ライフイベントに応じた商品・サービス（レコメンド商品）を出力することができる。

より具体的に、例えば顧客プロファイル中、就職以前は「職業」、「勤め先」、「年収」が空欄（なし）であった学生等の顧客において、例えば預金口座の取引明細においてはじめて給与振り込み発生が記録された場合、顧客プロファイル中に少なくとも「職業」が会社員であると推論されて更新される。この更新により顧客プロファイル中からライフイベントとして就職を検知することができるので、当該顧客に対して例えばクレジットカード発行をレコメンドする。

また例えば、例えば顧客プロファイル中、「家族構成」が本人のみであった独身顧客において、例えばクレジットカードの利用明細においてホテルでの高額利用明細が記録された場合や顧客属性情報において家族構成の変更申請や世帯名寄せできた場合に、顧客プロファイル中少なくとも「家族構成」が本人、妻であると推論されて更新される。この更新により顧客プロファイル中からライフイベントとして結婚を検知することができるので、当該顧客に対しては新婚向けの旅行商品や賃貸への引っ越しをレコメンドする。

また例えば、例えば顧客プロファイル中、「家族構成」が本人、妻であった顧客において、例えば預金口座の取引明細において出産一時金や幼児手当の入金が記録されている場合に、顧客プロファイル中少なくとも「家族構成」が本人、妻、及び第一子であると推論されて更新される。この更新により顧客プロファイル中からライフイベントとして出産を検知することができるので、当該顧客に対しては生命保険や学資保険をレコメンドする。なお一方で同時に、例えば当該顧客の商品等契約情報において学資保険契約が記載されている場合には、レコメンド商品から契約済みである学資保険は除外し、生命保険のみをレコメンドすることも可能である。

また例えば、例えば顧客プロファイル中、「家族構成」が本人、妻及び第一子であった顧客において、「第一子生年月日」と期間経過情報とに基づいて、顧客プロファイル中「第一子学校」を自動的に更新する。この更新により顧客プロファイル中からライフイベントとして例えば小学校入学を検知することができるので、当該顧客に対しては旅行商品や車をレコメンドする。

このように、管理サーバ２０は、顧客単位で顧客プロファイルを参照し、その顧客が所定のライフイベント発生に至ったと判定されるタイミングでこれを検知し、当該ライフイベントと関連性の高いレコメンド商品を出力する。これにより、顧客に対してその顧客のライフステージにマッチしたレコメンド商品を提案することができる。

一方、担当者が支援端末５０から管理サーバ２０に対して先に特定のレコメンド商品を入力することにより、入力時点における全顧客の顧客プロファイルを参照し、その特定のレコメンド商品と関連性の高い所定のライフイベント検知状態にある顧客を出力することも可能である。この場合、販売したいレコメンド商品ベースで、顧客に対して現在レコメンド商品にマッチしたライフステージにある顧客に対して一斉に当該レコメンド商品を提案することができる。例えば、車販売店が車の販促を実施したい場合、車需要が見込める顧客として例えば全顧客プロファイル中「車」なしの顧客を出力し、当該顧客らに対して車の販促を実施することができる。

（４）レコメンド商品の具体的施策（顧客アプローチ）
担当者は支援端末５０を用いて管理サーバ２０にアクセスし、上述（３）による顧客個人毎のライフイベントに応じた商品・サービスを出力する。そしてレコメンド商品の具体的施策として、担当者は例えば直接的な対面営業、コール、ＤＭ（ダイレクトメール）、メール、ネットバンキング上のバナー、ネットバンキングアプリ上へのプッシュ通知など、様々なチャネルを単独又は複合的に活用しながら、当該顧客に対してその顧客のライフステージ毎にマッチするレコメンド商品を提案する。

＜情報処理＞
次いで、本実施形態に係る管理サーバ２０が実行する顧客プロファイル作成・更新処理、顧客ライフイベントの検知処理、及びレコメンド商品の出力処理について説明する。

（顧客プロファイル作成・更新処理）
図７は、本実施形態に係る顧客プロファイル作成・更新処理を示すフローチャートである。顧客プロファイル作成とは、顧客プロファイルＤＢ４０に顧客プロファイルが登録されていない顧客の顧客プロファイルを新規に作成するものであり、顧客プロファイル更新とは、顧客プロファイルＤＢ４０に顧客プロファイルが登録されている顧客の顧客プロファイルを更新（アップデート）するものである。管理サーバ２０のＣＰＵ２１に本フローチャートを実現可能なプログラムを読み込んで実行させることで、各ステップ（以下、「Ｓ」と表記する）を実現する。

Ｓ１：管理サーバ２０は、顧客プロファイル作成・更新対象となる顧客セグメントの中から、一の顧客（顧客ＩＤ等）を取得する。顧客セグメントは、基本的に金融機関の有する全顧客であるが、次のように選択・設定が可能である。例えば当該金融機関の営業支店のくくりであれば当該支店の有する全顧客であり、又は営業担当者のくくりであれば当該営業担当者が担当する全顧客でもよい。また顧客条件が入力されることで任意に対象となる顧客が決定されてもよい。

Ｓ２：管理サーバ２０は、加工ＤＢ３０から当該顧客に対応する加工データ（金融機関の保有データ）を取得する。上述したように取得される加工データ（金融機関の保有データ）は、顧客属性情報、預金口座の取引明細・決済手段の利用明細、商品等契約情報、及び交渉履歴情報である。またこれらの情報は現在時点の最新のもののみならず過去履歴を含む。

Ｓ３：管理サーバ２０は、顧客プロファイルのデータ項目のうち、Ｓ２で取得した顧客属性情報に基づいて一義的に特定可能な項目を転記・更新する。

上述したように、顧客プロファイルのデータ項目中、氏名、住所、生年月日、年齢、性別、家族構成、賃貸・持ち家、職業、勤め先、年収など、顧客属性情報から顧客プロファイルに対して一義的に特定可能な項目については、そのまま転記することができる。また、顧客から変更申請があった場合は、変更申請された顧客属性情報の記載事項に基づいてそのまま転記され更新される。

Ｓ４：管理サーバ２０は、顧客プロファイルのデータ項目のうち、Ｓ２で取得した預金口座の取引明細・決済手段の利用明細、商品等契約情報、交渉履歴情報に基づいて推論可能な項目を補充・更新する。

推論と元となる記載情報（便宜上、推論元記載情報という）としては、例えば普通預金口座の場合、普通預金明細に含まれる「取引日」、「取引金額」、「摘要コード」、取引内容を示す「摘要」（テキスト情報）等から取得される。例えばクレジットカードの場合には、クレジットカードの利用明細に含まれる「取引日」、「利用金額」、「加盟店名」、「加盟店番号」、「加盟店業種」、「摘要」（テキスト情報）等から取得される。商品等契約情報からは、生命保険の場合、「契約日」、「商品名」、「被保険者」、「受取人」、「保険金額」などが、住宅ローンの場合、「契約日」、「連帯保証人」、「融資金額」などが取得される。また交渉履歴情報からは、ＣＲＭ交渉履歴の場合、「交渉対応年月日」、「目標商品コード」、「目標商品名」、「交渉結果」、「交渉内容」などが、アンケート履歴の場合、「回答日」、「アンケートコード」、「目標商品名」、「回答内容」などが取得される。

また具体的に推論方法としては、例えば、予めこれら推論元記載情報ごとに、顧客プロファイルのデータ項目との因果関係や相関関係に基づいて顧客プロファイルのどのデータ項目を推論できるかを対応付けした情報をＨＤＤ２４等に保持しておく。そしてこれら各々又は複数の推論元記載情報が所定の推論条件を満たした場合に、推論条件を満たした場合の推論結果（推論値）を補充・更新することができる。推論条件を満たしたかどうかは、各々又は複数の推論元記載情報（テキスト情報内から形態素解析等により抽出されたキーワードも含む）と予め対応して設けられた条件値や条件キーワードとの一致又はその度合い、もしくは、各々又は複数の推論元記載情報の特徴量を示す特徴ベクトルと、予め対応して設けられた特徴量との距離に基づいて判定することができる。特徴ベクトルの特徴量や距離は従来手法により算出してよいが、特徴ベクトル間の距離が近いほど関連の度合いが高く推論条件を満たしやすくなり、距離が遠いほど関連の度合いが低く推論条件を満たしにくくなる。

Ｓ５：管理サーバ２０は、顧客プロファイルの更新であるか否かを判定する。顧客プロファイル更新かは、Ｓ１で取得した顧客（顧客ＩＤ等）の顧客プロファイルが顧客プロファイルＤＢ４０に既に登録されていた場合、顧客プロファイルの更新であると判定することができる。顧客プロファイルの更新である場合、Ｓ６へ進む。一方、顧客プロファイルの更新でない場合、ＥＮＤへ進み顧客プロファイルの作成処理を終了する。

Ｓ６：管理サーバ２０は、顧客プロファイルのデータ項目のうち、期間経過情報に基づいて特定可能な項目を補充・更新する。具体的に、管理サーバ２０は、顧客プロファイル中、どのデータ項目が期間経過情報に基づいて特定可能（更新可能）かを対応付けした情報をＨＤＤ２４等に保持しておく。例えば、顧客プロファイル中、家族構成において、家族の特に年齢や子供の学校（小学校〜大学）といったデータ項目が更新対象である。この場合、顧客プロファイル中の子供の「生年月日」と期間経過情報（基準となる子供の生年月日と現在日時とから何年が経過したか）とから、顧客プロファイル中において「学校（小学校〜大学）」を特定し、更新することができる。

（顧客ライフイベントの検知処理及びレコメンド商品の出力処理）
図８は、本実施形態に係る顧客ライフイベントの検知処理及びレコメンド商品の出力処理を示すフローチャート１である。本フローチャートの実行タイミングは、一つは管理サーバ２０側から自動的に顧客個人毎のライフイベントに応じた商品・サービスを出力する仕様とする場合には、顧客プロファイル作成・更新処理が発生した顧客に対して都度である。また一つは、担当者が支援端末５０を用いて管理サーバ２０にアクセスし、顧客個人毎のライフイベントに応じた商品・サービスを出力する操作を行ったときである。

Ｓ１１：管理サーバ２０は、顧客ライフイベント検知対象となる一の顧客（顧客ＩＤ等）を取得する。

Ｓ１２：管理サーバ２０は、顧客プロファイルＤＢから、Ｓ１１で取得した当該顧客の最新（現在）及び過去を含む顧客プロファイルを取得する。本フローチャートの実行タイミングが顧客プロファイル作成・更新処理が発生した顧客に対して都度である場合、ここでいう過去の顧客プロファイルには、最新の顧客プロファイルの１つ前に古い顧客プロファイルを用いるものとする。一方、本フローチャートの実行タイミングが担当者が支援端末５０を用いて管理サーバ２０にアクセスし顧客個人毎のライフイベントに応じた商品・サービスを出力する操作を行ったときである場合、現時点から所定のタイムスパン前の顧客プロファイル（例えば１か月前に古い顧客プロファイル）又は前回アクセス時点の次に更新された顧客プロファイルを用いる。

Ｓ１３：管理サーバ２０は、Ｓ１２で取得した顧客プロファイルのデータ項目に基づいて、当該顧客に発生したライフイベントを検知（判定）する。顧客に発生したライフイベントには、仮に実際には発生していなかったとしても、この時点発生した可能性の高いとされるライフイベントを含む。

具体的に、管理サーバ２０は、予め所定のライフイベントとして例えば、就職、結婚、転職、出産、住宅購入、小学校入学、中学校入学、住宅買替、高校入学、大学入学、定年退職などの情報をＨＤＤ２４等に保持しておく。また、これらライフイベント毎に、当該ライフイベントと関連度の高い顧客プロファイルのデータ項目と、当該ライフイベント検知条件とを対応付けた情報をＨＤＤ２４等に保持しておく。

そして管理サーバ２０は、最新（現在）の顧客プロファイルと、過去の顧客プロファイルとのデータ項目情報に差異・変化があるデータ項目（変化データ項目という）を特定し、各々のライフイベント毎に、顧客プロファイルの変化データ項目が、当該ライフイベント検知条件を満たすか否かを判定していき、ライフイベント検知条件を満たすライフイベントを検知する。

例えば、ライフイベント「就職」は、「就職」と関連度の高い顧客プロファイルのデータ項目として「職業」、「勤め先」、「年収」とのデータ項目と、「職業」、「勤め先」、又は「年収」の少なくとも１以上が空欄から非空欄となると定義されたライフイベント検知条件と対応付けられている。

例えば、１つ前に古い顧客プロファイル中に「職業」、「勤め先」、「年収」が空欄（なし）であった学生等の顧客において、例えば預金口座の取引明細においてはじめて給与振り込み発生が記録された場合、顧客プロファイル作成・更新処理を経て、最新の顧客プロファイル中に「職業」、「勤め先」、「年収」が補充される。

管理サーバ２０は、最新（現在）の顧客プロファイルと、過去の顧客プロファイルとの変化データ項目を特定し、ライフイベント「就職」においてプロファイルの変化データ項目「職業」が、空欄から非空欄となるライフイベント検知条件を満たすため、当該顧客に対してライフイベント「就職」を検知することができる。なおこれ関連して、例えば顧客プロファイルの変化データ項目「勤め先」が、異なる会社名となった場合、当該顧客に対してライフイベント「転職」を検知しうる。

Ｓ１４：管理サーバ２０は、少なくとも一以上のライフイベントを検知したか否かを判定する。一以上のライフイベントを検知した場合、Ｓ１５へ進む。一方、一以上のライフイベントを検知しない場合、ＥＮＤへ進み、ライフイベント検知処理を終了する。ライフイベント検知結果として、ライフイベント非検知の旨を出力してもよい。

Ｓ１５：管理サーバ２０は、Ｓ１３で検知したライフイベントに対応するレコメンド商品を出力する。具体的に、管理サーバ２０は、予め所定のライフイベント毎に、レコメンド商品を対応付けた情報をＨＤＤ２４等に保持しておく。これにより、管理サーバ２０は、Ｓ１３で検知したライフイベントに対応付けられたレコメンド商品を出力することができる。上述の例でいえば、ライフイベント「就職」には、クレジットカード発行（レコメンド商品）が対応付けられている場合、ライフイベント「就職」が検知された当該顧客に対してはクレジットカード発行をレコメンドすることができる。

なお、ライフイベントとレコメンド商品との対応付けは、「就職」と「クレジットカード発行」のみといったように１対１のみに限られず、１対複数である場合もある。例えば、ライフイベント「就職」が発生し且つ普通預金口座しか保有しない顧客には、例えばレコメンド商品「定期預金」や「外貨預金」などもレコメンドできる。また、Ｓ１５で管理サーバ２０（レコメンド商品出力部２０４）は、レコメンド商品と併せて又は別途に発生が検知されたライフイベントを出力してもよい。

また、管理サーバ２０は、Ｓ１３で検知したライフイベントを、別途、当該顧客に発生したライフイベント情報として出力してもよい。

図９は、本実施形態に係る顧客ライフイベントの検知処理及びレコメンド商品の出力処理を示すフローチャート２である。本フローチャートにおいては、担当者が支援端末５０から管理サーバ２０に対して先に特定のレコメンド商品を入力することにより、入力時点における全顧客の顧客プロファイルを参照し、その特定のレコメンド商品と関連性の高い所定のライフイベント検知状態にある顧客を出力する。

Ｓ２１：管理サーバ２０は、特定のレコメンド商品を取得する。例えば担当者が支援端末５０から管理サーバ２０に対して販促を実施したいレコメンド商品を入力することで、特定のレコメンド商品が取得される。

Ｓ２２：管理サーバ２０は、Ｓ２１で取得したレコメンド商品に対応付けられたライフイベントを特定する。管理サーバ２０は、予め所定のレコメンド商品毎に、ライフイベントを対応付けた情報をＨＤＤ２４等に保持しておく。これにより、管理サーバ２０は、特定のレコメンド商品に対応付けられたライフイベントを特定することができる。上述の例でいえば、レコメンド商品「クレジットカード発行」には、ライフイベント「就職」が対応付けられている場合、ライフイベントとして「就職」を特定することができる。

なお、レコメンド商品とライフイベントとの対応付けは、「クレジットカード発行」と「就職」といったように１対１のみに限られず、１対複数である場合もある。例えば、レコメンド商品「クレジットカード発行」に、更にライフイベント「転職」が対応付けられている場合、ライフイベント「転職」が発生し且つ「年収」が増加した顧客には、よりステータスの高い「クレジットカード発行」をレコメンドできるからである。

Ｓ２３：管理サーバ２０は、顧客プロファイルＤＢから、全顧客の最新（現在）及び過去を含む顧客プロファイルを取得する。過去の顧客プロファイルには、現時点から所定のタイムスパン前の顧客プロファイルとして、例えば１か月前に古い顧客プロファイルを用いるものとする。Ｓ１２のように、最新の顧客プロファイルの１つ前に古い顧客プロファイルを用いるものとすると、顧客プロファイルの更新サイクルが短い場合に最新の顧客プロファイルと１つ前に古い顧客プロファイルとのタイムスパンが短くなるため、発生したライフイベントを検知できない恐れがあるためである。

Ｓ２４：管理サーバ２０は、Ｓ２３で取得した顧客プロファイルを取得した全顧客のうち、各々の顧客プロファイルのデータ項目に基づいて、Ｓ２２で特定したライフイベントが発生している顧客を検知（判定）する。

具体的に、管理サーバ２０は、予め所定のライフイベントとして例えば、就職、結婚、転職、出産、住宅購入、小学校入学、中学校入学、住宅買替、高校入学、大学入学、定年退職などの情報をＨＤＤ２４等に保持しておく。また、これらライフイベント毎に、当該ライフイベントと関連度の高い顧客プロファイルのデータ項目と、当該ライフイベント検知条件とを対応付けた情報をＨＤＤ２４等に保持しておく。

具体的に、管理サーバ２０は、最新（現在）の顧客プロファイルと、過去の顧客プロファイルとのデータ項目情報に差異・変化がある変化データ項目を特定し、ライフイベントと関連度が高いと対応付けられた顧客プロファイルの変化データ項目が、ライフイベント検知条件を満たすか否かを判定していき、ライフイベント検知条件を満たす顧客プロファイルを有する顧客を検知・判定する。

例えば、ライフイベント「就職」は、「就職」と関連度の高い顧客プロファイルのデータ項目として「職業」、「勤め先」、「年収」とのデータ項目と、「職業」、「勤め先」、又は「年収」の少なくとも１以上が空欄から非空欄となると定義されたライフイベント検知条件と対応付けられている。

管理サーバ２０は、最新（現在）の顧客プロファイルと、過去（例えば１か月前）の顧客プロファイルとの変化データ項目を特定し、ライフイベント「就職」においてプロファイルの変化データ項目「職業」、「勤め先」、又は「年収」の少なくとも１以上が空欄から非空欄となるライフイベント検知条件を満たす顧客を検知する。なお、過去の顧客プロファイルとして例えば１か月前のものを用いた場合には、直近１か月間以内の間にライフイベント「就職」が発生した顧客を検知することができる。また例えば３か月前のものを用いた場合には、直近３か月間以内の間にライフイベント「就職」が発生した顧客を検知することができる。

Ｓ２５：管理サーバ２０は、Ｓ２４で検知・判定した顧客を、例えばリスト形式等で出力する。このように、本フローチャートによれば、販売したいレコメンド商品ベースで、顧客に対して現在レコメンド商品にマッチしたライフステージにある顧客に対して一斉に当該レコメンド商品を提案することができる。例えば、クレジットカードの販促を実施したい場合、クレジットカード発行需要が見込める顧客として例えば全顧客プロファイル中「就職」のライフイベントが直近に発生している顧客（「就職」のライフステージにある顧客ともいえる）を出力し、当該顧客らに対してクレジットカード発行の販促を実施することができる。

＜応用例１＞
図１０は、本応用例に係る顧客プロファイルと車の価格帯別車種との対応一覧表を示す。本応用例においては、顧客のライフイベントの検知に伴い、当該顧客にそのライフイベントと関連性の高い商品をレコメンドする場合、その商品のうち当該顧客プロファイルに応じた種類のレコメンド商品を出力する。これにより、顧客に対してその顧客のライフプロファイル及びライフステージによりマッチしたレコメンド商品を提案することができる。レコメンド商品内において、販売ターゲット層の異なる複数種類の商品が存在する場合に特に有効である。

具体的に、顧客に所定のライフイベントと関連性の高い商品として車をレコメンドする場合、当該顧客プロファイルに応じた価格帯別車種を特定し、特定した車種をレコメンドする。

例えばライフイベントとして結婚が検知された顧客に対して、レコメンド商品として車をレコメンドする場合であって、当該顧客プロファイルが、家族構成が夫婦のみ、子供なし、年齢が２７歳である場合、商品名Ａ、Ｂ、Ｃ、Ｄをレコメンドする。また、年齢が２７歳であることや顧客プロファイルの年収が平均的であった場合、このうち中価格帯の１５１−２５０万円の商品Ｂ又は２５１−３５０万円の商品Ｃに絞ってレコメンドすることも可能である。なお、商品名Ａ、Ｂ、Ｃ、Ｄ、Ｅは、何れも２０代向けのユーザ層をターゲットにして販売されている車種群である。

また例えばライフイベントとして子供の小学校入学が検知された顧客に対して、レコメンド商品として車をレコメンドする場合であって、当該顧客プロファイルが、家族構成が夫婦、子供３人、年齢が３５歳である場合、商品名Ｆ、Ｇ、Ｈ、Ｉをレコメンドする。また、年齢が３５歳であることや顧客プロファイルの年収が平均以上であった場合、このうち価格帯が２５１−３５０万円の商品Ｇ、３５１−４５０万円の商品Ｈ、又は４５１万円以上の商品Ｉに絞ってレコメンドすることも可能である。なお、商品名Ｆ、Ｇ、Ｈ、Ｉは、何れも大家族向けのユーザ層をターゲットにして販売されている車種群である。

また例えばライフイベントとして定年退職が検知された顧客に対して、レコメンド商品として車をレコメンドする場合であって、当該顧客プロファイルが、家族構成が夫婦のみ、子供独立、年齢が６５歳である場合、商品名Ｊ、Ｋ、Ｌ、Ｍ、Ｎをレコメンドする。また、年齢が６５歳であることや顧客プロファイルの年収がハイクラスであった場合、このうち価格帯が３５１−４５０万円の商品Ｍ、又は４５１万円以上の商品Ｎに絞ってレコメンドすることも可能である。なお、商品名Ｊ、Ｋ、Ｌ、Ｍ、Ｎは、何れもシニアのユーザ層をターゲットにして販売されている車種群である。

なお、先にレコメンド商品及び車種を入力して、入力時点における全顧客の顧客プロファイルを参照し、そのレコメンド商品と関連性の高い所定のライフイベント検知状態にある顧客であって、且つその顧客プロファイルと関連性の高い車種を出力することも可能である。この場合、販売したいレコメンド商品の車種ベースで、顧客に対して現在レコメンド商品にマッチしたライフステージにある顧客に対して一斉に当該レコメンド商品を提案することができる。例えば、車販売店が車種ミニバンの販促を実施したい場合、ミニバン需要が見込める顧客、即ち家族構成が夫婦、子供３人、年齢が３５歳である顧客プロファイル・モデルケースに近い（関連度が高い）顧客プロファイルを有する顧客を出力し、当該顧客らに対してミニバンの販促を実施することができる。

＜応用例２＞
図２Ｂに示されるように、本実施形態に係る顧客属性情報は、家族構成、家族口座番号（法定相続関係にある家族の保有する当行銀行口座番号）を有している。従って、当該顧客本人の顧客プロファイル及び当該家族（例えば当該顧客の祖父母や両親）の顧客プロファイルに基づいて、家族・親族の口座番号から預金残高や保有する金融商品を特定することも可能である。

そして、このような家族や親族が所定額以上の預金残高や金融商品を有する資産家であると判定される場合、当該顧客本人は、家族や親族からの金銭的援助の可能性を加味すれば、このような家族や親族を有しない顧客に比べ、レコメンド商品に対するその潜在的な購買力が高いことが推定される。即ち、レコメンド商品として例えば、家、車など比較的高額なレコメンド商品を提案する場合があり、近年親から子への贈与税の非課税枠の拡大もあって、管理サーバ２０は、顧客個人毎のライフイベントに応じた商品・サービスを出力するに際し、特にこのような顧客プロファイルを有する顧客に対して、潜在的購買力が高いことを示す情報を付加することができる。

また、図１０に示したように、レコメンド商品に販売ターゲット層の異なる複数種類の価格帯別商品が存在する場合、顧客プロファイル中、表面的な「年齢」や「年収」のみからでは推論しきれない潜在的な顧客の購買力を推論し、高額帯の商品に絞ってレコメンドすることが可能である。これにより、担当者は当該顧客に対してその顧客のライフステージ毎にマッチするレコメンド商品をより効率的に提案することが可能である。

[実施形態２]
上述の実施形態１において、管理サーバ２０は、顧客毎に顧客プロファイルに基づいてその顧客において発生したライフイベントを検知したことを以って、当該顧客に対して当該ライフイベントに応じた商品・サービス（レコメンド商品）を出力するものであった。これに対して実施形態２において、管理サーバ２０は、顧客毎に顧客プロファイルに基づいてその顧客においてライフイベント発生の兆候を予知（察知）した場合に、当該顧客に対して当該ライフイベントに応じた商品・サービス（レコメンド商品）を出力する。

こうすることで、顧客にライフイベントが実際に発生する以前に、当該顧客に対して近々発生する可能性の高いライフイベントに応じたレコメンド商品を出力し提案することでき、これにより、レコメンド商品をいち早く顧客に提案が可能となるとともに、ライフイベントが発生してからでは馴染まないレコメンド商品を顧客に提案することが可能、つまりレコメンド商品の品目幅を広げることが可能である。

より具体的に、例えば顧客プロファイル中、年齢が２２歳、大学生である顧客において、例えばクレジットカードの利用明細においてスーツやカバンの購入が記録された場合、これら取引データを推論元記載情報として、ライフイベントとして近く就職が発生する予兆を推論することができる。そしてこの場合、就職後では馴染まないレコメンド商品、例えば、就職セミナー等を顧客に提案することが可能となる。

また例えば、例えば顧客プロファイル中、「家族構成」が本人のみであった独身顧客において、例えばクレジットカードの利用明細において結婚の予兆を推論できる利用明細が記録された場合（但しまだ顧客属性情報において家族構成の変更申請や世帯名寄せなどの結婚確定情報は確認されない）、これら取引データを推論元記載情報として、ライフイベントとして近く結婚が発生する予兆を推論することができる。そしてこの場合、結婚前に例えば結婚式場等のレコメンド商品を顧客に提案することが可能となる。

また例えば、例えば顧客プロファイル中、「家族構成」が本人、妻であった顧客において、例えばクレジットカードの利用明細において出産の予兆を推論できる利用明細が記録された場合（但しまだ顧客属性情報において家族構成の変更申請や預金口座の取引明細において出産一時金や幼児手当の入金などの出産確定情報は確認されない）、これら取引データを推論元記載情報として、ライフイベントとして近く出産が発生する予兆を推論することができる。そしてこの場合、出産前だからこその例えばマタニティフォト等のレコメンド商品を顧客に提案することが可能となる。

また例えば、上述したように、顧客本人の顧客プロファイル及び当該家族（例えば当該顧客の祖父母や両親）の顧客プロファイルに基づいて、家族・親族が所定額以上の預金残高や金融商品を有する資産家であると判定される場合であって且つ家族・親族の年齢が高齢である場合、また更にクレジットカードの利用明細において頻繁に病院の利用明細や終活に係る利用明細が記録された場合などに、これら取引データを推論元記載情報として、ライフイベントとして近く相続が発生する予兆を推論することができる。そしてこの場合、ライフイベント発生前からライフイベント「相続」に応じた例えば投資信託などのレコメンド商品を顧客に提案することが可能となる。

なお、図６のケースにおいて、ライフイベント「相続」は、当該顧客が例えば年齢５０〜６０代、つまり「第一子大学入学」以降「定年退職」前付近に発生するものとして想定されているものの、現実の相続発生はこれらライフステージ付近に限られず、いつでも発生しうるものである。よって例えば、近くライフイベント「相続」が発生する予兆が推論される顧客であって、併せて近くライフイベント「出産」が発生する予兆が推論される又はライフイベント「出産」が発生したことが推論される顧客に対しては、ライフイベント「相続」に応じた投資信託などのレコメンド商品に限られず、ライフイベント「出産」に応じたレコメンド商品のうち例えば住宅販売など特に高額なレコメンド商品を顧客に提案することが可能となる。なおこの場合、当該顧客にとって住宅資金の借り入れ資金としての住宅ローンは適切なレコメンド商品とはいえないため除外する。

＜情報処理＞
次いで、本実施形態に係る管理サーバ２０が実行する顧客プロファイル予兆更新処理、顧客ライフイベントの予兆検知処理、及びレコメンド商品の出力処理について説明する。

（顧客プロファイル予兆更新処理）
図１１は、本実施形態に係る顧客プロファイル予兆更新処理を示すフローチャートである。
Ｓ３１：管理サーバ２０は、顧客プロファイル予兆更新対象となる顧客セグメントの中から、一の顧客（顧客ＩＤ等）を取得する。なお、当該顧客は、顧客プロファイルが顧客プロファイルＤＢ４０に既に登録されている顧客である。

Ｓ３２：管理サーバ２０は、加工ＤＢ３０から当該顧客に対応する加工データ（金融機関の保有データ）を取得する。上述したように取得される加工データ（金融機関の保有データ）は、顧客属性情報、預金口座の取引明細・決済手段の利用明細、商品等契約情報、及び交渉履歴情報である。またこれらの情報は現在時点の最新のもののみならず過去履歴を含む。

Ｓ３３：管理サーバ２０は、顧客プロファイルのデータ項目のうち、Ｓ３２で取得した預金口座の取引明細・決済手段の利用明細、商品等契約情報、交渉履歴情報に基づいて予兆推論可能な項目を補充・更新する。

予兆推論と元となる記載情報（便宜上、予兆推論元記載情報という）としては、例えば普通預金口座の場合、普通預金明細に含まれる「取引日」、「取引金額」、「摘要コード」、取引内容を示す「摘要」（テキスト情報）等から取得される。例えばクレジットカードの場合には、クレジットカードの利用明細に含まれる「取引日」、「利用金額」、「加盟店名」、「加盟店番号」、「加盟店業種」、「摘要」（テキスト情報）等から取得される。また交渉履歴情報からは、ＣＲＭ交渉履歴の場合、「交渉対応年月日」、「目標商品コード」、「目標商品名」、「交渉結果」、「交渉内容」などが、アンケート履歴の場合、「回答日」、「アンケートコード」、「目標商品名」、「回答内容」などが取得される。

また具体的に予兆推論方法としては、例えば、予めこれら予兆推論元記載情報ごとに、顧客プロファイルのデータ項目との因果関係や相関関係に基づいて顧客プロファイルのどのデータ項目を予兆推論できるかを対応付けした情報をＨＤＤ２４等に保持しておく。そしてこれら各々又は複数の予兆推論元記載情報が所定の予兆推論条件を満たした場合に、予兆推論条件を満たした場合の予兆推論結果（予兆推論値）を補充・更新することができる。予兆推論条件を満たしたかどうかは、各々又は複数の予兆推論元記載情報と予め対応して設けられた条件値や条件キーワードとの一致又はその度合い、もしくは、各々又は複数の予兆推論元記載情報の特徴量を示す特徴ベクトルと、予め対応して設けられた特徴量との距離に基づいて判定することができる。

Ｓ３４：管理サーバ２０は、顧客プロファイルのデータ項目のうち、期間経過情報に基づいて予兆可能な項目を補充・更新する。具体的に、管理サーバ２０は、顧客プロファイル中、どのデータ項目が期間経過情報に基づいて予兆可能（予兆更新可能）かを対応付けした情報をＨＤＤ２４等に保持しておく。例えば、顧客プロファイル中、家族構成において、家族の特に年齢や子供の学校（小学校〜大学）といったデータ項目が予兆更新対象である。この場合、顧客プロファイル中の子供の「生年月日」と期間経過情報（基準となる子供の生年月日と現在日時とから何年が経過したか）とから、顧客プロファイル中において「学校（小学校〜大学）」を特定し、予兆として更新することができる。

図１２は、本実施形態に係る顧客プロファイルの一例を示す。図１２に示される顧客プロファイルは、図４に示される顧客プロファイルと比較すると、顧客プロファイル予兆更新処理による予兆推論の結果、当該データ項目が更新され、予兆を示す予兆推論結果（予兆推論値）が示される。

例えば、顧客ＩＤ００００２のレコード、年齢が２２歳、大学生である顧客において、例えばクレジットカードの利用明細においてスーツやカバンの購入が記録された場合に、これら取引データを推論元記載情報として、「職業」に会社員（予兆）という予兆推論結果が補充・更新されていることが分かる。なお、予兆のフラグは、まだ未達であるものの近々間もなく当該顧客において「職業」に会社員が補充・更新される可能性が高いと推論されたことを意味する。従って、その後実際に、例えば預金口座の取引明細においてはじめて給与振り込み発生が記録されるなどした場合、顧客プロファイル中「職業」が会社員であると推論されて更新される（予兆のフラグは削除される）。

また例えば、顧客ＩＤ００００３のレコード、「家族構成」が本人のみであった独身の顧客において、例えばクレジットカードの利用明細において結婚の予兆を推論できる利用明細が記録された場合に、「家族構成」に夫（予兆）、及び「配偶者」にあり（予兆）という予兆推論結果が補充・更新されていることが分かる。

（顧客ライフイベントの予兆検知処理及びレコメンド商品の出力処理）
図１３は、本実施形態に係る顧客ライフイベントの予兆検知処理及びレコメンド商品の出力処理を示すフローチャートである。本フローチャートの実行タイミングは、一つは管理サーバ２０側から自動的に顧客個人毎のライフイベントに応じた商品・サービスを出力する仕様とする場合には、顧客プロファイル予兆更新処理が発生した顧客に対して都度である。また一つは、担当者が支援端末５０を用いて管理サーバ２０にアクセスし、顧客個人毎のライフイベントに応じた商品・サービスを出力する操作を行ったときである。

Ｓ４１：管理サーバ２０は、顧客ライフイベント予兆検知対象となる一の顧客（顧客ＩＤ等）を取得する。

Ｓ４２：管理サーバ２０は、顧客プロファイルＤＢから、Ｓ４１で取得した当該顧客の最新（現在）及び過去を含む顧客プロファイルを取得する。過去の顧客プロファイルには、上述したように最新の顧客プロファイルの１つ前に古い顧客プロファイル、又は現時点から所定のタイムスパン前の顧客プロファイルを用いる。

Ｓ４３：管理サーバ２０は、Ｓ４２で取得した顧客プロファイルのデータ項目に基づいて、当該顧客に近々間もなく発生する可能性の高いライフイベントを検知（判定）する。

上述したように、管理サーバ２０は、予め所定のライフイベントとして例えば、就職、結婚、転職、出産、住宅購入、小学校入学、中学校入学、住宅買替、高校入学、大学入学、定年退職などの情報をＨＤＤ２４等に保持しておく。また、これらライフイベント毎に、当該ライフイベントと関連度の高い顧客プロファイルのデータ項目と、当該ライフイベント予兆検知条件とを対応付けた情報をＨＤＤ２４等に保持しておく。

そして管理サーバ２０は、最新（現在）の顧客プロファイルと、過去の顧客プロファイルとのデータ項目情報に差異・変化がある変化データ項目を特定し、各々のライフイベント毎に、顧客プロファイルの変化データ項目が、当該ライフイベント予兆検知条件を満たすか否かを判定していき、ライフイベント予兆検知条件を満たすライフイベントを、当該顧客に近々間もなく発生する可能性が高いライフイベントとして検知する。

例えば、ライフイベント「就職」は、「就職」と関連度の高い顧客プロファイルのデータ項目として「職業」、「勤め先」、「年収」とのデータ項目と、「職業」、「勤め先」、又は「年収」の少なくとも１以上が空欄から非空欄となると定義されたライフイベント予兆検知条件と対応付けられている。

例えば、１つ前に古い顧客プロファイル中に「職業」、「勤め先」、「年収」が空欄であった学生等の顧客において、顧客プロファイル予兆更新処理を経て、最新の顧客プロファイル中に「職業」に会社員（予兆）が補充される。

このとき管理サーバ２０は、最新（現在）の顧客プロファイルと、過去の顧客プロファイルとの変化データ項目を特定し、ライフイベント「就職」においてプロファイルの変化データ項目「職業」が、空欄から非空欄となるライフイベント予兆検知条件を満たすため、当該顧客に対してライフイベント「就職」を予兆検知することができる。

Ｓ４４：管理サーバ２０は、少なくとも一以上のライフイベントを予兆検知したか否かを判定する。一以上のライフイベントを予兆検知した場合、Ｓ４５へ進む。一方、一以上のライフイベントを予兆検知しない場合、ＥＮＤへ進む。

Ｓ４５：管理サーバ２０は、Ｓ４３で予兆検知したライフイベントに対応するレコメンド商品を出力する。上述したように、管理サーバ２０は、予め所定のライフイベント毎に、レコメンド商品を対応付けた情報をＨＤＤ２４等に保持しておく。これにより、管理サーバ２０は、Ｓ４３で予兆検知したライフイベントに対応付けられたレコメンド商品を出力することができる。

なお、担当者が支援端末５０から管理サーバ２０に対して先に特定のレコメンド商品を入力することにより、入力時点における全顧客の顧客プロファイルを参照し、その特定のレコメンド商品と関連性の高い所定のライフイベントが予兆検知状態にある顧客を出力することも可能である。

＜応用例３＞
上述したように、本実施形態に係る顧客属性情報は、家族構成、家族口座番号（法定相続関係にある家族の保有する当行銀行口座番号）を有している。従って、当該顧客本人（相続人）の顧客プロファイル及び当該家族（例えば当該顧客の祖父母や両親などの非相続人）の顧客プロファイルに基づいて、家族・親族の口座番号から預金残高や保有する金融商品を特定することも可能である。

そして、管理サーバ２０は、当該顧客本人及び当該家族の顧客プロファイルのデータ項目に基づいて、当該顧客の家族や親族が所定額以上の預金残高や金融商品を有する資産家であって、例えば家族や親族の年齢が例えば非常に高齢であったり、当該顧客又はその家族や親族における預金口座の取引明細やクレジットカードの利用明細において相続の予兆が推論された場合、当該顧客に近々間もなく発生する可能性の高いライフイベント「相続」を検知（判定）することができる。なお、当該家族の顧客プロファイルのデータ項目において、相続の予兆が推論されうる預金口座の取引明細やクレジットカードの利用明細としては、例えば終活に係る費用、弁護士・司法書士費用など様々なものがありうる。

このような家族や親族からの相続が近々に発生しうる可能性を加味すれば、このような顧客は、レコメンド商品に対するその購買力がより高いことが推定されるため、ライフイベント「相続」に応じたレコメンド商品として例えば、家、車など比較的高額なレコメンド商品を積極的に提案することができる。管理サーバ２０は、顧客個人毎のライフイベントに応じた商品・サービスを出力するに際し、特にこのような顧客プロファイルを有する顧客に対して、相続が近々に発生しうる可能性や潜在的購買力が高いことを示す情報を付加することができる。また、当該顧客が相続する可能性のある預金残高や保有する金融商品の資産価値情報を付加してもよい。

＜応用例４＞
上述したように、管理サーバ２０は、顧客プロファイルのデータ項目に基づいて、当該顧客の法定相続関係にある家族や親族が所定額以上の預金残高や金融商品を有する資産家であって、例えばその家族や親族の年齢が例えば非常に高齢であったり、当該顧客又はその家族や親族における預金口座の取引明細やクレジットカードの利用明細において相続の予兆が推論された場合、当該顧客に近々間もなく発生する可能性の高いライフイベント「相続」を検知（判定）することができる。

ここで、上述の応用例３においては、このような顧客に、ライフイベント「相続」に応じたレコメンド商品として例えば、家、車など比較的高額なレコメンド商品を積極的に提案することができた。しかしながら、ライフイベント「相続」に応じたレコメンド商品を具体的に特定せず、当該顧客に相続が近々に発生しうる可能性や潜在的購買力が高いことを示す情報（潜在的購買力の根拠として当該顧客が相続する可能性のある預金残高や保有する金融商品の資産価値情報を含む）のみを出力してもよい。ライフイベント「相続」に応じた具体的なレコメンドは出力しない。

このように、顧客に近々間もなく発生する可能性の高いライフイベント「相続」が検知された場合、近々に発生しうる相続により潜在的購買力が特に高まる当該顧客の情報それ自体が、表面的な「年収」等の情報からのみでは検知困難であり、マーケティング戦略上、様々な商品・サービス（レコメンド商品）に対する見込み上顧客となりうる有用な情報である。

＜総括＞
以上、本実施形態に係る管理サーバ２０は、金融機関の保有データをウォッチ・解析し、顧客のデータが顧客個人自身のライフイベントの発生を示す／又は示している可能性が高いと検知した場合、当該顧客に対して当該ライフイベントに応じた商品・サービスを出力する。また、管理サーバ２０は、顧客のデータが顧客個人自身のライフイベントの発生を示す／又は示している可能性が高いことを検知するために、顧客個人毎のライフプロファイル又はライフステージを逐一捕捉するため、顧客個人毎の顧客プロファイルを作成する。

我々個人は日々金融機関との取引を行いながら、各々が様々なライフ活動を行っている。その活動は、長期的スパンで金融機関における顧客個人の属性データや取引データの時系列変化として記録されており、金融機関におけるその記録が顧客個人のライフステージやライフスタイルを反映しうる。

また、新たなライフイベントの発生は生活が新たなライフステージに変化する転機・出発点でもある。従って、その顧客にとってのライフイベントが発生したタイミング（又はその予兆が見られたタイミング）で、そのライフイベント発生、つまり新たなライフステージに必要となって需要の発生が見込まれる商品・サービスを、その顧客に対して提案することにより、より効果的な営業活動や販売促進を行うことが可能である。

なお、本発明の好適な実施の形態により、特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

管理サーバ２０は、当該サーバの機能面から着目することで、営業支援装置、見込み顧客抽出装置、営業先リスト作成装置、顧客プロファイル作成装置、顧客ライフイベント検知装置などと称することも可能である。

また、本発明は、上述の実施形態の１つ以上の機能を実現するプログラムを、ネットワークまたは記録媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読み出し作動させる処理でも実現可能である。

１０ 金融機関システム
２０ 管理サーバ
３０ 加工ＤＢ
４０ 顧客プロファイルＤＢ
５０ 支援端末
７０ ネットワーク
１００ 営業支援システム
２０１ データ取得部
２０２ 顧客プロファイル作成部
２０３ ライフイベント検知部
２０４ レコメンド商品出力部

Claims (3)

1. 顧客及び該顧客と非相続人の関係を有する家族顧客の取引記録に関する取引データと顧客属性情報とを含む金融機関の保有データを取得する取得手段と、
   前記顧客及び前記家族顧客の取引データと顧客属性情報とに基づいて、該顧客及び該家族顧客のプロファイルを作成する作成手段と、
   前記顧客及び前記家族顧客のプロファイルに基づいて前記家族顧客が所定額以上の金融資産を有する場合であって、現時点における前記家族顧客のプロファイルと所定の過去時点における前記家族顧客のプロファイルとの特定の変化に基づいて、生じた該特定の変化が満たした予兆検知条件と対応付けられた相続イベントの発生の予兆を検知する予兆検知手段と、
   前記予兆検知手段により検知された前記家族顧客が非相続人となる前記顧客の相続イベントの発生の予兆を示す情報を出力する出力手段と、
   を有することを特徴とする顧客ライフイベント検知装置。
2. 前記顧客及び前記家族顧客の取引データは、金融機関における、前記顧客の預金口座の取引明細、決算手段の利用明細、商品等契約情報、及び交渉履歴情報の少なくとも何れかを含むこと、
   を特徴とする請求項１に記載の顧客ライフイベント検知装置。
3. 前記予兆を示す情報は、前記顧客が前記家族顧客から相続する可能性のある資産の価値情報を含むこと、
   を特徴とする請求項１に記載の顧客ライフイベント検知装置。
   

Images