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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 03/23/2022. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
Applicant's arguments filed 12 have been fully considered but they are not persuasive.
On page 10, applicant argues that Glass does not teach “launching, by the one or more processors, a reconciler in response to the deployment event,” and “initiating, by the reconciler, a reconciliation process for the deployment event”. Examiner respectfully disagrees. This argument is not persuasive because the rejection does not only rely on Glass alone for the reconciler aspect. Glass teaches receipt of a deployment task/event and initiation of deployment handling. Glass teaches on [0151] At 1308, the scheduler 1302 may receive a task for deploying infrastructure resources in a region, and the scheduler 1302 may transmit data pertaining to the task to the worker 1304. In some embodiments, the scheduler 1302 may instantiate the worker 1304 to handle deployment of a resource (e.g., a service). Rudraraju teaches on [0010] that CRAFT creates custom resources operators and provides “automated and/or controlled reconciliation” for resources during application/service deployment, and further teaches on [0115] “reconciliation logic”. Rudraraju also explains that the controller file includes operator image and that the CRAFT creates an operator container image for deployment [0068-0070]. Thus the combined teachings of Glass and Rudraraju suggest invoking operator reconciliation logic in response to a deployment event within a virtualized operator environment.
On page 11, applicant argues that Glass does not teach “launching, by the reconciler, a master executor in the virtualized operator environment” . Examiner respectfully disagrees. Under BRI, Glass’s CIOS executor/ scheduler reads on the claimed master executor because it handles the execution, tracks available worker nodes, assigns job request to eligible workers, track worker status and execution updates. [0086] In some instances, the CIOS Frontend may be dependent on a CIOS Executor 206 (also referred to herein as a “scheduler”), which can handle the actual execution. The CIOS Executor, in some examples, operates at the level of “Execution,” and it can: [0087] Track a pool of available Worker nodes [0088] Query incoming job requests, and assigns them to eligible workers as available [0089] Track worker status and Execution updates for reporting to clients [0090] Detect dead nodes via a leasing protocol, and can fail tasks assigned to dead nodes, depending on task status. [0091] Provide facilities to cancel/kill/pause/resume Executions, and can map those onto facilities to pass cancellation/kill/resumption info on to Worker nodes. Rudraraju also teaches the operator/controller framework in which reconciliation logic is implemented and deployed in Kubernetes using operator files and operator container images. See Rudraraju [0067-0073] and [0115]. The combined teachings of Glass and Rudraraju suggest a reconciler/operator environment that invokes or triggers Glass’s executor-based deployment.
On page 11, applicant argues that Glass merely assigns task to existing workers and therefore does not teach "causing, by the master executor, a plurality of executors to be launched in the virtualized operator environment, each executor being configured to execute a respective one of the plurality of task lists". Examiner respectfully disagrees. Glass teaches that the scheduler may instantiate a worker to handle deployment of a resource. “[0151] At 1308, the scheduler 1302 may receive a task for deploying infrastructure resources in a region, and the scheduler 1302 may transmit data pertaining to the task to the worker 1304. In some embodiments, the scheduler 1302 may instantiate the worker 1304 to handle deployment of a resource (e.g., a service).” Glass further teaches that each worker is an agent executing assigned task. See Glass [0092-0099]. These teachings suggest causing execution agents to be brought to operation to execute deployment tasks. Further Glass teaches the execution of targets sharing a common dependency may be executed concurrently. The reference teaches coordinated task execution, including instantiation of workers and container based execution of assigned task items.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9-10 and 12-16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 9, the claim recites “a processing unit” in the preamble, but later recites “launching, by the one or more processors”. There is no antecedent basis in claim 9 for “the one or more processors”. Claims 10 and 12-16 are rejected based on their dependency on claim 9.
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-6, 8-10, 12-14, 16-17 and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over by Glass (US 20210224122 in view of Rudraraju (US 20220012045 A1).
Regarding claim 1, Glass teaches:
A computer-implemented method comprising: (Claim 1. A computer-implemented method, comprising)
receiving, by one or more processors, a deployment event for a plurality of services in a computing cluster; and ([0151] At 1308, the scheduler 1302 may receive a task for deploying infrastructure resources in a region, and the scheduler 1302 may transmit data pertaining to the task to the worker 1304. In some embodiments, the scheduler 1302 may instantiate the worker 1304 to handle deployment of a resource (e.g., a service).)
performing, by the one or more processors, a reconciliation process in a virtualized operator environment for deployment of the plurality of services, the reconciliation process comprising: ([0036] 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. See also [0025, 0028]))
obtaining, by the one or more processors, a plurality of task lists for the deployment of the plurality of services by parsing a service specification associated with the deployment event, and ([0152] At 1310, the worker 1304 may instantiate IP process 1306 which may be configured to execute an instance of a declarative infrastructure provisioner (e.g., the declarative provisioning tool, Terraform, discussed above).[0153] At 1312, the IP process 1306 may parse a configuration file (e.g., a configuration file that includes code segments 1000 and/or 1100 of FIGS. 10 and 11) associated with the deployment to generate a directed acyclic graph (DAG) for a particular resource. Through parsing the configuration, the IP process 1306 (the declarative infrastructure provisioner) may identify any suitable number of implicit and/or explicit dependencies on capabilities of other resources. Once identified, the IP process 1306 builds a DAG that specifies tasks for booting and/or deploying a resource with potentially one or more nodes that correspond to a capability on which the resource depends (e.g., in accordance with the implicit and/or explicit dependencies identified during the parsing).)
causing, by the master executor, a plurality of executors to be launched in the virtualized operator environment, each executor being configured to execute a respective one of the plurality of task lists. ([0092] In some instances, the CIOS Executor can depend on CIOS Workers, which can assign tasks for execution to Workers, and provide a facility for Workers to update job progress. The worker service operates at the granularity of “Task.” Each worker is an agent executing Tasks assigned to that worker and reporting Task status and output. Each worker can: [0093] Poll Executor Worker APIs for assigned work items, and take action to make the assign state match its local state: [0094] start containers for polls task items that do not exist locally [0095] kill containers for locally running containers that have no corresponding assigned task item [0096] Report status for jobs [0097] Stage input and output for job container execution [0098] Launch and monitor declarative infrastructure provisioning containers for doing the real work of a Release for an Execution Target.[0099] CIOS Workers may depend on CIOS Executor to poll work from and report results to the worker endpoint of the CIOS Executor. The Worker may rely on the Executor for all coordination. Additionally, the CIOS Workers may also depend on CIOS Regional 202, where the Worker services reads input from and writes output to one or more APIs that are associated with the Regional Frontend service. Examples of input are configuration and starting state files and import mappings. Examples of output are declarative provisioning process, output declarative provisioning state files, and import result states. [0151] At 1308, the scheduler 1302 may receive a task for deploying infrastructure resources in a region, and the scheduler 1302 may transmit data pertaining to the task to the worker 1304. In some embodiments, the scheduler 1302 may instantiate the worker 1304 to handle deployment of a resource (e.g., a service). See also [0160] )
deploying, by the one or more processors, the plurality of services into the computing cluster by launching the plurality of executors to at least partially parallelly execute tasks in the plurality of task lists. ([0092] In some instances, the CIOS Executor can depend on CIOS Workers, which can assign tasks for execution to Workers, and provide a facility for Workers to update job progress. The worker service operates at the granularity of “Task.” Each worker is an agent executing Tasks assigned to that worker and reporting Task status and output. Each worker can: [0093] Poll Executor Worker APIs for assigned work items, and take action to make the assign state match its local state: [0094] start containers for polls task items that do not exist locally [0095] kill containers for locally running containers that have no corresponding assigned task item [0096] Report status for jobs [0097] Stage input and output for job container execution [0098-0099] Launch and monitor declarative infrastructure provisioning containers for doing the real work of a Release for an Execution Target.)
Glass does not appear to explicitly teach: launching, by the one or more processors, a reconciler in response to the deployment event, initiating, by the reconciler, a reconciliation process for the deployment event, and launching, by the reconciler, a master executor in the virtualized operator environment,
However, Rudraraju teaches: [0010] CRAFT declares operators in a robust and generic way for any resource, letting developers focus on CRUD operations of resource management in an idempotent way, in a language of their choice. In embodiments, CRAFT offers support for all languages, and therefore, the CRUD operations of the operator can be written in any language. The embodiments herein also provide automated and/or controlled reconciliation for any resource to create native abstractions. Here, “reconciliation” may refer to processes or procedures for verifying data, and may take place during application/service deployment and/or during data migration. Reconciliation may involve comparing target data with source data to ensure that the deployment or migration architecture is operating as intended. In some embodiments, structural schema validation for a Custom Resource Definition (CRD) happens within CRAFT while creating an operator. In some embodiments, CRAFT may provide automated data validation and reconciliation (DVR), which involves using mathematical models to automatically recalibrate or correct the resource(s) and/or structural schema(s). [0115] Once the controller skeleton is generated, the reconciliation logic 305a and 305b can then be implemented. Operatify 305a is used for this purpose because this functionality is not offered by the Kubebuilder 308. See also [0053],[0061-0063], [0063], [0070-073]. E.N.: CRAFT automated reconciliation module (reconciler). It is invoked (launched) to execute the reconciliation process by verifying and correcting configurations
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Glass and Rudraraju before them, to include Rudraraju’s reconciler components with Glass’s system of using graphs for deployment. One would have been motivated to make such a combination to improve the deployment system by providing a reconciler component capable of automatically verifying the state of the deployed resources.
Regarding claim 2, Glass does not appear to explicitly teach:
The method of claim 1, wherein the deployment event comprises an instance of a custom resource definition for the computing cluster, and wherein parsing the service specification comprises: parsing the service specification according to the instance of the custom resource definition.
However, Rudraraju teaches: [0063] FIG. 2 shows a context diagram that shows how a Custom Resource Abstraction and Fabrication Tool (CRAFT) is used to automatically create an operator that can be used to deploy an application, in accordance with embodiments. As discussed above, CRAFT may be used to declare custom resource operators (e.g., Kubernetes operators) in a high level, generic way for any resource. A “resource” may refer to an object with a type, associated data, a set of methods that operate on it, and relationships to other resources (if applicable). For purposes of the present disclosure, a “resource” may additionally or alternatively include a component that makes up a part of an application or application service. For example, in a customer relationship management (CRM) application, resources may include an email server, database server, and an analytics server, or components thereof. These resources may be customized to include business logic and operational processes, for example, to be included in the deployed application or service.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Glass and Rudraraju before them, to include Rudraraju’s methods for custom resource deployment with Glass’s system of using graphs for deployment. One would have been motivated to make such a combination to more efficiently and reliably orchestrate multi-service deployment by providing the right type of environment for execution.
Regarding claim 4, Glass teaches:
The method of claim 3, further comprising : distributing, by the reconciler, the plurality of task lists to the master executor; and causing, by the master executor. ([0151] At 1308, the scheduler 1302 may receive a task for deploying infrastructure resources in a region, and the scheduler 1302 may transmit data pertaining to the task to the worker 1304. In some embodiments, the scheduler 1302 may instantiate the worker 1304 to handle deployment of a resource (e.g., a service).[0152] At 1310, the worker 1304 may instantiate IP process 1306 which may be configured to execute an instance of a declarative infrastructure provisioner (e.g., the declarative provisioning tool, Terraform, discussed above).[0153] At 1312, the IP process 1306 may parse a configuration file (e.g., a configuration file that includes code segments 1000 and/or 1100 of FIGS. 10 and 11) associated with the deployment to generate a directed acyclic graph (DAG) for a particular resource. Through parsing the configuration, the IP process 1306 (the declarative infrastructure provisioner) may identify any suitable number of implicit and/or explicit dependencies on capabilities of other resources. Once identified, the IP process 1306 builds a DAG that specifies tasks for booting and/or deploying a resource with potentially one or more nodes that correspond to a capability on which the resource depends (e.g., in accordance with the implicit and/or explicit dependencies identified during the parsing).[0160] At 1328, in response to determining that the capabilities on which the resource corresponding to IP process 1306 depends have become available, the scheduler 1302 may return to step 1308, where it transmits data pertaining to the original task (e.g., deploying the resource) to the worker 1304. In some embodiments, the scheduler 1302 may instantiate a new worker or utilize the previous worker 1304 (as depicted) to continue handling the task associated with the resource. The worker 1304 may instantiate IP process (not depicted) which may be configured to execute parse the configuration file to generate the DAG for the resource. The IP process may access the stored state information to identify the node that was last access in the DAG (e.g., the node corresponding to the one or more capabilities for which the resource was waiting). See also [0025, 0028, 0165-0166])
Regarding claim 5, Glass teaches:
The method of claim 1, wherein the service specification indicates a dependency relationship between the plurality of services, and wherein causing, by the master executor, a plurality of executors to be launched comprises: determining, based on the dependency relationship, an execution plan for at least partially parallel execution of the tasks in the plurality of task lists; and launching the plurality of executors according to the execution plan. ([0133] Although four execution targets are defined in FIG. 8, it should be appreciated that any suitable number of phases may be defined in a similar manner. In some embodiments, execution targets may share a common dependency (e.g., identical predecessors definitions). A common dependency may be utilized to indicate that tasks associated with execution targets that share the common dependency may be executed concurrently. [0135] Each node of the DAG 900 may include a pointer/reference to one or more nodes in the DAG 90). By way of example, node 902 may include a reference to node 904, which may include references to nodes 906-910, which each may include a reference to node 912, which may indicate (e.g., via a null pointer) that it is the end node of the DAG 900. In some embodiments, these pointers/references may be identified based on indicators similar to indicators 818-824 discussed above in connection with FIG. 8. In some embodiments, nodes 906, 908, and 910 may share a common dependency to node 904, thus the tasks associated with the nodes 906-910 may be executed, at least in part, concurrently. In some embodiments, node 912 may correspond to an execution target that depends on nodes 906-910. Thus, tasks associated with the execution target corresponding to node 912 may be executed only after tasks associated with all of the execution targets corresponding to nodes 906-910 have been completed.)
Regarding claim 6, Glass teaches:
The method of claim 5, wherein the dependency relationship indicates that a first service of the plurality of services depends on a second service of the plurality of services, and a third service of the plurality of services does not depend on a fourth service of the plurality of services, and wherein the execution plan indicates that tasks in a first task list of the plurality of task lists for deployment of the first service are to be executed after tasks in a second task list of the plurality of task lists for deployment of the second service, and tasks in a third task list of the plurality of task lists for deployment of the third service are to be executed in parallel with execution of tasks in a fourth task list of the plurality of task lists for deployment of the fourth service. ([0142-0148] CIOS (or a declarative infrastructure provisioner such as the declarative provisioning tool of CIOS, discussed above) may be utilized to parse the configuration file including code segment 1000. Through this parse, CIOS (or the declarative provisioning provisioner) may generate a directed acyclic graph (DAG) for each resource, module, and/or capability that compiles and defines an ordered list of dependencies on other resources, modules, and/or capabilities. While attempting to deploy a resource, CIOS may traverse the DAG to identify when a resource is dependent on another resource, module, and/or capability. The DAG for each resource may specify implicit dependencies, explicit dependencies, or a combination thereof and may be used for booting or otherwise deploying the corresponding resource with CIOS.; see also [0154 and 0171-0175)
Regarding claim 8, Glass teaches:
The method of claim 1, further comprising: collecting, by the one or more processors, a plurality of execution results of the tasks in the plurality of task lists from the plurality of executors; and determining, by the one or more processors, an event status for the deployment event based on the plurality of execution results, the event status indicating whether the deployment of the plurality of services successes or fails. ([0092] In some instances, the CIOS Executor can depend on CIOS Workers, which can assign tasks for execution to Workers, and provide a facility for Workers to update job progress. The worker service operates at the granularity of “Task.” Each worker is an agent executing Tasks assigned to that worker and reporting Task status and output. Each worker can: [0093] Poll Executor Worker APIs for assigned work items, and take action to make the assign state match its local state: [0094] start containers for polls task items that do not exist locally [0095] kill containers for locally running containers that have no corresponding assigned task item [0096] Report status for jobs [0097] Stage input and output for job container execution [0098] Launch and monitor declarative infrastructure provisioning containers for doing the real work of a Release for an Execution Target. [0101] In some examples, CIOS Central 102 can call CIOS Regional 202 to create plans, push approvals, watch job status (service principal), and extract declarative provisioner state (service principal). An ingress proxy 218 can be configured as the ACL and various identity policies may be used for both authentication and authorization. Alternatively, in some examples, the ingress proxy 218 may be replaced with a load balancer configured to balance the load incoming requests, plans, etc. In some instances, CIOS Regional 202 may run a declarative provisioner by asking the scheduler 206 to do so. Worker 210 can ask Scheduler 206 what it should be running, and can report status to Scheduler 206 when done.)
Regarding claim 9, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Glass also teaches:
A system comprising: a processing unit; and a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, performing acts including:. (Claim 10. A system, comprising: one or more processors; and one or more memories storing computer-executable instructions that, when executed by the one or more processors, configure the one or more processors to:)
Regarding claim 10, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 12, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 16, the claim recites similar limitation as corresponding claim 8 and is rejected for similar reasons as claim 8 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Glass also teaches:
A computer program product being tangibly stored on a non-transient machine-readable medium and comprising machine-executable instructions, the instructions, when executed on a device, causing the device to perform acts including. (Claim 15. A computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:)
Regarding claim 22, Rudraraju teaches:
The method of claim 1 further comprising: determining, by the master executor, an execution plan for at least partially parallel execution of tasks in the plurality of task lists based on a dependency relationship. ([0043] In some embodiments, the stream processor(s) 105 may be used to orchestrate container spin-up and deployment, as well as generate operators based on one or more configuration files according to the embodiments discussed herein. [0053] Each application server 100 is communicably coupled with tenant DB 22 and system DB 24, for example, having access to tenant data 23 and system data 25, respectively, via a different network connection 15. For example, one application server 1001 can be coupled via the network 14 (e.g., the Internet), another application server 100N can be coupled via a direct network link 15, and another application server 100N can be coupled by yet a different network connection 15. Transfer Control Protocol and Internet Protocol (TCP/IP) are examples of typical protocols that can be used for communicating between application servers 100 and the system 16. However, it will be apparent to one skilled in the art that other transport protocols can be used to optimize the system 16 depending on the network interconnections used. The application servers 100 may access the tenant data 23 and/or the system data 25 using suitable private APIs as discussed previously. See also [0019, 0064-0067] )
Further, Glass teaches launching, by the reconciler, a master executor in the virtualized operator environment; and determining, by the master executor, an execution plan for at least partially parallel execution of tasks in the plurality of task lists based on a dependency relationship (0092] In some instances, the CIOS Executor can depend on CIOS Workers, which can assign tasks for execution to Workers, and provide a facility for Workers to update job progress. The worker service operates at the granularity of “Task.” Each worker is an agent executing Tasks assigned to that worker and reporting Task status and output. Each worker can: [0093] Poll Executor Worker APIs for assigned work items, and take action to make the assign state match its local state: [0094] start containers for polls task items that do not exist locally [0095] kill containers for locally running containers that have no corresponding assigned task item [0096] Report status for jobs [0097] Stage input and output for job container execution [0098-0099] Launch and monitor declarative infrastructure provisioning containers for doing the real work of a Release for an Execution Target.)
Regarding claim 23, Glass teaches:
The method of claim 22 further comprising: parsing the service specification to get a role list; launching a plurality of executors and distributing the role list among the executors; executing, by the executors, the task list and send execution results to master executor; and recording, by the reconciler, an event status. ([0086] In some instances, the CIOS Frontend may be dependent on a CIOS Executor 206 (also referred to herein as a “scheduler”), which can handle the actual execution. The CIOS Executor, in some examples, operates at the level of “Execution,” and it can: [0087] Track a pool of available Worker nodes [0088] Query incoming job requests, and assigns them to eligible workers as available [0089] Track worker status and Execution updates for reporting to clients [0090] Detect dead nodes via a leasing protocol, and can fail tasks assigned to dead nodes, depending on task status. [0091] Provide facilities to cancel/kill/pause/resume Executions, and can map those onto facilities to pass cancellation/kill/resumption info on to Worker nodes. [0092] In some instances, the CIOS Executor can depend on CIOS Workers, which can assign tasks for execution to Workers, and provide a facility for Workers to update job progress. The worker service operates at the granularity of “Task.” Each worker is an agent executing Tasks assigned to that worker and reporting Task status and output. Each worker can: [0093] Poll Executor Worker APIs for assigned work items, and take action to make the assign state match its local state: [0094] start containers for polls task items that do not exist locally [0095] kill containers for locally running containers that have no corresponding assigned task item [0096] Report status for jobs [0097] Stage input and output for job container execution [0098] Launch and monitor declarative infrastructure provisioning containers for doing the real work of a Release for an Execution Target. E.N. The executors are launch and task distributes, results collected and recorded as deployment status)
Claims 7 and 15 is rejected under 35 U.S.C. 103 as being unpatentable over by Glass (US 20210224122 in view of Rudraraju (US 20220012045 A1) and in further view of Banerjee (US 20220035650 A1), hereafter Banerjee.
Regarding claim 7, Glass does not appear to explicitly teach:
The method of claim 1, wherein the virtualized operator environment comprises an Ansible operator, and wherein the service specification comprises a role list with each of the plurality of task lists specified as one role in the role list.
However, Banerjee teaches: ([0076] The operation begins at step 502, where references to intent files, such as manifests, YAML and XML files, which are stored in the repositories 154, that are needed to execute a lifecycle management operation of a CNF in a particular container-based virtual infrastructure 106 are identified. Depending on the orchestration scheme utilized in the container-based virtual infrastructure, the intent files that are needed will differ. As an example, the intent files may be Helm charts, Heat templates, BPM scripts, Ansible scripts that can manage containers or Kustomize. In some embodiments, these references are provided by the vendor of the container-based virtual infrastructures.; see also [0047-0051)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Glass and Banerjee before them, to include Banerjee’s Ansible scripts that manage containers(virtual environments ) with Glass’s system of using graphs for
Regarding claim 15, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m 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, LEWIS BULLOCK JR can be reached at (571)272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199