Prosecution Insights
Last updated: October 04, 2026
Application No. 18/406,442

ORCHESTRATOR FOR OPTIMIZING HPC COMPUTTING JOB ALLOCATION

Final Rejection §103
Filed
Jan 08, 2024
Examiner
EWALD, JOHN ROBERT DAKITA
Art Unit
2199
Tech Center
2100 — Computer Architecture & Software
Assignee
RTX Corporation
OA Round
2 (Final)
77%
Grant Probability
Favorable
3-4
OA Rounds
7m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allowance Rate
23 granted / 30 resolved
+21.7% vs TC avg
Strong +49% interview lift
Without
With
+49.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 4m
Avg Prosecution
17 currently pending
Career history
51
Total Applications
across all art units

Statute-Specific Performance

§101
7.8%
-32.2% vs TC avg
§103
63.2%
+23.2% vs TC avg
§102
12.4%
-27.6% vs TC avg
§112
14.0%
-26.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 30 resolved cases

Office Action

§103
CTNF 18/406,442 CTNF 99329 DETAILED ACTION 07-03-aia AIA 15-10-aia 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 in this application. Information Disclosure Statement The IDS’s filed on 1/08/2024 and 7/09/2025 have been considered. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1-6, 8-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ferreira et al. (US Pub. No. 2022/0327001 A1 hereinafter Ferreira *cited in IDS*) in view of Poort et al. (US Patent No. 11,809,907 B2 hereinafter Poort *cited in IDS*) . As per claim 1, Ferreira teaches a computer-implemented method for high-performance computing (HPC) (See Abstract and ¶ [0025], “In addition to cloud computing providers 110A, 110B, and 110C, in some embodiments, management server 160 may also be configured to communicate with bare metal computing devices 130A and 130B (e.g., non-virtualized servers), as well as a datacenter 120 including for example one or more supercomputers or high-performance computing (HPC) systems (e.g., each having multiple nodes organized into clusters, with each node having multiple processors and memory), and storage system 190.”) , comprising: receiving, from a user, a computing job request that includes or describes input data required for performing a computing job, and includes an urgency request for the computing job (¶ [0028], “The management application 170 may be configured to provide an interface to users (e.g., via a web application, portal, API server or command line interface) that permits users and administrators to submit applications (also called jobs) via their network-connected PCs, servers, or workstations (140A), or laptop or mobile devices (140B). The management application 170 may present the user with controls to specify the application, the type of application (e.g., TensorFlow, scikit-learn, Caffe, etc.), the data sources to be used by the application, designate a destination for the results of the application, and selected application requirements (e.g., parameters such as a minimum number of processors to use, a minimum amount of memory to use, a minimum number of accelerators such as GPUs or TPUs or FPGAs, a minimum interconnection type or speed, cost limits, time limit for job completion , etc.).”); determining, for a plurality of HPC environments, an extent to which the plurality of HPC environments can perform the computing job and fulfill the urgency request (¶ [0025], “Management server 160 is connected to a number of different computing devices and services via local or wide area network connections 150 such as the Internet…In addition to cloud computing providers 110A, 110B, and 110C, in some embodiments, management server 160 may also be configured to communicate with bare metal computing devices 130A and 130B (e.g., non-virtualized servers), as well as a datacenter 120 including for example one or more supercomputers or high-performance computing (HPC) systems (e.g., each having multiple nodes organized into clusters, with each node having multiple processors and memory), and storage system 190.” ¶ [0028], “The management application may then select and search multiple clouds (e.g., clouds 110A-B) that offer spot instance types meeting the requirements. The management application may access the selected cloud systems, determine spot instance availability and pricing, and assemble a list of available instance types by stepping through different instance types (e.g., 2 CPUs, 4CPUs, 6 CPUs, etc.) for each selected cloud service. The resulting list may for example be filtered to offer the best matches to the user from the available instance types.” See also para. 0030.); based on the determining, presenting to the user a summary of a cost and availability of each of the plurality of HPC environments for performance of the computing job according to the urgency request (¶ [0028], “The management application 170 may present this to the user and permit them to select one to be used to run the application.” ¶ [0032], “The list of available instance types may be filtered and or sorted (step 232) and presented to the user (step 236). For example, in one embodiment if a large number of instance types are available, they may be sorted and presented to the user from lowest cost to highest cost. In another example embodiment, they may be filtered to provide a lowest cost option, a highest performance option, and a best bargain option (e.g., largest price discount relative to a reserved instance). Different instance types may be sorted for example based on relative performance (e.g., based on historical benchmark data collected by the system, wherein the benchmark is selected to from a set of benchmarks to approximate the user's application).”); receiving a selection of one of the plurality of HPC environments from the user based on the summary (¶ [0033], “The user's selection from the available options maybe received (step 240), and the availability of that option may be confirmed (step 244). For example, an available instance may become unavailable during the delay between the system initially receiving the availability information and the user making their selection.”); and allocating the computing job to the selected HPC environment (¶ [0034], “The job may then be deployed to the selected instance type (step 252). This may entail creating an instance on the selected cloud provider's system of the selected instance type and loading the application onto the instance once it has been created.”). Ferreira fails to explicitly teach an in-house HPC environment and third-party HPC environments. However, Poort teaches a plurality of HPC environments, which include an in-house HPC environment associated with the user and a plurality of third-party HPC environments (Col. 12, lines 17-25, “As alluded to above, the workflows and jobs of HPC users 155 are not executed directly by Multi-Provider Server 101. Instead the platform integrates with the computing resources provided by multiple different hardware providers, including public cloud providers 116, private data center providers 117 and the on-premise computing resources 118 provided by HPC users 155.” See also Fig. 1.). Ferreira and Poort are considered to be analogous to the claimed invention because they are in the same field of allocating hardware resources to service a request. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Ferreira with the well-known technique of employing in-house or third-party HPC environments of Poort to arrive at the claimed invention. This modification would have yielded predictable results and have been reasonable under MPEP § 2143 as both references allocate HPC environments to service a user’s job request. As per claim 2, Ferreira and Poort teach the method of claim 1. Ferreira teaches said determining and presenting are performed based on HPC environments not having sufficient computing capacity available to complete the computing job and fulfill the urgency request (¶ [0033], “If the selected instance type is no longer available, the next closest instance type may be presented to the user for confirmation (step 248). In other embodiments, the next closest instance type may be automatically selected and used without addition user intervention (e.g., if there is no difference in price or performance).”). Poort teaches the in-house HPC environment and the method includes, based on the in-house HPC environment having sufficient computing capacity available to complete the computing job and fulfill the urgency request, automatically allocating the computing job to the in-house HPC environment (Col. 10, lines 9-22, “In one embodiment, an HPC user 155 desires to utilize its own on-premise hardware and software environment in a manner that is otherwise independent of the platform.” Col. 16, lines 36-49, “This multi-provider approach affords HPC users 155 improved visibility into the costs of HPC workflows, as well as flexibility to optimize for cost, time and other desired factors by “mixing and matching” different hardware and software environments, “bursting” from on-premise hardware into the cloud for excess capacity, and other configuration, pricing and licensing options.”). As per claim 3, Ferreria and Poort teach the method of claim 1. Ferreira teaches the determining includes polling the plurality of HPC environments to determine pricing and availability of the plurality of HPC environments ; and the summary includes a ranking of the plurality of HPC environments based on an extent to which the plurality of HPC environments can complete the computing job according to the urgency request and based on cost (¶ [0032], “The list of available instance types may be filtered and or sorted (step 232) and presented to the user (step 236). For example, in one embodiment if a large number of instance types are available, they may be sorted and presented to the user from lowest cost to highest cost. In another example embodiment, they may be filtered to provide a lowest cost option, a highest performance option, and a best bargain option (e.g., largest price discount relative to a reserved instance). Different instance types may be sorted for example based on relative performance (e.g., based on historical benchmark data collected by the system, wherein the benchmark is selected to from a set of benchmarks to approximate the user's application). The user may be presented with controls to select what type of filtering or sorting they prefer.” See also para. 0028.). As per claim 4, Ferreira and Poort teach the method of claim 1. Ferreira teaches determining a set of computing resources required for performing the computing job, which includes receiving a description of the set of computing resources required for the computing job as part of the computing job request ; and determining the summary based on the determined set of computer resources required (¶ [0028], “The management application 170 may present the user with controls to specify the application, the type of application (e.g., TensorFlow, scikit-learn, Caffe, etc.), the data sources to be used by the application, designate a destination for the results of the application, and selected application requirements (e.g., parameters such as a minimum number of processors to use, a minimum amount of memory to use, a minimum number of accelerators such as GPUs or TPUs or FPGAs, a minimum interconnection type or speed, cost limits, time limit for job completion, etc.). The management application may then select and search multiple clouds (e.g., clouds 110A-B) that offer spot instance types meeting the requirements. The management application may access the selected cloud systems, determine spot instance availability and pricing, and assemble a list of available instance types by stepping through different instance types (e.g., 2 CPUs, 4CPUs, 6 CPUs, etc.) for each selected cloud service. The resulting list may for example be filtered to offer the best matches to the user from the available instance types.”). As per claim 5, Ferreira and Poort teach the method of claim 1. Ferreira teaches determining a set of computing resources required for performing computing job, which includes estimating the set of computing resources required for the computing job based on the computing job request ; and determining the summary based on the estimated set of computer resources required (¶ [0028], “The management application 170 may present the user with controls to specify the application, the type of application (e.g., TensorFlow, scikit-learn, Caffe, etc.), the data sources to be used by the application, designate a destination for the results of the application, and selected application requirements (e.g., parameters such as a minimum number of processors to use, a minimum amount of memory to use, a minimum number of accelerators such as GPUs or TPUs or FPGAs, a minimum interconnection type or speed, cost limits, time limit for job completion, etc.).” ¶ [0031], “The selected cloud provider may be queried for the availability of one or more instance types that meet the current job's requirements (step 212) and associated data may be collected (step 216). For example, the configuration, price and number of instances available of a particular instance type may be collected. Based on the job requirements and or instance types offered by the selected cloud provider, a range may be used for each cloud provider. For example, if a job requirement is at least 2 CPUs and at least 2 GPUs, and a particular cloud provider offers various combinations of CPUs and GPUs from 1:1 up to 8:16, then the search range may be from 2:2 to 8:16. If collecting data for the search range has not been completed, the query may be stepped up or down (step 224) for additional matching instance types, and the cloud may again be queried for the availability of one or more instance types that meet the current job's requirements (step 212), associated data may be collected (216), and the process may be repeated until the search range has been completed (step 220).”). As per claim 6, Ferreira and Poort teach the method of claim 1. Ferreira teaches wherein the computing job request includes one or more of the following: a number of computing cores needed for the computing job; a type of computing core needed for the computing job; an amount of memory needed for the computing job; an estimated length of the computing job; an amount of data storage needed for the computing job; and an amount data transfer needed for uploading the input data to the HPC environment and for downloading output data of the computing job from the HPC environment (¶ [0029], “In this embodiment, job requirements are collected (step 200). For example, a minimum number of CPUs, a minimum number of GPUs, maximum execution time, minimum storage, data file size, geographic restrictions, and or minimum interconnection type/speed may be collected. These may for example be collected from a job metadata file, from previously stored job history (in the event the job is a repeat job or similar to a previous job), or interactively by prompting the user (e.g., via a web interface).”). As per claim 8, Ferreira and Poort teach the method of claim 1. Ferreira teaches wherein the summary includes a plurality of configurations for at least one of the third-party HPC environments that vary in terms of estimated completion date (¶ [0032], “Different instance types may be sorted for example based on relative performance (e.g., based on historical benchmark data collected by the system, wherein the benchmark is selected to from a set of benchmarks to approximate the user's application). The user may be presented with controls to select what type of filtering or sorting they prefer.” ¶ [0037], “Redundancy might be desirable for a user that wants to compare the performance of a job in parallel on two different instance types. For example, the administrator of the system for managing the spot market may periodically use this function to run many redundant instances of a benchmark across different instance types to populate a database of relative performance rankings that can be used in filtering/sorting different available instance types when presented to the user.”). As per claim 9, Ferreira teaches utilizing a machine learning algorithm trained with historical data of computing jobs performed by one of the plurality of HPC environments to predict future availability of computing resources at said one of the plurality of HPC environments (¶ [0043]-[0044], “In this embodiment, a training process (shown as steps 400 through 424 in the figure) is performed. The training process may comprise selecting a cloud provider (step 400), collecting and storing data for instance types from the cloud provider (step 404) and stepping up/down through different instance types (step 412) until a search range has been completed (step 408). This process may be repeated for multiple cloud providers (step 416), and the data collected may be stored and used to train a machine learning model to recognize availability patterns (step 420). For example, a machine learning model may be created (e.g., using the scikit-learn package in Python) to recognize if there are certain times (e.g., times of day or days of week) where availability for certain instance types is predicted to be higher…The user's job requirements may be received (step 430), and a multi-cloud provider search may be performed based on those requirements to identify available instance types (step 434). The list of available instance types may be filtered and or sorted and presented to the user (step 436) as described above. The results may be fed into the machine learning (ML) model, and if the ML model indicates that a better match is likely at some future time (step 438), the user may be presented with an option to defer deployment (step 442) for a selectable amount of time. For example, if the user is requesting an instance at noon local time Friday, the ML model may indicate that a better deal (e.g., a twice as powerful system at half the cost) is likely to be available in the next 8 hours. The user may be presented with an option to defer the deployment up to a selected time delay (e.g., 12 hours) in hopes of securing a reduced cost (step 446).”). As per claim 10, Ferreira and Poort teach the method of claim 1. Ferreira teaches wherein for each of at least one of the plurality of HPC environments that can perform the computing job but cannot also fulfill the urgency request, the summary includes a best effort option for the HPC environment that indicates an earliest time the computing job could be completed by the HPC environment (¶ [0032], “For example, in one embodiment if a large number of instance types are available, they may be sorted and presented to the user from lowest cost to highest cost. In another example embodiment, they may be filtered to provide a lowest cost option, a highest performance option, and a best bargain option (e.g., largest price discount relative to a reserved instance).” ¶ [0044], “For example, if the user is requesting an instance at noon local time Friday, the ML model may indicate that a better deal (e.g., a twice as powerful system at half the cost) is likely to be available in the next 8 hours. The user may be presented with an option to defer the deployment up to a selected time delay (e.g., 12 hours) in hopes of securing a reduced cost (step 446). The user may elect to deploy immediately (step 454) or wait, in which case the system may want until the predicted better deal becomes available (e.g., periodically checking the clouds for availability)…”). As per claim 11, it is a device claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Ferreira also teaches processing circuitry operatively connected to memory (¶ [0026], “Management server 160 may be a traditional PC or server, a specialized appliance, one or more nodes within a cluster (e.g., running within a virtual machine or container). Management server 160 may be configured with one or more processors (physical or virtual), volatile memory, and non-volatile memory such as flash storage or internal or external hard disk (e.g., network attached storage accessible to management server 160).”). As per claim 12, it is a device claim comprising similar limitations to claim 2, so it is rejected for similar reasons. As per claim 13, it is a device claim comprising similar limitations to claim 3, so it is rejected for similar reasons. As per claim 14, it is a device claim comprising similar limitations to claim 4, so it is rejected for similar reasons. As per claim 15, it is a device claim comprising similar limitations to claim 5, so it is rejected for similar reasons. As per claim 16, it is a device claim comprising similar limitations to claim 6, so it is rejected for similar reasons. As per claim 18, it is a device claim comprising similar limitations to claim 8, so it is rejected for similar reasons. As per claim 19, it is a device claim comprising similar limitations to claim 9, so it is rejected for similar reasons. As per claim 20, it is a device claim comprising similar limitations to claim 10, so it is rejected for similar reasons . 07-22-aia AIA Claim (s) 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ferreira and Poort as applied to claim s 1 and 11 above, and further in view of Kurtzer et al. (US Patent No. 10,970,113 B1 hereinafter Kurtzer) . As per claim 7, Ferreira and Poort teach the method of claim 1. Ferreira teaches the summary (¶ [0028], “The management application 170 may present this to the user and permit them to select one to be used to run the application.” ¶ [0032], “The list of available instance types may be filtered and or sorted (step 232) and presented to the user (step 236). For example, in one embodiment if a large number of instance types are available, they may be sorted and presented to the user from lowest cost to highest cost. In another example embodiment, they may be filtered to provide a lowest cost option, a highest performance option, and a best bargain option (e.g., largest price discount relative to a reserved instance). Different instance types may be sorted for example based on relative performance (e.g., based on historical benchmark data collected by the system, wherein the benchmark is selected to from a set of benchmarks to approximate the user's application).”). Ferreira and Poort fail teach considering data locality when generating the summary of HPC environments that is presented to the user. However, Kurtzer teaches the computing job includes a data locality requirement indicating one or more geographic restrictions on transfer of data associated with the computing job (Col. 2, lines 14-19, “In some embodiments, a distributed HPC orchestration system may perform the automatic orchestration in response to a user-provided task definition. The task definition may identify the jobs associated with a task, the data for each job, and/or the set of policies that specify execution priorities for the task/job execution.” Col. 2 & 3, lines 52-67 & 1-4, “For instance, the distributed HPC orchestration system may instantiate and/or execute a particular job for a first task using on-premises compute nodes when the data for the particular job of the first task is stored at one or more on-premises storage devices and relocating the data would result in performance that does not satisfy one or more defined policies. The distributed HPC orchestration system may instantiate and/or execute the same particular job for a different second job using cloud compute nodes of a particular cloud service provider when the data for the particular job of the second task is stored in a storage cluster of the cloud service provider and the costs for relocating the data would violate one or more defined policies.” Col. 4 & 5, lines 58-67 & 1-3, “Primary orchestrator 101 may receive user-defined policies and/or task definitions for different HPC and/or other compute tasks from different users. Each task definition may specify a sequence of one or more compute jobs for stateful or stateless processing of data that may be stored at one or more storage locations , and/or for producing output based on the collective result of the compute jobs.”); and the method includes, based on the data locality requirement, excluding an HPC environment that is unable to comply with the data locality requirement (Col. 5, lines 22-50, “By prioritizing the selection of compute nodes 105 based on the user-defined policies and state information, primary orchestrator 101 does not perform a simplistic allocation of jobs to any available compute node 105. Instead, primary orchestrator 101 may dynamically and selectively execute each job using compute nodes 105 that provide greatest conformance to the policies based on the current state of compute nodes 105 and the task being executed, and/or that prioritize job execution according to the policies and the current state. Accordingly, the selection of compute nodes 105 for a first job in a particular task definition may be prioritized based on the location of the input data for the first job and the hardware resources that may complete the operations of the first job in the least amount of time, and the selection of compute nodes 105 for a second job in the particular task definition may be affected by the selection of compute nodes 105 for the first job. For instance, the selection of compute nodes 105 for the first job may set a location where input data and/or other dependencies for the second job may be found, and execution time for the second job may be minimized by selecting compute nodes 105 that are located in the same or a geographically proximate compute cluster 107 as the compute nodes 105 selected for the first job, and that include hardware resources that are optimized for the operations of the second job.” See also Col. 9, lines 18-47.). Ferreira, Poort, and Kurtzer are all considered to be analogous to the claimed invention because they are all in the same field of allocating hardware resources to service a request. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for high performance computing (HPC) of Ferreira and Poort with the data locality policies of Kurtzer to arrive at the claimed invention. The motivation to modify Ferreira and Poort with the teachings of Kurtzer is that considering data locality when determining where to execute a job avoids any performance deficiencies due to failed or prolonged data transfers (See Kurtzer Col. 2 & 3, lines 52-67 & 1-4.). As per claim 17, it is a device claim comprising similar limitations to claim 7, so it is rejected for similar reasons . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Hillier et al. (US Pub. No. 2025/0021459 A1) teaches using workload characteristics to identify suitable environments for executing said workload . Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 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, Lewis Bullock can be reached at (571)272-3759. 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.D.E./Examiner, Art Unit 2199 /LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199 Application/Control Number: 18/406,442 Page 2 Art Unit: 2199 Application/Control Number: 18/406,442 Page 3 Art Unit: 2199 Application/Control Number: 18/406,442 Page 4 Art Unit: 2199 Application/Control Number: 18/406,442 Page 5 Art Unit: 2199 Application/Control Number: 18/406,442 Page 6 Art Unit: 2199 Application/Control Number: 18/406,442 Page 7 Art Unit: 2199 Application/Control Number: 18/406,442 Page 8 Art Unit: 2199 Application/Control Number: 18/406,442 Page 9 Art Unit: 2199 Application/Control Number: 18/406,442 Page 10 Art Unit: 2199 Application/Control Number: 18/406,442 Page 11 Art Unit: 2199 Application/Control Number: 18/406,442 Page 12 Art Unit: 2199 Application/Control Number: 18/406,442 Page 13 Art Unit: 2199 Application/Control Number: 18/406,442 Page 14 Art Unit: 2199 Application/Control Number: 18/406,442 Page 15 Art Unit: 2199 Application/Control Number: 18/406,442 Page 16 Art Unit: 2199 Application/Control Number: 18/406,442 Page 17 Art Unit: 2199 Application/Control Number: 18/406,442 Page 18 Art Unit: 2199
Read full office action

Prosecution Timeline

Jan 08, 2024
Application Filed
Apr 15, 2026
Non-Final Rejection mailed — §103
Jul 15, 2026
Response Filed
Sep 29, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12705084
MIGRATING A FUNCTION BETWEEN VIRTUAL MACHINES
3y 1m to grant Granted Aug 11, 2026
Patent 12693883
Method for controlling a distributed computer system and associated devices
3y 8m to grant Granted Jul 28, 2026
Patent 12688040
DATA PROCESSING APPARATUS AND METHODS TENSOR TRANSFORM OPERATION
3y 3m to grant Granted Jul 21, 2026
Patent 12619459
EXTENDING PARALLEL SOFTWARE THREADS
4y 3m to grant Granted May 05, 2026
Patent 12602267
DYNAMIC APPLICATION PROGRAMMING INTERFACE MODIFICATION TO ADDRESS HARDWARE DEPRECIATION
3y 3m to grant Granted Apr 14, 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

3-4
Expected OA Rounds
77%
Grant Probability
99%
With Interview (+49.3%)
3y 4m (~7m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 30 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