DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
1. Claims 1, 8, and 15 are currently amended.
Claim 2 is cancelled.
Claim 21 is newly added.
Claims 1 and 3-21 are pending.
Claims 1 and 3-21 are rejected.
Response to Arguments
2. Regarding Prior Art Rejections:
The arguments regarding the rejections under 35 U.S.C. § 102(a)(1) and 35 U.S.C. § 103 challenge certain limitations. These limitations are newly added and were therefore not addressed in the previous rejection; therefore, the arguments are moot. The amendments are newly addressed by the new grounds of rejection under 35 U.S.C. § 103.
Applicant’s arguments with respect to claim(s) 1, 8, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on March 2, 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
4. Claims 1, 3, 5-6, 8, 11, 13, 15-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta US 20210124577 A1 in view of Schejter et al. US 20130263139 A1.
Gupta US 20210124577 A1 was cited in IDS filed on March 2, 2026.
5. With regard to claim 1, Gupta teaches:
A system, comprising:
at least one processor ([0040] The method is performed by at least one processing device comprising a processor coupled to a memory.); and
at least one memory coupled to the processor ([0004] The method is performed by at least one processing device comprising a processor coupled to a memory.), comprising instructions that, in response to execution by the at least one processor, cause the system to perform operations ([0082] As indicated previously, components of an information processing system as disclosed herein can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device.), comprising:
determining to combine a first function that executes in a first container and a second function that executes in a second container in a third container ([0016] Microservices-based software architectural design structures an application as a collection of loosely coupled services. Microservices-based software architectures may be viewed as a variant of a service-oriented architecture that focuses on fine-grained services, lightweight protocols, etc. Large, monolithic applications can be decomposed or disintegrated into sets of small independent and composable services, referred to herein as nanoservices. A nanoservice refers to a service that can be broken down into very small pieces, though not all small pieces of code are nanoservices. Nanoservices are deployable, reusable and useful. When a service or a method does not call other internal methods but calls an external service, such as a web service or a database interface, it may be considered as a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice; [0017] A microservices architecture enables individual microservices to be deployed and scaled independently, such as via software containers; [0032] The microservices design recommendation tool 102 is configured to identify at least a portion of an application that is to be converted (e.g., “disintegrated”) into a set of microservices. 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 (e.g., on one or more assets of the enterprise system 110) to generate a calling-context tree identifying interactions among the plurality of functions; [0043] The process begins with step 200, identifying at least a portion of an application to be converted into a set of microservices. In some embodiments, the application is a “legacy” application that is being converted into a cloud native application. In step 202, the software code of the application is analyzed to identify a plurality of functions as candidates for combination with one another into the set of microservices. Step 202 may include finding functions in the software code of the application, determining whether each of the found functions references one or more external services, and selecting ones of the found functions that reference at least one of the one or more external services as the candidates for combination with one another into the set of microservices. The one or more external services may comprise at least one of a web service, a database interface and a network protocol.);
determining a first runtime of the first function based on a first container configuration of the first container ([0049] FIGS. 3A-3E depict a process 300 for deconstructing a monolithic application into microservices using a semantic-based approach. To start 301, a monolithic application is selected by a user, such as via inputting a monolithic application name and location in step 303. A monolithic application may be implemented using various programming languages (e.g., C#, Python, Java, etc.). The monolithic application may also be implemented using various architectures (e.g., the monolithic application may be on a single platform, be divided on different platforms with each part having the same characteristics as the general monolithic application, etc.). Given the monolithic application name and location, a microservices design recommendation tool (e.g., 102) starts in 305 to disintegrate the selected monolithic application into a set of microservices by fetching the code of the monolithic application (e.g., from an application database or other data source); [0050] The process 300 proceeds to step 307, where a determination is made as to whether a file of the monolithic application is available for code scanning (e.g., whether there are any code files or code of the monolithic application not yet scanned). If the result of the step 307 determination is yes, the process 300 continues with step 309 and scans for available methods (e.g., to find candidates for nanoservices) by comparing against some general method or function syntax that is pre-defined within the microservices design tool. For example, if the monolithic application is written in the Java programming language, a method may be found by searching the code for the format or syntax of <modifier><return type><method name>(parameters . . . ) {. . . }. For other languages, an appropriate general method syntax may be used to find one or more methods in step 309.);
determining a second runtime of the second function based on a second container configuration of the second container ([0049] FIGS. 3A-3E depict a process 300 for deconstructing a monolithic application into microservices using a semantic-based approach. To start 301, a monolithic application is selected by a user, such as via inputting a monolithic application name and location in step 303. A monolithic application may be implemented using various programming languages (e.g., C#, Python, Java, etc.). The monolithic application may also be implemented using various architectures (e.g., the monolithic application may be on a single platform, be divided on different platforms with each part having the same characteristics as the general monolithic application, etc.). Given the monolithic application name and location, a microservices design recommendation tool (e.g., 102) starts in 305 to disintegrate the selected monolithic application into a set of microservices by fetching the code of the monolithic application (e.g., from an application database or other data source); [0050] The process 300 proceeds to step 307, where a determination is made as to whether a file of the monolithic application is available for code scanning (e.g., whether there are any code files or code of the monolithic application not yet scanned). If the result of the step 307 determination is yes, the process 300 continues with step 309 and scans for available methods (e.g., to find candidates for nanoservices) by comparing against some general method or function syntax that is pre-defined within the microservices design tool. For example, if the monolithic application is written in the Java programming language, a method may be found by searching the code for the format or syntax of <modifier><return type><method name>(parameters . . . ) {. . . }. For other languages, an appropriate general method syntax may be used to find one or more methods in step 309.);
deploying the third container that comprises the first function matched to the first runtime and the second function matched to the second runtime, wherein the first runtime in the third container differs from the second runtime in the third container ([0016] Microservices-based software architectural design structures an application as a collection of loosely coupled services. Microservices-based software architectures may be viewed as a variant of a service-oriented architecture that focuses on fine-grained services, lightweight protocols, etc. Large, monolithic applications can be decomposed or disintegrated into sets of small independent and composable services, referred to herein as nanoservices. A nanoservice refers to a service that can be broken down into very small pieces, though not all small pieces of code are nanoservices. Nanoservices are deployable, reusable and useful. When a service or a method does not call other internal methods but calls an external service, such as a web service or a database interface, it may be considered as a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice; [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. As development moves toward cloud-native approaches, it is desired to decompose, disintegrate or otherwise separate existing monolithic applications into microservices; [0049] FIGS. 3A-3E depict a process 300 for deconstructing a monolithic application into microservices using a semantic-based approach. To start 301, a monolithic application is selected by a user, such as via inputting a monolithic application name and location in step 303. A monolithic application may be implemented using various programming languages (e.g., C#, Python, Java, etc.). The monolithic application may also be implemented using various architectures (e.g., the monolithic application may be on a single platform, be divided on different platforms with each part having the same characteristics as the general monolithic application, etc.). Given the monolithic application name and location, a microservices design recommendation tool (e.g., 102) starts in 305 to disintegrate the selected monolithic application into a set of microservices by fetching the code of the monolithic application (e.g., from an application database or other data source); [0050] The process 300 proceeds to step 307, where a determination is made as to whether a file of the monolithic application is available for code scanning (e.g., whether there are any code files or code of the monolithic application not yet scanned). If the result of the step 307 determination is yes, the process 300 continues with step 309 and scans for available methods (e.g., to find candidates for nanoservices) by comparing against some general method or function syntax that is pre-defined within the microservices design tool. For example, if the monolithic application is written in the Java programming language, a method may be found by searching the code for the format or syntax of <modifier><return type><method name>(parameters . . . ) {. . . }. For other languages, an appropriate general method syntax may be used to find one or more methods in step 309.);
directing a first call that is originated externally to the third container to the first function to the third container, and executing the first function in the third container ([0016] A nanoservice refers to a service that can be broken down into very small pieces, though not all small pieces of code are nanoservices. Nanoservices are deployable, reusable and useful. When a service or a method does not call other internal methods but calls an external service, such as a web service or a database interface, it may be considered as a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice; Examiner’s Note: The first external call is directed towards the web service nanoservice.); and
directing a second call that is originated externally to the third container to the second function to the third container, and executing the second function in the third container ([0016] A nanoservice refers to a service that can be broken down into very small pieces, though not all small pieces of code are nanoservices. Nanoservices are deployable, reusable and useful. When a service or a method does not call other internal methods but calls an external service, such as a web service or a database interface, it may be considered as a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice; Examiner’s Note: The first external call is directed towards the database interface nanoservice.).
Although Gupta teaches of combing nanoservices/monolithic application and deploying a microservice in a third container doesn’t explicitly say that the nanoservices/monolithic applications are in first and second containers.
However, in analogous art, Schejter teaches:
[0045] At 320, a second runtime container to execute the second portion of the application code is determined. [...] Each of the first runtime container and the second runtime container may be associated with at least one of a client device, an application server, a database, a web service, a computer, a user interface, or a virtual machine. The determination of the second runtime container can be based on a policy or a characteristic associated with the application code. Example policies may include a security policy, an administrative policy, a service policy, or a business policy. The characteristic can be a characteristic of the application code, and/or a characteristic of an application that corresponds to the application code. In some implementations, the characteristic is a capability characteristic, which characterizes capabilities for the first container and the second container to execute the second portion of the application code. In some implementations, the characteristic is a latency characteristic, which characterizes latencies for the first container and the second container to execute the second portion of the application code. In some instances, at least one characteristic may be determined dynamically based on a runtime evaluation of the system and its components. At 325, a request and the identified logic are dispatched to the second runtime container for executing the second portion of the application code. In some implementations, the dispatch of the request and the identified logic can be triggered by an invocation of an application programming interface (API) from an external entity outside of the first runtime container. Example invocation of an API can include a user clicks on a button or touches the touchscreen, an external application calls a web service, a web browser sends an HTTP Request, a sensor triggers a process (aka request) or, one runtime container calls another runtime container.
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 teachings of Gupta with the teachings of Schejter where the first and second functions execute in a first container and second container respectively. Gupta teaches of combing nanoservices/monolithic application and deploying a microservice in a third container. An external call to a web service or database interface is considered a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice ([0016]). Similarly, Schejter teaches of a first container that executes a first portion of code and a second container that executes a second portion of code. The containers can be associated with a database, web service, or other things. The invocation of the containers comes from an external entity outside of the containers that triggers the container or calls another container. This is similar to the external call and microservice process of Gupta, but emphasizes that the first and second functions are held within a container. This allows a runtime container to identify a portion of application code associated with the portion that is currently executed by the runtime container. Furthermore, the runtime container can identify one or more system components with which the identified portion of application code is associated. For example, when the execution of a portion of application code 175 involves the objects 165 associated with the repository 160, and the objects 165 have a data dependency with the client-side objects 150, a runtime container (not shown) may delegate the portion of application code 175 that involves the client-side objects to be executed at the client device 140. The delegation can involve dispatching the associated logic and sending a request to the client device 140. When the portion of the application code 175 identified based on data dependency is delegated to be executed by another system component, the system component can execute the portion of the application code 175 in parallel with the runtime container or in a subsequent time, as discussed in Schejter ([0029]). Therefore, optimizing both performance and resource utilization.
6. With regard to claim 3, Gupta further teaches:
wherein the first runtime comprises a computer language in which the first function is written ([0049] A monolithic application may be implemented using various programming languages (e.g., C#, Python, Java, etc.).).
7. With regard to claim 5, Schejter further teaches:
wherein determining the first runtime of the first function based on the first container configuration of the first container comprises:
scanning a fusion configuration that corresponds to a fusion of the first function and the second function, wherein the first container configuration comprises the fusion configuration ([0004] The first runtime container also identifies a first portion of the application code associated with the identified logic and executed by the first runtime container, and a second portion of the application code associated with the identified logic; [0043] At 310, a first portion of the application code associated with the identified logic is identified and executed by the first runtime container. In some instances, the first portion of the application code may correspond to the beginning portion of a logic flow associated with executing the application code. In such case, the runtime container is a runtime container included in a computing device that initiates and manages the execution of the application code; [0045] Example invocation of an API can include a user clicks on a button or touches the touchscreen, an external application calls a web service, a web browser sends an HTTP Request, a sensor triggers a process (aka request) or, one runtime container calls another runtime container.).
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 teachings of Gupta with the teachings of Schejter wherein determining the first runtime of the first function based on the first container configuration of the first container comprises: scanning a fusion configuration that corresponds to a fusion of the first function and the second function, wherein the first container configuration comprises the fusion configuration. Gupta teaches of combing nanoservices/monolithic application and deploying a microservice in a third container. An external call to a web service or database interface is considered a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice ([0016]). Similarly, Schejter teaches of a first container that executes a first portion of code and a second container that executes a second portion of code. The containers can be associated with a database, web service, or other things. The invocation of the containers comes from an external entity outside of the containers that triggers the container or calls another container. This is similar to the external call and microservice process of Gupta, but emphasizes that the first and second functions are held within a container. The containers include fusion information that determines which functions to merge. This allows a runtime container to identify a portion of application code associated with the portion that is currently executed by the runtime container. Furthermore, the runtime container can identify one or more system components with which the identified portion of application code is associated. For example, when the execution of a portion of application code 175 involves the objects 165 associated with the repository 160, and the objects 165 have a data dependency with the client-side objects 150, a runtime container (not shown) may delegate the portion of application code 175 that involves the client-side objects to be executed at the client device 140. The delegation can involve dispatching the associated logic and sending a request to the client device 140. When the portion of the application code 175 identified based on data dependency is delegated to be executed by another system component, the system component can execute the portion of the application code 175 in parallel with the runtime container or in a subsequent time, as discussed in Schejter ([0029]). Therefore, optimizing both performance and resource utilization.
8. With regard to claim 6, Schejter further teaches:
wherein determining the second runtime of the second function based on the second container configuration of the first container comprises:
scanning the fusion configuration that corresponds to the fusion of the first function and the second function, wherein the second container configuration comprises the fusion configuration ([0004] A second runtime container is then determined to execute the second portion of the application code, based on a policy or a characteristic associated with the application code, and a request and the identified logic are dispatched to the second runtime container for executing the second portion of the application code which in turn may continue to delegate the execution to additional runtime containers; [0044] At 315, a second portion of the application code associated with the identified logic is identified. The second portion of the application code may be identified based on a data dependency of the first portion of the application code included in compile-time information generated by a compiler.).
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 teachings of Gupta with the teachings of Schejter wherein determining the second runtime of the second function based on the second container configuration of the first container comprises: scanning the fusion configuration that corresponds to the fusion of the first function and the second function, wherein the second container configuration comprises the fusion configuration. Gupta teaches of combing nanoservices/monolithic application and deploying a microservice in a third container. An external call to a web service or database interface is considered a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice ([0016]). Similarly, Schejter teaches of a first container that executes a first portion of code and a second container that executes a second portion of code. The containers can be associated with a database, web service, or other things. The invocation of the containers comes from an external entity outside of the containers that triggers the container or calls another container. This is similar to the external call and microservice process of Gupta, but emphasizes that the first and second functions are held within a container. The containers include fusion information that determines which functions to merge. This allows a runtime container to identify a portion of application code associated with the portion that is currently executed by the runtime container. Furthermore, the runtime container can identify one or more system components with which the identified portion of application code is associated. For example, when the execution of a portion of application code 175 involves the objects 165 associated with the repository 160, and the objects 165 have a data dependency with the client-side objects 150, a runtime container (not shown) may delegate the portion of application code 175 that involves the client-side objects to be executed at the client device 140. The delegation can involve dispatching the associated logic and sending a request to the client device 140. When the portion of the application code 175 identified based on data dependency is delegated to be executed by another system component, the system component can execute the portion of the application code 175 in parallel with the runtime container or in a subsequent time, as discussed in Schejter ([0029]). Therefore, optimizing both performance and resource utilization.
9. Regarding claim 8, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
10. With regard to claim 11, Gupta further teaches:
wherein determining to combine the first function that executes in the first container and the second function that executes in the second container is based on determining that the first function invokes the second function ([0054] As will be described in further detail below, the application may be analyzed at runtime to generate a calling-context tree for grouping methods or functions into proposed microservices in addition to or in place of using keyword-based approaches. More generally, methods or functions of a monolithic application may be grouped into proposed microservices based on any desired shared characteristics, including combinations of keywords in method or function names, calling-context tree edges, etc; [0059] While the microservices design recommendation 400 included just six microservice candidates, the visualization 500 includes a visually appealing calling-context tree graph where functions are represented by circular nodes, and calls between functions are represented as edges connecting the nodes; Claims 7-9; Examiner’s Note: Functions are grouped into microservices based on function calls amount the plurality of functions.).
11. With regard to claim 13, Gupta further teaches:
wherein deploying the third container comprises:
accessing first source code of the first function and second source code of the second function from a repository ([0016] When a service or a method does not call other internal methods but calls an external service, such as a web service or a database interface, it may be considered as a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice; [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 (e.g., on one or more assets of the enterprise system 110) to generate a calling-context tree identifying interactions among the plurality of functions; [0051] The array [A1], also referred to as a reference array, provides a repository to store methods (e.g., method names and associated code));
packaging the first source code and the second source code into an image of the third container ([0016] Microservices-based software architectural design structures an application as a collection of loosely coupled services. Microservices-based software architectures may be viewed as a variant of a service-oriented architecture that focuses on fine-grained services, lightweight protocols, etc. Large, monolithic applications can be decomposed or disintegrated into sets of small independent and composable services, referred to herein as nanoservices. A nanoservice refers to a service that can be broken down into very small pieces, though not all small pieces of code are nanoservices. Nanoservices are deployable, reusable and useful. When a service or a method does not call other internal methods but calls an external service, such as a web service or a database interface, it may be considered as a nanoservice. A number of nanoservices may be grouped according to various characteristics (e.g., a common keyword in method or other function name) to form a microservice; [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. As development moves toward cloud-native approaches, it is desired to decompose, disintegrate or otherwise separate existing monolithic applications into microservices; [0049] FIGS. 3A-3E depict a process 300 for deconstructing a monolithic application into microservices using a semantic-based approach. To start 301, a monolithic application is selected by a user, such as via inputting a monolithic application name and location in step 303. A monolithic application may be implemented using various programming languages (e.g., C#, Python, Java, etc.). The monolithic application may also be implemented using various architectures (e.g., the monolithic application may be on a single platform, be divided on different platforms with each part having the same characteristics as the general monolithic application, etc.). Given the monolithic application name and location, a microservices design recommendation tool (e.g., 102) starts in 305 to disintegrate the selected monolithic application into a set of microservices by fetching the code of the monolithic application (e.g., from an application database or other data source); [0050] The process 300 proceeds to step 307, where a determination is made as to whether a file of the monolithic application is available for code scanning (e.g., whether there are any code files or code of the monolithic application not yet scanned). If the result of the step 307 determination is yes, the process 300 continues with step 309 and scans for available methods (e.g., to find candidates for nanoservices) by comparing against some general method or function syntax that is pre-defined within the microservices design tool. For example, if the monolithic application is written in the Java programming language, a method may be found by searching the code for the format or syntax of <modifier><return type><method name>(parameters . . . ) {. . . }. For other languages, an appropriate general method syntax may be used to find one or more methods in step 309.); and
deploying the image of the third container ([0017] A microservices architecture enables individual microservices to be deployed and scaled independently, such as via software containers.).
12. Regarding claim 15, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
13. With regard to claim 16, Gupta further teaches:
wherein the first runtime and the second runtime have different types ([0049] FIGS. 3A-3E depict a process 300 for deconstructing a monolithic application into microservices using a semantic-based approach. To start 301, a monolithic application is selected by a user, such as via inputting a monolithic application name and location in step 303. A monolithic application may be implemented using various programming languages (e.g., C#, Python, Java, etc.). The monolithic application may also be implemented using various architectures (e.g., the monolithic application may be on a single platform, be divided on different platforms with each part having the same characteristics as the general monolithic application, etc.). Given the monolithic application name and location, a microservices design recommendation tool (e.g., 102) starts in 305 to disintegrate the selected monolithic application into a set of microservices by fetching the code of the monolithic application (e.g., from an application database or other data source); [0050] The process 300 proceeds to step 307, where a determination is made as to whether a file of the monolithic application is available for code scanning (e.g., whether there are any code files or code of the monolithic application not yet scanned). If the result of the step 307 determination is yes, the process 300 continues with step 309 and scans for available methods (e.g., to find candidates for nanoservices) by comparing against some general method or function syntax that is pre-defined within the microservices design tool. For example, if the monolithic application is written in the Java programming language, a method may be found by searching the code for the format or syntax of <modifier><return type><method name>(parameters . . . ) {. . . }. For other languages, an appropriate general method syntax may be used to find one or more methods in step 309.).
14. Regarding claim 17, it is rejected under the same reasoning as claim 3 above. Therefore, it is rejected under the same rationale.
15. Regarding claim 19, it is rejected under the same reasoning as claim 5 above. Therefore, it is rejected under the same rationale.
16. Regarding claim 20, it is rejected under the same reasoning as claim 6 above. Therefore, it is rejected under the same rationale.
17. Claims 4 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta US 20210124577 A1 and Schejter et al. US 20130263139 A1, as applied in claim 1, in further view of Dunham et al. US 11531526 B1.
18. With regard to claim 4, Gupta and Schejter teach the system of claim 1 but fails to explicitly teach wherein the first runtime comprises a version of the computer language in which the first function is written.
However, in analogous art, Dunham teaches:
wherein the first runtime comprises a version of the computer language in which the first function is written (Col. 5, lines 1-14, The application transfer tool may read the serverless application template to identify definitions for serverless functions of the serverless application. A function definition may specify various properties of a respective serverless function, such as a runtime environment, source code information, function triggering events, memory requirements, environment variables, and others. The application transfer tool may then create a container file for the serverless function based at least in part on these definitions. For example, if a function definition specifies a given type of runtime environment (e.g., NodeJS, version 12), then the application transfer tool may employ a container image having the specified type of runtime environment as a base image for the container file.).
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 teachings of Gupta and Schejter with the teachings of Dunham wherein the first runtime comprises a version of the computer language in which the first function is written. In order to deploy a container, it is important to have information that specifies runtime environment, source code information, etc. in order to ensure the container meets desired standards. By specifying a version of the computer language, the container can be properly deployed and ensure that it operates correctly.
19. Regarding claim 18, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
20. Claims 7, 9-10, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta US 20210124577 A1 and Schejter et al. US 20130263139 A1, as applied in claim 1, in further view of Jung et al. US 20200225917 A1.
21. With regard to claim 7, Gupta and Schejter teach the system of claim 1 but fails to explicitly teach wherein determining the first runtime of the first function based on the first container configuration of the first container comprises: performing a code scan of a container configuration file of the first container configuration.
However, in analogous art, Jung teaches:
wherein determining the first runtime of the first function based on the first container configuration of the first container comprises:
performing a code scan of a container configuration file of the first container configuration ([0021] To address these and other similar issues, FaaS service layer 104 of FIG. 1 is enhanced to include an admin image management tool 112, a developer image management tool 114, and an installed software catalog 116. Components 112, 114, and 116 may be implemented in software, hardware, or a combination thereof. At a high level, admin image management tool 112 can enable the administrators of FaaS infrastructure 100 to create curated base images and one or more curated lists of software (comprising, e.g., names and versions) that have been vetted and approved by the administrators as being safe for use/execution on the hosts of infrastructure 100. The curated base images can include system-level libraries, drivers, and a language runtime that are specific to the OS platform of FaaS hosts 102(1)-(N). The curated lists of software can include application and/or system-level libraries, packages, frameworks, etc. that are common dependencies for functions that are uploaded to FaaS infrastructure 100; [0022] By way of example, an administrator may create (1) a first base image B1 that includes system-level software and a language runtime for the Python programming language, (2) a second base image B2 that includes system-level software and a language runtime for the Java programming language, (3) a first list of curated software that is associated with base image B1 and comprises software components S1 (version 1.0), S2 (version 1.0), and S3 (version 1.5), and (3) a second list of curated software that is associated with base image B2 and comprises software components S4 (version 2.0) and S5 (version 1.1); [0036] In a particular embodiment, the determination at block 306 can be made by looking at the curated base image selected by the user for this custom image and identifying all of the administrator-defined curated software lists that are associated with the selected base image; Examiner’s Note: The curated base image (configuration file) includes a language runtime. The configuration file is looked at to identify things like runtime.).
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 teachings of Gupta and Schejter with the teachings of Jung wherein determining the first runtime of the first function based on the first container configuration of the first container comprises: performing a code scan of a container configuration file of the first container configuration. Similarly to Thoemmes and Gupta, Jung teaches of implementing curated image management in a Functions-as-a-Service (FaaS) infrastructure (Abstract). Moreover, Jung teaches of looking at a configuration file in order to determine runtime information. This is help in image deployment because it ensures that containers are deployed correctly with all aspects in mind. These could include dependency, runtime environment, software versions, etc. Proper deployment of containers with all necessary aspects ensures smooth execution; therefore, preventing any faults that could inhibit consumer usage.
22. With regard to claim 9, Jung further teaches:
further comprising:
in response to determining that language information of the first runtime is omitted from a fusion configuration that corresponds to a fusion of the first function and the second function, performing, by the system, a code scan of a container configuration file of the first container configuration ([0021] To address these and other similar issues, FaaS service layer 104 of FIG. 1 is enhanced to include an admin image management tool 112, a developer image management tool 114, and an installed software catalog 116. Components 112, 114, and 116 may be implemented in software, hardware, or a combination thereof. At a high level, admin image management tool 112 can enable the administrators of FaaS infrastructure 100 to create curated base images and one or more curated lists of software (comprising, e.g., names and versions) that have been vetted and approved by the administrators as being safe for use/execution on the hosts of infrastructure 100. The curated base images can include system-level libraries, drivers, and a language runtime that are specific to the OS platform of FaaS hosts 102(1)-(N). The curated lists of software can include application and/or system-level libraries, packages, frameworks, etc. that are common dependencies for functions that are uploaded to FaaS infrastructure 100; [0022] By way of example, an administrator may create (1) a first base image B1 that includes system-level software and a language runtime for the Python programming language, (2) a second base image B2 that includes system-level software and a language runtime for the Java programming language, (3) a first list of curated software that is associated with base image B1 and comprises software components S1 (version 1.0), S2 (version 1.0), and S3 (version 1.5), and (3) a second list of curated software that is associated with base image B2 and comprises software components S4 (version 2.0) and S5 (version 1.1); [0036] In a particular embodiment, the determination at block 306 can be made by looking at the curated base image selected by the user for this custom image and identifying all of the administrator-defined curated software lists that are associated with the selected base image; Examiner’s Note: The curated base image (configuration file) includes a language runtime. The configuration file is looked at to identify things like language.).
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 teachings of Gupta and Schejter with the teachings of Jung wherein determining the first runtime of the first function based on the first container configuration of the first container comprises: performing a code scan of a container configuration file of the first container configuration. Similarly to Thoemmes and Gupta, Jung teaches of implementing curated image management in a Functions-as-a-Service (FaaS) infrastructure (Abstract). Moreover, Jung teaches of looking at a configuration file in order to determine language information. This is help in image deployment because it ensures that containers are deployed correctly with all aspects in mind. These could include dependency, runtime environment, software versions, etc. Proper deployment of containers with all necessary aspects ensures smooth execution; therefore, preventing any faults that could inhibit consumer usage.
23. With regard to claim 10, Jung further teaches:
further comprising:
in response to determining that version information of the first runtime is omitted from a fusion configuration that corresponds to a fusion of the first function and the second function, performing, by the system, a code scan of a container configuration file of the first container configuration ([0021] To address these and other similar issues, FaaS service layer 104 of FIG. 1 is enhanced to include an admin image management tool 112, a developer image management tool 114, and an installed software catalog 116. Components 112, 114, and 116 may be implemented in software, hardware, or a combination thereof. At a high level, admin image management tool 112 can enable the administrators of FaaS infrastructure 100 to create curated base images and one or more curated lists of software (comprising, e.g., names and versions) that have been vetted and approved by the administrators as being safe for use/execution on the hosts of infrastructure 100. The curated base images can include system-level libraries, drivers, and a language runtime that are specific to the OS platform of FaaS hosts 102(1)-(N). The curated lists of software can include application and/or system-level libraries, packages, frameworks, etc. that are common dependencies for functions that are uploaded to FaaS infrastructure 100; [0022] By way of example, an administrator may create (1) a first base image B1 that includes system-level software and a language runtime for the Python programming language, (2) a second base image B2 that includes system-level software and a language runtime for the Java programming language, (3) a first list of curated software that is associated with base image B1 and comprises software components S1 (version 1.0), S2 (version 1.0), and S3 (version 1.5), and (3) a second list of curated software that is associated with base image B2 and comprises software components S4 (version 2.0) and S5 (version 1.1); [0036] In a particular embodiment, the determination at block 306 can be made by looking at the curated base image selected by the user for this custom image and identifying all of the administrator-defined curated software lists that are associated with the selected base image; Examiner’s Note: The curated base image (configuration file) includes software component versions. The configuration file is looked at to identify things like version information.).
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 teachings of Gupta and Schejter with the teachings of Jung wherein determining the first runtime of the first function based on the first container configuration of the first container comprises: performing a code scan of a container configuration file of the first container configuration. Similarly to Thoemmes and Gupta, Jung teaches of implementing curated image management in a Functions-as-a-Service (FaaS) infrastructure (Abstract). Moreover, Jung teaches of looking at a configuration file in order to determine version information. This is help in image deployment because it ensures that containers are deployed correctly with all aspects in mind. These could include dependency, runtime environment, software versions, etc. Proper deployment of containers with all necessary aspects ensures smooth execution; therefore, preventing any faults that could inhibit consumer usage.
24. Regarding claim 21, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
25. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta US 20210124577 A1 and Schejter et al. US 20130263139 A1, as applied in claim 8, in further view of Coleman et al. US 20160147529 A1.
26. With regard to claim 12, Gupta and Schejter teach the method of claim 8 but fails to explicitly teach wherein deploying the third container comprises: terminating the first container; and terminating the second container.
However, in analogous art, Coleman teaches:
wherein deploying the third container comprises:
terminating the first container; and terminating the second container ([0074] At block 443, the processing device can create a third container to host the source code. For example, the processing device can create the third container using the image. At block 445, the processing device can remove the second container. In some embodiments, the processing device can remove the second container upon creating and/or starting the third container from the image. Additionally, the processing device can remove one or more previously created application containers (e.g., “old containers” that were previously created for the application prior to the creation of the third container).).
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 teachings of Gupta and Schejter with the teachings of Coleman wherein deploying the third container comprises: terminating the first container; and terminating the second container. Once the third container is deployed, it is important to terminate the previous containers in order to maintain and organized environment, as discussed in Coleman ([0013]; [0048]). Deleting old containers helps free memory, maintains an organized environment, and prevents conflicts by ensuring the latest version of the application is the one executing.
27. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta US 20210124577 A1, as applied in claim 13, in further view of Miller et al. US 20210342145 A1.
28. With regard to claim 14, Gupta teaches the method of claim 13 but fails to explicitly teach wherein the packaging and the deploying are performed by a continuous integration and continuous deployment component.
However, in analogous art, Miller teaches:
wherein the packaging and the deploying are performed by a continuous integration and continuous deployment component ([0027] Once a serverless function has been completed and tested, a build service can take platform source code 211 in a workspace 205 and performs appropriate build operations for the various platform components to prepare the serverless function for deployment. The build services outputs a buildpack that includes the serverless function and related metadata amongst other information. A deploy service 231 receives the buildpack and performs deployment operations for the various built platform components including installing metadata 251 into the multi-tenant platform 101 and the serverless function 253 into the elastic runtime 103. The metadata defines the interfaces, calls, triggers, event handling, and similar mechanisms by which the components of the multi-tenant platform 101 can access the serverless function 253 in the elastic runtime 103. The deployment service 231 deploys and configures exposure and secure connections for the appropriate substrate (e.g., Apex, elastic runtime for polyglot such as Java or Node.js). Serverless function metadata 251 is deployed to the function registry 113 of the elastic runtime 101 HTTPS/REST endpoints or similar interfaces are registered with the API Gateway 111. Core metadata within the metadata 251 is deployed to the appropriate org-based environment of the multi-tenant platform 101, including references to the serverless functions 253; [0028] In some implementations, continuous integration (CI)/continuous delivery (CD) integration support is provided, where the workspace CU and elastic runtime APIs can be integrated into CI/CD tools 261 (e.g., Circle CI, GitHub CI, Jenkins, and Spinnaker).).
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 teachings of Gupta with the teachings of Miller wherein the packaging and the deploying are performed by a continuous integration and continuous deployment component. Miller teaches of deploying a function in a polyglot serverless elastic runtime execution environment. Additionally, Miller teaches where the packaging and deploying is done by a CI/CD component ([0028]). Utilizing a CI/CD component is extremely beneficial because it automates the software delivery pipeline. This prevents manual errors and provides for faster and reliable application updates; therefore, ensuring improved consumer usage.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AN-AN N NGUYEN whose telephone number is (571)272-6147. The examiner can normally be reached Monday-Friday 8:00-5:00 ET.
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, AIMEE LI can be reached at (571) 272-4169. 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.
/AN-AN NGOC NGUYEN/Examiner, Art Unit 2195
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights