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 .
This action is responsive to the Applicant’s amendments filed on 09/30/2025. Claims 1-20 remain pending in the application. Claims 1, 8, and 15 have been amended. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Objections
Claims 1-7 are objected to because of the following informalities: in claim 1, “creating, by the first operator and response to generation of the first custom resource…” as amended suggests that “response to generation” is an additional actor performing the creation alongside the first operator, which is nonsensical. For the purposes of examination, the Examiner assumes “and in response to generation” is intended.
Any claim not explicitly mentioned above is objected to due to dependency on an objected claim.
Appropriate correction is required.
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-2, 5, 7, 8-9, 12, 14-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Miriyala et al. (US 20240095158 A1) hereafter referred to as Miriyala, in view of Henkel et al. (US 20240073087 A1) hereafter referred to as Henkel, further in view of Mansour et al. (US 11561802 B2) hereafter referred to as Mansour.
Regarding claim 1, Miriyala teaches:
generating, in the container-based cluster, a first custom resource for the product, the first custom resource representing a deployment and runtime configuration of the product, wherein the first custom resource defines a deployment specification for each of the plurality of microservices of the product (Paragraph 74; the generation of interface configuration data for virtual network interfaces for the pod corresponds to the applicant’s generation of a first custom resource for the product in a container-based cluster representing a deployment and runtime configuration of the product, defining a deployment specification).
Miriyala does not teach creating, by the first operator and in response to generation of the first custom resource, a corresponding second custom resource for an instance of the product based on the deployment specification defined for the instance in the first custom resource
However, Henkel teaches:
creating, by the first operator and in response to generation of the first custom resource, a corresponding second custom resource for an instance of the product based on the deployment specification defined for the instance in the first custom resource (Paragraph 170; where the creation of appropriate SDN architecture objects by a SDN controller manager corresponds to the applicant’s creating, by the first operator, a corresponding second custom resource. A person of ordinary skill in the art would recognize that the architecture objects are custom resources as they are extensible, defined outside native system primitives, and used by a controller to manage deployment lifecycles. Creating a corresponding instance of a custom object based on the configuration data for a particular custom resource corresponds to the applicant’s creating a resource for each instance. Further, Paragraph 152 discloses “In the case that API request is a create request for a custom resource, reconciler 816 can act on the create event for the instance data for the custom resource. Reconciler 816 may create instance data for custom resources that the requested custom resource depends on. As an example, an edge node custom resource may depend on a virtual network custom resource, a virtual interface custom resource, and an IP address custom resource”, where the creation of a second custom resource is triggered by the generation of the first custom resource. Paragraphs 34-35 confirm that these steps may occur in a Kubernetes environment.);
Miriyala and Henkel are considered to be analogous to the claimed invention because they are in the same field of resource management in Kubernetes. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Miriyala with Henkel to create a corresponding second custom resource for an instance of a product based on a deployment specification in the first custom resource. This would facilitate modular resource generation which would allow automatic instantiation of configurations dependent on the passed custom resource defined by unique service requirements.
Miriyala in view of Henkel does not teach the action taken is deployment, that the created custom resources are microservices that are to be deployed, that the first custom resource represents a deployment/runtime configuration defining a deployment specification for each microservice, that the custom resources are for microservices, that the first custom resource is for a product, that the second custom resource is created for each microservice of the product based on deployment specifications for each microservice, using a second operator to detect created custom resources for each microservice, and deploying each of the microservices based on the second custom resources.
However, Mansour teaches:
the action taken is deployment (Col. 5, lines 18-27; the deployment of microservices based on the microservice CRD teaches the deployment action);
the created custom resources are associated with microservices to be deployed (Col. 5, lines 18-27; the use of microservice CRDs and associated config binding CRDs correspond to a plurality of custom resources that are used to deploy an instance of a microservice);
a first custom resource represents microservice deployment/configuration specifications for each microservice (Col. 5, lines 18-27; where the deployment of a microservice in accordance with the microservice CRD that is transformed into low-level steps and resources to provision the microservice corresponds to the applicant’s first custom resource representing microservice deployment/configuration specifications. A person of ordinary skill in the art would recognize that it would be obviously extensible to apply this idea to each microservice);
the first custom resource is for a product (Col. 4, Table 1, line 2; where the first custom resource is associated with a microservice identity, and each microservice is associated with a product);
creating, by the first operator in response to generation of the first custom resource, a second custom resource for each microservice based on the first custom resource (Col. 5, lines 18-27; the lifecycle uses both the microservice CRD and the config binding CRD to deploy a microservice with a specific configuration. A person of ordinary skill in the art would understand that the second custom resource, the config binding CRD, is created or generated in a manner that must be informed by the first custom resource as the configuration and deployment behavior are derived from the definition of the microservice);
the second custom resource is created for a plurality of microservices (Col. 5, lines 18-27; where the deployment of a microservice in accordance with the config binding CRD associated with the microservice CRD that is transformed into low-level steps and resources to provision the microservice corresponds to the applicant’s second custom resource for a microservice. A person of ordinary skill in the art would recognize that it would be obviously extensible to apply this idea to each microservice.);
and deploying, in response to creation of the second custom resource, each of the plurality of microservices in the container-based cluster based on the second custom resources (Col. 5, lines 18-27; config binding CRDs, corresponding to the applicant’s second custom resource, contains configuration details specific to microservice deployment. The lifecycle operator uses the second custom resource to deploy and manage microservices, corresponding to deploying microservices based on a second custom resource. Col. 7 lines 10-14 disclose “In the case that API request is a create request for a custom resource, reconciler 816 can act on the create event for the instance data for the custom resource. Reconciler 816 may create instance data for custom resources that the requested custom resource depends on. As an example, an edge node custom resource may depend on a virtual network custom resource, a virtual interface custom resource, and an IP address custom resource” and Col. 7 lines 34-38 disclose “the lifecycle operator invokes additional operators based on the microservice CRD. The lifecycle operator can output resources required by the additional operators to perform one or more tasks contributing to the management of the lifecycle of the microservice” together show that the creation of a second custom resource results in further action taken.).
Miriyala, Henkel, and Mansour are considered to be analogous to the claimed invention because they are in the same field of resource management in Kubernetes. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Miriyala in view of Henkel with Mansour to have the action taken being deployment, to have the created custom resources be associated with microservices to be deployed, to have a first custom resource representing microservice deployment/configuration specifications for each microservice, to have the first custom resource associated with a product, to create a second custom resource for each microservice based on the first, to have the second custom resource created for a plurality of microservices, and to deploy each microservice in the container-based cluster based on the second custom resources. A person of ordinary skill in the art would have been motivated to make these combinations in order to implement declarative design principles where specifications within custom resources serve as specifications for the instantiation of necessary sub-components of microservices, to enhance modularity by defining product logic in reusable custom resources, and to support scalability.
Claim 8 contains the same limitations as claim 1, additionally reciting one or more processors and at least one memory, directed towards a system. Mansour teaches:
one or more processors (Col. 11, lines 35-38);
and at least one memory (Col. 10, lines 21-23).
Claim 8 is rejected for similar reasons as claim 1.
Claim 15 contains the same limitations as claim 1, additionally reciting a non-transitory computer-readable medium comprising instructions, directed towards an apparatus. Mansour teaches:
a non-transitory computer-readable medium comprising instructions (Col. 10, lines 31-37).
Claim 15 is rejected for similar reasons as those of claim 1.
Regarding claim 2, Miriyala in view of Henkel, further in view of Mansour teach the method of claim 1. Mansour teaches:
determining, by the first operator, that the deployment specification for at least one microservice of the plurality of microservices defined in the first custom resource has been modified (Col. 5, lines 42-52; the ability of the lifecycle operator to bounce microservice pods in response to changes in config maps/bindings means the operator must monitor/detect changes to deployment specifications. Because the config binding CRD, associated with microservice deployment of a specific microservice, is a custom resource related to deployment configuration, determining modifications thereof corresponds to the claimed step of detecting changes in the deployment spec of at least one microservice);
and updating the corresponding second custom resource for the at least one microservice based on the modified deployment specification (Col. 5, lines 42-52; the bounce behavior means the lifecycle operator detects configuration changes and ensures that the deployed microservices conforms to updated specs. To do so, the system would be required to update the associated config binding CRD to reflect modified deployment specifications before bouncing the pod).
Claim 9 contains the same limitations as those of claim 2, directed towards a system. Claim 9 is rejected for similar reasons as those of claim 2.
Claim 16 contains the same limitations as those of claim 2, directed towards an apparatus. Claim 16 is rejected for similar reasons as those of claim 2.
Regarding claim 5, Miriyala in view of Henkel, further in view of Mansour teach the method of claim 1. Mansour teaches:
wherein the second custom resource for each of the plurality of microservices of the product provides instructions for deploying the corresponding microservice (Col. 5, lines 18-27, Col. 5, lines 52-55, Table 4; where the config binding CRD corresponds to the applicant’s second custom resource that may exist in a 1:1 ratio, corresponding to the applicant’s custom resource for each microservice, in a possible embodiment of Mansour. The config binding CRD is used alongside the microservice CRD to provide instructions for deploying a corresponding microservice, corresponding to the applicant’s providing instructions for deploying the corresponding microservice).
Claim 12 contains the same limitations as those of claim 5, directed towards a system. Claim 12 is rejected for similar reasons as those of claim 5.
Claim 19 contains the same limitations as those of claim 5, directed towards an apparatus. Claim 19 is rejected for similar reasons as those of claim 5.
Regarding claim 7, Miriyala in view of Henkel, further in view of Mansour teach the method of claim 1. Miriyala teaches:
wherein the container-based cluster is a set of one or more containers of one or more pods running on one or more nodes (Paragraph 65; the disclosure of Kubernetes would allow a person of ordinary skill in the art to recognize the applicant’s limitation as obvious. Kubernetes is a widely known container orchestration platform in which a Kubernetes-based cluster by definition is composed of one or more containers within one or more pods deployed on one or more nodes. The use of such a system design is predictable and well known to a person of ordinary skill).
Claim 14 contains the same limitations as those of claim 7, directed towards a system. Claim 14 is rejected for similar reasons as those of claim 7.
Claims 3-4, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Miriyala in view of Henkel, further in view of Mansour, further in view of Fox et al. (US 20220191234 A1) hereafter referred to as Fox.
Regarding claim 3, Miriyala in view of Henkel, further in view of Mansour teach the method of claim 1. Mansour teaches:
a first custom resource comprising parameters defined for a corresponding microservice (Col. 4, Table 1, line 2; where the first custom resource contains a plurality of parameters and is associated with a microservice identity).
Miriyala in view of Henkel further in view of Mansour does not teach that the custom resource comprises an apps field for each of the plurality of microservices.
However, Fox teaches:
the custom resource comprises an apps field for each of the plurality of microservices (Paragraph 51; where the custom property added to the specification is functionally the same as the “apps field”. It would be routine and obvious to extend the functionality from a singular microservice to a plurality thereof. Data points mapped to the microservice request body corresponding to rules of the server correspond to the applicant’s parameters defined for a corresponding microservice).
Miriyala, Henkel, Mansour, and Fox are considered to be analogous to the claimed invention because they are in the same field of resource management in orchestration systems. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Miriyala in view of Henkel further in view of Mansour with Fox to have the custom resource comprise an apps field for each microservice. This would allow a single controller to parse and act on deployment specifications for a product rather than requiring separate resource controllers for each individual microservice.
Claim 10 contains the same limitations as those of claim 3, directed towards a system. Claim 10 is rejected for similar reasons as those of claim 3.
Claim 17 contains the same limitations as those of claim 3, directed towards an apparatus. Claim 17 is rejected for similar reasons as those of claim 3.
Regarding claim 4, Miriyala in view of Henkel, further in view of Mansour, further in view of Fox teach the method of claim 3. Miriyala teaches:
wherein the parameters comprise at least one of: a name of the corresponding microservice, a namespace where the corresponding microservice is to be deployed, a name of an image package bundle to be used for deploying the corresponding microservice, a registry tag associated with the image package bundle, a name of a helm chart for the corresponding microservice, a namespace to be provided for rendering the helm chart, a namespace where resources for the corresponding microservice are to be deployed, an indication that the corresponding microservice is an operator, a deployment time override, an indication that the second custom resource created for the corresponding microservice is to be deleted during an upgrade to the first custom resource, or an indication of a period of time to wait for deployment of the corresponding microservice (Paragraph 61; teaching the following elements: namespace where the microservice is to be deployed, and namespace where resources for the microservice are to be deployed).
Claim 11 contains the same limitations as those of claim 4, directed towards a system. Claim 11 is rejected for similar reasons as those of claim 4.
Claim 18 contains the same limitations as those of claim 4, directed towards an apparatus. Claim 18 is rejected for similar reasons as those of claim 4.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Miriyala in view of Henkel, further in view of Mansour, further in view of Rodriguez et al. (US 20220171648 A1) hereafter referred to as Rodriguez.
Regarding claim 6, Miriyala in view of Henkel, further in view of Mansour teach the method of claim 1. Miriyala in view of Henkel further in view of Mansour does not teach that the container-based cluster is running in an air-gapped environment.
However, Rodriguez teaches:
wherein the container-based cluster is running in an air-gapped environment (Paragraph 70; the secure immutable container hosting environment achieved by hardware root of trust capabilities that is made immutable by the tent, orchestrator, or container, utilizing attestation and appraisal mechanisms would cause a person of ordinary skill in the art to understand that this type of tightly controlled environment provides the same security assurances and operational characteristics as an air-gapped environment).
Miriyala, Henkel, Mansour, and Rodriguez are considered to be analogous to the claimed invention because they are in the same field of resource management in container-based cluster systems. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Miriyala in view of Henkel further in view of Mansour with Rodriguez to have the container-based cluster run in an air-gapped environment. A person of ordinary skill in the art would have been motivated to do so to enable enhanced security, trust, and policy enforcement in environments that necessitate high security standards, such as backend payment processing or hospital systems.
Claim 13 contains the same limitations as those of claim 6, directed towards a system. Claim 13 is rejected for similar reasons as those of claim 6.
Claim 20 contains the same limitations as those of claim 6, directed towards an apparatus. Claim 20 is rejected for similar reasons as those of claim 6.
Response to Arguments
Applicant's arguments filed 09/30/2025 have been fully considered but some are not persuasive. Applicant’s arguments are summarized below:
Amendments to independent claims 1, 8, and 15 overcome the rejections under 35 U.S.C. 101.
Miriyala fails to teach or suggest a first custom resource.
Henkel fails to teach or suggest the claimed limitation of creating a second custom resource in response to an event on a first custom resource and does not teach a “custom resource”.
Mansour does not disclose “a deployment specification for each of the plurality of microservices of the product” as recited in claim 1.
Dependent claims are submitted as allowable for at least the above reasons.
The Examiner respectfully disagrees with points B, C, D, and E.
With regard to independent claims 1, 8, and 15, the claims as amended do not recite an abstract idea. Therefore, the 101 analysis of the independent claims ends at step 2A, prong one, with a conclusion of eligibility. Accordingly, the rejections of claims 1-20 under 35 U.S.C. 101 are withdrawn.
Miriyala explicitly identifies custom resources as Kubernetes objects used to declaratively define and manage system components. Paragraph 28 discloses “The SDN architecture… provides a declarative way of resources using aggregation APIs for SDN architecture objects (i.e. custom resources).” Paragraph 7 further discloses that Miriyala operates within a Kubernetes orchestration environment. The particular cited Paragraph 74 on record discloses the configuration data for VNIs is generated and managed by the orchestrator and network controller, “network controller 24 processes the request to generate interface configuration data for virtual network interfaces for the pod 22” which would be recognized by a PHOSITA as constituting a “custom resource” based on the broadest reasonable interpretation in light of the specification, which defines a custom resource as “one type of object used in Kubernetes to define the state of the Kubernetes cluster, includes custom resource definition (CRD) objects (also referred to herein as a “custom resources (CRs)”)” (Paragraph 7). Therefore, contrary to Applicant’s arguments, Miriyala teaches or at least suggests a first custom resource.
Henkel teaches the functionality of a second custom resource as a response to a first custom resource as evidenced by the cited Paragraph 170: “in response to detecting an event on an instance of a custom resource, control node 232 obtains configuration data… and configures a corresponding instance of a configuration object”, where the SDN architecture objects created are “defined as custom resources for SDN architecture configuration”. The term “configuration object” is therefore disclosed as a custom resource that would be recognized by a PHOSITA as being implemented under Kubernetes as further evidenced by Paragraph 15, “An SDN architecture system with native Kubernetes integration”, consistent with the definition of “custom resource” based on the broadest reasonable interpretation in light of the specification, which defines a custom resource as “one type of object used in Kubernetes to define the state of the Kubernetes cluster, includes custom resource definition (CRD) objects (also referred to herein as a “custom resources (CRs)”)” (Paragraph 7). With regard to performing the action in response to generation of the first custom resource, Henkel further elaborates on the custom resources in that “in the case that API request is a create request for a custom resource, reconciler 816 can act on the create event… for the custom resource” (Paragraph 152) and “may create instance data for custom resources that the requested custom resource depends on”. Thus, Henkel teaches that the second custom resource is created in response to a create event for a custom resource, corresponding to responsive to generation of a first custom resource. Therefore, contrary to Applicant’s arguments, Henkel teaches or at least suggests a second custom resource created in response to the creation of a first custom resource.
With regard to Applicant’s argument that “Table 1 uses the term “Product,” but Mansour never again uses that term”, Mansour explicitly teaches that a CRD is “provided for each microservice (MS1-MSN)” (Paragraph 25) and the CRD provides a description of the microservice which includes the product attribute as evidenced by Table 1 “Microservice identity (name, version, domain, product)”. Given that information, a PHOSITA would recognize that each and every microservice is associated with a product and has a corresponding CRD that defines its deployment specification. Therefore, contrary to Applicant’s arguments, Mansour teaches or at least suggests “a first custom resource defines a deployment specification for each of the plurality of microservices of the product”.
Independent claims 1, 8, and 15 remain rejected for the reasons stated above. Therefore, contrary to Applicant's arguments, because the dependent claims depend from an unpatentable claim and does not add limitations that overcome the rejection, it likewise remains rejected.
Accordingly, the rejections under 35 U.S.C. 103 are maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Miriyala et al. (US 20230107891 A1) discusses deploying sets of microservice components to compute nodes for microservice-based applications by utilizing an API request to create a custom resource to act upon. The authors further discuss creation and tracking the status of custom resources from which edge node configuration relies upon.
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 KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 5:30 a.m. - 2 p.m. PT, F 5:30 a.m. - 9:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
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, April Blair can be reached at (571) 270-1014. 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.
/KENNETH P TRAN/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196