CTNF 18/131,310 CTNF 96187 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This Office Action is in response to the Continuation filed on 11/26/2025. In the instant Amendment, claims 1, 4, 11, and 14 have been amended; and claims 1 and 11 are independent claims. Claims 1, 4-11, and 14-19 have been examined and are pending. Response to Arguments Applicant’s Argument filed on 06/04/2025, regarding the 103 rejection have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment. Applicant further argues that Innes’s SDK would be located in Suresh’s virtualized application rather than at the smartphone device. This argument is not persuasive because the rejection relies on Innes for a client-device SDK, not for placing an SDK inside Suresh’s virtualized session. Innes expressly teaches that the client device includes the PKOperation SDK module and that signing and certificate operations are sent to the PKOperation SDK at the client device. Also, Applicant’s own specification (e.g. para [36], [41]) supports that an SDK incorporated into an application installed on a communication device is still an SDK at the device: the specification states that the application installed at the communication device includes the digital identity SDK, and that the API call is received at the digital identity SDK “in the communication device 110, as part of the application 112”. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-21-aia AIA Claim s 1, 4-6, 9-11, 14-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Suresh et al. (U.S. Pub. 20200374284 A1; Hereinafter “Suresh”) in view of Innes et al. (U.S. Pub. 20180007059 A1; Hereinafter “Innes”), Baghdasaryan (U.S. Pub. 2017/0109509 A1; Hereinafter “Baghdasaryan”), and Ross et al. (U.S. Pub. 20190334884 A1; Hereinafter “Ross”) . As per claims 1 and 11, Suresh teaches a computer-implemented method for use in managing user identities, the method comprising (Suresh: fig. 1, 7, para [118-122] “configured to communicate with a given client device 201a over a network, for example, the Internet, or a local network, to provide the client device with a virtualized session 208 for a user….The given client device 201a also includes a processor 224 coupled to the biometric device 207, and a memory 225 coupled to the processor.”): based on an interaction between a browser of a smartphone device (device 201) and a website of a relying party (Suresh: para [003], [119], Figs. 12-13, “An application 204 within the virtualized session 208 performs an authentication operation 223 with the relying party 203 to access a resource. For example, the application 204 comprises a web browser application, a native application operating within the virtualized session 208, or an interface for a local resource .”, “user's physical computing device (e.g., smartphone, laptop, desktop computer)”), receiving, at the smartphone device , an application programming interface (API) call request from the relying party for an assertion of an identity of a user, the user to be returned to the relying party (Suresh: para [99-101], [123], [134-138], table 1 “the processor 224 is configured to receive a web authentication API command from the relying party 203 . The processor 224 is configured to translate the web authentication API command from the relying party 203 into the authentication challenge message 205. The given client device 201a is configured to generate the web authentication API command based upon the authentication challenge message 205. The web authentication API command may comprise a WebAuthn standard authentication command, for example.”, see also para[38], ), the user associated with the smartphone device (Suresh: para [03], [43], [82-84], user's physical computing device (e.g., smartphone, laptop, desktop computer)”) ; based on receiving the API call request for the assertion from the relying party : soliciting, by the smartphone device, a biometrics of the user; receiving, by the smartphone device, the biometric of the user from the user (Suresh: para[134-138], [143], “Other parts of the user interface that involve user verification are directly presented directly locally at the client device, e.g. by the Microsoft Windows Hello dialogs “Windows Security. Making sure it's you . . . ”Making sure it's you . . . ”, working in conjunction with the platform authenticator 207, 307, and asking the user to answer the biometric authentication challenge, e.g. “Scan your finger on the fingerprint reader ”); and authenticating, by the smartphone device, the user based on the received biometric of the user relative to a reference biometric included in the smartphone device (Suresh: fig. 12, [134-138], [143], “verify user”, “Other parts of the user interface that involve user verification are directly presented directly locally at the client device, e.g. by the Microsoft Windows Hello dialogs “Windows Security. Making sure it's you . . . ”, working in conjunction with the platform authenticator 207, 307, and asking the user to answer the biometric authentication challenge, e.g. “Scan your finger on the fingerprint reader”.”, para[121-122], “The authentication answer message 206 is based upon a biometric characteristic of the user accessible from the memory 225 of the given client device 201a.”); based on a successful authentication of the user at the smartphone device : compiling by the smartphone device, an assertion packet including an attestation of the identity of the user (Suresh: fig. 13, table 1, “create assertion” para[138], “After successful user verification by the platform authenticator 207, the platform authenticator 207 creates an authentication answer message”, para[121-122], “The authentication answer message 206 is based upon a biometric characteristic of the user accessible from the memory 225 of the given client device 201a .”); and transmitting the assertion packet to the relying party (Suresh: fig. 13, “response with assertion”, para [100], [134-138], “The browser 204 then sends the authentication answer message to the relying party 203.”) . Suresh does not explicitly teach a software development kit (SDK) at the smartphone device; the API call is based on a phone number specific to the smartphone device; and that the assertion packet includes an attestation confirming authentication of the user and identity data specific to the user; singing, by the smartphone device, via the SDK, the compiled assertion with a private key of a private-public key pair stored in a memory of the smartphone device; and whereby the assertion packet permits the relying party to verify the identity data of the user based on a public key of the private public key pair, previously received from the smartphone. However, in an analogous art, Innes teaches a software development kit (SDK) at the smartphone device (Innes: para [122-127], [133-136] fig. 8, “The client device 801 may also include a Private Key Operation (PKOperation) SDK module 807 configured to process certificate operations, such as with the smart card 817. The functionality of the PKOperation SDK 807 is described in co-pending nonprovisional U.S. patent application Ser. No. 13/886,845, which is hereby incorporated by reference in its entirety. In particular, the PKOperation SDK module 807 of the client device 801 may facilitate access to a keystore that stores one or more client certificates with corresponding private keys that may be used to sign for authentication purposes. For example, the client device 801 may authorize access to or have possession of a client certificate representing the user of the client device 801. In some aspects, the certificate may be an enterprise-issued certificate.” See also fig. 6 para[0086]) Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify Suresh’s client-device authentication operation to include the client-device PKOperation SDK of Innes, such that the client device performs private-key authentication and signing operations through a client-side SDK, because it will provide client-side access to keystore, private-key operations for authentication purposes, while reducing the amount of sensitive authentication information transmitted between the client device and server and improving the efficiency, security of certificate, and signing operations (Innes: para[151]). Suresh in view of Inness does not explicitly teach the API call is based on a phone number specific to the smartphone device; and that the assertion packet includes an attestation confirming authentication of the user and identity data specific to the user; singing, by the smartphone device, via the SDK, the compiled assertion with a private key of a private-public key pair stored in a memory of the smartphone device; and whereby the assertion packet permits the relying party to verify the identity data of the user based on a public key of the private public key pair, previously received from the smartphone. However, in the related art, Baghdasaryan teaches an assertion packet includes an attestation confirming authentication of the user and identity data specific to the user (Baghdasaryan: para[37-41], [55] “the relying party 202 will accept an authentication response (sometimes referred to as a “token”) generated by the local authentication device on the client as a valid authentication response.. in response to the user initiating a transaction with the relying party 202 which requires authentication (e.g., initiating payment from the relying party's website, accessing private user account data, etc), the relying party 202 generates an authentication request which includes a random challenge (e.g., a cryptographic nonce)… In response to receipt of the authentication request, the user may be presented with a graphical user interface (GUI) requesting authentication (e.g., in the form of a web page or a GUI of an authentication application/app). The user then performs the authentication (e.g., swiping a finger on a fingerprint reader, etc). In response, the authentication client 201 generates an authentication response containing a signature over the random challenge with the private key associated with the authenticator. It may also include other relevant data such as the user ID code in the authentication response ”); singing, by the smartphone device the compiled assertion with a private key of a private-public key pair stored in a memory of the smartphone device (Baghdasaryan: Para [37-41], “the authentication client 201 generates an authentication response containing a signature over the random challenge with the private key associated with the authenticator…”, para [31-33], “the public/private key pair may be generated by the secure transaction servers 132-133. The public key may then be stored by the secure transaction servers 132-133 and the related private key may be stored in the secure storage 120 on the client.”); and whereby the assertion packet permits the relying party to verify the identity of the user based on a public key of the private public key pair, previously received from the smartphone ( Baghdasaryan: para[37-41], “Upon receipt of the authentication response, the relying party may validate the signature over the random challenge (e.g., using the public key associated with the authenticator) and confirm the identity of the user. Once authentication is complete, the user is permitted to enter into secure transactions with the relying party, as illustrated.”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to further modify Suresh, as modified by Innes, so that the authentication answer assertion response includes Baghdasaryan’s signed authentication response/token including user identity information, such as a user ID code, and a private-key signature over a relying-party challenge. A person of ordinary skill in the art would have been motivated to do so to bind the authentication response to a relying-party challenge, allow the relying party to confirm the identity of the user using a corresponding public key, and reduce the risk of replay or fraudulent authentication responses (Baghdasaryan: para[42]). Suresh in view of Inness and Baghdasaryan does not explicitly teach the API call is based on a phone number specific to the smartphone device; singing, by the smartphone device, the compiled assertion with a private key of a private-public key pair stored in a memory of the smartphone device; and whereby the assertion packet permits the relying party to verify the identity of the user based on a public key of the private public key pair, previously received from the smartphone. However, in the related art, Ross teaches API call is based on a phone number specific to the smartphone device (Ross: para[86], [99], “IDP service core (150, 250) can send a generated page of an electronic mail or other communication (e.g. text message, SMS message, page, etc.) to an application other than dID app 850 to display identity information provided by the Internet user (e.g. e-mail address, phone number, pager number), and provide instructions for the Internet user to respond and/or to confirm the registration information (e.g. e-mail address) initially supplied by the Internet user using the application other than dID app 850.”, “a pseudorandom string generated by the single IDP service core (150-N, 250-N) and transmitted to dID app 850 via an API call, and a device identifier (e.g. device name, device PIN, device IMEI, device MIN, device MAC address, device SIM card, etc.) of the device upon which dID app 850 resides.). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to further modify Suresh, as modified by Innes and Baghdasaryan, so that the API call/authentication request is based on a phone number or device-specific identifier as taught by Ross. A person of ordinary skill in the art would have been motivated to do so to bind the authentication transaction to a specific user device, confirm that the user controls the device associated with the phone number/device identifier, and reduce fraudulent or unauthorized authentication attempts (Ross: para[114]). Furthermore, Suresh also discloses the hardware components of claim 11 , such as a non-transitory computer-readable storage medium including executable instructions, which when executed by at least one processor of a communication device of the user, cause the at least one processor to: (Suresh:: para[52-53], “the non-volatile memory 30 may include: one or more hard disk drives (HDDs) or other magnetic or optical storage media; one or more solid state drives (SSDs), such as a flash drive or other solid-state storage media”), and based on an interaction between a network-based application included in the smartphone and a website of a relying party (Suresh: para[03], [119], “An application 204 within the virtualized session 208 performs an authentication operation 223 with the relying party 203 to access a resource. For example, the application 204 comprises a web browser application, a native application operating within the virtualized session 208, or an interface for a local resource .”, “user's physical computing device (e.g., smartphone, laptop, desktop computer)”). As per claims 4 and 14, Suresh in view of Innes, Baghdasaryan and Ross teaches the dependent claim 1. Ross teaches wherein the attestation of the identity of the user includes at least a name and an address associated with the user Ross: para[86], [99], “IDP service core (150, 250) can send a generated page of an electronic mail or other communication (e.g. text message, SMS message, page, etc.) to an application other than dID app 850 to display identity information provided by the Internet user (e.g. e-mail address, phone number, pager number), and provide instructions for the Internet user to respond and/or to confirm the registration information (e.g. e-mail address) initially supplied by the Internet user using the application other than dID app 850.”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to further modify Suresh, as modified by Innes and Baghdasaryan, so that the API call/authentication request is based on a phone number or device-specific identifier as taught by Ross. A person of ordinary skill in the art would have been motivated to do so to bind the authentication transaction to a specific user device, confirm that the user controls the device associated with the phone number/device identifier, and reduce fraudulent or unauthorized authentication attempts (Ross: para[114]). As per claims 5 and 15, Suresh in view of Innes, Baghdasaryan and Ross teaches the dependent claim 1. Suresh additionally teaches wherein receiving the biometric of the user includes capturing, by the smartphone device, the biometric of the user (Suresh: para [143], “Other parts of the user interface that involve user verification are directly presented directly locally at the client device, e.g. by the Microsoft Windows Hello dialogs “Windows Security. Making sure it's you . . . ”, working in conjunction with the platform authenticator 207, 307, and asking the user to answer the biometric authentication challenge, e.g. “Scan your finger on the fingerprint reader”.). Baghdasaryan teaches wherein authenticating the user includes matching, by the smartphone device, the captured biometric to a reference biometric associated with the user ; and wherein the successful authentication includes the captured biometric matching the reference biometric (Baghdasaryan: para[55], “in response to the authentication request sent from the relying party, the authentication client 410 prompts the user to perform authentication using one or more specified authentication devices 420-421 (if explicit authentication is required). If the user successfully authenticates (e.g., swipes a registered finger on a fingerprint authenticator), then the authentication client 410 sends back an authentication response indicating a successful authentication.”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to further modify Suresh, as modified by Innes, so that the authentication answer assertion response includes Baghdasaryan’s signed authentication response/token including user identity information, such as a user ID code, and a private-key signature over a relying-party challenge. A person of ordinary skill in the art would have been motivated to do so to bind the authentication response to a relying-party challenge, allow the relying party to confirm the identity of the user using a corresponding public key, and reduce the risk of replay or fraudulent authentication responses (Baghdasaryan: para[42]). As per claims 6 and 16, Suresh in view of Innes, Baghdasaryan and Ross teaches the dependent claim 5. Suresh additionally teaches wherein the biometric includes one of a fingerprint of the user and a voiceprint of the user (Suresh: para [143], “Other parts of the user interface that involve user verification are directly presented directly locally at the client device, e.g. by the Microsoft Windows Hello dialogs “Windows Security. Making sure it's you . . . ”, working in conjunction with the platform authenticator 207, 307, and asking the user to answer the biometric authentication challenge, e.g. “Scan your finger on the fingerprint reader”.”). As per claim 9, Suresh in view of Innes, Baghdasaryan and Ross teaches the independent claim 1. Innes teaches wherein the communication device includes an application, which incorporates the SDK (Innes: para[0086], “A software development kit 584 may provide a user the capability to secure applications selected by the user by wrapping the application as described previously in this description. An application that has been wrapped using the software development kit 584 may then be made available to the mobile device 502 by populating it in the application store 578 using the application controller 574.”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify Suresh’s client-device authentication operation to include the client-device PKOperation SDK of Innes, such that the client device performs private-key authentication and signing operations through a client-side SDK, because it will provide client-side access to keystore, private-key operations for authentication purposes, while reducing the amount of sensitive authentication information transmitted between the client device and server and improving the efficiency, security of certificate, and signing operations (Innes: para[151]). As per claims 10 and 19, Suresh in view of Innes, Baghdasaryan and Ross teaches the dependent claim 9. Baghdasaryan teaches wherein the application includes a banking application (Baghdasaryan s: para[20], [25] “The term “local” is used herein to refer to the fact that the user is completing a transaction in person, at a particular location such as at an automatic teller machine (ATM) or a point of sale (POS) retail checkout location…. The authentication devices 110-112 are communicatively coupled to the client through an interface 102 (e.g., an application programming interface or API) exposed by a secure transaction service 101”); and wherein the user is associated with an account issued by the banking institution, whereby the application is usable to access information about the account (Baghdasaryan: para [38], “t Turning to the specific details shown in FIG. 3, in response to the user initiating a transaction with the relying party 202 which requires authentication (e.g., initiating payment from the relying party's website, accessing private user account data, etc),”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to further modify Suresh, as modified by Innes, so that the authentication answer assertion response includes Baghdasaryan’s signed authentication response/token including user identity information, such as a user ID code, and a private-key signature over a relying-party challenge. A person of ordinary skill in the art would have been motivated to do so to bind the authentication response to a relying-party challenge, allow the relying party to confirm the identity of the user using a corresponding public key, and reduce the risk of replay or fraudulent authentication responses (Baghdasaryan: para[42]). As per claim 18, Suresh in view of Innes, Baghdasaryan and Ross teaches the independent claim 11. Suresh teaches wherein the network-based application is a browser, and wherein the interaction is between the browser and a website of the relying party (Suresh: para[39-42], “All these components are needed to authenticate to a website that has WebAuthn enabled...this disclosure relates to a biometric authentication framework that leverages the crypto-processor (e.g. a TPM 2.0) at a client device (desktop computing device, mobile device, or a trusted multi-hop with Citrix Workspace App (CWA)) to provide biometric authentication services to hosted browsers and native applications”) . 07-21-aia AIA Claim s 7-8, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Suresh et al. (U.S. Pub. 20200374284 A1; Hereinafter “Suresh”) in view of Innes et al. (U.S.Pub. 20180007059 A1; Hereinafter “Innes”), Baghdasaryan (U.S. Pub. 2017/0109509 A1; Hereinafter “Baghdasaryan”), Ross et al. (U.S. Pub. 20190334884 A1; Hereinafter “Ross”), and Avetisov et al. (U.S. 20200067907 A1; Hereinafter “Avetisov”) . As per claims 7 and 17, Suresh in view of Innes, Baghdasaryan and Ross teaches the independent claim 1. Suresh in view of Innes, Baghdasaryan and Ross does not teach, however, in the related art Avetisov teaches prior to receiving the request from the relying party: generating, by the smartphone device, the private-public key pair (Avetisov: para[229-235], “the TEE 103 may generate one or more keys, and one or more of those keys may be bound to a received identifier. The TEE 103 may generate a public key and a private key of a key pair, which may be bound to the received identifier.”); compiling, by the Smartphone device, a credential packet including the public key of the private-public key pair and identity data associated with the user (Avetisov: Para [0235] figure 3 “The authentication application 120 receives data output from the TEE 103, which may include representations of credentials, signed data corresponding to those representations, and signature key (e.g., a public key) for verifying signed data output by the TEE 103”); and transmitting the credential packet to the relying party (Avetisov: Para [0235] & Para [0237] “The data and signed data are provided to the authentication application 120, which transmits the data and signed data to a server for authentication”), whereby the relying party is registered to the SDK to request assertions from the SDK of an identity of the user (Avetisov: Para[0081], [0196] “An example SDK may be used by application 225 developers to incorporate functionality (e.g., similar to that of an authentication application) affording interoperability with the identity management system within the application. Such functionality may include one or more modules or computer program code for exchanging data with a TEE of a mobile device 101 over a secure channel,”). It would have been obvious, for one of ordinary skills in the art, to have update the modified Suresh and include the attestation of the user, as it is a security measure that validates the identity of the user trying to connect to a network, and protects against fraud. As per claim 8 , Suresh in view of Innes, Baghdasaryan, Ross and Avetisov teaches the dependent claim 7. Avetisov teaches storing the private key in a trusted execution environment (TEE) of the communication device (Avetisov: para[0062], “the trusted execution environment 103, with the TEE coprocessor 105, may execute a process to generate or otherwise store one or more encryption keys 108, which may include one or more keys from a key-pair, such as a pairing of a private encryption key and a public encryption key. One or more generated keys 108, such as generated private keys, may be protected within the trusted execution environment, such as within the TEE memory 107.”); and signing the assertion packet with the private key from the TEE of the communication device (Avetisov: para[0267], “in some embodiments, those results are structured and signed by private signature of an authority (or controlling relying party) as proof of authentication, by which a terminal or electro-mechanical device may perform an action subject to signature verification based on the results and signed results when presented by the mobile device.”). It would have been obvious, for one of ordinary skills in the art, to have update the modified Suresh and include the attestation of the user, as it is a security measure that validates the identity of the user trying to connect to a network, and protects against fraud. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Alexander Lagor can be reached on (571)-270-5143. 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. /L.L.N./ Examiner, Art Unit 2437 /ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437 Application/Control Number: 18/131,310 Page 2 Art Unit: 2437 Application/Control Number: 18/131,310 Page 3 Art Unit: 2437 Application/Control Number: 18/131,310 Page 4 Art Unit: 2437 Application/Control Number: 18/131,310 Page 5 Art Unit: 2437 Application/Control Number: 18/131,310 Page 6 Art Unit: 2437 Application/Control Number: 18/131,310 Page 7 Art Unit: 2437 Application/Control Number: 18/131,310 Page 8 Art Unit: 2437 Application/Control Number: 18/131,310 Page 9 Art Unit: 2437 Application/Control Number: 18/131,310 Page 10 Art Unit: 2437 Application/Control Number: 18/131,310 Page 11 Art Unit: 2437 Application/Control Number: 18/131,310 Page 12 Art Unit: 2437 Application/Control Number: 18/131,310 Page 13 Art Unit: 2437 Application/Control Number: 18/131,310 Page 14 Art Unit: 2437 Application/Control Number: 18/131,310 Page 15 Art Unit: 2437 Application/Control Number: 18/131,310 Page 16 Art Unit: 2437 Application/Control Number: 18/131,310 Page 17 Art Unit: 2437 Application/Control Number: 18/131,310 Page 18 Art Unit: 2437
Prosecution Insights