(57)【要約】【課題】  保険契約の保全手続を効率的に処理するために有益な情報を提供し、保全業務を円滑に行う。【解決手段】  契約識別情報及び請求内容を含む請求情報の入力を受け付け、保全手続の種別を判定する工程、契約識別情報に基づいて、契約情報ＤＢから請求対象の契約を特定し、その契約の変更履歴情報を検索する工程、保全手続の種別に基づいて、決裁基準テーブルから当該保全手続の決裁基準を特定する工程、決裁基準に関連付けられた変更履歴と、契約情報ＤＢから検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、決裁レベルを判定して出力する工程、請求に係る保全手続が決裁レベルに従って決了したことを示す決裁済情報の入力を受け付ける工程と、決裁済情報が入力された場合に、請求情報に従って前記契約情報ＤＢに格納された契約情報及び変更履歴情報を夫々更新する工程とを備えた。【選択図】  図１
2009230380.tif 000002
【特許請求の範囲】
【請求項１】
入力手段、出力手段、制御手段、及びコンピュータソフトウェアを格納する記憶装置を備えた保険会社のコンピュータシステムによって、生命保険契約を締結した顧客からの保険金の請求、契約内容の変更などの保全手続の処理を支援する方法であって、
前記記憶装置は、
保険契約者や被保険者の個人情報、特約の種別、保険料（掛金）の支払い方法などの生命保険契約の情報と、これらの情報が変更された日付及び項目を含む変更履歴情報と、を夫々契約識別情報に関連付けて格納する契約情報データベース（ＤＢ）と、
多数の保全手続の種別ごとに、少なくとも前記変更履歴との関係で設定された決裁基準を格納する決裁基準テーブルと、を備え、
この方法は、
請求受付手段が、契約識別情報及び請求内容を含む請求情報の入力を受け付ける請求受付工程と、
検索手段が、入力された契約識別情報に基づいて、前記契約情報ＤＢから請求対象の契約を特定し、その契約の変更履歴情報を検索する検索工程と、
決裁基準特定手段が、前記受け付けた請求情報に基づいて判定された保全手続の種別で前記決裁基準テーブルを検索し、当該保全手続の決裁基準を特定する決裁基準特定工程と、
決裁レベル判定手段が、特定された決裁基準に関連付けられた変更履歴と、契約情報ＤＢから検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、この保全手続の決裁権限や必要書類などの決裁レベルを判定して出力する決裁レベル判定工程と、
決裁済情報受付手段が、請求に係る保全手続が前記判定された決裁レベルに従って決了したことを示す決裁済情報の入力を受け付ける決裁済情報受付工程と、
決裁済情報が入力された場合に、契約情報更新手段が、前記請求情報に従って前記契約情報ＤＢに格納された契約情報及び変更履歴情報を夫々更新する契約情報更新工程と
を備えたことを特徴とする方法。
【請求項２】
請求項１の方法において、
前記決裁レベル判定工程は、契約情報ＤＢから検索された契約情報の更新日及び更新項目と、判定された保全手続の種別及び請求内容と、決裁基準テーブルに登録された当該保全手続の種別及び変更履歴の関連性と、に従って、決裁レベルを判定することを特徴とする方法。
【請求項３】
請求項１の方法において、
前記記憶装置は、各保全手続に必要な添付書類の種類及び各保全手続の請求書フォーマットを、保全手続の種別に関連付けて格納する請求書情報データベース（ＤＢ）を備え、
この方法は、さらに、
請求書情報検索手段が、前記決裁レベル判定工程で判定された決裁レベルと、前記請求受付工程で判定された保全手続の種別とに基いて、前記請求書情報ＤＢから当該手続の請求書フォーマット及び必要な添付書類の情報を検索する請求書情報検索工程と、
請求書出力手段が、検索された請求書フォーマットに、添付書類の情報と抽出された契約情報とを合成して請求書データを生成し、保全手続の請求書として顧客に提示するために出力する請求書出力工程と
を備えたことを特徴とする方法。
【請求項４】
請求項３の方法であって、
前記記憶装置は、保全手続の受け付けから決了までの処理ステータスを前記契約識別情報若しくは保全手続の識別情報に関連付けて格納する進捗管理データベース（ＤＢ）を備え、
この方法は、さらに、前記請求受付手段が顧客からの請求情報の入力を受け付けた場合、前記請求書出力手段が保全手続の請求書を出力した場合、及び前記決裁済情報受付手段が決裁済情報の入力を受け付けた場合に、進捗管理手段が前記各手段から契約識別情報若しくは保全手続識別情報を含む進捗データを夫々受け取り、前記進捗管理ＤＢから該当する保全手続を検索して進捗情報を更新する進捗管理工程を備えた
ことを特徴とする方法。
【請求項５】
請求項４の方法において、
前記契約情報ＤＢは、契約情報の特定の項目について顧客から保全手続以外の簡易変更請求手続によって変更された変更履歴情報も格納するものであり、
前記決裁基準テーブルは、保全手続の種別ごとに、保全手続若しくは簡易変更請求手続の何れかによって変更された変更履歴との関係で設定された決裁基準を格納するものであり、
前記請求受付工程は、契約情報の特定の項目について顧客から請求情報の入力を受け付けた場合に、保全手続か簡易変更請求手続かを判定し、保全手続である場合にさらに保全手続の種別を判定するものである
ことを特徴とする方法。
【請求項６】
請求項４の方法において、
前記進捗管理ＤＢは、１の契約識別情報について、複数の保全手続の処理ステータス、若しくは保全手続と簡易変更手続との処理ステータスを関連付けて格納するものであり、
前記決裁基準テーブルは、１の契約に関して同時期に、複数の保全手続若しくは保全手続と簡易変更手続とが係属した場合の決裁順序、決裁レベル、若しくは必要な添付書類の何れかを含む第２の決裁基準を各保全手続の種別に関連付けて格納するものであり、
前記決裁レベル判定工程は、決裁前の第１の保全手続と同一の契約に対する第２の保全手続若しくは簡易変更手続を受け付けた場合に、第１又は第２の保全手続の種別、若しくは簡易変更手続の種別に基づいて決裁基準テーブルから第２の決裁基準を検索して決裁レベルを判断するものである
ことを特徴とする方法。
【請求項７】
請求項３の方法において、
前記記憶装置は、請求書の記載内容や添付書類の適否を判断するためのチェックポイントを保全手続の種別に関連付けて格納するチェックポイントテーブルを備え、
この方法は、さらに、
チェックポイント出力手段が、前記請求書出力工程で顧客に提示され、その顧客から返送された請求書の保全手続の種別が入力手段を介して入力された場合に、その保全手続の種別に基づいて前記チェックポイントテーブルから当該保全手続の１又は２以上のチェックポイントを抽出して出力装置に出力するチェックポイント出力工程と、
チェックポイント入力受付手段が、前記出力手段に出力された１又は２以上のチェックポイントについてチェック済みの情報の入力を受け付けるチェックポイント入力受付工程と、
チェックポイント監視手段が、全てのチェックポイントについてチェック済情報が入力されたかを監視し、チェック済情報が入力された場合に前記決裁レベル判定工程で判定された決裁レベルに従って決裁機関に当該保全手続の決裁指示情報を出力するチェックポイント監視工程と
を備えたことを特徴とする方法。
【請求項８】
請求項７の方法において、
記憶装置は、請求書の記載項目の不備の説明文、添付書類の不備の説明文、及びそれらの不備を解消する補正内容の説明文を不備の種類に関連付けて格納する案内文テーブルを備え、
この方法は、さらに、
前記チェックポイント入力受付工程で、顧客から返送された請求書に不備が発見された場合に、案内文作成手段が、前記案内文テーブルからその不備と補正内容と不備を解消する補正内容の説明文とを検索し、これらを案内文フォームに合成して顧客への案内文書を作成する案内文作成工程を備えた
ことを特徴とする方法。
【請求項９】
請求項１の方法において、
前記決裁基準テーブルは、前記変更履歴に加えて、保全手続によって顧客に金銭の支払いが発生するか及びその支払い金額との関係で設定された決裁基準を格納するものであり、
前記決裁レベル判定工程は、受け付けた保全手続の種別が金銭の支払いを伴うものである場合に、その支払い金額に応じた決裁基準を前記決裁基準テーブルから特定して決裁レベルを判定する
ことを特徴とする方法。
【請求項１０】
請求項１の方法において、
前記契約情報ＤＢは、１の顧客が複数の保険契約を締結している場合に、全ての契約の変更履歴を顧客の識別情報に関連付けて格納するものであり、
前記検索工程は、契約識別情報に基づいて、前記契約情報ＤＢからこの顧客の全ての契約に関する変更履歴情報を検索するものであり、
前記決裁レベル判定工程は、決裁基準特定工程で特定された決裁基準に関連付けられた変更履歴と、前記契約情報ＤＢから検索された当該顧客の全ての契約の変更履歴情報の何れかが該当するかに基づいて決裁レベルを判定するものである
ことを特徴とする方法。
【請求項１１】
請求項１０の方法において、
前記検索工程は、入力された契約識別情報に基づいて顧客の識別情報を特定し、この顧客識別情報に基づいて前記契約情報ＤＢからその顧客の他の全ての契約を検索するものであり、
この方法は、さらに、
請求内容判別手段が、前記受け付けた保全手続の請求内容が、当該顧客の複数の契約に共通する項目のうち特定の項目に関する変更であるかを判別する請求内容判別工程と、
保全手続の請求内容が特定の項目の変更である場合に、アラーム出力手段が、前記検索された全ての契約に関する変更履歴情報を参照して、この特定項目の変更が他の契約について行われていない場合に所定のアラームを出力するアラーム出力工程と
を備えたことを特徴とする方法。
【請求項１２】
入力手段、出力手段、制御手段、及びコンピュータソフトウェアを格納する記憶装置を備え、生命保険契約を締結した顧客からの保険金の請求、契約内容の変更などの保全手続の処理を支援するシステムであって、
保険契約者や被保険者の個人情報、特約の種別、保険料（掛金）の支払い方法などの生命保険契約の情報と、これらの情報が変更された日付及び項目を含む変更履歴情報と、を夫々契約識別情報に関連付けて格納する契約情報データベース（ＤＢ）と、
多数の保全手続の種別ごとに、少なくとも前記変更履歴との関係で設定された決裁基準を格納する決裁基準テーブルと、
契約識別情報及び請求内容を含む請求情報の入力を受け付ける請求受付手段と、
入力された契約識別情報に基づいて、前記契約情報ＤＢから請求対象の契約を特定し、その契約の変更履歴情報を検索する検索手段と、
前記受け付けた請求情報に基づいて判定された保全手続の種別に基づいて、前記決裁基準テーブルから当該保全手続の決裁基準を特定する決裁基準特定手段と、
特定された決裁基準に関連付けられた変更履歴と、契約情報ＤＢから検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、この保全手続の決裁権限や必要書類などの決裁レベルを判定して出力する決裁レベル判定手段と、
請求に係る保全手続が前記判定された決裁レベルに従って決了したことを示す決裁済情報の入力を受け付ける決裁済情報受付手段と、
決裁済情報が入力された場合に、前記請求情報に従って前記契約情報ＤＢに格納された契約情報及び変更履歴情報を夫々更新する契約情報更新手段と
を備えたことを特徴とするシステム。
【請求項１３】
入力手段、出力手段、制御手段、及びコンピュータソフトウェアを格納する記憶装置を備えた保険会社のコンピュータシステムに、生命保険契約を締結した顧客からの保険金の請求、契約内容の変更などの保全手続の処理を支援する処理を実行させるためのコンピュータプログラムであって、
前記記憶装置は、
保険契約者や被保険者の個人情報、特約の種別、保険料（掛金）の支払い方法などの生命保険契約の情報と、これらの情報が変更された日付及び項目を含む変更履歴情報と、を夫々契約識別情報に関連付けて格納する契約情報データベース（ＤＢ）と、
多数の保全手続の種別ごとに、少なくとも前記変更履歴との関係で設定された決裁基準を格納する決裁基準テーブルと、を備え、
このプログラムは、
請求受付手段が、契約識別情報及び請求内容を含む請求情報の入力を受け付ける請求受付手順と、
検索手段が、入力された契約識別情報に基づいて、前記契約情報ＤＢから請求対象の契約を特定し、その契約の変更履歴情報を検索する検索手順と、
決裁基準特定手段が、前記受け付けた請求情報に基づいて判定された保全手続の種別に基づいて、前記決裁基準テーブルから当該保全手続の決裁基準を特定する決裁基準特定手順と、
決裁レベル判定手段が、特定された決裁基準に関連付けられた変更履歴と、契約情報ＤＢから検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、この保全手続の決裁権限や必要書類などの決裁レベルを判定して出力する決裁レベル判定手順と、
決裁済情報受付手段が、請求に係る保全手続が前記判定された決裁レベルに従って決了したことを示す決裁済情報の入力を受け付ける決裁済情報受付手順と、
決裁済情報が入力された場合に、契約情報更新手段が、前記請求情報に従って前記契約情報ＤＢに格納された契約情報及び変更履歴情報を夫々更新する契約情報更新手順と
を備えたことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、入力装置、出力装置、制御装置、及びコンピュータソフトウェアを格納する記憶装置を備えた保険会社のコンピュータシステムによって、生命保険契約を締結した顧客からの保険金の請求、契約内容の変更などの保全手続の処理を支援する方法、この方法を実行するシステム及びこの方法をコンピュータシステムに実行させるコンピュータプログラムに関する。
【背景技術】
【０００２】
生命保険契約は、契約関係が数年から数十年の長期に亘る場合が少なくないため、その間に契約者のライフスタイルや家庭環境などが変化し、契約内容の変更が必要となる場合が多い。そのような契約情報の変更は、契約者や相続人などが保険会社に種々の変更を請求する保全手続によって行われている。保険会社は、契約者等から請求があると、保険会社が用意した所定の請求書を顧客に提示し、契約情報や契約者の住所・氏名などの必要事項の記入、捺印、必要な添付書類と共に返送してもらう。また、保険会社は、受け取った請求書（添付書類を含む。以下、同様）を社内の決裁基準に照らして点検し、不備を発見した場合には顧客に不備を指摘して修正等を依頼している。
【０００３】
このような請求書の点検は、事務担当者が経験や点検項目のチェックリスト等を基にして点検項目を判断して行っている。一般的に、請求の種類は、支払い保険料の変更、保険金額の変更、受取人の変更、特約の追加・変更・解約などの契約内容の変更や、解約など１００種類以上あり、また契約内容も特約の有無等によって数百パターンにも及ぶため、請求ごとの点検項目を漏れなくあげた上で正確・迅速に点検することは困難である。また、このような請求の件数は、大手の生保会社であれば、年間に数百万件に上るため、点検のための人員を確保したり教育することが容易ではなくコスト増の原因になっている。
【０００４】
また、顧客に請求書の不備を通知する場合、業務の効率化のために定型の通知書で行うことが一般的であるが、上記したように、請求書は多種類の様々なバリエーションについて行われるため、この定型の通知書に不備の内容を具体的かつ分かり易く指摘することが容易ではない。そのため、顧客との間で齟齬が生じ、修正依頼が複数回になってしまうこともある。このような請求書の不備の指摘にも相応のスキルが必要であるため、点検の人的負荷が一層大きくなってしまう。
【０００５】
一方で、請求手続を決了する（点検・承認後にマスタファイルを更新する）際には、証券番号や請求内容などの全ての請求項目を事務担当者が社内のオンライン入力画面で入力している。そのため、入力作業が繁雑で人為的なミスも生じ易い。
【０００６】
さらに、請求手続が決了するまでは、事務処理を行っている担当部門・担当者などの限られた者しか進捗を把握できていない。そのため、顧客から記名・捺印などされた請求書を受領してから決了までに長期間かかってしまうと、顧客からコールセンター等に進捗の問い合わせが来た場合に、迅速に回答することができない。
【０００７】
以上のような課題を解決するため、例えば、以下の特許文献１〜４において、保険会社の業務を効率化する手法などが種々提案されている。
【０００８】
【特許文献１】特開２００２−１１７２２６号公報
【特許文献２】特開２００２−１８９８５３号公報
【特許文献３】特開２００２−２３０２６９号公報
【特許文献４】特開２００２−２８８３９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ところで、上記した従来の技術では、何れも、保全手続の請求があった場合に、請求書の様式や添付書類などの、その手続の適否を検査するだけで、他の関連手続との関連性までチェックしていない。そのため、例えば、保険契約に基づく貸付の申込みを受け付けて処理している最中に、同じ保険契約について保険金額の減額の申込みを受け付けた場合に、受け付けた順に処理して行くと、結果的に限度額を越えた貸し付けを認めてしまうことになる。
【００１０】
一方で、このような場合を想定して、膨大な数の保全手続の全てについて現在のチェック項目に加えて他の関連手続との関連性をチェックすることは、保全業務の迅速・効率的な処理を阻害することになり、顧客サービスやコストの面で問題がある。
【００１１】
本発明は、このような課題を解決するためになされたもので、保険契約の保全手続を効率的に処理するために有益な情報を提供して保全業務を支援すると共に、契約情報の変更による保全業務への影響を把握して保全業務を円滑に行うための方法、システム、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の第１の主要な観点によれば、入力手段、出力手段、制御手段、及びコンピュータソフトウェアを格納する記憶装置を備えた保険会社のコンピュータシステムによって、生命保険契約を締結した顧客からの保険金の請求、契約内容の変更などの保全手続の処理を支援する方法であって、前記記憶装置は、保険契約者や被保険者の個人情報、特約の種別、保険料（掛金）の支払い方法などの生命保険契約の情報と、これらの情報が変更された日付及び項目を含む変更履歴情報と、を夫々契約識別情報に関連付けて格納する契約情報データベース（ＤＢ）と、多数の保全手続の種別ごとに、少なくとも前記変更履歴との関係で設定された決裁基準を格納する決裁基準テーブルと、を備え、この方法は、請求受付手段が、契約識別情報及び請求内容を含む請求情報の入力を受け付ける請求受付工程と、検索手段が、入力された契約識別情報に基づいて、前記契約情報ＤＢから請求対象の契約を特定し、その契約の変更履歴情報を検索する検索工程と、決裁基準特定手段が、前記受け付けた請求情報に基づいて判定された保全手続の種別で前記決裁基準テーブルを検索し、当該保全手続の決裁基準を特定する決裁基準特定工程と、決裁レベル判定手段が、特定された決裁基準に関連付けられた変更履歴と、契約情報ＤＢから検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、この保全手続の決裁権限や必要書類などの決裁レベルを判定して出力する決裁レベル判定工程と、決裁済情報受付手段が、請求に係る保全手続が前記判定された決裁レベルに従って決了したことを示す決裁済情報の入力を受け付ける決裁済情報受付工程と、決裁済情報が入力された場合に、契約情報更新手段が、前記請求情報に従って前記契約情報ＤＢに格納された契約情報及び変更履歴情報を夫々更新する契約情報更新工程とを備えたことを特徴とする方法が提供される。
【００１３】
ここで、生命保険会社における「保全手続」とは、一般的に、保険契約者や被保険者の氏名変更・主契約の内容変更や解約・特約の追加や解約・契約者貸付・入院給付・保険金給付等の行うための手続の総称であり、この保全手続を保険会社で処理することが保全業務と称される。
【００１４】
この保全手続は、保険契約者への影響が極めて低い特定の項目を変更するための「簡易変更手続」とは区別される。この「簡易変更手続」は、電話やＦＡＸ、営業所の店頭などにおいて、保険証券番号や氏名などで対象となる契約と本人であることを確認した上で、特定項目の変更を受け付け、契約情報ＤＢを更新する。すなわち、請求書の提出や本店等での決裁は不要である。
【００１５】
また、本明細書における「決裁基準」とは、保全手続の種別によって予め画一的に設定された基準であり、決裁権限（決裁者レベル）、必要な証明書（添付書類）などの情報が含まれる。これに対して、「決裁レベル」とは、上記した限度額を越えた貸付けや保険契約以外の者への書類発送などの、顧客や保険会社の利害に関係する手続的なミスが発生する可能性（リスクレベル）に応じて決裁基準を具体的に修正したものであり、保全手続の種別、変更履歴情報、請求情報、同時継続の他の手続等との関係で個別具体的に判定される。
【００１６】
さらに、「顧客」は、一般に保険会社と保険契約を締結した「保険契約者」を指すが、保険契約者と被保険者とが異なる契約も少なくなく、何れの者からも保全手続を申し込まれる可能性がある。そのため、本明細書では、特に明記しない限り、保全手続を請求できる者を全て「顧客」と称する。
【００１７】
また、本発明の第２の主要な観点によれば、入力手段、出力手段、制御手段、及びコンピュータソフトウェアを格納する記憶装置を備え、生命保険契約を締結した顧客からの保険金の請求、契約内容の変更などの保全手続の処理を支援するシステムであって、保険契約者や被保険者の個人情報、特約の種別、保険料（掛金）の支払い方法などの生命保険契約の情報と、これらの情報が変更された日付及び項目を含む変更履歴情報と、を夫々契約識別情報に関連付けて格納する契約情報データベース（ＤＢ）と、多数の保全手続の種別ごとに、少なくとも前記変更履歴との関係で設定された決裁基準を格納する決裁基準テーブルと、契約識別情報及び請求内容を含む請求情報の入力を受け付ける請求受付手段と、入力された契約識別情報に基づいて、前記契約情報ＤＢから請求対象の契約を特定し、その契約の変更履歴情報を検索する検索手段と、前記受け付けた請求情報に基づいて判定された保全手続の種別に基づいて、前記決裁基準テーブルから当該保全手続の決裁基準を特定する決裁基準特定手段と、特定された決裁基準に関連付けられた変更履歴と、契約情報ＤＢから検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、この保全手続の決裁権限や必要書類などの決裁レベルを判定して出力する決裁レベル判定手段と、請求に係る保全手続が前記判定された決裁レベルに従って決了したことを示す決裁済情報の入力を受け付ける決裁済情報受付手段と、決裁済情報が入力された場合に、前記請求情報に従って前記契約情報ＤＢに格納された契約情報及び変更履歴情報を夫々更新する契約情報更新手段とを備えたことを特徴とするシステムが提供される。
【００１８】
また、本発明の第３の主要な観点によれば、入力手段、出力手段、制御手段、及びコンピュータソフトウェアを格納する記憶装置を備えた保険会社のコンピュータシステムに、生命保険契約を締結した顧客からの保険金の請求、契約内容の変更などの保全手続の処理を支援する処理を実行させるためのコンピュータプログラムであって、前記記憶装置は、保険契約者や被保険者の個人情報、特約の種別、保険料（掛金）の支払い方法などの生命保険契約の情報と、これらの情報が変更された日付及び項目を含む変更履歴情報と、を夫々契約識別情報に関連付けて格納する契約情報データベース（ＤＢ）と、多数の保全手続の種別ごとに、少なくとも前記変更履歴との関係で設定された決裁基準を格納する決裁基準テーブルと、を備え、このプログラムは、請求受付手段が、契約識別情報及び請求内容を含む請求情報の入力を受け付ける請求受付手順と、検索手段が、入力された契約識別情報に基づいて、前記契約情報ＤＢから請求対象の契約を特定し、その契約の変更履歴情報を検索する検索手順と、決裁基準特定手段が、前記受け付けた請求情報に基づいて判定された保全手続の種別に基づいて、前記決裁基準テーブルから当該保全手続の決裁基準を特定する決裁基準特定手順と、決裁レベル判定手段が、特定された決裁基準に関連付けられた変更履歴と、契約情報ＤＢから検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、この保全手続の決裁権限や必要書類などの決裁レベルを判定して出力する決裁レベル判定手順と、決裁済情報受付手段が、請求に係る保全手続が前記判定された決裁レベルに従って決了したことを示す決裁済情報の入力を受け付ける決裁済情報受付手順と、決裁済情報が入力された場合に、契約情報更新手段が、前記請求情報に従って前記契約情報ＤＢに格納された契約情報及び変更履歴情報を夫々更新する契約情報更新手順とを備えたことを特徴とするコンピュータプログラムが提供される。
【発明の効果】
【００１９】
本発明によれば、契約情報の変更履歴との関連性に基づいて決裁権限（支店決裁か本店決裁か等）や必要な添付書類（所定期間内に発行された戸籍謄本や印鑑証明など）などの決裁レベルを判定するようにした。このような決裁レベルの判定結果は、決裁業務やその前後の種々の事務手続を円滑に行うために非常に有益な情報となる。特に、保全手続の事務処理に不慣れな者であっても、受け付けた保全手続の種別などに応じた適切な社内処理を迅速に行うことができるようになる。
【００２０】
また、上記した決裁レベルの判定に際して、保全手続に係る契約情報の変更履歴を参照するようにしたので、契約情報の変更に伴う手続的なミスを容易に発見して適切な処理を行わせることができる。
【００２１】
さらに、必要に応じて契約情報の変更履歴を参照することで、以下のような不適切な行為を防止できるという副次的な効果もある。例えば、保険契約者本人が知らない間に、請求権のない第三者が保険契約者の住所や受取人を変更する手続を申し込み、その直後に契約者になりすまして保険金の請求や保険額の引き下げなどの保全手続を申し込んだとする。このような場合に、保険会社の方で後から請求された保全手続に係る契約情報の変更履歴との関連性をチェックしないと、保険料の支払いや減額による精算保険料の支払い等の通知が、変更後の住所に送付されたり、変更後の受取人に送付されることになる。このような行為は、契約情報の変更履歴を参照することで有効に防止できるようになる。また、保全手続の種別に基づいて決裁基準（変更履歴を参照するかどうか等）を特定することにしたので、保全業務の円滑な処理を阻害することもない。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施の形態を図面に基づき説明する。  
図１は本発明の一実施形態のネットワーク構成図である。この図で符号１で示す保全業務処理システム（保全手続処理支援システム）は、生命保険会社２の複数の営業所や支部などの営業拠点（以下、「支部」と総称する）３を統括する支社・支店・サービスセンタ（ＳＣ）若しくは本店（以下、「本店」と総称する）４に備えられた１又は２以上のコンピュータシステムが連携して構成される。このシステム１は、顧客（潜在契約者）５との間で新たに保険契約を締結する新規契約締結機能、契約を締結した顧客５から契約情報の変更などを受け付けて処理する保全業務機能、及び契約者５の個人情報や契約情報をデータベースに登録・更新したり照会を受け付けて処理する情報管理機能を備えている。すなわち、この保全業務処理システム１は、顧客情報管理サーバ、契約情報管理サーバ、職員情報管理サーバ、ＷＥＢサーバ、決裁処理システムなどの従来周知の種々の機能に加えて、本発明特有の保全業務支援機能を備えている。以下においては、説明の便宜上、保全業務処理システム１が本店４のメインフレームで構成されていることにする。
【００２３】
保全業務処理システム１は、ＬＡＮ、ＷＡＮなどの社内通信回線網や、インターネットなどの公衆回線網を介して全国の多数の支部３に設置された支部端末６と接続される。上記した顧客５からの種々のリクエストは、支部３に来店した顧客５から支部３の担当者（事務担当者や営業担当者、コールセンター受電担当者等。以下「支部担当者」と総称する）が口頭や電話で受け付けた情報をこの端末６に入力したり、営業担当者が顧客５の自宅や勤務先で受け付けた情報をモバイル端末から通信回線を介してこの端末６に送信することで、受け付けた情報が保全業務処理システム１に送信される。なお、顧客５が自身のＰＣなどの通信端末９でＷＥＢ上のユーザページにログインして直接入力してＷＥＢサーバを介して保全業務処理システム１に送信することもできる。
【００２４】
ここで、契約内容の変更手続には、電話やＦＡＸ、支部３の窓口において口頭で受け付けて担当者がそのまま処理可能な簡易変更手続と、必要な書類を添付した所定フォーマットの請求書を提出させ、所定の決裁基準に従って決裁される保全手続とがある。本実施形態では、何れの変更手続においても、支部担当者が変更に係る保険契約の識別情報（保険証券番号など）と変更内容を支部端末６から入力して社内の通信ネットワークを介して保全業務処理システム１に送信して契約ごとの変更履歴情報として記録・管理する。保全手続については、所定の決裁処理を経た上で契約情報が更新されることになる。そして、その後に請求された当該契約に関する保全手続について、その変更履歴情報を参照して決裁処理（保全業務）を行うようにしている。
【００２５】
次に、図１を参照して、本実施形態における保全業務処理の概略工程を説明する。なお、以下の例は、顧客５が支部３の窓口（電話）で保全手続を申し込む場合である。
【００２６】
まず、顧客５が保険会社２の支部３の窓口で、保険契約の識別情報（保険証券番号など）と、変更したい項目や内容等を提示して契約情報の変更を申し込む（Ｓ１）。支部担当者は、顧客５から提示された申込み情報を支部端末６に入力して本店４の保全業務処理システム１に送信する（Ｓ２）。保全業務処理システム１は、受け付けた申込み情報に基いて対象となる契約を特定する。ここで、本店のオペレータや管理者などが請求情報によって保全手続の種別を判定して入力すると、保全業務処理システム１がその手続の決裁基準を判定し、顧客５の個人情報、契約書情報、及び保全手続の識別情報（バーコード）を合成して請求書データを生成する（Ｓ３）。また、この段階で、保全手続の処理の進捗管理を開始する。なお、支部端末６や保全業務処理システム１に、請求情報と保全手続の種別とを関連付けて登録した保全手続種別テーブルを設けて、受け付けた請求情報に基いて保全手続の種別を自動判定するようにしてもよい。
【００２７】
次いで、保全業務処理システム１は、生成された請求書データをプリンタに出力して保全手続の請求書を印刷し（Ｓ４）、顧客５に郵送などによって送付する（Ｓ５）。この時、上記した決裁基準に従って、請求書の記載要領や必要な添付書類などを明記した送付状も印刷して同封するのが好ましい。
【００２８】
顧客５から、必要事項が記入された請求書と必要な添付書類とが支部３に返送されると（Ｓ６）、支部担当者が支部端末６に接続されたバーコードリーダ８で請求書に印刷されたバーコードを読み取らせ（Ｓ７）、保全手続の識別情報を保全業務処理システム１に送信する（Ｓ８）。保全業務処理システム１は、受信した保全手続識別情報から対象となる契約及び保全手続の情報をデータベースから検索すると共に、この保全手続のチェックリストと決裁者などの情報をデータベースから収集して決裁処理を実行する（Ｓ９）。決裁処理が決了すると、請求内容に従って契約情報を更新する（Ｓ１０）。また、保全手続の決裁が決了したことを顧客に知らせる手続完了通知書データを生成して（Ｓ１１）、プリンタから出力させる（Ｓ１２）。そして、プリントアウトした手続完了通知書を顧客５に郵送などによって送付する（Ｓ１３）。なお、上記した保全手続請求書データや手続完了通知書データをデータセンタなどに送信して印刷と顧客への発送を行わせてもよい。
【００２９】
次に、図２の機能ブロック図を参照して、上記した各機能を奏する本実施形態の保全業務処理システム１の構成を説明する。  
このシステム１は、図２（Ａ）に示すように、本店４などに設置されたメインフレーム（コンピュータシステム）のＣＰＵ１１にシステムバス１２を介してＲＡＭ１３、磁気ディスクなどの外部記憶装置１４及び入出力インタフェース（Ｉ／Ｆ）１５が接続されている。入出力Ｉ／Ｆ１５には、キーボードやマウスなどの入力装置１７、液晶ディスプレイなどの出力装置１８、及びモデムなどの通信デバイス１９が夫々接続されている。前記記憶装置１４は、データ記憶領域１４ａとプログラム格納領域１４ｂとを備えており、本発明の機能を実現するソフトウェアプログラムはプログラム格納領域１４ｂにインストールされている。
【００３０】
このようなハードウェア構成において、支部担当者が支部端末６から各種のデータを入力して保全業務処理システム１に送信したり、本店４のオペレータや決裁者などが入力装置１７から各種のデータを入力することで、ＣＰＵ１１がソフトウェアプログラムを読み出してＲＡＭ１３上にロードして所定の手順を実行することで、ＯＳ（オペレーションシステム）と協働してこの発明の機能を奏するようになっている。
【００３１】
前記記憶装置１４のデータ記憶領域１４ａは、図２（Ｂ）に示すように、契約情報データベース（ＤＢ）２２、決裁基準テーブル２３、チェックポイントテーブル２４、進捗管理データベース（ＤＢ）２５、請求書情報データベース（ＤＢ）２６、及び案内文テーブル２７を備えている。これらのデータベースやテーブルで管理されるデータの一部又は全部は、各種のデータを集中的に管理するデータセンタのマスタファイルで管理されており、所定周期で各データベース等と同期させたり、ミラーリングなどによって複数の支社などで分散処理できるように構成されている。
【００３２】
契約情報ＤＢ２２は、保険契約者・被保険者の氏名、家族構成、顧客登録をした年月日などの顧客の個人情報、担当支部や担当者などの情報、保険料の支払い状況、保険金の支給履歴などの保険契約の基礎となる情報と、これらの情報が変更された日付及び項目を含む変更履歴情報と、を夫々契約識別情報（保険証券番号など）に関連付けて格納するものである。この契約情報ＤＢ２２は、１人の顧客５が複数の保険契約を締結している場合は、全ての契約の変更履歴をこの顧客の識別情報（顧客管理番号や最初の契約の保険証券番号など）に関連付けて格納する。
【００３３】
保険契約は、長期間に亙って継続し、その間に顧客のライフスタイルも変化するため契約の見直しや個人情報の変更が必要になる場合が多い。そのため、住所・氏名・勤務先などの書誌事項に加えて、契約内容自体の変更も変更履歴情報として登録することにした。
【００３４】
決裁基準テーブル２３は、多数の保全手続の種別ごとに、上記した契約情報の変更履歴や、顧客の属性、保全手続の種別などとの関係で設定された決裁基準を格納するものである。具体的には、図３に示すように、保全手続の種別ごとに決裁権限や添付書類の種類、請求書の保管期限などが格納される。この保全手続の種別は、防止すべき行為のリスク等に連動させるため、例えば、顧客５への金銭の支払いが発生するか及びその支払い金額との関係で分類される。そして、この保全手続の種別ごとに、請求対象の契約の変更履歴情報、若しくはその顧客５の他の契約の変更履歴情報を参照するかの基準が設定される。個々の保全手続や簡易変更手続だけ見れば何ら問題なくても、その前後の保全手続の種別や請求内容（条件）と合わせて考えるとリスクが大きくなる可能性があるため、誤払い、二重払い、過払いなどの不適切な処理や請求権のない第三者の行為などを未然に防止するために、対象となる契約の変更履歴情報を参照するのが好適である。
【００３５】
例えば、保険金請求や契約者貸付の請求の直前（数ヶ月以内）に振込口座情報の変更が行われている場合は、変更後の口座名義人が契約者本人であればリスクはないが、契約者以外の名義の口座への振込指示はリスクが大きい。また、保全手続の完了後に、正当性の確認の意味も含めて請求者の登録住所宛に完了報告書を送付するが、保険金請求や契約者貸付の請求の直前（数ヶ月以内）に住所変更が行われていると、顧客本人の知らない間に第三者によって保険金請求などが行われるおそれがある。このような保全手続の種別や請求内容、変更履歴情報との多数の組み合わせに応じたリスク度合いを事務担当者や決裁者などが迅速・正確に判別するのは現実的には不可能であるが、決裁基準テーブル２３や契約情報ＤＢ２２を参照することでこれが可能になる。なお、支部窓口や顧客の自宅などで面前で申し込まれた場合より、郵送申込みの方がリスクが大きいため、申込みのチャンネルで区別することも好ましい。
【００３６】
ここで、保全手続の請求書が顧客５から返送されてから決了するまでに、一般的に数日から２週間ほどかかるため、１の契約に関して複数の未決の保全手続が同時期に係属することが考えられる。そして、それらの保全手続の種別によっては、受け付けた順序で処理すると矛盾が生じたり、上記した変更履歴情報を参照することが有名無実化するおそれがある。例えば、先に「受取人の変更」や「振込口座の変更」が請求され、その直後に「保険金の支払」が請求された場合は、請求権のない第三者からの請求であるおそれがある。また、先に「本契約の解約」が請求され、その直後に「特約の付加」が請求された場合は、先の保全手続は顧客５の錯誤である可能性が高い。
【００３７】
そのため、本実施形態の決裁基準テーブル２３は、１の契約について複数の保全手続が同時期に継続した場合の決裁順序、決裁レベル、若しくは必要な添付書類などを含む第２の決裁基準を当該複数の保全手続の種別に関連付けて格納している。特に、現金の支払いを伴う保全手続については、この契約情報ＤＢ２２に格納されている過去の変更履歴情報とともに、同時進行の他の保全手続についても、請求権のない第三者からの請求を防止する観点ではより重要であるため、複数種類の本人確認書類（免許証と保険証など）を提出させるなど、決裁基準を厳格に定めるのが好ましい。また、前記簡易変更手続も特定の保全手続との関係で不適切な行為のリスクが高まることから、保全手続と簡易変更手続とが同時期に継続した場合にも、上記と同様に第２の決裁基準の対象とするのが好ましい。具体的には、この第２の決裁基準には、保険金請求などの処理中に住所変更の請求が行われた場合や、その逆に住所変更の直後に保険金請求が行われた場合等には、先に行われた請求、若しくは双方の請求の処理を中断することが含まれる。この場合には、進捗管理ＤＢ２５や契約情報ＤＢ２２に両方の請求（保全手続や簡易変更手続）に「要注意の手続」であることを示すフラグを立てて、決裁者などの注意を促す。
【００３８】
チェックポイントテーブル２４は、支部の担当者や本店４の審査部門の社員が、顧客５から返送された請求書の記載内容や添付書類の適否を判断するためのチェックポイントを保全手続の種別に関連付けて格納するものである。チェックポイントとしては、例えば、「受取人の変更」であれば、「顧客本人からの請求か」「この顧客の他の契約はあるか」「変更履歴は確認したか」「添付書類は発行から６か月以内か」などのチェックポイントが格納される。後述するように、全てのチェックポイントにチェック済み情報が入力されないと決裁処理（決裁者への回付、決裁済み情報の入力等）に移行されない。
【００３９】
進捗管理ＤＢ２５は、保全手続の処理状況を前記契約識別情報（保険証券番号）に関連付けて格納するものである。また、上記したように、１の契約識別情報について複数の保全手続若しくは保全手続と簡易変更手続が同時に継続した場合には、それらの処理状況を相互に関連付けて格納する。
【００４０】
請求書情報ＤＢ２６は、各保全手続に必要な添付書類の種類及び各保全手続の請求書フォーマットを、保全手続の種別に関連付けて格納するものである。請求書フォームは、図４に示すように、顧客５が署名・捺印する欄と、保険契約の情報の表示欄と、保全手続の請求情報の表示欄と、保全手続の識別情報を示すバーコードとを有する。
【００４１】
ここで、必要な添付書類は、上記した決裁基準テーブル２３に登録されているが、保全手続の請求情報によって異なってくる。例えば、保険金の支払請求、特約の解約などのように、保険会社が顧客に現金を支払う必要がある保全手続については、過払いなどの可能性があるため、同一種別の保全手続であってもその請求金額によって添付書類の種類を異ならせる。例えば、請求金額によって、１）本人確認書類（免許証のコピー等）だけ、２）本人確認書類及び医療機関の証明書類（診断書等）、３）本人確認書類・医療機関の証明書類及び公的機関が発行した書類（印鑑証明書等）、などのように複数段階で設定する。また、死亡保険金の請求であれば、金額に拘らず、保険契約者と被保険者（遺族等）との関係を示す戸籍謄本等の公的書類を添付させる。一方、勤務先や自宅の電話番号の変更などの手続は、過払いや二重払いなどとの関連性が低いので、添付書類を簡易にしたり不要とする。
【００４２】
案内文テーブル２７は、請求書の記載項目の不備の説明文、添付書類の不備の説明文、及びそれらの不備を解消する補正内容の説明文を不備の種類に関連付けて格納するものである。顧客５から返送された保全手続の請求書について、支部３や本店４などの事務担当者が上記チェックポイントをチェックした結果、記載事項や添付書類に不備を発見した場合に、後述する案内文生成手段４０が、この案内文テーブル２７から適切な説明文サンプルを選択して合成することで、顧客５に送付する不備の説明書を自動生成できる。
【００４３】
また、この案内文テーブル２７には、図５に示すように、請求書の案内書のフォームや説明文等のひな形も格納している。この案内書には、請求書に添付すべき書類（健康保険証、運転免許証等）、及びその条件（有効期限、記載事項等）の説明文が表記される。顧客５は、この案内書を参照して必要な書類を用意し、上記請求書に署名・捺印して保険会社２の支部などに返送する。
【００４４】
前記プログラム格納領域１４ｂにインストールされるソフトウェアプログラムは、図２（Ｂ）に示すように、請求受付手段３０、契約情報検索手段（請求内容判別手段、アラーム出力手段）３１、決裁基準特定手段３２、決裁レベル判定手段３３、請求書データ生成手段（請求書情報検索手段、請求書出力手段）３４、決裁済情報受付手段３５、進捗管理手段３６、契約情報更新手段３７、及び保全業務支援手段（チェックポイント出力手段、チェックポイント入力受付手段、チェックポイント監視手段、案内文作成手段）３８を備えている。これらの各手段は、実際には、夫々独立したプログラムや、ルーチン、サブルーチン、モジュールなどであり、ＣＰＵ１１がＲＡＭ１３上でプログラムの手順を実行させることで、コンピュータシステムが各手段として機能するものである。
【００４５】
請求受付手段３０は、前記支部端末６から送信された、若しくは本店４などのオペレータが前記入力装置１７を介して入力した契約識別情報及び請求内容を含む請求情報の入力を受け付けて記憶装置１４に格納するものである。顧客５がＷＥＢ上のユーザ専用ページから保全手続を申し込んだ場合は、この請求受付手段３０は、ＷＥＢサーバを介して請求情報を取得する。この受け付けた請求情報に基づいて支部担当者や管理者などが保全手続か簡易変更請求手続かを判別し、保全手続である場合にはその種別を判別して入力する。請求受付手段３０が、判定テーブルなどに基づいて保全手続の種別などを判別するようにしてもよい。この場合、簡易変更請求手続によって変更できる項目は限られているため、保全手続か簡易変更請求手続かの判定を支部端末６に行わせてもよい。
【００４６】
契約情報検索手段３１は、入力された契約識別情報に基づいて、前記契約情報ＤＢ２２から請求対象の契約の情報及び当該契約の変更履歴情報を検索してメモリに一時的に記憶させるものである。ここで、顧客５が複数の保険契約を締結している場合もあるが、契約者・保険契約者・被保険者の氏名（新姓と旧姓、漢字表記の相違など）や電話番号、勤務先、保険金の受取口座情報などの特定の項目は、同一人であれば複数の契約において共通しているため、一部の契約についてだけ変更が申し込まれた場合は、他の契約の存在を失念しているか、請求権のない第三者による手続である可能性が高い。そのため、このような場合は、その保全手続の通常の決裁ルールとは別に、本人認証レベルをより厳格にしたり、他の契約について変更請求が出されていないことを知らせるアラームを出力することが好ましい。
【００４７】
そこで、本実施形態の契約情報検索手段３１は、受け付けた保全手続の請求内容が、当該顧客５の複数の契約に共通する項目のうち、特定の項目に関する変更であるかを判定する機能と、特定項目の変更である場合に前記契約情報ＤＢ２２から請求対象の契約に加えて、その顧客５の他の全ての契約を特定し、それらの契約の情報及び変更履歴情報を検索する機能と、検索された全ての契約に関する変更履歴情報を参照して、この特定項目の変更が他の契約について行われていない合に所定のアラームを出力する機能とを備えている。具体的には、所定のメッセージを支部端末７に送信して表示させたり、顧客５に送付する案内文書のデータを生成してプリンタに出力する。上記したように、このような複数契約が存在する場合の決裁基準も、決裁基準テーブル２３に登録されている。
【００４８】
決裁基準特定手段３２は、請求受付手段３０が判別した保全手続の種別に基づいて、前記決裁基準テーブル２３から当該保全手続の決裁基準を特定して決裁レベル判定手段３３に受け渡すものである。特定された決裁基準は、具体的には、数桁〜１０桁程度の数字や記号で構成され、変更履歴情報の参照要否、変更履歴情報で注視すべき特定の項目のコード、複数段階の決裁レベル（支店／本社、決裁者の職制コードなど）、及び上記した必要な添付書類（本人確認書類のみか、医療機関や公的機関の証明書も必要か、など）の識別情報が含まれる。なお、特定された決裁基準をプログラムロジックとして実装してもよい。
【００４９】
決裁レベル判定手段３３は、特定された決裁基準に関連付けられた変更履歴と、契約情報ＤＢ２２から検索された当該契約の変更履歴情報と、前記請求情報に含まれる請求内容とを参照して、この保全手続の決裁権限や必要書類などの決裁レベルを判定して出力するものである。具体的には、契約情報ＤＢ２２から検索された契約情報の更新日及び更新項目と、判定された保全手続の種別及び請求内容と、決裁基準テーブル２３に登録された当該保全手続の種別及び変更履歴の関連性と、に従って、決裁レベルを判定する。
【００５０】
決裁レベルは、保険契約の種類や保全手続の種別などに応じて画一的に決定される決裁基準とは異なり、対象となる契約に関する過去の変更履歴情報を始めとして、当該保全手続の請求内容、他の手続との関係、さらには、その顧客５の他の契約との関係を考慮する必要がある。
【００５１】
例えば、変更履歴情報との関係では、保全手続が「保険金請求」で１週間前に受取人が変更されている場合と３年前に変更されている場合とでは誤払いや二重払いなどの可能性が異なるため、それに応じて決裁レベルも異ならせるのが好ましい。また、保全手続が「改姓・改名手続」であれば受取人の変更時期は二重払いなどへの影響はないため、決裁レベルの判定に際してこの変更履歴情報を考慮する必要はない。
【００５２】
保全手続の請求内容との関係では、同じ保険金の請求であっても、１万円の通院給付金の請求と、１０００万円の死亡保険金の請求とでは二重払いなどによる影響が格段に異なる。また、特約の追加や変更であっても、被保険者の病歴や職業などとの関係で付加できないものも存在する。
【００５３】
また、他の手続との関係では、１の契約について複数の保全手続が同時に継続した場合や、過去の変更履歴情報のうち、住所変更や保険金の振込口座の変更などの特定の項目との関係で影響の大きさが異なってくる。この場合の他の手続には、保全手続と簡易変更手続の両方が含まれる。すなわち、この決裁レベル判定手段３３は、決裁前の第１の保全手続と同一の契約に対する第２の保全手続若しくは簡易変更手続を受け付けた場合に、第１又は第２の保全手続の種別、若しくは簡易変更手続の種別に基づいて決裁基準テーブルから第２の決裁基準を検索して決裁レベルを判断する。
【００５４】
他の契約との関係では、前記契約情報検索手段３１で説明したように、契約情報ＤＢ２２から検索された当該顧客５の全ての契約の変更履歴情報を参照し、複数の契約の間で共通する項目に関する変更が行われたか等に基づいて決裁レベルを判定する。なお、商品種別や手続種別、顧客属性等との関係で、契約情報の検索条件を設定するようにしてもよい。
【００５５】
請求書データ生成手段３４は、前記判定された保全手続の種別と、前記決裁レベル判定手段３３が判定した決裁レベルとに基いて、前記請求書情報ＤＢ２６から当該保全手続の請求書フォーマット及び必要な添付書類の情報を検索する機能と、保全手続に係る契約の保険証券番号に関連付けて保全手続の識別情報をバーコード形式で生成する機能と、検索された請求書フォーマットに、添付書類の情報と抽出された契約情報と生成されたバーコードとを合成して生成した請求書データをプリンタに出力して保全手続の請求書（図４参照）を印刷し、郵送などの方法で顧客５に送信する機能とを有する。
【００５６】
進捗管理手段３６は、請求手続の処理状況を前記進捗管理ＤＢ２５に登録して管理する機能を有する。具体的には、前記請求受付手段３０が顧客５からの請求情報を支部端末６を介して受け付けた場合、前記請求書データ生成手段３４が請求書データを生成して請求書を顧客５に送信した場合、保全業務支援手段３８が請求書の不備を説明する案内文データを生成して案内文を顧客５に送信した場合、及び前記決裁済情報受付手段３５が決裁済情報を受け付けた場合に、各手段から契約識別情報を含む進捗データを夫々受け取り、前記進捗管理ＤＢ２５から該当する保全手続を検索して進捗情報を更新する。また、顧客５から請求書が返送された場合の保全手続の識別情報（バーコード）や、請求書が決裁者に回付された場合のステータス情報は、この進捗管理手段３６が入力を受け付けて進捗管理ＤＢ２５を更新する。
【００５７】
契約情報更新手段３７は、前記決裁済情報受付手段３５から決裁された保全手続の識別情報を取得して前記契約情報ＤＢ２２からこの保全手続を特定し、前記請求受付手段３０が取得した請求情報に従って契約情報ＤＢ２２に格納された契約情報及び変更履歴情報を夫々更新するものである。また、この契約情報更新手段３７は、上記した簡易変更請求手続に基づく契約情報の変更請求を受け付けて、前記契約情報ＤＢ２２に登録された契約情報を更新して更新年月日を登録する機能も有する。
【００５８】
保全業務支援手段３８は、顧客５から返送された請求書を事務担当者がチェックする業務を支援する機能と、請求書に不備が発見された場合に案内文データを生成して顧客５に送付する機能とを有する。
【００５９】
まず、請求書のチェック業務支援機能は、顧客５から返送された請求書のバーコードが支部端末６に接続されたバーコードリーダ８で読み取られて保全手続の識別情報が送信された場合に、その保全手続の種別を契約情報ＤＢ２２から特定し、前記チェックポイントテーブル２４から当該保全手続のチェックポイントを全て抽出してチェックリスト（図８参照）を生成して支部端末６に返信するものである。返信されたチェックリストは、支部端末６のディスプレイに表示され、支部担当者がチェックリストを見ながら請求書の不備をチェックする。これにより、ヒューマンエラーを回避し、不慣れな担当者にもベテラン社員と同等の正確性、早さで請求書のチェックを行わせることができる。なお、チェックリストを印刷して郵送などの方法で支部に送信してもよい。
【００６０】
なお、本店４やサービスセンタの事務担当者が請求書をチェックする場合には、生成したチェックリストをそのまま保全業務処理システム１のディスプレイ（１８）に表示する。以下においては、支部端末６にチェックリストを表示させて支部担当者が請求書をチェックする例を説明する。
【００６１】
支部担当者が黙視で請求書の記載事項や添付書類の種類、有効期限などをチェックした結果は、例えば、各チェックポイントに併記されたラジオボタンにチェックしたり、デフォルトでアクティブになっている「未確認」ボタンから「確認済」に変更したり、デフォルトで「false」や「未確認」が表示された入力ボックスを、プルダウンなどで「true」や「確認済」に変更する。入力されたチェック済み情報は保全業務処理システム１に送信される。
【００６２】
保全業務支援手段３８は、全てのチェックポイントについてチェック済情報を取得したかを監視し、全てのチェック済情報を取得した場合に、前記決裁レベル判定手段３３が判定した決裁レベルの決裁機関（支部を統括する支店、本店などの上位機関）に対して決裁指示情報を出力すると共に、当該請求書と添付書類とを回付するための送付状（図９参照）を作成する。すなわち、全てのチェックポイントがチェック済みにならない限り、決裁処理には移行できない。この決裁指示情報は、保全業務支援手段３８によって上記決裁機関（決裁者）の端末に電子メール等で送信されると共に、進捗管理手段３６に対して保全手続の識別情報と共に送信される。これにより、進捗管理ＤＢ２５の処理ステータスが更新される。決裁機関では、端末に「未処理の請求書」があることを示すメッセージが表示されると共に、「未処理ボックス」にこの保全手続の契約種別や請求情報などが表示される。なお、この場合でも、決裁機関（決裁者）は、現物の決裁書類（請求書や添付書類等）が回付されてきてからその決裁書類に基づいて決裁を実行するため、電子メール等の通知や「未処理ボックス」への表示などの一部又は全部を省略してもよい。
【００６３】
次に、案内文データ作成機能は、支部担当者等が請求書の不備を発見し不備入力画面（図１０参照）で不備項目に入力した場合に、その入力情報を受信し、不備の項目と、補正内容と、それらの説明文とを請求書情報ＤＢ２６から検索すると共に、契約情報ＤＢ２２から顧客の氏名や保険商品名、保全手続の受付日、請求内容などを検索し、これらの情報を案内文フォームに合成して図１１に示す案内文書データを作成してプリンタに出力する機能である。プリンタで印刷された案内文は、顧客５の登録住所に本店４から送付される。上記したように、請求書のチェックポイントは保全手続の種別や請求内容等に応じて多岐に亘るため、このような不備の説明文書を１件ずつ作成するのは非常に手間がかかる上、不備の項目や修正事項を正確かつ顧客５に不快感を与えないように伝えるのは相応の経験を積む必要がある。そのため、予め、保全手続の種別ごとに請求書の不備のパターンとその修正内容とその説明文とを用意しておき、不備の項目を指定するだけで顧客５への案内文書を自動作成できるようにした。この案内文書が顧客５から返送された場合は、支部担当者等によって上記したチェックリストに従って再度請求書がチェックされる。
【００６４】
以下、このシステム１の詳細な機能を実際の動作と共に、図６のフローチャートを参照して説明する。  
まず、顧客５が営業所や支部の窓口などで契約情報の変更を申し出て、支部担当者が保険証券番号と顧客５の書誌事項などを支部端末６に入力すると、前記請求受付手段３０が入力された情報を受け付ける（Ｓ２０）。また、この情報に基いて支部担当者等が保全手続の種別を判別して入力する（Ｓ２１）。この時点で、進捗管理手段３６が保全手続の識別情報を生成して進捗管理ＤＢ２５に登録し、進捗管理を開始する（Ｓ２２）。
【００６５】
ついで、決裁基準特定手段３２が起動し、前記判別された保全手続の種別に関する決裁基準を前記決裁基準テーブル２３から検索する（Ｓ２３）。同時に、契約情報検索手段３１が契約情報ＤＢ２２から対象となる契約の変更履歴情報を検索する（Ｓ２４）。このように収集された情報に従って、前記決裁レベル判定手段３３が、上記した手法に従って当該保全手続と変更履歴情報と関連性を判定する（Ｓ２５）。
【００６６】
ここで、対象となる契約の契約者について、他の契約が存在する場合は（Ｓ２６のＹｅｓ）、前記Ｓ２４に戻って当該他の契約に関する変更履歴情報を検索する。全ての契約についてこれらの処理を繰り返した後、前記決裁レベル判定手段３３は、同一の契約者について未決の保全手続や簡易変更手続がないかを監視する（Ｓ２７）。同時進行の他の手続が存在する場合は（Ｓ２７のＹｅｓ）、変更履歴を参照するのと同様の趣旨で、決裁基準との関連性を再度判定する。なお、個々の契約情報とは別に、顧客の書誌事項などの基本情報を顧客データベース（ＤＢ）などで一元管理している場合は、住所や氏名などの特定項目の変更手続を受け付けた場合に、契約情報ＤＢ２２の変更履歴情報を参照せずに顧客識別情報などに従って顧客ＤＢを更新するようにしてもよい。この場合には、複数の契約のうちの一部について住所変更等を受け付けても決裁できないようにワーニングを出力するなどの処理を行なうのが好ましい。
【００６７】
この時点で、決裁レベル判定手段３３が、収集したデータや判定結果に基づいてその保全手続の決裁レベルを決定する（Ｓ２８）。それに続いて、前記請求書データ生成手段３４が請求書情報ＤＢ２６から請求書フォーマットを検索し、その請求書フォーマットに契約書情報や契約者の個人情報などを嵌め込んで請求書データを生成しプリンタに出力して請求書を印刷する（Ｓ２９）。この時点で、請求書データ生成手段３４が進捗管理手段３６に保全手続の識別情報を送信して保全手続の進捗情報を更新させる（Ｓ３０）。この請求書は顧客５の登録住所宛に郵送される。
【００６８】
顧客５が、受領した請求書に署名・捺印し、指示された添付書類と共に返送してくると（Ｓ３１）、支部担当者がバーコードリーダ８で保全手続の識別情報を読み取り、保全業務処理システム１に送信する。この時点でも、保全手続の進捗情報が更新される（Ｓ３２）。また、保全業務支援手段３８は、保全手続に関するチェックリストを作成して、支部端末６に送信する（Ｓ３３）。上記したように、このチェックリストは支部端末６のディスプレイに表示される。
【００６９】
このチェックリストに従って支部担当者が請求書に不備がないかを判断し（Ｓ３４）、不備がなければ全てのチェックポイントに「チェック済」を示す情報が入力される（Ｓ３５）。全ての「チェック済」情報が入力されたかは保全業務支援手段３８が監視し、１つでも「チェック済」の情報が入力されていなければ「不備あり」とみなして決裁処理には移行させない。全てが「チェック済」になると、請求書を決裁者に回付するための社内送付状が支部端末６から印刷されると共に、決裁者端末や管理部門等に対して決裁指示情報が送信される（Ｓ３６）。この時点で進捗情報が「チェック完了」に更新される（Ｓ３７）。支部担当者は、請求書に上記社内送付状を付して所定の決裁機関に回付する。
【００７０】
一方、請求書の不備が発見された場合（支部端末６からの不備項目の入力を受け付け、かつ不備請求書を受領した場合）は、保全業務支援手段３８が顧客５向けの案内文データを生成して案内文を印刷する（Ｓ３８）。この案内文も、顧客５の登録住所に郵送される。そして、この時点で、進捗情報が「不備」に更新される（Ｓ３９）。案内文には前記不備のある請求書が同封され、顧客が案内文に従って請求書を修正して返送すると、上記Ｓ３１に戻って処理が繰り返される。
【００７１】
請求書が決裁者に届き、この決裁者が社内端末で決裁済み情報を入力すると（Ｓ４０）、契約情報の更新が指示されると共に、この保全手続の進捗情報が「決了（決裁済）」に更新される（Ｓ４１）。
【００７２】
そして、契約情報更新手段３７が、契約情報ＤＢ２２に登録されている情報を請求内容に従って更新し、更新日及び更新項目（変更履歴）を登録すると共に（Ｓ４２）、進捗管理手段３６がこの保全手続の進捗情報を「データ更新済」に更新してこの処理を終了する（Ｓ４３）。
【００７３】
次に、図７〜図１３の画面例等を参照して、請求書の作成処理（Ｓ２９）、点検結果の入力と請求書の決裁者への回付の処理（Ｓ３３〜Ｓ３５）、請求書に不備があった場合の処理（Ｓ３８）、及び保全業務の進捗照会の各処理を説明する。
【００７４】
まず、図７の画面例を参照して、請求書の作成処理（Ｓ２９）を説明する。  
この処理では、支部担当者が支部端末６のディスプレイに表示された図示しない処理メニュー画面で保険証券番号を入力すると、図７の「試算・請求書データ作成画面」が表示される。この画面の紙面左側には、保険証券番号に基づいて検索された契約書データが表示される。支部担当者が、画面上部の「請求書作成」にチェックした上で、顧客５が変更を希望する条件を個別に選択入力していく。この例は、主契約は変更せず、複数の特約について、「減額」と「解約」とを請求している。
【００７５】
全ての項目を選択し、画面左上の「送信」ボタンを押すと、確認画面が表示される。この確認画面で、支部担当者が変更後の保険料や請求者の属性等を確認した上で、「送信」ボタンか「次へ」ボタンを押すと、請求書の送付先などの確認画面に遷移する。この画面で、送付先などを確認して「送信」ボタンを押すと、入力されたデータや検索された契約書データ等が本店４の保全業務処理システム１に送信され、請求書データ生成手段３４に請求書データと案内文書データの生成が指示される。生成された請求書データ及び案内文書データはプリンタ７に出力され、図４の保全手続の請求書と、図５の案内文書が印刷され、顧客の登録住所宛に本店４から郵送される。
【００７６】
次に、図８の画面例と図９の社内送付状の例を参照して、点検結果の入力と請求書の決裁者への回付の処理（Ｓ３３〜Ｓ３５）を説明する。  
この処理は、支部担当者が、顧客５から返送された請求書に表示されたバーコード（図４参照）をバーコードリーダ８で読み取ることで開始する。読み取った保全手続の識別情報は本店４の保全業務処理システム１に送信され、契約情報やこの保全手続のチェックリストなどを含む図８の点検入力画面が生成されて支部端末６に表示される。支部担当者は、チェック項目に従って顧客５から返送された請求書や添付書類を点検し、チェックポイントに点検結果（「ＯＫ」「ＮＧ」「？」の何れか）を順次入力していく。全ての項目について「ＯＫ」であれば、画面左上の「送信」ボタンを押して、提出書類確認画面を表示させる。この画面で、書類の種類などを確認し「送信」ボタンを押すと、点検結果確認画面に遷移する。この画面で点検結果等を最終確認し「印刷」ボタンを押すと、請求書等を決裁者に回付するための図９の社内送付状が支部端末６に接続されたプリンタ７に出力される。これと同時に、決裁者端末等に決裁の指示情報（ワーニングなど）が送信される。
【００７７】
次に、図１０〜図１１の画面例と図１２の案内文の例を参照して、請求書に不備があった場合の処理（Ｓ３８）を説明する。  
この処理は、図８に示した点検入力画面のチェックリストで、「ＮＧ」や「？」が１つでも含まれている場合に開始する。まず、支部端末６に不備入力画面が表示され、支部担当者が発見した不備の項目のうち、書類の種類等に関する情報の入力を受け付ける。なお、この画面の左側に、この契約についての変更履歴情報（手続中・ファイル更新済の情報）が表示されており、支部担当者の注意を喚起している。
【００７８】
この画面で支部担当者が書類の種類等を入力して画面左上の「送信」ボタンを押すと、図１０の具体的な不備の入力画面が表示される。この画面で、支部担当者が不備項目を入力して「送信」ボタンを押すと、本店４の保全業務処理システム１に契約情報や不備の情報が送信される。保全業務処理システム１が不備の情報を受信すると、前記保全業務支援手段３８が顧客へ送付する案内文のデータ（図１１に示す）を生成して支部端末６に表示させる。支部担当者は、この画面上で不備の説明文などを確認すると共に、挨拶文などの少数の項目を入力して「送信」ボタンを押す。すると、保全業務支援手段３８が追加入力された情報を含む案内文データをプリンタに出力して図１２に示す請求書不備の案内文を印刷する。この案内文は、顧客の登録された住所宛に本店４から郵送される。
【００７９】
最後に、図１３の画面例を参照して、保全業務の進捗照会の処理を説明する。  
顧客５から、電話や窓口で保全手続の進捗状況の照会があった場合、図示しない取引メニュー画面で保険証券番号を入力し「進捗状況の照会」ボタンを押すと、図１３の照会画面が表示される。この例では、請求書作成から決裁及び契約情報の更新まで９日間かかっている。
【００８０】
なお、この発明は上記の実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。
【００８１】
例えば、上記実施形態においては、本店４などのメインフレームで保全業務処理システム１を構成したが、支部内に設置したサーバと支部端末６とでシステムを構成してもよい。さらに、一部の保全手続の決裁を支部で行える場合には、支部端末６だけでシステムを構成することもできる。
【００８２】
また、決裁基準や各種の識別情報、請求書や案内文のフォーマット等も上記の例に限らない。
【図面の簡単な説明】
【００８３】
【図１】図１は、本発明の一実施形態のネットワーク構成図である。
【図２】図２は、同、保全業務処理システムの概略構成を示す機能ブロック図である。
【図３】図３は、決裁基準テーブルのデータ構造を示す図である。
【図４】図４は、保全手続の請求書の一例を示す図である。
【図５】図５は、請求書の送付状の例を示す図である。
【図６】図６は、保全業務の処理工程を示すフローチャートである。
【図７】図７は、請求書作成画面の例を示す図である。
【図８】図８は、点検結果の入力画面の例を示す図である。
【図９】図９は、保全手続の請求書の社内送付状の例を示す図である。
【図１０】図１０は、請求書の不備入力画面の例を示す図である。
【図１１】図１１は、請求書の不備の案内文の作成画面の例を示す図である。
【図１２】図１２は、請求書の不備の案内文の例を示す図である。
【図１３】図１３は、保全業務の進捗状況照会結果の表示画面の例を示す図である。
【符号の説明】
【００８４】
１…保全業務処理システム
２…生命保険会社
３…支部
４…本店
５…顧客
６…支部端末
７…プリンタ
８…バーコードリーダ
９…通信端末
１１…ＣＰＵ
１２…システムバス
１３…ＲＡＭ
１４…外部記憶装置
１４ａ…データ記憶領域
１４ｂ…プログラム格納領域
１５…入出力インタフェース
１７…入力装置
１８…出力装置
１９…通信デバイス
２０…リムーバブル記録媒体
２１…ドライブ
２２…契約情報データベース（ＤＢ）
２３…決裁基準テーブル
２４…チェックポイントテーブル
２５…進捗管理データベース（ＤＢ）
２６…請求書情報データベース（ＤＢ）
２７…案内文テーブル
３０…請求受付手段
３１…契約情報検索手段
３２…決裁基準特定手段
３３…決裁レベル判定手段
３４…請求書データ生成手段
３５…決裁済情報受付手段
３６…進捗管理手段
３７…契約情報更新手段
３８…保全業務支援手段
４０…案内文生成手段
【図１】
2009230380.tif 000003
【図２】
2009230380.tif 000004
【図３】
2009230380.tif 000005
【図４】
2009230380.tif 000006
【図５】
2009230380.tif 000007
【図６】
2009230380.tif 000008
【図７】
2009230380.tif 000009
【図８】
2009230380.tif 000010
【図９】
2009230380.tif 000011
【図１０】
2009230380.tif 000012
【図１１】
2009230380.tif 000013
【図１２】
2009230380.tif 000014
【図１３】
2009230380.tif 000015