Inheritance debt management system, inheritance debt management method, and program

Abstract

To provide an inheritance debt management system that manages a debt balance of an heir and, when an heir negotiates a debt, manages the debt balance reflecting status and a result of the negotiation.SOLUTION: A debt balance management system for managing debt for an heir 1 includes: a related party management unit 111 that acquires attribute data related to a debtor or a joint guarantor and an heir of the debtor or the joint guarantor; a debt management unit that acquires debt data related to the debt of the debtor or the joint guarantor; a payment management unit 112 that acquires payment data for the debt; and a calculation unit 120 that calculates, on the basis of the debt data and the payment data, a balance of the debt.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a system, a method, and a program for managing an heir's debt balance. [Background technology]

[0002] When a principal debtor dies, there is a need to accurately manage the heirs and the extent of their assets. However, currently, information about heirs is often managed on paper, and a systematization of this information is needed. For example, Patent Document 1 discloses a system in which an estate sorting company generates an heir relationship explanatory diagram in a tree structure of parent-child / sibling / marriage relationships based on non-decedents, generates inheritance information that includes at least property information and property distribution information for identified deceaseds among the people included in the heir relationship explanatory diagram, and manages heir procedures. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-0099627 Summary of the Invention [Problem to be solved by the invention]

[0004] However, Patent Document 1 does not allow for the continuous management of inherited debts by heirs. In particular, it is not possible to manage the outstanding debt balance after inheritance. In addition, if the heir negotiates the debt, specifically if they file for specific mediation or personal rehabilitation, if they settle through negotiations (including voluntary settlement), or if they undergo legal debt restructuring, it is not possible to manage the outstanding debt balance in a way that reflects these circumstances and results.

[0005] The present invention has been made based on this background, and aims to provide a debt management system, debt management method, and program that manages the outstanding debt balance of an heir and, if the heir negotiates the debt, manages the outstanding debt balance reflecting the status and results of the negotiation. [Means for solving the problem]

[0006] One aspect of the present invention for achieving the above goal is to provide a debt balance management system for managing the debt of an heir, which includes a related party management unit that acquires attribute data regarding the parties involved in the debt, including the debtor or guarantor and the heir of the debtor or guarantor, a debt management unit that acquires debt data regarding the debt of the debtor or guarantor, a deposit management unit that acquires deposit data for the debt, and a calculation unit that calculates the balance of the debt based on the debt data and the deposit data.

[0007] Although the present invention is in the category of a debt balance management system, the same effects and advantages can be achieved with a debt balance management method and program. [Effects of the Invention]

[0008] According to the present invention, the outstanding debt balance of an heir can be managed, and if a creditor negotiates with the heir regarding the debt, the outstanding debt balance can be managed to reflect the status and results of the negotiations. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a schematic diagram of a debt balance management system according to an embodiment of the present invention. [Figure 2] 1 is a block diagram showing a functional configuration of a debt balance management system according to an embodiment of the present invention. [Figure 3] 10 is a flowchart showing a debt balance management process of the debt balance management system according to the present embodiment. [Figure 4] 10 is a screen transition diagram of the debt balance management process of the debt balance management system according to the present embodiment. FIG. [Figure 5] FIG. 10 is a diagram illustrating a display example of a master screen. [Figure 6] 10 is a flowchart showing a related party management process A of the debt balance management system according to the present embodiment. [Figure 7] FIG. 10 is a diagram showing a display example of a related person information screen. [Figure 8] FIG. 10 is a diagram illustrating a display example of a related person details screen. [Figure 9] FIG. 10 is a diagram showing an example of a name code DB related party classification table. [Figure 10] FIG. 10 is a diagram showing an example of a relationship table of a name code DB. [Figure 11] A figure showing an example of an inheritance status table in the name code DB. [Figure 12] FIG. 10 is a diagram illustrating an example of a data format of attribute data stored in a related person DB. [Figure 13] FIG. 10 is a diagram showing an example of a data format of debt data stored in a debt DB. [Figure 14] FIG. 10 is a diagram showing the processing flow of deposit / withdrawal management process B of the debt balance management system according to the present embodiment. [Figure 15] FIG. 10 is a diagram showing a display example of a deposit screen. [Figure 16] FIG. 10 is a diagram showing an example of an inputter classification table of a name code DB. [Figure 17] FIG. 10 is a diagram showing an example of a data format of deposit data stored in a deposit DB. [Figure 18] FIG. 10 is a diagram showing an example of a withdrawal screen display. [Figure 19] FIG. 10 is a diagram showing an example of a cost type table of a name code DB. [Figure 20] FIG. 10 is a diagram showing an example of a data format of withdrawal data stored in a withdrawal DB. [Figure 21] FIG. 10 is a diagram showing an example of a deposit / withdrawal history screen display. [Figure 22] FIG. 10 is a diagram showing an example of a deposit screen displaying deposit data. [Figure 23] FIG. 10 is a diagram showing an example of a withdrawal screen displaying withdrawal data. [Figure 24] FIG. 10 is a diagram showing the processing flow of negotiation management processing E of the debt balance management system according to the present embodiment. [Figure 25] FIG. 10 is a diagram showing a display example of a mediation settlement screen. [Figure 26] FIG. 10 is a diagram showing an example of a data format of mediated settlement data stored in a mediated settlement DB. [Figure 27] FIG. 10 is a diagram showing a display example of a debt settlement screen. [Figure 28] A figure showing an example of the data format of debt settlement data stored in a debt settlement DB. [Figure 29] FIG. 10 is a diagram showing an example of an initial display of a legal procedure screen. [Figure 30] FIG. 10 is a diagram showing an example of a legal procedure type table in the name master DB. [Figure 31] A figure showing an example of a court classification table in the name master DB. [Figure 32] FIG. 10 is a diagram illustrating an example of a result table of a name master DB. [Figure 33] 10 is a diagram showing an example of a data format of legal procedure data stored in a legal procedure DB. FIG. [Figure 34] FIG. 10 is a diagram showing the processing flow of negotiation memo management processing C of the debt balance management system according to the present embodiment. [Figure 35] FIG. 10 is a diagram showing a display example of a negotiation memo screen. [Figure 36] FIG. 10 is a diagram illustrating an example of a negotiation partner type table in the name master DB. [Figure 37] FIG. 10 is a diagram illustrating an example of a negotiation means type table in the name master DB. [Figure 38] FIG. 2 is a diagram showing an example of a data format of negotiation memo data stored in a negotiation memo DB. [Figure 39] FIG. 10 is a diagram showing the processing flow of a demand note output process D of the debt balance management system according to the present embodiment. [Figure 40] FIG. 10 is a diagram showing a display example of a notice output screen. [Figure 41] FIG. 10 is a diagram showing an example of an output of a demand notice. [Figure 42] FIG. 10 is a diagram showing an example of a notice type table in the name master DB. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments will be described with reference to the drawings. In the following description, identical or similar components will be designated by the same reference numerals, and duplicate descriptions will be omitted. In the following description, when it is necessary to distinguish between components of the same type, an identifier (numbers, letters, etc.) will be written in parentheses after the reference numeral that collectively refers to the components.

[0011] <Overview> FIG. 1 is a schematic diagram of a debt balance management system 1 according to this embodiment. The debt balance management system 1 is a system managed by creditors and debt guarantors such as financial institutions and guarantee companies (hereinafter referred to as creditors, etc.), and is a system that properly manages debts inherited by heirs (hereinafter referred to as inherited debts) when a debtor or joint guarantor (hereinafter referred to as the deceased) dies. Specifically, the debt balance management system 1 is a system that manages the balance of inherited debts of each heir, and when creditors negotiate with heirs, manages the balance of inherited debts that reflects the negotiation status and results. In addition, by managing the debt balances of heirs, the debt balance management system 1 can also manage the balance of the debts of the deceased (hereinafter also referred to as inherited debts). Here, negotiations mean negotiations between heirs and creditors regarding debts, such as specific mediation, voluntary settlement, judicial settlement, and debt consolidation.

[0012] An overview of the debt balance management system 1 will be explained using a specific example shown in the figure. First, when deceased A dies, an inheritance investigation is conducted, and if heirs B and C "inherit" or "simple accept" the debt, the user of the debt balance management system 1 identifies deceased A and heirs B and C as debt-related parties (hereinafter simply referred to as related parties) in the debt balance management system 1 and registers attribute data for each related party. The attribute data is information about individuals used to manage debts, such as name, related party classification, relationship, date of death, contact information, and place of employment.

[0013] Furthermore, through the inheritance investigation, the user determines the principal, damages, and damage interest rate (interest) of deceased A, as well as the amount of recourse, damages, and damage interest rate (interest) inherited by each heir, and registers this as debt data in the debt balance management system 1. Here, the amount of recourse is the sum of the deceased's principal and damages, and is the amount that creditors, etc. have the right to demand repayment.

[0014] Heir B inherits the debt without negotiating with creditors, etc. In this case, the amount of reimbursement right B determined in the inheritance investigation becomes the balance of reimbursement right B at the time of repayment start, damages B becomes the balance of damages B at the time of repayment start, and damage interest rate B becomes the damage interest rate at the time of repayment. Then, each time a deposit is made by heir B, the debt balance management system 1 registers the deposit data, and calculates the new balance of reimbursement right B after the deposit, damages B incurred up to the date of deposit, and new balance of damages B based on the debt data and deposit data.

[0015] Meanwhile, heir C negotiates with the creditor and inherits the debt that has been finalized through a mediated settlement. In this case, the balance of the right of reimbursement C at the time of repayment commencement will be the sum of the final principal C and final damages C finalized through the mediated settlement, instead of the amount of the right of reimbursement C determined in the inheritance investigation. Similarly, the balance of damages C at the time of repayment commencement will become the final damages C. In addition, the damage interest rate C at the time of repayment will be replaced by the final damage interest rate C. Then, just like with heir B, each time a deposit is made by heir C, the debt balance management system 1 registers the deposit data and calculates the new balance of the right of reimbursement C after the deposit, the damages C incurred up to the date of the deposit, and the new balance of damages C based on the debt data and the deposit data.

[0016] For example, if an inheritance investigation reveals that the principal A of deceased A is 1,000,000 yen and damages A is 100,000 yen, and the heirs each inherit half, then heir B's claim amount B will be 550,000 yen and damages B will be 0 yen, and heir C's claim amount C will be 550,000 yen and damages C will be 0 yen.

[0017] Then, when the debt balance management system 1 registers that Heir B deposited "50,000 yen" on October 1, 2023, it subtracts the deposit amount "50,000 yen" from the amount of recourse (recourse balance at the time of repayment start) B "550,000 yen" to calculate the new recourse balance B "500,000 yen."

[0018] In addition, the debt balance management system 1 calculates the damages B "¥4,500" incurred from the damages calculation date to the deposit date based on the number of days until the deposit date, with the date of completion of the inheritance investigation being September 1, 2023, as the damages calculation date, the remaining amount of the right to reimbursement on the right to reimbursement calculation date, i.e., the right to reimbursement amount B, and the damage interest rate B. Note that in this explanation, the incurred damages are approximate estimates. Then, the incurred damages B "¥4,500" is added to the damages (balance of damages at the start of repayment) B "¥0" to calculate the new damages balance B "¥4,500."

[0019] Next, when the debt balance management system 1 registers that the same amount was deposited by Heir B on November 1, 2023, it similarly calculates the new balance B of the right of reimbursement "¥450,000" and the balance B of damages "¥8,500." Then, the debt balance management system 1 calculates Heir B's debt balance as of November 2, 2023 as "¥458,500" by adding the remaining amount of the right of reimbursement B after the last payment, "¥450,000," and the remaining amount of damages B, "¥8,500."

[0020] In addition, when the debt balance management system 1 registers that heir C deposited "¥30,000" on November 1, 2023, it subtracts the deposit amount "¥30,000" from the confirmed principal amount (balance of the right of recourse at the time of repayment start) C "¥300,000" to calculate the new balance of the right of recourse C "¥270,000."

[0021] Additionally, the debt balance management system 1 calculates the incurred damages C "¥2,500" based on the number of days from the date of calculation of damages (October 1, 2023, when the mediation settlement is concluded) to the date of payment, the remaining amount of the right to reimbursement on the date of calculation of damages, i.e., the fixed principal C, and the fixed damage interest rate C. Then, the incurred damages C "¥2,500" is added to the fixed damages (damages balance at the time of repayment start) C "¥0" to calculate a new damages balance C "¥2,500". The debt balance management system 1 calculates Heir B's debt balance as of November 2, 2023 as "¥272,500" by adding the remaining amount of the right of reimbursement C after the last payment, "¥270,000," and the remaining amount of damages B, "¥2,500."

[0022] Then, the debt balance management system 1 can calculate the remaining debt balance of deceased A as of November 2, 2023 as "731,000 yen" by adding up the remaining debt balances of each heir at the same time.

[0023] In this way, the debt balance management system 1 can identify debt data including the balance at the time repayment begins for each heir, in both cases where inheritance occurs without negotiation and where inheritance occurs after negotiation, and calculate and manage the debt balances of the heirs and the deceased based on the registered deposit data for each heir.

[0024] <Functional configuration of debt balance management system> FIG. 2 is a block diagram showing the functional configuration of the debt balance management system 1 according to this embodiment. The debt balance management system 1 includes a debt balance management device 100, a display device 201, an output device 202, and an input device 203, and each device is connected to each other so as to be able to communicate with each other. A monitor (including a home television) or a touch panel can be used as the display device 201. A printer can be used as the output device 202. In addition to a keyboard, a mouse, and a microphone, a monitor that cooperates with a mouse to realize a pointing device function can be used as the input device 203.

[0025] The debt balance management device 100 comprises a control unit 101, a storage unit 103, and an input / output I / F 105 for connecting with each device, and each unit is communicably connected via an arbitrary communication path (not shown). In this embodiment, the debt balance management apparatus 100 is a cloud server, but it may also be a stationary or portable information processing device such as a personal computer or a smartphone.

[0026] The memory unit 103 stores various databases, tables, files, and the like. The memory unit 103 also stores computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) so that the control unit 101 can perform various processes. In this embodiment, the debt balance management device 100 is a cloud server, so the memory unit 103 is preferably constructed using cloud storage or a distributed ledger, but it may also be composed of a hard disk, semiconductor memory, storage medium, memory card, or the like. In this specification and drawings, DB is used as an abbreviation for database.

[0027] The memory unit 103 also includes a related party DB130 that stores attribute data of related parties, a debt DB131 that stores debt data, a deposit DB132 that stores deposit data regarding deposits from heirs, a withdrawal DB133 that stores withdrawal data regarding withdrawals made to heirs, a negotiation memo DB134 that stores negotiation memo data regarding negotiations between debtors and heirs, a mediated settlement DB135 that stores mediated settlement data regarding mediated settlements by heirs, a debt settlement DB136 that stores debt settlement data regarding debt settlement by heirs, a legal procedure DB137 that stores legal procedure data regarding legal procedures by heirs, and a name master DB138 that stores various names and name codes that identify the names.

[0028] The control unit 101 is a CPU or the like that controls the debt balance management device 100 in an overall manner, and realizes various functional units based on programs stored in the memory unit 103. The control unit 101 includes a master management unit 110, a related party management unit 111, a deposit management unit 112, a withdrawal management unit 113, a deposit / withdrawal history management unit 114, a negotiation memo management unit 115, a mediation / settlement management unit 116, a debt consolidation management unit 117, a legal procedure management unit 118, a debt management unit 119, a calculation unit 120, and a demand letter output unit 121.

[0029] The master management unit 110 manages a master screen that shows the status of the deceased heir (debtor or guarantor) and the status of the heir. The related person management unit 111 manages the attribute data of the deceased deceased and the heirs, displays the attribute data stored in the related person DB 130 on the related person screen, and registers the attribute data entered / modified on the related person details screen in the related person DB 130.

[0030] The deposit management unit 112 manages the deposit data, and registers the deposit data entered / modified on the deposit screen in the deposit DB 132. The withdrawal management unit 113 manages withdrawal data and registers the withdrawal data input / modified on the withdrawal screen in the withdrawal DB 133. The deposit and withdrawal history management unit 114 manages the history of deposits and withdrawals, and displays a history on the deposit and withdrawal history screen in which deposit data obtained from the deposit DB 132 and withdrawal data obtained from the withdrawal DB 133 are arranged in chronological order.

[0031] The negotiation memo management unit 115 manages the negotiation memo, displays the negotiation memo data stored in the negotiation memo DB 134 on the negotiation memo screen, and registers the negotiation memo data entered / modified on the negotiation memo screen in the negotiation memo DB 134. The negotiation memo data stored in the negotiation memo DB 134 is displayed on the negotiation memo screen as a history arranged in chronological order.

[0032] The mediation and settlement management unit 116 manages the mediation and settlement data of the heirs, displays the mediation and settlement data stored in the mediation and settlement DB 135 on the mediation and settlement screen, and registers the mediation and settlement data entered / modified on the mediation and settlement screen in the mediation and settlement DB 135. The debt settlement management unit 117 manages the debt settlement data of the heirs, displays the debt settlement data stored in the debt settlement DB 136 on the debt settlement screen, and registers the debt settlement data entered / modified on the debt settlement screen in the debt settlement DB 136.

[0033] The legal procedure management unit 118 manages the legal procedure data of the heirs, displays the legal procedure data stored in the legal procedure DB 137 on the legal procedure screen, and registers the legal procedure data entered / modified on the legal procedure screen in the legal procedure DB 137.

[0034] The debt management unit 119 manages debt data. The debt data consists of original debt data relating to the debts of the deceased, inherited debt data relating to the debts of each heir determined by inheritance investigation, first confirmed debt data relating to the debts of the heirs confirmed by mediation and settlement, and second confirmed debt data relating to the debts of the heirs confirmed by debt restructuring.

[0035] In addition, the debt management unit 119 displays the original debt data and inherited debt data stored in the debt DB 131 on the related party screen, and registers the original debt data and inherited debt data entered / modified on the related party details screen in the debt DB 131. The debt management unit 119 displays the original debt data, inherited debt data, and first confirmed debt data stored in the debt DB 131 on the mediation and settlement screen, and registers the first confirmed debt data entered / modified on the mediation and settlement screen in the debt DB 131. The debt management unit 119 displays inherited debt data and second confirmed debt data from the debt data stored in the debt DB 131 on the debt settlement screen, and registers second confirmed debt data entered / modified on the debt settlement screen in the debt DB 131.

[0036] The calculation unit 120 calculates the debt balance based on the deposit data entered / modified on the deposit screen or the withdrawal data entered / modified on the withdrawal screen, and the debt data (original debt data, first confirmed debt data, second confirmed debt data) in the debt DB 131, in accordance with instructions from the deposit management unit 112, etc. Furthermore, the calculation unit 120 calculates damages from the damage base date to the present in response to instructions from the master management unit 110 or the like.

[0037] The demand note output unit 121 acquires data from each of the DBs 130 to 137 in the storage unit 103 based on the data input to the demand note output screen, inserts the input data and the acquired data into predetermined positions in a pre-prepared demand note format, creates a demand note, and outputs it to the output device 202.

[0038] <Operation flow of debt balance management device 100> 3 to 42, the debt balance management process of the debt balance management system 1 in this embodiment will be described in detail. Note that in this debt balance management process, the item names of various data are used when the administrator of this system is a debt guarantor such as a guarantee company.

[0039] 3 is a flowchart showing the debt balance management process of the debt balance management system 1. FIG. 4 is a screen transition diagram of the debt balance management process of the debt balance management system 1. The master management unit 110 displays a start screen (not shown) on the display device 201, which has an input field for a number that identifies the debt, which in this embodiment is a management number, and when it accepts the management number entered in the input field, it starts the debt balance management process. The master management unit 110 determines whether or not attribute data can be acquired from the related person DB 130 based on the input management number (step S1).

[0040] If attribute data can be acquired from the related party DB130, the master management unit 110 acquires debt data from the debt DB131, deposit data from the deposit DB132, withdrawal data from the withdrawal DB133, mediated settlement data from the mediated settlement DB135, debt settlement data from the debt settlement DB136, and legal procedure data from the legal procedure DB137 based on the input management number (S2). The master management unit 110 displays the acquired data together with the attribute data acquired in step S1 on the master screen W100 (step S3). It is not necessary to acquire all of the debt data, deposit data, withdrawal data, mediated settlement data, debt settlement data, and legal procedure data; only the acquired data is displayed on the master screen W100.

[0041] On the other hand, if attribute data cannot be acquired from the related person DB 130, the master management unit 110 displays the initial display master screen W100 in which the various data acquired in S1 and S2 described above are not displayed (S4).

[0042] FIG. 5 shows an example of the display of the master screen W100. The master screen W100 is a screen that displays details of debts, and for each debt, the status of the deceased person (debtor or guarantor) and the status of the heirs can be confirmed. The master screen W100 displays the latest statute of limitations for related parties, information about the deceased, the status of negotiations with creditors, details of the debt, information about related parties, deposit and withdrawal history, negotiation memo, and calculation of damages incurred. The master screen W100 also displays the buttons shown in Figure 4 for transitioning from the master screen W100 to other screens: the related party information button, deposit and withdrawal history button, deposit input button, withdrawal input button, negotiation memo button, and demand note output button. The master screen W100 also displays an exit button for shutting down the system.

[0043] The most recent prescription date for the related person is displayed as a date five or ten years from the specified starting date, with reference to the legal procedure DB137 and the deposit DB132. Specifically, if no deposit data is stored in the deposit DB132, the prescription date is ten years from the date of determination of the debt title stored in the legal procedure DB137. On the other hand, if deposit data is stored in the deposit DB132, the prescription date is ten years from the earliest date of the last deposit data for each heir stored in the deposit DB132. The information on the deceased and related parties is based on related party data stored in related party DB 130, and includes, for example, name, date of birth, and the like.

[0044] The status of negotiations with creditors is based on negotiation memo data stored in the negotiation memo DB 134. For example, negotiation memo data relating to each of "Assignment," "Debt Reorganization," "Mediation and Settlement," and "Debtor Title" is displayed.

[0045] The debt details are based on the debt data stored in the debt DB 131, the deposit data stored in the deposit DB 132, and the withdrawal data stored in the withdrawal DB 133. For example, the debt details include the claimable principal, claimable expenses, claimable damages, and their current balances that can be claimed from the heirs. The claimable principal, claimable expenses, and claimable damages are entered by the user on the related party details screen W210, which will be described later.

[0046] The deposit / withdrawal history is a history in which deposit data stored in the deposit DB 132 and withdrawal data stored in the withdrawal DB 133 are arranged in chronological order. The negotiation memo is a history of negotiation memo data stored in the negotiation memo DB 134 arranged in chronological order.

[0047] The damages calculation involves input fields for the damages reference date and damage rate, the damages, and the total amount. The damages are calculated and displayed by calculation unit 120 based on the date and damage rate entered in the input fields, the claimable principal of the debt data stored in debt DB 131, and the current date. The total amount is the total amount of the creditors' rights of reimbursement, and is calculated and displayed by calculation unit 120 by adding the damages calculated by calculation unit 120 and the claimable principal. The user then inputs the calculated damages as the remaining damages (claimable damages) of the deceased on the related party details screen W210, which will be described later. Note that this may also be input automatically.

[0048] Returning to Figure 3, the master management unit 110 determines which of the related party information button, deposit / withdrawal history button, deposit input button, withdrawal input button, negotiation memo button, notice output button, or end button displayed on the master screen W100 has been operated (S5).

[0049] If the master management unit 110 determines that the related person information button has been pressed, it proceeds to related person management processing A shown in Figure 6. If the master management unit 110 determines that the deposit / withdrawal history button, deposit input button, or withdrawal input button has been pressed, it proceeds to deposit / withdrawal management processing B shown in Figure 14. If the master management unit 110 determines that the negotiation memo button has been pressed, it proceeds to negotiation memo processing C shown in Figure 34. If the master management unit 110 determines that the demand note output button has been pressed, it proceeds to demand note output processing D shown in Figure 39. Then, if the master management unit 110 determines that the end button has been pressed, it closes the master screen W100 and ends the debt balance management processing.

[0050] [Related Person Management Processing] Fig. 6 is a diagram showing the processing flow of related party management processing A of the debt balance management system 1 according to this embodiment. Fig. 7 is a diagram showing a display example of the related party information screen W200. Fig. 8 shows a display example of the related party details screen W210. 6 and 7, the related person management process A when the related person information button is pressed on the master screen W100 will be described.

[0051] First, the related person management unit 111 determines whether or not the attribute data has been acquired in S1 of FIG. 3 (S101). If the attribute data has not been acquired, the initial related person information screen is displayed (S102). On the other hand, if the attribute data has been acquired, the related person information screen displaying the attribute data acquired in S1 is displayed (S103).

[0052] Here, the related person information screen W200 will be described with reference to FIG. The related party information screen W200 is displayed for each debt, and allows the user to check various data about the related parties of the debt, i.e., the deceased heir and his heirs.

[0053] The related person information screen W200 displays attribute data obtained from related person DB130 and debt data obtained from debt DB131 for each related person based on the management number. Note that there may be DBs from which data cannot be obtained. Note that if related person attribute data cannot be obtained from related person DB130 based on the management number, nothing is displayed in the list (initial display of related person information screen).

[0054] At the bottom of the related party information screen W200, as shown in Figure 4, there are displayed the New button, Details button, Mediation and Settlement button, Debt Consolidation button, Legal Procedure button, and Exit button, which transition to other screens when selected. Note that, on the initially displayed related party information screen displayed in S102 of Figure 6, it is desirable that only the New button and Exit button be activated among the buttons provided at the bottom of the screen. This is because the other buttons transition to a screen displaying data linked to the related party, and therefore transition is not possible if the related party is not registered.

[0055] 6, the related person management unit 111 determines the user's operation on the initially displayed related person information screen, i.e., determines whether the New button or the End button has been operated (S104). If the New button has been operated, the initially displayed related person details screen W210 is displayed (S106). On the other hand, if the End button has been operated, the related person management unit 111 ends the related person management process A and transitions the related person information screen W200 to the master screen W100.

[0056] In addition, the related party management unit 111 determines the operation performed by the user on the related party information screen displaying the attribute data, i.e., determines which of the New button, Details button, Mediation / Settlement button, Debt Consolidation button, Legal Procedure button, and End button was operated (S105).

[0057] When the New button is operated, the related person management unit 111 displays the related person details screen W210 in the initial display (S106). On the other hand, when the Details button is operated, the related person management unit 111 displays the related person details screen W210 that displays the attribute data of the related person selected on the related person information screen W200 (S107). If any of the mediation settlement button, debt consolidation button, and legal procedure button is operated, the process proceeds to negotiation management process E shown in Fig. 24. Furthermore, if the end button is operated, the related person management unit 111 ends related person management process A and transitions the related person information screen W200 to the master screen W100.

[0058] The related person management unit 111 determines the operation from the user on the related person detail screen W210 displaying the attribute data, that is, determines whether the correction button or the end button has been operated (S108). When the Modify button is operated, the related person management unit 111 enables input to the related person details screen W210, while when the End button is pressed, the processing returns to S101 and the related person details screen W210 transitions to the related person information screen W200.

[0059] Here, the related person details screen W210 shown in FIG. 8 will be described. The related person details screen W210 is displayed for each related person, and allows the user to register new related person attribute data and debt / inheritance debt data, modify already registered attribute data and debt / inheritance debt data, and confirm already registered attribute data and debt / inheritance debt data. The related person details screen W210 displays an input field for relationship identification information that identifies the relationship between the deceased and the related person, an input field for personal information of the related person, an input field for employment information of the related person, and an input field for credit information (debt / inheritance debt data).

[0060] The relationship specifying information includes, for example, the management number, the name of the deceased, the relationship classification, the relationship, and the inheritance status. The related party category is entered by displaying a list of name codes and names associated with each other on a pop-up screen from the related party category table of the name master DB 138, and selecting a name code from the list. Note that a pull-down list format may be used instead of a pop-up screen, and when selecting a name code from a list regardless of the related party category, either a pop-up screen or a pull-down list format may be used. Figure 9 shows an example of the related party category table of the name master DB 138.

[0061] Similarly, the relationship is entered by selecting a name code from the list displayed on a pop-up screen, which shows a list of name codes and names associated with each other from the relationship classification table of the name master DB 138. An example of the relationship table of the name master DB 138 is shown in FIG. Similarly, the inheritance status is input by displaying a list of name codes and names associated with each other on a pop-up screen from the inheritance status table of the name master DB 138, and selecting a name code from the list. Figure 11 shows an example of the inheritance status table of the name master DB 138.

[0062] Personal information of related parties includes, for example, name (kana or kanji), date of birth, gender, date of death, postal code and address (kana or kanji), telephone number (home or mobile), current address, registered address, registered address, and driver's license number or other identification number. Note that the date of death should only be entered for the deceased person. The workplace information includes, for example, the type of company, the prefix and suffix indicating the position of the legal entity, the name of the workplace (kana or kanji), telephone number, stock listing, number of employees, capital, postal code, address (kana or kanji), industry, and employment status.

[0063] The credit information may be, for example, the deceased's balance of reimbursement rights, balance of investigation expenses, and balance of damages, relationship ratio, the heir's balance of reimbursement rights, balance of investigation expenses, and balance of damages according to relationship ratio, and the damage interest rate (%). For convenience, the heir's balance of reimbursement rights, balance of investigation expenses, and balance of damages according to relationship ratio are enclosed in a box to make them easy to distinguish from the deceased's balance of reimbursement rights, balance of investigation expenses, and balance of damages.

[0064] Here, the deceased's remaining investigation expenses are the expenses that can be claimed up until the completion of the inheritance investigation. Also, the deceased's remaining damages are the damages that can be claimed up until the completion of the inheritance investigation. And the deceased's remaining right to claim is the sum of the deceased's claimable principal and the above-mentioned remaining investigation expenses and remaining damages. Note that the deceased's remaining right to claim, remaining investigation expenses, and remaining damages are entered by the user after the inheritance investigation is completed, so they are not necessarily entered at the same time as personal information or employment information. The heir's remaining balance of the right to claim reimbursement, the remaining balance of investigation expenses, and the remaining balance of damages are calculated by multiplying the decedent's remaining balance of the right to claim reimbursement, the remaining balance of investigation expenses, and the remaining balance of damages by the relationship ratio, respectively. Therefore, these may be calculated automatically by calculation unit 120 in response to input of the decedent's remaining balance of the right to claim reimbursement, the remaining balance of investigation expenses, and the remaining balance of damages and the relationship ratio, or may be calculated and input by the user.

[0065] 6, when the user enters information into the input fields on the related person details screen W210, checks the input content, and if there are no problems with the content, operates the register button, the related person management unit 111 registers the relationship specification information, personal information, and workplace information as attribute data in the related person DB 130. The related person management unit 111 also registers the claim information in the inherited debt data of the debt DB 131 (S109).

[0066] Specifically, the related party management unit 111 assigns a CIF number to identify the related party, and registers the relationship specification information, personal information, and workplace information as attribute data in the related party DB 130 in association with the management number and CIF number. The related party management unit 111 also registers the deceased's balance of reimbursement rights, balance of investigation expenses, and balance of damages in the claim information as the claimable principal, claimable expenses, and claimable damages, respectively, in association with the management number and CIF number, as original debt data in the debt DB 131. The related party management unit 111 also registers the heir's balance of reimbursement rights, balance of investigation expenses, balance of damages, relationship ratio, and damage interest rate in association with the management number and CIF number, as inherited debt data in the debt DB 131. The balance of reimbursement rights, balance of investigation expenses, and balance of damages in the inherited debt data are the balances at the time of completion of the inheritance investigation. In contrast, the balance of reimbursement rights, balance of investigation expenses, and balance of damages in the deposit data in the deposit DB 132, described below, are the balances at the time of deposit.

[0067] An example of the data format of the attribute data stored in the related party DB 130 is shown in Figure 12. As shown in the figure, the attribute data includes a management number, CIF number, related party classification, relationship, inheritance status, name (kana or kanji), date of birth, gender, date of death, telephone number (home or mobile), postal code and address, government office, permanent residence postal code and permanent residence address, permanent residence government office, personal identification number such as driver's license number, company type, employer name (kana or kanji), telephone number, stock listing, number of employees, capital, postal code and address, industry, and employment status. Note that the data format of the attribute data and each data format described below show only examples of data items, and unnecessary data items can be omitted and necessary data items can be added as desired.

[0068] 13 shows an example of the data format of the debt data stored in the debt DB 131. As shown in the figure, the debt data includes a management number, a CIF number, original debt data, inherited debt data, first fixed debt data, and second fixed debt data. Original debt data includes the claimable principal, claimable investigation costs, and claimable damages. Inheritance debt data includes the inheritance ratio, the balance of the right of reimbursement, the balance of investigation expenses, the balance of damages, and the damage interest rate (%). The first fixed debt data includes the fixed repayment amount (principal), the fixed repayment amount (damages), the fixed repayment amount, the balance, investigation costs, the repayment damage interest rate (%), and the late damage interest rate (%). The second fixed debt data includes the principal amount of the rehabilitation repayment, the damages amount of the rehabilitation repayment, and the rehabilitation damage interest rate (%).

[0069] 6, the related person management unit 111 determines the operation from the user (S110). If the end button is operated, the related person management unit 111 transitions the related person details screen W210 to the related person information screen W200. On the other hand, if the edit button is operated, the process returns to S109.

[0070] [Deposit and Withdrawal Management Processing] (Deposit processing) Fig. 14 is a diagram showing the processing flow of the deposit / withdrawal management process B of the debt balance management system 1 according to this embodiment. Fig. 15 is a diagram showing a display example of the deposit screen W300. Fig. 18 is a diagram showing a display example of the withdrawal screen W310. Fig. 21 is a diagram showing a display example of the deposit / withdrawal history screen W320. 14, 15, 18, and 21, the deposit / withdrawal management process B when the deposit input button, withdrawal input button, or deposit / withdrawal history button is pressed on the master screen W100 will be described.

[0071] The master data manager 110 determines whether the deposit input button, the withdrawal input button, or the deposit / withdrawal history button has been operated (S201). When the deposit button is operated, the master data manager 110 instructs the deposit manager 112 to display the initial deposit screen (S211).

[0072] Here, the deposit screen W300 will be described with reference to FIG. The deposit screen W300 is displayed for each deposit, and allows the user to register new deposit data, modify already registered deposit data, and confirm already registered deposit data. The deposit screen W300 displays data presenting inherited debts, various input fields for accepting deposit data input from the user, and display fields for displaying various balances.

[0073] Data presenting the inherited debt includes, for example, the control number, CIF number, heir's name, inherited debt at the time of completion of the inheritance investigation, and the current balance of the inherited debt. The heir's name is obtained from the related party DB130 based on the control number and CIF number. The claimable principal, claimable expenses, and claimable damages are inherited debts at the time of completion of the inheritance investigation, and are the remaining balance of the right of reimbursement, the remaining balance of investigation costs, and the remaining balance of damages obtained from the debt DB131 based on the control number and CIF number. The remaining balance of the right of reimbursement, the remaining balance of damages, and the remaining balance of investigation costs are current inherited debts, and are the remaining balance of the right of reimbursement, the remaining balance of investigation costs, and the remaining balance of damages obtained from the deposit DB132 based on the control number and CIF number. The final deposit date is the starting date for the remaining balance of the right of reimbursement, etc. obtained from the deposit DB132.

[0074] These data may be acquired from the master screen W100 from which the transition is made. If the balance of the right of reimbursement, the balance of investigation expenses, and the balance of damages cannot be acquired from the deposit DB132, the balance of the right of reimbursement, the balance of investigation expenses, and the balance of damages acquired from the debt DB131 based on the management number and CIF number are presented as the balance of the right of reimbursement, the balance of investigation expenses, and the balance of damages.

[0075] If a mediation settlement or debt restructuring has been finalized for the inherited debt, the date of finalization of the debt restructuring, the claimable principal, the claimable damages, and the damage interest rate will be presented. If a mediation settlement has been finalized for an inherited debt, the finalization date is the settlement / mediation date obtained from Mediation and Settlement DB135 based on the control number and CIF number, and the claimable principal, claimable damages, and damage interest rate are the final repayment amount (principal), final repayment amount (damages), and repayment damage interest rate (%) obtained from Debt DB131 based on the control number and CIF number.On the other hand, if a debt restructuring has been finalized, the finalization date is the approval and finalization date of Debt Restructuring DB136, and the claimable principal, claimable damages, and damage interest rate are the rehabilitation repayment amount principal, rehabilitation repayment damages, and rehabilitation damage interest rate obtained from Debt DB131 based on the control number and CIF number.

[0076] The deposit data is information regarding deposits from heirs, such as the depositor classification, CIF number, related party classification, name of depositor (heir), starting date, deposit type, breakdown, deposit amount, allocation method, damages incurred, amount allocated to right of recourse, amount allocated to damages, amount allocated to investigation expenses (hereinafter, the amount allocated to right of recourse, amount allocated to damages, and amount allocated to investigation expenses are collectively referred to as various amounts allocated).

[0077] The depositor classification can be entered by displaying a list of name codes and names associated with each other on a pop-up screen from the depositor classification table in the name code DB 138, and selecting a name code from the list. Figure 16 shows an example of the depositor classification table in the name master DB 138.

[0078] The deposit type is information on the deposit type, such as bank transfer, postage stamp, revenue stamp, money order, cash, etc., which is displayed in the form of a pull-down list, and can be input by selecting one of them. The appropriation method is displayed in the form of a pull-down list, and can be entered by selecting one of the following: statutory appropriation, principal appropriation, manual, specific mediation / settlement, and civil rehabilitation. The various balances are the various balances after the deposit, such as the balance of the right of reimbursement, the balance of damages, and the balance of investigation expenses. The deposit data may also include the amount of the provisionally received funds appropriated and the provisionally received funds balance.

[0079] 14, when deposit data including at least the deposit amount and an allocation method other than manual is input, the deposit management unit 112 inputs the deposit amount into at least one of the amount appropriated to the right of reimbursement, the amount appropriated to damages, and the amount appropriated to investigation expenses, based on the input allocation method. In the case of manual input, the user inputs the amount appropriated to the right of reimbursement, the amount appropriated to damages, and the amount appropriated to investigation expenses into the input fields (S212). Next, the deposit management unit 112 instructs the calculation unit 120 to first calculate the incurred damages. The deposit management unit 112 then calculates various balances based on the calculated incurred damages, the allocation destination and allocation amount determined based on the input allocation method and deposit amount, and the balance of the final deposit data, and displays the calculation results in the display columns for each of the various balances on the deposit screen W300 (S213).

[0080] In detail, first, the calculation unit 120 acquires the remaining balance of the right of reimbursement, the remaining balance of damages, the remaining balance of investigation expenses, and the damage interest rate presented on the deposit screen W300 from the deposit management unit 112. Note that, if there is a damage interest rate for debt restructuring, the damage interest rate for debt restructuring is acquired. The calculation unit 120 may obtain data directly from the deposit DB 132 and the debt DB 131. In this case, the calculation unit 120 obtains the final deposit data from the deposit DB 132 and the loss interest rate of the debt data from the debt DB 131. Note that the loss interest rate is the loss interest rate of the inherited debt data when there is neither first nor second fixed debt data, the repayment loss interest rate when there is first fixed debt data, and the rehabilitation loss interest rate when there is second fixed debt data.

[0081] Next, the calculation unit 120 calculates the incurred damages based on the number of days from the starting date of the final deposit data to the starting date entered on the deposit screen W300, the remaining balance of the right of reimbursement acquired above, and the damage interest rate. Next, the calculation unit 120 refers to the withdrawal DB 133, and acquires withdrawal data from the starting date of the final deposit data to the starting date entered on the deposit screen W300, if any.

[0082] Then, the calculation unit 120 subtracts the amount of allocation from the balance of the allocation destination determined by the deposit management unit 112 among the various balances of the final deposit data, adds the calculated amount of damage incurred to the damage balance, and adds the withdrawal amount of the acquired withdrawal data to the investigation fee balance, thereby calculating the various balances after the deposit.

[0083] Next, when the user checks the input contents and operates the register button if there is no problem with the contents, the deposit management unit 112 registers the deposit data and the various balances calculated in S213 in the deposit DB 132 (S214). In detail, the deposit management unit 112 assigns a deposit / withdrawal number to the deposit data to identify the deposit data and withdrawal data, and registers the deposit data in the deposit DB 132 by correlating the assigned deposit / withdrawal number, the management number, and the CIF number obtained from the related party DB 130 based on the name of the depositor.

[0084] An example of the data format of the deposit data stored in the deposit DB 132 is shown in Fig. 17. As shown in the figure, the deposit data has the following data items: control number, CIF number, deposit / withdrawal number, name (kana / kanji), depositor classification, related party classification, calculation start date, deposit type, breakdown, deposit amount, allocation method, amount of damages incurred, amount appropriated for right of reimbursement, amount appropriated for damages, amount appropriated for investigation, balance of right of reimbursement, balance of damages, and balance of investigation expenses.

[0085] Returning to Figure 14, when the user operates the end button, the deposit management unit 112 ends the deposit / withdrawal management process B and returns from the deposit screen W300 to the master screen W100 (see Figure 4). On the other hand, when the administrator operates the correction button, the process proceeds to S239, which will be described later.

[0086] (Withdrawal processing) Returning to S201 in FIG. 14, when the withdrawal button is operated, the master data manager 110 instructs the withdrawal manager 113 to display the initial withdrawal screen (S221).

[0087] Here, the withdrawal screen W310 will be described with reference to FIG. The withdrawal screen W310 is displayed for each withdrawal, and allows the user to register new withdrawal data, modify already registered withdrawal data, and confirm already registered withdrawal data. The withdrawal screen W310 displays data presenting inherited debts and various input fields for accepting withdrawal data input from the user.

[0088] The data presenting the inherited debt is the same as the data presenting the inherited debt to be paid as described above. Note that even if the mediated settlement and debt restructuring have been finalized, the first and second confirmed debt data are not included. Withdrawal data is information about withdrawals to heirs, i.e., expenses incurred by the heirs, such as the starting date, withdrawal amount, expense type, and item. The cost type is input by displaying a list of name codes and names associated with each other on a pop-up screen from the cost type table of the name master DB 138, and selecting a name code from the list. Figure 19 shows the cost type table of the name master DB 138. Information on subjects such as research expenses is displayed in the form of a pull-down list, and can be selected and entered.

[0089] Next, the withdrawal management unit 113 receives input of withdrawal data from the user (S222). Next, when the user checks the input contents and operates the register button if there is no problem with the contents, the withdrawal management unit 113 registers the withdrawal data in the withdrawal DB 133 (S223). In detail, the withdrawal management unit 113 assigns a deposit / withdrawal number that identifies the deposit data and withdrawal data to the withdrawal data, and registers the withdrawal data in the withdrawal DB 133 in association with the assigned deposit / withdrawal number, the management number, and the CIF number acquired from the related party DB 130 based on the name of the depositor.

[0090] An example of the data format of the withdrawal data stored in the withdrawal DB 133 is shown in Fig. 20. As shown in the figure, the withdrawal data has the following data items: control number, CIF number, deposit / withdrawal number, name (kana / kanji), calculation start date, withdrawal amount, expense type, and subject.

[0091] When the user operates the end button, the withdrawal management unit 113 ends the deposit / withdrawal management process B and returns from the withdrawal screen W310 to the master screen W100 (see FIG. 4). On the other hand, when the user operates the correction button, the process proceeds to S243, which will be described later.

[0092] (Deposit and withdrawal history processing) Returning to S201 in FIG. 14, when the deposit / withdrawal history button is operated, the master data manager 110 acquires deposit data from the deposit DB 132 and withdrawal data from the withdrawal DB 133 based on the management number (S231).

[0093] Next, the deposit / withdrawal history management unit 114 instructs the calculation unit 120 to calculate total deposit amount data based on the deposit data acquired in S231 (S232). The deposit / withdrawal history management unit 114 then displays the deposit / withdrawal history screen W320 (S233), which displays the total deposit amount data calculated in S232 and deposit / withdrawal history data in which the deposit / withdrawal data acquired in S231 is arranged in chronological order. Note that it is not necessary to display all deposit / withdrawal data, and it is also possible to display a preset number of recent transactions or the history for the period entered in the start date input field in the upper right corner. The deposit / withdrawal history may be displayed in either descending or ascending order.

[0094] Here, the deposit / withdrawal history screen W320 will be described with reference to FIG. In this embodiment, the deposit / withdrawal history screen W320 is displayed for each inherited debt, and the user can check the deposit / withdrawal history, print the deposit / withdrawal history, and select the deposit / withdrawal data to modify. Note that the deposit / withdrawal history screen W320 may also be displayed for each inherited debt.

[0095] As described above, the deposit / withdrawal history screen W320 displays total deposit data, which is a compilation of all deposit amounts to date, and deposit / withdrawal history data, which lists all deposit / withdrawal data to date in chronological order. The total deposit amount data includes, for example, the total deposit amount, which is the total amount of deposits for all deposit data, "principal amount," which is the total amount of deposits allocated to principal, "damages amount," which is the total amount of deposits allocated to damages, and "investigation expenses," which is the total amount of deposits allocated to investigation expenses. The deposit / withdrawal history data includes, for example, the transaction date when the deposit / withdrawal data was registered, the starting date, the deposit / withdrawal classification, the withdrawal amount, the deposit amount, the depositor indicating the name of the depositor classification, the account item classifying the deposit / withdrawal, and the type indicating the deposit type or withdrawal expense type.

[0096] The deposit / withdrawal history management unit 114 determines the operation from the user (S234). If the user operates the end button, the deposit / withdrawal management process B is terminated and the deposit / withdrawal history screen W320 returns to the master screen W100 (see Figure 4). If the user operates the print button, an instruction to output the displayed deposit / withdrawal history is sent to the output device 202, and the deposit / withdrawal history is printed by the output device 202 (S235). The total amount of deposits may also be printed together with the deposit / withdrawal history.

[0097] When the user selects one item from the deposit / withdrawal history and operates the details button, the deposit / withdrawal history management unit 114 determines whether the selected history is classified as a deposit or a withdrawal (S236). If the selected history is classified as a deposit, the deposit / withdrawal history management unit 114 causes the deposit management unit 112 to display a deposit screen with the deposit data corresponding to the selected history displayed in the input field (S237).

[0098] Here, the deposit screen W301 displaying the deposit data will be described with reference to FIG. The deposit screen W301, like the initial display deposit screen W300 shown in Figure 15, displays data presenting the inherited debt to be deposited, and also displays the deposit data in each input field that accepts deposit data from the user and in various balances.

[0099] Returning to FIG. 14, the deposit management unit 112 judges the operation from the user (S238). To correct the deposit data displayed on the deposit screen W301, the user operates the correction button, and the deposit management unit 112 executes the deposit data correction process (S239), returns the process to S231, and displays the deposit / withdrawal history screen W320. In detail, when the correction button is operated, the deposit management unit 112 makes the deposit screen W301 input-enabled, corrects the deposit data displayed in the input fields, and makes additional input into input fields that are not displayed, and then executes the processes of S213 and S214 described above. Furthermore, if the user wishes to delete the deposit data displayed on the deposit screen W301, the user operates the cancel button to delete the deposit data from the deposit DB 132 (S240), and the process returns to S231, displaying the deposit / withdrawal history screen W320. Even if the user operates the end button, the deposit management unit 112 returns the process to S231 and displays the deposit / withdrawal history screen W320.

[0100] If the history category selected on the deposit / withdrawal history screen W320 is withdrawal, the deposit / withdrawal history management unit 114 causes the withdrawal management unit 113 to display a withdrawal screen in which the withdrawal data corresponding to the selected history is displayed in the input field (S241). Here, the withdrawal screen W311 displaying the withdrawal data will be described with reference to FIG. The withdrawal screen W311, like the initial display withdrawal screen W310 shown in Figure 18, displays data presenting inherited debts, and also displays withdrawal data in each input field that accepts withdrawal data input from the user.

[0101] Returning to FIG. 14, the withdrawal management unit 113 determines an operation from the user (S242). To correct the withdrawal data displayed on the withdrawal screen W311, the user operates the correction button, and the withdrawal management unit 113 executes the withdrawal data correction process (S243), returns the process to S231, and displays the deposit / withdrawal history screen W320. In detail, the withdrawal management unit 113 makes the withdrawal screen W311 input-enabled, corrects the withdrawal data displayed in the input fields, and enters additional data into input fields that are not displayed, and then executes S223 described above. Furthermore, if the user wishes to delete the withdrawal data on the withdrawal screen W311, the user operates the cancel button, and the withdrawal management unit 113 deletes the withdrawal data from the withdrawal DB 133 (S244), returns the process to S231, and displays the deposit / withdrawal history screen W320. Even if the user operates the end button, the withdrawal management unit 113 returns the process to S231 and displays the deposit / withdrawal history screen W320.

[0102] (Negotiation management processing) FIG. 24 is a diagram showing the processing flow of the negotiation management process E of the debt balance management system 1 according to this embodiment. Using the process flow diagram of FIG. 24, the negotiation management process E when the mediation and settlement button, debt consolidation button, or legal procedure button is operated on the related party information screen W200 shown in FIG. 7 will be described.

[0103] The related party management unit 111 determines whether the mediation settlement button, the debt consolidation button, or the legal procedure button has been operated (S301). (Mediation settlement) When the mediation / settlement button is operated, the mediation / settlement management unit 116 determines whether or not mediation / settlement data can be acquired from the mediation / settlement DB 135 based on the management number and the CIF number (S311). If the mediated settlement data cannot be acquired, the mediated settlement management unit 116 displays the initial mediated settlement screen W400 (S312). Note that the mediated settlement screen W400 allows the input of mediated settlement data. If the mediated settlement data is acquired, the mediated settlement management unit 116 displays the mediated settlement screen W400 showing the acquired mediated settlement data (S313). The mediated settlement screen W400 allows the administrator to input mediated settlement data by operating the edit button.

[0104] Here, the mediation settlement screen W400 will be described with reference to FIG. The mediation settlement screen W400 is displayed for each debt or party involved, and allows the user to register new mediation settlement data or first fixed debt data, modify already registered mediation settlement data or first fixed debt data, or confirm already registered mediation settlement data or first fixed debt data. The mediation settlement screen W400 displays data presenting the debt that is the subject of mediation settlement, an input field for accepting input of mediation settlement data, and a registration category for specifying which mediation settlement data the user is allowed to input.

[0105] The data presenting the debt may be, for example, a control number, a CIF number, original debt data, or inherited debt data. In the case of a debt-based arbitration settlement, the data may be the control number and original debt data. In the case of a related party-based arbitration settlement data, the names obtained from the related party DB 130 may be displayed based on the CIF number.

[0106] The debt data includes, for example, the principal of the right of reimbursement, damages, and investigation costs. In the case of a mediated settlement on a debt-by-debt basis, the claimable principal as the principal of the right of reimbursement, the claimable damages as damages, and the claimable expenses as investigation costs are obtained from the original debt data in the debt DB131 based on the management number. In the case of a mediated settlement on a related party basis, the remaining balance of the right of reimbursement, the remaining damages, and the remaining investigation costs are obtained from the inherited debt data in the debt DB131 based on the management number and CIF number as the principal of the right of reimbursement, damages, and investigation costs.

[0107] Mediation and settlement data consists of, for example, specific mediation and settlement information, repayment plan information, and premature termination information. Which of these mediation and settlement data is allowed to be entered can be selected in the registration category. If you do not want to allow input, simply check the cancel checkbox provided for each piece of information.

[0108] Specific mediation / settlement information includes the mediation / settlement category indicating whether it is specific mediation or settlement, the case number for specific mediation or court settlement, the court, the court category, the settlement / mediation date, the final repayment amount data, and the starting date for damages exemption. The final repayment amount data includes the (final) principal, (final) damages, investigation costs incurred after the date of default, the balance on the settlement / mediation date, and the (final) repayment amount which is the sum of the (final) principal and (final) damages.

[0109] The repayment plan data includes, for example, regular repayment amount, repayment cycle, repayment date, loss interest rate (repayment loss interest rate), first repayment month, first repayment amount, increased repayment month, increased repayment amount, and allocation method. The data on prepayment includes, for example, prepayment conditions, a damage interest rate (late damage interest rate) in the event of prepayment, and a prepayment date. The default date is entered after the default date. Once entered, late fees will be charged based on the late fee interest rate from the day after the default date, and will be added to the remaining fees along with the fees based on the late fee interest rate.

[0110] 24, when at least one of the specific mediation / settlement information, repayment plan information, and premature termination information selected in the registration category is input, and the user checks the input content and operates the register button if there is no problem with the content, the mediation / settlement management unit 116 registers the input mediation / settlement data in the mediation / settlement DB 135. Furthermore, when the final repayment amount data, repayment damage interest rate, and late damage interest rate are input, the mediation / settlement management unit 116 registers the final repayment amount data, repayment damage interest rate, and late damage interest rate in the debt DB 131 (S314).

[0111] In detail, the mediation and settlement management unit 116 associates the mediation and settlement data with the control number or the control number and the CIF number, and registers the mediation and settlement data in the mediation and settlement DB 135. In addition, the mediation and settlement management unit 116 registers the fixed repayment amount data, the repayment loss interest rate, and the late loss interest rate as first fixed debt data in the debt DB 131, associated with the control number or the control number and the CIF number.

[0112] An example of the data format of the mediated settlement data stored in the mediated settlement DB 135 is shown in Fig. 26. As shown in the figure, the mediated settlement data has the following data items: management number, CIF number, mediated settlement category, case number, court, court category, settlement / mediation date, damages exemption calculation start date, regular repayment amount, repayment cycle, repayment date, first repayment month, first repayment amount, increased repayment month, increased repayment amount, final repayment amount, allocation method, conditions for default, and date for default.

[0113] When the user operates the end button, the mediation and settlement management unit 116 ends the negotiation management process E and transitions the mediation and settlement screen W400 to the related party information screen W200 (see FIG. 4). On the other hand, when the user operates the modify button, the process of S314 is repeated.

[0114] (Debt restructuring procedures) Returning to S301 in FIG. 24, when the debt settlement button is operated, the debt settlement management unit 117 determines whether or not debt settlement data can be acquired from the debt settlement DB 136 based on the management number and CIF number (S321). If the debt settlement data cannot be acquired, the debt settlement management unit 117 displays the initial debt settlement screen W410 (S322). The initial debt settlement screen W410 allows the input of debt settlement data.

[0115] If the debt settlement data is acquired, the debt settlement management unit 117 displays the debt settlement screen W410 that displays the acquired debt settlement data (S323). The debt settlement screen W410 allows the user to input debt settlement data by operating the correction button.

[0116] Here, the debt settlement screen W410 will be described with reference to FIG. The debt settlement screen W410 is displayed for each party involved, and allows the user to register new debt settlement data, modify already registered debt settlement data, and confirm already registered debt settlement data. The debt settlement screen W410 displays data presenting the debt to be settled, input fields for accepting input of debt settlement data, and debt settlement classifications that specify which debt settlement data the user is allowed to input.

[0117] The data presenting the debt may be, for example, a control number, a CIF number, or inherited debt data. The inherited debt data is, for example, the principal of the right of reimbursement remaining balance (right of reimbursement remaining balance) and damages (damages remaining balance), and is obtained from the debt DB 131 based on the management number and CIF number.

[0118] Debt settlement data consists of, for example, attorney information, bankruptcy information, and rehabilitation information. The debt settlement category allows you to select which of these debt settlement data you want to be able to enter. If you want to disable input of a particular data item, simply check the corresponding cancel checkbox.

[0119] The attorney data includes, for example, the notification date, the details of the debt restructuring, data on the attorney (judicial scrivener), and data on the trustee attorney. The data on the attorney (judicial scrivener) and the trustee attorney includes, for example, the name, postal code, address, office name, telephone number, and fax number. The bankruptcy data includes, for example, the case number, the date of filing for bankruptcy proceedings, the date of the bankruptcy commencement decision, the date of bankruptcy repeal, and the date of discharge decision.

[0120] The rehabilitation data includes, for example, the rehabilitation type, case number, rehabilitation proceeding filing date, commencement decision date, final repayment date, approval confirmation date (input date), rehabilitation cancellation date, final amount data, and rehabilitation repayment plan data. The determined amount data includes, for example, the determined claim amount, the rehabilitation repayment amount, the exemption amount, the exemption damages, and the remaining repayment balance. Here, the determined claim amount is the amount of the claim up to the day before the rehabilitation approval decision, which is stated in the claim statement submitted to the court after the rehabilitation application, and consists of the principal and damages. The rehabilitation repayment amount is the rehabilitation repayment amount decided by the court, and consists of the principal and damages. Furthermore, the exemption amount is the difference between the determined claim amount and the rehabilitation repayment amount, and consists of the principal and damages. Furthermore, the remaining repayment balance is the current balance, and the remaining reimbursement right balance of the most recent deposit data in the deposit DB132 is displayed as the principal, and the remaining damages are displayed as damages.

[0121] The rehabilitation repayment plan includes, for example, the regular repayment amount, repayment cycle, repayment date, loss interest rate for rehabilitation repayment (rehabilitation loss interest rate), first repayment month, first repayment amount, increased repayment month, increased repayment amount, final repayment month, final repayment amount, and allocation method.

[0122] Returning to Figure 24, the debt settlement management unit 117 accepts the selection of a debt settlement category from the user (S324). Next, the debt settlement management unit 117 performs attorney registration processing, bankruptcy registration processing, rehabilitation registration processing, or rehabilitation repayment plan registration processing according to the debt settlement category selected in S324 (S325). If the user wishes to perform two or more registration processes, the user may change the debt settlement category after inputting one registration process, perform another registration process, and then operate the registration button.

[0123] In detail, when the selected debt classification is attorney registration, the debt settlement management unit 117 first enables the input of attorney data. Then, when at least one of the attorney data is input, the debt settlement management unit 117 checks the input contents, and if there are no problems with the contents, operates the register button, the debt settlement management unit 117 registers the attorney data in the debt settlement DB 136. Even when the debt settlement classification is bankruptcy registration, the debt settlement management unit 117 first enables the input of bankruptcy data. Then, when at least one piece of bankruptcy data is input, the debt settlement management unit 117 checks the input contents, and if there are no problems with the contents, operates the register button, the debt settlement management unit 117 registers the bankruptcy data in the debt settlement DB 136.

[0124] Even when the selected debt settlement category is rehabilitation registration, the debt settlement management unit 117 first enables the input of rehabilitation data. Then, when at least one piece of rehabilitation data is input, the debt settlement management unit 117 checks the input contents, and if there are no problems with the contents, operates the registration button, the debt settlement management unit 117 registers the rehabilitation data in the debt settlement D136. Even when the selected debt settlement category is rehabilitation repayment plan registration, the debt settlement management unit 117 first enables the input of rehabilitation repayment plan data. Then, when at least one piece of rehabilitation repayment plan data is input, the debt settlement management unit 117 checks the input contents, and if there are no problems with the contents, operates the register button, the debt settlement management unit 117 registers the rehabilitation repayment plan data in the debt settlement DB 136.

[0125] The debt settlement management unit 117 associates the attorney data, bankruptcy data, rehabilitation data, and rehabilitation repayment plan data with the management number and CIF number and registers them in the debt settlement DB 136. The debt settlement management unit 117 also registers the rehabilitation repayment principal amount, rehabilitation repayment damages, and the damage interest rate (rehabilitation damage interest rate) of the rehabilitation data as second fixed debt data in the debt DB 131, associated with the management number and CIF number.

[0126] 28 shows an example of the data format of the debt settlement data stored in the debt settlement DB 136. As shown in the figure, the debt settlement data includes, as data items, a management number, a CIF number, a notice date, the name of the lawyer (judicial scrivener), the name of the firm, the postal code, the address, the telephone number, the fax number, the name of the trustee lawyer, the name of the firm, the postal code, the address, the telephone number, the fax number, the case number, the filing date of the bankruptcy proceedings, the date of the bankruptcy commencement decision, the date of the bankruptcy dismissal, the date of the discharge decision, the rehabilitation type, the case number, the filing date of the rehabilitation proceedings, the commencement decision section, the final repayment date, the approval confirmation date (the date of input), the rescission date, the confirmed claim amount principal, the confirmed claim amount damages, the exemption amount principal, the exemption amount damages, the regular repayment amount, the repayment cycle, the repayment date, the damage interest rate (the restructuring damage interest rate), the first repayment month, the first repayment amount, the increased repayment month, the increased repayment amount, the final repayment month, the final repayment amount, and the allocation method.

[0127] When the user operates the end button, the debt settlement management unit 117 ends the negotiation management process E and transitions the debt settlement screen W410 to the related person information screen W200 (see FIG. 4). On the other hand, when the user operates the correction button, the process returns to S324 (not shown).

[0128] (Legal procedure processing) Returning to S301 in FIG. 24, when the legal procedure button is operated, the legal procedure management unit 118 determines whether legal procedure data can be obtained from the legal procedure DB 137 based on the management number and CIF number (S331). If the legal procedure data cannot be acquired, the legal procedure management unit 118 displays the initial legal procedure screen W420 (S332). The initial legal procedure screen W420 allows the input of legal procedure data.

[0129] If the legal procedure data is acquired, the legal procedure management unit 118 displays the legal procedure screen W420 showing the acquired legal procedure data (S333). On the legal procedure screen, the user can modify the displayed legal procedure data by operating the edit button, and can input new legal procedure data by operating the add row button.

[0130] Here, the legal procedure screen W420 will be described with reference to FIG. The legal proceedings screen W420 is displayed for each party involved, and allows the user to register new legal proceedings data, modify already registered legal proceedings data, and confirm already registered legal proceedings data. The legal procedure screen W420 displays input fields for accepting input of legal procedure data from the user.

[0131] The legal procedure data may include, for example, the registration date, legal procedure type, case number, court name, court division, clerk in charge, trial date, court opening time, courtroom, result, and whether the defendant appeared. Note that required input items may be set among the legal procedure data. The registration date may be entered automatically by clicking a checkbox provided in the entry field, or may be entered manually. The legal procedure type is entered by displaying a list of name codes and names associated with each other on a pop-up screen from the legal procedure type table of name master DB 138, and selecting a name code from the list. Figure 30 is a diagram showing an example of the legal procedure type table of name master DB 138.

[0132] As with the legal procedure type, the court division is also entered by selecting a name code from the list displayed on a pop-up screen, which shows a list of name codes and names associated with each other from the court division table of the name master DB 138. Figure 31 shows an example of the court division table of the name master DB 138.

[0133] As with the legal procedure type, the results are also entered by selecting a name code from the list displayed on a pop-up screen, which associates the name code with the name from the result table of the name master DB 138. Figure 32 shows an example of the result table of the name master DB 138. If there is a debtor's name, the electronic file of the debtor's name, for example, a PDF file, is also registered in the results. The appearance of the defendant can be entered by displaying a list of whether the defendant will appear, "0: No appearance" and "1: Appearance", which are associated with the name code and name, in a pull-down menu or pop-up screen, and selecting the name code from the list.

[0134] Returning to Figure 24, when at least one piece of legal procedure data is entered (this may be the case where pre-set required fields are entered), the user checks the entered content, and if there are no problems with the content, operates the registration button, the legal procedure management unit 118 registers the legal procedure data in the legal procedure DB 137 (S334).

[0135] An example of the data format of the legal procedure data stored in the legal procedure DB 137 is shown in Fig. 33. As shown in the figure, the legal procedure data includes, as data items, a control number, a CIF number, a registration date, a legal procedure type, a case number, a court name, a court division, a clerk in charge, a (trial) date, a court opening time, a courtroom, a result, and whether or not the defendant appeared.

[0136] When the user operates the end button, the legal procedure management unit 118 ends the negotiation management process E and transitions the legal procedure screen W420 to the related person information screen W200 (see FIG. 4). On the other hand, when the user operates the modify button, the process returns to S334.

[0137] (Negotiation memo management processing) FIG. 34 is a diagram showing the processing flow of the negotiation memo management process C of the debt balance management system 1 according to this embodiment. FIG. 35 is a diagram showing a display example of the negotiation memo screen W500. 34 and 35, the negotiation memo management process C when the negotiation memo button is pressed on the master screen W100 will be described. By managing the negotiation memo, the progress of negotiations regarding debts can be recorded and confirmed.

[0138] First, the negotiation memo management unit 115 determines whether or not negotiation memo data can be acquired from the negotiation memo DB 134 based on the management number (S401). If the negotiation memo data cannot be acquired, the negotiation memo management unit 115 displays the initial negotiation memo screen W500 (S402). The initial negotiation memo screen W500 may display only the management number and the name of the deceased, or may display a table containing the item names of the negotiation memo history together with the management number and the name of the deceased.

[0139] On the other hand, if negotiation memo data can be acquired, the negotiation memo management unit 115 displays a negotiation memo history in which the acquired negotiation memo data is displayed in chronological order along with the management number and the name of the deceased on the negotiation memo screen W500 (S403). In this embodiment, the negotiation memo screen W500 displays negotiation memo data for each debt, but it may also display negotiation memo data for each inherited debt.

[0140] Here, the negotiation memo screen W500 will be described with reference to FIG. The negotiation memo screen W500 displays negotiation memo data in chronological order for each debt, and allows the user to register new negotiation memo data, modify / delete already registered negotiation memo data, and check already registered negotiation memo data.

[0141] When the user operates the row addition button on the negotiation memo screen W500, a row having input fields for accepting input of negotiation memo data from the user is added to the table. Furthermore, when the user operates the edit button on the negotiation memo screen W500, the displayed negotiation memo data can be edited / deleted.

[0142] The negotiation memo history includes, for example, the target, deletion, negotiation date, negotiation partner, and negotiation means.

[0143] The target is automatically checked when the user operates the row addition button to add a row with input fields for accepting new negotiation memo data from the user to the table. If the deceased has multiple claims, the same negotiation memo data for the checked row will be entered into the negotiation memo for other claims with different management numbers. For "Delete," it is possible to set whether or not to delete the negotiation memo data; checking the checkbox indicates that it is to be deleted, while leaving the checkbox unchecked indicates that it is not to be deleted. Negotiation memo data that has been checked and is to be deleted is deleted from the negotiation memo DB 134 when the clear button is operated.

[0144] The negotiation date is the date on which the creditor negotiated the debt. Clicking the checkbox in the input field will automatically enter the current date and time. You can also manually enter or modify the date and time.

[0145] After selecting the field in which the other party wants to input information, the other party operates the search button, and a list of name codes and names associated with each other from the negotiation partner type table in the name master DB 138 is displayed in a pop-up screen, and the other party can input information by selecting a name code and name from the list. Figure 36 is a diagram showing an example of the negotiation partner type table in the name master DB 138. For the means, after selecting the field in which you want to input the means, operate the search button to display a pop-up screen showing a list in which name codes and names are associated from the negotiation means type table of the name master DB 138, and you can input the means by selecting the name code and name from the list. Figure 37 is a diagram showing an example of the negotiation means type table of the name master DB 138.

[0146] Returning to Figure 34, when at least the counterparty or means of the negotiation memo data is entered / modified, the user checks the entered content, and if there are no problems with the content, operates the registration button, the negotiation memo management unit 115 registers / modifies the negotiation memo data in the negotiation memo DB 134 (S404).

[0147] 38 shows an example of the data format of the negotiation memo data stored in the negotiation memo DB 134. As shown in the figure, the negotiation memo data has the following data items: management number, target necessity, negotiation date, counterparty, and means.

[0148] Then, when the user operates the end button, the negotiation memo management unit 115 ends the negotiation memo process C and transitions the negotiation memo screen W500 to the master screen W100 (see FIG. 4). On the other hand, when the user operates the edit button, the process returns to S401.

[0149] (Preparation of notice) FIG. 39 is a diagram showing the processing flow of the demand note output process D of the debt balance management system 1 according to this embodiment. FIG. 40 is a diagram showing a display example of the demand notice output screen W600. 39 and 40, we will explain the debt collection notice output process D when the debt collection notice output button is pressed on the master screen W100. By being able to output debt collection notices in addition to managing the debt balance, debt collection can be made more efficient.

[0150] First, when the user inputs the related party (related party classification) and name (addressee), the notice output unit 121 acquires the destination information, that is, the postal code and address, from the related party DB 130 based on the input related party and management number, and displays them on the notice output screen W600 (S501). At this time, the notice output unit 121 also acquires the CIF number.

[0151] The demand statement output unit 121 acquires the final deposit data from the deposit DB 132 based on the management number and CIF number, and acquires the remaining balance of the right of reimbursement, the remaining balance of the investigation fee, and the remaining balance of the damages from the final deposit data. Next, the demand note output unit 121 refers to the withdrawal DB 133 based on the management number and CIF number, and if there is withdrawal data after the final deposit data, acquires it, and instructs the calculation unit 120 to determine the investigation expense balance as the sum of the investigation expense balance that has been acquired and the withdrawal amount of the acquired withdrawal data. Note that if there is no withdrawal data after the final deposit data, the investigation expense balance acquired from the final deposit data is determined as the investigation expense balance as is. Then, the demand statement output unit 121 displays the acquired balance of the right to claim reimbursement, the acquired balance of damages, and the determined balance of investigation expenses on the demand statement output screen W600 (S502).

[0152] If there is no withdrawal data after the final deposit data, the notice output unit 121 obtains the handling date of the final deposit data as the final transfer date, and if there is withdrawal data after the final deposit data, it obtains the handling date of the final withdrawal data as the final transfer date and displays it on the notice output screen W600 (S503).

[0153] The demand notice output unit 121 obtains the remaining amount of the right of reimbursement, the remaining amount of the investigation fee, and the remaining amount of the damages from the inherited debt data in the debt DB 131 based on the management number and the CIF number, and displays them on the demand notice output screen W600 (S504).

[0154] Next, if there is mediated settlement data based on the control number or the control number and the CIF number, the demand notice output unit 121 acquires court case data (case number, date of settlement, etc.) related to the court case of the mediated settlement data from the mediated settlement DB 135. If there is debt consolidation data based on the control number or the control number and the CIF number, it acquires and displays the court case data of the debt consolidation data (case number, approval date, etc.) from the debt consolidation DB 136 (S505). Furthermore, if there is mediation settlement data or debt restructuring data based on the management number or the management number and CIF number in S505, the notice output unit 121 obtains and displays the first repayment date from the first repayment month and repayment date of the mediation settlement data or debt restructuring data (S506).

[0155] The notice output unit 121 instructs the calculation unit 120 to calculate and display the damages from the damages calculation date to the input deadline if the payment deadline has been input, or the damages from the damages calculation date to the notice date if the payment deadline has not been input (S507). The detailed calculation method is as described above for calculating incurred damages. Furthermore, when repayments are being made in accordance with a repayment plan or a rehabilitation repayment plan, the notice output unit 121 displays the regular overdue amount if there is arrears so that the presence or absence of arrears can be ascertained (S508). Specifically, the notice output unit 121 instructs the calculation unit 120 to calculate and display the regular overdue amount from the number of repayments and the regular repayment amount from the last transfer date to the payment due date or the notice date, based on the mediated settlement data in the mediated settlement DB 135 or the debt consolidation data in the debt consolidation DB 136. The processing of S502 to S508 may be performed in any order, and each piece of data may be acquired first, and then the acquired data may be displayed together at the end.

[0156] When the user checks the input contents and operates the print button if there is no problem with the contents, the notice output unit 121 acquires a prepared notice format based on the input notice type, inserts the contents of the notice output screen W600 into a predetermined position in the acquired format, creates a notice as shown in Fig. 41, and instructs the output device 202 to print it (S509). The notice output unit 121 may store the printed record in the storage unit 103.

[0157] Here, the demand note type is input by displaying a list in a pop-up screen in which name codes and names are associated with each other from the court classification table of the name master DB 138, and selecting a name code from the list. Figure 42 is a diagram showing an example of the demand note type table of the name master DB 138. For example, there are notices such as "C, D, F, G, H, J, K" in the notice type table, which are used to demand payment of overdue amounts when a party who has promised to make installment repayments through specific mediation, reconciliation, rehabilitation, etc., defaults on their repayments. There are also notices such as "E" in the notice type table, which demand a lump-sum repayment from a party who does not make installment repayments or who has reneged on a promise to make installment repayments through specific mediation, reconciliation, rehabilitation, etc., and for whom the final due date has passed.

[0158] The notice of demand shown in Figure 41 lists the sum of the remaining reimbursement rights and the remaining damages displayed on the notice of demand output screen W600 as the "remaining principal," the damages calculated in S507 as the "late damages," and the remaining investigation expenses displayed on the notice of demand output screen W600 as the "expenses." The notice also lists the "total" which is the sum of the "remaining principal," "late damages," and "expenses." Note that the total is the total as of the date on the notice of demand. Furthermore, if court information is presented on the notice of demand output screen W600, the court information will also be listed on the notice of demand.

[0159] As described above in detail, the debt balance management system of this embodiment can manage the debt balances of the heirs and the deceased by managing debt data related to the heirs, data on deposits from the heirs, and data on withdrawals to the heirs. Furthermore, the debt balance management system can manage not only debts that have been simply acknowledged, but also debts that have been settled through negotiations such as mediation and settlement, debt consolidation, or legal procedures, thereby managing debt balances that reflect the status and results of negotiations. In addition, the debt balance management system not only manages the debt balance but also manages the debt repayment plan, and can also create reminder letters if payments from heirs are delayed.

[0160] It goes without saying that the present invention is not limited to the above-described embodiments and can be modified in various ways without departing from the spirit of the present invention. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those having all of the described configurations. Furthermore, it is possible to add, delete, or replace part of the configuration of the above-described embodiments with other configurations.

[0161] Furthermore, the above-described configurations, functional units, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), an IC card, an SD card, a DVD, or other recording media.

[0162] In addition, in the above figures, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily show all the control lines and information lines that are actually implemented. For example, it can be considered that almost all components are actually connected to each other.

[0163] Furthermore, the above-described layout of the various functional units, processing units, and databases of the image recognition device 10 is merely an example. The layout of the various functional units, processing units, and databases can be changed to an optimal layout in terms of the performance, processing efficiency, communication efficiency, etc. of the hardware and software provided in these devices.

[0164] Furthermore, the configuration (schema, etc.) of the database that stores the various types of data described above can be flexibly changed from the viewpoint of efficient use of resources, improved processing efficiency, improved access efficiency, improved search efficiency, and the like. [Explanation of symbols]

[0165] 1. Debt balance management system 100 Debt balance management device 101 Control section 103 Storage section 105 Input / Output Interface 110 Master Management Department 111 Personnel Management Department 112 Deposit Management Department 113 Withdrawal Management Department 114 Deposit and Withdrawal History Management Department 115 Negotiation Memo Management Department 116 Mediation and Settlement Management Department 117 Debt Settlement Management Department 118 Legal Proceedings Management Department 119 Debt Management Department 120 Calculation Unit 121 Notice output section 130 Related Persons DB 131 Debt DB 132 Deposit DB 133 Withdrawal DB 134 Negotiation Memo DB 135 Mediation Settlement DB 136 Debt settlement DB 137 Legal Procedures DB 138 Name Master DB 201 Display device 202 Output Device 203 Input Device

Claims

1. A debt balance management system for managing debts of heirs, a related party management unit that acquires attribute data regarding debt related parties, including a debtor or a joint guarantor, and an heir of the debtor or the joint guarantor; a debt management unit that acquires debt data relating to the debt of the debtor or the joint guarantor; a deposit management unit that acquires deposit data for the debt; a calculation unit that calculates the balance of the debt based on the debt data and the deposit data.

2. a withdrawal management unit that acquires withdrawal data for the debt, The debt balance management system according to claim 1 , wherein the calculation unit calculates the balance of the debt based on the debt data and the withdrawal data.

3. a negotiation management unit that acquires negotiation data related to the debt; The debt balance management system according to claim 1 , wherein the calculation unit calculates the debt data by referring to the negotiation data.

4. The debt balance management system according to claim 3 , wherein the negotiation management unit acquires debt repayment plan data for the debt data.

5. The debt balance management system according to claim 1 , wherein a notice of demand regarding the debt is automatically generated.

6. The debt balance management system of claim 1, wherein the calculation unit calculates the total balance of the debt based on the debt data and deposit data received from all debtors when there are multiple debtors.

7. A debt balance management method for managing debts of an heir, comprising: A step of acquiring attribute data regarding debt-related parties including a debtor or a joint guarantor and an heir of the debtor or the joint guarantor; acquiring debt data relating to the debt of the debtor or the guarantor; obtaining payment data for the debt; calculating a balance of the debt based on the debt data and the deposit data; Debt management methods, including:

8. Debt balance management system to manage heirs' debts a related party management unit that acquires attribute data regarding debt related parties, including debtors or joint guarantors, and heirs of the debtor or joint guarantor; a debt management unit that acquires debt data relating to the debt of the debtor or the joint guarantor; a deposit management unit that acquires deposit data for the debt; a calculation unit that calculates the balance of the debt based on the debt data and the deposit data; A program that functions as a

Images