Prosecution Insights
Last updated: April 19, 2026
Application No. 18/320,405

AUTOMATIC SCALING OF MICROSERVICES APPLICATIONS

Non-Final OA §102§103
Filed
May 19, 2023
Examiner
KIM, SISLEY NAHYUN
Art Unit
2196
Tech Center
2100 — Computer Architecture & Software
Assignee
Juniper Networks Inc.
OA Round
5 (Non-Final)
89%
Grant Probability
Favorable
5-6
OA Rounds
2y 9m
To Grant
99%
With Interview

Examiner Intelligence

Grants 89% — above average
89%
Career Allow Rate
590 granted / 665 resolved
+33.7% vs TC avg
Strong +17% interview lift
Without
With
+16.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
42 currently pending
Career history
707
Total Applications
across all art units

Statute-Specific Performance

§101
9.1%
-30.9% vs TC avg
§103
49.6%
+9.6% vs TC avg
§102
26.1%
-13.9% vs TC avg
§112
7.2%
-32.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 665 resolved cases

Office Action

§102 §103
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 . Continued Examination A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 25 November 2025 has been entered. Response to Arguments Applicant’s arguments with respect to claims 1-11 and 13-21 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection. Claim Rejections - 35 USC § 102 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. 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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1-3, 5, 6, 8, 9, 11, 15, 18, 20, and 21 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Katsaros et al. (US 2017/0288982). Regarding claim 1, Katsaros discloses A device, comprising: a memory (FIG. 8 main memory 804, static memory 806, mass storage 816); and one or more processors to (FIG. 8 processor 802): access information identifying one or more tasks (paragraph [0027]: A Key Performance Indicator (KPI) of a cloud application 102 is a measurable parameter 302 that represents one aspect of the cloud application's 102 effectiveness and performance under variable operational conditions and workload; paragraph [0043]: The .DLL/.SO component 406 provides performance monitoring functionality) to be executed by a software application, the software application being associated with a plurality of modular applications (paragraph [0025]: The cloud application 102 is composed of one or more cloud application instances 104), each of the plurality of modular applications configured to perform a respective functionality of the software application (paragraph [0025]: Each cloud application instance 104 is composed of one or more cloud services, each of which may be a microservice … A cloud application instance 104 is the result of each of these cloud services 106, 108, 110 working together, and a cloud application 102 is the result of each cloud service type 116, 118, 120 working together); determine an amount of resources for the software application (paragraph [0029]: In a cloud computing environment, it is possible to vary the number of compute resources available to a cloud application 102. To do this and still ensure that the cloud application stays within its acceptable performance range 306, two regions, referred to as “Adaption Regions,” 312, 314 may be defined. When the cloud application's 102 performance moves into one of these regions 312, 314, the cloud application 102 may take steps to adjust the compute resources available and maintain the cloud application's 102 KPIs within the acceptable range 306) based on resource utilization to execute the one or more tasks (paragraph [0027]: A Key Performance Indicator (KPI) of a cloud application 102 is a measurable parameter 302 that represents one aspect of the cloud application's 102 effectiveness and performance under variable operational conditions and workload); and allocate a particular number of instances of one of the plurality of modular applications (paragraph [0046]: The scope of the adaption available at a Complete Service Instance Monitor 425 includes the ability to add or remove additional virtual machines to the set already executing the cloud service type (e.g., 116, 118, or 120); paragraph [0055]: upon the current value of the KPI being outside of an acceptable range 306 (or being within an adaptation region 312, 314), a first API is invoked to request a cloud service instance monitor 404 to adapt the cloud service instance 402 back into an acceptable KPI range 306; paragraph [0117]: In Example 36, the subject matter of Example 35 optionally includes wherein adapting includes at least one of the cloud service monitor and the application monitor initializing an additional virtual machine within the platform to execute a new cloud service instance) based on determining the amount of resources (paragraph [0029]: In a cloud computing environment, it is possible to vary the number of compute resources available to a cloud application 102. To do this and still ensure that the cloud application stays within its acceptable performance range 306, two regions, referred to as “Adaption Regions,” 312, 314 may be defined. When the cloud application's 102 performance moves into one of these regions 312, 314, the cloud application 102 may take steps to adjust the compute resources available and maintain the cloud application's 102 KPIs within the acceptable range 306). Regarding claim 8 referring to claim 1, Katsaros discloses A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by one or more processors of a first device, cause the one or more processors to (paragraph [0077]: The storage device 816 may include a machine-readable medium 822 on which is stored one or more sets of data structures or instructions 824 … The instructions 824 may also reside, completely or at least partially, within the main memory 804, within static memory 806, or within the hardware processor 802 during execution thereof by the machine 800). Regarding claim 15 referring to claim 1, Katsaros discloses A method comprising: ... (See the rejection for claim 1). Regarding claim 2, Katsaros discloses where the software application is a microservices application (paragraph [0025]: Each cloud application instance 104 is composed of one or more cloud services, each of which may be a microservice). Regarding claim 3, Katsaros discloses where the one or more processors are further to: increase a number of the plurality of instances (paragraph [0046]: The scope of the adaption available at a Complete Service Instance Monitor 425 includes the ability to add or remove additional virtual machines to the set already executing the cloud service type (e.g., 116, 118, or 120); paragraph [0055]: upon the current value of the KPI being outside of an acceptable range 306 (or being within an adaptation region 312, 314), a first API is invoked to request a cloud service instance monitor 404 to adapt the cloud service instance 402 back into an acceptable KPI range 306; paragraph [0117]: In Example 36, the subject matter of Example 35 optionally includes wherein adapting includes at least one of the cloud service monitor and the application monitor initializing an additional virtual machine within the platform to execute a new cloud service instance) of the one of the plurality of modular applications (paragraph [0025]: Each cloud application instance 104 is composed of one or more cloud services, each of which may be a microservice … A cloud application instance 104 is the result of each of these cloud services 106, 108, 110 working together). Regarding claim 5, Katsaros discloses where the one or more processors are further to: allocate the plurality of instances of the one of the plurality of modular applications (paragraph [0046]: The scope of the adaption available at a Complete Service Instance Monitor 425 includes the ability to add or remove additional virtual machines to the set already executing the cloud service type (e.g., 116, 118, or 120); paragraph [0055]: upon the current value of the KPI being outside of an acceptable range 306 (or being within an adaptation region 312, 314), a first API is invoked to request a cloud service instance monitor 404 to adapt the cloud service instance 402 back into an acceptable KPI range 306; paragraph [0117]: In Example 36, the subject matter of Example 35 optionally includes wherein adapting includes at least one of the cloud service monitor and the application monitor initializing an additional virtual machine within the platform to execute a new cloud service instance) based on a service level agreement (paragraph [0028]: The SLA to which the cloud application 102 should comply may be translated into a series of smaller SLAs (“sub-SLA”), each sub-SLA relating to a cloud service 106, 108, 110 of a cloud application instance 104. Thus, the cloud application 102 SLA may be decomposed and mapped to each of the cloud services 106, 108, 110 that comprise a cloud application instance 104. Each sub-SLA may be managed independently; thus the service and the defined KPIs may be assured for each cloud service 106, 108, 110 of the cloud application instance 104 as well as for the overall SLA for the cloud application 102). Regarding claim 6, Katsaros discloses where the one or more processors are further to: determine a quantity of the instances of the one of the plurality of modular applications (paragraph [0046]: The scope of the adaption available at a Complete Service Instance Monitor 425 includes the ability to add or remove additional virtual machines to the set already executing the cloud service type (e.g., 116, 118, or 120); paragraph [0055]: upon the current value of the KPI being outside of an acceptable range 306 (or being within an adaptation region 312, 314), a first API is invoked to request a cloud service instance monitor 404 to adapt the cloud service instance 402 back into an acceptable KPI range 306; paragraph [0117]: In Example 36, the subject matter of Example 35 optionally includes wherein adapting includes at least one of the cloud service monitor and the application monitor initializing an additional virtual machine within the platform to execute a new cloud service instance) based on one or more resources (paragraph [0029]: In a cloud computing environment, it is possible to vary the number of compute resources available to a cloud application 102. To do this and still ensure that the cloud application stays within its acceptable performance range 306, two regions, referred to as “Adaption Regions,” 312, 314 may be defined. When the cloud application's 102 performance moves into one of these regions 312, 314, the cloud application 102 may take steps to adjust the compute resources available and maintain the cloud application's 102 KPIs within the acceptable range 306). Regarding claims 9 and 18, Katsaros discloses where each of the plurality of modular applications is configured to perform a respective functionality of the software application (paragraph [0025]: Each cloud application instance 104 is composed of one or more cloud services, each of which may be a microservice … A cloud application instance 104 is the result of each of these cloud services 106, 108, 110 working together, and a cloud application 102 is the result of each cloud service type 116, 118, 120 working together). Regarding claim 11, Lawson discloses where the one or more processors (FIG. 8 processor 802) are further to: provision a network device to execute the software application (paragraph [0025]: a cloud application 102 built on a three-tier model (e.g., a front end providing a user interface, a middle layer providing custom business logic, and a back end providing data storage and retrieval) may include three cloud services: a web server 106, a business logic layer 108, and a data store 110). Regarding claims 20 and 21, Lawson discloses where each of the plurality of modular applications is independently deployable (paragraph [0024]: Elasticity is improved with microservices because each microservice type may scale independently of the others). Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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 Claims 4, 7, 13, 14, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Katsaros et al. (US 2017/0288982) in view of Kumar (US 2018/0069806, hereinafter Kumar). Regarding claims 4, 13, and 17, Katsaros does not teach where the one or more processors are further to: selectively adjust the plurality of instances of the one of the plurality of modular applications to increase resource utilization. Kumar teaches where the one or more processors are further to: selectively adjust the plurality of instances of the one of the plurality of modular applications to increase resource utilization (paragraph [0065]: In the step 552, the resource allocation manager resets the cost of all edges of each microservice identified to MIC_min. At a next step 554, the resource allocation manager changes the status of the identified INACTIVE microservices (if any) to ACTIVE. At a step 556, the resource allocation manager then ascertains that dependency information is up to date in both MSD graph and microservice graph. In this way, the resource allocation manager supports the scale up of microservices. In embodiments, the resource allocation manager does not launch new microservices in the group when scale-up is needed but rather manages the existing, unused (e.g., dormant) microservices of the group in an efficient way; paragraph [0069]: The inactive microservice also relinquishes resources (e.g., file handlers, locks, database connections etc.), it has for processing requests). It would have been obvious to one of ordinary skill in the art at the time the claimed invention was effectively filed to modify the teaching of Katsaros by resetting the cost of all edges of each microservice identified to MIC_min to support the scale up (i.e., increasing resource utilization) of microservices for processing requests upon changing the status of the identified INACTIVE microservices to ACTIVE of Kumar. The motivation would have been to manage the existing, unused (e.g., dormant) microservices of the group in an efficient (Kumar paragraph [0065]). Regarding claim 7, Katsaros does not teach where the one or more processors are further to: allocate the plurality of instances of the one of the plurality of modular applications in a linear or an exponential manner. Kumar teaches where the one or more processors are further to: allocate the plurality of instances of the one of the plurality of modular applications in a linear or an exponential manner (paragraph [0065]: In the step 552, the resource allocation manager resets the cost of all edges of each microservice identified to MIC_min. At a next step 554, the resource allocation manager changes the status of the identified INACTIVE microservices (if any) to ACTIVE. At a step 556, the resource allocation manager then ascertains that dependency information is up to date in both MSD graph and microservice graph. In this way, the resource allocation manager supports the scale up of microservices. In embodiments, the resource allocation manager does not launch new microservices in the group when scale-up is needed but rather manages the existing, unused (e.g., dormant) microservices of the group in an efficient way; paragraph [0069]: The inactive microservice also relinquishes resources (e.g., file handlers, locks, database connections etc.), it has for processing requests). It would have been obvious to one of ordinary skill in the art at the time the claimed invention was effectively filed to modify the teaching of Katsaros by resetting the cost of all edges of each microservice identified to MIC_min to support the scale up of microservices for processing requests upon changing the status of the identified INACTIVE microservices not being able to process the requests to ACTIVE (i.e., increasing the number of instances in a linear or an exponential manner) of Kumar. The motivation would have been to manage the existing, unused (e.g., dormant) microservices of the group in an efficient (Kumar paragraph [0065]). Regarding claims 14, and 16, Katsaros does not teach where the one or more instructions, to allocate the plurality of instances of the one of the plurality of modular applications, cause the one or more processors to: increase a number of the plurality of instances of the one of the plurality of modular applications; and determine an execution time based on the increase number of the plurality of instances of the one of the plurality of modular applications. Kumar teaches where the one or more instructions, to allocate the plurality of instances of the one of the plurality of modular applications, cause the one or more processors to: increase a number of the plurality of instances of the one of the plurality of modular applications; and determine an execution time based on the increase number of the plurality of instances of the one of the plurality of modular applications (paragraph [0065]: In the step 552, the resource allocation manager resets the cost of all edges of each microservice identified to MIC_min. At a next step 554, the resource allocation manager changes the status of the identified INACTIVE microservices (if any) to ACTIVE. At a step 556, the resource allocation manager then ascertains that dependency information is up to date in both MSD graph and microservice graph. In this way, the resource allocation manager supports the scale up of microservices. In embodiments, the resource allocation manager does not launch new microservices in the group when scale-up is needed but rather manages the existing, unused (e.g., dormant) microservices of the group in an efficient way; paragraph [0069]: The inactive microservice also relinquishes resources (e.g., file handlers, locks, database connections etc.), it has for processing requests), it has for processing requests). Execution time will be implicitly determined upon processing more requests. It would have been obvious to one of ordinary skill in the art at the time the claimed invention was effectively filed to modify the teaching of Katsaros by resetting the cost of all edges of each microservice identified to MIC_min to support the scale up of microservices for processing requests (i.e., increasing the number of instances) upon changing the status of the identified INACTIVE microservices to ACTIVE of Kumar. The motivation would have been to manage the existing, unused (e.g., dormant) microservices of the group in an efficient (Kumar paragraph [0065]). Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Katsaros et al. (US 2017/0288982) in view of Ming (US 2015/0262114, hereinafter Ming). Regarding claim 10, Katsaros does not teach where the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: determine a percentage completion associated with the one or more tasks; and determine the execution time based on the percentage completion. Ming teaches where the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: determine a percentage completion associated with the one or more tasks; and determine the execution time based on the percentage completion (paragraph [0049]: The performance module 120 may generate the reports based on a comparison of estimated timing information for jobs (e.g., the timing information communicated to customers at a time a job work order is created) and actual timing information associated with the actual completion of the jobs. For example, the performance module 130 may generate reports that provide: an average amount of time to complete jobs of a particular type during a given time period (e.g., a day, five days, a month, etc.), a number of jobs of a particular type actually completed during the given time period, a total number of jobs actually completed during the given time period, a number or percentage of jobs actually completed within a threshold period time (e.g., five minutes) after the estimated duration of time to complete a job of a particular type expires, a number or percentage of jobs actually started before or within a threshold period time of an estimated start time (e.g., the estimated start time communicated to a customer), a number or percentage of jobs completed before or within a threshold period of time of the estimated complete time (e.g., the estimated complete time communicated to a customer). It is contemplated that other reports may be generated by the performance module 130 as well). It would have been obvious to one of ordinary skill in the art at the time the claimed invention was effectively filed to modify the teaching of Katsaros by generating reports that provide an average amount of time to complete jobs of a particular type during a given time period (e.g., a day, five days, a month, etc.), a number of jobs of a particular type actually completed during the given time period, a total number of jobs actually completed during the given time period, a number or percentage of jobs actually completed within a threshold period time (e.g., five minutes) after the estimated duration of time to complete a job of a particular type expires, a number or percentage of jobs actually started before or within a threshold period time of an estimated start time (e.g., the estimated start time communicated to a customer), a number or percentage of jobs completed before or within a threshold period of time of the estimated complete time (e.g., the estimated complete time communicated to a customer) of Ming. The motivation would have been to help an entity operating one or more service facilities manage the timing of service jobs across work stations (Ming paragraph [0022]). Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Katsaros et al. (US 2017/0288982) in view of Chung et al. (US 2018/0113742, hereinafter Chung). Regarding claim 19, Katsaros does not disclose further comprising: implementing a machine learning technique to determine an execution time associated with execution of the one or more tasks. Chung discloses further comprising: implementing a machine learning technique to determine an execution time associated with execution of the one or more tasks (paragraph [0003]: The tuning server may include mathematical tuning algorithm (e.g., function minimization) and/or the machine learning methods (e.g., artificial neural network). The tuning server explores the resource allocation space and improves configuration suggested through time progresses with many job executions. The tuning /learning is based on historic data collected from previously executed jobs (job characteristics, resource used, performance measurements) and its tuning /learning mechanism. The output of the tuning server (which is a configuration) then used by the job scheduler to run the job and render guaranteed services for users. The job-associated information is then collected and stored into the historical data for future references). It would have been obvious to one of ordinary skill in the art at the time the claimed invention was effectively filed to modify the teaching of Katsaros by performing tuning /learning based on historic data collected from previously executed jobs (job characteristics, resource used, performance measurements) and its tuning /learning mechanism of Chung. The motivation would have been to an optimized configuration for a projected amount of resources based on machine learning (Chung paragraph [0001]). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y. Blair can be reached on (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /SISLEY KIM/ Primary Examiner, Art Unit 2196 1/19/2026
Read full office action

Prosecution Timeline

May 19, 2023
Application Filed
Jan 09, 2024
Non-Final Rejection — §102, §103
Mar 06, 2024
Interview Requested
Mar 15, 2024
Applicant Interview (Telephonic)
Mar 15, 2024
Examiner Interview Summary
Apr 02, 2024
Response Filed
Apr 30, 2024
Final Rejection — §102, §103
Jun 14, 2024
Interview Requested
Jun 25, 2024
Examiner Interview Summary
Jun 25, 2024
Applicant Interview (Telephonic)
Jul 03, 2024
Response after Non-Final Action
Jul 24, 2024
Response after Non-Final Action
Aug 02, 2024
Request for Continued Examination
Aug 10, 2024
Response after Non-Final Action
Feb 08, 2025
Non-Final Rejection — §102, §103
Apr 21, 2025
Interview Requested
Apr 30, 2025
Examiner Interview Summary
Apr 30, 2025
Applicant Interview (Telephonic)
Jul 11, 2025
Response Filed
Sep 01, 2025
Final Rejection — §102, §103
Oct 20, 2025
Interview Requested
Oct 30, 2025
Applicant Interview (Telephonic)
Oct 30, 2025
Examiner Interview Summary
Oct 31, 2025
Response after Non-Final Action
Nov 25, 2025
Request for Continued Examination
Dec 06, 2025
Response after Non-Final Action
Jan 21, 2026
Non-Final Rejection — §102, §103
Mar 24, 2026
Interview Requested
Apr 07, 2026
Examiner Interview Summary
Apr 07, 2026
Applicant Interview (Telephonic)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602254
JOB NEGOTIATION FOR WORKFLOW AUTOMATION TASKS
2y 5m to grant Granted Apr 14, 2026
Patent 12602260
COMPUTER-BASED PROVISIONING OF CLOUD RESOURCES
2y 5m to grant Granted Apr 14, 2026
Patent 12591474
BATCH SCHEDULING FUNCTION CALLS OF A TRANSACTIONAL APPLICATION PROGRAMMING INTERFACE (API) PROTOCOL
2y 5m to grant Granted Mar 31, 2026
Patent 12585507
LOAD TESTING AND PERFORMANCE BENCHMARKING FOR LARGE LANGUAGE MODELS USING A CLOUD COMPUTING PLATFORM
2y 5m to grant Granted Mar 24, 2026
Patent 12578994
SYSTEMS AND METHODS FOR TRANSITIONING COMPUTING DEVICES BETWEEN OPERATING STATES
2y 5m to grant Granted Mar 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
89%
Grant Probability
99%
With Interview (+16.9%)
2y 9m
Median Time to Grant
High
PTA Risk
Based on 665 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month