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 .
Response to Amendment
This office action has been issued in response to amendment filed on 05/20/2026. Claims 1, 3-6, 8-11 and 13-19 have been amended. Claims 20-24 have been added. Claims 1-24 are pending, of which claims, of which claim 1, claim 9, claim 10, claim 11 and claim 24 are in independent form.
Claim 6 have been amended to overcome 112(b) rejection. The 112(b) rejection for claim 6 have been withdrawn.
Applicant's arguments with respect to claims 1-24 have been considered but are moot in view of the new ground(s) of rejection.
Status of Claims
Claims 1-24 are pending, of which claims, of which claim 1, 9, 10, 11 and 24 are in independent form.
The Office's Note:
The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1-24 rejected under 35 U.S.C. 103 as being obvious over Hussain et al. (US 10,684,840, herein after Hussain), in view of Thompson et al. (US 20130067454, herein after Thompson) and further in view of Myers et al. (US 20200099773, herein after Myers).
Claim 1 is rejected, Hussain teaches a method for carrying out software management for multiple heterogenous devices, the method comprising the following steps (Hussain, abstract and summary):
receiving, by a central orchestrator, a request to upgrade and/or deploy software on at least one of the devices (Hussain, US 10,684,840,column 4 , line 66, to column 5, line 20, In the example of FIG. 1, the request 105 is received by command interface 110, which may be an interface that allows customers and other users to issue various tasks, requests, and commands for execution on a fleet or other group of computing instances. Fig. 2, column 5, line 21-65, Action 213 indicates an action associated with the request 210, such as install or uninstall.);
initiating, by the central orchestrator, a connection to the at least one of the devices(Hussain, column 4 , line 66, to column 5, line 20, Upon receiving the request 105, the command interface 110 may forward the request 105 may forward the request 105 to computing instances 120A-N for processing. In particular, in some examples, the request 105 may be provided to agents 121A-D executing respectively on each computing instance 120A-D. Agents 121A-D may generally be components for executing and managing various tasks and operations on computing instances 120A-D, such as through interaction with various agent plug-in components that may include specialized instructions for performing certain specific tasks and operations. In the example of FIG. 1, the agents 121A-D interact with respective package configuration plug-ins 122A-D, which are agent plug-ins that may include specialized instructions for implementing operations associated with the installation, uninstallation, updating, constraint enforcement, and other configuration-related aspects of software packages.);
The Office would like to use prior art Thompson to back up Hussain to further teach limitation
initiating, by the central orchestrator, a connection to the at least one of the devices(Thompson, fig. 1 and para [0039], the orchestrator may interact with the distributed processing system using input from a distributed processing plugin. The distributed processing plugin may include data collection routines that identify the devices being managed, determine the mechanisms for communicating to the devices, ensure availability of services offered by the distributed processing system, and includes the logic for determining a sequence of devices to update and how to prepare devices for updating. Fig. 3, component 302 – Orchestrator, component 312 – Send update request, component 346 and 348 - Prepare device for installation).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filling date of the claimed invention would have been motivated to incorporate Thompson into Hussain’s invention to update distributed processing systems. The command is transmitted to each of the devices causing an update to be performed by each of the devices. Easily performs updating of the distributed processing system. Ensures the availability of services offered by the distributed processing system during an update as suggested by Thompson (See abstract and summary of the invention.).
Hussain and Thompson do not explicitly teach
transmitting, by the central orchestrator, via the connection, and to the at least one device, at least one benchmark program that is executable on the at least one device and that, when executed on the at least one device, causes the at least one device to execute computational test workloads and to produce one or more numerical performance measurements asruntime measured respective computational capability of the at least one device;
receiving, by the central orchestrator and from the at least one device, the one or more numerical performance measurements computational test workloads;
detennining, by the central orchestrator, whether of the at least one quantitative benchmark value
carrying out the upgrading and/or deployment of the software according to the determination.
However, Myers teaches
transmitting, by the central orchestrator, via the connection, and to the at least one device, at least one benchmark program that is executable on the at least one device and that, when executed on the at least one device, causes the at least one device to execute computational test workloads and to produce one or more numerical performance measurements asruntime measured respective computational capability of the at least one device (Myers, US 20200099773, fig. 2 and para [0124], The set of upgrade metrics 206 can include performance parameters that are used to measure the performance of the upgraded version 202b with data that is predetermined to be assigned to the current version 202a (e.g., the system data 112), and provide an evaluation, to the administrator, of how well the upgraded version 202b performs relative to the current version 202a. In the example depicted in FIG. 2, the list of metrics 206 includes a maximum number of users that the enterprise applications can accommodate, a reliability score associated with operation of the software, performance impacts resulting from an upgrade implementation, and compatibility between the upgraded version of the enterprise applications and the other associated application components (e.g., data sources used to retrieve data to be visualized in a report, other enterprise applications used to import data from or export data to, etc.). As described more particularly with respect to FIG. 3B, the set of upgrade metrics 206 can be used to provide a benefits summary that indicates potential improvements from using an upgraded version of software (e.g., an actual existing installation of the upgraded software that has been prepared and is ready for use). Para [0138], Measures of performance (e.g., latency, total time to complete a task, CPU time or memory used, errors or retries, that occur, and so on) can be determined for the earlier version from the log data, and corresponding measures can be determined for the new version as the tasks are repeated with the new version. Fig. 5 and para [0182-0183], The client device 520 may be configured to provide the selected testing parameters to the environment test platform 510. For example, the client device 520 may transmit a file, indicating the selected parameters, over a network to the environment test platform 510.);
receiving, by the central orchestrator and from the at least one device, the one or more numerical performance measurements computational test workloads (Myers, fig. 5 and para [0185-0186], The environment test platform 510 may be configured to perform the server environment test on the server environments 530. For example, the environment test platform 510 perform the server environment test on the first server environment 530A after, before, or in parallel with performing the server environment test on the second server environment 530B. From the performance of the server environment test, the environment test platform 510 may generate results that indicate resource usage levels and response times for the server environments 530. For example, the environment test platform 510 may determine that for the first server environment 530A, average memory usage was 80%, processor usage was 60%, and average completion time per task was thirty seconds and determine that for the second server environment 530B, average memory usage was 95%, processor usage was 60%, and average completion time per task was sixty seconds. Para [0191], workload. Para [0198], Performance testing can be used to verify that response time, resource usage and/or throughput of an environment 530A, 530B are adequate. Performance tests can come in several forms, e.g., load, stress and capacity testing, among others. Load testing verifies that the system is stable under normal or expected workload conditions. Stress testing verifies the system's behavior is expected under abnormally high workload conditions. Capacity testing helps determine the workload a system can support while meeting all performance goals, or the performance levels a system can achieve given a workload goal. Single-user performance tests additionally allow measuring system performance under no load, with one user and one single executing job. For evaluating the suitability of an upgrade, load and single-user performance testing are often used to verify that performance is maintained in acceptable ranges or improved. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment. Para [0120-0124].);
detennining, by the central orchestrator, whether of the at least one quantitative benchmark value (Myers, para [0256-0258], As shown in FIG. 10, in response to the message from the management server 760, a system performance prediction indicator (SPPI) 402 is displayed on a GUI 400 user's device as a “Heads Up” window and provides information that compares the likely performance of the environment (e.g., “Aqueduct Production”) and object (e.g., “Corporate Performance” dossier) after the object is migrated relative to the performance of the environment and object before the object is migrated. For example, as shown in FIG. 4, the SPPI indicates that by migrating the object into the new environment, enterprise system reliability may drop by 32.7% and a response time of the object may increase by 42.7%. The reliability and response time information may be part of an anticipated health score presented to the user that reflects a likely state of one or more portions of the enterprise system if the object is migrated. Although the change in reliability and response time shown in FIG. 10 is provided in a percentage change, in some cases, the change may be presented in non-relative terms. For example, the SPPI may indicate that the response time will likely increase from 3 milliseconds to 3.6 milliseconds and the increase may correspond to, for example, a 42.7% increase. The SPPI 1002 can indicate to the user that the requested change has not been made, and requires confirmation before the configuration change will be carried out. By blocking or deferring execution of the requested change, the system can limit the potential for changes with unintended consequences to adversely affect the enterprise computing system. Similarly, erroneous or inadvertent changes can be identified and stopped more easily. Para [0120-0124].); and
carrying out the upgrading and/or deployment of the software according to the determination(Myers, para [0218-0219], In some implementations, the process 600 includes, after performing the server environment test for the first environment, making a hardware and/or software change to the first server environment to create the second server environment. For example, the environment test platform 510 may perform the server environment test on the first server environment 530A and then increase the number of central processing units that can be used to create the second server environment 540.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filling date of the claimed invention would have been motivated to incorporate Myers into Hussain and Thompson’s invention to provide an interface that indicates a set of software objects used in a first server environment, by the computers. Receive data that indicates a selection of testing parameters including a load level and software objects selected from among the set of software objects by the computers. Generate a server environment test provided to generate concurrently running tasks at the indicated load level using the selected software objects by the one or more computers. Performing the server environment test on the first server environment to generate first results indicating server resource usage levels and response times of the first server environment during the server environment test by the computers.as suggested by Myers (See abstract and summary of the invention.).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the devices are configured as nodes in an edge or cloud computing system, each of the nodes being capable of executing the software, the software including an application and/or an application container, the capabilities of the devices for executing the software differing from each other and each of the nodes being capable of hosting a platform neutral byte-code format runtime for executing the software in an intermediate byte code format( Hussain, column 4, line 6-65, FIG. 1 is a diagram illustrating an example software package installation and monitoring system that may be used in accordance with the present disclosure. As shown in FIG. 1, a user 100 may have a group of computing instances 120A-D that are operated on the user's behalf. The computing instances 120A-D may include, for example, virtual machine instances and/or managed computing hardware and/or software instances. In some examples, user 100 may be a customer of a cloud or other computing service provider that hosts execution of Computing instances 120A-D on the user's behalf. For example, the computer service provider may operate one or more data centers or other large collections of computing resources. In the example of FIG. 1, computing instances 120A-D have a number of different characteristics with respect to one another, such as different operating system types, different architecture (e.g., processor) types, different package manager types, different framework types, and other different characteristics. In particular, FIG. 1 shows that computing instance 120A has an Operating System XX (as indicated by the text OS=XX within computing instance 120A). Additionally, computing instance 120A has an Architecture AA (as indicated by the text OS=AA within Computing instance 120A). As also shown in FIG. 1, computing instance 120B has Operating System XX and Architecture BB, computing instance 120C has Operating System YY and Architecture AA, and computing instance 120D has Operating System YY and Architecture BB. It is noted that the different operating system and architecture types shown in FIG. 1 are merely non-limiting examples of different computing instance characteristics. Moreover, it is noted that any or all of computing instances 120A-D may, in some examples, represent any number of computing instances having their respective indicated characteristics. Hussain, column 8, line 6-31, In some examples, information collections 431-440 may each include data that enables installation and uninstallation of their respective package types 411-420 on a computing instance. In some examples, the information collections may include compressed data, such as in a .zip, .tar, or other similar file format. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the determination is carried out based on the at least one quantitative benchmark value determined for the at least one device and respective quantitative benchmark values determined for further ones of the devices to decide on which of the devices the software is upgraded and/or deployed( Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. In some examples, the denied and/or prohibited request or operation may return an error message and/or may include instructions to re-attempt the request or operation at a later time. Also, in some examples, the denied and/or prohibited request or operation may be logged, for example along with associated metadata (e.g., name of package component issuing request, time of request, type of request, etc.), for further review or evaluation. In some examples, monitoring components 712A-D may be specific to a particular operating system type executed by a computing instance 120A-D. For example, as shown in FIG. 6, monitoring components 712A and 712B are designed for execution on Operating System XX employed by computing instances 120A and 120B, while monitoring components 712C and 712D are designed for execution on Operating System YY employed by computing instances 120C and 120D. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment ).
Claim 4 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the at least one benchmark program further causes the at least one device to one determine at least one of the following capabilities of the at least one device: a computational capability specific for a computing performance of the device, a hardware capability characterizing on a hardware topology of the device, an architecture capability of the device, a performance capability specific for at least one performance related metric of the connected device, a software capability specific for a software of the device, including for a software version (Hussain, column 5, line 21-65, and column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the request includes an application manifest that specifies application requirements on the device for execution of the software, the determination being carried out based on the comparison of the at least one quantitative benchmark value with the requirements specified by the application manifest( Hussain, column 5, line 21-65, For an installation request, an agent on a given computing instance may process the request by accessing a manifest (e.g., at the specified source or other known location) for the software package that indicates various computing instance characteristics (e.g., operating system types, architecture types, etc.) and various respective available versions of the software package. The agent may then select, based on characteristics of the computing instance, a package type for the computing instance, such as a package type corresponding to an appropriate version of the software package that is suitable for installation on an operating system type and architecture type of the computing instance. Hussain, column 5, line 21-65. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1,wherein the at least one benchmark and/or the software is provided by providing a location for downloading the at least one benchmark program and/or the software to the device so that the device carries out the downloaded benchmark program, and wherein the central orchestrator is executed by a central data processing apparatus different from the device ( Hussain, column 8, line 6-31, Package data 511 may include data included in or otherwise associated with a software package, such as installers (e.g., .msi files, .rpm files, etc.), executable files (e.g., .exe files), and other associated data and/or metadata. Installation instructions 512 may include instructions that are executable by one or more components (e.g., agents 121A-D and/or plug-ins 122A-D) for installing of the software package. For example, in some cases, installation instructions 512 may include instructions to execute one or more scripts to execute a .msi file or other installer within the package data 511. Additionally, in some examples, installation instructions 512 may employ certain specialized .msi or other installer execution capabilities that may be supported by agents 121A-D, plug-ins 122A-D, and/or command interface 110. Installation instructions 512 may also include instructions to reboot a computing instance after installation of the software package. Hussain, column 4, line 6-65. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 7 is rejected for the reasons set forth hereinabove for claim 12, Hussain, Thompson and Myers teach the method of claim 12, wherein the bytecode format is WebAssembly (Hussain, column 8, line 6-31, In some examples, information collections 431-440 may each include data that enables installation and uninstallation of their respective package types 411-420 on a computing instance. In some examples, the information collections may include compressed data, such as in a .zip, .tar, or other similar file format. Referring now to FIG. 5, an example information collection 431 now be described in detail. As shown in FIG.5, information collection 431 includes package data 511, installation instructions 512, and uninstallation instructions 513. Package data 511 may include data included in or otherwise associated with a software package, such as installers (e.g., .msi files, .rpm files, etc.), executable files (e.g., .exe files), and other associated data and/or metadata. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 8 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the central orchestrator transmits the at least one benchmark program and receives the one or more numerical performance measurements of the one or more computational test workloads for each of the multiple heterogenous devices to automatically quantify the capabilities for executing the software by the devices and for different respective upgrades and/or deployments of the software on different ones of the devices(Thompson, paragraph [0002], a distributed system manager may identify updates to perform, identify devices to update, and perform the updates while maintaining service availability. The manager may consist of an orchestrator that uses a plug in architecture to interface with different update systems. The plugins may interface with an update system and respond to scan, download, and install commands from the orchestrator. The orchestrator may prepare each device within the distributed system for updating, then cause the updates to be performed via the plugins. In some embodiments, the logic for selecting devices to update and managing the workloads on the devices may be contained in a second type of plugin. Fig. 2, component 210 – Determine if update is applicable and component 214 – identify devices for installation. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
As per claim 9, this is the apparatus claim to method claim 1. Therefore, it is rejected for the same reasons as above.
Claim 10 is rejected, Hussain teaches a device for a computing system, the device comprising(Hussain, abstract and summary):
a processor system that includes one or more processors, wherein the processor system is programmed to (Hussain, fig. 12, component 10a..n - processor):
install on the device the received software or software upgrade ( Hussain, fig. 5 and column 8, line 19 to 31, installation instructions 512 may include instructions that are executable by one or more components (e.g., agents 121A-D and/or plug-ins 122A-D) for installing of the software package. For example, in some cases, installation instructions 512 may include instructions to execute one or more scripts to execute a .msi file or other installer within the package data 511. Additionally, in some examples, installation instructions 512 may employ certain specialized .msi or other installer execution capabilities that may be supported by agents 121A-D, plug-ins 122A-D, and/or command interface 110. Installation instructions 512 may also include instructions to reboot a computing instance after installation of the software package. Hussain, column 9 , line 45, to column 10, line 29. Hussain, column 5, line 21-65. Hussain, column 8, line 6-31. Hussain, column 4, line 6-65.).
Hussain does not explicitly teach
orchestrator
However, Thompson teaches
orchestrator(Thompson, fig. 1 and para [0039], the orchestrator may interact with the distributed processing system using input from a distributed processing plugin. The distributed processing plugin may include data collection routines that identify the devices being managed, determine the mechanisms for communicating to the devices, ensure availability of services offered by the distributed processing system, and includes the logic for determining a sequence of devices to update and how to prepare devices for updating. Fig. 3, component 302 – Orchestrator, component 312 – Send update request, component 346 and 348 - Prepare device for installation)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filling date of the claimed invention would have been motivated to incorporate Thompson into Hussain’s invention to update distributed processing systems. The command is transmitted to each of the devices causing an update to be performed by each of the devices. Easily performs updating of the distributed processing system. Ensures the availability of services offered by the distributed processing system during an update as suggested by Thompson (See abstract and summary of the invention.).
Hussain and Thompson do not explicitly teach
execute the at least one benchmark program to execute ran one or more computational test workloads and to produce one or more numerical performance measurements as , at least one quantitative benchmark value characterizing a runtime measured computational capability of the device;
transmit the one or more numerical performance measurements of the one or more computational test workloads to the central orchestrator for use by the central orchestrator in determining whether the software is to be upgraded and/or deployed on the device;
receive, from the central orchestrator, a software or software upgrade determined by the central orchestrator to be deployed and/or upgraded on the device based on a comparison of the at least one quantitative benchmark value with requirements of the software;
However, Myers teaches
execute the at least one benchmark program to execute ran one or more computational test workloads and to produce one or more numerical performance measurements as , at least one quantitative benchmark value characterizing a runtime measured computational capability of the device (Myers, US 20200099773, fig. 2 and para [0120-0124], The set of upgrade metrics 206 can include performance parameters that are used to measure the performance of the upgraded version 202b with data that is predetermined to be assigned to the current version 202a (e.g., the system data 112), and provide an evaluation, to the administrator, of how well the upgraded version 202b performs relative to the current version 202a. In the example depicted in FIG. 2, the list of metrics 206 includes a maximum number of users that the enterprise applications can accommodate, a reliability score associated with operation of the software, performance impacts resulting from an upgrade implementation, and compatibility between the upgraded version of the enterprise applications and the other associated application components (e.g., data sources used to retrieve data to be visualized in a report, other enterprise applications used to import data from or export data to, etc.). As described more particularly with respect to FIG. 3B, the set of upgrade metrics 206 can be used to provide a benefits summary that indicates potential improvements from using an upgraded version of software (e.g., an actual existing installation of the upgraded software that has been prepared and is ready for use). Para [0138], Measures of performance (e.g., latency, total time to complete a task, CPU time or memory used, errors or retries, that occur, and so on) can be determined for the earlier version from the log data, and corresponding measures can be determined for the new version as the tasks are repeated with the new version. Fig. 5 and para [0182-0183], The client device 520 may be configured to provide the selected testing parameters to the environment test platform 510. For example, the client device 520 may transmit a file, indicating the selected parameters, over a network to the environment test platform 510.);
transmit the one or more numerical performance measurements of the one or more computational test workloads to the central orchestrator for use by the central orchestrator in determining whether the software is to be upgraded and/or deployed on the device (Myers, fig. 5 and para [0185-0186], The environment test platform 510 may be configured to perform the server environment test on the server environments 530. For example, the environment test platform 510 perform the server environment test on the first server environment 530A after, before, or in parallel with performing the server environment test on the second server environment 530B. From the performance of the server environment test, the environment test platform 510 may generate results that indicate resource usage levels and response times for the server environments 530. For example, the environment test platform 510 may determine that for the first server environment 530A, average memory usage was 80%, processor usage was 60%, and average completion time per task was thirty seconds and determine that for the second server environment 530B, average memory usage was 95%, processor usage was 60%, and average completion time per task was sixty seconds. Para [0191], workload. Para [0198], Performance testing can be used to verify that response time, resource usage and/or throughput of an environment 530A, 530B are adequate. Performance tests can come in several forms, e.g., load, stress and capacity testing, among others. Load testing verifies that the system is stable under normal or expected workload conditions. Stress testing verifies the system's behavior is expected under abnormally high workload conditions. Capacity testing helps determine the workload a system can support while meeting all performance goals, or the performance levels a system can achieve given a workload goal. Single-user performance tests additionally allow measuring system performance under no load, with one user and one single executing job. For evaluating the suitability of an upgrade, load and single-user performance testing are often used to verify that performance is maintained in acceptable ranges or improved. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment.);
receive, from the central orchestrator, a software or software upgrade determined by the central orchestrator to be deployed and/or upgraded on the device based on a comparison of the at least one quantitative benchmark value with requirements of the software (Myers, para [0256-0258], As shown in FIG. 10, in response to the message from the management server 760, a system performance prediction indicator (SPPI) 402 is displayed on a GUI 400 user's device as a “Heads Up” window and provides information that compares the likely performance of the environment (e.g., “Aqueduct Production”) and object (e.g., “Corporate Performance” dossier) after the object is migrated relative to the performance of the environment and object before the object is migrated. For example, as shown in FIG. 4, the SPPI indicates that by migrating the object into the new environment, enterprise system reliability may drop by 32.7% and a response time of the object may increase by 42.7%. The reliability and response time information may be part of an anticipated health score presented to the user that reflects a likely state of one or more portions of the enterprise system if the object is migrated. Although the change in reliability and response time shown in FIG. 10 is provided in a percentage change, in some cases, the change may be presented in non-relative terms. For example, the SPPI may indicate that the response time will likely increase from 3 milliseconds to 3.6 milliseconds and the increase may correspond to, for example, a 42.7% increase. The SPPI 1002 can indicate to the user that the requested change has not been made, and requires confirmation before the configuration change will be carried out. By blocking or deferring execution of the requested change, the system can limit the potential for changes with unintended consequences to adversely affect the enterprise computing system. Similarly, erroneous or inadvertent changes can be identified and stopped more easily. Myers, para [0218-0219], In some implementations, the process 600 includes, after performing the server environment test for the first environment, making a hardware and/or software change to the first server environment to create the second server environment. For example, the environment test platform 510 may perform the server environment test on the first server environment 530A and then increase the number of central processing units that can be used to create the second server environment 540.);
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filling date of the claimed invention would have been motivated to incorporate Myers into Hussain and Thompson’s invention to provide an interface that indicates a set of software objects used in a first server environment, by the computers. Receive data that indicates a selection of testing parameters including a load level and software objects selected from among the set of software objects by the computers. Generate a server environment test provided to generate concurrently running tasks at the indicated load level using the selected software objects by the one or more computers. Performing the server environment test on the first server environment to generate first results indicating server resource usage levels and response times of the first server environment during the server environment test by the computers.as suggested by Myers (See abstract and summary of the invention.).
As per claim 11, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
Claim 12 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the benchmark program is provided in a bytecode format that is executable irrespective of a hardware architecture of the device ( Hussain, column 8, line 6-31. Hussain, column 4, line 6-65. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 13 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the one or more computational test workloads include a testing of an instruction-per-cycle rate (Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. Hussain, column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 14 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the one or more computational test workloads include a testing of a floating point performance (Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. Hussain, column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 15 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the one or more computational test workloads include a stress testing of a memory to determine a maximum memory bandwidth (Para [0012-0015]. Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. Hussain, column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 16 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the one or more computational test workloads include a testing of a memory usability (Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. Hussain, column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 17 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the one or more computational test workloads include a testing of a graphics processing unit (GPU) compute capability (Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. Hussain, column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 18 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the one or more computational test workloads include a testing of a floating point unit (FPU) compute capability (Para [0012-0015]. Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. Hussain, column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 19 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the one or more computational test workloads include a testing of a digital signal processor (DSP) compute capability (Hussain, column 5, line 21-65, Upon receiving the operating constraints 730 and associated information, monitoring components 712A-D may proceed to monitor the operations of the installed package components 611A-D in order to ensure that the package components 611A-D comply with the operating constraints 730. For example, if package components 611A-D issue a request and/or attempt to perform an operation that may result in meeting or exceeding a threshold amount (e.g., percentage) of usage of processing, memory, I/O, and/or other resources, then monitoring components 712A-D may wholly or partially deny or prohibit the request or operation. Hussain, column 20, line 15 to 25, The resources may in some embodiments be offered to clients in various units related to the web service, such as an amount of storage capacity for storage, processing capability for processing, as instances, as sets of related services and the like. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 20 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, further comprising determining, by the central orchestrator, in what variant the software is to be upgraded and/or deployed on the at least one device based on a comparison of the at least one quantitative benchmark value with requirements of the software(Myers, para [0256-0258], As shown in FIG. 10, in response to the message from the management server 760, a system performance prediction indicator (SPPI) 402 is displayed on a GUI 400 user's device as a “Heads Up” window and provides information that compares the likely performance of the environment (e.g., “Aqueduct Production”) and object (e.g., “Corporate Performance” dossier) after the object is migrated relative to the performance of the environment and object before the object is migrated. For example, as shown in FIG. 4, the SPPI indicates that by migrating the object into the new environment, enterprise system reliability may drop by 32.7% and a response time of the object may increase by 42.7%. The reliability and response time information may be part of an anticipated health score presented to the user that reflects a likely state of one or more portions of the enterprise system if the object is migrated. Although the change in reliability and response time shown in FIG. 10 is provided in a percentage change, in some cases, the change may be presented in non-relative terms. For example, the SPPI may indicate that the response time will likely increase from 3 milliseconds to 3.6 milliseconds and the increase may correspond to, for example, a 42.7% increase. The SPPI 1002 can indicate to the user that the requested change has not been made, and requires confirmation before the configuration change will be carried out. By blocking or deferring execution of the requested change, the system can limit the potential for changes with unintended consequences to adversely affect the enterprise computing system. Similarly, erroneous or inadvertent changes can be identified and stopped more easily. Para [0218-0219]. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 21 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, further comprising determining, by the central orchestrator, in what variant, among a plurality of variants of the software that have different computational-capability requirements, the software is to be upgraded and/or deployed on the at least one device based on a comparison of the at least one quantitative benchmark value with requirements of the software(Myers, para [0256-0258], As shown in FIG. 10, in response to the message from the management server 760, a system performance prediction indicator (SPPI) 402 is displayed on a GUI 400 user's device as a “Heads Up” window and provides information that compares the likely performance of the environment (e.g., “Aqueduct Production”) and object (e.g., “Corporate Performance” dossier) after the object is migrated relative to the performance of the environment and object before the object is migrated. For example, as shown in FIG. 4, the SPPI indicates that by migrating the object into the new environment, enterprise system reliability may drop by 32.7% and a response time of the object may increase by 42.7%. The reliability and response time information may be part of an anticipated health score presented to the user that reflects a likely state of one or more portions of the enterprise system if the object is migrated. Although the change in reliability and response time shown in FIG. 10 is provided in a percentage change, in some cases, the change may be presented in non-relative terms. For example, the SPPI may indicate that the response time will likely increase from 3 milliseconds to 3.6 milliseconds and the increase may correspond to, for example, a 42.7% increase. The SPPI 1002 can indicate to the user that the requested change has not been made, and requires confirmation before the configuration change will be carried out. By blocking or deferring execution of the requested change, the system can limit the potential for changes with unintended consequences to adversely affect the enterprise computing system. Similarly, erroneous or inadvertent changes can be identified and stopped more easily. Para [0218-0219]. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment)..
Claim 22 is rejected for the reasons set forth hereinabove for claim 1, Hussain, Thompson and Myers teach the method of claim 1, wherein the at least one device is a new device, the method further comprising receiving, by the central orchestrator and from a local coordinator executed by the at least one device, a node registration request for registering the at least one device with the central orchestrator, wherein the transmitting of the at least one benchmark program is performed by the central orchestrator in response to the node registration request(Myers, para [0256-0258], As shown in FIG. 10, in response to the message from the management server 760, a system performance prediction indicator (SPPI) 402 is displayed on a GUI 400 user's device as a “Heads Up” window and provides information that compares the likely performance of the environment (e.g., “Aqueduct Production”) and object (e.g., “Corporate Performance” dossier) after the object is migrated relative to the performance of the environment and object before the object is migrated. For example, as shown in FIG. 4, the SPPI indicates that by migrating the object into the new environment, enterprise system reliability may drop by 32.7% and a response time of the object may increase by 42.7%. The reliability and response time information may be part of an anticipated health score presented to the user that reflects a likely state of one or more portions of the enterprise system if the object is migrated. Although the change in reliability and response time shown in FIG. 10 is provided in a percentage change, in some cases, the change may be presented in non-relative terms. For example, the SPPI may indicate that the response time will likely increase from 3 milliseconds to 3.6 milliseconds and the increase may correspond to, for example, a 42.7% increase. The SPPI 1002 can indicate to the user that the requested change has not been made, and requires confirmation before the configuration change will be carried out. By blocking or deferring execution of the requested change, the system can limit the potential for changes with unintended consequences to adversely affect the enterprise computing system. Similarly, erroneous or inadvertent changes can be identified and stopped more easily. Para [0218-0219]. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 23 is rejected for the reasons set forth hereinabove for claim 22, Hussain, Thompson and Myers teach the method of claim 22, wherein the central orchestrator derives a node profile of the at least one device from the one or more numerical performance measurements for use in determining whether software is to be upgraded and/or deployed on the at least one device(Myers, para [0256-0258], As shown in FIG. 10, in response to the message from the management server 760, a system performance prediction indicator (SPPI) 402 is displayed on a GUI 400 user's device as a “Heads Up” window and provides information that compares the likely performance of the environment (e.g., “Aqueduct Production”) and object (e.g., “Corporate Performance” dossier) after the object is migrated relative to the performance of the environment and object before the object is migrated. For example, as shown in FIG. 4, the SPPI indicates that by migrating the object into the new environment, enterprise system reliability may drop by 32.7% and a response time of the object may increase by 42.7%. The reliability and response time information may be part of an anticipated health score presented to the user that reflects a likely state of one or more portions of the enterprise system if the object is migrated. Although the change in reliability and response time shown in FIG. 10 is provided in a percentage change, in some cases, the change may be presented in non-relative terms. For example, the SPPI may indicate that the response time will likely increase from 3 milliseconds to 3.6 milliseconds and the increase may correspond to, for example, a 42.7% increase. The SPPI 1002 can indicate to the user that the requested change has not been made, and requires confirmation before the configuration change will be carried out. By blocking or deferring execution of the requested change, the system can limit the potential for changes with unintended consequences to adversely affect the enterprise computing system. Similarly, erroneous or inadvertent changes can be identified and stopped more easily. Para [0218-0219]. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
Claim 24 is rejected, Hussain teaches a method for carrying out software management for multiple heterogenous devices, the method comprising the following steps (Hussain, abstract and summary):
receiving, by a central orchestrator and from a local coordinator executed by one of the devices, a node registration request for registering the device with the central orchestrator (Hussain, US 10,684,840,column 4 , line 66, to column 5, line 20, In the example of FIG. 1, the request 105 is received by command interface 110, which may be an interface that allows customers and other users to issue various tasks, requests, and commands for execution on a fleet or other group of computing instances. Upon receiving the request 105, the command interface 110 may forward the request 105 may forward the request 105 to computing instances 120A-N for processing. In particular, in some examples, the request 105 may be provided to agents 121A-D executing respectively on each computing instance 120A-D. Agents 121A-D may generally be components for executing and managing various tasks and operations on computing instances 120A-D, such as through interaction with various agent plug-in components that may include specialized instructions for performing certain specific tasks and operations. In the example of FIG. 1, the agents 121A-D interact with respective package configuration plug-ins 122A-D, which are agent plug-ins that may include specialized instructions for implementing operations associated with the installation, uninstallation, updating, constraint enforcement, and other configuration-related aspects of software packages. Fig. 2, column 5, line 21-65, Action 213 indicates an action associated with the request 210, such as install or uninstall.);
The Office would like to use prior art Thompson to back up Hussain to further teach limitation
a central orchestrator (Thompson, fig. 1 and para [0039], the orchestrator may interact with the distributed processing system using input from a distributed processing plugin. The distributed processing plugin may include data collection routines that identify the devices being managed, determine the mechanisms for communicating to the devices, ensure availability of services offered by the distributed processing system, and includes the logic for determining a sequence of devices to update and how to prepare devices for updating. Fig. 3, component 302 – Orchestrator, component 312 – Send update request, component 346 and 348 - Prepare device for installation).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filling date of the claimed invention would have been motivated to incorporate Thompson into Hussain’s invention to update distributed processing systems. The command is transmitted to each of the devices causing an update to be performed by each of the devices. Easily performs updating of the distributed processing system. Ensures the availability of services offered by the distributed processing system during an update as suggested by Thompson (See abstract and summary of the invention.).
Hussain and Thompson do not explicitly teach
in response to the node registration request, transmitting, by the central orchestrator and to the device, at least one benchmark program that is executable on the device and that, when executed on the device, causes the device to execute one or more computational test workloads and to produce one or more numerical performance measurements as at least one quantitative benchmark value characterizing a runtime measured computational capability of the device;
receiving, by the central orchestrator and from the device, the one or more numerical performance measurements of the one or more computational test workloads;
determining, by the central orchestrator, whether software is to be upgraded and/or deployed on the device based on a comparison of the at least one quantitative benchmark value with requirements of the software; and
carrying out the upgrading and/or deployment of the software according to the determination.
However, Myers teaches
in response to the node registration request, transmitting, by the central orchestrator and to the device, at least one benchmark program that is executable on the device and that, when executed on the device, causes the device to execute one or more computational test workloads and to produce one or more numerical performance measurements as at least one quantitative benchmark value characterizing a runtime measured computational capability of the device (Myers, US 20200099773, fig. 2 and para [0120-0124], The set of upgrade metrics 206 can include performance parameters that are used to measure the performance of the upgraded version 202b with data that is predetermined to be assigned to the current version 202a (e.g., the system data 112), and provide an evaluation, to the administrator, of how well the upgraded version 202b performs relative to the current version 202a. In the example depicted in FIG. 2, the list of metrics 206 includes a maximum number of users that the enterprise applications can accommodate, a reliability score associated with operation of the software, performance impacts resulting from an upgrade implementation, and compatibility between the upgraded version of the enterprise applications and the other associated application components (e.g., data sources used to retrieve data to be visualized in a report, other enterprise applications used to import data from or export data to, etc.). As described more particularly with respect to FIG. 3B, the set of upgrade metrics 206 can be used to provide a benefits summary that indicates potential improvements from using an upgraded version of software (e.g., an actual existing installation of the upgraded software that has been prepared and is ready for use). Para [0138], Measures of performance (e.g., latency, total time to complete a task, CPU time or memory used, errors or retries, that occur, and so on) can be determined for the earlier version from the log data, and corresponding measures can be determined for the new version as the tasks are repeated with the new version. Fig. 5 and para [0182-0183], The client device 520 may be configured to provide the selected testing parameters to the environment test platform 510. For example, the client device 520 may transmit a file, indicating the selected parameters, over a network to the environment test platform 510.);
receiving, by the central orchestrator and from the device, the one or more numerical performance measurements of the one or more computational test workloads (Myers, fig. 5 and para [0185-0186], The environment test platform 510 may be configured to perform the server environment test on the server environments 530. For example, the environment test platform 510 perform the server environment test on the first server environment 530A after, before, or in parallel with performing the server environment test on the second server environment 530B. From the performance of the server environment test, the environment test platform 510 may generate results that indicate resource usage levels and response times for the server environments 530. For example, the environment test platform 510 may determine that for the first server environment 530A, average memory usage was 80%, processor usage was 60%, and average completion time per task was thirty seconds and determine that for the second server environment 530B, average memory usage was 95%, processor usage was 60%, and average completion time per task was sixty seconds. Para [0191], workload. Para [0198], Performance testing can be used to verify that response time, resource usage and/or throughput of an environment 530A, 530B are adequate. Performance tests can come in several forms, e.g., load, stress and capacity testing, among others. Load testing verifies that the system is stable under normal or expected workload conditions. Stress testing verifies the system's behavior is expected under abnormally high workload conditions. Capacity testing helps determine the workload a system can support while meeting all performance goals, or the performance levels a system can achieve given a workload goal. Single-user performance tests additionally allow measuring system performance under no load, with one user and one single executing job. For evaluating the suitability of an upgrade, load and single-user performance testing are often used to verify that performance is maintained in acceptable ranges or improved. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment.);
determining, by the central orchestrator, whether software is to be upgraded and/or deployed on the device based on a comparison of the at least one quantitative benchmark value with requirements of the software (Myers, para [0256-0258], As shown in FIG. 10, in response to the message from the management server 760, a system performance prediction indicator (SPPI) 402 is displayed on a GUI 400 user's device as a “Heads Up” window and provides information that compares the likely performance of the environment (e.g., “Aqueduct Production”) and object (e.g., “Corporate Performance” dossier) after the object is migrated relative to the performance of the environment and object before the object is migrated. For example, as shown in FIG. 4, the SPPI indicates that by migrating the object into the new environment, enterprise system reliability may drop by 32.7% and a response time of the object may increase by 42.7%. The reliability and response time information may be part of an anticipated health score presented to the user that reflects a likely state of one or more portions of the enterprise system if the object is migrated. Although the change in reliability and response time shown in FIG. 10 is provided in a percentage change, in some cases, the change may be presented in non-relative terms. For example, the SPPI may indicate that the response time will likely increase from 3 milliseconds to 3.6 milliseconds and the increase may correspond to, for example, a 42.7% increase. The SPPI 1002 can indicate to the user that the requested change has not been made, and requires confirmation before the configuration change will be carried out. By blocking or deferring execution of the requested change, the system can limit the potential for changes with unintended consequences to adversely affect the enterprise computing system. Similarly, erroneous or inadvertent changes can be identified and stopped more easily. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment); and
carrying out the upgrading and/or deployment of the software according to the determination (Myers, para [0218-0219], In some implementations, the process 600 includes, after performing the server environment test for the first environment, making a hardware and/or software change to the first server environment to create the second server environment. For example, the environment test platform 510 may perform the server environment test on the first server environment 530A and then increase the number of central processing units that can be used to create the second server environment 540. Myers, para [0120-0124]. fig. 5 and para [0185-0186]. Para [0191], workload. Para [0198]. Para [0204-0206], Monitoring can be performed for various variables, such as: (1) report and document execution statistics, (2) memory usage of the environment, (3) CPU usage of the environment, and/or (4) additional performance counters retrieved from the environment).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filling date of the claimed invention would have been motivated to incorporate Myers into Hussain and Thompson’s invention to provide an interface that indicates a set of software objects used in a first server environment, by the computers. Receive data that indicates a selection of testing parameters including a load level and software objects selected from among the set of software objects by the computers. Generate a server environment test provided to generate concurrently running tasks at the indicated load level using the selected software objects by the one or more computers. Performing the server environment test on the first server environment to generate first results indicating server resource usage levels and response times of the first server environment during the server environment test by the computers.as suggested by Myers (See abstract and summary of the invention.).
Myers also teaches
receiving, by a central orchestrator and from a local coordinator executed by one of the devices, a node registration request for registering the device with the central orchestrator(Myers, para [0178-0179], FIG. 5 is a diagram that illustrates an example of a system 500 with an environment testing platform 510. In the example, the system 500 includes a client device 520 used by a user 522, an environment test platform 510, a first server environment 530A, and a second server environment 530B (the first server environment 530A and the second server environment 530B collectively referred to as server environments 530). Fig. 6, para [0207-0212], In more detail, the process 600 includes performing the server environment test on a second server environment to generate second results (650). For example, where the second server environment 530B only differs from the first server environment 530A in doubling a number of central processing units, the environment test platform 510 may perform the server environment test on the second server environment 530B and generate results that indicate average memory usage was 60%, average processor usage was at 45%, and average response times were fifteen seconds.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached at 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights