Prosecution Insights
Last updated: July 17, 2026
Application No. 18/929,558

SECURE SHARING OF DATA BETWEEN APPLICATIONS

Final Rejection §103
Filed
Oct 28, 2024
Priority
Dec 20, 2021 — continuation of 12/155,765
Examiner
ABEDIN, NORMIN
Art Unit
2449
Tech Center
2400 — Computer Networks
Assignee
American Express Travel Related Services Company, Inc.
OA Round
2 (Final)
84%
Grant Probability
Favorable
3-4
OA Rounds
1y 0m
Est. Remaining
94%
With Interview

Examiner Intelligence

Grants 84% — above average
84%
Career Allowance Rate
367 granted / 435 resolved
+26.4% vs TC avg
Moderate +10% lift
Without
With
+10.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
20 currently pending
Career history
455
Total Applications
across all art units

Statute-Specific Performance

§101
3.1%
-36.9% vs TC avg
§103
85.1%
+45.1% vs TC avg
§102
7.6%
-32.4% vs TC avg
§112
0.9%
-39.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 435 resolved cases

Office Action

§103
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 Claims 1-20 are pending in Instant Application. Priority Examiner acknowledges Applicant’s claim to priority benefits of U.S. Patent 1255765 filed 12/20/2021. Response to Arguments Applicant's arguments filed in the amendment filed 05/11/2026 have been fully considered but they are not persuasive. The reasons are set forth below. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Clark et al., “hereinafter Clark” (U.S. Patent: 10275798) in view of Coimbra et al., “hereinafter Coimbra” (U.S. Patent Application: 20210326430). As per Claim 1, Clark discloses a system comprising: a first computing device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor (Clark, Col.32, Line:64-67, a computer program may be stored in a non-transitory, tangible computer readable storage medium, or any type of media suitable for storing electronic instructions, which may be coupled to a computer system bus. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.), cause the first computing device to at least: receive, from a source application executing on a second computing device, a request comprising a set of data (Clark, Col.14, Line:27-34, users of the online system 140 can request information stored in the application linking addressability store 245, allowing for users to easily link into application associated with the online system 140 or out of the application into an additional application); send at least a portion of the set of data to a token service (Clark, Col.2, Line:38-50, a deep link may include metadata describing information associated with the user, information associated with the application, information associated with the client device, information associated with the operating system of the client device, or any other suitable metadata, Col.12, Line:54-63 , metadata included in a deep link may be used by the application identified by the deep link to format presentation of information to the user. The metadata can also include user profile information of a user presented with a deep link. The user profile information can include a user identifier, an access token, and an expiration time. The access token indicates whether the application associated with the application identifier has been previously or is currently authenticated with the online system 140 associated with the application.), wherein the portion of the set of data comprises confidential data (Clark, Col.19, Line:21-31, if the ad is for subscribing to a service, the state of the additional application associated with the presented 305 ad includes input fields for specifying a first name, a last name, an email address, a phone number, an address, or any other suitable information for subscribing to the service. In this example, the instructions in the deep link include information such as the first name, the last name, and other information maintained by the application as well as a field of the additional application associated with different information maintained by the application.); receive, from the token service, a token associated with the portion of the set of data (Clark, Col.2, Line:34-50, Deep links included in various advertisements or other content include different instructions, allowing different content/advertisements to differently configure states of additional applications. Additionally, a deep link may include metadata describing information associated with the user, information associated with the application, information associated with the client device, information associated with the operating system of the client device, or any other suitable metadata., Clark, Col.2, Line:54-63, metadata included in a deep link may be used by the application identified by the deep link to format presentation of information to the user. The metadata can also include user profile information of a user presented with a deep link. The user profile information can include a user identifier, an access token, and an expiration time. The access token indicates whether the application associated with the application identifier has been previously or is currently authenticated with the online system 140 associated with the application… The metadata can also include referrer information describing the information of an application that presented the deep link including an application identifier associated with an additional application.); generate a deep link based at least in part on the token (Clark, Col.14, Line:1-8,The deep link generation module 240 generates a deep link for a state of an application such as an application associated with the online system 140 or an application associated with an advertiser advertising products in the online system 140. The generated deep link can be generated for an application using a custom address scheme used by the application and includes an application identifier and one or more instructions.); and return the deep link and the token to the source application (Clark, Col.3, Line:1-5, a user playing a game in a game mobile app can interact with an offer in the game that deep links to a state in another mobile app that presents the offer, and the offer mobile app can provide the user with an option to return to a particular state in the game mobile app that corresponds with the game level the user was playing (e.g., click here to return to Level 7 of Game X), Clark, Col.4, Line:5-20, When the user interacts with the reverse deep link via the client device (e.g., the link in the offer mobile app to return to Level 7 in the game mobile app), an additional indication is received by the client device, for example, by the additional application (e.g., the offer mobile app) and communicated to the application (e.g., the game mobile app) associated with the application identifier included in the reverse deep link. After receiving the additional indication, one or more additional instructions included in the reverse deep link are communicated by the client device to the application associated with the reverse deep link. Thus, the application executes the one or more additional instructions and presents a state of the application based on the one or more additional instructions (e.g., the game mobile app presents Level 7 of Game X).). However Clark does not disclose the second computing device. Coimbra discloses the second computing device (Coimbra, Para.36, The system 100 can include application delivery infrastructure. The system 100 can include an online application store or marketplace. The system 100 can include a data processing system 102. The data processing system 102 can communicate with one or more of an third-party (“3P) developer device 162 (or application developer device) or a client computing device 128 (or client device or computing device) via network 101. The system 100 can also communicate with other devices, such as third-party devices, content provider devices, or digital surface devices, Para.78, The action data structure generated by the direct action API 108 can include a deep link for an application installed on the client computing device 128. The application installed on the client computing device 128 can then perform the action or communicate with the 3P developer device 162 or a 3P developer device 162 to perform the action.). The reference Clark discloses application-to-application linking or allowing linking into particular states in an application via a deep link presented in another application within the same client device. The reference Coimbra discloses the application-to-application linking between the first computing device and the second computing device. It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Clark with the teachings as in Coimbra. The motivation for doing so would have been for directed to a system for secure digital assistant integration with web pages. The system can include a data processing system having one or more processors and memory. The data processing system can receive, from a third-party developer device, an intent manifest data structure containing a mapping between a plurality of actions of a digital assistant and a plurality of link templates of an electronic resource developed by the third-party developer device. The data processing system can validate, via a validation policy, the electronic resource based on the intent manifest data structure. The data processing system can receive, from a data exchange component of an iframe of the electronic resource loaded by a client computing device, an identifier of the client computing device that executes the electronic resource. The data processing system can query an onsite state sharing application programming interface of the electronic resource. (Coimbra, Para.3). With respect to Claim 8, 15 are substantially similar to Claim 1 and are rejected in the same manner, the same art and reasoning applying. As per Claim 2, Clark in view of Coimbra discloses the system of claim 1, wherein the request comprising the set of data identifies a set or subset of the set of data to share with a destination application (Clark, Col.25, Line:17-23, if the ad includes an input for playing a file in an additional application and the instructions communicated 325 to the additional application identify the file and include command to play the file, the reverse deep link can include context describing an option to share information associated with the file in the application or a specified state of the application, Clark, Col.10, Line:16-26, Each advertisement includes an advertisement content (“ad content”), which is content presented to an online system user, such as text data, image data, audio data, video data, or any other suitable data. An advertisement may also associate a destination address with an ad content to specify a source of content presented to a user that accesses the advertisement when it is presented. For example, the destination address identifies a landing page including content that is presented to the user when the user accesses the advertisement. The destination address can be included in a deep link.). As per Claim 3, Clark in view of Coimbra discloses the system of claim 2, wherein the first computing device queries a source data store to retrieve information associated with the set or subset of the set of data (Clark, Col.03, Line:40-50, an application identifies an additional application and a search query through a deep link associated with an input presented by the application. When a user accesses the input, the search query is communicated from the application to the additional application, which performs a search across one or more sources based on the search query and subsequently presents the search results as the state of the additional application. Thus, deep links may also allow applications to leverage functionality of additional applications executing on a client device to provide a user with additional information.). As per Claim 4, Clark in view of Coimbra discloses the system of claim 1, wherein the request comprising the set of data includes a destination application identifier associated with a destination application (Clark, Col.02, Line:20-35, The deep link includes an application identifier (also referred to as “app ID”) associated with the additional application (e.g., app ID for mobile travel app) and one or more instructions for execution by the additional application to configure the additional application to a specific state (e.g., instructions to configure the mobile travel app to a state that displays the particular travel deal referenced in the ad). A state of the additional application identifies data received by the additional application as well as data presented by the additional application. Instructions included in a deep link are executed by the additional application identified by the deep link to configure the additional application into a state where content associated with the advertisement or other suitable content is presented based on the instructions.). With respect to Claim 16 is substantially similar to Claim 4 and is rejected in the same manner, the same art and reasoning applying. As per Claim 5, Clark in view of Coimbra discloses the system of claim 4, wherein the request comprising the set of data includes a set of data associated with a schema corresponding to the destination application identified by the destination application identifier (Clark, Col.12, Line:65-67 to Col.13, Line:1-10, the metadata can include a web address in addition to the custom address scheme that can be used to present content associated with the deep link a web browser. Thus, if the application associated with the application identifier is not installed on the client device 110, the content of the deep link can still be presented on the web browser using the web address. The metadata can also include referrer information describing the information of an application that presented the deep link including an application identifier associated with an additional application. The metadata can also include a store identifier associated with the application for use when presenting the application for purchase, download, or install on an application installation interface.). As per Claim 6, Clark in view of Coimbra discloses the system of claim 5, wherein first computing device generates the deep link formatted according to the schema (Clark, Col.11, Line:30-37, The deep link for presenting content on a mobile application includes an application identifier and instructions and, in various implementations, the application identifier can also be referred to as a scheme and the instructions can be in the form of a path and one or more query strings instructing the application to present a state of the application such as a page and the order and/or format of the path and query strings can differ for various operating systems.). As per Claim 7, Clark in view of Coimbra discloses the system of claim 4, wherein the first computing device uses the destination application identifier to search for a deep link schema associated with the destination application and format the deep link generated by the first computing device according to the deep link schema (Clark, Col.11, Line:45-61, Various information (e.g., the application identifier and the instructions) in a deep link can be used in a custom address scheme (e.g., a URL) that allows the mobile app-to-app linking similar to the address scheme used for linking of content on the web. However, the custom address scheme differs from an address scheme used for presenting content on the web (e.g., via a web browser) and can also differ for presenting content on various client devices. For example, an address scheme used for presenting content on the web may have a format of “protocol://domain:path?query_string” to present content at “path?query_string” on “domain” using “protocol” to access the content. The custom address scheme for presenting content via a mobile application may have a format of “application_identifier://path?query_string” for presenting content located at “path?query_string” on a mobile application associated with “application_identifier.”). As per Claim 9, Clark in view of Coimbra discloses the method of claim 8, further comprising including a destination application identifier in the request comprising data and formatting the deep link according to a schema associated with the destination application identifier (Clark, Col.2, Line:20-35, The deep link includes an application identifier (also referred to as “app ID”) associated with the additional application (e.g., app ID for mobile travel app) and one or more instructions for execution by the additional application to configure the additional application to a specific state (e.g., instructions to configure the mobile travel app to a state that displays the particular travel deal referenced in the ad). A state of the additional application identifies data received by the additional application as well as data presented by the additional application. Instructions included in a deep link are executed by the additional application identified by the deep link to configure the additional application into a state where content associated with the advertisement or other suitable content is presented based on the instructions, Clark, Col.11, Line:32-37, the application identifier can also be referred to as a scheme and the instructions can be in the form of a path and one or more query strings instructing the application to present a state of the application such as a page and the order and/or format of the path and query strings can differ for various operating system). As per Claim 10, Clark in view of Coimbra discloses the method of claim 9, further comprising including the schema for the deep link compatible with a destination application in the request from the source application (Clark, Col.11, Line:32-37, the application identifier can also be referred to as a scheme and the instructions can be in the form of a path and one or more query strings instructing the application to present a state of the application such as a page and the order and/or format of the path and query strings can differ for various operating system). As per Claim 11, Clark in view of Coimbra discloses the method of claim 9, further comprising including querying a source data store included in the source computing environment for the schema associated with the destination application identifier (Clark, Col.11, Line:45-61, Various information (e.g., the application identifier and the instructions) in a deep link can be used in a custom address scheme (e.g., a URL) that allows the mobile app-to-app linking similar to the address scheme used for linking of content on the web. However, the custom address scheme differs from an address scheme used for presenting content on the web (e.g., via a web browser) and can also differ for presenting content on various client devices. For example, an address scheme used for presenting content on the web may have a format of “protocol://domain:path?query_string” to present content at “path?query_string” on “domain” using “protocol” to access the content. The custom address scheme for presenting content via a mobile application may have a format of “application_identifier://path?query_string” for presenting content located at “path?query_string” on a mobile application associated with “application_identifier.” ). As per Claim 12, Clark in view of Coimbra discloses the method of claim 8, further comprising identifying a set or subset of data identified by the request comprising data from the source application to share with a third component ( Clark, Col.25, Line:24-32, if the ad includes an input for generating a search query for searching for content presented by the ad and the instructions communicated 325 to the additional application include a search query based on the content presented by the ad, the reverse deep link can include context describing an option to share the search results of the search query on the application, context describing the input to the search query, or any combination thereof.). As per Claim 13, Clark in view of Coimbra discloses the method of claim 12, further comprising including the token associated with the data specified in the request from the source application (Clark, Col.12, Line:47-62, a deep link included in an advertisement or other content also includes metadata describing additional information for communication to an application identified by the application identifier of the deep link. For example, metadata associated with the user, associated with the application, associated with the client device 110, or associated with an operating system of the client device 110 is included in the deep link. For example, metadata included in a deep link may be used by the application identified by the deep link to format presentation of information to the user. The metadata can also include user profile information of a user presented with a deep link. The user profile information can include a user identifier, an access token, and an expiration time. The access token indicates whether the application associated with the application identifier has been previously or is currently authenticated with the online system 140 associated with the application.). As per Claim 14, Clark in view of Coimbra discloses the method of claim 8, further comprising appending the token to an end of the deep link (Clark, Col.12, Line:47-62, a deep link included in an advertisement or other content also includes metadata describing additional information for communication to an application identified by the application identifier of the deep link. For example, metadata associated with the user, associated with the application, associated with the client device 110, or associated with an operating system of the client device 110 is included in the deep link. For example, metadata included in a deep link may be used by the application identified by the deep link to format presentation of information to the user. The metadata can also include user profile information of a user presented with a deep link. The user profile information can include a user identifier, an access token, and an expiration time. The access token indicates whether the application associated with the application identifier has been previously or is currently authenticated with the online system 140 associated with the application.). As per Claim 17, Clark in view of Coimbra discloses the non-transitory, computer-readable medium of claim 16, wherein the request comprising the set of data includes a schema associated with the destination application identifier (Clark, Col.12, Line:65-67, the metadata can include a web address in addition to the custom address scheme that can be used to present content associated with the deep link a web browser. Thus, if the application associated with the application identifier is not installed on the client device 110, the content of the deep link can still be presented on the web browser using the web address. The metadata can also include referrer information describing the information of an application that presented the deep link including an application identifier associated with an additional application. The metadata can also include a store identifier associated with the application for use when presenting the application for purchase, download, or install on an application installation interface.). As per Claim 18, Clark in view of Coimbra discloses the non-transitory, computer-readable medium of claim 16, wherein machine-readable instructions, when executed by the processor, further cause the first computing device to at least: determine a deep link schema associated with the destination application identifier associated with the destination application identifier; and format the deep link generated by the first computing device according to the deep link schema (Clark, Col.11, Line:45-61, Various information (e.g., the application identifier and the instructions) in a deep link can be used in a custom address scheme (e.g., a URL) that allows the mobile app-to-app linking similar to the address scheme used for linking of content on the web. However, the custom address scheme differs from an address scheme used for presenting content on the web (e.g., via a web browser) and can also differ for presenting content on various client devices. For example, an address scheme used for presenting content on the web may have a format of “protocol://domain:path?query_string” to present content at “path?query_string” on “domain” using “protocol” to access the content. The custom address scheme for presenting content via a mobile application may have a format of “application_identifier://path?query_string” for presenting content located at “path?query_string” on a mobile application associated with “application_identifier.” ). As per Claim 19, Clark in view of Coimbra discloses the non-transitory, computer-readable medium of claim 17, wherein the first computing device queries a source data store included in a source computing environment for the schema associated with the destination application identifier (Clark, Col.11, Line:45-61, Various information (e.g., the application identifier and the instructions) in a deep link can be used in a custom address scheme (e.g., a URL) that allows the mobile app-to-app linking similar to the address scheme used for linking of content on the web. However, the custom address scheme differs from an address scheme used for presenting content on the web (e.g., via a web browser) and can also differ for presenting content on various client devices. For example, an address scheme used for presenting content on the web may have a format of “protocol://domain:path?query_string” to present content at “path?query_string” on “domain” using “protocol” to access the content. The custom address scheme for presenting content via a mobile application may have a format of “application_identifier://path?query_string” for presenting content located at “path?query_string” on a mobile application associated with “application_identifier.” ). As per Claim 20, Clark in view of Coimbra discloses the non-transitory, computer-readable medium of claim 19, wherein the first computing device generates the deep link formatted according to the schema (Clark, Col.11, Line:45-61, The deep link for presenting content on a mobile application includes an application identifier and instructions and, in various implementations, the application identifier can also be referred to as a scheme and the instructions can be in the form of a path and one or more query strings instructing the application to present a state of the application such as a page and the order and/or format of the path and query strings can differ for various operating systems.). The applicant Argue: Argument 1: Applicant argues that the reference Clark in view of Coimbra fails to teach or suggest “send at least a portion of the set of data to token service, wherein the portion of the set of data comprises confidential data;” as recited in claim 1. In response, Examiner would like to point out that the reference **** does teach in Col.2, Line:38-50, “a deep link may include metadata describing information associated with the user, information associated with the application, information associated with the client device, information associated with the operating system of the client device, or any other suitable metadata” and in Col.12, Line:54-63 , “metadata included in a deep link may be used by the application identified by the deep link to format presentation of information to the user. The metadata can also include user profile information of a user presented with a deep link. The user profile information can include a user identifier, an access token, and an expiration time. The access token indicates whether the application associated with the application identifier has been previously or is currently authenticated with the online system 140 associated with the application” and in Col.19, Line:21-31, “if the ad is for subscribing to a service, the state of the additional application associated with the presented 305 ad includes input fields for specifying a first name, a last name, an email address, a phone number, an address, or any other suitable information for subscribing to the service. In this example, the instructions in the deep link include information such as the first name, the last name, and other information maintained by the application as well as a field of the additional application associated with different information maintained by the application.”. In the instant application the confidential data is described in Para.22, “Examples of confidential data 133 can include personally identifying information (PII) of users or customers (e.g., legal names, account numbers, email addresses, mailing addresses, telephone numbers, authentication credentials, etc.), files or documents containing confidential information, etc.”. The reference Clark teaches the confidential data in Col.19, Line:21-31. The deep link module generated deep link with metadata (application identifier and a user identifier, an access token, and an expiration time). Argument 2: Applicant argues that the reference Clark in view of Coimbra fails to teach or suggest “receive, from the token service, a token associated with the portion of the set of data” as recited in claim 1. In response, Examiner would like to point out that the reference Clark does teach in Col.2, Line:34-50, “Deep links included in various advertisements or other content include different instructions, allowing different content/advertisements to differently configure states of additional applications. Additionally, a deep link may include metadata describing information associated with the user, information associated with the application, information associated with the client device, information associated with the operating system of the client device, or any other suitable metadata” and in Col.2, Line:54-63, “metadata included in a deep link may be used by the application identified by the deep link to format presentation of information to the user. The metadata can also include user profile information of a user presented with a deep link. The user profile information can include a user identifier, an access token, and an expiration time. The access token indicates whether the application associated with the application identifier has been previously or is currently authenticated with the online system 140 associated with the application… The metadata can also include referrer information describing the information of an application that presented the deep link including an application identifier associated with an additional application.” Conclusion THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to NORMIN ABEDIN whose telephone number is (571)270-5970. The examiner can normally be reached Monday to Friday from 10 am to 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, Vivek Srivastava can be reached at 5712727304. 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. /NORMIN ABEDIN/Primary Examiner, Art Unit 2449
Read full office action

Prosecution Timeline

Oct 28, 2024
Application Filed
Feb 19, 2026
Non-Final Rejection mailed — §103
May 04, 2026
Examiner Interview Summary
May 04, 2026
Examiner Interview (Telephonic)
May 11, 2026
Response Filed
Jun 23, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12684348
NETWORK MANAGEMENT IN AN INTERNET-OF-THINGS (IOT) ENVIRONMENT
2y 9m to grant Granted Jul 14, 2026
Patent 12682296
Rules Engine for Dynamic Contextual Routing to Artificial Intelligence Models
12m to grant Granted Jul 14, 2026
Patent 12676827
COMMUNICATION SYSTEM
1y 9m to grant Granted Jul 07, 2026
Patent 12659382
VEHICLE MOBILITY SYSTEM COMMUNICATIONS NETWORK
1y 6m to grant Granted Jun 16, 2026
Patent 12647389
Forcing Use of Streaming Meter as Alternate Gateway to Facilitate Media-Exposure Measurement
1y 9m to grant Granted Jun 02, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
84%
Grant Probability
94%
With Interview (+10.0%)
2y 9m (~1y 0m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 435 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