DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to amendment filed on 12/03/2025.
Response to Amendment
By this amendment, claims 1-2, 4-7, 11-16, and 19-20 are amended. Therefore, claims 1-20 are pending. Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Response to Arguments
Applicant's arguments filed 12/03/2025 have been fully considered but they are not persuasive. Applicant argues in substance:
However, none of them disclose the executor reuse based on immediate prior task feature. In particular, none of the cited references discloses or suggests, "identifying the pool includes determining that an executor of the pool has executed an immediate prior build task of a same affinity class as the new build task, the immediate prior build task being a most recent build task executed by the executor before the new build task and belonging to the same affinity class as the new build task;" recited in amended independent claims.
With regard to point (a), due to claim amendments, Frankin et al. Pub. No. US 2011/0276939 Al (hereafter Frankin) has been utilized to cure the stated deficiencies of independent claims 1, 12, and 20. Therefore, the independent claims 1, 12, and 20 are still rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
For at least the foregoing, Independent claims 1, 12, and 20 are allowable over cited references, and respectfully requests that the rejection sunder 35 U.S.C. 103 be withdrawn.
With regard to point (b), due to claim amendments, Frankin et al. Pub. No. US 2011/0276939 Al (hereafter Frankin) has been utilized to cure the stated deficiencies of independent claims 1, 12, and 20 as stated above. Therefore, independent claims 1, 12, and 20 and their respective dependent claims are still rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Claim Objections
Claims 1-20 are objected to because of the following informalities:
In Claims 12 and 20, “wherein one or more tasks represent compilation” should read “wherein one or more build tasks represent compilation”.
In Claims 12 and 20, “wherein tasks for a pool” should read “wherein build tasks for a pool”.
In Claims 12 and 20, “wherein a pool represents a set of processors” should read “wherein the pool represents a set of processors”.
In Claims 12 and 20, “characteristics of build tasks assigned” should read “characteristics of the build tasks assigned”.
In Claims 12 and 20, “determining an affinity class for the new build task” should read “determining the affinity class for the new build task”.
In Claims 12 and 20, “identifying a pool matching the affinity class” should read “identifying the pool matching the affinity class”.
In Claim 3, “storing build tasks for the pool” should read “storing the build tasks for the pool”.
In Claim 8, “wherein the measure of workload for a pool” should read “wherein the measure of workload for the pool”.
In Claims 5-7 and 15, “storing tasks for the pool” should read “storing the build tasks for the pool”.
In Claim 15, “an estimated time for executing tasks” should read “an estimated time for executing the build tasks”.
In Claims 11, “features describing a pool and predict a size of the pool” should read “features describing the pool and predict the size of the pool”.
In Claims 19, “wherein measure of workload for the pool is determined using a machine learning model trained to receive as input, features describing a pool and predict a size of the pool” should read “wherein the measure of workload for the pool is determined using a machine learning model trained to receive as input, features describing the pool and predict the size of the pool”.
Any claim not specifically mentioned above, is objected due to its dependency on an objected claim.
Appropriate correction is required.
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-2, 4, 8, 10-13, 16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mcweeney Pub. No. US 2021/0109789 Al in view of Belkin et al. Pat. No. US 6,542,920 Bl (hereafter Belkin), and further in view of Frankin et al. Pub. No. US 2011/0276939 Al (hereafter Frankin).
Regarding claim 1, Mcweeney teaches a computer-implemented method for scheduling build tasks for execution using multiple processors ([0098] “…a non-transitory computer-readable medium can comprise instructions that, when executed by one or more processors, cause a computing device to perform the acts of FIG. 8…”), the computer-implemented method comprising: receiving a plurality of build tasks for executing on a plurality of processors ([0038] “…the client device 116 can provide a service request to the cloud-based computing cluster 112 (or the digital cloud management system 104) and the digital cloud management system 104 can utilize the nodes 114a-114n to perform computing tasks associated with the service request…”) … grouping the plurality of processors into a set of pools ([0030] “…the quantity of computing resources allocated (or provisioned) within one or more computing clusters. Additionally, a computing resource can include, but is not limited to, a node…”, Note: The cluster is the pool) … wherein the pool represents a set of processors ([0038] “Furthermore, as shown in FIG. 1, the cloud-based computing cluster 112 can include nodes 114a-114n…”, Note: The cluster is the pool)…
Mcweeney fails to teach wherein one or more build tasks represent compilation of source code files specified using a programming language, the compilation performed using a compiler of the programming language … wherein build tasks for a pool are stored in a queue data structure … associated with an affinity class, wherein each affinity class is associated with characteristics of the build tasks assigned to the pool; and repeating for new build tasks received for execution: receiving a new build task; determining the affinity class for the new build task based on characteristics of the new build task; identifying the pool matching the affinity class determined for the new build task … and adding the new build task to the queue data structure of the pool matching the affinity class.
In analogous art Belkin teaches wherein one or more build tasks represent compilation of source code files specified using a programming language, the compilation performed using a compiler of the programming language (Col. 5 lines 20-40: “Depending upon the request, various services 112 within the server 106 may be invoked in order to service the request. For example, if the request is a simple request for an HTML page, then the request processing mechanism 110 forwards the request on to HTML engine 122 for further servicing … If the request is for a JAVA type service, then the request processing mechanism 110 forwards the request on to the JAVA services engine 126 … The request may also request other types of services, such as certain legacy code 120. If that is the case, then the request processing mechanism 110 invokes the legacy code 120 to further service the request.”, Note: Requests are tasks requiring different programming languages) … wherein build tasks for a pool are stored in a queue data structure (Col. 16 lines 1-6: “(1) that the request is processed by the request processing mechanism 110 and determined to be a request for a JAVA type service; and (2) that the thread pool associated with JAVA type services currently has no free threads available. In this situation, the request is typically put onto the queue associated with the thread pool.”, Fig. 2) … associated with an affinity class, wherein each affinity class is associated with characteristics of the build tasks assigned to the pool (Col. 4 lines 52-54: “the thread pool that is associated with the request is the one that is customized for the type of service being requested by the request.”, Fig. 2, Note: The type of service is the affinity class); and repeating for new build tasks received for execution: receiving a new build task (Col. 16 lines 1-2: “the request is processed by the request processing mechanism 110”, Fig. 2); determining the affinity class for the new build task based on characteristics of the new build task (Col. 16 lines 1-3: “the request is processed by the request processing mechanism 110 and determined to be a request for a JAVA type service”, Fig. 2, Note: The type of service is the affinity class); identifying the pool matching the affinity class determined for the new build task (Col. 16 lines 3-5: “the thread pool associated with JAVA type services currently has no free threads available”, Fig. 2, Note: The type of service is the affinity class, and no threads are available in the pool with the JAVA type services) … and adding the new build task to the queue data structure of the pool matching the affinity class (Col. 16 lines 1-6: “In this situation, the request is typically put onto the queue associated with the thread pool.”, Fig. 2, Note: The type of service is the affinity class).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Mcweeney to incorporate the teachings of Belkin to optimize the servicing of the request and optimize system performance (Belkin Col. 3 lines 38-42: “Because the request is serviced using a thread from the thread pool customized for the type of service being requested, the servicing of the request is optimized. This in turn optimizes system performance.”).
Mcweeney and Belkin fail to teach wherein identifying the pool includes determining that an executor of the pool has executed an immediate prior build task of a same affinity class as the new build task, the immediate prior build task being a most recent build task executed by the executor before the new build task and belonging to the same affinity class as the new build task.
In analogous art Frankin teaches wherein identifying the pool includes determining that an executor of the pool has executed an immediate prior build task of a same affinity class as the new build task, the immediate prior build task being a most recent build task executed by the executor before the new build task and belonging to the same affinity class as the new build task ([0025] “The system 100 may comprise the build resource pool 150. The build resource pool 150 may comprise various build resources 152-1-c suitable for use in executing build execution tasks for building the software application 170 … the build resources 152-1-c may comprise a generic server having general hardware capable of running any general type of server software, such as compilers, linkers, software libraries, include libraries, and so forth…”, [0028] “…During creation of the virtual software build platform, the software build service 126 assigns multiple build resources 152-1-c from the resource pool 150 to the virtual software build platform used to build the software application. In various embodiments, each of the assigned build resources 152-1-c may have one or more assigned affinity relationships for build execution tasks to build the software application. The affinity relationship allows the software build service 126 to efficiently and effectively assign build execution tasks to appropriate build resources 152-1-c suited to a given set of design parameters for the software application and/or software production team. The build execution tasks may then be executed by the build resources 152-1-c in a sequential or parallel manner, or any combination thereof, to reduce software build times…”, [0038] “In one embodiment, the resource manager 126-2 may assign a type one affinity relationship 220-1 to a build resource, a build task or both a build resource and a build task. The type one affinity relationship indicates a build resource 152-1-c (e.g., build resource 152-1) can execute a specific build execution task 210-1-e (e.g., build execution task 210-1) and other build execution tasks 210-2-e (e.g., build execution tasks 210-2, 210-3) during a software build session … This may also be advantageous in cases such as when a Product X is being written to use a new set of libraries. Assume these libraries are available only on the build resource 152-1, 152-2. Build execution tasks 210-1-e for Product X are set with type one affinity relationship 220-2 to ensure that they will only run on the build resources 152-1, 152-2 since they have operating environments to support a special requirement of Product X.”, Note: A build resource is interpreted as the executor, wherein the build resource comprises a compiler to run a specific build task as noted by its affinity relationship; and the build tasks are executed by build resources (executors) in a sequential manner).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Mcweeney and Belkin to incorporate the teachings of Frankin to increase build performance and on demand scalability (Frankin [0016] “…software production teams experience increased build performance and on demand scalability by distributing builds over a shared pool of many dynamically managed machines…”).
Regarding claim 2, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 1, and Mcweeney further teaches adjusting a size of the pool based on a measure of workload associated with the pool ([0063] “…the reinforcement auto-scaling model can analyze the current load and historical trends (e.g., historical data as described above) to determine an auto-scaling action…”, [0038] “…modify one or more nodes of the cloud-based computing cluster 112 … add or remove nodes … based on a determined auto-scaling action…”, Note: The cluster is the pool).
Regarding claim 4, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 2, and Mcweeney further teaches wherein the measure of workload for the pool is a predicted workload based on a measure of current workload and a measure of past workload ([0063] “…the reinforcement auto-scaling model can analyze the current load and historical trends (e.g., historical data as described above) to determine an auto-scaling action…”, Note: The auto-scaling action is the action taken to resize the cluster (pool) in order to perform the predicted workload).
Regarding claim 8, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 2, and Mcweeney further teaches wherein the measure of workload for a pool is determined based on factors comprising an estimate of expected amount of work for the affinity class associated with the pool ([0063] “…the reinforcement auto-scaling model can analyze the current load and historical trends (e.g., historical data as described above) to determine an auto-scaling action…”, Note: The auto-scaling action is the action taken to resize the cluster (pool) in order to perform the estimate of expected amount of work).
Regarding claim 10, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 8, and Mcweeney further teaches wherein the estimate of expected amount of work for the affinity class associated with the pool is determined as a weighted aggregate of factors including an estimate of past work for the affinity class and an estimate of current work for the affinity class ([0063] “…the reinforcement auto-scaling model can analyze the current load and historical trends (e.g., historical data as described above) to determine an auto-scaling action…”, Note: The auto-scaling action is the action taken to resize the cluster (pool) in order to perform the estimate of expected amount of work).
Regarding claim 11, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 2, and Mcweeney further teaches wherein the measure of workload for the pool is determined using a machine learning model trained to receive as input, features describing a pool and predict a size of the pool ([0026] “…For instance, a scaling model can include a machine learning model (e.g., a neural network) that learns from and make predictions on input information associated with a computing cluster to generate outputs that reflect patterns and attributes from the information in order to determine an auto-scaling action (or outputs that reflect an auto-scaling action)…”, [0038] “…modify one or more nodes of the cloud-based computing cluster 112 … add or remove nodes … based on a determined auto-scaling action…”, Note: The machine learning model receives input information associated with a computing cluster and predicts a size of the cluster (pool) to determine the auto-scaling action (quantity of nodes to add or remove)).
Regarding claim 12, Mcweeney further teaches a non-transitory storage medium storing instructions that when executed by one or more processors, cause the one or more processors to perform steps comprising ([0098] “…a non-transitory computer-readable medium can comprise instructions that, when executed by one or more processors, cause a computing device to perform the acts of FIG. 8…”). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 13, it is an article of manufacture claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 16, it is an article of manufacture claim whose limitations are substantially the same as those of claim 8. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 18, it is an article of manufacture claim whose limitations are substantially the same as those of claim 10. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 19, it is an article of manufacture claim whose limitations are substantially the same as those of claim 11. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 20, Mcweeney further teaches a computer system comprising: one or more processors; and a non-transitory storage medium storing instructions that when executed by the one or more processors, cause the one or more processors to perform steps comprising ([0098] “…a non-transitory computer-readable medium can comprise instructions that, when executed by one or more processors, cause a computing device to perform the acts of FIG. 8…”). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Claims 3, 5-7, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Mcweeney Pub. No. US 2021/0109789 Al in view of Belkin et al. Pat. No. US 6,542,920 Bl (hereafter Belkin), further in view of Frankin et al. Pub. No. US 2011/0276939 Al (hereafter Frankin) as applied to claims 1-2, 4, 8, 10-13, 16, and 18-20 above, and further in view of Watt, JR. et al. Pub. No. US 2018/0225155 Al (hereafter Watt).
Regarding claim 3, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 2, and Mcweeney further teaches modifying a number of processors allocated to the pool based on the new size ([0038] “…modify one or more nodes of the cloud-based computing cluster 112 … add or remove nodes … based on a determined auto-scaling action…”, Note: The cluster is the pool).
Mcweeney, Belkin, and Frankin fail to teach wherein adjusting the size of the pool comprises: determining a new size of the pool based on factors comprising a size of the queue data structure storing build tasks for the pool.
In analogous art Watt teaches wherein adjusting the size of the pool comprises: determining a new size of the pool based on factors comprising a size of the queue data structure storing build tasks for the pool ([0039] “…For example, the workload resource optimization subsystem 212 may include a plurality of predetermined container generation conditions that indicate whether the jobs generated by the workload manager subsystem 202 are being processed according to a desired standard and, if not, whether the agent infrastructure subsystem 204 requires more containers with more agents to process the jobs in the job queue of the workload manager subsystem 202. The workload resource optimization subsystem 212 may compare the job queue information to the container generation conditions that may be based on thresholds for a number of jobs in the job queue 308…a number of jobs in the job queue 308 per agent pool…”, [0041] “…At block 706, the workload resource optimization subsystem 212 may provide the container instructions that identify an agent pool that needs a new container and agent to process the job(s) in the job queue 308, and provide instructions to generate a new container to the agent infrastructure subsystem 204.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Mcweeney, Belkin, and Frankin to incorporate the teachings of Watt to optimize resources usage and reduce queue times (Watt [0033] “…The workload resource optimization engine uses job queue information from the workload manager subsystem to scale up and scale down container hosts and/or containers hosted by the container hosts…By implementing scaling of containers and container hosts, information technology departments can substantially reduce their hardware footprints by requiring less hardware resources to provision customized agents that can process a variety of different jobs, while simultaneously reducing job queue times at the workload manager subsystem, as well as agent provisioning times.”).
Regarding claim 5, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 2.
Mcweeney, Belkin, and Frankin fail to teach wherein the measure of workload for the pool is determined based on factors comprising a size of the queue data structure storing tasks for the pool.
In analogous art Watt teaches wherein the measure of workload for the pool is determined based on factors comprising a size of the queue data structure storing tasks for the pool ([0039] “…For example, the workload resource optimization subsystem 212 may include a plurality of predetermined container generation conditions that indicate whether the jobs generated by the workload manager subsystem 202 are being processed according to a desired standard and, if not, whether the agent infrastructure subsystem 204 requires more containers with more agents to process the jobs in the job queue of the workload manager subsystem 202. The workload resource optimization subsystem 212 may compare the job queue information to the container generation conditions that may be based on thresholds for a number of jobs in the job queue 308…a number of jobs in the job queue 308 per agent pool…”, [0041] “…At block 706, the workload resource optimization subsystem 212 may provide the container instructions that identify an agent pool that needs a new container and agent to process the job(s) in the job queue 308, and provide instructions to generate a new container to the agent infrastructure subsystem 204.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Mcweeney, Belkin, and Frankin to incorporate the teachings of Watt to optimize resources usage and reduce queue times (Watt [0033] “…The workload resource optimization engine uses job queue information from the workload manager subsystem to scale up and scale down container hosts and/or containers hosted by the container hosts…By implementing scaling of containers and container hosts, information technology departments can substantially reduce their hardware footprints by requiring less hardware resources to provision customized agents that can process a variety of different jobs, while simultaneously reducing job queue times at the workload manager subsystem, as well as agent provisioning times.”).
Regarding claim 6, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 2.
Mcweeney, Belkin, and Frankin fail to teach wherein the measure of workload for the pool is determined based on factors comprising a square value of a size of the queue data structure storing tasks for the pool.
In analogous art Watt teaches wherein the measure of workload for the pool is determined based on factors comprising a square value of a size of the queue data structure storing tasks for the pool ([0039] “…For example, the workload resource optimization subsystem 212 may include a plurality of predetermined container generation conditions that indicate whether the jobs generated by the workload manager subsystem 202 are being processed according to a desired standard and, if not, whether the agent infrastructure subsystem 204 requires more containers with more agents to process the jobs in the job queue of the workload manager subsystem 202. The workload resource optimization subsystem 212 may compare the job queue information to the container generation conditions that may be based on thresholds for a number of jobs in the job queue 308, a rate of jobs being processed from the job queue 308, a rate of jobs being added to the job queue 308, a time period that jobs are in the job queue 308, a number of jobs in the job queue 308 per agent pool, and/or other job queue thresholds/conditions or combinations of job queue thresholds/conditions that would be apparent to one of skill in the art in possession of the present disclosure.”, Note: The combinations of job queue thresholds/conditions that would be apparent to one of skill in the art covers the square value of the number of jobs in the job queue (size of the queue)).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Mcweeney, Belkin, and Frankin to incorporate the teachings of Watt to optimize resources usage and reduce queue times (Watt [0033] “…The workload resource optimization engine uses job queue information from the workload manager subsystem to scale up and scale down container hosts and/or containers hosted by the container hosts…By implementing scaling of containers and container hosts, information technology departments can substantially reduce their hardware footprints by requiring less hardware resources to provision customized agents that can process a variety of different jobs, while simultaneously reducing job queue times at the workload manager subsystem, as well as agent provisioning times.”).
Regarding claim 7, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 2.
Mcweeney, Belkin, and Frankin fail to teach wherein the measure of workload for the pool is determined based on factors comprising a product of a size of the queue data structure storing tasks for the pool and an estimated time for executing the build tasks assigned to the pool.
In analogous art Watt teaches wherein the measure of workload for the pool is determined based on factors comprising a product of a size of the queue data structure storing tasks for the pool and an estimated time for executing the build tasks assigned to the pool ([0039] “…For example, the workload resource optimization subsystem 212 may include a plurality of predetermined container generation conditions that indicate whether the jobs generated by the workload manager subsystem 202 are being processed according to a desired standard and, if not, whether the agent infrastructure subsystem 204 requires more containers with more agents to process the jobs in the job queue of the workload manager subsystem 202. The workload resource optimization subsystem 212 may compare the job queue information to the container generation conditions that may be based on thresholds for a number of jobs in the job queue 308, a rate of jobs being processed from the job queue 308, a rate of jobs being added to the job queue 308, a time period that jobs are in the job queue 308, a number of jobs in the job queue 308 per agent pool, and/or other job queue thresholds/conditions or combinations of job queue thresholds/conditions that would be apparent to one of skill in the art in possession of the present disclosure.”, [0041] “…At block 706, the workload resource optimization subsystem 212 may provide the container instructions that identify an agent pool that needs a new container and agent to process the job(s) in the job queue 308, and provide instructions to generate a new container to the agent infrastructure subsystem 204.”, Note: The time period that jobs are in the job queue (measure of workload) is the product of the number of jobs in the job queue (size of the queue) and the rate of jobs being processed from the job queue (estimated time for executing tasks)).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Mcweeney, Belkin, and Frankin to incorporate the teachings of Watt to optimize resources usage and reduce queue times (Watt [0033] “…The workload resource optimization engine uses job queue information from the workload manager subsystem to scale up and scale down container hosts and/or containers hosted by the container hosts…By implementing scaling of containers and container hosts, information technology departments can substantially reduce their hardware footprints by requiring less hardware resources to provision customized agents that can process a variety of different jobs, while simultaneously reducing job queue times at the workload manager subsystem, as well as agent provisioning times.”).
Regarding claim 14, it is an article of manufacture claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 15, it is an article of manufacture claim whose limitations are substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
Claims 9 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mcweeney Pub. No. US 2021/0109789 Al in view of Belkin et al. Pat. No. US 6,542,920 Bl (hereafter Belkin), further in view of Frankin et al. Pub. No. US 2011/0276939 Al (hereafter Frankin) as applied to claims 1-2, 4, 8, 10-13, 16, and 18-20 above, and further in view of Liu et al. Pub. No. US 2007/0219944 Al (hereafter Liu).
Regarding claim 9, Mcweeney, Belkin, and Frankin teach the computer-implemented method of claim 8.
Mcweeney, Belkin, and Frankin fail to teach wherein the estimate of expected amount of work for the affinity class associated with the pool is determined as a product of an average arrival rate of build tasks for the affinity class and an average processing time of build tasks for the affinity class.
In analogous art Liu teaches wherein the estimate of expected amount of work for the affinity class associated with the pool is determined as a product of an average arrival rate of build tasks for the affinity class and an average processing time of build tasks for the affinity class ([0084] “…Little's Law states, "The average number of jobs in a system is the product of the arrival rate and the average time a job spends in the system."…”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Mcweeney, Belkin, and Frankin to incorporate the teachings of Liu to determine and implement optimized parameters for system workloads (Liu [0011] “From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method to model enterprise application system workloads, to project resource utilization for such systems, and to determine optimization parameters for such systems. Beneficially, such an apparatus, system, and method would also allow implementation of the optimized parameters.”).
Regarding claim 17, it is an article of manufacture claim whose limitations are substantially the same as those of claim 9. Accordingly, it is rejected for substantially the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. In particular, US 2004/0139433 Al is cited because it discloses classifying requests and executing them on pools each with a respective queue.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner respectfully requests, in response to this Office action, support be
shown for language added to any original claims on amendment and any new claims.
That is, indicate support for newly added claim language by specifically pointing to
page(s) and line number(s) in the specification and/or drawing figure(s). This will assist
Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111 (c).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN CHE-CHUN TONG whose telephone number is (703)756-1737. The examiner can normally be reached Monday-Thursday: 7:30 AM to 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on (571)270-1014. 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.
/J.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196