Negotiation support device, negotiation support method, and program

Abstract

Traditionally, there has been no platform that provides multi-stage support for activities related to the processing of claims and other related matters. [Solution] A negotiation support device 8 can provide a platform that supports the processing of applications in multiple stages, comprising: an application notification unit 741 that acquires notification information including information of the applicant and information of the application, and uses the notification information to process a notification to the respondent, the application notification unit 741 includes a first notification means 7411 that, in response to the acquisition of application information, processes a first notification to notify the debtor of the first notification information from the first entity, which is first notification information including information of the applicant and information of the application, and a second notification means 7412 that, after the first notification means 7411 has processed the first notification, processes a second notification to notify the respondent of the second notification information from the second entity, which is second notification information including information of the applicant identified by an applicant identifier in the application information and information of the application.

Description

Technical Field

[0004] , , , , , ,

[0006] , , , , , ,

[0005] , , , , , , ,

[0001] The present invention relates to a negotiation support device and the like for supporting negotiations regarding an application from an applicant. In particular, the present invention relates to a negotiation support device and the like for supporting activities for the processing of claims.

[0002] Here, the application is, for example, the resolution of various disputes including the processing of claims. The application is usually a claim by an applicant against a respondent. The applicant is the person who makes the claim. The respondent is the party against whom the claim is made. The application only needs to be the subject of negotiation. The various disputes are, for example, disputes regarding the handover of a building, disputes regarding an increase in the rent of a building, negotiations regarding retirement benefits, disputes regarding the conditions at the time of retirement, etc. The disputes may also be called disputes, conflicts, etc.

Background Art

[0003] Conventionally, there has been a system (see Patent Document 1) that enables a card issuer or other electronic payment provider to obtain a quick and desirable efficient solution to a dispute with a customer's franchise.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, conventionally, there has been no platform that supports activities for the processing of claims in multiple stages.

Means for Solving the Problems

[0006] The negotiation support device of the first invention includes: an application acquisition unit that acquires application information having an application identifier that identifies the application, a respondent identifier that identifies the respondent, and application content information relating to the content of the application; an application storage unit that stores the application information acquired by the application acquisition unit in association with the application identifier that identifies the application, in an application management unit that stores one or more application status information including the application information, which is information associated with the application identifier that identifies the application; and a notification process that acquires notification information including information of the application identified by the application identifier in the application information and application content information, and uses the notification information to notify the respondent. The negotiation support device comprises a petition notification unit, the petition notification unit having obtained petition information, first notification means for performing first notification processing to notify the respondent of first notification information from a first entity, which includes petitioner information identified by petitioner identifiers in the petition information and petition content information, in response to the petition acquisition unit obtaining petition information, and second notification means for performing second notification processing to notify the respondent of second notification information from a second entity different from the first entity, which includes petitioner information identified by petitioner identifiers in the petition information and petition content information, after the first notification means has performed first notification processing.

[0007] This configuration allows for support in processing applications at least in two stages.

[0008] Furthermore, the negotiation support device of the second invention, in contrast to the first invention, comprises a third notification means which performs a third notification process to notify the respondent of the third notification information, which is a third notification information that includes the applicant's information identified by the applicant identifier in the application information and the application content information, after the second notification means has performed the second notification process, and is from a third entity different from the first and second entities.

[0009] This structure allows for support in processing applications in at least three stages.

[0010] Furthermore, the negotiation support device of this third invention further comprises a transition determination unit that determines whether or not a transition condition, which is a condition for changing the entity that notifies the notification information, has been met, compared to the first invention, and the second notification means is a negotiation support device that performs a second notification process when the transition determination unit determines that the transition condition has been met.

[0011] With this configuration, the multi-stage activities for processing the application can be advanced to the next stage when the transition conditions are met.

[0012] Furthermore, the negotiation support device of this fourth invention is a negotiation support device in which, with respect to any one of the first to third inventions, the first subject is the applicant and the first notification process is a process for the company to make a request.

[0013] This configuration allows for multi-stage support of activities related to processing applications.

[0014] Furthermore, the negotiation support device of the fifth invention, in relation to the fourth invention, is a negotiation support device in which the second entity is the agent of the petitioner.

[0015] This configuration allows for support in processing applications at least in two stages.

[0016] Furthermore, in relation to the second invention, the negotiation support device of this sixth invention is such that the third entity is the negotiation support device, and the third notification process is the negotiation support device which is a process for mediation.

[0017] This structure allows for support in processing applications in at least three stages.

[0018] In addition, the negotiation support device of the seventh invention further includes a negotiation reception unit that receives negotiation information regarding the negotiation between the applicant and the respondent from the applicant's applicant terminal and the respondent's respondent terminal with respect to the second invention, and a determination unit that determines whether or not the agreed conditions are satisfied using the negotiation information received by the negotiation reception unit. The transition condition is a condition regarding the period after the first notification means performs the first notification process until the determination unit does not determine that the agreed conditions are satisfied. The negotiation support device is as described above.

[0019] With such a configuration, for the multi-stage activities for the application process, when the transition conditions regarding the period until an agreement is reached are satisfied, the next stage can be entered.

[0020] In addition, the negotiation support device of the eighth invention further includes a negotiation reception unit that receives negotiation information regarding the negotiation between the applicant and the respondent from the applicant's applicant terminal and the respondent's respondent terminal with respect to the second invention. The transition condition is a condition regarding the negotiation information. The negotiation support device is as described above.

[0021] With such a configuration, for the multi-stage activities for the application process, when the transition conditions regarding the negotiation information are satisfied, the next stage can be entered.

Effect of the Invention

[0022] According to the negotiation support device of the present invention, a platform that supports the activities for the application process in multiple stages can be provided.

Brief Description of the Drawings

[0023] [Figure 1] Conceptual diagram of the information system A in Embodiment 1 [Figure 2] Block diagram of the same information system A [Figure 3] Block diagram of the claim management device 1 [Figure 4] Flowchart for explaining an operation example of the claim management device 1 [Figure 5] Flowchart for explaining an operation example of the claim 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] Figure 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] Figure showing an example of the same output screen. [Figure 26] This figure shows an example of the output of the payment schedule. [Figure 27] Figure showing an example of the same output screen. [Figure 28] Figure 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 debt management device 7 in Embodiment 4 [Figure 44] A flowchart illustrating an example of the operation of the debt management device 7. [Figure 45] A flowchart illustrating an example of the operation of the debt management device 7. [Figure 46] A flowchart illustrating an example of the operation of the debt management device 7. [Figure 47] A flowchart illustrating an example of the first notification process. [Figure 48] A flowchart illustrating an example of the same transition process. [Figure 49] A flowchart illustrating an example of the second notification process. [Figure 50]A flowchart illustrating an example of the third notification process. [Figure 51] A flowchart illustrating an example of the same transition decision process. [Figure 52] A diagram showing an example of the creditor management table. [Figure 53] A diagram showing an example of the debt management table. [Figure 54] A diagram showing an example of the first notification information. [Figure 55] A diagram showing an example of the printed third-party notification information. [Figure 56] Block diagram of information system E in Embodiment 5 [Figure 57] Block diagram of the negotiation support device 8 [Figure 58] A flowchart illustrating an example of the operation of the negotiation support device 8. [Figure 59] A flowchart illustrating an example of the operation of the negotiation support device 8. [Figure 60] A flowchart illustrating an example of the operation of the negotiation support device 8. [Figure 61] Block diagram of the computer system in the above embodiment [Modes for carrying out the invention]

[0024] 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.

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

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

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

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

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

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.).

[0057] 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).

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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."

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

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

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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".

[0084] 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".

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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®.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

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

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] Here, output is a concept that typically 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 transfer of processing results to other processing devices or other programs.

[0117] 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.

[0118] 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.

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

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

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

[0132] (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.

[0133] (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.

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

[0135] (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.

[0136] (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.

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

[0138] (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.

[0139] (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.

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

[0141] (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".

[0142] (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.

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

[0144] (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.

[0145] (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.

[0146] (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.

[0147] (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.

[0148] (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.

[0149] (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.

[0150] (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.

[0151] (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.

[0152] (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.

[0153] (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.

[0154] (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.

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

[0156] (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.

[0157] (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.

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

[0159] (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.

[0160] (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.

[0161] (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.

[0162] (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.

[0163] (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.

[0164] (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.

[0165] (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.

[0166] (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.

[0167] (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.

[0168] (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.

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

[0170] (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.

[0171] 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.

[0172] (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.

[0173] (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.

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

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

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

[0177] (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.

[0178] (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.

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

[0180] (Step S605) The petition notification section 141 substitutes the debtor's information into the variable that is to be substituted with the debtor's information in the notification information template.

[0181] (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.

[0182] (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.

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

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

[0185] 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.

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

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

[0188] (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.

[0189] (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.

[0190] (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.

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

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

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

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

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

[0196] (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.

[0197] (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.

[0198] (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.

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

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

[0201] (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.

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

[0203] (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.

[0204] (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.

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

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

[0207] (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.

[0208] (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.

[0209] (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.

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

[0211] (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.

[0212] (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.

[0213] (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.

[0214] (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.

[0215] (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.

[0216] (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).

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

[0218] (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.

[0219] (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.

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

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

[0222] (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.

[0223] (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.

[0224] (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.

[0225] (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.

[0226] (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.

[0227] (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.

[0228] (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.

[0229] (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.

[0230] (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.

[0231] (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.

[0232] (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.

[0233] (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.

[0234] (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.

[0235] (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.

[0236] (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.

[0237] (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.

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

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

[0240] (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.

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

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

[0243] (Step S1104) The debtor processing unit 33 obtains the debt identifier associated with the notification information. The debtor transmission unit 34 transmits confirmation information, etc., associated with the debt identifier to the debt management device 1. The process returns to step S1101.

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

[0245] (Step S1106) The debtor processing unit 33 obtains a debt identifier corresponding to the screen for inputting an output instruction. The debtor transmission unit 34 transmits the output instruction to the debt management device 1, associating it with the debt identifier.

[0246] (Step S1107) The debtor receiving unit 35 determines whether or not it has received output information. If it has received output information, it proceeds to step S1109; otherwise, it returns to step S1107.

[0247] (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. The process returns to step S1101.

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

[0249] (Step S1110) The debtor processing unit 33 acquires the claim identifier associated with the screen for inputting negotiation information. The debtor transmission unit 34 transmits the negotiation information received in Step S1109 to the claim management device 1 in association with the claim identifier. Return to Step S1101.

[0250] (Step S1111) The debtor reception unit 32 determines whether a screen output instruction has been received. If a screen output instruction has been received, proceed to Step S1112; if not, proceed to Step S1115.

[0251] (Step S1112) The debtor processing unit 33 acquires the claim identifier. The debtor transmission unit 34 transmits the screen output instruction received in Step S1111 to the claim management device 1 in association with the claim identifier.

[0252] (Step S1113) The debtor reception unit 35 determines whether screen information has been received from the claim management device 1. If screen information has been received, proceed to Step S1114; if not, return to Step S1113.

[0253] (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. Return to Step S1101.

[0254] (Step S1115) The debtor reception unit 32 determines whether other instructions have been received. If other instructions have been received, proceed to Step S1116; if not, return to Step S1101.

[0255] (Step S1116) The debtor processing unit 33 acquires the claim identifier. The debtor transmission unit 3 transmits the instructions received in Step S1115 to the claim management device 1 in association with the claim identifier.

[0256] (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.

[0257] (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. The process returns to step S1101.

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

[0259] 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.

[0260] 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.

[0261] 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.

[0262] 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.

[0263] The storage unit 11 of the debt management device 1 stores a template of the proposed content for each debt processing means identifier (Figure 15). The storage unit 11 of the debt management device 1 also stores a template of the agreement document for each debt processing means identifier (Figure 16). In the template of the proposed content and the template of the agreement document, the strings enclosed in "<" and ">" are variables. The information in the variables is replaced to form the proposed content. The variable <debtor name> is placed in place of the debtor name, and the variable <creditor name> is placed in place of the creditor name.

[0264] In the above circumstances, Tanaka A, who has registered creditor information in debt management device 1, logged into debt management device 1 using creditor terminal 2.

[0265] Then, through the actions of Tanaka A, creditor terminal 2 received screen information for filing a claim from debt management device 1 and output the case registration screen shown in Figure 17.

[0266] Next, Tanaka A entered information into each field on the screen shown in Figure 17, such as "Petition Name," "Petition Amount," and "Payment Due Date," and then clicked the "Submit Petition" button 1701.

[0267] Next, the creditor reception unit 22 of the creditor terminal 2 accepts the case registration in accordance with the instructions of button 1701. The case registration has the following claim information: "<Claim 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". Next, the creditor transmission unit 24 transmits the case registration to the debt management device 1. The creditor identifier "C01" is, for example, stored in the creditor storage unit 21.

[0268] 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.

[0269] 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".

[0270] 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.

[0271] 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".

[0272] 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".

[0273] 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.

[0274] The debtor terminal 3 receives the screen information and outputs a determination screen for the claim processing identifier (FIG. 20). The screen of FIG. 20 has the past history 2001 for claim processing and buttons 2002 corresponding to each candidate of the seven claim processing identifiers.

[0275] And let's assume that Yamada Yuko instructed button 2003 from FIG. 20. Also, let's assume that Yamada Yuko entered the divided amount "5000 yen" to be inquired about by pressing button 2003. Then, the debtor reception unit 32 of the debtor terminal 3 receives the negotiation information "<claim processing identifier>3 <divided amount>5000". The debtor processing unit 33 acquires the claim identifier "1" and constructs the negotiation information to be transmitted "<claim identifier>1 <claim processing identifier>3 <divided amount>5000". Next, the debtor transmission unit 34 transmits the negotiation information to the claim management device 1.

[0276] Next, the negotiation reception unit 123 of the claim management device 1 receives the negotiation information from the debtor terminal 3. Next, the negotiation accumulation unit 134 acquires the claim identifier "1" from the received negotiation information. Also, the negotiation accumulation unit 134 acquires the negotiation time "2024 / 8 / 11 16:01", which is the current date and time, from a clock (not shown). Also, the negotiation accumulation unit 134 detects that the claim processing identifier "3" (installment payment) is involved, acquires the claim amount "100000 yen" and the divided amount "5000 yen" that are paired with the claim identifier "1", and acquires the payment start date, payment end date, and the payment amount for each month (acquires the payment schedule), and accumulates them in pairs with the claim identifier "1". The payment schedule is accumulated in FIG. 14 but is not shown.

[0277] Next, the proposal content acquisition unit 135 determines that the claim processing identifier "3" included in the received negotiation information meets the proposal content creation conditions. Then, the proposal content acquisition unit 135 constructs the proposal content by the process described using the flowchart of FIG. 7. Next, the proposal content acquisition unit 135 accumulates the constructed proposal content in the claim management table (FIG. 14) in association with the negotiation information. Such proposal content is the file "P1".

[0278] 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.

[0279] 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.

[0280] 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.

[0281] 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.

[0282] 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.

[0283] 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).

[0284] 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."

[0285] 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".

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

[0287] 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.

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

[0289] 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.

[0290] 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.

[0291] 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).

[0292] 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.

[0293] 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.

[0294] 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".

[0295] 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".

[0296] 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.

[0297] 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.

[0298] 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.

[0299] 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.

[0300] 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.

[0301] 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.

[0302] 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".

[0303] 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."

[0304] 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".

[0305] 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.

[0306] 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".

[0307] 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.

[0308] Furthermore, according to this embodiment, proposals regarding debt processing can be automatically configured based on negotiation information.

[0309] 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.

[0310] 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.

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

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

[0313] 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.

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

[0315] 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.

[0316] (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.

[0317] 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.

[0318] 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.

[0319] 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.

[0320] 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.

[0321] 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.

[0322] 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.

[0323] 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.

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

[0325] 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".

[0326] 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.

[0327] 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.

[0328] 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.

[0329] 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.

[0330] 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.

[0331] 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.

[0332] 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.

[0333] (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.

[0334] (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.

[0335] 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.

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

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

[0338] (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.

[0339] (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.

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

[0341] (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.

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

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

[0344] (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.

[0345] (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.

[0346] (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.

[0347] 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.

[0348] 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.

[0349] 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.

[0350] 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.

[0351] 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.

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

[0353] Furthermore, according to this embodiment, proposals regarding debt processing can be automatically configured based on negotiation information.

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

[0355] 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.

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

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

[0358] 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.

[0359] (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.

[0360] 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.

[0361] 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.

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

[0363] 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.

[0364] 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.

[0365] 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.

[0366] 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.

[0367] 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.

[0368] 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.

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

[0370] 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.

[0371] 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.

[0372] 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."

[0373] 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.

[0374] 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.

[0375] 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.

[0376] The response receiving unit 521 receives responses from the creditor to inquiries. 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.

[0377] 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.

[0378] 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.

[0379] 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.

[0380] 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.

[0381] 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.

[0382] 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.

[0383] 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.

[0384] 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.

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

[0386] 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.

[0387] 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.

[0388] 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.

[0389] 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.

[0390] 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.

[0391] 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.

[0392] 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.

[0393] 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.

[0394] 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.

[0395] 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.

[0396] 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.

[0397] 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 of 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.

[0398] (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.

[0399] (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.

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

[0401] (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.

[0402] (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.

[0403] (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.

[0404] (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.

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

[0406] (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.

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

[0408] (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.

[0409] (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.

[0410] (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.

[0411] (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.

[0412] (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.

[0413] (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.

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

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

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

[0417] (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.

[0418] 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.

[0419] (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.

[0420] (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.

[0421] (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.

[0422] (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.

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

[0424] (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.

[0425] (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.

[0426] (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.

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

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

[0429] 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.

[0430] 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.

[0431] 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.

[0432] 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.

[0433] 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.

[0434] 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.

[0435] (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).

[0436] 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".

[0437] 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".

[0438] 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".

[0439] 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".

[0440] 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.

[0441] 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 ..."

[0442] 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 ...".

[0443] 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.

[0444] 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.

[0445] 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.

[0446] (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".

[0447] 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".

[0448] 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)".

[0449] 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.

[0450] 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.

[0451] 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.

[0452] 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.

[0453] 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.

[0454] 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.

[0455] Furthermore, according to this embodiment, it is possible to inquire whether or not to file a claim with the creditor only when an inquiry is necessary.

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

[0457] 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.

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

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

[0460] Furthermore, according to this embodiment, proposals regarding debt processing can be automatically configured based on negotiation information.

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

[0462] 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.

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

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

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

[0466] 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.

[0467] (Embodiment 4) In this embodiment, a debt management device is described that sequentially and in multiple stages requests for debt settlement from entities with different positions. Note that "multiple stages" refers to, for example, two or three stages, but may also refer to four or more stages. The entities are, for example, the creditor (principal), a lawyer (agent), or a system (debt management device 7, described later).

[0468] In this embodiment, we will describe a debt management device that, when the transition condition is met in the nth stage activity for debt processing, proceeds to the (n+1)th stage activity. Note that the activity is an activity for debt processing.

[0469] Information system D comprises a debt management device 7, one or more creditor terminals 2, and one or more debtor terminals 3. The conceptual diagram of information system D in this embodiment is the same as in Figure 1, except that the reference numerals for the debt management device are different.

[0470] Figure 43 is an example of a block diagram of the debt management device 7 that constitutes the information system D in this embodiment. The debt management device 7 of the information system D may include all or part of the components of any of the debt management devices 1, 4, or 5.

[0471] The debt management device 7 comprises a storage unit 71, a receiving unit 72, a processing unit 73, and a transmission unit 74. The storage unit 71 comprises a debt management unit 711. The receiving unit 72 comprises a petition acquisition unit 121, a confirmation receiving unit 122, a negotiation receiving unit 123, an instruction receiving unit 124, and a transition instruction receiving unit 721. The processing unit 73 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 135, a mediation support unit 136, a judgment unit 137, an agreement document generation unit 138, an information acquisition unit 139, and a transition judgment unit 731. The transmission unit 74 comprises a petition notification unit 741, 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.

[0472] The petition notification section 741 here comprises a first notification means 7411, a second notification means 7412, and a third notification means 7413. However, the petition notification section 741 may also comprise only the first notification means 7411 and the second notification means 7412. Furthermore, the petition notification section 741 may also comprise a fourth or subsequent notification means.

[0473] The storage unit 71, which constitutes the debt management device 7, 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.

[0474] The various conditions include, for example, one or more transition conditions, proposal content creation conditions, and agreement conditions, which will be described later. These conditions may also be embedded within the program.

[0475] Here, "lawyer information" refers to information about a lawyer acting as a creditor's representative, or information about a lawyer assisting with 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 registration number, or lawyer ID. The lawyer contact information is information that indicates how to contact the lawyer. For example, the lawyer contact information may be the lawyer's email address, lawyer's phone number, or the ID the lawyer uses to log in to the debt management system 7.

[0476] The debt management unit 711 stores one or more debt status information. Debt status information refers to information about a debt. In this embodiment, debt status information identifies the current stage in the multi-stage activities for processing the debt. In each of the two or more stages, a different entity is responsible for prompting or negotiating the activities for processing the debt. Note that a different entity usually means a different entity is responsible for notifying the debtor.

[0477] In this embodiment, the debt status information is, for example, information that can identify the current phase among two or more phases from the creation of the debt to agreement. The debt status information may also be information that can identify the current phase among two or more phases from the filing of the claim to agreement. In this embodiment, a phase refers to a specific state or period in the progress of processing related to a debt, from the creation of the debt to agreement or breakdown, etc. A phase may also be called a step, stage, etc. In this embodiment, a phase is not the stage described above.

[0478] The debt status information here includes information that identifies the stage. This information includes, for example, a stage identifier that identifies the stage, and a subject identifier that identifies the entity that initiates or negotiates activities for the processing of the debt. The stage identifier may be the same information as the subject identifier. In other words, the subject may be determined once the stage is determined. Examples of subject identifiers are "creditor," "creditor identifier," "system," "lawyer (or agent)," and "lawyer identifier (or agent identifier)." The subject identifier "creditor" and "creditor identifier" indicate that the stage is the company's initiation stage. The subject identifier "system" indicates that the stage is the mediation stage by the debt management device 7. The subject identifier "lawyer (or agent)" and "lawyer identifier (or agent identifier)" indicate that the stage is the negotiation stage by the agent.

[0479] Debt status information includes, for example, creditor information, debtor information, debt details, confirmation information, negotiation information, proposal details, agreement documents, stage identifiers, entity identifiers, phase identification information, and various time-related information.

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

[0481] The transition instruction receiving unit 721 receives transition instructions from the creditor terminal 2. Transition instructions are usually associated with a debt identifier.

[0482] A transition instruction is a directive that moves from the current stage to the next stage in the multi-stage process of processing a claim. A transition instruction may include, for example, a creditor identifier and a claim identifier.

[0483] The processing unit 73 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, the information acquisition unit 139, or the transition judgment unit 731.

[0484] The transition determination unit 731 determines whether or not the transition condition, which is the condition for changing the entity that notifies the notification information, has been met.

[0485] Transition conditions include, for example, conditions related to the negotiation period, conditions related to negotiation information, and conditions related to the number of negotiations.

[0486] Conditions relating to the negotiation period include, for example, the period from the start of the current stage of activities until an agreement is reached exceeding a threshold or exceeding a threshold. Conditions relating to the negotiation period include, for example, the period from when the first notification means 7411 performs the first notification process until when the determination unit 137 determines that the agreement conditions have been met. Conditions relating to the negotiation period include, for example, conditions relating to the payment due date. Conditions relating to the payment due date include, for example, when the payment due date has passed, or when a threshold has elapsed since the payment due date.

[0487] The conditions for negotiation information are the conditions for negotiation information received by the negotiation receiving unit 123. For example, the conditions for negotiation information are that the difference between the conditions presented by the creditor (e.g., repayment amount or number of installments) and the negotiation information sent by the debtor (e.g., repayment amount or number of installments) is equal to or greater than a threshold. For example, the conditions for negotiation information are that the negotiation information sent by the debtor does not satisfy the conditions presented by the creditor.

[0488] The condition regarding the number of negotiations is, for example, that negotiation information has been exchanged between the creditor and the debtor N or more times (where N is a natural number greater than or equal to 2).

[0489] The transmitting unit 74 transmits various types of information. These types of information include, for example, notification information, first notification information (described later), second notification information (described later), third notification information (described later), screen information, proposal content, negotiation information, necessary information, and agreement documents. First notification information, second notification information, and third notification information are examples of notification information.

[0490] The Petition Notification Section 741 obtains notification information that includes creditor information identified by the creditor identifier contained in the petition information and debt content information, and uses said notification information to perform notification processing. Notification processing is the process of notifying the debtor about the debt. Notification processing is preferably carried out in multiple stages, as described later. The means of notification to the debtor are not limited. Notification means include, for example, email, web system (software), fax, telephone, sending short messages, notification using SNS, and postal mail. In addition, in notification processing (first notification processing, second notification processing, or third notification processing), notification or support for notification using two or more notification means is also possible.

[0491] The means of notification to the debtor at each stage of the first to nth stages carried out by the Notification Section 741 may be the same or different.

[0492] Notification processing includes, for example, the process of sending notification information to the debtor, the process of sending the debtor a URL that identifies the location of the notification information on the device, the process of faxing the notification information to the debtor, and the process of supporting the mailing of a demand letter (which may also be called a reminder letter, warning letter, etc.) containing the notification information. The process of supporting mailing includes, for example, the process of printing the demand letter and the process of printing the address for mailing.

[0493] The first notification means 7411 performs the first notification process in response to the application acquisition unit 121 acquiring the application information. It is preferable for the first notification means 7411 to perform the first notification process immediately when the application acquisition unit 121 acquires the application information, but it may also perform the first notification process after a delay in time following the acquisition of the application information.

[0494] The first notification process is the process of notifying the debtor of the first notification information from the first entity (for example, the creditor). The first notification process is the process of notifying the debtor regarding the claim.

[0495] The first notification information includes information about the creditor identified by the creditor identifier contained in the application information, and information about the nature of the claim. Preferably, the first notification information has a first entity identifier that identifies the first entity (e.g., creditor's name, agent's name).

[0496] The first, second, and third notification information are preferably different, but they may be the same except for the information concerning the subject.

[0497] The primary entity is, for example, the creditor (the principal), but it can also be a third party other than the creditor. The third party can be, for example, a lawyer acting as an agent, or a debt management device 7 (system).

[0498] When the primary entity is the creditor, the first notification process is for the purpose of demanding payment from the creditor.

[0499] The second notification means 7412 performs the second notification process after the first notification means 7411 has performed the first notification process. It is preferable for the second notification means 7412 to perform the second notification process when the transition determination unit 731 determines that the first transition condition has been met. The first transition condition is an example of a transition condition. For example, in the situation of the first stage, the second notification means 7412 performs the second notification process when the transition instruction receiving unit 721 receives a transition instruction.

[0500] The second notification process is the process of notifying the debtor of the second notification information from the second entity. The second notification process is the process of notifying the debtor regarding the claim.

[0501] The second notice information includes creditor information identified by the creditor identifier contained in the application information, and information on the nature of the claim. Typically, the second notice information differs from the first notice information. It is preferable that the second notice information has a second entity identifier that identifies the second entity (e.g., the name of the agent, the name of the creditor).

[0502] The second entity is different from the first entity. The second entity is, for example, the creditor's agent (usually a lawyer), the debt management device 7 (system), or the creditor (the principal).

[0503] If the second entity is the debt management device 7 (system), the second notification process is a process for mediation.

[0504] The third notification means 7413 performs the third notification process after the second notification means 7412 has performed the second notification process. It is preferable that the third notification means 7413 performs the second notification process when the transition determination unit 731 determines that the second transition condition has been met. The second transition condition is an example of a transition condition. It is preferable that the second transition condition is different from the first transition condition, but it may also be the same. For example, in the situation of the second stage, the third notification means 7413 performs the third notification process when the transition instruction receiving unit 721 receives a transition instruction.

[0505] Third-party notification processing refers to the process of notifying a debtor of third-party notification information from a third party. Third-party notification processing is the process of notifying a debtor regarding a claim.

[0506] Third-party notification information typically includes creditor information identified by the creditor identifier contained in the application information, and information about the nature of the claim. It is preferable that the third-party notification information has a third-party entity identifier that identifies the third party (for example, the name of the agent).

[0507] A third-party entity is different from the first or second-party entity. A third-party entity may be, for example, the creditor's agent (usually a lawyer), the debt management system, or the creditor (the principal).

[0508] If the third-party entity is the debt management device 7 (system), the third-party notification process is a process for mediation.

[0509] After the first notification process is carried out by the first notification means 7411, any negotiations may take place between the first entity and the creditor in the first stage. After the first notification process is carried out by the first notification means 7411, support may be provided by the debt management device 7, for example, as described in Embodiment 1.

[0510] After the second notification process is carried out by the second notification means 7412, any negotiations may take place between the second entity and the creditor in the second stage. After the second notification process is carried out by the second notification means 7412, support may be provided by the debt management device 7, for example, as described in Embodiment 1.

[0511] After the third notification process is carried out by the third notification means 7413, any negotiations may take place between the third entity and the creditor in the third stage. After the third notification process is carried out by the third notification means 7413, support may be provided by the debt management device 7, for example, as described in Embodiment 1.

[0512] The support provided by the debt management device 7 in the first, second, and third stages, which involves assistance in negotiations between the entity and the debtor after notification of the notice information, may be the same or different.

[0513] The storage unit 71 and the debt management unit 711 are preferably made of non-volatile recording media, but can also be made of volatile recording media.

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

[0515] The receiving unit 72 and the transition instruction receiving unit 721 are typically implemented by wireless or wired communication means.

[0516] The processing unit 73 and the transition determination unit 731 can typically be implemented using a processor, memory, etc. The processing procedures of the processing unit 73, 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 limited.

[0517] The transmitting unit 74, the claim notification unit 741, the first notification means 7411, the second notification means 7412, and the third notification means 7413 are implemented, for example, by wireless or wired communication means.

[0518] Next, an example of the operation of the debt management device 7 will be explained using the flowcharts in Figures 44 to 46. Note that in the flowcharts in Figures 44 to 46, the explanation of steps identical to those in Figure 4 or Figure 5 will be omitted.

[0519] (Step S4401) The first notification means 7411, etc., perform the first notification process. An example of the first notification process will be explained using the flowchart in Figure 47.

[0520] (Step S4402) The processing unit 73 stores the stage flag "1" in the debt management unit 711, associating it with the debt identifier obtained in step S403. The process returns to step S401. Note that the stage flag is an example of a stage identifier.

[0521] (Step S4403) The transition instruction receiving unit 721 determines whether or not it has received a transition instruction from the creditor terminal 2. If a transition instruction is received, the process proceeds to step S4404; if no transition instruction is received, the process proceeds to step S4406.

[0522] (Step S4404) The processing unit 73 obtains the debt identifier corresponding to the transition instruction.

[0523] (Step S4405) The processing unit 73, etc., performs transition processing with respect to the processing of the claim identified by the claim identifier obtained in step S4404. The process returns to step S401.

[0524] An example of the transition process will be explained using the flowchart in Figure 48. The transition process refers to the process of moving between stages in the debt processing.

[0525] (Step S4406) The transition determination unit 731 determines whether or not it is time to perform the transition determination process. If it is time to perform the transition determination process, the unit proceeds to step S4407; otherwise, the unit proceeds to step S408.

[0526] The timing of the transition decision process is not restricted. The timing of the transition decision process is, for example, when a predetermined time arrives, or when negotiation information transmitted from debtor terminal 3 is received.

[0527] (Step S4407) The transition determination unit 731 assigns 1 to counter i.

[0528] (Step S4408) The transition determination unit 731 determines whether or not the i-th claim identifier of the claim subject to the transition determination process exists. If the i-th claim identifier exists, the process proceeds to step S4409; otherwise, the process returns to step S401.

[0529] The claim identifier for the claim subject to the transition determination process is, for example, the claim identifier of the claim management unit 711, or the claim identifier associated with the received negotiation information.

[0530] (Step S4409) The transition determination unit 731 performs a transition determination process for the i-th claim identified by the i-th claim identifier. An example of the transition determination process will be explained using the flowchart in Figure 51.

[0531] The transition decision process is the process of determining whether or not to move to a new stage in the negotiation process for resolving the debt.

[0532] (Step S4410) If the result of the judgment is "transition", proceed to step S4411; if it is "do not transition", proceed to step S4413.

[0533] (Step S4411) The processing unit 73 obtains the i-th debt identifier.

[0534] (Step S4412) The processing unit 73, etc., performs a transition process to transition the processing stage of the claim identified by the i-th claim identifier. An example of the transition process will be explained using the flowchart in Figure 48.

[0535] (Step S4413) The transition determination unit 731 increments counter i by 1. The process returns to step S4408.

[0536] In the flowcharts shown in Figures 44 to 46, processing is terminated by power-off or processing termination interrupts.

[0537] Next, an example of the first notification process in step S4401 will be explained using the flowchart in Figure 47. Note that in the flowchart in Figure 47, the explanation of the same steps as in Figure 4 will be omitted.

[0538] (Step S4701) The first notification means 7411 obtains a first entity identifier. The first notification means 7411 obtains, for example, a first entity identifier from the storage unit 71 that does not change depending on the creditor. The first notification means 7411 obtains, for example, a first entity identifier from the storage unit 71 that is paired with a creditor identifier. In other words, the first entity may be fixed or may change depending on the creditor.

[0539] (Step S4702) The first notification means 7411 constitutes notification information including information of the first entity identified by the first entity identifier. Proceed to step S406.

[0540] Furthermore, the process for structuring the notification information here can be the same as the process explained using the flowchart in Figure 6, except that it includes information about the first entity.

[0541] Next, an example of the transition process in steps S4405 and S4412 will be explained using the flowchart in Figure 48.

[0542] (Step S4801) The petition notification unit 741 obtains a stage flag from the debt management unit 711 that is paired with a debt identifier that identifies the debt in question.

[0543] (Step S4802) If the step number is "1", proceed to step S4803; if it is "2", proceed to step S4805.

[0544] (Step S4803) The second notification means 7412 performs the second notification process. An example of the second notification process will be explained using the flowchart in Figure 49.

[0545] (Step S4804) The processing unit 73 updates the stage flag, which is paired with the debt identifier, to "2". The process returns to step S401.

[0546] (Step S4805) The processing unit 73 determines whether or not to perform the third notification process. If the third notification process is to be performed, the unit proceeds to step S4806; otherwise, it proceeds to step S4808.

[0547] The processing unit 73 may also decide to always perform the third-party notification process. Alternatively, the processing unit 73 may obtain information from the storage unit 71 that is paired with the creditor identifier or claim identifier, and which is used to determine whether or not to perform the third-party notification process, and use this information to determine whether or not to perform the third-party notification process.

[0548] (Step S4806) The third notification means 7413 performs the third notification process. An example of the third notification process will be explained using the flowchart in Figure 50.

[0549] (Step S4807) The processing unit 73 updates the stage flag, which is paired with the debt identifier, to "3". The process returns to step S401.

[0550] (Step S4808) The processing unit 73 stores information in the debt management unit 711 indicating that the debt processing was unsuccessful. The process returns to step S401.

[0551] Next, an example of the second notification process in step S4803 will be explained using the flowchart in Figure 49. Note that in the flowchart in Figure 49, the explanation of the same steps as in Figure 4 will be omitted.

[0552] (Step S4901) The second notification means 7412 obtains a second entity identifier. The second notification means 7412 obtains, for example, a second entity identifier from the storage unit 71 that does not change depending on the creditor. The second notification means 7412 obtains, for example, a second entity identifier from the storage unit 71 that is paired with a creditor identifier. In other words, the second entity may be fixed or may change depending on the creditor.

[0553] (Step S4902) The second notification means 7412 constructs notification information that includes information of the second entity identified by the second entity identifier. The notification information construction process may be the same as the process described using the flowchart in Figure 6, except that it includes information of the second entity. Proceed to step S406.

[0554] Next, an example of the third notification process in step S4806 will be explained using the flowchart in Figure 50.

[0555] (Step S5001) The third notification means 7413 obtains the third notification information template from the storage unit 71.

[0556] (Step S5002) The third notification means 7413 obtains a third entity identifier. The third notification means 7413 obtains, for example, a third entity identifier from the storage unit 71 that does not change depending on the creditor. The third notification means 7413 obtains, for example, a third entity identifier from the storage unit 71 that is paired with a creditor identifier. In other words, the third entity may be fixed or may change depending on the creditor.

[0557] (Step S5003) The third notification means 7413 obtains third entity information from the storage unit 71 that is paired with the third entity identifier obtained in step S5002.

[0558] (Step S5004) The third notification means 7413 substitutes the third entity information obtained in step S5003 into the third notification information template obtained in step S5001. Proceed to step S602.

[0559] (Step S5005) The third notification means 7413 prints the third notification information obtained in step S5004. It returns to the higher-level process.

[0560] In the flowchart of Figure 50, the information substitution in steps S603 and S605 is the substitution into the third notification information template. Furthermore, the completion of the information substitution in step S605 completes the configuration of the output third notification information.

[0561] Furthermore, in the flowchart of Figure 50, the printed third-party notification information is usually mailed to the debtor. However, the third-party notification means 7413 may also notify the debtor of the third-party notification information by other means such as email.

[0562] Furthermore, the processes performed in the flowchart of Figure 50 may be the same as those in Figure 47 or Figure 49, except that the subject information is different.

[0563] Next, an example of the transition decision process in step S4409 will be explained using the flowchart in Figure 51.

[0564] (Step S5101) The transition determination unit 731 obtains debt management information from the debt management unit 711 that corresponds to the debt identifier of the target debt.

[0565] (Step S5102) The transition determination unit 731 assigns 1 to counter i.

[0566] (Step S5103) The transition determination unit 731 determines whether or not the i-th transition condition exists in the storage unit 71. If the i-th transition condition exists, the process proceeds to step S5104; otherwise, the process proceeds to step S5108.

[0567] (Step S5104) The transition determination unit 731 obtains one or more pieces of information to be used to determine the i-th transition condition. The one or more pieces of information include, for example, the start date of negotiations and today's date, the payment due date and today's date, the terms presented by the creditor and the negotiation information received from the debtor, and the number of times negotiation information has been exchanged.

[0568] (Step S5105) The transition determination unit 731 uses one or more pieces of information obtained in step S5104 to determine whether the i-th transition condition is met. If the i-th transition condition is met, the unit proceeds to step S5106; otherwise, the unit proceeds to step S5107.

[0569] (Step S5106) The transition determination unit 731 assigns "transition" to the variable "determination result". It returns to the higher-level process.

[0570] (Step S5107) The transition determination unit 731 increments counter i by 1. The process returns to step S5103.

[0571] (Step S5108) The transition determination unit 731 assigns "Do not transition" to the variable "Decision Result". It returns to the higher-level process.

[0572] The following describes a specific example of the operation of information system D in this embodiment.

[0573] The storage unit 71, which constitutes the debt management device 7, stores the creditor management table shown in Figure 52. 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 7. The creditor management table here manages one or more records that have "ID", "creditor identifier", "creditor name", "email address", "payment destination information", "first stage", "second stage", "third stage", "first transition condition", and "second transition condition". Note that "creditor name", "email address", and "payment destination information" constitute creditor information.

[0574] "Stage 1," "Stage 2," and "Stage 3" are pieces of information that identify the entity at each stage to which the debt is processed. "1" indicates that the entity is the creditor (the principal). "2" indicates that the entity is the debt management device 7 (system). "3" indicates that the entity is an attorney acting as an agent. If "Stage 2" or "Stage 3" is "- (empty)," it indicates that the creditor will not proceed to that stage, meaning that they will only notify the debtor up to the previous stage.

[0575] The "first transition condition" is the information required to transition from the "first stage" to the "second stage." The "second transition condition" is the information required to transition from the "second stage" to the "third stage." In this context, the transition conditions are conditions related to time and conditions related to the number of negotiations. The transition condition "time >= 10 days" indicates that if an agreement has not been reached after 10 days or more have passed since the notification (after the start of negotiations), the stage will transition. The transition condition "payment due date passed" indicates that if an agreement has not been reached even after the payment due date has passed, the stage will transition. The transition condition "number of negotiations >= 4" indicates that if an agreement has not been reached even after four or more exchanges of negotiation information (presentation of conditions, acceptance or rejection of conditions), the stage will transition.

[0576] Furthermore, in the creditor management table shown in Figure 52, the entities and transition conditions for each stage are managed for each creditor. In other words, here, creditors can specify the entities and transition conditions for each stage. It is preferable that creditors can specify the entities and transition conditions for each stage for each debt identifier. In Figure 52, the entities and transition conditions for each stage are managed for each debt identifier.

[0577] The debt management unit 711 of the debt management device 7 stores a debt management table having the structure shown in Figure 53. The debt management table is a table that manages debt status information. The debt management table here 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," "agreement document," and "stage flag."

[0578] The "stage flag" is information that identifies the current stage in a multi-stage negotiation process and can take the values ​​of "1," "2," or "3." Stage flags "1," "2," and "3" represent the first, second, and third stages, respectively.

[0579] Furthermore, the storage unit 71 of the debt management device 7 stores attorney information relating to the attorney acting as an agent corresponding to the principal identifier "3". Here, the attorney information is assumed to be "<Law Firm> ABC Law Firm <Attorney in Charge> Tanaka Hajime <Address> 060-0031 Sapporo City...". In this case, only one attorney information is stored in the storage unit 71, but attorney information may also be managed for each creditor identifier or each debt identifier. In other words, notifications may be sent to the debtor under different attorney names for each creditor or each debt.

[0580] In the above situation, suppose that Company H (creditor identifier "C02"), which operates the gym, enters information about a claim for debt against Yamada A, a member of the gym who has outstanding monthly membership fees, into creditor terminal 2. Creditor terminal 2 then receives the claim information and, paired with creditor identifier "C02", transmits a case registration including the claim information to the debt management device 7.

[0581] The claim acquisition unit 121 of the debt management device 7 receives the case registration from the creditor terminal 2. Next, the claim storage unit 131 configures the claim information to be stored through the process described above and stores the claim information in the debt management table. The stored claim information is the claim information with "ID=2" in the debt management table (Figure 53).

[0582] Next, the first notification means 7411 obtains "First Stage = 1 (Principal)" which is paired with the creditor identifier "C02" from the creditor management table (Figure 52). The first notification means 7411 also obtains the application information which is paired with the creditor identifier "C02" from the creditor management table (Figure 53). Next, the first notification means 7411 obtains the first notification information template corresponding to the first subject identifier "1 (Principal)" from the storage unit 71. Then, the first notification means 7411 substitutes the debtor's name, creditor information, application amount, etc., contained in the application information into the first notification information template to construct the first notification information.

[0583] Next, the first notification method 7411 obtains the email address "zz@z.jp" of the debtor "Yamada Ao" from the application information.

[0584] Next, the first notification means 7411 sends the configured first notification information to the email address "zz@z.jp".

[0585] Next, Yamada A's debtor terminal 3 receives and outputs the first notification information. An example of such first notification information is shown in Figure 54.

[0586] Subsequently, Yamada A. stated that he did not respond to the initial notification information he received via email (Figure 54), and that the payment deadline of "January 31, 2025" had passed.

[0587] The transition determination unit 731 then obtains the first transition condition "payment due date has passed" which is paired with the creditor identifier "2", and the payment due date "January 31, 2025" which is paired with the debt identifier "2". The transition determination unit 731 also obtains today's date "February 1, 2025" from a clock (not shown). The transition determination unit 731 then determines that the first transition condition has been met.

[0588] Next, the second notification means 7412 obtains the second stage "2", which is paired with the creditor identifier "C02", from the creditor management table (Figure 52). Then, the second notification means 7412 changes the subject from "Company H (the principal)" to the debt management device 7 (system) and performs the processing described in Embodiment 1 (in particular, the processing described as a specific example of the operation of information system A). The second notification means 7412 also updates the stage flag paired with the debt identifier "2" from "1" to "2".

[0589] In the second stage of mediation using information system A, the judgment unit 137 determined that the exchange of negotiation information between Company H and Mr. A Yamada had reached four rounds, and that neither party had reached an agreement (the conditions for agreement had not been met).

[0590] Next, the transition determination unit 731 obtains the second transition condition "Number of negotiations >= 4," which is paired with the creditor identifier "C02," from the creditor management table (Figure 52). Then, the transition determination unit 731 examines the negotiation information for "ID=2" in the debt management table (Figure 53), confirms that no agreement has been reached and that there have been four exchanges of negotiation information, and determines that the second transition condition has been met.

[0591] Next, the petition notification unit 741 retrieves the stage flag "2," which is paired with the debt identifier "2," from the debt management table (Figure 53). Then, the processing unit 73 retrieves the third stage "3," which is paired with the creditor identifier "C02." Since the third stage is not NULL, the processing unit 73 decides to perform the third notification process.

[0592] Next, the third notification means 7413 performs the third notification process as follows: The third notification means 7413 obtains a third notification information template from the storage unit 71. Here, the third notification information template is a template for a postcard to be mailed to the debtor. Next, the third notification means 7413 obtains the third entity identifier "3". Next, the third notification means 7413 obtains the lawyer information, which is the third entity information corresponding to the third entity identifier "3", from the storage unit 71. Next, the third notification means 7413 substitutes the obtained third entity information into the obtained third notification information template. The third notification means 7413 also obtains the creditor's information and substitutes it into the third notification information template. Furthermore, the third notification means 7413 obtains the debtor's information and substitutes it into the third notification information template. With the above steps completed, the third notification information to be notified to the debtor is finished. Next, the third notification means 7413 prints the third notification information. An example of such printed third notification information is shown in Figure 55. In Figure 55, (A) is the front of the postcard, and (B) is the back of the postcard. The third notification means 7413 also updates the stage flag paired with the claim identifier "2" from "2" to "3".

[0593] For example, the person in charge of operating the debt management system 7 mails a postcard, primarily from a lawyer, to the debtor, Yamada A.

[0594] Yamada A. reportedly made the monthly gym membership payment after seeing a postcard addressed to a lawyer. It is preferable that the fact that such a payment was made be managed by the Debt Management Department 711.

[0595] As described above, according to this embodiment, activities for processing debts can be supported in multiple stages. These multiple stages may be, for example, two or three stages.

[0596] Furthermore, according to this embodiment, with respect to the multi-stage activities for processing debt, the process can move to the next stage when the transition conditions are met.

[0597] Furthermore, according to this embodiment, with respect to the multi-stage activities for processing the debt, the process can move to the next stage when the transition conditions regarding the period until an agreement is reached are met.

[0598] Furthermore, according to this embodiment, in the multi-stage activities for processing claims, the process can move to the next stage when the transition conditions related to negotiation information are met.

[0599] The processing in this embodiment may be implemented by software. This software may be distributed by 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 the debt management device 7 in this embodiment is the following program. In other words, this program is a computer application acquisition unit that 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, The claim management unit stores information associated with a claim identifier that identifies a claim, and one or more claim status information including application information. The claim storage unit stores the application information acquired by the application acquisition unit, associating it with a claim identifier that identifies the claim associated with the application information. The claim notification unit functions as a notification processing unit that acquires notification information including the creditor information identified by the creditor identifier in the application information and the claim content information, and uses the notification information to notify the debtor. The claim notification unit, in response to the application acquisition unit acquiring the application information, has previously... The program for causing the computer to function comprises: first notification means for performing first notification processing to notify the debtor of first notification information from a first entity, which includes first notification information including information of the creditor identified by a creditor identifier and the content of the claim information; and second notification means for performing second notification processing to notify the debtor of second notification information from a second entity different from the first entity, which includes information of the creditor identified by a creditor identifier in the application information and the content of the claim information, after the first notification means has performed the first notification processing.

[0600] In Embodiments 1, 2, 3, and 4, support may be provided for the processing of applications other than the processing of claims. In other words, the claims management device 1, 4, 5, and 7 may also be negotiation support devices that support the processing of applications other than the processing of claims.

[0601] The claim in Embodiment 1, Embodiment 2, Embodiment 3, and Embodiment 4 may also be called a petition. Furthermore, the claim identifier may also be called a petition identifier. Furthermore, the creditor may be called the petitioner. Furthermore, the debtor may be called the respondent.

[0602] Creditor terminal 2 may also be a terminal used by the petitioner filing a claim regarding some kind of dispute. In other words, creditor terminal 2 can also be called petitioner terminal 2.

[0603] Debtor terminal 3 may also be a terminal used by the respondent in a dispute. In other words, debtor terminal 3 can also be called respondent terminal 3.

[0604] The Debt Management Department 111 and the Debt Management Department 711 may store information regarding the status of various claims. In other words, the Debt Management Department 111 and the Debt Management Department 711 can also be referred to as the Claim Management Department 811, which will be described later. The claim status information described later may also be the debt status information mentioned above.

[0605] (Embodiment 5) In this embodiment, a negotiation support device is described that sequentially and in multiple stages urges the processing of an application from parties with different positions. Note that "multiple stages" refers to, for example, two or three stages, but may also refer to four or more stages. The parties involved may be, for example, the applicant (principal), a lawyer (representative), or a system (negotiation support device 8, described later).

[0606] In this embodiment, we will describe a negotiation support device that, when the transition conditions are met in the nth stage of the activity for processing a claim, proceeds to the (n+1)th stage of the activity. Note that the activity is an activity for processing a claim.

[0607] The debt management device 7 of Embodiment 4 is capable of managing not only debts but also applications. In other words, the debt management device 7 includes a negotiation support device 8 that manages applications other than debts and assists in the processing of applications. The negotiation support device 8 has all or some of the components of the debt management device 7. The negotiation support device 8 can perform all or some of the functions of the debt management device 7.

[0608] Information system E comprises a negotiation support device 8, one or more petitioner terminals 2, and one or more respondent terminals 3. Petitioner terminals 2 are equivalent to creditor terminals 2. Respondent terminals 3 are equivalent to debtor terminals 3.

[0609] The conceptual diagram of the information system E in this embodiment is the same as in Figure 1, except that the name and reference numeral of the negotiation support device 8 are different. The negotiation support device 8 is a server, and its type is not limited to, for example, a cloud server or an ASP server.

[0610] The block diagram of information system E is shown in Figure 56. The block diagram of negotiation support device 8 is shown in Figure 57.

[0611] The petitioner terminal 2 comprises a petitioner storage unit 21, a petitioner reception unit 22, a petitioner processing unit 23, a petitioner transmission unit 24, a petitioner receiving unit 25, and a petitioner output unit 26. The petitioner storage unit 21, petitioner reception unit 22, petitioner processing unit 23, petitioner transmission unit 24, petitioner receiving unit 25, and petitioner output unit 26 perform the same processing as the creditor storage unit 21, creditor reception unit 22, creditor processing unit 23, creditor transmission unit 24, creditor receiving unit 25, and creditor output unit 26, respectively.

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

[0613] The respondent storage unit 31, respondent reception unit 32, respondent processing unit 33, respondent transmission unit 34, respondent receiving unit 35, and respondent output unit 3 each perform the same processing as the debtor storage unit 31, debtor reception unit 32, debtor processing unit 33, debtor transmission unit 34, debtor receiving unit 35, and debtor output unit 36, respectively.

[0614] The negotiation support device 8 comprises a storage unit 81, a receiving unit 82, a processing unit 83, and a transmission unit 84. The storage unit 81 comprises a petition management unit 811. The receiving unit 82 comprises a petition acquisition unit 121, a confirmation receiving unit 122, a negotiation receiving unit 123, an instruction receiving unit 124, and a transition instruction receiving unit 721. The processing unit 73 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 135, a mediation support unit 136, a judgment unit 137, an agreement document generation unit 138, an information acquisition unit 139, and a transition judgment unit 731. The transmission unit 74 comprises a petition notification unit 741, 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.

[0615] The petition management unit 811 stores one or more petition status information. Petition status information refers to information about a petition. For example, petition status information is information that identifies the current phase of one of two or more phases from the filing of the petition to an agreement. The agreement here refers to an agreement between the petitioner and the respondent regarding the handling of the petition. Petition status information may also be information that identifies the current phase of one of two or more phases from the filing of the petition to an agreement. A phase is a specific state or period in the progress of handling the petition from the filing of the petition to an agreement or breakdown, etc. A phase can also be called a step or stage. Petition status information is information that identifies the current stage in the multi-stage activities for handling the petition. In each of the two or more stages, a different entity is responsible for prompting or negotiating activities for handling the petition. Note that different entities usually mean different entities are responsible for notifying the respondent.

[0616] Application status information can be described as information used to manage the status of an application. Application status information is information associated with an application identifier. An application identifier is information that identifies an application. An application identifier is, for example, the application ID or the name of the application (for example, the name of the application case). Application status information includes, for example, applicant information, respondent information, application content information, confirmation information, negotiation information, proposed content, agreement documents, phase identification information, and various time information.

[0617] The application status information here includes information that identifies the stage. This information includes, for example, a stage identifier that identifies the stage, and a subject identifier that identifies the entity that prompts or negotiates for the processing of the application. The stage identifier may be the same information as the subject identifier. In other words, the subject may be determined when the stage is determined. Subject identifiers include, for example, "Applicant," "Applicant Identifier," "System," "Lawyer (or Agent)," and "Lawyer Identifier (or Agent Identifier)." The subject identifiers "Applicant" and "Applicant Identifier" indicate that the stage is prompting by the company. The subject identifier "System" indicates that the stage is mediation by the negotiation support device 8. The subject identifiers "Lawyer (or Agent)" and "Lawyer Identifier (or Agent Identifier)" indicate that the stage is negotiation by an agent.

[0618] The application status information includes, for example, applicant information, respondent information, application content information, confirmation information, negotiation information, proposed content, agreement documents, stage identifiers, subject identifiers, phase identification information, and various time information.

[0619] Petitioner information refers to information about the petitioner. Petitioner information includes, for example, a petitioner identifier and one or more petitioner attribute values. The petitioner identifier is information that identifies the petitioner. Examples of petitioner identifiers include the petitioner's ID, petitioner's name, petitioner's telephone number, petitioner's email address, and the IP address of petitioner terminal 2. Petitioner attribute values ​​include, for example, the petitioner's payment destination information, the petitioner's company name, the name of the representative of the company that is the petitioner, and the petitioner type indicating whether the petitioner is a corporation or an individual. Payment destination information is information that the respondent uses to make payments to the petitioner.

[0620] Respondent information refers to information about the respondent. Respondent information includes, for example, a respondent identifier and one or more respondent attribute values. The respondent identifier is information that identifies the respondent. The respondent identifier may include, for example, the respondent's ID, the respondent's name, the respondent's telephone number, the respondent's email address, and the IP address of respondent terminal 3. Respondent attribute values ​​may include, for example, the respondent's contact information, the respondent's company name, the name of the representative of the respondent company, the respondent's address, and the respondent type indicating whether the respondent is a corporation or an individual. Contact information may include, for example, an email address, a telephone number, and an ID for social media (e.g., Line®, Slack®).

[0621] Claim information refers to information that identifies the content of a claim. This information may include, for example, the name of the claim, the claimed amount, and the original payment due date. If the claim is a request for the return of borrowed items, the claim information may include, for example, information about the items to be returned and information identifying the return address.

[0622] Next, an example of the operation of the negotiation support device 8 will be explained using the flowcharts in Figures 58 to 60. Note that in the flowcharts in Figures 58 to 60, the explanation of steps identical to those in Figures 4, 5, 44, 45, or 46 will be omitted.

[0623] In addition, in the flowcharts from Figure 58 to Figure 60, "Creditor Terminal 2" in the flowcharts from Figure 4, Figure 5, Figures 44 to 46, etc., is replaced with "Petitioner Terminal 2", "Debtor Terminal 3" with "Respondent Terminal 3", "Credit Identifier" with "Petition Identifier", "Credit Management Department 111" with "Petition Management Department 811", "Creditor" with "Petitioner", "Debtor" with "Respondent", "Credit" with "Petition", "Credit Identifier" with "Petition Identifier", "Credit Content Information" with "Petition Content Information", and "Credit Status Information" with "Petition Status Information", etc.

[0624] Furthermore, in this embodiment, in the first notification process described using the flowchart in Figure 47, the transition process described using the flowchart in Figure 48, the second notification process described using the flowchart in Figure 49, the third notification process described using the flowchart in Figure 50, and the transition determination process described using the flowchart in Figure 51, "creditor" is replaced with "petitioner," "debtor" with "respondent," "creditor identifier" with "petitioner identifier," "debtor identifier" with "respondent identifier," "debt processing" with "petition processing," "debt management information" with "petition management information," and "debt management department 711" with "petition management department 811," etc.

[0625] As described above, according to this embodiment, the activities for processing applications can be supported in multiple stages. These multiple stages may be, for example, two or three stages.

[0626] Furthermore, according to this embodiment, with respect to the multi-stage activities for processing the application, the process can move to the next stage when the transition conditions are met.

[0627] Furthermore, according to this embodiment, with respect to the multi-stage activities for processing the application, the process can move to the next stage when the transition conditions regarding the period until an agreement is reached are met.

[0628] Furthermore, according to this embodiment, with respect to the multi-stage activities for processing the application, the process can move to the next stage when the transition conditions related to negotiation information are met.

[0629] The processing in this embodiment may be implemented by software. This software may be distributed by 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 the debt management device 7 in this embodiment is the following program. In other words, this program causes the computer to function as a petition acquisition unit that acquires petition information having a petitioner identifier that identifies the petitioner, a respondent identifier that identifies the respondent, and petition content information relating to the content of the petition; a petition storage unit that stores the petition information acquired by the petition acquisition unit in association with a petition identifier that identifies the petition that corresponds to the petition identifier that identifies the petition, and one or more petition status information including the petition information, which are information associated with the petition identifier that identifies the petition; and a petition notification unit that acquires notification information including the petitioner information identified by the petitioner identifier in the petition information and the petition content information, and performs a notification process which is the process of notifying the respondent using the notification information. The application notification unit is a program for causing the computer to function, comprising: first notification means for performing first notification processing to notify the respondent of first notification information from a first entity, which includes first notification information including information of the applicant identified by the applicant identifier in the application information and the application content information, in response to the application acquisition unit acquiring the application information; and second notification means for performing second notification processing to notify the respondent of second notification information from a second entity different from the first entity, which includes second notification information including information of the applicant identified by the applicant identifier in the application information and the application content information, after the first notification means has performed the first notification processing.

[0630] Furthermore, Figure 61 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 7 and negotiation support device 8 described above.

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

[0632] In Figure 61, 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.

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

[0634] 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 7 and negotiation support device 8 of the above-described embodiment. The program only needs to include the instruction portion that calls the appropriate function (module) in a controlled manner and obtains the desired result. How the computer system 300 operates is well known, so a detailed explanation is omitted.

[0635] 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).

[0636] 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.

[0637] 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.

[0638] 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.

[0639] 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]

[0640] As described above, the debt management device 7 according to the present invention has the effect of being able to support debt processing activities in multiple stages, and is useful as a server or the like that supports debt processing. [Explanation of Symbols]

[0641] D, E Information Systems 2. Creditor terminal 3. Debtor's terminal 7. Debt Management System 8 Negotiation support device 71, 81 Storage section 72, 82 Receiving section 73, 83 Processing Unit 74, 84 Transmitter 121 Petition Acquisition 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 Negotiation Accumulation Department 135 Proposal content acquisition section 136 Mediation Support Department 137 Judgment Department 138 Agreement Document Generation Department 139 Information Acquisition 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 711 Debt Management Department 721 Transition instruction receiving unit 731 Transition judgment section 741 Petition Notification Department 811 Shin Management Department 811 7411 First means of notification 7412 Second means of notification 7413 Third means of notification

Claims

1. A petition acquisition unit that acquires petition information having a petitioner identifier that identifies the petitioner, a respondent identifier that identifies the respondent, and petition content information relating to the content of the petition, Information associated with a petition identifier that identifies a petition, and a petition management unit that stores one or more petition status information including petition information, a petition storage unit that stores the petition information acquired by the petition acquisition unit, associated with a petition identifier that identifies the petition associated with the petition information, The system comprises a petition notification unit which obtains notification information including the petitioner's information identified by the petitioner identifier contained in the petition information and the petition content information, and performs a notification process which is the process of notifying the respondent using the notification information, The aforementioned notification department of the petition, In response to the acquisition of the application information by the application acquisition unit, the first notification means performs a first notification process to notify the respondent of the first notification information from the first entity, which includes the information of the applicant identified by the applicant identifier in the application information and the application content information, and the first notification unit acquires the application information. A negotiation support device comprising: a second notification means that, after the first notification means has performed the first notification processing, performs second notification processing to notify the respondent of second notification information, which includes information of the applicant identified by the applicant identifier in the application information and the application content information, and is from a second entity different from the first entity.

2. The aforementioned notification department of the petition, The negotiation support device according to claim 1, further comprising: a third notification means that, after the second notification means has performed the second notification processing, performs third notification processing to notify the respondent of third notification information, which includes information of the applicant identified by the applicant identifier in the application information and the application content information, from a third entity different from the first entity and the second entity.

3. The system further comprises a transition determination unit that determines whether or not a transition condition is met, which is a condition for changing the entity that notifies the notification information. The second notification means is, The negotiation support device according to claim 1, wherein the transition determination unit determines that the transition conditions are met and performs the second notification process.

4. The aforementioned first party is the aforementioned petitioner, The negotiation support device according to claim 1, wherein the first notification process is a process for the company to send a reminder.

5. The aforementioned second entity is the negotiation support device according to claim 4, which is the agent of the aforementioned petitioner.

6. The aforementioned third entity is a negotiation support mechanism, The negotiation support device according to claim 2, wherein the third notification process is a process for mediation.

7. A negotiation receiving unit that receives negotiation information relating to negotiations between the petitioner and the respondent from the petitioner's terminal and the respondent's terminal, The system further comprises a determination unit that uses the negotiation information received by the negotiation receiving unit to determine whether or not the conditions of agreement have been met, The negotiation support device according to claim 2, wherein the transition condition is a condition relating to the period from when the first notification means performs the first notification process until when the determination unit determines that the agreement conditions have been met.

8. The system further comprises a negotiation receiving unit that receives negotiation information relating to negotiations between the petitioner and the respondent from the petitioner's petitioner terminal and the respondent's respondent terminal, The negotiation support device according to claim 2, wherein the transition condition is a condition relating to the negotiation information.

9. A negotiation support method comprising all the processes performed by the negotiation support device described in any one of claims 1 to 8.

10. Computers, A program for causing a negotiation support device to function as described in any one of claims 1 to 8.

Images