Prosecution Insights
Last updated: August 18, 2026
Application No. 18/786,610

IDENTITY VERIFICATION METHOD FOR NETWORK FUNCTION SERVICE AND RELATED APPARATUS

Final Rejection §103§DOUBLEPATENT
Filed
Jul 29, 2024
Priority
Apr 28, 2019 — CN 201910359634.9 +3 more
Examiner
CHAMPAKESAN, BADRI NARAYANAN
Art Unit
2494
Tech Center
2400 — Computer Networks
Assignee
Huawei Technologies Co., Ltd.
OA Round
2 (Final)
91%
Grant Probability
Favorable
3-4
OA Rounds
3m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 91% — above average
91%
Career Allowance Rate
352 granted / 386 resolved
+33.2% vs TC avg
Strong +55% interview lift
Without
With
+55.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 4m
Avg Prosecution
23 currently pending
Career history
396
Total Applications
across all art units

Statute-Specific Performance

§101
4.5%
-35.5% vs TC avg
§103
55.5%
+15.5% vs TC avg
§102
10.0%
-30.0% vs TC avg
§112
15.2%
-24.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 386 resolved cases

Office Action

§103 §DOUBLEPATENT
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 Arguments Applicant’s arguments, see Remarks, filed 06/02/2026, with respect to claim objection and 112f invocation have been fully considered and are persuasive due to new amendments to the claims. The objection and 112f invocation have been withdrawn. Since no arguments have been put forth for the DP rejection nor an e-TD was filed, the rejection is hereby maintained. Applicant's arguments filed 06/02/2026 have been fully considered but they are not persuasive. The attorney argues that “The applicant notes that Brockhaus is not in the same field of endeavor as the claimed 5G SBA network-function (NF) service identity verification (it is industrial PKI enrollment/token issuance control), and thus cannot be used to retrofit Li's carrier entitlement flow into the claimed SBA proxy-mediated NF service architecture (Office Action, Rejection 9; Brockhaus, col. 6 11. 35- 47). Separately, even if Bro is considered, the Office's rationale is conclusory because it never explains how an industrial enrollment "authorization apparatus" request message becomes a 5G SBA "serving communication proxy" relaying an NF service request/response as claimed, which fails the requirement for articulated reasoning with rational underpinning (Office Action, Rejection 9; MPEP § 2143; In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)). The present specification makes clear that the claimed "serving communication proxy" is the SBA intermediary (SFSF/SCP) that forwards NF service requests between NF service consumer and producer in a 5G core service-based architecture, not a certificate-enrollment authority, and that the security problem is token misuse in NRF-based NF service authorization (SPEC [0003]-[0006], [0091]-[0094]). Against that, Li is limited to password-less carrier entitlement/SIM provisioning flows (not SBA NF service proxying), and Brockhaus's CSReq is a certificate issuance/enrollment request, not a proxied NF service request that includes a token and is conditionally relayed/returned by a serving communication proxy (Li [0001]-[0003], [0024]- [0027]; Brockhaus, col. 6 11. 35-47; Office Action, Rejection 9). Accordingly, the applicant urges that Bro is not analogous art and has been improperly combined with Li to form the rejection under 103”. The examiner respectfully disagrees with the arguments. In response to applicant's argument that ‘Bro’ is non-analogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. One cannot import the information from the specification to the claims and argue based on the specification but not claimed. The specification is typically used to understand and/or interpret the proper context and meaning of the claimed concept. MPEP 2173.01 I. BRI states “Under a broadest reasonable interpretation, words of the claim must be given their plain meaning, unless such meaning is inconsistent with the specification. The plain meaning of a term means the ordinary and customary meaning given to the term by those of ordinary skill in the art at the time of the invention. The ordinary and customary meaning of a term may be evidenced by a variety of sources, including the words of the claims themselves, the specification, drawings, and prior art … The court upheld the Board’s refusal to import from the specification a limitation that would apply the term only to hairbrushes for the scalp. "[T]his court counsels the PTO to avoid the temptation to limit broad claim terms solely on the basis of specification passages.” Also, see MPEP 2111.01 Interpreting the Claims II. IT IS IMPROPER TO IMPORT CLAIM LIMITATIONS FROM THE SPECIFICATION. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, ‘Bro’ is reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The attorney argues that “A) Li does not disclose calculating, by a first NE, an input parameter in the manner as required in the first emphasized element. Li discloses in par. 026 that the managing entity can generate a response including a digital signature for the response established using a private key, and the private key corresponding to a public key. However, Li fails to disclose that: (1) the input parameter for calculating the digital signature includes information about the second network element (i.e., a provider of the network function service or a control plane network element). Bro also fails to disclose this feature.” The examiner respectfully disagrees with the arguments. When prior art recites “[025] the existing mobile device can utilize a private key (that is specific to the existing mobile device) to establish a digital signature for the request” – this means the private key is used to calculate the digital signature. Further, [026] a digital signature for the response that is established using a private key associated with the managing entity (i.e., provider). Additionally, the managing entity can provide, to the MNO, the public key counterpart to the private key associated with the managing entity … Additionally, the request can include a digital signature that is established using the private key associated with the managing entity; [037-38, 58] the information associated with the second mobile device includes a digital signature produced using a private key associated with the second mobile device, and the information includes: (1) a nonce that is received from the entitlement server in response to authenticating with the entitlement server, where the nonce is included in the request to register the first mobile device with the MNO, and (2) one or more of …”. The attorney argues that “B) Li does not describe receiving, by the first NE, a service response from the serving communication proxy a service response indicating that the digital signature is verified to be correct but also that the identity of the first NE in the certificate and an identity of the first NE in the token are verified to be correct.” The examiner respectfully disagrees with the arguments as the arguments are based on new amendments which was present during the prior rejection. The amendments were given due careful consideration and updated rejection is made below. Therefore, the rejections under 103 are maintained. 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 1 – 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims of U.S. Patent No. 12052233. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application claims are made obvious by said patent claims and further in view of Brockhaus et al (US 10,511,587), Bro and Birgisson et al (US 20170214664), Bir. Instant App. 18786610 Patent No. 12052233 1. (Currently Amended) An identity verification method for a network function service, comprising: calculating, by a first network element, an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about a second network element, the first network element is a requester of the network function service, and the second network element is a provider of the network function service or a control plane network element; sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; and receiving, by the first network element, a service response from the serving communication proxy in the case that the digital signature is verified to be correct but also an identity of the first network element in the certificate and an identity of the first network element in the token are verified to be correct 2. (Original) The identity verification method according to claim 1, wherein the information about the second network element comprises at least one of a type of the second network element, a group identifier of the second network element, a set identifier of the second network element, or address information of the second network element. 3. (Original) The identity verification method according to claim 1, wherein the input parameter further comprises information about a consumer service communication proxy, and the information about the consumer service communication proxy comprises at least one of the following: an instance identifier of the consumer service communication proxy, address information of the consumer service communication proxy, a group identifier of the consumer service communication proxy, or a set identifier of the consumer service communication proxy. 4. (Original) The identity verification method according to claim 1, wherein the input parameter further comprises slice information, and the slice information comprises a network slice instance identifier or single network slice selection assistance information (S-NSSAI). 5. (Original) The identity verification method according to claim 1, wherein the input parameter further comprises at least one of the token or the identity of the first network element. 6. (Currently Amended) The identity verification method according to claim 1, further comprising: receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or when the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect. 7. (Currently Amended) An identity verification method for a network function service, comprising: receiving, by a second network element, a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; verifying, by the second network element, whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate and an identity of the first network element in the token are correct and the identity of the first network element in the token are correct, sending, by the second network element, a service response. 8. (Currently Amended) The identity verification method according to claim 7, further comprising: when the digital signature is verified to be incorrect or when the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect, sending, by the second network element, an error code. 9. (Currently Amended) The identity verification method according to claim 8, wherein the error code indicates that the digital signature is verified to be incorrect, or indicates that the error code indicates that the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect. 10. (Currently Amended) An apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to: calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about a second network element, the apparatus is a requester of a network function service, and the second network element is a provider of the network function service or a control plane network element; send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; and receive a service response from the serving communication proxy in the case that the digital signature is verified to be correct and an identity of the apparatus in the certificate and an identity of the apparatus in the token are verified to be correct 11. (Original) The apparatus according to claim 10, wherein the information about the second network element comprises at least one of a type of the second network element, a group identifier of the second network element, a set identifier of the second network element, or address information of the second network element. 12. (Original) The apparatus according to claim 10, wherein the input parameter further comprises at least one of the token or the identity of the apparatus. 13. (Currently Amended) The apparatus according to claim 10, wherein the processor is further configured to: receive an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the apparatus in the certificate and the identity of the apparatus in the token are verified to be incorrect. 14. (Currently Amended) An apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to: receive a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; verify whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate and an identity of the first network element in the token are correct, wherein the first network element is a requester of a network function service, and the apparatus is a provider of the network function service or a control plane network element; and when the digital signature is verified to be correct but also the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be correct 15. (Currently Amended) The apparatus according to claim 14, wherein the processor is further configured to: when the digital signature is verified to be incorrect or when the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect, send an error code. 16. (Currently Amended) The apparatus according to claim 14, wherein the error code indicates that the digital signature is verified to be incorrect, or the error code indicates that the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect. 17. (Currently Amended) A system comprising: a first network element; and a second network element, wherein the first network element is a requester of a network function service, the second network element is a provider of the network function service or a control plane network element, and wherein the first network element comprises a first processor and a first memory storing instructions that, when executed by the first processor, cause the first network element to: calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about the second network element; and send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token, wherein the second network element comprises a second processor and a second memory with instructions to cause the second network element to: receive the service request from the serving communication proxy; verify whether the digital signature is correct based on the certificate and whether the identity of the first network element in the certificate and the identity of the first network element in the token are correct; and when the digital signature is verified to be correct but also the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be correct 18. (Original) The system according to claim 17, wherein the information about the second network element comprises a type of the second network element, and the input parameter further comprises the identity of the first network element. 19. (Currently Amended) The system according to claim 17, wherein the second network element is further configured to: when the digital signature is verified to be incorrect or when the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect, send an error code to the serving communication proxy, and wherein the first network element is further configured to: receive the error code from the serving communication proxy. 20. (Currently Amended) The system according to claim 17, wherein the system comprises the serving communication proxy, and the serving communication proxy is configured to: receive the service request from the first network element; send the service request to the second network element; receive the service response from the second network element; and send the service response to the first 1. An identity verification method performed by a managing network element in a service network, comprising: receiving, via the service network, a network function (NF) service request from a requesting network element in the service network, wherein the NF service request comprises a service token for a first NF service provided by the managing network element, the service token is provided by a service token server of the service network for the first NF service and comprises first certificate information, wherein the first certificate information is related to a certificate of a requester of the service token and comprises identity information of the requester of the service token as used in the certificate of the requester of the service token, wherein the managing network element is a control plane network element of the service network, and the first certificate information comprises an identifier or an NF type of the requester of the service token; obtaining, via the service network, a certificate of the requesting network element; determining 2. (Canceled) 3. (Previously Presented) The method according to claim 1, wherein the identity information of the requester of the service token in the first certificate information comprises an identifier of 4. (Previously Presented) The method according to claim 1, wherein the first certificate information comprises an NF type of the requester of the service token, and the certificate of the requesting network element indicates an NF type of the requesting network element. 5. (Canceled) 6. A requester identity verification method performed by a requesting network element in a service network, comprising: obtaining, from a service token server in the service network, a service token corresponding to a first NF service provided by a managing network element in the service network, wherein the service token comprises first certificate information related to a certificate of a requester of the service token and comprising identity information of the requester of the service token as used in the certificate of the requester of the service token, wherein the managing network element is a control plane network element of the service network, and the first certificate information comprises an identifier or an NF type of the requester of the service token; sending an NF service request for the first NF service to the managing network element, wherein the NF service request comprises the service token; and receiving a reject message from the managing network element, wherein receiving the reject message indicates that the managing network element fails to verify the requesting network element based on the service token in the NF service request. 7. (Previously Presented) The method according to claim 6, wherein the identity information in the first certificate information comprises an identifier of the requester of the service token. 8. (Previously Presented) The method according to claim 6, wherein the identity information in the first certificate information comprises an NF type of the requester of the service token. 9. (Previously Presented) The method according to claim 6, wherein the step of obtaining the service token corresponding to the first NF service comprises: sending a token obtaining request to the service token server in a control plane network of the service network; and receiving, by the requesting network element, the service token returned by the service token server. 10. A network element in a service network comprising: a transceiver for network communications; a memory storing executable instructions; a processor configured to execute the executable instructions to: receive, via the service network, a network function (NF) service request for a first NF service from a requesting network element in the service network, wherein the NF service request comprises a service token provided by a service token server of the service network for the first NF service, the service token comprises first certificate information related to a certificate of a requester of the service token and comprising identity information of the requester of the service token as used in the certificate of the requester of the service token, wherein the network element is a control plane network element of the service network, and the first certificate information comprises an identifier or an NF type of the requester of the service token; obtaining, via the service network, a certificate of the requesting network element; determine whether the identity information of the requester of the service token in the first certificate information is consistent with identity information of the requesting network element in the certificate of the requesting network element; and upon determining that the identity information of the requester in the service token in the first certificate information is inconsistent with the identity information of the requesting network element in the certificate of the requesting network element, reject the NF service request. 11. (Previously Presented) The network element according to claim 10, wherein the processor is further configured to: process the NF service request when the identity information of the requester of the service token in represented by the first certificate information is consistent with the identity information of the requesting network element in the certificate of the requesting network element. 12. (Canceled) 13. (Canceled) 14. The network element according to claim 10 15. (Currently Amended) The network element according to claim 10 Pat. # 12052233 teaches the concept of instant application but is silent on sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; and receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token. But analogous art Bro teaches sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of 12052233 to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59). Analogous art Bir teaches receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of 12052233 and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07]. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claim(s) 1 – 5, 7, 10 – 12, 14, 17, 18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al (US 20190373471), Li and Brockhaus et al (US 10,511,587), Bro. Claim 1: Li teaches a identity verification method for a network function service, comprising: calculating, by a first network element, an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature ([025-26] the existing mobile device can utilize a private key (specific to the existing mobile device) to establish a digital signature for the request … where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer). wherein the input parameter comprises information about a second network element, the first network element is a requester of the network function service, and the second network element is a provider of the network function service or a control plane network element; ([053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device sends a message to the entitlement server to sign up for cellular wireless service for the new device). and receiving, by the first network element, a service response from the serving communication proxy in the case that the digital signature is verified to be correct but also an identity of the first network element in the certificate and an identity of the first network element in the token are verified to be correct ([09] request for the authentication token includes unique identifiers associated with the current device... [026-27] the request can include a digital signature that is established using the private key associated with the managing entity, where the MNO verifies the digital signature by utilizing the public key counterpart ... In response, the one or more SIM data servers utilizes the information (that is associated with the authentication token...) to verify the authentication token, when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and information, such as an equipment identifiers (EIDs) ... and the new eICCID). Li is silent on sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; But analogous art Bro teaches sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59). Claim 2: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the information about the second network element comprises at least one of a type of the second network element, a group identifier of the second network element, a set identifier of the second network element, or address information of the second network element. (Li: [053] credentials include an EID, a fully qualified domain name (FQDN), and/or a new eICCID). Claim 3: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the input parameter further comprises information about a consumer service communication proxy, and the information about the consumer service communication proxy comprises at least one of the following: an instance identifier of the consumer service communication proxy, address information of the consumer service communication proxy, a group identifier of the consumer service communication proxy, or a set identifier of the consumer service communication proxy. (Li: [038] The pre-flight request can include the information provided by the remote server including the trust score, credentials, and nonce as signed by the entitlement server). Claim 4: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the input parameter further comprises slice information, and the slice information comprises a network slice instance identifier or single network slice selection assistance information (S-NSSAI). (Li: [041] entitlement server verifies and responds with additional credentials and/or information such as an EID, a fully qualified domain name (FQDN), and the new eICCID (i.e., slice)). Claim 5: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the input parameter further comprises at least one of the token or the identity of the first network element. (Li: [012] the current device can provide the carrier token obtained from the entitlement server). Claim 7: Li teaches an identity verification method for a network function service, comprising: verifying, by the second network element, whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate and an identity of the first network element in the token are correct and the identity of the first network element in the token are correct, sending, by the second network element, a service response. ([025-26] the existing mobile device can utilize a private key (specific to the existing mobile device) to establish a digital signature for the request … where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device (i.e., requester) sends a message to the entitlement server (i.e., provider) to sign up for cellular wireless service for the new device; [09] request for the authentication token includes unique identifiers associated with the current device... [026-27] the request can include a digital signature that is established using the private key associated with the managing entity, where the MNO verifies the digital signature by utilizing the public key counterpart ... In response, the one or more SIM data servers utilizes the information (that is associated with the authentication token...) to verify the authentication token, when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and information, such as an equipment identifiers (EIDs) ... and the new eICCID). Li is silent on receiving, by a second network element, a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; But analogous art Bro teaches receiving, by a second network element, a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59). Claim 10: Li teaches an apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to (Fig. 7): calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about a second network element, the apparatus is a requester of a network function service, and the second network element is a provider of the network function service or a control plane network element; and receive a service response from the serving communication proxy in the case that the digital signature is verified to be correct and an identity of the apparatus in the certificate and an identity of the apparatus in the token are verified to be correct ([025-26] the existing mobile device can utilize a private key (specific to the existing mobile device) to establish a digital signature for the request … where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device (i.e., requester) sends a message to the entitlement server (i.e., provider) to sign up for cellular wireless service for the new device; [09] request for the authentication token includes unique identifiers associated with the current device... [026-27] the request can include a digital signature that is established using the private key associated with the managing entity, where the MNO verifies the digital signature by utilizing the public key counterpart ... In response, the one or more SIM data servers utilizes the information (that is associated with the authentication token...) to verify the authentication token, when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and information, such as an equipment identifiers (EIDs) ... and the new eICCID). Li is silent on send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; But analogous art Bro teaches send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59). Claim 11: the combination of Li and Bro teaches the apparatus according to claim 10, wherein the information about the second network element comprises at least one of a type of the second network element, a group identifier of the second network element, a set identifier of the second network clement, or address information of the second network element. (Li: [053] credentials include an EID, a fully qualified domain name (FQDN), and/or a new eICCID). Claim 12: the combination of Li and Bro teaches the apparatus according to claim 10, wherein the input parameter further comprises at least one of the token or the identity of the apparatus. (Li: [012] the current device can provide the carrier token obtained from the entitlement server). Claim 14: Li teaches an apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to (Fig. 7): verify whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate and an identity of the first network element in the token are correct, wherein the first network element is a requester of a network function service, and the apparatus is a provider of the network function service or a control plane network element; and when the digital signature is verified to be correct but also the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be correct ([025-26] the request includes a digital signature that is established using the private key associated with the managing entity… where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device 110 sends a message to the entitlement server to sign up for cellular wireless service for the new device 150; [027] when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and/or information, an EID, a fully qualified domain name (FQDN), and the new eICCID). Li is silent on receive a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; But analogous art Bro teaches receive a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59). Claim 17: Li teaches a system comprising: a first network element; and a second network element, wherein the first network element is a requester of a network function service, the second network element is a provider of the network function service or a control plane network element, and wherein the first network element comprises a first processor and a first memory storing instructions that, when executed by the first processor, cause the first network element to: calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about the second network element; wherein the second network element comprises a second processor and a second memory with instructions to cause the second network element to: receive the service request from the serving communication proxy; verify whether the digital signature is correct based on the certificate and whether the identity of the first network element in the certificate and the identity of the first network element in the token are correct; and when the digital signature is verified to be correct but also the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be correct ([025-26] the existing mobile device can utilize a private key (specific to the existing mobile device) to establish a digital signature for the request … where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device (i.e., requester) sends a message to the entitlement server (i.e., provider) to sign up for cellular wireless service for the new device; [09] request for the authentication token includes unique identifiers associated with the current device... [026-27] the request can include a digital signature that is established using the private key associated with the managing entity, where the MNO verifies the digital signature by utilizing the public key counterpart ... In response, the one or more SIM data servers utilizes the information (that is associated with the authentication token...) to verify the authentication token, when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and information, such as an equipment identifiers (EIDs) ... and the new eICCID).Li is silent on send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; But analogous art Bro teaches send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59). Claim 18: the combination of Li and Bro teaches the system according to claim 17, wherein the information about the second network element comprises a type of the second network element, and the input parameter further comprises the identity of the first network element. (Li: [053] credentials include an EID, a fully qualified domain name (FQDN), and/or a new eICCID; [042-43, Fig. 3] the first mobile device is added to an existing wireless service account without requiring use of MNO login credentials … the second mobile device authenticates with an entitlement server associated with the MNO, such as by providing SIM data that is possessed by the second mobile device). Claim 20: the combination of Li and Bro teaches the system according to claim 17, wherein the system comprises the serving communication proxy, and the serving communication proxy is configured to: receive the service request from the first network element; send the service request to the second network element; receive the service response from the second network element; and send the service response to the first [035-039, Fig. 1]: The remote server 120 provides information that assists with authentication by the network-based servers to validate providing cellular wireless service to the new wireless device. At 132, the existing device 110 performs an extensible authentication protocol (EAP) authentication key agreement (AKA) procedure with an entitlement server 130 of an MNO to establish a secure communication link between the existing device 110 and the entitlement server 130. At 112, the existing device 110 initiates authentication with the entitlement server 130, which responds to the existing device 110 at 134 with a nonce generated at 133. At 113, the existing device 110 sends an authentication request to the remote server 120 to obtain a trust score from the remote server). Claim(s) 6, 8, 9, 13, 15, 16, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li and Bro as applied to claims above, and further in view of Birgisson et al (US 20170214664), Bir. Claim 6: the combination of Li and Bro teaches the identity verification method according to claim 1, further comprising: but analogous art Bir teaches receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or when the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07]. Claim 8: the combination of Li and Bro teaches the identity verification method according to claim 7, further comprising: but analogous art Bir teaches when the digital signature is verified to be incorrect or when the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect, sending, by the second network element, an error code. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07]. Claim 9: the combination of Li and Bro teaches the identity verification method according to claim 8, but analogous art Bir teaches wherein the error code indicates that the digital signature is verified to be incorrect, or indicates that the error code indicates that the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect. ([061] determine that the computed digital signature fails to match the received digital signature, client device establishes that resource device failed to prove its possession of the client-specific cryptographic key, and client device transmits a message indicative of a failed connection to resource device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Van so that the said control access server determines in a request validation step whether for the authenticated secret mobile communication device identifying code, the access request to the protected area within said predetermined time period of access is a validated access request for the authenticated secret mobile communication device identifying code [0138]. Claim 13: the combination of Li and Bro teaches the apparatus according to claim 10, but analogous art Bir teaches wherein the processor is further configured to: receive an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the apparatus in the certificate is inconsistent with the identity of the apparatus in the token. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07]. Claim 15: the combination of Li and Bro teaches the apparatus according to claim 14, but analogous art Bir teaches wherein the processor is further configured to: when the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token, send an error code. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07]. Claim 16: the combination of Li and Bro teaches the apparatus according to claim 14, but analogous art Bir teaches wherein the error code indicates that the digital signature is verified to be incorrect, or the error code indicates that the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect. ([061] determine that the computed digital signature fails to match the received digital signature, client device establishes that resource device failed to prove its possession of the client-specific cryptographic key, and client device transmits a message indicative of a failed connection to resource device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Van so that the said control access server determines in a request validation step whether for the authenticated secret mobile communication device identifying code, the access request to the protected area within said predetermined time period of access is a validated access request for the authenticated secret mobile communication device identifying code [0138]. Claim 19: the combination of Li and Bro teaches the system according to claim 17, but analogous art Bir teaches wherein the second network element is further configured to: when the digital signature is verified to be incorrect or when the identity of the first network element in the certificate and the identity of the first network element in the token are verified to be incorrect, send an error code to the serving communication proxy, and wherein the first network element is further configured to: receive the error code from the serving communication proxy. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device). Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07]. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Badri Champakesan whose telephone number is (571)270-3867. The examiner can normally be reached M-F: 8.30am-4.30pm (EST). 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, Jung Kim can be reached at (571) 272-3804. 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. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Badri Champakesan whose telephone number is (571)270-3867. The examiner can normally be reached M-F: 8.30am-4.30pm (EST). 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, Jung Kim can be reached at (571) 272-3804. 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. /BADRINARAYANAN /Primary Examiner, Art Unit 2494.
Read full office action

Prosecution Timeline

Jul 29, 2024
Application Filed
Feb 13, 2026
Examiner Interview (Telephonic)
Mar 02, 2026
Non-Final Rejection mailed — §103, §DOUBLEPATENT
Jun 02, 2026
Response Filed
Jun 22, 2026
Examiner Interview (Telephonic)
Jul 06, 2026
Final Rejection mailed — §103, §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12689639
DETECTING ANOMALOUS NETWORK BEHAVIOR IN OPERATIONAL TECHNOLOGY PROTOCOLS
3y 0m to grant Granted Jul 21, 2026
Patent 12689636
TECHNIQUES FOR INCIDENT RESPONSE AND STATIC ANALYSIS REPRESENTATION IN COMPUTING ENVIRONMENTS
1y 8m to grant Granted Jul 21, 2026
Patent 12676868
Pattern Analysis Threat Identification
2y 12m to grant Granted Jul 07, 2026
Patent 12675561
MODULAR DATA CENTER
1y 11m to grant Granted Jul 07, 2026
Patent 12675758
NESTED MODEL STRUCTURES FOR THE PERFORMANCE OF COMPLEX TASKS
1y 8m to grant Granted Jul 07, 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
91%
Grant Probability
99%
With Interview (+55.4%)
2y 4m (~3m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 386 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