ANONYMOUS MATCH ENGINE and QUADMODAL NEGOTIATION SYSTEM
20200273124 ยท 2020-08-27
Inventors
Cpc classification
G06Q30/0605
PHYSICS
G06Q10/107
PHYSICS
G06Q10/04
PHYSICS
H04L51/222
ELECTRICITY
H04L51/046
ELECTRICITY
International classification
G06Q10/04
PHYSICS
G06Q10/06
PHYSICS
Abstract
RoboNegotiator (RN) describes an unbiased match engine which preserves the identity of all the parties involved until an anonymity match, mutual interests or deal terms match their individual needs. RN automatically negotiates sellers offers against buyer's offers for a live match within an overlap of the seller's spread and the buyer's spread subject to predetermined seller's parameters and an ability of the buyer to initiate a negotiation against a forecast. Negotiations are forecast an n number of times via a machine learning of a prior deal history behavior of the seller and the buyer within the system for commerce and a crawled/scrapped market data in a geographical proximity. There is no risk of identity exposure if there is no mutual interest or deal and hence the disclosed RN will also preserve confidentiality of interest, deal terms and dreams.
Claims
1. A system for commerce, comprising: a match engine negotiating module configured to negotiate a plurality of seller's offers against a plurality of buyer's offers for a match within an overlap of a seller's spread of acceptable counter offers from a buyer and a buyer's spread of acceptable counter offers from a seller subject to a negotiation forecast; and a four mode operation module configured to operate in a live mode enabled by the seller predetermining and entering into system memory a plurality of negotiation parameters and a buyer starting the negotiation via a plugin platform, in an automated mode without any input from the parties after anonymous accounts and profiles have been created, in a classic mode based on the seller and the buyer interacting over chat, email and other communications and in a hybrid mode based on a mix of the classic mode and the automated mode.
2. The system of claim 1, wherein the match engine negotiating module is adapted for a seller's offer of a lowest acceptable counter offer and the buyer's offer includes a highest acceptable counter offer.
3. The system of claim 1, wherein the match engine negotiating module is adapted for a seller's spread tighter than the buyer's spread for a seller's deference in the n negotiations based on predefined rules.
4. The system of claim 1, wherein the match engine negotiating module is adapted for a buyer's spread tighter than the seller's spread for a buyer's deference in the n negotiations based on predefined rules.
5. The system of claim 1, further comprising a match engine forecasting module configured to determine an n number of negotiations via a learning of the match engine negotiation module of a prior deal history behavior of the seller and a prior deal history behavior of the buyer within a system for commerce and of a crawled/scrapped market data in a geographical proximity to the seller and to the buyer.
6. The system of claim 5, wherein the match engine forecasting module is adapted for a learning of a number of negotiations n for a certain type of item for all negotiations within the system for commerce.
7. The system of claim 5, wherein the match engine forecasting module is adapted for a match engine learning of a number of negotiations n for an item type negotiated the most for all negotiations within the system for commerce.
8. The system of claim 5, wherein the match engine forecasting module is adapted for a learning of a number of negotiations n for a repeat buyer.
9. The system of claim 5, wherein the match engine forecasting module is adapted for a learning of a number of negotiations n for a buyer of a quantity of items.
10. The system of claim 5, wherein the match engine forecasting module is adapted for a learning of a number of negotiations n for an item sold the most across state borders within the system for commerce and within the crawled/scrapped market data.
11. The system of claim 1, wherein the match engine negotiating module is adapted for a live negotiation via a plurality of circuits designed to simulate conversation between human sellers and human buyers based on a plurality of negotiation parameters being available prior to a start of a negotiation.
12. The system of claim 1, wherein the match engine negotiating module is adapted for an overlap of the seller's spread and the buyer's spread occur in a middle of a difference between a latest seller counter off and a latest seller counter offer as a starting place for a subsequent n negotiation.
13. The system of claim 1, wherein the match engine negotiating module is adapted for a decrementing circuit for a buyer's highest counter offer and an incrementing circuit for a seller's lowest counter offer.
14. The system of claim 1, further comprising a plurality of plug-in modules adapted for a portability and an interoperability of a seller's system into the match engine negotiating module and the match engine forecasting module.
15. The system of claim 1, further comprising a Representational State Transfer module adapted for a call from an application programming interface (REST API) in the system for commerce to an external API including corporate API.
16. The system of claim 5, wherein the match engine forecasting module is adapted for a deference in negotiations to be given to one of the buyer and the seller based on the negotiations forecast and predefined rules.
17. A method for commerce, the method comprising: negotiating a plurality of seller's offers against a plurality of buyer's offers for a match within an overlap of a seller's spread of acceptable counter offers from a buyer and a buyer's spread of acceptable counter offers from a seller subject to a negotiation forecast; and entering a plurality of negotiations via a four mode operation module configured to operate in a live mode enabled by the seller predetermining and entering into system memory a plurality of negotiation parameters and a buyer starting the negotiation via a plugin platform, in an automated mode without any input from the parties after anonymous accounts and profiles have been created, in a classic mode based on the seller and the buyer interacting over chat, email and other communications and in a hybrid mode based on a mix of the classic mode and the automated mode.
18. The method of commerce of claim 17, further comprising predicting a party's demographics based on a prior deal history of the seller and the buyer and based on a market data and a party's demographics crawled/scrapped from the internet for similar negotiations.
19. The method of commerce of claim 17, further comprising live negotiating for multiple sellers and buyers processing simultaneously based on a seller's negotiation parameters being predetermined and a buyer's ability to initiate a live negotiation based thereon.
20. The method of commerce of claim 17, further comprising using various negotiation data points to predict/forecast if a given negotiation underway for a given product between a certain buyer and a certain seller will go through or not and calculate therefrom a chance of success.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0009]
[0010]
[0011]
[0012]
[0013]
[0014]
[0015]
[0016]
[0017]
[0018]
[0019]
[0020]
[0021]
[0022]
[0023]
[0024]
[0025]
[0026]
[0027] Throughout the description, similar reference numbers may be used to identify similar elements depicted in multiple embodiments. Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The scope of the invention is to be defined by the claims appended hereto and their equivalents.
[0028] The following detailed description of the invention and the examples are intended to describe aspects of the invention in sufficient detail to enable those skilled in the art to practice the invention. Other examples can be utilized and changes can be made without departing from the scope of the current invention. The following detailed description is, therefore, not to be taken in a limiting sense.
DETAILED DESCRIPTION
[0029] Reference will now be made to exemplary embodiments illustrated in the drawings and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Alterations and further modifications of the inventive features illustrated herein and additional applications of the principles of the inventions as illustrated herein, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the invention.
[0030] Throughout the present disclosure the term spread, refers to a bounded range of acceptable offers for services, products and other consideration. The spread, or range are used interchangeably and are bimodal, meaning a seller's range does not have to equal a buyer's range for a match. One range can be tighter than the other side for a match depending on predetermined conditions. Both parties give their spread/range and third party/independent service like RN uses them to decide if matching occurs or not to start negotiations. The term deference, refers throughout the present disclosure to a negotiating party's terms for negotiation remaining unchanged initially and through a negotiation.
[0031] The term match engine refers to circuits, modules, devices, systems and non-transitory processor-readable storage media having one or more instructions which when executed by at least one processing circuit causes the at least one processing circuit to match at least two terms, conditions or fields via a logical comparison thereof. The term blackbox is referred to as a proper noun for a name of a proprietary device and system designed and engineered for matching logic and users according to the disclosure. The term RoboNegotiator is a protected mark referred to as a proper noun herein and is a disclosed system surrounding and enabling the blackbox matching engine. Furthermore, the term associative, semi-associatve, and fully associative, refer to a logical grouping of relational data domains according to a set of terms and business rules and a monetary consideration a user pays in order to have his or her data considered for as many matches as is logically possible. Relational data is referred to herein as a product or service. Service request is a transaction which comes to the Match engine to be matched with other such requests. Service Requests contain various attributes, and parameters as defined in
[0032] The present disclosure details live negotiation on eCommerce stores through chatbots and sales automation through a seller's ability to define negotiation parameters/rules which become negotiation logic. The present disclosure also includes business intelligence and market data. The present disclosure also details negotiation specific AI/Machine learning models for historical deal intelligence, demographics of potential customers based on historical data, buyer negotiation behavior and seller negotiation behavior and marrying all information to derive negotiation forecasting/prediction. Portability for plug and play modules especially for eCommerce are also included.
[0033] The disclosure deals with a private marketplace and provides a SaaS based anonymous and secure, cloud based matching service. Various parties who do not want to reveal their identity until a match is happened with an opposite party based on certain attributes can use the present invention. The present disclosure, also known herein as a blackbox and the associated system including a RoboNegotiator and other applications is unique and doesn't deal with just one domain or product line. The disclosed blackbox service is cloud based and uses a general match engine which can act as independent match engine for multiple companies and consumers. The purpose of this blackbox is to match interests from two users out of thousands of users in the system anonymously, independently, secretly and concurrently.
[0034] According to the anonymous aspect of the disclosure, a single match request by itself will not make any difference to a user's identity and nobody will know what a user is seeking. A user can be assured that he can try to check or explore anything without fear of revealing his or her identity, until someone can and is ready to respond to requests similar to the one posted by the user.
[0035] According to an independency aspect of the disclosure in an embodiment, once transactions are posted, match of interest will be done by a software process known herein as a blackbox engine and the RoboNegotiator system and not by any company or consumer but as a broker who arranges transactions between two parties and draws a commission therefrom. According to a confidential aspect of the invention, a user can post all kinds of requests in the system and no one will know about the user's attempts to reach someone on the user's terms. This nature of the system allows a user to try wildest things in the system without fearing exposing their identity. Their identity will need to be exposed only if their wildest dream is coming true (there is match in the system) or if something illegal is being done.
[0036] According to a concurrent aspect of the invention in an embodiment as disclosed, two transactions are compared for a match ONCE and either they match or they don't match. Concurrent aspects come from processing multiple requests using many threads and in parallel as when they come to the system and are processed. There is no negotiation or retries. On the other hand, in negotiative embodiments disclosed, if two users are trying to close a deal or explore some possibilities with each other, they get one chance. Multiple match requests will be processed simultaneously in different threads, with each thread matching one request. A threshold of negotiation is adjustable so that a primary negotiator offering a product or a service may want to try negotiating only once or n number of times with the same user offering a price or consideration for the product or services. The threshold number n allows the primary negotiator the ability to be exposed to other better offers via secondary negotiators who are more flexible and more eager to close a deal. The primary negotiator is also enabled to having multiple negotiation threads running concurrently in parallel or running serially depending on his style of negotiation.
[0037] The objective of the present disclosure includes mutual terms matching, secrecy, no-spam buying/selling experience, remaining anonymous, keeping identities private/secret, preserving mutual terms via an independent match engine.
[0038] The disclosed blackbox Match engine runs a SaaS model (Software as a Service) in the cloud and offers its services to registered and sometimes to non-registered customers. Customers can be independent consumers (retail) or specific vendors offering unique services or products.
[0039] Unique Admin UI (user interface) or Provisioning API (published Application Programming Interface) help to configure business rules for some of the match making processes and other attributes (confidentiality, anonymity, security, priority, etc.). These business rules are specific to certain types of service requests (or transactions) and will work on unique pairs of service requests (like LOSTFOUND or SELLBUY or SEND INFORECEIVE INFO) or can work on the same kind of requests, LOVE requests for example. These business rules also include specifying what attributes/parameters can be in those service requests when they arrive and which of them are used for successful match decisions. Not all attributes/parameters are needed for a successful match. Similarly, resulting actions on successful matches can be also configured differently for different service request types/transactions. Each service request will have a default expiry period when it no longer needs to remain in the system and can be purged.
[0040] Once business rules and service request types are provisioned in the system, the Match engine accepts requests from these customers over Web APIs (SOAP or REST or HTTP/XML derivation). Requests are stored in relational databases but are also stored in big data or noSQL databases too in embodiments. Once validated for completeness, and structural integrity, the match engine will store them in a relational database implemented in Big Data Solution or different noSQL (SQL=Sequel) databases. A database is used for storing incoming service requests, also referred to as transactions, which need to be matched and acted upon in the event of a successful match process and also for secured digital documents which are part of the service requests in some embodiments. In other embodiments digital files aren't needed in a negotiation.
[0041]
[0042] Request Receiver 10: The blackbox match engine will be made available to a client application through the Request Receiver web service. This service can be accessed by a client application over SOAP (simple object access protocol) and over REST API (RESTful web Programming interface). SOAP API receives XML requests which get stored in a folder before it gets added in the database while REST API gets a Key=Value based parameters which get inserted in the database. Request Dump 15: The match request received by the web service will be serialized and stored as xml in a folder. The request is not processed directly, but rather the action is performed asynchronously by an external service. A separate watch module provides scalability for concurrent processing.
[0043] Match engine 20: A continuously running service responsible for processing all match requests in FIFO order. While processing, the match request service retrieves request details and compares for a potential match. The matching logic is maintained in a separate xml file or database that is generated while an administrator configures match request types. Match Store 25: The processed match request will be stored in a separate database. This database will contain the matched and unmatched although processed requests. Match logic and rules are stored in separate folders or in a separate table in a database depending on the embodiment implemented per the present disclosure. One seller can have more than 1 item or service to sell, also known as a unit and similarly a buyer may have more than 1 unit (quantity) to buy. The disclosed match engine matches quantity accordingly. Therefore, one seller can be matched with 1 or more buyers and vice versa. Similarly, negotiations are also entertained with multiple parties as long as enough quantity of product or service is available to be matched to negotiating buyers.
[0044] Notification Component 30: defined when the match engine finds a match corresponding to a match request. The engine moves the match to a separate table. The match engine invokes a notification component 30 configured for passing the match details. The notification component 30 informs the involved users corresponding to the two match requests. The notification method includes email and is extensible to support other notification means such as text and digital media.
[0045]
[0046] As soon as the Request Watcher 35 recognizes a new match request in the request dump folder 15 it notifies the core Match Maker component 40 to process the request. The Match Maker 40 then tries to find a match for the newly arrived request attempting to find its match in an earlier received request. Match rules are already provisioned earlier as part of defining service requests earlier by an administrator and hence those rules are available in xml or database.
[0047] If the Match Maker 40 successfully finds a match for the request, it archives the two match requests updating their status as matched in the database 25. Further it notifies the Responder 45 component to update external parties about the found match.
[0048] If the Match Maker 40 fails to find a match for the newly arrived match request, it stores the unmatched request for future matching against any new match request, assuming a match will be found over a period of time. The system is configurable to allow a wait of a pending request for a finite or infinite period of time. The Responder component 45 is responsible for informing the involved parties through the Notification component 30 about the found match via email. Other notification medium includes a Dialer or Web Control.
[0049] Match request structure is described as follows. Each match request will have a mandatory Request Type attribute. The Request Type attribute is required for categorization of the match request and identify the corresponding matching logic (Match Rule) that should be adopted for finding a match for the given match request. The Request Type attribute will also signify the rest of the attribute that is to available with the match request.
[0050] The administrator will have the authority to define new Request Types and their corresponding attributes. The administrator will further be required to define a Match Rule for the given Request Type. Match Rule Structure is described as follows. For each pair of Match Request Type the administrator will define a Match Rule. Effectively each Request Type will have a corresponding Match Rule and an associated Request Type.
[0051] There are different system users and their roles are defined. Administrator User is the (default) user highest privilege blackbox user. Its roles includes: Create and configure Match Request; Define Match Rules; Manage other users; Unique Identifier: Username & password. Note: The system currently will support a single administrator user, but shall be extensible to support multiple administrators with different roles.
[0052] Now the functions of the client application are described as follows. Each client application having access to the Request Receiver Web Service will be uniquely identified by the system. This will allow the possibility of authenticating the client application and preventing spam attack. Furthermore, limiting a client access to a product or a service is included by coding restrictions to a limitation Type or an identifying Number of requests acceptable from the client, or a priority of request.
[0053] The End Users or individuals accessing the matching service through a client application can also be maintained by the system. Unique Identifier: Username & password. Basic Concept of Core engine is described as follows: Core part is Universal, General Purpose. The disclosed Smart Match engine takes transactions asynchronously over the web via distributed computers and matches them 1:1 or 1 to many. Every transaction has a specific life and if there are matching transactions within its life, two entities go ahead and do the specific business outside the disclosed engine. The system charges them per transaction matched and per a life of their transaction in the system. Match Parameters, Resulting Action all are part of transaction service requests. Match rules are already provisioned via an administrator.
[0054]
[0055]
[0056]
[0057]
[0058]
[0059] For instance, a semi-associative match is one where a user is looking to buy a sports car and is single and a matching user is also single and also looking for someone who can afford a sports car. The relational data sports car and single are associated in a match and other relational data are not associated. A two way set associative data match is one where sports car and single are a first associated set of data but also Houston location and running partner are a second associated set of data. A fully associative match is one where all the data of a user is available to match all the data or partial data domains of another user depending on if both parties are fully associative or if one is simply semi-associative or fully associative. Associativity of relational data domains is an aspect of the present disclosure that is used to distinguish higher paying users. Associativity refers to matching data across multiple domains where domains include personal and commercial aspects of a product or a service.
[0060]
[0061] $fieldstxn1=[
[0062] transaction_type=<SellAnonymously, //Unique Type
[0063] definition_id=>5, //API definition id
[0064] api_password=>b6a9bd1071d37d92d43c22131e0b16c8781d8b82, //API Key
[0065] quantity=>1, //quantity seller wants to sell for deal
[0066] notification_email_id=>seller@robonegotiator.com, //seller's email address
[0067] notification_contact_number=>+1-937-969-7626, //Seller Phone Number [0068] service_request_field[product_id]=>Tesla S Model, //S Service [0069] service_request_field[product_category]=>Automobiles, //Electronics, Jewelry [0070] service_request_field[sell_to_specific_or_any_buyer]=>any, //product details [0071] service_request_field[isbuyermarried]=>Yes, [0072] service_request_field[buyerownssportscar]=>Yes, [0073] service_request_field[minimum_sale_price]=>85000//Seller's Deal
[0074] Notice above that the transactional type is sellanonymously, and the relational data types above including isbuyermarried, and buyerownssportscar, are both considered so that a match is fully associative across data types. The disclosed data rules and services can be used in a relational database or used in a non-relational database according to the user's matching needs and negotiation requirements.
[0075]
TABLE-US-00001 $fieldstxn2= [ transaction_type =>BuyAnonymously, //Unique Type definition_id => 5, //API definition id api_password => b6a9bd1071d37d92d43c22131e0b16c8781d8b82, //API Key quantity => 1, //quantity seller wants to sell for deal notification_email_id => dshah@chalkstick.com, //Buyer's email address - Identity 1 notification_contact_number => +1-310-889-4304, //Buyer Phone Number - Identity 2 service_request_field[product_id] =>Tesla S Model, // Product ID which is being bought service_request_field[product_category] =>Automobiles, //Electronics, Jewelry service_request_field[buy_from_specific_or_any_seller] =>any, //Buy from anyone service_request_fieldmarital_status] =>Yes, //Yes, I am married service_request_field[own_sports_car] =>Yes, //Yes, I own Sports Car service_request_field[maximum_buy_price] => 90000 // Buyer's Price - will match as it's higher than seller's needs. ];
[0076] A Send First REST API for SellAnonymously transaction is followed by a ProcessRestOperation($fieldstxn1). A Send Second REST API for BuyAnonymously included in the pair so they match or at least initiate a negotiation, ProcessRestOperation($fieldstxn2).
[0077] Service request types include types include lost n found, sell n buy, lock n key, data push n data pull, date seek n date find, interview n feedback, social event n find applications. Depictions include a Bluetooth handset sell n buy, a travel sell n buy, a data push n data pull, and a housing rental sell n buy requests.
[0078] Now, consider following scenarios which are slightly distinguishable over used traditional Internet matching services.
[0079] (a) John is interested in dating Nancy, but only if Nancy has similar interest in John. However, both do not want to take initiative to inform each other about their intentions independently. They want someone else to mediate for them.
[0080] (b) Delta Airlines is ready to discount heavily on its route from LAX to JFK for a given date/flight as long as it doesn't get published to all and it doesn't set up precedence. John is ready to buy an air ticket for the same flight if his terms for the fare are met independently, but not after Delta knows price named by John.
[0081] (c) A house with a given MLS # is for sale and everyone knows about the market value for the house based on publically available research. The Seller and a Buyer want to close on a deal without going into lengthy negotiation which might waste some time.
[0082] (d) John has written a living will and wants to secure it in a place where it is accessible only to his daughter Nancy and only at a time John wants Nancy to access it. John may update the will meanwhile and he wants Nancy to be able to see the latest and greatest when the time comes.
[0083] (e) John is living on a budget and wants to organize his monthly expenses by putting a limit on each type of expenses he is ready to commit. Vendors can get John's business only if they are also offering the items for which John put in his budget if the items fit within that budget.
[0084] (f) A plumbing company has decided to discount heavily on their service rate for specific hours. However, they don't want to publish the cheapest rate as it will set-up a precedence they don't want to perpetuate. John needs a plumber and is looking for an inexpensive rate and he is OK to get a plumber whenever a plumber is free at his cheapest rate. This is similar in some sense as in the airfare example (b) above.
Example 1
[0085] Lost n Found Service. A company tracking lost items or tracking a person who lost an item, sends a LOST request to the disclosed match engine. The requests describes what the item is, where it was lost, when it was lost and potentially unique characteristics about the item including but not limited to an URL showing the image. At a later stage, another company/person who finds the item puts a FOUND request in the match engine describing some of the parameters or characteristics which match from the original request such as an URL for example, the city where it was lost/found, etc.). The disclosed match engine matches the LOST request with the FOUND request and reveals the identity of each other including but not limited to their identity, email address, phone number, etc.).
[0086] For instance, let's say John lost a Timex watch in Thousand Oaks city and Nancy found that watch in a park in Thousand Oaks city. To help these two individuals to reach to each other, the disclosed blackbox match engine can help in the following way.
[0087] Nancy puts a transaction FOUND identifying herself (User1=Nancy, User2=*) as a recipient of the ITEM_TYPE=WATCH with additional attributes LOCATION_CITY=Thousand Oaks and ITEM=Timex. If John also puts a transaction LOST identifying himself (User1=John, User2=*) with ITEM_TYPE=WATCH and LOCATION CITY=Thousand Oaks, the disclosed system will compare the transaction types (LOSTFOUND), followed by two names (incl. wildcards) followed by LOCATION_CITY followed by ITEM TYPE and sees that there is a match.
Example 2
[0088] Digital Safe Deposit Vault. A parent is leaving some confidential and secret digital documents including but not limited to a Will, financial accounts, login/passwords for various websites, etc. to their son/daughter. The parent would put a transaction LOCK to a system along with attachments, secret documents along with a potential key and the identity of a son/daughter who would retrieve it in the future. At a later stage, the son/daughter enters a KEY transaction with identity, and further key information to unlock the confidential and secret information. The disclosed system matches the LOCK and KEY transactions and reveals the secret documents to the respective son/daughter.
[0089] In a similar example or use case, John wants to send a file MyData.doc to Nancy only. John and Nancy both have user id or email addresses in the system so it can uniquely authorize, identify and associate them. However, John doesn't want to send his file directly to Nancy. John wants this data to be available to Nancy only if Nancy has shown interest to get a file from John even though she may not know his name.
[0090] In order to get his file into Nancy's hand, the following things are performed by the disclosed blackbox service.
[0091] (a) John puts a message, also referred to as a transaction, of type DATA_PUSH for Nancy in the system for example. The actual data is MyData.doc. John also can optionally define a Lock and a Key to enable Nancy access to his information but here he chooses not to put that limitation.
[0092] (b) Nancy puts a message of type DATA_PULL from John in the system for example. If John put a lock and key on his information, Nancy must have the access key in to the system.
[0093] The disclosed blackbox matching engine will parse both of these messages in the background and at some regular interval to see that two users match in the source and destination of their messages. When Transaction Types are opposite to each other or are part of pair of responses, it is a MATCH event.
[0094] On a match event, the blackbox will see if Users asked for confirmation before exposing the data and identity of each other or not. If identity confirmation is requested, the System will send a confirmation message to John and Nancy individually mentioning that a MATCH has occurred. The system queries the two parties to see if it should go ahead with exposing the identity of each other and their data in their respective MyData.doc file. If one of them or both of them accept the confirmation, the system will expose the data depending on the restriction imposed.
[0095] Exposing the secret data or a user's identity on a match event can happen either through email, text, and other media or through web access by two users, persons or parties.
Example 3
[0096] Real Estate Transaction. There is a unique URL describing a house in a given city and the seller/owner of the house puts a SELL transaction describing the unique URL, minimum sell value he or she would agree to, conditions, etc. in this transaction. A Buyer asynchronously puts a BUY transaction for the same URL (unique) along with his identity (email or phone #) with the maximum price he is committed to pay for the house. The disclosed blackbox matching engine compares and matches SELLBUY transactions for same URL (unique) and reveals the identity of buyer and seller to each other unless either party wanted a confidential sale. There is a provision for a seller who wants to meet a potential buyer to maintain a certain character of a neighborhood.
Example 4
[0097] Car Purchase. A unique URL, for example http://www.blackbox.com/negotiate/item101.htm contains all the information regarding John's 2001 Honda Accord car he is trying to sell. Nancy is interested in buying his car after reviewing the URL and both want to negotiate through blackbox. John will put a SELL transaction in the system for ITEM=http://www.blackbox.com/negotiate/item101.htm and other users will be * so anyone can bid. John will put price=>16000 in the message.
[0098] Nancy puts a BUY transaction for the same or similar item and URL above from Nancy and other user=*(any seller) and puts price=<16500. The system will match these two requests, BUYSELL, same or similar ITEM and same set of users with their price also matching and will reveal the identity and price to both the users.
[0099] Regarding New Car Transactions/DealershipsMost new car buyers are now trying to get away from a car dealership. A new car dealership negotiation is fraught with games and emotions not everyone is willing to play. With a unique VIN # mechanism in place to identify a vehicle, dealership can offer a final negotiation via the blackbox for the customer who is about to leave the dealership.
Example 5
[0100] Dating a Colleague, Classmates or a Friend. Two colleagues/co-workers, classmates or friends like each other but cannot openly propose a romantic or physical relationship to the other. Both of them put a LOVE transaction for each other into the disclosed system. It one person doesn't perfect a LOVE transaction in the match engine, a match is not possible on all terms when the matching rule=identity of each other (email or phone #). On a successful match event, the system reveals party identities and introduces each other as a third party mediator.
[0101] For example, let's say John and Nancy know each other and are silently interested in each other for date purposes or for a physical relationship possibly leading to love. Assuming they are shy and not able to expose their intention to each other directly, both of them will put a message into the blackbox matching engine knowing that they will not be exposed until a mutual interest matches from both of them. John puts a transaction DATE SEEK from John for Nancy. Nancy puts a similar DATE SEEK transaction from Nancy for John and the disclosed System independently matches these intentions and reveals the identity/interest to each other on a match event.
[0102] In the examples above, it is important to observe that the MATCH criteria changes depending on transaction types, DATA_PUSHDATA_PULL. The match engine compares the transaction types and compares users and a match occurs. In a second use case, a transaction type, users with wild card consideration, LOCATION, ITEM TYPE are used for a MATCH event. In some embodiments, the disclosure can also go one more levels to compare ITEM=Timex in to mix for full associativity.
Example 6
[0103] Goods/Products/Items, 10 items special dealSeller has 25 items including JABRA headsets for example and puts a special deal for 10 customers into the disclosed match engine. A SELL transaction with a unique URL showing Jabra handsets with a request to match 10 customers with a deal price. Customers interested in same and similar items come to visit seller's page and puts BUY transactions for the items with their offering value. If customers put more value than the deal requests and if the deal is still available, they get matches otherwise their transaction doesn't match and gets voided. On a match event, the system matches SELLBUY transactions one offered item to 10 purchases (1:10) and reveals the identities of all the parties to each other.
Example 7
[0104] Airline/Hotel Deals. Southwest Airlines puts special deals for specific flights including routes, dates, origin and destinations with a minimum fare for first 20 people. Consumers interested in checking their luck puts their bids into the matching engine and on successful match, these consumers get special discounted price/code which they can apply on Southwest website. This same mechanism can be applied to a hotel deal for a certain location, specific nights or other vacation/travel package deals.
Example 8
[0105] FacebookKnow your real friends. Know your best 10 friends through the disclosed matching engine immediately. One might have 500+ friends on Facebook but how many consider you their best friend? The disclosure makes it a matter of matching friends who care for you through the blackbox matching engine.
Example 9
[0106] Hiring Decision through 5 interviews for a best candidate. A typical corporate world hiring decision includes a group wrap-up at the end of a day of interviews to discuss the outcome. There are at least two problems with this(1) waste of 30 minutes at least per interviewer and (2) initial feedback from some interviewers dictate the outcome as later interviewers tend to change their tone/answers/feedback in a group set-up. One solutionat the end of an interview, all interviewers send their feedback against 5 pre-defined parameters to blackbox. blackbox matches and consolidates feedback and sends a report to Human Resources. Based on success criteria defined for this match, Human Resources acts on it or ignores the candidate completely.
Example 10
[0107] Company Execs & Employee Feedback. Successful companies are transparent and seek input from their employees in order to act on important issues brought to their attention. Most employees do not give honest feedback in a group or an open forum set-up and hence management has a hard time knowing reality. blackbox can help here where executives are seeking feedback and where employees have provided feedback. Chief Executive Officers can also seek input on specific Vice President, Chief Technology Officer, Chief Financial Officers and high level positions by putting a match transaction into blackbox.
[0108] Other examples includes Secured Uni-Directional Data Transfer, Salary Negotiation, Mobile Appsusing MSIMDN # automatically to send each other message, anonymous interests, Venture Capital ActivitiesNegotiation on Equities, Company/Date Finder, Vanpool/Carpool Partner finder. Social convenience matches are also compared, such as, does anyone want to go to Veggie Gill, Thousand Oaks with * on 14th February? If there is someone who is interested in the same, a match event happens. Similarly, vanpool/carpool finder service can be also offered using the disclosed match engine, No Spam=private experience of information exchange.
[0109] No one needs to know who got what deal and who offered it. Scheduled/Delayed/Password based File Transfers are also performed such as, Wanted to send this file to my IP Consultant only when he sends me NDA. Post a file for a given password for IPJuvarez in blackbox so he can retrieve it based on a password first user tells him verbally once NDA is received. The first users doesn't need to be on my computer when this happens.
[0110]
[0111]
[0112] The match engine code, heuristics and algorithms enable matching items and products between buyers and sellers trying buy/sell same or similar things and not something else. An ideal hosting space is provided with item description/image/info (like Groupon deals) via proprietary matching engine code. Requests from sellers and buyers are put into the system initiated from specific web sites so there is no confusion on an item. Every request put into the system by a Seller is implemented in code that conveys that there is a deal in blackbox for them to try. However, there is no guarantee of a match up though.
[0113] Personal Matches involving love affairs and dating requires identifying a unique person and hence Facebook page integration could be a best approach for matching. Social media cooperation across media and across platforms is provided in the system and code.
[0114] Airline Deals showing deals on their web page, www.southwest.com for example, are enabled by the disclosure for buyers visiting their sites to initiate requests for a match against Southwest's requests/deals.
System Requirements
[0115] System Requirements are discussed in detail below. There are different major Components: blackbox engine with DB/File Access published with API (application programming interface) to take messages. This is a large amount of focus and time in designing and implementing and is the heart of the system. Scalability to thousands of transactions in a system, Concurrency (Multiple transactions are being matched at the same time), Performance, Security (information from one transaction do not go to others, no one can retrieve a transaction or data from the system, etc) are some of the key requirements.
[0116] Sample Applications per above are integrated with the disclosed blackbox engine. Applications demonstrate that blackbox has an open API (Web 2.0) and can take and publish information. Applications are designed from use cases described above. More and more use cases are implemented using blackbox engine.
[0117] Admin UI (user interface): This will be used only internally by a blackbox Administrator. Visibility is provided into which messages are stored in the blackbox at a given time along with their types and status. This is useful for demo and debugging purposes.
Data and Control Flow
[0118] Control Flow of the system is as follows.
[0119] (a) When the system comes up initially, it is in a blank state. The system doesn't yet recognize any transaction pairs.
[0120] (b) The web API first configures the pair types along with matching criteria which are going to be used by a given application (external web app). Alternatively, an Admin User configures the types of Transaction Pairs which must be matched along with Matching Criteria for that pair (Lost Vs. Found, Sell Vs. Buy, etc).
[0121] (c) Various transactions/messages come from published APIs with all key details including user info, access info, data and other relevant attributes/pairs which are posted by various users from various web sites. If system is not configured for the given transaction type yet, an appropriate error message is returned.
[0122] (d) Transactions are validated against published schema (DTD document type definition) and users as part of a message authenticated against some DB (database). Once everything is checked and cleared against rules, a transaction is stored in the system with a time stamp. If there is external data associated with a message such as a file attachment, the file will be saved as well.
[0123] (e) Match engine process(es) in the background match various transactions in the system including source Vs. destination users, transaction type pairs and one or more attributes which must be matched before two transactions generate a match event.
[0124] (f) If no matching transaction occurs in the system, compare the next transaction for a match. Status indicators will remain in WAITING.
[0125] (g) If there is a potential match but transactions didn't match completely up to and including acceptance of a failed condition, status indicators for these transactions change to PARTIAL MATCH.
[0126] (h) Once transactions are matched completely between two users along with acceptance conditions, a transaction will be checked and compared for notification to both the users before exposing the content of the messages. If so, users are notified about the match by email, text and other media. Users are allowed to retrieve data from the system when both users agree to reveal the terms and content of the transactions. Alternatively, depending on a delivery preference defined by a source user, the destination user can be automatically notified about the data present in the system. Until both users access the hidden data, a transaction will remain in the MATCH status.
[0127] (i) Once data for matched transactions are revealed/published to both users, the transaction status of the match changes to ARCHIVE.
[0128] (j) Each transaction will have an expiry attribute, at which time a transaction is no longer valid and can be purged from the system. If an expiry is not explicitly defined, the disclosure assumes one year from the entry date as a default expiry date.
[0129] (k) Additional threads keep scanning the fully associative database for expired transactions and purges them from the system.
[0130] Other general requirements of the system are:
[0131] (a) Matching engine is a back end part so it is developed as an independent algorithm/process which takes any number of transactions from Data Base storage and processes them. In a typical world, more of these application servers/processes are scanning thousands of transactions posted to the site by thousands of users processing in real time or delayed fashion.
[0132] (b) Messages are always coming from trusted sources such as external partner websites. Users ID listed in the transactions are blackbox subscribers or partner subscribers and hence are authenticated as UserIDs against a database.
[0133] (c) In real time, there are many MATCH ENGINE PROCESSES which access the match database simultaneously including one process for each transaction pair type so scalability, sharing records and locking are also required.
[0134] (d) File Upload of data which are part of a matching transaction remain in a flat file systemon the disk, but no one is able to access those files directly. Only a matched user gets access to matching files through the blackbox GUI/Service.
[0135] (e) Ability to encrypt and decrypt data on retrieval is included in embodiments. Secure applications looking to use blackbox in a safe deposit vault mode use this feature.
[0136] (f) blackbox is an algorithm/engine or a backend module which has access to SQL DB (structured query language data base) and file systems to store documents and data coming from within the blackbox.
[0137] (g) blackbox receives transaction requests, also referred to as Messages from outside the system and stores them and processes them in a compare for a match. Messages have various parameters/attributes as follows.
[0138] Transaction Type==Examples=Lost, Found, Push, Pull, Sell, Buy
[0139] Source User=User who posted the transaction (assume some kind of
[0140] ID which will be authenticated from some database). Each User ID will have a corresponding email address which can derived from the same database.
[0141] Target User=User who this message is targeted for (*=match with anyone). The asterisk is a character that will match any character or sequence of characters and can have any value and any property.
[0142] Additional parameters have attributes with some values. Embodiments may also have data (files) depending on transaction types. These parameters/values will be used for a matching algorithm.
[0143] Few additional possibilities are there for each transaction/message:
[0144] (a) User may put a Lock and Key so information in the system gets to another user only if same lock and key (username/password kind) were provided by other user. This feature can be useful when the system acts as a safe box (online vault).
[0145] (b) There could be an expiry attribute to the system and hence a message may not reach another user if another transaction for matching comes after the message has expired. This will prevent the system from overflowing from all sorts of transactions which will never match and are best aborted. Also, this will allow faster processing times and bound deals and interests from two fresh users.
[0146] (c) There could be a possibility that User1 and/or User2 do not want to expose themselves even on a MATCH event which occurs between their messages. They may prefer that system confirms the match first and asks them before letting System reveal each other's identity. Email approval will trigger data delivery from the system in such cases.
[0147] (d) User1 may want to send data to one or more users and hence he or she may use a * wild card so anyone with matching transactions for User1 can retrieve respective data.
[0148] (e) Similarly, a transaction can come anonymously from user1 and hence user1 can choose * for the source user (person who posted the data) and hence another user doesn't need to know where the data is coming from. User2 will seek data from * so he doesn't know who posted the data. Some use cases and features listed above may not make sense in practical ways but they are being provided to enable some of the applications in the future.
[0149] Match engine status includes available, a full match, a partial match, in negotiation, Queued and archived or perfected. A hidden status provides protection for a deal in negotiation but as mentioned above, without a hidden status a deal in negotiation is open to a better offer at any time. All parties have the ability to call off a negotiation in progress or to stall a negotiation.
[0150]
TABLE-US-00002 public function updateActiveNegotiationPage($activeNegotiationId, $serviceRequestId,$option,$key){ $data=ActiveNegotiation::find($activeNegotiationId); $serviceRequest=ServiceRequest::find($serviceRequestId); if($data==null){ return view(templates.negotiation.update_failed); return json_encode(array([success => false, error => true, message => Invalid Request.])); } if($data->primary_request_id==$serviceRequestId){ if($data->primary_key !=$key){ return view(templates.negotiation.update_failed); return json_encode(array([success => false, error => true, message => Invalid Request.])); } $data->my_offer=$data->primary_negotiation_value; $data->other_offer=$data->secondary_negotiation_value; $data->request_id=$serviceRequestId; $data->option=$option;//1 for update,2 for meetin middle , //3 for stay at current $data->email=$serviceRequest->notification_email_id; $data->min; $data->max; $data->key=$data->primary_key; $data->term=$data->primary_negotiation_term; if($option==1){ $data->my_value=$data->my_offer; }else if($option==2){ $data->my_value=($data->primary_negotiation_value+$data- >secondary_negotiation_value)/2; }else{ $data->my_value=$data->my_offer; } $isSatisfied=$this->doOperatorCalculation($data->index,$data- >primary_negotiation_value,$data->secondary_negotiation_value,$data- >operator); if($isSatisfied==0){ if($data->primary_negotiation_value>=$data- >secondary_negotiation_value){ $data->max=true; }else{ $data->min=true; } }else{ if($data->primary_negotiation_value>=$data- >secondary_negotiation_value){ $data->min=true; }else{ $data->max=true; } }
Trimodal Negotiation
[0151] An expedited machine and system negotiation feature of the present disclosure occurs between two parties when their interests are closely matched but not completely matched. Coded non-transitory processor-readable storage media instructions executed by at least one processing circuit to perform a service request for automated negotiations, also known as the RoboNegotiator system, are disclosed herein.
[0152] The RoboNegotiator solution is intended to act as a mediator, a negotiator and also as a facilitator to explore an individual's wishes which they may not explore with their real-world identity. A user will never be sure that there is another matching User for his/her request. Similarly, another User, even if he exists, will not know about the message User1 has posted for User2 unless both have matching terms for each other.
[0153] RoboNegotiator provides neutral and anonymous matching to businesses and consumers through three unique services, 1) Introduction of compatible parties, 2) automatic and guided negotiation with unknown or known parties and 3) verification of mutual interests. RoboNegotiator provides all these services securely while exposing deal terms and identities to only matched parties.
[0154] RoboNegotiator is initiating change in the market place. Now high cost deals including Real Estate and Automobiles, Time bound inventory including empty flights and even E*Commerce averse businesses including luxury brands can go out and touch formally unknown customers through RoboNegotiator's secret but independent Matching As A Service capabilities.
[0155] In a disclosed embodiment, matches occur on a first come first serve basis or first in first out basis but a negotiation is open to a better offer in the middle of a negotiation in the interest of at least one of the parties. An option is also included which locks the parties in negotiation after a match on anonymity is found unless both parties consent to an open negotiation in a third party's interest.
[0156] There are at least three operating modes for the disclosed system. The modes are known as classic, automatic and guided. The Classic mode handles deals the way deals are handled in the real world between two or more parties without digital automation or digital circuits. Buyer and Seller offers are relayed to each other openly with the blackbox or RoboNegotiator as the communicator via email or text and other media. The process happens without the need for face-to-face communication.
[0157] An embodiment includes a tri-operating mode module for the disclosed system including classic, automatic and guided modes where the automatic mode uses the match database, match engine and match engine logic. The guided mode is a hybrid of the automatic mode and the classic mode which simply introduces matching clients.
[0158] The Automatic mode gets the lowest price the seller is willing to sell at the highest price the buyer is willing to go with. The blackbox and RoboNegotiator match the best possible parties with one another with a focus on making sure they both save some money and more importantly time via the disclosed match engine components, circuits, modules and non-transitory computer readable instructions.
[0159] The Guided mode gets preferences from both sides to engage them in negotiations according to their preferences. One side can choose the disclosed system to manage negotiation and the other side may prefer to negotiate on his or her own. All communication is done in a neutral, unbiased manner.
[0160] RoboNegotiator consists of the Match Engine and Negotiation System. In an negotiation application, RoboNegotiator takes interest deals from the sellers in the form of product or services to be sold, quantity, minimum selling price, negotiation mode (automatic, classic and hybrid) and contact details of the sellers along with additional optional product/service-related data.
[0161] Asynchronously, at a later time, RoboNegotiator takes counter offers from buyers providing their maximum purchase price, quantity, contact details for a given product/service so RoboNegotiator can match terms from sellers and buyers and then inform parties if they are matching or not. If they are close to each other in terms of difference, RoboNegotiator decides if they need to negotiate back and forth before they mutually agree on a price depending on predetermined threshold values.
[0162] When a buyer offers his/her price for a given product on any website, four outcomes from RoboNegotiator are possible: 1) There is no deal for this product from this seller (where buyer counter offered) or from any other sellers. Nothing happens and offer remains in system waiting to be matched. 2) Buyer's counteroffer is too lownot worth going into negotiation. 3) Buyer's counteroffer matched with seller's deal terms and two parties will be introduced along with a mutually agreed price calculated in an unbiased way. 4) Buyer's counteroffer is close to seller's deal terms, but two parties will need to negotiate back and forth before deal can be reached.
Negotiation Modes
[0163] In Automatic Negotiation mode, the seller or buyer have agreed to provide all negotiation related details to RoboNegotiator so RoboNegotiator can do negotiations for that party or those parties. In case of seller preferring this mode, the seller is asked to choose a deal price (also referred as Minimum Sell Price). In order to negotiate further down, if a buyer is offering close to MSP, how low the seller is willing to go is also predetermined. On other hand, when a buyer prefers this mode, the buyer is asked for their highest offer in case an automatic negotiation is able to take place.
[0164] Once RoboNegotiator gets all details, RoboNegotiator decides if the buyer and seller match or they don't, including lowest and highest numbers within predetermined ranges or thresholds. This quick decision making by RoboNegotiator allows it to offer expedited negotiation progress instantaneously from the buyer and seller's point of views.
Example
[0165] Seller A with email and phone #805777AAAA prefers an automated mode of negotiation for product XYZ and offers MSP (deal price) at $100. Along with it, Seller A also provides RoboNegotiator $90 as their lowest sell price in case an automatic negotiation needs to take place. Therefore, Seller: $100 initial offer, $90 lowest offer to sell.
[0166] On other hand, Seller B with an email and phone #805777BBBB prefers an automated mode of negotiation for the same product XYZ and makes a committed offer at $85. Along with it, Seller B also provides RoboNegotiator $95 as his/her highest offer in case negotiation needs to take place. Therefore, Buyer: $85 initial offer, $95 highest offer to buy.
[0167] RoboNegotiator compares $100 and $85 first followed by $90 and $95 and decides that they match and being unbiased, independent negotiator, it settles them at $92.50 giving both of them benefit of $2.50 from their lowest/highest offers.
[0168] RoboNegotiator sends email and/or text to both parties introducing them with their name, email address, phone number along with mutually agreed price of $92.50 so two parties can contact each other and finish remaining business formalities including payment, delivery of product/service, etc.
Classic Mode Negotiation
[0169] RoboNegotiator uses Twilio API (Texting gateway) to send texts to all users involved here. In this mode, seller (or buyer) decides to remain in full control of his/her negotiation progress and wants RoboNegotiator to find another party and relay information about negotiation back and forth and nothing else.
[0170] In case of seller preferring the classic mode, the seller is asked to choose a deal price also referred to as a Minimum Sell Price. On other hand when a buyer prefers this mode, the buyer is asked his/her initial offer (counteroffer). After the parties have been virtually introduced by the disclosure in an anonymous manner, the parties decide based on these figures if they should be negotiating or not depending on the spread difference in their numbers with deference given to the seller.
[0171] RoboNegotiator has a preconfigurable data point spread about when negotiation should occur. It could be 10% or 25% or other numbers. If seller's numbers and buyer's numbers are within this numbers spread, RoboNegotiator decides to engage them.
[0172] RoboNegotiator (RN) uses email addresses and/or text numbers to reach out to these two parties when it decides that they should negotiate and goes back and forth until they decide to quit negotiating, or they don't take actions until certain expiry time period or their numbers finally match.
[0173] RN informs both parties at a beginning of the negotiation and reveals two numbers (seller's and buyer's) and asks buyer to go up whereas seller to go down. RoboNegotiator provides a common link/URL where the deal related parameters can be updated and hence it tracks a buyer's new numbers as well as a seller's numbers via an indexed relational database. Once a seller updates or a buyer updates or both update their numbers independently, RoboNegotiator checks both # s (updated) again and decides to relay information further if they have not matched. If matched, both parties are notified with each other's identity and both are also made aware of a mutually agreed price (negotiated amount) in an unbiased way.
Example
[0174] a configuration says a 10% difference spread will result in a negotiation in play. Now the seller has offered a deal for $100 whereas the Buyer has countered it for $95. The 5% difference from the maximum number is within the spread so a negotiation kicks in.
[0175] RoboNegotiator sends the seller an email and/or text informing them that there is another party (buyer) and a negotiation needs to occur down from $100. A similar email/text goes to the buyer requesting them to go up. Both of them see each other's numbers but not each other's identity. Let's assume the seller goes down from $100 to $98 while buyer moved up from $95 to $97. RoboNegotiator gets updated numbers and compares them again and sends two emails/texts to both parties with the new updated numbers.
[0176] Assuming the Seller goes down to $97 while buyer goes up to $98 independently, RoboNegotiator automatically gets these numbers independently and introduces them in middle at $97.50 giving $0.50 benefit to both seller and buyer. The Seller gets buyer's contact details (name, number, text #) and similarly the buyer gets the seller's contact details along with mutually agreed price $97.50 so they can do their remaining business/formalities (payment, delivery of product, etc.)
Hybrid/Guided Mode Negotiation
[0177] In this mode, we allow a seller and a buyer to choose their own preferred way of negotiation. It is possible that a seller may choose automatic mode while a buyer may choose classic mode. The disclosed RN provides an intelligent way to act as an independent, unbiased middleman in this situation and support a preferred method.
[0178] For Example: a Seller has chosen the automatic mode of negotiation and wants RoboNegotiator to do the negotiation for them. The Seller provides all data for product XYZ in terms of deal price, minimum sell price and quantity. The Seller also mentions he wants to negotiate a maximum 3 times of back and forth negotiations. The Buyer has requested one unit of this same product and prefers to deal himself for the negotiation and hence chose classic mode.
[0179] Let's say Seller: XYZ, $100, $90, 25, Automatic, 3 Buyer: XYZ, $88, 1, Classic. In this case, RoboNegotiator takes service requests from both parties as described and let's the buyer engage in negotiation while using all confidential data from the seller. Since the seller has given us a lowest amount $90 and 3 attempts, RN goes back to the buyer every time decrementing from $100 in subsequent attempts$96.66 Attempt 1, $93.33 Attempt 2 and $90.00 in attempt 3 making sure we never go below seller's lowest selling price. Buyer goes up from $88 and at some point, they will match, or they will stop negotiating further (if buyer didn't respond or we tried 3 times going back). In case of successful match, RoboNegotiator introduces two parties and reveals mutually agreed price.
Live Negotiation
[0180] In an embodiment of the disclosure, Live Negotiation is started through a button in product catalog by a buyer. RoboNegotiator comes with a specially built JavaScript that can be integrated in any website platform. The script generates a button Negotiate through RoboNegotiator in a virtual product catalog. This button supposedly engages a buyer/website visitor when they don't want to pay list price of a product and when they want to negotiate with the seller. Since seller has chosen automatic mode of negotiation for this option to work, RoboNegotiator engages the buyer through series of dialogs and makes them feel as if they are negotiating in real time with a seller for a product.
[0181] Overall live negotiation has the following outcomes. There is no deal from this seller (whose website buyer is browsing through) or from any other seller for the same product and hence a buyer can provide their counter-offer to RoboNegotiator so it can find a seller for them. When a Buyer's offer is too low (far from seller's minimum selling price) negotiation on behalf of seller is halted because the buyer's counteroffer is outside the difference spread and the buyer is not regarded as a serious buyer for that particular seller. When a Buyer offers little less than seller's minimum selling price, RN helps the buyer to come up and match to seller's deal. In the event a Buyer offers above seller's minimum selling price, RN matches them and introduce them to each other.
[0182] The JavaScript allows sellers to offer Live Negotiation button along with Add to Shopping Cart button in their product catalog as shown below. This JavaScript engages a buyer/website visitor in an automated way when it gets clicked. The JavaScript opens a chatbot and Chatbot shows various messages and instructions for a buyer to get engaged. The disclosed JavaScript does this in 5 steps as shown below and uses specially built REST APIs to talk to RoboNegotiator Systems in other servers for appropriate responses.
[0183] Step 1:
[0184] Get Counteroffer from buyerClicking button on Negotiate Through RoboNegotiator asks buyer/visitor to end his counter offer only. Let's assume this amount is$amount. JavaScript calls InstantDealCheck and receives information if there is any deal for this product (UPC Product Code) in system from same seller or other sellers etc and returns following kind of response.
[0185] Step 2:
[0186] Call/api/instantDealCheck and receive following response from backend:
TABLE-US-00003 Response: { success: true, deal_exist: yes, deal_count: 1, same_seller: yes }
[0187] JavaScript shows the response that Good News. We have a deal etc..)
[0188] and subsequently asks user to enter all details (name, number, email, etc.) and it uses $amount as offer and maximum offer and sends offer to backend using our normal AddBuyerOffer API.
[0189] Step 3:
[0190] call/api/addBuyerOffer where buyer offer_price and buyer_highest_offer_price both are set to $amountIt returns request_ID. This design results in a biased approach for an amount which is above the seller's lowest price without asking for a highest offer from the buyer but using the lowest sell price from seller. The API call and response are shown above.
[0191] Now, RN gives the buyer information about the status of negotiationsif his counter offer would work or not and hence CheckBuyerOfferWithID is calledwhere a request ID is what was assigned to AddBuyerOffer in an earlier step. It is expected this call returns a result similar to the following JavaScript. If it matches, it will return to negotiation or it is too low. The JavaScript responds appropriately to a user and asks for a counter-offer (update offer) if needed.
[0192] Step 4:
[0193] /api/checkBuyerOfferWithId (pass request_ID) and the following request.
TABLE-US-00004 { success: true, details: Matched Found, response: if the offer gets into the system it will have status: deal_closed, message: deal_closed, potential_result: match } OR { success: true, details: Matched Found, response: if the offer gets into the system it will have status: too_low, message: too_low, potential_result: too_low } OR { success: true, details: Matched Found, response: if the offer gets into the system it will have status:negotiation_with_no_mode, message: negotiation_with_no_mode, potential_result: in negotiation }
[0194] Step 5
[0195] In case a response is In negotiation, the disclosure gets an updated amount from a buyer $amount2 and calls/api/updateBuyerOffer for the request_ID used above and passes $amount, $amount2 to update the same original offer.
TABLE-US-00005 Response body { success: true, response: { success: true, message: ServiceRequest 2 has been updated successfully., request_id: 2 }, message: Buyer Offer has been updated successfully., request_id: 2 }
[0196] Step 6
[0197] /api/getDealStatus
result: 1, // this field dictates if there was a match or not. 1=matched status: 1
[0198] If there was a match and a deal closed, a response has body with additional details. Otherwise, a response is generated like the following:
TABLE-US-00006 result: 0, // this field dictates if there was a match or not. . 0 = no matched status: 1, { success: true, data: [ { id: 2, upc_product_code: lexus_green_es330, transaction_type: BUYER, quantity: 1, remaining_quantity: 0, notification_email_id: buyer@robonegotiator.com, notification_contact_number: 9379697626, result: 1, status: 1, expiry_date: 2020-03-23 00:00:00, added_on: 2020-02-22 02:51:39, edited_on: 2020-02-22 02:39:10 } ], closed_deal: { id: 1, type1_request_id: 1, type2_request_id: 2, upc_product_code: lexus_green_es330, seller_email: seller@robonegotiator.com, buyer_email: buyer@robonegotiator.com, type1_type: SELLER, type2_type: BUYER, type1_key: FBVBK0kSoW, type2_key: c1Qwiw1UGD, type1_negotiation_term: seller_deal_price, type2_negotiation_term: buyer_offer_price, type1_negotiation_mode: auto, type2_negotiation_mode: auto, type1_initial_offer: 4500, type2_initial_offer: 4700, type1_negotiation_best_offer: 4400, type2_negotiation_best_offer: 4800, final_amount: 4600, type1_final_amount: 4600, type2_final_amount: 4600, matched_quantity: 1, type1_result: 1, type2_result: 2, comment: 2:Full Match, 1:Partial Match, created_at: 2020-02-22 02:39:11, updated_at: 2020-02-22 02:39:11 } ] }
[0199] The above section shows various negotiation modes which are uniquely designed and supported by RoboNegotiator.
Sales Automation Features
[0200] In many eCommerce applications, sellers negotiate through sales team/functions to engage customers/buyers to close deals. Final negotiations make sure a buyer and a seller are on same page. Usually these interactions occur during business hours through phone, emails and/or in-person meetings/negotiations.
[0201] CPQ (Configure, Price and Quote) tools are common in industries nowadays where sales teams configure product offerings based on bundle or various parameters and generates price lists and quotations for buyers. RoboNegotiator provides website based/self-serve negotiation capabilities so sellers get multiple advantages. Deal closing functions operate 247 through website traffic.
[0202] RN doesn't need any salespersons to be in an office or on a computer, email, phone call. Usually a seller negotiates on the phone and follows through via email on some pre-defined needs/conditions. RN provides features to sellers to define those rules/negotiation parameters ahead of the time so RoboNegotiator can close deals and finish negotiations as if occurring the same way.
Define Negotiation Parameters and Rules
[0203] (1) Ability for a seller to decide negotiation parameters/rules which dictate how negotiation will be carried out by a RoboNegotiator service, including a) Pro Buyer Parameters, b) Pro Seller Parameters, c) Using AI/Machine Learning Results for deciding negotiation outcomes.
[0204] The disclosure defines the following 10 rules/negotiation parameters which a seller can define for any of his/her product deals. RoboNegotiator honors these rules/parameters when in play and when applicable. [0205] 1) If a buyer is a repeat customer, offer special discounts and go pro-buyer by being lenient in a negotiation and giving preference to the buyer. [0206] 2) If a buyer is buying more quantity (usually more than 1), offer a special discount and go pro-buyer by being lenient in negotiations and let the buyer close the deal. [0207] 3) If this particular product is more in stock and incurs inventory cost for keeping inventory in a warehouse on a shelf-cost basis, a seller may decide to offer a special discount to a buyer and hence prefers negotiations to be pro-buyer. [0208] 4) This product is out of fashion/older model so go pro-buyer and be lenient in negotiations in order to close a deal. [0209] 5) Seller wants to give some special consideration/discount to a buyer (undefined) so trimodal negotiations go pro-buyer [0210] 6) Seller wants top dollar for a product in negotiation as this product is hot/in demand and in limited quantity so deference goes to the seller. [0211] 7) Seller is incurring some extra cost for selling this product including shipping cost or other and hence seller wants to go pro-seller route in negotiations including a tighter spread on seller offers and a liberal spread on the buyers offers. [0212] 8) Seller has knowledge of buyer's demographics who buys this product. Seller wants to go pro-seller route (be stricter in negotiation) when buyer who is buying now falls in these demographic parameters [0213] 9) Seller wants to see historic sell prices of this product and wants to go pro-buyer or pro-seller based on current negotiation price compared to market data. [0214] 10) Seller wants to go pro-seller for special (undefined) reasons.
[0215] These 10 parameters/rules get fed into RoboNegotiator negotiation server through special variables/fields in a database by calling special APIs. Negotiations transpire logically by these parameters and adjusts negotiation technique/price according to these rules.
AI/Machine Learning Models:
Product Intelligence
[0216] The RN disclosure is in middle of lots of transactions where sellers from many sites/companies are selling products through offering special deals and buyers are negotiating through the disclosed plugins. RoboNegotiator collects lots of information for a given product. For clarity, the following examplary three service requests come from three individuals to RoboNegotiator:
, Name=Dave Shah, Seller Phone #8055320085, Product Selling=Honda Accord, Zip Code=91362, Offer Price=$15000, Lowest Offer Price: $14750
, Name=Sami Shah, Seller Phone #8053005268, Product Selling=Honda Accord, Zip Code=94004, Offer Price=$15100, Lowest Offer Price: $14950
, Name=Biraj Shah, Buyer Phone #8053007424, Product Selling=Honda Accord, Zip Code=91362, Offer Price=$14500, Highest Offer Price: $14750
[0217] One seller in ZIP 91362 might be selling a 2015 year Honda Accord for $15000 while another seller in zip 94004 might be selling a similar car for $14800 and hence RoboNegotiator collects lots of information on various products. All of these products are uniquely identified by a Universal Product Code including the following. [0218] a) Use past historical data: RoboNegotiator itself has lots of data from sellers and buyers around the world and also closed deal prices (negotiated prices from past transactions). RN dives deep into these records to provide average selling prices for a given product anywhere in world using a ZIP code in the USA and even aggregate numbers at the country level. This price information for a given product provides additional information to the seller at the time of coming up with a deal. If the average sell price is $15000 for a same year Honda Accord, it is advisable to come up with a deal for that product which is less than $15000 for example to attract more buyers. [0219] b) Use purchased market data: In a data exchange market place, RN supplies the average purchase price of a given product and uses that information to inform a seller to what is market price for the given product. [0220] c) Use web crawled data/scrapped dataRN also includes technical capabilities to employ web scrappers and web crawlers which check all competitive marketplaces in a given zip code and accumulates listed prices for all products on sale.
Buyer Demographics for a Given Product
[0221] RoboNegotiator uses three sources to provide price level intelligence for any product. RoboNegotiator also collects buyer's counter offers for every product it negotiates on. In this process, RN knows who offered what price for which product. RN collects a buyer's name, email address and phone # when any buyer puts out a counteroffer for a product on sell. This way, we can send SMS and email to that buyer when a successful deal has culminated.
[0222] From data exchanges/marketplaces RN gets demographic attributes for a given buyer like gender, ethnicity, age group, income group, marital status, has pets or not and other information like geographic region (s/he belongs to), Profession and others. This information is retrieved using email addresses and/or phone numbers. Once RN has these buyers' demographic data, it also figures out various interesting demographics data for a given product. It is commonly known that parents or soccer moms characteristically have minivans for example. Now, RN looks at all historical purchase data for Honda Odyssey minivans and heuristically derives that Honda Odyssey is indeed bought/sought after by parents more often than single buyers. Similarly, RN finds out if Japanese cars like Toyota, Honda, Nissan, Lexus, etc. are purchased by Asians in majority or not.
[0223] RoboNegotiator has implemented various machine learning/artificial intelligence models which learn this type of information from data it has accumulated from negotiations and through purchased/web scrapped data sources. At any given time, RN is able to provide the following kind of demographics information for any product. Conversely, we can also provide typical products any particular demographic group buys more often. [0224] a) Show most common (majority) demographics parameters for a product: In this model, machine learning aspects, we look at all data in the past and see all closed deals (successfully negotiated deals) and we can give those demographic parameters for the prospective buyers for that product which are seen in majority of past deals (above 50%) [0225] Gender: Male or Female [0226] IsParent or Not [0227] IsMarried or Not [0228] etc. [0229] b) Majority attribute value for each demographic based on product history
[0230] In this model, RN is able to derive the value for each demographic parameter which is seen by a maximum number of past buyers for this product. In short, we can show that Honda Odyssey minivan is usually purchased by Gender=Female (52% time), IsParent=Yes (58% time), Ethnicity=Asian Indian (20% of time), Income Group is within $45000 to $75000 (for 28%) etc.
Buyer Negotiation Behavior/Profiling
[0231] RoboNegotiator provides classic, automated, hybrid and live negotiation modes where buyers and sellers go back and forth on their offers while RoboNegotiator matches their offers and introduces them if there is successful match.
[0232] In this fashion, RN collects all past sales data and runs machine learning models and AI algorithms to learn and derive buyer and seller behavior based on historical data. RN is therefore able to inform sellers and buyers or an administrative third party about the likely hood of a buyer going up in his counter offer.
[0233] For example: a buyer is currently negotiating for a 2016 Lexus ES330 car with a seller. Both buyer and seller are going back and forth on their offers.
[0234] Now, old data of when a party has negotiated for let's say product=INSTANT POT or REFRIGERATOR or DELL LAPTOP is available. RN sees from past data if a particular buyer usually negotiates YES or NO. If Yes, how he goes up from his first initial offer. May be, he goes up on average 10% in every attempt and maximum he has gone up is 25% in past. The data doesn't predict he will do the exact same thing while negotiating for Lexus ES330 (current negotiation in progress) but a seller can definitely use this information to adjust his counter offer accordingly.
Seller Negotiation Behavior/Profiling
[0235] RoboNegotiator provides classic, automated, hybrid and live negotiation modes where buyers and sellers go back and forth on their offers while RoboNegotiator matches their offers and introduces them if there is successful match.
[0236] In this fashion, RN collects all past data and runs proprietary machine learning models and AI algorithms to learn about seller behavior based on historical data and informs buyers or a RoboNegotiator administrator about likely hood of a seller going down in his counter offer based on historical habits.
[0237] For example: a seller@robonegotiator.com currently negotiates for a product 2016 Lexus ES330 car with a buyer. Both are going back and forth on their offers.
[0238] Now, the old data of how he negotiated in past deals for let's say product=INSTANT POT or REFRIGERATOR or DELL LAPTOP is used. RN determines from past data if this seller usually negotiates YES or NO. If Yes, how he goes down from his first initial offer. May be, he goes down on average 10% in every attempt and maximum he has gone down 25% in past. These data don't predict he will do exact same thing while negotiating for Lexus ES330 in a current negotiation in progress but a buyer can definitely use this information to adjust his counter offer accordingly.
Negotiation Forecasting/Prediction
[0239] Having product information from past deals and market data and having enough information from a buyer and a seller, RN makes predictions about whether a current negotiation will result in success or failure. For example: Seller A is asking for $15000 for Honda Odyssey car while Buyer B is offering $13500 for the same car. Now if we know this car (this product) historically has sold for $14500 and RN also learned that the buyer doesn't go UP usually after his initial offer and seller goes down hardly 10%. Based on all data on hand, RN predicts that seller and buyer would not agree and negotiation will fail at the end.
[0240] On other hand, if the buyer is frequently going UP and if product is sold historically for $13000, seller is most motivated to go down from $15000 to $14000 and there are high chances buyer will come up to $14000 as well and this negotiation will result in a pass or consummated deal.
[0241] In shortthrough combined data learned or derived from all 4 models listed above, it is possible for RN to define if a current negotiation will turn successful or will result in failure by not meeting at a common point.
Business Analytical Reports
[0242] A Seller, after uploading a deal for various products, is able to generate reports on how deals are performing in terms of getting additional business insights. Since RoboNegotiator service is between sellers and buyers, it is able to capture information, offers, counter offers from many buyers and many sellers from various channels. RN comprises a centralized database and hence provides business analytics reports as and when needed around the following aspects. [0243] 1) Who is selling which product in a given ZIP or state or country? [0244] 2) Who is selling a particular product (let's say Honda Accord car)? [0245] 3) How many offers for a given product (red Honda Accord car) came in for a given seller on his website in last one month? Last one week? Yesterday? What was Minimum, Maximum, Average counteroffer from these users/web site visitors [0246] 4) How many visitors made a counteroffer and through correlating this data with Google Analytics, RN provides what % website visitors looked at the particular product page and what % counter offered. [0247] 5) What product is negotiated the most in any certain category? [0248] 6) What is the typical demographics of the buyers who buy a product? [0249] 7) What products are usually going through maximum negotiations? [0250] 8) What products are hot items where sellers usually do not negotiate? [0251] 9) What products are sellers desperate to get rid of? Based on their offers and negotiation histories? [0252] 10) Who sells a particular product cheapest in certain state/country? [0253] 11) What products are bought most across geo-political borders (global buyers included)? [0254] 12) And many more.
[0255] RN also adds certain data dimensions and attributes from industry that allow clients to extend our business intelligence and analytics capabilities.
Portability of JavaScript/Many Platforms
[0256] A Live negotiation button is included in a product catalog developed through our plain JavaScript which doesn't use jQuery or CSS or any third-party dependencies. RN has deliberately chosen to develop JavaScript to port and install in a maximum number of websites/platforms without causing any conflict with other jQuery or CSS versions.
[0257] The disclosed RN JavaScript is developed as portable library/plugins which are easy to install in any CMS and non-CMS based eCommerce websites where product catalogs are usually offered. The disclosed RN JavaScript takes the following parameters from the store owner/CMS developers in order to provide live negotiation capability in any platform:
1) API key=identifier or license key to work with RoboNegotiator
2) Product Code=Unique Identifier of the product (ideally Universal Product Code) used to uncover what product is being sought after by a website visitor/buyer.
3) Seller Email Address of a productSince the disclosed RN JavaScript plug in does end to end negotiation with a buyer on behalf of a seller, we introduce two parties at the end and hence we need to retrieve seller's email address.
4) Negotiation ModeAutomatic/Classis, etc. so we can let buyer and seller negotiate based on their own preferences.
E*Commerce Eco System
[0258] RoboNegotiator has developed solving eCommerce industry problems by thinking through how negotiation is used by many buyers and many sellers independently while RoboNegotiator matches buyers and sellers coming from various channels. In order to get to larger adoption of RoboNegotiator, it has developed an eco system of components and service so that maximum website technologies, sellers, buyers, industries can utilize RoboNegotiator. Disclosed plug-ins are used in Magento, Shopify, WooCommerce, 3DCart, Opencart, Prestashop, BigCommerce, PHP, Wix, Wordpress based sites easily.
[0259] In addition to coming up with portable JavaScript which can be installed in almost all platforms, RN also provides industry standard REST API interfaces for services so almost anyone can integrate with RN and its services. The ability to host services on many load balanced servers with many databases allow RN to scale operations across 1000s of companies across many geographic locations.
[0260] An embodiment of the disclosure uses various data points to predict/forecast if a given negotiation underway for a given product between a certain buyer and certain seller is likely to go through or not and its chances of success.
[0261]
[0262]
[0263]
[0264]
[0265]
[0266]
[0267] The hybrid mode mixes the classic mode and the automated mode as described herein. Auto mode is entered upon determination that the negotiations are fully automated. The classic mode allows the seller and the buyer to interact over chat, email and other communications. The live mode is enabled by the seller predetermining and entering into system memory all negotiation parameters as disclosed herein and the buyer's terms entered into the disclosed system in real time. The live mode is also enabled by a buyer starting the negotiation on a plugin platform. Party identities are disclosed after entering live mode. The automated mode occurs behind the scenes so to speak without any input from the parties based on anonymous accounts and profiles being created. Negotiations continue via an n number of negotiations.
[0268] While the forgoing examples are illustrative of the principles of the present disclosure in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention.
[0269] Accordingly, it is not intended that the disclosure be limited, except as by the specification and claims set forth herein. While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope of the disclosure.
[0270] Although the operations of the method(s) herein are shown and described in a particular order, the order of the operations of each method may be altered so that certain operations may be performed in an inverse order or so that certain operations may be performed, at least in part, concurrently with other operations. In another embodiment, instructions or sub-operations of distinct operations may be implemented in an intermittent and/or alternating manner.