Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
2. Claims 3, 10, and 17 are objected to because of the following informalities: the term “an” should be changed to “a”. Appropriate correction is required.
Response to Arguments
3. Applicant’s arguments with respect to claim(s) 1, 8, 15, 6, 13, and 20 have been 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.
4. Regarding claims 2, 9, and 16, the Applicant argues that a container image and a docker compose YAML file is not a “specification for the custom resource” as recited in the claims. The Applicant also states that Waterman is directed to deploying retail GUI applications… using containerized server-side rendering; not the same field of endeavor nor is it reasonably pertinent to the problem of generating custom resource specifications.
In response to applicant's argument that Waterman is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Waterman was used to show that the resource CRUD container image generated may be represented as a YAML file, combined with the teaching of RUDRARAJU where the image was created from the resource file and the controller file as taught in RUDRARAJU [0068-0070].
5. The Applicant further argues that Kerr’s teaching of a CRD specification is directed towards a “node management custom resource” and not a CRD defining the structure of a custom resource to be managed by an operator.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Kerr was used to teach a deployment configuration including a custom resource definition (CRD) specification, not what the CRD is directed towards. As RUDRARAJU [0107 – Table 4] teaches of a custom resource operator code, which contains a CRD corresponding to the custom resource operator. Combined with Kerr, it teaches the limitation of “wherein the first YAML file includes a custom resource definition corresponding to the custom resource”.
6. Regarding claims 3, 10, and 17, Applicant argues that “Shmulevich is directed to an entirely different technical domain. Shmulevich's "Template Based Software Container" is about assembling enterprise Java applications from pre-built software components using Maven dependency templates. The "container" in Shmulevich's title refers to a Java/OSGi application container - not a Docker or Kubernetes container. Shmulevich's templates are build-time Maven POM XML files that list JAR dependency coordinates (groupid, artifactld, version) for downloading and bundling Java software packages. Shmulevich, col. 10, II. 55-67; col. 11, II. 25-45. These dependency lists do not have "fields" that "map to" identified Kubernetes objects (such as deployments, services, or secrets) or runtime configuration parameters. They are simply lists of software packages to be assembled at build time. Shmulevich does not mention Kubernetes, container orchestration, operators, custom resources, custom resource definitions, or declarative infrastructure specifications. There is no reasonable basis for concluding that a POSITA would look to a Java application dependency management system to address the problem of generating Kubernetes custom controller specifications - these are entirely different fields of endeavor addressing entirely different problems.”
In response to applicant's argument that Shmulevich is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, the claim limitation states “generating the specification of the custom controller is further based on a custom controller template comprising one or more fields wherein each of the one or more fields maps to at least one of the identified one or more objects or at least one of the one or more parameters”, the claimed language having no mention of a specific type of controller template framework such as Kubernetes as argued by the applicant. As taught by Shmulevich, it would have been obvious to one of ordinary skill in the art before the effective filing date to implement a template-based container generation feature with the teachings of RUDRARAJU to teach the claimed limitation.
7. Regarding claims 6, 13, and 20, the amended claim 1 has changed the scope of the claims as the custom controller that is instantiated from the container image is that of a default operator image and then configured by the specification, to a specified container image. As such, the argument is 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.
8. Regarding claims 7 and 14, the Applicant argues that “operator processes 24-1 and 24-2 are the same operator at two different versions in an upgrade context – version 1 and version 2 of a single operator. This is not “managing a plurality of custom controllers” as recited in the claims. The Operator Lifecycle Manager (OLM) in Gallagher manages the upgrade lifecycle of operators, not a portfolio of independently created and deployed custom controllers. Applicant's arguments filed have been fully considered but they are not persuasive. Examiner clarifies that Gallagher [0037] teaches an Operator Lifecycle Manager that can install, update, and manage the lifecycle of operators such that when combined with the newly deployed operators of RUDRARAJU, it would meet the limitation disclosed in claim 7 “managing a plurality of custom controllers”. Though not explicit, Gallagher implies that it can manage multiple operators at once as in the CSV files of [0037], it specifies an operator to be upgraded (e.g. etcd-operator) such that an operator must be selected from the one or more installed operators.
Claim Rejections - 35 USC § 103
9. 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.
10. Claims 1, 4, 5, 8, 11, 12, 15, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over RUDRARAJU et al. Pub. No. US 2022/0012045 A1 (hereafter RUDRARAJU) in view of Cherny et al. Pub. No. US 2020/0082071 A1 (hereafter Cherny).
11. With regard to claim 1, RUDRARAJU teaches a method for automatically creating a custom controller for a container-based cluster comprising ([0063] FIG. 2 shows a context diagram that shows how a Custom Resource Abstraction and Fabrication Tool (CRAFT) is used to automatically create an operator that can be used to deploy an application, in accordance with embodiments), receiving input identifying one or more objects to include as part of a custom resource, the custom resource being an object deployable in a container-based cluster ([0068] In FIG. 2, a Custom Request 202 may be identified that includes requirements that may reflect business logic, operational requirements, business rules such as defining authorizations for access or for other resources based upon a type of a user for custom resource components that make up the deployed application/service. Based upon the Custom request 202, one or more custom resource components 204 are identified. In this example, custom resource components 204 may include a controller file 206, a resource file 208, and a resource container file 210 [0065] An example of a built-in resource is a pod. A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications.); receiving, for each of the one or more objects, a configuration of corresponding one or more parameters of the object; generating, based on the input and the configuration, a specification of a custom controller configured to manage the custom resource; generating, based on the input and the configuration, a specification for the custom resource ([0069] The controller file 206 may be written in a suitable markup language such as XML, JSON (e.g., as shown by Table 1a infra), YAML, and/or some other markup and/or serialization language. The controller file 206 may include CRD information such as group, domain, operator image, and reconciliation frequency. The resource file 208 may be written in XML, JSON (e.g., as shown by Table 2 infra) YAML, and/or some other markup and/or serialization language. The resource file 208 may include schema information for validating inputs while creating a CRD. The resource container file 210 is then built that holds all service dependency files such as packages, data files, and other application-specific files. The resource container file 210 may also contain logic for managing the CRUD resources. In one example, the resource container file 210 may be a Docker® container file or the like. [0070] CRAFT 212 may then be implemented to take as input the controller 206, resource 208, and resource container file 210, and create a deployment set of files 214. These files include the Operator file {Specification of custom controller} 216, Operator container image 218, and resource CRUD container image 220 {Specification of custom resource} [0090] In the example of FIG. 2, this controller container image may be the resource CRUD container image 220 [0107] Table 4 shows an example of automatically generated custom resource operator code {within the operator file} that can be used to deploy an application, in accordance with embodiments. In the example of Table 4, the control plane is a container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers); and deploying the custom controller and the custom resource in a first container-based cluster using the specification of the custom controller and the specification of the custom resource ([0120] Process 500B begins at operation 512 where an app server 100 receives a request to generate an application for providing a service. The request includes (e.g., in a request message) or indicates (e.g., includes suitable resources or identifiers) one or more configurations. The one or more configurations indicate application requirements for the application that is to be generated. At operation 514, the app server 100 generates, using the one or more configurations, each of an operator file 216, an operator container image 218, and a controller container image 220. At operation 516, the app server 100 deploys an operator into a computing cluster using information contained in the operator file 216. This may include creating (or building) a container on a computing cluster using the operator container image and the controller container image, and deploying the operator into the container using information contained in the operator file 216. The operator includes code to perform one or more operations according to the application requirements indicated by the one or more configurations. Also see [0096]-[0100] for additional details).
However, RUDRARAJU may not explicitly teach the new limitations of the claim.
Cherny teaches “wherein the custom controller is instantiated from a default operator image and configured based on the specification of the custom controller ([0017] Multiple ones of the container images 14 may share a same “base image.” A base image is a container image 14 that serves as a foundation upon which additional files/layers can be added to create a final container image 14. Thus, a plurality of the container images 14 may originate from a common base image).”
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Cherny with the teachings of RUDRARAJU in order to show that the operator container image can be created from modified base images. The motivation for applying Cherny’s teaching with RUDRARAJU’s teaching is to provide for flexible customization of custom controller container images. Together, Cherny and RUDRARAJU teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of the invention, one of ordinary skill could have applied the teachings of Cherny with the teachings of RUDRARAJU by known methods and gained expected results.
12. Claim 8 has similar limitations to claim 1 and is rejected for similar reasons. Claim 8 is directed towards a system comprising: one or more processors; and at least one memory, the one or more processors and the at least one memory ([0127] one or more processors… stored as a computer- or processor-executable instructions or commands on a physical non-transitory computer-readable medium).
13. Claim 15 has similar limitations to claim 1 and is rejected for similar reasons. Claim 15 is directed towards One or more non-transitory computer-readable media comprising instructions ([0127] The software code can be stored as a computer- or processor-executable instructions or commands on a physical non-transitory computer-readable medium) that, when executed by one or more processors of a computing system, cause the computing system to perform operations for deploying a product having a plurality of microservices in a container-based cluster, ([0017] FIG. 1A shows an example of an environment 10 in which on-demand services (e.g., cloud computing services and/or database services) can be used in accordance with various embodiments. The environment 10 includes user systems 12, a network 14, system 16 (also referred to herein as a “cloud-based system,” “database system,” “cloud computing service,” or the like), and one or more customer platforms (CPs) 50. The cloud system 16 includes a processor system 17, an application platform 18, a network interface 20, tenant database (DB) 22 for storing tenant data 23 (see e.g., FIG. 1B), system DB 24 for storing system data 25 (see FIG. 1B), program code 26 for implementing various functions of the system 16, and process space 28 for executing DB system processes and tenant-specific processes, such as running applications as part of an application hosting service. In some other implementations, environment 10 may not have all of these components or systems, or may have other components or systems instead of, or in addition to, those listed above).
14. With regard to claim 4, RUDRARAJU teaches wherein deploying the custom controller and the custom resource comprises applying the specification of the custom controller and the specification of the custom resource to the first container-based cluster via an API server of the first container- based cluster ([0054] In some implementations, each application server 100 is configurable or operable to handle requests for any user associated with any organization that is a tenant of the system 16. [0066] The API server may be implemented or operated by an app server 100 discussed previously. [0120] At operation 516, the app server 100 deploys an operator into a computing cluster using information contained in the operator file 216. This may include creating (or building) a container on a computing cluster using the operator container image and the controller container image, and deploying the operator into the container using information contained in the operator file 216. [0070] CRAFT 212 may be run via kubectl, which is a command line tool for communicating with an API server such as a Kubernetes API server. [0096] Sixth, deploy the operator to a cluster. After completing the setup (e.g., the previously described first through fifth steps), the operator can be deployed to the cluster. First, a namespace is created in the cluster using the following command: [0097] kubectl apply -f<path-to-namespace.yaml>). Here shows the app server operating the API server to deploy the operator. A more detailed example shows using a command line tool to communicate with the API server to deploy the operator.
15. Claim 11 has similar limitations to claim 4 and is rejected for similar reasons.
16. Claim 18 has similar limitations to claim 4 and is rejected for similar reasons.
17. With regard to claim 5, RUDRARAJU teaches wherein the one or more objects include one or more of a deployment, a service, or a secret ([0069] The resource container file 210 is then built that holds all service dependency files such as packages, data files, and other application-specific files. The resource container file 210 may also contain logic for managing the CRUD resources [103] The various elements in the controller file 206 are defined … It also includes the location of … a vault address of where the secrets are to be pulled (“registrycredential”) for application security during operation).
The claim uses selection language such as “or” meaning it may be one of the three object types, deployment, service, or secret.
18. Claim 12 has similar limitations to claim 5 and is rejected for similar reasons.
19. Claim 19 has similar limitations to claim 5 and is rejected for similar reasons.
20. Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over RUDRARAJU and Cherny as applied to claims 1, 8, and 15 above, and in further view of Waterman Pub. No. US 2024/0330025 A1 (hereafter Waterman) and Kerr et al. Pub. No. US 2024/0220227 A1 (hereafter Kerr).
21. With regard to claim 2, RUDRARAJU teaches wherein the specification of the custom controller is a first YAML file ([0070] As examples, the Operator file 216 may be generated in XML, JSON, YAML, and/or some other suitable format) and the specification of the custom resource is an image ([0070] … resource CRUD container image 220 may be … a resource CRUD Docker® image); wherein a controller file includes a CRD which is then used to generate the first YAML file ([0084] CRAFT 212 uses the controller file 206 (e.g., controller, json) and the resource file 208 (e.g., resource.json) to develop the operator template and the operator metadata to build the operator images (e.g., images 218 and/or 220) and deploy the operator on the cluster. In embodiments, the operator template and the operator metadata are stored in the operator file 216 (e.g., operator.yaml). [0121] The controller file 206 may include a custom resource definition (CRD) [0119] CRAFT 212 combines the data in the controller file 206, the resource file 208, and the resource container file 210 to produce the operator file 216).
RUDRARAJU does not explicitly teach that the image being specified by a YAML file; and the first YAML file includes a custom resource definition corresponding to the custom resource.
However, Waterman teaches that an image may be specified as a YAML file ([0069] a container image (docker compose YAML file) is created. It will be appreciated that in other embodiments, the docker compose YAML file may be replaced by any standardized application definition file).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply the teachings of Waterman to RADRARAJU to show that the a container image may be a YAML file. A person having ordinary skill in the art would have been motivated to make this substitution for the purpose of configuration preference and compatibility.
RUDRARAJU as modified by Waterman does teach of a custom resource definition in [RUDRARAJU 0107], though not explicit.
Kerr also teaches a deployment configuration including a CRD such that the first YAML file includes a custom resource definition corresponding to the custom resource ([0039] The deployment configuration may include a custom resource definition specification).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply the teachings of Kerr to RUDRARAJU to show as evidence, that the operator file of RUDRARAJU may include a CRD. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of allowing an operator to define the custom resource within the container. Together, Kerr in combination with RUDRARAJU and Waterman, teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied said teachings to achieve expected results.
23. Claim 9 has similar limitations to claim 2 and is rejected for similar reasons.
24. Claim 16 has similar limitations to claim 2 and is rejected for similar reasons.
25. Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over RUDRARAJU as applied to claims 1, 8, and 15 above, and in further view of Shmulevich et al. Pat. No. US 9,646,064 B2 (hereafter Shmulevich).
26. With regard to claim 3, RUDRARAJU teaches wherein generating the specification of the custom controller is further based on an custom controller template comprising one or more fields ([0072] In embodiments, CRAFT 212 uses the controller file 206 and resource file 208 to develop the operator template and the operator metadata that are both stored in Operator file 216 to build the operator Container image 218 and Resource CRUD Container Image 220. The operator template holds information about the controllers, reconcilers, and configurations such as web hooks, Role-Based Access Control (RBAC) for clusters, and the like. The operator template also stores the application package, such as a “main, go” file in Golang. The operator template also stores operator variables such as, for example, reconciliation frequency, resource manager, CRUD operations deployment, and the like. Also see [0101]).
RUDRARAJU does not explicitly teach that the one or more fields of the template maps to at least one of the identified one or more objects or at least one of the one or more parameters.
Shmulevich teaches generating a deployment specification based upon a profile, parameters, and an application specification file such that generating the specification of the custom controller is further based on an custom controller template comprising one or more fields, wherein each of the one or more fields maps to at least one of the identified one or more objects or at least one of the one or more parameters ([Col. 10, lines 58-67] Templates 108 identify different groups of software components for building different software applications and services. For example, template 108A may identify software components for building a UI tier application and template 108B may identify software components for building a headless application template. Template 108C may identify software components for building a lower tier service used in either template 108A or 108B. Also see columns 11 & 12 for more detail).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply the teachings of Shmulevich to RUDRARAJU to show that the operator file may be generated based upon a template that maps the parameters to the fields. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of automating the generation process. Together, Shmulevich in combination with RUDRARAJU, Kerr, and Waterman, teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied said teachings to achieve expected results.
27. Claim 10 has similar limitations to claim 3 and is rejected for similar reasons.
28. Claim 17 has similar limitations to claim 3 and is rejected for similar reasons.
29. Claims 6, 7, 13, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over RUDRARAJU and Cherny as applied to claims 1, 8, and 15 above, and in further view of Gallagher et al. Pub. No. 2024/0362078 A1 (hereafter Gallagher).
30. With regard to claim 6, RUDRARAJU teaches wherein the specification of the custom controller specifies a container image for the custom controller ([0120] At operation 516, the app server 100 deploys an operator into a computing cluster using information contained in the operator file 216. This may include creating (or building) a container on a computing cluster using the operator container image and the controller container image, and deploying the operator into the container using information contained in the operator file 216).
RUDRARAJU does not explicitly teach instantiating a custom controller from its custom controller image.
Cherny teaches instantiation of a container from container images such that it teaches the limitation “wherein deploying the custom controller comprises instantiating the custom controller from the container image for the custom controller ([0015-0017] teaches of a container image repository containing container images that originated from a base image, said container images may be used to instantiate the container images).”
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply the teachings of Cherny to RUDRARAJU to show as evidence, that the operator file of RUDRARAJU may specify the operator image, which can then be used to instantiate the operator. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of allowing an operator to define the custom resource within the container. Together, Cherny in combination with RUDRARAJU, teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied said teachings to achieve expected results.
31. Claim 13 has similar limitations to claim 6 and is rejected for similar reasons.
32. Claim 20 has similar limitations to claim 6 and is rejected for similar reasons.
33. With regard to claim 7, RUDRARAJU teaches creating and deploying a plurality of operators ([0120] At operation 516, the app server 100 deploys an operator into a computing cluster using information contained in the operator file 216 … After performance of operation 516, process 500B may end or repeat as necessary.)
RUDRARAJU does not explicitly teach managing the plurality of operators. However, Gallagher teaches an operator manager that can manage multiple operators such that it teaches the method further comprising managing a plurality of custom controllers ([0037] The operator manager 50 can install, update, and manage the lifecycle of operators, such as the first operator process 24-1 and the second operator process 24-2). Examiner also notes that the Operator Lifecycle Manager implicitly manages a plurality of operators as suggested by the upgrade process outlined in the CSV, Gallagher [0037]. The OLM must name an operator from a list of one or more operators to be upgraded such that it would manage a plurality of operators.
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to apply the teachings of Gallagher to RUDRARAJU to show as evidence, that the method of RUDRARAJU may implement an Operator Lifecycle Manager to manage a plurality of operators. A person having ordinary skill in the art would have been motivated to make this combination for the purpose centralizing control of operators and allow users to efficiently manage their resources. Together, Gallagher in combination with RUDRARAJU, teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied said teachings to achieve expected results.
34. Claim 14 has similar limitations to claim 7 and is rejected for similar reasons.
Conclusion
35. THIS ACTION IS MADE FINAL. 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.
36. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON A NGUYEN whose telephone number is (571)272-6074. The examiner can normally be reached Mon-Fri (10am-6pm).
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, Aimee Li can be reached at (571) 272-4169. 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.
/BRANDON NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights