(57)【要約】【課題】払込み収集を伴う金融プログラムの管理システムと方法を提供する。【解決手段】システム（１０２）には、金融プログラムの管理を統合する保険料請求システムが含まれ、そのプログラムには、利用者が保険料請求システム（２０２）とやりとりするインタフェースロジックと、金融プログラムに関するバッチ処理を行うバッチ処理ロジックが含まれる。さらに、本システムは、保険料請求システムに接続され、金融プログラムを管理し、保険料請求システムと通信する支援システムを少なくとも１台備える。データ記憶装置（１０９）は、金融プログラムを管理する際に保険料請求システムによって使用されるデータテーブル（１１４）を記憶し、金融プログラムを管理するために以前使用された旧システムによって保持された情報の表現が含まれる。【選択図】図１
2004510224.tif 000002
【特許請求の範囲】
【請求項１】
払込み収集を伴う金融プログラムの管理システムであって、
前記金融プログラムの管理を調整する保険料請求システムであって、利用者が前記保険料請求システムとやりとりすることを可能にするインタフェースロジックと、金融プログラムに関するバッチ処理を実行するバッチ処理ロジックを含む、当該システムと、
前記保険料請求システムに接続され、前記金融プログラムを管理する一態様を扱い、前記保険料請求システムと通信する、少なくとも１台の支援システムと、
金融プログラムを管理する際に保険料請求システムで使用されるデータテーブルを記憶するデータ記憶装置であって、前記金融プログラムを管理するために以前使用された旧システムによって管理された情報の表現を含む、当該データ記憶装置を備えるシステム。
【請求項２】
前記インタフェースロジックは、
保険契約管理を実施するインタフェースロジックと、
請求と保険料払込みを管理するインタフェースロジックと、
払込免除処理を実施するインタフェースロジックと、
貸付処理を実施するインタフェースロジックと、
解約返戻金処理を実施するインタフェースロジックと、
延長効力処理を実施するインタフェースロジックと、
システム関連の管理を行うインタフェースロジックと、
前記旧システムによって管理された情報の表現を利用するインタフェースロジックのうちの少なくとも１つを含む、請求項１のシステム。
【請求項３】
前記バッチ処理ロジックは、預金徴収者から払込通知を受け取るロジックを含む、請求項１のシステム。
【請求項４】
前記バッチ処理ロジックは、前記少なくとも１台の支援システムとやりとりするロジックを含む、請求項１のシステム。
【請求項５】
前記少なくとも１台の支援システムは、
死亡に関する保険請求を扱う死亡請求システムと、
満期養老関連の事柄を扱う満期養老システムと、
保険料払込免除処理を扱う保険料払込免除システムを備える、請求項１のシステム。
【請求項６】
前記金融プログラムは、前記金融プログラムの別の態様を扱う複数の処理ルーチンの実行に関与し、前記システムは、これらのさまざまな処理ルーチン間のやりとりを容易にする機能を備える、請求項１のシステム。
【請求項７】
前記旧システムによって管理された情報の表現を利用する前記インタフェースロジックは、そこから保険契約情報を検索するロジックを含む、請求項２のシステム。
【請求項８】
前記金融プログラムは保険プログラムである、請求項１のシステム。
【請求項９】
前記保険プログラムは、週毎もしくは月毎に発生する払込期日を備える、請求項８のシステム。
【請求項１０】
前記システムは、クライアント／サーバアーキテクチャでのサーバとして実現される、請求項１のシステム。
【請求項１１】
前記データ記憶装置は、リレーショナルデータベースとして実現される、請求項１のシステム。
【請求項１２】
払込み収集を伴う金融プログラムの管理方法であって、
前記金融プログラムの管理を調整する保険料請求サービスを提供する工程であって、前記保険料請求サービスはデータ記憶装置に接続され、前記データ記憶装置は変換レコードと前記金融プログラムを管理するために以前使用された旧システムによって管理された情報の表現を含む、当該工程と、
前記保険料請求サービスとやりとりするインタフェースを提供する工程と、
前記インタフェースを介して利用者から金融保険契約に関する情報についてのリクエストを受け取る工程と、
前記保険契約情報が前記データ記憶装置に記憶された変換レコードから得られるかどうかを判断する工程と、
前記保険契約情報が前記変換レコードから得られる場合に、そこから前記保険契約情報をから検索する工程と、
前記保険契約情報が前記変換レコードから得られない場合に、前記旧システムによって管理された情報の表現から前記保険契約情報を検索する工程を備える方法。
【請求項１３】
前記インタフェースは、
保険契約管理を実施するインタフェース機能と、
請求と保険料払込みを管理するインタフェース機能と、
払込免除処理を実施するインタフェース機能と、
貸付処理を実施するインタフェース機能と、
解約返戻金処理を実施するインタフェース機能と、
延長効力処理を実施するインタフェース機能と、
システム関連の管理を実施するインタフェース機能のうちの少なくとも１つを利用者が利用できるようにするものである、請求項１２の方法。
【請求項１４】
前記旧システムによって管理された情報の表現から得られる前記保険契約情報は、前記保険料請求サービスが導入された際に前記保険料請求サービスに転送されなかった保険契約に属するものである、請求項１２の方法。
【請求項１５】
前記金融プログラムは保険プログラムである、請求項１２の方法。
【請求項１６】
前記保険プログラムは、週毎あるいは月毎に発生する払込期日を備える、請求項１５の方法。
【請求項１７】
払込み収集を伴う金融プログラムの管理システムであって、
前記金融プログラムの管理を調整する保険料請求システムであって、利用者が前記保険料請求システムとやりとりすることを可能にするインタフェースロジックと、前記金融プログラムに関するバッチ処理を実行するバッチ処理ロジックを含む、当該保険料請求システムと、
前記保険料請求システムに接続され、金融プログラムを管理する一態様を扱い、保険料請求システムと通信する少なくとも１台の支援システムと、
前記金融プログラムの管理の際に前記保険料請求システムによって使用されるデータテーブルを記憶するデータ記憶装置を備え、
前記インタフェースロジックは、
基本保険契約管理を実施するインタフェースロジックと、
請求と保険料払込みを管理するインタフェースロジックと、
払込免除処理を実施するインタフェースロジックと、
解約返戻金処理を実施するインタフェースロジックと、
延長効力処理を実施するインタフェースロジックと、
システム関連の管理を実施するインタフェースロジックを含む、システム。
【請求項１８】
払込み収集を伴う金融プログラムの管理方法であって、
前記金融プログラムの管理を調整する保険料請求サービスを提供する工程であって、前記保険料請求サービスはデータ記憶装置に接続される、当該工程と、
前記保険料請求サービスとやりとりするインタフェースを提供する工程と、
基本保険契約管理を実施するインタフェース機能と、
請求と保険料払込みを管理するインタフェース機能と、
払込免除処理を実施するインタフェース機能と、
貸付処理を実施するインタフェース機能と、
解約返戻金処理を実施するインタフェース機能と、
延長効力処理を実施するインタフェース機能と、
システム関連の管理を実施するインタフェース機能から選択するオプションを利用者に提供する工程を備える方法。
【請求項１９】
ロジックを処理することによって実行する際に、払込みの収集を伴う金融プログラムを管理するコンピュータ読取可能媒体であって、
利用者が保険料請求サービスとやりとりすることを可能にするインタフェースロジックと、
前記金融プログラムに関するバッチ処理を実行するバッチ処理ロジックを備え、
前記インタフェースロジックは、
基本保険契約管理を実施するインタフェースロジックと、
請求と保険料払込みを管理するインタフェースロジックと、
払込免除処理を実施するインタフェースロジックと、
貸付処理を実施するインタフェースロジックと、
解約返戻金処理を実施するインタフェースロジックと、
延長効力処理を実施するインタフェースロジックと、
保険料請求システムでシステム関連の管理を実施するインタフェースロジックと、
前記金融プログラムを管理するために以前使用された旧システムによって管理された情報の表現を利用するインタフェースロジックのうち少なくとも１つを含む、コンピュータ読取可能媒体。
【請求項２０】
前記金融プログラムは保険プログラムである、請求項１９の媒体。
【請求項２１】
前記保険プログラムは、週毎あるいは月毎に発生する払込期日を備える、請求項２０の媒体。
【発明の詳細な説明】
【０００１】
【発明の背景】
本発明は一般的に、払込みの収集に関わる金融プログラムを管理するシステムと方法に関する。特定の実施形態に係る本発明は、生命保険契約に付随する払込みの収集に関わる保険プログラムの管理システムと方法に関する。
【０００２】
一般的に、金融プログラムには、定期的に大量の情報を処理することが求められる。例えば、通常の保険プログラムでは顧客から保険料の払込みを定期的に収集し処理する必要がある。従って、金融分野では、これらの作業を自動化するためにコンピュータを大いに活用しているのは当然のことである例えば、コンピュータテクノロジは少なくとも１９７０年代から金融分野で大いに利用されてきた。
【０００３】
多くの金融プログラムでは、長期間に渡って顧客にサービスを提供する。例えば、顧客が何十年も継続するサービスを受けることを選んだ場合には、仲介システムと銀行業務関連システムには顧客にサービスを中断することなく提供することが求められる。また、このことは特に生命保険プログラムに当てはまる。生命保険プログラムでは、保険契約した保険会社から、保険契約が終了（例えば、死亡）した顧客に対して中断することのない信頼性の高いサービスの提供が求められる。この場合のサービス期間は、顧客の一生のうちの大切な時期であるかもしれない。
【０００４】
長期間にわたって保険プログラムに関与することになるので、そのプログラムを実行するコンピュータ装置は時代遅れのものなることがある。例えば、金融業者の中には、「古いデータベース」とやりとりする「古いシステム」から、「新しいデータベース」とやりとりする「新しいシステム」に管理を移行することを面倒に感じて、既存のシステムを変更することに気が進まないものもいる。記憶されたデータの完全性を損なうことなく、また、顧客にサービスを中断することなく提供しながらこの移行を行う必要がある。サービスの質に関する先の制約条件を満たしながら、古いシステムから新しいシステムに移行する方法がいつも明らかになっているとは限らない。
【０００５】
特に、本発明者は理解していることであるが、従来のシステムを引続き利用する必要が無い方法で、従来のシステムで得られたデータを変換することが望ましい。これには、新しいシステムとは異なる実行プラットフォームを使って従来のシステムのデータが保存されているため、データ移行の問題があるからである。複数であったり複雑な構成をしたデータファイルとしてそのデータが従来システムに格納されている場合には、データの移行は一層困難になる。また、本発明者は理解していることであるが、旧システムから新システムへのデータ変換の際にある程度の柔軟性があることが望ましい。例えば、長年存在するシステムでは、こわれたデータがこわれていたり、データがなくなっていたり（紛失していたり）、プログラムコードがこわれていたりなくなってしまっているという被害があるかもしれない。本発明者は理解していることであるが、このような異常事態が、一回の労力でデータやロジックを新しいシステムに移行することを困難にしている。むしろ、システム設計者はデータの変換方法を変えた方がよいと考えるかもしれない（従って、データ移行に柔軟性があることが有効な特徴となる）。公知の従来技術にはこれらの問題の対処方法が示されていない。実際上、上述したような形でこの問題について言及する見識をもつ者が他にいることを示すものはない。
【０００６】
その他のプロバイダも、プログラムに十分な関心がないので、システムの変更に関して気が進まない可能性がある。例えば、プロバイダは、契約上既存の契約者にサービスを提供し続ける義務を負っているはずだが、（より利益になると考えられる）その他の営業活動に関心が向いている場合がある。そのようなプロバイダは、システムを機能的に改良する気があまりなく、能率のよい業務を行っていないかもしれない。
【０００７】
上述の理由から、プロバイダの中には、長期間、最適でないメインフレーム技術などの非最適なテクニカルプラットフォームを使用して金融プログラムを管理する所があるかもしれない。このため、プロバイダは、十分な効率でプログラムを実行できない可能性がある。さらに、旧式のテクニカルプラットフォームを使用すると、プログラムに関連する「故障」やハードウェアの「故障」によってエラーが生じる可能性がある。１０００年の最後には、時間に基づくエラー源がこれらのシステムに与えられるかもしれない。
【０００８】
コンピュータシステムのデータベース内で選択された表を変更し、処理能力を上げ、高度ネットワークを利用可能にすること等によって既存のシステムを少しずつ改良することができる。しかしながら、注意深く設計しないと、そのような断片的な改良によって既存システムと新システム間の互換性に問題が生じる可能性がある。
【０００９】
テクニカルプラットフォームを改良する努力を十分に行っている金融プロバイダであっても、満足のいくシステムを作れないことがある。例えば、生命保険プログラムの形態の中には、顧客からの払込みに関する処理を頻繁に行う必要があるものがある。例えば、「デビット」保険プログラム、もしくは「簡易保険」プログラムとして知られているシステムでは、週毎や月毎（あるいは、その他のかなり短い期間）のようにかなり頻繁に生命保険料の情報を収集する必要がある。この特徴から、保険提供システムにかなりの負担がかかる場合があり、システムとやりとりして払込みを処理したり保険契約を管理したりする必要のある者にかなりの負担がかかる可能性がある。技術的な解決策が、そのような「頻繁な収集」サービス固有の特徴に適切に対応したものではない場合、使用の際に効率が悪かったり、エラーが発生し易かったり、使いづらかったりするシステムが提供されてしまうことになる。そのような要因によって最終的には保険プログラムの利益が減少することになる。
【００１０】
特許文献には、金融分野でコンピュータ技術を利用した例が幾つかある。保険関連の特許の例としては、米国特許第５、４２９、５０６号（連邦保証年金と生命保険投資の処理方法とシステム）と、米国特許第５、４７９、３４４号（保険計算ディスプレイ）と、米国特許第５、６３１、８２８号（生命保険の方法とシステム）と、米国特許第５、７５２、２３６号（管理監督コンピュータシステムを使用した生命保険プランのコンピュータによる管理方法）と、米国特許第６、０４１、３０４号（生命保険契約の解約返戻金の増加を管理するシステムと方法）がある。
【００１１】
しかしながら、このような特許に記載されたシステムが上述の問題に対して完璧で十分な解決策を提供できることは示されていない。特に、これらのシステムによって既存のシステムから新しいシステムに移行するための十分に満足のいく手段が提供されることは示されていない。また、これらのシステムによって、払込みをかなり頻繁に収集する必要のある保険契約などの幾つかの上述した特有の種類の保険プログラムを管理する十分に満足のいく手段が提供されるとも示されていない。
【００１２】
従って、保険プログラムを管理するより効率のよいシステムと方法が求められている。
【００１３】
【発明の概要】
本発明は、上述の特定のニーズ並びにその他の明記していないニーズに焦点を当てたものである。
【００１４】
本発明の模範的な一態様は、払込みの収集に関する金融プログラムの管理システムに関する。本システムには、金融プログラムの管理を調整する保険料請求システムが含まれ、そのプログラムには、利用者と保険料請求システムとのやりとりを可能にするインタフェースロジックと、金融プログラムに関連するバッチ処理を実行するバッチ処理ロジックが含まれている。さらに、システムには、保険料請求システムに接続されており、金融プログラムの一管理態様を処理し保険料請求システムと通信する支援システムが少なくとも１台含まれている。さらに、システムには、金融プログラムの管理の際に保険料請求システムが使用するデータ表を記憶するデータ記憶装置が含まれている。また、データ記憶装置には、金融プログラムを管理するために、以前は使用されていた旧システムで保持する情報の説明が含まれている。
【００１５】
本発明の模範的なその他の一態様では、インタフェースロジックには、基本保険契約を維持するインタフェースロジックと、請求業務と保険料払込みを管理するインタフェースロジックと、保険料払込み免除処理を行うインタフェースロジックと、貸付処理を行うインタフェースロジックと、解約返戻金処理を行うインタフェースロジックと、延長効力処理を行うインタフェースロジックと、システム関連の保守を行うインタフェースロジックと、旧システムが保持する情報の説明を利用するインタフェースロジックのうち少なくとも１つが含まれている。
【００１６】
本発明の模範的なその他の態様によれば、金融プログラムは、金融プログラムのその他の態様を取り扱う複数の処理ルーチンのパフォーマンスを必要とし、本システムにはそれらの異なる処理ルーチン間のやりとりを容易にする機能が含まれている。
【００１７】
好適な一実施形態の金融プログラムとは保険プログラムである。その他の好適な実施形態の保険プログラムには、週毎や月毎にある払込みの期日が含まれている。
【００１８】
本発明のその他の特徴は、添付図面と関連付けて以下の詳細な説明について検討すれば明らかになる。
【００１９】
【発明の実施の形態】
本願に記載されたシステムと方法は、かなり頻繁に（例えば、週毎や月毎やその他のインターバルでの）払込みが起こり、給付がかなり低額であることを一般的に特徴とする保険契約の管理に適用可能である。一般的に、この種類の保険は、「簡易保険」や「月払保険料請求普通（ＭＯＤ）保険」や「週払保険料（ＷＰ）保険」や「家庭向サービス提供保険」と呼ばれる。また、これらのプログラムでは、伝統的に、保険料を徴収するために特定の周期毎に保険契約者を直接訪問する保険外交員を活用することが特徴であった。しかしながら、現状では明らかに、保険契約者は保険提供業者にその他の方法で（メールしたり、銀行口座からの預金自動引落しを許可するなどによって）払込むことが多い。「保険料」とは、契約上、保険契約を有効に維持するために定期的に支払う必要がある額のことである。
【００２０】
しかしながら、本願に記載のシステムと方法は、その他の種類の金融プログラムにも適用可能である。例えば、本システムと方法は、その他の種類の保険契約の管理、ならびに様々な貸付プログラムの管理等にも適用できる。
【００２１】
本願の第１章では、本発明を実現するための模範的なシステム構成の概要を説明する。第２章では、関連するバッチ処理や画面表示などと共に、本発明で使用される様々なプロセスの流れについて説明する。そして、第３節では、本発明の模範的な特定の一実装形態を説明する一連のテーブルを提供する。また、第３節には、第１章と第２章で使用される用語から選択した用語を定義する用語集（テーブル６）を記載する。
【００２２】
１．システム構成（図１〜図３）
図１は、本発明を実現するシステム１００の全体像を示したものである。システム１００は、（図２で詳細に説明される）保険プログラムを管理する保険処理システム１０２を特徴とする。保険処理システム１０２は、（図３で詳細に説明される）１台以上のワークステーション（ワークステーション１０４、１０６、１０８など）に直接接続される。１台以上のその他のワークステーション（ワークステーション１１８、１２０など）は、企業内イントラネットや同様のネットワークなどのローカルネットワーク１１６を介して保険処理システム１０２に接続されていてもよい。ワークステーションサーバは、保険処理システム１０２とやりとりする「ポータル」として働く。即ち、利用者は、ワークステーションを利用して保険処理システム１０２に入り、保険処理システム１０２から情報を検索することができる。
【００２３】
保険処理システム１０２を、現在使用されなくなった従来システム１１４の１台（または複数台）に置き換えることができる。従来のシステム１１４は、（例えば、保険処理システム１０２を導入する前に）保険プログラムを管理する組織が以前使用していたテクニカルプラットフォーム（および関連するデータベース）に相当する。例えば、従来のシステム１１４は、保険プログラムを実現するために使用される１台以上のメインフレームシステムであってもよい。一方、保険処理システム１０２は、（例えば、クライアント／サーバ構成での）サーバ型テクニカルプラットフォームであっても、更新されたその他の構成であってもよい。
【００２４】
保険処理システム１０２には、複数のテーブルを用いて保険契約に属する情報を格納するデータ記憶装置１０９が備わっている。そのような情報には、指定された変換日（または、複数の日）に旧システム１１４から抽出され保険処理システム１０２と互換性のあるフォーマットに変換された保険契約データ（このため、「変換データ」と呼ばれる）が含まれていてもよい。例えば、一実施形態では、変換日での値（ｖａｌｕｅ）を保持している保険契約のみが変換され、従来システム１１４から保険処理システム１０２に転送される。つまり、一実施形態では、変換時には、解約や満期や満了などになった保険契約は変換されなかった。
【００２５】
即ち、保険処理システムは旧システム１１４の表現（即ち、「ミラー」）１１５も備えていてもよい。この表現１１５には、従来システム１１４を新規システム（即ち、保険処理システム１０２）に変換した時に存在した、全保険契約のデータフィールドの値を特定する情報を記憶するデータベースが含まれてもよい。このようなデータベースには、従来システム１１４で使用されたデータ構造を反映させことができる。図示された実施形態では、旧システム１１４の表現１１５がデータ記憶装置１０９の一部として示されている。その他の実施形態では、表現１１５を個別の記憶モジュールとして実現することができる。また、さらに別の実施形態の旧システム１１４の表現１１５には、そのようなデータ値を保険処理システム１０２と互換性のあるフォーマットに変換するインタフェースロジックが含まれてよい。
【００２６】
この独特なコンフィギュレーションのおかげで、保険処理システム１０２はデータ記憶装置１０９をアクセスして、通常の保険契約処理の過程で変換されたレコードを検索することができる。さらに、必要であれば、保険処理システム１０２では、表現１１５からデータを抽出することもできる。例えば、保険処理システム１０２では、適切に転送されなかったり、変換日に新システム１０２のテーブル構造に適切に変換されなかった保険契約に関する情報を利用することが必然か、または有効であると認識される場合がある。本文書の後章では、保険処理システム１０２と旧システムの「ミラー」１１５間のやりとりに関して詳述する。
【００２７】
また、保険処理システム１０２は、１つ以上の金融機関（金融機関１１０、１１２など）とやりとりすることができる。例えば、金融機関１１０には、保険料払込み通知を保険処理システム１０２へ送るために利用される銀行が含まれていてもよい。金融機関１１２には、（保険契約者が自分の保険契約の解約返戻金に基づく貸付に対する資格がある場合）貸付払込通知を保険処理システムへ転送するために利用される銀行が含まれていてもよい。この転送は、電子通信またはその他の手段によって行うことができる。特に、一実施形態の保険契約者は、支払いが配賦される請求口座を指定する請求書「控え」に付記された銀行に対して払込みを行うことができる。そして、銀行は、払込まれた旨を保険会社（例えば、システム１０２）に日々通知する。この処理は「分割払込処理」と呼ばれる。
【００２８】
さらに、保険処理システム１０２は、オプションとして、インタネットなどの広域ネットワーク１２２に接続可能である。その接続によって、遠隔地にいる利用者は、例えば、ワークステーション１２４、１２６を介して保険処理システム１０２をアクセスすることができる。また、その接続によって、保険処理システム１０２は、例えば１台以上の遠隔サーバ（サーバ１２８など）によって実現される様々な遠隔資源とやりとりすることができる。
【００２９】
最後に、保険処理システム１０２が保持しているデータの完全性を守るためにファイアウォール１４０が利用可能である。特に、一実施形態では、ファイアウォール１４０の上に位置する装置は保険プログラムを管理する組織に関連付けられており、ファイアウォール１４０の下に位置する装置は保険プログラムの管理上で直接的な役割を果たさない外部エンティティと関連付けられている場合がある。ファイアウォール１４０には、その管理組織外の者が、保険処理システム１０２によって管理されている機密情報にアクセスすることを防止する（その組織内の者が機密情報を組織外のパーティに漏らさないようにする）従来の機能が含まれている。
【００３０】
図２は、保険処理システム１０２の模範的な一実装形態を示すものである。保険処理システム１０２には、保険プログラムを管理するための主要な「エンジン」として働く保険料請求システム２０２が備わっている。保険料請求システム２０２は、通信インタフェース２０３と、データ記憶装置１０９と、「支援システム」とも呼ばれる様々な保険処理システム（システム２１２、２１４、２１６、２１８など）に接続される。これらの保険処理システム（例えば、システム２１２、２１４、２１６、２１８）は、保険料請求システム２０２外にある。これは、それらの保険処理システムがそのシステムとは（互いに）独立に存在するという意味であるが、それらのシステムは保険料請求システム２０２と（相互に）簡単にやりとりすることができる。通信インタフェース２０３は、図１で上述したエンティティ（ワークステーションやイントラネットや金融機関など）とやりとりするために使用される。データ記憶装置１０９には、割り当てられた保険処理の機能を実行するに際に保険料請求システムで使用される様々なデータテーブルが記憶されている。例えば、データ記憶装置には下記の第３節のテーブル１で特定されるデータテーブルが記憶されていてもよい。また、データ記憶装置１０９には、従来システム１１４の「ミラー」１１５も記憶されていてよい。
【００３１】
様々な外部システム（２１２、２１４、２１６、２１８）は、保険プログラムの様々な態様を扱う。例えば、死亡請求システム２１２では、保険契約者の死亡に関する請求処理と最終的処置を行う。特に、「死亡請求」は、被保険者の死亡に基づく保険契約条項に従う支払い要求のことである。
【００３２】
満期養老システム２１４では、満期養老に関する請求処理と最終的処置を行う。保険契約では、保険契約の解約返戻金が保険契約によって払込まれる保険満額と同額なった時点で「満期になる」。「満期養老」とは、解約返戻金が保険契約に基づいて払込まれる保険満額と同額となる（被保険者が生存している）保険契約を指す。
【００３３】
保険料払込免除システム２１６は、保険料払込免除に関する保険プログラムの態様を扱う。「払込免除処理」とは、被保険者が払込み不能となりその保険契約に傷害特約が付加されていたので、保険料の払込みを免除する場合に実施される処理のことである。（一般に「特約」とは、保険契約に基づく付加的な、即ち「副次的な」担保を意味する。）保険契約が保険料払込免除ステータス（即ち、「ＷＡＩＶ」ステータス）になった後、保険料は本質的には保険会社から支払われる。被保険者が将来払込み可能になった場合、保険契約を保険料払込みステータスに戻すことができる。
【００３４】
また、保険料請求システム２０２は、保険プログラムのその他の態様を扱うことができるその他の様々なシステム２１８と交信することができる。
【００３５】
保険料請求システム２０２自体には、割り当てられた機能を実行するための様々な機能モジュールが含まれてもよい。例えば保険料請求システム２０２には、ワークステーションの利用者が保険処理システム１０２とやりとりする際に利用する様々なインタフェース画面（例えば図１１から４３）を提供するインタフェースロジック２０４が備えられる。特に、インタフェース画面には、データ記憶装置１０９に記憶されたレコードとやりとりするために利用されるグラフィックユーザインタフェース（ＧＵＩ）ページが含まれている。また、保険料請求システム２０２には、（例えば、下記のテーブル２、３で特定される処理やレポートで例示するなどの）バッチ単位での様々な処理やレポート作成を行うバッチ処理ロジック２０６が含まれてもよい。特に、「バッチ処理」とは、データベースから抽出された情報をかなり大量にまとめてコンピュータで処理することである。そのような処理は利用者が保険処理システム１０２とネットワークで繋がっていない夜間に実施されることが多い。
【００３６】
さらにインタフェースロジック２０４とバッチ処理ロジック２０６には、保険処理システム１０２の別の態様で相互に通信することを可能にする相互作用機能が組み込まれている。例えば、貸付処理を対応する保険処理システム１０２の態様では、（貸付残高が解約返戻金を上回った場合には担保が中止されるので）解約返戻金処理を対応する保険処理システム１０２の複数の態様と相互に作用できることが望ましい。さらに、例えば保険料請求／払込み処理を対応する保険処理システム１０２の態様では、（担保が変更になった場合に保険料が変わるので）保険契約管理処理を対応する保険処理システム１０２の複数の態様と相互に作用できることが望ましい。従ってシステム１０２では一般に、金融プログラムの別の態様を対応する複数の処理ルーチンを実行させる必要があると言われており、システムにはそのような様々な処理ルーチン間でやりとりすることを容易にする機能が含まれてもよい。
【００３７】
さらに保険料請求システム２０２には、オンラインレポートを作成するロジックや様々な外部支援システム（死亡請求システム２１２や満期養老システム２１４など）とやりとりするロジックなどのような割り当てられた機能のその他の態様に対応するためのその他の処理ロジック２０８が含まれてもよい。ロジック（２０４、２０６、２０８など）は、プロセッサでの実行時に様々な機能を実現する機械コードとして利用される。保険料請求処理システムの「出力」の一部には、通信インタフェース２０３によって提供されるインタフェース画面表示と、（レポート２２２として一般的に表示される）様々なハードコピーのレポートやオンラインレポートが含まれる。
【００３８】
保険処理システム１０２は、様々なアーキテクチャで実現することができる。例えば、システム１０２は（クライアント／サーバアーキテクチャ環境では）サーバコンピュータユニットとして実現することができる。例えば保険処理システム１０２には、Ｍｉｃｒｏｓｏｆｔ　ＷｉｎｄｏｗｓＮＴ（商標）やＷｉｎｄｏｗｓ２０００（商標）やＵｎｉｘ（商標）やＬｉｎｕｘ（商標）やＸｅｎｉｘ（商標）やＩＢＭ　ＡＩＸ（商標）やＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ　ＵＸ（商標）やＮｏｖｅｌｌＮｅｔｗａｒｅ（商標）やＳｕｎ　ＭｉｃｒｏｓｙｓｔｅｍｓＳｏｌａｒｉｓ（商標）やＯＳ／２（商標）やＢｅＯＳ（商標）やＭａｃｈ（商標）やＡｐａｃｈｅ（商標）やＯｐｅｎＳｔｅｐ（商標）やその他のオペレーティングシステムやプラットフォームで動作する従来のコンポーネント（例えば、プロセッサやメモリやキャッシュやインタフェース手段など）を有するサーバコンピュータが含まれてもよい。一実施形態の保険処理システム１０２には、一台のコンピュータが備えられてもよい。またその他の構成によれば、保険処理システム１０２が、分散方式で互いに接続された複数のコンピュータを備えおり、各コンピュータは保険プログラムの個別の態様を実行／管理してもよい。システム１０２に関連する装置は中央施設に配置されていてもよく、また、別の一実施形態では複数の施設に分散されてもよい。
【００３９】
一実施形態では、一台のコンピュータ（例えば一台のサーバ型コンピュータ）を使って、保険料請求システム２０２と、それに関連する死亡請求システム２１２や満期養老システム２１４や保険料払込免除システム２１６などの様々な外部支援システムを実現することができる。別の一実施形態では、個別のコンピュータを使用して、上で特定した各システムを実現することができる。当業者であれば、様々なアプリケーションからの要求に対応するために、さらにその他の処理機能の割り当てが可能であることを理解することができる。
【００４０】
データ記憶装置１０９は、一台のデータ記憶ユニットでも、分散方式で互いに接続された複数のデータ記憶ユニットでもよい。データ記憶装置１０９は、Ｏｒａｃｌｅ社から販売されているＯｒａｃｌｅ（商標）リレーショナルデータベースを利用して実現することができる。また、その他のデータベース、例えば、Ｉｎｆｏｒｍｉｘ（商標）やＤＢ２（データベース２）（商標）や、Ｓｙｂａｓｅ（商標）やその他のデータ記憶装置や照会形式や、ＯＬＡＰ（オンライン分析処理）などのプラットフォームもしくは資源や、ＳＱＬ（標準照会言語）や、記憶域ネットワーク（ＳＡＮ）や、Ｍｉｃｒｏｓｏｆｔ　Ａｃｃｅｓｓ（商標）なども利用することができる。データ記憶装置１０９には、磁気ディスクやテープや光学媒体などの記憶媒体を利用してデータを物理的に記憶することができる。
【００４１】
上述したように、データ記憶装置１０９には、変換日に旧システム１１４から変換された情報を表わす変換データレコードと、変換日に変換されずに、旧システム１１４で管理されている情報の表現１１５が含まれる。変換データは、更新されたシステム１０２で使用される（例えば、下の第３節のテーブル１のデータテーブルによって表される）データ構造を表現することができ、その表現１１５は、旧システム１１４のデータ構造を表現することができる。このような「古い」データの保存方法は、古いシステム１１４から新しいシステム１０２へ移行させる効率的で強力な方法である。
【００４２】
図３は、図１のシステム１００とやりとりする模範的な１台のワークステーションを示したものである。このワークステーションは、従来のハードウェアを備える汎用コンピュータもしくは特殊用途向コンピュータである。即ち、ワークステーションには、バス３１０を介してランダムアクセスメモリ（ＲＡＭ）３０４とリードオンリメモリ（ＲＯＭ）３０６と記憶装置３０８（ハードドライブやＣＤＲＯＭや光ディスクなど）に接続されたプロセッサ３１４が含まれる。さらに、ワークステーションには、情報を入力するための１台以上の装置３１８（キーボードやマウス型入力デバイスやタッチ画面もしくはタッチパネルなど）と、情報を表現するための１台以上の装置３１６（ディスプレイやプリンタなど）を含むインタフェースユニット３０２が備えられる。模範的な一実施形態のインタフェースユニット３０２には、図１１から図４３で示される画面が表示される。また、ワークステーションには（保険処理システム１０２やイントラネット１１６などの）外部装置とやりとりするための通信インタフェースデバイス３１２（モデムなど）が含まれている。このコンピュータは、Ｍｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ９８（商標）プログラムなどの様々なオペレーティングプログラムの１つを用いて動作可能である。
【００４３】
２．プロセスフローとそれに関する特徴（図４から図４３）
保険プログラムを管理する際に使われるプロセスフローは、保険料請求／払込み処理と、貸付処理と、保険料払込免除処理と、解約返戻処理と、延長効力処理と、死亡請求処理と、満期処理と、多種多様なシステム関連の管理に分類することができる。
【００４４】
一般的に、保険料請求／払込み処理とは、請求明細書の印刷とメール、そして、受け取った払込みを配賦し（例えば、その払込みを特定の保険契約の貸方に記入）、それに関連する処理作業を行うことを意味する。それに関連して、「保険料」とは、保険契約を有効に維持するために（契約上同意しているように）定期的に払込む必要がある最低額を指す。
【００４５】
貸付処理とは、保険契約に基づく貸付を設定したり、年間利息を変更したり、年間利息を請求したり、元金や利息に対する払込みを記録したり、（残存利息が保険契約額を上回る場合に）最低利息の払込みの収集／処理を行ったりするなどの貸付を成立させて管理することに関する様々な作業を意味する。
【００４６】
保険料払込免除処理とは、（保険契約者が身体障害を被った時など）保険契約者の保険契約に払込免除が設定されている場合に実施される様々な作業である。
【００４７】
解約返戻処理とは、保険契約を解約返戻額と等価なものに転換することに関連して実施される様々な作業に関するものであって、それによって保険契約は終了することになる。特に、保険契約の解約返戻金とは、保険契約期間中の任意の時に、保険契約者が担保を取り止めたり保険会社に対して解約したりした場合に受け取る金銭を意味する。保険契約者は、保険契約に基づく保険料の払込みを中止し、解約返戻金不没収オプションを要求して、保険契約の解約返戻金の支払いを受けることによって、保険契約を解約する。
【００４８】
延長定期保険とは、定期保険を購入するために一時払い純保険料として保険契約の純解約返戻金を配賦する保険契約に関する非没収オプションである。延長効力処理とは、保険契約を延長定期ステータスにするために実施される様々な処理（例えば、解約返戻金の算出など）である。
【００４９】
死亡請求処理とは、死亡請求が保険契約に基づいて提出された時に実施される様々な作業を意味する。「死亡」請求とは、被保険者の死亡に基づく保険契約条項に従った支払い要求を意味する。
【００５０】
満期処理とは、保険契約が満期に迎えた時に実施される様々な作業を意味する。保険契約は、保険契約の解約返戻金が保険契約によって払込まれる保険の満額と同額になった時点で「満期」になる。
【００５１】
多種多様なシステム関連の管理処理とは、エラーログのレビューや抽出ファイルの作成などの様々な管理作業を意味する。
【００５２】
２（ａ）保険料処理（図４）
２（ａ−ｉ）概要
図４は、模範的な一人の顧客に関して、図１のシステム１００を使用して保険料処理を実施する模範的な１つのルーチンを示したものである。一般的に、このプロセスには、例えば、メールサービスや電子伝送によって顧客に情報を送る初期ステップ４０２がある。特に、このステップには、（サブステップ４０４で）月払保険料請求普通（ＭＯＤ）クーポン帳を送ることが含まれる。通常、このクーポン帳には、一連の保険料払込期日のインターバル（例えば１年間のうちの数ヶ月間）で必要な払込みを明示した一連の明細書が含まれている。さらに、このステップには、（サブステップ４０８で）週払い保険料払込み（ＷＰ）保険契約の保険料払込み延滞通知を送ることが含まれる。さらに、このステップには、（サブステップ４１０で）新規請求口座の通知を送ることが含まれていてもよい。
【００５３】
ステップ４１２では、システム１００は、適切な払込期日に払込まれたかどうかを確認する。払込まれていない場合には、ステップ４１４で、システム１００から失効通知が送信される。ステップ４１６では、所定の日数（例えば、９０日）後に、システムは、保険契約を延長定期ステータスに転換する。逆に、払込まれていた場合には、（ステップ４１８で）システム１００は、その払込みを対応する保険契約口座に配賦する。そして、ステップ４２０では、システム１００は適切な払込後処理を行う。この処理には、（サブステップ４２２で）請求明細書としても働く払込受領承認証書を送ることと、（サブステップ４２４で）保険契約ステータスを更新することと、（サブステップ４２６で）必要に応じて払戻金を生成することが含まれていてもよい。
【００５４】
２（ａーｉｉ）保険料バッチ処理とレポート作成
（下の第３節の）テーブル２、３で示されるバッチプログラムとレポートのサブセットを利用して、上述の手続きで選択されたステップを実行することができる。例えば、ＤＢ＿ＰＡＹＩＭＥＮＴ＿ＰＫＧルーチンによって、金融機関（例えば銀行）から送られた払込み通知が処理される。特に、このルーチンによって、一致払込みと不一致払込みが検出される。（一致払込みとは、保険契約の複数の指定保険料に一致する、ドル立て金額の払込みを意味する。）また、このルーチンによって、一致した払込みのための払込みトランザクションと、不一致であった払込みのための「保留」トランザクションが適切に作成される。保留トランザクションとは、払込み金額が請求額と一致しないため払込みがどのように配賦されるのかに関する支払者の意図がまだわからないため、特定の保険契約または口座に対する払込を記録するが、払込を「配賦」しないトランザクションを意味する。保留トランザクションは、預金の希望する振り分けが決まった時にオンライン入力によって適用することができる。また、このルーチンによって、保険料払込リストが作成され、一致払込みに対して承認証書が作成され、さらに払込みによって保険契約ステータスが（ＰＡＩＤ＿ＵＰ＿ＤＡＴＥ変数によって得られる）「払込済日」にされた場合には適切な完了処理が実行される。（「払込済日」とは、払込まれた保険契約の条項に基づいて保険料の全ての払込みが契約上認められた暦日のことを言う。）
【００５５】
ＤＢ＿ＬＡＰＳＥ＿ＰＰＡＹルーチンによって、過去９０日のＰＡＩＤ＿Ｔｏ＿ＤＡＴＥフィールドの口座ステータスがアクティブの「Ａ」である保険料払込保険契約が明示される。そのような請求口座が検出されると、このルーチンによって、「ＰＰＡＹ」（保険料払込み）ステータスの保険契約に属する保険契約がまだ存在するかどうかが判定される。（保険契約が現在有効であるが保険料の払込みがまだ完了していないので有効であり続けるために保険料の払込みがさらに必要であることがＰＰＡＹステータスによって示される。）そのような場合には、この請求口座と保険契約は失効となる（即ち、延長定期ステータスに転換される）。
【００５６】
このシステムでは、払込みの承認証書や失効が次の暦月まで未決定になっている保険契約の通知や失効したＭＯＤ保険料払込み通知や失効した週払い保険料払込み通知や保険料未払込みのため失効した保険契約の通知や３１日間の保険料未払込みの保険契約の通知や保険料払込保険契約の貸付に対する返済最低利息通知やＷＰ延滞通知などの様々な保険料関連バッチレポートを作成することができる。
【００５７】
また、保険料請求システム２０２には、下記の第３節のテーブル５で明示されるように上述の処理に付随するオンラインレポートが多数用意されている。
【００５８】
２（ａーｉｉｉ）保険料処理と関連管理インタフェース画面
（下記の第３節の）テーブル４で明示される画面のサブセットは、上述の手続きで選択されたステップの実行を容易にしたり、保険契約に関する管理処理を行うために使用することができる。例えば、保険契約データ画面（図１１）では保険契約番号を入力すると保険契約の詳細が引き出せる。画面上の「ＵＰＤＡＴＥ　ＩＮＳＵＲＥＤ　ＮＡＭＥ」ボタンと「ＵＰＤＡＴＥ　ＢＥＮＥＦＩＣＩＡＲＹ　ＮＡＭＥ」ボタンを押すと、利用者は受取人と被保険者名をそれぞれ修正することができる。さらに、「ＲＥＳＴＯＲＥ　ＬＯＳＴ　ＰＯＬＩＣＹ」ボタンをクリックしてシステムに全く新しい保険契約を入力することができる。これによって、利用者は、古いシステム１１４でなぜか紛失されて新規システム１０２に転送されなかった保険契約情報を追加することができる。従って、現在このシステムを使用しているビジネスエンティティが新しい保険契約を今後販売しないかもしれないが、新しい保険契約を受け入れるために必要な機能を求めているビジネスエンティティが使用する場合にはシステム１０２自体にそのような機能が含まれている。
【００５９】
保険契約担保画面（図１２）では、保険契約番号を入力すると、利用者は保険契約の担保レコードの詳細を追加したり修正することができる。この画面で基本担保に加えて特約と給付が管理される。保険契約の「基本」担保とは、保険契約で特定された「主要な」人に対して提供される保険を意味する。保険契約に関する「給付」は、被保険者死亡時などのある特定の事柄が発生した時に、保険契約に従って契約上支払われる金銭を指す。上述したように、「特約」とは保険契約に基づく追加、即ち「副次的な」担保を指す。
【００６０】
保険契約ステータス画面（図１３）によって、様々な期日にわたる保険契約のステータス情報が検索される。さらに、利用者は既存の保険契約番号に照会し、保険契約に付随するステータス情報を検索することができる。加えて、「ＧＥＮＥＲＡＴＥ　ＲＥＦＵＮＤ」ボタンを押すことによって、該当する場合には、利用者は払込み済みの保険契約について保険料払戻金を生成することができる。「ＲＥＶＥＲＳＥ　ＲＥＦＵＮＤ」ボタンによって、利用者は払戻金の操作を取り消すことができる。一般に、何らかの理由によって払込みが多すぎた時に払戻金が利用される。
【００６１】
保険契約概要画面（図１４）では、有効な保険契約番号を入力すると保険契約概要の詳細が提供される。一実施形態では、この画面で利用者は画面に表示されたデータを修正することはできない。保険団体が雇用したアシスタント人員が、電話やその他の通信手段でアシスタント人員と連絡をとった保険契約者からの質問に答えるためにこの画面を使用することができる。
【００６２】
未転換保険契約画面（図１５）には、従来システム１１４で以前記憶されていたデータを表わした（即ちミラーした）情報が提示されており、この情報は現在ミラーシステム１１５で管理されている。従って、一実施形態では、この画面を使って変換時に従来システム１１４で管理されていた全ての情報を検索することができる。この特性によって、変換プロセスでデータを紛失する危険が削減される。
【００６３】
保険契約満期年画面（図１６）によって、利用者は保険契約の満期日に訂正を加えることができる。特に、この画面にはデータが従来システムで紛失されたために満期日が入力されていない（即ち指定されていない）保険契約が一覧表示される。利用者は「Ｍａｔｕｒｉｔｙ　Ｙｅａｒ」や「Ｐｏｌｉｃｙ　Ｂｅｇｉｎ」や「Ｐｏｌｉｃｙ　Ｅｎｄ」に照会可能である。利用者は、ユーザＩＤに照会し「Ｃｏｒｒｅｃｔｅｄ　Ｍａｔｕｒｉｔｙ　Ｄａｔｅｓ」チェックボックスをチェックして特定の利用者が訂正した満期日を見ることができる。この特性は、従来システム１１４で管理されたが破損したデータに訂正を加える新規システムの便利な機能の一例である。
【００６４】
保険料請求口座画面（図１７、１８）では、口座番号や口座ステータスやペイド・ツー・デイトや割引コードや保険契約種類（例えば、ＷＰやＭＤＯ）を入力すると請求口座の詳細が提示される。その画面で利用者は請求口座の保険契約を追加したり削除することができる。さらにこの画面で利用者は新しい請求口座を追加することができる。
【００６５】
請求口座／保険契約関連画面（図１９）には、保険料請求口座とその保険契約との関連情報が示されている。その画面で利用者は保険契約番号か請求口座番号かその双方のいずれかに照会することができる。さらにこの画面で利用者は特定の請求口座に関する保険契約を追加したり削除することができる。
【００６６】
請求口座トランザクション画面（図２０）では、利用者は有効な請求口座番号を入力することによって、保険料請求口座トランザクションの詳細情報を検索し、新しい払込みトランザクションを入力することができる。利用者が「受け取り額」を入力し「ＡＰＰＬＹ　ＰＡＹＭＥＮＴ」ボタンを押すと、払込まれた指定保険料の合計が計算され保険契約に関するペイド・ツー・デイトが調整され払込みに反映される。
【００６７】
保険契約指定保険料情報画面（図２１）では、指定された期日にわたる保険契約の指定保険料が検索される。その画面で利用者は、（担保の変更により保険料が変わった時）既存の保険契約番号に照会して新しい指定保険料を追加することができる。
【００６８】
保険料払戻金情報画面（図２２）によって、利用者は保険料払戻金を見たり生成することができる。操作中、この画面で利用者は保険契約番号に照会し、「ＧＥＮＥＲＡＴＥ　ＲＥＦＵＮＤ」ボタンと「ＲＥＶＥＲＳＥ　ＲＥＦＵＮＤ」ボタンをそれぞれ押して保険料払戻金を生成したり払戻金を取り消すことができる。
【００６９】
２（ｂ）貸付処理（図５）
２（ｂ−ｉ）概要
図５は、模範的な一人の顧客について図１のシステム１００を使用して貸付処理を実施する模範的な１つのルーチンを示したものである。概要として、このプロセスには顧客に見積書を提示して顧客の保険担保への申請を処理する初期ステップ５０２が含まれる。そしてこのプロセスは、ステップ５０４で例えばメールサービスや電子送信によって顧客に通知／明細書を送ることを伴う。特に、このステップにはサブステップ５０６で利息払込み請求明細書を送ることが含まれる場合もある。さらに、このステップには貸付残高の合計が保険契約額を上回った時に、（サブステップ５１０で）返済最低利息通知を送ることが含まれてもよい。
【００７０】
ステップ５１２では、システム１００によって該当する払込期日に払込まれたかどうかが判断される。ステップ５１４で、最低利息が払込まれる予定になっていて払込期日が過ぎても払込まれていない場合には、システム１００によってその保険契約は失効される。あるいは、払込まれていた場合、ステップ５１６でシステム１００によって払込みは元金あるいは利息として顧客の口座に自動もしくは手動で加えられる。そして、ステップ５１８でシステム１００によって該当する払込後処理が実施される。貸付が全部返済された場合には、このプロセスには（サブステップ５２０で）完済書を送信したり、必要な場合には（サブステップ５２２で）払戻金を生成したり、（利息が事前に請求されていたので）未経過利息を口座の貸方に記入したりすることが含まれることもある。
【００７１】
２（ｂ−ｉｉ）貸付バッチ処理とレポート作成
（以下の第３節の）テーブル２と３で明らかになるバッチプログラムとレポートのサブセットは、上述の手続きで選択されたステップを実行するために使用することができる。例えば、ＤＢ＿ＬＯＡＮ＿ＰＫＧプログラムによって銀行から送られてくる分割払込み通知が処理されたり、一致（払込みが返済利息と同額の）払込みと不一致払込みを表したものが該当するデータ記憶テーブルに挿入されたりする。特に、このルーチンによって、（１）保険料請求システムに関する保険料と貸付の払込みが記録された銀行用バッチファイルが並べ替えられたり、（２）バッチ情報が詳細レコードと結合されたり、（３）一致払込みと不一致払込みが検出されたり、（４）該当すれば払込み取扱レコードが作成され最低利息取扱レコード（ＭＩＮＩＮＴ）が更新されて払込みが記録されたり、（５）貸付利息払込み収集レポートが作成されたりする。不一致払込みは、利用者が望ましい預金の振り分けを決め画面インタフェースを介してその振り分けを適用させるまで記憶装置内で「保留」される。
【００７２】
ＤＢ＿ＮＰＡＹ＿ＭＩＮＩＮＴプログラムによって、返済最低利息のある保険契約が特定される。特に、このルーチンは、ＡＮＮＵＡＬ＿ＩＮＴＥＲＥＳＴ＿ＤＵＥＤＡＴＥフィールドが過去３０日以上経過した値であってトランザクション額の無いＭＩＮＩＮＴ保険契約貸付トランザクションを見つけだして、影響を受けた保険契約を失効させる（保険契約ステータスはＬＰＮＶＬに変わる、即ち、失効して価値がなくなる）。
【００７３】
また、保険料請求システム２０２は、下の第３節のテーブル５で示される上述の処理に関する多くのオンラインレポートを提供する。
【００７４】
２（ｂーｉｉｉ）貸付処理とそれに関する管理インタフェース画面
（以下の第３節の）テーブル４で明示される画面のサブセットは、上述の手続きで選択されたステップの実行を容易にしたり、貸付に関する管理処理を行うために利用可能である。例えば、貸付管理画面（図２４、図２５）では、有効な保険契約番号を入力すると、保険契約の貸付トランザクション情報が検索される。利用者は、（画面右下の）矢印ボタンを押すことによって、（払込期日や返済最低利息などの）貸付の詳細を見ることができる。さらに、利用者は、その画面上で、表示された保険契約のための新規貸付を追加することができる。さらに、この画面上で、利用者は「支払者名（Ｐａｙｏｒ　Ｎａｍｅ）」と「住所（Ａｄｄｒｅｓｓ）」を修正することができる。また、この特定の模範的なアプリケーションでは、利用者は（フロリダ法で必要とされる副請求書のための）フロリダでの契約者の氏名と住所を修正することもできる。
【００７５】
貸付見積画面（図２６）と貸付承認画面（図２７）によって、利用者は新規貸付を処理することができる。特に、その画面で、利用者は既存の保険契約番号に照会して貸付詳細を見ることができる。新規の貸付を処理するために、この画面で利用者は保険契約番号と貸付日と貸付額を入力するよう指示される。一実施形態では、貸付額は保険契約の解約返戻金（ＣＳＶ）より少なくなるはずであり、この画面に関する処理によって正しいかどうかが判断される。利用者が「Ｌｏａｎ　Ａｐｐｒｏｖａｌ」ボタンを押すと、システムは（ＣＳＶに基づいて）貸付を承認するか、もしくは、否認する。この画面は、「Ａｐｐｒｏｖａｌ　Ｉｎｄｉｃａｔｏｒ」フィールドに「Ｙ」か「Ｎ」の記号を配置することによってシステムが承認したか、否認したかを示す。
【００７６】
保険契約貸付画面（図２８）では、保険契約についての貸付の詳細情報が検索される。その画面で、利用者は貸付に適用可能な利率を修正することができる。
【００７７】
２（ｃ）保険料払込免除処理（図６）
２（ｃ−ｉ）概要
図６は、保険料払込免除処理を行うための模範的な１つのルーチンを示したものである。一般的に、この処理には保険契約を払込免除にする初期ステップ６０２が含まれる。上述したように、身体障害特約が保険契約にある場合には、例えば、保険契約者が身体障害であると、所定の期間保険料払込みが免除されるというこのアクションは適切である。本プロセスは、ステップ６０４で保険契約を払込免除ステータス（即ち、「ＷＡＩＶ」ステータス）に更新することを含む。ステップ６０６では、払込免除期間に払込まれた保険料を払い戻すことができる。本プロセスは、ステップ６０８で現在までの払込みに関する情報を定期的に更新することを含む。そして、本プロセスは、ステップ６１０で必要に応じて払込免除を終了することを含む。
【００７８】
２（ｃ−ｉｉ）保険料払込免除バッチ処理とレポート作成
（以下の第３節の）テーブル２、３で明らかになるバッチプログラムとレポートのサブセットは、上述の手続きで選択されたステップを実行するために利用可能である。例えば、ＤＢ＿ＷＡＩＶ＿ＰＴＤ＿ＵＰＤＡＴＥルーチンは、払込免除された保険契約のペイド・ツー・デイトを更新する。特に、このルーチンによって、ＰＡＩＤ＿ＴＯ＿ＤＡＴＥフィールドの更新が必要な（現在の保険契約ステータスが「ＷＡＩＹ」である）払込免除の保険契約が検出される。
【００７９】
その他の作成可能なバッチレポートには、払込免除の保険契約に関する貸付返済最低利息通知などが含まれる。
【００８０】
また、保険料請求システム２０２は、下記の第３節のテーブル５で示される、上述の処理に付随する多くのオンラインレポートを提供する。
【００８１】
２（ｃ−ｉｉｉ）保険料払込免除処理インタフェース画面
（以下の第３節の）テーブル４で示される画面のサブセットは、上述の手続きで選択されたステップの実行を容易にするために利用可能である。例えば、保険契約払戻金情報画面（図２３）によって、保険契約が払込免除ステータスの複数の期日と共に保険契約情報が検索される。利用者は、「Ｇｅｎｅｒａｔｅ　Ｒｅｆｕｎｄ」ボタンを押すことによって、払込免除期間に払込まれた保険料の払戻金を生成するようにシステムに指示することができる。それに応じて、システムは保険契約の払戻番号を作成する。利用者は、「ＲｅｖｅｒｓｅＲｅｆｕｎｄ」ボタンを押すことによって、（必要に応じて）払戻トランザクションの取消しを実行するようにシステムに指示することができる。さらに、利用者は「払込免除の終了（Ｔｅｒｍｉｎａｔｅ　Ｗａｉｖｅｒ）」ボタンを押すことによって、保険契約の払込免除ステータスを終了させることができる。また、利用者は、「終了の取消し（Ｒｅｖｅｒｓｅ　Ｔｅｒｍｉｎａｔｉｏｎ）」ボタンを押すことによって、そのような終了を取り消すことができる。
【００８２】
２（ｄ）解約返戻金処理（図７）
２（ｄ−ｉ）概要
図７は、模範的な一人の顧客に関して、図１のシステム１００を使用した解約返戻処理の模範的な１つのルーチンを示したものである。概観すると、この処理には解約返戻金（ＣＳＶ）見積書を顧客に提供する初期ステップ７０２が含まれる。顧客が自分の保険契約を「解約」することを選択した場合、ステップ７０４でシステム１００によって残存貸付額と利率簿に基づくＣＳＶを計算するなどの様々なＣＳＶ処理が実施される。ステップ７０６で、システム１００によって保険契約が「解約された」（即ち、現在「ＳＵＲＲ」ステータスである）ことを示すために保険契約ステータスが更新される。そして、ステップ７０８では、要求された（適宜）場合には、システム１００によって解約返戻金の取消しが行われる。
【００８３】
２（ｄ−ｉｉ）解約返戻金バッチ処理とレポート作成
（以下の第３節の）テーブル２、３に示されるバッチプログラムとレポートのサブセットは、上述の手続きで選択されたステップを実行するために使用可能である。例えば、ＤＢＣＡＬＣＣＳＶルーチンは、保険契約の解約返戻金（ＣＳＶ）を返納する。貸付利息請求書を作成して最低利息が払込まれる予定かどうかチェックし、それに応じて返済最低利息（ＭＩＮＩＮＴ）トランザクションを生成するために同様のＣＳＶ計算ルーチンがＤＢ＿ＬＯＡＮ＿ＢＩＬＬ１ＮＧ＿ＭＩＮＩＮＴルーチン内で使用される。このルーチンでは、該当するレコードを（ＣＳＶＲＡＴＥテーブルなどの）データ記憶装置１０９から取り込むことによって解約返戻金が計算される。そのルーチンの実行時にエラーが発生した場合は、本関数は値「−１」を返す。
【００８４】
また、保険料請求システム２０２は、以下の第３節のテーブル５で示される、上述の処理に付随する多くのオンラインレポートを提供する。
【００８５】
２（ｄ−ｉｉｉ）解約返戻処理インタフェース画面
（以下の第３節の）テーブル４で示される画面のサブセットは、上述の手続きで選択されたステップの実行を容易にするために利用可能である。例えば、解約返戻金見積画面（図２９）によって、利用者は、有効な保険契約番号について照会して、対応する保険契約の解約返戻金（ＣＳＶ）の詳細情報を検索することができる。一実施形態の画面では、利用者は画面上のどのフィールドも修正することはできない。
【００８６】
解約返戻処理画面（図３０）によって、利用者は、特定の保険契約の解約返戻金トランザクションを生成したり取り消すことができる。その画面では、利用者は既存の保険契約番号について照会することができる。「Ｃａｓｈ　Ｓｕｒｒｅｎｄｅｒ」ボタンを押すことによって、システムは特定の保険契約のＣＳＶ額を計算したり、保険契約に対する解約トランザクションを生成したり、保険契約のステータスを「ＳＵＲＲ」に変更する。利用者は「Ｒｅｖｅｒｓｅ」ボタンを押すことによって、解約された保険契約を取り消すことができる。
【００８７】
ＣＳＶレート画面（図３１）では、解約返戻金レートテーブルを検索して表示する。本システムでは、このＣＳＶレートテーブルを利用して保険契約のＣＳＶ額を計算する。一実施形態での画面では、利用者は利率簿を追加、修正することはできない。
【００８８】
プランコード画面（図３２）では、データ記憶装置１０９からプランコードと対応するプラン内容を検索する。この画面で、利用者はプランコードを追加、修正することができる。
【００８９】
保険契約ＣＳＶトランザクション画面（図３３）では、保険契約のＣＳＶトランザクションレコードが検索される。この画面で、利用者は新しいＣＳＶトランザクションを追加したり、既存のＣＳＶトランザクションを修正することができる。
【００９０】
２（ｅ）延長効力処理（図８）
２（ｅ−ｉ）概要
図８は、延長効力処理を行うための模範的な一ルーチンを示す。概観すると、本プロセスには保険契約の失効を自動または手動で登録する初期ステップ８０２が含まれている。ステップ８０４では、システム１００は、残存貸付金と利率簿に基づいて保険契約の解約返戻金（ＣＳＶ）を計算する。ステップ８０６では、システム１００は延長効力処理が行われたことを示すために保険契約ステータスを更新する。ステップ８０８では、システム１００は必要に応じて（適宜）、失効を取り消して延長定期にする（保険契約が保険料払込みステータスに戻される）。
【００９１】
２（ｅ−ｉｉ）延長効力関連インタフェース画面
（下記の第３節の）テーブル４に示される画面のサブセットは、上述の手続きで選択されたステップの実行を容易にするために利用可能である。例えば、延長効力主画面（図３４）では、利用者は保険契約ステータスを延長定期保険（ＥＴＩ）ステータスか減額払済（ＲＰＵ）ステータスに修正することができる。利用者は、操作中に有効な保険契約番号を入力することによって保険契約情報を呼び出す。本システムは、ＣＳＶ額と、その額から利用可能な延長定期担保と、減額払済担保の年数を計算する。そして、本システムは、この情報をデータ記憶装置１０９内の適切なテーブルに追加し、定期延長保険オプションかあるいは減額払済オプションが選択されたかによって保険契約のステータスをＥＴＩかあるいはＲＰＵにそれぞれ変更する。
【００９２】
延長定期保険画面（図３５）では、利用者がＬＰＮＶＬタイプかＥＴＩタイプの有効な保険契約番号を入力すると、延長定期保険ステータスの保険契約の詳細情報が検索される。その画面では、利用者は「Ｒｅｖｅｒｓｅ」ボタンを押すことによってステータスを以前のステータスに戻すことができる。
【００９３】
減額払済画面（図３６）では、ＲＰＵステータスの有効な保険契約番号が入力されると、ＲＰＵステータスの保険契約の詳細情報が検索される。一実施形態の画面では、「Ｒｅｖｅｒｓｅ」ボタンを押すことによって保険契約の以前のステータスに戻すことができる。
【００９４】
拡大レート画面（図３７）では、保険契約をＥＴＩステータスに変換する際に利用される拡大レート因子テーブルが検索される。一実施形態では、その画面では、利用者は利率簿を追加、修正することはできない。
【００９５】
２（ｆ）死亡請求処理（図９）
２（ｆ−ｉ）概要
図９は、模範的な一人の顧客に関して、図１のシステム１００を利用して死亡請求処理を実施する模範的な１つのルーチンを示したものである。概観すると、本プロセスには、外部システムから保険契約情報のリクエストを受け取る初期ステップ９０２が含まれている。このリクエストに応じて、ステップ９０４では、システム１００が、保険契約ステータスを提出済死亡請求（即ち、「ＤＴＨＦ」）に更新される。ステップ９０６では、本システムは、リクエストされた保険契約情報を死亡請求システムに送る。
【００９６】
死亡請求処理のその他の一態様では、（ステップ９０８で）死亡請求が支払われたかあるいは取り止めたことを示すデータを受け取る初期ステップが含まれる。本システムは、ステップ９１０で死亡請求が支払われた（「ＤＴＨＰ」になった）ことを示すために保険契約ステータスを更新する。死亡請求が取り止められた場合は、本システム１００は、取止め前の保険契約ステータスに戻す。
【００９７】
２（ｆ−ｉｉ）死亡請求バッチ処理とレポート作成
（以下の第３節の）テーブル２、３で示されるバッチプログラムとレポートのサブセットは、上述の手続きで選択されたステップを実行するために利用可能である。例えば、ＤＢ＿ＤＣ＿ＩＮＴＥＲＦＡＣＥ＿ＰＲＣルーチンは、死亡請求システム２１２とやりとりを行う。特に、死亡請求が出された時に、死亡請求システム２１２はファイルを作成する。保険料請求システム２０２は、死亡請求システム２１２からの情報ファイルに対するリクエストがあるかどうかを毎日チェックする。リクエストがあれば、ＤＢ＿ＤＣ＿ＩＮＴＥＲＦＡＣＥ＿ＰＲＣルーチンは、ファイルを読み出して、リクエストファイル内の特定の死亡請求に関する保険契約の保険契約／受取人情報の入った返送ファイルを作成する。特に、保険料請求システム２０２は、リクエストファイルのレコード毎に死亡請求システム２１２が何の情報をリクエストしたかを特定して、その情報を入手する。例えば、死亡請求が出されたことが死亡請求システムのファイルによって示された場合は、保険料請求システム２０２は、既存の保険契約ステータスを「ＤＴＨＦ」ステータスに変更するためのＤＢ＿ＤＣＩＮＴ＿ＣＬＡＩＭ＿ＳＥＴＵＰＰＲＣルーチンを呼び出す。死亡請求に対する支払いが行われたことが死亡請求システムのファイルによって示された場合に、保険料請求システム２０２は、保険契約ステータスを「ＤＴＨＦ」から「ＤＴＨＰ」に変更するためのＤＢ＿ＤＣＩＮＴ＿ＣＬＡＩＭ＿ＳＥＴＴＬＥＰＲＣルーチンを呼び出す。死亡請求が取り消されたことが死亡請求システムのファイルによって示された場合は、保険料請求システム２０２は、「ＤＴＨＦ」ステータスを削除して以前の保険契約ステータスに戻すためのＤＢ＿ＤＣ＿ＩＮＴ＿ＣＬＡＩＭＣＡＮＣＢＬ＿ＰＲＣルーチンを呼び出す。ＤＢＤＣＩＮＴＥＲＦＡＣＥ＿ＷＲＩＴＥＰＲＣルーチンは、死亡請求システム２１２がリクエストした保険契約と受取人の情報を作成する。特定の保険契約が保険料請求システム２０２内で見つからない場合にはＤＢ＿ＤＣ＿ＩＮＴ＿ＲＥＱＮＦＰＲＣルーチンは、死亡請求システムへのリクエストを処理する。
【００９８】
また、以下の第３節のテーブル５で示されるように、保険料請求システム２０２は、上述の処理に付随する多くのオンラインレポートを提供する。
【００９９】
２（ｇ）満期処理（図１０）
２（ｇ−ｉ）概要
図１０は、模範的な一人の顧客に関して、図１のシステム１００を利用した満期関連処理の模範的な一ルーチンを示したものである。概観すると、本プロセスには、翌月に満期になる保険契約に関する保険契約情報を毎月末に外部の満期養老システム２１４へ送るステップ１００２が含まれている。そして、ステップ１００４では、本システムは、保険契約ステータスを「ＭＡＴＦ」（申告満期）に更新する。
【０１００】
図１０の満期処理の別の態様によれば、（ステップ１００６に）満期養老システム２１４から満期請求が支払われたという情報を受け取る初期ステップが含まれている。そして、ステップ１００８では、本システムは、保険契約ステータスを「ＭＡＴＰ」（払込満期ステータス）に更新する。
【０１０１】
２（ｇ−ｉｉ）満期バッチ処理とレポート作成
（以下の第３節の）テーブル２、３で示されるバッチプログラムとレポートのサブセットは、上述の手続きで選択されたステップを実行するために利用可能である。例えば、ＤＢ＿ＤＣ＿ＭＥ＿ＲＥＳＰ＿ＲＥＡＤ＿ＰＲＣルーチンは、満期養老システム２１４によって作成されたインタフェースファイル「ＤＣ＿ＭＥ＿ＬＡＰＳＥＳ．ＴＸＴ」を読み出し、満期ステータスと死亡請求ステータスとなった保険契約の保険契約ステータスを更新する。特に、本ルーチンは、「ＤＣ＿ＭＥ＿ＬＡＰＳＥＳ．ＴＸＴ」で特定された保険契約の「ＭＡＴＦ」ステータスを完了にする「ＤＢＤＣ＿ＭＥ＿ＲＥＳＰ＿ＵＰＤ＿ＰＲＣ」ルーチンを呼び出す。即ち、本ルーチンは、ＰＯＬＩＣＹ＿ＳＴＡＴＵＳテーブルの「ＭＡＴＦ」（申告満期）ステータスを「ＭＡＴＰ」（払込満期）ステータスに変更する。
【０１０２】
ＤＢ＿ＬＩＥＭＡＥＸＰＲ＿ＰＲＣプログラムは、満期もしくは満了になる保険契約を特定し、この事象を反映させるためにデータ記憶装置１０９内の適切なテーブルのステータスを変更する。特に、本ルーチンは、毎月末にデータ記憶を確認して、約３０日で満期もしくは満了となる保険契約を確認する。
【０１０３】
その他の作成可能なバッチレポートには、次の暦月に満期になる予定の有効な保険契約や、次の暦月に満了もしくは満期になる予定の延長定期保険契約または減額払済保険契約や、満期になる予定の払込免除の保険契約などを示すレポートが含まれている。
【０１０４】
また、保険料請求システム２０２は、以下の第３節のテーブル５で示されるように、上述の処理に付随する多くのオンラインレポートを提供する。
【０１０５】
２（ｈ）多種多様な管理処理
２（ｈ−ｉ）概要
システム１００には、システム１００に対する管理を扱うその他のルーチンが含まれている。そのようなルーチンによって、利用者はシステムパラメータを変更したりエラーログ情報を見たりすることができる。
【０１０６】
２（ｈ−ｉｉ）多種多様な管理バッチ処理とレポート作成
（下記の第３節の）テーブル２、３で示されるバッチプログラムとレポートのサブセットは、システム関連の管理を行うために利用可能である。例えば、ＤＢ＿ＥＲＲＯＲＳ＿ＬＯＧ＿ＰＲＣルーチンは、保険料請求システムのルーチンを実行する過程で発生したエラーを記録する。特に、本ルーチンは、プログラムＩＤやエラー回線やＯｒａｃｌｅエラー番号やＯｒａｃｌｅエラーメッセージなどの詳細情報がＤＢ＿ＥＲＲＯＲＳテーブルに記録する。
【０１０７】
ＤＢ＿ＧＥＮ＿ＡＣＣ＿ＥＸＴＲＡＣＴルーチンは、貸付のある保険契約が失効になった場合に、保険料請求形式が「ＷＰ」と「ＭＤＯ」の会計抽出ファイル「ＥＸＴＲＡＣＴ．ＴＸＴ」を作成する。特に、本ルーチンは、データ記憶装置１０９の適切なテーブルからレコードを取り出して、抽出ファイル「ＥＸＴＲＡＣＴ．ＴＸＴ」を作成する。
【０１０８】
ＤＢＪＮＶＡＬＩＤ＿ＢＩＬＬ＿ＡＣＣ＿ＰＲＣルーチンは、口座が無効な場合にはＡＣＣＯＵＮＴ＿ＳＴＡＴＵＳを「Ｉ」にセットする。特に、本ルーチンは、ＡＣＣＯＵＮＴ＿ＳＴＡＴＵＳが「Ａ」（アクティブ）である、データ記憶装置１０９内の請求口座テーブルの全てのレコードを調べる。次いで、本ルーチンは、無効の口座を見つける。
【０１０９】
ＤＢ＿ＭＯＮＴＬＹＣＯＵＮＴＳルーチンは、データ記憶装置１０９に記憶されたテーブルの様々な勘定と総計を管理する。一実施形態では、本テーブルからのデータによって、インターネットのウェブサイトに統計情報を表示することができる。特に、入力日を基準にした翌月の最初の日が算定され、その翌月の最初の日に勘定と総計が計算される。計算される勘定には、（１）保険料請求形式がＭＯＤとＷＰの保険料払込生命保険契約件数と、（２）保険料請求形式がＭＯＤとＷＰの保険料払込健康保険契約件数と、（３）保険料請求形式がＭＯＤとＷＰで払込免除ステータスの生命保険契約件数と、（４）保険料請求形式がＭＯＤとＷＰのＹＴＤ（過去１年間）の保険料払込額と、（５）保険料請求形式がＭＯＤとＷＰの延長定期保険（ＥＴＩ）タイプの保険契約件数と、（６）保険料請求形式がＭＯＤとＷＰの減額払済（ＲＰＵ）タイプの保険契約件数と、（７）保険料請求形式がＭＯＤとＷＰの解約保険契約のＹＴＤ件数と、（８）保険料請求形式がＭＯＤとＷＰの死亡請求処理（ＤＴＨＰ）保険契約のＹＴＤ件数と、（９）保険料請求形式がＭＯＤとＷＰの満期養老処理（ＭＡＴＰ）された保険契約のＹＴＤ件数と、（１０）保険料請求形式がＭＯＤとＷＰの失効生命保険契約のＹＴＤ件数と、（１１）保険料請求形式がＭＯＤとＷＰの払済保険契約の件数と、（１２）保険料請求形式がＭＯＤとＷＰの保険料払込生命保険契約の年間総保険料と、（１３）保険料請求形式がＭＯＤとＷＰの健康保険契約の年間総保険料が含まれる。
【０１１０】
また、保険料請求システム２０２は、以下の第３節のテーブル５で示されるように、上述の処理に付随する多くのオンラインレポートを提供する。
【０１１１】
２（ｈ−ｉｉｉ）多種多様な管理処理インタフェース画面
（以下の第３節の）テーブル４で示される画面のサブセットは、上述の手続きで選択されたステップの実行を促進するために利用可能である。例えば、アクセス機能入力（）画面（図３８）では、管理者はインタフェース画面へのアクセスを制限することができる。特に、この画面によって、現在この画面に適用可能な機能と特権のリストが取り出される。その画面で、利用者はその画面に対するアクセス機能やアクセス特権を追加したり修正したり削除することができる。
【０１１２】
エラーメッセージ入力画面（図３９）では、保険料請求システムの画面で作成されたエラーメッセージが（関連するエラーの種類とエラー番号と共に）検索されて表示される。
【０１１３】
レポート記述画面（図４０）では、有効なレポートＩＤと関連するレポート名が検索されて表示され、（レポートがオンラインかバッチかを指定する）モードで実行する。その画面で、利用者はレポートを追加したり修正したり削除することができる。
【０１１４】
フォーム記述画面（図４１）では、データ記憶装置１０９から保険料請求システムで有効な画面ＩＤや画面名が全て検索される。その画面で、利用者は画面ＩＤや画面名の情報を追加したり修正したり削除することができる。
【０１１５】
保険統計抽出画面（図４２）によって、利用者は組織内の保険数理士が利用する保険統計抽出ファイルを作成することができる。利用者は操作中に出力される抽出ファイルを置く希望場所と日付を入力する。そして、利用者は、「Ｇｅｎｅｒａｔｅ　Ｅｘｔｒａｃｔｓ」ボタンを押して保険統計抽出ファイルを作成する。
【０１１６】
エラーログ画面（図４３）では、（ＤＢ＿ＥＲＲＯＲＳテーブルにある）バッチプログラムの実行中に発生したエラーの詳細情報が検索される。その画面で、利用者はバッチの「Ｐｒｏｇｒａｍ　ｎａｍｅ」や「Ｒｕｎ　ｂｙ」や「Ｒｕｎ　ｄａｔｅ」フィールドについて照会して、エラーメッセージを検索することができる。
【０１１７】
３．模範的な実施形態の詳細テーブル
図１１から図４３と以下のテーブルによって、本発明の模範的な一実施形態の詳細が明かにされる。つまり、テーブル１には、図２の保険処理システム１０２のデータ記憶装置１０９にデータを記憶させるために使用可能な模範的なデータテーブルが記載されている。テーブル２には、保険プログラムを管理する際に使用される模範的なバッチプログラムが示されている。テーブル３には、図１のシステムによって作成される模範的なバッチレポートが示されている。図１１から図４３とテーブル４では、図１のシステム１００とやりとりするための模範的な複数の画面が示されている。そして、テーブル５には、図１のシステム１００によって作成される模範的なオンラインレポートが記載されている。
【０１１８】
【表１】
2004510224.tif 000003
【０１１９】
2004510224.tif 000004
【０１２０】
2004510224.tif 000005
【０１２１】
2004510224.tif 000006
【０１２２】
2004510224.tif 000007
【０１２３】
2004510224.tif 000008
【０１２４】
【表２】
2004510224.tif 000009
【０１２５】
2004510224.tif 000010
【０１２６】
2004510224.tif 000011
【０１２７】
2004510224.tif 000012
【０１２８】
2004510224.tif 000013
【０１２９】
2004510224.tif 000014
【０１３０】
2004510224.tif 000015
【０１３１】
2004510224.tif 000016
【０１３２】
2004510224.tif 000017
【０１３３】
【表３】
2004510224.tif 000018
【０１３４】
2004510224.tif 000019
【０１３５】
2004510224.tif 000020
【０１３６】
2004510224.tif 000021
【０１３７】
2004510224.tif 000022
【０１３８】
2004510224.tif 000023
【０１３９】
2004510224.tif 000024
【０１４０】
2004510224.tif 000025
【０１４１】
2004510224.tif 000026
【０１４２】
【表４】
2004510224.tif 000027
【０１４３】
2004510224.tif 000028
【０１４４】
2004510224.tif 000029
【０１４５】
2004510224.tif 000030
【０１４６】
2004510224.tif 000031
【０１４７】
【表５】
2004510224.tif 000032
【０１４８】
2004510224.tif 000033
【０１４９】
2004510224.tif 000034
【０１５０】
2004510224.tif 000035
【０１５１】
2004510224.tif 000036
【０１５２】
2004510224.tif 000037
【０１５３】
2004510224.tif 000038
【０１５４】
2004510224.tif 000039
【０１５５】
2004510224.tif 000040
【０１５６】
2004510224.tif 000041
【０１５７】
【表６】
2004510224.tif 000042
【０１５８】
2004510224.tif 000043
【０１５９】
2004510224.tif 000044
【０１６０】
2004510224.tif 000045
【０１６１】
本発明の精神や範囲から逸脱することなく、冒頭の特許請求の範囲と法律上それに等価するものを包含するその他の修正や変更を上述の複数の実施形態に加えることが可能である。
【図面の簡単な説明】
【図１】
図１は、本発明を実現する模範的なシステムを示す。
【図２】
図２は、図１のシステムで利用するための模範的な保険処理システムを示す。
【図３】
図３は、図１のシステムで利用するための模範的な１台のワークステーションを示す。
【図４】
図４は、本発明の模範的な保険料処理ルーチンを示す。
【図５】
図５は、本発明の模範的な貸付処理ルーチンを示す。
【図６】
図６は、本発明の模範的な保険料払込免除処理ルーチンを示す。
【図７】
図７は、本発明の模範的な解約返戻処理ルーチンを示す。
【図８】
図８は、本発明の模範的な延長効力処理ルーチンを示す。
【図９】
図９は、本発明の模範的な死亡請求処理ルーチンを示す。
【図１０】
図１０は、本発明の模範的な満期処理ルーチンを示す。
【図１１】基本保険契約を管理する際の模範的な画面を示す。
【図１２】基本保険契約を管理する際の模範的な画面を示す。
【図１３】基本保険契約を管理する際の模範的な画面を示す。
【図１４】基本保険契約を管理する際の模範的な画面を示す。
【図１５】基本保険契約を管理する際の模範的な画面を示す。
【図１６】基本保険契約を管理する際の模範的な画面を示す。
【図１７】保険料の請求／払込処理を行う際の模範的な画面を示す。
【図１８】保険料の請求／払込処理を行う際の模範的な画面を示す。
【図１９】保険料の請求／払込処理を行う際の模範的な画面を示す。
【図２０】保険料の請求／払込処理を行う際の模範的な画面を示す。
【図２１】保険料の請求／払込処理を行う際の模範的な画面を示す。
【図２２】保険料の請求／払込処理を行う際の模範的な画面を示す。
【図２３】図２３は、保険料払込免除処理を行うための模範的な一画面を示す。
【図２４】貸付け処理を行うための模範的な画面を示す。
【図２５】貸付け処理を行うための模範的な画面を示す。
【図２６】貸付け処理を行うための模範的な画面を示す。
【図２７】貸付け処理を行うための模範的な画面を示す。
【図２８】貸付け処理を行うための模範的な画面を示す。
【図２９】解約返戻金（ＣＳＶ）処理を行うための模範的な画面を示す。
【図３０】解約返戻金（ＣＳＶ）処理を行うための模範的な画面を示す。
【図３１】解約返戻金（ＣＳＶ）処理を行うための模範的な画面を示す。
【図３２】解約返戻金（ＣＳＶ）処理を行うための模範的な画面を示す。
【図３３】解約返戻金（ＣＳＶ）処理を行うための模範的な画面を示す。
【図３４】延長定期保険処理を行うための模範的な画面を示す。
【図３５】延長定期保険処理を行うための模範的な画面を示す。
【図３６】延長定期保険処理を行うための模範的な画面を示す。
【図３７】システムパラメータを表示し修正するための模範的な画面を示す。
【図３８】システムパラメータを表示し修正するための模範的な画面を示す。
【図３９】システムパラメータを表示し修正するための模範的な画面を示す。
【図４０】システムパラメータを表示し修正するための模範的な画面を示す。
【図４１】システムパラメータを表示し修正するための模範的な画面を示す。
【図４２】
図４２は、保険統計の抽出ファイルを作成するための模範的な一画面を示す。
【図４３】
図４３は、エラーログを調べるための模範的な一画面を示す。
【図１】
2004510224.tif 000046
【図２】
2004510224.tif 000047
【図３】
2004510224.tif 000048
【図４】
2004510224.tif 000049
【図５】
2004510224.tif 000050
【図６】
2004510224.tif 000051
【図７】
2004510224.tif 000052
【図８】
2004510224.tif 000053
【図９】
2004510224.tif 000054
【図１０】
2004510224.tif 000055
【図１１】
2004510224.tif 000056
【図１２】
2004510224.tif 000057
【図１３】
2004510224.tif 000058
【図１４】
2004510224.tif 000059
【図１５】
2004510224.tif 000060
【図１６】
2004510224.tif 000061
【図１７】
2004510224.tif 000062
【図１８】
2004510224.tif 000063
【図１９】
2004510224.tif 000064
【図２０】
2004510224.tif 000065
【図２１】
2004510224.tif 000066
【図２２】
2004510224.tif 000067
【図２３】
2004510224.tif 000068
【図２４】
2004510224.tif 000069
【図２５】
2004510224.tif 000070
【図２６】
2004510224.tif 000071
【図２７】
2004510224.tif 000072
【図２８】
2004510224.tif 000073
【図２９】
2004510224.tif 000074
【図３０】
2004510224.tif 000075
【図３１】
2004510224.tif 000076
【図３２】
2004510224.tif 000077
【図３３】
2004510224.tif 000078
【図３４】
2004510224.tif 000079
【図３５】
2004510224.tif 000080
【図３６】
2004510224.tif 000081
【図３７】
2004510224.tif 000082
【図３８】
2004510224.tif 000083
【図３９】
2004510224.tif 000084
【図４０】
2004510224.tif 000085
【図４１】
2004510224.tif 000086
【図４２】
2004510224.tif 000087
【図４３】
2004510224.tif 000088
【国際公開パンフレット】
2004510224.tif 000089
2004510224.tif 000090
2004510224.tif 000091
2004510224.tif 000092
2004510224.tif 000093
2004510224.tif 000094
2004510224.tif 000095
2004510224.tif 000096
2004510224.tif 000097
2004510224.tif 000098
2004510224.tif 000099
2004510224.tif 000100
2004510224.tif 000101
2004510224.tif 000102
2004510224.tif 000103
2004510224.tif 000104
2004510224.tif 000105
2004510224.tif 000106
2004510224.tif 000107
2004510224.tif 000108
2004510224.tif 000109
2004510224.tif 000110
2004510224.tif 000111
2004510224.tif 000112
2004510224.tif 000113
2004510224.tif 000114
2004510224.tif 000115
2004510224.tif 000116
2004510224.tif 000117
2004510224.tif 000118
2004510224.tif 000119
2004510224.tif 000120
2004510224.tif 000121
2004510224.tif 000122
2004510224.tif 000123
2004510224.tif 000124
2004510224.tif 000125
2004510224.tif 000126
2004510224.tif 000127
2004510224.tif 000128
2004510224.tif 000129
2004510224.tif 000130
2004510224.tif 000131
2004510224.tif 000132
2004510224.tif 000133
2004510224.tif 000134
2004510224.tif 000135
2004510224.tif 000136
2004510224.tif 000137
2004510224.tif 000138
2004510224.tif 000139
2004510224.tif 000140
2004510224.tif 000141
2004510224.tif 000142
2004510224.tif 000143
2004510224.tif 000144
2004510224.tif 000145
2004510224.tif 000146
2004510224.tif 000147
2004510224.tif 000148
2004510224.tif 000149
2004510224.tif 000150
2004510224.tif 000151
2004510224.tif 000152
2004510224.tif 000153
2004510224.tif 000154
2004510224.tif 000155
2004510224.tif 000156
2004510224.tif 000157
2004510224.tif 000158
2004510224.tif 000159
2004510224.tif 000160
2004510224.tif 000161
2004510224.tif 000162
2004510224.tif 000163
2004510224.tif 000164
2004510224.tif 000165
2004510224.tif 000166
2004510224.tif 000167
2004510224.tif 000168
2004510224.tif 000169
2004510224.tif 000170
2004510224.tif 000171
2004510224.tif 000172
2004510224.tif 000173
2004510224.tif 000174
2004510224.tif 000175
2004510224.tif 000176
2004510224.tif 000177
2004510224.tif 000178
2004510224.tif 000179
2004510224.tif 000180
2004510224.tif 000181
2004510224.tif 000182
2004510224.tif 000183
2004510224.tif 000184
2004510224.tif 000185
2004510224.tif 000186
2004510224.tif 000187
2004510224.tif 000188
2004510224.tif 000189
2004510224.tif 000190
2004510224.tif 000191
2004510224.tif 000192
2004510224.tif 000193
2004510224.tif 000194
2004510224.tif 000195
2004510224.tif 000196
2004510224.tif 000197
2004510224.tif 000198
2004510224.tif 000199
2004510224.tif 000200
2004510224.tif 000201
2004510224.tif 000202
2004510224.tif 000203
【国際調査報告】
2004510224.tif 000204