DETAILED ACTION
Claims 1-20 rejected under 35 USC § 103.
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 § 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 1, 7-8, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Birsan et al., U.S. PG-Publication No. 2023/0126168 A1 (hereinafter BIRSAN), in view of Pieczul et al., U.S. PG-Publication No. 2022/0191099 A1 (hereinafter PIECZUL).
Claim 1
BIRSAN discloses a system comprising: a processing device; and a memory device comprising instructions that are executable by the processing device for causing the processing device to. ¶ 0085: Computing device 12 includes “the memory 16 and the processor device 14 coupled to the memory 16.” Its deployment applications deploy applications resources onto clusters, “each cluster 24 comprising a plurality of nodes 26.” ¶ 0089: Program modules, including introspection service 20, are stored in volatile memory 184. ¶ 0090: The program code comprises “software instructions for implementing the functionality of the examples described herein when executed on the processor 14.”
BIRSAN discloses record one or more actions performed by an operator that is deploying a containerized application to one or more first nodes of a first cluster. ¶ 0037: Deployment applications are “configured to deploy containerized applications onto one or more of the clusters 24 via interactions with the corresponding cluster controllers 28.” ¶ 0038: Examples include Argo, Advanced Cluster Management, and FLUX deployment applications. ¶ 0055: Deployment application 42-1 “has deployed the containerized application 32-1 to the cluster 24-1” as deployment, service and route resources. ¶ 0052: The introspection service “may store collected information in a location, such as application resource deployment information 62, for subsequent processing and consolidation.” ¶ 0056: The service obtains the deployment, service, route and pod resources from the cluster controller. ¶ 0057, Table 5: The deployment resource records manager: argocd-application-controller, operation: Update, and a timestamp, together with managed container-port and protocol fields.
BIRSAN discloses determine that the containerized application is in a desired state. ¶ 0050: The introspection service determines “whether the containerized application 32 has been successfully deployed to each cluster 24 and namespace 46.” ¶ 0057, Table 5: The deployment resource includes replicas: 1, readyReplicas: 1, and availableReplicas: 1, together with deployment condition information. ¶ 0058: The introspection service determines resource status from information returned by the cluster controller.
BIRSAN does not expressly disclose in response to determining that the containerized application is in the desired state, generate one or more resources usable to deploy the containerized application based on the recorded one or more actions; and use the one or more resources to automatically deploy the containerized application to one or more second nodes of a second cluster.
PIECZUL discloses in response to determining that the containerized application is in the desired state, generate one or more resources usable to deploy the containerized application based on the recorded one or more actions. ¶ 0067: Component monitor module 625 “records any changes to component arrangement,” including integration of a component into a node, together with addresses and timestamps. It stores associated component metadata and corelates those records with observed connections for policy creation. ¶ 0071: “If the component passes the functional test and no violation of the coarse-grained policy is detected, the test result may indicate that the component can be successfully deployed to production.” In that case, policy creator 630 accesses traffic data 640, “retrieves the pertinent processed information,” and “creates a network policy 655.” The retrieved information included component metadata, addresses, ports and timestamps. ¶ 0072: “The component, fine grained policy and other deployment (such as deployment manifests) are packaged together to create a deployment package for the component.”
PIECZUL discloses use the one or more resources to automatically deploy the containerized application to one or more second nodes of a second cluster. ¶ 0043: The test system generates the deployment package, and “[a] deployment orchestrator system 116 in the production environment 122 receives the deployment package 114.” ¶ 0073: “In certain examples, a deployment orchestrator system in the production orchestrator system in the production environment 122 receives the deployment package and sues the deployment package to deploy the component(s) of the application and their associated network policies to different nodes in a cluster of nodes within a containerized environment of the production environment 122. ¶ 0074: The policy and component may be packaged in a Helm chart that “will automatically control the deployment of multiple objects together.”
The combined system would correlate the source deployment controller’s recorded updates and affected resource configurations with component identities and observed connections. After successful validation, it would generate the network policies and deployment package from that correlated information and use the package to deploy the application to the second cluster.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the deployment information collection of BIRSAN to incorporate the successful test triggered network policy generation and packaged production deployment taught by PIECZUL. One of ordinary skill in the art would be motivated to integrate that policy generation and packaged deployment into BIRSAN, with a reasonable expectation of success, in order to reduce manual policy maintenance effort and avoid configuration errors caused by changing component addresses and versions, because deriving policies from recorded component metadata and deploying them with their corresponding components reduces reliance on manually maintained network mappings (PIECZUL ¶¶ 0034-0035, 0061).
Claim 7
PIECZUL discloses automatically deploy the containerized application to the one or more second nodes without the operator. ¶ 0072: Packages the application component, its network policy, and deployment artifacts together, including “deployment manifests.” ¶ 0073: The production deployment orchestrator receives the package and uses it to deploy the application components and policies to “different nodes in a cluster of nodes.” ¶ 0074: A Helm chart can package the component and policy and “automatically control the deployment of multiple objects together.”
Claims 8 and 14
Claims 8 and 14 are rejected utilizing the rationale for claims 1 and 7; the claims are directed to a method performed by the system.
Claim 15
Claim 15 is rejected utilizing the aforementioned rationale for claim 1; the claim is directed to a medium storing instructions executed by the system.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over BIRSAN, in view of PIECZUL, further in view of Streete et al., U.S. Patent No. 10,536,518 B1 (hereinafter STREETE).
Claim 2
BIRSAN discloses a plurality of resources that the operator has acted upon in deploying the containerized application to the one or more first nodes. ¶ 0055: Identifies the deployment application and the deployment, service, and route resources it deployed in the first cluster.
PIECZUL discloses maintain a cache identifying a plurality of resources. ¶ 0067: Stores component arrangement information, addresses, timestamps, and identifying metadata in a “cache or local data store.”
BIRSAN-PIECZUL does not expressly disclose identify a final state of each resource of the plurality of resources in the desired state of the containerized application; and generate the one or more resources based on the final state of each resource of the plurality of resources.
STREETE discloses identify a final state of each resource of the plurality of resources in the desired state of the containerized application. Col. 11, ll. 31-49: Collection module 318 collects configuration information for each discovered resource, including “all configuration settings” necessary for its operation in the application. Col. 11, ll.17-30: Discovery module 316 can lock configuration changes so discovery is “not spoiled by changes” after configuration information has been gathered.
STREETE discloses generate the one or more resources based on the final state of each resource of the plurality of resources. Col. 12, ll.14-22: Generation module 320 generates the application deployment plan from the configuration information collected by module 318. Col. 14, ll.56-65: Step 418 generates an application manifest containing resource information sufficient to replicate another set of resources supporting the application.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the deployment resource generation of BIRSAN-PIECZUL to incorporate the per resource configuration capture and configuration based deployment plan generation taught by STREETE, capturing the identified resources’ configurations when the application reaches the desired state. One of ordinary skill in the art would be motivated to integrate those features into BIRSAN-PIECZUL, with a reasonable expectation of success, in order to replace incomplete manual configuration tracking with captured operative configurations and thereby reduce configuration drift and the manual investigation and repair required after an incomplete or nonoperational redeployment (STREETE, col. 3, ll.19-49).
Claim 9
Claim 9 is rejected utilizing the rationale for claim 2; the claim is directed to a method performed by the system.
Claim 16
Claim 16 is rejected utilizing the aforementioned rationale for claim 2; the claim is directed to a medium storing instructions executed by the system.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over BIRSAN, in view of PIECZUL, further in view of Chawda et al., U.S. Patent No. 10,572,294 B1 (hereinafter CHAWDA).
Claim 3
BIRSAN discloses the one or more actions performed by the operator to deploy the containerized application. ¶ 0037: Deployment applications deploy containerized applications onto clusters through interactions with cluster controllers, including through an “application programming interface.”
BIRSAN does not expressly disclose detect the one or more actions via a proxy configured to intercept the one or more actions performed by the operator to deploy the containerized application.
CHAWDA discloses detect the one or more actions via a proxy configured to intercept the one or more actions. Col.2, ll. 33-41: An interceptor monitors application requests and may act “inline” in their path, receiving requests before passing them to the underlying servicing layer. Col. 5, ll. 18-25: The interceptor detects a resource request, returns the requested information, and records the dependency while allowing the application to “run normally.”
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the deployment action recording mechanism of BIRSAN-PIECZUL to incorporate the inline request interception taught by CHAWDA, placing the interceptor in the path of the deployment operator’s requests to the cluster controller. One of ordinary skill in the art would be motivated to integrate that interception mechanism into BIRSAN-PIECZUL, with a reasonable expectation of success, in order to collect deployment action information without disrupting the operator’s deployment execution, by observing and forwarding requests as CHAWDA teaches for application requests (CHAWDA col.2 ll. 33-41; col.5 ll.18-25).
Claim 10
Claim 10 is rejected utilizing the rationale for claim 3; the claim is directed to a method performed by the system.
Claim 17
Claim 17 is rejected utilizing the aforementioned rationale for claim 3; the claim is directed to a medium storing instructions executed by the system.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over BIRSAN, in view of PIECZUL, further in view of Tripathi et al., U.S. PG-Publication No. 2023/0048653 A1 (hereinafter TRIPATHI).
Claim 4
BIRSAN discloses the one or more actions performed by the operator in deploying the containerized application. Deployment applications deploy containerized applications onto clusters through interactions with cluster controllers, including through an “application programming interface.”
BIRSAN does not expressly disclose generating a configurator that is configured to reproduce the one or more actions.
TRIPATHI discloses generating a configurator that is configured to reproduce the one or more actions. ¶ 0058: After successful deployment, the orchestrator parses the deployed application deployment code to identify attributes including “actions, entities, values, and orders of operation.” ¶ 0087: The generated semantic tree represents deployment actions as nodes and their “order of operation” as edges— for example, installing a VM, then an agent, then a tool. ¶ 0096: The orchestrator uses that semantic tree and target specific mappings to compose application deployment code for the second computing environment. ¶ 0097: The composed deployment code defines a package that the second environment installs and deploys.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the deployment resource generation of BIRSAN-PIECZUL, to incorporate the deployment workflow representation and executable deployment code composition taught by TRIPATI, representing the recorded operator actions as workflow operations from which the configurator is generated. One of ordinary skill in the art would be motivated to integrate those features into BIRSAN-PIECZUL, with a reasonable expectation of success, in order to reuse the established deployment workflow instead of manually rewriting deployment code for the destination environment, thereby reducing development cost and accelerating deployment, benefits expressly identified by TRIPATHI (¶¶ 0128, 0133).
Claim 11
Claim 11 is rejected utilizing the rationale for claim 4; the claim is directed to a method performed by the system.
Claim 18
Claim 18 is rejected utilizing the aforementioned rationale for claim 4; the claim is directed to a medium storing instructions executed by the system.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over BIRSAN, in view of PIECZUL, further in view of TRIPATHI, further in view of Webster et al., U.S. PG-Publication No. 2020/0133711 A1 (hereinafter WEBSTER).
Claim 5
WEBSTER discloses automatically deploy the containerized application to the one or more second nodes by: reordering, by the configurator, the one or more actions; or combining, by the configurator, the one or more actions into a single action. ¶ 0120: The “configurator engine 620” executes workflow model configuration rules, including segment model configuration rules 646. ¶ 0193: Rules 646 permit segment model actions and action sequences to be “modified, adjusted, and/or reordered.” Those rules define models for integrating, building, testing, and deploying applications. ¶ 0010: Workflow optimizations expressly include “a reordering of tasks” specified by the workflow process. ¶ 0122: The orchestrator executes the configured workflow, determining the actions to execute and coordinating their execution.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the generated deployment configurator of BIRSAN-PIECZUL-TRIPATHI to incorporate the context sensitive workflow action reordering into BIRSAN-PIECZUL-TRIPATHI, with a reasonable expectation of success, in order to schedule dependency permitted deployment actions according to available computing capacity and thereby reduce resource content and avoid execution delays caused by a fixed schedule unsuited to that capacity (WEBSTER ¶¶ 0030, 0044).
Claim 12
Claim 12 is rejected utilizing the rationale for claim 5; the claim is directed to a method performed by the system.
Claim 19
Claim 19 is rejected utilizing the aforementioned rationale for claim 5; the claim is directed to a medium storing instructions executed by the system.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over BIRSAN, in view of PIECZUL, further in view of TRIPATHI, further in view of Zhang et al., U.S. PG-Publication No. 2024/0211148 A1 (hereinafter ZHANG).
Claim 6
ZHANG discloses identifying, by the configurator, a failed action performed by the configurator in automatically deploying the containerized application. ¶ 0072: The deployment process performs reactive error handling during deployment, including handling “insufficient capacity errors” affecting the primary cloud instance type.
ZHANG discloses identifying, by the configurator, an alternative action that is equivalent to the failed action. ¶ 0072: The process can “fallback to alternative resource types,” including an alternative cloud instance type when capacity for the primary type is unavailable.
ZHANG discloses automatically executing, by the configurator, the alternative action to deploy the containerized application to the one or more second nodes. ¶ 0072: The cloud deployment process performs the reactive fallback during deployment. ¶ 0067: Deployment includes communicating with the cloud provider to “organize, provision, allocate, and couple” components according to the selected deployment intent.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the generated deployment configurator of BIRSAN-PIECZUL-TRIPATHI to incorporate the receive capacity error handling and alternative instance fallback taught by ZHANG. One of ordinary skill in the art would be motivated to integrate that error handling into BIRSAN-PIECZUL-TRIPATHI, with a reasonable expectation of success, in order to substitute an available instance capable of satisfying the same deployment requirements and thereby reduce deployment failures caused by unavailable capacity for the originally selected instance type (ZHANG, ¶¶ 0004, 0072).
Claim 13
Claim 13 is rejected utilizing the rationale for claim 6; the claim is directed to a method performed by the system.
Claim 20
Claim 20 is rejected utilizing the rationale for claim 6; the claim is directed to a medium storing instructions executed by the system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Balcha, et al., U.S. PG-Publication No. 2021/0149769 A1: BALCHA discovers resources belonging to an operator-managed Kubernetes application, creates a workload resource definition from those resources, and back up application templates, configuration metadata, and data for restoration to another cluster (BALCHA ¶¶ 0047-0050, 0073).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 9-5:30 CT.
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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 September 11, 2026
Prosecution Insights