Negotiation support device, negotiation support method, and program

Abstract

Traditionally, applicants have not been able to automate the negotiation process regarding the handling of their applications. [Solution] The negotiation support device 5 comprises a condition management unit 511 that stores concession conditions which are conditions under which the applicant can make concessions for the processing of the application; a negotiation receiving unit 523 that receives negotiation information regarding the applicant's application from the respondent terminal 3; a concession determination unit 532 that determines whether the negotiation information received by the negotiation receiving unit 523 satisfies the concession conditions of the condition management unit 511; and an automatic negotiation unit 533 that, if the concession determination unit 532 determines that the concession conditions are not met, acquires second negotiation information which is new negotiation information based on the concession conditions and transmits the second negotiation information to the respondent terminal 3, thereby automating negotiations regarding the processing of the application for the applicant.

Description

Technical Field

[0001] The present invention relates to a negotiation support device and the like for supporting negotiations regarding an application from an applicant. Here, the application is, for example, the processing of claims and the resolution of various disputes. The application is usually a claim against a respondent. The respondent is the object of the claim. The application only needs to be an object of negotiation. 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 conditions at the time of retirement, etc. Disputes may also be referred to as disputes, conflicts, etc.

Background Art

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

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the prior art, for an applicant, the negotiation regarding the processing of an application could not be automated. The processing of an application may also be referred to as the resolution of an application or application processing.

[0005] Moreover, in the prior art, there was no platform for managing the situation until the resolution of an application in two or more phases until the applicant and the respondent agreed on the application and for promoting the processing of the application.

Means for Solving the Problems

[0006] The negotiation support device of the first invention comprises: a condition management unit that stores concession conditions which are conditions which the applicant can make for the processing of the application; a negotiation receiving unit that receives negotiation information regarding the application from the respondent's terminal; a concession determination unit that determines whether the negotiation information received by the negotiation receiving unit satisfies the concession conditions of the condition management unit; and an automatic negotiation unit that, if the concession determination unit determines that the concession conditions are not satisfied, acquires second negotiation information which is new negotiation information based on the concession conditions and transmits the second negotiation information to the respondent's terminal.

[0007] This configuration allows the petitioner to automate negotiations regarding the processing of their petition.

[0008] Furthermore, the negotiation support device of the second invention, compared to the first invention, further comprises a negotiation receiving unit which, after the automatic negotiation unit transmits second negotiation information to the respondent terminal, receives new negotiation information, namely third negotiation information, from the respondent terminal and determines whether the third negotiation information received by the negotiation receiving unit satisfies the automatic negotiation termination conditions, and a negotiation information output unit which, if the termination determination unit determines that the automatic negotiation termination conditions are met, transmits the third negotiation information to the applicant's terminal.

[0009] This configuration allows for the transfer of negotiations to the petitioner if the automated negotiation process on the petitioner's side fails.

[0010] Furthermore, the negotiation support device of this third invention, compared to the first invention, has a condition management unit that stores two or more concession conditions with priority, a concession judgment unit that determines whether the negotiation information received by the negotiation receiving unit satisfies the first concession condition, which is the first priority concession condition of the condition management unit, and if the concession judgment unit determines that the first concession condition is not satisfied, the automatic negotiation unit acquires second negotiation information, which is new negotiation information based on the first concession condition, and transmits the second negotiation information to the respondent terminal, and after the automatic negotiation unit has transmitted the second negotiation information to the respondent terminal, the negotiation receiving unit receives third negotiation information from the respondent terminal, the concession judgment unit determines whether the third negotiation information received by the negotiation receiving unit satisfies the second concession condition, which is the second priority concession condition of the condition management unit, and if the concession judgment unit determines that the second concession condition is not satisfied, the automatic negotiation unit acquires fourth negotiation information, which is new negotiation information based on the second concession condition, and transmits the fourth negotiation information to the respondent terminal.

[0011] This configuration allows for more flexible and automated negotiations on the part of the petitioner regarding the processing of their application.

[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 concession conditions include one or more conditions from among the following: total payment conditions, which are conditions relating to the total amount to be paid; number of installments conditions, which are conditions relating to the number of installments of payment; payment amount conditions, which are conditions relating to the amount of each installment; and mediation conditions, which are conditions relating to whether or not to request mediation or arbitration by a lawyer.

[0013] This configuration allows the petitioner to automate negotiations regarding the processing of their petition.

[0014] Furthermore, the negotiation support device of this fifth invention is a negotiation support device in which, with respect to any one of the first to fourth inventions, the automatic negotiation unit generates second negotiation information, which is new negotiation information based on the concession conditions, using the negotiation information received by the negotiation receiving unit when the concession judgment unit determines that the concession conditions are not met, and transmits the second negotiation information to the respondent's terminal.

[0015] This configuration allows for more flexible and automated negotiations on the part of the petitioner regarding the processing of their application.

[0016] Furthermore, the negotiation support device of the sixth invention includes, for any one of the first to fifth inventions, 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 management unit that stores information associated with the application identifier that identifies the application, and which can identify the current phase of one or more phases from the filing of the application to the agreement between the application and the respondent regarding the processing of the application; an application storage unit that stores the application information acquired by the application acquisition unit, associated with the application identifier that identifies the application associated with the application information; and, in response to the application acquisition unit acquiring the application information, an application storage unit that acquires notification information including information of the application identified by the application identifier in the application information and application content information, and transmits the notification information to the respondent. The negotiation support device further comprises: a petition notification unit; a confirmation receiving unit that receives confirmation information regarding the confirmation of the petition from the respondent's terminal; a confirmation storage unit that, in response to the confirmation receiving unit receiving the confirmation information, acquires the stored confirmation information and stores it in the petition management unit in association with a petition identifier; a negotiation storage unit that stores negotiation information received by the negotiation receiving unit in the petition management unit in association with a petitioner identifier that identifies the petitioner or a respondent identifier that identifies the respondent, and the petition identifier; an instruction receiving unit that receives an instruction to output petition status information from the petitioner's terminal or the respondent's terminal; an information acquisition unit that acquires part or all of the petition status information corresponding to the output instruction from the petition management unit; and an information transmission unit that transmits part or all of the petition status information acquired by the information acquisition unit to the petitioner's terminal or the respondent's terminal.

[0017] This configuration allows for the management of the status of a petition in two or more phases out of two or more phases, from the filing of the petition to the agreement between the petitioner and the respondent on how to process the petition, and provides a platform to facilitate the processing of the petition. [Effects of the Invention]

[0018] According to the negotiation support device of the present invention, for the applicant, the negotiation regarding the application process can be automated.

Brief Description of the Drawings

[0019] [Figure 1] Conceptual diagram of 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] Flowchart for explaining an example of the composition process of the same notification information [Figure 7] Flowchart for explaining an example of the composition process of the same proposed content [Figure 8] Flowchart for explaining an example of the generation process of the same agreement document [Figure 9] Flowchart for explaining an example of the composition process of the same output information [Figure 10] Flowchart for explaining an operation example of the creditor terminal 2 [Figure 11] Flowchart for explaining an operation example of the debtor terminal 3 [Figure 12] Diagram showing an example of the flow of phases after the claim filing [Figure 13] Diagram showing an example of the creditor management table [Figure 14] Diagram showing an example of the claim management table [Figure 15] Diagram showing an example of the proposed content template [Figure 16] Diagram showing an example of the agreement document template [Figure 17] Diagram showing an example of the case registration screen [Figure 18] Diagram showing an example of the same notification information [Figure 19] Diagram showing an example of the same 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 negotiation support device 5 [Figure 36] A flowchart illustrating an example of the operation of the negotiation support device 5. [Figure 37] A flowchart illustrating an example of the automated negotiation decision-making process. [Figure 38] A flowchart illustrating an example of the automated negotiation process. [Figure 39] A flowchart illustrating the first example of the process for obtaining negotiation information from the respondent. [Figure 40] A flowchart illustrating a second example of the process for obtaining negotiation information from the respondent. [Figure 41] A flowchart illustrating an example of operation of the petitioner's terminal 6. [Figure 42]A flowchart illustrating an example of operation of the respondent's terminal 7. [Figure 43] A diagram showing an example of a concession condition management table. [Figure 44] Block diagram of the computer system in the above embodiment [Modes for carrying out the invention]

[0020] The following describes embodiments of the negotiation support device and the like with reference to the drawings. Note that components denoted by the same reference numerals in the embodiments perform similar operations, and therefore, further explanation may be omitted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0264] Next, the application acquisition unit 121 of the claim management device 1 receives a case registration from the creditor terminal 2. The application acquisition unit 121 acquires the current date and time, "2024 / 8 / 11 09:00" at the time of application, from a clock (not shown). The application acquisition unit 121 constructs the application information to be accumulated, "<Application case name> Non-payment by Company X <Application amount> 100,000 <Principal payment due date> 2024 / 8 / 1 <Creditor identifier> C01 ··· <Name of the other party> Company X ··· <Email address of the other party> yy@x.jp <Time of application> 2024 / 8 / 11 15:35". Next, the application accumulation unit 131 acquires a unique claim identifier "1". Next, the application accumulation unit 131 accumulates the constructed application information in the claim management table (Figure 14) in pairs with the claim identifier "1". Such application information is the application information of "ID=1" in Figure 14. Also, the update unit 132 accumulates the phase identifier "1" in the record of "ID=1" in Figure 14.

[0265] Next, the application notification unit 141 of the claim management device 1 constructs notification information as follows. First, the application notification unit 141 constructs the notification information in Figure 18 according to the operation of the notification information construction process described using the flowchart in Figure 6. Note that the application notification unit 141 substitutes the information corresponding to each underlined part into the notification information prototype with the underlined parts in Figure 18 becoming variables to construct the notification information. Next, the application notification unit 141 acquires the debtor's contact information "yy@x.jp" from the application information. Next, the application notification unit 141 transmits the notification information (Figure 18) to the contact specified by the contact information. Also, the update unit 132 updates the phase identifier of "ID=1" in Figure 14 from "1" to "2".

[0266] Next, the debtor terminal 3 receives and outputs the email, which is the notification information (Figure 18), from the claim management device 1. Note that the trigger for the output of the notification information in the debtor terminal 3 is not limited.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0286] Next, the negotiation reception unit 123 of the claim management device 1 receives the negotiation information. Next, the negotiation accumulation unit 134 acquires the claim identifier "1" included in the negotiation information. Also, assume that the negotiation accumulation unit 134 has acquired time information "2024 / 8 / 11 16:34" from a clock (not shown). Further, the negotiation accumulation unit 134 acquires the claimed amount "100,000 yen" and the divided amount "20,000 yen" paired with the claim identifier "1", acquires the payment start date, payment end date, and the payment amount for each month (acquires the payment schedule), and accumulates them in pair with the claim identifier "1". Note that the payment schedule is accumulated in FIG. 14 but not shown.

[0287] Next, the proposal content acquisition unit 135 acquires the previously acquired proposal content. Next, the proposal content acquisition unit 135 accumulates the proposal content in the claim management table (FIG. 14) in association with the negotiation information (file "P2").

[0288] Next, the processing unit 13 determines that the transmission condition "the proposal content has been configured" for transmitting specific screen information is satisfied. Next, the information acquisition unit 139 configures screen information including link information to the negotiation information and the proposal content. Next, the information transmission unit 147 transmits the screen information to the debtor terminal 3 of Yuko Yamada.

[0289] Next, the debtor terminal 3 receives the screen information and outputs the screen of FIG. 24. And assume that Yuko Yamada has instructed the "Accept Divided Amount Modification" button 2401 in FIG. 24. Then, the debtor terminal 3 accepts the instruction to the button 2401. Next, the debtor terminal 3 acquires the information "<Negotiation Result> Agreement" associated with the button 2401, and configures negotiation information "<Claim Identifier> 1 <Negotiation Result> Agreement <Divided Amount> 20,000 <Debtor Identifier> Company X" including the information, and transmits it to the claim management device 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0310] Furthermore, according to this embodiment, when an agreement is reached in negotiations regarding debt settlement, an agreement document can be automatically generated.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0355] In Embodiments 1 and 2, support may be provided for the processing of applications other than those related to the processing of claims. In other words, the claims management device 1 and the claims management device 4 may also be negotiation support devices that support the processing of applications other than those related to the processing of claims.

[0356] The claim in Embodiment 1 and Embodiment 2 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.

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

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

[0359] The Debt Management Department 111 may store information regarding the status of various claims. In other words, the Debt Management Department 111 can also be called the Claim Management Department 511. The claim status information may be the debt status information mentioned above.

[0360] Application status information refers to information related to an application. It is information that identifies the current phase of one of two or more phases from application to agreement. The agreement here refers to an agreement between the applicant and the respondent regarding the handling of the application. For example, application status information can be described as information for managing 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.

[0361] (Embodiment 3) This embodiment describes a negotiation support device that automatically conducts negotiations with the respondent using the stored concession conditions of the petitioner. More specifically, this embodiment describes a negotiation support device that manages the concession conditions of the petitioner, receives negotiation information from the respondent, determines whether the negotiation information satisfies the concession conditions, declares the negotiation successful if it does, and acquires new negotiation information if it does not, and transmits the negotiation information to the respondent. The concession conditions are, for example, one or more conditions from the following: total payment conditions, number of installments conditions, payment amount conditions, and mediation conditions.

[0362] In this embodiment, a negotiation support device that contacts the claimant when the conditions for automatic negotiation termination are met will be described.

[0363] In this embodiment, there are two or more concession conditions with priority, and a negotiation support device that automatically conducts negotiations with the respondent while changing the conditions based on that priority is described.

[0364] In this embodiment, a negotiation support device that generates new negotiation information using negotiation information transmitted by the respondent will be described.

[0365] Figure 33 is a conceptual diagram of the information system C in this embodiment. The information system C comprises a negotiation support device 5, one or more petitioner terminals 6, and one or more respondent terminals 7.

[0366] Negotiation support device 5 is a device that automatically conducts negotiations with the respondent using the concession conditions sent by the petitioner. Negotiation support device 5 may include all or part of the configuration of petition management device 1 and / or petition management device 4. Here, we will mainly describe the case in which negotiation support device 5 includes all of the configuration of petition management device 1. Negotiation support device 5 may be, 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 negotiation support device 5.

[0368] The negotiation support device 5 comprises a storage unit 51, a receiving unit 52, a processing unit 53, and a transmission unit 54. The storage unit 51 comprises a petition management unit 511 and a condition management unit 512. The receiving unit 52 comprises a petition acquisition unit 121, a confirmation receiving unit 122, a negotiation receiving unit 523, an instruction receiving unit 124, and a condition receiving unit 521. The processing unit 53 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, a condition storage unit 531, a concession judgment unit 532, an automatic negotiation unit 533, and a termination judgment unit 534. The transmission unit 54 includes a petition notification unit 141, a screen transmission unit 142, a proposal content transmission unit 143, a negotiation information output unit 544, a necessary information transmission unit 145, an agreement document output unit 146, and an information transmission unit 147.

[0369] The petitioner terminal 6 comprises a petitioner storage unit 61, a petitioner reception unit 62, a petitioner processing unit 63, a petitioner transmission unit 64, a petitioner receiving unit 65, and a petitioner output unit 66. The petitioner terminal 6 may be the same as the petitioner terminal 2.

[0370] The respondent terminal 7 comprises a respondent storage unit 71, a respondent reception unit 72, a respondent processing unit 73, a respondent transmission unit 74, a respondent receiving unit 75, and a respondent output unit 76. The respondent terminal 7 may be the same as the respondent terminal 3.

[0371] The storage unit 51, which constitutes the negotiation support device 5, stores various types of information. These types of information include, for example, application status information, screen information, various conditions, various templates, and lawyer information. The various conditions include, for example, agreement conditions, one or more concession conditions (described later), and one or more automatic negotiation termination conditions.

[0372] The automatic negotiation termination conditions are the conditions under which the negotiation support device 5 terminates automatic negotiations with the respondent on behalf of the petitioner. Examples of automatic negotiation termination conditions include: "The reception of negotiation information that does not satisfy one or more concession conditions," "The reception of negotiation information that does not satisfy all concession conditions," "The sending of negotiation information to the respondent with all concession conditions applied, but no agreement was reached," "Negotiations with the respondent have been conducted more than a threshold number of times (more than a threshold number of times negotiation information has been sent and received)," and "More than a threshold time has elapsed since the start of negotiations." Note that the automatic negotiation termination conditions are not restricted. Furthermore, the automatic negotiation termination conditions may be associated with a petition identifier. In other words, the automatic negotiation termination conditions may differ for each petition.

[0373] The condition management unit 512 stores one or more concession conditions. It is preferable that each of the one or more concession conditions is associated with a claim identifier. In other words, it is preferable that the concession conditions differ for each claim. If the condition management unit 512 stores two or more concession conditions, it is preferable that these two or more concession conditions have a priority order. The two or more concession conditions in the condition management unit 512 are stored, for example, in order of priority. Each of the two or more concession conditions in the condition management unit 512 is associated with, for example, a priority identifier.

[0374] A concession condition is a condition that the applicant can make concessions on in order to process the application. A concession condition may include, for example, one or more subconditions. A subcondition is a condition that makes up a concession condition. If a concession condition includes two or more subconditions, the concession condition is a condition in which those two or more subconditions are combined by AND. Examples of subconditions include the total payment condition, which is a condition concerning the total amount to be paid; the number of installments condition, which is a condition concerning the number of installments in which payments are made; the payment amount condition, which is a condition concerning the amount of each installment; and the mediation condition, which is a condition concerning whether or not to request attorney mediation or arbitration. Examples of subconditions include the timing of the handover of the building; the amount upon handover of the building (a condition concerning the amount the applicant pays to the respondent); the timing of the rent increase for the building; the amount of the rent increase for the building; the amount of retirement allowance; the number of installments in which retirement allowance payments are made; and the conditions concerning work to be provided after retirement. Note that the subconditions are not specified.

[0375] The receiving unit 52 receives various information and instructions from the petitioner's terminal 6 or the respondent's terminal 7. These various information and instructions include, for example, concession conditions, case registration, petition information, confirmation information, negotiation information, output instructions, proposal content instructions, agreement document instructions, payment schedule instructions, or payment information. The receiving unit 52 may also have all the functions of the receiving unit 12.

[0376] The negotiation receiving unit 523 receives negotiation information relating to the petition from the respondent's terminal 7. For example, after the automated negotiation unit 533 has sent second negotiation information to the respondent's terminal 7, the negotiation receiving unit 523 receives new negotiation information, namely third negotiation information, from the respondent's terminal 7. The negotiation receiving unit 523 performs all the processing that the negotiation receiving unit 123 would perform. In other words, the negotiation receiving unit 523 may also receive negotiation information from the petitioner.

[0377] The condition receiving unit 521 receives one or more concession conditions from the petitioner terminal 6. The concession conditions received by the condition receiving unit 521 are usually associated with a petition identifier. The timing of the condition receiving unit 521 receiving the concession conditions is not restricted. The condition receiving unit 521 may receive the concession conditions when receiving the case registration.

[0378] The processing unit 53 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, the condition storage unit 531, the concession judgment unit 532, the automatic negotiation unit 533, or the termination judgment unit 534. For example, the processing unit 53 performs all the processes that the processing unit 13 performs.

[0379] The concession judgment unit 532 determines whether the negotiation information received by the negotiation receiving unit 523 from the respondent satisfies the concession conditions of the condition management unit 512.

[0380] The concession determination unit 532 determines, for example, whether the negotiation information received by the negotiation receiving unit 523 satisfies the first concession condition, which is the first priority concession condition of the condition management unit 512.

[0381] The concession determination unit 532 determines, for example, whether the third negotiation information received by the negotiation receiving unit 523 satisfies the second concession condition, which is the second priority concession condition of the condition management unit 512.

[0382] The automated negotiation unit 533 automatically conducts negotiations with the respondent on behalf of the petitioner, using the concession conditions of the conditions management unit 512.

[0383] For example, if the concession judgment unit 532 determines that the concession conditions are not met, the automated negotiation unit 533 acquires second negotiation information, which is new negotiation information based on those concession conditions, and transmits the second negotiation information to the respondent terminal 7.

[0384] For example, if the concession judgment unit 532 determines that the first concession conditions are not met, the automated negotiation unit 533 acquires second negotiation information, which is new negotiation information based on the first concession conditions, and transmits the second negotiation information to the respondent terminal 7.

[0385] For example, if the concession judgment unit 532 determines that the second concession conditions are not met, the automated negotiation unit 533 acquires new negotiation information, which is the fourth negotiation information, based on the second concession conditions, and transmits the fourth negotiation information to the respondent terminal 7.

[0386] For example, if the concession judgment unit 532 determines that the concession conditions are not met, the automated negotiation unit 533 uses the negotiation information received by the negotiation receiving unit 523 to generate new negotiation information, which is new negotiation information based on those concession conditions, and transmits the second negotiation information to the respondent terminal 7.

[0387] The termination determination unit 534 determines whether or not the conditions for automatic negotiation termination are met. For example, the termination determination unit 534 determines whether or not the third negotiation information received by the negotiation receiving unit 523 satisfies the conditions for automatic negotiation termination.

[0388] The transmitting unit 54 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.

[0389] The negotiation information output unit 544 transmits third-party negotiation information to the applicant when the termination determination unit 534 determines that the conditions for automatic negotiation termination have been met. The negotiation information output unit 544 performs all the processing that the negotiation information output unit 144 would normally perform.

[0390] Here, "output" typically refers to transmission to the petitioner's terminal 6 or the respondent's terminal 7. 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 the petitioner's terminal 6 or the respondent's terminal 7.

[0391] The storage unit 51, the claim management unit 511, and the condition management unit 512 are preferably made of non-volatile recording media, but can also be made of volatile recording media.

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

[0393] The receiving unit 52, negotiation receiving unit 523, and condition receiving unit 521 are usually implemented by wireless or wired communication means, but may also be implemented by means of receiving broadcasts.

[0394] The processing unit 53, condition storage unit 531, concession judgment unit 532, automatic negotiation unit 533, and termination judgment 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.

[0395] The transmitting unit 54 and the negotiation information output unit 544 are usually implemented by wireless or wired communication means, but may also be implemented by broadcasting means.

[0396] Next, an example of the operation of the negotiation support device 5 will be explained using the flowchart in Figure 36. In the flowchart in Figure 36, the explanation will be omitted for steps that are the same as those in the flowcharts in Figures 4 and 5. Here, if it is determined in step S417 that the "agreement conditions are not met", the process proceeds to step S3601.

[0397] In the flowchart steps shown in Figures 4 and 5, the claim is referred to as the petition, the creditor as the petitioner, the debtor as the respondent, creditor terminal 2 as petitioner terminal 6, debtor terminal 3 as respondent terminal 7, the claim management unit 111 as petition management unit 511, the claim status information as petition status information, the claim content information as petition content information, the claim identifier as petition identifier, the creditor identifier as petitioner identifier, and the debtor identifier as respondent identifier.

[0398] (Step S3601) The automated negotiation unit 533 determines in step S411 whether the negotiation receiving unit 523 has received negotiation information from the respondent terminal 7. If it has been received from the respondent terminal 7, the process proceeds to step S3602; if it has been received from the petitioner terminal 6, the process proceeds to step S3609.

[0399] (Step S3602) The automated negotiation unit 533 determines whether or not to perform automated negotiation. An example of such automated negotiation determination process will be explained using the flowchart in Figure 37.

[0400] (Step S3603) If the result of the decision in step S3602 is "Do not negotiate automatically", proceed to step S3604; if it is "Negotiate automatically", proceed to step S3608.

[0401] (Step S3604) The negotiation information output unit 544 obtains the petitioner identifier that corresponds to the petition identifier paired with the received negotiation information.

[0402] (Step S3605) The negotiation information output unit 544 constitutes notification information, which is information containing the received negotiation information and is to be notified to the applicant. The notification information here only needs to contain the negotiation information. For example, the notification information may contain information about the respondent who sent the negotiation information.

[0403] (Step S3606) The negotiation information output unit 544 transmits the notification information configured in step S360 to the applicant identified by the applicant identifier obtained in step S3604.

[0404] (Step S3607) The automated negotiation unit 533 deletes the automated negotiation flag associated with the claim identifier that is paired with the received negotiation information. The process returns to step S401.

[0405] (Step S3608) The automated negotiation unit 533 performs automated negotiation processing. An example of automated negotiation processing will be explained using the flowchart in Figure 38.

[0406] (Step S3609) The negotiation information output unit 544 obtains the respondent identifier that corresponds to the claim identifier paired with the received negotiation information.

[0407] (Step S3610) The negotiation information output unit 544 transmits the received negotiation information to the respondent identified by the respondent identifier obtained in step S3609. Return to step S401.

[0408] (Step S3611) The condition receiving unit 521 determines whether it has received one or more concession conditions from the applicant terminal 6. If concession conditions have been received, the unit proceeds to step S3612; otherwise, it returns to step S401.

[0409] (Step S3612) The condition storage unit 531 stores the one or more concession conditions received in step S3611 in the condition management unit 512, associating them with the claim identifier that corresponds to the concession conditions received in step S3611. Return to step S401.

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

[0411] Next, an example of the automated negotiation decision process in step S3602 will be explained using the flowchart in Figure 37.

[0412] (Step S3701) The automated negotiation unit 533 obtains the claim identifier associated with the received negotiation information.

[0413] (Step S3702) The automated negotiation unit 533 determines whether the application identified by the application identifier obtained in step S3701 is currently under automated negotiation. If it is under automated negotiation, the unit proceeds to step S3703; otherwise, the unit proceeds to step S3710.

[0414] In this process, the automated negotiation unit 533 determines, for example, whether an automated negotiation flag corresponding to the claim identifier exists in the storage unit 51. If the automated negotiation flag exists in the storage unit 51, the automated negotiation unit 533 determines that "automatic negotiation is in progress," and if it does not exist, it determines that "automatic negotiation is not in progress." In addition, the automated negotiation unit 533 obtains, for example, status information indicating the status of the negotiation, which is paired with the claim identifier, from the storage unit 51, and determines whether the status information indicates "automatic negotiation is in progress."

[0415] (Step S3703) The automated negotiation unit 533 assigns 1 to counter i.

[0416] (Step S3704) The automatic negotiation unit 533 determines whether or not the i-th automatic negotiation termination condition exists in the storage unit 51. If the i-th automatic negotiation termination condition exists, the unit proceeds to step S3705; otherwise, the unit proceeds to step S3711.

[0417] (Step S3705) The automatic negotiation unit 533 obtains the i-th automatic negotiation termination condition from the storage unit 51.

[0418] (Step S3706) The automated negotiation unit 533 obtains information to be used to determine the i-th automated negotiation termination condition.

[0419] (Step S3707) The automated negotiation unit 533 determines whether the information obtained in step S3706 satisfies the i-th automated negotiation termination condition. If the i-th automated negotiation termination condition is met, the unit proceeds to step S3708; otherwise, it proceeds to step S3709.

[0420] (Step S3708) The automated negotiation unit 533 assigns "Do not negotiate automatically (for example, "0")" to the variable "Decision Result".

[0421] (Step S3709) The automated negotiation unit 533 increments counter i by 1. Return to step S3704.

[0422] (Step S3710) The automated negotiation unit 533 determines whether a concession condition corresponding to the claimant identifier obtained in step S3701 exists in the conditions management unit 512. If a concession condition exists, the process proceeds to step S3711; otherwise, the process proceeds to step S3708.

[0423] (Step S3711) The automated negotiation unit 533 assigns "Negotiate automatically (for example, "1")" to the variable "Decision Result".

[0424] (Step S3712) The automated negotiation unit 533 associates an automated negotiation flag with the claim identifier and adds it. It then returns to the higher-level processing. If an automated negotiation flag is already associated with the claim identifier, the automated negotiation unit 533 does nothing, for example.

[0425] Next, an example of the automated negotiation process in step S3608 will be explained using the flowchart in Figure 38.

[0426] (Step S3801) The automated negotiation unit 533 obtains the negotiation information received from the respondent in step S411.

[0427] (Step S3802) The automated negotiation unit 533 acquires the applicant's negotiation information. An example of this applicant negotiation information acquisition process will be explained using the flowcharts in Figures 39 and 40.

[0428] (Step S3803) The automated negotiation unit 533 obtains a respondent identifier that corresponds to the negotiation information received from the respondent.

[0429] (Step S3804) The automated negotiation unit 533 transmits the negotiation information obtained in step S3802 to the respondent identified by the respondent identifier.

[0430] (Step S3805) The automated negotiation unit 533 increments the automated negotiation count associated with the petition identifier associated with the negotiation information received from the respondent by 1. It returns to the higher-level process. The automated negotiation count associated with the petition identifier is used, for example, to determine the conditions for terminating automated negotiations.

[0431] Next, we will explain the first example of the petitioner negotiation information acquisition process in step S3802 using the flowchart in Figure 39.

[0432] (Step S3901) The automated negotiation unit 533 obtains the claim identifier. The automated negotiation unit 533 obtains the concession conditions that correspond to the obtained claim identifier from the conditions management unit 512.

[0433] (Step S3902) The automated negotiation unit 533 determines whether the negotiation information sent by the respondent satisfies the concession conditions obtained in step S3901. If the concession conditions are met, the process proceeds to step S3912; otherwise, it proceeds to step S3903.

[0434] (Step S3903) The automated negotiation unit 533 assigns 1 to counter i.

[0435] (Step S3904) The automated negotiation unit 533 determines whether or not item i exists in the negotiation information sent by the respondent. If item i exists, proceed to step S3905; otherwise, proceed to step S3911.

[0436] The items that exist are predetermined. For example, there are four items in total: an item for the total amount to be paid, an item for the number of payments, an item for the amount of each payment, and an item for whether or not to request mediation or arbitration by a lawyer.

[0437] (Step S3905) The automated negotiation unit 533 retrieves information from the i-th item of the negotiation information sent by the respondent.

[0438] (Step S3906) The automated negotiation unit 533 obtains the partial condition of the i-th item from the concession conditions obtained in step S3901.

[0439] Note that the automated negotiation unit 533 may not be able to obtain the partial condition of the i-th item.

[0440] (Step S3907) The automated negotiation unit 533 determines whether the information of the i-th item in the negotiation information satisfies the partial condition of the i-th item obtained in step S3906. If the partial condition is satisfied, the unit proceeds to step S3908; otherwise, the unit proceeds to step S3909.

[0441] If the partial condition could not be obtained in step S3906, for example, the automated negotiation unit 533 is assumed to satisfy the partial condition, and the process proceeds to step S3908.

[0442] (Step S3908) The automated negotiation unit 533 obtains the information of the i-th item in the negotiation information and temporarily stores it in a buffer (not shown). Proceed to step S3910.

[0443] (Step S3909) The automated negotiation unit 533 obtains the content of the partial condition from the i-th item as information for the i-th item and temporarily stores the information in a buffer (not shown).

[0444] (Step S3910) The automated negotiation unit 533 increments counter i by 1. Return to step S3904.

[0445] (Step S3911) The automated negotiation unit 533 uses the information of one or more items temporarily stored in a buffer (not shown) to construct negotiation information that includes all of that information. It returns to the higher-level processing. Note that the negotiation information here is, for example, information that contains all of the information of one or more items temporarily stored in a buffer (not shown). The negotiation information here is, for example, information that shows negotiation conditions in which the information of one or more items temporarily stored in a buffer (not shown) is each a partial condition.

[0446] (Step S3912) The automated negotiation unit 533 obtains negotiation information that indicates the acceptance of negotiation information received from the respondent, and to send negotiation information to the respondent. It then returns to the higher-level processing.

[0447] Next, a second example of the petitioner negotiation information acquisition process in step S3802 will be explained using the flowchart in Figure 40.

[0448] (Step S4001) The automated negotiation unit 533 assigns 1 to counter i.

[0449] (Step S4002) The automated negotiation unit 533 obtains the claim identifier of interest. The automated negotiation unit 533 determines whether the i-th priority concession condition that corresponds to the claim identifier exists in the condition management unit 512. If the i-th priority concession condition exists, the process proceeds to step S4003; otherwise, the process proceeds to step S4006.

[0450] (Step S4003) The automated negotiation unit 533 obtains the i-th priority concession condition that corresponds to the claim identifier from the condition management unit 512. The automated negotiation unit 533 determines whether the negotiation information sent by the respondent meets the acceptance criteria for the concession condition. If the acceptance criteria are met, the unit proceeds to step S4004; otherwise, it proceeds to step S4005.

[0451] The adoption conditions are the criteria for selecting concession conditions when constructing negotiation information. For example, the adoption conditions might be "meeting a certain percentage or more of the subconditions of the concession conditions" or "meeting a certain number or more of the subconditions of the concession conditions." The adoption conditions may be the same as the concession conditions themselves.

[0452] (Step S4004) The automated negotiation unit 533 constructs negotiation information using the i-th priority concession condition. It then returns to the higher-level process.

[0453] Furthermore, the automated negotiation unit 533, for example, for each of two or more items in the received negotiation information, replaces the information of items that do not satisfy the partial conditions of the concession conditions with, for example, the content of those partial conditions, and for items that do satisfy the partial conditions of the concession conditions, it adopts the information of those items as they are to constitute negotiation information. If all of the partial conditions of the concession conditions are satisfied, it obtains information indicating that the received negotiation information is adopted as the applicant's negotiation information.

[0454] (Step S4005) The automated negotiation unit 533 increments counter i by 1. Return to step S4002.

[0455] (Step S4006) The automated negotiation unit 533 constructs negotiation information using the concession conditions of the last priority. It returns to the higher-level process.

[0456] Furthermore, the automated negotiation unit 533, for example, for each of two or more items in the received negotiation information, replaces the information of items that do not satisfy the partial conditions of the concession condition of the last priority with, for example, the content of the partial conditions, and for items that do satisfy the partial conditions of the concession condition, it uses the information of the items as they are to construct negotiation information.

[0457] Next, an example of the operation of the petitioner's terminal 6 will be explained using the flowchart in Figure 41. In the flowchart in Figure 41, the explanation will be omitted for steps that are the same as those in the flowchart in Figure 10.

[0458] In the steps of the flowchart in Figure 10, the claim is referred to as the petition, the creditor as the petitioner, the debtor as the respondent, the claim identifier as the petition identifier, the creditor terminal 2 as the petitioner terminal 6, the creditor storage unit 21 as the petitioner storage unit 61, the creditor reception unit 22 as the petitioner reception unit 62, the creditor processing unit 23 as the petitioner processing unit 63, the creditor transmission unit 24 as the petitioner transmission unit 64, the creditor receiving unit 25 as the petitioner receiving unit 65, the creditor output unit 26 as the petitioner output unit 66, and the claim management device 1 as the negotiation support device 5.

[0459] (Step S4101) The petitioner reception unit 62 determines whether it has received one or more concession conditions from the petitioner. If concession conditions have been received, the process proceeds to step S4102; otherwise, it proceeds to step S4103. The received concession conditions are associated with the petition identifier.

[0460] (Step S4102) The petitioner processing unit 63 obtains a petition identifier corresponding to the concession conditions received in step S4101. The petitioner transmission unit 64 transmits the received one or more concession conditions to the negotiation support device 5, associated with the petition identifier. The process returns to step S1001.

[0461] (Step S4103) The petitioner's receiving unit 65 determines whether or not it has received information from the negotiation support device 5. If information has been received, it proceeds to step S4104; otherwise, it returns to step S1001. The information here is, for example, negotiation information transmitted by the respondent.

[0462] (Step S4104) The petitioner processing unit 63 uses the information received in step S4103 to configure the information to be output. The petitioner output unit 66 outputs the information. The process returns to step S1001.

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

[0464] Next, an example of the operation of the respondent's terminal 7 will be explained using the flowchart in Figure 42. In the flowchart in Figure 42, the explanation will be omitted for steps that are the same as those in the flowchart in Figure 11.

[0465] In the steps of the flowchart in Figure 11, the claim is referred to as the petition, the creditor as the petitioner, the debtor as the respondent, the claim identifier as the petition identifier, the debtor terminal 3 as the respondent terminal 7, the debtor storage unit 31 as the respondent storage unit 71, the debtor reception unit 32 as the respondent reception unit 72, the debtor processing unit 33 as the respondent processing unit 73, the debtor transmission unit 34 as the respondent transmission unit 74, the debtor receiving unit 35 as the respondent receiving unit 75, the debtor output unit 36 ​​as the respondent output unit 76, and the claim management device 1 as the negotiation support device 5.

[0466] (Step S4201) The respondent receiving unit 75 determines whether or not it has received information from the negotiation support device 5. If information has been received, it proceeds to step S4202; otherwise, it returns to step S1101. The information here is, for example, negotiation information automatically generated by the negotiation support device 5.

[0467] (Step S4202) The respondent processing unit 73 uses the information received in step S4201 to configure the information to be output. The respondent output unit 76 outputs the information. The process returns to step S1101.

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

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

[0470] The storage unit 51 of the negotiation support device 5 stores the petitioner management table shown in Figure 13.

[0471] Furthermore, the petition management unit 511 of the negotiation support device 5 stores a petition management table having the structure shown in Figure 14. In Figure 14, "claim identifier" is the same as "petition identifier," "claim content information" is the same as "petition content information," "debtor identifier" is the same as "respondent identifier," "debtor information" is the same as "respondent information," "debtor name" is the same as "respondent name," and "claim processing identifier" is the same as "petition processing identifier."

[0472] Furthermore, the condition management unit 512 of the negotiation support device 5 stores the concession condition management table shown in Figure 43. The concession condition management table is a table for managing concession conditions. The concession condition management table is a table that manages one or more records having "ID", "Application Identifier", "Concession Condition", "Priority", and "Status". The "Concession Condition" has "Total Payment Amount Condition", "Number of Installments Condition", "Payment Amount Condition", and "Mediation Condition". "Priority" is information indicating the priority of concession conditions for a single application. "Status" is information indicating whether or not automated negotiation is in progress. Status "1" indicates that automated negotiation is in progress, and status "0" indicates that automated negotiation is not in progress. In this case, the concession conditions in the concession condition management table are information uploaded by the applicant to the negotiation support device 5.

[0473] In the concession conditions management table (Figure 43), the concession conditions for priority "1" of petition identifier "1" indicate that "the maximum number of installments is 5" and "the minimum amount per payment is 20,000 yen." The concession conditions for priority "2" of petition identifier "1" indicate that "the total payment amount of 100,000 yen can be reduced to 80,000 yen, but installments are not permitted." In Figure 43, there are no records matching petition identifier "2." This indicates that negotiations regarding the petition identified by petition identifier "2" are not conducted automatically, but rather between the petitioner and the respondent.

[0474] Furthermore, the storage unit 51 stores "automatic negotiation termination conditions = information indicating that all concession conditions have been applied." In other words, these automatic negotiation termination conditions indicate that, for a given application, if negotiations are not successful after applying all concession conditions associated with the application identifier of that application, the automatic negotiations will terminate and the negotiations will proceed to the applicant and the respondent.

[0475] In the circumstances described above, Tanaka A, who has registered her petitioner information in the negotiation support device 5, logged into the negotiation support device 5 using petitioner terminal 6.

[0476] Then, through the actions of Tanaka A, the petitioner's terminal 6 received screen information for filing the petition from the negotiation support device 5 and output the case registration screen shown in Figure 17.

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

[0478] Next, the petitioner reception unit 62 of the petitioner terminal 6 accepts the case registration in accordance with the instructions of button 1701. The case registration has petition information "<Petition Name> X Company Nonpayment <Petition Amount> 100,000 <Main Payment Due Date> 2924 / 8 / 1 <Petitioner Identifier> C01 ... <Name of Respondent> X Company ... <Respondent's Email Address> yy@x.jp". Next, the petitioner transmission unit 64 transmits the case registration to the negotiation support device 5. Note that the petitioner identifier "C01" is stored, for example, in the petitioner storage unit 61.

[0479] Next, the claim acquisition unit 121 of the negotiation support device 5 receives the case registration from the claimant terminal 6. 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 claim information to be stored as "<Claim Case Name> X Company Nonpayment <Claim Amount> 100,000 <Main Payment Due Date> 2024 / 8 / 1 <Claimant Identifier> C01 ··· <Name of Counterparty> 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 claim identifier "1". Next, the claim storage unit 131 stores the constructed claim information in the claim management table (Figure 14) in pairs with the claim 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.

[0480] Next, the petition notification unit 141 of the negotiation support device 5 configures the notification information as follows. First, the petition 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 petition 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 petition notification unit 141 obtains the respondent's contact information "yy@x.jp" from the petition information. Next, the petition 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".

[0481] Next, the respondent's terminal 7 receives and outputs an email containing notification information (Figure 18) from the negotiation support device 5. The trigger for outputting the notification information on the respondent's terminal 7 is irrelevant.

[0482] 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 respondent terminal 7 receives screen information containing the petition information corresponding to URL 1801 from the negotiation support device 5 and outputs a confirmation screen (Figure 19) based on that screen information. The confirmation screen is a screen for the respondent to confirm the petition. Next, let's assume that Yamada Y looks at the confirmation screen, checks the checkbox 1901 that says "This is a petition against me," and clicks the "Next" button 1902. Then, the respondent reception unit 72 of the respondent terminal 7 receives the confirmation information. Next, the respondent processing unit 73 obtains the petition identifier "1" associated with the screen information. Next, the respondent processing unit 73 constructs the confirmation information to be transmitted "<Confirmation Result> Confirmation <Petition Identifier> 1". Next, the respondent transmission unit 74 transmits the confirmation information to the negotiation support device 5. The confirmation result "Confirmed" indicates that the confirmation has been made, for example, "1".

[0483] Next, the confirmation receiving unit 122 of the negotiation support device 5 receives the confirmation information "<Confirmation Result> Confirmed <Application Identifier> 1" from the respondent terminal 7. Next, the confirmation storage unit 133 acquires the received application 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 combination with the application identifier "1" based on the confirmation information "<Confirmation Result> Confirmed". Also, the update unit 132 updates the phase identifier from "2" to "3".

[0484] Next, the processing unit 53, 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 51. This screen information is screen information for forming the decision screen. The decision screen is a screen for determining the petition processing identifier. Next, the screen transmission unit 142 transmits this screen information to Yamada Y's respondent terminal 7.

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

[0486] Then, Yamada Y. indicated button 2003 from Figure 20. Furthermore, by pressing button 2003, Yamada Y. entered the installment amount to be inquired about, "5000 yen". The respondent reception unit 72 of the respondent terminal 7 then receives the negotiation information "<Application Processing Identifier>3 <Installment Amount>5000". The respondent processing unit 73 obtains the application identifier "1" and constructs the negotiation information to be transmitted "<Application Identifier>1 <Application Processing Identifier>3 <Installment Amount>5000". Next, the respondent transmission unit 74 transmits the negotiation information to the negotiation support device 5.

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

[0488] Next, the proposal content acquisition unit 135 determines that the received negotiation information does not meet the conditions for creating the proposal content.

[0489] Furthermore, the judgment unit 137 determines that the received negotiation information does not conform to the terms of the agreement. Here, the terms of the agreement are defined as "repaying the requested amount of 100,000 yen in a lump sum."

[0490] Next, the automated negotiation unit 533 determines that the negotiation receiving unit 523 has received the negotiation information "<Application Identifier>1 <Application Processing Identifier>3 <Installment Amount>5000" from the respondent terminal 7. Then, the automated negotiation unit 533 performs the automated negotiation decision processing explained using the flowchart in Figure 37. Specifically, the automated negotiation unit 533 obtains the application identifier "1" from the negotiation information. Then, the automated negotiation unit 533 obtains the state "0" which is paired with the application identifier "1" from the concession management table (Figure 43) and determines that the application identified by application identifier "1" is not currently under automated negotiation. Next, the automated negotiation unit 533 detects that a concession condition paired with the application identifier "1" exists in the condition management table (Figure 43) and determines to perform automated negotiation.

[0491] Next, the automated negotiation unit 533 performs the automated negotiation process described using the flowchart in Figure 38. That is, first, the automated negotiation unit 533 obtains negotiation information sent from the respondent. Next, the automated negotiation unit 533 performs the respondent negotiation information acquisition process described using, for example, the flowchart in Figure 39 or Figure 40, and uses the concession conditions paired with the claim identifier "1" and priority "1" to obtain the negotiation information "<Number of installments> 5 installments <Payment amount conditions> Please pay 20,000 yen / installment...".

[0492] Next, the automated negotiation unit 533 obtains the respondent identifier "yy@x.jp" associated with the received negotiation information. Then, the automated negotiation unit 533 sends the negotiation information "<Number of installments> 5 installments <Payment terms> Please pay 20,000 yen per installment." to the respondent identified by the respondent identifier "yy@x.jp". Next, the automated negotiation unit 533 increments the automated negotiation count associated with the claim identifier "1" associated with the received negotiation information by 1.

[0493] Next, the respondent terminal 7 of the respondent "Yamada Y-ko" receives and outputs the negotiation information. An example of such output is shown in Figure 24. An example of the proposed content in Figure 24 (the proposed content in the box that says "We have proposed changing the installment amount to 20,000 yen") is shown in Figure 23.

[0494] Next, let's assume that Yamada Y-ko looked at the screen in Figure 24 and the proposed content in Figure 23, and instructed the user to press the "Accept revised installment amount" button 2401 in Figure 24. Then, Yamada Y-ko's respondent terminal 7 receives the instruction to press the button 2401. Next, the respondent terminal 7 obtains the information "<Negotiation Result> Agreement" associated with button 2401, constructs negotiation information "<Petition Identifier>1 <Negotiation Result> Agreement <Installment Amount>20000 <Respondent Identifier>Company X" containing this information, and transmits it to the negotiation support device 5.

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

[0496] 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 the 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 application management table (Figure 14) paired with the application identifier "1".

[0497] Next, the information acquisition unit 139, in response to the instructions of the respondent (Yoko Yamada) via button 2401 (Figure 24), acquires screen information corresponding to the negotiation information "<Petition Identifier>1 <Negotiation Result>Agreement <Installment Amount>20000 <Respondent Identifier>Company X", which is to be sent to the petitioner. Next, the information transmission unit 147 transmits this screen information to the petitioner's terminal 6.

[0498] Furthermore, the information acquisition unit 139 acquires screen information that allows the respondent to determine the petition processing identifier, in response to the respondent's button 2401 (Figure 24). Next, the information transmission unit 147 transmits the screen information to the respondent's terminal 7.

[0499] Next, the petitioner's terminal 6 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 negotiations leading up to the petition, confirmation of the case, and agreement. Note that in the screen in Figure 25, the information automatically proposed by the negotiation support device 5 (the box in Figure 25 that says "We have proposed changing the installment amount to 20,000 yen") may be output in a different manner (for example, in a more prominent manner) compared to others.

[0500] Let's assume that Tanaka A-ko instructed the user to click the "Check Payment Schedule" button 2501 on the screen shown in Figure 25. The petitioner's terminal 6 then receives the instruction and retrieves and outputs a payment schedule corresponding to that instruction, which is paired with the petition identifier "1" from the negotiation support device 5. An example of such an output payment schedule is shown in Figure 26.

[0501] Furthermore, the respondent terminal 7 receives screen information for determining the petition processing identifier and outputs a screen for determining the petition processing identifier. An example of such a screen is shown in Figure 27.

[0502] Next, it is stated that Yamada Y. instructed the respondent terminal 7 to click the "Pay by bank transfer" button 2701 on the screen shown in Figure 27.

[0503] Next, the respondent terminal 7 receives the instruction and obtains the application processing identifier "B". It should be noted that application processing identifier "A" represents "payment by credit card" and "B" represents "payment by bank transfer". Next, the respondent terminal 7 transmits the application processing identifier "B" to the negotiation support device 5, paired with application identifier "1".

[0504] Next, the negotiation support device 5 receives the application processing identifier "B," etc., and stores the application processing identifier "B" in the application management table (Figure 14) in conjunction with the application identifier "1." As a result of this process, the application processing identifier "3,B" is stored in the record "ID=1" in the application management table.

[0505] Furthermore, the update unit 132 of the negotiation support device 5 updates the phase identifier, which is paired with the claim identifier "1", to "5".

[0506] Next, the information acquisition unit 139 acquires the petitioner identifier "C01," which is paired with the petitioner identifier "1," from the petition management table (Figure 14). Next, the information acquisition unit 139 acquires the recipient information "Bank Account A," which is paired with the petitioner identifier "C01." Next, the information acquisition unit 139 constructs screen information including the recipient information "Bank Account A." Next, the information transmission unit 147 transmits the screen information to the respondent terminal 7.

[0507] Next, the respondent's terminal 7 receives the screen information and outputs the screen shown in Figure 28. In Figure 28, 2801 is the information for "Bank Account A".

[0508] As described above, according to this embodiment, the applicant can automate all or part of the negotiations regarding the processing of their application.

[0509] Furthermore, according to this embodiment, if the automated negotiation process for the petitioner is unsuccessful, the negotiation process can be handed over to the petitioner at an appropriate time.

[0510] Furthermore, according to this embodiment, negotiations on the part of the petitioner regarding the processing of the petition can be carried out more flexibly and automatically.

[0511] Furthermore, according to this embodiment, it is possible to manage the status of an application in two or more phases out of two or more phases until the applicant and the respondent reach an agreement on the application, and to provide a platform for facilitating the processing of the application.

[0512] The software that implements the negotiation support device 5 in this embodiment is as follows: This program is designed to enable a computer that can access a condition management unit, which stores concession conditions that the applicant can make for the processing of the application, to function as an automated negotiation unit. This unit includes a negotiation receiving unit that receives negotiation information regarding the application from the respondent's terminal, a concession determination unit that determines whether the negotiation information received by the negotiation receiving unit satisfies the concession conditions in the condition management unit, and, if the concession determination unit determines that the concession conditions are not met, an automated negotiation unit that acquires new negotiation information, namely second negotiation information, based on the concession conditions, and transmits the second negotiation information to the respondent's terminal.

[0513] Figure 44 is a block diagram of a computer system 300 that executes the program described herein to realize the negotiation support device 5 and the like of the various embodiments described above.

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

[0515] In Figure 44, 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.

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

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

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

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

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

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

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

[0523] As described above, the negotiation support device 5 according to the present invention has the effect of automating negotiations regarding the processing of the application for the applicant, and is useful as a server or the like that supports negotiations regarding the processing of the application. [Explanation of Symbols]

[0524] C Information Systems 2. Petitioner's terminal 3. Respondent's terminal 5 Negotiation support device 51 Storage Unit 52 Receiving section 53 Processing Unit 54 Transmitter 111 Complaint Management Department 121 Petition Acquisition Department 122 Confirmation Receiving Unit 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 141. Notification of Petition Department 142 Screen transmission unit 143 Proposal Submission Section 145 Required Information Transmission Unit 146 Agreement Document Output Section 147 Information Transmission Section 511 Condition Management Department 521 Condition receiving unit 523 Negotiation Reception Department 531 Condition storage unit 532 Concession Judgment Section 533 Automated Negotiation Department 534 Termination Determination Unit 544 Negotiation Information Output Unit

Claims

1. A condition management unit stores concession conditions, which are the conditions that the applicant can make to process the application. A negotiation receiving unit that receives negotiation information regarding the petitioner's petition from the respondent's terminal, A concession determination unit determines whether the negotiation information received by the negotiation receiving unit satisfies the concession conditions of the condition management unit, A negotiation support device comprising: an automated negotiation unit that, when the concession determination unit determines that the concession conditions are not met, acquires second negotiation information, which is new negotiation information based on the concession conditions, and performs automated negotiation processing to transmit the second negotiation information to the respondent's terminal.

2. The aforementioned negotiation receiving unit, After the automated negotiation unit transmits the second negotiation information to the respondent's terminal, it receives new negotiation information, the third negotiation information, from the respondent's terminal. The negotiation receiving unit determines whether the third negotiation information received satisfies the conditions for automatic negotiation termination, The negotiation support device according to claim 1, further comprising: a negotiation information output unit that transmits the third negotiation information to the applicant's terminal when the termination determination unit determines that the automatic negotiation termination conditions are met.

3. The aforementioned condition management unit includes: Two or more concession conditions with priority are stored, The aforementioned concession determination unit, The negotiation receiving unit determines whether the negotiation information received satisfies the first concession condition, which is the first priority concession condition of the condition management unit. The aforementioned automated negotiation unit, If the concession determination unit determines that the first concession conditions are not met, it acquires second negotiation information, which is new negotiation information based on the first concession conditions, and transmits the second negotiation information to the respondent's terminal. The aforementioned negotiation receiving unit, After the automated negotiation unit transmits the second negotiation information to the respondent's terminal, it receives the third negotiation information from the respondent's terminal. The aforementioned concession determination unit, The negotiation receiving unit determines whether the third negotiation information received satisfies the second concession condition, which is the second priority concession condition of the condition management unit. The aforementioned automated negotiation unit, The negotiation support device according to claim 1, wherein if the concession determination unit determines that the second concession condition is not met, it acquires fourth negotiation information, which is new negotiation information based on the second concession condition, and transmits the fourth negotiation information to the respondent's terminal.

4. Each of the one or more concession conditions in the aforementioned condition management unit is associated with a claim identifier. The negotiation information received by the negotiation receiving unit includes a claim identifier attached to the time of correspondence. The aforementioned automated negotiation unit, The negotiation support device according to claim 1, wherein the negotiation receiving unit obtains a claim identifier corresponding to the negotiation information received, and if there are no special concession conditions corresponding to the claim identifier, the automatic negotiation process is not performed.

5. The negotiation support device according to claim 1, wherein the aforementioned concession conditions include one or more conditions among the following: a total payment condition, which is a condition relating to the total amount to be paid for the claim; a number of installments condition, which is a condition relating to the number of installments in which payments for the claim are made; a payment amount condition, which is a condition relating to the amount of each payment for the claim; and a mediation condition, which is a condition relating to whether or not to request the mediation or arbitration of a lawyer.

6. The aforementioned automated negotiation unit, The negotiation support device according to claim 1, wherein if the concession determination unit determines that the concession conditions are not met, the negotiation receiving unit generates second negotiation information, which is new negotiation information based on the concession conditions, using the received negotiation information, and transmits the second negotiation information to the respondent terminal.

7. 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, The application management unit stores information associated with an application identifier that identifies the application, and one or more application status pieces of information that can identify the current phase of two or more phases until the applicant and the respondent reach an agreement on the processing of the application. The application storage unit stores the application information acquired by the application acquisition unit, associating it with an application identifier that identifies the application associated with the application information. A petition notification unit, in response to the petition acquisition unit acquiring the petition information, acquires notification information including the petitioner's information identified by the petitioner identifier contained in the petition information and the petition content information, and transmits the notification information to the respondent. A confirmation receiving unit that receives confirmation information regarding the confirmation of the aforementioned petition from the respondent's terminal, A confirmation storage unit acquires the confirmation information to be stored in response to the confirmation receiving unit receiving the confirmation information, associates the confirmation information with the claim identifier, and stores it in the claim management unit; A negotiation storage unit stores the negotiation information received by the negotiation receiving unit in association with a petitioner identifier that identifies the petitioner, a respondent identifier that identifies the respondent, and the petition identifier in the petition management unit. An instruction receiving unit that receives an instruction to output application status information from the applicant's terminal or the respondent's terminal, An information acquisition unit that acquires some or all of the application status information corresponding to the output instruction from the application management unit, The negotiation support device according to claim 1, further comprising an information transmission unit that transmits part or all of the claim status information acquired by the information acquisition unit to the claimant terminal or the respondent terminal.

8. A negotiation support method that performs all processing performed by the negotiation support device described in any one of claims 1 to 7.

9. A program for causing a computer to function as a negotiation support device according to any one of claims 1 to 7.

Images