(57)【要約】      （修正有）【課題】メッセージ交換サーバを利用して効率の高い通信システムを提供する。【解決手段】複数のユーザのあいだのメッセージ交換を行うためのメッセージ交換サーバを備えた通信システムにおいて、当該メッセージ交換サーバは、単位閲覧情報管理手段と、単位閲覧情報生成支援手段と、アクセス権限管理手段と、アクセス制御手段とを備える。また、マネジメント対象ユーザが、情報提供用の単位閲覧情報を介して、リスクマネジメント基礎情報を提供した場合、少なくともリスクマネジメント案の記述を含む単位閲覧情報を自動的に生成し、自動的に生成したこの単位閲覧情報にアクセスするためのアクセス識別子を、情報提供用の単位閲覧情報を介してマネジメント対象ユーザに伝えるように構成する。【選択図】  図１
2004227019.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザのあいだのメッセージ交換を行うためのメッセージ交換サーバを備えた通信システムにおいて、
当該メッセージ交換サーバは、
前記ユーザのうち損害発生に関連するリスクマネジメント案の提供を受けるマネジメント対象ユーザのため、前記リスクマネジメント案、および／またはそのリスクマネジメント案の基礎となったリスクマネジメント基礎情報の記述を含む単位閲覧情報を生成し、管理する単位閲覧情報管理手段と、
当該マネジメント対象ユーザに関するリスクマネジメント基礎情報を、収集し、識別して、前記単位閲覧情報管理手段に供給することで、前記単位閲覧情報の生成を支援する単位閲覧情報生成支援手段と、
前記ユーザのうち、前記マネジメント対象ユーザに対し前記リスクマネジメント案を前記単位閲覧情報に記述することによって提案するマネジメント提案ユーザにつき、前記単位閲覧情報に対するアクセス権限を管理するアクセス権限管理手段と、
前記マネジメント対象ユーザからの指示に応じて、当該マネジメント対象ユーザのための単位閲覧情報に対する各マネジメント提案ユーザのアクセス権限を動的に変更するアクセス制御手段とを備えたことを特徴とする通信システム。
【請求項２】
請求項１の通信システムにおいて、
前記単位閲覧情報管理手段は、
前記マネジメント対象ユーザが、情報提供用の単位閲覧情報を介して、前記リスクマネジメント基礎情報を提供した場合、少なくとも前記リスクマネジメント案の記述を含む単位閲覧情報を自動的に生成し、自動的に生成したこの単位閲覧情報にアクセスするためのアクセス識別子を、前記情報提供用の単位閲覧情報を介して当該マネジメント対象ユーザに伝えることを特徴とする通信システム。
【請求項３】
請求項１の通信システムにおいて、
前記単位閲覧情報管理手段は、
前記マネジメント対象ユーザからの直接的な提供によらずに、前記リスクマネジメント基礎情報を収集しておき、当該リスクマネジメント基礎情報を閲覧した前記マネジメント提案ユーザから前記リスクマネジメント案の提供を受けた場合、当該リスクマネジメント案を記述した単位閲覧情報を自動的に生成すると共に、自動的に生成したこの単位閲覧情報にアクセスするためのアクセス識別子を、プッシュ型の通信手段を用いて、当該マネジメント対象ユーザまたはマネジメント提案ユーザに伝えることを特徴とする通信システム。
【請求項４】
請求項１の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記リスクマネジメント基礎情報の構成要素である各要素情報を収集する際、各要素情報に１または複数の事業者が付与した異なる要素識別子を所定の手順で解釈処理し、同一のマネジメント対象ユーザに関する要素情報を識別して、集約することを特徴とする通信システム。
【請求項５】
請求項４の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記リスクマネジメント基礎情報として、前記マネジメント対象ユーザの所定範囲の近親者に関するリスクマネジメント基礎情報も含め、個々の近親者に関するリスクマネジメント情報も識別して集約することを特徴とする通信システム。
【請求項６】
請求項４の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記要素識別子の解釈処理の過程で、前記要素情報の種類も識別することを特徴とする通信システム。
【請求項７】
請求項４の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記リスクマネジメント基礎情報を提供してくれる収集先とのあいだで、付与すべき要素識別子の表現規則を予め決定しておくことにより、前記解釈処理を簡略化することを特徴とする通信システム。
【請求項８】
請求項４の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記要素情報を、前記損害発生の要因別に分析し、その分析結果を、前記リスクマネジメント基礎情報として前記単位閲覧情報管理手段に供給し、
当該単位閲覧情報管理手段は、この分析結果に応じて単位閲覧情報の生成を行い、
前記マネジメント提案ユーザは、当該単位閲覧情報を閲覧して、前記リスクマネジメント案を決定し記述することを特徴とする通信システム。
【請求項９】
請求項１の通信システムにおいて、
前記単位閲覧情報管理手段は、単一のマネジメント対象ユーザにつき複数の単位閲覧情報を用意し、その一部はマネジメント対象ユーザに閲覧させるための対象ユーザ用単位閲覧情報、残りは、前記マネジメント提案ユーザに閲覧させるための提案ユーザ用単位閲覧情報としておき、当該提案ユーザ用単位閲覧情報には、前記単位閲覧情報生成支援手段が収集し、識別した当該マネジメント対象ユーザに関するリスクマネジメント基礎情報を含むことを特徴とする通信システム。
【請求項１０】
請求項９の通信システムにおいて、
前記単位閲覧情報管理手段は、
前記リスクマネジメント基礎情報を構成する要素情報のうち、前記メッセージ交換サーバに対してマネジメント対象ユーザが提供を拒否した要素情報については、前記対象ユーザ用単位閲覧には記述せず、前記提案ユーザ用単位閲覧情報に記述することを特徴とする通信システム。
【請求項１１】
請求項１０の通信システムにおいて、
前記単位閲覧情報管理手段は、
前記提案ユーザ用単位閲覧情報の記述に基づいてマネジメント提案ユーザが提案したリスクマネジメント案を、前記対象ユーザ用単位閲覧情報に記述することを特徴とする通信システム。
【請求項１２】
請求項１の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記リスクマネジメント基礎情報のうち所定の事業者が提供し、予め個人単位に整理された個人単位リスクマネジメント基礎情報につき、仮に、第１の識別情報を付与し、
次に、当該個人単位リスクマネジメント基礎情報の内容をもとに名寄せ処理を行い、
この名寄せ処理の結果に応じて、前記第１の識別情報を第２の識別情報に修正し、
当該第２の識別情報を利用して前記個人単位リスクマネジメント基礎情報を集約することを特徴とする通信システム。
【請求項１３】
請求項１の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記リスクマネジメント基礎情報を提供してくれる収集先または前記マネジメント対象ユーザ自身が提供したリスクマネジメント基礎情報が、前記リスクマネジメント案を作成するために十分であるか否かを判定し、十分でないとの判定結果を得た場合には、前記マネジメント対象ユーザに対して、さらなるリスクマネジメント基礎情報の提供を促すことを特徴とする通信システム。
【請求項１４】
請求項１の通信システムにおいて、
前記単位閲覧情報生成支援手段は、
前記リスクマネジメント基礎情報のうち保険契約上の有効期限の存在するものについては、満期のスケジュールを管理し、満期の所定期間前には、満期の予告を伝える満期予告メッセージを発信して保険切れのリスクを低減することを特徴とする通信システム。
【請求項１５】
請求項１の通信システムにおいて、
前記単位閲覧情報管理手段は、
前記リスクマネジメント案またはリスクマネジメント基礎情報以外に、所定の付随情報を前記単位閲覧情報に記述して、前記マネジメント対象ユーザに閲覧させることを特徴とする通信システム。
【請求項１６】
請求項１５の通信システムにおいて、
前記付随情報には、
前記マネジメント提案ユーザからマネジメント対象ユーザに宛てた連絡用のメッセージまたは、マネジメント対象ユーザにとって有益なメッセージを含むことを特徴とする通信システム。
【請求項１７】
請求項１の通信システムにおいて、
前記アクセス制御手段は、
前記マネジメント対象ユーザがアクセス禁止を指示しない限り、当該マネジメント対象ユーザのための単位閲覧情報に対するマネジメント提案ユーザの複数回のアクセスを許容することを特徴とする通信システム。
【請求項１８】
請求項１７の通信システムにおいて、
前記アクセス制御手段は、
前記マネジメント対象ユーザがアクセス禁止を指示しない限り、所定の周期にしたがい、当該マネジメント対象ユーザのための単位閲覧情報に対するマネジメント提案ユーザのアクセスを許可する許可期間と許可しない不許可期間とを、周期的に繰り返すことを特徴とする通信システム。
【請求項１９】
請求項１の通信システムにおいて、
前記メッセージ交換サーバは、
複数のマネジメント対象ユーザに関する属性情報を格納した対象ユーザ管理手段を備え、
前記マネジメント提案ユーザが、当該対象ユーザ管理手段を検索した結果に基づき、複数のマネジメント対象ユーザのための単位閲覧情報に対し、一括して、同じ内容のリスクマネジメント案を提供することを許容することを特徴とする通信システム。
【請求項２０】
請求項１の通信システムにおいて、
前記メッセージ交換サーバは、
前記マネジメント対象ユーザが、自身の単位閲覧情報に記述されたリスクマネジメント案に応じて当該単位閲覧情報上で保険の契約または解約を開始または完結するための契約関連処理手段を備えたことを特徴とする通信システム。
【請求項２１】
請求項２０の通信システムにおいて、
当該単位閲覧情報上でマネジメント対象ユーザが保険の契約または解約を開始または完了する場合はもとより、前記メッセージ交換サーバの外部に存在する外部サーバ上で保険の契約または解約を完了する場合も、その契約または解約の完了を、当該単位閲覧情報上のリスクマネジメント基礎情報に反映させることを特徴とする通信システム。
【請求項２２】
請求項２１の通信システムにおいて、
前記外部サーバ上で実行される保険の契約または解約の完了操作と、前記単位閲覧情報側で実行されるリスクマネジメント基礎情報の変更操作とを、１つのトランザクション処理に収容することを特徴とする通信システム。
【請求項２３】
請求項１の通信システムにおいて、
前記メッセージ交換サーバは、
複数のマネジメント対象ユーザに関する属性情報を格納した対象ユーザ管理手段を備え、
前記マネジメント対象ユーザに関する保険事故の発生または保険金の支払状況に応じて、前記対象ユーザ管理手段内の当該マネジメント対象ユーザに関する属性情報の値を変更し、その変更を単位閲覧情報の記述に反映させることを特徴とする通信システム。
【請求項２４】
請求項１の通信システムにおいて、
前記単位閲覧情報管理手段は、
前記リスクマネジメント基礎情報のうち保険関連以外の利用者情報に関する記述の変更を、前記マネジメント対象ユーザ自身が行うための記述変更用単位閲覧情報を生成し、
当該記述変更用単位閲覧情報を介してのみ、前記マネジメント対象ユーザによる前記利用者情報の記述の変更を許容することを特徴とする通信システム。
【請求項２５】
請求項１の通信システムにおいて、
前記単位閲覧情報管理手段は、
前記単位閲覧情報に関連付けられた所定のキャラクタプログラムを生成し、
前記マネジメント対象ユーザが当該単位閲覧情報を閲覧するときには、当該キャラクタプログラムがマネジメント対象ユーザに提供するキャラクタを介して、当該単位閲覧情報に記述された提案リスクマネジメントに関する説明を提供することを特徴とする通信システム。
【請求項２６】
請求項１の通信システムにおいて、
前記メッセージ交換サーバは、
当該メッセージ交換サーバを運営する運営事業者が、前記マネジメント対象ユーザまたは／およびリスクマネジメント提案ユーザから、サービス利用料を自動的に受け取るための決済手段を備えたことを特徴とする通信システム。
【請求項２７】
請求項１〜２６の通信システムにおいて、
前記単位閲覧情報として、Ｗｅｂページを利用することを特徴とする通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は通信システムに関し、例えば、Ｗｅｂページを利用して、リスクマネジメントを行う場合などに適用して好適なものである。
【０００２】
【従来の技術】
通常の個人または法人（以下［利用者」）は、自身を取リ巻く各種のリスク（財物、賠償責任、傷害・疾病、死亡、生存、保証、各種費用など）を正しく認識・把握していないことも多い。一例として、生存のリスクでは、個人利用者が通常より長生きしすぎることによって、老後の生活設計に問題が生じる場合などを取り扱うが、それらリスクのマネジメント方法について、熟知している者は少ないのが実態である。
【０００３】
そのため、保険会社、その代理店、リスク・コンサルティング会社など（これらを、以下「リスク・マネジャー」という。）に所属する提案者（以下「専門アドバイザ」）が、営業活動を通じて、リスク存在の啓蒙活動およびリスクに対処するための保険販売やリスク回避・軽減のアドバイスを行っている。
【０００４】
それら専門アドバイザが、それぞれの顧客である前記利用者に対して、利用者を取り巻く各種リスクについて包括的かつ網羅的に説明し、それらを良好に反映したリスクの対処方法を提案することが理想的な営業形態である。このような営業形態を、トータル・リスク・コンサルティングと呼ぶ。
【０００５】
トータル・リスク・コンサルティングを実現するには、利用者を取り巻くリスクの全体像を把握する必要があるから、当該利用者に関し、各保険会社との保険契約の内容などを、詳細かつ網羅的に調べる必要がある。
【０００６】
最近、利用者を取り巻くすべてのリスクについて、コンサルティングしながらその利用者のための商品設計を行う保険商品（トータルリスク商品）も登場した。このようなトータルリスク商品は、トータル・リスク・コンサルティングを具現化した例とみることができる。
【０００７】
【特許文献１】
特開２００１−２４３２８１号公報
【０００８】
【発明が解決しようとする課題】
ところが、前記専門アドバイザのアドバイスを受けるために保険会社、代理店、リスク・コンサルティング会社などの店舗に出向き、専門アドバイザと対面して（Ｆａｃｅ  ｔｏ  Ｆａｃｅで）相談を行うことは、前記利用者にとって、時間や手間がかかり、効率的ではない。
【０００９】
専門アドバイザのなかでも、経験や熟練度に優れ、真に適切なアドバイスを行うことのできる者（高度専門アドバイザ）の割合は決して多くはないため、利用者がそのような高度専門アドバイザに出会うまでには、多大な労力と時間と資産が消費されることが多い。
【００１０】
組織としてのリスクマネージャの側からみた場合、真の高度専門アドバイザのみが多くの利用者から、大きな信頼を、長期間にわたって得ることが可能であるため、少ない高度専門アドバイザを効率的に活用することが有利であるが、対面による相談を行うかぎり、効率アップにも限界がある。
【００１１】
一方、専門アドバイザが有能であってもなくても、前記トータル・リスク・コンサルティングを実現するには、当該利用者に関し、各保険会社との保険契約の内容などを、詳細かつ網羅的に把握する必要があるから、利用者にとっても専門アドバイザにとっても煩雑な作業が長時間おこなわれることになる。この作業があまりに煩雑で、専門アドバイザにも利用者にも敬遠される傾向が強いため、トータル・リスク・コンサルティングを理想としながらも、実際には、このような煩雑さがはるかに少ない、火災や自動車など限定的なリスクだけに対応した在来型の保険商品だけを販売して済ませることも多く、トータル・リスク・コンサルティングが実現されているとはいえない状況にある。
【００１２】
また、前記トータル・リスク商品についても、このような煩雑さが販売増進の妨げになる可能性が高い。
【００１３】
【課題を解決するための手段】
かかる課題を解決するために、本発明では、複数のユーザのあいだのメッセージ交換を行うためのメッセージ交換サーバを備えた通信システムにおいて、当該メッセージ交換サーバは、（１）前記ユーザのうち損害発生に関連するリスクマネジメント案の提供を受けるマネジメント対象ユーザのため、前記リスクマネジメント案、および／またはそのリスクマネジメント案の基礎となったリスクマネジメント基礎情報の記述を含む単位閲覧情報を生成し、管理する単位閲覧情報管理手段と、（２）当該マネジメント対象ユーザに関するリスクマネジメント基礎情報を、収集し、識別して、前記単位閲覧情報管理手段に供給することで、前記単位閲覧情報の生成を支援する単位閲覧情報生成支援手段と、（３）前記ユーザのうち、前記マネジメント対象ユーザに対し前記リスクマネジメント案を前記単位閲覧情報に記述することによって提案するマネジメント提案ユーザにつき、前記単位閲覧情報に対するアクセス権限を管理するアクセス権限管理手段と、（４）前記マネジメント対象ユーザからの指示に応じて、当該マネジメント対象ユーザのための単位閲覧情報に対する各マネジメント提案ユーザのアクセス権限を動的に変更するアクセス制御手段とを備えたことを特徴とする。
【００１４】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる通信システムを、ＥＣサイトに適用した場合を例に、実施形態について説明する。
【００１５】
このＥＣサイトは、前記利用者との関係では主としてＢｔｏＣのＥＣサイトであり、前記保険会社等（あるいは専門アドバイザ）などとの関係では主としてＢｔｏＢのＥＣサイトであるといえる。
【００１６】
（Ａ−１）実施形態の構成
本実施形態にかかるＥＣシステム１０の全体構成例を図１に示す。
【００１７】
図１において、当該ＥＣシステム１０は、情報提供端末８，９と、提案端末１３，１４と、利用者端末１５，１６と、ネットワーク１７と、ＥＣサイト１８とを備えている。
【００１８】
このうちネットワーク１７はＬＡＮ（ローカルエリアネットワーク）などであってもかまわないが、ここではインターネットであるものとする。
【００１９】
また、ＥＣサイト１８は、ＥＣ（電子商取引）を実行する会員制のサイトで、Ｗｅｂサーバ１１と、データベースサーバ１２を備えている。なお、図１上は省略してあるが、ＥＣサイト１８内にルータや、ファイアウオールなどの各種ネットワーク機器や、ＤＮＳサーバなどのサーバ類が適宜配置されることは当然である。また、本実施形態では、情報提供端末８，９から供給される多量の情報を受信するために、ＥＣサイト１８内にＦＴＰサーバを設けることも望ましい。その場合、ＦＴＰサーバが受信した情報は、前記データベース１２に格納され得る。
【００２０】
当該ＥＣサイト１８にアクセスしてくる会員ユーザは大きく分けて３種類ある。その第１は前記利用者で、第２は当該利用者に対してリスクマネジメントのアドバイス（すなわち、提案リスクマネジメントの提供）を行う専門アドバイザ（高度専門アドバイザも含む）で、第３は、前記利用者に関する保険契約の内容などを提供してくれる情報提供ユーザである。
【００２１】
ここで、リスクとは、損害発生に関する不確実性のことをいう。そして、リスクマネジメントとは、損害発生の結果、利用者に生ずる可能性のある経済的損失を最小化するのに必要な処理のことで、具体的には、次の手続き（１）〜（４）のいずれか、または手続き（１）〜（４）を連続的に実行することによって実現され得る。
【００２２】
（１）損害を発生させる可能性があるリスクの特定とその説明
（２）損害発生時の予想損害額の測定
（３）損害発生の原因となるリスクに対する適切な対処方法（複数の対処方法の組み合わせを含む。）の選定
（４）上記（１）〜（３）の手続きの管理（上記（３）の「リスクに対する適切な対処方法」の実行を含む。）
また、前記提案リスクマネジメントには、損害の原因となり得る事象が発生した場合に備えた保険商品の購入などを勧めることのほか、損害の原因となり得る事象の発生自体を防止するための措置などの提案も含まれ得る。
【００２３】
利用者（例えば、Ｕ１１，Ｕ１２）は利用者端末１５，１６を利用して当該ＥＣサイト１８へアクセスし、専門アドバイザ（例えば、Ｕ２１，Ｕ２２）は提案端末１３，１４を利用して当該ＥＣサイト１８へアクセスし、情報提供ユーザ（例えば、Ｕ３１，Ｕ３２）は情報提供端末８，９を利用して当該ＥＣサイト１８へアクセスする。
【００２４】
利用者端末１５，１６、提案端末１３，１４、および、情報提供端末８，９は、基本的に、ネットワーク機能、ディスプレイ装置、キーボード、マウス、ハードディスク、ＲＡＭなどを備えた通常のパーソナルコンピュータであってよい。ただし、本実施形態の構成上、端末１３〜１６が、Ｗｅｂページの閲覧などに利用するクライアントソフトであるＷｅｂブラウザを搭載していることは必須であり、必要に応じて、電子メールの送受信や読み書きに使用するメーラも搭載している。
【００２５】
また、前記ハードディスクの一部の領域には、当該Ｗｅｂブラウザの制御下にあるキャッシュ領域が設けられ、利用者Ｕ１１がこれまで閲覧したＥＣサイト１８のＷｅｂページを、そのキャッシュ領域の容量が許すかぎり保存する。
【００２６】
情報提供端末８，９の場合、利用者端末１５，１６や提案端末１３，１４と同様に構成し、情報提供ユーザＵ３１などの指示に応じて情報提供を行うようにしてもよいが、情報提供ユーザＵ３１などの指示によらず自動で定期的に情報提供を行うように構成することも望ましい。その場合には、必ずしも情報提供ユーザＵ３１，Ｕ３２は必要ではないし、ディスプレイ装置、キーボード、マウスなどのユーザインタフェースも省略可能である。
【００２７】
図１の例では、利用者も専門アドバイザも二人ずつ図示しているが、この数は二人ずつに限定するものではないことは当然である。特に、ＥＣシステム１０が実際に運用された場合、数千人〜数万人程度あるいはそれ以上の利用者の会員登録およびアクセスが期待できるものと考えられる。会員登録する専門アドバイザの数は、利用者の数よりは少なくなる可能性が高いが、数十人から数百人、あるいはそれ以上にはなることが期待できる。
【００２８】
情報提供ユーザについても同様であるが、専門アドバイザが１つの組織（前記リスクマネジャーなど）に複数存在し得るのに対し、単に情報の提供だけを行う情報提供ユーザの数は１組織に一人で十分であると考えられるため、情報提供ユーザの数は、専門アドバイザの数よりもさらに少なくなる可能性が高い。
【００２９】
上述したトータル・リスク・コンサルティングを実現するためには、専門アドバイザ（例えば、Ｕ２１）が利用者（例えば、Ｕ１１）を取り巻くリスクの全体像を把握する必要がある。専門アドバイザはＷｅｂサーバ１１の提供するＷｅｂページを介してこの全体像を認識することになるため、Ｗｅｂサーバ１１に接続されたデータベース１２内には、当該全体像を把握するのに十分な情報が蓄積されている必要がある。そのため、各保険会社（例えば、Ｍ２）などに設置された情報提供端末（例えば、８）は、利用者の保険契約の内容などを事業者提供情報としてＥＣサイト１８に提供することになる。
【００３０】
この場合、情報提供端末８，９を設置してＥＣサイト１８に情報提供を行う保険会社等を、情報提供事業者と呼ぶ。
【００３１】
このような情報提供を行うためにもし必要であれば、情報提供事業者等は、予め、利用者からの承諾を得ておくようにしてもよい。
【００３２】
ただし、例えば、ＥＣサイト１８を運営する事業者Ｍ１と当該保険会社等が同一である場合などには、そのような承諾は不要であると考えられる。
【００３３】
ＥＣサイト１８を運営する事業者Ｍ１と、専門アドバイザが所属するリスクマネジャーＭ４，Ｍ５のあいだ、あるいは、事業者Ｍ１と情報提供事業者Ｍ２，Ｍ３のあいだには、いわゆる系列関係などが存在していてもかまわないが、事業者Ｍ１はいずれの系列にも属さない独立系の事業者であってもよい。
【００３４】
利用者は自然人であっても法人であってもかまわないが、たとえ法人の場合でも、実際に利用者端末１５などを操作してＥＣサイト１８にアクセスしてくるのは、当該法人のリスクマネジメント担当者などの自然人であることは当然である。したがって以下の説明では、実際にこの利用者端末を操作している者Ｕ１１またはＵ１２などのことを利用者と呼ぶことにする。
【００３５】
この点、専門アドバイザＵ２１，Ｕ２２についても同様である
専門アドバイザ（例えば、Ｕ２１）が所属するリスクマネジャー（ここでは、Ｍ４）が利用者（例えば、Ｕ１１）が保険契約を実際に行っている保険会社（すなわち、情報提供事業者Ｍ２，Ｍ３）などと一致することがあってもよく、このような一致は本実施形態の構成上、望ましいものである。
【００３６】
すなわち、図１では、情報提供事業者Ｍ２，Ｍ４と、リスクマネジャーＭ４，Ｍ５を別なものとして図示しているが、これらは同一であってもよい。
【００３７】
また、リスクマネジャー以外の保険会社等も情報提供事業者となってよいことは当然である。
【００３８】
上述したＥＣサイト１８の内部構成は、例えば、図２に示す通りである。
【００３９】
（Ａ−１−１）ＥＣサイトの内部構成例
図２において、当該ＥＣサイト１８は、通信部２０と、ユーザ認証部２１と、情報収集部２２と、ページ生成部２３と、ページ読み出し部２４と、情報集約部２５と、決済処理部２６と、データベース２７とを備えている。
【００４０】
このうちデータベース（前記データベースサーバ１２の配下にある）２７以外の構成要素２０〜２６は、前記Ｗｅｂサーバ１１に包含されるものである。
【００４１】
通信部２０は、前記端末１３〜１６のＷｅｂブラウザと通信を行う部分で、ＨＴＴＰプロトコルに対応した処理を実行する。当該通信部２０は、前記ページ生成部２３やページ読み出し部２４とともに、ある会員ユーザ（例えば、Ｕ１１）からの一連のアクセスに対して、矛盾のない応答や処理を行うため、必要に応じて、セッション管理を行う。セッション管理の実現法には様々なものがあるが、例えば、クッキーを利用する方法や、ＳＳＬセッションＩＤを利用する方法などを用いることができる。
【００４２】
ユーザ認証部２１は、ＥＣサイト１８にアクセスしてきた利用者Ｕ１１〜Ｕ２２に対して、会員登録時に設定したユーザＩＤやパスワードなどを入力させユーザ認証を実行する部分である。ユーザ認証の結果が肯定的なものでなければ、以降の処理へ進むことはできない。ユーザ認証の結果が否定的な場合、このユーザ認証部２１からの制御に応じて、アクセスしてきた者（非会員）に対し、会員登録を促すメッセージなどを閲覧させるようにしてもよい。
【００４３】
ページ読み出し部２４は、所定のＵＲＬでアクセスしてきたユーザに対し、当該ＵＲＬに対応するＷｅｂページを閲覧させるためにデータベース２７に格納されている各種のファイル（ＨＴＭＬファイルや画像ファイルなど）を読み出し、通信部２０を介して送信させる部分である。１つのＷｅｂページは通常、基本となるＨＴＭＬファイルのほか、１または複数の各種ファイル（画像ファイルなど）によって構成されるため、１回のアクセスに対して複数のファイルが読み出されることが多い。
【００４４】
非会員がアクセスしてきた場合、会員登録を行わなければ、当該ページ読み出し部２４がトップページのログイン画面（これもＨＴＭＬファイル）や会員登録を促すメッセージを表示するＷｅｂページだけしか読み出さないため、それ以外のＷｅｂページを閲覧することはできない。仮に、このような非会員がＥＣサイト内に実在するＵＲＬ（例えば、ＵＲＬ１１（図５参照））を指定してアクセスしてきたとしても、その場合には、前記通信部２０が所定のアクセス拒否のステータスコードを返す。
【００４５】
アクセスしてきたのが会員登録済みの前記利用者のうちの一人（例えば、Ｕ１１）であるとすると、ログイン以降の処理で当該利用者が閲覧できるのは、基本的に、自身のために用意された個人用のＷｅｂページＰＰ１だけであるから、ページ読み出し部２４は、当該利用者Ｕ１１のための個人用ＷｅｂページＰＰ１をデータベース２７から読み出し、前記通信部２０からインターネット１７経由で利用者端末１５へ送信することになる。
【００４６】
もちろん、当該利用者Ｕ１１のための個人用ＷｅｂページＰＰ１が複数ページにおよんでいてもよく、複数ファイルから構成されていてもよいことは当然である。
【００４７】
ただし、この個人用ＷｅｂページＰＰ１には、利用者Ｕ１１の保険契約の内容などの個人情報が記述されているため、他の利用者（例えば、Ｕ１２）はＵ１１のための個人用Ｗｅｂページにアクセスすることはできない。
【００４８】
反対に、利用者Ｕ１１が利用者Ｕ１２のための個人用ＷｅｂページＰＰ２にアクセスすることもできない。
【００４９】
要するに、データベース２７内に蓄積されている膨大な数の個人用Ｗｅｂページ（ＰＰ１，ＰＰ２はその一部）のうち、各利用者がアクセス（閲覧や情報の書き込み）できるのは、自身のための個人用Ｗｅｂページだけである。
【００５０】
他人の個人用Ｗｅｂページにアクセスしようとして実在のＵＲＬを指定した場合には、たとえ会員登録された正規の利用者であっても、上述した非会員の場合と同様、前記通信部２０からアクセス拒否のステータスコードを受け取ることになる。
【００５１】
ある利用者（例えば、Ｕ１１）のための個人用ＷｅｂページＰＰ１は、利用者Ｕ１１が閲覧するためのＷｅｂページと、その利用者に対して提案リスクマネジメントを提案しようとする専門アドバイザ（例えば、Ｕ２１など）が閲覧するＷｅｂページとを同一としてもよいが、本実施形態では、両者は一致しないものとする。また、利用者Ｕ１１が閲覧する個人用Ｗｅｂページとその専門アドバイザが閲覧するＷｅｂページがそれぞれ複数ある場合、一部のＷｅｂページは重複していてもよいが、本実施形態ではまったく重複がなく、すべてのＷｅｂページは別個であるものとする。
【００５２】
そして当該利用者Ｕ１１が閲覧するための１または複数ページの個人用Ｗｅｂページ（利用者用Ｗｅｂページ）をＰＰ１１とし、専門アドバイザが閲覧するための利用者Ｕ１１に関する１または複数ページの個人用Ｗｅｂページ（専門アドバイザ用Ｗｅｂページ）をＰＰ１２とする。
【００５３】
同様に、利用者Ｕ１２のための利用者用ＷｅｂページをＰＰ２１とし、専門アドバイザが閲覧するための利用者Ｕ１２に関する専門アドバイザ用ＷｅｂページをＰＰ２２とする。
【００５４】
利用者用ＷｅｂページＰＰ１１やＰＰ２１には、その利用者自身が入力し提供した自己提供情報（例えば、保険契約などに関する個人情報など）と、専門アドバイザが提案した提案リスクマネジメントの内容を表示し、専門アドバイザ用Ｗｅｂページには、利用者が入力した自己提供情報だけでなく、利用者が入力していない情報（情報提供事業者Ｍ２，Ｍ３などから提供された事業者提供情報など）も含めて表示する。利用者が入力していない情報のなかには、Ｗｅｂサーバ１１とのやり取りで、利用者が入力を拒否した情報も含まれる。
【００５５】
入力を拒否した情報までＥＣサイト１８側が勝手に収集してＷｅｂページ上に表示することは利用者に不快感を与える可能性が高いが、入力を拒否した情報も、高品質な提案リスクマネジメントを作成するためには重要な情報であることもあり得る。利用者は、たとえ、その作成に自身が入力を拒否した情報を利用していたとしても、真に、自身にとって有益な提案リスクマネジメントであると判断すれば、その提案リスクマネジメントを受け入れる可能性が高い。
【００５６】
なお、同一の利用者（例えば、Ｕ１１）に対して、複数の専門アドバイザが提案リスクマネジメントを提案してもよいことは当然である。また、提案リスクマネジメントの提案は、無料で行ってもよく、有料で行ってもよい。
【００５７】
データベース２７内には、ＥＣサイト１８に会員登録した膨大な数の利用者のため、膨大な数の個人用Ｗｅｂページが蓄積されているが、その中から、ページ読み出し部２４が当該利用者Ｕ１１の個人用Ｗｅｂページを特定するには、前記ログイン画面で入力させたユーザＩＤやパスワードを利用することができる。
【００５８】
一方、アクセスしてきたのが会員登録済みの前記専門アドバイザのうちの一人（例えば、Ｕ２１）であるとすると、ログイン以降の処理で当該専門アドバイザＵ２１が最初に閲覧するのは、自身のために用意されたアドバイザ用トップページＰＡ１であり、つづいて、必要ならば、当該アドバイザ用トップページＰＡ１の後述する機能を利用して、各個人用Ｗｅｂページ（例えば、前記ＰＰ１）に属する前記専門アドバイザ用Ｗｅｂページ（例えば、ＰＰ１２）を閲覧することになる。
【００５９】
そのため、専門アドバイザからのアクセスに対しては、ページ読み出し部２４は、前記ログイン画面（当然、認証結果は肯定的）の次に当該アドバイザ用トップページＰＡ１を読み出して提案端末１３に送信することになる。ここでも、会員登録した多数の専門アドバイザ（Ｕ２１，Ｕ２２はその一部）のなかから当該専門アドバイザＵ２１のためのアドバイザ用トップページＰＡ１を特定するために、前記ログイン画面で当該専門アドバイザが入力したユーザＩＤやパスワードを利用することになる。
【００６０】
なお、Ｗｅｂサーバ１１の処理上、利用者と専門アドバイザは区別する必要があるが、その区別は、会員登録時に、利用者として登録するか、専門アドバイザとして登録するかを、各ユーザに選択させ、その選択の結果をデータベース２７の専門アドバイザ管理テーブルＴＡ内で保存することによって実現可能である。一例として、会員登録時に利用者に付与するユーザＩＤと、専門アドバイザに付与するユーザＩＤに、異なる特徴を持たせることにようにすることも簡便である。
【００６１】
前記ページ生成部２３は、前記個人用Ｗｅｂページ（例えば、ＰＰ１）やアドバイザ用トップページ（例えば、ＰＡ１）などのＷｅｂページを生成する機能を持つ部分で、生成したＷｅｂページは、新規に、あるいは、既存の対応するＷｅｂページを更新する形で、データベース２７に蓄積する。
【００６２】
データベース２７へＷｅｂページを新規に蓄積するのは、新たな会員登録が行われ、その会員のために、個人用Ｗｅｂページや、専門アドバイザ用トップページを生成した場合であり、更新する形で蓄積するのは、すでにデータベース２７に蓄積されている個人用Ｗｅｂページや専門アドバイザ用トップページの内容の一部を変更した場合である。このような変更は、例えば、個人用Ｗｅｂページに記述されている提案リスクマネジメントを変更する場合などに発生する。
【００６３】
ページ生成部２３による当該ＷｅｂページＰＰ１１やＰＰ１２などのＷｅｂページの生成は、情報収集部２２が収集した情報に基づいて行われる。
【００６４】
専門アドバイザが各利用者のために作成した提案リスクマネジメントの内容も、当該ページ生成部２３により、所定のＷｅｂページ（提案リスクマネジメントページ）として生成され、その利用者（例えば、Ｕ１１）の個人用ＷｅｂページＰＰ１の一構成要素となる。
【００６５】
情報収集部２２は、いわゆるフォームの機能を利用して、利用者や専門アドバイザが入力した情報を収集し、データベース２７に一時的に保存する部分である。一時的に保存した情報は、ページ生成部２３によるＷｅｂページの生成に利用されたあと削除されるものであってよい。なお、必要に応じて、収集した情報はデータベース２７に保存することなく、直接、ページ生成部２３に渡し、ページ生成部２３が直ちにその情報に基づいてＷｅｂページを生成するようにしてもよい。
【００６６】
必要ならば、情報提供ユーザ（Ｕ３１など）もフォームを利用して、前記事業者提供情報をＥＣサイト１８へ提供するようにしてもよい。
【００６７】
フォームは、テキストボックス、テキストエリア、ラジオボタンなどの各種フィールドを備えたＨＴＭＬファイルである。利用者Ｕ１１や、専門アドバイザＵ２１、情報提供ユーザＵ３１などが端末１５，１３のＷｅｂブラウザを介して閲覧中のフォームの各フィールドに入力した情報（前記事業者提供情報も含む）は、インターネット１７を介してＷｅｂサーバ１１に送信されるため、Ｗｅｂサーバ１８内の情報収集部２２へ到達する。
【００６８】
入力する情報のサイズが大きい場合などには、フォームではなく、ＦＴＰプロトコルを利用して各端末１５，１３、８などから送信するようにしてもよい。そのためには、ＥＣサイト１８側で前記ＦＴＰサーバを用意する必要があるが、現在、広く使用されている多くのＷｅｂブラウザはＦＴＰクライアントの機能も備えているため、利用者、専門アドバイザ、情報提供ユーザなどの会員ユーザ側では、端末８，９、１３〜１６に特段の機能追加などを行う必要が生じる可能性は低い。
【００６９】
ＦＴＰプロトコルを利用する場合などには、前記事業者提供情報は、ＣＳＶ形式のファイル（ＣＳＶファイル）に収容して送信することも望ましい。
【００７０】
情報集約部２５は、前記情報提供端末８，９から供給される事業者提供情報を集約処理することにより、注目している利用者（例えば、Ｕ１１）に関してリスクの全体像の把握を容易化する部分で、効率的なトータル・リスク・コンサルティングを可能にする。
【００７１】
事業者提供情報の提供元である事業者Ｍ２，Ｍ３などは多くの場合、事業者Ｍ１や、いずれか１つのリスクマネジャーとは別な事業者であるため、同一の利用者（例えば、Ｕ１１）に対しても異なるユーザＩＤを付与するなどの相違があり、そのままでは、ＥＣサイト１８に提供された事業者提供情報のうち、どの事業者提供情報が利用者Ｕ１１の保険契約内容を示す情報であるかさえ識別できないなどの不便がある。この不便を解消するのが、当該情報集約部２５の行う集約処理である。
【００７２】
したがって集約処理には様々な処理が含まれ得るが、本実施形態では、個々の利用者を識別して、当該利用者に関する事業者提供情報をまとめる処理（第１の集約処理）と、第１の集約処理を実行したあと各事業者提供情報に含まれる多様な情報のなかから対応する情報を特定してその作用をまとめる処理（第２の集約処理）と、当該利用者に関する所定範囲の近親者（例えば、配偶者など）に関しても当該第１および第２の集約処理を実行しその実行結果を当該利用者に関する事業者提供情報の一部として整理する処理（第３の集約処理）とから、集約処理が構成されるものとする。
【００７３】
第１の集約処理は、個々の利用者に関する提案リスクマネジメントを作成する際には、必要不可欠な前提となる
第１の集約処理を実行する場合、一般的には、事業者Ｍ２，Ｍ３などで利用者に付与される各ユーザＩＤの表記規則さえ分かっていれば、その表記規則に合わせた解釈処理を行うことによってＥＣサイト１８側でも当該ユーザＩＤの指定する利用者を特定することも可能である。また、必要に応じて、ユーザＩＤ以外の識別情報を利用することも望ましい。
【００７４】
例えば、電話番号（住所などでも可）と氏名が特定できれば、ほとんどの場合、利用者をグローバルに、なおかつ一意に特定できる。
【００７５】
また、第２の集約処理や第３の集約処理も、精度の良いリスクマネジメントを行うためには、実行することが望ましい。
【００７６】
必要ならば、前記利用者用Ｗｅｂページ（例えば、ＰＰ１１など）には、提案リスクマネジメントとともに、その提案リスクマネジメントを利用者が採用した場合のシミュレーション情報を表示するようにしてもよい。シミュレーション情報は、その提案リスクマネジメントを採用した場合、所定時間後（例えば、１ヶ月後、３ヶ月後、１年後、１０年後など）に、その利用者の資産状況、生活状況、営業活動状況などがどのように変化するかをシミュレーションによって予測した情報である。
【００７７】
そのためには、当該シミュレーションを実行する機能を、ＥＣサイト１８の内部または外部に設けることになる。
【００７８】
決済処理部２６は、前記専門アドバイザが所属するリスクマネジャーなどを含むリスクマネジャーと利用者のあいだ、利用者とＥＣサイト１８を運営する事業者Ｍ１のあいだ、および当該リスクマネジャーと当該事業者Ｍ１のあいだ等における決済の状況を監視し、適切な決済が行われたか否かを管理する部分である。
【００７９】
保険商品の購入（契約）や解約などの場合、オンラインショップや、インターネットオークションなどのように、物品としての商品の引き渡しを伴わないため、決済方法に求められる条件はかなり緩やかで、様々な決済方法を使用可能である。
【００８０】
例えば、ある提案リスクマネジメントにしたがって、利用者Ｕ１１などが前記専門アドバイザＵ２１などが所属するリスクマネジャーが取り扱う保険商品を購入する場合などには、提案端末１３側に決済用のサーバ機能を用意しておけばＥＣシステム１０の内部だけで決済を完結することができる。
【００８１】
ただしこの際、代理店の紹介などを行い、利用者用ＷｅｂページＰＰ１１に当該代理店のＷｅｂページ（図示せず）へのリンク、または保険会社としてのリスクマネジャーのＷｅｂページ（図示せず）ヘのリンクを設けておくことも望ましい。
【００８２】
その決済では、必要に応じて、ＥＣシステム１０外のクレジットカード会社などを介するクレジットカード決済なども利用可能である。
【００８３】
このように個人用Ｗｅｂページや代理店などのＷｅｂページ上で、保険契約を完結する場合は、保険会社や代理店の側にも、販売活動を効率化できる利点があるため、範囲料率などを活用し通常の契約よりも保険料を割り引くようにしてもよい。
【００８４】
利用者が利用者用Ｗｅｂページ上で保険を契約・解約した場合はもとより、当該利用者用Ｗｅｂページ上以外で保険を契約・解約した場合（当該利用者用Ｗｅｂページにリンクされた代理店などのＷｅｂページ上で保険を契約・解約した場合や、店舗に出向いて対面で保険を契約・解約した場合など）も、その内容が保険会社または代理店のコンピュータに入力・計上され、そのコンピュータから当該入力・計上の結果が電送された時点で、その結果を、利用者用ＷｅｂページＰＰ１１や専門アドバイザ用ＷｅｂページＰＰ１２、代理店のＷｅｂページなどに表示されている、利用者の保険加入状況に反映させることも望ましい。
【００８５】
当該入力・計上の結果を電送するために必要ならば、ＥＣサイト１８と各保険会社または代理店のコンピュータとを専用線やＩＰ網（通信事業者が構築した閉じたＩＰネットワーク（ＩＰ−ＶＰＮ網なども含む））などで接続するようにしてもよい。
【００８６】
インターネット１７経由の通信では、通信品質が保証されておらず、十分な即時性を確保することが難しいことも多いが、専用線やＩＰ網などでは、通信品質を保証することができるため、即時性を確保し、前記入力・計上の結果を個人用ＷｅｂページＰＰ１の内容に速やかに反映させることが可能になる。
【００８７】
また、前記入力に応じた保険会社または代理店のコンピュータ上での計上と、当該入力に応じて、前記ＥＣサイト１８上で行う個人用ＷｅｂページＰＰ１の書き換えとを、一体不可分な１つのトランザクション（オンライントランザクション）内の操作として処理することにより、論理的に即時性を確保することも可能である。例えば、個人用ＷｅｂページＰＰ１の書き換えが完了したあとでなければ、保険会社または代理店のコンピュータ上での計上が行えないように当該トランザクションを構成することにより、個人用ＷｅｂページＰＰ１の内容と保険会社等のコンピュータの計上の内容の整合性を常に保証することができる。
【００８８】
１つのトランザクションはトランザクション中の全ての操作を完全に行うか、１つの操作も行わないかのいずれかの終了形態しか許されないオール・オア・ナッシングの処理であり、何らかの障害で、もし個人用ＷｅｂページＰＰ１の内容を書き換えることができなければ、保険会社等のコンピュータへの計上も行うことができないからである。
【００８９】
なお、前記決済のための通信を含め、ＥＣシステム１０内でインターネット１７を経由して行われる通信は、基本的にすべて、暗号化によって秘匿性を確保する必要がある。インターネット１７経由の通信でやり取りされる情報は、利用者の保険契約の内容など、そのほとんどが、個人情報に属するものだからである。さらに、必要に応じて、秘匿性を確保するだけでなく、なりすましや、改ざんの検出、防止にも配慮する必要がある。
【００９０】
端末１３〜１６、８，９のＷｅｂブラウザとＷｅｂサーバ１１（前記ＦＴＰサーバも含む）のあいだの通信の暗号化には、前記ＦＴＰによるファイル転送なども含め、ＳＳＬが使用でき、クレジットカード会社を介するクレジットカード決済の暗号化では、ＳＥＴやＳＥＣＥなどのプロトコルが利用できる。
【００９１】
ＥＣサイト１８を運営する事業者Ｍ１は、当該ＥＣサイト１８を利用して利用者（例えば、Ｕ１１）が保険商品を購入した保険会社などが、会員登録した専門アドバイザの所属するリスクマネジャー等であれば、そのリスクマネジャーから、所定の手数料などサービス提供の対価を電子商取引によって、自動的に受け取ることができるようにしてもよい。
【００９２】
なお、必要に応じて、ＥＣサイト１８はこのような対価を要求しない無料サイトとすることも可能である。すべての会員ユーザに対して対価を要求しないようにしてもよいが、一部のユーザには対価を要求するようにしてもよい。例えば、利用者（Ｕ１１など）に対しては対価を要求せず、リスクマネジャー（Ｍ４など）に対しては対価を要求したり、その反対に、利用者（Ｕ１１など）に対しては対価を要求し、リスクマネジャー（Ｍ４など）に対しては対価を要求しないようにしてもよい。
【００９３】
一方、前記データベース２７には、上述したＰＰ１，ＰＰ２，ＰＡ１，ＰＡ２などのＷｅｂページ群のほか、各ユーザを管理するための管理テーブルＴＡとＴＳと、前記事業者提供情報を格納するための事業者提供情報テーブルＤＴ１と、当該事業者提供情報テーブルＤＴ１内の事業者提供情報に対し、前記情報集約部２５で集約処理を施した結果を格納する集約結果テーブルＤＴ２が蓄積されいる。
【００９４】
管理テーブルＴＡは、専門アドバイザを管理するためのテーブルで、管理テーブルＴＳは利用者を管理するためのテーブルである。同じ管理テーブルで専門アドバイザと利用者を管理してもかまわないが、専門アドバイザと利用者では管理のためのデータ項目が異なることから、ここでは、別な管理テーブルを設けることとした。
【００９５】
利用者管理テーブルＴＳの構成例は図５に示すとおりである。
【００９６】
図５において、当該利用者管理テーブルＴＳは、データ項目（列名）として、「ユーザＩＤ」、「パスワード」、「アクセス許容アドバイザ」、「料金支払状況」、「ＵＲＬ」を備えている。
【００９７】
「ユーザＩＤ」は、ＥＣシステム１０内において各ユーザ（利用者および専門アドバイザ）を一意に識別するための識別子である。ユーザＩＤの具体的な値を構成する文字列の全部または一部は、ＥＣサイト１８側で自動的に生成してもかまわないが、ログイン時に各ユーザに入力させる必要があるため、ユーザＩＤの内容は該当する各ユーザに伝えておく必要がある。
【００９８】
「パスワード」は、各ユーザがＥＣサイト１８にログインする際、前記ユーザＩＤとともに入力する必要のある文字列である。
【００９９】
「アクセス許容アドバイザ」は、各利用者が、自身のための個人用Ｗｅｂページ（例えば、ＰＰ１）へアクセスすることを許容する専門アドバイザを指定する情報である。この指定を行うのは、利用者自身であり、指定の内容は利用者がいつでも自由に変更することができる。
【０１００】
ここで指定するのは、各専門アドバイザが所属するリスクマネジャーの名称などではなく、専門アドバイザの個人名とするのが望ましい。同じリスクマネジャーに所属する専門アドバイザであっても、経験や熟練度に優れ、真に信頼するに値すると利用者（例えば、Ｕ１１）が認めた者だけにしか当該利用者の個人用Ｗｅｂページ（ここでは、ＰＰ１）にアクセスさせないようにすることが望ましいからである。
【０１０１】
したがって、専門アドバイザ（例えば、Ｕ２１）が各利用者の資産状況などに応じて提案する上述した提案リスクマネジメントも、リスクマネジャー名ではなく、専門アドバイザの個人名で提案されることが望ましい。
【０１０２】
なお、専門アドバイザの個人名（個人の姓名）だけでは一意性を確保できない可能性がある場合などには、個人名に換えて、あるいは個人名とともに、所属するリスクマネジャー名や、専門アドバイザのユーザＩＤ（テーブルＴＡで管理するユーザＩＤとは別に、利用者による指定用のユーザＩＤを用意してもよい）などを用いるようにしてもよい。
【０１０３】
ＥＣサイト１８に会員登録した専門アドバイザの数が、上述した数百人であるとすると、一人の利用者のアクセス許容アドバイザとして、多い場合には、数百人分の個人名が並ぶ可能性がある。
【０１０４】
「料金支払い状況」は、各利用者が、ＥＣサイト１８に対する料金の支払いを適切に行っているか否か等を示す情報である。必要に応じて、前記決済処理部２６が管理する前記専門アドバイザが所属するリスクマネジャー、利用者、事業者Ｍ１の相互間で、決済が適切に行われているか否かの管理も、この料金支払い状況を用いて行うようにしてもよい。
【０１０５】
「ＵＲＬ」は、各利用者の前記個人用Ｗｅｂページ（例えば、ＰＰ１など）を指定するＵＲＬである。個人用Ｗｅｂページが複数ページにおよぶ場合、最初にアクセスさせたいページ（例えば、前記ＰＰ１１）のＵＲＬであってよい。
【０１０６】
図５中、最上部のＵ１１ＩＤ、ＰＷ１１，Ｕ２１，適、ＵＲ１１の行Ｌ１１は、前記利用者Ｕ１１に対応する行で、上から２番目の行Ｌ１２は、前記利用者Ｕ１２に対応する行である。
【０１０７】
次に、前記専門アドバイザ管理テーブルＴＡの構成例は、図６に示す。
【０１０８】
図６において、当該専門アドバイザ管理テーブルＴＡは、データ項目（列名）として、「ユーザＩＤ」、「パスワード」、「対象利用者」、「対象ＵＲＬ」、「料金支払状況」を備えている。
【０１０９】
この「ユーザＩＤ」、「パスワード」、「料金支払い状況」は、図５に示した利用者管理テーブルＴＳと同様である。
【０１１０】
「対象利用者」は、前記利用者管理テーブルＴＳのデータ項目「アクセス許容アドバイザ」に対応するデータ項目で、各専門アドバイザが対象とすることのできる（すなわち、個人用Ｗｅｂページを閲覧して提案リスクマネジメントの提案を行うことのできる）利用者の集合を示す。
【０１１１】
ＥＣサイト１８に会員登録した利用者の数が、上述した数万人であるとすると、一人の専門アドバイザの対象利用者として、多い場合には、数万人分の個人名が並ぶ可能性がある。
【０１１２】
この利用者の個人名に関しても、前記「アクセス許容アドバイザ」の個人名と同様、一意性を確保するために、個人名に換えて、あるいは個人名とともに、利用者が所属する法人の名称や、利用者のユーザＩＤ（テーブルＴＳで管理するユーザＩＤとは別に、専用のユーザＩＤを用意してもよい）などを用いるようにしてもよい。
【０１１３】
「対象ＵＲＬ」は各専門アドバイザが対象とすることのできる（すなわち、閲覧することのできる）個人用Ｗｅｂページ（例えば、ＰＰ１）のＵＲＬを示すデータ項目である。各専門アドバイザに関する当該「対象ＵＲＬ」の具体的な値は、前記利用者管理テーブルＴＳの「アクセス許容アドバイザ」の具体値と、「ＵＲＬ」の具体値に基づいて決定されるから、利用者が「アクセス許容アドバイザ」の値を変更すると、その変更に連動して、当該「対象ＵＲＬ」の具体値も変更される。この点は、前記データ項目「対象利用者」についても同様である。
【０１１４】
もっとも、個人用Ｗｅｂページ（例えば、ＰＰ１）が複数ページから構成される場合、アクセスを許可した専門アドバイザであっても必ずしもすべてのページを閲覧できるようにする必要はないし、ページ単位で閲覧できるようにする必要もない。例えば、個人用Ｗｅｂページ（例えば、ＰＰ１）を構成する複数のＷｅｂページのうち、一部のＷｅｂページのＵＲＬだけを当該「対象ＵＲＬ」に記述してそのＷｅｂページにのみアクセスできるようにしてもよく、あるＷｅｂページ中の一部の情報だけをもとに新たなＷｅｂページを、前記ページ生成部２３に生成させ、そのＷｅｂページを専門アドバイザに閲覧させるようにしてもよい。
【０１１５】
なお、前記「対象利用者」と同様、この「対象ＵＲＬ」に記述されるＵＲＬの数は、会員登録された利用者の数に応じて、多い場合には、例えば、上述した数万（あるいは、その数倍）におよぶ可能性がある。
【０１１６】
図６中、最上部のＵ２１ＩＤ、ＰＷ２１，Ｕ１１，Ｕ１２，ＵＲＬ１１，ＵＲＬ１２，適の行Ｌ２１は、前記専門アドバイザＵ２１に対応する行で、上から２番目の行Ｌ２２は、前記専門アドバイザＵ２２に対応する行である。
【０１１７】
以下、上記のような構成を有する本実施形態の動作について、図３，図４，図７を用いて説明する。
【０１１８】
図７は、前記情報集約部２５の処理、あるいは情報集約部２５の処理に関連して情報提供事業者（Ｍ２など）が行う処理を示すシステムフローで、Ｓ１０〜Ｓ２０の各ステップを有する。
【０１１９】
また、図３，図４は、当該情報集約部２５の処理を説明するための図である。
【０１２０】
（Ａ−２）実施形態の動作
上述した利用者Ｕ１１とＵ１２、および専門アドバイザＵ２１とＵ２２がそれぞれＥＣサイト１８に対する会員登録を済ませ、前記利用者管理テーブルＴＳが図５に示す状態で、専門アドバイザ管理テーブルＴＡが図６に示す状態であるとする。
【０１２１】
この場合、データ項目「アクセス許可アドバイザ」の値から、利用者Ｕ１２は、専門アドバイザＵ２１とＵ２２に自身の個人用Ｗｅｂページに対するアクセスを認めており、利用者Ｕ１１は専門アドバイザＵ２２のアクセスは拒否し、専門アドバイザＵ２１のアクセスだけを認めていることがわかる。
【０１２２】
したがって、利用者Ｕ２２の個人用ＷｅｂページＰＰ２のうち、「対象ＵＲＬ」で指定されたＷｅｂページに対しては、専門アドバイザＵ２１とＵ２２の双方がアクセスでき、利用者Ｕ２１の個人用ＷｅｂページＰＰ１のうち、「対象ＵＲＬ」で指定されたＷｅｂページに対しては、専門アドバイザＵ２１だけしかアクセスすることはできない。
【０１２３】
これにより、利用者Ｕ１１は、信頼が置けないと判断した専門アドバイザＵ２２に、自身の保険契約の内容を知られたり、提案リスクマネジメントを提供されることがなくなる。適切な提案リスクマネジメントを提供する能力に疑問があると利用者（Ｕ１１など）がみなした専門アドバイザは、このようにして各利用者から、個人用Ｗｅｂページへのアクセスを拒否される。
【０１２４】
一方、利用者（氏名は、日動太郎で、配偶者が日動花子）Ｕ１１が保険会社等である前記情報提供事業者Ｍ２，Ｍ３とのあいだで保険契約を締結しているものとすると、情報提供事業者Ｍ２，Ｍ３側では、保険の種類（例えば、医療保険、自動車保険など）単位にまとめた保険契約データＤＴ１１〜ＤＴ１４ごと、あるいは、保険契約データ中の各データ項目（例えば、氏名、保険の種類、保険の支払額（医療保険の場合なら、入院日額））ごとに、契約データＩＤを付与している（Ｓ１０，Ｓ１２）。
【０１２５】
図７では、保険契約データＤＴ１１〜ＤＴ１４ごとのＩＤは図示していないので、当該契約データＩＤは、保険契約データ中の各データ項目を識別するためのＩＤである。
【０１２６】
さらに各情報提供事業者Ｍ２，Ｍ３では、リスクの種類ごとに、リスクＩＤも付与している（Ｓ１１，Ｓ１３）。リスクの種類は通常、保険の種類に対応する。例えば、医療保険や生命保険ならば、通常、利用者（例えば、Ｕ１１）が入院した場合に保険金が支給され、入院というリスクに対して同質の作用を持つから、同じリスクＩＤ（図７では、Ｒ０１）を付与することになる。
【０１２７】
図７から明らかなように、当該保険契約データＤＴ１１〜ＤＴ１４のうち、ＤＴ１１、ＤＴ１２，ＤＴ１４は、情報提供事業者Ｍ２から提供されるものであり、ＤＴ１３は情報提供事業者Ｍ３から提供されるものである。また、ＤＴ１１〜ＤＴ１３は利用者Ｕ１１本人に関する保険契約データであり、ＤＴ１４は利用者Ｕ１１の配偶者に関する保険契約データである。
【０１２８】
これら保険契約データＤＴ１１〜ＤＴ１４を含む事業者提供情報を受け取った事業者Ｍ１のＥＣサイト１８では、当該保険契約データＤＴ１１〜ＤＴ１４を前記事業者提供情報テーブルＤＴ１に格納したあと、前記情報集約部２５が動作する。
【０１２９】
事前に取り決め等を行っておかなければ、前記契約データＩＤやリスクＩＤは、各情報提供事業者（例えば、Ｍ２）の内部でのみ通用するローカルな識別情報になるのが普通であるが、ここでは、グローバルな（少なくとも、通信システム１０の内部では一意性の保証された）識別情報としている。このようなグローバルな契約データＩＤを付与するためには、各情報提供事業者間（例えば、Ｍ２，Ｍ３のあいだ）で、取り決めを行い、システムも、契約データＩＤの表記規則などが同じになるように構成しておくことが必要である。
【０１３０】
事業者提供情報の提供を受けた時点で、このようなグローバルな識別情報が付与されていれば、前記情報集約部２５が実行する集約処理は簡単なものとなる。
【０１３１】
当該情報集約部２５が実行する集約処理の内容には様々なものがあり得るが、ここでは、最初に、仮のファミリＩＤと個人ＩＤを付与している（Ｓ１４，Ｓ１５）。ファミリＩＤは、前記利用者の家族を識別する情報であり、個人ＩＤは前記利用者を含む家族のメンバを個別に識別する情報である。図７から明らかなように、ここでは、一例として、ファミリＩＤには７桁の１０進数を用い、当該ファミリＩＤの末尾に２桁の１０進数を結合したものを個人ＩＤとしている。
【０１３２】
次に、上述したグローバルな契約データＩＤを照合して名寄せを行う（Ｓ１６）。
【０１３３】
ここでは、前記契約データのデータ項目のうち氏名、郵便番号、住所、生年月日の契約データＩＤを照合することによって名寄せを行っているが、必要ならば、ＩＤを用いずに、直接、これらの契約データ本体を照合して名寄せを行うことも可能である。その場合には、表記のゆれなどを吸収するための対策を講じる必要があるものの、情報提供事業者Ｍ２，Ｍ３がグローバルな契約データＩＤを付与する必要はなくなるため、事前に情報提供事業者間で取り決めを行ったり、契約データＩＤの表記規則などが同じになるようにシステムを構成する必要もなくなる。また、場合によっては、契約データＩＤそのものを省略できる可能性もある。
【０１３４】
また、ここでは、氏名、郵便番号、住所、生年月日の契約データＩＤを照合しているが、その一部は省略したり、他の識別情報と置換することも可能である。例えば、郵便番号や生年月日は省略し、住所と氏名の契約データＩＤだけを用いても、ほとんどの場合、一意性は確保され、問題は生じないものと考えられる。
【０１３５】
ステップＳ１６の名寄せが完了すると、前記ステップＳ１４，Ｓ１５では異なるファミリＩＤや個人ＩＤであったものが１つに集約される（Ｓ１７、Ｓ１８）。これにより、家族単位、個人単位の集約が実現され、例えば、契約データＤＴ１１〜ＤＴ１４が１つの家族（利用者Ｕ１１の家族）に対応する事業者提供情報であり、なかでも、ＤＴ１１，ＤＴ１２，ＤＴ１４は利用者Ｕ１１本人の保険契約内容であり、Ｄ１４は利用者Ｕ１１の家族に属する利用者Ｕ１１以外のメンバ（ここでは、配偶者）の保険契約内容であることが分かる。さらなる処理を行うことにより、例えば、契約データＤＴ１４が利用者Ｕ１１の配偶者であることまで特定することも可能である。
【０１３６】
次に、前記リスクＩＤを照合し（Ｓ１９）、同じリスクＩＤの作用（保障）を合成することにより、当該利用者（例えば、Ｕ１１）の当該リスクに関するトータルな作用（保障）の大きさを算出することができる（Ｓ２０）。このステップＳ２０で、情報集約部２５が行う集約処理は完了する。
【０１３７】
なお、上述したステップＳ１０〜Ｓ１８までの処理を、別なケースを例に取って説明したのが、図３（Ａ）〜（Ｃ）である。
【０１３８】
図３は、情報提供事業者が４つの保険会社であるケースを示している。
【０１３９】
また、前記ステップＳ１９〜Ｓ２０の処理を、別なケースを例に取って説明したのが、図４（Ａ）および（Ｂ）である。
【０１４０】
図７では入院保障に関してのみトータルな保障の大きさを算出したが、図４（Ａ）、（Ｂ）では、個人賠償責任、傷害死亡、疾病死亡など、その他の保障に関しても、複数の保険会社によるトータルな保障の大きさを算出している。
【０１４１】
以上のような集約処理によって、事業者提供情報テーブルＤＴ１に格納されている事業者提供情報の内容を整理、集約し、集約結果を集約結果テーブルＤＴ２に格納しておけば、利用者Ｕ１１の個人用ＷｅｂページＰＰ１のうち前記専門アドバイザ用ＷｅｂページＰＰ１２には、利用者Ｕ１１に関する保険契約の内容を、分かりやすく整理して表示できるから、専門アドバイザＵ２１は、利用者Ｕ１１を取り巻くリスクの全体像を短時間で効率的に把握することができる。
【０１４２】
これにより専門アドバイザＵ２１は、専門アドバイザ用ＷｅｂページＰＰ１２を介して良質な提案リスクマネジメントを提供することができるから、従来は実現困難であったトータル・リスク・コンサルティングを容易に実現することが可能になる。
【０１４３】
なお、専門アドバイザ用ＷｅｂページＰＰ１２に専門アドバイザＵ２１が記述した提案リスクマネジメントを、利用者用ＷｅｂページＰＰ１の記述内容に反映させること等は、前記ページ生成部２３にＣＧＩプログラムなどを実装すること等によって容易に実現可能である。
【０１４４】
また本実施形態では、利用者Ｕ１１のほうでも、当該トータル・リスク・コンサルティングの実現のために多くの時間や労力を要することがない。
【０１４５】
利用者Ｕ１１は、専門アドバイザＵ２１が提案した提案リスクマネジメントやそのシミュレーション情報などを閲覧することで、必要性を感じれば、基本的にいつでも、新たな保険商品を購入などを行うことができる。この購入をＥＣサイト１８経由で行ってもよいことは当然である。
【０１４６】
ＥＣサイト１８経由の購入では、前記決済処理部２６の機能や、ＳＥＴやＳＥＣＥなどのプロトコルによるクレジットカード決済などを利用できるため、利用者Ｕ１１は、保険会社の店舗などへ出向くことなく、利用者端末１５を操作するだけでよい。
【０１４７】
なお、新たな提案リスクマネージが提案されたことや、シミュレーション情報が生成され、データベース２７に蓄積されたことを利用者Ｕ１１に通知するため、ＥＣサイト１８から利用者端末１５に宛てて電子メールを送信するようにしてもよい。
【０１４８】
この場合、ＥＣサイト１８内にメールサーバを設けたり、このような電子メールを自動的に生成する機能を設けることが望ましい。また、当該電子メールは、利用者端末１５宛てではなく、利用者Ｕ１１の携帯電話機（図示せず）などに宛てて行うようにしてもよい。携帯電話機の電子メールシステムでは、利用者Ｕ１１がどこにいても、電子メールの着信を、着信音やバイブレーションによって即座に利用者Ｕ１１に伝えることができるため、ＥＣサイト１８側では、利用者Ｕ１１からの速やかな応答が期待できる。
【０１４９】
一方、前記専門アドバイザＵ２１がＵ１１などの利用者の個人用Ｗｅｂページにアクセスする場合、その前に、前記アドバイザ用トップページＰＡ１を閲覧することになる。
【０１５０】
このアドバイザ用トップページは、１または複数のハイパーリンクや、当該アドバイザ用トップページに関連づけられたプログラムを伴う。ハイパーリンクは、図６に示す「対象ＵＲＬ」の値ＵＲＬ１１，ＵＲＬ１２で、それを利用者Ｕ１１が利用者端末１５のＷｅｂブラウザを介して操作（クリックなど）することにより、該当する利用者（例えば、ＵＲＬ１１に対しては利用者Ｕ１１）の個人用Ｗｅｂページ（例えば、ＰＰ１）にアクセスすることができる。
【０１５１】
これにより、専門アドバイザＵ２１はクリックなどの簡単な操作を行うだけで個人用ＷｅｂページＰＰ１にアクセスできる。
【０１５２】
当該アドバイザ用トップページも、Ｗｅｂブラウザの制御下にある前記キャッシュ領域に保存されるので、Ｗｅｂブラウザの機能によって、その都度、このアドバイザ用トップページを読み出して画面表示すれば、アドバイザ用トップページ上のハイパーリンクが複数存在し複数の利用者の個人用Ｗｅｂページに専門アドバイザＵ２１がアクセスする必要がある場合にも対応可能である。
【０１５３】
これにより、上述したアクセス拒否などのステータスコードをＷｅｂサーバ１１の通信部２０から送信される可能性もなくなり、操作性が極めて良好であるため、専門アドバイザＵ２１は、提案リスクマネジメントの作成だけに専念することができる。
【０１５４】
さらに、良好な操作性を求める場合には、前記プログラムの機能や、Ｗｅｂブラウザに新たな機能を追加するためのプラグインソフトの機能、フレームの機能などを利用して、逐一、キャッシュ領域からアドバイザ用トップページを読み出して画面表示させるための操作を行わなくても、クリックなどの簡単な操作だけで、複数の個人用Ｗｅｂページに次々とアクセスできるようにすることも可能である。
【０１５５】
一例としては、メニューを置いたフレームを利用し、当該専門アドバイザ（例えば、Ｕ２１）にアクセスを許可している複数の利用者（例えば、Ｕ１１）の個人用Ｗｅｂページ（例えば、ＰＰ１２）のＵＲＬをメニュー内のハイパーリンクとして埋め込む構成とするのも、効率的である。ただしこの場合、提案端末１３，１４などがフレーム対応のＷｅｂブラウザを搭載していることを要する。
【０１５６】
多数の利用者に対する提案リスクマネジメントの提供を効率的に行うためには、このようなアドバイザ用トップページの機能が重要である。
【０１５７】
アドバイザ用トップページによれば、対面でアドバイスを行う場合に比べて、はるかに効率的にアドバイスを行うことができるため、リスクマネジャーの側からみても、少数の高度専門アドバイザを効率的に活用できる利点がある。
【０１５８】
なお、アドバイスの効率性をいっそう高めるため、所定の条件に該当する複数の利用者に対し、一人の専門アドバイザから、一括して、同じ提案リスクマネジメントを提供することのできる仕組みを構築することも望ましい。
【０１５９】
例えば、多数の利用者に関する集約結果テーブル（例えば、前記ＤＴ２）に対する検索処理により、所定の条件に該当する保険契約内容の利用者集団を特定することができるため、その利用者集団を構成する各利用者にとって、より重要な提案リスクマネジメントを提供し、当該提案リスクマネジメントを介して、保険商品の購入を一括して勧めることができる。
【０１６０】
一例として、各利用者が締結している生命保険Ａ１の契約内容と同じ内容の生命保険契約を結ぶことができ、なおかつ、掛け金がその契約内容に対応する生命保険Ａ１の掛け金よりも有利な保険商品Ａ２の購入を、前記検索処理によって得られた複数の利用者に勧めること等が可能になる。
【０１６１】
この方法であれば、専門アドバイザは効率的に提案リスクマネジメントを提案できるため、一人の専門アドバイザ（例えば、Ｕ２１）が例えば数万人の利用者に対して提案リスクマネジメントを同時に提供することも容易である。
【０１６２】
また、商品を提供する保険会社としてのリスクマネジャーの側では、利用者の資産状況などに応じて選別を行い、選別した利用者にだけ、自社の高度専門アドバイザの提案リスクマネジメントを提供すること等が可能になる。
【０１６３】
画期的な保険商品を開発した場合などには、高度専門アドバイザにその保険商品の購入を含む提案リスクマネジメントを作成させること等により、その保険商品の売り込みを行うことができる。
【０１６４】
反対に、利用者の側からは、少数の高度専門アドバイザによる提案リスクマネジメントの提供を受けられる可能性がいっそう高くなるという利点がある。
【０１６５】
（Ａ−３）実施形態の効果
本実施形態によれば、利用者にとっても、専門アドバイザにとっても効率的なＥＣシステムを提供することができる。
【０１６６】
この効率性は、利用者にとって、少数の高度専門アドバイザによる適切なアドバイス（提案リスクマネジメントの提供）を得られる可能性アップにつながる。
【０１６７】
また、このような高度専門アドバイザの所属するリスクマネジャーなどにとっては、少ない高度専門アドバイザを効率的に活用することで、利用者から、大きな信頼を、長期間、得ることができる利点がある。
【０１６８】
さらに、従来は実現困難であったトータル・リスク・コンサルティングを実現することも容易となる。
【０１６９】
なお、本実施形態は、前記トータル・リスク商品の販売に際して利用しても有効である。
【０１７０】
（Ｂ）他の実施形態
なお、上記実施形態では、フォームなどを用いて前記利用者から収集した情報によらずに、前記事業者提供情報だけに基づいて前記専門アドバイザに提案リスクマネジメントを提供させ、その提案リスクマネジメントを記述した前記個人用Ｗｅｂページ（ＰＰ１など）を生成することがあってもよいが、その場合には、当該個人用ＷｅｂページのＵＲＬを当該利用者に通知する必要がある。
【０１７１】
この通知には、プッシュ型の通信を用いることができる。プッシュ型の通信には、例えば、電子メールなどのネットワーク経由の通信のほか、郵便なども含まれるものであってよい。
【０１７２】
電子メールの場合、利用者がリンクに対応したメーラを使用していれば、電子メールの本文に記述された当該リンク（ＵＲＬ）を操作（クリック）するだけで自動的にＷｅｂブラウザが起動して当該ＵＲＬで指定される個人用Ｗｅｂページへアクセスすることが可能となる。
【０１７３】
また、フォームなどのＷｅｂページを用いて前記利用者から収集した自己提供情報をもとに前記専門アドバイザが提案リスクマネジメントを提供し、その提案リスクマネジメントを記述した個人用Ｗｅｂページが生成された場合にも、当該個人用ＷｅｂページのＵＲＬを利用者に閲覧させるとよい。
【０１７４】
ただしこの場合には、利用者は前記フォームへ入力するためにＷｅｂページを閲覧中であるため、前記電子メールなどのプッシュ型通信を利用しなくても、通常のＷｅｂブラウジングと同様なプル型の通信、すなわち、フォームの入力内容を利用者側からＷｅｂサーバ側へ送信するＨＴＴＰリクエストに応えるＨＴＴＰレスポンスの形で、当該ＵＲＬを利用者に閲覧させることができる。
【０１７５】
このとき、予め専門アドバイザ側から、利用者の前記全体像に関する所定の条件とその条件に該当する利用者に対して提案する提案リスクマネジメントに関する情報を得ておき、ＷｅｂサーバがＨＴＴＰリクエストを受け取った場合には、当該情報をもとに即座に個人用Ｗｅｂページを生成してそのＵＲＬを決定し、前記ＨＴＴＰレスポンスを返すようにするとよい。このような処理は、Ｗｅｂサーバ側に搭載するＣＧＩプログラムなどによって実現可能である。
【０１７６】
また、当該ＵＲＬは、それ自体を利用者に目視させず、当該ＵＲＬに対応したボタンなどの表示部品を目視させ、当該ボタンなどの操作に応じて、当該ＵＲＬで指定される個人用Ｗｅｂページへ当該利用者がアクセスできるようにしてもよいことは当然である。
【０１７７】
なお、上記実施形態では、端末１３〜１５、８，９とＥＣサイト１８のあいだはすべて、インターネットで接続されていたが、必要に応じてその全部または一部が専用線で接続されるようにしてもよいことは当然である。
【０１７８】
例えば、提案端末（１３など）とＥＣサイト１８のあいだは専用線で接続するようにしてもよい。
【０１７９】
さらに、ＥＣサイト１８と各端末（１５など）とのあいだの通信の暗号化には、ＳＳＬのほかに、ＩＰｓｅｃ（ＶＰＮ）なども利用可能である。
【０１８０】
上記実施形態では、端末１３〜１６はパーソナルコンピュータとしたが、このパーソナルコンピュータは、ＰＤＡ端末、ＰＨＳ端末、携帯電話機などのモバイル端末、あるいは、デジタルテレビ端末などにも置換可能である。また、これらの汎用的な端末ではなく、専用の端末を利用するようにしてもよい。
【０１８１】
上記実施形態では、ハイパーテキストシステムを利用したが、メーリングリストシステムなどを活用することも可能である。
【０１８２】
また、上記実施形態においても多くの変形例を記載したが、さらに、以下のような変形例（Ｖ１）〜（Ｖ７）を使用することも望ましい。
【０１８３】
（Ｖ１）  前記利用者用Ｗｅｂページ（例えば、ＰＰ１）へ利用者が自身で入力した自己提供情報（例えば、自動車運転者の年齢、自動車保有台数、住宅の再調達価格などの個人情報）が、適切な提案リスクマネジメントを作成するために十分でない場合には、当該入力のために利用者が閲覧している画面を通じて、即座に、不足している情報の入力を促すようにする入力促進システム。
【０１８４】
この場合、入力された自己提供情報が適切な提案リスクマネジメントを作成するために十分であるか否かは、Ｗｅｂサーバ１１側のＣＧＩプログラムなどを利用して判断することができる。
【０１８５】
また、不足している情報の入力をそのＷｅｂページの閲覧中に即座に促すには、当該Ｗｅｂページを介した対話的な処理を行うことになるが、ある程度の時間がかかってもかまわない場合などには、電子メールや、紙媒体を用いるダイレクトメール、保険証券などを利用して入力を促すこともできる。さらに、前記プッシュ型通信を利用して入力を促すことも可能であるが、プッシュ型通信の場合には、その詳細な仕様により、即座に促すタイプと、一定時間の後に促すタイプの２通りがあり得る。
【０１８６】
ＥＣサイト１８が前記事業者提供情報の入力を受けた場合もこれと同様である。不足している情報の入力を促すことは、自己提供情報の入力を受けた場合だけでなく、前記事業者提供情報の入力を受けた場合にも起こり得るからである。
【０１８７】
情報提供事業者（例えば、Ｍ２など）側のシステムの運用負担などを考慮すると、現実には、事業者提供情報は、前記ＦＴＰプロトコルなどを利用して、一括して大量に転送される形式になる可能性が高いと考えられるが、もしも事業者提供情報がＷｅｂページのフォームなどを利用して対話的に転送される場合には、ＥＣサイト１８側から情報提供事業者に対し、不足している情報の入力を即座に促すことも可能である。
【０１８８】
また、事業者提供情報を対話的に提供する場合でも、ＦＴＰプロトコルなどを利用して一方的に転送する場合でも、前記電子メールやプッシュ型通信によって、不足している情報の入力を促すことは可能である。
【０１８９】
なお、情報（自己提供情報または事業者提供情報）の提供元に対して不足している情報の入力を促すのが基本であるが、必要ならば、提供元とは異なる相手に不足している情報の入力を促すようにしてもかまわない。例えば、情報提供事業者Ｍ１が提供した事業者提供情報が、適切な提案リスクマネジメントを作成するために十分でない場合に、当該情報提供事業者Ｍ１ではなく、他の情報提供事業者（例えば、Ｍ２）にその情報の提供を促したり、利用者（例えば、Ｕ１１）にその情報の提供を促すようにしてもよい。
【０１９０】
ＥＣサイト１８側にとって（または、リスクマネジャーにとって）、基本的に、その情報の提供元がどこであるかや、どのような収集方法を用いたかは重要ではなく、必要な情報が揃っていることが重要だからである。
【０１９１】
（Ｖ２）  利用者が現在保有している保険の満期の一定期間（例えば２ヶ月）前に、一定期間後に満期になる旨を、個人用Ｗｅｂページヘの表示または／および電子メールにて利用者に通知する満期予告システム。
【０１９２】
これによって、保険切れのリスクを軽減できる。
【０１９３】
ただし、個人用Ｗｅｂページを介した通信はプル型の通信であるため、利用者が当該一定期間のあいだに当該個人用Ｗｅｂページを閲覧しなければ満期を予告することができない。
【０１９４】
一例として、プッシュ型の通信を利用すれば、利用者に対して能動的に満期を予告することが可能である。様々な専用アプリケーションを利用してこのようなプッシュ型の通信を実現することができる。当該専用アプリケーションの機能により、利用者（例えば、Ｕ１１）が通信端末（例えば、１５）に対し何ら操作を行わなくても、例えば、Ｗｅｂブラウザ、壁紙、スクリーンセーバなどを媒介として、警告用のウインドウを開き、当該ウインドウ内に、満期を予告するメッセージを表示すること等が可能である。
【０１９５】
また、電子メール（プッシュ型通信手段の一種）などを利用して満期を予告することも簡便である。メーラは普及率の高いクライアントソフトであるため、電子メールによる満期予告は、実現性の点で有利である。
【０１９６】
（Ｖ３）  前記利用者用Ｗｅｂぺージ（例えば、ＰＰ１）を利用して、利用者（例えば、Ｕ１１）が入力した自己提供情報や提案リスクマネジメントのほかに、付随的な各種の情報（付随情報）を利用者に伝える付随情報提供システム。
【０１９７】
この付随情報のなかには、利用者に有益と思われるあらゆる情報を含めることができる。
【０１９８】
当該付随情報として、前記リスク・マネジャーから利用者に対する連絡・メッセージなどを伝えることも望ましい。
【０１９９】
（Ｖ４）  リスク・マネジャーが、利用者に対してリスク・マネジメントに関する提案を定期的または随時行うシステム。
【０２００】
上記実施形態でも、提案リスクマネジメントを定期的に、または随時、提供することは基本的にリスク・マネジャー（または専門アドバイザ）側の自由であり、ＥＣサイト１８側では例えばユーザ認証部２１などで、定期的にまたは随時、専門アドバイザが各個人用Ｗｅｂページ（例えば、ＰＰ１）へアクセスし、新たな提案リスクマネジメントを記述することを禁止しないようにするだけでよい。
【０２０１】
ただし、もっと積極的にＥＣサイト１８側が、前記提案リスクマネジメントの提供の定期性を確保するための機能を備えるようにしてもよい。
【０２０２】
例えば、提案リスクマネジメントを提供するべき時期が近づいたら、そのことをＥＣサイト１８側から専門アドバイザに通知することも望ましい。この通知には、電子メールなどの前記プッシュ型通信を利用することができる。
【０２０３】
定期性を保証して、例えば、一定の期間（許容期間）だけ新たな提案リスクマネジメントの提供を許し、他の期間（禁止期間）には許さないようにして、当該許容期間と禁止期間を厳密に周期的に繰り返すようにすれば、利用者の立場からみて、新たな提案リスクマネジメントが自身の個人用Ｗｅｂページに記述される可能性の高い時期を、ある程度、特定することができ、その時期に集中的に個人用Ｗｅｂページにアクセスすればよいから、新たな提案リスクマネジメントがいつ提案されるかわからない場合に比べ、より効率的な利用が可能となる。
【０２０４】
また、専門アドバイザ側からみても、前記許容期間に合わせて、提案リスクマネジメントの作成に必要な様々な業務のスケジュールを決めることができ、なおかつ、自身が作成した提案リスクマネジメントを利用者に閲覧してもらえる確率が高まるという利点がある。
【０２０５】
（Ｖ５）  利用者の保険事故の発生・保険金の支払状況に関して、その内容が保険会社または代理店のコンピュータに入力・計上され、そのコンピュータから当該入力・計上の結果が電送された時点で、前記利用者用Ｗｅｂページ（例えば、ＰＰ１１）や専門アドバイザ用Ｗｅｂページ（例えば、ＰＰ１２）、または代理店のＷｅｂページなどに表示されている利用者情報に反映させる事故関連反映システム。
【０２０６】
これにより、ある利用者に関する保険事故の発生などを、当該利用者に提案リスクマネジメントを提案しようとする全リスクマネジャーに周知させることができる。保険事故の発生や保険金の支払いは、利用者を取り巻く環境に劇的な変化を与え、前記全体像を大きく変貌させる可能性があるため、提案リスクマネジメントを提供する上でも重要な情報となる。
【０２０７】
（Ｖ６）  個人用Ｗｅｂぺージ上に表示されている、保険関連以外の利用者情報の変動に対するメンテナンスは、利用者が修正専用Ｗｅｂページ（入力画面に入力した利用者情報を修正するページ）にアクセスし、同ページ上で行う修正制御システム。
【０２０８】
上記実施形態でも、利用者用Ｗｅｂページ（例えば、ＰＰ１１）の記述内容の変更を認めることによって、利用者自身による利用者情報の動的な変更（メンテナンス）は可能であるが、利用者用Ｗｅｂページ（例えば、ＰＰ１１）は入力および／または閲覧専用のＷｅｂページとし、いったん入力した記述内容の利用者による変更は修正専用Ｗｅｂページを介してしか行えない構成とすれば、前記ユーザ認証部２１などの機能を利用して、前記修正専用Ｗｅｂページへのアクセスを制御、管理することにより、ＥＣサイト１８側が、利用者用Ｗｅｂページの内容の管理や、利用者情報の管理を効率的に行うことができる。
【０２０９】
（Ｖ７）  前記個人用Ｗｅｂページ（例えば、ＰＰ１）に対して提案リスクマネジメントが記述され、その記述の内容を利用者（例えば、Ｕ１１）が閲覧すると、所定のキャラクタ（人物、動物、架空の者など）が利用者に文字または／および音声で語りかけるキャラクタシステム。
【０２１０】
楽しい動物などのキャラクタを介した説明により、親しみのあるＷｅｂページを提供でき、分かりやすく提案リスクマネジメントの内容を伝えることが可能になる。例えば、「利用者が抱えるリスクの説明」や「リスク別のベストな対処方法の提案・アドバイス」などの具体的な内容を、当該キャラクタが音声や文字表現などによって説明する構成となる。
【０２１１】
当該キャラクタの姿を示す画像の定義や、当該キャラクタが発する音声の定義、キャラクタが発する文字によるメッセージの微妙な表現の定義および当該キャラクタが当該画像、音声、文字表現などを利用して実行する説明の内容は、ＥＣサイト１８側で管理しておく。そして、実際にキャラクタの画像を利用者端末（１５など）の表示部に画面表示したり、スピーカから音声出力したりするのは、前記利用者用Ｗｅｂページにリンクされたプログラムなどの機能による。
【０２１２】
キャラクタの画像は二次元でも良いが、三次元の立体的なものが望ましい。
【０２１３】
また、キャラクタは単数でも良いし、複数でも良い、特に、１利用者あたりのキャラクタ数が複数である場合は、キャラクタ間の対話を通じて、利用者に対する説明や提案・アドバイスを効果的に行うことができる。
【０２１４】
さらに、選択候補となるキャラクタを複数用意し、個人用Ｗｅｂぺージ上で使用するキャラクタを利用者が選択できるようにしてもよい。その場合、１利用者が複数キャラクタを選択できるようにしてもよい。利用者がいったん行った選択の内容は、例えば、前記利用者管理テーブルＴＳにそのためのデータ項目（列名）を用意してユーザ管理の情報の１つとして記憶しておくことができるから、利用者が個人用Ｗｅｂページにアクセスするたびに、同じキャラクタに、利用者への対応を行わせることができる。
【０２１５】
なお、これらの変形例（Ｖ１）〜（Ｖ７）においても、上記実施形態と同様に、ある利用者（例えば、Ｕ１１）のための個人用Ｗｅｂページ（例えば、ＰＰ１）は、当該利用者が閲覧するためのＷｅｂページと、その利用者に対して提案リスクマネジメントを提案しようとする専門アドバイザ（例えば、Ｕ２１など）が閲覧するＷｅｂページとを同一としてもよく、別なものとしてもよい。また、一部のＷｅｂページだけが同一であってもよい。
【０２１６】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０２１７】
【発明の効果】
以上に説明したように、本発明によれば、マネジメント対象ユーザにとってもマネジメント提案ユーザにとっても効率的な通信システムを提供することができる。
【０２１８】
これにより、例えば、従来は実現困難であったトータル・リスク・コンサルティングを容易に実現することが可能となる。
【図面の簡単な説明】
【図１】実施形態に係るＥＣシステムの全体構成例を示す概略図である。
【図２】実施形態で使用するＥＣサイトの内部構成例を示す概略図である。
【図３】実施形態の動作説明図である。
【図４】実施形態の動作説明図である。
【図５】実施形態で使用する利用者管理テーブルの構成例を示す概略図である。
【図６】実施形態で使用する専門アドバイザ管理テーブルの構成例を示す概略図である。
【図７】実施形態の動作説明図である。
【符号の説明】
１０…ＥＣシステム、１１…Ｗｅｂサーバ、１２…データベースサーバ、１３、１４…提案端末、１５，１６…利用者端末、１７…ネットワーク、２０…通信部、２１…ユーザ認証部、２２…情報収集部、２３…ページ生成部、２４…ページ読み出し部、２５…情報集約部、２６…決済処理部、２７…データベース、ＰＰ１，ＰＰ２…個人用Ｗｅｂページ、ＰＡ１，ＰＡ２…アドバイザ用トップページ、ＴＡ…専門アドバイザ管理テーブル、ＴＳ…利用者管理テーブル。
【図１】
2004227019.tif 000003
【図２】
2004227019.tif 000004
【図３】
2004227019.tif 000005
【図４】
2004227019.tif 000006
【図５】
2004227019.tif 000007
【図６】
2004227019.tif 000008
【図７】
2004227019.tif 000009