DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is made non-final.
Claims 1-20 filed on 01/31/2024 have been reviewed and considered by this office action.
Information Disclosure Statement
The information disclosure statement filed on 01/31/2024 and 01/09/2026 have been reviewed and considered by this office action.
Drawings
The drawings filed on 01/31/2024 have been reviewed and are considered acceptable.
Specification
The specification filed on 01/31/2024 has been reviewed and is considered acceptable.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6-9 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vergara et al. (US 11356508 B1, Hereinafter Vergara).
As per claim 1, Vergara teaches A method, comprising:
accessing, by a computer system, a declarative specification for a datacenter on a cloud platform, (see [Column 9, Paragraph 3], The parsing module 310 parses various types of user input including declarative specification of a data center)
wherein the datacenter includes a hierarchy of datacenter entities, (see [Column 3, Paragraph 3], The system accesses a data center configured on a target cloud platform. The data center is generated based on a cloud platform independent declarative specification comprising a hierarchy of data center entities. Each data center entity comprises one or more of (1) a service or (2) one or more other data center entities.
and wherein the declarative specification describes dependencies between datacenter entities required for execution of particular datacenter entities
(see [Column 3, Paragraph 3], The system accesses a data center configured on a target cloud platform. The data center is generated based on a cloud platform independent declarative specification comprising a hierarchy of data center entities. Each data center entity comprises one or more of (1) a service or (2) one or more other data center entities.
See [Column 18, Paragraph 1], The cloud platform independent declarative specification specifies dependencies between services, for example, start dependencies for each service listing all services that should be running when a particular service is started. The data center generation module 220 generates the cloud platform specific detailed metadata representation of the data center that includes information describing these dependencies such that the instructions for deploying the service ensure that the cloud platform starts the services in an order specified by the dependencies such that for each service, the services required to be started before the service are running when the service is started. Accordingly, the dependencies between services represent a dependency graph and the cloud platform starts running the services in an order determined based on the dependency graph such that if service A depends on service B, the service B is started before service A is started.
Vergara teaches parsing (assessing) a declarative specification for a data center on a cloud form based on that declarative specification, which details a hierarchy of data center entities. The dependencies being required for execution of a data center entity is taught in Vergara’s description of service dependencies being required before starting the dependent service.);
generating an aggregate pipeline for the datacenter based on the declarative specification, wherein the aggregate pipeline includes a hierarchy of pipelines for datacenter entities of the datacenter, at least some of the pipelines being datacenter entity pipelines for individual datacenter entities, and wherein a datacenter entity pipeline include stages for deployment of the individual datacenter entity associated with the datacenter entity pipeline
(see [Column 22, Paragraph 1], the master pipeline comprises a hierarchy of pipelines. The hierarchy comprises multiple levels and pipelines at a particular level include pipelines of the next lower level as children pipelines.
see [Column 22, Paragraph 2], A data center instance pipeline 1010 may include service group pipelines 1020. Each service group pipeline 1020 may include one or more service pipelines 1030. A data center instance pipeline 1010 may include cell pipelines 1025, each cell pipeline 1025 comprising one or more service pipelines 1030. The service pipeline 1030 may comprise stages, each stage representing a pipeline representing instructions for deploying the service for specific environments. The lowest level pipeline or the leaf level pipeline in the hierarchy is referred to as a unit pipeline and may include detailed service specific instructions for performing an operation related to a service. For example, deployment for a service may include pre-deployment steps, deployment steps, post deployment steps, and post deployment test and validation step. A pipeline that is not a leaf level pipeline and has one or more child pipeline is an aggregate pipeline that orchestrates executions of the child pipelines.
see [Column 21, Paragraph 2], the pipeline generator module 320 generates pipelines in a hierarchical fashion based on the hierarchy of the data center entities of the data center. For example, the data center comprises data center entities of different types including data centers, service groups, services, and so on. A data center entity may include one or more child data center entities. For example, a data center includes one or more service groups as child data center entities. A service group includes one or more services as child data center entities. Accordingly, the data center generation module 210 starts at a data center entity at a level of the hierarchy and generates pipelines of data center entities below that level. For example, the pipeline generator module 320 starts at the data center level and generates pipelines for service groups within the data center. For each service group, the pipeline generator module 320 generates pipelines for services within the service group.
see [Column 20, Paragraph 6], Each pipeline comprises a sequence of stages, each stage representing one or more actions that need to be performed by the target cloud platform towards provisioning and deploying of the data center.
Vergara teaches an aggregate pipeline (the master pipeline) with a hierarchy of pipelines, an entity pipeline with stages for deployment (the quoted service pipeline and its stages), and clarifies that each pipeline comprises stages for deployment (stages needed for the deploying of a data center).
placing retry stages at ends of the datacenter entity pipelines, wherein a retry stage in a datacenter entity pipeline is configured to invoke a retry strategy for the datacenter entity pipeline in response to a failure in execution of a particular stage in the datacenter entity pipeline, and wherein the retry strategy for the datacenter entity pipeline is invoked starting at the particular stage that failed
(See [Column 31, Paragraph 3], the pipeline generator introduces an invoke retrier stage within an aggregate pipeline to trigger a retry strategy if a previous pipeline stage fails.
see [Column 36, Claim 1], encountering a failure during execution of a stage of the aggregate pipeline; and repeatedly executing the stage of the aggregate pipeline in accordance with the retry strategy before executing a next stage of the aggregate pipeline.
see [Column 33, Paragraph 1], If the execution of the stage S1 of the pipeline corresponding to datacenter entity D1 is retried, the idempotency of execution of the pipeline ensures that the stages that were successfully executed during the previous execution are not executed again during the retry.
Vergara teaches a retry stage in response to encountering a failure. Further, it teaches that the “retrier” ensures that previous successfully executed stages are not executed again, but also that is executes a retry strategy before the next stage of the pipeline begins. Because this retry takes place after the stage that fails, but before the next, it is positioned “at the ends”. The idempotency mentioned in Vergara teaches that no previous successful stages of the pipeline are re-executed, meaning that the retry begins at the stage that failed as claimed.);
and executing the aggregate pipeline for the datacenter on the cloud platform according to the declarative specification.
(See [Column 21, Paragraph 3], The software release deployment module 230 receives a request to deploy a software artifact on a set of data center entities in the target cloud platform. The software release deployment module 230 executes the master pipeline for one or more data centers. The software release deployment module 230 executes the aggregate pipelines for each service group of each data center. The aggregate pipeline comprises pipelines for services within the service group. For each service within each service group, the pipeline is executed by executing all the stages of the pipeline. The execution of the provisioning pipelines results in provisioning of the resource for a service and the deployment pipeline causes deployment of the service in the target cloud platform.
see [Column 19, Paragraph 4], The software release management module 230 compiles 740 the cloud platform independent master pipeline to generate a cloud platform specific detailed deployment pipeline that is specific to the hierarchy of data center entities of each data center as specified by the cloud platform independent declarative specification
Vergara teaches that the aggregate pipeline (the master pipeline) is executed based on the declarative specification, and is deployed on the cloud platform.)
As per claim 2, Vergara teaches the method of claim 1,
wherein the retry strategy for a particular datacenter entity pipeline is defined by an owner of the individual datacenter entity associated with the particular datacenter entity pipeline
(see [Column 28, Paragraph 2], Allow service owners to provide the retry behavior configuration in their deployment manifest.
see [Column 32, Paragraph 5], the same data center entity may apply strategy S1 in the development environment but strategy S2 in the test environment and strategy S3 in the production environment. The name of the strategy is selected from one of the retry strategies defined, for example, a “fixed_timeout” strategy. The specification further specifies an attribute datacenter_entities identifying the names of the data center entities to which the retry strategy is applied
Vergara teaches that the service owner (the entity owner) provides retry strategy, which is the retry behavior configuration, or the selected retry strategy mentioned in the above quotes).
As per claim 3, Vergara teaches the method of claim 1,
wherein the retry stages are operable to be enabled or disabled by an operator of the computer system
(see [Column 26, Paragraph 5], the generated cloud platform specific detailed pipeline includes artifact version map filters before certain stages to determine whether certain stages should be enabled or disabled according to the artifact version map.
see [Column 8, Paragraph 2], The software release management module 230 receives as inputs (1) an artifact version map
see [Column 8, Paragraph 4], a user may modify the input artifact version map.
Vergara that stages can be enabled or disabled based upon the artifact version map filter which is operator/user supplied input. This means that for all stages, including retries, the operator determines whether they are enabled to execute.)
As per claim 4, Vergara teaches the method of claim 1,
wherein the stages in the datacenter entity pipeline include instructions for deployment of the individual datacenter entity on the cloud platform
(see [Column 20, Paragraph 6], each stage representing one or more actions that need to be performed by the target cloud platform towards provisioning and deploying of the data center.
see [Column 21, Paragraph 5], The environment pipeline for an environment E includes instructions to deploy 910 the software on a set of data center entities
Vergara teaches that each stage includes instructions and are necessary for the deployment of a data center).
As per claim 6, Vergara teaches the method of claim 5, further comprising
placing at least one conditional expression in the provision stage and in the deploy stage, wherein the conditional expression includes instructions not to rerun the stage during a retry when the stage has already been successfully run or any stage positioned before the stage in the datacenter entity pipeline has failed
(See [Column 31, Paragraph 1], If the pipeline controller stage determines that a particular stage was successfully executed previously with matching inputs, the pipeline controller stage skips execution of that stage.
see [Column 29, Paragraph 6], The pipeline may be configured such that the execution of subsequent stages stops when one stage fails.
see [Column 30, Paragraph 8], stage includes instructions to check the status of the stages of the pipeline that are selected for execution
Vergara teaches that successfully executed stages are not rerun, and that the pipeline will not a stage when a stage before it has failed (subsequent stages stop executing). This is enabled by checking the status of the stage to see whether it has been successful or if an earlier stage as failed(conditional).)
As per claim 7, Vergara teaches the method of claim 1,
wherein the retry stage in the datacenter entity pipeline is configured to invoke the retry strategy for the datacenter entity pipeline agnostically of retry strategies in other datacenter entity pipelines
(see [Column 5, Paragraph 3], different data center entities within the hierarchy may be associated with different retry strategies. For example, a data center entity D1 may be associated with retry strategy S1 and a data center entity D1 below the data center entity D1 may be associated with another retry strategy S2.
Vergara teaches that entities can have different retry strategies that operate independently of each other).
As per claim 8, Vergara teaches the method of claim 1,
wherein the aggregate pipeline includes at least a first datacenter entity pipeline with a first retry stage and a second datacenter entity pipeline with a second retry stage, the first retry stage being invoked in response to a failure in execution of the first datacenter entity pipeline and the second retry stage being invoked in response to a failure in execution of the second datacenter entity pipeline, and wherein the first retry stage and the second retry stage are capable of being invoked in parallel
(See [Column 37, Claim 4], wherein the data center entity is a first data center entity and wherein the one or more data center entities include a second data center entity, wherein the first data center entity is associated with a first retry strategy and the second retry strategy is associated with a second retry strategy.
see [Column 37, Claim 5], responsive to a failure of a stage of the second data center entity the first retry strategy is executed for the first data center entity and the second retry strategy is executed for the second data center entity.
see [Column 29, Paragraph 1], The representation of a pipeline is canonical, such that ordering of stages that can be executed in parallel does not affect the state.
Vergara teaches that a first and second data center entity can have a first and second retry strategy respectively, where that strategy is executed in a stage and can be executed in parallel.)
As per claim 9, Vergara teaches the method of claim 1,
wherein the declarative specification is a cloud platform independent declarative specification, and wherein executing the aggregate pipeline for the datacenter includes building datacenter entities for the datacenter, destroying datacenter entities for the datacenter, or updating datacenter entities for the datacenter
(See [Column 3, Paragraph 2], The cloud platform independent declarative specification is configured to generate the data center on any of a plurality of cloud platforms and is specified using a cloud platform infrastructure language.
see [Column 17, Paragraph 3], if any updates, deletes, or additions of data center entities need to be performed, they are performed on the cloud platform independent declarative specification
Vergara teaches the declarative specification being cloud platform independent and that building(addition), destroying(delete), or updates can be done through the execution of the pipeline based on this specification.)
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 5, 11-20 rejected under 35 U.S.C. 103 as being unpatentable over Vergara, in view of the Microsoft Azure DevOps Azure Pipelines 2019, September 23 release, “Azure Pipelines - Sprint 158 Update” (hereinafter Azure), and further in view of Laplanche et al. (US 20180069804 A1, herein Laplanche).
As per claim 5, Vergara teaches the method of claim 1,
wherein the stages in the datacenter entity pipeline include at least one provision stage and at least one deploy stage, and wherein the particular stage for which the retry strategy for the datacenter entity pipeline is invoked is a provision stage or a deploy stage
(see [Column 20, Paragraph 6], A master pipeline comprises multiple pipelines, for example, a provisioning pipeline for provisioning resources of the target cloud platform and a deployment pipeline for deploying a software artifact on a data center entity. Each pipeline comprises a sequence of stages
Vergara teaches that the pipeline includes both provision stages and deploy stages. However, Vergara alone does not teach explicitly that the retry would be invoked at a provision or deploy stage.
Azure establishes that “One of the most requested features in multi-stage pipelines is the ability to retry a failed stage without having to start from the beginning. With this update, we are adding a big portion of this functionality.
You can now retry a pipeline stage when the execution fails. Any jobs that failed in the first attempt and those that depend transitively on those failed jobs are all re-attempted.
This can help you save time in several ways. For instance, when you run multiple jobs in a stage, you might want each stage to run tests on a different platform. If the tests on one platform fail while others pass, you can save time by not re-running the jobs that passed. As another example, a deployment stage may have failed due to flaky network connection. Retrying that stage will help you save time by not having to produce another build.”
In the above quote, Azure teaches the ability to retry a multi stage pipeline beginning from the stage that failed. It explicitly states an example where the stage that failed (and thus where the retry begins) is a deployment stage, thus invoking a retry for a pipeline from a deploy or provision stage.
It would have been obvious to one of ordinary skill in the arts to combine the teachings of Azure and Vergara Azure states that the feature being spoken of is “One of the most requested features in multi-stage pipelines”. Vergara is a retry strategy specifically for such multi-stage pipelines, thus someone possessing ordinary skill in the arts would have the motivation and ability described by Azure to combine these teachings with Vergara.)
As per claim 10, Vergara and Azure teach the method of claim 1, further comprising:
generating a deployment manifest associating the datacenter entities of the datacenter with versions of software artifacts targeted for deployment on the datacenter entities wherein a software artifact is associated with a datacenter entity of the datacenter
(see [Column 3, Paragraph 4], The system receives a cloud platform independent artifact version m ap associating data center entities of the data center with versions of software artifacts targeted for deployment on the data center entities.
see [Column 8, Paragraph 4], The artifact version map may also be referred to as a deployment manifest, a version manifest, a software release map, or a software artifact version map.
see [Column 24, Paragraph 2], the deployment module 210 receives an artifact version map that associates various software artifacts and their versions with data center entities… The deployment module 210 generates master pipelines and instructions that ensure that the appropriate software artifact versions are deployed in the data center entities as specified in the artifact version map.
Vergara teaches an artifact version map, also called a deployment manifest, that associates entities with artifacts targeted for deployment. However, Vergara and Azure do not teach that the deployment manifest would necessarily be generated.
Laplanche (0028) states “The manifest generator 216 is a functional module of the service adapter 212 configured to generate a deployment manifest based on a selected plan”
Laplanche explicitly teaches the generating of a deployment manifest. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to adapt the deployment manifest of Vergara and Azure to incorporate the teachings of Laplanche so as to include the generation of the deployment manifest. As set forth in MPEP § 2143, by combining the known technique of generating a deployment manifest as taught by Laplanche with the usage of the deployment manifest of Vergara, one of ordinary skill would expect to achieve the predictable result of generating a deployment manifest that associates entities with artifacts for deployment.);
and executing the aggregate pipeline in conjunction with the deployment manifest for the datacenter on the cloud platform according to the declarative specification
(see Vergara. [Column 21, Paragraph 3], The software release deployment module 230 executes the aggregate pipelines for each service group of each data center.
see Vergara. [Column 27, Paragraph 2], The deployment manifest determines which of these pipelines are active during a particular execution.
see Vergara. [Column 3, Paragraph 3], The system accesses a data center configured on a target cloud platform. The data center is generated based on a cloud platform independent declarative specification
Vergara teaches the ability to execute the aggregate pipeline in accordance with the deployment manifest and declarative specification).
As per claim 11, Vergara in combination with Azure and Laplanche teaches
A non-transitory computer readable medium having program instructions stored thereon that are executable by a computer system to cause the computer system to perform operations comprising:
receiving a request for orchestration of a datacenter on a cloud platform
(see Vergara. [Column 37, Claim 13], A non-transitory computer readable storage medium for storing instructions that when executed by a computer processor cause the computer processor to perform steps
see Vergara. [Column 21, Paragraph 3], The software release deployment module 230 receives a request to deploy a software artifact on a set of data center entities in the target cloud platform. The software release deployment module 230 executes the master pipeline for one or more data centers.
see Vergara. [Column 31, Paragraph 3], The artifact version map and master pipelines are used to orchestrate various types of operations related to continuous delivery of software artifacts in a cloud-based data center. The artifact version map and the master pipelines can be configured to perform aggregate retry operations for a service or a service group or any data center entity.
see Vergara. [Column 22, Paragraph 3], The master pipeline may be driven based on an on-demand manner, for example, by invoking a request using application programming interface (API) of the deployment module 210.
Vergara teaches a non-transitory computer readable medium storing operations (instructions) to be performed (executed). It further teaches that the operations include receiving a request for a “software artifact” where this artifact is used to orchestrate operations for a cloud-based data center.);
accessing a declarative specification for a datacenter on a cloud platform
wherein the datacenter includes a hierarchy of datacenter entities, and
wherein the declarative specification describes dependencies between datacenter entities required for execution of particular datacenter entities
(see Vergara. [Column 3, Paragraph 3], The system accesses a data center configured on a target cloud platform. The data center is generated based on a cloud platform independent declarative specification comprising a hierarchy of data center entities. Each data center entity comprises one or more of (1) a service or (2) one or more other data center entities.
See Vergara. [Column 18, Paragraph 1], The cloud platform independent declarative specification specifies dependencies between services, for example, start dependencies for each service listing all services that should be running when a particular service is started. The data center generation module 220 generates the cloud platform specific detailed metadata representation of the data center that includes information describing these dependencies such that the instructions for deploying the service ensure that the cloud platform starts the services in an order specified by the dependencies such that for each service, the services required to be started before the service are running when the service is started. Accordingly, the dependencies between services represent a dependency graph and the cloud platform starts running the services in an order determined based on the dependency graph such that if service A depends on service B, the service B is started before service A is started.
Vergara teaches a data center on a cloud form based on a declarative specification that details a hierarchy of data center entities. The dependencies being required for execution of a data center entity is taught in Vergara’s description of service dependencies being required before starting the dependent service.);
generating an aggregate pipeline for the datacenter based on the declarative specification
wherein the aggregate pipeline includes a hierarchy of pipelines for datacenter entities of the datacenter, at least some of the pipelines being datacenter entity pipelines for individual datacenter entities, and
wherein a datacenter entity pipeline include stages for deployment of the individual datacenter entity associated with the datacenter entity pipeline
(see Vergara. [Column 22, Paragraph 1], the master pipeline comprises a hierarchy of pipelines. The hierarchy comprises multiple levels and pipelines at a particular level include pipelines of the next lower level as children pipelines.
see Vergara. [Column 22, Paragraph 2], A data center instance pipeline 1010 may include service group pipelines 1020. Each service group pipeline 1020 may include one or more service pipelines 1030. A data center instance pipeline 1010 may include cell pipelines 1025, each cell pipeline 1025 comprising one or more service pipelines 1030. The service pipeline 1030 may comprise stages, each stage representing a pipeline representing instructions for deploying the service for specific environments. The lowest level pipeline or the leaf level pipeline in the hierarchy is referred to as a unit pipeline and may include detailed service specific instructions for performing an operation related to a service. For example, deployment for a service may include pre-deployment steps, deployment steps, post deployment steps, and post deployment test and validation step. A pipeline that is not a leaf level pipeline and has one or more child pipeline is an aggregate pipeline that orchestrates executions of the child pipelines.
see Vergara. [Column 21, Paragraph 2], the pipeline generator module 320 generates pipelines in a hierarchical fashion based on the hierarchy of the data center entities of the data center. For example, the data center comprises data center entities of different types including data centers, service groups, services, and so on. A data center entity may include one or more child data center entities. For example, a data center includes one or more service groups as child data center entities. A service group includes one or more services as child data center entities. Accordingly, the data center generation module 210 starts at a data center entity at a level of the hierarchy and generates pipelines of data center entities below that level. For example, the pipeline generator module 320 starts at the data center level and generates pipelines for service groups within the data center. For each service group, the pipeline generator module 320 generates pipelines for services within the service group.
see Vergara. [Column 20, Paragraph 6], Each pipeline comprises a sequence of stages, each stage representing one or more actions that need to be performed by the target cloud platform towards provisioning and deploying of the data center.
Vergara teaches an aggregate pipeline (the master pipeline) with a hierarchy of pipelines, an entity pipeline with stages for deployment (the quoted service pipeline and its stages), and clarifies that each pipeline comprises stages for deployment (stages needed for the deploying of a data center).
locating retry stages at ends of the datacenter entity pipelines
wherein a retry stage in a datacenter entity pipeline is configured to invoke a retry strategy for the datacenter entity pipeline in response to a failure in execution of a particular stage in the datacenter entity pipeline, and
wherein the retry strategy for the datacenter entity pipeline is invoked starting at the particular stage that failed
(See Vergara. [Column 31, Paragraph 3], the pipeline generator introduces an invoke retrier stage within an aggregate pipeline to trigger a retry strategy if a previous pipeline stage fails.
see Vergara. [Column 36, Claim 1], encountering a failure during execution of a stage of the aggregate pipeline; and repeatedly executing the stage of the aggregate pipeline in accordance with the retry strategy before executing a next stage of the aggregate pipeline.
see Vergara. [Column 33, Paragraph 1], If the execution of the stage S1 of the pipeline corresponding to datacenter entity D1 is retried, the idempotency of execution of the pipeline ensures that the stages that were successfully executed during the previous execution are not executed again during the retry.
Vergara teaches a retry stage in response to encountering a failure. Further, it teaches that the “retrier” ensures that previous successfully executed stages are not executed again, but also that is executes a retry strategy before the next stage of the pipeline begins. Because this retry takes place after the stage that fails, but before the next, it is positioned “at the ends”. The idempotency mentioned in Vergara teaches that no previous successful stages of the pipeline are re-executed, meaning that the retry begins at the stage that failed as claimed.);
generating a deployment manifest associating the datacenter entities of the datacenter with versions of software artifacts targeted for deployment on the datacenter entities
(see Vergara. [Column 3, Paragraph 4], The system receives a cloud platform independent artifact version map associating data center entities of the data center with versions of software artifacts targeted for deployment on the data center entities.
see Vergara. [Column 8, Paragraph 5], The artifact version map may also be referred to as a deployment manifest, a version manifest, a software release map, or a software artifact version map.
see Vergara. [Column 24, Paragraph 2], the deployment module 210 receives an artifact version map that associates various software artifacts and their versions with data center entities… The deployment module 210 generates master pipelines and instructions that ensure that the appropriate software artifact versions are deployed in the data center entities as specified in the artifact version map.
Vergara teaches an artifact version map, also called a deployment manifest, that associates entities with artifacts targeted for deployment. However, Vergara and Azure do not teach that the deployment manifest would necessarily be generated.
Laplanche (0028) states “The manifest generator 216 is a functional module of the service adapter 212 configured to generate a deployment manifest based on a selected plan”
Laplanche explicitly teaches the generating of a deployment manifest.)
wherein a software artifact is associated with a datacenter entity of the datacenter
(see Vergara. [Column 3, Paragraph 4], The system receives a cloud platform independent artifact version map associating data center entities of the data center with versions of software artifacts targeted for deployment on the data center entities.
see Vergara. [Column 8, Paragraph 5], The artifact version map may also be referred to as a deployment manifest, a version manifest, a software release map, or a software artifact version map.
see Vergara. [Column 24, Paragraph 2], the deployment module 210 receives an artifact version map that associates various software artifacts and their versions with data center entities… The deployment module 210 generates master pipelines and instructions that ensure that the appropriate software artifact versions are deployed in the data center entities as specified in the artifact version map.
Vergara teaches an artifact version map, also called a deployment manifest, that associates entities with artifacts targeted for deployment.);
and executing the aggregate pipeline in conjunction with the deployment manifest for orchestration of the datacenter on the cloud platform according to the declarative specification
(see Vergara. [Column 21, Paragraph 2], The software release deployment module 230 executes the aggregate pipelines for each service group of each data center.
see Vergara. [Column 27, Paragraph 2], The deployment manifest determines which of these pipelines are active during a particular execution.
see Vergara. [Column 3, Paragraph 3], The system accesses a data center configured on a target cloud platform. The data center is generated based on a cloud platform independent declarative specification
see Vergara. [Column 31, Paragraph 3], The artifact version map and master pipelines are used to orchestrate various types of operations related to continuous delivery of software artifacts in a cloud-based data center. The artifact version map and the master pipelines can be configured to perform aggregate retry operations for a service or a service group or any data center entity.
Vergara teaches the ability to execute and orchestrate the aggregate pipeline in accordance with the deployment manifest and declarative specification).
As per claim 12, Vergara in combination with Azure and Laplanche teaches the non-transitory computer readable medium of claim 11,
wherein the retry strategy includes at least one conditional expression that is satisfied for execution of a retry of the stage
(see Vergara. [Column 34, Paragraph 1], The tries left stage 1915 checks if the maximum retry count is reached and determines whether to execute the retry branch of the pipeline accordingly.
see Vergara. [Column 31, Paragraph 3], the retry strategy, a threshold number of retries to perform in case of failure to execute a stage of a pipeline, whether confirmation from a user is required before retrying or retry is performed automatically
Vergara teaches a “tries left” stage that is a conditional expression satisfied for execution. Depending on how many retry attempts are allotted, and how many have thus been attempted, the stage is allowed to retry. Thus, the retry of a stage requires a condition (retries remaining) to be satisfied.)
As per claim 13, Vergara in combination with Azure and Laplanche teaches the non-transitory computer readable medium of claim 11,
wherein the retry strategy includes at least one conditional expression that assesses whether the stage has been run successfully during a prior execution of the datacenter entity pipeline
(see Vergara. [Column 29, Paragraph 2], idempotency module 1420 allows the system to check whether a stage successfully completed execution during a prior run of a pipeline
see Vergara. [Column 4, Paragraph 3], If the system determines that the status of the stage for the context indicates a successful execution of the stage, the system skips execution of the stage for the subsequent pipeline execution.
Vergara teaches that the idempotency module checks whether a stage has previously been successfully executed (a conditional).)
As per claim 14, Vergara in combination with Azure and Laplanche teaches the non-transitory computer readable medium of claim 11,
wherein the retry strategy includes restarting execution of the datacenter entity pipeline at an earliest stage in the datacenter entity pipeline that has failed
(see Vergara. [Column 4, Paragraph 3], If the system determines that the status of the stage for the context indicates a successful execution of the stage, the system skips execution of the stage for the subsequent pipeline execution.
see Vergara. [Column 29, Paragraph 7] the system executes only a subset of the stages of the pipeline in the subsequent execution, the subset including stages that did not complete successful execution in the previous run of the pipeline
Vergara teaches a retry strategy where the stages that were previously executed successfully are not retried, and the pipeline only re-executes the stages that previously failed.)
As per claim 15, Vergara in combination with Azure and Laplanche teaches the non-transitory computer readable medium of claim 14,
wherein the earliest stage in the datacenter entity pipeline is a deploy stage or a provision stage
(see Vergara. [Column 20, Paragraph 6], A master pipeline comprises multiple pipelines, for example, a provisioning pipeline for provisioning resources of the target cloud platform and a deployment pipeline for deploying a software artifact on a data center entity. Each pipeline comprises a sequence of stages
Vergara teaches that the pipeline includes both provision stages and deploy stages. However, Vergara alone does not teach explicitly that the retry would be invoked at a provision or deploy stage.
Azure establishes that “One of the most requested features in multi-stage pipelines is the ability to retry a failed stage without having to start from the beginning. With this update, we are adding a big portion of this functionality.
You can now retry a pipeline stage when the execution fails. Any jobs that failed in the first attempt and those that depend transitively on those failed jobs are all re-attempted.
This can help you save time in several ways. For instance, when you run multiple jobs in a stage, you might want each stage to run tests on a different platform. If the tests on one platform fail while others pass, you can save time by not re-running the jobs that passed. As another example, a deployment stage may have failed due to flaky network connection. Retrying that stage will help you save time by not having to produce another build.”
In the above quote, Azure teaches the ability to retry a multi stage pipeline beginning from the stage that failed. It explicitly states an example where the stage that failed (and thus the earliest failure, where the retry begins) is a deployment stage, thus invoking a retry for a pipeline from a deploy or provision stage.
As per claim 16, Vergara in combination with Azure and Laplanche teaches the non-transitory computer readable medium of claim 11,
wherein the retry strategy includes a maximum number of retries attempts that are allowed before failing the datacenter entity pipeline
(see Vergara. [Column 5, Paragraph 2], A retry strategy may specify a maximum number of times an execution of the stage is attempted if the stage execution continues to fail.
Vergara teaches the ability to set a maximum amount of retry attempts.)
As per claim 17, Vergara in combination with Azure and Laplanche teaches A system, comprising:
at least one processor
and memory having program instructions stored thereon that are executable by the at least one processor to cause the system to perform operations comprising:
accessing a declarative specification for a datacenter on a cloud platform in response to receiving a request to orchestrate the datacenter on the cloud platform
wherein the datacenter includes a hierarchy of datacenter entities, and
wherein the declarative specification describes dependencies between datacenter entities required for execution of particular datacenter entities
(see Vergara. [Column 38, Claim 19], A computer system comprising: a computer processor; and a non-transitory computer readable storage medium for storing instructions that when executed by the computer processor, cause the computer processor to perform steps for configuring data centers in a cloud platform
see Vergara. [Column 21, Paragraph 3], The software release deployment module 230 receives a request to deploy a software artifact on a set of data center entities in the target cloud platform. The software release deployment module 230 executes the master pipeline for one or more data centers.
see Vergara. [Column 31, Paragraph 3], The artifact version map and master pipelines are used to orchestrate various types of operations related to continuous delivery of software artifacts in a cloud-based data center. The artifact version map and the master pipelines can be configured to perform aggregate retry operations for a service or a service group or any data center entity.
see Vergara. [Column 3, Paragraph 1], The data center is generated based on a cloud platform independent declarative specification comprising a hierarchy of data center entities.
Vergara teaches a system including processors capable of being executed to perform steps. It further teaches that the operations include receiving a request for a “software artifact” where this artifact is used to orchestrate operations for a cloud-based data center. Vergara also teaches that the data center is based on a declarative specification that includes a hierarchy of datacenter entities.)
generating an aggregate pipeline for the datacenter based on the declarative specification
wherein the aggregate pipeline includes a hierarchy of pipelines for datacenter entities of the datacenter, at least some of the pipelines being datacenter entity pipelines for individual datacenter entities, and
wherein a datacenter entity pipeline include stages for deployment of the individual datacenter entity associated with the datacenter entity pipeline
(see Vergara. [Column 22, Paragraph 1], the master pipeline comprises a hierarchy of pipelines. The hierarchy comprises multiple levels and pipelines at a particular level include pipelines of the next lower level as children pipelines.
see Vergara. [Column 22, Paragraph 2], A data center instance pipeline 1010 may include service group pipelines 1020. Each service group pipeline 1020 may include one or more service pipelines 1030. A data center instance pipeline 1010 may include cell pipelines 1025, each cell pipeline 1025 comprising one or more service pipelines 1030. The service pipeline 1030 may comprise stages, each stage representing a pipeline representing instructions for deploying the service for specific environments. The lowest level pipeline or the leaf level pipeline in the hierarchy is referred to as a unit pipeline and may include detailed service specific instructions for performing an operation related to a service. For example, deployment for a service may include pre-deployment steps, deployment steps, post deployment steps, and post deployment test and validation step. A pipeline that is not a leaf level pipeline and has one or more child pipeline is an aggregate pipeline that orchestrates executions of the child pipelines.
see Vergara. [Column 21, Paragraph 2], the pipeline generator module 320 generates pipelines in a hierarchical fashion based on the hierarchy of the data center entities of the data center. For example, the data center comprises data center entities of different types including data centers, service groups, services, and so on. A data center entity may include one or more child data center entities. For example, a data center includes one or more service groups as child data center entities. A service group includes one or more services as child data center entities. Accordingly, the data center generation module 210 starts at a data center entity at a level of the hierarchy and generates pipelines of data center entities below that level. For example, the pipeline generator module 320 starts at the data center level and generates pipelines for service groups within the data center. For each service group, the pipeline generator module 320 generates pipelines for services within the service group.
see Vergara. [Column 20, Paragraph 6], Each pipeline comprises a sequence of stages, each stage representing one or more actions that need to be performed by the target cloud platform towards provisioning and deploying of the data center.
Vergara teaches an aggregate pipeline (the master pipeline) with a hierarchy of pipelines, an entity pipeline with stages for deployment (the quoted service pipeline and its stages), and clarifies that each pipeline comprises stages for deployment (stages needed for the deploying of a data center).
locating retry stages at ends of the datacenter entity pipelines,
wherein a retry stage in a datacenter entity pipeline is configured to invoke a retry strategy for the datacenter entity pipeline in response to a failure in execution of the datacenter entity pipeline, and
wherein the retry strategy for the datacenter entity pipeline is invoked starting at an earliest failed stage in the datacenter entity pipeline
(See Vergara. [Column 31, Paragraph 3], the pipeline generator introduces an invoke retrier stage within an aggregate pipeline to trigger a retry strategy if a previous pipeline stage fails.
see Vergara. [Column 36, Claim 1], encountering a failure during execution of a stage of the aggregate pipeline; and repeatedly executing the stage of the aggregate pipeline in accordance with the retry strategy before executing a next stage of the aggregate pipeline.
see Vergara. [Column 33, Paragraph 1], If the execution of the stage S1 of the pipeline corresponding to datacenter entity D1 is retried, the idempotency of execution of the pipeline ensures that the stages that were successfully executed during the previous execution are not executed again during the retry.
Vergara teaches a retry stage in response to encountering a failure. Further, it teaches that the “retrier” ensures that previous successfully executed stages are not executed again, but also that is executes a retry strategy before the next stage of the pipeline begins. Because this retry takes place after the stage that fails, but before the next, it is positioned “at the ends”. The idempotency mentioned in Vergara teaches that no previous successful stages of the pipeline are re-executed, meaning that the retry begins at the stage that failed as claimed.);
and generating a deployment manifest associating the datacenter entities of the datacenter with versions of software artifacts targeted for deployment on the datacenter entities
wherein a software artifact is associated with a datacenter entity of the datacenter
(see Vergara. [Column 3, Paragraph 4], The system receives a cloud platform independent artifact version map associating data center entities of the data center with versions of software artifacts targeted for deployment on the data center entities.
see Vergara. [Column 8, Paragraph 5], The artifact version map may also be referred to as a deployment manifest, a version manifest, a software release map, or a software artifact version map.
see Vergara. [Column 24, Paragraph 2], the deployment module 210 receives an artifact version map that associates various software artifacts and their versions with data center entities… The deployment module 210 generates master pipelines and instructions that ensure that the appropriate software artifact versions are deployed in the data center entities as specified in the artifact version map.
Vergara teaches an artifact version map, also called a deployment manifest, that associates entities with artifacts targeted for deployment. However, Vergara and Azure do not teach that the deployment manifest would necessarily be generated.
Laplanche (0028) states “The manifest generator 216 is a functional module of the service adapter 212 configured to generate a deployment manifest based on a selected plan”
Laplanche explicitly teaches the generating of a deployment manifest.)
and executing the aggregate pipeline in conjunction with the deployment manifest to orchestrate the datacenter on the cloud platform according to the declarative specification
(See Vergara. [Column 21, Paragraph 3], The software release deployment module 230 receives a request to deploy a software artifact on a set of data center entities in the target cloud platform. The software release deployment module 230 executes the master pipeline for one or more data centers. The software release deployment module 230 executes the aggregate pipelines for each service group of each data center. The aggregate pipeline comprises pipelines for services within the service group. For each service within each service group, the pipeline is executed by executing all the stages of the pipeline. The execution of the provisioning pipelines results in provisioning of the resource for a service and the deployment pipeline causes deployment of the service in the target cloud platform.
see Vergara. [Column 19, Paragraph 4], The software release management module 230 compiles 740 the cloud platform independent master pipeline to generate a cloud platform specific detailed deployment pipeline that is specific to the hierarchy of data center entities of each data center as specified by the cloud platform independent declarative specification
see Vergara. [Column 31, Paragraph 3], The artifact version map and master pipelines are used to orchestrate various types of operations related to continuous delivery of software artifacts in a cloud-based data center.
Vergara teaches that the aggregate pipeline (the master pipeline) is executed based on the declarative specification, and is deployed on the cloud platform. It further teaches that the artifact version map (also referred to as a deployment manifest in Vergara) orchestrates the data center.)
As per claim 18, Vergara in combination with Azure and Laplanche teaches the system of claim 17,
wherein the stages in the datacenter entity pipeline include at least one provision stage and at least one deploy stage
(see Vergara. [Column 20, Paragraph 6], A master pipeline comprises multiple pipelines, for example, a provisioning pipeline for provisioning resources of the target cloud platform and a deployment pipeline for deploying a software artifact on a data center entity. Each pipeline comprises a sequence of stages, each stage representing one or more actions that need to be performed by the target cloud platform towards provisioning and deploying of the data center.
Vergara teaches the existence of provision and deploy stages in the pipelines).
As per claim 19, Vergara in combination with Azure and Laplanche teaches the system of claim 17,
wherein program instructions include instructions not to rerun a stage during a retry when the stage has already been successfully run
(see Vergara. [Column 4, Paragraph 3], If the system determines that the status of the stage for the context indicates a successful execution of the stage, the system skips execution of the stage for the subsequent pipeline execution.
Vergara teaches that the system does not re-execute or retry a stage that was successfully run).
As per claim 20, Vergara in combination with Azure and Laplanche teaches the system of claim 17,
wherein program instructions include instructions not to rerun a stage during a retry when any stage before the stage has failed
(see Vergara. [Column 29, Paragraph 5], The pipeline may be configured such that the execution of subsequent stages stops when one stage fails
Vergara teaches that the failure of a stage will prevent the running of stages positioned after it).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jefferson Matricardi whose telephone number is (571) 270 0765. The examiner can normally be reached Mon-Fri 8:00-4:00 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.T.M./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights