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
Claim Interpretation - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claim limitations 6-15 has/have been interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because it uses/they use a generic placeholder data plane, control plane, coupled with functional language without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier. Since the claim limitation(s) invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claim 13 has/have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification, Fig. 6 [0091] shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation.
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
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.
Claim/s 1, 2, 6-11, 13-16, 19, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Truyen (NPL: 2023 “Vendor-Agnostic Reconfiguration of Kubernetes Clusters in Cloud Federations”) in view of Kovachka-Dimitrova (Pub. No. US 2006/0037030).
Claims 1, 6, 16, Truyen teaches “a computer-implemented method, comprising: receiving a request to run an application ([1. Introduction] It aims to support the following application deployment scenarios [1]: • Cloud bursting facilitates an application scenario where a portion of workloads is dynamically migrated from an on-premise private cloud to public cloud platforms to cope with peaks and spikes in workload while reducing capital expenditures; • High availability and geodistribution requires replicating an application across different availability zones and different regions, respectively. The latter is necessary to offer a the same quality of service level to end-users across the world; • Security policy and regulation compliance requires that sensitive workloads and data are deployed on-premise, whereas insensitive traffic and workloads can be handled by elastic public clouds…. In this paper, we present a unified and vendor-agnostic cluster reconfiguration approach, so that cluster administrators and application managers can avoid vendor lock-in limitations when reconfiguring clusters and can also change a broader set of configuration settings than offered in the proprietary customization interfaces. In particular, we make the following contributions:) in response to the request: determining a current state of a container instance within which the application may be run, wherein the container instance is operating in a data plane of a cloud provider network ([Fig. 1] worker node as data plane); determining a desired state of the container instance that is needed to run the application ([6.1 Design of the Control Loop] The user specifies the desired features that each member cluster should support through a declarative API; • The controller monitors actual supported features and compares them with the desired features for each member cluster; • If a desired feature is not supported in the cluster, the controller performs the vendoragnostic feature reconfiguration tactics to activate the missing feature.); determining, with a container set manager that is operating in a control plane of the cloud network provider, a plurality of operations to be performed at the container instance to transition the container instance from the current state to the desired state and run the application on the container instance, wherein the control plane runs on a first computing hardware that is at least one of physically or logically separated from a second computing hardware upon which the data plane and the container instance operates ([Fig. 3] Control Plane comprising API server and scheduler [6.1. Design of the Control Loop] Kubernetes uses a declarative management approach to manage cluster resources. The user specifies the desired state of cluster resources through the API server. A control loop monitors the actual state of the resources and compares it with the user-specified desired state. If there is any difference between them, the control loop takes actions to bring the actual state to the desired. The controller in our approach adopts a similar idea to implement the control loop (Figure 7) for feature compatibility management in a Kubefed cluster federation:); pushing, from the control plane and to an agent operating on the data plane, a first operation of the plurality of operations that is to be performed by the agent; receiving, from the agent a first acknowledgement that the first operation has been completed; in response to receiving the first acknowledgement, pushing, from the control plane and to the agent, a second operation of the plurality of operations that is to be performed by the agent; receiving, from the agent a second acknowledgement that the second operation has been completed; determining, subsequent to receiving the second acknowledgement, that the container instance is in the desired state ([6.1. Design of the Control Loop] Kubernetes uses a declarative management approach to manage cluster resources. The user specifies the desired state of cluster resources through the API server. A control loop monitors the actual state of the resources and compares it with the user-specified desired state. If there is any difference between them, the control loop takes actions to bring the actual state to the desired. The controller in our approach adopts a similar idea to implement the control loop (Figure 7) for feature compatibility management in a Kubefed cluster federation: • The user specifies the desired features that each member cluster should support through a declarative API; • The controller monitors actual supported features and compares them with the desired features for each member cluster; • If a desired feature is not supported in the cluster, the controller performs the vendor agnostic feature reconfiguration tactics to activate the missing feature. Figure 7. Feature compatibility controller’s control loop. The control loop is event-driven, and it blocks after an iteration finishes. When desired features change, the control loop continues with the next iteration to maintain feature compatibility. Regularly, the controller restarts the control loop for every installed feature to see if the feature is still working. [6.2.2. Controller Architecture] Reconfigure is the method where we monitor and apply vendor-agnostic reconfiguration tactics for one or more desired features. It takes the desired features and credentials to communicate with a member cluster. For all desired features that the reconfigurator is able to configure, the reconfigurator will check if any of the desired features are not yet enabled in the cluster. If so, it will apply one of the vendor-agnostic tactic for these missing features, and it returns true. [2.1.2. Kubernetes Architecture] Kubelet is the essential component on the worker node. It watches the pod resource objects on the API server to detect changes about Pods on its node. It interacts with the container runtime, the network plugin and other add-ons to ensure that the container running state is consistent with the specification of the pod manifest. For example, if the Kubelet sees that the pods to be created have specific resource limits, it will first interact with the container runtime to create a pod-level network namespace with a particular cgroup parent setting.)”.
However, Truyen may not explicitly teach the remaining limitations.
Kovachka-Dimitrova teaches “determining…that that application is running on the container instance; and providing a confirmation that the application is running ([0078] The deploy service 1004, upon receiving the return notification 1014 from the container via the container API 1008, prepares for deploying 1016 of the application. For deployment preparation 1016, the deploy service may use the following method: <public void prepareDeploy(String applicationName, Configuration appConfig) throws DeploymentException, WarningException>. If the deployment preparation 1016 is successful, the container 1008 communicates back with the deploy service 1004 with a response or notification 1018 indicating the success. In one embodiment, the notification 1018 may be communicated from various containers at various servers, via their corresponding container APIs, to the deploy service 1004 or to the deploy services at their corresponding servers. [0079] According to one embodiment, upon receiving the notification 1018, the successful deployment status relating to any or all of the deploy service operations is then committed 1020 to the container via container API 1008. The status may also be committed 1028 to a database 1030 for performing transactional commitment of the state of deployment in addition to the logical commitment 1020. The commitment 1028 regarding the application deployment is performed by the deploy service 1004 using, for example, the following method: <public void commitDeploy(String applicationName) throws WarningException>. In one embodiment, if a deployment exception is thrown or an error of some kind has occurred at anytime during the beginning 1012 of deployment and receiving of the notification 1018, the deployment may be stopped and/or rolled back to the previous step. In one embodiment, if the transaction is not committed, the rolling back of the transaction is performed using, for example, the following method: <public void rollbackDeploy(String applicationName) throws DeploymentException>. [0080] The deploy service 1004 then provides a result 1022 for a successful transaction or state of the application deployment to the client 1002.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kovachka-Dimitrova with the teachings of Truyen in order to provide a system that teaches confirmations. The motivation for applying Kovachka-Dimitrova teaching with Truyen teaching is to provide a system that allows for situational awareness. Truyen, Kovachka-Dimitrova are analogous art directed towards software deployment. Together Truyen, Kovachka-Dimitrova teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Kovachka-Dimitrova with the teachings of Kovachka-Dimitrova by known methods and gained expected results.
Claim 2, 7, 19 the combination teaches the claim, wherein Truyen teaches “the computer-implemented method of claim 1, further comprising: determining an order of operations for each operation of the plurality of operations; and wherein the first operation is a first operation in the order of operations ([6.1. Design of the Control Loop] The control loop is event-driven, and it blocks after an iteration finishes. When desired features change, the control loop continues with the next iteration to maintain feature compatibility. Regularly, the controller restarts the control loop for every installed feature to see if the feature is still working.)”.
Claim 8, 20, “the system of claim 7, wherein: the control plane pushes a second operation to the agent in response to receipt of an acknowledgement from the agent that a first operation has been completed; and the second operation follows the first operation in the order” is similar to claim 1 and therefore rejected with the same references and citations.
Claim 9, the combination teaches the claim, wherein Truyen teaches “the system of claim 6, wherein the control plane is further configured to at least: receive a request to run an application; and wherein the plurality of operations are further determined based at least in part on the current state of the container instance and the desired state of the container instance that is needed to run the application on the container instance ([6.1 Design of the Control Loop] The user specifies the desired features that each member cluster should support through a declarative API; • The controller monitors actual supported features and compares them with the desired features for each member cluster; • If a desired feature is not supported in the cluster, the controller performs the vendoragnostic feature reconfiguration tactics to activate the missing feature.)”.
Claim 10, “the system of claim 6, wherein the control plane, as part of pushing each operation to the agent, is further configured to at least: push a first operation of the plurality of operations to the agent; receive, an acknowledgement from the agent indicating that the first operation is complete; and in response to the acknowledgement, push a second operation of the plurality of operations to the agent” is similar to claim 1 and therefore rejected with the same references and citations.
Claim 11, the combination teaches the claim, wherein Truyen teaches “the system of claim 6, wherein the agent operating on the data plane is a thin agent that awaits operations from the control plane, upon receipt of an operation, performs the operation, upon completion of the operation sends an acknowledgement to the control plane indicating that the operation is complete, and upon sending the acknowledgement, returns to a wait state and awaits a next operation from the control plane ([6.1. Design of the Control Loop] Kubernetes uses a declarative management approach to manage cluster resources. The user specifies the desired state of cluster resources through the API server. A control loop monitors the actual state of the resources and compares it with the user-specified desired state. If there is any difference between them, the control loop takes actions to bring the actual state to the desired. The controller in our approach adopts a similar idea to implement the control loop (Figure 7) for feature compatibility management in a Kubefed cluster federation: • The user specifies the desired features that each member cluster should support through a declarative API; • The controller monitors actual supported features and compares them with the desired features for each member cluster; • If a desired feature is not supported in the cluster, the controller performs the vendor agnostic feature reconfiguration tactics to activate the missing feature. Figure 7. Feature compatibility controller’s control loop. The control loop is event-driven, and it blocks after an iteration finishes. When desired features change, the control loop continues with the next iteration to maintain feature compatibility. Regularly, the controller restarts the control loop for every installed feature to see if the feature is still working. [6.2.2. Controller Architecture] Reconfigure is the method where we monitor and apply vendor-agnostic reconfiguration tactics for one or more desired features. It takes the desired features and credentials to communicate with a member cluster. For all desired features that the reconfigurator is able to configure, the reconfigurator will check if any of the desired features are not yet enabled in the cluster. If so, it will apply one of the vendor-agnostic tactic for these missing features, and it returns true.)”.
Claim 13, “the system of claim 6, wherein the control plane is further configured to at least: determine a second current state of a second container instance of the data plane; determine a second desired state of the second container instance; determine, based at least in part on the second desired state, a second plurality of operations to be performed at the second container instance to transition the second container instance to the second desired state; and push, from the control plane and to a second agent of the data plane, each of the second plurality of operations such that the second agent causes each operation of the second plurality of operations to be performed and the second container instance to transition from the second current state to the second desired state” is similar to claim 1 and is interpreted as performing the step of claim 1 for a second instance and therefore would be obvious to one ordinarily skilled in the are the combination teaches the claim.
Claim 14, the combination teaches the claim, wherein Truyen teaches “the system of claim 13, wherein the control plane is further configured to push each of the plurality of operations and each of the second plurality of operations through a proxy that communicates with the control plane, the agent, and the second agent ([Fig. 6] VPC Network as proxy)”.
Claim 15, the combination teaches the claim, wherein Truyen teaches “the system of claim 6, wherein the control plane includes at least: a container set manager configured to determine the plurality of operations; and a workflow manager that pushes each operation of the plurality of operations to the agent ([2.1.2. Kubernetes Architecture] On Control Plane, we usually run four core components: API server, Scheduler, Controller Managers, and etcd database: • APIserveristhecentralpoint of communication among the components of the cluster. It exposes various RESTful APIs, through which worker node agents, controllers, users and applications can create, query or update cluster and application resources. These APIs are an abstraction of the actual resources deployed. Here, we introduce the APIs resources that are used in this paper: Pod is the atomic unit of deployment in Kubernetes, consisting of one or more tightly coupled containers. Aodcanbethoughtofasavirtualhostforcontainers, and all containers in it share the same Linux network namespace and cgroup parent; Deployment represents a set of pod replicas managed by the Deployment con troller. We can specify the desired number of replicas and the updating strategy in the Deployment API. The Deployment controller will enforce our specification; Daemonsetrepresents a pod that should be deployed on every node of the cluster, and every node should only have one copy of the pod; Service is an API resource that specifies a stable network access point behind a set of volatile pods; Custom Resource Definition (CRD), customresource represents extended API resources in the API server. We can use this API to introduce new custom APIs; • etcdDatabaseisakey-value database that stores the desired and actual states of all API resource objects. After the API server receives the client’s request, it will query or update the corresponding resource states in the etcd database [18]; • Controller Manager, controller contains many built-in controllers that implement control loops to manage resources of various built-in API types like Deployments and Services. For example, the Deployment Controller monitors the actual number of replicas of pods in a Deployment and performs actions to make it match the desired number as described by users; • Schedulerisresponsible for placing pods on the appropriate worker nodes based on the node states and the requirements of the pods.)”.
Claim/s 3, 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Truyen, Kovachka-Dimitrova in further view of Aygar (Pub. No. US 2024/0078127).
Claim 3, the combination may not explicitly teach the limitation.
Aygar teaches “the computer-implemented method of claim 1, wherein receiving the request to run the application, includes: receiving, from an orchestrator, an application specification indicating the request to run the application ([0078] At block 504, operations 500 proceed with, in response to booting the device, automatically obtaining, by the device, one or more intended state configuration files from a server external to the device, the one or more intended state configuration files defining a control plane configuration for providing services for at least deploying and managing the containerized workload and workload configuration parameters for the containerized workload. In certain aspects, the control plane configuration for providing services for deploying and managing the containerized workload is a control plane configuration for Keswick Node 204 illustrated in FIG. 2.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Aygar with the teachings of Truyen, Kovachka-Dimitrova in order to provide a system that teaches a specification. The motivation for applying Aygar teaching with Truyen, Kovachka-Dimitrova teaching is to provide a system that allows for design choice. Truyen, Kovachka-Dimitrova, Kovachka-Dimitrova are analogous art directed towards software deployment. Together Truyen, Kovachka-Dimitrova teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Aygar with the teachings of Truyen, Kovachka-Dimitrova by known methods and gained expected results.
Claim 4, the combination teaches the claim, wherein Aygar teaches “the computer-implemented method of claim 3, wherein determining the plurality of operations, includes: determining, based at least in part on the application specification, one or more of the plurality of operations ([0078] At block 504, operations 500 proceed with, in response to booting the device, automatically obtaining, by the device, one or more intended state configuration files from a server external to the device, the one or more intended state configuration files defining a control plane configuration for providing services for at least deploying and managing the containerized workload and workload configuration parameters for the containerized workload. In certain aspects, the control plane configuration for providing services for deploying and managing the containerized workload is a control plane configuration for Keswick Node 204 illustrated in FIG. 2.)”.
Rationale to claim 3 is applied here.
Claim/s 5, 12, is/are rejected under 35 U.S.C. 103 as being unpatentable over Truyen, Kovachka-Dimitrova, Aygar in view of Liu (Pub. No. US. 2021/0294623).
Claim 5, 12, the combination may not explicitly teach the limitation.
Liu teaches “the computer-implemented method of claim 3, further comprising: transforming the application specification from an orchestrator specific language to a general state machine definition language that may be used by the container set manager to determine operations of the plurality of operations ([0098] Processing the request message by the server in the first container may be understood as modifying, by the server, a format of the content information stored by the first process in the first container in the private memory 2412. For example, when the first process in the first container serves as a client to request a service from the server, a preset interface function (for example, a transact interface function) is actually invoked, and a data format of the content information in the request message sent by the first process complies with a structure format of the interface. When notifying the second process that there is a request message needing to be processed, the server also needs to invoke a preset interface function (for example, a notify interface function), and a data format of the content information of the sent request message should comply with a structure format of the interface. Therefore, the server needs to modify a format of the content information stored by the first process in the private memory 2412, so that the second process, needing to process the request message, in the first container can receive the request message, and perform a corresponding action based on the content information in the request message.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Liu with the teachings of Truyen, Kovachka-Dimitrova, Aygar in order to provide a system that teaches a specification. The motivation for applying Aygar teaching with Truyen, Kovachka-Dimitrova teaching is to provide a system that allows for design choice. Truyen, Kovachka-Dimitrova, Kovachka-Dimitrova are analogous art directed towards software deployment. Together Truyen, Kovachka-Dimitrova teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Aygar with the teachings of Truyen, Kovachka-Dimitrova by known methods and gained expected results.
Claim/s 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over Truyen, Kovachka-Dimitrova, in view of Sadasivan (Pub. No. US 2024/0152378).
Claim 17, the combination may not explicitly teach the limitation.
Sadasivan teaches “the computer-implemented method of claim 16, wherein the second component pushes operations to a plurality of agents of the data plane, wherein the agent is included in the plurality of agents ([0087] FIG. 1 conceptually illustrates the architecture of a cloud-based multi-tenant network management and monitoring system 100 of some embodiments. In some embodiments, the network management and monitoring system 100 operates in a container cluster (e.g., a Kubernetes cluster 105, as shown). The network management and monitoring system 100 (subsequently referred to herein as a network management system) manages multiple groups of datacenters for multiple different tenants. For each group of datacenters, the tenant to whom that group of datacenters belongs selects a set of network management services for the network management system to provide (e.g., policy management, network flow monitoring, threat monitoring, etc.). In addition, in some embodiments, a given tenant can have multiple datacenter groups (for which the tenant can select to have the network management system provide the same set of services or different sets of services).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Sadasivan with the teachings of Truyen, Kovachka-Dimitrova in order to provide a system that teaches a specification. The motivation for applying Sadasivan teaching with Truyen, Kovachka-Dimitrova teaching is to provide a system that allows for design choice. Truyen, Kovachka-Dimitrova, Sadasivan are analogous art directed towards software deployment. Together Truyen, Kovachka-Dimitrova, Sadasivan teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Sadasivan with the teachings of Truyen, Kovachka-Dimitrova by known methods and gained expected results.
Claim/s 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over Truyen, Kovachka-Dimitrova, in view of Lee (Pub. No. US 2021/0146950).
Claim 18, the combination may not explicitly teach the limitation.
Lee teaches “the computer-implemented method of claim 16, further comprising: updating at least one of the first component or the second component while an application is running on the container instance and without terminating the application ([Abstract] A method for updating a container in a container-based vehicle system includes: executing an application included in the container, the application configured to access at least one item included in the container to operate a service related to a vehicle, receiving, from a server, a container image of an update target based on determining an update of the container being needed, the container image including a set of items, storing the received container image of the update target in a system registry, generating a new container by combining a user data item that is generated in the container and the stored container image of the update target, and updating the container by using a container management table on the new container while executing the application. The application reflects the updated container based on items included in the updated container.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Lee with the teachings of Truyen, Kovachka-Dimitrova in order to provide a system that teaches updating office action. The motivation for applying Lee teaching with Truyen, Kovachka-Dimitrova teaching is to provide a system that allows for design choice. Truyen, Kovachka-Dimitrova, Lee are analogous art directed towards software deployment. Together Truyen, Kovachka-Dimitrova, Lee teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Lee with the teachings of Truyen, Kovachka-Dimitrova by known methods and gained expected results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
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 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.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199
