DETAILED ACTION
Claims 1-20 are pending.
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 .
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 6-9, 11, 13-16, and 19-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Dockter et al. (US 2021/0224076 A1).
Dockter was cited in IDS.
Regarding claim 1, Dockter teaches the invention as claimed including A computer-implemented method ([0003] In some embodiments, a computer-implemented method is disclosed.), comprising:
obtaining, by a cloud infrastructure orchestration system, a service plan defining a first release execution order for executing a release of one or more releases associated with a first process for bootstrapping a service of a plurality of services at one or more execution targets of a cloud-computing environment ([0002] cloud infrastructure services utilize many individual services to provision and deploy code and configuration (respectively) across the cloud infrastructure service's many regions. [0055] Release plan—The set of steps that the a cloud infrastructure orchestration service CIOS would take to transition all regions from their current state to the state described by a release. [0056] Release plans have a finite number of steps and a well-defined start and end time.; [0073] A release may include any suitable combination of tasks related to one or more infrastructure components and/or one or more code changes to one or more applications (e.g., artifacts).; [0028] As various resources of the system are deployed and/or booted up these resources may publish to a scheduling service an indication of the various capabilities availability as the capabilities become available. As used herein, the term “boot,” “booting,” “booted” refer to a process of performing a startup sequence of operations corresponding to a particular resource (e.g., a software service, a computing device, etc.). Deploying a resource (e.g., a software service) can include booting and/or otherwise making available at least some portion of functionality provided by the resource; [0152]);
generating, by the cloud infrastructure orchestration system, a directed acyclic graph based at least in part on a plurality of service plans comprising the service plan, the directed acyclic graph defining a second release execution order for executing a set of releases comprising the one or more releases, the second release execution order comprising the first release execution order for executing the one or more releases associated with the first process for bootstrapping the service ([0003] The computer-implemented method comprises operations performed by a declarative infrastructure provisioner (DIP) of a computing system. In some embodiments, the DIP parses configuration data associated with the computing system and generates a directed acyclic graph (DAG) for booting a first resource of the computing system based at least in part on the parsing. The DAG may specify a dependency of the first resource of the computing system on a capability of a second resource of the computing system. The DIP may traverse the DAG, where operations for booting the first resource are performed in accordance with the traversing.; [0109]; [0104]; Fig. 3-4);
executing, by the cloud infrastructure orchestration system, the release at an execution target of the one or more execution targets as part of a second process for bootstrapping the plurality of services at the one or more execution targets of the cloud-computing environment, the release being executed according to the second release execution order ([0076] In some examples, CIOS Regional 202 is where much of the work of declarative provisioning and planning, as well as approved release application can occur. In some instances, each instance of CIOS Regional 202 may have a regional fronted that can handle operations at the level of “Execution Targets.” It can be configured to perform the following: [0077] Handling all CIOS Authentication for incoming operations from CIOS Central 102. [0078] Enforcing a rule that only one “execution” (plan/import resources/apply plan) can be ongoing for a given Execution target at a time.; [0101] Teams approve tactical releases just like world-wide releases. CIOS orchestrates them similarly. If a team needs to deploy a tactical release while there is an active a world-wide release, CIOS will stop executing the world-wide release in the targeted regions, then start executing the tactical release.; Fig. 3; [0109] CIOS executes ETs based on the DAG 200 defined in the flock config.; Claim 6, wherein the infrastructure deployment operations correspond to bootstrapping tasks of a plurality of infrastructure components of the computing system.); and
tracking, by the cloud infrastructure orchestration system, a state of the execution target based at least in part on executing the release at the execution target as part of the second process for bootstrapping the plurality of services at the one or more execution targets of the cloud-computing environment ([0031] In some instances, the workflow of the provisioning tool may be configured to perform various commands. One function that can be performed is view reconciliation, where the provisioning tool can compare the view of the current infrastructure (e.g., the expected state of the infrastructure) with how the infrastructure is actually running. In some instances, performing the view reconciliation function may include querying various resource providers or infrastructure resources to identify what resources are actually running. Another function that the provisioning tool can perform is plan generation, where the provisioning tool can compare the actually running infrastructure components with what the provisioning tool wants the state to look like (e.g., the desired configuration). In other words, the plan generation function can determine what changes need to be made to bring the resources up to the most current expectations. In some instances, a third function is the execution (e.g., apply) function, where the provisioning tool can execute the plan generated by the plan generation function.; [0052] State—A point-in-time snapshot of the state of every resource in the flock.; Claim 6).
Regarding claims 2, 9 and 16, Dockter teaches wherein the first release execution order is defined based at least in part on a plurality of execution target checkpoint transitions, each execution target transition being associated with a release of the one or more releases and a transition between a pair of execution target checkpoints of a plurality of execution target checkpoints associated with the service ([0093] [0093] Launch and monitor declarative infrastructure provisioning containers for doing the real work of a Release for an Execution Target. [0101] When generating a plan, teams may ask CIOS to target the plan at specific resources in several ways: topologically (e.g., realm, region, AD, etc.), by resource type (e.g., “only metrics configs” or “only deployment orchestration service deployments”, etc.), or combinations of the above (e.g., in a disjunctive manner). Teams approve tactical releases just like world-wide releases. CIOS orchestrates them similarly.; [0109] FIG. 3 depicts a directed acyclic graph (DAG) 300 for illustrating an example flock 302. The progression of code/config from check-in to production, for a single flock config in CIOS, can be described all the way from the first testing deployment to the last prod deployment. Internally, CIOS calls each element in the progression an Execution Target (ET)—this is all over our internal APIs, but does not leak out in to the flock config. CIOS executes ETs based on the DAG 200 defined in the flock config. Each ET (e.g., ET-1, ET-2, ET-3, ET-4, ET-5, ET-6, and ET-7) is, roughly, one copy of the
service described by the flock config.).
Regarding claims 6, 13 and 19, Dockter teaches further comprising generating, by the cloud infrastructure orchestration service, a release plan defining the second process for bootstrapping the plurality of services at the one or more execution targets of the cloud-computing environment, wherein the release plan is generated based at least in part on traversing the directed acyclic graph ([0003]).
Regarding claims 7, 14, and 20, Dockter teaches wherein tracking the state of the execution target comprises updating the state with a value corresponding to an execution target checkpoint ([0031]; [0052]; [0055]).
Regarding claim 8, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above. Further, the additional limitations one or more processors; and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to are taught by Dockter in at least [0005] “In other embodiments, a non-transitory computer-readable storage medium is disclosed that may include one or more processors of a declarative infrastructure provisioner and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause”
Regarding claim 15, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above. Further, the additional limitations one or more processors; and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to are taught by Dockter in at least [0005] “In other embodiments, a non-transitory computer-readable storage medium is disclosed
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3-5, 10, 12, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Dockter et al. (US 2021/0224076 A1) in further view Chaganti et al. (US 2020/0244545 A1).
Regarding claim 3 and 10, Dockter teaches wherein the state of the execution target is associated with an execution target checkpoint, the execution target checkpoint being associated with one or more build flags ([0003] The DAG may specify a dependency of the first resource of the computing system on a capability of a second resource of the computing system. The DIP may traverse the DAG, where operations for booting the first resource are performed in accordance with the traversing. Based at least in part on the traversing of the DAG, the DIP may determine that the dependency of the DAG has been reached. The DIP may publish, to a scheduling process of the computing system, an indication that the first resource is awaiting availability of the capability of the second resource. In some embodiments, the DIP receives a subsequent indication that the capability is available, regenerates the DAG, and recommences traversal of the DAG. Additional operations for booting the first resource of the computing system are performed in accordance with the recommenced traversal.).
Dockter does not explicitly teach the execution target checkpoint being associated with one or more build flags.
However, Chaganti the execution target checkpoint being associated with one or more build flags (Abstract: A deployment orchestrator for managing deployment of a solution architecture includes persistent storage that stores a deployment plan and a deployment manager that orchestrates display, to a user of a user device of the solution architecture, of a graphical user interface (GUI) based on the deployment plan; obtains a task completion indicator for a task specified by the deployment plan via the graphical user interface).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chaganti of using a completion indicator to track status of different deployment stages as taught by Dockter. The modification would have been motivated by the desire of tracking each orchestration stage.
Regarding claim 4, 10, and 17, Chaganti teaches wherein each build flag of the one or more build flags indicates that execution of a corresponding release associated with a corresponding execution target checkpoint has been successfully executed ([0084] In one or more embodiments of the invention, the task completion indicator specifies that a task of the deployment plan has allegedly been completed.).
Regarding claim 5, 12, and 18, the combination teaches wherein the service is a first service, wherein at least one release of the set of releases associated with the second process is associated with a second service, and wherein a dependency of the at least one release associated with the second process on successful execution of the release associated with the first service is expressed based at least in part on a build flag of the one or more build flags associated with the execution target checkpoint (Dockter’s [0003] and Chaganti’s [0069] For example, groups of tasks that are mutually dependent upon completion of another task may be demarcated from the task upon which the group of tasks depends. In FIG. 3, for example, task A graphical user interface element (300) and task B graphical user interface element (302) are demarcated from task E graphical user interface element (310) because task E depends on both task A and task B of the deployment plan. The ordering indicators (320) may have different thicknesses, coloring, or other visual indicators to indicate particular types of groupings. For example, a thick line used as an ordering indicator may indicate a task that is dependent upon a string of other tasks that each depends upon each other.; [0080; [0084]; [0114] In response to the report, the deployment orchestrator changes a visual appearance of the first and second dependency indicators (520.2, 520.4) to long dashing to indicate the alleged completion as shown in FIG. 5.3.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gross (US 2023/0014635 A1) MULTI-REGION DEPLOYMENT OF JOBS IN A FEDERATED CLOUD INFRASTRUCTURE. See at least [0039].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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 J 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights