JP2006048087A - 更新処理方法及び装置 - Google Patents

Abstract

【課題】
保険契約の更新時における業務効率化を図る。
【解決手段】
更新対象の契約情報を格納する情報格納部を参照し、各更新対象の契約につき、申込書を作成すべき更新対象契約を特定するための第1条件を満たしているか判断し、第1条件を満たしていると判断された更新対象契約に対応して上記申込書を生成すべきことを表す第1情報を登録する工程と、更新対象契約を除く各更新対象契約につき、更新申込が行われた後の計上時の確認処理を省略するための条件を含む第2条件を満たすか判断し、第2条件を満たしていないと判断された更新対象契約に対応して申込書ファイルを生成すべきことを表す第2情報を登録し、第2条件を満たしていると判断された更新対象契約に対応してオンラインで手続きすべきことを表す第3情報を登録する工程とを含む。情報格納部に更新対象契約情報が分類の上一元的に登録され、更新対象契約の取扱代理店の業務は効率化される。
【選択図】 図２

Description

本発明は、保険契約の更新処理技術に関する。

例えば特開２００２−１３３１１８号公報には、団体保険における保険条件の管理や更新を容易に行えるようにするため、以下のような技術が開示されている。すなわち、保険管理装置は、団体が管理している所属員データベースから各所属員の情報を取得し、これら情報と団体内ルールデータベース及び保険会社内ルールデータベースを用いて各所属員の保険金額及び保険料率を設定する。設定された保険金額及び保険料率は保険条件データベースに格納される。

また、特開２００２−１６９９３７号公報には、取引成立処理やその代金の徴収に関する作業を効率的に行うため、以下のような技術が開示されている。すなわち、従業員は、端末からネットワークを介してペイロール管理センタのＷＷＷサーバにアクセスし、実勤務時間等の報告を行うために、勤務データの入力を行っている。これらの勤務データは、ペイロール管理センタの人事データを格納するペイロールデータベースに格納される。端末からＷＷＷサーバに対して保険の引合い信号が送信されると、ペイロール管理センタから前記端末を操作する所属員に関する個人データの少なくとも一部の引継データが保険 取扱センタへと送られて、保険取扱センタでは、この引継データに基づき端末との間で取引処理を行う。
特開２００２−１３３１１８号公報 特開２００２−１６９９３７号公報

上で述べた従来技術では、ネットワークを介して保険契約の申し込みを受け付けたり、保険金額及び保険料率をコンピュータを用いて算出する技術については触れられているが、保険契約の更新を促す際などの業務効率化については考慮されていない。

従って、本発明の目的は、保険契約の更新時における業務効率化を図るための新規な技術を提供することである。

本発明に係る更新処理方法は、更新対象の契約データを格納する処理対象データ格納部を参照して、各更新対象の契約につき、特定の形態に係る申込書を作成すべき更新対象の契約を特定するための第１の条件を満たしているか判断し、上記第１の条件を満たしていると判断された更新対象の契約の契約データに対応して第１データ格納部（処理対象データ格納部と同一である場合もある）に上記特定の形態に係る申込書を生成すべきことを表す第１のデータを登録するステップと、処理対象データ格納部を参照して、第１の条件を満たしていると判断された更新対象の契約を除く各更新対象の契約につき、当該更新の申込が行われた後の計上時のチェック処理を省略するための条件を含む第２の条件を満たしているか判断し、第２の条件を満たしていないと判断された更新対象の契約の契約データに対応して第１データ格納部に申込書ファイルを生成すべきことを表す第２のデータを登録し、第２の条件を満たしていると判断された更新対象の契約の契約データに対応して第１データ格納部にオンラインで手続きすべきことを表す第３のデータを登録するステップとを含む。

このようにすれば、第１データ格納部に第１乃至第３のデータが対応付けられた更新対象の契約データが格納されるようになる。すなわち、第１データ格納部に更新対象の契約データが分類の上一元的に登録されることになるため、例えば更新対象の契約データを取り扱う代理店（仲介人を含む）は、当該第１データ格納部を利用して、顧客に対して適切な手段にて更新手続きを促す等、業務効率の効率化を図ることができるようになる。

また、第１データ格納部において第３のデータが対応して登録されている更新対象の契約について、ネットワークに接続された更新受付サーバにおいて更新申込を受け付けた場合、当該更新申込については計上時チェックを省略して、当該更新申込みのデータを登録するステップをさらに含むようにしても良い。第２の条件を適切に設定すれば、第２の条件を満たす更新対象の契約については、顧客の利便性を向上させつつ、計上時チェックが省略でき、業務効率化を図ることも可能である。

さらに、上で述べた第２の条件が、更新受付サーバの機能上の制約から更新受付サーバにおいて受け付けることができない契約内容を包含しないという第３の条件を含むようにしてもよい。更新受付サーバは、全ての契約内容に対応可能に構成することも可能であるが、コストがかさみすぎる場合がある。従って、一部の契約内容に対応できないような更新受付サーバを導入してコスト削減を図った上で、第２の条件に上で述べたような第３の条件を含めるようにする場合もある。例えば、上記第３の条件が、付保率が所定の基準以下である所定の特約を含まないという条件である場合もある。

また、上で述べた第１データ格納部が、特定の団体についての更新対象の契約データを格納しており、上で述べた第２の条件が、特定の団体特有の条件を含むようにしてもよい。例えば、特定の団体について付加的な契約引き受け条件を設定したり、除外する契約引き受け条件を設定する場合があるためである。

さらに、満期から所定期間内の他社契約のデータを格納する第２データ格納部を参照して、他社契約のデータを自社の契約のデータに変換し、更新対象の契約データとして処理対象データ格納部に格納するステップをさらに含むようにしてもよい。このようにすれば、第１データ格納部で、満期から所定期間内の他社契約についても一元的に取り扱うことが可能となり、業務効率が改善される。

また上で述べた第２の条件が、他社契約のデータを自社の契約のデータに変換する際に生ずる自社基準との齟齬に関する条件を含むようにしてもよい。例えば、他社の引き受け上限が一億円で、自社が五千万円である場合、変換時に一億円を五千万円に変換するような構成も可能であるが、顧客側からすれば更新時に説明もなく五千万円に自動変換されてしまうことは、好ましくない。従って、自社基準との齟齬に関する条件を含めて分類を判断して、顧客へ説明を行うようにする。

なお、第１データ格納部を参照して、第２の条件を満たしていないと判断された更新対象の契約について、更新の申込書ファイルを生成し、当該更新対象の契約の契約者メールアドレス宛に送信するステップをさらに含むようにしてもよい。オンラインで手続きできなくとも、更新の申込書ファイルをメール送信することができるだけでも、印刷及び郵送するような場合に比して業務効率化を図ることができる。

本発明に係る更新処理方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、保険契約の更新時における業務効率化を図ることができる。

図１に本発明の一実施の形態に係るシステム概要図を示す。例えば、企業の従業員である顧客Ａが操作する顧客端末Ａと、顧客Ｂが操作する顧客端末Ｂと、通常のメールサーバ４等が企業内のイントラネット１に接続されている。また、代理店サーバ３は、イントラネット１に直接接続している場合もあれば、例えばＶＰＮ（Virtual Private Network）などのセキュアなネットワーク２を介してイントラネット１に接続している。また、代理店サーバ３は、セキュアなネットワーク２を介して保険会社サーバ７に接続されている。なお、セキュアなネットワーク２は、１つのネットワークのみで構成される場合だけではないが、図１では簡略化して示している。代理店サーバ３は、代理店内のＬＡＮ（Local Area Network）１０にも接続されており、当該ＬＡＮ１０には代理店端末９も接続されている。同じように、保険会社サーバ７は、保険会社内のＬＡＮ１１にも接続されており、ＬＡＮ１１には保険会社端末８が接続されている。

顧客端末Ａ及び顧客端末Ｂは、例えばパーソナルコンピュータであり、例えばウェブ（Ｗｅｂ）ブラウザ機能とメーラ・クライアント機能を有している。すなわち、ＷｅｂサーバにアクセスしてＷｅｂページのブラウジングを行ったり、メールサーバ４とメールを送受信することができる。また、代理店端末９及び保険会社端末８も、例えばパーソナルコンピュータであり、例えばＷｅｂブラウザ機能とメーラ・クライアント機能を有している。但し、代理店端末９及び保険会社端末８は、代理店サーバ３又は保険会社サーバ７とのやりとりのため、専用のプログラムがインストールされている場合もある。

本実施の形態において主要な処理を実施する代理店サーバ３は、更新手続処理部３１と、通知処理部３２と、他社満期データ収集部３３とを含み、抽出案件データ格納部３４を管理している。また、保険会社サーバ７は、契約ＤＢ７１及び計上データ格納部７２を管理している。

図２に、代理店サーバ３の通知処理部３２に関連する機能ブロック図を示す。他社満期データ収集部３３において収集されたデータについては、入力データ格納部３３１に一旦格納されるようになっている。通知処理部３２のコンバータ３２０２は、他社と自社の特約等についての対応テーブル３２０１を参照して、入力データ格納部３３１に格納されている他社形式の他社満期データを、自社形式の他社満期データに変換し、他社満期ＤＢ３２０３に登録する。通知対象案件抽出部３２０５は、他社満期ＤＢ３２０３と、保険会社サーバ７の契約ＤＢ７１又は契約ＤＢ７１のレプリカとを参照して、例えば特定月に満期を迎える案件の抽出処理を実施し、抽出されたデータを抽出案件データ格納部３４に格納する。なお、契約データ更新処理部３２０６は、保険会社サーバ７の契約ＤＢ７１又は契約ＤＢ７１のレプリカを参照して、抽出案件データ格納部３４に格納されているデータに係る契約（自社契約）の異動や事故情報などが契約ＤＢ７１に登録された場合には、それに応じて抽出案件データ格納部３４のデータを更新する。第１振分処理部３２０８は、振分テーブル３２０７を参照して、抽出案件データ格納部３４に格納されているデータに係る案件の第１振分処理を実施し、オフライン（すなわち申込書）で更新手続きを行う案件をオフライン案件データ３４１として特定する。第２振分処理部３２１０は、振分ルールＤＢ３２０９を参照して、抽出案件データ格納部３４内のオフライン案件データ３４１以外の案件に対して第２振分処理を実施し、申込書ファイル（例えばＰＤＦファイル）を送付する案件（申込書ファイルの印刷物を送付する案件を含む）をファイル生成案件データ３４２として特定し、オンラインで更新手続きを行う案件をオンライン案件データ３４３として特定する。このように、抽出案件データ格納３４において、オフライン案件データ３４１、ファイル生成案件データ３４２及びオンライン案件データ３４３として、特定月に満期を迎える自社案件及び他社案件を一元的に管理できるように保持している。

通常申込書データ生成部３２１２は、抽出案件データ格納部３４に格納されたオフライン案件データ３４１を用いて、通常申込書データを生成し、通常申込書データ格納部３２１８に格納する。通常申込書データが生成された案件については、別途、通常申込書データ格納部３２１８に格納されたデータを用いて申込書Ａの印刷が行われる。申込書Ａは、例えば郵送又は企業内郵便で顧客に送付される。申込書ファイル生成部３２１３は、抽出案件データ格納部３４に格納されたファイル生成案件データ３４２を用いて、申込書ファイルを生成し、申込書ファイル格納部３２１５に格納する。ファイル送信部３２１６は、特定のタイミングで再度抽出案件データ格納部３４を参照して、申込書ファイルのメール送信が設定されている案件について、申込書ファイル格納部３２１５に格納された申込書ファイルを添付して、満期更新案内の電子メールＢを顧客宛に送信する。また、ファイル印刷部３２１７は、特定のタイミングで再度抽出案件データ格納部３４を参照して、申込書ファイルの印刷及び当該印刷物の送付が設定されている案件について、申込書ファイル格納部３２１５に格納された申込書ファイルを申込書Ｂとして印刷する。この申込書Ｂは、顧客に郵送などで送付される。なお、ファイル印刷部３２１７は、代理店の指示に応じて申込書ファイルの印刷を実行するようにしても良いし、代理店サーバ３の通知処理部３２には設けない場合もある。満期案内メール生成送信部３２１４は、抽出案件データ格納部３４に格納されたオンライン案件データ３４３を用いて、オンラインにて代理店サーバ３にアクセスし、更新手続きを実施するように促す満期案内のメールを生成し、電子メールＡとして送信する。

なお、顧客によっては、オンラインにて代理店サーバ３にアクセスし、更新手続きを実施するように促す満期案内のメールを受信しても、「申込書」で手続きすることを欲する場合もある。そのような場合には、区分変更処理部３２１１は、例えば顧客自ら又は代理店による変更入力を受け付け、それに応じてオンライン案件データ３４３として登録された案件のデータを、ファイル生成案件データ３４２となるように区分変更を行う。その場合、申込書ファイル生成部３２１３は、区分変更がなされた案件については随時申込書ファイルを生成して、申込書ファイル格納部３２１５に格納する。申込書ファイルをファイル送信部３２１６から電子メールＢとして送信しても良いし、ファイル印刷部３２１７にて申込書Ｂとして印刷して、代理店により送付するようにしても良い。このような配布手段についても区分変更処理部３２１１において指定可能とする。

図３に更新手続処理部３１に関連する機能ブロック図を示す。更新手続処理部３１の更新ユーザインターフェース部３１０１は、Ｗｅｂサーバ機能を有しており、顧客端末ＡのＷｅｂブラウザとデータのやり取りを行う。その際には、抽出案件データ格納部３４に格納されたオンライン案件データ３４３を用いる。また、顧客Ａが、更新手続きなどを途中で中断したい場合には、更新ユーザインターフェース部３１０１は、途中まで入力されたデータを抽出案件データ格納部３４に中断データ３４４として格納する。更新ユーザインターフェース部３１０１は、顧客Ａから更新申込みを受け付けると、当該更新申込みのデータを第１更新申込データ格納部３１０２に格納する。更新申込データ送信部３１０３は、第１更新申込データ格納部３１０２に格納された更新申込データを、セキュアなネットワーク２を介して保険会社サーバ７に送信する。

代理店において計上処理を実施する場合には、代理店は、代理店端末９を操作して申込書Ａ又は申込書Ｂのデータを入力する。そうすると、入力されたデータは代理店端末９から代理店サーバ３に送信され、当該代理店サーバ３における更新手続処理部３１の計上入力受付部３１０６により受け付けられる。計上入力受付部３１０６は、受け付けたデータを計上チェック処理部３１０５に出力する。計上チェック処理部３１０５は、受け付けたデータに対して所定の計上チェックを実施し、もし計上できないと判断した場合には、エラーを代理店端末９に返す。なお、計上チェック処理部３１０５は、抽出案件データ格納部３４又は契約ＤＢ７１を参照して、計上チェックを実施する。そして計上チェックにおいて問題がないと判断した場合には、更新の申込書に係る案件（元が他社契約であるものを含む）のデータに対応して、更新の申込書を受領したということを表すデータを抽出案件データ格納部３４に登録する。また、計上チェック済みの更新の申込書に係る更新申込データを第２更新申込データ格納部３１０４に格納する。更新申込データ送信部３１０３は、第２更新申込データ格納部３１０４に格納された更新申込データを、セキュアなネットワーク２を介して保険会社サーバ７に送信する。

一方、保険会社において計上処理を実施する場合、保険会社の担当者は、保険会社端末８を操作して申込書Ａ又は申込書Ｂのデータを入力し、入力されたデータは保険会社端末８から保険会社サーバ７に送信され、当該保険会社サーバ７の計上チェック処理部７０２により受け付けられる。そして、計上チェック処理部７０２は、契約ＤＢ７１を参照して、受け付けたデータに対して所定の計上チェック処理を実施する。もし計上できないと判断した場合には、エラーを保険会社端末８に返す。そして計上チェックにおいて問題がないと判断した場合には、更新の申込書に係る案件のデータを計上データ格納部７２に格納する。また、契約ＤＢ７１に、元の契約が自社契約であれば、更新手続きがなされたことを表すデータを元の契約データに対応して登録する。

また、更新申込データ受信部７０１は、代理店サーバ３における更新手続処理部３１の更新申込データ送信部３１０３から更新申込データを受信し、計上データ格納部７２に登録する。但し、更新申込データ受信部７０１が、受信した更新申込データを計上チェック処理部７０２に出力して、他の観点に係る計上チェックを実施する場合もある。

次に、図４乃至図８を用いて図１乃至図３に示したシステムにおける詳細な処理フローを説明する。まず、他社満期データ収集部３３は、他社満期案件データの取得処理を実施する（ステップＳ１）。他社満期データ収集部３３は、例えば顧客に保険料の試算を可能にする機能を有する。すなわち、例えば顧客端末Ａからのアクセスに応じて、保険料試算データ入力ページのデータを顧客端末Ａに送信し、当該保険料試算データ入力ページに入力されたデータを顧客端末Ａから受信し、試算結果を含むＷｅｂページ・データを顧客端末Ａに返信すると共に、顧客端末Ａから受信したデータを入力データ格納部３３１に格納する。例えば、自動車保険であれば、保険料試算データ入力ページに入力されるデータは、例えば満期日、登録番号、等級、型式、初度登録年月、年齢条件、氏名、住所、年齢、メールアドレス、電話番号、団体コード、場所コード、所属コード、社員コード、現在契約内容データなどを含む。

また、他社満期データ収集部３３は、例えば代理店端末９とのインターフェースを有する。すなわち、代理店端末９が、何らかの手段により得られた他社満期案件データのファイル（例えばＣＳＶ形式のファイル）を代理店サーバ３に送信すると、他社満期データ収集部３３は当該他社満期案件データのファイルを受信し、入力データ格納部３３１に格納する。

そして、通知処理部３２のコンバータ３２０２は、対応テーブル３２０１を参照して、入力データ格納部３３１に格納された他社満期案件データの変換処理を実施する（ステップＳ２）。対応テーブル３２０１には、例えば、他社の特約名と自社の特約名との対応関係のデータを含む。他にも数値の換算が必要な場合には当該換算に関するデータをも含む。従って、他社満期案件データの特約名（及び数値）を自社の特約名（及び数値）に変換するような処理を実施し、変換結果を他社満期ＤＢ３２０３に登録する。

次に、通知対象案件抽出部３２０５は、契約ＤＢ７１又は契約ＤＢ７１のレプリカと他社満期ＤＢ３２０３を参照して、例えば特定月（例えば３ヵ月後）に満期を迎える契約データ及び他社満期案件データを満期通知案件として抽出し、抽出案件データ格納部３４に格納する（ステップＳ３）。例えば契約ＤＢ７１又は契約ＤＢ７１のレプリカから抽出される契約データは、証券番号、満期日、登録番号、等級、型式、初度登録年月、年齢条件、特約データ、氏名、住所、年齢、メールアドレス、電話番号、団体コード、場所コード、所属コード、代理店コード（枝番を含む）、社員コード、事故データ、異動データ、申込書の希望データ（書面を希望するか否か）などを含み、抽出案件データ格納部３４に格納される際には、処理区分データ（初期値はNull）、更新手続進捗データ（初期値は未通知）等が付加される。処理区分データは、以下で説明する振分処理などにおいて設定される、オフライン案件、仮オンライン案件、ファイル生成案件（メール送信／印刷配布）、オンライン案件のいずれかを識別するコードである。更新手続進捗データは、未通知、通知済み、督促済み、手続き済みなど、各段階を識別するコードを含む。また、他社満期ＤＢ３２０３から抽出される他社満期案件データは、満期日、登録番号、等級、型式、初度登録年月、年齢条件、氏名、住所、年齢、メールアドレス、電話番号、団体コード、場所コード、所属コード、社員コード、現在契約内容データなどを含む。契約データと同様に、他社満期案件データについても、抽出案件データ格納部３４に格納する際に、処理区分データ、更新手続進捗データ等が付加される。

なお、抽出案件データ格納部３４に格納された契約データについては、契約データ更新処理部３２０６が、例えば契約ＤＢ７１において当該契約データについて変更等があれば、それを随時抽出案件データ格納部３４に格納された対応契約データに反映させる処理を実施する。また、ステップＳ３の処理結果については、抽出案件データ格納部３４ではなく、他のテンポラリのファイル等に格納して、以下で述べる第１及び第２振分処理の後に、抽出案件データ格納部３４に格納するようにしても良い。

その後、第１振分処理部３２０８は、振分テーブル３２０７を参照して、第１振分処理を実施する（ステップＳ５）。第１振分処理については、図５を用いて説明する。第１振分処理部３２０８は、振分テーブル３２０７を参照して、当該振分テーブル３２０７に登録されているデータを、案件データ（契約データ又は他社満期案件データ）が含むかを判断する（ステップＳ３１）。振分テーブル３２０７には、例えばオフライン設定すべき団体コード、場所コード、所属コード、代理店コード（代理店枝番を含む）を含む。すなわち、団体、所属、勤務場所、代理店（その支店などの場合も含む）によっては、オンラインでの対応が不可能である場合があるためである。もし、振分テーブル３２０７に登録されているデータを含む案件データについては、オフライン設定を行う（当該案件データの処理区分データ領域にオフライン案件であることを示すデータを登録する）（ステップＳ３５）。

一方、振分テーブル３２０７に登録されているデータを含まない案件データについては、当該案件データにおける申込書の希望データが「通常の申込書」を希望することを示しているか判断する（ステップＳ３３）。もし、案件データに係る顧客が通常の申込書を希望していると判断される案件データについては、オフライン設定を行う（当該案件データの処理区分データ領域にオフライン案件であることを示すデータを登録する）（ステップＳ３５）。

顧客が通常の申込書を特に希望していないとされる案件データについては、当該案件データの仮オンライン設定を実施する（ステップＳ３７）。すなわち、当該案件の処理区分データ領域に仮オフライン案件であることを示すデータを登録する。仮オンライン設定が行われた案件データについては、第２振分処理の対象となる。

なお、現在の日付と案件データの満期日とを比較して、満期日まで一定期間以上あるか判断する場合もある。通常の申込書を印刷して郵送するには一定期間必要であるから、本処理実施の際に印刷及び郵送に十分な期間がない場合にはオフライン設定をすべきではない。従って、満期時期まで一定期間以上ないと判断される案件データについては、当該案件データの処理区分データに仮オンライン設定を実施する場合もある。その場合には、申込書ファイル生成（印刷配布）設定がなされるようにする。

図４の処理フローに戻って、通常申込書データ生成部３２１２は、ステップＳ５においてオフライン設定がなされた案件データをオフライン案件データ３４１として特定し（ステップＳ７：Ｙｅｓルート）、当該オフライン案件データ３４１を用いて通常申込書データ生成処理を実施し、生成した通常申込書データを通常申込書データ格納部３２１８に格納する（ステップＳ９）。通常申込書データには、例えば、現在の契約内容をそのまま継続する場合の申込書だけではなく、お薦めの契約内容についての申込書を含める場合もある。代理店は、通常申込書データ格納部３２１８に格納されたデータを用いて、通常の申込書を印刷し、郵送などによって顧客に送付する（ステップＳ１１）。なお、ステップＳ１１については、代理店サーバ３が主要な処理主体ではないので、ここでは点線ブロックで示している。処理は、端子Ａを介して図８の処理に移行する。

次に、ステップＳ５において仮オンライン設定がなされた案件データについては（ステップＳ７：Ｎｏルート）、第２振分処理部３２１０が、振分ルールＤＢ３２０９を参照して第２振分処理を実施する（ステップＳ１３）。第２振分処理については図６を用いて説明する。第２振分処理部３２１０は、案件データが他社満期案件データであるか判断する（ステップＳ４１）。案件データが他社満期案件データではなく自社の契約データである場合にはステップＳ４５に移行する。一方、案件データが他社満期案件データである場合には、振分ルールＤＢ３２０９を参照して、当該案件データに含まれる現在契約内容データが、当社特約条件（場合によっては主契約の条件も含む）に合致するか判断する（ステップＳ４３）。例えば、他社の特約について一億円が保険金として設定されているが、自社の対応する特約では五千万円しか保険金として設定できない場合には、顧客がそのままの内容では契約を継続できない。よって、この点については顧客に何らかの説明等が必要となるため、オンラインによる更新手続きを勧めるのは好ましくない。よって、現在契約内容データが当社特約条件に合致しないと判断される案件データについては、ファイル生成設定を行う（当該案件データの処理区分データ領域にファイル生成案件であることを示すデータを格納する）（ステップＳ５３）。すなわち、ファイル生成案件データ３４２として特定される。なお、振分ルールＤＢ３２０９には、他社から自社への単純な移行に不都合が生ずる可能性のある特約等及びその条件についてのデータを含む。

一方、自社契約データである場合又は他社満期案件データであって当社特約条件等と合致する場合には、第２振分処理部３２１０は、振分ルールＤＢ３２０９を参照して、案件データに含まれる契約内容データを、現在の更新ユーザインターフェース部３１０１が取り扱うことができるか、すなわちシステム対応可能であるか判断する（ステップＳ４５）。例えば、付保率の低い特約（例えば二輪車や原付特約。また自然災害についての特約）についても、更新ユーザインターフェース部３１０１において受付可能な構成にすると、コストが非常に高くなってしまう場合がある。すなわち経営効率が下がることになるので、振分ルールＤＢ３２０９に、更新ユーザインターフェース部３１０１において受け付けられない特約など、契約内容についての項目を登録しておき、本ステップにおいて、案件データに含まれる契約内容データと、振分ルールＤＢ３２０９に登録されている項目とに重複があるか判断する。もし、振分ルールＤＢ３２０９に登録されている項目と重複があると判断される契約内容を含む案件データについては、当該案件データの処理区分データにファイル生成設定を行う（当該案件データの処理区分データ領域にファイル生成案件であることを示すデータを登録する）（ステップＳ５３）。すなわち、ファイル生成案件データ３４２として特定される。

システム対応可能であると判断された案件の場合には、第２振分処理部３２１０は、振分ルールＤＢ３２０９を参照して、案件データに含まれる団体コードから当該団体に固有の基準が存在するか確認し、存在する場合には当該団体固有の基準を満たしているか判断する（ステップＳ４７）。例えば、特定の団体については、ある特約について通常の条件に所定の条件を付加した形で引き受け可否を判断しなければならないという場合には、当該特約と所定の条件とを振分ルールＤＢ３２０９に登録しておく。なお、特定の団体については、ある特約について通常の条件に代わって低い基準で引き受け可否を判断する場合もある。その場合には、その特約と低い基準についての条件とを振分ルールＤＢ３２０９に登録しておく。このような特約及び条件については、団体の特性を解析して特定する必要がある。もし、団体固有の基準を満たしていないとされる案件データについては、当該案件データの処理区分データにファイル生成設定を行う（当該案件データの処理区分データ領域にファイル生成案件であることを示すデータを登録する）（ステップＳ５３）。すなわち、ファイル生成案件データ３４２として特定される。

一方、団体固有の基準を満たしていると判断された場合には、第２振分処理部３２１０は、振分ルールＤＢ３２０９を参照して、案件データに含まれる契約内容データ等が契約更新上の問題を有しているか判断する（ステップＳ４９）。ここでは、従来から計上チェックとして保険契約の引き受け可否の判断を行っていたものと同様の処理を実施する。判断項目及びその基準については、振分ルールＤＢ３２０９に予め設定しておく。ステップＳ４９では、例えば、（１）保険金額のチェックと、（２）特約等の組み合わせのチェックと、（３）事故暦のチェックとを実施する。（１）のチェックを行うため、全体の保険金額と、特約毎の保険金額との閾値を予め振分ルールＤＢ３２０９に格納しておき、案件毎に閾値と当該案件の対応する数値とを比較することにより、更新の可否を判断する。より具体的には、搭乗者傷害特約（日数払い）の場合、予め設定された代理店の引受可能限度を閾値として予め振分ルールＤＢ３２０９に登録しておき、搭乗者傷害特約が付帯されていた案件については当該案件の保険金額が上記引受可能限度額以下であるか判断する。また、車両修理費用補償特約の付帯は車両保険金額が所定の金額以上であることが条件となっているので、車両保険金額という項目と金額と車両修理費用補償特約という項目とをセットで振分ルールＤＢ３２０９に登録しておき、車両修理費用補償特約が付帯されていた案件については当該案件の車両保険金額が所定金額未満になっているか判断する。さらに、現在の内容で継続する場合であっても、顧客の自動車が古くなると現在の車両保険金額を維持できない場合があるので、車両保険という項目と条件（自動車の年数及び基準）とを登録しておく。また、傷害保険の保険金額が所定の基準以上である場合にも、問題が生ずる場合があるので、傷害保険という項目と条件（閾値となる保険金額）とを登録しておく。（２）のチェックを行うため、予め不可能な特約等の組み合わせを振分ルールＤＢ３２０９に登録しておき、そのような組み合わせに合致しないことを各案件につき判断する。例えば、子供年齢条件追加特約を付帯する場合には、臨時運転者特約を重ねて付帯できないので、この組み合わせを振分ルールＤＢ３２０９に格納しておく。（３）については、予め振分ルールＤＢ３２０９に、事故回数の閾値、支払い保険金額の閾値等を登録しておき、現在の契約に対応して登録されている事故回数、支払い保険金額とをそれぞれ閾値と比較することにより判断する。なお、ステップＳ４７において、通常の条件に代わって低い基準で引き受け可否を判断する場合には、本ステップではその項目について通常の条件では判断しない。

契約内容データ等が契約更新上の問題を有していないと判断される案件データについては、オンライン設定を行う（当該案件データの処理区分データ領域にオンライン案件であることを示すデータを格納する）（ステップＳ５１）。すなわち、オンライン案件データ３４３として特定される。一方、契約内容データ等が契約更新上の問題を有していると判断される案件データについては、ファイル生成設定を行う（当該案件データの処理区分データ領域にファイル生成案件であることを示すデータを登録する）（ステップＳ５３）。このようにして元の処理に戻る。

図４の説明に戻って、満期案内メール生成送信部３２１４は、ステップＳ１３においてオンライン設定がなされた案件データをオンライン案件データ３４３として特定し（ステップＳ１５：Ｙｅｓルート）、当該オンライン案件データ３４３を用いて満期案内メール（電子メールＡ）を生成し、オンライン案件データ３４３に係る顧客宛に送信する（ステップＳ１７）。満期案内メールについては、例えば「満期日２００４年５月ｘ日が近くなりましたので、以下のＵＲＬ（Uniform Resource Locator：代理店サーバ３における更新手続処理部３１の更新ユーザインターフェース部３１０１のＵＲＬ）にアクセスして、更新手続きをお願い申し上げます」といったように手続きを促す文章が含まれる。例えば雛型文章に案件データに固有のデータを埋め込むようにすればよい。顧客Ａは、顧客端末Ａを操作して、メールサーバ４から満期案内メールを受信して表示装置にさせる。これによって顧客Ａは満期が近づいたこと及びアクセス先ＵＲＬとを把握することができる。以下では、顧客によるアクセスに応じて処理が開始される。

また、申込書ファイル生成部３２１３は、ステップＳ１３においてファイル生成設定された案件データをファイル生成案件データ３４２として特定し（ステップＳ１５：Ｎｏルート）、当該ファイル生成案件データ３４２を用いて申込書ファイルを生成し、申込書ファイル格納部３２１５に格納する（ステップＳ１９）。なお、申込書ファイル生成部３２１３は、代理店が操作する代理店端末９とのデータのやりとりに基づき申込書ファイルを生成するようにしても良い。すなわち、代理店は現在の契約内容などを確認の上、お薦めの契約内容を指定し、それに応じて申込書ファイル生成部３２１３が申込書ファイルを生成する。また、例えば図６の処理フローにおいてステップＳ５３のファイル生成設定に移行する元のステップに応じた申込書データの雛型を用意しておき、その雛型申込書データを用いるようにしても良い。

そして、ファイル送信部３２１６は、抽出案件データ格納部３４のファイル生成案件データ３４２を参照して、まずファイル送信する案件データを特定し（ステップＳ２１：Ｙｅｓルート）、申込書ファイル格納部３２１５に格納されている申込書ファイルを、満期通知メール（電子メールＢ）に添付して、顧客宛に送信する（ステップＳ２３）。満期通知メールには、例えば「満期日２００４年５月ｘ日が近くなりましたので、添付の申込書ファイルを印刷し、記入捺印の上ご返送ください」といったように手続きを促す文章が含まれる。本実施の形態では、原則として申込書ファイルのファイル送信を実施するように、処理区分データ領域に「ファイル生成案件（メール送信）」と設定されているため、ほとんどの案件でファイル送信が行われる。そして、例えば顧客Ａは、顧客端末Ａを操作して、メールサーバ４から満期通知メールを受信し、添付ファイルとなっている申込書ファイルを自ら印刷する。そして申込書ファイルの印刷物は、記入捺印の上、郵送などにより代理店に返送される。処理は端子Ａを介して図８に移行する。

但し、例えば顧客からの要望に応じて代理店が代理店端末９を操作して、区分変更処理部３２１１に「申込書ファイルの印刷物の送付」への区分変更を命じた場合には、当該区分変更処理部３２１１は、例えばファイル生成案件データ３４２の処理区分データ領域にファイル生成案件（印刷配布）であることを示すデータを登録する。

このような場合、ファイル送信ではなく郵送であるので、ファイル印刷部３２１７は、抽出案内データ格納部３４のファイル生成案件データ３４２を参照して、申込書ファイル生成（印刷配布）が処理区分データ領域に登録されている案件データを特定し（ステップＳ２１：Ｎｏルート）、当該申込書ファイルを印刷して、申込書Ｂを郵送する（ステップＳ２５）。処理は端子Ａを介して図８に移行する。なお、顧客は、申込書ファイルの印刷物に記入捺印の上、郵送などにより代理店に返送する。

以上のような処理を実施することにより、様々な条件に従って適切な満期通知を顧客に行うことができるようになる。

次に後半の処理フローについて図７及び図８を用いて説明する。まず、オンライン案件データ３４３として抽出案件データ格納部３４に登録された案件についての更新手続処理について図７を用いて説明する。例えば顧客Ａは、顧客端末Ａを操作して、更新申込ページにアクセスさせる（ステップＳ６１）。なお、この段階までに認証処理は終了しているものとする。代理店サーバ３における更新手続処理部３１の更新ユーザインターフェース部３１０１は、顧客端末Ａからのアクセスに応じて、抽出案件データ格納部３４の該当するオンライン案件データ３４３を用いて更新申込ページ・データを生成し、顧客端末Ａに送信する（ステップＳ６３）。顧客端末Ａは、代理店サーバ３から更新申込ページ・データを受信し、表示装置に表示する（ステップＳ６５）。なお、更新申込ページには、保険金額など保険契約の内容を指定するための入力又は選択欄が設けられている。但し、初期的には、抽出案件データ格納部３４に含まれる該当オンライン案件データ３４３に基づき、現在の契約内容を提示する。また、お薦めのプランを合わせて提示するようにしても良い。顧客Ａは、更新申込ページにおいて、希望する条件を設定して、送信ボタンをクリックする。なお、更新申込ページは複数ページで構成される場合もある。上で述べたように、付保率が低い特約などについては、更新申込ページでは指定することができないようになっている。

顧客端末Ａは、顧客Ａからの入力を受け付け、送信指示に応じて入力データを代理店サーバ３に送信する（ステップＳ６７）。代理店サーバ３における更新手続処理部３１の更新ユーザインターフェース部３１０１は、顧客端末Ａから入力データを受信すると、更新申込データとして第１更新申込データ格納部３１０２に格納する（ステップＳ６９）。この際、例えばデータ・チェックなどを実施するが、あくまで形式的なチェックに留まる。なお、このデータ・チェックにおいてエラーを検出した場合には、再入力及び確認を求めるため、ステップＳ６３に戻る。もしデータ・チェックでエラーが発生していなければ、第１更新申込データ格納部３１０２に格納する。

そして、更新ユーザインターフェース部３１０１は、受付完了ページ・データを生成し、顧客端末Ａに送信する（ステップＳ７１）。これに対して、顧客端末Ａは、代理店サーバ３から受付完了ページ・データを受信し、表示装置に表示する（ステップＳ７３）。例えば、「ＡＡＡ様、契約更新の申込みを受け付けました。ありがとうございました。追って、証書などをお送りいたします」といったような文章が含まれる。これにて、顧客Ａは、オンラインで簡単に更新手続きを行うことができるようになり、利便性が高まる。

また、更新ユーザインターフェース部３１０１は、第１更新申込データ格納部３１０２に格納した更新申込データについて、ネットワーク経由での申込みである場合に付保する特約を付保するように、当該特約データを更新申込データに付加する（ステップＳ７５）。また、更新ユーザインターフェース部３１０１は、更新手続済みを、抽出案件データ格納部３４における該当オンライン案件データ３４３の更新手続進捗データ領域に設定する（ステップＳ７７）。これにより、督促の必要がない案件として把握されるようになる。

その後、更新申込データ送信部３１０３は、第１更新申込データ格納部３１０２に格納された更新申込データを保険会社サーバ７に送信する（ステップＳ７９）。保険会社サーバ７の更新申込データ受信部７０１は、代理店サーバ３から更新申込データを受信し（ステップＳ８１）、計上データとして計上データ格納部７２に格納する（ステップＳ８３）。このように第２振分処理においてこれまでの計上チェック以上のチェックを行っているため、実際の更新申込みを受け付けた後には、計上チェックをせず形式チェック程度で済ませることができる。これにより計上時のエラーにて顧客に戻すようなことがなくなり、業務の効率化が実現されている。

次に、申込書Ａ又は申込書Ｂが顧客から戻された場合の処理について図８を用いて説明する。この図８は、図４における端子Ａを介して移行した後の処理となる。まず代理店は、申込書Ａ又は申込書Ｂを顧客Ａから受領する（ステップＳ９１）。これはシステムの処理ではないので点線ブロックで示している。そして、代理店で計上する場合には（ステップＳ９３：Ｙｅｓルート）、代理店は代理店端末９を用いて申込書Ａ又は申込書Ｂの更新申込データを入力する（ステップＳ９５）。このステップもシステムの処理ではないので点線ブロックで示している。そして、代理店端末９は、入力された更新申込データを受け付け、代理店サーバ３における更新手続処理部３１の計上入力受付部３１０６に送信する（ステップＳ９７）。なお、受け付け時に形式チェックを行う場合もある。計上入力受付部３１０６は、受信した更新申込データを計上チェック処理部３１０５に出力し、計上チェック処理部３１０５は、契約ＤＢ７１、そのレプリカ又は抽出案件データ格納部３４を参照して、更新申込データに対して計上チェックを実施する（ステップＳ９９）。この計上チェックについては、上でも述べたように通常行われている計上チェックであるからここでは説明を省略する。もし、計上エラーが発生した場合には、代理店端末９に対してエラーを通知する。代理店端末９を操作している代理店は、エラーに応じて必要な手続き等を実施する。

一方、計上チェックが正常に終了した場合には、計上チェック処理部３１０５は、抽出案件データ格納部３４において該当する案件データを特定し、当該案件データにおける更新手続進捗データ領域に更新手続済みを設定する。さらに、更新申込データを第２更新申込データ格納部３１０４に格納する。

そして、更新申込データ送信部３１０３は、第２更新申込データ格納部３１０４に格納されている更新申込データを保険会社サーバ７に送信する（ステップＳ１０１）。これに対して保険会社サーバ７の更新申込データ受信部７０１は、代理店サーバ３から更新申込データを受信し（ステップＳ１０３）、計上データ格納部７２に格納する（ステップＳ１０５）。この際他の観点にて計上チェックを実施する場合もある。

また、代理店計上ではなく保険会社計上の場合（ステップＳ９３：Ｎｏルート）、代理店は受領した申込書Ａ又は申込書Ｂを保険会社に送付する（ステップＳ１０７）。保険会社では、代理店から申込書Ａ又は申込書Ｂを受領し、保険会社の担当者は、申込書Ａ又は申込書Ｂの計上入力を保険会社端末８に対して行う（ステップＳ１０９）。ここまではシステムの処理ではないので点線ブロックで示している。保険会社端末８は、保険会社の担当者からの入力を受け付け、更新申込データとして保険会社サーバ７に送信する（ステップＳ１１１）。保険会社サーバ７の計上チェック処理部７０２は、更新申込データに対して計上チェックを実施する（ステップＳ１１３）。この計上チェックについては、上でも述べたように通常行われている計上チェックであるからここでは説明を省略する。もし、計上エラーが発生した場合には、保険会社端末８に対してエラーを通知する。保険会社端末８を操作している保険会社の担当者は、エラーに応じて必要な手続き等を実施する。

一方、計上チェックが正常に終了した場合には、計上チェック処理部７０２は、更新申込データを計上データ格納部７２に格納する（ステップＳ１１５）。なお、契約ＤＢ７１において更新申込データに対応する契約データを特定し、当該契約データに更新手続進捗データを登録できるようになっている場合には、更新手続済みを設定する。

このように書面として申込書Ａ又は申込書Ｂを受領した場合には、計上チェックを通常どおり実施する必要がある。一方、申込書を使用しないオンライン案件については、最初にオンライン案件の適格性確認において自動的にチェックしているため、更新申込み後の計上チェックを行わず、自動的に計上する。従って、業務の効率化を図ることができる。

また、更新手続に関連する案件のデータは抽出案件データ格納部３４において一元管理されるため、代理店では管理上の省力化を図ることができ、この点において業務効率の改善が図られている。

なお上では詳しく述べなかったが、代理店サーバ３には、顧客に対しては、抽出案件データ格納部３４に格納されているデータを用いて現在の契約の照会機能を提供している。場合によっては、異動申請を可能にする場合もある。また、顧客が代理店サーバ３にログインする際に使用するＩＤ及びパスワードの設定及び変更や、メールアドレスの登録及び変更、抽出案件データ格納部３４に格納されている案件の各種検索（募集形態、進捗状況、満期日、顧客コード、団体コード、場所コード、メールアドレス、保険種別、契約内容、保険料など）、上で述べた処理区分の変更、保険料試算、契約照会、申込書ファイル作成・印刷、メール送信等の機能を、代理店向けに提供している。

また、図９に示すように、本実施の形態における顧客端末Ａ、顧客端末Ｂ、メールサーバ４、代理店サーバ３、保険会社サーバ７、代理店端末９、保険会社端末８は、コンピュータであって、当該コンピュータにおいては、メモリ２０１とＣＰＵ２０３とハードディスク・ドライブ（ＨＤＤ）２０５と表示装置２０９に接続される表示制御部２０７とリムーバブル・ディスク２１１用のドライブ装置２１３と入力装置２１５とネットワークに接続するための通信制御部２１７とがバス２１９で接続されている。オペレーティング・システム（ＯＳ）及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２０５に格納されており、ＣＰＵ２０３により実行される際にはＨＤＤ２０５からメモリ２０１に読み出される。必要に応じてＣＰＵ２０３は、表示制御部２０７、通信制御部２１７、ドライブ装置２１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２０１に格納され、必要があればＨＤＤ２０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２０３、メモリ２０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラム（端末認証プログラム及び画像処理プログラムを含む）とが有機的に協働することにより、上で述べたような各種機能を実現する。

以上本発明に係る一実施の形態を説明したが、本発明はこれに限定されない。すなわち、図１乃至図３に示した機能ブロック図は一例であって、必ずしも実際のプログラム・モジュールに対応しない場合もある。例えば、代理店サーバ３は、一台のコンピュータではなく複数台のコンピュータにより上で述べた機能を実現する場合もある。例えば、更新手続処理部３１については、顧客の団体が管理するイントラネット１に直接接続されたサーバに組み込まれる場合もある。また、処理フローについても、順番を入れ替えたり、並列に実行される可能性のあるステップもある。適用対象の保険は、自動車保険だけではなく、他の保険であっても良い。

なお、抽出案件データ格納部３４には、各案件につき契約内容データが格納されているような構成を示したが、例えば契約ＤＢ７１又はそのレプリカなどを用いて申込書ファイル又は申込書データを生成する場合にはファイル生成案件及びオフライン案件については契約内容データを抽出案件データ格納部３４に格納しない場合もある。

本発明の一実施の形態におけるシステム概要図である。 通知処理部に関連する機能ブロック図である。 更新手続処理部に関連する機能ブロック図である。 本発明の実施の形態における第１の処理フローを示す図である。 第１振分処理の処理フローを示す図である。 第２振分処理の処理フローを示す図である。 本発明の実施の形態における第２の処理フローを示す図である。 本発明の実施の形態における第３の処理フローを示す図である。 コンピュータの機能ブロック図である。

符号の説明

１ イントラネット ２ セキュアなネットワーク
３ 代理店サーバ ４ メールサーバ
７ 保険会社サーバ ８ 保険会社端末
９ 代理店端末
１０，１１ ＬＡＮ
３１ 更新手続処理部 ３２ 通知処理部
３３ 他社満期データ収集部

Claims (10)

1. 更新対象の契約データを格納する処理対象データ格納部を参照して、各更新対象の契約につき、特定の形態に係る申込書を作成すべき更新対象の契約を特定するための第１の条件を満たしているか判断し、前記第１の条件を満たしていると判断された更新対象の契約の契約データに対応して前記第１データ格納部に前記特定の形態に係る申込書を生成すべきことを表す第１のデータを登録するステップと、
   前記処理対象データ格納部を参照して、前記第１の条件を満たしていると判断された更新対象の契約を除く各更新対象の契約につき、当該更新の申込が行われた後の計上時のチェック処理を省略するための条件を含む第２の条件を満たしているか判断し、前記第２の条件を満たしていないと判断された更新対象の契約の契約データに対応して前記第１データ格納部に申込書ファイルを生成すべきことを表す第２のデータを登録し、前記第２の条件を満たしていると判断された更新対象の契約の契約データに対応して前記第１データ格納部にオンラインで手続きすべきことを表す第３のデータを登録するステップと、
   を含み、コンピュータにより実行される更新処理方法。
2. 前記第１データ格納部において前記第３のデータが対応して登録されている更新対象の契約について、ネットワークに接続された更新受付サーバにおいて更新申込を受け付けた場合、当該更新申込については前記計上時チェックを省略して更新申込のデータを登録するステップ、
   をさらに含む請求項１記載の更新処理方法。
3. 前記第２の条件が、前記更新受付サーバの機能上の制約から前記更新受付サーバにおいて受け付けることができない契約内容を包含しないという第３の条件を含む請求項２記載の更新処理方法。
4. 前記第１データ格納部が、特定の団体についての更新対象の契約データを格納しており、
   前記第２の条件が、前記特定の団体特有の条件を含む
   ことを特徴とする請求項１乃至３のいずれか１つ記載の更新処理方法。
5. 満期から所定期間内の他社契約のデータを格納する第２データ格納部を参照して、前記他社契約のデータを自社の契約のデータに変換し、前記更新対象の契約データとして前記処理対象データ格納部に格納するステップ
   をさらに含む請求項１乃至４のいずれか１つ記載の更新処理方法。
6. 前記第２の条件が、前記他社契約のデータを自社の契約のデータに変換する際に生ずる自社基準との齟齬に関する条件を含む
   ことを特徴とする請求項５記載の更新処理方法。
7. 前記第１データ格納部を参照して、前記第２の条件を満たしていないと判断された更新対象の契約について、更新の申込書ファイルを生成し、当該更新対象の契約の契約者メールアドレス宛に送信するステップ
   をさらに含む請求項１乃至６のいずれか１つ記載の更新処理方法。
8. 前記第３の条件が、付保率が所定の基準以下である所定の特約を含まないという条件であることを特徴とする請求項３記載の更新処理方法。
9. 請求項１乃至８のいずれか１つ記載の更新処理方法をコンピュータに実行させるためのプログラム。
10. 更新対象の契約データを格納する処理対象データ格納部を参照して、各更新対象の契約につき、特定の形態に係る申込書を作成すべき更新対象の契約を特定するための第１の条件を満たしているか判断し、前記第１の条件を満たしていると判断された更新対象の契約の契約データに対応して前記第１データ格納部に前記特定の形態に係る申込書を生成すべきことを表す第１のデータを登録する手段と、
    前記処理対象データ格納部を参照して、前記第１の条件を満たしていると判断された更新対象の契約を除く各更新対象の契約につき、当該更新の申込が行われた後の計上時のチェック処理を省略するための条件を含む第２の条件を満たしているか判断し、前記第２の条件を満たしていないと判断された更新対象の契約の契約データに対応して前記第１データ格納部に申込書ファイルを生成すべきことを表す第２のデータを登録し、前記第２の条件を満たしていると判断された更新対象の契約の契約データに対応して前記第１データ格納部にオンラインで手続きすべきことを表す第３のデータを登録する手段と、
    を有する更新処理装置。

Images