JP4334933B2 - 保険約款交付のための情報処理方法及び装置 - Google Patents

Description

【０００１】
【発明が属する技術分野】
本発明は、保険約款交付に関する情報処理技術に関する。
【０００２】
【従来の技術】
例えば特開２００２−１３３０９８号公報には以下のような技術が開示されている。すなわち、保険契約等手続方法およびシステムにおいて、保険会社または代理店は、顧客からの保険契約申込み情報に基づいて、インターネット等の通信ネットワークを介して顧客端末へ契約情報を送信する。また、顧客端末へ送信される契約情報のうち、契約した保険内容にとって必要な約款および特約条項のみを送信する。また、保険会社または代理店（媒介人、仲介人を含む）は、顧客端末に送信した契約情報について、顧客の要求に応じて、顧客がインターネット等の通信ネットワークを介して閲覧できるようにする。
【０００３】
【発明が解決しようとする課題】
しかしながら、上で述べた従来技術では、例えば保険契約申込みの修正があった場合や、異動があった場合などの約款の交付方法については考慮されていない。すなわち、共通する保険契約内容を含み、顧客に交付すべき約款データに重複があったとしても、最新の保険契約について必要な約款データを全て送信するような構成となっている。そのため、例えば特約を１つだけ追加した場合などには、該当する部分についてだけの約款データを交付すれば十分であるにも拘わらず、保険契約全体に対応した約款データを送信する。また、特約を減らした場合など、対応する約款データを顧客が既に取得済みであり、その約款が不適用となることを通知する必要がある場合でも、それに対応した通知を行うための手段が存在していなかった。このように、保険会社や顧客にとって通信及び処理負荷の削減等につながりにくい構成となっている。
【０００４】
また、約款などのデータを顧客にインターネット等の通信ネットワークを介して送信するとしても、顧客によってはこうしてネットワークへの対応ができていない場合がある。そのため、顧客によっては郵送などの別途の方法によって約款等を送付することが必要となる。
【０００５】
従って本発明の目的は、顧客に対して適切な内容の約款交付を適切な方法で行うための情報処理技術を提供することである。
【０００６】
【課題を解決するための手段】
本発明の第１の態様に係る、保険約款交付のための情報処理方法は、顧客の保険契約に関連するデータと顧客の属性データとを受信し、記憶装置に格納する受信ステップと、受信ステップにおいて記憶装置に格納された保険契約に関連するデータに基づき顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する約款特定ステップと、受信ステップにおいて記憶装置に格納された顧客の属性データに基づき、約款特定ステップにおいて特定され且つ必要約款識別データ格納部に識別データが格納された約款の約款データを顧客が受信可能か否かを判断する受信可能性判断ステップと、受信可能性判断ステップにおいて受信可能であると判断された顧客に対して、約款特定ステップにおいて特定され且つ必要約款識別データ格納部に識別データが格納された約款の約款データを送信する送信ステップとを含む。これにより、ネットワーク対応が可能な顧客にはネットワークを介して約款データを送信することができ、保険会社は省力化を図ることができる。
【０００７】
また、本発明の第１の態様において、受信可能性判断ステップにおいて受信不可能であると判断された顧客に対して、約款特定ステップにおいて特定され且つ必要約款識別データ格納部に識別データが格納された約款の約款データを印刷処理する印刷処理ステップをさらに含むようにしてもよい。ネットワーク対応が不可能な顧客等には印刷処理ステップにおいて印刷された約款を送付するようにするものである。なお、この場合においても交付が必要な約款だけが印刷されるので、消費資源の減量を図ることができるようになる。
【０００８】
また、上で述べた約款特定ステップが、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する第１特定ステップと、受信ステップにおいて記憶装置に格納されたデータに含まれる顧客の識別データを用いて顧客データ格納部を検索することにより読み出された顧客のデータに基づき当該顧客に交付済みの約款を特定し、当該顧客に交付済みの約款の識別データを交付済約款識別データ格納部に格納する第２特定ステップと、第１特定ステップにおいて特定され且つ必要約款識別データ格納部に格納された約款の識別データと、第２特定ステップにおいて特定され且つ交付済約款識別データ格納部に格納された顧客に交付済みの約款の識別データとを用いて今回交付すべき約款を特定し、当該約款の識別データを交付約款識別データ格納部に格納する第３特定ステップとを含み、上で述べた送信ステップにおいて、第３特定ステップにおいて特定され且つ交付約款識別データ格納部に識別データが格納された今回交付すべき約款の約款データを顧客宛に送信ような構成とすることも可能である。このように顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、通信負荷を減らすことができるようになる。
【０００９】
本発明の第２の態様に係る、保険約款交付ための情報処理方法は、顧客の保険契約に関連するデータを受信し、記憶装置に格納する受信ステップと、受信ステップにおいて記憶装置に格納された保険契約に関連するデータに基づき顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する第１特定ステップと、受信ステップにおいて記憶装置に格納されたデータに含まれる顧客の識別データを用いて顧客データ格納部を検索することにより読み出された顧客のデータに基づき当該顧客に交付済みの約款を特定し、当該顧客に交付済みの約款の識別データを交付済約款識別データ格納部に格納する第２特定ステップと、第１特定ステップにおいて特定され且つ必要約款識別データ格納部に格納された約款の識別データと、第２特定ステップにおいて特定され且つ交付済約款識別データ格納部に格納された顧客に交付済みの約款の識別データとを用いて今回交付すべき約款を特定し、当該約款の識別データを交付約款識別データ格納部に格納する第３特定ステップと、第３特定ステップにおいて特定され且つ交付約款識別データ格納部に識別データが格納された今回交付すべき約款の約款データを顧客宛に送信する送信ステップとを含む。すなわち、顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、重複した約款データを送信しないようにする。これにより、約款データを電子ファイルで送信する際には通信負荷の軽減を図ることができる。また、保険会社や顧客が約款データを紙に印刷するような場合には消費資源の削減を図ることができる。
【００１０】
本発明の第１及び第２の態様において、第２特定ステップにおいて交付済約款識別データ格納部に格納された約款の識別データのうち、第１特定ステップにおいて必要約款識別データ格納部に格納された約款の識別データに含まれていない、不適用とされる約款の識別データを不適用約款識別データ格納部に格納する不適用約款特定ステップをさらに含むようにしてもよい。
【００１１】
さらに、上で述べた不適用約款特定ステップにおいて不適用約款識別データ格納部に格納された約款の識別データに対応する約款についての情報を含む約款適用取消情報を生成し、取消情報格納部に格納する取消情報生成ステップと、取消情報格納部に格納された約款適用取消情報を顧客宛に送信するステップとをさらに含むようにしてもよい。これにより、顧客は読むべき約款を正確に把握できるようになる。
【００１２】
また、本発明の第１及び第２の態様において、記憶装置に格納された保険契約に関連するデータは、顧客の保険契約申込データ又は保険契約計上データである場合もある。これにより、例えば代理店端末から保険契約申込又は保険契約計上を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、以前に保険契約申込を受けて交付した約款の約款データの一部又は全部を、再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【００１３】
また、本発明の第１及び第２の態様において、記憶装置に格納された保険契約に関連するデータは、顧客の保険異動データである場合もある。これにより、代理店端末から保険異動要求を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、既契約保険の契約の際に交付した約款の約款データの一部又は全部を再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【００１４】
さらに、本発明の第１及び第２の態様において、記憶装置に格納された保険契約に関連するデータに基づき生成された保険証券データを顧客宛に送信するステップをさらに含むようにしてもよい。顧客は保険証券のデータ及び保険証券に対応した約款データを取得することができる。
【００１５】
また、上で述べた本発明の第１及び第２の態様において、送信ステップにおいて交付が必要な約款の約款データ又は今回送付すべき約款の約款データをメールの添付ファイルとして顧客に対して送信する、又は顧客のダウンロード要求により今回送付すべき約款の約款データを送信するようにしてもよい。保険会社及び顧客のシステム環境や通信環境に合わせた形態での約款送信が可能となる。
【００１６】
さらに、本発明の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データが複数ある場合、１つの約款ファイルに合成し、約款ファイル記憶部に格納するステップと、約款ファイル記憶部に格納された約款ファイルのダウンロード用リンク情報を生成し、リンク情報格納部に格納するステップと、リンク情報格納部に格納されたダウンロード用リンク情報を顧客に対して通知するステップとをさらに含み、顧客がダウンロード用リンク情報を用いてダウンロードを指示した場合、上記送信ステップが実行されるようにしてもよい。顧客は、約款ダウンロード用ホームページから今回の契約又は異動に対応した約款データを一括でダウンロードすることが可能となる。これにより、約款交付の管理も簡単になる。
【００１７】
また、本発明の第１及び第２の態様において、送信ステップにおいて送信された約款データを顧客が受信したと判定された場合、記憶装置に格納されたデータに含まれる顧客の識別データを用いて顧客データ格納部を検索することにより読み出された顧客のデータに、約款データが交付済みであることを表す情報を追加し、顧客データ格納部に格納するステップをさらに含むようにしてもよい。これにより、顧客に対して既に交付された約款の約款データを特定することが可能となる。また一方で、約款データを送信してから又はダウンロードを要求するメールを送信してから所定の期間、交付済みであることを表す情報が顧客のデータに追加されなかった場合には、約款を紙に印刷して郵送するような構成とすることも可能になる。
【００１８】
さらに、本発明の第１及び第２の態様において、送信ステップにおいて約款データを顧客に送信した時、又は記憶装置に格納された保険契約に関連するデータに基づき保険契約が計上された時に基づいて特定される時点において、送信ステップにおいて送信された約款データを顧客が受信したと判定されない場合、当該約款データを印刷処理するステップをさらに含むようにしてもよい。何らかの理由で受信されなかった約款を別途顧客に送付するためである。
【００１９】
本発明に係る情報処理方法をコンピュータに実行させるためのプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介して頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００２０】
【発明の実施の形態】
［実施の形態１］
本発明の第１の実施の形態に係るシステム構成図を図１に示す。例えばパーソナル・コンピュータであるユーザ端末１３は、図示しないがメーラ機能及びウェブ（Ｗｅｂ）ブラウザ機能を備えており、無線又は有線によりメールの送受信を行うこと及びインターネットに接続してホームページを閲覧することが可能となっている。
【００２１】
例えばインターネットであるネットワーク１１には、１又は複数のユーザ端末１３の他、保険契約の計上処理等を行う１又は複数の契約計上サーバ１５５、例えばメーラ機能及び保険契約申込機能を備えたパーソナル・コンピュータである１又は複数の代理店端末１７が接続されている。
【００２２】
契約計上サーバ１５５には、顧客に対する約款交付状況に関連するデータが格納されている約款交付管理データベース（ＤＢ）１５５１及び保険証券の印刷を行う保険証券印刷機１５５３が接続されている。また、契約計上サーバ１５５のハードディスク・ドライブ（ＨＤＤ）１５５５には、顧客に交付するための約款データが例えば約款ファイルとして格納されている。保険契約の分類方法や特約の種類によって、対応する約款ファイルは何種類であってもよい。ＨＤＤ１５５５は、その他データの記憶装置としても機能する。
【００２３】
また、保険会社１５には、図示しないＷｅｂサーバがあり、約款ファイルのダウンロード用ホームページの管理を行う。また、図示しないメール・サーバにより、顧客に対してメール送信等を実施する。その他、契約計上サーバ１５５又は図示しないその他のサーバによって管理される保険契約ＤＢ、顧客管理ＤＢ及び代理店ＤＢ等、保険業務処理を行うためのシステムが設置されている。
【００２４】
また、契約計上サーバ１５５には、図示しないが制御部と通信部とが設けられている。制御部の処理の詳細については、後の処理フローの説明において述べるが、例えば、約款交付管理ＤＢ１５５１の管理や、ＨＤＤ１５５５に格納されている約款ファイルやその他データの管理等の処理を行う。通信部は、約款ファイルの顧客などへの伝送等の処理を行うための通信インタフェイスである。
【００２５】
なお、契約計上サーバ１５５及び保険証券印刷機１５５３は必ずしも保険会社１５の内部に設置されている必要はなく、同様の機能が実現できればアウトソーシング等により外部に設置されるような構成であってもよい。
【００２６】
また、ネットワーク１１を経由する通信には、図示していないがドメイン・ネーム・サーバ（ＤＮＳ）、メール・サーバ、ファイア・ウォール等の、インターネット接続やメール送受信に必要な機器及び機能を使用するものとする。
【００２７】
約款交付管理ＤＢ１５５１のテーブル構成及び格納されるデータの一例を図２及び図３に示す。約款交付管理ＤＢ１５５１には、例えば図２に示す約款テーブルと図３に示す交付管理テーブルとが含まれている。
【００２８】
図２に示す約款テーブルの例には、約款番号の列２００、名称の列２０２及びファイル保存場所の列２０４が含まれている。本テーブルでは、例えば自動車保険の約款に関するデータが登録されており、約款番号の列２００の値がキーとなって約款の名称及び物理的な約款ファイルの保存（格納）場所を特定できるような構成となっている。なお、約款の種類や名称については各保険会社の保険商品の特徴や分類方法などによって変わる場合もあり、物理的な約款ファイルの格納場所についてもシステム環境に合わせて変わる場合もある。
【００２９】
図３に示す交付管理テーブルの例には、申込書番号の列３００、顧客番号の列３０２、顧客メール・アドレスの列３０４、契約申込内容の列３０６、約款交付済フラグの列３０８、交付約款の列３１０、登録日時の列３１２及び計上フラグの列３１４が含まれている。レコードは保険契約申込みのデータを代理店端末１７から受信する毎に生成され、キーとなる申込書番号の列３００によって特定される。顧客番号の列３０２には顧客を特定するＩＤが登録され、図示しない顧客管理ＤＢ等によって顧客の氏名や住所などの情報が導出できるような構成になっている。顧客メール・アドレスの列３０４には約款データ送信の際の宛先となる電子メール・アドレスが登録される。本実施の形態では、一連の処理において参照するテーブルの数を少なくするために非正規化しているが、正規化して交付管理テーブル（図３）には顧客メール・アドレスの列３０４を含めず、メール送信する際には顧客番号の列３０２の値から導出するような構成であってもよい。
【００３０】
契約申込内容の列３０６には、当該保険契約申込の内容に対応する、交付が必要な約款を表すデータが契約計上サーバ１５５の制御部によって登録される。制御部は、保険契約申し込みの内容に基づき対応する約款を特定し、契約申込内容の列３０６に登録する。本テーブルの例では約款テーブル（図２）の約款番号の列２００の値が１つ又は複数登録される。具体的には、例えばある顧客の契約申込内容が、総合自動車保険であり運転者家族限定特約を付加したものであった場合、約款テーブル（図２）の参照によって約款番号の列の値"００"及び"０１"が特定される。この交付が必要な約款番号の特定は、特約等の契約内容の設定と必要な約款を対応付けしておき保険契約申込の際に自動になされるような構成であってもよいし、契約内容から代理店が判断するような構成であってもよい。そして、特定された約款番号を合成したデータが登録される。ここでは"００"及び"０１"から合成された"０００１"が、契約申込内容の列３０６に登録される。従って、契約申込内容の列３００の値を使用した処理を行う際には、約款番号の桁数である例えば２桁づつに区切って処理を行うような構成となっている。
【００３１】
約款交付済フラグの列３０８には、レコード生成時には"０"が設定され、送信した約款データを顧客が受信したと判定された場合には"１"が設定される。契約計上サーバ１５５の制御部は、通信部を介して約款データを送信し、例えばメールの開封通知等により顧客が約款データを確認したというデータを取得した時点で、フラグを"１"とする。
【００３２】
交付約款の列３１０には、顧客に対して今回交付すべき（未だ交付済みでない）約款を表すデータが契約計上サーバ１５５の制御部によって登録される。なお、契約申込内容の列３０６と同様に、約款番号によってデータが構成される。レコード生成時には、顧客番号の列３０２の値が同じレコードを抽出することにより、交付約款の列３１０の値と約款交付済フラグの列３０８の値から既に交付済みの約款番号が特定される。そして契約申込内容の列３０６の値と既に交付済みの約款番号とから今回交付すべき（未だ交付済みでない）約款番号が特定され、合成したものが交付約款の列３１０に登録される。例えば、顧客番号の列３０２の値が"００００１１１１"で、契約申込内容の列３０６の値が"０００１０２１０"であるレコードが生成される。ここで、契約申込内容に対応する約款の番号は、"００"、"０１"、"０２"及び"１０"である。そして、顧客番号の列３０２の値が"００００１１１１"である既存レコードが抽出される。
【００３３】
例えば抽出されたレコードが１つあり、約款交付済フラグの列３０８の値が"１"で且つ交付約款の列３１０の値が"０００１"であった場合には、"００"及び"０１"の約款番号が示す約款データは当該顧客に対して既に交付済みであることが分かる。そこで、契約申込内容に対応する約款の番号である"００"、"０１"、"０２"及び"１０"から、既に交付済みの約款の番号である"００"及び"０１"を除いた"０２"及び"１０"が今回交付すべき約款の番号となる。"０２"及び"１０"を合成して"０２１０"という値が交付約款の列３１０に登録される。このように、今回交付すべき約款は、交付が必要な約款の一部若しくは全部により構成されることになる。
【００３４】
登録日時の列３１２には、レコードが生成された日時が登録される。また、計上フラグの列３１４には、レコード生成時には"０"が設定され、当該レコードのデータで計上（顧客が申込み内容を確定し、その確定内容に基づいた保険契約データが保険会社に送られ、受け付けられること）が行われる場合には"１"が設定される。
【００３５】
次に、図４乃至図８を用いて図１に示したシステムの動作を説明する。
【００３６】
代理店端末１７は、例えば、図示しない保険契約申込用システムの画面において、代理店による顧客に関するデータ（顧客データ又は顧客属性データとも呼ぶ）と保険契約の申込書データとの入力を受け付ける（ステップＳ１）。続いて代理店端末１７は、代理店の指示に応じて、入力を受け付けた顧客データと受け付けた申込書データとを契約計上サーバ１５５に対して送信する（ステップＳ３）。契約計上サーバ１５５の制御部（以下、契約計上サーバ１５５における処理の説明において、単に契約計上サーバ１５５と表示する場合は、制御部による処理を示す。または契約計上サーバ１５５（制御部）と表示する場合もある。）は、代理店端末１７から顧客データと申込書データとを受信し、図示しない保険契約申込ＤＢ等に格納する（ステップＳ５）。また、契約計上サーバ１５５（制御部）は、通信部を介して代理店端末１７から受信した申込書データを用いて交付管理テーブル（図３）用のレコードを生成し、約款交付管理ＤＢ１５５１内の交付管理テーブル（図３）に格納する（ステップＳ７）。
【００３７】
この段階では、レコードには申込書番号の列３００、顧客番号の列３０２、顧客メール・アドレスの列３０４、契約申込内容の列３０６及び登録日時の列３１２の値が記録され、約款交付済フラグの列３０８及び計上フラグの列３１４には初期値として"０"が記録される。交付約款の列３１０の値については、以下に述べる処理によって特定されるため、ＮＵＬＬ値が記録されるか又は何も記録されない。なお、顧客がメール・アドレスを有しない等、約款データの受信が不可能な場合は、顧客メール・アドレスの列３０４には何も記録されない。例えば、図３の交付管理テーブルにおいて顧客番号の列３０４のうち、００００７７７７の顧客については、約款データの受信が不可能な顧客であるため、顧客メール・アドレスの列３０４には空白のまま何も記されていない。
【００３８】
一方で、代理店端末１７は、保険契約の申込み処理を終了するかどうかを判定する（ステップＳ９）。例えば、図示しない保険契約申込用システムの画面で、終了ボタンが押されたかどうかを判定する。まだ終了しないと判定された場合には、ステップＳ１からの申込書データ受付処理を繰り返す。終了と判定された場合には、代理店による申込書番号の入力を受け付ける（ステップＳ１１）。ここでは、複数の保険契約申込みが存在した場合に、代理店が顧客に対して約款を送信するために特定した、交付管理テーブル（図３）のレコードにおける申込書番号の入力を受け付ける。というのも、顧客はどんな内容で加入するかを検討するために、暫時、複数タイプの保険契約の申込みがなされる場合があるためである。そして代理店端末１７は、入力された申込書番号を契約計上サーバ１５５に対して送信する（ステップＳ１３）。
【００３９】
契約計上サーバ１５５（制御部）は、代理店端末１７から申込書番号を受信し、一旦記憶装置に格納する（ステップＳ１５）。処理は端子Ａを介して図５の処理に移行する。
【００４０】
契約計上サーバ１５５（制御部）は、代理店端末１７から受信した申込書番号を用いて約款交付管理ＤＢ１５５１を検索し、交付管理テーブル（図３）のレコードを特定する（ステップＳ１７）。そして、特定されたレコードの契約申込内容の列３０６の値に対応する約款ファイルを特定する（ステップＳ１９）。例えば約款番号を記憶装置（ＨＤＤ１５５５など）に格納する。また、契約計上サーバ１５５（制御部）は、特定されたレコードの顧客番号の列３０２の値と同じ顧客番号を含み且つ約款交付済みフラグが"１"であるレコードを検索して抽出する（ステップＳ２１）。抽出した結果、レコードが存在するかどうか判定し（ステップＳ２３）、存在しないと判定された場合には、特定されたレコードの交付約款の列３１０に契約申込内容の列３０６の値をそのまま登録する（ステップＳ２７）。すなわち、当該顧客に対しては以前に約款を送付していないため、今回の契約申込内容に対応し且つ交付が必要な約款を全て交付するように設定する。
【００４１】
一方で、ステップＳ２３においてレコードが存在すると判定された場合には、契約計上サーバ１５５（制御部）は、ステップＳ１７の処理で特定されたレコードの契約申込内容の列３０６の値と、ステップＳ２１の処理で抽出されたレコードの交付約款の列３１０の値とから、未だ交付済みでない約款を特定する（ステップＳ２５）。例えば約款番号を記憶装置に格納する。この場合には、ステップＳ１７の処理で特定されたレコードの交付約款の列３１０に、ステップＳ２５で特定された未だ交付済みでない約款を表すデータ（約款番号）を登録する（ステップＳ２６）。なお、ステップＳ２１の処理で抽出されたレコードが複数存在する場合には、契約計上サーバ１５５（制御部）は、交付約款の列３１０の値をレコード数分合わせて交付済みの約款を特定する。例えば２つのレコードが抽出され、交付約款の列３１０の値が"０００１"及び"０２０３"であった場合には、交付済みの約款の約款番号は"００"、"０１"、"０２"及び"０３"である。また、交付が必要な約款が全て交付済みであった場合には、ステップＳ２７の処理において、ステップＳ１７の処理で特定されたレコードの交付約款の列３１０に、所定の「交付約款なし」を表す値を登録するか、又は何も登録しないようにする。
【００４２】
契約計上サーバ１５５（制御部）は、交付が必要な約款（ここでは既に交付済みの約款が無い場合）又は今回交付すべき約款が特定できたら、顧客が約款データの受信が可能かどうかを判定する（ステップＳ２７）。そして、約款データを受信不可能であると判定された場合（ステップＳ２７：Ｎｏルート）、契約計上サーバ１５５（制御部）は図示しないプリンタ等を用いて約款データの印刷処理を行う（ステップＳ２８）。そして印刷された約款は、別途、保険会社などから顧客に対して送付される。一方、顧客が約款データを受信可能であると判定された場合（ステップＳ２７：Ｙｅｓルート）、契約計上サーバ１５５（制御部）は約款データの顧客への送信方法を判定する（ステップＳ３０）。この判定は、予め定められたいずれかの方法に固定してもよいし、顧客の希望に合わせてもよい。メールの添付ファイルで送信すると判定された場合には、端子Ｂを介して図６の処理に移行する。また、メールの添付ファイルでは送信しないと判定された場合には、顧客にファイルをダウンロードしてもらうため、申込書番号毎のダウンロード用ページのＵＲＬ（Uniform Resource Locator）を生成してＵＲＬ記憶部に格納し（ステップＳ３１）、端子Ｃを介して図７の処理に移行する。契約計上サーバ１５５の制御部は、通信部を介していずれかの方法で送信する。
【００４３】
次に、端子Ｂを介して遷移した処理について図６を用いて説明する。
【００４４】
契約計上サーバ１５５（制御部）は通信部を介して、今回顧客に交付すべき約款データを、例えば１つのファイルに合成した上で、メールの添付ファイルとして顧客（例えばユーザ端末１３を使用する）に送信する（ステップＳ３３）。但し、１つのファイルに合成せずに送る場合もある。ユーザ端末１３は、顧客の指示に応じて、契約計上サーバ１５５からのメールを受信して表示装置に表示する（ステップＳ３５）。そしてユーザ端末１３は、メールを受信したことを通知するために、開封確認メールを契約計上サーバ１５５に送信する（ステップＳ３７）。ここで、開封確認メール送信の仕組みとしては、メーラの機能を使用するような構成であってもよいし、例えば開封確認ボタンを顧客が押すことによってメールが送信されるような構成であってもよい。そしてユーザ端末１３は、自動的に又は顧客の操作に従い、図示しないユーザ端末１３のＨＤＤ等の記憶装置に、受信したメールの添付ファイル（約款データ）を格納する（ステップＳ３９）。
【００４５】
一方で契約計上サーバ１５５（制御部）は、通信部を介してユーザ端末１３からの開封確認メールを受信（ステップＳ４１）した場合には、対応する交付管理テーブル（図３）のレコードを特定し、約款交付済フラグの列３０８の値を"１"に設定する（ステップＳ４３）。
【００４６】
次に、端子Ｃを介して遷移した処理について図７を用いて説明する。
【００４７】
契約計上サーバ１５５（制御部）は、ステップＳ３１の処理で生成した約款ダウンロード用ページのＵＲＬを、通信部を介して顧客（例えばユーザ端末１３を使用する）に送信する（ステップＳ４５）。ユーザ端末１３は、顧客の指示に応じて、契約計上サーバ１５５（制御部）からのメールを受信して表示装置に表示する（ステップＳ４７）。表示されたＵＲＬを、顧客がクリックしたりＷｅｂブラウザのアドレス欄に入力した場合には、ユーザ端末１３は顧客からの操作を受け付け、約款ダウンロード用ページ・データの要求を契約計上サーバ１５５に送信する（ステップＳ４９）。なお、ユーザ端末１３が送信するデータは、Ｗｅｂページを表示するためのものであり、実際には図示しないＷｅｂサーバに対して送信する。そしてＷｅｂサーバは、契約計上サーバ１５５のＨＤＤ１５５５や契約計上サーバ１５５（制御部）が管理する約款交付管理ＤＢ１５５１にアクセスして処理を行う。ここでは説明を分かりやすくするために、サーバ側の処理は契約計上サーバ１５５が行うものとしている。
【００４８】
契約計上サーバ１５５（制御部）は、ユーザ端末１３から約款ダウンロード用ページ・データの要求を通信部を介して受信する（ステップＳ５１）。なお、約款ダウンロード用ページのＵＲＬは、ステップＳ３１において申込書番号毎に生成されているため、逆にＵＲＬから申込書番号を特定することができる。契約計上サーバ１５５（制御部）は、受信したＵＲＬから申込書番号を特定する（ステップＳ５３）。さらに、特定した申込書番号を用いて約款交付管理ＤＢ１５５１を検索し、交付管理テーブル（図３）のレコードを特定する。特定されたレコードの交付約款の列３１０の値から、今回交付すべき約款を特定する（ステップＳ５５）。特定された約款番号は記憶装置に格納される。例えば、特定されたレコードの交付約款の列３１０の値が"０００１"であった場合には、今回交付すべき約款の番号は、"００"及び"０１"である。
【００４９】
契約計上サーバ１５５（制御部）は、約款ダウンロード用ページ・データを生成し、ユーザ端末１３に通信部を介して送信する（ステップＳ５７）。ユーザ端末１３は、契約計上サーバ１５５から通信部を介して送信された約款ダウンロード用ページ・データを受信し、表示装置に表示する（ステップＳ５９）。ユーザ端末１３は、顧客による約款ダウンロードの操作を受け付けた場合には、約款ダウンロード要求を契約計上サーバ１５５に対して送信する（ステップＳ６１）。契約計上サーバ１５５（制御部）は通信部を介して、ユーザ端末１３から約款ダウンロード要求を受信する（ステップＳ６３）。そして契約計上サーバ１５５（制御部）は、今回交付すべき約款データを１つのファイルに合成してユーザ端末１３に対して送信する（ステップＳ６５）。約款データを１つのファイルに合成することにより、顧客の約款のダウンロード処理及び保険会社のダウンロード（交付）管理が容易になる。契約計上サーバ１５５（制御部）は、ユーザ端末１３への送信が完了した時点で、顧客に対して約款を送信したことを示す記録として、交付管理テーブル（図３）の対応するレコードの約款交付済フラグを"１"に設定する（ステップＳ６７）。
【００５０】
一方、ユーザ端末１３は、通信部を介して契約計上サーバ１５５（制御部）から送信された約款ファイルを受信する（ステップＳ６９）。そしてユーザ端末１３は、自動的に又は顧客の操作に従い、図示しないユーザ端末１３のＨＤＤ等の記憶装置に、受信した約款ファイルを格納する（ステップＳ７１）。
【００５１】
以上では、申込書が作成される際に、都度、交付が必要な約款や今回交付すべき約款データを特定した交付するようにしていたが、約款データの交付は計上時点にまとめて行うようにしてもよい。この場合、契約計上サーバ１５５（制御部）は顧客の新規の保険契約を計上した時点で、約款交付管理ＤＢ１５５１を検索し、交付管理テーブル（図３）のレコードを特定する。そして、交付管理テーブル（図３）において、計上フラグを"１"に設定するのと併せて、当該申込書番号の契約内容の列３０６の値に対応する約款ファイルを特定する。その上で、約款データの受信が可能な顧客については、当該保険契約に対応して顧客に交付することが必要な約款データとして特定された約款ファイルを送信する。この場合、図５のステップＳ２１からステップＳ２６までの処理は省略することになる。また、約款データの受信が不可能な顧客については、契約計上サーバ１５５（制御部）は保険証券印刷機１５５３に対して交付が必要な約款の印刷処理の指示を行う。
【００５２】
次に、図８における処理について説明する。契約計上サーバ１５５（制御部）は、約款交付管理ＤＢ１５５１の交付管理テーブル（図３）を検索して、計上フラグの列３１４の値が"１"であるレコードを抽出する（ステップＳ７３）。すなわち、計上指示が代理店端末１７から受信された申込書番号に対応して計上フラグの列３１４に"１"を登録しておくものとする。そして、ステップＳ７３において抽出されたレコードから、さらに特定の顧客のレコードを顧客番号を用いて抽出する（ステップＳ７５）。そして顧客番号によって抽出されたレコードの約款交付済フラグの列３０８の値を判定する（ステップＳ７７）。全て"１"であるかどうか判定し（ステップＳ７９）、全て"１"であると判定された場合には、交付すべき約款は顧客に交付済みであるため、当該保険契約の証券を例えばハガキ形式で保険証券印刷機１５５３により印刷する（ステップＳ８１）。または、図示しない証券印刷システムに印刷指示を出力するような構成でもよい。また、ステップＳ７９において、全て"１"ではない（少なくとも１つは"１"ではない）と判定された場合には、約款交付済フラグの列３０８の値が"０"であるレコードの交付約款の列３１０の値から、約款（約款番号）を特定する（ステップＳ８３）。特定された約款番号は記憶装置に格納される。
【００５３】
交付約款の列３１０の値の特性から、顧客単位で重複する値（約款番号）は存在しないため、顧客に交付すべき約款のうち、未だ顧客に交付済みでない約款（約款番号）が、以上の処理により特定できる。例えば、同一顧客（交付管理テーブル（図３）の顧客番号００００１１１１）について、第１のレコード（申込書番号０００００００１）において契約申込内容の列３０６の値が"０００１"、約款交付済みフラグの列３０８の値が"１"、交付約款の列３１０の値が"０００１"、計上フラグの列３１４の値が"０"であり、第２のレコード（申込書番号０００００００２）において契約申込内容の列３０６の値が"０００１０２１０"、約款交付済みフラグの列３０８の値が"１"、交付約款の列３１０の値が"０２１０"、計上フラグの列３１４の値が"１"であり、第３のレコード（申込書番号０００００００３）において契約申込内容の列３０６の値が"０００１０５１０"、約款交付済みフラグの列３０８の値が"０"、交付約款の列３１０の値が"０５"、計上フラグの列３１４の値が"０"であったとする。つまり、顧客が３つの契約タイプの内、申込書番号０００００００２を最終的に選択して契約したとする。計上フラグの列３１４の値から、計上の対象となるのは第２のレコードだけであり、顧客に交付が必要な約款（約款番号）は、契約申込内容の列３０６の値の"０００１０２１０"に示される"００"、"０１"、"０２"及び"１０"である。ここで、第１のレコード及び第２のレコードの、約款交付済みフラグの列３０８の値及び交付約款の列３１０の値から、約款が"００"及び"０１"と、"０２"及び"１０"との２回に分けて交付され、顧客は必要とする"００"、"０１"、"０２"及び"１０"で示される約款を全て受信したことが分かる。
【００５４】
これを図８の処理フローに当てはめてみると、ステップＳ７３において第２のレコードだけが抽出される。ステップＳ７５は、ステップＳ７３で抽出したレコードを同一顧客についてさらに抽出するステップがあり、ここでは既に同一顧客のレコードが抽出されているためそのまま通過する。そして、ステップＳ７７において約款交付済フラグが"１"と判定される。レコードは１つなのでステップＳ７９において「Ｙｅｓ」と判定され、ステップＳ８１の処理へ進む。約款の追加送信は必要ないケースであったため、正しく処理が行われることが分かる。
【００５５】
一方、第３のレコードの計上フラグの列３１４の値が"１"であり、他の全ての条件は上で述べたケースと同じ場合であったとする。すなわち、第２のレコード及び第３のレコードの計上フラグの列３１４の値が"１"であるものとする。その場合、計上フラグの列３１４の値から、計上の対象となるのは第２のレコードと第３のレコードとなる。顧客に交付が必要な約款（約款番号）は、契約申込内容の列３０６の値からの重複を除くと"００"、"０１"、"０２"、"０５"及び"１０"である。ここで、第２のレコード及び第３のレコードの、約款交付済みフラグの列３０８の値及び交付約款の列３１０の値から、約款が"００"及び"０１"と、"０２"及び"１０"との２回に分けて交付され、顧客は必要とする"００"、"０１"、"０２"、"０５"及び"１０"で示される約款のうち、"００"、"０１"、"０２"、及び"１０"を受信したことが分かる。すなわち、"０５"で示される約款を顧客に追加送信する必要がある。こうした判定処理が契約計上サーバ１５５（制御部）によってなされる。
【００５６】
これを図８の処理フローに当てはめてみると、ステップＳ７３において、契約計上サーバ１５５（制御部）により第２のレコード及び第３のレコードが抽出される。ステップＳ７５は、ステップＳ７３で抽出したレコードを同一顧客についてさらに抽出するステップであり、ここでは既に同一顧客のレコードが抽出されているためそのまま通過する。そして、ステップＳ７７において第２のレコードの約款交付済フラグは"１"、第３のレコードの約款交付済フラグは"０"と判定される。第３のレコードが"０"のため、ステップＳ７９において「Ｎｏ」と判定され、契約計上サーバ１５５（制御部）による処理はステップＳ８３の処理へ進む。そして、ステップＳ８３の処理において第３のレコードの交付約款の列３１０の値から約款番号"０５"が特定される。"０５"で示される約款の顧客への追加送信が必要なケースであったため、正しく処理が行われることが分かる。
【００５７】
このように、同一顧客が１つの契約タイプを選択した場合だけではなく、例えば同一顧客が２台以上の車両についてそれぞれ異なる契約タイプの自動車保険を申し込む場合であっても本実施の形態では対処可能である。
【００５８】
なお、ここでは同一顧客が例えば複数の車両にそれぞれ自動車保険契約を申し込む場合、複数の自動車保険契約間で約款を共有して利用するような仕組みとしている。しかし本実施の形態に代えて、同一契約者であっても、例えば個々の自動車保険契約毎に交付が必要な約款を全て交付するようにしても良い。すなわち、約款交付の管理を個々の保険対象毎（あるいは保険契約毎）に行い、各保険対象毎に約款交付状況を管理しても良い。そして、同一の保険契約のために複数の申し込み（複数タイプの契約申し込み）がなされた場合、その都度重複した約款を交付するのではなく、先の申し込みで交付済みの約款を改めて交付せずに後の申し込みに対応して未交付の約款（今回交付が必要な約款）のみを交付する。
【００５９】
以上説明したようにステップＳ８３では、何らかの原因により、顧客が約款を受信したという確認がとれなかったケースを契約計上サーバ１５５（制御部）が抽出している。そして、このようなケースでは約款を紙（冊子）で顧客に対して送付するため、契約計上サーバ１５５（制御部）はステップＳ８３で特定された約款及び当該契約の証券を保険証券印刷機１５５３を使用して印刷する（ステップＳ８５）か、または印刷処理するように指示をする。あるいは、既存の約款冊子が印刷された証券と共に封筒に封入される。
【００６０】
なお、図８の処理フローは、契約計上サーバ１５５におけるシステム時間を制御部が取得することによって、所定の周期（例えば１日）で実施することを前提としたフローとなっている。しかし、あるレコードの計上フラグが"１"にセットされた場合や他の任意のタイミングを制御部が検知して、その時点で実施するようにしても良い。また、あるレコードに着目して、当該レコードの計上タイミングから所定時間経過後に実行するといった構成を採用する場合もある。
【００６１】
なお、ステップＳ７９において「Ｎｏ」と判定された場合、ステップＳ８３の処理に代えて、顧客が最終的に選択して計上された契約申込内容に対応し且つ交付が必要な約款（約款番号）を特定して、そのすべてを印刷するようにしてもよい。つまり、計上された契約申込内容に対応し、交付が必要な約款（約款番号）として、契約申込内容の列３０６の値から約款番号（例えば第３レコードが計上された場合には、"００"、"０１"、"０５"及び"１０"）を特定して、それらを印刷処理するようにしてもよい。
【００６２】
契約計上サーバ１５５（制御部）は、ステップＳ７３において抽出されたレコードの全顧客について、以上の処理を行ったかどうか判定し（ステップＳ８７）、全顧客について処理が終了していないと判定された場合には、ステップＳ７５からの処理を繰り返す。また、全顧客について処理が終了したと判定された場合には、交付管理テーブルの計上済みのレコードをクリアする（ステップＳ８９）。
【００６３】
次に、交付済みの約款データの内、実際の契約にいたらなかったために適用されないものを、顧客に通知する処理について説明する。
【００６４】
例えば、交付管理テーブル（図３）の顧客番号００００２２２２の顧客について見ると、申込書番号０００００００４については、契約申込内容の列３０６の値が"０００１０２０３"であり、交付約款の列３１０の値も"０００１０２０３"であり、約款交付済みフラグの列３０８の値が"１"であることから"００"、"０１"、"０２"、及び"０３"の約款データが交付済みであることが契約計上サーバ１５５（制御部）によって確認される。また、申込書番号０００００００５については、契約申込内容の列３０６の値が"０００１０２"であり、申込書番号０００００００４においてすでにこれに対応する約款データが交付済みであることから、交付約款の列３１０は空白となっている。そして、申込書番号０００００００５については、計上フラグの列３１４の値が"１"であり、申込書番号０００００００４の計上フラグの列３１４の値が"０"となっている。つまり、顧客番号００００２２の顧客は、申込書番号０００００００４と、申込書番号００００００５の契約内容で検討した結果、最終的に申込書番号０００００００５の内容で契約締結し、その契約データが計上されたことになる。
【００６５】
すなわち、申込書番号０００００００４の交付約款の列３１０の値のうち、"０３"に対応する約款がすでに交付されたにもかかわらず、最終的には計上された契約に照らすと不必要な約款であったことになる。そこで、契約計上サーバ１５５（制御部）は、申込書番号０００００００５について計上フラグを"１"に更新した時点で、図示しないが交付管理テーブル（図３）の別途設けられた削除約款の列に"０３"の値を設定する。さらに、契約計上サーバ１５５（制御部）は、"０３"に対応する約款が実際に契約された保険契約においては適用されないことを知らせるために、図９に例として示した内容の通知を通信部を介して行う。図９には、契約加入へのお礼の言葉、送信内容の説明文、適用とならない約款の名称、約款番号、さらに約款の内容が記載されている。契約計上サーバ１５５（制御部）は、図９に示した送信内容を所定のデータ記録領域（例えばＨＤＤ１５５５）から抽出して生成する。
【００６６】
また、交付管理テーブル（図３）の顧客番号００００４４４４の顧客について見ると、申込書番号０００００００７については、契約申込内容の列３０６の値が"０００１０３"であり、交付約款の列３１０の値が"０００１０３"となっており、約款交付済みフラグの列３０８の値が"１"であることから"００"、"０１"及び"０３"の約款データが交付済みであることが契約計上サーバ１５５（制御部）によって確認される。なお、計上フラッグの列の３１４の値が"１"となっており、この内容で契約が締結されたことが確認できる。また、申込書番号０００００００８については、契約申込内容の列３０６の値が"０００１０４１４"であり、交付約款の列３１０の値が"０４１４"となっており、約款交付済みフラグの列３０８の値が"１"であることから"０４"及び"１４"の約款データがすでに交付済みであることが契約計上サーバ１５５（制御部）によって確認される。
【００６７】
そして、申込書番号０００００００８については、計上フラグの列３１４の値は"０"となっている。すなわち顧客番号００００４４４４の顧客は、申込書番号００００００００７と、申込書番号０００００００８の内容で検討した結果、最終的に申込書番号００００００００７の内容で契約締結し、その契約データが計上されたことになる。つまり、申込書番号０００００００８の交付約款の列３１０の値、"０４１４"に対応する約款はすでに交付されたにもかかわらず、最終的に計上された契約に照らすと不必要な約款であったことになる。そこで、契約計上サーバ１５５（制御部）は、申込書番号０００００００７について計上フラグを"１"に更新した時点で、図示しないが交付管理テーブル（図３）の申込書番号０００００００８の別途設けられた削除約款の列の値を"０４１４"と設定する。さらに、契約計上サーバ１５５（制御部）は、"０４１４"に対応する約款が実際に契約された保険契約においては適用されないことを知らせるための通知を通信部を介して行う。通知内容は、図９に示したのと同様の方法を採ることができる。
【００６８】
なお、適用されない約款を通知するための方法は、以上で示したような方法に代えて、あらためて交付が必要な約款をすべて送信し直してもよい。その場合、送信内容の説明文としては、例えば「この度ご契約いただきました保険契約については、下記記載の約款の内容が適用されることになります。過日お送りした約款データは削除いただき、本データを保存いただきますようお願いいたします。」といった内容になる。契約計上サーバ１５５（制御部）は、交付が必要な約款をすべて抽出し、併せてそれに対応する説明文を付加して送信内容を生成し、通信部を介して顧客に送信する。
【００６９】
このように約款データを受信可能な顧客に対して交付が必要な約款をネットワークを介した送信によって交付することで、保険会社は郵送によって約款を交付することよる通信費や負荷を削減できる。また、顧客は適用される約款のみを、都度、入手することが可能となり、保険加入の参考資料として利用することができる。さらに、今回交付すべき約款を特定することで、複数の保険契約タイプについて検討したうえで契約内容を決定したり、保険契約申込書の修正を行うなどの原因によって、約款を交付済みの顧客に対してさらに約款を交付するような場合に、顧客に交付済みの約款データを特定することにより、重複した約款データの送信を避けることができる。また、不必要となった約款について、対象外という通知を行うことで、顧客の契約内容に関する誤解を防止することができる。こうして、保険会社や顧客は通信及び処理負荷の削減を図ることができる。また、顧客が何らかの理由により約款を受信しなかった場合又は受信できなかった場合にも、冊子に印刷して郵送するなどの対応処理が可能となる。
【００７０】
［実施の形態２］
本発明の第２の実施の形態に係るシステム構成図を図１０に示す。例えばパーソナル・コンピュータであるユーザ端末２３は、図示しないがメーラ機能及びウェブ（Ｗｅｂ）ブラウザ機能を備えており、無線又は有線によりメールの送受信を行うこと及びインターネットに接続してホームページを閲覧することが可能となっている。
【００７１】
例えばインターネットであるネットワーク２１には、１又は複数のユーザ端末２３の他、保険契約の計上処理等を行う１又は複数の契約計上サーバ２５５、例えばメーラ機能及び保険契約申込機能を備えたパーソナル・コンピュータである１又は複数の代理店端末２７が接続されている。
【００７２】
契約計上サーバ２５５には、顧客の保険契約状況に関連するデータが格納されている契約管理ＤＢ２５５１が接続されている。また、契約計上サーバ２５５のＨＤＤ２５５５には、顧客に交付するための約款データが例えば約款ファイルとして格納されている。保険契約の分類方法や特約の種類によって、対応する約款ファイルは何種類であってもよい。 また、契約計上サーバ２５５には、図示しないが制御部と通信部とが設けられている。制御部の処理の詳細については、後の処理フローの説明において述べるが、例えば、約款交付管理ＤＢ２５５１の管理や、ＨＤＤ２５５５に格納されている約款ファイルやその他データの管理等の処理を行う。通信部は、約款ファイルの顧客などへの伝送等の処理を行うための通信インタフェイスである。
【００７３】
また、保険会社２５には、図示しないＷｅｂサーバがあり、約款ファイルのダウンロード用ホームページの管理を行う。また、図示しないメール・サーバにより、顧客に対してメール送信等を実施する。その他、契約計上サーバ２５５又は図示しないその他のサーバによって管理される保険契約ＤＢ、顧客管理ＤＢ及び代理店ＤＢ等、保険業務処理を行うためのシステムが設置されている。また、契約計上サーバ２５５には図示しない保険証券又は異動承認書印刷機が接続されている。
【００７４】
なお、契約計上サーバ２５５やその他の図示しないサーバは必ずしも保険会社２５の内部に設置されている必要はなく、同様の機能が実現できればアウトソーシング等により外部に設置されるような構成であってもよい。
【００７５】
また、ネットワーク２１を経由する通信には、図示していないがドメイン・ネーム・サーバ（ＤＮＳ）、メール・サーバ、ファイア・ウォール等の、インターネット接続やメール送受信に必要な機器及び機能を使用するものとする。
【００７６】
契約管理ＤＢ２５５１には、例えば約款テーブル（図２）と以下に説明する契約管理テーブルとが含まれている。契約管理テーブルの構成及び格納されるデータの一例を図１１に示す。
【００７７】
図１１に示す契約管理テーブルの例では、証券番号の列１００、証券ファイル保存場所の列１０２、顧客番号の列１０４、顧客メール・アドレスの列１０６、契約内容の列１０８、交付約款の列１１０、約款交付済フラグの列１１２、顧客交付済約款の列１１４、契約計上日／異動承認日の列１１６及び削除フラグの列１１８が含まれている。レコードは顧客の保険契約毎に生成され、キーとなる証券番号の列１００によって特定される。なお、図１１の例では証券番号の列１００の値だけを見ると重複しているレコードが存在するが、削除フラグの列１１８の値によって、有効なレコードと無効なレコードとの判別を可能にし、有効なレコードは重複しないような構成となっている。
【００７８】
証券ファイル保存場所の列１０２には、例えば図示しない保険証券発行システムによって生成された保険証券ファイルの物理的な保存（格納）場所が登録される。本実施の形態では保険証券を電子ファイルで取扱うため、保険証券を印刷したり顧客に送信したりする時に、この証券ファイル保存場所の列１０２の値から保険証券ファイルを特定する。
【００７９】
顧客番号の列１０４には顧客を特定するＩＤが登録され、図示しない顧客管理ＤＢ等によって顧客の氏名や住所などの情報が導出できるような構成になっている。顧客メール・アドレスの列１０６には保険証券データ及び約款データ送信の際の宛先となる電子メール・アドレスが登録される。本実施の形態では、一連の処理において参照するテーブルの数を少なくするために非正規化しているが、正規化して契約管理テーブル（図１１）には顧客メール・アドレスの列１０６を含めず、メール送信する際には顧客番号の列１０４の値から導出するような構成であってもよい。
【００８０】
契約内容の列１０８には、当該保険契約の内容に対応した約款を表すデータが登録される。本テーブルの例では約款テーブル（図２）の約款番号の列２００の値が１つ又は複数登録される。具体的には、例えばある顧客の契約内容が、総合自動車保険であり運転者家族限定特約を付加したものであった場合、約款テーブル（図２）の参照によって約款番号の列の値"００"及び"０１"が特定される。この交付が必要な約款番号の特定は、特約等の契約内容の設定と必要な約款を対応付けしておき保険契約の際に自動になされるような構成であってもよいし、契約内容から代理店が判断するような構成であってもよい。そして、特定された約款番号を合成したデータが登録される。ここでは"００"及び"０１"から合成された"０００１"が、契約内容の列１０８に登録される。従って、契約内容の列１０８の値を使用した処理を行う際には、約款番号の桁数である例えば２桁づつに区切って処理を行うような構成となっている。
【００８１】
交付約款の列１１０には、顧客に対して今回交付すべき（未だ交付済みでない）約款又は当該契約時に交付した約款を表すデータが登録される。なお、契約内容の列１０８と同様に、約款番号によってデータが構成される。このように、今回交付すべき約款は、交付が必要な約款の一部もしくは全部を含むことになる。また、約款交付済フラグの列１１２には、レコード生成時には"０"が設定され、送信した約款データを顧客が受信したと判定された場合には"１"が設定される。
【００８２】
顧客交付済約款の列１１４には、当該顧客に対してこれまでに交付済みである約款の番号が全て登録される。例えば、これまでの契約に対応するレコードの顧客交付済約款の列１１４の値が"０００１"であり、保険の異動が発生し、今回の保険契約の異動に対応するレコードの交付約款の列１１０の値が"０５"であった場合には、今回の契約に対応するレコードの生成時には、顧客交付済約款の列１１４の値は"０００１"が登録されているが、約款交付済フラグの列１１２の値が"１"に設定される際に顧客交付済約款の列１１４の値は"０００１０５"に更新される。すなわち、顧客は既に約款番号"００"及び"０１"に対応する約款の交付を受けており、今回は追加で約款番号"０５"に対応する約款の交付を受けたので、これまでに当該顧客が交付を受けた約款は"００"、"０１"及び"０５"であるということを表している。そのため、交付約款の列１１０の値を登録する際には、当該顧客の前回の契約に対応するレコードの顧客交付済約款の列１１４の値と、今回の契約に対応するレコードの契約内容の列１０８の値とから今回交付すべき約款番号を特定して登録する。
【００８３】
契約計上日／異動承認日の列１１６には、契約を計上した日付又は保険の異動が確定した日付が登録される。また、削除フラグの列１１８には、レコード生成時には"０"が設定（又は空白と）され、保険の異動処理などにより、これまでの契約に対応するレコードを無効にする場合には"１"が設定される。なお、不要になったレコードを削除するような構成であってもよい。
【００８４】
次に、図１２乃至図１４を用いて図１０に示したシステムの動作を説明する。
【００８５】
契約計上サーバ２５５の制御部は、代理店（例えば代理店端末２７）から顧客の保険契約に関するデータを通信部を介して受信し、一旦記憶装置に格納する（ステップＳ９１）。契約計上サーバ２５５の制御部（以下、契約計上サーバ２５５における処理の説明において、単に契約計上サーバ２５５と表示したときは、制御部による処理を意味する。また契約計上サーバ２５５（制御部）と表示する場合もある。）は、契約内容から、交付が必要な約款ファイルを特定する（ステップＳ９３）。この交付すべき約款ファイルの特定については、特約等の契約内容の設定と必要な約款を対応付けしておき保険契約申込の際に自動になされるような構成であってもよいし、契約内容から代理店が判断して契約計上サーバ２５５に送信するデータに含めておくような構成であってもよい。
【００８６】
また、契約計上サーバ２５５（制御部）が代理店端末２７から通信部を介して受信したデータには、例えば新規の保険契約か既契約保険の異動かを判定することができる情報が含まれており、契約計上サーバ２５５（制御部）は、当該保険契約は保険の異動であるかどうかを判定する（ステップＳ９５）。新規の保険契約か既契約保険の異動かの判定は、例えば既存契約の証券番号データが含まれていなければ新規の保険契約であると判断し、既存契約の証券番号データが含まれていれば異動であると判断することができる。あるいは、新規の保険契約と既契約保険の異動のぞれぞれに固有のコード番号を保持させてもよい。契約計上サーバ２５５（制御部）は、これらデータの有無やデータの内容に基づき、新規の保険契約か既契約保険の異動かの判定を行う。
【００８７】
異動であると判定した場合、契約計上サーバ２５５（制御部）は、受信したデータに含まれる契約番号をキーとして契約管理ＤＢ２５５１の契約管理テーブル（図１１）を検索し、既契約保険のレコードを特定する（ステップＳ９７）。特定されたレコードの顧客交付済約款の列１１４の値から、顧客に交付済みの約款ファイルを特定する（ステップＳ９９）。契約計上サーバ２５５（制御部）は、ステップＳ９３において特定された契約内容に対応した約款ファイルの情報と、ステップＳ９９において特定された顧客に交付済みの約款ファイルの情報とから、今回顧客に交付すべき約款ファイルを特定する（ステップＳ１０１）。そして、ステップＳ９７において特定されたレコードの削除フラグの列１１８の値を"１"に更新する（ステップＳ１０３）。また、ステップＳ９９において特定された顧客に交付済みの約款ファイルの情報を顧客交付済約款の列１１４に含むレコードを生成し、契約管理ＤＢ２５５１の契約管理テーブル（図１１）に新規に格納する（ステップＳ１０５）。
【００８８】
例えば、保険の特約の追加（対応する約款の番号は"０２"）が発生し、今回の契約内容に対応する交付が必要な約款（約款番号）が"００"、"０１"及び"０２"であるとする。既契約内容に対応して交付済みの約款（約款番号）が"００"及び"０１"である場合、今回顧客に対して送信すべき約款（約款番号）は"０２"となる。ここで、契約計上サーバ２５５（制御部）は、顧客に交付済みの約款（約款番号）が"００"及び"０１"であることを示す新しいレコードをＤＢに格納しておき、今回交付すべき"０２"で示される約款を顧客が受信したことが確認された時に、顧客に交付済みの約款（約款番号）の情報に"０２"が含まれるようにレコードを更新する。
【００８９】
一方、ステップＳ９５において異動ではないと判定した場合、契約計上サーバ２５５（制御部）は、契約管理ＤＢ２５５１の契約管理テーブル（図１１）にレコードを新たに生成して格納する（ステップＳ１０７）。証券番号の列１００、顧客番号の列１０４、顧客メール・アドレスの列１０６、契約内容の列１０８及び契約計上日／異動承認日の列１１６にはステップＳ９１において受信したデータに基づいた値が記録され、約款交付済フラグの列１１２及び削除フラグの列１１８には初期値として"０"が記録される。また、証券ファイル保存場所の列１０２には保険証券データの物理的な格納場所が記録される。なお、当該顧客に対して交付済みの約款はないため、顧客交付済約款の列１１４にはＮＵＬＬ値が記録されるか又は何も記録されない。そして、今回交付すべき約款は契約内容に対応した全ての約款（すなわち交付が必要な約款）であるため、交付約款の列１１０には契約内容の列１０８と同じ値が記録される。
【００９０】
今回交付すべき約款（又はステップＳ１０７経由の場合には交付が必要な約款）が特定できたら、契約計上サーバ２５５（制御部）は、顧客が約款データの受信が可能かどうかを判定する（ステップＳ１０８）。そして、約款データを受信不可能であると判定した場合（ステップＳ１０８：Ｎｏルート）、契約計上サーバ２５５（制御部）は図示しないプリンタ等に約款データの印刷指示を発することにより、約款の印刷処理を行う（ステップＳ１０９）。顧客が約款データを受信可能であると判定した場合（ステップＳ１０８：Ｙｅｓルート）、契約計上サーバ２５５（制御部）は約款データ及び保険証券データの顧客への送信方法を判定する（ステップＳ１１０）。送信方法は予め固定的に設定してもよいし、顧客毎に異なる方法を採用してもよい。メールの添付ファイルで送信すると判定された場合には、端子Ｄを介して図１３の処理に移行する。また、メールの添付ファイルでは送信しないと判定された場合には、顧客にファイルをダウンロードしてもらうため、保険証券番号毎のダウンロード用ページのＵＲＬを生成してＵＲＬ記憶部に格納し（ステップＳ１１１）、端子Ｅを介して図１４の処理に移行する。
【００９１】
次に、端子Ｄを介して遷移した処理について図１３を用いて説明する。
【００９２】
契約計上サーバ２５５（制御部）は通信部を介して、今回顧客に交付すべき約款データ（複数の約款データが存在する場合にはそれらを合成した約款ファイルとしての約款データである場合もある）及び保険証券又は異動承認書をメールの添付ファイルとして顧客（例えばユーザ端末２３を使用する）に送信する（ステップＳ１１３）。ユーザ端末２３は、顧客の指示に応じて、契約計上サーバ２５５からのメールを受信して表示装置に表示する（ステップＳ１１５）。そしてユーザ端末２３は、メールを受信したことを通知するために、開封確認メールを契約計上サーバ２５５に送信する（ステップＳ１１７）。ここで、開封確認メール送信の仕組みとしては、メーラの機能を使用するような構成であってもよいし、例えば開封確認ボタンを顧客が押すことによってメールが送信されるような構成であってもよい。そしてユーザ端末２３は、自動的に又は顧客の操作に従い、図示しないユーザ端末２３のＨＤＤ等の記憶装置に、受信したメールの添付ファイル（保険証券又は異動承認書データ及び約款データ）を格納する（ステップＳ１１９）。
【００９３】
一方で契約計上サーバ２５５（制御部）は、ユーザ端末２３からの開封確認メールを通信部を介して受信（ステップＳ１２１）した場合には、対応する契約管理テーブル（図１１）のレコードを特定し、約款交付済フラグの列１１２の値を"１"に設定し、顧客交付済約款の列１１４の値を更新する（ステップＳ１２３）。顧客交付済約款の列１１４の値については、レコード生成時に既契約のデータ（交付済みの約款番号）が登録されていたのに対し、今回交付した約款番号を合せたものを更新データとする。例えば、交付約款の列１１０の値が"０５"で、顧客交付済約款の列１１４の値が"０００１"であった場合、ステップＳ１２３において顧客交付済約款の列１１４の値を"０００１０５"に更新する。また例えば、交付約款の列１１０の値が"０００１"で、顧客交付済約款の列１１４の値がＮＵＬＬ値であったか又は何も登録されていなかった場合、ステップＳ１２３において顧客交付済約款の列１１４の値を"０００１"に更新する。
【００９４】
次に、端子Ｅを介して遷移した処理について図１４を用いて説明する。
【００９５】
契約計上サーバ２５５（制御部）は、ステップＳ１１１の処理で生成した保険証券又は異動承認書及び約款ダウンロード用ページのＵＲＬを通信部を介して顧客（例えばユーザ端末２３を使用する）に送信する（ステップＳ１２５）。ユーザ端末２３は、顧客の指示に応じて、契約計上サーバ２５５からのメールを受信して表示装置に表示する（ステップＳ１２７）。表示されたＵＲＬを、顧客がクリックしたりＷｅｂブラウザのアドレス欄に入力した場合には、ユーザ端末２３は顧客からの操作を受け付け、約款ダウンロード用ページ・データの要求を契約計上サーバ２５５に送信する（ステップＳ１２９）。なお、ユーザ端末２３が送信するデータは、Ｗｅｂページを表示するためのものであり、実際には図示しないＷｅｂサーバに対して送信する。そしてＷｅｂサーバは、契約計上サーバ２５５のＨＤＤ２５５５や契約計上サーバ２５５が管理する契約管理ＤＢ２５５１にアクセスして処理を行う。ここでは説明を分かりやすくするために、サーバ側の処理は契約計上サーバ２５５（制御部）が行うものとしている。
【００９６】
契約計上サーバ２５５（制御部）は、ユーザ端末２３から保険証券又は異動承認書及び約款ダウンロード用ページ・データの要求を通信部を介して受信する（ステップＳ１３１）。契約計上サーバ２５５（制御部）は、保険証券又は異動承認書データを当該顧客以外に参照させないために、例えばパスワードによる認証処理を行う（ステップＳ１３３）。パスワードは例えば代理店等から顧客に提供されるものとする。また、生年月日を仮パスワードとしてもよい。また、契約計上サーバ２５５の通信部を介して行われる契約計上サーバ２５５（制御部）とユーザ端末２３との通信には、例えばＳＳＬ（Secure Socket Layer）等の暗号化通信を利用するような構成であってもよい。
【００９７】
また、保険証券又は異動承認書及び約款ダウンロード用ページのＵＲＬは、ステップＳ１１１において保険証券番号毎に生成されているため、逆にＵＲＬから保険証券番号を特定することができる。契約計上サーバ２５５（制御部）は、受信したＵＲＬから保険証券番号を特定する（ステップＳ１３５）。さらに、特定した保険証券番号を用いて契約管理ＤＢ２５５１を検索し、契約管理テーブル（図１１）のレコードを特定する。特定されたレコードの交付約款の列１１０の値から、今回交付すべき約款を特定する（ステップＳ１３７）。例えば、特定されたレコードの交付約款の列１１０の値が"０００１"であった場合には、今回交付すべき約款の番号は、"００"及び"０１"である。
【００９８】
契約計上サーバ２５５（制御部）は、保険証券又は異動承認書及び約款ダウンロード用ページ・データを生成し、通信部を介してユーザ端末２３に送信する（ステップＳ１３９）。保険証券又は異動承認書及び約款ダウンロード用ページには、契約管理テーブル（図１１）の証券ファイル保存場所の列１０２の値を用いて生成されたリンク情報が含まれる。ユーザ端末２３は、契約計上サーバ２５５から保険証券又は異動承認書及び約款ダウンロード用ページ・データを受信し、表示装置に表示する（ステップＳ１４１）。
【００９９】
ユーザ端末２３は、顧客による保険証券又は異動承認書及び約款ダウンロードの操作を受け付けた場合には、保険証券又は異動承認書及び約款ダウンロード要求を契約計上サーバ２５５に対して送信する（ステップＳ１４３）。契約計上サーバ２５５（制御部）は、ユーザ端末２３から保険証券又は異動承認書及び約款ダウンロード要求を通信部を介して受信する（ステップＳ１４５）。そして受信したデータに基づいて契約計上サーバ２５５（制御部）は、今回交付すべき約款データを１つのファイルに合成して保険証券又は異動承認書データと共にユーザ端末２３に対して通信部を介して送信する（ステップＳ１４７）。
【０１００】
なお、保険証券又は異動承認書データと約款データとは別ファイルとして送信するが、対応関係にあるため、一回の送信処理で両方のファイルを顧客に送信できることが望ましい。例えば図示しないが保険証券又は異動承認書及び約款ダウンロード用ページに含まれるダウンロード・ボタンが顧客によって押された場合には、保険証券又は異動承認書ファイルと今回交付すべき約款ファイルと、の両方を顧客に送信するような構成であってもよい。契約計上サーバ２５５（制御部）は、ユーザ端末２３への送信が完了した時点で、顧客に対して約款を送信したことを示す記録として、対応する契約管理テーブル（図１１）のレコードを特定し、約款交付済フラグの列１１２の値を"１"に設定し、顧客交付済約款の列１１４の値を更新する（ステップＳ１４９）。
【０１０１】
一方、ユーザ端末２３は、契約計上サーバ２５５から保険証券又は異動承認書及び約款ファイルを受信する（ステップＳ１５１）。そしてユーザ端末２３は、自動的に又は顧客の操作に従い、図示しないユーザ端末２３のＨＤＤ等の記憶装置に、受信した保険証券又は異動承認書及び約款ファイルを格納する（ステップＳ１５３）。
【０１０２】
ところで、何らかの原因により、顧客が約款を受信したという確認がとれなかった場合、約款等を紙（冊子）で顧客に対して送付するための処理を実施する必要がある。そのため、契約計上サーバ２５５（制御部）は、ステップＳ１０１で特定された約款及び当該異動に関する異動承認書を異動承認書印刷機などを使用して印刷するための指示を印刷機に対して発する。または、保険会社によって、既存の約款冊子が印刷された異動承認書と共に封筒に封入される。
【０１０３】
なお、契約計上サーバ２５５（制御部）は、約款データが交付済みであるかどうかの確認を、保険契約又は異動の計上時点若しくはその他の任意の時点において行うことができる。例えば、今回交付すべき約款データを送信した時や保険契約又は異動を計上した時などに基づいて特定される、所定の時点において確認することができる。例えば、約款データを送信した時もしくは計上した時から所定時間（例えば２４時間）が経過した時点や、約款データを送信した時もしくは計上した時の含まれる日から２日後の午後３時（翌々日の午後３時）になった時点など、あらかじめ設定された所定の時点において確認する。
【０１０４】
約款データを送信した時もしくは計上した時から所定時間（例えば２４時間）が経過した時点に確認する場合は、図示しないが契約管理テーブル（図１１）において、約款データを送信した時もしくは計上した時刻データが契約計上サーバ２５５（制御部）によって記録され、かつそれ以降の経過時間が同様に記録される。また、翌々日の午後３時などといった所定の時点において確認する場合には、図示しないが契約管理テーブル（図１１）において、約款データを送信した時もしくは計上した時刻データが契約計上サーバ２５５（制御部）によって記録され、それと共に予め設定されたルールに基づいて、確認すべき時点のデータが記録される。そして、契約計上サーバ２５５（制御部）は、契約計上サーバ２５５におけるシステム時間を取得して、経過時間を測定し、所定時間が経過した時点で上で述べたような必要な処理を実施する。
【０１０５】
また、既契約に対応して交付済みであった約款データの内、異動に伴って適用されなくなったものについては、契約計上サーバ２５５（制御部）は、通信部を介して顧客にその旨の通知をする。例えば、契約内容の列１０８の値が"０００１０２０３"で、交付約款の列１１０および顧客交付済約款の列１１４の値も"０００１０２０３"であり、そして約款交付済フラグの列１１２の値が"１"であった場合（契約管理テーブル（図１１）の証券番号ｘｘｘｚｚｚ００１２のケース）に、後日、異動によって、「運転者家族限定特約（約款番号「０１」）」が削除されることとなったとする。この場合、契約計上サーバ２５５（制御部）は、"０１"に対応する約款が適用されなくなることを知らせるために、図１５に例として示した内容の通知を行う。図１５には、契約加入に対するお礼の言葉、送信内容の説明文、対象の保険契約、適用とならない当該約款の内容等が記載されている。
【０１０６】
このようにすると、保険の異動などの原因によって、約款を交付済みの顧客に対してさらに約款を交付するような場合に、顧客に交付済みの約款データを特定することにより、重複した約款データの送信を避けることができる。そのため、保険会社や顧客は通信及び処理負荷の削減を図ることができる。また、異動によって適用されなくなった約款について、顧客に通知することで、顧客の契約内容に関する誤解を防止することができる。さらに、約款データとともに保険証券又は異動承認書データも送信することにより、保険会社及び顧客の、保険証券及び約款の管理が楽になる。また、顧客が何らかの理由により保険証券及び約款を受信しなかった場合又は受信できなかった場合にも、紙及び冊子を郵送するなどの対応処理が可能となる。
【０１０７】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１及び図１０に示したシステム構成は一例であって他の構成であっても図１及び図１０に示した実施パターンを実現することができればよい。例えばＤＢ構成についても一例であって同様のデータを格納するためであれば、別の構成を採用するようにしてもよい。また、必要に応じて項目を追加又は削除するようにしてもよい。例えば約款テーブル（図２）については、同じ特約でも約款の改定等があれば新しい約款番号を付与して登録しておくような構成であってもよい。また、各サーバは１台による構成に限らず、複数台による構成であってもよい。例えば契約計上サーバ１５５や契約計上サーバ２５５が複数台で構成されていてもよい。また、保険証券ファイルを顧客に送信する際には、ファイルを暗号化して送信するような構成であってもよい。
【０１０８】
また、本実施の形態をまとめると以下のようになる。
【０１０９】
本実施の形態の第１の態様に係る、保険約款交付のための情報処理方法は、顧客の保険契約に関連するデータと顧客の属性データとを受信した場合、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定する約款特定ステップと、受信した顧客の属性データに基づき、約款特定ステップにおいて特定された約款の約款データを顧客が受信可能か否かを判断する受信可能性判断ステップと、受信可能性判断ステップにおいて受信可能であると判断された顧客に対して、約款特定ステップにおいて特定された約款の約款データを顧客宛に送信する送信ステップとを含む。これにより、ネットワーク対応が可能な顧客にはネットワークを介して約款データを送信することができ、保険会社は省力化を図ることができる。
【０１１０】
また、本実施の形態の第１の態様において、受信可能性判断ステップにおいて受信不可能であると判断された顧客に対して、約款特定ステップにおいて特定された約款の約款データを印刷処理する印刷処理ステップをさらに含むような構成であってもよい。ネットワーク対応が不可能な顧客等には印刷処理ステップにおいて印刷された約款を送付するようにするものである。なお、この場合においても交付が必要な約款だけが印刷されるので、消費資源の減量を図ることができるようになる。
【０１１１】
また、上で述べた約款特定ステップが、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定する第１特定ステップと、予め記憶装置に格納された顧客のデータに基づき当該顧客に交付済みの約款を特定する第２特定ステップと、第１特定ステップにおいて特定された約款と、第２特定ステップにおいて特定された約款とを用いて今回交付すべき約款を特定する第３特定ステップとを含み、上で述べた送信ステップにおいて、第３特定ステップにおいて特定された今回交付すべき約款の約款データを顧客宛に送信するような構成とすることも可能である。このように顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、通信負荷を減らすことができるようになる。
【０１１２】
本実施の形態の第２の態様に係る、保険約款交付ための情報処理方法は、顧客の保険契約に関連するデータを受信した場合、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定する第１特定ステップと、予め記憶装置に格納された顧客のデータに基づき当該顧客に交付済みの約款を特定する第２特定ステップと、第１特定ステップにおいて特定された約款と、第２特定ステップにおいて特定された約款とを用いて今回交付すべき約款を特定する第３特定ステップと、第３特定ステップにおいて特定された今回交付すべき約款の約款データを顧客宛に送信する送信ステップとを含む。すなわち、顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、重複した約款データを送信しないようにする。これにより、約款データを電子ファイルで送信する際には通信負荷の軽減を図ることができる。また、保険会社や顧客が約款データを紙に印刷するような場合には消費資源の削減を図ることができる。
【０１１３】
本実施の形態の第１及び第２の態様において、第２特定ステップにおいて特定された約款のうち、第１特定ステップにおいて特定された約款に含まれていない、不適用とされる約款を特定する不適用約款特定ステップをさらに含むような構成であってもよい。
【０１１４】
さらに、上で述べた不適用約款特定ステップにおいて特定された不適用とされる約款についての情報を含む約款適用取消情報を生成する取消情報生成ステップと、生成された約款適用取消情報を顧客宛に送信するステップとをさらに含むような構成であってもよい。これにより、顧客は読むべき約款を正確に把握できるようになる。
【０１１５】
また、本実施の形態の第１及び第２の態様において、受信した保険契約に関連するデータは、顧客の保険契約申込データ又は保険契約計上データである場合もある。これにより、例えば代理店端末から保険契約申込又は保険契約計上を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、以前に保険契約申込を受けて交付した約款の約款データの一部又は全部を、再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【０１１６】
また、本実施の形態の第１及び第２の態様において、受信した保険契約に関連するデータは、顧客の保険異動データである場合もある。これにより、代理店端末から保険異動要求を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、既契約保険の契約の際に交付した約款の約款データの一部又は全部を再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【０１１７】
さらに、本実施の形態の第１及び第２の態様において、保険証券データを顧客宛に送信するステップをさらに含むような構成であってもよい。顧客は保険証券のデータ及び保険証券に対応した約款データを取得することができる。
【０１１８】
また、上で述べた本実施の形態の第１及び第２の態様における送信ステップにおいて、交付が必要な約款の約款データ又は今回送付すべき約款の約款データをメールの添付ファイルとして顧客に対して送信する、又は顧客のダウンロード要求により今回送付すべき約款の約款データを送信するような構成であってもよい。保険会社及び顧客のシステム環境や通信環境に合わせた形態での約款送信が可能となる。
【０１１９】
さらに、本実施の形態の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データが複数ある場合、１つの約款ファイルに合成し、約款ファイル記憶部に格納するステップと、合成された約款ファイルのダウンロード用リンク情報を生成するステップと、生成されたダウンロード用リンク情報を顧客に対して通知するステップとをさらに含み、顧客がダウンロード用リンク情報を用いてダウンロードを指示した場合、送信ステップが実行されるような構成であってもよい。顧客は、約款ダウンロード用ホームページから今回の契約又は異動に対応した約款データを一括でダウンロードすることが可能となる。これにより、約款交付の管理も簡単になる。
【０１２０】
また、本実施の形態の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データを顧客が受信したと判定された場合、顧客のデータに、交付が必要な約款の約款データ又は今回送付すべき約款の約款データが交付済みであることを表す情報を追加するステップをさらに含むような構成であってもよい。これにより、顧客に対して既に交付された約款の約款データを特定することが可能となる。また一方で、約款データを送信してから又はダウンロードを要求するメールを送信してから所定の期間、交付済みであることを表す情報が顧客のデータに追加されなかった場合には、約款を紙に印刷して郵送するような構成とすることも可能になる。
【０１２１】
さらに、本実施の形態の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データを顧客に送信した時、又は保険契約に関連するデータに基づいて保険契約が計上された時、に基づいて特定される時点において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データを顧客が受信したと判定されない場合、当該約款データを印刷処理するステップをさらに含むような構成であってもよい。これにより、何らかの理由で受信されなかった約款を別途顧客に送付するためである。
【０１２２】
【発明の効果】
以上述べたように、本発明によれば、顧客に対して適切な内容の約款交付を適切な方法にて行うための情報処理技術を提供することができた。
【図面の簡単な説明】
【図１】本発明の一実施の形態におけるシステム概要図である。
【図２】約款テーブルの構成及び格納されるデータの一例を示す図である。
【図３】交付管理テーブルの構成及び格納されるデータの一例を示す図である。
【図４】本発明の一実施の形態における処理フロー（その１）を示す図である。
【図５】本発明の一実施の形態における処理フロー（その２）を示す図である。
【図６】本発明の一実施の形態における処理フロー（その３）を示す図である。
【図７】本発明の一実施の形態における処理フロー（その４）を示す図である。
【図８】本発明の一実施の形態における処理フロー（その５）を示す図である。
【図９】約款の不適用通知の一例を示す図である。
【図１０】本発明の実施の形態２におけるシステム概要図である。
【図１１】契約管理テーブルの構成及び格納されるデータの一例を示す図である。
【図１２】本発明の実施の形態２における処理フロー（その１）を示す図である。
【図１３】本発明の実施の形態２における処理フロー（その２）を示す図である。
【図１４】本発明の実施の形態２における処理フロー（その３）を示す図である。
【図１５】約款の不適用通知の一例を示す図である。
【符号の説明】
１１ ネットワーク １３ ユーザ端末
１５ 保険会社 １７ 代理店端末
１５５ 契約計上サーバ １５５１ 約款交付管理ＤＢ
１５５３ 保険証券印刷機 １５５５ 契約計上サーバＨＤＤ
２１ ネットワーク ２３ ユーザ端末
２５ 保険会社 ２７ 代理店端末
２５５ 契約計上サーバ ２５５１ 契約管理ＤＢ
２５５５ 契約計上サーバＨＤＤ

Claims (6)

1. 顧客の保険契約に関連するデータと顧客の属性データとを受信し、記憶装置に格納する受信ステップと、
   前記受信ステップにおいて前記記憶装置に格納された前記保険契約に関連するデータに基づき前記顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する約款特定ステップと、
   前記受信ステップにおいて前記記憶装置に格納された前記顧客の属性データに基づき、前記約款特定ステップにおいて特定され且つ前記必要約款識別データ格納部に識別データが格納された約款の約款データを前記顧客が受信可能か否かを判断する受信可能性判断ステップと、
   前記受信可能性判断ステップにおいて受信可能であると判断された前記顧客に対して、前記約款特定ステップにおいて特定され且つ前記必要約款識別データ格納部に識別データが格納された前記約款の約款データを送信する送信ステップと、
   を含み、
   前記約款特定ステップが、
   受信した前記保険契約に関連するデータに基づき前記顧客に交付が必要な約款を特定し、当該約款の識別データを前記必要約款識別データ格納部に格納する第１特定ステップと、
   前記受信ステップにおいて前記記憶装置に格納されたデータに含まれる前記顧客の識別データを用いて顧客データ格納部を検索することにより読み出された前記顧客のデータに基づき当該顧客に交付済みの約款を特定し、当該顧客に交付済みの約款の識別データを交付済約款識別データ格納部に格納する第２特定ステップと、
   前記第１特定ステップにおいて特定され且つ前記必要約款識別データ格納部に格納された前記約款の識別データと、前記第２特定ステップにおいて特定され且つ前記交付済約款識別データ格納部に格納された前記顧客に交付済みの約款の識別データとを用いて今回交付すべき約款を特定し、当該約款の識別データを交付約款識別データ格納部に格納する第３特定ステップと、
   を含み、
   前記送信ステップにおいて、前記第３特定ステップにおいて特定され且つ前記交付約款識別データ格納部に識別データが格納された前記今回交付すべき約款の約款データを前記顧客宛に送信することを特徴とする
   コンピュータにより実行される、保険約款交付のための情報処理方法。
2. 顧客の保険契約に関連するデータを受信し、記憶装置に格納する受信ステップと、
   前記受信ステップにおいて前記記憶装置に格納された前記保険契約に関連するデータに基づき前記顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する第１特定ステップと、
   前記受信ステップにおいて前記記憶装置に格納されたデータに含まれる前記顧客の識別データを用いて顧客データ格納部を検索することにより読み出された前記顧客のデータに基づき当該顧客に交付済みの約款を特定し、当該顧客に交付済みの約款の識別データを交付済約款識別データ格納部に格納する第２特定ステップと、
   前記第１特定ステップにおいて特定され且つ前記必要約款識別データ格納部に格納された前記約款の識別データと、前記第２特定ステップにおいて特定され且つ前記交付済約款識別データ格納部に格納された前記顧客に交付済みの約款の識別データとを用いて今回交付すべき約款を特定し、当該約款の識別データを交付約款識別データ格納部に格納する第３特定ステップと、
   前記第３特定ステップにおいて特定され且つ前記交付約款識別データ格納部に識別データが格納された前記今回交付すべき約款の約款データを前記顧客宛に送信する送信ステップと、
   を含み、コンピュータにより実行される保険約款交付のための情報処理方法。
3. 前記第２特定ステップにおいて前記交付済約款識別データ格納部に格納された約款の識別データのうち、前記第１特定ステップにおいて前記必要約款識別データ格納部に格納された約款の識別データに含まれていない、不適用とされる約款の識別データを不適用約款識別データ格納部に格納する不適用約款特定ステップ
   をさらに含む請求項１又は２記載の保険約款交付のための情報処理方法。
4. 前記不適用約款特定ステップにおいて前記不適用約款識別データ格納部に格納された前記約款の識別データに対応する約款についての情報を含む約款適用取消情報を生成し、取消情報格納部に格納する取消情報生成ステップと、
   前記取消情報格納部に格納された前記約款適用取消情報を前記顧客宛に送信するステップと、
   をさらに含む請求項３記載の保険約款交付のための情報処理方法。
5. 前記送信ステップにおいて送信された前記約款データを前記顧客が受信したと判定された場合、前記記憶装置に格納されたデータに含まれる前記顧客の識別データを用いて前記顧客データ格納部を検索することにより読み出された前記顧客のデータに、前記約款データが交付済みであることを表す情報を追加し、前記顧客データ格納部に格納するステップ
   をさらに含む請求項１又は２記載の保険約款交付のための情報処理方法。
6. 請求項１乃至５のいずれか１つに記載の保険約款交付のための情報処理方法をコンピュータに実行させるためのプログラム。

Images