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

Abstract

To provide a system that enables debtors themselves to carry out debt restructuring through simple procedures. [Solution] The debt management system has a control unit that executes the steps of acquiring debt information regarding a debtor's debt, acquiring settlement condition information regarding the terms of settlement with a creditor of the debt, and generating a settlement proposal with the creditor based on the received debt information and settlement condition information.

Description

[Technical field]

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

[0002] 2. Description of the Related Art Systems have been developed for managing debts, such as repayment of loans borrowed by debtors from creditors. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2024-122547 A Summary of the Invention [Problem to be solved by the invention]

[0004] On the other hand, in conventional debt management systems, debtors generally ask a lawyer or other professional to settle their debts by agreeing with creditors to waive (or reduce) interest on future repayments. However, the psychological barrier to such debt settlement is high, which has led to problems such as multiple debts not being settled.

[0005] The problem that the present disclosure aims to solve is to provide a system that allows debtors themselves to restructure their debts through simple procedures. [Means for solving the problem]

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

[0007] [Figure 1] FIG. 1 is a block diagram showing the functional configuration of a debt management system according to an embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of a data structure of a database stored in the storage unit. [Diagram 3] FIG. 3 is a diagram illustrating an example of a data structure of a database stored in the storage unit. [Figure 4] FIG. 4 is a diagram illustrating an example of a data structure of a database stored in the storage unit. [Diagram 5] FIG. 5 is a diagram showing the flow of debt consolidation using a debt management system. [Figure 6] FIG. 6 is a diagram showing the flow of debt consolidation using a debt management system. [Figure 7] FIG. 7 is a diagram showing the flow of diagnostic result generation processing using the debt management system. [Figure 8] FIG. 8 is a diagram illustrating an example of a loan information input screen displayed on the debtor terminal. [Figure 9] FIG. 9 is a diagram illustrating an example of an income / expense information input screen displayed on a debtor terminal. [Figure 10] FIG. 10 is a diagram illustrating an example of the upper part of the diagnosis result display screen displayed on the debtor terminal. [Figure 11] FIG. 11 is a diagram illustrating an example of the lower part of the diagnosis result display screen displayed on the debtor terminal. [Figure 12] FIG. 12 is a diagram showing an example of a history information request input screen displayed on the debtor terminal. [Figure 13] FIG. 13 is a diagram showing an example of a history information request transmission screen displayed on the debtor terminal. [Figure 14] FIG. 14 is a diagram showing an example of a status confirmation screen displayed on the debtor terminal. [Figure 15] FIG. 15 is a diagram illustrating an example of a settlement proposal transmission screen displayed on the debtor terminal. [Figure 16] FIG. 16 is a diagram showing an example of a status confirmation screen displayed on the debtor terminal. [Figure 17] FIG. 17 is a diagram illustrating an example of a negotiation result input screen displayed on the debtor terminal. [Figure 18] FIG. 18 is a block diagram showing the hardware configuration of the debt management system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] <1. Embodiment> The debt management system 1 according to an embodiment of the present disclosure will be described below with reference to the drawings. In the present specification and each drawing, elements similar to those already described are given the same reference numerals and detailed description will not be repeated. In the present disclosure, the user may include a debtor user who is a debtor who uses the debt management system 1 to carry out debt restructuring, a creditor user who is a creditor related to the debt that is the subject of debt restructuring, and an agent user who performs work related to debt restructuring as an agent of the debtor. In addition, the administrator means a person who manages and provides the debt management system 1. In principle, different aspects are assumed between the user and the administrator, but in one aspect, the agent user may also serve as the administrator.

[0009] (1.1. Functional configuration of debt management system 1) The functional configuration of a debt management system 1 according to an embodiment will be described with reference to FIGS. 1 to 3. 1, the debt management system 1 includes 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 be able to communicate with each other.

[0010] The server 100 is, as an example, an information processing device that manages the debt of a debtor user U. The server 10 performs processing related to debt consolidation as an example of debt management. Debt consolidation refers to a procedure in which a debtor who has difficulty repaying a debt, such as a loan, negotiates with a creditor, either directly or through an agent, to exempt future interest or change repayment conditions. The hardware configuration of the information processing device will be described later.

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

[0012] The debt information acquisition module 111 acquires debt information related to the debtor's debt. The debt information may include borrowing information related to the debtor's borrowing and balance information related to the debtor's income and expenditure. The process of the debt information acquisition module 111 will be described in detail later.

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

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

[0015] The storage unit 120 stores programs and data necessary for the processing of the control unit 110, data obtained by the processing of the control unit 110, etc. 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 conditions database 125. Details of each database will be described later.

[0016] The debtor terminal 200 is an information processing device that includes input means and output means and can be operated by a user and an administrator. The debtor terminal 200 may be a general-purpose or dedicated personal computer, a smart device, etc. The smart device may be a tablet terminal, a smartphone, smart glasses, a smart watch, etc.

[0017] When the debtor terminal 200 is a tablet terminal or a smartphone, the debtor terminal 200 has a display that functions as an input means and an output means. The debtor terminal 200 accepts data input by a debtor user's touch operation on the display.

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

[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) 2 to 4, the data structure of the database stored in storage unit 120 will be described. Note that the data structure described below is merely an example, and may not include some data, or may include other data.

[0021] 2, each record in the debtor database 121 stores data on a debtor as debtor information. As an example, the debtor database 121 includes an item "debtor number", an item "name", an item "date of birth", an item "address", and an item "maiden name".

[0022] The item “debtor number” is an identifier for uniquely identifying a record in the debtor database 121 and functions as a primary key of the debtor database 121 .

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

[0024] The item "Address" is information about the address of the debtor. The item "Maiden name" is information about the maiden name of the debtor.

[0025] 2, each record in the loan information database 122 stores data on loans as debt information of a debtor as loan information. As an example, the loan information database 122 includes an item "loan number", an item "debtor number", an item "lender", an item "loan amount", an item "monthly repayment amount", an item "loan period", an item "payment status", and an item "problem".

[0026] The item “loan number” is an identifier for uniquely identifying a record in the loan information database 122 and functions as a 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 loan information) corresponding to the record in the loan information database 122. The item "debtor number" functions as an external key that references the item "debtor number" in the debtor database 121.

[0028] The item "Lender" is information on the creditor as the borrower of the borrowing information. The item "Loan amount" is information on the loan amount of the borrowing information. The item "Monthly repayment amount" is information on the monthly repayment amount of the borrowing information.

[0029] The item "loan period" is information about the loan period of the loan information. The item "payment status" is information about the payment status of the loan information. The item "problem" is information about the circumstances in which the debtor is in trouble with respect to the loan information.

[0030] 3, each record in the income information database 123 stores data on income as income information among the debtor's income and expenditure information. The income information database 123 includes, as an example, an item "income number", an item "debtor number", an item "employment type", an item "take-home income", and an item "other income".

[0031] The item “income number” is an identifier for uniquely identifying a record in the income information database 123 and functions as a 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 income information) corresponding to the record in the income information database 123. The item “Debtor Number” functions as an external key that references the item “Debtor Number” in the debtor database 121.

[0033] The item "Employment type" is information about the employment type of the debtor in the income information. The item "Net income" is information about the debtor's net income in the income information. The item "Other income" is information about income other than the debtor's "Net income" in the income information.

[0034] 3, each record in the expenditure information database 124 stores data on expenditures from among the debtor's income and expenditure information as expenditure information. As an example, the expenditure information database 124 includes an item "expense number", an item "debtor number", an item "mortgage loan", an item "car loan", an item "parking", an item "food expenses", and an item "utility expenses".

[0035] The item “Expense number” is an identifier for uniquely identifying a record in the expense information database 124 , and functions as a 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 expenditure information) corresponding to a record in the expenditure information database 124. The item "debtor number" functions as an external key that references the item "debtor number" in the debtor database 121.

[0037] The item "Mortgage" is the amount of mortgage expenditure in the expenditure information. The item "Car loan" is the amount of car loan expenditure in the expenditure information. The item "Parking" is the amount of parking fee expenditure in the expenditure information.

[0038] The item "food expenses" is the amount of food expenses in the expenditure information. The item "utility expenses" is the amount of utility expenses in the expenditure information. The items in the expenditure information database 124 may be appropriately set according to the expenditure of the debtor user.

[0039] As shown in Figure 4, each record in the settlement conditions database 125 stores data on the settlement conditions for each creditor as settlement conditions information. The settlement conditions database 125 is generated based on the performance of past settlement cases. As an example, the settlement conditions 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 settlement terms) corresponding to a record in the settlement terms database 125. The item "transaction details" is information regarding the type of loan in the settlement terms.

[0041] The item "Number of Installments" is information about the number of future installments under the settlement terms. The item "Number of Installments" further has a subitem "Number of Repayments." The subitem "Number of Repayments" is the actual number of repayments at the time of the debtor's settlement negotiations. In other words, the item "Number of Installments" specifies the number of future installments for each number of repayments at the time of the debtor's settlement negotiations. Generally, the more actual number of repayments, the more future installments will be made.

[0042] The item "Maximum number of installments" is the maximum number of installments that the creditor can accept under the settlement conditions. The item "Whether down payment is required" is information about whether a down payment (a lump sum repayment amount paid after settlement negotiations) is required under the settlement conditions.

[0043] The item "Notes" is a note regarding the settlement conditions, and is specified based on past settlement records. As an example, the item "Notes" stores the conditions of debt restructuring that are applied to the transaction contents. Specifically, for example, If the number of repayments is less than the specified number (for example, 10 times), debt consolidation is not possible. If the number of repayments is less than a certain number (for example, 20), future interest will be reduced rather than waived. If the number of repayments is more than a certain number (e.g. 20), future interest will be waived. · Conditions for the creditor to agree to debt restructuring -Conditions under which the creditor does not agree to debt restructuring etc. are specified in the "Notes" section.

[0044] (1.3. Processing Procedure) The flow of processing in the debt management system 1 will be described with reference to FIGS.

[0045] (1.3.1. Overall flow) As shown in Fig. 5, in step S110, the debtor terminal 200 accepts debt information. As described above, the debt information may include loan information and balance information. The debtor terminal 200 accepts input of loan information by a debtor user's operation on a loan information input screen 210 displayed on the display. The debtor terminal 200 also accepts input of balance information by a debtor user's operation on a balance information input screen 220 displayed on the display.

[0046] 8 is a diagram illustrating an example of a loan information input screen 210. As shown in FIG. 8, the loan information input screen 210 includes a loan information input area 211 and an add loan destination 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 frequency 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 the loan information for the lender.

[0048] The add lender button 212 is a button for adding lender information when the debtor user has borrowed from multiple lenders. By pressing the add lender button 212, the debtor user can input loan information data for multiple lenders.

[0049] 9 is a diagram illustrating an example of an income / expense information input screen 220. As shown in FIG. 9, the income / expense information input screen 220 includes an income / expense information input area 221, a diagnosis result confirmation button 222, and an expert consultation button 223.

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

[0051] The diagnosis result confirmation button 222 is a button for executing a diagnosis of the debt repayment status based on the debt information (i.e., borrowing information and income and expenditure information) entered by the debtor user. When the debtor user presses the diagnosis result confirmation button 222, the process of step S115 is executed.

[0052] The expert consultation button 223 is a button that enables the debtor user to consult with an expert (for example, a judicial scrivener or lawyer) about the debt. When the debtor user presses the expert consultation button 223, the debt information entered by the user is transmitted to the agent terminal 500. Thereafter, the user can consult with the expert who manages the agent terminal 500 about the debt by entering personal information.

[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 a diagnostic result generation process. This generates a diagnostic result on the debt repayment status. The diagnostic result may mainly include a repayment plan and an analysis content. The diagnostic result generation process will be described in detail later.

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

[0056] Fig. 10 is a diagram illustrating an example of the upper part of the diagnosis result display screen 230. Fig. 11 is a diagram illustrating an example of the lower part of the diagnosis result display screen 230. As shown in Figs. 11 and 12, the diagnosis result 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 correction proposal selection button 235, a correction execution button 236, and a debt consolidation start button 237.

[0057] A future repayment plan generated based on debt information received from the user is displayed in the repayment plan display area 231. 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 interest amount, the expected year and month of full repayment, and the period until full repayment.

[0058] When a debtor user borrows from multiple lenders, the repayment plans for each lender are displayed side by side in the breakdown display area 232. By pressing the lender designation button 232a, the debtor user can easily check the repayment plan for each lender and can consider the repayment plan for each lender.

[0059] The analysis content of the repayment status generated based on the debt information received from the user is displayed in the analysis content display area 233. The analysis content may include information on whether the debtor's repayment status of the loan is sustainable or difficult to continue, advice on how to pay off the loan more quickly, and the like.

[0060] In the income / expense status display area 234, the surplus amount that can be appropriated for repaying the loan is calculated based on the income / expense information received from the user and is displayed.

[0061] The revision proposal selection button 235 is a button for selecting a revision policy for the repayment plan based on the current diagnosis result. By selecting the revision proposal selection button 235, the debtor user can revise the repayment plan in accordance with the selected policy.

[0062] The execute modification button 236 is a button for executing the generation of a proposed modification of the repayment plan. By pressing the execute modification button 236, the debtor user executes step S135 in Fig. 6, and a proposed modification is generated according to a policy in line with the contents of the selected proposed modification selection button 235.

[0063] The debt restructuring start button 237 is a button for the debtor user to carry out debt restructuring by himself / herself. When the debtor user presses the debt restructuring start button 237, step S130 in FIG. 5 is executed. When the debt restructuring start button 237 is pressed, it is preferable that a notice regarding preferential payment is displayed. By adopting such specifications, it is possible to reduce the risk that the debt restructuring by the user himself / herself becomes preferential payment.

[0064] Also, an expert consultation button may be displayed alongside the debt restructuring start button 237. In this case, by pressing the expert consultation button, the debtor user transmits the diagnosis result of the debtor user to the agent terminal 500. This allows the debtor user to request an expert to carry out subsequent debt restructuring procedures.

[0065] In step S130, the debtor terminal 200 accepts a request for historical information. Historical information is historical information about the debtor's debt managed by the creditor. In this embodiment, when the debtor performs debt restructuring himself, it is mandatory to request the historical information managed by the creditor. In this way, it becomes possible to conduct accurate settlement negotiations based on the historical information managed by the creditor. The debtor terminal 200 accepts input of loan information by the debtor user's operation on the historical information request input screen 240 displayed on the display.

[0066] 12 is a diagram illustrating a history information request input screen 240. As shown in FIG. 12, the history information request input screen 240 includes a request request button 241, a request input area 242, and a request content confirmation button 243.

[0067] The request button 241 is a button that the debtor user presses when he / she does not request the history information by himself / herself but requests an expert to do so. When the debtor user presses the request button 241, a request for the history information is transmitted to the agent terminal 500.

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

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

[0070] 13 is a diagram illustrating a history information request transmission screen 250. As shown in FIG. 13, the history information request transmission screen 250 includes a history information request confirmation area 251 and a history information request transmission button 252.

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

[0072] The history information request send button 252 is a button for sending a history information disclosure request form. When the debtor user presses the history information request send button 252, the debtor terminal 200 sends the history information disclosure request form to the server 100.

[0073] In step S220, the server 100 receives the history information disclosure claim form. In step S225, the server 100 transmits the history information disclosure claim form to the creditor terminal 400. In step S310, the creditor terminal 400 receives the history information disclosure claim form.

[0074] In step S315, the creditor terminal 400 transmits 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 accepted from the debtor, the debtor is prompted to correct the diagnosis result, and step S135 is executed.

[0075] As shown in Fig. 6, in step S135, the debtor terminal 200 accepts a request to correct the diagnosis result. As an example, the debtor user presses the correction execution button 236 on the diagnosis result display screen 230 shown in Fig. 11. In step S235, the server 100 accepts the request to correct the diagnosis result.

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

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

[0078] The next action display area 261 displays what the debtor user who is performing debt restructuring himself / herself should do next.

[0079] The corrected diagnostic result is displayed in the diagnostic result display area 262. The debtor user can confirm the corrected diagnostic result by pressing the diagnostic result confirmation button 262a. The debtor user can also correct the debt information or income / expense information and correct the diagnostic result 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 the lender by pressing the Create Settlement Proposal button 263a1 in the lender display field 263a. A settlement proposal is a document that describes the proposed settlement conditions that the debtor user presents to the creditor user. The debtor user can add information about the 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 transmits a request for creating a settlement proposal to the server 100. In step S245, the server 100 accepts the request for creating a settlement proposal.

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

[0083] In step S255, the server 100 transmits the generated settlement proposal to the debtor terminal 200. In step S150, the debtor terminal 200 receives the settlement proposal. The debtor terminal 200 displays a settlement proposal transmission screen 270 on the display based on the received settlement proposal.

[0084] 15 is a diagram illustrating a settlement proposal transmission screen 270. As shown in FIG. 15, the settlement proposal transmission screen 270 includes a settlement proposal confirmation area 271 and a settlement proposal transmission button 272.

[0085] The settlement proposal confirmation area 271 displays the settlement proposal to be transmitted as a settlement proposal to the creditor terminal 400. The creditor user can confirm the settlement proposal displayed in the settlement proposal confirmation area 271.

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

[0087] In step S260, the server 100 transmits 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 he or she can agree to the received settlement proposal.

[0088] The server 100 transmits a notification to the debtor terminal 200 that the settlement proposal has been sent to the creditor terminal 400. When the debtor terminal 200 receives the notification, it reflects the status on the status confirmation screen 260. As shown in Fig. 16, on the status confirmation screen 260, the lender display field 263a of the settlement status confirmation area 263 reflects the status of sending the settlement proposal for each lender.

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

[0090] When the debtor user confirms the notification of consent to the settlement proposal, the debtor user presses the negotiation result input button 263a2 on the status confirmation screen 260. When the negotiation result input button 263a2 is pressed, a negotiation result input screen 280 is displayed.

[0091] 17 is a diagram illustrating an example of a negotiation result input screen 280. As shown in FIG. 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 result of the settlement negotiation. The creditor user can select a button according to the result of the settlement negotiation. As an example, if the creditor user agrees with the contents of the settlement proposal, the debtor user presses the "Success" button. The negotiation completion button 282 is a button for the creditor user to confirm the negotiation result. When the negotiation completion 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 a contract or the like as necessary. When the settlement is concluded, as shown in FIG. 18, a status confirmation screen 260 displays a message indicating that the settlement with the lender has been completed.

[0094] (1.3.2. Flow of diagnostic result generation process) The flow of the diagnosis result generation process (S400) will be described with reference to FIG. 7. In step S510, the settlement condition acquisition module 112 of the server 100 acquires settlement conditions corresponding to the debt information acquired from the debtor user with reference to the settlement condition database 125. As an example, the settlement condition acquisition module 112 acquires repayment conditions corresponding to the debt data acquired from the debtor user from the settlement condition database 125. Specifically, for example, it acquires the subitem "Number of repayments" corresponding to the actual number of repayments in the debt data with reference to the item "Number of installments" in the settlement condition database 125.

[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 a prompt required for an inquiry to generate analysis contents to the external AI server 300. In generating the prompt, so-called RAG (Retrieval-Augmented Generation) may be used. For example, in the previous information retrieval step, information specified in the item "Notes" of the settlement conditions database 125 may be searched, and in the subsequent generation step, a prompt for generating analysis contents may be generated based on the information acquired by the search and the debt information received from the debtor. In this way, the external AI server 300 can generate analysis contents based on the information specified in the item "Notes" of the settlement conditions database 125.

[0096] In step S525, the server 100 sends the prompt to the external AI server 300. In step S610, the 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 transmits 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 diagnosis result based on the repayment plan and the analysis content. In this manner, the diagnosis result generation process (S400) is executed. When a correction to the settlement plan is received (S135), the settlement proposal generation module 113 may refer to the item "maximum number of times" in the settlement conditions database 125 so that the number of future repayments desired by the debtor user does not exceed the maximum number of times.

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

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

[0101] The ROM 92 stores a program for controlling the operation of the computer 90. The ROM 92 stores a program necessary for causing the computer 90 to realize each of the above-mentioned processes. The RAM 93 functions as a storage area in which the programs stored in the ROM 92 are expanded.

[0102] The storage 94 stores data necessary for executing a program and data obtained by executing a program. The storage 94 includes one or more selected from a hard disk drive (HDD) and a solid state drive (SSD). 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 an 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 and an output device 96a. The output interface 96 is, for example, a video output interface such as a Digital Visual Interface (DVI) or a High-Definition Multimedia Interface (HDMI (registered trademark)). The CPU 91 can transmit data to the output device 96a via the output interface 96 and cause the output device 96a to output the data.

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

[0106] The communication interface (I / F) 97 can connect the computer 90 to an external server 97a that is external to 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 executed by the server 100 may be realized by one computer 90 or by a plurality of computers 90 working together.

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

[0109] For example, information recorded on a recording medium can be read by a computer (or an embedded system). The recording medium may have any recording format (storage format). For example, the computer reads a program from the recording medium and causes a processor to execute instructions described in the program based on the program. In the computer, the program may be acquired (or read) through a network.

[0110] (1.5.Summary) As described above, the debt management system 1 in the present disclosure includes a server 100 having a control unit 110. The control unit 110 executes the steps of acquiring debt information related to the debt of the debtor, acquiring settlement condition information related to the conditions of settlement with the creditor of the debt, and generating a settlement proposal with the creditor based on the debt information and the settlement condition information. This configuration allows the debtor himself to carry out debt restructuring through a simple procedure.

[0111] In addition, the debt information may include loan information received from the debtor regarding the debt. By adopting such specifications, it becomes possible to smoothly guide the debtor to the debt restructuring procedure in response to an inquiry about debt restructuring from the debtor.

[0112] In addition, the settlement condition information includes information regarding points to note based on past settlement results. In this way, by generating a settlement proposal with a creditor based on points to note based on past settlement results, it is possible to increase the likelihood that the creditor will agree to the settlement proposal generated by the debt management system 1.

[0113] A debt repayment plan may be included in the settlement proposal generated by the debt management system 1. By adopting such specifications, settlement negotiations with creditors can be conducted based on a specific repayment plan.

[0114] The repayment plan may also include information on the repayment amount and number of repayments for each creditor. In this way, for a debtor who has borrowed from multiple creditors, a repayment plan for each creditor can be generated, making it possible to conduct settlement negotiations with each creditor in parallel.

[0115] The control unit 110 may also be configured to amend the settlement proposal based on a request from the user and present it to the user. By configuring in this way, the user as a debtor can flexibly amend the proposed settlement proposal, making it easier for the user to present to the creditor a repayment plan that the debtor is likely to be able to fulfill.

[0116] In addition, the control unit 110 presents the repayment plans for each of the multiple lenders to the user side by side. With this specification, the user as a debtor can compare the repayment plans for each of the multiple lenders and consider a response policy of whether or not to consolidate the debt for each lender.

[0117] The control unit 110 may also be configured to generate a settlement proposal for the creditor based on the generated settlement proposal. By using such specifications, the user as the debtor can save the trouble of generating a settlement proposal and can reduce the cost that may be incurred when requesting a professional to create the settlement proposal.

[0118] In addition, the control unit 110 transmits debt information to an expert based on a request from the user. With this specification, the user as a debtor can cooperate with an expert at a timing desired by the user, and the user can save the trouble of searching for an expert by himself.

[0119] The debt management system 1 further includes a storage unit 120 that stores settlement condition information, and the control unit 110 updates the settlement condition information in the storage unit 120 based on the track record of settlement between the creditor and the debtor. By updating the settlement condition information in the storage unit 120 based on the track record of settlement in this way, it is possible to increase the likelihood that the creditor will agree to a settlement proposal that will be generated in the future.

[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 the present disclosure is not limited to the above embodiment. For example, in the above embodiment, the external AI server 300 is used using RAG only for generating the analysis content in the diagnosis result generation process (S400), but the present invention is not limited to this aspect. For example, the external AI server 300 may also be used using RAG for generating the repayment plan.

[0121] Specifically, for example, in the previous information retrieval step, information stored in the "Notes" item of the settlement conditions database 125 may be retrieved, and in the subsequent generation step, a prompt may be generated for generating a repayment plan based on the information acquired in the search. 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 conditions database 125.

[0122] In addition, the server 100 may be configured to update the settlement condition database 125 based on the contents of the settlement after the settlement is concluded in step S160. Specifically, for example, the item "Notes" may be updated or added based on the contents of the settlement. By adopting such specifications, settlement conditions based on the settlement track record are accumulated in the settlement condition database 125, making it possible to generate more diverse settlement proposals that are more likely to conclude a settlement and present them to the creditor. In this way, by the debtor presenting a settlement proposal based on the settlement track record to the creditor, when the debtor himself conducts settlement negotiations without an agent, the creditor's motivation to turn away the debtor due to the absence of an agent is reduced, and debt consolidation by the debtor himself can be popularized.

[0123] In the above embodiment, the settlement conditions database 125 is managed by the server 10 in a centralized manner, but the present invention is not limited to this. Specifically, for example, the settlement conditions database 125 may be stored in the storage unit of the agent terminal 500 for each agent, and a debt consolidation service by the debt consolidation system may be provided for each agent. By adopting such specifications, the agent can update the settlement conditions based on his or her own track record and generate a settlement proposal, making it possible to present a more diverse and reliable settlement proposal to the creditor that is more in line with practical experience.

[0124] In the above embodiment, the server 100 and the creditor terminal 400 are configured to be able to communicate with each other, and the server 100 is configured to be able to transmit a settlement proposal or the like to the creditor terminal 400, but the present invention is not limited to this embodiment. For example, the server 100 may be configured to transmit a settlement proposal to the creditor using another communication device such as a fax machine.

[0125] The server 100 may also be linked to other debt management systems. For example, the server 100 may be linked to a remittance management system in which an agent such as a lawyer manages remittances from a debtor to a creditor. This specification further improves the convenience of debt management for the debtor.

[0126] Although some embodiments of the present disclosure have been illustrated above, these embodiments are presented as examples and are not intended to limit the scope of the invention. These new embodiments can be implemented in various other forms, and various omissions, substitutions, modifications, etc. can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are included in the scope of the invention and its equivalents described in the claims. In addition, the above-mentioned embodiments 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 condition 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 conditions 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: lender designation button, 233: analysis content display area, 234: income / expense status display area, 235: revision proposal selection button, 236: revision execution button, 237: debt consolidation start button, 240: history information request input screen, 241: request 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 content confirmation button, 250: history information request transmission screen, 251: history information request request confirmation area, 252: history information request send button, 260: status confirmation screen, 261: next action display area, 262: diagnosis result display area, 262a: diagnosis result confirmation button, 262b: correction button, 263: settlement status confirmation area, 263a: lender display field, 263a1: settlement proposal creation button, 263a2: negotiation result input button, 263c: lender addition button, 270: settlement proposal send screen, 271: settlement proposal confirmation area, 272: settlement proposal send button, 280: negotiation result input screen, 281: negotiation result input button, 282: negotiation completion button, 300: external AI server,400: Creditor terminal, 500: Agent terminal,

Claims

1. obtaining debt information relating to the debtor's debt; obtaining settlement terms information regarding the terms of a settlement with a creditor of the debt; A debt management system comprising a control unit that executes a step of generating a settlement proposal with the creditor based on the debt information and the settlement condition information.

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

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

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

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

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

7. The debt management system according to claim 1 , wherein the control unit presents repayment plans for each of a plurality of lenders to the user in a line.

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 a user.

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

11. Further comprising a storage unit for storing settlement condition information; The debt management system according to claim 1 , wherein the control unit updates the settlement condition information in the storage unit based on a track record of settlements between creditors and debtors.

12. A control unit is provided, obtaining debt information relating to the debtor's debt; obtaining settlement terms information regarding the terms of a settlement with a creditor of the debt; and generating a settlement proposal with the creditor based on the debt information and the settlement terms information.

13. An information processing device including a control unit, obtaining debt information relating to the debtor's debt; obtaining settlement terms information regarding the terms of a settlement with a creditor of the debt; generating a settlement proposal with the creditor based on the debt information and the settlement terms information.

14. An information processing device including a control unit, obtaining debt information relating to the debtor's debt; obtaining settlement terms information regarding the terms of a settlement with a creditor of the debt; An information processing method that executes a step of generating a settlement proposal with the creditor based on the debt information and the settlement terms information.

Images