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
This Office Actions is in response to claims filed 08/11/2025
Claims 1 - 16 are pending. Claims 1, 3, 5 – 7, 9, 11, 13 – 15 are amended. This action is Final.
Claim Objections
Claims 6 and 14 are objected to because of the following informalities: “scaling a quantity of nodes”. The applicant would need to change the “scaling a quantity of nodes” to “scaling a number of nodes” to make it consistent with the Specification, for example at pages 4, lines 16 – 19, because the Specification does not have support for the “a quantity of nodes”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 – 16 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1 and 9, the claims recite the limitation “retrieve, from the managed Kubernetes platform, an administrative manifest indicative of one or more administrative artifacts”. The examiner cannot find the support for the above underline limitation from the Specification filed on 07/19/2022. The closest support from the Specification that the examiner could find is “The PSM retrieves (operation 122) a Kubernetes manifest, referred to herein as an admin manifest, from a suitable formatted file, e.g., a YAML (yet another markup language) file. As suggested by its name, the admin manifest includes one or more administrative-management artifacts, e.g., pods, services, etc., some or all of which are deployed to the cluster.”, on pages 11, lines 25 – 30.
If the applicant believes the above limitation is supported by the Specification filed on 07/19/2022, the applicant can clearly point out which paragraphs or Figures contain the above limitation.
Claims 2 – 8 and 10 – 16 are also rejected due to the rejection of the independent claims 1 and 9.
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, and Singh et al. US Pat. No. US 11516220 B1 (hereafter Singh)
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, 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; importing the cluster of interest into the central orchestrator; and performing platform-specific management 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 indicative of 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 [0070] disclose the data could the user access information permission/administrative artifacts for the application container. However, Kosaka does not clearly teach a manifest indicative of one or more artifacts. The “indicative of” will be taught by Singh, as discuss below.
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 performing platform specific management tasks on the cluster of interest via the central orchestrator. (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)
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 retrieve, from the managed Kubernetes platform, an administrative manifest including one or more administrative artifacts; and deploy the administrative artifacts to the cluster to enable the central orchestrator to communicate securely with the managed Kubernetes platform and deploy and manage application workloads on the cluster, 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 indicative of 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; ....... administrative manifest indicative of 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.
Regarding claim 4, Gupta, in view of Kosaka, Humphreys and Singh, 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, and Singh, in further view of BHAT et al. US Pub. No. US 20230110527 A1 (hereafter BHAT)
Regarding claim 2, Gupta, in view of Kosaka, Humphreys and Singh, 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 and Singh’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 and Singh, 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 and Singh, 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 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, Kosaka, Humphreys, and Singh, in further view of SPIVAK et al. US Pub. No. US 20120266168 A1 (hereafter SPIVAK)
Regarding claim 5, Gupta, in view of Kosaka, Humphreys and Singh, discloses the method of claim 1, but fails to teach wherein the platform-specific management tasks include cluster infrastructure configuration tasks.
However, SPIVAK teaches wherein the platform-specific management tasks include cluster infrastructure configuration tasks. (e.g. [0029]: “A system administrator may create deployment manifest 402 for an initial deployment of cloud computing platform application 200, modify deployment manifest 402 to scale up or down an already-deployed cloud computing platform application 200, or update a deployed cloud computing platform application 200.”) The citation discloses some tasks that can be performed by the system administrator, such as scale up or down an already-deployed cloud computing platform application / cluster infrastructure configuration 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 wherein the platform-specific management tasks include cluster infrastructure configuration tasks, as taught in SPIVAK’s invention into Gupta, Kosaka, Humphreys, and Singh’s invention because by incorporating infrastructure configuration into the central orchestrator’s management tasks, the system can improve scalability, consistency, and operational efficiency, and reduces the complexity and manual effort required for configuring cluster.
Regarding claim 13, the claim is an information handling system claim that having similar limitations cited in claim 5. Thus, claim 13 is also rejected under the same rational as cited in the rejection of rejected claim 5.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, Kosaka, Humphreys, Singh, and SPIVAK, 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, and SPIVAK, discloses the method of claim 5, and SPIVAK further teaches scaling a quantity of nodes associated with the cluster of interest (e.g. [0029]: “modify deployment manifest 402 to scale up or down an already-deployed cloud computing platform application 200”)
upgrading a Kubernetes version associated with the cluster of interest; ([0029]: “update a deployed cloud computing platform application 200”)
Gupta, in view of Kosaka, Humphreys, Singh, and SPIVAK 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, and SPIVAK’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.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, Kosaka, Humphreys, and Singh, in further view of Aggarwal et al. US Pub. No. US 20060136490 A1 (hereafter Aggarwal)
Regarding claim 7, Gupta, in view of Kosaka, Humphreys, and Singh, discloses the method of claim 1, but fail to teach further comprising: saving a cluster definition to enable future accesses to the cluster of interest.
However, Aggarwal teaches further comprising: saving a cluster definition to enable future accesses to the cluster of interest. [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 template/cluster definition is stored 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 further comprising: saving a cluster definition to enable future accesses to the cluster, as taught in Aggarwal’s invention into Gupta, Kosaka, Humphreys, and Singh’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 15, the claim is an information handling system claim that having similar limitations cited in claim 7. Thus, claim 15 is also rejected under the same rational as cited in the rejection of rejected claim 7.
Response to Amendment
The amendment filed on 08/11/2025 is objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows:
the independent claims recite the “retrieve, from the managed Kubernetes platform, an administrative manifest indicative of one or more administrative artifacts”. The examiner cannot find the support for the above underline limitation from the Specification filed on 07/19/2022. If the applicant believes the above limitation is supported by the Specification filed on 07/19/2022, the applicant can clearly point out which paragraphs or Figures contain the above limitation
Applicant is required to cancel the new matter in the reply to this Office Action.
Response to Arguments
Response to Drawing Objection
The Drawings filed on 08/11/2025 regarding Drawing Objection has been fully considered and the examiner agreed with all the changes made to the drawings. The Drawing Objection has been withdrawn
Response to 35 U.S.C. §112 Remarks
Applicant’s argument filed on 08/11/2025 regarding 35 USC § 112 rejection has been fully considered and they are persuasive. The examiner agreed with all the changes made to the claims. The previous 35 USC § 112 rejection has been withdrawn.
Response to 35 U.S.C. §103 Remarks
Applicant’s argument filed on 08/11/2025 regarding 35 USC § 103 rejections have been fully considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TUAN MINH NGUYEN whose telephone number is (703)756-1599. The examiner can normally be reached Monday-Friday: 9:30am - 5:00PM 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, Chat Do can be reached on 571-272-3721. 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
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193