Debt management system, server, program, and information processing method

Abstract

We provide a system that allows debtors to manage their debts themselves through a simple procedure. [Solution] The debt management system includes a control unit that performs the steps of: acquiring debt information relating to a debtor's debts; acquiring settlement terms information relating to the terms of settlement with the creditor of the debts; and generating a settlement proposal with the creditor based on the received debt information and the settlement terms information.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to a debt management system, a server, a program, and an information processing method.

Background Art

[0002] Systems have been developed for managing debts such as repayment of borrowed money that a debtor has borrowed from a creditor.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] On the other hand, in conventional debt management systems, it is common for debtors to consult an expert such as a lawyer in order to conduct debt restructuring by reaching an agreement with the creditor regarding the waiver (or reduction) of interest on future repayments. However, since there is a high psychological barrier to conducting debt restructuring in such a manner, problems such as leading to multiple debts without debt restructuring have occurred.

[0005] The problem to be solved by the present disclosure is to provide a system that allows a debtor to conduct debt restructuring with a simple procedure.

Means for Solving the Problems

[0006] As one aspect of the present disclosure, there is provided a debt management system including a control unit that executes steps of acquiring debt information regarding a debtor's debt, acquiring settlement condition information regarding conditions for settlement with the creditor of the debt, and generating a settlement plan with the creditor based on the received debt information and the settlement condition information.

Brief Description of the Drawings

[0007] [Figure 1] Figure 1 is a block diagram showing the functional configuration of a debt management system according to an embodiment. [Figure 2] Figure 2 illustrates the data structure of a database stored in the memory unit. [Figure 3] Figure 3 illustrates the data structure of a database stored in the memory unit. [Figure 4] Figure 4 illustrates the data structure of a database stored in the memory unit. [Figure 5] Figure 5 shows the flow of debt restructuring using a debt management system. [Figure 6] Figure 6 shows the flow of debt restructuring using a debt management system. [Figure 7] Figure 7 shows the flow of the diagnostic result generation process using the debt management system. [Figure 8] Figure 8 is an example of a loan information input screen displayed on a debtor's terminal. [Figure 9] Figure 9 is an example of the income and expenditure information input screen displayed on the debtor's terminal. [Figure 10] Figure 10 is an example diagram showing the upper part of the diagnostic results display screen displayed on the debtor's terminal. [Figure 11] Figure 11 is an example diagram showing the lower part of the diagnostic results display screen displayed on the debtor's terminal. [Figure 12] Figure 12 illustrates an example of a history information request input screen displayed on a debtor's terminal. [Figure 13] Figure 13 illustrates a screen showing a request for transaction history information displayed on the debtor's terminal. [Figure 14] Figure 14 is an example of a status confirmation screen displayed on the debtor's terminal. [Figure 15] Figure 15 is an example of the settlement proposal transmission screen displayed on the debtor's terminal. [Figure 16] Figure 16 is an example of a status confirmation screen displayed on the debtor's terminal. [Figure 17] Figure 17 illustrates a negotiation result input screen displayed on the debtor's terminal. [Figure 18] Figure 18 is a block diagram showing the hardware configuration of the debt management system. [Modes for carrying out the invention]

[0008] <1. Embodiments> The debt management system 1, as an embodiment of this disclosure, will be described below with reference to the drawings. In this specification and in each drawing, elements similar to those already described will be denoted by the same reference numerals, and detailed descriptions will not be repeated. In this disclosure, users may include debtor users who are debtors who use the debt management system 1 to carry out debt restructuring, creditor users who are creditors of the debts subject to debt restructuring, and agent users who act as agents for debtors and perform debt restructuring-related services. Administrators mean those who manage and provide the debt management system 1. In principle, users and administrators are assumed to be different entities, but in one embodiment, an agent user may also serve as the administrator.

[0009] (1.1. Functional Configuration of Debt Management System 1) The functional configuration of the debt management system 1 according to this embodiment will be explained with reference to Figures 1 to 3. As shown in Figure 1, the debt management system 1 comprises a server 100, a debtor terminal 200, an external AI server 300, a creditor terminal 400, and an agent terminal 500. The server 100, the debtor terminal 200, the external AI server 300, the creditor terminal 400, and the agent terminal 500 are configured to communicate with each other.

[0010] Server 100 is an information processing device that, as an example, manages the debts of debtor user U. Server 10 performs processing related to debt restructuring as an example of debt management. Debt restructuring means a procedure in which a debtor who has difficulty repaying debts such as loans negotiates with creditors through an agent or directly to waive future interest or change repayment conditions. The hardware configuration of the information processing device will be described later.

[0011] Server 100 includes a control unit 110 and a storage unit 120. The control unit 110 controls the processing of server 100 as a processor. The control unit 110 includes a debt information acquisition module 111, a settlement condition acquisition module 112, and a settlement plan generation module 113.

[0012] The debt information acquisition module 111 acquires debt information regarding the debts of the debtor. The debt information may include borrowing information regarding the debtor's borrowings and income and expenditure information regarding the debtor's income and expenditures. The details of the processing of the debt information acquisition module 111 will be described later.

[0013] The settlement condition acquisition module 112 acquires settlement condition information regarding the settlement conditions between the debtor and the creditor. The settlement conditions are the conditions agreed upon by the creditor and the debtor regarding future repayment in debt restructuring, and may include the amount of waived interest (or reduced interest), total repayment amount, number of repayments, repayment deadline, applicability of campaigns, etc. The details of the processing of the settlement condition acquisition module 112 will be described later.

[0014] The settlement plan generation module 113 generates a settlement plan between the debtor and the creditor based on the debt information and the settlement condition information. The details of the processing of the settlement plan generation module 113 will be described later.

[0015] The storage unit 120 stores programs and data necessary for processing by the control unit 110, as well as data obtained through processing by the control unit 110. As an example, the storage unit 120 stores a debtor database 121, a loan information database 122, an income information database 123, an expenditure information database 124, and a settlement terms database 125. Details of each database will be described later.

[0016] The debtor terminal 200 is an information processing device equipped with input and output means, which can be operated by users and administrators. The debtor terminal 200 may be a general-purpose or dedicated personal computer, a smart device, etc. Smart devices include tablet terminals, smartphones, smart glasses, smartwatches, etc.

[0017] If the debtor terminal 200 is a tablet or smartphone, the debtor terminal 200 has a display that functions as both an input and output means. The debtor terminal 200 accepts data input through touch operations on the display by the debtor user.

[0018] The external AI server 300 is an external server that performs processing based on AI (Artificial Intelligence) technology, and may, for example, implement an LLM (Large Language Model).

[0019] The creditor terminal 400 is an information processing terminal that can be operated by a creditor user. The agent terminal 500 is an information processing terminal that can be operated by an agent user (for example, a judicial scrivener or lawyer) who performs duties as an agent regarding debt management.

[0020] (1.2. Data Structure) Referring to Figures 2 to 4, the data structure of the database stored in the storage unit 120 will be explained. Note that the data structure described below is merely an example, and it may not include all of the data, nor may it include other data.

[0021] As shown in Figure 2, each record in the debtor database 121 stores data about the debtor as debtor information. The debtor database 121 includes, as an example, the fields "Debtor Number", "Name", "Date of Birth", "Address", and "Former Name".

[0022] The item "Debtor Number" is an identifier used to uniquely identify a record in the debtor database 121, and functions as the primary key of the debtor database 121.

[0023] The "Name" field contains information about the name of the debtor (hereinafter referred to as "the debtor") corresponding to the record in the debtor database 121. The "Date of Birth" field contains information about the date of birth of the debtor.

[0024] The "Address" field contains information about the debtor's address. The "Former Name" field contains information about the debtor's former name.

[0025] As shown in Figure 2, each record in the loan information database 122 stores data related to the borrower's debt as loan information. The loan information database 122 includes, as an example, the following items: "Loan Number", "Debtor Number", "Lender", "Loan Amount", "Monthly Repayment Amount", "Loan Period", "Payment Status", and "Problem".

[0026] The item "Loan Number" is an identifier used to uniquely identify a record in the loan information database 122, and functions as the primary key of the loan information database 122.

[0027] The item "Debtor Number" is information about the debtor of the loan information (hereinafter referred to as "the said loan information") corresponding to the record in the loan information database 122. The item "Debtor Number" functions as a foreign key that references the item "Debtor Number" in the debtor database 121.

[0028] The item "Lender" contains information about the creditor who provided the loan information. The item "Loan Amount" contains information about the loan amount. The item "Monthly Repayment Amount" contains information about the monthly repayment amount for the loan information.

[0029] The "Loan Period" item contains information about the loan period of the loan in question. The "Payment Status" item contains information about the payment status of the loan in question. The "Problems" item contains information about the difficulties the debtor is experiencing regarding the loan in question.

[0030] As shown in Figure 3, each record in the income information database 123 stores income-related data from the debtor's income and expenditure information as income information. The income information database 123 includes, as an example, the items "Income Number", "Debtor Number", "Employment Status", "Net Income", and "Other Income".

[0031] The item "Income Number" is an identifier used to uniquely identify a record in the income information database 123, and functions as the primary key of the income information database 123.

[0032] The item "Debtor Number" is information about the debtor of the income information (hereinafter referred to as "the said income information") corresponding to the record in the income information database 123. The item "Debtor Number" functions as a foreign key that references the item "Debtor Number" in the debtor database 121.

[0033] The item "Employment Status" refers to information about the debtor's employment status in the income information. The item "Net Income" refers to information about the debtor's net income in the income information. The item "Other Income" refers to information about income other than the debtor's "Net Income" in the income information.

[0034] As shown in Figure 3, each record in the expenditure information database 124 stores expenditure data from the debtor's income and expenditure information as expenditure information. The expenditure information database 124 includes, as an example, the items "Expense Number", "Debtor Number", "Mortgage", "Car Loan", "Parking", "Food Expenses", and "Utilities".

[0035] The item "Expense Number" is an identifier used to uniquely identify a record in the expense information database 124, and functions as the primary key of the expense information database 124.

[0036] The item "Debtor Number" is information about the debtor of the expenditure information (hereinafter referred to as "the said expenditure information") corresponding to the record in the expenditure information database 124. The item "Debtor Number" functions as a foreign key that references the item "Debtor Number" in the debtor database 121.

[0037] The item "Mortgage" represents the amount spent on a mortgage in the relevant expenditure information. The item "Car loan" represents the amount spent on a car loan in the relevant expenditure information. The item "Parking" represents the amount spent on parking fees in the relevant expenditure information.

[0038] The item "Food Expenses" is the amount spent on food in the expenditure information. The item "Utilities Expenses" is the amount spent on utilities in the expenditure information. The items in the expenditure information database 124 may be configured to be set as appropriate according to the type of expenditure of the debtor user.

[0039] As shown in Figure 4, each record in the settlement terms database 125 stores settlement terms data for each creditor as settlement terms information. The settlement terms database 125 is generated based on past settlement cases. As an example, the settlement terms database 125 includes the following items: "Creditor Name", "Transaction Details", "Number of Installments", "Maximum Number of Installments", "Down Payment Required", and "Notes".

[0040] The item "Creditor Name" is the name of the creditor in the settlement terms (hereinafter referred to as "the said settlement terms") corresponding to the record in the settlement terms database 125. The item "Transaction Details" is information regarding the type of loan in the said settlement terms.

[0041] The item "Number of Installments" contains information about the number of future installment payments under the settlement terms. The item "Number of Installments" has a sub-item called "Number of Repayments." The sub-item "Number of Repayments" is the actual number of repayments made by the debtor during the settlement negotiations. In other words, the item "Number of Installments" specifies the number of future installments for each repayment made by the debtor during the settlement negotiations. Generally, the more repayments made in the past, the more installment payments will be made in the future.

[0042] The item "Maximum Number of Installments" is the maximum number of installments that the creditor can accept under the settlement terms. The item "Down Payment Required" is information regarding whether a down payment (a lump-sum repayment payment made after settlement negotiations) is required under the settlement terms.

[0043] The "Notes" section contains important points regarding the settlement terms and is based on past settlement records. For example, the "Notes" section may include the terms of debt restructuring applicable to the transaction. Specifically, for instance, • If the number of repayments made is less than the specified number (for example, 10 times), debt restructuring is not possible. • If the number of repayments is less than the specified number (for example, 20), future interest will be reduced, not waived. • If the number of repayments exceeds a specified number (for example, 20 times), future interest will be waived. Conditions for the creditor to agree to debt restructuring Conditions under which the creditor will not agree to debt restructuring These and other details are stipulated in the "Notes" section.

[0044] (1.3. Processing Procedure) Refer to Figures 5 to 18 to explain the processing flow in the debt management system 1.

[0045] (1.3.1. Overall Flow) As shown in Figure 5, in step S110, the debtor terminal 200 receives debt information. As described above, debt information may include borrowing information and income and expenditure information. The debtor terminal 200 receives input of borrowing information through the debtor user's operation on the borrowing information input screen 210 displayed on the display. The debtor terminal 200 also receives input of income and expenditure information through the debtor user's operation on the income and expenditure information input screen 220 displayed on the display.

[0046] Figure 8 is an example of the loan information input screen 210. As shown in Figure 8, the loan information input screen 210 includes a loan information input area 211 and an add loaner button 212.

[0047] The loan information input area 211 includes a lender input field 211a, a loan amount input field 211b, a repayment amount input field 211c, a repayment number input field 211d, and a loan period input button 211e. The debtor user can input information corresponding to each item in the loan information input area 211 regarding loan information to the lender.

[0048] The "Add Loan" button 212 is used to add loan information for multiple lenders when the debtor user has borrowed from several lenders. By pressing the "Add Loan" button 212, the debtor user can input loan information data for multiple lenders.

[0049] Figure 9 is an example of the income and expenditure information input screen 220. As shown in Figure 9, the income and expenditure information input screen 220 includes an income and expenditure information input area 221, a diagnosis result confirmation button 222, and a specialist consultation button 223.

[0050] The income and expenditure information input area 221 includes an employment type input button 221a, an income amount input field 221b, an expenditure amount input field 221c, and an expenditure information confirmation button 221d. The debtor user can input information corresponding to each item in the income and expenditure information input area 221 regarding income and expenditure information to the lender.

[0051] The diagnostic result confirmation button 222 is a button used to perform a diagnosis of the debt repayment status based on the debt information (i.e., borrowing information and income / expense information) entered by the debtor user. When the debtor user presses the diagnostic result confirmation button 222, the process in step S115 is executed.

[0052] The Expert Consultation Button 223 is a button that allows debtor users to consult with an expert (for example, a judicial scrivener or lawyer) about their debt. When a debtor user presses the Expert Consultation Button 223, the debt information entered by the user is sent to the agent terminal 500. The user can then enter their personal information to consult with the expert managing the agent terminal 500 about their debt.

[0053] In step S115, the debtor terminal 200 transmits the debt information received from the debtor user to the server 100. In step S210, the server 100 receives the debt information. The debt information acquisition module 111 of the server 100 acquires the received debt information.

[0054] In step S400, the server 100 executes the diagnostic result generation process. This generates a diagnostic result regarding the debt repayment status. The diagnostic result may mainly include the repayment plan and analysis. Details of the diagnostic result generation process will be described later.

[0055] In step S215, the server 100 transmits the diagnostic results to the debtor terminal 200. In step S120, the debtor terminal 200 receives the diagnostic results. In step S125, the debtor terminal 200 displays the diagnostic results display screen 230 on its display based on the received diagnostic results.

[0056] Figure 10 is an example of the upper part of the diagnostic results display screen 230. Figure 11 is an example of the lower part of the diagnostic results display screen 230. As shown in Figures 11 and 12, the diagnostic results display screen 230 includes a repayment plan display area 231, a breakdown display area 232, an analysis content display area 233, an income and expenditure status display area 234, a revised proposal selection button 235, a revised execution button 236, and a debt settlement start button 237.

[0057] The repayment plan display area 231 displays a future repayment plan generated based on the debt information received from the user. The repayment plan may include, for example, information such as the amount that can be reduced if debt restructuring is performed, the total amount borrowed, the total monthly repayment amount, the total repayment amount including interest, the amount of interest, the expected year and month of completion, and the period until completion.

[0058] In the breakdown display area 232, if the debtor user has borrowed from multiple lenders, the repayment plans for each lender are displayed side by side. By pressing the lender selection button 232a, the debtor user can easily check the repayment plan for each lender and consider the repayment plan for each lender.

[0059] The analysis content display area 233 displays the analysis of the repayment status generated based on the debt information received from the user. The analysis content may include information such as whether the debtor's loan repayment status is sustainable or difficult to maintain, as well as advice on how to repay the debt more quickly.

[0060] In the income and expenditure display area 234, the surplus amount that can be used to repay loans is calculated and displayed based on the income and expenditure information received from the user.

[0061] The proposed revision button 235 is used to select a revision policy for the repayment plan based on the current diagnostic results. By selecting the proposed revision button 235, the debtor user can revise the repayment plan according to the selected policy.

[0062] The modification execution button 236 is a button for generating a revised repayment plan. By pressing the modification execution button 236, the debtor user executes step S135 in Figure 6, and a revised plan is generated in accordance with the content of the selected revised plan selection button 235.

[0063] The debt restructuring start button 237 is a button that allows the debtor user to initiate debt restructuring themselves. When the debtor user presses the debt restructuring start button 237, step S130 in Figure 5 is executed. Preferably, when the debt restructuring start button 237 is pressed, a warning about preferential payments is displayed. By implementing this specification, the risk of the user's self-initiated debt restructuring resulting in preferential payments can be reduced.

[0064] Alternatively, a "Consult a Specialist" button may be displayed alongside the "Start Debt Settlement" button 237. In this case, the debtor user can press the "Consult a Specialist" button, and the diagnosis results of the debtor user will be sent to the agent terminal 500. This allows the debtor user to request a specialist to handle the subsequent debt settlement procedures.

[0065] In step S130, the debtor terminal 200 accepts a request for historical information. Historical information refers to the history of the debtor's debts managed by the creditor. In this embodiment, when a debtor is to handle debt restructuring themselves, it is mandatory for them to request historical information managed by the creditor. This makes it possible to conduct accurate settlement negotiations based on the historical information managed by the creditor. The debtor terminal 200 accepts input of borrowing information through the debtor user's operation on the historical information request input screen 240 displayed on the display.

[0066] Figure 12 is an example of the history information request input screen 240. As shown in Figure 12, the history information request input screen 240 includes a request button 241, a request input area 242, and a request details confirmation button 243.

[0067] The request button 241 is pressed by the debtor user when they wish to request the historical information from a professional rather than doing so themselves. When the debtor user presses the request button 241, a request for historical information is sent to the agent terminal 500.

[0068] The billing input area 242 includes a name confirmation button 242a, an address confirmation button 242b, a date of birth input field 242c, a membership number input field 242d, and a contract number input field 242e. The debtor user can enter information corresponding to each item necessary for requesting history information.

[0069] The billing details confirmation button 243 is a button for the debtor user to confirm the request for historical information. When the debtor user presses the billing details confirmation button, the historical information request transmission screen 250 is displayed on the debtor terminal 200's display.

[0070] Figure 13 is an example of the history information request submission screen 250. As shown in Figure 13, the history information request submission screen 250 includes a history information request confirmation area 251 and a history information request submission button 252.

[0071] The history information request confirmation area 251 displays a draft of the history information disclosure request form, which is generated based on the information entered by the debtor user on the history information request input screen 240.

[0072] The History Information Request Send Button 252 is a button for sending a History Information Disclosure Request. When the debtor user presses the History Information Request Send Button 252, the debtor terminal 200 sends the History Information Disclosure Request to the server 100.

[0073] In step S220, the server 100 receives the request for disclosure of historical information. In step S225, the server 100 sends the request for disclosure of historical information to the creditor terminal 400. In step S310, the creditor terminal 400 receives the request for disclosure of historical information.

[0074] In step S315, the creditor terminal 400 sends the history information requested in the history information disclosure request form to the server 100. In step S230, the server 100 receives the history information. If the content of the history information received by the server 100 differs from the debt data received from the debtor, the server prompts the debtor to correct the diagnosis result, and step S135 is executed.

[0075] As shown in Figure 6, in step S135, the debtor terminal 200 accepts the correction of the diagnostic result. For example, the creditor user presses the correction execution button 236 on the diagnostic result display screen 230 shown in Figure 11. In step S235, the server 100 accepts the request for correction of the diagnostic result.

[0076] In step S400, the server 100 executes the diagnostic result generation process. This generates the corrected diagnostic result. In step S240, the server 100 sends the corrected diagnostic result to the debtor terminal 200. In step S140, the debtor terminal 200 receives the corrected diagnostic result. The debtor terminal 200 displays a status confirmation screen 260 based on the corrected diagnostic result on its display.

[0077] Figure 14 is an example of the status confirmation screen 260. As shown in Figure 14, the status confirmation screen 260 includes a next action display area 261, a diagnosis result display area 262, and a settlement status confirmation area 263.

[0078] The next action display area 261 shows what the debtor user, who is handling their own debt restructuring, should do next.

[0079] The revised diagnostic results are displayed in the diagnostic results display area 262. The debtor user can confirm the revised diagnostic results by pressing the diagnostic results confirmation button 262a. The debtor user can also correct the debt information or income and expenditure information and revise the diagnostic results again by pressing the correction button 262b.

[0080] The settlement status confirmation area 263 displays the progress of debt restructuring for each lender. The debtor user can create a settlement proposal for a lender by pressing the "Create Settlement Proposal" button 263a1 in the lender display field 263a. A settlement proposal is a document that outlines the proposed settlement terms that the debtor user will present to the creditor user. The debtor user can add information about a lender by pressing the "Add Lender" button 263c. When the debtor user presses the "Create Settlement Proposal" button 263a1, step S145 is executed.

[0081] In step S145, the debtor terminal 200 sends a request to the server 100 to generate a settlement proposal. In step S245, the server 100 accepts the request to generate a settlement proposal.

[0082] In step S250, the settlement proposal generation module 113 of the server 100 generates a settlement proposal based on the diagnostic results. This settlement proposal may include information such as the settlement amount (total repayment amount), the amount of interest waived, the number of repayments, and the scheduled repayment date.

[0083] In step S255, the server 100 sends the generated settlement proposal to the debtor terminal 200. In step S150, the debtor terminal 200 receives the settlement proposal. Based on the received settlement proposal, the debtor terminal 200 displays the settlement proposal transmission screen 270 on its display.

[0084] Figure 15 is an example of the settlement proposal submission screen 270. As shown in Figure 15, the settlement proposal submission screen 270 includes a settlement proposal confirmation area 271 and a settlement proposal submission button 272.

[0085] The settlement proposal confirmation area 271 displays the settlement proposal that will be sent to the creditor terminal 400 as a settlement proposal. The creditor user can review the settlement proposal displayed in the settlement proposal confirmation area 271.

[0086] The settlement proposal submission button 272 is a button used by the creditor user to send a settlement proposal to the creditor terminal 400. When the settlement proposal submission button 272 is pressed, step S260 is executed.

[0087] In step S260, the server 100 sends a settlement proposal, including the settlement plan, to the creditor terminal 400. In step S320, the creditor terminal 400 receives the settlement proposal. The creditor considers whether or not they can agree to the received settlement proposal.

[0088] Server 100 sends a notification to debtor terminal 200 that it has sent the settlement proposal to creditor terminal 400. Upon receiving this notification, debtor terminal 200 reflects the status on status confirmation screen 260. As shown in Figure 16, on status confirmation screen 260, the status of sending the settlement proposal to each lender is reflected in the lender display column 263a of the settlement status confirmation area 263.

[0089] If the creditor agrees to the contents of the settlement proposal, in step S325, the creditor terminal 400 sends a notification to the server 100 indicating acceptance of the settlement proposal. In step S265, the server 100 receives the notification of acceptance of the settlement proposal. The server 100 sends a notification of acceptance of the settlement proposal to the debtor terminal 200. The debtor terminal 200 displays the notification on its display.

[0090] Upon confirming the notification that the debtor user has accepted the settlement proposal, they press the negotiation result input button 263a2 on the status confirmation screen 260. When the negotiation result input button 263a2 is pressed, the negotiation result input screen 280 is displayed.

[0091] Figure 17 is an example of the negotiation result input screen 280. As shown in Figure 17, the negotiation result input screen 280 includes a negotiation result input button 281 and a negotiation completion button 282.

[0092] The Negotiation Result Input Button 281 is a button for the creditor user to input the results of the settlement negotiation. The creditor user can select a button corresponding to the outcome of the settlement negotiation. For example, if the creditor user agrees to the contents of the settlement proposal, the debtor user presses the "Success" button. The Negotiation Complete Button 282 is a button for the creditor user to confirm the negotiation results. When the Negotiation Complete Button 282 is pressed, the settlement negotiation is completed. If the "Success" button of the Negotiation Result Input Button 281 is pressed, step S160 is executed.

[0093] In step S160, a settlement is concluded between the creditor user and the debtor user. The creditor user and the debtor user may exchange contracts or other documents as needed. Once the settlement is concluded, as shown in Figure 18, the status confirmation screen 260 will display a message indicating that the settlement with the lender has been completed.

[0094] (1.3.2. Flow of the diagnostic result generation process) Referring to Figure 7, the flow of the diagnostic result generation process (S400) will be explained. In step S510, the settlement conditions acquisition module 112 of the server 100 refers to the settlement conditions database 125 to acquire settlement conditions corresponding to the debt information acquired from the debtor user. As an example, the settlement conditions acquisition module 112 acquires the repayment conditions corresponding to the debt data acquired from the debtor user from the settlement conditions database 125. Specifically, for example, it refers to the item "Number of installments" in the settlement conditions database 125 to acquire the sub-item "Number of repayments" corresponding to the actual number of repayments in the debt data.

[0095] In step S515, the settlement proposal generation module 113 of the server 100 generates a repayment plan. In step S520, the server 100 generates prompts necessary for querying the external AI server 300 to generate analysis content. In generating prompts, so-called RAG (Retrieval-Augmented Generation) may be used. For example, in the preceding information retrieval step, the server 100 may search for information specified in the "Notes" item of the settlement conditions database 125, and in the subsequent generation (Augmented Generation) step, prompts may be generated to generate analysis content based on the information obtained from the search and the debt information received from the debtor. In this way, the external AI server 300 can generate analysis content based on the information specified in the "Notes" item of the settlement conditions database 125.

[0096] In step S525, server 100 sends a prompt to external AI server 300. In step S610, external AI server 300 receives the prompt.

[0097] In step S615, the external AI server 300 generates analysis content based on the received prompt. In step S620, the external AI server 300 sends the generated analysis content to the server 100. In step S530, the server 100 receives the analysis content.

[0098] In step S535, the server 100 generates a diagnostic result based on the repayment plan and analysis. The diagnostic result generation process (S400) is then executed. If the settlement proposal generation module 113 accepts a revision to the settlement proposal (S135), it may refer to the "Maximum Number" item in the settlement conditions database 125 to ensure that the number of future repayments desired by the debtor user does not exceed the maximum number.

[0099] (1.4. Hardware configuration of the information processing device) Referring to Figure 19, the hardware configuration of the information processing device used as server 100, debtor terminal 200, external AI server 300, creditor terminal 400, agent terminal 500, etc. will be described. As an example, the information processing device is implemented by the computer 90 shown in Figure 19. The computer 90 may include a CPU 91, ROM 92, RAM 93, storage 94, input interface 95, output interface 96, and communication interface 97.

[0100] The CPU 91 functions as a processor that executes processing. Specifically, the CPU 91 uses the RAM 93 as work memory and executes programs stored in at least one of the ROM 92 or storage 94. During program execution, the CPU 91 controls each component via the system bus 98 and performs various processes. As an example, the CPU 91 functions as a control unit 110.

[0101] ROM92 stores programs that control the operation of computer 90. ROM92 contains the programs necessary for computer 90 to perform each of the processes described above. RAM93 functions as a memory area where the programs stored in ROM92 are loaded.

[0102] The storage 94 stores data necessary for program execution and data obtained through program execution. The storage 94 includes one or more selected from Hard Disk Drives (HDDs) and Solid State Drives (SSDs). As an example, the storage 94 functions as a memory unit 120.

[0103] The input interface (I / F) 95 can connect the computer 90 and the input device 95a. The input interface 95 is, for example, a serial bus interface such as USB. The CPU 91 can read various data from the input device 95a via the input interface 95.

[0104] The output interface (I / F) 96 can connect the computer 90 to the output device 96a. The output interface 96 is a video output interface such as Digital Visual Interface (DVI) or High-Definition Multimedia Interface (HDMI®). The CPU 91 can transmit data to the output device 96a via the output interface 96 and cause the output device 96a to output data.

[0105] The input device 95a is an example of an input means and includes one or more selected from a mouse, keyboard, microphone (voice input), and touchpad. The output device 96a is an example of an output means and includes one or more selected from a display, projector, printer, and speaker. Devices that have the functions of both the input device 95a and the output device 96a, such as a touch panel, may also be used.

[0106] The communication interface (I / F) 97 allows the computer 90 to connect with an external server 97a located outside the computer 90. The communication interface 97 is, for example, a network card such as a LAN card. The CPU 91 can read various data from the external server 97a via the communication interface 97.

[0107] Each process performed by the server 100 may be implemented by a single computer 90, or it may be implemented through the cooperation of multiple computers 90.

[0108] The processing of the various data described above may be recorded as a program that can be executed by a computer on a magnetic disk (flexible disk and hard disk, etc.), an optical disk (CD-ROM, CD-R, CD-RW, DVD-ROM, DVD±R, DVD±RW, etc.), a semiconductor memory, or another non-transitory computer-readable storage medium.

[0109] For example, information recorded on a recording medium can be read by a computer (or embedded system). The recording format (storage format) of the recording medium is arbitrary. For example, a computer reads a program from the recording medium and, based on this program, causes the processor to execute the instructions written in the program. In a computer, program acquisition (or reading) may be performed via a network.

[0110] (1.5.Summary) As described above, the debt management system 1 in this disclosure comprises a server 100 having a control unit 110. The control unit 110 performs the steps of acquiring debt information relating to the debtor's debts, acquiring settlement terms information relating to the terms of settlement with the creditors of the debts, and generating a settlement proposal with the creditors based on the debt information and the settlement terms information. This configuration makes it possible for the debtor to carry out debt restructuring through a simple procedure.

[0111] Furthermore, debt information may include borrowing information received from the debtor regarding their debts. This specification makes it possible to smoothly guide debtors through the debt restructuring process, starting with inquiries about debt restructuring from them.

[0112] Furthermore, the settlement terms information includes information on precautions based on past settlement results. By generating settlement proposals with creditors based on precautions derived from past settlement results, the likelihood of creditors agreeing to the settlement proposal generated by the debt management system 1 can be increased.

[0113] Furthermore, the settlement proposal generated by the debt management system 1 may include a debt repayment plan. This specification allows for settlement negotiations with creditors based on a concrete repayment plan.

[0114] Furthermore, the repayment plan may include information on the repayment amount and number of repayments for each creditor. In this way, for debtors who have borrowed from multiple creditors, generating a separate repayment plan for each creditor makes it possible to conduct settlement negotiations with each creditor in parallel.

[0115] Furthermore, the control unit 110 may be configured to modify the settlement proposal based on a request from the user and present it to the user. With such a configuration, the user, as the debtor, can flexibly modify the presented settlement proposal and easily present a repayment plan to the creditor that they are able to fulfill.

[0116] Furthermore, the control unit 110 presents the user with repayment plans for each of the multiple lenders side by side. This specification allows the user, as a debtor, to compare the repayment plans for each of the multiple lenders and consider whether or not to pursue debt restructuring for each lender.

[0117] Furthermore, the control unit 110 may be configured to generate a settlement proposal to the creditor based on the generated settlement plan. This configuration saves the user, as the debtor, the trouble of generating a settlement proposal, and also reduces the costs that may be incurred if the settlement proposal is to be prepared by a specialist.

[0118] Furthermore, the control unit 110 transmits debt information to a specialist based on a request from the user. This specification allows the user, as the debtor, to coordinate with a specialist at the time they desire, saving the user the trouble of finding a specialist themselves.

[0119] Furthermore, the debt management system 1 is further equipped with a storage unit 120 that stores settlement terms information, and the control unit 110 updates the settlement terms information in the storage unit 120 based on the history of settlements between creditors and debtors. By updating the settlement terms information in the storage unit 120 based on the history of settlements in this way, the likelihood of creditors agreeing to future settlement proposals can be increased.

[0120] <2. Other Embodiments> The debt management system 1 according to this embodiment has been described above, but the application of the technical ideas of this disclosure is not limited to the above embodiment. For example, in the above embodiment, the external AI server 300 is used with RAG only for generating the analysis content in the diagnostic result generation process (S400), but the invention is not limited to this embodiment. For example, the external AI server 300 may also be used with RAG for generating the repayment plan.

[0121] Specifically, for example, in the preceding information retrieval step, the system may retrieve information stored in the "Notes" item of the settlement terms database 125, and in the subsequent augmented generation step, it may generate a prompt to generate a repayment plan based on the information obtained from the retrieval. In this way, the external AI server 300 can generate a repayment plan based on the information specified in the "Notes" item of the settlement terms database 125.

[0122] Furthermore, the server 100 may be configured to update the settlement terms database 125 based on the content of the settlement after the settlement is concluded in step S160. Specifically, for example, it may be configured to update or add the item "Notes" based on the content of the settlement. By adopting such a configuration, settlement terms based on settlement history will be accumulated in the settlement terms database 125, making it possible to generate and present to creditors settlement proposals that are more diverse and have a higher probability of being concluded. In this way, by presenting creditors with settlement proposals based on settlement history, when debtors conduct settlement negotiations without an agent, the creditors have less incentive to refuse on the grounds of the absence of an agent, thereby promoting debt restructuring by debtors themselves.

[0123] Furthermore, in the above embodiment, the settlement terms database 125 is centrally managed by the server 10, but the system is not limited to this configuration. Specifically, for example, the settlement terms database 125 may be stored in the memory of the agent terminal 500 for each agent, and the system may be configured to provide debt restructuring services by the debt restructuring system to each agent. With such a configuration, agents can update the settlement terms based on their own experience and generate settlement proposals, making it possible to present creditors with a variety of settlement proposals that are more in line with their practical experience and have a higher degree of accuracy.

[0124] Furthermore, in the above embodiment, the server 100 and the creditor terminal 400 are configured to communicate with each other, and the server 100 is configured to send settlement proposals, etc., to the creditor terminal 400, but the system is not limited to this configuration. For example, the settlement proposal may be sent from the server 100 to the creditor using other communication equipment such as a fax machine.

[0125] Furthermore, server 100 may be linked with other debt management systems. For example, server 100 may be linked with a remittance management system that allows a lawyer or other representative to manage remittances from debtors to creditors. This specification would further improve the convenience of debtor debt management.

[0126] While several embodiments of this disclosure have been illustrated above, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. Furthermore, the embodiments described above can be implemented in combination with each other. [Explanation of Symbols]

[0127] 1: Debt management system, 90: Computer, 91: CPU, 92: ROM, 93: RAM, 94: Storage, 95: Input interface, 95a: Input device, 96: Output interface, 96a: Output device, 97: Communication interface, 97a: External server, 98: System bus, 100: Server, 110: Control unit, 111: Debt information acquisition module, 112: Settlement terms acquisition module, 113: Settlement proposal generation module, 120: Memory unit, 121: Debtor database, 122: Loan information database, 123: Income information database, 124: Expenditure information Information Database, 125: Settlement Terms Database, 200: Debtor Terminal, 210: Loan Information Input Screen, 211: Loan Information Input Area, 211a: Lender Input Field, 211b: Loan Amount Input Field, 211c: Repayment Amount Input Field, 211d: Number of Repayments Input Field, 211e: Loan Period Input Button, 212: Add Lender Button, 220: Income and Expenditure Information Input Screen, 221: Income and Expenditure Information Input Area, 221a: Employment Type Input Button, 221b: Income Amount Input Field, 221c: Expenditure Amount Input Field, 221d: Expenditure Information Confirmation Button, 222: Diagnosis Result Confirmation Button, 223: Expert Consultation Button, 230: Diagnosis Result Result display screen, 231: Repayment plan display area, 232: Breakdown display area, 232a: Specify lender button, 233: Analysis content display area, 234: Income and expenditure status display area, 235: Select revision proposal button, 236: Execute revision button, 237: Start debt restructuring button, 240: History information request input screen, 241: Request button, 242: Request input area, 242a: Name confirmation button, 242b: Address confirmation button, 242c: Date of birth input field, 242d: Membership number input field, 242e: Contract number input field, 243: Request details confirmation button, 250: History information request submission screen, 251: History information request Request confirmation area, 252: Send history information request button, 260: Status confirmation screen, 261: Next action display area, 262: Diagnosis result display area, 262a: Confirm diagnosis result button, 262b: Edit button, 263: Settlement status confirmation area, 263a: Lender display field, 263a1: Create settlement proposal button, 263a2: Input negotiation result button, 263c: Add lender button, 270: Send settlement proposal screen, 271: Confirm settlement proposal area, 272: Send settlement proposal button, 280: Input negotiation result screen, 281: Input negotiation result button, 282: Complete negotiation button, 300: External AI server,400: Creditor terminal, 500: Agent terminal,

Claims

1. Steps to obtain debt information regarding the debtor's debts, A step of obtaining settlement terms information regarding the terms of settlement with the creditor of the said debt, A debt management system comprising a control unit that performs the steps of generating a settlement proposal with the creditor based on the debt information and the settlement terms information.

2. The debt management system according to claim 1, wherein the debt information includes borrowing information received from the debtor with respect to the debt.

3. The debt management system according to claim 1, wherein the settlement terms information includes information regarding precautions based on past settlement records.

4. The debt management system according to claim 1, wherein the settlement proposal includes a debt repayment plan.

5. The debt management system according to claim 4, wherein the repayment plan includes information on the repayment amount and number of repayments for each creditor of the debt.

6. The debt management system according to claim 1, wherein the control unit modifies the settlement proposal based on a request from the user and presents it to the user.

7. The debt management system according to claim 1, wherein the control unit presents to the user, side by side, repayment plans for each of the multiple lenders.

8. The debt management system according to claim 1, wherein the control unit generates a settlement proposal to the creditor based on the settlement proposal.

9. The debt management system according to claim 1, wherein the control unit transmits the debt information to an expert based on a request from the user.

10. It further includes a memory unit for storing settlement terms information, The debt management system according to claim 1, wherein the control unit, in the step of generating the settlement proposal, generates a prompt for generating a repayment plan based on the settlement conditions information obtained by searching the storage unit, and transmits the prompt to an external server on which a large-scale language model is implemented.

11. It further includes a memory unit for storing settlement terms information, The debt management system according to claim 1, wherein the control unit updates the settlement terms information in the storage unit based on the actual settlement results between the creditor and the debtor.

12. Equipped with a control unit, Steps to obtain debt information regarding the debtor's debts, A step of obtaining settlement terms information regarding the terms of settlement with the creditor of the said debt, An information processing device that performs the steps of generating a settlement proposal with the creditor based on the debt information and the settlement terms information.

13. An information processing device equipped with a control unit, Steps to obtain debt information regarding the debtor's debts, A step of obtaining settlement terms information regarding the terms of settlement with the creditor of the said debt, A program that performs the steps of generating a settlement proposal with the creditor based on the debt information and the settlement terms information.

14. An information processing device equipped with a control unit, Steps to obtain debt information regarding the debtor's debts, A step of obtaining settlement terms information regarding the terms of settlement with the creditor of the said debt, An information processing method that performs the step of generating a settlement proposal with the creditor based on the debt information and the settlement terms information.

Images