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 responsive to the following communications: amendment filed on April 28, 2026
This application has been examined. Claims 1-20 are pending.
Claim Objection - 35 USC § 112
§ 112(b) Definiteness - Noted Issues (Not Formally Rejected):
(i) "state declaration... in a standard format" (Claims 1, 8, 15): The phrase "standard format" is potentially indefinite in scope. The specification discloses ConfigMap as an example (¶ [0020]), but the claims use "standard format" without limitation to any particular format. Applicant is encouraged to clarify the metes and bounds of "standard format." A § 112(b) rejection may be made in a subsequent action if this issue is not addressed.
(ii) "set of scripts" (Claims 1, 8, 15): The term "scripts" is used without limitation as to type. The specification discloses Ansible modules as one example (¶ [0025]). The term appears adequately supported as a broad functional term. No rejection is made at this time.
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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-11, 13-18, 20 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Bregman et al. (“Bregman”) (US No. 11,822,933) in view of Sedukhin et al. (“Sedukhin”) (US No. 8,099,720).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Bregman and Sedukhin references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 1, Bregman discloses a method comprising: receiving a state declaration associated with a target computing system, (as shown in Fig. 2, which is reproduced below for ease of reference and convenience, Bregman discloses a method for derivation and development of executable configuration tasks. Bregman further discloses obtaining configuration parameters of a first computer system (reference machine) that collectively define the desired configuration state of the target computer system. The configuration parameters represent the desired state of the system (package, service, user, group, configuration file, network interface settings, SELinux settings, security settings, firewall settings. See col. 6:37-56). Bregman's configuration manager receives this state input via a user interface and/or configuration file associated with the configuration manager (e.g., Ansible inventory/playbook file). Col. 6:37-8:59; FIG. 2 (configuration manager 130, repository 160, configuration parameters 162); FIG. 5 (steps 502–506). FIG. 6 (method 600); FIG. 7 (method 700));
PNG
media_image1.png
812
662
media_image1.png
Greyscale
translating, by a processing device, the state declaration into configuration operations associated with the target computing system (in Bregman expressly discloses translating/deriving, by a processor executing a configuration manager on a control machine, a set of configuration parameters (desired state) into one or more executable tasks (configuration operations) that convert the system's configuration to match the desired state. The processor compares the first set of configuration parameters (desired state) to the second set (current state) and derives executable tasks corresponding to each difference which is directly constituting "translating the state declaration into configuration operations." Col. 3:21-4:54 ("deriving, by a processor executing a configuration manager on a control machine, one or more executable tasks that convert the first set of configuration parameters to the second set"); Claim 1 ("deriving, by a processor executing a configuration manager..."); FIG. 3 (task derivation module 230, processing device); FIG. 5 (step 510: deriving executable tasks); FIG. 6 (step 608)); generating a set of scripts to perform the configuration operations on the target computing system (in Bregman expressly discloses deriving one or more executable tasks (scripts/Ansible playbooks/commands) that perform the identified configuration operations on the target computer system. Bregman discloses that the configuration manager (e.g., Ansible) derives executable tasks in the form of scripts, commands, and/or playbooks that implement the required configuration changes when executed on the target system. Bregman explicitly discloses that executable tasks include Ansible playbook tasks. Col. 3:21-4:54 (deriving one or more executable tasks (i.e.,scripts/commands)); Col. 7:40-54 ("the configuration manager may provide the executable task(s) to another computer system"); Col. 3:21-4:54 (configuration manager e.g., Ansible™, Puppet™, Chef™ generates executable tasks); FIG. 2 (tasks 164 in repository 160); FIG. 3 (derivation of executable tasks 320); Claim 1 ("deriving... one or more executable tasks")); and deploying the set of scripts to the target computing system to configure the target computing system according to the state declaration (in Bregman expressly discloses sending/deploying the derived executable tasks (scripts) to the target computer system for execution to configure the target computer system to match the desired configuration state. Bregman discloses that the configuration manager connects to the target computer system, copies a file with the executable tasks/commands to the target computer system, and executes the tasks on the target system which is directly constituting deploying the set of scripts to configure the target computing system. Claim 1 ("sending, from the configuration manager of the control machine, one or more files to a computer system to provide the one or more executable tasks for execution by the computer system to synchronize configuration parameters of the computer system"); Col. 22:64-23:26 (gaining access to target system, copying files, executing tasks); FIG. 5 (step 518): sending executable tasks to target system); FIG. 7 (steps 718–722)). But Bregman does not expressly recite that the state input is in a "standard format" in the sense of a cloud-native standardized declaration format such as a ConfigMap. In the same field of endeavor, Sedukhin discloses a method for translating declarative models to perform operations on target computing environments wherein that the state input is in a standard format (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Sedukhin expressly discloses receiving a declarative model in a standard format as the input. Specifically, Sedukhin discloses receiving a "declarative model" (i.e. a standardized, format-specific description of a desired application/system state that defines the topology, configuration, and operational state of a target computing environment in a standard declarative format). Sedukhin's declarative model is analogous to the claimed "state declaration in a standard format." Col. 2:23-57 ("declarative models of applications are processed and realized onto a target environment"); Col. 4:1-46 (receiving declarative model as standard input to the system); FIG. 1 (act 102 for receiving declarative model 106); Abstract).
PNG
media_image2.png
482
597
media_image2.png
Greyscale
A person of ordinary skill in the art, seeking to improve automation and reduce manual effort in configuring complex computing systems (as both references are directed to the same field of configuration management and deployment in distributed or enterprise environments), would have found it obvious to incorporate the declarative model translation techniques of Sedukhin into the task derivation and deployment framework of Bregman. This combination would allow a system to accept a clean, high-level state declaration in a standard format, translate it efficiently into operations, generate the necessary executable scripts/tasks, and deploy them which is yielding predictable, idempotent, and scalable configuration of target systems while minimizing errors associated with manual or purely difference-based approaches.
In regard to claims 2, 9, 16, Bregman discloses wherein translating the state declaration to the configuration operations for the target computing system comprises: determining configuration rules of the target computing system associated with each definition provided by the state declaration (in Bregman expressly discloses deriving executable tasks using a set of rules and libraries associated with the target system's entity types (package, service, user, group, configuration file, network interface, SELinux, security, firewall). Col. 3:21-4:54 ("deriving the one or more executable tasks comprises: deriving the one or more executable tasks in view of a set of rules and libraries" such in Claim 6); FIG. 3); and translating the state declaration based on the configuration rules for each definition of the state declaration ((in Bregman expressly discloses deriving executable tasks using a set of rules and libraries associated with the target system's entity types (package, service, user, group, configuration file, network interface, SELinux, security, firewall). Col. 3:21-4:54 ("deriving the one or more executable tasks comprises: deriving the one or more executable tasks in view of a set of rules and libraries" such in Claim 6); col. 13:6-38; FIG. 3).
In regard to claims 3, 10, 17, Bregman discloses wherein the standard format of the state declaration comprises a format associated with a cloud native architecture (in Bregman, configuration manager (Ansible) interfaces with both cloud-native and non-cloud-native computing systems and accepts configuration state inputs in various formats. Bregman discloses cloud-native environments and virtual machines as target systems, implicitly encompassing cloud-native format inputs. Col. 3:21-4:54 (computer system 100 includes virtual machines, containers, cloud-based systems); FIG. 1).
In regard to claim 4, 11, 18, Bregman discloses use of Ansible and similar configuration managers that interface with Kubernetes environments and accept standardized configuration inputs. (Col. 3:21-4:54). Sedukhim discloses declarative model formats corresponding to cloud-native application state specifications. (Col. 2:23-57). Even though Bregman or Sedukhim does not expressly disclose the standard format comprises a ConfigMap state declaration, however the ConfigMap is a well-known, standard Kubernetes configuration object. Implementing the standard format as a Kubernetes ConfigMap represents a routine design choice among a finite number of known standard cloud-native formats. See MPEP § 2144.05.
In regard to claims 6, 13, 20, Bregman discloses wherein the target computing system comprises a legacy computing system or a non-cloud native computing system (in Bregman expressly discloses that the configuration manager operates on legacy, non-cloud-native, and cloud-native target systems alike, including physical machines and non-virtualized computing systems. Col. 5:1-6:36 (computer system 100 includes physical machines, virtual machines, and non-cloud systems); FIG. 1).
In regard to claims 7, 14, Bregman discloses wherein deploying the set of scripts to the target computing system comprises: distributing the set of scripts to an execution node of an automation system associated with the target computing system (in Bregman expressly discloses deploying executable tasks via a configuration manager architecture that includes a control machine (control node) and target computer systems (execution nodes), wherein the configuration manager connects to the target computer system and copies/executes the tasks on the target machine over a network. This is precisely the automation mesh/execution node architecture claimed. Col. 22:64-23:26 ("sending, from the configuration manager of the control machine, one or more files to a computer system... gaining access to the computer system; copying a file with the one or more executable tasks to the computer system for execution" such as in Claims 1–4); and causing, by the execution node, the set of scripts to be executed by the target computing system (in Bregman, Col. 3:21-4:54 ("configuration manager runs in 'server mode' where master server provides and executes changes for client machines"); FIG. 1 (network 150, computer systems 100A–100N); FIG. 7 (steps 718–724)).
Independent claims 8 (system) and 15 (non-transitory computer-readable medium) recite the same operative limitations as method claim 1 in system and medium form respectively. Bregman discloses a computer system (FIG. 1, element 100) comprising a processor (CPU 141) and memory (ROM/NVRAM 143) storing firmware instructions (firmware 162) that perform the identical operations. The method/system/medium distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114.
Therefore, claims 8 and 15 are rejected on the same basis and mapping as claim 1 above.
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Allowable Subject Matter
Claims 5, 12, 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is an Examiner's statement of reasons for the indication of allowable subject matter: Claims 5, 12, 19 are allowable over the prior art of record because the prior arts, cited in its entirety, or in combination, do not teach
wherein translating the state declaration to the set of configuration operations for the target computing system comprises: providing the state declaration to a machine learning model trained to infer the set of configuration operations based on statements provided by the state declaration.
Response to Amendment
Applicant’s arguments and amendment, see on pages 2-12, filed on April 28, 2026, with respect to the rejections of claims 1-20 under 35USC102(2) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Bregman and Sedukhim.
Conclusion
Claims 1-4, 6-11, 13-18, 20 are rejected. Claims 5, 12, 19 are objected.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Colcord et al. (US No. 11,838,221) disclose a system receiving a "first definition" in a "first format" and generating a "second definition" mapping declarations to a format supported by a selected virtualized environment, then deploying the virtualized instance using the second set of declarations.
Sedukhin et al. (US No. 8,443,347) disclose the translating declarative models into execution plans with additional focus on updating existing application deployments based on differences between old and new declarative models.
Bregman et al. (US Pub No. 2020/0356383) disclose a configuration data management system may enable ConfigMaps to be added to an application pod of a virtual software environment without restarting the application pod, a ConfigMap including a data object containing configuration data. The configuration data management process may monitor for creation of a first ConfigMap in the virtual software environment, append a name of the first ConfigMap to a data element name from the first ConfigMap to produce an appended data element.
Bregman et al. (US No. 10,725,793) disclose the configuration management task derivation by a processing device with additional focus on obtaining configuration parameters at different time values.
Chaware et al. (US No. 11,140,032) disclose the building idempotent configuration management modules for cloud infrastructure services, including receiving a configuration management task definition, deriving a meta-model of a requested resource type, computing a desired state, and generating configuration management modules.
Bhosle et al. (US No. 11,424,982) disclose the remediation of a system to a new desired state using a configuration dependency graph, generating configuration scripts/operations from a desired state specification, and deploying them to target systems.
Bregman et al. (US No. 10,419,289) disclose an agentless computing system configuration management service with a standard network interface, receiving a specified configuration from a client, and applying configuration operations to a target system.
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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, Andrew Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
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 hop://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).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
.
Prosecution Insights