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 Office Action is in response to the application filed on 08/27/2024. Claims 1-20 are pending in this application. Claims 1, 13 and 17 are independent claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Regarding claim 1, the limitation, “identifying a change to a repository of a version control system;” as drafted, is a function that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. This limitation encompasses a human mind carrying out these functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. For example, a user of a version control system can look at a log of committed changes to a repository and select or identify one of the commits. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the judicial exception is not integrated into a practical application. The additional element, “providing, …update data to a container orchestration platform in response to identification of the change to the repository of the version control system“, does nothing more than add insignificant extra solution activity to the judicial exception of mere data gathering and outputting, thus is not a practical application under Prong 2. The additional element, “and updating the repository based on completion data received from the container orchestration platform in response to performing at least a portion of the multi-stage update based on the update data”, merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. The additional element, ”the update data associated with a multi-stage update on a component of the container orchestration platform, and the update data including scheduling information associated with each stage of the multi-stage update”, can be classified as field of use and technical environment. Accordingly, the additional element does not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05 (g), MPEP 2106.05 (f) and MPEP 2106.05 (h) respectively.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional element, “and updating the repository based on completion data received from the container orchestration platform in response to performing at least a portion of the multi-stage update based on the update data”, merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. The additional element, ”the update data associated with a multi-stage update on a component of the container orchestration platform, and the update data including scheduling information associated with each stage of the multi-stage update”, can be classified as field of use and technical environment. The additional element “providing, …update data to a container orchestration platform in response to identification of the change to the repository of the version control system“, is merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Claim 1 recites additional element “a processing device. The additional element is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Accordingly, the elements of the claims do not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B.
Regarding claim 2, the limitation “identification of the change to the repository of the version control system”, recites additional mental process under Prong 1. The additional element, ”wherein a hook is utilized to provide the update data to the container orchestration platform in response”, can be classified as mere data gathering and outputting which does not integrate the judicial exception into a practical application under Prong 2, or amount to significantly more under Step 2B for the reasons provided in the rejection of claim 1.
Regarding claim 3, the limitation, “wherein the completion data is included in a commit notification received from the container orchestration platform”, can be classified as mere data gathering and outputting which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided in the rejection of claim 1.
Regarding claim 4, the limitation, “wherein the update data is provided via an application programming interface (API) of the container orchestration platform”, can be classified as mere data gathering and outputting which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Regarding claim 5, the limitation, “wherein the scheduling information includes or identifies a directed-acyclic graph (DAG)”, recites additional mental process under Prong 1. The claim does not recite additional elements that integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B
Regarding claim 6, the limitation, “further comprising performing the multi-stage update based on the DAG”, merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea; which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Regarding claim 7, the limitation, “wherein each stage of the multi-stage update corresponds to a node in the DAG”, can be classified as field of use and technical environment which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Regarding claim 8, the limitation, “wherein a hook is utilized to perform the multi-stage update based on the DAG”, merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea; which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Regarding claim 9, the limitation, “wherein the component of the container orchestration platform comprises a first component and a second component, the update data comprises first update data associated with the first component”, can be classified as field of use and technical environment. The limitation, “and the method further comprises providing second update data associated with the second component to the container orchestration platform based on the completion data”, can be classified as mere data gathering and outputting. Accordingly, the elements of the claim do not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Regarding claim 10, the limitation, “wherein a hook is utilized to provide the second update data”, can be classified as mere data gathering and outputting which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Regarding claim 11, the limitation, “performing the multi-stage update on the component of the container orchestration platform based on the scheduling information associated with each stage of the multi-stage update”, merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea; which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Regarding claim 12, the limitation, “generating at least a portion of a directed-acyclic graph (DAG) based on the change to the repository of the version control system”, can be classified as mere data gathering and outputting. The limitation, “wherein the scheduling information includes the DAG”, can be classified as field of use and technical environment. Accordingly, the elements of the claim do not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Claim sets 13-16 and 17-20 recite similar limitations to that of claims 1-9 and therefore are rejected under the same rationale.
Claim 17-20 recite additional elements “non-transitory computer-readable storage medium”, and “a/the processing device” in claims 17 and 20 . The additional elements are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Accordingly, the elements of the claims do not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-2, 4-9, 11-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Babu et al (US 20230368055 A1) hereafter Babu , in view of (Auto update Kubernetes Deployment on GitHub Webhook, Last Edit May 25, 2023) hereafter Velrajan.
Regarding claim 1, Babu teaches : providing, by a processing device, update data to a container orchestration platform,( [0028] “FIG. 3 is a more detailed block diagram of a system 300 in accordance with some embodiments. The system 300 include a Helm Client 320 that interacts with a Kubernetes cluster 330. The Helm Client 320 gives a developer a Command-Line Interface (“CLI”) to work with charts, configs, release, repositories, etc. In particular, the Helm Client 320 exchanges information with a Helm Tiller 340 in the Kubernetes cluster 330 (e.g., to perform various actions such as install, upgrade, rollback, etc.). The Helm Tiller 340 manages resources in connection with an API server 350 of the Kubernetes cluster 330. That is, the Helm Tiller 340 may comprise an in-cluster server in the Kubernetes cluster 330, interacting with the Helm Client 320 and communicating with the Kubernetes API server 350. Thus, Helm can easily manage Kubernetes with tasks such as install, upgrade, query, and remove for Kubernetes resources.”) The Kubernetes cluster corresponds to a container orchestration platform. Helm comprises a client-side component for managing charts that sends information to the Helm Tiller of the Kubernetes cluster to perform various actions such as install, upgrade, rollback which corresponds to, providing, by a processing device, update data to a container orchestration platform.
the update data associated with a multi-stage update on a component of the container orchestration platform, and the update data including scheduling information associated with each stage of the multi-stage update; ([0046-0047]”A complex Kubernetes application will often have dependency between various sub-charts that needs to be followed during the time of deployment (e.g., which has similar Kubernetes resources and that which can't be solved by the basic resource type ordering of Helm… Another way to solve this using Helm is to extend its plugin feature to develop a Helm plugin that handles the ordering of deployment and performs the rollout. The Helm plugin can be applied at the parent chart, which would contain a dependency manifest which determines dependency between the charts… Referring again to FIG. 3 , according to some embodiment, a Helm chart 312 can depend on another Helm chart 312 for deployments that require deployment of multiple stand-alone components.” [0048] The dependencies explicitly documented in the parent chart manifest 314 will let a plugin parse them and construct a DAG before the Helm release execution. The DAG can then dictate the ordering of sub-chart deployments. The dependency manifest 314 is first parsed by the Helm plugin and validated to form a DAG. The topological ordering of the DAG can be used produce the order of execution. For example, FIG. 5 is a dependency manifest 500 in accordance with some embodiments. The dependency manifest 500 (named “parent-chart”) represents a diamond dependency, where chart A is deployed first and then chart B and C are deployed in parallel. After both B and C of these are deployed successfully, chart D can be deployed. This dependency manifest 500 may be validated, parsed, and a DAG is formed. For example, FIG. 6 illustrates 600 task dependencies as defined by the dependency manifest 500 of FIG. 5 according to some embodiments. The topological ordering of the DAG can produce the order of execution. [0049] FIG. 7 is a workflow 700 in accordance with some embodiments. At S710, a Helm install/update is performed. If the chart does not contain a dependency manifest at S720, the default Helm behavior is performed at S730. If the chart does contain a dependency manifest at S720, it is determined if the dependency manifest is correct at S740. If the dependency manifest is not correct at S740, any errors may be parsed at S750. If the dependency manifest is correct at S740, a topological sort of a resulting DAG (as defined by the manifest) is performed at S760. The Helm chart may then be executed based on that ordering at S770”) Helm charts are used to deploy components of the Kubernetes cluster. The DAG produces the order of execution for deploying the charts referenced by the dependency manifest, wherein the dependency manifest stored in the repository corresponds to update data because it is information that can be exchanged between the Helm Tiller and Helm Client to perform the deployment and the DAG corresponding to scheduling information.
and updating the repository based on completion data received from the container orchestration platform in response to performing at least a portion of the multi-stage update based on the update data.
([0058-0060]”In some embodiments (such as the one shown in FIG. 12 ), the storage device 1230 further stores a deployment database 1300. An example of a database that may be used in connection with the platform 1200 will now be described in detail with respect to FIG. 13 … various databases might be split or combined in accordance with any of the embodiments described herein. Referring to FIG. 13 , a table is shown that represents the deployment database 1300 that may be stored at the platform 1200 according to some embodiments. The table may include, for example, entries identifying tenant requests for database allocations in a cloud computing environment. The table may also define fields 1302, 1304, 1306, 1308, 1310 for each of the entries. The fields 1302, 1304, 1306, 1308, 1310 may, according to some embodiments, specify a deployment identifier 1302, chart identifiers 1304, a dependency manifest identifier 1306, a date and time 1308, and a status 1310. The deployment database 1300 may be created and updated, for example, when applications are deployed in a cloud computing environment, statuses are updated, etc.… The status 1310 might indicate that a deployment was successful, is in process, has been rolled back, etc.”)
Figure 13 is a deployment database stored in the storage device 120 of figure 12 with the chart management engine responsible for managing repositories. The deployment database may be combined with other databases of the system, thus the deployment database can be implemented as a part of the repository which stores information corresponding to the deployments. The deployment database updates the status of deployments at each stage of the update for the deployments of the Kubernetes cluster such as DEPLOYED , IN PROCESS and ROLLBACK (fig 13). Thus, updating the status in the deployment database based on the statuses received at each stage of deployment in the Kubernetes cluster, corresponds to, and updating the repository based on completion data received from the container orchestration platform in response to performing at least a portion of the multi-stage update based on the update data.
Babu does not explicitly teach: A method comprising: identifying a change to a repository of a version control system; [] in response to identification of the change to the repository of the version control system
However, Velrajan teaches: A method comprising: identifying a change to a repository of a version control system; [] in response to identification of the change to the repository of the version control system([Continuous Deployment Strategy] “In this demo, I'll show you how to create a separate git repo for the Helm chart of our app. Whenever a new release is tagged on the master branch for this Helm chart git repo we'll upgrade the Helm chart release in our Kubernetes Cluster, which in turn will upgrade our http-server app in our Kubernetes cluster.”[Helm]”I have already created an Helm chart for this demo…Now edit the values.yaml file and update the repository …Commit the changes to your chart into a git repository, so that the changes/versions can be tracked.”)
The creation/update of the Helm chart .yaml files which are committed to the Git Repository corresponds to, identifying a change to a repository of a version control system. The Helm chart release is updated on the cluster following the change to the repository which corresponds to providing the update data in response to identification of the change to the repository of the version control system.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Babu with, a method comprising: identifying a change to a repository of a version control system; and providing the update data, [] in response to identification of the change to the repository of the version control system, in order to automatically trigger the Helm deployment as taught by Babu in response to the user saving /updating the repository. While Babu does not explicitly illustrate that the deployment is automatically triggered by the change to a repository, Babu provides a package deployment interface that allows users to manage and save charts to a repository( Babu, par 53 & FIG 11). Combining the teachings of Velrajan serves to automate the deployment of the chart in response to the user saving or updating the configuration which reduces the manual effort required by the developer to make changes live to container deployments.
Regarding claim 2, Babu in view of Velrajan teach the method of claim 1. Babu does not teach: wherein a hook is utilized to provide the update data to the container orchestration platform in response to identification of the change to the repository of the version control system.
However, Velrajan teaches: wherein a hook is utilized to provide the update data to the container orchestration platform in response to identification of the change to the repository of the version control system.([Release version 0.2.0 of the chart] “As soon as we do git push for the chart into its online repo, GitHub will trigger a webhook notification for the git push event. SocketXP will receive the webhook, validate the signature and try to match it with the filter rules. Since this is not a release webhook, SocketXP will throw a mismatch error and not further process this webhook.”)See update-kube.sh hook script in header figure. The push to GitHub triggers a webhook notification to Socket to perform validation and update the deployment based on user set requirements. The webhook provides a way for the notification to be delivered in response to events and the triggering of subsequent events such as a git pull command to retrieve the changed data and the Helm upgrade instruction of the update-kube.sh by the cluster to retrieve the data, which corresponds to, wherein a hook is utilized to provide the update data to the container orchestration platform in response to identification of the change to the repository of the version control system.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Babu with, wherein a hook is utilized to provide the update data to the container orchestration platform in response to identification of the change to the repository of the version control system, in order to utilize the webhooks functionality of GitHub to automatically notify the Kubernetes server of changes intended for deployment and retrieve the changes, thereby contributing to the creation of a secure full-automated Continuous Deployment(CD) which reduces the manual effort required by the user to deploy and update the Kubernetes cluster.[Velrajan, Conclusion]
Regarding claim 4, Babu in view of Velrajan teach the method of claim 1. Babu further teaches: wherein the update data is provided via an application programming interface (API) of the container orchestration platform.([0028-0029]The Helm Client 320 gives a developer a Command-Line Interface (“CLI”) to work with charts, configs, release, repositories, etc. In particular, the Helm Client 320 exchanges information with a Helm Tiller 340 in the Kubernetes cluster 330 (e.g., to perform various actions such as install, upgrade, rollback, etc.). The Helm Tiller 340 manages resources in connection with an API server 350 of the Kubernetes cluster 330. That is, the Helm Tiller 340 may comprise an in-cluster server in the Kubernetes cluster 330, interacting with the Helm Client 320 and communicating with the Kubernetes API server 350. Thus, Helm can easily manage Kubernetes with tasks such as install, upgrade, query, and remove for Kubernetes resources…Kubernetes provides the Application Programming Interface (“API”) server 350 which the end users or clients can then use to deploy and configure their applications with Kubernetes. …. Kubernetes resource objects can be created, updated, and/or deleted by writing multiple object configuration files (usually YAML files) and using the kubectl command-line tool.)The information exchanged between the Helm Client and the Helm Tiller corresponds to update data because it is used to perform various actions such as install, upgrade, rollback as previously stated. The Helm Tiller of the Kubernetes Cluster communicates with the Helm Client through the use of an API to update and deploy configurations, which corresponds to, wherein the update data is provided via an application programming interface (API) of the container orchestration platform.
Regarding claim 5 , Babu in view of Velrajan teach the method of claim 1. Babu further teaches: wherein the scheduling information includes or identifies a directed-acyclic graph (DAG). ([0048-0049] “The dependencies explicitly documented in the parent chart manifest 314 will let a plugin parse them and construct a DAG before the Helm release execution. The DAG can then dictate the ordering of sub-chart deployments. The dependency manifest 314 is first parsed by the Helm plugin and validated to form a DAG… FIG. 7 is a workflow 700 in accordance with some embodiments. At S710, a Helm install/update is performed…If the dependency manifest is correct at S740, a topological sort of a resulting DAG (as defined by the manifest) is performed at S760. The Helm chart may then be executed based on that ordering at S770.”) The dependency manifest received from the Helm Client is used to define the DAG for performing the deployment, which corresponds to, wherein the scheduling information includes or identifies a directed-acyclic graph (DAG).
Regarding claim 6, Babu in view of Velrajan teach the method of claim 1. Babu further teaches: further comprising performing the multi-stage update based on the DAG. ([0049] “If the dependency manifest is correct at S740, a topological sort of a resulting DAG (as defined by the manifest) is performed at S760. The Helm chart may then be executed based on that ordering at S770.”[0051] “any desired rollback would be done in the reverse order of the topological ordering from the chart that failed, making sure the entire Helm release procedure is atomic.”) Executing the Helm chart based on the ordering of the DAG to perform tasks of a deployment, corresponds to, further comprising performing the multi-stage update based on the DAG.
Regarding claim 7, Babu in view of Velrajan teach the method of claim 6. Babu further teaches: wherein each stage of the multi-stage update corresponds to a node in the DAG.([0049] “If the dependency manifest is correct at S740, a topological sort of a resulting DAG (as defined by the manifest) is performed at S760. The Helm chart may then be executed based on that ordering at S770.”[0051] “any desired rollback would be done in the reverse order of the topological ordering from the chart that failed, making sure the entire Helm release procedure is atomic.”)See figure 6, where the DAG is illustrated as directing the order of tasks to perform the deployment. The Helm Tiller of the Kubernetes cluster is responsible for deploying the update based on the DAG generated. The Helm chart is executed based on the ordering of the DAG as each node of the DAG is a task corresponding to the deployment parsed from the dependency manifest, which corresponds to, wherein each stage of the multi-stage update corresponds to a node in the DAG.
Regarding claim 8, Babu in view of Velrajan teach the method of claim 7. Babu teaches: perform the multi-stage update based on the DAG. ([0048-0049] “The dependencies explicitly documented in the parent chart manifest 314 will let a plugin parse them and construct a DAG before the Helm release execution. The DAG can then dictate the ordering of sub-chart deployments. The dependency manifest 314 is first parsed by the Helm plugin and validated to form a DAG… FIG. 7 is a workflow 700 in accordance with some embodiments. At S710, a Helm install/update is performed…If the dependency manifest is correct at S740, a topological sort of a resulting DAG (as defined by the manifest) is performed at S760. The Helm chart may then be executed based on that ordering at S770.”) Figure 7 illustrates the Helm install/upgrade process carried out by the Helm Tiller of the Kubernetes cluster. The dependency manifest is used to define the DAG for performing the deployment, which corresponds to, perform the multi-stage update based on the DAG.
Babu does not explicitly teach: wherein a hook is utilized , However, Velrajan teaches: wherein a hook is utilized , ([Begin Demo - Upgrade the app and the chart] “As soon as we do git push for the chart into its online repo, GitHub will trigger a webhook notification for the git push event. SocketXP will receive the webhook, validate the signature and try to match it with the filter rules. “) Velrajan uses hooks to trigger the Helm chart upgrade which corresponds to wherein a hook is utilized.
Furthermore, it is well known in the art of software development that webhooks may be used for triggering user defined actions. Velrajan adds the “git pull” and “Helm upgrade” actions to the update-kube.sh hook script [Run SocketXP on the master node] however any supported deployment actions can be added when editing the hook such that the functionality of Babu in defining the DAG can be performed between the git pull and Helm upgrade commands of the hook script. Babu teaches that the deployment database is used to store the state of deployments, and further teaches that the support of SAGA patterns is used with messages/events to trigger subsequent update tasks.[Babu 52, and Fig 10].Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Babu with, wherein a hook is utilized, in order to define hooks that send the messages consumed by the saga pattern for triggering subsequent tasks in the deployments. When the deployment database is implemented as a repository as stated in the rejection of claim 1, the combination of webhooks through GitHub as illustrated by Velrajan is a well-known technique in the art of software development for implementing automated deployment pipelines; allowing developers to define custom deployment behavior in advance thereby streamlining development.
Regarding claim 9, Babu in view of Velrajan teach the method of claim 1. Babu further teaches: wherein the component of the container orchestration platform comprises a first component and a second component
(“[0047]Referring again to FIG. 3 , according to some embodiment, a Helm chart 312 can depend on another Helm chart 312 for deployments that require deployment of multiple stand-alone components. “) Also see figure 4, Chart A defines A-Service and chart B defines B-Service. The Helm repository stores Helm charts to be deployed to the Kubernetes cluster for multiple standalone components, which corresponds to , wherein the component of the container orchestration platform comprises a first component and a second component.
the update data comprises first update data associated with the first component,
([0002] “A package manager platform, coupled to the package manager chart file repository, may access a first parent chart from the package manager chart file repository and determine that the first parent chart includes a dependency manifest. The package manager platform may then construct a Directed Acyclic Graph (“DAG”) based on the dependency manifest. Container orchestration system objects, including those associated with sub-charts of the first parent chart, may then be deployed in accordance with a topological ordering of the DAG.”)
The constructed DAG that Helm uses to order deployments is based on the charts for all components of the associated dependency manifest which is update data as stated in the rejection of claim 1, which corresponds to, the update data comprises first update data associated with the first component.
and the method further comprises providing second update data associated with the second component to the container orchestration platform based on the completion data.([0048] “ The topological ordering of the DAG can be used produce the order of execution. For example, FIG. 5 is a dependency manifest 500 in accordance with some embodiments. The dependency manifest 500 (named “parent-chart”) represents a diamond dependency, where chart A is deployed first and then chart B and C are deployed in parallel. After both B and C of these are deployed successfully, chart D can be deployed. “ [0052]“ when a failure is encountered while deploying a chart the tool may choose to tolerate the failure (or execute compensable measures to recover from the failure). Moreover, embodiments may support the inherent properties of operational atomicity and consistency of a distributed system. In addition, embodiments may be capable of executing compensating tasks in case of failure. For example, FIG. 10 is a saga system 1000 according to some embodiments including a saga pattern 1010. The saga pattern 1010 includes a number of services 1020 (e.g., local transactions) linked by messages/events. In this way, the saga pattern 1010 may provide transaction management using a sequence of local transactions. A local transaction is the atomic work effort performed by a saga participant. Each local transaction may, for example, update the database and publish a message or event to trigger the next local transaction in the saga pattern 1010. “)Deployments of dependent charts are done sequentially based on the ordering of the DAG, furthermore Babu implements a SAGA pattern that carries out each stage of the deployment and then sends messages/events to trigger the next task in the deployment. When for example task A is deployed first, chart B and chart C are for second components. The update to the database at each stage of deployment such as the deployment database in fig 13 status column corresponds to completion data, the messages of the saga pattern that trigger the next local transaction can be considered second update data , and thus corresponds to, and the method further comprises providing second update data associated with the second component to the container orchestration platform based on the completion data.
Regarding claim 11, Babu in view of Velrajan teach the method of claim 1. Babu further teaches: further comprising performing the multi-stage update on the component of the container orchestration platform based on the scheduling information associated with each stage of the multi-stage update.([0048] “The dependencies explicitly documented in the parent chart manifest 314 will let a plugin parse them and construct a DAG before the Helm release execution. The DAG can then dictate the ordering of sub-chart deployments. The dependency manifest 314 is first parsed by the Helm plugin and validated to form a DAG. The topological ordering of the DAG can be used produce the order of execution. For example, FIG. 5 is a dependency manifest 500 in accordance with some embodiments. The dependency manifest 500 (named “parent-chart”) represents a diamond dependency, where chart A is deployed first and then chart B and C are deployed in parallel. After both B and C of these are deployed successfully, chart D can be deployed. This dependency manifest 500 may be validated, parsed, and a DAG is formed. For example, FIG. 6 illustrates 600 task dependencies as defined by the dependency manifest 500 of FIG. 5 according to some embodiments. The topological ordering of the DAG can produce the order of execution.”) Executing the deployment using the DAG which dictates the ordering of execution, corresponds to, further comprising performing the multi-stage update on the component of the container orchestration platform based on the scheduling information associated with each stage of the multi-stage update.
Regarding claim 12, Babu in view of Velrajan teach the method of claim 1. Babu further teaches: further comprising generating at least a portion of a directed-acyclic graph (DAG) based on [] the repository of the version control system, wherein the scheduling information includes the DAG.([0048-0049] “The dependencies explicitly documented in the parent chart manifest 314 will let a plugin parse them and construct a DAG before the Helm release execution. The DAG can then dictate the ordering of sub-chart deployments. The dependency manifest 314 is first parsed by the Helm plugin and validated to form a DAG”[0053]”FIG. 11 is a package deployment display 1100 … The display 1100 includes a graphical representation 1110 or dashboard that might be used to manage sub-chart dependencies (e.g., for a cloud computing environment… The display 1100 may also include a user selectable “Save” icon 1120 to store configurations and/or system mappings (e.g., to a particular repository) and an “Update” icon 1122 to adjust values as appropriate.” [0062] “ FIG. 14 illustrates a tablet computer 1400 providing a package deployment display 1410 … used, for example, to enter a dependency manifest for a cloud computing environment. Moreover, the display 1410 might be used to update and/or create Helm charts, sub-charts, deployment details, etc. via an “Update” icon 1420.”)The dependency manifests stored in the repository is used to define the DAG for dictating the ordering of sub chart deployments, which corresponds to wherein the scheduling information includes or identifies a directed-acyclic graph (DAG).
Babu does not explicitly teach that the generation of the DAG as a part of the deployment is based on the change to the repository. However, Velrajan teaches automatically triggering deployments based on the change to the repository
([Continuous Deployment Strategy] “Whenever a new release is tagged on the master branch for this Helm chart git repo we'll upgrade the Helm chart release in our Kubernetes Cluster, which in turn will upgrade our http-server app in our Kubernetes cluster.)
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Babu with, based on the change to the repository, in order to automatically trigger the deployment steps when there is a change to a repository by the user saving /updating the repository using the interface provided by Babu [Babu, Par 53 & FIG 11 , FIG 14]. Automating the deployment tasks in response to the user saving or updating the configurations reduces the manual effort required by the developer to make changes to deployments.
Regarding claim 13, it is a system claim having similar limitations cited in the
rejection of claim 1. Thus, claim 13 is also rejected under the same rationale as
cited in the rejection of claim 1 above.
Regarding claim 14, it is a system claim having similar limitations cited in the
rejection of claim 2. Thus, claim 14 is also rejected under the same rationale as
cited in the rejection of claim 2 above.
Regarding claim 15, it is a system claim having similar limitations cited in the
rejection of claim 5. Thus, claim 15 is also rejected under the same rationale as
cited in the rejection of claim 5 above.
Regarding claim 17, it is a system claim having similar limitations cited in the
rejection of claim 1. Thus, claim 17 is also rejected under the same rationale as
cited in the rejection of claim 1 above.
Regarding claim 18, it is a non-transitory computer-readable storage medium claim having similar limitations cited in the rejection of claim 2. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 2 above.
Regarding claim 19, it is a non-transitory computer-readable storage medium claim having similar limitations cited in the rejection of claim 5. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 5 above.
Regarding claim 20, it is a non-transitory computer-readable storage medium claim having similar limitations cited in the rejection of claim 9. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claim 9 above.
Claims 3 ,10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over (US 20230368055 A1) Babu , in view of (Auto update Kubernetes Deployment on GitHub Webhook, Last Edit May 25, 2023) Velrajan, and further in view of (GitOps: A New Way of DevOps Delivery, Author: Nilesh Naik , Published: September 2, 2021) hereafter Naik.
Regarding claim 3, Babu in view of Velrajan teach the method of claim 1. Babu and Velrajan do not explicitly teach : wherein the completion data is included in a commit notification received from the container orchestration platform.
However, Naik teaches: wherein the completion data is included in a commit notification received from the container orchestration platform.
PNG
media_image1.png
368
710
media_image1.png
Greyscale
([How Do We Do it, #5] ”Upon completion, the GitOps operator notifies the deployment state by setting commit status in the Git repository. The CI system uses this status to determine if the change is successfully deployed and run any post-deployment actions.”)See step A of above figure. The deployment state corresponds to completion data , setting the commit status in the Git repository with the deployment state from the Kubernetes Cluster corresponds to, wherein the completion data is included in a commit notification received from the container orchestration platform.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Babu with, wherein the completion data is included in a commit notification received from the container orchestration platform, because the method of Babu already implements a deployment database that keeps track of deployment statuses which mirrors the function of the Environment Repository taught by Naik above [Babu, Par 52, 59-60]. Explicitly implementing the deployment database as an Environment Repository and committing these statuses allows developers to keep a complete history of changes for automatic recovery in the event of a failure. [Naik, Why Should You Adopt GitOps?]
Regarding claim 10, Babu in view of Velrajan teach the method of claim 9. Babu further teaches: [] to provide the second update data.
[Babu 52, and Fig 10] Babu teaches that the deployment database is used to store the state of deployments, and further teaches that the support of SAGA patterns is used with messages/events to trigger subsequent update tasks. When the dependency manifest comprises multiple standalone components that need to be updated/deployed as stated previously, the saga pattern is used to update the deployment database and sends messages/events that trigger the next task in the deployment for each component if successful . The message sent to trigger the next task in deployment thus corresponds to, to provide the second update data.
Babu does not explicitly teach: wherein a hook is utilized
However, Velrajan teaches: wherein a hook is utilized , ([Begin Demo - Upgrade the app and the chart] “As soon as we do git push for the chart into its online repo, GitHub will trigger a webhook notification for the git push event. SocketXP will receive the webhook, validate the signature and try to match it with the filter rules. “) Velrajan uses hooks to trigger the initial Helm chart upgrade in response to an update to a repository. As stated above, the deployment database taught by Babu corresponds to repository in which statuses indicating the state of deployments are stored , updated , and used to trigger dependent deployments. As illustrated by Naik above, when the deployment database is represented as a repository, saving the status of the deployment is implemented by a commit notification to the deployment/environment repository. Thus, hooks can be implemented to provide notifications that trigger the second chart in response to a commit notification that indicates a first chart has been successfully deployed.
Furthermore, it is well known in the art of software development that webhooks may be used for triggering user defined actions. Velrajan adds the “git pull” and “Helm upgrade” actions to the update-kube.sh hook script [Run SocketXP on the master node], however any supported deployment instructions can be added when editing the hook script. Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Babu with, wherein a hook is utilized, in order to define hooks that send the messages consumed by the saga pattern for triggering subsequent tasks in the deployments. When the deployment database is implemented as a repository as stated in the rejection of claim 1 , the combination of webhooks through GitHub as illustrated by Velrajan is a well-known technique in the art of software development for implementing automated deployment pipelines; Allowing developers to define custom deployment behavior in advance thereby streamlining development.
Regarding claim 16, it is a system claim having similar limitations cited in the
rejection of claim 3. Thus, claim 16 is also rejected under the same rationale as
cited in the rejection of claim 3 above.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
US 20250335184 A1: Discloses a repository in conjunction with a host application platform and a continuous integration/continuous deployment (CI/CD) system. Relevant to claims 1, 13, 17 and 20.
US 20240211248 A1 : Discloses a version management-and-container management system. Relevant to claims 1, 13, 17 and 20. Relevant Figures ( 2, 6).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE O'CONNOR EMANUEL whose telephone number is (571)272-8975. The examiner can normally be reached M-F 9:00 - 5:00 pm .
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, Chat Do can be reached at (571) 272-3721. 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.
/L.S.O./ Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights