Prosecution Insights
Last updated: October 04, 2026
Application No. 18/898,515

ARTIFICIAL INTELLIGENCE SERVICE(S) IN A DISTRIBUTED CLOUD COMPUTING NETWORK

Non-Final OA §103§112
Filed
Sep 26, 2024
Priority
Sep 26, 2023 — provisional 63/585,593
Examiner
TAYLOR, JOSHUA D
Art Unit
2441
Tech Center
2400 — Computer Networks
Assignee
Cloudflare Inc.
OA Round
1 (Non-Final)
59%
Grant Probability
Moderate
1-2
OA Rounds
1y 8m
Est. Remaining
90%
With Interview

Examiner Intelligence

Grants 59% of resolved cases
59%
Career Allowance Rate
321 granted / 542 resolved
+1.2% vs TC avg
Strong +31% interview lift
Without
With
+30.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 8m
Avg Prosecution
15 currently pending
Career history
567
Total Applications
across all art units

Statute-Specific Performance

§101
6.0%
-34.0% vs TC avg
§103
57.1%
+17.1% vs TC avg
§102
12.7%
-27.3% vs TC avg
§112
18.9%
-21.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 542 resolved cases

Office Action

§103 §112
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 . DETAILED ACTION This Office Action is in response to CLAIMS entered for patent application 18/898,515 filed on September 26, 2024. Claims 1-24 are pending. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 8, 16 and 24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claims 8, 16 and 24 recite the limitations “the other plurality of code pieces” and “the other plurality of isolated execution environments” in lines 3-4, 4-5, and 3-4, respectively. As there is no previous mention of these terms, there is insufficient antecedent basis for these limitations in the claims. Appropriate correction or explanation is required. 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. Claims 1-3, 5, 6, 9-11, 13, 14, 17-19, 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Finnie et al. (Pub. No.: US 2022/0358375) in view of Royal et al. (Pat. No.: US 11,394,710) and Ehrat et al. (Pub. No.: US 2020/0366592). Regarding claims 1, 9 and 17, Finnie discloses a method, a non-transitory machine-readable storage medium, and a first compute server for providing artificial intelligence (AI) service, comprising: receiving a first inference request (para. [0060]; “In step 401, a new model inference request is received. The inference request may include a model input of the machine learning model.” para. [0059]; “FIG. 4 depicts flowchart 400, a method for inference of a machine learning model;” para. [0039]; “Machine learning service 104 may be hosted by a separate machine that is remotely connected to client 101 of computer system 100;” para. [0040]; “Machine learning service 104 may comprise any number of trained machine learning model.”); determining that the received first inference request triggers execution of first code (Fig. 1, element 107, paras. [0040]-[0043]), wherein the first code is related to an AI application that interacts with the first inference request and causes input of the first inference request to be run through a first AI model (Fig. 1, element 111-N, paras. [0040]-[0042]; the limitation of “AI” is met because a machine learning model is a type of AI model (see also [0002])); determining that the first AI model is not loaded at the first compute server (Fig. 4, paras. [0059]-[0062]); receiving a first result of the first inference operation; and providing the first result to the first code (Fig. 2, paras. [0046]-[0052]). It could be argued that Finnie does not explicitly disclose that the service is provided in a distributed cloud computing network, nor wherein the first request is received at a first compute server of a plurality of compute servers of the distributed cloud computing network that includes a plurality of datacenters, and thus does not disclose wherein the first compute server is part of a first one of the plurality of datacenters, nor execution of first code occurring at the distributed cloud computing network, and thus does not disclose determining that the first AI model is loaded at a second compute server of the first datacenter. However, in analogous art, Royal discloses that “[t]he identity proxy and access gateway 110 may be executed on a compute server of a distributed cloud computing network. The distributed cloud computing network includes multiple geographically distributed nodes. Each node may include one or more compute servers, one or more control servers, one or more DNS servers, and one or more other pieces of networking equipment (e.g., routers, switches, hubs, etc.). The node may be part of the same physical device or multiple physical devices. For example, the compute server(s), control server(s), and DNS server(s) may be virtual instances running on the same physical device or may be separate physical devices. Each node may be part of a data center or a collocation site. The nodes may be geographically distributed that decreases the distance between requesting client devices and content. Thus, there may be multiple servers providing the functionality of the identity proxy and access gateway 110 (col. 5, ln. 24-41),” wherein “[t]he identity proxy and access gateway 110 executes on one or more servers. The identity proxy and access gateway 110 may be provided by a cloud computing network. The cloud computing network includes multiple data centers that each include multiple servers respectively. Each of these servers and/or data centers may execute an instance of the identity proxy and access gateway 110 (col. 3, ln. 38-44).” 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 Finnie to allow for the service to be provided in a distributed cloud computing network, wherein the first request is received at a first compute server of a plurality of compute servers of the distributed cloud computing network that includes a plurality of datacenters, wherein the first compute server is part of a first one of the plurality of datacenters, execution of first code occurs at the distributed cloud computing network, and determining that the first AI model is loaded at a second compute server of the first datacenter. This would have produced predictable and desirable results, in that it would allow for a simple substitution of one known element for another to obtain predictable results. In accordance with MPEP § 2143(I)(B), the prior art method of Finnie differed from the claimed method the substitution of the system performing the method (i.e., the client 101 in Finnie) with other components (namely, a distributed cloud computing network and its compute servers which include a first compute server), and one of ordinary skill in the art could have substituted one known element for another and the results of the substitution would have been predictable (specifically, the predictable result of merely using a different generic computer system for performing a computing task). It could further be argued that the combination of Finnie and Royal does not explicitly disclose routing the first inference request to the second compute server of the first datacenter for performing a first inference operation on input of the first inference request using the first AI model at the second compute server; nor receiving, from the second compute server, a first result of the first inference operation. However, in analogous art, Ehrat discloses that “The optimized routing module 320A is configured to intelligently route at least certain requests towards their destination (para. [0040]),” wherein “[n]ext, at operation 525, the compute node 220A transmits the request to a next hop over the identified transit connection as defined by the optimized route. If the next hop is another data center 120, the compute node 220A may transmit the request to another compute node in a different data center using a layer-4 point-to-point link that is a mutually authenticated TLS connection (para. [0053]).” 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 Finnie and Royal to allow routing the first inference request to the second compute server of the first datacenter for performing a first inference operation on input of the first inference request using the first AI model at the second compute server, and receiving, from the second compute server, a first result of the first inference operation. This would have produced predictable and desirable results, in that it would enable “intelligently routing internet traffic through multiple compute nodes of a distributed network (Ehrat, para. [0011]).” Regarding claim 2, the combination of Finnie, Royal and Ehrat discloses the method of claim 1, and further discloses wherein the first AI model is dynamically determined at the first compute server based on a context of the first inference request (Finnie, Fig. 2, paras. [0046]-[0052]). Regarding claim 3, the combination of Finnie, Royal and Ehrat discloses the method of claim 1, and further discloses further comprising: receiving, at the first compute server, a second inference request (Finnie, para. [0025]); determining that the received second inference request triggers execution of second code at the distributed cloud computing network, wherein the second code is related to a second AI application that interacts with the inference request and causes input of the second inference request to be run through a second AI model (Fig. 1, elements 111-1 to 111-N, paras. [0040]-[0042]); determining that the second AI model is not loaded at the first compute server but is loaded at a third compute server of a second datacenter (Royal, col. 3, ln. 38-44, col. 5, ln. 24-41); routing the inference request to the third compute server of the second datacenter for performing a second inference operation on input of the second inference request using the second AI model at the third compute server (Ehrat, paras. [0040]-[0053]); receiving, from the third compute server, a second result of the second inference operation; and providing the second result to the second code (Finnie, Fig. 2, paras. [0046]-[0052]. This claim is rejected on the same grounds as claim 1.). Regarding claim 5, the combination of Finnie, Royal and Ehrat discloses the method of claim 1, and further discloses wherein the first AI model is a custom model provided by a developer of the AI application (Finnie, paras. [0003]-[0006]). Regarding claim 6, the combination of Finnie, Royal and Ehrat discloses the method of claim 1, and further discloses wherein the first AI model is provided by a provider of the distributed cloud computing network (Finnie, Fig. 1, paras. [0039]-[0045]; Royal, col. 3, ln. 38-44, col. 5, ln. 24-41. This claim is rejected on the same grounds as claim 1.). Regarding claim 10, the combination of Finnie, Royal and Ehrat discloses the non-transitory machine-readable storage medium of claim 9, and further discloses wherein the first AI model is dynamically determined at the first compute server based on a context of the first inference request (Finnie, Fig. 2, paras. [0046]-[0052]). Regarding claim 11, the combination of Finnie, Royal and Ehrat discloses the non-transitory machine-readable storage medium of claim 9, and further discloses wherein the operations further comprise: receiving, at the first compute server, a second inference request (Finnie, para. [0025]); determining that the received second inference request triggers execution of second code at the distributed cloud computing network, wherein the second code is related to a second AI application that interacts with the inference request and causes input of the second inference request to be run through a second AI model (Fig. 1, elements 111-1 to 111-N, paras. [0040]-[0042]); determining that the second AI model is not loaded at the first compute server but is loaded at a third compute server of a second datacenter (Royal, col. 3, ln. 38-44, col. 5, ln. 24-41); routing the inference request to the third compute server of the second datacenter for performing a second inference operation on input of the second inference request using the second AI model at the third compute server (Ehrat, paras. [0040]-[0053]); receiving, from the third compute server, a second result of the second inference operation; and providing the second result to the second code (Finnie, Fig. 2, paras. [0046]-[0052]. This claim is rejected on the same grounds as claim 1.). Regarding claim 13, the combination of Finnie, Royal and Ehrat discloses the non-transitory machine-readable storage medium of claim 9, and further discloses wherein the first AI model is a custom model provided by a developer of the AI application (Finnie, paras. [0003]-[0006]). Regarding claim 14, the combination of Finnie, Royal and Ehrat discloses the non-transitory machine-readable storage medium of claim 9, and further discloses wherein the first AI model is provided by a provider of the distributed cloud computing network (Finnie, Fig. 1, paras. [0039]-[0045]; Royal, col. 3, ln. 38-44, col. 5, ln. 24-41. This claim is rejected on the same grounds as claim 1.). Regarding claim 18, the combination of Finnie, Royal and Ehrat discloses the first compute server of claim 17, and further discloses wherein the first AI model is dynamically determined at the first compute server based on a context of the first inference request (Finnie, Fig. 2, paras. [0046]-[0052]). Regarding claim 19, the combination of Finnie, Royal and Ehrat discloses the first compute server of claim 17, and further discloses wherein the operations further comprise: receiving, at the first compute server, a second inference request (Finnie, para. [0025]); determining that the received second inference request triggers execution of second code at the distributed cloud computing network, wherein the second code is related to a second AI application that interacts with the inference request and causes input of the second inference request to be run through a second AI model (Fig. 1, elements 111-1 to 111-N, paras. [0040]-[0042]); determining that the second AI model is not loaded at the first compute server but is loaded at a third compute server of a second datacenter (Royal, col. 3, ln. 38-44, col. 5, ln. 24-41); routing the inference request to the third compute server of the second datacenter for performing a second inference operation on input of the second inference request using the second AI model at the third compute server (Ehrat, paras. [0040]-[0053]); receiving, from the third compute server, a second result of the second inference operation; and providing the second result to the second code (Finnie, Fig. 2, paras. [0046]-[0052]. This claim is rejected on the same grounds as claim 1.). Regarding claim 21, the combination of Finnie, Royal and Ehrat discloses the first compute server of claim 17, and further discloses wherein the first AI model is a custom model provided by a developer of the AI application (Finnie, paras. [0003]-[0006]). Regarding claim 22, the combination of Finnie, Royal and Ehrat discloses the first compute server of claim 17, and further discloses wherein the first AI model is provided by a provider of the distributed cloud computing network (Finnie, Fig. 1, paras. [0039]-[0045]; Royal, col. 3, ln. 38-44, col. 5, ln. 24-41. This claim is rejected on the same grounds as claim 1.). Claims 4, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Finnie et al. (Pub. No.: US 2022/0358375) in view of Royal et al. (Pat. No.: US 11,394,710) Ehrat et al. (Pub. No.: US 2020/0366592) and Jeyapaul et al. (Pub. No.: US 2023/0104246). Regarding claim 4, the combination of Finnie, Royal and Ehrat discloses the method of claim 1, and further discloses further comprising: receiving, at the first compute server, a second inference request (Finnie, para. [0025]); determining that the received second inference request triggers execution of second code at the distributed cloud computing network, wherein the second code is related to a second AI application that interacts with the inference request and causes input of the second inference request to be run through a second AI model (Finnie, Fig. 1, elements 111-1 to 111-N, paras. [0040]-[0042]); receiving, at the first compute server, a third inference request (Finnie, para. [0025]); determining that the received third inference request triggers execution of second code at the distributed cloud computing network, wherein the second code is related to a second AI application that interacts with the inference request and causes input of the second inference request to be run through a second AI model (Fig. 1, elements 111-1 to 111-N, paras. [0040]-[0042]); determining that the second AI model is fetched and loaded at the first compute server (Fig. 4, elements 409 and 410, paras. [0059]-[0062]); and performing a third inference operation on input of the third inference request using the second AI model (Fig. 4, elements 409 and 410, paras. [0059]-[0062]). However, the combination does not disclose determining that the second AI model is not loaded at the first compute server but a quantized model of the second AI model is loaded at the first compute server; loading the second AI model at the first compute server including fetching the second AI model from a model repository; performing a second inference operation on input of the second inference request using the quantized model; providing a second result of the second inference operation to the second code. However, in analogous art, Jeyapaul discloses “a diagram illustrating an example of a deep neural network model energy rating system is depicted in accordance with an illustrative embodiment. Deep neural network (DNN) model energy rating system 300 may be implemented in a network of data processing systems, such as network data processing system 100 in FIG. 1. DNN model energy rating system 300 is a system of hardware and software components for energy rating deep neural network models. In this example, DNN model energy rating system 300 includes DNN model computing environment 302 and energy-rated DNN model repository 304. DNN model computing environment 302 is comprised of central processing unit (CPU) and graphics processing unit (GPU) cores 306, hardware (HW) accelerators 308, power supply unit 310, DNN model profile 312, and DNN model energy rater 314. It should be noted that DNN model profile 312 may represent a plurality of different DNN model profiles corresponding to a plurality of different deep neural network models. DNN model profile 312 contains information, such as, for example, architecture type, dataset, weights, network layers, and the like, corresponding to a particular deep neural network model, such as DNN model 316. DNN model energy rater 314 may be a component of an orchestrator, such as, for example, edge inference computing environment orchestrator 218 in FIG. 2. DNN model energy rater 314 computes FLOPS/Watt based on energy consumption of CPU and GPU cores 306, HW accelerators 308, and power supply unit 310. DNN model energy rater 314 converts the FLOPS/Watt to energy rating 318 for DNN model 316 based on existing benchmark values of existing energy efficient deep neural network models. Please see the example of FLOPS/Watt benchmarking table 400 in FIG. 4. DNN model energy rater 314 updates DNN model profile 312 corresponding to DNN model 316 to include energy rating 318. At 320, DNN model energy rater 314 determines whether DNN model 316 is quantized (e.g., software optimized) after training. If DNN model energy rater 314 determines that DNN model 316 is not quantized post training, then DNN model energy rater 314 stores DNN model profile 312 corresponding to DNN model 316, which includes energy rating 318, in energy-rated DNN model repository 304. If DNN model energy rater 314 determines that DNN model 316 is quantized post training, then, at 322, DNN model energy rater 314 increases energy rating 318 of DNN model 316 to an overall energy efficiency rating (OEER) based on the quantization. At 324, DNN model energy rater 314 updates DNN model profile 312 corresponding to DNN model 316 to include OEER 326 and stores DNN model profile 312, which includes OEER 326, in energy-rated DNN model repository 304 (paras. [0066]-[0069]; Fig. 3).” 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 Finnie, Royal and Ehrat to allow for determining that the second AI model is not loaded at the first compute server but a quantized model of the second AI model is loaded at the first compute server; loading the second AI model at the first compute server including fetching the second AI model from a model repository; performing a second inference operation on input of the second inference request using the quantized model, and providing a second result of the second inference operation to the second code. This would have produced predictable and desirable results, in that it would allow the system to be “capable of providing visibility of energy efficiency of deep neural network models using corresponding energy ratings (Jeyapaul, para. [0063]).” Claims 12 and 20 are rejected using the same rationale as claim 4. Claims 7, 15 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Finnie et al. (Pub. No.: US 2022/0358375) in view of Royal et al. (Pat. No.: US 11,394,710) Ehrat et al. (Pub. No.: US 2020/0366592) and Lahner et al. (Pub. No.: US 2007/0083839). Regarding claim 7, the combination of Finnie, Royal and Ehrat discloses the method of claim 1, but it could be argued that the combination does not explicitly disclose wherein the code is third-party code that is written or deployed by a customer of the distributed cloud computing network. However, in analogous art, Lahner discloses that “[t]he RTL instructor tool 104 may be operational to characterize existing code before significant investments in time, money and/or people are made. The existing RTL code to be integrated may be read and characterized to determine if the existing RTL code meets the defined goals. The characterization analysis may be completed (i) before the existing code is synthesized and (ii) before any layout tasks start. Someone who wants to purchase third-party code IP may request to have the RTL instructor tool 104 characterize the code before being licensed or purchased. Where the existing code is legacy code from within a company, the RTL instruction library 114 may be filled with RTL implementations for the same functionality. For example, one or more core circuit designs with the same functionality as the circuit being written may be available to meet the highest performance goals or the DFT goals. If the legacy code has to be implemented and changed, the RTL instructor tool 104 may guide the designer to make changes that may be difficult to make manually (para. [0069]).” 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 Finnie, Royal and Ehrat to allow for the code to be third-party code that is written or deployed by a customer of the distributed cloud computing network. This would have produced predictable and desirable results, in that it would allow for a well-known process of acquiring code to be used. Regarding claim 15, the combination of Finnie, Royal and Ehrat discloses the non-transitory machine-readable storage medium of claim 9, but it could be argued that the combination does not explicitly disclose wherein the code is third-party code that is written or deployed by a customer of the distributed cloud computing network. However, in analogous art, Lahner discloses that “[t]he RTL instructor tool 104 may be operational to characterize existing code before significant investments in time, money and/or people are made. The existing RTL code to be integrated may be read and characterized to determine if the existing RTL code meets the defined goals. The characterization analysis may be completed (i) before the existing code is synthesized and (ii) before any layout tasks start. Someone who wants to purchase third-party code IP may request to have the RTL instructor tool 104 characterize the code before being licensed or purchased. Where the existing code is legacy code from within a company, the RTL instruction library 114 may be filled with RTL implementations for the same functionality. For example, one or more core circuit designs with the same functionality as the circuit being written may be available to meet the highest performance goals or the DFT goals. If the legacy code has to be implemented and changed, the RTL instructor tool 104 may guide the designer to make changes that may be difficult to make manually (para. [0069]).” 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 Finnie, Royal and Ehrat to allow for the code to be third-party code that is written or deployed by a customer of the distributed cloud computing network. This would have produced predictable and desirable results, in that it would allow for a well-known process of acquiring code to be used. Regarding claim 23, the combination of Finnie, Royal and Ehrat discloses the first compute server of claim 17, but it could be argued that the combination does not explicitly disclose wherein the code is third-party code that is written or deployed by a customer of the distributed cloud computing network. However, in analogous art, Lahner discloses that “[t]he RTL instructor tool 104 may be operational to characterize existing code before significant investments in time, money and/or people are made. The existing RTL code to be integrated may be read and characterized to determine if the existing RTL code meets the defined goals. The characterization analysis may be completed (i) before the existing code is synthesized and (ii) before any layout tasks start. Someone who wants to purchase third-party code IP may request to have the RTL instructor tool 104 characterize the code before being licensed or purchased. Where the existing code is legacy code from within a company, the RTL instruction library 114 may be filled with RTL implementations for the same functionality. For example, one or more core circuit designs with the same functionality as the circuit being written may be available to meet the highest performance goals or the DFT goals. If the legacy code has to be implemented and changed, the RTL instructor tool 104 may guide the designer to make changes that may be difficult to make manually (para. [0069]).” 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 Finnie, Royal and Ehrat to allow for the code to be third-party code that is written or deployed by a customer of the distributed cloud computing network. This would have produced predictable and desirable results, in that it would allow for a well-known process of acquiring code to be used. Conclusion Claims 1-24 are rejected. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joshua D Taylor whose telephone number is (571)270-3755. The examiner can normally be reached Monday - Friday 8 am - 6 pm. 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, Nasser Goodarzi can be reached at 571-272-4195. 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. /Joshua D Taylor/Primary Examiner, Art Unit 2426 August 20, 2026
Read full office action

Prosecution Timeline

Sep 26, 2024
Application Filed
Aug 25, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12744947
Systems, Methods, And Apparatuses For Improved Content Recording And Playback
4y 4m to grant Granted Sep 22, 2026
Patent 12744945
METHOD AND APPARATUS FOR DETERMINING CLICK-FARMING IN LIVE ROOM
2y 3m to grant Granted Sep 22, 2026
Patent 12720158
WIRELESS DEVICE
2y 8m to grant Granted Aug 25, 2026
Patent 12719956
APPLICATION SPECIFIC PROTOCOL DATA UNIT SESSIONS
2y 4m to grant Granted Aug 25, 2026
Patent 12707124
HEALTH AWARE MEDIA NAVIGATION AND CONSUMPTION
3y 2m to grant Granted Aug 11, 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
59%
Grant Probability
90%
With Interview (+30.8%)
3y 8m (~1y 8m remaining)
Median Time to Grant
Low
PTA Risk
Based on 542 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