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 . 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.
DETAILED ACTION
This Final Office Action is in response Applicant communication filled on 08/19/2026.
Status of Claims
Claims 1-3, 5, 8, 10-16, and 19-21 heaved been amended by Applicant.
Claims 6,17 have been canceled by Applicant.
Claims 1-5, 7-16 and 18-21 are currently pending and have been rejected as follows.
Response to Applicant’s rebuttal on the claims’ objection
Objection to claim 11 in the prior act is withdrawn in view of Applicant’s amendment as suggested by the Non-Final Act 05/21/2026 p.2 ¶4.
Response to Applicant’s rebuttal on the 35 USC 112 rejection
Remarks 08/19/2026 p.8 ¶5 - p.9 ¶2 argues the claims were amended as suggested in the previous act and thus the 112(b) rejection should be withdrawn.
Examiner fully considered the argument which is found persuasive in view of Applicant’s amendment as suggested in the previous act. 112(b) rejection in the prior act is withdrawn.
Response to Applicant’s rebuttal on the 35 USC 101 rejection
Step 2A prong one: Remarks 08/19/2026 p.12 ¶ 1 argues independent claim 1, requires a processor to receive API execution parameters and historical API execution logs, determine daily resource requirements, predict future API load, forecast API execution time, optimize resource requirements based on the forecasted execution time, and allocate resources to APIs, which is argued as not directed to a fundamental economic practice, a method of organizing human activity, or a mental process. Remarks 08/19/2026 p.12 ¶ 2 further argues that amended independent claim 1 requires processing historical API execution logs associated with a plurality of APIs, determining resource requirements for each day, generating future load predictions, forecasting execution times, and using those forecasts to control resource allocation across a networked computing environment. Such operations involve the analysis of large volumes of execution data and the generation of machine-based forecasts that are not practically performable mentally or with pen and paper. Remarks 08/19/2026 p.12 ¶3-p.13 ¶1 then argues that similar to Enfish, the current Claim 1 is directed to improving the operation of API based computing systems by generating execution-time forecasts and using those forecasts to optimize and allocate computing resources. Remarks 08/19/2026 p.13 ¶2 argues that similar to McRO, Claim 1 recites a particular sequence of computer-implemented operations in which resource requirements are determined from historical API execution data, future API load is predicted based on those requirements, execution time is forecast based on the predicted load, and computing resources are optimized and allocated based on the forecast, as a specific technological methodology for managing computing resources rather than claiming the result of efficient resource allocation.
Examiner fully considered the Step 2A prong one argument but respectfully disagrees.
First, as an issue of claim construction and claim interpretation, it is noted that the independent Claims 1,11,12 as argued by Applicant above, do not explicitly recite API execution parameters, but rather parameters associated with the plurality of APIs. In fact, the receiv[ing] limitation, as raised by Applicant at Remarks 08/19/2026 p.12 ¶1, 3rd sentence is completely devoid of the term execution. In the absence of an explicit definition for the term parameters said parameters, are interpreted, under broadest reasonable interpretation (MPEP 2111), to include any parameters including but not limited to, abstract promotional features, as further exemplified at dependent Claims 2,13 and consistent with the abstract fundamental principles of economy (MPEP 2106.04(A)(2) II A) and/or commerce (MPEP 2106.04(a)(2) II B).
Second, even as amended, the claims still recite, describe or set forth the abstract idea of forecasting as summarized in the preamble of each of independent Claims 1,12 and detailed in the body of the claims 1-4, 7-15 and 18-21. The fact that such forecasting or resources, and associated optimization and allocation happen to correspond to computer resources or assets in general, and to “application programing interface API” in particular, instead of a broader recitation of any type of resources or underlining assets, does not necessarily render the current claims less abstract and eligible because according to MPEP 2106.04(a)(2) II A ¶2, a fundamental concept is not used in the sense of being old or well-known but rather as a building block of modern economy. Here, as revealed by the Non-Final Act 05/21/2026 p.3 last three paragraphs to p.4 ¶1, the demand, supply and predict[ive], forecast[ing] and their associated mitigative functions, represent such building blocks of modern economy no matter of the computer environment upon which they are used. Here such computer environment is set forth by the application programming interfaces APIs. In a similar vein, MPEP 2106.04(A)(2) I ¶3, corroborates that narrow laws that have limited applications were still held ineligible. Thus here, the demand, supply and predict[ive], forecast[ing] and the associated mitigative functions, are limited to applications relating to application programming interfaces APIs, as an environment, which, as tested per MPEP 2106.04(A)(2) I ¶3 supra, does not preclude the claims to recite, describe or set forth the abstract exception. In fact, there is a preponderance of evidence showing the claims character, as a whole being abstract as evidenced by: “forecasting execution time” “based on” “prediction of future load” [or work] “based on number of resources” [or supply] “required” [or needed or demanded] “for each day”, which, at its turn, is “based on” “parameters” (i.e. “promotional”, “environmental” etc.) used “to determine a cumulative service level agreement (SLA)”, and also based on “a historical log” (i.e. “calendar events” with respect to “data size”) as recited throughout Claims 1-2,5,11,12, 13,16. Such fundamental economic practices are corroborated by the resources’ “allocation” “based on the optimization of the number of resources” “based on the forecasting time” as now amended at each of independent Claims 1,11,12, and a best business practice or test of “checking if the cumulative SLA” [service level agreement] “is affected by increasing request or data load based on the historical log” at dependent Claims 8,19, to perform a fundamental, mitigative functions to: “maintain the cumulative SLA when actual load increases based on the prediction of the future load” at dependent Claims 9,20 and “minimizing a combination of execution, run time and traffic” “based on the prediction and optimization made” at dependent Claims 10,21.
When tested per MPEP 2106.04(a)(2) II such limitations recite, describe or set forth the fundamental practices or principles of demand and ensuing maintenance supply allocation, that fall well within the broad abstract grouping of “Certain Methods of Organizing Human Activities”.
Once again, the Examiner stresses that the fact that such execution and allocat[ion] of resources or their underlining assets correspond to “application programing interface API”, does not necessarily render the claims less abstract and eligible because per MPEP 2106.04(a)(2) II A ¶2, a fundamental concept is not used in the sense of being old or well-known but rather as a building block of modern economy. Here, the demand, supply and predict[ive], forecast[ing] and mitigative functions as set forth above, represent such building blocks of modern economy no matter of the computer environment upon which they are used. MPEP 2106.04(A)(2) I ¶3, corroborates this by stating that narrow laws that have limited applications are still ineligible.
It then follows that here, the abstract demand, supply and predict[ive], forecast[ing] and mitigative functions, as identified above, are limited to applications relating to application programming interfaces APIs, which, as tested per MPEP 2106.04(A)(2) I ¶3 supra, do not preclude the claims to recite, describe or set forth the abstract idea.
Such findings are further corroborated by Tranxition v. Lenovo (United States) Inc. as cited by USPTO’s 35 USC 101 Examination Guidance and Training Materials, Current Training, C. Information about Judicial Decisions, subsection 1. Subject Matter Eligibility Court Decisions, listed within the Federal Circuit decisions at Row# 49. Claim 1 of the ’877 patent read as follows:
1. A method in a computer system for preparing configuration settings for transfer from a source computing system to a target computing system, the method comprising:
providing configuration information about configuration settings on the source computing system, the configuration information including a name and location of each configuration setting;
generating an extraction plan that identifies con figuration settings to be extracted from the source computing system, the generating including providing a list of configuration set tings known to the source computing system and including identifying active configuration settings out of the provided list of configuration settings to be extracted from the source computing system;
extracting the active configuration settings of the extraction plan from the source computing system, the extracted configuration settings being located using the provided configuration information;
generating a transition plan that identifies con figuration settings to be transferred from the source computing system to the target computing system, the generating including providing active configuration settings of the extraction plan and including identifying from the active configuration settings of the extraction plan active configuration settings to be transferred from the source computing system to the target computing; and for each active configuration setting of the transition plan,
retrieving the extracted configuration settings identified as active configuration settings of the transition plan; and
transitioning one or more of the retrieved con figuration settings from a format used on the source computing system to a format used on the target computing system.
Specifically, Tranxition was unpersuasive in arguing that migration or transitioning of computer settings from one computer to another, is a specific software-based solution to a computer-based problem and exceeds the abstract concept of migration. Thus, the solution was found by the Court to still be abstract.
Here, similar to Tranxition’s migration or transitioning of computer settings from one computer to another, the current claims are “allocating one or more resources” “based on the optimization of the number of resources, after a prior “forecasting execution time” “based on” “prediction of future load” [or work] “based on number of resources” [or supply] “required” [or demanded] “for each day”, which, at its turn, is “based on” “parameters” (i.e. “promotional”, “environmental” etc.) used “to determine a cumulative service level agreement (SLA)”, and also based on “a historical log” (i.e. “calendar events” with respect to “data size)” recited at Claims 1-2,5,11,12,13,16, and the best business practice of “checking if the cumulative SLA” [service level agreement] “is affected by increasing request or data load based on the historical log” at dependent Claims 8,19, to perform fundamental, mitigative functions to: “maintain the cumulative SLA when actual load increases based on the prediction of the future load” at dependent Claims 9, 20 and “minimizing a combination of execution, run time and traffic” “based on the prediction and optimization made” at dependent Claims 10,21.
Thus here, the Examiner reasons that similar to Tranxition’s analysis and manipulation of computer settings, the current limitations would also recite, describe or set forth the abstract exception, despite its execution, association and/or further narrowing to a computer environment.
Accordingly, the current claims are closer to the ineligibility findings of Tranxition’s supra than the eligibility findings in either Enfish or McRO, cited by Remarks 08/19/2026 p.12 ¶3-p.13 ¶1. This is because at no point do the current claims provide anything remotely analogous to the classification of structures for repeated extraction and the importing as required precursors for mapping with self-referential data structures, as was the case in Enfish, 822 F.3d 1327,1336,118 USPQ2d 1684, 1689 (Fed. Cir. 2016) cited by MPEP 2106.04(a), or the technological details of automatic lip synchronization and facial expression animation by using computer-implemented rules, as was the case in McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1316, 120 USPQ2d 1091, 1103 (Fed. Cir. 2016), as cited by MPEP 2106.04(a) paragraph 1.
Rather the current claims recite the fundamental and abstract “forecasting execution time” “based on” “prediction of future load” [or work] “based on number of resources” [or supply] “required” [or demanded] “for each day”, which, at its turn, is “based on” “parameters” (i.e. “promotional”, “environmental” etc.) used “to determine a cumulative service level agreement (SLA)”, and also based on “a historical log” (i.e. “calendar events” with respect to “data size)”, “optimizing the number of resources required for each day based on the forecasting of time” recited at Claims 1-2,5,11,12,13,16, resources’ “allocation” “based on the optimization of the number of resources” “based on the forecasting time” as recited at independent Claims 1,11,12, and the best business practice of “checking if the cumulative SLA” [service level agreement] “is affected by increasing request or data load based on the historical log” at dependent Claims 8,19, to perform fundamental, mitigative functions to: “maintain the cumulative SLA when actual load increases based on the prediction of the future load” at dependent Claims 9,20 and “minimizing a combination of execution, run time and traffic” “based on the prediction and optimization made” at dependent Claims 10,21. Finally, “allocating one or more resources” “based on the optimization of the number of resources” can also be argued to be abstract right from the onset, as demonstrated above vis-a-vis Tranxition’s migration or transitioning of computer settings, which the Federal Circuit ruled as insufficient under step one of Alice. This is also consistent with the limited applications of the abstract idea which, according to MPEP 2106.04(A)(2) I ¶3, does not render the claimed less abstract and eligible. Examiner further submits, in the arguendo, that even if tested at the subsequent steps, as part of additional elements, such “allocating” would at most correspond to applying of the abstract exception, as tested per MPEP 2106.05(f)(2), and/or a narrowing of the abstract forecasting and optimization to a field of use or technological environment, as reflected here by the application programming interfaces APIs, when equally tested under MPEP 2106.05(h). These considerations would also not render the claims eligible.
Additionally, or alternatively1, when tested per MPEP 2106.04(a)(2) III C #2. the Examiner finds that a computer environment upon which processes, (i.e computer aided mental processes), are being performed still sets forth the abstract idea. Here, such computer environment is set forth by the application programming interfaces APIs, while the computer aided metal processes executed in such computer environment are those of computer aided
i. observation: namely the receiv[ed] “parameters” (i.e. “promotional”, “environmental” etc.)
and “historical log” (i.e. “calendar events” with respect to “data size”) at Claims 1-2,5,11,12,13,16 and “check if the cumulative SLA of each of said API is affected by increasing request or data load based in the historical log of execution of the plurality of APIs” at dependent Claims 8,19,
ii. evaluation: “predicting” “future load on each of said APIs based on the number of resources required for each day”, “forecasting” “execution time required for each said API based on the prediction oof the future load on each of said API” at independent Claims 1,11,12 to arrive at a
iii. judgment to “optimize the number of resources required for each day based on the forecasting of time required for each said API”, “allocate one or more resources to an API based on the optimization of the number of resources” at independent Claims 1,11,12 “maintain the cumulative SLA when actual load increased based on the prediction of the future load” at dependent Claims 9,20, “minimize a combination of execution, run time, and traffic in the API based on the prediction and optimization made” at dependent Claims 10,21.
However, MPEP 2106.04(a)(2) III ¶2 is clear that processes that include i. observations, ii. evaluations, and iii. judgments, set forth the abstract exception with MPEP 2106.04(a)(2) III C stating that: #1. Performing a mental process on a generic computer, # 2. Performing a mental process in a computer environment, and # 3. Using a computer as a tool to perform a mental process, do not preclude the claims from recting, describing or setting forth the abstract exception.
Hence, here the requirement for a processor as raised by Remarks 08/19/2026 p.12 ¶1, to receive parameters and historical API execution logs, determine daily resource requirements, predict future API load, forecast API execution time, optimize resource requirements based on the forecasted execution time, and allocate resources to APIs, would not necessarily preclude the claims to recite, describe or set forth the abstract idea.
Thus here, there is a preponderance of legal evidence to show that the claims’ character as a whole is abstract, regardless of the computerized environment where they are executed. Accordingly, the Step 2A prong one argument is unpersuasive.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 2A prong two: Remarks 08/19/2026 p.13 last ¶ - p.14 ¶1 argues that independent claim 1 uses API execution parameters and historical execution logs to determine resource requirements, predict future API load, forecast execution time required for each API optimize resource requirements based on the forecasted execution time, and ultimately allocate one or more computing resources to an API. Thus, Applicant argues that the forecasting operations are not performed for informational purposes alone; they directly control the allocation of computing resources within a networked computing environment. Next, Remarks 08/19/2026 p.14 ¶2 argues that similar to DDR Holdings, the present invention addresses a technical problem arising in API-based computing systems, namely the inefficient allocation of computing resources caused by fluctuating and difficult-to-predict API workloads. Specifically, the Applicant argues that the claimed solution forecasts execution time based on predicted API load and uses the forecast to optimize and allocate resources, thereby improving the operation of the computing environment itself. Then, Remarks 08/19/2026 p.14 ¶3 argues that the current claim 1 is similar to SRI International, because it is directed to improving the functioning of API execution systems through a specific sequence of processing operations that enables proactive resource allocation based on forecasted execution requirements. Specifically, Applicant argues that the claimed forecasting, optimization, and allocation operations collectively improve the efficiency and performance of the computing environment rather than merely generating information for a user. Finally, Remarks 08/19/2026 p.14 ¶4 - p.15 ¶1 argues that similar to Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016), the amended independent claim 1 does not end with forecasting or prediction. Instead, the forecasted execution time is used to optimize the number of resources required and to allocate one or more resources to an API.
Examiner fully considered the Step 2A prong two argument but respectfully disagrees finding it unpersuasive, reincorporating herein all findings and rationales above.
First, as an issue of claim construction and claim interpretation, it is once again noted that independent Claims 1,11,12 as argued above, do not explicitly recite API execution parameters, but rather parameters associated with the plurality of APIs. In fact, the receiv[ing] limitation, as raised by Applicant at Remarks 08/19/2026 p.13 last ¶, is completely devoid of the term execution. In the absence of an explicit definition for the term parameters said parameters, are interpreted, under broadest reasonable interpretation (MPEP 2111), to include any parameters including but not limited to, abstract promotional features, as further exemplified at dependent claims 2,13 and consistent with the fundamental principles of economy (MPEP 2106.04(A)(2) II A) and/or commerce (MPEP 2106.04(a)(2) II B). The same principles apply to predicting future load, forecast execution time and mitigative function to optimize resource requirements based on the forecasted execution time, as building blocks of economy no matter of the computer environment (i.e. API) upon which they are used. MPEP 2106.04(A)(2) I ¶3, corroborates by stating that narrow laws that have limited applications were still held ineligible. Thus here, the demand, supply and predict[ive], forecast[ing] and mitigative functions, are limited to applications relating to application programming interfaces APIs, as an environment, which, as tested per MPEP 2106.04(A)(2) I ¶3 supra, does not preclude the claims to recite, describe or set forth the abstract exception. When tested per MPEP 2106.04(a)(2) II such limitations recite, describe or set forth the fundamental practices or principles of demand and ensuing maintenance supply allocation, that fall well within the broad Certain Methods of Organizing Human Activities grouping. It is thus plausible that “allocating one or more resources” “based on the optimization of the number of resources” could be argued as abstract right from onset, as demonstrated above vis-a-vis Tranxition’s migration or transitioning of computer settings above, which the Federal Circuit ruled as insufficient under step one of Alice. This is also consistent with the limited applications of the abstract idea which, according to MPEP 2106.04(A)(2) I ¶3, does not render the claimed less abstract and eligible. Accordingly, the improvement asserted by Remarks 08/19/2026 p.14 ¶2-¶3, would represent an improvement in the abstract exception. Yet, MPEP 2106.04 I is clear that even “groundbreaking, innovative, or even brilliant discovery” [in the judicial exception] “does not by itself satisfy the 101 inquiry” citing Myriad, 569 U.S. at 591, 106 USPQ2d at 1979. The Myriad rationale was corroborated by “SAP Am, Inc v InvestPic” and cited by both MPEP 2106.04(a)(2) I ¶4 and MPEP 2106.04(a)(2) I.C(i), stressing that performing a resampled analysis to generate a resampled distribution, remain directed to the abstract idea. Indeed, digging deeper into SAP supra, the Examiner finds that the Court adopted a similar ruling as in Myriad, restating that “even if one assumes that the techniques claimed are groundbreaking, innovative, or even brilliant those features are not enough for eligibility because their innovation is innovation in ineligible subject matter. An advance of that nature is ineligible for patenting”. This is consistent with MPEP 2106.05(a) II stating that: improvement in the abstract idea is not improvement in technology. Thus, here the argued allocation, similar to SAP’s resampling would also be ineligible.
Examiner also submits, in arguendo, that even if tested at subsequent steps, as part of additional elements, such “allocating one or more resources to an API based on the optimization of the number of resources”, which at its turn, is “based on the forecasting of time required for each said API”, would at most correspond to applying of the fundamental and abstract forecasting execution and resource optimization by invocation or computer components or other machinery, which as revealed tested per MPEP 2106.05(f)(2), would not integrate the abstract exception into a practical application. Additionally or alternatively, it could also be argued a narrowing of the abstract forecasting and optimization to a field of use or technological environment, as reflected here by the application programming interfaces APIs, which when equally tested under MPEP 2106.05(h)(vi) would represent a narrowing to a field of use or technological environment of the combination of collecting (here receiving) information, analyzing (here predicting, forecasting), for certain results (here optim[al] number) of the collection and analysis.
No matter at which stage of the subject matter eligibility analysis such “allocating” limitation is tested, it does not render the claims less abstract and eligible given their current breadth.
With respect to DDR, as cited by Applicant at Remarks 08/19/2026 p.14 ¶2, the Examiner submits that, at no point do the claims provide anything remotely technologically analogous to the systems and methods of generating a composite webpage that combines certain visual elements of a host website with the content of a third-party, as in DDR Holdings, LLC v Hotels.com, LP,773 F.3d 1245,113 USPQ2d 1097 (Fed Cir 2014) and cited by MPEP 2106.05(d). Digging deeper into DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d at 1248, 113 USPQ2d at 1099, the Examiner finds the Court ruled that the eligible claim in DDR modified conventional Internet hyperlink protocol to dynamically produce a dual-source hybrid webpage, which differed from the conventional operation of Internet hyperlink protocol that transported the user away from the host’s webpage to the third party’s webpage when the hyperlink was activated. The current claims are devoid of any such technological improvements. Also, the current claims have nothing to do with detecting suspicious activity by using network monitors and analyzing network packets as was the case in SRI Int’l, 930 F.3d at 1304 as cited by MPEP 2106.04(a)(2) III A, 2nd bullet point.
Instead, the current claims recite the fundamental and abstract “forecasting execution time” “based on” “prediction of future load” [or work] “based on number of resources” [or supply] “required” [or demanded] “for each day”, which, at its turn, is “based on” “parameters” (i.e. “promotional”, “environmental” etc.) used “to determine a cumulative service level agreement (SLA)”, and also based on “a historical log” (i.e. “calendar events” with respect to “data size)”, “optimizing the number of resources required for each day based on the forecasting of time” recited at Claims 1-2,5,11,12,13,16, resources’ “allocation” “based on the optimization of the number of resources” “based on the forecasting time” as recited at independent Claims 1,11,12, and the best business practice of “checking if the cumulative SLA” [service level agreement] “is affected by increasing request or data load based on the historical log” at dependent Claims 8,19, to perform fundamental, mitigative functions to: “maintain the cumulative SLA when actual load increases based on the prediction of the future load” at dependent Claims 9,20 and “minimizing a combination of execution, run time and traffic” “based on the prediction and optimization made” at dependent Claims 10,21. Finally, “allocating one or more resources” “based on the optimization of the number of resources” can also be argued to be abstract right from the onset, as demonstrated above vis-a-vis Tranxition’s migration or transitioning of computer settings, which the Federal Circuit ruled as insufficient under step one of Alice. Yet, Examiner resubmits, in the arguendo, that even if tested at Step 2A prong two, as part of additional elements, such “allocating” would at most correspond to applying of the abstract idea of forecasting execution, as tested per MPEP 2106.05(f)(2), and/or a narrowing of the abstract forecasting and optimization to a field of use or technological environment, as reflected here by the application programming interfaces APIs, when equally tested under MPEP 2106.05(h). These would not integrate the abstract idea into a practical application. Thus, step 2A prong two argument is unpersuasive.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 2B: Remarks 08/19/2026 p.16 ¶3 argues that all 6 limitations of: (i) receiving API execution parameters and historical execution logs, (ii) determining resource requirements for each day, (iii) predicting future API load based on the determined resource requirements, (iv) forecasting execution time required for each API based on the predicted future load, (v) optimizing resource requirements based on the forecasted execution time, and (vi) allocating computing resources to APis based on the optimization; represent a specific sequence of technological operations define a particular technological workflow for managing computing resources in an API execution environment and amount to significantly more than abstract forecasting or planning.
Remarks 08/19/2026 p.16 last ¶ argues similar to BASCOM Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016), claim 1 recites specific and unconventional arrangement in which predicted future API load used to forecast execution time, the forecasted execution time is then used to optimize resource requirements, and the optimization is further used to allocate resources. Remarks 08/19/2026 p.17 ¶1 argues similar to Amdocs (Israel) Ltd v. Openet Telecom, Inc., 841 F.3d 1288 (Fed. Cir. 2016) the claimed combination provides a technical improvement by enabling proactive allocation of computing resources based on forecasted execution requirements, thereby improving resource utilization and reducing inefficiencies associated with over-provisioning and under-provisioning of computing resources.
Finally, Remarks 08/19/2026 p.17 ¶2 argues that current claims are distinguishable from
Alice Corp. Pty. Ltd v. CLS Bank International, 573 U.S. 208 (2014).
Examiner fully considered the Step 2B argument but disagrees, finding it unpersuasive.
Examiner notes that all or nearly all of the (i) to (vi) limitations above recite features that are, for the most part abstract. Thus, Examiner reincorporates all findings and rationales above.
Even if the “allocating” limitation would warrant additional investigation, as part of the additional elements, it would still not render the claims patent eligible. Specifically, in such case, the Examiner would follow MPEP 2106.05 II guidelines and carries over the above findings at MPEP 2106.05 (f) and/or (h) to submit that as shown above, the contested element(s), merely apply the already recited abstract idea [MPEP 2106.05(f)] and/or narrow it to a field of use or technological environment [MPEP 2106.05(h)].
With respect to Applicant’s allegation that similar to Amdocs, the current claims improve resource utilization and reduce inefficiencies associated with over-provisioning and under-provisioning of computing resources, the Examiner points to MPEP 2106.04(d)(1) ¶2 to submit that the Applicant’s alleged improvement at Remarks 08/19/2026 p.17 ¶1, is not reflected in the claim itself, nor described in the Original Specification, in such a manner that it would have been apparent to one of ordinary skill in the art. This is important since the “101 inquiry must focus on language of Asserted Claims themselves” as in “Synopsys, Inc. v Mentor Graphics Corp, U.S. Court of Appeals Federal Circuit, No 2015-1599, October 17 2016 2016 BL 344522 839 F3d 1138” citing “Accenture Global Servs., GmbH
PNG
media_image1.png
1
1
media_image1.png
Greyscale
v
PNG
media_image1.png
1
1
media_image1.png
Greyscale
. Guidewire Software, Inc. 728
PNG
media_image1.png
1
1
media_image1.png
Greyscale
F.3d
PNG
media_image1.png
1
1
media_image1.png
Greyscale
1336, 1345 108 USPQ2d 1173 Fed Cir. 2013: admonishing that the important inquiry for a 101 analysis is to look to the claim”, citing “Content Extraction & Transmission LLC
PNG
media_image1.png
1
1
media_image1.png
Greyscale
v.
PNG
media_image1.png
1
1
media_image1.png
Greyscale
Wells Fargo Bank Nat’l Ass’n 776
PNG
media_image1.png
1
1
media_image1.png
Greyscale
F3d
PNG
media_image1.png
1
1
media_image1.png
Greyscale
1343, 1346 113 USPQ2d 1354 (Fed. Cir. 2014): We focus here on whether the claims of the asserted patents fall within the excluded category of abstract ideas”, cert. denied, 136 S Ct 119, 193 L. Ed. 2d 208 2015). This is consistent with MPEP 2103 I.C stating that “claims define the property rights provided by patent, thus require careful scrutiny. The goal of claim analysis is to identify boundaries of protection sought by applicant and to understand how claims relate to and define what applicant indicated is the invention. USPTO personnel must first determine the scope of a claim by thoroughly analyzing the language of claim before determining if claim complies with each statutory requirement for patentability”. Simply said “[T]he name of the game is the claim”.
Equally important, at no point do the current claims provide anything remotely analogous to minimizing impact on network and system resources through a distributed architecture by collecting and processing data close to its source, followed by enabling load distribution to allow data to reside close to the information sources, thereby reducing congestion in network bottlenecks, while still allowing data to be accessible from a central location, as was the case in Amdocs (Israel) Ltd v. Openet Telecom, Inc., 841 F.3d 1288 (Fed. Cir. 2016). At most the current claims receive parameters (i.e. promotional features) and historical log of execution of the plurality of APIs to determine a number of resources, predict future load and forecast execution time, for subsequent resource optimiz[ation], recited at high level of generality as being, “based on the forecasting of time required for each said API” and subsequent allocat[ion], also recited at a high level of generality, as being “based on the optimization of the number of resources”. There is no distributed architecture by collecting and processing data close to its source, followed by load distribution to allow data to reside close to the information sources, thereby reducing congestion in network bottlenecks, while still allowing data to be accessible from a central location, as was the case in Amdocs (Israel) Ltd v. Openet Telecom, Inc., 841 F.3d 1288 (Fed. Cir. 2016).
Also here, the argued features are irreconcilably different than the technological improvements found in the BASCOM case law, as cited by Applicant at Remarks 08/19/2026 p.16 ¶4. For once, in BASCOM Global Internet Servs. v. AT&T Mobility LLC, 827 F.3d 1341,1350-51,119 USPQ2d 1236,1243-44 (2016), as cited MPEP 2106.05(d) I.3, the additional computer-based elements amounted to significantly more than the abstract idea due to a non-conventional and non-generic arrangement that provided a technical improvement in the art. Indeed, digging deeper into Bascom supra, the Examiner discovers that its claims were found eligible because they utilized a hybrid filtering scheme implemented on ISP server, which, for its time (1990s), was found by the Federal Circuit to be a technology-based solution that filtered content on Internet to overcome existing problems with other Internet filtering systems. Specifically, in Bascom, the claims took a prior art filter solution (one-size-fits-all filter at the ISP server) and made it more dynamic and efficient (providing individualized filtering at ISP server), raising the claims to a level of software-based invention that improved performance of the computer system itself Bascom Glob. Internet Servs. v. AT&T Mobility, LLC, U.S. Court of Appeals Federal Circuit, No. 2015-1763, June 27,2016,2016 BL 204401,827 F.3d 1341. Here however, there is nothing remotely technologically similar to the dual filtering scheme of Bascom. Rather the current claims receive parameters (i.e. promotional features) and historical log of execution of the plurality of APIs to determine a number of resources, predict future load and forecast execution time, for subsequent resource optimiz[ation], recited at high level of generality as being, “based on the forecasting of time required for each said API” and subsequent allocat[ion], also recited at a high level of generality, as being “based on the optimization of the number of resources”.
Based on the preponderance of legal evidence above, the Examiner submits that the claims still recite, or at minimum describe or set forth the abstract exception(Step 2A prong one), with no additional elements capable to integrate the abstract exception into a practical application (Step 2A prong 2) or provide significantly more than what was already identified abstract idea (Step 2B). Thus Step 2B argument along with Step 2A prong 1 and 2 arguments are unpersuasive.
Response to Applicant’s rebuttal on the 35 USC 102(a)(1) rejection
- independent Claims 1,11,12 -
Argument 1: Remarks 08/19/2026 p.19 ¶2-¶4 argues Dave US 20180331928 A1 does not - “forecast, an execution time required for each said API" because Applicant argues that Dave supra is concerned with whether a client device will exceed a contractual usage limit, not with predicting how long each API will take to execute.
Argument 1 has been fully considered but is found unpersuasive.
First, as an issue of correct claim interpretation, as tested under the broadest reasonable interpretation of MPEP 2111, it is noted independent claims 1,11,12 do not explicitly recite predicting or forecasting how long each API will take to execute. Rather said claims 1,11,12, broadly recite “execution time” interpreted, based on the broadest reasonable interpretation of MPEP 2111, as any “time” related to “execution” including but not limited to a time of execution, a time of starting, completing, or meeting a process or execution, but not necessarily exclusively limited to the duration of said execution as narrowly interpreted by Applicant above. Based on such claim interpretation in accordance with broadest reasonable interpretation, Dave ¶ [0076] 2nd sentence, discloses a predict[ed] a time at which client device 210 is expected to use a threshold amount of cloud computing resource 232… and thus teaches the “execution time”, under the broad umbrella of time of starting, completing, or meeting a process or execution consistent with the broadest reasonable interpretation MPEP 2111. Such an execution time of the API is reflected at Fig.1D element 180: Estimated date of satisfying API call threshold: March 26, 2017, as 23:15.
PNG
media_image2.png
522
844
media_image2.png
Greyscale
Dave Annotated Fig.1D in support of rebutting argument 1
Second, the Examiner submits, in the arguendo, that even if the term “execution time” is interpreted to refer to a duration, Dave still meets such much narrower interpretation, because Dave ¶ [0075] 3rd sentence, and ¶ [0080] 2nd sentences: predict[s] future resource utilization such as additional resource utilization or reduced resource utilization based on current resource utilization. For example, at Fig.1B below, ¶ [0023] 2nd-3rd sentences: the predicted execution of 20,000 API calls PER 24 hours is equivalent to 1 API call per 24/20000 hours, which, is equivalent to 1 API call per 0.0012 hours, which, is equivalent to 1 API call PER 4.32 seconds.
PNG
media_image3.png
868
854
media_image3.png
Greyscale
Dave Fig.1B in support of rebutting argument 1
Accordingly, Dave not only teaches “execution time” based on the proper broadest reasonable interpretation test of MPEP 2111, but also teaches the “execution time” as 1 API call PER 4.32 seconds, based on the Applicant’s much narrower interpretation.
Based on such legal standards and findings of fact, the Examiner concludes that the Applicant’s prior art Argument 1 is unpersuasive.
Argument 2: Remarks 08/19/2026 p.19 ¶5-p.20 ¶1 argues Dave does not:
- “optimize the number of resources required for each day based on the forecasting of time required for each said API” because Dave does not forecast execution time in the first place.
Argument 2 has been fully considered but is unpersuasive, with Examiner reincorporating herein all findings and rationales in the response to prior art Argument 1 above. Specifically,
Dave predicts 20000 API calls PER 24 hours or per each day or 1 API call PER 4.32 seconds.
Dave ¶ [0026] 4th sentence further states: the resource analysis platform may configure the cloud computing resources to operate according to the set of recommendations... to optimize the resource utilization of the set of client devices, etc. Specifically, per Dave ¶ [0075], ¶ [0089] 1st-2nd sentences: resource analysis platform 220 may determine a priority [or optimization] based on a current score with which a recommendation is associated. For example, assuming that a first current score indicates a higher likelihood of a first resource utilization satisfying a threshold than a second current score associated with a second resource utilization, resource analysis platform 220 may prioritize [or optimize] a first recommendation associated with the first current score higher than a second recommendation associated with the second current score. Similarly, per
Dave ¶ [0090] 2nd sentence: resource analysis platform 220 determine priority for recommendation related to a resource utilization of a particular type of cloud computing resource 232 (e.g. prioritize a resource utilization of a static cloud computing resource 232 higher than a resource utilization of dynamic cloud computing resource 232, or vice versa), based on a demand for various cloud computing resources 232 (e.g., prioritize a recommendation for cloud computing resource 232 that has a threshold demand from multiple client devices 210), based on a predicted impact of the recommendation (predicted impact on current score, whether the recommendation will prevent a resource utilization from satisfying a threshold, etc.), and/or the like).
Therefore, the Applicant’s prior art Argument 2 is also found unpersuasive.
Argument 3: Remarks 08/19/2026 p.20 ¶2 recognizes Dave’s ¶ [0083] recommendations relate to reducing or increasing a resource utilization, but still contests Dave “allocate one or more resources to an API based on the optimization of the number of resources”
Argument 3 has been fully considered but is unpersuasive.
First, it is noted that Remarks 08/19/2026 p.20 ¶2 recognizes or admits Dave ¶ [0083] recommendations relate to reducing or increasing a resource utilization in a manner similar to how Applicant previously argued above that the current invention provides proactive allocation of computer resources for over-provisioning and under-provisioning at the prior Step 2B argument of Remarks 08/19/2026 p.17 ¶1. Thus, an argument can be made that Dave teaches the contested allocation limitation based on these facts alone.
More to the point, Dave provides a preponderance of evidence starting with ¶ [0015] disclosing that … cloud computing resources to perform various operations, such application program interface (API) calls. Then Dave ¶ [0072] 3rd sentence discloses that a current score indicate…, amount of cloud computing resource 232 allocated for a transaction or operation, and/or the like. For example, at ¶ [0083] 2nd-4th sentence: …recommendations…relate to…increasing [or allocating] a resource utilization, a rate of resource utilization, and/or the like. Additionally… a set of recommendations may relate to cloud computing resource 232. For example, resource analysis platform 220 may determine a recommendation to use [or allocated] a different cloud computing resource 232… a different combination of cloud computing resources 232 (e.g., a combination of cloud computing resources 232 that consumes less total cloud computing resources 232), and/or the like).
Based on the totality of the evidence above, the Applicant’s admission, the breadth of the claims, and the broadest reasonable interpretation, the Examiner submits that Dave teaches the contested features. Thus, Argument 3 is, along with Arguments 1,2, unpersuasive.
Response to Applicant’s rebuttal on the 35 USC 103 rejection
Remarks 08/19/2026 p.20 ¶5 - p.22 argues the dependent claims overcome the prior art by dependency to parent independent claim 1,11,12. Examiner fully considered the argument but respectfully disagrees reincorporating herein all findings and rationales above.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 1-5,7-16,18-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract “forecasting execution time” “based on” “prediction of future load” [or work] “based on number of resources” [or supply] “required” [or needed or demanded] “for each day”, which, at its turn, is determin[ed] “based on” “parameters” (i.e. “promotional”, “environmental” etc.) used “to determine a cumulative service level agreement (SLA)”, and also based on “a historical log” (i.e. “calendar events” with respect to “data size”) recited throughout Claims 1-2,5,11,12,13, 16. These do correspond to the fundamental economic practices of MPEP 2106.04(a)(2) II A within the broad abstract grouping of Certain Methods of Organizing Human Activities.
Such fundamental economic practices are corroborated by the resources’ “allocation” “based on the optimization of the number of resources” “based on the forecasting time” as recited at independent Claims 1,11,12, and a best business practice or test of “checking if the cumulative SLA” [service level agreement] “is affected by increasing request or data load based on the historical log” at dependent Claims 8,19, to perform a fundamental, mitigative functions with respect to: “the cumulative SLA when actual load increases based on the prediction of the future load” at dependent Claims 9, 20 and “minimizing a combination of execution, run time and traffic” “based on the prediction and optimization made” at dependent Claims 10,21. When tested per MPEP 2106.04(a)(2) II such limitations recite, describe or set forth the fundamental practices or principles of demand and ensuing maintenance supply allocation, that fall well within the abstract “Certain Methods of Organizing Human Activities”. The fact that such execution and allocat[ion] of resources correspond to “application programing interface API” does not necessarily render the claims less abstract and eligible because per MPEP 2106.04(a)(2) II A ¶2, a fundamental concept is not used in the sense of being old or well-known but rather as a building block of modern economy. Here, the demand, supply and predict[ive], forecast[ing] and mitigative functions as set forth above, represent such building blocks of economy no matter of the computer environment upon which they are used. MPEP 2106.04(A)(2) I ¶3, corroborates by stating that narrow laws that have limited applications were still held ineligible. Here, the demand, supply and predict[ive], forecast[ing] and mitigative functions, as set forth above are limited to applications relating to application programming interfaces APIs, which, as tested per MPEP 2106.04(A)(2) I ¶3 supra, do not preclude the claims to recite, describe or set forth the abstract idea.
Such findings are further corroborated by Tranxition v. Lenovo (United States) Inc. as cited by USPTO’s 35 USC 101 Examination Guidance and Training Materials, Current Training, C. Information about Judicial Decisions, subsection 1. Subject Matter Eligibility Court Decisions, listed within the Federal Circuit decisions at Row# 49. Claim 1 of the ’877 patent read as follows:
1. A method in a computer system for preparing configuration settings for transfer from a source computing system to a target computing system, the method comprising:
providing configuration information about configuration settings on the source computing system, the configuration information including a name and location of each configuration setting;
generating an extraction plan that identifies con figuration settings to be extracted from the source computing system, the generating including providing a list of configuration set tings known to the source computing system and including identifying active configuration settings out of the provided list of configuration settings to be extracted from the source computing system;
extracting the active configuration settings of the extraction plan from the source computing system, the extracted configuration settings being located using the provided configuration information;
generating a transition plan that identifies con figuration settings to be transferred from the source computing system to the target computing system, the generating including providing active configuration settings of the extraction plan and including identifying from the active configuration settings of the extraction plan active configuration settings to be transferred from the source computing system to the target computing; and for each active configuration setting of the transition plan,
retrieving the extracted configuration settings identified as active configuration settings of the transition plan; and
transitioning one or more of the retrieved con figuration settings from a format used on the source computing system to a format used on the target computing system.
Specifically, Tranxition was unpersuasive in arguing that migration or transitioning of computer settings from one computer to another, is a specific software-based solution to a computer-based problem and exceeds the abstract concept of migration. Thus, the solution was found by the Court to still be abstract.
Here, similar to Tranxition’s migration or transitioning of computer settings from one computer to another, the current claims are “forecasting execution time” “based on” “prediction of future load” [or work] “based on number of resources” [or supply] “required” [or demanded] “for each day”, which, at its turn, is “based on” “parameters” (i.e. “promotional”, “environmental” etc.) used “to determine a cumulative service level agreement (SLA)”, and also based on “a historical log” (i.e. “calendar events” with respect to “data size)” recited at Claims 1-2,5,11,12,13,16, resources’ “allocation” “based on the optimization of the number of resources” “based on the forecasting time” as recited at independent Claims 1,11,12, and the best business practice of “checking if the cumulative SLA” [service level agreement] “is affected by increasing request or data load based on the historical log” at dependent Claims 8,19, to perform fundamental, mitigative functions to: “maintain the cumulative SLA when actual load increases based on the prediction of the future load” at dependent Claims 9, 20 and “minimizing a combination of execution, run time and traffic” “based on the prediction and optimization made” at dependent Claims 10,21. Thus here, Examiner reasons that similar to Tranxition’s analysis and manipulation of computer settings, the current limitations would also recite, describe or set forth the abstract exception, despite its execution, association and/or further narrowing to a computer environment.
Also2, MPEP 2106.04(a)(2) III C #2 states: a computer environment upon which processes, (i.e computer aided mental processes), are being performed still sets forth the abstract idea. Here, such computer environment is set forth by the APIs application programming interfaces, while the computer aided metal processes executed in such computer environment are those of aided
i. observation: namely the receiv[ed] “parameters” (i.e. “promotional”, “environmental” etc.)
and “historical log” (i.e. “calendar events” with respect to “data size”) at Claims 1-2,5,11,12,13,16 and “check if the cumulative SLA of each of said API is affected by increasing request or data load based in the historical log of execution of the plurality of APIs” at dependent Claims 8,19,
ii. evaluation: “predicting” “future load on each of said APIs based on the number of resources required for each day”, “forecasting” “execution time required for each said API based on the prediction oof the future load on each of said API” at independent Claims 1,11,12 to arrive at a
iii. judgment to “optimize the number of resources required for each day based on the forecasting of time required for each said API”, “allocate one or more resources to an API based on the optimization of the number of resources” at independent Claims 1,11,12, “maintain the cumulative SLA when actual load increased based on the prediction of the future load” at dependent Claims 9,20, “minimize a combination of execution, run time, and traffic in the API based on the prediction and optimization made” at dependent Claims 10,21
However, MPEP 2106.04(a)(2) III ¶2 is clear that processes that include i. observations, ii. evaluations, and iii. judgments, set forth the abstract exception with MPEP 2106.04(a)(2) III C stating that: #1. Performing a mental process on a generic computer, # 2. Performing a mental process in a computer environment, and # 3. Using a computer as a tool to perform a mental process, do not preclude the claims from recting, describing or setting forth the abstract exception.
Thus here, there is a preponderance of legal evidence to show that the character of the claims as a whole is abstract, regardless of the computerized environment where they are executed.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This judicial exception is not integrated into a practical application because per Step 2A prong two, because the individual or combination of additional, computer-based elements are/is found to merely apply the already recited abstract exception, as tested per MPEP 2106.05(f), and/or narrow it to a technological environment or field of use, as tested per MPEP 2106.05(h), neither of which integrates said abstract exception into a practical application.
Here, the degree of automation or computerization identified at the prior step, does not to preclude the claims from reciting, describing or setting forth the abstract exception. Now, even when more granularly testing such computer related elements as additional, computer-based elements at Step 2A prong two, such computer components (i.e. “processor” / “edge processor”, coupled to” a “memory” and “one or more computing devices in a network” at independent Claims 1,11 and similarly at independent Claim 12, and the “neural network module” of Claims 3,4,14,15) represent mere invocation of computer components or machinery to perform tasks to receive, store, and transmit data [here “parameters” and “historical log”], which per MPEP 2106.05(f)(2) ¶1, does not integrate the abstract idea into a practical application. Also, when tested per MPEP 2106.05(f)(2)(iii), such additional elements merely monitor audit log data [here “parameters” and “historical log” (i.e. “calendar events”) “along with times taken for each API execution with respect to the data size provided for the API for execution”, and a checking of the cumulative API of each of said API is aggregate by increasing request or data load based in the historical log of execution of the plurality of APIs”] executed on a computer, which represent mere invocation of computers or machinery as tools that do not integrate the abstract exception into a practical application.
Similarly, recitation of “neural network module” “associated with the processor” “to forecast” “the execution time of each of said API” at dependent Claims 3,14 , and “by the neural network module” “generate a trained model” “to train the system for forecasting the execution time” at dependent Claims 4,15, represent examples of a mathematical algorithm being applied on a computer, which according to MPEP 2106.05(f)(2)(i) represents mere invocation of computers or machinery as a tool which does not integrate the abstract exception into a practical application.
Additionally, or alternatively, the level of automation or computerization, identified above at Claims 1-5,7-16,18-21, when tested per MPEP 2106.05(h) vi., can also be argued as narrowing of the abstract idea to a field of use or technological environment such as narrowing combination of collecting information (here “receiving” “parameters” and “historical log”) and analyzing it (here “predicting” and “forecasting”), to certain results of collection and analysis, related to a technological environment characterized here by the application programming interfaces “API” as recited throughout the claims and “CPU”, “memory”, “GPU utilization” as recited at Claims 2,13.
According to MPEP 2106.05(h) such narrowing of the abstract idea to a field of use or technological environment does not integrate the abstract idea into a practical application.
Thus, Examiner provided a preponderance of legal evidence showing that the automation or computerization elements above do not integrate the abstract idea into a practical application.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because Examiner follows MPEP 2106.05 II guidelines and carries over the above findings at MPEP 2106.05 (f) and/or (h) to submit that as shown above, the additional elements, merely apply the already recited abstract idea [MPEP 2106.05(f)] and/or narrow it to a field of use or technological environment [MPEP 2106.05(h)]. For these same reasons, said computer-based additional elements also do not provide significantly more than the abstract idea itself, in light of MPEP 2106.05(f) and/or (h) as sufficient option(s) for evidence without having to rely on the well understood routine and conventional test of MPEP 2106.05(d). Based on such legal evidence conferred by the MPEP 2106.05(f),(h) tests above, the Examiner submits that the additional computer-based elements do not provide significantly more without having to rely on the well-understood, routine and conventional test of MPEP 2106.05(d).
Yet, assuming in the arguendo, that further evidence would be required to demonstrate conventionality of the additional, computer-based elements, the Examiner would further point to MPEP 2106.05(d) to demonstrate that said additional elements remain well-understood, routine, conventional. In such case, Examiner would rely on the Original Specification as follows:
- Original Specification ¶ [0023] 4th sentence: “It will be appreciated by those skilled in the art that invention of such drawings includes the invention of electrical components, electronic components or circuitry commonly used to implement such components”.
- Original Specification ¶ [0042] reciting at high level of generality: “In an embodiment, the system may be configured to forecast, by a neural network module, the execution time of each API and is further configured to generate a trained model, by the neural network module, to train the system for forecasting the execution time”.
- Original Specification ¶ [0047] reciting at high level of generality: “FIG. 2A with reference to Fig.1, illustrates an exemplary representation of system (110) for facilitating scheduling of APIs, in accordance with an embodiment of the present disclosure. In an aspect, the system (110) may comprise one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (110). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like”.
- Original Specification ¶ [0051] reciting at high level of generality: “Fig.2B illustrates an exemplary representation (220) of the user equipment (UE) (108), in accordance with an embodiment of the present disclosure. In an aspect, the UE (108) may comprise an edge processor (222). The edge processor (222) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the edge processor(s) (222) may be configured to fetch and execute computer-readable instructions stored in a memory (224) of the UE (108). The memory (224) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (224) may comprise any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like”.
- Original Specification ¶ [0052] reciting at high level: “In an embodiment, the UE (108) may include an interface(s) 226. The interface(s) 206 may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, and the like. The interface(s) 206 may facilitate communication of the UE (108). Examples of such components include, but are not limited to, processing engine(s) 228 and a database (230)”.
- Original Specification ¶ [0053] reciting at high level of generality: “The processing engine(s) (228) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) (228). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) (228) may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (228) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (228). In such examples, the UE (108) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the UE (108) and the processing resource. In other examples, the processing engine(s) (228) may be implemented by electronic circuitry”.
- Original Specification ¶ [0054] reciting at high level of generality: “The processing engine (228) may include one or more engines selected from any of a data acquisition engine (232), a machine learning (ML) engine (234), and other engines (236)”.
All of this preponderance of legal and/or factual evidence demonstrate that the additional computer-based elements fail to provide anything significantly more.
In conclusion, Claims 1-5,7-16,18-21 although directed to statutory categories (here “system” and “user equipment” as machine at respective Claims 1-5, 7-10, and Claim 11 and “method” or process at Claims 12-16,18-21) they still recite, or at least set forth or describe the abstract idea (Step 2A prong one), with their additional, computer-based elements not integrating the abstract idea into a practical application (Step 2A prong 2) or providing significantly more than abstract idea (Step 2B). Therefore, Claims 1-5,7-16 and 18-21 are patent ineligible.
Claim Rejections - 35 USC § 102
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 is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1,11 and 12 are rejected under 35 U.S.C. 102(a)(1) based upon a public use or sale or other public availability of the invention as disclosed by:
Dave et al, US 20180331928 A1 hereinafter Dave. As per,
Claims 1,11,12 Dave teaches “A system for facilitating forecasting execution of a plurality of application programming interfaces (API), the system comprising: a processor coupled to one or more computing devices in a network, wherein the processor is further coupled with a memory, wherein said memory stores instructions which when executed by the processor causes the system to”: / “A user equipment for facilitating forecasting execution of a plurality of application programming interfaces (API), the UE comprising: an edge processor and a receiver, the edge processor coupled to one or more computing devices in a network, wherein the edge processor is further coupled with a memory, wherein said memory stores instructions which when executed by the edge processor causes the UE to”: / “A method for facilitating forecasting execution of a plurality of application programming interfaces (API)” (Dave ¶ [0015], ¶ [0031]-¶ [0052], ¶ [0053] 2nd sentence: one or more process blocks of Fig.4 may be performed by resource analysis platform 220. In some implementations, one or more process blocks of Fig.4 may be performed by another device or a group of devices separate or remote from resource analysis platform 220, such as client device 210), “the method comprising”:
- “receive a set of parameters from the one or more computing devices (104), the set of parameters associated with the plurality of APIs” (Dave Fig.4 step 410, ¶ [0054] 1st sentence: receiving information that identifies a resource utilization. For example, per ¶ [0059] the resource utilization of cloud computing resource 232 by client device 210 relate to a manner in which client device 210 is using cloud computing resource 232. For example, the information identify a quantity of cloud computing resources 232 client device 210 is using, an amount of cloud computing resources 232 that client device 210 is using, a rate at which client device 210 is using cloud computing resources 232, and/or the like. As specific examples, the information identify a quantity of database queries client device 210 requested cloud computing resource 232 to perform (e.g. during a time period), an amount of data cloud computing resource 232 is obtaining for client device 210, quantity of operations cloud computing resource 232 is performing concurrently for client device 210, quantity of API calls cloud computing resource 232 is performing for client device 210, and/or the like. ¶ [0036] 3rd sentence: cloud computing environment 230 include a group of computing resources 232 referred to collectively as computing resources 232 and individually as computing resource 232. Similar example at ¶ [0058]).
- “receive a historical log of execution of the plurality of APIs from a database, the historical log of execution of the plurality of APIs associated with the execution of the plurality of APIs”;
(Dave ¶ [0054] 1st, 3rd sentences: resource analysis platform 220 receive the information from cloud computing resource 232, periodically [or historically], according to a schedule, based on requesting the information, based on input from a user of client device 210 and/or resource analysis platform 220, and/or the like. ¶ [0059] 3rd sentence: As specific examples, the information identify a quantity of database queries client device 210 has requested cloud computing resource 232 to perform (e.g., during a time period). Also ¶ [0022] 1st sentence: The current score indicate whether the resource utilization is predicted to satisfy the threshold within a threshold amount of time, based on current and historical resource utilization, and/or the like).
- “determine, a number of resources required for each day based on the received set of parameters and the received historical log of execution of the plurality of APls”;
(Dave ¶ [0073]: resource analysis platform 220 determine current score using information related to a resource utilization. For example, resource analysis platform 220 determine a current score using information related to rate of resource utilization (e.g. amount of resource utilization per time period). resource analysis platform 220 determine current score using information related to an amount of cloud computing resource 232 that client device 210 has used in a particular time period (e.g. last 24 hours, during the current day of week or month of year, etc.
Dave ¶ [0022] 1st sentence: The current score indicate whether the resource utilization is predicted to satisfy the threshold within a threshold amount of time, based on a current resource utilization, based on a historical resource utilization, and/or the like)
- “predict, a future load on each said API based on the number of resources required for each day”; (Dave ¶ [0073] 3rd sentence: resource analysis platform 220 determine a current score using information related to an amount [or number] of cloud computing resource 232 that client device 210 has used in a particular time period (e.g., the last 24 hours, during the current day of the week or month of the year, etc.) and/or is using for a transaction or operation. ¶ [0075] 3rd sentence: a prediction of a future score may be the same as a current score, may be based on a current score (or a current score may be based on a prediction of a future score), and/or the like). - “forecast, an execution time required for each said API based on the prediction of the future load on each said APL”
(Dave Fig.1B, ¶ [0020] 1st sentence determine current score indicative of the resource utilization relative to a threshold (e.g. satisfying a threshold).
Dave ¶ [0023] Reference number 140 shows result of determining a current score for a resource utilization. For example, the resource analysis platform determine a current score of 100 for resource utilization in association with API calls, indicating that the set of client devices is predicted to satisfy a threshold of 20,000 API calls within a 24-hour period [equivalent to 1 API call PER 4.32 seconds]. The current score may be based on a quantity of API calls that the set of client devices has already performed and a rate at which the set of client devices is performing API calls. Additionally, or alternatively, the resource analysis platform may determine a current score of 90 for resource utilization associated with database queries, indicating a high likelihood that the set of client devices is predicted to satisfy a threshold of 5000 database queries within a 24-hour period. The current score may be based on a quantity of prior database queries that the set of client devices has already performed and a rate at which the set of client devices is performing database queries.
Dave ¶ [0075] 3rd sentence: a prediction of a future score may be the same as a current score, may be based on a current score (or a current score may be based on a prediction of a future score), and/or the like.
Dave ¶ [0080] 2nd-3rd sentences: resource analysis platform 220 predict additional resource utilization or reduced resource utilization based on information identifying an expected resource utilization. this way resource analysis platform 220 determine a more accurate prediction of a future score and can better manage resource utilization of various cloud computing resources 232. ¶ [0076] 2nd sentence: For example, resource analysis platform 220 predict a date and/or time at which client device 210 is expected to use a threshold amount of cloud computing resource 232 based on an amount of cloud computing resource 232 client device 210 has already used, a rate at which client device 210 is using cloud computing resource 232, and/or the like).
- “optimize the number of resources required for each day based on the forecasting of time required for each said API”; (Dave ¶ [0026] 4th sentence: resource analysis platform may configure the cloud computing resources to operate according to the set of recommendations... to optimize the resource utilization of the set of client devices, etc. For example, at ¶ [0073] 3rd-4th sentences: resource analysis platform 220 determine a current score using information related to an amount of cloud computing resource 232 that client device 210 used in the last 24 hours, during the current day etc.) and is using for a transaction or operation. Additionally…resource analysis platform 220 determine a current score using information identifying a threshold related to a resource utilization. ¶ [0023] 2nd sentence: For example, the resource analysis platform determine a current score of 100 for resource utilization in association with API calls, indicating the set of client devices is predicted to satisfy a threshold of 20000 API calls within 24-hour period
Dave ¶ [0075], ¶ [0089] 1st-2nd sentences: resource analysis platform 220 determine a priority [or optimization] based on a current score with which a recommendation is associated. For example, assuming that a first current score indicates a higher likelihood of a first resource utilization satisfying a threshold than a second current score associated with a second resource utilization, resource analysis platform 220 prioritize a 1st recommendation associated with the 1st current score higher than a second recommendation associated with the second current score.
Dave ¶ [0090] 2nd sentence: resource analysis platform 220 determine priority for recommendation related to a resource utilization of a particular type of cloud computing resource 232 (e.g. prioritize a resource utilization of a static cloud computing resource 232 higher than a resource utilization of dynamic cloud computing resource 232, or vice versa), based on a demand for various cloud computing resources 232 (e.g., prioritize a recommendation for cloud computing resource 232 that has a threshold demand from multiple client devices 210), based on a predicted impact of the recommendation (predicted impact on current score, whether the recommendation will prevent a resource utilization from satisfying a threshold, etc.), and/or the like).
- “allocate one or more resources to an API based on the optimization of the number of resources” (Dave ¶ [0072] 3rd sentence: current score indicate…, amount of cloud computing resource 232 allocated for a transaction or operation, and/or the like. For example, at ¶ [0083] 2nd-4th sentence: …recommendations…relate to…increasing [or allocating] a resource utilization, a rate of resource utilization, and/or the like. Additionally… a set of recommendations may relate to cloud computing resource 232. For example, resource analysis platform 220 may determine a recommendation to use [or allocated] a different cloud computing resource 232… a different combination of cloud computing resources 232 (e.g., a combination of cloud computing resources 232 that consumes less total cloud computing resources 232), and/or the like).
PNG
media_image4.png
534
433
media_image4.png
Greyscale
PNG
media_image5.png
528
439
media_image5.png
Greyscale
PNG
media_image6.png
525
524
media_image6.png
Greyscale
Dave Figs.1B-1D in support of rejection arguments
Rejections under 35 § U.S.C. 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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 2,13 are rejected under 35 U.S.C. 103 as being unpatentable over:
Dave as applied to claims 1,12 above in view of
Vichare et al, US 20230056042 A1 hereinafter Vichare. As per,
Claims 2,13 Dave / Vichare teaches all the limitations in claims 1,12 above
Dave does not exactly recite: “wherein the set of parameters includes combination of promotional, environmental features, data size, central processing unit (CPU), memory and graphical processing unit (GPU) utilization associated with the APIs in the queue” as claimed.
Vichare in analogous art of collecting analytics metrics of APIs teaches/suggests:
- “wherein the set of parameters includes combination of promotional, environmental features, data size, central processing unit (CPU), memory and graphical processing unit (GPU) utilization associated with the APIs in the queue”
(Vichare ¶ [0130] …collect workspace context information 604 using Application Programming Interfaces (APIs) provided by each context information source, such as: workspace utilization [or size] [of] telemetry [or data]…e.g. CPU, GPU, memory, storage,…and… environment concerning applications, …Net Promoter Score…. ¶ [0133] 1st sentence: Examples of E3 data 704 include… a process runtime, foreground or background state, AC/DC power consumption, I/O activity, utilization of CPU, GPU, memory, disk, network, etc.)
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention to have modified Dave’s “system” / “method” to have included Vichare’s teachings or suggestions in order to have more effectively determined which workspaces launched by users in an organization have customer experience and/or performance level metrics below a threshold value, and therefore should be prioritized for migration consideration. Within each workspace, systems and methods described herein may also select candidate workloads that are determined to benefit from being executed using cloud resources instead of local resources, and vice-versa, to improve the level of customer experience and/or performance, and/or to reduce or manage IT costs (Vichare ¶ [0125] in view of MPEP 2143 G and/or F). To this end Vichare would have generated a recommendation of which workspaces to migrate to or from a cloud service based, upon the selection of workloads and allocation of allocation of cloud resources (e.g., subscriptions or licenses) and client device resources available to the organization. In some cases, such a recommendation may increase the user experience and/or performance level while maintaining the total organization's costs of cloud and device resources under a defined budget (Vichare ¶ [0126] in view of MPEP 2143 G and/or F).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar API analytics field of endeavor. In such combination each element merely would have performed same collection and analytical function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Dave in view of Vichare, the to be combined elements would have fitted together like piece of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 3-4,7,14-15,18 are rejected under 35 U.S.C. 103 as being unpatentable over:
Dave as applied to respective claims 1,12 above in further view of:
Mohanty et al, US 20230124166 A1 hereinafter Mohanty. As per,
Claims 3,14 Dave teaches all the limitations in claims 1,12.
Dave does not explicitly “forecast, by a neural network module, the execution time of each said API, wherein the neural network module is associated with the processor”.
Mohanty however in analogous art of API analysis or forecasting teaches/suggests:
- “forecast, by a neural network module, the execution time of each said API, wherein the neural network module is associated with the processor”
(Mohanty ¶ [0028] 7th-8th sentences: by leveraging a large amount of historical data for each of a plurality of APIs 103 in normal situations and utilizing an unsupervised machine learning model, anomalous or outlier API behavior is predicted [or forecasted]. Using the historical dataset, the machine learning model learns responses and latency for each API 103 in normal situations and identifies anomalous behavior when the API metrics deviate from what has been learned as being normal. [0040] last sentence machine learning ML layer 231 (or 131) uses neural networks).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention to have further modified Dave system/method to have included Mohanty’s teachings or suggestions to more efficiently predicted anomalies and more adequately responded when such anomalies were predicted (Mohanty ¶ [0028] in view of MPEP 2143 G). These teaching or suggestions would also have the benefits in detecting and managing outages minimizing the impact on applications relying on API operations. (Mohanty ¶ [0035], ¶ [0076] in view of MPEP 2143 G). The predictability of such modification would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohanty ¶ [0102].
Further, the claimed invention is merely a combination of old elements in a similar API analysis or forecasting field of endeavor. In such combination each element merely would have performed same analytical and forecasting function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Dave in view of Mohanty, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
Claims 4,15. Dave / Mohanty teaches all the limitations in claims 3,12.
Dave does not explicitly: generate a trained model, by the/a neural network module, / to train the system / for forecasting the execution time as claimed.
Mohanty however in analogous art of AP analysis or forecasting teaches or suggests
- generate a trained model, by the/a neural network module, / to train the system / for forecasting the execution time (Mohanty ¶ [0040] 11th sentence: ML layer 231 (or 131) uses neural networks. ¶ [0031] 3rd sentence: anomaly prediction engine 130 includes machine learning layer 131 comprising anomaly prediction and training layers 132 and 133. ¶ [0033] 4th sentence: The historical API parameters relating to normal API operations are used to train the machine learning models used by the anomaly prediction layer 132 to learn which parameters correspond to normal operation of the respective APIs 103. Similarly, ¶ [0041] 2nd sentence: the machine learning model is trained using historical parameter data (e.g., historical API parameter data 236).
Rationales to have modified/combined Dave / Mohanty are above and reincorporated.
Claims 7,18 Dave teaches all the limitations in claims 1,12 above.
Dave does not explicitly recite: “wherein the historical log of execution of the plurality of APIs are based on calendar events along with times taken for each API execution with respect to the data size provided for the API for execution” as claimed.
Mohanty however in analogous art of AP analysis or forecasting teaches or suggests:
- “wherein the historical log of execution of the plurality of APIs are based on calendar events along with times taken for each API execution with respect to the data size provided for the API for execution” (Mohanty ¶ [0028] 7th-9th sentences: by leveraging a large amount [or size] of historical data for each of APIs 103 in normal situations and utilizing an unsupervised machine learning model, anomalous or outlier API behavior is predicted. Using the historical dataset, the machine learning model learns responses and latency for each API 103 in normal situations and identifies anomalous behavior when the API metrics deviate from what has been learned as being normal. The framework is also configured to redirect API requests to alternate (e.g., secondary) APIs upon determining that the state of a primary API is anomalous. ¶ [0033] API log collection layer 122 collects historical API parameters similar to those collected by the transaction data collection layer 121 such as, for example, API identifiers, API request time and/or date, API response time and/or date [or calendar], differences between request and response times, user information, error information and input/output (IO) parameters (e.g., throughput, IO operations per second (IOPS), latency). The historical API parameters may be collected from the APIs 103 and/or from applications used for monitoring API metrics, such as the monitoring tools mentioned herein, which log API and application activity. The historical API parameters relating to normal API operations (e.g. when an API is operating without any issues or problems) are stored in the historical API parameters repository 123 and input to the anomaly prediction engine 130 to be used as training data by training layer 133. The historical API parameters relating to normal API operations are used to train the machine learning models used by anomaly prediction layer 132 to learn which parameters correspond to normal operation of the respective APIs 103)
Rationales to have modified/combined Dave / Mohanty are above and reincorporated.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 5,16 are rejected under 35 U.S.C. 103 as being unpatentable over:
Dave/Vichare as applied to respective claims 2,13 above, and in further view of
Makie et al, US 20210336809 A1 hereinafter Makie. As per,
Claims 5,16 Dave/Vichare teaches all the limitations in claims 2 and 13 above. However,
Dave/Vichare does not: “determine a cumulative service-level agreement (SLA) of each API applicable for each computing device based on the received set of parameters”.
Makie in analogous API analysis “determine a cumulative service-level agreement (SLA) of each API applicable for each computing device based on the received set of parameters”.
(Makie ¶ [0211] 1st-3rd sentences: constant list 513 displays the value of the arbitrary constant (i.e. arbitrary constant 1 to 13) used in Formula 1 to 11 of the foregoing API usage fee calculation formula in the arbitrary constant 5131. The value of this arbitrary constant is defined for each application 300 in the contract of the API providing service, and is calculation parameter of the API usage fee. As a result of this kind of constant list 513 being displayed, since it is possible to clearly present the basis for calculation of the API usage fee to the API user, the API user can recognize the data processing resource amount and the value thereof required for the processing of each API, and also know the cost expended for retaining the service level (target latency).
Makie ¶ [0217] last sentence: Note that the term latency means the duration from the time that the API connection platform 200 received the API (request) sent from the API user (application 300) to the time [parameter] that the API connection platform 200 sends the response to that API, and the service level to be guaranteed is defined by setting the target latency).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have further modified Dave/Vichare’s “system” / “method” to have included
Makie’s teachings/suggestions in order to have improved the API reliability and customer satisfaction can be expected as a result of the transparency of the API provider's service (Makie ¶ [0211] 4th sentence in view of MPEP 2143 G).
Further, the claimed invention could have been viewed as a mere combination of old elements in a similar API analysis field of endeavor. In such combination each element would have merely performed the same analytical and determining function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Dave/Vichare in further view of Makie, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 8,19 are rejected under 35 U.S.C. 103 as being unpatentable over:
Dave / Mohanty as applied to respective claims 7,18 above in further view of
Bhorkar et al, US 20200371893 A1 hereinafter Bhorkar. As per,
Claims 8,19 Dave / Mohanty teaches all the limitations at claims 7,18 above.
Dave / Mohanty does not explicitly recite:
- “check if a cumulative SLA of each said API is affected by increasing request or data load based on the historical log of execution of the plurality of APIs” as claimed. However,
Bhorkar in analogous art of API analysis teaches or suggests:
- “check if a cumulative SLA of each said API is affected by increasing request or data load based on the historical log of execution of the plurality of APIs”
(Bhorkar ¶ [0040] 1st sentence measure latency for each API. ¶ [0044] 2nd sentence: service node 233-1 includes API database containing information regarding various supported APIs and service level agreements (SLAs). ¶ [0129] noting such information regarding use of services is generated including consumption history. ¶ [0044] 3rd sentence: each application has a latency requirement and SLA associated therewith; the SLA specifies quality of service (QoS) requirements. Fig.2I, ¶ [0068] 2nd, 4th sentences: In step 2902, a target latency is calculated, based on an applicable service level agreement (SLA) 2901 and a predetermined margin; the target may thus be expressed as (SLA-Margin). ¶ [0086] 2nd sentence: increasing workload consumes incremental resources from the common resource pool. ¶ [0080] 2nd sentence: the applications are sorted in increasing order of latency requirements. ¶ [0068] 4th sentence If the latency does not meet the target (step 2910), the optimization procedure may be repeated (step 2912) ).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Dave / Mohanty’s “system” / “method” to have further included Bhorkar’s teachings/suggestions in order to have provided better or more rigorous learning classifiers that would have automatically learned and performed a number of beneficial functions, including determining according to predetermined criteria which of the acquired cell sites will benefit a maximum number of subscribers and/or which of the acquired cell sites will add minimum value to the existing communication network coverage, etc. (Bhorkar ¶ [0131] 3rd senetcne in view of MPEP 2143 G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as articulated by Bhorkar ¶ [0091], ¶ [0139]
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar API analysis field of endeavor. In such combination each element would have merely performed the same analytical and monitoring, deterministic function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Dave / Mohanty in view of Bhorkar, the to be combined elements would have fitted together, like puzzle pieces in logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 9,20 are rejected under 35 U.S.C. 103 as being unpatentable over:
Dave/Mohanty/Bhorkar as applied to claims 8,19 above in further view of
Tootaghaj et al, US 11436054 B1 hereinafter Tootaghaj. As per,
Claims 9,20 Dave / Mohanty / Bhorkar teaches all the limitations in claims 8,19 above.
Dave / Mohanty / Bhorkar does not teach: “maintain the cumulative SLA when actual load increases based on the prediction of the future load” as claimed. However
Tootaghaj in analogous API calls analysis in distributive computing teaches/suggests:
- “maintain the cumulative SLA when actual load increases based on the prediction of the future load” (Tootaghaj Fig.2 steps 260->270->280, Fig.4, 440->460, column 9 line 65-column 10 line 2: to proactively provision sufficient number of replicas to maintain compliance with SLA, the future workload demands of an application are predicted ahead of time. column 11 lines 16-19: the goal is to dynamically scale the number of replicas to maintain a threshold (e.g., 90%) of the observed response times at or above a target value (reference value (Resref)). Fig.8 metric > corresponding SLA threshold 0 -> Yes -> scale the number of pods by a scaling factor. column 18 lines 20-35: At block 860 the number of pods is scaled by a scaling factor. the scaling factor is calculated as: Δ = ceil [current Replicas X current Metric Value / desired Metric Value]. the set of available metrics include: gateway_functions_seconds , representing how many seconds each API gateway function invocation takes to run over observed window size of Tr; gateway_function_invocation_total , representing a count of total number of API gateway function invocations during the window column 3 lines 9-13 and column 6 lines 53-55: scale up/down the number of replicas based on a target value of a performance metric and a measured value of the performance metric. For example at, at column 8 lines 24-26: If the system's latency (T)+2δ (where 2δ accounts for the auto-scaling startup latency) is larger than the target SLA latency, then the number of replicas may be scaled up).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have further modified Dave / Mohanty / Bhorkar’s “system” / “method” to have included Tootaghaj’s teachings or suggestions in order to have better monitored the service rates of the hardware accelerator and the host server, respectively, have sent the results to the workload predictor and an orchestrator to facilitate decisions regarding the optimal number of replicas (Tootaghaj column 6 lines 38-45 in view of MPEP 2143 G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as further articulated by Tootaghaj column 3 lines 40-46.
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar API analysis field of endeavor. In such combination each element merely would have performed the same analytical function and best practice function of maintaining service level agreements as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Dave / Mohanty / Bhorkar in further view of Tootaghaj, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 10,21 are rejected under 35 U.S.C. 103 as being unpatentable over:
Dave/Mohanty/Bhorkar/Tootaghaj as applied to claims 9,20 in further view of
Liao et al, US 20190392307 A1 hereinafter Liao. As per,
Claims 10,21 Dave / Mohanty / Bhorkar / Tootaghaj teaches all limitations in claims 9,20 above.
Bhorkar ¶ [0067] 1st 2nd sentences further recites: Based on current measurements of KPIs, performance metrics (e.g. available bandwidth and latencies at various nodes) are predicted; the predicted performance metrics are analyzed and compared with applicable SLAs and QoS requirements. If the measured or predicted latency does not meet a target latency, the optimization engines is triggered in an adaptive process. In this embodiment, optimization triggering is performed dynamically, in response to the analysis of changing KPIs.
Bhorkar ¶ [0072] minimize latencies of the applications/APIs, subject to various criteria including (1) resources used by the applications (e.g. bandwidth and/or computational resources) and (2) a target latency reflecting requirements based on a SLA. Furthermore, the network may be optimized with respect to a KPI in addition to the latency.
Bhorkar ¶ [0074] inputs 2101 to an optimization engine can include: (1) identifiers and locations of applications and jobs to be run; (2) priority of the application; (3) available bandwidth; (4) measurement delay; (5) available computational and storage resources; (6) local and real-time data relating to particular nodes; (7) auxiliary information, including information from sources outside the network, e.g. public websites and social networks. In step 2102, an objective function is defined that targets latency, a function of latency, or some other objective to satisfy requirements of the application (e.g. QoS requirements).
Dave/Mohanty/Bhorkar/Tootaghaj in combination however still fall short to teach:
- “minimize a combination of execution, run time and traffic in an API queue based on the prediction and an optimization made” as claimed. Nevertheless
Liao in analogous art of predicting API latency teaches or suggests:
- “minimize a combination of execution, run time and traffic in an API queue based on the prediction and an optimization made”
(Liao ¶ [0005] 3rd sentence for distributed cluster composed of multiple processors, how to reduce [or minimize] the impact of network delay on the time for distributed training of the deep neural network has now become a pressing issue in the field of deep neural network technology. To this end as stated by ¶ [0082] 2nd -3rd sentences: to minimize the training time of the deep neural network, it is necessary to find the minimum sum of the remaining run-time and data transmission time of all applications. Therefore, the management device may schedule multiple tasks to multiple cloud resource nodes according to equation, c=min (Σp=1.Aap) so as to perform distributed training of multiple subnetworks.
Liao ¶ [0085] Each task has its data stored on a fixed cloud resource node in the distributed cluster architecture. As such, the data transmission time depends on available bandwidth between the cloud resource node on which the data is stored and the cloud resource node on which the task is performed. Obviously, the minimization of the data transmission time is to select a cloud resource node with best available bandwidth to perform the task. ¶ [0086] The minimum data transmission time of a task t is estimated as follows: mt = min n∈NC (mtn + wn).
Liao ¶ [0087] Wherein, mt denotes the estimated minimum data transmission time of the task t, wn denotes the waiting time till the resource of the cloud resource node n becomes idle, and mtn is the data transmission time for the task t running on the cloud resource node n.
Liao ¶ [0088] If a cloud resource computing node is currently idle, a task may be immediately initiated thereon, and the waiting time is thus 0; if the cloud resource computing node is currently busy, i.e., performing a task, the waiting time is the remaining run-time for one of the tasks which is closest to its end.
Liao ¶ [0091] Furthermore, in order to reduce training time of the distributed deep neural network as much as possible, the management device needs to minimize the sum of the remaining run-time and data transmission time of each application, which may be represented as: ap = fp + min n∈NC ∑pt t=1 mt . ¶ [0092] In order to accelerate the distributed training of the neural network in the distributed cluster architecture, the sum of the remaining run-time and transmission time of all applications is to be minimized, as shown below: c=min (Σp=1.Aap) (5)
Liao ¶ [0093] To minimize the sum of the remaining run-time and data transmission time of all applications, tasks have to be properly scheduled to the cloud resource nodes.
Liao ¶ [0094] as shown in Fig.2, the above step of scheduling the multiple tasks to the multiple cloud resource nodes according to the equation c=min (Σp=1 Aap) may comprise:
¶ [0095] S201 mapping the scheduling of tasks into directed graph model.
¶ [0096] In order to properly schedule multiple tasks to fulfill the purpose as shown by equation (5), the management device may map the scheduling of the multiple tasks in the distributed cluster architecture into a directed graph model. The directed graph model is a model comprising nodes, and directed edges between the nodes.
¶ [0097] S202, transforming the directed graph model into a residual graph; ¶ [0098] S203, scheduling the multiple tasks to the multiple cloud resource nodes based on the preset scheduling method and the residual graph.
¶ [0099 to minimize the training time, the management device may further transform the directed graph model into a residual graph. Then, based on the preset scheduling method and the residual graph, the multiple tasks are scheduled to the multiple cloud resource nodes, so as to minimize the training time of the distributed deep neural network model).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have further modified Dave/Mohanty/Bhorkar/Tootaghaj’s “system/ method”
to have further included Liao’s teachings/suggestions in order to have more effectively address the pressing issue of how to reduce the impact of network delay (Liao ¶ [0005] in view of MPEP 2143 G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as further articulated by Liao ¶ [0048], ¶ [0054].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar API analysis field of endeavor. In such combination each element would have merely performed same analytical and optimization functions as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Dave/Mohanty/Bhorkar/Tootaghaj in further view of Liao, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
The following art is made of record and considered pertinent to Applicant's disclosure:
- Gamez Diaz et al, The role of limitations and SLAs in the API industry, InProceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering pp 1006-1014, Aug 12, 2019
- DE 202025101482 U1 teaching The intelligent API gateway according to Claim 1, where the predictive caching mechanism uses machine learning algorithms to predict API requests and proactively cache high-demand data, reducing latency and improving system performance.
- JP 2019101541 A teaching in parallel processing, speeding up can be realized more than serial processing simply by executing APIs with arbitrary execution orders in separate threads, but there is no waiting time, for example, and the longest estimated processing time It is also possible to speed up and reduce the number of threads by combining the API with one thread and scheduling the rest in serial processing
- US 11366660 B1 column 4 line 66-column 5 line 2, column 14 lines 39-41: The process of updating a latency estimation model with classification data that has been verified by a user allows for the model to have improved accuracy in making future estimates.
- US 20170329657 A1 ¶ [0077], the prediction may be associated with a series of future API requests, such as a predication associated with API requests that management platform 215 may receive at a same time each day, based on a recurring event, or the like.
- US 20150172206 A1 mid-¶ [0099] At step 1890 the process adjusts the commands/APIs stored in command queue 1770 by reducing/eliminating the last command or API based on the cloud entities that have already been created in the Passive Cloud Environment (step 1860) based on the replication policies.
- US 10178046 B1 noting at Fig.4 remaining quota as example of a historic log. Also see
= column 4 lines 22-31: an API product may be limited by a quota on the number of requests allowed. In this example, one API product may be made available with a low access limit, such as 1000 requests per day, for a low price, while another API product provides access to the same API services, but with a much higher access limit, for a higher price. In some embodiments, platform 102 provides tools for adding and configuring APIs, applications, and related policies. In some embodiments, platform 102 is deployed within the computing environment of backend service 116.
= column 11 lines 53-60 In some embodiments, at the expiration of the quota, the remaining amount of the quota allocation that has not been utilized or the amount of the quota allocation that has been utilized is reported. For example, this report may be utilized to better predict future quota allocation for a particular server and redistribute any unutilized allocation to other servers and/or users.
- US 20110167067 A1 ¶ [0019] 2nd sentence: Typically, an application is pre-programmed to define a particular service level in the application commands based on latency, throughput, and possibly reliability expected for the application commands
- US 20220035689 A1 ¶ [0084] 3rd-8th sentences: A subset of the high-level gateway operation policies may comprise a service level agreement (SLA) that defines performance requirements for the API. For example, such an SLA setting may include required availability of the gateway at which the API is executing to process calls to the API and successfully access data at the backend application the API services at any given time. This may be referred to herein as a call processing availability requirement. The SLA setting may be a percentage value of API calls received at the gateway that successfully act to access resources at the backend application the API services. APIs associated with more critical business tasks (e.g., processing online sale orders) may be associated with a higher SLA setting or call processing availability requirement than other APIs performing less critical business tasks (e.g., locating a store nearest a customer's current location). Setting a lower call processing availability requirement via a lower SLA percentage setting for less critical APIs may save resources or costs for cloud computing occupancy in an embodiment.
- US 20190149424 A1 ¶ [0110] In some cases, users, providers and stakeholders can define formal Service Level Agreements (SLA) that explicitly state criteria by which it is possible to determine whether an API is meeting its SLA. Depending on the SLA criteria, an API quality monitoring subsystem can use data and information derived from API test calls to determine automatically whether an API is meeting its SLA. Alternatively, the API quality monitoring subsystem can report data and information related to API performance to human users who can apply judgement to determine whether API is meeting its SLA. Furthermore, machine learning techniques can be applied to automate the process of determining whether an API meets qualitative criteria related to business judgement.
- US 11704229 B1 column 11 lines 46-52: For example, the test analysis engine 140 may identify involved services, their dependencies, and/or interaction requirements thereof (e.g., based on analyzing of service level agreements (SLAs)), and may obtain and analyze various API calls and/or responses between services, monitor service logs, identify errors and corruption based on the criteria defined by SLAs, etc.
- US 10284660 B1 teaching Tracing the execution of services in a service provider network
= column 10 lines 55-67: “A user may have selected or paid for a particular service level agreement (SLA) by which each API submitted by a client device is to be executed in less than a predetermined period of time (e.g., less than 100 milliseconds). That is, to the extent that an incoming API to the service provider network requires execution by multiple services 126, the time from the initial invocation of the first of such services 126 to the completion of the last of such services should be less than the prescribed SLA period of time. In other embodiments, the service provider has guaranteed that the APIs will be executed in less than the SLA period of time, and the service provider user does not select the period of time”.
= column11 lines 45-47: For purposes of illustrating the method depicted in FIG. 4, assume that the level L3 service 126c of Fig. 2 took much too long to execute and thereby caused the entire API data flow to exceed the defined SLA threshold.
- US 10983850 B1 Real-time application programming interface anomaly detection and mitigation, column 3 lines 33-42: The SLAs may define configurable criteria for dependency services (e.g., dependency APIs), such as acceptable data types, data ranges, data sources used to respond to an API call, and the like. For example, a configurable SLA may define the criteria for a string of characters used in an API response, allowing the API notification service to determine (e.g., based on service log information) whether an API response included a string of characters that complied with the criteria defined by the SLA.
- US 20090119673 A1 [0117] In step 1205, a service level agreement is created to define the service level requirements for each resource to be utilized by the application program
- US 20110302337 A1 ¶ [0027] Typically, an application is pre-programmed to define a particular service level of an application command based on latency, throughput, and possible reliability expected for the application command.
- US 20170123863 A1 ¶ [0058]1st sentence: A module instance can generate service level agreement (“SLA”) and service level objective (“SLO”) events, which can be processed by a performance event handler API.
- US 20170063645 A1 ¶ [0096] 2nd-3rd sentences: Each SLA metric may be defined as a metric with a specific SLA identifier at the monitoring API 330. A status may be updated at the monitoring API 330 each time, for example when SLA metrics, dependent metrics, dependency statuses and/or weights are modified. A specific set of internal alarms may be defined for updating metric status and dependent metrics.
- US 20080244607 A1 ¶ [0039] In step 250, the requirements broker 114 monitors the performance of the allocated resources and the service level requirements of each application program to insure that the performance of the allocated resources meets the service level requirements of each application program. Step 250 will be described in further detail hereinafter with reference to Fig.10.
- US 20150161051 A1 ¶ [0337] The performance management program 5112 collects the SLA information and the migration ability information set by the user at the time when each application program 4 is established, and registers the information in an SLA information column 51121 and a migration ability column 51125 of the performance management table 5112 (S1301).
¶ [0345] The cache management program 5113 collects the performance information of each application program 4, compares the collected performance information with the SLA information 51222, and determines whether or not the application program 4 of an SLA event violation disappears (S1404). ¶ [0348] The cache management program 5113 refers to the performance management table 5122, and compares the SLA information 51222 with the maximum request number 51223 for each application program 4 (S1501).
- US 20020152305 A1 mid-¶ [0031] Short term forecast analysis may include predicting workload for a given succeeding time unit (e.g., day, week, or month) based on historical load on the system. In one exemplary embodiment, short term forecast analysis may be employed by users to schedule maintenance windows without causing major interruptions to system performance. Long term analysis may include predicting overall trend line and growth pattern based on historical data (e.g., on a daily, weekly, or monthly basis). Long term analysis may be advantageously employed to help information management system (e.g., data center owners) to plan future equipment needs and to make purchase decisions so that new resources may be added before system performance suffers.
- US 20210256593 A1 ¶ [0048] last two sentences: resume information 14a contains histories of the execution APIs stored in list form. After each of the API executions, a history thereof is added to a bottom of an appropriate list.
- US 9081623 B1 Service resource allocation emphasis on Figs.3-4 and associated text
- US 20210006496 A1 teaching Application Programing Interface API Gateway Cluster Control Method and API Gateway Cluster
- US 20220058064 A1 emphasis on Fig. 13 below and
= ¶ [0133] The application release test processing unit 116 is a process for verification to finally determine a unique API which has the best performance, in which traffic is increased to all of the plurality of APIs connected to the application resources of the application execution environment 3 to measure the performance of the APIs, and the traffic is controlled to gradually increase for an API with the best measurement value. The performance referred to here is an index that can quantitatively measure the performance of the API linked with the application to be developed.
= ¶ [0137] Next, in Step S604, the application release test processing unit 116 compares each measurement value of the performance of the candidate API saved in the memory in Step S603, and transmits a control command to the API gateway 32 such that an API with higher performance has more traffic than the other APIs.
For example, if the measured performance of an API (A), which is one of the n APIs listed in the candidate API list, is the best, the traffic in the (n−1) APIs other than the API (A) is reduced by c %, and the traffic in the API (A) is increased by (n−1)×a %.
= ¶ [0138] Next, in Step S605, the application release test processing unit 116 confirms whether the API with the best performance has been uniquely determined. When an API has been uniquely determined, it means that the traffic increased from the API gateway 32 to one of the multiple APIs listed in the candidate API list has reached 100%. In other words, 100% of traffic is flowed from the API gateway 32 to one API. If the API has been uniquely determined (Step S605, YES), the process shifts to Step S606, but if the API has not been uniquely determined (Step S605, NO), the process returns to Step S604.
PNG
media_image7.png
611
576
media_image7.png
Greyscale
Fig.13 of US 20220058064 A1
- US 20180062944 A1 API Rate limiting for cloud native application
= ¶ [0039] Fig.7 is a flow diagram of steps executed in connection with a technique for API rate limiting for cloud native applications based on host hardware regulations and application SLA guarantees in accordance with embodiments described herein. Referring to Fig.7, in step 130, an API call for a particular cloud application executing on a server in a server cloud is received at the API rate limiting function. In step 132, an SLA profile for the application is accessed to determine SLA guarantees associated with the application. In step 134, current and historical resource utilization for the server, SLA guarantees for the remaining applications executing on the server, and the current load on each application are examined to determine how the API call should be handled. For example, in one embodiment, assuming a memory constraint of 2 GB, a determination is made as to how much memory on the server as a whole is being used, how much is being used by the present application, by other applications, and what is the SLA memory guarantee for the application. Assuming the application is consuming 1 GB, but is guaranteed 2 GB, and the server has 4 GB free out of total 64 GB RAM, and other applications on the server are Tier II, more API calls are allowed by the application because there is spare (unused) memory. In step 136, the API call is handled (e.g., forwarded, queued, or dropped) in accordance with the determination made in step 134.
- US 20160188656 A1 ¶ [0281] last sentence: User portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.
- US 20230073760 A1 ¶ [0042] the runtime estimator 112 may generate the test schedule 124 to minimize the overall runtime of the test suite 122. In the example of the testing system 110 shown in Fig.1B, the runtime estimator 112 may send the test schedule 124 to the test engine 120 via an application programming interface (API) gateway 155 (e.g., a representational state transfer (REST) API gateway, a simple object access protocol (SOAP) API gateway, and/or the like). One example strategy to minimize the overall runtime of the test suite 122 may be to schedule tests with longer expected [or predicted] runtimes for execution before tests with shorter expected [or predicted] runtimes. The overall runtime of the test suite 122 may be minimized by distributing [or trafficking] the tests with the longer expected runtimes for execution across the parallelized test environment 126. FIG. 3B depicts a table 350 illustrating examples of test schedules and the corresponding savings in time, in accordance with some example embodiments.
- US 20120173513 A1 ¶ [0052] last sentence: Caching resulted in optimized plans with their estimate costs enables a reduction [or minizining] in the number of QTC API calls to O(n2m), and also significantly improves the running time.
- US 20180205666 A1 ¶ [0048] For improved understanding of such a classification structure according to an embodiment, exemplary classification may be represented as follows:
PNG
media_image8.png
476
250
media_image8.png
Greyscale
PNG
media_image9.png
178
252
media_image9.png
Greyscale
¶ [0049] in the above-detailed example, the classification may describe an application (“App1”) that in general has light resource usage, but CPU resource usage increases between 12 noon and 5 pm on weekdays and networking resource usage spikes high between 8 pm and 10 pm on weekdays (e.g. because it is a social network app for a television network). Also, the storage resource usage remains relatively constant (e.g. in a substantially steady state with no notable spikes or dips in resource usage. Thus, the above example may be thought of as including information relating to triggers or events upon which the time variant resource usage depends
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 OCTAVIAN ROTARU whose telephone number is (571)270-7950. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number (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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Octavian Rotaru/
Primary Examiner, Art Unit 3624 A
September 19th, 2026
1 MPEP 2106.04(a) last ¶: to submit that …examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible, if a claim limitation(s) is determined to fall within multiple groupings…
2 MPEP 2106.04(a) last ¶: to submit that …examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible, if a claim limitation(s) is determined to fall within multiple groupings…
Prosecution Insights