JP2006338562A - 金融商品管理システム及び金融商品管理方法 - Google Patents

Abstract

【課題】 顧客の保有する複数の個別金融商品を全体として簡単に管理できるようにし、使い勝手を向上させる。
【解決手段】
資産運用管理システム１は、金融商品Ｆ１〜Ｆ４を仮想金融商品として仮想化する仮想化部１Ａと、現在価格等に基づいて仮想金融商品を評価する資産評価部１Ｃと、自動換金サービス部１Ｃと、定期換金サービス部１Ｄと、分散購入サービス部１Ｅとを備える。自動換金サービス部１Ｃは、仮想金融商品が所定値以上値下がりしたような場合に、警告を発したり、仮想金融商品の全部または一部を換金する。定期換金サービス部１Ｄは、仮想金融商品が所定値以上値上がりしたような場合に、その仮想金融商品の少なくとも一部を換金させ、利益を投資家に還元する。分散購入サービス部１Ｅは、仮想金融商品を構成する各個別金融商品の割合を調節する。
【選択図】 図１

Description

本発明は、金融商品管理システム及び金融商品管理方法に関する。

金融商品としては、例えば、投資信託等が知られている。投資信託では、個人や法人の投資家から資金を集めてファンドを構成する。このファンドは、専門家の手によって、例えば、国債市場、為替市場、株式市場等で運用される。運用で得られた利益は、投資家に還元される。

投資信託では、預金とは異なり、より多くの利益を期待することができるが、その分リスクも高い。経済環境の変化やファンドを運用する会社の手腕等により、元金割れする可能性も存在する。

そこで、投資した商品の価値を周期的に評価し、価値が減少している場合は、よりリスクの低い商品に再投資し、価値が増大している場合は、より高リスクの商品に再投資するようにしたリスク管理システムが提案されている（特許文献１）。
特開２００１−２８２９９２号公報

上記文献に記載の技術では、投資した商品の価値に基づいて自動的に再投資を行う。しかし、単に再投資するだけでは、十分なリスク管理とは言えない。投資した商品を現金化するまでは、実際の損益は確定しないためである。相対的にリスクの少ない商品に再投資した場合でも、その元本が必ずしも保証されるわけではない。従って、再投資を繰り返しながら、投資金額が目減りしていく可能性もある。

また、上記文献に記載の技術は、投資した商品それ自体の価値の増減に基づいて、単純に再投資の判断を行うだけのものである。従って、投資した商品の特性を越えて管理することができず、投資家にとって使い勝手が低いという問題もある。

例えば、ハイリスク・ハイリターン型商品、ミドルリスク・ミドルリターン型商品、ローリスク・ローリターン型商品、リスク限定型商品等のように、種々の特性を備えた商品が知られているが、前記文献に記載の技術では、各商品間で単純に乗り換えるだけのもので、商品の特性を越えたリスク管理を提供することはできない。

また、前記文献に記載の技術では、各商品毎にそれぞれ個別にリスクを管理するだけのものであるから、投資家が多数の商品に投資している場合には、全体としての資産評価を適切に行うことができず、使い勝手が低いという問題もある。

そこで、本発明の目的は、個別の金融商品を仮想化して管理することにより、使い勝手を向上させた金融商品管理システム及び金融商品管理方法を提供することにある。本発明の他の目的は、個別の金融商品を仮想化して管理することにより、個別の金融商品の特性とは異なる別の特性を適用することができ、使い勝手を向上できるようにした金融商品管理システム及び金融商品管理方法を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明の一つの観点に従う金融商品管理システムは、一つまたは複数の個別金融商品に関する情報を仮想金融商品に関する情報にそれぞれ関連づけて記憶させることにより、各個別金融商品に基づいて仮想金融商品を生成させる仮想化手段と、各個別金融商品の現在価値をそれぞれ取得する個別価値取得手段と、取得された各個別金融商品の現在価値と予め設定された所定の条件とに基づいて、仮想金融商品を評価し、その評価結果を記憶させる評価手段と、記憶された評価結果に基づいて、各個別金融商品毎にそれぞれ所定のデータを生成可能なデータ生成手段と、を備える。

本発明の実施形態では、評価結果には、データ生成手段への指示情報が含まれており、データ生成手段は、指示情報に基づいて、所定のデータを生成する。

本発明の一実施形態では評価手段は、各個別金融商品の取得コストを考慮して仮想金融商品を評価し、その評価結果を記憶させる。

本発明の実施形態では、評価部は、各個別金融商品の取得コスト及び各個別金融商品の現在価値に基づいて、仮想金融商品の損益を算出し、この算出された損益が予め設定された第１の所定値に到達した場合は、各個別金融商品のうち所定の個別金融商品を換金させるための換金評価を行い、データ生成手段は、換金評価を検出すると、所定の個別金融商品に関する換金データを生成する。

本発明の実施形態では、評価手段は、各個別金融商品の取得コスト及び各個別金融商品の現在価値に基づいて、仮想金融商品の損益を算出し、この算出された損益が予め設定された第２の所定値に到達した場合は、警告を出力させるための警告評価を行い、データ生成手段は、警告評価を検出すると、仮想金融商品に関する警告データを生成する。

本発明の実施形態では、評価部は、仮想金融商品に損失が発生している場合、所定の個別金融商品の全体を換金させるための換金評価を行う。

本発明の実施形態では、評価部は、仮想金融商品に利益が発生している場合、その利益の範囲内で所定の個別金融商品を換金させるための換金評価を行う。

本発明の実施形態では、評価手段は、各個別金融商品に関して予め設定されている保有割合に近づくように、各個別金融商品のうち所定の個別金融商品を購入または換金させるための評価を行い、データ生成手段は、評価を検出すると、所定の個別金融商品に関する購入データまたは換金データを生成する。

本発明の他の観点に従う金融商品管理システムは、仮想金融商品として仮想化させる一つまたは複数の個別金融商品に関する情報及び所定の条件をそれぞれ記憶する第１記憶手段と、各個別金融商品の取得コストをそれぞれ記憶する第２記憶手段と、各個別金融商品の現在価格をそれぞれ記憶する第３記憶手段と、仮想金融商品に関する評価結果を記憶する第４記憶手段と、仮想金融商品を評価して、その評価結果を第４記憶手段に記憶させる評価手段と、第４記憶手段に記憶された評価結果に基づいて、各個別金融商品毎にそれぞれ所定のデータを生成可能なデータ生成手段とを備えている。そして、評価手段は、（１）第１記憶手段に記憶されている各個別金融商品毎の個別損益を、第２記憶手段に記憶されている各個別金融商品の取得コスト及び第３記憶手段に記憶されている各個別金融商品の現在価格に基づいてそれぞれ算出し、（２）算出された各個別損益に基づいて、仮想金融商品の損益を算出し、（３）算出された仮想金融商品の損益と第１記憶手段に記憶されている所定の条件とに基づいて、仮想金融商品を評価し、その評価結果を第４記憶手段に記憶させる。

本発明のさらに別の観点に従うコンピュータプログラムは、仮想金融商品として仮想化させる一つまたは複数の個別金融商品に関する情報及び所定の条件を第１記憶手段に記憶させるステップと、第２記憶手段からそれぞれ取得される各個別金融商品の取得コストと、第３記憶手段からそれぞれ取得される各個別金融商品の現在価格とに基づいて、各個別金融商品の個別損益をそれぞれ算出するステップと、算出された各個別損益に基づいて仮想金融商品の損益を算出し、この算出された損益と所定の条件とに基づいて仮想金融商品を評価し、この評価結果を第４記憶手段に記憶させるステップと、第４記憶手段に記憶された評価結果に基づいて、各個別金融商品毎にそれぞれ所定のデータを生成するステップと、生成された所定のデータを出力させるステップと、をコンピュータにそれぞれ実行させる。

本発明の他の観点に従う金融商品管理方法は、一つまたは複数の個別金融商品を仮想化して仮想金融商品とし、仮想金融商品について所定の条件を設定し、少なくとも各個別金融商品の現在価格に基づいて仮想金融商品を評価し、仮想金融商品の評価結果と所定の条件とに基づいて、各個別金融商品のうち全部または所定の一部の個別金融商品について、売買指示を発行させる。

本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。

以下、図面に基づき、本発明の実施の形態を説明する。本実施形態では、以下に述べるように、複数の金融商品Ｆ１〜Ｆ４を仮想金融商品として仮想化し、この仮想金融商品の価値変化を監視して管理するようになっている。

金融商品管理システムとしての資産運用管理システム１は、例えば、金融商品Ｆ１〜Ｆ４を販売する金融機関に設置されるコンピュータシステムである。この資産運用管理システム１には、例えば、運用管理会社のコンピュータシステム２と、端末３とが、それぞれ通信ネットワークを介して接続されている。

運用管理会社とは、投資信託のような金融商品Ｆ１〜Ｆ４を運用する会社であり、運用実績は、定期的に資産運用管理システム１に通知される。端末３は、例えば、銀行や証券会社等の金融機関の本店及び各支店に設置されるコンピュータ端末である。あるいは、端末３は、投資家の自宅や勤務先に設置されるコンピュータ端末であってもよい。投資家（エンドユーザ）の希望するサービス契約の情報は、端末３を介して資産運用管理システム１に入力される。

資産運用管理システム１は、例えば、金融商品仮想化部１Ａと、資産評価部１Ｂと、自動換金サービス部１Ｃと、定期換金サービス部１Ｄと、分散購入サービス部１Ｅとを備えて構成することができる。これらの各機能１Ａ〜１Ｅは、例えば、所定のコンピュータプログラムを演算処理装置が読み込んで実行することにより、実現される。

金融商品仮想化部１Ａは、投資家の希望に応じて、複数の個別金融商品Ｆ１〜Ｆ４の中から一つまたは複数の金融商品を仮想化するものである。図１中では、金融商品Ｆ１〜Ｆ３が一つの仮想金融商品として仮想化され、金融商品Ｆ４が他の一つの仮想金融商品として仮想化されている。仮想金融商品とは、一つまたは複数の個別金融商品を全体として一つの商品であるかのように仮想化した商品である。例えば、一つまたは複数の個別金融商品を特定するための識別情報を、仮想化金融商品の識別情報に対応付けることにより、一つの仮想的な金融商品を生成することができる。

資産評価部１Ｂは、各仮想金融商品を評価する。資産評価部１Ｂは、各仮想金融商品を構成する各個別金融商品の現在価格（時価）及び取得コストに基づいて、各個別金融商品毎にそれぞれ損益を算出する。そして、資産評価部１Ｂは、各個別金融商品の損益に基づいて、仮想金融商品の損益（全体損益）を求める。

自動換金サービス部１Ｃ，定期換金サービス部１Ｄ及び分散購入サービス部１Ｅは、資産評価部１Ｂの評価に基づいて、それぞれのサービスを投資家に提供する。これら各サービス部１Ｃ〜１Ｅと資産評価部１Ｂとにより、「評価手段」及び「データ生成手段」をそれぞれ実現可能である。各サービス部１Ｃ〜１Ｅは、「評価手段」の少なくとも一部をそれぞれ備えることができる。

自動換金サービス部１Ｃは、投資家によって予め設定された条件に基づき、仮想金融商品が所定値以上値下がりしたような場合に、警告を発したり、あるいは、その仮想金融商品を構成する各個別金融商品の全部または一部を換金したりする。これにより、投資家の投資金額の全体について所定値以上値下がりしたか否かを監視し、所定値以上の損失が発生した場合は、全部または一部を換金することにより、損失の増大を抑制することができる。

定期換金サービス部１Ｄは、投資家によって予め設定された条件に基づき、仮想金融商品が所定値以上値上がりしたような場合に、その仮想金融商品を構成する各個別金融商品の少なくとも一部を換金させ、仮想金融商品に生じた利益を投資家に還元する。これにより、投資家は、利益が出ている場合のみ、その利益を受け取ることができる。

分散購入サービス部１Ｅは、投資家によって予め設定された条件に基づき、仮想金融商品を構成する各個別金融商品の割合を調節する。例えば、投資家によって予め設定された各個別金融商品の保有割合（ポートフォリオ）に基づいて、分散購入サービス部１Ｅは、個別金融商品の追加購入や部分的な売却を行うことができる。例えば、投資家が、毎月一定金額を投資する場合、分散購入サービス部１Ｅは、ポートフォリオに基づいて、毎月の投資額を割り当てる個別金融商品を決定し、その商品を購入することができる。また、分散購入サービス部１Ｅは、仮想金融商品に利益が生じている場合、ポートフォリオに基づいて、その利益を再投資することができる。

これらの各サービス部１Ｃ〜１Ｅによりそれぞれ実現される管理サービスは、有償または無償で、投資家に提供することができる。また、上述した自動換金サービス、定期換金サービス及び分散購入サービスの全てを投資家に提供してもよいし、そのうちの一部のサービスのみを投資家に提供してもよい。また、例えば、自動換金サービスは無償で提供し、定期換金サービス及び分散購入サービスを有償で提供する場合のように、各サービス毎にそれぞれ有償とするか無償とするかを個別に設定することができる。

このように、本実施形態では、一つまたは複数の個別金融商品を仮想化し、投資家が投資した金額の全体を評価して管理することができ、使い勝手が向上する。

また、本実施形態では、個別金融商品を仮想金融商品として仮想化するため、個別金融商品の特性とは異なる別の特性を仮想金融商品に与えることができる。例えば、それぞれハイリスク・ハイリターンの特性を備える一つまたは複数の個別金融商品を仮想化し、１０％程度損失が発生した場合に自動的に換金させることにより、仮想化金融商品をあたかもミドルリスク・ミドルリターン型の商品であるかのように、あるいは、リスク限定型の商品であるかのように管理することができ、使い勝手が向上する。

本実施形態では、投資家は、自動換金サービス、定期換金サービス及び分散購入サービスの全部または一部を利用することができるため、希望条件に応じて、投資金額の全体を容易に管理することができる。

また、これらの各サービスは各個別金融商品について重ねて設定することもできる。例えば、ある個別金融商品は、他の個別金融商品と共に仮想化されて定期換金サービスを利用することができると同時に、それ自体単独で、またはさらに別の個別金融商品と共に仮想化されて、自動換金サービスの適用を受けることもできる。これにより、投資家は、自己の投資金額の全体について、種々の観点から管理を行うことができ、より使い勝手が向上する。以下、本実施形態のより詳細な実施例を説明する。

図２は、資産運用管理システムの概略構成の一例を示す構成図である。図２には、ハードウェア構成、ソフトウェア構成及びネットワーク構成がそれぞれ示されている。図１と図２との対応関係について説明すると、図１中の資産運用管理システム１は、図２中のウェブサーバ１１００及び業務サーバ１２００に対応し、図１中の運用会社のコンピュータシステム２は、図２中のコンピュータシステム２０００に対応し、図１中の端末３は、図２中の端末３０００に対応する。

資産運用管理システム１は、例えば、ウェブサーバ１１００と、業務サーバ１２００との複数のコンピュータシステムを連携させることにより、構成することができる。単一のコンピュータシステムで資産運用管理システム１を構成してもよいし、３台以上のコンピュータシステムから資産運用管理システム１を構成してもよい。

ウェブサーバ１１００と業務サーバ１２００とは、例えば、インターネットや専用通信回線等の通信ネットワークCN１を介して、双方向通信可能に接続されている。また、各サーバ１１００，１２００は、通信ネットワークCN１を介して、端末３０００に接続されている。また、各サーバ１１００，１２００は、通信ネットワークCN１，ゲートウェイ装置GD及び通信ネットワークCN２を介して、運用会社のコンピュータシステム２０００に接続されている。

ウェブサーバ１１００は、例えば、情報処理部１１１０と、記憶部１１２０と、通信部（図中「Ｉ／Ｆ」）１１３０とを備えて構成可能である。情報処理部１１１０は、例えば、CPU（Central Processing Unit）等から構成され、所定のプログラムを実行することにより、種々の機能を実現させるものである。

記憶部１１２０は、例えば、ROM（Read Only Memory）、RAM（Random Access Memory）、ハードディスクドライブ等の記憶デバイスから構成可能である。記憶部１１２０には、例えば、情報処理部１１１０により実行されるOS（Operating System）１１１１，ウェブアプリケーションサーバ１１１２，画面制御プログラム１１１３等の各種プログラムやデータ等を記憶させることができる。また、記憶部１１２０は、各プログラムにより利用されるワーク領域も提供することができる。通信部１１３０は、例えば、ネットワークカードのように構成可能であり、通信ネットワークCN１を介したデータ通信を担当するものである。

ウェブアプリケーションサーバ１１１２は、ウェブサーバを実現するためのプログラムであり、端末３０００のウェブブラウザ３１１０との間で、HTTP（HyperText Transfer Protocol）のような所定のプロトコルに基づく双方向のデータ通信を行う。

画面制御プログラム１１１３は、端末３０００のウェブブラウザ３１１０に提供するための画面を生成するプログラムである。

業務サーバ１２００は、情報処理部１２１０と、記憶部１２２０と、通信部１２３０と、データベース１２４０とを備えて構成可能である。情報処理部１２１０は、例えば、OS１２１１と、バッチプログラム１２１２と、口座管理プログラム１２１３と、契約登録プログラム１２１４と、資産評価プログラム１２１５と、自動換金プログラム１２１６と、定期換金プログラム１２１７と、分散購入プログラム１２１８とをそれぞれ実行することができる。記憶部１２２０には、これらのプログラム１２１１〜１２１８やデータ等が記憶されている。通信部１２３０は、ウェブサーバ１１００や運用会社のコンピュータシステム２０００との間のデータ通信を担当する。データベース１２４０には、後述する各種の情報が記憶されている。

主要なプログラムの詳細はさらに後述するが、先に簡単に説明すると、バッチプログラム１２１２は、所定のタイミングを見計らってデータベース１２４０の更新作業等を行うプログラムである。口座管理プログラム１２１３は、各投資家の口座を管理するためのプログラムである。以下、投資家を顧客と呼ぶ。契約登録プログラム１２１４は、端末３０００から入力されたサービス契約の内容をデータベース１２４０に登録させるプログラムである。資産評価プログラム１２１５は、例えば、運用会社のコンピュータシステム２０００から取得される個別金融商品の最新価格と購入時の取得コストとに基づいて、仮想金融商品の評価を行うプログラムである。

自動換金プログラム１２１６は、仮想金融商品の評価に基づいて、契約した顧客に自動換金サービスを提供するプログラムである。同様に、定期換金プログラム１２１７，分散購入プログラム１２１８は、契約した顧客に定期換金サービス，分散購入サービスをそれぞれ提供するプログラムである。

端末３０００は、例えば、個別金融商品を販売する金融機関の本店や各支店にそれぞれ設置されたコンピュータ端末である。あるいは、顧客の自宅や勤務先に設置されたコンピュータ端末であってもよい。端末３０００は、例えば、情報処理部３１００と、記憶部３２００と、通信部３３００とを備えることができる。端末３０００は、例えば、パーソナルコンピュータやワークステーション、携帯情報端末として構成できる。

次に、図３〜図１１に基づいて、資産運用管理システム１が自動換金サービスを提供する場合を説明する。図３は、自動換金サービスを提供する場合の概略構成を示すブロック図である。

資産運用管理システム１が自動換金サービスを提供する場合、資産運用管理システム１は、例えば、自動換金システム１０と、投資情報システム２０と、店舗端末３０と、口座管理システム４０とを備えて構成することができる。

本実施例では、顧客が直接使用可能な端末３と、金融機関に設置された端末３０との両方を備えている。顧客は、パーソナルコンピュータや携帯情報端末（携帯電話を含む）等の端末３を介して、資産運用管理システム１に自動換金サービスの契約を申し込むことができる。あるいは、顧客は、例えば、金融機関の窓口に出向いたり、または、郵便や電話・ファクシミリあるいはコンピュータ通信により、自動換金サービスの契約を申し込むこともできる。この場合、顧客の申込内容は、金融機関に設置された端末３０から自動換金システム１０に入力される。

自動換金システム１０は、例えば、契約登録部１１０と、資産評価部１２０と、警告・注文データ生成部１３０と、契約情報データベース１１１と、投資情報データベース１２１と、顧客情報データベース１２２と、評価結果データベース１２３と、を備えて構成可能である。自動換金システム１０は、例えば、図２中の各プログラム１２１１〜１２１６がそれぞれ実行されることにより、実現される。

契約登録部１１０は、自動換金サービスの利用を希望する顧客との契約内容を、契約情報データベース１１１に登録させる。自動換金サービスの契約申込は、端末３から自動換金システム１０に入力できる。自動換金サービス契約の申込によって、顧客の選択した一つまたは複数の個別金融商品は、仮想金融商品として仮想化され、契約情報データベース１１１に登録される。契約登録部１１０は、例えば、契約登録プログラム１２１４を情報処理部１２１０が実行することにより、実現される。契約情報データベース１１１は、例えば、データベース１２４０により実現される。

資産評価部１２０は、自動換金サービスの対象とされた仮想金融商品の価値を、契約情報データベース１１１に記憶されている契約内容と投資情報データベース１２１に記憶されている個別金融商品の最新の価格と顧客情報データベース１２２に記憶されている顧客情報とに基づいて評価する。資産評価部１２０の評価結果は、評価結果データベース１２３に記憶される。資産評価部１２０は、例えば、資産評価プログラム１２１５を情報処理部１２１０が実行することにより、実現される。投資情報データベース１２１及び顧客情報データベース１２２は、それぞれデータベース１２４０によって実現される。

警告・注文データ生成部１３０は、評価結果データベース１２３に記憶されている評価結果に基づいて、警告データファイル１３１や換金注文データファイル１３２を生成するものである。

警告データファイル１３１は、仮想金融商品の価値が下がった場合に、顧客に注意を促すための情報である。換金注文データファイル１３２は、予め顧客が設定した条件（換金ポリシー）に基づいて、仮想金融商品を構成する各個別金融商品のうち所定の個別金融商品を全部または一部、換金させるための情報である。警告データファイル１３１及び換金注文データファイル１３２は、例えば、口座管理システム４０に入力される。これにより、口座管理システム４０は、顧客へ注意を促す電子メールを送信したり、指定された個別金融商品を指定された額だけ換金させる。

投資情報システム２０は、運用会社のコンピュータシステム２から投資情報を受け取り、この投資情報を投資情報データベース１２１に記憶させるものである。投資情報の詳細はさらに後述する。投資情報システム２０は、口座管理システム４０の一部として構成することもできる。

口座管理システム４０は、顧客の口座を管理するためのものである。口座管理システム４０は、例えば、情報処理部１２１０が口座管理プログラム１２１３を実行することにより、実現される。口座管理システム４０は、顧客の投資内容を管理し、この情報を顧客情報データベース１２２に記憶させる。

次に、図４，図５に基づいて、各データベース１１１，１２１，１２２，１２３等の内容を説明する。まず、図４には、契約情報データベース１１１と、顧客情報データベース１２２と、投資情報データベース１２１とが示されている。

契約情報データベース１１１は、例えば、契約識別情報（以下、識別情報をIDと略記）と、口座IDと、ファンドIDと、警告条件と、換金条件と、解約順位と、頻度/期間とを対応付けることにより、構成することができる。

契約IDとは、各契約をそれぞれ識別するための情報である。同一の顧客が複数の契約を申し込むことができ、各契約毎にそれぞれ契約IDが設定される。口座IDとは、顧客の口座を識別するための情報である。同一の顧客が複数の口座を開設してもよく、その場合は、それぞれの口座に別々の口座IDが設定される。

ファンドIDとは、自動換金サービスの対象となる個別ファンド（個別金融商品）を特定するための識別情報である。一つの契約について、一つまたは複数の個別ファンドを設定することができる。サービスの対象として設定された各個別ファンドは、仮想ファンド（仮想金融商品）として仮想化されることになる。即ち、契約IDは、各仮想ファンドを識別する情報であり、この契約IDに関連づけられる各個別ファンドは、全体として一つの仮想ファンドであるかのように管理することができる。但し、実際の換金注文処理等は、各個別ファンド毎に行われる。

警告条件とは、仮想ファンドについて警告を発するための条件を示す情報である。例えば、仮想ファンドの価値が１０％以上値下がりまたは値上がりした場合に、顧客に向けて警告が発せられる。

換金条件とは、仮想ファンドを換金させるか否かを判断する条件を示す情報である。例えば、仮想ファンドが２０％以上値下がりまたは値上がりした場合、その仮想ファンドは換金対象となる。

解約順位とは、換金する場合の条件を示す情報である。例えば、解約順位には、「仮想ファンド全体」、「最も値下がりしている個別ファンド」等のように、換金時の順位が設定されている。

頻度/期間とは、自動換金サービスを行うための頻度と、自動換金サービスの適用期間を示す情報である。サービス頻度としては、例えば、「毎日」、「毎週」、「毎月」、「３ヶ月毎」等のように設定することができる。サービス期間としては、例えば、「１ヶ月」、「３ヶ月」、「６ヶ月」、「１年」等のように設定することができる。

上述した情報以外の情報も契約情報データベース１１１に含めることができる。図４では、自動換金サービスで使用する主要な項目を例示的に挙げている。上記の各項目のうち、どのファンドを仮想化するか（ファンドID）、どのような場合に警告を出すか（警告条件）、どのような場合に何をどれだけ換金するか（換金条件、解約順位）、サービスの頻度及び利用期間（頻度/期間）は、顧客の要望に基づいて設定される。

次に、顧客情報データベース１２２の構成を説明する。顧客情報データベース１２２は、各顧客の口座に関する情報を管理するためのものである。顧客情報データベース１２２は、例えば、口座IDと、保有ファンドIDと、残高と、コストとを対応づけることにより、構成することができる。これら以外の情報を含めてもよい。

残高とは、個別ファンドの残高を示す情報であり、例えば、口数として設定される。コストとは、そのファンドを顧客が購入したときの費用を示す情報である。顧客は、複数の口座を開設することができる。口座A01に着目すると、この口座A01には、４つの個別ファンドF01〜F04が含まれている。契約情報データベース１１１に示すように、これら４つの個別ファンドF01〜F04のうち、F01〜F03は、契約C01として仮想化されている。個別ファンドF03は、さらに別の契約C02によっても仮想化されている。

このように、本実施例では、一つの個別ファンドについてそれぞれ異なる複数の仮想化を行うことができる。なお、顧客が保有する個別ファンドF04は、自動換金サービスが適用されない。本実施例では、顧客は、自己の保有する個別ファンドF01〜F04のうち、所望の個別ファンドについて自動換金サービスを申し込むことができる。なお、一つの個別ファンドについて、後述する他のサービス（定期換金サービス、分散購入サービス）を、重ねて適用することもできる。

投資情報データベース１２１の構成を説明する。投資情報データベース１２１は、各個別ファンドの現在価格（最新価格あるいは時価とも呼ぶ）を記憶するものである。投資情報データベース１２１は、例えば、ファンドIDと、基準日と、直近基準価額とを対応付けることにより、構成される。基準日とは、前営業日を示す情報である。直近基準価格とは、その個別ファンドの最新の価格を示す情報であり、例えば、１万口当たりの金額として表示される。

資産評価部１２０は、これらの契約情報データベース１１１，顧客情報データベース１２２，投資情報データベース１２１の記憶内容に基づいて、各契約毎に（各仮想ファンド毎に）評価を行う。

図５は、資産評価部１２０による評価方法及び評価結果データベース１２３の構成等を示す説明図である。資産評価部１２０は、各自動換金サービスの契約毎に、それぞれの契約の対象となっている各個別ファンドの損益をそれぞれ算出する。具体的には、資産評価部１２０は、投資情報データベース１２１から各個別ファンドの現在価格（直近基準価格）をそれぞれ取得し、また、顧客情報データベース１２２から各個別ファンドの取得コストをそれぞれ取得する。資産評価部１２０は、現在価格と取得コストとの差分を求めて、各個別ファンド毎の損益をそれぞれ算出し、これら各個別ファンドの損益に基づいて、仮想ファンドの損益（全体損益とも呼ぶ）を算出する。この場合、既に投資家が受取っている分配金、解約金など過去の取引を含めて損益を算出することも出来る。

図５中には、各個別ファンド及び仮想ファンドの損益の額及び変化の割合を算出する様子が示されている。資産評価部１２０は、このようにして算出された評価損益の値を評価結果データベース１２３に記憶させる。また、資産評価部１２０は、各口座毎に行うべきアクションがある場合、それを指示する。

図５に示す評価結果データベース１２３は、資産評価部１２０による評価の結果を記憶するものである。評価結果データベース１２３は、例えば、口座IDと、基準日と、契約IDと、評価結果とを対応付けることにより、構成することができる。評価結果には、損益に関する評価情報と、アクションの指示情報とが含まれている。アクション指示情報としては、例えば、「警告」と「換金」とを挙げることができる。「警告」とは、その仮想ファンドに関して顧客に警告すべき旨を指示する情報である。「換金」とは、その仮想ファンドについて換金すべき旨を指示する情報である。

警告・注文データ生成部１３０は、仮想ファンドに関する所定のデータを生成するものである。警告・注文データ生成部１３０は、評価結果データベース１２３を参照し、評価結果に示されているアクション指示情報に基づいて、警告データファイル１３１や換金注文データファイル１３２を生成する。また、警告・注文データ生成部１３０は、各データファイル１３１，１３２のほかに、必要な帳票類なども生成する。

警告データファイル１３１は、例えば、口座IDと、基準日と、契約IDと、評価結果（仮想ファンドの損益に関する情報及びアクション指示情報）とを対応付けることにより、構成することができる。同様に、換金注文データファイル１３２は、口座IDと、基準日と、契約IDと、アクション指示情報及び換金量とを対応付けることにより、構成することができる。

図５に示す例では、契約C01が購入時から17.5%値下がりしたため、この仮想ファンドについて警告が発せられている。契約C02では、購入時から23.8%値下がりしたため、換金が指示されている。契約C02は、単一の個別ファンドF03のみから構成されるため、換金指示は、その個別ファンドF03について行われる。これに対し、もしも、契約C01において、換金が指示された場合は、顧客によって予め設定された条件に従う。例えば、顧客が全部の換金を予め指示している場合、その仮想ファンドに含まれる全ての個別ファンドを全て換金するためのデータファイル１３２が生成される。顧客が、例えば、「最も値下がりの大きなファンドのみ換金」すべき旨を予め指示している場合、顧客の希望に合致する個別ファンドのみを換金させるためのデータファイル１３２が生成される。

次に、自動換金サービスの処理の流れについて、図６〜図１０に基づき説明する。図６は、自動換金サービスの全体概要を示すフローチャートである。

自動換金サービスは、例えば、契約登録処理（Ｓ１）と、資産評価処理（Ｓ２）と、警告・注文データ生成処理（Ｓ３）とを、この順番で実行する。以下、各処理Ｓ１〜Ｓ３の詳細を説明する。

図７は、契約登録処理を示すフローチャートである。契約登録処理では、例えば、端末３または端末３０を介して、以下に述べる種々の情報を取得し、これら取得した情報を契約情報データベース１１１に登録させる。

契約登録部１１０は、口座IDを取得する（Ｓ１１）。口座IDは、同一の金融機関内で一意に特定可能な情報であり、自動的に発行される。次に、契約登録部１１０は、顧客が指定する一つまたは複数の個別ファンドのファンドIDを取得し（Ｓ１２）、また、顧客が指定する警告条件（Ｓ１３）及び換金条件（Ｓ１４）をそれぞれ取得する。さらに、契約登録部１１０は、顧客が指定する評価頻度（Ｓ１５）及びサービス利用期間（Ｓ１６）と解約順位（Ｓ１７）とをそれぞれ取得する。そして、契約登録部１１０は、これらの各情報を契約情報データベース１１１に記憶させる（Ｓ１８）。

図８は、資産評価処理を示すフローチャートである。資産評価処理では、以下に述べるように、顧客から指定されたタイミングで、その顧客の仮想ファンドについて評価を行い、その評価結果を評価結果データベース１２３に記憶させる。

資産評価部１２０は、契約情報データベース１１１を参照し（Ｓ２１）、評価を行うべき仮想ファンドが存在するか否かを判定する（Ｓ２２）。評価すべきタイミングが到来している仮想ファンドが存在する場合（S22：YES）、資産評価部１２０は、投資情報データベース１２１及び顧客情報データベース１２２をそれぞれ参照し（S23，S24）、各個別ファンド毎の損益をそれぞれ算出する（Ｓ２５）。

そして、資産評価部１２０は、各個別ファンドの損益に基づいて、仮想ファンドの損益を算出し（Ｓ２６）、また、損益率を算出する（Ｓ２７）。資産評価部１２０は、仮想ファンドの損益率が警告条件に示されている所定値（例えば10%）に達したか否かを判定し（Ｓ２８）、損益率が警告用所定値に達している場合（S28：YES）、その契約IDについて「警告」の評価を与え、評価結果データベース１２３に記憶させる（Ｓ２９）。

また、資産評価部１２０は、仮想ファンドの損益率が換金条件に示されている所定値（例えば20%）に達したか否かを判定し（Ｓ３０）、損益率が換金用所定値に達している場合（S30：YES）、その契約IDについて「換金」の評価を与え、評価結果データベース１２３に記憶させる（Ｓ３１）。

図９は、警告・注文データ生成処理を示すフローチャートである。警告・注文処理では、以下に述べるように、評価結果データベース１２３に記憶されている評価結果に基づいて、所定のデータファイル１３１，１３２を生成する。

警告・注文データ生成部１３０は、評価結果データベース１２３を参照し（Ｓ４１）、警告の評価が与えられた契約IDが存在するか否かを判定する（Ｓ４２）。警告・注文データ生成部１３０は、「警告」が設定された契約IDを検出すると（S42：YES）、その契約IDについて、警告データファイル１３１及び帳票を作成し（Ｓ４３）、これら警告データファイル１３１等を口座管理システム４０に出力する（Ｓ４４）。

警告・注文データ生成部１３０は、「換金」が設定された契約IDが存在するか否かを判定する（Ｓ４５）。警告・注文データ生成部１３０は、「換金」が設定された契約IDを検出すると（S45：YES）、その契約IDについて、換金注文データファイル１３２及び帳票を作成し（Ｓ４６）、これら換金注文データファイル１３２等を口座管理システム４０に出力する（Ｓ４７）。

図１０は、警告・換金処理を示すフローチャートである。この処理は、例えば、口座管理システム４０によって実行される。口座管理システム４０は、警告データファイル１３１を受領すると（S51：YES）、警告データファイル１３１に関する仮想ファンドの顧客に向けて、警告を発する（Ｓ５２）。例えば、電話やファクシミリ通信、電子メール等によって顧客に注意を促すことができる。または、顧客が端末３を介して資産運用管理システム１にログインした際に、警告メッセージを表示させることもできる。

口座管理システム４０は、換金注文データファイル１３２を受領すると（S53：YES）、運用会社のコンピュータシステム２に向けて、所定の個別ファンドの換金を指示する（Ｓ５４）。所定の個別ファンドとは、換金注文データファイル１３２に明示された個別ファンドである。換金注文データファイル１３２には、どの個別ファンドをいくら解約するかが明示されている。

続いて、口座管理システム４０は、仮想ファンドの一部についての換金であるか否かを判定する（Ｓ５５）。仮想ファンドを構成する一部の個別ファンドについて換金した場合は、仮想ファンドの構成が変化する。例えば、損失の大きい個別ファンドのみを換金した場合、その仮想ファンドには、損失の少ないまたは利益の出ている個別ファンドのみが残ることになる。逆に、利益の大きい個別ファンドのみを換金した場合、その仮想ファンドには、損失の出ているまたは利益の少ない個別ファンドのみが残ることになる。

このように、仮想ファンドの一部について換金した場合、その仮想ファンドの構成（性格）が変化する。この構成変化に応じて、顧客は、仮想ファンドの管理について再検討を必要とする可能性がある。例えば、顧客は、警告条件や換金条件を再設定したり、または、別の個別ファンドを仮想ファンドに組み込むことを希望する可能性がある。そこで、本実施例では、仮想ファンドが部分的に解約された場合（S55：YES）、自動換金サービスを停止させる（Ｓ５６）。

ここで、自動換金サービスを停止させるのは、仮想ファンドの構成をそれ以上変化させないためである。従って、自動換金システム１０は、仮想ファンドの構成に影響を与えない範囲で、顧客にサービスを提供する。具体的には、換金注文データファイル１３２を口座管理システム４０に出力する処理以外の処理、例えば、仮想ファンドの評価、ユーザへの警告、換金レベルに達した旨の通知は、継続される。

図１１は、仮想ファンド及び個別ファンドの変化を模式的に示す説明図である。図中の横軸は時間変化を、縦軸は金額変化をそれぞれ示す。
図１１（ａ）に示すように、各個別ファンドF01〜F03は、時間変化に応じて、それぞれの価格が変化している。図１１（ｂ）は仮想ファンドC01の推移を示す。時刻t0は、初期状態を示す。初期状態における各ファンドF01〜F03の価格は、それぞれの取得コストである。

時刻t0から時刻t1に変化して、仮想ファンドC01の価格が取得コストよりもΔM1だけ値下がりした場合を考える。この下落率が警告用所定値以上のときは、顧客に警告が発せられる。さらに、時刻t2になって、仮想ファンドC01の価格が取得コストよりもΔM2だけ値下がりした場合、この下落率が換金用所定値以上のときは、換金指示が出される。図１１に示す例では、個別ファンドF01〜F03の全体を全て解約することもできるし、F01〜F03のいずれかを部分的に解約することもできる。

本実施例では、上述のような自動換金サービスを顧客に提供することができる。従って、一つまたは複数の個別ファンドを仮想化して、あたかも別のファンドであるかのように管理することができる。

これにより、本実施例では、各個別ファンドの特性とは異なる特性を与えて、管理することができ、利便性が向上する。例えば、ハイリスク・ハイリターン型の個別ファンドを自動換金サービスによって仮想化すれば、10%値下がりした場合に顧客は警告を受けることができ、20%値下がりした場合に自動的に解約することができる。これにより、ハイリスク・ハイリターン型の個別ファンドから構成される仮想ファンドを、例えば、ミドルリスク型またはリスク限定型ファンドのように利用でき、使い勝手が向上する。

本実施例では、単にリスクのより小さなまたはより大きな別の個別ファンドに乗り換えるのではなく、解約して現金化させることができる。従って、損失または利益を確定させることができる。

本実施例では、顧客が多数の個別ファンドを購入している場合でも、それらを仮想化して一つまたは複数の仮想ファンドにまとめることができ、仮想ファンド全体として警告や換金を行うことができる。仮想ファンドが所定値以上値下がりまたは値上がりした場合に、警告や換金を行うため、安全装置のように機能する。これにより、顧客は、多数のファンドを簡単に管理することができ、使い勝手が向上する。

本実施例では、各個別ファンドの現在価格のみならず、各個別ファンドの取得コストも考慮して、仮想ファンドを評価する。従って、顧客は、実際の損益を明確に把握することができ、使い勝手が向上する。

本実施例では、仮想ファンドの一部が換金された場合に、それ以後自動的な換金を行わないように制御する。従って、仮想ファンドの構成がそれ以上変化するのを防止しながら、顧客に再検討の時間を与えることができ、使い勝手が向上する。

図１２〜図１７に基づいて、第２実施例を説明する。本実施例では、仮想ファンドに利益が発生している場合に、その利益に相当する額を解約して、顧客に還元するようにしている。このサービスを、本実施例では、定期換金サービスと呼ぶ。この定期換金サービスは、仮想ファンドに利益が発生している場合に換金されるもので、周期的に機械的に換金するサービスとは異なる。従って、定期換金サービスは、例えば、利益駆動型換金サービスと呼び変えることもできる。

図１２は、定期換金サービスを提供する場合の資産運用管理システム１の構成を示す説明図である。資産運用管理システム１には、定期換金システム１０Ａが構築される。この定期換金システム１０Ａは、例えば、契約登録部１１０Ａと、契約情報データベース１１１Ａと、資産評価部１２０Ａと、投資情報データベース１２１と、顧客情報データベース１２２と、評価結果データベース１２３と、注文データ生成部１３０Ａとを備えて構成することができる。

これら各部１１０Ａ，１１１Ａ，１２０Ａ，１２１，１２２，１２３，１３０Ａは、第１実施例で述べた各部と同様の構成を備えているが、相違する点もある。共通する部分については、第１実施例で述べた説明を援用することができるため、以下、相違点を中心に説明する。

契約登録部１１０Ａは、端末３または端末３０から入力される定期換金サービスの契約内容を、契約情報データベース１１１Ａに登録させる。契約内容の詳細は後述する。資産評価部１２０Ａは、仮想ファンドについて評価し、その評価結果を評価結果データベース１２３に記憶させる。注文データ生成部１３０Ａは、評価結果データベース１２３に記憶された調査結果に基づいて、換金注文データファイル１３２Ａを生成する。生成された換金注文データファイル１３２Ａは、口座管理システム４０に入力され、利益が現金化されて顧客に還元される。

図１３は、契約情報データベース１１１Ａ等の構成を示す説明図である。契約情報データベース１１１Ａは、例えば、契約IDと、口座IDと、ファンドIDと、換金条件と、換金対象と、解約金額と、頻度/期間とを対応付けることにより、構成可能である。

換金条件とは、仮想ファンドに生じた利益を換金するための条件を示す情報である。例えば、換金条件として「10%以上」と設定されている場合、仮想ファンドに10%以上の利益が生じたときは、この利益分に相当する個別ファンドが解約される。換金対象とは、換金させる個別ファンドを決定するための情報である。例えば、換金対象として「最低利益」が設定されている場合、仮想ファンドを構成する各個別ファンドのうち、最も利益率の低い個別ファンドが選択される。これに限らず、例えば、最も利益率の高い個別ファンドから解約することもできる。解約金額とは、換金金額を決定するための情報である。例えば、解約金額として「利益全部」が設定されている場合、仮想ファンドに発生した利益全体に相当する分だけ、個別ファンドが解約される。これに限らず、仮想ファンドに生じた利益の一部を換金させるように、顧客は指定することもできる。

なお、図１３中の契約C04では、換金条件と換金対象に値を設定せず、解約金額として一定金額（例えば５万円）を設定している。従って、この契約C04では、仮想ファンドに利益が発生しているか否かを問わずに、決まった額だけ個別ファンドが解約されていくことになる。このように、本実施例では、利益が発生した場合のみ、その利益の全部または一部を換金するサービスと、損益を問わずに一定額または一定率だけ換金するサービスとを、共通の契約情報データベース１１１Ａを用いて実現することができる。

図１４は、資産評価部１２０Ａ等の構成を示す説明図である。資産評価部１２０Ａは、前記実施例で述べたと同様に、仮想化された各個別ファンドの損益をそれぞれ算出し、この個別損益に基づいて、仮想ファンドの損益を評価する。

図１４中に示す例では、契約C03の仮想ファンドに８０万円の利益が生じているため、資産評価部１２０Ａは、この利益を顧客に還元すべく、契約C03について「８０万円分の換金」という評価結果を与える。一方、契約C04に着目すると、この仮想ファンドでは、２８万円の損失が生じているが、契約C04では、毎月一定額を換金するように指定されている。そこで、資産評価部１２０Ａは、契約C04について、「５万円分の換金」という評価結果を与える。

注文データ生成部１３０Ａは、評価結果データベース１２３を参照し、各仮想ファンドの評価結果に応じた換金注文データファイル１３２Ａを生成する。

図１５は、資産評価処理を示すフローチャートである。資産評価処理は、図８に示すフローチャートと同様の処理を行うが、本実施例では、顧客への「警告」を行わない点で、前記実施例と相違する。

資産評価部１２０Ａは、契約情報データベース１１１Ａを参照し（Ｓ６１）、評価を行うべき仮想ファンドが存在するか否かを判定する（Ｓ６２）。評価すべきタイミングが到来している仮想ファンドが存在する場合（S62：YES）、資産評価部１２０Ａは、投資情報データベース１２１及び顧客情報データベース１２２をそれぞれ参照し（S63，S64）、各個別ファンド毎の損益をそれぞれ算出する（Ｓ６５）。

資産評価部１２０Ａは、各個別ファンドの損益に基づいて、仮想ファンドの損益及び損益率をそれぞれ算出する（S66，S67）。そして、資産評価部１２０Ａは、仮想ファンドの利益率が換金条件に示されている所定値（例えば10%）に達したか否かを判定し（Ｓ６８）、利益率が換金用所定値に達している場合（S68：YES）、その契約IDについて「換金」の評価を与え、評価結果データベース１２３に記憶させる（Ｓ６９）。

次に、図１６は、口座管理システム４０により実行される換金処理を示すフローチャートである。口座管理システム４０は、換金注文データファイルを受領すると（S71：YES）、運用会社のコンピュータシステム２に換金を指示する（Ｓ７２）。

なお、契約登録処理及び注文データ生成処理については、図示を省略する。これらの処理は、前記実施例で述べた説明及び図面をそれぞれ援用可能である。例えば、契約登録処理では、図７に示すフローチャートにおいて、図１３中に示す契約情報データベース１１１Ａの各項目に関するデータをそれぞれ取得すればよい。また、例えば、注文データ生成処理では、図９に示すフローチャートにおいて、Ｓ４２，Ｓ４３，Ｓ４４を省略し、換金の評価が与えられた仮想ファンド（契約ID）についてのみ、換金注文データファイル１３２Ａを生成すればよい。

図１７は、本実施例の定期換金サービスによる仮想ファンド及び個別ファンドの変化をそれぞれ示す説明図である。
図１７（ａ）に示すように、各個別ファンドF01〜F03は、時間変化に応じて、それぞれの価格が変化している。図１７（ｂ）は仮想ファンドC03の推移を示す。時刻t0は、初期状態を示す。初期状態における各ファンドF01〜F03の価格は、それぞれの取得コストである。

時刻t0から時刻t1に変化して、仮想ファンドC03の価格が取得コストよりもM３だけ値上がりした場合、この上昇率が「換金条件」に設定された値以上のときは、利益Ｍ３の範囲内で換金が行われる。ここでは、利益Ｍ３の全てに相当する額だけ、個別ファンドF01を解約するものとする。

時刻t1a において、利益Ｍ３に相当する分だけ個別ファンドF01が解約されるため、このファンドF01の残高（口数）は減少する。この換金時刻t1aにおける仮想ファンドC03の価値は、初期状態t0の価値と等しい。

さらに時間が経過して時刻t2に至り、仮想ファンドに再び利益Ｍ４が生じた場合、この利益Ｍ４に相当する額だけ個別ファンドF01，F02が解約される。図示の例では、個別ファンドF01の残高が利益Ｍ４に及ばないため、次に利益率の低い個別ファンドF02が部分的に解約されている。

このように構成される本実施例でも、一つまたは複数の個別ファンドを仮想化して、全体として管理できるため、前記実施例で述べたと同様に、使い勝手が向上する。これに加えて、本実施例では、仮想ファンドに利益が発生した場合にのみ、その利益分を換金して顧客に還元する。従って、顧客は、元本を減らすことなく利益を受け取ることができ、堅実な投資を行うことができる。また、例えばファンド毎に毎月分配金を出すような場合、運用に制約を受けるため、運用会社で柔軟な運用を行うことができなくなって、運用効率が低下する可能性がある。これに対し、本実施例では、個別ファンドを仮想化するため、運用会社における運用方針を何ら制限することなく、顧客に利益を還元可能である。

図１８〜図２１に基づいて第３実施例を説明する。本実施例では、顧客が設定した保有割合（ポートフォリオ）を目標値として、仮想ファンドの構成を制御する。本実施例では、保有割合に近づくように、個別ファンドを追加購入したり、個別ファンドを部分的に解約することができる。以下の説明では、主に追加購入の場合を例に挙げて説明する。本実施例では、このサービスを分散購入サービスと呼ぶが、ポートフォリオ制御型サービスまたは保有割合維持型サービス等と呼び変えることもできる。

図１８は、分散購入サービスを提供する場合の資産運用管理システム１の構成を示す説明図である。資産運用管理システム１には、分散購入システム１０Ｂが構築される。

分散購入システム１０Ｂは、例えば、契約登録部１１０Ｂと、契約情報データベース１１１Ｂと、資産評価部１２０Ｂと、投資情報データベース１２１と、顧客情報データベース１２２と、評価結果データベース１２３と、注文データ生成部１３０Ｂとを備えて構成可能である。

これら各部１１０Ｂ，１１１Ｂ，１２０Ｂ，１２１，１２２，１２３，１３０Ｂは、第１実施例で述べた各部と同様の構成を備えているが、相違する点もある。共通する部分については、第１実施例で述べた説明を援用できる。以下、相違点を中心に説明する。

契約登録部１１０Ｂは、端末３または端末３０から入力される分散購入サービスの契約内容を、契約情報データベース１１１Ｂに登録させる。契約内容の詳細は後述する。資産評価部１２０Ｂは、仮想ファンドについて保有割合を評価し、評価結果を評価結果データベース１２３に記憶させる。注文データ生成部１３０Ｂは、評価結果データベース１２３に記憶された調査結果に基づいて、購入注文データファイル１３２Ｂを生成する。生成された購入注文データファイル１３２Ｂは、口座管理システム４０に入力され、一つまたは複数の個別ファンドが購入される。

図１９は、契約情報データベース１１１Ｂ等の構成を示す説明図である。契約情報データベース１１１Ｂは、例えば、契約IDと、口座IDと、ファンドIDと、ポートフォリオと、購入条件と、頻度/期間とを対応付けることにより、構成できる。

ポートフォリオとは、仮想ファンドを構成する各個別ファンドの保有割合を示す情報（目標値）である。一つまたは複数の個別ファンドをグループ化し、各ファンドグループの割合を設定することができる。

図１９に示す例では、個別ファンドF01，F02がファンドグループFaに所属し、個別ファンドF03がファンドグループFbに所属し、個別ファンドF04がファンドグループFcに所属している。そして、これら各ファンドグループFa，Fb，Fcは、契約C05に関連づけられ、仮想ファンドとして仮想化されている。そして、図１９に示す例では、ファンドグループFaは50%、ファンドグループFbは40%、ファンドグループFcは10%の保有比率を目標とする様子が示されている。保有割合の合計は100%である。このように、本実施例では、ファンドグループによる第１の仮想化と、契約IDによる第２の仮想化との複数段階の仮想化が行われる。

購入条件とは、顧客が定期的に個別ファンドを追加購入するような場合に指定される情報であり、定期的に購入する金額を示す情報が記憶される。どの銘柄の個別ファンドを購入するかのファンド選択情報は必要ない。その月の資金をどの個別ファンドに振り分けるかは、分散購入システム１０Ｂがポートフォリオに基づいて決定する。図１９に示す例では、毎月１０日に５万円分の個別ファンドを購入する様子が示されている。

図２０は、資産評価部１２０Ｂ等の構成を示す説明図である。本実施例の資産評価部１２０Ｂは、仮想ファンドを構成する各個別ファンドの現在価格を取得してポートフォリオを分析し、現在の保有割合と目標値との偏差を算出し、この偏差を少なくするように、購入する個別ファンド及び購入額を決定する。

図２０に示す例では、ファンドグループFaの割合が56.1%，同Fbの割合が16.7%、同Fcの割合が27.2%となっている。そこで、資産評価部１２０Ｂは、グループFa，Fcの割合をそれぞれ減じさせ、グループFbの割合を増加させるように、購入する個別ファンド及び購入額を決定する。この例では、その月の投資額全てが、グループFbの個別ファンドF03に振り向けられる。個別ファンドF03を５万円分購入することにより、保有割合は、グループFaが54.8%、グループFbが18.6%、グループFcが26.6%にそれぞれ変化し、目標値に近づくことになる。保有割合の合計は100%であり、追加購入の前後で変化しない。

どの個別ファンドを購入するかのファンド選択情報は、評価結果データベース１２３内に記憶させてもよいし、プログラム間通信等の手段により、資産評価部１２０Ｂから注文データ生成部１３０Ｂに直接受け渡すようにしてもよい。

図２１は、資産評価処理を示すフローチャートである。資産評価部１２０Ｂは、契約情報データベース１１１Ｂを参照し（Ｓ８１）、評価を行うべき仮想ファンドが存在するか否かを判定する（Ｓ８２）。評価タイミングが到来している仮想ファンドが存在する場合（S82：YES）、資産評価部１２０Ｂは、投資情報データベース１２１を参照し（Ｓ８３）、保有割合を算出する（Ｓ８４）。

そして、資産評価部１２０Ｂは、各個別ファンドの保有割合が目標値に近づくように、購入する個別ファンド及びその購入金額を決定し（Ｓ８５）、評価結果データベース１２３に記憶させる（Ｓ８６）。

このように構成される本実施例では、顧客の指定したポートフォリオを実現するように、複数の個別ファンドを容易に管理することができ、利便性が向上する。

図２２は、第４実施例の全体構成を示す説明図である。本実施例では、資産運用管理システム１を金融機関４Ａ〜４Ｃとは別の機関（例えば、インターネットプロバイダ等）に設ける。資産運用管理システム１は、複数の金融機関４Ａ〜４Ｃに分散して購入されている個別ファンドＦ１〜Ｆ４を、仮想化して一元管理する。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、当業者であれば、前記各実施例を適宜組み合わせることができる。
例えば、自動換金を行うか否か等の基準として、「率」を例に挙げて説明したが、「金額」を用いることもできる。また、株価指数等の指標に対する変化率に基づいて、警告や換金の閾値を設定することもできる。
さらに、警告を所定回数または所定期間発した場合でも、顧客による換金指示が入力されない場合は、警告の評価を受けたファンドを強制的に換金させるようにしてもよい。
また、定期的に個別ファンドを追加購入して、ポートフォリオを自律的に維持する場合を例に挙げて説明したが、これに限らず、例えば、個別ファンドを部分的に解約して、保有比率を維持するようにしてもよい。

本発明の実施形態の全体概念を示す説明図である。 資産運用管理システムのハードウェア構成、ソフトウェア構成及びネットワーク構成の一例をそれぞれ示す説明図である。 資産運用管理システムを自動換金サービスに適用した場合のブロック図である。 契約情報データベース、顧客情報データベース及び投資情報データベースの構成例をそれぞれ示す説明図である。 資産評価部及び評価結果データベースの構成例をそれぞれ示す説明図である。 自動換金サービス処理の全体を示すフローチャートである。 契約登録処理を示すフローチャートである。 資産評価処理を示すフローチャートである。 警告・換金データ生成処理を示すフローチャートである。 警告・換金処理を示すフローチャートである。 個別ファンド及び仮想ファンドの推移を示す説明図である。 第２実施例に係り、資産運用管理システムを定期換金サービスに適用した場合のブロック図である。 契約情報データベース等の構成例を示す説明図である。 資産評価部等の構成例を示す説明図である。 資産評価処理を示すフローチャートである。 換金処理を示すフローチャートである。 個別ファンド及び仮想ファンドの推移を示す説明図である。 第３実施例に係り、資産運用管理システムを分散購入サービスに適用した場合のブロック図である。 契約情報データベース等の構成例を示す説明図である。 資産評価部等の構成例を示す説明図である。 資産評価処理を示すフローチャートである。 第４実施例に係る構成を示す説明図である。

符号の説明

１…資産運用管理システム、１Ａ…金融商品仮想化部、１Ｂ…資産評価部、１Ｃ…自動換金サービス部、１Ｄ…定期換金サービス部、１Ｅ…分散購入サービス部、２…運用会社のコンピュータシステム、３…端末、４Ａ〜４Ｃ…金融機関、１０…自動換金システム、１０Ａ…定期換金システム、１０Ｂ…分散購入システム、２０…投資情報システム、３０…店舗端末、４０…口座管理システム、CN１，CN２…通信ネットワーク、GD…ゲートウェイ装置、１１０，１１０Ａ，１１０Ｂ…契約登録部、１１１，１１１Ａ，１１１Ｂ…契約情報データベース、１２０，１２０Ａ，１２０Ｂ…資産評価部、１２１…投資情報データベース、１２２…顧客情報データベース、１２３…評価結果データベース、１３０…警告・注文データ生成部、１３０Ａ，１３０Ｂ…注文データ生成部、１３１…警告データファイル、１３２，１３２Ａ，１３２Ｂ…注文データファイル

Claims (9)

1. 一つまたは複数の個別金融商品に関する情報を仮想金融商品に関する情報にそれぞれ関連づけて記憶させることにより、前記各個別金融商品に基づいて前記仮想金融商品を生成させる仮想化手段と、
   前記各個別金融商品の現在価値をそれぞれ取得する個別価値取得手段と、
   取得された前記各個別金融商品の現在価値と予め設定された所定の条件とに基づいて、前記仮想金融商品を評価し、その評価結果を記憶させる評価手段と、
   前記記憶された評価結果に基づいて、前記各個別金融商品毎にそれぞれ所定のデータを生成可能なデータ生成手段と、
   を備えた金融商品管理システム。
2. 前記評価手段は、前記各個別金融商品の取得コストを考慮して前記仮想金融商品を評価し、その評価結果を記憶させる請求項１に記載の金融商品管理システム。
3. 前記評価手段は、前記各個別金融商品の取得コスト及び前記各個別金融商品の現在価値に基づいて、前記仮想金融商品の損益を算出し、この算出された損益が予め設定された第１の所定値に到達した場合は、前記各個別金融商品のうち所定の個別金融商品を換金させるための換金評価を行い、
   前記データ生成手段は、前記換金評価を検出すると、前記所定の個別金融商品に関する換金データを生成する請求項１に記載の金融商品管理システム。
4. 前記評価手段は、前記各個別金融商品の取得コスト及び前記各個別金融商品の現在価値に基づいて、前記仮想金融商品の損益を算出し、この算出された損益が予め設定された第２の所定値に到達した場合は、警告を出力させるための警告評価を行い、
   前記データ生成手段は、前記警告評価を検出すると、前記仮想金融商品に関する警告データを生成する請求項１に記載の金融商品管理システム。
5. 前記評価手段は、前記仮想金融商品に利益が発生している場合、その利益の範囲内で前記所定の個別金融商品を換金させるための換金評価を行う請求項１に記載の金融商品管理システム。
6. 前記評価手段は、前記各個別金融商品に関して予め設定されている保有割合に近づくように、前記各個別金融商品のうち所定の個別金融商品を購入または換金させるための評価を行い、
   前記データ生成手段は、前記評価を検出すると、前記所定の個別金融商品に関する購入データまたは換金データを生成する請求項１に記載の金融商品管理システム。
7. 仮想金融商品として仮想化させる一つまたは複数の個別金融商品に関する情報及び所定の条件をそれぞれ記憶する第１記憶手段と、
   前記各個別金融商品の取得コストをそれぞれ記憶する第２記憶手段と、
   前記各個別金融商品の現在価格をそれぞれ記憶する第３記憶手段と、
   前記仮想金融商品に関する評価結果を記憶する第４記憶手段と、
   前記仮想金融商品を評価して、その評価結果を前記第４記憶手段に記憶させる評価手段と、
   前記第４記憶手段に記憶された前記評価結果に基づいて、前記各個別金融商品毎にそれぞれ所定のデータを生成可能なデータ生成手段とを備え、
   前記評価手段は、
   （１）前記第１記憶手段に記憶されている前記各個別金融商品毎の個別損益を、前記第２記憶手段に記憶されている前記各個別金融商品の取得コスト及び前記第３記憶手段に記憶されている前記各個別金融商品の現在価格に基づいてそれぞれ算出し、
   （２）算出された前記各個別損益に基づいて、前記仮想金融商品の損益を算出し、
   （３）前記算出された前記仮想金融商品の損益と前記第１記憶手段に記憶されている前記所定の条件とに基づいて、前記仮想金融商品を評価し、その評価結果を前記第４記憶手段に記憶させるようになっている金融商品管理システム。
8. 仮想金融商品として仮想化させる一つまたは複数の個別金融商品に関する情報及び所定の条件を第１記憶手段に記憶させるステップと、
   第２記憶手段からそれぞれ取得される前記各個別金融商品の取得コストと、第３記憶手段からそれぞれ取得される前記各個別金融商品の現在価格とに基づいて、前記各個別金融商品の個別損益をそれぞれ算出するステップと、
   算出された前記各個別損益に基づいて前記仮想金融商品の損益を算出し、この算出された損益と前記所定の条件とに基づいて前記仮想金融商品を評価し、この評価結果を第４記憶手段に記憶させるステップと、
   前記第４記憶手段に記憶された前記評価結果に基づいて、前記各個別金融商品毎にそれぞれ所定のデータを生成するステップと、
   生成された前記所定のデータを出力させるステップと、
   をコンピュータに実行させるためのコンピュータプログラム。
9. 一つまたは複数の個別金融商品を仮想化して仮想金融商品とし、
   前記仮想金融商品について所定の条件を設定し、
   少なくとも前記各個別金融商品の現在価格に基づいて前記仮想金融商品を評価し、
   前記仮想金融商品の評価結果と前記所定の条件とに基づいて、前記各個別金融商品のうち全部または所定の一部の個別金融商品について、売買指示を発行させる金融商品管理方法。
   

Images