DETAILED ACTION
This office action is in response to claims filed 31 May 2023.
Claims 1-20.
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(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 6 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 13-16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by BERNAT et al. Pub. No.: US 2020/0228626 A1 (hereafter BERNAT).
Regarding claim 13, BERNAT teaches:
At least one non-transitory machine-readable storage medium with instructions stored thereon, the instructions executable to cause the machine to:
begin execution of an application on a deployment comprising a particular platform ([0028] The disaggregation of resources to sleds comprised predominantly of a single type of resource (e.g., compute sleds comprising primarily compute resources, memory sleds containing primarily memory resources), and the selective allocation and deallocation of the disaggregated resources to form a managed node (i.e., compute “platform”) assigned to execute a workload improves the operation and resource usage of the data center 100 relative to typical data centers), wherein the platform comprises a plurality of hardware components, and a subset of the plurality of hardware components are deactivated when execution of the application begins ([0090] The method 1900 advances to block 1928 of FIG. 20, in which the compute sled 1620 executes the assigned workload with the identified resources (i.e., initial allocation of identified resources are used to execute the workload, representing “activation” of the identified resources while other resources of system 1510 that are not identified for use in the managed node));
identify that a particular subset of the plurality of hardware components is activated by the particular platform, wherein the particular hardware component is activated based on telemetry information collected for the particular platform; and adjust execution of the application to use the particular hardware component based on activation of the particular hardware component, wherein use of the particular hardware component assists in the execution of the application meeting a particular service level ([0093] The compute sled 1620 may adjust the set of resources available for execution of the assigned workload if the target QoS data (i.e., “service level”) cannot be satisfied with the present resources (e.g., including any thermal adjustments to increase the throughput, operations per second, etc. of the resources), as indicated in block 1982. In doing so, the compute sled 1620 may request the pod manager 1608 to adjust the set of available resources (e.g., allocate more resources for the execution of the workload), as indicated in block 1984 (i.e., the additional resources for allocation represent a “particular subset” of resources allocated, or “activated” for use in executing the workload in the adjusted set of resources based on thermal telemetry measurements)).
Regarding claim 14, BERNAT further teaches:
the instructions are executable to further cause the machine to orchestrate execution of the application on the deployment, the deployment comprises an edge deployment ([0080] In some embodiments, at least some of the components of the system 1600 may be located at one or more edge locations (e.g., small cells, base stations, etc.) of a network), and the particular platform is one of a plurality of platforms in the deployment ([0028] Such utilization may allow for more managed nodes to run in a data center with a given set of resources).
Regarding claim 15, BERNAT further teaches:
determine performance metrics for execution of the application; and send the performance metrics to the particular platform, wherein the particular hardware component is activated based on the performance metrics ([0076] The orchestrator server 1520 may receive telemetry data indicative of performance conditions (e.g., throughput, latency, instructions per second, etc.) in each sled 400 of the managed node 1570 and compare the telemetry data to the quality of service targets to determine whether the quality of service targets are being satisfied. The orchestrator server 1520 may additionally determine whether one or more physical resources may be deallocated from the managed node 1570 while still satisfying the QoS targets, thereby freeing up those physical resources for use in another managed node (e.g., to execute a different workload). Alternatively, if the QoS targets are not presently satisfied, the orchestrator server 1520 may determine to dynamically allocate additional physical resources to assist in the execution of the workload (e.g., the application 1532). [0093] The compute sled 1620 may adjust the set of resources available for execution of the assigned workload if the target QoS data cannot be satisfied with the present resources (e.g., including any thermal adjustments to increase the throughput, operations per second, etc. of the resources), as indicated in block 1982 (i.e., both temperature and performance considerations are used to make resource allocation profile decisions)).
Regarding claim 16, BERNAT further teaches:
identify that the particular subset of hardware components is deactivated by the particular platform; and further adjust execution of the application to continue execution of the application without use of the particular subset of hardware components ([0076] The orchestrator server 1520 may selectively allocate and/or deallocate physical resources 620 from the sleds 400 and/or add or remove one or more sleds 400 from the managed node 1570 as a function of quality of service (QoS) targets (e.g., a target throughput, a target latency, a target number instructions per second, etc.) (i.e., resources representing “particular hardware blocks” are deallocated, or “deactivated” as performance changes corresponding to a QoS target)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-10, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over BERNAT (cited above), and in further view of SPIERS et al. Pub. No.: US 2010/0217454 A1 (hereafter SPIERS).
Regarding claim 1, BERNAT teaches the invention substantially as claimed, including:
An apparatus comprising:
a host processor ([0076] The system 1510 (i.e., “host processor”) includes an orchestrator server 1520, which may be embodied as a managed node comprising a compute device (e.g., a processor 820 on a compute sled 800) executing management software (e.g., a cloud operating environment, such as OpenStack) that is communicatively coupled to multiple sleds 400) to execute;
a set of hardware blocks, wherein each hardware block in the set of hardware blocks comprises hardware logic to implement respective functionality ([0090] The compute sled 1620 identifies resource(s) to be used in the execution of the workload (i.e., resources represent “hardware blocks” that execute workloads to provide “functionality”)) and is configured to be selectively activated and deactivated at direction of the host processor ([0028] The selective allocation and deallocation of the disaggregated resources to form a managed node assigned to execute a workload improves the operation and resource usage of the data center 100 relative to typical data centers comprised of hyperconverged servers containing compute, memory, storage and perhaps additional resources in a single chassis (i.e., selectively allocating and deallocating resources “activates” and “deactivates” the resources respectively)); and
a hardware profile definition circuity to:
identify environmental conditions of the apparatus…determine, from the environmental conditions, a hardware profile for activation, wherein the hardware profile comprises a particular one of the set of hardware blocks ([0078] The orchestrator server 1520 may generate a map of heat generation in the data center 100 using telemetry data (e.g., temperatures, fan speeds, etc.) (i.e., at least temperatures represent “environmental conditions”) reported from the sleds 400 and allocate resources to managed nodes as a function of the map of heat generation and predicted heat generation associated with different workloads, to maintain a target temperature and heat distribution in the data center 100 (i.e., identifying particular resources for allocation, or “activation” according to a map of heat and predicted heat generation represents a plan, or “profile” for resource activation based on environmental heat conditions)), and
execution of the application begins without use of the particular hardware block; and cause the particular hardware block to be activated and used during the execution of the application ([0090] The method 1900 advances to block 1928 of FIG. 20, in which the compute sled 1620 executes the assigned workload with the identified resources (i.e., initial allocation of resources are used to execute the workload). [0093] The compute sled 1620 may adjust the set of resources available for execution of the assigned workload if the target QoS data cannot be satisfied with the present resources (e.g., including any thermal adjustments to increase the throughput, operations per second, etc. of the resources), as indicated in block 1982. In doing so, the compute sled 1620 may request the pod manager 1608 to adjust the set of available resources (e.g., allocate more resources for the execution of the workload), as indicated in block 1984 (i.e., additional particular resources predicted for allocation to meet the required thermal adjustments are allocated during execution of the workload)).
While BERNAT discusses allocating and deallocating resources of a data center based at least in part on environmental data including heat measurements, BERNAT does not explicitly teach:
identify environmental conditions of the apparatus based on data from a set of sensors;
However, in analogous art that similarly discusses allocation and deallocation of data center resources, SPIERS teaches:
identify environmental conditions of the apparatus based on data from a set of sensors ([0010] A method is provided for improving thermal efficiency in one or more data centers housing a plurality of computing devices in a computing system environment. The method comprises providing a plurality of computing devices hosting a pool of computing workloads defined by virtual machines, providing a plurality of sensors (i.e., sensor “set”) for measuring a temperature at one or more of the plurality of computing devices, and providing a data orchestrator configured at least for receiving data concerning a measured temperature at one or more of the plurality of computing devices (i.e., data orchestrator makes allocation decisions based at least in part on temperature data from sets of sensors)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined SPIERS’s teaching of monitoring temperature of compute devices in a data center using a set of sensors, with BERNAT’s teaching of making allocation and deallocation decisions based on collected temperature measurements, to realize, with a reasonable expectation of success, a system that makes allocation and deallocation decisions based on collected temperature measurements, as in BERNAT, from a set of sensors, as in SPIERS. A person having ordinary skill would have been motivated to make this combination to use multiple sensors to collect temperature data more accurately and in a more redundant manner.
Regarding claim 2, BERNAT further teaches:
the host processor is to execute at least a portion of an application and the apparatus further comprises a performance monitoring block comprising circuitry to identify performance attributes of the application, wherein the hardware profile is determined based on the environmental conditions and the performance attributes ([0076] The orchestrator server 1520 may receive telemetry data indicative of performance conditions (e.g., throughput, latency, instructions per second, etc.) in each sled 400 of the managed node 1570 and compare the telemetry data to the quality of service targets to determine whether the quality of service targets are being satisfied. The orchestrator server 1520 may additionally determine whether one or more physical resources may be deallocated from the managed node 1570 while still satisfying the QoS targets, thereby freeing up those physical resources for use in another managed node (e.g., to execute a different workload). Alternatively, if the QoS targets are not presently satisfied, the orchestrator server 1520 may determine to dynamically allocate additional physical resources to assist in the execution of the workload (e.g., the application 1532). [0093] The compute sled 1620 may adjust the set of resources available for execution of the assigned workload if the target QoS data cannot be satisfied with the present resources (e.g., including any thermal adjustments to increase the throughput, operations per second, etc. of the resources), as indicated in block 1982 (i.e., both temperature and performance considerations are used to make resource allocation profile decisions)).
Regarding claim 3, BERNAT further teaches:
the particular hardware block is to be activated based on a change in at least one of the environmental conditions as measured by the set of sensors or the performance attributes of the application ([0093] The compute sled 1620 may adjust the set of resources available for execution of the assigned workload if the target QoS data cannot be satisfied with the present resources (e.g., including any thermal adjustments to increase the throughput, operations per second, etc. of the resources), as indicated in block 1982 (i.e., changes in temperature or performance resulting in a target QoS being unable to be satisfied prompts activation of additional resources)).
Regarding claim 4, BERNAT further teaches:
the hardware profile definition block is further to predict a need for the particular hardware block in execution of the application based on the change ([0078] The orchestrator server 1520 may determine the differences based on the telemetry data stored in the hierarchical model and factor the differences into a prediction of future resource utilization of a workload if the workload is reassigned from one managed node to another managed node, to accurately balance resource utilization in the data center 100. In some embodiments, the orchestrator server 1520 may identify patterns in resource utilization phases of the workloads and use the patterns to predict future resource utilization of the workloads. [0093] The compute sled 1620 may adjust the set of resources available for execution of the assigned workload if the target QoS data cannot be satisfied with the present resources (e.g., including any thermal adjustments to increase the throughput, operations per second, etc. of the resources), as indicated in block 1982. In doing so, the compute sled 1620 may request the pod manager 1608 to adjust the set of available resources (e.g., allocate more resources for the execution of the workload), as indicated in block 1984 (i.e., additional resources are activated based on a resource utilization prediction representing a predicted need for those additional resources)).
Regarding claim 5, BERNAT further teaches:
the hardware profile definition block is further to:
identify another change in in at least one of the environmental conditions as measured by the set of sensors or the performance attributes of the application; and deactivate the particular hardware block based on the other change, wherein execution of the application is to continue without use of the particular hardware block after deactivation of the particular hardware block ([0076] The orchestrator server 1520 may selectively allocate and/or deallocate physical resources 620 from the sleds 400 and/or add or remove one or more sleds 400 from the managed node 1570 as a function of quality of service (QoS) targets (e.g., a target throughput, a target latency, a target number instructions per second, etc.) (i.e., resources representing “particular hardware blocks” are deallocated, or “deactivated” as performance changes corresponding to a QoS target)).
Regarding claim 6, BERNAT further teaches:
the set of sensors ([0010] A method is provided for improving thermal efficiency in one or more data centers housing a plurality of computing devices in a computing system environment. The method comprises providing a plurality of computing devices hosting a pool of computing workloads defined by virtual machines, providing a plurality of sensors (i.e., sensor “set”) for measuring a temperature at one or more of the plurality of computing devices, and providing a data orchestrator configured at least for receiving data concerning a measured temperature at one or more of the plurality of computing devices (i.e., data orchestrator makes allocation decisions based at least in part on temperature data from sets of sensors)).
Regarding claim 7, SPIERS further teaches:
the set of sensors comprises a temperature sensor and the environmental conditions comprise a local ambient temperature ([0024] Temperature sensors 106 a-f are provided, for measuring a temperature in an interior of or on a surface of components arrayed in racks 102, for measuring an ambient temperature in a vicinity of racks 102, and the like).
Regarding claim 8, BERNAT further teaches:
the particular hardware block comprises a hardware accelerator block ([0026] Each rack houses multiple sleds, each of which may be primarily equipped with a particular type of resource (e.g., memory devices, data storage devices, accelerator devices, general purpose processors), i.e., resources that can be logically coupled to form a composed node, which can act as, for example, a server).
Regarding claim 9, BERNAT further teaches:
the particular hardware block comprises a processor core, the host processor comprises a plurality of processor cores, and the application begins execution when at least a portion of the plurality of processor cores are deactivated ([0076] Referring now to FIG. 15, a system for executing one or more workloads (e.g., applications) may be implemented in accordance with the data center 100. In the illustrative embodiment, the system 1510 includes an orchestrator server 1520, which may be embodied as a managed node comprising a compute device (e.g., a processor 820 on a compute sled 800). [0081] The sleds 1620, 1630 are compute sleds, similar to the compute sled 800 and include among other components, processors 1624 (e.g., similar to the processors 820) to execute one or more applications 1626 (e.g., sets of instructions, processes, etc. defining a workload). [0028] The disaggregation of resources to sleds comprised predominantly of a single type of resource (e.g., compute sleds comprising primarily compute resources, memory sleds containing primarily memory resources), and the selective allocation and deallocation of the disaggregated resources to form a managed node assigned to execute a workload improves the operation and resource usage of the data center 100 (i.e., system 1510 represents a host processor having plural processor cores, wherein at least a portion of compute cores are allocated to a workload and a portion of the cores are not allocated to the workload)).
Regarding claim 10, BERNAT further teaches:
an edge computing device ([0080] In some embodiments, at least some of the components of the system 1600 may be located at one or more edge locations (e.g., small cells, base stations, etc.) of a network).
Regarding claim 17 BERNAT teaches the invention substantially as claimed, including:
A system comprising:
a platform device comprising:
a plurality of hardware blocks, wherein each hardware block in the plurality of hardware blocks is to provide respective functionality for use in execution of an application ([0090] The compute sled 1620 (i.e., “platform device”) identifies resource(s) to be used in the execution of the workload (i.e., resources represent “hardware blocks” that execute workloads to provide “functionality”)), wherein a subset of the plurality of hardware blocks are deactivated and unavailable for use in the execution of the application at a start of the execution of the application ([0028] The disaggregation of resources to sleds comprised predominantly of a single type of resource (e.g., compute sleds comprising primarily compute resources, memory sleds containing primarily memory resources), and the selective allocation and deallocation of the disaggregated resources to form a managed node assigned to execute a workload improves the operation and resource usage of the data center 100 (i.e., managed node comprises activated resources available for use in execution of the workload, and other resources not allocated to the managed node are “deactivated”))…
a hardware profile modification circuitry to:
identify performance characteristics of the execution of the application ([0076] The orchestrator server 1520 may receive telemetry data indicative of performance conditions (e.g., throughput, latency, instructions per second, etc.) in each sled 400 of the managed node 1570 and compare the telemetry data to the quality of service targets to determine whether the quality of service targets are being satisfied));
receive telemetry data…wherein the telemetry data describes physical characteristics of an environment in which the platform device is deployed ([0078] The orchestrator server 1520 may generate a map of heat generation in the data center 100 using telemetry data (e.g., temperatures, fan speeds, etc.) (i.e., at least temperatures represent “environmental conditions”) reported from the sleds 400 and allocate resources to managed nodes as a function of the map of heat generation and predicted heat generation associated with different workloads, to maintain a target temperature and heat distribution in the data center 100 (i.e., identifying particular resources for allocation, or “activation” according to a map of heat and predicted heat generation represents a plan, or “profile” for resource activation based on environmental heat conditions)); and
dynamically activate at least a particular one of the subset of hardware blocks based on the performance characteristics and the physical characteristics, wherein following activation of the particular hardware block, the execution of the application continues and uses the particular hardware block ([0090] The method 1900 advances to block 1928 of FIG. 20, in which the compute sled 1620 executes the assigned workload with the identified resources (i.e., initial allocation of resources are used to execute the workload). [0093] The compute sled 1620 may adjust the set of resources available for execution of the assigned workload if the target QoS data cannot be satisfied with the present resources (e.g., including any thermal adjustments to increase the throughput, operations per second, etc. of the resources), as indicated in block 1982. In doing so, the compute sled 1620 may request the pod manager 1608 to adjust the set of available resources (e.g., allocate more resources for the execution of the workload), as indicated in block 1984 (i.e., additional particular resources predicted for allocation to meet the required thermal adjustments and QoS data are allocated during execution of the workload)).
While BERNAT discusses allocating and deallocating resources of a data center based at least in part on environmental data including heat measurements, BERNAT does not explicitly teach:
a set of sensors; receive telemetry data generated by the set of sensors;
However, in analogous art that similarly discusses allocation and deallocation of data center resources, SPIERS teaches:
identify environmental conditions of the apparatus based on data from a set of sensors ([0010] A method is provided for improving thermal efficiency in one or more data centers housing a plurality of computing devices in a computing system environment. The method comprises providing a plurality of computing devices hosting a pool of computing workloads defined by virtual machines, providing a plurality of sensors (i.e., sensor “set”) for measuring a temperature at one or more of the plurality of computing devices, and providing a data orchestrator configured at least for receiving data concerning a measured temperature at one or more of the plurality of computing devices (i.e., data orchestrator makes allocation decisions based at least in part on temperature data from sets of sensors)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined SPIERS’s teaching of monitoring temperature of compute devices in a data center using a set of sensors, with BERNAT’s teaching of making allocation and deallocation decisions based on collected temperature measurements, to realize, with a reasonable expectation of success, a system that makes allocation and deallocation decisions based on collected temperature measurements, as in BERNAT, from a set of sensors, as in SPIERS. A person having ordinary skill would have been motivated to make this combination to use multiple sensors to collect temperature data more accurately and in a more redundant manner.
Regarding claim 20 BERNAT further teaches:
a second platform device, wherein the second platform device comprises hardware profile modification circuitry and a different set of hardware blocks, and the hardware profile modification circuitry of the second platform device is to selectively activate or deactivate at least a subset of the different set of hardware blocks during execution of the application ([0026] Resources within sleds in the data center 100 may be allocated to a group (referred to herein as a “managed node”) containing resources from one or more sleds to be collectively utilized in the execution of a workload (i.e., a single managed node comprises resources from multiple sleds, or “platforms” that each selectively allocate and deallocate resources to the managed node as described above)).
Claims 11, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over BERNAT, in view of SPIERS as applied to claim 1 above, and in further view of SOLEIL et al. Pub. No.: US 2022/0060943 A1 (hereafter SOLEIL).
Regarding claim 11, while BERNAT and SPIERS discuss allocation of data center resources, they do not explicitly teach:
metering circuitry to log activation of the hardware profile and duration of the activation of the particular hardware block.
However, in analogous art that similarly discusses allocation of data center resources, SOLEIL teaches:
metering circuitry to log activation of the hardware profile and duration of the activation of the particular hardware block ([0005] Careful and more sophisticated management of these resources is therefore needed and different pricing for these resources is a need which is addressed by a simultaneous double auction model used in this innovation. The model performs automatic resource management, revenue maximization as well as cost minimization for the network operator. This model for resources assumes that demand is dynamic and varies in real time. The supply may also vary based on time of day or type and aggregated quantity of resource demanded. The model also considers the particular network resources that are required (e.g., CPU, Graphics Processing Unit (GPU), storage, security services, etc.), and may also consider: the resources required, the cost to provide the resource, the history of customer requests or the history of resource usage and the customer requested duration of need (i.e., duration of resource usage, or activation, is recorded, or “logged”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined SOLEIL’s teaching of logging resource usage duration, with BERNAT’s teaching of allocating and deallocating resources of a data center, to realize, with a reasonable expectation of success, a system that allocates and deallocates resources of a data center, as in BERNAT, and meters usage of those resources, as in SOLEIL. A person having ordinary skill would have been motivated to make this combination to maximize revenue while minimizing costs (SOLEIL [0005]).
Regarding claim 12, SOLEIL further teaches:
use of the particular hardware block is to be billed at a different rate than use of one or more other hardware blocks in the hardware profile, and the apparatus is further to send log data to an external computing system for use in billing a customer for use of the particular hardware block ([0005] Careful and more sophisticated management of these resources is therefore needed and different pricing for these resources is a need which is addressed by a simultaneous double auction model used in this innovation. The model performs automatic resource management, revenue maximization as well as cost minimization for the network operator. This model for resources assumes that demand is dynamic and varies in real time. The supply may also vary based on time of day or type and aggregated quantity of resource demanded. The model also considers the particular network resources that are required (e.g., CPU, Graphics Processing Unit (GPU), storage, security services, etc.), and may also consider: the resources required, the cost to provide the resource, the history of customer requests or the history of resource usage and the customer requested duration of need (i.e., each of the types of network resources are priced at a different rate and billed to a customer)).
Claims 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over BERNAT, in view of SPIERS as applied to claim 17 above, and in further view of YAMATO Pub. No.: US 2022/0188086 A1 (hereafter YAMATO).
Regarding claim 18, while BERNAT and SPIERS discuss allocating and deallocating resources to execute a workload, they do not explicitly teach:
the platform device further comprises logging circuitry to: identify an effect on performance characteristics of the execution of the application following activation of the particular hardware block; and log the activation of the particular hardware block and the effect on the performance characteristics.
However, in analogous art that similarly discusses allocating resources to execute workloads, YAMATO teaches:
the platform device further comprises logging circuitry to: identify an effect on performance characteristics of the execution of the application following activation of the particular hardware block; and log the activation of the particular hardware block and the effect on the performance characteristics ([0038] Performing a reconfiguration reconfiguring software settings when an initially expected performance is not achieved after an operation of the application is started. The step of performing the reconfiguration includes constructing a reconfiguration destination and performing migration processing, to change software settings. The step of constructing the reconfiguration destination includes: making a trial calculation of the resource amounts setting and deployment place selection in a trial simulation, in a cyclic manner or when the performance is reduced to a threshold or less, to calculate a performance improvement and a degree of cost reduction; and when there is a prospect of improvement in performance and cost through a change of the resource amounts and/or through a change of the deployment place (i.e., performance improvement represents an effect of allocation of resources amounts in the reconfiguration following the execution of the application using an initial allocation)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined YAMATO’s teaching of logging the performance effect of activation of resource amounts, with the combination of BERNAT and SPIERS’s teaching of allocating resources to execute workloads, to realize, with a reasonable expectation of success, a system that allocates resources to execute workloads, as in BERNAT and SPIERS, and determines an effect on performance based on a reallocation, as in YAMATO. A person having ordinary skill would have been motivated to make this combination so that an improvement to performance can be accurately conveyed to a user upon resource migration (YAMATO [0038]).
Regarding claim 19, YAMATO further teaches:
a billing server system to: receive log data over a network from the platform device, wherein the log data describes the activation of the particular hardware block; and determine fees to charge a customer associated with the platform device based on the log data ([0038] Performing a reconfiguration reconfiguring software settings when an initially expected performance is not achieved after an operation of the application is started. The step of performing the reconfiguration includes constructing a reconfiguration destination and performing migration processing, to change software settings. The step of constructing the reconfiguration destination includes: making a trial calculation of the resource amounts setting and deployment place selection in a trial simulation, in a cyclic manner or when the performance is reduced to a threshold or less, to calculate a performance improvement and a degree of cost reduction; and when there is a prospect of improvement in performance and cost through a change of the resource amounts and/or through a change of the deployment place (i.e., reallocation of resources results in a different, reduced cost to the customer)).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL W AYERS/ Primary Examiner, Art Unit 2195
Prosecution Insights