Prosecution Insights
Last updated: July 05, 2026
Application No. 18/630,416

Managing Different Compute-Intensive Workloads In Cloud

Non-Final OA §103
Filed
Apr 09, 2024
Examiner
LI, HARRISON
Art Unit
Tech Center
Assignee
International Business Machines Corporation
OA Round
1 (Non-Final)
68%
Grant Probability
Favorable
1-2
OA Rounds
1y 8m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allowance Rate
15 granted / 22 resolved
+8.2% vs TC avg
Strong +53% interview lift
Without
With
+52.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 11m
Avg Prosecution
17 currently pending
Career history
50
Total Applications
across all art units

Statute-Specific Performance

§101
6.8%
-33.2% vs TC avg
§103
89.6%
+49.6% vs TC avg
§112
3.7%
-36.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 22 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claims 1-20 are pending. 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, 9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gummaraju et al. US 20160378554 A1 in view of Netes US 20240104096 A1. Regarding claim 1, Gummaraju teaches the invention substantially as claimed including: A computer-implemented method for enhancing data processing, the computer-implemented method comprising: generating, by a computer, a plurality of derivative application instances to run a plurality of parallel jobs based on an image of an instance of an application providing a service corresponding to a data processing request ([0016] In order to process received job requests, the job resolution system 114 maintains a set of parent special purpose VMs 108a-108c. The job resolution system 114 uses the parent special purpose VMs 108a-108c as templates to create and provision child special purpose VMs to execute the job request), the computer generating one derivative application instance for each respective job of the plurality of parallel jobs to run the plurality of parallel jobs at a same time in parallel to meet defined data processing performance objectives ([0024] The instantiation engine 118 determines the number of children special purpose VMs to instantiate based on the number of tasks; [0025] The service engine 116 assigns the identified tasks to the instantiated child special purpose VMs with each child special purpose assigned at least one task; [0006] By using virtual machines to perform tasks in parallel, performance and security isolation in executing tasks can be improved. In particular, the parallel execution allows for the simultaneous processing of multiple streams of data, which increases performance and decreases execution time. The distributed nature in the execution of tasks on multiple virtual machines provides increased security isolation. By performing multiple tasks in parallel, virtual machines increase hardware utilization and reduce capital and operating costs by sharing virtual machines. Additionally, virtual machines provide flexibility in allowing applications to execute in different operating environments); and running, by the computer, the plurality of parallel jobs on the plurality of derivative application instances at the same time in parallel to increase data processing throughput and decrease an amount of time and resources needed to fulfill the data processing request ([0006] By using virtual machines to perform tasks in parallel, performance and security isolation in executing tasks can be improved. In particular, the parallel execution allows for the simultaneous processing of multiple streams of data, which increases performance and decreases execution time. The distributed nature in the execution of tasks on multiple virtual machines provides increased security isolation. By performing multiple tasks in parallel, virtual machines increase hardware utilization and reduce capital and operating costs by sharing virtual machines. Additionally, virtual machines provide flexibility in allowing applications to execute in different operating environments), each job of the plurality of parallel jobs retrieves a particular chunk of a dataset corresponding to the data processing request from a database to process that particular chunk of the dataset to generate a sub-result of the data processing request ([0027] The service engine 116 receives an output from each child special purpose VM assigned to perform a task. The service engine 116 aggregates and integrates the output from each child special purpose VM, and then, the service engine 116 stores the job results in memory or provides the job results to an external system, e.g., to the user who requested the job). While Gummaraju teaches the system including databases ([0020] The software framework may include support programs, a file system, compilers, code libraries, tool sets, application programming interfaces (APIs), and so on that bring together different components to enable development of a project or solution, for example, the completion of a job request. For example, Hadoop® and MongoDB® are example software frameworks; [0059] a database management system), Gummaraju does not explicitly teach each job of the plurality of parallel jobs retrieves a particular chunk of a dataset corresponding to the data processing request from a database to process that particular chunk of the dataset to generate a sub-result of the data processing request. However, Netes teaches each job of the plurality of parallel jobs retrieves a particular chunk of a dataset corresponding to the data processing request from a database to process that particular chunk of the dataset to generate a sub-result of the data processing request ([0050] receiving a data request from a client, the data request directed to data stored in a plurality of data shards, determining a set of operating parameters of the data shards for retrieving data from the plurality of shards, determining a chunking factor based on the set of operating parameters, dividing the data request into a plurality of API requests based on the chunking factor, each of the API requests directed to a portion of the plurality of data shards, and communicating the plurality of API requests in parallel to a source API configured to perform data queries on the plurality of data shards). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Nete’s parallel data querying jobs with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of improving data access latency through parallelization (see Nete [0014] A high latency query optimization system disclosed herein allows retrieving data organized in data shard faster, more efficiently, and in a more flexible manner). Regarding claim 9, it is the computer system of claim 1 respectively. Therefore, they are rejected for the same reasons as claim 1 respectfully. Gummaraju further teaches a communication fabric (Fig 1 Network 100; [0015] a data communication network 120. The data communication network 120, e.g., a local area network (LAN) or wide area network (WAN), e.g., the Internet, or a combination of networks, connects the user 122 and the job resolution system 114); a set of computer-readable storage media connected to the communication fabric, wherein the set of computer-readable storage media collectively stores program instructions ([0058] Embodiments of the subject matter described in this document can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution); and a set of processors connected to the communication fabric ([0061] The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output;[0062] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data). Regarding claim 15, it is the computer program product of claim 1 respectively. Therefore, they are rejected for the same reasons as claim 1 respectfully. Gummaraju further teaches the computer program product comprising a set of computer-readable storage media having program instructions collectively stored therein, the program instructions executable by a computer to cause the computer ([0058] Embodiments of the subject matter described in this document can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus). Claims 2, 3, 8, 10, 11, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Gummaraju et al. US 20160378554 A1 in view of Netes US 20240104096 A1 in view of Seetharaman et al. US 20210406102 A1. Regarding claim 2, Gummaraju and Netes teach the computer-implemented method of claim 1. Gummaraju further teaches receiving, by the computer, the data processing request corresponding to the service provided by the application of the computer from a client device of a user (Fig 1A User + User Device; [0015] The job resolution system 114 converts the job requests received from the user 122 into a job to be processed using special purpose virtual machines (VMs) executing on one or more physical machines, e.g. physical machines 102a or 102b. Generally, a job request is a request to process input data identified in the request using a specific service); determining, by the computer, whether the data processing request satisfies an interception rule of a plurality of interception rules ([0015] The job resolution system 114 may process job requests for several different service types, e.g., job requests for a distributed data processing framework and job requests for a remote display protocol; [0018] Each of the parent special purpose VMs 108a-108c is specific to a respective service type of a job request and executes on one of multiple physical machines 102a and 102b. That is, the infrastructure and configuration of each parent special purpose VM 108a-108c supports an optimal operating environment, e.g., operating environment 110 of FIG. 1B, for a respective service type; [0020] For a job request, the job resolution system 114 uses a parent special purpose VM, e.g., parent special purpose VM 108a, to instantiate one or more child special purpose VMs, e.g., child special purpose VMs 112a or 112b, in an optimal operating environment, e.g. operating environment 110, for a respective service type). Gummaraju and Netes do not explicitly teach sending, by the computer, a response to the client device indicating acceptance of the data processing request and identification of a specific location where a data processing result corresponding to the data processing request will be located in response to receiving the data processing request. However, Seetharaman teaches sending, by the computer, a response to the client device indicating acceptance of the data processing request ([0026 Once the request is determined to be handled asynchronously, user handler and reporting module 420A returns a HTTP 202 ‘Accepted’ code to the user 440 (e.g., to the user's browser), via API gateway 410) and identification of a specific location where a data processing result corresponding to the data processing request will be located in response to receiving the data processing request (Fig 3, 6; [0038] API gateway 410 accordingly notifies user/browser (see user 440 in FIG. 4) that job J1 has been added to the job queue; Examiner notes: Browser utilizes received job id to make GET requests for job status/results). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Seetharaman’s API gateway request handler system with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of asynchronous REST API handling for job request status updates (see Seetharaman [0006] To avoid such blocking behavior and data conflict possibility, microservice developers are tending towards changing the API handler to implement an asynchronous handling logic where the user's request is logged in a job queue and the API call returns right away with a job identifier (job ID). The microservice processes the jobs in the background and updates the status when done, in an asynchronous manner. In the meantime, the caller (i.e., user's computer browser) can keep polling or register a callback to get updates on the background job. This allows the browser to do other operations while the microservice is busy processing the last request). Regarding claim 3, Gummaraju, Netes, and Seetharaman teach the computer-implemented method of claim 2. Gummaraju further teaches dividing, by the computer, the data processing request into a plurality of sub-requests in accordance with the interception rule ([0022] The service engine 116 of the job resolution system 114 identifies one or more tasks in the job request that, when performed, collectively result in the completion of the job. A job is a series of tasks that perform an action that changes the status of a managed object. Some or all of the tasks that make up a job may depend on one or more of the other tasks that make up the job. A task depends on another task if data from the other task is necessary to complete execution of the task. In some implementations, the job resolution system 114 identifies one or more subtasks in one or more of the tasks, and the performance of the subtasks collectively results in the completion of the task) to meet the defined data processing performance objectives regarding at least one of time and resources needed to fulfill the data processing request ([0006] By using virtual machines to perform tasks in parallel, performance and security isolation in executing tasks can be improved. In particular, the parallel execution allows for the simultaneous processing of multiple streams of data, which increases performance and decreases execution time. The distributed nature in the execution of tasks on multiple virtual machines provides increased security isolation. By performing multiple tasks in parallel, virtual machines increase hardware utilization and reduce capital and operating costs by sharing virtual machines. Additionally, virtual machines provide flexibility in allowing applications to execute in different operating environments) in response to the computer determining that the data processing request does satisfy the interception rule (Fig 2 204; [0032] The system selects a parent special purpose VM from among a set of parent special purpose VMs to perform the job request (step 204). Each of the parent special purpose VMs is specific to a respective service type); and generating, by the computer, the plurality of parallel jobs to fulfill the data processing request in accordance with the defined data processing performance objectives, the computer generating one job for each respective sub-request of the plurality of sub-request ([0025] The service engine 116 assigns the identified tasks to the instantiated child special purpose VMs with each child special purpose assigned at least one task. The service engine 116 also determines if a task includes subtasks. In these instances, the instantiation engine 118 causes the respective child special purpose VM to instantiate additional child special purpose VMs, and then the service engine 116 assigns at least one subtask to each additional child special purpose VM). Regarding claim 8, Gummaraju and Netes teach the computer-implemented method of claim 1. Gummaraju further teaches sending, by the computer, the data processing result corresponding to the data processing request to the client device of the user ([0027] the service engine 116 … provides the job results to an external system, e.g., to the user who requested the job). Gummaraju and Netes do not explicitly teach receiving, by the computer, a request for a data processing result corresponding to the data processing request from a client device of a user, the request including a specific location where the data processing result is located; retrieving, by the computer, the data processing result corresponding to the data processing request from the specific location. However, Seetharaman teaches receiving, by the computer, a request for a data processing result corresponding to the data processing request from a client device of a user, the request including a specific location where the data processing result is located (Fig 3 Browser GET requests job result status of J1; retrieving, by the computer, the data processing result corresponding to the data processing request from the specific location (Fig 3 Job Result sent from DB to Browser; [0008] Subsequently, when the browser sends the request for a job update after execution of job J1 has ended, the job queue returns a “success” message. In response to the “success” message, the handler microservice accesses the database to read the job result. Upon receiving the job result from the database, the handler microservice forwards the “success” message and the job result to the API gateway, which forwards them to the browser). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Seetharaman’s job result retrieval method with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of asynchronous non blocking job status updates (see Seetharaman [0006] To avoid such blocking behavior and data conflict possibility, microservice developers are tending towards changing the API handler to implement an asynchronous handling logic where the user's request is logged in a job queue and the API call returns right away with a job identifier (job ID). The microservice processes the jobs in the background and updates the status when done, in an asynchronous manner. In the meantime, the caller (i.e., user's computer browser) can keep polling or register a callback to get updates on the background job. This allows the browser to do other operations while the microservice is busy processing the last request.). Regarding claims 10 and 11, they are the computer system of claims 2 and 3 respectively. Therefore, they are rejected for the same reasons as claims 2 and 3 respectfully. Regarding claims 16 and 17, they are the computer program product of claims 2 and 3 respectively. Therefore, they are rejected for the same reasons as claims 2 and 3 respectfully. Claims 4, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gummaraju et al. US 20160378554 A1 in view of Netes US 20240104096 A1 in view of Seetharaman et al. US 20210406102 A1 in view of Inagaki et al. US 20150120376 A1. Regarding claim 4, Gummaraju, Netes, and Seetharaman teach the computer-implemented method of claim 2. Seetharaman further teaches determining, by the computer, whether the data processing request was successfully processed (Fig 3 Job status as Success + Job Result). Gummaraju, Netes, and Seetharaman do not explicitly teach sending, by the computer, the data processing request to the instance of the application for processing in response to the computer determining that the data processing request does not satisfy the interception rule; However, Inagaki teaches sending, by the computer, the data processing request to the instance of the application for processing in response to the computer determining that the data processing request does not satisfy the interception rule (Fig 14 cloud distributed execution flag determines parallel processing for eligible jobs i.e., third job); It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Inagaki’s parallel processing determination with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of utilizing parallel processing of jobs when possible (see Inagaki [0006] Technology is known that generates parallel execution-type job control language in order to reduce the processing load of a processing device; [0067] The respective information of the "cloud execution assessment flag", the "job flow change flag", and the "cloud distributed execution flag" are information included in information indicating jobs processable in parallel in a processing series). Regarding claim 12, it is the computer system of claim 4 respectfully. Therefore, it is rejected for the same reasons as claim 4 respectfully. Regarding claim 18, it is the computer program product of claim 4 respectfully. Therefore, it is rejected for the same reasons as claim 4 respectfully. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Gummaraju et al. US 20160378554 A1 in view of Netes US 20240104096 A1 in view of Li et al. US 20100223297 A1. Regarding claim 7, Gummaraju and Netes teach the computer-implemented method of claim 1. Gummaraju further teaches merging, by the computer, the sub-result of each job of the plurality of parallel jobs into a data processing result corresponding to the data processing request in response to the computer determining that the sub-result generated by each job of the plurality of parallel jobs needs to be merged according to the merge logic; and storing, by the computer, the data processing result corresponding to the data processing request in a specific location ([0027] The service engine 116 receives an output from each child special purpose VM assigned to perform a task. The service engine 116 aggregates and integrates the output from each child special purpose VM, and then, the service engine 116 stores the job results in memory). Gummaraju and Netes does not explicitly teach determining, by the computer, whether the sub-result generated by each job of the plurality of parallel jobs needs to be merged according to merge logic. However, Li teaches determining, by the computer, whether the sub-result generated by each job of the plurality of parallel jobs needs to be merged according to merge logic ([0008] The configuration file may contain information specifying items such as the name of the database table for data merging, names of database table fields, the data insertion method to be used and the data merging method to be used). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Li’s data result merging method with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of guiding the merging of split result data into a comprehensive result (see Li [0004] In distributed computing, a project data that requires lots of computation is split into many small pieces, which are separately computed by many different computers. These different computers, called distributed nodes, send the distributed computational results back to a central computer. Upon uploading the distributed computational results, the central computer merges the results to obtain the final data or a solution; [0007] A data merging method for distributed computing uses a configuration file to guide the insertion of computational results obtained by distributed nodes into a database table, and to merge the computational results inserted in the database table. The configuration file is established according to the task splitting conditions of distributed computing). Allowable Subject Matter Claims 5, 6, 13, 14, 19, 20 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The examiner can normally be reached Monday-Friday 9:00am-5:30pm ET. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached on (571) 272-4169. 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. /H.L./ Examiner, Art Unit 2195 /Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Read full office action

Prosecution Timeline

Apr 09, 2024
Application Filed
Jun 11, 2026
Non-Final Rejection mailed — §103
Jun 18, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12670020
SYSTEMS AND METHODS FOR GENERATING RUNTIME PREDICTIONS IN DISTRIBUTED COMPUTER ARCHITECTURES
3y 11m to grant Granted Jun 30, 2026
Patent 12657045
VIRTUAL MACHINE MEMORY MANAGEMENT METHOD AND DEVICE
4y 2m to grant Granted Jun 16, 2026
Patent 12639126
LOAD DISTRIBUTION IN A DATA STORAGE SYSTEM
4y 1m to grant Granted May 26, 2026
Patent 12632291
CONTROLLING JOB PACKING PROCESSING UNIT CORES FOR GPU SHARING
4y 3m to grant Granted May 19, 2026
Patent 12547428
PAGE TRANSITION DETECTION USING SCREEN OPERATION HISTORY
4y 1m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
68%
Grant Probability
99%
With Interview (+52.8%)
3y 11m (~1y 8m remaining)
Median Time to Grant
Low
PTA Risk
Based on 22 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month