WO2020077441A1

WO2020077441A1 - Electronic negotiation system that automatically determines and retracts conflicting offers after offer acceptance to avoid overcommitment without restricting negotiations

Info

Publication number: WO2020077441A1
Application number: PCT/CA2019/051436
Authority: WO
Inventors: Vladyslav SHAPOSHNIKOV
Original assignee: Executive Otc Group Inc.
Priority date: 2018-10-17
Filing date: 2019-10-08
Publication date: 2020-04-23

Abstract

An electronic negotiation system applied in a user network includes a controller that stores an initial aggregate limit associated with a first user. The first user sends a plurality of offers to the controller, each of the offers specifying different deal terms. The controller sends the offers to other users and receives a request to accept one of the offers from a second network user. The controller confirms the acceptance and stores a contract between the first and second users. Before processing a next request for offer acceptance, the controller calculates a remaining aggregate limit associated with the first user according to a deal term of the accepted offer. The controller then determines whether any still pending offer by the first user includes a corresponding deal term that exceeds the remaining aggregate limit. When yes, the controller automatically retracts the conflicting offer thereby preventing overcommitment by the first user.

Description

ELECTRONIC NEGOTIATION SYSTEM THAT AUTOMATICALLY DETERMINES AND RETRACTS CONFLICTING OFFERS AFTER OFFER ACCEPTANCE TO AVOID OVERCOMMITMENT WITHOUT

RESTRICTING NEGOTIATIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority of U.S. Provisional Application No. 62/746,740 filed October 17, 2018, which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

(1) Field of the Invention

The invention pertains generally to the field of negotiations and negotiation technology for electronic, online, internet or cloud based negotiations using computing devices such as smart phones, tablets, or laptops. More specifically, the invention relates to systems, methods and apparatuses which connect a network of users allowing for the user network to simultaneously negotiate deals with a plurality of different parties within the network.

(2) Description of the Related Art

Negotiation is a process of discussion aimed to reach an agreement between two or more parties. Bilateral negotiations involve two parties making offers between each other aiming to close a deal, contract, or an agreement; multilateral negotiations involve group discussions to reach a mutual agreement amongst all the parties involved. Negotiations can be a stand-alone bargaining process, or a subprocess of a broader commercial activity, or discussions on government policy, moreover, negotiations are a means of getting to the agreeable terms and conditions of a specific deal, or to reach an agreement between two or more parties. In recent years we have observed a rapid growth of powerful smart phone devices, rise of cloud computing, and social media platforms. Related fields such as data analysis, data migration, video streaming, and global connectivity have all benefited from the rapid growth in information technology (IT). Some areas advance at a different pace than others, and the field of negotiations and negotiation technology is an area that has not yet been properly explored to benefit from the rise of new IT network applications.

Whether aware of it or not, buyers and sellers forming a free market or seeking to do business directly, are always engaged in some kind of negotiation activity prior to finalizing terms of their agreement. The negotiation process results in obtaining documented commitments from the parties involved on the price, terms, and conditions of their deal, which can be in a form of a sales invoice, a contract, policy, or an agreement. Followed by completion of negotiations, electronic commerce processes are engaged where online payments are transferred, providing services described in the contract agreement and facilitating final shipment of goods, or provision of services.

A typical e-commerce website allows sellers to post ads for products and services. Buyers then make bids and the highest bid wins the auction. United States Patent No. 8,108,284 entitled “METHOD AND SYSTEM FOR IMPLEMENTING AN OFFER/COUNTEROFFER NEGOTIATION” discloses a system where the buyers and sellers can make any number of offers and counteroffers to each other, where each offer can have different terms. When presented with an offer, a user may choose to either accept the offer or propose a counteroffer with an adjusted term. Unlike a simple auction website where the terms are fixed by the seller in the initial posting, the system disclosed in the above patent allows users to negotiate any number of terms back and forth until both parties are happy and a deal is created.

However, although innovations have been made allowing parties to negotiate individual terms and arrive at customized deals acceptable to both parties, problems can still arise as a result of overcommitments and loss of favourable trade deal opportunities. For instance, suppose a first party desires to negotiate bilaterally, with a plurality of other parties simultaneously. In this case, the first party must be very careful to ensure they can meet the terms of the various offers they have made to the other parties.

In other words, in the event that all outstanding offers by the first party were to be accepted by the other parties, the first party needs to be able to meet the terms in aggregate. To use a concrete example, if a first party has only one-hundred apples and wishes to sell all one-hundred apples, the first party must be careful to not simultaneously extend legally binding offers to two separate potential buyers for the full one-hundred apples. To extend two legally binding offers provides broader trade deal opportunities but runs the risk that both other parties might accept the offer and then the first party would be in an overcommitment situation as they only have one-hundred apples to sell, not two hundred that would be needed to fulfil both deals. A similar overcommitment could occur if the first party is a buyer who wishes to buy one-hundred apples. Similar to the above seller example, buyers should not simultaneously make multiple offers that could result in a commitment to buy two-hundred apples if they can only purchase one-hundred apples. Especially when offers represent potentially legally binding contracts if they are accepted, users must actively prevent overcommitment by restricting their negotiations.

When it comes to bilateral negotiations with a plurality of participants that form any type of an online user network, such as a network of users that are part of a client list or a customer relationship database, or a network or a group of social media users with a plurality of participants, each participant will equally and likely seek to maximize the value of their trade deal or contract during the negotiations process. The existing commonplace process is for the participants to limit their negotiations in pursuit of one offer at a time in order to actively mitigate risk of overcommitment, or to extend multiple‘soft’ offers to the participants which would qualify the deal with multiple conditions, requiring further negotiations between the parties. Doing so drastically increases overall time spent on negotiations to reach a favourable deal and can exclude participants from timely considering favourable trade deal opportunities that would have been available if the offered terms were equally extended to the broad or complete population of participants.

Preventing overcommitment can be done in a number of ways but each way involves the user taking responsibility and actively managing their pending offers to prevent overcommitment. Users may serialize their offers by negotiating with one party at a time. However, this option slows the negotiation process and may prevent the user from taking advantage of time sensitive opportunities presented by other parties different than the current party with which the user is negotiating. Likewise, the user may lower or reduce terms in their offers or otherwise ensure they have wide margins of error to cover the situation that multiple of their offers are accepted by different parties. However, this again tends to extend the effort and time required by the user to reach the full amount of goods/services that they desire to purchase or sell. In some cases, the user may simply accept the risk of overcommitment and allow it to potentially happen. This option is generally the best option if the risk is low or the losses could be covered if overcommitment did occur. However, there are situations where the risk of overcommitment may be high and/or the user is unable to fulfd all extended offers and would be forced to renege on one or more of the deals. Reneging on a deal may result in penalties for the user both monetarily and in terms of the user’s reputation. On most systems, when a first user a makes a deal with a second user, the second user expects that deal to be fulfilled and serious losses may be incurred if one of the parties (i.e., the first user) reneges on the deal. In some cases, a user may be forbidden from making future deals if they have previously reengaged on a deal. In short, there are negative social status consequences of breaking a deal and not keeping to one’s word.

BRIEF SUMMARY OF THE INVENTION

It is an object of some embodiments of the invention to provide a controlling apparatus in an electronic negotiation system that allows its users to lead simultaneous bilateral negotiations with multiple participants in the network ecosystem, increasing trade opportunities, and mitigating risks of overcommitment. It is an object of some embodiments of the invention to provide a controlling apparatus in an electronic commerce system that allows users to negotiate while mitigating risk of overcommitment and increasing trade opportunities to allow simultaneous negotiations with multiple participants in the market ecosystem.

It is an object of some embodiments of the invention to protect each user in a negotiation system from overcommitment during negotiations while maximizing favourable trade deal opportunities by simultaneously extending competitive negotiations to multiple participants in a network eco system.

According to an exemplary embodiment of the invention there is disclosed an apparatus facilitating bilateral negotiations between a plurality of parties. The apparatus includes a storage device, a communication interface coupled to a computer network, and a processor coupled to the storage device and the communication interface. By the processor executing a plurality of software instructions loaded from the storage device, the processor is configured to store an initial aggregate limit associated with a first user in the storage device. The processor is further configured to receive a plurality of offers from the first user and store information of the plurality of offers in the storage device. Each of the plurality of offers specifies one or more deal terms, at least some of the deal terms is different for different ones of the plurality of offers, and the information stored in the storage device for each offer includes state information representing whether the offer has been accepted and whether the offer has been retracted. The processor is further configured to send the plurality of offers to a plurality of other users via the communication interface, and to receive a request to accept a selected one of the plurality of offers, the request to accept being received via the communication interface from a second user different than the first user. In response to receiving the request, the processor is configured to check the state information of the selected one of the plurality of offers in the storage device to confirm that the selected one of the plurality offers has not already been accepted and has not already been retracted. In response to confirming that the selected one of the plurality of offers has not already been accepted and has not already been retracted, the processor is configured to store a record of a contract between the first user and the second user in the storage device, the contract including the one or more deal terms of the selected one of the plurality of offers. The processor is further configured to update the state information in the storage device to record that the selected one of the plurality of offers has been accepted, send an acceptance confirmation message to each of the first user and the second user via the communication interface, and calculate a remaining aggregate limit associated with the first user by adjusting the initial aggregate limit according to a particular deal term of the selected one of the plurality of offers. The processor is further configured to determine a set of conflicting offers being remaining offers of the plurality of offers that include a corresponding deal term exceeding the remaining aggregate limit, and automatically update the state information in the storage device to record that each of the set of conflicting offers has been retracted. In this way, once the selected one of the plurality of offers is confirmed to be accepted by the processor, the processor prevents the other users from being able to accept any other of the plurality of the offers from the first user that, if accepted, would cause the first user to have a plurality of contracts that in aggregate would have deal terms that exceed the initial aggregate limit.

According to an exemplary embodiment of the invention there is disclosed a method of facilitating bilateral negotiations between a plurality of parties. The method includes storing an initial aggregate limit associated with a first user in the storage device and receiving a plurality of offers from the first user and store information of the plurality of offers in the storage device. Each of the plurality of offers specifies one or more deal terms, at least some of the deal terms are different for different ones of the plurality of offers, and the information stored in the storage device for each offer includes state information representing whether the offer has been accepted and whether the offer has been retracted. The method further includes sending the plurality of offers to a plurality of other users via a computer network, receiving a request to accept a selected one of the plurality of offers, the request to accept being received via the computer network from a second user different than the first user, and in response to receiving the request, checking the state information of the selected one of the plurality of offers in the storage device to confirm that the selected one of the plurality offers has not already been accepted and has not already been retracted. The method further includes in response to confirming that the selected one of the plurality of offers has not already been accepted and has not already been retracted, storing a record of a contract between the first user and the second user in the storage device, the contract including the one or more deal terms of the selected one of the plurality of offers; updating the state information in the storage device to record that the selected one of the plurality of offers has been accepted, sending an acceptance confirmation message to each of the first user and the second user via the communication interface; calculating a remaining aggregate limit associated with the first user by adjusting the initial aggregate limit according to a particular deal term of the selected one of the plurality of offers; determining a set of conflicting offers being remaining offers of the plurality of offers that include a corresponding deal term exceeding the remaining aggregate limit; and automatically updating the state information in the storage device to record that each of the set of conflicting offers has been retracted. In this way, once the selected one of the plurality of offers is confirmed to be accepted, the other users are prevented from being able to accept any other of the plurality of the offers from the first user that, if accepted, would cause the first user to have a plurality of contracts that in aggregate would have deal terms that exceed the initial aggregate limit.

According to an exemplary embodiment of the invention there is disclosed an electronic negotiation system applied in a user network. The system includes a controller that stores an initial aggregate limit associated with a first user. The first network user sends a plurality of offers to the controller, each of the offers specifying different deal terms. The controller sends the offers to other users and receives a request to accept one of the offers from a second network user. The controller confirms the acceptance and stores a contract between the first and second users. Before processing a next request for offer acceptance, the controller calculates a remaining aggregate limits associated with the first and second users by adjusting their initial aggregate limit according to a deal term of the accepted offer. The controller then determines whether any still pending offer by the first user includes a corresponding deal term that exceeds the remaining aggregate limit. When yes, the controller automatically retracts the conflicting offer thereby preventing overcommitment by the first user. The controller repeats the same steps for the second user, cascading automatic retraction to n-th network user that has been affected by first and second users entering into contract. Offers retracted by the controller 102 are stored as an electronic data record.

According to an exemplary embodiment of the invention there is disclosed a non-transitory processor-readable medium comprising a plurality of processor-executable instructions that when executed by one or more processors cause the one or more processors to perform steps of the above described method.

According to an exemplary embodiment of the invention there is disclosed a Webserver in an electronic over-the-counter (OTC), private contracts market system that performs steps of the above described method.

These and other advantages and embodiments of the present invention will no doubt become apparent to those of ordinary skill in the art after reading the following detailed description of preferred embodiments illustrated in the various figures and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in greater detail with reference to the accompanying drawings which represent preferred embodiments thereof:

FIG. 1 shows an electronic negotiation system that prevents accepted offers from exceeding an aggregate limit during multi-party negotiations according to an exemplary embodiment. FIG. 2 illustrates a block diagram of the controller of FIG. 1 according to an exemplary embodiment.

FIG. 3 illustrates a flowchart describing operations made by a user device of FIG. 1 to make an offer according to an exemplary embodiment.

FIG. 4 illustrates a flowchart describing operations made by a user device of FIG. 1 upon receiving an offer according to an exemplary embodiment.

FIG. 5 illustrates a flowchart describing operations by the controller of FIG. 1 upon receiving a request to accept an offer according to an exemplary embodiment.

FIG. 6 illustrates a flowchart describing operations by the controller of FIG. 2 in order to check for conflicting offers during the check for conflicting offers step of FIG. 5 according to an exemplary embodiment.

FIG. 7 illustrates a first timeline example of a remaining quantity' limit resulting in automatic offer retraction for a plurality of users as seen from the point of view of a first user according to an exemplary embodiment.

FIG. 8 shows the same example as FIG. 7 but from the point of view of second user.

FIG. 9 shows the same example as FIG. 7 but from the point of view of third user.

FIG. 10 show a block diagram of an electronic negotiation system including a plurality of virtualized negotiation systems accessible to users of different social media platforms via an Internet-connected hub according to an exemplary embodiment.

DETAILED DESCRIPTION

FIG. 1 shows an electronic negotiation system 100 that prevents accepted offers from exceeding an aggregate limit during multi-party negotiations according to an exemplary embodiment. The system 100 includes a controller 102 coupled to a computer network 104 such as the Internet, an admin device 112 that is also coupled to the network 104, and a storage device 114 is coupled to the controller 102. The system 100 can operate as a stand-alone module that is connected to or applied to an existing network of users and their devices; or it can be integrated directly into a website, an online market, a user network, a client list, a client relationship database, or a social media network or platform, see FIG.10. Connection to the network of users by plurality of user devices 106 are also shown to the network 104 and can include merchant operated devices 108, client operated devices 110, or any other user operated device not limited to being a merchant or a client, such as a social media user. The user devices 106 are computers or portable electronic devices such as mobile phones carried by users. Although the described merchant devices 108 and client devices 110 are illustrated as separate user devices 106 in FIG. 1, this is for convenience of description only. In actual applications and embodiments, a single user device 106 may at certain times act as a merchant device 108 while at other times acting as a client device 110 that is part of a social media platform, a user group, a client list, or an online network. In fact, a single user device 106 may simultaneously act as a merchant 108 for some deals and act as a client 110 for other deals, not limited to this description.

FIG. 2 illustrates a block diagram of the controller 102 of FIG. 1 according to an exemplary embodiment. The controller 102 in this embodiment is a computer server including one or more processors 200 coupled to one or more communication interfaces 202 and one or more storage devices 114. In this example, the storage devices 114 are a combination random access memory (RAM), magnetic hard drives, and / or FLASH memory within the controller 102; however, in other embodiments, the storage device(s) 114 may also be external to the controller 102 such as coupled to the controller 102 via the network 104.

The one or more processors 200 may be included in a central processor unit (CPU) of a computer server acting as the controller 102. In the following description the plural form of the word“processors” will be utilized as it is common for a CPU of a computer server to have multiple processors 200 (sometimes also referred to as cores); however, it is to be understood that a single processor 200 may also be configured to perform the described functionality of the controller 102 in other implementations.

The storage devices 114 include software instructions 204 that are executed by the processors 200 to perform a variety of operations as described herein. The storage devices 114 also include various data utilized by the processors 200 in conjunction with running the software. Users data 206 stores details of users that use the electronic negotiation system, limits data 208 stores details of various aggregate limits that are managed by the controller 102 for the users when negotiating deals, offers data 210 stores records regarding offers that have been by users to other users, and contracts data 212 stores details of finalized contracts that have been made by the users on the system. Other data 214 may be stored in the storage devices 114 as required.

FIG. 3 illustrates a flowchart describing operations made by a user device 106 to make an offer according to an exemplary embodiment. The steps of FIG. 3 may be performed by one or more processors within a user device 106 while executing software instructions loaded from a storage device. The steps of the flowchart are not restricted to the exact order shown, and, in other configurations, shown steps may be omitted or other intermediate steps added. In some embodiments, the user devices 106 are computing device that execute a web browser in order to access various web pages or a web application provided by the controller 102 acting as a web server on a network 104 such as the Internet. The various steps illustrated in FIG. 3 may also be performed by a predetermined application running on the user device 106 such as a mobile application or software application loaded from either a local hard drive or other storage device within the client device 106, or loaded from a storage device that is coupled to the network 104. In either case, the user device 106 executes one or more instructions that allow the user of the device 106 to initiate creation of a new offer.

The process begins at step 300 when a user device 106 begins the process to make an offer. In this description, user devices 106 operating as both merchants 108 and clients 110 may make offers to other users. An offer represents a potentially legally binding contract. The only thing it is required for an offer to become a legally binding contract is for the offer to be confirmed by the controller 102 as having been properly accepted by another user. Once the controller 102 confirms the acceptance of an offer, the terms of the accepted offer become a legally binding contract between the user that made the offer and the user that accepted the offer. Details of the offers and the states thereof are stored by the controller 102 in the offers data 210 and details of the legally binding contract are stored by the controller 102 in the contracts data 210.

Taking a brand new offer by a merchant 108 as an example, step 300 may be triggered by a user device 106 acting as a merchant 108 creating an initial offer. Initial offers may be initiated by a user of a social media platform, or other type of user network where the merchant 108 provides a description of a product or service along with one or more required terms. The initial offer may be an offer to buy a product or service at a certain price. Alternatively, the initial offer may be to sell a product or service at a certain price. Other terms may also be included such as a quantity of the product or service, quality requirements, a time duration of the offer, a regional location, shipping terms, or any other specific terms as set by the merchant device 108. The term “merchant” in this description represents, but is not limited to, the party that creates the initial offer and is used interchangeable with the merchant device 108, which is the user device 106 under control of the actual merchant user. Typically, the initial offer by a merchant 108 will be a public offer that is visible to other users. The controller 102 sets a public field of the offer to true in the offers data 210 to indicate that the offer is visible to all user devices 106. The other users may search for the initial offer using search terms related to the product or service, may browse available initial offers in various categories, and / or may receive notification messages regarding the newly posted offer. In addition to initial offerings by merchants 108, there are other ways that new offer creation can be triggered at step 300. For instance, another user device 106 may view an initial offer posted by a merchant 108 and decide to make a counteroffer back to the merchant 108. The counteroffer is also an offer that, if confirmed by the controller 102 to be accepted by the merchant 108, will create a legally binding contract between the merchant 108 and the client 110. As such, another way that step 300 can be triggered on a user device 106 is when the user device 106 is acting as a client 110 creating a counteroffer to an initial offer posted by a merchant 108. Typically a counteroffer 110 will be a private offer that is addressed to a specific other user such as a merchant 108 that posted the initial offer. The controller 102 may set the public field to false in the offer data 210 and may set one or more specific target user identifiers to indicate the destination users who able to view and accept the offer.

In yet another example, any user upon receiving a counteroffer, whether merchant 108 or client 110, may still not be happy with the terms of the counteroffer and decide to create yet another counteroffer with one or more adjusted terms. Counteroffers may go back and forth between user devices 106 via the controller 102 as an intermediary as may times as necessary or desired. Each time a new counteroffer is initiated on a user device 106, the process illustrated in FIG. 3 will begin anew at step 300.

At step 302, the user device 106 sends the offer to the controller 102. This step may involve the user device 106 sending information in an offer message to the controller 102 via the computer network. The offer message may include the terms of the offer along with a target user address for private offers. Again, typically an initial offer made by a merchant 108 is a public offer that would not have a specific target user address. In this case, a NULL value or other predetermined wildcard value may be employed in the offer message for the destination to indicate that the offer should be made visible to any interested user. Although initial offers are usually public, it is also possible that a merchant may want to make an initial offer that is only visible to one or more specific other users such as previous client(s) 110 of that merchant 108. In this case, even an initial offer message made by a merchant 108 may include a target user address value.

At step 304, the user device 106 determines whether the offer sent at step 300 has been automatically retracted by the controller 102. Automatic retraction by the controller 102 due to conflicting offers is further explained below with reference to FIG. 5 and FIG. 6; however, at this point it is worthwhile to explain that the controller 102 actively confirms acceptance of offers. Whenever an offer is confirmed by the controller 102 to be accepted, the controller 102 automatically retracts all other offers by the various users that can no longer be accepted without creating an overcommitment situation for at least one user. These are conflicting offers. In the event that the controller 102 automatically retracts a conflicting offer made by a particular user, the controller 102 notifies the user device 106 upon which the particular user is logged in or otherwise associated by sending that user device 106 an automatic offer retraction message. Step 304 of FIG. 3 firstly represents receipt of such a message from the controller 102. If the user device 106 receives a message of automatic retraction from the controller 102, the flowchart proceeds to step 314 to notify the user of the situation; otherwise, if an automatic retraction has not occurred at this point in time, control proceeds to step 306.

At step 306, the user device 106 determines whether the offer sent at step 300 has been expired by the controller 102. Expiry of the offer will be automatically performed by the controller 102 when the expiry time of the offer has been reached and the controller 102 automatically deactivates the offer due to expiry. Deactivation due to offer expiry is similar to automatic retraction of the offer at step 304 in that receiving either an automatic retraction message at step 304 or an expiry message at step 306 indicate that the offer is no longer being made available to other users by the controller 102. If the user device 106 receives a message of offer expiry, control proceeds to step 316 to notify the user of the situation; otherwise, control proceeds to step 308.

At step 308, the user device 106 determines whether the offer sent at step 300 has been confirmed to be accepted by the controller 102. As mentioned above, the controller 102 confirms each offer’s acceptance. Upon an offer being confirmed to be accepted, the controller 102 sends an offer acceptance message to the user device 106 upon which the user that made the offer is logged in or otherwise associated. Step 308 represents receipt of an offer acceptance confirmation from the controller 102. When the user device 106 receives an offer acceptance confirmation message from the controller 102, the flowchart proceeds to step 310 to store the contract; otherwise, control proceeds to step 312.

At step 310, the user device 106 retrieves and stores an electronic copy of the contract created between the user that created the offer at step 300 and the other user that has now been confirmed by the controller 102 to have accepted the offer. In the embodiment of FIG. 3, a local copy of the contract details such as terms of the offer that are now accepted by both parties are stored locally on the user’s device 106. The contract is also stored in the cloud such as in contract data 212 within the storage device of the controller 102.

At step 312, the user device 106 determines whether the user has manually retracted the offer. At any time, the user who made the offer at step 300 may decide to retract the offer. In this case, the retraction is initiated on the user device 106 rather than on the controller 102. If the user has decided to manually retract the offer, control proceeds to step 314; otherwise, control returns back to step 304 to begin the loop again.

At step 314, the user device 106 sends a manual retraction message to the controller 102 via the computer network. In some embodiments, the manual retraction message is timestamped upon receipt by the controller 102. To be valid, manual retraction of the offer must be received by the controller 102 prior to the controller 102 receiving an acceptance of the offer by another user.

At step 316, the user device 106 notifies the user such as via a user interface of the situation. In this embodiment, the offer created at step 300 and sent to the controller 102 at step 302 stays pending an available to other users until it is automatically retracted by the controller 102 (will result in step 304 triggering“yes”), it expires (will result in step 306 triggering“yes”), it is confirmed to be accepted by another user (will result in step 308 triggering“yes”), or it is manually retracted by the user that made the offer (will result in step 312 trigger“yes”). Depending on which path is followed to reach step 316, the user device 106 will notify the user of the appropriate situation, namely, whether the offer was automatically retracted to conflicting with another of the user’s accepted offers, whether the offer expired, whether the offer was confirmed accepted by another user, or whether the offer was successfully manually retracted by the user prior to acceptance.

FIG. 4 illustrates a flowchart describing operations made by a user device 106 upon receiving an offer according to an exemplary embodiment. Similar to FIG. 3, the steps of FIG. 4 may be performed by one or more processors within a user device 106 after executing software instructions loaded from a storage device such as memory. The steps of the flowchart are not restricted to the exact order shown, and, in other configurations, shown steps may be omitted or other intermediate steps added.

The process begins at step 400 when a user device 106 receives an offer. In this description, user devices 106 operating as both merchants and clients may receive offers from other users. For instance, a client 110 may receive an initial offer made by a merchant 108. Likewise, merchants 108 may receive counteroffers made by clients 110. Yet further, merchants 108 and clients 110 may make and receive any number of further counteroffers back and forth between them as negotiations toward a potential deal continue.

At step 402, the user device 106 determines whether the user wishes to accept the offer received at step 400. Acceptance may be initiated by a user clicking an“Accept” button on a user interface of the user device 106, for example. If the user wishes to accept the offer, control proceeds to step 404; otherwise, control proceeds to step 410.

At step 404, the user device 106 sends an offer acceptance request to the controller 102 via the network 104.

At step 406, the user device 106 receives a response back from the controller 102 indicating whether the request to accept the offer has been confirmed or not. When the response received at step 406 is an acceptance confirmation; control proceeds to step 408; otherwise, when the response is an acceptance refusal, control proceeds to step 412 to notify the user.

At step 408, the user device 106 stores a local copy of the contract created between the users as a result of the offer acceptance sent at step 404. This step 408 is the counterpart to step 310 previously described for FIG. 3. Step 310 represents the contract being stored for the party that sent the offer (at step 302) and step 408 represents the contract being stored for the party that sent the acceptance of the offer (at step 404). Again, cloud copies of the contract may also be stored at the controller 102.

At step 410, the user device 106 determines whether the offer is still available. The offer will no longer be available to be accepted after it has been retracted or otherwise deactivated by the controller 102. This step may involve the user device 106 checking to see whether any number of different types of offer cancelation messages have been received from the controller 102. A cancelation message may be sent by the controller 102 in any of the cases where a previously sent offer (received by the user device 106 at step 400) is no longer pending and is therefore no longer available to be accepted. Similar to as shown in the flowchart of FIG. 3 for the party that initiated the offer, an offer will no longer be available after it has been automatically retracted by the controller 102, has expired, has been accepted by another user, or has been manually retracted by the user that made the offer. In each of these cases, an offer cancelation message will be sent by the controller 102 to the user device l06(s) that had previously received the offer. Upon receipt at step 410, the user device 106 may update the user interface to remove the “Accept” button thereby preventing the user from attempting to accept the offer. Control proceeds in this case to step 412 to notify the user. Alternatively, when the offer is still available to be accepted, control returns to step 402 to check if the user now wishes to attempt to accept the offer.

At step 412, the user device 106 notifies the user of the situation depending on the path that was utilized to reach step 412. In this embodiment, upon receipt of an offer (step 400), there are two situations that will occur - either the user will attempt to accept the offer (triggering the“yes” path of step 402) or a message will be received from the controller 102 that the offer is no longer available to be accepted (triggering the“no” path from step 410).

FIG. 5 illustrates a flowchart describing operations by the controller 102 upon receiving a request to accept an offer while facilitating bilateral negotiations between a plurality of parties according to an exemplary embodiment. The steps of FIG. 5 may be performed by the one or more processors within the controller 102 by executing the software instructions loaded from the storage device. The steps of the flowchart are not restricted to the exact order shown, and, in other configurations, shown steps may be omitted or other intermediate steps added.

The process begins at step 500 when the controller 102 receives a request from a user device 106 to accept an offer. The request to accept an offer received at this step corresponds to the request sent by a particular user device 106 at step 404 of FIG. 4. The request to accept an offer may be received from a client 110 such as when the client 110 attempts to accept the initial offer posted by a merchant 108; alternatively, in another example, the request to accept an offer may be received from merchant 108 when the merchant 108 attempts to accept a counteroffer made by a client 110.

At step 502, the controller 102 checks the acceptance requirements to ensure that the acceptance is valid. The acceptance requirements can include any desired requirements, but in this embodiment, the controller 102 time stamps all received acceptance requests at the moment they are received and processes them one by one in order of receipt. In this way, an acceptance request for a particular offer may be denied by the controller 102 if another user managed to already send an acceptance request for that same particular offer. In general, if the offer expired, was automatically retracted, was accepted by another user, or was manually retracted prior to receipt of the acceptance request at step 500, the acceptance request would not meet the requirements of a valid acceptance. The controller 102 may also confirm that none of the deal terms of the offer to be accepted would violate (i.e., exceed) any aggregate limit for either user involved in the potentially accepted offer according to the limits data 208.

At step 504, the controller 102 determines whether the results of the check performed at step 502 are positive or negative. When the acceptance is confirmed as valid, control proceeds to step 508; alternatively, if acceptance is not confirmed as valid, control proceeds to step 506.

At step 506, because acceptance was not confirmed as valid by the controller 102, the controller 102 sends an acceptance refusal message to the user device 106 from which the acceptance request was received at step 500. At step 508, in response to acceptance being confirmed valid, the controller 102 begins performing an automatic conflicting offer retraction process. The automatic conflicting offer retraction process is performed by the controller 102 in this embodiment immediately after and in response to an offer being confirmed accepted by the controller 102 (“yes” branch from step 504). The sub-steps of the automatic conflicting offer retraction process are performed as part of the acceptance process prior to the controller 102 processing any further acceptance requests. The first step 508 involves the controller 102 updating the limit threshold(s) for each of the users involved in the newly accepted offer.

In order to avoid overcommitment, limits data 208 are stored and actively managed by the controller 102. The limits stored therein are user-specific and may be tied to users and / or specific deals that a particular user is trying to close. For instance, if a particular user desires to purchase a predetermined quantity of a product or service from other users, the particular user may set an aggregate quantity limit equal to the amount of product or service they wish to purchase. Setting of the aggregate limit can be done by the user prior to making any offers; for instance, the user may configure their limit prior to creating a first offer at step 300. Additionally, setting of the aggregate limit can also be done by the user prior to accepting any offers; for instance, the user may configure their limit prior to attempting to accept an offer at step 402. Assuming the limit is configured prior to either of these steps, the controller 102 is then in a position to automatically manage the limit and ensure that no offers will be accepted by any party that, if accepted, would result in the particular exceeding their aggregate quantity limit.

In addition to quantity limits, total price, cost, or any other aggregate limits may also be configured in a similar manner. For instance, a user may wish to purchase up to a certain dollar amount of product or service and want to ensure they do not overspend above the total cost limit. Both merchants and clients may set limits and the controller 102 will manage the limits for all affected users regardless of whether the affected user is one of the direct parties involved a newly accepted offer. Each user can have any number of predetermined aggregate limits configured and stored in the limits data 210 for enforcement by the controller 102.

A usage example to help illustrate the above is as follows. Suppose a user has a project to buy 100 Apples. The project’s limit of 100 Apples is stored in the limits data 208 for the user. The user creates an initial offer (or“new listing” or“new project”, which are different terms referring to the initial offer) and publicly lists it as BUY, 100 apples, at $l/apple. Acting as a merchant 108, the user listed the project which is caused by the controller 102 to show up in the public catalogue for anyone to accept terms as they are or to send the first user offers. The same user now acting as a client 110 goes to the public catalogue and sees which other users are selling apples. At this point, the user sends offers for price and/or quantity for which the user is offering to buy. When the user sends offers to other users, for every sent offer, the controller 102 links this offer to the original listing by the user, i.e., links the offer to the project of buying 100 apples, which thereby links these offers to the limit of 100 apples stored in the limits data 108. This link means that if an offer that the user has sent to other users is accepted, the controller 102 will automatically update the initial listing and the remaining limit 208 for the first user to reflect acceptance of the offer. At the same time, if a sent offer is accepted by another user, the controller will 1) check for any conflicting offers based on revised limits 208 and retract them, and 2) if the project was fulfilled (i.e., the user has now bought 100 apples or more), the controller 102 will automatically retract all offers and remove the user’s initial offer from the public catalogue. In this way, the user is continuing to receive offers and is able to send offers for as long as the project is not fulfilled. The user relies on the controller 102 and the electronic negotiation system 100 to retract any offers that could result in over-commitment all without restricting the user’s negotiations to maximize favourable trade deal opportunities.

The updating that occurs at step 508 involves the controller 102 calculating a remaining aggregate limit based on the offer that was newly confirmed to be accepted at step 504. The calculating of the remaining aggregate limit is similar to a remaining amount or quantity that is still available to the user(s) after the terms of the newly accepted offer are taken in account. For instance, if a particular user has an aggregate limit to sell one-hundred apples, after an offer extended by another user to purchase eighty apples is accepted by the particular user, the remaining apples that are available to be sold is twenty apples. The controller 102 also updates the initial offer (i.e. my Project) to only 20 apples required, instead of 100. The value of twenty apples is calculated by the controller 102 subtracting the quantity deal term (eighty apples) specified in the newly accepted offer from the previously stored aggregate limit (one-hundred apples). The deal terms that are utilized correspond to the type of the aggregate limit. In other words, if the aggregate limit represents a quantity, then the deal term related to quantity from the newly accepted offer will be utilized when updating the aggregate limit to form a remaining aggregate limit. The aggregate limit represents an economic (resource) constraint that is identified as part of the terms of the deal, measured, and set as a value by the user. The constraint that is selected as an aggregate limit can be, but not limited to, a resource quantity, product quantity, transportation capacity, money, cost, time, etc. Aggregate limit may also be set at value of one (1), such as one unique real estate property, one unique resource, or entire quantity, in which case the aggregate limit for a quantity of 100 apples would be set at one, meaning that the deal is negotiated for the entire quantity of 100 apples or no deal. Likewise, if the aggregate limit represents a monetary value such as cost, then the corresponding monetary value or cost of the newly accepted offer will be used by the controller 102 when updating this aggregate limit to form a remaining aggregate limit.

Because the newly accepted offer involves two users, i.e., the originator of the offer and the party that accepts the offer, an accepted offer will result in the controller 102 updating one or more remaining aggregate limits for the two different users that are directly involved in the offer. For example, the purchaser may have an aggregate maximum number of apples they are willing to purchase and the seller may have an aggregate maximum number of apples available to sell. After a deal is made between these two parties, the controller 102 will subtract the number of apples involved in the deal from the target number of apples limit for the purchaser and subtract the number of apples involved in the deal from the maximum number of apples limit for the seller.

In addition to each user having a single aggregate limit, it is also possible that each user can have multiple aggregate limits configured and the controller 102 at step 508 will make adjustments to update each of the user’s aggregate limits according to the various deal terms. For instance, a user may have preconfigured both a total aggregate cost limit and a total aggregate quantity limit. Once an offer involving that user is accepted by either the user or another party, the controller 102 will update both the total cost limit and the total quantity limit by calculating new total cost and quantity thresholds. Similar updating of any aggregate limits for the other user involved in the accepted offer are done by the controller 102 at the same time.

At step 510, the controller 102 checks the offers data 210 in the storage device 114 to determine whether there are any still pending offers that now conflict the newly updated aggregate limits, i.e., the remaining aggregate limits calculated at step 508. Step 510 is further explained in the flowchart of FIG. 6; however, briefly stated, the controller 102 determines at step 510 a set of conflicting offers that are remaining offers still pending between users that include at least one deal term that, if accepted, would exceed one of the remaining aggregate limits of the user that made the offer.

At step 512, the controller 102 determines whether any conflicting offers were found at step 510. For instance, if the set of conflicting offers is a non-empty set, this means at least one still pending offer for one of the involved users would cause an overcommitment situation if accepted; in this case, control proceeds to step 514. Alternatively, if the set of conflicting offers determined at step 510 is an empty set, this means there are no conflicting offers for the users involved in the now accepted offer and control proceeds to step 516.

At step 514, the controller 102 retracts each of the set of conflicting offers determined at step 510. The retraction process firstly involves the controller 102 updating a record of each conflicting offer in the offers data 210 in storage device 114 to change the offer status to “retracted”. In this way, none of the conflicting offers can be accepted because they will not pass the acceptance requirements check performed by the controller 102 at step 502. Because the offer acceptance messages received by the controller 102 are processed in order of receipt, even if a user has already requested to accept a conflicting offer retracted at step 514, the controller 102 will mark the conflicting offer as “retracted” prior to confirming acceptance and no overcommitment situation will occur. Thus, even if a user requests to accept an offer, the request would not be approved by the controller in the case the offer was automatically retracted by the controller 102 prior to acceptance request.

Retracting conflicting offers at step 514 may also involve any number of desired sub-step (not shown) such as sending automatic retraction messages to both the parties involved in the offer. For instance, the controller 102 may send an automatic retraction message to the originator of the offer, which will be received by the originating user device 106 at step 304 of FIG. 3. Likewise, the controller 102 may send an automatic offer retraction message to the recipient of the offer, which will be received by the offer recipient user device 106 at step 410 of FIG. 4. By sending offer retraction messages, the user devices 106 involved in the offer can immediately update their user interfaces to show that the offer is no longer available to be accepted and can notify the respective users.

To facilitate a positive user experience, in preferred embodiments, the various devices of the system 100 including the controller 102 and the user devices 106 actively prevent users from attempting to accept offers that have already been retracted or that are no longer available. However, as previously explained, even if a race condition occurs where multiple user devices 106 send messages attempting to accept conflicting offers before the controller 102 has a chance to notify them that the offers have been retraced, the controller 102 will still prevent overcommitment by simply refusing to confirm acceptance of any later-accepted offers that would conflict with an already accepted offer or that have already been confirmed accepted by another user. In this way, acceptance is a race to the controller 102 where the earlier the acceptance message is received by the controller 102, the higher the likelihood that the controller 102 will confirm acceptance. Acceptance confirmation is a bullet proof Yes or No process meaning the first confirmed acceptance with the controller 102 wins the acceptance race.

At step 516, the controller 102 marks the offer that was confirmed accepted at step 504 as “accepted” in the offer record stored in the offers data 210 of the storage device 114. This step may also involve the controller 102 sending an offer acceptance confirmation message to the user devices 106 of both parties involved in the offer.

At step 518, the controller 102 creates a contract between the users involved in the newly accepted offer. This step may also involve the controller 102 sending a copy of the contract details to the user devices 106 of both parties involved in the deal.

In some embodiments, the controller 102 performs all steps from step 508 to step 516 immediately in response to an offer being accepted and before the controller 102 processes a next offer acceptance request. In this way, upon confirmed offer acceptance, the accepted offer and all conflicting offers that would exceed any remaining aggregate limits for any users are no longer available to be accepted by other users. In this sequence, the offer that was accepted by the controller is marked with a time stamp that is earlier than the subsequent requests of offer acceptance. The controller 102 thereby prevents users from exceeding their aggregate limits and prevents multiple users from accepting a single offer. Beneficially, the controller 102 allows users to extend and accept offers freely without needing to worry about getting stuck in an overcommitment situation.

In some embodiments, in addition to utilizing a time stamp added to the request, the controller 102 locks out the particular offer to which the acceptance request is directed for a lockout time such as one to five seconds while processing the acceptance request. During the lockout time, the controller 102 processes the acceptance request steps from 502 to 518. Within that time frame the controller 102 performs the automatic offer retraction process as in 304 and the initial offer is briefly locked out to properly assess/update limits and update the initial offer terms in the offers database 210 after creating the contract in the contracts database 212. Having a lock out time duration for acceptance requests and offers may be beneficial in embodiments where the controller includes a plurality of processors 200 that operate somewhat independently from one other, for example.

FIG. 6 illustrates a flowchart describing operations by the controller 102 in order to check for conflicting offers during step 510 of FIG. 5 according to an exemplary embodiment. Like FIG. 5, the steps of FIG. 6 may be performed by the one or more processors 200 within the controller 102 by executing the software instructions 204 loaded from the storage device 114. The steps of the flowchart are not restricted to the exact order shown, and, in other configurations, shown steps may be omitted or other intermediate steps added.

The process begins at step 600 when the controller 102 retrieves the still pending offers for the users that are involved in the offer confirmed to be accepted at step 504. Each offer has an originating party and an accepting party and these two users are the users directly involved in the offer. At step 600, the controller 102 does a database query to select or otherwise pull all pending offers that have been extended by either of these two parties. The pending offers retrieved at this step include all offers whether public or private offers that have an originating party equal to either of the involved users. In some embodiments, rather than checking both user’s offers at the same time, the controller 102 checks the first user for all conflicting offers that they made, and automatically retracts all conflicting offers based on new aggregate limits. The controller 102 then performs the same process for the second user.

At step 602, the controller 102 determines whether any pending offers were retrieved at step 600. For instance, it could be that the users involved in the newly accepted offer have not extended any other offers to other parties. In this case, the pending offers retrieved at step 600 will be an empty set and control can proceed directly step 512. However, if any of the involved users has also extended other offers that are still pending and therefore available to be accepted, control proceeds to step 604.

At step 604, the controller 102 selects one of the pending offers determined at step 600 (or still remaining to be checked after step 610) for analysis.

At step 606, the controller 102 compares the various terms included in the offer to see if any of the offered terms exceeds a remaining aggregate limit for the user from which the selected offer originated. For instance, if a user’s remaining quantity aggregate limit is for twenty apples after an offer is newly accepted, any still pending offers made by this same user for more than twenty apples now conflict with the user’s remaining quantity aggregate limit. Again, any number of aggregate limits may be configured for each user and thus the controller 102 at step 606 may check a plurality of deal terms. If any offer term exceeds a remaining aggregate limit for the user that sent the offer, control proceeds to step 608; otherwise, control proceeds to step 610.

At step 608, the controller 102 flags the offer that has at least one deal term exceeding a remaining aggregate limit for the originating user as“conflicting”. This may be done by the controller 102 updating a status field in a record of the offer stored in the offers data 210 of the storage device. The offers that are marked as“conflicting” at step 608 are the offers that are then automatically retracted by the controller 102 at step 514. At step 610, the controller 102 checks whether there is another still pending offer in the set of pending offers retrieved at step 600. If yes, the controller 102 returns to step 604 to select one of the remaining pending offers for analysis and the process continues until all the remaining offers have been checked for conflicts. Once there are no more pending offers left to check, control proceeds from step 610 to step 512.

FIG. 7 illustrates a first timeline example of a remaining quantity limit resulting in automatic offer retraction for a plurality of users as seen from the point of view of a first user according to an exemplary embodiment. FIG. 7 is form the point of view of user A. Prior to making an offer, the originating user A sets an aggregate limit of one-hundred apples. In some cases, this aggregate quantity limit may refer to how many total apples the user A wishes to purchase. In other cases, the aggregate quantity limit may refer to how many total apples the user A wishes to sell. Both types of aggregate quantity limits work in a similar manner and FIG. 7 is applicable to both and therefore the distinction between selling / purchasing is not indicated in FIG. 7 to keep the example generic to both directions. The aggregate limit for user A is stored in the limits data 208 by the controller 102. The aggregate limit may be set by the user in the form of configuring or otherwise setting up a project such as to sell (or buy) 100 apples.

At time Tl, user A makes an initial public offer 700 to buy (or sell) one-hundred apples for $100. The initial offer 700 is sent from a user device 106 operated by user A to the controller 102 and stored in the offers data 210 of the storage device 110. Other users may thereby search for public offers and find the initial offer 700.

At time T2, user A makes a private offer 702 to user B to buy (or sell) one-hundred apples for $80. This private offer 702 may be sent to user B in response to user A receiving an unacceptable counteroffer from user B. Alternatively, user A may decide to send a private offer to user B because user B is a previous vendor with which user A has made deals in the past.

At time T3, user A makes a private offer 704 to user C to buy (or sell) forty apples for $45. Again, this private offer 704 may be sent by user A as a counteroffer during back and forth negotiations with user C, or may be simply sent by user A as an initial private offer to user C.

At time T4, user A makes a private offer 706 to user D to buy (or sell) thirty apples for $40, and at time T5, user A makes a private offer 708 to user E to buy (or sell) forty-five apples for $45. Again, these two offers 706, 708 may be sent as counteroffers during negotiations or as simple private offers that are not in response to previous negotiation.

As illustrated in FIG. 7, after the time point T5, user A has five still-pending offers 700, 702,

704, 706, 708 that could be accepted by other parties. The controller 102 has stored each of these offers as a record in the offer data 210 in the storage device 114 and sends offer messages to each of the user devices 106 operated by the recipient users B, C, D, and E. These five pending offers 700, 702, 704, 706, 708 represent potentially legally binding contracts if they are confirmed accepted by the controller 102.

At time point T6, the user device 106 operated by user D sends a message to the controller 102 requesting to accept offer 706. The controller 102 performs the steps of FIG. 5 and FIG. 6 to both confirm the acceptance and to automatically retract all conflicting offers for the users A and D involved in the accepted offer. Taking user A as an example, a remaining aggregate limit 703 of seventy apples is calculated by the controller 102 at step 508 by subtracting the thirty apples in the confirmed accepted offer 706 from the user’s initial aggregate limit 701 of one-hundred apples. The controller 102 stores the remaining aggregate limit 703 of seventy apples in the limits data 208 in storage device 114 for user A and then uses the process illustrated in FIG. 7 to see whether any of the still pending offers for user A conflict with the remaining aggregate limit

703 of seventy apples.

In this example, both of user A’s first and second offers 700 and 702 have deal terms of one hundred apples, which is a greater value than the user’s remaining aggregate limit of 703 of seventy apples. For this reason, at step 514 performed very shorty after time T6, the controller 102 automatically retracts both the first and second offers 700 and 702. In this way, as soon as the controller 102 confirms acceptance of offer 704 by user C, no other users are able to accept offers 700 or 702 because these offers 700, 702 are automatically retracted by the controller 102.

Continuing the example, after time T6, user A has two pending offers 704, 708 that are still available to be accepted by other users because they do not have a quantity deal term that conflicts with user A’s new remaining aggregate limit 703 of seventy apples. In other words, these offers 704, 708 are not in the set of conflicting offers determined by the controller 102 at step 510.

At time T7, user C is confirmed by the controller 102 to have accepted offer 704. Again, using the steps of FIG. 5 and FIG. 6, the controller 102 dynamically calculates a remaining aggregate limit 705 for user A to be thirty apples by subtracting the forty apples in newly accepted offer

704 from the previously remaining aggregate limit 703 of seventy apples. The controller 102 then determines at step 606 that user A’s still-pending offer 708 includes a deal term (i.e., quantity of forty-five apples) that exceeds the user A’s new remaining aggregate limit 705 of thirty apples. For this reason, the controller 102 automatically retracts user A’s offer 708 as a conflicting offer at step 514. Thus, after time point T7 in this example, user A has two legally binding contracts 710, 712 that total to seventy apples. User A has no more pending offers still available to be accepted. Additionally, user A has a remaining aggregate quantity threshold 705 of thirty apples still remaining to be bought (or sold). User A may continue to make offers up to that aggregate quantity threshold 705 and the process will continue with the controller 102 preventing any offers from being accepted that would exceed said remaining aggregate limit 705 of thirty apples.

In some embodiments, at this point in time where there are 30 apples remaining or at any other time, user A may also have the option to update the aggregate limit if they choose to do so. For example, the user may decide to increase from 30 apples to 200 apples if the scope of their project changes.

As mentioned, FIG. 7 illustrates the example from the point of view of User A. Beneficially, the electronic negotiation system 100 in this embodiment and in particular the operations of the controller 102 in FIG. 5 and FIG. 6 allow user A to make as many simultaneous offers as desired without worry that multiple of said offers would be accepted resulting in an overcommitment situation for user A. For instance, having five offers 700, 702, 704, 706, 708 all pending and available to be accepted by other users at the same time (i.e., between time T5 and T6 in FIG. 7) increases the probability that user A will be able to make one or more acceptable deal(s). As long as all the offers made by user A are acceptable to user A on an individual basis, user A need not worry about conflicting offers as the controller 102 will automatically retract conflicting offers whenever an offer acceptance is confirmed. Likewise, as long as user A simply sets their initial aggregate limit 701 and then makes individual offers that in isolation would be acceptable to user A, the system beneficially prevents user A from needing to manually mange their offers or keep track of how many purchases / sales have been confirmed so far to avoid overcommitment.

Furthermore, in preferred embodiments, the controller 102 provides the same benefits to each of the other users involved in accepting offers with user A. For instance, FIG. 8 shows the same example as FIG. 7 but from the point of view of user D and FIG. 9 shows the same example as FIG. 7 but from the point of view of user C.

As illustrated in FIG. 8, user D has an initial aggregate limit 800 to sell (or purchase) at most fifty apples. This is stored by the controller in the limits data 208. At time Tl, user D posts a public offer 802 for fifty apples. At times T2, T3, T5, user D further sends offers 804, 806, 810 to other users for various quantities of apples. Likewise, at time point T4, user D receives the offer 706 from user A that was previously shown form the point of view of user A in FIG. 7. This offer 706 is accepted by user D at time point T6. As illustrated in FIG. 8, immediately after the controller 102 has confirmed that user D properly accepted offer 706 at time point T6, the controller 102 performs the various steps of FIG. 5 and FIG. 6 for user D to calculate a remaining aggregate limit 812 of twenty apples (initial limit of fifty apples minus thirty apples confirmed in offer 706) and to automatically retract the two still-pending offers made by user D that conflict this new aggregate limit 812. In particular, in this example, each user D’s remaining offers 804, 806, 810 are automatically retracted by the controller 102 because all of them have a deal term (i.e., apple quantity) that exceeds user D’s newly calculated aggregate limit 812 of twenty apples. From user D’s point of view, after time T6, user D has one legally binding contract 814 for thirty apples and a remaining aggregate limit of twenty apples.

As illustrated in the combination of FIG. 7 and FIG. 8, the controller 102 retracts offers made by both of the users A and D that are involved in newly accepted offer 706. At step 508 in FIG. 5, the controller 102 calculates the remaining aggregate limit for both users A and D involved in the newly accepted offer 706. The controller 102 then in step 510 checks for any still pending offers of either of these users that include a deal term exceeding the offer originator’s remaining aggregate threshold.

As illustrated in FIG. 9, user C has an initially configured aggregate cost limit 900 of $100. This example is intended to show how different users may have different types of aggregate limits and there is no requirement that both involved users in a single offer or deal need to have the same types of aggregate limits. In this example, user C makes no public initial offer but does make and receive private offers. In particular, at times T2, T4 and T5, user C makes private offers to other users I, J, K. Likewise, at time T3, user C receives the private offer 704 from user A.

From user C’s point of view, at time T6, user J accepts offer 904. At this point, the controller 102 performs the above described steps of FIG. 5 and FIG. 6 for both user’s C and J in order to calculate remaining aggregate limits for these users and to automatically retracting pending offers originating from these users that conflict with the originating user’s remaining aggregate thresholds. For example, from user C’s point of view in FIG. 9, the controller 102 calculates remaining aggregate threshold 908 for user C of $60, which is the user C’s initial aggregate limit of $100 minus the deal term cost of $40 listed in newly accepted offer 904. The controller 102 then checks user C’s still pending offers to see which conflict with the remaining aggregate limit 908. In this example, offer 902 is a conflicting offer because it includes a deal term of $100 that exceeds the remaining limit of $60. Offer 902 is therefore automatically retracted by the controller 102. After T6, user C has one remaining pending offer that originated from user C, namely offer 906 to user K. In addition, user C also has the incoming offer 704 from user A that is still under consideration by user C. At time T7, user C decides to accept the offer 704 from user A and the controller 102 calculates a remaining aggregate limit 910 for user C of $15. The controller 102 then determines that offer 906 originating from user C conflicts with the new remaining aggregate limit 910 and therefore automatically retracts offer 906. After T7, user C has two legally binding contracts 710, 914 totaling $85 and has a remaining aggregate limit of $15.

Confirming acceptance by the controller 102 at step 504 in some embodiments includes the user requesting acceptance wining the race in order to be the first to request acceptance of the pending offer. This step 504 can also include the controller 102 confirming that the offer is still valid and has not been retracted in the time since the accepting user sent the request to accept it. Likewise, the controller 102 may also double check that acceptance of the offer would not conflict with either users’ remaining aggregate limits stored in the limits data 208, which might happen in the event that another offer was confirmed accepted by the controller 102 for either user in the intervening time period before the controller 102 began processing the request for acceptance of the current offer. In short, the controller 102 can check the remaining aggregate limits for each user involved in a particular offer when confirming acceptance to make sure that the offer has no deal term that conflicts with the remaining threshold for either user. This check is part of the acceptance confirmation at step 504 in some embodiments. Likewise, the user devices 106 may also include checks prior to allowing a user to make an offer or request acceptance of an offer to ensure that no aggregate threshold for the user is exceeded. For instance, user devices 106 may perform a blunt limit check. Say the limit that’s set is $100, and if the user tries to send an offer for $200, then the user device 106 will determine the proposed offer exceeds the limit and will generate an error message or prompt on the user device 106 that the user is attempting to send an offer over and above the currently set limit. As the user completes deals and established contracts and the scope of the project is reduced (i.e., the user’s remaining aggregate limit is lowered), the user device 106 may continue to be notified of the remaining aggregate limit in order to use the updated remaining aggregate limit when doing the blunt limit check at offer creation. In other words, the user devices 106 and / or controller 102 can also prevent a user from extending of accepting offers that would conflict with any of that user’s aggregate limit(s) 208.

In some embodiments, the steps of searching for conflicting offers and retracting them are performed by the controller 102 as soon as possible each time an offer is confirmed accepted and may involve interrupts and push messages sent by the controller 102 to immediately inform the affected user devices 106. As illustrated in FIGS. 7-9, some users may be affected by automatic offer retractions even though they are not directly involved in any offer acceptance. For instance, user F illustrated in FIG. 8 receives an automatic retraction message from the controller 102 for offer 806 in response to another separate offer 706 being confirmed accepted between user A and user D. In this way, because of users A and D accepting offer 706 and entering into the legally binding contract 712, user F is automatically prevented by the controller 102 from attempting to accept offer 806 with user D. No action was required by user D to manually retract offer 806 prior to user F accepting, and even if user F did manage to accept offer 806 prior to users A and D accepting offer 706, the controller 102 would no longer confirm acceptance of offer 706. So from each user’s point of view, the controller 102 and electronic negotiation system 100 in general protect them from becoming locked into multiple offers that would exceed their requirements or result in them overbuying or overselling past their desired aggregate limits 208.

In addition to users configuring and setting their own initial aggregate limits prior to starting negotiations, it is also possible for users to change their remaining aggregate limits during negotiations and it is likewise possible that a system administrator 112 may set or update an aggregate remaining limit for another user at any time. As an example of user’s changing limits on the fly, the controller 102 may allow a user to increase the limit in Fig 7 between accepting offer 706 and 704 by another 30 apples. Therefore after accepting the offer 706, there could be a limit of 30+30 apples, allowing user E to accept the offer, instead of retracting it. As an example of admins setting and or changing limits, a system administrator 112 may set predetermined credit limits to prevent users from accidentally becoming legally obligated in one or more contracts that exceed the user’s credit limit. Admin limits can be around credit or quantity, imposed on top of the aggregate limit set by the user, to limit risk exposure of overcommitment on contracts.

In some embodiments, the electronic negotiation system 100 acts as a standalone Webserver module that is connected to an electronic over-the-counter (OTC) market, or forms an electronic OTC market directly, where the electronic negotiation system 100 enables negotiations for deals and contracts within a private network of OTC users. In other embodiments such as FIG. 10, the electronic negotiation system 100 connects users of social media platforms, online groups, chats, and other network of users. In other embodiments, the electronic negotiation system 100 is connected to Real Estate markets, or to an online market for equipment, assets, resources, or commodities. For instance, the controller 102 may be added on as a Webserver module in an OTC system, or a Webserver module in a residential or commercial Real Estate website application, or a Webserver module that connects the users of a Facebook® group. In the absence of the electronic negotiation system 100, a recurring problem arises during negotiations. Whether you are a direct participant or relying on an intermediary such as broker or an agent, given that these intermediaries are acting in your best interest, negotiations will eventually become limited and restricted as parties expose themselves to the risk of over commitment, by simultaneously extending electronic counteroffers to multiple parties in order to secure more competitive deal terms. One could find themselves in a situation to have committed to multiple online contracts, and subject to contract penalties due to breach of contract as a result of overcommitment. If negotiations are contained to only a few selected participants in a user network that are easy to manage, the advantages of favourable contract opportunities are lost due to lack of lack of competitive offers that one would accept otherwise if the negotiations were extended to a broader audience of market participants.

Beneficially, by connecting the electronic negotiation systems 100 disclosed herein, the above problems may be overcome. Through a web or cloud application using JavaScript, Python, PHP and C language programmable server solutions served by the controller 102 of FIG. 1, automated and anonymous offer and negotiation can take place between merchant 108 and clients 110 using specified aggregate limits, to simultaneously extend bilateral negotiations potentially to every user in the user network, that is part of an online client list, a customer relationship database, or a group in a social media platform, without taking any risk of over-commitment beyond the aggregate limits set by the user. In some embodiments, the controller 102 completely in whole mitigates any risk of over-commitment and allows network participants to take advantage of infinite number opportunities by extending bilateral negotiations to everyone in the electronic network eco-system.

In some embodiments, programing languages such as JavaScript, Python, and C languages are used in combination with emerging technology such as Blockchain open ledger or artificial intelligence are employed as the controller 102. All active and retracted offers from the network user ecosystem are stored by the controller 102, where the controller collects and analyses all data on active and retracted offers for trends, variables, naturally occurring algorithms, predictive modelling, and produces meaningful data analytics insights. Further upgraded by means of machine learning, and or artificial intelligence, the controller 102 leams and improves the efficiency and design of the entire process, including risk management and automatic retraction functions of the electronic negotiation system 100.

In some embodiments, the controller 102 uses voice activated commands and speech recognition technology, to send offers and counteroffers using spoken voice commands that direct the controller 102 to act, perform tasks, and execute functions of the electronic negotiation system 100. In addition, voice commands can be used to query the controller 102 for specific information, filter results, recall historical transaction records, or perform a certain type of analytic using the collected data on past and current negotiations.

In some embodiments, the controller 102 hides the originator and recipient user information during negotiations between user devices 106 until an offer is confirmed to be accepted. Providing anonymous user negotiations is performed in some embodiments by a stand alone (module) of the electronic negotiation system 100, or in embodiments that is integrated directly into a web application which is using the benefits of the controller 102.

In other embodiments, the controller 102 limits the number of offers and counter offers that can be sent by each user within a plurality of bilateral negotiation sessions. For example, when entering into bilateral negotiations between a first user and a second user, the controller 102 can be programmed to limit sending and/or receiving counteroffers to three (3), where after sending three (3) counteroffers, the second user, who is the recipient of the 3^rd and final counteroffer from the first user, has to decide whether to accept the terms of the deal and enter into contract with the first user, or to decline the deal, at which point the controller 102 follows the same processes described in FIG.4, FIG. 5, and FIG. 6.

Some embodiments of the present invention are applied to a network ecosystem or social media based network with a plurality of participants, where each participant is equal to the other based on a fundamental criteria (such as income, credit, asset base, or net worth) that restricts network eco-system entry only to qualifying participants. In such network eco-systems, the participants will equally seek to maximize the value of their trade deal or contract value during the negotiations process.

A specific example can be utilized to illustrate a solution in an exemplary embodiment of an emerging and extremely volatile markets for digital currencies such as Bitcoin or Ethereum. Take for example User A wanting to sell 150 Bitcoins, at the desired price of $7,000 USD per one Bitcoin, and $1,050,000 USD total contract value. Using other prior art techniques, the User A may call a specialized OTC trade desk in New York. The Broker working for the OTC trade firm reaches out to their electronic network and advertises that the broker has an open contract to sell 150 Bitcoins. The broker receives five offers, Offer 1, 2, 3, 4, and 5, from their network eco system in the range of $5,000 USD to $7,000 USD per one coin, for various quantities. Assuming that the Broker is acting in the best interest of User A and honestly discloses all of the offers received, in agreement with User A, the Broker decides to pursue Offer 2 for higher price but lower quantity, leaving other offers on hold while negotiations are in progress around Offer 2. At this moment there are missed opportunities for the Broker working on behalf of User A, to send counteroffers simultaneously on Offers 1, 3, 4 and 5 because of the risk to over-commit on multiple contracts. Offer 2 does not work out and Broker once again reaches out to the network eco-system, repeating this process again and again until the initial request of User A to sell 150 Bitcoins is fulfdled. Lack of transparency in the existing market process is evident as well as the age old principal-agent problem.

In contrast, in some embodiments of the present invention, the controller 102 performs an automated and anonymous process, removing any information asymmetry and conflict of interest completely out of the broker-client interactions, providing active risk management functions by preventing overcommitment on contracts, while at the same time allowing to take full advantage of competitive opportunities. In some embodiments, the Broker connects and integrates the electronic negotiation system 100 module into their website or user network. User A then hires the Broker, who then lists the 150 Bitcoins (the aggregate limit) on behalf of User A, as the initial public offer transparently available to the broad network eco-system as described above. Seeking to maximize the value of the trade deal, relying on the controller 102 the Broker is able to simultaneously receive offers on the initial public offering to the network ecosystem, send unlimited number of counteroffers, and send private offers to the complete population of market participants. As multiple bilateral negotiations are developing around the contract to find a buyer for the 150 Bitcoins, the Broker (and therefore User A) carries 0, NIL risk of over-commitment on the aggregate limits set at 150 Bitcoins, while negotiating potentially with the entire population of buyers looking to purchase up to the aggregate limit set at 150 Bitcoins, in order to maximize the number of competitive offers for User A. Using these embodiments, the Broker is also maximizing transaction profits for both parties entering into contract, to the outmost satisfaction of the User A, who hired the Broker to sell the 150 Bitcoins. The negotiation process is not limited to negotiating the price attribute only. Any deal term or terms may be negotiated in a similar manner and the controller 102 may prevent overcommitment for any type of deal term attribute. For example, the quantity may be bilaterally negotiated with multiple negotiation sessions available between multiple users conducted simultaneously.

In some embodiments, the User A directly participates in the private over-the-counter contracts markets, which use the electronic negotiation system 100 module, by making the initial public offer to sell 150 Bitcoins themselves, without the assistance of a Broker or Agent, gaining the same benefits and advantages of the negotiated process and offer retraction of the controller 102. In such embodiments, User A lists the contract promise anonymously, controls their entire process themselves with full transparency, receives anonymous quantity and price offers from multiple parties wanting to enter into contract and sends multiple counteroffers to maximize the competitive offers on the 150 Bitcoins. Personal bias, lack of disclosure, information asymmetry, and conflicts of interest are all eliminated from the negotiation process in some embodiments.

Examples of technologies that may be used to implement the controller 102 and user device 106 software programing include JavaScript, PHP, Python and other server side and controller programming. Client side solutions may involve customized, graphical user interfaces that enable merchant 108 and client 110 to connect to the server side controller and ultimately to the network eco-system.

Another specific example can be utilized to illustrate a solution in an exemplary embodiment of a Real Estate markets, including market participants such as real estate buyers, investors, developers, realtors, leasing and property managing companies. Company B, a real estate investment-holding corporation has a project to invest $10,000,000 USD ($10MM) into real estate, identifying multiple properties around the globe that would fit their requirements. Company B integrates the electronic negotiation system 100 with their Real Estate website, gaining the benefits of the system 100 and the controller 102 to facilitate bilateral negotiations with multiple parties, where the controller 102 ensures that the aggregate value of purchased real estate properties does not exceed $10MM, thus removing all risk of over-commitment for Company B. Multiple bilateral negotiations of Company B can result as an example, with one property purchase valued at $10MM or four properties purchased valued at $2.5MM each, with the controller 102 retracting conflicting offers with multiple parties up to the aggregate limit of $10MM set by the Company B. After completing the bilateral negotiations with multiple parties and locking in purchase contracts through negotiations facilitated by the electronic negotiation system 100, Company B would send bank wires and make payments to real estate sellers.

In a similar example as above, Company B, a real estate investment-holding corporation is part of a social media user network, a Facebook® Group called“FB Global Realty Connections”. As in the example above, Company B requires purchasing $10MM in real estate with some specific property requirements. Company B requests the FIG 1. Admin 112 administrator to connect the electronic negotiation system 100 with the social media users of the “FB Global Realty Connections”. At which time the entire social media group gains the benefits of the system 100 and the controller 102 to facilitate bilateral negotiations within their network group. By connecting the system 100 and the controller 102 to the social media network user group, Company B is able to bilaterally negotiate with multiple social media users, and also ensuring that the aggregate value of purchased real estate properties does not exceed $10MM, thus removing all risk of over-commitment for Company B and all other social media user participants in negotiations with Company B. An example of such embodiment is described in FIG.10.

In some embodiments, offers sent, received and countered on Real Estate properties can be anonymous to the participants, or can be fully transparent to the entire population of the market eco-system by disclosing the parties involved in the entire negotiation for the Real Estate property in question. Whether parties are anonymous or not, the controller 102 maintains a complete audit trail of the negotiation process, to ensure authority and transparency of the created contract.

A contract promise, or the initial public offering, such as a public offer sell a Real Estate property, can be initially listed by specifying price as the aggregate limit, quantity, quality and other terms or specifying just qualitative terms and leaving the price as“Offer Only”. Once listed in the web catalogue as an initial offering, multiple clients are able to submit their price offers to the holder of the contract promise, or if agreeing to the initial price offered by the contract holder, to enter into contract immediately. All negotiations are done bilaterally between the owner of the contract, and each of the multiple parties submitting the offers to the owner of the contract. In some embodiments, the controller 102 automatically confirms acceptance and manages aggregate limits to avoid overcommitment.

The controller 102 keeps track of the holder of the contract as the merchant 108 and anyone else as the client 110. Usernames are generated by the controller 102 in some embodiments with random values to provide anonymity to the multiple parties in the negotiation process. At each step of the negotiations process, for example when a client 110 sends an offer to the holder of the contract promise, the merchant 108, there may be a transaction fee charged by the controller 102 to facilitate the transaction and provide strong intent of the offer to enter into contract. A transaction fee may also be paid when the offer is requested to be accepted by the holder of the contract promise (and/or when confirmed to be accepted by the controller 102).

When the two parties 108, 110 have completed the automated negotiations process, they have agreed to create a contract. At this time, the controller 102 sends out notifications to both users that a legally binding contract has been created. On demand, once a contract is created, the controller 102 is able to provide a history and a documented sequence of events to both users entered into contract, to evidence creation of the stated contract. In some embodiments the controller 102 requires users to confirm the negotiated contract with both parties by sending a contract document to sign off on with e-signatures and immediately proceeds to settlement. In some embodiments, in addition or an alternative to a transaction processing free, each step of the negotiation process may involve the controller 102 collecting directly embedded e-signatures or include additional verification methods to strengthen the validity of the offers sent and requested to be accepted.

FIG. 10 show a block diagram of an electronic negotiation system 1000 including a plurality of virtualized negotiation systems 1002 accessible to users of different social media platforms 1004 via an Internet-connected hub 1006 according to an exemplary embodiment. The system 1000 includes a plurality of user devices 1008 being computer devices such as laptops, desktops, phones, and tablets operated by users. The user devices 1008 are coupled by a network 1010 such as the Internet and connecting to a plurality of social media platforms 1004.

The term social media platform in this context means a computerized networking system that allows a plurality of users to interact with each other. The interaction may involve messages, photos, videos, etc. Examples of social media platforms include popular social platforms and ecommerce websites such as Facebook®, Linkedln®, Craigslist®, eBay®, etc. Likewise, messaging systems such as Skype® and other chatting systems may also be considered social media platforms 1004 in some embodiments.

The hub 1006 is connected to the Internet 1010 and the plurality of virtualized negotiation systems 1002. Each virtualized negotiation system 1002 includes a controller 1012 coupled to a storage device 1014. Among other software and data (not shown for simplicity), the storage device 1014 stores a user list 1016 representing user accounts that are authorized to login and utilize each respective virtualized negotiation system 1002.

Taking the first virtualized negotiation system l002a as an example, the controller l0l2a receives from one or more of the social media platforms 1004 user account details of users that are authorized to utilize the first virtualized negotiation system. For example, there may be a group of users on the first social media platform l004a that are car enthusiasts. Users that join the group on the social media platform 1004a may have details of their user accounts automatically transferred from the social media platform 1004a to the user list 1016a of the first virtualized negotiation system 1002. The transfer may occur via the Internet 1010 and the intermediate hub 1006, for example. The details that are transferred may include a user identifier such that the user list includes a plurality of user identifiers representing a plurality of users on the first social media platform 1004a that are authorized to conduct negotiations on the first virtualized negotiation system 1002a. Users from the group that wish to make use of the negotiation capabilities of the first virtualized negotiation system l002a may click a link such as an HTML web link from a web page of the group on the social media platform 1004a in order to redirect their web browsers over to a URL of the hub 1006. Alternatively, in some embodiments, the hub 1006 and first virtualized negotiation system l002a may operate utilizing a software app (e.g., a negotiation system app) that runs on the users’ phones and computers. In this case, the button available on a user interface of the first social media platform l004a may cause the negotiation system app to open on the user’s user device 1008.

Once at the hub 1006, either in a web browser or via a login page of a negotiation app, a user logs in to the hub 1006 utilizing their same credentials that they utilize on the first social media platform l004a. The hub 1006 verifies the credentials with the social media platform l004a utilizing standard single-sign-on application programming interfaces (APIs) provided by the social media platform 1004a. Assuming the credentials are verified, the hub 1006 determines a target virtualized negotiation system 1002 for the user either based on a manual selection by the user or by automatically matching an identifier of the user that has now logged in with the same user identifier being included on the user list 1016 of a particular one of the virtualized negotiation systems 1002. Again, taking the example where the target system 1002 is the first virtualized negotiation system 1002a, the user’s identifier will be included on the user list 1016a of this target virtualized system 1002a.

Once the target virtualized negotiation system 1002a is determined, the hub 1006 forwards the user to the target virtualized negotiation system 1002a such that the user can interact with the controller 1012a of said target system 1002a in a similar manner as described above for the controller 102 of FIG. 1. For example, the user may review incoming offers, place new public offers, accept and reject offers, make counter offers etc. In this embodiment, the other users that the user is negotiating with while utilizing the target virtualized negotiation system 1002a are the same users in the group on the first social media platform 1004a as per the user list 1016a of the target virtualized negotiation system 1002a. Again taking the example of a group of users that are car enthusiasts, the various users may negotiate deals on cars, parts and accessories. Beneficially, the social media platform l004a can leverage the functionality and overcommitment protections of the controller 1012a for the platform’s l004a user base without the social media platform l004a needing to implement / replicate all of said functionality.

In some embodiments, each virtualized negotiation system 1002 corresponds to a particular one of the social media platforms 1004; however, this is not a limitation and in other embodiments, the virtualized negotiation systems 1002 may be organized in any desired manner. Allowing users from multiple social media platforms 1002 to join a single virtualized negotiation system by including their user identifiers on a single user list 1016 would, for example, increase the membership on the user list 1016 of a single virtualized negotiation system 1002 to allow trading between users of multiple social media platforms 1004. In other words, users do not necessarily need to sign up for multiple social media platforms 1004 if they wish to trade with users of each of those platforms 1004.

In some embodiments, the organization of system 1000 of FIG. 10 allows users to use their preferred social media platforms 1004 like normal. They can also log in to the hub 1006 using their same social media credentials and then be redirected to one or more target virtualized negotiation system(s) 1002 where they can do trade with other members of a group of other users authorized for access to that target negotiation system 1002. The groups may correspond to things like Facebook® groups, etc.

Although FIG. 10 illustrates virtualized negotiation systems 1002, it is not a requirement that virtual servers be utilized for each virtualized negotiation system 1002. In other embodiments, the virtualized negotiation systems 1002 of FIG. 10 are replaced with a plurality of custom negotiations systems 1002 behaving in a similar manner. Each custom negotiation system 1002 has its own user list 1016 and operates as described above. In general, the custom negotiation systems 1002 may be virtualized and/or run on separate physical computer servers as desired according to application specific requirements and preferences.

An exemplary advantage of certain embodiments is that the electronic negotiation system 100, 1000 streamlines negotiation processes and provides a fair platform for the entire network eco system that’s connected to the system, enabling parties to negotiate and enter into a favourable contract to both sides.

In an exemplary embodiment of the invention, an electronic negotiation system includes a controller 102 that stores an initial aggregate limit associated with a first user. The first user sends a plurality of offers to the controller 102, each of the offers specifying different deal terms. The controller 102 sends the offers to other users and receives a request to accept one of the offers from a second user. The controller 102 confirms the acceptance is proper and stores a contract between the first user and the second user. Before processing a next request for offer acceptance, the controller 102 calculates a remaining aggregate limit associated with the first user by adjusting the initial aggregate limit according to a deal term of the accepted offer. The controller 102 then determines whether any still pending offer by the first user includes a corresponding deal term that exceeds the remaining aggregate limit. When yes, the controller 102 automatically retracts the conflicting offer thereby preventing overcommitment by the first user.

Although the invention has been described in connection with preferred embodiments, it should be understood that various modifications, additions and alterations may be made to the invention by one skilled in the art without departing from the spirit and scope of the invention. For example, although the above-description provides an example of application in an electronic over-the-counter (OTC) market for private contracts and an example of residential real estate, the electronic negotiation systems 100 and controller l02s and user devices 106 disclosed herein may be employed in any kind of user network including social media networks, OTC markets, real estate, buy-and-sell bulletin boards, mobile apps, transportation contracts, chat boards and hots, etc.

While the above examples have discussed calculating the remaining aggregate limits by subtracting a newly accepted deal term from the user’s current aggregate limit, subtracting is an example only. Addition is utilized in other embodiments such as running total that climbs up to the user’s aggregate threshold instead of counting down to zero from said threshold limit. As such, the usage of the term“exceeds” when checking if a deal term exceeds an aggregate limit means to check whether the deal term crosses the threshold in either the greater than or less than directions depending on the type of limit threshold and type of calculation addition / subtraction being utilized. Likewise, although the above description has mostly focused on having aggregate limits greater than a value of one (“>l”) such as in a project to buy Real Estate with an aggregate limit of $10MM as in the example above, which could involve purchasing one property at $10MM or four properties at $2.5MM each, it is also possible to have the aggregate limit set at one (“=l”), because there is only one unique property or asset.

The above-described flowcharts and method steps may be implemented by software executed by one or more processors operating pursuant to instructions stored on a tangible computer-readable medium such as a storage device to perform the above-described functions of any or all aspects of the access controller 102. Examples of the tangible computer-readable medium include optical media (e.g., CDROM, DVD discs), magnetic media (e.g., hard drives, diskettes), and other electronically readable media such as flash storage devices and memory devices (e.g., RAM, ROM). The computer-readable medium may be local to the computer executing the instructions or may be remote to this computer such as when coupled to the computer via a computer network such as the Internet. The processors may be included in a general-purpose or specific- purpose computer that becomes the controller 102 or any of the above described user devices 106 or other devices as a result of executing the instructions.

In other embodiments, rather than being software modules executed by one or more processors, the above-described functionality may be implemented as hardware modules configured to perform the above-described functions. Examples of hardware modules include combinations of logic gates, integrated circuits, field programmable gate arrays, and application specific integrated circuits, and other analog and digital circuit designs.

Functions of single modules may be separated into multiple units, or the functions of multiple modules may be combined into a single unit. Unless otherwise specified, features described may be implemented in hardware or software, being a stand-alone module connecting to an existing user network, a website database, or integrated directly in an application according to different design requirements. In addition to a dedicated physical computing device, the word“server” may also mean a service daemon on a single computer, virtual computer, or shared physical computer or computers, for example. All combinations and permutations of the above described features and embodiments may be utilized in conjunction with the invention.

Claims

WHAT IS CLAIMED IS:

1. An apparatus facilitating bilateral negotiations between a plurality of parties, the apparatus comprising:

a storage device;

a communication interface coupled to a computer network; and

a processor coupled to the storage device and the communication interface;

wherein, by the processor executing a plurality of software instructions loaded from the storage device, the processor is configured to:

store an initial aggregate limit associated with a first user in the storage device;

receive a plurality of offers from the first user and store information of the plurality of offers in the storage device, each of the plurality of offers specifying one or more deal terms, at least some of the deal terms being different for different ones of the plurality of offers, and the information stored in the storage device for each offer including state information representing whether the offer has been accepted and whether the offer has been retracted;

send the plurality of offers to a plurality of other users via the communication interface; receive a request to accept a selected one of the plurality of offers, the request to accept being received via the communication interface from a second user different than the first user;

in response to receiving the request, check the state information of the selected one of the plurality of offers in the storage device to confirm that the selected one of the plurality offers has not already been accepted and has not already been retracted; and in response to confirming that the selected one of the plurality of offers has not already been accepted and has not already been retracted, store a record of a contract between the first user and the second user in the storage device, the contract including the one or more deal terms of the selected one of the plurality of offers; update the state information in the storage device to record that the selected one of the plurality of offers has been accepted, send an acceptance confirmation message to each of the first user and the second user via the communication interface; calculate a remaining aggregate limit associated with the first user by adjusting the initial aggregate limit according to a particular deal term of the selected one of the plurality of offers; determine a set of conflicting offers being remaining offers of the plurality of offers that include a corresponding deal term exceeding the remaining aggregate limit; and automatically update the state information in the storage device to record that each of the set of conflicting offers has been retracted;

wherein, once the selected one of the plurality of offers is confirmed to be accepted by the processor, the processor prevents the other users from being able to accept any other of the plurality of the offers from the first user that, if accepted, would cause the first user to have a plurality of contracts that in aggregate would have deal terms that exceed the initial aggregate limit.

2. The apparatus of claim 1, wherein, the processor is further configured to send a notice of offer retraction to each of the other users who were previously sent one or more of the set of conflicting offers.

3. The apparatus of any one of claims 1 to 2, wherein:

the processor further receives a plurality of requests for acceptance of selected ones of the plurality of offers;

the plurality of requests are processed by the processor in an order that they are received; and processing of each request involves the processor both confirming acceptance of the request and marking any conflicting offers as having been retracted in the storage device before beginning to process a next one of the plurality of requests.

4. The apparatus of claim 3, wherein the processor is further configured to store the remaining aggregate limit as the initial aggregate limit for after processing each of the requests, the initial aggregate limit thereby being changed each time one of the plurality of the offers is confirmed to be accepted.

5. The apparatus of any one of claims 1 to 4, wherein:

the initial aggregate limit is a total quantity; and the remaining aggregate limit is calculated by subtracting a quantity term of the selected one of the plurality of offers from the total quantity.

6. The apparatus of any one of claims 1 to 4, wherein:

the initial limit is a total cost; and

the remaining aggregate limit is calculated by subtracting a cost term of the accepted one of the plurality of offers from the total cost.

7. The apparatus of any one of claims 1 to 6, wherein the initial aggregate limit includes a plurality of initial aggregate limits and the processor is configured to calculate a plurality of remaining aggregate limits according to deal terms in the selected one of the plurality of offers and to determine the set of conflicting offers being remaining offers of the plurality of offers that include at least one corresponding deal term exceeding any one of the remaining aggregate limits.

8. The apparatus of any one of claims 1 to 7, wherein the processor is further configured to confirm that each of the plurality of offers received from the first user does not conflict with the initial aggregate limit.

9. The apparatus of any one of claims 1 to 8, wherein the processor is further configured to: receive one or more second offers from the first user after the selected one of the offers has been accepted; and

confirm each of the one or more second offers does not conflict with the initial aggregate limit prior to sending the one or more second offers to other users via the communication interface.

10. The apparatus of any one of claims 1 to 9, being a Webserver module that integrates with one or more electronic over-the-counter (OTC) markets.

11. The apparatus of any one of claims 1 to 9, being a Webserver module that integrates with one or more social media networks.

12. The apparatus of any one of claims 1 to 9, being a Webserver module that integrates with one or more real estate markets.

13. A method of facilitating bilateral negotiations between a plurality of parties, the method comprising:

storing an initial aggregate limit associated with a first user in a storage device;

receiving a plurality of offers from the first user and store information of the plurality of offers in the storage device, each of the plurality of offers specifying one or more deal terms, at least some of the deal terms being different for different ones of the plurality of offers, and the information stored in the storage device for each offer including state information representing whether the offer has been accepted and whether the offer has been retracted;

sending the plurality of offers to a plurality of other users via a computer network;

receiving a request to accept a selected one of the plurality of offers, the request to accept being received via the computer network from a second user different than the first user;

in response to receiving the request, checking the state information of the selected one of the plurality of offers in the storage device to confirm that the selected one of the plurality offers has not already been accepted and has not already been retracted; and in response to confirming that the selected one of the plurality of offers has not already been accepted and has not already been retracted, storing a record of a contract between the first user and the second user in the storage device, the contract including the one or more deal terms of the selected one of the plurality of offers; updating the state information in the storage device to record that the selected one of the plurality of offers has been accepted, sending an acceptance confirmation message to each of the first user and the second user via the communication interface; calculating a remaining aggregate limit associated with the first user by adjusting the initial aggregate limit according to a particular deal term of the selected one of the plurality of offers; determining a set of conflicting offers being remaining offers of the plurality of offers that include a corresponding deal term exceeding the remaining aggregate limit; and automatically updating the state information in the storage device to record that each of the set of conflicting offers has been retracted;

wherein, once the selected one of the plurality of offers is confirmed to be accepted, the other users are prevented from being able to accept any other of the plurality of the offers from the first user that, if accepted, would cause the first user to have a plurality of contracts that in aggregate would have deal terms that exceed the initial aggregate limit.

14. The method of claim 13, further comprising sending a notice of offer retraction to each of the other users who were previously sent one or more of the set of conflicting offers.

15. The method of any one of claims 13 to 14, further comprising: receiving a plurality of requests for acceptance of selected ones of the plurality of offers; and processing the requests for acceptance in an order that they are received;

wherein processing of each request involves both confirming acceptance of the request and marking any conflicting offers as having been retracted in the storage device before beginning to process a next one of the plurality of requests.

16. The method of claim 15, further comprising storing the remaining aggregate limit as the initial aggregate limit for after processing each of the requests, the initial aggregate limit thereby being changed each time one of the plurality of the offers is confirmed to be accepted.

17. The method of any one of claims 13 to 16, wherein:

18. The method of any one of claims 13 to 16, wherein:

the initial limit is a total cost; and the remaining aggregate limit is calculated by subtracting a cost term of the accepted one of the plurality of offers from the total cost.

19. The method of any one of claims 13 to 18, wherein:

the initial aggregate limit includes a plurality of initial aggrege limits; and the method further comprises calculating a plurality of remaining aggregate limits according to deal terms in the selected one of the plurality of offers and determining the set of conflicting offers being remaining offers of the plurality of offers that include at least one corresponding deal term exceeding any one of the remaining aggregate limits.

20. The method of any one of claims 13 to 19, further comprising confirming that each of the plurality of offers received from the first user does not conflict with the initial aggregate limit.

21. The method of any one of claims 13 to 20, further comprising:

receiving one or more second offers from the first user after the selected one of the offers has been accepted; and confirming each of the one or more second offers does not conflict with the initial aggregate limit prior to sending the one or more second offers to other users via the computer network.

22. A Webserver module connected to one or more real estate markets that performs the method of any one of claims 13 to 21.

23. A Webserver module connected to one or more social media networks that performs the method of any one of claims 13 to 21.

24. A _Webserver module connected to one or more electronic over-the-counter (OTC) markets that performs the method of any one of claims 13 to 21.

25. A non-transitory processor-readable medium comprising a plurality of processor-executable instructions that when executed by one or more processors cause the one or more processors to perform the method of any one of claims 13 to 24.

26. A non-transitory processor-readable medium comprising a plurality of processor-executable instructions that when executed by one or more processors cause the one or more processors to perform steps of:

sending the plurality of offers to a plurality of other users via a computer network; receiving a request to accept a selected one of the plurality of offers, the request to accept being received via the computer network from a second user different than the first user; in response to receiving the request, checking the state information of the selected one of the plurality of offers in the storage device to confirm that the selected one of the plurality offers has not already been accepted and has not already been retracted; and in response to confirming that the selected one of the plurality of offers has not already been accepted and has not already been retracted, storing a record of a contract between the first user and the second user in the storage device, the contract including the one or more deal terms of the selected one of the plurality of offers; updating the state information in the storage device to record that the selected one of the plurality of offers has been accepted, sending an acceptance confirmation message to each of the first user and the second user via the communication interface; calculating a remaining aggregate limit associated with the first user by adjusting the initial aggregate limit according to a particular deal term of the selected one of the plurality of offers; determining a set of conflicting offers being remaining offers of the plurality of offers that include a corresponding deal term exceeding the remaining aggregate limit; and automatically updating the state information in the storage device to record that each of the set of conflicting offers has been retracted;