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 .
Claims 1-9 are pending in this office correspondence.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. JP2023-005081, filed on 01/17/2023.
Drawings
The Drawings filed on 08/30/2023, have been acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/30/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112 (b)
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.
Claims 3-7 are rejected under 35 U.S.C. 112(b), 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 pre-AIA the applicant regards as the invention.
Dependent claim 3 (and similarly claims 4-7), recites the following limitations: “The cloud operation cost visualization system according to claim 1, …” (Emphasis Added)
The aforementioned claim(s) is/are dependent from Claim 1, wherein Claim 1 recites the following preamble – “An operation cost visualization system …” (Emphasis Added)
As mentioned above, Independent Claim 1 does not explicitly claim “A cloud operation cost visualization system”, meanwhile the aforementioned dependent claim(s) recite “The cloud operation cost visualization system according to claim 1”. The recitation of “The cloud operation cost visualization system” in the aforementioned dependent claim(s) creates a confusion since the term “cloud” is not explicitly defined in claim (1) which is being referenced in definitive form in dependent claims (3-7).
Consequently, there is insufficient antecedent basis for this term/limitation in the dependent claim language.
The aforementioned dependent claims (3-7) are rejected under 35 U.S.C. 112(b) for indefiniteness.
For the purpose of application examination, and for example, the examiner will interpret these claims preamble language to read as follows: “The operation cost visualization system according to claim 1, …”
Proper corrections are required.
Claim 8 is rejected under 35 U.S.C. 112(b), 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 pre-AIA the applicant regards as the invention.
The aforementioned claim recites the following preamble “An operation cost visualization system, …” The aforementioned preamble claim language seems to recite an independent claim recitation language. However, claim 1 already recites similar language as follows: “An operation cost visualization system …” This recitation of claim (8) language creates a confusion as to which claim is “An operation cost visualization system.”
Furthermore, claim (8) recites limitations in the definitive form, for example, “the dynamic parameters …”, “the impact parameter …”, “the designated operation task …”, “the processor …”, “the operation task …”, “the other operation tasks …” and “the result of the estimation.” If the aforementioned claim (8) was intended to be recited as in independent claim, then all of these definitive limitation terms have no insufficient antecedent basis to be recited in definitive form.
The aforementioned claim (8) is rejected under 35 U.S.C. 112(b) for indefiniteness.
For the purpose of application examination, and for example, the examiner will interpret this claim to be considered as a dependent claim from independent claim (1).
Therefore, and instead of the currently filed claim preamble reciting: “An operation cost visualization system, …”, the examiner suggests the claim preamble language of claim (8) to read as follows: “The operation cost visualization system according to claim 1, …” Consequently, overcoming the indefiniteness definitions of the claimed limitations mentioned above.
Proper corrections are required.
Claims (1 and 9) are rejected under 35 U.S.C. 112(b), 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 pre-AIA the applicant regards as the invention.
Independent claim 1 (and similarly claim 9), recites the following limitations: “…, an impact parameter indicating a parameter that affects costs of other operation tasks due to the operation task, …, and the dynamic parameters for other operation tasks” (Emphasis Added)
The aforementioned claim(s) recites the limitation of “other operation tasks” twice in the same claim limitation terms. This definition of “other operation tasks” leaves the examiner confused as to which “other operation tasks” the applicant is trying to define “other operation tasks” for later use, since this term is defined multiple times referencing potentially different limitations which does not define clearly the meets and bounds of this limitation.
Further, later in the aforementioned claim, the following reference is recited: “estimates the cost based on the impact calculation formula and a cost calculation table for calculating costs for the operation task and the other operation tasks, …” (Emphasis Added)
At this step, the examiner is confused as to which of the “other operation tasks” that are defined above that this “the other operation tasks” in definitive form is trying to reference at this step?
The aforementioned claim is are rejected under 35 U.S.C. 112(b) for indefiniteness.
For the purpose of application examination, and for example, the examiner will interpret this limitation to refence only one type of “other operation tasks.”
Proper corrections are required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-9 are rejected under 35 U.S.C 101 because the claimed invention is directed to abstract idea without significantly more.
Step 1:
The claims are directed to a process and a system, wherein the claimed process starts by receiving an operation task and an operation task cost related table, costs are compared in consideration of a cost of an entire operation task in an operation configured by combining plural operation tasks. Further, the operation task cost related table associates a cloud operation task, a dynamic cost parameter indicating a parameter that directly or indirectly affects a cost of an operation task, an impact parameter indicating a parameter that affects costs of other operation tasks due to the operation task, and an impact calculation formula for calculating a change or degree of impact by the dynamic cost parameter or the impact parameter. A user designates an operation task which is an estimation target regarding the cloud, specifies the dynamic parameters corresponding to the designated operation task and the dynamic parameters for other operation tasks including the impact parameters corresponding to the dynamic parameters, and estimates the cost.
Step 2A – Prong One – The claims recite an abstract idea
Independent claims 1 and 20 are directed to an abstract idea without significantly more.
The claim(s) recites the following limitation: “specifies the dynamic parameters corresponding to the designated operation task and the dynamic parameters for other operation tasks including the impact parameters corresponding to the dynamic parameters, based on the received operation task and the operation task cost related table.” The recited claim language of “specifies the dynamic parameters …”, which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components. That is, other than reciting: “system”, “processor” and/or “memory”, nothing in the claim element precludes the steps from practically being performed in a human mind. For example, and given some information at hand, a person is mentally capable, or with the aid of pen and paper, to assign information details to some labels/parameters, which is (for example) obvious from the specification of the instant application illustrating this information in a table of figure 6, which is a mental process.
The aforementioned claim continues to recite the following – “estimates the cost based on the impact calculation formula and a cost calculation table for calculating costs for the operation task and the other operation tasks, and outputs a result of the estimation.” At this step, the claimed language of: “estimates the cost based on the impact calculation formula …”, which include series of steps that recite a mathematical calculation/formula for analyzing information and calculating an output based on mathematical steps, which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components. That is, other than reciting “system”, “processor” and/or “memory”, nothing in the claim element precludes the steps from practically being performed by a person, or with the aid of pen and paper, to analyze information and perform a calculation as explained above, which are steps grouped under abstract idea of mathematical calculation to compute an output.
As explained above, a process of “specifies the dynamic parameters, …” and “estimates the cost based on the impact calculation formula …” are nothing more than an abstract idea. Consequently, if a claim limitation, under its broadest reasonable interpretation, covers an abstract idea that includes a series of steps that recite mental steps, but for the recitation of generic computer components, then it falls within the “Mental Processes and/or Mathematical Calculation” grouping of “Abstract Ideas”. Accordingly, the aforementioned claim(s) recite abstract ideas.
Step 2A – Prong Two - The abstract idea is not integrated into a practical application
This judicial exception is not integrated into a practical application. In particular, the aforementioned claim(s) recites the additional limitation – “the computer stores, in the memory, an operation task cost related table that associates the cloud operation task, ...” This recited language of “the computer stores, in the memory, an operation task cost related table, …” is considered to be extra-solution activities of mere data transmission activity. In this context, “stores” is an activity that is considered data manipulation activity for simply enabling a person to deal with information/data, and analyze the content of this information, which is considered to be an insignificant extra-solution activity to the judicial exception, for which an extra-solution activity includes both pre-solution and post-solution activity. In this example, the aforementioned claim limitations amount to mere data-updating/transmission step, and is considered an insignificant extra-solution activity because it is a mere nominal or tangential addition to the claim, a mere generic process of transmission of collected and analyzed data, see MPEP 2106.05(g).
Further, the aforementioned claim(s) recites the following limitation – “receives, from a user, designation of an operation task which is an estimation target regarding the cloud.” This recited language of “receives, from a user, designation of an operation task, …” is considered to be extra-solution activities of mere data gathering activity. In this context, “receives, from a user, …” is an activity that is considered data manipulation activity for simply enabling a person to deal with information/data, and analyze the content of this information, which is considered to be an insignificant extra-solution activity to the judicial exception, for which an extra-solution activity includes both pre-solution and post-solution activity. In this example, the aforementioned claim limitations amount to mere data-gathering step, and is considered an insignificant extra-solution activity because it is a mere nominal or tangential addition to the claim, a mere generic process of transmission of collected and analyzed data.
Additionally, the courts have decided that the use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components after the fact to an abstract idea, does not integrate a judicial exception into a practical application or provide significantly more, see MPEP 2106.05(f) and MPEP 2106.05(g).
The additional elements recited in the aforementioned claim(s) are: “system”, “processor” and/or “memory”. The additional elements of using a computer, storage device(s) and processor(s) to obtain information, analyze information, and manipulate information amounts to no more than mere instructions to apply the exception using a generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. See MPEP 2106.05(f).
Step 2B:
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The insignificant extra-solution activities identified above, which include the data-transmission activity: “the computer stores, in the memory, an operation task cost related table, …”; and the data-gathering activity: “– “receives, from a user, designation of an operation task, …”, which are also considered mere instruction activities, and are recognized by the courts as well-understood, routine, and conventional activities when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity (See MPEP 2106.05(d)(II)(i) Receiving or transmitting data over a network, e.g., using the Internet to gather data, buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); (v) Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93).
Additionally, the “system”, “processor” and/or “memory” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component that are well-know and conventional and cannot provide an inventive concept.
Thus, there are no additional elements that amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that any combination of elements improves the functioning of a computer or improves any other technology.
The claim(s) is not patent eligible.
Claim 2 is dependent on claim 1 and includes all the limitations of claim 1. Further, the aforementioned claim recites the additional limitations of “the processor specifies the impact parameter corresponding to the specified dynamic parameter for the other operation task, executes processing of specifying the dynamic parameter for a still other operation task including the specified impact parameter, and repeats the processing until the impact parameter is no longer specified.” The recited language of “executes processing of specifying the dynamic parameter …”, recites an insignificant extra-solution activity of data transmission and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea.
Claim 3 is dependent on claim 1 and includes all the limitations of claim 1. The aforementioned claim recites the additional limitations of “the computer stores the cost calculation table in the memory in association with an operation task, the dynamic parameter of the operation task, and a cost calculation formula for calculating a cost incurred by executing the operation task”. The claim language of “stores the cost calculation table …”, which recites an insignificant extra-solution activity of data transmission and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea.
Further, the aforementioned claim recites the following limitation(s) – “the processor acquires metrics from the cloud for the specified dynamic cost parameters, predicts a value of the dynamic parameter in the operation task from already acquired past metrics, and calculates the cost using the cost calculation formula defined by the cost calculation table.” Again, the claim language of “the processor acquires metrics from the cloud for the specified dynamic cost parameters, …”, which recites an insignificant extra-solution activity of data gathering and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea.
Claim 4 is dependent on claim 1 and includes all the limitations of claim 1. The aforementioned claim recites the additional limitations of “the computer stores, in the memory, an operating personnel management table that associates the user and a skill level of the user, and a personnel expenses skill related table that associates the skill of the user and personnel expenses according to the skill.” The recited language of “the computer stores …”, which recites an insignificant extra-solution activity of data transmission and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea.
Further, the aforementioned claim recites the following limitation(s) – “the processor estimates the personnel expenses affected by the operation task based on the operation management table, the cost calculation table, and the personnel expenses skill related table for the other operation tasks corresponding to the specified dynamic cost parameter.” At this step, the claim language of “the processor estimates, …”, which recites an abstract idea of performing a mental step of data manipulation, which does not amount to significantly more than the abstract idea.
Claim 5 is dependent on claim 1 and includes all the limitations of claim 1. The aforementioned claim recites the additional limitations of “the processor extracts the dynamic cost parameters for each of a plurality of the operation tasks registered in the operation task cost related table, measures metrics for each of the extracted dynamic parameters, and when it is determined that there is a relationship between the dynamic parameters based on the measured metrics and a predetermined statistical relational expression, registers the dynamic parameter determined to have the relationship as the impact parameter.” The recited claim language of: “the processor extracts the dynamic cost parameters …”, which recites an insignificant extra-solution activity of data gathering and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea. Further, the recited claim language of: “measures metrics for each of the extracted dynamic parameters …”, which recites an abstract idea of data analysis where a person can mentally, or with the aid of pen and paper, be able to apply some measures/metric to information at hand. Additionally, the recited claim language of: “registers the dynamic parameter determined to have the relationship as the impact parameter”, which recites an insignificant extra-solution activity of data transmission and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea.
Claim 6 is dependent on claim 1 and includes all the limitations of claim 1. The aforementioned claim recites the additional limitations of “the processor uses an exchange rate table that defines a latest exchange rate according to a type of currency and values for each type of currency to update information on a cost in the cost calculation table each time exchange rate fluctuations occur.” Again, at this step, the claim recites – “the processor uses an exchange rate table that defines a latest exchange rat …”, which disclose mental steps that a person can mentally perform, or with the use of pen and paper, which recites a mere mental step of information evaluation to be applied by a processor to apply mere instruction steps, which does not amount to significantly more than the abstract idea.
Claim 7 is dependent on claim 1 and includes all the limitations of claim 1. The aforementioned claim recites the additional limitations of “the computer stores, in the memory, an operation task relevance table that associates a category for classifying types of operation tasks, an operation task classified by the category, a similar operation task indicating an operation task similar to the operation task, and an assumed cost for the operation task.” The recited language of “the computer stores, in the memory, …”, which recites an insignificant extra-solution activity of data transmission and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea.
Further, the aforementioned claim recites the following limitation(s) – “the processor outputs the cost of the similar operation task, using the operation task relevance table, when the assumed cost of the operation task registered as the similar operation task among the operation tasks of the same category as the operation task for which the cost was estimated is lower than that of the operation task for which the cost was estimated.” Again, the claim language of “the processor outputs the cost of the similar operation task, …”, which recites an insignificant extra-solution activity of data transmission and/or mere instructions to apply the exception using a generic computer component, which does not amount to significantly more than the abstract idea.
Claim 8 is dependent on claim 1 and includes all the limitations of claim 1. The aforementioned claim recites the additional limitations of “when the dynamic parameters for other operation tasks including the impact parameter corresponding to the dynamic parameter corresponding to the designated operation task are specified, the processor outputs a screen showing a causal relationship between the operation task and the other operation tasks, including the result of the estimation.” The recited language of “the processor outputs a screen showing a causal …”, which recites an insignificant extra-solution activity of data transmission, which does not amount to significantly more than the abstract idea.
Independent claim 9 recites similar limitations to claim 1 and therefore rejected for the same reasons as explained above.
The aforementioned claims are not patent eligible.
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 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.
Claims 1-9 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication (US 20160321115 A1) issued to Thorpe et al. (hereinafter as “THORPE”), and in view of US Patent Application Publication (US 20210318912 A1) issued to Hashimoto et al. (hereinafter as “HASHIMOTO”).
Regarding claim 1, THORPE teaches an operation cost visualization system for estimating and visualizing a cost of a cloud operation task by a computer having a processor and a memory (memory (THORPE Para. [0015]: “…, a system for managing cloud compute resources is provided. The system comprises at least one processor operatively connected to a memory, the at least one processor when executing configured to: display execution characteristics associated with a first class of resources, ...”; and
Para. [0049]: “…, after a database of prices for Resources has been generated and/or stored for each provider, the database can be augmented with the expected performance of each Resource for a particular class of computation.”), wherein
the computer stores, in the memory, an operation task cost related table that associates the cloud operation task, a dynamic cost parameter indicating a parameter that directly or indirectly affects the cost of the operation task, an impact parameter indicating a parameter that affects costs of other operation tasks due to the operation task, and an impact calculation formula for calculating a change or degree of impact by the dynamic cost parameter or the impact parameter (THORPE the examiner notes that the reference discloses in Fig. 2A/2B cloud resource tables with prices based on resource usage parameters.; and
the reference discloses in Para. [0049]: “…, after a database of prices for Resources has been generated and/or stored for each provider, the database can be augmented with the expected performance of each Resource for a particular class of computation. …, in a cloud testing application, Customer can run a software's test framework on various Resources available from Provider, then assigns performance characteristics to each Resource. This assignment can be made by manual estimate, performance against standard benchmarks, or performance on a particular application or even instantiation of an application (such as a testing application running a particular suite of tests.) These performance characteristics may include any relevant data, for example: efficiency of computation (time to complete a benchmark); available RAM memory; available storage; network throughput, latency and bandwidth costs to a particular data store; co-tenants (other Customers using the same Resources, such as the same computing nodes, network bandwidth, or remote storage, at the same time), etc. Then each available Resource can be evaluated on the basis of cost per unit of performance.”; and
Para. [0052]: …”, characteristics of a task are provided when the task is defined and submitted to a Provider. In other embodiments, the system running a task records and stores characteristics about certain tasks that Customer may designate as likely to be run again (“repeated tasks”).”; and
Para. [0076]: “Spot kills are typically the result of a providers' resources becoming worth more to other participants in the market than the customer to which the resources are currently allocated. … an example, the time series of price data described above is used to predict a probability distribution over the possible prices of the resource for the near future, during which a compute task is contemplated to be executed. Using standard statistical methods on this distribution, the probability of a spot kill can be calculated from the probability that the price will exceed the customer's bid. If, based on analysis of prior prices from which the distribution is derived, the probability is high, e.g. 90%, that the price will exceed the customer's bid, then a spot kill is likely. In other example, different probabilities can be used (e.g., 95%, 85, 86, 87, 88, 89, 91, 92, 93, 94 etc.).”,
the examiner notes that the reference discloses a database of prices for Resources to that of a task cost table, and the reference discloses resources needs relevant data, for example: efficiency of computation (time to complete a benchmark); available RAM memory; available storage; network throughput, latency and bandwidth costs to a particular data store; co-tenants (other Customers using the same Resources, such as the same computing nodes, network bandwidth, or remote storage, at the same time; to that of the claimed dynamic cost parameter, an impact parameter and other operation tasks due to the operation task. Further, the reference discloses an example of analysis of prior prices from which the distribution is derived, see Para. [0076], to calculate from the probability that the price of prior prices when to meet customer's price bid to that of the claimed an impact calculation formula for calculating a change or degree of impact by the dynamic cost parameter)
However, THORPE does not explicitly teach the processor receives, from a user, designation of an operation task which is an estimation target regarding the cloud, specifies the dynamic parameters corresponding to the designated operation task and the dynamic parameters for other operation tasks including the impact parameters corresponding to the dynamic parameters, based on the received operation task and the operation task cost related table, and estimates the cost based on the impact calculation formula and a cost calculation table for calculating costs for the operation task and the other operation tasks, and outputs a result of the estimation.
But HASHIMOTO discloses the processor receives, from a user, designation of an operation task which is an estimation target regarding the cloud, specifies the dynamic parameters corresponding to the designated operation task and the dynamic parameters for other operation tasks including the impact parameters corresponding to the dynamic parameters, based on the received operation task and the operation task cost related table, and estimates the cost based on the impact calculation formula and a cost calculation table for calculating costs for the operation task and the other operation tasks, and outputs a result of the estimation (HASHIMOTO Fig. 1, Para. [0027]: “FIG. 1 shows a cost estimator framework 100 for providing a cost estimate to one or more client computers 101 based on resources planned or configured for being provisioned from one or more cloud providers 103. The cost estimator framework 100 includes a cost estimator system 102, which includes a number of processing modules to receive data representing a set of resources, such as a configuration file, for some or all of a cloud-based infrastructure. For instance, the resources can represent a change or upgrade to a cloud-based computing function or application, or can represent a change in a number of instances employed by an organization's cloud-based infrastructure. The output of the cost estimator system 102 is a pricing report.”; and
Fig. 1, Para. [0028]: “The cost estimator system 102 includes a client API 104 that communicates data from the processing modules to the client computer(s) 101. The processing modules include an input module 106 that is configured to receive inputs such as cloud-based infrastructure configurations or changes, workspace variables, a current state of an already-provisioned cloud infrastructure, etc. These inputs are provided by the input module 106 to a planning module 108, which can also receive configurations and proposed changes from one or more developers that provide a technical specification for the one or more cloud-based applications. The planning module 108 assembles the inputs to generate a cloud infrastructure plan for a run-phase that will accommodate the technical specification and proposed changes to the cloud-based infrastructure configuration. The technical specification and proposed changes can be sent to the client computer(s) 101 via the API 104.”; and
Fig. 1, Para. [0031]: “A process for cost estimation includes a step to split, divide or allocate resources in the prior state and proposed changes among two or more cloud providers 103. Those split resources are sent to the price resolvers 112, which in turn request price data from the cloud APIs 103 to the cloud providers. The price resolvers search price data, and estimate costs of each requested resource based on the configuration or plan. The price resolvers 112 can format results according to prior, proposed and delta costs. The costs are then returned to the cost estimator module 110, which sends the prior, proposed and/or delta costs to the client computer(s) 101.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of THORPE (disclosing methods for cost optimization of cloud computing resource) to include the teachings of HASHIMOTO (disclosing methods for cost estimation for a cloud-based infrastructure provisioning system) and arrive at a method to estimate cost of cloud resources needs based on a client request. One of ordinary skill in the art would have been motivated to make this combination because when a cost estimator system receives a configuration request or changes for a cloud-based infrastructure, which include data representing one or more computing resources needed for a cloud-based application, a price resolver resolves a price of the resources that are part of the new configuration, thereby providing a cost estimate for the new configuration of the cloud-based infrastructure aiding a network operation manager to take an informed decision, as recognized by (HASHIMOTO Abstract, Para. [0011]-[0017]). In addition, the references of THORPE and HASHIMOTO teach features that are directed to analogous art and they are directed to the same field of endeavor of cloud resource allocation and management.
Regarding claims (9), the aforementioned claims recite similar limitations to claim 1, and therefore rejected for similar reasons as discussed above.
Regarding claim 2, the combination of THORPE and HASHIMOTO teach the limitations of claim 1. Further, THORPE teaches that the processor specifies the impact parameter corresponding to the specified dynamic parameter for the other operation task, executes processing of specifying the dynamic parameter for a still other operation task including the specified impact parameter, and repeats the processing until the impact parameter is no longer specified (THORPE Para. [0052] In some embodiments, characteristics of a task are provided when the task is defined and submitted to a Provider. In other embodiments, the system running a task records and stores characteristics about certain tasks that Customer may designate as likely to be run again (“repeated tasks”). In these embodiments, characteristics important to resource allocation, including processor time, total memory utilization, storage input/output, network bandwidth, database accesses, and potentially others, are reported by the Resources or the system managing the Resources during the execution of the task and stored in one or more databases for future analysis. Once the task has been executed, the resources required for a future execution of the same task can be estimated using various standard prediction tools described herein, or tools described elsewhere in the literature. There is no guarantee that a future execution will require the same resources, but for tasks that are repeated frequently, past patterns do emerge and can be used to automatically optimize resource allocation.”).
Regarding claim 3, the combination of THORPE and HASHIMOTO teach the limitations of claim 1. Further, THORPE teaches wherein the computer stores the cost calculation table in the memory in association with an operation task, the dynamic parameter of the operation task, and a cost calculation formula for calculating a cost incurred by executing the operation task (THORPRE Fig. 6A/B, Para. [0049]: “…, after a database of prices for Resources has been generated and/or stored for each provider, the database can be augmented with the expected performance of each Resource for a particular class of computation. …, in a cloud testing application, Customer can run a software's test framework on various Resources available from Provider, then assigns performance characteristics to each Resource. This assignment can be made by manual estimate, performance against standard benchmarks, or performance on a particular application or even instantiation of an application (such as a testing application running a particular suite of tests.) These performance characteristics may include any relevant data, for example: efficiency of computation (time to complete a benchmark); available RAM memory; available storage; network throughput, latency and bandwidth costs to a particular data store; co-tenants (other Customers using the same Resources, such as the same computing nodes, network bandwidth, or remote storage, at the same time), etc. Then each available Resource can be evaluated on the basis of cost per unit of performance.”), and
the processor acquires metrics from the cloud for the specified dynamic cost parameters, predicts a value of the dynamic parameter in the operation task from already acquired past metrics, and calculates the cost using the cost calculation formula defined by the cost calculation table (THORPE Para. [0043]: “Further embodiments also store other data relevant to predicting characteristics of Resources in the future, such as prices and availability. The data may include whether particular resources are available (or unavailable) at a particular time, instance “steal” (a measure of how much of the Resources available to an instance is used by other co-tenants or the Provider's infrastructure), performance of input/output interfaces, day of week and holiday schedules, any special events (such as a reduced supply due to a significant outage or increased demand due to retail and e-commerce analytics activity common during the holiday shopping season), and any other pertinent information that can be gathered, tracked and recorded.”; and
Para. [0072]: “…, the system monitors the Resource prices for all running Instances and both updates their current prices in the time series and their predicted future prices, all as quickly as possible. In many cases, changes in actual real-time prices will lead to updating the expectation of future prices; as the hour from 1 pm to 2 pm passes, the price at 3 pm is an hour closer and the system uses a 2 pm price to help the system increase accuracy in a prediction—a system may be configured to make better predictions of every future moment as each hour passes. Thus, although changes in current prices may not be substantial enough to lead immediately to a spot kill, changes in current prices may be substantial enough to lead the predictive model to predict higher prices in the future than were expected when the computation was planned, the spot price was bid, and the instance was allocated. If these predicted prices are higher than the bid price for the spot Instance, then a system can infer the likelihood that these predicted prices will occur, triggering a spot kill. A system can also predict that likelihood over time. In practice, the time series changes as new information comes in, and predictions can be continuously calculated and updated.”,
the reference discloses that data collection provides a measure of how much of the Resources available to an instance is used by other co-tenants or the Provider's infrastructure to that of metrics from the cloud for the specified dynamic parameters).
Regarding claim 4, the combination of THORPE and HASHIMOTO teach the limitations of claim 1. Further, HASHIMOTO teaches wherein the computer stores, in the memory, an operating personnel management table that associates the user and a skill level of the user, and a personnel expenses skill related table that associates the skill of the user and personnel expenses according to the skill, and the processor estimates the personnel expenses affected by the operation task based on the operation management table, the cost calculation table, and the personnel expenses skill related table for the other operation tasks corresponding to the specified dynamic cost parameter (HASHIMOTO Para. Fig. 1, Para [0039]: “The policy module 114 enables an organization to define policies that are enforced against infrastructure between the plan and apply phases of an infrastructure provisioning process. … the policy module 114 is a policy-as-code framework in which the policies can be coded and stored in the cost estimator system 102. Compared to many tools that scan existing infrastructure for policy infractions, the policy module 114 proactively prevents provisioning of out-of-policy infrastructure and gives teams the confidence that all changes they deploy and within the organization's policy. The policy module 114 is configured to ensure that consistent financial governance is applied to infrastructure changes. For example, in some implementations, the policy module 114 can implement and enforce a quota system, whereby teams or groups can be assigned a maximum spend quota. Therefore, instead of developers waiting weeks or longer to provision infrastructure, which becomes a bottleneck for deployment, policy-as-code allows an organization to separate the definition of the policy from the execution of the policy.”).
Regarding claim 5, the combination of THORPE and HASHIMOTO teach the limitations of claim 1. Further, THORPE teaches wherein the processor extracts the dynamic cost parameters for each of a plurality of the operation tasks registered in the operation task cost related table, measures metrics for each of the extracted dynamic parameters, and when it is determined that there is a relationship between the dynamic parameters based on the measured metrics and a predetermined statistical relational expression, registers the dynamic parameter determined to have the relationship as the impact parameter (THORPE Para. [0076]: “ Spot kills are typically the result of a providers' resources becoming worth more to other participants in the market than the customer to which the resources are currently allocated. This is true both in providers such as Amazon EC2, where the prevailing spot bid exceeds a customer's spot bid, and Google Compute Platform, where the instance is pre-empted by another customer. In order to predict the likelihood of a spot kill, in one embodiment using Amazon EC2 spot instances as an example, the time series of price data described above is used to predict a probability distribution over the possible prices of the resource for the near future, during which a compute task is contemplated to be executed. Using standard statistical methods on this distribution, the probability of a spot kill can be calculated from the probability that the price will exceed the customer's bid. If, based on analysis of prior prices from which the distribution is derived, the probability is high, e.g. 90%, that the price will exceed the customer's bid, then a spot kill is likely. In other example, different probabilities can be used (e.g., 95%, 85, 86, 87, 88, 89, 91, 92, 93, 94 etc.).”).
Regarding claim 6, the combination of THORPE and HASHIMOTO teach the limitations of claim 1. Further, THORPE teaches wherein the processor uses an exchange rate table that defines a latest exchange rate according to a type of currency and values for each type of currency to update information on a cost in the cost calculation table each time exchange rate fluctuations occur (THORPE Para. [0105]: “…, a Provider might publish a spot price of $0.25 per hour for a Resource and be relatively certain that the Resource's spot price will not exceed $0.30 per hour in the next 12 hours. Customers do not know this with as much certainty as a Provider and may be willing to pay a premium to “lock in” a spot price for the expected length of their computation—a fair exchange for eliminating the risk of a spot kill Because the Provider has a better estimate of the risk of the spot kill than the Customer, the Provider is more likely to make more money from Customers than this process allowing Customers to pay even less.”).
Regarding claim 7, the combination of THORPE and HASHIMOTO teach the limitations of claim 1. Further, THORPE teaches wherein the computer stores, in the memory, an operation task relevance table that associates a category for classifying types of operation tasks, an operation task classified by the category, a similar operation task indicating an operation task similar to the operation task, and an assumed cost for the operation task (THORPE Para. [0043]: “Further embodiments also store other data relevant to predicting characteristics of Resources in the future, such as prices and availability. The data may include whether particular resources are available (or unavailable) at a particular time, instance “steal” (a measure of how much of the Resources available to an instance is used by other co-tenants or the Provider's infrastructure), performance of input/output interfaces, day of week and holiday schedules, any special events (such as a reduced supply due to a significant outage or increased demand due to retail and e-commerce analytics activity common during the holiday shopping season), and any other pertinent information that can be gathered, tracked and recorded.”), and
the processor outputs the cost of the similar operation task, using the operation task relevance table, when the assumed cost of the operation task registered as the similar operation task among the operation tasks of the same category as the operation task for which the cost was estimated is lower than that of the operation task for which the cost was estimated (THORPE Para. [0007]: “…, analyzing, by the computer system, stored characteristics of prior task execution; and predicting, by the computer system, future characteristics of identical or similar tasks; wherein the act of determining, by the computer system, a duration of a reservation period for spot instances longer that an individual spot instance time unit, incorporates the prediction of future characteristics of the submitted compute task based on analysis of characteristics of prior execution of tasks identical or similar to the submitted compute task; wherein the act of accepting, executing, and completing the task on the one or more providers, incorporates the prediction of future characteristics of the submitted compute task, based on analysis of characteristics of prior execution of tasks identical or similar to the submitted compute task, in planning the execution and completion of the task.”).
Regarding claim 8, the combination of THORPE and HASHIMOTO teach the limitations of claim 1. Further, HASHIMOTO teaches wherein when the dynamic parameters for other operation tasks including the impact parameter corresponding to the dynamic parameter corresponding to the designated operation task are specified, the processor outputs a screen showing a causal relationship between the operation task and the other operation tasks, including the result of the estimation (HASHIMOTO Fig. 1, Para. [0027]: “FIG. 1 shows a cost estimator framework 100 for providing a cost estimate to one or more client computers 101 based on resources planned or configured for being provisioned from one or more cloud providers 103. The cost estimator framework 100 includes a cost estimator system 102, which includes a number of processing modules to receive data representing a set of resources, such as a configuration file, for some or all of a cloud-based infrastructure. For instance, the resources can represent a change or upgrade to a cloud-based computing function or application, or can represent a change in a number of instances employed by an organization's cloud-based infrastructure. The output of the cost estimator system 102 is a pricing report.”; and
Fig. 1, Para. [0031]: “A process for cost estimation includes a step to split, divide or allocate resources in the prior state and proposed changes among two or more cloud providers 103. Those split resources are sent to the price resolvers 112, which in turn request price data from the cloud APIs 103 to the cloud providers. The price resolvers search price data, and estimate costs of each requested resource based on the configuration or plan. The price resolvers 112 can format results according to prior, proposed and delta costs. The costs are then returned to the cost estimator module 110, which sends the prior, proposed and/or delta costs to the client computer(s) 101.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Dailianas et al.; (US 20200314174 A1); “Methods for cost and performance-based management of resources in a cloud environment, wherein cloud-based services may be priced as templates, reserved instances, or a combination.”
Brown et al.; (US 12204939 B1); “Methods for managing cloud pricing and what-if analysis to meet service level goals, wherein estimating runtime and pricing metrics executing tasks may be determined based on resource allocation, priority scheduling, and workload management, especially but not exclusively, in a cloud environment, which can be very dynamic and have financial costs associated with it.”
Shear et al.; (US 20140282586 A1); “Methods for cloud resource computing optimization, wherein by use of metrics, relationships, evaluations, assertions and/or other processing may vary over time, and these dynamic variations may impact their perceived and/or calculated values, including, importance and/or relevance.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zuheir A Mheir whose telephone number is (571)272-4151. The examiner can normally be reached on Monday - Friday 9:00 - 5:00.
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, Ajay Bhatia can be reached on (571)272-3906. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
1/23/2026
/ZUHEIR A MHEIR/Patent Examiner, Art Unit 2156
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198