DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 (similarly claim 12) recites the limitation "the identified classes". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear if “the identified classes” is referring to the predetermined class or the one or more classes.
Claim 1 (similarly claims 4, 5, 6, 12, 15, 16) recite: “the classes”. There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear if the classes are referring to one or more classes or some other classes.
Claim 3 (similarly claim 14) recite: “the total number of instances”. There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear if the total number of instances are referring to the total number of compute instances or other instances.
Claim 3 (similarly claims 4, 5, 6, 8, 10, 14-17 and 19) recite: “the compute instances”. The examiner is unclear if “the compute instances” is referring to “the total number of instances” or particular compute instances.
Claim 5 (similarly claims 6, 7, 9, 16-18 and 20) recite: “the compute instances with the lowest cost”. There is insufficient antecedent basis for this limitation in the claim.
Claim 6 (similarly claim 17) recite: estimating “the usage” There is insufficient antecedent basis for this limitation in the claim.
Claim 7 (similarly claims 9, 10, 18, 20) recite: “the class” for the compute task and/or the class of compute instances with the lowest cost. There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear if “the class” is referring to the one class of claim 1 or some other class.
Claims 2-11 and 13-20 are rejected based on rejection of its corresponding dependent claim.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-8 and 10-19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Shih et al. (Pub 20140229221) (hereafter Shih).
As per claim 1, Shih teaches:
A method performed by a customer account management system of a customer account associated with a cloud computing platform, the method comprising:
receiving a request for performing a compute task on the cloud computing platform, from a user associated with the customer account; ([Paragraph 1], For example, data centers housing significant numbers of interconnected computing systems have become commonplace, such as private data centers that are operated by and on behalf of a single organization and public data centers that are operated by entities as businesses to provide computing resources to customers. [Paragraph 32], In the illustrated embodiment, resource management system 100 includes a resource manager 180 operable to perform a variety of operations in response to requests submitted by a client 148… [Paragraph 132], For example, in at least some embodiments and situations, a client may represent an organization or other group (e.g., a company that has multiple people instead of an individual person). Thus, a client entity may have various forms in various embodiments.)
identifying a predetermined class for the compute task based on one or more features of the compute task; ([Paragraph 23], According to one such embodiment, a resource manager in such an environment may receive a task execution query comprising a specification of a task to be performed for a client, where the specification has an associated target deadline for completion of the task and an associated budget constraint for completion of the task. In response, the resource manager may generate an execution plan for the task, where the execution plan comprises using one or more resources of a selected resource pool to perform at least a portion of the task… [Paragraph 39], As noted above, the resource instances 130 of a provider network may be grouped into classes or categories based on several different dimensions in some embodiments, and the pricing policies associated with different classes may differ. Some of the categories may be reflected in the manner in which the resources are organized into pools, as indicated in FIG. 1. FIGS. 2a and 2b illustrate example resource instance classification approaches, according to at least some embodiments. FIG. 2a illustrates an approach in which instances are classified based in part on the timing or duration of instance allocations, i.e., on when instances are obtained by clients and when they are released by the clients. Three high-level types 201 of resource instances are shown: reserved instances 203, on-demand instances 205, and spot-instances 207, each with respective pricing policies 203P, 205P and 207P.)
identifying one or more classes of compute instances correlating to the compute task, based on a predetermined correlation rule; and ([Paragraph 23], According to one such embodiment, a resource manager in such an environment may receive a task execution query comprising a specification of a task to be performed for a client, where the specification has an associated target deadline for completion of the task and an associated budget constraint for completion of the task. In response, the resource manager may generate an execution plan for the task, where the execution plan comprises using one or more resources of a selected resource pool to perform at least a portion of the task. The resource pool may be selected based at least in part on the pricing policy of the resource pool and an analysis of the task specification. Other factors may also be taken into consideration in selecting the resource pool or resource type, such as whether the task or its subtasks can be resumed after an interruption without excessive overhead, and so on.)
performing a cost optimization process to determine one or more compute instances from one class of the identified classes for the requested compute task, wherein the cost optimization process further comprises: ([Paragraph 89], In some embodiments, using the systems and methods described herein, parameter values and/or computing resources for the execution of a task (e.g., configuration parameters for the resources) may be automatically selected to optimize a cost and/or a completion time for the execution of the task…)
determining a total number of the compute instances from each one of the classes for performing the compute task; ([Paragraph 22], Some clients may wish to take full advantage of the choices available among various pricing options, resource sizes, and the like, and the clients may be willing to specify the details for each of the resource instances that they need… Other clients may wish to specify a few constraints--such as the total number and/or sizes of instances to be used, or in the case of data transfer tasks, the total amount of data to be transferred from a specified source to a specified destination--and may wish to leave the selection of the resources to the resource manager. [Paragraph 37], As noted above, various other types of task execution queries may also be supported in some embodiments: e.g., queries requesting a least-estimated-cost plan, queries requesting plans that include acquiring a specified number and/or type of resource instance, or queries that request plans for data transfers of a specified amount of data or a specific data set…)
anticipating a time duration of executing the one or more compute instances from each one of the classes for performing the compute task; ([Paragraph 19], The resource management system may schedule and execute tasks using resources such as compute instances. In some embodiments, using the systems and methods described herein, a task may be scheduled to finish prior to a need-by time based on an estimated duration of the execution of the task. [Paragraph 23], According to one such embodiment, a resource manager in such an environment may receive a task execution query comprising a specification of a task to be performed for a client, where the specification has an associated target deadline for completion of the task and an associated budget constraint for completion of the task. In response, the resource manager may generate an execution plan for the task, where the execution plan comprises using one or more resources of a selected resource pool to perform at least a portion of the task. The resource pool may be selected based at least in part on the pricing policy of the resource pool and an analysis of the task specification. Other factors may also be taken into consideration in selecting the resource pool or resource type, such as whether the task or its subtasks can be resumed after an interruption without excessive overhead, and so on.)
calculating, for each one of the classes, a total cost for the one or more compute instances of the class, based on the total number of the compute instances, the time duration, and a predetermined unit price for the compute instance; and ([Paragraph 19], In some embodiments, using the systems and methods described herein, parameter values for the execution of a task (e.g., configuration parameters for the resources) may be automatically selected to optimize a cost and/or a completion time for the execution of the task. [Paragraph 44], FIG. 3 illustrates an example of a set of sources from which data may be gathered by resource manager 180 to generate task execution plans, according to one embodiment. As shown, the resource manager 180 may obtain task specifications 307, task budget goals (which may be expressed simply by indicating that the plan for the lowest feasible estimated cost should be generated) or constraints 309 (such as specified budget targets), and/or task timing constraints such as deadlines 311, from the task execution query 303 submitted by a client 148. In some embodiments, clients may specify instance count requirements 313 (e.g., a requirement that N instances of a particular type be allocated) and/or data transfer requirements 315 (e.g., indicating an amount of data to be transferred, or a specific data set to be transferred, from a specified source to a specified destination). The task specification 307 may indicate various details of the task, e.g., whether the task is a compute task or a data transfer task, what programs or executables are to be used for the task, how the success of the task is to be determined, performance-related requirements (such as minimum CPU power, memory size, network bandwidth), and so on. In embodiments where the client 148 is allowed to specify subtasks, the same kinds of information may be specified for each subtask. Budget constraints and timing constraints may also be specified at the subtask level as well as, or instead of, at the task level in some embodiments. Budget constraints 309 may include, for example, the total price the client is willing to pay for task or subtask completion or the maximum usage-based billing rate the client is willing to pay. Timing constraints 311 may indicate the deadline by which the task or subtask is to be completed. In some embodiments, specific budget constraints and/or timing constraints may be omitted, allowing the resource manager 180 even greater flexibility in planning and scheduling tasks and subtasks. [Paragraph 45], The pricing data 304 used by the resource manager 180 may include the current pricing in effect for the various types of resources (such as on-demand or spot instances) at various locations of the provider network as well as past variations in such prices over time. In some embodiments, the resource manager 180 may develop a predictive model that projects pricing changes in the future, e.g., based on pricing variations in the past. Especially for long-lasting tasks and subtasks, the projections of future pricing based on past trends may be useful in determining the execution plans for the client's query. [Paragraph 49], Each instance pool 121 may have associated resource management and pricing policies, governing for example whether a reservation or allocation of a resource instance can be interrupted, whether reservations of one client can be resold to another, the different types of static and dynamic pricing rates in effect for instances of the pool, and so on.)
ranking the one or more classes of compute instances, based on the total costs for each class. ([Paragraph 96], The constraints 605 applied to the optimization process performed by the optimization manager 610 may vary, e.g., as decided by the client. In one embodiment, the user may select either cost or completion time as a constraint on the optimization process. In some embodiments, the user may elect to use both cost and completion time as constraints. When both constraints are used, the relative order of the cost constraint and the completion time constraint may be determined using any suitable user interface techniques or elements. For example, either the cost constraint or the completion time constraint may be selected as the primary constraint, and the remaining constraint may be a secondary constraint. In one embodiment, a slider bar in a graphical user interface (GUI) may receive user input to determine a relative contribution of the cost constraint and the completion time constraint, with one end of the slider bar indicating 100% cost constraint (and 0% completion time constraint) and the other end of the slider bar indicating 100% completion time constraint (and 0% cost constraint). Additional constraints may also be applied to the optimization process. [Paragraph 101], The execution constraints may include the cost of executing the task, the completion time for the execution of the task, the likelihood of success or failure of the task, or a combination of any such constraints. Additional constraints may also be received, such as a location constraint (e.g., one or more specific regions or availability zones in the provider network 110). If more than one constraint is specified, the constraints may be identified in a relative order, such that one constraint is a primary constraint, another constraint is a secondary constraint, etc. [Paragraph 32], If an acceptable task execution plan is found, the resource manager 180 may schedule the tasks in accordance with the plans, using resources 130 selected from one or more pools 121 at one or more availability zones 120… [Paragraph 39], As noted above, the resource instances 130 of a provider network may be grouped into classes or categories based on several different dimensions in some embodiments, and the pricing policies associated with different classes may differ. [Paragraph 26], The resource manager may use the specified preferences and properties, the target deadline(s), and budget constraints in its attempt to identify the most suitable resources and/or resource pools for the client's tasks and/or subtasks… )
As per claim 2, rejection of claim 1 is incorporated:
Shih teaches determining availability of the total number of compute instances of each class on the cloud computing platform. ([Paragraph 19], In some embodiments, using the systems and methods described herein, parameter values for the execution of a task (e.g., configuration parameters for the resources) may be automatically selected to optimize a cost and/or a completion time for the execution of the task. [Paragraph 22], Some clients may wish to take full advantage of the choices available among various pricing options, resource sizes, and the like, and the clients may be willing to specify the details for each of the resource instances that they need. [Paragraph 31], FIG. 1 may be implemented, such as an "available instance" pool comprising currently idle instances, from which instances may be moved to other pools in response to instance enablement requests. It is noted that the pools may represent logical collections or aggregations, so that, for example, the presence of two instances in the same pool or sub-pool may not necessarily imply anything about the physical location of the hardware used for the two instances. [Paragraph 65], As shown in 460, one or more compute resources and/or configurations may be selected for execution of the task based on the anticipated usage cost. In one embodiment, the lowest-cost compute instance pool may be selected from the compute instance pools that are available to complete the execution of the task within the execution window, i.e., from the compute instance pools having an estimated duration allowing completion of the execution of the task prior to the need-by time. Because the anticipated cost may be dependent on the time of execution, the resource(s) and/or configuration(s) at different times of day may be compared in selecting the resource(s) and/or configuration(s) to minimize the cost of execution. In one embodiment, the task may correspond to a node in a graph that represents multiple tasks, and the global cost of executing all the tasks in the graph may be minimized.)
As per claim 3, rejection of claim 2 is incorporated:
Shih teaches selecting the class of the total number of instances having the lowest total cost; and determining a specific time of allocating the compute instances of the selected class. ([Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when. [Paragraph 29], In some embodiments, another supported query type may simply request that the resource manager generate the execution plan with the lowest estimated execution cost, e.g., without a specified budget limit or even a specified deadline. [Paragraph 32], If an acceptable task execution plan is found, the resource manager 180 may schedule the tasks in accordance with the plans, using resources 130 selected from one or more pools…)
As per claim 4, rejection of claim 3 is incorporated:
Shih teaches generating an output, the output recommending the class of the compute instances having the lowest total cost, the total number of the compute instances, and the specific time of allocating the compute instances to a decision maker of the customer; upon receiving an approval from the decision maker, sending a request for allocating the compute instances to the cloud computing platform; and causing the compute instances to be allocated to a cloud specific to the user on the cloud computing platform at the specific time. ([Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when. [Paragraph 29], In some embodiments, another supported query type may simply request that the resource manager generate the execution plan with the lowest estimated execution cost, e.g., without a specified budget limit or even a specified deadline. [Paragraph 32], If an acceptable task execution plan is found, the resource manager 180 may schedule the tasks in accordance with the plans, using resources 130 selected from one or more pools… [Paragraph 23], he resource pool may be selected based at least in part on the pricing policy of the resource pool and an analysis of the task specification. Other factors may also be taken into consideration in selecting the resource pool or resource type, such as whether the task or its subtasks can be resumed after an interruption without excessive overhead, and so on. The resource manager may provide an indication of the execution plan to the client in some embodiments, e.g., in order to receive an approval of the plan. The resource manager may then schedule an execution of at least a portion of the task on a resource from the selected resource pool.)
As per claim 5, rejection of claim 2 is incorporated:
Shih teaches wherein determining the availability of the compute instances further comprises: obtaining real-time usage data indicating a current usage of the compute instances of each one of the classes on the cloud computing platform; and determining whether the compute instances with the lowest cost are currently available, based on the real-time usage data and a total number of the compute instances of the class. ([Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when… In embodiments where the provider network resources are organized into pools with associated pricing policies, the resource instances to be used during any given period of time for the long-term computations may be selected from the appropriate pool, e.g., a spot-instance pool or an on-demand instance pool, based for example on a current pricing of resources of the pool and a current utilization level of the pool. [Paragraph 38], As subtasks are executed, or even during the execution of a given subtask or task, the resource manager 180 may in some embodiments regenerate or refresh the execution plan, e.g., based on current operational conditions and prices in the provider network. [Paragraph 19], In some embodiments, using the systems and methods described herein, parameter values for the execution of a task (e.g., configuration parameters for the resources) may be automatically selected to optimize a cost and/or a completion time for the execution of the task. [Paragraph 22], Some clients may wish to take full advantage of the choices available among various pricing options, resource sizes, and the like, and the clients may be willing to specify the details for each of the resource instances that they need. [Paragraph 31], FIG. 1 may be implemented, such as an "available instance" pool comprising currently idle instances, from which instances may be moved to other pools in response to instance enablement requests. It is noted that the pools may represent logical collections or aggregations, so that, for example, the presence of two instances in the same pool or sub-pool may not necessarily imply anything about the physical location of the hardware used for the two instances.)
As per claim 6, rejection of claim 2 is incorporated:
Shih teaches wherein determining the availability of the compute instances further comprises: estimating the usage of compute instances of each one of the classes for an anticipated time duration of executing the one or more compute instances; and determining whether the compute instances with the lowest cost are available during the anticipated time duration, based on the estimated usage and a total number of the compute instances of the class. ([Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when… In embodiments where the provider network resources are organized into pools with associated pricing policies, the resource instances to be used during any given period of time for the long-term computations may be selected from the appropriate pool, e.g., a spot-instance pool or an on-demand instance pool, based for example on a current pricing of resources of the pool and a current utilization level of the pool. [Paragraph 38], As subtasks are executed, or even during the execution of a given subtask or task, the resource manager 180 may in some embodiments regenerate or refresh the execution plan, e.g., based on current operational conditions and prices in the provider network. [Paragraph 19], In some embodiments, using the systems and methods described herein, parameter values for the execution of a task (e.g., configuration parameters for the resources) may be automatically selected to optimize a cost and/or a completion time for the execution of the task. [Paragraph 22], Some clients may wish to take full advantage of the choices available among various pricing options, resource sizes, and the like, and the clients may be willing to specify the details for each of the resource instances that they need. [Paragraph 31], FIG. 1 may be implemented, such as an "available instance" pool comprising currently idle instances, from which instances may be moved to other pools in response to instance enablement requests. It is noted that the pools may represent logical collections or aggregations, so that, for example, the presence of two instances in the same pool or sub-pool may not necessarily imply anything about the physical location of the hardware used for the two instances. [Paragraph 65], As shown in 460, one or more compute resources and/or configurations may be selected for execution of the task based on the anticipated usage cost. In one embodiment, the lowest-cost compute instance pool may be selected from the compute instance pools that are available to complete the execution of the task within the execution window, i.e., from the compute instance pools having an estimated duration allowing completion of the execution of the task prior to the need-by time. Because the anticipated cost may be dependent on the time of execution, the resource(s) and/or configuration(s) at different times of day may be compared in selecting the resource(s) and/or configuration(s) to minimize the cost of execution. In one embodiment, the task may correspond to a node in a graph that represents multiple tasks, and the global cost of executing all the tasks in the graph may be minimized. [Paragraph 52], Elements of the resource usage data that are relevant to an execution window for the submitted task may be used. In one embodiment, the execution window may begin with the submission of the task definition 405 by the client 148 and end at the need-by time. For example, if the execution window begins at 5 PM and ends at 11 PM on a Monday, then resource usage trends for various of the instance pools in the provider network 110 may be analyzed for the same times of the day on previous Mondays. The execution history for similar tasks may also be analyzed, where such history is available. In one embodiment, if the execution history for similar tasks is not available, then the user may be prompted to provide an estimated execution duration 415. In one embodiment, the estimated execution duration 415 may be determined by executing only a portion of the submitted task and then extrapolating the total estimated execution duration 415 from the partial execution duration. [Paragraph 53], By using the scheduling flexibility provided by the execution window, the cost of executing the task may be minimized. As discussed with respect to FIGS. 2a and 2b, each of the instance types may have a different pricing policy and associated cost. Accordingly, in some embodiments, the schedule manager 410 may schedule the task to execute using the lowest-cost instance pool that is available to complete execution of the task within the execution window for the task. Using the resource usage data, the schedule manager 410 may determine the estimated execution duration 415 of the submitted task for one or more instance pools in the provider network 110. In one embodiment, for example, the estimated execution duration 415 may be determined to be shorter for the on-demand instance pool 121B and longer for the spot instance pool 121C. Furthermore, the cost of using the instance pool with the shorter estimated execution duration (e.g., the on-demand instance pool 121B) to perform the submitted task may be more than the cost of using the instance pool with the longer estimated execution duration (e.g., the spot instance pool 121C). In one embodiment, therefore, the task may be scheduled to execute on the lower-cost (and slower) instance pool if the execution window is long enough to complete the task but on the higher-cost (and faster) instance pool otherwise.)
As per claim 7, rejection of claim 2 is incorporated:
Shih teaches wherein the class for the compute task is not a predetermined high-priority class, and the class of compute instances with the lowest cost is a class of on-demand compute instances specific to the customer. ([Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when… In embodiments where the provider network resources are organized into pools with associated pricing policies, the resource instances to be used during any given period of time for the long-term computations may be selected from the appropriate pool, e.g., a spot-instance pool or an on-demand instance pool, based for example on a current pricing of resources of the pool and a current utilization level of the pool.)
As per claim 8, rejection of claim 3 is incorporated:
Shih teaches wherein the predetermined class for the compute task is not a high-priority class, and the specific time of allocating the compute instances is in a predetermined off-peak period. ([Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when… In embodiments where the provider network resources are organized into pools with associated pricing policies, the resource instances to be used during any given period of time for the long-term computations may be selected from the appropriate pool, e.g., a spot-instance pool or an on-demand instance pool, based for example on a current pricing of resources of the pool and a current utilization level of the pool. [paragraph 45], For example, the resource manager may schedule the new tasks at a more lightly-utilized availability zone than one that is extremely busy. Projections for future resource utilizations may also be made based on past usage data, and may in some implementations be tied to projections of future pricing. Pricing data 304 and/or usage records 305 may be maintained in a repository such as resource management database 191 in some embodiments. In some implementations, the resource manager 180 may obtain current resource usage data from various monitoring agents distributed in the provider network, instead of or in addition to obtaining historical usage data from a repository.)
As per claim 10, rejection of claim 1 is incorporated:
Shih teaches wherein the one or more features of the requested compute task indicates that the compute task is to be performed in a specific availability zone (AZ) of the cloud computing platform, and the class of the compute instances with the lowest cost is specific to the AZ. ([Paragraph 25], In some embodiments, the provider network may be organized into a plurality of geographical regions, and each region may include one or more availability zones. An availability zone in turn may comprise one or more distinct locations or data centers, engineered in such a way that the resources in a given availability zone are insulated from failures in other availability zones. That is, a failure in one availability zone may not be expected to result in a failure in any other availability zone; thus, the availability profile of a resource instance is intended to be independent of the availability profile of a resource instance in a different availability zone. Clients may be able to protect their applications from failures at a single location by launching multiple application instances in respective availability zones… In some implementations, clients may also be able to specify preferred availability zones for their tasks and/or subtasks. [Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when…)
As per claim 11, rejection of claim 10 is incorporated:
Shih teaches refraining from recommending a cross-AZ compute instance for the requested compute task. ([Paragraph 25], That is, a failure in one availability zone may not be expected to result in a failure in any other availability zone; thus, the availability profile of a resource instance is intended to be independent of the availability profile of a resource instance in a different availability zone. Clients may be able to protect their applications from failures at a single location by launching multiple application instances in respective availability zones. At the same time, in some implementations, inexpensive and low latency network connectivity may be provided between resource instances that reside within the same geographical region (and network transmissions between resources of the same availability zone may be even faster). In some implementations, clients may also be able to specify preferred availability zones for their tasks and/or subtasks. [Paragraph 31], Not all the availability zones may implement the same sets of pools: for example, some availability zones may implement only reserved instance pools and on-demand pools, and may not implement a spot instance pool. [Paragraph 35], Location-related preferences (such as availability zones or regions in which the task should be scheduled) may also be provided by the client in some embodiments. )
As per claim 12-19, these are system claims corresponding to the method claims 1-8. Therefore, rejected based on similar rationale.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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, 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) 9 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shih in view of Brooker et al. (Pat 8,639,595) (hereafter Brooker).
As per claim 9, rejection of claim 1 is incorporated:
Shih teaches wherein the one or more features of the requested compute task indicate that the compute task is to be performed in a non-production cloud environment on the cloud computing platform, and the class of the compute instances with the lowest cost has an instance type of a single database compute instance. ([Paragraph 22], In some cases, clients may simply desire that a given task be completed at the lowest possible cost, regardless of exactly which resources are used or when… [Paragraph 107], In some embodiments, the configurable workflow service may provide internal storage locations for use by clients in storing their source data, with a particular data source corresponding to such an internal storage location, while in other embodiments and situations, a particular data source may be external to the configurable workflow service, such as one or more network-accessible storage systems that are provided by or otherwise controlled by the client, one or more online storage services, one or more online data generation services, etc. A non-exclusive list of examples of online storage services that may be used include the following: Amazon Simple Storage Service (S3) that stores object data of various types, Amazon Relational Database Service (RDS) that provides relational database functionality, Amazon SimpleDB that provides database functionality to store key-value pairs, Amazon DynamoDB service that provides NoSQL database functionality, Amazon Elastic Block Store (EBS) that provides access to raw block storage devices (e.g., mounting a virtual local block storage device on a target computer system), etc. A non-exclusive list of examples of online data generation services includes an RSS feed, the Amazon Cloudwatch Service that provides monitoring functionality for executing applications and services and generates corresponding information, etc. Data sources may thus be of various forms, such as a relational or other database (e.g., the HBase open-source distributed database, the BigTable distributed database, the MongoDB database system, the Apache Cassandra distributed database management system, etc.), a hash table, a file system, an object store, etc., optionally implemented in a distributed manner. A non-exclusive list of examples of data groups that may be obtained from a data source includes a file (e.g., a web server log), a database row or other record, a stored data object, a streamed group of data, etc.)
Although Shih teaches testing of execution time ([Paragraph 73]).
Shih does not explicitly disclose wherein the one or more features of the requested compute task indicate that the compute task is to be performed in a non-production.
Brooker teaches wherein the one or more features of the requested compute task indicate that the compute task is to be performed in a non-production. ([Column 6 line 57-67 and Column 7 line 1-2], The environment 100 may also include a development and/or testing side, which includes a user device 118 allowing a user such as a developer, data administrator, or tester to access the system. The user device 118 may be any appropriate device or machine, such as is described above with respect to the client device 102. The environment 100 may also include a development server 120, which functions similar to the application server 108 but typically runs code during development and testing before the code is deployed and executed on the production side and becomes accessible to outside users…)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Shih wherein a compute task request is received from a user of a customer, class(es)/pool(s) of resource(s) is/are identified based on the task feature(s), cost optimization process(es) is/are performed, number of resource(s) is/are determined to complete the task based on anticipated time and total cost, and resource(s) of class(es)/pool(s) is/are ranked based on total cost, into teachings of Brooker wherein an environment includes a testing environment for test execution, because this would enhance the teachings of Shih wherein by executing the task in the test environment, it provides a safe/isolated environment to test the execution prior to the task being implement in production environment.
As per claim 20, this is a system claim corresponding to the method claim 9. Therefore, rejected based on similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Madtha et al. (Pub 20180060106) discloses constraint requirements for an application(s), virtual machine(s), multi-tiered applications which includes different classes of compute resources.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
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, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights