Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/29/2024, 03/25/2025 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
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 of this title, 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-4, 6-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dobrev et al. (U.S. Pub. No. 20200159573 A1) in view of Minna et al. “An Open-Source Cloud Testbed for Security Experimentation”.
As per claim 1, Dobrev teaches the invention substantially as claimed including a method, comprising:
obtaining a … automation file comprising an indication of a set of tasks for automating a process (par. 0068 generates a task list 240 of tasks in the automation plan(s) 128 to deploy the SDDC 202 and/or the virtual appliance(s); par. 0108 automation plan configuration files 1402);
providing, via a host operating system (OS) of a device, the … automation file to a container instance managed by a container engine (par. 0056 The deployment director 124 provides each VM 114 with a series of tasks specific to the receiving VM 114 (herein referred to as a “local deployment plan”); par. 0067 the vA automation plans 128b are provided to define deployments of virtual appliances in one or more VMs 114 (or containers ));
generating, by a processing device and via an automation system, a payload within the container instance based on the … automation file; and outputting the payload to cause the set of tasks to be performed (par. 0056 Tasks are executed by the VMs 114 to install, configure, and/or start one or more application components. For example, a task may be a script that, when executed by a VM 114, causes the VM 114 to retrieve and install particular software packages from a central package repository 134).
Dobrev does not expressly describe: obtaining a domain-specific automation file.
However, Minna teaches: obtaining a domain-specific automation file (Abstract - using Domain Specific Language (DSL) files (e.g. with JSON or YAML syntax); pg. 757, left column, lines 9-11, Step 1. During the first step, the practitioner defines DSL files describing the experiment’s configuration).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed inventio to combine the technique of using Domain Specific Language (DSL) files that define a configuration of an automation process of an experiment of Minna with the system and method of Dobrev resulting in a system and method which provides for obtaining a Domain Specific Language files, generating an executable script/payload, and to automatically perform tasks to deploy a virtual appliance as in Minna. One of ordinary skill in the art would have been motivated to make this combination for the purpose of allowing to create, share, customize, automatically deploy, and reproduce different scenarios in a user-friendly manner (Abstract).
As per claim 2, Dobrev further teaches: wherein the container instance comprises a build phase of the container instance or a run phase of the container instance (par. 0067 In the illustrated example of FIG. 2, the vA automation plans 128b are provided to define deployments of virtual appliances in one or more VMs 114 (or containers 114a of FIG. 1) [run phase]; par. 0108] FIG. 14 shows an example listing of automation plan configuration files 1402 that include example build resolution configuration files 1404 for use during a quality assurance phase to test a corresponding automation plan 128 (FIGS. 1 and 2) for component interoperability issues that could arise during a deployment. The build resolution configuration files 1404 (e.g., “build-resolution.json” and “build-resolution.json.org”) indicate the most recent build numbers or build versions of the product components (e.g., the virtual environment infrastructure 208, the network virtualizer 210, the virtual storage area network 212, the operations manager 228, the automation manager 230, the site recovery manager 232 of FIG. 2) that are used by an automation plan 128 for deployments [build phase]).
As per claim 3, Dobrev further teaches: wherein generating the payload based on the … automation file comprises generating an executable, and wherein outputting the payload comprises outputting the executable (par. 0056 For example, a task may be a script that, when executed by a VM 114, causes the VM 114 to retrieve and install particular software packages from a central package repository. It is noted, a task may be a script, which is executable). Further, Minna teaches: using a domain-specific automation file (Abstract - using Domain Specific Language (DSL) files (e.g. with JSON or YAML syntax)).
As per claim 4, Dobrev further teaches: wherein generating the payload based on the … automation file comprises generating a script that is to be executed by an executable, and wherein outputting the payload comprises outputting the script (par. 0056 For example, a task may be a script that, when executed by a VM 114, causes the VM 114 to retrieve and install particular software packages from a central package repository). Further, Minna teaches: using a domain-specific automation file (Abstract - using Domain Specific Language (DSL) files (e.g. with JSON or YAML syntax)).
As per claim 6, Dobrev further teaches: wherein outputting the payload comprises outputting the payload to a second container instance, and wherein the second container instance performs the set of tasks based on the payload (par. 0055 an automation plan 128 is separated and distributed as local automation plans having a series of tasks to be executed by the VMs 114 [or containers]).
As per claim 7, Dobrev further teaches: wherein the container instance is associated with a first context (par. 0038 a process executing within a container [first context] is isolated from other processes executing on the host operating system) and the host OS is associated with a second context that is different from the first context (par. 0038 a host operating system is installed on the server hardware [second context]), and wherein generating the payload based on the …. automation file comprises translating the second context to the first context within the container instance (par. 0056 The deployment director 124 provides each VM 114 with a series of tasks specific to the receiving VM 114 (herein referred to as a “local deployment plan”)).
As per clam 8, Minna further teaches: responsive to outputting the payload, purging resources associated with the container instance (pg. 759, left column, lines 16-18 Finally, the tool is also in charge of cleaning up the experiment environment, thus removing all VMs, containers, and applications.).
As per claim 9, Dobrev further teaches: wherein the container engine includes a set of software dependencies for implementing the automation system, and wherein generating the payload is further based on the set of software dependencies (par. 0053 Based on the deployment to be defined, the example customer-customizable deployment blueprints 126 may define one or more dependencies between components (e.g., between two or more components) of the deployment to indicate an installation order of the components during deployment. For example, since a load balancer usually cannot be configured until a web application is up and running).
As per claim 10, Minna further teaches: wherein the container engine invokes the automation system during a build phase or a run phase associated with the container instance, and wherein generating the payload is further based on invoking the automation system during the build phase or the run phase (pg. 757, left column, lines 1-4 Testbed Tool [automation system]. This tool parses the DSL (configuration) files and automatically deploys the corresponding scenario. At the end of the experiment, it will also clean up the environment; pg. 757, left column, lines 13-14, During the second step, the testbed tool automatically deploys [during run phase] the previously defined configuration; par. par. 0108] FIG. 14 shows an example listing of automation plan configuration files 1402 that include example build resolution configuration files 1404 for use during a quality assurance phase to test a corresponding automation plan 128 (FIGS. 1 and 2) for component interoperability issues that could arise during a deployment. The build resolution configuration files 1404 (e.g., “build-resolution.json” and “build-resolution.json.org”) indicate the most recent build numbers or build versions of the product components (e.g., the virtual environment infrastructure 208, the network virtualizer 210, the virtual storage area network 212, the operations manager 228, the automation manager 230, the site recovery manager 232 of FIG. 2) that are used by an automation plan 128 for deployments [build phase]).
As per claim 11, Minna further teaches: instantiating, via the container engine, the container instance based on a container image (pg. 756, right column, lines 12-14 container images are created, shared, and customized as templates to instantiate containers in different computing environments; pg. 758, right column, Table 1, Docker Containers).
As per claim 12, Dobrev further teaches: wherein outputting the payload comprises transmitting the payload to a set of computing devices, and wherein each of the set of computing devices performs the set of tasks based on the payload (par. 0055 an automation plan 128 is separated and distributed as local automation plans having a series of tasks to be executed by the VMs 114).
As per claim 13, Dobrev further teaches: wherein the process comprises installing an application (par. 0056 to deploy a SDDC and/or a virtual appliance using the automation plan(s) 128,).
As per claim 14, it is a system having similar limitations as claim 1. Thus, claim 14 is rejected for the same rationale as applied to claim 1. Dobrev further teaches: a memory; and a processing device operatively coupled to the memory (Fig. 13, Processor 1312 couple to Memory 1314, 1316).
As per claim 15, it is a system having similar limitations as claim 2. Thus, claim 15 is rejected for the same rationale as applied to claim 2.
As per claim 16, it is a system having similar limitations as claim 3. Thus, claim 16 is rejected for the same rationale as applied to claim 3.
As per claim 17, it is a system having similar limitations as claim 4. Thus, claim 17 is rejected for the same rationale as applied to claim 4.
As per claim 18, it is a non-transitory computer-readable medium having similar limitations as claim 1. Thus, claim 18 is rejected for the same rationale as applied to claim 1. Dobrev further teaches: a non-transitory computer-readable medium (par. 0106 computer readable storage medium).
As per claim 19, it is a non-transitory computer-readable medium having similar limitations as claim 2. Thus, claim 19 is rejected for the same rationale as applied to claim 2.
As per claim 20, it is a non-transitory computer-readable medium having similar limitations as claim 3. Thus, claim 20 is rejected for the same rationale as applied to claim 3.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Dobrev in view of Minna, and further in view of Pulla et al. (U.S. Pub. No. 20110276793 A1).
As per claim 5, Dobrev and Minna do not expressly teach: wherein outputting the payload comprises outputting the payload to the host OS, and wherein the host OS performs the set of tasks based on the payload.
However, Pulla teaches: wherein outputting the payload comprises outputting the payload to the host OS, and wherein the host OS performs the set of tasks based on the payload (par. 032 storing one or more second files (hereafter collectively referred to as a "payload") into the runtime environment of operating system 120. The one or more second files may be executable files; par. 0032 thread 126 may … write the payload, or a portion thereof, to a file system provided by operating system 120).
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 technique of writing/outputting a payload into the runtime environment of the operating system of Pulla with the system and method of Dobrev and Minna resulting in a system which provides for writing a payload into the runtime of the host operating system for executing tasks based pm the payload. One of ordinary skill in the art would have been motivated to make this combination for the purpose of enabling an executable file to be introduced (or "injected") into the runtime environment of the operating system without the aid of a file system driver (par. 0006).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 20200356383 A1 teaches configuration management task derivation.
U.S. Pub. No. 20030070119 A1 teaches method and system for testing a software product.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Willy W. Huaracha whose telephone number is (571)270-5510. The examiner can normally be reached on M-F 8:30-5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached on (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WH/
Examiner, Art Unit 2195
/BRADLEY A TEETS/ Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights