Prosecution Insights
Last updated: October 01, 2026
Application No. 18/403,975

TECHNIQUES FOR A UNIFIED SIMULATION INTERFACE

Final Rejection §103
Filed
Jan 04, 2024
Examiner
MACASIANO, JOANNE GONZALES
Art Unit
2197
Tech Center
2100 — Computer Architecture & Software
Assignee
GM Cruise Holdings LLC
OA Round
2 (Final)
67%
Grant Probability
Favorable
3-4
OA Rounds
9m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 67% — above average
67%
Career Allowance Rate
217 granted / 323 resolved
+12.2% vs TC avg
Strong +42% interview lift
Without
With
+41.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
19 currently pending
Career history
353
Total Applications
across all art units

Statute-Specific Performance

§101
12.7%
-27.3% vs TC avg
§103
62.3%
+22.3% vs TC avg
§102
15.1%
-24.9% vs TC avg
§112
8.5%
-31.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 323 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 . Response to Amendment With respect to Applicant’s amendment of claims 1, 11 and 17 with regards to the rejection under 35 U.S.C. 112, rejections with respect to the same have been withdrawn. 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, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos et al. (US PGPUB 2015/0339217; hereinafter “Avgerinos”) in view of Saha et al. (US PGPUB 2023/0106929; hereinafter “Saha”) and Wang et al. (US PGPUB 2022/0058490; hereinafter “Wang”). Claim 1: (Currently Amended) Avgerinos teaches a unified simulation interface system comprising: a software client configured to receive a simulation build graph ([0056] “Once the CFG is obtained, various example embodiments of the methods and systems discussed herein proceed to the next operation.” [0110] “The software testing machine 1110 is shown as including… a CFG module 1240 (e.g., a control flow graph generator, as discussed above with respect to FIG. 3).” [0136] “the machine 1700 may operate in the capacity of a server machine or a client machine.”), wherein the simulation build graph comprises a static portion and a dynamic portion ([0047] “DSE [dynamic symbolic exploration] and SSE [static symbolic exploration] may be combined (e.g., alternated dynamically and opportunistically).” [0049] “the example embodiments analyze a dynamically recovered CFG and identify a core of statements that are easy for SSE to analyze, as well as a frontier of statements that are difficult for SSE to analyze. The SSE algorithm summarizes the effects of all paths through the easy statements (e.g., nodes) up to the hard frontier. Accordingly, some example embodiments of the methods and systems described herein then switch back to DSE to handle the statically difficult cases appropriately and may thereafter alternate between DSE and SSE in response to similar criteria.”), and wherein the software client generates [inputs] for execution nodes comprising the static portion of the simulation build graph ([0006] “Symbolic execution can be attractive, because it systematically explores the software code (e.g., program) and produces real inputs… by automatically translating a software code fragment… into a formula… The logical formula is then solved to determine inputs.” [0116] “In operation 1340, the SSE module 1220 performs a static phase (e.g., an SSE phase) of the automatic test of the software code. Specifically, the SSE module 1220 performs SSE on the portion (e.g., the second portion) of the execution paths determined in operation 1330 to be devoid of non-statically interpretable executable statements.”); a processor invoked by the software client to generate the [inputs] for execution nodes comprising the dynamic portion of the simulation build graph ([0111] “Any one or more of the modules described herein may be implemented using hardware alone (e.g., one or more processors 1299 of a machine) or a combination of hardware and software.” [0006] “Symbolic execution can be attractive, because it systematically explores the software code (e.g., program) and produces real inputs… by automatically translating a software code fragment… into a formula… The logical formula is then solved to determine inputs.” [0114] “In operation 1320, the DSE module 1210 performs a dynamic phase (e.g., DSE phase) of an automatic test of the software code. Specifically, the DSE module 1210 performs DSE on a portion (e.g., a first portion) of the execution paths of the software code”); and a remote build execution server configured to receive the [inputs] generated by the software client and the processor, and to schedule execution of tasks in connection with the received [inputs] for the execution nodes of the simulation build graph on a compute cluster ([0127] “As shown in FIG. 15, operation 1560 may be performed after operation 1350, in which the solver module 1230 generates the set of test cases based on formulas generated during the dynamic and static phases (e.g., multiple dynamic phase and multiple static phases) of the automatic test. In operation 1560, the solver module 1230 determines a set of one or more software bugs in the software code. The determination may be performed by concretely executing one or more test cases from the generated set of test cases from operation 1350.” [0085] “In performing the evaluations, all experiments on the example system were distributed among a private cluster consisting of 100 virtual nodes (e.g., virtual software testing machines).” [0148] “The performance of certain operations may be distributed among the one or more processors, whether residing only within a single machine or deployed across a number of machines.”). With further regard to Claim 1, Avgerinos does not teach the following, however, Saha teaches: wherein generating [inputs] comprises generating application programming interface (API) payloads for execution nodes ([0021] “paths of the PDG may be explored by generating inputs that are similar to inputs that resulted in failures,” wherein the “PDG” is similar to the “CFG” discussed in Avgerinos. [0024] “the initial test input generation module 108 generates random input… the random test inputs may include a sequence of API calls with random data,” wherein the “random data” is the “payload” in this instance. [0044] “generating realistic production payload data in privacy-preserving way to recommend untested system behavior for black-box API access.”); and Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos with the use of API payloads as taught by Saha in order to “enable developers to design a technology-agnostic API interface” (Saha [0019]). With further regard to Claim 1, Avgerinos in view of Saha does not teach the following, however, Wang teaches: a processor to process the dynamic portion of the simulation build graph to represent the dynamic portion as a secondary static graph ([0025] “There may be two solutions. One solution is to rewrite, by a user, the codes that has been debugged in the dynamic graph mode (hereinafter referred to as a dynamic graph codes) to a corresponding codes executable in the static graph mode (hereinafter referred to as a static graph codes).” [0026] “The other solution is to perform a conversion between the dynamic graph codes and the static graph codes (hereinafter referred to as dynamic-static conversion) by a computing device.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha with the conversion of dynamic graph information to static graph information as taught by Wang since “codes written in a programming language in the dynamic graph mode cannot directly run in the static graph mode” (Wang [0024]). Claim 11: With regard to Claim 11, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 11 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1. Claim 17: With regard to Claim 17, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 17 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1. With further regard to Claim 17, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Avgerinos reference also anticipates these additional elements of Claim 17, for example, Avgerinos teaches: One or more non-transitory computer-readable storage media comprising instructions for execution that, when executed by a processor, are operable to cause to be performed operations ([0135] “FIG. 17 is a block diagram illustrating components of a machine 1700, according to some example embodiments, able to read instructions 1724 from a machine-readable medium 1722 (e.g., a non-transitory machine-readable medium, a machine-readable storage medium, a computer-readable storage medium, or any suitable combination thereof) and perform any one or more of the methodologies discussed herein.” [0137] “The machine 1700 includes a processor 1702”). Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha and Wang as applied to Claim 1 above, and further in view of Plate et al. (US PGPUB 2025/0348596; hereinafter “Plate”). Claim 3: (Currently Amended) Avgerinos in view of Saha and Wang teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha and Wang does not teach the following, however, Plate teaches: wherein the software client comprises a Bazel client ([0054] “In some cases, the orchestrator 145 may use Bazel, an open-source build tool used for the automation of building and testing software.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha and Wang with the Bazel client as taught by Plate in order to reduce software development costs, as Bazel is a free open-source software tool. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha, Wang and Plate as applied to Claim 3 above, and further in view of Urhegyi (“Introducing the Remote Execution API Testing Project,” 2019; hereinafter “Urhegyi”). Claim 4: Avgerinos in view of Saha, Wang and Plate teaches all the limitations of claim 3 as described above. Avgerinos in view of Saha, Wang and Plate does not teach the following, however, Urhegyi teaches: wherein the API payloads comprise Bazel remote execution API (REAPI) payloads (Paragraphs 1-2: “Introducing Remote Execution to builds will help achieve this, and for this, there is Bazel's Remote Execution API, which gives us the ability to parallelise the construction and validation phases of the software development cycle, and thus massively reduce elapsed time. The API specifies protocols for both client and server.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha, Wang and Plate with the use of the remote execution API as taught by Urhegyi in order “to get critical updates and features out to users as quickly as possible and … to increase the productivity of teams who rely on an efficient edit and compile cycle” (Urhegyi Paragraph 1). Claims 5, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha and Wang as applied to Claims 1, 11 and 17 above, and further in view of Mazumdar et al. (US PGPUB 2023/0195596; hereinafter “Mazumdar”). Claim 5: Avgerinos in view of Saha and Wang teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha and Wang does not teach the following, however, Mazumdar teaches: wherein the compute cluster comprises a compute scheduler and a plurality of compute workers ([0049] “The cloud platform 1406 may include a runtime service 1417 that may provide an intermediate persistence layer for test execution requests which will be consumed by a poller service 1422 deployed in a cluster 1418.” [0059] “The cluster 1418 may be comprised of one master node (not shown) and a number of worker nodes on which the services (e.g., poller service, scheduler service, execution jobs, etc.) run.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha and Wang with the compute cluster components as taught by Mazumdar in order “to facilitate dynamic load testing with multiple load testing tools in a shared platform” (Mazumdar [0028]). Claims 13 and 19: With regard to Claims 13 and 19, these claims are equivalent in scope to Claim 5 rejected above, merely having a different independent claim type, and as such Claims 13 and 19 are rejected under the same grounds and for the same reasons as discussed above with regard to Claim 5. Claims 6-7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha and Wang as applied to Claims 1, 11 and 17 above, and further in view of Reddy et al. (US PGPUB 2022/0164181; hereinafter “Reddy”). Claim 6: Avgerinos in view of Saha and Wang teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha and Wang does not teach the following, however, Reddy teaches: wherein the nodes comprising the dynamic portion of the simulation build graph comprise dynamic dependencies among the nodes of the dynamic portion of the simulation build graph ([0006] “An internal-domain dynamic dependency graph is generated, in an aspect, by tracing a first plurality of method calls based on execution of the code base in an internal domain. The internal-domain dynamic dependency graph includes a second plurality of dependencies identified for the one or more client workflows based on the first plurality of method calls, in some aspects.” [0060] “the internal-domain dynamic dependency graph can indicate which method calls “called” other particular methods, which specific methods were called by other methods, and the sequencing of calls/calling between methods”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha and Wang with the graph comprising dynamic dependencies as taught by Reddy as this “provides a comprehensive view of all or nearly all of the dependencies present in the workflows” (Reddy [0044]). Claim 7: Avgerinos in view of Saha and Wang teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha and Wang does not teach the following, however, Reddy teaches: wherein the nodes comprising the static portion of the simulation build graph comprise only static dependencies ([0005] “a static dependency graph is generated that maps a first plurality of dependencies for one or more client workflows encoded in a code base.” [0040] “the static dependency graph module 102 generates a static dependency graph that maps a first plurality of dependencies for one or more client workflows, as the workflows are encoded in a code base. The static dependency graph module 102 scans the code in a static manner, without execution of the code, in aspects.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha and Wang with the graph comprising static dependencies as taught by Reddy as this “provides a comprehensive view of all or nearly all of the dependencies present in the workflows” (Reddy [0044]). Claims 14 and 20: With regard to Claims 14 and 20, these claims are equivalent in scope to Claims 6-7 rejected above, merely having a different independent claim type, and as such Claims 14 and 20 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 6-7. Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha and Wang as applied to Claims 1 and 11 above, and further in view of Bramley-Moore (“remote_asset.proto,” 2023; hereinafter “Bramley-Moore”). Claim 8: Avgerinos in view of Saha and Wang teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha and Wang does not teach the following, however, Bramley-Moore teaches: further comprising a native object fetching service, wherein the native object fetching service is configured to move a data asset described using a Bazel remote execution API (REAPI) extension directly to a compute worker from a data store remote from the compute worker (Lines 32-33: “The Remote Asset API provides a mapping from a URI and Qualifiers to Digests.” Lines 86-88: “service Fetch { Resolve or fetch referenced assets, making them available to the caller and other consumers.” Line 102: “Servers *MAY* cache fetched content and reuse it for subsequent requests.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha and Wang with the use of the fetching service as taught by Bramley-Moore in order to standardize and simplify the manner in which data assets can be made available for use by the various software modules. Claim 15: With regard to Claim 15, this claim is equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claim 15 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8. Claims 9-10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha, Wang and Bramley-Moore as applied to Claims 8 and 15 above, and further in view of Schouten (“remote_execution.proto,” 2023; hereinafter “Schouten”). Claim 9: Avgerinos in view of Saha, Wang and Bramley-Moore teaches all the limitations of claim 8 as described above. Avgerinos in view of Saha, Wang and Bramley-Moore does not teach the following, however, Schouten teaches: wherein the native object fetching service further comprises a native Bazel target in which metadata for scheduling a replay on the compute worker is packaged (Lines 407-418: “Fetch the entire directory tree rooted at a node. This request must be targeted at a [Directory][build.bazel.remote.execution.v2.Directory] stored in the [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage] (CAS). The server will enumerate the `Directory` tree recursively and return every node descended from the root. The GetTreeRequest.page_token parameter can be used to skip ahead in the stream (e.g. when retrying a partially completed and aborted request), by setting it to a value taken from GetTreeResponse.next_page_token of the last successfully processed GetTreeResponse),” wherein the “GetTreeRequest.page_token parameter” is the “metadata for scheduling a replay”.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha, Wang and Bramley-Moore with the use of a Bazel target for the fetching service as taught by Schouten in order to standardize and simplify the manner in which data assets can be made available for use by the various software modules. Claim 10: Avgerinos in view of Saha, Wang, Bramley-Moore and Schouten teaches all the limitations of claim 9 as described above. Avgerinos in view of Saha, Wang and Bramley-Moore does not teach the following, however, Schouten teaches: wherein the native Bazel target employs at least one user-defined configuration flag to expand capabilities of the native Bazel target (Lines 1767-1773: “message GetTreeRequest {The instance of the execution system to operate against. A server may support multiple instances of the execution system (with their own workers, storage, caches, etc.). The server MAY require use of this field to select between them in an implementation-defined fashion, otherwise it can be omitted. string instance_name = 1,” wherein the “string instance_name = 1” is the “user-defined configuration flag”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Avgerinos in view of Saha, Wang and Bramley-Moore with the use of a user-defined configuration flag as taught by Schouten in order to advantageously enable the ‘fetching-service’ to be customized based on a user’s desired functionality. Claim 16: With regard to Claim 16, this claim is equivalent in scope to Claim 9 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 9. Claims 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha and Wang as applied to Claims 11 and 17 above, and further in view of Urhegyi. Claim 12: Avgerinos in view of Saha and Wang teaches all the limitations of claim 11 as described above. Avgerinos in view of Saha and Wang does not teach the following, however, Urhegyi teaches: wherein the API payloads comprise Bazel remote execution API (REAPI) payloads (Paragraphs 1-2: “Introducing Remote Execution to builds will help achieve this, and for this, there is Bazel's Remote Execution API, which gives us the ability to parallelise the construction and validation phases of the software development cycle, and thus massively reduce elapsed time. The API specifies protocols for both client and server.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Avgerinos in view of Saha and Wang with the use of the remote execution API as taught by Urhegyi in order “to get critical updates and features out to users as quickly as possible and … to increase the productivity of teams who rely on an efficient edit and compile cycle” (Urhegyi Paragraph 1). Claim 18: With regard to Claim 18, this claim is equivalent in scope to Claim 12 rejected above, merely having a different independent claim type, and as such Claim 18 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 12. Response to Arguments Applicant's arguments, see Pages 7-9 of the Remarks filed May 8, 2026, with respect to the rejections under 35 U.S.C. 103 of Claims 1 and 3-20 have been fully considered but they are not persuasive. With respect to the Applicant’s argument that the newly amended language of Claims 1 and 3-20 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Wang et al. (US PGPUB 2022/0058490) reference as discussed above in the respective rejections. With respect to the Applicant’s further arguments, Page 9 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to claims discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows: Battiato et al. (US PGPUB 2023/0089336) discusses a system and method for providing the ability to automate the process of generating load tests used for benchmarking APIs, particularly with regard to rapid generation of test suites for verifying the operation of REST APIs. 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. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time. 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, Bradley Teets can be reached at (571) 272-3338. 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. /JOANNE G MACASIANO/ Examiner, Art Unit 2197
Read full office action

Prosecution Timeline

Jan 04, 2024
Application Filed
Feb 10, 2026
Non-Final Rejection mailed — §103
May 08, 2026
Response Filed
Jul 29, 2026
Final Rejection mailed — §103
Sep 28, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12657119
SELF-CONTAINED MOBILE APPLICATION PROCESSING AND INTEGRATION
3y 9m to grant Granted Jun 16, 2026
Patent 12657076
SYSTEM AND METHOD FOR PROCESSING DATA OF ANY EXTERNAL SERVICES THROUGH API CONTROLLED UNIVERSAL COMPUTING ELEMENTS
2y 2m to grant Granted Jun 16, 2026
Patent 12650682
INDUSTRIAL AUTOMATION PROJECT DESIGN TELEMETRY
4y 8m to grant Granted Jun 09, 2026
Patent 12639193
SYSTEMS AND METHODS FOR RETRIEVAL-AUGMENTED PATCH GENERATION FOR AUTOMATIC PROGRAM REPAIR
3y 9m to grant Granted May 26, 2026
Patent 12613689
ELECTRONIC CONTROL DEVICE, REPROGRAM EXECUTION METHOD, AND NON-TRANSITORY COMPUTER READABLE STORAGE MEDIUM
3y 0m to grant Granted Apr 28, 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
67%
Grant Probability
99%
With Interview (+41.8%)
3y 6m (~9m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 323 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