Prosecution Insights
Last updated: April 19, 2026
Application No. 18/884,021

SERVICE DISCOVERY AND RENAMING

Non-Final OA §103§DP
Filed
Sep 12, 2024
Examiner
MIAN, MOHAMMAD YOU A
Art Unit
2457
Tech Center
2400 — Computer Networks
Assignee
Amazon Technologies, Inc.
OA Round
1 (Non-Final)
66%
Grant Probability
Favorable
1-2
OA Rounds
3y 3m
To Grant
98%
With Interview

Examiner Intelligence

Grants 66% — above average
66%
Career Allow Rate
179 granted / 273 resolved
+7.6% vs TC avg
Strong +33% interview lift
Without
With
+32.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
23 currently pending
Career history
296
Total Applications
across all art units

Statute-Specific Performance

§101
6.0%
-34.0% vs TC avg
§103
57.8%
+17.8% vs TC avg
§102
9.9%
-30.1% vs TC avg
§112
16.0%
-24.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 273 resolved cases

Office Action

§103 §DP
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 The preliminary amendment filed 09/24/2024 has been entered. Claims 1-20 have been canceled. Claims 21-40 have been added. Claims 21-40 are pending and are examined herein. Claim Objections Claim 35 is objected to because of the following informalities: Claim 35 recite “…executed on or across one or more processors…”, it is suggested to recite as “…executed by one or more processors…”. Appropriate correction is required. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 21-40 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 6-8 and 14-16 of U.S. Patent 11425085. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope, and they achieve the same overall result. Accordingly, the claim limitations of the present application represent obvious variation of those in the reference US Patent 11425085. The table below shows comparison between the instant application and the reference US Patent claims. 18/884,021 (instant application) Ref. Patent US 11425085 Claim 21. A system, comprising: one or more computing devices of a provider network comprising respective processors and memory to implement: subsequent to addition, by a domain name service, of a new entry for a new name of a service, retrieve data from query logs generated by the domain name service, wherein the query logs comprise query logs that indicate an old name of the service as a queried name; analyze the retrieved data; identify, based on the analysis of the retrieved data, clients of the service that are continuing to use the old name of the service; and send, to the identified clients of the service that are continuing to use the old name of the service, a name change notification for the service. Claim 1. A system, comprising: one or more computing devices of a provider network comprising respective processors and memory to implement: …subsequent to addition, by the domain name service, of the new entry for the other name of the service, retrieve data from one or more of the query logs, wherein the one or more query logs respectively indicate the name of the service as the queried name and an originating client network address of a client of the service that used the queried name; analyze the retrieved data; identify, based on the analysis of the retrieved data that includes the originating client network address of clients of the service that used the queried name, a plurality of different clients of the service that have continued to use the name of the service after the addition of the new entry for the other name of the service; and in response to the identification of the plurality of different clients of the service that have continued to use the name of the service after the addition of the new entry for the other name of the service, send to an endpoint an indication of the plurality of different clients of the service that have continued to use the name of the service after the addition of the new entry for the other name of the service. Claim 22. The system as recited in claim 21, wherein to identify clients of the service that are continuing to use the old name of the service, the one or more computing devices further implement: identify the clients based on an originating client network address of the query logs that include the old name of the service. Claim 1. …identify, based on the analysis of the retrieved data that includes the originating client network address of clients of the service that used the queried name, a plurality of different clients of the service that have continued to use the name of the service after the addition of the new entry for the other name of the service; Claim 23. The system as recited in claim 21, wherein the one or more computing devices further implement: send, to an endpoint, data that indicates the clients that are continuing to use the old name of the service. Claim 1. …send to an endpoint an indication of the plurality of different clients of the service that have continued to use the name of the service after the addition of the new entry for the other name of the service. Claim 24. The system as recited in claim 21, wherein the query logs further comprise query logs that indicate the new name of the service as a queried name. Claim 2. …wherein individual ones of the additional query logs indicate at least the respective queried name; Claim 25. The system as recited in claim 24, wherein the one or more computing devices further implement: identify, based on the analysis of the retrieved data, clients of the service that have switched to using the new name. Claim 2. …identify, based on the analysis of the retrieved additional data, one or more of: clients that are continuing to use the name of the service, or clients that have switched to using the other name of the service. Claim 26. The system as recited in claim 25, wherein to identify clients of the service that have switched to using the new name of the service, the one or more computing devices further implement: identify the clients that have switched to using the new name based on an originating client network address of the query logs that include the new name of the service. Claim 1. …identify, based on the analysis of the retrieved data that includes the originating client network address of clients of the service that used the queried name, Claim 27. The system as recited in claim 25, wherein the one or more computing devices further implement: send, to an endpoint, data that indicates the clients that have switched to using the new name. Claim 3. …send to a management device data indicating one or more of:… one or more of the clients that have switched to using the other name Claims 28-34 are correspond to Claims 6-8 and Claims 35-40 are correspond to Claims 14-16 of US Patent 11425085. 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 21, 28 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over US 2012/0030274 (Christenson et al.) in view of US 2013/0173497 (Gould et al.). Regarding Claim 21, Christenson teaches a system, comprising: one or more computing devices of a provider network comprising respective processors and memory to implement (Fig. 2, ¶ 0033): subsequent to addition, by a domain name service, of a new entry for a new name of a service, retrieve data from query logs generated by the domain name service, wherein the query logs comprise query logs that indicate an old name of the service as a queried name ([¶¶ 0031-0032], A business may wish to change the domain name its application server to a new domain name. …the DNS server may contain an alias from the old domain name for the application server to the new domain name. …use a CNAME record to create this alias. …while the business may wish for customers to be able to access their application server using the old domain name shortly after the domain name change, …the DNS server may contain an alias manager component. The alias manager component may monitor requests for alias records on the DNS server. This monitoring may be done in either real-time or performed periodically as a batch job. [Fig. 2, ¶¶ 0038-0039] The DNS database 272 may contain DNS records that contain a domain name and a current IP address associated with the domain name. … also contains a DNS query log 276, which the message manager 274 may use for logging received DNS queries. [¶ 0044], alias manager component 270 reads record stored in the DNS database. If the alias manager component 270 determines the record is an expirable record [i.e., having an old domain name], the alias manager component 270 searches the DNS query log 276 for a query for the hostname specified by the expirable record); analyze the retrieved data; identify, based on the analysis of the retrieved data, clients of the service that are continuing to use the old name of the service ([¶ 0019], the alias manager component may determine whether the old hostname specified in the record has been accessed within a number of days…whether the old hostname specified by the record has been accessed recently. [¶¶ 0047, 0049], after searching the DNS query log 276 for a matching query for the record the alias manager component 270… the method takes into account whether users are still accessing the address specified by the expirable record [i.e., the old name of service] …whether a particular record is still being frequently accessed by DNS queries). Christenson does not explicitly teach, however, Gould teaches send, to the identified clients of the service that are continuing to use the old name of the service, a name change notification for the service. (Gould teaches creating a new domain, such as a top-level domain (TLD) or a second-level domain (SLD). [¶ 0067], a Registrar queries a Registry for data on one or more new TLDs. When the Registry receives the query and a new TLD is available. With the received data, the Registrar will be able to inform its customers of the name of the new TLD and the various characteristics (services, features and policies) of the new TLD. Gould sending notification to identified customers associated with existing domain, informing them of new name of TLD, which reasonably corresponds to sending a name-change notification to clients continuing to use an old name.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Gould's teaching of informing customers of the name of the new TLD to the Christenson’s teachings of detecting continued use of old domain name, because such incorporation would have improved service continuity, prevent user disruption, and facilitate orderly migration prior to deletion of old domain. Regarding Claim 28, the claim limitations are identical and/or equivalent in scope to Claim 21, therefore, Claim 28 is rejected under the same rationale as Claim 21. Regarding Claim 35, Christenson teaches one or more non-transitory computer-accessible storage media storing program instructions that when executed on or across one or more processors of a provider network ([¶¶ 0022, 0027]). The rest of the limitations of Claim 35 are identical and/or equivalent in scope to Claim 21, therefore, Claim 35 is rejected under the same rationale as Claim 21. Claims 22, 24-26, 29, 31-33, 36 and 38-40 are rejected under 35 U.S.C. 103 as being unpatentable over Christenson in view of Gould, and further in view of US 2014/0215628 (Yan) Regarding Claim 22, as aforementioned, Christenson teaches the system as recited in claim 21, wherein to identify clients of the service that are continuing to use the old name of the service, however, Christenson in view of Gould do not teach, but Yan teaches identify the clients based on an originating client network address of the query logs that include the old name of the service ([¶ 0021] client request log data is accessed. The log may include a table of DNS requests. The table may include for each DNS request, the source IP addresses and the target domain name of the DNS request. the log data may contain information for many different clients and many different domains. [¶ 0035] In response to a DNS request for domain name information associated with a domain name, a recursive DNS nameserver can determine a client identifier. A client identifier discriminates the sender, owner, user, or subscribing entity associated with the request for domain name information. Some examples of a client identifier are IP addresses, userid's, and secure tokens. If an IP address identifier is used, the recursive DNS nameserver can inspect the network packet containing the request to determine the source IP address of the packet). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Yan's teaching of identify user from a DNS request log using IP address of the client to the combined teachings of Christenson and Gould because such incorporation would have improved accuracy of identifying the client. Regarding Claim 24, Christenson in view of Gould do not teach, however, Yan teaches the system as recited in claim 21, wherein the query logs further comprise query logs that indicate the new name of the service as a queried name ([¶ 0021], log may include a table of DNS requests. The table may include for each DNS request, the source IP addresses and the target domain name of the DNS request. Note: When a service is renamed, clients that use the new name will issue a DNS requests in which the target domain name will be the new service name. Since, Yan logs the target domain name for each DNS request, the DNS log necessarily records the new name as a queried name once clients begin using the new name, therefore, Yan teaches that the query log indicates the new name of the service as a queried name by explicitly logging the domain name that was requested in each DNS query). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Yan's table of DNS request which indicate requested target domain name to the combined teachings of Christenson and Gould because such incorporation would have improved accuracy of identifying client’s request for a domain name. Regarding Claim 25, Christenson in view of Gould do not teach, however, Yan teaches the system as recited in claim 24, wherein the one or more computing devices further implement: identify, based on the analysis of the retrieved data, clients of the service that have switched to using the new name ([0016], The network requests of a plurality of clients are analyzed to determine a domain corresponding to each request. This information can be used to associate a set of domains with each individual client. Because of the reciprocal nature of a network request, the information is also used to associate a set of clients with each individual domain. [¶ 0021-0022], client request log data is accessed. The log may include a table of DNS requests in one example. The table may include for each DNS request, the source IP addresses and the target domain name of the DNS request. Each domain is associated with a set of one or more clients from which a DNS request was received for the domain. …for each domain, creating a list of clients that issued a request for the domain. …each client is associated with a set of one or more domains for which the client issued a request. …for each client, creating a list of domains for which a request was issued. [0043] Subscriber database 350 includes a log reflecting client DNS request behavior. The log includes a record of each DNS request received by a nameserver from a client. The log can include a client identifier such as the source IP address of each request and a domain identifier such as the target domain or host name of the request. Note: Since, Yan storing DNS request logs with client identifiers and domain names and analyzing those logs to determine client-domain association, therefore, it would be understood that change in a client’s domain usage over time can be identified by comparing historical and current DNS log entries. Accordingly Yan provides the necessary data structures and analysis mechanism that enable identifying , based on DNS log analysis, clients that have switched to using a new name of a service). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Yan's teachings of analyzing client-domain association based on DNS request log to the combined teachings of Christenson and Gould, because such incorporation would have allowed accurately and reliably determine, based on DNS log analysis, which domain name client are using. The combination applies known DNS log analysis techniques to improve an existing domain-transition management process, yielding predictable results without undue experimentation. Regarding Claim 26, Christenson in view of Gould do not teach, however, Yan teaches the system as recited in claim 25, wherein to identify clients of the service that have switched to using the new name of the service, the one or more computing devices further implement: identify the clients that have switched to using the new name based on an originating client network address of the query logs that include the new name of the service ([¶ 0021] client request log data is accessed. The log may include a table of DNS requests. The table may include for each DNS request, the source IP addresses and the target domain name of the DNS request. the log data may contain information for many different clients and many different domains. [¶ 0035] In response to a DNS request for domain name information associated with a domain name, a recursive DNS nameserver can determine a client identifier. A client identifier discriminates the sender, owner, user, or subscribing entity associated with the request for domain name information. Some examples of a client identifier are IP addresses. Yan teaches identifying client based on the originating Client IP address of DNS queries that include a particular domain name, which corresponds to the claimed identification of clients that have switched to using the new name). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Yan's teaching of identify clients based on the IP address to the combined teachings of Christenson, and Gould, because such incorporation would be a predictable and well-understood alternative for identifying clients, as the use of client IP address is a standard and commonly accepted mechanism for associating DNS queries with requesting clients. Regarding Claims 29 and 31-33, the claim limitations are identical and/or equivalent in scope to Claims 22 and 24-26, therefore, Claims 29 and 31-33 are rejected under the same rationale as Claim 22 and 24-26. Regarding Claims 36 and 38-40, the claim limitations are identical and/or equivalent in scope to Claims 22 and 24-26, therefore, Claims 36 and 38-40 are rejected under the same rationale as Claims 22 and 24-26. Claims 23, 30 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Christenson in view of Gould, and further in view of US 2003/0065762 (Stolorz et al.) Regarding Claim 23, Christenson in view of Gould do not teach, however, Stolorz teaches the system as recited in claim 21, wherein the one or more computing devices further implement: send, to an endpoint, data that indicates the clients that are continuing to use the old name of the service ([¶ 0088] The ATC network monitoring mechanism collect DNS log summaries from different name servers in the ATC name server network. Such summary log data may be received in the form of events that provide information such as, for example, the number of requests directed to particular servers in a given time period. The ATC network monitoring mechanism may collectively processes such DNS log summaries from the entire ATC system. The report generation mechanism may generates monitoring status reports from these summaries and makes such reports available to the subscriber via the secure web-based GUI 160. [¶ 0143] monitor the performance of name servers and generates viewable DNS log reports. The monitoring mechanism may gather performance information from either the DNS logs of the name servers or the events trapped from the name servers. Such gathered information may be used by the report generation mechanism to construct informative reports. The report generation mechanism may also make such reports available to the subscribers via the secure web-based GUI. Note: Stolorz teaches analyzing DNS log data to generate reports and sending those reports to an endpoint (subscriber interface). Since, DNS logs inherently associate client identifiers with queried domain names, the disclosed reports necessarily indicate which client are using particular domain name. Accordingly, when a domain has an old name and a new name, it would be appreciated that the reference teaches sending, to an endpoint, data that indicates clients using the old name or new name). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Stolorz 's teaching of DNS log based reports identifying clients requests directed to particular servers to the combined teachings of Christenson, and Gould, because such incorporation would be improved the reliability and automation of the decision close the old service. The combination is predictable and uses known DNS log monitoring and reporting techniques in a routine manner to enhanced service transition management. Regarding Claims 30 and 37, the claim limitations are identical and/or equivalent in scope to Claim 23, therefore, Claims 30 and 37 are rejected under the same rationale as Claim 23. Claims 27 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Christenson, Gould and Yan, and further in view of Stolorz. Regarding Claim 27, Christenson in view of Gould and Yan do not teach, however, Stolorz teaches the system as recited in claim 25, wherein the one or more computing devices further implement: send, to an endpoint, data that indicates the clients that have switched to using the new name ([¶ 0088] The ATC network monitoring mechanism collect DNS log summaries from different name servers in the ATC name server network. Such summary log data may be received in the form of events that provide information such as, for example, the number of requests directed to particular servers in a given time period. The ATC network monitoring mechanism may collectively processes such DNS log summaries from the entire ATC system. The report generation mechanism may generates monitoring status reports from these summaries and makes such reports available to the subscriber via the secure web-based GUI 160. [¶ 0143] monitor the performance of name servers and generates viewable DNS log reports. The monitoring mechanism may gather performance information from either the DNS logs of the name servers or the events trapped from the name servers. Such gathered information may be used by the report generation mechanism to construct informative reports. The report generation mechanism may also make such reports available to the subscribers via the secure web-based GUI. Note: Stolorz teaches analyzing DNS log data to generate reports and sending those reports to an endpoint (subscriber interface). Since, DNS logs inherently associate client identifiers with queried domain names, the disclosed reports necessarily indicate which client are using particular domain name. Accordingly, when a domain has an old name and a new name, it would be appreciated that the reference teaches sending, to an endpoint, data that indicates clients using the old name or new name). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Stolorz 's teaching of DNS log based reports identifying clients requests directed to particular servers to the combined teachings of Christenson, Gould and Yan, because such incorporation would be improved the reliability and automation of the decision close the old service. The combination is predictable and uses known DNS log monitoring and reporting techniques in a routine manner to enhanced service transition management. Regarding Claim 34, the claim limitations are identical and/or equivalent in scope to Claim 27, therefore, Claim 34 is rejected under the same rationale as Claim 27. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm. 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, ARIO ETIENNE can be reached at 571-272-4001. 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. /MOHAMMAD YOUSUF A. MIAN/ Examiner, Art Unit 2457 /MOUSTAFA M MEKY/ Primary Examiner, Art Unit 2457
Read full office action

Prosecution Timeline

Sep 12, 2024
Application Filed
Sep 24, 2024
Response after Non-Final Action
Jan 08, 2026
Non-Final Rejection — §103, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598236
OWNER CONTROLLED AND INCENTIVISED SMARTPHONE PLATFORM BASED ON MICROSERVICES
2y 5m to grant Granted Apr 07, 2026
Patent 12587550
DETECTING COMPROMISED CLOUD USERS
2y 5m to grant Granted Mar 24, 2026
Patent 12574281
SECURE MANAGEMENT OF ACCESS TO HOST DEVICE REMOTE MANAGEMENT FUNCTIONALITY
2y 5m to grant Granted Mar 10, 2026
Patent 12568280
IMAGE PROCESSING APPARATUS AND METHOD FOR POSTING SCANNED DOCUMENT DATA TO CHAT THREADS
2y 5m to grant Granted Mar 03, 2026
Patent 12550228
Systems and Methods for Collaborative Edge Computing
2y 5m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
66%
Grant Probability
98%
With Interview (+32.7%)
3y 3m
Median Time to Grant
Low
PTA Risk
Based on 273 resolved cases by this examiner. Grant probability derived from career allow 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