DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following FINAL Office Action is in response to Applicant’s communication filed 11/03/2025 regarding Application 18/686,485.
Status of Claim(s)
Claim(s) 1-4, 6, and 8-13 is/are currently pending and are rejected as follows
Response to Arguments – 101 Rejection
Applicant’s arguments in regards to the previously applied 101 rejection have been fully considered and deemed persuasive.
Examiner therefore withdraws the previously applied 101 rejection.
Response to Arguments – 102 Rejection
Applicant’s arguments in regards to the previously applied 102 rejection are rendered moot in view of the newly amended prior art rejection below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 6, 8, and 10-11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen (US 2021/0390647 A1) in view of Fitzgerald (US 10,825,084 B1)
Claim(s) 1 and 6 –
Chen discloses the following limitations:
a memory configured to store instructions; and (Chen: Paragraph 63, "No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
a processor configured to execute the instructions (Chen: Paragraph 63, "No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
acquiring history information about a proposal which has been implemented in a negotiation…; (Chen: Paragraph 22, "In other instances, a second party that receives a proposal from a first party may receive intelligent suggestions for counterproposal terms based on the transaction history, and deal-flow characteristics and/or other characteristics of the first party (e.g., suggested rates, terms, concessions, transactional history, tenant industry, locale, etc.). Such intelligent suggestions during negotiations may improve the efficiency of the negotiation process and result in reduced usage of network resources."; Paragraph 25, "Client devices 102, 104, and 106 may be configured to receive and transmit proposals and counter-proposals related to a negotiation. Additionally, client devices 102, 104, and 106 may be configured to receive outside data related to transaction histories, market data, financial trends, etc. to train at least one machine learning algorithm. The client devices 102, 104, and 106 may then receive intelligent dealterm suggestions based on the trained machine learning algorithm(s) related to the proposals/counter-proposals. In aspects, a client device, such as client devices 102, 104, and 106, may have access to one or more data sources and/or databases comprising third-party market data, asset information (e.g., comparable property valuations, most current lease rate, etc.), past deal-flow history of the other negotiating party (e.g., time to respond to new proposal, terms most likely to negotiate, terms most likely to not negotiate, etc.). In other aspects, client devices 102, 104, and 106, may be equipped to receive broadband and/or satellite signals carrying proposal/counter-proposal information to be displayed on a display device, such as a client devices 102, 104, and 106. The signals/information that client devices 102, 104, and 106 may receive may be transmitted from satellite 122. Satellite 122 may also be configured to communicate with network(s) 108, in addition to being able to communicate directly with client devices 102, 104, and 106. In some examples, a client device may be a mobile phone, a laptop computer, a tablet, a smart home device, a desk phone, and a wearable (e.g., smart watch), among other devices.")
acquiring an evaluation value for a proposal from a negotiation counterpart as its own expected utility value according to a negotiation phase; and (Chen: Paragraph 28, "Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise."; Paragraph 37, "In conjunction with the user making edits to the cloned version of the initial proposal, the intelligent contract staging and capturing system described herein may provide suggestions to the user, wherein the suggestions may comprise proposed terms for a counter-proposal. The intelligent suggestions for counterproposal terms may be based on predictive analytics and/or at least one trained machine learning model that may be trained on historical transactional/deal-flow history related to the LO, similarly situated assets and valuations (in this example, property locations), current market trends, future market predictors, and other data sources relevant to providing intelligent counter-proposal term suggestions. The user may approve or disapprove of the suggestions, so the ultimate counterproposal may comprise entirely of intelligent suggestions, a combination of intelligent suggestions and user-generated terms, or entirely of user-generated terms.")
learning a determination method for an own proposal to the negotiation counterpart, based on the history information and the evaluation value by learning the counterpart’s behavior pattern and the time series change of the negotiation…. (Chen: Paragraph 23, "Accordingly, the present disclosure provides a plurality of technical benefits including but not limited to: enabling more efficient use of electronic resources during negotiations; more efficient storage management, since each stage of the negotiation process is captured within the system ( as opposed to each party having to manually download and save a copy of each proposal); and enabling computing devices to generate intelligent negotiation suggestions based on machine-learning and predictive analytics algorithms, among other examples."; Paragraph 28, "As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. An ML model may comprise or be inclusive of one or more predictive analytics algorithms. A model may be based on, or incorporate, one or more rule sets, machine learning, predictive analytics, a neural network, or the like. In examples, the ML models may be located on the client device, service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML models may process user transaction and deal-flow history, as well as other data stores of user preferences (e.g., social media profiles) to determine which types of suggestions should be automatically presented to a negotiating party. Determining whether a certain suggestion should be presented may comprise identifying various characteristics of a user's transaction/deal-flow history and preferences, e.g., including at least an average response time. These transaction/deal-flow history data points may be referred to as negotiation metrics. For instance, based on a user's property search history or parameters or if a user has a social media profile that indicates that the user frequently travels to different locales or uses an airport, then the intelligent contract system described herein may determine that a different property asset should be presented to that user (e.g., through an intelligent suggestion prompting the other party to submit a counter-proposal based on the different property). This may be particularly relevant in the scenario of a negotiation for office space or in the residential setting. Rather than submit a counter-proposal based on the initial property in which a user may be interested, a counter-proposal proposing an entirely different property that more likely matches with the user's preferences (e.g., the new property may be closer to public transportation than the initial property) may be a more attractive proposal. Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise."; Paragraph 55, "The method of FIG. 6 begins with receiving and analyzing input related to the first party at step 602. The information related to the first party at step 602 may be provided by database 612 and/or real-time input from the first party, e.g., while the first party is providing proposed deal terms in an in-progress proposal form. The method may then proceed to step 604, where the asset characteristics and historical data related to the asset are received and analyzed. This information may be provided to the system via database 614. For example, the asset may be a property location, where the property characteristics may include geographic location, size, amenities, past tenants, maintenance history, proximity to POis, demographics of the surrounding community, etc. Historical data related to the property location may include the average rent paid for the property over the past ten years, the most recent rent, the most recent rental concession terms (e.g., the number of months of free rent compared to the term duration of the lease), and other historical data that may be relevant to determining intelligent and competitive proposal suggestions. The method may then proceed to analyze current market data at step 606. Current market data may be provided via a third-party data source through database 616 and/or a cloud-based data lake. The current market data may affect certain suggested terms. For instance, if the current market is depressed, where supply is high and demand is low, the intelligent suggestion for the monthly rent for a property location may be lower than average. If the current market data shows a low supply and high demand, then the suggested monthly rent may be higher than average. Another example would be an instance where a property with unique characteristics (e.g., the maximum interior storage height of an industrial building, LEED-ratings, LED lighting fixtures, smart building infrastructure, etc.) in a given geography is being offered for sale. In such an instance, the system may appropriately increase the offering price based on such unique characteristics. Another example would be an adjusted price based on the non-economic terms (e.g., mutual indemnification, representations and warranties) contained in a customer's leasing history.")
Chen does not explicitly disclose the following, however in analogous art of proposal negotiation and management, Fitzgerald discloses the following:
…as vector-formatted data encoded by one-hot encoding for each item (Fitzgerald: Column 5 lines 14 – 43, “FIG. 2 is a schematic diagram of a very simple artificial neural network used to make accept or reject decisions for bids on golf tee times, as one non-limiting example. A plurality of input features is shown on the left side of FIG. 2, each input establishing a value that is input to each node in a column 21. Each input feature or variable is represented numerically through normalization, scaling, or one-hot encoding. For example, when using one-hot encoding, a single category (i.e. colors) is coded into a series of binary representations for each type represented in that the category where only one column has a 1 corresponding to the appropriate category (only the “green” column has a 1, while all other colors are marked with a 0). Scaling and normalization are used to represent numerical data in a similar fashion to the algorithm. For example, rather than inputting the actual bid amount, the input can be the actual bid amount as a percent of the typical sale price. The granularity of the inputs can also vary. For example, an advertising promotion is typically offered for the entire day (or several consecutive days) and thus the input value to the neural network does not change during the day. However, the weather can vary from hour-to-hour and different input values can be supplied on an hourly basis to represent weather variations. Alternatively, the user may decide to use a simple weather forecast for the entire day. Another example of varying granularity is that overall weather conditions could be a single input, or there could be separate inputs for expected temperature, expected windspeed, chance of precipitation, etc.”)
…and updating a neural network to increase its own utility value in a negotiation model. (Fitzgerald: Column 5 line 63 – Column 6 line 6, “Nodes 30 and 32 represent bias values for each node in columns 22 and 24. These bias values may be based on results from prior iterations through the neural network 20 and thus establish a starting point (or constant adjustment) for the input value in each node. The bias values are not necessarily changed for each learning iteration through the neural network 20. Instead, when the algorithm is trained or updated, the weight values are changed to optimize the outcome from the neural network so that, in the context of the golf tee time application for example, the golf course revenue is optimized.”; Column 6 lines 35 – 47, “In one scenario, the initial weights may be randomly selected. Training is then conducted using historical data until the weights converge to values that work fairly well for matching input data with the correct output data. The weight values can then be tested using additional historical data. Finally, in the context of maximizing revenue based on bids, the machine learning algorithm predicts whether a bid should be accepted or declined. Training of the algorithm can continue even after it has been put to use by the optimization and back-propagation techniques described herein (which is generally referred to as updating the algorithm).”)
end the negotiation without reaching an agreement in a case where the negotiation does not reach the agreement by a predetermined time (Fitzgerald: Column 10 line 61 – Column 11 line 10, “On a post hoc basis, all bids submitted (whether accepted or rejected) are evaluated at a step 120. An optimization algorithm, many of which are known by those skilled in the art, receives and evaluates all submitted bids for a given time interval over which the inventory items are consumed. In a golf tee time application, the time interval may be one hour, during which there are typically eight tee times with each tee time able to accommodate four (but not more than four) golfers. The optimization algorithm determines which of the accepted bids should have been rejected in favor of more valuable bids that were received at a later time and also determines which of the rejected bids could have been accepted subject to the capacity constraints of the inventory items. Again, in the golf course tee time application the capacity constraints include eight tee times per hour and no more than four golfers for each tee time.”; Column 12 lines 60 – 65, “A golfer can send bid messages to a course, the message advising that he is willing to pay a specified dollar amount to play the course anytime during an identified time interval. The bid can be input to the machine learning algorithm several times during that interval until the bid is accepted or until the interval has passed.”)
Chen discloses a method for a automated negotiations for physical assets. Fitzgerald discloses a bid negotiation and management engine. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Chen with the teachings of Fitzgerald in order to optimize revenue within business constraints as disclosed by Fitzgerald (Fitzgerald: Column 1 lines 1 – 30, “The invention helps these businesses to make the difficult decisions over which bids to accept and which to reject given these time and capacity constraints.”)
Claim(s) 2 –
Chen in view of Fitzgerald disclose the limitations of claim 1
Chen further discloses the following:
output the history information in vector format data, and (Chen: Paragraph 66,
"Proposal generator module 715 may contain at least one predictive analytics or machine-learning (ML) engine that comprises at least one machine-learning model. The ML engine may be configured to receive user transaction/deal-flow history, other user profile data, comparable asset valuation data, current market data, future market indicator data, standard deal terms based on current deal characteristics, etc., to train at least one machine-learning model or compare against an already-trained machine-learning model. For example, to train the ML model(s), the extracted features of the input data may be associated with specific asset identifiers (e.g., geographic location, size, amenities, proximity to POis, price, etc.). The ML engine may utilize various machine learning algorithms to train the ML model, including but not limited to linear regression, logistic regression, linear discriminant analysis, classification and regression trees, nai:ve Bayes, k-Nearest neighbors, learning vector quantization, neural networks, support vector machines (SVM), bagging and random forest, and/or boosting and AdaBoost, among other supervised and unsupervised machine learning algorithms. The aforementioned machine learning algorithms may also be applied when comparing input data to an already-trained machine learning model. Based on the identified and extracted features and patterns (e.g., related to individual negotiating parties, property locations, standard deal terms, etc.), the ML engine may select the appropriate machine learning algorithm to apply to the features to train the at least one machine learning model. For example, if the received input data are complex and demonstrate non-linear relationships, then the ML engine may select a bagging and random forest algorithm to train the machine learning model. However, if the received features demonstrate a linear relationship to certain features and input data (e.g., price per month of rent for a property location increases as distance to an international airport decreases), then the ML engine may apply a linear or logistic regression algorithm to train the machine learning model.")
the memory stores a neural network that, upon receiving an input of the history information in the vector format data, outputs its own proposal to the negotiation counterpart. (Chen: Paragraph 66, "Proposal generator module 715 may contain at least one predictive analytics or machine-learning (ML) engine that comprises at least one machine-learning model. The ML engine may be configured to receive user transaction/deal-flow history, other user profile data, comparable asset valuation data, current market data, future market indicator data, standard deal terms based on current deal characteristics, etc., to train at least one machinelearning model or compare against an already-trained machine-learning model. For example, to train the ML model(s), the extracted features of the input data may be associated with specific asset identifiers (e.g., geographic location, size, amenities, proximity to POis, price, etc.). The ML engine may utilize various machine learning algorithms to train the ML model, including but not limited to linear regression, logistic regression, linear discriminant analysis, classification and regression trees, nai:ve Bayes, k-Nearest neighbors, learning vector quantization, neural networks, support vector machines (SVM), bagging and random forest, and/or boosting and AdaBoost, among other supervised and unsupervised machine learning algorithms. The aforementioned machine learning algorithms may also be applied when comparing input data to an already-trained machine learning model. Based on the identified and extracted features and patterns (e.g., related to individual negotiating parties, property locations, standard deal terms, etc.), the ML engine may select the appropriate machine learning algorithm to apply to the features to train the at least one machine learning model. For example, if the received input data are complex and demonstrate non-linear relationships, then the ML engine may select a bagging and random forest algorithm to train the machine learning model. However, if the received features demonstrate a linear relationship to certain features and input data (e.g., price per month of rent for a property location increases as distance to an international airport decreases), then the ML engine may apply a linear or logistic regression algorithm to train the machine learning model."; Paragraph 65, "Proposal Generator Module 715 may be configured to run a portion of the operation steps described in FIGS. 2-6, particularly the steps of analyzing data and generating intelligent suggestions related to proposals and counter-proposals. Module 715 may receive data from various sources, as described in FIG. 6. The data may be processed, analyzed, and used to train at least one ML model that may be contained within proposal generator module 715. It should be appreciated that proposal generator module 715 is configured to communicate with communications module 720, where communications module 720 may provide at least one intelligent suggestion to a negotiating party. In some examples, the proposal generator module 715 may be built on the server-side and execute functions using built-in calculations (e.g., pre-programmed lease economic calculations).")
Claim(s) 3 –
Chen discloses the following:
a memory configured to store instructions; and (Chen: Paragraph 63, "No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
a processor configured to execute the instructions (Chen: Paragraph 63, "No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
acquiring history information about a proposal which has been implemented in a negotiation…; (Chen: Paragraph 22, "In other instances, a second party that receives a proposal from a first party may receive intelligent suggestions for counterproposal terms based on the transaction history, and deal-flow characteristics and/or other characteristics of the first party (e.g., suggested rates, terms, concessions, transactional history, tenant industry, locale, etc.). Such intelligent suggestions during negotiations may improve the efficiency of the negotiation process and result in reduced usage of network resources."; Paragraph 25, "Client devices 102, 104, and 106 may be configured to receive and transmit proposals and counter-proposals related to a negotiation. Additionally, client devices 102, 104, and 106 may be configured to receive outside data related to transaction histories, market data, financial trends, etc. to train at least one machine learning algorithm. The client devices 102, 104, and 106 may then receive intelligent dealterm suggestions based on the trained machine learning algorithm(s) related to the proposals/counter-proposals. In aspects, a client device, such as client devices 102, 104, and 106, may have access to one or more data sources and/or databases comprising third-party market data, asset information (e.g., comparable property valuations, most current lease rate, etc.), past deal-flow history of the other negotiating party (e.g., time to respond to new proposal, terms most likely to negotiate, terms most likely to not negotiate, etc.). In other aspects, client devices 102, 104, and 106, may be equipped to receive broadband and/or satellite signals carrying proposal/counter-proposal information to be displayed on a display device, such as a client devices 102, 104, and 106. The signals/information that client devices 102, 104, and 106 may receive may be transmitted from satellite 122. Satellite 122 may also be configured to communicate with network(s) 108, in addition to being able to communicate directly with client devices 102, 104, and 106. In some examples, a client device may be a mobile phone, a laptop computer, a tablet, a smart home device, a desk phone, and a wearable (e.g., smart watch), among other devices.")
acquiring an evaluation value for a proposal from a negotiation counterpart as its own expected utility value according to a negotiation phase; and (Chen: Paragraph 28, "Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise."; Paragraph 37, "In conjunction with the user making edits to the cloned version of the initial proposal, the intelligent contract staging and capturing system described herein may provide suggestions to the user, wherein the suggestions may comprise proposed terms for a counter-proposal. The intelligent suggestions for counterproposal terms may be based on predictive analytics and/or at least one trained machine learning model that may be trained on historical transactional/deal-flow history related to the LO, similarly situated assets and valuations (in this example, property locations), current market trends, future market predictors, and other data sources relevant to providing intelligent counter-proposal term suggestions. The user may approve or disapprove of the suggestions, so the ultimate counterproposal may comprise entirely of intelligent suggestions, a combination of intelligent suggestions and user-generated terms, or entirely of user-generated terms.")
learning a determination method for an own proposal to the negotiation counterpart, using the history information and the evaluation value, by learning the counterpart’s behavior pattern and the time series change of the negotiation… and output its own proposal counterpart (Chen: Paragraph 23, "Accordingly, the present disclosure provides a plurality of technical benefits including but not limited to: enabling more efficient use of electronic resources during negotiations; more efficient storage management, since each stage of the negotiation process is captured within the system (as opposed to each party having to manually download and save a copy of each proposal); and enabling computing devices to generate intelligent negotiation suggestions based on machine-learning and predictive analytics algorithms, among other examples."; Paragraph 28, "As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. An ML model may comprise or be inclusive of one or more predictive analytics algorithms. A model may be based on, or incorporate, one or more rule sets, machine learning, predictive analytics, a neural network, or the like. In examples, the ML models may be located on the client device, service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML models may process user transaction and deal-flow history, as well as other data stores of user preferences (e.g., social media profiles) to determine which types of suggestions should be automatically presented to a negotiating party. Determining whether a certain suggestion should be presented may comprise identifying various characteristics of a user's transaction/deal-flow history and preferences, e.g., including at least an average response time. These transaction/deal-flow history data points may be referred to as negotiation metrics. For instance, based on a user's property search history or parameters or if a user has a social media profile that indicates that the user frequently travels to different locales or uses an airport, then the intelligent contract system described herein may determine that a different property asset should be presented to that user (e.g., through an intelligent suggestion prompting the other party to submit a counter-proposal based on the different property). This may be particularly relevant in the scenario of a negotiation for office space or in the residential setting. Rather than submit a counter-proposal based on the initial property in which a user may be interested, a counter-proposal proposing an entirely different property that more likely matches with the user's preferences (e.g., the new property may be closer to public transportation than the initial property) may be a more attractive proposal. Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise."; Paragraph 55, "The method of FIG. 6 begins with receiving and analyzing input related to the first party at step 602. The information related to the first party at step 602 may be provided by database 612 and/or real-time input from the first party, e.g., while the first party is providing proposed deal terms in an in-progress proposal form. The method may then proceed to step 604, where the asset characteristics and historical data related to the asset are received and analyzed. This information may be provided to the system via database 614. For example, the asset may be a property location, where the property characteristics may include geographic location, size, amenities, past tenants, maintenance history, proximity to POis, demographics of the surrounding community, etc. Historical data related to the property location may include the average rent paid for the property over the past ten years, the most recent rent, the most recent rental concession terms (e.g., the number of months of free rent compared to the term duration of the lease), and other historical data that may be relevant to determining intelligent and competitive proposal suggestions. The method may then proceed to analyze current market data at step 606. Current market data may be provided via a third-party data source through database 616 and/or a cloud-based data lake. The current market data may affect certain suggested terms. For instance, if the current market is depressed, where supply is high and demand is low, the intelligent suggestion for the monthly rent for a property location may be lower than average. If the current market data shows a low supply and high demand, then the suggested monthly rent may be higher than average. Another example would be an instance where a property with unique characteristics (e.g., the maximum interior storage height of an industrial building, LEED-ratings, LED lighting fixtures, smart building infrastructure, etc.) in a given geography is being offered for sale. In such an instance, the system may appropriately increase the offering price based on such unique characteristics. Another example would be an adjusted price based on the non-economic terms (e.g., mutual indemnification, representations and warranties) contained in a customer's leasing history."; Paragraph 65, "Proposal Generator Module 715 may be configured to run a portion of the operation steps described in FIGS. 2-6, particularly the steps of analyzing data and generating intelligent suggestions related to proposals and counter-proposals. Module 715 may receive data from various sources, as described in FIG. 6. The data may be processed, analyzed, and used to train at least one ML model that may be contained within proposal generator module 715. It should be appreciated that proposal generator module 715 is configured to communicate with communications module 720, where communications module 720 may provide at least one intelligent suggestion to a negotiating party. In some examples, the proposal generator module 715 may be built on the server-side and execute functions using built-in calculations (e.g., pre-programmed lease economic calculations).")
output, upon receiving an input of its own proposal to the negotiation counterpart, outputs a proposal from the negotiation counterpart; (Chen: Paragraph 30, "Because the client devices 102, 104, and 106 are constantly in communication with one another via network(s) 108 and satellite 122, real-time intelligent contract suggestions may be presented to one or more parties currently in negotiations. For instance, sudden market changes may prompt the intelligent contract system described herein to transmit a notification to a party to update a certain term in a counter-proposal. Specifically, a first party may have already transmitted a counter-proposal to a second party. Before the second party may respond to the counter-proposal, the first party may amend and submit a new counter-proposal and retransmit with updated terms, thereby revoking the first counter-proposal and replacing it with the updated terms. However, the initial counter-proposal from the first party is locked and stored, so the second party may review the changes between the initial counter-proposal and the new counterproposal from the first party. Each proposal and counter-proposal submitted within the system is stored and locked to preserve the data integrity of each proposal and counter-proposal, allowing the capture of the flow of negotiations. Such real-time negotiations are available because of the interconnectedness of client device(s) 102, 104, and 106 with network(s) 108 and satellite 122."; Paragraph 36, "At submit proposal 210, a party may transmit an initial proposal or a counter-proposal to the other party. In the initial proposal scenario, a party begins at the property page 202 and selects submit proposal. The submit proposal may be displayed to the user for the user to fill out. In some instances, the submit proposal form may be filled out manually by the user. The system may provide helpful third-party data sources to reference while filling out the proposal form. Additionally, if a user makes a typographical error in the proposal form by putting in an incorrect price (e.g., $1,000 vs. $10,000/month), the intelligent contract system may flag that error for the user. The error may be indicated to the user, and the user may either acknowledge the error and fix the number based on a suggested correction from the intelligent contract system, or the user may dismiss the error notification and proceed with the original entry."; Paragraph 37, "In the counter-proposal scenario at block 210, the initial proposal (from the other party-LO) may be locked and cloned. The locked version may not be edited but may be displayed in conjunction (e.g., adjacent within a display) with the cloned and editable version of the initial proposal. The locked version of each proposal captures the stage of the negotiations at that point in time. Each subsequent counter-proposal is also locked and "daisy-chained" to the initial locked proposal to show the progression and evolution of the contract negotiations. The user (broker/customer in this example) may make edits to the cloned version of the proposal to then create a counter-proposal that will be transmitted back to the LO. In conjunction with the user making edits to the cloned version of the initial proposal, the intelligent contract staging and capturing system described herein may provide suggestions to the user, wherein the suggestions may comprise proposed terms for a counter-proposal. The intelligent suggestions for counterproposal terms may be based on predictive analytics and/or at least one trained machine learning model that may be trained on historical transactional/deal-flow history related to the LO, similarly situated assets and valuations (in this example, property locations), current market trends, future market predictors, and other data sources relevant to providing intelligent counter-proposal term suggestions. The user may approve or disapprove of the suggestions, so the ultimate counterproposal may comprise entirely of intelligent suggestions, a combination of intelligent suggestions and user-generated terms, or entirely of user-generated terms.")
and output, upon receiving an input of a proposal from the negotiation counterpart, the evaluation value. (Chen: Paragraph 37, "In the counter-proposal scenario at block 210, the initial proposal (from the other party-LO) may be locked and cloned. The locked version may not be edited but may be displayed in conjunction (e.g., adjacent within a display) with the cloned and editable version of the initial proposal. The locked version of each proposal captures the stage of the negotiations at that point in time. Each subsequent counter-proposal is also locked and "daisy-chained" to the initial locked proposal to show the progression and evolution of the contract negotiations. The user (broker/customer in this example) may make edits to the cloned version of the proposal to then create a counter-proposal that will be transmitted back to the LO. In conjunction with the user making edits to the cloned version of the initial proposal, the intelligent contract staging and capturing system described herein may provide suggestions to the user, wherein the suggestions may comprise proposed terms for a counterproposal. The intelligent suggestions for counter-proposal terms may be based on predictive analytics and/or at least one trained machine learning model that may be trained on historical transactional/deal-flow history related to the LO, similarly situated assets and valuations (in this example, property locations), current market trends, future market predictors, and other data sources relevant to providing intelligent counter-proposal term suggestions. The user may approve or disapprove of the suggestions, so the ultimate counter-proposal may comprise entirely of intelligent suggestions, a combination of intelligent suggestions and user-generated terms, or entirely of user-generated terms."; Paragraph 50, "The method then proceeds to auto-generate potential proposal suggestions (i.e., intelligent suggestions) based on predictive analytics and/or the trained machine learning model that is trained on e.g., past transaction/deal-flow history related to the first party, similarly situated asset valuations, standard terms given the deal characteristics, current market conditions, future market predictors, etc. The proposals may be provided to the second party, where the second party may either approve or disapprove of the suggestions. The system may receive these approval and disapproval indications as the proposal is crafted. Once the proposal is completed, the proposal may be finalized and provided to the first party at step 414. The system may receive a submission indication from the second party and then subsequently provide the proposal to the first party."; Paragraph 63, "FIG. 7 illustrates an example input processor for implementing systems and methods for intelligently staging, capturing, and facilitating negotiations, as described herein. Input processing system 700 may be embedded within a client device (E.g., client devices 102, 104, and/or 106), remote web server device (E.g., devices 116, 118, and/or 120), and other devices capable of implementing systems and methods for intelligently staging, capturing, and facilitating negotiations. The input processing system contains one or more data processors and is capable of executing algorithms, software routines, and/or instructions based on processing data provided by a variety of sources related to negotiations, transaction history, current market trends, future market predictors, and asset valuations (e.g., intelligently via an ML algorithm and/or manually by a user). The input processing system can be a factory-fitted system or an add-on unit to a particular device. Furthermore, the input processing system can be a general-purpose computer or a dedicated, special-purpose computer. No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
Chen does not explicitly disclose the following, however in analogous art of proposal negotiation and management, Fitzgerald discloses the following:
…as vector-formatted data encoded by one-hot encoding for each item (Fitzgerald: Column 5 lines 14 – 43, “FIG. 2 is a schematic diagram of a very simple artificial neural network used to make accept or reject decisions for bids on golf tee times, as one non-limiting example. A plurality of input features is shown on the left side of FIG. 2, each input establishing a value that is input to each node in a column 21. Each input feature or variable is represented numerically through normalization, scaling, or one-hot encoding. For example, when using one-hot encoding, a single category (i.e. colors) is coded into a series of binary representations for each type represented in that the category where only one column has a 1 corresponding to the appropriate category (only the “green” column has a 1, while all other colors are marked with a 0). Scaling and normalization are used to represent numerical data in a similar fashion to the algorithm. For example, rather than inputting the actual bid amount, the input can be the actual bid amount as a percent of the typical sale price. The granularity of the inputs can also vary. For example, an advertising promotion is typically offered for the entire day (or several consecutive days) and thus the input value to the neural network does not change during the day. However, the weather can vary from hour-to-hour and different input values can be supplied on an hourly basis to represent weather variations. Alternatively, the user may decide to use a simple weather forecast for the entire day. Another example of varying granularity is that overall weather conditions could be a single input, or there could be separate inputs for expected temperature, expected windspeed, chance of precipitation, etc.”)
…and updating a neural network to increase its own utility value in a negotiation model. (Fitzgerald: Column 5 line 63 – Column 6 line 6, “Nodes 30 and 32 represent bias values for each node in columns 22 and 24. These bias values may be based on results from prior iterations through the neural network 20 and thus establish a starting point (or constant adjustment) for the input value in each node. The bias values are not necessarily changed for each learning iteration through the neural network 20. Instead, when the algorithm is trained or updated, the weight values are changed to optimize the outcome from the neural network so that, in the context of the golf tee time application for example, the golf course revenue is optimized.”; Column 6 lines 35 – 47, “In one scenario, the initial weights may be randomly selected. Training is then conducted using historical data until the weights converge to values that work fairly well for matching input data with the correct output data. The weight values can then be tested using additional historical data. Finally, in the context of maximizing revenue based on bids, the machine learning algorithm predicts whether a bid should be accepted or declined. Training of the algorithm can continue even after it has been put to use by the optimization and back-propagation techniques described herein (which is generally referred to as updating the algorithm).”)
end the negotiation without reaching an agreement in a case where the negotiation does not reach the agreement by a predetermined time (Fitzgerald: Column 10 line 61 – Column 11 line 10, “On a post hoc basis, all bids submitted (whether accepted or rejected) are evaluated at a step 120. An optimization algorithm, many of which are known by those skilled in the art, receives and evaluates all submitted bids for a given time interval over which the inventory items are consumed. In a golf tee time application, the time interval may be one hour, during which there are typically eight tee times with each tee time able to accommodate four (but not more than four) golfers. The optimization algorithm determines which of the accepted bids should have been rejected in favor of more valuable bids that were received at a later time and also determines which of the rejected bids could have been accepted subject to the capacity constraints of the inventory items. Again, in the golf course tee time application the capacity constraints include eight tee times per hour and no more than four golfers for each tee time.”; Column 12 lines 60 – 65, “A golfer can send bid messages to a course, the message advising that he is willing to pay a specified dollar amount to play the course anytime during an identified time interval. The bid can be input to the machine learning algorithm several times during that interval until the bid is accepted or until the interval has passed.”)
Chen discloses a method for a automated negotiations for physical assets. Fitzgerald discloses a bid negotiation and management engine. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Chen with the teachings of Fitzgerald in order to optimize revenue within business constraints as disclosed by Fitzgerald (Fitzgerald: Column 1 lines 1 – 30, “The invention helps these businesses to make the difficult decisions over which bids to accept and which to reject given these time and capacity constraints.”)
Claim(s) 4 –
Chen in view of Fitzgerald disclose the limitations of claim 3
Chen further discloses the following:
determine a proposal according to an own proposal to the negotiation counterpart;(Chen: Paragraph 37, "In the counter-proposal scenario at block 210, the initial proposal (from the other party-LO) may be locked and cloned. The locked version may not be edited but may be displayed in conjunction (e.g., adjacent within a display) with the cloned and editable version of the initial proposal. The locked version of each proposal captures the stage of the negotiations at that point in time. Each subsequent counter-proposal is also locked and "daisy-chained" to the initial locked proposal to show the progression and evolution of the contract negotiations. The user (broker/customer in this example) may make edits to the cloned version of the proposal to then create a counter-proposal that will be transmitted back to the LO. In conjunction with the user making edits to the cloned version of the initial proposal, the intelligent contract staging and capturing system described herein may provide suggestions to the user, wherein the suggestions may comprise proposed terms for a counter-proposal. The intelligent suggestions for counter-proposal terms may be based on predictive analytics and/or at least one trained machine learning model that may be trained on historical transactional/deal-flow history related to the LO, similarly situated assets and valuations (in this example, property locations), current market trends, future market predictors, and other data sources relevant to providing intelligent counter-proposal term suggestions. The user may approve or disapprove of the suggestions, so the ultimate counter-proposal may comprise entirely of intelligent suggestions, a combination of intelligent suggestions and user-generated terms, or entirely of user-generated terms."; Paragraph 50, "The method then proceeds to auto-generate potential proposal suggestions (i.e., intelligent suggestions) based on predictive analytics and/or the trained machine learning model that is trained on e.g., past transaction/deal-flow history related to the first party, similarly situated asset valuations, standard terms given the deal characteristics, current market conditions, future market predictors, etc. The proposals may be provided to the second party, where the second party may either approve or disapprove of the suggestions. The system may receive these approval and disapproval indications as the proposal is crafted. Once the proposal is completed, the proposal may be finalized and provided to the first party at step 414. The system may receive a submission indication from the second party and then subsequently provide the proposal to the first party."; Paragraph 63, "FIG. 7 illustrates an example input processor for implementing systems and methods for intelligently staging, capturing, and facilitating negotiations, as described herein. Input processing system 700 may be embedded within a client device (E.g., client devices 102, 104, and/or 106), remote web server device (E.g., devices 116, 118, and/or 120), and other devices capable of implementing systems and methods for intelligently staging, capturing, and facilitating negotiations. The input processing system contains one or more data processors and is capable of executing algorithms, software routines, and/or instructions based on processing data provided by a variety of sources related to negotiations, transaction history, current market trends, future market predictors, and asset valuations (e.g., intelligently via an ML algorithm and/or manually by a user). The input processing system can be a factory-fitted system or an add-on unit to a particular device. Furthermore, the input processing system can be a general-purpose computer or a dedicated, special-purpose computer. No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
add noise to a proposal from the negotiation counterpart determined by the proposal determination means. (Chen: Paragraph 28, "As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. An ML model may comprise or be inclusive of one or more predictive analytics algorithms. A model may be based on, or incorporate, one or more rule sets, machine learning, predictive analytics, a neural network, or the like. In examples, the ML models may be located on the client device, service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML models may process user transaction and deal-flow history, as well as other data stores of user preferences (e.g., social media profiles) to determine which types of suggestions should be automatically presented to a negotiating party. Determining whether a certain suggestion should be presented may comprise identifying various characteristics of a user's transaction/deal-flow history and preferences, e.g., including at least an average response time. These transaction/deal-flow history data points may be referred to as negotiation metrics. For instance, based on a user's property search history or parameters or if a user has a social media profile that indicates that the user frequently travels to different locales or uses an airport, then the intelligent contract system described herein may determine that a different property asset should be presented to that user (e.g., through an intelligent suggestion prompting the other party to submit a counter-proposal based on the different property)."; Paragraph 55, "For example, the asset may be a property location, where the property characteristics may include geographic location, size, amenities, past tenants, maintenance history, proximity to POis, demographics of the surrounding community, etc. Historical data related to the property location may include the average rent paid for the property over the past ten years, the most recent rent, the most recent rental concession terms (e.g., the number of months of free rent compared to the term duration of the lease), and other historical data that may be relevant to determining intelligent and competitive proposal suggestions. The method may then proceed to analyze current market data at step 606. Current market data may be provided via a third-party data source through database 616 and/or a cloud-based data lake. The current market data may affect certain suggested terms. For instance, if the current market is depressed, where supply is high and demand is low, the intelligent suggestion for the monthly rent for a property location may be lower than average. If the current market data shows a low supply and high demand, then the suggested monthly rent may be higher than average. Another example would be an instance where a property with unique characteristics (e.g., the maximum interior storage height of an industrial building, LEED-ratings, LED lighting fixtures, smart building infrastructure, etc.) in a given geography is being offered for sale. In such an instance, the system may appropriately increase the offering price based on such unique characteristics. Another example would be an adjusted price based on the non-economic terms (e.g., mutual indemnification, representations and warranties) contained in a customer's leasing history."; Paragraph 67, "In other aspects, the ML engine may apply at least one already-trained machine learning model and/or predictive analytics to the received input features from the past user transaction/deal-flow history and other user profile data to detect previously identified and extracted data points and preferences (e.g., certain negotiating parties prefer to negotiate on some terms but not others; which terms are most important to one party may not be as important to another party) and previously recognized patterns (e.g., party A will rarely come down on price per month for property locations within X geographic location and with at least Y square units in size, but party A will negotiate rent concessions based on duration of lease for the same property locations). The ML engine may be configured to compare at least one trained machine learning model to the received input data to generate comparison results that indicate which intelligent suggestions should be provided to a user during the formation of a proposal and/or counter-proposal. Specifically, the ML engine may compare the identified and extracted features from a user's past transaction/dealflow history that are associated with specific property characteristics. The ML engine is also configured to generate comparison results, indicating the similarity (or lack thereof) between certain assets (that are the subject of the negotiations). In other aspects, the comparison results may include a suggestion score, which may indicate how confident the system may be that a candidate intelligent suggestion is relevant to the user and/or how confident the intelligent suggestion will expedite the negotiation process and allow the parties to reach mutual agreement. For instance, based on a user's past transaction/deal-flow history and other user profile data, a suggestion score may be assigned to certain candidate intelligent suggestions that may be provided to the user during a proposal/counterproposal cycle. The candidate intelligent suggestions that are scored above a certain threshold may be provided to the user at a certain point in the negotiation cycle, whereas those below the threshold may not be provided (e.g., suggestions with scores of "7" or higher may be provided, but suggestions with scores of "6" or below may not be provided). It should be appreciated that the ML engine embedded within proposal generator module 715 may be its own separate and discrete module within the input processor 700, in some examples. The ML engine may be configured to communicate with communications module 720. In particular, the ML engine may transmit intelligent contract suggestions based on the results of at least one machine-learning algorithm process, as described in FIG. 6, for example.") Examiner equates the statistical analysis and variations of input data according to history data and profile data when generating recommendations for proposals and valuations as described by Chen, to be equitable to adding noise as disclosed in the claim limitation, both in view Applicant's specification and under broadest reasonable interpretation by one of ordinary skill in the art.
Claim(s) 8 –
Chen discloses the following:
a memory; and (Chen: Paragraph 63, "No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
a processor configured to execute instructions to: (Chen: Paragraph 63, "No limitations are imposed on the location of the input processing system relative to a client or remote web server device, etc. According to embodiments shown in FIG. 7, the disclosed system can include memory 705, one or more processors 710, proposal generator module 715, and communications module 720. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.")
acquire history information about proposals implemented in a negotiation… (Chen: Paragraph 28, "Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise."; Paragraph 37, "In conjunction with the user making edits to the cloned version of the initial proposal, the intelligent contract staging and capturing system described herein may provide suggestions to the user, wherein the suggestions may comprise proposed terms for a counter-proposal. The intelligent suggestions for counterproposal terms may be based on predictive analytics and/or at least one trained machine learning model that may be trained on historical transactional/deal-flow history related to the LO, similarly situated assets and valuations (in this example, property locations), current market trends, future market predictors, and other data sources relevant to providing intelligent counter-proposal term suggestions. The user may approve or disapprove of the suggestions, so the ultimate counterproposal may comprise entirely of intelligent suggestions, a combination of intelligent suggestions and user-generated terms, or entirely of user-generated terms.")
acquire an evaluation value for a proposal from a negotiation counterpart as its own expected utility value according to a negotiation phase; (Chen: Paragraph 23, "Accordingly, the present disclosure provides a plurality of technical benefits including but not limited to: enabling more efficient use of electronic resources during negotiations; more efficient storage management, since each stage of the negotiation process is captured within the system (as opposed to each party having to manually download and save a copy of each proposal); and enabling computing devices to generate intelligent negotiation suggestions based on machine-learning and predictive analytics algorithms, among other examples."; Paragraph 28, "As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. An ML model may comprise or be inclusive of one or more predictive analytics algorithms. A model may be based on, or incorporate, one or more rule sets, machine learning, predictive analytics, a neural network, or the like. In examples, the ML models may be located on the client device, service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML models may process user transaction and deal-flow history, as well as other data stores of user preferences (e.g., social media profiles) to determine which types of suggestions should be automatically presented to a negotiating party. Determining whether a certain suggestion should be presented may comprise identifying various characteristics of a user's transaction/deal-flow history and preferences, e.g., including at least an average response time. These transaction/deal-flow history data points may be referred to as negotiation metrics. For instance, based on a user's property search history or parameters or if a user has a social media profile that indicates that the user frequently travels to different locales or uses an airport, then the intelligent contract system described herein may determine that a different property asset should be presented to that user (e.g., through an intelligent suggestion prompting the other party to submit a counter-proposal based on the different property). This may be particularly relevant in the scenario of a negotiation for office space or in the residential setting. Rather than submit a counter-proposal based on the initial property in which a user may be interested, a counter-proposal proposing an entirely different property that more likely matches with the user's preferences (e.g., the new property may be closer to public transportation than the initial property) may be a more attractive proposal. Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise."; Paragraph 55, "The method of FIG. 6 begins with receiving and analyzing input related to the first party at step 602. The information related to the first party at step 602 may be provided by database 612 and/or real-time input from the first party, e.g., while the first party is providing proposed deal terms in an in-progress proposal form. The method may then proceed to step 604, where the asset characteristics and historical data related to the asset are received and analyzed. This information may be provided to the system via database 614. For example, the asset may be a property location, where the property characteristics may include geographic location, size, amenities, past tenants, maintenance history, proximity to POis, demographics of the surrounding community, etc. Historical data related to the property location may include the average rent paid for the property over the past ten years, the most recent rent, the most recent rental concession terms (e.g., the number of months of free rent compared to the term duration of the lease), and other historical data that may be relevant to determining intelligent and competitive proposal suggestions. The method may then proceed to analyze current market data at step 606. Current market data may be provided via a third-party data source through database 616 and/or a cloud-based data lake. The current market data may affect certain suggested terms. For instance, if the current market is depressed, where supply is high and demand is low, the intelligent suggestion for the monthly rent for a property location may be lower than average. If the current market data shows a low supply and high demand, then the suggested monthly rent may be higher than average. Another example would be an instance where a property with unique characteristics (e.g., the maximum interior storage height of an industrial building, LEED-ratings, LED lighting fixtures, smart building infrastructure, etc.) in a given geography is being offered for sale. In such an instance, the system may appropriately increase the offering price based on such unique characteristics. Another example would be an adjusted price based on the non-economic terms (e.g., mutual indemnification, representations and warranties) contained in a customer's leasing history."; Paragraph 65, "Proposal Generator Module 715 may be configured to run a portion of the operation steps described in FIGS. 2-6, particularly the steps of analyzing data and generating intelligent suggestions related to proposals and counter-proposals. Module 715 may receive data from various sources, as described in FIG. 6. The data may be processed, analyzed, and used to train at least one ML model that may be contained within proposal generator module 715. It should be appreciated that proposal generator module 715 is configured to communicate with communications module 720, where communications module 720 may provide at least one intelligent suggestion to a negotiating party. In some examples, the proposal generator module 715 may be built on the server-side and execute functions using built-in calculations (e.g., pre-programmed lease economic calculations).")
learn a determination method for its own proposal to the negotiation counterpart using the history information and the evaluation value by learning the counterpart's behavior pattern and the time-series change of the negotiation; and (Chen: Paragraph 23, "Accordingly, the present disclosure provides a plurality of technical benefits including but not limited to: enabling more efficient use of electronic resources during negotiations; more efficient storage management, since each stage of the negotiation process is captured within the system (as opposed to each party having to manually download and save a copy of each proposal); and enabling computing devices to generate intelligent negotiation suggestions based on machine-learning and predictive analytics algorithms, among other examples."; Paragraph 28, "As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. An ML model may comprise or be inclusive of one or more predictive analytics algorithms. A model may be based on, or incorporate, one or more rule sets, machine learning, predictive analytics, a neural network, or the like. In examples, the ML models may be located on the client device, service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML models may process user transaction and deal-flow history, as well as other data stores of user preferences (e.g., social media profiles) to determine which types of suggestions should be automatically presented to a negotiating party. Determining whether a certain suggestion should be presented may comprise identifying various characteristics of a user's transaction/deal-flow history and preferences, e.g., including at least an average response time. These transaction/deal-flow history data points may be referred to as negotiation metrics. For instance, based on a user's property search history or parameters or if a user has a social media profile that indicates that the user frequently travels to different locales or uses an airport, then the intelligent contract system described herein may determine that a different property asset should be presented to that user (e.g., through an intelligent suggestion prompting the other party to submit a counter-proposal based on the different property). This may be particularly relevant in the scenario of a negotiation for office space or in the residential setting. Rather than submit a counter-proposal based on the initial property in which a user may be interested, a counter-proposal proposing an entirely different property that more likely matches with the user's preferences (e.g., the new property may be closer to public transportation than the initial property) may be a more attractive proposal. Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise."; Paragraph 55, "The method of FIG. 6 begins with receiving and analyzing input related to the first party at step 602. The information related to the first party at step 602 may be provided by database 612 and/or real-time input from the first party, e.g., while the first party is providing proposed deal terms in an in-progress proposal form. The method may then proceed to step 604, where the asset characteristics and historical data related to the asset are received and analyzed. This information may be provided to the system via database 614. For example, the asset may be a property location, where the property characteristics may include geographic location, size, amenities, past tenants, maintenance history, proximity to POis, demographics of the surrounding community, etc. Historical data related to the property location may include the average rent paid for the property over the past ten years, the most recent rent, the most recent rental concession terms (e.g., the number of months of free rent compared to the term duration of the lease), and other historical data that may be relevant to determining intelligent and competitive proposal suggestions. The method may then proceed to analyze current market data at step 606. Current market data may be provided via a third-party data source through database 616 and/or a cloud-based data lake. The current market data may affect certain suggested terms. For instance, if the current market is depressed, where supply is high and demand is low, the intelligent suggestion for the monthly rent for a property location may be lower than average. If the current market data shows a low supply and high demand, then the suggested monthly rent may be higher than average. Another example would be an instance where a property with unique characteristics (e.g., the maximum interior storage height of an industrial building, LEED-ratings, LED lighting fixtures, smart building infrastructure, etc.) in a given geography is being offered for sale. In such an instance, the system may appropriately increase the offering price based on such unique characteristics. Another example would be an adjusted price based on the non-economic terms (e.g., mutual indemnification, representations and warranties) contained in a customer's leasing history."; Paragraph 65, "Proposal Generator Module 715 may be configured to run a portion of the operation steps described in FIGS. 2-6, particularly the steps of analyzing data and generating intelligent suggestions related to proposals and counter-proposals. Module 715 may receive data from various sources, as described in FIG. 6. The data may be processed, analyzed, and used to train at least one ML model that may be contained within proposal generator module 715. It should be appreciated that proposal generator module 715 is configured to communicate with communications module 720, where communications module 720 may provide at least one intelligent suggestion to a negotiating party. In some examples, the proposal generator module 715 may be built on the server-side and execute functions using built-in calculations (e.g., pre-programmed lease economic calculations).")
Chen does not explicitly disclose the following, however in analogous art of proposal negotiation and management, Fitzgerald discloses the following:
…as vector-formatted data encoded by one-hot encoding for each item (Fitzgerald: Column 5 lines 14 – 43, “FIG. 2 is a schematic diagram of a very simple artificial neural network used to make accept or reject decisions for bids on golf tee times, as one non-limiting example. A plurality of input features is shown on the left side of FIG. 2, each input establishing a value that is input to each node in a column 21. Each input feature or variable is represented numerically through normalization, scaling, or one-hot encoding. For example, when using one-hot encoding, a single category (i.e. colors) is coded into a series of binary representations for each type represented in that the category where only one column has a 1 corresponding to the appropriate category (only the “green” column has a 1, while all other colors are marked with a 0). Scaling and normalization are used to represent numerical data in a similar fashion to the algorithm. For example, rather than inputting the actual bid amount, the input can be the actual bid amount as a percent of the typical sale price. The granularity of the inputs can also vary. For example, an advertising promotion is typically offered for the entire day (or several consecutive days) and thus the input value to the neural network does not change during the day. However, the weather can vary from hour-to-hour and different input values can be supplied on an hourly basis to represent weather variations. Alternatively, the user may decide to use a simple weather forecast for the entire day. Another example of varying granularity is that overall weather conditions could be a single input, or there could be separate inputs for expected temperature, expected windspeed, chance of precipitation, etc.”)
update a neural network model to increase its own utility value in a negotiation round. (Fitzgerald: Column 5 line 63 – Column 6 line 6, “Nodes 30 and 32 represent bias values for each node in columns 22 and 24. These bias values may be based on results from prior iterations through the neural network 20 and thus establish a starting point (or constant adjustment) for the input value in each node. The bias values are not necessarily changed for each learning iteration through the neural network 20. Instead, when the algorithm is trained or updated, the weight values are changed to optimize the outcome from the neural network so that, in the context of the golf tee time application for example, the golf course revenue is optimized.”; Column 6 lines 35 – 47, “In one scenario, the initial weights may be randomly selected. Training is then conducted using historical data until the weights converge to values that work fairly well for matching input data with the correct output data. The weight values can then be tested using additional historical data. Finally, in the context of maximizing revenue based on bids, the machine learning algorithm predicts whether a bid should be accepted or declined. Training of the algorithm can continue even after it has been put to use by the optimization and back-propagation techniques described herein (which is generally referred to as updating the algorithm).”)
Chen discloses a method for a automated negotiations for physical assets. Fitzgerald discloses a bid negotiation and management engine. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Chen with the teachings of Fitzgerald in order to optimize revenue within business constraints as disclosed by Fitzgerald (Fitzgerald: Column 1 lines 1 – 30, “The invention helps these businesses to make the difficult decisions over which bids to accept and which to reject given these time and capacity constraints.”)
Claim(s) 10 –
Chen in view of Fitzgerald disclose the limitations of claim 1
Chen further discloses the following:
optimize the learning of the determination method to maintain proposal generation and response processing time per negotiation round within a defined one-time step, while ensuring its own expected utility value at the end of the negotiation is at least a predetermined proportion of the maximum achievable utility value in a negotiation domain. (Chen: Paragraph 37, “In the counter-proposal scenario at block 210, the initial proposal (from the other party—LO) may be locked and cloned. The locked version may not be edited but may be displayed in conjunction (e.g., adjacent within a display) with the cloned and editable version of the initial proposal. The locked version of each proposal captures the stage of the negotiations at that point in time. Each subsequent counter-proposal is also locked and “daisy-chained” to the initial locked proposal to show the progression and evolution of the contract negotiations. The user (broker/customer in this example) may make edits to the cloned version of the proposal to then create a counter-proposal that will be transmitted back to the LO. In conjunction with the user making edits to the cloned version of the initial proposal, the intelligent contract staging and capturing system described herein may provide suggestions to the user, wherein the suggestions may comprise proposed terms for a counter-proposal. The intelligent suggestions for counter-proposal terms may be based on predictive analytics and/or at least one trained machine learning model that may be trained on historical transactional/deal-flow history related to the LO, similarly situated assets and valuations (in this example, property locations), current market trends, future market predictors, and other data sources relevant to providing intelligent counter-proposal term suggestions. The user may approve or disapprove of the suggestions, so the ultimate counter-proposal may comprise entirely of intelligent suggestions, a combination of intelligent suggestions and user-generated terms, or entirely of user-generated terms. “; Paragraph 48, “In some example aspects, as a user is filling out the request for proposal form, the intelligent contract system described herein may provide intelligent suggestions to the user regarding potential assets of interest. For instance, a user that may be filling out a request for proposal regarding a commercial property lease may receive an intelligent suggestion that suggests the user consider a particular property location that may comport with some of the criteria the user has already inputted into the request for proposal form. Such intelligent suggestions may occur in real-time, as the user is filling out the request for proposal form, or, in other example, the suggestions may be presented after a user submits the request for proposal. In the latter example, a user may then indicate to the system that the user would like to receive a request for proposal on a particular suggested property. This indication may be captured by the system and linked to the user's initial RFP. When the other party views the initial RFP, the other party may view the criteria specified in the RFP along with the specific property location that was intelligently suggested by the system.”; Paragraph 55, “The method of FIG. 6 begins with receiving and analyzing input related to the first party at step 602. The information related to the first party at step 602 may be provided by database 612 and/or real-time input from the first party, e.g., while the first party is providing proposed deal terms in an in-progress proposal form. The method may then proceed to step 604, where the asset characteristics and historical data related to the asset are received and analyzed. This information may be provided to the system via database 614. For example, the asset may be a property location, where the property characteristics may include geographic location, size, amenities, past tenants, maintenance history, proximity to POIs, demographics of the surrounding community, etc. Historical data related to the property location may include the average rent paid for the property over the past ten years, the most recent rent, the most recent rental concession terms (e.g., the number of months of free rent compared to the term duration of the lease), and other historical data that may be relevant to determining intelligent and competitive proposal suggestions. The method may then proceed to analyze current market data at step 606. Current market data may be provided via a third-party data source through database 616 and/or a cloud-based data lake. The current market data may affect certain suggested terms. For instance, if the current market is depressed, where supply is high and demand is low, the intelligent suggestion for the monthly rent for a property location may be lower than average. If the current market data shows a low supply and high demand, then the suggested monthly rent may be higher than average. Another example would be an instance where a property with unique characteristics (e.g., the maximum interior storage height of an industrial building, LEED-ratings, LED lighting fixtures, smart building infrastructure, etc.) in a given geography is being offered for sale. In such an instance, the system may appropriately increase the offering price based on such unique characteristics. Another example would be an adjusted price based on the non-economic terms (e.g., mutual indemnification, representations and warranties) contained in a customer's leasing history.”; Paragraph 67, “In other aspects, the ML engine may apply at least one already-trained machine learning model and/or predictive analytics to the received input features from the past user transaction/deal-flow history and other user profile data to detect previously identified and extracted data points and preferences (e.g., certain negotiating parties prefer to negotiate on some terms but not others; which terms are most important to one party may not be as important to another party) and previously recognized patterns (e.g., party A will rarely come down on price per month for property locations within X geographic location and with at least Y square units in size, but party A will negotiate rent concessions based on duration of lease for the same property locations). The ML engine may be configured to compare at least one trained machine learning model to the received input data to generate comparison results that indicate which intelligent suggestions should be provided to a user during the formation of a proposal and/or counter-proposal. Specifically, the ML engine may compare the identified and extracted features from a user's past transaction/deal-flow history that are associated with specific property characteristics. The ML engine is also configured to generate comparison results, indicating the similarity (or lack thereof) between certain assets (that are the subject of the negotiations). In other aspects, the comparison results may include a suggestion score, which may indicate how confident the system may be that a candidate intelligent suggestion is relevant to the user and/or how confident the intelligent suggestion will expedite the negotiation process and allow the parties to reach mutual agreement. For instance, based on a user's past transaction/deal-flow history and other user profile data, a suggestion score may be assigned to certain candidate intelligent suggestions that may be provided to the user during a proposal/counter-proposal cycle. The candidate intelligent suggestions that are scored above a certain threshold may be provided to the user at a certain point in the negotiation cycle, whereas those below the threshold may not be provided (e.g., suggestions with scores of “7” or higher may be provided, but suggestions with scores of “6” or below may not be provided). It should be appreciated that the ML engine embedded within proposal generator module 715 may be its own separate and discrete module within the input processor 700, in some examples. The ML engine may be configured to communicate with communications module 720. In particular, the ML engine may transmit intelligent contract suggestions based on the results of at least one machine-learning algorithm process, as described in FIG. 6, for example.”)
Claim(s) 11 –
Chen in view of Fitzgerald disclose the limitations of claim 3
Chen further discloses the following:
a noise adding unit configured to intentionally add probabilistic noise with predetermined statistical characteristics to a proposal from the negotiation counterpart determined by the proposal determination unit, thereby ensuring statistical diversity in the learning dataset, suppressing overfitting, and improving the generalization performance of the learned determination method for unseen negotiation scenarios in real-world environments, even when the counterpart's action model is deterministic. (Chen: Paragraph 28, "As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. An ML model may comprise or be inclusive of one or more predictive analytics algorithms. A model may be based on, or incorporate, one or more rule sets, machine learning, predictive analytics, a neural network, or the like. In examples, the ML models may be located on the client device, service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML models may process user transaction and deal-flow history, as well as other data stores of user preferences (e.g., social media profiles) to determine which types of suggestions should be automatically presented to a negotiating party. Determining whether a certain suggestion should be presented may comprise identifying various characteristics of a user's transaction/deal-flow history and preferences, e.g., including at least an average response time. These transaction/deal-flow history data points may be referred to as negotiation metrics. For instance, based on a user's property search history or parameters or if a user has a social media profile that indicates that the user frequently travels to different locales or uses an airport, then the intelligent contract system described herein may determine that a different property asset should be presented to that user (e.g., through an intelligent suggestion prompting the other party to submit a counter-proposal based on the different property)."; Paragraph 55, "For example, the asset may be a property location, where the property characteristics may include geographic location, size, amenities, past tenants, maintenance history, proximity to POis, demographics of the surrounding community, etc. Historical data related to the property location may include the average rent paid for the property over the past ten years, the most recent rent, the most recent rental concession terms (e.g., the number of months of free rent compared to the term duration of the lease), and other historical data that may be relevant to determining intelligent and competitive proposal suggestions. The method may then proceed to analyze current market data at step 606. Current market data may be provided via a third-party data source through database 616 and/or a cloud-based data lake. The current market data may affect certain suggested terms. For instance, if the current market is depressed, where supply is high and demand is low, the intelligent suggestion for the monthly rent for a property location may be lower than average. If the current market data shows a low supply and high demand, then the suggested monthly rent may be higher than average. Another example would be an instance where a property with unique characteristics (e.g., the maximum interior storage height of an industrial building, LEED-ratings, LED lighting fixtures, smart building infrastructure, etc.) in a given geography is being offered for sale. In such an instance, the system may appropriately increase the offering price based on such unique characteristics. Another example would be an adjusted price based on the non-economic terms (e.g., mutual indemnification, representations and warranties) contained in a customer's leasing history."; Paragraph 67, "In other aspects, the ML engine may apply at least one already-trained machine learning model and/or predictive analytics to the received input features from the past user transaction/deal-flow history and other user profile data to detect previously identified and extracted data points and preferences (e.g., certain negotiating parties prefer to negotiate on some terms but not others; which terms are most important to one party may not be as important to another party) and previously recognized patterns (e.g., party A will rarely come down on price per month for property locations within X geographic location and with at least Y square units in size, but party A will negotiate rent concessions based on duration of lease for the same property locations). The ML engine may be configured to compare at least one trained machine learning model to the received input data to generate comparison results that indicate which intelligent suggestions should be provided to a user during the formation of a proposal and/or counter-proposal. Specifically, the ML engine may compare the identified and extracted features from a user's past transaction/dealflow history that are associated with specific property characteristics. The ML engine is also configured to generate comparison results, indicating the similarity (or lack thereof) between certain assets (that are the subject of the negotiations). In other aspects, the comparison results may include a suggestion score, which may indicate how confident the system may be that a candidate intelligent suggestion is relevant to the user and/or how confident the intelligent suggestion will expedite the negotiation process and allow the parties to reach mutual agreement. For instance, based on a user's past transaction/deal-flow history and other user profile data, a suggestion score may be assigned to certain candidate intelligent suggestions that may be provided to the user during a proposal/counterproposal cycle. The candidate intelligent suggestions that are scored above a certain threshold may be provided to the user at a certain point in the negotiation cycle, whereas those below the threshold may not be provided (e.g., suggestions with scores of "7" or higher may be provided, but suggestions with scores of "6" or below may not be provided). It should be appreciated that the ML engine embedded within proposal generator module 715 may be its own separate and discrete module within the input processor 700, in some examples. The ML engine may be configured to communicate with communications module 720. In particular, the ML engine may transmit intelligent contract suggestions based on the results of at least one machine-learning algorithm process, as described in FIG. 6, for example.") Examiner equates the statistical analysis and variations of input data according to history data and profile data when generating recommendations for proposals and valuations as described by Chen, to be equitable to adding noise as disclosed in the claim limitation, both in view Applicant's specification and under broadest reasonable interpretation by one of ordinary skill in the art.
Claim(s) 9 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen (US 2021/0390647 A1) in view of Fitzgerald (US 10,825,084 B1) and Kephart (US 2022/028366 A1)
Claim(s) 9 –
Chen in view of Fitzgerald disclose the limitations of claim 1
Chen further discloses the following:
wherein the processor is further configured to execute the instructions to: learn the determination method using the history information and the evaluation value, in a case where proposals implemented in a negotiation are defined within a complex multi-dimensional parameter space comprising multiple negotiation items, each having multiple options… (Chen: Paragraph 28, “As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. An ML model may comprise or be inclusive of one or more predictive analytics algorithms. A model may be based on, or incorporate, one or more rule sets, machine learning, predictive analytics, a neural network, or the like. In examples, the ML models may be located on the client device, service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML models may process user transaction and deal-flow history, as well as other data stores of user preferences (e.g., social media profiles) to determine which types of suggestions should be automatically presented to a negotiating party. Determining whether a certain suggestion should be presented may comprise identifying various characteristics of a user's transaction/deal-flow history and preferences, e.g., including at least an average response time. These transaction/deal-flow history data points may be referred to as negotiation metrics. For instance, based on a user's property search history or parameters or if a user has a social media profile that indicates that the user frequently travels to different locales or uses an airport, then the intelligent contract system described herein may determine that a different property asset should be presented to that user (e.g., through an intelligent suggestion prompting the other party to submit a counter-proposal based on the different property). This may be particularly relevant in the scenario of a negotiation for office space or in the residential setting. Rather than submit a counter-proposal based on the initial property in which a user may be interested, a counter-proposal proposing an entirely different property that more likely matches with the user's preferences (e.g., the new property may be closer to public transportation than the initial property) may be a more attractive proposal. Similarly, in a commercial negotiation context, if a certain broker frequently offers lower-than-normal proposals initially, the intelligent contract systems described herein may capture that pattern of behavior and suggest to the other negotiating party to increase the price of the property asset on counter-proposal, since the broker is likely to increase the price after subsequent cycles of negotiation. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise.”; Paragraph 41, “The method described in FIG. 2 may also apply for comparison of multiple proposals from various negotiating parties interested in the asset. The ML model can be applied to compare all offers and make suggestions in preparing counter-proposals to each proposal or counter-proposal. For example, a tenant solicits request for proposals from multiple land owners based on a set of criteria or a seller requests offers from multiple buyers and in each case, the platform allows concurrent negotiations. The ML model captures the data associated with these concurrent negotiations and is able to intelligently suggest to the tenant/seller which offers may be most competitive, most fair, or most unusual. Additionally, the ML model may be trained on past transaction and deal-flow history from the multiple parties, and the intelligent contract system may suggest particular counter-proposals to particular parties based on the past transaction and deal-flow history for that particular land owner/buyer (e.g., past positive interactions with a certain buyer may prompt the intelligent contract system to suggest certain “discounted” terms for a counter-proposal in order to facilitate future positive interactions with that certain buyer).”; Paragraph 66, “Proposal generator module 715 may contain at least one predictive analytics or machine-learning (ML) engine that comprises at least one machine-learning model. The ML engine may be configured to receive user transaction/deal-flow history, other user profile data, comparable asset valuation data, current market data, future market indicator data, standard deal terms based on current deal characteristics, etc., to train at least one machine-learning model or compare against an already-trained machine-learning model. For example, to train the ML model(s), the extracted features of the input data may be associated with specific asset identifiers (e.g., geographic location, size, amenities, proximity to POIs, price, etc.). The ML engine may utilize various machine learning algorithms to train the ML model, including but not limited to linear regression, logistic regression, linear discriminant analysis, classification and regression trees, naïve Bayes, k-Nearest neighbors, learning vector quantization, neural networks, support vector machines (SVM), bagging and random forest, and/or boosting and AdaBoost, among other supervised and unsupervised machine learning algorithms. The aforementioned machine learning algorithms may also be applied when comparing input data to an already-trained machine learning model. Based on the identified and extracted features and patterns (e.g., related to individual negotiating parties, property locations, standard deal terms, etc.), the ML engine may select the appropriate machine learning algorithm to apply to the features to train the at least one machine learning model. For example, if the received input data are complex and demonstrate non-linear relationships, then the ML engine may select a bagging and random forest algorithm to train the machine learning model. However, if the received features demonstrate a linear relationship to certain features and input data (e.g., price per month of rent for a property location increases as distance to an international airport decreases), then the ML engine may apply a linear or logistic regression algorithm to train the machine learning model.”)
Chen in view of Fitzgerald do not explicitly disclose the following, however, in analogous art of bid organization and negotiation Kephart discloses the following:
…thereby automatically identifying a Pareto optimal solution or a Kalai-Smorodinsky Solution (KS solution) that is difficult to identify through conventional negotiation processes. (Kephart: Paragraph 167, “Optionally, the system provides representations that are displayed on the screens to illustrate the negotiation process, through charts, tables or any representation that not only help on the formation of the bid, but also help humans to learn the heuristic or strategies that are being used by the avatars throughout the interaction. Information with regard to the Pareto Frontier can also be included. For example, if there are three participants in the conversation, a three-dimensional plot of the Pareto Frontier can be updated on each interaction. For n>3 participants, techniques (such as projections) for representing n-dimensional data on a 2- or 3-dimensional plot can be used to represent the frontier.”)
Chen discloses a method for a automated negotiations for physical assets. Fitzgerald discloses a bid negotiation and management engine. Kephart discloses a method for an negotiation agent and platform. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Chen in view of Fitzgerald with the teachings of Kephart in order to optimize the learning models utilized in the negotiations and bids as disclosed by Kephart (Kephart: Paragraph 7, “Thus, current UIs for human-agent negotiation are typically limited to text-based systems and are not multi-lateral (that is, they do not support human-agent interactions involving multiple agents or multiple humans).”)
Claim(s) 12 –
Chen in view of Fitzgerald disclose the limitations of claim 1
Chen further discloses the following:
wherein the processor is further configured to execute the instructions to: process history information related to proposals within a specific domain such as financial transactions, supply chain optimization, or equipment lending scheduling (Chen: Paragraph 25, “Client devices 102, 104, and 106 may be configured to receive and transmit proposals and counter-proposals related to a negotiation. Additionally, client devices 102, 104, and 106 may be configured to receive outside data related to transaction histories, market data, financial trends, etc. to train at least one machine learning algorithm. The client devices 102, 104, and 106 may then receive intelligent deal-term suggestions based on the trained machine learning algorithm(s) related to the proposals/counter-proposals. In aspects, a client device, such as client devices 102, 104, and 106, may have access to one or more data sources and/or databases comprising third-party market data, asset information (e.g., comparable property valuations, most current lease rate, etc.), past deal-flow history of the other negotiating party (e.g., time to respond to new proposal, terms most likely to negotiate, terms most likely to not negotiate, etc.). In other aspects, client devices 102, 104, and 106, may be equipped to receive broadband and/or satellite signals carrying proposal/counter-proposal information to be displayed on a display device, such as a client devices 102, 104, and 106. The signals/information that client devices 102, 104, and 106 may receive may be transmitted from satellite 122. Satellite 122 may also be configured to communicate with network(s) 108, in addition to being able to communicate directly with client devices 102, 104, and 106. In some examples, a client device may be a mobile phone, a laptop computer, a tablet, a smart home device, a desk phone, and a wearable (e.g., smart watch), among other devices.”; Paragraph 33, “Once the request for proposal is submitted, the system captures the request and provides it to the other negotiating party. The request for proposal may be locked and cloned. The locked version of the request for proposal may not be edited but may be displayed for reference. The cloned version may be edited by the other negotiating party to create a proposal. Once the request for proposal is locked and cloned, the system may generate an intelligent scenario with proposal suggestions for the other negotiating party (Generate Proposal 218). For real estate leasing transactions, the suggestions may include but are not limited to rent, term duration, commencement date, and rent concessions (e.g., number of months of free rent). The intelligent suggestions provided to the other negotiating party at block 218 may be based on at least one machine learning or predictive analytics model that is trained on historical transaction and deal-flow data related to the requesting party, similarly situated property locations, and current and future market data. The party receiving the intelligent suggestions through the scenario generator may approve or reject the suggestions, in whole or in part. Some suggested terms may be approved, but some suggested terms may be rejected. The system may receive these approval and disapproval indications as the user reviews the intelligent contract suggestions. The system may also store these approval and rejection indications as historical data that may be used to further train the at least one machine learning or predictive analytics model.”)
Chen in view of Fitzgerald do not explicitly disclose the following, however, however, in analogous art of bid organization and negotiation Kephart discloses the following:
learn the determination method by performing learning in a simulated environment that considers a degree of conflict exceeding a predetermined threshold for the negotiation, thereby reducing cost associated with negotiation failures or optimizing processing time until agreement formation within the specified domain, as compared to conventional negotiation processes. (Kephart: Paragraph 195, “Beyond the realm of negotiation, there are additional scenarios in which interactions among humans and multiple agents are of interest, and can be enabled by embodiments of the invention. The prior art includes an educational scenario in which students practice the Mandarin Chinese language and culture through spoken role-play with embodied AI agents in an immersive environment. Initial studies of AI-assisted language education had shown that immersion has a beneficial impact. In the Mandarin education scenario, the agents play various roles, including shopkeepers who compete with each other for the student's business. One or more embodiments provide a platform that can be used as a basis for a new type of AI competition that blends aspects of agent-agent and human-agent interactions, and brings those interactions to life by situating them in an immersive environment. Embodiments can be used not only for competitions, but for-real world negotiation, education, training, and the like. One or more embodiments provide a platform that can be used to teach negotiation skills to students by simulating negotiation with one or more agents. The interactions also have the potential of letting users compare complex products/services in new ways.”; Paragraph 287, “In the test platform, the Chat UI stands in the place of the Competition Manager. It provides buttons that allow a human to launch a single negotiation round, and displays results when the round is over. One cannot use the Chat UI to simulate a competition; it only handles one round at a time. In its role as substitute Competition Manager, the Chat UI calls the Utility service to randomly generate utilities at the beginning of a round, and calls the Environment Orchestrator to launch a round.”; Paragraph 296, “Other approaches are possible; for example, using the chat UI to simulate another seller. Alternatively, simply run two seller agents.”; Paragraph 339, “In this example, the messages are the same, but the timing is slightly different, in that both agents try to respond to human utterances more-or-less simultaneously (to within a two-second tolerance). A1's response to H's first utterance is legal, as A1 was addressed. But A2 has also responded to H without waiting for A1. In this case, the system accepts A1's message and blocks A2's. After receiving the rejection notice, it would be legal for A2 to try again. A2 could send the same message as before, but it may want to take into account A1's message, a copy of which it will have received. For the second utterance of H, the roles are exactly reversed, and in this case A2's response is accepted while A1's is blocked. Again, it would be advisable for A1 to hold off, wait for A2 to respond, and then possibly take advantage of A2's offer.”)
Chen discloses a method for a automated negotiations for physical assets. Fitzgerald discloses a bid negotiation and management engine. Kephart discloses a method for an negotiation agent and platform. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Chen in view of Fitzgerald with the teachings of Kephart in order to optimize the learning models utilized in the negotiations and bids as disclosed by Kephart (Kephart: Paragraph 7, “Thus, current UIs for human-agent negotiation are typically limited to text-based systems and are not multi-lateral (that is, they do not support human-agent interactions involving multiple agents or multiple humans).”)
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen (US 2021/0390647 A1) in view of Fitzgerald (US 10,825,084 B1) and Francon (US 2020/0311556 A1)
Claim(s) 13 –
Chen in view of Fitzgerald disclose the limitations of claim 1
Chen in view of Fitzgerald do not explicitly disclose the following, however, in analogous art of market negotiations and decision making Francon discloses the following:
utilize a neural network using a Double Deep Q Network (DDQN) model comprising an input layer, multiple hidden layers, and an output layer, simultaneously outputting whether a proposal is accepted and the content of the proposal, given that the history information is vector- formatted data encoded by one-hot encoding for each item, thereby extracting abstract features necessary for advanced decision-making from complex behavior patterns of the negotiation counterpart and time-series changes of the negotiation and increasing its own utility value, as compared to conventional shallow neural network models. (Francon: Paragraph 39, “There is now significant historical data available on decision making in organizations, consisting of the decision problem, what decisions were made, and how desirable the outcomes were. Using this historical data, it is possible to learn a surrogate model, and with that model, evolve a decision strategy that optimizes the outcomes. The present embodiments introduce a general such approach, called Evolutionary Surrogate-Assisted Prescription, or ESP. The surrogate is, for example, a random forest or a neural network trained with gradient descent, and the strategy is a neural network that is evolved to maximize the predictions of the surrogate model. As discussed further below, ESP can be extended to sequential decision-making tasks, which makes it possible to evaluate the framework in reinforcement learning (RL) benchmarks. Because the majority of evaluations are done on the surrogate, ESP is more sample efficient, has lower variance, and lower regret than standard RL approaches. Surprisingly, ESP solutions are also better because both the surrogate and the strategy network regularize the decision making behavior. ESP thus introduces a foundation to decision optimization in real-world problems.”; Paragraph 43, “In ESP, two models are employed: a Predictor P.sub.d, and a Prescriptor P.sub.s. As shown in FIG. 2(a), the Predictor takes, as its input, context information (C), as well as actions (A) performed in that context, along with historical C, A, O data sets. The output of the Predictor is the resulting outcomes when the given actions are applied in the given context. The Predictor is therefore defined as”; Paragraph 70, “The Predictor's predicted reward for each state-action pair is shown using the background colors in each snapshot of ESP. The rapid convergence of the Predictor highlights the sample efficiency of ESP, due to aggressive use of historical data (shown as translucent circles). Note, however, that the Predictor does not converge to the ground truth over the entire domain; it does so just in the neighborhood of the optimal Prescriptor. Thus, ESP avoids excessive costly exploration of low-quality actions once the structure of optimal actions has become clear.”; Paragraph 76, “The first Predictor is trained on samples collected from five random agents playing five episodes each. Random agents choose a uniform random action at each time step. A sample corresponds to a time step in the game and comprises four observations, two actions, and the discounted future reward. Reward is +1 on each time step, except for the last one where it is adjusted to +2,000 in case of success, −2,000 in case of failure (i.e. 10× max time steps). The discount factor is set to 0.9. The reward value is then scaled to lie between −1 and 1.”; Paragraph 79, “In addition to DE and ESP, two state-of-the-art RL methods were implemented for comparison: double DQN with dueling network architectures and actor-critic style PPO. The implementation and parametric setup of DQN and PPO were based on OpenAI Baselines. For PPO, the policy's update frequency was set to 20, which was found to be optimal during hyperparameter search. All other parametric setups of DQN and PPO utilized default setups as recommended in OpenAI Baselines.”)
Chen discloses a method for a automated negotiations for physical assets. Fitzgerald discloses a bid negotiation and management engine. Francon discloses a method of optimizing prediction of suggested business actions using machine and AI models. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Chen in view of Fitzgerald with the teachings of Francon in order to optimize the decision making processes used in negotiations as disclosed by Francon (Francon: Paragraph 7, “Moreover, the solution is not a single point but a strategy, i.e. a function that maps input situations to optimal decisions, exacerbating the scale-up problem further.”)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Philip N Warner whose telephone number is (571)270-7407. The examiner can normally be reached Monday-Friday 7am-4:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jerry O’Connor can be reached at 571-272-6787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Philip N Warner/Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624