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
This is the initial Office action based on the application filed on March 6, 2024.
Claims 1-20 are presently pending in the application have been examined below, of which, claims 1 and 11 are presented in independent form.
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-2 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248058 (hereinafter "Hattingh”) in view of US 11,550,562 (hereinafter “Josza”) and further in view of US 2020/0174840 (hereinafter “Zhao).
In the following claim analysis, Applicant’s claim limitations are presented in bold text, the Examiner’s explanations, notes, and remarks are enclosed in square brackets; and emphasized portions are underlined.
As to claim 1, Hattingh discloses A method for developing a containerized application using an opinionated pipeline to facilitate subsequent deployment of the containerized application to a cloud environment (Hattingh, Abstract, Techniques for feature-based deployment pipelines. … The feature-based deployment pipelines invoke sequential stages to enable feature branches of an application to be fully tested before proceeding to a succeeding stage. At each stage, relevant stakeholders are able to evaluate the new features before they become part of the master image of the tested application. A variety of validation and performance tests are conducted at each stage, resulting in a fully vetted application available for a consumer; ¶ 43, send the application out as a single package. Docker™ works well with Jenkins™ and its containers may be deployed in a cloud), the method comprising the steps of:
receiving an application containing original code (Hattingh, Fig. 3, ¶ ¶ 52-53, A large number of feature branches 302 may be separately and independently generated for the application program 122 by the developers. The application program 122 may not include all feature branches, but only those that successfully become part of the master branch);
generating a variable file based on parameters selected by a developer of the application (Hattingh, Fig. 4-6, ¶ 59, The solution codebase 102 uses the tools, such as the service file 104 (e.g., AppSvc.json), container orchestration system 106 (e.g., Kubernetes™) continuous integration service 108 (e.g., Jenkins™), as well as the many additional tools described above, to enable the environment, including feature branches and endpoints, that will enable the application program 122 to be tested; ¶ 61, A developer 402 initiates the sandbox stage 400 by launching a project repository 406 (e.g., a Git Project™, or the like), which includes several files. Git Project™ is a Git™ command that creates a Git™ repository. The Git™ repository tracks all changes made to files on the project);
using the parameters to select a plurality of application development processes and tools from a set of available tools and processes (Hattingh, Fig. 4-6, ¶ 61, A developer 402 initiates the sandbox stage 400 by launching a project repository 406 (e.g., a Git Project™, or the like), which includes several files; ¶ ¶ 62-65, Once the feature branch pull request 418 is made, the feature branch 302 goes into the CI/CD systems 424, which is created by the continuous integration service 108 … At this point, basic building and testing of the feature branch are done, after which the feature branch goes through a unit test, static analysis, vetting, compile, and linking 426); and
packaging the containerized application (Hattingh, ¶ 43, containers allow the developers to package up an application with the parts needed by the application, such as libraries and dependencies, and send the application out as a single package).
Hattingh discloses a plurality of application development processes and tools from a set of available tools and processes, such as processes and tools for basic building, testing of the feature, static analysis, vetting, compiling, and linking (Hattingh, ¶ ¶ 62-65), but does not appear to explicitly disclose dynamically provisioning the opinionated pipeline to include the plurality of application development processes and tools; implementing the opinionated pipeline; the intended use: in order to develop the containerized application by combining a set of code with the original code, the set of code associated with the plurality of application development processes and tools; modifying the set of code based on selections made by the developer to provide modified code; and to include at least a portion of the original code and the modified code as the application content to result in the containerized application.
However, in an analogous art to the claimed invention in the field of software development, Zhao teaches dynamically provisioning the opinionated pipeline (Zhao, ¶ 51, the resource manager module 270 provisions logical nodes and resources across the server cluster to dynamically compose the data flow pipeline 230, and the client node 210 orchestrates the data I/O, preprocessing, and staging operations that are performed by the logical nodes of the data flow pipeline 230) and implementing the opinionated pipeline (Zhao, Fig. 7, ¶ 73, a cloud computing environment in which techniques according to embodiments of the invention are implemented for dynamically composing and implementing a data flow pipeline).
Therefore, the combination of Hattingh and Zhao teaches dynamically provisioning the opinionated pipeline (Zhao, ¶ 51) to include the plurality of application development processes and tools (Hattingh, ¶ ¶ 62-65).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh with the teaching taught by Zhao. The modification would be obvious because one of ordinary skill in the art would be motivated to dynamically compose a data flow pipeline such that cluster wide resources, including storage nodes for I/O, CPU nodes for pre-processing, and server nodes (e.g., GPU nodes) for deep learning model training, can be better utilized in a more balanced way, improving the performance and scalability (Zhao, ¶ 51).
Hattingh as modified does not appear to explicitly disclose the intended use: in order to develop the containerized application by combining a set of code with the original code, the set of code associated with the plurality of application development processes and tools; modifying the set of code based on selections made by the developer to provide modified code; and to include at least a portion of the original code and the modified code as the application content to result in the containerized application. However, in an analogous art to the claimed invention in the field of software development, Josza teaches the intended use: in order to develop the containerized application by combining a set of code with the original code, the set of code associated with the plurality of application development processes and tools (Josza, Fig. 3, col. 17, ln.52-58, the computing platform 102 can determine, based on the comparing in operation 306, if the application 120 should be changed (e.g., if a function 116 should be added to the application 120, if a function 116 should be removed from the application 120, if the application 120 should be deployed to a particular computing environment 122’ col. 18, ln. 27-37, the computing platform 102 can determine whether or not the application 120 is to be changed based on settings [pointing to processes], configurations [for tools]); modifying the set of code based on selections made by the developer to provide modified code (Josza, Fig. 3, col. 18, ln. 38-53, If the computing platform 102 determines, in operation 310, that the application 120 is to be changed, the method 300 can proceed to operation 312. At operation 312, the computing platform 102 can update the application 120. According to various embodiments of the concepts and technologies disclosed herein, the application 120 can be updated to add a function 116 (in an associated container 118) to the application 120; to remove a function 116 (and its associated container 118) from the application 120; to change a target computing environment (e.g., based on a change to the operating system and/or platform associated with the application 120); and to include at least a portion of the original code and the modified code as the application content to result in the containerized application (Josza, Fig. 3, col. 18, ln. 50-53, virtualizing a new function as a new function 116, adding the new function 116 to a new container 118, and adding the container 118 that includes the function 116 to the application 120).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh as modified with the teaching taught by Josza. The modification would be obvious because one of ordinary skill in the art would be motivated to package one or more portions of the software code in one or more associated containers, which can enable standardization of each piece of functionality of the software package (Josza, col. 9, ln. 3-22).
As to claim 2, the rejection of claim 1 is incorporated. Hattingh as modified further discloses The method of claim 1 further comprising selecting one or more binders based on the parameters and deploying the containerized application to the cloud environment by applying the one or more binders to the containerized application to result in a deployed version of the containerized application (Hattingh, ¶ 43, The solution codebase 102 also utilizes a container deployment system 112, such as Docker™. Docker™ is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow the developers to package up an application with the parts needed by the application, such as libraries and dependencies, and send the application out as a single package. Docker™ works well with Jenkins™ [a binder] and its containers may be deployed in a cloud).
As to claims 11-12, the claims are system claims corresponding to method claims 1-2. And Hattingh also teaches one or more computer processors in communication with a memory storing a set of executable instructions for execution by the computer processor (Hattingh, ¶ 48, the FBDP apparatus 200 consists of a he FBDP apparatus 200 consists of a processor 202 and memory 204 connected to one another by a bus 208. The processor 202 may be circuitry arranged to execute instructions). Therefore, they are rejected under the same rational set forth in the rejections of claim 1-2.
Claims 3, 5-8, 10, 14 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248058 (hereinafter "Hattingh”) in view of US 11,550,562 (hereinafter “Josza”) in view of US 2020/0174840 (hereinafter “Zhao), and further in view of US 2023/0188613 (hereinafter “Velammal”).
As to claim 3, the rejection of claim 1 is incorporated. Hattingh as modified does not appear to explicitly disclose The method of claim 1 further comprising implementing a comparison of the application content against policy content using static code analysis. However, in an analogous art to the claimed invention in the field of software development, Velammal teaches The method of claim 1 further comprising implementing a comparison of the application content against policy content using static code analysis (Velammal. ¶ 59, the migration parameters including the cloud impediments, the tech-stack suitability score, and the anti-patterns are evaluated by analyzing the source code of the application using static code analysis techniques based on a predefined set of rules).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh as modified with the teaching taught by Velammal. The modification would be obvious because one of ordinary skill in the art would be motivated to analyze each file in the retrieved source code zip folder for evaluating the cloud impediments, the tech-stack suitability score, and the anti-patterns (Velammal, ¶ 59).
As to claim 5, the rejection of claim 1 is incorporated. Hattingh as modified further discloses The method of claim 1, wherein the set of code includes code template content selected from the group consisting of: policy content; security content; selected environment content, code option content, and use case content (Velammal, ¶ 48, the pre-configured deployment templates include, but are not limited to, deployment yaml templates, configMap yaml template, service yaml internal template and service yaml external templates. … each of the deployment temples are customizable and support Kubernetes based cloud platforms. ….the pre-configured templates may be customized and uploaded by the user via the GUI as per the migration requirements. …. the pre-configured templates comprise one or more placeholders; ¶ 49, a value of each of one or more placeholders associated with the selected pre-configured deployment template are evaluated based on the runtime data of the application ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh as modified with the teaching taught by Velammal. The modification would be obvious because one of ordinary skill in the art would be motivated to facilitate user interaction and allow users to select one or more target cloud platforms, illustrate detailed migration readiness report, select deployment configuration templates as per the selected target cloud platform, and select migration settings amongst other things (Velammal, ¶ 31).
As to claim 6, the rejection of claim 1 is incorporated. Hattingh as modified further discloses The method of claim 1 further comprising obtaining the parameters as application parameters as provided an onboarding process (Velammal. ¶ 49, the migration unit 126 is configured to generate the deployment configurations as per the target cloud platform by selecting a pre-configured deployment template as per the target cloud platform. Further, a value [a parameter] of each of one or more placeholders associated with the selected pre-configured deployment template are evaluated based on the runtime data of the application and equivalent backing services of the target cloud platform). The motivation to combine the references is the same as set forth in the rejection of claim 5.
As to claim 7, the rejection of claim 6 is incorporated. Hattingh as modified further discloses the claim limitation user interface configuration (Velammal, ¶ 48, the pre-configured deployment templates include, but are not limited to, deployment yaml templates, configMap yaml template, service yaml internal template and service yaml external templates. … each of the deployment temples are customizable and support Kubernetes based cloud platforms. ….the pre-configured templates may be customized and uploaded by the user via the GUI as per the migration requirements) in the method of claim 6, wherein content of the application parameters includes code content related to application features selected from the group consisting of; program language, user interface configuration, business unit operational features, business unit process features, and business unit differences. The motivation to combine the references is the same as set forth in the rejection of claim 5.
As to claim 8, the rejection of claim 6 is incorporated. Hattingh as modified further discloses The method of claim 7, wherein the content include at least one of a specified platform (Velammal. ¶ 49, the migration unit 126 is configured to generate the deployment configurations as per the target cloud platform by selecting a pre-configured deployment template as per the target cloud platform. Further, a value of each of one or more placeholders associated with the selected pre-configured deployment template are evaluated based on the runtime data of the application and equivalent backing services of the target cloud platform), a specified security requirement, and / or a specified functionality for the containerized application. The motivation to combine the references is the same as set forth in the rejection of claim 5.
As to claim 10, the rejection of claim 3 is incorporated. Hattingh as modified further discloses The method of claim 3, wherein the policy content is related to security of network communication (Velammal, ¶ 59, the predefined set of rules are regular expression rules (regex rules) categorized into, but not limited to, anti-pattern regex rules [including security of network communication rules], tech stack suitability evaluation regex rules, tech stack summary regex rules, impediment identification regex rules, and backing services recommendation rules).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh as modified with the teaching taught by Velammal. The modification would be obvious because one of ordinary skill in the art would be motivated to evaluate cloud impediments, tech-stack suitability score, and anti-patterns by analyzing the source code using static code analysis techniques based on a predefined set of rules (Velammal, ¶ 38).
As to claims 14 and 16-18, the claims are system claims corresponding to method claims 3 and 6-8. Therefore, they are rejected under the same rational set forth in the rejections of the method claims.
Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248058 (hereinafter "Hattingh”) in view of US 11,550,562 (hereinafter “Josza”) in view of US 2020/0174840 (hereinafter “Zhao), in view of US 2023/0188613 (hereinafter “Velammal”), and further in view of CN 110058863 (hereinafter “Du”).
As to claim 4, the rejection of claim 1 is incorporated. Hattingh as modified does not appear to explicitly disclose The method of claim 3 further comprising modifying content of the variables in the variable file in order to direct customization of the containerized application development. However, in an analogous art to the claimed invention in the field of software development, Du teaches The method of claim 3 further comprising modifying content of the variables in the variable file in order to direct customization of the containerized application development (Du, pg. 9, the last paragraph, when receiving the container build instructions, display parameter selection input interface, receiving user based on build parameters of the selected input interface. wherein the constructing parameter comprises the starting parameter, starting parameter includes an application name and a code address. i.e., for identifying the target application of the application name, the code address is to generate code needed by the Docker mirror image downloading address. a build platform of the Docker container can be adjusted according to the code address, downloading application code the target application corresponding to the application code is stored to build platform of a Docker container).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh as modified with the teaching taught by Du. The modification would be obvious because one of ordinary skill in the art would be motivated to provide a uniform distribution process optimization, such that the user only needs to fill the corresponding build parameters to realize the container configuration, which not only saves the labor cost, reduces the construction difficulty of the container, but also based on the integral of the configuration template, which is convenient for uniform management of the container group, and improves the user experience (Du, Abstract).
As to claim 15, the claim is a system claim corresponding to method 4. Therefore, it is rejected under the same rational set forth in the rejection of the method claim.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248058 (hereinafter "Hattingh”) in view of US 11,550,562 (hereinafter “Josza”) in view of US 2020/0174840 (hereinafter “Zhao), further in view of US 9483240 (hereinafter “Boyar”).
As to claim 9, the rejection of claim 1 is incorporated. Hattingh as modified does not appear to explicitly disclose The method of claim 1 further comprising a failure in application of at least one of the one or more binders. However, in an analogous art to the claimed invention in the field of Dependency analysis, Boyar teaches The method of claim 1 further comprising a failure in application of at least one of the one or more binders (Boyar, col. 21, ln. 1-6, After determining the above list of invalidate flags and performing the above binding expression analysis, preprocessor module 362 generates source code that, when executed, causes an application to determine when binding expressions are invalid).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh as modified with the teaching taught by Boyar. The modification would be obvious because one of ordinary skill in the art would be motivated to only valuate those data binding expressions that should be evaluated whenever the application package 328 determines that the particular data binding expressions have become invalid or otherwise need reevaluating instead of requiring application package 328, while executing at a computing device, to repeatedly have to reevaluate all of the data binding expressions of an entire layout defined in application resources 320 each time a component of the layout changes (Boyar, col. 17, ln. 34-54).
As to claim 19, the claim is a system claim corresponding to method 9.Therefore, it is rejected under the same rational set forth in the rejection of the method claim.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248058 (hereinafter "Hattingh”) in view of US 11,550,562 (hereinafter “Josza”) in view of US 2020/0174840 (hereinafter “Zhao), further in view of US 11252655 (hereinafter “Gupta”).
As to claim 13, the rejection of claim 12 is incorporated. Hattingh as modified does not appear to explicitly disclose The system of claim 12 further comprising a control plane for implementing the one or more binders using an orchestration sequence. However, in an analogous art to the claimed invention in the field of application migration, Gupta teaches The system of claim 12 further comprising a control plane for implementing the one or more binders using an orchestration sequence (Gupta, col. 13, ln. 46-47,When the control plane executes a live migration workflow [an orchestration sequence] it can create a new “inactive” domain [as a binder] associated with the instance).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Hattingh as modified with the teaching taught by Gupta. The modification would be obvious because one of ordinary skill in the art would be motivated to adapt live migration process by moving a running virtual machine or application between different physical machines without significantly disrupting the availability of the virtual machine (e.g., the down time of the virtual machine is not noticeable by the end user) (Gupta, col. 13, ln. 42-45).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0248058 (hereinafter "Hattingh”) in view of US 11,550,562 (hereinafter “Josza”) in view of US 2020/0174840 (hereinafter “Zhao), in view of US 11252655 (hereinafter “Gupta”), and further in view of Velammal.
As to claim 20, the rejection of claim 13 is incorporated. Hattingh as modified does not appear to explicitly disclose The system of claim 13, wherein the policy content is related to security of network communication. However, in an analogous art to the claimed invention in the field of software development, Velammal teaches The system of claim 13, wherein the policy content is related to security of network communication (Velammal, ¶ 59, the predefined set of rules are regular expression rules (regex rules) categorized into, but not limited to, anti-pattern regex rules [including security of network communication rules], tech stack suitability evaluation regex rules, tech stack summary regex rules, impediment identification regex rules, and backing services recommendation rules). The motivation to combine the references is the same as set forth in the rejection of claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11599348 teaches a process of container image building using shared resources; and
US 2022/0222096 teaches managing a container integration pipeline in software system that allows developers to customize the deployment of containers into a cloud computing platform.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAXIN WU whose telephone number is (571) 270-7721. The examiner can normally be reached on M-F (7 am - 11:30 am; 1:30- 5 pm).
If attempts to reach the examiner by telephone are unsuccessful, the examiner' s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/DAXIN WU/
Primary Examiner, Art Unit 2191