IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ノースアイランドの特許一覧

特開2024-61995ライフイベント型金融商品情報出力装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024061995
(43)【公開日】2024-05-09
(54)【発明の名称】ライフイベント型金融商品情報出力装置
(51)【国際特許分類】
   G06Q 40/03 20230101AFI20240430BHJP
   G06Q 40/06 20120101ALI20240430BHJP
【FI】
G06Q40/02 300
G06Q40/06
【審査請求】未請求
【請求項の数】17
【出願形態】OL
(21)【出願番号】P 2022169704
(22)【出願日】2022-10-24
(71)【出願人】
【識別番号】514090289
【氏名又は名称】株式会社ノースアイランド
(74)【代理人】
【識別番号】100109553
【弁理士】
【氏名又は名称】工藤 一郎
(72)【発明者】
【氏名】嶋 敬介
(72)【発明者】
【氏名】岩永 慶子
【テーマコード(参考)】
5L040
5L055
【Fターム(参考)】
5L040BB05
5L040BB56
5L040BB57
5L055BB05
5L055BB56
5L055BB57
(57)【要約】      (修正有)
【課題】顧客のライフイベントに関わる支出に備えると共に、その資金を効率的に運用できる金融商品を出力するライフイベント型金融商品情報出力装置、その制御方法及び制御プログラムを提供する。
【解決手段】ライフイベント型金融商品情報出力装置0200は、顧客の顧客属性情報を取得する顧客属性情報取得部と、顧客属性情報に基づき、顧客に今後発生見込みがある見込ライフイベントの識別情報を取得し、見込ライフイベント発生時の将来時期と関連付けて選択させる見込ライフイベント識別情報選択受付部と、顧客識別情報に関する顧客属性情報、将来情報に基づき、見込ライフイベントでの出費の一部を賄うために投資する金融商品の金融商品識別情報の選択ルールを保持する金融商品識別情報選択ルール保持部と、顧客属性情報、取得された将来情報と、金融商品識別情報の選択ルールとに基づき金融商品識別情報を選択する金融商品識別情報選択部と、を含む。
【選択図】図2
【特許請求の範囲】
【請求項1】
顧客の氏名、年齢、生後経過時間、性別、職業、職位、住宅の有無、結婚の有無、被扶養者の有無、所有している金融商品(その金融商品の属性情報と関連付けられている。)、現在の年収、現在の家計支出、投資性向、などのいずれか一以上を含む顧客属性情報を取得する顧客属性情報取得部と、
顧客を識別する顧客識別情報を保持する顧客識別情報保持部と、
取得した顧客属性情報を顧客識別情報と関連付けて保持する顧客属性情報保持部と、
入社、本人の結婚、自宅購入、出産、子供の入学、子供の結婚などのまとまった出費が発生するイベントであるライフイベントを識別するライフイベント識別情報を保持するライフイベント識別情報保持部と、
保持されている顧客属性情報に基づいて、顧客識別情報で識別される顧客に今後発生する見込みがあるライフイベントを識別するライフイベント識別情報である見込ライフイベント識別情報をライフイベント識別情報保持部から選択可能に取得し、顧客の見込ライフイベント発生時の将来時期(年齢であってもよい)と関連付けて選択させる見込ライフイベント識別情報選択受付部と、
選択された、又は選択の有無とは無関係に見込ライフイベント識別情報を少なくとも含む将来情報(見込ライフイベント発生時の将来時期と関連付けられているもの)を顧客識別情報と関連付けて保持する将来情報保持部と、
金融商品の属性情報である金融商品属性情報と関連付けて金融商品を識別する金融商品識別情報を保持する金融商品識別情報保持部と、
顧客識別情報と関連付けられた顧客属性情報又は/及び取得された将来情報とに基づいて少なくとも複数の見込みライフイベント識別情報で識別されるライフイベントでの出費の少なくとも一部をまかなうためにライフイベントの発生予定時期に向けて継続的に又は/及びスポット的に投資する金融商品の金融商品識別情報が少なくとも一以上含まれるように時系列で保持されている金融商品識別情報を選択するルールである金融商品識別情報選択ルールを保持する金融商品識別情報選択ルール保持部と、
顧客属性情報又は/及び取得された将来情報と、金融商品識別情報選択ルールとに基づいて金融商品識別情報を選択する金融商品識別情報選択部と、
選択された金融商品識別情報を顧客識別情報と関連付けて出力する金融商品識別情報出力部と、
を有するライフイベント型金融商品情報出力装置。
【請求項2】
顧客識別情報と関連付けて将来の収入を示す情報である将来収入情報を取得する将来収入情報取得部をさらに有し、
前記将来情報保持部は将来情報としてさらに将来収入情報を保持するように構成された請求項1に記載のライフイベント型金融商品情報出力装置。
【請求項3】
顧客識別情報と関連付けて将来の支出を示す情報である将来支出情報を取得する将来支出情報取得部をさらに有し、
前記将来情報保持部は将来情報としてさらに将来収支出情報を保持するように構成された請求項1または2のいずれか一に記載のライフイベント型金融商品情報出力装置。
【請求項4】
将来収入情報取得部で取得した将来収入情報と、将来支出情報取得部で取得した将来支出情報とに基づいて金融商品を購入するための金額である将来積立情報を取得する将来積立情報取得部を有し、
前記将来情報保持部は、将来情報として将来積立情報を保持するように構成される請求項2に従属する請求項3に記載のライフイベント型金融商品情報出力装置。
【請求項5】
将来収入情報取得部で取得した将来収入情報と、将来支出情報取得部で取得した将来支出情報と、将来積立情報取得部にて取得した将来積立情報と、に基づいて将来の資産を示す情報である将来資産情報を取得する将来資産情報取得部を有し、
前記将来情報保持部は、将来情報として将来資産情報を保持するように構成される請求項4に記載のライフイベント型金融商品情報出力装置。
【請求項6】
助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持する公的制度識別情報保持部と、
顧客識別情報で識別される顧客が今後享受する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得する公的制度識別情報取得部と、をさらに有し、
将来収入情報取得部は、見込公的制度識別情報に基づいて将来収入情報を取得することを特徴とする
請求項2に記載のライフイベント型金融商品情報出力装置。
【請求項7】
助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持する公的制度識別情報保持部と、
顧客識別情報で識別される顧客が今後享受する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得する公的制度識別情報取得部と、をさらに有し、
将来支出情報取得部は、見込公的制度識別情報に基づいて将来支出情報を取得することを特徴とする
請求項3に記載のライフイベント型金融商品情報出力装置。
【請求項8】
日々の衣食住に関わる支出である家計情報を取得する家計情報取得部をさらに有し、
前記将来支出情報取得部は、前記家計情報取得部の家計情報に基づいて、将来支出情報を取得することを特徴とする請求項3に記載のライフイベント型金融商品情報出力装置。
【請求項9】
見込ライフイベント識別情報に含まれるライフイベント発生時に、ライフイベントの履行状況を確認する見込ライフイベント履行状況取得部を有し、
見込みライフイベント履行状況取得部の取得結果に基づいて、将来情報保持部の内容を更新する請求項1に記載のライフイベント型金融商品情報出力装置。
【請求項10】
ライフイベント識別情報に関連付けて、ライフイベントに関わる、平均的な金額、最低必要金額、上限金額、路線価、公示地価、税制情報、助成金情報等のいずれか一以上の情報を含むライフイベント関連情報を保持するライフイベント関連情報保持部と、
顧客の要求に基づいて、ライフイベント関連情報を出力するライフイベント関連情報提供部と、を有する請求項1に記載のライフイベント型金融商品情報出力装置。
【請求項11】
顧客属性情報取得部は、顧客の近親者の情報である顧客近親者情報(例えば親の年齢を含む情報、子供の情報(子供の年齢を含むとなおよい。))を取得するための顧客近親者情報取得手段を有し、
顧客属性情報保持部は取得した顧客近親者情報を保持する顧客近親者情報保持手段をさらに有する請求項1に記載のライフイベント型金融商品情報出力装置。
【請求項12】
顧客属性情報取得部は、顧客の健康に関する情報である顧客健康関連情報(例えば、基礎疾患、更年期障害、三大疾病)を取得するための顧客健康関連報取得手段(全国民健康関連情報データベースから自動取得するように構成してもよい)を有し、
顧客属性情報保持部は取得した顧客健康関連情報を保持する顧客健康関連情報保持手段をさらに有する請求項1に記載のライフイベント型金融商品情報出力装置。
【請求項13】
ライフイベント型金融商品情報出力装置は、
閲覧者を識別する閲覧者識別情報を顧客識別情報と関連付けて保持する閲覧者識別情報保持部と、
閲覧者識別情報に関連付けて顧客識別情報で識別される顧客の顧客属性情報又は/及び、購入契約情報の閲覧を要求する情報である閲覧要求情報を取得する閲覧要求情報取得部と、
取得した閲覧要求情報に含まれる顧客識別情報が取得された閲覧者識別情報に関連付けられているか判断する閲覧権限判断部と、
判断結果が関連付けられているとの判断結果である場合に、その顧客識別情報で識別される顧客の顧客属性情報又は/及び購入契約情報の閲覧を閲覧要求情報に関わる閲覧者識別情報で識別される閲覧者に閲覧させる閲覧部と、
を有する請求項1に記載のライフイベント型金融商品情報出力装置。
【請求項14】
出力された金融商品識別情報に基づいてその金融商品識別情報で識別される金融商品の購入契約情報を取得する購入契約情報取得部と、
取得した購入契約情報を保持する購入契約情報保持部と、
を有する請求項1に記載のライフイベント型金融商品出力装置。
【請求項15】
請求項14に記載のライフイベント型金融商品出力装置と、
顧客識別情報を保持する顧客識別情報保持部と、
ライフイベント型金融商品出力装置から金融商品識別情報を取得する金融商品識別情報取得部と、
取得した金融商品識別情報を保持する金融商品識別情報保持部と、
取得した金融商品識別情報に基づいて金融商品の購入契約をするための購入契約情報の入力を受付ける購入契約情報入力受付部と、
受付けた購入契約情報を保持されている顧客識別情報と関連付けて出力する購入契約情報出力部と、
入力を受付けた購入契約情報に基づいて購入契約をするための処理をする購入契約処理部と、
購入契約を締結した金融商品の運用状況に関する情報である運用状況情報を取得する運用状況情報取得部と、
取得した運用状況情報を出力する運用状況情報出力部と、
を有する顧客利用端末と、からなる金融商品運用システム。
【請求項16】
顧客の氏名、年齢、生後経過時間、性別、職業、職位、住宅の有無、結婚の有無、被扶養者の有無、所有している金融商品、現在の年収、家計支出などのいずれか一以上を含む顧客属性情報を取得する顧客属性情報取得ステップと、
顧客を識別する顧客識別情報を保持する顧客識別情報保持ステップと、
取得した顧客属性情報を顧客識別情報と関連付けて保持する顧客属性情報保持ステップと、
入社、本人の結婚、自宅購入、出産、子供の入学、子供の結婚などのまとまった出費が発生するイベントであるライフイベントを識別するライフイベント識別情報を保持するライフイベント識別情報保持ステップと、
保持されている顧客属性情報に基づいて、顧客識別情報で識別される顧客に今後発生する見込みがあるライフイベントを識別するライフイベント識別情報である見込ライフイベント識別情報をライフイベント識別情報保持部から選択可能に取得し、顧客の見込ライフイベント発生時の将来時期(年齢であってもよい)と関連付けて選択させる見込ライフイベント識別情報選択受付ステップと、
選択された、又は選択の有無とは無関係に見込ライフイベント識別情報を少なくとも含む将来情報を顧客識別情報と関連付けて保持する将来情報保持ステップと、
金融商品の属性情報である金融商品属性情報と関連付けて金融商品を識別する金融商品識別情報を保持する金融商品識別情報保持ステップと、
顧客識別情報と関連付けられた顧客属性情報又は/及び取得された将来情報とに基づいて少なくとも複数の見込みライフイベント識別情報で識別されるライフイベントでの出費の少なくとも一部をまかなうためにライフイベントの発生予定時期に向けて継続的に又は/及びスポット的に投資する金融商品の金融商品識別情報が少なくとも一以上含まれるように時系列で保持されている金融商品識別情報を選択するルールである金融商品識別情報選択ルールを保持する金融商品識別情報選択ルール保持ステップと、
顧客属性情報と将来情報と、金融商品識別情報選択ルールとに基づいて金融商品識別情報を選択する金融商品識別情報選択ステップと、
選択された金融商品識別情報を顧客識別情報と関連付けて出力する金融商品識別情報出力ステップと、
を有するライフイベント型金融商品情報出力装置の制御方法。
【請求項17】
顧客の氏名、年齢、生後経過時間、性別、職業、職位、住宅の有無、結婚の有無、被扶養者の有無、所有している金融商品、現在の年収、家計支出などのいずれか一以上を含む顧客属性情報を取得する顧客属性情報取得プログラムと、
顧客を識別する顧客識別情報を保持する顧客識別情報保持プログラムと、
取得した顧客属性情報を顧客識別情報と関連付けて保持する顧客属性情報保持プログラムと、
入社、本人の結婚、自宅購入、出産、子供の入学、子供の結婚などのまとまった出費が発生するイベントであるライフイベントを識別するライフイベント識別情報を保持するライフイベント識別情報保持プログラムと、
保持されている顧客属性情報に基づいて、顧客識別情報で識別される顧客に今後発生する見込みがあるライフイベントを識別するライフイベント識別情報である見込ライフイベント識別情報をライフイベント識別情報保持部から選択可能に取得し、顧客の見込ライフイベント発生時の将来時期(年齢であってもよい)と関連付けて選択させる見込ライフイベント識別情報選択受付プログラムと、
選択された、又は選択の有無とは無関係に見込ライフイベント識別情報を少なくとも含む将来情報を顧客識別情報と関連付けて保持する将来情報保持プログラムと、
金融商品の属性情報である金融商品属性情報と関連付けて金融商品を識別する金融商品識別情報を保持する金融商品識別情報保持プログラムと、
顧客識別情報と関連付けられた顧客属性情報又は/及び取得された将来情報とに基づいて少なくとも複数の見込みライフイベント識別情報で識別されるライフイベントでの出費の少なくとも一部をまかなうためにライフイベントの発生予定時期に向けて継続的に又は/及びスポット的に投資する金融商品の金融商品識別情報が少なくとも一以上含まれるように時系列で保持されている金融商品識別情報を選択するルールである金融商品識別情報選択ルールを保持する金融商品識別情報選択ルール保持プログラムと、
顧客属性情報と将来情報と、金融商品識別情報選択ルールとに基づいて金融商品識別情報を選択する金融商品識別情報選択プログラムと、
選択された金融商品識別情報を顧客識別情報と関連付けて出力する金融商品識別情報出力プログラムと、
を有するライフイベント型金融商品情報出力装置の制御プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、顧客のライフイベントに対応するための資産形成を支援する金融商品情報を出力するライフイベント型金融商品情報出力装置に関する。
【背景技術】
【0002】
近年、平均寿命は順調な伸びを見せており、人生100年時代と言われるように、老後といわれる生活の期間が長くなり、十分な資産形成をしておく必要が迫られている。一方で、人生にはライフイベントとよばれ、例えば、学費、結婚、出産、住宅購入など大きな出費を伴うイベントがある。また、介護、病気など予期せぬ大きな出費を伴うこともある。こうした出費に対して、十分な備えが無ければ、不足分を借入して出費に充てる必要がある。借金をした場合、借入残高に対して、利息がかかり、その利息は返済金から差し引かれるため、元金の返済が進まず、借入期間が長いと実際に借入した金額よりも、多額の返済を行わなければならなくなる。こうしたことから、借入は資産形成の大きな障害となり老後の生活不安へとつながるものである。
【0003】
しかしながら、多くの人々は、健康なうちは老後の生活や、ライフイベントに対する出費など、漠然と考え、生活の余剰資金を貯蓄や資産形成に充てる程度で、十分将来のライフイベントに備えた貯蓄や、資産運用計画ができているとは言い難い。また、資産運用は、貯蓄と比較して、運用利回りが大きく、大きく資産を増やすこともあるが、逆に元本割れを起こすリスクもあり、商品も様々で金融商品に対する知識も必要となる。特に、余剰資金を運用するわけではなく、ライフプランや、ライフイベントに対して投資による運用を行う場合は、そのライフイベントの性質にあった金融商品を選択する必要がある。
【0004】
例えば、教育費に関しては、発生時期は決まっており、想定した金額を必ず確保する必要があるため、未達許容度は低く、リスクの低い商品(例えば、学資保険、預金、債券)を選択する必要があるが、車の購入などは、買い替え時期を後にずらしたり、車のグレードを抑えるなど、資産の状態に応じて対応が可能なため、未達許容度が高いと言え、ハイリスクな金融商品(投資信託や株)を選択したりしても良い。この場合、運用により利益が出た場合、予定していた車よりも高いグレードの車を購入しても良いし、運用が振るわず元本を割り込んだ場合は、新車ではなく中古車にするなどの対応が考えられる。
【0005】
以上のように、ライフイベントの特性に合わせた運用が行われるべきであるが、もし、ライフイベントの特性に合わない商品を選択してしまった場合、例えば、老後資金に対してハイリスクな金融商品を選択して、大きく資産を失ってしまった場合は取り返しがつかない事態となる。
したがって、ライフイベントの特性を考慮して、それに備えた資産運用を手軽に行える方法があれば、多くの人が将来の不安を解消できるようになる。またそのような金融商品の選択は利用者を安心させるために他の金融商品と比較して購入の動機付けが高くなる(販売促進をしやすい)傾向があると考えられる。
【0006】
このようなことから、ライフイベントに備えた資産運用を行うものとして、例えば特許文献1では、各イベントの発生を意識した資産運用を計画するシステムを提供する。このシステムでは、ライフイベントごとの目標額および達成時期を含むイベント情報に基づき、各イベントのための資産運用計画を作成する制御部を備える。ライフイベント毎に目標額、達成時期、支出額、時期の変更の可否、支出額の変更の可否、未達許容度を考慮し、イベント毎のポートフォリオを形成し金融商品の売買を行うようにしていた。
【0007】
また、特許文献2では、資産運用における未達許容度に適合した資産運用方法に基づくライフプランニングを行えるようにする。ライフプランニング装置は、資産運用に対する未達許容度、所有資産額、住宅購入等の将来のライフイベントの時期およびその支出予定金額等を含んだ基本データの入力を受け、未達許容度に適合した資産運用方法を決定する。また、所有資産額と、決定された資産運用方法の期待収益率と、ライフイベントの時期およびその支出予定金額とに基づいて、資産額の将来の時系列的な変化を表す収支表を計算するようにしていた。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】WO2017/221448号
【特許文献2】特開2004-295492号
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかしながら、特許文献1記載の情報処理装置、及び特許文献2記載のライフプランニング装置に共通することであるが、ライフイベントを考慮した資産運用の計画及び、シミュレーションは行えるが、生涯のライフプランを考えるためには、さまざまな要件を考慮する必要があり、十分とは言えない。
例えば、積立金額やライフイベントによる支出、金融商品の運用利回りなどが考慮されているが、それ以外にも、助成金や奨学金などの収入や借入も考慮する必要があるし、所得控除や年金など税制も考慮した運用なども大きく影響する。また、ライフイベントのある/なしや支出額は、人により違いがあり、発生時期も変化する場合がありその点も考慮する必要がある。また、利用者のライフイベントに対する知識も十分でない可能性もある。
【0010】
例えば、児童手当などは、日々の生活費にあてるよりも、将来的な学費として貯蓄しておくほうが好ましい。また、老後を考えた場合、iDeCoで年金として積立を行うことで所得が控除され、税金や社会保障費の低減につながるし、退職金の場合は一時金による取得と年金による取得が考えられるが、取得方法により税制区分が異なり、一般的には一時金で取得したほうが、税金が低く抑えられる。こうしたことから、退職金を切り崩して、年金の繰下げ支給を選択することで、支給金額を割り増しできるので、退職金をいくら運用するか、年金支給を何年繰り下げるかなどの選択により、所得金額が大きく異なってくる。
【0011】
また、人々の生活も多様化しており、住宅は購入せず一生賃貸で構わないと考える人もいれば、結婚はしない、したいが出来ないなど、人それぞれである。また、子供が欲しいと思う夫婦もいれば、子供はいなくて良いと考える夫婦も増えてきており、不妊も大きな社会問題となってきている。こうしたことから、一般的にライフイベントと考えられているイベントが、そもそも必要ない人もおり、人それぞれに対応したライフイベントを考慮する必要がある。
【0012】
また、ライフイベントで必要とする費用は、だれでも一律ではなく、生活レベル、居住地、職業などで大きく異なってくる。例えば、東京在住の人の住宅価格が一生の支出に占める割合と、北海道在住の人の住宅価格が一生の支出に占める割合は大きく異なる。また、いわゆるメタボリックシンドロームに分類される人と、標準体型の人が大きな病気にかかるリスクは異なるので、備えておくべき医療費も異なってくる。こうしたことから、人それぞれに対応したライフイベント目標を設定する必要がある。
【0013】
また、ライフイベントの時期は、おおそよ見当はつくが、正確なタイミングが分からない場合や、もともと予定していたが、発生しなくなるケースもある。また、けがや病気は、いつ発生するかわからず思わぬ出費となる。こうした場合に、資産運用計画を見直す必要が生じる。
【0014】
また、ライフイベントは、一般的には一生のうちに何度も経験するものではない。このため、各ライフイベントに対してどのような対応をすればよいか、ライフイベントに伴う申請手続きなどをどのようにしたら良いかなど戸惑うことが多い。例えば、住宅購入では、転入届けや免許証の住所変更、電気、水道の手続きなど様々な手続きが必要となる。また、病気に際しては、高額医療費の申請や保険の申請など行わなくても問題ないが、不利益となってしまうものもある。
【0015】
本発明のライフプラン支援ステムは、以上に述べてきた課題に着目し開発されたものであり、顧客の生涯発生し得るライフイベントに基づいて、税金や年金、公的給付金といった様々な収支も考慮しつつ、ライフイベントや金融商品に対する知識が十分でない顧客でも安心して使いこなせ、ライフイベントに関わる様々な問題に対処可能なサービスを提供することを目的とする。
【課題を解決するための手段】
【0016】
そこで、本発明においては、結婚、出産、教育、介護、住居購入、転職、退職といったライフイベント別に設計された目的型金融商品ポートフォリオについて、顧客の属性情報や家族構成に基づいてシミュレーションを行い、将来にわたる支出と収入の変化や税制措置や元本取崩等を総合的に考慮し、最適な金融商品ポートフォリオを選択・販売し、併せて金融商品の運用に必要な情報提供も行う総合的なサービスを提供する。
【0017】
金融商品を目的別にポートフォリオ化して販売する利点は、金融商品の分散によるリスク管理が行える点にあり、ライフイベントに関わる、イベント発生までの期間、未達許容度、目標達成までの難易度、目標の見直し、イベント発生時期の変動、イベントの消滅など様々な要素を考慮して設計が行える点にある。
【0018】
具体的には、第一の発明として、顧客の氏名、年齢、生後経過時間、性別、職業、職位、住宅の有無、結婚の有無、被扶養者の有無、所有している金融商品(その金融商品の属性情報と関連付けられている。)、現在の年収、現在の家計支出、投資性向、などのいずれか一以上を含む顧客属性情報を取得する顧客属性情報取得部と、顧客を識別する顧客識別情報を保持する顧客識別情報保持部と、取得した顧客属性情報を顧客識別情報と関連付けて保持する顧客属性情報保持部と、入社、本人の結婚、自宅購入、出産、子供の入学、子供の結婚などのまとまった出費が発生するイベントであるライフイベントを識別するライフイベント識別情報を保持するライフイベント識別情報保持部と、保持されている顧客属性情報に基づいて、顧客識別情報で識別される顧客に今後発生する見込みがあるライフイベントを識別するライフイベント識別情報である見込ライフイベント識別情報をライフイベント識別情報保持部から選択可能に取得し、顧客の見込ライフイベント発生時の将来時期(年齢であってもよい)と関連付けて選択させる見込ライフイベント識別情報選択受付部と、選択された、又は選択の有無とは無関係に見込ライフイベント識別情報を少なくとも含む将来情報(見込ライフイベント発生時の将来時期と関連付けられているもの)を顧客識別情報と関連付けて保持する将来情報保持部と、金融商品の属性情報である金融商品属性情報と関連付けて金融商品を識別する金融商品識別情報を保持する金融商品識別情報保持部と、顧客識別情報と関連付けられた顧客属性情報又は/及び取得された将来情報とに基づいて少なくとも複数の見込みライフイベント識別情報で識別されるライフイベントでの出費の少なくとも一部をまかなうためにライフイベントの発生予定時期に向けて継続的に又は/及びスポット的に投資する金融商品の金融商品識別情報が少なくとも一以上含まれるように時系列で保持されている金融商品識別情報を選択するルールである金融商品識別情報選択ルールを保持する金融商品識別情報選択ルール保持部と、顧客属性情報又は/及び取得された将来情報と、金融商品識別情報選択ルールとに基づいて金融商品識別情報を選択する金融商品識別情報選択部と、選択された金融商品識別情報を顧客識別情報と関連付けて出力する金融商品識別情報出力部と、を有するライフイベント型金融商品情報出力装置を提供する。
【0019】
また、第二の発明として、前記構成に加えて、顧客識別情報と関連付けて将来の収入を示す情報である将来収入情報を取得する将来収入情報取得部をさらに有し、前記将来情報保持部は将来情報としてさらに将来収入情報を保持するように構成されたライフイベント型金融商品情報出力装置を提供する。
【0020】
また、第三の発明として、前記構成に加えて、顧客識別情報と関連付けて将来の支出を示す情報である将来支出情報を取得する将来支出情報取得部をさらに有し、前記将来情報保持部は将来情報としてさらに将来収支出情報を保持するように構成されたライフイベント型金融商品情報出力装置を提供する。
【0021】
また、第四の発明として、前記構成に加えて、将来収入情報取得部で取得した将来収入情報と、将来支出情報取得部で取得した将来支出情報とに基づいて金融商品を購入するための金額である将来積立情報を取得する将来積立情報取得部を有し、前記将来情報保持部は、将来情報として将来積立情報を保持するように構成されるライフイベント型金融商品情報出力装置を提供する。
【0022】
また、第五の発明として、前記構成に加えて、将来収入情報取得部で取得した将来収入情報と、将来支出情報取得部で取得した将来支出情報と、将来積立情報取得部にて取得した将来積立情報と、に基づいて将来の資産を示す情報である将来資産情報を取得する将来資産情報取得部を有し、前記将来情報保持部は、将来情報として将来資産情報を保持するように構成されるライフイベント型金融商品情報出力装置を提供する。
【0023】
また、第六の発明として、前記構成に加えて、助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持する公的制度識別情報保持部と、顧客識別情報で識別される顧客が今後享受する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得する公的制度識別情報取得部と、をさらに有し、将来収入情報取得部は、見込公的制度識別情報に基づいて将来収入情報を取得することを特徴とするライフイベント型金融商品情報出力装置を提供する。
【0024】
また、第七の発明として、前記構成に加えて、助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持する公的制度識別情報保持部と、顧客識別情報で識別される顧客が今後享受する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得する公的制度識別情報取得部と、をさらに有し、将来支出情報取得部は、見込公的制度識別情報に基づいて将来支出情報を取得することを特徴とするライフイベント型金融商品情報出力装置を提供する。
【0025】
また、第八の発明として、前記構成に加えて、日々の衣食住に関わる支出である家計情報を取得する家計情報取得部をさらに有し、前記将来支出情報取得部は、前記家計情報取得部の家計情報に基づいて、将来支出情報を取得することを特徴とするライフイベント型金融商品情報出力装置を提供する。
【0026】
また、第九の発明として、前記構成に加えて、見込ライフイベント識別情報に含まれるライフイベント発生時に、ライフイベントの履行状況を確認する見込ライフイベント履行状況取得部を有し、見込みライフイベント履行状況取得部の取得結果に基づいて、将来情報保持部の内容を更新するライフイベント型金融商品情報出力装置を提供する。
【0027】
また、第十の発明として、前記構成に加えて、ライフイベント識別情報に関連付けて、ライフイベントに関わる、平均的な金額、最低必要金額、上限金額、路線価、公示地価、税制情報、助成金情報等のいずれか一以上の情報を含むライフイベント関連情報を保持するライフイベント関連情報保持部と、顧客の要求に基づいて、ライフイベント関連情報を出力するライフイベント関連情報提供部と、を有するライフイベント型金融商品情報出力装置を提供する。
【0028】
また、第十一の発明として、前記構成に加えて、顧客属性情報取得部は、顧客の近親者の情報である顧客近親者情報(例えば親の年齢を含む情報、子供の情報(子供の年齢を含むとなおよい。))を取得するための顧客近親者情報取得手段を有し、顧客属性情報保持部は取得した顧客近親者情報を保持する顧客近親者情報保持手段をさらに有するライフイベント型金融商品情報出力装置を提供する。
【0029】
また、第十二の発明として、前記構成に加えて、顧客属性情報取得部は、顧客の健康に関する情報である顧客健康関連情報(例えば、基礎疾患、更年期障害、三大疾病)を取得するための顧客健康関連報取得手段(全国民健康関連情報データベースから自動取得するように構成してもよい)を有し、
顧客属性情報保持部は取得した顧客健康関連情報を保持する顧客健康関連情報保持手段をさらに有するライフイベント型金融商品情報出力装置を提供する。
【0030】
また、第十三の発明として、前記構成に加えて、ライフイベント型金融商品情報出力装置は、閲覧者を識別する閲覧者識別情報を顧客識別情報と関連付けて保持する閲覧者識別情報保持部と、閲覧者識別情報に関連付けて顧客識別情報で識別される顧客の顧客属性情報又は/及び、購入契約情報の閲覧を要求する情報である閲覧要求情報を取得する閲覧要求情報取得部と、取得した閲覧要求情報に含まれる顧客識別情報が取得された閲覧者識別情報に関連付けられているか判断する閲覧権限判断部と、判断結果が関連付けられているとの判断結果である場合に、その顧客識別情報で識別される顧客の顧客属性情報又は/及び購入契約情報の閲覧を閲覧要求情報に関わる閲覧者識別情報で識別される閲覧者に閲覧させる閲覧部と、を有するライフイベント型金融商品情報出力装置を提供する。
【0031】
また、第十四の発明として、前記構成に加えて、出力された金融商品識別情報に基づいてその金融商品識別情報で識別される金融商品の購入契約情報を取得する購入契約情報取得部と、取得した購入契約情報を保持する購入契約情報保持部を有するライフイベント型金融商品出力装置を提供する。
【0032】
また、第十五の発明として、前記構成に加えて、顧客識別情報を保持する顧客識別情報保持部と、ライフイベント型金融商品出力装置から金融商品識別情報を取得する金融商品識別情報取得部と、取得した金融商品識別情報を保持する金融商品識別情報保持部と、取得した金融商品識別情報に基づいて金融商品の購入契約をするための購入契約情報の入力を受付ける購入契約情報入力受付部と、受付けた購入契約情報を保持されている顧客識別情報と関連付けて出力する購入契約情報出力部と、入力を受付けた購入契約情報に基づいて購入契約をするための処理をする購入契約処理部と、購入契約を締結した金融商品の運用状況に関する情報である運用状況情報を取得する運用状況情報取得部と、取得した運用状況情報を出力する運用状況情報出力部と、を有する顧客利用端末と、からなる金融商品運用システムを提供する。
【0033】
また、第十六の発明として、顧客の氏名、年齢、生後経過時間、性別、職業、職位、住宅の有無、結婚の有無、被扶養者の有無、所有している金融商品、現在の年収、家計支出などのいずれか一以上を含む顧客属性情報を取得する顧客属性情報取得ステップと、顧客を識別する顧客識別情報を保持する顧客識別情報保持ステップと、取得した顧客属性情報を顧客識別情報と関連付けて保持する顧客属性情報保持ステップと、入社、本人の結婚、自宅購入、出産、子供の入学、子供の結婚などのまとまった出費が発生するイベントであるライフイベントを識別するライフイベント識別情報を保持するライフイベント識別情報保持ステップと、 保持されている顧客属性情報に基づいて、顧客識別情報で識別される顧客に今後発生する見込みがあるライフイベントを識別するライフイベント識別情報である見込ライフイベント識別情報をライフイベント識別情報保持部から選択可能に取得し、顧客の見込ライフイベント発生時の将来時期(年齢であってもよい)と関連付けて選択させる見込ライフイベント識別情報選択受付ステップと、選択された、又は選択の有無とは無関係に見込ライフイベント識別情報を少なくとも含む将来情報を顧客識別情報と関連付けて保持する将来情報保持ステップと、金融商品の属性情報である金融商品属性情報と関連付けて金融商品を識別する金融商品識別情報を保持する金融商品識別情報保持ステップと、顧客識別情報と関連付けられた顧客属性情報又は/及び取得された将来情報に基づいて少なくとも複数の見込みライフイベント識別情報で識別されるライフイベントでの出費の少なくとも一部をまかなうためにライフイベントの発生予定時期に向けて継続的に又は/及びスポット的に投資する金融商品の金融商品識別情報が少なくとも一以上含まれるように時系列で保持されている金融商品識別情報を選択するルールである金融商品識別情報選択ルールを保持する金融商品識別情報選択ルール保持ステップと、顧客属性情報と、将来情報と、金融商品識別情報選択ルールと、に基づいて金融商品識別情報を選択する金融商品識別情報選択ステップと、選択された金融商品識別情報を顧客識別情報と関連付けて出力する金融商品識別情報出力ステップと、を有するライフイベント型金融商品情報出力装置の制御方法を提供する。
【0034】
また、第十七の発明として、顧客の氏名、年齢、生後経過時間、性別、職業、職位、住宅の有無、結婚の有無、被扶養者の有無、所有している金融商品、現在の年収、家計支出などのいずれか一以上を含む顧客属性情報を取得する顧客属性情報取得プログラムと、顧客を識別する顧客識別情報を保持する顧客識別情報保持プログラムと、取得した顧客属性情報を顧客識別情報と関連付けて保持する顧客属性情報保持プログラムと、入社、本人の結婚、自宅購入、出産、子供の入学、子供の結婚などのまとまった出費が発生するイベントであるライフイベントを識別するライフイベント識別情報を保持するライフイベント識別情報保持プログラムと、保持されている顧客属性情報に基づいて、顧客識別情報で識別される顧客に今後発生する見込みがあるライフイベントを識別するライフイベント識別情報である見込ライフイベント識別情報をライフイベント識別情報保持部から選択可能に取得し、顧客の見込ライフイベント発生時の将来時期(年齢であってもよい)と関連付けて選択させる見込ライフイベント識別情報選択受付プログラムと、選択された、又は選択の有無とは無関係に見込ライフイベント識別情報を少なくとも含む将来情報を顧客識別情報と関連付けて保持する将来情報保持プログラムと、金融商品の属性情報である金融商品属性情報と関連付けて金融商品を識別する金融商品識別情報を保持する金融商品識別情報保持プログラムと、顧客識別情報と関連付けられた顧客属性情報又は/及び取得された将来情報に基づいて少なくとも複数の見込みライフイベント識別情報で識別されるライフイベントでの出費の少なくとも一部をまかなうためにライフイベントの発生予定時期に向けて継続的に又は/及びスポット的に投資する金融商品の金融商品識別情報が少なくとも一以上含まれるように時系列で保持されている金融商品識別情報を選択するルールである金融商品識別情報選択ルールを保持する金融商品識別情報選択ルール保持プログラムと、顧客属性情報と、将来情報と、金融商品識別情報選択ルールと、に基づいて金融商品識別情報を選択する金融商品識別情報選択プログラムと、選択された金融商品識別情報を顧客識別情報と関連付けて出力する金融商品識別情報出力プログラムと、を有するライフイベント型金融商品情報出力装置の制御プログラムを提供する。
【発明の効果】
【0035】
本発明によれば、資産運用に関する十分な知識を持たない利用者でも、ライフイベントに関わる公的支援制度、税制、年金制度などの実際の収入以外の要素も考慮しつつ、ライフイベントに備えた最適な資産形成が行える。
【図面の簡単な説明】
【0036】
図1】本ビジネスモデルの概要を示す図
図2】実施形態1のライフイベント型金融商品情報出力装置の機能構成を 示すブロック図
図3】顧客属性情報の入力に関わる顧客情報登録画面の一例を示す図
図4A】ログイン画面の一例を示す図
図4B】メインメニュー画面の一例を示す図
図5A】家族構成入力画面の一例を示す図
図5B】収入入力画面の一例を示す図
図5C】支出入力画面の一例を示す図
図5D】ポートフォリオ入力画面の一例を示す図
図5E】進学予定入力画面の一例を示す図
図6】見込ライフイベント入力画面の一例を示す図
図7】ライフイベント一覧画面の一例を示す図
図8】見込ライフイベント追加画面の一例を示す図
図9】金融商品識別情報選択処理の流れを示すフローチャート図
図10】ライフイベントに対応した購入金額・金融商品指定画面の一例を 示す図
図11】金融商品選択画面の一例を示す図
図12】イベント別積立金額確認画面の一例を示す図
図13】購入金融商品確認画面の一例を示す図
図14】積立状況確認画面の一例を示す図
図15】ライフイベント到来時の積立結果確認画面の一例を示す図
図16】ライフプランシミュレーションの処理の流れを示すフロー チャート図
図17】ライフイベント向け積立資産の推移の一例(並列積立)を示す図
図18】ライフイベント向け積立資産の推移の一例(直列積立)を示す図
図19】実施形態1のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図20】実施形態1のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図21】実施形態2のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図22】収入入力画面の一例を示す図
図23】将来収入情報の一例を示す図
図24】実施形態2のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図25】実施形態2のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図26】実施形態3のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図27】実施形態3のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図28】実施形態3のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図29】将来支出情報の一例を示す図
図30】実施形態4のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図31】実施形態4のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図32】実施形態4のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図33】実施形態5のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図34】実施形態5のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図35】実施形態5のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図36】実施形態6のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図37】実施形態6のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図38】実施形態6のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図39】実施形態7のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図40】実施形態7のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図41】実施形態7のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図42】将来積立情報を含む将来情報の一例を示す図
図43】将来支出情報を含む将来情報の一例を示す図
図44】実施形態8のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図45】実施形態8のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図46】実施形態8のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図47】家計情報取得部のユーザインタフェースの一例を示す図
図48】実施形態9のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図49】実施形態9のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図50】実施形態9のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図51】見込ライフイベント履行状況取得部が行う顧客との対話の一例を 示す図
図52】見込ライフイベント履行確認通知の一例を示す図
図53】実施形態10のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図54】実施形態10のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図55】実施形態10のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図56】ライフイベント関連情報提供部により提供される情報の一例を 示す図
図57】実施形態11のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図58】実施形態11のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図59】実施形態11のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図60】実施形態11の近親者を含む家族構成入力画面の一例を示す図
図61】実施形態12のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図62】実施形態12のライフイベント型金融商品情報出力装置の制御の 流れを示すフローチャート図
図63】実施形態12のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図64】実施形態13の顧客一覧画面の一例を示す図
図65】実施形態13の顧客情報閲覧画面の一例を示す図
図66】実施形態13のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図67】実施形態13のライフイベント型金融商品情報出力装置の閲覧処理 の制御の流れを示すフローチャート
図68】実施形態13のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図69】実施形態14のライフイベント型金融商品情報出力装置の機能構成 を示すブロック図
図70】実施形態14のライフイベント型金融商品情報出力装置の金融商品 情報出力処理の制御の流れを示すフローチャート
図71】実施形態14のライフイベント型金融商品情報出力装置のハード ウェア構成を示すブロック図
図72】実施形態15の金融商品運用システムの顧客利用端末の機能構成 を示すブロック図
図73】実施形態15の金融商品運用システムの顧客利用端末のハード ウェア構成を示すブロック図
図74】実施形態15の金融商品運用システムの顧客利用端末の制御の 流れを示すフローチャート
図75】本発明の基本ハードウェア構成図
図76】日本株における期待利回りと標準偏差の関係を表す一例を示す図
【0037】
<本発明を構成し得るハードウェアについて>
図75は、本件発明に適用される基本ハードウェア構成図である。
本件発明は、原則的に電子計算機を利用する発明であるが、ソフトウェアによって実現され、ハードウェアによっても実現され、ソフトウェアとハードウェアの協働によっても実現される。本件発明の各構成要件の全部又は一部を実現するハードウェアでは、コンピュータの基本的構成であるCPU、メモリ、バス、入出力装置、各種周辺機器、ユーザインタフェースなどによって構成される。各種周辺機器には、記憶装置、インターネット等インタフェース、インターネット等機器、ディスプレイ、キーボード、マウス、スピーカー、カメラ、ビデオ、テレビ、実験室又は工場などでの生産状態を把握するための各種センサ(流量センサ、温度センサ、重量センサ、液量センサ、赤外線センサ、出荷個数計数機、梱包個数計数機、異物検査装置、不良品計数機、放射線検査装置、表面状態検査装置、回路検査装置、人感センサ、作業者作業状況把握装置(映像、ID、PC作業量などで)等)、CD装置、DVD装置、ブルーレイ装置、USBメモリ、USBメモリインタフェース、着脱可能タイプのハードディスク、一般的なハードディスク、プロジェクタ装置、SSD、電話、ファックス、コピー機、印刷装置、ムービー編集装置、各種センサ装置などが含まれる。また、本システムは、必ずしも一つの筐体によって構成されている必要はなく、複数の筐体を通信で結合して構成されるものであってもよい。また、通信は、LANであってもWAN、WiFi(登録商標)、ブルートゥース(登録商標)、赤外線通信、超音波通信であってもよく、さらに、一部が国境を跨いで設置されていてもよい。さらに、複数の筐体のそれぞれが異なる主体によって運営されていてもよく、一の主体によって運営されていてもよい。本件発明のシステムの運用主体は、単数であるか複数であるかは問わない。また、本システムの他に第三者の利用する端末、さらに他の第三者の利用する端末を含むシステムとしても発明を構成することができる。また、これらの端末は国境を越えて設置されていてもよい。さらに、本システムや前記端末の他に第三者の関連情報や、関連人物の登録のために利用される装置、登録の内容を記録するためのデータベースに利用される装置などが用意されてもよい。これらは、本システムに備えてもよいし、本システム外に備えてこれらの情報を利用可能に、本システムを構成してもよい。
【0038】
この図にあるように、計算機は、マザーボード上に構成される、チップセット、CPU、不揮発性メモリ、メインメモリ、各種バス、BIOS、USBやHDMI(登録商標)やLANなどの各種インタフェース、リアルタイムクロック等からなる。これらはオペレーティングシステムやデバイスドライバ(USB、HDMI(登録商標)などの各種インタフェース、カメラ、マイク、スピーカー又はヘッドホン、ディスプレイなどの各種機器組込み用)、各種プログラムなどと協働して動作する。本発明を構成する各種プログラムや各種データはこれらのハードウェア資源を効率的に利用して各種の処理を実行するように構成されている。
【0039】
≪チップセット≫
「チップセット」は、計算機のマザーボードに実装され、CPUの外部バスと、メモリや周辺機器を接続する標準バスとの連絡機能、つまりブリッジ機能を集積した大規模集積回路(LSI)のセットである。2チップセット構成を採用する場合と、1チップセット構成を採用する場合とがある。CPUやメインメモリに近い側をノースブリッジ、遠い側で比較的低速な外部I/Oとのインタフェースの側にサウスブリッジが設けられる。
【0040】
(ノースブリッジ)
ノースブリッジには、CPUインタフェース、メモリコントローラ、グラフィックインタフェースが含まれる。従来のノースブリッジの機能のほとんどをCPUに担わせてもよい。ノースブリッジは、メインメモリのメモリスロットとはメモリバスを介して接続し、グラフィックカードのグラフィックカードスロットとは、ハイスピードグラフィックバス(AGP、PCI Express)で接続される。
【0041】
(サウスブリッジ)
サウスブリッジには、PCIインタフェース(PCIスロット)とはPCIバスを介して接続し、ATA(SATA)インタフェース、USBインタフェース、EthernetインタフェースなどとのI/O機能やサウンド機能を担う。高速な動作が必要でない、あるいは不可能であるようなPS/2ポート、フロッピーディスクドライブ、シリアルポート、パラレルポート、ISAバスをサポートする回路を組み込むことは、チップセット自体の高速化の足かせとなるためサウスブリッジのチップから分離させ、スーパーI/Oチップと呼ばれる別のLSIに担当させることとしてもよい。CPU(MPU)と、周辺機器や各種制御部を繋ぐためにバスが用いられる。バスはチップセットによって連結される。メインメモリとの接続に利用されるメモリバスは、高速化を図るために、これに代えてチャネル構造を採用してもよい。バスとしてはシリアルバスかパラレルバスを採用できる。パラレルバスは、シリアルバスが1ビットずつデータを転送するのに対して、元データそのものや元データから切り出した複数ビットをひとかたまりにして、同時に複数本の通信路で伝送する。クロック信号の専用線がデータ線と平行して設け、受信側でのデータ復調の同期を行う。CPU(チップセット)と外部デバイスをつなぐバスとしても用いられ、GPIB、IDE/(パラレル)ATA、SCSI、PCIなどがある。高速化に限界があるため、PCIの改良版PCI ExpressやパラレルATAの改良版シリアルATAでは、データラインはシリアルバスでもよい。
【0042】
≪CPU≫
CPUはメインメモリ上にあるプログラムと呼ばれる命令列を順に読み込んで解釈・実行することで信号からなる情報を同じくメインメモリ上に出力する。CPUは計算機内での演算を行なう中心として機能する。なお、CPUは演算の中心となるCPUコア部分と、その周辺部分とから構成され、CPU内部にレジスタ、キャッシュメモリや、キャッシュメモリとCPUコアとを接続する内部バス、DMAコントローラ、タイマー、ノースブリッジとの接続バスとのインタフェースなどが含まれる。なお、CPUコアは一つのCPU(チップ)に複数備えられていてもよい。また、CPUに加えて、グラフィックインタフェース(GPU)若しくはFPUによって、処理を行っても良い。なお、実施形態での説明は2コアタイプのものであるが、これに限定されない。またCPU内にプログラムを内蔵することもできる。
【0043】
≪不揮発性メモリ≫
(HDD)
ハードディスクドライブの基本構造は、磁気ディスク、磁気ヘッド、および磁気ヘッドを搭載するアームから構成される。外部インタフェースは、SATA(過去ではATA)を採用することができる。高機能なコントローラ、例えばSCSIを用いて、ハードディスクドライブ間の通信をサポートする。例えば、ファイルを別のハードディスクドライブにコピーする時、コントローラがセクタを読み取って別のハードディスクドライブに転送して書き込むといったことができる。この時ホストCPUのメモリにはアクセスしない。したがってCPUの負荷を増やさないで済む。
【0044】
≪メインメモリ≫
CPUが直接アクセスしてメインメモリ上の各種プログラムを実行する。メインメモリは揮発性のメモリでDRAMが用いられる。メインメモリ上のプログラムはプログラムの起動命令を受けて不揮発性メモリからメインメモリ上に展開される。その後もプログラム内で各種実行命令や、実行手順に従ってCPUがプログラムを実行する。
【0045】
≪オペレーティングシステム(OS)≫
オペレーティングシステムは計算機上の資源をアプリケーションに利用させるための管理をしたり、各種デバイスドライバを管理したり、ハードウェアである計算機自身を管理するために用いられる。小型の計算機ではオペレーティングシステムとしてファームウェアを用いることもある。
【0046】
≪BIOS≫
BIOSは、計算機のハードウェアを立ち上げてオペレーティングシステムを稼働させるための手順をCPUに実行させるもので、最も典型的には計算機の起動命令を受けるとCPUが最初に読取りに行くハードウェアである。ここには、ディスク(不揮発性メモリ)に格納されているオペレーティングシステムのアドレスが記載されており、CPUに展開されたBIOSによってオペレーティングシステムが順次メインメモリに展開されて稼働状態となる。なお、BIOSは、バスに接続されている各種デバイスの有無をチェックするチェック機能をも有している。チェックの結果はメインメモリ上に保存され、適宜オペレーティングシステムによって利用可能な状態となる。なお、外部装置などをチェックするようにBIOSを構成してもよい。以上については、すべての実施形態でも同様である。
【0047】
図に示すように、本発明は基本的に汎用計算機プログラム、各種デバイスで構成することが可能である。計算機の動作は基本的に不揮発性メモリに記録されているプログラムを主メモリにロードして、主メモリとCPUと各種デバイスとで処理を実行していく形態をとる。デバイスとの通信はバス線と繋がったインタフェースを介して行われる。インタフェースには、ディスプレイインタフェース、キーボード、通信バッファ等が考えられる。以下、本発明の実施の形態を図示例と共に説明する。
【0048】
≪本明細書に関連する主な用語≫
<ライフイベント>
一生涯のうちで、年齢等に紐づいてある程度予測される大きなイベントを、ライフイベントと呼ぶ。
代表的なものとしては、入学、卒業、就職、結婚、子育て、教育、住宅購入、車の購入、旅行、退職、死などがあり、大きな出費を伴う場合もある。
<ライフプラン>
一生涯の中で想定されるライフイベントを考え、お金が必要になるタイミングやその金額を把握し、計画を立てることをいう。
実施形態のなかでは、ライフプランを行うことをライフプランニングと言ったり、シミュレーションすることをライフプランシミュレーションと言ったりする。
<金融用語:金融商品>
金融商品とは、預金、保険、株式、為替、債券、投資信託またそこから発生したデリバティブなど、銀行や証券会社、保険会社が取り扱う商品のことである。
デリバティブとは、「派生したもの」という意味で、先物やオプション、スワップの総称として用いられる。
先物とは、将来の定められた日に、商品を現時点で決めた価格と量で受け渡すことを約束する取引である。
オプションとは、対象の商品を一定期間内に、予め決められた価格で売買する権利で、この権利を取引することをオプション取引という。
スワップとは、金利や通貨などを、複数の当事者が合意して行う交換取引のことである。
【0049】
<金融用語:ポートフォリオ>
資産運用におけるポートフォリオとは、金融商品の組み合わせやその保有比率(または購入比率)のことで、リスクとリターンを判断する目的で利用される。目的と資産に合わせた組成が可能であり、長期の運用では特に、適切にリスクが分散されたポートフォリオを構成することが重要となる。
本発明のライフイベント型金融商品情報出力装置は、ライフイベントに備えた資金を適切に運用するために、以上説明したポートフォリオを最適に設計するものである。
【0050】
<金融用語:投資信託>
投資信託は、多数の投資家から販売会社を通じて拠出された資金(信託財産)を、運用会社のファンドマネージャーと呼ばれる資産運用の専門家が、株式や債券、為替、デリバティブなどの金融資産、あるいは不動産などに投資するよう運用を指図し、運用成果を投資家に還元する金融商品である。運用による利益・損失は投資家に帰属する。元本保証はなく、銀行などの普通預金や定期預金よりも良い利回りが期待されるが、これに相当するリスクがある。近年の低金利により、預金での利息収入がほぼ見込めない現状では、資産運用のための一手段として注目されている。どの程度のリスクで、どの程度のリターンが得られるかは、投資信託の投資対象により様々である。たとえば、株式は債券よりもリスクが大きく、リターンも大きいとされる。また、国内を投資対象としているものよりも、海外を投資対象としているもののほうが為替レートの影響も受けるためリスクやリターンが大きいとされる。いつでも購入・解約できる追加型投資信託などでは、保有する資産の評価額の変動に対応して、基準価額が計算されている。運用の利益は、一定期間ごとに払出される分配金の他、基準価額の値上がり益があれば、解約・売却時に受取ることができる。
本発明のライフイベント型金融商品情報出力装置が出力する情報は、金融商品全般が対象となるが、主に、投資信託が対象となる。
【0051】
投資信託の種類について説明する。
投資信託には大きく分けて2つの区分がある。一つは公社債投資信託で、国債や社債などの債券を中心に運用する。もう一つは、株式投資信託で、株式を組み入れて運用することができる。
また、運用対象商品、購入時期、分配方法により、下記のような種類がある。
【0052】
<投資信託詳細:MRF(マネーリザーブ・ファンド)>
証券総合口座で、投資資金を待機させておくための追加型公社債投資信託である。
元本は保証されないが、流動性と安全性を確保するため、運用対象を格付け・残存期間などで厳しく定めており、高格付けの債券のほか、コマーシャル・ペーパー、譲渡性預金証書などの短期金融商品で運用される。収益分配金を毎日計算し、月末に分配金に対する税金を差し引いて一括して再投資する。いつでも手数料なしで、1円単位で入出金出来る。
【0053】
<投資信託詳細:公社債投信>
安全性の高い債券を中心に運用する追加型の公社債投資信託である。金利上昇時には債券の価格が下がり、元本割れする可能性もある。分配は、例えば、年に1度行われるものや毎月行われるものもあるが、この収益分配金をその都度受け取らずに自動的に再投資することも出来る。
【0054】
<投資信託詳細:外貨建てMMF(マネー・マーケット・ファンド)>
運用対象は高格付けの債券や海外短期証券が中心なので、外貨ベースでは、安全性が重視されている。収益分配金は運用実績に応じて毎日分配する。月末に分配金に対する税金を差し引いて一括して再投資するため、複利効果が期待できる。満期や途中換金の制約条件がないため、いつでも手軽に購入・換金することができ、流動性に優れた商品である。
【0055】
<投資信託詳細:オープン型株式投資信託>
いつでも時価で売買できる追加型の株式投資信託である。株式市場や金利、為替などの動きをとらえたタイムリーな資金運用ができる。積極的に値上がり益を狙うものや、安定性を重視するものなど様々な商品がある。
【0056】
<投資信託詳細:スポット型株式投資信託>
その時々の経済・金融情勢を考慮し、今後の成長が期待できる会社などを中心にタイムリーな運用で収益を狙う単位型の株式投資信託である。1回限りの募集で設定されるので、一般的に「スポット投信」と呼ばれる。
【0057】
また、投資信託はその資金の運用方法により以下2つに分けられる。
<投資信託詳細:アクティブ運用>
アクティブ運用は、アナリストやファンドマネージャーが個別企業の情報を収集して、投資銘柄を選定し、運用を行う。信託報酬などの費用がパッシブ運用のファンドと比べ高く設定されている一方、ベンチマークを上回るリターンが期待できるという特徴がある。
【0058】
<投資信託詳細:パッシブ運用>
パッシブ運用は原則、ベンチマークに連動する成果を目指す運用方法である。ベンチマークはインデックス(指数)とも呼ばれ、日経平均株価などのように株式や債券などの市場全体の値動きを表す指標のことをいう。アクティブ運用と異なり、調査を通じた銘柄選定などは行わないため、アクティブ運用と比べて信託報酬などの費用が低く設定されている特徴がある。
【0059】
<投資信託詳細:コスト>
投資信託を購入する顧客に発生するコストについて簡単に説明する。顧客に発生するコストは大きく分けて二種類ある。一つは、投資信託を選択して積立を行う都度発生するコストである購入時手数料である。この手数料は販売会社に支払う。もう一つは、運用期間中に信託財産から間接的に差し引かれる「運用管理費用(信託報酬)」である。これは運用管理にかかる費用などをまかなうもので、運用会社・販売会社・信託銀行(ファンドの運用方針によっては信託財産の一部を現金で保持する場合がある。)の3者で配分される。さらに信託財産からは、「監査報酬」「売買委託手数料」などの費用が差し引かれる。また、換金時に「信託財産留保額」(換金手数料を、投資信託を運用している人だけで負担するのは不公平という考え方もある。そこで換金する人(顧客)に費用(=信託財産留保額)を支払ってもらおうという制度を、信託財産留保金制度という。この留保額は基準価額に反映される。)がかかるファンドもある。
このようなコスト構造を考慮すると、各イベントごとに投資信託を選択するという考え方は非効率である場合がある。一方で投資信託等の金融商品は時代の変遷や投資環境の変化などによってその運用効率が増減する場合があり、継続的に少数の投資信託等の金融商品を持ち続けるよりは、投資環境等の変化に応じて適宜金融商品を選択し直すという考え方もある。
そこで選択されたイベントで発生が予想される費用を賄いながら比較的少数の投資信託を継続しながら全体のイベントに対応するように投資信託を選択するルールと、投資環境の変化に応じて金融商品を選択し直すというルールの両者が利用できるシステムであることが好ましい。後者のルールの場合にはイベントの発生時期を金融商品の選択の見直し時期として確定しておくようにルールを構成することができる。また、そのイベント発生時期に予め所定の金融商品を選択するようにスケジュールを立てておくことも可能である。
【0060】
<金融用語:標準偏差>
標準偏差とは、一般的には統計学における散布度(ばらつき)を計測する手法のことを指す。標準偏差は金融商品のリスクを数値化する際にも使われる。例えば、投資信託の場合では、ある一定の年数を設定し、まず騰落率の平均値を求め、年ごとにリターンから平均値との差(偏差)を求める。それから偏差を2乗して一定期間の年ごとの偏差を合計し、それを年数で割って平方根を出す。これが、リターンとのブレを示す標準偏差となり、その数値が大きい程リスクが大きく、小さければリスクも小さいということになる。
資産運用の場面では、リスク(標準偏差)とは、リターンの分布の広がりがどの程度の大きさかを表す指標であり、例えば、1年間のリターンがどれくらいブレそうかということを示そうとするものである。株式など有価証券のリターンの分布は、統計学で用いられる正規分布の形状に似ている。一般的に、正規分布は左右対称の釣り鐘型の形をしている。各資産のリターンが正規分布に従うならば、リターンは約68.3%(約3分の2)の確率で中心から±1σ(標準偏差)に収まり、95%の確率で±2σ(標準偏差)に収まることが想定される。
図76は、日本株における期待利回りと標準偏差の関係を表す一例を示す図である。
ここでは、期待利回りが5%、標準偏差が15%であるという前提で説明する。リスクは通常1σ(標準偏差)で表される。本件発明においても1σ(標準偏差)を用いる。図に示すように、期待利回りが5%、標準偏差が15%であれば、1年間のリターンは期待利回り5%を中心にして、上下15%の間で変動する確率が約68.3%(約3分の2)であることを意味する。言い換えれば、1年間のリターンが+5%から+20%の範囲に収まる確率が約3分の1、+5%から-10%の範囲に収まる確率が約3分の1であると想定している。逆にいうと、毎年のリターンが-10%より大きく下がる確率は約16%、+20%より大きく上がる確率も約16%となる。
【0061】
<本発明の自然法則の利用性の充足>
本発明は、コンピュータと通信設備とソフトウェアとの協働で機能するものである。従来、ライフイベントを目的として資産運用するには、運用者自身がライフイベントの目標金額、期間、未達許容度など様々な要素を考慮する必要があった。これを、ICTを介して支援するなど、ICTならではの処理が含まれているのでいわゆるビジネスモデル特許として成立するものである。本願発明はコンピュータなどのリソースを請求項や明細書に記載された事項と、それらの事項に関係する技術常識に基づいて判断すれば、本願発明は自然法則を利用したものであることとなる。
【0062】
<特許法で求められる自然法則の利用の意義>
特許法で求められる自然法則の利用とは、法目的に基づいて、発明が産業上利用性を有し、産業の発達に寄与するものでなければならないとの観点から、産業上有用に利用することができる発明であることを担保するために求められるものである。つまり、産業上有用であること、すなわち出願に際して宣言した発明の効果がその発明の実施によってある一定の確実性の下再現できることを求めるものである。この観点から自然法則利用性とは、発明の効果を発揮するための発明の構成である発明特定事項(発明構成要件)のそれぞれが発揮する機能が自然法則を利用して発揮されるものであればよい、と解釈される。さらに言えば、発明の効果とはその発明を利用する顧客に所定の有用性を提供できる可能性があればよいのであって、その有用性を顧客がどのように感じたり、考えたりするかという観点で見るべきではない。したがって、顧客が本システムによって得る効果が心理的な効果であったとしても、その効果自体は求められる自然法則の利用性の対象外の事象である。
【発明を実施するための形態】
【0063】
本発明の実施形態の説明に先立ち、図1を用いて、本発明のビジネスモデルの概要を説明する。
図1において、ライフイベント型金融商品情報出力装置は、Webサーバとして顧客にサービスを提供しており、顧客は、このWebサーバのWebページにインターネット経由でアクセスし、ユーザインタフェースをWebページが行う形態を想定している。
ただし、本ビジネスは様々な形態が考えられ、例えばユーザインタフェース部分をスマートフォン上のアプリで構成され、その他の機能をサーバ側に搭載するような構成であってもよいし、すべてスマートフォン上のアプリに構成することも可能である。
【0064】
<全体像:ビジネスモデルの説明>
本発明のライフイベント型金融商品情報出力装置は、顧客の年齢や職業、家族構成など、を考慮しながら、顧客のライフプランに応じて見込まれるライフイベントを抽出して、投資信託ポートフォリオをカスタマイズし、ライフイベントの出費に備えるための資産形成を支援するための装置およびシステムである。
具体的には顧客の情報から、今後発生する可能性のあるライフイベントをすべて抽出し、顧客に該当するライフイベントを選択させる。そして、それに備える資金を運用する場合に最適な投資信託を組み合わせたポートフォリオを出力するものである。
ポートフォリオの設計にあたっては、顧客の所得収入や生活支出を考慮したり、公的支援金や税制を考慮したりしても良い。
【0065】
図1は、本ライフイベント型金融商品情報出力装置の代表的な実施例であるライフプランニングサーバと顧客のやり取りの概要を説明した図である。
(1)まず、顧客は、本発明のライフイベント型金融商品情報出力装置に、氏名、性別、生年月日、連絡先(電話番号、e-mailアドレスなど)のうちいずれか一以上の情報を用いて顧客登録する。登録後、ログインIDが付与され、ログインIDを用いてログインして、顧客自身に関わる情報である顧客属性情報を入力する。顧客属性情報は、家族構成ならびに家族の生年月日、年収、支出、現在の手持ち資産、会社員である場合にはその企業名、その企業における役職、自営業の場合には自営業の種類、年間売上高、有資格者である場合には資格名、居住住宅に関する情報(賃貸か、賃貸の場合には賃料はいくらか? 賃貸の更新手数料は必要か、必要な場合にいくらか?持ち家か、持ち家の場合にローンはあるか、ローンがある場合にはどのような支払条件になっているか、など)、マイナンバー、投資性向などのいずれか一以上の情報である。
【0066】
(2) その後、ライフイベント型金融商品情報出力装置は、顧客属性情報から見込まれる顧客自身の見込ライフイベントを表示する。見込ライフイベントとは、進学、就職、退職、結婚、出産、子供の進学、住宅購入、病気、介護など、一般的にライフイベントとして考えられているイベントに対して、顧客の生年月日や家族構成および家族の生年月日からイベントの発生が推定される時期を年齢に割り当てたものである。進学や、就職、退職などは、発生年度が特定可能なイベントであるが、結婚、出産、住宅購入などは、発生年度が特定できないイベントである。この場合は、例えば、顧客が予定している年齢を入力するようにしても良いし、結婚や出産など国勢調査の調査結果があるイベントについては国勢調査の統計情報でその年齢を採用するように構成することができる。なお、統計情報は国勢調査に限定されることなく、各種の統計情報を利用可能である。例えば結婚の場合、国勢調査の調査結果で判明する平均結婚年齢で表示するなどが考えられる。その他の年齢が限定されないイベントは、平均的な年齢で発生するものとして見込ライフイベントの候補として表示するようにしても良い。
【0067】
(3) 見込みライフイベントの候補が表示されたら、顧客は、見込みライフイベントの候補から自分の見込ライフイベントとして選択できるものを決定してシステムに対して編集入力する。これは、ライフイベントのあり/なしや発生時期は人それぞれだからである。
したがって、顧客は予定しないライフイベントがある場合は削除し、予定時期が異なる場合は、自分が予定している年齢にイベント発生予定時期を変更する。
【0068】
(4) 編集されたライフイベントである見込ライフイベントに基づいて、どのような金融商品に投資するかをポートフォリオとして提案する。これは、ライフイベントの属性に応じて必要な資金が不足することが無いように安全性は確保しつつ、資産形成のために運用利回りも見込めるように、金融商品を組み合わせたポートフォリオを提案する。
【0069】
(5) 顧客は、提案された金融商品のポートフォリオを確認する。
提案内容に顧客が納得し、購入する場合は、購入申込を受け付けるように構成しても良い。
購入申込を受け付けるように構成された場合、例えば、ライフイベント型金融商品情報出力装置が購入申し込みを受け付けるようにしても良い。その場合、は以下の流れで購入申し込みを処理する。
(6)購入を行うための資金の引落を、顧客の指定の銀行口座から行う。
(7)運用会社に金融商品の購入申込を行う。
購入申込は、積立購入の場合もあれば、スポット購入の場合もある。スポット購入の場合は、(6)と(7)の処理が1回行われるが、積立購入の場合は、(6)と(7)の処理を積立周期ごとに(例えば毎月)繰り返し行う。
【0070】
以上のように、ライフイベントに備えて、金融商品の購入により資産運用を行い、ライフイベントが到来したら、運用資金を取り崩して、ライフイベントの支出に充てるようにする。
また、次のライフイベントに備えて、積立額や金融商品の再提案を行うようにしても良い。
このように、ライフイベントに対して備えるためには、どのような金融商品の組み合わせを購入すればよいかが自動で提案されるので、顧客は、特に意識することなく、ライフイベントに備えた資金を運用して資産形成が行える。
【0071】
<実施形態1(主に請求項1に対応)>
<実施形態1(主に請求項1に対応):概要>
本実施形態に関わるライフイベント型金融商品情報出力装置は、主に請求項1に対応する、顧客の属性情報と今後見込まれるライフイベントに基づき、将来発生する支出をまかなうために適切な金融商品の組合せを提案する装置である。これによって適切な資産運用計画を立てることが期待できる。
サービス提供の形態としては、インターネットを介したWebサーバとして構成する場合や、スマートフォン上のアプリとして構成する場合や、アプリとWebサーバで機能を分担する形態と様々な提供方法が考えられる。
【0072】
<実施形態1(主に請求項1に対応):構成>
図2は、実施形態1のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図であり、顧客属性情報取得部0201と、顧客識別情報保持部0202と、顧客属性情報保持部0203と、ライフイベント識別情報保持部0204と、見込ライフイベント識別情報選択受付部0205と、将来情報保持部0206と、金融商品識別情報保持部0207と、金融商品識別情報選択ルール保持部0208と、金融商品識別情報選択部0209と、金融商品識別情報出力部0210と、を有している。
【0073】
<実施形態1(主に請求項1に対応):構成の説明 顧客属性情報取得部>
「顧客属性情報取得部」0201は、顧客の氏名、年齢、生後経過時間(生年月日の情報にて代替される場合がある。)、性別、職業、職位、住宅の有無、結婚の有無、被扶養者の有無、所有している金融商品(その金融商品の属性情報と関連付けられている。)、現在の年収、現在の家計支出、投資性向、などのいずれか一以上を含む顧客属性情報を取得する。
「顧客属性情報」とは、顧客の属性を示す情報である。一般的には人に共通して備わっているとされる性質や特徴のことである。これは、最終的に顧客に適した金融商品を装置が選択する際に利用可能な情報であり上記に列記した情報以外の情報であってもよい。
顧客属性情報は、見込ライフイベント識別情報を顧客に選択可能にライフイベント識別情報保持部から取得して提示する際に利用され、また、金融商品識別情報を装置が選択する際の選択のためのルールである金融商品識別情報選択ルールが選択のために利用する場合がある。
顧客属性情報取得部は、顧客の属性情報を入力する入力ウインドウなどのユーザインタフェースとして、構成しても良い。例えばWebページや、スマートフォンアプリの画面として顧客が自身の、生年月日、性別、職業、住宅の有無、配偶者の有無、被扶養者の有無、子供の有無、収入、支出などの情報を画面の指示に従って入力するような構成が考えられる。
配偶者や子供、被扶養者に関しては、生年月日、性別、収入の有無などの情報も入力し、さらに子供に関しては、進学の予定等も入力するようにする。
これは、上記配偶者や子供は、顧客のライフイベントに大きく係り、ライフイベントの抽出に必要となるためである。
【0074】
この他、顧客属性情報の取得には、マイナンバーカードや免許証などの画像から取得可能な情報は取得するようにして、勤務先や収入、家族に関わる情報など、取得できない情報に関しては入力を促すようにしても良い。具体的には、スマートフォンのカメラで免許証やマイナンバーカードを撮影すると、撮影画像から、年齢、生年月日、住所など取得可能な情報を取得するようにすれば良い。
以降、顧客属性情報取得部の一例である入力画面について、図3及び図5Aから図5Dを使用して説明する。
【0075】
<実施形態1(主に請求項1に対応):顧客属性情報取得部 顧客情報登録画面の一例>
顧客属性情報取得部は、その入力インタフェースの一部として顧客情報登録画面を有するように構成しても良い。
図3は、顧客属性情報を取得するインタフェースである顧客属性情報取得部の一例としての顧客情報登録画面0300である。
氏名入力欄0301と、生年月日入力欄0302と、住所欄0303と、電話番号欄0304と、e-mail欄0305と、パスワード入力欄0306と、で構成されている。図中の各欄に必要事項を入力し、登録ボタン0308を押すことで、入力内容が確定し、顧客属性情報が登録されるとともに、本装置内で顧客を一意に識別可能となり、これに応じてユニークなログインIDが付与される。付与されたログインIDは、e-mailで顧客に送信されるように構成しても良い。
【0076】
<実施形態1(主に請求項1に対応):顧客属性情報取得部 家族構成入力画面の一例>
顧客属性情報取得部は、その入力インタフェースの一部として家族構成入力画面を有するように構成してもよい。これによって、結婚の有無や、被扶養者の有無や被扶養者がある場合のその者の年齢、自身や被扶養者を含めた性別などの顧客属性情報が装置に取得される。
図5Aは家族構成入力画面0500で、顧客属性情報取得部の家族構成の入力画面の一例である。
入力情報選択スイッチ0501で家族構成を選択すると、家族構成入力画面の表示となる。ここでは、例えば、生計を同一にする家族を入力するようにする。生計を同一とする家族ではその資産(運用する金融商品等の情報を含む)が共通の注目事項となるからである。家族構成0502は、顧客自身の家族を設定する入力部である。図の様に、配偶者と子供二人が表示されている状態を初期画面としても良い。顧客は自身の家族構成と合わせるために、いない人物に関しては、例えば、削除スイッチ0504で消すことができるようにしてもよい。子供が二人よりも多い場合は、追加スイッチ0505を押すことで一人ずつ追加することができる。家族構成を入力したら、家族の詳細情報の入力を行う。家族詳細情報0503は、対象の人物のアイコンをクリックすると表示され、生年月日、性別、同居/別居の入力を行う。ここで、扶養の有無を入力するようにしても良いし、扶養していない家族は、削除するようにしても良い。
以上は、家族構成の一例であり、上記の構成に限定するものではない。表にプルダウンメニューで入力するようにしても良いし、初期画面は本人のみで、関係者を追加で入力するようにしても良い。主な対象が子持ちの妻帯者であれば、最初に説明した構成の入力が良く、独身者が主な対象になる場合は、本人以外は、追加入力したほうが、手間がなく良いと思われる。また、その両方の構成を有して、顧客が選択できるようにしても良い。
なお、子が就職年齢に達して、生計を分けることが見込まれる場合は、その子を家族構成から自動的に除外するように構成しても良いし、顧客に該当する子を家族構成から除外するか否かの確認を行わせるための処理機能を本装置に設けるように構成してもよい。例えば子供の就職時期が到来したらプッシュ通知で扶養を外すか外さないかの二択で顧客に選択させるための通知を行うような機能を本装置に設けることが考えられる。
【0077】
<実施形態1(主に請求項1に対応):顧客属性情報取得部 収入入力画面の一例>
顧客属性情報取得部は、その入力インタフェースの一部として収入入力画面を有するように構成してもよい。収入入力画面は、顧客の顧客属性情報である現在の年収を装置に取得させるためのものである。
図5Bは、収入入力画面0510で、顧客属性情報取得部の収入入力画面の一例である。
入力情報選択スイッチ0511で収入が選択されると、収入入力画面0510が表示される。
給与所得入力0512には、本人の手取り収入および家族の手取り収入を例えば年収で入力する。
この他に、子供にアルバイト収入がある場合や、同居の親が居て年金収入がある場合は、ここで入力するようにしてもよい。このように本人以外の年収も入力させるのは家計を一にしている家族構成を最初に入力させた場合には特に有効である。これらの収入に基づいて複数の人が協働で生計を立てるからである。年収の入力方法はこれに限らず、月額でも構わないが、ボーナスなど毎月の収入以外の収入もあるため、サラリーマンは、年収のほうが扱い易いと思われる。従って、先に入力があれば職業などの顧客属性情報に基づいて、入力方法を変更するようにしても良い。
【0078】
次に、退職予定の年齢と、退職金の見込を一時所得入力欄0513に記入する。また、個人年金等の取得や、確定拠出年金の積立金等があれば、ここで入力するようにしておけばよい。公的年金入力欄0514には、公的年金の受給予定年齢および予定の年額を記入する。これは、例えば、毎年送られてくる「ねんきん定期便」に記載された内容を入力するようにしてもよい。その他、収入入力欄0515では、例えば、相続により財産を相続したり、持ち家を売却したりして住み替えなどを行い一時的に収入が見込まれる場合に記入する。この時、収入が見込まれる時期を、顧客の年齢で入力することが考えられる。以上の記入により、給与所得だけではなく、年金等も考慮した、生計全体での各年齢での収入の推移を見積もることができる。
【0079】
<実施形態1(主に請求項1に対応):顧客属性情報取得部 支出入力画面一例>
顧客属性情報取得部は、その入力インタフェースの一部として支出入力画面を有するように構成してもよい。現在の家計支出を顧客属性情報として装置が取得するためである。
図5Cは、支出入力画面0520で、顧客属性情報取得部の支出入力画面の一例である。
入力情報選択スイッチ0521で支出を選択すると、支出入力画面の表示になる。生活費入力欄0522に生活費の年額を入力する。生活費の入力は月額でも構わない。ここには、衣食住に関わる、毎月支出する金額を記入する。
一時支出予定入力欄0523は、支出額の大きい一時支出の予定がある場合は記入する。図の例のように、例えば、一時支出か毎年の支出かを選択し、その金額を入力するようにしても良い。例えば、毎年旅行に行く場合は、毎年の支出を選択し、金額欄に大まかな支出金額を入力するようにする。保険金額記入欄0524は、生命保険や、個人年金などの支出がある場合は記入する。ローン返済記入欄0525は、ローンの支払いがある場合は記入する。
【0080】
<実施形態1(主に請求項1に対応):顧客属性情報取得部 資産入力画面の一例>
顧客属性情報取得部は、その入力インタフェースの一部として資産入力画面を有するように構成してもよい。
図5Dは、ポートフォリオ入力画面0540の一例であり、所有資産を入力することで、資産割合などを図で分かり易く表示する画面である。
入力情報選択スイッチ0541で、金融資産を選択すると、現在保有している金融資産を入力する画面表示となる。預金がある場合は、預金入力欄0543に入力するが、複数の通貨を選択してそれぞれ保有額を入力できるようにしても良い。金融商品入力欄0544には、投資信託などの金融商品の選択と口数を入力するようにしても良い。株式入力欄0545には、株式を保有している場合には、銘柄と保有株数を入力しても良い。その他資産入力欄には、金や不動産などの資産を入力するようにしても良い。金やコモディディなどの日々の価格は取得可能なので、保有数量を入力するようにすれば良いが、不動産の場合は、評価額などを顧客が入力したり、不動産の評価情報を蓄積したデータベースからインターネット経由で評価額を計算するための情報を取得、その情報に基づいて計算するように構成したりすることもできる。投資信託や株の場合は、その日の価格と所有数から評価額に換算して比率を求めるようにしても良い。この計算についても株や投資信託の価格のデータベースから株価や投資信託の単位当たりの価格の情報を取得してその情報に基づいて株数や投資信託の口数を用いて資産額を計算するように構成することが考えられる。資産比率0542は、各入力した資産の比率を示す。図の例では、円グラフで表示しているが、表示方法は問わない。また資産総額0547などを表示するようにして現状の資産額評価額を把握しやすくしておくことが望ましい。
なお、本画面の入力は、入力時点の保有資産を入力することで説明したが、月々金融商品の積立購入を行っている場合は、購入した金融商品の情報が自動で更新されるようにしても良いし、インターネット口座等から資産情報を定期的に取得して更新するようにしても良い。
【0081】
<実施形態1(主に請求項1に対応):構成の説明 顧客識別情報保持部>
「顧客識別情報保持部」0202は、顧客を識別する顧客識別情報を保持する。
「顧客識別情報」とは、ライフイベント型金融商品情報出力装置において顧客を唯一に識別する情報であり、ライフイベント型金融商品情報出力装置が提供するサービスに接続する際のログインIDなどが該当する。また、顧客のメールアドレスをそのまま用いるなどしても良い。最初にサービスに登録する際に、名前、住所、電話番号、メールアドレスなど、顧客を特定するための情報を登録後に、その情報に関連付けて付与されるようにする方法が一般的である。その付与されたログインIDに、登録された情報を関連付けて保持する。
また、この顧客識別情報には、サービスにログインするためのパスワードも関連付けて保持しても良い。パスワードに関しては、顧客が任意に指定するようにしても良いし、ランダムに生成された文字列を初期パスワードとして割りつけても良い。
この顧客識別情報が、顧客識別情報保持部に保持されることで、顧客は、ログイン画面からログインできるようになる。
【0082】
<実施形態1(主に請求項1に対応):顧客識別情報に関連するログイン画面の一例>
顧客識別情報保持部に保持された顧客識別情報は、ライフイベント型金融商品情報出力装置にログインする際に参照される。
図4Aは、ライフイベント型金融商品出力装置にログインするためのログイン画面0400の一例である。ログイン画面0400には、ログインID入力欄0401と、パスワード入力欄0402と、LOGINボタン0403がある。
顧客は、ログインID入力欄と、パスワード入力欄にそれぞれ、付与されたログインIDと登録したパスワードを入力することで、ライフイベント型金融商品出力装置が提供するサービスにログインできる。
【0083】
<実施形態1(主に請求項1に対応):ログイン後の画面 メインメニュー画面の一例>
ログインすると、様々なサービスを開始するためのメインメニュー画面が表示される。
図4Bは、メインメニュー画面0410の一例を示す図である。
メインメニュー画面は、タイトルバー0411と、Newsスイッチ0412と、ライフイベント情報スイッチ0413と、家計簿スイッチ0414と、ライフプランシミュレーションスイッチ0415と、マイページスイッチ0416と、資産状況スイッチ0417とで構成されている。
各スイッチで起動するサービスは、適宜必要に応じて説明する。
【0084】
<実施形態1(主に請求項1に対応):構成の説明 顧客属性情報保持部>
「顧客属性情報保持部」0203は、顧客属性情報取得部で取得した顧客属性情報を顧客識別情報と関連付けて保持する。
これらの情報は、ライフイベント型金融商品情報出力装置内の不揮発性メモリにおいて保持される。顧客が、顧客識別情報を用いてログインすると、顧客識別情報をインデックスに用いて顧客属性情報を顧客属性情報保持部から読み出すようにして以降のサービス提供のために使用する。
また、これらの情報は、個人情報のため顧客自身のみアクセスが可能なようにアクセス制限をつけて保持されることが望ましい。
本ライフイベント型金融商品情報出力装置は、Webサーバ以外にスマートフォンなどのアプリとして提供する場合や、その両方の組み合わせで提供される場合もある。Webサーバとスマートフォンを組み合わせて提供する場合、顧客属性情報は顧客の端末側は保持しておき、サーバ側は顧客識別情報のみを保持しておくような構成であっても良い。こうすることで、Webサーバ側に顧客の情報が残らないので、情報漏洩等の心配が無い。
【0085】
<実施形態1(主に請求項1に対応):構成の説明 ライフイベント識別情報保持部>
「ライフイベント識別情報保持部」0204は、入社、本人の結婚、住宅購入、出産、子供の入学、子供の結婚などのまとまった出費が発生するイベントであるライフイベントを識別するライフイベント識別情報を保持している。また、ライフイベントは、一般的な人が想定するイベントの他にも、失業、転職、早期退職、病気による入院・手術、留学、介護、相続など、人により発生する場合があるイベントで、ライフプランに大きく影響するようなイベントも保持しておくことも可能である。
【0086】
ライフイベント識別情報に関連付けて、そのライフイベント識別情報で識別されるライフイベントの発生の将来時期、例えば、発生年齢を関連付けるように構成してもよい。発生年齢を一概に特定できないような場合には、そのライフイベント識別情報で識別されるライフイベント発生の発生頻度が高い年齢や平均年齢を関連付けるように構成することが考えられる。また、そのライフイベントの発生の将来時期、例えば、発生年齢の幅が大きい場合には年齢の幅を示す期間で示される将来発生時期と関連付けるように構成することもできる。これらの情報は厚生労働省の統計データ(例えば婚姻に関する統計)や、政府系の研究機関の統計データ、マスメディアのデータベースに蓄積されている統計データなどに基づいて得ることができる。
【0087】
<実施形態1(主に請求項1に対応):構成の説明 見込ライフイベント識別情報選択受付部>
「見込ライフイベント識別情報選択受付部」0205は、保持されている顧客属性情報に基づいて、顧客識別情報で識別される顧客に今後発生する見込みがあるライフイベントを識別するライフイベント識別情報である見込ライフイベント識別情報をライフイベント識別情報保持部から選択可能に取得し、顧客の見込ライフイベント発生時の将来時期(年齢であってもよい)と関連付けて選択させる。ここで「顧客属性情報に基づいて」とは、例えばすでに保持されている顧客属性情報がその顧客が既婚であり、すでに子供ももうけているような場合には、原則的に将来結婚というライフイベントが発生する可能性が少ないので、顧客に選択可能に提示される選択肢の中には、ライフイベントとしての結婚は表示されないようにする。また、例えば顧客属性で職業が自営業の場合には、定年退職というライフイベントは一般的には考えられないので選択可能なライフイベントして定年退職は表示されない。このように顧客属性情報に応じて将来発生可能性があるライフイベントが異なるので、顧客ごとに将来発生可能性があるライフイベントのみを表示するようにライフイベント識別情報保持部から絞り込まれたライフイベント識別情報を選択して表示し顧客による選択が容易に行えるように構成することが望ましい。なお、このような取捨選択を装置が行うために、顧客属性情報とライフイベント識別情報とが関連付けて保持されているか、顧客属性情報に応じてどのようなライフイベント識別情報を取捨選択して表示するかを計算するライフイベント識別情報取捨選択ルールが取捨選択ルール保持部に保持されており、このルールが利用されるように構成されていてもよい。
【0088】
見込ライフイベント識別情報選択受付部は、顧客が今後予定しているライフイベントの入力を促す画面等を表示して顧客が入力した情報を取得する。
見込ライフイベント識別情報選択受付部は、顧客に今後発生すると見込まれる見込みライフイベントの見込ライフイベント識別情報を取得して初期値として表示しても良い。顧客が表示された初期値に対して変更入力した情報を取得するように構成しても良い。
見込ライフイベント識別情報の変更入力とは、例えば、見込ライフイベントの発生年齢の変更、見込ライフイベントの支出予定額の変更、見込ライフイベントの追加、および削除などが考えられる。
【0089】
<実施形態1(主に請求項1に対応):見込ライフイベント識別情報選択受付部 進学予定入力画面の一例>
見込ライフイベント識別情報選択受付部は、その入力インタフェースの一部として進学予定入力画面を有するように構成してもよい。進学予定入力画面は、顧客の被扶養者(主に子)の教育に係る見込みライフイベントを選択入力するためである。
図5Eは、進学予定入力画面0530の一例である。この図にある様に第一子と第二子の入力画面が準備されている。これは図5Aで入力した生計を一にする家族の入力の際に既婚で、第一子と第二子がいることが入力されたことに基づいている。
入力情報選択スイッチ0531で、教育費を選択すると進学予定入力画面が表示される。
子供の選択0532で、第一子、第二子のいずれについて入力するか選択する。進学予定入力0533で、幼稚園、小学校、中学校、高校、大学、大学院の各学校で、公立か私立かを選択する。これは、一般的に、私立に進学する場合、入学金や授業料が高額であるとともに、教材費、施設利用料など学費以外にも大きな支出がでる可能性が高いからである。詳細スイッチ0534は、学費以外にかかる費用の詳細を入力するためのスイッチであり、詳細スイッチを押すと、詳細記入欄0535が表示される。ここで、寮・下宿費用や、海外留学などを予定しているか、また、その金額を記入するように構成しても良い。
【0090】
<実施形態1(主に請求項1に対応):見込ライフイベント識別情報選択受付部 見込ライフイベント入力画面の一例>
見込ライフイベント識別情報選択受付部は、その入力インタフェースの一部として見込ライフイベント入力画面を有するように構成してもよい。
図6は、見込ライフイベント入力画面0600であり、ライフイベント型金融商品出力装置が自動で抽出した見込ライフイベントを顧客が編集できるようになっている。
年齢表示部0601で、見込ライフイベントを生成した時点の顧客本人の年齢を現在の年齢として表示している。ちなみに入力を行った日、即ち入力現在日は、2023年4月1日(顧客本人の誕生日)である。見込ライフイベント識別情報表示欄0602には、見込ライフイベント識別情報選択受付部で入力された見込ライフイベントが顧客本人の年齢順に表示されている。削除スイッチ0603は、対応する見込ライフイベントに対して、顧客が予定していない場合は、このボタンを押すことで、見込ライフイベントから削除できる。目標金額欄0604は、見込ライフイベントで使用する予定金額で、初期状態は、一般的な平均金額が示されていても良い。例えば大学の入学時期に子供のために発生するであろう費用に関して一般的な情報を知りたい場合には、見込ライフイベント名がハイパーリンクなどの情報を閲覧するボタンになっており、政府の統計情報や、研究機関の統計情報、その他インターネット上の情報源が視聴できるように構成されていることが好ましい。このようにライフイベント関連情報を視聴・閲覧することができるようにライフイベント識別情報自体がリンク機能やボタン機能を有していることが好ましい。なお、視聴の内、特に目が不自由な顧客に対しては音声での説明がされるように構成されることが好ましい。自動音声読み上げ機能が備わっていてもよい。これは見込ライフイベント識別情報選択受付部の選択インタフェースのみならず、本件装置に関係するインタフェースであってライフイベント識別情報や、見込ライフイベント識別情報が表示される場面の全てで同様の機能が実現することが望ましい。顧客は、この金額に対して、変更を行うことができる。予定年齢欄0605は、ライフイベントが発生する見込みの顧客本人の年齢であり、発生年齢が確定しないものに関しては、顧客属性情報などから導かれ、統計情報などを利用して取得される平均年齢を初期値として入れておくようにしても良い。顧客は、見込ライフイベントの発生年齢に対して予定年齢欄を書き換えることができる。追加ボタン0606は、見込ライフイベントとして挙げられていないが、顧客が予定しているライフイベントがある場合は、ここで追加ボタンを押すと後述する図8の様な画面が表示され、追加するイベントの詳細を入力するようにしても良い。見込ライフイベント追加画面に関しては後で説明する。OKボタン0608を押すと、見込ライフイベントの編集内容が確定し内容を確認するための見込ライフイベント一覧画面を表示する。なお、見込ライフイベントの編集は、一画面で行う例を説明してきたが、これに限るものではない。例えば、各ライフイベントに対応して編集ボタンを設け、編集ボタンが押されたら、対応するライフイベントを編集する見込ライフイベント編集画面を表示するようにしても良い。
【0091】
<実施形態1(主に請求項1に対応):見込ライフイベント識別情報選択受付部 見込ライフイベント一覧画面の一例>
見込ライフイベント識別情報選択受付部は、その入力インタフェースの一部として見込ライフイベント一覧画面を有するように構成してもよい。
図7は、見込ライフイベント一覧画面0700の一例である。見込ライフイベントを編集して確定した後に、見込ライフイベントの一覧を表示し内容を確認するための画面である。
年齢表示部0701で、見込ライフイベントを生成した時点の年齢を現在の年齢として表示している。ライフイベント表示0702に、見込ライフイベント識別情報選択受付部で取得した、ライフイベントと、イベントが発生する年齢、必要金額などが表示されている。表示された内容に問題が無ければ、確定ボタン0703を押すことで、確定した見込ライフイベント識別情報を少なくとも含む将来情報(見込ライフイベントの発生時の将来時期と関連付けられているもの)を顧客識別情報と関連付けて将来情報保持部に保持されるように処理が進む。また、確定した見込ライフイベント識別情報の一覧に基づいた、ライフプランのシミュレーションが行えるように構成することもできる。ここでのシミュレーション結果は、図42に示すような内容となるが、詳細は後述する。
【0092】
<実施形態1(主に請求項1に対応):見込ライフイベント識別情報選択受付部 見込ライフイベント追加画面の一例>
見込ライフイベント識別情報選択受付部は、その入力インタフェースの一部として見込ライフイベント追加画面を有するように構成してもよい。
図8は、見込ライフイベント追加画面0800の一例である。
見込ライフイベント一覧画面は、初期状態では、例えば属性情報でカテゴライズした一般的な人に発生する可能性があるライフイベントをライフイベント識別情報保持部から取得して対応した年齢に割り当てて表示しているが、人によっては、留学や転職など一般的には発生するとは限らないライフイベントを計画している場合がある。この場合は、見込ライフイベント入力画面0600の追加ボタン0606を押した場合に、見込ライフイベント追加画面が表示されるように構成しても良い。この画面では、(見込)ライフイベント選択欄0801で目的の(見込)ライフイベントを選択し、予算入力欄0802で支出予定金額、場合により収入予定金額を入力し、年齢欄0803で顧客本人の予定年齢を入力するようになっている。決定ボタン0804を押すことで入力したライフイベントを追加することができる。また、予め本システムに準備されていないライフイベントがある場合には、テキスト手入力でそのライフイベントを入力するように構成することもできる。本システムには予め手入力で入力を受付けるライフイベントの関数を準備しておき、それを手入力のライフイベントに割り当ててシステム内で利用するように構成する。この予備の関数は、5から10関数程度準備しておけば十分である。この関数の機能としては、その見込ライフイベントが発生する前や、発生時、発生後に生じる出費や収入などの収支を示す関数などが該当する。例えば、大学入学という見込ライフイベントがある場合には、大学受験、入学金の出費などが直接的なものであり、図6図7の第一子の場合にはこれに該当するのが200万円となるが、それ以前に大学の入学準備のための塾や予備校での出費や、大学入学後の授業料や、諸経費などが大学入学という見込ライフイベントを確定した場合に関数で表現されるように構成することが考えられる。このような関数は後述するライフプランのシミュレーションを実行する際に利用される。この関数は関連する出費や収入のパターンに応じて数種類準備されているのが好ましいが、関数自体を編集して特殊な見込ライフイベントに対応するように構成されていてもよい。これは関数編集部で行うように構成することができる。なお、ここで述べたことは本件装置が保持するライフイベント識別情報に対応してライフイベント関数として保持されていることが好ましい。
なお、戻るボタン0805を押した場合は、見込ライフイベント一覧画面に戻るようにする。
【0093】
以上述べたように、ライフイベント型金融商品出力装置が取得した見込ライフイベントに対して、顧客は、自身のライフプランに合わせて、見込ライフイベントの内容を変更したり、見込ライフイベントを追加したりといった編集入力が可能である。なお、入力方法に関しては、前述の内容に限定するものではなく、様々な形態が考えられる。要は、顧客が簡単に内容を編集できるようになっていればよく、そのように構成されたユーザインタフェースであれば形態を問わない。
【0094】
<実施形態1(主に請求項1に対応):構成の説明 将来情報保持部>
「将来情報保持部」0206は、選択された、又は選択の有無とは無関係に見込ライフイベント識別情報を少なくとも含む将来情報を顧客識別情報と関連付けて保持する。
将来情報保持部は、見込ライフイベント識別情報選択受付部で入力された見込ライフイベント識別情報と、顧客の見込ライフイベントの発生年齢(発生予定年齢あるいは発生予定時期)を関連付けて将来情報として、不揮発性メモリに保持する。その他、見込ライフイベント識別情報選択受付部で、見込ライフイベントの支出予定額が入力されている場合はその情報も関連付けて保持しても良い。将来情報には、その他にも、将来の収入の推移、将来の支出の推移、資産の推移、資産を資産運用した場合の資産の推移などを含んでいても良い。
【0095】
<実施形態1(主に請求項1に対応):構成の説明 金融商品識別情報保持部>
「金融商品識別情報保持部」0207は、金融商品の属性情報である金融商品属性情報などを6桁のコードで表現するものなどの金融商品属性情報と関連付けて金融商品を識別する金融商品識別情報を保持する。「金融商品識別情報」とは、金融商品を唯一に識別するためのIDコードの様な情報であり、例えば証券コードであったり、社債コード、ティッカーシンボルであったりと、一般的に日本国内の金融機関で共通に使用されている識別コードであることが好ましい。同一の金融商品を異なる金融機関から購入する場合もあるからである。ただし、これに限定されず、本システムでユニークに金融商品を識別できる識別情報であり、国内の金融機関が使用していない識別情報であてもよい。また、これらの識別コードと対応づけられたライフイベント型金融商品出力装置特有のコードで扱っても良い。この金融商品識別情報と、その情報が示す金融商品の特徴である金融商品属性情報とを関連付けて、HDDなどの不揮発性メモリに保持するように構成することが考えられる。
【0096】
「金融商品属性情報」とは、その金融商品の運用対象、期待利率、標準偏差、運用期間、リスク要因などの情報を含んでいる。また、金融商品分類(CFI)コード、即ちISO10962として定められた国際規格で、証券のカテゴリー(株式か債券か)や証券の属性(「議決権の有無」、「転売制限の有無」等であってもよい。さらに、金融商品属性情報としては例えばその金融商品の運用期間や、投資信託などの場合には、その目論見書に記載されている情報やデータ、過去の運用実績、購入者の統計情報などを含んでもよい。
この情報に基づいて、顧客が金融商品を選択したり、ライフイベント型金融商品出力装置がおすすめの金融商品を選択したりする。また、選択した金融商品で構成されるポートフォリオの運用利回りや標準偏差の算出にも使用する。
【0097】
「金融商品の運用対象」とは、例えば、投資信託の場合、運用対象が、株、債券(国債、社債)、仕組債権、為替、コモディティ、不動産、不動産担保証券等のいずれを運用対象としているかである。また、投資信託の他にも、金等の現物、様々な商品の先物、絵画、不動産など、長期で運用可能なものであれば対象商品として含まれる。ただし、金融商品の流動性は資産の取り崩しの際に問題となるので、流動性に問題のある商品に関してはその旨も関連付けて保持しておき、商品選択の際には考慮される必要がある。
【0098】
「期待利率」とは、過去所定期間の(金融商品単位量当たりの)平均的な運用益を運用総額で除したものである。投資信託などの場合は、運用目論見としている利率である。「標準偏差」とは、上述したように、リターンの分布の広がりがどの程度の大きさかを表す指標であり、一般的には±1σを用いる。「運用期間」は、例えば債券のような償還がある金融商品の場合は、購入予定時期からその償還までの期間を言う。また、定期預金のように満期が定まっている場合には、その期間である。投資信託のような無期限の金融商品の場合には運用期間は定められない。「リスク要因」とは、株式が運用対象の場合、株式の騰落リスクがあり、債券にはデフォルトリスクもある。また、外国株式や外国債券、為替などは為替変動リスクが含まれる。これらのリスク要因は、リスク度合を示す情報として金融商品に関連付けられて格付情報などとして保持されていることが好ましい。格付情報とした場合には金融商品識別情報選択ルールの関数の変数として利用することができるからである。
【0099】
以上の様な、金融商品属性情報に基づいて、資産をどの金融商品で運用するかを決定することが考えられる。
したがって、これら金融商品の選択をしやすくするために、期待利率でソートしたり、期待利率が何%以上かでフィルタリングしたり、取り扱い対象商品によって選別したり、といったデータの編集が可能なように保持することが望ましい。また選択すべき金融商品の候補を表示して、各金融商品の比較情報をグラフや図、表などで表現するように構成すると便利である。比較したい金融商品に関しては、顧客がチェックボックスなどを利用して比較金融商品を選択し、選択されて比較金融商品に関して前記図表やグラフなどを出力するように構成することができる。また、各金融商品の属性に関しても属性の種類に応じてチェックボックスをもうけて、チェックボックスでチェックされた金融商品属性情報に関して前記比較情報を出力するように構成することもできる。また、この出力はインターネットや近距離無線を利用して顧客が利用するスマートフォンやコンピュータに出力するように構成することも可能である。
【0100】
<実施形態1(主に請求項1に対応):構成の説明 金融商品識別情報選択ルール保持部>
「金融商品識別情報選択ルール保持部」0208は、顧客識別情報と関連付けられた顧客属性情報又は/及び取得された将来情報とに基づいて少なくとも複数の見込みライフイベント識別情報で識別されるライフイベントでの出費の少なくとも一部をまかなうためにライフイベントの発生予定時期に向けて継続的に又は/及びスポット的に投資する金融商品の金融商品識別情報が少なくとも一以上含まれるように時系列で保持されている金融商品識別情報を選択するルールである金融商品識別情報選択ルールを保持する。
【0101】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールの概要>
「金融商品識別情報選択ルール」とは、顧客の見込ライフイベントに備えた資産形成のために、いずれの金融商品を購入することが好ましいかを決定するルールである。また、どの程度の割合で購入するかを決定するルールがこれに含まれていてもよい。つまり、金融商品の経時的なポートフォリオ(購入割合が決定されない場合を含む。)を設計するためのルールである。また、現在の保有資産がある場合は、保有資産をどの金融商品の購入のためにどのように配分すべきかを決定するルールであってもよい。またもちろん、手持ちの金融商品をそのまま継続して保有し続けるという判断結果が出るように構成することもできる。
この金融商品識別情報選択ルールとしては、第一としてライフイベントに対して備えるものなので、ライフイベントが発生する時期に、そのライフイベントでの必要金額まかなうことが出来るようなルールであることが理想である。ただし、資産が必要金額を下回らないように設計することが困難である場合には銀行等借入によってライフイベントの実行が可能なように設計する場合があってよい。第二に顧客のライフプランに対して安心と余裕をもたらすものであるために、なるべく運用益が見込めて将来の資産形成に役立つものである必要がある。こうしたことから、資産のうちライフイベントに備える部分はなるべくリスクの低い金融商品、例えばリスク格付が低リスク格付となっている金融商品を選択し、ライフイベントでの必要金額に上乗せする余剰部分の獲得のための金融商品としては高いリターンを目指すような金融商品の選択を行うようにすることが考えられる。
【0102】
「時系列で」とは、時系列に並ぶライフイベントに応じて時間をずらして金融商品を選ぶために採用されるルールであるが、時間をずらさないですべての金融商品を同時に選択して購入し、運用を開始する場合も含むものとする。また「時系列」とは、金融商品の運用開始タイミングのみを指すのでなく、運用の終了タイミングを指すように構成されてもよい。代表的には金融商品の運用の終了のタイミングを示す場合があってもよい。また時系列とは、購入開始日と終了日を含む場合でもおおよそのタイミングを示す情報と関連付けられて選択されるように構成することが好ましい。
「継続的に又は/及びスポット的」とは、金融商品を継続的に購入し続ける場合、即ち継続的にその金融商品を積立購入する場合又は/及び、一時にあるいは散発的に購入するが、所定のインターバルで購入し続けることはない場合をいう。
【0103】
「ライフイベントの発生時期」とは、特定の日付を指す場合や、所定の期間を指す場合など両者があり得る。前者の場合の代表的な例は、特定の日付が「誕生日」、「入学日」「就職日」などが該当し、後者の代表的な例は、「結婚時期」、「出産時期」、「持ち家購入時期」などが該当する。ライフイベントの種類に応じて発生時期を示す情報はまちまちの形態でよい。ライフイベント識別情報にデータ形式フォーマットが関連付けられており、入力を顧客に促す場合には、その関連付けられたフォーマットでの入力画面が表示されるように構成することがあってもよい。
【0104】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールに基づく金融商品の選択方法>
金融商品の選択は、今後発生する見込ライフイベントの予定支出額に対する未達許容度に基づいて複数の金融商品を決定することが考えられる。
金融商品の選択は、例えば、元本が保証される預金と、債券などを運用する低リスク金融商品、金やコモディティ、不動産などを投資対象とする中リスク金融商品、株などに投資するハイリスク商品を組み合わせて選択するようにする。
これは、利回りとリスク(標準偏差)(以下、「リスク」については「標準偏差」のことを指す。)が異なる金融商品を組み合わせることで、購入比率により保有資産全体としての利回りや標準偏差を調整することができるからである。
また、預金だけでなく、資産を複数の金融商品に分散することで、様々なリスクを分散できるといった効果がある。景気の後退時期には株を運用資産とする金融商品はマイナスの利回りとなるが、コモディティ、例えば金を同時に運用資産としている場合には、むしろ金の相場が上昇する場合がある、また国債などを償還時期まで保有するようにポートフォリオを構成している場合には、国債の確定利回りは景気後退などに影響を受けない、などとして、これらを総合的に合わせれば大きく資産が損なわれることを防止できるというような考え方である。
【0105】
また、例えば、大半の資産を預金で保有した場合、元本は保証されるが、ほぼ金利が0%の昨今においては、長期的な視点で見ると、インフレリスクがあり、インフレ率に応じた資産の目減りが懸念される。こうした場合は、金や株などを投資対象とした金融資産を持つことで、インフレリスクに備えることができる。また、為替相場も長期視点では考慮する必要があるため、通貨も数カ国の通貨建てに分散して保有しておくことも為替リスクを回避する観点では重要である。
このようなことを考慮して様々な対象に分散投資をする金融商品もあるのでそのようなものを選ぶようにしても良い。
【0106】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールに関係する用語の説明「運用利回りと標準偏差」>
ここで、運用利回りと標準偏差について説明する。
運用利回りは、金融商品により異なるが、分配金や配当金による資産増加分と、金融商品の評価額を合算した金額が、元の金額よりも何%増えたかで示される。開始からの運用利回りであれば、投資した額に対する前述の増加額の割合となり、年間利回りであれば、年単位に換算した増加割合である。リスクとは、運用商品の評価額の変動率の標準偏差で表される。
例えば、過去5年の平均運用利回りが10%の商品に対して、その標準偏差が1σ(20%)であった場合、下ブレのリスクは、10%-20%=-10%となる。高い運用利回りの金融商品は、リスクも高くなる傾向がある。
【0107】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールにおける選択のための指標であるポートフォリオの総合的な運用利回りと標準偏差の計算方法>
さらに、複数の金融商品を組み合わせた場合の、全ての金融商品を総合した運用利回りと、標準偏差の算出方法は以下のようになる。
例えば、平均運用利回り2%、標準偏差2.5%の低リスク商品Aを購入代金の80%で購入し、平均運用利回り5%、標準偏差7.0%の中リスク商品Bを購入代金の10%で購入し、平均運用利回り20%、標準偏差32.0%の高リスク商品Cを購入代金の10%で購入したことを例として説明する。
また、例えば、一例として、金融商品Aと金融商品Bとの相関係数を0.27、金融商品Aと金融商品Cの相関係数を-0.25、金融商品Bと金融商品Cの相関係数を0.56と仮定して説明する。
ここで、「相関係数」とは、銘柄間やファンド間、指数などとの値動きの連動性を表す指標であり、+1から-1までの範囲で表される。相関係数が+1に近い場合には、一方の上昇率(下落率)が大きくなると、他方の上昇率(下落率)も大きくなる傾向が強く、相関係数が0に近い場合には、双方の騰落率の動きに関連性が無いと考えられる。相関係数が-1に近い場合には、一方の上昇率(下落率)が大きくなると他方が下落(上昇)するなど逆の動きをする傾向が強いと考えられる。例えば、相関係数が低い資産を組み合わせると、価格変動リスクを効率的に減らすことが期待できる。
全金融商品を総合したリスクは以下のような式で求められる。
(ア) 金融商品Aの割合の2乗×(金融商品Aの平均運用利回り-金融商品Aの標準偏差)の2乗+金融商品Bの割合の2乗×(金融商品Bの平均運用利回り-金融商品Bの標準偏差)の2乗+金融商品Cの割合の2乗×(金融商品Cの平均運用利回り-金融商品Cの標準偏差)の2乗
(イ) 2×金融商品Aの割合×(金融商品Aの平均運用利回り-金融商品Aの標準偏差)×金融商品Bの割合×(金融商品Bの平均運用利回り-金融商品Bの標準偏差)×(金融商品Aと金融商品Bとの相関係数)
(ウ) 2×金融商品Aの割合×(金融商品Aの平均運用利回り-金融商品Aの標準偏差)×金融商品Cの割合×(金融商品Cの平均運用利回り-金融商品Cの標準偏差)×(金融商品Aと金融商品Cとの相関係数)
(エ) 2×金融商品Bの割合×(金融商品Bの平均運用利回り-金融商品Bの標準偏差)×金融商品Cの割合×(金融商品Cの平均運用利回り-金融商品Cの標準偏差)×(金融商品Bと金融商品Cとの相関係数)
(オ) √分散=√[(ア)+(イ)+(ウ)+(エ)]=標準偏差
よって、総合した下ブレのリスク(標準偏差)は、上記式に当てはめると、-1.5%となる。
また、平均運用利回りを算出すると、
0.8×(2%)+0.1×(5%)+0.1×(20%)=4.1%となる。
このように、今回の例では、平均運用利回り4.1%で毎年運用が見込まれることを前提として考え、複利効果も考慮すれば、大きな資産の増加が期待できる可能性がある。
【0108】
以上述べたように、運用利回りや標準偏差の異なる商品を複数組み合わせることで、それらの金融商品の購入比率により、運用利回りや標準偏差を自由に設計できるので、様々なライフイベントに対して対応が可能になる。つまり、見込ライフイベントの未達許容度に応じて、選択した金融商品の購入比率を決定するようにすれば良い。
【0109】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールにおけるその他の選択のための指標例>
この他にも、例えば、購入時手数料や信託報酬などの手数料を抑えたいと思う顧客に対しては、インデックスファンドの様な、手数料が低いものを選択するようにする必要があるし、分配金に興味がある顧客に対しては、定期的な分配金があるファンドを選択するようにする。また、投資対象により、株、債券、コモディティなどで、顧客が興味を持つ運用対象のファンドを選択するようにする。このような、顧客の志向は、顧客属性情報として顧客属性情報取得部で取得するようにすればよい。以上も、金融商品識別情報選択ルールに含まれる。
以上述べてきた内容は、金融商品の商品選択ルールであるが、以降は金融商品の購入比率によるリスクの設定に関わる未達許容度について説明する。
【0110】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールの説明 ライフイベント未達許容度に基づく選択の考え方>
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールの説明 未達許容度低>
ライフイベントには予定している支出金額に対して、備えが未達であった場合でも対応可能かで未達許容度という考え方を用いる。未達許容度は、ライフイベント識別情報と関連付けて保持されているとよい。その場合には、金融商品識別情報の選択に際してそれぞれのライフイベントに関連付けられている未達許容度に応じて金融商品識別情報を選択するという演算が可能となる。これはもちろん金融商品識別情報に関連付けられている金融商品属性情報のリスクに関する情報を利用して選択することとなる。
未達許容度の考え方としては、教育費や老後資金は、未達許容度が低いと考えられる。
これは、教育費も老後資金もともに、支出予定の変更が難しい。教育費に関しては、予定金額を確保していなければ、子供に必要な教育の質が低下するし、不足分を借入した場合はその後の資産形成の支障となる。また、老後資金が必要額を確保されていないと、生活の質を低下させるしかなく、また、病気等大きな支出が発生した場合に対応できなくなる。また、発生時期に関しても、教育費は発生する年齢がほぼ決まっており先送りすることが出来ない。老後資金に関しても、定年後もなるべく長く働かない限りは、決まった年齢から必要になる。こうした、必ず発生し、予定支出を下回ることが許されないライフイベントは、未達許容度が低いと言え、低リスク(例えば、標準偏差2%未満、運用利回り3%以下)なポートフォリオを形成することが望ましい。
【0111】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール 未達許容度中>
次に未達許容度が中程度のライフイベントとしては、結婚や資格取得などがある。
これは、結婚に関しては、予算に応じて、結婚式への参列者の人数を減らしたり、新婚旅行の行き先を変更したりするなど、予算を抑えることができる。また、資格取得で、通信教育や専門学校など学費が必要になる場合は、予算に応じて勉強方法を変えたりなどの対応が可能である。
また、これらのライフイベントに関しては、発生時期に関しても、資金が準備できるまで先送するなど時期の融通も効くと考えられる。
こうした、実施しないことは無いが、支出額、時期ともに、ある程度融通が効くライフイベントは、未達許容度が中程度であり、中リスク(例えば、標準偏差2%以上~5%未満、運用利回り3~7%)なポートフォリオを形成することが望ましい。
【0112】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールの説明 未達許容度高>
次に未達許容度が高いライフイベントとしては、車の買い替えや旅行等、趣味に関するものが該当する。これは、車ならば、買い替える車のグレードを落とすことで支出額を抑えられるし、旅行も行き先を海外から国内に変更するなどして支出額を抑えることができる。また、時期に関しても先送り出来るし、場合によっては、実施を見合わせることもあり得る。
こうしたことから、未達許容度は高いと言え、高リスク(例えば、標準偏差5%以上、運用利回り7%以上)なポートフォリオを選択しても良い。
このようなライフイベントは、運用成績が良ければ、購入する車のグレードを上げたり、旅行を豪華にしたりするなど資産運用のモチベーションにも繋がる。
以上に述べた、ライフイベントの未達許容度は、ライフイベント識別情報保持部にライフイベント識別情報に関連付けて保持されるようにすればよい。
【0113】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールの説明 ポートフォリオリスク決定の一例>
金融商品識別情報選択ルールでは、選択した金融商品の購入比率を、以上に述べたライフイベントの未達許容度に対応したリスク以下になるように、金融商品の購入比率を決定することが考えられる。
例えば、未達許容度はライフイベントに対して予め決められる値となるが、結婚に対して未達許容度が-8%として設定されていたとする。つまり結婚の際の出費予想が100万円の場合には92万円しか準備できなくても可とする考えからである。
ここでの金融商品識別情報選択ルールで決定されているルールとして、「未達許容度の50%までのリスクを許容する」とした場合、リスクは上限として4%までと決定される。
従って、結婚は未達許容度中のライフイベントと考えられ、リスクが4%を上限としたポートフォリオを設計する。
以上述べたような、リスクを何%まで許容するかのルールの決定は、顧客の資産の状況によって変更するようにしても良いし、ライフイベント発生までの期間で決めるようにしても良い。
【0114】
<実施形態1(主に請求項1に対応):金融商品識別情報選択ルール保持部 金融商品識別情報選択ルールの説明 運用期間の考え方>
ライフイベントの発生までの期間が、そのライフイベントに向けて備えた資金の運用期間となるが、運用期間が長くなるほど、ポートフォリオの標準偏差を高く設定しても良い。
このように、ライフイベント発生までの期間により、ポートフォリオのリスクを変化させ、高めに設定することで、高いリターンも期待できる。
ライフイベントまでの期間が長い場合、即ち金融商品の運用期間が相対的に長期となる場合には同じ金融商品でも期待リターンを大きく設定することが可能となる。3年を超えるとポートフォリオの期待リターンを変更可能なように構成することが考えられる。これは、リスクが標準偏差に基づいて算出されており、運用期間が長いほど金融商品の価格ボラティリティが標準偏差に基づいて定めた理論値に近づくからである。
なお、前述のようなポートフォリオのリスクを変更することは、顧客の確認に基づいて行うようにすることが望ましい。
【0115】
<実施形態1(主に請求項1に対応):構成の説明 金融商品識別情報選択部>
「金融商品識別情報選択部」0209は、顧客属性情報又は/及び取得された将来情報と、金融商品識別情報選択ルールとに基づいて金融商品識別情報を選択する。
金融商品識別情報選択部は、金融商品識別情報選択ルール保持部に保持された金融商品識別情報選択ルールに基づいて、金融商品識別情報保持部に保持されている金融商品識別情報の中から、購入する金融商品を示す金融商品識別情報を決定し、購入対象の金融商品識別情報を取得する。この際に金融商品識別情報と関連付けられているその金融商品の属性情報が参照される。
【0116】
基本的な考え方として、顧客の見込ライフイベントの未達許容度に応じて、未達許容度が低ければリスクの低いポートフォリオを設計し、未達許容度が高くなるに従って、利回りを重視してリスクが高いことを許容するポートフォリオを設計するようにする。この他、顧客属性情報から推定される顧客の志向を反映した金融商品を選択するようにしても良い。例えば、投資性向に関して、安定志向か、利回り重視か、日本への投資主体か外国への投資が主体か、為替リスクは避けたいと考えているかなど、この他にも、顧客の投資に対する考え方を反映するようにすることが望ましい。
以上の様な投資性向に基づいて、顧客が好みと思われる金融商品を、低リスクなものから一つ以上、中リスクのものから一つ以上、高リスクなものから一つ以上それぞれ選択するようにすることが考えられる。
【0117】
次に、見込ライフイベントを参照し、金融商品情報選択ルール保持部に保持された金融商品情報選択ルールに基づいて、選択した金融商品の比率を決定する。
これは、今後発生する見込ライフイベントの未達許容度から求められるポートフォリオのリスクを決定し、そのリスクに収まるように、金融商品の比率を決定する。
【0118】
<実施形態1(主に請求項1に対応):金融商品識別情報選択部 金融商品識別情報選択処理>
図9は、金融商品識別情報選択処理の、処理の流れを示すフローチャートである。
金融商品識別情報選択処理では先ず、ポートフォリオリスク決定ステップS0901で、ポートフォリオの標準偏差の上限値を決定する。このリスクの上限は、ライフイベントの未達許容度に基づいて、前述した金融商品識別情報選択ルール従って決定する。
【0119】
次に、金融商品銘柄決定ステップS0902で、ポートフォリオに組み込む金融商品を1つ以上選択する。金融商品の銘柄は、顧客属性情報から顧客の投資志向に合わせた金融商品を選択するようにすると良い。顧客の投資志向は、顧客属性情報取得部にて顧客属性情報を取得する際、投資に関するいくつかの質問を行って取得するなどの方法が考えられる。そして、顧客の志向に合わせた金融商品から、低リスク金融商品、中リスク金融商品、高リスク金融商品からそれぞれ1つ以上の銘柄を選ぶようにする方法が考えられる。
【0120】
次に、金融商品比率決定ステップ1504で、金融商品銘柄決定ステップで決定した金融商品の比率を決定する。この金融商品の比率決定方法は、金融商品識別情報選択ルールの総合的な運用利回りと標準偏差の計算方法で説明した方法で計算し、ポートフォリオのリスクを超えないように決定する。
以上の処理により、金融商品識別情報とそれに対応した比率を決定できる。
【0121】
<実施形態1(主に請求項1に対応):金融商品識別情報選択部 金融商品一覧画面の一例>
金融商品識別情報選択部は、その入力インタフェースの一部として金融商品一覧画面を有するように構成してもよい。
ライフイベントに対応する資産形成のための複数の金融商品は、顧客が指定するように構成しても良い。この時、ライフイベント向け金融商品出力装置は、推奨する商品をピックアップし、顧客はその金融商品群の中から選択するようにしても良い。
【0122】
図11は金融商品選択方法の一例を説明するための図であり、金融商品一覧画面1100には、低リスク金融商品表示欄1101と、中リスク金融商品表示欄1102と、高リスク商品表示欄1103と、があり、各該当する金融商品の商品名が商品名欄1104に、各金融商品の運用利回りが運用利回り欄1105に、各金融商品の標準偏差が標準偏差欄1106にそれぞれ表示されている。
ライフイベント型金融商品出力装置は、低リスク、中リスク、高リスクに分類される金融商品の中から、それぞれの分類ごとに、金融商品識別情報選択ルールに従って、複数の金融商品を選択する。そして、その中から顧客に所望の金融商品を選択させる。
【0123】
金融商品識別情報選択ルールの一例として、顧客の顧客属性情報からわかる投資性向によって、各リスク分類に対して1銘柄以上選択するようにする。顧客の投資性向とは、例えば、為替リスクは避ける傾向がある場合は、外貨建ての預金や債券は選択しないようにしたり、為替リスクのある投資信託の場合リスクヘッジありの投資信託を選択したりする。また、不動産投資に興味がある場合は、REITを選択したり、金などの現物志向がある場合は金の現物を購入したりするなどが考えられる。以上は、一例であり、この例では、リスクを3段階に分類しているが、これよりも多くても良いし、各リスクから複数選択するようにしても良い。
【0124】
<実施形態1(主に請求項1に対応):構成の説明 金融商品識別情報出力部>
「金融商品識別情報出力部」0210は、選択された金融商品識別情報を顧客識別情報と関連付けて出力する。
金融商品識別情報出力部は、顧客が承認または決定した複数の金融商品の金融商品識別情報と各金融商品の購入額とを含む情報を出力する。
この情報には購入日に関わる情報を含んでいても良く、例えば、積立購入の場合は、毎月指定の購入日に、選択した金融商品が指定額購入される処理が行われる。この購入処理は、ライフイベント型金融商品出力装置が行う場合もあれば、金融商品の購入先である運用会社が行う場合もある。金融商品識別情報出力は、積立購入する金融商品の出力に限ったものでは無い。例えば、保有資産がある場合には、その時点の資産で購入する金融商品と購入額を出力して発注を行う場合もあれば、資産運用対象の見直しの際に、保有金融商品を売却して新しい金融商品を購入する際の購入する金融商品と、各金融商品の購入額を出力して発注を行う場合も含まれる。なお、金融商品識別情報出力部から出力された金融商品識別情報をさらに顧客に選択させて実際のポートフォリオを作ったり、試しにポートフォリオを作るような段取りで構成されたりしてもよい。なお、この段階で金融商品の購入が決定されるようなシステムであっても、購入は直ちに開始される必要はなく、将来の時期から購入を開始するように設計することもできる。
【0125】
<実施形態1(主に請求項1に対応):構成の説明 金融商品識別情報出力部 購入金額・金融商品指定画面の一例>
図10は、ライフイベントに対応した購入金額・金融商品指定画面の一例である。
購入金額・金融商品指定画面では、顧客により選択されたライフイベント向けの金融商品と購入金額を表示する。
図の例では、月々の積立購入による金融商品の購入例を示しているが、一括購入であっても良い。
購入金額・金融商品指定画面1000は、図7のライフイベント一覧画面で指定のライフイベントを選択した場合に表示するように構成することが考えられる。
購入金額・金融商品指定画面には、ライフイベント情報1001と、金融商品比率表示円グラフ1002と、購入金額指定欄1003と、金融商品名1004と、購入比率欄1005と、リスク表示欄1006と、決定ボタン1007と、期待利率1008と、標準偏差1009とが表示されている。
【0126】
図の例では、5年後の住宅購入向けの資産形成のための購入金額・金融商品指定画面を示している。
ライフイベント情報には、ライフイベントとして住宅購入、ライフイベントまでの期間が5年、目標金額が800万円で、現在資産額が500万円あることが示されている。購入金額欄1003は、購入する金額を入力する欄であり、図の例では積立購入での月額が示されている。初期値として自動で、目標金額を積立月数で除算した金額を入力しておくようにしても良い。
金融商品名は、選択した金融商品を表示する欄である。購入比率欄は、該当する金融商品の購入総額に対する購入比率を選択する欄である。リスク表示欄は、該当する金融商品のリスク区分を表示する欄で、図の例では、低リスク、中リスク、高リスクの3区分で示している。期待利率は、選択された金融商品の期待利率を総合した年間利回りである。標準偏差は、選択された金融商品の標準偏差を総合した年間での想定標準偏差である。決定ボタンを押すと、ライフイベント向けの資産形成のための複数の金融商品を組み合わせた金融商品ポートフォリオと購入金額が確定される。
【0127】
<実施形態1(主に請求項16に対応):制御方法>
以上が、実施形態1の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図19に示すように、本実施形態の計算機(コンピュータ)であるライフイベント型金融商品情報出力装置の制御方法は、顧客属性情報取得ステップS1921と、顧客識別情報保持ステップS1922と、顧客属性情報保持ステップS1923と、ライフイベント識別情報保持ステップS1911と、見込ライフイベント識別情報入力受付ステップS1931と、将来情報保持ステップS1932と、金融商品識別情報保持ステップS1912と、金融商品識別情報選択ルール保持ステップS1913と、金融商品識別情報選択ステップS1933と、金融商品識別情報出力ステップS1934と、を有して金融商品識別情報を出力する方法である。
各ステップの作用は、構成で説明した内容と同じなので省略する。
【0128】
<実施形態1(主に請求項16、17に対応):処理の流れ>
図19は、本発明のライフイベント型金融商品情報出力処理の実施形態1に関わる処理の流れを示すフローチャートである。本フローチャートは、メイン処理と、起動処理S1910と、顧客登録処理S1920と、金融商品情報出力処理1930の3つのサブルーチン処理で構成されている。
【0129】
<実施形態1(主に請求項16、17に対応):処理の流れ メイン処理>
先ず、ライフイベント型金融商品情報出力処理が開始されると、起動処理を行う。
その後、顧客の顧客情報登録処理要求があった場合は、顧客登録処理を行い(S1901でYを選択)、なかった場合は、次の処理に移行する(S1901でNを選択)。
次に、金融商品情報の出力要求があった場合は、金融商品情報出力処理を行い(S1902でYを選択)、要求が無かった場合は次の処理に移行する(S1902でNを選択)。
次に、ライブイベント型金融商品情報出力処理の終了要求があった場合は、処理を終了するが(S1903でYを選択)、終了要求が無かった場合は、起動処理の後から再度処理を実行する。
なお、顧客の顧客情報登録処理要求の判断S1910と、金融商品情報出力要求の判断S1920の順序は逆でも構わない。
【0130】
<実施形態1(主に請求項16、17に対応):処理の流れ 起動処理>
次に、起動処理について説明する。起動処理は、ライフイベント型金融商品情報出力処理を行うための準備処理であり、ライフイベント識別情報保持ステップS1911と、金融商品情報保持ステップS1912と、金融商品情報選択ルール保持ステップS1913とで構成される。
先ず、ライフイベント識別情報保持ステップで、ライフイベント識別情報をメインメモリ上のデータ領域にロードする。
次に、金融商品情報保持ステップで、金融商品識別情報をメインメモリ上のデータ領域にロードする。
次に、金融商品情報選択ルール保持ステップで金融商品識別情報選択ルールをメインメモリ上のデータ領域にロードする。なお、金融商品情報選択ルールは、プログラムとして構成することも可能であり、この場合は、金融商品情報選択ルール実行プログラムとして、メインメモリ上のプログラム領域にロードするようにすれば良い。
なお、ライフイベント識別情報保持ステップと、金融商品情報保持ステップと、金融商品情報選択ルール保持ステップの実行順は、フローチャートで示した順でなくても構わない。適宜順番の変更は可能である。
【0131】
<実施形態1(主に請求項16、17に対応):処理の流れ 顧客情報登録処理>
次に、顧客情報登録処理について説明する。顧客情報登録処理は、顧客が入力した顧客識別情報及び顧客属性情報を保持する処理であり、顧客識別情報取得ステップS1921と、顧客属性情報保持ステップS1922と、顧客属性情報保持ステップS1923とを有する。
顧客がインターネットを経由して、ライフイベント型金融商品情報出力処理を有するサーバにアクセスして、顧客登録を行うことで、顧客情報登録ありS1901の判定が「Y」となり処理が開始される。
【0132】
先ず、顧客識別情報取得ステップでは、顧客の氏名、生年月日、住所、電話番号、e-mailアドレスなど、顧客の特定情報の入力を促す画面を表示して入力を受け付ける。必要情報が入力されたら、顧客識別情報として、ライフイベント型金融商品情報出力処理内での顧客を特定するIDやナンバー等を付与し、顧客識別子として顧客に発行する。
次に、顧客属性情報取得ステップで、顧客の家族構成、収入、支出、教育費、保険、年金など顧客の状態に関わる顧客属性情報の入力を促す画面を表示し、顧客の入力した内容を取得する。
その後、顧客属性情報保持ステップで付与した顧客識別情報に関連付けて、顧客識別情報取得ステップで取得した顧客の特定情報と、顧客属性情報取得ステップで取得した顧客属性情報を関連付けて、不揮発性メモリに保持する。
【0133】
なお、顧客属性情報取得ステップと、顧客識別情報取得ステップは、続けて行う必要は無く別なタイミングで行うようにしても良い。ただし、顧客識別情報取得ステップの後に、顧客属性情報取得ステップが実行される必要があり、また、どちらか一の処理を行った場合でも、顧客属性情報保持ステップは必ず行う必要がある。
【0134】
<実施形態1(主に請求項16、17に対応):処理の流れ 金融商品情報出力処理>
次に、金融商品情報出力処理について説明する。金融商品情報出力処理は、顧客がライフイベント型金融商品情報出力処理を行うサーバにログインし、金融商品の選択や出力を行う際に実行される処理であり、見込ライフイベント識別情報入力受付ステップS1931と、将来情報保持ステップS1932と、金融商品識別情報選択ステップS1933と、金融商品識別情報出力ステップS1934とを有する。
【0135】
先ず、見込ライフイベント識別情報入力受付ステップで、顧客に今後起こる予定の見込ライフプランの入力を促す画面を表示し、顧客に見込ライフイベントを入力させる。
次に、金融商品識別情報選択ステップで、積立購入を行う金融商品の選択を行う。この金融商品の選択は、顧客が行っても良いし、ライフイベント型金融商品情報出力処理により推奨しても良い。また、ここで月々の積立金額を決定するようにしても良い。
次に、将来情報保持ステップで将来の見込資産の計算を行う。将来の見込資産とは、顧客の指定したまたはライフイベント型金融商品情報出力処理で決定した月々の積立金額で積立を行った場合の積立資産の推移を少なくもとも含み、見込ライフイベントが発生した場合はその予定支出金額を積立資産から減額するようにしたものである。さらにそれを金融商品識別情報選択ステップで選択した金融商品ポートフォリオで運用した場合は資産がどのように推移するかを示す情報も含むことが望ましい。この結果は、何度やり直しても良いが、最終的に顧客が良とした結果は少なくとも、将来情報として不揮発性メモリ内に記録するようにする。
次に、金融商品識別情報出力ステップで将来情報として保持された内容に該当する金融商品の識別情報を顧客が視認できるように表示し、顧客が購入を決定する入力を受け付けた場合は、資産運用会社に金融商品ポートフォリオの発注を行う。
【0136】
<実施形態1(主に請求項17に対応):ハードウェア構成>
図20は、実施形態1のライフイベント型金融商品情報出力装置のハードウェア構成の一例を示すブロック図であり、CPU2010と、メインメモリ2020と、不揮発性メモリ2030と、チップセット2041・2042と、BIOS2050と、I/Oコントローラ2060と、LANインタフェース2070と、グラフィックカード2080とを有している。
不揮発性メモリ内には、顧客属性情報取得プログラム20301と、顧客識別情報保持プログラム20302と、顧客属性情報保持プログラム20303と、ライフイベント識別情報保持プログラム20304と、見込ライフイベント識別情報選択受付プログラム20305と、将来情報保持プログラム20306と、金融商品識別情報保持プログラム20307と、金融商品識別情報選択ルール保持プログラム20308と、金融商品識別情報選択プログラム20309と、金融商品識別情報出力プログラム20310と、顧客属性情報20321と、ライフイベント識別情報20322と、将来情報保持20323と、金融商品識別情報20324と、金融商品識別情報選択ルール20325とを有し、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出して実行する。なお、金融商品識別情報と関連付けられて金融商品の属性を示す情報である金融商品属性情報がメモリに格納され、CPUや各種プログラムによって利用可能に構成されていることが好ましい。あるいは外部装置格納された金融商品属性情報を、金融商品識別情報をキーとして、取得できるように構成されていてもよい。
【0137】
<実施形態1(主に請求項1に対応):効果>
以上述べてきたように、本実施形態によれば、顧客は予定しているライフイベントの出費に対して、備えができるように、金融商品の積立購入による資産形成を行えるので、ライフイベントの際の多額の出費に対して、借り入れを行う必要が無くなり、顧客の資産形成に貢献できる。
また、資産運用により将来のライフプランを明確に描けるので、老後資金の不安が無くなり、余裕のある老後の備えができる。
<実施形態2(主に請求項2に対応)>
<実施形態2(主に請求項2に対応):概要>
実施形態2は、実施形態1の構成に加えて、将来収入情報取得部をさらに有して、将来の収入の変化を取得し、各年齢における年間収入額の推移を算出する。これにより、将来的に積立可能な金額の変化を推定し積立金額設定の際に参照しても良い。
【0138】
<実施形態2(主に請求項2に対応):構成>
図21は、実施形態の機能の構成を示すブロック図であり、実施形態1の構成に加えて、将来収入情報取得部2111をさらに有している。
以降、各部の構成を説明するが、実施形態1と重複する構成の説明は省略する。
【0139】
実施形態1と重複する構成の説明は省略する。
将来収入情報取得部2111は、顧客属性情報保持部に保持された顧客の収入に関わる情報から将来的な各年齢における収入を推定する。推定した各年齢での収入の推移は、将来情報保持部に保持される。
【0140】
<実施形態2(主に請求項2に対応):構成の説明 将来収入情報取得部>
「将来収入情報取得部」2111は、顧客識別情報と関連付けて将来の収入を示す情報である将来収入情報を取得する。
将来収入は、各年齢での収入なので年収で計算することが望ましいが、これに限定するものではなく、月収に展開できる様になっていても良い。一般的なサラリーマンであれば収入は所得収入によりある程度決まっているが、フリーランスなど月々の収入にばらつきがある場合は、平均的な収入額で計算するようにすれば良い。
【0141】
将来収入情報取得部は、現在の収入に基づいて、今後見込まれる昇給を加味し、各年齢における収入を取得するようにしても良い。将来の収入の推定には、顧客の勤務先の業種情報や、顧客の職種を、顧客属性情報として入力させてその情報を用いて行っても良い。具体的には、勤務先の業種から業界の平均給与を、顧客の職種からその職種における平均給与を求め、現在の年齢と収入から今後の収入の推移を推定することが考えられる。また、そのような情報が得られない職種に関しては、様々な顧客の実際の収入情報を用いて、平均的な給与を参考に、今後の給与の推移を推定するようにしても良い。実際の収入情報は顧客属性情報として蓄積されている顧客の収入情報を匿名で利用するものである。
【0142】
また、顧客属性情報により取得した退職年齢以降の給与については、一般的には再雇用などで雇用された場合、退職前の収入よりも大幅に低下するため、退職前の収入からは推測しづらい内容である。これに関しては、再雇用で働く人の平均年収を用いるようにしても良い。
【0143】
また、老後の年金収入を考慮することも重要である。
この金額に関しては、厚生労働省が運営するねんきんネットで調べることができるので、その金額を顧客が入力するようにしても良いし、年金番号等を入力しておくことで、自動で取得できる様に構成しても良い。また、年齢が若い場合、年金加入期間が短いため支給金額が正確に推定できない場合がある。この場合は、平均的な年金額を使用するようにしても良い。いずれにしても、年金額は、老後の積立資産の取り崩し金額に関わるものなので、老後資産の見積に非常に重要となる。
以上の様に、各年齢における収入の見込を計算する。
【0144】
図22は、本実施形態における収入入力画面2200の一例あり、給与所得入力欄2202に、現在の手取り年収に加えて、会社の事業内容と、職種を入力するようになっている。この情報に基づいて、将来の収入を見積もるようにしている。図の例では、事業内容に電子機器製造業と、職種に開発職を入力している。
【0145】
図23は、将来収入情報取得部で将来収入情報を取得した場合の一例である。
図22の収入入力画面で取得した事業内容と職種に従い、電子機器製造業の給与推移、開発職の給与水準を加味し、現在の手取り年収412万円から今後の年収を推定している。図の例では、50歳程度で年収が頭打ちし、定年の60歳に向けて徐々に下がっている。退職後は、再雇用で400万円の年収で65歳まで推移し、その後は年金を260万円受け取る推定をしている。
【0146】
<実施形態2(主に請求項2に対応):制御方法>
以上が、実施形態2の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図25は、実施形態2のライフイベント型金融商品情報出力装置の制御方法を示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態1の制御方法に加えて、将来収入情報取得ステップ2535をさらに有する制御方法である。
各ステップの作用は、構成で説明した内容と同じなので省略する。
【0147】
<実施形態2(主に請求項2に対応):処理の流れ>
実施形態2のライフイベント型金融商品情報出力装置の制御装方法は、金融商品情報出力処理に、将来収入情報取得ステップが追加になっている。
メイン処理、起動処理、顧客登録処理は、実施形態1の処理の流れと同じなので省略する。
将来情報保持ステップ2533の前に、今後の各年齢での収入である将来収入情報を取得する将来収入情報取得ステップ2535を実施する。将来収入情報は、昇給等を考慮した各年齢での年収の変動を反映した情報であり、年金等による収入も含む情報である。将来収入情報取得ステップは、将来情報保持ステップの前までに実行されていれば良く、金融商品出力処理内での他の処理との順番は入れ替わっても良い。
【0148】
<実施形態2(主に請求項2に対応):ハードウェア構成>
図24は、実施形態2のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態1の構成に加えて将来収入情報取得プログラム24311をさらに有し、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出して実行する。
【0149】
<実施形態2(主に請求項2に対応):効果>
本実施形態のライフイベント型金融商品情報出力装置によれば、将来の収入の推移を把握できるので資産形成のために、どの程度の積立金額が可能かを決めるのに参照できる。
【0150】
<実施形態3(主に請求項3に対応):概要>
実施形態3は、実施形態1又は実施形態2を基本として各年齢における年間の主に家計に関わる将来支出情報を取得する。家計支出は、家族構成や家族の年齢により変化する。また、物価上昇による上昇も加味する必要があり、将来の支出がどのように推移するかを把握することは、ライフプランを考えるうえで重要である。
【0151】
<実施形態3(主に請求項3に対応):構成>
図26は、本発明のライフイベント型金融商品情報出力装置の実施形態3の構成を示すブロック図であり、実施形態1または2の構成に加えて、将来支出情報取得部2612をさらに有している。
以降、各部の構成を説明するが、実施形態1と重複する構成の説明は省略する。
【0152】
<実施形態3(主に請求項3に対応):構成の説明 将来支出算出取得部>
「将来支出」とは、今後の各年齢における年間の支出であり、主には家計支出である。ただし、支出情報は、支出金額のみならず、将来の支出を占ううえで必要な情報を含んでいてもよい。例えば支出のボラティリティ、物価上昇のボラティリティなどである。支出情報は、各ライフイベントで発生する出費を含んでいても、含まないようにしてもよい。含まないようにする場合でも前述のようにライフイベントの前後で付随的に発生する支出を含むように構成することが好ましい。
「将来支出情報取得部」2612は、顧客の各年齢での年間支出の推移を推定するものである。
衣食住に関わる家計支出の他に、生命保険や個人年金などの月々の支払、車の維持費、学費、住宅ローンの返済額などの支出も合わせて年間総支出として推定する。また、家計支出は子供の成長とともに増えるので、顧客属性情報で入力された家族構成の情報に基づいて、子供の年齢を考慮し、食費や衣料費などの増加を平均的な家計支出などの統計情報に基づいて算出するようにする。
【0153】
また、顧客属性情報として入力された支出情報から、生活水準を推定し、平均値から増加または減少させるように構成することが望ましい。家計支出は、顧客の生活水準によりばらつきがあるからである。
また、子供の学費が発生する場合はその支出も加算して計算する必要がある。
【0154】
ライフプランを考える場合、推定する期間が長いので、インフレ率による上昇も考慮した数値を算出するようにすることが望ましい。このような様々な条件を考慮して、各年齢における支出の推移を計算するが、顧客により設定された顧客属性情報に基づいて自動で計算を行うことが望ましい。
これにより、将来の支出金額の推移が把握でき、積立金額を決める場合に参照出来る情報となる。
【0155】
図29は、将来支出情報取得部により取得された将来支出情報の一例である。
図の例では、4人家族の支出額であるが、子供の成長とともに、支出額が増えている。これは、食費、衣料費、学費の増加が主な要因である。その後、55歳で第一子が、57歳で第二子が大学に入学するため支出額が大幅に増加している。これは、大学の学費によるものもあるが、子供の下宿代や食費による増加も含まれる。その後61歳で子供が独立するので、家計支出は大幅に低下している。その後は大きな支出がないので一定金額の支出となっている。なお、顧客属性情報を定期的に最新の情報にアップデートし、アップデートされた顧客属性情報に応じて将来支出情報を修正するように構成することもできる。またこれとは別に将来支出情報を編集することが出来るように構成することもできる。将来支出情報編集部にその機能を担わせるように構成することができる。
以上の様に、一生涯での支出額の推移が把握できるので、ライフプランを考える参考となる。
【0156】
<実施形態3(主に請求項3に対応):制御方法>
以上が、実施形態3の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図28は、実施形態3のライフイベント型金融商品情報出力装置の制御方法を示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態1または2のいずれか一の制御方法に加えて、将来支出情報取得ステップ2836をさらに有する制御方法である。
各ステップの作用は、構成で説明した内容と同じなので省略する。
【0157】
<実施形態3(主に請求項3に対応):処理の流れ>
実施形態3のライフイベント型金融商品情報出力装置の制御方法は、金融商品情報出力処理に、将来支出情報取得ステップが追加になっている。メイン処理、起動処理、顧客登録処理は、実施形態1の処理の流れと同じなので省略する。将来情報保持ステップS2833の前に、今後の各年齢での収入である将来支出情報を取得する将来支出情報取得ステップS2836を実施する。将来支出情報は、主に家計支出に関わる情報であり、学費、保険料の支出やローンの支払いなどを含めた年間の総支出額である。将来支出情報取得ステップは、将来情報保持ステップの前までに実行されていれば良く、金融商品出力処理内での他の処理との順番は入れ替わっても良い。
【0158】
<実施形態3(主に請求項3に対応):ハードウェア構成>
図27は、実施形態3のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態1または2のいずれか一の構成に加えて将来支出情報取得プログラム27312をさらに有し、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出して実行する。
【0159】
<実施形態3(主に請求項3に対応):効果>
本実施形態のライフイベント型金融商品情報出力装置によれば、将来の支出の推移を把握できるので資産形成の必要性や、将来の出費に対する備えの必要性を把握できる。
【0160】
<実施形態4(主に請求項4に対応)>
<実施形態4(主に請求項4に対応):概要>
実施形態4のライフイベント型金融商品情報出力装置は、将来収入情報と将来支出情報に基づいて、積立金額を決定し、その積立金額を積み立てた場合の積立資産額の推移を将来積立情報として将来情報保持部に保持する。
このように、将来の収入額と、支出額に基づいて、積立金額を決定するので、その積立金額の範囲内での金融商品の積立購入が、将来的に継続可能なのかを確認して決定できるので、ライフプランニングの精度が向上するといえる。
【0161】
<実施形態4(主に請求項4に対応):構成>
図30は、実施形態4のライフイベント型金融商品情報出力装置の構成を示すブロック図であり、実施形態2を含む実施形態3の構成に加えて、将来積立情報取得部3013をさらに有している。
以降、各部の構成を説明するが、実施形態2および3と重複する構成の説明は省略する。
【0162】
<実施形態4(主に請求項4に対応):構成の説明 将来積立情報取得部>
「将来積立情報取得部」3013は、将来収入情報取得部で取得した将来収入情報と、将来支出情報取得部で取得した将来支出情報とに基づいて金融商品を購入するための金額である将来積立情報を取得する。
「将来積立情報」とは、今後行う積立金額の累積値又は将来の各月などの積立タームにおける各積立金額であり、積立金額は、固定した金額であっても良いし、経時的に変化する金額であっても良い。
積立が可能な金額は、収入金額から、支出金額(生活費)を減算した金額が、積立金額の上限値となる。これに対して上限いっぱいで積立金額を設定した場合、日々の生活の余裕がなくなってしまう。
具体的には、見込通りに給与所得が増えなかった場合や、見込よりも家計支出が増えてしまった場合などに対応できなくなる。また、事故や病気、火事、自然災害などの突発的な出費が必要となる事象にも対応できなくなる。
【0163】
従って、将来積立情報取得部は、将来収入情報と、将来支出情報から、各年齢において将来収入から将来支出を減額した額に対して所定の割合を乗算した金額を算出し、その金額から積立金額を決定する様にしても良い。また、所定の割合を顧客が決めておいて、各年齢での積立金額を算出する方法も考えられる。この場合、積立金額は年齢ごとに変化することになる。
この積立金額を決める割合は、顧客が指定しても良いが、顧客属性から取得した内容に基づいて、将来積立情報取得部が決定するようにしても良い。顧客の貯蓄性向を判定し、その値によって決めるようにすることが考えられる。また、見込ライフイベントの支出予定額に対して不足する場合には、高く設定する様にしても良いし、比較的裕福な顧客に対しても資産形成の意味で、高めに設定することを推奨しても良い。
【0164】
<実施形態4(主に請求項4に対応):構成の説明 将来積立情報取得部 イベント別積立金額確認画面>
将来積立情報取得部は、インタフェースの一例としてイベント別積立金額確認画面を有しても良い。
図12は、イベント別積立金額確認画面の一例を示す図である。
イベント別積立金額確認画面1200は、イベント別購入金額欄1201と、支払総額表示1202と、OKボタン1203で構成される。
イベント別購入金額欄には、イベント別に設定した金融商品ポートフォリオに対して指定した購入金額が表示される。また、ここで購入金額を変更できるように構成しても良い。
各イベントの積立金額を合計した支払総額が、支払総額欄に表示される。
ライフイベントごとに積立購入金額を設定した場合、総額として顧客の支払い可能な金額を超えてしまう可能性もある。積立購入の場合、毎月支払いが行われるため、ある程度余裕を持った積立金額にしておかなければ、支払いに苦慮するケースが想定される。
従って、顧客はイベント別の積立金額の総額を確認し、OKボタンを押して積立金額を確定することで、上記のような問題を回避できる。
【0165】
<実施形態4(主に請求項1に対応):将来積立情報取得部 購入金融商品確認画面>
図13は、購入金融商品確認画面1300の一例である。
購入金融商品確認画面は、図12のイベント別積立金額確認画面で設定した積立金額に基づいて、どの金融商品をいくら購入するかを確認する画面である。
購入商品欄に、各ライフイベント向けに決定した金融商品ポートフォリオに含まれる金融商品が挙げられている。購入金額欄1301には、ライフイベントごとに選択した金融商品とその購入比率に基づいて算出される購入金額が表示されている。
購入日欄1302には、積立購入する各月の購入日が顧客により指定されるように構成されている。
発注ボタン1303を押すと、証券会社などの金融商品の取り扱い機関に、各金融商品の積立購入が発注される。ID欄は、顧客のログインIDが表示されており、積立購入発注の際に併せて送信される。
以上のようにして設定された、購入金融商品、購入金額、購入日、顧客IDなどの情報は、将来積立情報として取得される。従って、将来にわたって、指定金融商品を一定金額で積立購入することが取得される。
【0166】
<実施形態4(主に請求項4に対応):構成の説明 将来積立情報取得部 積立状況画面>
将来積立情報は、ライフベントごとに目標金額に対して積立の進捗を表示する積立状況画面として構成することができる。
図14は、将来積立情報を表示した場合の積立状況画面の一例を示す図である。
積立状況確認画面1400は、イベント情報表示1401と、金融商品比率円グラフ1402と、積立進捗状況1403と、イベント変更ボタン1404と、終了ボタン1405とで構成されている。
イベント情報表示は、対象のライフイベントや、イベントまでの期間、積立の進捗率などが表示される。金融商品比率円グラフは、積立購入した金融商品ポートフォリオの総額にたいして、各金融商品が何%を占めているかを円グラフで分かり易く表示している。積立進捗状況は、積立を続けた場合の線に対して、現在価格が黒丸で推移が実線で示されており、平均利回りで運用した場合の予測も破線で表示されている。イベント変更ボタンは、他のライフイベントに関わる積立の進捗状況を確認する場合に押す。終了ボタンを押すと、積立状況確認画面を閉じる。
【0167】
<実施形態4(主に請求項4に対応):構成の説明 将来積立情報取得部 積立金額推移画面>
また、将来積立情報は、積立した金額の一生涯の推移として表示するように構成しても良い。
図42は、積立金額推移画面の一例を示す図である。
横軸で年齢の推移を示し、縦軸で金額を示している。左の縦軸は、ライフイベント支出、収入、支出に対応した単年度の金額であり、右の縦軸は、積立資産に対応したその年の累積金額である。ライフイベントの支出を棒グラフで示しており、収入および支出、積立資産の推移を折れ線グラフで示している。
積立資産が示す金額は、1年間で変動するが、グラフに示す値は、その年の最終の時点での金額を示している。
将来積立情報は、将来積立情報取得部で将来収入情報と将来支出情報から求めたものである。図の例では、将来収入情報から将来支出情報を減算した金額から将来的に年間60万円の積み立てが可能であると判断し、月々の積立金額を5万円と設定し、積立を行なった場合の積立資産の推移を計算している。57歳では、将来支出が将来収入を上回っているため、積立は57歳で終了するようにしている。さらに不足金額に関しては、積立資産から取り崩すように計算している。66歳以降は、積立金額を取り崩して生活費に充てていることを示している。
以上図の例で説明したように、将来積立情報取得部によれば、顧客は特に将来の収入や支出を考慮することなく最適な積立金額を設定することができる。
【0168】
<実施形態4(主に請求項4に対応):構成の説明 将来積立情報取得部 積立方法>
積立方法としては、各ライフイベントに対して同時に並列で積み立てていく方法と、直近のライフイベントに対して積立を行っていく方法と二通り考えられる。
また、ライフイベントに対して並行して積立を行った場合、ライフイベント到来後、それまで当該ライフイベントに向けて積み立てていた金額をどうするかについては、そのまま、別名目で積立を行うか、積立を停止するかの二通りが考えられる。
【0169】
<実施形態4(主に請求項4に対応):構成の説明 将来積立情報取得部 積立方法1 並列積立>
図17は、各ライフイベントに対して、並列して積立を行う場合の一例を示している。
イベント1から3に対して、イベント到来時に、目標金額に対して、積立資産が一致するように積立金額を設定している。イベント1が到来した場合に、以降はイベント1に対する積立金額は必要なくなるが、これを老後の備えとして積み立てるように、名目を振り替えている。この場合、購入に関わる金融商品のポートフォリオを変更するようにしても良い。同様にイベント2およびイベント3でも積立金額を老後の備えに転用している。こうすることで、ライフイベントが消化されても資産形成は継続される。
【0170】
<実施形態4(主に請求項4に対応):構成の説明 将来積立情報取得部 積立方法2 直列積立>
図18は、各ライフイベントに対して、直近のライフイベントに対して積立を行う場合の一例を示している。
まずイベント1に向けて見立てが開始される。イベント1が到来しても同じ積立金額で積立を継続するが、イベント2に備えた積立に名目を振り替える。イベント2に向けた積立に対して余剰した金額は、老後の備えとして積立を行うようにする。イベント2およびイベント3が到来した場合は、それぞれ名目が振り替えられて積立を継続している。また、イベント2が到来した時点では、イベント3に必要な資産は確保されているので、その資産からイベント3に必要な金額を引き当てて、積立は老後の備え名目で行うようにしても良い。
ライフイベントに向けた積立方法や、ライフイベント到来後の積立金額の処理方法は、以上述べた以外にも考えられ、顧客の利便性の良い方法が選択されるべきで、上記に限定されるものでは無い。
【0171】
<実施形態4(主に請求項4に対応):制御方法>
以上が、実施形態4の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図31は、実施形態4のライフイベント型金融商品情報出力装置の制御方法を示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態2に従属する実施形態3の制御方法に加えて、将来積立情報取得ステップS3137を有し、将来収入情報取得部で取得した将来収入情報と、将来支出情報取得部で取得した将来支出情報とに基づいて金融商品を購入するための金額である将来積立情報を取得し、将来情報保持部は、将来情報として将来積立情報を保持する制御方法である。
【0172】
<実施形態4(主に請求項4に対応):処理の流れ>
実施形態4のライフイベント型金融商品情報出力装置の制御方法、金融商品情報出力処理に、将来積立情報取得ステップが追加になっている。メイン処理、起動処理、顧客登録処理は実施形態1の処理と同じなので記載は省略している。将来積立情報取得ステップは、将来情報取得ステップS3132の前で、将来収入情報取得ステップS3135と、将来支出情報取得ステップS3136の後に実行され、将来収入と将来支出の差をもとめ、その金額に所定の割合を乗じて将来積立情報を決定する。将来積立情報は、将来情報保持手段に保持される。
【0173】
<実施形態4(主に請求項4に対応):ハードウェア構成>
図32は、実施形態3のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態2を含む実施形態3の構成に加えて、将来積立情報取得プログラム32313を有し、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0174】
<実施形態4(主に請求項4に対応):効果>
本実施形態のライフイベント型金融商品情報出力装置によれば、将来の収入と支出に基づいて、顧客が指定した割合またはライフイベント型金融商品情報出力装置が最適と判断した割合で積立金額が決定されるので、無理のない資産形成計画が立案できる。
【0175】
<実施形態5(主に請求項5に対応)>
<実施形態5(主に請求項5に対応):概要>
実施形態5のライフイベント型金融商品情報出力装置は、将来積立情報取得部で取得した積立金額で、金融商品識別情報選択部で選択した金融商品とその購入比率に基づいて、積立購入した場合の運用益を含む資産の推移を計算するものである。
【0176】
<実施形態5(主に請求項5に対応):構成>
図33は、実施形態5のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図である。
本実施形態のライフイベント型金融商品情報出力装置は、実施形態4の全てを含む構成に加えて、将来資産情報取得部3314を有する。
以降で、各部の構成を説明するが、実施形態4と重複する構成の説明は省略する。
<実施形態5(主に請求項5に対応):構成の説明 将来資産情報取得部>
【0177】
「将来資産情報取得部」3314は、将来収入情報取得部で取得した将来収入情報と、将来支出情報取得部で取得した将来支出情報と、将来積立情報取得部にて取得した将来積立情報と、に基づいて将来の資産の推移を示す情報である将来資産情報を取得する。
将来資産情報取得部は、将来積立情報取得部で取得した積立資産の推移に対して、金融商品識別情報選択部で選択した金融商品とその購入比率に基づいて計算される平均利回りで運用した場合の資産の推移を計算する。資産の推移は、各年齢における資産額を算出する。この計算は、平均利回りの利率を複利として計算するもので、前年度の資産額に対して平均利回りを乗算し、積立金額を加算する。
【0178】
図43は、将来資産情報である運用資産の推移の一例を示す図である。
図42で、説明した積立資産の推移に対して、金融商品識別情報選択部で選択された、金融商品及びその購入比率に基づいて求められる運用利回りで、運用した場合の資産額の推移を示している。図43の例では、実線の折れ線グラフで示される資産運用をしない単純な積立資産に対して、平均利回りを3%として計算した例であり、破線の折れ線グラフで示される運用資産が、計算結果である。図から分かるように、資産運用しなかった場合は、89歳で積立資金が底をついているが、平均的に運用できた場合は100歳時点でも、資産残高があり、老後の生活不安がないことが一目でわかる。
【0179】
<実施形態5:将来資産情報取得部 ライフプランシミュレーション>
将来資産取得部として、ライフプランシミュレーションを行う構成としても良い。
ライフプランシミュレーションは、積立による将来の資産推移を計算することで、資産がマイナスになることは無いか、金融商品で運用した場合にどのような資産推移が見込めるかを計算するものである。
【0180】
図16は、ライフプランシミュレーションの処理の流れの一例である。
先ず、積立金額決定S1601で、各年齢における積立金額の累積金額を算出する。積立金額は、顧客が指定した金額であっても良いし、ライフプランニングサーバまたはアプリが決定した金額でも良い。
【0181】
次に、ライフイベント支出減算S1602で、算出した積立資産から見込ライフイベントの支出予定金額を見込ライフイベントの発生年齢において減算する。これにより、見込ライフイベントにおける支出を考慮した積立資産の推移が求められる。
【0182】
ライフイベント支出減算の結果、積立資産にマイナスが生じるか否かを判定し(S1603)、マイナスが生ない場合にはライフプランシミュレーションを終了するが(S1603でNを選択)、マイナスが生じる場合には、ライフプランシミュレーションの条件見直しを行う。積立資産にマイナスが生じるとは、見込ライフイベントで予定している支出金額に対して、積立資産が不足している状態であり、ライフイベントに対しての備えが十分にできていないと言える。従ってこの場合は、ライフプランシミュレーションの条件を見直して再度行うことが望ましい。
【0183】
条件見直しS1604とは、積立資産がマイナスになることが無いように、積立金額を増やすか、マイナスが生じる見込ライフイベントでの発生費用を変更するかのどちらかである。積立金額を増やす場合は、積立可能金額の何パーセントを積立に回すかの割合を変更することが考えられる。この場合、ライフプランシミュレーションは、マイナス額から見込ライフイベントが発生するまでの期間を用いて、積立額をどれだけ増やせばよいかを算出して顧客にアドバイスするようにしても良い。また、見込ライフイベントでの支出額を見直す場合はいくら減額すれば良いか、見込ライフイベントの時期をどの程度遅らせれば良いかをアドバイスするようにしても良い。また、積立の増額と、見込ライフイベントの支出の見直しとを組み合わせてアドバイスするようにしても良い。さらに、運用により運用益が出た場合は、見込ライフイベントでの支出額の減額を補える可能性があることを示唆するようにしても良い。
【0184】
以上述べてきたように、ライフプランシミュレーションにより、見込まれるライフイベントに備えるために、月々の積立金額はいくら必要か、それで備えが十分できているかなどを確認することができる。
【0185】
ライフプランシミュレーションは、少なくとも、見込ライフイベントに備えるために顧客が指定した積立金額で積み立てた場合の積立資産と、見込ライフイベントで予定している支出額を積立資産から取り崩した場合の資産の推移を示す情報を取得するものである。例えば、図7の見込ライフイベント一覧画面で、見込ライフイベントの内容が確認され、シミュレーションボタンが押されたら実施されるように構成することが考えられる。
これにより、積立資産がマイナスにならなければ、見込ライフイベントに対する備えが出来ており、見込ライフイベント発生時に借入をする必要が無いことを把握できる。
【0186】
<実施形態5(主に請求項5に対応):制御方法>
以上が、実施形態5の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図34は、実施形態5のライフイベント型金融商品情報出力装置の制御方法を示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力装置の制御方法は、実施形態2から実施形態4すべての制御方法に加えて、将来資産情報取得ステップS3438を有し、将来積立情報取得部で取得した将来積立情報を、金融商品識別情報選択部で選択した金融商品識別情報で示される金融商品で運用した場合の資産の推移である将来資産情報を取得し、将来情報保持ステップで不揮発性メモリに保持する。
【0187】
<実施形態5(主に請求項5に対応):処理の流れ>
本実施形態5のライフイベント型金融商品情報出力装置の制御方法は、実施形態2から実施形態4のすべての構成に加えて、金融商品情報出力処理に、将来資産情報取得ステップが追加になっている。将来資産情報取得ステップは、将来積立情報取得ステップで取得した将来積立情報と、金融商品識別情報選択ステップで選択した金融商品で運用した場合の運用資産を算出する。算出した将来資産情報は、将来情報保持ステップで保持される。
【0188】
<実施形態5(主に請求項5に対応):ハードウェア構成>
図35は、実施形態5のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態2から実施形態4のすべての構成に加えて、将来資産情報取得プログラム35314を有し、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0189】
<実施形態5(主に請求項5に対応):効果>
以上述べてきたように、実施形態5のライフイベント型金融商品情報出力装置によれば、将来の資産の状況を把握することが出来るので、例えば、老後何歳くらいまで資産が残るかなどが把握でき、老後の安心が得られたり、老後に備えた資産形成を計画したりすることなどが可能になる。
【0190】
<実施形態6(主に請求項6に対応)>
<実施形態6(主に請求項6に対応):概要>
本実施形態のライフイベント型金融商品情報出力装置は、公的制度識別情報保持部と、公的制度識別情報取得部を有して将来収入情報取得部での将来収入情報の取得に際して、顧客が今後享受する可能性がある公的制度による収入を含めて将来収入として算出する。これにより将来収入情報は所得収入だけではなく、公的な給付金等も含めた収入も含み、これを考慮した資産形成が可能になる。
【0191】
<実施形態6(主に請求項6に対応):構成>
図36は、実施形態6のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図である。
本実施形態のライフイベント型金融商品情報出力装置は、実施形態2から実施形態5のいずれか一の構成に加えて、公的制度識別情報保持部3616と、公的制度識別情報取得部3615と、をさらに有する。
以降で、各部の構成を説明するが、実施形態2から実施形態5と重複する構成の説明は省略する。
【0192】
<実施形態6(主に請求項6に対応):構成の説明 公的制度識別情報保持部>
「公的制度識別情報保持部」3616は、助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持する。
公的制度識別情報保持部は、収入に関わる公的制度を唯一に特定するためのIDコード情報などである公的制度識別情報を有し、該当する公的制度に関わる情報を関連付けて保持する。この情報は、不揮発性メモリに保持する。
【0193】
収入に関わる公的制度とは、例えば児童手当、児童扶養手当、出産育児一時金、出産手当、育児休業給付金などがある。児童手当は子供を持つ世帯に対して、所定の金額が支給される制度である。従って、顧客属性情報から子供を持つ場合、将来収入額に児童手当の給付額を加算して考慮する。これにより、積立可能金額が増え積立金額を増額することができる。
この他にも、年金や税金の控除などを将来収入情報に追加して考慮する。例えば、年金であれば加給年金を考慮したり、税金の控除であれば住宅ローン減税などを考慮しその収入金額を将来収入に加算する。
【0194】
以上の様な公的制度は、将来的には変更される可能性がある。こうしたことから、公的制度による収入がいくら含まれているか、またその金額は、変化する可能性があることを顧客に周知されるように構成することが望ましい。また、公的制度識別情報に関連付けられる公的制度に関わる情報は定期的に更新されるべきであり、これによる変更があった場合は、積立金額に関わる将来積立情報を更新して、積立金額を変更することが望ましい。
また、公的制度とは上記したものに限定するものではなく、新しく収入に関わる制度が実施された場合には、その制度も含まれる。
【0195】
<実施形態6(主に請求項6に対応):構成の説明 公的制度識別情報取得部>
「公的制度識別情報取得部」3615は、顧客識別情報で識別される顧客が今後享受する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得する。
公的制度識別情報取得部は、顧客識別情報に基づいて、公的制度識別情報保持部に保持された公的制度情報から、顧客が対象となる公的制度識別情報を抽出し、それに関連付けられて保持されている公的制度の情報を用いて、顧客の将来収入となる金額を算出する。
【0196】
例えば、顧客属性情報より、顧客が子供を持つ場合、現行制度では、中学校卒業までは児童手当が支給される。これは、例えば、3歳未満までは1万5千円でそれ以降は、1万円が月額で支給される。この金額の支給期間を顧客の年齢に割り付けて将来収入情報として取得する。
また、顧客属性情報より、厚生年金加入者で扶養対象の配偶者がいる場合、顧客年金支給年齢において、加給年金を受給できる場合がある。このような場合も、年金支給年齢以降の将来収入情報として、該当する支給期間を顧客の年齢に割り付けて将来収入情報として取得する。
【0197】
<実施形態6(主に請求項6に対応):制御方法>
以上が、実施形態6の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図37は、実施形態6のライフイベント型金融商品情報出力装置の制御方法の処理の流れを示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態2から実施形態5のいずれか一の制御方法に加えて、実施形態公的制度識別情報保持ステップS3714と、公的制度識別情報取得ステップS3739とをさらに有し、実施形態公的制度識別情報保持ステップで、助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持し、公的制度識別情報取得ステップで、顧客識別情報で識別される顧客が今後享受する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得し、将来収入情報取得部は、見込公的制度識別情報に基づいて将来収入情報を取得する制御方法である。各ステップの機能は、構成で説明した内容と同じである。
【0198】
<実施形態6(主に請求項6に対応):処理の流れ>
実施形態6のライフイベント型金融商品情報出力装置の制御方法は、起動処理に、公的制度識別情報保持ステップをさらに有し、金融商品情報出力処理に、公的制度識別情報取得ステップをさらに有する。起動処理で、公的制度識別情報保持ステップを実施し、公的制度識別情報と公的制度に関わる情報を関連付けて不揮発性メモリに保持する。金融商品情報出力処理では、公的制度識別情報取得ステップで、顧客に将来的に見込まれる公的制度識別情報とそれに関連付けられた公的制度に関わる情報を取得し、公的制度に基づく収入を算出する。
算出した収入は、将来収入情報取得ステップで将来収入情報に加算する。
【0199】
<実施形態6(主に請求項6に対応):ハードウェア構成>
図38は、実施形態6のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態2から実施形態5のいずれか一の構成に加えて、実施形態公的制度識別情報保持プログラム38316と、公的制度識別情報取得プログラム38315と、をさらに有する。
適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0200】
<実施形態6(主に請求項6に対応):効果>
本実施形態によれば、公的制度に基づいた給付金や還付金なども収入として自動的に計算され将来情報に反映されるので、顧客は、特に意識する必要なく、最適な積立金額を計画できる。また、給付金等は、申請しないともらえないものなので、知らずにもらいそびれるといった問題も無くなる。
【0201】
<実施形態7(主に請求項7に対応)>
<実施形態7(主に請求項7に対応):概要>
本実施形態のライフイベント型金融商品情報出力装置は、将来支出情報取得部での将来支出情報の取得に際して、顧客が今後支払わなければならない可能性がある公的制度による支出を含めて将来支出として算出する。これにより将来支出情報は家計支出など消費による支出だけではなく、税金等も含めた支出も含み、これを考慮した資産形成が可能になる。
【0202】
<実施形態7(主に請求項7に対応):構成>
図39は、実施形態7のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図である。
本実施形態のライフイベント型金融商品情報出力装置は、実施形態2から実施形態6いずれか一の構成に加えて、公的制度識別情報保持部3916と、公的制度識別情報取得部3915を有する。
以降で、各部の構成を説明するが、実施形態3から実施形態6と重複する構成の説明は省略する。
【0203】
<実施形態7(主に請求項7に対応):構成の説明 公的制度識別情報保持部>
「公的制度識別情報保持部」3916は、助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持する。
本実施形態の公的制度識別情報保持部は、実施形態6とは異なり、支出に関わる公的制度を唯一に特定するためのIDコード情報などである公的制度識別情報を有し、該当する公的制度に関わる情報を関連付けて保持する。この情報は、不揮発性メモリに保持する。
【0204】
支出に関わる公的制度とは、税金等の支出がある。具体的には、積立資産の取り崩しを行う場合、資産の評価額に利益がある場合その利益部分に対して、所定の割合で税金の納付が必要になる。例えば積立資産が1000万円ありこのうち運用による利益が250万円であったとすると、この積立資産から、100万円取り崩しを行う場合、25万円が運用益として扱われ、税率が20%とすると5万円の税支出が必要になる。
【0205】
また、退職金を年金として受け取る場合や、確定拠出年金を受け取る場合は、雑所得として課税対象となる。従って、控除額を超える金額の給付を受けた場合は納税義務が生じる。この他にも、不動産の貸出など給与所得以外の収入がある場合は納税が必要になる。また、退職後の初年度は、前年度所得に対して住民税が課税されるため、大きな支出となる場合がある。
以上の様な税支出に関わる情報を、公的制度識別情報保持部で不揮発性メモリに保持するようにする。なお、公的制度は税制改正や政府の方針により変更になる場合もあるので定期的に更新されることが望ましい。公的制度識別情報と関連付けて公的制度に関する属性情報が保持されていることが好ましい。これは公的制度情報保持部が担う。そしてこの属性情報としては主に給付金に関する情報を保持し、各顧客に対して将来時系列に公的給付がどの程度されるかについての情報であることが好ましい。なお、これは外部装置に蓄積され、公的制度識別情報をキーとして取得できるように構成されていてもよい。
<実施形態7(主に請求項7に対応):構成の説明 公的制度識別情報取得部>
【0206】
「公的制度識別情報取得部」3915は、顧客識別情報で識別される顧客が今後享受する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得する。
本実施形態では、公的制度識別情報取得部は、顧客識別情報から顧客が今後支払わなければならないと見込まれる税金等に関わる情報を、公的制度識別情報保持部から取得し、将来支出情報取得部で将来支出情報に加算する。
【0207】
例えば、60歳で退職し65歳まで再雇用で働き続けたとすると、66歳において年金収入のみとなったとしても、65歳時の所得に基づいた住民税が課税される。支出としては大きな額となるため、将来支出情報として予め加算しておくことが望ましい。
また、子供が20歳を超えても学生で収入がない場合、子供の年金を負担する必要が生じる場合もある。この場合も、子供の国民年金納入金額を将来支出情報として加算することが望ましい。
【0208】
<実施形態7(主に請求項7に対応):制御方法>
以上が、実施形態7の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図40は、実施形態7のライフイベント型金融商品情報出力装置の制御方法の処理の流れを示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態3から実施形態6のいずれか一の制御方法に加えて、公的制度識別情報保持ステップS4014と、公的制度識別情報取得ステップS4039とをさらに有し、公的制度識別情報保持ステップで、助成金、補助金、年金、税金の所得控除などのいずれか一以上からなる公的制度を識別する公的制度識別情報を保持し、公的制度識別情報取得ステップで、顧客識別情報で識別される顧客に対して今後義務が発生する可能性がある公的制度を識別する見込公的制度識別情報を公的制度識別情報保持部から取得し、将来支出情報取得部は、見込公的制度識別情報に基づいて将来支出情報を取得する制御方法である。各ステップの機能は、構成で説明した内容と同じである。
【0209】
<実施形態7(主に請求項7に対応):処理の流れ>
施形態7のライフイベント型金融商品情報出力装置は、起動処理に、公的制度識別情報保持ステップS4014を、金融商品情報出力処理に、公的制度識別情報取得ステップS4039をさらに有している。
起動処理で、公的制度識別情報保持ステップを実施し、公的制度識別情報と公的制度に関わる情報を関連付けて不揮発性メモリに保持する。
金融商品情報出力処理では、公的制度識別情報取得ステップで、顧客に将来的に見込まれる公的制度識別情報とそれに関連付けられた公的制度に関わる情報を取得し、公的制度に基づく支出を算出する。
算出した支出は、将来支出情報取得ステップで将来支出情報に加算する。
【0210】
<実施形態7(主に請求項7に対応):ハードウェア構成>
図41は、実施形態7のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態3から実施形態6のいずれか一の構成に加えて、公的制度識別情報保持プログラム41316と、公的制度識別情報取得プログラム41315と、をさらに有する。適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0211】
<実施形態7(主に請求項7に対応):効果>
本実施形態によれば、税金等の将来的な支払い義務の生じる可能性のあるものが、前もって抽出できるので、計画していなくていきなり大きな出費を余儀なくされるなどといったことを防止できる。
また、公的な支払いも含めて積立金額の設定ができるので、最適なライフプランが行える。
【0212】
<実施形態8(主に請求項8に対応):概要>
実施形態8のライフイベント型金融商品情報出力装置は、顧客の支出に関わる情報を、家計簿機能を持つアプリケーションから取得し、顧客の将来の支出を推定する。これにより、実際の顧客の生活支出に基づいた最適な積立金額を提案する。
【0213】
<実施形態8(主に請求項8に対応):構成>
図44は、実施形態8のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図であり、実施形態3から実施形態7のいずれか一の構成に加えて、家計情報取得部4417をさらに有する。
以降で、各部の構成を説明するが、重複する構成の説明は省略する。
【0214】
<実施形態8(主に請求項8に対応):構成の説明 家計情報取得部>
「家計情報取得部」4417は、日々の衣食住に関わる支出である家計情報を取得する。
「家計情報」とは、食費、衣料費、住居費などの月々の出費に関わる情報であり、携帯電話やデータ通信のための通信費や、塾や習い事などの教育費、保険料の支払い、ローンの支払い、交際費、通勤や通学のための交通費など月々の決まった支払いなども含まれる。
また、給与所得やボーナス所得などの収入の情報を含んでいても良い。
家計情報取得部は、顧客の日々の出費に関わる情報の入力を蓄積し、月々の支出金額を算出する。
算出された支出金額は、将来支出取得部で将来支出の算出に使用する。また、出費の目的等を分析し、一般的な支出金額や平均支出金額と比較して、出費に関するアドバイスを行う機能を実装しても良い。具体的には、食費の比率が世間一般の平均よりも大きい場合は、食費にかかりすぎであることをアドバイスしたり、通信費が高い場合には、もっと安価なプランで支出の圧縮ができるように提案したりしても良い。抑えた支出は、積立金額の増額を提案するようにしても良い。
【0215】
家計情報取得部は、家計簿機能を有するアプリとして提供されることが考えられる。また、そのような家計簿アプリと連携して必要な情報を取得するようにしても良い。
家計簿アプリは、ライフイベント型金融商品情報出力装置の一実施形態であるライフプランニングアプリに組み込まれた機能として提供されても良い。この場合、一例として図4Bに示すようなメインメニュー画面から家計簿ボタン0414が押されたら起動するように構成されることが考えられる。また、別の構成として、家計簿アプリは、ライフプランニングアプリとは別アプリとして提供され、家計簿アプリから家計支出に関わる家計情報を取得するようにしても良い。
【0216】
図47は、家計簿アプリとして実装された場合のインタフェース画面の一例である。
本日の支出出力画面4710は、日々起動し、顧客にその日の支出金額を入力するように促す構成が考えられる。名目欄4711は、食費や衣料費など出費に関わる名目が記載されており、金額欄4712に名目に対応する支出金額を入力するように構成されている。名目欄に無い支出に関しては、その他の欄に、例えばプルダウンメニューの様な構成で支出名目を入力するようにしても良い。
本日の支出の入力が終わると、月の最終日の場合は、今月の収支入力画面4720を起動しその月の収入や支出の入力を、顧客に促すように構成しても良い。ここでの入力は、給与所得や、電話代などの通信費、住居費、塾の月謝などの教育費など月ごとに請求される内容を入力するようにすれば良い。
日々の入力は、月末まで保持しておき、今月の収支の入力が終わった段階で、日々の支出入力の累積金額と、今月の収支入力画面で入力された支出を合算してその月の全支出を算出する。
【0217】
その月の全支出が算出できたら、家計の分析を行うようにしても良い。
家計の分析とは、支出の名目に対する支出額の比率を分析することが考えられる。
支出名目欄4731に、支出名目があり支出金額欄4732に対応する支出金額が表示されている。円グラフ4733は支出名目に対する支出金額の比率を示している。
さらに、図に示したように収入金額も入力されていれば、収入と支出の関係が明確になり、余剰金額がどの程度あるかを一目で把握できる。この余剰金額は、積立可能金額として考えることができる。従ってこの情報に基づいて、将来積立金額取得部で、積立金額を決定するようにしても良い。
このように、支出を分析した結果をグラフなどで分かり易く表示することで、顧客は収支状況を把握できる。
【0218】
なお、支出金額の入力は、顧客の入力操作による入力だけに限らない。例えば、 支出に関わるレシートや領収書をカメラで撮影し、その画像から支出名目や支出金額を読み取るようにしても良い。また顧客の音声による入力によっても構わない。またキャッシュレス決済をしている場合は、その利用履歴から支出に関わる情報を取得するようにすることも考えられる。なお、家計情報に基づいて将来支出情報を取得するために将来支出情報取得ルールを保持するように構成し、そのルールに基づいて将来支出情報を取得するように構成することが考えられる。このルールは複数種類用意しておき、その顧客の顧客属性情報や、その顧客のこれまでの家計情報の履歴に基づいて将来支出情報を取得するルールを選択できるように構成することもできる。顧客に応じて将来支出の傾向に一定の癖があると考えられるからである。また、家計情報は日々更新されるものであるので、日々そのルールに基づいて将来支出情報を更新してもよいし、所定間隔で、例えば1か月おきに更新するように設計してもよい。
【0219】
<実施形態8(主に請求項8に対応):制御方法>
以上が、実施形態8の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図45は、実施形態8のライフイベント型金融商品情報出力装置の処理の流れを示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態3から実施形態7のいずれか一の制御方法に加えて、家計情報取得ステップ4540をさらに有する。
【0220】
<実施形態8(主に請求項8に対応):処理の流れ>
実施形態8のライフイベント型金融商品情報出力装置は、金融商品出力処理に家計情報取得ステップ4540をさらに有する。家計情報取得ステップは、顧客が日々入力した、家計情報を取得し、月々の支出金額を、将来支出情報取得部4536に出力する。将来支出情報取得部は、取得した月々の支出金額の実績に基づいて、将来の支出金額を取得する。以降の処理に関しては、これまで述べてきた実施形態と同じである。
【0221】
<実施形態8(主に請求項8に対応):ハードウェア構成>
図46は、実施形態8のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態3から実施形態7のいずれか一の構成に加えて、家計情報取得プログラム46317をさらに有する。適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0222】
<実施形態8(主に請求項8に対応):効果>
実施形態8のライフイベント型金融商品情報出力装置によれば、顧客が入力した日々の家計支出から将来の家計支出を推定するので、顧客の実際の生活状況に従った積立金額の設定などが可能になる。
【0223】
<実施形態9(主に請求項9に対応):概要>
実施形態9のライフイベント型金融商品情報出力装置は、顧客に見込ライフイベントの発生時期が到来した場合に、顧客に見込ライフイベントが実際に発生したか否かの履行状況を確認し、その状況に応じて新たな金融商品のポートフォリオを提案する。
【0224】
<実施形態9(主に請求項9に対応):構成>
図48は、実施形態9のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図であり、実施形態1から実施形態8のいずれか一の構成に加えて、見込ライフイベント履行状況取得部4818をさらに有する。以降で、各部の構成を説明するが、重複する構成の説明は省略する。
【0225】
<実施形態9(主に請求項9に対応):構成の説明 見込ライフイベント履行状況取得部>
「見込ライフイベント履行状況取得部」4818は、見込ライフイベント識別情報に含まれるライフイベント発生時に、ライフイベントの履行状況を確認する。将来情報保持部は、見込みライフイベント履行状況取得部の取得結果に基づいて、保持している将来情報の内容を更新する。
【0226】
見込ライフイベント履行状況取得部は、直近の見込ライフイベントの発生時期が到来したかを確認する。見込ライフイベントの発生時期が到来した場合には、顧客に対して、見込ライフイベントが発生したか否かを確認する通知を行う。この通知はアプリから、顧客が使用する携帯端末への通知であったり、メールによる通知であったりしても良い。これは、ライフイベントによっては必ず発生するわけでは無いため確認が必要になるからである。例えば、子供が学校に入学した場合は、卒業が到来する年齢はほぼ決まっているが、結婚などの予定に関しては実際に発生するとは限らない。予定が遅れる場合もあれば、そもそもライフイベントが発生しない可能性もあるためである。
【0227】
顧客の回答により得られた、見込ライフイベントの履行状況に応じて、新たに金融商品を出力するようにする。
見込ライフイベントの発生時期が遅れた場合は、そのまま積み立てを継続し、ライフイベントの発生時期を更新するようにすることが考えられる。見込みライフイベントが発生しなかった場合には、予定していた支出金額が取り崩されないため積立金額に余裕ができる。この場合は、利回りの高いポートフォリオで運用するなどの提案をしても良い。見込みライフイベントが実施されている場合は、積立資産の取り崩し金額を確認し 、残りの資産と今後の見込みライフイベントから、新たに金融商品のポートフォリオを提案するようにすれば良い。
【0228】
図52は、見込ライフイベント履行確認通知5200の一例である。
図のように、見込ライフイベントが実施されたかを確認するメッセージを表示し、Yesボタン5201またはNoボタン5202で履行状況を確認するようにしている。確認通知はこれに限定されるものではなく、音声による対話入力や、積立資産の取り崩し状況で判断するようにすることも考えられる。
【0229】
図51は、見込ライフイベント履行状況取得部が行う顧客との対話の一例を示す図である。
図は子供の大学入学のライフイベントの確認の一例である。
まず、ライフイベント型金融商品情報出力装置から、子供の大学入学が実施されたかを確認するメッセージを出力し、顧客がはいと回答している(5101)。次に、積立資産を取り崩すか否かの確認を行い、顧客がはいと回答している(5102)。次に、積立金融商品を見直すかの確認を行い、顧客がはいと回答している(5103)。次に、ライフイベント型金融商品出力装置は、金融商品のポートフォリオを新たに出力する(5104)。顧客が提案を受けた金融商品の積立を了承した場合はライフイベント型金融商品出力装置は金融商品の積立購入の発注を行う(5105)。
このようにライフイベント型金融商品出力装置は、顧客の見込ライフイベントの履行状況を確認して積立資産の状況により新たな金融商品を提案する。
【0230】
<実施形態9(主に請求項9に対応):構成の説明 見込ライフイベント履行状況取得部 積立状況画面(満期時)>
ライフイベント履行状況確認の際に、積立状況画面を表示するようにしても良い。
図15は、ライフイベントが到来した際の積立状況を表示する積立状況画面の一例である。
積立状況確認画面1500は、ライフイベント情報1501と、金融商品比率円グラフ1502と、積立状況1503と、履行状況入力ボタン1504と、終了ボタン1505とで構成されている。
履行状況入力ボタンは、履行状況の入力に移行するボタンである。履行状況の入力とは、ライフイベントを履行したか、積立金融商品を売却して取り崩すか、不足がある場合はどこから充当するか、余剰金がある場合はどのように処理するかなどを指定する。
その他構成は、図14と同じなので各部の説明は、省略する。図の例の様に、イベントが到来してからの積立状況の表示であるため、目標金額に対して進捗がどうかを確認できる。図の例では、運用成績が目論見通りに進んだため、目標金額に対して10%の利益がでている。
【0231】
この積立状況確認画面に基づいて、顧客はいくら取り崩すか、余りが生じた場合にはどうするか、不足が生じている場合にはどこから充当するかを検討することができる。
【0232】
<実施形態9(主に請求項9に対応):制御方法>
以上が、実施形態9の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図49は、実施形態9のライフイベント型金融商品情報出力装置の制御方法の処理の流れを示すフローチャートである
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態1から実施形態8のいずれか一の制御方法に加えて、見込ライフイベント履行状況取得ステップS4905をさらに有する。
【0233】
<実施形態9(主に請求項9に対応):処理の流れ>
実施形態9のライフイベント型金融商品情報出力装置の制御方法は、実施形態1から実施形態8のいずれか一の処理に加えて、メイン処理に、見込ライフイベント到来判定S4904と見込ライフイベント履行状況確認処理S4905が追加されている。
見込ライフイベント履行状況確認処理は、見込ライフイベント履行状況取得ステップS4951と、履行済判定S4952と、延期判定S4953と、将来情報更新ステップと、金融商品識別情報選択ステップS4955と、金融商品識別情報選択ステップS4956とを有する。
メイン処理で、顧客の見込ライフイベントが到来したと判定した場合は(S4904でYを選択)、見込ライフイベント履行状況確認処理を行う。顧客の見込ライフイベントが到来していない場合は、終了判定S4903に移行する。
見込ライフイベント履行状況確認処理は、先ず、見込ライフイベント履行状況取得ステップで、見込ライフイベントが履行されたか否か、また履行していないが、時期を延期したかを取得する。
履行済判定で履行済と判定された場合は(S4952でYを選択)、将来情報更新ステップに移行し、履行していないと判定された場合は(S4952でNを選択)、延期判定に移行する。延期判定で延期ではないと判定された場合は(S4953でNを選択)、将来情報更新ステップに移行し、延期されたと判定された場合は(S4953でYを選択)、処理を終了する。
将来情報更新ステップでは、見込ライフイベントでの支出を減算して(見込ライフイベントが無かった場合はそのまま)、将来情報を更新する。その後、その時点での積立資産の残高を含めて以降の見込ライフイベントに備えた金融商品を選択する。金融商品識別情報出力ステップでは、選択した金融商品の識別情報と、その積立購入金額とを関連付けて出力する。
【0234】
<実施形態9(主に請求項9に対応):ハードウェア構成>
図50は、実施形態9のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態1から実施形態8のいずれか一の構成に加えて、見込ライフイベント履行状況取得プログラム50318をさらに有する。適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
<実施形態9(主に請求項9に対応):効果>
実施形態9のライフイベント型金融商品情報出力装置によれば、顧客に見込ライフイベントが到来した場合に、その履行状況を確認し、その後の見込ライフイベントに備えて新たな金融商品のポートフォリオを提案するので、顧客のライフイベントの履行状況や資産残高に応じて最適な投資計画に変更できる。
【0235】
<実施形態10(主に請求項10に対応):概要>
実施形態10のライフイベント型金融商品情報出力装置は、ライフイベント関連情報保持部に保持された、ライフイベントに関連する情報から、顧客の見込ライフイベントに該当し、顧客が情報の提供を要求した場合に、ライフイベント関連情報提供部が、該当するライフイベント関連情報を、ライフイベント関連情報保持部から取得し、顧客に対して、視認できる形式で提供する。
【0236】
<実施形態10(主に請求項10に対応):構成>
図53は、実施形態10のライフイベント型金融商品出力装置の機能の構成を示すブロック図である。
本実施形態のライフイベント型金融商品情報出力装置は、実施形態1から実施形態9のいずれか一の構成に加えて、ライフイベント関連情報保持部5318と、ライフイベント関連情報提供部5319とをさらに有する。
以降で、各部の構成を説明するが、重複する構成の説明は省略する。
【0237】
<実施形態10(主に請求項10に対応):構成の説明 ライフイベント関連情報保持部>
「ライフイベント関連情報保持部」5318は、ライフイベント識別情報に関連付けて、ライフイベントに関わる、平均的な金額、最低必要金額、上限金額、路線価、公示地価、税制情報、助成金情報等のいずれか一以上の情報を含むライフイベント関連情報を保持する。
ライフイベント関連情報保持部は、不揮発性メモリ上にライフイベント関連情報を保持するように構成することが考えられる。この不揮発性メモリ上に保持されたライフイベント関連情報をメインメモリのデータ領域にロードするようにしても良い。また、ライフイベント関連情報は、別体となったサーバ上に保持され、ネットワーク経由でライフイベント関連情報を取得して、メインメモリ上に保持する構成も考えられる。ライフイベント関連情報はどこに保持されても良いが、必要に応じてメインメモリ上にロードされていれば良い。
【0238】
<実施形態10(主に請求項10に対応):構成の説明 ライフイベント関連情報提供部>
「ライフイベント関連情報提供部」5319は、顧客の要求に基づいて、ライフイベント関連情報を出力する。
ライフイベント関連情報提供部は、顧客が要求したライフイベント関連情報を、ライフイベント関連情報取得部から取得し、文字情報として、スマートフォンなどの顧客の通信端末に表示するようにする構成が考えられる。また、情報は、表示に限らず、音声での出力であっても良い。ライフイベント関連情報保持部は、顧客が操作する通信端末内のアプリの一部として構成されていても良いし、ライフイベント型金融商品出力装置内に保持されネットワーク経由で取得する構成であっても構わない。
【0239】
図56は、ライフイベント関連情報提供部により顧客に提供されるライフイベント関連情報の表示の一例である。図4Bのメインメニューにおいて、ライフイベント情報ボタン0413が押された場合に表示させることが考えられる。図の例では、ライフイベントに関わるすべての情報にアクセス可能なように構成されている。ライフイベントに関わる情報としては、例えば、制度、税制、金融・経済、ライフイベント費用、キャッシュフロー、商品、必要書類の見方、法人などのカテゴリーに分けられるようにしてもよい。「制度」では、年金や、医療、介護などの分類に分けられ、例えば年金では、年金制度の仕組みなどの基本的な内容から、繰上げ・繰下げや任意加入制度など、実際の給付を受ける場合にどうすべきかなどの情報も含まれている。税制では、所得税の区分や、所得控除など実際に確定申告する場合や、還付を受けるための情報等が含まれていることが考えられる。
以上の様に、顧客にライフイベントに関わる情報を提供することで、顧客は、ライフイベントの際に戸惑うことなく対応が可能になる。
以上の様な情報は、図56のようなメニュー画面で探すようにしても良いが、例えば、図7のライフイベントを入力する段階で、ライフイベントを選択すると、ライフイベント費用に区分される情報の中から該当するライフイベントの関連情報が取得されるようにしても良い。
【0240】
<実施形態10(主に請求項10に対応):制御方法>
以上が、実施形態10の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図54は、実施形態10のライフイベント型金融商品情報出力装置の制御方法の処理の流れを示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態1から実施形態9のいずれか一の制御方法に加えて、ライフイベント関連情報保持ステップS5415と、ライフイベント関連情報提供ステップS5405とをさらに有する。
【0241】
<実施形態10(主に請求項10に対応):処理の流れ>
実施形態10のライフイベント型金融商品情報出力装置の制御方法は、メイン処理に、ライフイベント関連情報提供要求判定S5404と、ライフイベント関連情報提供ステップS5405をさらに有し、起動処理にライフイベント関連情報保持ステップS5415をさらに有する。起動処理では、ライフイベント関連情報保持ステップにより、ライフイベント関連情報をメインメモリ上のデータ領域にロードする。その後、メイン処理において、顧客からライフイベント関連情報の提供要求があったと判定した場合は(S5404でYを選択)、ライフイベント関連情報提供ステップを実施する。ライフイベント関連情報提供ステップでは、メインメモリ上のデータ領域にロードされたライフイベント関連情報の中から、顧客が要求したライフイベント関連情報を取得し、顧客が視認できるように出力する。
【0242】
<実施形態10(主に請求項10に対応):ハードウェア構成>
図55は、実施形態10のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態1から実施形態9のいずれか一の構成に加えて、ライフイベント関連情報保持プログラム55319と、ライフイベント関連情報提供プログラム55320とをさらに有し、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0243】
<実施形態10(主に請求項10に対応):効果>
以上述べてきたように、実施形態10のライフイベント型金融商品情報出力装置によれば、ライフイベントに必要な支出金額の情報や、ライフイベントに関する様々な情報を入手できるので、事前にライフイベントに対して勉強し、準備することができる。
【0244】
<実施形態11(主に請求項11に対応):概要>
実施形態11のライフイベント型金融商品情報出力装置は、実施形態1から実施形態10のいずれか一を基本として、以下の特徴を有する。
実施形態11のライフイベント型金融商品情報出力装置の顧客属性情報取得部は、顧客近親者情報取得手段で、顧客の生計を同一にしない近親者(例えば、顧客の両親、祖父母、配偶者の両親、祖父母、別居している子供と孫)の情報を取得し、顧客属性情報保持部の顧客近親者情報保持手段に保持するようにする。見込ライフイベント入力受付部では、顧客の両親や祖父母の介護、孫の七五三や成人式など生計を同一にしていない親族の関わるライフイベントも含めてライフプランを計画できる。
【0245】
<実施形態11(主に請求項11に対応):構成>
図57は、実施形態11のライフイベント型金融商品情報出力装置の構成を示すブロック図であり、実施形態1から実施形態10のいずれか一の構成に加えて、顧客属性情報取得部5701に、顧客近親者情報取得手段57011を含み、顧客属性情報保持部5703に、顧客近親者情報保持手段57031を含む。以降で、各部の構成を説明するが、重複する構成の説明は省略する。
【0246】
<実施形態11(主に請求項11に対応):顧客属性情報取得部 顧客近親者情報取得手段>
「顧客近親者情報取得手段」57011は、顧客属性情報取得部に含まれ、顧客の近親者の情報である顧客近親者情報(例えば親の年齢を含む情報、子供の情報(子供の年齢を含むとなおよい。))を取得する。
顧客近親者情報取得手段は 、生計を同一としない親族(例えば、顧客の両親、配偶者の両親、顧客の同居していない子供及び孫など)の情報を取得する。
例えば、ユーザインタフェースとしてアプリの画面に、家系図を表示し対象の親族の生年月日などの情報を入力する方法が考えられる。この取得した親族の情報に基づいて、見込ライフイベント入力受付部に、親の介護や、孫の七五三、結婚式など親族に関わるライフイベントの情報を入力するように構成することが考えられる。これにより、生計を同一としない親族に関わるライフイベントを含めたライフプランが可能になる。
また、近親者情報は現在存在する近親者に限らず、予定する家族について入力するようにしてもよい。これは例えば、まだ結婚をしていない顧客が、将来結婚して子供を設けた場合のライフプランをシミュレーションするための方法として考えられる。
【0247】
ここで、介護費用に関して簡単に説明する。
例えば、一例として、在宅での介護費用は、公益財団法人生命保険文化センターの行った平成30年度「生命保険に関する全国実態調査」によると、費用の平均は1ヶ月当たり7.8万円で近年は横ばい傾向で推移している。老人ホームに入居した場合は特別養護老人ホームで月6~15万円くらいである。一方で有料の老人ホームは10~50万円と幅が広い。このような介護費用は、いつまで続くかわからず、親自身が負担できなかった場合は、子供に大きな負担がかかるリスクがある。こうしたことから、親の介護費用の負担リスクを考慮したライフプランも重要となってくる。
【0248】
図60は、顧客近親者情報取得手段を含む顧客属性情報取得部を、ユーザインタフェースとして構成した場合の一例を示す図である。図に示すように家族情報入力画面6000では、顧客本人に繋がる家系図が 示されており、顧客本人の両親、配偶者の両親、の情報が入力可能となっている。この図では顧客が30歳の時に顧客属性情報の入力を行っているものと想定している。ここで、家族情報入力6003で配偶者の情報は、既婚または予定のチェックボックスがあり、図の例では予定で35歳となっているため、まだ結婚していないが5年後に結婚するものとしてライフプランのシミュレーションを行う想定である。以上の様にまだいない家族などを設定することで、未婚の若者や結婚予定のカップルなど、具体的な将来像を想定しながらライフプランニングが行える。
【0249】
<実施形態11(主に請求項11に対応):顧客属性情報保持部 顧客近親者情報保持手段>
「顧客近親者情報保持手段」57031は、顧客属性情報保持部に含まれ、顧客近親者情報取得手段で取得した顧客近親者情報を保持する。
近親者情報保持手段は、近親者情報取得手段により取得された近親者情報は、顧客識別情報に関連付けられ、顧客属性情報とともに不揮発性メモリに記録する。記録された近親者情報は、見込ライフイベント入力受付部により、見込みライフイベントの抽出に使用されることが想定される。
【0250】
<実施形態11(主に請求項11に対応):制御方法>
以上が、実施形態11の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図58は、実施形態11のライフイベント型金融商品情報出力装置の制御方法の処理の流れを示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力装置の制御方法は、実施形態1から実施形態10のいずれか一の制御方法に加えて、顧客属性情報取得ステップ5822に、顧客近親者情報取得サブステップ58221を含み、顧客属性情報保持ステップ5823に、顧客近親者情報保持サブステップ58231を含む。
【0251】
<実施形態11(主に請求項11に対応):処理の流れ>
実施形態11のライフイベント型金融商品情報出力装置の制御方法は、顧客登録処理の顧客識別情報取得ステップS5822に顧客近親者情報取得サブステップS58221を含み、顧客属性情報保持ステップS5823に顧客近親者情報保持サブステップS58231を含む。顧客近親者情報取得サブステップで顧客の近親者にかかわる顧客近親者情報を取得し、取得した顧客近親者情報を顧客近親者情報保持サブステップで不揮発性メモリに保持する。
【0252】
<実施形態11(主に請求項11に対応):ハードウェア構成>
図59は、実施形態11のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態1から実施形態10のいずれか一の構成に加えて、顧客属性情報取得プログラム59301に、顧客近親者情報取得サブプログラム59321を含み、顧客属性情報保持プログラム59302に、顧客近親者情報保持サブプログラム59322を含み、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0253】
<実施形態11(主に請求項11に対応):効果>
以上述べてきたように、実施形態11のライフイベント型金融商品情報出力装置によれば、顧客の生計を同一してない親族の情報をも考慮してライフイベントが抽出されるので、突然の親の介護費用の捻出などに備えたライフプランニングが行える。また、将来の家族予定も考慮したライフプランニングが行える。
【0254】
<実施形態12(主に請求項12に対応):概要>
実施形態12のライフイベント型金融商品情報出力装置は、顧客の健康情報を取得し保持する。
【0255】
<実施形態12(主に請求項12に対応):構成>
図61は、実施形態12のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図であり、実施形態1から実施形態11のいずれか一の構成に加えて、顧客属性情報取得部6101に、顧客健康関連情報取得手段61011を含み、顧客属性情報保持部6103に、顧客健康関連情報保持手段61031を含む。以降で、各部の構成を説明するが、重複する構成の説明は省略する。
【0256】
<実施形態12(主に請求項12に対応):顧客属性情報取得部 顧客健康関連情報取得手段>
「顧客健康関連情報取得手段」61011は、顧客属性情報取得部に含まれ、顧客の健康に関する情報である顧客健康関連情報(例えば、基礎疾患、更年期障害、三大疾病)を取得する。
顧客健康関連情報取得手段は、顧客の基礎疾患や更年期障害、三大疾病などのリスクに関わる情報を取得する。顧客属性情報取得部に、健康に関わる情報を入力するインタフェースを設け、健康関連情報を入力するように構成することが考えられる。
「健康関連情報」とは、将来の健康リスクの推定に利用できる情報であり、顧客の病歴、親族の病歴、身長、体重、体脂肪率、血圧、血液検査の結果、DNA検査の結果のいずれか一以上を含む情報が考えられる。また、毎年の健康診断の情報を入力するようにしても良い。この他、国民健康保険などが運営するデータベースから医療情報を取得するような構成であってもよい。取得した情報から将来の健康リスクを推定して、見込ライフイベント入力受付部で、見込ライフイベントとして入院や手術等のイベントを抽出するように構成することが考えられる。
【0257】
<実施形態12(主に請求項12に対応):顧客属性情報保持部 顧客健康関連情報保持手段>
「顧客健康関連情報保持手段」61031は、顧客属性情報保持部に含まれ、顧客健康関連情報取得手段で取得した顧客健康関連情報を保持する。
顧客健康関連情報保持手段は、顧客健康関連情報取得手段で取得した健康関連情報を、不揮発性メモリに記録する。記録された健康関連情報は、見込ライフイベント入力受付部により読み出され、健康リスクに関わる見込ライフイベントの抽出に使用される。
【0258】
<実施形態12(主に請求項12に対応):制御方法>
以上が、実施形態12の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図62は、実施形態12のライフイベント型金融商品情報出力装置の制御方法の処理の流れを示すフローチャートである。
本実施形態のライフイベント型金融商品情報出力制御方法は、実施形態1から実施形態11のいずれか一の制御方法に加えて、顧客属性情報取得ステップS6222に、顧客健康関連情報取得サブステップS62221を含み、顧客属性情報保持ステップS6223に、顧客健康関連情報保持サブステップS62231を含む。
【0259】
<実施形態12(主に請求項12に対応):処理の流れ>
実施形態12のライフイベント型金融商品情報出力装置の制御方法は、顧客登録処理の顧客識別情報取得ステップS6222に顧客健康関連情報取得サブステップS62221を含み、顧客属性情報保持ステップS6223に顧客健康関連情報保持サブステップS62231を含む。顧客健康関連情報取得サブステップで顧客の健康にかかわる顧客健康関連情報を取得し、取得した顧客健康関連情報を顧客健康関連情報保持サブステップで不揮発性メモリに保持する。
【0260】
<実施形態12(主に請求項12に対応):ハードウェア構成>
図63は、実施形態12のライフイベント型金融商品情報出力装置のハードウェア構成を示すブロック図であり、実施形態1から実施形態11のいずれか一の構成に加えて、顧客属性情報取得プログラム63301に、顧客健康関連情報取得サブプログラム63323を含み、顧客属性情報保持プログラム63302に、顧客健康関連情報保持サブプログラム63324を含み、適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0261】
<実施形態12(主に請求項12に対応):効果>
以上述べてきたように、実施形態12のライフイベント型金融商品出力装置によれば、 顧客の将来の健康リスクも考慮したライフプランニングが行えるので、将来の健康リスクによる生活不安の解消が可能になる。
【0262】
<実施形態13:(請求項13に対応)>
<実施形態13: 概要>
実施形態13のライフイベント型金融商品出力装置は、顧客が顧客属性情報として入力した様々な情報や、ライフイベント型金融商品出力装置によって出力された金融商品の情報を、第三者に閲覧可能にすることができる。
【0263】
<実施形態13:構成>
図66は、実施形態13のライフイベント型金融商品出力装置の機能の構成を示すブロック図である。
実施形態13のライフイベント型金融商品情報出力装置は、実施形態1から実施形態12のいずれか一の構成に加えて、閲覧者識別情報保持部6611と、閲覧要求情報取得部6612と、閲覧権限判断部6613と、閲覧部6614と、をさらに有する。
【0264】
<実施形態13:構成の説明 閲覧者識別情報保持部>
「閲覧者識別情報保持部」6611は、閲覧者を識別する閲覧者識別情報を顧客識別情報と関連付けて保持する。
「閲覧者識別情報」は、閲覧者として登録された人物を特定するための識別情報であり、閲覧者識別情報保持部で、顧客識別情報と関連付けて、不揮発性メモリに保持する。
閲覧者は、閲覧者識別情報に関連付けられた顧客識別情報により特定される顧客のライフイベント型金融商品出力装置に保持された情報のうち、閲覧が許諾された情報の閲覧が可能になる。
閲覧者識別情報と、顧客識別情報の関連付けは、顧客が閲覧者を指定し閲覧可能と設定した場合に、関連付けて、閲覧者識別情報に保持するように構成することが考えられる。
【0265】
<実施形態13:構成の説明 閲覧要求情報取得部>
「閲覧要求情報取得部」6612は、閲覧者識別情報に関連付けて顧客識別情報で識別される顧客の顧客属性情報又は/及び、購入契約情報の閲覧を要求する情報である閲覧要求情報を取得する。
「閲覧要求情報」は、閲覧者の、ライフイベント型金融商品出力装置に保持された顧客に関わる情報の閲覧要求である。顧客に関わる情報には、顧客属性情報、将来情報、金融商品識別情報が該当する。閲覧要求情報は、閲覧者識別情報と、顧客識別情報と、閲覧要求とで構成するようにしても良い。
【0266】
図64は、閲覧要求取得部の一例である顧客一覧画面を示す。
顧客一覧画面6400には、閲覧者識別情報に関連付けられた顧客識別情報に該当する顧客が、顧客一覧として表示されている。お客様ID欄6401は、顧客識別情報に該当する情報を表示する。氏名欄6402には、顧客識別情報に関連付けられた顧客の氏名を表示する。詳細ボタン6403を押すと、該当する顧客識別情報で識別される顧客の情報に対する閲覧要求情報が取得され情報表示画面に切り替わる。終了ボタン6404を押すと顧客一覧画面を終了する。
【0267】
<実施形態13:構成の説明 閲覧権限判断部>
「閲覧権限判断部」6613は、取得した閲覧要求情報に含まれる顧客識別情報が取得された閲覧者識別情報に関連付けられているか判断する。
閲覧要求情報を取得したら、閲覧要求情報に含まれる閲覧者識別情報に基づいて、閲覧者識別情報保持部から、閲覧者識別情報に関連付けられた、顧客識別情報を取得する。閲覧要求情報に含まれる顧客識別情報が、取得した顧客識別情報にある場合は、閲覧可能と判断する。
閲覧権限判断部は、顧客の情報ごとに閲覧可能か否かを判断するように構成しても良い。
この場合、閲覧可能か否かの判断は、顧客自身が行い設定することが考えられる。
【0268】
<実施形態13:構成の説明 閲覧部>
「閲覧部」6614は、判断結果が関連付けられているとの判断結果である場合に、その顧客識別情報で識別される顧客の顧客属性情報又は/及び購入契約情報の閲覧を閲覧要求情報に関わる閲覧者識別情報で識別される閲覧者に閲覧させる。
閲覧部は、顧客情報閲覧画面として構成され、顧客識別情報、将来情報、金融商品識別情報などを整理して見易い形式で表示する。
【0269】
図65は、顧客情報閲覧画面の一例である家計表示画面である。
家計表示画面6500は、収入欄6501と支出欄6502で構成されている。
収入欄には、収入明細6503と、収入合計6505があり、家計全体の収入とその内訳が把握できるようになっている。
支出欄には、支出明細6504と、支出合計6506があり、家計全体の支出とその内訳が把握できるようになっている。
このように、顧客識別情報として入力された情報を、目的別に見やすいように整理して表示することが望ましい。
【0270】
<実施形態13:方法>
以上が、実施形態13の構成であるが、これを制御方法若しくはプログラムとして実現する場合も本発明の範囲内である。
図67は、実施形態13のライフイベント型金融商品情報出力装置の制御方法の処理の流れを示すフローチャートである。
実施形態13のライフイベント型金融商品情報出力装置の制御方法は、実施形態1から実施形態12のいずれか一の構成に加えて、閲覧処理として、閲覧者識別情報保持ステップS6701と、要求情報取得ステップS6702と、閲覧権限判断ステップS6703と、閲覧ステップS6704と、をさらに有する。
【0271】
実施形態13のライフイベント型金融商品情報出力装置の制御方法は、閲覧者識別情報保持ステップS6701では、顧客から閲覧者を指定する指示があった場合、顧客が指定した閲覧者の閲覧者識別番号に、指示した顧客の顧客識別情報を関連付けて不揮発性メモリに保持する。顧客からの指示がない場合、本処理は何も行わない。
閲覧要求情報取得ステップS6702は、閲覧者からの閲覧要求情報を取得する。
閲覧権限判断ステップS6703では、閲覧要求情報に含まれた閲覧者識別情報に関連付けられた顧客識別情報を取得し、閲覧要求情報に含まれた顧客識別情報が、閲覧者識別情報に関連付けられた顧客識別情報の中にあるかを確認し、ある場合は閲覧を「可」とし、無い場合は閲覧を「否」とする。
可と判断された場合、閲覧ステップS6704に移行するが、否とされた場合は、閲覧不可として閲覧処理を終了する。
閲覧ステップは、閲覧要求情報で指定された顧客識別情報で識別される顧客の情報を表示して閲覧者が閲覧可能な状態にする。
【0272】
<実施形態13:ハードウェア構成>
以上が実施形態13の構成であるが、これをプログラムもしくは制御方法として実現する場合も本発明の範囲内である。
図68は、実施形態13のハードウェア構成を示すブロック図である。
実施形態13のライフイベント型金融商品情報出力装置は、実施形態1から実施形態12のいずれか一の構成に加えて、閲覧者識別情報保持プログラム68311と、閲覧要求情報取得プログラム68312と、閲覧権限判断プログラム68313と、閲覧プログラム68314と、をさらに有する。適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0273】
<実施形態13:効果>
実施形態13のライフイベント型金融商品出力装置によれば、顧客が入力した、収入や支出、保有資産などの家計や顧客のキャッシュフローに関わる情報と、ライフイベント型金融商品出力装置により出力された金融商品ポートフォリオの情報を、ファイナンシャルプランナーなどの金融の専門家に共有することが可能になり、アドバイスを受ける場合の情報提供の手間を低減できる。
【0274】
<実施形態14:(請求項14に対応)>
<実施形態14: 概要>
実施形態14のライフイベント型金融商品情報出力装置は、自らが出力した金融商品を、顧客が購入した場合にその購入履歴に関わる情報を保持する。
【0275】
<実施形態14:構成>
図69は、実施形態14のライフイベント型金融商品情報出力装置の機能の構成を示すブロック図である。
実施形態14のライフイベント型金融商品情報出力装置は、実施形態1から実施形態13の構成に加えて、購入契約情報取得部6911と、購入契約情報保持部6912と、をさらに有する。
【0276】
<実施形態14:構成の説明 購入契約情報取得部>
「購入契約情報取得部」6911は、出力された金融商品識別情報に基づいてその金融商品識別情報で識別される金融商品の購入契約情報を取得する。
「購入契約情報」は、金融商品の購入に関わる契約情報で、一つ以上の金融商品識別情報と、各金融商品の購入金額、を少なくとも含む情報である。購入金額は、購入口数でも良い。
積立購入契約の場合、一つ以上の金融商品と、月々の各金融商品の購入金額である。
また、購入方法は、積立購入に限定するものではなく、スポット購入を毎月発注するようにしても良い。
以上述べたような金融商品の購入契約に関わる情報を取得する。
【0277】
<実施形態14:構成の説明 購入契約情報保持部>
「購入契約情報保持部」6912は、取得した購入契約情報を保持する。
購入契約情報取得部で取得した購入契約情報を顧客識別情報と関連付けて、不揮発性メモリに保持する。
【0278】
<実施形態14:方法>
図70は、実施形態14の金融商品運用システムの顧客利用端末の制御方法の処理の流れを示すフローチャートである。実施形態14の顧客利用端末の制御方法は、実施形態1から実施形態13のいずれか一の構成に加えて、金融商品情報出力処理に、購入契約情報取得ステップS7045と、購入契約情報保持ステップS7046と、をさらに有する。
【0279】
見込みライフイベント識別情報入力受付ステップS7041から金融商品情報出力ステップS7044の処理は実施形態1と同じなので説明を省略する。
金融商品識別情報出力ステップS7044で出力された金融商品識別情報を、購入契約情報取得ステップS7045で購入契約情報として取得し、購入契約情報保持ステップS7046で購入契約情報を不揮発性メモリに保持する。
【0280】
<実施形態14:ハードウェア構成>
以上が実施形態14の構成であるが、これをプログラムもしくは制御方法として実現する場合も本発明の範囲内である。
図71は、実施形態14のハードウェア構成を示すブロック図である。
実施形態14の顧客利用端末装置は、実施形態1から実施形態13のいずれか一の構成に加えて、購入契約情報取得プログラム71311と、購入契約情報保持プログラム71312と、をさらに有する。適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
【0281】
<実施形態14:効果>
実施形態14のライフイベント型金融商品情報出力装置は、自らが出力した金融商品を、顧客が購入した場合にその購入履歴に関わる情報を保持することができるので、外部の証券会社等の運用機関で購入を行った場合でも、その購入履歴が残っているので、参照等行うことが可能になる。
【0282】
<実施形態15:(請求項15に対応)>
<実施形態15: 概要>
実施形態15の金融商品運用システムは、ライフイベント型金融商品出力装置と、顧客利用者端末で構成される。顧客利用端末は、スマートフォンやタブレット端末等の情報端末で動作するアプリケーションとして構成され、顧客利用端末から、金融商品の購入契約を行ったり、購入した金融商品の運用状況を確認したりすることができる。
【0283】
<実施形態15: 構成>
実施形態15の金融商品運用システムは、実施形態1から実施形態14のいずれか一の構成に加えて、顧客利用端末をさらに有する。
図72は、顧客利用端末の機能の構成を示すブロック図であり、顧客利用端末は、顧客識別情報保持部7201と、金融商品識別情報取得部7202と、金融商品識別情報保持部7203と、購入契約情報入力受付部7204と、購入契約情報出力部7205と、購入契約処理部7206と、運用状況情報取得部7207と、運用状況情報出力部7208と、で構成される。
【0284】
<実施形態15:構成の説明 顧客識別情報保持部>
「顧客識別情報保持部」7201は、顧客識別情報を保持する。
顧客識別情報は、ライフイベント型金融商品出力装置に最初に利用者登録を行った際に、例えば顧客識別子として付与される情報である。
利用者登録時に付与された利用者識別情報を、不揮発性メモリに保持する。
【0285】
<実施形態15:構成の説明 金融商品識別情報取得部>
「金融商品識別情報取得部」7202は、ライフイベント型金融商品出力装置から金融商品識別情報を取得する。
金融商品識別情報取得部は、公衆回線やLANを介してインターネット接続可能な通信機能を有して、ライフイベント型金融商品出力装置の金融商品識別情報から出力された金融商品識別情報をインターネットなどのネットワークを経由して取得する。
【0286】
<実施形態15:構成の説明 金融商品識別情報保持部>
「金融商品識別情報保持部」7203は、取得した金融商品識別情報を保持する。
金融商品識別情報保持部は、金融商品識別情報保持部が取得した金融商品識別情報を不揮発性メモリに保持する。
【0287】
<実施形態15:構成の説明 購入契約情報入力受付部>
「購入契約情報入力受付部」7204は、取得した金融商品識別情報に基づいて金融商品の購入契約をするための購入契約情報の入力を受付ける。
購入契約情報入力受付部は、取得した金融商品識別情報に該当する金融商品名を表示し、購入金額や購入口数などを入力するように構成しても良い。
また、月々の購入日や、購入間隔、購入条件などを設定することができるように構成しても良い。
図13の購入金融商品確認画面は、購入契約入力受付部の一例である。
【0288】
<実施形態15:構成の説明 購入契約情報出力部>
「購入契約情報出力部」7205は、受付けた購入契約情報を保持されている顧客識別情報と関連付けて出力する。
図13の例では、発注ボタンが押されると、表示された金融商品を購入額欄で入力した金額で月々積立投資を行うという注文が、利用者識別情報と関連付けられて出力される。
【0289】
<実施形態15:構成の説明 購入契約処理部>
「購入契約処理部」7206は、入力を受付けた購入契約情報に基づいて購入契約をするための処理をする。
購入契約処理部は、出力された購入契約情報に含まれる金融商品の購入先である金融機関または証券会社等に、指定された金額で購入する発注を、インターネットなどのネットワークを経由して送信する。
購入契約は、積立購入であっても良いし、スポット購入であっても良い。
【0290】
<実施形態15:構成の説明 運用状況情報取得部>
「運用状況情報取得部」7207は、購入契約を締結した金融商品の運用状況に関する情報である運用状況情報を取得する。
「運用状況情報」は、購入した金融商品の時価評価額や保有口数を含む情報である。
運用状況情報取得部は、購入先の金融機関から運用状況情報を取得する。
また、ライフイベント型金融商品出力装置の購入契約情報保持部に購入契約情報が残っている場合は、その情報を取得し、時価評価額の情報に基づいて運用状況情報を生成するようにしても良い。
【0291】
<実施形態15:構成の説明 運用状況情報出力部>
「運用状況情報出力部」7208は、取得した運用状況情報を出力する。
運用状況情報出力部は、顧客が運用状況を確認できるように、顧客利用端末の画面に運用状況として分かり易い形式にして出力する。
図14は、運用状況情報出力結果の一例である。ライフイベント向けの積立投資の状況や、目標に対する進捗率などが一目で把握できるようになっている。
【0292】
<実施形態15:方法>
図74は、実施形態15の金融商品運用システムの顧客利用端末の制御方法の処理の流れを示すフローチャートである。
実施形態15の金融商品運用システムの顧客利用端末の制御方法は、顧客識別情報保持ステップS7401と、金融商品識別情報取得ステップS7402と、金融商品識別情報保持ステップS7403と、購入契約情報入力受付ステップS7404と、購入契約情報出力ステップS7405と、購入契約処理ステップS7406と、運用状況情報取得ステップS7407と、運用状況情報出力ステップS7408と、をさらに有する。
【0293】
先ず、顧客が最初にライフイベント型金融商品出力装置にアクセスし利用者登録した場合、ライフイベント型金融商品出力装置から利用者IDが付与される。
次に、顧客識別情報保持ステップS7401では、付与された利用者IDを顧客識別情報として不揮発性メモリに保持する。
次に、金融商品識別情報取得ステップS7402で、ライフイベント型金融商品出力装置から出力された金融商品識別情報をインターネットなどのネットワークを介して取得する。
金融商品識別情報保持ステップS7403は、金融商品識別情報取得ステップで取得した金融商品識別情報を不揮発性メモリに保持する。
次に、購入契約情報入力受付ステップS7404で、取得した金融商品識別情報を表示し、該当する金融商品の購入金額、購入日などの情報の入力を受け付ける。
次に購入契約情報出力ステップS7405で、金融商品識別情報に購入金額や購入日などを関連付けて購入契約情報として出力する。
次に購入契約情報保持ステップで、取得した購入契約情報を不揮発性メモリに保持する。
運用状況情報取得ステップS7407は、銀行や証券会社などの外部運用機関から購入した金融商品の運用状況である運用状況情報を、インターネットなどのネットワークを介して取得する。
次に運用状況情報出力ステップS7408は、取得した運用状況情報を、スマートフォンなどの画面に表示する。
以上が、利用者端末処理の処理の流れである。
【0294】
<実施形態15:ハードウェア構成>
以上が実施形態15の構成であるが、これをプログラムもしくは制御方法として実現する場合も本発明の範囲内である。すなわち、実施形態15の金融商品運用システムは、実施形態1から実施形態14のいずれか一の構成に加えて、顧客利用端末をさらに有する。
図73は、実施形態15の金融商品運用システムの顧客利用端末のハードウェア構成を示す図である。
顧客利用端末は、CPU7310と、メインメモリ7320と、不揮発性メモリ7330と、チップセット7341,7342と、BIOS7350と、I/Oコントローラ7360と、無線LANインタフェース7370と、GPU(Graphics Processing Unit)7380と、を有し、不揮発性メモリ内に、顧客識別情報保持プログラム73301と、金融商品識別情報取得プログラム73302と、金融商品識別情報保持プログラム73303と、購入契約情報入力受付プログラム73304と、購入契約情報出力プログラム73305と、購入契約処理プログラム73306と、運用状況情報取得プログラム73307と、運用状況情報出力プログラム73308と、をさらに有する。適宜必要なプログラムをメインメモリ上のプログラム領域にロードし、必要なデータをメインメモリ上のデータ領域にロードしCPUにより読み出し実行する。
GPUは、画面の表示制御を専門に行うプロセッサーであり、無線インタフェースは、移動体通信などの公衆回線または無線LANなどの無線通信が可能なインタフェースで、インターネットなどのネットワークに接続する。
【0295】
<実施形態15:効果>
実施形態15のライフイベント型金融商品出力装置によれば、顧客のスマートフォンなどの情報端末にアプリとして構成でき、金融商品の購入契約や、運用状況の確認が簡単に行えるようになる。
【符号の説明】
【0296】
ライフイベント型金融商品出力装置:0200
顧客属性情報取得部:0201
顧客識別情報保持部:0202
顧客属性情報保持部:0203
ライフイベント識別情報保持部:0204
見込ライフイベント識別情報選択受付部:0205
将来情報保持部:0206
金融商品識別情報保持部:0207
金融商品識別情報選択ルール保持部:0208
金融商品識別情報選択部:0209
金融商品識別情報出力部:0210
CPU:2010
メインメモリ:2020
不揮発性メモリ:2030
チップセット(ノースブリッジ):2041
チップセット(サウスブリッジ):2042
BIOS:2050
I/Oコントローラ:2060
LANインタフェース:2070
グラフィックカード:2080
図1
図2
図3
図4A
図4B
図5A
図5B
図5C
図5D
図5E
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37
図38
図39
図40
図41
図42
図43
図44
図45
図46
図47
図48
図49
図50
図51
図52
図53
図54
図55
図56
図57
図58
図59
図60
図61
図62
図63
図64
図65
図66
図67
図68
図69
図70
図71
図72
図73
図74
図75
図76