DETAILED ACTION
Claims 1-20 have been examined and are rejected.
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 .
Specification
The disclosure is objected to because the specification lacks a background of the invention section. The specification should include a background of the invention section including: (1) Field of the Invention and (2) Description of Related Art including information disclosed under 37 CFR 1.97. See MPEP 608.01(a).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-3, 5, 7-10 and 16-18 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 2, 5, 8, 10-11, 13 and 18 of U.S. Patent No. 12425387. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims cover substantially the same subject matter and recite similar limitations.
Regarding independent claims 1-2 and 17, claim 1 corresponds to claims 2 and 11 of U.S. Patent No. 12425387 (see the table below). Clams 2 and 17 recite similar limitations to claim 1 and are rejected for the same reasons as claim 1.
Application No. 18/503,720
U.S. Patent No. 12425387
Claim 1. A system for text messaging-based self-service authentication in absence of a physical authentication token, comprising: one or more processors; and one or more non-transitory, computer-readable media comprising instructions that, when executed by the one or more processors, cause operations comprising:
receiving, from a mobile device, a first text message addressed to a recipient digital identifier associated with an account type, wherein the mobile device is operating on a mobile network and associated with a user digital identifier relating to the mobile network, and wherein the first text message indicates a request for account access in absence of the physical authentication token;
generating, for transmission to the mobile device, a second text message including a link to a webpage for account access in absence of the physical authentication token;
in response to receiving an indication of accessing the link from the mobile device, determining, based on the user digital identifier, whether there exists a user account of the account type; in response to determining an existence of the user account, retrieving mobile device information relating to the mobile network and associated with the user digital identifier;
determining, based on the mobile device information, whether to authenticate the request; in response to determining that the request is authenticated, generating a temporary machine-readable code associated with the user account, wherein the temporary machine-readable code is valid for a specified period of time; and
transmitting the temporary machine-readable code to the mobile device for display within the webpage on the mobile device, wherein the temporary machine- readable code is configured to allow a third party to access the user account by scanning, within the specified period, the temporary machine-readable code.
Claim 2. A method for machine-readable code-based access in absence of a physical authentication token, comprising:
receiving, from a mobile device, a text message indicating a first request for access in absence of the physical authentication token, wherein the mobile device is operating on a mobile network and associated with a user digital identifier relating to the mobile network;
11. The method of claim 2, further comprising: transmitting, to the mobile device, a second text message including a link to a webpage for accessing the user account in absence of the physical authentication token; and detecting that the mobile device accesses the webpage via the link before retrieving the mobile device information.
determining whether there exists a user account based on the user digital identifier; in response to determining an existence of the user account based on the user digital identifier, retrieving mobile device information relating to the mobile network and associated with the user digital identifier; determining whether to authenticate the first request based on the mobile device information;
in response to determining that the first request is authenticated, generating a first machine- readable code associated with the user account, wherein the first machine-readable code is valid for a specified period;
transmitting, to the mobile device, the first machine-readable code for display on the mobile device; receiving a second request from a third party for accessing the user account, wherein the second request was initiated by the third party scanning a second machine-readable code using a third party electronic device; assessing second information associated with the second machine-readable code based on a prediction model and first information associated with the first machine-readable code; in response to determining that the second information corresponds to the first information and the third party scanned the second machine-readable code within the specified period of the first machine-readable code, identifying the user account associated with the first machine-readable code; and authenticating the second request for the third party to access the user account.
Regarding claims 3, 5, 7-10, 16 and 18, claims 3, 5, 7-10, 16 and 18 of Application No. 18/503,720 correspond respectively to claims 5, 10, 2, 13, 2, 8, 5 and 18 of U.S. Patent No. 12425387.
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.
Claims 1-4, 7-13, 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kassemi et a. (U.S. PGPub 2015/0310438) in view of Zhou et al. (WO 2019/246626).
Regarding claim 1. Kassemi teaches A system for text messaging-based self-service authentication in absence of a physical authentication token, comprising: one or more processors; and one or more non-transitory, computer-readable media comprising instructions that, when executed by the one or more processors, cause operations comprising: receiving, from a mobile device, a first text message addressed to a recipient digital identifier associated with an account type, wherein the mobile device is operating on a mobile network and associated with a user digital identifier relating to the mobile network, and wherein the first text message indicates a request for account access in absence of the physical authentication token; (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
generating, for transmission to the mobile device, a second text message including a link to a webpage for account access in absence of the physical authentication token; (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0111 where using SMS messages and...acquire the token by a URL based logon tool or integration with the @Pay application program interface (API)... token in a mailto link in an email (807) to the customer 801(b)...; see paragraph 0114 mailto link or URL link included in the message and when selected either a confirmation or cancellation of the order occurs...note that no physical token is required)
in response to receiving an indication of accessing the link from the mobile device, determining, based on the user digital identifier, whether there exists a user account of the account type; (Kassemi, see fig. 11 customer opens authentication URL link; see paragraph 0117 authenticates that customer 1101 (1108) into the e-commerce system 1102. The e-commerce system 1102 delivers an additional authentication email upon successful login that invalidates any existing unused tokens and includes a new, valid token for the next time the customer must authenticate (1115) with the e-commerce system 1102...)
in response to determining an existence of the user account, retrieving mobile device information relating to the mobile network and associated with the user digital identifier; (Kassemi, see figs. 11-12B; see paragraph 0121 opting into a non-password based form of authentication. The client 1201 shares with the e-commerce system 1202 the address or phone number for the alternative media, such as SMS messaging or Facebook...web page requests that the customer check their alternative media for a code, which is required before moving completing authentication...)
determining, based on the mobile device information, whether to authenticate the request; (Kassemi, see figs. 11-12B; see paragraph 0121 opting into a non-password based form of authentication. The client 1201 shares with the e-commerce system 1202 the address or phone number for the alternative media, such as SMS messaging or Facebook...web page requests that the customer check their alternative media for a code, which is required before moving completing authentication...)
in response to determining that the request is authenticated, generating a temporary machine-readable code associated with the user account, wherein the temporary machine-readable code is valid for a specified period of time; and (Kassemi, see fig. 14; see paragraph 0123 the code sent via SMS. If the code matches the customer is granted access (1215). The e-commerce system 1202 requests an authentication email with a token (1216) and generates an email addressed to the customer and token and sends it to the customer 1201 (1217). The authentication email is stored in the email client until the next time the customer needs to access their account. In FIG. 12B the process of FIG. 12A is repeated, however, once the customer 1201 has logged-on, the e-commerce system 1202 invalidates the previous authentication tokens (1218), which indicate it's only valid for a specified period of time or the time period until the customer has logged-on)
However, Kassemi does not explicitly teach transmitting the temporary machine-readable code to the mobile device for display within the webpage on the mobile device,
wherein the temporary machine-readable code is configured to allow a third party to access the user account by scanning, within the specified period, the temporary machine-readable code.
Zhou teaches transmitting the temporary machine-readable code to the mobile device for display within the webpage on the mobile device, (Zhou, see paragraph 00116 A customer 501 can login or otherwise gain access to a protected account of the customer on a web-based interface 502...The web-based interface may request for a login graphical code, such as a login QR code, from a merchant’s identity broker. The graphical code may represent and be associated with the login request. The web-based interface may display the graphical code for scanning by the customer 501, such as with a user device of the customer...)
wherein the temporary machine-readable code is configured to allow a third party to access the user account by scanning, within the specified period, the temporary machine-readable code. (Zhou, see paragraph 00116 A customer 501 can login or otherwise gain access to a protected account of the customer on a web-based interface 502...The web-based interface may request for a login graphical code, such as a login QR code, from a merchant’s identity broker. The graphical code may represent and be associated with the login request. The web-based interface may display the graphical code for scanning by the customer 501, such as with a user device of the customer...; see paragraph 00100 authentication request may expire after a finite duration of time)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Kassemi and Zhou to provide the technique of transmitting the temporary machine-readable code to the mobile device for display within the webpage on the mobile device and allow a third party to access the user account by scanning, within the specified period, the temporary machine-readable code of Zhou in the system of Kassemi in order to accurately and efficiently verify an identity without revealing information about the individual whose identity is being verified beyond what is needed for the transaction (Zhou, see paragraph 0003).
Regarding claims 2 and 17, Kassemi teaches A method for text messaging-based self-service authentication in absence of a physical authentication token, comprising: receiving, from a mobile device, a first text message addressed to a recipient digital identifier, wherein the mobile device is operating on a mobile network and associated with a user digital identifier relating to the mobile network, and wherein the first text message indicates a request for account access in absence of the physical authentication token; (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
generating, for transmission to the mobile device, a second text message including a link to a webpage for account access in absence of the physical authentication token; (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0111 where using SMS messages and...acquire the token by a URL based logon tool or integration with the @Pay application program interface (API)... token in a mailto link in an email (807) to the customer 801(b)...; see paragraph 0114 mailto link or URL link included in the message and when selected either a confirmation or cancellation of the order occurs...note that no physical token is required)
in response to receiving an indication of accessing the link from the mobile device, determining, based on the user digital identifier, whether there exists a user account associated with the user digital identifier; (Kassemi, see fig. 11 customer opens authentication URL link; see paragraph 0117 authenticates that customer 1101 (1108) into the e-commerce system 1102. The e-commerce system 1102 delivers an additional authentication email upon successful login that invalidates any existing unused tokens and includes a new, valid token for the next time the customer must authenticate (1115) with the e-commerce system 1102...)
in response to determining an existence of the user account, determining, based on mobile device information, whether to authenticate the request, wherein the mobile device information relates to the mobile network and is associated with the user digital identifier; (Kassemi, see figs. 11-12B; see paragraph 0121 opting into a non-password based form of authentication. The client 1201 shares with the e-commerce system 1202 the address or phone number for the alternative media, such as SMS messaging or Facebook...web page requests that the customer check their alternative media for a code, which is required before moving completing authentication...)
in response to determining that the request is authenticated, generating a temporary machine-readable code associated with the user account, wherein the temporary machine-readable code is valid for a specified period of time; and (Kassemi, see fig. 14; see paragraph 0123 the code sent via SMS. If the code matches the customer is granted access (1215). The e-commerce system 1202 requests an authentication email with a token (1216) and generates an email addressed to the customer and token and sends it to the customer 1201 (1217). The authentication email is stored in the email client until the next time the customer needs to access their account. In FIG. 12B the process of FIG. 12A is repeated, however, once the customer 1201 has logged-on, the e-commerce system 1202 invalidates the previous authentication tokens (1218), which indicate it's only valid for a specified period of time or the time period until the customer has logged-on)
However, Kassemi does not explicitly teach transmitting the temporary machine-readable code to the mobile device for display within the webpage on the mobile device, wherein the temporary machine-readable code is configured to allow a third party to access the user account by scanning, within the specified period, the temporary machine-readable code.
Zhou teaches transmitting the temporary machine-readable code to the mobile device for display within the webpage on the mobile device, wherein the temporary machine-readable code is configured to allow a third party to access the user account by scanning, within the specified period, the temporary machine-readable code. (Zhou, see paragraph 00116 A customer 501 can login or otherwise gain access to a protected account of the customer on a web-based interface 502...The web-based interface may request for a login graphical code, such as a login QR code, from a merchant’s identity broker. The graphical code may represent and be associated with the login request. The web-based interface may display the graphical code for scanning by the customer 501, such as with a user device of the customer...; see paragraph 00100 authentication request may expire after a finite duration of time)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Kassemi and Zhou to provide the technique of transmitting the temporary machine-readable code to the mobile device for display within the webpage on the mobile device, wherein the temporary machine-readable code is configured to allow a third party to access the user account by scanning, within the specified period, the temporary machine-readable code of Zhou in the system of Kassemi in order to accurately and efficiently verify an identity without revealing information about the individual whose identity is being verified beyond what is needed for the transaction (Zhou, see paragraph 0003).
Regarding claim 3, Kassemi-Zhou teaches wherein the mobile device information comprises an operation duration during which the mobile device has been operating on the mobile network, an activity history of activities associated with the mobile device, roaming status, a mobile device location when the mobile device transmits the request, or subscriber information. (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
Regarding claim 4, Kassemi-Zhou teaches wherein determining, based on the mobile device information, whether to authenticate the request comprises: comparing the operation duration with a duration threshold, comparing the mobile device location with a location of the third party, comprising the subscriber information with information of a user associated with the user account, or identifying, based on the mobile device information, whether a fraudulent behavior is associated with the mobile device. (Kassemi, see paragraphs 0063-0065 detect email spoofing...verifying the SPF information in TXT records may reject messages from unauthorized sources .... If the server rejects the sender, the unauthorized client should receive a rejection message; see paragraph 0078 perform additional security measures to prevent unauthorized access to the system or fraud)
Regarding claim 7, Kassemi-Zhou teaches further comprising: in response to determining not to authenticate the request based on the mobile device information, generating, for transmission to the mobile device, a first notification requesting first additional authentication information. (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
Regarding claim 8, Kassemi-Zhou teaches further comprising: transmitting the first notification via a third text message to the mobile device, or transmitting the first notification for display in the webpage on the mobile device. (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
Regarding claim 9, Kassemi-Zhou teaches wherein: the first notification comprises a prompt configured to allow a submission of the first additional authentication information, and (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
the method further comprises: receiving, from the mobile device, the first additional authentication information; determining whether to authenticate the request based on the first additional authentication information; and (Kassemi, see figs. 11-12B; see paragraph 0121 opting into a non-password based form of authentication. The client 1201 shares with the e-commerce system 1202 the address or phone number for the alternative media, such as SMS messaging or Facebook...web page requests that the customer check their alternative media for a code, which is required before moving completing authentication...)
in response to determining that the request is authenticated based on the first additional authentication information, generating the temporary machine-readable code for transmitting to the mobile device. (Kassemi, see fig. 14; see paragraph 0123 the code sent via SMS. If the code matches the customer is granted access (1215). The e-commerce system 1202 requests an authentication email with a token (1216) and generates an email addressed to the customer and token and sends it to the customer 1201 (1217). The authentication email is stored in the email client until the next time the customer needs to access their account. In FIG. 12B the process of FIG. 12A is repeated, however, once the customer 1201 has logged-on, the e-commerce system 1202 invalidates the previous authentication tokens (1218))
Regarding claim 10, Kassemi-Zhou teaches wherein receiving the first additional authentication information comprises: receiving information transmitted using a secure protocol, the information corresponding to the first additional authentication information. (Kassemi, see paragraph 0026 r multiple encrypted strings, files, passwords, cyphers or other data which may contain information used to perform or authenticate a transaction when sent to payment servers. These tokens may be encrypted using a public-private key encryption system; see paragraph 0069 default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64...)
Regarding claim 11, Kassemi-Zhou teaches wherein: the information comprises encrypted data that represent the first additional authentication information or compressed data that represent the first additional authentication information, and (Kassemi, see paragraph 0026 r multiple encrypted strings, files, passwords, cyphers or other data which may contain information used to perform or authenticate a transaction when sent to payment servers. These tokens may be encrypted using a public-private key encryption system; see paragraph 0069 default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64...)
the method further comprising obtaining the first additional authentication information by decrypting or decompressing the information. (Kassemi, see paragraph 0026 r multiple encrypted strings, files, passwords, cyphers or other data which may contain information used to perform or authenticate a transaction when sent to payment servers. These tokens may be encrypted using a public-private key encryption system; see paragraph 0069 default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64...; see paragraph 0072 receiver may use this to then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail message (headers and body) that was received. If the two values match, this cryptographically proves that the mail was signed by the indicated domain and has not been tampered with in transit)
Regarding claim 12, Kassemi-Zhou teaches further comprising: in response to failing to determine the existence of the user account, generating, for transmission to the mobile device, a second notification requesting second additional authentication information. (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
Regarding claim 13, Kassemi-Zhou teaches further comprising: transmitting the second notification via a fourth text message to the mobile device, or transmitting the second notification for display in the webpage on the mobile device. (Kassemi, see fig. 14; see paragraph 0123 the code sent via SMS. If the code matches the customer is granted access (1215). The e-commerce system 1202 requests an authentication email with a token (1216) and generates an email addressed to the customer and token and sends it to the customer 1201 (1217). The authentication email is stored in the email client until the next time the customer needs to access their account. In FIG. 12B the process of FIG. 12A is repeated, however, once the customer 1201 has logged-on, the e-commerce system 1202 invalidates the previous authentication tokens (1218), which indicate it's only valid for a specified period of time or the time period until the customer has logged-on)
Regarding claim 16, Kassemi-Zhou teaches wherein: the user account belongs to an account type, and at least one of the account type or the recipient digital identifier is associated with the third party. (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
Regarding claim 18, Kassemi-Zhou teaches wherein accessing the webpage from the mobile device comprises scanning a second machine-readable code associated with the third party. (Zhou, see paragraph 00116 A customer 501 can login or otherwise gain access to a protected account of the customer on a web-based interface 502...The web-based interface may request for a login graphical code, such as a login QR code, from a merchant’s identity broker. The graphical code may represent and be associated with the login request. The web-based interface may display the graphical code for scanning by the customer 501, such as with a user device of the customer...; see paragraph 00100 authentication request may expire after a finite duration of time) The motivation regarding to the obviousness to claims 2 and 17 is also applied to claim 18.
Regarding claim 20, Kassemi-Zhou teaches wherein the operations further comprise: in response to determining not to authenticate the request based on the mobile device information, generating, for transmission to the mobile device, a notification requesting additional authentication information, the notification comprising a prompt configured to allow a submission of the additional authentication information; (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.)
receiving, from the mobile device, the additional authentication information; and determining whether to authenticate the request based on the additional authentication information. (Kassemi, see figs. 2-3, 5 and 8; see paragraph 0113 the SMS messages...one may require the customer to message the word “YES” to confirm the order...the account is frozen until the customer may be authenticated. If the customer does lock the account they may receive additional SMS messages and/or social media posts and emails describing how to access their account and reset the security password or may instruct them to cancel their payment method i.e. credit card, debit, bank account or direct carrier billing system...note that no physical token is required; see paragraph 0111 using SMS messages ... an SMS message addressed to the customer's phone number.; see figs. 11-12B; see paragraph 0121 opting into a non-password based form of authentication. The client 1201 shares with the e-commerce system 1202 the address or phone number for the alternative media, such as SMS messaging or Facebook...web page requests that the customer check their alternative media for a code, which is required before moving completing authentication...)
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Kassemi-Zhou in view of Goldman et al. (U.S. PGPub 2018/0033089).
Regarding claim 5, Kassemi-Zhou teaches determining, based on the characterization of the mobile device information, whether to authenticate the request. (Kassemi, see figs. 11-12B; see paragraph 0121 opting into a non-password based form of authentication. The client 1201 shares with the e-commerce system 1202 the address or phone number for the alternative media, such as SMS messaging or Facebook...web page requests that the customer check their alternative media for a code, which is required before moving completing authentication...)
However, Kassemi-Zhou does not explicitly teach wherein determining, based on the mobile device information, whether to authenticate the request comprises: extracting, from the mobile device information, a feature vector representing one or more features that are indicative of a risk of fraudulent behavior associated with the mobile device or the user digital identifier;
inputting the feature vector into a machine learning model, wherein the machine learning model outputs a characterization of the mobile device information; and
Goldman teaches wherein determining, based on the mobile device information, whether to authenticate the request comprises: extracting, from the mobile device information, a feature vector representing one or more features that are indicative of a risk of fraudulent behavior associated with the mobile device or the user digital identifier; (Goldman, see fig. 4; see paragraph 0010 predictive models that are trained to identify potentially fraudulent activity...using system access data (mobile device information) that has been associated with fraudulent activity, which enables the one or more predictive models to generate scores that represent the likelihood of fraudulent activity based on analysis of prior cases...; see paragraph 0074 predictive models 122 are trained generate a risk score or risk score data 121 for one particular risk category (e.g., user system characteristics identifier, IP address identifier, user account identifier, etc.)...)
inputting the feature vector into a machine learning model, wherein the machine learning model outputs a characterization of the mobile device information; and (Goldman, see fig. 4; see paragraph 0010 predictive models that are trained to identify potentially fraudulent activity...using system access data (mobile device information) that has been associated with fraudulent activity, which enables the one or more predictive models to generate scores that represent the likelihood of fraudulent activity based on analysis of prior cases...; see paragraph 0074 predictive models 122 are trained generate a risk score or risk score data 121 for one particular risk category (e.g., user system characteristics identifier, IP address identifier, user account identifier, etc.)...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Kassemi-Zhou and Goldman to provide the technique of determining, based on the mobile device information, whether to authenticate the request comprises: extracting, from the mobile device information, a feature vector representing one or more features that are indicative of a risk of fraudulent behavior associated with the mobile device or the user digital identifier and inputting the feature vector into a machine learning model, wherein the machine learning model outputs a characterization of the mobile device information of Goldman in the system of Kassemi-Zhou in order to computing performance, by identifying and addressing potentially fraudulent activity in a financial system and provide an efficient user experience (Goldman, see paragraph 0016).
Regarding claim 6, Kassemi-Zhou-Goldman teaches wherein: the characterization of the mobile device information comprises a risk score; and (Goldman, see fig. 4; see paragraph 0010 predictive models that are trained to identify potentially fraudulent activity...using system access data (mobile device information) that has been associated with fraudulent activity, which enables the one or more predictive models to generate scores that represent the likelihood of fraudulent activity based on analysis of prior cases...; see paragraph 0074 predictive models 122 are trained generate a risk score or risk score data 121 for one particular risk category (e.g., user system characteristics identifier, IP address identifier, user account identifier, etc.)...)
determining, based on the characterization of the mobile device information, whether to authenticate the request comprises: comparing the risk score with a risk score threshold; and in response to determining that the risk score exceeds the risk score threshold, determining not to authenticate the request based on the mobile device information. (Goldman, see fig. 4; see paragraph 0077 represent a low likelihood for fraudulent activity as well as to existing sessions 116 that represent a high likelihood for fraudulent activity, to define risk score thresholds to apply to the risk score data 121...the risk score data 121 is compared to one or more predefined risk score thresholds to determine if one or more of the risk categories 123 has a high enough likelihood of potential fraudulent characteristics to warrant performing risk reduction actions...; see paragraph 0081 If at least part of the risk score data 121 indicates that potentially fraudulent activity...challenging the authentication of the user, removing multi-factor authentication options (e.g., removing email as a multi-factor authentication option), increasing the difficulty of multi-factor authentication options, sending a text message to an authorized user, logging a user out of a session with the financial system 111, ending a session, blocking access to the financial system 111) The motivation regarding to the obviousness to claim 5 is also applied to claim 6.
Claims 14-15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kassemi-Zhou in view of Bodera et al. (U.S. PGPub 20200202066).
Regarding claim 14, Kassemi-Zhou teaches all of the features of claim 2. However, Kassemi-Zhou does not explicitly teach further comprising: in response to receiving the indication of accessing the link from the mobile device, determining, based on the user digital identifier, that multiple user accounts exist; and
generating, for transmitting to the mobile device, a third notification inviting a selection from the multiple user accounts to proceed with respect to the request.
Bodera teaches further comprising: in response to receiving the indication of accessing the link from the mobile device, determining, based on the user digital identifier, that multiple user accounts exist; and (Bodera, see fig. 4; see paragraphs 0136-0138 where received access key is not sufficient to grant access to the content of the URL ... does not have sufficient permissions to access the underlying URL and that the user can try a different account...user decides to try a different account, the user selects this option from the smart link card…)
generating, for transmitting to the mobile device, a third notification inviting a selection from the multiple user accounts to proceed with respect to the request. (Bodera, see fig. 4; see paragraph 0136 where received access key is not sufficient to grant access to the content of the URL ...the error message may notify the user that the user's current account is not authorized to access the resource and the user can try to connect via a different user account.. does not have sufficient permissions to access the underlying URL and that the user can try a different account.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Kassemi-Zhou and Bodera to provide the technique of in response to receiving the indication of accessing the link from the mobile device, determining, based on the user digital identifier, that multiple user accounts exist and generating, for transmitting to the mobile device, a third notification inviting a selection from the multiple user accounts to proceed with respect to the request of Bodera in the system of Kassemi-Zhou in order to avoid negative impact on user experience and system resources (Bodera, see paragraph 0006).
Regarding claim 15, Kassemi-Zhou teaches all of the features of claim 2. However, Kassemi-Zhou does not explicitly teach further comprising: in response to receiving the indication of accessing the link from the mobile device, determining, based on the user digital identifier, that multiple user accounts exist; and
selecting, from the multiple user accounts, the user account that is associated with the third party.
Bodera teaches further comprising: in response to receiving the indication of accessing the link from the mobile device, determining, based on the user digital identifier, that multiple user accounts exist; and (Bodera, see fig. 4; see paragraphs 0136-0138 where received access key is not sufficient to grant access to the content of the URL ... does not have sufficient permissions to access the underlying URL and that the user can try a different account...user decides to try a different account, the user selects this option from the smart link card…)
selecting, from the multiple user accounts, the user account that is associated with the third party. (Bodera, see fig. 4; see paragraph 0136 where received access key is not sufficient to grant access to the content of the URL ...the error message may notify the user that the user's current account is not authorized to access the resource and the user can try to connect via a different user account.. does not have sufficient permissions to access the underlying URL and that the user can try a different account.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Kassemi-Zhou and Bodera to provide the technique of in response to receiving the indication of accessing the link from the mobile device, determining, based on the user digital identifier, that multiple user accounts exist and selecting, from the multiple user accounts, the user account that is associated with the third party of Bodera in the system of Kassemi-Zhou in order to avoid negative impact on user experience and system resources (Bodera, see paragraph 0006).
Regarding claim 19, Kassemi-Zhou teaches all of the features of claim 17. However, Kassemi-Zhou does not explicitly teach wherein the operations further comprise: detecting multiple user accounts associated with the user digital identifier; and selecting, from the multiple user accounts, the user account that is associated with the third party.
Bodera teaches wherein the operations further comprise: detecting multiple user accounts associated with the user digital identifier; and selecting, from the multiple user accounts, the user account that is associated with the third party. (Bodera, see fig. 4; see paragraph 0136 where received access key is not sufficient to grant access to the content of the URL ...the error message may notify the user that the user's current account is not authorized to access the resource and the user can try to connect via a different user account.. does not have sufficient permissions to access the underlying URL and that the user can try a different account.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Kassemi-Zhou and Bodera to provide the technique of detecting multiple user accounts associated with the user digital identifier; and selecting, from the multiple user accounts, the user account that is associated with the third party of Bodera in the system of Kassemi-Zhou in order to avoid negative impact on user experience and system resources (Bodera, see paragraph 0006).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
U.S. Patent No. 10972475, which describes account access security using a distributed ledger and/or a distributed file system;
U.S. PGPub 2021/0058395, which describes a system to identify artifacts in a plurality of messages of an account of a user, and to replace the identified artifacts in the messages with respective modified artifacts while also maintaining in access-controlled storage at least information related to the identified artifacts; and
U.S. PGPub 2017/0103674, which describes mock attack cybersecurity training system and methods.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG VANG whose telephone number is (571)270-7023. The examiner can normally be reached M-F 8AM-2PM, 3PM-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, NICHOLAS TAYLOR can be reached at (571) 272-3889. 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.
/MENG VANG/Primary Examiner, Art Unit 2443