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 .
DETAILED ACTION
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/29/2025 and 11/25/2025 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim 1-20 are rejected under 35 U.S.C. 112(b) 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.
The following claim languages are not clearly understood and indefinite:
As per claim 1, lines 15-21, recite the limitations “determining whether a percentage of the respective iterations, for which corresponding upper limits, of the respective upper limits, on amount of time for which the containerized function is idle, is below a threshold idleness value, and for which corresponding numbers of cold starts, of the respective numbers of cold starts, are above a threshold cold start value; in response to determining that the percentage of the respective iterations is above a threshold successful probes value”. However, it is uncertain and not clearly understood how to determine whether the percentage of the respective iterations is above the “threshold successful probes value” (e.g. is it based on the amount of time the containerized function is idle being below a threshold idleness value or based on number of cold starts being above cold start threshold Or both or else?). Further, it is unclear what the relationship is between the “threshold successful probes value” and the threshold idleness value and the threshold cold start value.
As per claims 9 and 15, they are rejected as having similar issues as claim 1 above.
Claims 2-8, 10-14 and 15-20, they are rejected as being dependent on rejected claims 1, 9 and 15.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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 1, 3, 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (U.S. Pub. No. 20210124577 A1) in view of Fu et al. (U.S. Pub. No. 20250370763 A1), further in view of Chandrasekhar et al. (U.S. Patent No. 11614982 B1), and further in view of Babay et al. (U.S. Pub. No. 20160275402 A1).
As per claim 1, Gupta teaches the invention substantially as claimed including a system, comprising:
a processor (Fig. 7, Processor 710); and
a memory coupled to the processor (Fig. 7, Memory 712; par. 0073 a processor 710 coupled to a memory 712), comprising instructions that, in response to execution by the processor, cause the system to perform operations (par. 0075 memories disclosed herein … are more generally referred to as “processor-readable storage media” storing executable program code of one or more software programs), comprising:
executing a group of … functions (par. 0032 The application parsing module 112 is configured to analyze software code of the application to identify a plurality of functions as candidates; Gupta, par, 0066, further teaches cloud infrastructure 600 that comprises physical/virtual processing that may be utilized to implement at least a portion of information processing system 100 in FIG. 1. The cloud infrastructure 600 comprises multiple virtual machines (VMs) and/or container sets 602-1, 602-2, . . . 602-L; par. 0067 The cloud infrastructure 600 further comprises sets of applications … running on respective ones of the VMs/container sets);
monitoring a … function of the group of … functions for a number of iterations of the … function, respective iterations of the number of iterations being for a defined amount of time, wherein the … function is configured to execute a function (par. 0032 The application parsing module 112 is configured to analyze software code of the application to identify a plurality of functions as candidates for combination with one another into the set of microservices, and to monitor a running instance of the application … to generate a calling-context tree identifying interactions among the plurality of functions; par. 0044 determining amounts of function calls [number of iterations] between respective ones of the plurality of functions while monitoring the running instance of the application); for the respective iterations),
deploying a microservice that is configured to execute the function (par. 0004 generating the set of microservices based at least in part on the modified design), and terminating deployment of the containerized function (par. 0046 replacing software code of the given subset of the plurality of functions from the application with one or more references to the given microservice).
Gupta does not expressly disclose: determining respective upper limits of amounts of time for which the containerized function is idle; containerized function.
However, in analogous art, Fu teaches: determining respective upper limits of amounts of time for which the containerized function is idle (par. 0050 determine the amount of time that the application program has remained idle; par. 0045 computing system 100 may be configured to generate the triggers based on the … amount of time that one or more of the processors 110 has remained idle, the amount of time that the application program has remained in the idle state); containerized function. (par. 0028 Application programs running inside of a container).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to combine the technique of determining to switch between containers based on idle time of Fu with the method of determining whether to deploy a microservice instead of a function of Gupta, by taking the concept of determining to switch between containers based on idle time of Fu and instead applying the idle determination to Gupta to make the determination that a microservice should be deployed rather than a function. One of ordinary skill would have realized the combination would provide advantages so as to achieve improved performance, to balance tradeoffs between performance and power consumption (par. 0045) in such system.
Gupta and Fu do not expressly teach: determining respective numbers of cold starts of the containerized function.
However, Chandrasekhar teaches: determining respective numbers of cold starts of the containerized function (col. 11, lines 1-4 In some implementations, a number of cold starts may be determined based on another received parameter such as initialization (init) duration for each invocation of a serverless function in a given window).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to modify/combine the teaching of Gupta and Fu by incorporating the teaching of Chandrasekhar because it would provide for determining a number of cold starts for applications functions. Motivation to combine would have been to take advantage for various advantages such as improving the performance of serverless computing systems, and particularly to mitigate cold start latency (col. 8, lines 11-13).
Gupta, Fu and Chandrasekhar do not expressly disclose: determining whether a percentage of the respective iterations, for which corresponding upper limits, of the respective upper limits, on amount of time for which the containerized function is idle, is below a threshold idleness value, and for which corresponding numbers of cold starts, of the respective numbers of cold starts, are above a threshold cold start value; in response to determining that the percentage of the respective iterations is above a threshold successful probes value.
However, Babay teaches: determining whether a percentage of the respective iterations, for which corresponding upper limits, of the respective upper limits, on amount of time for which the containerized function is idle, is below a threshold idleness value … and in response to determining that the percentage of the respective iterations is above a threshold successful probes value (par. 0036 In some examples, an average of the percent of successful use can be determined and the approval recommendation 122 can be based off of the average. In an example, if the average exceeds a threshold of percentage of successful use (e.g., is used successfully an average of 99 percent of the time), the approval recommendation 122 can recommend a minimum approval level. Alternatively, if [in response to] the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to modify/combine the teaching of Gupta, Fu and Chandrasekhar by incorporating the technique of recommending an approval level based on a successful threshold as taught by Babay by implementing in the manner of recommending the conversion of application functions to a microservice based at least amount of idle times and cold starts of the applications functions meeting a successful threshold value. Gupta, Fu and Chandrasekhar teach analyzing an application to identify a plurality of functions and generating microservices based on the monitoring of the application functions, determining an amount of time that an application program [function] has remained idle, and determining the number of cold starts of serverless functions, except determining that the percentage of iterations is above a threshold successful probes value. Babay teaches a technique of recommending an approval level based on a successful threshold. One of ordinary skill in the art would have been motivated to make this combination for the purpose of enhancing efficiency in decision-making by providing a clear, pre-defined limits for action. Further, it would have provided an approval recommendation based on how successfully [a criteria is met] a process model is used (par. 0036).
As per claim 3, Chandrasekhar further teaches: wherein the respective numbers of cold starts of the containerized function corresponds to instances of the containerized function being provisioned in response to attempts to invoke the containerized function (col. 11, lines 1-4 cold starts may be determined based on another received parameter such as initialization (init) duration for each invocation of a serverless function in a given window).
As per claim 5, Gupta teaches: wherein the containerized function is a first containerized function, and wherein the microservice is configured to call a second containerized function of the group of containerized functions (par. 0048 considering expected calls between the microservices; par. 0063 microservices that communicate with the selected classes or functions).
As per claim 6, Gupta teaches wherein the microservice is configured to be called by the group of containerized functions (par. 0063 microservices that communicate with the selected classes or functions).
As per claim 7, Gupta further teaches: accessing source code of the function from a repository (par. 0032 analyze software code of the application to identify a plurality of functions as candidates for combination with one another into the set of microservices); packaging the source code into a microservice image; and deploying the microservice image to produce the deployed microservice instance (par. 0004 generating the set of microservices based at least in part on the modified design; par. 0028 modify proposed designs [images] of microservices for one or more applications, to select microservices to be created, to deploy created microservices).
As per claim 8, Gupta further teaches: wherein deploying the microservice is performed by a continuous integration and continuous deployment component (par. 0017 A microservices architecture enables individual microservices to be deployed and scaled independently, such as via software containers. Individual microservices can be worked on in parallel by different teams, may be built in different programming languages, and have continuous delivery and deployment flows).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Fu, Chandrasekhar and Babay, further in view of Ibrahim et al. (U.S. Pub. No. 20240248739 A1), and further in view of Kanso et al. (US 20240086160 A1).
As per claim 2, Gupta further teaches monitoring the microservice for a second number of iterations of the containerized function for a second defined amount of time (par. 0043 a running instance of the application is monitored to generate a calling-context tree identifying interactions among the plurality of functions; par. 0044 determining amounts of function calls between respective ones of the plurality of functions while monitoring the running instance of the application). Babay further teaches in response to determining that a second percentage of the respective second iterations is below a second threshold successful probes value (par. 0036 In an example, if the average exceeds a threshold of percentage of successful use … the approval recommendation 122 can recommend a minimum approval level. Alternatively, if the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level).
Gupta, Fu and Chandrasekhar and Babay do not expressly describe: redeploying the containerized function.
However, Ibrahim teaches: redeploying the containerized function (par. 0069 the container management circuitry 210 redeploys containerized applications that have been suspended).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine/modify they teachings of Gupta, Fu and Chandrasekhar and Babay with the method of redeploying containerized applications taught by Ibrahim. Gupta, Fu, Chandrasekhar and Babay teach analyzing software code of the application to identify a plurality of functions, determining amounts of function calls [number of iterations] between respective ones of the plurality of functions, generating microservices and replacing the functions with reference to the microservices, determining an amount of time that an application program [function] has remained idle and determining the number of cold starts of serverless functions, except redeploying a containerized function. However, Ibrahim does. One of ordinary skill in the art would have been motivated to combine the method of Ibrahim with the teaching of Gupta, Fu, Chandrasekhar and Baba for the purpose restarting (e.g., reprovisioning and/or redeploying) the containerized application) without human intervention, in response to receipt of a request for the containerized function/application (par. 0127).
Gupta, Fu and Chandrasekhar, Babay and Ibrahim do not expressly teach: terminating deployment of the microservice.
However, Kanso teaches: terminating deployment of the microservice (par. 0006 the termination manager can detect any microservices that do not appear in any of the call graphs. This indicates that these microservices are not needed to process the outstanding requests. In response, the termination manager can immediately terminate the unneeded microservices).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine/modify they teachings of Gupta, Fu and Chandrasekhar and Babay with the method of redeploying containerized applications taught by Ibrahim. Gupta, Fu, Chandrasekhar, Babay and Ibrahim teach analyzing software code of the application to identify a plurality of functions, determining amounts of function calls [number of iterations] between respective ones of the plurality of functions, generating microservices and replacing the functions with reference to the microservices, determining an amount of time that an application program [function] is idle, determining the number of cold starts of serverless functions, redeploying containerized applications, except terminating deployment of microservices. Kanso, however, does. One of ordinary skill in the art would have been motivated to make this combination for the purpose of taking advantage for various advantages including preventing microservices from being terminated too early as is the issue with existing approaches for microservice termination (par. 0023). Further, utilizing call graphs to terminate microservices would enable such system to reduce the amount of time required to complete termination (par. 0024).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Fu, Chandrasekhar and Babay, and further in view of Mahapatra et al. (U.S. Pub. No. 10469617 B1).
As per claim 4, Fu further teaches: wherein a first amount of time associated with a first invocation the containerized function that occurs independently (par. 0045 the amount of time that the application program has remained in the idle state). Chandrasekhar further teaches: a second amount of time associated with a second invocation of the containerized function that occurs with the cold start (col. 11 lines 9-13 the run-time data may include an average duration (of execution) of a serverless function, an average cold start time, a number of concurrent invocations, and memory configuration(s) and concurrency configuration(s) of one or more serverless functions).
Gupta in view of Fu, Chandrasekhar and Babay do not expressly disclose: wherein a first amount of time associated with a first invocation the containerized function that occurs independently of a cold start of the cold starts is less than a second amount of time associated with a second invocation of the containerized function that occurs with the cold start.
However, Mahapatra teaches: wherein a first amount of time associated with a first invocation the … function that occurs independently … is less than a second amount of time associated with a second invocation of the … function that occurs … (col. 25, lines 59-65 determine a first estimated response time for the first network application request based on the crowdsource data; determine a second estimated response time for the second network application request based on the crowdsource data, the second estimated response time is less than the first estimated response time).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine determining a second estimated response time is less than the first estimated response time of Mahapatra with the teaching of Gupta, Fu, Chandrasekhar, Babay and Ibrahim resulting in a system/metho where a first amount of time associated with a first invocation the containerized function that occurs independently of a cold start of the cold starts is less than a second amount of time associated with a second invocation of the containerized function that occurs with the cold start. One of ordinary skill in the art would have been motivated to make this combination for purpose of taking advantage of shorter download times for the network responses, which leads to an improved user experience, and reduces consumption of user device resources (col. 4, lines 5-8).
Claims 9, 12-15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (U.S. Pub. No. 20210124577 A1) in view of Fu et al. (U.S. Pub. No. 20250370763 A1), further in view of Chandrasekhar et al. (U.S. Patent No. 11614982 B1), and further in view of Babay et al. (U.S. Pub. No. 20160275402 A1), and further in view of Klein et al. (U.S. Patent No. 5905901 A).
As per claim 9, Gupta teaches the invention substantially as claimed including a method, comprising:
monitoring, by a system comprising a processor (par. 0070 components of system 100 may each run on a computer … or other processing platform element; par. 0073, processing platform 700 comprises a processor 710), a … function for recurring measurement periods (par. 0032 The application parsing module 112 is configured to analyze software code of the application to identify a plurality of functions as candidates for combination with one another into the set of microservices, and to monitor a running instance of the application … to generate a calling-context tree identifying interactions among the plurality of functions; par. 0044 determining amounts of function calls [number of iterations] between respective ones of the plurality of functions while monitoring the running instance of the application); for the respective iterations);
deploying, by the system, a microservice that is configured to execute a function that corresponds to the containerized function (par. 0004 generating the set of microservices based at least in part on the modified design).
Gupta does not expressly teach: for respective recurring measurement periods of the recurring measurement periods, determining, by the system, respective upper limit idle times of the containerized function; containerized function.
However, Fu teaches: … determining, by the system, respective upper limit idle times of the containerized function (par. 0050 determine the amount of time that the application program has remained idle; par. 0045 computing system 100 may be configured to generate the triggers based on the … amount of time that one or more of the processors 110 has remained idle, the amount of time that the application program has remained in the idle state); containerized function (par. 0028 Application programs running inside of a container).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to modify/combine the teaching of Gupta by incorporating the technique of switching an application program to another container based on an amount of idle time of the application program set forth by Fu by implementing in the manner of deploying a microservice responsive to determining an amount of idle time/number of iterations exceeding a threshold value. One of ordinary skill would have realized the combination would provide advantages such as in cost efficiency through usage-based billing, resource utilization, better scalability.
Gupta and Fu do not expressly teach: determining, by the system, respective numbers of cold starts of the containerized function.
However, Chandrasekhar teaches: determining, by the system, respective numbers of cold starts of the containerized function (col. 11, lines 1-4 In some implementations, a number of cold starts may be determined based on another received parameter such as initialization (init) duration for each invocation of a serverless function in a given window).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to modify/combine the teaching of Gupta and Fu by incorporating the teaching of Chandrasekhar because it would provide for determining a number of cold starts for applications functions. Motivation to combine would have been to take advantage for various advantages such as improving the performance of serverless computing systems, and particularly to mitigate cold start latency (col. 8, lines 11-13).
Gupta, Fu and Chandrasekhar do not expressly disclose: determining, by the system, a percentage of the recurring measurement periods where any respective upper limit idle times of the respective upper limit idle times are below a first value, and where any respective number of cold starts of the respective numbers of cold starts are above a second value; and in response to determining that the percentage of the recurring measurement periods is above a threshold percentage of successful probes, deploying, a microservice.
However, Babay teaches: determining, by the system, a percentage of the recurring measurement periods where any respective upper limit idle times of the respective upper limit idle times are below a first value … and in response to determining that the percentage of the recurring measurement periods is above a threshold percentage of successful probes (par. 0036 In some examples, an average of the percent of successful use can be determined and the approval recommendation 122 can be based off of the average. In an example, if the average exceeds a threshold of percentage of successful use (e.g., is used successfully an average of 99 percent of the time), the approval recommendation 122 can recommend a minimum approval level. Alternatively, if the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to modify/combine the teaching of Gupta, Fu and Chandrasekhar by incorporating the technique of recommending an approval level based on a successful threshold as taught by Babay by implementing in the manner of recommending the conversion of application functions to a microservice based at least amount of idle times and cold starts of the applications functions meeting a successful threshold value. Gupta, Fu and Chandrasekhar teach analyzing an application to identify a plurality of functions and generating microservices base on the monitoring of the application functions, determining an amount of time that an application program [function] has remained idle, and determining the number of cold starts of serverless functions, except determining that the percentage of iterations is above a threshold successful proves value. Babay teaches a technique of recommending an approval level based on a successful threshold. One of ordinary skill in the art would have recognized that applying the technique of recommending based on a successful threshold value to the teachings of Gupta, Fu and Chandrasekhar would have yielded in system that recommends deployment of microservices at least based on a percentage of iterations satisfying a successful threshold value, with predictable results.
Gupta, Fu and Chandrasekha and Babay do not expressly teach: for respective recurring measurement periods of the recurring measurement periods, determining, by the system, respective upper limit idle times of the containerized function.
However, Klein teaches: for respective recurring measurement periods of the recurring measurement periods, determining, by the system, respective upper limit idle times of the containerized function (col. 6, lines 62-64 For each of the calendar time periods [recurring time periods], a component idle time value is then calculated or otherwise determined).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to combine/modify the technique of calculating component idle times for each calendar time period of Klein with the system/methods of Gupta, Fu, Chandrasekhar and Babay resulting in a system/method in which idle times of application functions are monitored and calculated for each calendar time period as in Klein. One of ordinary skill in the art would have been motivated to make this combination for the purpose providing improved energy efficiency while maintaining ready and rapid access to system [application functions] capabilities during the time the computer system is normally used (col. 6, lines 34-37).
As per claim 12, Gupta further teaches: terminating deployment of the containerized function (par. 0046 replacing [terminating] software code of the given subset of the plurality of functions from the application with one or more references to the given microservice).
As per claim 13, Klein further teaches: wherein the respective upper limit idle times indicates a measured idle time of the containerized function per recurring measurement period of the recurring measurement periods (col. 6, lines 62-64 For each of the calendar time periods [recurring time periods], a component idle time value is then calculated or otherwise determined).
As per claim 14, Babay further teaches: wherein the threshold percentage of successful probes indicates a number of recurring measurement periods of the recurring measurement periods for which any respective upper limit idle times of the respective upper limit idle times are below the first value and any respective number of cold starts of the respective numbers of cold starts are above the second value (par. 0036 an average of the percent of successful use can be determined and the approval recommendation 122 can be based off of the average. In an example, if the average exceeds a threshold of percentage of successful use (e.g., is used successfully an average of 99 percent of the time), the approval recommendation 122 can recommend a minimum approval level. Alternatively, if [in response to] the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level).
As per claim 15, it is a non-transitory computer-readable medium having similar limitations as claim 9. Thus, claim 15 is rejected for the same rationale as applied to claim 9. Gupta further teaches: non-transitory computer-readable medium (par. 0075 processor-readable storage media).
As per claim 19, Gupta further teaches: accessing source code of the function from a repository, and wherein deploying the containerized function comprises accessing the source code of the function from the repository (par. 0032 analyze software code of the application to identify a plurality of functions as candidates for combination with one another into the set of microservices; par. 0028 modify proposed designs [images] of microservices for one or more applications, to select microservices to be created, to deploy created microservices).
As per claim 20, Fu further teaches: wherein the respective upper limit idle times comprise respective maximum idle times (par. 0050 the computing system may monitor the operations of the application program, determine the amount of time that the application program has remained idle, determine whether the amount of time that application program has remained idle exceeds a threshold value, and generate the trigger in response to determine that an amount of time exceeds the threshold value [maximum idle time]. In response to detecting the trigger that indicate that there has been a decrease in the performance requirements, the computing system may switch from using the container 106b that includes a Linux embedded user space instance 132).
Claims 10 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Fu, Chandrasekhar, Babay and Klein, and further in view of Ibrahim et al. (U.S. Pub. No. 20240248739 A1).
26. As per claim 10, Gupta further teaches: monitoring, by the system, the microservice for second recurring measurement periods (par. 0043 a running instance of the application is monitored to generate a calling-context tree identifying interactions among the plurality of functions; par. 0044 determining amounts of function calls between respective ones of the plurality of functions while monitoring the running instance of the application). Babay further teaches: in response to determining that a second percentage of the second recurring measurement periods is below a second threshold percentage of successful probes (par. 0036 In an example, if the average exceeds a threshold of percentage of successful use … the approval recommendation 122 can recommend a minimum approval level. Alternatively, if the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level).
Gupta, Fu and Chandrasekhar, Babay and Klein do not expressly describe: deploying, by the system, the containerized function.
However, Ibrahim teaches: deploying, by the system, the containerized function (par. 0069 the container management circuitry 210 redeploys containerized applications that have been suspended).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine/modify they teachings of Gupta, Fu and Chandrasekhar and Babay with the method of redeploying containerized applications taught by Ibrahim. Gupta, Fu, Chandrasekhar, Babay and Klein teach analyzing software code of the application to identify a plurality of functions, determining amounts of function calls [number of iterations] between respective ones of the plurality of functions, generating microservices and replacing the functions with reference to the microservices, determining an amount of time that an application program [function] has remained idle and determining the number of cold starts of serverless functions, except redeploying a containerized function. However, Ibrahim does. One of ordinary skill in the art would have been motivated to combine the method of Ibrahim with the teaching of Gupta, Fu, Chandrasekhar and Babay for the purpose restarting (e.g., reprovisioning and/or redeploying) the containerized application) without human intervention, in response to receipt of a request for the containerized function/application (par. 0127).
As per claim 16, Gupta further teaches: after deploying the microservice (par. 0004 generating the set of microservices based at least in part on the modified design). in response to determining that a second percentage of second recurring measurement periods is below a second threshold percentage of successful probes (par. 0036 if the average exceeds a threshold of percentage of successful use (e.g., is used successfully an average of 99 percent of the time), the approval recommendation 122 can recommend a minimum approval level. Alternatively, if [in response to] the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level).
Gupta, Fu and Chandrasekhar, Babay and Klein do not expressly describe: deploying the containerized function.
However, Ibrahim teaches: redeploying the containerized function (par. 0029 deploys one or more additional containers to a pod executing the first application 110A in response to (e.g., based on) an increased demand; par. 0069 the container management circuitry 210 redeploys containerized applications that have been suspended).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine/modify they teachings of Gupta, Fu, Chandrasekhar, Babay and Klein with the method of redeploying containerized applications taught by Ibrahim. Gupta, Fu, Chandrasekhar, Babay and Klein teach analyzing software code of the application to identify a plurality of functions, determining amounts of function calls [number of iterations] between respective ones of the plurality of functions, generating microservices and replacing the functions with reference to the microservices, determining an amount of time that an application program [function] has remained idle and determining the number of cold starts of serverless functions, except deploying a containerized function. However, Ibrahim does. One of ordinary skill in the art would have been motivated to combine the method of Ibrahim with the teaching of Gupta, Fu, Chandrasekhar, Baba and Klein for the purpose restarting (e.g., reprovisioning and/or redeploying) the containerized application) without human intervention, in response to receipt of a request for the containerized function/application (par. 0127).
As per claim 17, Babay further teaches: wherein a third value of the threshold percentage of successful probes equals a fourth value of the second threshold percentage of successful probes (par. 0036 In an example, if the average exceeds a threshold of percentage of successful use (e.g., is used successfully an average of 99 percent of the time), the approval recommendation 122 can recommend a minimum approval level. Alternatively, if [in response to] the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level).
As per claim 18, Babay teaches: wherein a third value of the threshold percentage of successful probes differs from a fourth value of the second threshold percentage of successful probes (par. 0036 if the average exceeds a threshold of percentage of successful use (e.g., is used successfully an average of 99 percent of the time), the approval recommendation 122 can recommend a minimum approval level. Alternatively, if [in response to] the average is below a threshold of percentage of successful use (e.g., is used successfully an average of 1 percent of the time), the approval recommendation 122 can recommend a maximum approval level).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Fu, Chandrasekhar, Babay, Klein and Ibrahim, and further in view of Kanso et al. (US 20240086160 A1).
Gupta, Fu, Chandrasekhar, Babay, Klein and Ibrahim do not expressly teach: terminating deployment of the microservice.
However, Kanso teaches: terminating deployment of the microservice (par. 0006 the termination manager can detect any microservices that do not appear in any of the call graphs. This indicates that these microservices are not needed to process the outstanding requests. In response, the termination manager can immediately terminate the unneeded microservices).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of redeploying containerized applications of Ibrahim with the method/systems of Gupta, Fu, Chandrasekhar, Babay, Klein and Ibrahim. Gupta, Fu, Chandrasekhar, Babay, Klein and Ibrahim teach analyzing software code of the application to identify a plurality of functions, determining amounts of function calls [number of iterations] between respective ones of the plurality of functions, generating microservices and replacing the functions with reference to the microservices, determining an amount of time that an application program [function] is idle, determining the number of cold starts of serverless functions, redeploying containerized applications, except terminating deployment of microservices. Kanso, however, does. One of ordinary skill in the art would have been motivated to make this combination for the purpose of taking advantage for various advantages including preventing microservices from being terminated too early as is the issue with existing approaches for microservice termination (par. 0023). Further, utilizing call graphs to terminate microservices would enable such system to reduce the amount of time required to complete termination (par. 0024).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent No. 11368521 B1 teaches Utilizing Reinforcement Learning For Serverless Function Tuning.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Willy W. Huaracha whose telephone number is (571)270-5510. The examiner can normally be reached on M-F 8:30-5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached on (571) 272-3338. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WH/
Examiner, Art Unit 2195
/BRADLEY A TEETS/ Supervisory Patent Examiner, Art Unit 2197