JP2009087051A - 目論見書管理システム、目論見書管理方法及び目論見書管理プログラム - Google Patents

Abstract

【課題】顧客に対して的確な目論見書を交付するとともに、この目論見書について効率的な理解を促し、商品を販売するための目論見書管理システム、目論見書管理方法及び目論見書管理プログラムを提供する。
【解決手段】取引管理サーバ２０の制御部２１は、ユーザ認証を行ない、目論見書の交付履歴を検索する。交付履歴を特定できた場合には、利用可能日、目論見書のバージョンを確認する。交付バージョンが最新バージョンである場合には、取引を許可する。一方、目論見書の送付処理においては、制御部２１は、交付バージョンの目論見書と最新バージョンの目論見書との変更箇所を抽出し、ブックマークを貼付する。そして、ブックマークを貼付した最新バージョンの目論見書ファイルを送付する。
【選択図】図１

Description

本発明は、金融商品を販売する場合に交付する目論見書を管理するための目論見書管理システム、目論見書管理方法及び目論見書管理プログラムに関する。

今日、金融取引において、例えば、投資信託、外貨預金や金融派生商品（デリバティブ取引）などの多様な金融商品が提供されている。これらの金融商品を利用することにより、顧客は多様な方法で資産運用を図ることができる。

しかし、これらの商品の中にはリスクを伴うものもある。例えば、金利・為替・株式相場などの価格変動によって元本割れが生じるリスク（市場リスク）がある商品も含まれる。また、金融商品販売者や社債発行企業等の業務や財産の信用状況の変化によっても元本割れのおそれ（信用リスク）がある場合もある。さらに、商品によっては権利行使期間や解約期間の制限がある場合もある。

従って、金融商品の販売者は、金融商品を販売する際、価格変動リスク、販売者等の信用リスク、権利行使・中途解約等の制限等の重要事項について顧客に説明する必要がある。さらに、投資信託を販売する際、発行する有価証券に関する情報、有価証券の発行者に関する情報等を記載した目論見書を投資家に交付することが法律上義務付けられている。

そこで、効率的かつ的確に商品の販売を行なうための金融商品販売管理システムが検討されている（例えば、特許文献１を参照。）。この文献記載の金融商品販売管理システムの管理コンピュータは携帯電話端末から商品申込の受付を行なう。商品が選択された場合、管理コンピュータは申込の事前確認の処理を実行する。ここでは、顧客の所持する目論見書の特定のページの閲覧を促し、そのページに印字された確認番号の送信を促す。管理コンピュータが受信した確認番号の照合ができた場合には、照合結果を取引データ記憶部に記録し、金融商品を販売するための処理を行なう。

また、目論見書の交付実績を管理する金融商品販売支援システムも検討されている（例えば、特許文献２を参照。）。この文献記載の金融商品販売支援システムは、顧客に対する目論見書の交付実績をデータベースに登録する。そして、目論見書に対して顧客から確認書を受領した場合に受領実績を目論見書の交付実績に含める。登録された目論見書の交付実績をデータベースで顧客毎に管理するデータ管理手段を備えている。

更に、インターネットを通じて交付する目論見書の版の変更管理を行なう投資信託電子取引装置も検討されている（例えば、特許文献３を参照。）。この文献記載の投資信託電子取引装置は、投資信託に対応する目論見書データを登録する目論見書データベースと、目論見書の利用者への交付履歴を記憶する交付履歴データベースとを備える。そして、投資信託の買付け注文等を受け付けたとき、その投資信託に対応する目論見書データの最新の版をその利用者へ交付済みか否かを判定する。ここで、未交付あるいは交付済みのものが古い版の場合に、最新の版の目論見書データをその利用者へ自動配信する。
特開２００４−９４３７７号公報（第１頁） 特開２００３−８５３６３号公報（第１頁） 特開２００２−２６９３４４号公報（第１頁）

しかし、目論見書の交付には、ネット経由、郵送、店頭交付等、多様なルートがある。特に郵送の場合には、顧客の手元に目論見書が届くまでに時間がかかるために、この時間を考慮して、取引を行なう必要がある。

また、顧客が所有している目論見書が最新のものではない場合、最新バージョンの目論見書を再交付する必要があるが、その場合には、以前のバージョンの目論見書の内容との違いが分かりにくいことがある。

本発明は、上記問題点を解決するためになされたものであり、その目的は、顧客に対して的確な目論見書を交付するとともに、この目論見書について効率的な理解を促し、商品を販売するための目論見書管理システム、目論見書管理方法及び目論見書管理プログラムを提供することにある。

上記問題点を解決するために、請求項１に記載の発明は、ユーザ毎に交付した目論見書のバージョン情報を記録した交付バージョン情報記憶手段と、バージョン毎に目論見書ファイルを記録した目論見書管理情報記憶手段と、目論見書の管理を行なう制御手段とを備えた目論見書管理システムであって、前記制御手段が、ユーザ端末からアクセス要求を受信した場合、ユーザ認証を行なうユーザ認証手段、前記ユーザ端末から取引要求を受信した場合、前記交付バージョン情報記憶手段を用いて、前記ユーザ認証したユーザに対して交付した目論見書の交付バージョンを特定する目論見書確認手段、前記目論見書管理情報記憶手段に記録された最新バージョンと前記交付バージョンとを比較し、バージョンが一致しない場合には、両バージョンの差分を特定し、この差分を明示した差分情報表示媒体を生成する差分抽出手段、前記差分情報表示媒体を付加した最新バージョンの目論見書を前記ユーザ端末に送信する送付処理手段を備えたことを要旨とする。

請求項２に記載の発明は、請求項１に記載の目論見書管理システムにおいて、バージョン毎に、改定箇所、改定種別を記録した改定履歴記憶手段を更に備え、前記差分抽出手段は、両バージョンの差分について、前記改定履歴記憶手段を用いて、改定箇所、改定種別を取得し、前記改定種別に応じて、前記改定箇所の表示方法を変更した差分情報表示媒体を生成することを要旨とする。

請求項３に記載の発明は、請求項１又は２に記載の目論見書管理システムにおいて、前記交付バージョン情報記憶手段には、ユーザに対する交付方法及び送付日に関する情報が更に記録されており、前記制御手段が、前記交付方法においてユーザに対して目論見書を郵送にて交付したことが記録されている場合には、前記目論見書の送付日を特定する手段を更に備え、前記目論見書確認手段は、前記送付日から所定の所要日数を加算して算出した配達予測日が現在日付より先の場合には、この目論見書を交付バージョンとして特定しないことを要旨とする。

請求項４に記載の発明は、請求項３に記載の目論見書管理システムにおいて、前記制御手段が、前記ユーザの住所情報を取得し、前記住所に基づいて配達所要日数を算出する配達予測手段を更に備えたことを要旨とする。

請求項５に記載の発明は、請求項４に記載の目論見書管理システムにおいて、発送処理を行なう日程が記録された発送処理カレンダと、配達処理が行なわれる日程が記録された郵便配達カレンダとを記録した郵送スケジュール記憶手段を更に備え、前記配達予測手段は、前記発送処理カレンダと郵便配達カレンダに基づいて、配達予測日を算出することを要旨とする。

請求項６に記載の発明は、ユーザ毎に交付した目論見書のバージョン情報を記録した交付バージョン情報記憶手段と、バージョン毎に目論見書ファイルを記録した目論見書管理情報記憶手段と、目論見書の管理を行なう制御手段とを備えた目論見書管理システムを用いて、目論見書を管理する方法であって、前記制御手段が、ユーザ端末からアクセス要求を受信した場合、ユーザ認証を行なうユーザ認証段階、前記ユーザ端末から取引要求を受信した場合、前記交付バージョン情報記憶手段を用いて、前記ユーザ認証したユーザに対して交付した目論見書の交付バージョンを特定する目論見書確認段階、前記目論見書管理情報記憶手段に記録された最新バージョンと前記交付バージョンとを比較し、バージョンが一致しない場合には、両バージョンの差分を特定し、この差分を明示した差分情報表示媒体を生成する差分抽出段階、前記差分情報表示媒体を付加した最新バージョンの目論見書を前記ユーザ端末に送信する送付処理段階を実行することを要旨とする。

請求項７に記載の発明は、ユーザ毎に交付した目論見書のバージョン情報を記録した交付バージョン情報記憶手段と、バージョン毎に目論見書ファイルを記録した目論見書管理情報記憶手段と、目論見書の管理を行なう制御手段とを備えた目論見書管理システムを用いて、目論見書を管理するプログラムであって、前記制御手段を、ユーザ端末からアクセス要求を受信した場合、ユーザ認証を行なうユーザ認証手段、前記ユーザ端末から取引要求を受信した場合、前記交付バージョン情報記憶手段を用いて、前記ユーザ認証したユーザに対して交付した目論見書の交付バージョンを特定する目論見書確認手段、前記目論見書管理情報記憶手段に記録された最新バージョンと前記交付バージョンとを比較し、バージョンが一致しない場合には、両バージョンの差分を特定し、この差分を明示した差分情報表示媒体を生成する差分抽出手段、前記差分情報表示媒体を付加した最新バージョンの目論見書を前記ユーザ端末に送信する送付処理手段として機能させることを要旨とする。

（作用）
請求項１、６又は７に記載の発明によれば、制御手段が、ユーザ端末からアクセス要求を受信した場合、ユーザ認証を行なう。そして、ユーザ端末から取引要求を受信した場合、交付バージョン情報記憶手段を用いて、ユーザ認証したユーザに対して交付した目論見書の交付バージョンを特定する。ここで、目論見書管理情報記憶手段に記録された最新バージョンと交付バージョンとを比較し、バージョンが一致しない場合には、両バージョンの差分を特定し、この差分を明示した差分情報表示媒体を生成する。そして、差分情報表示媒体を付加した最新バージョンの目論見書をユーザ端末に送信する。これにより、顧客に対する目論見書の交付履歴を考慮して、的確な取引管理を行なうことができる。ユーザにとっても差分情報表示媒体を利用して、効率的に目論見書の内容を把握することができる。

請求項２に記載の発明によれば、制御手段は、両バージョンの差分について、改定履歴記憶手段を用いて、改定箇所、改定種別を取得する。そして、改定種別に応じて、改定箇所の表示を変更した差分情報表示媒体を生成する。これにより、ユーザは、更に効率的に目論見書の内容を把握することができる。

請求項３に記載の発明によれば、交付方法においてユーザに対して目論見書を郵送にて交付したことが記録されている場合には、目論見書の送付日を特定する。そして、目論見書確認手段は、送付日から所定の所要日数を加算して算出した配達予測日が現在日付より先の場合には、この目論見書を交付バージョンとして特定しない。これにより、まだ配達されていない目論見書による取引を防止することができる。

請求項４に記載の発明によれば、ユーザの住所情報を取得し、住所に基づいて配達所要日数を算出する。これにより、ユーザの住所を考慮して、的確な配達日を予測することができる。

請求項５に記載の発明によれば、制御手段は、発送処理カレンダと郵便配達カレンダに基づいて、配達予測日を算出する。これにより、発送処理事情や郵便配達事情を考慮して、的確な配達日を予測することができる。

本発明によれば、顧客に対して的確な目論見書を交付するとともに、この目論見書について効率的な理解を促し、商品を販売するための目論見書管理システム、目論見書管理方法及び目論見書管理プログラムを提供することができる。

以下、本発明を具体化した一実施形態を図１〜図５に基づいて説明する。本実施形態では、ネットワークを介して顧客に対して金融商品を販売する場合に交付する目論見書を管理する目論見書管理システム、目論見書管理方法及び目論見書管理プログラムとして説明する。金融商品の提供者（ここでは金融機関）が、金融商品を販売する場合には、商品説明媒体としての目論見書やパンフレットを予め交付する。これらの目論見書やパンフレットには、金融商品の購入を希望する顧客が読んでおくべき内容（金融商品に関する内容説明や注意事項等）が記載される。

本実施形態では、図１に示すように、ユーザ端末１０と取引管理サーバ２０とがインターネットを介して接続される。
ユーザ端末１０は、顧客が取引管理サーバ２０にアクセスし、金融商品の購入取引を行なう場合に用いるコンピュータ端末である。このユーザ端末１０は、ディスプレイ等の出力手段、キーボード及びポインティングデバイス等の入力手段を備えている。顧客は、ディスプレイに表示された各種画面を閲覧しながら、キーボードやポインティングデバイスを用いて入力を行なう。このユーザ端末１０は、ブラウザプログラムを格納しており、ブラウザ上で、ＨＴＭＬ（HyperText Markup Language ）等で記述されたウェブページを出力する。

取引管理サーバ２０は、ユーザ端末１０から受信した金融商品の購入要求に応じて金融商品の販売管理を行なう取引処理を実行するコンピュータシステムである。この取引処理の中で目論見書管理処理が行なわれる。

取引管理サーバ２０は、制御部２１、顧客管理データ記憶部２２、目論見書管理データ記憶部２３、バージョン管理データ記憶部２４、所要日数データ記憶部２５を備えている。

この制御部２１は、ユーザ端末１０と通信を行なう制御手段（ＣＰＵ、ＲＡＭ及びＲＯＭ等）として機能し、後述する処理（ユーザ認証段階、目論見書確認段階、差分抽出段階、送付処理段階等を含む処理）を行なう。このため、目論見書管理プログラムを実行することにより、制御部２１は、ユーザ認証手段２１１、取引管理手段２１２、目論見書確認手段２１３、取引可否判断手段２１４、差分抽出手段２１５、送付処理手段２１６として機能する。

ここで、ユーザ認証手段２１１は、取引管理サーバ２０にアクセスした顧客のユーザ認証を行なう。
取引管理手段２１２は、顧客から金融商品の購入要求を受け付けることにより金融商品の取引管理を行なう。

目論見書確認手段２１３は、顧客に対して交付された目論見書のバージョンを特定する
。
取引可否判断手段２１４は、顧客に対して交付された目論見書のバージョンに応じて、取引可否を判断する。

差分抽出手段２１５は、顧客に対して交付された目論見書と、最新バージョン目論見書との相違点を特定する。
送付処理手段２１６は、顧客に対する目論見書の送付管理を行なう。送付処理手段２１６は、更に配達予測手段として機能する。

また、顧客管理データ記憶部２２には、図２（ａ）に示すように、金融機関の顧客であって、本サービスを利用しての金融商品を購入する顧客についての顧客管理レコード２２０が記録されている。この顧客管理レコード２２０は、インターネットを介して金融商品を購入する利用申請を行なった場合に登録される。この顧客管理レコード２２０は、顧客コード、パスワード、住所コードに関するデータを含んで構成される。

顧客コードデータ領域には、各顧客を特定するための識別子に関するデータが記録される。
パスワードには、各顧客を認証するためのデータが記録される。このパスワードは、ログイン要求時に本人を認証するために用いられる。
住所コードデータ領域には、顧客の住所が含まれる地域を特定するための識別子に関するデータが記録される。

目論見書管理データ記憶部２３は目論見書管理情報記憶手段として機能し、図２（ｂ）に示すように、金融機関が金融商品を販売する場合に顧客に交付する目論見書についての目論見書管理レコード２３０が記録されている。この目論見書管理レコード２３０は、顧客に交付する目論見書を決定した場合に登録される。この目論見書管理レコード２３０は、商品コード、バージョンコード、目論見書ファイル、リリース日に関するデータを含んで構成される。

商品コードデータ領域には、金融機関が提供する各金融商品を特定するための識別子に関するデータが記録される。
バージョンコードデータ領域には、目論見書のバージョンを特定するための識別子に関するデータが記録される。

目論見書ファイル領域には、顧客に交付する目論見書のコンテンツを含めた電子ファイルが記録される。本実施形態では、目論見書ファイルのファイル形式としてＰＤＦ（Portable Document Format）形式を用いる。
リリース日データ領域には、このバージョンの目論見書の交付を開始した時期、或いは交付予定時期に関するデータが記録される。

バージョン管理データ記憶部２４は交付バージョン情報記憶手段として機能し、図２（ｃ）に示すように、顧客に交付した目論見書のバージョンを管理するためのバージョン管理レコード２４０が記録されている。このバージョン管理レコード２４０は、顧客に対して目論見書を交付したときに登録される。このバージョン管理レコード２４０は、顧客コード、商品コード、バージョンコード、交付方法コード、送付日、利用可能日に関するデータを含んで構成される。

顧客コードデータ領域には、目論見書を交付した顧客を特定するための識別子に関するデータが記録される。
商品コードデータ領域には、顧客に交付した目論見書の対象商品を特定するための識別
子に関するデータが記録される。

バージョンコードデータ領域には、顧客に交付した目論見書のバージョンを特定するための識別子に関するデータが記録される。
交付方法コードデータ領域には、顧客に対して目論見書を交付した方法に関するデータが記録される。本実施形態では、ネットワーク経由で交付する場合と、郵送により交付する場合とがある。

送付日データ領域には、この顧客に対して目論見書を交付した日付に関するデータが記録される。
利用可能日データ領域には、顧客に対して交付した目論見書が利用可能状態になると予測される日付に関するデータが記録される。この利用可能日は、後述するように、目論見書の交付方法によって異なる。具体的には、ネット経由により目論見書を交付した場合には、利用可能日として送信日が設定される。一方、郵送により目論見書を交付した場合には、送付日に対して所要日数を加算した日付が利用可能日として設定される。

所要日数データ記憶部２５には、図２（ｄ）に示すように、郵送した場合の所要日数を算出するための地域別所要日数テーブル２５０及び期間考慮テーブル２５１が記録されている。この地域別所要日数テーブル２５０及び期間考慮テーブル２５１は、地域毎の所要日数や、繁忙期の付加日数を決定したときに登録される。

この地域別所要日数テーブル２５０は、地域コード、通常所要日数に関するデータを含んで構成される。
地域コードデータ領域には、住所に対応した各地域を特定する識別子に関するデータが記録される。この地域コードとしては、例えば、郵便番号を用いることができる。
通常所要日数データ領域には、目論見書の発送センタから、この地域に郵送した場合の通常所要日数に関するデータが記録される。

期間考慮テーブル２５１には、郵送による所要日数が長くなる時期（特別考慮期間）に対して付加日数に関するデータが記録される。例えば、年末年始の期間については所要日数に加算すべき日数（付加日数）が記録されている。

更に、取引管理サーバ２０は、郵送スケジュール記憶手段としての郵送スケジュール記憶部（図示せず）を備えている。この郵送スケジュール記憶部には、発送処理を行なう日程が記録された発送処理カレンダと、配達処理が行なわれる日程が記録された郵便配達カレンダとを記録されている。

次に、以上のように構成された取引管理サーバ２０において、金融商品の販売取引を行なう場合において、目論見書の取り扱いについての手順を図３〜図５に基づいて説明する。ここでは、目論見書の確認処理、目論見書の送付処理、目論見書の郵送処理の順番に説明する。

（目論見書の確認処理）
まず、図３に従って、目論見書の確認処理を説明する。
金融商品の購入を希望する場合、まず、顧客はユーザ端末１０を用いて取引管理サーバ２０にアクセスする。この場合、取引管理サーバ２０の制御部２１は、ユーザ端末１０に対して、ログイン画面データを送信する。そして、ログイン画面において、顧客コード及びパスワードが入力された場合、ユーザ端末１０は、ログイン要求を取引管理サーバ２０に送信する。このログイン要求には、顧客コード及びパスワードに関するデータを含める。

このログイン要求を受信した取引管理サーバ２０の制御部２１は、ユーザ認証処理を実行する（ステップＳ１−１）。具体的には、制御部２１のユーザ認証手段２１１は、顧客管理データ記憶部２２を用いて、ユーザ端末１０から取得した顧客コード及びパスワードを含む顧客管理レコード２２０を検索する。顧客管理データ記憶部２２に両者が一致する顧客管理レコード２２０が登録されていない場合には、ユーザ認証手段２１１は、その旨を通知し、ログインを拒否する。

一方、顧客コード及びパスワードを照合できた場合には、取引管理サーバ２０の制御部２１は、商品種別の取得処理を実行する（ステップＳ１−２）。具体的には、制御部２１の取引管理手段２１２は、ユーザ端末１０に対して、金融商品一覧画面データを送信する。そして、金融商品一覧画面において、顧客が購入を希望している金融商品が選択された場合には、ユーザ端末１０は、商品購入依頼を送信する。この商品購入依頼には、金融商品一覧画面において選択された金融商品の商品コードに関するデータを含める。

商品購入依頼を受信した取引管理サーバ２０の制御部２１は、目論見書の交付履歴の検索処理を実行する（ステップＳ１−３）。具体的には、制御部２１の目論見書確認手段２１３は、バージョン管理データ記憶部２４を用いて、ユーザ認証された顧客コード及びユーザ端末１０から取得した商品コードが記録されたバージョン管理レコード２４０を検索する。

ここで、バージョン管理レコード２４０を特定できず、目論見書の交付履歴がない場合（ステップＳ１−４において「ＮＯ」の場合）には、顧客が目論見書を店頭において取得している可能性がある。この場合、取引管理サーバ２０の制御部２１は、顧客が所有する目論見書の所有確認処理を実行する（ステップＳ１−５）。具体的には、制御部２１の目論見書確認手段２１３は、ユーザ端末１０に対して目論見書確認画面データを送信する。この目論見書確認画面には、目論見書の有無の入力欄、目論見書を所持している場合の目論見書のバージョンコード入力欄が設けられている。そして、目論見書確認画面において、目論見書の有無や目論見書のバージョンコードが入力された場合、ユーザ端末１０は、目論見書確認依頼を取引管理サーバ２０に送信する。この目論見書確認依頼には、目論見書の有無、更に目論見書を所持している場合には目論見書のバージョンコードに関するデータを含める。

目論見書確認依頼を受信した取引管理サーバ２０の制御部２１は、目論見書の有無確認処理を実行する（ステップＳ１−６）。目論見書を所持していない場合（ステップＳ１−６において「ＮＯ」の場合）には、取引管理サーバ２０の制御部２１は、後述する目論見書の送付処理を実行する（ステップＳ１−７）。

一方、目論見書を所持している場合（ステップＳ１−６において「ＹＥＳ」の場合）には、取引管理サーバ２０の制御部２１は、ユーザ端末１０から受信した目論見書確認依頼により、顧客が所有する目論見書のバージョンの取得処理を実行する（ステップＳ１−８）。

一方、バージョン管理レコード２４０を特定でき、目論見書の交付履歴がある場合（ステップＳ１−４において「ＹＥＳ」の場合）には、取引管理サーバ２０の制御部２１は、利用可能日の取得処理を実行する（ステップＳ１−９）。具体的には、制御部２１の取引可否判断手段２１４は、バージョン管理データ記憶部２４のバージョン管理レコード２４０に記録された利用可能日を取得する。

ここで、現在日付が利用可能日前の場合（ステップＳ１−１０において「ＮＯ」の場合
）には、取引管理サーバ２０の制御部２１は、この目論見書を交付バージョンとして特定せずに取引を保留する（ステップＳ１−１１）。具体的には、制御部２１の取引可否判断手段２１４は、利用可能日以前であることをユーザ端末１０に通知する。この場合、顧客は目論見書が配達されるまで待機する。なお、ここで、制御部２１の取引可否判断手段２１４は、ユーザ端末１０に対して、ネット経由でで最新バージョンの目論見書の送付を推奨するようにしてもよい。この場合、後述する処理により、最新バージョンの目論見書をネット経由で取得した場合には、取引可能となる。

一方、現在日付が利用可能日以降の場合（ステップＳ１−１０において「ＹＥＳ」の場合）には、取引管理サーバ２０の制御部２１は、目論見書のバージョン確認処理を実行する（ステップＳ１−１２）。具体的には、制御部２１の取引可否判断手段２１４は、購入希望の金融商品の商品コードについて、目論見書管理データ記憶部２３から最新の目論見書のバージョンコードを取得する。ここでは、取引可否判断手段２１４は、現在日付がリリース日を経過しており、バージョンコードが最大値のバージョンを最新バージョンとして特定する。そして、取引可否判断手段２１４は、バージョン管理レコード２４０に記録されているバージョンコードと最新バージョンコードとを比較する。

両バージョンコードが一致することにより、交付バージョンが最新バージョンである場合（ステップＳ１−１２において「ＹＥＳ」の場合）には、取引管理サーバ２０の制御部２１は、取引許可処理を実行する（ステップＳ１−１３）。具体的には、制御部２１の取引可否判断手段２１４は、取引管理手段２１２に対して取引を許可する。これにより、取引管理手段２１２は、ユーザ端末１０との間で取引処理を実行する。

一方、バージョンコードが一致せず、交付バージョンが最新バージョンでない場合（ステップＳ１−１２において「ＮＯ」の場合）には、取引管理サーバ２０の制御部２１は、後述する目論見書の送付処理を実行する（ステップＳ１−７）。

（目論見書の送付処理）
次に、図４に従って、目論見書の送付処理を説明する。
ここでは、まず、取引管理サーバ２０の制御部２１は、希望交付方法の取得処理を実行する（ステップＳ２−１）。具体的には、制御部２１の取引可否判断手段２１４は、ユーザ端末１０に対して、目論見書の交付方法を選択するための交付方法選択画面データを送信する。この交付方法選択画面においては、目論見書の交付方法として「ネット経由」或いは「郵送」を選択するための交付方法選択欄が設けられている。そして、交付方法選択画面において、所望の交付方法が入力された場合、ユーザ端末１０は、送付依頼を取引管理サーバ２０に送信する。この送付依頼には、「ネット経由」或いは「郵送」を特定するためのデータを含める。

送付依頼を受信した取引管理サーバ２０の制御部２１は、交付方法の確認処理を実行する（ステップＳ２−２）。ここで、送付依頼において「郵送」が設定されている場合（ステップＳ２−２において「郵送」の場合）、取引管理サーバ２０の制御部２１は、後述する目論見書の郵送処理を実行する（ステップＳ２−３）。

一方、「ネット経由」が設定されている場合（ステップＳ２−２において「ネット経由」の場合）には、取引管理サーバ２０の制御部２１は、目論見書の生成処理を実行する。この生成処理においては、まず、取引管理サーバ２０の制御部２１は、この顧客に交付された目論見書のバージョン情報の取得処理を実行する（ステップＳ２−４）。具体的には、制御部２１の差分抽出手段２１５は、バージョン管理レコード２４０に記録されたバージョンコードを取得する。

そして、取引管理サーバ２０の制御部２１は、交付バージョンの目論見書と最新バージョンの目論見書との変更箇所の抽出処理を実行する（ステップＳ２−５）。具体的には、制御部２１の差分抽出手段２１５は、目論見書管理データ記憶部２３から交付バージョンのバージョンコードに関連付けられた目論見書ファイルと、最新バージョンコードに関連付けられた目論見書ファイルを抽出する。そして、差分抽出手段２１５は、両ファイルを比較して差分を特定することにより変更箇所を抽出する。

次に、取引管理サーバ２０の制御部２１は、ブックマーク貼付処理を実行する（ステップＳ２−６）。具体的には、制御部２１の差分抽出手段２１５は、最新バージョンの目論見書ファイルにおいて、抽出した変更箇所に対してブックマークを貼付する。このブックマークは、差分を明示した差分情報表示媒体として機能する。

そして、取引管理サーバ２０の制御部２１は、目論見書の送信処理を実行する（ステップＳ２−７）。具体的には、制御部２１の送付処理手段２１６は、差分抽出手段２１５においてブックマークが貼付された目論見書ファイルを、インターネットを介してユーザ端末１０に送信する。

更に、送付処理手段２１６は、この送付について、バージョン管理レコード２４０を生成して、バージョン管理データ記憶部２４に登録する。このバージョン管理レコード２４０においては、このユーザ端末１０の顧客コード、交付した目論見書についての商品コード、最新のバージョンコード、交付方法コードとして「ネット経由」を設定する。更に、バージョン管理レコード２４０の「送付日」および「利用可能日」として当日日付を記録する。

そして、送付処理手段２１６は、最新バージョンの目論見書を交付したことを、取引管理手段２１２に対して通知する。この場合も、取引管理手段２１２は、ステップＳ１−１３と同様に、取引許可処理を実行する（ステップＳ２−８）。

（目論見書の郵送処理）
次に、図５に従って、目論見書の郵送処理を説明する。
ここでは、取引管理サーバ２０の制御部２１は、郵送の通常所要日数の取得処理を実行する（ステップＳ３−１）。具体的には、制御部２１の送付処理手段２１６は、顧客管理データ記憶部２２の顧客管理レコード２２０から、この顧客の住所コードを取得する。そして、送付処理手段２１６は、顧客の住所コードに対応する地域コードを用いて、地域別所要日数テーブル２５０から通常所要日数を取得する。

次に、取引管理サーバ２０の制御部２１は、郵便事情の取得処理を実行する（ステップＳ３−２）。具体的には、制御部２１の送付処理手段２１６は、現在日付が期間考慮テーブル２５１に記録された特別考慮期間に該当するかどうかを確認する。特別考慮期間に該当する場合には、期間考慮テーブル２５１から付加日数を取得する。

そして、取引管理サーバ２０の制御部２１は、配達所要日数の算出処理を実行する（ステップＳ３−３）。具体的には、制御部２１の送付処理手段２１６は、通常所要日数に付加日数を加算することにより、目論見書を郵送するための配達所要日数を算出する。

次に、取引管理サーバ２０の制御部２１は、郵送期間中の更新判断処理を実行する（ステップＳ３−４）。具体的には、制御部２１の送付処理手段２１６は、現在日付に対して、ステップＳ３−３において算出した配達所要日数を加算することにより、目論見書の配達予測日を特定する。更に、送付処理手段２１６は、目論見書管理データ記憶部２３から、この商品について更新予定の目論見書のリリース日を取得する。そして、配達予測日が
リリース日より先の場合には、郵送期間中に目論見書が更新されることになる。

この場合（ステップＳ３−４において「ＹＥＳ」の場合）には、取引管理サーバ２０の制御部２１は、郵送延期の通知処理を実行する（ステップＳ３−５）。具体的には、制御部２１の送付処理手段２１６は、ユーザ端末１０に対して、目論見書の郵送を延期することを通知する。

そして、取引管理サーバ２０の制御部２１は、更新バージョンの郵送設定処理を実行する（ステップＳ３−６）。具体的には、制御部２１の送付処理手段２１６は、郵送スケジュール記憶部に記録されている発送処理カレンダから、更新バージョンのリリース日以降の発送処理予定日を取得する。そして、送付処理手段２１６は、バージョン管理レコード２４０の送付日としてリリース日以降の発送処理予定日を設定する。この場合、送付処理手段２１６は、更新される目論見書について、発送センタに対して、この送付日の郵送指示を送信する。

次に、取引管理サーバ２０の制御部２１は、更新予定の目論見書の利用可能日の設定処理を実行する（ステップＳ３−７）。具体的には、制御部２１の送付処理手段２１６は、バージョン管理レコード２４０において、更新バージョンのリリース日以降の発送処理予定日に配達所要日数を加算した日付（配達予測日）を利用可能日として登録する。なお、この日付が、郵送スケジュール記憶部に記録されている郵便配達カレンダにおいて配達が行なわれない日である場合には、次の配達日を設定する。

一方、配達予測日がリリース日より早く、郵送期間中に目論見書の更新がない場合（ステップＳ３−４において「ＮＯ」の場合）には、取引管理サーバ２０の制御部２１は、最新バージョンの郵送設定処理を実行する（ステップＳ３−８）。具体的には、制御部２１の送付処理手段２１６は、郵送スケジュール記憶部に記録されている発送処理カレンダから直近の発送処理予定日を取得する。そして、送付処理手段２１６は、この発送処理予定日をバージョン管理レコード２４０の送付日として設定する。更に、送付処理手段２１６は、発送センタに対して、最新バージョンの目論見書についての郵送指示を送信する。

次に、取引管理サーバ２０の制御部２１は、最新の目論見書の利用可能日の設定処理を実行する（ステップＳ３−９）。具体的には、制御部２１の送付処理手段２１６は、バージョン管理レコード２４０において、発送処理予定日から配達所要日数を加算した日付（配達予測日）を利用可能日として登録する。この場合も、この日付が郵便配達カレンダにおいて配達が行なわれない日である場合には、次の配達日を設定する。

以上、説明した本実施形態によれば、以下のような効果を得ることができる。
・ 本実施形態によれば、バージョン管理データ記憶部２４には、顧客に交付した目論見書のバージョンを管理するためのバージョン管理レコード２４０が記録されている。そして、現在日付が利用可能日以降であり、交付バージョンが最新バージョンである場合には、取引管理サーバ２０の制御部２１は、取引許可処理を実行する（ステップＳ１−１３）。これにより、顧客が所有する目論見書のバージョンを確認しながら、的確に商品の販売を行なうことができる。また、取引管理サーバ２０の制御部２１がバージョンを判断するため、目論見書を所有する顧客にとっても効率的に商品購入の手続を行なうことができる。

・ 本実施形態によれば、目論見書の交付履歴がある場合（ステップＳ１−４において「ＹＥＳ」の場合）には、取引管理サーバ２０の制御部２１は、利用可能日の取得処理を実行する（ステップＳ１−９）。現在日付が利用可能日前の場合（ステップＳ１−１０において「ＮＯ」の場合）には、取引管理サーバ２０の制御部２１は、この目論見書を利用
しての取引を保留する（ステップＳ１−１１）。この利用可能日は、目論見書の郵送処理（ステップＳ２−３）によって、郵送先住所や郵送時期に応じて設定される。これにより、郵便事情等を含めた目論見書の配達状況を考慮して、より確実に目論見書を所有する顧客に対して商品の販売を行なうことができる。

・ 本実施形態によれば、目論見書の交付履歴がない場合（ステップＳ１−４において「ＮＯ」の場合）、取引管理サーバ２０の制御部２１は、顧客が所有する目論見書の所有確認処理を実行する（ステップＳ１−５）。これにより、顧客が店頭で目論見書を取得している場合にも対応することができる。

・ 本実施形態によれば、取引管理サーバ２０の制御部２１は、交付バージョンの目論見書と最新バージョンの目論見書との変更箇所を抽出し（ステップＳ２−５）、この変更箇所に対してブックマーク貼付処理を実行する（ステップＳ２−６）。これにより、顧客は、これまで利用していた目論見書に対しての変更箇所を容易に把握することができるため、的確かつ効率的に商品情報の交付を行なうことができる。

・ 上記実施形態では、目論見書の配達予測日がリリース日より先の場合（ステップＳ３−４において「ＹＥＳ」の場合）には、取引管理サーバ２０の制御部２１は、郵送延期を通知し（ステップＳ３−５）、更新バージョンの郵送設定処理を実行する（ステップＳ３−６）。これにより、利用できない目論見書の郵送を抑制することができる。

なお、上記実施形態は以下のように変更してもよい。
○ 上記実施形態では、目論見書の生成処理において、取引管理サーバ２０の制御部２１は、ブックマーク貼付処理を実行する（ステップＳ２−６）。顧客に交付する目論見書において、変更箇所を表示する差分情報表示媒体はこれに限定されるものではない。例えば、差分情報表示媒体として、差分抽出手段２１５が変更箇所に基づき新旧対照表を作成するようにしてもよい。そして、送付処理手段２１６は、最新バージョンの目論見書とともに、この新旧対照表を顧客に送付する。この新旧対照表により、顧客は変更箇所を理解することができる。

○ 上記実施形態では、取引管理サーバ２０の制御部２１は、ブックマーク貼付処理を実行する（ステップＳ２−６）。顧客に交付する目論見書において、変更箇所を表示する差分情報表示媒体はこれに限定されるものではない。変更の内容に応じて表示方法を変える差分情報表示媒体を提供することも可能である。以下に、目論見書の生成処理について説明する。

ここでは、取引管理サーバ２０に、図６に示すように、改定履歴記憶手段としての改定履歴データ記憶部２６を設けておく。この改定履歴データ記憶部２６には、目論見書の改定経緯について改定履歴レコード２６０が記録される。この改定履歴レコード２６０は、目論見書が更新されたときに登録される。改定履歴レコード２６０は、商品コード、バージョンコード、改定箇所、改定種別に関するデータが記録される。

商品コードには、目論見書を交付する金融商品を特定するための識別子に関するデータが記録される。
バージョンコードには、目論見書の版を特定するための識別子に関するデータが記録される。

改定箇所には、先のバージョンに対して改定された箇所に関するデータが記録される。
改定種別には、改定箇所毎に、この改定における種類を特定するためのデータが記録される。この改定種別は、「投資先の変更」、「法規制の変更」、「手数料など取引条件の
変更」、「それ以外」等のように改定内容の種類・性質を示す。

次に、図７に従って、改定履歴データ記憶部２６を用いて、顧客に応じた目論見書の生成処理を説明する。
まず、ステップＳ２−４と同様に、取引管理サーバ２０の制御部２１は、ユーザの目論見書のバージョン情報の取得処理を実行する（ステップＳ４−１）。

次に、取引管理サーバ２０の制御部２１は、交付バージョンと最新バージョンとの改定箇所の抽出処理を実行する（ステップＳ４−２）。具体的には、制御部２１の差分抽出手段２１５は、交付バージョンから最新バージョンに至るまでの改定履歴レコード２６０を改定履歴データ記憶部２６から抽出する。

取引管理サーバ２０の制御部２１は、改定箇所の改定種別の特定処理を実行する（ステップＳ４−３）。具体的には、制御部２１の差分抽出手段２１５は、抽出した改定履歴レコード２６０に記録された改定箇所に対応する改定種別を取得する。

取引管理サーバ２０の制御部２１は、改定種別に応じて改定箇所表示処理を実行する（ステップＳ４−４）。具体的には、制御部２１の差分抽出手段２１５は、改定種別に応じて、色や新旧対照表上の記載順を変化させる。
これにより、顧客は、改定種別に応じて、効率的に改定内容を把握することができる。

○ 上記実施形態では、目論見書の生成処理において、取引管理サーバ２０の制御部２１は、最新バージョンの目論見書についての郵送指示を送信する。この場合、ネット経由と同様に、ブックマークを貼付したり、新旧対照表を作成し、目論見書とともに郵送したりするように構成してもよい。また、新旧対照表の内容を、ユーザ端末１０のディスプレイに出力するようにしてもよい。これにより、顧客は変更箇所を理解することができる。

○ 上記実施形態では、バージョン管理データ記憶部２４において、「ネットワーク経由」及び「郵送」による交付を管理対象とする。これに加えて、金融機関の店頭における「窓口交付」を管理対象とすることも可能である。この場合には、窓口交付を行なった場合には、バージョン管理データ記憶部２４において、送付日の代わりに交付日を記録したバージョン管理レコード２４０を登録する。なお、交付したすべての目論見書についてのバージョン管理レコード２４０がバージョン管理データ記憶部２４に登録されている場合には、ステップＳ１−５、Ｓ１−６、Ｓ１−８の処理をなくすことができる。

本発明の一実施形態のシステムの概略図。 本発明の一実施形態の各データ記憶部に記録されたデータの説明図であって、（ａ）は顧客管理データ記憶部、（ｂ）は目論見書管理データ記憶部、（ｃ）はバージョン管理データ記憶部、（ｄ）は所要日数データ記憶部に記録されたデータの説明図。 本発明の一実施形態の処理手順の説明図。 本発明の一実施形態の処理手順の説明図。 本発明の一実施形態の処理手順の説明図。 他の実施形態の改定履歴データ記憶部に記録されたデータの説明図。 他の実施形態の処理手順の説明図。

符号の説明

１０…ユーザ端末、２０…取引管理サーバ、２１…制御部、２１１…ユーザ認証手段、２１２…取引管理手段、２１３…目論見書確認手段、２１４…取引可否判断手段、２１５…差分抽出手段、２１６…送付処理手段、２２…顧客管理データ記憶部、２３…目論見書
管理データ記憶部、２４…バージョン管理データ記憶部、２５…所要日数データ記憶部。

Claims (7)

1. ユーザ毎に交付した目論見書のバージョン情報を記録した交付バージョン情報記憶手段と、
   バージョン毎に目論見書ファイルを記録した目論見書管理情報記憶手段と、
   目論見書の管理を行なう制御手段とを備えた目論見書管理システムであって、
   前記制御手段が、
   ユーザ端末からアクセス要求を受信した場合、ユーザ認証を行なうユーザ認証手段、
   前記ユーザ端末から取引要求を受信した場合、前記交付バージョン情報記憶手段を用いて、前記ユーザ認証したユーザに対して交付した目論見書の交付バージョンを特定する目論見書確認手段、
   前記目論見書管理情報記憶手段に記録された最新バージョンと前記交付バージョンとを比較し、バージョンが一致しない場合には、両バージョンの差分を特定し、この差分を明示した差分情報表示媒体を生成する差分抽出手段、
   前記差分情報表示媒体を付加した最新バージョンの目論見書を前記ユーザ端末に送信する送付処理手段
   を備えたことを特徴とする目論見書管理システム。
2. バージョン毎に、改定箇所、改定種別を記録した改定履歴記憶手段を更に備え、
   前記差分抽出手段は、両バージョンの差分について、前記改定履歴記憶手段を用いて、改定箇所、改定種別を取得し、
   前記改定種別に応じて、前記改定箇所の表示方法を変更した差分情報表示媒体を生成することを特徴とする請求項１に記載の目論見書管理システム。
3. 前記交付バージョン情報記憶手段には、ユーザに対する交付方法及び送付日に関する情報が更に記録されており、
   前記制御手段が、
   前記交付方法においてユーザに対して目論見書を郵送にて交付したことが記録されている場合には、前記目論見書の送付日を特定する手段を更に備え、
   前記目論見書確認手段は、前記送付日から所定の所要日数を加算して算出した配達予測日が現在日付より先の場合には、この目論見書を交付バージョンとして特定しないことを特徴とする請求項１又は２に記載の目論見書管理システム。
4. 前記制御手段が、
   前記ユーザの住所情報を取得し、前記住所に基づいて配達所要日数を算出する配達予測手段を更に備えたことを特徴とする請求項３に記載の目論見書管理システム。
5. 発送処理を行なう日程が記録された発送処理カレンダと、配達処理が行なわれる日程が記録された郵便配達カレンダとを記録した郵送スケジュール記憶手段を更に備え、
   前記配達予測手段は、前記発送処理カレンダと郵便配達カレンダに基づいて、配達予測日を算出することを特徴とする請求項４に記載の目論見書管理システム。
6. ユーザ毎に交付した目論見書のバージョン情報を記録した交付バージョン情報記憶手段と、
   バージョン毎に目論見書ファイルを記録した目論見書管理情報記憶手段と、
   目論見書の管理を行なう制御手段とを備えた目論見書管理システムを用いて、目論見書を管理する方法であって、
   前記制御手段が、
   ユーザ端末からアクセス要求を受信した場合、ユーザ認証を行なうユーザ認証段階、
   前記ユーザ端末から取引要求を受信した場合、前記交付バージョン情報記憶手段を用い
   て、前記ユーザ認証したユーザに対して交付した目論見書の交付バージョンを特定する目論見書確認段階、
   前記目論見書管理情報記憶手段に記録された最新バージョンと前記交付バージョンとを比較し、バージョンが一致しない場合には、両バージョンの差分を特定し、この差分を明示した差分情報表示媒体を生成する差分抽出段階、
   前記差分情報表示媒体を付加した最新バージョンの目論見書を前記ユーザ端末に送信する送付処理段階
   を実行することを特徴とする目論見書管理方法。
7. ユーザ毎に交付した目論見書のバージョン情報を記録した交付バージョン情報記憶手段と、
   バージョン毎に目論見書ファイルを記録した目論見書管理情報記憶手段と、
   目論見書の管理を行なう制御手段とを備えた目論見書管理システムを用いて、目論見書を管理するプログラムであって、
   前記制御手段を、
   ユーザ端末からアクセス要求を受信した場合、ユーザ認証を行なうユーザ認証手段、
   前記ユーザ端末から取引要求を受信した場合、前記交付バージョン情報記憶手段を用いて、前記ユーザ認証したユーザに対して交付した目論見書の交付バージョンを特定する目論見書確認手段、
   前記目論見書管理情報記憶手段に記録された最新バージョンと前記交付バージョンとを比較し、バージョンが一致しない場合には、両バージョンの差分を特定し、この差分を明示した差分情報表示媒体を生成する差分抽出手段、
   前記差分情報表示媒体を付加した最新バージョンの目論見書を前記ユーザ端末に送信する送付処理手段
   として機能させることを特徴とする目論見書管理プログラム。

Images