(57)【要約】   【課題】  契約者の利便を損なわず、かつ、商品を販売する会社の業務負担を軽減しつつ、適切に決済できる。  【解決手段】  商品の購入契約に伴い、入金予定額および契約にかかる商品を特定する情報を含む入金予定データを、入金予定データテーブルのレコードとして記憶する入金予定データ管理部２２と、入力予定データに基づいて作成された払込票を用いた支払にしたがって生成された、入金金額および商品を特定する情報を含む入金済データを、入金済データテーブルのレコードとして記憶する入金済データ管理部２４と、双方のテーブルのレコードを照合して、レコードに関する消込を実行するデータ消込部２６を備え、同じ商品を特定する情報を含む複数のレコードが存在する場合に、複数のレコードに含まれる金額を合算して、合算額を照合することにより消込を実行する。【選択図】  図１
2005084880.tif 000002
【特許請求の範囲】
【請求項１】
商品の購入契約に伴い、入金予定額、および、当該契約にかかる商品を特定する情報を含む入金予定データを、入金予定データテーブルのレコードとして記憶する入金予定データ管理手段と、
前記入力予定データに基づいて作成された、決済者が店舗にて決済額を支払うための払込票を用いた支払にしたがって生成された入金済データであって、入金金額、および、商品を特定する情報を含む入金済データを、入金済データテーブルのレコードとして記憶する入金済データ管理手段と、
前記入金データテーブルのレコードと、入金済データテーブルのレコードとを照合して、レコードに関する消込を実行するデータ消込手段であって、前記入金済データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金金額を合算し、かつ、照合すべき入金予定データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金予定額を合算し、合算額を照合することにより消込を実行するデータ消込手段とを備えたことを特徴とする決済システム。
【請求項２】
前記商品が、保険商品であり、前記商品を特定する情報が、証券番号であり、
さらに、ある保険商品の満期返戻金を、新たな保険商品の契約の保険料に充当するように、入金予定データが、もとの保険商品の証券番号である旧証券番号、当該もとの保険商品の満期返戻金の金額、および、満期返戻金と保険料との差額に対応する差額徴収額とを含み、差額徴収額が入金金額に相当し、かつ、旧証券番号および満期返戻金の金額が含まれる払込票が作成され、かつ、入力済データが、旧証券番号および満期返戻金の金額を含み、
前記データ消込手段が、前記入力済データテーブルのレコード中、入金金額および満期返戻金の金額の総和が、前記入金予定データテーブルの対応するレコード中の入金予定金額に合致するか否かを判断することを特徴とする請求項１に記載の決済システム。
【請求項３】
前記データ消込手段が、少なくとも、前記消込が完了した入金予定のレコードの消込フラグをセットすることを特徴とする請求項１または２に記載の決済システム。
【請求項４】
さらに、データ消込手段が、前記商品の販売者のシステムに対して、ネットワークを介して、前記消込が完了したレコードの情報を通知することを特徴とする請求項１ないし３の何れか一項に記載のシステム。
【請求項５】
商品の購入契約に伴い、入金予定額、および、当該契約にかかる商品を特定する情報を含む入金予定データを、入金予定データテーブルのレコードとして記憶するステップと、
前記入力予定データに基づいて作成された、決済者が店舗にて決済額を支払うための払込票を用いた支払にしたがって生成された入金済データであって、入金金額、および、商品を特定する情報を含む入金済データを、入金済データテーブルのレコードとして記憶するステップと、
前記入金データテーブルのレコードと、入金済データテーブルのレコードとを照合して、レコードに関する消込を実行するステップであって、前記入金済データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金金額を合算し、かつ、照合すべき入金予定データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金予定額を合算し、合算額を照合することにより消込を実行するステップとを、コンピュータに実行させることを特徴とするコンピュータにより読み出し可能な決済プログラム。
【請求項６】
前記商品が、保険商品であり、前記商品を特定する情報が、証券番号であり、
さらに、ある保険商品の満期返戻金を、新たな保険商品の契約の保険料に充当するように、入金予定データが、もとの保険商品の証券番号である旧証券番号、当該もとの保険商品の満期返戻金の金額、および、満期返戻金と保険料との差額に対応する差額徴収額とを含み、差額徴収額が入金金額に相当し、かつ、旧証券番号および満期返戻金の金額が含まれる払込票が作成され、かつ、入力済データが、旧証券番号および満期返戻金の金額を含み、
前記消込を実行するステップにおいて、前記入力済データテーブルのレコード中、入金金額および満期返戻金の金額の総和が、前記入金予定データテーブルの対応するレコード中の入金予定金額に合致するか否かを判断するステップを、前記コンピュータに実行させることを特徴とする請求項５に記載のプログラム。
【請求項７】
前記消込を実行するステップにおいて、少なくとも、前記消込が完了した入金予定のレコードの消込フラグをセットするステップを、前記コンピュータに実行させることを特徴とする請求項５または６に記載のプログラム。
【請求項８】
さらに、消込を実行するステップにおいて、前記商品の販売者のシステムに対して、ネットワークを介して、前記消込が完了したレコードの情報を通知するステップを、前記コンピュータに実行させることを特徴とする請求項５ないし７の何れか一項に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、決済処理を円滑に実行することができるシステムおよびプログラムに関する。
【背景技術】
【０００２】
従来、保険料の支払は、保険代理店の口座に指定の金額を振り込み、或いは、保険代理店の職員に直接、指定の金額を手渡すのが一般的であった。契約者による保険料の支払の利便を高めるために、たとえば、コンビニエンスストアを利用した決済が提案されている。
【０００３】
特許文献１には、火災共済の掛金の払い込みにコンビニエンスストアを利用することが提案されている。この提案では以下の手順にしたがう。
【０００４】
共済会の特約店にて、住宅の賃貸借契約締結と同時に、火災共済の報告書兼申込書を駅訳者が記入する。この報告書兼申込書には管理番号が付されている。
【０００５】
特約店は、コンビニエンスストアでの支払い用の、管理番号の付いた払込票を契約者に手渡す。
【０００６】
特約店は、共済会に、報告書兼申込書をファックスにて送信する。
【０００７】
共済会は、報告書兼申込書の内容を契約データとして、管理番号とともにシステムに入力する。システムにおいては、このデータが記憶される。
【０００８】
契約者は、コンビニエンスストアに払込票を持参し、所定の金額を支払う。
【０００９】
支払われた金額のデータ（払込データ）が、収納代行業者を経て、共済会に送信される。
【００１０】
共済会は、払込データの管理番号と、システムにて記憶された契約データの管理番号とを照合することにより、入金を確認する。
【特許文献１】特開２００２−１８３４４０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、特に、損害保険の分野では、申込内容が変更され、同じ証券番号で複数の申込書が発行される可能性がある。この場合、もとの申込書の金額および新たな申込書の金額の双方が入金されて始めて、入金が確認されることになる。また、保険によっては、満期返戻金の一部が、継続される保険の保険料に充当される場合がある。このような場合にも、契約者の利便が損なわれることない支払、および、適切な入金確認が実現されるのが望ましい。
【００１２】
本発明は、契約者の利便を損なわず、かつ、商品を販売する会社の業務負担を軽減しつつ、適切な決済が可能なシステムおよびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明の目的は、商品の購入契約に伴い、入金予定額、および、当該契約にかかる商品を特定する情報を含む入金予定データを、入金予定データテーブルのレコードとして記憶する入金予定データ管理手段と、前記入力予定データに基づいて作成された、決済者が店舗にて決済額を支払うための払込票を用いた支払にしたがって生成された入金済データであって、入金金額、および、商品を特定する情報を含む入金済データを、入金済データテーブルのレコードとして記憶する入金済データ管理手段と、前記入金データテーブルのレコードと、入金済データテーブルのレコードとを照合して、レコードに関する消込を実行するデータ消込手段であって、前記入金済データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金金額を合算し、かつ、照合すべき入金予定データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金予定額を合算し、合算額を照合することにより消込を実行するデータ消込手段とを備えたことを特徴とする決済システムにより達成される。
【００１４】
本発明によれば、ある商品について複数の払込票が作成された場合であっても、これらで支払われた入金金額を合算して、消込を行なうことができる。特に、損害保険の保険商品のように、申込内容が変更され、同じ証券番号で複数の申込書が発行される可能性がある場合でも、保険商品単位、たとえば、証券番号単位での消込ができる。これにより、保険会社における業務負担を著しく軽減することができる。
【００１５】
好ましい実施態様においては、前記商品が、保険商品であり、前記商品を特定する情報が、証券番号であり、さらに、ある保険商品の満期返戻金を、新たな保険商品の契約の保険料に充当するように、入金予定データが、もとの保険商品の証券番号である旧証券番号、当該もとの保険商品の満期返戻金の金額、および、満期返戻金と保険料との差額に対応する差額徴収額とを含み、差額徴収額が入金金額に相当し、かつ、旧証券番号および満期返戻金の金額が含まれる払込票が作成され、かつ、入力済データが、旧証券番号および満期返戻金の金額を含み、前記データ消込手段が、前記入力済データテーブルのレコード中、入金金額および満期返戻金の金額の総和が、前記入金予定データテーブルの対応するレコード中の入金予定金額に合致するか否かを判断する。
【００１６】
また、好ましい実施態様においては、前記データ消込手段が、少なくとも、前記消込が完了した入金予定のレコードの消込フラグをセットする。
【００１７】
別の好ましい実施態様においては、さらに、データ消込手段が、前記商品の販売者のシステムに対して、ネットワークを介して、前記消込が完了したレコードの情報を通知する。
【００１８】
また、本発明の目的は、商品の購入契約に伴い、入金予定額、および、当該契約にかかる商品を特定する情報を含む入金予定データを、入金予定データテーブルのレコードとして記憶するステップと、前記入力予定データに基づいて作成された、決済者が店舗にて決済額を支払うための払込票を用いた支払にしたがって生成された入金済データであって、入金金額、および、商品を特定する情報を含む入金済データを、入金済データテーブルのレコードとして記憶するステップと、前記入金データテーブルのレコードと、入金済データテーブルのレコードとを照合して、レコードに関する消込を実行するステップであって、前記入金済データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金金額を合算し、かつ、照合すべき入金予定データテーブルのレコードにおいて、同じ商品を特定する情報を含む複数のレコードが存在する場合に、当該複数のレコードに含まれる入金予定額を合算し、合算額を照合することにより消込を実行するステップとを、コンピュータに実行させることを特徴とするコンピュータにより読み出し可能な決済プログラムにより達成される。
【００１９】
好ましい実施態様においては、前記商品が、保険商品であり、前記商品を特定する情報が、証券番号であり、さらに、ある保険商品の満期返戻金を、新たな保険商品の契約の保険料に充当するように、入金予定データが、もとの保険商品の証券番号である旧証券番号、当該もとの保険商品の満期返戻金の金額、および、満期返戻金と保険料との差額に対応する差額徴収額とを含み、差額徴収額が入金金額に相当し、かつ、旧証券番号および満期返戻金の金額が含まれる払込票が作成され、かつ、入力済データが、旧証券番号および満期返戻金の金額を含み、前記消込を実行するステップにおいて、前記入力済データテーブルのレコード中、入金金額および満期返戻金の金額の総和が、前記入金予定データテーブルの対応するレコード中の入金予定金額に合致するか否かを判断するステップを、前記コンピュータに実行させる。
【００２０】
また、前記消込を実行するステップにおいて、少なくとも、前記消込が完了した入金予定のレコードの消込フラグをセットするステップを、前記コンピュータに実行させるのが望ましい。さらに、消込を実行するステップにおいて、前記商品の販売者のシステムに対して、ネットワークを介して、前記消込が完了したレコードの情報を通知するステップを、前記コンピュータに実行させるのが望ましい。
【発明の効果】
【００２１】
本発明によれば、契約者の利便を損なわず、かつ、商品を販売する会社の業務負担を軽減しつつ、適切な決済が可能なシステムおよびプログラムを提供することが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下、添付図面を参照して、本発明の実施の形態について説明する。図１は、本実施の形態にかかるシステム全体の概略を示すブロックダイヤグラムである。図１に示すように、このシステムにおいては、コンビニエンスストアのシステム１２と、保険会社のシステム１４との間に、ネットワーク１６，１８を介して接続されたサーバ１０が設けられている。
【００２３】
図１に示すように、サーバ１０は、後述する種々のデータを記憶するＤＢ２０と、保険会社のシステム１４からの入金予定データを受理して、必要な処理を実行した上でＤＢ２０に記憶する入金予定データ管理部２２と、コンビニエンスストアのシステム１２からの入金済データを受理して、必要な処理を実行した上でＤＢ２０に記憶する入金済データ管理部２４と、入金予定データおよび入金済データに基づいて、後述する消込処理を実行するデータ消込部２６と、保険会社のシステム１４からの要求に応答して、種々の情報を、システム１４に対して提示するための処理を実行する入金状況管理部２８とを有している。
【００２４】
本実施の形態にかかるシステムを利用する際の払込票の作成や資金移動のデータの生成等について、図２を参照して説明する。契約者が記入した保険の申込書は、代理店から保険会社に送付される（符号２０１参照）。保険会社のシステム１４においては、申込書に基づいて、入金予定データが生成され、これがサーバ１０に送信される（符号２０２、２０３参照）。図３（ａ）は、ＤＢ２０中、入金予定データを記憶した入金予定データテーブルのデータ構成を示す図である。入金予定データテーブルのレコードは、項目として、「契約者名」、「入金予定保険料額」、「証券番号」、「代理店コード」、「課所コード」、「母店コード」、「申込日」、「入金種類」、「代理店名称」、「契約者住所」、「契約者郵便番号」、「契約者電話番号」、「保険責任開始日」および「連番」を含む。ここで、「連番」は、入金予定データのレコードが一意的に特定されるように採番される。連番に使用する番号は、保険会社システム１４にて採番され、これがサーバ１０に伝達されても良いし、サーバ１０において採番されても良い。
【００２５】
サーバ１０においては、入金予定データが参照されて、払込票が作成される（符号２０４参照）。作成された払込票は、たとえば郵送にて決済者に送られる（符号２０５参照）。決済者は、通常は契約者であるが、それ以外のものであっても良い。払込票には、払込金額のほか、「証券番号」および「連番」が記載されている。「証券番号」および「連番」は、
【００２６】
決済者（契約者）は、コンビニエンスストアに払込票を持参して、所定の保険料を支払う（符号２１１参照）。支払われた保険料のデータは、コンビニエンスストアのシステム１２に送られ、さらに、入金済データとしてサーバ１０に送られる。図３（ｂ）は、ＤＢ２０中、入金済データを記憶した入金済データテーブルのデータ構成を示す図である。入金済データテーブルのレコードは、項目として、「入金日」、「入金金額」、「入金時間」、「証券番号」および「連番」を含む。
【００２７】
保険会社のシステム１４からの入金予定データがサーバ１０に受理されると、サーバ１０の入金予定データ管理部２２は、ＤＢ２０の入金予定データテーブルのレコードとして、受理した入金予定データを記憶する。また、コンビニエンスストアのシステム１２からの入金済データがサーバ１０に受理されると、サーバ１０の入金済データ管理部２４は、ＤＢ２０の入金済データテーブルのレコードとして、受理した入金済データを記憶する。
【００２８】
サーバ１０は、ＤＢ２０に記憶された入金予定データおよび入金済データを参照して、以下に述べる処理を実行する。図４は、サーバ１０にて実行される消込処理を示すフローチャートである。この処理は、コンビニエンスストアのシステム１２からの入金済データを受理するごとに実行しても良いし、所定のタイミングで（たとえば毎日、所定の時刻に）実行しても良い。後者の場合、入金済データテーブル中のレコードのうち、消込処理が終了していない全てのレコードに対して処理が施されれば良い。
【００２９】
図４に示すように、サーバ１０のデータ消込部２６は、入金済データテーブルの処理対象となるレコードと、その「証券番号」および「入金金額」が同一のレコードが、入金済データテーブルに既に存在するか否かを判断する（ステップ４０１）。本実施の形態においては、図２を参照して説明したように、入金予定データがサーバ１０に伝達されると、これに応答して、払込票が作成されて、決済者に郵送される。また、払込票を用いた支払に応じて、入金済データが生成され、これがサーバ１０に伝達される。したがって、基本的には、入金予定データのレコードと、入金済のレコードとは一対一に対応している。しかしながら、何らかの誤りで、同一の入金済データが複数にわたってサーバ１０に伝達される可能性があるため、ステップ４０１でこのような誤った入金済データを排除する。
【００３０】
なお、本実施の形態においては、入金予定データテーブルのレコード、および、入金済データレコードには「連番」が含まれる。したがって、入金済データテーブルにおいて、「連番」の重複を判断すれば、重複するレコードの排除に際する二重チェックを実現することができる。
【００３１】
ステップ４０１でイエス(Yes)と判断された場合には、何からのエラーが生じていると考えられるため、エラーメッセージをサーバ１０の表示装置に表示してエラーが生じたことをオペレータに通知する（ステップ４０２）。これに加えて、コンビニエンスストアシステム１２にもエラーを通知しても良い。
【００３２】
次に、データ消込部２６は、処理対象となる入金済データテーブルのレコードの「証券番号」を参照して、同一の「証券番号」を有する、入金済データテーブル中の他のレコードが存在するか否かを判断する（ステップ４０３）。ステップ４０３でイエス(Yes)と判断された場合には、データ消込部２６は、当該複数のレコード中の「入金金額」を合算する（ステップ４０４）。ステップ４０３でノー(No)と判断された場合には、後述するステップ４０５に進む。
【００３３】
その後、データ消込部２６は、入金予定データテーブルから、同一の「証券番号」を有するレコードを参照して、その「入金予定保険料額」を取得する（ステップ４０５）。レコードが複数ある場合には、複数のレコードの「入金予定保険料額」の総和が求められる。次いで、入金済データテーブルに基づき得られた「入金金額」或いはその総和と、入金予定データテーブルに基づき得られた「入金予定保険料額」或いはその総和とが一致するか否かが判断される（ステップ４０６）。双方が一致しない場合（ステップ４０６でノー(No)）には、何からのエラーが生じていると考えられるため、エラーメッセージをサーバ１０の表示装置に表示してエラーが生じたことをオペレータに通知する（ステップ４０７）。その一方、ステップ４０６でイエス(Yes)と判断された場合には、入金済データテーブルおよび入金予定データテーブル中、処理対象となったレコード、つまり、双方で一致した金額の算出に利用されたレコードに消込フラグ（図示せず）がセットされる（ステップ４０８）。消込フラグがセットされたレコードについては、以後、消込処理の対象から除外される。
【００３４】
また、データ消込処理部２６は、消込が完了した証券番号を、保険会社のシステム１４に通知する（ステップ４０９）。
【００３５】
本実施の形態によれば、保険会社からの申込書に基づく入金予定データの受理に応答して、サーバ１０は、その「保険料額」および「証券番号」を含む払込票を作成する。また、決済者によるコンビニエンスストアでの払込に応答して、「入金金額」および「証券番号」を含む入金済データがサーバ１０に伝達される。サーバ１０においては、「証券番号」をキーとして、同一の「証券番号」を備えた入金済データを合算して消込を実行する。したがって、消込は、「証券番号」ごとに実行することができ、保険会社への消込完了の通知も「証券番号」単位で行なわれる。したがって、間違いのない消込が可能であり、かつ、保険会社における保険料額の領収の確認を容易にすることが可能となる。保険業界においては、保険契約が成立するまでの間に、追加の保険料を契約者から徴収する場合がある。本実施の形態では、同一の証券番号で複数の入金があった場合に、証券番号単位で合算して消し込むことができる。
【００３６】
次に、入金状況管理部２８にて実行される処理について簡単に説明する。入金状況管理部２８は、ネットワーク１８を介して与えられた、保険会社のシステム１４からの要求にしたがって、所望の入金予定データのレコードを読み出し、これを保険会社のシステム１４に提示することができる。提示される情報には、各レコードに含まれる消込フラグに基づき入金／未入金を示す情報が含まれる。たとえば、入金予定であったが、その後、契約の取り消しにより入金予定がなくなった場合には、そのレコードを消去することもできる。或いは、必要に応じて、レコードの内容を変更することもできる。
【００３７】
なお、図１においては、入金状況管理部２８は、保険会社のシステム１４に、必要な情報を提示できるようになっているが、これに限定されるものではなく、保険代理店からも、当該保険代理店の代理店コードを有するレコードを参照できるようにしても良い。また、レコードの消去や変更は、代理店コード、課所コード、母店コードなどに基づいて、そのコードに対応する代理店、課所、母店のみが行なえるように制限をするのが望ましい。
【００３８】
さらに、入金状況管理部２８は、入金予定データテーブルのレコードを参照して、申込日から一定期間経過後にも消込フラグがセットされていないレコード、或いは、保険責任開始日前所定の期日であるにもかかわらず消込フラグがセットされていないレコードを見出す。これらのレコードについては、レコード中の契約者を特定して、再度、払込票を作成し、最郵送するのが望ましい。
【００３９】
次に、本発明の第２の実施の形態について説明する。満期返戻金のある契約が満期を迎えたとき、自動継続特約などで新たな契約の一時払保険料に充当する場合でも、満期返戻金と一時払保険料との差額を契約者から徴収する場合がある。このような場合に、第2の実施の形態にかかるサーバ１０は、旧契約の満期返戻金と新契約の差額徴収分を合算することにより、新契約に必要な額の一時払保険料を消し込み、消込にかかる証券番号を、保険会社のシステム１４に伝達することができる。第２の実施の形態におけるシステム全体の概略は、図１に示す第１の実施の形態のものとほぼ同様である。また、払込票の作成や資金移動のデーの作成についても、図２に示すものとほぼ同様である。
【００４０】
再度、払込票の作成および資金移動のデータの作成について簡単に説明する。第２の実施の形態においても、契約者が記入した保険の申込書が、代理店から保険会社に送付され、保険会社のシステム１４において、満期を迎えた契約の証券番号（「旧証券番号」とも称する。）や新たな保険契約の証券番号（「新証券番号」とも称する。）などに基づいて、入金予定データが生成され、これがサーバ１０に送信される。
【００４１】
図５（ａ）は、第２の実施の形態にかかる入金予定データテーブルのデータ構成の部分を示す図である。第２の実施の形態にかかる入金予定データテーブルのレコードにおいては、図３（ａ）に示すデータテーブルのレコードの項目に加えて、図５（ａ）に示すように、項目として、「旧証券番号」、「満期返戻金の金額」、および、「差額徴収額」が含まれる。また、入金予定データテーブルのレコード中、項目「証券番号」の値は、新たな保険契約にかかる新証券番号に相当する。また、入金予定データテーブルのレコード中、入金予定保険料額は、新たな保険契約における保険料額（たとえば、一時払保険料額）と一致する。
【００４２】
サーバ１０においては、新証券番号、差額徴収額に相当する払込金額、旧証券番号、および、連番が少なくとも含まれる。作成された払込票は、決済者（契約者）に送られ、決済者（契約者）が、コンビニエンスストアにて、差額徴収額を支払う。
【００４３】
コンビニエンスストアのシステム１２は、支払われた払込金のデータに基づいて、入金済データを生成して、サーバ１０に送信する。第２の実施の形態にかかる入金済データテーブルのレコードは、図３（ｂ）に示す項目に加えて、図５（ｂ）に示すように、「旧証券番号」、「満期返戻金の金額」を含む。また、第２の実施の形態では、図３（ｂ）に中の項目「入金金額」が、差額徴収額に相当する。
【００４４】
第１の実施の形態と同様に、保険会社のシステム１４からの入金予定データがサーバ１０に受理された場合には、入金予定データ管理部２２が、ＤＢ２０の入金予定データテーブルのレコードとして、受理した入金予定データを記憶する。また、コンビニエンスストアのシステム１２からの入金済データが、サーバ１０に受理された場合にも、入金済データ管理部２４が、ＤＢ２０の入金済データテーブルのレコードとして、受理した入金済データを記憶する。
【００４５】
次に、第２の実施の形態にかかるサーバ１０のデータ消込部２６の処理について説明する。図６は、第２の実施の形態にかかるサーバ１０において実行される、満期返戻金を充当する場合の消込処理を示すフローチャートである。この処理は、図４に示す消込処理に引き続いて実行され得る。
【００４６】
図６に示すように、サーバ１０のデータ消込部２６は、入金済データテーブルの処理対象となるレコードを参照して、項目「旧証券番号」が存在するかどうかを判断する（ステップ６０１）。ステップ６０１でノー(No)と判断された場合には処理が終了する。その一方、ステップ６０１でイエス(Yes)と判断された場合には、データ消込部２６は、入金済データテーブルのレコードに存在していた「旧証券番号」と同一の「旧証券番号」を項目として含むレコードが、入金予定データテーブルに存在するか否かを判断する（ステップ６０２）。このステップ６０２でノー(No)と判断された場合には、何からのエラーが生じていると考えられるため、エラーメッセージをサーバ１０の表示装置に表示してエラーが生じたことをオペレータに通知する（ステップ６０３）。
【００４７】
ステップ６０２でイエス(Yes)と判断された場合には、データ消込部２６は、入金済データテーブルのレコードに存在していた「新証券番号」と同一の「証券番号」を含むレコードが、入金予定データテーブル中に存在するか否かを判断する（ステップ６０４）。このステップ６０４でノー(No)と判断された場合にも、データ消込部２６は、エラーメッセージをサーバ１０の表示装置に表示してエラーが生じたことをオペレータに通知する（ステップ６０５）。
【００４８】
ステップ６０２およびステップ６０４においてイエス(Yes)と判断された場合には、データ消込部２６は、入金済データテーブルのレコード中、満期返戻金の金額と、差額徴収額とを合算し（ステップ６０６）、当該合算額が、入金予定データテーブル中、新証券番号を含むレコードの保険料額と一致するか否かを判断する（ステップ６０７）。ステップ６０７においてノー(No)と判断された場合には、合算額が、保険料額より少額かどうかが判断される（ステップ６０８）。少額である場合（ステップ６０８でイエス(Yes)）には、保険料額と合算額の差額を徴収するように、差額を払込金額とする払込票が作成され（ステップ６０９）、当該払込票が、決済者に対して送付される。なお、合算額が少額となった場合には、たとえば、入金済データテーブルの、処理対象となったレコードに、所定のフラグ（再送付フラグ）をセットしておき、次回の処理の際に、再送付フラグがセットされたレコードについて、同一の新証券番号および旧証券番号を有する他のレコード（差額の払込票による支払に基づく入金済データのレコード）を探し出して、双方のレコードの差額徴収額を合算した上で、これを新たな差額徴収額として、図６の処理を実行すれば良い。
【００４９】
また、ステップ６０８においてノー(No)、つまり、合算額が保険料額より多かった場合には、払戻しのための処理が実行される（ステップ６１０）。なお、決済者への払い戻しが完了すると、後述するステップ６１１と同様に、処理対象となった入金済データテーブルのレコードおよび入金予定データテーブルのレコード（新証券番号を含むレコード）の消込フラグがセットされる。
【００５０】
ステップ６０７でイエス(Yes)、つまり、合算額と保険料額とが一致した場合には、データ消込部２６は、処理対象となった入金済データテーブルのレコードの消込フラグ、および、入金予定データテーブルの、新証券番号を含むレコードの消込フラグをセットする（ステップ６１１）。これにより、以後の処理において、消込フラグがセットされたレコードについては、以後、データ消込処理（図４参照）や、満期返戻金を充当する場合の消込処理（図６参照）の対象外となる。次いで、データ消込処理部２６は、消込が完了した証券番号を、保険会社のシステム１４に通知する（ステップ６１２）。
【００５１】
第２の実施の形態によれば、満期返戻金がある保険契約が満期を迎えたとき、自動継続特約による新たな契約において、満期返戻金を、保険料（たとえば一時払保険料）の一部として充当することができる。この場合に、ユーザは払込票にしたがってコンビニエンスストアに、差額徴収分の金額を支払えばよい。また、サーバ１０において、満期返戻金の金額および差額徴収分の金額を合算して消込を行なうことにより、上述したようなケースでも適切な消込を実現することができる。
【００５２】
なお、前記第２の実施の形態においては、満期返戻金がある保険契約が満期を迎えたとき、自動継続特約により、同じ保険種目の新たな契約を結ぶ場合に、本発明が適用されているが、これに限定されるものではなく、異なる保険種目の保険に新規に契約する場合にも、本発明を適用することができる。たとえば、養老保険の満期返戻金を、新たに契約する終身保険の頭金に充当するときに、保険料計算単位の制限により少額の不足分が発生する場合などが考えられる。このような場合に、不足分を、差額徴収分として払込票を作成し、決済者の支払による入金済データに基づいて、図６に示す処理が実行されれば良い。
【００５３】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【図面の簡単な説明】
【００５４】
【図１】図１は、本実施の形態にかかるシステム全体の概略を示すブロックダイヤグラムである。
【図２】図２は、本実施の形態にかかるシステムを利用する際の払込票の作成や資金移動のデータの生成等を説明するための図である。
【図３】図３（ａ）、（ｂ）は、それぞれ、入金予定データを記憶した入金予定データテーブルのデータ構成、および、入金済データを記憶した入金済データテーブルのデータ構成を示す図である。
【図４】図４は、本実施の形態にかかる消込処理を示すフローチャートである。
【図５】図３（ａ）、（ｂ）は、それぞれ、第２の実施の形態にかかる入金予定データを記憶した入金予定データテーブルのデータ構成の一部、および、入金済データを記憶した入金済データテーブルのデータ構成の一部を示す図である
【図６】図６は、第２の実施の形態にかかる満期返戻金を充当する場合の消込処理を示すフローチャートである。
【符号の説明】
【００５５】
１０        サーバ
１２        コンビニエンスストアシステム
１４        保険会社システム
１６、１８  ネットワーク
２０        入金状況ＤＢ
２２        入金予定データ管理部
２４        入金済データ管理部
２６        データ消込部
２８        入金状況管理部
【図１】
2005084880.tif 000003
【図２】
2005084880.tif 000004
【図３】
2005084880.tif 000005
【図４】
2005084880.tif 000006
【図５】
2005084880.tif 000007
【図６】
2005084880.tif 000008