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 .
Notice to Applicant
The following is a first Non-Final Office Action to Application Serial Number: 19/559, 235, filed on March 06, 2026. In response to Examiner's Requirement for Restriction/Election notice dated July 23, 2026, Applicant on September 23, 2026 elected claims 8-14 in Group II without traverse. Claims 8-14 are pending in this application and have been rejected below.
Priority
The Examiner has noted this Application is a Continuation-In-Part (CIP) of Application No. 18/341.714 filed June 26, 2023 and Application No. 18/349,836 filed July 10, 2023.
Information Disclosure Statement (IDS)
The information disclosure statements (IDS) filed on July 06, 2026 and October 01, 2026 comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and are considered by the Examiner.
Claim Objections
Claim 8 is objected to because of the following informalities: grammatical error. Claim 8 should end with a period. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 11 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 11, the phrase "such as" renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 8-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: The claimed subject matter falls within the four statutory categories of patentable subject matter.
Claims 8-14 are directed towards a computerized method, which is among the statutory categories of invention.
Step 2A – Prong One: The claims recite an abstract idea.
Claims 8-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite dynamically adjusting pricing based on customer data.
Claim 8 recites limitations directed to an abstract idea based on certain methods of organizing human activity and mental processes. Specifically, generating, the current data and historical transaction data, a predicted pricing-response value indicative of at least one of willingness to pay or price sensitivity for a customer or customer segment; and computing a dynamically adjusted price based on the predicted pricing-response value and at least one of the inventory data or the market data constitutes methods based on commercial or legal interactions, as well as, methods based on evaluations, observation and judgement that can be performed by a combination of the human mind and a human using pen and paper. The recitation of a machine-learning module and dynamic pricing engine does not take the claim out of the certain methods of organizing human activity and mental processes groupings. Thus the claim recites an abstract idea.
Step 2A – Prong Two: The judicial exception is not integrated into a practical application.
The judicial exception is not integrated into a practical application. In particular, claim 8 recites monitoring, by a Real-Time Data Mesh (RTDM), a plurality of transactional systems including at least one Enterprise Resource Planning (ERP) system for data changes using a Change Data Capture (CDC) mechanism that captures updates, modifications, or new transactions; standardizing, by the RTDM, data captured by the CDC mechanism and maintaining the standardized data in a data layer comprising a data lake and a plurality of Purposive Datastores (PDSes) associated with the data lake, each PDS being a purpose-built repository configured to store and retrieve a respective type of data; performing, by a distributed computing framework of the data layer, parallel processing across data stored in the data lake and the plurality of PDSes to provide current customer transaction data and at least one of product pricing data, inventory data, or market data; and synchronizing, through an integration and synchronization layer, the dynamically adjusted price with at least one enterprise system comprising an ERP system, a customer relationship management system, or an inventory management system, which are limitations considered to be an insignificant extra-solution activity of collecting and delivering data; see MPEP 2106.05(g). Additionally, claim 8 recites RTDM, transactional systems including ERP systems using CDC mechanism, data layer comprising a data lake, PDSes, distributed computing framework of the data layer, parallel processing, dynamic pricing engine, and an integration and synchronization layer amounts to no more than generally linking the user of the judicial exception to a particular technological environment; see MPEP 2106.05(h) and uses generic computer components used tools to apply the instructions of the abstract idea; see MPEP 2106.05(f). Additionally, claim 8 recites using a machine-learning module for generating a predicted pricing-response value. The general use of a machine learning technique does not provide a meaningful limitation to transform the abstract idea into a practical application. Therefore, the machine-learning module disclosed in the claim are solely used as a tool to perform the instructions of the abstract idea. Thus, the additional elements do not integrate the abstract idea into practical application because they do not impose any meaningful limitations on practicing the abstract idea. Claim 8 as a whole, looking at the additional elements individually and in combination, does not integrate the judicial exception into a practical application and therefore is directed to an abstract idea.
Step 2B: The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional elements in the claims other than the abstract idea per se, including RTDM, transactional systems including ERP systems using CDC mechanism, data layer comprising a data lake, PDSes, distributed computing framework of the data layer, parallel processing, dynamic pricing engine, and an integration and synchronization layer amount to no more than a recitation of generic computer elements utilized to perform generic computer functions, such as receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); electronic recordkeeping, Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log) and storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; see MPEP 2106.05(d)(II). The machine learning techniques recited in the claim are disclosed at a high-level of generality (see at least Specification [0093]; [0154]; [0161]) and does not amount to significantly more than the abstract idea. Viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. Therefore, since there are no limitations in the claim that transform the abstract idea into a patent eligible application such that the claim amounts to significantly more than the abstract idea itself, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
§ 101 Analysis of the dependent claims.
Regarding the dependent claims, dependent claim 13 recites further comprising sending a notification to the user upon successful generation and availability of the dynamically adjusted price which is considered an insignificant extra-solution activities of collecting and delivering data; see MPEP 2106.05(g). Claim 9 recites utilizing machine learning algorithms in a feedback loop to analyze user feedback and system performance for continual optimization of the dynamic pricing process. The general use of a machine learning technique does not provide a meaningful limitation to transform the abstract idea into a practical application. Therefore, the machine-learning algorithm disclosed in the claim are solely used as a tool to perform the instructions of the abstract idea; MPEP 2106.05(f). Additionally, claims 10-12 and 14 recite steps that further narrow the abstract idea. Therefore claims 9-14 do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself.
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.
Claims 8, 9 and 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Makhija et al., U.S. Publication No. 2020/0279200 [hereinafter Makhija], and further in view of Subramanian et al., U.S. Publication No. 2019/0244230 [hereinafter Subramanian].
Referring to Claim 8, Makhija teaches:
A computerized method for dynamically adjusting pricing using real-time enterprise data, comprising:
monitoring, by a Real-Time Data Mesh (RTDM), a plurality of transactional systems including at least one Enterprise Resource Planning (ERP) system for data changes using a Change Data Capture (CDC) mechanism that captures updates, modifications, or new transactions (Makhija, [0035]-[0037]), “a self-driven system 100 for operating one or more applications including supply chain management (SCM) and enterprise resource planning (ERP) applications is provided in accordance with an embodiment of the present invention… The system 100 includes a data lake 108 for storing plurality of data from distinct sources, where the data includes, text data, voice data, image data, functional data, data models, scripts etc. to be processed based on Artificial intelligence and machine learning. The system 100 connecting various elements through a network 109…the self-driven system 100 of the present invention operates one or more applications that may include enterprise applications (EA) and/or supply chain management (SCM) applications… the enterprise applications include finance applications like automated billing applications and payment processing applications, Customer relationship management applications (CRM) and enterprise resource planning applications (ERP)”; (Makhija, [0042]), “…The support architecture further includes a control tower 117 for controlling a plurality of functions associated with the one or more applications wherein the control tower determines characteristic of at least one attribute of one or more of the plurality of received data wherein characteristic includes change in the at least one attribute or determination of the attribute as a new attribute… The control tower 117 also includes a sensing means 119 for sensing characteristics of a data received at a data lake. The sensing means 119 of the support architecture 107 triggers a re-calibration of the plurality of data models based on the sensed characteristics of the received data only in case of enhanced performance by the models…”; (Makhija, [0053]; [0055]; [0070]; [0080]; [0098]);
standardizing, by the RTDM, data captured by the CDC mechanism and maintaining the standardized data in a data layer comprising a data lake and a plurality of Purposive Datastores (PDSes) associated with the data lake, each PDS being a purpose-built repository configured to store and retrieve a respective type of data (Makhija, [0042]), “The support architecture 107 includes an AI engine 120 for determining relevant data models stored in a data model database 126 and created by a generation mechanism 120a for execution using the bot based on data sets received at the data lake 108. Further, the support architecture 107 includes a data cleansing and normalization engine 116 for receiving processed and cleansed data sets from the front-end server 106 to execute multiple functions of the one or more ERP and SCM application”; (Makhija, [0046]), “the data cleansing and normalization engine 116 is configured to clean data received at the data lake in real time using natural language processing and machine learning algorithms for enhanced accuracy. Since, the data will be received from multiple disconnected sources, the engine 116 has an ability to remove duplicates, standardize and group the data. The cleansing engine is coupled to a data mapper and curator engine”; (Makhija, [0093]), “… The method steps for operating on the one or more applications include S303, checking if new attributes are introduced to data lake, if yes then in S304 Cleansing/transformation of new attributes (remove outliers, normalization, impute missing, dimensionality reduction etc.)…”; (Makhija, [0062]), “The curator engine 132b with the help of mapper and ingestion module 132a stores the received data in multiple type stores viz, the search store for advance search, graph for data and relations, flat structure for logs purpose etc. The Curation including selection and organization of data takes place through capturing metadata and lineage and making it available in a data catalog…”; (Makhija, [0066]);
performing, by a distributed computing framework of the data layer, parallel processing across data stored in the data lake and the plurality of PDSes to provide current customer transaction data and at least one of product pricing data, inventory data, or market data (Makhija, [0042]), “The controller 113 is configured to determine and generate a processing logic for each function in real-time depending on the received data and processing cycle of that received data in the one or more application. For e.g., the processing logic may include serial or parallel processing of certain functions depending on the impact on the one or more applications. The system also includes a processor 114 configured to process various functions based on the AI based processing of data sets and data models by the bot. The support architecture 107 includes a data manager 115 for managing data relating to any function of the Enterprise application EA or SCM application… The support architecture 107 includes an AI engine 120 for determining relevant data models stored in a data model database 126 and created by a generation mechanism 120a for execution using the bot based on data sets received at the data lake 108.”; (Makhija, [0053]), “data lake/platform (100B, 100c) of AI based self-driven ERP and SCM system is shown in accordance with an embodiment of the present invention. The system 100a includes a plurality of distinct data source layer 127 to capture all customer, factory, supplier, machine and third-party sources of data (both structured and unstructured), the data lake layer 108 storing all data received from the distinct data source layer 127, an application function layer 128 configured to re-calibrate functions based on data models and scripts generated by a bot…”; (Makhija, [0069]; [0088]).
Makhija teaches a tool including an AI based prediction and recommendation engine coupled to a processor configured for processing at least one prediction algorithm to generate at least one recommendation option/task/action in real time (see par. 0057), but Makhija does not explicitly teach:
generating, by a machine-learning module from the current data and historical transaction data, a predicted pricing-response value indicative of at least one of willingness to pay or price sensitivity for a customer or customer segment;
computing, by a dynamic pricing engine, a dynamically adjusted price based on the predicted pricing-response value and at least one of the inventory data or the market data;
synchronizing, through an integration and synchronization layer, the dynamically adjusted price with at least one enterprise system comprising an ERP system, a customer relationship management system, or an inventory management system;
However Subramanian teaches:
generating, by a machine-learning module from the current data and historical transaction data, a predicted pricing-response value indicative of at least one of willingness to pay or price sensitivity for a customer or customer segment (Subramanian, [0023]), “Based on historical and learned data, factors such as “willingness to pay” and total expected number of future customers are also incorporated in its methodology. As inventory becomes more constrained, the innovation differentiates and reprices the VOI accordingly. After each request and offer, there are two updates that can occur, first a longer-term update for future historical data mining (e.g., data such as “willingness to pay”, cost, preference, etc.) and the second update which is instantaneous and updates the VOI and the price. An example of this method would be after a customer accepts or declines a certain price offer, the methodology can reprice the VOI and the following customer would be submitted a different price”; (Subramanian, [0027]-[0028]), “Functions such as calculating risk of existing pricing trade-offs, updating the VOI and pricing in real time after customer feedback along with conducting parallel searches to capture customer mix data. Various sampling methods such as Thompson sampling can also be implemented by either 108 or 110. The recommendation component 110 can compile historical customer data and process updated customer profile data to develop a “most likely stack” or a historical database carved up into multiple categories. The VOI component 108 can pre-calculate prices and value of inventory in real time to offer a customer most revenue friendly options… Any suitable predictive model can be employed such as for example: a logistical regression model; a Bayesian network; a neural network; hidden Markov model (HMM); or a support vector machine (SVM). Customer history can include at least one of the following… willingness to pay, and other significant factors that can be utilized in the calculations…”; (Subramanian, [0037]);
computing, by a dynamic pricing engine, a dynamically adjusted price based on the predicted pricing-response value and at least one of the inventory data or the market data (Subramanian, [0062]), “The look ahead pricing and VOI optimizer 910 interacts bi-directionally with module 908 which can run multiple threads of pricing algorithms Modules 908 and 910 can be primary software drivers behind developing and managing the price stack. Module 912 can be a primary interface from a customer historical profile data to an optimizer module 910 where the software takes into account customer patterns in the process of developing the price stack. Modules 914 and 918 are data storage repositories that are sent relevant customer data from various customer feedback channels 920 and a message hub 916. This data which can contain vital data such as customer profiles, historical preferences and willingness to pay is married into the pricing and VOI optimizer to account for all possible factors when generating a final price output”; (Subramanian, [0027]), “Functions such as calculating risk of existing pricing trade-offs, updating the VOI and pricing in real time after customer feedback along with conducting parallel searches to capture customer mix data. Various sampling methods such as Thompson sampling can also be implemented by either 108 or 110. The recommendation component 110 can compile historical customer data and process updated customer profile data to develop a “most likely stack” or a historical database carved up into multiple categories. The VOI component 108 can pre-calculate prices and value of inventory in real time to offer a customer most revenue friendly options”; (Subramanian, [0028]; [0063]); and
synchronizing, through an integration and synchronization layer, the dynamically adjusted price with at least one enterprise system comprising an ERP system, a customer relationship management system, or an inventory management system (Subramanian, [0024]), “The innovation is consistently updating prices to remain compatible with the inventory so the prices and remaining inventory stay in sync. The innovation can also cross check risks based on filling in seats against possibly leaving empty seats and losing potential revenue. Such distributed network infrastructure enables a pricing system to rapidly re-sync personalized prices and VOI over lifetime of a significant number of products concurrently offered to a high volume of customers”; (Subramanian, [0023]), “After each request and offer, there are two updates that can occur, first a longer-term update for future historical data mining (e.g., data such as “willingness to pay”, cost, preference, etc.) and the second update which is instantaneous and updates the VOI and the price”; (Subramanian, [0061]), “The initial customer request 802 is piped into a pricing API (application programming interface) 804 where there may be some re-formatting and then the data sent to the master processing module 806. As the core mathematics and complex programming is conducted in 806, additional external or historical data 808 is also supplied to 806 to further optimize pricing calculations. The result is a top priority pricing stack 810 which will contain the most likely options to resend to the customer as response 812. The stack is always updated after each transaction as to minimize additional computations for each request”; (Subramanian, [0063]), “price stack 1010 is what provides data to the recommendation module and itself is provided the updated stack data from the look ahead pricing and VOI optimization module 1014. The multiple parallel threads performing many calculations are depicted in 1016, 1018, 1020, and 1022, referred to as pricing modules. Item 1024 depicts the mathematical flow and equations each one of the pricing module can process. The historical customer profiles are captured using the application 1004 and the customer response data 1006 and the data is stored in the inventory update 1008. The storage of this data would correspond to the storage repositories depicted in FIG. 9. As implied in FIG. 9, this storage data will be piped into the optimizer 1014 to update the price stack”; (Subramanian, [0027]);
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the recommendations generated by a tool including an AI based prediction and recommendation engine in Makhija to include the dynamic pricing limitations as taught by Subramanian. The motivation for doing this would have been to improve the method of improving supply chain management (SCM) and ERP systems that self-evolve and self-drive the functions with real-time identification and resolution capabilities in Makhija (see par. 0007) to efficiently include the results of real time personalized pricing (see Subramanian par. 0001).
Referring to Claim 9, Makhija in view of Subramanian teaches the method of claim 8. Makhija teaches reprocessing the functions of the one or more applications based on the plurality of data models and script by receiving the recalibrated function processed by the SQL server and applying the AI based dynamic processing logic to the data models and functions using the bot (see par. 0088), but Makhija does not explicitly teach:
further comprising utilizing machine learning algorithms in a feedback loop to analyze user feedback and system performance for continual optimization of the dynamic pricing process.
However Subramanian teaches:
further comprising utilizing machine learning algorithms in a feedback loop to analyze user feedback and system performance for continual optimization of the dynamic pricing process (Subramanian, [0038]-[0039]), “FIG. 6 illustrates a basic data process flow for the method processing. The initial customer request (602) starts the transactional process, and the request is sent into a master data processing block (604) where distributed data and the processing pricing component that comprises multiple data and processing nodes, store copies of latest persona and time-period level data, wherein respective nodes receive tentative VOI signals, compute optimal prices in real-time, and transmit the results back to a master processor, within a response clock time limit. Also as time based feedback into this process, the system learns customer persona types and respective product choice preferences (606) using historical booking and inputs this data back into the distributed optimization processing block (604). The processing block (604) also factors in making a correct pricing decision against cost of making an incorrect pricing decision… This large scale discrete optimization problem also takes into account a future customer persona mix arrival pattern as well as expected number of bookings, both of which are calculated using a Machine-Learning module, e.g., percentage of premium, mid-tier, and economy customer personas for future time periods. This prediction is periodically updated by re-acquiring latest purchase and customer attribute data from the database as shown in outer-loop on the right side of FIG. 6)”; (Subramanian, [0040]; [0061]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the recommendations generated by a tool including an AI based prediction and recommendation engine in Makhija to include the dynamic pricing limitations as taught by Subramanian. The motivation for doing this would have been to improve the method of improving supply chain management (SCM) and ERP systems that self-evolve and self-drive the functions with real-time identification and resolution capabilities in Makhija (see par. 0007) to efficiently include the results of real time personalized pricing (see Subramanian par. 0001).
Referring to Claim 11, Makhija in view of Subramanian teaches the method of claim 8. Makhija teaches a collaborative platform is configured to maximize profits and margins as an accurate demand and commodity prices data is available in real-time for improved decision making based on the recommended tasks (Makhija, [0075]), but Makhija does not explicitly teach:
further comprising generating real-time reports related to the dynamic pricing process, including metrics such as user satisfaction and pricing customization level.
However Subramanian teaches:
further comprising generating real-time reports related to the dynamic pricing process, including metrics such as user satisfaction and pricing customization level (Subramanian , Fig. 3-Fig. 4, [0035]-[0036]), “FIG. 3 illustrates a 7 day in advance booking attribute diagram. Notice that on 302, the price profile is a Tier-2 business customer (e.g., a medium level typical customer requiring a flight but willing to pursue the best fare he/she can) who's willingness to pay factor is about in the middle. As the graph in green reflects, the higher the price the less chance the customer can pay. The menu of availability 304 displays the various seats within the same cabin and has a certain price distribution based on preference. The price at this point has been modified based on time and VOL Notice that in 304 that the typical window seat in a regular row has move from S25 to S28 as the total number of seats available has been reduced (the red unavailable seats have been increased). The window seat with extra leg space is now S37 for a similar adjustment. The method has considered the decreased inventory, time to departure and likely other factors such as customer mix, customer history, etc. from its historical tracking. As 306 indicates, the VOI has started to influence pricing as seats of various types become occupied. This is a novel concept for this invention… FIG. 4 illustrates a 1 day in advance booking attribute diagram. Notice that on 402, the price profile is a Tier-1 business customer (e.g., a higher level typical businessman requiring a flight and willing to pursue the best seat he/she can get) who's willingness to pay factor is high. The menu of availability 404 displays the various seats within the same cabin and has a certain price distribution based on preference. The price at this point has been modified based on time and VOL Notice that in 404 that the typical window seat in a regular row has move from S25 to S30 now as the total number of seats available has been reduced again. It's important to note the method has still preserved a premium seat 406 (e.g., as shown S40 seat in brown) The method has considered the decreased inventory, time to departure and the concept of saving premium seats for an optimum window where the system predicts the premium customer is likely to purchase”.
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the collaborative platform in Makhija to include the display limitations as taught by Subramanian. The motivation for doing this would have been to improve the method of improving supply chain management (SCM) and ERP systems that self-evolve and self-drive the functions with real-time identification and resolution capabilities in Makhija (see par. 0007) to efficiently include the results of real time personalized pricing (see Subramanian par. 0001).
Referring to Claim 12, Makhija in view of Subramanian teaches the method of claim 8. Makhija teaches a collaborative platform is configured to maximize profits and margins as an accurate demand and commodity prices data is available in real-time for improved decision making based on the recommended tasks (Makhija, [0075]), but Makhija does not explicitly teach:
wherein pricing adjustments are made based on predefined criteria including user preferences, market trends, and inventory levels.
However Subramanian teaches:
wherein pricing adjustments are made based on predefined criteria including user preferences, market trends, and inventory levels (Subramanian, [0023]), “The innovation can use time as a key variable for its calculations. As the time to departure decreases, the innovation recognizes type of customer expected throughout a remaining period. This predictability combined with remaining VOI is used to calculate subsequent price offers. Based on historical and learned data, factors such as “willingness to pay” and total expected number of future customers are also incorporated in its methodology. As inventory becomes more constrained, the innovation differentiates and reprices the VOI accordingly. After each request and offer, there are two updates that can occur, first a longer-term update for future historical data mining (e.g., data such as “willingness to pay”, cost, preference, etc.) and the second update which is instantaneous and updates the VOI and the price. An example of this method would be after a customer accepts or declines a certain price offer, the methodology can reprice the VOI and the following customer would be submitted a different price”; (Subramanian, [0032]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the collaborative platform in Makhija to include the criteria limitations as taught by Subramanian. The motivation for doing this would have been to improve the method of improving supply chain management (SCM) and ERP systems that self-evolve and self-drive the functions with real-time identification and resolution capabilities in Makhija (see par. 0007) to efficiently include the results of real time personalized pricing (see Subramanian par. 0001).
Referring to Claim 13, Makhija in view of Subramanian teaches the method of claim 8. Makhija teaches a tool is configured to attach the recommended task/action to a desired workflow or User interface element (see par. 0058), but Makhija does not explicitly teach:
further comprising sending a notification to the user upon successful generation and availability of the dynamically adjusted price.
However Subramanian teaches:
further comprising sending a notification to the user upon successful generation and availability of the dynamically adjusted price (Subramanian, [0062]), “FIG. 9 illustrates an embodiment that starts with customer pricing channels 902 as an initial input point. This drawing can be used in conjunction with FIGS. 6 & 8. Node 904 is a pricing API module which can be an input and output interface to a customer… VOI optimizer to account for all possible factors when generating a final price output”; (Subramanian, [0027]; [0059]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the collaborative platform in Makhija to include the criteria limitations as taught by Subramanian. The motivation for doing this would have been to improve the method of improving supply chain management (SCM) and ERP systems that self-evolve and self-drive the functions with real-time identification and resolution capabilities in Makhija (see par. 0007) to efficiently include the results of optimal prices corresponding to the subproblem solution for the current time period (see Subramanian par. 0052).
Referring to Claim 14, Makhija in view of Subramanian teaches the method of claim 9. Makhija teaches reprocessing the functions of the one or more applications based on the plurality of data models and script by receiving the recalibrated function processed by the SQL server and applying the AI based dynamic processing logic to the data models and functions using the bot (see par. 0088), but Makhija does not explicitly teach:
wherein the feedback loop for dynamic pricing decisions is conducted within a defined timeframe based on user engagement and system analytics.
However Subramanian teaches:
wherein the feedback loop for dynamic pricing decisions is conducted within a defined timeframe based on user engagement and system analytics (Subramanian, [0038]-[0039]), “FIG. 6 illustrates a basic data process flow for the method processing. The initial customer request (602) starts the transactional process, and the request is sent into a master data processing block (604) where distributed data and the processing pricing component that comprises multiple data and processing nodes, store copies of latest persona and time-period level data, wherein respective nodes receive tentative VOI signals, compute optimal prices in real-time, and transmit the results back to a master processor, within a response clock time limit. Also as time based feedback into this process, the system learns customer persona types and respective product choice preferences (606) using historical booking and inputs this data back into the distributed optimization processing block (604). The processing block (604) also factors in making a correct pricing decision against cost of making an incorrect pricing decision… This large scale discrete optimization problem also takes into account a future customer persona mix arrival pattern as well as expected number of bookings, both of which are calculated using a Machine-Learning module, e.g., percentage of premium, mid-tier, and economy customer personas for future time periods. This prediction is periodically updated by re-acquiring latest purchase and customer attribute data from the database as shown in outer-loop on the right side of FIG. 6)”; (Subramanian, [0040]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the recommendations generated by a tool including an AI based prediction and recommendation engine in Makhija to include the dynamic pricing limitations as taught by Subramanian. The motivation for doing this would have been to improve the method of improving supply chain management (SCM) and ERP systems that self-evolve and self-drive the functions with real-time identification and resolution capabilities in Makhija (see par. 0007) to efficiently include the results of real time personalized pricing (see Subramanian par. 0001).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Makhija et al., U.S. Publication No. 2020/0279200 [hereinafter Makhija], in view of Subramanian et al., U.S. Publication No. 2019/0244230 [hereinafter Subramanian], and further in view of Shpanya et al., U.S. Publication No. 2017/0109767 [hereinafter Shpanya].
Referring to Claim 10, Makhija in view of Subramanian teaches the method of claim 8. Makhija teaches collects data from diverse sources (Makhija, [0062]), but Makhija does not explicitly teach:
wherein the RTDM fetches real-time data based on current market conditions, customer behavior, and inventory availability.
However Shpanya teaches:
wherein the RTDM fetches real-time data based on current market conditions, customer behavior, and inventory availability (Shpanya, [0072]), “Data gathering is performed with reference to competitor pricing data and also a seller's sales data. The data may be gathered from and processed in the Cloud. Competitive data may be captured through scraping, and a seller's sales data may be imported from or synced from a seller's existing ecommerce platform. An input/output processor may be configured to acquire data on corresponding products and may also be used to identify possible competitors and the competitors' sales characteristics. Non-limiting examples of the competitors' sales characteristics may include competitor pricing, sales performance, conversion rates, the number of available products for sale and traffic”; (Shpanya, [0048]; [0053]; [0056]-[0057]; [0073]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the collected data in Makhija to include the data limitations as taught by Shpanya. The motivation for doing this would have been to improve the method of improving supply chain management (SCM) and ERP systems that self-evolve and self-drive the functions with real-time identification and resolution capabilities in Makhija (see par. 0007) to efficiently include the results of using variables to determine pricing (see Shpanya par. 0051).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Eglen et al. (US 20050139661 A1) – A system for dynamically pricing products available from one or more merchants. The system sends a first price for a product from a processor to a customer device, and receives a report of sale for the product at the first price from a merchant computer. The system then determines a second price for the product based at least on the report of sale for the product at the first price, and sends the second price to the client customer device.
Wise (US 20080275792 A1) – A web-based system and method of distributing products which are produced at a location remote from the seller. The system includes an administrator who creates a website having workrooms for each member of the organization. Each member of the system is a seller and producer of a product. Templates are provided in the workroom to permit the members to upload inventory and pricing information. Members will also be permitted to enter markup pricing for transactions where they are acting as sellers. A search engine permits sellers to search the inventory of producers by geographic and other protocol. The inventory along with pricing information which includes both the producer's cost and the seller's markup is displayed at the seller's terminal. The system also includes provisions for affiliates to purchase products form producers either for resale or on a volume discount.
Ashok et al. (Price Minds: AI-Driven Insights, Recommendations and Dynamic Pricing) – This research aims to enhance e-commerce systems by leveraging customer behavior analysis, dynamic pricing, and personalized recommendations. With the increasing demand for tailored shopping experiences and competitive pricing, businesses require adaptive solutions. The study integrates synthetic and real-time customer data to identify purchasing patterns and segment customers effectively. Dynamic pricing strategies are applied to optimize revenue while maintaining customer satisfaction. A unified framework combines clustering techniques, real-time data streams, and decision-making models to deliver actionable insights for business operations. The proposed system dynamically adjusts pricing and recommends products based on individual customer preferences and behavior. The approach addresses the growing need for intelligent systems that adapt to market trends and consumer demands. Results demonstrate improved operational efficiency, better customer engagement, and enhanced profitability. This work highlights the importance of real-time analytics and intelligent pricing mechanisms in advancing e-commerce and creating competitive advantages in rapidly evolving markets.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Crystol Stewart whose telephone number is (571)272-1691. The examiner can normally be reached 9:00am-5: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, Patty Munson can be reached at (571)270-5396. 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.
/CRYSTOL STEWART/Primary Examiner, Art Unit 3624
