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 .
Status of claims
This office action is in response to claims filed on 06/22/2026
Claims 1-6, 8-17 and 19-22 are pending and rejected; claim 1,12 and 20 are independent claim; claims 7 and 18 are canceled.
Response to Arguments
Applicant's arguments filed on 06/22/2026 have been fully considered but they are not persuasive.
With respect to applicants argument: The cited references, singly or in any proper combination, do not disclose and would not have rendered obvious "authenticating, by authentication circuitry, the recipient based on a recipient mobile driver's license (mDL) associated with the recipient,"
Examiner respectfully disagree with applicant’s argument for the following reasons: Peterson discloses (see Petersen Fig. 4A-4B and ¶¶8-9 108, recipient, or user B for example, may be identified via one or more identifiers, such as a name, a username, a numerical code, and/or the like. In some embodiments, the digital asset transfer query comprises an identifier token associated with the recipient and configured to identify the recipient for the account management system 102 [i.e. authenticating the recipient]; ¶¶33 56, the identifier token uses single-sign-on (SSO) authentication techniques to identify the end user; ¶¶113-114, 117 Claims 1-3, the first identifier token is configured to cause one or more digital asset user accounts associated with the first end user to be identified, and wherein the second identifier token is configured to cause one or more digital asset user accounts associated with the second end user to be identified; ¶¶44, 46, on-chain transaction record data object is committed to a distributed ledger for processing (e.g., authentication, verification, validation, acceptance) of the on-chain transaction.. on-chain transaction record data object is configured to describe at least a number of digital asset units of the on-chain transaction,…, an on-chain transaction record data object identifies the sender and recipient via cryptographic keys and/or key references associated with each of the sender and recipient … In various examples, an on-chain transaction record data object comprises one or more hash values enabling the authenticity and security of the on-chain transaction record data object to be publicly verified [i.e. disclosing when transaction including sender and recipient authenticity and asset transfer condition satisfied]. And Hanson discloses, (see Hanson Fig. 7 and ¶68, the verification engine 720 [i.e. authentication circuitry] may apply the issuing authority credentialing standard to the proffered digital credential to verify the identity of the end user 704 [i.e. recipient]. As noted above, this may include verification of the validity, authenticity, and originality of the digital credential provided as well as potential matching of biometric information from the end user 704 with biometric information contained in the digital credential. Accordingly, the verification engine 720 may comprise hardware, software, and/or firmware adapted to perform secure computing (e.g., using a TPM, HSM, or other secure processor). ¶20, digital credentials for identity verification…including mobile driving license(MDL)). Disclose the recited claim limitation.
With respect to applicants argument: The cited references, singly or in any proper combination, do not disclose and would not have rendered obvious "authenticating, by authentication circuitry, the sender based on a sender mobile driver's license (mDL) associated with the sender,"
Examiner respectfully disagree with applicant’s argument for the following reasons: Peterson discloses (see Petersen Fig. 4A-4B and ¶¶8-9 113, The account management system 102 may, for example, locate and process an identifier token associated with the sender in order to identify one or more digital asset user accounts associated with the sender. [i.e. authenticating the sender]; ¶¶33 56, the identifier token uses single-sign-on (SSO) authentication techniques to identify the end user; ¶¶113-114, 117 Claims 1-3, the first identifier token is configured to cause one or more digital asset user accounts associated with the first end user to be identified, and wherein the second identifier token is configured to cause one or more digital asset user accounts associated with the second end user to be identified; ¶¶44, 46, on-chain transaction record data object is committed to a distributed ledger for processing (e.g., authentication, verification, validation, acceptance) of the on-chain transaction.. on-chain transaction record data object is configured to describe at least a number of digital asset units of the on-chain transaction,…, an on-chain transaction record data object identifies the sender and recipient via cryptographic keys and/or key references associated with each of the sender and recipient … In various examples, an on-chain transaction record data object comprises one or more hash values enabling the authenticity and security of the on-chain transaction record data object to be publicly verified [i.e. disclosing when transaction including sender and recipient authenticity and asset transfer condition satisfied]. And Hanson discloses, (see Hanson Fig. 7 and ¶68, the verification engine 720 [i.e. authentication circuitry] may apply the issuing authority credentialing standard to the proffered digital credential to verify the identity of the end user 704 [i.e. sender]. As noted above, this may include verification of the validity, authenticity, and originality of the digital credential provided as well as potential matching of biometric information from the end user 704 with biometric information contained in the digital credential. Accordingly, the verification engine 720 may comprise hardware, software, and/or firmware adapted to perform secure computing (e.g., using a TPM, HSM, or other secure processor). ¶20, digital credentials for identity verification…including mobile driving license(MDL)). Disclosing the recited claim limitation.
With respect to applicant’s argument: The cited references, singly or in any proper combination, do not disclose and would not have rendered obvious "in response to successfully authenticating both the recipient and the sender, effectuating, by the transfer management circuitry, a transfer of the asset from the sender account to the recipient account", as recited in amended claim 1.
Examiner respectfully disagree with applicant argument for the following reasons: Peterson discloses, (see Petersen Figs. 4A-4B and ¶¶44, 46, 108, 114, 127-128, 142-144, if the defined outbound digital asset transfer satisfies the transfer conditions [i.e.in response to successfully authenticating both recipient and sender]… processing and executing an outbound digital asset transfer [i.e. a transfer of the asset from the sender account to the recipient account] ). Disclosing the recited claim limitations.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
In Claim 20:
“means for receiving an asset transfer initiation request from a sender device, wherein the asset transfer initiation request comprises an indication of an asset to transfer and a sender account identifier associated with a sender account of a sender”
“means for receiving an indication of a recipient intended to receive the asset”
“means for selecting a recipient account associated with the recipient”
“means for authenticating the recipient based on a recipient mobile driver’s license (mDL) associated with the recipient”
“means for authenticating the sender based on a recipient mobile driver’s license (mDL) associated with the sender”
“means for, in response to successfully authenticating the recipient, effectuating a transfer of the asset from the sender account to the recipient account”.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 5-6, 11-12 16-17, 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over Petersen et al. US Pub. No.: 2022/0188917 A1 (hereinafter Petersen) in view of Hanson et al. US Pub. No.: 2024/0193245 A1(hereinafter Hanson).
Petersen teaches:
As to claim 1, a method for secure peer-to-peer asset transfer, the method comprising: receiving, by communications hardware, an asset transfer initiation request from a sender device, wherein the asset transfer initiation request comprises an indication of an asset to transfer and a sender account identifier associated with a sender account of a sender (see Petersen Fig. 4A and ¶¶30 106, receiving a digital asset transfer query originating from a first client device 104A associated with user A [i.e. sender account identifier] and defining an outbound digital asset transfer of a digital asset from user A to user B… ¶110, Process 400 then comprises steps/operations for retrieving and/or receiving user account data for both the sender and the recipient identified for the digital asset transfer (e.g., the outbound digital asset transfer) ; ¶113, the sender (e.g., user A) is identified by the account management system 102 based at least in part on the digital asset transfer query originating from the first client device 104A associated with the sender [i.e. receiving by the communication hardware/management system an indication of an asset to transfer and sender account identifier/104A]] )
receiving, by the communications hardware, an indication of a recipient intended to receive the asset ( see Petersen Fig. 4A ¶108, digital asset transfer query comprises an indication of a recipient for the outbound digital asset transfer. The recipient, or user B for example, may be identified via one or more identifiers, such as a name, a username, a numerical code, and/or the like… the digital asset transfer query comprises an identifier token associated with the recipient and configured to identify the recipient for the account management system 102);
selecting, by transfer management circuitry, a recipient account associated with the recipient (see Petersen Fig. 4A ¶110, the digital asset transfer query defines a particular digital asset user account specific to the digital asset that the sender has selected to be debited during the outbound digital asset transfer [i.e. selecting recipient account]; ¶113, account management system 102…, the digital asset transfer query defines a particular digital asset user account specific to the digital asset that the sender has selected to be debited during the outbound digital asset transfer; ¶6 10 35, identifying and providing alternative digital asset transfer to a recipient of a digital asset transfer (e.g., the end user to be credited with digital asset units). Such alternative digital asset transfers provide optionality and choice to a recipient );
in response to successfully authenticating both the recipient and the sender, effectuating, by the transfer management circuitry, a transfer of the asset from the sender account to the recipient account (see Petersen Figs. 4A-4B and ¶¶44, 46, 108, 114, 127-128, 142-144, if the defined outbound digital asset transfer satisfies the transfer conditions [i.e.in response to successfully authenticating both recipient and sender]… processing and executing an outbound digital asset transfer [i.e. a transfer of the asset from the sender account to the recipient account] )
Even if Petersen teaches:
authenticating, the recipient (see Petersen Fig. 4A-4B and ¶¶8-9 108, recipient, or user B for example, may be identified via one or more identifiers, such as a name, a username, a numerical code, and/or the like. In some embodiments, the digital asset transfer query comprises an identifier token associated with the recipient and configured to identify the recipient for the account management system 102 [i.e. authenticating the recipient]; ¶¶33 56, the identifier token uses single-sign-on (SSO) authentication techniques to identify the end user; ¶¶113-114, 117 Claims 1-3, the first identifier token is configured to cause one or more digital asset user accounts associated with the first end user to be identified, and wherein the second identifier token is configured to cause one or more digital asset user accounts associated with the second end user to be identified);
authenticating, the sender (see Petersen Figs. 4A-4B and ¶¶8-9, 44, 46, on-chain transaction record data object is committed to a distributed ledger for processing (e.g., authentication, verification, validation, acceptance) of the on-chain transaction.. on-chain transaction record data object is configured to describe at least a number of digital asset units of the on-chain transaction,…, an on-chain transaction record data object identifies the sender and recipient via cryptographic keys and/or key references associated with each of the sender and recipient … In various examples, an on-chain transaction record data object comprises one or more hash values enabling the authenticity and security of the on-chain transaction record data object to be publicly verified [i.e. when transaction including sender and recipient authenticity and asset transfer condition satisfied];)
Peterson does not explicitly teach but the related art Hanson teaches:
authenticating, by authentication circuitry, based on a recipient mobile driver’s license (mDL) associated with the recipient (see Hanson Fig. 7 and ¶68, the verification engine 720 [i.e. authentication circuitry] may apply the issuing authority credentialing standard to the proffered digital credential to verify the identity of the end user 704 [i.e. recipient]. As noted above, this may include verification of the validity, authenticity, and originality of the digital credential provided as well as potential matching of biometric information from the end user 704 with biometric information contained in the digital credential. Accordingly, the verification engine 720 may comprise hardware, software, and/or firmware adapted to perform secure computing (e.g., using a TPM, HSM, or other secure processor). ¶20, digital credentials for identity verification…including mobile driving license(MDL))
authenticating, by the authentication circuitry, the sender based on a sender MDL associated with the sender ((see Hanson Fig. 7 and ¶68, the verification engine 720 [i.e. authentication circuitry] may apply the issuing authority credentialing standard to the proffered digital credential to verify the identity of the end user 704 [i.e. sender]. As noted above, this may include verification of the validity, authenticity, and originality of the digital credential provided as well as potential matching of biometric information from the end user 704 with biometric information contained in the digital credential. Accordingly, the verification engine 720 may comprise hardware, software, and/or firmware adapted to perform secure computing (e.g., using a TPM, HSM, or other secure processor). ¶20, digital credentials for identity verification…including mobile driving license(MDL)))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Peterson to include an authentication circuitry to authenticate the recipient/sender based on mobile driver’s license (MDL) as disclosed by Hanson. The motivation for doing so would have been to adopt a standard by accredited identity issuing authorities around the world based on reusable digital identification to provide relying parties with a cost-effective and accurate way to verify identity while enabling end-user control over the use of their identities (see Hanson ¶4).
As to claim 5, the combination of Petersen and Hanson teaches the method of claim 1, wherein authenticating the recipient further comprises:
receiving, by the communications hardware, an authorization selection from the sender device, wherein the authorization selection is indicative of sender’s feedback to proceed with authentication of the recipient based on the recipient mDL (see Hanson ¶50, authentication of the user credentials and verification of the identity of the user is received, as indicated in illustrations 416 and 426, two different results may be displayed on each of the identity verification device and the user device; ¶52, application may present multiple digital identification documents for selection and use depending upon the circumstance [i.e. wherein the authorization selection is indicative of sender’s feedback to proceed with authentication of the recipient based on the recipient mDL]; ¶¶20 23-24 29, [i.e. request to verification of authentication credentials including mobile driving license (mDL)]; ¶54, authentication of the user credentials and verification of the identity of the user is received by the identity verification device; ) ; and
authenticating, by the authentication circuitry, the recipient based on the recipient mDL in response to receiving the authorization selection from the sender device (see Hanson Fig. 7 and ¶68, the verification engine 720 [i.e. authentication circuitry] may apply the issuing authority credentialing standard to the proffered digital credential to verify the identity of the end user 704 [i.e. recipient]. As noted above, this may include verification of the validity, authenticity, and originality of the digital credential provided as well as potential matching of biometric information from the end user 704 with biometric information contained in the digital credential. Accordingly, the verification engine 720 may comprise hardware, software, and/or firmware adapted to perform secure computing (e.g., using a TPM, HSM, or other secure processor). ¶20, digital credentials for identity verification…including mobile driving license(MDL); 50, authentication of the user credentials and verification of the identity of the user is received, as indicated in illustrations 416 and 426, two different results may be displayed on each of the identity verification device and the user device; ¶52, application may present multiple digital identification documents for selection and use depending upon the circumstance [i.e. wherein the authorization selection is indicative of sender’s feedback to proceed with authentication of the recipient based on the recipient mDL]).
Similar rational applies as above to combine the cited prior art references.
As to claim 6, the combination of Petersen and Hanson teaches the method of claim 1, further comprising:
receiving, by the communications hardware, a candidate recipient identification request from the sender device, wherein the candidate recipient identification request comprises a location of the sender device (see Hanson ¶70, The identification verification device 750 provides an example of a local device at a POS setting or other location that may include a verification endpoint 752);
identifying, by the transfer management circuitry, one or more candidate recipient identifiers, wherein each candidate recipient identifier is associated with a candidate recipient device located within a predefined proximity of the location of the sender device (see Hanson ¶¶41 70, identity verification device 754 illustrates a local device at a POS setting that may coordinate with the verification endpoint 752 of the verification platform 708 to perform a remote verification operation) in addition (see Petersen ¶89, the client device 104 may include location determining aspects, devices, modules, functionalities, and/or similar words used herein interchangeably… such technologies may include the iBeacons, Gimbal proximity beacons, Bluetooth Low Energy (BLE) transmitters, NFC transmitters, and/or the like [i.e. candidate recipient identifier is located within a predefined proximity of the location of sender device]); and
providing, by the communications hardware, the one or more candidate recipient identifiers to the sender device (see Hanson ¶70, The identification verification device 750 provides an example of a local device at a POS setting or other location that may include a verification endpoint 752 [i.e. recipient identifiers to the sender device]).
Similar rational applies as above to combine the cited prior art references.
As to claim 7, (canceled)
As to claim 11, the method of claim 1, wherein authenticating the sender further comprises:
receiving, by the communications hardware, an authorization selection from a recipient device, wherein the authorization selection is indicative of recipient’s feedback to proceed with authentication of the sender based on the sender mDL (see Hanson ¶50, authentication of the user credentials and verification of the identity of the user is received, as indicated in illustrations 416 and 426, two different results may be displayed on each of the identity verification device and the user device; ¶54, authentication of the user credentials and verification of the identity of the user is received by the identity verification device ; ¶52, application may present multiple digital identification documents for selection and use depending upon the circumstance; [i.e. wherein the authorization selection is indicative of recipient’s feedback to proceed with authentication of the sender] ¶¶20 23-24 29, [i.e. request to verification of authentication credentials including mobile driving license (mDL)); and
authenticating, by the authentication circuitry, the sender based on the sender MDL in response to receiving the authorization selection from the recipient device (see Hanson Fig. 7 and ¶68, the verification engine 720 [i.e. authentication circuitry] may apply the issuing authority credentialing standard to the proffered digital credential to verify the identity of the end user 704 [i.e. sender]. As noted above, this may include verification of the validity, authenticity, and originality of the digital credential provided as well as potential matching of biometric information from the end user 704 with biometric information contained in the digital credential. Accordingly, the verification engine 720 may comprise hardware, software, and/or firmware adapted to perform secure computing (e.g., using a TPM, HSM, or other secure processor). ¶20, digital credentials for identity verification…including mobile driving license(MDL)). ¶52, application may present multiple digital identification documents for selection and use depending upon the circumstance; [i.e. in response to receiving the authorization selection from the recipient device]
Similar rational applies as above to combine the cited prior art references.
As to claim 21, the combination of Petersen and Hanson discloses the method of claim 1, further comprising: logging, by the transfer management circuitry, a sender account record and a recipient account record with transfer details associated with the transfer of the asset, wherein the transfer details comprise at least an indication of whether both the recipient and the sender were successfully authenticated (see Hanson Fig. 7 and ¶73, the verification platform 708 may maintain audit logs 722 regarding verification operations performed. Such audit log 722 may provide compliance verification for end user 704 and/or relying party 706 [i.e. a sender account record and a recipient account record] utilizing the verification platform 708 [i.e. by the transfer management circuitry] as an intermediary for verification of digital identities [i.e. an indication of whether both the recipient and the sender were successfully authenticated]; ¶¶76, verification operations performed by the verification endpoint 752 at the verification platform 708 may be stored in the audit log 722. These operations may include verification operations initiated through the user device communication interface 714 and/or relying party communication interface 712 as well as operations initiated through the identity verification device 754).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Peterson to include logging transfer details comprising at least an indication of whether both the recipient and the sender were successfully authenticated, as disclosed by Hanson. The motivation for doing so would have been to provide verification record for both relying parties and/or end users (see Hanson ¶73).
As to independent claim 12, this claim directed to an apparatus executing the method of claim 1; therefore it is rejected along similar rationale.
As to independent claim 20, this claim directed to a system executing the method of claim 1; therefore it is rejected along similar rationale.
As to dependent claims 16-17, these claims contain substantially similar subject matter as claims 5-6; therefore they are rejected along the same rationale.
As to dependent claim 22, this claims contain substantially similar subject matter as claim 21; therefore it is rejected along the same rationale.
Claim(s) 2-4, 8-10, 13-15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Petersen in view of Hanson and further in view of Washington et al. US Pub.: 2021/0261272 A1 (hereinafter Washington)
As to claim 2, the combination of Peterson and Hanson teaches the method of claim 1, wherein authenticating the recipient further comprises:
receiving, by the communications hardware, a recipient mDL authentication request from the sender device, wherein the recipient mDL authentication request is a request to authenticate the recipient mDL associated with the recipient (see Hanson Fig. 7 and ¶79, the relying party 806 [i.e. sender device] may communicate a verification [i.e. send/receive] request 816 to the verification endpoint 808 [i.e. the communications hardware]. The verification request 816 may include information regarding the end user 804 [i.e. recipient] from which the access request 814 is received [i.e. to authenticate the recipient]; ¶¶20 23-24 29, [i.e. request to verification of authentication credentials including mobile driving license (mDL) ]) ;
generating, by the authentication circuitry and based on the recipient mDL authentication request, a recipient digital token (see Hanson Fig. 7 and ¶¶ 98, the verification engine [i.e. authentication circuitry] are executable by the verification server to perform the verification operation and generate the verification log; ¶100, receiving a request for verification of a human user's identity from a relying party generating a non-repudiable token of the verification operation [i.e. generating digital token] based on demographic data and biometric data; and storing the non-repudiable token in a verification log; and ¶¶20 23-24 29 [i.e. based on the recipient mDL])
the combination of Petersen over Hanson does not explicitly teach but the related art Washington discloses:
transmitting, by the communications hardware, the recipient digital token to an issuing authority (IA) system associated with an IA that provisioned the recipient mDL to the recipient (see Washington ¶80, The travel carrier [i.e. communications hardware] also sends a copy of the token to an authorizing source [i.e. issuing authority], such as an issuer of the traveler's digital identity (e.g., a Department of Motor Vehicles)) ;
receiving, by the communications hardware and from the IA system, a recipient mDL validity response, wherein the recipient mDL validity response is generated based on the recipient digital token (see Washington ¶80, The commercial entity and the authorizing source [i.e. issuing authority] then compare tokens, and upon matching, the authorizing source verifies that the transaction is trusted and authorizes the commercial entity to release to the travel carrier the unlock code corresponding to that traveler's digital identity [i.e. mDL validity response is granted based on the recipient digital token]), and
wherein the recipient mDL validity response indicates verified credential data associated with the recipient mDL (see Washington ¶80, the token passes from the digital identity to the travel carrier for that bag, and then the travel carrier matches the token to the authorizing source, and retrieves the unlock code) ; and
authenticating, by the authentication circuitry, the recipient based on the recipient mDL validity response (see Washington ¶80, the token passes from the digital identity to the travel carrier for that bag, and then the travel carrier matches the token to the authorizing source, and retrieves the unlock code).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the combination of Peterson and Hanson to include to transmit the authentication token to authorizing authority for verification of mDL. The motivation for doing so would have been to perform verification using a token associated with the mDL (or digital identity) credential to serve as the authentication to the secured applications by relying on the issuing authority (IA). (see Washington ¶¶92-93).
As to claim 3, the combination of Petersen, Hanson and Washington discloses the combination of Petersen, Hanson and Washington discloses the method of claim 2, wherein the recipient mDL authentication request comprises one or more of recipient identification data, desired credential data associated with the recipient mDL, or user attribute data associated with the recipient (see Hanson ¶42, identity verification device 300 may additionally include one or more biometric information sensors, which may be used as part of the identity verification process, e.g., to confirm that the human user presenting the digital identity document or credential is, in fact, the human associated with the digital credential [i.e. associated with recipient mDL authentication request])
As to claim 4, the combination of Petersen, Hanson and Washington discloses the combination of Petersen, Hanson and Washington discloses the method of claim 3, wherein the recipient mDL validity response further indicates verified recipient device identification data related to a recipient device (see Hanson ¶41, identity verification device 300 may further include a sensor imager 324, e.g., an infrared image reader (“barcode scanner”), for scanning one- and two-dimensional image codes [i.e. data related to recipient device when recipient mDL validity response/request])
As to claim 8, the combination of Peterson and Hanson teaches the method of claim 1, wherein authenticating the sender further comprises:
receiving, by the communications hardware, a sender mDL authentication request from a recipient device, wherein the sender mDL authentication request is a request to authenticate the sender mDL associated with the sender (see Hanson Fig. 7 and ¶79, the relying party 806 [i.e. sender device] may communicate a verification [i.e. send/receive] request 816 to the verification endpoint 808 [i.e. the communications hardware]. The verification request 816 may include information regarding the end user 804 [i.e. sender] from which the access request 814 is received [i.e. to authenticate the sender]; ¶¶20 23-24 29, [i.e. request to verification of authentication credentials including mobile driving license (mDL) ]) and ((see Petersen ¶¶33 56, the identifier token uses single-sign-on (SSO) authentication techniques to identify the end user; ¶¶113, 117 Claims 1-3, the first identifier token is configured to cause one or more digital asset user accounts associated with the first end user to be identified, and wherein the second identifier token is configured to cause one or more digital asset user accounts associated with the second end user to be identified; ¶114, account management system 102 may, for example, locate and process an identifier token associated with the sender in order to identify one or more digital asset user accounts associated with the sender);
generating, by the authentication circuitry and based on the sender mDL authentication request, a digital token (see Hanson Fig. 7 and ¶¶ 98, the verification engine [i.e. authentication circuitry] are executable by the verification server to perform the verification operation and generate the verification log; ¶100, receiving a request for verification of a human user's identity from a relying party generating a non-repudiable token of the verification operation [i.e. generating digital token] based on demographic data and biometric data; and storing the non-repudiable token in a verification log; and ¶¶20 23-24 29 [i.e. based on the sender mDL]);
the combination of Petersen over Hanson does not explicitly teach but the related art Washington discloses:
transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the sender mDL to the sender (see Washington ¶80, The travel carrier [i.e. communications hardware] also sends a copy of the token to an authorizing source [i.e. issuing authority], such as an issuer of the traveler's digital identity (e.g., a Department of Motor Vehicles););
receiving, by the communications hardware and from the IA system, a sender mDL validity response, wherein the sender mDL validity response is generated based on the digital token, and wherein the sender mDL validity response indicates verified credential data associated with the sender mDL (see Washington ¶80, The commercial entity and the authorizing source [i.e. issuing authority] then compare tokens, and upon matching, the authorizing source verifies that the transaction is trusted and authorizes the commercial entity to release to the travel carrier the unlock code corresponding to that traveler's digital identity [i.e. mDL validity response is granted based on the recipient digital token]); and
authenticating, by the authentication circuitry, the sender based on the sender mDL validity response (see Washington ¶80, the token passes from the digital identity to the travel carrier for that bag, and then the travel carrier matches the token to the authorizing source, and retrieves the unlock code).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the combination of Peterson and Hanson to include to transmit the authentication token to authorizing authority for verification of mDL. The motivation for doing so would have been to perform verification using a token associated with the mDL (or digital identity) credential to serve as the authentication to the secured applications by relying on the issuing authority (IA). (see Washington ¶¶92-93).
As to claim 9 the combination of Petersen, Hanson and Washington discloses the combination of the method of claim 8, wherein the sender mDL authentication request comprises one or more of sender identification data, desired credential data associated with the sender mDL, or user attribute data associated with the sender (see Hanson ¶42, identity verification device 300 may additionally include one or more biometric information sensors, which may be used as part of the identity verification process, e.g., to confirm that the human user presenting the digital identity document or credential is, in fact, the human associated with the digital credential [i.e. associated with sender mDL authentication request]).
As to claim 10, the combination of Petersen, Hanson and Washington discloses the method of claim 9, wherein the sender mDL validity response further indicates verified sender device identification data related to the sender device (see Hanson ¶41, identity verification device 300 may further include a sensor imager 324, e.g., an infrared image reader (“barcode scanner”), for scanning one- and two-dimensional image codes [i.e. data related to recipient device when recipient mDL validity response/request]).
As to dependent claims 13-15, these claims contain substantially similar subject matter as claims 2-4; therefore are rejected along the same rationale.
As to dependent claim 19, these claims contain substantially similar subject matter as claim 8; therefore are rejected along the same rationale.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NEGA WOLDEMARIAM whose telephone number is (571)270-7478. The examiner can normally be reached Monday to Friday, 8am-5pm.
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, Cathy Thiaw can be reached at 5712701138. 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.
NEGA . WOLDEMARIAM
Examiner
Art Unit 2407
/N.W/ Examiner, Art Unit 2407
/Catherine Thiaw/ Supervisory Patent Examiner, Art Unit 2407 7/31/2026
Prosecution Insights