CTNF 18/630,343 CTNF 99025 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 AIA Claim s 3-4, 6-7, 10-11, 13-14 and 15-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Regarding claim 3, the claim recites the limitation “receive a second indicator of a second workload of a third microservice of the first microservice-based application…” . There is insufficient antecedent basis for this limitation in the claim. “the first microservice-based application” the independent claim only introduces “a micro-service based application” Regarding claims 10 and 14 , the claims recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar rationale. Regarding claim 6, the claim recites the limitation “determine, based on the second indicator of the second workload and a second mapping of workloads of the plurality of entry microservices”. There is insufficient antecedent basis for this limitation in the claim “the plurality of entry microservices”. Regarding claims 13 and 20 , the claims recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar rationale. Regarding claim 15, the claim recites the limitation “receiving an indicator of a workload of an entry microservice of the microservice-based application”. There is insufficient antecedent basis for this limitation in the claim. “the microservice-based application” is not introduce Regarding claims 4, 7, 11, 14 and 16-20 dependent claims inherit the deficiencies of the respective parent claim. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-12-aia AIA (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. 07-15-03-aia AIA Claim s 1-2 and 8-9 are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Biswas ((US 20230231933 A1 ) . Regarding claim 1 , Biswas teaches: A system comprising: ([0024] FIG. 13 conceptually illustrates an electronic system with which some embodiments of the invention are implemented. See also [0091]) a first execution environment of a first microservice of a microservice-based application, the first execution environment comprising . ([0036] The service chain 135 is a set of services deployed in a specific topology. In the Kubernetes context of some embodiments, each of these services is implemented as a “micro-service” and is deployed as a set of one or more Pods. However, it should be understood that in other embodiments the service chain may be implemented as a set of virtual machines (VMs) or other data compute nodes (DCNs) rather than as Pods in a Kubernetes cluster. In this case, a front-end load balancer can still be configured to measure incoming traffic and provide this data to a scaler module (executing, e.g., on a different VM) that performs similar auto-scaling operations outside of the Kubernetes context. See also [0037]) a first memory storing executable program code; and a first one or more processing units to execute the executable program code to cause the first execution environment to . ([0093] From these various memory units, the processing unit(s) 1310 retrieve instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments.[0094] The read-only-memory (ROM) 1330 stores static data and instructions that are needed by the processing unit(s) 1310 and other modules of the electronic system. The permanent storage device 1335, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 1300 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 1335.) receive an indicator of a workload of a second microservice of the microservice-based application; determine, based on the indicator of the workload, an estimated future workload of the first microservice . ([0040] The metrics receiver 210 receives traffic metrics, including those indicating the amount of requests received at the first service in the service chain. In some embodiments, the metrics receiver 210 receives API schema information for the front-end load balancer from the ingress controller and uses this API information to retrieve the traffic metrics from the load balancer controller via API calls. The specific metrics received can include a total number of requests, requests per unit time (e.g., requests per second or millisecond), etc. As these metrics are retrieved, the metrics receiver 210 provides the metrics to the auto-scaling and deployment module 215. [0072] As shown, the process 700 begins by receiving (at 705 ) traffic measurements at the ingress of a service chain, corresponding to the traffic at the first service in the service chain. As described, the front-end load balancer of some embodiments generates these metrics, which are retrievable by the scaler module (e.g., using API calls in the load balancer schema). The received metrics provide a measure of incoming traffic to the first service. This may be measured in an absolute number of requests, a rate of requests (e.g., requests per second), a latency measure (which can be assumed to scale linearly with the request rate, or other metrics.[0073] The scaler is then able to use these received metrics to scale each of the services in the service chain. The scaler determines, for each service, the expected traffic to reach that service (based on the scaling factor) and whether the current deployment for the service will have adequate capacity to handle that expected traffic. If the current deployment is inadequate, the scaler initiates deployment of one or more additional instances; if the current deployment should be reduced, the scaler initiates deletion of one or more existing instances. See also [0082]) and re-allocate computing resources to the first microservice based on the estimated future workload . ([0041] The auto-scaling and deployment module 215 uses the scaling factors computed by the modeler 205 to determine, in real-time, whether any of the services in the service chain need to be scaled (e.g., either instantiation of additional Pods or removal of Pods) based on the traffic metrics. The capacity of each Pod is specified for each service (the capacity can vary between services) for one or more metrics (e.g., requests per unit time) and provided to the auto-scaling and deployment module 215 (e.g., as an administrator-provided variable or based on observation). The current value for this metric (as received from the load balancer controller and multiplied by the scaling factor for a given service) is divided by the Pod capacity for the service to determine the number of Pods that will be required for the service. If the actual number of Pods is less than the required number of Pods, then the auto-scaling and deployment module 215 manages the deployment of additional Pods for the service. In this manner, if a large increase in traffic is detected at the load balancer, all of the services can be scaled up to meet this demand prior to the receipt of all of those requests at the services. On the other hand, if the actual number of Pods deployed is greater than the required amount for the service, the auto-scaling and deployment module 215 manages the deletion of one or more Pods for the service. In different embodiments, the auto-scaling and deployment module 215 either handles the deployment/deletion operations directly or provides the necessary instructions to a Kubernetes control plane module that handles these operations for the cluster. The operations of the auto-scaling and deployment module 215 to predictively auto-scale the services of a service chain will be described in detail below by reference to FIG. 7. [0071] Specifically, FIG. 8 conceptually illustrates an example of a service chain 800 as deployed. The service chain 800 includes a first service (A) for which two Pods are instantiated, a second service (B) for which three Pods are instantiated, a third service (C) for which two Pods are deployed, and a fourth service (D) for which a single Pod is deployed. This figure also shows the direct path coefficients for each of the connections in the service chain 800. Service A receives data messages directly from the front-end load balancer 805 then forwards 40% of its traffic to Service B and 50% of its traffic to Service C. Service B sends 80% of its traffic to Service D and Service C sends 90% of its traffic to Service D. See also [0077]) Regarding claim 2 , Biswas teaches: A system according to Claim 1, a third execution environment of a third microservice of the microservice-based application, the third execution environment comprising: a third memory storing third executable program code; and a third one or more processing units to execute the third executable program code to cause the third execution environment to:. ([0037] In this example, the service chain 135 includes three services 140-150. The first service 140 receives traffic directly from the load balancer data plane 110 (potentially via Kubernetes ingress modules) and sends portions of this traffic (after performing processing) to both the second service 145 and the third service 150. The second service 145 also sends a portion of its traffic (after it has performed its processing) to the third service 150. The first service 140 is implemented using two Pods, the second service 145 is implemented using three Pods, and the third service 150 is implemented using a single Pod. Each Pod is allocated a particular amount of resources (e.g., memory and processing capability) that enable the Pod to perform its respective service on a particular number of requests in a given time period (e.g., requests/second).) receive the indicator of the workload ([0040] The metrics receiver 210 receives traffic metrics, including those indicating the amount of requests received at the first service in the service chain. In some embodiments, the metrics receiver 210 receives API schema information for the front-end load balancer from the ingress controller and uses this API information to retrieve the traffic metrics from the load balancer controller via API calls. The specific metrics received can include a total number of requests, requests per unit time (e.g., requests per second or millisecond), etc. As these metrics are retrieved, the metrics receiver 210 provides the metrics to the auto-scaling and deployment module 215.) determine, based on the indicator of the workload, an estimated future workload of the third microservice, where the estimated future workload of the first microservice is not equal to the estimated future workload of the third microservice . ([0082] The process 700 then determines (at 730 ) whether to scale the selected service. If the service should be scaled, the process determines (at 735 ) the scaling action for the selected service. As discussed, some embodiments scale the services predictively so that the additional instances are deployed prior to the existing instances for the service being overloaded by the incoming traffic. In the example, shown in the table 1000 of FIG. 10 , Services A and B should be scaled by adding 2 Pods for each service while Services C and D should be scaled by adding 1 Pod for each service. Owing to (1) the different per-instance capacity of different applications (in this case, the services) and (2) the different expected traffic flow reaching each different applications based on the computed scaling factors, in many cases different numbers of instances will be required due to the same change in ingress traffic.) and re-allocate computing resources to the third microservice based on the estimated future workload of the third microservice . ([0041] The auto-scaling and deployment module 215 uses the scaling factors computed by the modeler 205 to determine, in real-time, whether any of the services in the service chain need to be scaled (e.g., either instantiation of additional Pods or removal of Pods) based on the traffic metrics. The capacity of each Pod is specified for each service (the capacity can vary between services) for one or more metrics (e.g., requests per unit time) and provided to the auto-scaling and deployment module 215 (e.g., as an administrator-provided variable or based on observation). The current value for this metric (as received from the load balancer controller and multiplied by the scaling factor for a given service) is divided by the Pod capacity for the service to determine the number of Pods that will be required for the service. If the actual number of Pods is less than the required number of Pods, then the auto-scaling and deployment module 215 manages the deployment of additional Pods for the service. In this manner, if a large increase in traffic is detected at the load balancer, all of the services can be scaled up to meet this demand prior to the receipt of all of those requests at the services. On the other hand, if the actual number of Pods deployed is greater than the required amount for the service, the auto-scaling and deployment module 215 manages the deletion of one or more Pods for the service. In different embodiments, the auto-scaling and deployment module 215 either handles the deployment/deletion operations directly or provides the necessary instructions to a Kubernetes control plane module that handles these operations for the cluster. The operations of the auto-scaling and deployment module 215 to predictively auto-scale the services of a service chain will be described in detail below by reference to FIG. 7. [0071] Specifically, FIG. 8 conceptually illustrates an example of a service chain 800 as deployed. The service chain 800 includes a first service (A) for which two Pods are instantiated, a second service (B) for which three Pods are instantiated, a third service (C) for which two Pods are deployed, and a fourth service (D) for which a single Pod is deployed. This figure also shows the direct path coefficients for each of the connections in the service chain 800. Service A receives data messages directly from the front-end load balancer 805 then forwards 40% of its traffic to Service B and 50% of its traffic to Service C. Service B sends 80% of its traffic to Service D and Service C sends 90% of its traffic to Service D. See also [0077]) Regarding claim 8 , A teaches the elements of claim 1 as outlined above. A also teaches: A method comprising: receiving . (Claim 1. A method comprising:) Regarding claim 9 , the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale . Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA Claim s 3-7 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over Biswas (US 20230231933 A1 )in view of Mulpuri (US 20230176920 A1) . Regarding claim 3, Biswas does not appear to explicitly teach: A system according to Claim 1, the first one or more processing units to execute the executable program code to cause the system to: receive a second indicator of a second workload of a third microservice of the first microservice-based application, wherein the determination of the estimated future workload of the first microservice is based on the indicator of the workload and the second indicator of the second workload . However, Mulpuri teaches: [0043] In one embodiment, software applications containing one or more components are deployed in nodes 160 of computing infrastructure 130 . Examples of such software include, but are not limited to, data processing (e.g., batch processing, stream processing, extract-transform-load (ETL)) applications, Internet of things (IoT) services, mobile applications, and web applications. In the following description, the term “components” may refer to components of a single software application or multiple software applications. The components may also represent infrastructure components such as virtual machines (VMs), operating systems, etc. that form the basis for the deployment and execution of the software applications. It should be noted that some of the deployed components may be in a “executing” state where the software instructions are loaded into memory and being executed by processors in nodes 160 , while some of the deployed components may be in a “ready for execution” state where the software instructions are merely loaded into memory. [0053] In step 240 , performance manager 150 receives data indicating an entry workload expected to be received in a future duration at one or more entry components (of the software applications). The data may be provided by an administrator of computing infrastructure 130 using one of end-user systems 110 . The term “future duration” used herein refers to any duration after the time instance at which the data is provided/received. [0054] In step 260 , performance manager 150 estimates by traversing the component graph, a component workload, corresponding to the entry workload, expected to be received in the future duration at a specific component. In other words, performance manager 150 estimates the proportion of the expected entry workload that will be received by the specific component in the future duration.[0055] According to an aspect, performance manager 150 estimates the component workload by first identifying, by traversing the component graph, a set of paths connecting the one or more entry components to the specific component in the component graph, each path of the set of paths containing a respective set of edges. Performance manager 150 then computes the component workload for the specific component based on the expected entry workload and a respective set of branch probabilities associated with the identified respective set of edges.[0092] Referring again to FIG. 5, upon receiving at time instance 550, performance manager 150 receives data indicating the entry workload (EW8) expected to be received in the future block duration t8, performance manager 150 first estimates the component workload at a specific component (such as C9) corresponding to the expected entry load EW8. [0093] In one embodiment, performance manager 150 first identifies, by traversing component graph 400, a set of paths connecting the one or more entry components to the specific component in the component graph, each path of the set of paths containing a respective set of edges. For example, for EW8 where there are transactions of all types, performance manager 150 may identify the set of paths to be {E1->C1->C9, E1->C3->C9, E2->C2->C9, E2->C4->C9 } with each arrow (->) indicating the sequence/order of invocation of the components. Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Biswas and Mulpuri before them, to include Mulpuri’s component workload estimation in Biswas’s predictive service chain scaling system. One would be motivated to make such combination to more accurately estimate downstream service workload by using workload data from one or more entry or interior components as taught in by Mulpuri in paragraphs [0054-0056] and [0093-0092]. Regarding claim 4, Biswas teaches: A system according to Claim 3, a third execution environment of a third microservice of the microservice-based application, the third execution environment comprising: a third memory storing third executable program code; and a third one or more processing units to execute the third executable program code to cause the third execution environment to: receive the indicator of the workload and the second indicator of the second workload . ([0040] The metrics receiver 210 receives traffic metrics, including those indicating the amount of requests received at the first service in the service chain. In some embodiments, the metrics receiver 210 receives API schema information for the front-end load balancer from the ingress controller and uses this API information to retrieve the traffic metrics from the load balancer controller via API calls. The specific metrics received can include a total number of requests, requests per unit time (e.g., requests per second or millisecond), etc. As these metrics are retrieved, the metrics receiver 210 provides the metrics to the auto-scaling and deployment module 215.) determine, based on the indicator of the workload and the second indicator of the second workload, an estimated future workload of the third microservice, where the estimated future workload of the first microservice is not equal to the estimated future workload of the third microservice; and ([0082] The process 700 then determines (at 730 ) whether to scale the selected service. If the service should be scaled, the process determines (at 735 ) the scaling action for the selected service. As discussed, some embodiments scale the services predictively so that the additional instances are deployed prior to the existing instances for the service being overloaded by the incoming traffic. In the example, shown in the table 1000 of FIG. 10 , Services A and B should be scaled by adding 2 Pods for each service while Services C and D should be scaled by adding 1 Pod for each service. Owing to (1) the different per-instance capacity of different applications (in this case, the services) and (2) the different expected traffic flow reaching each different applications based on the computed scaling factors, in many cases different numbers of instances will be required due to the same change in ingress traffic.) re-allocate computing resources to the third microservice based on the estimated future workload of the third microservice. ([0041] The auto-scaling and deployment module 215 uses the scaling factors computed by the modeler 205 to determine, in real-time, whether any of the services in the service chain need to be scaled (e.g., either instantiation of additional Pods or removal of Pods) based on the traffic metrics. The capacity of each Pod is specified for each service (the capacity can vary between services) for one or more metrics (e.g., requests per unit time) and provided to the auto-scaling and deployment module 215 (e.g., as an administrator-provided variable or based on observation). The current value for this metric (as received from the load balancer controller and multiplied by the scaling factor for a given service) is divided by the Pod capacity for the service to determine the number of Pods that will be required for the service. If the actual number of Pods is less than the required number of Pods, then the auto-scaling and deployment module 215 manages the deployment of additional Pods for the service. In this manner, if a large increase in traffic is detected at the load balancer, all of the services can be scaled up to meet this demand prior to the receipt of all of those requests at the services. On the other hand, if the actual number of Pods deployed is greater than the required amount for the service, the auto-scaling and deployment module 215 manages the deletion of one or more Pods for the service. In different embodiments, the auto-scaling and deployment module 215 either handles the deployment/deletion operations directly or provides the necessary instructions to a Kubernetes control plane module that handles these operations for the cluster. The operations of the auto-scaling and deployment module 215 to predictively auto-scale the services of a service chain will be described in detail below by reference to FIG. 7. [0071] Specifically, FIG. 8 conceptually illustrates an example of a service chain 800 as deployed. The service chain 800 includes a first service (A) for which two Pods are instantiated, a second service (B) for which three Pods are instantiated, a third service (C) for which two Pods are deployed, and a fourth service (D) for which a single Pod is deployed. This figure also shows the direct path coefficients for each of the connections in the service chain 800. Service A receives data messages directly from the front-end load balancer 805 then forwards 40% of its traffic to Service B and 50% of its traffic to Service C. Service B sends 80% of its traffic to Service D and Service C sends 90% of its traffic to Service D. See also [0077]) Regarding claim 5, Mulpuri teaches: A system according to Claim 1, wherein determination of the workload is based on a mapping of workloads of a plurality of entry microservices to a workload of the first microservice . ([0049] In step 220, performance manager 150 constructs a component graph for the components deployed in computing infrastructure 130. The component graph indicates for each component, a corresponding subset of components that are invoked by the component and a corresponding distribution of component workload received at a component to its subset of components. The component graph may contain one or more entry components that directly receive (and are considered to be directly invoked by) user requests received from end-user systems 110, and one or more internal components that are in turn invoked by the entry components (or other internal components) during the processing of the received user requests. [0071] 5. Component Graph[0072] FIG. 4 illustrates a component graph indicating the invocation of components deployed in a computing infrastructure in one embodiment. Component graph 400 illustrates the invocation of components of online travel application deployed in computing infrastructure 130 . In particular, components E 1 -E 3 correspond to instances 311 P- 311 Q and 312 P of FIG. 3 B, while components C 1 -C 12 correspond to instances 321 P- 321 Q, 322 P- 322 Q, 323 P, 331 P-Q, 332 P, 324 P- 324 Q and 333 P- 333 Q of FIG. 3 B respectively.[0073] E1, E2 and E3 represent entry components that directly receive (and are considered to be directly invoked by) user requests received from end-user systems 110 .) Refer to claim 3 for the motivation to combine. Regarding claim 6, Biswas teaches: A system according to Claim 5, the first one or more processing units to execute the executable program code to cause the first execution environment to: receive a second indicator of a second workload of the second microservice of the microservice-based application . ([0040] The metrics receiver 210 receives traffic metrics, including those indicating the amount of requests received at the first service in the service chain. In some embodiments, the metrics receiver 210 receives API schema information for the front-end load balancer from the ingress controller and uses this API information to retrieve the traffic metrics from the load balancer controller via API calls. The specific metrics received can include a total number of requests, requests per unit time (e.g., requests per second or millisecond), etc. As these metrics are retrieved, the metrics receiver 210 provides the metrics to the auto-scaling and deployment module 215.) determine, based on the second indicator of the second workload and a second mapping of workloads of the plurality of entry microservices to workloads of the plurality of interior microservices, a second estimated future workload of the first microservice; and. ([0082] The process 700 then determines (at 730 ) whether to scale the selected service. If the service should be scaled, the process determines (at 735 ) the scaling action for the selected service. As discussed, some embodiments scale the services predictively so that the additional instances are deployed prior to the existing instances for the service being overloaded by the incoming traffic. In the example, shown in the table 1000 of FIG. 10 , Services A and B should be scaled by adding 2 Pods for each service while Services C and D should be scaled by adding 1 Pod for each service. Owing to (1) the different per-instance capacity of different applications (in this case, the services) and (2) the different expected traffic flow reaching each different applications based on the computed scaling factors, in many cases different numbers of instances will be required due to the same change in ingress traffic.) re-allocate computing resources to the first microservice based on the second estimated future workload . ([0041] The auto-scaling and deployment module 215 uses the scaling factors computed by the modeler 205 to determine, in real-time, whether any of the services in the service chain need to be scaled (e.g., either instantiation of additional Pods or removal of Pods) based on the traffic metrics. The capacity of each Pod is specified for each service (the capacity can vary between services) for one or more metrics (e.g., requests per unit time) and provided to the auto-scaling and deployment module 215 (e.g., as an administrator-provided variable or based on observation). The current value for this metric (as received from the load balancer controller and multiplied by the scaling factor for a given service) is divided by the Pod capacity for the service to determine the number of Pods that will be required for the service. If the actual number of Pods is less than the required number of Pods, then the auto-scaling and deployment module 215 manages the deployment of additional Pods for the service. In this manner, if a large increase in traffic is detected at the load balancer, all of the services can be scaled up to meet this demand prior to the receipt of all of those requests at the services. On the other hand, if the actual number of Pods deployed is greater than the required amount for the service, the auto-scaling and deployment module 215 manages the deletion of one or more Pods for the service. In different embodiments, the auto-scaling and deployment module 215 either handles the deployment/deletion operations directly or provides the necessary instructions to a Kubernetes control plane module that handles these operations for the cluster. The operations of the auto-scaling and deployment module 215 to predictively auto-scale the services of a service chain will be described in detail below by reference to FIG. 7. [0071] Specifically, FIG. 8 conceptually illustrates an example of a service chain 800 as deployed. The service chain 800 includes a first service (A) for which two Pods are instantiated, a second service (B) for which three Pods are instantiated, a third service (C) for which two Pods are deployed, and a fourth service (D) for which a single Pod is deployed. This figure also shows the direct path coefficients for each of the connections in the service chain 800. Service A receives data messages directly from the front-end load balancer 805 then forwards 40% of its traffic to Service B and 50% of its traffic to Service C. Service B sends 80% of its traffic to Service D and Service C sends 90% of its traffic to Service D. See also [0077]) Regarding claim 7, Biswas teaches: A system according to Claim 6, wherein re-allocation of computing resources to the first microservice based on the estimated future workload comprises increasing of the computing resources, and wherein re-allocation of computing resources to the first microservice based on the second estimated future workload comprises decreasing of the computing resources . (In this manner, if a large increase in traffic is detected at the load balancer, all of the services can be scaled up to meet this demand prior to the receipt of all of those requests at the services. On the other hand, if the actual number of Pods deployed is greater than the required amount for the service, the auto-scaling and deployment module 215 manages the deletion of one or more Pods for the service. In different embodiments, the auto-scaling and deployment module 215 either handles the deployment/deletion operations directly or provides the necessary instructions to a Kubernetes control plane module that handles these operations for the cluster. The operations of the auto-scaling and deployment module 215 to predictively auto-scale the services of a service chain will be described in detail below by reference to FIG. 7. [0070] FIG. 7 conceptually illustrates a process 700 of some embodiments for determining whether scaling of services in a service chain is required based on traffic expected to arrive at those services and initiating that scaling if needed. In some embodiments, the process 700 is performed by a scaler module (e.g., the auto-scaling and deployment module 215 of the scaler shown in FIG. 2 ). In some embodiments, the process 700 is performed at regular intervals or as metrics are retrieved from the front-end load balancer. The process 700 will be described by reference to FIGS. 8 - 12 , which illustrate examples of scaling the services in a service chain.[0071] Specifically, FIG. 8 conceptually illustrates an example of a service chain 800 as deployed. The service chain 800 includes a first service (A) for which two Pods are instantiated, a second service (B) for which three Pods are instantiated, a third service (C) for which two Pods are deployed, and a fourth service (D) for which a single Pod is deployed. This figure also shows the direct path coefficients for each of the connections in the service chain 800 . Service A receives data messages directly from the front-end load balancer 805 then forwards 40% of its traffic to Service B and 50% of its traffic to Service C. Service B sends 80% of its traffic to Service D and Service C sends 90% of its traffic to Service D.[0072] As shown, the process 700 begins by receiving (at 705 ) traffic measurements at the ingress of a service chain, corresponding to the traffic at the first service in the service chain. As described, the front-end load balancer of some embodiments generates these metrics, which are retrievable by the scaler module (e.g., using API calls in the load balancer schema). The received metrics provide a measure of incoming traffic to the first service. This may be measured in an absolute number of requests, a rate of requests (e.g., requests per second), a latency measure (which can be assumed to scale linearly with the request rate, or other metrics.[0073] The scaler is then able to use these received metrics to scale each of the services in the service chain. The scaler determines, for each service, the expected traffic to reach that service (based on the scaling factor) and whether the current deployment for the service will have adequate capacity to handle that expected traffic. If the current deployment is inadequate, the scaler initiates deployment of one or more additional instances; if the current deployment should be reduced, the scaler initiates deletion of one or more existing instances.) Regarding claim 10 , the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale. Regarding claim 11 , the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale. Regarding claim 12 , the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale. Regarding claim 13 , the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale. Regarding claim 14 , the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale. Regarding claim 15 , Biswas teaches: A method comprising : (Claim 1. A method comprising:) receiving an indicator of a workload of an entry microservice of the microservice-based application ; ([0040] The metrics receiver 210 receives traffic metrics, including those indicating the amount of requests received at the first service in the service chain. In some embodiments, the metrics receiver 210 receives API schema information for the front-end load balancer from the ingress controller and uses this API information to retrieve the traffic metrics from the load balancer controller via API calls. The specific metrics received can include a total number of requests, requests per unit time (e.g., requests per second or millisecond), etc. As these metrics are retrieved, the metrics receiver 210 provides the metrics to the auto-scaling and deployment module 215. [0072] As shown, the process 700 begins by receiving (at 705 ) traffic measurements at the ingress of a service chain, corresponding to the traffic at the first service in the service chain. As described, the front-end load balancer of some embodiments generates these metrics, which are retrievable by the scaler module (e.g., using API calls in the load balancer schema). The received metrics provide a measure of incoming traffic to the first service. This may be measured in an absolute number of requests, a rate of requests (e.g., requests per second), a latency measure (which can be assumed to scale linearly with the request rate, or other metrics.[0073] The scaler is then able to use these received metrics to scale each of the services in the service chain. The scaler determines, for each service, the expected traffic to reach that service (based on the scaling factor) and whether the current deployment for the service will have adequate capacity to handle that expected traffic. If the current deployment is inadequate, the scaler initiates deployment of one or more additional instances; if the current deployment should be reduced, the scaler initiates deletion of one or more existing instances.) determining, based on the indicator of the workload, an estimated future workload of a first microservice of the microservice-based application; and ([0082] The process 700 then determines (at 730 ) whether to scale the selected service. If the service should be scaled, the process determines (at 735 ) the scaling action for the selected service. As discussed, some embodiments scale the services predictively so that the additional instances are deployed prior to the existing instances for the service being overloaded by the incoming traffic. In the example, shown in the table 1000 of FIG. 10 , Services A and B should be scaled by adding 2 Pods for each service while Services C and D should be scaled by adding 1 Pod for each service. Owing to (1) the different per-instance capacity of different applications (in this case, the services) and (2) the different expected traffic flow reaching each different applications based on the computed scaling factors, in many cases different numbers of instances will be required due to the same change in ingress traffic.) Biswas does not appear to explicitly teach: transmitting the estimated future workload to a first execution environment of the first microservice . However, Mulpuri teaches: ([0092] Referring again to FIG. 5, upon receiving at time instance 550, performance manager 150 receives data indicating the entry workload (EW8) expected to be received in the future block duration t8, performance manager 150 first estimates the component workload at a specific component (such as C9) corresponding to the expected entry load EW8.[0093] In one embodiment, performance manager 150 first identifies, by traversing component graph 400, a set of paths connecting the one or more entry components to the specific component in the component graph, each path of the set of paths containing a respective set of edges. For example, for EW8 where there are transactions of all types, performance manager 150 may identify the set of paths to be {E1->C1->C9, E1->C3->C9, E2->C2->C9, E2->C4->C9 } with each arrow (->) indicating the sequence/order of invocation of the components. [0094] Each identified path may correspond to a respective transaction type. As such, for a single path (e.g.,, E1->C1->C9) corresponding to a transaction type (Txn_Search_Hotel), the number of transaction instances of the transaction type as specified in the expected future workload (e.g. 2000) may be multiplied by the set of branch probabilities (in table 680) associated with the set of edges in the single path to determine the number of transaction instances expected to be received at the specific component. [0110] Workload estimator 770 receives (via path 121) data indicating an entry workload expected in a future duration, accesses a component graph (400) generated by topology generator 750 and estimates a component workload based on the entry workload and a set of branch probabilities determined by traversing the component graph, as explained in the above sections.) Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Biswas and Mulpuri before them, to include Mulpuri’s workload estimator that forwards or estimates a component workload and provides the estimated workload to another system component for resource allocation. This would have improve Biswas’s scaling system by enabling the expected workload to be communicated to the environment or module for resource allocation. Regarding claim 16 , Biswas teaches: A method according to Claim 15, further comprising: determining, based on the indicator of the workload, an estimated future workload of a second microservice of the microservice-based application, where the estimated future workload of the first microservice is not equal to the estimated future workload of the second microservice; and ([0082] The process 700 then determines (at 730 ) whether to scale the selected service. If the service should be scaled, the process determines (at 735 ) the scaling action for the selected service. As discussed, some embodiments scale the services predictively so that the additional instances are deployed prior to the existing instances for the service being overloaded by the incoming traffic. In the example, shown in the table 1000 of FIG. 10 , Services A and B should be scaled by adding 2 Pods for each service while Services C and D should be scaled by adding 1 Pod for each service. Owing to (1) the different per-instance capacity of different applications (in this case, the services) and (2) the different expected traffic flow reaching each different applications based on the computed scaling factors, in many cases different numbers of instances will be required due to the same change in ingress traffic.) Biswas does not appear to explicitly teach: transmitting the estimated future workload of the second microservice to a second execution environment of the second microservice . However, Mulpuri teaches: ([0092] Referring again to FIG. 5, upon receiving at time instance 550, performance manager 150 receives data indicating the entry workload (EW8) expected to be received in the future block duration t8, performance manager 150 first estimates the component workload at a specific component (such as C9) corresponding to the expected entry load EW8.[0093] In one embodiment, performance manager 150 first identifies, by traversing component graph 400, a set of paths connecting the one or more entry components to the specific component in the component graph, each path of the set of paths containing a respective set of edges. For example, for EW8 where there are transactions of all types, performance manager 150 may identify the set of paths to be {E1->C1->C9, E1->C3->C9, E2->C2->C9, E2->C4->C9 } with each arrow (->) indicating the sequence/order of invocation of the components. [0094] Each identified path may correspond to a respective transaction type. As such, for a single path (e.g.,, E1->C1->C9) corresponding to a transaction type (Txn_Search_Hotel), the number of transaction instances of the transaction type as specified in the expected future workload (e.g. 2000) may be multiplied by the set of branch probabilities (in table 680) associated with the set of edges in the single path to determine the number of transaction instances expected to be received at the specific component. [0110] Workload estimator 770 receives (via path 121) data indicating an entry workload expected in a future duration, accesses a component graph (400) generated by topology generator 750 and estimates a component workload based on the entry workload and a set of branch probabilities determined by traversing the component graph, as explained in the above sections.) Same motivation as claim 15. Regarding claim 17 , the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale. Regarding claim 18 , Biswas teaches: A method according to Claim 17, further comprising: determining, based on the indicator of the workload and the second indicator of the second workload, an estimated future workload of a second microservice of the microservice-based application, where the estimated future workload of the first microservice is not equal to the estimated future workload of the second microservice; and ([0082] The process 700 then determines (at 730 ) whether to scale the selected service. If the service should be scaled, the process determines (at 735 ) the scaling action for the selected service. As discussed, some embodiments scale the services predictively so that the additional instances are deployed prior to the existing instances for the service being overloaded by the incoming traffic. In the example, shown in the table 1000 of FIG. 10 , Services A and B should be scaled by adding 2 Pods for each service while Services C and D should be scaled by adding 1 Pod for each service. Owing to (1) the different per-instance capacity of different applications (in this case, the services) and (2) the different expected traffic flow reaching each different applications based on the computed scaling factors, in many cases different numbers of instances will be required due to the same change in ingress traffic.) Biswas does not appear to explicitly teach: transmitting the estimated future workload of the second microservice to a second execution environment of the second microservice. However, Mulpuri teaches: ([0092] Referring again to FIG. 5, upon receiving at time instance 550, performance manager 150 receives data indicating the entry workload (EW8) expected to be received in the future block duration t8, performance manager 150 first estimates the component workload at a specific component (such as C9) corresponding to the expected entry load EW8.[0093] In one embodiment, performance manager 150 first identifies, by traversing component graph 400, a set of paths connecting the one or more entry components to the specific component in the component graph, each path of the set of paths containing a respective set of edges. For example, for EW8 where there are transactions of all types, performance manager 150 may identify the set of paths to be {E1->C1->C9, E1->C3->C9, E2->C2->C9, E2->C4->C9 } with each arrow (->) indicating the sequence/order of invocation of the components. [0094] Each identified path may correspond to a respective transaction type. As such, for a single path (e.g.,, E1->C1->C9) corresponding to a transaction type (Txn_Search_Hotel), the number of transaction instances of the transaction type as specified in the expected future workload (e.g. 2000) may be multiplied by the set of branch probabilities (in table 680) associated with the set of edges in the single path to determine the number of transaction instances expected to be received at the specific component. [0110] Workload estimator 770 receives (via path 121) data indicating an entry workload expected in a future duration, accesses a component graph (400) generated by topology generator 750 and estimates a component workload based on the entry workload and a set of branch probabilities determined by traversing the component graph, as explained in the above sections.) Same motivation as claim 15. Regarding claim 19 , the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale. Regarding claim 20, Biswas teaches: A method according to Claim 19, further comprising: receiving a second indicator of a second workload of the entry microservice of the microservice-based application; determining, based on the second indicator of the second workload and a second mapping of workloads of the plurality of entry microservices to workloads of the plurality of interior microservices, a second estimated future workload of the first microservice ; ([0082] The process 700 then determines (at 730 ) whether to scale the selected service. If the service should be scaled, the process determines (at 735 ) the scaling action for the selected service. As discussed, some embodiments scale the services predictively so that the additional instances are deployed prior to the existing instances for the service being overloaded by the incoming traffic. In the example, shown in the table 1000 of FIG. 10 , Services A and B should be scaled by adding 2 Pods for each service while Services C and D should be scaled by adding 1 Pod for each service. Owing to (1) the different per-instance capacity of different applications (in this case, the services) and (2) the different expected traffic flow reaching each different applications based on the computed scaling factors, in many cases different numbers of instances will be required due to the same change in ingress traffic.) Biswas does not appear to explicitly teach: and transmitting the second estimated future workload to the first execution environment of the first microservice. However, Mulpuri teaches: ([0092] Referring again to FIG. 5, upon receiving at time instance 550, performance manager 150 receives data indicating the entry workload (EW8) expected to be received in the future block duration t8, performance manager 150 first estimates the component workload at a specific component (such as C9) corresponding to the expected entry load EW8.[0093] In one embodiment, performance manager 150 first identifies, by traversing component graph 400, a set of paths connecting the one or more entry components to the specific component in the component graph, each path of the set of paths containing a respective set of edges. For example, for EW8 where there are transactions of all types, performance manager 150 may identify the set of paths to be {E1->C1->C9, E1->C3->C9, E2->C2->C9, E2->C4->C9 } with each arrow (->) indicating the sequence/order of invocation of the components. [0094] Each identified path may correspond to a respective transaction type. As such, for a single path (e.g.,, E1->C1->C9) corresponding to a transaction type (Txn_Search_Hotel), the number of transaction instances of the transaction type as specified in the expected future workload (e.g. 2000) may be multiplied by the set of branch probabilities (in table 680) associated with the set of edges in the single path to determine the number of transaction instances expected to be received at the specific component. [0110] Workload estimator 770 receives (via path 121) data indicating an entry workload expected in a future duration, accesses a component graph (400) generated by topology generator 750 and estimates a component workload based on the entry workload and a set of branch probabilities determined by traversing the component graph, as explained in the above sections.) Same motivation as claim 15. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST. 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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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. /C.A.E./Examiner, Art Unit 2199 /LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199 Application/Control Number: 18/630,343 Page 2 Art Unit: 2199 Application/Control Number: 18/630,343 Page 3 Art Unit: 2199 Application/Control Number: 18/630,343 Page 4 Art Unit: 2199 Application/Control Number: 18/630,343 Page 5 Art Unit: 2199 Application/Control Number: 18/630,343 Page 6 Art Unit: 2199 Application/Control Number: 18/630,343 Page 7 Art Unit: 2199 Application/Control Number: 18/630,343 Page 8 Art Unit: 2199 Application/Control Number: 18/630,343 Page 9 Art Unit: 2199 Application/Control Number: 18/630,343 Page 10 Art Unit: 2199 Application/Control Number: 18/630,343 Page 11 Art Unit: 2199 Application/Control Number: 18/630,343 Page 12 Art Unit: 2199 Application/Control Number: 18/630,343 Page 13 Art Unit: 2199 Application/Control Number: 18/630,343 Page 14 Art Unit: 2199 Application/Control Number: 18/630,343 Page 15 Art Unit: 2199 Application/Control Number: 18/630,343 Page 16 Art Unit: 2199 Application/Control Number: 18/630,343 Page 17 Art Unit: 2199 Application/Control Number: 18/630,343 Page 18 Art Unit: 2199 Application/Control Number: 18/630,343 Page 19 Art Unit: 2199 Application/Control Number: 18/630,343 Page 20 Art Unit: 2199 Application/Control Number: 18/630,343 Page 21 Art Unit: 2199 Application/Control Number: 18/630,343 Page 22 Art Unit: 2199 Application/Control Number: 18/630,343 Page 23 Art Unit: 2199 Application/Control Number: 18/630,343 Page 24 Art Unit: 2199 Application/Control Number: 18/630,343 Page 25 Art Unit: 2199 Application/Control Number: 18/630,343 Page 26 Art Unit: 2199 Application/Control Number: 18/630,343 Page 27 Art Unit: 2199 Application/Control Number: 18/630,343 Page 28 Art Unit: 2199 Application/Control Number: 18/630,343 Page 29 Art Unit: 2199
Prosecution Insights