JP2022041097A - 代位弁済情報管理装置、代位弁済情報管理方法、及び代位弁済情報管理プログラム - Google Patents

Abstract

【課題】本発明は、代位弁済が不要になった場合であっても、手間を要することなく精確に債務と債権の双方を管理することができる代位弁済情報管理装置、代位弁済情報管理方法、及び代位弁済情報管理プログラムを提供することを目的とする。【解決手段】本発明に係る代位弁済情報管理装置は、代位弁済に関する情報を管理するための情報処理装置である。この代位弁済情報管理装置の制御部は、代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新するとともに、前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する。【選択図】図２

Description

本発明は、代位弁済情報管理装置、代位弁済情報管理方法、及び代位弁済情報管理プログラムに関する。

特許文献１には、販売者に生ずる債権が譲り渡された場合において、その代金を販売者により指定される金融機関口座に振り込むことが記載されている。このように、第三者が、債権者（販売者）が有していた原債権を取得することは、代位弁済と称され、この第三者には、求償債権が発生する。

特許第６６７４５７８号公報

代位弁済は、商品の販売の場面だけでなく、不動産の賃貸借の場面でも生じる。不動産物件の賃貸主（例えば、不動産の賃貸主又はその管理会社）は、賃借主に滞納（現場では「事故」とも称される）があった場合に、賃貸主の依頼又は事故報告を受けて、賃借主の家賃保証会社（以下、単に「保証会社」ともいう）が代位弁済することがある。このような代位弁済は、不動産の賃貸主又はその管理会社との賃料保証契約に基づいて行われる。

代位弁済が行われた場合、賃借人は、代位弁済分を保証会社へ支払わなければならない。しかしながら、賃借人は、そうせずに、賃貸主へ支払いを行ってしまうことが多い。その理由としては、普段の家賃の支払い先の口座（すなわち管理会社指定の口座）を振込みに利用してしまうことが挙げられる。このような事態が生じると、賃貸主は、保証会社からの代位弁済の入金分と、賃借人が支払った入金分とを受け取ることになる（重複入金）。

重複入金の事態が生じた場合又はそのような事態が生じそうになった場合、管理会社は、保証会社へ連絡して、代位弁済分が不要になった旨（代位弁済不要情報）を伝えることになる。ここで、代位弁済の入金が確認できていない段階においては、代位弁済の依頼を取り下げる等の手段も採り得る。他方で、代位弁済の入金がなされている場合には、代位弁済の依頼を取り下げることに代えて、代位弁済分を返金することにより、収支を一致させることが可能となる。

一方で、保証会社は、代位弁済の依頼を受けた時点で、賃借人に対する求償債権が発生するものと管理していることが多い。そのため、保証会社は、管理会社への代位弁済分の支払い（債務）と、賃借人に対する求償債権（債権）との両方を管理することとなるが、管理会社から代位弁済不要情報を取得して初めて、債務と債権をどうすべきかで新たな管理の手間が生じることとなる。このような新たな管理の手間を従業員が手作業で実施すると、債務又は債権の一方の消込みが実施されず、その結果、例えば債権の消込み漏れが生じると賃貸主へ代位弁済分の返済を通知（督促）してしまいかねない。ここで、本業界に特有の事情として、賃借人としては、滞納はしたものの（本人としては）速やかに家賃の支払いを済ませたと思っているところに保証会社から賃借人への督促がなされることで生じる三者間のトラブル（賃借人及び保証会社間のトラブル又は賃借人及び管理会社間のトラブル）を可能な限り回避するといった、賃借人の機嫌を損ねないための努力が求められている。そのため、保証会社としては、代位弁済が不要になった場合、特には、代位弁済が支払い済であっても管理会社に重複入金があった場合には、賃借人に対する債権を速やかにかつ精確に取り消すことが求められる。

本発明は、上述の問題（要求）に鑑みてなされたものであって、代位弁済が不要になった場合であっても、手間を要することなく精確に債務と債権の双方を管理することができる代位弁済情報管理装置、代位弁済情報管理方法、及び代位弁済情報管理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る代位弁済情報管理装置は、代位弁済に関する情報を管理するための、制御部を備えた代位弁済情報管理装置であって、前記制御部は、代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新する支払管理データ更新手段と、前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する債権管理データ更新手段とを備えることを特徴とする。

また、本発明に係る代位弁済情報管理装置は、前記支払管理データ更新手段は、前記代位弁済不要情報に基づき、支払い前の代位弁済を消し込むための支払予定消込データを生成することにより、前記支払管理データの更新を行い、前記債権管理データ更新手段は、前記代位弁済不要情報に基づき、代位弁済によって生じる予定であった債権を消し込むための債権消込データを生成することにより、前記債権管理データの更新を行うことを特徴とする。

さらに、本発明に係る代位弁済情報管理装置は、前記支払管理データ更新手段は、支払い前の代位弁済が複数である場合、前記支払予定消込データとして、前記複数の代位弁済の支払予定金額の総額に関する情報を含む支払予定消込データを生成することを特徴とする。

さらにまた、本発明に係る代位弁済情報管理装置は、前記支払管理データ更新手段は、前記複数の代位弁済の支払予定金額の総額に関する情報を含む支払予定消込データを代位弁済依頼元ごとに生成することを特徴とする。

また、本発明に係る代位弁済情報管理装置は、前記制御部は、前記代位弁済不要情報に基づき、支払い後の代位弁済に応じた代位弁済依頼元への請求に関する請求データを生成する請求データ生成手段をさらに含むことを特徴とする。

また、本発明に係る代位弁済情報管理装置は、前記代位弁済は、不動産の賃貸主又はその管理会社との賃料保証契約に係る代位弁済であり、前記代位弁済不要情報は、前記不動産の賃貸主又はその管理会社からの賃借主からの重複入金に関する情報であることを特徴とする。

また、本発明に係る代位弁済情報管理方法は、制御部を備えた情報処理装置において実行される、代位弁済に関する情報を管理するための代位弁済情報管理方法であって、前記制御部において実行される、代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新する支払管理データ更新ステップと、前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する債権管理データ更新ステップとを含むことを特徴とする。

また、本発明に係る代位弁済情報管理プログラムは、制御部を備えた情報処理装置において実行される、代位弁済に関する情報を管理するための代位弁済情報管理プログラムであって、前記制御部において実行させるための、代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新する支払管理データ更新ステップと、前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する債権管理データ更新ステップとを含むことを特徴とする。

本発明によれば、代位弁済が不要になった場合であっても、手間を要することなく精確に債務と債権の双方を管理することができるという効果を奏する。

図１は、本発明の実施形態に係る代位弁済情報管理装置を含む代位弁済情報管理システムの構成の一例を示すブロック図である。 図２は、図１の代位弁済情報管理システム１０００において、代位弁済情報管理装置１００が実行する代位弁済情報管理方法の処理手順を示すフローチャートである。 図３は、図２のステップＳ２１０で受信し得る代位弁済依頼データの構成例を模式的に示す図である。 図４は、図２のステップＳ２２０で生成される支払予定データの構成例を模式的に示す図である。 図５は、図２のステップＳ２３０で生成される債権データの構成例を模式的に示す図である。 図６は、図２のステップＳ２５０で生成される重複入金データの構成例を模式的に示す図である。 図７は、図２のステップＳ２７０の重複入金処理の詳細を示すサブルーチンのフローチャートである。 図８は、図７のステップＳ２７４で生成される支払予定消込データを含む支払管理データの構成を模式的に示す図である。 図９は、図７のステップＳ２７５で生成される債権消込データを含む債権管理データの構成を模式的に示す図である。 図１０は、図７のステップＳ２７７で生成される請求データの構成を模式的に示す図である。 図１１は、図９に示した債権管理データに、重複入金処理の対象でない債権データに対する債権消込データのレコードが追加された状態を示す図である。

本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。

［１．構成］
本実施形態に係る代位弁済情報管理装置を含む代位弁済情報管理システムの構成の一例について、図１を参照して説明する。図１は、本発明の実施形態に係る代位弁済情報管理装置を含む代位弁済情報管理システムの構成の一例を示すブロック図である。

図１に示す代位弁済情報管理システム１０００は、情報処理装置としての代位弁済情報管理装置１００と、サーバ２００と、代位弁済情報管理装置１００及びサーバ２００を通信可能に接続するネットワーク３００とを含んでいる。

代位弁済情報管理装置１００は、代位弁済に関する情報を管理するための情報処理装置であり、例えば市販のデスクトップ型パーソナルコンピュータで構成される。この代位弁済情報管理装置１００は、例えば、家賃保証会社内における代位弁済に基づく債務及び債権を管理する部門（例えば、経理部門）に１台設置されている。なお、代位弁済情報管理装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。また、代位弁済情報管理装置１００は、代位弁済情報管理システム１０００内において複数台設置されていてもよく、複数台の代位弁済情報管理装置１００の間で同期をとることで１台の代位弁済情報管理装置１００として機能してもよい。

代位弁済情報管理装置１００は、制御部１０２と、通信インターフェース部１０４と、記憶部１０６と、入出力インターフェース部１０８とを備えている。代位弁済情報管理装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

通信インターフェース部１０４は、ルータ等の通信装置及び専用線等の有線又は無線の通信回線を介して、代位弁済情報管理装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、代位弁済情報管理装置１００とサーバ２００とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。したがって、通信インターフェース部１０４は、他の情報処理装置（例えば賃貸主（管理会社）や取引銀行の情報処理装置）からの情報等を、ネットワーク３００を介して又はネットワーク３００及びサーバ２００を介して受け付けることが可能に構成されているとともに、所定の情報処理装置（例えば賃貸主（管理会社）や賃借人の情報処理装置）に対して所定の情報を出力することが可能に構成されている。

記憶部１０６には、各種のデータベース、テーブル、及びファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラム（本発明のプログラムを含む）が記録される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、及び光ディスク等を用いることができる。また、この記憶部１０６には、本発明のプログラムを実施するために用いられる各種のデータが書き出し／読み出し可能に格納されている。

入出力インターフェース部１０８には、入力装置１１２及び出力装置１１４が接続されている。出力装置１１４には、モニタ（家庭用テレビを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。

制御部１０２は、代位弁済情報管理装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。

さらに図１を参照しながら、記憶部１０６及び制御部１０２の構成について詳述する。

記憶部１０６は、図１に示されるように、代位弁済不要情報記憶領域１０６ａと、支払管理データ記憶領域１０６ｂと、債権管理データ記憶領域１０６ｃと、請求データ記憶領域１０６ｄとを含む。また、記憶部１０６は、その他のマスタやデータ記憶領域を備えていてもよい。

代位弁済不要情報記憶領域１０６ａ、支払管理データ記憶領域１０６ｂ、債権管理データ記憶領域１０６ｃ、請求データ記憶領域１０６ｄは、それぞれ、後述する代位弁済不要情報、支払管理データ、債権管理データ、請求データを記憶するための領域であり、必要に応じて各データを出力可能に保持する。

制御部１０２は、図１に示されるように、複数のモジュールを備えている。図１に示す例では、制御部１０２は、支払管理データ更新部１０２ａと、債権管理データ更新部１０２ｂと、請求データ生成部１０２ｃとを備えている。

支払管理データ更新部１０２ａは、代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新する支払管理データ更新手段として機能するモジュールである。債権管理データ更新部は、前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する債権管理データ更新手段として機能するモジュールである。請求データ生成部１０２ｃは、前記代位弁済不要情報に基づき、支払い後の代位弁済に応じた代位弁済依頼元への請求に関する請求データを生成するとして機能するモジュールである。各部の機能は、後述する処理内容を実現する機能を含む。

［２．処理］
次に、図１に示す代位弁済情報管理システム１０００において実行される代位弁済情報管理方法を例示的に説明する。

図２は、図１の代位弁済情報管理システム１０００において、代位弁済情報管理装置１００が実行する代位弁済情報管理方法の処理手順を示すフローチャートである。この図２に示す処理は、概略的には、代位弁済に関する情報を管理するに際し、代位弁済が不要との情報（代位弁済不要情報）が取得された場合には、支払管理データを更新するとともに、債権管理データを更新するというものであり、本処理の大部分は、代位弁済情報管理装置１００の制御部１０２において実行される。なお、以下では、代位弁済が、不動産の賃貸主又はその管理会社との賃料保証契約に係る代位弁済であり、代位弁済不要情報が、前記不動産の管理会社からの賃借主からの重複入金に関する情報である場合の例を挙げて説明する。

図２において、まず、ステップＳ２１０では、代位弁済依頼情報を取得するのを待機する。代位弁済依頼は、通常、賃借人に滞納があった場合に、賃貸主又はその管理会社から、賃借人の家賃保証会社へなされる。代位弁済依頼情報は、明示的な代位弁済の依頼に限られず、賃借人に滞納（事故）があった旨の連絡等であってもよいし、滞納があった賃借人のリストを含む代位弁済依頼データの受信等であってもよい。図３は、図２のステップＳ２１０で受信し得る代位弁済依頼データの構成例を模式的に示す図である。図３に示すように、代位弁済依頼データは、滞納があった賃借人を特定する情報（例えば契約キー及び契約者名）と、代位弁済依頼金額に関する情報と、請求月に関する情報とを含むことが好ましい。代位弁済依頼金額は、通常、滞納額と同一である。そして、代位弁済依頼情報を取得した場合には（ステップＳ２１０でＹｅｓ）、ステップＳ２２０に進む。

ステップＳ２２０では、ステップＳ２１０で取得した代位弁済依頼情報に基づき、所定フォーマットの支払予定データを生成する。ここで生成される支払予定データは、代位弁済依頼金額に対応する弁済金額に関する支払予定データある。生成された支払予定データは、支払管理データ中で新たなレコードとして保存される。なお、ステップＳ２１０で取得した代位弁済依頼情報が支払予定データのフォーマットに準じている場合にはそのまま又は任意に加工して用いてもよい。また、代位弁済依頼情報に含まれる滞納があった賃借人（契約者）が複数である場合には、代位弁済依頼金額の合計額を算出し、１つの支払予定データを生成することが好ましい。

図４は、図２のステップＳ２２０で生成される支払予定データの構成例を模式的に示す図である。

図４に示す支払予定データは、図３に示した代位弁済依頼データに応じて作成されたものであり、複数の契約者分が１つにまとめられている。支払予定データは、図４に示すように、弁済先（すなわち代位弁済依頼元）を特定する情報（例えば、管理会社コード及び管理会社名）と、弁済金額に関する情報と、支払日に関する情報とを含む。支払日は、月次で管理する場合等においては、支払月としてもよい。

続いて、ステップＳ２３０では、ステップＳ２１０で取得した代位弁済依頼情報に基づき、所定フォーマットの債権データを生成する。ここで生成される債権データは、代位弁済依頼に基づき取得した求償債権に関する債権データである。生成された債権データは、債権管理データ中で新たなレコードとして保存される。なお、ステップＳ２１０で取得した代位弁済依頼情報が債権データのフォーマットに準じている場合にはそのまま又は任意に加工して用いてもよい。

図５は、図２のステップＳ２３０で生成される債権データの構成例を模式的に示す図である。

図５に示す債権データは、図３に示した代位弁済依頼データに応じて作成されたものである。債権データは、図５に示すように、滞納があった賃借人を特定する情報（例えば契約キー及び契約者名）と、求償債権金額に関する情報と、滞納月数に関する情報とを含む。求償債権金額は、通常、滞納額と同一である。ここで、求償債権とは、代位弁済依頼に基づき取得した債権であって、好ましくは、弁済完了により発生したものとして管理されることが好ましい。そこで、債権データは、図５に示すように、求償債権発生日に関する情報をさらに含むことが好ましい。求償債権発生日は、月次で管理する場合等においては、求償債権発生月としてもよい。債権データは、求償債権発生日に関する情報に代えて、弁済完了の有無に関するフラグ又は求償債権発生の有無に関するフラグを含んでいてもよい。

上述したステップＳ２１０～Ｓ２３０では、代位弁済依頼情報が取得されると、支払予定データ（債務に関するデータ）と、債権データとが自動的に生成されて支払管理データと債権管理データとが更新されることとなる。なお、生成された支払予定データ及び債権データは、ユーザによる任意の編集（修正や加工）を受け付け可能に構成されている。

その後、ステップＳ２４０では、重複入金情報が取得されたかどうかを判別する。重複入金とは、代位弁済依頼に係る滞納金額につき（保証会社が弁済金額を入金したかどうかにかかわらず）、賃借人が賃貸主である管理会社へ入金してしまうことをいう。したがって、重複入金情報は、保証会社にとっては、代位弁済不要情報に該当する。重複入金情報は、明示的な重複入金の連絡に限られず、滞納があった賃借人から入金があった旨の連絡等であってもよいし、重複入金があった賃借人のリストを含む重複入金報告データの受信等であってもよい。そして、重複入金情報が取得されていない場合には（ステップＳ２４０でＮｏ）、後述するステップＳ２８０に進み、他方、重複入金情報が取得された場合には（ステップＳ２４０でＹｅｓ）、ステップＳ２５０に進む。

ステップＳ２５０では、ステップＳ２４０で取得された重複入金情報に基づき、所定フォーマットの重複入金データを生成する。ここで生成される重複入金データは、重複入金金額に関するデータある。なお、ステップＳ２４０で取得した重複入金情報が重複入金データのフォーマットに準じている場合にはそのまま又は任意に加工して用いてもよい。図６は、図２のステップＳ２５０で生成される重複入金データの構成例を模式的に示す図である。図６に示すように、重複入金データは、重複入金があった賃借人を特定する情報（例えば契約キー及び契約者名）と、重複入金金額に関する情報と、入金月に関する情報とを含むことが好ましい。重複入金金額は、通常、滞納額と同一である。重複入金データは、図６に示すように、弁済依頼元（すなわち管理会社）を特定する情報を含んでいることが好ましい。

そして、ステップＳ２６０では、重複入金処理を開始するかどうかを判別する。重複入金処理の詳細についてはステップＳ２７０で後述する。この重複入金処理の開始は、任意のタイミングで実行可能であり、例えば日次の予め指定された時刻で行われるが、これに代えて月次で行われてもよいし、重複入金処理はユーザの指示に基づいて開始されてもよい。重複入金処理を開始しない場合には（ステップＳ２６０でＮｏ）、ステップＳ２１０に戻って、代位弁済依頼情報の取得、重複入金情報の取得を待機する。他方、重複入金処理を開始する場合には、ステップＳ２７０に進む。

図７は、図２のステップＳ２７０の重複入金処理の詳細を示すサブルーチンのフローチャートである。

ステップＳ２７０の重複入金処理において、まず、ステップＳ２７１では、ステップＳ２６０で生成した重複入金データの読出しを行う。続く、ステップＳ２７２では、ステップＳ２７１で読出した重複入金データから、１つの代位弁済依頼元（例えば「京橋不動産」）を特定する。

そして、ステップＳ２７３では、特定した代位弁済依頼元に関する重複入金データにつき、代位弁済の支払いが済んでいない分のレコード（代位弁済未払い分のレコード）があるかどうかを判別する。代位弁済未払い分のレコードは１つであってもよいし、複数であってもよい。

代位弁済の支払いが済んでいないかどうかは、例えば、以下のようにして判別することが可能である。まず、重複入金データ（図６）に含まれている重複入金があった賃借人を特定する情報（例えば契約キー及び契約者名）に基づき、債権管理データ（図５）を参照して、滞納があった賃借人を特定する情報（例えば契約キー及び契約者名）とが一致するレコードがあるかどうかを判別し、続いて、一致した賃借人を特定する情報に基づき、支払管理データ（図４）を参照して、対応するレコードにおいて、支払日（支払予定日）が経過していないかどうかを判別する。これに代えて、債権管理データ（図５）において求償債権の発生日又はそのフラグが管理されている場合には、これらの情報により、代位弁済の支払いが済んでいない旨の情報を取得するようにしてもよい。なお、判別の方法は上述の例に限られることはなく任意の方法を採用可能である。

そして、ステップＳ２７３の判別の結果、代位弁済未払い分がある場合には、ステップＳ２７４～Ｓ２７５の消込処理に進み、他方、代位弁済未払い分がない場合には、ステップＳ２７４～Ｓ２７５の消込処理をスキップして、ステップＳ２７６に進む。

代位弁済未払い分がある場合（ステップＳ２７３でＹｅｓ）、まず、ステップＳ２７４では、支払予定消込データを生成する。ここで生成される支払予定消込データは、代位弁済未払い分の金額に対応する弁済金額にマイナスの符号を付した金額に関する支払予定消込データある。生成された支払予定消込データは、支払管理データ中で新たなレコードとして保存される。なお、重複入金があった賃借人（契約者）が複数であった場合（すなわち代位弁済未払い分のレコードが複数である場合）には、弁済金額にマイナスの符号を付した金額の合計額を算出し、１つの支払予定消込データを生成することが好ましい。

図８は、図７のステップＳ２７４で生成される支払予定消込データを含む支払管理データの構成を模式的に示す図である。図８に示す支払管理データは、図４に示した支払管理データに対し、ステップＳ２７４の処理の結果、図６の重複入金金額の合計にマイナスの符号を付した金額に関する情報を含む支払予定消込データの１つのレコードが追加された状態を示している。このように、支払管理データへ支払予定消込データを追加することで、既存の支払予定データに含まれる代位弁済の金額の全部又は一部を消し込むことが可能となる。

続くステップＳ２７５では、ステップＳ２７４の支払予定データの消込みと同様に、債権データの消込が行われる。具体的には、債権消込データが生成される。ここで生成される債権消込データは、求償債権金額にマイナスの符号を付した金額に関する債権消込データある。生成された債権消込データは、債権管理データ中で新たなレコードとして保存される。債権消込データと対となる債権データについては、求償債権に基づく督促が行われないように、例えば督促状況を示すフラグ等を用いて管理することが好ましい。

図９は、図７のステップＳ２７５で生成される債権消込データを含む債権管理データの構成を模式的に示す図である。図９に示す債権管理データは、図５に示した債権管理データに対し、ステップＳ２７５の処理の結果、図６の重複入金金額にマイナスの符号を付した金額に関する情報を含む債権消込データの２つのレコードが追加された状態を示している。このように、債権管理データへ債権消込データを追加することで、既存の債権データに含まれる求償債権金額の全部又は一部を消し込むことが可能となる。なお、図９に示すように、債権消込データの対象でない債権データがある場合には、求償債権の発生日又はそのフラグを管理することが好ましく、他方で、債権消込データの対象となる債権データについては、求償債権の発生日又はそのフラグをＮｕｌｌに変更する等、予め設定された方法にしたがって管理されることが好ましい。そして、ステップＳ２７６の処理に進む。

ステップＳ２７６では、代位弁済の支払いが済んでいる分のレコード（代位弁済支払い済分のレコード）があるかどうかを判別する。この判別方法は、ステップＳ２７３の判別方法と同様であるのでその説明を割愛する。代位弁済支払い済分のレコードは１つであってもよいし、複数であってもよい。ステップＳ２７６の判別の結果、代位弁済支払い済分がある場合には、ステップＳ２７７の消込処理に進み、他方、代位弁済支払い済分がない場合には、ステップＳ２７７の消込処理をスキップして、ステップＳ２７８に進む。

代位弁済支払い済分がある場合（ステップＳ２７６でＹｅｓ）、ステップＳ２７７では、請求データを生成する。ここで生成される請求データは、代位弁済支払い済分の弁済金額と同額の金額を請求金額情報（債権）として含む請求データある。

図１０は、図７のステップＳ２７７で生成される請求データの構成を模式的に示す図である。図１０に示す請求データは、図６に示した重複入金データに含まれる重複入金金額の合計のうち、代位弁済支払い済分の弁済金額の合計が１５０，０００円であって、それと同額の金額を請求金額情報として含む例を示している。このように生成される請求データは、ステップＳ２７２で特定した代位弁済依頼元の管理会社への請求（返金要求）のために用いられる。このように代位弁済が支払い済である場合に請求データを生成する理由は、管理会社は、滞納があった賃借人からも保証会社からも入金を既に受け取った状態にあるため、保証会社は、管理会社からの返金を受け付け（代位弁済依頼がなかったものとして扱い）、かつ、賃借人に対する求償債権を取り消すことで、賃借人との間で生じ得るトラブルを未然に防止できるからである。なお、重複入金があった賃借人（契約者）が複数であった場合（すなわち代位弁済支払い済分のレコードが複数である場合）には、弁済金額の合計額を算出し、１つの請求データを生成することが好ましい。なお、代位弁済支払い済分がない場合には、請求金額情報がゼロ又はＮｕｌｌの請求データを生成してもよく、これにより、当日の重複入金処理完了のレコードを残すようにしてもよい。そして、ステップＳ２７８の処理に進む。

その後、ステップＳ２７８では、ステップＳ２７１で読出した重複入金データにつき、他の代位弁済依頼元があるかどうかを判別する。この判別の結果、他の代位弁済依頼元がある場合には（ステップＳ２７８でＹｅｓ）、ステップＳ２７２に戻って、１つの代位弁済依頼元を特定して、上述したステップＳ２７４～Ｓ２７７の一連の処理を実行する。他方で、他の代位弁済依頼元がない場合には、すべての重複入金データについての処理が完了したと判断して、図７に示す処理を完了して、図２の処理にリターンし、ステップＳ２８０の処理に進む。

ステップＳ２８０では、残りの債権について、回収がなされたかどうかを判別する。残りの債権は、図９に示した重複入金処理の対象でない求償債権（契約者Ｂに対する求償債権）と、図１０に示した請求データに係る管理会社への債権（返金）が該当する。該判別の結果、回収がなされていない場合には（ステップＳ２８０でＮｏ）、重複入金情報の取得を待機すべく、ステップＳ２４０に戻る。他方、これら債権について、回収がなされた場合には（ステップＳ２８０でＹｅｓ）、相応の消込データを作成する（ステップＳ２９０）。作成された消込データは、必要に応じて、支払管理データ、債権管理データ、請求データに新たなレコードとして追加される。例えば、賃借人が求償債権に基づく督促に応じて入金を行った場合には、債権消込データが生成されて、新たなレコードとして追加される（図１１参照）。これにより、代位弁済依頼のあった弁済金額につき、すべての収支が一致することとなる。そして、本処理を完了する。

以上詳細に説明したように、図２に示した代位弁済情報管理方法の一連の処理によれば、代位弁済に関する情報を管理するに際し、代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データが更新され（ステップＳ２７４）（支払管理データ更新手段）、かつ、前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データが更新される（ステップＳ２７５）（債権管理データ更新手段）。具体的には、前記代位弁済不要情報に基づき、支払い前の代位弁済を消し込むための支払予定消込データを生成することにより（ステップＳ２７４）、前記支払管理データの更新が行われ、かつ、前記代位弁済不要情報に基づき、代位弁済によって生じる予定であった債権を消し込むための債権消込データを生成することにより（ステップＳ２７５）、前記債権管理データの更新が行われる。これにより、代位弁済が不要になった場合であっても、ユーザの手間を要することなく精確に債務と債権の双方を管理することができる。また、ユーザの
手間が削減されて処理の高速化を実現できる結果、代位弁済不要情報を取得した後のタイムラグが短縮化されるので、ユーザとのトラブルを発生しにくくすることができる。

また、図２の処理によれば、支払い前の代位弁済が複数である場合、前記支払予定消込データとして、前記複数の代位弁済の支払予定金額の総額に関する情報を含む支払予定消込データが生成される（ステップＳ２７１，Ｓ２７４）。このようにバッチ処理が可能であるので、債務をまとめて管理することができる。特に、管理対象の物件数が多い場合や、滞納しがちな賃借人が多い場合に有効であり、ユーザの手間を大幅に削減することができる。

さらに、図２の処理によれば、前記複数の代位弁済の支払予定金額の総額に関する情報を含む支払予定消込データが代位弁済依頼元ごとに生成される（ステップＳ２７１，Ｓ２７２，Ｓ２７４）。これにより、代位弁済依頼元ごとに債務を精確に管理することができる。

また、図２の処理によれば、前記代位弁済不要情報に基づき、支払い後の代位弁済に応じた代位弁済依頼元への請求に関する請求データが生成される（ステップＳ２７７）（請求データ生成手段）。これにより、ユーザとのトラブルを回避することができる。

また、図２の処理によれば、前記代位弁済は、不動産の賃貸主又はその管理会社との賃料保証契約に係る代位弁済であり、前記代位弁済不要情報は、前記不動産の賃貸主又はその管理会社からの賃借主からの重複入金に関する情報である。このように、本発明は、三社間の契約において債務と債権を精確に管理すべき技術分野において特に有効である。

なお、上述した実施形態では、支払管理データ及び債権管理データの更新の例として、消込データを生成する場合を説明したが、消込データを生成することに代えて、対象となる既存の支払予定データ又は債権データを削除するようにしてもよい。また、債権管理データについて、図５、図９、図１１を用いて、求償債権の発生日又はそのフラグを用いる例について説明したが、債権管理データはこれらの情報を含んでいなくてもよい。また、図６に示したような重複入金データは、弁済依頼元を特定できる場合には、当該情報を含んでいなくてもよい。

［３．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

また、代位弁済情報管理装置１００及び代位弁済情報管理システム１０００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

例えば、代位弁済情報管理装置１００が備える処理機能、特に制御部にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて代位弁済情報管理装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

また、このコンピュータプログラムは、代位弁済情報管理装置１００に対して任意のネットワーク（例えばネットワーク３００）を介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。したがって、本明細書で説明した処理を実行するためのプログラムを格納した記録媒体もまた本発明を構成することとなる。

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

記憶部１０６に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、及び、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、及び、ウェブページ用ファイル等を格納する。

また、代位弁済情報管理装置１００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、代位弁済情報管理装置１００は、当該装置に本明細書で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。

更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

本発明は、代位弁済に関する情報を管理する際において、特に重複入金があった場合に有用である。

１００ 代位弁済情報管理装置
１０２ 制御部
１０２ａ 支払管理データ更新部
１０２ｂ 債権管理データ更新部
１０２ｃ 請求データ生成部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 代位弁済不要情報記憶領域
１０６ｂ 支払管理データ記憶領域
１０６ｃ 債権管理データ記憶領域
１０６ｄ 請求データ記憶領域
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク
１０００ 代位弁済情報管理システム

Claims (8)

1. 代位弁済に関する情報を管理するための、制御部を備えた代位弁済情報管理装置であって、
   前記制御部は、
   代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新する支払管理データ更新手段と、
   前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する債権管理データ更新手段と
   を備える
   ことを特徴とする代位弁済情報管理装置。
2. 前記支払管理データ更新手段は、
   前記代位弁済不要情報に基づき、支払い前の代位弁済を消し込むための支払予定消込データを生成することにより、前記支払管理データの更新を行い、
   前記債権管理データ更新手段は、
   前記代位弁済不要情報に基づき、代位弁済によって生じる予定であった債権を消し込むための債権消込データを生成することにより、前記債権管理データの更新を行う
   ことを特徴とする請求項１に記載の代位弁済情報管理装置。
3. 前記支払管理データ更新手段は、
   支払い前の代位弁済が複数である場合、前記支払予定消込データとして、前記複数の代位弁済の支払予定金額の総額に関する情報を含む支払予定消込データを生成する
   ことを特徴とする請求項２に記載の代位弁済情報管理装置。
4. 前記支払管理データ更新手段は、
   前記複数の代位弁済の支払予定金額の総額に関する情報を含む支払予定消込データを代位弁済依頼元ごとに生成する
   ことを特徴とする請求項３に記載の代位弁済情報管理装置。
5. 前記制御部は、
   前記代位弁済不要情報に基づき、支払い後の代位弁済に応じた代位弁済依頼元への請求に関する請求データを生成する請求データ生成手段
   をさらに含む
   ことを特徴とする請求項１～４のいずれか１項に記載の代位弁済情報管理装置。
6. 前記代位弁済は、不動産の賃貸主又はその管理会社との賃料保証契約に係る代位弁済であり、
   前記代位弁済不要情報は、前記不動産の賃貸主又はその管理会社からの賃借主からの重複入金に関する情報である、
   ことを特徴とする請求項１～５のいずれか１項に記載の代位弁済情報管理装置。
7. 制御部を備えた情報処理装置において実行される、代位弁済に関する情報を管理するための代位弁済情報管理方法であって、
   前記制御部において実行される、
   代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新する支払管理データ更新ステップと、
   前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する債権管理データ更新ステップと
   を含む
   ことを特徴とする代位弁済情報管理方法。
8. 制御部を備えた情報処理装置において実行される、代位弁済に関する情報を管理するための代位弁済情報管理プログラムであって、
   前記制御部において実行させるための、
   代位弁済不要情報に基づき、代位弁済の支払状況に関する支払管理データを更新する支払管理データ更新ステップと、
   前記代位弁済不要情報に基づき、代位弁済によって生じ得る債権に関する債権管理データを更新する債権管理データ更新ステップと
   を含む
   ことを特徴とする代位弁済情報管理プログラム。

Images