DETAILED ACTION
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 .
Status of Claims
Claims 1-20 are presented for examination in this application. The application filing date on 01/31/2023. Claims 1, 9 and 17 are independent.
Examiner notes
(A). Drawings submitted on 01/31/2023 comply with the provisions of 37 CFR 1.121(d).
(B). IDS submitted on 01/31/2023 and 02/16/2026 have been fully considered by the Examiner.
(C) Limitations have been provided with the Bold fonts in order to distinguish from the cited part of the reference (Italic).
(D). Examiner has cited particular columns, line numbers, references, or figures in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses to fully consider the reference in entirety, as potentially teaching all or part of the claimed invention. See MPEP § 2141.02 VI and 2123.
The examiner requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claim 1
Claim 1, line 10, “the predefined storage attributes”, lacks proper antecedent basis.
“the PVC specification” in line 8, lacks proper antecedent basis.
“the specification” in line 10, lack proper antecedent basis.
Claim 2
Claim 2, line 2, “the default storage classes” lacks proper antecedent basis.
Claim 4
Claim 4, line 2, “the persistent volume” lacks proper antecedent basis.
Claim 6
Claim 6, “a cluster” (line 3) should have --the--.
Claim 7
Claim 7, “a node” (line 5) should have --the--.
Claim 7, line 2, “the different namespace” lacks proper antecedent basis.
Claim 7, line 3 before “predefined storage attribute”, --the-- should be inserted.
Claim 8
Claim 8, “a namespace” (line 2) should have --the--.
Claim 9
Claim 9, line 9, “the predefined storage attributes”, lacks proper antecedent basis.
Claim 12
Claim 12, line 2, “the persistent volume” lacks proper antecedent basis.
Claim 14
Claim 14, “a cluster” (line 2-3) should have --the--.
Claim 15
Claim 15, “a node” (line 5) should have --the--.
Claim 16
Claim 16, “a namespace attribute” (line 2-3) should have --the--.
Claim17
Claim 17, line 10, “the predefined storage attributes”, lacks proper antecedent basis.
Claim 20
Claim 20, line 2, “the persistent volume” lacks proper antecedent basis.
These claims 3, 5, 10-11, 13 and 18-19 are dependent claims of objected claims; therefor they inherit the same issue.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1: Claims 1-8 are directed to computer implemented device and fall within the statutory category of machines; Claims 9-16 are directed to method and fall within the statutory category of processes; Claims 17-20 are directed to computer-readable medium and fall within the statutory category of manufacture. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Under Step 2A, Prong 1, the claim 9 recites multiple limitations that recite an abstract idea. The limitations “identifying a namespace based on namespace attribute of the PVC;
identifying a storage class which is declared as a default storage class for the identified namespace based on one or more other attributes of the PVC and injecting storage criteria of the
default storage class into the specification of the software application;” The limitations of identifying a name space and identifying a storage class are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. Therefore, since the BRI is a concept that can be reasonably performed in the human mind.
Under Step 2A, Prong 2, the additional elements “receiving, via an application programming interface (API) of a cluster, a persistent volume claim (PVC) with a specification of a software application;” and “deploying the software application via a node within the identified namespace according to the predefined storage attributes of the default storage class injected into the specification of the software application.” The additional elements of receiving software application via API merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g).
Further, the additional elements of deploying the software application merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. See MPEP 2106.05(f).
Under step 2B, the additional elements do not amount to significantly more than the abstract idea. As stated above, the claimed invention merely recites generic computer system for carrying out or applying the abstract idea. Furthermore, the courts have recognized that mere data gathering, such as those defined in the claim, are well-understood, routine, and convention computer functions which cannot serve as an inventive concept according to MPEP 21.06.05(d).
For the above reasons, the claims of this application are not patentable under 35 USC 101.
Under Step 2A, Prong 1, the claim 1 recites multiple limitations that recite an abstract idea. The limitations “identify a namespace based on namespace attribute of the PVC;
identify a storage class which is declared as a default storage class for the identified namespace based on one or more other attributes of the PVC and injecting storage criteria of the
default storage class into the specification of the software application” The limitations of identifying a name space and identifying a storage class are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. Therefore, since the BRI is a concept that can be reasonably performed in the human mind.
Under Step 2A, Prong 2, the additional elements “a processor configured to: receive, via an application programming interface (API) of a cluster, a persistent volume claim (PVC) with a specification of a software application;” and “deploy the software application via a node within the identified namespace according to the predefined storage attributes of the default storage class injected into the specification of the software application.” the additional elements of receiving software application via API merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g).
Further, the additional elements of d a processor configurate to, deploying the software application merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. See MPEP 2106.05(f).
Under step 2B, the additional elements do not amount to significantly more than the abstract idea. As stated above, the claimed invention merely recites generic computer system for carrying out or applying the abstract idea. Furthermore, the courts have recognized that mere data gathering, such as those defined in the claim, are well-understood, routine, and convention computer functions which cannot serve as an inventive concept according to MPEP 21.06.05(d).
For the above reasons, the claims of this application are not patentable under 35 USC 101.
Under Step 2A, Prong 1, the claim 17 recites multiple limitations that recite an abstract idea. The limitations “identify a namespace based on namespace attribute of the PVC;
identify a storage class which is declared as a default storage class for the identified namespace based on one or more other attributes of the PVC and injecting storage criteria of the
default storage class into the specification of the software application;” The limitations of identifying a name space and identifying a storage class are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. Therefore, since the BRI is a concept that can be reasonably performed in the human mind.
Under Step 2A, Prong 2, the additional elements “A computer-readable storage medium comprising instructions, that when read by a processor, cause the processor to perform a method comprising: receive, via an application programming interface (API) of a cluster, a persistent volume claim (PVC) with a specification of a software application;” and “deploy the software application via a node within the identified namespace according to the predefined storage attributes of the default storage class injected into the specification of the software application.” the additional elements of receiving software application via API merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g).
Further, the additional elements of a computer-readable storage medium comprising instructions, that when read by a processor, cause the processor to perform a method comprising: deploying the software application merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. See MPEP 2106.05(f).
Under step 2B, the additional elements do not amount to significantly more than the abstract idea. As stated above, the claimed invention merely recites generic computer system for carrying out or applying the abstract idea. Furthermore, the courts have recognized that mere data gathering, such as those defined in the claim, are well-understood, routine, and convention computer functions which cannot serve as an inventive concept according to MPEP 21.06.05(d).
For the above reasons, the claims of this application are not patentable under 35 USC 101.
Dependent Claims 2, 3-5, 10-11, 13 and 18-19 are not patent eligible for the same reasons given for claim 9, wherein the “… configure to identify file, namespace, specification of software application … configure to deploy, intercept, ” is merely uses a generic computer or computer components as a tool to perform the abstract idea, thus fails to integrate the judicial exception into a practical application, nor an inventive concept.
Further Dependent Claims 4, 12 and 20 is rejected for similar reasons as articulated for claim 9 as the additional limitations “processor is configured to assign resources from the persistent volume to the software application deployed via the identified namespace based on the predefined storage attributes of the default storage class injected into the PVC” is merely uses a generic computer or computer components as a tool to perform the abstract idea, that does not allude to a practical application of the abstract idea or amount to significantly more.
Further dependent claims 6-8 and 14-16 are not patent eligible for the same reasons given for claim 1, wherein the “ … processor is configured to assign resources from the persistent volume to the software application deployed via the identified namespace based on the predefined storage attributes of the default storage class injected into the PVC.”, expand on the abstract idea in its calculation and/or expand on the type of metric value that is used that does not integrate the invention into a practical application of the abstract idea or amount to significantly more.
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 of this title, 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1, 3-4, 6-8, 11-12, 16-17 and 19-20 are rejected under 35 U.S.C. 103 as being obvious over Dontu et al (US 11194483 B1) in view of Nagar et al (US 20240126630 A1).
As to claim 1, Dontu discloses an apparatus comprising:
a processor configured to (col. 4, ll. 61-65, . Hypervisor 150 abstracts processor, memory, storage, and network resources of hardware platform 122 to provide a virtual machine execution space within which multiple virtual machines (VM)):
receive, via an application programming interface (API) of a cluster (col. 16, ll. 53-57, CSI driver 510 notices the modified and/or created SCO objects 532 and calls API 509 of storage service 110 to convert the persistent volume lifecycle operations of guest cluster 580 into operations on storage volumes 318), a persistent volume claim (PVC) with attributes of a software application (col. 10, ll. 10-20, A pod includes a specification and a status. The specification includes metadata, such as a name of the pod and optionally one or more labels. The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component [i.e. application attribute], and the like.);
identify a namespace based on namespace attribute of the PVC (col. 7, ll. 65-ll. 4 of col 8, a supervisor namespace. A “supervisor namespace” is a shared abstraction between VI control plane 113 and orchestration control plane 115. Each supervisor namespace provides resource-constrained and authorization-constrained units of multi-tenancy. A supervisor namespace provides resource constraints, user-access constraints, and policies. Further, col. 10, ll. 1-20, A PVC includes a specification and a status. The specification includes metadata, such as a name of the PVC, a cluster ID, a namespace, and optionally one or more labels associated with the PVC. The specification further includes attributes of the PVC, such as access mode, volume mode, resource requests, storage class, and the like. The PVC status is one of a plurality of phases, such as pending (not available), bound, terminating, etc. A PVC is bound when assigned to a PV. Pods consume persistent volumes using PVCs. A pod includes a specification and a status. The specification includes metadata, such as a name of the pod and optionally one or more labels. The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like);
identify a storage class declared as a default storage class for the identified namespace based on one or more other attributes of the PVC (col. 1, ll. 40-49, Kubernetes maintains various metadata for PVs, persistent volume claims (PVCs) (i.e., requests for persistent storage [i.e. default]), and pods. This metadata includes PV/PVC/pod labels, PV/PVC/pod names, a cluster identifier (ID), and the like. From an administrative perspective, it is desirable to associate the relevant Kubernetes metadata with storage volume objects managed by the storage provider of the underlying infrastructure. The CSI drivers, however, are container orchestrator agnostic and do not present any Kubernetes metadata to the storage provider. Further, see col. 10, ll. 1-20 for namespace and attributes of the PVC) and injecting the identified storage class into the PVC specification of the software application (col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like); and
deploy the software application (col. 2, ll. 45-49, configured to deploy and manage applications in the host cluster. In embodiments, the container orchestrator is a Kubernetes platform that deploys and manages containerized applications in a cluster of VMs) (col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like).
Dontu does not explicitly disclose the following limitation but,
Nagar discloses deploy the software application via a node within the identified namespace (par. 0075, the lattice definition module 604 receives application deployment information that will be used to construct a lattice model for lattice clustering. As a non-limiting example, an explanation detection module that includes the lattice definition module 604 may be used for providing explanations for anomalies that occur in a microservices application deployed on a container-based platform in a cloud infrastructure, such as microservices deployed on a Kubernetes platform (Kubernetes is a registered trademark of Google Inc.). In this example, the application is deployed in a namespace in a cluster that has nodes [i.e. identified namespace], where each node has pods, and the pods have containers, with each container being identified by a container identifier (container ID). … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include deploy the software application via a node within the identified namespace, as disclosed by Nagar, for the purpose to deploy and manage applications in the host cluster. In embodiments, the container orchestrator is a Kubernetes platform that deploys and manages containerized applications in a cluster of VMs (see col. 2, ll. 46-49 of Nagar).
As to claim 3, Nagar discloses the apparatus wherein the processor is configured to deploy the software application via the identified namespace of the cluster (par. 0075, … the application is deployed in a namespace in a cluster that has nodes, where each node has pods, and the pods have containers, with each container being identified by a container identifier (container ID). …).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include the apparatus wherein the processor is configured to deploy the software application via the identified namespace of the cluster, as disclosed by Nagar, for the purpose to deploy and manage applications in the host cluster. In embodiments, the container orchestrator is a Kubernetes platform that deploys and manages containerized applications in a cluster of VMs (see col. 2, ll. 46-49 of Nagar).
As to claim 4, Dontu discloses the apparatus wherein the processor is configured to assign resources from the persistent volume to the software application (col. 8, ll. 2-9, A supervisor namespace provides resource constraints, user-access constraints, and policies (e.g., storage policies, network policies, etc.). Resource constraints can be expressed as quotas, limits, and the like with respect to compute (CPU and memory), storage, and networking of the virtualized infrastructure (host cluster 118, shared storage 170, SD network layer 175). Further, col. 10, ll. 9-20, when assigned to a PV. Pods consume persistent volumes using PVCs. A pod includes a specification and a status. The specification includes metadata, such as a name of the pod and optionally one or more labels. The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component) deployed via the identified namespace based on the predefined storage attributes of the default storage class injected into the PVC (col. 8, ll. 18-20, the user interacts with supervisor Kubernetes master 104 to deploy applications in supervisor cluster 101 within defined supervisor namespaces. Further, col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like).
As to claim 6, Dontu discloses the apparatus wherein the processor is further configured to receive, via the API, a second PVC with a second specification of a second software application to be hosted in a cluster (col. 9, ll. 53-56, in embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs)[i.e. plurality of PVC], and pods (e.g., Kubernetes PVs, PVCs, and pods). Note: any PVC beside first PVC is consider the second PCV. Further, col. 16, ll. 53-57, CSI driver 510 notices the modified and/or created SCO objects 532 and calls API 509 of storage service 110 to convert the persistent volume lifecycle operations of guest cluster 580 into operations on storage volumes 318. Further, col. 10, ll. 10-20, A pod includes a specification and a status. The specification includes metadata, such as a name of the pod and optionally one or more labels. The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like. Further, 0016, FIG. 5C is a block diagram depicting a logical view of a guest cluster container orchestrator environment according to an embodiment. In the embodiment, host cluster 118 is enabled as a supervisor cluster 101 and manages an application 141 comprising a guest cluster 580), and in response, identify storage class for PVC for the software application based on one or more attributes within the second PVC (col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like. Note: any PVC beside first PVC is consider the second PCV, see col. 9, ll. 53-55).
As to claim 8, Dontu discloses the apparatus wherein the processor is configured to identify the namespace from among a plurality of namespaces within the cluster based on a namespace attribute stored in the PVC (col. 8, ll. 14-19, a Kubernetes namespace or generally a “native namespace”), which allows users to deploy applications in supervisor cluster 101 within the scope of supervisor namespaces. In this manner, the user interacts with supervisor Kubernetes master 104 to deploy applications in supervisor cluster 101 within defined supervisor namespaces [i.e. plurality of namespaces. Further, col. 10, ll. 1-20, A PVC includes a specification and a status. The specification includes metadata, such as a name of the PVC, a cluster ID, a namespace, and optionally one or more labels associated with the PVC. The specification further includes attributes of the PVC, such as access mode, volume mode, resource requests, storage class, and the like. The PVC status is one of a plurality of phases, such as pending (not available), bound, terminating, etc. A PVC is bound when assigned to a PV. Pods consume persistent volumes using PVCs. A pod includes a specification and a status. The specification includes metadata, such as a name of the pod and optionally one or more labels. The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like).
As to claim 9, Dontu discloses a method comprising:
receiving, via an application programming interface (API) of a cluster (col. 16, ll. 53-57), a persistent volume claim (PVC) with a specification of a software application (col. 10, ll. 10-20);
identifying a namespace based on namespace attribute of the PVC (col. 7, ll. 65-ll. 4 of col 8);
identifying a storage class which is declared as a default storage class for the identified namespace based on one or more other attributes of the PVC (col. 1, ll. 40-49)
and injecting storage criteria of the default storage class (col. 9, ll. 30-38, Container orchestrator 302 manages objects that include the desired state, including persistent volume-based (PV-based) objects 320. Each of PV-based objects 320 defines, requests, or consumes a persistent volume. A persistent volume is storage [i.e. default storage class]that has a lifecycle independent of the lifecycle of applications 316. A persistent volume contrasts with ephemeral storage, which is created and deleted with creation and deletion of an application 316) into the specification of the software application (col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like); and
deploying the software application (col. 2, ll. 45-49) v(col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like);
Nagar discloses deploying the software application via a node within the identified namespace (par. 0075, the lattice definition module 604 receives application deployment information that will be used to construct a lattice model for lattice clustering. As a non-limiting example, an explanation detection module that includes the lattice definition module 604 may be used for providing explanations for anomalies that occur in a microservices application deployed on a container-based platform in a cloud infrastructure, such as microservices deployed on a Kubernetes platform (Kubernetes is a registered trademark of Google Inc.). In this example, the application is deployed in a namespace in a cluster that has nodes [i.e. identified namespace], where each node has pods, and the pods have containers, with each container being identified by a container identifier (container ID). … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include deploy the software application via a node within the identified namespace, as disclosed by Nagar, for the purpose to deploy and manage applications in the host cluster. In embodiments, the container orchestrator is a Kubernetes platform that deploys and manages containerized applications in a cluster of VMs (see col. 2, ll. 46-49 of Nagar).
As to claim 11, it is a method claim, having similar limitations of claim 3. Thus, claim 11 is also rejected under the same rationale as cited in the rejection of claim 3.
As to claim 12, it is a method claim, having similar limitations of claim 4. Thus, claim 12 is also rejected under the same rationale as cited in the rejection of claim 4.
As to claim 16, it is a method claim, having similar limitations of claim 8. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 8.
As to claim 17, it is a medium claim, having similar limitations of claim 9. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 9.
As to claim 19, it is a medium claim, having similar limitations of claim 3. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 3.
As to claim 20, it is a medium claim, having similar limitations of claim 4. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claim 4.
Claims 2, 7, 10, 14-15 and 19 are rejected under 35 U.S.C. 103 as being obvious over Dontu et al. and Nagar aa applied to claims 1, 9, 17 in the above and further in view of Kazi et al (US 11314442 B2).
As to claim 2, Dontu as modified by Nagar does not explicitly disclose the following limitation but,
Kazi discloses the apparatus wherein the processor is configured to identify a configuration file of the identified names (col. 5, ll. 50-61, Storage system information 106 includes aggregated information related to plurality of storage systems within dispersed storage environment 100. In an embodiment, information related to a storage system may include the availability data, a physical (e.g., geographic) location, configuration information related to the storage system, etc. Configuration information [i.e. file] related to a storage system may include an identifier, a network address, a global namespace, one or more internal namespaces, one or more sub-namespaces, respective capabilities of storage 125-1 through 125-n, capabilities of other included hardware, installed/supported firmware and/or software, a file structure, etc.) pace which defines a type of the default storage classes (col. 9, ll. 11-ll. 11 of col. 10, In step 204, namespace health program 200 determines information corresponding to a storage device of a storage system. Information corresponding to a storage device may include a storage media type, a hardware architecture, a capacity, a date of manufacture, a manufacturer, a cumulative power-on duration, a cumulative number of write operations, and other information previously discussed above. In one embodiment, namespace health program 200 determines information corresponding to a storage device of a storage system based on obtaining information aggregated within storage system information 106. In some embodiments, namespace health program 200 determines information corresponding to a storage device of a storage system from the information received from the broadcast requests for information from the instances of monitoring functions 121 executing within storage system 120-1 through storage system 120-n included within dispersed storage environment 100), and
then inject an identifier of the defined type of the default storage class from the configuration file into the specification of the software application (col. 1, ll. 12-15, Cloud computing is an information technology paradigm that enables ubiquitous access to shared pools of configurable computing resources over the Internet, such as computational resources, storage resource, and software applications and services. Further, col. 9, ll. 61-ll. 4 of col. 10, In step 204, namespace health program 200 determines information corresponding to a storage device of a storage system. Information corresponding to a storage device may include a storage media type, a hardware architecture, a capacity, a date of manufacture, a manufacturer, a cumulative power-on duration, a cumulative number of write operations, and other information previously discussed above. In one embodiment, namespace health program 200 determines information corresponding to a storage device of a storage system based on obtaining information aggregated within storage system information 106).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include the apparatus wherein the processor is configured to identify a configuration file of the identified namespace which defines a type of the default storage classes and then inject an identifier of the defined type of the default storage class from the configuration file into the specification of the software application, as disclosed by Kazi, for the purpose to enables the centralized management of distributed resources (see col. 3, ll. 48-49 of Kazi).
As to claim 7, Dontu discloses the apparatus wherein the processor is configured to identify a different type of default storage class (col. 5, ll. 50-61, Storage system information 106 includes aggregated information related to plurality of storage systems within dispersed storage environment 100. In an embodiment, information related to a storage system may include the availability data, a physical (e.g., geographic) location, configuration information related to the storage system, etc. Configuration information related to a storage system may include an identifier, a network address, a global namespace [i.e. default storage class], one or more internal namespaces, one or more sub-namespaces, respective capabilities of storage 125-1 through 125-n, capabilities of other included hardware, installed/supported firmware and/or software, a file structure, etc. . Further, see col. 10, ll. 1-20 for attributes of the PVC) (col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like. Note: there are plurality of PVCs. Each PVC correspond / associated with specification. Any specification beside first specification is consider as second specification, and first and second are different type of default storage class than each other, see col. 9, ll. 53-55 for plurality of PVCs).
Nagar discloses deploy the second software application via a node within the identified namespace (par. 0075, the lattice definition module 604 receives application deployment information that will be used to construct a lattice model for lattice clustering. As a non-limiting example, an explanation detection module that includes the lattice definition module 604 may be used for providing explanations for anomalies that occur in a microservices application deployed on a container-based platform in a cloud infrastructure, such as microservices deployed on a Kubernetes platform (Kubernetes is a registered trademark of Google Inc.). In this example, the application is deployed in a namespace in a cluster that has nodes [i.e. identified namespace], where each node has pods, and the pods have containers, with each container being identified by a container identifier (container ID). … Note: applications [i.e. plurality of application] have multiple components spread across a distributed infrastructure. Thus, any application beside initial application is consider as second application, see par. 0017-0018).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include deploy the second software application via a node within the identified namespace, as disclosed by Nagar, for the purpose to deploy and manage applications in the host cluster. In embodiments, the container orchestrator is a Kubernetes platform that deploys and manages containerized applications in a cluster of VMs (see col. 2, ll. 46-49 of Nagar).
Kazi discloses that is assigned to the different namespace inject predefined storage attribute of the different type of default storage class (col. 8, ll. 56-61, Configuration information related to a storage system may include an identifier, a network address, a global namespace, one or more internal namespaces, one or more sub-namespaces, respective capabilities of storage 125-1 through 125-n, capabilities of other included hardware, installed/supported firmware and/or software, a file structure, etc.)
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include that is assigned to the different namespace inject predefined storage attribute of the different type of default storage class, as disclosed by Kazi, for the purpose of capabilities of other included hardware, installed/supported firmware and/or software, a file structure (see col. 5, ll. 60-61 of Kazi).
As to claim 10, it is a method claim, having similar limitations of claim 2. Thus, claim 10 is also rejected under the same rationale as cited in the rejection of claim 2.
As to claim 14, Dontu discloses the method wherein the method further comprises receiving, via the API, a second PVC with a second specification of a second software application to be hosted in a cluster (col. 9, ll. 53-56), and in response, (col. 9, ll. 53- ll. 20 of 10, In embodiments, PV-based objects 320 include persistent volumes (PVs), persistent volume claims (PVCs), and pods (e.g., Kubernetes PVs, PVCs, and pods). A PV is an object representing a persistent volume provisioned statically by an administrator/user or provisioned dynamically by container orchestrator 302 in response to a PVC. A PV includes a specification that defines a persistent volume and a status. The specification includes [i.e. inject] metadata, such as a name of the PV, a volume ID of a storage [i.e. storage class] volume 318 backing the PV, and optionally one or more labels associated with the PV. The specification further includes attributes of the PV, … The specification further includes attributes of the pod, such as containers and PVCs. PV-based objects 320 include container orchestrator (CO) metadata 314, which encompasses the various metadata discussed above for PVs, PVCs, and pods (e.g., names, labels, identifiers, etc.). Information in the labels can include, for example, a name of an application, a name of an instance of an application, an application version, an application component, and the like. Note: there are plurality of PVCs. Each PVC correspond / associated with specification. Any specification beside first specification is consider as second specification, and first and second are different type of default storage class than each other, see col. 9, ll. 53-55 for plurality of PVCs).
Kazi discloses in response, identifying a different namespace (col. 8, ll. 56-61, Configuration information related to a storage system may include an identifier, a network address, a global namespace, one or more internal namespaces, one or more sub-namespaces, respective capabilities of storage 125-1 through 125-n, capabilities of other included hardware, installed/supported firmware and/or software, a file structure, etc.)
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include identifying a different namespace, as disclosed by Kazi, for the purpose of capabilities of other included hardware, installed/supported firmware and/or software, a file structure (see col. 5, ll. 60-61 of Kazi).
As to claim 15, it is a method claim, having similar limitations of claim 7. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 7.
As to claim 18, it is a medium claim, having similar limitations of claim 2. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 2.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being obvious over Dontu et al. and Nagar aa applied to claims 1, 9 in the above and further in view of Whitehead et al (US 10929200 B1).
As to claim 5, Dontu discloses inject the predefined storage attributes via a control plane of the cluster (col. 3, ll. 28-35, the virtualized computing system includes an orchestration control plane comprising a container orchestrator having extensions that cooperate with the virtualization management server and agents installed in the virtualization layer. A host cluster having the orchestration control plane is referred to herein as a “supervisor cluster.” A user interacts with the orchestration control plane to deploy and manage applications executing on the supervisor cluster. Further, col. 12, ll. 47-57, master node software 505 comprises various control plane components executing on a guest operating system (e.g., as containers supported by a container runtime executing on Linux). In Kubernetes, for example, base master node software 505 comprises an API server (kube-api-server), a scheduler (kube-scheduler), a controller manager (kube-controller-manager), and the like. The base software of container orchestrator 502 is extended by storage control plane 507. In embodiments, storage control plane 507 includes synchronization software 304),
Dontu as modified by Nagar does not explicitly disclose the following limitation but,
Whitehead discloses the apparatus wherein the processor is configured to intercept the PVC via a handler of the API (col. 4, ll. 1-8, FIG. 3, read/write calls 302 made from container 102 and/or container 142 to persistent volumes 120-130 in file system 310 are intercepted by a function hook layer 306. In various embodiments, file system 310 can be a specialized file system. Application Programming Interface (API) Server 308 is used to create the persistent volumes 120-130 and also to satisfy PVCs 110-114 and PVCs 140-144 against real persistent volumes 120-130), and
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Dontu to include the apparatus wherein the processor is configured to intercept the PVC via a handler of the API, as disclosed by Whitehead, for the purpose to container 102 and/or container 142 is requesting to actually make use of the PVC (see col. 4, ll. 12-13 of Whitehead).
As to claim 13, it is a method claim, having similar limitations of claim 5. Thus, claim 13 is also rejected under the same rationale as cited in the rejection of claim 5.
Conclusion
11. Prior arts made of record are considered pertinent to applicant's disclosure. See MPEP § 707.05 (C) For Examples:
I. Alluboyina et al. (US 20250321783 A1) discloses: “The system 400 includes a cluster 200, such as the cluster first illustrated in FIG. 2. The cluster 200 includes a namespace 402. Several compute nodes 102 are bound to the namespace 402, and each compute node 102 includes a pod 404 and a persistent volume claim 408. In the example illustrated in FIG. 4, the namespace 402 is associated with three compute nodes 102a, 102b, 102n, but it should be appreciated that any number of compute nodes 102 may include within the cluster 200. The first compute node 102a includes a first pod 404a and a first persistent volume claim 408a that draws upon a first persistent volume 410a. The second compute node 102b includes a second pod 404b and a second persistent volume claim 408b that draws upon a second persistent volume 410b. Similarly, the third compute node 102n includes a third pod 404n and a third persistent volume claim 408n that draws upon a third persistent volume 410n. Each of the persistent volumes 410b may draw from a storage node 416. The cluster 200 executes tasks 406 that feed into the compute nodes 102 associated with the namespace 402.” (please see [0046]).
II. Rosoff et al. (IDS provided)(US 20210311792 A1) discloses: “An application executing in the computing system can include multiple parts referred to herein as “workloads.” Each workload can be implemented using one or more compute objects, such as virtual machines (VMs) and/or containers, as well as associated support objects, such as storage resources and networking resources. As noted above, managing these workloads and constituent objects individually is labor intensive and error prone. The techniques described herein simplify management of modern applications by grouping all objects of the application workloads together within a namespace for the supervisor cluster referred to as a “supervisor namespace.” The supervisor namespace is a shared abstraction between application developers (e.g., users) and infrastructure managers (e.g., VI admins). A VI admin creates “supervisor namespaces” within the supervisor cluster control plane, which provide resource-constrained and authorization-constrained units of multi-tenancy. Users deploy their applications within the scope of the supervisor namespaces and subject to their constraints. In this manner, the user guarantees that all the resources they deploy as part of their application are contained within the same supervisor namespace. The VI admin sees the application and its components in the supervisor namespace as a single unit. The VI admin can perform operations at the supervisor namespace level, the results of which are applied automatically across all resources of the application. These and further advantages and aspects of the disclosed architecture are described below with respect to the drawings.” (please see [0018]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammad Kabir whose telephone number is (571)270-13411. The examiner can normally be reached on M-F, 8:00 am - 5:00 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sam Sough can be reached on (571) 272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohammad Kabir/
Examiner, Art Unit 2192
/S.SOUGH
spe, art unit 2192