JP2004127264A

JP2004127264A - Information processing method and device for issuing insurance clause

Info

Publication number: JP2004127264A
Application number: JP2003206050A
Authority: JP
Inventors: Satoshi Yano; 矢野　聡
Original assignee: Tokio Marine and Fire Insurance Co Ltd
Current assignee: Tokio Marine and Fire Insurance Co Ltd
Priority date: 2002-08-05
Filing date: 2003-08-05
Publication date: 2004-04-22
Anticipated expiration: 2023-08-05
Also published as: JP4334933B2

Abstract

<P>PROBLEM TO BE SOLVED: To issue clauses with appropriate contents to a customer in a proper manner. <P>SOLUTION: This information processing method includes a clause specifying step specifying clause data requiring issue to the customer on the basis of data related to a received insurance contract when the data related to the insurance contract of the customer and attribute data of the customer are received, a receivability determination step determining whether the customer can receive the clause data specified in the clause specifying step or not, and a transmission step transmitting the clause data specified in the clause specifying step to the customer determined to be able to receive the data in the receivability determination step. In this way, the clause data can be transmitted to the customer accessible to a network via the network, and an insurance company can save labor. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明が属する技術分野】
本発明は、保険約款交付に関する情報処理技術に関する。
【０００２】
【従来の技術】
例えば特開２００２−１３３０９８号公報には以下のような技術が開示されている。すなわち、保険契約等手続方法およびシステムにおいて、保険会社または代理店は、顧客からの保険契約申込み情報に基づいて、インターネット等の通信ネットワークを介して顧客端末へ契約情報を送信する。また、顧客端末へ送信される契約情報のうち、契約した保険内容にとって必要な約款および特約条項のみを送信する。また、保険会社または代理店（媒介人、仲介人を含む）は、顧客端末に送信した契約情報について、顧客の要求に応じて、顧客がインターネット等の通信ネットワークを介して閲覧できるようにする。
【０００３】
【発明が解決しようとする課題】
しかしながら、上で述べた従来技術では、例えば保険契約申込みの修正があった場合や、異動があった場合などの約款の交付方法については考慮されていない。すなわち、共通する保険契約内容を含み、顧客に交付すべき約款データに重複があったとしても、最新の保険契約について必要な約款データを全て送信するような構成となっている。そのため、例えば特約を１つだけ追加した場合などには、該当する部分についてだけの約款データを交付すれば十分であるにも拘わらず、保険契約全体に対応した約款データを送信する。また、特約を減らした場合など、対応する約款データを顧客が既に取得済みであり、その約款が不適用となることを通知する必要がある場合でも、それに対応した通知を行うための手段が存在していなかった。このように、保険会社や顧客にとって通信及び処理負荷の削減等につながりにくい構成となっている。
【０００４】
また、約款などのデータを顧客にインターネット等の通信ネットワークを介して送信するとしても、顧客によってはこうしてネットワークへの対応ができていない場合がある。そのため、顧客によっては郵送などの別途の方法によって約款等を送付することが必要となる。
【０００５】
従って本発明の目的は、顧客に対して適切な内容の約款交付を適切な方法で行うための情報処理技術を提供することである。
【０００６】
【課題を解決するための手段】
本発明の第１の態様に係る、保険約款交付のための情報処理方法は、顧客の保険契約に関連するデータと顧客の属性データとを受信し、記憶装置に格納する受信ステップと、受信ステップにおいて記憶装置に格納された保険契約に関連するデータに基づき顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する約款特定ステップと、受信ステップにおいて記憶装置に格納された顧客の属性データに基づき、約款特定ステップにおいて特定され且つ必要約款識別データ格納部に識別データが格納された約款の約款データを顧客が受信可能か否かを判断する受信可能性判断ステップと、受信可能性判断ステップにおいて受信可能であると判断された顧客に対して、約款特定ステップにおいて特定され且つ必要約款識別データ格納部に識別データが格納された約款の約款データを送信する送信ステップとを含む。これにより、ネットワーク対応が可能な顧客にはネットワークを介して約款データを送信することができ、保険会社は省力化を図ることができる。
【０００７】
また、本発明の第１の態様において、受信可能性判断ステップにおいて受信不可能であると判断された顧客に対して、約款特定ステップにおいて特定され且つ必要約款識別データ格納部に識別データが格納された約款の約款データを印刷処理する印刷処理ステップをさらに含むようにしてもよい。ネットワーク対応が不可能な顧客等には印刷処理ステップにおいて印刷された約款を送付するようにするものである。なお、この場合においても交付が必要な約款だけが印刷されるので、消費資源の減量を図ることができるようになる。
【０００８】
また、上で述べた約款特定ステップが、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する第１特定ステップと、受信ステップにおいて記憶装置に格納されたデータに含まれる顧客の識別データを用いて顧客データ格納部を検索することにより読み出された顧客のデータに基づき当該顧客に交付済みの約款を特定し、当該顧客に交付済みの約款の識別データを交付済約款識別データ格納部に格納する第２特定ステップと、第１特定ステップにおいて特定され且つ必要約款識別データ格納部に格納された約款の識別データと、第２特定ステップにおいて特定され且つ交付済約款識別データ格納部に格納された顧客に交付済みの約款の識別データとを用いて今回交付すべき約款を特定し、当該約款の識別データを交付約款識別データ格納部に格納する第３特定ステップとを含み、上で述べた送信ステップにおいて、第３特定ステップにおいて特定され且つ交付約款識別データ格納部に識別データが格納された今回交付すべき約款の約款データを顧客宛に送信ような構成とすることも可能である。このように顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、通信負荷を減らすことができるようになる。
【０００９】
本発明の第２の態様に係る、保険約款交付ための情報処理方法は、顧客の保険契約に関連するデータを受信し、記憶装置に格納する受信ステップと、受信ステップにおいて記憶装置に格納された保険契約に関連するデータに基づき顧客に交付が必要な約款を特定し、当該約款の識別データを必要約款識別データ格納部に格納する第１特定ステップと、受信ステップにおいて記憶装置に格納されたデータに含まれる顧客の識別データを用いて顧客データ格納部を検索することにより読み出された顧客のデータに基づき当該顧客に交付済みの約款を特定し、当該顧客に交付済みの約款の識別データを交付済約款識別データ格納部に格納する第２特定ステップと、第１特定ステップにおいて特定され且つ必要約款識別データ格納部に格納された約款の識別データと、第２特定ステップにおいて特定され且つ交付済約款識別データ格納部に格納された顧客に交付済みの約款の識別データとを用いて今回交付すべき約款を特定し、当該約款の識別データを交付約款識別データ格納部に格納する第３特定ステップと、第３特定ステップにおいて特定され且つ交付約款識別データ格納部に識別データが格納された今回交付すべき約款の約款データを顧客宛に送信する送信ステップとを含む。すなわち、顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、重複した約款データを送信しないようにする。これにより、約款データを電子ファイルで送信する際には通信負荷の軽減を図ることができる。また、保険会社や顧客が約款データを紙に印刷するような場合には消費資源の削減を図ることができる。
【００１０】
本発明の第１及び第２の態様において、第２特定ステップにおいて交付済約款識別データ格納部に格納された約款の識別データのうち、第１特定ステップにおいて必要約款識別データ格納部に格納された約款の識別データに含まれていない、不適用とされる約款の識別データを不適用約款識別データ格納部に格納する不適用約款特定ステップをさらに含むようにしてもよい。
【００１１】
さらに、上で述べた不適用約款特定ステップにおいて不適用約款識別データ格納部に格納された約款の識別データに対応する約款についての情報を含む約款適用取消情報を生成し、取消情報格納部に格納する取消情報生成ステップと、取消情報格納部に格納された約款適用取消情報を顧客宛に送信するステップとをさらに含むようにしてもよい。これにより、顧客は読むべき約款を正確に把握できるようになる。
【００１２】
また、本発明の第１及び第２の態様において、記憶装置に格納された保険契約に関連するデータは、顧客の保険契約申込データ又は保険契約計上データである場合もある。これにより、例えば代理店端末から保険契約申込又は保険契約計上を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、以前に保険契約申込を受けて交付した約款の約款データの一部又は全部を、再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【００１３】
また、本発明の第１及び第２の態様において、記憶装置に格納された保険契約に関連するデータは、顧客の保険異動データである場合もある。これにより、代理店端末から保険異動要求を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、既契約保険の契約の際に交付した約款の約款データの一部又は全部を再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【００１４】
さらに、本発明の第１及び第２の態様において、記憶装置に格納された保険契約に関連するデータに基づき生成された保険証券データを顧客宛に送信するステップをさらに含むようにしてもよい。顧客は保険証券のデータ及び保険証券に対応した約款データを取得することができる。
【００１５】
また、上で述べた本発明の第１及び第２の態様において、送信ステップにおいて交付が必要な約款の約款データ又は今回送付すべき約款の約款データをメールの添付ファイルとして顧客に対して送信する、又は顧客のダウンロード要求により今回送付すべき約款の約款データを送信するようにしてもよい。保険会社及び顧客のシステム環境や通信環境に合わせた形態での約款送信が可能となる。
【００１６】
さらに、本発明の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データが複数ある場合、１つの約款ファイルに合成し、約款ファイル記憶部に格納するステップと、約款ファイル記憶部に格納された約款ファイルのダウンロード用リンク情報を生成し、リンク情報格納部に格納するステップと、リンク情報格納部に格納されたダウンロード用リンク情報を顧客に対して通知するステップとをさらに含み、顧客がダウンロード用リンク情報を用いてダウンロードを指示した場合、上記送信ステップが実行されるようにしてもよい。顧客は、約款ダウンロード用ホームページから今回の契約又は異動に対応した約款データを一括でダウンロードすることが可能となる。これにより、約款交付の管理も簡単になる。
【００１７】
また、本発明の第１及び第２の態様において、送信ステップにおいて送信された約款データを顧客が受信したと判定された場合、記憶装置に格納されたデータに含まれる顧客の識別データを用いて顧客データ格納部を検索することにより読み出された顧客のデータに、約款データが交付済みであることを表す情報を追加し、顧客データ格納部に格納するステップをさらに含むようにしてもよい。これにより、顧客に対して既に交付された約款の約款データを特定することが可能となる。また一方で、約款データを送信してから又はダウンロードを要求するメールを送信してから所定の期間、交付済みであることを表す情報が顧客のデータに追加されなかった場合には、約款を紙に印刷して郵送するような構成とすることも可能になる。
【００１８】
さらに、本発明の第１及び第２の態様において、送信ステップにおいて約款データを顧客に送信した時、又は記憶装置に格納された保険契約に関連するデータに基づき保険契約が計上された時に基づいて特定される時点において、送信ステップにおいて送信された約款データを顧客が受信したと判定されない場合、当該約款データを印刷処理するステップをさらに含むようにしてもよい。何らかの理由で受信されなかった約款を別途顧客に送付するためである。
【００１９】
本発明に係る情報処理方法をコンピュータに実行させるためのプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介して頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００２０】
【発明の実施の形態】
［実施の形態１］
本発明の第１の実施の形態に係るシステム構成図を図１に示す。例えばパーソナル・コンピュータであるユーザ端末１３は、図示しないがメーラ機能及びウェブ（Ｗｅｂ）ブラウザ機能を備えており、無線又は有線によりメールの送受信を行うこと及びインターネットに接続してホームページを閲覧することが可能となっている。
【００２１】
例えばインターネットであるネットワーク１１には、１又は複数のユーザ端末１３の他、保険契約の計上処理等を行う１又は複数の契約計上サーバ１５５、例えばメーラ機能及び保険契約申込機能を備えたパーソナル・コンピュータである１又は複数の代理店端末１７が接続されている。
【００２２】
契約計上サーバ１５５には、顧客に対する約款交付状況に関連するデータが格納されている約款交付管理データベース（ＤＢ）１５５１及び保険証券の印刷を行う保険証券印刷機１５５３が接続されている。また、契約計上サーバ１５５のハードディスク・ドライブ（ＨＤＤ）１５５５には、顧客に交付するための約款データが例えば約款ファイルとして格納されている。保険契約の分類方法や特約の種類によって、対応する約款ファイルは何種類であってもよい。ＨＤＤ１５５５は、その他データの記憶装置としても機能する。
【００２３】
また、保険会社１５には、図示しないＷｅｂサーバがあり、約款ファイルのダウンロード用ホームページの管理を行う。また、図示しないメール・サーバにより、顧客に対してメール送信等を実施する。その他、契約計上サーバ１５５又は図示しないその他のサーバによって管理される保険契約ＤＢ、顧客管理ＤＢ及び代理店ＤＢ等、保険業務処理を行うためのシステムが設置されている。
【００２４】
また、契約計上サーバ１５５には、図示しないが制御部と通信部とが設けられている。制御部の処理の詳細については、後の処理フローの説明において述べるが、例えば、約款交付管理ＤＢ１５５１の管理や、ＨＤＤ１５５５に格納されている約款ファイルやその他データの管理等の処理を行う。通信部は、約款ファイルの顧客などへの伝送等の処理を行うための通信インタフェイスである。
【００２５】
なお、契約計上サーバ１５５及び保険証券印刷機１５５３は必ずしも保険会社１５の内部に設置されている必要はなく、同様の機能が実現できればアウトソーシング等により外部に設置されるような構成であってもよい。
【００２６】
また、ネットワーク１１を経由する通信には、図示していないがドメイン・ネーム・サーバ（ＤＮＳ）、メール・サーバ、ファイア・ウォール等の、インターネット接続やメール送受信に必要な機器及び機能を使用するものとする。
【００２７】
約款交付管理ＤＢ１５５１のテーブル構成及び格納されるデータの一例を図２及び図３に示す。約款交付管理ＤＢ１５５１には、例えば図２に示す約款テーブルと図３に示す交付管理テーブルとが含まれている。
【００２８】
図２に示す約款テーブルの例には、約款番号の列２００、名称の列２０２及びファイル保存場所の列２０４が含まれている。本テーブルでは、例えば自動車保険の約款に関するデータが登録されており、約款番号の列２００の値がキーとなって約款の名称及び物理的な約款ファイルの保存（格納）場所を特定できるような構成となっている。なお、約款の種類や名称については各保険会社の保険商品の特徴や分類方法などによって変わる場合もあり、物理的な約款ファイルの格納場所についてもシステム環境に合わせて変わる場合もある。
【００２９】
図３に示す交付管理テーブルの例には、申込書番号の列３００、顧客番号の列３０２、顧客メール・アドレスの列３０４、契約申込内容の列３０６、約款交付済フラグの列３０８、交付約款の列３１０、登録日時の列３１２及び計上フラグの列３１４が含まれている。レコードは保険契約申込みのデータを代理店端末１７から受信する毎に生成され、キーとなる申込書番号の列３００によって特定される。顧客番号の列３０２には顧客を特定するＩＤが登録され、図示しない顧客管理ＤＢ等によって顧客の氏名や住所などの情報が導出できるような構成になっている。顧客メール・アドレスの列３０４には約款データ送信の際の宛先となる電子メール・アドレスが登録される。本実施の形態では、一連の処理において参照するテーブルの数を少なくするために非正規化しているが、正規化して交付管理テーブル（図３）には顧客メール・アドレスの列３０４を含めず、メール送信する際には顧客番号の列３０２の値から導出するような構成であってもよい。
【００３０】
契約申込内容の列３０６には、当該保険契約申込の内容に対応する、交付が必要な約款を表すデータが契約計上サーバ１５５の制御部によって登録される。制御部は、保険契約申し込みの内容に基づき対応する約款を特定し、契約申込内容の列３０６に登録する。本テーブルの例では約款テーブル（図２）の約款番号の列２００の値が１つ又は複数登録される。具体的には、例えばある顧客の契約申込内容が、総合自動車保険であり運転者家族限定特約を付加したものであった場合、約款テーブル（図２）の参照によって約款番号の列の値”００”及び”０１”が特定される。この交付が必要な約款番号の特定は、特約等の契約内容の設定と必要な約款を対応付けしておき保険契約申込の際に自動になされるような構成であってもよいし、契約内容から代理店が判断するような構成であってもよい。そして、特定された約款番号を合成したデータが登録される。ここでは”００”及び”０１”から合成された”０００１”が、契約申込内容の列３０６に登録される。従って、契約申込内容の列３００の値を使用した処理を行う際には、約款番号の桁数である例えば２桁づつに区切って処理を行うような構成となっている。
【００３１】
約款交付済フラグの列３０８には、レコード生成時には”０”が設定され、送信した約款データを顧客が受信したと判定された場合には”１”が設定される。契約計上サーバ１５５の制御部は、通信部を介して約款データを送信し、例えばメールの開封通知等により顧客が約款データを確認したというデータを取得した時点で、フラグを”１”とする。
【００３２】
交付約款の列３１０には、顧客に対して今回交付すべき（未だ交付済みでない）約款を表すデータが契約計上サーバ１５５の制御部によって登録される。なお、契約申込内容の列３０６と同様に、約款番号によってデータが構成される。レコード生成時には、顧客番号の列３０２の値が同じレコードを抽出することにより、交付約款の列３１０の値と約款交付済フラグの列３０８の値から既に交付済みの約款番号が特定される。そして契約申込内容の列３０６の値と既に交付済みの約款番号とから今回交付すべき（未だ交付済みでない）約款番号が特定され、合成したものが交付約款の列３１０に登録される。例えば、顧客番号の列３０２の値が”００００１１１１”で、契約申込内容の列３０６の値が”０００１０２１０”であるレコードが生成される。ここで、契約申込内容に対応する約款の番号は、”００”、”０１”、”０２”及び”１０”である。そして、顧客番号の列３０２の値が”００００１１１１”である既存レコードが抽出される。
【００３３】
例えば抽出されたレコードが１つあり、約款交付済フラグの列３０８の値が”１”で且つ交付約款の列３１０の値が”０００１”であった場合には、”００”及び”０１”の約款番号が示す約款データは当該顧客に対して既に交付済みであることが分かる。そこで、契約申込内容に対応する約款の番号である”００”、”０１”、”０２”及び”１０”から、既に交付済みの約款の番号である”００”及び”０１”を除いた”０２”及び”１０”が今回交付すべき約款の番号となる。”０２”及び”１０”を合成して”０２１０”という値が交付約款の列３１０に登録される。このように、今回交付すべき約款は、交付が必要な約款の一部若しくは全部により構成されることになる。
【００３４】
登録日時の列３１２には、レコードが生成された日時が登録される。また、計上フラグの列３１４には、レコード生成時には”０”が設定され、当該レコードのデータで計上（顧客が申込み内容を確定し、その確定内容に基づいた保険契約データが保険会社に送られ、受け付けられること）が行われる場合には”１”が設定される。
【００３５】
次に、図４乃至図８を用いて図１に示したシステムの動作を説明する。
【００３６】
代理店端末１７は、例えば、図示しない保険契約申込用システムの画面において、代理店による顧客に関するデータ（顧客データ又は顧客属性データとも呼ぶ）と保険契約の申込書データとの入力を受け付ける（ステップＳ１）。続いて代理店端末１７は、代理店の指示に応じて、入力を受け付けた顧客データと受け付けた申込書データとを契約計上サーバ１５５に対して送信する（ステップＳ３）。契約計上サーバ１５５の制御部（以下、契約計上サーバ１５５における処理の説明において、単に契約計上サーバ１５５と表示する場合は、制御部による処理を示す。または契約計上サーバ１５５（制御部）と表示する場合もある。）は、代理店端末１７から顧客データと申込書データとを受信し、図示しない保険契約申込ＤＢ等に格納する（ステップＳ５）。また、契約計上サーバ１５５（制御部）は、通信部を介して代理店端末１７から受信した申込書データを用いて交付管理テーブル（図３）用のレコードを生成し、約款交付管理ＤＢ１５５１内の交付管理テーブル（図３）に格納する（ステップＳ７）。
【００３７】
この段階では、レコードには申込書番号の列３００、顧客番号の列３０２、顧客メール・アドレスの列３０４、契約申込内容の列３０６及び登録日時の列３１２の値が記録され、約款交付済フラグの列３０８及び計上フラグの列３１４には初期値として”０”が記録される。交付約款の列３１０の値については、以下に述べる処理によって特定されるため、ＮＵＬＬ値が記録されるか又は何も記録されない。なお、顧客がメール・アドレスを有しない等、約款データの受信が不可能な場合は、顧客メール・アドレスの列３０４には何も記録されない。例えば、図３の交付管理テーブルにおいて顧客番号の列３０４のうち、００００７７７７の顧客については、約款データの受信が不可能な顧客であるため、顧客メール・アドレスの列３０４には空白のまま何も記されていない。
【００３８】
一方で、代理店端末１７は、保険契約の申込み処理を終了するかどうかを判定する（ステップＳ９）。例えば、図示しない保険契約申込用システムの画面で、終了ボタンが押されたかどうかを判定する。まだ終了しないと判定された場合には、ステップＳ１からの申込書データ受付処理を繰り返す。終了と判定された場合には、代理店による申込書番号の入力を受け付ける（ステップＳ１１）。ここでは、複数の保険契約申込みが存在した場合に、代理店が顧客に対して約款を送信するために特定した、交付管理テーブル（図３）のレコードにおける申込書番号の入力を受け付ける。というのも、顧客はどんな内容で加入するかを検討するために、暫時、複数タイプの保険契約の申込みがなされる場合があるためである。そして代理店端末１７は、入力された申込書番号を契約計上サーバ１５５に対して送信する（ステップＳ１３）。
【００３９】
契約計上サーバ１５５（制御部）は、代理店端末１７から申込書番号を受信し、一旦記憶装置に格納する（ステップＳ１５）。処理は端子Ａを介して図５の処理に移行する。
【００４０】
契約計上サーバ１５５（制御部）は、代理店端末１７から受信した申込書番号を用いて約款交付管理ＤＢ１５５１を検索し、交付管理テーブル（図３）のレコードを特定する（ステップＳ１７）。そして、特定されたレコードの契約申込内容の列３０６の値に対応する約款ファイルを特定する（ステップＳ１９）。例えば約款番号を記憶装置（ＨＤＤ１５５５など）に格納する。また、契約計上サーバ１５５（制御部）は、特定されたレコードの顧客番号の列３０２の値と同じ顧客番号を含み且つ約款交付済みフラグが”１”であるレコードを検索して抽出する（ステップＳ２１）。抽出した結果、レコードが存在するかどうか判定し（ステップＳ２３）、存在しないと判定された場合には、特定されたレコードの交付約款の列３１０に契約申込内容の列３０６の値をそのまま登録する（ステップＳ２７）。すなわち、当該顧客に対しては以前に約款を送付していないため、今回の契約申込内容に対応し且つ交付が必要な約款を全て交付するように設定する。
【００４１】
一方で、ステップＳ２３においてレコードが存在すると判定された場合には、契約計上サーバ１５５（制御部）は、ステップＳ１７の処理で特定されたレコードの契約申込内容の列３０６の値と、ステップＳ２１の処理で抽出されたレコードの交付約款の列３１０の値とから、未だ交付済みでない約款を特定する（ステップＳ２５）。例えば約款番号を記憶装置に格納する。この場合には、ステップＳ１７の処理で特定されたレコードの交付約款の列３１０に、ステップＳ２５で特定された未だ交付済みでない約款を表すデータ（約款番号）を登録する（ステップＳ２６）。なお、ステップＳ２１の処理で抽出されたレコードが複数存在する場合には、契約計上サーバ１５５（制御部）は、交付約款の列３１０の値をレコード数分合わせて交付済みの約款を特定する。例えば２つのレコードが抽出され、交付約款の列３１０の値が”０００１”及び”０２０３”であった場合には、交付済みの約款の約款番号は”００”、”０１”、”０２”及び”０３”である。また、交付が必要な約款が全て交付済みであった場合には、ステップＳ２７の処理において、ステップＳ１７の処理で特定されたレコードの交付約款の列３１０に、所定の「交付約款なし」を表す値を登録するか、又は何も登録しないようにする。
【００４２】
契約計上サーバ１５５（制御部）は、交付が必要な約款（ここでは既に交付済みの約款が無い場合）又は今回交付すべき約款が特定できたら、顧客が約款データの受信が可能かどうかを判定する（ステップＳ２７）。そして、約款データを受信不可能であると判定された場合（ステップＳ２７：Ｎｏルート）、契約計上サーバ１５５（制御部）は図示しないプリンタ等を用いて約款データの印刷処理を行う（ステップＳ２８）。そして印刷された約款は、別途、保険会社などから顧客に対して送付される。一方、顧客が約款データを受信可能であると判定された場合（ステップＳ２７：Ｙｅｓルート）、契約計上サーバ１５５（制御部）は約款データの顧客への送信方法を判定する（ステップＳ３０）。この判定は、予め定められたいずれかの方法に固定してもよいし、顧客の希望に合わせてもよい。メールの添付ファイルで送信すると判定された場合には、端子Ｂを介して図６の処理に移行する。また、メールの添付ファイルでは送信しないと判定された場合には、顧客にファイルをダウンロードしてもらうため、申込書番号毎のダウンロード用ページのＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）を生成してＵＲＬ記憶部に格納し（ステップＳ３１）、端子Ｃを介して図７の処理に移行する。契約計上サーバ１５５の制御部は、通信部を介していずれかの方法で送信する。
【００４３】
次に、端子Ｂを介して遷移した処理について図６を用いて説明する。
【００４４】
契約計上サーバ１５５（制御部）は通信部を介して、今回顧客に交付すべき約款データを、例えば１つのファイルに合成した上で、メールの添付ファイルとして顧客（例えばユーザ端末１３を使用する）に送信する（ステップＳ３３）。但し、１つのファイルに合成せずに送る場合もある。ユーザ端末１３は、顧客の指示に応じて、契約計上サーバ１５５からのメールを受信して表示装置に表示する（ステップＳ３５）。そしてユーザ端末１３は、メールを受信したことを通知するために、開封確認メールを契約計上サーバ１５５に送信する（ステップＳ３７）。ここで、開封確認メール送信の仕組みとしては、メーラの機能を使用するような構成であってもよいし、例えば開封確認ボタンを顧客が押すことによってメールが送信されるような構成であってもよい。そしてユーザ端末１３は、自動的に又は顧客の操作に従い、図示しないユーザ端末１３のＨＤＤ等の記憶装置に、受信したメールの添付ファイル（約款データ）を格納する（ステップＳ３９）。
【００４５】
一方で契約計上サーバ１５５（制御部）は、通信部を介してユーザ端末１３からの開封確認メールを受信（ステップＳ４１）した場合には、対応する交付管理テーブル（図３）のレコードを特定し、約款交付済フラグの列３０８の値を”１”に設定する（ステップＳ４３）。
【００４６】
次に、端子Ｃを介して遷移した処理について図７を用いて説明する。
【００４７】
契約計上サーバ１５５（制御部）は、ステップＳ３１の処理で生成した約款ダウンロード用ページのＵＲＬを、通信部を介して顧客（例えばユーザ端末１３を使用する）に送信する（ステップＳ４５）。ユーザ端末１３は、顧客の指示に応じて、契約計上サーバ１５５（制御部）からのメールを受信して表示装置に表示する（ステップＳ４７）。表示されたＵＲＬを、顧客がクリックしたりＷｅｂブラウザのアドレス欄に入力した場合には、ユーザ端末１３は顧客からの操作を受け付け、約款ダウンロード用ページ・データの要求を契約計上サーバ１５５に送信する（ステップＳ４９）。なお、ユーザ端末１３が送信するデータは、Ｗｅｂページを表示するためのものであり、実際には図示しないＷｅｂサーバに対して送信する。そしてＷｅｂサーバは、契約計上サーバ１５５のＨＤＤ１５５５や契約計上サーバ１５５（制御部）が管理する約款交付管理ＤＢ１５５１にアクセスして処理を行う。ここでは説明を分かりやすくするために、サーバ側の処理は契約計上サーバ１５５が行うものとしている。
【００４８】
契約計上サーバ１５５（制御部）は、ユーザ端末１３から約款ダウンロード用ページ・データの要求を通信部を介して受信する（ステップＳ５１）。なお、約款ダウンロード用ページのＵＲＬは、ステップＳ３１において申込書番号毎に生成されているため、逆にＵＲＬから申込書番号を特定することができる。契約計上サーバ１５５（制御部）は、受信したＵＲＬから申込書番号を特定する（ステップＳ５３）。さらに、特定した申込書番号を用いて約款交付管理ＤＢ１５５１を検索し、交付管理テーブル（図３）のレコードを特定する。特定されたレコードの交付約款の列３１０の値から、今回交付すべき約款を特定する（ステップＳ５５）。特定された約款番号は記憶装置に格納される。例えば、特定されたレコードの交付約款の列３１０の値が”０００１”であった場合には、今回交付すべき約款の番号は、”００”及び”０１”である。
【００４９】
契約計上サーバ１５５（制御部）は、約款ダウンロード用ページ・データを生成し、ユーザ端末１３に通信部を介して送信する（ステップＳ５７）。ユーザ端末１３は、契約計上サーバ１５５から通信部を介して送信された約款ダウンロード用ページ・データを受信し、表示装置に表示する（ステップＳ５９）。ユーザ端末１３は、顧客による約款ダウンロードの操作を受け付けた場合には、約款ダウンロード要求を契約計上サーバ１５５に対して送信する（ステップＳ６１）。契約計上サーバ１５５（制御部）は通信部を介して、ユーザ端末１３から約款ダウンロード要求を受信する（ステップＳ６３）。そして契約計上サーバ１５５（制御部）は、今回交付すべき約款データを１つのファイルに合成してユーザ端末１３に対して送信する（ステップＳ６５）。約款データを１つのファイルに合成することにより、顧客の約款のダウンロード処理及び保険会社のダウンロード（交付）管理が容易になる。契約計上サーバ１５５（制御部）は、ユーザ端末１３への送信が完了した時点で、顧客に対して約款を送信したことを示す記録として、交付管理テーブル（図３）の対応するレコードの約款交付済フラグを”１”に設定する（ステップＳ６７）。
【００５０】
一方、ユーザ端末１３は、通信部を介して契約計上サーバ１５５（制御部）から送信された約款ファイルを受信する（ステップＳ６９）。そしてユーザ端末１３は、自動的に又は顧客の操作に従い、図示しないユーザ端末１３のＨＤＤ等の記憶装置に、受信した約款ファイルを格納する（ステップＳ７１）。
【００５１】
以上では、申込書が作成される際に、都度、交付が必要な約款や今回交付すべき約款データを特定した交付するようにしていたが、約款データの交付は計上時点にまとめて行うようにしてもよい。この場合、契約計上サーバ１５５（制御部）は顧客の新規の保険契約を計上した時点で、約款交付管理ＤＢ１５５１を検索し、交付管理テーブル（図３）のレコードを特定する。そして、交付管理テーブル（図３）において、計上フラグを”１”に設定するのと併せて、当該申込書番号の契約内容の列３０６の値に対応する約款ファイルを特定する。その上で、約款データの受信が可能な顧客については、当該保険契約に対応して顧客に交付することが必要な約款データとして特定された約款ファイルを送信する。この場合、図５のステップＳ２１からステップＳ２６までの処理は省略することになる。また、約款データの受信が不可能な顧客については、契約計上サーバ１５５（制御部）は保険証券印刷機１５５３に対して交付が必要な約款の印刷処理の指示を行う。
【００５２】
次に、図８における処理について説明する。契約計上サーバ１５５（制御部）は、約款交付管理ＤＢ１５５１の交付管理テーブル（図３）を検索して、計上フラグの列３１４の値が”１”であるレコードを抽出する（ステップＳ７３）。すなわち、計上指示が代理店端末１７から受信された申込書番号に対応して計上フラグの列３１４に”１”を登録しておくものとする。そして、ステップＳ７３において抽出されたレコードから、さらに特定の顧客のレコードを顧客番号を用いて抽出する（ステップＳ７５）。そして顧客番号によって抽出されたレコードの約款交付済フラグの列３０８の値を判定する（ステップＳ７７）。全て”１”であるかどうか判定し（ステップＳ７９）、全て”１”であると判定された場合には、交付すべき約款は顧客に交付済みであるため、当該保険契約の証券を例えばハガキ形式で保険証券印刷機１５５３により印刷する（ステップＳ８１）。または、図示しない証券印刷システムに印刷指示を出力するような構成でもよい。また、ステップＳ７９において、全て”１”ではない（少なくとも１つは”１”ではない）と判定された場合には、約款交付済フラグの列３０８の値が”０”であるレコードの交付約款の列３１０の値から、約款（約款番号）を特定する（ステップＳ８３）。特定された約款番号は記憶装置に格納される。
【００５３】
交付約款の列３１０の値の特性から、顧客単位で重複する値（約款番号）は存在しないため、顧客に交付すべき約款のうち、未だ顧客に交付済みでない約款（約款番号）が、以上の処理により特定できる。例えば、同一顧客（交付管理テーブル（図３）の顧客番号００００１１１１）について、第１のレコード（申込書番号０００００００１）において契約申込内容の列３０６の値が”０００１”、約款交付済みフラグの列３０８の値が”１”、交付約款の列３１０の値が”０００１”、計上フラグの列３１４の値が”０”であり、第２のレコード（申込書番号０００００００２）において契約申込内容の列３０６の値が”０００１０２１０”、約款交付済みフラグの列３０８の値が”１”、交付約款の列３１０の値が”０２１０”、計上フラグの列３１４の値が”１”であり、第３のレコード（申込書番号０００００００３）において契約申込内容の列３０６の値が”０００１０５１０”、約款交付済みフラグの列３０８の値が”０”、交付約款の列３１０の値が”０５”、計上フラグの列３１４の値が”０”であったとする。つまり、顧客が３つの契約タイプの内、申込書番号０００００００２を最終的に選択して契約したとする。計上フラグの列３１４の値から、計上の対象となるのは第２のレコードだけであり、顧客に交付が必要な約款（約款番号）は、契約申込内容の列３０６の値の”０００１０２１０”に示される”００”、”０１”、”０２”及び”１０”である。ここで、第１のレコード及び第２のレコードの、約款交付済みフラグの列３０８の値及び交付約款の列３１０の値から、約款が”００”及び”０１”と、”０２”及び”１０”との２回に分けて交付され、顧客は必要とする”００”、”０１”、”０２”及び”１０”で示される約款を全て受信したことが分かる。
【００５４】
これを図８の処理フローに当てはめてみると、ステップＳ７３において第２のレコードだけが抽出される。ステップＳ７５は、ステップＳ７３で抽出したレコードを同一顧客についてさらに抽出するステップがあり、ここでは既に同一顧客のレコードが抽出されているためそのまま通過する。そして、ステップＳ７７において約款交付済フラグが”１”と判定される。レコードは１つなのでステップＳ７９において「Ｙｅｓ」と判定され、ステップＳ８１の処理へ進む。約款の追加送信は必要ないケースであったため、正しく処理が行われることが分かる。
【００５５】
一方、第３のレコードの計上フラグの列３１４の値が”１”であり、他の全ての条件は上で述べたケースと同じ場合であったとする。すなわち、第２のレコード及び第３のレコードの計上フラグの列３１４の値が”１”であるものとする。その場合、計上フラグの列３１４の値から、計上の対象となるのは第２のレコードと第３のレコードとなる。顧客に交付が必要な約款（約款番号）は、契約申込内容の列３０６の値からの重複を除くと”００”、”０１”、”０２”、”０５”及び”１０”である。ここで、第２のレコード及び第３のレコードの、約款交付済みフラグの列３０８の値及び交付約款の列３１０の値から、約款が”００”及び”０１”と、”０２”及び”１０”との２回に分けて交付され、顧客は必要とする”００”、”０１”、”０２”、”０５”及び”１０”で示される約款のうち、”００”、”０１”、”０２”、及び”１０”を受信したことが分かる。すなわち、”０５”で示される約款を顧客に追加送信する必要がある。こうした判定処理が契約計上サーバ１５５（制御部）によってなされる。
【００５６】
これを図８の処理フローに当てはめてみると、ステップＳ７３において、契約計上サーバ１５５（制御部）により第２のレコード及び第３のレコードが抽出される。ステップＳ７５は、ステップＳ７３で抽出したレコードを同一顧客についてさらに抽出するステップであり、ここでは既に同一顧客のレコードが抽出されているためそのまま通過する。そして、ステップＳ７７において第２のレコードの約款交付済フラグは”１”、第３のレコードの約款交付済フラグは”０”と判定される。第３のレコードが”０”のため、ステップＳ７９において「Ｎｏ」と判定され、契約計上サーバ１５５（制御部）による処理はステップＳ８３の処理へ進む。そして、ステップＳ８３の処理において第３のレコードの交付約款の列３１０の値から約款番号”０５”が特定される。”０５”で示される約款の顧客への追加送信が必要なケースであったため、正しく処理が行われることが分かる。
【００５７】
このように、同一顧客が１つの契約タイプを選択した場合だけではなく、例えば同一顧客が２台以上の車両についてそれぞれ異なる契約タイプの自動車保険を申し込む場合であっても本実施の形態では対処可能である。
【００５８】
なお、ここでは同一顧客が例えば複数の車両にそれぞれ自動車保険契約を申し込む場合、複数の自動車保険契約間で約款を共有して利用するような仕組みとしている。しかし本実施の形態に代えて、同一契約者であっても、例えば個々の自動車保険契約毎に交付が必要な約款を全て交付するようにしても良い。すなわち、約款交付の管理を個々の保険対象毎（あるいは保険契約毎）に行い、各保険対象毎に約款交付状況を管理しても良い。そして、同一の保険契約のために複数の申し込み（複数タイプの契約申し込み）がなされた場合、その都度重複した約款を交付するのではなく、先の申し込みで交付済みの約款を改めて交付せずに後の申し込みに対応して未交付の約款（今回交付が必要な約款）のみを交付する。
【００５９】
以上説明したようにステップＳ８３では、何らかの原因により、顧客が約款を受信したという確認がとれなかったケースを契約計上サーバ１５５（制御部）が抽出している。そして、このようなケースでは約款を紙（冊子）で顧客に対して送付するため、契約計上サーバ１５５（制御部）はステップＳ８３で特定された約款及び当該契約の証券を保険証券印刷機１５５３を使用して印刷する（ステップＳ８５）か、または印刷処理するように指示をする。あるいは、既存の約款冊子が印刷された証券と共に封筒に封入される。
【００６０】
なお、図８の処理フローは、契約計上サーバ１５５におけるシステム時間を制御部が取得することによって、所定の周期（例えば１日）で実施することを前提としたフローとなっている。しかし、あるレコードの計上フラグが”１”にセットされた場合や他の任意のタイミングを制御部が検知して、その時点で実施するようにしても良い。また、あるレコードに着目して、当該レコードの計上タイミングから所定時間経過後に実行するといった構成を採用する場合もある。
【００６１】
なお、ステップＳ７９において「Ｎｏ」と判定された場合、ステップＳ８３の処理に代えて、顧客が最終的に選択して計上された契約申込内容に対応し且つ交付が必要な約款（約款番号）を特定して、そのすべてを印刷するようにしてもよい。つまり、計上された契約申込内容に対応し、交付が必要な約款（約款番号）として、契約申込内容の列３０６の値から約款番号（例えば第３レコードが計上された場合には、”００”、”０１”、”０５”及び”１０”）を特定して、それらを印刷処理するようにしてもよい。
【００６２】
契約計上サーバ１５５（制御部）は、ステップＳ７３において抽出されたレコードの全顧客について、以上の処理を行ったかどうか判定し（ステップＳ８７）、全顧客について処理が終了していないと判定された場合には、ステップＳ７５からの処理を繰り返す。また、全顧客について処理が終了したと判定された場合には、交付管理テーブルの計上済みのレコードをクリアする（ステップＳ８９）。
【００６３】
次に、交付済みの約款データの内、実際の契約にいたらなかったために適用されないものを、顧客に通知する処理について説明する。
【００６４】
例えば、交付管理テーブル（図３）の顧客番号００００２２２２の顧客について見ると、申込書番号０００００００４については、契約申込内容の列３０６の値が”０００１０２０３”であり、交付約款の列３１０の値も”０００１０２０３”であり、約款交付済みフラグの列３０８の値が”１”であることから”００”、”０１”、”０２”、及び”０３”の約款データが交付済みであることが契約計上サーバ１５５（制御部）によって確認される。また、申込書番号０００００００５については、契約申込内容の列３０６の値が”０００１０２”であり、申込書番号０００００００４においてすでにこれに対応する約款データが交付済みであることから、交付約款の列３１０は空白となっている。そして、申込書番号０００００００５については、計上フラグの列３１４の値が”１”であり、申込書番号０００００００４の計上フラグの列３１４の値が”０”となっている。つまり、顧客番号００００２２の顧客は、申込書番号０００００００４と、申込書番号００００００５の契約内容で検討した結果、最終的に申込書番号０００００００５の内容で契約締結し、その契約データが計上されたことになる。
【００６５】
すなわち、申込書番号０００００００４の交付約款の列３１０の値のうち、”０３”に対応する約款がすでに交付されたにもかかわらず、最終的には計上された契約に照らすと不必要な約款であったことになる。そこで、契約計上サーバ１５５（制御部）は、申込書番号０００００００５について計上フラグを”１”に更新した時点で、図示しないが交付管理テーブル（図３）の別途設けられた削除約款の列に”０３”の値を設定する。さらに、契約計上サーバ１５５（制御部）は、”０３”に対応する約款が実際に契約された保険契約においては適用されないことを知らせるために、図９に例として示した内容の通知を通信部を介して行う。図９には、契約加入へのお礼の言葉、送信内容の説明文、適用とならない約款の名称、約款番号、さらに約款の内容が記載されている。契約計上サーバ１５５（制御部）は、図９に示した送信内容を所定のデータ記録領域（例えばＨＤＤ１５５５）から抽出して生成する。
【００６６】
また、交付管理テーブル（図３）の顧客番号００００４４４４の顧客について見ると、申込書番号０００００００７については、契約申込内容の列３０６の値が”０００１０３”であり、交付約款の列３１０の値が”０００１０３”となっており、約款交付済みフラグの列３０８の値が”１”であることから”００”、”０１”及び”０３”の約款データが交付済みであることが契約計上サーバ１５５（制御部）によって確認される。なお、計上フラッグの列の３１４の値が”１”となっており、この内容で契約が締結されたことが確認できる。また、申込書番号０００００００８については、契約申込内容の列３０６の値が”０００１０４１４”であり、交付約款の列３１０の値が”０４１４”となっており、約款交付済みフラグの列３０８の値が”１”であることから”０４”及び”１４”の約款データがすでに交付済みであることが契約計上サーバ１５５（制御部）によって確認される。
【００６７】
そして、申込書番号０００００００８については、計上フラグの列３１４の値は”０”となっている。すなわち顧客番号００００４４４４の顧客は、申込書番号００００００００７と、申込書番号０００００００８の内容で検討した結果、最終的に申込書番号００００００００７の内容で契約締結し、その契約データが計上されたことになる。つまり、申込書番号０００００００８の交付約款の列３１０の値、”０４１４”に対応する約款はすでに交付されたにもかかわらず、最終的に計上された契約に照らすと不必要な約款であったことになる。そこで、契約計上サーバ１５５（制御部）は、申込書番号０００００００７について計上フラグを”１”に更新した時点で、図示しないが交付管理テーブル（図３）の申込書番号０００００００８の別途設けられた削除約款の列の値を”０４１４”と設定する。さらに、契約計上サーバ１５５（制御部）は、”０４１４”に対応する約款が実際に契約された保険契約においては適用されないことを知らせるための通知を通信部を介して行う。通知内容は、図９に示したのと同様の方法を採ることができる。
【００６８】
なお、適用されない約款を通知するための方法は、以上で示したような方法に代えて、あらためて交付が必要な約款をすべて送信し直してもよい。その場合、送信内容の説明文としては、例えば「この度ご契約いただきました保険契約については、下記記載の約款の内容が適用されることになります。過日お送りした約款データは削除いただき、本データを保存いただきますようお願いいたします。」といった内容になる。契約計上サーバ１５５（制御部）は、交付が必要な約款をすべて抽出し、併せてそれに対応する説明文を付加して送信内容を生成し、通信部を介して顧客に送信する。
【００６９】
このように約款データを受信可能な顧客に対して交付が必要な約款をネットワークを介した送信によって交付することで、保険会社は郵送によって約款を交付することよる通信費や負荷を削減できる。また、顧客は適用される約款のみを、都度、入手することが可能となり、保険加入の参考資料として利用することができる。さらに、今回交付すべき約款を特定することで、複数の保険契約タイプについて検討したうえで契約内容を決定したり、保険契約申込書の修正を行うなどの原因によって、約款を交付済みの顧客に対してさらに約款を交付するような場合に、顧客に交付済みの約款データを特定することにより、重複した約款データの送信を避けることができる。また、不必要となった約款について、対象外という通知を行うことで、顧客の契約内容に関する誤解を防止することができる。こうして、保険会社や顧客は通信及び処理負荷の削減を図ることができる。また、顧客が何らかの理由により約款を受信しなかった場合又は受信できなかった場合にも、冊子に印刷して郵送するなどの対応処理が可能となる。
【００７０】
［実施の形態２］
本発明の第２の実施の形態に係るシステム構成図を図１０に示す。例えばパーソナル・コンピュータであるユーザ端末２３は、図示しないがメーラ機能及びウェブ（Ｗｅｂ）ブラウザ機能を備えており、無線又は有線によりメールの送受信を行うこと及びインターネットに接続してホームページを閲覧することが可能となっている。
【００７１】
例えばインターネットであるネットワーク２１には、１又は複数のユーザ端末２３の他、保険契約の計上処理等を行う１又は複数の契約計上サーバ２５５、例えばメーラ機能及び保険契約申込機能を備えたパーソナル・コンピュータである１又は複数の代理店端末２７が接続されている。
【００７２】
契約計上サーバ２５５には、顧客の保険契約状況に関連するデータが格納されている契約管理ＤＢ２５５１が接続されている。また、契約計上サーバ２５５のＨＤＤ２５５５には、顧客に交付するための約款データが例えば約款ファイルとして格納されている。保険契約の分類方法や特約の種類によって、対応する約款ファイルは何種類であってもよい。　また、契約計上サーバ２５５には、図示しないが制御部と通信部とが設けられている。制御部の処理の詳細については、後の処理フローの説明において述べるが、例えば、約款交付管理ＤＢ２５５１の管理や、ＨＤＤ２５５５に格納されている約款ファイルやその他データの管理等の処理を行う。通信部は、約款ファイルの顧客などへの伝送等の処理を行うための通信インタフェイスである。
【００７３】
また、保険会社２５には、図示しないＷｅｂサーバがあり、約款ファイルのダウンロード用ホームページの管理を行う。また、図示しないメール・サーバにより、顧客に対してメール送信等を実施する。その他、契約計上サーバ２５５又は図示しないその他のサーバによって管理される保険契約ＤＢ、顧客管理ＤＢ及び代理店ＤＢ等、保険業務処理を行うためのシステムが設置されている。また、契約計上サーバ２５５には図示しない保険証券又は異動承認書印刷機が接続されている。
【００７４】
なお、契約計上サーバ２５５やその他の図示しないサーバは必ずしも保険会社２５の内部に設置されている必要はなく、同様の機能が実現できればアウトソーシング等により外部に設置されるような構成であってもよい。
【００７５】
また、ネットワーク２１を経由する通信には、図示していないがドメイン・ネーム・サーバ（ＤＮＳ）、メール・サーバ、ファイア・ウォール等の、インターネット接続やメール送受信に必要な機器及び機能を使用するものとする。
【００７６】
契約管理ＤＢ２５５１には、例えば約款テーブル（図２）と以下に説明する契約管理テーブルとが含まれている。契約管理テーブルの構成及び格納されるデータの一例を図１１に示す。
【００７７】
図１１に示す契約管理テーブルの例では、証券番号の列１００、証券ファイル保存場所の列１０２、顧客番号の列１０４、顧客メール・アドレスの列１０６、契約内容の列１０８、交付約款の列１１０、約款交付済フラグの列１１２、顧客交付済約款の列１１４、契約計上日／異動承認日の列１１６及び削除フラグの列１１８が含まれている。レコードは顧客の保険契約毎に生成され、キーとなる証券番号の列１００によって特定される。なお、図１１の例では証券番号の列１００の値だけを見ると重複しているレコードが存在するが、削除フラグの列１１８の値によって、有効なレコードと無効なレコードとの判別を可能にし、有効なレコードは重複しないような構成となっている。
【００７８】
証券ファイル保存場所の列１０２には、例えば図示しない保険証券発行システムによって生成された保険証券ファイルの物理的な保存（格納）場所が登録される。本実施の形態では保険証券を電子ファイルで取扱うため、保険証券を印刷したり顧客に送信したりする時に、この証券ファイル保存場所の列１０２の値から保険証券ファイルを特定する。
【００７９】
顧客番号の列１０４には顧客を特定するＩＤが登録され、図示しない顧客管理ＤＢ等によって顧客の氏名や住所などの情報が導出できるような構成になっている。顧客メール・アドレスの列１０６には保険証券データ及び約款データ送信の際の宛先となる電子メール・アドレスが登録される。本実施の形態では、一連の処理において参照するテーブルの数を少なくするために非正規化しているが、正規化して契約管理テーブル（図１１）には顧客メール・アドレスの列１０６を含めず、メール送信する際には顧客番号の列１０４の値から導出するような構成であってもよい。
【００８０】
契約内容の列１０８には、当該保険契約の内容に対応した約款を表すデータが登録される。本テーブルの例では約款テーブル（図２）の約款番号の列２００の値が１つ又は複数登録される。具体的には、例えばある顧客の契約内容が、総合自動車保険であり運転者家族限定特約を付加したものであった場合、約款テーブル（図２）の参照によって約款番号の列の値”００”及び”０１”が特定される。この交付が必要な約款番号の特定は、特約等の契約内容の設定と必要な約款を対応付けしておき保険契約の際に自動になされるような構成であってもよいし、契約内容から代理店が判断するような構成であってもよい。そして、特定された約款番号を合成したデータが登録される。ここでは”００”及び”０１”から合成された”０００１”が、契約内容の列１０８に登録される。従って、契約内容の列１０８の値を使用した処理を行う際には、約款番号の桁数である例えば２桁づつに区切って処理を行うような構成となっている。
【００８１】
交付約款の列１１０には、顧客に対して今回交付すべき（未だ交付済みでない）約款又は当該契約時に交付した約款を表すデータが登録される。なお、契約内容の列１０８と同様に、約款番号によってデータが構成される。このように、今回交付すべき約款は、交付が必要な約款の一部もしくは全部を含むことになる。また、約款交付済フラグの列１１２には、レコード生成時には”０”が設定され、送信した約款データを顧客が受信したと判定された場合には”１”が設定される。
【００８２】
顧客交付済約款の列１１４には、当該顧客に対してこれまでに交付済みである約款の番号が全て登録される。例えば、これまでの契約に対応するレコードの顧客交付済約款の列１１４の値が”０００１”であり、保険の異動が発生し、今回の保険契約の異動に対応するレコードの交付約款の列１１０の値が”０５”であった場合には、今回の契約に対応するレコードの生成時には、顧客交付済約款の列１１４の値は”０００１”が登録されているが、約款交付済フラグの列１１２の値が”１”に設定される際に顧客交付済約款の列１１４の値は”０００１０５”に更新される。すなわち、顧客は既に約款番号”００”及び”０１”に対応する約款の交付を受けており、今回は追加で約款番号”０５”に対応する約款の交付を受けたので、これまでに当該顧客が交付を受けた約款は”００”、”０１”及び”０５”であるということを表している。そのため、交付約款の列１１０の値を登録する際には、当該顧客の前回の契約に対応するレコードの顧客交付済約款の列１１４の値と、今回の契約に対応するレコードの契約内容の列１０８の値とから今回交付すべき約款番号を特定して登録する。
【００８３】
契約計上日／異動承認日の列１１６には、契約を計上した日付又は保険の異動が確定した日付が登録される。また、削除フラグの列１１８には、レコード生成時には”０”が設定（又は空白と）され、保険の異動処理などにより、これまでの契約に対応するレコードを無効にする場合には”１”が設定される。なお、不要になったレコードを削除するような構成であってもよい。
【００８４】
次に、図１２乃至図１４を用いて図１０に示したシステムの動作を説明する。
【００８５】
契約計上サーバ２５５の制御部は、代理店（例えば代理店端末２７）から顧客の保険契約に関するデータを通信部を介して受信し、一旦記憶装置に格納する（ステップＳ９１）。契約計上サーバ２５５の制御部（以下、契約計上サーバ２５５における処理の説明において、単に契約計上サーバ２５５と表示したときは、制御部による処理を意味する。また契約計上サーバ２５５（制御部）と表示する場合もある。）は、契約内容から、交付が必要な約款ファイルを特定する（ステップＳ９３）。この交付すべき約款ファイルの特定については、特約等の契約内容の設定と必要な約款を対応付けしておき保険契約申込の際に自動になされるような構成であってもよいし、契約内容から代理店が判断して契約計上サーバ２５５に送信するデータに含めておくような構成であってもよい。
【００８６】
また、契約計上サーバ２５５（制御部）が代理店端末２７から通信部を介して受信したデータには、例えば新規の保険契約か既契約保険の異動かを判定することができる情報が含まれており、契約計上サーバ２５５（制御部）は、当該保険契約は保険の異動であるかどうかを判定する（ステップＳ９５）。新規の保険契約か既契約保険の異動かの判定は、例えば既存契約の証券番号データが含まれていなければ新規の保険契約であると判断し、既存契約の証券番号データが含まれていれば異動であると判断することができる。あるいは、新規の保険契約と既契約保険の異動のぞれぞれに固有のコード番号を保持させてもよい。契約計上サーバ２５５（制御部）は、これらデータの有無やデータの内容に基づき、新規の保険契約か既契約保険の異動かの判定を行う。
【００８７】
異動であると判定した場合、契約計上サーバ２５５（制御部）は、受信したデータに含まれる契約番号をキーとして契約管理ＤＢ２５５１の契約管理テーブル（図１１）を検索し、既契約保険のレコードを特定する（ステップＳ９７）。特定されたレコードの顧客交付済約款の列１１４の値から、顧客に交付済みの約款ファイルを特定する（ステップＳ９９）。契約計上サーバ２５５（制御部）は、ステップＳ９３において特定された契約内容に対応した約款ファイルの情報と、ステップＳ９９において特定された顧客に交付済みの約款ファイルの情報とから、今回顧客に交付すべき約款ファイルを特定する（ステップＳ１０１）。そして、ステップＳ９７において特定されたレコードの削除フラグの列１１８の値を”１”に更新する（ステップＳ１０３）。また、ステップＳ９９において特定された顧客に交付済みの約款ファイルの情報を顧客交付済約款の列１１４に含むレコードを生成し、契約管理ＤＢ２５５１の契約管理テーブル（図１１）に新規に格納する（ステップＳ１０５）。
【００８８】
例えば、保険の特約の追加（対応する約款の番号は”０２”）が発生し、今回の契約内容に対応する交付が必要な約款（約款番号）が”００”、”０１”及び”０２”であるとする。既契約内容に対応して交付済みの約款（約款番号）が”００”及び”０１”である場合、今回顧客に対して送信すべき約款（約款番号）は”０２”となる。ここで、契約計上サーバ２５５（制御部）は、顧客に交付済みの約款（約款番号）が”００”及び”０１”であることを示す新しいレコードをＤＢに格納しておき、今回交付すべき”０２”で示される約款を顧客が受信したことが確認された時に、顧客に交付済みの約款（約款番号）の情報に”０２”が含まれるようにレコードを更新する。
【００８９】
一方、ステップＳ９５において異動ではないと判定した場合、契約計上サーバ２５５（制御部）は、契約管理ＤＢ２５５１の契約管理テーブル（図１１）にレコードを新たに生成して格納する（ステップＳ１０７）。証券番号の列１００、顧客番号の列１０４、顧客メール・アドレスの列１０６、契約内容の列１０８及び契約計上日／異動承認日の列１１６にはステップＳ９１において受信したデータに基づいた値が記録され、約款交付済フラグの列１１２及び削除フラグの列１１８には初期値として”０”が記録される。また、証券ファイル保存場所の列１０２には保険証券データの物理的な格納場所が記録される。なお、当該顧客に対して交付済みの約款はないため、顧客交付済約款の列１１４にはＮＵＬＬ値が記録されるか又は何も記録されない。そして、今回交付すべき約款は契約内容に対応した全ての約款（すなわち交付が必要な約款）であるため、交付約款の列１１０には契約内容の列１０８と同じ値が記録される。
【００９０】
今回交付すべき約款（又はステップＳ１０７経由の場合には交付が必要な約款）が特定できたら、契約計上サーバ２５５（制御部）は、顧客が約款データの受信が可能かどうかを判定する（ステップＳ１０８）。そして、約款データを受信不可能であると判定した場合（ステップＳ１０８：Ｎｏルート）、契約計上サーバ２５５（制御部）は図示しないプリンタ等に約款データの印刷指示を発することにより、約款の印刷処理を行う（ステップＳ１０９）。顧客が約款データを受信可能であると判定した場合（ステップＳ１０８：Ｙｅｓルート）、契約計上サーバ２５５（制御部）は約款データ及び保険証券データの顧客への送信方法を判定する（ステップＳ１１０）。送信方法は予め固定的に設定してもよいし、顧客毎に異なる方法を採用してもよい。メールの添付ファイルで送信すると判定された場合には、端子Ｄを介して図１３の処理に移行する。また、メールの添付ファイルでは送信しないと判定された場合には、顧客にファイルをダウンロードしてもらうため、保険証券番号毎のダウンロード用ページのＵＲＬを生成してＵＲＬ記憶部に格納し（ステップＳ１１１）、端子Ｅを介して図１４の処理に移行する。
【００９１】
次に、端子Ｄを介して遷移した処理について図１３を用いて説明する。
【００９２】
契約計上サーバ２５５（制御部）は通信部を介して、今回顧客に交付すべき約款データ（複数の約款データが存在する場合にはそれらを合成した約款ファイルとしての約款データである場合もある）及び保険証券又は異動承認書をメールの添付ファイルとして顧客（例えばユーザ端末２３を使用する）に送信する（ステップＳ１１３）。ユーザ端末２３は、顧客の指示に応じて、契約計上サーバ２５５からのメールを受信して表示装置に表示する（ステップＳ１１５）。そしてユーザ端末２３は、メールを受信したことを通知するために、開封確認メールを契約計上サーバ２５５に送信する（ステップＳ１１７）。ここで、開封確認メール送信の仕組みとしては、メーラの機能を使用するような構成であってもよいし、例えば開封確認ボタンを顧客が押すことによってメールが送信されるような構成であってもよい。そしてユーザ端末２３は、自動的に又は顧客の操作に従い、図示しないユーザ端末２３のＨＤＤ等の記憶装置に、受信したメールの添付ファイル（保険証券又は異動承認書データ及び約款データ）を格納する（ステップＳ１１９）。
【００９３】
一方で契約計上サーバ２５５（制御部）は、ユーザ端末２３からの開封確認メールを通信部を介して受信（ステップＳ１２１）した場合には、対応する契約管理テーブル（図１１）のレコードを特定し、約款交付済フラグの列１１２の値を”１”に設定し、顧客交付済約款の列１１４の値を更新する（ステップＳ１２３）。顧客交付済約款の列１１４の値については、レコード生成時に既契約のデータ（交付済みの約款番号）が登録されていたのに対し、今回交付した約款番号を合せたものを更新データとする。例えば、交付約款の列１１０の値が”０５”で、顧客交付済約款の列１１４の値が”０００１”であった場合、ステップＳ１２３において顧客交付済約款の列１１４の値を”０００１０５”に更新する。また例えば、交付約款の列１１０の値が”０００１”で、顧客交付済約款の列１１４の値がＮＵＬＬ値であったか又は何も登録されていなかった場合、ステップＳ１２３において顧客交付済約款の列１１４の値を”０００１”に更新する。
【００９４】
次に、端子Ｅを介して遷移した処理について図１４を用いて説明する。
【００９５】
契約計上サーバ２５５（制御部）は、ステップＳ１１１の処理で生成した保険証券又は異動承認書及び約款ダウンロード用ページのＵＲＬを通信部を介して顧客（例えばユーザ端末２３を使用する）に送信する（ステップＳ１２５）。ユーザ端末２３は、顧客の指示に応じて、契約計上サーバ２５５からのメールを受信して表示装置に表示する（ステップＳ１２７）。表示されたＵＲＬを、顧客がクリックしたりＷｅｂブラウザのアドレス欄に入力した場合には、ユーザ端末２３は顧客からの操作を受け付け、約款ダウンロード用ページ・データの要求を契約計上サーバ２５５に送信する（ステップＳ１２９）。なお、ユーザ端末２３が送信するデータは、Ｗｅｂページを表示するためのものであり、実際には図示しないＷｅｂサーバに対して送信する。そしてＷｅｂサーバは、契約計上サーバ２５５のＨＤＤ２５５５や契約計上サーバ２５５が管理する契約管理ＤＢ２５５１にアクセスして処理を行う。ここでは説明を分かりやすくするために、サーバ側の処理は契約計上サーバ２５５（制御部）が行うものとしている。
【００９６】
契約計上サーバ２５５（制御部）は、ユーザ端末２３から保険証券又は異動承認書及び約款ダウンロード用ページ・データの要求を通信部を介して受信する（ステップＳ１３１）。契約計上サーバ２５５（制御部）は、保険証券又は異動承認書データを当該顧客以外に参照させないために、例えばパスワードによる認証処理を行う（ステップＳ１３３）。パスワードは例えば代理店等から顧客に提供されるものとする。また、生年月日を仮パスワードとしてもよい。また、契約計上サーバ２５５の通信部を介して行われる契約計上サーバ２５５（制御部）とユーザ端末２３との通信には、例えばＳＳＬ（Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔ　Ｌａｙｅｒ）等の暗号化通信を利用するような構成であってもよい。
【００９７】
また、保険証券又は異動承認書及び約款ダウンロード用ページのＵＲＬは、ステップＳ１１１において保険証券番号毎に生成されているため、逆にＵＲＬから保険証券番号を特定することができる。契約計上サーバ２５５（制御部）は、受信したＵＲＬから保険証券番号を特定する（ステップＳ１３５）。さらに、特定した保険証券番号を用いて契約管理ＤＢ２５５１を検索し、契約管理テーブル（図１１）のレコードを特定する。特定されたレコードの交付約款の列１１０の値から、今回交付すべき約款を特定する（ステップＳ１３７）。例えば、特定されたレコードの交付約款の列１１０の値が”０００１”であった場合には、今回交付すべき約款の番号は、”００”及び”０１”である。
【００９８】
契約計上サーバ２５５（制御部）は、保険証券又は異動承認書及び約款ダウンロード用ページ・データを生成し、通信部を介してユーザ端末２３に送信する（ステップＳ１３９）。保険証券又は異動承認書及び約款ダウンロード用ページには、契約管理テーブル（図１１）の証券ファイル保存場所の列１０２の値を用いて生成されたリンク情報が含まれる。ユーザ端末２３は、契約計上サーバ２５５から保険証券又は異動承認書及び約款ダウンロード用ページ・データを受信し、表示装置に表示する（ステップＳ１４１）。
【００９９】
ユーザ端末２３は、顧客による保険証券又は異動承認書及び約款ダウンロードの操作を受け付けた場合には、保険証券又は異動承認書及び約款ダウンロード要求を契約計上サーバ２５５に対して送信する（ステップＳ１４３）。契約計上サーバ２５５（制御部）は、ユーザ端末２３から保険証券又は異動承認書及び約款ダウンロード要求を通信部を介して受信する（ステップＳ１４５）。そして受信したデータに基づいて契約計上サーバ２５５（制御部）は、今回交付すべき約款データを１つのファイルに合成して保険証券又は異動承認書データと共にユーザ端末２３に対して通信部を介して送信する（ステップＳ１４７）。
【０１００】
なお、保険証券又は異動承認書データと約款データとは別ファイルとして送信するが、対応関係にあるため、一回の送信処理で両方のファイルを顧客に送信できることが望ましい。例えば図示しないが保険証券又は異動承認書及び約款ダウンロード用ページに含まれるダウンロード・ボタンが顧客によって押された場合には、保険証券又は異動承認書ファイルと今回交付すべき約款ファイルと、の両方を顧客に送信するような構成であってもよい。契約計上サーバ２５５（制御部）は、ユーザ端末２３への送信が完了した時点で、顧客に対して約款を送信したことを示す記録として、対応する契約管理テーブル（図１１）のレコードを特定し、約款交付済フラグの列１１２の値を”１”に設定し、顧客交付済約款の列１１４の値を更新する（ステップＳ１４９）。
【０１０１】
一方、ユーザ端末２３は、契約計上サーバ２５５から保険証券又は異動承認書及び約款ファイルを受信する（ステップＳ１５１）。そしてユーザ端末２３は、自動的に又は顧客の操作に従い、図示しないユーザ端末２３のＨＤＤ等の記憶装置に、受信した保険証券又は異動承認書及び約款ファイルを格納する（ステップＳ１５３）。
【０１０２】
ところで、何らかの原因により、顧客が約款を受信したという確認がとれなかった場合、約款等を紙（冊子）で顧客に対して送付するための処理を実施する必要がある。そのため、契約計上サーバ２５５（制御部）は、ステップＳ１０１で特定された約款及び当該異動に関する異動承認書を異動承認書印刷機などを使用して印刷するための指示を印刷機に対して発する。または、保険会社によって、既存の約款冊子が印刷された異動承認書と共に封筒に封入される。
【０１０３】
なお、契約計上サーバ２５５（制御部）は、約款データが交付済みであるかどうかの確認を、保険契約又は異動の計上時点若しくはその他の任意の時点において行うことができる。例えば、今回交付すべき約款データを送信した時や保険契約又は異動を計上した時などに基づいて特定される、所定の時点において確認することができる。例えば、約款データを送信した時もしくは計上した時から所定時間（例えば２４時間）が経過した時点や、約款データを送信した時もしくは計上した時の含まれる日から２日後の午後３時（翌々日の午後３時）になった時点など、あらかじめ設定された所定の時点において確認する。
【０１０４】
約款データを送信した時もしくは計上した時から所定時間（例えば２４時間）が経過した時点に確認する場合は、図示しないが契約管理テーブル（図１１）において、約款データを送信した時もしくは計上した時刻データが契約計上サーバ２５５（制御部）によって記録され、かつそれ以降の経過時間が同様に記録される。また、翌々日の午後３時などといった所定の時点において確認する場合には、図示しないが契約管理テーブル（図１１）において、約款データを送信した時もしくは計上した時刻データが契約計上サーバ２５５（制御部）によって記録され、それと共に予め設定されたルールに基づいて、確認すべき時点のデータが記録される。そして、契約計上サーバ２５５（制御部）は、契約計上サーバ２５５におけるシステム時間を取得して、経過時間を測定し、所定時間が経過した時点で上で述べたような必要な処理を実施する。
【０１０５】
また、既契約に対応して交付済みであった約款データの内、異動に伴って適用されなくなったものについては、契約計上サーバ２５５（制御部）は、通信部を介して顧客にその旨の通知をする。例えば、契約内容の列１０８の値が”０００１０２０３”で、交付約款の列１１０および顧客交付済約款の列１１４の値も”０００１０２０３”であり、そして約款交付済フラグの列１１２の値が”１”であった場合（契約管理テーブル（図１１）の証券番号ｘｘｘｚｚｚ００１２のケース）に、後日、異動によって、「運転者家族限定特約（約款番号「０１」）」が削除されることとなったとする。この場合、契約計上サーバ２５５（制御部）は、”０１”に対応する約款が適用されなくなることを知らせるために、図１５に例として示した内容の通知を行う。図１５には、契約加入に対するお礼の言葉、送信内容の説明文、対象の保険契約、適用とならない当該約款の内容等が記載されている。
【０１０６】
このようにすると、保険の異動などの原因によって、約款を交付済みの顧客に対してさらに約款を交付するような場合に、顧客に交付済みの約款データを特定することにより、重複した約款データの送信を避けることができる。そのため、保険会社や顧客は通信及び処理負荷の削減を図ることができる。また、異動によって適用されなくなった約款について、顧客に通知することで、顧客の契約内容に関する誤解を防止することができる。さらに、約款データとともに保険証券又は異動承認書データも送信することにより、保険会社及び顧客の、保険証券及び約款の管理が楽になる。また、顧客が何らかの理由により保険証券及び約款を受信しなかった場合又は受信できなかった場合にも、紙及び冊子を郵送するなどの対応処理が可能となる。
【０１０７】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１及び図１０に示したシステム構成は一例であって他の構成であっても図１及び図１０に示した実施パターンを実現することができればよい。例えばＤＢ構成についても一例であって同様のデータを格納するためであれば、別の構成を採用するようにしてもよい。また、必要に応じて項目を追加又は削除するようにしてもよい。例えば約款テーブル（図２）については、同じ特約でも約款の改定等があれば新しい約款番号を付与して登録しておくような構成であってもよい。また、各サーバは１台による構成に限らず、複数台による構成であってもよい。例えば契約計上サーバ１５５や契約計上サーバ２５５が複数台で構成されていてもよい。また、保険証券ファイルを顧客に送信する際には、ファイルを暗号化して送信するような構成であってもよい。
【０１０８】
また、本実施の形態をまとめると以下のようになる。
【０１０９】
本実施の形態の第１の態様に係る、保険約款交付のための情報処理方法は、顧客の保険契約に関連するデータと顧客の属性データとを受信した場合、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定する約款特定ステップと、受信した顧客の属性データに基づき、約款特定ステップにおいて特定された約款の約款データを顧客が受信可能か否かを判断する受信可能性判断ステップと、受信可能性判断ステップにおいて受信可能であると判断された顧客に対して、約款特定ステップにおいて特定された約款の約款データを顧客宛に送信する送信ステップとを含む。これにより、ネットワーク対応が可能な顧客にはネットワークを介して約款データを送信することができ、保険会社は省力化を図ることができる。
【０１１０】
また、本実施の形態の第１の態様において、受信可能性判断ステップにおいて受信不可能であると判断された顧客に対して、約款特定ステップにおいて特定された約款の約款データを印刷処理する印刷処理ステップをさらに含むような構成であってもよい。ネットワーク対応が不可能な顧客等には印刷処理ステップにおいて印刷された約款を送付するようにするものである。なお、この場合においても交付が必要な約款だけが印刷されるので、消費資源の減量を図ることができるようになる。
【０１１１】
また、上で述べた約款特定ステップが、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定する第１特定ステップと、予め記憶装置に格納された顧客のデータに基づき当該顧客に交付済みの約款を特定する第２特定ステップと、第１特定ステップにおいて特定された約款と、第２特定ステップにおいて特定された約款とを用いて今回交付すべき約款を特定する第３特定ステップとを含み、上で述べた送信ステップにおいて、第３特定ステップにおいて特定された今回交付すべき約款の約款データを顧客宛に送信するような構成とすることも可能である。このように顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、通信負荷を減らすことができるようになる。
【０１１２】
本実施の形態の第２の態様に係る、保険約款交付ための情報処理方法は、顧客の保険契約に関連するデータを受信した場合、受信した保険契約に関連するデータに基づき顧客に交付が必要な約款を特定する第１特定ステップと、予め記憶装置に格納された顧客のデータに基づき当該顧客に交付済みの約款を特定する第２特定ステップと、第１特定ステップにおいて特定された約款と、第２特定ステップにおいて特定された約款とを用いて今回交付すべき約款を特定する第３特定ステップと、第３特定ステップにおいて特定された今回交付すべき約款の約款データを顧客宛に送信する送信ステップとを含む。すなわち、顧客に交付が必要な約款の約款データのうち、当該顧客に対して既に交付済みの約款の約款データを除いて送信することにより、重複した約款データを送信しないようにする。これにより、約款データを電子ファイルで送信する際には通信負荷の軽減を図ることができる。また、保険会社や顧客が約款データを紙に印刷するような場合には消費資源の削減を図ることができる。
【０１１３】
本実施の形態の第１及び第２の態様において、第２特定ステップにおいて特定された約款のうち、第１特定ステップにおいて特定された約款に含まれていない、不適用とされる約款を特定する不適用約款特定ステップをさらに含むような構成であってもよい。
【０１１４】
さらに、上で述べた不適用約款特定ステップにおいて特定された不適用とされる約款についての情報を含む約款適用取消情報を生成する取消情報生成ステップと、生成された約款適用取消情報を顧客宛に送信するステップとをさらに含むような構成であってもよい。これにより、顧客は読むべき約款を正確に把握できるようになる。
【０１１５】
また、本実施の形態の第１及び第２の態様において、受信した保険契約に関連するデータは、顧客の保険契約申込データ又は保険契約計上データである場合もある。これにより、例えば代理店端末から保険契約申込又は保険契約計上を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、以前に保険契約申込を受けて交付した約款の約款データの一部又は全部を、再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【０１１６】
また、本実施の形態の第１及び第２の態様において、受信した保険契約に関連するデータは、顧客の保険異動データである場合もある。これにより、代理店端末から保険異動要求を受け付けた際に、未だ交付済みでない約款の約款データのみを顧客に送信することが可能となる。すなわち、既契約保険の契約の際に交付した約款の約款データの一部又は全部を再び同じ顧客に送信するようなことはせず、追加で交付が必要な約款の約款データのみを顧客に送信することが可能となる。
【０１１７】
さらに、本実施の形態の第１及び第２の態様において、保険証券データを顧客宛に送信するステップをさらに含むような構成であってもよい。顧客は保険証券のデータ及び保険証券に対応した約款データを取得することができる。
【０１１８】
また、上で述べた本実施の形態の第１及び第２の態様における送信ステップにおいて、交付が必要な約款の約款データ又は今回送付すべき約款の約款データをメールの添付ファイルとして顧客に対して送信する、又は顧客のダウンロード要求により今回送付すべき約款の約款データを送信するような構成であってもよい。保険会社及び顧客のシステム環境や通信環境に合わせた形態での約款送信が可能となる。
【０１１９】
さらに、本実施の形態の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データが複数ある場合、１つの約款ファイルに合成し、約款ファイル記憶部に格納するステップと、合成された約款ファイルのダウンロード用リンク情報を生成するステップと、生成されたダウンロード用リンク情報を顧客に対して通知するステップとをさらに含み、顧客がダウンロード用リンク情報を用いてダウンロードを指示した場合、送信ステップが実行されるような構成であってもよい。顧客は、約款ダウンロード用ホームページから今回の契約又は異動に対応した約款データを一括でダウンロードすることが可能となる。これにより、約款交付の管理も簡単になる。
【０１２０】
また、本実施の形態の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データを顧客が受信したと判定された場合、顧客のデータに、交付が必要な約款の約款データ又は今回送付すべき約款の約款データが交付済みであることを表す情報を追加するステップをさらに含むような構成であってもよい。これにより、顧客に対して既に交付された約款の約款データを特定することが可能となる。また一方で、約款データを送信してから又はダウンロードを要求するメールを送信してから所定の期間、交付済みであることを表す情報が顧客のデータに追加されなかった場合には、約款を紙に印刷して郵送するような構成とすることも可能になる。
【０１２１】
さらに、本実施の形態の第１及び第２の態様において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データを顧客に送信した時、又は保険契約に関連するデータに基づいて保険契約が計上された時、に基づいて特定される時点において、交付が必要な約款の約款データ又は今回交付すべき約款の約款データを顧客が受信したと判定されない場合、当該約款データを印刷処理するステップをさらに含むような構成であってもよい。これにより、何らかの理由で受信されなかった約款を別途顧客に送付するためである。
【０１２２】
【発明の効果】
以上述べたように、本発明によれば、顧客に対して適切な内容の約款交付を適切な方法にて行うための情報処理技術を提供することができた。
【図面の簡単な説明】
【図１】本発明の一実施の形態におけるシステム概要図である。
【図２】約款テーブルの構成及び格納されるデータの一例を示す図である。
【図３】交付管理テーブルの構成及び格納されるデータの一例を示す図である。
【図４】本発明の一実施の形態における処理フロー（その１）を示す図である。
【図５】本発明の一実施の形態における処理フロー（その２）を示す図である。
【図６】本発明の一実施の形態における処理フロー（その３）を示す図である。
【図７】本発明の一実施の形態における処理フロー（その４）を示す図である。
【図８】本発明の一実施の形態における処理フロー（その５）を示す図である。
【図９】約款の不適用通知の一例を示す図である。
【図１０】本発明の実施の形態２におけるシステム概要図である。
【図１１】契約管理テーブルの構成及び格納されるデータの一例を示す図である。
【図１２】本発明の実施の形態２における処理フロー（その１）を示す図である。
【図１３】本発明の実施の形態２における処理フロー（その２）を示す図である。
【図１４】本発明の実施の形態２における処理フロー（その３）を示す図である。
【図１５】約款の不適用通知の一例を示す図である。
【符号の説明】
１１　ネットワーク　　１３　ユーザ端末
１５　保険会社　　１７　代理店端末
１５５　契約計上サーバ　　１５５１　約款交付管理ＤＢ
１５５３　保険証券印刷機　　１５５５　契約計上サーバＨＤＤ
２１　ネットワーク　　２３　ユーザ端末
２５　保険会社　　２７　代理店端末
２５５　契約計上サーバ　　２５５１　契約管理ＤＢ
２５５５　契約計上サーバＨＤＤ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an information processing technology for issuing insurance contracts.
[0002]
[Prior art]
For example, JP-A-2002-133098 discloses the following technique. That is, in the insurance contract procedure method and system, the insurance company or agent transmits the contract information to the customer terminal via a communication network such as the Internet based on the insurance contract application information from the customer. Further, of the contract information transmitted to the customer terminal, only the terms and special provisions necessary for the contracted insurance content are transmitted. In addition, the insurance company or the agency (including an intermediary, an intermediary) allows the customer to view the contract information transmitted to the customer terminal via a communication network such as the Internet in response to the customer's request.
[0003]
[Problems to be solved by the invention]
However, the above-described conventional technology does not consider a method of issuing a contract when there is a modification of an insurance contract application or a transfer. In other words, even if there is duplication in the terms and conditions data to be delivered to the customer, including the common insurance contract contents, all necessary terms and conditions data for the latest insurance contract are transmitted. Therefore, for example, when only one special contract is added, the contract data corresponding to the entire insurance contract is transmitted, although it is sufficient to issue the contract data only for the relevant part. In addition, even if the customer has already acquired the corresponding clause data, such as when the number of special agreements has been reduced, and there is a need to notify that the terms and conditions will not be applied, there is a means for providing a corresponding notice. I didn't. In this way, the configuration is such that it is difficult for an insurance company or a customer to reduce communication and processing loads.
[0004]
Further, even if data such as a clause is transmitted to a customer via a communication network such as the Internet, some customers may not be able to cope with the network. Therefore, it is necessary for some customers to send the terms and conditions by a separate method such as mailing.
[0005]
Accordingly, an object of the present invention is to provide an information processing technique for issuing a clause with appropriate contents to a customer by an appropriate method.
[0006]
[Means for Solving the Problems]
An information processing method for issuing insurance contracts according to a first aspect of the present invention includes a receiving step of receiving data relating to an insurance contract of a customer and attribute data of the customer, and storing the data in a storage device; In the terms and conditions specifying step which needs to be delivered to the customer based on the data related to the insurance contract stored in the storage device, and storing the identification data of the terms and conditions in the required terms and identification data storage unit; Reception possibility to judge whether or not the customer can receive the clause data of the clause specified in the clause specifying step and the identification data stored in the required clause identification data storage unit based on the attribute data of the customer stored in the device. A determination step, and for the customer determined to be receivable in the receivability determination step, The main clause identification data storage unit and a transmission step of transmitting clause data covenants identification data is stored. Thereby, the agreement data can be transmitted to the network-capable customer via the network, and the insurance company can save labor.
[0007]
Further, according to the first aspect of the present invention, the identification data is stored in the required agreement identification data storage unit in the agreement identification step for the customer determined to be unreceivable in the reception possibility determination step. The method may further include a print processing step of performing print processing on the article data of the article. The terms and conditions printed in the print processing step are sent to a customer or the like who cannot support the network. In this case, since only the clauses that need to be issued are printed, the amount of resources consumed can be reduced.
[0008]
Further, the above-mentioned terms specifying step specifies the terms which need to be issued to the customer based on the received data related to the insurance contract, and stores the identification data of the terms in the necessary terms identification data storage unit. Searching the customer data storage unit using the customer identification data included in the data stored in the storage device in the receiving step and identifying the terms and conditions already issued to the customer based on the read customer data. A second specifying step of storing the identification data of the terms and conditions already issued to the customer in the issued terms and conditions identification data storage unit; and identifying the terms and conditions specified in the first specification step and stored in the necessary terms and conditions identification data storage unit. Using the data and the identification data of the terms and conditions issued to the customer and specified in the second specifying step and stored in the issued terms and conditions identification data storage unit A third specifying step of specifying the terms and conditions to be issued this time, and storing the identification data of the terms and conditions in the issued terms and conditions identification data storage unit. It is also possible to adopt a configuration in which the agreement data of the agreement to be issued this time, in which the identification data is stored in the identification data storage unit, is transmitted to the customer. As described above, the communication load can be reduced by transmitting the terms and conditions data of the terms and conditions that need to be delivered to the customer, excluding the terms and conditions data of the terms and conditions already delivered to the customer.
[0009]
According to a second aspect of the present invention, there is provided an information processing method for issuing insurance contracts, comprising the steps of: receiving data related to a customer's insurance contract and storing the data in a storage device; A first specifying step of specifying the terms and conditions that need to be provided to the customer based on the data related to the insurance contract, and storing the identification data of the terms and conditions in the necessary terms and conditions identification data storage unit; and a data stored in the storage device in the receiving step. Identify the terms and conditions that have been issued to the customer based on the data of the customer that has been read by searching the customer data storage unit using the customer identification data included in the identification data of the terms and conditions that have been issued to the customer. A second specifying step to be stored in the issued terms and conditions identification data storage unit, and a terms and conditions specified in the first specification step and stored in the necessary terms and conditions identification data storage unit Using the identification data and the identification data of the terms and conditions that have been issued to the customer and specified in the second specification step and stored in the issued terms and conditions identification data storage unit, the terms and conditions to be delivered this time are specified, and the identification data of the terms and conditions is specified. A third specifying step of storing the terms and conditions in the terms and conditions identification data storage unit, and transmitting to the customer the terms and conditions data of the terms and conditions to be delivered this time specified in the third specifying step and having the identification data stored in the terms and conditions specification data storage unit Transmitting step. That is, duplicate agreement data is prevented from being transmitted to the customer by excluding the agreement data of the agreement already issued from the agreement data of the agreement requiring delivery to the customer. As a result, it is possible to reduce the communication load when transmitting the clause data in an electronic file. Further, when the insurance company or the customer prints the clause data on paper, it is possible to reduce the consumption resources.
[0010]
In the first and second aspects of the present invention, of the agreement identification data stored in the issued agreement identification data storage unit in the second identification step, the identification data stored in the required agreement identification data storage unit in the first identification step The method may further include a non-applicable agreement specifying step of storing, in the non-applicable agreement identification data storage unit, identification data of an article that is not applied, which is not included in the identification data of the article.
[0011]
Further, in the above-mentioned non-applicable clause identification step, the contract application application cancellation information including information on the clause corresponding to the article identification data stored in the non-applicable clause identification data storage is generated and stored in the cancellation information storage. The method may further include a step of generating cancellation information, and a step of transmitting the agreement application cancellation information stored in the cancellation information storage unit to the customer. This allows the customer to know exactly which terms to read.
[0012]
In the first and second aspects of the present invention, the data related to the insurance contract stored in the storage device may be customer insurance contract application data or insurance contract recording data. Thus, for example, when an insurance contract application or insurance contract accounting is received from the agency terminal, it is possible to transmit only the clause data of the terms and conditions that have not been issued to the customer. In other words, some or all of the terms and conditions data of the terms and conditions previously issued in response to the insurance contract application will not be transmitted to the same customer again, and only the terms and conditions data of the terms and conditions that need to be additionally delivered to the customer. It becomes possible to transmit.
[0013]
In the first and second aspects of the present invention, the data related to the insurance contract stored in the storage device may be customer insurance transfer data. Thus, when an insurance transfer request is received from the agent terminal, it becomes possible to transmit only the clause data of the terms and conditions that have not been issued to the customer. In other words, some or all of the terms and conditions data of the terms and conditions issued at the time of the existing insurance contract will not be sent to the same customer again, but only the terms and conditions data of the terms and conditions that need to be additionally delivered to the customer. It is possible to do.
[0014]
Further, in the first and second aspects of the present invention, the method may further include transmitting, to the customer, insurance policy data generated based on the data related to the insurance contract stored in the storage device. The customer can obtain insurance policy data and clause data corresponding to the insurance policy.
[0015]
Further, in the first and second aspects of the present invention described above, in the transmission step, the terms and conditions data of the terms and conditions to be delivered or the terms and conditions data of the terms and conditions to be sent this time are transmitted to the customer as an attached file of e-mail. Alternatively, the agreement data of the agreement to be sent this time may be transmitted according to a download request of the customer. Terms and conditions can be transmitted in a form that matches the system environment and communication environment of insurance companies and customers.
[0016]
Further, in the first and second aspects of the present invention, when there are a plurality of clause data of a clause requiring a grant or a plurality of clause data of a clause to be delivered this time, they are combined into one clause file and stored in the clause file storage unit. Generating the link information for download of the agreement file stored in the agreement file storage unit, storing the link information in the link information storage unit, and transmitting the download link information stored in the link information storage unit to the customer. The transmitting step may be executed when the customer instructs the download using the download link information. The customer can collectively download the agreement data corresponding to the contract or the transfer from the agreement download homepage. This also simplifies the management of terms and conditions.
[0017]
In the first and second aspects of the present invention, when it is determined that the customer has received the clause data transmitted in the transmitting step, the customer identification data included in the data stored in the storage device is used. The method may further include a step of adding information indicating that the article data has been issued to the customer data read by searching the customer data storage, and storing the information in the customer data storage. Thereby, it becomes possible to specify the clause data of the clause already issued to the customer. On the other hand, if the information indicating that the delivery has been completed is not added to the customer data for a predetermined period after sending the agreement data or sending the download request email, the agreement is printed It is also possible to adopt a configuration in which the information is printed and mailed.
[0018]
Further, in the first and second aspects of the present invention, based on when the contract data is transmitted to the customer in the transmitting step or when the insurance contract is recorded based on the data related to the insurance contract stored in the storage device. If it is not determined at the specified point in time that the customer has received the agreement data transmitted in the transmission step, a step of printing the agreement data may be further included. This is in order to separately send the terms and conditions that have not been received for some reason to the customer.
[0019]
It is also possible to create a program for causing a computer to execute the information processing method according to the present invention, and the program includes, for example, a storage medium such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, and a hard disk. Alternatively, it is stored in a storage device. Also, it may be distributed via a network. The data being processed is temporarily stored in the memory of the computer.
[0020]
BEST MODE FOR CARRYING OUT THE INVENTION
[Embodiment 1]
FIG. 1 shows a system configuration diagram according to the first embodiment of the present invention. For example, the user terminal 13, which is a personal computer, has a mailer function and a Web (Web) browser function (not shown), and can transmit and receive mails wirelessly or by wire, and can browse a homepage by connecting to the Internet. It is possible.
[0021]
For example, the network 11 such as the Internet includes one or more user terminals 13 and one or more contract accounting servers 155 for performing insurance contract accounting processing, for example, a personal computer having a mailer function and an insurance contract application function. Is connected to one or more agency terminals 17.
[0022]
The contract accounting server 155 is connected to an agreement delivery management database (DB) 1551 storing data related to the agreement delivery status to the customer, and an insurance policy printing machine 1553 for printing insurance policies. Further, in a hard disk drive (HDD) 1555 of the contract accounting server 155, contract data for delivery to the customer is stored, for example, as a contract file. Depending on the method of classifying insurance contracts and the types of special contracts, there may be any number of corresponding covenant files. The HDD 1555 also functions as a storage device for other data.
[0023]
The insurance company 15 has a Web server (not shown), which manages a homepage for downloading the article file. In addition, a mail server (not shown) transmits mail to the customer. In addition, a system for performing insurance business processing such as an insurance contract DB, a customer management DB, and an agency DB managed by the contract accounting server 155 or another server (not shown) is installed.
[0024]
The contract accounting server 155 includes a control unit and a communication unit (not shown). The details of the processing of the control unit will be described later in the description of the processing flow. For example, the processing of the management of the agreement delivery management DB 1551 and the management of the agreement file and other data stored in the HDD 1555 are performed. The communication unit is a communication interface for performing processing such as transmission of a clause file to a customer or the like.
[0025]
It should be noted that the contract accounting server 155 and the insurance policy printing machine 1553 do not necessarily need to be installed inside the insurance company 15, and may be installed outside by outsourcing or the like as long as the same functions can be realized. .
[0026]
The communication via the network 11 uses devices and functions necessary for Internet connection and mail transmission and reception, such as a domain name server (DNS), a mail server, and a firewall (not shown). And
[0027]
FIGS. 2 and 3 show an example of a table configuration of the agreement provision management DB 1551 and stored data. The clause delivery management DB 1551 includes, for example, a clause table shown in FIG. 2 and a delivery management table shown in FIG.
[0028]
The example of the clause table shown in FIG. 2 includes a clause number column 200, a name column 202, and a file storage location column 204. In this table, for example, data relating to the terms and conditions of automobile insurance are registered, and the value of the term number column 200 is used as a key so that the name of the terms and conditions and the physical storage (storage) location of the terms and conditions file can be specified. It has become. It should be noted that the type and name of the terms and conditions may vary depending on the characteristics and the classification method of the insurance products of each insurance company, and the physical storage location of the terms and conditions file may also vary according to the system environment.
[0029]
The example of the delivery management table shown in FIG. 3 includes an application form number column 300, a customer number column 302, a customer e-mail address column 304, a contract application content column 306, a covenant delivery flag column 308, a provision covenant , A registration date / time column 312, and an accounting flag column 314. The record is generated each time insurance contract application data is received from the agency terminal 17, and is specified by a column 300 of an application form number serving as a key. An ID for specifying a customer is registered in the customer number column 302, and information such as the name and address of the customer can be derived from a customer management DB (not shown). In a customer mail address column 304, an e-mail address that is a destination when transmitting the clause data is registered. In this embodiment, the table is denormalized in order to reduce the number of tables to be referred to in a series of processing. However, the table is normalized and the delivery management table (FIG. 3) is not included in the customer mail address column 304. When sending an e-mail, a configuration in which the e-mail is derived from the value of the customer number column 302 may be used.
[0030]
In the column 306 of the contract application content, the control unit of the contract accounting server 155 registers data representing the terms and conditions that need to be delivered, corresponding to the contents of the insurance contract application. The control unit specifies the corresponding terms and conditions based on the contents of the insurance contract application, and registers them in the contract application column 306. In the example of this table, one or a plurality of values in the column 200 of the article number in the article table (FIG. 2) are registered. Specifically, for example, when the contract application content of a certain customer is general automobile insurance and a driver family limited special agreement is added, the value “00” in the column of the agreement number is referred to by referring to the agreement table (FIG. 2). "And" 01 "are specified. The specification of the contract number that needs to be issued may be made automatically when applying for an insurance contract by setting the contract contents such as special contracts and the necessary contracts, The configuration may be such that the agency determines from the above. Then, data obtained by synthesizing the specified article number is registered. Here, “0001” synthesized from “00” and “01” is registered in the contract application content column 306. Therefore, when performing the process using the value of the column 300 of the contract application content, the process is performed in such a manner that the process is performed by dividing the number of digits of the article number into, for example, two digits.
[0031]
In the column 308 of the agreement delivery flag, "0" is set at the time of record generation, and "1" is set when it is determined that the transmitted agreement data has been received by the customer. The control unit of the contract accounting server 155 transmits the agreement data via the communication unit, and sets the flag to “1” when acquiring the data indicating that the customer has confirmed the agreement data by, for example, a mail opening notification.
[0032]
In the delivery agreement column 310, data representing the agreement to be delivered to the customer this time (not yet delivered) is registered by the control unit of the contract accounting server 155. In addition, similarly to the column 306 of the contract application content, the data is constituted by the article number. At the time of record generation, by extracting a record having the same value in the column 302 of the customer number, the already-issued clause number is specified from the value of the column 310 of the issued agreement and the value of the column 308 of the agreement issued flag. An agreement number to be issued this time (not yet issued) is specified from the value of the column 306 of the contract application content and the already issued agreement number, and the synthesized article number is registered in the issued agreement column 310. For example, a record is generated in which the value of the customer number column 302 is “000011111” and the value of the contract application content column 306 is “000010210”. Here, the numbers of the clauses corresponding to the contract application content are “00”, “01”, “02” and “10”. Then, an existing record in which the value of the customer number column 302 is “000011111” is extracted.
[0033]
For example, if there is one extracted record and the value of the column 308 of the terms and conditions issued flag is "1" and the value of the column 310 of the terms and conditions of delivery is "0001", "00" and "01" It can be understood that the article data indicated by the article number has already been issued to the customer. Therefore, the numbers “00”, “01”, “02”, and “10” of the agreements corresponding to the contents of the contract application are obtained by excluding the numbers “00” and “01” of the agreements already issued. 02 "and" 10 "are the numbers of the covenants to be issued this time. "02" and "10" are combined and the value "0210" is registered in the column 310 of the delivery agreement. In this way, the terms and conditions to be delivered this time consist of some or all of the conditions and conditions that need to be delivered.
[0034]
In the column 312 of registration date and time, the date and time when the record was generated are registered. In addition, “0” is set in the record flag column 314 at the time of record generation, and the record is made based on the data of the record (the customer determines the application details, and insurance contract data based on the determined contents is sent to the insurance company. , Is accepted) is set to “1”.
[0035]
Next, the operation of the system shown in FIG. 1 will be described with reference to FIGS.
[0036]
The agent terminal 17 receives, for example, an input of customer data (also referred to as customer data or customer attribute data) and insurance contract application data on an insurance contract application system screen (not shown) (step S1). ). Subsequently, the agency terminal 17 transmits the accepted customer data and the accepted application form data to the contract accounting server 155 in accordance with the instructions of the agency (step S3). The control unit of the contract accounting server 155 (hereinafter, in the description of the processing in the contract accounting server 155, when simply displaying the contract accounting server 155, it indicates the processing by the control unit. Alternatively, the processing is displayed as the contract accounting server 155 (control unit). In some cases, the customer data and application form data are received from the agency terminal 17 and stored in an insurance contract application DB or the like (not shown) (step S5). Further, the contract accounting server 155 (control unit) generates a record for the delivery management table (FIG. 3) using the application form data received from the agent terminal 17 via the communication unit, and stores the record in the clause delivery management DB 1551. It is stored in the delivery management table (FIG. 3) (step S7).
[0037]
At this stage, the values of the application form number column 300, the customer number column 302, the customer mail address column 304, the contract application content column 306, and the registration date / time column 312 are recorded in the record. In column 308 and column 314 of the accounting flag, “0” is recorded as an initial value. Since the value of the column 310 of the delivery agreement is specified by the processing described below, a NULL value is recorded or nothing is recorded. If it is not possible to receive the clause data, for example, if the customer does not have a mail address, nothing is recorded in the customer mail address column 304. For example, among the customer number column 304 in the delivery management table of FIG. 3, since the customer of 00007777 is a customer who cannot receive the agreement data, the customer e-mail address column 304 is left blank. Not noted.
[0038]
On the other hand, the agency terminal 17 determines whether to end the insurance contract application process (step S9). For example, it is determined whether an end button has been pressed on a screen of an insurance contract application system (not shown). If it is determined that the processing has not been completed yet, the application data reception processing from step S1 is repeated. If it is determined that the processing has been completed, the input of the application form number by the agency is accepted (step S11). Here, when there are a plurality of insurance contract applications, the input of the application form number in the record of the grant management table (FIG. 3) specified by the agent to transmit the terms and conditions to the customer is accepted. This is because customers may temporarily apply for multiple types of insurance contracts in order to consider what kind of insurance they will subscribe to. Then, the agency terminal 17 transmits the input application form number to the contract accounting server 155 (step S13).
[0039]
The contract accounting server 155 (control unit) receives the application form number from the agent terminal 17 and temporarily stores it in the storage device (step S15). The processing shifts to a processing of FIG.
[0040]
The contract accounting server 155 (control unit) searches the agreement delivery management DB 1551 using the application form number received from the agent terminal 17, and specifies a record in the delivery management table (FIG. 3) (step S17). Then, a contract file corresponding to the value of the column 306 of the contract application content of the specified record is specified (step S19). For example, the article number is stored in a storage device (such as the HDD 1555). Further, the contract accounting server 155 (control unit) searches for and extracts a record that includes the same customer number as the value of the customer number column 302 of the specified record and for which the covenant delivery flag is “1” (step). S21). As a result of the extraction, it is determined whether or not the record exists (step S23). If it is determined that the record does not exist, the value of the column 306 of the contract application content is registered as it is in the column 310 of the delivery agreement of the specified record. (Step S27). That is, since the terms and conditions have not been sent to the customer before, it is set so that all the terms and conditions that need to be delivered in accordance with the contents of the contract application are delivered.
[0041]
On the other hand, if it is determined in step S23 that a record exists, the contract accounting server 155 (control unit) determines the value of the column 306 of the contract application content of the record specified in the processing of step S17 and the value of the column 306 in step S21. From the value of the column 310 of the terms and conditions of the record of the record extracted in the processing, the terms and conditions that have not been issued yet are specified (step S25). For example, the article number is stored in the storage device. In this case, in the column 310 of the terms and conditions of delivery of the record specified in the processing of step S17, the data (provision number) indicating the terms and conditions that have not been issued yet but specified in step S25 is registered (step S26). When there are a plurality of records extracted in the process of step S21, the contract accounting server 155 (control unit) specifies the issued terms and conditions by matching the values in the column 310 of the provision terms with the number of records. For example, if two records are extracted and the values of the column 310 of the issued agreement are “0001” and “0203”, the agreement numbers of the issued agreement are “00”, “01”, “02” and "03". If all the terms and conditions that need to be issued have been issued, in the process of step S27, a predetermined “no terms and conditions of delivery” is displayed in the column 310 of the issue conditions of the record specified in the process of step S17. Register a value or do not register anything.
[0042]
The contract accounting server 155 (control unit) determines whether or not the customer can receive the agreement data when the agreement requiring the agreement (here, there is no already-issued agreement) or the agreement to be issued this time can be specified. (Step S27). When it is determined that the agreement data cannot be received (step S27: No route), the contract accounting server 155 (control unit) performs printing processing of the agreement data using a printer (not shown) or the like (step S28). . The printed agreement is sent separately from the insurance company to the customer. On the other hand, when it is determined that the customer can receive the agreement data (step S27: Yes route), the contract accounting server 155 (control unit) determines a method of transmitting the agreement data to the customer (step S30). This determination may be fixed to one of the predetermined methods or may be in accordance with the customer's request. If it is determined that the data is to be transmitted as an e-mail attached file, the processing shifts to a processing of FIG. If it is determined that the file is not to be transmitted as an e-mail attached file, a URL (Uniform Resource Locator) for a download page for each application number is generated in order to have the customer download the file, and the URL is stored in the URL storage unit. It is stored (step S31), and the processing shifts to a processing of FIG. The control unit of the contract accounting server 155 transmits the data by any method via the communication unit.
[0043]
Next, the processing that has transited via the terminal B will be described with reference to FIG.
[0044]
The contract accounting server 155 (control unit) combines the terms and conditions data to be delivered to the customer this time into, for example, one file via the communication unit, and then attaches it to the customer (for example, using the user terminal 13) as an e-mail attached file. (Step S33). However, it may be sent without being combined into one file. The user terminal 13 receives the mail from the contract accounting server 155 according to the instruction of the customer and displays it on the display device (step S35). Then, the user terminal 13 transmits an opening confirmation mail to the contract accounting server 155 to notify that the mail has been received (step S37). Here, as a mechanism of sending the opening confirmation mail, a configuration that uses the function of the mailer may be used, or for example, a configuration may be used in which the mail is transmitted when the customer presses the opening confirmation button. Good. Then, the user terminal 13 stores the attached file (condition data) of the received mail in a storage device such as the HDD of the user terminal 13 (not shown) automatically or in accordance with the operation of the customer (step S39).
[0045]
On the other hand, when the contract accounting server 155 (control unit) receives the opening confirmation mail from the user terminal 13 via the communication unit (step S41), it specifies the record of the corresponding grant management table (FIG. 3). Then, the value of the column 308 of the terms and conditions issued flag is set to "1" (step S43).
[0046]
Next, the processing that has transited via the terminal C will be described with reference to FIG.
[0047]
The contract accounting server 155 (control unit) transmits the URL of the clause download page generated in the process of step S31 to the customer (for example, using the user terminal 13) via the communication unit (step S45). The user terminal 13 receives the mail from the contract accounting server 155 (control unit) according to the instruction of the customer, and displays it on the display device (step S47). When the customer clicks on the displayed URL or enters it in the address field of the Web browser, the user terminal 13 accepts the operation from the customer and transmits a request for the page data for downloading the terms and conditions to the contract accounting server 155. (Step S49). The data transmitted by the user terminal 13 is for displaying a Web page, and is actually transmitted to a Web server (not shown). Then, the Web server accesses the HDD 1555 of the contract accounting server 155 and the agreement delivery management DB 1551 managed by the contract accounting server 155 (control unit) to perform processing. Here, in order to make the explanation easy to understand, it is assumed that the processing on the server side is performed by the contract accounting server 155.
[0048]
The contract accounting server 155 (control unit) receives a request for the article download page data from the user terminal 13 via the communication unit (step S51). Since the URL of the article download page is generated for each application form number in step S31, the application form number can be specified from the URL. The contract accounting server 155 (control unit) specifies the application form number from the received URL (step S53). Further, using the specified application form number, the covenant delivery management DB 1551 is searched, and the record of the delivery management table (FIG. 3) is specified. The terms and conditions to be delivered this time are specified from the values in the delivery conditions column 310 of the specified record (step S55). The specified article number is stored in the storage device. For example, when the value of the column 310 of the delivery agreement of the specified record is “0001”, the numbers of the articles to be delivered this time are “00” and “01”.
[0049]
The contract accounting server 155 (control section) generates the article download page data and transmits it to the user terminal 13 via the communication section (step S57). The user terminal 13 receives the agreement download page data transmitted from the contract accounting server 155 via the communication unit, and displays the page data on the display device (step S59). When the user terminal 13 receives the operation of downloading the terms and conditions by the customer, the user terminal 13 transmits a request for downloading the terms and conditions to the contract accounting server 155 (step S61). The contract accounting server 155 (control unit) receives the agreement download request from the user terminal 13 via the communication unit (step S63). Then, the contract accounting server 155 (control unit) combines the clause data to be delivered this time into one file and transmits the file to the user terminal 13 (step S65). By synthesizing the agreement data into one file, it becomes easy to download the agreement of the customer and manage the download (grant) of the insurance company. When the transmission to the user terminal 13 is completed, the contract accounting server 155 (control unit) records, as a record indicating that the agreement has been transmitted to the customer, the agreement delivery of the corresponding record in the delivery management table (FIG. 3). The completion flag is set to "1" (step S67).
[0050]
On the other hand, the user terminal 13 receives the agreement file transmitted from the contract accounting server 155 (control unit) via the communication unit (step S69). Then, the user terminal 13 stores the received agreement file in a storage device such as the HDD of the user terminal 13 (not shown) automatically or in accordance with the operation of the customer (step S71).
[0051]
In the above, each time an application is created, the terms and conditions that need to be delivered and the terms and conditions data to be delivered this time have been specified and issued.However, the terms and conditions data should be delivered at the time of accounting. You may. In this case, the contract accounting server 155 (control unit) searches the agreement delivery management DB 1551 at the time of accounting for a new insurance contract of the customer, and specifies a record in the delivery management table (FIG. 3). Then, in the grant management table (FIG. 3), the accounting flag is set to “1”, and at the same time, the agreement file corresponding to the value of the contract content column 306 of the application form number is specified. Then, for a customer who can receive the terms and conditions data, the terms and conditions file specified as the terms and conditions data required to be delivered to the customer in accordance with the insurance contract is transmitted. In this case, the processing from step S21 to step S26 in FIG. 5 is omitted. For customers who cannot receive the clause data, the contract accounting server 155 (control unit) instructs the insurance policy printing machine 1553 to print a clause that requires delivery.
[0052]
Next, the processing in FIG. 8 will be described. The contract accounting server 155 (control unit) searches the delivery management table (FIG. 3) of the agreement delivery management DB 1551, and extracts a record in which the value of the accounting flag column 314 is "1" (step S73). That is, it is assumed that “1” is registered in the column 314 of the accounting flag corresponding to the application form number for which the accounting instruction is received from the agency terminal 17. Then, from the records extracted in step S73, a record of a specific customer is further extracted using the customer number (step S75). Then, the value of the column 308 of the terms and conditions issued flag of the record extracted by the customer number is determined (step S77). It is determined whether or not all are "1" (step S79). If it is determined that all are "1", the terms and conditions to be delivered have already been delivered to the customer. It is printed in the form of insurance policy printer 1553 (step S81). Alternatively, a configuration may be employed in which a print instruction is output to a security printing system (not shown). If it is determined in step S79 that all of the records are not "1" (at least one is not "1"), the terms and conditions of the record in which the value of the column 308 of the terms and conditions issued flag is "0" Is specified (step S83). The specified article number is stored in the storage device.
[0053]
From the characteristics of the values in the column 310 of the delivery agreement, since there is no duplicate value (article number) for each customer, among the agreements to be delivered to the customer, the agreement (article number) that has not been issued to the customer is It can be specified by processing. For example, for the same customer (customer number 00001111 in the delivery management table (FIG. 3)), in the first record (application form number 00000001), the value of the column 306 of the contract application content is “0001”, and the Is “1”, the value of the column 310 of the delivery agreement is “0001”, the value of the column 314 of the accounting flag is “0”, and the column 306 of the contract application content in the second record (application number 00000002). Is "000010210", the value of the column 308 of the provisional agreement issuance flag is "1", the value of the column 310 of the provisional agreement is "0210", the value of the column 314 of the accounting flag is "1", and the third In the record (application number 00000003), the value of the column 306 of the contract application content is “000010510”, the value of the column 308 of the covenant has been issued flag is “0”, The value of the column 310 is "05", the value of the column 314 of the recorded flag and a had been "0". That is, it is assumed that the customer finally selects and contracts the application number 00000002 among the three contract types. From the value in the column 314 of the accounting flag, only the second record is subject to accounting, and the terms and conditions (terms and conditions number) that need to be provided to the customer are “000010210” in the value of the column 306 in the contract application content. "00", "01", "02" and "10" as shown. Here, from the values in the column 308 of the terms and conditions issued flag and the value in the column 310 of the terms and conditions of delivery of the first record and the second record, the terms and conditions are "00" and "01", "02" and "10". It can be seen that the customer has received all of the necessary terms and conditions indicated by "00", "01", "02" and "10".
[0054]
Applying this to the processing flow of FIG. 8, only the second record is extracted in step S73. Step S75 includes a step of further extracting the record extracted in step S73 for the same customer. Here, since the record of the same customer has already been extracted, the record is passed through as it is. Then, in step S77, it is determined that the covenant delivery flag is "1". Since there is one record, “Yes” is determined in the step S79, and the process proceeds to the step S81. Since it was not necessary to send additional terms and conditions, it can be seen that the processing was performed correctly.
[0055]
On the other hand, it is assumed that the value of the column 314 of the accounting flag of the third record is “1”, and all other conditions are the same as the case described above. That is, it is assumed that the value of the column 314 of the accounting flag of the second record and the third record is “1”. In this case, from the value of the accounting flag column 314, the accounting target is the second record and the third record. The terms and conditions (terms and conditions number) that need to be delivered to the customer are "00", "01", "02", "05" and "10", excluding the duplication from the value in the column 306 of the contract application content. Here, the terms and conditions are "00" and "01", "02" and "10" from the value of the column 308 of the terms and conditions issued flag and the value of the column 310 of the terms and conditions of delivery in the second record and the third record. And "2", and the customer needs "00", "01", "02", "05" and "10". It can be seen that "02" and "10" have been received. That is, it is necessary to additionally transmit the agreement indicated by “05” to the customer. Such determination processing is performed by the contract accounting server 155 (control unit).
[0056]
When this is applied to the processing flow of FIG. 8, in step S73, the second record and the third record are extracted by the contract accounting server 155 (control unit). Step S75 is a step of further extracting the record extracted in step S73 for the same customer. In this case, since the record of the same customer has already been extracted, the record is passed as it is. Then, in step S77, it is determined that the covenant issued flag of the second record is "1" and the covenant issued flag of the third record is "0". Since the third record is "0", "No" is determined in the step S79, and the processing by the contract accounting server 155 (control unit) proceeds to the processing in the step S83. Then, in the process of step S83, the article number "05" is specified from the value in the column 310 of the issued article in the third record. Since it was necessary to additionally transmit the terms and conditions indicated by "05" to the customer, it can be seen that the processing was performed correctly.
[0057]
As described above, the present embodiment can cope not only with the case where the same customer selects one contract type but also with the case where the same customer applies for automobile insurance of different contract types for two or more vehicles. It is.
[0058]
Here, when the same customer applies for an automobile insurance contract to each of a plurality of vehicles, for example, a structure is used in which a plurality of automobile insurance contracts share and use the terms and conditions. However, instead of the present embodiment, even if the same policyholder, for example, all contracts that need to be issued may be issued for each individual automobile insurance contract. That is, the provision of the terms and conditions may be managed for each individual insurance object (or for each insurance contract), and the terms and conditions of the provision of the terms and conditions may be managed for each insurance object. And when multiple applications (multiple types of contract applications) are made for the same insurance contract, instead of issuing duplicate conditions each time, instead of reissuing the conditions already issued in the previous application, In response to the later application, only unissued terms (terms that need to be issued this time) will be issued.
[0059]
As described above, in step S83, the contract accounting server 155 (control unit) extracts a case in which the customer has not been able to confirm that the contract has been received for some reason. In such a case, since the contract is sent to the customer in paper (booklet), the contract accounting server 155 (control unit) transmits the contract specified in step S83 and the policy of the contract to the insurance printing machine 1553. It instructs to use and print (step S85) or to perform print processing. Alternatively, the existing covenant booklet is enclosed in an envelope with the printed securities.
[0060]
Note that the processing flow in FIG. 8 is a flow on the assumption that the processing is performed at a predetermined cycle (for example, one day) by the control unit acquiring the system time in the contract accounting server 155. However, the control unit may detect a case where the accounting flag of a certain record is set to “1” or another arbitrary timing, and execute the processing at that time. Further, there is a case where a configuration is adopted in which a certain record is focused on and executed after a lapse of a predetermined time from the accounting timing of the record.
[0061]
If “No” is determined in step S79, instead of the processing in step S83, a contract (corresponding to a contract number) corresponding to the contract application content finally selected and recorded by the customer and requiring delivery is provided. All of them may be specified and printed. That is, in accordance with the booked contract application contents, the contract article number (clause number) which needs to be issued is determined from the value of the column 306 of the contract application contents based on the contract article number (for example, “00” when the third record is recorded). , “01”, “05”, and “10”), and print processing may be performed on them.
[0062]
The contract accounting server 155 (control unit) determines whether the above processing has been performed for all customers of the record extracted in step S73 (step S87), and when it is determined that the processing has not been completed for all customers. , The processing from step S75 is repeated. If it is determined that the processing has been completed for all customers, the recorded records in the grant management table are cleared (step S89).
[0063]
Next, a description will be given of a process of notifying a customer of data of the issued agreement that is not applied because the actual contract has not been reached.
[0064]
For example, looking at the customer with the customer number 00002222 in the delivery management table (FIG. 3), for the application form number 00000004, the value of the column 306 of the contract application content is “00010203”, and the value of the column 310 of the delivery agreement is also “ 0002033 ”and the value in the column 308 of the terms and conditions issued flag is“ 1 ”, so that the terms and conditions data of“ 00 ”,“ 01 ”,“ 02 ”and“ 03 ”have been issued and the contract is recorded. Confirmed by the server 155 (control unit). Also, regarding the application form number 00000005, the value of the column 306 of the contract application content is “000102”, and the corresponding agreement data has already been issued in the application form number 00000004. It is blank. For the application form number 00000005, the value of the accounting flag column 314 is “1”, and the value of the accounting flag column 314 of the application form number 00000004 is “0”. In other words, the customer of the customer number 000022, after examining the application form number 00000004 and the contract content of the application form number 00000005, finally concluded the contract with the application form number 00000005 and recorded the contract data. Become.
[0065]
That is, although the agreement corresponding to “03” among the values in the column 310 of the agreement to be issued with the application form number 00000004 has already been issued, it is an unnecessary agreement in the light of the contract recorded in the end. That was. Therefore, the contract accounting server 155 (control unit) updates the accounting flag to “1” for the application form number 00000005, and displays the “deletion agreement” column (not shown) separately provided in the delivery management table (FIG. 3). 03 ”is set. Further, the contract accounting server 155 (control unit) sends a notification of the contents shown as an example in FIG. 9 to the communication unit in order to notify that the agreement corresponding to “03” is not applied to the insurance contract actually contracted. Done through. FIG. 9 shows words of thanks for joining the contract, a description of the contents of the transmission, names of the terms and conditions that are not applicable, a condition number, and the contents of the conditions. The contract accounting server 155 (control unit) extracts and generates the transmission content shown in FIG. 9 from a predetermined data recording area (for example, the HDD 1555).
[0066]
Looking at the customer with the customer number 00000444 in the delivery management table (FIG. 3), for the application form number 00000007, the value of the column 306 of the contract application content is “000103” and the value of the column 310 of the delivery agreement is “ 000103 ", and since the value of the column 308 of the terms and conditions issued flag is" 1 ", it is determined that the terms and conditions data of" 00 "," 01 "and" 03 "have been issued and the contract accounting server 155 ( Control unit). Note that the value of 314 in the column of the accounting flag is “1”, and it can be confirmed that the contract has been concluded with this content. Regarding the application form number 00000008, the value of the column 306 of the contract application content is “000010414”, the value of the column 310 of the grant agreement is “0414”, and the value of the clause 308 of the Since it is “1”, the contract accounting server 155 (control unit) confirms that the clause data of “04” and “14” have already been issued.
[0067]
As for the application form number 00000008, the value of the column 314 of the accounting flag is “0”. That is, the customer having the customer number 000004444, after examining the application form number 000000007 and the content of the application form number 00000008, finally concludes a contract with the application form number 000000007 and the contract data is recorded. In other words, the value in column 310 of the delivery agreement with application number 00000008, the agreement corresponding to "0414", has been issued, but was unnecessary in light of the contract finally recorded. become. Therefore, the contract accounting server 155 (control unit) updates the accounting flag to “1” for the application form number 00000007, but deletes the application form number 00000008 of the application form number 00000008 (not shown) in the delivery management table (FIG. 3). The value of the column of the clause is set to “0414”. Further, the contract accounting server 155 (control unit) sends a notification via the communication unit to inform that the agreement corresponding to “0414” is not applied to the insurance contract actually contracted. The content of the notification can be the same as that shown in FIG.
[0068]
As a method for notifying the terms and conditions that are not applied, instead of the method described above, all the terms and conditions that need to be newly delivered may be transmitted again. In this case, the description of the transmitted content may be, for example, "For the insurance contract you have recently contracted, the contents of the following terms and conditions will be applied. Please save the data. " The contract accounting server 155 (control unit) extracts all the terms and conditions that need to be issued, generates a transmission content by adding a corresponding explanation, and transmits the generated content to the customer via the communication unit.
[0069]
In this way, by issuing the terms and conditions that need to be delivered to the customers who can receive the terms and conditions data by sending them through the network, the insurance company can reduce the communication cost and load of issuing the terms and conditions by mail. In addition, the customer can obtain only the applicable terms and conditions each time, and can use it as reference material for insurance. In addition, by specifying the terms and conditions to be issued this time, customers who have already received the terms and conditions due to factors such as determining the contents of the contract after examining multiple insurance contract types and modifying the insurance contract application form On the other hand, when further provisions are issued, by specifying the provisions data already issued to the customer, transmission of duplicate provision data can be avoided. In addition, by giving notification that unnecessary terms and conditions are not covered, it is possible to prevent misunderstandings regarding customer contract contents. In this way, insurance companies and customers can reduce the communication and processing load. Further, even when the customer does not receive or cannot receive the agreement for some reason, it is possible to perform a corresponding process such as printing on a booklet and mailing the booklet.
[0070]
[Embodiment 2]
FIG. 10 shows a system configuration diagram according to the second embodiment of the present invention. For example, the user terminal 23, which is a personal computer, has a mailer function and a Web (Web) browser function (not shown), and can transmit and receive mails wirelessly or by wire, and can browse a homepage by connecting to the Internet. It is possible.
[0071]
For example, a network 21 such as the Internet includes one or more user terminals 23 and one or more contract accounting servers 255 for performing insurance contract accounting processing, for example, a personal computer having a mailer function and an insurance contract application function. Is connected to one or more agency terminals 27.
[0072]
The contract accounting server 255 is connected to a contract management DB 2551 in which data related to the insurance contract status of the customer is stored. In the HDD 2555 of the contract accounting server 255, agreement data for delivery to the customer is stored, for example, as an agreement file. Depending on the method of classifying insurance contracts and the types of special contracts, there may be any number of corresponding covenant files. The contract accounting server 255 includes a control unit and a communication unit (not shown). The details of the processing of the control unit will be described later in the description of the processing flow. For example, the processing of management of the agreement delivery management DB 2551 and management of the agreement file and other data stored in the HDD 2555 are performed. The communication unit is a communication interface for performing processing such as transmission of a clause file to a customer or the like.
[0073]
In addition, the insurance company 25 has a Web server (not shown), which manages a homepage for downloading an article file. In addition, a mail server (not shown) transmits mail to the customer. In addition, a system for performing insurance business processing such as an insurance contract DB, a customer management DB, and an agency DB managed by the contract accounting server 255 or another server (not shown) is installed. The contract accounting server 255 is connected to an insurance policy or transfer approval printing machine (not shown).
[0074]
Note that the contract accounting server 255 and other servers (not shown) are not necessarily installed inside the insurance company 25, and may be installed outside by outsourcing or the like as long as similar functions can be realized. .
[0075]
The communication via the network 21 uses devices and functions necessary for Internet connection and mail transmission and reception, such as a domain name server (DNS), a mail server, and a firewall (not shown). And
[0076]
The contract management DB 2551 includes, for example, a clause table (FIG. 2) and a contract management table described below. FIG. 11 shows an example of the structure of the contract management table and stored data.
[0077]
In the example of the contract management table shown in FIG. 11, a column 100 of the security number, a column 102 of the storage location of the security file, a column 104 of the customer number, a column 106 of the customer mail address, a column 108 of the contract content, and a column 110 of the terms and conditions of delivery are provided. , A column 112 of the terms and conditions issued flag, a column 114 of the terms of the customer issued terms, a column 116 of the contract accounting date / transfer approval date, and a column 118 of the deletion flag. The record is generated for each insurance policy of the customer, and is specified by a key number 100 of the security number. In the example of FIG. 11, there are duplicate records when only the value of the security number column 100 is viewed. However, the value of the deletion flag column 118 enables discrimination between a valid record and an invalid record. The valid records are configured so as not to overlap.
[0078]
In the security file storage location column 102, for example, a physical storage (storage) location of an insurance policy file generated by an insurance policy issuing system (not shown) is registered. In this embodiment, the insurance policy is handled as an electronic file. Therefore, when the insurance policy is printed or transmitted to the customer, the insurance policy file is specified from the value of the column 102 of the storage location of the policy file.
[0079]
An ID for specifying a customer is registered in the customer number column 104, and information such as the name and address of the customer can be derived from a customer management DB or the like (not shown). In the customer mail address column 106, an e-mail address as a destination when the insurance policy data and the agreement data are transmitted is registered. In the present embodiment, the table is denormalized in order to reduce the number of tables to be referred to in a series of processing. However, the contract management table (FIG. 11) is normalized and the customer mail address column 106 is not included. When sending an e-mail, a configuration that derives from the value of the customer number column 104 may be used.
[0080]
In the contract content column 108, data representing terms and conditions corresponding to the content of the insurance contract is registered. In the example of this table, one or a plurality of values in the column 200 of the article number in the article table (FIG. 2) are registered. Specifically, for example, when the contract content of a certain customer is general automobile insurance and a driver's family limited special agreement is added, the value “00” in the column of the agreement number is referred to by referring to the agreement table (FIG. 2). And “01” are specified. The specification of the contract number that needs to be issued may be made automatically when an insurance contract is made by associating the setting of contracts such as special contracts with the necessary contracts, or from the contract contents. The structure which an agency judges may be sufficient. Then, data obtained by synthesizing the specified article number is registered. Here, “0001” synthesized from “00” and “01” is registered in the contract details column 108. Therefore, when the processing using the value of the column 108 of the contract content is performed, the processing is performed by dividing the article number into two digits, for example, two digits.
[0081]
In the delivery terms column 110, data representing the terms to be delivered to the customer this time (not yet delivered) or the terms and conditions delivered at the time of the contract are registered. In addition, similarly to the column 108 of the contract contents, the data is constituted by the article number. As described above, the terms and conditions to be issued at this time include some or all of the terms and conditions that need to be issued. In the column 112 of the terms and conditions issued flag, “0” is set when a record is generated, and “1” is set when it is determined that the transmitted terms and conditions data is received by the customer.
[0082]
In the column 114 of the customer-issued terms and conditions, all the numbers of the terms and conditions already issued to the customer are registered. For example, the value of the column 114 of the customer-issued agreement of the record corresponding to the contract so far is "0001", an insurance change occurs, and the column 110 of the agreement-issued record of the record corresponding to the change of the insurance contract this time. Is "05", when the record corresponding to the current contract is generated, the value of the column 114 of the customer-issued agreement is registered as "0001". When the value of 112 is set to “1”, the value of the column 114 of the customer-issued terms and conditions is updated to “000105”. That is, the customer has already received the terms and conditions corresponding to the terms and conditions number “00” and “01”, and this time, the customer has been additionally provided with the terms and conditions corresponding to the terms and conditions number “05”. Indicates that the terms and conditions granted are "00", "01" and "05". Therefore, when registering the value of the column 110 of the delivery agreement, the value of the column 114 of the customer's issued agreement of the record corresponding to the previous contract of the customer and the column of the contract content of the record corresponding to the current agreement are registered. The article number to be issued this time is specified from the value of 108 and registered.
[0083]
The date on which the contract was recorded or the date on which the insurance change was confirmed is registered in the contract recording date / transfer approval date column 116. In the deletion flag column 118, “0” is set (or blank) at the time of record generation, and “1” is set when the record corresponding to the contract so far is invalidated by insurance transfer processing or the like. Is set. Note that a configuration in which unnecessary records are deleted may be employed.
[0084]
Next, the operation of the system shown in FIG. 10 will be described with reference to FIGS.
[0085]
The control unit of the contract accounting server 255 receives data on the insurance contract of the customer from the agency (for example, the agency terminal 27) via the communication unit, and temporarily stores the data in the storage device (step S91). The control unit of the contract accounting server 255 (hereinafter, in the description of the processing in the contract accounting server 255, simply displaying “contract accounting server 255” means the processing by the control unit. Also, displaying the contract accounting server 255 (control unit) ), The contract file that needs to be delivered is specified from the contract contents (step S93). The specification of the terms and conditions file to be issued may be configured so that the setting of the contract details such as special contracts and the necessary terms and conditions are associated with each other and automatically made when applying for an insurance contract, May be included in the data determined by the agency and transmitted to the contract accounting server 255.
[0086]
The data received by the contract accounting server 255 (control unit) from the agency terminal 27 via the communication unit includes, for example, information that can determine whether a new insurance contract or a change in existing insurance exists. Then, the contract accounting server 255 (control unit) determines whether the insurance contract is a transfer of insurance (step S95). For example, if a new insurance contract or a change in existing insurance is determined, if the security number data of the existing contract is not included, it is determined to be a new insurance contract, and if the security number data of the existing contract is included, It can be determined that this is a transfer. Alternatively, a unique code number may be held for each of a new insurance contract and a transfer of existing insurance. The contract accounting server 255 (control unit) determines whether there is a new insurance contract or a change in existing insurance, based on the presence or absence of the data and the content of the data.
[0087]
If it is determined that the transfer has been made, the contract accounting server 255 (control unit) searches the contract management table (FIG. 11) of the contract management DB 2551 using the contract number included in the received data as a key, and retrieves the record of the contracted insurance. It is specified (step S97). From the value of the customer-issued terms and conditions column 114 of the specified record, the terms and conditions file that has been delivered to the customer is specified (step S99). The contract accounting server 255 (control unit) issues to the customer this time from the information on the agreement file corresponding to the contract content specified in step S93 and the information on the agreement file already issued to the customer identified in step S99. A contract file to be specified is specified (step S101). Then, the value of the column 118 of the deletion flag of the record specified in step S97 is updated to “1” (step S103). Further, a record is generated which includes the information of the agreement file issued to the customer specified in step S99 in the column 114 of the agreement with customer issued, and is newly stored in the agreement management table (FIG. 11) of the agreement management DB 2551 (step S99). S105).
[0088]
For example, an insurance special contract is added (corresponding contract number is “02”), and the contracts (contract numbers) that need to be delivered corresponding to the contents of this contract are “00”, “01” and “02”. And If the terms and conditions (condition numbers) that have been issued in accordance with the contents of the contract are “00” and “01”, the conditions and conditions (condition numbers) to be transmitted to the customer this time are “02”. Here, the contract accounting server 255 (control unit) stores in the DB new records indicating that the terms and conditions (terms and conditions numbers) that have been issued to the customer are “00” and “01”, and should be issued this time. When it is confirmed that the customer has received the article indicated by "02", the record is updated so that the information of the article (article number) issued to the customer includes "02".
[0089]
On the other hand, if it is determined in step S95 that the transfer is not a transfer, the contract accounting server 255 (control unit) newly generates and stores a record in the contract management table (FIG. 11) of the contract management DB 2551 (step S107). A value based on the data received in step S91 is recorded in the security number column 100, the customer number column 104, the customer e-mail address column 106, the contract content column 108, and the contract accounting date / transfer approval date column 116. Then, “0” is recorded as an initial value in the column 112 of the agreement issued flag and the column 118 of the deletion flag. The physical storage location of the insurance policy data is recorded in the column 102 of the storage location of the policy file. Note that there is no provision that has been issued to the customer, so the NULL value is recorded or nothing is recorded in the column 114 of the customer-issued provision. Since the terms and conditions to be delivered this time are all the terms and conditions corresponding to the contents of the contract (that is, the terms and conditions requiring the provision), the same value as the column 108 of the contents of the contract is recorded in the column 110 of the provisional terms.
[0090]
When the terms and conditions to be issued this time (or the conditions that need to be issued in step S107) can be specified, the contract accounting server 255 (control unit) determines whether or not the customer can receive the terms and conditions data (step S107). S108). Then, when it is determined that the agreement data cannot be received (step S108: No route), the contract accounting server 255 (control unit) issues a print instruction of the agreement data to a printer or the like (not shown), thereby executing the agreement print processing. Is performed (step S109). When it is determined that the customer can receive the agreement data (step S108: Yes route), the contract accounting server 255 (control unit) determines a method of transmitting the agreement data and the insurance policy data to the customer (step S110). The transmission method may be fixedly set in advance, or a different method may be adopted for each customer. If it is determined that the mail is to be transmitted as an attached file, the processing shifts to a processing of FIG. If it is determined that the file is not transmitted by the attached file of the mail, the URL of the download page for each insurance policy number is generated and stored in the URL storage unit in order to have the customer download the file (step S111). ), And the processing shifts to a processing of FIG.
[0091]
Next, the processing that has transited via the terminal D will be described with reference to FIG.
[0092]
The contract accounting server 255 (control unit) transmits, through the communication unit, the contract data to be delivered to the customer this time (when there are a plurality of contract data, the contract data may be a contract file obtained by combining them). And the insurance policy or the transfer approval form is transmitted to the customer (for example, using the user terminal 23) as an attached file of the mail (Step S113). The user terminal 23 receives the e-mail from the contract accounting server 255 according to the customer's instruction and displays it on the display device (step S115). Then, the user terminal 23 transmits an opening confirmation mail to the contract accounting server 255 to notify that the mail has been received (step S117). Here, as a mechanism of sending the opening confirmation mail, a configuration that uses the function of the mailer may be used, or for example, a configuration may be used in which the mail is transmitted when the customer presses the opening confirmation button. Good. Then, the user terminal 23 automatically or in accordance with the operation of the customer stores the attached file (the insurance policy or the transfer approval data and the agreement data) of the received mail in a storage device such as the HDD of the user terminal 23 (not shown) ( Step S119).
[0093]
On the other hand, when the contract accounting server 255 (control unit) receives the opening confirmation mail from the user terminal 23 via the communication unit (step S121), it specifies the record of the corresponding contract management table (FIG. 11). Then, the value of the column 112 of the terms and conditions issued flag is set to "1", and the value of the column 114 of the terms and conditions of the customer issued terms is updated (step S123). Regarding the value of the column 114 of the customer-issued terms and conditions, while the data of the contracted contract (issued terms number) has been registered at the time of record generation, the value of the terms and conditions number issued this time is used as update data. For example, when the value of the column 110 of the issued agreement is "05" and the value of the column 114 of the issued agreement is "0001", the value of the column 114 of the issued agreement is changed to "000105" in step S123. Update. Further, for example, when the value of the column 110 of the issued agreement is "0001" and the value of the column 114 of the issued agreement is a NULL value or nothing is registered, in step S123, the column 114 of the issued agreement is outputted. Is updated to “0001”.
[0094]
Next, the processing that has transited via the terminal E will be described with reference to FIG.
[0095]
The contract accounting server 255 (control unit) transmits the insurance policy or the transfer approval letter and the URL of the article download page generated in the process of step S111 to the customer (for example, using the user terminal 23) via the communication unit ( Step S125). The user terminal 23 receives the mail from the contract accounting server 255 according to the customer's instruction and displays it on the display device (step S127). When the customer clicks on the displayed URL or inputs the URL into the address field of the Web browser, the user terminal 23 accepts the operation from the customer and transmits a request for the page data for downloading the terms and conditions to the contract accounting server 255. (Step S129). The data transmitted by the user terminal 23 is for displaying a Web page, and is actually transmitted to a Web server (not shown). Then, the Web server accesses the HDD 2555 of the contract accounting server 255 and the contract management DB 2551 managed by the contract accounting server 255 to perform processing. Here, in order to make the explanation easy to understand, it is assumed that the processing on the server side is performed by the contract accounting server 255 (control unit).
[0096]
The contract accounting server 255 (control unit) receives, from the user terminal 23, a request for an insurance policy or a transfer approval form and a request for page data for downloading the terms and conditions via the communication unit (step S131). The contract accounting server 255 (control unit) performs an authentication process using, for example, a password in order to prevent the insurance policy or the transfer approval data from being referred to other than the customer (step S133). The password is provided to the customer from, for example, an agency. The date of birth may be used as the temporary password. The communication between the contract accounting server 255 (control unit) and the user terminal 23 performed via the communication unit of the contract accounting server 255 uses, for example, an encrypted communication such as an SSL (Secure Socket Layer). It may be.
[0097]
Also, since the URL of the insurance certificate or transfer approval form and the contract download page is generated for each insurance policy number in step S111, the insurance policy number can be specified from the URL. The contract accounting server 255 (control unit) specifies the insurance policy number from the received URL (step S135). Further, the contract management DB 2551 is searched using the specified insurance policy number, and the record of the contract management table (FIG. 11) is specified. The terms and conditions to be delivered this time are specified from the values in the delivery conditions column 110 of the specified record (step S137). For example, when the value of the column 110 of the delivery agreement of the specified record is “0001”, the numbers of the agreements to be delivered this time are “00” and “01”.
[0098]
The contract accounting server 255 (control unit) generates the insurance policy or transfer approval form and the article download page data, and transmits them to the user terminal 23 via the communication unit (step S139). The insurance policy or transfer approval form and the terms and conditions download page include link information generated using the value of the column 102 of the policy file storage location in the contract management table (FIG. 11). The user terminal 23 receives the insurance policy or the transfer approval form and the contract download page data from the contract accounting server 255, and displays them on the display device (step S141).
[0099]
When the user terminal 23 receives the operation of downloading the insurance policy or transfer approval form and the terms and conditions by the customer, the user terminal 23 transmits the insurance policy or transfer approval form and the request for downloading the terms and conditions to the contract accounting server 255 (step S143). The contract accounting server 255 (control unit) receives the insurance policy or transfer approval form and the contract download request from the user terminal 23 via the communication unit (step S145). Then, based on the received data, the contract accounting server 255 (control unit) combines the terms and conditions data to be delivered this time into one file and sends it to the user terminal 23 via the communication unit together with the insurance policy or transfer approval data. The data is transmitted (step S147).
[0100]
The insurance certificate or transfer approval data and the agreement data are transmitted as separate files, but since there is a correspondence, it is desirable that both files can be transmitted to the customer in one transmission process. For example, although not shown, when the customer presses a download button included in the insurance policy or transfer approval form and the contract download page, both the insurance policy or transfer form file and the contract file to be issued this time are copied. It may be configured to transmit to a customer. When the transmission to the user terminal 23 is completed, the contract accounting server 255 (control unit) specifies a record in the corresponding contract management table (FIG. 11) as a record indicating that the agreement has been transmitted to the customer. Then, the value of the column 112 of the terms and conditions issued flag is set to "1", and the value of the column 114 of the terms and conditions of the customer issued terms is updated (step S149).
[0101]
On the other hand, the user terminal 23 receives the insurance policy or transfer approval form and the contract file from the contract accounting server 255 (step S151). Then, the user terminal 23 automatically or in accordance with the operation of the customer stores the received insurance policy or transfer approval and the contract file in a storage device such as an HDD of the user terminal 23 (not shown) (step S153).
[0102]
By the way, if for some reason it cannot be confirmed that the customer has received the agreement, it is necessary to carry out a process for sending the agreement to the customer in paper (booklet). Therefore, the contract accounting server 255 (control unit) issues an instruction for printing the terms and conditions specified in step S101 and the transfer approval document relating to the transfer using a transfer approval document printing machine or the like to the printing press. Alternatively, the insurance company will enclose the existing agreement booklet in an envelope with the printed transfer approval letter.
[0103]
Note that the contract accounting server 255 (control unit) can confirm whether or not the clause data has been issued at the time of accounting for an insurance contract or a change or at any other time. For example, it can be confirmed at a predetermined point in time that is specified based on when the clause data to be delivered this time is transmitted, when an insurance contract or a change is recorded, or the like. For example, when a predetermined time (for example, 24 hours) has elapsed from when the agreement data was transmitted or counted, or at 3:00 pm two days after the date when the agreement data was transmitted or counted (at 3:00 pm the next day). It is confirmed at a predetermined point in time, such as at 3:00 pm).
[0104]
In the case where confirmation is made at the time when a predetermined time (for example, 24 hours) has elapsed from the time when the agreement data was transmitted or counted, the time when the agreement data was transmitted or counted in the contract management table (FIG. 11), not shown. The data is recorded by the contract accounting server 255 (control unit), and the elapsed time thereafter is recorded similarly. When the confirmation is made at a predetermined point in time, such as 3:00 pm two days after the next day, the time when the agreement data is transmitted or recorded is stored in the contract management table 255 (not shown) in the contract management table (FIG. 11). ), And at the same time, data at a point in time to be confirmed is recorded based on a preset rule. Then, the contract accounting server 255 (control unit) acquires the system time in the contract accounting server 255, measures the elapsed time, and performs the above-described necessary processing when a predetermined time has elapsed.
[0105]
In addition, of the contract data that has been delivered in response to the existing contract and is no longer applied due to the transfer, the contract accounting server 255 (control unit) notifies the customer via the communication unit to that effect. Notify. For example, the value of the contract content column 108 is “00010203”, the value of the delivery agreement column 110 and the customer issued agreement column 114 is also “00010203”, and the value of the agreement delivery flag column 112 is “1”. (The case of the security number xxxzzzz0012 in the contract management table (FIG. 11)), it is assumed that the "driver's family limited special contract (condition number" 01 ")" will be deleted due to a change later. . In this case, the contract accounting server 255 (control unit) notifies the contents shown as an example in FIG. 15 to notify that the agreement corresponding to “01” is not applied. FIG. 15 shows a thank you for joining the contract, a description of the content of the transmission, the insurance contract to be covered, the contents of the applicable agreement that are not applicable, and the like.
[0106]
In this way, when additional terms are to be delivered to a customer who has already received terms and conditions due to a change in insurance, etc., the terms and conditions data already delivered to the customer can be specified, and You can avoid sending. Therefore, insurance companies and customers can reduce communication and processing loads. In addition, by notifying the customer of the terms and conditions that are no longer applied due to the transfer, misunderstanding regarding the customer's contract content can be prevented. Further, by transmitting the insurance policy or the transfer approval data together with the policy data, the insurance company and the customer can easily manage the insurance policy and the policy. Also, if the customer does not or cannot receive the insurance policy and the terms and conditions for some reason, it is possible to perform a response process such as mailing a paper and a booklet.
[0107]
Although the embodiment of the present invention has been described above, the present invention is not limited to this. For example, the system configuration shown in FIGS. 1 and 10 is an example, and other configurations may be used as long as the implementation pattern shown in FIGS. 1 and 10 can be realized. For example, a DB configuration is also an example, and another configuration may be adopted if similar data is stored. Further, items may be added or deleted as needed. For example, the agreement table (FIG. 2) may be configured such that even if the same special agreement is revised, a new agreement number is assigned and registered. Further, the configuration of each server is not limited to a single server, and may be a configuration of a plurality of servers. For example, a plurality of contract accounting servers 155 and 255 may be configured. When transmitting the insurance policy file to the customer, the file may be encrypted and transmitted.
[0108]
Further, the present embodiment is summarized as follows.
[0109]
The information processing method for issuing insurance contracts according to the first aspect of the present embodiment, when receiving data related to a customer's insurance contract and attribute data of the customer, receives the data related to the received insurance contract. Based on the terms and conditions that specify the terms and conditions that need to be delivered to the customer based on the received attribute data of the customer, to determine whether the customer can receive the terms and conditions data of the terms and conditions specified in the terms and conditions specifying step A sex determining step; and a transmitting step of transmitting, to the customer, which is determined to be receivable in the receivability determining step, the clause data of the clause specified in the clause specifying step to the customer. Thereby, the agreement data can be transmitted to the network-capable customer via the network, and the insurance company can save labor.
[0110]
Further, in the first aspect of the present embodiment, a printing process for printing the clause data of the clause specified in the clause specifying step for a customer determined to be unreceivable in the receivability determining step. The configuration may further include steps. The terms and conditions printed in the print processing step are sent to a customer or the like who cannot support the network. In this case, since only the clauses that need to be issued are printed, the amount of resources consumed can be reduced.
[0111]
Further, the above-mentioned clause specifying step includes a first specifying step of specifying a contract that needs to be issued to the customer based on the received data related to the insurance contract, and a corresponding step based on the customer data stored in the storage device in advance. A third specification for specifying the terms and conditions to be delivered this time using the second specification step for specifying the terms and conditions already issued to the customer, the terms and conditions specified in the first specification step, and the terms and conditions specified in the second specification step In the above-described transmission step, it is also possible to transmit the terms and conditions data of the terms and conditions to be issued this time specified in the third specifying step to the customer. As described above, the communication load can be reduced by transmitting the terms and conditions data of the terms and conditions that need to be delivered to the customer, excluding the terms and conditions data of the terms and conditions already delivered to the customer.
[0112]
According to the information processing method for issuing insurance contracts according to the second aspect of the present embodiment, when data related to a customer's insurance contract is received, the customer needs to be issued based on the received data related to the insurance contract. A first specifying step of specifying the relevant terms and conditions, a second specifying step of specifying the terms and conditions already issued to the customer based on the data of the customer stored in the storage device in advance, and the terms and conditions specified in the first specifying step. A third specifying step of specifying the terms and conditions to be delivered this time using the terms and conditions specified in the second specifying step, and transmission of transmitting the terms and conditions data of the terms and conditions to be delivered specified in the third specifying step to the customer Steps. That is, duplicate agreement data is prevented from being transmitted to the customer by excluding the agreement data of the agreement already issued from the agreement data of the agreement requiring delivery to the customer. As a result, it is possible to reduce the communication load when transmitting the clause data in an electronic file. Further, when the insurance company or the customer prints the clause data on paper, it is possible to reduce the consumption resources.
[0113]
In the first and second aspects of the present embodiment, out of the terms and conditions specified in the second specifying step, the non-applicable terms and conditions that are not included in the terms and conditions specified in the first specifying step are specified. A configuration that further includes a non-applicable clause specification step may be employed.
[0114]
Further, a cancellation information generating step of generating agreement application cancellation information including information on the non-applicable agreement specified in the non-applicable agreement specifying step described above, and transmitting the generated agreement application cancellation information to the customer. And a transmitting step. This allows the customer to know exactly which terms to read.
[0115]
In the first and second aspects of the present embodiment, the data related to the received insurance contract may be insurance contract application data or insurance contract recording data of the customer. Thus, for example, when an insurance contract application or insurance contract accounting is received from the agency terminal, it is possible to transmit only the clause data of the terms and conditions that have not been issued to the customer. In other words, some or all of the terms and conditions data of the terms and conditions previously issued in response to the insurance contract application will not be transmitted to the same customer again, and only the terms and conditions data of the terms and conditions that need to be additionally delivered to the customer. It becomes possible to transmit.
[0116]
In the first and second aspects of the present embodiment, the data related to the received insurance contract may be customer insurance transfer data. Thus, when an insurance transfer request is received from the agent terminal, it becomes possible to transmit only the clause data of the terms and conditions that have not been issued to the customer. In other words, some or all of the terms and conditions data of the terms and conditions issued at the time of the existing insurance contract will not be sent to the same customer again, but only the terms and conditions data of the terms and conditions that need to be additionally delivered to the customer. It is possible to do.
[0117]
Further, in the first and second aspects of the present embodiment, the configuration may further include a step of transmitting insurance policy data to a customer. The customer can obtain insurance policy data and clause data corresponding to the insurance policy.
[0118]
In the transmission step in the first and second aspects of the present embodiment described above, the terms and conditions data of the terms and conditions to be delivered or the terms and conditions data of the terms and conditions to be sent this time are sent to the customer as an attached file of e-mail. It may be configured to transmit or to transmit the clause data of the clause to be sent this time in response to a download request of the customer. Terms and conditions can be transmitted in a form that matches the system environment and communication environment of insurance companies and customers.
[0119]
Further, in the first and second aspects of the present embodiment, when there are a plurality of clause data of the clauses which need to be issued or a plurality of clause data of the clauses to be issued this time, they are combined into one agreement file and stored in the agreement file storage unit. , A step of generating link information for download of the combined agreement file, and a step of notifying the customer of the generated link information for download, wherein the customer uses the link information for download. When the download is instructed, the transmission step may be executed. The customer can collectively download the agreement data corresponding to the contract or the transfer from the agreement download homepage. This also simplifies the management of terms and conditions.
[0120]
Further, in the first and second aspects of the present embodiment, if it is determined that the customer has received the terms and conditions data of the terms and conditions to be delivered or the terms and conditions data of the terms and conditions to be delivered this time, the data of the customer The method may further include a step of adding information indicating that the necessary terms and conditions data or the terms and conditions data to be sent this time have been issued. Thereby, it becomes possible to specify the clause data of the clause already issued to the customer. On the other hand, if the information indicating that the delivery has been completed is not added to the customer data for a predetermined period after sending the agreement data or sending the download request email, the agreement is printed It is also possible to adopt a configuration in which the information is printed and mailed.
[0121]
Further, according to the first and second aspects of the present embodiment, when the contract data of the contract requiring delivery or the contract data of the contract to be delivered this time are transmitted to the customer, or based on the data related to the insurance contract, If it is not determined that the customer has received the terms and conditions data of the terms and conditions to be delivered or the terms and conditions data of the terms and conditions to be delivered this time at the time specified based on when the insurance contract was recorded, the terms and conditions data is printed. The configuration may further include the step of performing This is to send separately the terms and conditions that have not been received for some reason to the customer.
[0122]
【The invention's effect】
As described above, according to the present invention, it has been possible to provide an information processing technique for issuing a clause with appropriate contents to a customer by an appropriate method.
[Brief description of the drawings]
FIG. 1 is a schematic diagram of a system according to an embodiment of the present invention.
FIG. 2 is a diagram illustrating an example of a configuration of a clause table and stored data.
FIG. 3 is a diagram showing an example of the configuration of a delivery management table and stored data.
FIG. 4 is a diagram showing a processing flow (1) according to an embodiment of the present invention.
FIG. 5 is a diagram showing a processing flow (No. 2) in the embodiment of the present invention.
FIG. 6 is a diagram showing a processing flow (part 3) in the embodiment of the present invention.
FIG. 7 is a diagram showing a processing flow (part 4) in the embodiment of the present invention.
FIG. 8 is a diagram showing a processing flow (part 5) in the embodiment of the present invention.
FIG. 9 is a diagram showing an example of a notice of non-application of a clause.
FIG. 10 is a system schematic diagram according to Embodiment 2 of the present invention.
FIG. 11 is a diagram showing an example of the structure of a contract management table and stored data.
FIG. 12 is a diagram showing a processing flow (part 1) in the second embodiment of the present invention.
FIG. 13 is a diagram showing a processing flow (part 2) in the second embodiment of the present invention.
FIG. 14 is a diagram showing a processing flow (part 3) in the second embodiment of the present invention.
FIG. 15 is a diagram showing an example of a notice of non-application of a clause.
[Explanation of symbols]
11 network 13 user terminal
15 Insurance company 17 Agent terminal
155 Contract accounting server 1551 Covenant delivery management DB
1553 Insurance policy printing machine 1555 Contract accounting server HDD
21 Network 23 User Terminal
25 Insurance company 27 Agent terminal
255 Contract Accounting Server 2551 Contract Management DB
2555 Contract accounting server HDD

Claims

A receiving step of receiving data related to the customer's insurance contract and attribute data of the customer, and storing the data in a storage device;
In the receiving step, a clause specifying step that specifies a contract that needs to be issued to the customer based on data related to the insurance contract stored in the storage device, and stores identification data of the contract in a required contract identification data storage unit. When,
Based on the attribute data of the customer stored in the storage device in the receiving step, the customer receives the terms and conditions data of the terms and conditions identified in the terms and conditions specifying step and the identification data stored in the required terms and conditions identification data storage unit. A reception possibility determination step of determining whether or not reception is possible;
To the customer determined to be receivable in the receivability determining step, transmit the terms and conditions data of the terms and conditions specified in the terms and conditions specifying step and the identification data stored in the required terms and conditions identification data storage unit. Sending step;
And a computer-implemented information processing method for issuing insurance contracts.

For the customer determined to be unreceivable in the receivability determining step, the terms and conditions data of the terms and conditions specified in the terms and conditions specifying step and the identification data stored in the required terms and conditions identification data storage unit are stored. The information processing method for issuing insurance contracts according to claim 1, further comprising a print processing step of performing print processing.

The article identification step,
A first specifying step of specifying terms and conditions that need to be delivered to the customer based on the received data related to the insurance contract, and storing identification data of the terms and conditions in the necessary terms and conditions identification data storage unit;
In the receiving step, based on the data of the customer read by searching the customer data storage unit using the identification data of the customer included in the data stored in the storage device, the terms and conditions already issued to the customer A second specifying step of specifying and storing identification data of the terms and conditions issued to the customer in the issued terms and conditions identification data storage unit;
The identification data of the agreement specified in the first identification step and stored in the required agreement identification data storage unit; and the customer identified in the second identification step and stored in the issued agreement identification data storage unit A third specifying step of identifying the terms and conditions to be issued this time using the identification data of the terms and conditions already issued, and storing the identification data of the terms and conditions in the issued terms and conditions identification data storage unit;
Including
The transmitting step includes transmitting, to the customer, the article data of the article to be issued this time, which is specified in the third specifying step and whose identification data is stored in the issued article identification data storage unit, to the customer. An information processing method for issuing insurance contracts according to item 1 or 2.

Receiving data related to the customer's insurance contract and storing the data in a storage device;
A first specification that specifies, in the receiving step, the terms and conditions that need to be issued to the customer based on the data related to the insurance contract stored in the storage device, and stores the identification data of the terms and conditions in the required terms identification data storage unit Steps and
In the receiving step, based on the data of the customer read by searching the customer data storage unit using the identification data of the customer included in the data stored in the storage device, the terms and conditions already issued to the customer A second specifying step of specifying and storing identification data of the terms and conditions issued to the customer in the issued terms and conditions identification data storage unit;
The identification data of the agreement specified in the first identification step and stored in the required agreement identification data storage unit; and the customer identified in the second identification step and stored in the issued agreement identification data storage unit A third specifying step of identifying the terms and conditions to be issued this time using the identification data of the terms and conditions already issued, and storing the identification data of the terms and conditions in the issued terms and conditions identification data storage unit;
A transmitting step of transmitting, to the customer, the terms and conditions data of the terms and conditions to be delivered, which is specified in the third specifying step and whose identification data is stored in the terms and conditions of delivery terms identification data storage unit,
And a computer-implemented information processing method for issuing insurance contracts.

Of the identification data of the agreement stored in the issued agreement identification data storage unit in the second identification step, the identification data of the agreement stored in the required agreement identification data storage unit in the first identification step is included. The information processing method for issuing insurance contracts according to claim 3 or 4, further comprising: a non-applicable contract identification step of storing identification data of the non-applicable contracts in the non-applicable contract identification data storage unit.

In the non-applicable terms identification step, terminology application revocation information including information about terms and conditions corresponding to the terms and conditions identification data stored in the non-applicable terms and conditions identification data storage unit is generated, and the revocation information stored in the revocation information storage unit Generating step;
Transmitting the terms and conditions application cancellation information stored in the cancellation information storage unit to the customer;
6. The information processing method according to claim 5, further comprising:

The insurance policy delivery according to any one of claims 1 to 6, wherein the data related to the insurance contract stored in the storage device is insurance contract application data or insurance contract recording data of the customer. Information processing method.

7. The information processing method according to claim 1, wherein the data related to the insurance contract stored in the storage device is insurance change data of the customer. .

The insurance policy delivery method according to any one of claims 1 to 8, further comprising: transmitting insurance policy data generated based on data related to the insurance contract stored in the storage device to the customer. Information processing method.

In the transmitting step, the terms and conditions data of the terms and conditions to be delivered or the terms and conditions data of the terms and conditions to be sent this time should be sent to the customer as an attached file of e-mail, or should be sent this time by the customer's download request. The information processing method for issuing insurance contracts according to claim 1 or 4, wherein the contract data of the contracts is transmitted.

When there are a plurality of clause data of the clauses requiring the grant or the clause data of the clauses to be delivered this time, combining them into one clause file and storing them in the clause file storage unit;
Generating link information for download of the agreement file stored in the agreement file storage unit and storing the link information in the link information storage unit;
Notifying the customer of the download link information stored in the link information storage unit,
Further comprising
5. The information processing method according to claim 1, wherein the transmitting step is performed when the customer instructs download using the download link information.

When it is determined that the customer has received the agreement data transmitted in the transmitting step, searching the customer data storage unit using the identification data of the customer included in the data stored in the storage device. 5. The method according to claim 3, further comprising the step of: adding information indicating that the covenant data has been issued to the customer data read out by the user and storing the information in the customer data storage unit. Information processing method.

In the transmitting step, when the agreement data is transmitted to the customer in the transmitting step, or at a time specified based on when the insurance contract is recorded based on the data related to the insurance contract stored in the storage device, The information processing method for issuing insurance contracts according to claim 1 or 4, further comprising a step of printing the contract data when it is not determined that the customer has received the transmitted contract data.

A program for causing a computer to execute the information processing method for issuing insurance policy according to any one of claims 1 to 13.

Receiving means for receiving data related to the customer's insurance contract and customer attribute data, and storing the data in a storage device;
Terms and conditions specifying means for specifying terms and conditions that need to be issued to the customer based on data related to the insurance contract stored in the storage device by the receiving means, and storing identification data of the terms and conditions in a necessary terms identification data storage unit When,
Based on the attribute data of the customer stored in the storage device by the receiving means, the customer receives the terms and conditions data of the terms and conditions specified by the terms and conditions specifying means and the identification data stored in the required terms and conditions identification data storage unit. Reception possibility determining means for determining whether or not the reception is possible;
To the customer determined to be receivable by the receivability determining means, transmit the terms and conditions data of the terms and conditions whose identification data is stored in the required terms and conditions identification data storage unit and which is specified by the terms and conditions specifying means. Transmission means for
Information processing device for issuing insurance contracts.

Receiving means for receiving data related to the customer's insurance contract and storing the data in a storage device;
A first specification that specifies the terms and conditions that need to be issued to the customer based on the data related to the insurance contract stored in the storage device by the receiving unit, and stores identification data of the terms and conditions in a required terms identification data storage unit. Means,
Based on the data of the customer read by searching the customer data storage unit using the identification data of the customer included in the data stored in the storage device by the receiving means, the terms and conditions already issued to the customer Second specifying means for specifying and storing identification data of the terms and conditions issued to the customer in the issued terms and conditions identification data storage unit;
The identification data of the terms and conditions specified by the first specifying means and stored in the required terms and conditions identification data storage unit; and the customer specified by the second specification means and stored in the issued terms and conditions identification data storage unit A third specifying means for specifying the terms and conditions to be issued this time using the identification data of the terms and conditions already issued, and storing the identification data of the terms and conditions in the issued terms and conditions identification data storage unit;
Transmitting means for transmitting, to the customer, the article data of the article to be issued this time, which is specified by the third specifying means and whose identification data is stored in the issued article identification data storage unit,
Information processing device for issuing insurance contracts.