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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over McClory et al. (US20180324204A1) in view of Sharma et al. (US20230409464A1)
Regarding Claim 1, McClory teaches a method performed by at least one processor for building and deploying containerized software services during software development, comprising: accessing code from a code repository corresponding to a software service (McClory, [0053] "In an embodiment, the application source code data store 250 may be generally configured to store the source code for an application (i.e., application source code information 260). In an embodiment, the application source code data store 250 may be further configured to store one or more workflows configured to continuously integrate, test, and/or deploy the application, which may be represented as pipeline configuration information 262." [0089] "In an embodiment, the SCM configuration component 314-1 may be generally configured to enable the creation and/or provisioning of application source code data store (e.g., application source code data store 250) for storing application source code represented as application source code information (e.g., application source code information 260). The SCM configuration component 314-1 may be generally configured to provision an application source code data store in a public or private source code hosting facility (e.g., GitHub, GitLab, etc.) in response to receiving a request from the application orchestration component 312-1 during the initial creation and deployment of an application.")
generating a template for the software service based on the code; storing the template in a template repository (McClory, [0042] "In an embodiment, each container instance may be created and hosted by the container engine 134 based on a container application image, which may include, without limitation, the container OS image, the container application(s), and associated container components. Thus, the container applications 136 may be hosted and managed by the one or more container engines 134 and defined by its associated container application images. In an embodiment, each container engine of the one or more container engines 134 may also be configured to host and manage the execution of one or more container applications created and deployed by the AADDOMA 162." [0088] "In an embodiment, the application deployment component 314 may generally include, without limitation, source code management (SCM) configuration component 314-1, code analysis component 314-2, image component 314-3, integration and deployment component 314-4, artifact repository component 314-5, and performance and testing component 314-6. These components may be operatively and/or communicatively coupled to each other and generally configured to: (1) provide an integration and testing workflow to continuously integrate, test, and deploy an application; (2) perform code analysis on the application source code and provide code analysis information to the application developers and their organization; and (3) enable the modification of the testing workflow to include test logic gates and provide testing as a service.")
detecting a vulnerability in the code (McClory, [0090-0091]) "In an embodiment, the code analysis component 314-2 may be generally configured to perform code analysis (e.g., static code analysis using SonarQube, COMPUWARE Topaz, Twistlock, etc.) to analyze the application source code information (e.g., application source code information 260) stored in an application source code data store (e.g., application source code data store 250) in order to identify and report one or more errors in the source code (e.g., duplicate code, syntax errors, logic errors, memory leaks, security vulnerabilities, etc.). In an embodiment, the code analysis component 314-2 may be configured to analyze the application source code information and provide the code analysis information in response to a request to perform code analysis.")
generating an updated template based on the updated code (McClory, [0096] ""To enable at least continuous integration and testing, the integration and deployment component 314-4 may be further configured to: (1) detect changes or updates in the application source code data store (e.g., application source code data store 250) that indicate an update to the application source code information for an application; (2) retrieve the pipeline configuration information associated with the application source code information from the application source code data store; (3) perform the building and testing of the application in accordance with the retrieved pipeline configuration information; and (4) generate testing report information that includes one or more test results. Additionally or alternatively, the integration and deployment component 314-4 may be configured to automatically perform integration and testing on a periodic basis (e.g., every eight (8) hours, every twenty four (24) hours, etc.). In an embodiment, the integration and deployment component 314-4 may also be configured to detect one or more binary repository update events during the execution or interpretation of the integration workflows and testing workflows.")
deploying the updated template to a container orchestration platform (McClory, [0056] and [0096-0097] "To enable at least continuous integration and testing, the integration and deployment component 314-4 may be further configured to: (1) detect changes or updates in the application source code data store (e.g., application source code data store 250) that indicate an update to the application source code information for an application; (2) retrieve the pipeline configuration information associated with the application source code information from the application source code data store; (3) perform the building and testing of the application in accordance with the retrieved pipeline configuration information; and (4) generate testing report information that includes one or more test results. Additionally or alternatively, the integration and deployment component 314-4 may be configured to automatically perform integration and testing on a periodic basis (e.g., every eight (8) hours, every twenty four (24) hours, etc.). In an embodiment, the integration and deployment component 314-4 may also be configured to detect one or more binary repository update events during the execution or interpretation of the integration workflows and testing workflows. In response to the detection of binary repository update events, the integration and deployment component 314-4 may verify the set of generated build artifacts including an application for testing and initiate the execution or interpretation of the testing workflow to test the application.")
generating an instance of the software service with the container orchestration platform based on the updated template (McClory, [0039] "It may be appreciated that while load balancer devices 118 are illustrated as separate devices in FIG. 1, at least a portion of the functionality of the load balancer devices 118 may be performed by a load balancer application (not shown). For example, instead of the one or more load balancer devices 118 performing the functionalities discussed above, a load balancer application (e.g., AMAZON Elastic Load Balancer, GOOGLE Cloud Load Balancer, etc.), which may be implemented as one or more container applications 136 and/or native applications 138 deployed and executed by the one or more server devices 122 and/or 124. In some embodiments, the load balancer application may be configured to implement some or even all the functionalities of the load balancer devices 118. Thus, in some embodiments, the load balancer application may be configured to receive incoming network traffic and route or distribute incoming network traffic among multiple server devices 122, guest operating systems 132, and/or container applications 136 and/or native applications 138.")
However, McClory is not relied on for:
responsive to detecting the vulnerability in the code: updating the code to mitigate the vulnerability
Sharma teaches responsive to detecting the vulnerability in the code: updating the code to mitigate the vulnerability (Sharma, [0025-0027] "At stage A, a software development pipeline 201 that includes or invokes the remediation agent 117 is run. The software development pipeline 201 may be run upon detection of submission of a code change to a software project or run manually by a software developer. In this illustration, running the software development pipeline 201 involves building, testing, and scanning the software project with the submitted code change. The scan stage of the pipeline 201 generates scan results 203A (e.g., static scan results) that indicate flaws detected from the scanning. At stage B, the remediation agent 117 determines whether any of the detected flaws can be remediated with a fix template. The remediation agent 117 evaluates the detected flaws against automatic remediation rules. The automatic remediation rules can be defined to search for patterns (e.g., string patterns) of a flaw. A matching pattern is associated with a fix template in the fix templates repository 121. For example, the remediation agent 117 can search the fix template repository 121 for code flaw patterns that match one or more of the detected flaws, which may be a complete or partial match of code corresponding to the flaw. If a match is found, then the template repository 121 returns a template that specifies how to remediate the code (e.g., code string(s) to replace, code to remove, and/or code to insert). The patterns can be based on source code or an intermediate representation of the source code corresponding to the flaw, and the patterns can include wildcards. The remediation agent may parameterize the target program code using wildcards or generic placeholders and/or interpolation applied before or as part of the matching rules. At stage C, the remediation agent 117 runs the pipeline 201 based on applying a fix template for the updated code change. After applying an applicable fix template(s), the remediation agent submits the updated code. For instance, the remediation agent 117 submits a pull request via a software development tool to the code repository 111 to merge the updated code into a branch or local version of the software project or software project component.")
McClory and Sharma are analogous art because they are from the same field of endeavor in container orchestration tools and applications. Sharma teaches a known method of fixing vulnerabilities detected during the deployment of the applications. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine McClory and Sharma to utilize Sharma’s known technique, of fixing application vulnerabilities, into the environment and processes of McClory which teaches systems and environment for configuring and deploying applications in a container environment in order to reduce bugs and error rates. Note MPEP 2143- (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Regarding Claim 2, McClory in view of Sharma teaches the method of claim 1, the method further comprising: storing the updated template in a deployment repository, (McClory, [0096])
the deployment repository comprising at least one configuration file, (McClory, [0096] also [0053] "In an embodiment, the application source code data store 250 may be generally configured to store the source code for an application (i.e., application source code information 260). In an embodiment, the application source code data store 250 may be further configured to store one or more workflows configured to continuously integrate, test, and/or deploy the application, which may be represented as pipeline configuration information 262.")
deploying the updated template to the container orchestration platform based on the configuration file (McClory, [0096] and [0107] "In an embodiment, the infrastructure management component 318-1 may be generally configured to execute or otherwise interpret infrastructure creation workflow information to create an application infrastructure for an application to be created within a designated infrastructure services provider system. As previously discussed, infrastructure creation information may define an infrastructure creation workflow. ")
Regarding Claim 3, McClory in view of Sharma teaches the method of claim 1, wherein generating the template includes a continuous integration (CI) pipeline. (McClory, [0026] "In an embodiment, the one or more container applications 136 and/or native applications 138 may also implement a microservice architecture, where the structures of an application may be implemented as a set of individual microservices that are separated and organized by their discrete functions. In an embodiment, the individual microservices may be implemented with a variety of programming languages (e.g., Java, JavaScript, C#, C++, Python, PHP, Ruby, Go, Perl, and Erlang, Node.js, Elixir, etc.) and may be communicatively and/or operatively coupled to each other via distributed messaging systems (e.g., APACHE Kafka, PIVOTAL RabbitMQ, etc.) and overlay networks (e.g., flannel, WEAVE Net, Project Calico, etc.) to collectively provide the functionalities of the application. The individual microservices may also be independently built, tested, and deployed to facilitate continuous integration (CI) and continuous delivery (CD) software development and information technology operations (DevOps) paradigm(s)." and [0072] "In an embodiment, the pipeline configuration information may also include, without limitation, integration workflow and testing workflow configured to facilitate continuous integration of the application to be created and the frequent, recurring, automated, and configurable testing of the created application. The pipeline configuration information may further include an infrastructure creation workflow configured to facilitate the creation of a new cluster (if needed) and a deployment workflow configured to facilitate deployment of the created and tested application to the newly created cluster or an existing cluster as designated by the application developer.")
Regarding Claim 4, McClory in view of Sharma teaches the method of claim 1, wherein deploying the updated template includes a continuous deployment (CD) pipeline (McClory, [0026])
Regarding Claim 5, McClory in view of Sharma teaches the method of claim 1, wherein the container orchestration platform includes a development environment, a testing environment, and a production environment (McClory, [0025] "In an embodiment, the cloud platform system 160 may be representative of a system generally arranged to provide application developers with accelerated development, deployment, orchestration, and management of their container applications 136 and/or native applications 138. For example, the cloud platform system 160 may provide application developers with the functionality to rapidly design, create, build, test, and/or deploy their container applications 136 and/or native applications 138 to the respective infrastructure services provider systems 116. The services of the deployed container applications 136 and/or native applications 138 may then be accessed or used by the application developer's customers, clients, or consumers via their systems (e.g., consumer system 106)." an [0103] "In an embodiment, the performance and testing component 314-6 may be configured to provide testing as a service by: (1) deploying the container application image or a package that includes the application to be tested to a development environment configured to simulate a production environment; (2) execute the generated test application to provide randomized input that simulates peak access patterns the application may experience via its APIs when the application is executing in a production environment; (3) monitor the responses of the container application to determine compliance with the API specifications information for the application; and (4) generate testing result information based on the determined compliance with the API specifications information for the application. In an embodiment, development environment may include, without limitation, one or more cluster nodes that are primarily used for testing the application and not used by the customers or clients of an application developer that created the application (e.g., users of one or more consumer devices 108). In an embodiment, the production environment may include, without limitation, one or more cluster nodes that are primarily used by the customers or clients of the application developer that created the application (e.g., users of one or more consumer devices 108).")
Regarding Claim 6, McClory in view of Sharma teaches the method of claim 1, wherein the code repository includes at least one configuration file with the code (McClory [0095] "In an embodiment and after creating the pipeline configuration information, the integration and deployment component 314-4 may be configured to: (1) store the created pipeline configuration information (e.g., pipeline configuration information 262) in an application source code data store (e.g., application source code data store 250 that also stores the application source code information 260); (2) perform the one or more workflows of the pipeline configuration information to build and test the application; and (3) provide a deployment ready notification or generate a deployment ready event indicating that the application has successfully completed and passed testing workflow and the artifact data store 252 includes the application stored in a container application image for execution on container engines (e.g., container engines 134) or a native application package for installation and execution directly on a Guest OS (e.g., Guest OS 132) rather than on a container engine." [0046] "FIG. 2 illustrates another block diagram of the AADDOMA 162 configured to create, build, test, and deploy one or more applications in an example embodiment 200. For example, to create an application with a customizable development, testing, and deployment pipeline, the development device 104-1 may include an application orchestration client application 214 and application source code information 260 may generally include source code for the application and application build configuration for the application." [0053, 0055, and 0060])
Regarding Claim 7, McClory in view of Sharma teaches the method of claim 6, wherein generating the updated template comprises: updating a base image based on updated code of the at least one configuration file; (McClory, [0091] "In an embodiment, the image component 314-3 may be generally configured to generate one or more container images that support the operation of a container application. The one or more container images may include, without limitation, one or more container OS images that are used to create a container instance hosted by a container engine (e.g., container engine 134) of a cluster node (e.g., cluster node 220-1 as a slave cluster node). The container OS images may generally include, without limitation, an image of an OS with customized configurations and a minimum amount OS services to support the execution of container applications and associated container components within a container instance." and [0096] detects changes and restarts the build process.)
building the updated template based on the updated base image (McClory [0042] "In an embodiment, each container instance may be created and hosted by the container engine 134 based on a container application image, which may include, without limitation, the container OS image, the container application(s), and associated container components. Thus, the container applications 136 may be hosted and managed by the one or more container engines 134 and defined by its associated container application images. In an embodiment, each container engine of the one or more container engines 134 may also be configured to host and manage the execution of one or more container applications created and deployed by the AADDOMA 162." and [0096])
Regarding claim 8, McClory teaches A system comprising: a memory storing instructions; a database, in electronic communication with the memory, configured to store information comprising: a processor, in electronic communication with the database, configured to execute the instructions to perform operations comprising: (McClory, [0280-0286] and [0181])
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Claims 9-14 are system claims reciting limitations similar to claims 2-7 respectively and are rejected under the same rationale.
Claims 15-20 recite limitations similar to claims 8, 2, 5-7 and 4 respectively and are rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hagighat et al. (US20210263779A1): discloses function system enhancements in the context of container orchestration architecture.
Dimitriov et al. (US20200034206A1): discloses advanced configuration options for cloud computing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached on 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.E.D./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights