JP4313207B2 - 保険料の入金管理に関する情報処理方法、保険契約管理に関する情報処理方法及びコンピュータ・システム - Google Patents

Description

【技術分野】
本発明は、保険料の集金及び保険契約管理に関連する情報処理技術に関する。
【背景技術】
従来、保険会社は、代理店や媒介人等（以下、代理店という）を介して保険加入の申し込みを受け付け、保険料についても代理店を介して集金していた。しかし、このような保険料集金の仕組みによると、さまざまな問題が発生していた。例えば、保険契約者から集金された保険料は、一旦代理店が管理している銀行口座等に蓄積されるため、保険会社による管理が徹底し得ないという問題があった。また、代理店が管理している銀行口座等について法定帳簿を備えなければならず、さらに代理店及び保険会社両方で保険料集金・入金の確認を行う必要がある等、非効率性の問題も生じていた。しかし、代理店が受け付けた保険契約の保険料を保険会社が自ら集金していると、コストが割高になるという現実も存在する。また、事故発生時に保険金を支払う上では、例えば保険始期日までに保険料を集金するなど、保険会社として債権管理上何らかの手当てが求められている。
なお、例えば特開２００２−８３１３７号公報は、代理店から保険会社に各保険契約につき保険料から代理店手数料を差し引いた精算額を様々な方法にて送金する際の処理方法を開示している。しかし、保険料の集金代行については考慮されておらず、また保険金の支払可否についても当該保険料の集金代行と関連して考慮されてはいない。
【特許文献１】
特開２００２−８３１３７号公報
【発明の開示】
【発明が解決しようとする課題】
このように保険料集金業務を低コストで代理店から分離する必要が生じている。このためには、保険料の集金代行会社を用いることが好ましい。一方、必ずしも全ての顧客に対して、集金代行会社に保険料の支払いを依頼することも困難である。
よって本発明の目的は、保険料の集金代行サービスを実施するために必要な情報処理技術を提供することである。
また本発明の他の目的は、代理店が現金で保険料を領収した場合であっても、保険料の集金代行サービスをスムーズに実施するために必要な情報処理技術を提供することである。
【課題を解決するための手段】
本発明の第１の態様に係る、保険契約の入金管理に関する情報処理方法は、保険料の入金データを除く保険契約に関するデータを取得し、記憶装置に登録するステップと、保険契約に関するデータに基づき保険料の支払期日を決定し、記憶装置に登録する期日決定ステップと、保険料の集金を行った者から取得した、保険料の入金データを保険契約についてのデータに対応付け、少なくとも入金日のデータを記憶装置に登録するステップと、入金日又は未入金状態と少なくとも支払期日の関係から、保険金支払可否に関する情報を保険契約毎に生成し、記憶装置に登録する保険金支払可否決定ステップとを含む。
このように、集金代行会社から入金情報を入手し、その情報に基づいて保険会社が保険金支払可否についての情報を生成したり、集金代行会社において保険金支払可否についての情報を生成しておけば、保険会社は保険料の入金についての管理から開放され、さらに実際に事故などが発生した場合に保険金を支払っても良いのか否かという情報も得ることができ、業務が効率化される。集金代行会社は、保険会社から保険料集金代行手数料及び本情報処理によるサービスの対価を得ることができる。
また、上で述べた期日決定ステップにおいて、保険契約に関するデータに基づき保険料未入金の場合の自動契約解除日を決定して記憶装置に登録し、自動契約解除日以前の日付が入金日として登録されていない保険契約を抽出するステップをさらに含むようにしてもよい。
さらに、本発明の第１の態様においては、事故日の情報を含む事故受付データを取得するステップと、事故日と保険契約に関するデータに含まれる保険始期日と保険契約の計上日との任意の組み合わせに係る少なくともいずれかの関係が所定の条件を満たす保険契約を抽出するステップとをさらに含むようにしてもよい。例えば、事故日が計上日より前であったり、計上日が保険始期日より後であったりする場合には、不正が行われている可能性もあり、具体的な調査を行う必要がある。このような処理についても入金についてのデータを保持している集金代行会社から入金についてのデータを保険会社が取得した上で実施したり、集金代行会社側で実施することが可能となる。
なお、上で述べた保険金支払可否決定ステップにおいて、入金日又は未入金状態と支払期日と自動契約解除日との関係から、支払期日までの保険金支払可否と支払期日から自動契約解除日までの保険金支払可否を決定するようにしてもよい。例えば、支払期日までに入金されていなければ支払期日までに事故が起こっても保険料は支払われない。支払期日後自動契約解除日までに事故があった場合には例えば自動契約解除日までに入金がなされるまで保険金の支払いは保留扱いになる。自動契約解除日までに入金がなされた場合には保険金支払は可と判断される。
本発明の第２の態様に係る、保険契約管理に関する情報処理方法は、保険料の入金データを除き保険始期日の情報を含む、保険契約に関するデータを取得し、保険契約データ格納部に登録するステップと、保険料の集金を行った者から取得した、保険料の入金データを保険契約についてのデータに対応付け、少なくとも入金日のデータを保険契約データ格納部に登録するステップと、保険始期日に基づき設定される所定の日までに未入金である未入金保険契約を抽出し、当該未入金保険契約を特定する情報を保険料債権の譲渡に係る保険契約として記憶装置に格納するステップとを含む。
本発明の第１の態様では、保険会社は集金代行会社に保険料の集金を委託している形であるが、本発明の第２の態様においては、保険始期日に基づき設定される日までに入金されていない場合には、集金代行会社が保険会社から保険料債権を譲り受けるようにする。このようにすれば、保険会社は個々の保険契約について入金管理を行わず、単純に保険始期日より責任期間が開始するものと取り扱うことができる。集金代行会社は、保険料債権を譲り受け、直接保険契約者から保険料の回収を行い、保険料と債権価格の差を自己の収益とすることができる。
また、本発明の第２の態様において、保険契約データに基づき保険料の支払期日を決定し、保険契約データ格納部に登録するステップと、保険料の支払期日以前の日付が入金日として登録されていない第２未入金保険契約を抽出し、当該第２未入金保険契約を特定する情報を督促に係る保険契約として記憶装置に格納するステップとをさらに含むようにしてもよい。保険料債権を譲り受けた場合には、集金代行会社は自らの責任において保険料を回収する必要があるので、支払期日を設定すると共に当該支払期日までに入金されない保険契約を特定し、当該保険契約者に対して保険料の支払いを督促するためである。
また、本発明の第２の態様において、保険料債権の譲渡に係る保険契約に対応して、要回収金額のデータを記憶装置に格納するステップをさらに含むようにしてもよい。
さらに、本発明の第２の態様において、保険契約に関するデータに基づき保険料未入金の場合の自動契約解除日を決定し、保険契約データ格納部に登録するステップと、自動契約解除日以前の日付が入金日として登録されていない第３未入金保険契約を抽出し、当該第３未入金保険契約を特定する情報を契約解除に係る保険契約として記憶装置に格納するステップとをさらに含むようにしてもよい。自動契約解除日になっても保険料が支払われない場合には、保険契約を有効にしておく必要が無いので、解除すべき保険契約を特定し、当該特定された保険契約について解除手続きを実施するためである。
また、第３未入金保険契約に対応する要回収金額のデータを、自動解除確定に応じて登録するステップをさらに含むようにしてもよい。自動解除すると解除返戻金が発生する場合もあり、実際に保険契約者から回収すべき金額が変更される場合もあるためである。
さらに、本発明の第２の態様において、事故日の情報を含む事故受付データを取得するステップと、事故日と保険契約に関するデータに含まれる保険始期日と保険契約の計上日との任意の組み合わせに係る少なくともいずれかの関係が所定の条件を満たす保険契約を抽出するステップとをさらに含むようにしてもよい。これにより、調査の必要な疑義のある保険契約を抽出することができるようになる。
本発明の第３の態様に係る、保険料の入金管理に関する情報処理方法は、顧客からの保険料の現金領収に関し且つ当該現金領収者（例えば代理店）からの送金方法を含む現金領収データを当該現金領収の基となる保険契約に関するデータより先に受信するステップと、受信した現金領収データから入金予定データを生成し、記憶装置に登録するステップと、現金領収者から保険料の送金を指示された者から取得した入金データを入金予定データと対応付け、少なくとも入金済みを表すデータを記憶装置に登録する入金確認ステップと、保険料の入金データを除く保険契約に関するデータを取得し、記憶装置に登録するステップと、保険契約に関するデータ（例えば実施の形態における計上データ）と入金済みを表すデータが登録されている入金予定データとを対応付け、所定の条件を満たしている場合（例えば保険料金額と領収金額が一致している場合）には保険金支払可を表すデータを記憶装置に登録するステップとを含む。
例えば代理店が現金で保険料を顧客から領収し、その都度送金することとすると、金融機関などからの入金データとマッチングをとるためのデータが必要となるため、予め現金領収データを受信し当該現金領収データから入金予定データを生成する。また、例えば集金代行会社のコンピュータでは保険契約に関するデータを直ぐには受け取れない場合が多いので、入金済みと判定された入金予定データと保険契約に関するデータとを後でマッチングさせる必要もある。なお、例えば集金代行会社において保険金の支払可否を管理する場合には、上で述べたように入金済みと判定された入金予定データと適正な対応関係が見出された保険契約については保険金を支払うことができるものとして登録しておき、事故などの発生に備える。
なお、上で述べた送金方法が極度額貸付払いである場合には、保険料相当の融資のためのデータを生成し、貸し付けを行う会社のコンピュータに上記融資のためのデータを送信するステップをさらに含むようにしてもよい。振込やデビットカード払いは、口座に残高がないと利用できないため、極度額貸付払いが必要な場合もあるためである。なお、極度額貸付とは、所定の金額の範囲内で任意の額について実施される融資を言うが、ここではクレジットカードによる立替え又は債権譲渡を含むものとする。
また、上で述べた送金方法が店舗払いである場合、店舗で読み取り可能なバーコード・データを生成し、現金領収者の端末（例えば代理店の携帯電話機）に送信するステップをさらに含むようにしてもよい。例えば、現金領収者たる代理店が多種類の端末装置を持ち歩くのは負担が大きいので、広く普及している例えば携帯電話機にバーコード・データを配信して、例えばコンビニエンスストアで送金を行うことができるようにするものである。
また、上で述べた入金確認ステップが、入金データの取得元のデータ及び入金予定データに含まれる送金方法のデータに基づいて、処理対象の入金予定データを抽出するステップをさらに含むようにしてもよい。予め指定される送金方法のデータを用いれば、対応する入金予定データを抽出することが容易になる。
さらに、上で述べた入金確認ステップが、入金予定データに対応する入金データが取得されない場合に、現金領収者に対する通知データを生成するステップをさらに含むようにしてもよい。入金の金額が異なっている場合や入金がなされていないような場合を検出し、警告するためである。
また、上記所定の条件を満たしていない保険契約に関するデータと対応する入金済みを表すデータが登録されている入金予定データとのうち少なくとも上記入金予定データを出力するステップをさらに含む。例えば、保険契約に関するデータに含まれる保険料の金額又は入金予定データに含まれる保険料の金額が間違っている場合には、間違いを訂正する必要があり、そのために上記のようなデータが必要である。
本発明の第４の態様に係る端末装置は、保険料金額、顧客名及び証券番号を含む領収証を発行する手段と、保険料領収者からの保険料の送金方法を選択可能に提示する手段と、選択された保険料の送金方法のデータと保険料金額のデータと顧客名のデータと証券番号と保険料領収者のデータとを含む現金領収データを、集金代行会社のコンピュータに当該現金領収の基となる保険契約に関するデータより先に且つ別途送信する手段とを有する。また、選択可能な保険料の送金方法が、送金手数料を基準に予め選択されているようにしてもよい。
なお、上で述べた情報処理方法は、プログラム及びコンピュータにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配布される場合もある。尚、中間的な処理結果はメモリに一時保管される。
【発明を実施するための最良の形態】
１．実施例１
第１図を用いて本発明の第１の実施例に係る手続き及び処理について概説する。本実施例は、代理店が保険料を現金で顧客（保険契約者）から受領する第１のケースを示す。
代理店２００は、顧客１００とのやり取りに基づき保険契約の申込書を作成し、顧客１００に申込書への署名・押印を求め、署名・押印後の申込書の提出を受け付ける。また、併せて口座振替依頼書（顧客指定の銀行口座等から保険料等を、ここでは保険料の集金代行会社の口座に振り替えることを金融機関に対して依頼する書面）への記入・押印も求め、記入・押印後の口座振替依頼書の提出を受け付ける（ステップ（１））。なお、口座振替依頼書の作成は任意であり、省略することもできる（以下同じとする。）この際、代理店２００は、顧客１００に保険料払込方法を指定してもらう（ステップ（２））。ここでは、現金による支払いが指定されたものとする。その場合には、申込書等と共に保険料を現金で受領する（ステップ（３））。例えば、代理店２００は、領収証の発行機能、各種決済機能、集金代行会社３００との通信機能を有する代理店専用端末を保有しており、当該代理店専用端末を用いて領収証を発行する（ステップ（４））。領収証には、領収日、顧客名、保険料金額、証券番号等の情報が含まれる。
また代理店２００は、顧客１００から受領した保険料を集金代行会社３００に送金するため送金方法を選択し、代理店専用端末に入力する。本実施例では保険料を現金で受領する毎に送金しなければならないので、送金手数料が大きな負担となる。従って、送金方法は、送金手数料が安価な、ネット銀行振込、デビットカード払い、コンビニエンスストア払い、極度額貸付払い（クレジットカード払いを含む。なお、以下における第１及び第２の実施例においては極度額貸付の一例としてクレジットカードの利用が選択された場合を示す。）、同行同一支店内の振込みといった方法から選択するようになっている。但し、予め設定された送金方法に固定させることも可能である。なお、ここでは、デビットカード払い、ネット銀行振込等の銀行振込、コンビニエンスストア払いのいずれかが選択されたものとする。代理店専用端末は、領収証を発行すると共に、顧客名、保険料金額、証券番号、代理店コード（又は代理店名）、送金方法及び領収日のデータを含む領収証データを集金代行会社３００のコンピュータに送信する（ステップ（５））。集金代行会社３００のコンピュータは、領収証データを代理店専用端末から受信し、入金予定データを生成し、例えば入金管理データベース（ＤＢ）に登録しておく（ステップ（６））。代理店専用端末ではなく、パーソナルコンピュータ等の汎用端末を用いて領収証データを集金代行会社３００のコンピュータに送信するようにしても良い。また、電話にて領収証データを集金代行会社３００に通知し、音声認識処理等により領収証データを集金代行会社３００のコンピュータに入力しても良い。その他ＦＡＸ等を利用しても良い。
代理店２００は、代理店専用端末から領収証データを集金代行会社３００のコンピュータに送信すると共に、選択した送金方法に沿った操作などを実施して、集金代行会社３００への送金指示を金融機関等５００に対して行う（ステップ（７））。デビットカード払いの場合には、デビットカードであるキャッシュカードを代理店専用端末のカードリーダに通してパスワードを入力し、金融機関等５００のコンピュータに決済情報を送信させる。金融機関等５００のコンピュータは、周知の方法にて代理店２００の口座から保険料金額を集金代行会社３００の口座に振り替える（ステップ（８））。コンビニエンスストア払いの場合には、代理店専用端末は少なくとも代理店コード及び保険料金額を表すバーコードを印刷し、出力する。代理店２００は、当該バーコードが印刷された払込用紙をコンビニエンスストアに持って行き、保険料の支払いを行う。コンビニエンスストア払いの場合コンビニエンスストアも金融機関等５００として機能し、代理店２００から保険料を受領すると、例えばコンビニエンスストアの本部は、当該保険料金額を集金代行会社３００の所定の口座に払い込む（ステップ（８））。ネット銀行振込の場合には、例えば代理店専用端末がインターネット経由で銀行サイトにアクセスし、代理店２００のキー入力に従ってログインし、所定の手順に従って代理店２００の口座から集金代行会社３００の口座へ保険料金額の振込みを指示する。金融機関等５００である銀行のコンピュータは、代理店２００の口座から集金代行会社３００の口座へ保険料金額の振替処理を実施する（ステップ（８））。通常の振込の場合には、代理店２００は、銀行等のＡＴＭ（Automatic Teller Machine）を操作して、代理店２００の口座から又はＡＴＭに投入した現金にて集金代行会社３００の口座へ保険料金額の振込みを指示する。金融機関等５００である銀行のコンピュータは、代理店２００の口座から集金代行会社３００の口座へ保険料金額の振替処理を実施する（ステップ（８））。
金融機関等５００のコンピュータは、任意のタイミングで又は集金代行会社３００のコンピュータからの要求に応じて、入金データを集金代行会社３００のコンピュータに送信する（ステップ（９））。集金代行会社３００は、入金データを受信し、記憶装置に格納する。そして、入金予定データと入金データとのマッチング処理を実施する（ステップ（１０））。このマッチング処理では、入金データの送信元に対応する送金方法を特定し、入金予定データには送金方法が含まれているので、当該送金方法にてマッチング対象の入金予定データを絞り込む。そして、入金データに含まれる入金者名及び入金金額と、入金予定データに含まれる代理人コード又は代理店名及び保険料金額とを比較することにより、入金データに対応する入金予定データを抽出する。対応する入金データが抽出された入金予定データには入金確認済みを表すデータを登録する。
一方、代理店２００は、保険契約の申込書及び口座振替依頼書などを保険会社４００に送付すると共に、代理店２００のコンピュータから計上データ（保険契約についてのデータ）を保険会社４００のコンピュータに送信する（ステップ（１１））。場合によっては、代理店２００によっては計上データの生成は行われず、保険会社４００により保険契約の申込書に基づき計上データが生成される場合もある。保険会社４００は、代理店２００から申込書等を受領すると共に、保険会社４００のコンピュータは代理店２００のコンピュータから計上データを受信する。そして、保険会社４００のコンピュータは、所定の確認処理などを行った後に計上データを保険契約ＤＢに登録して、計上処理を実施する（ステップ（１２））。計上処理実施後、保険会社４００のコンピュータは、任意のタイミングで計上データを集金代行会社３００のコンピュータに送信する（ステップ（１３））。集金代行会社３００のコンピュータは、計上データを受信し、例えば入金管理ＤＢに登録する。計上データの他に、口座振替依頼書等も送付される。そして、集金代行会社３００のコンピュータは、計上データと入金確認済みの入金予定データとのマッチング処理を実施する（ステップ（１４））。入金予定データには証券番号のデータが含まれるので、計上データに含まれる証券番号を用いて対応付けを行う。さらに、入金予定データに含まれる保険料金額と計上データに含まれる保険料金額とを比較する。保険料金額が両データで一致する場合には、入金管理ＤＢに格納された計上データに保険料の領収日及び保険金支払可を表すデータを追加登録する。一方、保険料金額が両データで一致しない場合には、計上データの保険料金額に問題がある場合、入金予定データに問題がある場合のいずれか若しくはその両方の可能性がある。従って、少なくとも入金予定データを確認データとして用意し、保険会社４００のコンピュータに送信する（ステップ（１５））。保険会社４００のコンピュータは集金代行会社３００のコンピュータから確認データを受信し、保険会社４００の担当者は入金予定データ及び計上データにより確認及び調査を行う（ステップ（１６））。訂正が必要であれば、訂正計上データなどを集金代行会社３００に送信し、集金代行会社３００では計上データの更新、保険料の追徴又は返戻処理を実施する。追徴の場合には、追徴分の入金予定データを生成し、追徴分の入金データを受信した場合には、計上データに対応して追徴分の保険料の入金日等を登録する。保険金の支払可否については追徴分の保険料の入金日などに依存して決定するようにしてもよい。なお、返戻金がある場合には、例えば口座振替依頼書で特定される口座に返金する。
集金代行会社３００は、例えば所定期間毎に、領収した保険料と、代理店２００に支払う代理店手数料と、集金代行会社３００の手数料との精算処理を実施する（ステップ（１７））。すなわち、領収した保険料から代理店２００に支払う代理店手数料と集金代行会社３００の手数料とを差し引いて保険会社４００に支払う金額を決定し、精算の明細データを生成し、保険会社４００に送る。また、別途保険会社４００に対して計算された金額の送金を行う。さらに、代理店毎に所定期間中の代理店手数料を計算し、当該手数料の明細データを生成して、代理店２００に送付する（ステップ（１８））。また、別途代理店手数料を代理店２００宛に送金する。
なお、図示していないが、集金代行会社３００は、保険契約の更改時の集金代行、保険契約の異動の登録、保険料の追徴又は返戻の処理についても実施する。また、代理店手数料に齟齬が発見された場合についても、集金代行会社３００が最終的に差額の精算を行う。なお、代理店手数料の齟齬の原因が計上データにある場合には、保険会社４００に計上データの訂正を求めるなどの手続きも実施する。
このような手続き及び処理を実施することにより、集金代行会社３００を導入する場合においても、即時精算をスムーズに行うことができるようになる。
２．実施例２
第２図を用いて本発明の第２の実施例に係る手続き及び処理について概説する。本実施例は、代理店が保険料を現金で顧客（保険契約者）から受領する第２のケースを示す。
代理店２００は、顧客１００とのやり取りに基づき保険契約の申込書を作成し、顧客１００に申込書への署名・押印を求め、署名・押印後の申込書の提出を受け付ける。また、併せて口座振替依頼書への記入・押印も求め、記入・押印後の口座振替依頼書の提出を受け付ける（ステップ（２１））。この際、代理店２００は、顧客１００に保険料払込方法を指定してもらう（ステップ（２２））。ここでは、現金による支払いが指定されたものとする。その場合には、申込書等と共に保険料を現金で受領する（ステップ（２３））。例えば、代理店２００は、第１の実施例で述べたような代理店専用端末を保有しており、当該代理店専用端末を用いて領収証を発行する（ステップ（２４））。領収証には、領収日、顧客名、保険料金額、証券番号等の情報が含まれる。
また代理店２００は、顧客１００から受領した保険料を集金代行会社３００に送金するための送金方法を選択し、代理店専用端末に入力する。ここでは、極度額貸付払いの一例であるクレジットカード払いが選択されたものとする。代理店専用端末は、領収証を発行すると共に、顧客名、保険料金額、証券番号、代理店コード（又は代理店名）、送金方法及び領収日のデータを含む領収証データを集金代行会社３００のコンピュータに送信する（ステップ（２５））。集金代行会社３００のコンピュータは、領収証データを代理店専用端末から受信し、入金予定データを生成し、例えば入金管理ＤＢに登録しておく（ステップ（２６））。代理店専用端末ではなく、パーソナルコンピュータ等の汎用端末を用いて又は電話にて領収証データを集金代行会社３００のコンピュータに通知するようにしても良い。その場合、領収証は手書きの領収証となる。
送金方法がクレジットカード払いの場合、集金代行会社３００のコンピュータは、予め登録された代理店２００のクレジットカード番号及び保険料金額を含む融資データを生成し、信販会社５１０のコンピュータに送信する（ステップ（２７））。なお、代理店２００のクレジットカード番号を、領収証データに含めるようにして、代理店専用端末などから受信したクレジットカード番号を用いるようにしてもよい。信販会社５１０のコンピュータは、集金代行会社３００のコンピュータから融資データを受信し、記憶装置に格納する。信販会社５１０は、代理店２００に対する与信確認を実施した後、問題がなければ融資を実行し、融資データを例えば融資ＤＢに登録する（ステップ（２８））。信販会社５１０のコンピュータは、銀行５２０のコンピュータに、信販会社５１０の口座から集金代行会社３００の口座へ融資された資金を振り替えるため、送金指示を送信する（ステップ（２９））。銀行５２０のコンピュータは、送金指示に従って送金処理を実施する。また、信販会社５１０のコンピュータは、任意のタイミングで又は集金代行会社３００のコンピュータからの要求に応じて、融資を実行した結果としての入金データを集金代行会社３００のコンピュータに送信する（ステップ（３０））。集金代行会社３００は、入金データを受信し、記憶装置に格納する。そして、入金予定データと入金データとのマッチング処理を実施する（ステップ（３１））。このマッチング処理では、入金データに含まれる入金者名（又はクレジットカード番号等から特定される代理店コード等）及び入金金額と、入金予定データに含まれる代理人コード又は代理店名及び保険料金額とを比較することにより、入金データに対応する入金予定データを抽出する。対応する入金データが抽出された入金予定データには入金確認済みを表すデータを登録する。
一方、代理店２００は、保険契約の申込書及び口座振替依頼書などを保険会社４００に送付すると共に、代理店２００のコンピュータから計上データ（保険契約についてのデータ）を保険会社４００のコンピュータに送信する（ステップ（３２））。保険会社４００は、代理店２００から申込書等を受領すると共に、保険会社４００のコンピュータは代理店２００のコンピュータから計上データを受信する。そして、保険会社４００のコンピュータは、所定の確認処理などを行った後に計上データを保険契約ＤＢに登録して、計上処理を実施する（ステップ（３３））。計上処理実施後、保険会社４００のコンピュータは、任意のタイミングで計上データを集金代行会社３００のコンピュータに送信する（ステップ（３４））。集金代行会社３００のコンピュータは、計上データを受信し、例えば入金管理ＤＢに登録する。計上データの他に、口座振替依頼書等も送付される。そして、集金代行会社３００のコンピュータは、計上データと入金確認済みの入金予定データとのマッチング処理を実施する（ステップ（３５））。入金予定データには証券番号のデータが含まれるので、計上データに含まれる証券番号を用いて対応付けを行う。さらに、入金予定データに含まれる保険料金額と計上データに含まれる保険料金額とを比較する。保険料金額が両データで一致する場合には、入金管理ＤＢに格納された計上データに保険料の領収日及び保険金支払可を表すデータを追加登録する。一方、保険料金額が両データで一致しない場合には、計上データの保険料金額に問題がある場合、入金予定データに問題がある場合のいずれか若しくはその両方の可能性がある。従って、少なくとも入金予定データを確認データとして用意し、保険会社４００のコンピュータに送信する（ステップ（３６））。保険会社４００のコンピュータは集金代行会社３００のコンピュータから確認データを受信し、保険会社４００の担当者により入金予定データ及び計上データにより確認及び調査が行われる（ステップ（３７））。訂正が必要であれば、訂正計上データなどを集金代行会社３００に送信し、集金代行会社３００では計上データの更新、保険料の追徴又は返戻処理を実施する。追徴の場合には、追徴分の入金予定データを生成し、追徴分の入金データを受信した場合には、計上データに対応して追徴分の保険料の入金日等を登録する。保険金の支払可否については追徴分の保険料の入金日などに依存して決定するようにしてもよい。なお、返戻金がある場合には、例えば口座振替依頼書で特定される口座に返金する。
集金代行会社３００は、例えば所定期間毎に、領収した保険料と、代理店２００に支払う代理店手数料と、集金代行会社３００の手数料との精算処理を実施する（ステップ（３８））。すなわち、領収した保険料から代理店２００に支払う代理店手数料と集金代行会社３００の手数料とを差し引いて保険会社４００に支払う金額を決定し、精算の明細データを生成し、保険会社４００に送る。また、別途保険会社４００に対して計算された金額の送金を行う。さらに、代理店毎に所定期間中の代理店手数料を計算し、当該手数料の明細データを生成して、代理店２００に送付する（ステップ（３９））。また、別途代理店手数料を代理店２００宛に送金する。
一方、信販会社５１０は、融資データに基づき、代理店２００に対して融資した資金の返済を請求する（ステップ（４０））。代理店２００は、信販会社５１０に対して融資された資金の返済を行う（ステップ（４１））。
なお、図示していないが、集金代行会社３００は、保険契約更改時の集金代行、保険契約の異動の登録、保険料の追徴又は返戻の処理についても実施する。また、代理店手数料に齟齬が発見された場合についても、集金代行会社３００が最終的に差額の精算を行う。なお、代理店手数料の齟齬の原因が計上データにある場合には、保険会社４００に計上データの訂正を求めるなどの手続きも実施する。
このような手続き及び処理を実施することにより、集金代行会社３００を導入する場合においても、即時精算をスムーズに行うことができるようになる。
３．実施例３
第３図を用いて本発明の第３の実施例に係る手続き及び処理について概説する。本実施例は、顧客が保険料を集金代行会社に直接支払う第１のケースを示す。
代理店２００は、顧客１００とのやり取りにより保険契約の申込書を作成し、顧客１００に申込書への署名・押印を求め、署名・押印後の申込書の提出を受け付ける。また、併せて口座振替依頼書への記入・押印も求め、記入・押印後の口座振替依頼書の提出を受け付ける（ステップ（５１））。この際、代理店２００は、顧客１００に保険料払込方法を指定してもらう（ステップ（５２））。ここでは、顧客１００が直接集金代行会社３００に保険料を払い込むという方法を選択したものとする。なお、顧客１００が直接保険会社４００に保険契約の申し込みを行うようにしても良い。保険契約の申し込みを受け付けた代理店２００は、申し込みに係る保険契約の内容を含む、保険契約の計上データを生成して、代理店２００のコンピュータから保険会社４００のコンピュータに上記計上データを送信する。また、保険契約の申込書及び口座振替依頼書を保険会社４００に送付する（ステップ（５３））。場合によっては、保険会社４００が、受領した保険契約の申込書に基づき計上データを生成する場合もある。保険会社４００のコンピュータは、代理店２００のコンピュータから計上データを受信すると、当該計上データを用いた保険契約の計上処理を実施する（ステップ（５４））。すなわち、計上データ等の情報が保険契約ＤＢに登録される。次に、保険会社４００のコンピュータは、計上データを集金代行会社３００のコンピュータに送信する（ステップ（５５））。口座振替依頼書についても集金代行会社３００に送付される。この口座振替依頼書については代理店２００から直接集金代行会社３００に送付される場合もある。集金代行会社３００のコンピュータは、計上データを受信すると、入金管理ＤＢに登録すると共に、支払期限データを生成し、入金管理ＤＢ等に登録する（ステップ（５６））。支払期限については、保険料の支払期日だけでなく、自動契約解除日も含まれる。これらの日付は、保険始期、保険種類、払込方法（一括払い、月払い、半年払いなど）等に基づき決定される。
集金代行会社３００は、計上データ及び生成された支払期限データに基づき保険料の支払いを顧客１００に要求するようにしても良いし、代理店２００等が支払い期限についての情報を顧客１００に提示しておき、顧客１００が自発的に入金するようにしても良い。入金の方法は任意であって、ネット銀行振込を含む銀行振込、郵便振替、コンビニエンスストア払い、クレジットカード払いその他の方法が使用できる。自動口座引き落としでもよい。顧客１００は、いずれかの方法にて金融機関等５００に対して保険料の送金指示を行う（ステップ（５７））。金融機関等５００は、顧客１００からの指示に従って保険料を集金代行会社３００の口座に送金する（ステップ（５８））。なお、ここでは金融機関等５００には、銀行、クレジットカード会社（又は信販会社）、郵便局、コンビニエンスストア等が含まれる。金融機関等５００のコンピュータは、任意のタイミング又は集金代行会社３００のコンピュータからの要求に応じて、集金代行会社３００の口座への入金データを送信する（ステップ（５９））。集金代行会社３００のコンピュータは、入金データを金融機関等５００のコンピュータから受信し、入金データ格納部等に格納する。そして、集金代行会社３００のコンピュータは、入金データを入金管理ＤＢに格納された計上データに対応付けるための入金照合処理を実施する（ステップ（６０））。すなわち、どの保険契約についての入金であるかを特定し、入金日のデータを入金管理ＤＢに登録する。マッチングが取れない入金については、別途どのような入金なのか、過不足金額はいくらなのかについて確認する処理が必要となる。マッチングが取れた入金については、入金された保険料から代理店手数料及び集金代行会社３００の手数料を差し引いた、保険会社４００への支払金額を計算し、保険契約毎の明細データを生成する精算処理を実施する（ステップ（６１））。支払金額の送金については別途行う。
次に、集金代行会社３００のコンピュータは、入金管理ＤＢに登録された支払期日及び自動契約解除日並びに入金日又は未入金状態の情報に基づき、支払期限確認処理を実施する（ステップ（６２））。より詳しくは、（ａ）支払期日以前の入金日が記録されている保険契約については保険金支払可を設定する。また、（ｂ）支払期日以前において未入金状態が記録されている保険契約については支払期日までの事故に対する保険金支払いについて保留を設定する。また、（ｃ）支払期日から自動契約解除日までの間の日付で入金日が記録されている保険契約については、保険始期日から支払期日までは支払不可で且つ支払期日以降は保険金支払可を設定する。さらに、（ｄ）支払期日から自動契約解除日までの間で未入金状態が記録されている保険契約については保険始期日から支払期日までは支払不可で且つ支払期日以降は保険金支払いの保留を設定する。また、（ｅ）自動契約解除日までの日付で入金日が記録されていない保険契約については支払期日まで及び支払期日以降についても保険金支払不可を設定する。
第４図に保険契約の締結から自動契約解除までの手続きの流れを詳しく示す。顧客１００は保険契約の締結に伴い保険契約の申込書４１０を代理店２００に提出する。その際、例えば代理店２００が保険料の請求書４１１を顧客１００に渡す。ここでは例えば契約締結日から所定日数後（例えば１４日後）に保険料の支払期日が設定されるものとする。但し他の方法で決定しても良い。また、保険契約の計上データ４１２は保険会社４００のコンピュータから集金代行会社３００のコンピュータに送信される。顧客１００が、支払期日までに保険料を集金代行会社３００に送金すれば、所定のタイミングにて集金代行会社３００は、保険料から手数料などを精算した後の金額を保険会社４００に送金する。一方、例えば契約締結日から１週間以内に入金が確認できない場合、集金代行会社３００は、保険料支払案内書４１３を顧客１００に送付する場合もある。支払期日以前であれば、この保険料支払案内書４１３に応じて送金しても特に問題はなく、通常の入金と同様に取り扱われ、入金が確認できた時点で入金確認通知４１４が集金代行会社３００から顧客１００に送付される。また、支払期日までに保険料の入金が確認できれば、保険始期日から保険金が支払われる。一方、支払期日までに保険料の入金が確認できないと、集金代行会社３００は解除予告通知４１５（督促書）を顧客１００に送付する。支払期日から自動契約解除日までは猶予期間であって、例えば１４日設けられる。支払期日までに保険料が支払われなければ、支払期日までの事故に対して保険金は支払われない。この猶予期間内に保険金の支払いがあれば、支払期日以降の事故に対して保険金が支払われる。もし、自動契約解除日までに入金が確認できなければ、集金代行会社３００は、契約の解除通知４１６を顧客１００に送付する。そして、始期に遡及して契約は解除される。２回目以降の保険料支払い及び契約更改時についても、通知の回数等に差がある場合もあるが、ほぼ同様の取り扱いとなる。
上で述べたような、支払期限確認処理の処理結果については、集金代行会社３００のコンピュータから保険会社４００のコンピュータに送信される（ステップ（６３））。なお、以上で示した支払期限と保険金支払可否は一例であって、別のスキームに従うようにしてもよい。また、第４図で示したように、保険料の支払いがない場合には、適宜入金の督促を実施する（ステップ（６５））。
保険会社４００のコンピュータは、支払期限確認処理の処理結果を受信すると、例えば支払状況管理ＤＢに格納する。そして、実際に事故の通知を受け付けた際に保険金の支払可否を判断するために用いる。また、集金代行会社３００のコンピュータにおいて実施される支払期限確認処理において、自動契約解除日までの日付で入金日が記録されていない保険契約を、別途自動解除対象保険契約として特定する。そして、当該自動解除対象保険契約の情報を、集金代行会社３００のコンピュータから保険会社４００のコンピュータに送信し（ステップ（６４））、保険会社４００のコンピュータでは、保険契約データの更新を行う。すなわち、契約の自動解除をすべき保険契約について自動解除（例えば自動解除日）を登録する。
また、集金代行会社３００のコンピュータは、代理店毎に所定期間中の代理店手数料を計算し、当該手数料の明細データを生成して、代理店２００に送る（ステップ（６６））。また、別途代理店手数料を代理店２００宛に送金する。
このようにすることにより、保険会社４００は入金の有無や時期について直接管理することなく、保険金支払の可否や自動解除といった必要な情報を集金代行会社３００から得ることができるようになる。集金代行会社３００は、これらのサービスにより保険会社４００から対価を得て収益を上げることができる。
４．実施例４
第５図を用いて本発明の第４の実施例に係る手続き及び処理について概説する。本実施例は、顧客が保険料を集金代行会社に直接支払う第２のケースを示す。
代理店２００は、顧客１００とのやり取りにより保険契約の申込書を作成し、顧客１００に申込書への署名・押印を求め、署名・押印後の申込書の提出を受け付ける。また、併せて口座振替依頼書への記入・押印も求め、記入・押印後の口座振替依頼書の提出を受け付ける（ステップ（７１））。この際、代理店２００は、顧客１００に保険料払込方法を指定してもらう（ステップ（７２））。ここでは、顧客１００が直接集金代行会社３００に保険料を払い込むという方法を選択したものとする。なお、顧客１００が直接保険会社４００に保険契約の申し込みを行うようにしても良い。
保険契約の申し込みを受け付けた代理店２００は、申し込みに係る保険契約の内容を含む、保険契約の計上データを生成して、代理店２００のコンピュータから保険会社４００のコンピュータに上記計上データを送信する。また、保険契約の申込書及び口座振替依頼書を保険会社４００に送付する（ステップ（７３））。場合によっては、保険会社４００が、受領した保険契約の申込書に基づき計上データを生成する場合もある。保険会社４００のコンピュータは、代理店２００のコンピュータから計上データを受信すると、当該計上データを用いた保険契約の計上処理を実施する（ステップ（７４））。すなわち、計上データ等の情報が保険契約ＤＢに登録される。次に、保険会社４００のコンピュータは、計上データを集金代行会社３００のコンピュータに送信する（ステップ（７５））。口座振替依頼書についても集金代行会社３００に送付される。この口座振替依頼書については代理店２００から直接集金代行会社３００に送付される場合もある。集金代行会社３００のコンピュータは、計上データを受信すると、入金管理ＤＢに登録すると共に、支払期限データを生成し、入金管理ＤＢ等に登録する（ステップ（７６））。ここでは支払期限は、保険料の支払期日だけではなく、自動契約解除日を含む。これらの日付は、保険始期、保険種類、払込方法（一括払い、月払い、半年払いなど）等に基づき決定される。
集金代行会社３００は、計上データ及び生成された支払期限データに基づき保険料の支払いを顧客１００に要求するようにしても良いし、代理店２００等が支払い期限についての情報を顧客１００に提示しておき、顧客１００が自発的に入金するようにしても良い。入金の方法は任意であって、ネット銀行振込を含む銀行振込、郵便振替、コンビニエンスストア払い、極度額貸付払い（クレジットカード払いを含む）、自動口座振替その他の方法が使用できる。顧客１００は、いずれかの方法にて金融機関等５００に対して保険料の送金指示を行う（ステップ（７７））。金融機関等５００は、顧客１００からの指示に従って保険料を集金代行会社３００の口座に送金する（ステップ（７８））。なお、ここでは金融機関等５００には、銀行、クレジットカード会社（又は信販会社）、郵便局、コンビニエンスストア等が含まれる。金融機関等５００のコンピュータは、任意のタイミング又は集金代行会社３００のコンピュータからの要求に応じて、集金代行会社３００の口座への入金データを送信する（ステップ（７９））。集金代行会社３００のコンピュータは、入金データを金融機関等５００のコンピュータから受信し、入金データ格納部等に格納する。そして、集金代行会社３００のコンピュータは、入金データを入金管理ＤＢに格納された計上データに対応付けるための入金照合処理を実施する（ステップ（８０））。すなわち、どの保険契約についての入金であるかを特定し、入金日のデータを入金管理ＤＢに登録する。マッチングが取れない入金については、別途どのような入金なのか、過不足金額はいくらなのかについて確認する処理が必要となる。マッチングが取れた入金については、入金された保険料から代理店手数料及び集金代行会社３００の手数料を差し引いた、保険会社４００への支払金額を計算し、保険契約毎の明細データを生成する精算処理を実施する（ステップ（８１））。支払金額の送金については別途行う。
次に、集金代行会社３００のコンピュータは、入金管理ＤＢに登録された保険始期日並びに入金日又は未入金状態の情報に基づき支払状況を確認し、保険料債権の譲渡に係る保険契約を特定する処理を実施する（ステップ（８２））。より詳しくは、（ａ）保険始期日（若しくは、保険始期日より一定日数前又は後の日でもよい。以下同じ）以前の入金日が記録されている保険契約については、通常の取り扱いとする。また、（ｂ）保険始期日以前において未入金状態が記録されている保険契約を、保険料債権の譲渡に係る保険契約として抽出する。支払期日より前に保険料の支払いがあれば本来問題ないが、本実施例では保険始期日以前において未入金状態である場合には、集金代行会社３００が保険料債権を保険会社４００から譲り受けることにより、一旦保険会社４００に対しては問題なく保険料を受領したものとして取り扱う。但し、支払期日までに入金を確認できなければ、集金代行会社３００は顧客１００に対して督促を行う（ステップ（８４））。なお、後に述べるが、自動契約解除日までに入金が確認できなければ、契約を解除するため、契約解除に係る保険契約を抽出して、保険会社４００に通知する。
このように、保険料債権が譲渡されるものとして抽出された保険契約の情報は、集金代行会社３００のコンピュータから保険会社４００のコンピュータに送信される（ステップ（８３））。保険会社４００は、保険料債権が譲渡されるものとして抽出された保険契約の情報を受信すると、当該保険契約については保険料債権の譲渡に基づき保険始期日までに保険料が支払われたものとして取り扱う。但し、実際に保険料が顧客１００から支払われた契約とは区別できるようにしておく。また、集金代行会社３００は、保険料債権の譲受金額を算出し、当該譲受金額の送金を別途行う。なお、集金代行会社３００のコンピュータは、保険始期日までの日付で入金日が記録されている保険契約のデータについても、別途保険料の入金日の情報と共に保険会社４００のコンピュータに送信するようにしてもよい。このような保険契約は、保険料の債権譲渡ではなく、集金代行扱いである。集金代行会社３００のコンピュータは、保険料債権を譲り受けた保険契約について、顧客１００からの要回収金額を管理し、回収に努める。
一方、保険会社４００では、事故情報を顧客１００等から受け付ける場合がある（ステップ（８５））。保険料債権を譲渡している場合には、最終的に保険料を顧客１００から集金できたかということは保険会社４００では把握できない場合もある。集金代行会社３００が保険料未収であるにもかかわらず、保険金だけが支払われてしまうのは問題であるので、本実施例では、保険料債権が譲渡された保険契約について事故情報を受け付けた場合には、警告ということで保険会社４００のコンピュータから集金代行会社３００のコンピュータへ、証券番号と事故日、事故受付日などの事故データを送信する（ステップ（８６））。また、不正等の検出のため詳細調査の対象とする保険契約を特定するために、事故データを保険会社４００のコンピュータから集金代行会社３００のコンピュータへ送信するようにしても良い。集金代行会社３００のコンピュータは、保険料債権を譲り受けた保険契約についての事故データを用いて、保険料集金上問題が無いか確認する（ステップ（８７））。詳細調査の対象とする保険契約を特定するために事故データを受け取った場合には、例えば第１７図に示したような処理を実施する。なお、保険料を支払っていないのにもかかわらず事故発生が通知されている場合には保険金が支払われるのは不適切であるから、保険契約を特定した保険金支払停止要求を集金代行会社３００のコンピュータから保険会社４００のコンピュータに送信する（ステップ（８８））。保険会社４００では、保険金支払停止要求を受信した場合には、原則として保険金の支払いを停止し、詳細を調査する。
また、集金代行会社３００のコンピュータは、期限確認処理も実施する（ステップ（８９））。すなわち、所定のタイミングにて、自動契約解除日までの日付で入金日が登録されていない保険契約を契約の自動解除に係る保険契約として抽出する。そして、当該抽出された保険契約の証券番号等のデータを、保険会社４００のコンピュータに送信する（ステップ（９０））。そして、保険会社４００のコンピュータは、自己の保持する保険契約の情報に自動契約解除を登録する（ステップ（９１））。集金代行会社３００は、保険会社４００から契約解除により解除返戻金を受け取ることができる場合もあり、その場合には保険会社４００のコンピュータは当該解除返戻金のデータを集金代行会社３００のコンピュータに送信する（ステップ（９２））。当該解除返戻金については、保険会社４００から集金代行会社３００に別途送金される。なお、集金代行会社３００は、解除返戻金と保険料との差額及び手数料などを顧客１００から別途回収することになる。すなわち、管理している要回収金額を更新し、債権回収を実施する。
また、集金代行会社３００のコンピュータは、代理店毎に所定期間中の代理店手数料を計算し、当該手数料の明細データを生成して、代理店２００に送る（ステップ（９３））。また、別途代理店手数料を代理店２００宛に送金する。
このようにすれば保険会社４００は入金の有無や時期について直接管理することなく、保険金支払の可否や自動解除といった必要な情報を集金代行会社３００から得ることができるようになる。集金代行会社３００は、これらのサービスにより保険会社４００から対価を得て収益を上げることができる。
５．システム構成
上で述べた第１乃至第４の実施の形態を実施するためのシステム構成例を第６図に示す。例えばインターネット、公衆回線網、専用線などを含むネットワーク１には、保険会社４００により管理・運用される保険会社コンピュータ５と、集金代行会社３００により管理・運用される集金代行会社コンピュータ３と、コンビニエンスストアの本部コンピュータ又は銀行５２０のコンピュータである金融機関コンピュータ７と、信販会社５１０により管理・運用される信販会社コンピュータ９と、代理店２００が使用する代理店ＰＣ（Personal Computer）１１と、代理店２００が使用する携帯電話機１５と、カードリーダ機能とプリンタ機能と通信機能と各種処理機能を有する代理店専用端末１３とが接続される。
集金代行会社コンピュータ３は、入金予定データ生成部３１と、バーコード配信処理部３２と、融資データ処理部３３と、入金照合処理部３４と、期日設定処理部３５と、期限確認処理部３６と、集金関連処理部３７と、代理店管理部３８と、契約抽出処理部３９と、精算処理部４０とを含む。また、集金代行会社コンピュータ３は、入金管理ＤＢ４１と、入金データ格納部４２と、事故受付情報ＤＢ４３と、通知データ格納部４４とを管理している。
入金予定データ生成部３１は、代理店専用端末１３又は代理店ＰＣ１１から受信した領収証データから入金予定データを生成する。バーコード配信処理部３２は、代理店２００により顧客１００から保険料を現金で領収し、その保険料を集金代行会社３００に送金する際の送金方法がコンビニエンスストア払いであって代理店２００が代理店専用端末１３を使用していない代理店である場合に、例えば当該代理店２００の携帯電話機１５に対してバーコード・データを配信するための処理を実施する。融資データ処理部３３は、同じく代理店２００が保険料を集金代行会社３００に送金する際の送金方法がクレジットカード払いである場合に信販会社５１０に対する融資データを生成・送信する。入金照合処理部３４は、入金予定データと入金データとのマッチング処理、入金確認済みの入金予定データと計上データとのマッチング処理、入金データと計上データとのマッチング処理を実施する。期日設定処理部３５は、保険会社コンピュータ５から受信する計上データに基づき支払期日や自動契約解除日等の期日を設定し、入金管理ＤＢ４１に登録する。期限確認処理部３６は、入金管理ＤＢ４１に登録されている各保険契約の始期日、支払期日、自動契約解除日と入金日、未入金の場合には処理日との比較を行い、期日を徒過したか等の判断を行う。集金関連処理部３７は、集金関連の諸処理を実施する。代理店管理部３８は、代理店２００の手数料計算や手数料の明細データを生成するための処理を実施する。契約抽出処理部３９は、事故受付情報ＤＢ４３に格納された事故日の情報等から詳細な調査が必要な保険契約を抽出するための処理を実施する。精算処理部４０は、受領した保険料の精算のための処理を実施する。入金管理ＤＢ４１は、入金予定データと集金代行会社３００が管理する保険契約についての情報とを格納する。入金データ格納部４２は、金融機関コンピュータ７等から受信した入金データを格納する。事故受付情報ＤＢ４３は、保険会社コンピュータ５から受信した事故受付情報を格納する。通知データ格納部４４は、他のコンピュータに送信するためのデータなどを格納する。
保険会社コンピュータ５は、代理店ＰＣ１１等からネットワーク１を介して受信し且つ計上処理が実施された計上データ（保険契約データ）を登録する保険契約ＤＢ５２と、顧客１００等から受け付けた事故のデータを登録するための事故受付情報ＤＢ５１と、集金代行会社コンピュータ３から受信する保険料入金に関連する情報等を保管するための支払状況管理ＤＢ５３とを管理している。金融機関コンピュータ７は、ウェブ（Ｗｅｂ）サーバ機能及びネットバンク機能を有している場合もある。また、顧客１００又は代理店２００による入金のデータを格納する入金データ格納部７１を管理している。金融機関コンピュータ７は、金融機関毎について設けられる。信販会社コンピュータ９は、集金代行会社コンピュータ３から受信した融資データを格納する融資データ格納部９１を管理している。
代理店ＰＣ１１は、保険契約の計上データを生成するためのプログラムがインストールされており、ネットワーク１を介して計上データを保険会社コンピュータ５に送信することができる。また、領収日、保険料金額（領収金額）、証券番号、送金方法、顧客名などを含む領収証データを生成し、集金代行会社コンピュータ３に送信するためのプログラムがインストールされている場合もある。また、ウェブ（Ｗｅｂ）ブラウザやメーラ・プログラムもインストールされており、インターネットのホームページを閲覧したり、メールのやり取りを行うことができるようになっている。
代理店２００の携帯電話機１５は、ネットワーク・アクセス機能を有しており、Ｗｅｂブラウザ機能及びメーラ機能を有しているものとする。また、バーコード・データを表示できる程度のサイズを有する表示装置を備えているものとする。
代理店専用端末１３は、上で述べたように、保険料を現金で受領した場合には当該保険料のための領収証を印刷したり、コンビニエンスストア払いを可能とするためのバーコードを含む払込用紙を印刷する機能を有し、さらに、カードリーダを備えており、当該カードリーダによりデビットカード（キャッシュカード）を読み取って決済処理を実施する機能、及びカードリーダによりクレジットカードを読み取ってクレジットカードによる決済処理を実施する機能を有する。なお、これら機能の具体的な実施方法については、従来技術と同じであるからここでは詳しく述べない。また、代理店専用端末１３は、集金代行会社コンピュータ３とネットワーク１を介して通信することができ、上で述べた領収証データを集金代行会社コンピュータ３に送信する機能も有している。この機能については以下で詳しく述べる。
６．実施例１及び２における処理内容
次に第６図に示したシステムの第１及び第２の実施例における処理フローを第７図乃至第１４図を用いて説明する。
例えば代理店２００が顧客１００から保険契約の申込書等を受け取り、さらに保険料を現金で受領する場合には、代理店専用端末１３を操作して、顧客名、金額、証券番号、保険種別等の領収証データを入力する。代理店専用端末１３は、当該領収証データの入力を受け付ける（ステップＳ１）。なお、予め入力されている場合には、当該予め入力されている領収証データを読み出す。例えば代理店ＰＣ１１に接続させて、代理店ＰＣ１１において入力されていたデータを代理店専用端末１３に送信しておくようにしても良い。
次に、代理店専用端末１３は、代理店２００からの出力指示に応じて領収証を印刷する（ステップＳ３）。印刷された領収証は、顧客１００に手渡される。また、代理店専用端末１３は、送金方法のメニューを表示装置に表示する（ステップＳ５）。上で述べたが送金方法は送金手数料が安価なものが優先して表示される。これに対して代理店２００は、今回の送金方法を選択する。なお、送金方法をメニュー表示することなく、例えば送信ボタンをクリックするまでに変更がなされなければ、予め設定されている特定の送金方法を使用するものとするといった手法で送金方法を特定するようにしても良い。そして、例えば代理店２００の指示に従って、送金方法、領収日、代理店コード、金額及び証券番号などを含む領収証データを生成し、集金代行会社コンピュータ３に送信する（ステップＳ７）。この後、代理店専用端末１３等により送金の処理を実施するが、これは端子Ａを介して移行した第１０図において説明する。
集金代行会社コンピュータ３の入金予定データ生成部３１は、代理店専用端末１３から領収証データを受信し、記憶装置に格納する（ステップＳ９）。そして、領収証データから入金予定データを生成し、例えば入金管理ＤＢ４１に格納する（ステップＳ１１）。例えば第８図に示すようなテーブルに入金予定データが登録される。すなわち、送金方法と、領収日と、顧客名と、保険料金額と、代理店コード（又は代理店名若しくはその両方）と、証券番号と、照合結果（例えば１は照合済み、０は未照合）とが各レコードについて登録される。この他にも取得できるデータを登録しておいても良い。
受信した領収証データに送金方法としてクレジットカード払いというデータが含まれている場合には（ステップＳ１３：Ｙｅｓルート）、融資データ処理部３３は、領収証データに基づき融資データを生成し、提携している信販会社コンピュータ９に送信する（ステップＳ１５）。融資データは、少なくとも、例えば予め信販会社コンピュータ９に代理店コードが登録されている場合には代理店コード、代理店コードに対応して予め登録されている代理店２００のクレジットカード番号若しくは領収証データに含まれる代理店２００のクレジットカード番号と、金額とを含む。信販会社コンピュータ９は、集金代行会社コンピュータ３から融資データを受信すると当該融資データを融資データ格納部９１に格納し、与信処理を実施し、問題なければ融資を行うための送金指示を例えばネットワーク１を介して金融機関コンピュータ７に送信する。金融機関コンピュータ７では、送金指示に従って送金処理を実施する。なお、信販会社コンピュータ９は、融資データに従って融資を行った場合には、融資実行結果についてのデータを入金データとして集金代行会社コンピュータ３に送信する。なおステップＳ１５のような処理を実行するのは一例であって、後に述べるように代理店専用端末１３にて信販会社コンピュータ９にデータを送信してしまい、ステップＳ１５を実行しないような構成であってもよい。
受信した領収証データに送金方法としてクレジットカード払い以外のデータが含まれている場合（ステップＳ１３：Ｎｏルート）及びステップＳ１５の後に、集金代行会社コンピュータ３は、金融機関コンピュータ７等からその入金データ格納部７１に格納された入金データを受信し、例えば入金データ格納部４２に格納する（ステップＳ１７）。例えば、第９図に示すように、少なくとも入金日と入金金額と入金者（代理店コード又は代理店名若しくはその両方）のデータが含まれる。金融機関等５００によってはより多くのデータを含む場合もある。そして、入金照合処理部３４は、入金データ格納部４２に新規にデータが格納されると、入金管理ＤＢ４１に格納されている入金予定データとのマッチング処理を実施する（ステップＳ１９）。この際、例えば、入金データの送信元である金融機関のデータ（例えば銀行）から送金方法（銀行振込）を特定し、当該特定された送金方法にて比較する入金予定データを絞り込むようにしてもよい。またマッチングは、例えば入金データに含まれる金額と代理店コード（又は代理店名）をキーにして入金予定データを検索するような処理であってもよい。このマッチング処理において、マッチングがとれた入金予定データについてはその照合結果に例えば「１」を登録する。また、入金照合処理部３４は、入金予定データに含まれる領収日から所定期間経過しても未照合（アンマッチ）である入金予定データを入金管理ＤＢ４１から抽出し、当該入金予定データに含まれる代理店コードから代理店２００を特定し、当該代理店２００宛の入金確認データを生成する（ステップＳ２１）。当該入金確認データについては、例えば通知データ格納部４４に格納しておき、例えば該当する代理店２００の代理店専用端末１３からの領収証データを受信した場合に、領収証データの受信完了データと共に送信するようにしても良い。また、別途電子メールなどで予め登録されている当該代理店２００のメールアドレス宛に送信するようにしても良い。さらに、集金代行会社３００の担当者に出力し、電話などで確認を行うようにしても良い。例えば代理店専用端末１３は、入金確認データを集金代行会社コンピュータ３から受信すると、表示装置に表示する（ステップＳ２３）。代理店２００は、表示装置の表示を見て、入金忘れなどがなかったか金額が間違っていなかったか等を確認する。なお、入金確認データについては代理店ＰＣ１１にて受信する場合も、代理店２００の携帯電話機１５にて受信する場合もある。
以上のような処理を実施することにより、即日精算により法定帳簿の記帳などの事務作業を無くして業務の効率化を図り、且つ代理店の手数が大幅に軽減される。また、現金領収で即日精算する場合には、集金代行会社コンピュータ３は、計上データを保持しない状態で入金データを受信する可能性がある。実施例１及び２ではそのために入金予定データを生成して、一旦入金予定データと入金データのマッチングを取るようにしている。そして、以下で説明するように、入金予定データと計上データとのマッチングを行う。
次に第１０図を用いて第７図における端子Ａ以降の送金処理の一例について説明する。まず、代理店専用端末１３は、クレジットカード払いが送金方法として指定されたか判断する（ステップＳ３１）。クレジットカード払いであると判断された場合には、代理店２００は自己のクレジットカードを代理店専用端末１３のカードリーダに通すので、代理店専用端末１３は当該クレジットカードのデータを読み取る（ステップＳ３３）。そして、クレジットカードのデータ及び領収証データ（例えば保険料金額）に基づき、信販会社コンピュータ９宛の、集金代行会社３００への送金データを生成し、信販会社コンピュータ９に送信する（ステップＳ３５）。この際例えばパスワードの入力を求め、信販会社コンピュータ９に送信するといった処理を実施する場合もある。これらの処理については従来技術と変わらないのでこれ以上述べない。なお、ステップＳ３１乃至Ｓ３５については第７図のステップＳ１５の処理を実行する場合には必要ない。また、端子Ｂから第７図の処理に戻る。
クレジットカード払いではないと判断された場合にはデビットカード払いが送金方法として指定されたか判断する（ステップＳ３７）。デビットカード払いであると判断された場合には、代理店２００はデビットカードであるキャッシュカードを、代理店専用端末１３のカードリーダに通すので、当該キャッシュカードのデータを読み取る（ステップＳ３９）。そして、キャッシュカードのデータ及び領収証データ（例えば保険料金額）に基づき、金融機関コンピュータ７宛の、集金代行会社３００への送金データを生成し、金融機関コンピュータ７に送信する（ステップＳ４１）。この際例えばパスワードの入力を求め、金融機関コンピュータ７に送信するといった処理を実施する場合もある。これらの処理については従来技術と変わらないのでこれ以上述べない。また、端子Ｂから第７図の処理に戻る。
デビットカード払いではないと判断された場合にはネット振込みが送金方法として指定されたか判断する（ステップＳ４３）。ネット振込みであると判断された場合には、例えば予め登録されている銀行口座のリストを表示し、いずれの銀行から送金するのか選択させる。代理店専用端末１３は、代理店２００による銀行口座の選択入力を受け付け（ステップＳ４５）、例えばインターネット上に開設されている指定の銀行サイトにアクセスする。そしてログインする。なお、自動的にログインできない場合にはログインページからログインする（ステップＳ４７）。そして、銀行サイトのページ構成に従って所定の手順で振込データを入力し、振込みデータを送信して送金を指示する（ステップＳ４９）。また、端子Ｂから第７図の処理に戻る。
また、ネット振込みではないと判断された場合には、コンビニエンスストア払いが指定されたか判断する（ステップＳ５１）。コンビニエンスストア払いであると判断された場合には、少なくとも代理店コード又は代理店名若しくはその両方と保険料金額のデータとを用いてバーコード・データを生成し、印刷する（ステップＳ５３）。代理店２００は、出力されたバーコードを含む払込用紙を持ってコンビニエンスストアの店頭に行き、保険料金額を支払う（ステップＳ５５）。また、端子Ｂから第７図の処理に戻る。コンビニエンスストア払いの場合には、集金代行会社コンピュータ３のバーコード配信処理部３２が処理を実行する場合もある。これについては後に説明する。
コンビニエンスストア払いではないと判断された場合には、銀行の店頭における振込みであるか判断する（ステップＳ５７）。なお、以上述べた方法以外の方法を利用する場合には、そのための処理を実施するものとする。銀行の店頭における振込みを行う場合には、代理店専用端末１３では特に処理は必要ない。従って、代理店２００は、銀行の店頭などに設置されているＡＴＭなどに行き、振込みを実施する（ステップＳ５９）。また、端子Ｂから第７図の処理に戻る。
このように代理店専用端末１３を用いれば各種送金方法に対処することができる。なお、代理店ＰＣ１１や携帯電話機１５を使用してもネット振込みなどを行うことは可能であるので、代理店２００が使用する端末が代理店専用端末１３に限定されるわけではない。
また、携帯電話機１５を使用する場合には、たとえば第１１図のような処理を実施する場合もある。集金代行会社コンピュータ３のバーコード配信処理部３２は、送金方法がコンビニエンスストア払いの場合、代理店２００の携帯電話機１５向けのバーコード・データを生成する（ステップＳ６１）。例えば代理店２００が代理店専用端末１３を使用していないことを表すデータおよび携帯電話機１５のメールアドレスが予め登録されている場合に、例えばバーコード配信処理部３２を起動するようにしても良い。また、バーコード配信処理部３２は、代理店コードに対応して登録されている携帯電話機宛に、生成したバーコード・データを配信するためのＵＲＬ（Uniform Resource Locator）が埋め込まれたメールを送信する（ステップＳ６３）。代理店２００の携帯電話機１５は、集金代行会社コンピュータ３から所定のＵＲＬが埋め込まれたメールを受信し、表示装置に表示する（ステップＳ６５）。代理店２００が、メールに埋め込まれているＵＲＬをクリックすると、携帯電話機１５は当該ＵＲＬへアクセスする（ステップＳ６７）。バーコード配信処理部３２は、携帯電話機１５からのアクセスに応じて、ステップＳ６１において生成されたバーコード・データを携帯電話機１５に送信する（ステップＳ６９）。携帯電話機１５は、バーコード・データを集金代行会社コンピュータ３から受信し、表示装置に表示する（ステップＳ７１）。そして、代理店２００は、当該携帯電話機１５を持ってコンビニエンスストアに行き、コンビニエンスストアではバーコード・スキャナにより携帯電話機１５の表示装置に表示されたバーコード・データをスキャンする（ステップＳ７３）。これにより、従来から存在しているコンビニエンスストアによる料金徴収スキームに載せることができるようになる。なお、一旦ＵＲＬが埋め込まれたメールを送信するようにしているが、携帯電話機１５が対応していればバーコード・データが埋め込まれたメールを送信するようにしても良い。また、バーコード表示についてはＪａｖａ（Sun Microsystems社の商標）アプレットにて行う方法もある。
次に、保険会社コンピュータ５が計上データを受信した後の処理について第１２図乃至第１４図を用いて説明する。保険会社コンピュータ５は、例えば代理店ＰＣ１１から保険契約の申込みに係る計上データを受信し、保険契約ＤＢ５２に登録する（ステップＳ８１）。計上データについては、例えば保険料などのデータチェックを実施した後に、問題なければ保険契約ＤＢ５２に登録する。そして、保険会社コンピュータ５は、任意のタイミングで又は所定の周期で、新規登録を行った計上データを集金代行会社コンピュータ３に送信する（ステップＳ８３）。集金代行会社コンピュータ３は、保険会社コンピュータ５から計上データを受信し、例えば入金管理ＤＢ４１に登録する（ステップＳ８５）。入金管理ＤＢ４１には例えば第１３Ａ図及び第１３Ｂ図のようなデータが格納される。第１３Ａ図の例では、契約者名、証券番号、保険種類、保険料、払込方法、保険始期日、申込受付日、計上日、代理店コード（又は代理店名）などの計上データに含まれるデータが入金管理ＤＢ４１に登録される。また、第１３Ｂ図の例では、第１３Ａ図の１つのレコードに対応して、支払期日、自動契約解除日、入金日、保険金支払可否フラグ（支払期日までのフラグと自動契約解除日までのフラグ）と解除フラグなどが設定されるようになっている。
そして入金照合処理部３４は、入金照合済みの入金予定データと計上データとのマッチング処理を実施する（ステップＳ８７）。例えば、入金予定データに含まれる証券番号と同じ証券番号を含む計上データを検索する。そして、入金予定データに含まれる証券番号と同じ証券番号を含む計上データを検出した場合には、さらに入金予定データに含まれる保険料金額と、計上データに含まれる保険料金額とが同じであるか判断する。この２つの条件が満たされた場合には、入金予定データに含まれる領収日のデータを、入金管理ＤＢ４１の計上データを登録するテーブル（第１３Ｂ図）の入金日の欄に登録する。また、保険金支払可否フラグについては、全ての期間につき支払可にセットする（ステップＳ８９）。なお、対応する入金予定データがない計上データについては、第３及び第４の実施例で説明した、顧客１００が直接集金代行会社３００に送金する場合において、入金データとのマッチング処理に用いられる。従って、入金予定データに含まれる証券番号により対応関係が見出されない計上データについては照合失敗扱いをしない。但し、証券番号が一致するが保険料金額が一致しない入金予定データと計上データとについてはマッチングが取れないものとして取り扱うため、そのような入金予定データと計上データとを抽出し、保険会社コンピュータ５に送信する（ステップＳ９３）。なお、入金予定データのみを送信するようにしても良い。これは入金予定データに証券番号が含まれているため、この証券番号により保険会社コンピュータ５では計上データを取得することができるためである。
保険会社コンピュータ５は、集金代行会社コンピュータ３からマッチングが取れない入金予定データ及び計上データを受信すると、記憶装置に格納する（ステップＳ９５）。後に保険会社コンピュータ５は、保険会社４００の担当者に当該マッチングの取れない入金予定データ及び計上データを出力し、保険会社４００の担当者は計上データ等の確認を行う（ステップＳ９７）。マッチングが取れないのは、計上データに問題がある場合、入金予定データに問題がある場合のいずれか若しくはその両方である。計上データに問題があれば、計上データを訂正して、保険契約ＤＢ５２に登録し、訂正後の計上データを集金代行会社コンピュータ３に送信する。一方、入金予定データに問題がある場合には、入金予定データについての訂正データを集金代行会社コンピュータ３に送信する（ステップＳ９９）。
集金代行会社コンピュータ３の入金照合処理部３４は、訂正データを受信した場合には、例えば入金管理ＤＢ４１に登録する（ステップＳ１０１）。なお、計上データに訂正がなければ、保険料の追徴又は返戻が発生しており、当該保険料の追徴金又は返戻金の計算を実施する。そして、保険料の精算書のデータを生成して、例えば通知データ格納部４４に格納する（ステップＳ１０３）。後に、例えば精算書のデータを印刷して顧客１００に郵送するなどの手続きを行う。また、返戻金があれば例えば口座振替依頼書により取得した顧客の銀行口座データを用いて、返金処理を実施するようにしてもよい。また、追徴金があれば当該追徴金についての入金予定データを生成し、入金管理ＤＢ４１に登録しておく。そして、入金データとのマッチング処理を実施する（ステップＳ１０５）。追徴金がある場合の保険金支払可否フラグのセットについては、各種の取り扱い方法があるが、この場合には代理店２００が間違っていることになるので、最初の領収日に受領したものとして取り扱う場合もある。
なお、集金代行会社コンピュータ３の代理店管理部３８は、第１図及び第２図で説明したように、例えば１月に一回など所定の周期で、入金照合済みの入金予定データと計上データとのマッチングが取れた保険契約について代理店手数料を計算し、代理店毎に代理店手数料の明細データを生成し、例えば通知データ格納部４４に格納する（第１４図：ステップＳ１１１）。明細データは、ネットワーク１を介して代理店２００に通知するようにしても良いし、印刷してから送付しても良い。
さらに、精算処理部４０は、受領した保険料から代理店手数料及び集金代行会社３００の手数料を差し引いた金額を計算し、保険会社４００に支払う精算金額のデータとして、例えば通知データ格納部４４に格納する（ステップＳ１１３）。また、保険会社４００向けの明細データを生成して、ネットワーク１を介して送信するようにしてもよいし、印刷して送付しても良い。
また、集金代行会社３００は、例えばコールセンタなどにおいて保険契約の異動を受け付ける機能を有する場合もあり、その場合には例えば集金関連処理部３７は、保険契約の異動データの入力を受け付け、入金管理ＤＢ４１などに異動データを登録する（ステップＳ１１５）。そして、保険会社コンピュータ５に当該異動データを送信する（ステップＳ１１７）。保険会社コンピュータ５は、集金代行会社コンピュータ３から異動データを受信すると、所定の確認処理の後に例えば保険契約ＤＢ５２に異動データを登録する（ステップＳ１１９）。また、異動によって保険料の追徴金又は返戻金が生ずる場合がある。集金関連処理部３７は、保険料の追徴金又は返戻金の金額を計算し、さらに精算書のデータを生成して例えば通知データ格納部４４に格納する（ステップＳ１２１）。その後例えば精算書を印刷して、顧客１００に送付する。返戻金がある場合には、例えば口座振替依頼書で特定される口座に返金する。追徴金がある場合には、精算書にて追徴金分の送金を求める。入金予定データを生成して、入金管理ＤＢ４１に登録する場合もある。
このような処理により集金代行会社３００を利用する場合であっても、保険料を即時に精算する手続きがスムーズに進む。
７．実施例３における処理内容
次に第６図に示したシステムの第３の実施例における処理フローを第１５図乃至第１７図を用いて説明する。
代理店２００は、顧客１００から保険契約の申し込みを受け付けると、代理店ＰＣ１１などにより計上データを生成し、代理店ＰＣ１１などに保険会社コンピュータ５へ送信させる。保険会社コンピュータ５は、代理店ＰＣ１１などから計上データを受信すると、計上処理にて保険契約ＤＢ５２に登録する。また、保険料の集金代行を依頼するため、保険契約ＤＢ５２に新規に登録された計上データを所定の周期で又は任意のタイミングで集金代行会社コンピュータ３に送信する。集金代行会社コンピュータ３は、保険会社コンピュータ５から計上データを受信すると、入金管理ＤＢ４１に登録する（ステップＳ１３１）。例えば第１３Ａ図の部分のデータが格納される。また、期日設定処理部３５は、確認すべき期日として支払期日と自動契約解除日を、保険始期日、保険種類、払込方法（一括払い、月払い、半年払いなど）を基に設定し、入金管理ＤＢ４１の、例えば第１３Ｂ図の部分に登録する（ステップＳ１３３）。例えば長期の保険の場合には保険始期日から３０日、短期の場合には保険始期日から１５日若しくは７日というように支払期日を設定する。なおこれは一括払い又は分割払いの最初の保険料の支払期日であり、分割払いの二度目以降の保険料については各分割期間の最初の日から所定の日数後を支払期日として別途設定する。長期の保険の例としては一年以上の保険期間を有する自動車保険や火災保険などが、また短期の保険の例では一年未満の旅行傷害保険などが挙げられる。この場合、支払期日は保険契約データに含まれる保険期間若しくは保険種目に応じて設定されることになる。また、計上データに含まれるその他の属性に応じて支払期日を設定しても良い。例えば契約締結日を基準に支払期限を設定する場合もある。
また、集金代行会社コンピュータ３は、金融機関コンピュータ７から例えば入金データ格納部７１に格納された入金データを所定の周期で又は任意のタイミングで受信し、入金データ格納部４２に格納する（ステップＳ１３５）。入金照合処理部３４は、入金データ格納部４２に新たな入金データが格納されると、各入金がいずれの保険契約に対応するのかということを決定する。このために、入金データに含まれる入金者名及び入金金額のデータを、計上データに含まれる契約者名及び保険料のデータとの照合に用いる。なお、入金データにさらに証券番号等のデータが含まれていればそれを用いればよい。入金データと計上データの対応付けが特定された場合には、入金データに含まれる入金日のデータを入金管理ＤＢ４１（第１３Ｂ図の部分）に登録する（ステップＳ１３７）。
集金代行会社コンピュータ３の期限確認処理部３６は、所定の周期又は任意のタイミングで、各保険契約について、入金日又は未入金の場合には処理日と、支払期日及び自動契約解除日とを比較する。そして、入金日が支払期日までの日付である場合には、支払期日まで及び自動契約解除日までの保険金支払可否フラグを「１」にセットする。すなわち、保険金支払を可とする。未入金である場合には処理日が支払期日までの日付である場合には、支払期日までの保険金支払可否フラグを「０」にセットする。すなわち、保険金支払を保留とする。また、未入金である場合に処理日が支払期日以降自動契約解除日までの日付である場合には、支払期日までの保険金支払可否フラグを「２（不可）」にセットし、自動契約解除日までの保険金支払可否フラグを「０」にセットする。入金日が支払期日以降自動契約解除日までの日付である場合には、支払期日までの保険金支払可否フラグを「２」にセットし、自動契約解除日までの保険金支払可否フラグを「１」にセットする。自動契約解除日以降も未入金である場合には、支払期日まで及び自動契約解除日までの保険金支払可否フラグを「２」にセットする（ステップＳ１３９）。この段階で各保険契約の証券番号と保険金支払可否フラグの内容と入金されていれば入金日とを別途保険金支払可否データとして生成し、例えば通知データ格納部４４に格納するようにしてもよい。そして、集金代行会社コンピュータ３の期限確認処理部３６は、入金管理ＤＢ４１から、保険契約の証券番号と保険金支払可否フラグの内容と入金されていれば入金日のデータを含む保険金支払可否データを保険会社コンピュータ５に送信する（ステップＳ１４１）。
保険会社コンピュータ５は、集金代行会社コンピュータ３から保険金支払可否データを受信すると、例えば支払状況管理ＤＢ５３等の記憶装置に格納し、後に必要になった時点で参照する。すなわち、事故等が発生した場合に、保険金の支払い可否を例えば事故日で判断する。
このような処理を実施することにより、保険会社は、事故発生時点を特定できれば、入金を管理していなくとも集金代行会社コンピュータ３からの情報に基づき保険金を支払っても良いのか、又は支払ってはいけないのか、若しくは、その時点では保留状態なのかを容易に判断することができる。
集金代行会社コンピュータ３の期限確認処理部３６は、また第１６図に示すような処理を実施する。すなわち、入金管理ＤＢ４１を検索して、自動契約解除日までの日付で入金日が記録されていない保険契約を特定する（ステップＳ１４３）。そして、特定された保険契約について、入金管理ＤＢ４１において解除フラグをオン（例えば「１」）にセットすると共に、証券番号等を含む自動解除契約リストを構成し、保険会社コンピュータ５に送信する（ステップＳ１４５）。保険会社コンピュータ５は、集金代行会社コンピュータ３から自動解除契約リストを受信すると、例えば支払状況管理ＤＢ５３などの記憶装置に格納する。そして、後に保険契約ＤＢ５２のデータに、自動解除保険リストに列挙された保険契約の自動契約解除を登録する。ここでは、自動契約解除という重要な情報については別途自動解除契約リストとして構成して、保険会社４００側に通知するものである。
また、集金代行会社コンピュータ３の契約抽出処理部３９は、例えば第１７図に示すような、不正が行われていないか確認するため詳細な調査が必要な保険契約を特定する処理を実施する。すなわち、保険会社コンピュータ５から、所定の周期で又は任意のタイミングで、証券番号と事故日と事故受付日とを含む事故受付情報を受信し、事故受付情報ＤＢ４３などの記憶装置に格納する（ステップＳ１４７）。そして、事故のあった各保険契約につき、入金管理ＤＢ４１から計上データを読み出し、以下の処理を実施する。まず、事故日が申込受付日（又は計上日）の所定日数以上後になっているか判断する（ステップＳ１４９）。申込受付日は、例えば保険会社コンピュータ５が、代理店ＰＣ１１から保険契約の計上データを受信した日や、代理店２００にてデータ入力せずに保険会社４００側で計上データの生成を行う場合には申込書を代理店２００から受領した日、若しくは別途手続きとして代理店２００に義務付けている保険会社４００への通知の受領日等を示す。計上日は、例えば保険契約ＤＢ５２に登録した日であるが、計上日と申込受付日を区別しない場合もある。事故日から所定日数以上前に代理店２００等から申し込みの通知があった場合には、不正を行っている可能性は無く、ここでは調査対象とはせずに処理を終了する。
一方、事故日が申込受付日の所定日数以上後とは言えない場合には、保険始期日が計上日以降であるか判断する（ステップＳ１５１）。計上日が保険始期日より後である場合には、事務的な遅れなのか、不正のために計上日が遅れているのかを確認する必要がある。よって、調査対象契約としてリストアップするため、当該保険契約の証券番号を例えば通知データ格納部４４などの記憶装置に格納する（ステップＳ１５５）。一方、保険始期日が計上日以降である場合には、他の所定の条件を満たすかを確認する（ステップＳ１５３）。他の所定の条件とは、例えば顧客１００（保険契約者）がブラックリストに載っていないかといった事項であったり、事故日が保険始期日以降直ぐ（例えば数日以内）であるかという事項、保険料の請求初日、入金日、計上日及び申込受付日等のうち最先日が事故受付日より後であるかといった事項であってもよい。もし、所定の条件を満たしている場合には調査対象契約として特定し、リストに追加する（ステップＳ１５５）。所定の条件を満たしていない場合には、処理を終了する。リストアップされた保険契約の証券番号等は、集金代行会社コンピュータ３から保険会社コンピュータ５に送信される。保険会社コンピュータ５は、集金代行会社コンピュータ３から受信した調査対象の保険契約のデータを、記憶装置に格納し、後の調査に使用する。
このような処理を実施することにより、集金代行会社３００から、不正などの不適切な保険契約の調査のための情報を取得することができ、保険会社は調査のための手数を減らすことができる。
なお、各コンピュータ間の通信はネットワークを経由しなくとも良い。例えば、磁気テープやその他の記録媒体を用いてデータを交換するようにしても良い。なお、以上で示した不正有無の確認フローはあくまでも例示であり、事故日、申込受付日又は計上日、及び保険始期日等の日付の対応状況やその他の条件を任意に組み合わせて照合することで、不正有無の確認を行うことができる。
８．実施例４の処理内容
次に第６図に示したシステムの第４の実施例における処理フローを第１８図乃至第２１図を用いて説明する。
代理店２００は、顧客１００から保険契約の申し込みを受け付けると、代理店ＰＣ１１等により計上データを生成し、代理店ＰＣ１１等に保険会社コンピュータ５へ送信させる。保険会社コンピュータ５は、代理店ＰＣ１１等から計上データを受信すると、計上処理にて保険契約ＤＢ５２に登録する。また、保険料の集金代行を依頼するため、保険契約ＤＢ５２に新規に登録された計上データを所定の周期で又は任意のタイミングで集金代行会社コンピュータ３に送信する。集金代行会社コンピュータ３は、保険会社コンピュータ５から計上データを受信すると、入金管理ＤＢ４１に登録する（ステップＳ１６１）。第１３Ａ図の部分のデータが格納される。また、期日設定処理部３５は、確認すべき期日として支払期日と自動契約解除日を、保険始期日、保険種類、払込方法（一括払い、月払い、半年払いなど）を基に設定し、入金管理ＤＢ４１に登録する（ステップＳ１６３）。なお、実施例４では、第１３Ｂ図のデータの代わりに第１９図に示すようなデータを入金管理ＤＢ４１に登録するようにする。第１９図に示す例では、各保険契約について、支払期日、自動契約解除日、入金日、譲渡フラグ、督促フラグ、解除フラグ、要回収金額のデータ等を登録するようになっている。
また、集金代行会社コンピュータ３は、金融機関コンピュータ７から入金データ格納部７１に格納された入金データを所定の周期で又は任意のタイミングで受信し、入金データ格納部４２に格納する（ステップＳ１６５）。入金照合処理部３４は、入金データ格納部４２に新たな入金データが格納されると、各入金がいずれの保険契約に対応するのかということを決定する。このために、入金データに含まれる入金者名及び入金金額のデータを、計上データに含まれる契約者名及び保険料のデータとの照合に用いる。なお、入金データにさらに証券番号等のデータが含まれていればそれを用いればよい。入金データと計上データの対応付けが特定された場合には、入金データに含まれる入金日のデータを入金管理ＤＢ４１（第１９図の部分）に登録する（ステップＳ１６７）。
そして、集金代行会社コンピュータ３の期限確認処理部３６は、期限確認処理を実施する（ステップＳ１６９）。この期限確認処理については後に詳述する。そして、この期限確認処理にて生成された債権譲渡の対象となる契約リスト及び契約解除リストを、集金代行会社コンピュータ３から保険会社コンピュータ５に送信する（ステップＳ１７１）。保険会社コンピュータ５は、集金代行会社コンピュータ３から、債権譲渡契約リスト及び契約解除リストを受信すると、支払状況管理ＤＢ５３等の記憶装置に格納する。そして、債権譲渡契約リストに載っている保険契約については、原則として保険始期日までに入金があったものとして取り扱う。債権譲渡が行われたことを示すデータを保険契約ＤＢ５２に登録するようにしても良い。また、契約解除リストに載っている保険契約については、解除日等を保険契約ＤＢ５２に登録する。
このような処理を実施することにより、保険会社は入金日について全く管理することなく、基本的に全件保険始期日までに入金があったものとして取り扱うことができるようになる。なお、最終的に保険料が支払われなかった場合であっても、保険会社側では通常の解除として取り扱うことが可能になる。但し、保険料債権の譲渡先である集金代行会社３００のために事故情報等を通知する。集金代行会社３００は、保険料債権を譲り受け、その債権の回収を行うことにより、収益を上げることができる。
次に第２０図を用いて実施例４における期限確認処理部３６の処理を説明する。この処理については、所定の周期又は任意のタイミングで実施される。まず、１つの未処理のレコードを入金管理ＤＢ４１から読み出す（ステップＳ１７３）。そして、当該未処理のレコードに入金日が含まれるか否かで未入金であるかを判断する（ステップＳ１７５）。もし、入金されていれば、ステップＳ２０５に移行する。すなわち、全てのレコードについて処理したかを判断し、もし全てのレコードについて処理した場合には処理を終了し、未処理のレコードがあればステップＳ１７３に戻る（ステップＳ２０５）。
もし、未入金である場合には、処理日が保険始期日（又は入金日登録にかかる期間を考慮して、保険始期日＋入金日登録にかかる期間、もしくは保険始期日以前の任意に設定する日としてもよい）を経過したか判断する（ステップＳ１７７）。もし、処理日が保険始期日を経過していないようであればステップＳ２０５に移行する。一方、処理日が保険始期日を経過していれば、第１９図に示した譲渡フラグが「１」にセットされているか判断する（ステップＳ１７９）。もし、譲渡フラグが「０」にセットされていれば、入金管理ＤＢ４１において譲渡フラグを「１」にセットし（ステップＳ１８１）、保険料債権の譲渡に係る契約リスト（債権譲渡契約リスト）に証券番号等の情報を追加する（ステップＳ１８３）。例えば債権譲渡契約リストは通知データ格納部４４に格納される。また、保険会社４００と集金代行会社３００の取り決めに従って当該保険料から計算される要回収金額を入金管理ＤＢ４１に登録する（ステップＳ１８５）。要回収金額については保険料そのものであってもよい。そしてステップＳ２０５に移行する。
このようにすることにより、保険料の債権譲渡がなされた保険契約を特定することが容易になる。また、保険会社への通知もこの債権譲渡契約リストにより行うことができる。また、要回収金額も登録されるので、債権の回収に利用することもできる。
もし、譲渡フラグが「１」に設定済みである場合には、第１９図に示した督促フラグが「１」に設定されているかを判断する（ステップＳ１８７）。もし、督促フラグが「１」に設定されていない場合には、処理日が支払期日（又は入金日登録にかかる期間を考慮して、支払期日＋入金日登録にかかる期間）を経過しているか判断する（ステップＳ１８９）。もし、経過していないようであればステップＳ２０５に移行する。一方、処理日が支払期日を経過している場合には、督促フラグを「１」にセットし（ステップＳ１９１）、督促リストに証券番号等の情報を登録する（ステップＳ１９３）。督促リストは例えば通知データ格納部４４に格納される。そしてステップＳ２０５に移行する。
このようにすることにより、支払期限を過ぎても保険料の支払いが行われていない保険契約を特定することが容易になる。なお、要回収金額を更新するようなステップを追加しても良い。支払期日が守られないため、遅延手数料などを徴収する場合である。
もし、督促フラグが「１」に設定済みである場合には、第１９図に示した解除フラグが「１」に設定されているか判断する（ステップＳ１９５）。もし、解除フラグが既に「１」にセットされている場合にはステップＳ２０５に移行する。一方、解除フラグが「０」に設定されている場合には、処理日が自動契約解除日（又は入金日登録にかかる期間を考慮して、自動契約解除日＋入金日登録にかかる期間とする場合もある。）を経過したか判断する（ステップＳ１９７）。もし、まだ処理日が自動契約解除日を経過していなければ、ステップＳ２０５に移行する。処理日が自動契約解除日を経過していれば、解除フラグを「１」にセットし（ステップＳ１９９）、契約解除リストに証券番号等の情報を登録する（ステップＳ２０１）。契約解除リストは例えば通知データ格納部４４に格納される。そして、要回収金額を更新する（ステップＳ２０３）。契約解除による解除返戻金があれば、要回収金額＝要回収金額−解除返戻金＋手数料として更新登録する。但し、解除返戻金はない場合もあり、その場合には手数料だけ考慮するようにしても良い。そしてステップＳ２０５に移行する。
このような処理を実行することにより、自動解除となる契約を保険会社に通知することができるようになる。また、集金代行会社３００にとっては、自動解除となった保険契約については、回収できなければ自社の損失となるため、その特定は非常に重要である。
次に、集金代行会社コンピュータ３の集金関連処理部３７の処理について第２１図を用いて説明する。集金関連処理部３７は、保険会社コンピュータ５から事故受付情報を受信し、事故受付情報ＤＢ４３に格納する（ステップＳ２０７）。事故受付情報には、例えば証券番号、事故受付日、事故日などの情報が含まれる。そして、事故の発生した保険契約のうち、譲渡フラグ、督促フラグ、解除フラグのいずれかが「１」にセットされた保険契約を入金管理ＤＢ４１を検索することにより特定し、要注意契約リストに登録する（ステップＳ２０９）。例えば要注意契約リストは通知データ格納部４４に格納される。入金日が登録されているかを併せて確認するようにしても良い。要注意契約リストについては、証券番号や事故受付日、事故日などが含まれる。
要注意契約リストに登録された契約については、保険料を支払わずに保険金を取得するような事態にならないようにする必要があり、特に注意が必要である。
以上本発明の実施例を示したが、本発明はこれに限定されない。例えば、第６図に示すように各コンピュータがネットワークに接続していなくともよい。データの受け渡しは、例えば磁気テープその他の記録媒体を用いても良い。
また、第６図では保険会社コンピュータ５を１台のコンピュータで構成する例を示しているが、複数のコンピュータで構成するようにしてもよい。集金代行会社コンピュータ３、金融機関コンピュータ７、信販会社コンピュータ９も同様である。集金代行会社コンピュータ３の各機能ブロックは、単に説明の都合上示しているものであり、具体的なプログラムモジュールと直接対応するとは限らない。データベースなどの記憶装置の構成についても第６図は一例であって、他のデータ保持方法を採用しても良い。
また、集金代行会社コンピュータ３が管理する入金管理ＤＢ４１を、例えば顧客１００、保険会社４００、代理店２００の所定のパスワードを有する者が参照できるように例えばインターネットで公開することも可能である。顧客１００については、自己の保険契約のデータについてのみ参照できる。代理店２００も自己が取り扱った保険契約のデータについてのみ参照できる。
さらに、集金代行会社コンピュータ３においては、第４の実施例において督促フラグが「１」に設定されている保険契約について、地域や金額、督促状況など所定の基準にて分類し、担当する集金人に集金を委託するための分類処理を実施するようにしても良い。
第３及び第４の実施例については、保険会社４００からの依頼に基づき集金代行を行う又は債権譲渡を行うような構成を示したが、顧客１００から例えば保険契約申込時に、ノンカード立替払い依頼があった場合には、その依頼に基づき立替払いを行うような構成とすることも可能である。
また、期日設定処理部３５、期限確認処理部３６、契約抽出処理部３９、精算処理部４０など図６に示した集金代行会社コンピュータ３の各処理部は、集金代行会社３００ではなく、保険会社４００の保険会社コンピュータ５に備えて、期日設定、期限確認、契約抽出、精算処理などの各種処理を保険会社４００側で実施するような構成にすることも可能である。この場合、例えば第３及び第４の実施例において、保険会社コンピュータ５に備えられた期日設定処理部３５が計上データに基づいて支払期日と自動契約解除日を設定し、保険始期日、保険種類、払込方法を基に、入金管理ＤＢ４１における第１３Ｂ図に示した部分の内容を登録する。さらに、保険会社コンピュータ５に備えられた期限確認処理部３６が、集金代行会社コンピュータ３から入金日及び未入金などの入金情報を取得して、その入金情報に基づき、第１３Ｂ図に示したテーブルにおける保険金支払可否フラグや解除フラグなどをセットする。また、保険会社コンピュータ５に備えられた契約抽出処理部３９が、事故受付情報ＤＢ５１から証券番号と事故日と事故受付日とを含む事故受付情報を抽出し、その情報と計上データを基に、例えば事故受付日と申込受付日との関係を判断し、詳細な調査が必要となる保険契約を特定するための処理を実施する。また、保険会社コンピュータ５に備えられた精算処理部４０が代理店手数料及び集金代行会社３００の手数料を算出する。
この場合、保険会社コンピュータ５は、期日設定処理部３５が設定した期日等、期日確認処理部３６によりセットされた保険金支払可否フラグや解除フラグなどの情報を、集金代行会社コンピュータ３に送信する。また、契約抽出処理部３９が特定した詳細な調査が必要となる保険契約に関する情報や精算に係るデータを集金代行会社コンピュータ３や、代理店専用端末１３、代理店ＰＣ１１又は代理店携帯電話機１５など代理店２００側の装置に送信する。
また、期日設定、期限確認、契約抽出、精算処理等の各処理を集金代行会社コンピュータ３と保険会社コンピュータ５とが各処理を分担の上協働して実施しても良い。その場合、それぞれ各種処理を担当したコンピュータから他のコンピュータに対して処理結果に関する情報を送信し、集金代行会社コンピュータ３と保険会社コンピュータ５は、送信された情報に基づいてそれぞれにおいて必要な処理を実施する。
また集金代行会社３００が保険会社４００と異なる別組織として例示したが、保険会社の一部門が集金代行会社となってもよく、組織の態様は問わない。さらに各処理フローも例示であり、上で述べたものに限定されるものではない。
【図面の簡単な説明】
【図１】第１図は、本発明の第１の実施例に係る手続き及び処理のフロー図である。
【図２】第２図は、本発明の第２の実施例に係る手続き及び処理のフロー図である。
【図３】第３図は、本発明の第３の実施例に係る手続き及び処理のフロー図である。
【図４】第４図は、顧客と集金代行会社とのやり取りの詳細フロー図である。
【図５】第５図は、本発明の第４の実施例に係る手続き及び処理のフロー図である。
【図６】第６図は、本発明の実施例におけるシステム概要図である。
【図７】第７図は、本発明の第１及び第２の実施例における処理フロー（第１の部分）を示す図である。
【図８】第８図は、入金予定データの一例を示す図である。
【図９】第９図は、入金データの一例を示す図である。
【図１０】第１０図は、本発明の第１及び第２の実施例における処理フロー（第２の部分）を示す図である。
【図１１】第１１図は、本発明の第１及び第２の実施例における処理フロー（第３の部分）を示す図である。
【図１２】第１２図は、本発明の第１及び第２の実施例における処理フロー（第４の部分）を示す図である。
【図１３Ａ】第１３Ａ図は、入金管理データベースに格納されるデータの一部の例を示す図である。
【図１３Ｂ】第１３Ｂ図は、入金管理データベースに格納されるデータの一部の例を示す図である。
【図１４】第１４図は、本発明の第１及び第２の実施例における処理フロー（第５の部分）を示す図である。
【図１５】第１５図は、本発明の第３の実施例における処理フロー（第１の部分）を示す図である。
【図１６】第１６図は、本発明の第３の実施例における処理フロー（第２の部分）を示す図である。
【図１７】第１７図は、本発明の第３の実施例における処理フロー（第３の部分）を示す図である。
【図１８】第１８図は、本発明の第４の実施例における処理フロー（第１の部分）を示す図である。
【図１９】第１９図は、本発明の第４の実施例において入金管理データベースに格納されるデータの一部の例を示す図である。
【図２０】第２０図は、本発明の第４の実施例における処理フロー（第２の部分）を示す図である。
【図２１】第２１図は、本発明の第４の実施例における処理フロー（第３の部分）を示す図である。

Claims (4)

1. 保険料を保険始期日より後に支払うことができる保険契約に関するデータを保持する第１のコンピュータと保険料の入金データを保持する第２のコンピュータとにネットワークを介して接続されており、期日設定処理部と入金照合処理部と期限確認処理部と入金管理データ格納部とを有する第３コンピュータにより実行される、保険料の入金管理に関する情報処理方法であって、
   前記第１のコンピュータから、保険契約の証券番号と保険契約者名と保険種別と保険料の納付なしに設定される保険始期日と支払方法と保険料の金額とを少なくとも含み且つ保険料が未入金である保険契約に関する計上データを受信すると、前記期日設定処理部が、前記保険始期日から前記保険種別及び前記支払方法に応じて予め定められている第１の日数後の支払期日と当該支払期日から所定の猶予期間後の自動契約解除日とを決定し、前記計上データと前記支払期日と前記自動契約解除日とを前記入金管理データ格納部に格納するステップと、
   前記第２のコンピュータから前記保険契約の証券番号と前記保険契約者名との少なくともいずれかと支払金額と入金日とを含む、保険料の入金データを受信すると、前記入金照合処理部が、前記入金データからいずれの保険契約についての入金データであるか特定し、特定された保険契約の前記保険料の金額と支払金額が一致する場合には、特定された前記保険契約の証券番号に対応付けて前記入金管理データ格納部に前記入金日を格納するステップと、
   前記期限確認処理部が、前記入金管理データ格納部にデータが格納されている各保険契約について、（Ａ）前記入金日が設定されている場合には、（Ａ−ａ）当該入金日が前記支払期日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金を支払うことを表す第１データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金を支払うことを表す第２データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ａ−ｂ）当該入金日が前記支払期日の後前記自動契約解除日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金を支払わないことを表す第３データと前記第２データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ）前記入金日が設定されていない場合には、（Ｂ−ａ）処理日が前記支払期日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金の支払が保留されることを表す第４データを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ−ｂ）処理日が前記支払期日の後前記自動契約解除日以前であれば前記第３データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金の支払が保留されることを表す第５データを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ−ｃ）処理日が前記自動契約解除日より後であれば前記第３データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金を支払わないことを表す第６データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納するステップと、
   を含む情報処理方法。
2. 前記第３コンピュータが、契約抽出処理部及び通知データ格納部をさらに有しており、
   前記計上データが計上日又は申込受付日をさらに含み、
   前記第２のコンピュータから事故日を含む事故受付情報を受信した場合、前記契約抽出処理部が、前記事故日が前記申込受付日又は前記計上日の所定日数以内であり且つ前記保険始期日が前記計上日又は前記申込受付日より前である保険契約を前記入金管理データ格納部から抽出し、前記通知データ格納部に格納するステップ
   をさらに含む請求項１記載の情報処理方法。
3. 保険料を保険始期日より後に支払うことができる保険契約に関するデータを保持する第１のコンピュータと保険料の入金データを保持する第２のコンピュータとにネットワークを介して接続されており、入金管理データ格納部を有する第３コンピュータに、
   前記第１のコンピュータから、保険契約の証券番号と保険契約者名と保険種別と保険料の納付なしに設定される保険始期日と支払方法と保険料の金額とを少なくとも含み且つ保険料が未入金である保険契約に関する計上データを受信すると、前記保険始期日から前記保険種別及び前記支払方法に応じて予め定められている第１の日数後の支払期日と当該支払期日から所定の猶予期間後の自動契約解除日とを決定し、前記計上データと前記支払期日と前記自動契約解除日とを前記入金管理データ格納部に格納するステップと、
   前記第２のコンピュータから前記保険契約の証券番号と前記保険契約者名との少なくともいずれかと支払金額と入金日とを含む、保険料の入金データを受信すると、前記入金データからいずれの保険契約についての入金データであるか特定し、特定された保険契約の前記保険料の金額と支払金額が一致する場合には、特定された前記保険契約の証券番号に対応付けて前記入金管理データ格納部に前記入金日を格納するステップと、
   前記入金管理データ格納部にデータが格納されている各保険契約について、（Ａ）前記入金日が設定されている場合には、（Ａ−ａ）当該入金日が前記支払期日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金を支払うことを表す第１データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金を支払うことを表す第２データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ａ−ｂ）当該入金日が前記支払期日の後前記自動契約解除日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金を支払わないことを表す第３データと前記第２データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ）前記入金日が設定されていない場合には、（Ｂ−ａ）処理日が前記支払期日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金の支払が保留されることを表す第４データを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ−ｂ）処理日が前記支払期日の後前記自動契約解除日以前であれば前記第３データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金の支払が保留されることを表す第５データを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ−ｃ）処理日が前記自動契約解除日より後であれば前記第３データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金を支払わないことを表す第６データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納するステップと、
   を実行させるためのプログラム。
4. 保険料を保険始期日より後に支払うことができる保険契約に関するデータを保持する第１のコンピュータと保険料の入金データを保持する第２のコンピュータとにネットワークを介して通信を行う情報処理装置であって、
   入金管理データ格納部と
   前記第１のコンピュータから、保険契約の証券番号と保険契約者名と保険種別と保険料の納付なしに設定される保険始期日と支払方法と保険料の金額とを少なくとも含み且つ保険料が未入金である保険契約に関する計上データを受信すると、前記保険始期日から前記保険種別及び前記支払方法に応じて予め定められている第１の日数後の支払期日と当該支払期日から所定の猶予期間後の自動契約解除日とを決定し、前記計上データと前記支払期日と前記自動契約解除日とを前記入金管理データ格納部に格納する期日設定処理部と、
   前記第２のコンピュータから前記保険契約の証券番号と前記保険契約者名との少なくともいずれかと支払金額と入金日とを含む、保険料の入金データを受信すると、前記入金照合処理部が、前記入金データからいずれの保険契約についての入金データであるか特定し、特定された保険契約の前記保険料の金額と支払金額が一致する場合には、特定された前記保険契約の証券番号に対応付けて前記入金管理データ格納部に前記入金日を格納する入金照合処理部と、
   前記入金管理データ格納部にデータが格納されている各保険契約について、（Ａ）前記入金日が設定されている場合には、（Ａ−ａ）当該入金日が前記支払期日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金を支払うことを表す第１データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金を支払うことを表す第２データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ａ−ｂ）当該入金日が前記支払期日の後前記自動契約解除日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金を支払わないことを表す第３データと前記第２データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ）前記入金日が設定されていない場合には、（Ｂ−ａ）処理日が前記支払期日以前であれば前記保険始期日から前記支払期日までに事故があった場合に保険金の支払が保留されることを表す第４データを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ−ｂ）処理日が前記支払期日の後前記自動契約解除日以前であれば前記第３データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金の支払が保留されることを表す第５データを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納し、（Ｂ−ｃ）処理日が前記自動契約解除日より後であれば前記第３データと前記支払期日の後前記自動契約解除日までに事故があった場合に保険金を支払わないことを表す第６データとを当該保険契約の証券番号に対応付けて前記入金管理データ格納部に格納する期限確認処理部と、
   を有する情報処理装置。

Images