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 .
The objections to claims 3, 10, and 17 for informalities have been withdrawn.
Examiner invites Applicant to schedule an interview at their own leisure to discuss any upcoming topics/issues. Applicant may request via email or through the USPTO AIR system.
Response to Arguments
3. Applicant’s arguments with respect to claim(s) 1, 8, and 15 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.
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) and Bai et al. Pub. No. US 2023/0259392 A1 (hereafter Bai).
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 instantiating a custom controller from a default image.
Cherny teaches “wherein the custom controller is instantiated from a default operator image ([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.
The combination may not explicitly teach of configuring the custom controller based on the specification of the custom controller once running in the cluster.
Bai teaches a deployment event such that it teaches the limitation “and, once running in the first container-based cluster, is then configured based on the specification of the custom controller ([0065] FIG. 4 depicts a block diagram of a service deployment platform 400 in which embodiments of the present disclosure can be implemented. As illustrated in FIG. 4, a virtualized operator environment 410 is deployed to control and manage deployment of services in one or more computing clusters, e.g., a computing cluster 420. The computing cluster 420 may consist of a group of configurable physical and/or virtual resources that can be utilized for running services. The resources may include, for example, servers, memories, storage, network connectivity, and so on.
[0066] In some embodiments, the overall platform 400 in FIG. 4 may be a cloud, such as a cloud based on the Kubernetes container platform. In some embodiments, related to a container-based cloud, the virtualized operator environment 410 may be an operator container which is launched as an instance of an operator within the cloud.
[0067] The virtualized operator environment 410 receives a deployment event 402 for a service or a group of services that are included in a software product. The virtualized operator environment 410 is operable to deploy the services into the computing cluster 420 according to a service specification 412. In some cases, the deployment event 402 includes a request for deployment of a new group of services or an application for a change to a group of services that has been deployed in the computing cluster 420. As illustrated, services 421, 422, 423, . . . , 42N may be deployed in the computing cluster 420.
[0068] The service specification 412 may include a custom resource definition (CRD) for a group of services associated with the software product, indicating a mapping between resources in the computing cluster 420 and the services. The service specification 412 may be of any data structure specifying tasks that are required to execute during the deployment of the services in the computing cluster 420. In some embodiments, the service specification 412 may comprise a plurality of segments each specifying tasks that are to be executed to deploy one or more groups of services. The deployment event 402 may indicate the group of services to be deployed so the virtualized operator environment 410 is able to perform the corresponding deployment.
[0069] The service specification 412 may be utilized to deploy a same group of services for a plurality of instances in the computing cluster 420. Each time when one or more of the deployed services are to be changed or a new group of services are to be deployed, the virtualized operator environment 410 may receive a deployment event 402. The deployment event 402 may be considered a custom resource instance for the CRD in the service specification 412.
[0070] In some embodiments, the service specification 412 may be a file written using a human-readable data serialization language such as YAML Ain′t Markup Language, YAML. The service specification 412 may be written in other languages.
[0071] One example of operators configured for automatic service deployment may include an Ansible Operator. An Ansible Operator is an operator that allows users to package operational knowledge (how to install and maintain the services) in the form of Ansible Roles and Playbooks. The Ansible Operator uses Ansible for the reconciliation logic. This logic (contained in roles or playbooks) is mapped to a particular computing cluster by a service specification (sometimes referred to as a watches.yaml file). The operator checks the service specification to determine which playbook or roles to execute, and then launches the playbooks/roles using Ansible Runners to execute corresponding tasks. The users can write the roles and playbooks so as to manage the services deployed in the computing cluster 420)”.
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 Bai with the combination of RUDRARAJU and Cherny in order to show that the operator may be instantiated and deployed onto the cluster, awaiting for a deployment event containing specifications, in order to determine and configure specific playbooks or roles to execute during the deployment process of services, such that the operator is configured while running on the cluster. The motivation for applying Bai’s teaching with the combination is for implementing a reusable operator that supports different service deployment workflows without requiring a separately developed operator for each service or deployment scenario as well as decreasing the deployment time consumption (Bai [0005]). Together Bai, 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 Bai with the combination of RUDRARAJU and Cherny 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, ([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 a 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, Cherny, and Bai 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
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