Prosecution Insights
Last updated: May 29, 2026
Application No. 18/339,539

ROBOTIC PROCESS AUTOMATION (RPA) ACCELERATION OF TASKS WITH MACHINE LEARNING GENERATION OF NETWORK REQUESTS

Non-Final OA §101§102§103
Filed
Jun 22, 2023
Examiner
HINCKLEY, CHASE PAUL
Art Unit
2124
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
1 (Non-Final)
68%
Grant Probability
Favorable
1-2
OA Rounds
11m
Est. Remaining
78%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allowance Rate
137 granted / 201 resolved
+13.2% vs TC avg
Moderate +10% lift
Without
With
+10.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 11m
Avg Prosecution
11 currently pending
Career history
217
Total Applications
across all art units

Statute-Specific Performance

§101
1.1%
-38.9% vs TC avg
§103
94.4%
+54.4% vs TC avg
§102
3.5%
-36.5% vs TC avg
§112
0.7%
-39.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 201 resolved cases

Office Action

§101 §102 §103
DETAILED ACTION This non-final office action is responsive to application 18/339,539 as submitted 22 June 2023. Claim status is currently pending and under examination for claims 1-20 of which independent claims are 1, 11 and 15. 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 . Information Disclosure Statement As required by MPEP 609(c), the applicant’s submissions of the Information Disclosure Statement dated 06/22/2023 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending. As required by MPEP 609 C(2), a copy of the PTOL-1449 initialed and dated by the examiner is attached to the instant office action. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claim 3 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. In determining whether the claims are subject matter eligible, the examiner applies guidance set forth under MPEP 2106. Claim 3 depends from claims which do not recite an abstract idea. However, Claim 3 further introduces a “determining” limitation which can be a mental determination as the abstract idea. Under Step 1, claim 3 is drawn to a method which is a process being one of the enumerated statutory categories under MPEP 2106.03. Thus, the analysis should proceed. Under Step 2A, prong one: abstract idea is recited under the broadest reasonable interpretation. Particularly, the claim recites the following limitation which can be a mental process which falls under MPEP 2106.04(a)(2): “determining if a confidence measure in the output of the generated network request exceeds a predetermined threshold” Mental Process, evaluation or judgment The above identified limitation is shown Fig 6 as a decision block and specification describes a human operator [0002] or end user [0040]. Such human is not precluded from performing the determining which could be judgment or evaluation by ad-hoc rule for observations. Therefore, the claim is found to recite at least a mental process as the abstract idea. Under Step 2A, prong two: additional elements do not integrate the judicial exception into a practical application. Particularly, additional elements comprise computer-implementation and the claim dependency. Computer-implementation with processor is recited at a high level of generality and falls under MPEP 2106.05(f) as mere use of a computer as a tool to perform the abstract idea. The dependency limitations of claim 1 comprise receiving and sending which fall under MPEP 2106.05(g) adding an insignificant extra-solution activity to the judicial exception, and further limitation generating is considered generally linking the use of the judicial exception to a particular technological environment under MPEP 2106.05(h) which also applies to the dependency limitations of claim 2. For example, the machine learning model broadly encompasses known models that could be applied off-the-shelf, and the bot fails to pinpoint RPA robotic process automation. Taken as a whole, the earlier claims provide drafting effort to monopolize the judicial exception and presents a substantial risk of pre-emption. Accordingly, the additional elements do not integrate the abstract idea into a practical application. Under Step 2B: additional elements do not amount to significantly more. As already discussed, the additional elements are identified with respect to MPEP 2106.05 and do not further demonstrate inventive concept. Particularly, the computer-implementation with processor does not qualify as a particular machine under MPEP 2106.05(b). The specification attempts to suggest acceleration but fails to describe a GPU/TPU or dedicated machine learning hardware, nor is there any benchmarking of time or measurable rates such as flops. Regarding the claim limitations of receiving and sending as insignificant extra-solution activities, these functionalities have been recognized by the courts as being well-understood, routine and conventional (WURC) activities under MPEP 2106.05(d)(II)(i). Further, the limitation of generating as generally linking judicial exception to a particular technological environment or field of use does not meaningfully limit the claim because it lacks particularity of technical solution where machine learning model is unspecified as are the bot variables. If the claim language provides only a result-oriented solution, with insufficient detail for how a computer accomplishes it, then the claims do contain an inventive concept. Taken alone, their additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Their collective functions merely provide conventional computer implementation. In view of the foregoing, claim 3 is not patent eligible. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1-2, 7, 9-12, 15, 17-18 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by: Vlad et al., US PG Pub No: 2024/0256370A1 hereinafter Vlad (UiPath). With respect to claim 1, Vlad teaches: A computer-implemented method {Vlad discloses [0023] “methods described herein” via “computer systems” Figs 13 or 1}, comprising: receiving, by a processor, plural runtime variables of a bot executing client-side web application code {Vlad discloses [0096-7] “runtime parameters, such as defining RPA processes and jobs, scheduling execution of various RPA workflows, managing robot… receive from the user a set of call parameter values” where RPA is ro(bot)ic process automation shown Fig 3 with client-side web browser 16, arrows indicate receiving dataflow, e.g. Figs 7:714 or 11:1110. Application code comprises json, xml and/or scripts disclosed [0052,60]. Processor shown Fig 13:82, described [0100] CPU/GPU}; generating, by the processor, a network request from a machine learning model given input of the plural runtime variables of the bot {Vlad [0079] “(HTTP) request… POST requests are used” shown Figs 6:61 and/or 5:60a as part of RPA workflow 56a, further Figs 3:46 and 1:36 show AI/ML integration described [0071] “robots 22 may call AI/ML models 36 by interfacing with AI/ML server 46” call/request thus communicatively couples ML models 36 with robots 22 that configure runtime parameters [0096] and “automatically generate an API specification” [0091]. The process may repeat [0049], [0097]}; and sending, by the processor, the network request generated from the machine learning model to the bot {Vlad [0079] “POST requests are used for sending” such that [0062] “RPA robots 22 may send input for execution of the AI/ML models” establishes communication between RPA robot and ML model shown Figs 3 and 1. Sending comprises e.g. [0091] “transmitting API specification” Fig 12:1214 and/or [0036-39] “exported to the automation hub to speed up implementation” speedup is acceleration}. With respect to claim 2, Vlad teaches the computer-implemented method of claim 1, further comprising inputting the plural runtime variables of the bot into the machine learning model; and receiving output of the generated network request from the machine learning model {Vlad [0062] “RPA robots 22 may send input for execution of the AI/ML model(s) and receive output therefrom” similar at [0071,45]. The RPA robot workflow comprising runtime parameters [0096] and received via network requests [0079], Figs 3 and 1}. With respect to claim 7, Vlad teaches the computer-implemented method of claim 1, wherein at least one of the plural runtime variables of the bot comprises a parameter of a robotic process automation command {Vlad [0096] “runtime parameter such as defining RPA processes and jobs, scheduling execution of various RPA workflows, managing robot fleets” e.g. [0057] “activities of attended robots 122 are triggered by user events and/or commands” Figs 12:1210, 3:26, 2}. With respect to claim 9, Vlad teaches the computer-implemented method of claim 1, further comprising receiving a request for generation of the network request from the bot executing client-side web application code {Vlad [0079] “(HTTP) request” via client-side web browser illustrated Fig 3:16 where bidirectional arrows indicate receiving at RPA conductor in communication with RPA robot 22, [0103] “API call (e.g., HTTP request) issued to an RPA conductor orchestrating a fleet of RPA robots)” Application code comprises json, xml and/or scripts disclosed [0052,60]. See also [0065-69]}. With respect to claim 10, Vlad teaches the computer-implemented method of claim 1, further comprising storing the association of the plural runtime variables of the bot and the network request in persistent storage {Vlad Fig 3 Persistence layer with database so as to [0069-70] “selectively store and/or retrieve data to/from RPA databases… data stored/retrieved by server 45 may include configuration parameters” e.g. [0089-90] “call parameters may be encoded for instance as metadata” Figs 5:60a, 6:61 post-http network request [0079] url-encoded pairs of concatenated strings based on arguments that can be considered associations/affiliations subject to logging Fig 3 [0067,69]. See also [0095] associations maintained with ledger}. With respect to claim 11, Vlad teaches: A computer program product comprising one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media {Vlad discloses [0023] “computer program…software” with “Computer-readable media encompasses non-transitory media… computer readable media encoding instructions to perform the methods herein” similar at [0008] and shown Figs 8-9 UiPath software screenshots}, the program instructions executable to: receive runtime variables from executions of at least one bot executing client-side web application code {Vlad [0096-97] “runtime parameters, such as defining RPA processes and jobs, scheduling execution of various RPA workflows, managing robot… receive from the user a set of call parameter values” where RPA is ro(bot)ic process automation shown Fig 3 with client-side web browser 16, arrows indicate receiving dataflow, e.g. Figs 7:714 or 11:1110. Application code comprises json, xml and/or scripts disclosed [0052,60]}; receive network requests from the executions of the at least one bot executing client-side web application code {Vlad [0079] “(HTTP) request” via client-side web browser illustrated Fig 3:16 where bidirectional arrows indicate receiving at RPA conductor in communication with RPA robot 22, [0103] “API call (e.g., HTTP request) issued to an RPA conductor orchestrating a fleet of RPA robots)” Application code comprises json, xml and/or scripts disclosed [0052,60]. See also [0065-69]}; store plural associations of the runtime variables and the network requests {Vlad [0069-70] “selectively store and/or retrieve data to/from RPA databases… data stored/retrieved by server 45 may include configuration parameters” e.g. [0089-90] “call parameters may be encoded for instance as metadata” Figs 5:60a, 6:61 post-http network request [0079] url-encoded pairs of concatenated strings based on arguments that can be considered associations/affiliations subject to logging Fig 3 [0067,69]. See also [0095] associations maintained with ledger}; and train a machine learning model with the plural associations of the runtime variables and the network requests to generate a network request given input of runtime variables from an executing bot {Vlad [0045] “training jobs to train the new versions of AI/ML models” where “dynamic input may then be saved as training data for retraining AI/ML models” emphasis saved (i.e. stored) training data, training data may be labeled [0045,62], and [0037-38] “AI/ML models 36 may be employed to uncover recurring task patterns” recurrent pattern mining of tasks where tasks configure runtime parameters [0096] and network requests [0079], to [0091] “automatically generate an API specification for the respective workflow” Fig 3}. With respect to claim 12, Vlad teaches the computer program product of claim 11, and further teaches the limitation of claim 7. Therefore, the rejection of claim 7 is applied to claim 12. With respect to claim 15, Vlad teaches: A system {Vlad [0006] “computer system” Figs 1 and 13} comprising: a processor set, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media {Vlad [0100-1] “Fig. 13 shows an exemplary hardware configuration of a computer system” comprising CPU or GPU processors and computer-readable media or memory storing executable software instructions. Similar at Fig 1 [0025]}, the program instructions executable to: receive opt-in permission from a user of a client device {Vlad [0055] “user permissions” e.g. see Fig 6 “access-control-allow-credential: true” [0052-53] “credentials for accessing” and/or [0047] “interface may list automations/workflows approved for a given user” Fig 1:12 client devices}; request generation of a network request from runtime variables of a bot executing client-side web application code of a web application {Vlad [0103] “API call (e.g., HTTP request) issued to an RPA conductor orchestrating a fleet of RPA robots” comprising [0096] “runtime parameters” Fig 3 shows client-side web browser 16, Figs 5-6 detail the request. Application code comprises json, xml and/or scripts disclosed [0052,60]. Further [0091] “automatically generate an API specification… To generate the API specification, some embodiments rely on data included in RPA package 50, for instance workflow-specific API call parameter values (e.g., call method and call URl)”}; receive the network request generated from a machine learning model given input of the runtime variables of the bot {Vlad [0099] “call response 68 (Fig. 4) back to the sender of the respective API call” where [0071] “robots 22 may call AI/ML models” e.g. [0062] “RPA robots 22 may send input for execution of the AI/ML model(s) and receive output therefrom” similar at [0045], RPA robot workflow comprising runtime parameters [0096]}; and send the network request to the web application for processing {Vlad [0079] “(HTTP) request… POST requests are used for sending” shown Fig 3 arrows to/from web browser 16 [0065] and/or [0068] “web application”}. With respect to claim 17, Vlad teaches the system of claim 15, wherein the program instructions are further executable to identify the runtime variables of the bot {Vlad Fig 12:1206-10 “Identify RPA workflow” e.g. by Fig 11:06-110 selecting rpa workflow and indicating API call parameter values, described [0096] “runtime parameters”}. With respect to claim 18, Vlad teaches the system of claim 15, wherein the machine learning model is trained with plural associations of runtime variables and network requests to generate the network request given input of the runtime variables of the bot {Vlad [0045] “training jobs to train the new versions of AI/ML models” where “dynamic input may then be saved as training data for retraining AI/ML models” emphasis saved (i.e. stored) training data, training data may be labeled [0045,62], and [0037-38] “AI/ML models 36 may be employed to uncover recurring task patterns” recurrent pattern mining of tasks where tasks configure runtime parameters [0096] and network requests [0079], to [0091] “automatically generate an API specification for the respective workflow” Fig 3 }. With respect to claim 20, Vlad teaches the system of claim 15, wherein the program instructions are further executable to track plural network requests from client-side web application code sent to the web application {Vlad Fig 3 [0067] “Logging endpoints may be used to log different information, such as errors, explicit messages sent by robot 22, and other environment-specific information” shown as logging by conductor that handles interface with web browser with API endpoints in communication via requests Fig 6, [0079]. See also [0055] “keep track of robot state... Logging may include storing and indexing logs to a database”}. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 3-6, 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Vlad in view of Brons et al., US PG Pub No 2024/0403797A1 hereinafter Brons (UiPath). With respect to claim 3, Vlad teaches the computer-implemented method of claim 2. Brons teaches further comprising determining if a confidence measure in the output of the generated network request exceeds a predetermined threshold {Brons discloses [0123-24] “confidence score that meets or exceeds a confidence threshold… For instance, if the confidence threshold is 80%” similar at [0144], and where calls are requests [0047,49] or [0086,92]}. Brons is directed to RPA robots with ML models thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to employ confidence threshold per Brons in combination to arrive at the invention as claimed as applying a known technique to a known method ready for improvement to yield predictable results described typical or common per [0124] “neural networks are probabilistic constructs that typically have a confidence score… common types of confidence scores” and/or for further motivation “In order to reduce matches with unacceptably low likelihoods” [0123] such that evaluative testing does not lead to overfitting [0144]. With respect to claim 4, Vlad teaches the computer-implemented method of claim 1. Brons teaches wherein the machine learning model comprises a recurrent neural network trained with plural associations of runtime variables and network requests to a web application {Brons discloses [0121] “recurrent neural networks” among [0117] “types of AI/ML models may be trained” Fig 6 or 1:132. The runtime variables are series/sequence of vectorized input [0126,134] and network requests are calls [0047,49] or [0086,92], and web browser/application is disclosed [0064], [0092]}. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to use the recurrent network of Brons in combination to arrive at the invention as claimed as simple substation among known models types to obtain predictable results and/or to ensure the model does not over fit [0139,144]. With respect to claim 5, Vlad teaches the computer-implemented method of claim 1. Brons teaches wherein the machine learning model comprises a Long Short Term Memory (LSTM) neural network trained with plural associations of runtime variables and network requests to a web application {Brons [0050] “long short term memory (LSTM)” again at [0121] “long/short term memory networks” among [0117] “types of AI/ML models may be trained” Fig 6 or 1:132. The runtime variables are series/sequence of vectorized input [0126,134] and network requests are calls [0047,49] or [0086,92], and web browser/application is disclosed [0064], [0092]}. Motivation is applied equally as in claim 4. With respect to claim 6, Vlad teaches the computer-implemented method of claim 1. Brons teaches wherein the machine learning model comprises a Gated Recurrent Unit (GRU) neural network trained with plural associations of runtime variables and network requests to a web application {Brons [0121] “gated recurrent unit networks” among [0117] “types of AI/ML models may be trained” Fig 6 or 1:132. The runtime variables are series/sequence of vectorized input [0126,134] and network requests are calls [0047,49] or [0086,92], and web browser/application is disclosed [0064], [0092]}. Motivation is applied equally as in claim 4. With respect to claim 14, Vlad teaches the computer program product of claim 11, and further combination with Brons teaches the limitation of claims 4-6. Therefore, the rejection of claims 4-6 are applied to claim 14 with equal motivation. With respect to claim 19, Vlad teaches the system of claim 15 and further combination with Brons teaches the limitation of claim 4. Therefore, the rejection of claim 4 is applied to claim 19 with equal motivation. Claims 8 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Vlad in view of Mani et al., US PG Pub No 2023/0023382A1 hereinafter Mani. With respect to claim 8, Vlad teaches the computer-implemented method of claim 1. Mani teaches wherein the network request comprises a hypertext transfer protocol request with payload data of a selection of a user interface control in the client-side web application code {Mani discloses [0052] “request comprising the type of call method (e.g., an HTTP request method, such as POST), a payload” i.e. [0060] “request along with the payload in a call” shown e.g. Figs 9:928,918, 8:820 with [0050] “selectable user interface elements… software bot” similar at [0041-42] and browser [0022]}. Mani is directed to RPA robotic process automation with network requests thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to specify payload per Mani in combination with Vlad to arrive at the invention as claimed for a motivation of “improved user interface that enables the user to effectively and efficiently configure a software bot to dynamically conform API requests” [0019] by [0017] “converting the data of the objects into the payload of the request in a format required by the API” thereby “enables multiple different APIs to be called and used in various scenarios without a user having to rewrite the software program of the bot. The computer system may provide a data file having a predefined template in which the user may simply enter some basic data of an API, metadata of objects to the included in a payload of a request to be transmitted to the API.” With respect to claim 13, Vlad teaches the computer program product of claim 11, and further combination with Mani teaches the limitation of claim 8. Therefore, the rejection of claim 8 is applied to claim 13 with equal motivation. Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Vlad in view of Grigore et al., US PG Pub No 2023/0191601A1 hereinafter Grigore (UiPath). With respect to claim 16, Vlad teaches the system of claim 15. Grigore teaches wherein the sending the network request comprises bypassing execution of a robotic process automation command {Grigore Fig 10:1050 at [0114] “RPA robot skips the activity at 1050. This is repeated for each activity until the end of the workflow is reached” skipping is bypassing, e.g. [0028-30] “RPA robot only executes activities that are tagged for the current target platform at runtime… speedy execution” further discloses API calls corresponding to requests}. Grigore is directed to RPA robotic process automation with web browser thus being analogous. A person having ordinary skill in the art would have considered it obvious prior to the effective filing date to perform skipping per Grigore in combination to arrive at the invention as claimed for a motivation “to facilitate speedy execution” [0030] so as for the benefit of “saving developer time… reduce development time” [0109,112]. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Chase P Hinckley whose telephone number is (571)272-7935. The examiner can normally be reached M-F 9:00 - 5:00. 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, Miranda M. Huang can be reached at 571-270-7092. 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. /CHASE P. HINCKLEY/Examiner, Art Unit 2124
Read full office action

Prosecution Timeline

Jun 22, 2023
Application Filed
Apr 02, 2026
Non-Final Rejection mailed — §101, §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12639499
INFORMATION PROCESSING SYSTEM, COMPUTER SYSTEM, INFORMATION PROCESSING METHOD, AND PROGRAM
4y 8m to grant Granted May 26, 2026
Patent 12639122
PROCESSING COMPUTATIONAL GRAPHS
2y 9m to grant Granted May 26, 2026
Patent 12614081
FRACTAL COGNITIVE COMPUTING NODE, COMPUTER-IMPLEMENTED METHOD FOR LEARNING PROCEDURES, COMPUTATIONAL COGNITION CLUSTER AND COMPUTATIONAL COGNITION ARCHITECTURE
4y 9m to grant Granted Apr 28, 2026
Patent 12608444
AUTOMATED SELECTION OF PRINCIPAL COMPONENT ANALYSIS VARIANTS FOR LARGE-SCALE DATAASETS
3y 8m to grant Granted Apr 21, 2026
Patent 12608585
NEURAL NETWORKS FOR SELECTING ACTIONS TO BE PERFORMED BY A ROBOTIC AGENT
3y 9m to grant Granted Apr 21, 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
78%
With Interview (+10.1%)
3y 11m (~11m remaining)
Median Time to Grant
Low
PTA Risk
Based on 201 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