System for implementing negotiation, method for implementing negotiation, and program

Abstract

To provide a system for implementing a negotiation, a method for implementing a negotiation, and a program.SOLUTION: A system includes a computer readable medium configured to store system instructions thereon for implementing a negotiation, and a processor connected to the computer readable medium. The processor is configured to execute the instructions for preventing a party concerned from repeating an offer during the negotiation unless a predetermined condition is satisfied, and requiring the party concerned to continue to repeat the offer until the end of the negotiation in response to satisfaction of the predetermined condition.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates to negotiation protocols, methods, and systems for implementing same. [Background technology]

[0002] With the increase in commerce using the Internet, there has also been an increase in autonomous negotiations. Autonomous negotiations utilize artificial intelligence (AI) instead of a human negotiator to attempt to reach an agreement between the parties. The AI ​​is used to evaluate a proposal from the other party and then determine a response to the proposal. In some cases, the response is a counterproposal. In some cases, the response is an acceptance of the proposal. In some cases, the response is to terminate the negotiation.

[0003] In some approaches, the AI ​​negotiator is fully trained with the user's preferences and priorities before the start of the negotiation. In some approaches, the AI ​​negotiator includes some small uncertainty about the user's preferences and priorities at the start of the negotiation. In some approaches, the AI ​​negotiator can submit queries to the user to reduce the uncertainty of the user's preferences and priorities. However, the queries only inquire how valuable a particular parameter is to the user, without asking the user's preferences between alternatives. Summary of the Invention [Problem to be solved by the invention]

[0004] Improvements in the usefulness of negotiations are desirable. [Means for solving the problem]

[0005] A first aspect of the present disclosure is a system for conducting a negotiation comprising a computer-readable medium configured to store instructions and a processor coupled to the computer-readable medium, the processor configured to execute the instructions to prevent a party from repeating a proposal during a negotiation unless a predetermined condition is met, and in response to the predetermined condition being met, to request the party to continue repeating the proposal until the negotiation is terminated.

[0006] A second aspect of the present disclosure is a method for conducting a negotiation that includes preventing a party from repeating a proposal during a negotiation unless a predetermined condition is met, and, in response to the predetermined condition being met, requiring the party to continue repeating the proposal until the negotiation is terminated.

[0007] A third aspect of the present disclosure is a program for causing a computer to execute the following: prevent a party from repeating a proposal during the negotiation unless a predetermined condition is met; and, in response to the predetermined condition being met, request the party to continue repeating the proposal until the negotiation is terminated. [Brief description of the drawings]

[0008] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings, in which: It should be noted that, in accordance with standard industry practice, various features have not been drawn to scale, and in fact, dimensions of various features may be arbitrarily expanded or reduced for clarity of illustration. [Figure 1] 1 is a schematic diagram of a negotiation, according to some embodiments. [Diagram 2] 1 is a flowchart of a negotiation protocol, according to some embodiments. [Diagram 3] 1 is a flowchart of a method for determining suggestion validity according to some embodiments. [Figure 4] 1 is a flowchart of a method of suggestion selection according to some embodiments. [Diagram 5] FIG. 1 is a diagram of a graphical user interface (GUI) for participating in automated negotiation, according to some embodiments. [Figure 6] 1 is a graph of the performance of a negotiation protocol compared to other negotiation protocols, according to some embodiments. [Figure 7] 1 is a block diagram of a system for conducting negotiations, according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. Hereinafter, specific examples of components, values, operations, materials, arrangements, etc. will be described to simplify the disclosure. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc. are contemplated. For example, the formation of a first feature above or on a second feature in the following description can include embodiments in which the first and second features are formed in direct contact, and can also include embodiments in which an additional feature may be formed between the first and second features such that the first and second features are not in direct contact. In addition, the disclosure may repeat reference numbers and / or letters in various examples. This repetition is for simplicity and clarity, and does not in itself dictate a relationship between the various embodiments and / or configurations described.

[0010] Negotiations utilizing automated systems are used to increase the speed at which a solution is reached between multiple stakeholders. Each of the stakeholders seeks to maximize the value or utility function of the outcome of the negotiation. However, incentivized participants in some negotiation protocols continually repeat proposals until a deadline, such as the duration of the negotiation or the maximum number of proposals (offers) exchanged, for the negotiation approach. Some negotiations waste 70%-80% of the negotiation period repeating optimal proposals that have already been rejected. Because the other party in the negotiation knows this common policy, each party in the negotiation lacks incentive to make proposals of lower utility until near the end of the negotiation. Negotiation protocols that allow proposal repetition until the risk of the negotiation failing is near, i.e., until the negotiation is nearing a deadline, generate an incentive for each party in the negotiation to repeat the proposal that is most advantageous to that party. This incentivized proposal repetition sometimes reduces the overall utility of the negotiation to both parties. That is, continually making proposals that are sure to be rejected does little to advance negotiations, and then rushing to reach an agreement near the end of the negotiation hinders the ability to explore the outcome space of the negotiation to more fully attempt to find an outcome of higher utility for each of the parties in the negotiation.

[0011] In addition, some negotiation protocols terminate the negotiation when a proposal is accepted. Note that, although this application is not limited to bilateral negotiations, the following description focuses on bilateral negotiations for simplicity. In bilateral negotiations, when a first party makes a proposal that is accepted by a second party, the negotiation terminates when an agreement is reached. However, terminating the negotiation upon the acceptance of the proposal limits the possibility of exploring other proposals that are potentially acceptable to both parties. In some cases, these unexplored proposals result in an overall improvement to the utility of the negotiation to both parties. For example, the utility is improved for one party without adversely affecting the other party, or the utility is improved for both parties. Not exploring these alternative proposals limits the effectiveness of negotiation protocols that terminate immediately upon acceptance.

[0012] In contrast to other negotiation protocols, the present application includes a negotiation protocol that prevents the repetition of a previous proposal. By preventing the repetition of a proposal, the negotiation protocol forces more exploration of the outcome space for each of the parties in the negotiation to help increase the overall utility of the negotiation outcome. When a proposal is repeated, the same proposal is maintained until the negotiation is terminated. Maintaining the same proposal, when repeated, signals to the other party in the negotiation that no more alternative proposals are coming. This helps reduce uncertainty from non-offering parties and potentially shorten the duration of the negotiation. Also, in contrast to other negotiation protocols, the present application includes a negotiation policy that accepts all reasonable proposals (acceptable proposals), but does not terminate the negotiation upon the mere acceptance of a reasonable proposal. A reasonable proposal includes a proposal that is an acceptable outcome for a party, even if that proposal is not the most favorable outcome. By accepting all reasonable proposals and continuing the negotiation after acceptance, the outcome space is more fully explored and the overall utility of the negotiation is improved compared to other negotiation protocols.

[0013] FIG. 1 is a schematic diagram of a negotiation 100 using an autonomous negotiation method, according to some embodiments. The negotiation 100 includes a first negotiator 110 that includes a first policy 112. The negotiation 100 includes a second negotiator 120 that includes a second policy 122. A protocol 130 is used to determine a style of negotiation between the first negotiator 110 and the second negotiator 120. A domain 140 includes a problem to be solved in the negotiation 100. The negotiation 100 is a bilateral negotiation. However, the present disclosure is not limited to only bilateral scenarios.

[0014] The first negotiator 110 includes an AI algorithm for determining priorities for the problems to be solved. These priorities are captured in a utility value associated with each of the problems to be solved. The first negotiator 110 uses these utility values ​​to prioritize possible outcomes from the negotiation 100. The first negotiator 110 can communicate with the second negotiator 120 using a protocol 130. In some embodiments, the first negotiator 110 can communicate wirelessly. In some embodiments, the first negotiator 110 can communicate using a wired connection. In some embodiments, the first negotiator 110 can communicate over the Internet. The first negotiator 110 can send a proposal, a counterproposal, an acceptance, or a rejection to the second negotiator 120. The first negotiator 110 is autonomous, i.e., it operates without user input or control.

[0015] The first policy 112 is an action determined by the first negotiator 110 based on utility values ​​and algorithms used by the first negotiator 110. In some embodiments, the first policy 112 includes an offer, a counteroffer, an acceptance, or a rejection. In some embodiments, the first policy 112 changes during the negotiation 100 based on new information received from the second negotiator 120.

[0016] The second negotiator 120 includes an AI algorithm for determining priorities for the problems to be solved, which are populated using utility values. The second negotiator 120 can communicate with the first negotiator 110 using a protocol 130. In some embodiments, the second negotiator 120 can communicate wirelessly. In some embodiments, the second negotiator 120 can communicate using a wired connection. In some embodiments, the second negotiator 120 can communicate over the Internet. The second negotiator 120 can send a proposal, a counterproposal, an acceptance, or a rejection to the first negotiator 110. In some embodiments, the hardware for the first negotiator 110 is the same as the hardware for the second negotiator 120. In some embodiments, the hardware for the first negotiator 110 is different from the hardware for the second negotiator 120. In some embodiments, the algorithm implemented in the first negotiator 110 is the same as the algorithm implemented in the second negotiator 120. In some embodiments, the algorithm implemented in the first negotiator 110 is different from the algorithm implemented in the second negotiator 120. In some embodiments, the second negotiator 120 is autonomous. In some embodiments, the second negotiator 120 is controlled based on user input.

[0017] The second policy 122 is an action determined by the second negotiator 120 based on the utility values ​​and algorithms used by the second negotiator 120. In some embodiments, the second policy 122 includes an offer, a counteroffer, an acceptance, or a rejection. In some embodiments, the second policy 122 changes during the negotiation 100 based on new information received from the first negotiator 110.

[0018] Protocol 130 is the rules for negotiation 100. For example, in an alternating offers protocol, negotiators, e.g., first negotiator 110 and second negotiator 120, alternately exchange offers. Protocol 130 is established before starting negotiation 100 so that first negotiator 110 and second negotiator 120 know when and whether an offer or reply should be sent. In some embodiments, negotiation protocol 130 includes negotiation protocol 200 (FIG. 2) for determining valid offers, counteroffers, acceptances, and rejections. In some embodiments, protocol 130 includes steps, e.g., a maximum number of offers. In some embodiments, protocol 130 includes a time limit for negotiation 100.

[0019] Domain 140 includes problems to be solved. For example, problems to be solved in some embodiments include price, quantity, brand name, etc. In some embodiments, domain 140 includes a single problem. In some embodiments, domain 140 includes multiple problems. First negotiator 110 and second negotiator 120 each know domain 140 and attribute utility values ​​to combinations of problems to be solved. For example, if domain 140 includes price and brand name and there are two options for each of price and brand name, first negotiator 110 has four different utility values, i.e., one utility value for each possible combination. In some embodiments, first negotiator 110 and second negotiator 120 have a number of utility values ​​that is less than all possible combinations. In some embodiments, the utility values ​​assigned by first negotiator 110 are different from the utility values ​​assigned by second negotiator 120 because the first and second negotiators have different priorities.

[0020] FIG. 2 is a flow chart of negotiation protocol 200, according to some embodiments. In some embodiments, negotiation protocol 200 can be used in negotiation 100 (FIG. 1). In some embodiments, negotiation protocol 200 can be used in negotiations other than negotiation 100 (FIG. 1). Negotiation protocol 200 can be fully implemented using automated negotiations, live human negotiations, automated negotiations monitored by humans, or other suitable negotiations. Negotiation protocol 200 helps to explore more outcome space for a negotiation, which helps to improve the usefulness of the negotiation results to all parties in the negotiation. According to some embodiments, some performance information about negotiation protocol 200 against other negotiation protocols is provided in graph 600 (FIG. 6). In some embodiments, negotiation protocol 200 is implemented using system 700 (FIG. 7). In some embodiments, negotiation protocol 200 is implemented using a system other than system 700 (FIG. 7). In some embodiments, a GUI, such as graphical user interface (GUI) 500 (FIG. 5), is generated during a negotiation conducted using negotiation protocol 200. As noted above, negotiation protocol 200 can be used for negotiations between any number of parties, although the following discussion focuses on bilateral negotiations for simplicity.

[0021] In operation 205, a proposal is received. In some embodiments, the proposal is received wirelessly. In some embodiments, the proposal is received via a wired connection. In some embodiments, the proposal is from the other party in the negotiation. In some embodiments, in response to receiving the proposal, a GUI, such as GUI 500 (FIG. 5), is updated. In some embodiments, a notification to the user is automatically generated in response to receiving the proposal. In some embodiments, the notification includes an audio notification or a visual notification. In some embodiments, the notification is sent to a wireless device accessible by the user and includes instructions to cause the wireless device to automatically announce the notification. In some embodiments involving more than two parties in the negotiation, multiple proposals are received simultaneously. The proposals are processed sequentially based on a predefined order of proposing parties or are processed simultaneously on separate machines or systems.

[0022] In operation 210, a determination is made as to whether the received proposal is a valid proposal. A valid proposal is one that is not a repeat of a previous proposal. Repeat proposals include both proposals that match the proposal immediately preceding the current proposal, as well as proposals that match any proposal from the same party during the entire negotiation. In some embodiments where the domain includes multiple factors, e.g., price and quantity, a difference in any factor constitutes a difference in the proposal. That is, if the combination of factors in the proposal is different from the combination of factors in all previous proposals, the proposal is valid. For example, in a situation where a first proposal includes a price of $10, a quantity of 100, and a delivery time of 2 weeks, and a second proposal includes a price of $10, a quantity of 100, and a delivery time of 1 week, the second proposal is a valid proposal. Similarly, a third proposal that includes a price of $10, a quantity of 110, and a delivery time of 2 weeks also constitutes a valid proposal. In some embodiments, the determination of whether a proposal is valid is based on a method 300 (FIG. 3) described below.

[0023] In response to a determination that the proposal is valid, ie, "yes," negotiation protocol 200 proceeds to operation 215. In response to a determination that the proposal is invalid, ie, "no," negotiation protocol 200 proceeds to operation 255.

[0024] In operation 215, the next negotiator is selected. The next negotiator selection includes determining an algorithm to be utilized to determine a counter-proposal in response to the proposal received from operation 205 and determining the counter-proposal. In some cases, operation 215 includes maintaining the same negotiator used to create at least one previous counter-proposal. In some cases, during the course of the negotiation, operation 215 results in a change from a first negotiator to a second negotiator in a subsequent iteration of the negotiation using the negotiation protocol 200, and later back to the first negotiator. In some embodiments, the parties include only a single algorithm for determining a counter-proposal, and operation 215 includes only determining the counter-proposal. In some embodiments, the change in the negotiator is determined based on a trend in the usefulness of previously received proposals. In some embodiments, the change in the negotiator is determined based on input received from a user. In some embodiments, the change in the negotiator is determined based on the remaining duration of the negotiation, e.g., the duration or the number of proposals.

[0025] Once a decision is made regarding whether to change negotiators, if more than one negotiator is available, the selected negotiator uses an algorithm to determine a counterproposal based on the received valid proposal. In some embodiments, the counterproposal includes an acceptance of the received valid proposal. In some embodiments, the counterproposal includes at least one difference from the received valid proposal. In some embodiments, the negotiator accepts all reasonable proposals, i.e., if the received valid proposal is a reasonable proposal, the counterproposal is an acceptance of the received valid proposal. In some embodiments, the negotiator is prevented from repeating a previous proposal if another reasonable proposal that has not been made is available. A reasonable proposal is one that falls within an acceptable outcome space for the parties to the negotiation. The acceptable outcome space is predetermined by a user prior to the negotiation. In some embodiments, the acceptable outcome space is determined based on a utility value of the proposal ranging from 0.0 to 1.0. In some embodiments, the acceptable utility value is predetermined by a user. In some embodiments, the acceptable utility value is 0.2 or greater. If the utility value is lower than the acceptable utility value, then the value of failure of negotiation with the party is greater than the value of the received proposal. If no other reasonable proposals are available, the counter-proposal is a repeat of a previous proposal, such as the most recent proposal from the party that received the proposal in operation 205. If the counter-proposal is a repeat of a previous proposal from the same party, then the counter-proposal continues to repeat the same proposal until the negotiation is terminated. In some embodiments, the algorithm for determining the counter-proposal is based on method 400 (FIG. 4). In some embodiments, a different algorithm than method 400 (FIG. 4) is utilized to determine the counter-proposal.

[0026] At operation 220, the counter-proposal is received by the other party or parties to the negotiation. In some embodiments, the counter-proposal is received wirelessly. In some embodiments, the counter-proposal is received via a wired connection. In some embodiments, in response to receiving the counter-proposal, a GUI, such as GUI 500 (FIG. 5), is updated. In some embodiments, in response to receiving the counter-proposal, a notification to the user is automatically generated. In some embodiments, the notification includes an audio notification or a visual notification. In some embodiments, the notification is sent to a wireless device accessible by the user and includes instructions to cause the wireless device to automatically announce the notification.

[0027] At operation 225, a determination is made as to whether the counteroffer is an acceptance. In some embodiments, the determination is made based on a comparison of the values ​​for each of the factors of the counteroffer to the values ​​for each of the factors of the proposal to determine whether the counteroffer is an acceptance. In some embodiments, the determination is made based on other information in the counteroffer that indicates acceptance.

[0028] In response to a determination that the counter-offer is an acceptance, ie, a "yes," negotiation protocol 200 proceeds to operation 230. In response to a determination that the counter-offer is not an acceptance, ie, a "no," negotiation protocol 200 proceeds to operation 235.

[0029] At operation 230, a determination is made as to whether all parties have accepted the proposal. In a bilateral negotiation, the results of operations 225 and 230 will be the same. In a negotiation involving three or more parties, the results of operations 230 and 225 may be different. In some embodiments, the determination is made based on a comparison of the values ​​for each of the factors of the counterproposal with the values ​​for each of the factors of the most recent proposal from each party to determine whether the counterproposal is an acceptance. In some embodiments, the determination is made based on other information in the counterproposal that indicates acceptance.

[0030] In response to all parties accepting, i.e., a "yes" determination, negotiation protocol 200 proceeds to operation 250. In some embodiments, including bilateral negotiations, operation 230 is omitted. According to some embodiments, in response to fewer than all parties accepting, i.e., a "no" determination, negotiation protocol 200 proceeds to operation 205. According to some embodiments, in response to fewer than all parties accepting, i.e., a "no" determination, negotiation protocol 200 proceeds to operation 215.

[0031] In operation 235, a determination is made as to whether the counterproposal is a valid counterproposal. In some embodiments, the analysis in operation 235 is the same analysis as in operation 210. In some embodiments, the analysis in operation 235 is different from the analysis in operation 210. A valid counterproposal is a counterproposal that is not a repeat of a previous proposal from the counterproposal party. Repeat counterproposals include both counterproposals that match a proposal immediately preceding the current counterproposal, as well as counterproposals that match any proposal from the same party during the entire negotiation. In some embodiments where the domain includes multiple factors, e.g., price and quantity, a difference in any factor constitutes a difference in the counterproposal. In some embodiments, the determination of whether the counterproposal is valid is based on method 300 (FIG. 3) described below.

[0032] In response to a determination that the counter-offer is valid, ie, "yes," negotiation protocol 200 proceeds to operation 240. In response to a determination that the counter-offer is invalid, ie, "no," negotiation protocol 200 proceeds to operation 255.

[0033] At operation 240, a determination is made as to whether all parties have repeated proposals. In other words, a determination is made as to whether all parties have made invalid proposals. In some embodiments, the analysis at operation 240 is the same analysis at operation 210 or operation 235 that is applied to all parties. In some embodiments, the analysis at operation 240 is different from the analysis at operation 210 or operation 235 and is applied to all parties. In some embodiments, the determination of whether all parties have repeated is based on method 300 (FIG. 3), described below.

[0034] In response to all parties having repeated the proposal, i.e., a "yes" determination, negotiation protocol 200 proceeds to operation 255. In response to fewer than all parties having repeated the proposal, i.e., a "no" determination, negotiation protocol 200 proceeds to operation 215.

[0035] At operation 250, a decision is made to accept either the proposal received at operation 205 or the counter-proposal received at operation 220, whichever is most recent. In some embodiments, in response to the decision to accept, a GUI, such as GUI 500 (FIG. 5), is updated. In some embodiments, a notification to the user is automatically generated in response to the decision to accept. In some embodiments, the notification includes an audio notification or a visual notification. In some embodiments, the notification is sent to a wireless device accessible by the user and includes instructions to cause the wireless device to automatically announce the notification.

[0036] At operation 255, no acceptance or a failure of the negotiation is determined. In some embodiments, in response to the determination of no acceptance, a GUI, such as GUI 500 (FIG. 5), is updated. In some embodiments, a notification to the user is automatically generated in response to the determination of no acceptance. In some embodiments, the notification includes an audio notification or a visual notification. In some embodiments, the notification is sent to a wireless device accessible by the user and includes instructions to cause the wireless device to automatically announce the notification.

[0037] In some embodiments, negotiation protocol 200 includes additional operations. For example, in some embodiments, negotiation protocol 200 includes soliciting input from a user in a user-monitored negotiation. In some embodiments, at least one of the operations of negotiation protocol 200 is omitted. For example, in some embodiments, operation 230 is omitted in a bilateral negotiation. In some embodiments, the order of operations of negotiation protocol 200 is modified. For example, in some embodiments, operation 235 is performed before operation 225, and a determination is made regarding the validity of the counter-offer before determining whether the counter-offer is an acceptance.

[0038] Negotiation protocol 200 helps explore more outcome space for a negotiation compared to other approaches. By reducing proposal iterations until a final iterative proposal is made, a party cannot "waste time" during a negotiation by repeating the highest utility proposal that was rejected until the end of the negotiation is near. With the reduction in proposal iterations, there is also no disincentive for the other party to similarly decline to adjust the proposal until the end of the negotiation is near. As a result, the overall utility of the negotiation is improved compared to other approaches. Furthermore, as a party begins to iterate on proposals, the other party in the negotiation has an improved understanding of the priorities of the iterating party, which helps reduce the length of the negotiation and save time and resources consumed by the negotiation. According to some embodiments, evidence of the improvement in overall utility and duration of negotiation protocol 200 compared to other approaches is provided in graph 600 (FIG. 6).

[0039] 3 is a flowchart of a method 300 for determining proposal validity, according to some embodiments. In some embodiments, method 300 can be used in negotiation 100 (FIG. 1). In some embodiments, method 300 can be used in negotiations other than negotiation 100 (FIG. 1). In some embodiments, method 300 is implemented during negotiation protocol 200 (FIG. 2). In some embodiments, method 300 is implemented in a negotiation protocol other than negotiation protocol 200 (FIG. 2). In some embodiments, method 300 is implemented using system 700 (FIG. 7). In some embodiments, method 300 is implemented using a system other than system 700 (FIG. 7).

[0040] At operation 305, a determination is made as to whether the proposal is acceptable. An acceptable proposal is one that includes acceptable values ​​for each of the factors in the domain. That is, the proposal includes a value for each factor in the domain, where each value is acceptable according to the parameters of the negotiation. For example, in a domain that includes price and quantity, a proposal that includes a value for price but not a value for quantity is an unacceptable proposal. Similarly, if the parameters of the negotiation specify that the maximum quantity is 100 units, and the proposal includes a value for price and a quantity value of 150 units, the proposal is an unacceptable proposal. In some embodiments, the parameters of the negotiation are predetermined by the parties prior to the negotiation. In some embodiments, the parameters of the negotiation are determined based on the ability of the parties to meet the values. For example, if a party is capable of producing a maximum of 100 units and the proposal is for 150 units, the party is unable to meet the criteria of the proposal and the proposal is deemed unacceptable.

[0041] In response to a determination that the proposal is an acceptable proposal, i.e., "yes," method 300 proceeds to operation 310. In response to a determination that the proposal is an unacceptable proposal, i.e., "no," method 300 outputs an indication that the proposal is not a valid proposal. For example, in the situation where method 300 is utilized in operation 210 (FIG. 2), the determination of the validity of the proposal is "no" and negotiation protocol 200 proceeds to operation 255.

[0042] At operation 310, a determination is made as to whether the proposal is a repeat proposal. As discussed above, a repeat proposal is a combination of values ​​and factors that match a proposal previously received from the same party. Repeat proposals include both proposals that match the proposal immediately preceding the current proposal, as well as proposals that match any proposal from the same party that does not match the last proposal received from that party during the entire negotiation. In some embodiments where the domain includes multiple factors, e.g., price and quantity, a difference in any factor constitutes a difference in the proposal. That is, if the combination of factors in the proposal is different from the combination of factors in all previous proposals, the proposal is valid.

[0043] In response to a determination that the proposal is not a repeat proposal, i.e., "yes," method 300 outputs an indication that the proposal is valid. For example, in the context in which method 300 is utilized in operation 210 (FIG. 2), the determination of the validity of the proposal is "yes," and negotiation protocol 200 proceeds to operation 215. In response to a determination that the proposal is a repeat proposal, i.e., "no," method 300 outputs an indication that the proposal is not a valid proposal. For example, in the context in which method 300 is utilized in operation 210 (FIG. 2), the determination of the validity of the proposal is "no," and negotiation protocol 200 proceeds to operation 255.

[0044] In some embodiments, the determination of method 300, i.e., a valid or invalid suggestion, prompts the generation of a notification. In some embodiments, the notification includes an audio or visual notification. In some embodiments, the notification is sent to a wireless device accessible by the user and includes instructions to cause the wireless device to automatically announce the notification. In some embodiments, a GUI, such as GUI 500 (FIG. 5), is updated based on the determination of method 300.

[0045] In some embodiments, method 300 includes additional operations. For example, in some embodiments, the method includes generating and sending a notification. In some embodiments, at least one of the operations of method 300 is omitted. For example, in some embodiments, operation 305 is omitted and a negotiation protocol, such as negotiation protocol 200 (FIG. 2) utilizing method 300, declines to accept an unacceptable proposal. In some embodiments, the order of operations of method 300 is modified. For example, in some embodiments, operation 310 is performed before operation 305.

[0046] Method 300 helps explore more outcome space for negotiations compared to other approaches. By reducing proposal iterations until a final iterative proposal is made, parties are prevented from "wasting time" during negotiations by repeating the highest utility proposal that was rejected until the end of the negotiation is near. With the reduction in proposal iterations, there is also no disincentive for the other party to similarly decline to adjust the proposal until the end of the negotiation is near. As a result, the overall utility of the negotiation is improved compared to other approaches. Furthermore, as a party begins to iterate proposals, the other party in the negotiation has an improved understanding of the priorities of the iterating party, which helps reduce the length of the negotiation and save time and resources consumed by the negotiation. According to some embodiments, evidence of the improvement in the overall utility and duration of a negotiation protocol utilizing method 300 compared to other approaches is provided in graph 600 (FIG. 6).

[0047] FIG. 4 is a flow chart of a method 400 of proposal selection, according to some embodiments. In some embodiments, method 400 can be used in negotiation 100 (FIG. 1). In some embodiments, method 400 can be used in negotiations other than negotiation 100 (FIG. 1). In some embodiments, method 400 is implemented during negotiation protocol 200 (FIG. 2). In some embodiments, method 400 is implemented in a negotiation protocol other than negotiation protocol 200 (FIG. 2). In some embodiments, method 400 is implemented using system 700 (FIG. 7). In some embodiments, method 400 is implemented using a system other than system 700 (FIG. 7). In some embodiments, method 400 is utilized by all parties in a negotiation. In some embodiments, method 400 is utilized by fewer than all parties in a negotiation.

[0048] At operation 405, a proposal policy is generated. The proposal policy is generated using an algorithm selected by a user or using a trained neural network or other machine learning method. In some embodiments, the algorithm remains constant throughout the negotiation. In some embodiments, the algorithm changes over the course of the negotiation. The proposal policy is generated based on the usefulness of the proposal to the parties to attempt to maximize the value of the outcome of the negotiation. In some embodiments, the proposal policy is generated in a manner similar to operation 215 (FIG. 2).

[0049] At operation 410, a determination is made as to whether a suggestion has been made previously. The determination as to whether a suggestion has been made previously is based on whether the values ​​of each of the factors in the domain match corresponding values ​​for the factors in the domain from a previous suggestion. In some embodiments, the determination as to whether a suggestion has been made previously is similar to the determination at operation 210 (FIG. 2).

[0050] In response to a determination that a suggestion has not been previously made, i.e., a "no", the method 400 proceeds to operation 435. In response to a determination that a suggestion has been previously made, i.e., a "yes", the method 400 proceeds to operation 415.

[0051] At operation 415, a determination is made as to whether all possible proposals have been made; i.e., every combination of values ​​and factors in the domain has been explored by previous proposals during the negotiation. In some embodiments, all possible proposals include both reasonable and unsuitable proposals (unacceptable proposals). That is, all possible proposals include proposals that have utility values ​​both above and below a predetermined acceptable utility value.

[0052] In response to a determination that all proposals have been made, i.e., a "yes" determination, method 400 proceeds to operation 435. That is, the proposal issued at operation 435 is a repeat of the previous proposal. In some embodiments in which method 400 is utilized in negotiation protocol 200 (FIG. 2), the repeat proposal issued at operation 435 is continually repeated until the negotiation is terminated. In response to a determination that fewer than all possible proposals have been made, i.e., a "no" determination, method 400 proceeds to operation 420.

[0053] At operation 420, a determination is made as to whether the proposal is reasonable. A reasonable proposal is one that has a utility value equal to or greater than an acceptable utility value for the party making the proposal. For example, if a party sets a minimum acceptable utility value at 0.2, then any proposal with a utility value equal to or greater than 0.2 will be a reasonable proposal, and any proposal with a utility value less than 0.2 will be an inappropriate proposal.

[0054] In response to a determination that the suggestion was unreasonable, i.e., "no," the method 400 proceeds to operation 425. In response to a determination that the suggestion was reasonable, i.e., "yes," the method 400 proceeds to operation 430.

[0055] In operation 425, the proposal having the closest utility value to the inappropriate proposal is selected. The negotiator, running an algorithm for proposal selection, adjusts the proposal to be as similar as possible to the proposal policy in operation 405. The negotiator adjusts the value for each factor in the domain until the smallest difference in utility values ​​is determined. During operation 425, all previous proposals are removed from consideration. In operation 425, the proposal selected is potentially irrational as well as potentially rational.

[0056] In operation 430, the valid proposal having the closest utility value to the valid proposal is selected. The negotiator, running an algorithm for proposal selection, adjusts the proposal to be as similar as possible to the proposal policy in operation 405. The negotiator adjusts the value for each factor in the domain until the smallest difference in utility values ​​is determined. During operation 425, all previous proposals are removed from consideration. In operation 430, the selected proposal is reasonable.

[0057] At operation 435, a proposal is issued to the other party in the negotiation. In some embodiments, the proposal is transmitted wirelessly. In some embodiments, the proposal is transmitted over a wired connection. In some embodiments, a GUI, such as GUI 500 (FIG. 5), is updated in response to the issuance of the proposal. In some embodiments, the issuance of the proposal further includes automatically generating a notification. In some embodiments, the notification includes an audio notification or a visual notification. In some embodiments, the notification is sent to a device accessible by the user, and the notification includes instructions to cause the wireless device to automatically show the notification.

[0058] In some embodiments, method 400 includes additional operations. For example, in some embodiments, method 400 includes prompting the user for approval of the suggestion before publication. In some embodiments, at least one of the operations of method 400 is omitted. For example, in some embodiments, operation 420 is omitted and operations 425 and 430 are combined into a single operation for selecting the suggestion having the closest utility value. In some embodiments, the order of operations of method 400 is modified. For example, in some embodiments, operation 420 is performed before operation 415.

[0059] Method 400 helps explore more outcome space for negotiations compared to other approaches. By reducing proposal iterations until a final iterative proposal is made, parties are prevented from "wasting time" during negotiations by repeating the highest utility proposal that was rejected until the end of the negotiation is near. With the reduction in proposal iterations, there is also no disincentive for the other party to similarly decline to adjust the proposal until the end of the negotiation is near. As a result, the overall utility of the negotiation is improved compared to other approaches. Furthermore, as a party begins to iterate proposals, the other party in the negotiation has an improved understanding of the priorities of the iterating party, which helps reduce the length of the negotiation and save time and resources consumed by the negotiation. According to some embodiments, evidence of the improvement in the overall utility and duration of a negotiation protocol utilizing method 400 compared to other approaches is provided in graph 600 (FIG. 6).

[0060] FIG. 5 is an illustration of a graphical user interface (GUI) 500 for accompanying an automated negotiation, according to some embodiments. GUI 500 is usable to allow a human to track an ongoing negotiation. GUI 500 is usable to allow a human to interact during an ongoing negotiation. In some embodiments, GUI 500 is usable in negotiation 100 (FIG. 1). In some embodiments, GUI 500 is usable in negotiations other than negotiation 100 (FIG. 1). In some embodiments, GUI 500 is usable during negotiation protocol 200 (FIG. 2). In some embodiments, GUI 500 is usable in negotiation protocols other than negotiation protocol 200 (FIG. 2). In some embodiments, GUI 500 is usable during method 400 (FIG. 4). In some embodiments, GUI 500 is usable in methods other than method 400 (FIG. 4). In some embodiments, GUI 500 is implemented using system 700 (FIG. 7). In some embodiments, GUI 500 is implemented using systems other than system 700 (FIG. 7). In some embodiments, the GUI 500 is utilized by all parties in a negotiation. In some embodiments, the GUI 500 is utilized by fewer than all parties in a negotiation.

[0061] The GUI 500 includes a chat box 510. The chat box 510 includes each proposal and counterproposal made during the negotiation along with whether either the proposal or counterproposal was accepted or rejected. Each proposal 512 in the chat box is distinguished from each counterproposal 516. In some embodiments, the proposal 512 is on a first side of the chat box 510 and the counterproposal 516 is on an opposite side of the chat box 510. In some embodiments, the proposal 512 is highlighted in a different color than the counterproposal 516. In some embodiments, the proposal 512 is in a different font style or font color than the counterproposal 516. One of ordinary skill in the art will recognize that the above distinctions are not exhaustive and other distinctions are within the scope of this specification. The chat box 510 further includes indications of acceptance 514 and rejection 518 of the corresponding proposal 512 or counterproposal 516. In some embodiments, the acceptance 514 and rejection 518 are indicated by icons, text, or other suitable indications separate from the proposal 512 and counterproposal 516. In some embodiments, acceptance 514 and rejection 518 are indicated by direct modifications to the proposal 512 or counterproposal 516, such as highlighting, bolding, underlining, or other suitable indication. In some embodiments, the chat box 510 further includes additional information, such as a note associated with the proposal 512 or counterproposal 516. In some embodiments, the note includes information such as "Agreement if accepted," a utility value of the proposal to the user, or other suitable information.

[0062] The GUI 500 further includes a proposal input field 520 for receiving a next proposal from a user. In some embodiments, the proposal input field 520 is automatically populated when the GUI 500 is controlled during an automated negotiation. In some embodiments, the proposal input field 520 is configured to receive input from a user when human interaction is permitted during a negotiation. In some embodiments, the user enters a command or takes an action to switch between a fully automated negotiation and a negotiation that allows human interaction. In some embodiments, the proposal input field 520 is editable by a user only during a negotiation that allows human interaction. In some embodiments, the proposal input field 520 is configured to generate a notification, such as an audio or visual notification, in response to the proposal in the proposal input field 520 being a repeat proposal. In some embodiments, the GUI 500 is configured to prompt the user to confirm the issuance of the repeat proposal before issuing the repeat proposal in response to receiving a confirmation from the user.

[0063] GUI 500 further includes a trends field 530. Trends field 530 includes information that allows a user to determine how a negotiation has progressed over time. In some embodiments, trends field 530 includes one or more graphs. In some embodiments, the graphs displayed in trends field 530 are selectable by the user.

[0064] The trends field 530 of FIG. 5 includes a first graph 532 showing utility values ​​to the user for each proposal and counterproposal, and predicted utility values ​​to another party for each proposal and counterproposal. In some embodiments, the predicted utility values ​​are based on empirical data from previous negotiations, analysis of proposals received from the other party during the negotiation, or other suitable information. In some embodiments, the predicted utility values ​​are determined using a trained neural network. In some embodiments, the first graph 532 further includes an estimated efficient solution boundary (optimal solution boundary graph, frontier plot). The estimated efficient solution boundary indicates a predicted acceptable outcome space for both parties in the negotiation. That is, the acceptable outcome space is the area under the estimated efficient solution boundary. In some embodiments, the estimated efficient solution boundary is based on empirical data from previous negotiations, analysis of proposals received from the other party during the negotiation, or other suitable information. In some embodiments, the estimated efficient solution boundary is determined using a trained neural network.

[0065] The trends field 530 of FIG. 5 includes a second graph 534 showing the utility value of each proposal made by the user during the negotiation. The second graph 534 includes a plot of utility value versus time, however, in some embodiments, the plot includes utility value versus negotiation round. In some embodiments, the second graph 534 further includes an acceptable utility value for the user. That is, any utility value above the acceptable utility value has a greater value to the user than a failure to reach an agreement during the negotiation. In some embodiments, the second graph 534 further includes an estimated acceptable utility value for the other party. That is, any utility value above the estimated acceptable utility value for the other party is predicted to have a greater value to the other party than a failure of the negotiation. In some embodiments, the estimated acceptable utility value for the other party is based on empirical data from previous negotiations, an analysis of proposals received from the other party during the negotiation, or other suitable information. In some embodiments, the estimated acceptable utility value for the other party is determined using a trained neural network.

[0066] The trends field 530 of FIG. 5 includes a third graph 536 showing the utility value of each counterproposal made by the other party during the negotiation. The third graph 536 includes a plot of utility value versus time, although in some embodiments, the plot includes utility value versus negotiation round. In some embodiments, the third graph 536 further includes an acceptable utility value for the user. That is, any utility value above the acceptable utility value has a greater value to the user than a failure to reach an agreement during the negotiation. In some embodiments, the third graph 536 further includes an estimated acceptable utility value for the other party. That is, any utility value above the estimated acceptable utility value for the other party is predicted to have a greater value to the other party than a failure of the negotiation. In some embodiments, the estimated acceptable utility value for the other party is based on empirical data from previous negotiations, an analysis of proposals received from the other party during the negotiation, or other suitable information. In some embodiments, the estimated acceptable utility value for the other party is determined using a trained neural network.

[0067] Those skilled in the art will appreciate that the particular graphs mentioned for the trends field 530 are merely examples and that other graphs are within the scope of the present disclosure.

[0068] The GUI 500 further includes a first list 540. The first list 540 includes a list of potential proposals that are predicted to be accepted by the other party if proposed by the user. The first list 540 provides a tool for the user to review potential proposals for input into the proposal input field 520. The first list 540 includes a plurality of entries 542. Each entry 542 includes a proposal and a corresponding proposal utility value. In some embodiments, an entry 542 is removed from the first list 540 in response to the entry 542 being proposed to the other party in the negotiation. In some embodiments, the first list 540 is populated using a trained neural network based on an analysis of utility values ​​acceptable to the user as well as current and / or previous negotiations with the other party. In some embodiments, the user can automatically populate the proposal input field 520 by selecting an entry 542 in the first list 540.

[0069] The GUI 500 further includes a second list 550. The second list 550 includes a list of potential counter-proposals acceptable to the user. The second list 550 provides a tool for the user to preview the potential counter-proposals and / or populate the proposal input field 520. The second list 550 includes a plurality of entries 552. Each entry 552 includes a proposal and a corresponding proposal utility value. In some embodiments, an entry 552 is removed from the second list 550 in response to the entry 552 being proposed by the other party in the negotiation. In some embodiments, the second list 550 is populated using a trained neural network based on an analysis of utility values ​​acceptable to the user as well as current and / or previous negotiations with the other party. In some embodiments, the user can automatically populate the proposal input field 520 by selecting an entry 552 in the second list 550.

[0070] GUI 500 provides a useful tool for users to monitor automated negotiations, as well as a guide for interacting with negotiations that allow for human interaction. By tracking proposals, counterproposals, and utility value predictions for the other party, GUI 500 enables its users to determine which parts of the outcome space have not been explored and to identify potential proposals for shortening the negotiation.

[0071] 6 is a graph 600 of the performance of a negotiation protocol compared to other negotiation protocols, according to some embodiments. Graph 600 includes a bar graph comparing a negotiation protocol described in this application, such as negotiation protocol 200 (FIG. 2), with other negotiation protocols. Graph 600 includes various metrics for evaluating the performance of the negotiation protocol. The metrics are known to those skilled in the art, and only a few of the metrics are described in this application for the sake of brevity.

[0072] Graph 600 compares the negotiation protocol for the present application (TAU) with an alternating proposal protocol (AOP) having a negotiation duration of three minutes (3 min) and AOP with a preset number of rounds of negotiation (n.). TAU performance is the right-most bar for each metric, AOP(3 min) is the middle bar for each metric, and AOP(n.) is the left-most bar for each metric. Graph 600 was generated by conducting automated negotiations utilizing each of the three protocols for domains from the Automated Negotiation Agent Competition (ANAC) for each of the years 2010-2016 and 2019.

[0073] Graph 600 shows higher values ​​in all metrics. Higher values ​​are desired for most metrics, but a smaller information revelation (IRUB) metric is often desired. IRUB is a measure of how much information the other party in the negotiation can obtain about the utility value to the user. Often, the user seeks to reduce the knowledge of the internal evaluation by the other party. However, as clearly shown by metrics such as optimality, welfare, and speed, the TAU protocol significantly outperforms other protocols in actual results. Optimality is a measure of how much the outcome of the negotiation differs from the set of Pareto optimal solutions (the set of Pareto efficient solutions, the Pareto-frontier). Welfare is a measure of the sum of the utility values ​​per party in the negotiation. Speed ​​is a measure of how quickly the negotiation is resolved. Graph 600 provides clear evidence that TAU ​​protocols, such as negotiation protocol 200 (FIG. 2), offer improvements in the technical field of automated negotiations compared to other approaches.

[0074] FIG. 7 is a block diagram of a system 700 for performing negotiations, according to some embodiments. The system 700 includes a hardware processor 702 and a non-transitory computer-readable storage medium 704 encoded with, i.e., storing, a computer program code 706, i.e., a set of executable instructions. The computer-readable storage medium 704 is also encoded with instructions 707 for interfacing with an external device, such as a device accessible by a user. The processor 702 is electrically coupled to the computer-readable storage medium 704 via a bus 708. The processor 702 is also electrically coupled to an input / output (I / O) interface 710 by the bus 708. A network interface 712 is also electrically connected to the processor 702 via the bus 708. The network interface 712 is connected to a network 714 such that the processor 702 and the computer-readable storage medium 704 can connect to external elements via the network 714. The processor 702 is configured to execute computer program code 706 encoded on the computer-readable storage medium 704 to enable the system 700 to perform some or all of the operations described in the negotiation protocol 200 (FIG. 2), the method 300 (FIG. 3), the method 400 (FIG. 4), or the GUI 500 (FIG. 5).

[0075] In some embodiments, the processor 702 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an application specific integrated circuit (ASIC), and / or other suitable processing unit.

[0076] In some embodiments, computer readable storage medium 704 is an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system (or apparatus or device). For example, computer readable storage medium 704 includes a semiconductor or solid state memory, a magnetic tape, a removable computer diskette, a random access memory (RAM), a read only memory (ROM), a rigid magnetic disk, and / or an optical disk. In some embodiments using an optical disk, computer readable storage medium 704 includes a compact disk read only memory (CD-ROM), a compact disk read / write (CD-R / W), and / or a digital video disk (DVD).

[0077] In some embodiments, the storage medium 704 stores computer program code 706 configured to cause the system 700 to perform some or all of the operations described in the negotiation protocol 200 (FIG. 2), the method 300 (FIG. 3), the method 400 (FIG. 4), or the GUI 500 (FIG. 5). In some embodiments, the storage medium 704 also stores information for performing some or all of the operations described in negotiation protocol 200 (FIG. 2), method 300 (FIG. 3), method 400 (FIG. 4), or GUI 500 (FIG. 5), as well as information generated while performing some or all of the operations described in negotiation protocol 200 (FIG. 2), method 300 (FIG. 3), method 400 (FIG. 4), or GUI 500 (FIG. 5), such as proposal parameters 716, previous proposal parameters 718, utility value parameters 720, rational spatial parameters 722, domain parameters 724, and / or a set of executable instructions for performing some or all of the operations described in negotiation protocol 200 (FIG. 2), method 300 (FIG. 3), method 400 (FIG. 4), or GUI 500 (FIG. 5).

[0078] In some embodiments, the storage medium 704 stores instructions 707 for interfacing with an external component. The instructions 707 enable the processor 702 to generate instructions readable by the external component to effectuate some or all of the operations described in the negotiation protocol 200 (FIG. 2), the method 300 (FIG. 3), the method 400 (FIG. 4), or the GUI 500 (FIG. 5).

[0079] System 700 includes an I / O interface 710. The I / O interface 710 is coupled to external circuitry. In some embodiments, the I / O interface 710 includes a keyboard, a keypad, a mouse, a trackball, a trackpad, and / or cursor direction keys for communicating information and commands to processor 702.

[0080] The system 700 also includes a network interface 712 coupled to the processor 702. The network interface 712 enables the system 700 to communicate with a network 714 to which one or more other computer systems are connected. The network interface 712 includes a wireless network interface, such as BLUETOOTH, WIFI, WIMAX, GPRS, or WCDMA, or a wired network interface, such as ETHERNET, USB, or IEEE-1394. In some embodiments, some or all of the operations described in the negotiation protocol 200 (FIG. 2), method 300 (FIG. 3), method 400 (FIG. 4), or GUI 500 (FIG. 5) are implemented in two or more systems 700, and information is exchanged between the different systems 700 via the network 714.

[0081] A part or all of the above-described embodiments can be described as follows, but is not limited to the following.

[0082] (Appendix 1) A computer-readable medium configured to store instructions; a processor coupled to the computer-readable medium; Equipped with The processor, Prevents parties from repeating proposals during negotiations unless certain conditions are met; In response to the predetermined condition being satisfied, requesting the parties to continue repeating the proposal until the negotiation is terminated. configured to execute the instructions for: A system for conducting negotiations.

[0083] (Appendix 2) 2. The system of claim 1, wherein the predetermined conditions include all acceptable proposals to the party being issued.

[0084] (Appendix 3) The processor, receiving said proposal; determining whether the proposal is valid; In response to determining that the suggestion is valid, generating a response to the suggestion. 2. The system of claim 1, further configured to execute the instructions for:

[0085] (Appendix 4) 4. The system of claim 3, wherein the processor is further configured to execute the instructions for determining whether the proposal is valid based on whether the proposal matches previous proposals from the parties in the negotiation.

[0086] (Appendix 5) The processor, generating said response to said proposal comprising an acceptance in response to said proposal being a valid proposal; generating a response to the proposal that includes a counterproposal in response to the proposal being an inappropriate proposal; 4. The system of claim 3, configured to execute the instructions for:

[0087] (Appendix 6) The processor, all parties in said negotiations decide whether to accept said proposal; generating a second proposal different from the proposal in response to a decision by fewer than all of the parties in the negotiation to accept the proposal; 2. The system of claim 1, further configured to execute the instructions for:

[0088] (Appendix 7) The processor, determining whether all parties in the negotiations have issued reiterated proposals; terminating said negotiations without acceptance in response to a determination that all parties in said negotiations have issued reiterated proposals. 2. The system of claim 1, further configured to execute the instructions for:

[0089] (Appendix 8) Preventing parties from repeating proposals during negotiations unless certain conditions are met; in response to said predetermined condition being satisfied, requiring said parties to continue repeating said proposals until said negotiations are terminated; (a) a method for conducting negotiations, including:

[0090] (Appendix 9) 9. The method of claim 8, wherein the predetermined conditions include all acceptable proposals to the party being issued.

[0091] (Appendix 10) receiving the proposal; and determining whether the proposal is valid; and in response to determining that the suggestion is valid, generating a response to the suggestion; 9. The method of claim 8, further comprising:

[0092] (Appendix 11) 11. The method of claim 10, further comprising determining whether the proposal is valid based on whether the proposal matches previous proposals from the parties in the negotiation.

[0093] (Appendix 12) generating the response to the proposal including an acceptance in response to the proposal being a valid proposal; generating the response to the proposal including a counterproposal in response to the proposal being an inappropriate proposal; 11. The method of claim 10, further comprising:

[0094] (Appendix 13) determining whether all parties in the negotiations will accept the proposal; and generating a second proposal different from the proposal in response to a determination that fewer than all parties in the negotiation accept the proposal; 9. The method of claim 8, further comprising:

[0095] (Appendix 14) determining whether all parties in the negotiations have issued reiterated proposals; in response to a determination that all parties in said negotiations have issued reiterated proposals, terminating said negotiations without acceptance; 9. The method of claim 8, further comprising:

[0096] (Appendix 15) Preventing a party from repeating proposals during said negotiations unless certain conditions are met; In response to the predetermined condition being satisfied, requesting the parties to continue repeating the proposal until the negotiation is terminated. A program that makes a computer do something.

[0097] (Appendix 16) 16. The program of claim 15, wherein the predetermined conditions include all acceptable proposals to the parties being issued.

[0098] (Appendix 17) receiving said proposal; determining whether the proposal is valid; In response to determining that the suggestion is valid, generating a response to the suggestion. The program of claim 15, further causing the computer to execute the steps of:

[0099] (Appendix 18) 18. The program of claim 17, further causing the computer to determine whether the proposal is valid based on whether the proposal matches previous proposals from the parties in the negotiation.

[0100] (Appendix 19) generating said response to said proposal comprising an acceptance in response to said proposal being a valid proposal; generating a response to the proposal that includes a counterproposal in response to the proposal being an inappropriate proposal; The program of claim 17, further causing the computer to execute the steps of:

[0101] (Appendix 20) all parties in said negotiations decide whether to accept said proposal; generating a second proposal different from the proposal in response to a decision by fewer than all of the parties in the negotiation to accept the proposal; The program according to claim 15, further causing the computer to execute the steps of:

[0102] (Appendix 21) The system for conducting negotiations includes a (non-transitory) computer-readable medium configured to store instructions. The system further includes a processor connected to the (non-transitory) computer-readable medium. The processor is configured to execute the instructions for generating a proposed policy using an algorithm. The processor is further configured to execute instructions for determining whether the generated proposed policy has been previously proposed during the negotiation. The processor is further configured to execute instructions for issuing the generated proposed policy in response to a determination that the proposal has not been previously proposed during the negotiation. The processor is further configured to execute instructions for modifying the generated proposed policy to a second proposed policy based on a utility value of the second proposed policy in response to a determination that the proposal has been previously proposed during the negotiation. The processor is further configured to execute instructions for issuing the second proposed policy following modification of the generated proposed policy.

[0103] (Appendix 22) A system for conducting negotiations includes a (non-transitory) computer readable medium configured to store instructions. The system further includes a processor connected to the (non-transitory) computer readable medium. The processor is configured to execute the instructions for receiving a proposal. The processor is further configured to execute instructions for deciding whether to accept the proposal. The processor is further configured to execute instructions for generating a counter-proposal. The processor is further configured to execute instructions for receiving a response to the counter-proposal. The processor is further configured to execute instructions for updating a graphical user interface (GUI) after receiving the response, the GUI including a list of the proposal, the decision whether to accept the proposal, the counter-proposal, the response to the counter-proposal, and the proposal predicted to be acceptable to the other party in the negotiation.

[0104] The above outlines the features of some embodiments so that those skilled in the art can better understand the aspects of the present disclosure. Those skilled in the art should understand that the present disclosure can be easily used as a basis for designing or modifying other processes and structures for carrying out the same purpose and / or achieving the same advantages as the embodiments introduced herein. Those skilled in the art should also recognize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the present disclosure.

[0105] This application claims priority to U.S. Patent Application No. 18 / 447,264, filed August 9, 2023, the disclosure of which is incorporated herein in its entirety. [Explanation of symbols]

[0106] 100 Negotiations 110 First Negotiation Tool 112 First Policy 120 The Second Negotiator 122 Second Policy 130 Protocol 140 Domains 200 Negotiation Protocol 205 Operation 210 operation 215 operation 220 operation 225 operation 230 operation 235 operation 240 operation 250 operations 255 operation 300 ways 305 operation 310 operation 400 ways 405 operation 410 operation 415 operation 420 operation 425 operation 430 operation 435 operation 500 Graphical User Interface (GUI) 510 Chat Box 512 Suggestions 514 Accepted 516 Counterproposal 518 Rejected 520 Suggested input fields 530 Trend Field 532 First Graph 534 Second Graph 536 Third Graph 540 First List 542 entries 550 Second List 552 entries 600 graphs 700 System 702 Processor 704 Computer-readable storage medium 706 Computer Program Code 707 Instructions 708 Bus 710 Input / Output (I / O) Interface 712 Network Interface 714 Network 716 Suggested parameters 718 Previously proposed parameters 720 Utility Parameter 722 Reasonable spatial parameters 724 Domain parameters

Claims

1. A computer-readable medium configured to store instructions; a processor coupled to the computer-readable medium; Equipped with The processor, Prevents parties from repeating proposals during negotiations unless certain conditions are met; In response to the predetermined condition being satisfied, requesting the parties to continue repeating the proposal until the negotiation is terminated. configured to execute the instructions for: A system for conducting negotiations.

2. The system of claim 1 , wherein the predetermined conditions include all acceptable proposals to the party being issued.

3. The processor, receiving said proposal; determining whether the proposal is valid; In response to determining that the suggestion is valid, generating a response to the suggestion. The system of claim 1 , further configured to execute the instructions for:

4. 4. The system of claim 3, wherein the processor is further configured to execute the instructions for determining whether the proposal is valid based on whether the proposal matches previous proposals from the parties in the negotiation.

5. The processor, generating said response to said proposal comprising an acceptance in response to said proposal being a valid proposal; generating a response to the proposal that includes a counterproposal in response to the proposal being an inappropriate proposal; The system of claim 3 , configured to execute the instructions for:

6. all parties in the negotiation decide whether to accept the proposal; generating a second proposal different from the proposal in response to a decision by fewer than all of the parties in the negotiation to accept the proposal; The system of claim 1 , further configured to execute the instructions for:

7. The processor, determining whether all parties in the negotiations have issued reiterated proposals; terminating said negotiations without acceptance in response to a determination that all parties in said negotiations have issued reiterated proposals. The system of claim 1 , further configured to execute the instructions for:

8. Preventing parties from repeating proposals during negotiations unless certain conditions are met; in response to said predetermined condition being satisfied, requiring said parties to continue repeating said proposals until said negotiations are terminated; (a) a method for conducting negotiations, including:

9. The method of claim 8 , wherein the predetermined conditions include all acceptable proposals to the party being issued.

10. Preventing a party from repeating proposals during said negotiations unless certain conditions are met; In response to the predetermined condition being satisfied, requesting the parties to continue repeating the proposal until the negotiation is terminated. A program that makes a computer do something.

Images