DETAILED ACTION
This office action is in response to RCE filed on 12/18/2025.
Claims 1, 5, 13 and 18 are amended.
Claims 2 – 4 are cancelled.
Claims 1 and 5 – 20 are pending.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/18/2025 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 14 and 19 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. The claimed limitations of claims 14 and 19 are already part of amended independent claims 13 and 18. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 5 – 7, 10 – 12 and 18 – 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Du et al (US 20130227558, hereinafter Du), in view of Koropoff (US 20230102863), in view of Nagar et al (US 20210342468, hereinafter Nagar), in view of Bansal et al (US 20100153945, hereinafter Bansal), and further in view of Baughman et al (US 20130346614, hereinafter Baughman).
As per claim 1, Du discloses: A computing system, comprising: at least one processor; and at least one memory storing computer-executable instructions for defining a cluster of computing resources, the computer-executable instructions when executed by the at least one processor causing the computer to:
receive input data from a user interface accessible from a user computing device, the input data being associated with creating a cluster, wherein the input data comprises one or more of: a use case associated with the cluster; a run start time; a cluster data type; an amount of computing resources, including at least one of an amount of processing resources and an amount of memory; an environment in which to create the cluster; (Du [0040]: “In step 405, cluster management application 335 receives configuration information from a user to provision a cluster within host group 310, such as cluster size, data sets, data jobs, etc… or example, an embodiment that is designed to provide users a higher level of customization may further provide users a capability to select particular base virtual disk templates (e.g., different versions of Hadoop virtual disk templates having various combinations of different versions of guest OS, JVM and Hadoop software components, virtual disk templates to provision a cluster for different distributed computing platforms in addition to or other than Hadoop, etc.) to be used as primary virtual disks by the VM nodes in the cluster or may enable the user to choose a "placement strategy" for the cluster, such as to optimize operational efficiency, operational robustness, or a combination of operational efficiency and operational robustness. As previously discussed, receipt of such configuration information from the user may be achieved in a variety of ways, for example, through a user interface (e.g., web pages) or, programmatically, through an API.”)
prepare a cluster request associated with the input data; (Du [0031]: “Upon receipt of configuration information, in step 410, cluster management application 335 determines a placement of VM nodes (consistent with the specified cluster size in the received configuration information) by selecting one or more target hosts from host group 310 and determining the quantity of VM nodes to execute at each target host based on the specified cluster size (e.g., as provided by a user). For example, cluster management application 335 may select a quantity of hosts 100 equal to the cluster size as the target hosts, such that each target host will execute one VM node.”)
convert the cluster request into a generic format including receiving an image of an execution environment adapted for use according to the cluster request, wherein the image comprised a templated container image corresponding to the format of the cluster request; (Du [0033]: “In step 415, cluster management application 335 communicates with virtualization management application 330 to identify a base virtual disk template (as previously discussed) that may serve as a base template for a primary virtual disk for each VM node to be instantiated among hosts in host group 310 as determined in step 410. Cluster management application 335 may identify such a base virtual disk template based upon configuration information received in step 405 or may otherwise choose such a base virtual disk template based on other criteria (e.g., pre-determined, etc.).”)
utilizing the image of the execution environment, create clusters with the chosen computing resource provider, wherein creating clusters comprises: assigning an amount of computing resources equal to or greater than the amount of computing resources defined within the input data consistent with the predetermined allocation category; and preparing IP addresses of nodes of the chosen computing resource provider grouped into clusters; and utilize the cluster to run the use case, wherein running the use case includes calling a script. (Du [0035]: “In step 425, cluster management application 335 communicates with virtualization management application 330 to instruct each target host identified in step 410 to instantiate an appropriate number of VM nodes. In step 430, cluster management application 335 may then communicate with the VM nodes to configure them to properly interact as a cluster of the distributed computing platform. For example, in a Hadoop embodiment, cluster management application 335 may determine the hostnames and/or network addresses for each VM node and provide such mappings to each of the VM nodes to ensure that each VM node can communicate with other VM nodes in the cluster. In some embodiments, the configuration information received 405 by cluster management application 335 includes VM attributes, such as the number and/or speed of virtual processors 245, the amount of memory 250, the amount of local storage 255, and the number and/or type of network communication interfaces 265. In such embodiments, cluster management application 335 configures the VM nodes using the specified VM attributes… Similarly, cluster management application 335 may provide or otherwise update Hadoop configuration files (e.g., script files such as "hadoop-env.sh" and/or configuration files such as "core-site.xml", "hdfs-site.xml", and "mapred-site.xml," etc.) in the VM nodes to properly identify master and worker VM nodes in the cluster (e.g., select VM nodes to serve as NameNodes, JobTrackers, etc.), HDFS paths, a quantity of data block replicas for HDFS files as further discussed below, etc. As further discussed below, embodiments of cluster management application 335 may further generate and provide a "rack awareness" script to each VM node to identify the physical rack of the host running the VM node.”; [0036]: “Once the VM nodes are functioning as a cluster of the distribute computing platform, in step 435, cluster management application 335 may provide the data set to the cluster to be processed.”)
Du did not explicitly disclose:
receive a predetermined allocation category of the cluster, wherein the predetermine allocation category includes a predetermined size and category designation of the cluster;
determine, based on the input data, whether to create the cluster using enterprise computing resource infrastructure or to create the cluster using a third party computing resource infrastructure, wherein the determination is based at least in part on confidentiality of the user case;
establish a connection with a provider of a chosen computing resource infrastructure, the chosen computing resource infrastructure being selected from among the enterprise computing resource infrastructure and the third party computing resource infrastructure;
wherein creating clusters comprises: scheduling the cluster to run the use case at the run start time;
monitor, during execution of the use case, a measured utilization of the cluster including at least one of CPU utilization, memory utilization, and executor utilization;
in response to determining that the measured utilization is below a deallocation threshold, automatically deallocate a surplus portion of the computing resources assigned to the cluster;
and in response to determining that the measured utilization meets or exceeds a requested utilization level specified in the input data, automatically increase computing resources assigned to the cluster.
Koropoff teaches:
receive a predetermined allocation category of the cluster, wherein the predetermine allocation category includes a predetermined size and category designation of the cluster; (Koropoff [0030])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Koropoff into that of Du in order to receive a predetermined allocation category of the cluster, wherein the predetermine allocation category includes a predetermined size and category designation of the cluster. Koropoff has shown the claimed limitations are merely commonly known characteristics of the cluster deployment one can choose, applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
Nagar teaches:
determine, based on the input data, whether to create the cluster using enterprise computing resource infrastructure or to create the cluster using a third party computing resource infrastructure, wherein the determination is based at least in part on confidentiality of the user case; (Nagar [0071])
establish a connection with a provider of a chosen computing resource infrastructure, the chosen computing resource infrastructure being selected from among the enterprise computing resource infrastructure and the third party computing resource infrastructure; (Nagar [073] – [0074].)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Anand into that of Du and Koropoff in order to determine, based on the input data, whether to create the cluster using enterprise computing resource infrastructure or to create the cluster using a third party computing resource infrastructure; establish a connection with a provider of a chosen computing resource infrastructure, the chosen computing resource infrastructure being selected from among the enterprise computing resource infrastructure and the third party computing resource infrastructure. Koropoff has shown that the claimed limitations are merely commonly known steps to determine optimal placement of the VM nodes/clusters, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
Bansal teaches:
wherein creating clusters comprises: scheduling the cluster to run the use case at the run start time; (Bansal [0055]: “specific start time”.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Bansal into that of Du, Koropoff and Nagar in order to schedule the cluster to run the use case at the run start time. Bansal has shown that the claimed limitations are merely commonly known steps to schedule the execution of tasks in a distributed manner, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
Baughman teaches:
monitor, during execution of the use case, a measured utilization of the cluster including at least one of CPU utilization, memory utilization, and executor utilization; in response to determining that the measured utilization is below a deallocation threshold, automatically deallocate a surplus portion of the computing resources assigned to the cluster; and in response to determining that the measured utilization meets or exceeds a requested utilization level specified in the input data, automatically increase computing resources assigned to the cluster. (Baughman [0031])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Baughman into that of Du, Koropoff, Nagar and Bansal in order to monitor, during execution of the use case, a measured utilization of the cluster including at least one of CPU utilization, memory utilization, and executor utilization; in response to determining that the measured utilization is below a deallocation threshold, automatically deallocate a surplus portion of the computing resources assigned to the cluster; and in response to determining that the measured utilization meets or exceeds a requested utilization level specified in the input data, automatically increase computing resources assigned to the cluster. Baughman has shown that the claimed limitations are merely commonly known steps to optimization distributed scheduling and execution environment, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
As per claim 5, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The computing system of claim 1, further comprising instructions to: output performance metrics associated with the monitored performance of the cluster to a dashboard user interface. (Baughman [0040].)
As per claim 6, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The computing system of claim 5, further comprising instructions to: change the amount of computing resources assigned to the cluster, based on edit inputs received from a user via the dashboard user interface. (Baughman [0031] and [0041].)
As per claim 7, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The computing system of claim 1, further comprising instructions to: determine that the use case has been run to a completion point; and upon reaching the completion point, automatically decommission the cluster to release the amount of computing resources to the chosen provider. (Du [0054]: “VM nodes are stateless before a new job is loaded and after a job is completed and are therefore easily created and recycled… The procedure may be similar for recycling nodes when computing resource demand decreases, and the cluster size is scaled down. For example, N-1 nodes (where N is the number of data replicas in the cluster) may be recycled, and the rebalance command may be executed. This process may be performed iteratively, avoiding data loss”.)
As per claim 10, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The computing system of claim 1, wherein the script is called from a database location, wherein the input data includes a database location path. (Du [0035])
As per claim 11, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The computing system of claim 1, wherein the script is called from a location on a user device, wherein the input data includes a user device path. (Du [0027])
As per claim 12, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The computing system of claim 1, wherein running the use case includes performing a data enrichment job. (Du [0038])
As per claim 18, it is the method variant of claim 1 and is therefore rejected under the same rationale.
As per claim 19, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The method of claim 18, further comprising: monitoring a performance of the cluster when the cluster is running the use case. (Baughman [0031])
As per claim 20, the combination of Du, Koropoff, Nagar, Bansal and Baughman further teach:
The method of claim 19, wherein monitoring the performance of the cluster comprises: sending an instruction to the application programming interface to measure cluster performance; receiving cluster performance information from the application programming interface; and outputting performance metrics associated with the cluster performance information to a dashboard user interface. (Baughman [0031] and [0041].)
Claim(s) 8 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Du, Koropoff, Nagar, Bansal and Baughman, and further in view of Dolev et al (US 20080282246, hereinafter Dolev).
As per claim 20, the combination of Du, Koropoff, Nagar, Bansal and Baughman did not teach:
The computing system of claim 1, further comprising instructions to: based on the use case indicating that the use case is a reoccurring job, schedule the cluster to automatically run the use case at a second run start time.
However, Dolev teaches:
The computing system of claim 1, further comprising instructions to: based on the use case indicating that the use case is a reoccurring job, schedule the cluster to automatically run the use case at a second run start time. (Dolev [0039])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Dolev into that of Du, Koropoff, Nagar, Bansal and Baughman in order to, based on the use case indicating that the use case is a reoccurring job, schedule the cluster to automatically run the use case at a second run start time. Dolev has shown that the claimed limitations are merely commonly known steps of task scheduling, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
As per claim 9, the combination of Du, Koropoff, Nagar, Bansal, Baughman and Dolev further teach:
The computing system of claim 8, further comprising instructions to: after running the use case, determine that the use case has been run to a completion point; temporarily deallocate the computing resources assigned to the cluster; release the computing resources to the chosen provider until the second run start time; create a second instance of the cluster according to the input data; reassign the computing resources to the second instance of the cluster; and utilize the second instance of the cluster to automatically run the use case at the second run start time. (Dolev [0039] and Du [0035])
Claim(s) 13 – 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Du, Koropoff, Nagar, Bansal and Baughman and further in view of Grund et al (USPAT 11133933, hereinafter Grund).
As per claim 13, Du discloses: A computing system, comprising: at least one processor; and at least one memory storing computer-executable instructions for defining a cluster of computing resources as a service, the computer-executable instructions when executed by the at least one processor causing the computer to:
receive input data from a user, via a software development kit, the input data being associated with creating a cluster, wherein the input data comprises one or more of: a platform designation; a use case associated with the cluster; an owner designation; a cluster data type; an environment in which to create the cluster; and a predetermined allocation category; prepare a cluster request associated with the input data; (Du [0040]: “In step 405, cluster management application 335 receives configuration information from a user to provision a cluster within host group 310, such as cluster size, data sets, data jobs, etc… or example, an embodiment that is designed to provide users a higher level of customization may further provide users a capability to select particular base virtual disk templates (e.g., different versions of Hadoop virtual disk templates having various combinations of different versions of guest OS, JVM and Hadoop software components, virtual disk templates to provision a cluster for different distributed computing platforms in addition to or other than Hadoop, etc.) to be used as primary virtual disks by the VM nodes in the cluster or may enable the user to choose a "placement strategy" for the cluster, such as to optimize operational efficiency, operational robustness, or a combination of operational efficiency and operational robustness. As previously discussed, receipt of such configuration information from the user may be achieved in a variety of ways, for example, through a user interface (e.g., web pages) or, programmatically, through an API.”)
prepare a cluster request associated with the input data; (Du [0031]: “Upon receipt of configuration information, in step 410, cluster management application 335 determines a placement of VM nodes (consistent with the specified cluster size in the received configuration information) by selecting one or more target hosts from host group 310 and determining the quantity of VM nodes to execute at each target host based on the specified cluster size (e.g., as provided by a user). For example, cluster management application 335 may select a quantity of hosts 100 equal to the cluster size as the target hosts, such that each target host will execute one VM node.”)
convert the cluster request into a generic format including receiving an image of an execution environment adapted for use according to the cluster request, wherein the image comprised a templated container image corresponding to the format of the cluster request; (Du [0033]: “In step 415, cluster management application 335 communicates with virtualization management application 330 to identify a base virtual disk template (as previously discussed) that may serve as a base template for a primary virtual disk for each VM node to be instantiated among hosts in host group 310 as determined in step 410. Cluster management application 335 may identify such a base virtual disk template based upon configuration information received in step 405 or may otherwise choose such a base virtual disk template based on other criteria (e.g., pre-determined, etc.).”)
utilizing the image of the execution environment, create clusters with the chosen computing resource provider, wherein creating clusters comprises: assigning an amount of computing resources equal to or greater than the amount of computing resources defined within the input data consistent with the predetermined allocation category; and preparing IP addresses of nodes of the chosen computing resource provider grouped into clusters; and utilize the cluster to run the use case, wherein running the use case includes calling a script. (Du [0035]: “In step 425, cluster management application 335 communicates with virtualization management application 330 to instruct each target host identified in step 410 to instantiate an appropriate number of VM nodes. In step 430, cluster management application 335 may then communicate with the VM nodes to configure them to properly interact as a cluster of the distributed computing platform. For example, in a Hadoop embodiment, cluster management application 335 may determine the hostnames and/or network addresses for each VM node and provide such mappings to each of the VM nodes to ensure that each VM node can communicate with other VM nodes in the cluster. In some embodiments, the configuration information received 405 by cluster management application 335 includes VM attributes, such as the number and/or speed of virtual processors 245, the amount of memory 250, the amount of local storage 255, and the number and/or type of network communication interfaces 265. In such embodiments, cluster management application 335 configures the VM nodes using the specified VM attributes… Similarly, cluster management application 335 may provide or otherwise update Hadoop configuration files (e.g., script files such as "hadoop-env.sh" and/or configuration files such as "core-site.xml", "hdfs-site.xml", and "mapred-site.xml," etc.) in the VM nodes to properly identify master and worker VM nodes in the cluster (e.g., select VM nodes to serve as NameNodes, JobTrackers, etc.), HDFS paths, a quantity of data block replicas for HDFS files as further discussed below, etc. As further discussed below, embodiments of cluster management application 335 may further generate and provide a "rack awareness" script to each VM node to identify the physical rack of the host running the VM node.”; [0036]: “Once the VM nodes are functioning as a cluster of the distribute computing platform, in step 435, cluster management application 335 may provide the data set to the cluster to be processed.”)
Du did not explicitly disclose:
receive a predetermined allocation category of the cluster, wherein the predetermine allocation category includes a predetermined size and category designation of the cluster;
determine, based on the input data, whether to create the cluster using enterprise computing resource infrastructure or to create the cluster using a third party computing resource infrastructure, wherein the determination is based at least in part on confidentiality of the user case;
establish a connection with a provider of a chosen computing resource infrastructure, the chosen computing resource infrastructure being selected from among the enterprise computing resource infrastructure and the third party computing resource infrastructure;
wherein creating clusters comprises: scheduling the cluster to run the use case at the run start time;
monitor, during execution of the use case, a measured utilization of the cluster including at least one of CPU utilization, memory utilization, and executor utilization;
in response to determining that the measured utilization is below a deallocation threshold, automatically deallocate a surplus portion of the computing resources assigned to the cluster;
and in response to determining that the measured utilization meets or exceeds a requested utilization level specified in the input data, automatically increase computing resources assigned to the cluster.
determine that the cluster has not been utilized to run a second use case for a predetermined period of time; and automatically decommission the cluster to release the amount of computing resources to the chosen provider.
Koropoff teaches:
receive a predetermined allocation category of the cluster, wherein the predetermine allocation category includes a predetermined size and category designation of the cluster; (Koropoff [0030])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Koropoff into that of Du in order to receive a predetermined allocation category of the cluster, wherein the predetermine allocation category includes a predetermined size and category designation of the cluster. Koropoff has shown the claimed limitations are merely commonly known characteristics of the cluster deployment one can choose, applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
Nagar teaches:
determine, based on the input data, whether to create the cluster using enterprise computing resource infrastructure or to create the cluster using a third party computing resource infrastructure, wherein the determination is based at least in part on confidentiality of the user case; (Nagar [0071])
establish a connection with a provider of a chosen computing resource infrastructure, the chosen computing resource infrastructure being selected from among the enterprise computing resource infrastructure and the third party computing resource infrastructure; (Nagar [073] – [0074].)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Anand into that of Du and Koropoff in order to determine, based on the input data, whether to create the cluster using enterprise computing resource infrastructure or to create the cluster using a third party computing resource infrastructure; establish a connection with a provider of a chosen computing resource infrastructure, the chosen computing resource infrastructure being selected from among the enterprise computing resource infrastructure and the third party computing resource infrastructure. Koropoff has shown that the claimed limitations are merely commonly known steps to determine optimal placement of the VM nodes/clusters, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
Bansal teaches:
wherein creating clusters comprises: scheduling the cluster to run the use case at the run start time; (Bansal [0055]: “specific start time”.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Bansal into that of Du, Koropoff and Nagar in order to schedule the cluster to run the use case at the run start time. Bansal has shown that the claimed limitations are merely commonly known steps to schedule the execution of tasks in a distributed manner, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
Baughman teaches:
monitor, during execution of the use case, a measured utilization of the cluster including at least one of CPU utilization, memory utilization, and executor utilization; in response to determining that the measured utilization is below a deallocation threshold, automatically deallocate a surplus portion of the computing resources assigned to the cluster; and in response to determining that the measured utilization meets or exceeds a requested utilization level specified in the input data, automatically increase computing resources assigned to the cluster. (Baughman [0031])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Baughman into that of Du, Koropoff, Nagar and Bansal in order to monitor, during execution of the use case, a measured utilization of the cluster including at least one of CPU utilization, memory utilization, and executor utilization; in response to determining that the measured utilization is below a deallocation threshold, automatically deallocate a surplus portion of the computing resources assigned to the cluster; and in response to determining that the measured utilization meets or exceeds a requested utilization level specified in the input data, automatically increase computing resources assigned to the cluster. Baughman has shown that the claimed limitations are merely commonly known steps to optimization distributed scheduling and execution environment, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
Grund teaches:
determine that the cluster has not been utilized to run a second use case for a predetermined period of time; and automatically decommission the cluster to release the amount of computing resources to the chosen provider. (Grund col 11, line 52 – col 12, line 10.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Grund into that of Du, Koropoff, Nagar, Bansal and Baughman in order to determine that the cluster has not been utilized to run a second use case for a predetermined period of time; and automatically decommission the cluster to release the amount of computing resources to the chosen provider. Grund has shown that the claimed limitations are merely commonly known steps of optimizing distributed task execution environment, thus applicants have merely claimed the combination of known parts in the field to achieve predictable results and is therefore rejected under 35 USC 103.
As per claim 14, the combination of Du, Koropoff, Nagar, Bansal, Baughman and Grund further teach:
The computing system of claim 13, further comprising instructions to: monitor a performance of the cluster when the cluster is running the use case. (Baughman [0031])
As per claim 15, the combination of Du, Koropoff, Nagar, Bansal, Baughman and Grund further teach:
The computing system of claim 14, further comprising instructions to: output performance metrics associated with the monitored performance of the cluster to a dashboard user interface. (Baughman [0040].)
As per claim 16, the combination of Du, Koropoff, Nagar, Bansal, Baughman and Grund further teach:
The computing system of claim 15, further comprising instructions to: change the amount of computing resources assigned to the cluster, based on edit inputs received from a user via the dashboard user interface. (Baughman [0031] and [0041].)
As per claim 17, the combination of Du, Koropoff, Nagar, Bansal, Baughman and Grund further teach:
The computing system of claim 13, further comprising instructions to: monitor a status of the cluster when the cluster is not running the use case. (Grund col 11, line 52 – col 12, line 10.)
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 – 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at 5712701014. 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.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196
Prosecution Insights