DETAILED ACTION
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/26/2026 has been entered
Claims 1-4, 6, 8-12, 14, and 16 are pending. Claims 5, 7, 13, and 15 are canceled. Claims 1, 6, 9, 11, and 14 are amended. Claim 1 and 9 are in independent form.
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 .
Response to Amendment
This Office Action is in response to the applicant’s remarks and arguments filed on 03/26/2026.
Claims 5, 7, 13, and 15 are canceled. Claims 1, 6, 9, 11, and 14 are amended. Claims 1-4, 6, 8-12, 14, and 16 remain pending in the application and are being considered on the merits.
Applicant’s argument filed on 03/26/2026 regarding Claim Objections have been fully considered and they are persuasive. The examiner agreed with all of the amendment made to the claims 1 and 9. The Claim Objections has been withdrawn.
Applicant’s argument filed on 03/26/2026 regarding 35 U.S.C. §112(a) Rejections have been fully considered and they are persuasive. The examiner agreed with all of the amendment made to the claims 1 and 9. The 35 U.S.C. §112(a) Rejections has been withdrawn.
The previous claims Rejection under 35 U.S.C § 103 has been withdrawn due to the amendment to the claims filed on 03/26/2026. However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art White et al. US Pub. No. US 20200366752 A1, and in view of the previously cited prior art(s). Reference White, in combination with previously cited prior art(s), discloses each element of the claims highlighted by applicant.
Response to Arguments
The applicant’s remarks and/or arguments, filed on 03/26/2026 have been fully considered with the following result(s).
The examiner is entitled to give claim limitations their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation. The applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater, 162 USPQ 541,550-51 (CCPA 1969).
Response to Claim Objections
Applicant’s argument filed on 03/26/2026 regarding Claim Objections have been fully considered and they are persuasive. The examiner agreed with all of the amendment made to the claims 6 and 14. The Claim Objections has been withdrawn.
Response to 35 USC §112 Remarks
Applicant’s argument filed on 03/26/2026 regarding 35 U.S.C. §112(a) Rejections have been fully considered and they are persuasive. The examiner agreed with all of the amendment made to the claims 1 and 9. The 35 U.S.C. §112(a) Rejections has been withdrawn.
Response to 35 USC §103 Remarks
Applicant's arguments in the applicant’s remarks and amendments of independent claims 1 and 9, found on pages 7 – 10 and filed on 03/26/2026, have been fully considered and are persuasive. Therefore, the previous claim(s) rejection under 35 U.S.C § 103 has been withdrawn.
However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art White et al. US Pub. No. US 20200366752 A1, and in view of the previously cited prior art(s). Reference White, in combination with previously cited prior art(s), discloses each element of the claims highlighted by applicant.
For further details, please see below claims rejections under 35 U.S.C § 103.
Regarding the remark that “Moreover, with respect to saving a cluster definition and a platform definition as recited in the amended independent claims, even if Agrawal's description of cluster templates, cited by Examiner on page 20 of the Office Action for teaching features of previously presented claims 7, constitute a cluster definition, the ground of rejection is improper at least because it does not allege or assert prior art teaching with respect to the expressly recited platform definition.”
The examiner fully considered, but respectfully disagreed, and would like to point out that with the current claim language, in light of the Specification, the features of previously presented claims 7 are reasonable taught by reference Aggarwal, because the reference Aggarwal clearly disclosed the concept of storing cluster configuration as cluster definition, network and storage configuration as platform definition, are stored as cluster template for later retrieval and reuse/future access.
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 8 and 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 8 and 16, the claims recite the limitation “VMware Tanzu, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Red Hat OpenShift, and Docker EE.”. The claim scope is uncertain since the trademark or trade name cannot be used properly to describe any particular material or product. The use of a trademark or trade name in a claim to describe a material or product would not only render a claim indefinite, but would also constitute an improper use of the trademark or trade name. See MPEP 2173.05(u) Trademarks or Trade Names in a Claim.
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, 4, 9, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. US Pat. No. US 11593180 B2 (hereafter Gupta), in further view of Kosaka et al. US Pub. No. US 20200218798 A1 (hereafter Kosaka), Humphreys US Pat. No. US 10841152 B1, Singh et al. US Pat. No. US 11516220 B1 (hereafter Singh), White et al. US Pub. No. US 20200366752 A1, and Aggarwal et al. US Pub. No. US 20060136490 A1 (hereafter Aggarwal)
Regarding claim 1, Gupta teaches the invention substantially as claimed: a method comprising: accessing a central orchestrator including a plurality of cluster integration interfaces for a corresponding plurality of managed platforms;
(e.g. FIG. 4 and 43 – Col 6, lines 66 – 67, and Col 7, lines 1 – 6: “In general, universal public cloud 410 acts as a managed service managing a plurality of clusters (e.g., Kubernetes® clusters) created across a plurality of clouds 420, the clouds 420 potentially managed by separate and distinct cloud providers, such that a tenant is precluded from selecting particular cloud providers and, instead, universal public cloud 410 acts as an intermediary concerning the placement of workloads on clouds 420.”) The citation discloses the universal public cloud 410/central orchestrator, that manages a plurality of clusters that created across a plurality of clouds. As there are more than one clouds and clusters that could be access via the universal public cloud, it implies that there would be more than one cluster interfaces within the universal public cloud.
for each of two or more of the plurality of cluster integration interfaces, performing platform-specific operations, wherein the platform-specific operations include: selecting, via one of the cluster integration interfaces, a managed Kubernetes platform associated with a cluster of interest, wherein the cluster of interest comprises a remote Kubernetes cluster; (e.g. FIG. 4, 43 – Col 6, lines 66 – 67, and Col 7, lines 1 – 6: “In general, universal public cloud 410 acts as a managed service managing a plurality of clusters (e.g., Kubernetes® clusters) created across a plurality of clouds 420, the clouds 420 potentially managed by separate and distinct cloud providers, such that a tenant is precluded from selecting particular cloud providers and, instead, universal public cloud 410 acts as an intermediary concerning the placement of workloads on clouds 420.”) and FIG. 5, and 63 – Col 10, lines 11 – 19: “In step 550, universal placer 450 selects a cluster, or the remaining clusters, that minimizes incremental cost. If the only remaining clusters have Exclusive or Guaranteed QoS types, universal placer 450 selects a cluster with the lowest incremental cost. Alternatively, if at least one of the remaining clusters has a QoS type of Burstable or BestEffort, universal placer selects a cluster with the lowest incremental cost that would maximize unutilized capacity.”) The citation discloses at FIG. 5, and 63 – Col 10, lines 11 – 19 the selecting of a cluster from the multiple candidate clusters. At FIG. 4, 43 – Col 6, lines 66 – 67, and Col 7, lines 1 – 6 discloses the cluster could be the Kubernetes® clusters, and as there are more than one clouds and clusters that could be access via the universal public cloud, it implies that there would be two or more cluster interfaces within the universal public cloud.
registering a connection with the managed Kubernetes platform; (e.g. FIG. 4, FIG. 5, and 42 – Col 6, lines 35 – 41: “The network may be a local area network (LAN), a wire area network (WAN), such as the Internet, the public switched telephone network (PSTN), any combination thereof, or any combination of connections and protocols that will support communications between universal public cloud 410 and clouds 420, as well as universal public cloud 410 and tenant computing device 440.” and 73 – Col 12, lines 13 – 19: “In step 580, universal placer 450 creates the project on the selected cluster and deploys the workload. Typically, universal placer 450 will receive confirmation from the tenant via tenant computing device 440 after providing the price estimate and, in response to such confirmation, will create the project on the selected cluster, and deploy workload(s) on one or more pods of the cluster.”) The citation discloses at Col 6, lines 35 – 41 that there is combination of connections between the universal public cloud 410 and clouds 420, and at Col 12, lines 13 – 19 discloses the deployment of workloads between the universal placer and the selected clusters, so it implies that there must be a connection between the universal placer and the selected clusters.
...... and deploy and manage application workloads on the cluster of interest (e.g. 43 – Col 6, lines 58 – 66: “In the depicted embodiment, universal public cloud 410 contains, at least, universal placer 450 and organization 460, as created by tenant computing device 440 such that project 470 can be deployed on one or more of clouds 420-1 through 420-N. While not depicted, it is also contemplated that universal public cloud 410 may be capable of processing and deploying any necessary workload(s) associated with project 470 by utilizing on-premises computing resources.”) the citation discloses the deploying of workloads to the corresponding cluster within the corresponding clouds.
Gupta fails to teach Instantiating, within the central orchestrator, a platform-specific microservice (PSM) provisioned with platform-specific logic and tooling; providing credentials collected during the registering to the PSM, wherein the PSM is configured to: connect to the managed Kubernetes platform, retrieve, from the managed Kubernetes platform, an administrative manifest including one or more administrative artifacts; and deploy the administrative artifacts to the cluster of interest to enable the central orchestrator to communicate securely with the managed Kubernetes platform; importing the cluster of interest into the central orchestrator; and performing platform-specific management tasks on the cluster of interest via the central orchestrator; save a cluster definition and a platform definition in the central orchestrator to enable future access to the cluster of interest; and perform platform-specific management tasks, including one or more cluster infrastructure configuration tasks, on the cluster of interest via the central orchestrator.
However, Kosaka teaches wherein the PSM is configured to: connect to the managed Kubernetes platform, retrieve, from the managed Kubernetes platform, an administrative manifest including one or more administrative artifacts; (e.g. [0068]: “The policy interpreter 125 may receive data from the manifest detector 115 regarding newly initiated or added application containers and generates the application container network security policy 135 for the application container. This data may include the application container deployment configuration information 105, the dynamic running services information 110, and the metadata gathered by the protocol analyzer 120.” and [0075]: “The policy interpreter 125 may generate user access rules based on data from the manifest detector 115 indicating user accounts that are allowed to access the application container or user accounts that are used by the application container to connect to other application containers or other services. Upon detecting the existence of user accounts, the policy interpreter 125 may create user access rules allowing only the indicated user accounts to access the application container or to allow the application container to access the other application container or other service.”) the citation disclose at [0068] the policy interpreter 125/microservice, receive/retrieve data from the manifest detector regarding the application container. There must be a connection established between the policy interpreter and the manifest detector to transfer the data. At [0075] disclose the data could be used to generate user access information permission/administrative artifacts, for the application container.
and deploy the administrative artifacts to the cluster of interest to enable the central orchestrator to communicate securely with the managed Kubernetes platform; ([0082]: “The application container network security policy 135 is generated by the policy interpreter 125 and specifies one or more security rules which define the scope of the actions that can be performed by the application container.”) and [0083]: “The security system 140 applies the security rules specified in the application container network security policy 135. Any actions that are performed by the application container may be detected by the security system 140. These may include access to other application containers, receiving and transmitting data, accessing resources, and so on. The security system 140 checks the action of the application container with the security rules for the application container as specified in the application container network security policy 135, and determines if a security rule matching the action (i.e., allowing the action to proceed) exists.”) The citation discloses at [0082] the policy interpreter generates the network security policy 135, and at [0083] the security system 140 applied the security rules from the security policy 135 for checking the action of the application container, which enable the secure communication between the container and the system.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein the PSM is configured to: connect to the managed Kubernetes platform, retrieve, from the managed Kubernetes platform, an administrative manifest indicative of one or more administrative artifacts; and deploy the administrative artifacts to the cluster of interest to enable the central orchestrator to communicate securely with the managed Kubernetes platform, as taught in Kosaka’s invention into Gupta’s invention because the PSM feature would help the system to ensure secure communication, efficient workload management, and improve scalability across different cloud environment.
However, Humphreys teaches importing the cluster of interest into the central orchestrator; (Col 7, lines 24 – 29: “The service broker creates a deployment manifest (220). As described above, the service broker can generate the deployment manifest based on a release template for the cluster and a cloud computing platform on which the cluster will be deployed. The deployment manifest defines the components and properties of the cluster to be deployed.”) The citation discloses the deployment/importing of the cluster.
and perform platform-specific management tasks, including one or more cluster infrastructure configuration tasks, on the cluster of interest via the central orchestrator. (e.g. 11 - Col 3, lines 61 – 65: “The CLI of the user device 110 can also be used to perform other tasks with respect to clusters managed by the cluster management system 120. For example, the CLI can accept other commands that enable users to view information about clusters, view cluster plans, obtain credentials to deploy workloads to clusters, scale clusters, delete clusters, and/or perform other appropriate tasks related to clusters.”) The citation discloses the cluster’s management tasks (scale cluster, delete cluster), including cluster infrastructure configuration (scale, delete) task.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the providing credentials collected during the registering to the PSM retrieve; ...... importing the cluster of interest into the central orchestrator; and performing platform specific management tasks on the cluster of interest via the central orchestrator, as taught in Humphreys’s invention into Gupta’s invention because this enabling the orchestration of multiple clusters from a single interface. By performing platform management tasks through central orchestrator, the system can ensure consistency and improve the efficiency and scalability of managing complex environments.
However, Singh teaches Instantiating, within the central orchestrator, a platform-specific microservice (PSM) provisioned with platform-specific logic and tooling, (e.g. 9 – Col 3, lines 4 – 14: “The computer network administered by the service provider may provide a plurality of solutions to tenants, where each solution of the plurality of solutions includes a plurality of microservices. Each microservice may independently define object types, entities, remote procedure calls (RPCs) to modify objects, or any combination thereof. In this way, each microservice may, in some examples, expose many object types. To provide role-based access control (RBAC) in the computer network having the plurality of microservices, at least one custom role may be created by a service provider.”) The citation discloses the concept of having multiple microservices, wherein each microservice has their own object types, entities/logic and tooling, to help the tenant access different solutions that are provided by the service provider.
..... an administrative manifest including one or more administrative artifacts (e.g. 40 – Col 14, lines 19 – 32: “In addition to creating custom roles, controller 20 may also, in some cases, modify existing roles stored by storage device 22. In some examples, controller 20 is further configured to receive, from user interface 30, data indicative of a modification of the role. The data indicative of the modification may, in some cases, be coded in a human-readable data serialization language such as YAML or JSON Controller 20 may modify the role based on the data indicative of the modification. To modify the role based on the data indicative of the modification, controller 20 is configured to add at least one capability to the set of capabilities associated with the role, remove at least one capability of the set of capabilities associated with the role, or any combination thereof.”) The citation discloses the concept of describing data that represents or refers to another object rather than containing it directly.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the Instantiating, within the central orchestrator, a platform-specific microservice (PSM) provisioned with platform-specific logic and tooling; ....... an administrative manifest including one or more administrative artifacts, as taught in Singh’s invention into Gupta’s invention because the microservice with its own functioning would help the system to be more efficient and accurate communication and deployment operations. In addition, with the combine of data indicative of a modification of the role, would enable the microservice within the central orchestration to obtain only data or information needed to locate those artifacts, rather than transferring the full artifact data, which helps to improve system efficiency by reducing the data transfer overhead when connecting to and managing remote clusters.
However, White teaches providing credentials collected during the registering to the PSM (e.g. FIG. 7A and [0114]: “Referring now to operation (710), and in some embodiments, metadata 622 can be received. In embodiments, the device 602 can receive the metadata 622 as part of or included with the registration request 630. In embodiments, the metadata 622 can be received as part on or during the registration and/or configuration of the microservice 575. For example, the metadata 622 can be received or provided to the device 602 responsive to the command or instruction from the user through the command line or the user interface.”) the citation discloses the metadata/credential, is received/collected, during the registration of microservice/PSM.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the providing credentials collected during the registering to the PSM, as taught in White’s invention into Gupta’s invention because the additional feature would enable secure and reliable access the resources needed to deploy and manage cluster, which improves the efficiency, security, and reducing setup delay.
However, Aggarwal teaches save a cluster definition and a platform definition in the central orchestrator to enable future access to the cluster of interest. (e.g. [0170]: “Cluster Templates. According to another aspect of the present invention, not only are the workflows virtualized into reusable workflow templates, but the same technique is applied to the actual configurations of clustered servers, as well, to yield "cluster templates". How different clusters have been configured (e.g., what software products need to be installed on servers in the cluster, their network configuration, storage configuration etc.) is also analyzed by CCW to find common denominator partial cluster configurations, and these are stored as cluster templates for later retrieval and reuse during further configuration and provisioning activities Preferably, a cluster template includes, or is associated with, workflow information required to implement that portion of a cluster configuration.”) The citation discloses the cluster configuration/cluster definition, network and storage configuration/platform definition, are stored as cluster template for later retrieval and reuse/future access.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the save a cluster definition and a platform definition in the central orchestrator to enable future access to the cluster of interest, as taught in Aggarwal’s invention into Gupta’s invention because by storing the cluster definitions, the system can reduce the extra steps of repeating manual configuration and registration of Kubernetes clusters in the future access, ensures faster provisioning, and improve scalability across multiple managed platform.
Regarding claim 4, Gupta, in view of Kosaka, Humphreys, Singh, White, and Aggarwal, discloses the method of claim 1, and Kosaka further teaches wherein the administrative manifest comprises a yet another markup language (YAML) file. (Kosaka - [0025]: “The manifest data may be defined using any type of data description language, such as YAML (YAML Ain't Markup Language)”)
Regarding claim 9, the claim is an information handling system claim that having similar limitations cited in claim 1. Thus, claim 9 is also rejected under the same rational as cited in the rejection of rejected claim 1.
Regarding claim 12, the claim is an information handling system claim that having similar limitations cited in claim 4. Thus, claim 12 is also rejected under the same rational as cited in the rejection of rejected claim 4.
Claims 2, 3, 8, 10, 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, Kosaka, Humphreys, Singh, White, and Aggarwal, in further view of BHAT et al. US Pub. No. US 20230110527 A1 (hereafter BHAT)
Regarding claim 2, Gupta, in view of Kosaka, Humphreys, Singh, White, and Aggarwal, discloses the method of claim 1, but fails to teach further comprising: establishing, prior to selecting the managed Kubernetes platform, an authenticated cluster-admin role for the remote Kubernetes cluster.
However, BHAT teaches further comprising: establishing, prior to selecting the managed Kubernetes platform, an authenticated cluster-admin role for the remote Kubernetes cluster. (e.g. FIG. 9, and [0067] At 904, application manager 210 creates roles for different users. When cluster manager 104 is implemented within a cluster 102, various roles may be created leveraging cloud-native objects, according to some embodiments. When application manager 210 is deployed, admin role 304 may be created.” and [0070]: “At 906, application manager 210 binds user roles using cloud-native objects. For example, application manager 210 may bind admin role 304, basic role 306, and config role 308 using cloud-native objects. Cluster role binding 404 represents the cloud-native object that grants permissions to a user across an entire cluster. Admin role 304 and config role 308 may be bound by cluster role binding 404. In this case, cluster role binding 404 allows a user using application manager 210 to access applications, resources, policies, profiles, and/or activities in cluster 102.”) The citation discloses at FIG. 9 the flowchart illustrating a process for a method for role-based access control using cloud-native objects in multi-tenant environment, and at [0904] disclose the application manager creates the roles for different users, including admin roles. At [0070] disclose the application manager binds the set of roles created to the cluster role object, which grand permission to the user across the entire cluster. The above steps happen before/prior the user inputs the log-in credential for accessing and selecting the platform of interest.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the further comprising: establishing, prior to selecting the managed Kubernetes platform, an authenticated cluster-admin role for the remote Kubernetes cluster, as taught in BHAT’s invention into Gupta, Kosaka, Humphreys, Singh, White, and Aggarwal’s invention because it helps to reduce the risk of unauthorized actions and improve the overall security, since only authorized users with the appropriate privileges can perform administrative tasks.
Regarding claim 3, Gupta, in view of Kosaka, Humphreys, Singh, White, and Aggarwal, discloses the method of claim 2, but fails to teach wherein the connection with the managed Kubernetes platform includes platform account credentials and cluster admin role information corresponding to the authenticated cluster-admin role.
However, BHAT teaches wherein the connection with the managed Kubernetes platform includes platform account credentials and cluster admin role information corresponding to the authenticated cluster-admin role. (FIG. 3 and [0037]: “Cluster 102 may include cluster roles 302. Cluster roles 302 may include, but are not limited to, admin role 304, basic role 306, and/or config role 308. Each of the cluster roles 302 may contain rules that represent a set of permissions 310 (not shown). When application manager 210 is deployed, admin role 304 may be created. Admin role 304 may include a set of admin permissions 314. Admin permissions 314 may allow an authorized admin user 204 to create any policies 324 in cluster 102. Admin role 304 may also include admin permissions 314 to allow an admin user 204 to view any policies 324 created in cluster 102. Admin permissions 314 may include authorization of an admin user 204 to create and view the location of profiles 334 for any user. Moreover, admin permissions 314 may include authorization to list actions 344 created by all types of users in cluster 102. Actions 344 may include operations a user can perform (e.g., create, view, list, patch, put, get, restore, backup, etc.)”) The citation discloses the cluster roles 302/platform account credential and the admin role 304/cluster admin roles. The admin roles 302 includes the list of permission and action the user with admin roles can perform to the cluster.
Regarding claim 8, Gupta, in view of Kosaka, Humphreys, Singh, White, and Aggarwal, discloses the method of claim 1, and Kosaka further teaches wherein the plurality of managed platforms include one or more platforms selected from:
VMware Tanzu,
Google Kubernetes Engine (GKE), ([0023]: “Google Kubernetes Engine, ........ and/or any cloud orchestrator known to a person of ordinary skill in the art.”)
Amazon Elastic Kubernetes Service (EKS),
Azure Kubernetes Service (AKS) ([0023]: “Azure Kubernetes Service, and/or any cloud orchestrator known to a person of ordinary skill in the art.”)
Red Hat OpenShift, ([0023]: “Red Hat Openshift Container Platform, ........ and/or any cloud orchestrator known to a person of ordinary skill in the art.”)
and Docker EE
Regarding claim 10, the claim is an information handling system claim that having similar limitations cited in claim 2. Thus, claim 10 is also rejected under the same rational as cited in the rejection of rejected claim 2.
Regarding claim 11, the claim is an information handling system claim that having similar limitations cited in claim 3. Thus, claim 11 is also rejected under the same rational as cited in the rejection of rejected claim 3.
Regarding claim 16, the claim is an information handling system claim that having similar limitations cited in claim 8. Thus, claim 16 is also rejected under the same rational as cited in the rejection of rejected claim 8.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, Kosaka, Humphreys, Singh, White, and Aggarwal, in further view of Cantrill et al. US Pub. No. US 20170250988 A1 (hereafter Cantrill).
Regarding claim 6, Gupta, in view of Kosaka, Humphreys, Singh, White, and Aggarwal, discloses the method of claim 1, and Humphreys further teaches scaling a number of nodes associated with the cluster of interest (e.g. 27 – Col 6, lines 45 – 51: “The deployment manager 140 can scale the number of cluster masters 153, key value stores 155, and/or clusters 152 based on the health or workload of the cluster 152. For example, the deployment manager 140 can spin up another cluster master 153 virtual machine in response to an increase in demand for the containerized applications.”)
upgrading a Kubernetes version associated with the cluster of interest; (e.g. 6 – Col 2, lines 34 – 36: “Updating the deployment manifest in response to updates to the computing cluster, e.g., updates to a container orchestrator that manages the clusters” and FIG. 4)
Gupta, in view of Kosaka, Humphreys, Singh, White, and Aggarwal fails to teach adjusting user roles and user permissions associated with the cluster of interest.
However, Cantrill teaches adjusting user roles and user permissions associated with the cluster of interest. (e.g. [0038]: “If the user's access role has been changed (e.g., by an administrator or tenant owner), the next time the user makes a request to access the logs the user's updated role is reflected on the ACL 223 when the user's updated authorization token is added. Thus, the user may no longer have access to logs that they were able to previously access or they may now have access to additional logs in view of their new access role.”) The citation discloses the update/change/adjust of the user access roles/user permission.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the adjusting user roles and user permissions associated with the cluster of interest, as taught in Cantrill’s invention into Gupta, Kosaka, Humphreys, Singh, White, and Aggarwal’s invention because by adding the ability of adjusting the user roles as needed, the system can improve and reduce security risks and access control, and ensure that only authorized users can manage or modify the system, and provide more flexible and scalable cluster management approach.
Regarding claim 14, the claim is an information handling system claim that having similar limitations cited in claim 6. Thus, claim 14 is also rejected under the same rational as cited in the rejection of rejected claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20240020176 A1: methods for deployment of a Kubernetes cluster, comprising create a blueprint for the requested deployment of the Kubernetes cluster, identify a zone in which the blueprint is to be deployed, the zone identified based on at least one tag specified in the blueprint, and deploy a resource based on the blueprint, the resource created on a provider instance associated with the selected zone.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon 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 passage as taught by the prior art or disclosed by the Examiner.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TUAN M NGUYEN whose telephone number is (703)756-1599. The examiner can normally be reached Monday-Friday: 9:30am - 5:30PM ET.
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, Pierre Vital can be reached on (571) 272-4215. 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.
/TUAN M NGUYEN/Examiner, Art Unit 2193
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights