DETAILED ACTION
This action is in response to the application filed on September 25, 2024. Claims 1-20 are pending. Of such, claims 1-20 represent a method directed to anonymous device fingerprinting for device verification.
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 .
Claim Objections
Claims 4, 8, 14, and 18 are objected to because of the following informalities:
Claims 4 and 14: The term “mobile app” should be expanded to “mobile application” for clarity.
Claims 8 and 18: The term “app” should be expanded to “application” for clarity.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 4-8, 10-11, 14-15, 17-18, and 20 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated over Grajek et al. (US 20180124039), hereinafter referred to as Grajek.
Regarding Claim 1, Grajek discloses:
A method, comprising: causing generation of a fingerprint for a device (In ¶ 66, Grajek discloses “User device in block 307 executes the capture instructions to gather unique device, software, operating system, and/or user characteristics.” Wherein the captured chrematistics are representative of the device fingerprint); causing sending of the fingerprint, along with a device verification request, to a device fingerprinting server, wherein the device verification request comprises a secure context identifier for a user of the device; (In ¶ 88, Grajek discloses “The entity that requested authentication, for example the target application, may send, via the redirect to the authentication system 102, information requesting authentication using an additional device-based fingerprinting factor. For example, it may send a cookie or other token to the user computing device that may then be sent from the user computing device to the authentication system, and may comprise a number of different elements and information.” And further in ¶ 89 “the information sent from the network resource to the authentication system 102 may comprise, for example, a user identifier such as a user ID”) in response to the device fingerprint server determining that the fingerprint matches a previously-known fingerprint for the secure context identifier: causing receiving, at the device, of a notification that the device has been verified (In ¶ 92, Grajek discloses “If a match is made, then a successful authentication token may be sent back to the authentication calling product.” And in ¶ 113, further discloses “User device 110 may receive the authentication token which may be sent to application web server 103a for processing 622 as described above.”); and in response to the device fingerprint server determining that the fingerprint does not match a previously-known fingerprint for the secure context identifier: causing receiving, at the device, of a device verification challenge (In ¶ 95, Grajek discloses “If the user device was not matched either based on its fingerprints or based on a comparison of a stored user device's characteristics versus the user device's characteristics retrieved from the user device for this session, then the user may be forced to authenticate using an additional factor of authentication.”); responding, at the device, to the device verification challenge; and in response to the device fingerprint server verifying the fingerprint as part of the device verification challenge: causing receiving, at the device, of a notification that the device has been verified (In ¶ 96, Grajek discloses “Once communicated to the user, this randomly generated string may then be returned by the user computing device to the authentication system through the web and may be compared to the stored one-time password that was originally sent. If they are the same then the additional factor of authentication is successful.” And in ¶ 113, further discloses “User device 110 may receive the authentication token which may be sent to application web server 103a for processing 622 as described above.”).
Regarding Claim 4, Grajek discloses:
The method of claim 1, wherein the device further comprises a browser or mobile app executing on the device and configured to perform the device verification request and the device verification challenge (In ¶ 23, Grajek discloses “Specifically, the disclosure relates to a single sign-on process in which browsers, mobile applications, etc., may initially register a user device fingerprint using an additional factor of authentication that may require user interaction (such as a one-time password or knowledge based authentication).”).
Regarding Claim 5, Grajek discloses:
The method of claim 1, wherein the response to the device verification challenge comprises a challenge response. (In ¶ 96, Grajek discloses “Once communicated to the user, this randomly generated string may then be returned by the user computing device to the authentication system through the web and may be compared to the stored one-time password that was originally sent. If they are the same then the additional factor of authentication is successful.”)
Regarding Claim 6, Grajek discloses:
The method of claim 1, wherein the fingerprint comprises an anonymous and unique device (In ¶ 66, Grajek discloses “User device in block 307 executes the capture instructions to gather unique device, software, operating system, and/or user characteristics.”).
Regarding Claim 7, Grajek discloses:
The method of claim 1, wherein the secure context identifier comprises one of: an email address, a telephone number (In ¶ 89, Grajek discloses “No matter the method of transmission, the information sent from the network resource to the authentication system 102 may comprise, for example, a user identifier such as a user ID, an email address associated with the user of the user device, a telephone number associated with the user or the user device, an SMS number associated with the user of the user device or the user device a push number or a pin.”)
Regarding Claim 8, Grajek discloses:
The method of claim 1, wherein the device verification request further comprises an app identifier. (In ¶ 27, Grajek discloses “the system may send a device characteristic capture script to the user's device to capture information about the device, such as HTTP header information, identifiers of browser plug-ins, networking addresses, screen size and/or resolution, HTML5 session storage information, Internet Explorer User Data Support information, Browser Cookie enable/disable settings, a time zone, and/or other information.”)
Regarding Claim 10, Grajek discloses:
The method of claim 1, wherein, in response to the device fingerprint server failing to verify the fingerprint as part of the device verification challenge, the method further comprises: receiving, at the device, a notification that additional verification is required in order to verify the device. (In ¶ 95, Grajek discloses “If the user device was not matched either based on its fingerprints or based on a comparison of a stored user device's characteristics versus the user device's characteristics retrieved from the user device for this session, then the user may be forced to authenticate using an additional factor of authentication. In this case, a one-time password mechanism may be used. For example, an SMS message that may be sent to the user's phone; a telephone call may be made to the user's phone, whereby an audio voice describes a one-time password to be used; an email message may be sent, whereby the email message may include a link to verify that the email message was received (this email link may trigger the user computing device's browser to go to a specific web page that is provided by the authentication system); a push notification may be sent to a push number for the user; and so on.”)
Regarding Claim 11, Grajek discloses:
A method, comprising: receiving, at a device fingerprinting server, a fingerprint generated for a device and a device verification request (In ¶ 66, Grajek discloses “User device in block 307 executes the capture instructions to gather unique device, software, operating system, and/or user characteristics.” Wherein the captured chrematistics are representative of the device fingerprint), wherein the device verification request comprises a secure context identifier for a user of the device (In ¶ 88, Grajek discloses “The entity that requested authentication, for example the target application, may send, via the redirect to the authentication system 102, information requesting authentication using an additional device-based fingerprinting factor. For example, it may send a cookie or other token to the user computing device that may then be sent from the user computing device to the authentication system, and may comprise a number of different elements and information.” And further in ¶ 89 “the information sent from the network resource to the authentication system 102 may comprise, for example, a user identifier such as a user ID”); in response to the device fingerprint server determining that the fingerprint matches a previously-known fingerprint for the secure context identifier: sending, to the device, a notification that the device has been verified (In ¶ 92, Grajek discloses “If a match is made, then a successful authentication token may be sent back to the authentication calling product.” And in ¶ 113, further discloses “User device 110 may receive the authentication token which may be sent to application web server 103a for processing 622 as described above.”); and in response to the device fingerprint server determining that the fingerprint does not match a previously-known fingerprint for the secure context identifier: sending, to the device, a device verification challenge (In ¶ 95, Grajek discloses “If the user device was not matched either based on its fingerprints or based on a comparison of a stored user device's characteristics versus the user device's characteristics retrieved from the user device for this session, then the user may be forced to authenticate using an additional factor of authentication.”); receiving, from the device, a response to the device verification challenge; and in response to the verifying the fingerprint at the device fingerprint server as part of the device verification challenge: sending, to the device, a notification that the device has been verified (In ¶ 96, Grajek discloses “Once communicated to the user, this randomly generated string may then be returned by the user computing device to the authentication system through the web and may be compared to the stored one-time password that was originally sent. If they are the same then the additional factor of authentication is successful.” And in ¶ 113, further discloses “User device 110 may receive the authentication token which may be sent to application web server 103a for processing 622 as described above.”).
Regarding Claim 14, Grajek discloses:
The method of claim 11, wherein the device further comprises a browser or mobile app executing on the device and configured to perform the device verification request and the device verification challenge (In ¶ 23, Grajek discloses “Specifically, the disclosure relates to a single sign-on process in which browsers, mobile applications, etc., may initially register a user device fingerprint using an additional factor of authentication that may require user interaction (such as a one-time password or knowledge based authentication).”).
Regarding Claim 15, Grajek discloses:
The method of claim 11, wherein the response to the device verification challenge comprises a challenge response. (In ¶ 96, Grajek discloses “Once communicated to the user, this randomly generated string may then be returned by the user computing device to the authentication system through the web and may be compared to the stored one-time password that was originally sent. If they are the same then the additional factor of authentication is successful.”)
Regarding Claim 17, Grajek discloses:
The method of claim 11, wherein the secure context identifier comprises one of: an email address, a telephone number, or some other unique identifier. (In ¶ 89, Grajek discloses “No matter the method of transmission, the information sent from the network resource to the authentication system 102 may comprise, for example, a user identifier such as a user ID, an email address associated with the user of the user device, a telephone number associated with the user or the user device, an SMS number associated with the user of the user device or the user device a push number or a pin.”)
Regarding Claim 18, Grajek discloses:
The method of claim 11, wherein the device verification request further comprises an app identifier. (In ¶ 27, Grajek discloses “the system may send a device characteristic capture script to the user's device to capture information about the device, such as HTTP header information, identifiers of browser plug-ins, networking addresses, screen size and/or resolution, HTML5 session storage information, Internet Explorer User Data Support information, Browser Cookie enable/disable settings, a time zone, and/or other information.”)
Regarding Claim 20, Grajek discloses:
The method of claim 11, wherein, in response to the device fingerprint server failing to verify the fingerprint as part of the device verification challenge, the method further comprises: receiving, at the device, a notification that additional verification is required in order to verify the device. (In ¶ 95, Grajek discloses “If the user device was not matched either based on its fingerprints or based on a comparison of a stored user device's characteristics versus the user device's characteristics retrieved from the user device for this session, then the user may be forced to authenticate using an additional factor of authentication. In this case, a one-time password mechanism may be used. For example, an SMS message that may be sent to the user's phone; a telephone call may be made to the user's phone, whereby an audio voice describes a one-time password to be used; an email message may be sent, whereby the email message may include a link to verify that the email message was received (this email link may trigger the user computing device's browser to go to a specific web page that is provided by the authentication system); a push notification may be sent to a push number for the user; and so on.”)
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.
Claim(s) 2-3, 9, 12-13, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Grajek et al. (US 20180124039), hereinafter referred to as Grajek, in view of Axdorff et al. (US 20210226794), hereinafter referred to as Axdorff.
Regarding Claim 2, Grajek discloses the limitations of Claim 1.
However, Grajek does not explicitly disclose a proof generated from a keypair.
Axdorff discloses:
wherein the fingerprint comprises a cryptographic proof that is generated from a cryptographic keypair (In ¶ 18, Axdorff discloses “As indicated above, proof of possession may be implemented with OAuth 2.0, beginning with a request to the application server by the client for an access token The request may include key material (e.g., token binding type, key, and key parameters) that the client possesses or has access to, such as a public key of an asymmetric key pair. The public key, which may be a confirmation key as mentioned above, is added to the access token and may be JWT signed by the authorization server. The private key is retained by the client, which can generate the PoP token with the signed access token and use the PoP token to prove possession of the private key.”).
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Grajek’s approach by utilizing Axdorff’s approach of using a proof of possession token when performing device verification as the motivation would be that proof of possession tokens have a limited time to live which reduces the risk of theft by rendering them ineffective after expiration which allows for a stronger authentication mechanism. (See Axdorff, ¶¶ 46-47)
Regarding Claim 3, the combination of Grajek and Axdorff discloses the limitations of Claim 2.
However, Grajek does not explicitly disclose the security associated with the private key.
Axdorff discloses:
wherein the cryptographic keypair is stored in an unextractable fashion in the device (In ¶ 18, Axdorff discloses “The private key is retained by the client, which can generate the PoP token with the signed access token and use the PoP token to prove possession of the private key.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Grajek’s approach by utilizing Axdorff’s approach of using a proof of possession token when performing device verification as the motivation would be that proof of possession tokens have a limited time to live which reduces the risk of theft by rendering them ineffective after expiration which allows for a stronger authentication mechanism. (See Axdorff, ¶¶ 46-47)
Regarding Claim 9, Grajek discloses the limitations of Claim 1.
However, Grajek does not explicitly disclose the verification using a public key.
Axdorff discloses:
wherein verifying the fingerprint as part of the device verification challenge further comprises: verifying the fingerprint based, at least in part, on a public key. (In ¶ 19, Axdorff discloses “The public key is reflected in the token binding ID between the client and the authorization server. The token binding ID reflects the public key along with the key parameters agreed upon in the token binding negotiation. Server verification involves the server receiving the token binding request from the client, verifying that the key parameters in the request match the token binding parameters, and validating the signature contained in the request.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Grajek’s approach by utilizing Axdorff’s approach of using a public key when performing device verification as the motivation would be that the authorization server can validate a signature received from the device using the public key as an additional layer of security. (See Axdorff, ¶ 20)
Regarding Claim 12, Grajek discloses the limitations of Claim 11.
However, Grajek does not explicitly disclose a proof generated from a keypair.
Axdorff discloses:
wherein the fingerprint comprises a cryptographic proof that is generated from a cryptographic keypair (In ¶ 18, Axdorff discloses “As indicated above, proof of possession may be implemented with OAuth 2.0, beginning with a request to the application server by the client for an access token The request may include key material (e.g., token binding type, key, and key parameters) that the client possesses or has access to, such as a public key of an asymmetric key pair. The public key, which may be a confirmation key as mentioned above, is added to the access token and may be JWT signed by the authorization server. The private key is retained by the client, which can generate the PoP token with the signed access token and use the PoP token to prove possession of the private key.”).
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Grajek’s approach by utilizing Axdorff’s approach of using a proof of possession token when performing device verification as the motivation would be that proof of possession tokens have a limited time to live which reduces the risk of theft by rendering them ineffective after expiration which allows for a stronger authentication mechanism. (See Axdorff, ¶¶ 46-47)
Regarding Claim 13, the combination of Grajek and Axdorff discloses the limitations of Claim 12.
However, Grajek does not explicitly disclose the security associated with the private key.
Axdorff discloses:
wherein the cryptographic keypair is stored in an unextractable fashion in the device (In ¶ 18, Axdorff discloses “The private key is retained by the client, which can generate the PoP token with the signed access token and use the PoP token to prove possession of the private key.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Grajek’s approach by utilizing Axdorff’s approach of using a proof of possession token when performing device verification as the motivation would be that proof of possession tokens have a limited time to live which reduces the risk of theft by rendering them ineffective after expiration which allows for a stronger authentication mechanism. (See Axdorff, ¶¶ 46-47)
Regarding Claim 16, Grajek discloses the limitations of Claim 11.
However, Grajek does not explicitly disclose a proof generated from a keypair.
Axdorff discloses:
wherein the fingerprint comprises an anonymous and unique device proof for the device (In ¶ 18, Axdorff discloses “As indicated above, proof of possession may be implemented with OAuth 2.0, beginning with a request to the application server by the client for an access token The request may include key material (e.g., token binding type, key, and key parameters) that the client possesses or has access to, such as a public key of an asymmetric key pair. The public key, which may be a confirmation key as mentioned above, is added to the access token and may be JWT signed by the authorization server. The private key is retained by the client, which can generate the PoP token with the signed access token and use the PoP token to prove possession of the private key.”).
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Grajek’s approach by utilizing Axdorff’s approach of using a proof of possession token when performing device verification as the motivation would be that proof of possession tokens have a limited time to live which reduces the risk of theft by rendering them ineffective after expiration which allows for a stronger authentication mechanism. (See Axdorff, ¶¶ 46-47)
Regarding Claim 19, Grajek discloses the limitations of Claim 11.
However, Grajek does not explicitly disclose the verification using a public key.
Axdorff discloses:
wherein verifying the fingerprint as part of the device verification challenge further comprises: verifying the fingerprint based, at least in part, on a public key. (In ¶ 19, Axdorff discloses “The public key is reflected in the token binding ID between the client and the authorization server. The token binding ID reflects the public key along with the key parameters agreed upon in the token binding negotiation. Server verification involves the server receiving the token binding request from the client, verifying that the key parameters in the request match the token binding parameters, and validating the signature contained in the request.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Grajek’s approach by utilizing Axdorff’s approach of using a public key when performing device verification as the motivation would be that the authorization server can validate a signature received from the device using the public key as an additional layer of security. (See Axdorff, ¶ 20)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Schmaltz et al. (US 20200259652) discloses using hardened tokens for accessing services from devices.
Sheth et al. (US 20200322380) discloses a method for discovering trustworthy devices through attestation and authenticating devices through mutual attestation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHADI H KOBROSLI whose telephone number is (571)272-1952. The examiner can normally be reached M-F 9am-5pm ET.
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, Rupal Dharia can be reached at 571-272-3880. 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.
/SHADI H KOBROSLI/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492