(57)【要約】【課題】債務者が死亡したり高度障害状態になったりし、支払能力を欠くに至った場合にも対応できる債権管理システムを提供する。【解決手段】債権管理システム１０の特約処理部１６は、入金確認部１２が入金を確認できないと、死亡・高度障害特約の有無を判断し、死亡・高度障害特約があると判断すると、死亡・高度障害フラグのＯＮ／ＯＦＦを判断し、死亡・高度障害フラグがＯＮであると判断すると、入金履歴に基づいて、死亡・高度障害特約を適用するか否か判断し、滞納がない場合には特約適用と判断し、債権放棄に係る処理をおこなうとともに、債権管理を終了する（Ｓ１→Ｓ１１→Ｓ１２→Ｓ１６→Ｓ１８→Ｓ４→Ｓ５）。【選択図】図３
2014016783.tif 000002
【特許請求の範囲】
【請求項１】
金融機関から入金情報を取得し、入金の有無を確認する入金確認部と、
前記入金確認部が入金を確認すると、通常の処理をおこなう通常処理部と、
前記入金確認部が入金を確認できないと、督促に係る処理をおこなう督促処理部と、
前記通常処理部の指令に基づいて、新たな債権残高を演算し、前記督促処理部の指令に基づいて、遅延金を加算して債権残高を再演算する演算処理部と、
債務者に対する債権残高を含む債務者情報を記憶する債務者データベースと
を備える債権管理システムにおいて、
前記債務者データベースは、死亡・高度障害特約の有無および死亡・高度障害フラグのＯＮ／ＯＦＦを記憶し、
前記債権管理システムは、
前記入金確認部が入金を確認できないと、死亡・高度障害特約の有無を判断し、死亡・高度障害特約があると判断すると、死亡・高度障害フラグのＯＮ／ＯＦＦを判断し、死亡・高度障害フラグがＯＮであると判断すると、債権放棄に係る処理をおこなうとともに、債権管理を終了するように指令する特約処理部
を更に備えることを特徴とする債権管理システム。
【請求項２】
前記債務者データベースは、入金履歴を記憶し、
前記特約処理部は、入金履歴に基づいて、死亡・高度障害特約を適用するか否か判断する
ことを特徴とする請求項１記載の債権管理システム。
【請求項３】
前記債権管理システムは、信販会社の会計処理をおこなう会計処理システムと接続しており、
債権放棄する債権額を雑損失として前記会計処理システムに出力する
ことを特徴とする請求項１または２記載の債権管理システム。
【請求項４】
前記特約処理部は、入金履歴に基づいて、Ｎ回以上の滞納があった場合には、死亡・高度障害特約を適用しないと判断する
ことを特徴とする請求項２記載の債権管理システム。
【請求項５】
前記特約処理部は、入金履歴に基づいて、Ｎ回数未満の滞納があった場合には、滞納総額を除外して、死亡・高度障害特約を適用すると判断する
ことを特徴とする請求項５記載の債権管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は債権管理システムに関する。特に、債務者が死亡したり高度障害状態になったりし、支払能力を欠くに至った場合にも対応できる債権管理システムに関する。
【背景技術】
【０００２】
信販会社の基本的なビジネスモデルについて説明する。
【０００３】
原始的な商取引においては、顧客と販売店の間に売買契約が成立すると、顧客には代金支払債務（金銭債務、販売店の金銭債権）が発生し、販売店には売買目的物の引き渡し債務が発生する。
【０００４】
一方、耐久消費財と呼ばれる乗用車や太陽光発電装置などは、食料品等の日用品に比べて高額であり、顧客は現金一括で購入できない場合もある。また、商品が高額になる程、販売店が金銭債権を回収できないリスクが高くなる。そこで、信販会社が顧客と販売店の間に介在する。信販会社は商品代金を立て替えて販売店に支払い（金銭債権を買い取り）、顧客は信販会社に代金を後払いする。このとき、分割払いとすることも多い。
【０００５】
顧客は、自己の資力に応じた支払計画を立てながら、高額商品を即時取得でき、販売店（信販会社加盟店）は代金の回収が容易であり、信販会社は金利相当額を収入とすることができ、３者にメリットのあるビジネスモデルとなっている。
【０００６】
割賦契約は三者間契約であるが、債権買取後は、顧客（債務者）と信販会社の二者間契約となる。顧客は金銭債務が無くなるまで、金融機関を介して、複数回、所定額を支払う。信販会社の債権管理システムは、金銭債権を管理する。
【０００７】
例えば、債権管理システムは演算装置を有し、演算装置は毎月の入金を確認し、入金を確認できないと、督促に係る処理をおこなう（特許文献１、２）。督促に係る処理は、遅延金を含めた債権残高の再計算、督促状作成支援、督促メール発送、コールセンター業務支援などを含む。
【０００８】
ところで、債務者が死亡した場合、金銭債務は相続によって相続人に一般承継される。具体的に言えば、夫と妻と子供からなる家庭において、夫が債務者であり、夫が死亡した場合、相続人である妻及び子が債務者となる。生命保険（後述する団体信用生命保険と異なる）の保険金支払いにより経済状況が多少緩和されるものの、妻が専業主婦で支払い能力がなく、子供の教育費などで将来の支出が見込まれる場合など、相続人となる遺族に大きな負担を強いることになる。
【０００９】
この様な遺族に過度の負担を強いることを防止するため、信販会社は、団体信用生命保険への加入を顧客に推奨している。顧客は、信販会社との割賦契約に伴い、団体信用生命保険へ加入する。信販会社は生命保険会社と団体信用生命保険を契約する。債務者が死亡した場合、金銭債務は相続人となる遺族に一般承継されるが、団体信用生命保険が適用されると、生命保険会社が残りの債務を弁済する。これにより、残された遺族は過度の負担を強いられることはなくなり、一方、信販会社は確実に債権を回収できる。
【００１０】
なお、病気や怪我で債務者に高度障害が残り支払い能力を欠くに至った場合も、債務者に債務は残り、家族が債務を承継することはないものの、事実上、家族に大きな負担を強いることになる。団体信用生命保険が適用されると、生命保険会社が残りの債務を弁済する。これにより、家族は過度の負担を強いられることはなくなり、一方、信販会社は確実に債権を回収できる。以下、説明の簡略化のため高度障害については適宜割愛する。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００４―１１８３４９号公報
【特許文献２】特開２０１１―１０８２２１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
上述のように団体信用生命保険はメリットも多いが、一方で、デメリットも多い。
【００１３】
通常、団体信用生命保険へ加入する際は、販売店の店舗において、販売店の店員が顧客に説明することが多い。顧客も販売店員も保険契約に精通しているとは限らず、告知書を含む契約書面に不備があるおそれがある。信販会社の担当者または生命保険会社の担当者が契約書面の不備を確認し、不備があれば再提出を依頼する。このような煩雑な事務手続きは、顧客、販売店、信販会社の全てにとって負担となっている。
【００１４】
煩雑な事務手続きを嫌って、顧客の購買意欲が減少する恐れもある。販売店も事務手続きに煩わされて次のビジネスチャンスを失う恐れもある。販売店がビジネスチャンスを失うのに伴って、信販会社もビジネスチャンスを失う。更に、信販会社も事務手続きに人的資源を割く必要がある。
【００１５】
この様に、団体信用生命保険を利用したビジネスモデルは、顧客に安心を与えることによる販売促進効果がある一方、煩雑な事務手続きによる販売抑制効果もある。
【００１６】
更に、団体信用生命保険を適用する際にも問題がある。顧客が死亡した場合、顧客からの団体信用生命保険適用申請書類に基づいて生命保険会社が団体信用生命保険適用の可否を判断する。また、顧客が死亡した直後では、遺族は冷静な判断ができないおそれもあり、複雑な申請書類作成は、遺族にとって精神的な負担となる。申請書類に不備があったり、書類申請が遅延した場合、団体信用生命保険が適用されないおそれもある。団体信用生命保険が適用されない場合、遺族の負担は大きく、信販会社は債権を回収できないおそれもある。
【００１７】
これらの問題を解消するように、団体信用生命保険を考慮した債権管理システムを構築することも考えられるが、以下の点で困難である。
【００１８】
団体信用生命保険は、信販会社（債権者）を保険契約者および保険金受取人とし、顧客（債務者）を被保険者とする保険契約であり、顧客と信販会社と生命保険会社が関与する。生命保険会社と顧客の間のこと、例えば、団体信用生命保険適用の可否判断などは、信販会社は関与できない。
【００１９】
また、形式的には、遺族に金銭債務は遺族に一般承継される。金銭債権契約と保険契約が併存し、これらが密接に相互に関わっており、法的関係が複雑である。
【００２０】
更に、団体信用生命保険の適用を受ける際には、顧客と保険会社の間、顧客と信販会社の間、信販会社と保険会社の間の書面のやり取りが中心となり、業務に精通した人を介在させる必要がある。
【００２１】
一般に、債権管理システムの演算装置は、決められたルーチンを大量処理することを得意とするが、複雑な個別の事情を考慮して処理することを苦手としている。上記の理由から、団体信用生命保険に係る処理を債権管理システムに組み込むことは難しい。
【００２２】
団体信用生命保険に係る処理を債権管理システム組み込むことは難しい結果、既存の債権管理システムでも問題が生じている。
【００２３】
団体信用生命保険は顧客の申請書類に基づいて適用されることを前提とするが、実務において、入金を確認できずコールセンターから電話で督促した際に、遺族から顧客の死亡を知らされることも多い。信販会社の団体信用生命保険担当者は、コールセンターから顧客死亡の連絡を受け、団体信用生命保険適用の手続きを行う。
【００２４】
一方、顧客の死亡し遺族が混乱している状況では、次回の入金はされない。団体信用生命保険が適用されるまで、数か月を要することもある。債権管理システムは、入金を確認できないと、毎月督促に係る処理をおこなう。
【００２５】
このような無用な督促は、信販会社にとって無駄なオペレーションであるばかりでなく、遺族をさらに混乱させるおそれがある。
【００２６】
以上の様に、団体信用生命保険に係るビジネスモデルに代わる新たなビジネスモデルおよび新たなビジネスモデルを実現する債権管理システムが求められている。
【００２７】
本発明は上記課題を解決するものであり、債務者が死亡したり高度障害状態になったりし、支払能力を欠くに至った場合にも対応できる債権管理システムを提供することを目的とする。
【課題を解決するための手段】
【００２８】
上記課題を解決する本発明は、金融機関から入金情報を取得し、入金の有無を確認する入金確認部と、前記入金確認部が入金を確認すると、通常の処理をおこなう通常処理部と、前記入金確認部が入金を確認できないと、督促に係る処理をおこなう督促処理部と、前記通常処理部の指令に基づいて、新たな債権残高を演算し、前記督促処理部の指令に基づいて、遅延金を加算して債権残高を再演算する演算処理部と、債務者に対する債権残高を含む債務者情報を記憶する債務者データベースとを備える債権管理システムにおいて、前記債務者データベースは、死亡・高度障害特約の有無および死亡・高度障害フラグのＯＮ／ＯＦＦを記憶し、前記債権管理システムは、前記入金確認部が入金を確認できないと、死亡・高度障害特約の有無を判断し、死亡・高度障害特約があると判断すると、死亡・高度障害フラグのＯＮ／ＯＦＦを判断し、死亡・高度障害フラグがＯＮであると判断すると、債権放棄に係る処理をおこなうとともに、債権管理を終了するように指令する特約処理部を更に備えることを特徴とする。
【００２９】
本発明の債権管理システムは、特約処理部を備えることにより、死亡・高度障害特約を有する新たなビジネスモデルを実現できる。
【００３０】
新たなビジネスモデルでは、債務者が死亡したり高度障害状態になったりし、支払能力を欠くに至った場合には、信販会社は債権放棄する。これにより、団体信用生命保険が適用された場合と同様に、遺族が過度の負担を強いられることはなくなる。その結果、顧客に安心を与え、販売促進効果を得る。
【００３１】
一方、本ビジネスモデルは、法律関係が単純であるため、割賦契約の際に簡単な記載（例えばチェックボックス）を追加するのみでよく、顧客、販売店、信販会社の全てが、団体信用生命保険の保険契約のような煩雑な事務手続きから解放される。また、特約申請時の手続きも団体信用生命保険の申請手続きに比べて簡略化され、遺族や家族は確実に保護される。事務手続きの簡略化より、販売店および信販会社は、更なる販売促進効果を期待できる。
【００３２】
従来技術の債権管理システムは、一般的な滞納と死亡（高度障害）との区別が難しく、無用の督促に係る課題があった。本ビジネスモデルでは、死亡（高度障害）確認により、無用の督促を防止できる。これにより、信販会社のオペレーションを効率化できるとともに、遺族や家族の負担を軽減できる。
【００３３】
団体信用生命保険を利用したビジネスモデルを従来技術の債権管理システムに組み込むのは難しかった。これに対し、本ビジネスモデルは、従来の債権管理システムに特約処理部を追加し、債務者データベースに特約処理に係る情報を追加するだけで、実現できる。
【００３４】
本願発明において好ましくは、前記債務者データベースは、入金履歴を記憶し、前記特約処理部は、入金履歴に基づいて、死亡・高度障害特約を適用するか否か判断する。
【００３５】
これにより、適切に支払いを続けた優良な顧客を確実に保護する。優良な顧客にインセンティブを与える結果、債務者はなるべく支払うように努め、債権回収の実効性が向上する。
【００３６】
本願発明において好ましくは、前記債権管理システムは、信販会社の会計処理をおこなう会計処理システムと接続しており、債権放棄する債権額を雑損失として前記会計処理システムに出力する。
【００３７】
団体信用生命保険を利用したビジネスモデルは、法律関係が複雑で会計処理が複雑であった。これに対し、本ビジネスモデルでは、法律関係が単純であるため、債権管理システムや会計処理システムにより好適に処理できる。これにより、信販会社のオペレーションを効率化できる。
【００３８】
本願発明において好ましくは、前記特約処理部は、入金履歴に基づいて、Ｎ回以上の滞納があった場合には、死亡・高度障害特約を適用しないと判断する。
【００３９】
このように、優良でない顧客にペナルティを課す結果、債権回収の実効性が向上する。
【００４０】
本願発明において好ましくは、前記特約処理部は、入金履歴に基づいて、Ｎ回数未満の滞納があった場合には、滞納総額を除外して、死亡・高度障害特約を適用すると判断する。
【００４１】
これにより、何かしらの理由で支払いが遅滞した優良な顧客を救済できる。
【発明の効果】
【００４２】
本発明の債権管理システムによれば、債務者が死亡したり高度障害状態になったりし、支払能力を欠くに至った場合にも対応できる。
【図面の簡単な説明】
【００４３】
【図１】信販会社の基本ビジネスモデルを示す概念図
【図２】債権管理システムの概略構成図
【図３】債権管理システムの処理内容を示すフローチャート
【図４】債権管理システムの処理内容を示すフローチャート（変形例１）
【発明を実施するための形態】
【００４４】
〜基本ビジネスモデル〜
図１は、信販会社の基本ビジネスモデルを示す概念図である。本実施形態の説明する前に信販会社の基本ビジネスモデルについて説明する。なお、金額は理解の補助ために例示するものであり、実際とは異なる。
【００４５】
顧客と信販会社加盟店との間に太陽光発電パネルに関する２００万円の売買契約が成立した場合、信販会社は、信販会社加盟店からの顧客情報や商品情報を受信する。信販会社は、これらの情報および、信販会社データベースに記憶されている信用情報に基づき、顧客の返済能力等を審査し、審査結果に問題があれば、その旨を信販会社加盟店に送信する。
【００４６】
審査結果に問題がなければ、信販会社は、顧客が信販会社加盟店で購入した商品の代金２００万円から顧客が信販会社加盟店に支払った金額（頭金なしの場合は０円）を差し引いた残金に基づいて、立替金額２００万円を算出し、信販会社は信販会社加盟店に立替金を支払う。
【００４７】
一方、信販会社は、金利相当額２０万円を含む支払総額を２２０万円と設定し、支払い回数２０回および各回の支払額１１万円と設定する。さらに、各回の支払いを確認する。支払いが確認できない（入金未確認）場合、顧客（債務者）に督促する。
【００４８】
このとき、金利相当額２０万円が信販会社の収入となる。
【００４９】
信販会社の債権管理システム１０は、上記についての管理を行う。
【００５０】
〜構成〜
図２は、本実施形態に係る債権管理システム１０の概略構成を示す図である。図２を参照して債権管理システム１０の構成を説明する。
【００５１】
債権管理システム１０は、中央管理部１１と、入金管理部１２と、通常処理部１３と、督促処理部１４と、演算処理部１５と、データベース１７とを備える。更に、特徴的構成として特約処理部１６を備え、データベース１７は、特約処理に係る情報を記憶している。
【００５２】
各部１２〜１６に指令は、データベース１７に記憶されているプログラムを実行するにより行われる。
【００５３】
中央管理部１１は、各部１２〜１６に指令するとともに、各部１２〜１６で行わない制御をおこない、債権管理システム１０を統括する。
【００５４】
入金確認部１２は、金融機関から入金情報を取得し、入金の有無を確認する。
【００５５】
通常処理部１３は、入金確認部１２が入金を確認すると、通常の処理をおこなう。具体的には、債権残高（債務者にとっては債務残高）から支払額を差し引いて新たな債権残高を求めたり、入金確認のメールや書面の作成準備などを行う。
【００５６】
督促処理部１４は、入金確認部１２が入金を確認できないと、督促に係る処理をおこなう。具体的には、債権残高に遅延金を加算して新たな債権残高を求めたり、督促メールや督促状の作成準備や、コールセンターの補助資料作成などを行う。
【００５７】
演算処理部１５は、通常処理部１３や督促処理部１４の指令に基づき、債権残高等の演算を行う。
【００５８】
データベース１７は、債務者に対する債権残高を含む債務者情報を記憶する。債務者情報には債務者識別番号、債権総額、金利相当額、分割回数、入金履歴、債権残高等が含まれる。さらに、データベース１７は、死亡・高度障害特約の有無および死亡・高度障害フラグのＯＮ／ＯＦＦを記憶する。
【００５９】
特約処理部１６は、入金確認部１２が入金を確認できないと、死亡・高度障害特約の有無を判断し、死亡・高度障害特約があると判断すると、死亡・高度障害フラグのＯＮ／ＯＦＦを判断し、死亡・高度障害フラグがＯＮであると判断すると、債権放棄に係る処理をおこなうとともに、債権管理を終了するように指令する（詳細後述）。
【００６０】
さらに、特約処理部１６は、入金履歴に基づいて、死亡・高度障害特約を適用するか否か判断する。例えば、Ｎ回以上の滞納があった場合には、死亡・高度障害特約を適用しないと判断する。１回以上Ｎ回数未満の滞納があった場合には、滞納総額を除外して、死亡・高度障害特約を適用すると判断する。滞納がなければ、債権残高全額について死亡・高度障害特約を適用すると判断する。
【００６１】
債権放棄に係る処理とは、具体的には、関係書類の作成準備や会計処理用のデータ作成などである。
【００６２】
債権管理システム１０には、コールセンターの端末２１が接続されている。コールセンターでは、オペレータが端末２１に表示されている督促情報を参照しながら、入金未確認の顧客に督促の電話をかける。また、オペレータは顧客情報を確認すると、端末２１を介して顧客情報を入力する。
【００６３】
債権管理システム１０には、システム管理者用の端末２２が接続されている。システム管理者は端末２２を介して必要な情報を入力する。
【００６４】
債権管理システム１０には、会計処理システム２３が接続されている。会計処理システム２３は、信販会社全体の会計処理をおこなうシステムである。特約処理部１６は、債権放棄に係る処理として、債権放棄する債権額を雑損失として会計処理システム２３に出力する。
【００６５】
〜動作〜
図３は、債権管理システム１０の処理内容を示すフローチャートである。本実施形態の特徴的な処理について、点線で囲っている。図３を参照して債権管理システム１０の動作を説明する。なお、顧客死亡の例について説明するが、高度障害も同様である。
【００６６】
・通常時の例（Ｓ１→Ｓ２→Ｓ４→Ｓ５→Ｓ１）
通常、顧客は所定額を金融機関に毎月入金する。債権管理システム１０は、金融機関を介して入金情報を取得し、入金の有無を確認する（ステップＳ１）。入金を確認すると、通常処理をおこない（ステップＳ２）、更に通常処理に伴なう演算処理を行う（ステップＳ４）。新しい債権残高を確認し、所定回数の入金により債権残高がゼロか否かを判断する（ステップＳ５）。債権残高がゼロになれば、債権管理を終了し、債権残高が残っていれば、翌月のステップＳ１における判断を待つ。
【００６７】
・入金未確認の第１例（Ｓ１→Ｓ１１→Ｓ３→Ｓ４→Ｓ５→Ｓ１）
債権管理システム１０は、金融機関を介して入金情報を取得し、入金の有無を確認する（ステップＳ１）。入金を確認できないと、データベース１７を参照し、死亡・高度障害特約の有無を判断する（ステップＳ１１）。死亡・高度障害特約がないと判断すると、督促処理をおこない（ステップＳ３）、更に督促処理に伴う演算処理を行う（ステップＳ４）。新しい債権残高を確認し、債権残高がゼロか否か、すなわち債権管理を終了するか判断し（ステップＳ５）、債権残高が残っているため、ステップＳ１に戻り、翌月の入金確認に係る判断を待つ。
【００６８】
・入金未確認の第２例（Ｓ１→Ｓ１１→Ｓ１２→Ｓ１３→Ｓ１４→Ｓ３→Ｓ４→Ｓ５→Ｓ１）
債権管理システム１０は、金融機関を介して入金情報を取得し、入金の有無を確認する（ステップＳ１）。入金を確認できないと、データベース１７を参照し、死亡・高度障害特約の有無を判断する（ステップＳ１１）。死亡・高度障害特約があると判断すると、死亡・高度障害フラグのＯＮ／ＯＦＦを判断する（ステップＳ１２）。初期設定では死亡・高度障害フラグはＯＦＦとなっており、死亡・高度障害フラグがＯＦＦであると判断すると、死亡確認に係る処理をおこなう（ステップＳ１３）。具体的には、コールセンターの端末２１に表示される督促情報に、死亡確認の指示を追加する。コールセンターのオペレータは端末２１に表示されている督促情報を参照しながら、顧客に死亡確認の旨の電話をかけ、確認結果（死亡していない）を入力する。
【００６９】
債権管理システム１０は、オペレータによる入力情報に基づいて、顧客が死亡したか否かを判断する（ステップＳ１４）。顧客が死亡していない（一般的な未入金）と判断すると、引続き督促処理をおこない（ステップＳ３）、更に督促処理に伴う演算処理を行う（ステップＳ４）。新しい債権残高を確認し、債権残高がゼロか否か、すなわち債権管理を終了するか判断し（ステップＳ５）、債権残高が残っているため、ステップＳ１に戻り、翌月の入金確認に係る判断を待つ。
【００７０】
・死亡時の例（Ｓ１→Ｓ１１→Ｓ１２→Ｓ１３→Ｓ１４→Ｓ１５→Ｓ１２→Ｓ１６→Ｓ１８→Ｓ４→Ｓ５）
債権管理システム１０は、金融機関を介して入金情報を取得し、入金の有無を確認する（ステップＳ１）。入金を確認できないと、データベース１７を参照し、死亡・高度障害特約の有無を判断する（ステップＳ１１）。死亡・高度障害特約があると判断すると、死亡・高度障害フラグのＯＮ／ＯＦＦを判断する（ステップＳ１２）。初期設定では死亡・高度障害フラグはＯＦＦとなっており、死亡・高度障害フラグがＯＦＦであると判断すると、死亡確認に係る処理をおこなう（ステップＳ１３）。具体的には、コールセンターの端末２１に表示される督促情報に、死亡確認の指示を追加する。コールセンターのオペレータは端末２１に表示されている督促情報を参照しながら、顧客に死亡確認の旨の電話をかけ、確認結果（死亡）を入力する。
【００７１】
債権管理システム１０は、オペレータによる入力情報に基づいて、顧客が死亡したか否かを判断する（ステップＳ１４）。顧客死亡（特殊事情により未入金）と判断すると、データベース１７の死亡・高度障害フラグをＯＮにする（ステップＳ１５）。
【００７２】
ステップ１２に戻り、死亡・高度障害フラグのＯＮ／ＯＦＦを判断し（ステップＳ１２）、死亡・高度障害フラグがＯＮであると判断すると、データベース１７の入金履歴に基づいて、死亡・高度障害特約を適用するか否か判断する（ステップＳ１６）。
【００７３】
例えば、Ｎ回以上の滞納があった場合には、死亡・高度障害特約を適用しないと判断する。Ｎ回以上の滞納がないと判断すると、債権放棄に係る処理をおこなう（ステップＳ１８）。債権放棄する債権額を雑損失として会計処理システム２３に出力する。更に督促処理に伴う演算処理を行う（ステップＳ４）。具体的には、債権残高をゼロにする。債権管理を終了するか判断し（ステップＳ５）、債権残高がゼロであるため、債権管理を終了する。
【００７４】
・特約不適用の例（Ｓ１→Ｓ１１→Ｓ１２→Ｓ１３→Ｓ１４→Ｓ１５→Ｓ１２→Ｓ１６→Ｓ１７→Ｓ４→Ｓ５）
特約があり、死亡フラグがＯＮであっても、Ｎ回以上の滞納があった場合には、死亡・高度障害特約を適用しない。ステップ１６において、債権管理システム１０が死亡・高度障害特約を適用しないと判断すると、相続人請求に係る処理をおこなう（ステップＳ１７）。
【００７５】
〜効果〜
団体信用生命保険を利用したビジネスモデルは、顧客に安心を与えることによる販売促進効果がある一方、煩雑な事務手続きによる販売抑制効果もある。さらに、団体信用生命保険を利用したビジネスモデルを従来技術の債権管理システムに組み込むのは難しい。その結果、無用の督促をおこなうおそれなどあった。団体信用生命保険に係るビジネスモデルに代わる新たなビジネスモデルおよび新たなビジネスモデルを実現する債権管理システムが求められている。
【００７６】
動作説明で述べたように、本実施形態の債権管理システム１０は、新たなビジネスモデルを実現できる。
【００７７】
すなわち、新たなビジネスモデルでは、債務者が死亡したり高度障害状態になったりし、支払能力を欠くに至った場合には、信販会社は債権放棄する。これにより、団体信用生命保険が適用された場合と同様に、遺族が過度の負担を強いられることはなくなる。その結果、顧客に安心を与え、販売促進効果を得る。
【００７８】
一方、新たなビジネスモデルは、法律関係が単純であるため、割賦契約の際に簡単な記載（例えばチェックボックス）を追加するのみでよく、顧客、販売店、信販会社の全てが、団体信用生命保険の保険契約のような煩雑な事務手続きから解放される。また、特約申請時の手続きも団体信用生命保険の申請手続きに比べて簡略化され、遺族や家族は確実に保護される。事務手続きの簡略化より、販売店および信販会社は、更なる販売促進効果を期待できる。
【００７９】
更に、死亡（高度障害）確認により、無用の督促を防止できる。これにより、信販会社のオペレーションを効率化できるとともに、遺族や家族の負担を軽減できる。
【００８０】
本ビジネスモデルは、従来の債権管理システムに特約処理部１６を追加し、データベース１７に特約処理に係る情報を追加するだけで、実現できる。
【００８１】
また、本実施形態の債権管理システム１０は、他のシステムとの相性もよい。たとえば、債権管理システム１０は、債権放棄する債権額を雑損失として会計処理システム２３に出力する。会計処理システム２３は、出力データに基づいて会計処理をおこなう。これにより、信販会社のオペレーションを効率化できる。
【００８２】
〜変形例〜
本発明は、上記実施形態に限定されるものではなく、技術思想の範囲で種々変形可能である。
【００８３】
・変形例１
図４は、変形例に係る債権管理システム１０の処理内容を示すフローチャートである。
【００８４】
上記実施形態では、ステップ１６において、特約を適用するか否か判断するか否かの判断をおこなったが、一部適用する判断を追加してもよい。
【００８５】
すなわち、ステップ１６において、ケース１〜３のいずれかに該当するか判断する。
【００８６】
ケース１：特約処理部１６は、入金履歴に基づいて、Ｎ回以上の滞納があった場合には、死亡・高度障害特約を適用しないと判断する。ステップ１６において、ケース１に該当すると判断すると、相続人請求に係る処理をおこなう（ステップＳ１７）。
【００８７】
ケース２：特約処理部１６は、入金履歴に基づいて、滞納がない場合には、死亡・高度障害特約を適用すると判断する。ステップ１６において、ケース２に該当すると判断すると、債権放棄に係る処理をおこなう（ステップＳ１８）。
【００８８】
ケース３：特約処理部１６は、入金履歴に基づいて、Ｎ回数未満の滞納があった場合には、滞納総額を除外して、死亡・高度障害特約を適用すると判断する。ステップ１６において、ケース３に該当すると判断すると、一部適用に係る処理をおこなう（ステップＳ１９）。
【００８９】
一部適用に係る処理の具体例を図１のケースを参照して説明する。
【００９０】
顧客は、２００万円の商品を購入し、支払総額２２０万円、支払い回数２０回および各回の支払額１１万円との割賦契約を信販会社と締結した。その後、顧客は、１２回目（総額１３２万円）まで適切に入金したが、１３回目、１４回目を滞納した時点で死亡した。
【００９１】
例えば、Ｎ＝３とすると、顧客の滞納回数２回は、３回未満であるので、特約処理部１６は、ケース３に該当すると判断する。
【００９２】
演算処理部１５は、債務残高８８万円（＝２２０万円−１３２万円）から、滞納総額２２万円（＝１１万円×２回）を除外した６６万円（＝８８万円−２２万円）を演算し、特約処理部１６は、６６万円に対し債務放棄に関する処理をおこなう。
【００９３】
一方、特約処理部１６は、滞納総額２２万円に遅延金を加算した額について相続人請求に係る処理をおこなう。
【００９４】
これにより、適切に支払いを続けた優良な顧客を確実に保護する。優良な顧客にインセンティブを与え、優良でない顧客にペナルティを課す結果、債務者は適切に毎回支払うように努め、債権回収の実効性が向上する。また、何かしらの理由で支払いが遅滞した優良な顧客を救済できる。
【００９５】
・変形例２
上記実施形態では、ステップ１６において、特約処理部１６は、入金履歴に基づいて、死亡・高度障害特約を適用するか否か判断したが、更に、システム管理者の判断が反映されるように構成されていてもよい。
【００９６】
例えば、システム管理者用の端末２２のモニターに、債務者識別番号、債権総額、金利相当額、分割回数、入金履歴（滞納履歴を含む）、債権残高等死亡・高度障害特約の有無、死亡・高度障害フラグに加えて、特約適用の判断結果が表示された状態で、特約処理部１６は、システム管理者の入力指示を待つ。たとえば、端末２２のモニターに、指示入力を促すメセージを追加表示する。
【００９７】
システム管理者は、諸事情を勘案して問題なければ、特約適用許可の指示を入力する。一方、顧客との契約が不法不当な目的で締結されたものであることが判明したなど、特約を適用すべきでないと判断するときは、特約適用不許可の指示を入力する。
【００９８】
特約処理部１６は、入力指示に基づいて、債権放棄に係る処理（ステップＳ１８）または相続人請求に係る処理をおこなう（ステップＳ１７）。
【００９９】
〜補足（別の背景）〜
本実施形態のビジネスモデルは、団体信用生命保険への加入を停止する代わりに、債務者が死亡したり高度障害状態になったりし、支払能力を欠くに至った場合には、信販会社は債権放棄するものであり、言い換えると、債権未回収のリスクを信販会社が負担するものである。
【０１００】
団体信用生命保険に係る契約は、信販会社と生命保険会社との間で結ばれ、信販会社は利益の中から保険料を負担している。顧客が死亡した場合でも、債権回収が確実にでき、短期的なメリットはある。しかし、団体信用生命保険適用に起因して保険契約更新時の保険料が値上がりすると、長期的には信販会社の利益が減ることになる。
【０１０１】
発明者らは、過去の運用実績や、年齢ごとの死亡率に基づいて、綿密な統計解析を実施したところ、信販会社が回収不能と見込まれる債権総額より、将来負担まで考慮した保険料のほうが、高額であることを見出した。すなわち、債権未回収のリスクを信販会社が負担した方が、信販会社の利益向上になるとの結論に至り、新たなビジネスモデルを開発した。
【０１０２】
本発明は、新しいビジネスモデルを実現するための債権管理システムである。
【符号の説明】
【０１０３】
１０  債権管理システム
１１  中央管理部
１２  入金管理部
１３  通常処理部
１４  督促処理部と、
１５  演算処理部
１６  特約処理部
１７  データベース
２１  コールセンター端末
２２  システム管理者用端末
２３  会計処理システム
【図１】
2014016783.tif 000003
【図２】
2014016783.tif 000004
【図３】
2014016783.tif 000005
【図４】
2014016783.tif 000006