Debt management device, debt management method, and program

Abstract

Previously, it was not possible to automatically determine which accounting information should be used to file a claim for receivables from the accounting information stored in the accounting management department. [Solution] A debt management device 5 comprises an accounting management unit 61 that stores one or more accounting information items having a billing identifier, billing amount, and date information, a determination unit 531 that determines accounting information that matches the claim conditions from the accounting management unit 61 that stores one or more accounting information items having a billing identifier, a billing amount, and date information, a claim acquisition unit 533 that uses the accounting information to acquire claim information having a creditor identifier, a debtor identifier, and claim details information, a claim storage unit 131 that stores the claim information in association with the claim identifier, an instruction receiving unit 124 that receives an instruction to output claim status information from a terminal, an information acquisition unit 139 that acquires part or all of the claim status information corresponding to the output instruction, and an information transmission unit 147 that transmits part or all of the claim status information to the terminal, thereby enabling the automatic determination of accounting information to be used to file a claim from the accounting information stored in the accounting management unit.

Description

Technical Field

[0001] The present invention relates to a claim management device for managing information related to claims and the like.

Background Art

[0002] Conventionally, there has been a system that enables a card issuer or other electronic payment provider to obtain a quick and desirable efficient solution to disputes between customers and affiliated stores (see Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the prior art, it has been impossible to automatically determine the accounting information for which a claim should be made from the accounting information stored in the accounting management department.

Means for Solving the Problems

[0005] The debt management device of the first invention comprises: a debt management unit that stores one or more debt status information corresponding to a debt identifier that identifies a debt, which can identify the current phase of one of two or more phases from the occurrence of a debt to the agreement between the creditor and the debtor regarding the processing of the debt; a determination unit that determines accounting information that matches the application conditions from an accounting management unit that stores one or more accounting information having a billing address identifier that identifies the billing address, a billing amount, and date information that identifies the date related to the billing; an application acquisition unit that uses the accounting information determined by the determination unit to acquire application information having a creditor identifier that identifies the creditor, a debtor identifier that identifies the debtor, and debt content information relating to the content of the debt; an application storage unit that stores the application information acquired by the application acquisition unit in the debt management unit, corresponding to the debt identifier; an instruction receiving unit that receives an instruction to output debt status information from a creditor terminal or debtor terminal; an information acquisition unit that acquires part or all of the debt status information corresponding to the output instruction from the debt management unit; and an information transmission unit that transmits part or all of the debt status information acquired by the information acquisition unit to a creditor terminal or debtor terminal.

[0006] This configuration allows the system to automatically determine which accounting information should be used to file a claim for receivables from the accounting information stored in the accounting management department.

[0007] Furthermore, the debt management device of the second invention further comprises a user management unit that stores two or more user information items having claim conditions associated with a creditor identifier, and a determination unit that determines accounting information that matches the claim conditions associated with a creditor identifier from one or more accounting information items corresponding to a creditor identifier.

[0008] With this configuration, the accounting information to which a claim should be filed can be automatically determined from the accounting information stored in the accounting management department, based on different conditions for each creditor.

[0009] Furthermore, the debt management device of this third invention is a debt management device that, in addition to the first or second invention, comprises a payment receiving unit that receives payment information indicating payment from a debtor for a debt, and a payment storage unit that, when the payment receiving unit receives payment information, stores payment-related information in the accounting management unit indicating that a payment corresponding to the payment information has been made.

[0010] With this configuration, when a debtor makes a payment for a receivable, information regarding that payment can be stored and managed in the accounting management department.

[0011] Furthermore, the debt management device of the fourth invention further comprises an access management unit that stores access information for accessing an accounting management device having an accounting management unit, with each of the first to third inventions associated with two or more creditor identifiers, and the determination unit is a debt management device that accesses the accounting management device using the access information associated with the creditor identifier and determines accounting information that matches the application conditions associated with the creditor identifier.

[0012] With this configuration, by accessing two or more accounting management devices, it is possible to automatically determine, from the accounting information stored in the accounting management devices, the accounting information to which a claim should be filed for two or more creditors.

[0013] Furthermore, the debt management device of the fifth invention further comprises, with respect to any one of the first to fourth inventions, an inquiry unit that inquires with the creditor corresponding to the accounting information determined by the decision unit whether or not to file a claim against the claimant; an answer receiving unit that receives a response from the creditor to the inquiry; and, when the answer receiving unit receives a response indicating that a claim will be filed, an application notification unit that acquires notification information including creditor information identified by the creditor identifier in the application information and debt content information, and transmits the notification information to the debtor.

[0014] With this configuration, the accounting information that should be used to file a claim can be automatically selected from the accounting information stored in the accounting management department, and then the creditor can decide whether or not to file a claim.

[0015] Furthermore, the debt management device of the sixth invention, in contrast to the fifth invention, has an inquiry unit that determines whether or not to inquire with the claimant whether or not to file a claim, and only if it determines that an inquiry should be made, it inquires with the claimant whether or not to file a claim.

[0016] With this configuration, inquiries can only be made to the creditor regarding whether or not to file a claim, and only when necessary.

[0017] Furthermore, the debt management device of the seventh invention stores inquiry conditions associated with a creditor identifier, and the inquiry unit retrieves the inquiry conditions associated with the creditor identifier, determines whether the inquiry conditions are met, and only if it determines that the inquiry conditions are met, it inquires with the claimant whether or not to file a claim.

[0018] This configuration allows for inquiries to be made to creditors, under different conditions, regarding whether or not to file a claim with them.

[0019] Furthermore, the debt management device of the eighth invention is a debt management device that, in addition to any one of the first to seventh inventions, further comprises a confirmation receiving unit that receives confirmation information relating to the confirmation of a claim from the debtor's debtor terminal, and a confirmation storage unit that, in response to the confirmation receiving unit receiving the confirmation information, acquires the stored confirmation information and stores it in the debt management unit in association with a debt identifier.

[0020] This configuration allows for the management of the status of a debt in two or more phases out of two or more phases from the creation of the debt to its processing, and provides a platform to facilitate debt processing.

[0021] Further, the claim management apparatus of the ninth invention, with respect to the eighth invention, after the confirmation receiving unit receives the confirmation information, further includes a negotiation receiving unit that receives negotiation information for extinguishing the claim from the creditor's creditor terminal and the debtor's debtor terminal, and a negotiation storage unit that stores the negotiation information received by the negotiation receiving unit in association with a creditor identifier for identifying the creditor or a debtor identifier for identifying the debtor, and a claim identifier in the claim management unit.

[0022] With such a configuration, it is possible to manage the status of the claim in two or more phases from the generation of the claim to the processing of the claim, and to provide a platform for promoting the processing of the claim.

[0023] Further, the claim management apparatus of the tenth invention, with respect to any one of the first to ninth inventions, further includes an account generation unit that generates a virtual account of a bank in association with a claim identifier and acquires account information for specifying the virtual account, an account storage unit that stores the account information acquired by the account generation unit in the claim management unit in association with the claim identifier, and an account transmission unit that transmits the account information to the debtor.

[0024] With such a configuration, it is possible to automatically provide a bank account for claim collection.

[0025] Further, the claim management apparatus of the eleventh invention, with respect to the tenth invention, further includes a determination unit that determines whether or not information received from the creditor terminal or the debtor terminal matches an account condition that is a condition for acquiring account information, and the account generation unit acquires account information for specifying the virtual account when the determination unit determines that the account condition is met.

[0026] With such a configuration, it is possible to automatically provide a bank account only when the account condition is met.

[0027] In addition, the claim management device of the twelfth invention, for the ninth invention, when the negotiation information received by the negotiation reception unit meets the proposed content creation conditions, obtains the creditor's information and the debtor's information from the claim management unit, and is information including the creditor's information and the debtor's information, information including the content of the negotiation information, and information indicating a proposal regarding the claim processing. It is a claim management device further comprising a proposed content acquisition unit that acquires the proposed content, and a proposed content transmission unit that transmits the proposed content acquired by the proposed content acquisition unit to the creditor terminal or the debtor terminal.

[0028] With such a configuration, the proposed content regarding the claim processing according to the negotiation information can be automatically configured.

[0029] In addition, the claim management device of the thirteenth invention, for the twelfth invention, the proposed content transmission unit is a claim management device that transmits the proposed content so that the negotiation information received by the negotiation reception unit and the proposed content acquired by the proposed content acquisition unit are associated with each other.

[0030] With such a configuration, the negotiation information and the proposed content can be appropriately presented.

[0031] In addition, the claim management device of the fourteenth invention, for the twelfth or thirteenth invention, after the confirmation reception unit receives the confirmation information, it further comprises a screen transmission unit that transmits screen information for allowing the debtor to select one of two or more methods of claim processing to the debtor terminal. The negotiation reception unit receives negotiation information including a claim processing identifier for identifying one of two or more methods of claim processing from the debtor terminal, and the proposed content acquisition unit acquires the creditor's information and the debtor's information from the claim management unit, and is information including the creditor's information and the debtor's information, and a claim management device that acquires the proposed content corresponding to the claim processing identifier.

[0032] With such a configuration, the proposed content regarding the claim processing according to the negotiation information and the proposed content including the claim processing identifier selected by the debtor can be automatically configured.

[0033] Furthermore, the debt management device of the fifteenth invention is a debt management device that, in addition to the fourteenth invention, further comprises a mediation support unit that performs mediation support processing to assist a group including the creditor and the debtor in conducting mediation online when the negotiation receiving unit receives negotiation information including a debt processing identifier indicating online mediation from the debtor terminal.

[0034] This configuration can support online mediation for debts.

[0035] Furthermore, the debt management device of the sixteenth invention is a debt management device that, in addition to the nineth invention, further comprises a determination unit that determines whether or not the agreement conditions have been met using the negotiation information received by the negotiation receiving unit, and a necessary information transmission unit that transmits necessary information to the debtor, which is information necessary for the debtor to process the debt.

[0036] With this configuration, if negotiations for debt settlement are successful, the debtor can be presented with the information necessary for debt settlement.

[0037] Furthermore, the debt management device of the seventeenth invention is a debt management device that, in addition to any one of the nineteenth to sixteenth inventions, further comprises a negotiation information output unit that outputs two or more negotiation information received by the negotiation receiving unit in the order in which the negotiation receiving unit received them, and in a manner that allows it to determine whether the identifier to which the negotiation information is associated is a creditor identifier or a debtor identifier.

[0038] This configuration allows for the management of the status of a debt in two or more phases out of two or more phases from the creation of the debt to its processing, and provides a platform that facilitates the processing of debts.

[0039] Furthermore, the debt management device of the eighteenth invention is a debt management device that, in addition to any one of the nineteenth to seventeenth inventions, further comprises an agreement document generation unit that generates an agreement document using negotiation information when the negotiation information received by the negotiation receiving unit satisfies the agreement conditions, and an agreement document output unit that outputs the agreement document generated by the agreement document generation unit.

[0040] With this configuration, when an agreement is reached in negotiations regarding debt settlement, an agreement document can be automatically generated.

[0041] Furthermore, the debt management device of the nineteenth invention is a debt management device that, in addition to any one of the first to eighteenth inventions, has phase identification information that can identify the current phase among two or more phases from the creation of a debt to the processing of the debt, and further comprises an update unit that updates the phase identification information associated with a debt identifier in response to the notification unit sending notification information to the debtor and the confirmation receiving unit receiving confirmation information.

[0042] This configuration allows for the management of the status of a debt in two or more phases out of two or more phases from the creation of the debt to its processing, and provides a platform to facilitate debt processing. [Effects of the Invention]

[0043] According to the debt management device of the present invention, the accounting information to which a debt claim should be filed can be automatically determined from the accounting information stored in the accounting management unit. [Brief explanation of the drawing]

[0044] [Figure 1] Conceptual diagram of information system A in Embodiment 1 [Figure 2] Block diagram of information system A [Figure 3] Block diagram of the debt management device 1 [Figure 4] Flowchart illustrating an example of operation of the debt management device 1. [Figure 5] Flowchart illustrating an example of operation of the debt management device 1. [Figure 6] A flowchart illustrating an example of the configuration process for this notification information. [Figure 7] A flowchart illustrating an example of the proposed content structure processing. [Figure 8] A flowchart illustrating an example of the agreement document generation process. [Figure 9] A flowchart illustrating an example of the output information configuration process. [Figure 10] A flowchart illustrating an example of operation for the creditor's terminal 2. [Figure 11] A flowchart illustrating an example of the operation of the debtor's terminal 3. [Figure 12] This diagram shows an example of the flow of phases following the filing of the claim. [Figure 13] A diagram showing an example of the creditor management table. [Figure 14] A diagram showing an example of the debt management table. [Figure 15] A diagram showing an example of the proposed content template. [Figure 16] A diagram showing an example of the agreement document template. [Figure 17] A diagram showing an example of the case registration screen. [Figure 18] A diagram showing an example of the notification information. [Figure 19] A diagram showing an example of the confirmation screen. [Figure 20] A diagram showing an example of the decision screen. [Figure 21] A diagram showing an example of the notification information. [Figure 22] A diagram showing an example of the same output screen. [Figure 23] A diagram showing an example of the screen for changing the installment amount. [Figure 24] Figure showing an example of the same output screen. [Figure 25] A diagram showing an example of the same output screen. [Figure 26] This figure shows an example of the output of the payment schedule. [Figure 27] A diagram showing an example of the same output screen. [Figure 28] A diagram showing an example of the same output screen. [Figure 29] Block diagram of the debt management device 4 in Embodiment 2 [Figure 30] Flowchart illustrating an example of operation of the debt management device 4. [Figure 31]A flowchart illustrating an example of the account acquisition process. [Figure 32] A diagram showing an example of the debt management table. [Figure 33] Conceptual diagram of information system C in Embodiment 3 [Figure 34] Block diagram of the same information system C [Figure 35] Block diagram of the debt management device 5 [Figure 36] A flowchart illustrating an example of the operation of the debt management device 5. [Figure 37] A flowchart illustrating an example of the operation of the debt management device 5. [Figure 38] A flowchart illustrating an example of the operation of the debt management device 5. [Figure 39] A flowchart illustrating an example of the same decision-making process. [Figure 40] A diagram showing an example of the user management table. [Figure 41] A diagram showing an example of the access control table. [Figure 42] A diagram showing an example of the same inquiry information. [Figure 43] Block diagram of the computer system in the above embodiment [Modes for carrying out the invention]

[0045] The embodiments of the debt management device, etc., will be described below with reference to the drawings. In the embodiments, components that are denoted by the same reference numerals perform the same operation, and therefore, further explanation may be omitted.

[0046] (Embodiment 1) In this embodiment, a debt management device that stores debt status information in conjunction with a unique debt identifier will be described.

[0047] In this embodiment, a debt management device is described that uses the application information transmitted by the creditor to construct notification information to be sent to the debtor, and transmits said notification information to the debtor's contact information.

[0048] This embodiment describes a debt management device that accepts access from debtors based on notification information, receives confirmation information regarding debt claims from debtors, stores such confirmation information, and then stores negotiation information between creditors and debtors in association with debt identifiers.

[0049] In this embodiment, a debt management device is described that acquires proposal content based on negotiation information from creditors or debtors, and stores the proposal content in association with the negotiation information.

[0050] In this embodiment, a debt management device that displays a screen with two or more options during the negotiation process between a creditor and a debtor will be described.

[0051] In this embodiment, we will describe a debt management device that performs processing to support online mediation when both the creditor and the debtor agree.

[0052] This embodiment describes a debt management device that determines whether the agreement conditions are met and, if the agreement conditions are met, transmits information necessary for debt processing to the debtor.

[0053] In this embodiment, we describe a debt management device that outputs negotiation information in chronological order, and in a manner that allows for the identification of whether the negotiation information was entered by the creditor or the debtor.

[0054] In this embodiment, a debt management device that generates and outputs an agreement document using debt status information will be described.

[0055] In this specification, information X being associated with information Y means that information Y can be obtained from information X, or information X can be obtained from information Y, and the method of association is irrelevant. Information X and information Y may be linked, may reside in the same buffer, may information X be contained in information Y, or information Y may be contained in information X, and so on.

[0056] Furthermore, in this specification, selecting or determining information Z means obtaining information Z, obtaining a pointer to information Z, obtaining the ID of information Z, setting a flag on information Z, etc., and it is sufficient to be able to access information Z.

[0057] Figure 1 is a conceptual diagram of information system A in this embodiment. Information system A comprises a debt management device 1, one or more creditor terminals 2, and one or more debtor terminals 3.

[0058] Debt management device 1 is a server for managing information related to debts. Debt management device 1 may manage information related to two or more debts, including debts in which one user is the creditor and debts in which that same user is the debtor. Debt management device 1 may be, for example, a cloud server or an ASP server, but its type is not limited.

[0059] Creditor terminal 2 is a terminal used by the creditor. Debtor terminal 3 is a terminal used by the debtor. Creditor terminal 2 and debtor terminal 3 can be, for example, a personal computer, smartphone, or tablet device, but the type is not limited.

[0060] Figure 2 is a block diagram of information system A in this embodiment. Figure 3 is a block diagram of debt management device 1.

[0061] The debt management device 1 comprises a storage unit 11, a receiving unit 12, a processing unit 13, and a transmitting unit 14. The storage unit 11 includes a debt management unit 111. However, the storage unit 11 does not necessarily have to have a debt management unit 111. In other words, the debt management unit 111 may reside in an external device not shown.

[0062] The receiving unit 12 includes a petition acquisition unit 121, a confirmation receiving unit 122, a negotiation receiving unit 123, and an instruction receiving unit 124. The processing unit 13 includes a petition storage unit 131, an update unit 132, a confirmation storage unit 133, a negotiation storage unit 134, a proposal content acquisition unit 135, a mediation support unit 136, a judgment unit 137, an agreement document generation unit 138, and an information acquisition unit 139. The transmitting unit 14 includes a petition notification unit 141, a screen transmission unit 142, a proposal content transmission unit 143, a negotiation information output unit 144, a necessary information transmission unit 145, an agreement document output unit 146, and an information transmission unit 147.

[0063] The creditor terminal 2 includes a creditor storage unit 21, a creditor reception unit 22, a creditor processing unit 23, a creditor transmission unit 24, a creditor reception unit 25, and a creditor output unit 26.

[0064] The debtor terminal 3 comprises a debtor storage unit 31, a debtor reception unit 32, a debtor processing unit 33, a debtor transmission unit 34, a debtor reception unit 35, and a debtor output unit 36.

[0065] The storage unit 11, which constitutes the debt management device 1, stores various types of information. These types of information include, for example, debt status information, various screen information, various conditions, various templates, and lawyer information, which will be described later.

[0066] Screen information refers to the information used to construct a screen. Screen information can be written in HTML, XML, etc., but the method of implementation is not limited. Screen information is associated with, for example, selection objects within other screen information. A selection object is an object that can be selected. Examples of selection objects include buttons, menu items, or checkboxes.

[0067] These various conditions include, for example, the conditions for creating the proposal content and the conditions for agreement, which will be described later. These conditions may also be embedded within the program.

[0068] The various templates include, for example, notification information templates, proposal content templates, and agreement document templates. A notification information template is a template document for structuring notification information, as described later, and is a document with variables. A proposal content template is a template document for structuring proposal content, and is a document with variables. An agreement document template is a template document for structuring an agreement document, and is a document with variables.

[0069] Lawyer information refers to information about lawyers who support online mediation. Lawyer information includes a lawyer identifier and lawyer contact information. The lawyer identifier is information that identifies the lawyer. For example, the lawyer identifier may be the lawyer's name, lawyer's registration number, or lawyer's ID. The lawyer contact information is information that indicates how to contact the lawyer. For example, the lawyer's contact information may be the lawyer's email address, lawyer's phone number, or the ID the lawyer uses to log in to debt management device 1.

[0070] The Debt Management Unit 111 stores one or more debt status information. Debt status information refers to information about a debt. Debt status information is information that identifies the current phase of two or more phases from the creation of the debt to agreement. Debt status information may also be information that identifies the current phase of two or more phases from the filing of the claim to agreement. The agreement here is an agreement between the creditor and the debtor regarding the handling of the debt. A debt is a right of a creditor to demand a certain action from the debtor. The certain action here is usually the payment of money, but it may also be the delivery of goods, the provision of services, etc., and the action demanded by the debt is not limited. In other words, the type of debt handled here is preferably a monetary debt, but it is not limited to real debts, act debts, etc. The phase here refers to a specific state or period in the progress of handling the debt from the creation of the debt to agreement or breakdown, etc. A phase may also be called a step, stage, situation, etc.

[0071] Debt status information can be defined as information related to debt processing. For example, debt status information is information used to manage the status of debts. Debt status information is information associated with a debt identifier. A debt identifier is information that identifies a debt. Examples of debt identifiers include the debt ID and the debt name (for example, the name of the application). Debt status information includes, for example, creditor information, debtor information, debt details, confirmation information, negotiation information, proposed details, agreement documents, phase identification information, and various time-related information.

[0072] Creditor information refers to information about a creditor. Creditor information includes, for example, a creditor identifier and one or more creditor attribute values. A creditor identifier is information that identifies a creditor. Examples of creditor identifiers include the creditor's ID, name, phone number, email address, and IP address of creditor terminal 2. Creditor attribute values ​​include, for example, the creditor's payment destination information, the creditor's company name, the name of the representative of the company that is the creditor, and the creditor type indicating whether the creditor is a corporation or an individual. Payment destination information is information that debtors use to make payments to creditors. Examples of payment destination information include bank account information, credit card information, and online payment information. Bank account information is information about a bank account necessary for bank transfers, and includes, for example, the bank name, branch name, and bank account number. Credit card information is information necessary for making payments using a credit card, and includes, for example, the credit card number and expiration date. Online payment information is information necessary for making payments using online payment, and includes, for example, an ID for online payment. Note that bank account information may also be referred to as account information as appropriate.

[0073] Debtor information refers to information about a debtor. Debtor information includes, for example, a debtor identifier and one or more debtor attribute values. The debtor identifier is information that identifies the debtor. Examples of debtor identifiers include the debtor's ID, debtor's name, debtor's phone number, debtor's email address, and the IP address of debtor terminal 3. Debtor attribute values ​​include, for example, the debtor's contact information, the debtor's company name, the name of the representative of the company that is the debtor, the debtor's address, and the debtor type indicating whether the debtor is a corporation or an individual. Examples of contact information include an email address, phone number, and SNS (e.g., Line®, Slack®) ID.

[0074] Debt information refers to information that identifies the content of a debt. For example, debt information may include the name of the debt claim, the amount claimed, and the original payment due date. If the debt is a right to demand the return of borrowed items, the debt information may include, for example, information about the items to be returned and information identifying the return address.

[0075] Confirmation information is information indicating that the debtor has confirmed the creditor's claim. Debtor confirmation means that the debtor acknowledges that the claim is theirs. Confirmation information is, for example, a flag, but it may be replaced by the claim status information containing information that should be stored after the confirmation phase (for example, negotiation information). Confirmation information is, for example, confirmation time information. Confirmation time information is information that identifies when the debtor confirmed the claim. Confirmation time information is, for example, the date and time the information was received from debtor terminal 3. The time information that identifies the time may be just the date, or the date and time, etc. The granularity of the time information is not specified. Confirmation information only needs to be information that allows us to understand that the debtor has confirmed the claim.

[0076] Negotiation information refers to information relating to negotiations between a creditor and a debtor regarding the settlement of a claim. Negotiation information can be said to be information that identifies the content of the negotiations between the creditor and the debtor regarding the settlement of a claim. The information that identifies the content of the negotiation is the content of the negotiation. Negotiation information may also include an inputter identifier. An inputter identifier is information that identifies the person who proposed the content of the negotiation. An inputter identifier may, for example, be information indicating the creditor or information indicating the debtor.

[0077] The negotiations here are for the purpose of settling a debt. The negotiations are between the creditor and the debtor until an agreement is reached regarding the settlement of the debt. Negotiation information includes, for example, a debt settlement identifier. A debt settlement identifier is information that identifies the method for settling a debt. Examples of debt settlement identifiers include an ID and a name for the debt settlement (e.g., "Pay now by credit card," "Pay in full by the end of next month," "Pay in installments at the end of each month," "Proposal to revise the amount," "I don't recognize the claim," "Already paid directly," "Request online mediation"). Debt settlement identifiers also include, for example, a payment method identifier that identifies the means of payment (e.g., "credit card," "bank transfer," etc.).

[0078] The proposed content is a document that describes the matters agreed upon by both parties when processing a debt identified by a debt processing identifier. It can be said that the proposed content is information that indicates a proposal regarding the processing of a debt. The proposed content includes information about the creditor (e.g., the name of the creditor) and the debtor (e.g., the name of the debtor), as well as information about the negotiations (e.g., the monthly payment amount in installments).

[0079] An agreement document is a document created when negotiations regarding the settlement of a debt reach an agreement, and it contains the details of the negotiations. For example, the agreement document may include information about the creditor (e.g., the creditor's name), information about the debtor (e.g., the debtor's name), the method of payment by the debtor to the creditor, and the amount to be paid. The agreement document may also be identical to the final proposal made during the negotiations.

[0080] Phase identification information refers to information that identifies the current phase among two or more phases from the creation of a claim until the creditor and debtor agree on the settlement of the claim. The phases that can be identified by phase identification information do not have to be all of the two or more phases from the creation of a claim until the creditor and debtor agree on the settlement of the claim. Phase identification information is, for example, a phase identifier, but does not have to be explicitly present in the claim status information. Phase identification information only needs to be information that allows the phase to be determined from the claim status information. Phase identification information may be information that can be determined from information that the claim status information has or does not have. For example, if the claim status information has information at the time of application and at confirmation, but does not have negotiation information, the current phase can be determined to be the "negotiation" phase. In such a case, the phase identification information is a phase identifier determined from the time of application and at confirmation, or from the time of application and at confirmation and negotiation information that does not exist.

[0081] The two or more phases from the creation of a claim until the creditor and debtor agree on how to handle the claim are, for example, "claim filed," "awaiting confirmation," "confirmed," "negotiating," and "agreement reached." The "claim filed" phase is when the creditor files a claim against the debtor. The "awaiting confirmation" phase is when the creditor is waiting for confirmation from the debtor regarding the claim filed. Note that the "awaiting confirmation" phase may be the same as the "claim filed" phase. The "confirmed" phase is when the debtor has confirmed the claimed claim. The "negotiating" phase is when the creditor and debtor are negotiating how to handle the claim. The "agreement reached" phase is when negotiations for the handling of the claim have reached an agreement. Note that the two or more phases from the creation of a claim until the creditor and debtor agree on how to handle the claim do not necessarily have to include the "claim creation" phase and the "agreement" phase.

[0082] Furthermore, the phases handled by the debt management device 1 may include the phase after the agreement has been reached in negotiations. Such phases may be, for example, "Debt Processing in Progress" and "Debt Processing Completed." The "Debt Processing in Progress" phase is the phase after the agreement has been reached in negotiations and the debt is being processed (for example, in payment). The "Debt Processing Completed" phase is the phase when the debt processing has been completed. Ideally, the phases handled by the debt management device 1 should be "Application Filed," "Awaiting Confirmation," "Confirmed," "Negotiating," "Agreement Reached," "Debt Processing in Progress," and "Debt Processing Completed," but it may also be a selection of these phases. In addition, the phases handled by the debt management device 1 do not necessarily have to include all phases from the creation of the debt until the creditor and debtor agree on the processing of the debt.

[0083] Furthermore, various types of time information include, for example, application information, confirmation information, negotiation information, agreement information, and debt processing completion information. Application information is information indicating when a claim was filed. For example, application information is information indicating when the application acquisition unit 121 received the application information. Negotiation information is information indicating when negotiations took place. For example, negotiation information is information indicating when the negotiation receiving unit 123 received the negotiation information. Agreement information is information indicating when an agreement was reached. For example, agreement information is information indicating when the judgment unit 137 determined that the agreement conditions described later had been met. Debt processing completion information is information indicating when the processing of the claim was completed.

[0084] The receiving unit 12 receives various information and instructions from the creditor terminal 2 or the debtor terminal 3. These various information and instructions include, for example, case registration, application information, confirmation information, negotiation information, output instructions, proposal content instructions, agreement document instructions, payment schedule instructions, or payment information.

[0085] Payment information is information that identifies that a payment has been made by a debtor. Payment information is associated with a debt identifier. For example, payment information includes the payment amount.

[0086] The application acquisition unit 121 acquires application information. For example, the application acquisition unit 121 receives application information from the creditor terminal 2. For example, the application acquisition unit 121 receives a case registration containing application information from the creditor terminal 2. The application acquisition unit 121 may also read application information from the storage unit 11 or an external device (not shown). The method by which the application acquisition unit 121 acquires application information is not limited.

[0087] Application information refers to information about the claim being filed. It can also be considered to include information about claims that may be filed in the future, and the term "application information" is interpreted broadly. Application information includes a creditor identifier to identify the creditor, a debtor identifier to identify the debtor, and information about the claim. Application information may also include creditor information with a creditor identifier and debtor information with a debtor identifier. Case registration is an instruction to register a case that is the subject of a claim application.

[0088] The application acquisition unit 121 may, for example, acquire application time information from a clock (not shown), and constitute application information that includes said application time information and received application information, and which is stored information.

[0089] The confirmation receiving unit 122 receives confirmation information regarding the confirmation of the claim from the debtor's terminal 3. The confirmation receiving unit 122 usually receives confirmation information from the debtor's terminal 3 in response to the notification information described later being sent to the debtor. The confirmation information is usually information indicating that the debtor has acknowledged the existence of the claim. The confirmation information received by the confirmation receiving unit 122 is usually associated with a claim identifier. The confirmation information received by the confirmation receiving unit 122 is usually associated with a claim identifier. For example, the confirmation information received by the confirmation receiving unit 122 is a flag indicating that the claim has been confirmed, or a debtor identifier.

[0090] The confirmation receiving unit 122 may receive non-existence information. Non-existence information is information that indicates the debtor's claim that the claim does not exist.

[0091] The negotiation receiving unit 123 receives negotiation information from the creditor's terminal 2 and the debtor's terminal 3 after the confirmation receiving unit 122 has received confirmation information. The negotiation receiving unit 123 usually receives negotiation information alternately from the creditor's terminal 2 and the debtor's terminal 3. The negotiation is usually for the extinguishment of the debt. The extinguishment of the debt can also be called the processing of the debt. The negotiation information received by the negotiation receiving unit 123 is usually associated with a debt identifier. The negotiation information received by the negotiation receiving unit 123 is usually associated with the creditor identifier of the creditor who sent the negotiation information or the debtor identifier of the debtor who sent the negotiation information.

[0092] The negotiation receiving unit 123 receives negotiation information from the debtor terminal 3, for example, which includes a debt processing identifier that identifies one of two or more methods of debt processing. The negotiation receiving unit 123 also receives negotiation information from the creditor terminal 2 or debtor terminal 3, which is a proposal from the creditor that includes, for example, the starting month for installment payments for debt processing and the payment amount for each month.

[0093] The negotiation receiving unit 123 receives negotiation information, for example, from the creditor terminal 2 or the debtor terminal 3, including proposals regarding revisions to the payment amount.

[0094] The negotiation receiving unit 123 receives negotiation information from the debtor terminal 3, including, for example, "information indicating that the debtor has no recollection of the claim" and "information indicating that the debtor has already made a direct payment."

[0095] The negotiation receiving unit 123 receives negotiation information, including, for example, "information indicating a desire for online mediation," from the creditor terminal 2 or the debtor terminal 3.

[0096] The instruction receiving unit 124 receives various instructions from the creditor terminal 2 or the debtor terminal 3. These instructions include, for example, output instructions, proposal content instructions, agreement document instructions, or payment schedule instructions.

[0097] An output instruction is an instruction for outputting debt status information from the debt management unit 111. An output instruction is associated with a debt identifier. For example, an output instruction may have a debt identifier. An instruction for outputting debt status information can be considered to include an instruction for outputting only a portion of the debt status information.

[0098] Proposal content instructions refer to instructions for outputting the proposal content. Agreement document instructions refer to instructions for outputting the agreement document. Payment schedule instructions refer to instructions for outputting the payment schedule.

[0099] The processing unit 13 performs various processes. These processes include, for example, those performed by the application storage unit 131, the update unit 132, the confirmation storage unit 133, the negotiation storage unit 134, the proposal content acquisition unit 135, the mediation support unit 136, the judgment unit 137, the agreement document generation unit 138, and the information acquisition unit 139.

[0100] The processing unit 13 associates the received payment information with a debt identifier and stores it in the debt management unit 111.

[0101] Processing unit 13 acquires information corresponding to the received instructions. Processing unit 13 acquires the proposed content from the accounts receivable management unit 111 according to the received instructions for proposed content. Processing unit 13 acquires the agreement document from the accounts receivable management unit 111 according to the received instructions for agreement document. Processing unit 13 acquires the payment schedule from the accounts receivable management unit 111 according to the received instructions for payment schedule.

[0102] The petition storage unit 131 stores the petition information acquired by the petition acquisition unit 121 in the debt management unit 111, associating it with the debt identifier. The stored petition information constitutes the debt status information of the debt management unit 111.

[0103] For example, when the information acquisition unit 139 receives application information from the creditor terminal 2, the application storage unit 131 generates a unique claim identifier and stores the application information in the claim management unit 111 in association with the said claim identifier. The method for generating the unique claim identifier is not limited. For example, the application storage unit 131 obtains a unique numerical value by adding 1 to the most recently generated claim identifier.

[0104] The update unit 132 updates the phase identification information associated with the debt identifier in response to the notification unit 141 sending notification information to the debtor. The update unit 132 usually stores information in the debt management unit 111 indicating that the current phase is phase "awaiting confirmation". The update unit 132 may store the notification information in the debt management unit 111 associated with the debt identifier, or it may store a flag indicating that the notification information has been sent in the debt management unit 111 associated with the debt identifier. The update unit 132 only needs to perform processing to identify that the phase has advanced as a result of the notification information being sent. Such processing may be replaced by the processing in which the application storage unit 131 stores application information. For example, the update unit 132 updates the phase identification information to phase identification information indicating that the current phase is phase "awaiting confirmation".

[0105] The update unit 132 updates the phase identification information associated with the debt identifier in response to the confirmation receiving unit 122 receiving confirmation information. Here, for example, the update unit 132 stores information in the debt management unit 111 indicating that the current phase is phase "negotiating". The update unit 132 may store the confirmation information in the debt management unit 111 associated with the debt identifier, or it may store a flag indicating that confirmation information has been received in the debt management unit 111 associated with the debt identifier. The update unit 132 only needs to perform processing to identify that the phase has advanced due to the receipt of confirmation information. Such processing may be replaced by the processing in which the confirmation storage unit 133 stores the confirmation information. The update unit 132 updates the phase identification information to phase identification information indicating that the current phase is phase "negotiating".

[0106] The confirmation storage unit 133 acquires confirmation information to be stored in response to the confirmation receiving unit 122 receiving confirmation information, associates the confirmation information with a debt identifier, and stores it in the debt management unit 111. For example, the confirmation storage unit 133 acquires confirmation time information, which is time information, from a clock (not shown), and stores the confirmation information including the confirmation time information in the debt management unit 111, associating it with a debt identifier. Note that the confirmation information to be stored may also be confirmation time information. In other words, the confirmation information received and the confirmation information to be stored may be different information. The confirmation information only needs to be information that allows the debtor to determine that they have confirmed the application for the debt.

[0107] The negotiation storage unit 134 stores the negotiation information received by the negotiation receiving unit 123 in the debt management unit 111, associating it with a creditor identifier that identifies the creditor who sent the negotiation information, a debtor identifier that identifies the debtor who sent the negotiation information, and a debt identifier.

[0108] The negotiation storage unit 134 may, when the negotiation receiving unit 123 receives negotiation information, acquire negotiation time information from a clock (not shown) and store negotiation information including said negotiation time information. The negotiation storage unit 134 may, when the negotiation receiving unit 123 receives negotiation information, acquire an inputter identifier that identifies whether the person who sent the negotiation information is a creditor or a debtor, and store negotiation information including said inputter identifier.

[0109] The proposal content acquisition unit 135 acquires the proposal content using the negotiation information received by the negotiation receiving unit 123 when the negotiation information matches the conditions for creating the proposal content. It is preferable for the proposal content acquisition unit 135 to acquire the proposal content using the debt status information.

[0110] The conditions for creating a proposal are the conditions for creating a proposal. For example, the conditions for creating a proposal are that the negotiation information includes a debt processing identifier that indicates a specific method from two or more methods of debt processing (that a specific debt processing identifier has been selected). A specific debt processing identifier is, for example, from the debt processing identifiers "Pay now by credit card," "Pay in full by the end of next month," "Pay in installments at the end of each month," "Proposal to revise the amount," "I don't recognize the claim," "Already paid directly," and "Want online mediation," the debt processing identifier is "Pay now by credit card," "Pay in full by the end of next month," "Pay in installments at the end of each month," or "Proposal to revise the amount." For example, the conditions for creating a proposal are that the negotiation information includes the installment amount. For example, the conditions for creating a proposal are that the received negotiation information includes information that has not been included in any previously received negotiation information.

[0111] The proposal content acquisition unit 135 acquires creditor information and debtor information from the debt management unit 111, and acquires proposal content, which is information that includes said creditor information and said debtor information and indicates a proposal corresponding to one method of debt processing.

[0112] The proposal content acquisition unit 135 constructs the proposal content by, for example, substituting creditor information and debtor information into proposal content templates paired with one or more debt processing identifiers. The proposal content acquisition unit 135 constructs the proposal content by, for example, substituting creditor information (e.g., creditor name), debtor information (e.g., debtor name), and some or all of the negotiation information (e.g., payment amount) into proposal content templates paired with one or more debt processing identifiers.

[0113] When the negotiation receiving unit 123 receives negotiation information from the debtor terminal 3, including a debt processing identifier that identifies a method corresponding to online mediation, the mediation support unit 136 performs mediation support processing.

[0114] Mediation support processing is a process designed to assist a group, including creditors and debtors, in conducting mediation online. The group preferably includes lawyers. Mediation support processing involves, for example, sending meeting information for the online meeting to each member of the group. The meeting information includes, for example, a URL to start the online meeting. The meeting information also includes, for example, the start date and time of the online meeting. The online meeting may be conducted using, for example, Zoom® or Webex®.

[0115] The determination unit 137 uses the negotiation information received by the negotiation receiving unit 123 to determine whether or not the agreement conditions have been met.

[0116] A condition for agreement is the condition used to determine that negotiations regarding debt settlement have been concluded. A condition for agreement is, for example, that the received negotiation information includes a debt settlement identifier indicating a specific method from two or more methods of debt settlement (that a specific debt settlement identifier has been selected). A specific debt settlement identifier is, for example, from the debt settlement identifiers "Pay now by credit card," "Pay in full by the end of next month," "Pay in installments at the end of each month," "Proposal to revise the amount," "I don't recognize the claim," "Already paid directly," and "Want online mediation," the debt settlement identifiers are "Pay now by credit card" and "Pay in full by the end of next month." A condition for agreement is, for example, that the received negotiation information includes a payment method identifier. A condition for agreement is, for example, that negotiation information indicating that the debtor has agreed to the negotiation information sent by the creditor has been received. A condition for agreement is, for example, that negotiation information indicating that the creditor has agreed to the negotiation information sent by the debtor has been received.

[0117] The agreement document generation unit 138 generates an agreement document using one or more pieces of negotiation information when the negotiation information received by the negotiation receiving unit 123 satisfies the agreement conditions. It is preferable for the agreement document generation unit 138 to store the generated agreement document in the debt management unit 111, paired with a debt identifier.

[0118] The agreement document generation unit 138 generates an agreement document by, for example, substituting the creditor's information, the debtor's information, and information contained in one or more negotiation documents into the agreement document template in the storage unit 11.

[0119] The information acquisition unit 139 acquires some or all of the debt status information corresponding to the output instruction from the debt management unit 111. For example, the information acquisition unit 139 acquires some or all of the debt status information that is paired with the debt identifier in the output instruction from the debt management unit 111.

[0120] The transmission unit 14 transmits various types of information. These types of information include, for example, notification information, screen information, proposal content, negotiation information, necessary information, and agreement documents, which will be described later.

[0121] The petition notification unit 141, upon receiving petition information from the petition acquisition unit 121, acquires notification information including creditor information identified by the creditor identifier in the petition information and debt details information, and transmits said notification information to the debtor. The transmission of information may be either push-type or pull-type transmission.

[0122] The screen transmission unit 142 transmits specific screen information to the creditor terminal 2 or debtor terminal 3 when the transmission conditions for transmitting specific screen information are met. For example, after the confirmation receiving unit 122 receives confirmation information, the screen transmission unit 142 transmits screen information to the debtor terminal 3 to allow the debtor to select one of two or more methods of debt processing. For example, when the screen transmission unit 142 receives a selection of a selection object from the creditor terminal 2 or debtor terminal 3, it transmits screen information corresponding to that selection object to the creditor terminal 2 or debtor terminal 3.

[0123] The proposal content transmission unit 143 transmits the proposal content acquired by the proposal content acquisition unit 135 to the creditor terminal 2 or the debtor terminal 3. The proposal content transmission unit 143 may transmit the same proposal content to both the creditor terminal 2 and the debtor terminal 3. For example, in response to the receipt of a proposal content instruction, the proposal content transmission unit 143 transmits the proposal content corresponding to that instruction.

[0124] It is preferable for the proposal content transmission unit 143 to transmit the proposal content in such a way that the negotiation information received by the negotiation receiving unit 123 corresponds to the proposal content acquired by the proposal content acquisition unit 135. This is because the negotiation information that forms the basis of the proposal content can be grasped.

[0125] The negotiation information output unit 144 outputs two or more negotiation information received by the negotiation receiving unit 123. For example, the negotiation information output unit 144 outputs the two or more negotiation information received by the negotiation receiving unit 123 in the order in which it was received by the negotiation receiving unit 123, and in a manner that allows it to determine whether the identifier associated with the negotiation information is a creditor identifier or a debtor identifier. For example, the negotiation information output unit 144 outputs screen information that is aligned to the right or left of the screen for negotiation information associated with a creditor identifier, and screen information that is aligned to the left or right of the screen for negotiation information associated with a debtor identifier.

[0126] Here, output typically refers to transmission to creditor terminal 2 or debtor terminal 3. However, output may also be a concept that includes display on a screen, projection using a projector, printing with a printer, sound output, transmission to an external device, storage on a recording medium, and delivery of processing results to other processing devices or programs other than creditor terminal 2 or debtor terminal 3.

[0127] The necessary information transmission unit 145 transmits necessary information to the debtor, which is information necessary for the debtor to process the debt, when the judgment unit 137 determines that the agreement conditions have been met. The necessary information usually includes payment destination information. Payment destination information may include, for example, account information, credit card information, and online payment information. The necessary information may also include, for example, information indicating the mailing address for loaned items and information indicating the location where services are enjoyed.

[0128] The agreement document output unit 146 outputs the agreement document generated by the agreement document generation unit 138. The agreement document output unit 146 transmits the agreement document to the creditor terminal 2 and the debtor terminal 3. It is preferable for the agreement document output unit 146 to transmit the agreement document corresponding to the instruction when an agreement document instruction is received.

[0129] The information transmission unit 147 transmits the information acquired by the processing unit 13 to the creditor terminal 2 or the debtor terminal 3. The information transmission unit 147 transmits, for example, some or all of the debt status information acquired by the information acquisition unit 139 to the creditor terminal 2 or the debtor terminal 3. The information transmission unit 147 transmits some or all of the debt status information to the creditor terminal 2 or the debtor terminal 3 that has sent an output instruction. The information transmission unit 147 transmits, for example, the proposed content, the agreement document, or the payment schedule to the creditor terminal 2 or the debtor terminal 3 that has sent a proposed content instruction, an agreement document instruction, or a payment schedule instruction.

[0130] The creditor storage unit 21, which constitutes the creditor terminal 2, stores various types of information. These types of information include, for example, creditor identifiers.

[0131] The creditor reception unit 22 receives various types of information and instructions. These types of information and instructions include, for example, application information, negotiation information, output instructions, proposal content instructions, agreement document instructions, or payment schedule instructions.

[0132] The means of inputting various information and instructions can be anything, such as a touch panel, keyboard, mouse, or menu screen.

[0133] The creditor processing unit 23 performs various processes. These processes include, for example, converting received information and instructions into information and instructions for transmission. Other processes include, for example, converting received information into information for output.

[0134] The creditor transmission unit 24 transmits various information and instructions to the debt management device 1 or other devices (not shown). These various information and instructions include, for example, application information, negotiation information, and output instructions.

[0135] The creditor receiving unit 25 receives various types of information. These types of information include, for example, confirmation information, negotiation information, debt status information, and various screen information.

[0136] The creditor output unit 26 outputs various types of information. These types of information include, for example, confirmation information, negotiation information, debt status information, and various screens.

[0137] Here, output typically includes concepts such as displaying on a screen, projecting using a projector, printing with a printer, sound output, transmission to an external device, storage on a recording medium, and handing over processing results to other processing devices or other programs.

[0138] The debtor storage unit 31, which constitutes the debtor terminal 3, stores various types of information. These types of information include, for example, debtor identifiers.

[0139] The debtor reception unit 32 receives various types of information and instructions. These types of information and instructions include, for example, confirmation information, negotiation information, output instructions, proposal content instructions, agreement document instructions, or payment schedule instructions.

[0140] The means of inputting various information and instructions can be anything, such as a touch panel, keyboard, mouse, or menu screen.

[0141] The debtor processing unit 33 performs various processes. These processes include, for example, converting received information and instructions into information and instructions for transmission. Other processes include, for example, converting received information into information for output.

[0142] The debtor transmission unit 34 transmits various information and instructions to the debt management device 1 or other devices (not shown). These various information and instructions include, for example, confirmation information, negotiation information, and output instructions.

[0143] The debtor receiving unit 35 receives various types of information. These types of information include, for example, notification information, negotiation information, and debt status information.

[0144] The debtor output unit 36 ​​outputs various types of information. These types of information include, for example, notification information, negotiation information, debt status information, and various screens.

[0145] The storage unit 11, the debt management unit 111, the creditor storage unit 21, and the debtor storage unit 31 are preferably made of non-volatile recording media, but can also be made of volatile recording media.

[0146] The process by which information is stored in the storage unit 11, etc. is not relevant. For example, information may be stored in the storage unit 11, etc. via a recording medium, information transmitted via a communication line, etc. may be stored in the storage unit 11, etc., or information input via an input device may be stored in the storage unit 11, etc.

[0147] The receiving unit 12, the application acquisition unit 121, the confirmation receiving unit 122, the negotiation receiving unit 123, the instruction receiving unit 124, the creditor receiving unit 25, and the debtor receiving unit 35 are implemented, for example, by wireless or wired communication means, but may also be implemented by means of receiving broadcasts, etc.

[0148] The processing unit 13, application storage unit 131, update unit 132, confirmation storage unit 133, negotiation storage unit 134, proposal content acquisition unit 135, mediation support unit 136, judgment unit 137, agreement document generation unit 138, information acquisition unit 139, creditor processing unit 23, and debtor processing unit 33 can usually be implemented from a processor, memory, etc. The processing procedures of the processing unit 13, etc., are usually implemented in software, and this software is recorded on a recording medium such as ROM. However, it may also be implemented in hardware (dedicated circuitry). The processor can be a CPU, MPU, GPU, etc., and the type is not specified. The application acquisition unit 121 may also be implemented from a processor, memory, etc., similar to the processing unit 13.

[0149] The transmission unit 14, the petition notification unit 141, the screen transmission unit 142, the proposal content transmission unit 143, the negotiation information output unit 144, the necessary information transmission unit 145, the agreement document output unit 146, the information transmission unit 147, the creditor transmission unit 24, and the debtor transmission unit 34 are usually implemented by wireless or wired communication means, but may also be implemented by broadcasting means.

[0150] The creditor reception unit 22 and the debtor reception unit 32 can be implemented using device drivers for input means such as touch panels and keyboards, or control software for menu screens.

[0151] The creditor output unit 26 and the debtor output unit 36 ​​may or may not be considered to include output devices such as displays and speakers. The creditor output unit 26 can be implemented using driver software for the output device, or driver software for the output device and the output device itself.

[0152] Next, an example of the operation of the debt management device 1 will be explained using the flowcharts in Figures 4 and 5.

[0153] (Step S401) The petition acquisition unit 121 determines whether or not it has received the case registration from the creditor terminal 2. If the case registration has been received, it proceeds to step S402; otherwise, it proceeds to step S408.

[0154] (Step S402) The petition storage unit 131 obtains petition time information, which is the date and time of filing, from a clock (not shown). The petition storage unit 131 obtains petition information included in the case registration. The petition storage unit 131 is information that has said petition information and said petition time information, and constitutes the petition information to be stored.

[0155] (Step S403) The petition storage unit 131 obtains a unique claim identifier.

[0156] (Step S404) The application storage unit 131 stores the application information obtained in step S402 in the claim management unit 111, paired with the claim identifier obtained in step S403. At this point, the update unit 132 may update the phase identification information to "awaiting confirmation" paired with the said claim identifier.

[0157] (Step S405) The petition notification unit 141 constitutes the notification information. An example of the process of composing such notification information will be explained using the flowchart in Figure 6.

[0158] (Step S406) The petition notification unit 141 obtains the creditor's contact information from the received petition information.

[0159] (Step S407) The petition notification unit 141 sends the notification information configured in step S405 to the contact person identified by the contact information obtained in step S406. Return to step S401.

[0160] (Step S408) The confirmation receiving unit 122 determines whether or not it has received confirmation information, etc. from the debtor terminal 3. If confirmation information, etc. has been received, the unit proceeds to step S409; otherwise, it proceeds to step S411. Confirmation information, etc. refers to confirmation information or non-existent information. The received confirmation information, etc. is associated with the debt identifier.

[0161] (Step S409) The confirmation and storage unit 133 obtains the claim identifier associated with the confirmation information, etc.

[0162] (Step S410) The confirmation storage unit 133 acquires confirmation time information from a clock (not shown). The confirmation storage unit 133 stores the confirmation information, including the confirmation time information, in the debt management unit 111, associating it with the debt identifier acquired in step S409. The process returns to step S401. If the received information is confirmation information, the confirmation storage unit 133 may update the phase identification information associated with the debt identifier to "Confirmed".

[0163] (Step S411) The negotiation receiving unit 123 determines whether or not it has received negotiation information from the creditor terminal 2 or the debtor terminal 3. If negotiation information is received, the unit proceeds to step S412; otherwise, it proceeds to step S423. The received negotiation information is associated with a debt identifier.

[0164] (Step S412) The negotiation storage unit 134 obtains the debt identifier.

[0165] (Step S413) The negotiation storage unit 134 stores the negotiation information in the debt management unit 111, associating it with the debt identifier. The negotiation storage unit 134 may also acquire the inputter identifier and store the negotiation information including the inputter identifier.

[0166] (Step S414) The proposal content acquisition unit 135 determines whether the received negotiation information matches the proposal content creation conditions. If it matches the proposal content creation conditions, the process proceeds to step S415; otherwise, the process proceeds to step S417.

[0167] (Step S415) The proposal content acquisition unit 135 constructs the proposal content. An example of this proposal content construction process will be explained using the flowchart in Figure 7.

[0168] (Step S416) The proposal content acquisition unit 135 stores the proposal content, which was composed in step S415, in the debt management unit 111, associating it with negotiation information.

[0169] (Step S417) The determination unit 137 determines whether the received negotiation information matches the agreement conditions. If it matches the agreement conditions, the process proceeds to step S418; otherwise, it returns to step S401.

[0170] (Step S418) The agreement document generation unit 138 generates an agreement document. An example of such an agreement document generation process will be explained using the flowchart in Figure 8.

[0171] (Step S419) The agreement document generation unit 138 stores the agreement document obtained in step S418 in the debt management unit 111, associating it with the debt identifier.

[0172] (Step S420) The processing unit 13 obtains the creditor identifier. The necessary information transmission unit 145 obtains the necessary information corresponding to the creditor identifier from the debt management unit 111. The necessary information is, for example, payment destination information.

[0173] (Step S421) The processing unit 13 determines whether or not the necessary information was obtained in step S420. If the necessary information was obtained, the process proceeds to step S422; otherwise, it returns to step S401.

[0174] (Step S422) The necessary information transmission unit 145 transmits the necessary information to the debtor. Return to step S401. Note that the means of transmitting the necessary information here is irrelevant.

[0175] (Step S423) The instruction receiving unit 124 determines whether or not it has received an output instruction from the creditor terminal 2 or the debtor terminal 3. If an output instruction is received, the unit proceeds to step S424; otherwise, it proceeds to step S428. Note that the output instruction is associated with the debt identifier.

[0176] (Step S424) The information acquisition unit 139 acquires the debt identifier corresponding to the output instruction received in step S423.

[0177] (Step S425) The information acquisition unit 139 acquires debt status information from the debt management unit 111 that corresponds to the debt identifier acquired in step S424. Note that the debt status information acquired here may be only a portion of the debt status information from the debt management unit 111.

[0178] (Step S426) The information acquisition unit 139 uses the debt status information acquired in step S425 to construct the output information. An example of this output information configuration process will be explained using the flowchart in Figure 9.

[0179] (Step S427) The information transmission unit 147 transmits the output information to the terminal that sent the output instruction. Return to step S401.

[0180] (Step S428) The instruction receiving unit 124 determines whether or not it has received an instruction regarding the proposed content from the creditor terminal 2 or the debtor terminal 3. If an instruction regarding the proposed content has been received, the unit proceeds to step S429; otherwise, it proceeds to step S431. The instruction regarding the proposed content corresponds to a piece of negotiation information.

[0181] (Step S429) The information acquisition unit 139 acquires from the debt management unit 111 a proposal that corresponds to one negotiation piece of information corresponding to the proposal content instruction received in step S428.

[0182] (Step S430) The information transmission unit 147 transmits the proposal content obtained in step S429 to the terminal that sent the proposal content instruction. Return to step S401.

[0183] (Step S431) The instruction receiving unit 124 determines whether or not it has received an agreement document instruction from the creditor terminal 2 or the debtor terminal 3. If an agreement document instruction is received, the unit proceeds to step S432; otherwise, it proceeds to step S434. The agreement document instruction is associated with a debt identifier.

[0184] (Step S432) The information acquisition unit 139 acquires a debt identifier corresponding to the agreement document instruction received in step S431. The information acquisition unit 139 acquires the agreement document that corresponds to the debt identifier from the debt management unit 111.

[0185] (Step S433) The information transmission unit 147 transmits the agreement document obtained in step S432 to the terminal that sent the agreement document instruction. The process returns to step S401.

[0186] (Step S434) The instruction receiving unit 124 determines whether or not it has received a payment schedule instruction from the creditor terminal 2 or the debtor terminal 3. If a payment schedule instruction is received, the unit proceeds to step S435; otherwise, it proceeds to step S437. The payment schedule instruction is associated with a debt identifier.

[0187] (Step S435) The information acquisition unit 139 acquires the debt identifier associated with the payment schedule instruction received in step S434. The information acquisition unit 139 acquires the total payment amount and the monthly amount that are paired with the debt identifier from the debt management unit 111. The information acquisition unit 139 acquires the payment schedule using the total payment amount and the monthly amount.

[0188] (Step S436) The information transmission unit 147 transmits the payment schedule obtained in step S435 to the terminal that sent the payment schedule instruction. The process returns to step S401.

[0189] (Step S437) The receiving unit 12 determines whether or not it has received payment information. If payment information has been received, it proceeds to step S438; otherwise, it proceeds to step S439. The payment information is associated with a debt identifier.

[0190] (Step S438) The processing unit 13 stores payment information associated with the claim identifier. The process returns to step S401.

[0191] (Step S439) The processing unit 13 determines whether the conditions for sending specific screen information to the creditor terminal 2 or the debtor terminal 3 are met. If the conditions for sending are met, the process proceeds to step S440; otherwise, it returns to step S401.

[0192] The transmission conditions include, for example, the receipt of confirmation information or specific negotiation information, or the receipt of a screen output instruction from creditor terminal 2 or debtor terminal 3. The screen information to be transmitted is associated with each transmission condition.

[0193] (Step S440) The information acquisition unit 139 acquires screen information corresponding to the transmission conditions from the storage unit 11. The screen information corresponding to the transmission conditions is, for example, the screen information that is paired with the selected object.

[0194] (Step S441) The information transmission unit 147 transmits the screen information acquired in step S440 to the creditor terminal 2 or debtor terminal 3. The process returns to step S401.

[0195] In the flowcharts shown in Figures 4 and 5, processing is terminated by power-off or processing termination interrupts.

[0196] Next, an example of the notification information configuration process in step S405 will be explained using the flowchart in Figure 6.

[0197] (Step S601) The petition notification unit 141 obtains a notification information template from the storage unit 11.

[0198] (Step S602) The petition notification unit 141 obtains the claim identifier. The petition notification unit 141 obtains the creditor information (for example, the name of the creditor) that is paired with the claim identifier.

[0199] (Step S603) The petition notification section 141 substitutes the creditor's information into the variable in the notification information template that is used to substitute the creditor's information.

[0200] (Step S604) The petition notification unit 141 obtains debtor information (for example, the debtor's name) that is paired with the debt identifier.

[0201] (Step S605) The petition notification section 141 substitutes the debtor's information into the variable in the notification information template that is used to substitute the debtor's information.

[0202] (Step S606) The petition notification unit 141 obtains link information to access the debt details information that is paired with the debt identifier. Note that the link information is usually a URL, but any information that allows access to the debt details information is acceptable.

[0203] (Step S607) The petition notification unit 141 assigns the link information to the variable in the notification information template. It then returns to the higher-level process.

[0204] Next, an example of the proposed content configuration process in step S415 will be explained using the flowchart in Figure 7.

[0205] (Step S701) The proposal content acquisition unit 135 acquires a proposal content template from the storage unit 11.

[0206] The proposal content acquisition unit 135, for example, acquires a debt processing identifier included in the negotiation information and obtains a proposal content template that corresponds to the debt processing identifier from the storage unit 11.

[0207] (Step S702) The proposal content acquisition unit 135 acquires the debt identifier corresponding to the received negotiation information.

[0208] (Step S703) The proposal content acquisition unit 135 assigns 1 to counter i.

[0209] (Step S704) The proposal content acquisition unit 135 determines whether the i-th variable exists in the proposal content template acquired in step S701. If the i-th variable exists, the process proceeds to step S705; otherwise, it returns to the higher-level process.

[0210] (Step S705) The proposal content acquisition unit 135 acquires information corresponding to the i-th variable from the debt status information paired with the debt identifier.

[0211] (Step S706) The proposal content acquisition unit 135 assigns the information acquired in step S705 to the i-th variable in the proposal content template.

[0212] (Step S707) The proposal content acquisition unit 135 increments counter i by 1. Return to step S704.

[0213] Next, an example of the agreement document generation process in step S418 will be explained using the flowchart in Figure 8.

[0214] (Step S801) The agreement document generation unit 138 obtains an agreement document template from the storage unit 11.

[0215] (Step S802) The agreement document generation unit 138 obtains a claim identifier corresponding to the received negotiation information.

[0216] (Step S803) The agreement document generation unit 138 assigns 1 to counter i.

[0217] (Step S804) The agreement document generation unit 138 determines whether the i-th variable exists in the agreement document template obtained in step S801. If the i-th variable exists, the unit proceeds to step S805; otherwise, it returns to the higher-level process.

[0218] (Step S805) The agreement document generation unit 138 obtains information corresponding to the i-th variable from the debt status information paired with the debt identifier.

[0219] (Step S806) The agreement document generation unit 138 substitutes the information obtained in step S805 into the agreement document template at the location of the i-th variable.

[0220] (Step S807) The agreement document generation unit 138 increments counter i by 1. Return to step S804.

[0221] Next, an example of the output information configuration process in step S426 will be explained using the flowchart in Figure 9.

[0222] (Step S901) The information acquisition unit 139 acquires screen information from the storage unit 11 that will be used as the basis for constructing the output information.

[0223] (Step S902) The information acquisition unit 139 assigns 1 to counter i.

[0224] (Step S903) The information acquisition unit 139 determines whether or not the i-th variable exists in the screen information. If the i-th variable exists, the unit proceeds to step S904; otherwise, the unit proceeds to step S907.

[0225] (Step S904) The information acquisition unit 139 acquires the debt identifier. The information acquisition unit 139 acquires the information corresponding to the i-th variable in the screen information from the debt status information that is paired with the debt identifier. The information corresponding to the i-th variable is, for example, the creditor name, debtor name, payment amount, payment start date, and payment due date.

[0226] (Step S905) The information acquisition unit 139 assigns the information acquired in step S904 to the i-th variable in the screen information.

[0227] (Step S906) The information acquisition unit 139 increments counter i by 1. The process returns to step S903.

[0228] (Step S907) The information acquisition unit 139 uses the application information in the claim status information that is paired with the claim identifier acquired in step S904 to acquire application-related information. The application-related information includes, for example, information indicating that a claim has been filed (e.g., "I have filed a claim."), application information (e.g., date and time), and the name of the creditor.

[0229] (Step S908) The information acquisition unit 139 determines whether or not confirmation information exists in the claim status information that is paired with the claim identifier acquired in step S904. If confirmation information exists, the process proceeds to step S909; otherwise, it returns to the higher-level process.

[0230] (Step S909) The information acquisition unit 139 acquires confirmation-related information using confirmation information of the debt status information that is paired with the debt identifier. The confirmation-related information includes, for example, information indicating that the application for the debt has been confirmed (e.g., "The case has been confirmed."), confirmation time information (e.g., year, month, and time), and the name of the debtor.

[0231] (Step S910) The information acquisition unit 139 assigns 1 to counter i.

[0232] (Step S911) The information acquisition unit 139 determines whether or not the i-th negotiation information exists in the debt status information that is paired with the debt identifier acquired in step S904. If the i-th negotiation information exists, the unit proceeds to step S912; otherwise, the unit proceeds to step S919.

[0233] (Step S912) The information acquisition unit 139 acquires a creditor identifier or debtor identifier that corresponds to the i-th negotiation information from the debt status information that corresponds to the said debt identifier. The creditor identifier or debtor identifier will be referred to as an identifier as appropriate.

[0234] (Step S913) The information acquisition unit 139 determines whether the proposed content is associated with the i-th negotiation information. If the proposed content is associated, the process proceeds to step S914; otherwise, the process proceeds to step S915.

[0235] (Step S914) The information acquisition unit 139 uses the i-th negotiation information and the proposed content to construct the negotiation relationship information to be output. Proceed to step S916. Note that the negotiation relationship information here includes, for example, a sentence explaining the negotiation information, negotiation time information, and link information to the proposed content.

[0236] (Step S915) The information acquisition unit 139 uses the i-th negotiation information to construct the negotiation relationship information to be output. The negotiation relationship information here includes, for example, a sentence explaining the negotiation information and negotiation time information.

[0237] (Step S916) The information acquisition unit 139 places the i-th negotiation relationship information below the information already placed, where the identifier specifies the side (for example, the right or left side of the screen).

[0238] (Step S917) The information acquisition unit 139 increments counter i by 1. Return to step S911.

[0239] (Step S918) The information acquisition unit 139 determines whether an agreement has been reached. If an agreement has been reached, it proceeds to step S919; otherwise, it returns to the higher-level process.

[0240] (Step S919) The information acquisition unit 139 acquires the necessary information that corresponds to the claim identifier. The necessary information is usually the recipient information.

[0241] (Step S920) The information acquisition unit 139 places the necessary information on the screen. It then returns to the higher-level processing.

[0242] Next, an example of the operation of creditor terminal 2 will be explained using the flowchart in Figure 10.

[0243] (Step S1001) The creditor reception unit 22 determines whether or not it has accepted the case registration. If the case registration has been accepted, it proceeds to step S1002; otherwise, it proceeds to step S1003.

[0244] (Step S1002) The creditor transmission unit 24 transmits the case registration received in step S1001 to the debt management device 1. Return to step S1001.

[0245] (Step S1003) The creditor reception unit 22 determines whether or not it has received the output instruction. If it has received the output instruction, it proceeds to step S1004; otherwise, it proceeds to step S1007.

[0246] (Step S1004) The creditor processing unit 23 obtains the debt identifier. The creditor transmission unit 24 transmits the output instruction received in step S1003 to the debt management device 1, associating it with the debt identifier.

[0247] (Step S1005) The creditor receiving unit 25 determines whether or not it has received the output information. If it has received the output information, it proceeds to step S1006; otherwise, it returns to step S1005.

[0248] (Step S1006) The creditor processing unit 23 configures the output information to be output from the received output information. The creditor output unit 26 outputs the output information. The process returns to step S1001.

[0249] (Step S1007) The creditor reception unit 22 determines whether or not it has received the negotiation information. If it has received the negotiation information, it proceeds to step S1008; otherwise, it proceeds to step S1009.

[0250] (Step S1008) The creditor processing unit 23 obtains the debt identifier. The creditor transmission unit 24 transmits the negotiation information received in step S1007 to the debt management device 1, associating it with the debt identifier. The process returns to step S1001.

[0251] (Step S1009) The creditor reception unit 22 determines whether or not it has received a screen output instruction. If it has received a screen output instruction, it proceeds to step S1010; otherwise, it proceeds to step S1013. The screen output instruction contains information that identifies the screen information.

[0252] (Step S1010) The creditor processing unit 23 obtains the debt identifier. The creditor transmission unit 24 transmits the screen output instruction received in step S1009 to the debt management device 1, associating it with the debt identifier.

[0253] (Step S1011) The creditor receiving unit 25 determines whether or not it has received screen information from the debt management device 1. If screen information has been received, it proceeds to step S1012; otherwise, it returns to step S1011.

[0254] (Step S1012) The creditor processing unit 23 constructs a screen from the screen information received in step S1011. The creditor output unit 26 outputs the screen. The process returns to step S1001.

[0255] (Step S1013) The creditor reception unit 22 determines whether or not it has received any other instructions. If it has received any other instructions, it proceeds to step S1014; otherwise, it returns to step S1001.

[0256] (Step S1014) The creditor processing unit 23 obtains the debt identifier. The creditor transmission unit 24 transmits the instruction received in step S1013 to the debt management device 1, associating it with the debt identifier.

[0257] (Step S1015) The creditor receiving unit 25 determines whether or not it has received information from the debt management device 1. If information has been received, it proceeds to step S1016; otherwise, it returns to step S1015.

[0258] (Step S1016) The creditor processing unit 23 configures the information to be output from the received information. The creditor output unit 26 outputs the information. The process returns to step S1001.

[0259] In the flowchart shown in Figure 10, processing is terminated by power-off or processing termination interrupts.

[0260] Next, an example of the operation of the debtor terminal 3 will be explained using the flowchart in Figure 11.

[0261] (Step S1101) The debtor receiving unit 35 determines whether or not it has received notification information from the debt management device 1. If it has received notification information, it proceeds to step S1102; otherwise, it proceeds to step S1104. The received notification information is associated with a debt identifier.

[0262] (Step S1102) The debtor output unit 36 ​​outputs the notification information received in step S1101.

[0263] (Step S1103) The debtor reception unit 32 determines whether it has received confirmation information or the like. If it has received the confirmation information or the like, it proceeds to step S1104; if not, it returns to step S1103.

[0264] (Step S1104) The debtor processing unit 33 acquires the claim identifier associated with the notification information. The debtor transmission unit 34 transmits the confirmation information or the like to the claim management device 1 in association with the claim identifier. It returns to step S1101.

[0265] (Step S1105) The debtor reception unit 32 determines whether it has received an output instruction. If it has received the output instruction, it proceeds to step S1106; if not, it proceeds to step S1009.

[0266] (Step S1106) The debtor processing unit 33 acquires the claim identifier associated with the screen for inputting the output instruction. The debtor transmission unit 34 transmits the output instruction to the claim management device 1 in association with the claim identifier.

[0267] (Step S1107) The debtor reception unit 35 determines whether it has received output information. If it has received the output information, it proceeds to step S1109; if not, it returns to step S1107.

[0268] (Step S1108) The debtor processing unit 33 constructs the output information to be output from the output information received in step S1107. The debtor output unit 36 outputs the output information. It returns to step S1101.

[0269] (Step S1109) The debtor reception unit 32 determines whether it has received negotiation information. If it has received the negotiation information, it proceeds to step S1110; if not, it proceeds to step S1111.

[0270] (Step S1110) The debtor processing unit 33 obtains a debt identifier corresponding to the screen for inputting negotiation information. The debtor transmission unit 34 transmits the negotiation information received in step S1109 to the debt management device 1, associating it with the debt identifier. The process returns to step S1101.

[0271] (Step S1111) The debtor reception unit 32 determines whether or not it has received a screen output instruction. If it has received a screen output instruction, it proceeds to step S1112; otherwise, it proceeds to step S1115.

[0272] (Step S1112) The debtor processing unit 33 obtains the debt identifier. The debtor transmission unit 34 transmits the screen output instruction received in step S1111 to the debt management device 1, associating it with the debt identifier.

[0273] (Step S1113) The debtor receiving unit 35 determines whether or not it has received screen information from the debt management device 1. If screen information has been received, it proceeds to step S1114; otherwise, it returns to step S1113.

[0274] (Step S1114) The debtor processing unit 33 constructs a screen from the screen information received in step S1113. The debtor output unit 36 ​​outputs the screen. The process returns to step S1101.

[0275] (Step S1115) The debtor reception unit 32 determines whether or not it has received any other instructions. If it has received any other instructions, it proceeds to step S1116; otherwise, it returns to step S1101.

[0276] (Step S1116) The debtor processing unit 33 obtains the debt identifier. The debtor transmission unit 34 transmits the instruction received in step S1115 to the debt management device 1, associating it with the debt identifier.

[0277] (Step S1117) The debtor receiving unit 35 determines whether or not it has received information from the debt management device 1. If information has been received, it proceeds to step S1118; otherwise, it returns to step S1116.

[0278] (Step S1118) The debtor processing unit 33 configures the information to be output from the received information. The debtor output unit 36 ​​outputs the said information. Return to step S1101.

[0279] In the flowchart shown in Figure 11, processing is terminated by power-off or processing termination interrupts.

[0280] The following describes a specific example of the operation of information system A in this embodiment. Here, the debt management device 1 handles monetary debts. Figure 12 shows the flow of phases in the debt management device 1 from the creation of a debt to the agreement between the creditor and debtor regarding the processing of the debt and the completion of the debt processing. In Figure 12, the phases proceed in the order of "Application submitted," "Waiting for confirmation," "Confirmed," "Negotiating," "Debt processing," and "Debt processing completed." It is also assumed that the "Negotiating" phase may transition to "Online mediation in progress." Furthermore, the "Online mediation in progress" phase may progress to "Debt processing" or "Negotiation unsuccessful." The numbers above the strings indicating each phase in Figure 12 are phase identifiers that identify the phase. In other words, the phase identifier for the "Application submitted" phase is "1," "Waiting for confirmation" is "2," "Confirmed" is "3," "Negotiating" is "4," "Debt processing in progress" is "5," "Debt processing completed" is "6," "Online mediation in progress" is "7," and "Negotiation unsuccessful" is "8." Note that "debt processing in progress" refers to, for example, one of the intermediate payment stages in a multi-installment payment plan.

[0281] The storage unit 11 of the debt management device 1 stores the creditor management table shown in Figure 13. The creditor management table is a table that manages information about creditors. The creditor management table is a table that manages creditor information registered by users in order to receive services from the debt management device 1. The creditor management table manages one or more records that have "ID", "creditor identifier", "creditor name", "email address", and "payment destination information". Note that "creditor name", "email address", and "payment destination information" constitute creditor information. "Payment destination information" is, for example, bank account information.

[0282] The debt management unit 111 of the debt management device 1 stores a debt management table having the structure shown in Figure 14. The debt management table is a table that manages debt status information. The debt management table is a table that manages one or more records having "debt identifier," "petition information," "confirmation information," "debt processing identifier," "phase identifier," "negotiation information," "negotiation time," "proposal content," and "agreement document." "Petition information" has "debt content information," "creditor identifier," "debtor information," and "petition time." "Confirmation information" has "confirmation time." "Negotiation information" here has "inputter" and "negotiation content." "Inputter" has either "1" indicating that the person inputting the negotiation information is the creditor, or "2" indicating that the person inputting the negotiation information is the debtor.

[0283] Regarding the information that constitutes the "debt processing identifier," here we will assign the following to each category: "Pay now by credit card" is "1," "Pay in full by the end of next month" is "2," "Pay in installments at the end of each month" is "3," "Proposal to revise the amount" is "4," "I don't recognize the claim" is "5," "Already paid directly" is "6," and "Want online mediation" is "7." The "debt processing identifier" may also have a payment method identifier. For example, the payment method identifier could be "A" for credit card payment or "B" for bank transfer.

[0284] In the storage unit 11 of the claim management device 1, a proposal content template for each claim processing means identifier is stored (Fig. 15). Also, in the storage unit 11 of the claim management device 1, a consent document template for each claim processing means identifier is stored (Fig. 16). In the proposal content template and the consent document template, the character strings enclosed by "<" and ">" are variables. The variables are replaced with information to form the proposal content. The variable < debtor name > is where the debtor name is placed, and the variable < creditor name > is where the creditor name is placed.

[0285] In the above situation, assume that Ako Tanaka, who has registered creditor information in the claim management device 1, uses the creditor terminal 2 to log in to the claim management device 1.

[0286] Then, due to the operation of Ako Tanaka, assume that the creditor terminal 2 receives screen information for filing a claim from the claim management device 1 and outputs the case registration screen shown in Fig. 17.

[0287] Next, assume that Ako Tanaka inputs information into each field such as "Claim Case Name", "Claim Amount", "Principal Payment Date" on the screen of Fig. 17 and instructs the "Submit" button 1701.

[0288] Next, the creditor reception unit 22 of the creditor terminal 2 accepts the case registration according to the instruction of the button 1701. The case registration has the claim information "< Claim Case Name > Non - payment of Company X < Claim Amount > 100,000 < Principal Payment Date > 2924 / 8 / 1 < Creditor Identifier > C01 ··· < Counterparty Name > Company X ···< Counterparty Email Address > yy@x.jp". Next, the creditor transmission unit 24 transmits the case registration to the claim management device 1. Assume that the creditor identifier "C01" is stored in the creditor storage unit 21, for example.

[0289] Next, the claim acquisition unit 121 of the debt management device 1 receives the case registration from the creditor terminal 2. The claim acquisition unit 121 obtains the current date and time, the time of filing, "2024 / 8 / 11 09:00", from a clock (not shown). The claim acquisition unit 121 constructs the accumulated claim information "<Claim Case Name>X Company Nonpayment <Claim Amount>100,000 <Main Payment Due Date>2924 / 8 / 1 <Creditor Identifier>C01 ··· <Counterparty Name>X Company ···<Counterparty Email Address>yy@x.jp <Time of Filing>2024 / 8 / 11 15:35". Next, the claim storage unit 131 obtains a unique debt identifier "1". Next, the claim storage unit 131 stores the constructed claim information in the debt management table (Figure 14) in pairs with the debt identifier "1". This claim information is the claim information with "ID=1" in Figure 14. The update unit 132 also stores the phase identifier "1" in the record with "ID=1" in Figure 14.

[0290] Next, the application notification unit 141 of the debt management device 1 configures the notification information as follows. First, the application notification unit 141 configures the notification information shown in Figure 18 according to the operation of the notification information configuration process explained using the flowchart in Figure 6. The application notification unit 141 configures the notification information by substituting the information corresponding to each underlined part into the notification information template in Figure 18, where the underlined parts are variables. Next, the application notification unit 141 obtains the debtor's contact information "yy@x.jp" from the application information. Next, the application notification unit 141 sends the notification information (Figure 18) to the contact person identified by the contact information. The update unit 132 also updates the phase identifier "ID=1" in Figure 14 from "1" to "2".

[0291] Next, the debtor terminal 3 receives and outputs an email containing notification information (Figure 18) from the debt management device 1. The trigger for outputting the notification information on the debtor terminal 3 is irrelevant.

[0292] Next, let's assume that "Yamada Y," the person in charge at Company X, looks at the notification information (Figure 18) and clicks on URL 1801. Next, the debtor terminal 3 obtains screen information containing the application information corresponding to URL 1801 from the debt management device 1 and outputs a confirmation screen (Figure 19) based on that screen information. The confirmation screen is a screen for the debtor to confirm the application for the debt. Next, let's assume that Yamada Y looks at the confirmation screen, checks the checkbox 1901 that says "This is an application against me," and clicks the "Next" button 1902. Then, the debtor reception unit 32 of the debtor terminal 3 receives the confirmation information. Next, the debtor processing unit 33 obtains the debt identifier "1" that is associated with the screen information. Next, the debtor processing unit 33 constructs the confirmation information to be transmitted "<Confirmation Result> Confirmation <Debt Identifier> 1". Next, the debtor transmission unit 34 transmits the confirmation information to the debt management device 1. The confirmation result "Confirmation" is information indicating that confirmation has been made, for example, "1".

[0293] Next, the confirmation receiving unit 122 of the debt management device 1 receives the confirmation information "<Confirmation Result> Confirmed <Debt Identifier> 1" from the debtor terminal 3. Next, the confirmation storage unit 133 acquires the received debt identifier "1". Next, the confirmation storage unit 133 acquires the confirmation time "2024 / 8 / 11 15:50", which is the date and time, from a clock (not shown). Next, the confirmation storage unit 133 stores the confirmation time "2024 / 8 / 11 15:50" in conjunction with the debt identifier "1" based on the confirmation information "<Confirmation Result> Confirmed". Also, the update unit 132 updates the phase identifier from "2" to "3".

[0294] Next, the processing unit 13, having received the confirmation information, determines that the transmission conditions are met and retrieves screen information that matches the transmission conditions from the storage unit 11. This screen information is screen information for forming a decision screen. The decision screen is a screen for determining the debt processing identifier. Next, the screen transmission unit 142 transmits this screen information to Yamada Y's debtor terminal 3.

[0295] The debtor terminal 3 receives the screen information and outputs a screen for determining the debt processing identifier (Figure 20). The screen in Figure 20 has a history of debt processing to date 2001 and buttons 2002 corresponding to each of the seven candidate debt processing identifiers.

[0296] Then, Yamada Y-ko indicated button 2003 from Figure 20. Furthermore, by pressing button 2003, Yamada Y-ko entered the installment amount to be inquired about, "5000 yen". Then, the debtor reception unit 32 of the debtor terminal 3 receives the negotiation information "<debt processing identifier>3 <installment amount>5000". The debtor processing unit 33 obtains the debt identifier "1" and constructs the negotiation information to be transmitted "<debt identifier>1 <debt processing identifier>3 <installment amount>5000". Next, the debtor transmission unit 34 transmits the negotiation information to the debt management device 1.

[0297] Next, the negotiation receiving unit 123 of the debt management device 1 receives the negotiation information from the debtor terminal 3. Then, the negotiation storage unit 134 obtains the debt identifier "1" from the received negotiation information. The negotiation storage unit 134 also obtains the current date and time, negotiation time "2024 / 8 / 11 16:01", from a clock (not shown). The negotiation storage unit 134 also detects that the debt processing identifier is "3" (installment payment), obtains the application amount "100,000 yen" and installment amount "5,000 yen" which are paired with the debt identifier "1", obtains the payment start date, payment end date, and payment amount for each month (obtains the payment schedule), and stores them paired with the debt identifier "1". The payment schedule is stored in Figure 14, but is not shown.

[0298] Next, the proposal content acquisition unit 135 determines that the debt processing identifier "3" included in the received negotiation information matches the conditions for creating the proposal content. Then, the proposal content acquisition unit 135 constructs the proposal content using the process described using the flowchart in Figure 7. Next, the proposal content acquisition unit 135 stores the constructed proposal content in the debt management table (Figure 14) in association with the negotiation information. This proposal content is file "P1".

[0299] Furthermore, upon receiving the negotiation information, the processing unit 13 uses the notification information template in the storage unit 11 to compose notification information to send to the creditor. This notification information is for notifying the debtor of the proposal. Next, the transmission unit 14 sends the notification information to the creditor. The notification information template here is a document in which the underlined parts in Figure 21 are variables.

[0300] Next, creditor Tanaka A's creditor terminal 2 receives and outputs the notification information. This notification information is shown in Figure 21. Figure 21 is a notification information template in which the creditor name, installment amount, and link information 2101 for accessing negotiation information are placed in the variable section. Let's assume that Tanaka A then pointed to the URL 2101 in Figure 21.

[0301] Then, the creditor terminal 2 sends a transmission instruction to the debt management device 1 for screen information corresponding to URL 2101, receives the screen information from the debt management device 1, and outputs the screen shown in Figure 22. The screen information that makes up the screen in Figure 22 is information that was configured using the output information configuration process explained using the flowchart in Figure 9.

[0302] Next, let's assume that Tanaka A-ko instructed the "Propose a change in installment amount" button 2201 on the screen shown in Figure 22. The creditor terminal 2 then receives this instruction and sends a screen output instruction for the "Propose a change in installment amount" button 2201 to the debt management device 1.

[0303] Next, the instruction receiving unit 124 of the debt management device 1 receives the screen output instruction. Next, the information acquisition unit 139 acquires the screen information corresponding to the screen output instruction from the storage unit 11. Next, the information transmission unit 147 transmits the screen information to Tanaka A's creditor terminal 2.

[0304] Next, Tanaka A's creditor terminal 2 receives the screen information and outputs the installment amount change screen shown in Figure 23. Then, Tanaka A enters the proposed new installment amount "20,000 yen" on the screen in Figure 23 (2301 in Figure 23).

[0305] Next, creditor terminal 2 receives the proposed new installment amount of "20,000 yen" and transmits negotiation information, including the said installment amount of "20,000 yen," to debt management device 1, paired with the debt identifier "1."

[0306] Next, the receiving unit 12 of the debt management device 1 receives negotiation information including the installment amount "20,000 yen" paired with the debt identifier "1".

[0307] Next, the proposal content acquisition unit 135 determines that the received negotiation information meets the proposal content creation condition "includes installment payments".

[0308] Next, the proposal content acquisition unit 135 acquires a proposal content template from the storage unit 11 that corresponds to the proposal content creation conditions, based on the proposal content configuration process explained using the flowchart in Figure 7. The unit then substitutes the installment amount "20,000 yen," the creditor name, debtor name, and claim amount that correspond to the claim identifier "1" into the proposal content template, thereby composing the proposal content. Next, the transmission unit 14 transmits the proposal content to Tanaka A's creditor terminal 2.

[0309] Next, creditor terminal 2 receives and outputs the proposed content. An example of such output is shown in Figure 23, item 2031.

[0310] Next, let's assume that Tanaka A-ko instructed the "Propose a change in installment amount" button 2303 in Figure 23. Then, creditor terminal 2 receives the instruction to press the said button 203. Next, creditor terminal 2 composes negotiation information "<debt identifier>1 <installment amount>20,000 yen <debt identifier>C01" and transmits it to debt management device 1.

[0311] Next, the negotiation receiving unit 123 of the debt management device 1 receives the negotiation information. Then, the negotiation storage unit 134 obtains the debt identifier "1" included in the negotiation information. The negotiation storage unit 134 also obtains the time information "2024 / 8 / 11 16:34" from a clock (not shown). The negotiation storage unit 134 also obtains the claim amount "100,000 yen" and installment amount "20,000 yen" which are paired with the debt identifier "1", and obtains the payment start date, payment end date, and payment amount for each month (obtains the payment schedule), and stores them paired with the debt identifier "1". The payment schedule is stored in Figure 14, but is not shown.

[0312] Next, the proposal content acquisition unit 135 acquires the previously acquired proposal content. Then, the proposal content acquisition unit 135 associates the proposal content with the negotiation information (file "P2") and stores it in the debt management table (Figure 14).

[0313] Next, the processing unit 13 determines that the transmission condition for sending specific screen information, "the proposed content has been configured," is met. Next, the information acquisition unit 139 configures screen information including the negotiation information and link information to the proposed content. Next, the information transmission unit 147 transmits the screen information to Yamada Y's debtor terminal 3.

[0314] Next, the debtor terminal 3 receives the screen information and outputs the screen shown in Figure 24. Then, Yamada Y-ko instructs the user to press the "Accept Installment Amount Modification" button 2401 in Figure 24. The debtor terminal 3 then accepts the instruction to press the button 2401. Next, the debtor terminal 3 obtains the information "<Negotiation Result> Agreement" associated with the button 2401, constructs negotiation information "<Debt Identifier>1 <Negotiation Result> Agreement <Installment Amount>20000 <Debtor Identifier>Company X" containing this information, and transmits it to the debt management device 1.

[0315] Next, the negotiation receiving unit 123 of the debt management device 1 receives the negotiation information. The negotiation storage unit 134 obtains the debt identifier "1". The negotiation storage unit 134 obtains the current time, the agreement time "2024 / 8 / 11 16:39", from a clock (not shown). Next, the negotiation storage unit 134 stores the negotiation information "agreement" and the agreement time in association with the debt identifier "1".

[0316] Next, the judgment unit 137 determines that the received negotiation information matches the agreement condition "the negotiation information includes "<negotiation result> agreement". Next, the agreement document generation unit 138 generates agreement document "A1" using the agreement document generation process explained using the flowchart in Figure 8. Then, the agreement document generation unit 138 stores the agreement document "A1" in the debt management table (Figure 14) paired with the debt identifier "1".

[0317] Next, the information acquisition unit 139, in response to the instructions of the debtor (Yoko Yamada) via button 2401 (Figure 24), acquires screen information corresponding to the negotiation information "<Debt Identifier>1 <Negotiation Result>Agreement <Installment Amount>20000 <Debtor Identifier>Company X", which is screen information to be sent to the creditor. Next, the information transmission unit 147 transmits this screen information to the creditor terminal 2.

[0318] Furthermore, the information acquisition unit 139 acquires screen information for the debtor to determine the debt processing identifier in response to the debtor's button 2401 (Figure 24). Next, the information transmission unit 147 transmits this screen information to the debtor terminal 3.

[0319] Next, the creditor terminal 2 receives the screen information transmitted by the information transmission unit 147 and outputs the screen shown in Figure 25. The screen in Figure 25 shows the process of filing a claim, confirming the case, and negotiating until an agreement is reached.

[0320] Let's assume that Tanaka A-ko clicked the "Check Payment Schedule" button 2501 on the screen shown in Figure 25. The creditor terminal 2 then receives the instruction and retrieves and outputs a payment schedule corresponding to the instruction, which is paired with the debt identification number "1" from the debt management device 1. An example of such a payment schedule output is shown in Figure 26.

[0321] Furthermore, the debtor terminal 3 receives screen information for determining the debt processing identifier and outputs a screen for determining the debt processing identifier. An example of such a screen is shown in Figure 27.

[0322] Next, let's assume that Yamada Y. instructed the debtor terminal 3 to click the "Pay by bank transfer" button 2701 on the screen shown in Figure 27.

[0323] Next, the debtor terminal 3 receives the instruction and obtains the debt processing identifier "B". It is assumed that debt processing identifier "A" represents "payment by credit card" and "B" represents "payment by bank transfer". Next, the debtor terminal 3 transmits the debt processing identifier "B" to the debt management device 1, paired with debt identifier "1".

[0324] Next, the debt management device 1 receives the debt processing identifier "B," etc., and stores the debt processing identifier "B" in the debt management table (Figure 14) in conjunction with the debt identifier "1." As a result of this process, the record with "ID=1" in the debt management table now contains the debt processing identifier "3,B."

[0325] Furthermore, the update unit 132 of the debt management device 1 updates the phase identifier, which is paired with the debt identifier "1", to "5".

[0326] Next, the information acquisition unit 139 acquires the creditor identifier "C01," which is paired with the creditor identifier "1," from the debt management table (Figure 14). Next, the information acquisition unit 139 acquires the deposit destination information "Bank Account A," which is paired with the creditor identifier "C01." Next, the information acquisition unit 139 constructs screen information including the said deposit destination information "Bank Account A." Next, the information transmission unit 147 transmits the said screen information to the debtor terminal 3.

[0327] Next, the debtor terminal 3 receives the screen information and outputs the screen shown in Figure 28. In Figure 28, 2801 is the information for "Bank Account A".

[0328] As described above, according to this embodiment, it is possible to manage the status of a claim in two or more phases out of two or more phases from the creation of the claim to the point in which the creditor and debtor agree on the settlement of the claim, and to provide a platform for facilitating the settlement of the claim.

[0329] Furthermore, according to this embodiment, the content of proposals regarding debt processing can be automatically configured in accordance with negotiation information.

[0330] Furthermore, according to this embodiment, the proposed content can be appropriately presented in correspondence with negotiation information. Therefore, the other party's proposals during negotiations can be understood in detail.

[0331] Furthermore, according to this embodiment, the proposed content regarding debt processing, which corresponds to negotiation information, can be automatically configured and includes a debt processing identifier selected by the debtor.

[0332] Furthermore, according to this embodiment, online mediation for debts can be supported.

[0333] Furthermore, according to this embodiment, if negotiations for debt settlement are successful, the debtor can be presented with the information necessary for debt settlement.

[0334] Furthermore, according to this embodiment, it is possible to provide a platform that manages the status of a claim in two or more phases out of two or more phases from the creation of the claim to the point in which the creditor and debtor agree on the settlement of the claim, and that facilitates the settlement of the claim.

[0335] Furthermore, according to this embodiment, when negotiations regarding debt settlement reach an agreement, an agreement document can be automatically generated.

[0336] The processing in this embodiment may be implemented in software. This software may be distributed via software download or the like. Alternatively, this software may be recorded on a recording medium such as a CD-ROM and distributed. This also applies to other embodiments in this specification. The software that implements information system A in this embodiment is the following program.In other words, this program is a computer that can access a debt management unit which stores information relating to debt processing, information associated with a debt identifier that identifies a debt, and one or more debt status information that can identify the current phase of two or more phases from the occurrence of a debt to the creditor and debtor agreeing on the processing of the debt; a petition acquisition unit which acquires petition information having a creditor identifier that identifies a creditor, a debtor identifier that identifies a debtor, and debt content information relating to the content of the debt; a petition storage unit which stores the petition information acquired by the petition acquisition unit in the debt management unit, associating it with a debt identifier that identifies a debt associated with the petition information; a petition notification unit which acquires notification information including the creditor information identified by the creditor identifier in the petition information and the debt content information, in response to the petition acquisition unit acquiring the petition information, and transmits the notification information to the debtor; and a unit which receives confirmation information regarding the confirmation of the petition from the debtor's debtor terminal. This program causes the following to function: a confirmation receiving unit; a confirmation storage unit that, upon receiving the confirmation information from the confirmation receiving unit, acquires the confirmation information to be stored and stores the confirmation information in the debt management unit in association with the debt identifier; a negotiation receiving unit that, after receiving the confirmation information from the confirmation receiving unit, receives negotiation information relating to negotiations between the creditor and the debtor from the creditor's terminal and the debtor's terminal; a negotiation storage unit that stores the negotiation information received by the negotiation receiving unit in the debt management unit in association with a creditor identifier that identifies the creditor or a debtor identifier that identifies the debtor, and the debt identifier; an instruction receiving unit that receives an instruction to output debt status information from the creditor's terminal or the debtor's terminal; an information acquisition unit that acquires part or all of the debt status information corresponding to the output instruction from the debt management unit; and an information transmission unit that transmits part or all of the debt status information acquired by the information acquisition unit to the creditor's terminal or the debtor's terminal.

[0337] (Embodiment 2) In this embodiment, the difference from Embodiment 1 is that a virtual bank account is generated in conjunction with a debt identifier, and the account information of the virtual account is stored in conjunction with the debt identifier. Furthermore, in this embodiment, it is preferable to generate a virtual bank account only when the account conditions are met.

[0338] In this embodiment, all the processing of each device described in Embodiment 1 may be performed. Also, the claims handled in this embodiment are typically monetary claims.

[0339] In this embodiment, information system B comprises a debt management device 4, one or more creditor terminals 2, and one or more debtor terminals 3. The conceptual diagram of information system B is the same as in Figure 1, except that the reference numeral for the debt management device 4 is different.

[0340] Debt management device 4 is a server for storing information related to debts. Debt management device 4 may store information related to two or more debts, including debts where one user is the creditor and debts where that same user is the debtor. Debt management device 4 may be, for example, a cloud server or an ASP server, but the type is not limited.

[0341] The block diagram of information system A in this embodiment is the same as in Figure 2, except that the reference numerals for the debt management device 4 are different. Figure 29 is a block diagram of the debt management device 4.

[0342] The debt management device 4 comprises a storage unit 11, a receiving unit 12, a processing unit 43, and a transmission unit 44. The processing unit 43 comprises a petition storage unit 131, an update unit 132, a confirmation storage unit 133, a negotiation storage unit 134, a proposal content acquisition unit 134, a mediation support unit 135, a judgment unit 431, an agreement document generation unit 137, an information acquisition unit 138, an account generation unit 432, and an account storage unit 433. The transmission unit 44 comprises a petition notification unit 141, a screen transmission unit 142, a proposal content transmission unit 143, a negotiation information output unit 144, a necessary information transmission unit 145, an agreement document output unit 146, an information transmission unit 147, and an account transmission unit 441.

[0343] The processing unit 43, which constitutes the debt management device 4, performs various processes. These processes include, for example, those performed by the application storage unit 131, the update unit 132, the confirmation storage unit 133, the negotiation storage unit 134, the proposal content acquisition unit 134, the mediation support unit 135, the judgment unit 431, the agreement document generation unit 137, the information acquisition unit 138, the account generation unit 432, or the account storage unit 433. It is preferable for the processing unit 43 to perform all or some of the processes performed by the processing unit 13.

[0344] The determination unit 431 determines whether the information received from the creditor terminal 2 or the debtor terminal 3 matches the account conditions. The determination unit 431 may perform all or part of the processing performed by the determination unit 136. For example, it may use the negotiation information received by the negotiation receiving unit 123 to determine whether the agreement conditions have been met.

[0345] Information received from creditor terminal 2 or debtor terminal 3 may include, for example, application information, confirmation information, or negotiation information.

[0346] Account conditions are the conditions required for the account generation unit 432 to obtain account information. For example, account conditions include the fact that the claim acquisition unit 121 has obtained claim information, that negotiations have reached an agreement (that the agreement conditions have been met), and that the processing means identifier included in the received negotiation information is information indicating a "bank account".

[0347] The account generation unit 432 generates a virtual bank account in association with a debt identifier and obtains account information that identifies the virtual account. The account generation unit 432, for example, provides unique information for the debt (e.g., a debt identifier) ​​to an API that generates a virtual bank account, executes the API, and obtains account information. The account generation unit 432, for example, provides the "bank name," "bank code," "branch name," and "account holder name" to an API that generates a virtual bank account, executes the API, and obtains account information with a unique number. The "account holder name" is, for example, the name of the bank account on the operating side of the debt management device 1. The "bank name," "bank code," "branch name," and "account holder name" are stored in the storage unit 11.

[0348] Note that creating a virtual account also includes instructing the creation of a virtual account. Creating a virtual account can also be done by executing an API that creates a virtual account.

[0349] The account generation unit 432 preferably obtains account information that identifies a virtual account when the determination unit 431 determines that the account conditions are met.

[0350] The account storage unit 433 stores the account information acquired by the account generation unit 432 in the debt management unit 111, associating it with a debt identifier. It is preferable that the account information acquired by the account generation unit 432 is unique for each debt.

[0351] The transmission unit 44 transmits various types of information. These types of information include, for example, notification information, screen information, proposal details, negotiation information, account information, and agreement documents.

[0352] The account transmission unit 441 transmits the account information obtained by the account generation unit 432 to the debtor. For example, if the determination unit 431 determines that the agreement conditions have been met, the account transmission unit 441 transmits the account information to the debtor so that the debtor can process the debt.

[0353] Next, an example of the operation of the debt management device 4 will be explained using the flowcharts in Figures 30 and 5. In the flowchart of Figure 30, the explanation will be omitted for steps that are the same as those in Figure 4 or Figure 5.

[0354] (Step S3001) The determination unit 431 determines whether the received information, which corresponds to the claim identifier, satisfies the account conditions. If the account conditions are met, the unit proceeds to step S3002; otherwise, it returns to step S401.

[0355] (Step S3002) The account generation unit 432, etc., performs the account acquisition process. The process returns to step S401. An example of the account acquisition process will be explained using the flowchart in Figure 31.

[0356] In the flowchart of Figure 30, if the required information in S422 is account information, the account transmission unit 441 transmits the account information to the debtor.

[0357] Furthermore, in the flowchart of Figure 30, processing is terminated by power off or processing termination interrupt.

[0358] Next, an example of the account acquisition process in step S3002 will be explained using the flowchart in Figure 31.

[0359] (Step S3101) The account generation unit 432 obtains information such as the account holder's name from the storage unit 11. This information is necessary for opening a new virtual account. Examples of this information include the account holder's name, bank name, bank code, and branch name.

[0360] (Step S3102) The account generation unit 432 takes the account name and other information obtained in step S3101, opens a new virtual account, and passes it to the API.

[0361] (Step S3103) The account generation unit 432 executes the API.

[0362] (Step S3104) The account generation unit 432 determines whether or not it has obtained the account number, etc., by executing the API. If the account number, etc., has been obtained, it proceeds to step S3105; otherwise, it returns to step S3104.

[0363] (Step S3105) The account generation unit 432 constructs account information including the acquired account number, etc.

[0364] (Step S3106) The account storage unit 433 obtains the claim identifier of the target claim.

[0365] (Step S3107) The account storage unit 433 stores the account information configured in step S3105 in the account management unit 111, associating it with the account claim identifier obtained in step S3106.

[0366] (Step S3108) The determination unit 431 determines whether or not to send the account information to the debtor. If the account information is to be sent, the process proceeds to step S3109; otherwise, it returns to the higher-level process. Note that the account information is to be sent to the debtor only if the sending conditions are met. The sending conditions are met, for example, if the agreement conditions are met.

[0367] (Step S3109) The account transmission unit 441 transmits the account information configured in step S3105 to the debtor. It then returns to the higher-level processing.

[0368] The following describes a specific example of the operation of information system B in this embodiment. The specific example of the operation of information system B is generally the same as the specific example of the operation of information system A described in Embodiment 1, but differs in that the account generation unit 432 acquires account information that identifies a virtual account when the account conditions are met, and the account storage unit 433 stores the account information in the debt management table in pairs with the debt identifier.

[0369] In other words, the debt management unit 111 of the debt management device 4 stores a debt management table having the structure shown in Figure 32. Compared to the debt management table in Figure 14, the debt management table in Figure 32 stores account information for a virtual account that has been automatically acquired in each record. The account information is unique information that is paired with the debt identifier.

[0370] Then, as explained by the specific operation in Embodiment 1, the account information of the virtual account is transmitted to the debtor via the screen shown in Figure 28, etc.

[0371] As described above, according to this embodiment, when a claim for debt is received, a virtual bank account for the collection of said debt can be automatically established.

[0372] Furthermore, according to this embodiment, it is possible to manage the status of a claim in two or more phases out of two or more phases from the creation of the claim to the processing of the claim, and to provide a platform for facilitating the processing of the claim.

[0373] Furthermore, according to this embodiment, a bank account can be automatically established only if the account conditions are met.

[0374] Furthermore, according to this embodiment, the content of proposals regarding debt processing can be automatically configured in accordance with negotiation information.

[0375] Furthermore, according to this embodiment, negotiation information and proposal content can be presented appropriately.

[0376] Furthermore, according to this embodiment, the proposed content regarding debt processing, which corresponds to negotiation information, can be automatically configured and includes a debt processing identifier selected by the debtor.

[0377] Furthermore, according to this embodiment, online mediation for debts can be supported.

[0378] Furthermore, according to this embodiment, if negotiations for debt settlement are successful, the debtor can be presented with the information necessary for debt settlement.

[0379] The software that implements the debt management device 4 in this embodiment is as follows: This program is a computer that can access a debt management unit which stores information associated with a debt identifier that identifies a debt, and which can identify the current phase of one or more phases of debt status information from the occurrence of a debt to the agreement between the creditor and the debtor regarding the processing of the debt; an application acquisition unit which acquires application information having a creditor identifier that identifies the creditor, a debtor identifier that identifies the debtor, and debt content information regarding the content of the debt; an application storage unit which stores the application information acquired by the application acquisition unit in the debt management unit, associated with the debt identifier; and a virtual bank account associated with the debt identifier. This program functions as an account generation unit that generates and acquires account information to identify the virtual account; an account storage unit that stores the account information acquired by the account generation unit in the debt management unit in association with the debt identifier; an account transmission unit that transmits the account information to the debtor; an instruction receiving unit that receives an instruction to output debt status information from the creditor terminal or the debtor terminal; an information acquisition unit that acquires part or all of the debt status information corresponding to the output instruction from the debt management unit; and an information transmission unit that transmits part or all of the debt status information acquired by the information acquisition unit to the creditor terminal or the debtor terminal.

[0380] (Embodiment 3) In this embodiment, a debt management device that determines accounting information matching the conditions for filing a claim from an accounting management unit where accounting information is stored will be described. Note that the conditions for filing a claim may differ for each user.

[0381] In this embodiment, a debt management device is described that inquires with the user whether or not to file a claim for a debt based on accounting information that matches the claim conditions.

[0382] In this embodiment, a debt management device is described that inquires with the user whether or not to file a claim for debt based only on accounting information that matches the inquiry conditions.

[0383] In this embodiment, a receivables management device that receives payment information for receivables and stores it in the accounting management unit will be described.

[0384] In this embodiment, an account receivable management device that manages access information to an accounting management device equipped with an accounting management unit and uses said access information to access the accounting management device will be described.

[0385] Figure 33 is a conceptual diagram of information system C in this embodiment. Information system C comprises a debt management device 5, one or more creditor terminals 2, one or more debtor terminals 3, and one or more accounting management devices 6.

[0386] The debt management device 5 is a server for managing information related to debts. The debt management device 5 may manage information related to two or more debts, including debts in which one user is the creditor and debts in which that same user is the debtor. The debt management device 5 may be, for example, a cloud server or an ASP server, but its type is not limited.

[0387] The accounting management device 6 is a device that manages accounting information, which will be described later. The accounting management device 6 is, for example, a server for Yayoi Accounting (registered trademark), a server for Freee (registered trademark), or a server for Kanjo Bugyo (registered trademark). The accounting management device 6 is, for example, a cloud server or an ASP server, but the type is not limited.

[0388] Figure 34 is a block diagram of the information system C in this embodiment. Figure 35 is a block diagram of the debt management device 5.

[0389] The debt management device 5 comprises a storage unit 51, a receiving unit 52, a processing unit 53, and a transmission unit 44. The storage unit 51 comprises a debt management unit 111, a user management unit 511, and an access management unit 512. The receiving unit 52 comprises a response receiving unit 521, a confirmation receiving unit 122, a negotiation receiving unit 123, an instruction receiving unit 124, and a payment receiving unit 521. The processing unit 53 comprises a decision unit 531, an inquiry unit 532, a petition acquisition unit 533, a petition storage unit 131, an update unit 132, a confirmation storage unit 133, a negotiation storage unit 134, a proposal content acquisition unit 134, a mediation support unit 135, a judgment unit 431, an agreement document generation unit 138, an information acquisition unit 139, an account generation unit 432, an account storage unit 433, and a payment storage unit 534. The transmission unit 44 includes a petition notification unit 141, a screen transmission unit 142, a proposal content transmission unit 143, a negotiation information output unit 144, a necessary information transmission unit 145, an agreement document output unit 146, an information transmission unit 147, and an account transmission unit 441.

[0390] The accounting management device 6 includes an accounting management unit 61.

[0391] The storage unit 51, which constitutes the debt management device 5, stores various types of information. These types of information include, for example, debt status information, user information (described later), access information (described later), various screen information, various conditions, various templates, and lawyer information. The various conditions include, for example, application conditions and inquiry conditions (described later). It is preferable that the storage unit 51 stores default application conditions and default inquiry conditions. Needless to say, these conditions may also be embedded in the program.

[0392] The user management unit 511 stores one or more user information. User information refers to information about a user; a user is a person who uses the debt management device 5. In this context, a user is typically a person who could become a creditor. User information may also be creditor information. User information is associated with, for example, a user identifier. The user identifier may also be a creditor identifier. The user identifier may also be a debtor identifier. User information has one or more user attribute values. User attribute values ​​may include, for example, the creditor name, application conditions, and inquiry conditions.

[0393] The conditions for filing a claim are the conditions for filing a claim for a debt. The conditions for filing a claim are conditions related to accounting information. The conditions for filing a claim may include, for example, date conditions. The conditions for filing a claim may include, for example, date conditions and amount conditions. The conditions for filing a claim include the fact that payment for the claim has not been made. Date conditions are conditions related to dates. Date conditions may include, for example, "the payment deadline has passed," "a period of time greater than or equal to a threshold has elapsed since the payment deadline," or "a period of time greater than or equal to a threshold has elapsed since the date of the claim." Amount conditions are conditions related to the amount claimed (claim amount). Amount conditions may include, for example, "the amount claimed is greater than or equal to a threshold" or "the amount claimed is less than or equal to a threshold."

[0394] Inquiry conditions are conditions for inquiring whether or not to file a claim with a creditor if accounting information matching the claim conditions exists. Inquiry conditions include, for example, inquiry flag conditions or amount conditions. Inquiry flag conditions are conditions related to the inquiry flag. The inquiry flag is a flag that indicates whether or not to inquire. The inquiry flag can take either "inquire (e.g., "1")" or "do not inquire (e.g., "0")". Amount conditions are conditions related to the claim amount. Amount conditions include, for example, that the claim amount is less than or equal to a threshold.

[0395] The access management unit 512 stores one or more pieces of access information. Access information refers to information for accessing the accounting management device 6. Access information refers to information for accessing the accounting management device 6 used by a creditor. For example, access information may include the IP address of the accounting management device 6, the login ID and password for accessing the accounting management device 6, and API (Application Programming Interface) information for accessing the accounting management device 6. It is preferable that the access information is associated with a creditor identifier. In other words, it is preferable that the access management unit 512 stores access information for each creditor.

[0396] The receiving unit 52 receives various information and instructions from the creditor terminal 2 or the debtor terminal 3. These various information and instructions include, for example, responses, case registrations, application information, confirmation information, negotiation information, output instructions, proposal content instructions, agreement document instructions, payment schedule instructions, or payment information, as described later.

[0397] The response receiving unit 521 receives responses to inquiries from the creditor. Responses from the creditor are typically received from the creditor terminal 2. The response is an answer to an inquiry about whether or not to file a claim. The response may be, for example, "I will file a claim (e.g., "1")" or "I will not file a claim (e.g., "0")". Preferably, the response includes information to constitute the claim information. For example, the response may include the case name, claim amount, payment due date, billing address, contact information, etc.

[0398] The payment receiving unit 521 receives payment information. The payment receiving unit 521 usually receives payment information from the creditor or the debtor. Receipt from the creditor is usually from the creditor terminal 2. Receipt from the debtor is usually from the debtor terminal 3.

[0399] Payment information refers to information about payments made by debtors for receivables. Received payment information is associated with a receivable identifier. Payment information includes, for example, the payment amount, whether the payment has been completed, and the payment date.

[0400] The processing unit 53 performs various processes. These processes include, for example, those performed by the decision unit 531, the inquiry unit 532, the claim acquisition unit 533, or the payment accumulation unit 534.

[0401] The decision unit 531 determines one or more accounting information that matches the claim conditions from the accounting management unit 61, which stores one or more accounting information. The decision unit 531 usually determines accounting information that matches the claim conditions from accounting information for which payment has not been completed.

[0402] The accounting management unit 61 is usually located in an external device, the accounting management device 6, which is not part of the accounts receivable management device 5. However, the accounts receivable management device 5 may also have the accounting management unit 61.

[0403] Accounting information refers to information relating to a creditor's claim against a debtor. Accounting information includes a billing identifier and date information. For example, accounting information may include a billing source identifier and an invoice image. Accounting information may also include creditor information with a billing source identifier. Accounting information is associated with the creditor identifier. The billing identifier is, for example, the name of the billing party or the billing party's ID. The billing source identifier is, for example, the name of the billing company or the billing company's ID. The billing identifier may be the same as the debtor identifier or debtor name. The billing source identifier may be the same as the creditor identifier or creditor name. Date information refers to information that identifies a date. For example, date information may be the billing date, payment due date, or both the billing date and payment due date.

[0404] The determination unit 531, for example, determines accounting information that matches the application conditions associated with the creditor identifier from one or more accounting information items corresponding to the creditor identifier.

[0405] The decision unit 531, for example, accesses the accounting management device 6 using access information associated with the creditor identifier and determines accounting information that matches the application conditions associated with the creditor identifier.

[0406] The determination unit 531 searches, for example, one or more accounting management devices 6 and determines accounting information that matches the claim conditions.

[0407] The timing and triggers for the determination unit 531 to determine accounting information are not specified. It is preferable for the determination unit 531 to perform the process of determining accounting information periodically. The determination unit 531 may, for example, perform the process of determining accounting information at predetermined times (e.g., "12:00 on the 1st of every month", "0:00 every day", "10:00 every Monday"). The determination unit 531 may, for example, perform the process of determining accounting information when it receives instructions from the user. The timing of determining accounting information is the timing of automatic filing.

[0408] The inquiry unit 532 inquires with the creditors corresponding to each of the one or more accounting information determined by the decision unit 531 whether or not they will file a claim against the claimant regarding the accounting information. The means and timing of the inquiry are irrelevant. For example, the inquiry unit 532 sends inquiry information containing the one or more accounting information determined by the decision unit 531 to the creditor. When the creditor terminal 2 accesses the debt management device 5, the inquiry unit 532 sends inquiry information containing the one or more accounting information determined by the decision unit 531 to the creditor terminal 2.

[0409] Inquiry information refers to information used to ask creditors whether or not they wish to file a claim regarding accounting information. Inquiry information may include, for example, some or all of the accounting information.

[0410] The petition acquisition unit 533 uses the accounting information determined by the decision unit 531 to acquire petition information that includes a creditor identifier, a debtor identifier, and debt details information. The petition acquisition unit 533 acquires petition information, for example, when the response to an inquiry indicates "to file a petition." The debt details information includes, for example, the claim amount, the case name, and the payment due date as contained in the accounting information. The claim amount is the petition amount.

[0411] The petition storage unit 131 stores the petition information acquired by the petition acquisition unit 533 in the debt management unit 111, associating it with the debt identifier.

[0412] When the payment receiving unit 521 receives payment information, the payment storage unit 534 stores payment-related information in the accounting management unit 61 indicating that a payment corresponding to the payment information has been made. The payment storage unit 534 stores payment-related information in association with accounting information. The payment-related information may be part or all of the payment information, or it may be information indicating that the payment has been completed. The payment-related information may also be information for processing the reconciliation of accounting information corresponding to the payment.

[0413] The accounting management unit 61, which constitutes the accounting management device 6, stores one or more accounting information. Each of the one or more accounting information entries is associated with a billing source identifier. The billing source identifier may be the same as the creditor identifier.

[0414] The storage unit 51, user management unit 511, access management unit 512, and accounting management unit 61 are preferably made of non-volatile recording media, but can also be made of volatile recording media.

[0415] The process by which information is stored in the storage unit 51 is irrelevant. For example, information may be stored in the storage unit 51 via a recording medium, information transmitted via a communication line or the like may be stored in the storage unit 51, or information input via an input device may be stored in the storage unit 51.

[0416] The receiving unit 52, the response receiving unit 521, and the payment receiving unit 521 are usually implemented by wireless or wired communication means, but may also be implemented by means of receiving broadcasts.

[0417] The processing unit 53, decision unit 531, inquiry unit 532, claim acquisition unit 533, and payment storage unit 534 can typically be implemented using a processor, memory, etc. The processing procedures of the processing unit 53, etc., are typically implemented in software, and this software is recorded on a recording medium such as ROM. However, it may also be implemented in hardware (dedicated circuitry). The processor can be a CPU, MPU, GPU, etc., and the type is not limited.

[0418] Next, an example of the operation of the debt management device 5 will be explained using the flowcharts in Figures 36, 37, and 38. Note that in Figures 36, 37, and 38, the explanation for the same steps as in Figures 30 and 5 will be omitted. Also, here, if the result in step S439 is "N", the process proceeds to step S3601 in Figure 38.

[0419] (Step S3601) The decision unit 531 determines whether or not it is time for an automatic application. If it is time for an automatic application, proceed to step S3602; otherwise, proceed to step S3611.

[0420] (Step S3602) The decision unit 531 performs a decision process. An example of the decision process will be explained using the flowchart in Figure 39.

[0421] (Step S3603) The inquiry unit 532 assigns 1 to counter i.

[0422] (Step S3604) The inquiry unit 532 determines whether or not the i-th accounting information exists among the accounting information determined in step S3602. If the i-th accounting information exists, the unit proceeds to step S3605; otherwise, it returns to step S401.

[0423] (Step S3605) The inquiry unit 532 obtains the creditor identifier corresponding to the billing identifier corresponding to the i-th accounting information. Note that the creditor identifier may also be the billing entity identifier.

[0424] (Step S3606) The inquiry unit 532 obtains the inquiry conditions corresponding to the creditor identifier from the user management unit 511. Note that the inquiry conditions may be the same for all creditors.

[0425] (Step S3607) The inquiry unit 532 determines whether the inquiry conditions are met. If the inquiry conditions are met, the process proceeds to step S3608; otherwise, the process proceeds to step S3611.

[0426] (Step S3608) The inquiry unit 532 obtains inquiry information using the i-th accounting information.

[0427] (Step S3609) The inquiry unit 532 transmits the inquiry information obtained in step S3608 to the creditor identified by the creditor identifier obtained in step S3605. Transmission to the creditor is usually to the creditor terminal 2.

[0428] (Step S3610) The inquiry unit 532 increments counter i by 1. Return to step S3604.

[0429] (Step S3611) The claim acquisition unit 533 acquires the claim information using the i-th accounting information. Similar to the process explained using the flowchart in Figure 30, the processing unit 53 executes steps S404 to S407, then steps S3001 and S3002. Proceed to step S3610.

[0430] (Step S3612) The response receiving unit 521 determines whether or not it has received a response from the creditor to the inquiry. If a response has been received, the unit proceeds to step S3613; otherwise, it returns to step S401.

[0431] (Step S3613) The claim acquisition unit 533 determines whether the response is "to file a claim" or "not to file a claim". If the response is "to file a claim", proceed to step S3614; if the response is "not to file a claim", return to step S401.

[0432] (Step S3614) The claim acquisition unit 533 acquires accounting information corresponding to the inquiry regarding the response. The claim acquisition unit 533 uses the accounting information to acquire claim information. Proceed to step S403.

[0433] (Step S3615) The payment receiving unit 521 determines whether or not it has received payment information. If payment information has been received, the unit proceeds to step S3616; otherwise, it proceeds to step S439.

[0434] (Step S3616) The payment storage unit 534 stores payment-related information in the accounting management unit 61, indicating that a payment corresponding to the payment information received in step S3615 has been made. Return to step S401.

[0435] In the flowcharts shown in Figures 36, 37, and 38, processing is terminated by power-off or processing termination interrupts.

[0436] Next, an example of the decision process in step S3602 will be explained using the flowchart in Figure 39.

[0437] (Step S3901) The determination unit 531 assigns 1 to counter i.

[0438] (Step S3902) The determination unit 531 determines whether or not the i-th creditor exists. If the i-th creditor exists, the process proceeds to step S3903; otherwise, it returns to the higher-level process.

[0439] Furthermore, the determination unit 531 determines, for example, whether or not the i-th user information exists in the user management unit 511, thereby determining whether or not the i-th creditor exists.

[0440] (Step S3903) The determination unit 531 obtains the creditor identifier of the i-th creditor from the user management unit 511. Note that the creditor identifier may also be the user identifier.

[0441] (Step S3904) The determination unit 531 obtains access information from the access management unit 512 that corresponds to the creditor identifier of the i-th creditor.

[0442] (Step S3905) The decision unit 531 obtains the application conditions corresponding to the creditor identifier of the i-th creditor from the user management unit 511. Note that the application conditions may be common to all creditors.

[0443] (Step S3906) The decision unit 531 uses the access information obtained in step S3904 to access the accounting management unit 61 corresponding to the access information and obtains one or more accounting information from the accounting management unit 61 corresponding to the creditor identifier obtained in step S3903.

[0444] (Step S3907) The determination unit 531 assigns 1 to counter j.

[0445] (Step S3908) The determination unit 531 determines whether or not the j-th accounting information exists among the accounting information obtained in step S3906. If the j-th accounting information exists, the unit proceeds to step S3909; otherwise, the unit proceeds to step S3912.

[0446] (Step S3909) The decision unit 531 determines whether the j-th accounting information satisfies the claim conditions obtained in step S3905. If the claim conditions are met, proceed to step S3910; otherwise, proceed to step S3911.

[0447] (Step S3910) The determination unit 531 temporarily stores the j-th accounting information in a buffer (not shown) in association with the creditor identifier of the i-th creditor.

[0448] (Step S3911) The determination unit 531 increments counter j by 1. Return to step S3908.

[0449] (Step S3912) The determination unit 531 increments the counter i by 1. Return to step S3902.

[0450] The following describes a specific example of the operation of the information system C in this embodiment. The debt management unit 111 of the debt management device 5 stores, for example, a debt management table having the structure shown in Figure 32.

[0451] Furthermore, the user management unit 511 stores the user management table shown in Figure 40. The user management table is a table for managing user information. The user management table manages one or more records that have "ID," "creditor identifier," "creditor name," "email address," "filing conditions," and "inquiry conditions." "ID" is information that identifies the record.

[0452] The default claim conditions stored in storage unit 51 are "<Date Condition> Today - Payment Due Date = 1 day <Amount Condition> None". In other words, the default claim condition is "the payment due date has passed". The default claim condition does not have an amount condition. The claim condition for "ID=1" is that payment has not been received one week after the payment due date, regardless of the amount. The claim condition "-" for "ID=2" indicates that it is the default claim condition. The claim condition for "ID=3" indicates that a claim will be filed when the claim amount is greater than 80,000 yen and the payment due date has passed. Needless to say, the claim conditions also include the fact that the debtor has not made payment.

[0453] The inquiry condition "ID=1" indicates that if the claim amount is 100,000 yen or less, the creditor will be asked whether or not to file a claim with the debtor. The inquiry condition "1" for "ID=2" indicates that for claims that meet the filing conditions, the creditor will always be asked whether or not to file a claim for the claim. The inquiry condition "0" for "ID=3" indicates that for claims that meet the filing conditions, the claim will be filed with the debtor without contacting the creditor.

[0454] Furthermore, the access management unit 512 stores the access management table shown in Figure 41. The access management table is a table that manages access information. The access management table manages one or more records that have "ID", "creditor identifier", and "access information". The "access information" has "accounting management device identifier", "login ID", "password", and "API". The "API" has "search API" and "update API". The "accounting management device identifier" is information that identifies the accounting management device 6. The accounting management device identifier is, for example, the IP address of the accounting management device 6, or the URL for accessing the accounting management device 6. The "login ID" is the creditor's ID (user ID) for logging into the accounting management device 6. The "password" is the password for logging into the accounting management device 6. The "search API" is an API for searching for necessary accounting information from the accounting management device 6. The search API has definition information for one or more parameters that constitute the search conditions. The "update API" is an API for updating the accounting information of the accounting management device 6. Updating accounting information here usually involves adding payment information to the accounting information. Note that "API" refers to, for example, a function, method, or executable module.

[0455] The specific operation example of information system C in this embodiment differs from the specific operation example of information system B in embodiment 2 in that the debt management device 5 automatically acquires application information through processing by the application acquisition unit 533, etc., and that when the debt management device 5 receives payment information, it updates the accounting information of the accounting management device 6. Below, an example of the process by which the debt management device 5 automatically acquires application information through processing by the application acquisition unit 533, etc., will be explained in Specific Example 1, and an example of the process by which the debt management device 5 updates the accounting information of the accounting management device 6 when it receives payment information will be explained in Specific Example 2.

[0456] (Specific example 1) Assume that the decision unit 531 of the debt management device 5 has obtained the current time "2024 / 8 / 8 0:00" from a clock (not shown). Next, the decision unit 531 determines that it is time for automatic filing. Assume that the timing for automatic filing is "0:00" every day. Then, the decision unit 531 performs the decision process as described using the flowchart in Figure 39, as follows: The decision unit 531 obtains the creditor identifier "C01" of the first creditor from the user management table (Figure 40). The decision unit 531 also obtains the filing condition "Today - Payment due date >= 7 days" corresponding to the creditor identifier "C01" from the user management table (Figure 40).

[0457] Furthermore, the decision unit 531 obtains access information paired with the creditor identifier "C01" from the access management table (Figure 41). The decision unit 531 then uses the access information to access the accounting management device 6 "M01" corresponding to that access information and obtains a large amount of accounting information corresponding to the creditor identifier "C01".

[0458] Next, the decision unit 531, based on a large amount of accounting information, determines that one piece of accounting information, "<Case Name> Company X Unpaid <Invoice Amount> 100,000 <Payment Due Date> 2024 / 8 / 1 9:00 <Recipient Name> Company X <Contact Information> yy@x.jp <Payment Amount> 0 ...", is unpaid and satisfies the acquired claim condition "Today - Payment Due Date >= 7 days".

[0459] Next, the inquiry unit 532 retrieves the inquiry condition "claim amount <= 100,000" corresponding to the creditor identifier "C01" from the user management table (Figure 40). Then, the inquiry unit 532 determines that the inquiry condition is met based on the inquiry condition and "<claim amount> 100,000".

[0460] Next, the inquiry unit 532 constructs inquiry information using one accounting information. Next, the inquiry unit 532 obtains the email address "ta@c.com" which is paired with the creditor identifier "C01". Next, the inquiry unit 532 sends the obtained inquiry information to the email address "ta@c.com" of the creditor identified by the creditor identifier "C01".

[0461] Next, creditor "Tanaka A-ko"'s creditor terminal 2 receives and outputs the inquiry information. An example of such inquiry information is shown in Figure 42.

[0462] Suppose that creditor "Tanaka A-ko" carefully considered whether or not to file a claim and, on 2024 / 8 / 11, instructed the "File a Claim" button 4201 on the screen shown in Figure 42. Next, Tanaka A-ko's creditor terminal 2 receives this instruction. Next, creditor terminal 2 composes a response indicating "I will file a claim" and transmits this response to the debt management device 5. The composed response includes, for example, information contained in the inquiry information. Such a response may be, for example, "<Response> File a claim <Case name> X Company Nonpayment <Claim amount> 100000 <Payment due date> 2024 / 8 / 1 9:00 <Recipient name> X Company <Contact information> yy@x.jp <Payment amount> 0 ..."

[0463] Next, the response receiving unit 521 of the debt management device 5 receives the response to the inquiry from the creditor's creditor terminal 2. Next, the petition acquisition unit 533 determines from the received response that the response is "to file a petition". Next, the petition acquisition unit 533 acquires the accounting information corresponding to the inquiry corresponding to the response: "<Case name> X Company Nonpayment <Invoice amount> 100000 <Payment due date> 2024 / 8 / 1 9:00 <Billing recipient name> X Company <Contact information> yy@x.jp <Payment amount> 0 ...". The petition acquisition unit 533 acquires the current time, the time of filing, "2024 / 8 / 11 15:35", from a clock (not shown). Next, the claim acquisition unit 533 uses the accounting information to acquire the claim information "<Case Name>X Company Nonpayment <Claim Amount>100000 <Payment Due Date>2024 / 8 / 1 9:00 <Creditor Identifier>C01 <Billing Recipient>X Company <Contact Information>yy@x.jp <Time of Claim>2024 / 8 / 11 15:35 ...".

[0464] Next, the petition storage unit 131 obtains a unique claim identifier "1". Then, the petition storage unit 131 stores the obtained petition information in the claim management table (Figure 14) in conjunction with the claim identifier "1". This petition information is the petition information with "ID=1" in Figure 32. The update unit 132 also stores the phase identifier "1" in the record with "ID=1" in Figure 14.

[0465] The subsequent processing is the same as the processing described in the specific operation example of Embodiment 1 or the specific operation example of Embodiment 2.

[0466] Furthermore, the debt management device 5 continues to access the accounting information of each creditor from the second creditor onward and performs the processing described above.

[0467] (Specific example 2) Assume that the payment receiving unit 521 of the debt management device 5 received payment information "<Debt Identifier>1 <Payment Amount>20000 <Payment Date>2024 / 9 / 30", which indicates that payment has been made for the debt status information for "ID=1" in the debt management table of Figure 32, from Tanaka A's creditor terminal 2, paired with the creditor identifier "C01".

[0468] The payment storage unit 534 obtains the claim identifier "1" from the received payment information and retrieves the case name "X Company Nonpayment", the claim amount "100000", and the creditor name "X Company" from the claim management table (Figure 32) that are paired with the claim identifier "1". Next, the payment storage unit 534 uses the retrieved information to construct payment-related information indicating that payment has been made for the claim: "<Creditor Identifier>C01 <Case Name>X Company Nonpayment <Claim Amount>100000 <Recipient Name>X Company <Payment Amount>20000 <Payment Date>2024 / 9 / 30".

[0469] Next, the payment storage unit 534 obtains the update API "uf(pn,···)" which is paired with the creditor identifier "C01" from the access management table (Figure 41). Next, the payment storage unit 534 uses the configured payment-related information to substitute the information into the arguments of the API "uf(pn,···)", forming "uf(C01,X Company Non-Payment,100000,X Company,20000,2024 / 9 / 30)", and by executing this API, it adds information to the accounting information of the accounting management device 6 that manages Tanaka A's accounting information, indicating that an amount of "20000" was paid on "2024 / 9 / 30". The update API is assumed to have the structure "uf(creditor identifier, case name, billing amount, billing recipient name, payment amount, payment date)".

[0470] Through the above process, the accounts receivable management device 5 was able to update the accounting information in the accounting management device 6 upon receiving payment information for the receivables.

[0471] As described above, according to this embodiment, the accounting information to which a claim should be filed can be automatically determined from the accounting information stored in the accounting management unit.

[0472] Furthermore, according to this embodiment, the accounting information to which a claim should be filed can be automatically determined from the accounting information stored in the accounting management department, based on different conditions for each creditor.

[0473] Furthermore, according to this embodiment, when a debtor makes a payment for a claim, information regarding that payment can be stored and managed in the accounting management department.

[0474] Furthermore, according to this embodiment, by accessing two or more accounting management devices, it is possible to automatically determine, for two or more creditors, the accounting information to which a claim should be filed from the accounting information stored in the accounting management devices.

[0475] Furthermore, according to this embodiment, after automatically selecting the accounting information to which a claim should be filed from the accounting information stored in the accounting management unit, the creditor can decide whether or not to file a claim.

[0476] Furthermore, according to this embodiment, the creditor can be inquired about whether or not to file a claim only when an inquiry is necessary.

[0477] Furthermore, according to this embodiment, depending on the creditor, it is possible to inquire whether or not to file a claim with the creditor under different conditions.

[0478] Furthermore, according to this embodiment, it is possible to manage the status of a claim in two or more phases out of two or more phases from the creation of the claim to the processing of the claim, and to provide a platform for facilitating the processing of the claim.

[0479] Furthermore, according to this embodiment, a bank account for debt collection can be automatically established.

[0480] Furthermore, according to this embodiment, a bank account can be automatically established only if the account conditions are met.

[0481] Furthermore, according to this embodiment, the content of proposals regarding debt processing can be automatically configured in accordance with negotiation information.

[0482] Furthermore, according to this embodiment, negotiation information and proposal content can be presented appropriately.

[0483] Furthermore, according to this embodiment, the proposed content regarding debt processing, which corresponds to negotiation information, can be automatically configured and includes a debt processing identifier selected by the debtor.

[0484] Furthermore, according to this embodiment, online mediation for debts can be supported.

[0485] Furthermore, according to this embodiment, if negotiations for debt settlement are successful, the debtor can be presented with the information necessary for debt settlement.

[0486] Furthermore, according to this embodiment, when negotiations regarding debt settlement reach an agreement, an agreement document can be automatically generated.

[0487] The software that implements the debt management device 5 in this embodiment is the following program. In other words, this program is a program that enables a computer to access a debt management unit, which stores information associated with a debt identifier that identifies a claim, and which can identify the current phase of one or more phases from the creation of a claim to the agreement between the creditor and the debtor regarding the processing of the claim. The computer is configured to function as follows: a determination unit that determines accounting information that matches the claim conditions from an accounting management unit which stores one or more accounting information having a billing identifier that identifies the billing party, a billing amount, and date information that identifies the date of the claim; a claim acquisition unit that uses the accounting information determined by the determination unit to acquire claim information having a creditor identifier that identifies the creditor, a debtor identifier that identifies the debtor, and claim content information regarding the content of the claim; a claim storage unit that stores the claim information acquired by the claim acquisition unit in the debt management unit, associated with the debt identifier; an instruction receiving unit that receives an instruction to output debt status information from the creditor terminal or the debtor terminal; an information acquisition unit that acquires part or all of the debt status information corresponding to the output instruction from the debt management unit; and an information transmission unit that transmits part or all of the debt status information acquired by the information acquisition unit to the creditor terminal or the debtor terminal.

[0488] Figure 43 is a block diagram of a computer system 300 that executes the program described herein to realize the various embodiments of the debt management device 5 described above.

[0489] In Figure 43, the computer system 300 includes a computer 301 with a CD-ROM drive, a keyboard 302, a mouse 303, and a monitor 304.

[0490] In Figure 43, the computer 301 includes, in addition to the CD-ROM drive 3012, an MPU 3013, a bus 3014 connected to the CD-ROM drive 3012, a ROM 3015 for storing programs such as boot-up programs, a RAM 3016 connected to the MPU 3013 for temporarily storing instructions for application programs and providing temporary storage space, and a hard disk 3017 for storing application programs, system programs, and data. Although not shown here, the computer 301 may further include a network card for providing connectivity to a LAN.

[0491] The program that causes the computer system 300 to execute the functions of the debt management device 5, etc., as described above, may be stored on the CD-ROM 3101, inserted into the CD-ROM drive 3012, and then transferred to the hard disk 3017. Alternatively, the program may be transmitted to the computer 301 via a network (not shown) and stored on the hard disk 3017. The program is loaded into the RAM 3016 when executed. The program may also be loaded directly from the CD-ROM 3101 or the network.

[0492] The program does not necessarily have to include an operating system (OS) or third-party program that causes the computer 301 to execute functions such as the debt management device 5 of the above-described embodiment. The program only needs to include the instruction portion that calls appropriate functions (modules) in a controlled manner and obtains the desired result. How the computer system 300 operates is well known, so a detailed explanation is omitted.

[0493] In the above program, steps such as sending information and receiving information do not include hardware-based processing, such as processing performed by a modem or interface card in the transmission step (processing that can only be performed by hardware).

[0494] Furthermore, the computer running the above program may be a single computer or multiple computers. In other words, it may perform centralized processing or distributed processing.

[0495] Furthermore, it goes without saying that in each of the above embodiments, two or more communication means present in a single device may be physically implemented in a single medium.

[0496] Furthermore, in each of the above embodiments, each process may be implemented by centralized processing by a single device, or by distributed processing by multiple devices.

[0497] It goes without saying that the present invention is not limited to the embodiments described above, and various modifications are possible, all of which are also included within the scope of the present invention. [Industrial applicability]

[0498] As described above, the debt management device 5 according to the present invention has the effect of automatically determining the accounting information to which a debt claim should be filed from the accounting information stored in the accounting management unit 61, and is useful as a server for managing debts. [Explanation of Symbols]

[0499] C Information Systems 2. Creditor terminal 3. Debtor's terminal 5. Debt Management System 6. Accounting Management System 44 Transmitter 51 Storage Unit 52 Receiving section 53 Processing Unit 61 Accounting Management Department 111 Debt Management Department 122 Confirmation Receiving Unit 123 Negotiation Reception Department 124 Instruction receiving unit 131 Petitions Collection Department 132 Update Department 133 Verification and Storage Unit 134 Proposal content acquisition department 134 Negotiation Accumulation Department 135 Mediation Support Department 138 Agreement Document Generation Department 139 Information Acquisition Department 141. Notification of Petition Department 142 Screen transmission unit 143 Proposal Submission Section 144 Negotiation Information Output Unit 145 Required Information Transmission Unit 146 Agreement Document Output Section 147 Information Transmission Section 431 Judgment Department 432 Account Generation Department 433 Account Accumulation Department 441 Account Transmission Department 511 User Management Department 512 Access Management Department 521 Response Receiving Section 521 Payment Receiving Department 531 Decision Section 532 Inquiry Department 533 Petition Acquisition Department 534 Payment Accumulation Department

Claims

1. A determination unit that retrieves the claim conditions, which are conditions for filing a claim and are conditions relating to accounting information, from a storage unit that stores the claim conditions, and from an accounting management unit that stores one or more accounting information having a claimant identifier that identifies the claimant, a claim amount, and date information that identifies the date of the claim, determines accounting information that has not been paid and matches the claim conditions, A petition acquisition unit acquires petition information having a creditor identifier associated with the accounting information determined by the determination unit, a debtor identifier which is the billing recipient identifier in the accounting information, and debt information having the billing amount in the accounting information. A claim storage unit stores the claim information acquired by the claim acquisition unit in association with a claim identifier, and the claim storage unit stores one or more claim status information that is associated with a claim identifier that identifies a claim, and which can identify the current phase of one or more phases from the creation of the claim to the agreement between the creditor and the debtor regarding the processing of the claim. An instruction receiving unit receives an instruction to output debt status information from a creditor terminal or debtor terminal, and the instruction is associated with a debt identifier. An information acquisition unit that acquires some or all of the debt status information identified by the debt identifier corresponding to the output instruction from the debt management unit, A debt management device comprising: an information transmission unit that transmits part or all of the debt status information acquired by the information acquisition unit to the creditor terminal or the debtor terminal.

2. The system further comprises a user management unit that stores two or more user information entries having application conditions corresponding to a creditor identifier, The aforementioned determination unit, The debt management device according to claim 1, which determines accounting information that matches the claim conditions associated with the creditor identifier from one or more accounting information corresponding to the creditor identifier.

3. A payment receiving unit that receives payment information indicating payment from the debtor for the aforementioned claim, The debt management device according to claim 1, further comprising: a payment storage unit which stores in the accounting management unit payment-related information indicating that a payment corresponding to the payment information has been made when the payment receiving unit receives the payment information.

4. The system further comprises an access management unit which stores access information for accessing an accounting management device having an accounting management unit, associated with two or more creditor identifiers, The aforementioned determination unit, The debt management device according to claim 1, which accesses the accounting management device using the access information associated with the creditor identifier and determines accounting information that matches the claim conditions associated with the creditor identifier.

5. An inquiry unit inquires with the creditor corresponding to the accounting information determined by the decision unit whether or not to file a claim against the claimant, A response receiving unit that receives responses from the creditor to inquiries made by the aforementioned inquiry unit, The debt management device according to claim 1, further comprising: a response receiving unit which, upon receiving a response indicating that it will file a claim, acquires notification information which includes the creditor information identified by the creditor identifier in the claim information and the claim details information, and transmits the notification information to the debtor.

6. The aforementioned inquiry section, The debt management device according to claim 5, which determines whether or not to make the inquiry to the aforementioned claimant regarding whether or not to file a claim against the aforementioned claimant, and only if it is determined that the inquiry should be made, it inquires with the aforementioned claimant whether or not to file a claim against the aforementioned claimant.

7. The inquiry conditions are stored in association with the creditor identifier. The aforementioned inquiry section, The debt management device according to claim 6, which obtains the inquiry conditions associated with the creditor identifier, determines whether the inquiry conditions are met, and only if it is determined that the inquiry conditions are met, inquires with the claimant whether or not to file a claim.

8. A confirmation receiving unit that receives confirmation information regarding the confirmation of the claim from the debtor's debtor terminal, The debt management device according to claim 1, further comprising: a confirmation storage unit that acquires confirmation information to be stored in response to the confirmation receiving unit receiving the confirmation information, and stores the confirmation information in the debt management unit in association with the debt identifier.

9. After the confirmation receiving unit receives the confirmation information, the negotiation receiving unit receives negotiation information for extinguishing the claim from the creditor's terminal and the debtor's terminal. The debt management device according to claim 8, further comprising a negotiation storage unit that stores the negotiation information received by the negotiation receiving unit in the debt management unit, associating it with a creditor identifier that identifies the creditor or a debtor identifier that identifies the debtor, and the debt identifier.

10. An account generation unit generates a virtual bank account in association with the aforementioned claim identifier and obtains account information that identifies the virtual account, An account storage unit that stores the account information acquired by the account generation unit in the account management unit in association with the account identifier, The debt management device according to claim 1, further comprising an account transmission unit for transmitting the account information to the debtor.

11. The system further comprises a determination unit that determines whether the information received from the creditor terminal or the debtor terminal meets the account conditions, which are the conditions for obtaining the account information. The account generation unit, The debt management device according to claim 10, which acquires account information that identifies the virtual account when the determination unit determines that the account conditions are met.

12. When the negotiation information received by the negotiation receiving unit matches the conditions for creating the proposal content, the proposal content acquisition unit acquires the creditor information and the debtor information from the debt management unit, and acquires the proposal content which is information including the creditor information and the debtor information, information including the content of the negotiation information, and information indicating a proposal regarding the processing of the debt. The debt management device according to claim 9, further comprising a proposal content transmission unit that transmits the proposal content acquired by the proposal content acquisition unit to the creditor terminal or the debtor terminal.

13. The aforementioned proposal content transmission unit is: The debt management device according to claim 12, which transmits the proposal content such that the negotiation information received by the negotiation receiving unit corresponds to the proposal content acquired by the proposal content acquisition unit.

14. The system further comprises a screen transmission unit that, after the confirmation receiving unit has received the confirmation information, transmits screen information to the debtor's terminal to allow the debtor to select one of two or more methods for processing the debt, The aforementioned negotiation receiving unit, The negotiation information, which includes a debt processing identifier that identifies one of the two or more methods of debt processing, is received from the debtor terminal. The aforementioned proposal content acquisition unit is: The debt management device according to claim 12, which obtains the creditor information and the debtor information from the debt management unit, and obtains the proposed content which includes the creditor information and the debtor information and corresponds to the debt processing identifier.

15. The debt management device according to claim 14, further comprising a mediation support unit that performs mediation support processing to assist a group including the creditor and the debtor in conducting mediation online when the negotiation receiving unit receives the negotiation information, including the debt processing identifier indicating online mediation, from the debtor terminal.

16. A determination unit that uses the negotiation information received by the negotiation receiving unit to determine whether or not the agreement conditions have been met, The debt management device according to claim 9, further comprising: a determination unit that determines that the agreement conditions have been met, and a necessary information transmission unit that transmits necessary information to the debtor, which is information necessary for the debtor to process the debt.

17. The debt management device according to claim 9, further comprising a negotiation information output unit that outputs two or more pieces of negotiation information received by the negotiation receiving unit in the order in which they were received, and in a manner that allows it to determine whether the identifier associated with the negotiation information is a creditor identifier or a debtor identifier.

18. When the negotiation information received by the negotiation receiving unit satisfies the agreement conditions, the agreement document generation unit generates an agreement document using the negotiation information, The debt management device according to claim 9, further comprising: an agreement document output unit that outputs the agreement document generated by the agreement document generation unit.

19. The aforementioned claim status information includes phase identification information that allows for the identification of the current phase among two or more phases from the creation of a claim to the processing of the claim. The debt management device according to claim 5, further comprising an update unit that updates phase identification information associated with the debt identifier in response to the notification unit transmitting the notification information to the debtor.

20. A debt management method that causes a computer to perform all the processing performed by the debt management device described in any one of Claims 1 to 19.

21. A program for causing a computer to function as a debt management device according to any one of claims 1 to 19.

Images