Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This action is responsive to the application filed on August 2, 2024.
2. Claims 1-20 have been examined.
Allowable Subject Matter
3. After search and analysis, Examiner concluded that the claimed invention has been recited in such a manner that dependent claims 2 and 20 are not taught by any prior reference found through search.
The primary reason for allowance of the claims in this case, is the inclusion of the limitations “The method of claim 1, wherein the source platform is a testing platform,” which are not found in the prior art of record.
Incorporating claim 2 into claims 1, 8, and 14 would put the case in condition for allowance.
Claim Rejections – 35 USC §103
4. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
5. Claims 1, 3-6, 8, 9, 13, 14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 10,841,152 to Humphreys (hereafter “Humphreys”) in view of US 2005/0177635 to Schmidt et al. (hereafter “Schmidt”).
Claim 1.
Humphreys discloses a method of dynamically provisioning a software service on a destination platform, the method comprising:
accessing, by a computing system, a deployment document comprising one or more manifests associated with a source platform (FIG.2 and related text, service broker and deployment manager are associated with a source platform);
accessing, by the computing system, at least one of a configuration template associated with the software service,
Description
(13) A manifest generator 134 of the service broker 130 can generate a deployment manifest 138 for the cluster based on the release template for the cluster and the computing platform on which the cluster will be deployed. The deployment manifest 138 defines the components and properties of the cluster to be deployed. In general, the deployment manifest 138 instructs a deployment manager 140 on how to deploy the cluster. For example, the deployment manifest 138 can define the cloud computing or local platform on which the cluster is to be deployed, the number of instances of each component, e.g., instances of worker nodes, containers, containerized applications, etc., any credentials needed for users to access the clusters, a deployment identifier, e.g., a name for the deployment, release information, e.g., the name and version of each release in the deployment, network configuration, e.g., for a network that enables nodes, containers, and/or clusters to communicate, properties of virtual machines that will be created and managed by the deployment manager 140, properties of disk pools that will be created and managed by the deployment manager 140, update information that defines how the deployment manager 140 updates job instances during deployment, jobs information that defines the configuration and resource information for jobs, and/or other appropriate information. The deployment manifest 138 can be in the form of a text document, e.g., a YAML file. An example process for generating a deployment manifest is illustrated in FIG. 3 and described below.
(19) The cluster management system 120 also enables users to deploy clusters, e.g., Kubernetes clusters, on various different computing platforms without requiring the user to reconfigure the release template, the containerized application, or modifying any other parameters of the deployment outside of specifying the computing platform. The service broker 130 and deployment manager 140 handles all of the changes required for the different computing platforms.
(26) The configuration parameters of the health monitoring application can be specified in a policy associated with the user request for creating the cluster 152, e.g., associated with the cluster name, or associated with the release template cluster name. The containers can also be installed on the cluster 152 according to a customized policy specific to the user that requested creating the cluster 152.
(69) Embodiment 10 is the method of embodiment 9, wherein the one or more containerized applications include at least one monitoring application configured to monitor health of a computing cluster, configuration parameters of the monitoring application being specified in a policy associated with the user input or associated with the one or more release templates.
modifying, by the computing system, the deployment document to include at least one of configuration data based at least in part on the configuration template,
Description
(13) A manifest generator 134 of the service broker 130 can generate a deployment manifest 138 for the cluster based on the release template for the cluster and the computing platform on which the cluster will be deployed. The deployment manifest 138 defines the components and properties of the cluster to be deployed. In general, the deployment manifest 138 instructs a deployment manager 140 on how to deploy the cluster. For example, the deployment manifest 138 can define the cloud computing or local platform on which the cluster is to be deployed, the number of instances of each component, e.g., instances of worker nodes, containers, containerized applications, etc., any credentials needed for users to access the clusters, a deployment identifier, e.g., a name for the deployment, release information, e.g., the name and version of each release in the deployment, network configuration, e.g., for a network that enables nodes, containers, and/or clusters to communicate, properties of virtual machines that will be created and managed by the deployment manager 140, properties of disk pools that will be created and managed by the deployment manager 140, update information that defines how the deployment manager 140 updates job instances during deployment, jobs information that defines the configuration and resource information for jobs, and/or other appropriate information. The deployment manifest 138 can be in the form of a text document, e.g., a YAML file. An example process for generating a deployment manifest is illustrated in FIG. 3 and described below.
(33) The service broker creates a deployment manifest (220). As described above, the service broker can generate the deployment manifest based on a release template for the cluster and a cloud computing platform on which the cluster will be deployed. The deployment manifest defines the components and properties of the cluster to be deployed. In general, the deployment manifest instructs a deployment manager on how to deploy the cluster. The deployment manager that will create the clusters can be tied to a particular cloud computing platform. The service broker can generate the deployment manifest based on the particular cloud computing platform.
(41) A deployment manifest is generated based on the release template and the properties of the computing platform (330). The deployment manifest defines the components and properties of the cluster to be deployed. To generate the deployment manifest, a service broker can merge details of the deployment with a release template for the cluster. For example, the service broker can determine, based on the computing platform for the cluster and/or the data specified by the release template, specific network details for a virtual network of the cluster that will be implemented on the computing platform. These details can include the type of network that can be created on the computing platform, the type of network components that can be used in the network, and the number of network components required for the cluster. The service broker can also determine, based on the computing platform and/or the data specified by the release template, data storage of the computing platform that will be used to store data for the container(s) of the cluster, e.g., the type of data storage, the amount of data storage available, and/or the amount of data storage required by the cluster, virtual machine types of the computing platform that will be used to host the cluster, and/or other appropriate implementation details of the cluster on the computing platform. The service broker can merge these details with the release template to generate the deployment manifest.
(60) Embodiment 1 is a method comprising: receiving, by a service broker, a user input requesting creation of a computing cluster; generating, by the service broker and based at least in part on one or more release templates and the user input, a deployment manifest that specifies components and properties of a deployment of one or more clusters of a container orchestrator; providing, by the service broker, the deployment manifest to a deployment manager; creating, by the deployment manager according to the deployment manifest, one or more computing clusters in which one or more containerized applications are managed by the container orchestrator, the one or more computing clusters including a user space in the one or more computing clusters, each computing cluster configured to execute, in the user space, at least one containerized application specified by the container orchestrator; and providing references to the one or more computing clusters to a user device as a response to the user input.
determining, by the computing system, one or more compute instances instantiated on the destination platform (FIG.2, references to the computing cluser (destination platform); FIG.3, properties of the computing platform (destination platform)); and
provisioning, by the computing system, the one or more compute instances on the destination platform with the software service according to the deployment document (FIG.2, create the computing cluster including compute components; FIG.3, create the computing platform including components and properties).
Humphreys does not disclose data indicating the one or more resource limits associated with the software service.
However, Schmidt discloses data indicating the one or more resource limits associated with the software service (0016-0019, 0044, 0050, 0052).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Schmidt’s teaching into Humphreys‘ teaching. One would have been motivated to do so to grant access to resources based on limits and track resource usage as suggested by Schmidt (0014).
Claim 3.
Humphreys discloses the method of claim 1, wherein the one or more manifests indicate how the one or more compute instances, services executed on the one or more compute instances and/or compute resources of the destination platform are to be used by destination platform.
Description
(13) A manifest generator 134 of the service broker 130 can generate a deployment manifest 138 for the cluster based on the release template for the cluster and the computing platform on which the cluster will be deployed. The deployment manifest 138 defines the components and properties of the cluster to be deployed. In general, the deployment manifest 138 instructs a deployment manager 140 on how to deploy the cluster. For example, the deployment manifest 138 can define the cloud computing or local platform on which the cluster is to be deployed, the number of instances of each component, e.g., instances of worker nodes, containers, containerized applications, etc., any credentials needed for users to access the clusters, a deployment identifier, e.g., a name for the deployment, release information, e.g., the name and version of each release in the deployment, network configuration, e.g., for a network that enables nodes, containers, and/or clusters to communicate, properties of virtual machines that will be created and managed by the deployment manager 140, properties of disk pools that will be created and managed by the deployment manager 140, update information that defines how the deployment manager 140 updates job instances during deployment, jobs information that defines the configuration and resource information for jobs, and/or other appropriate information. The deployment manifest 138 can be in the form of a text document, e.g., a YAML file. An example process for generating a deployment manifest is illustrated in FIG. 3 and described below.
(16) Creating the cluster(s) 152 can include creating a number of clusters and instances of components in each cluster 152 based on the properties of the clusters defined by the deployment manifest 138. Configuring the cluster(s) 152 can include configuring the clusters for the deployment environment 150, which may include different configurations for different deployment environments. The deployment manifest 138 can include data that instructs the deployment manager 140 on how to configured the cluster(s) 152 for the specified deployment environment 150. Creating the cluster(s) 152 can also include designating one or more physical or virtual machines of a cloud provider as components of the cluster(s) 152.
(17) The deployment manager 140 can create, configure, and manage a particular type of clusters that include a particular container orchestrator that managers containerized applications executing in the clusters. In some implementations, the deployment manager 140 is a BOSH-compliant tool implemented on one or more computers. BOSH provides a tool chain for packaging, deploying, and managing cloud software. In some implementations, the cluster 152 is a Kubernetes cluster. In this example, a BOSH-compliant deployment manager can deploy and manage Kubernetes clusters on various cloud computing platforms using a deployment manifest 138. Although the examples described below are described largely in terms of Kubernetes clusters, similar techniques can be used to deploy and manage other types of clusters.
(20) To create a Kubernetes cluster in the deployment environment 150, the deployment manager 140 can create a cluster 152 that includes one or more virtual machines in the deployment environment 150. For example, the deployment manager 140 can initiate the virtual machines and designate them for use as the cluster 152. The deployment manager 140 can install the Kubernetes software on the virtual machines. The deployment manager 140 can then instruct the Kubernetes software to create the containers specified by the deployment manifest 138 and manage the execution of containerized applications in the containers. In response, the Kubernetes software can create the containers, install the containerized applications in the containers, and manage the execution of containerized applications in the containers.
(21) The Kubernetes software can also configure the containers, e.g., configure the security settings and configure communications between the containers. For example, as described below, the Kubernetes software can generate and configure a virtual network for the containers and nodes of the cluster 152 based on the deployment manifest 138.
(33) The service broker creates a deployment manifest (220). As described above, the service broker can generate the deployment manifest based on a release template for the cluster and a cloud computing platform on which the cluster will be deployed. The deployment manifest defines the components and properties of the cluster to be deployed. In general, the deployment manifest instructs a deployment manager on how to deploy the cluster. The deployment manager that will create the clusters can be tied to a particular cloud computing platform. The service broker can generate the deployment manifest based on the particular cloud computing platform.
Claim 4.
Humphreys discloses the method of claim 1, wherein the configuration template defines at least at least a portion of an operating environment of a node, a pod, and/or a container to be instantiated on the destination platform.
Description
(7) The cluster management system 120 can create the clusters in various deployment environments, such as various different cloud computing platforms and/or local deployment platforms, e.g., one or more local on-premises servers, without requiring the user to customize the specifications for the cluster, e.g., without the user being required to modify a release template that specifies jobs, packages, source code, and/or associated metadata for the clusters.
(12) When the service broker 130 receives a command to create a cluster, the service broker 130 can obtain a release template for the cluster based on the name of the cluster. For example, release templates for various clusters can be stored on a release templates data storage device 136 with a reference to the cluster name. The release templates can include the cluster components, e.g., Kubernetes cluster components, the application to be deployed in the cluster, e.g., including jobs, packages, and source code for the application, instructions on how to deploy the application, data specifying a cloud provider on which to deploy the cluster, and/or other appropriate data for the cluster. In some implementations, the release template can also include a user-specified computing platform for the cluster. This allows users to specify the computing platform in the release template. Each release template can be in the form of a TAR archive file, e.g., a TGZ file.
(39) A release template is identified for a cluster based on a cluster name (310). As described above, a service broker can receive a request to create a cluster and the request can specify the cluster name. Each cluster name can be associated with a release template that includes the cluster components, e.g., Kubernetes cluster components, the application to be deployed in the cluster, e.g., including jobs, packages, and source code for the application, instructions on how to deploy the application, data specifying a cloud provider on which to deploy the cluster, and/or other appropriate data for the cluster. The release template can be generated by a user, e.g., an application developer.
(41) A deployment manifest is generated based on the release template and the properties of the computing platform (330). The deployment manifest defines the components and properties of the cluster to be deployed. To generate the deployment manifest, a service broker can merge details of the deployment with a release template for the cluster. For example, the service broker can determine, based on the computing platform for the cluster and/or the data specified by the release template, specific network details for a virtual network of the cluster that will be implemented on the computing platform. These details can include the type of network that can be created on the computing platform, the type of network components that can be used in the network, and the number of network components required for the cluster. The service broker can also determine, based on the computing platform and/or the data specified by the release template, data storage of the computing platform that will be used to store data for the container(s) of the cluster, e.g., the type of data storage, the amount of data storage available, and/or the amount of data storage required by the cluster, virtual machine types of the computing platform that will be used to host the cluster, and/or other appropriate implementation details of the cluster on the computing platform. The service broker can merge these details with the release template to generate the deployment manifest.
Claim 5.
Humphreys discloses the method of claim 4, wherein the configuration template comprises at least one of a static value, a function, a loop, or an argument-defined parameter.
Description
(7) The cluster management system 120 can create the clusters in various deployment environments, such as various different cloud computing platforms and/or local deployment platforms, e.g., one or more local on-premises servers, without requiring the user to customize the specifications for the cluster, e.g., without the user being required to modify a release template that specifies jobs, packages, source code, and/or associated metadata for the clusters.
(12) When the service broker 130 receives a command to create a cluster, the service broker 130 can obtain a release template for the cluster based on the name of the cluster. For example, release templates for various clusters can be stored on a release templates data storage device 136 with a reference to the cluster name. The release templates can include the cluster components, e.g., Kubernetes cluster components, the application to be deployed in the cluster, e.g., including jobs, packages, and source code for the application, instructions on how to deploy the application, data specifying a cloud provider on which to deploy the cluster, and/or other appropriate data for the cluster. In some implementations, the release template can also include a user-specified computing platform for the cluster. This allows users to specify the computing platform in the release template. Each release template can be in the form of a TAR archive file, e.g., a TGZ file.
(39) A release template is identified for a cluster based on a cluster name (310). As described above, a service broker can receive a request to create a cluster and the request can specify the cluster name. Each cluster name can be associated with a release template that includes the cluster components, e.g., Kubernetes cluster components, the application to be deployed in the cluster, e.g., including jobs, packages, and source code for the application, instructions on how to deploy the application, data specifying a cloud provider on which to deploy the cluster, and/or other appropriate data for the cluster. The release template can be generated by a user, e.g., an application developer.
(41) A deployment manifest is generated based on the release template and the properties of the computing platform (330). The deployment manifest defines the components and properties of the cluster to be deployed. To generate the deployment manifest, a service broker can merge details of the deployment with a release template for the cluster. For example, the service broker can determine, based on the computing platform for the cluster and/or the data specified by the release template, specific network details for a virtual network of the cluster that will be implemented on the computing platform. These details can include the type of network that can be created on the computing platform, the type of network components that can be used in the network, and the number of network components required for the cluster. The service broker can also determine, based on the computing platform and/or the data specified by the release template, data storage of the computing platform that will be used to store data for the container(s) of the cluster, e.g., the type of data storage, the amount of data storage available, and/or the amount of data storage required by the cluster, virtual machine types of the computing platform that will be used to host the cluster, and/or other appropriate implementation details of the cluster on the computing platform. The service broker can merge these details with the release template to generate the deployment manifest.
Claim 6.
Humphreys discloses the method of claim 1, wherein the environment variable comprises at least one of an identifier associated with the software service
Description
(10) The user device 110 is an electronic device, e.g., a computer, that provides one or more interfaces to an application developer. The interface can be a command-line interface (CLI), graphical user interface (GUI), or a combination of the two. The user device 110 can use the CLI to issue a request to provision a cluster for deploying a service instance of an application. A service instance is also referred to as a deployment of the application. For example, a user, e.g., an application developer, can enter a command and the name of the cluster or other appropriate cluster identifier in the CLI of the user device 110. An example command is “pks create-cluster cluster name” in which “pks create-cluster” is the command to create the cluster and “cluster name” is the name of the cluster. The user device 110 can then send data specifying the command and the name of the cluster to the service broker 130.
(12) When the service broker 130 receives a command to create a cluster, the service broker 130 can obtain a release template for the cluster based on the name of the cluster. For example, release templates for various clusters can be stored on a release templates data storage device 136 with a reference to the cluster name. The release templates can include the cluster components, e.g., Kubernetes cluster components, the application to be deployed in the cluster, e.g., including jobs, packages, and source code for the application, instructions on how to deploy the application, data specifying a cloud provider on which to deploy the cluster, and/or other appropriate data for the cluster. In some implementations, the release template can also include a user-specified computing platform for the cluster. This allows users to specify the computing platform in the release template. Each release template can be in the form of a TAR archive file, e.g., a TGZ file.
(13) A manifest generator 134 of the service broker 130 can generate a deployment manifest 138 for the cluster based on the release template for the cluster and the computing platform on which the cluster will be deployed. The deployment manifest 138 defines the components and properties of the cluster to be deployed. In general, the deployment manifest 138 instructs a deployment manager 140 on how to deploy the cluster. For example, the deployment manifest 138 can define the cloud computing or local platform on which the cluster is to be deployed, the number of instances of each component, e.g., instances of worker nodes, containers, containerized applications, etc., any credentials needed for users to access the clusters, a deployment identifier, e.g., a name for the deployment, release information, e.g., the name and version of each release in the deployment, network configuration, e.g., for a network that enables nodes, containers, and/or clusters to communicate, properties of virtual machines that will be created and managed by the deployment manager 140, properties of disk pools that will be created and managed by the deployment manager 140, update information that defines how the deployment manager 140 updates job instances during deployment, jobs information that defines the configuration and resource information for jobs, and/or other appropriate information. The deployment manifest 138 can be in the form of a text document, e.g., a YAML file. An example process for generating a deployment manifest is illustrated in FIG. 3 and described below.
(26) The configuration parameters of the health monitoring application can be specified in a policy associated with the user request for creating the cluster 152, e.g., associated with the cluster name, or associated with the release template cluster name. The containers can also be installed on the cluster 152 according to a customized policy specific to the user that requested creating the cluster 152.
Claim 8.
This claim is a system version, which recites the same limitations as those of claim 1, wherein all claimed limitations have been addressed and/or set forth above. Therefore, as the reference teaches all of the limitations of the above claim, it also teaches all of the limitations of this claim.
Claim 9.
Humphreys does not disclose the system of claim 8, wherein the one or more resource limits comprise a maximum amount of compute resources of the one or more compute instances the software service is allowed to utilize.
However, Schmidt discloses the one or more resource limits comprise a maximum amount of compute resources of the one or more compute instances the software service is allowed to utilize (0016-0019, 0044, 0050, 0052).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Schmidt’s teaching into Humphreys‘ teaching. One would have been motivated to do so to grant access to resources based on limits and track resource usage as suggested by Schmidt (0014).
Claim 13.
Humphreys discloses the system of claim 8, wherein the system includes a container orchestrator (FIG.1 and related text).
Claim 14.
This claim is a memory version, which recites the same limitations as those of claim 1, wherein all claimed limitations have been addressed and/or set forth above. Therefore, as the reference teaches all of the limitations of the above claim, it also teaches all of the limitations of this claim.
Claims 16-19.
These claims are memory versions, which recite the same limitations as those of claims 3-6, wherein all claimed limitations have been addressed and/or set forth above. Therefore, as the reference teaches all of the limitations of the above claims, it also teaches all of the limitations of these claims.
6. Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Humphreys, in view of Schmidt, and further in view of US 2017/0041386 to Bhat et al. (hereafter “Bhat”).
Claim 7.
Humphreys and Schmidt do not disclose the method of claim 1, wherein the destination platform is provisioned dynamically.
However, Bhat discloses the destination platform is provisioned dynamically (0020, 0021, 0053, 0082).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Bhat’s teaching into Humphreys and Schmidt‘ teaching. One would have been motivated to do so to optimally provision middleware to host an application of a cloud computing environment as suggested by Bhat (0020, 0021, 0053, 0082).
Claim 20.
This claim is a memory version, which recites the same limitations as those of claim 7, wherein all claimed limitations have been addressed and/or set forth above. Therefore, as the reference teaches all of the limitations of the above claim, it also teaches all of the limitations of this claim.
7. Claims 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Humphreys, in view of Schmidt, and further in view of US 2017/0012819 to Raheja et al. (hereafter “Raheja”).
Claim 10.
Humphreys and Schmidt do not disclose the system of claim 8, wherein the source platform comprises a first version of the software service and a second version of the software service.
However, Raheja discloses the source platform comprises a first version of the software service and a second version of the software service (FIG.1, provision client nodes using different versions of applications stored in Code Repository 137).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Raheja’s teaching into Humphreys and Schmidt‘ teaching. One would have been motivated to do so to configure the client nodes for use in developing, testing, or deploying the software application as suggested by Raheja (0024).
Claim 11.
Humphreys and Schmidt do not disclose the system of claim 10, wherein the system receives a request indicating at least one of the first version of the software service or the second version of the software service to be provisioned on the destination platform.
However, Rajeha discloses the system receives a request indicating at least one of the first version of the software service or the second version of the software service to be provisioned on the destination platform (0026, 0028, 0031, 0036).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Raheja’s teaching into Humphreys and Schmidt‘ teaching. One would have been motivated to do so to configure the client nodes for use in developing, testing, or deploying the software application as suggested by Raheja (0024).
Claim 12.
Humphreys and Schmidt do not disclose the system of claim 10, wherein the system determines at least one of the first version of the software service or the second version of the software service to be provisioned on the destination platform based on at least one of a latest version or a fully-tested version.
However, Rajeha discloses the system determines at least one of the first version of the software service or the second version of the software service to be provisioned on the destination platform based on at least one of a latest version or a fully-tested version (0029, 0050, 0071).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Raheja’s teaching into Humphreys and Schmidt‘ teaching. One would have been motivated to do so to configure the client nodes for use in developing, testing, or deploying the software application as suggested by Raheja (0024).
Conclusion
8. Any inquiry concerning this communication should be directed to examiner Thuy (Twee) Dao, whose telephone/fax numbers are (571) 272 8570 and (571) 273 8570, respectively. Examiner can normally be reached from Monday to Friday, 5:30am - 2:00pm ET.
If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Hyung (Sam) Sough, can be reached at (571) 272 6799.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273 8300.
Any inquiry of a general nature of relating to the status of this application or proceeding should be directed to the TC 2100 Group receptionist whose telephone number is (571) 272 2100.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Thuy Dao/Primary Examiner, Art Unit 2192
Prosecution Insights