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 .
This action is in response to the amendment filed on 01/26/2026. Claims 1-19 and 21 are pending in this application. This action is Final.
Applicant Response
3. In Applicant’s response dated 01/26/2026, Applicant amended Claims 1, 10, and 19, and argued against all objections and rejections previously set forth in the Office action dated 09/25/2025.
Examiner Comments
5. 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 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.
Claim Rejections - 35 USC § 103
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 1-7, 9-16, 18-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Ding (US 20150309840 A1, published on 2015-10-29) in view of Achin (Pub. No.: US 20180060744 A1, Pub. Date: 2018-03-01.) in further view of Singh (NPL: Title: Analytical Modeling for What-if Analysis in Complex Cloud Computing Applications, Pub. Date: March 2013)
Regarding independent Claim 1,
Ding teaches a method comprising:
receiving a request to perform a what-if simulation for one or more performance metrics of a system (see Ding: Fig.5A, [0061], “What-if module 530 receives information as its input 502 similar to that received by predictive module 520, and what-if module 530 applies historical trending and predictive analysis to that information.” … see also Fig.5A, [0058], “predictive module 520 receives various types of information as its input 502 such as an operational profile characterizing server utilization, actual workloads, actual service levels, and time-related information.”), wherein the request includes at least one scenario parameter that identifies a first change to a first demand on a first system resource of a plurality of system resources (see Ding Fig.5A, [0062], “what-if module 530 accepts as user input a list of workload scenarios and desired service levels. The input may indicate (i.e., identifies) for example, that a response time of 1 second is expected at 100 transactions per second and that a response time of 2 seconds is expected at 1000 transactions per second. After analyzing the characteristics of the application, what-if module 530 runs a series of what-if scenarios to discover the desired number of resources, (i.e., change in response time is identified as the demand of transaction (i.e. one scenario parameter) increased or decreased and response time is an example of first demand on the plurality of resources (servers)).;
responsive to receiving the request to perform the what-if simulation see (see Ding: [0061, What-if module 530 receives information to perform simulation)
(a) selecting from among plurality of demand propagation models a set of demand propagation models based on which of the plurality of demand propagation models have been trained from data representing the first demand (see Deng: Fig.5A, [0055], “a capacity module 510, a predictive module 520, and a what-if module 530 (plurality of demand propagation models), although other implementations may have only one such module or any combination thereof. Policy generating module 500 receives input 502 and generates one or more policies 504 for provisioning computer system. As mentioned previously, the policies 504 can be characterized as a collection of rules to be looked up by provisioning tool (160) when making provisioning decisions or can be characterized as provisioning decisions or commands sent to provisioning tool (160) to act on directly); and
(b) generating, by the set of demand propagation models as a function of the first change to the first demand to perform the what-if simulation, a plurality of predictions including a first prediction by a first demand propagation model of a second change to a second demand on at least one of the plurality of system resources (see Ding: Fig.5A, [0061], “What-if module 530 (a first model) receives information as its input 502 similar to that received by predictive module 520, and what-if module 530 applies historical trending and predictive analysis to that information. … [0062], see for example explaining a first change to a first demand “in a scenario for 100 transactions per second, the module 530 may predict what would be the response time if 2 servers, 4 servers, 8 servers, 10 servers, and 20 servers were used.”, i.e. the What-if simulation model performs the effect of increasing the Sever capacity (first demand) and predict the to the transaction time (first change)), and a second prediction by a second demand propagation model of a third change to a third demand on at least one of the plurality of system resources (see Ding: Fig.6, [0072], “migrating module 600 produces output data 680 that includes the performance rating type, the performance rating (P), the maximum normalized utilization total (MNUT), and the number (n) of required servers with performance rating P. This output 680 can then be used by the provisioning tool (160) to migrate the various servers (112) among the virtual partitions.”), wherein the set of demand propagation models generate predictions based on learned patterns on how changes to the first demand affect other demands (see Ding: Fig.6, [0072], “migrating module 600 produces output data 680 that includes the performance rating type, the performance rating (P), the maximum normalized utilization total (MNUT), and the number (n) of required servers with performance rating P. This output 680 can then be used by the provisioning tool (160) to migrate the various servers (112) among the virtual partitions.”), wherein the second demand is different than the first demand (see Ding: Fig.5A, [0063], “determined information is used to generate a policy 534 that can state a predicate, such as “if transaction rate is 100 transactions per second for application having stated characteristics is encountered, then provision x servers with y processing power.”, i.e. the second demand (increase in power allocation) is different form the first demand
(increase in the number of servers to process transaction) and the server and the power are different system resource.)
Ding does not teach the method wherein:
receiving, as input to machine learning model that predicts the one or more performance metrics based on how the first demand is predicted to propagate to the one or more other demands, the at least (a) one scenario parameter that identifies the first change to the first demand, (b)the second change to the second demand predicted by the first demand propagation model, and (c) the third change to the third demand predicted by the second demand propagation model; and
generating, by the machine learning model, a third prediction of a performance values for the one or more performance metrics of the system, wherein the machine learning model generates the third prediction as a function of at least (a) one scenario parameter that identifies the first change to the first demand, (b)the second change to the second demand predicted by the first demand propagation model, and (c) the third change to the third demand predicted by the second demand propagation model.
However, Achin teaches the method wherein:
receiving, as input to machine learning model that predicts the one or more performance metrics based on how the first demand is predicted to propagate to the one or more other demands (see Achin: Fig.9, [0376], “In step 970, a predictive model is fitted to the training data. In step 980, the fitted model is tested on the testing data. Cross-validation (including but not limited to nested cross-validation) and holdout techniques may be used for fitting and/or testing the predictive model. For purposes of cross-validation, the time-series data may be partitioned cross-sectionally and/or temporally.”), the at least (a) one scenario parameter that identifies the first change to the first demand, (b)the second change to the second demand predicted by the first demand propagation model (see Achin: Fig.11B, [0423], “method 1120 for performing a second-order predictive modeling (a second model) procedure may include steps 1122, 1124, 1126, and 1128. In step 1122, second-order input data are generated. The second-order input data include a plurality of second-order observations. Each second-order observation includes observed values of one or more second input variables (values of first change to the first demand) and values of the output variables predicted by the first-order model based on values of the first input variables corresponding to the values of the second input variables (the second change to the second demand predicted in the first prediction by the first model), and (c) the third change to the third demand predicted by the second demand propagation model (see Achin: Fig.11B, [0423], “Generating the second-order input data may include, for each second-order observation: obtaining the observed values of the second input variables and corresponding observed values of the first input variables, and applying the first-order predictive model to the corresponding observed values of the first input variables to generate the predicted values of the output variables.”)
Because both Ding and Achin are in the same/similar field of endeavor predictive data analytics, accordingly, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Ding to include the system, that generate a second model by receiving, as input to a second model, at least the first change to the first demand identified by the first request and the second change to the second demand predicted in the first prediction by the first model as taught by Achin. After modification of Ding, the policy generating module receives input and generates one or more prediction provisioning computer system resources, can also generate additional propagation module on system resources as taught by Achin. One would have been motivated to make such a combination in order to provide computer system resource users to improve their operations or aid their decision-making process by providing efficient, accurate and time-saving prediction model make changes rapidly and accurately, as well as propagate such enhancements to other developers and users. (see Achin: [0004])
Ding and Achin does not teach or disclose the system wherein:
generating, by the machine learning model, a third prediction of a performance values for the one or more performance metrics of the system, wherein the machine learning model generates the third prediction as a function of at least (a) one scenario parameter that identifies the first change to the first demand, (b)the second change to the second demand predicted by the first demand propagation model, and (c) the third change to the third demand predicted by the second demand propagation model.
However, Singh teaches the system wherein:
generating, by the machine learning model, a third prediction of a performance values for the one or more performance metrics of the system (see Singh: Fig.5, Section 5.2, Pg.58, “The modeling engine retrieves data about the workload on the incoming and outgoing edges of the node and the total resource utilization of the node and then invokes an R module for building the node-level models. The R module uses the MARS function present in the MDA package to build piecewise linear node-level workload models and the linear regression function to find the per-class service rates using least squares regression. Next, the what-if analysis engine uses these models to answer (“execute”) the query via the change propagation algorithm to propagate the hypothetical workload change through the model and compute its impact on the nodes of interest to the user” ), wherein the machine learning model generates the third prediction as a function of at least (a) one scenario parameter that identifies the first change to the first demand, (b)the second change to the second demand predicted by the first demand propagation model, and (c) the third change to the third demand predicted by the second demand propagation model (see Singh: Fig.4, Section 4.2, Pg. 58 “The algorithm proceeds in a breadth first fashion through the influence graph, starting with the “if” nodes/edges and computing the outgoing workload for each of the “if” nodes. The outgoing workload of a node becomes the incoming workload for downstream node(s), and the change propagation process repeats, one node at a time, in a breadth-first fashion, until the change has propagated to all of the “what” nodes/edges. At this point, the algorithm computes the value of interest at the node by using the node-level models and terminates.”)
Examiner notes that Ding disclosed a machine learning model for workload to performance prediction with a cross resource correlation and performance metrics.
Because Ding, Achin and Singh are in the same/similar field of endeavor predictive data analytics, accordingly, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Ding to include the system, that predicts how changes in the first demand on the first system resource propagate to one or more other demands to one or more other system resources and that predicts the one or more performance metrics based on how the first demand is predicted to propagate to the one or more other demands as taught by Singh. One would have been motivated to make such a combination in order to provide computer system resource users to improve their operations or aid their decision-making process by providing efficient, accurate and time-saving prediction model make changes rapidly and accurately, as well as propagate such enhancements to other developers and users.
Regarding Claim 2,
As shown above, Ding, Achin and Singh teaches all the limitations of claim 1. Ding further teaches the method wherein:
the first change is a change to at least one historical value that corresponds to a measurement of the first demand on the first system resource of the plurality of system resources (see Ding: Fig.3, [0024], “analysis of the historical performance data is used to identify resource usage patterns for (near future) resource provisioning and allocation. Furthermore, the analysis can be used to generate provisioning policies 304 as a developed set of rules or the like to implement desired outcomes based on predictive analysis and what-if scenarios. The policies 304 can then be used to provision the computer system's resources in terms of what, how, and when available servers 112 and/or other resources are needed to support applications 114 associated with the various SLOs 102.”)
Regarding Claim 3,
As shown above, Ding, Achin and Singh teaches all the limitations of claim 1. Ding further teaches the method wherein generating the third prediction of the one or more performance metrics of the system (see Ding: Fig.6, [0072], “migrating module 600 produces output data 680 that includes the performance rating type, the performance rating (P), the maximum normalized utilization total (MNUT), and the number (n) of required servers with performance rating P. This output 680 can then be used by the provisioning tool (160) to migrate the various servers (112) among the virtual partitions.”), comprises:
predicting a change to at least one historical value that corresponds to a measurement of the one or more performance metrics of the system (see Ding: Fig.2B, [0031], “As schematically shown by a graph, performance data 250 collected and stored in data repository (180) can include historical as well as real-time CPU utilization data for each of the various servers (112) of the computer system (100) and may have been collected for weeks or months from computer system (100). As discussed previously, recommendation tool (300) analyzes this performance data 250 and generates an operational profile. In embodiments discussed previously, the operational profile can characterize service levels in computer system (100) in a certain configuration and having a certain capacity, such as response times of servers when subjected to given workloads or the ability of severs to process given workloads or throughputs.”)
Regarding Claim 4,
As shown above, Ding, Achin and Singh teaches all the limitations of claim 1. Ding further teaches the method wherein the third prediction of the one or more performance metrics of the system (see Ding: Fig.6, [0072], “migrating module 600 produces output data 680 that includes the performance rating type, the performance rating (P), the maximum normalized utilization total (MNUT), and the number (n) of required servers with performance rating P. This output 680 can then be used by the provisioning tool (160) to migrate the various servers (112) among the virtual partitions.”), comprises:
a change to at least one future value that corresponds to a forecast of the one or more performance metrics of the system (see Ding: Fig.3, [0024], “analysis of the historical performance data is used to identify resource usage patterns for (near future) resource provisioning and allocation. Furthermore, the analysis can be used to generate provisioning policies 304 as a developed set of rules or the like to implement desired outcomes based on predictive analysis and what-if scenarios. The policies 304 can then be used to provision the computer system's resources in terms of what, how, and when available servers 112 and/or other resources are needed to support applications 114 associated with the various SLOs 102.”)
Regarding Claim 5,
As shown above, Ding, Achin and Singh teaches all the limitations of claim 1. Ding further teaches the method wherein the third prediction of the one or more performance metrics of the system (see Ding: Fig.6, [0072], “migrating module 600 produces output data 680 that includes the performance rating type, the performance rating (P), the maximum normalized utilization total (MNUT), and the number (n) of required servers with performance rating P. This output 680 can then be used by the provisioning tool (160) to migrate the various servers (112) among the virtual partitions.”), comprises:
a change to an uncertainty interval in a forecast of the one or more performance metrics of the system (see Ding: Fig5A, [0058], “predictive module 520 applies historical trending and predictive analysis to the input information and generates policies 524 that can then match current/past application performance based on predicted resource requirements. Therefore, predictive module 520 can use a form of curve matching analysis based on forecasted demand (i.e., expected workload). In other words, predictive module 520 can predict that at a given time a given number of x more servers may be needed, where this prediction is partly based on what workload the system may be required to handle at that time or based on the expected utilization at the time.”), wherein the predicted change to the uncertainty interval includes at least one of an upper limit or a lower limit of the uncertainty interval (see Ding: Fig. 2A, [0024], “The process 200 can also monitor and modify its performance as it continues. In this way, the process 200 can update policies 304 and validate SLOs 102 on a continuous basis. If the probability of meeting a given SLO 102 is below a certain level, for example, a policy 304 generated at Block 220 may need to be updated using more recently collected performance data from data repository 180.”)
Regarding Claim 6,
As shown above, Ding, Achin and Singh, teaches all the limitations of claim 1. Ding further teaches the method further comprising:
presenting a historical or forecast simulation based on at least the third prediction of the one or more performance metrics of the system (see Ding: Fig.5A, [0058], “Predictive module 520 applies historical trending and predictive analysis to the input information and generates policies 524 that can then match current/past application performance based on predicted resource requirements. Therefore, predictive module 520 can use a form of curve matching analysis based on forecasted demand (i.e., expected workload). In other words, predictive module 520 can predict that at a given time a given number of x more servers may be needed, where this prediction is partly based on what workload the system may be required to handle at that time or based on the expected utilization at the time.”)
Regarding Claim 7,
As shown above, Ding, Achin and Singh teaches all the limitations of claim 1. Ding further teaches the method wherein:
at least one of the first prediction or the second prediction is generated based on one or more seasonal patterns (see Ding: Fig.2, [0032] “This resource usage profile 260 captures workload-oriented information related to resource usage and history of computer system (100) that can be used in its capacity management. In this example, resource usage profile 260 encompasses a one-week interval (7 days×24 hours) with data points for each hour so that the profile 260 has 168 data points. Alternatively, resource usage profile 260 can encompass one or more one-week intervals, two-week intervals, monthly intervals, particular business seasons, or any other desirable time periods.”)
Regarding Claim 9,
As shown above, Ding, Achin and Singh teaches all the limitations of claim 1. Ding further teaches the method further comprising:
configuring one or more system resources based on a result of the what-if simulation (see Ding: Fig.5A, [0057], “predictive module 520 and what-if module 530 generate policies based on a combination of information pertaining to resources, workloads, service levels, and time. For example, the time information can be any given time interval, the workload information can be an average arrival rate of x transactions or jobs, the resource information can be the number of allocated servers, and the service level information can be average response times or throughput. What-if module 530 can further produce different combinations of workloads and resources to determine what the resulting performance would be in each of the different combinations and whether the system will be saturated or not”)
Regarding independent Claims 10,
Claim 10 is directed to a non-transitory computer-readable media claim and Claim 19 is directed to a system claim and both claims have similar/same claim limitations as Claim 1 and are rejected under the same rationale.
Regarding Claims 11-16 and 18,
Claims 11-16 and 18 are directed to a non-transitory computer-readable media claim and the claims has similar/same claim limitations as Claims 2-7 and 9 and are rejected under the same rationale.
Regarding Claims 21,
As shown above, Ding, Achin and Singh teaches all the limitations of claim 1. Ding further teaches the method further comprising:
filtering at least one demand pair based at least in part on a correlation coefficient associated with the demand pair, wherein the demand pair is not used to train the first model or the second model based on said filtering ( see Achin: Fig.1, [0220], “the user interface 120 may offer a graphical flow-diagram tool for specifying a hierarchical directed graph of tasks, along with any built-in operations for conditional logic, filtering output, transforming output, partitioning output, combining inputs, iterating over sub-graphs, etc. In some embodiments, user interface 120 may provide facilities for creating the wrappers around pre-existing software to implement leaf-level tasks, including properties that can be set for each task.”)
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Ding to include filtering at least one demand pair based at least in part on a correlation coefficient associated with the demand pair as taught by Achin. One would have been motivated to make such a combination in order to provide efficient, time- saving and cost effective what-if analysis to a user by providing sufficient resources (e.g., computing resource, storage resources, tools, expertise, etc.) on demand to accommodate the simulation requests such that the simulation time for a requested simulation service can be shortened.
Claim Rejections - 35 USC § 103
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 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ding in view of Achin and Singh, as applied to claims 1-7, 9-16, 18-19 and 21 as shown above and in view of Zeng (Pub. No.: US 20140156557 Al, Pub. Date: 2014-06-05)
Regarding Claim 8,
As sown above, Ding teaches all the limitations of claim 1. Ding does not explicitly teach suggest the system wherein the request is received from a tenant of a cloud service wherein responsive to the request the cloud service presents, to the tenant, or stores, at a location accessible to the tenant, a result of the what-if simulation.
However, Zeng teaches the system wherein:
the request is received from a tenant of a cloud service (see Zeng: Fig.2, [0032], “The process can be performed by the cloud-based simulation service infrastructure 102 of FIG. 1. The infrastructure 102 provides (at 202) a cloud-based simulation service that is accessible by multiple enterprises, such as by use of respective enterprise systems 110 in FIG. 1.”); and
wherein responsive to the request the cloud service presents, to the tenant, or stores, at a location accessible to the tenant, a result of the what-if simulation (see Zeng: Fig.3, [0053], “Once a simulation is completed, the analysis code package of the respective simulation model can be invoked (either manually or automatically) to perform analysis of the simulation output data. In some examples, a simulation result analysis manager 320 is able to interact with the VMM 306 or another entity to allocate a virtual machine for the simulation result analysis, and to populate the analysis code package in the virtual allocated machine. The launched analysis code package is then able to communicate with the requestor to start the analysis of the simulation output data, and to navigate through analysis results.”)
Because both Ding, Achin, Singh, and Zeng are in the same/similar field of endeavor of Providing what-if simulation, accordingly, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Ding to be applied in a cloud service platform that include the function of running what-if simulations for several cloud service customers or tenants and provide the result of the what-if analysis as taught by Zeng. After modification of Ding, the server that provide “what-if” functionalities that can be used to evaluate performance implications of different hardware configurations of that system can be implemented using a cloud service platform to provide the same functionality of improving performance of a system as taught by Zeng. One would have been motivated to make such a combination in order to provide efficient, time- saving and cost effective what-if analysis to a user by providing sufficient resources (e.g., computing resource, storage resources, tools, expertise, etc.) on demand to accommodate the simulation requests such that the simulation time for a requested simulation service can be shortened. (See Zeng: [0014])
Regarding Claims 17,
Claim 17 is directed to a non-transitory computer-readable media claim and the claims has similar/same claim limitations as Claims 8 and is rejected under the same rationale.
Response to Arguments
Applicant's prior art arguments with respect to the currently amended independent claims and the dependent claims have been fully considered but they are moot in view of the new grounds of rejection presented above. Applicant is respectfully referred to the complete rejections presented above and the newly cited portions of the references previously relied upon. Examiner further notes that Applicant’s arguments are mere allegations that the cited art does not teach the limitations of the independent claim as amended and do not explicitly show any deficiencies with the previously cited art of the record in relationship with the newly recited limitations.
Thus, Examiner respectfully reasserts that the combination of Ding in view of Achin and Singh sufficiently teaches all the limitations recited in the independent claims, as amended, and therefore independent claims 1-19 and 21 are still rejected under 35 U.S.C. 103 as being unpatentable over Ding in view of Achin and Singh.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
PGPUB
NUMBER:
INVENTOR-INFORMATION:
TITLE / DESCRIPTION
US 10361925 B1
Shukla; Himanshu
Title: Storage Infrastructure Scenario Planning
Description: he present invention relates generally to computer automated activity based budget modeling, forecasting and cost accounting, and more particularly, but not exclusively to what-if analysis of complex data models.
US 20040138936 A1
Johnson, Christopher D
Title: Performing What-if Forecasts Using A Business Information And Decisioning Control System
Description: his invention relates to providing business-related analysis, and, in a more particular implementation, to an automated technique for providing business-related forecasts.
THIS ACTION IS MADE FINAL. 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 ZELALEM W SHALU whose telephone number is (571)272-3003. The examiner can normally be reached M- F 0800am- 0500pm.
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, Cesar Paula can be reached at (571) 272-4128. 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.
/Zelalem Shalu/Examiner, Art Unit 2145
/CESAR B PAULA/Supervisory Patent Examiner, Art Unit 2145
Prosecution Insights