Verification operations based on wireless communication

Abstract

Authentication techniques based on wireless communication with a contactless card. The password is generated based on a ciphertext read from the contactless card. The password is generated in response to the device detecting the contactless card. The password has an associated account and an associated validity criterion. The password is stored on the server. A request is received that specifies an operation associated with the account to be performed and further specifies a password generated prior to the operation being specified. And after determining that the specified password is matched with the stored password and the validity criterion is still met, authorizing to execute the operation specified by the request. The operation is authorized without the need for the device to re-detect the contactless card.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202480060719.6 (22) Application Date 2024.09.20 (30) Priority Data 18 / 471,505 2023.09.21 US (85) PCT International Application Entering National Phase Date 2026.03.23 (86) PCT International Application Application Data PCT / US2024 / 047641 2024.09.20 (87) PCT International Application Publication Data WO2025 / 064782 EN 2025.03.27 (71) Applicant: Capital Services LLC Address: USA (72) Inventor: Daniel Pico Jayant Pratipatico Hart (74) Patent Agency: Beijing Pinyuan Patent Agency Co., Ltd. 11332 Patent Attorneys Tan Yingying and Hu Bin (51) Int.Cl. H04L 9 / 40 (2006.01) G06F 21 / 35 (2006.01) G06Q 20 / 34 (2006.01) H04W 12 / 47 (2006.01) (54) Invention Title: Authentication Operation Based on Wireless Communication (57) Abstract: Authentication technology based on wireless communication with a contactless card. The password is generated based on ciphertext read from the contactless card. The password is generated in response to the device detecting the contactless card. The password has an associated account and associated validity criteria. The password is stored on a server. A request is received specifying the operation associated with the account and further specifying a password generated before the operation is specified. After determining that the specified password matches the stored password and the validity criteria are still satisfied, the operation specified in the request is authorized. The operation is authorized without the device re-detecting the contactless card. Claims 2 pages, Description 22 pages, Drawings 23 pages, CN 121890040 A 2026.04.17 CN 1 21 89 00 40 A 1. A method comprising: storing by a server a password generated based on ciphertext read from a contactless card, wherein the password is generated in response to a device detecting the contactless card, and wherein the password is associated with an account and validity criteria; receiving one or more requests, each request specifying to perform a corresponding operation associated with the account, each request further specifying a corresponding password generated prior to the specified operation; and authorizing the execution of the operation specified by the first request when it is determined that the password specified by a first request of the one or more requests matches the password stored by the server and the validity criteria are still satisfied, wherein the operation is authorized without the device re-detecting the contactless card.2. The method of claim 1, wherein the validity criterion includes a time validity period. 3. The method of claim 1, wherein the operation specified by the first request is further authorized based on verifying authentication credentials of the account. 4. The method of claim 2, wherein the password is generated in response to a request to pre-generate the password for the validity period, wherein the password is not generated in response to any requested operation associated with the account, and wherein the request to pre-generate the password is in response to the request. 5. The method of claim 2, further comprising: upon determining that the password specified by the second request in one or more requests does not match a password stored in the server and the validity period has not expired, requesting (i) a matching password or (ii) the device to re-detect the contactless card before authorizing the execution of the operation specified by the second request. 6. The method of claim 2, further comprising: upon determining that the password specified by the third request in one or more requests matches a password stored in the server and the validity period has expired, requesting the device to re-detect the contactless card before authorizing the execution of the operation specified by the third request. 7. The method of claim 2, further comprising: upon determining that the password specified in a fourth request of the one or more requests does not match a password stored by the server and the expiration date has expired, requesting the device to re-detect the contactless card before authorizing the execution of the operation specified by the fourth request. 8. The method of claim 1, wherein the password specified in the first request is provided based on input received via an input device selected from a microphone, touchscreen, touchpad, keyboard, and pointing device. 9. The method of claim 8, wherein the password specified in the first request is provided via at least one of a call center agent or a web browser application. 10. The method of claim 8, further comprising: receiving a request to retrieve a password stored by the server; and sending the password stored by the server to an application on the device, wherein the application outputs the password, wherein the password specified in the first request is provided based on the output password. 11. The method of claim 8, wherein the input device is operatively connected to (i) a first device including the device or (ii) a second device other than the device. 12. The method of claim 1, wherein the one or more requests comprise a plurality of requests, and wherein the corresponding operation of each of the plurality of requests is authorized based on the same password stored by the server.13. The method of claim 1, wherein the ciphertext and the Uniform Resource Locator (URL) are readable from the contactless card based on Near Field Communication (NFC). 14. The method of claim 13, wherein the server includes an authentication server configured to: receive the ciphertext from the device; transmit a decryption result to the device, the decryption result indicating that the authentication server has decrypted the ciphertext; receive a request for the password from the device, the request including an identifier based on at least one of a customer identifier, an account identifier, a device identifier, or a card identifier; generate the password using components of the authentication server, the components including a password generator accessible via the URL; and transmit the password to the device. 15. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to perform the following operations: storing a password generated based on ciphertext read from a contactless card, wherein the password is generated in response to a device detecting the contactless card, and wherein the password is associated with an account and validity criteria; receiving one or more requests, each request specifying the execution of a corresponding operation associated with the account, each request further specifying a corresponding password generated prior to the specified operation; and authorizing the execution of the operation specified by the first request when it is determined that the password specified by a first request of the one or more requests matches the stored password and the validity criteria are still satisfied, wherein the operation is authorized to re-detect the contactless card without the device. 16. The non-transitory computer-readable medium of claim 15, wherein the validity criteria include a time validity period. 17. The non-transitory computer-readable medium of claim 15, wherein the operation specified by the first request is further authorized based on authentication credentials verifying the account.18. A system comprising: a processor; and a memory storing instructions that the processor can cause the processor to perform the following operations: storing a password generated based on ciphertext read from a contactless card, wherein the password is generated in response to a device detecting the contactless card, and wherein the password is associated with an account and validity criteria; receiving one or more requests, each request specifying the execution of a corresponding operation associated with the account, each request further specifying a corresponding password generated prior to the specified operation; and authorizing the execution of the operation specified by the first request when it is determined that the password specified by a first request of the one or more requests matches the stored password and the validity criteria are still satisfied, wherein the operation is authorized without the device re-detecting the contactless card. 19. The system of claim 18, wherein the validity criteria include a time validity period. 20. The system of claim 18, wherein the operation specified by the first request is further authorized based on authentication credentials verifying the account. Claims 2 / 2 Page 3 CN 121890040 A Cross-Reference to Related Applications Regarding Authentication Operations Based on Wireless Communication

[0001] This application claims priority to U.S. Application No. 18 / 471,505, filed September 21, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0002] With the increasing prevalence of user devices such as mobile phones, ensuring secure access to data and private information on user devices remains a significant concern. For example, in order to access a mobile device or an application running on that mobile device, user authentication is typically required before access is granted. However, attackers attempt to circumvent security measures by stealing passwords and eavesdropping on users during the registration and authentication process (e.g., by implementing man-in-the-middle attacks). Therefore, attackers may attempt to intercept data that can be used to infer the identity of a user, user device, or server computer, such as public keys. Attackers may also attempt to intercept authentication data, such as passwords or responses to challenges. Intercepted data may be used to track a user's device, or it may be used for illicit purposes. While additional security measures may be necessary to increase the difficulty for attackers to steal and gain access, in some cases, these additional security measures may be too stringent for legitimate users, especially in specific use cases.

[0003] Embodiments presented in this disclosure provide a method, computer-readable medium, and system for performing authentication steps based on wireless communication with a contactless card. The steps include storing a password generated by a server based on ciphertext read from the contactless card. The password is generated in response to a device detecting the contactless card. The password has an associated account and associated validity criteria.The step also includes receiving one or more requests, each request specifying the execution of a corresponding operation associated with the account. Each request also specifies a corresponding password generated before the operation is specified. The one or more requests are received after the password is stored. The step also includes authorizing the execution of the operation specified by the first request when it is determined that the password specified by the first request of the one or more requests matches the stored password and the validity criteria are still met. The operation is authorized without the device re-detecting the contactless card. Brief Description of the Drawings

[0004] Figures 1A-1C illustrate computing environments with respect to various aspects of the subject matter according to embodiments presented in this disclosure.

[0005] Figures 2A-2I are schematic diagrams illustrating graphical user interface (GUI) screens with respect to various aspects of the subject matter according to embodiments presented in this disclosure.

[0006] Figure 3 illustrates a routine for authentication based on wireless communication with a contactless card according to one embodiment presented in this disclosure.

[0007] Figure 4 illustrates another routine for authentication based on wireless communication with a contactless card according to one embodiment presented in this disclosure.

[0008] Figures 5A-5C are sequence diagrams depicting additional routines for authentication based on wireless communication with a contactless card, according to embodiments presented in this disclosure. Specification 1 / 22 pages 4 CN 121890040 A

[0009] Figure 6 shows another routine for authentication based on wireless communication with a contactless card, according to an embodiment presented in this disclosure.

[0010] Figures 7A-7B show a contactless card according to an embodiment presented in this disclosure.

[0011] Figure 8 shows a data structure according to an embodiment presented in this disclosure.

[0012] Figure 9 shows a computer architecture according to an embodiment presented in this disclosure. Detailed Description

[0013] Multi-factor authentication (MFA) typically involves knowledge factors (what the user knows) and holding factors (what the user possesses). Embodiments presented in this disclosure provide an alternative holding factor, which can be characterized as "what the user recently possesses." More specifically, according to one embodiment, an alternative holding factor can be characterized as "what the user has previously requested to be verified."

[0014] At least some embodiments of this disclosure provide passwords that can be pre-generated. These passwords may be time-limited, such as limited to a thirty-day time window. Additionally or alternatively, these passwords may have a maximum allowed number of reuses, such as a maximum of five uses. Advantageously, in addition to allowing the user to authorize the desired transaction by responsively swiping a contactless card, the user is also given the additional option of pre-swiping a contactless card to generate a time-limited and / or reusable password.

[0015] The pre-generated password can then be used no more than a maximum number of times and / or within a time window, and the user does not need to swipe the contactless card again during such use of the pre-generated password. The user can either memorize the pre-generated password or view it using an application. The user can then provide the pre-generated password via a web browser or to a service agent to authorize the desired operation.

[0016] The disclosed embodiments regarding pre-generated passwords can address various use cases involving users traveling or moving abroad. In such use cases, the user may not currently possess their contactless card and / or a computing device such as a smartphone, or the smartphone may not be able to connect to any mobile operator network that is compatible with the network used by the organization issuing the contactless card and / or providing the user account in terms of communication protocols.

[0017] Without the disclosed embodiments regarding pre-generated passwords, it is conceivable that the desired operation of such user transactions cannot be authorized or performed unless the user takes additional security measures (such as providing a copy of their passport or government identification document) or the conditions of their usage experience a favorable change (such as returning from a trip or moving back to a previous country). With the benefits of the disclosed technology, such desired user operations can be authorized and performed as long as the user recalls the pre-generated codes or can view them separately through the application, even if the user is not currently holding a contactless card.

[0018] For this purpose, the disclosed embodiments also provide techniques for securely generating passwords that can be used as a second form of authentication. Typically, a user may expect authentication to access an account, complete a purchase, or perform any operation requiring an MFA. In one embodiment, a user can swipe the contactless card onto a computing device to initiate authentication. In response to entering communication range with the device, the contactless card can generate a data packet including ciphertext and a Uniform Resource Locator (URL). The device's operating system can read the data packet and / or URL and launch the account application associated with the URL on the device. In some embodiments, if the account application is already started but only inactive, the operating system can activate the account application without stopping and / or restarting it. In one example, the account application is associated with the issuer of a contactless card. The account application can transmit a password request to a password generator at a URL. The password request may include the ciphertext.

[0019] The password generator and / or the server associated with the password generator can then attempt to decrypt the ciphertext, as described in more detail herein. If decryption is successful, the password generator can identify contact information for the associated account, such as a phone number, a code, email address, etc. The password generator can generate a password and transmit the password to the identified contact information.According to embodiments, the password can be pre-generated or reactively generated relative to the time specified by the user for the desired operation.

[0020] In one embodiment, the user can receive a password from a password generator and provide the received password as input to an account application. The account application can compare the input with an instance of the password received from the password generator. If the comparison matches, the account application can verify the password and allow the requested operation, such as viewing account details, making a purchase, etc. If the comparison does not match, the verification may fail, and the account application can refuse or otherwise restrict the execution of the requested operation. It is envisioned that at a given time, multiple passwords (including different types of passwords, such as pre-generated passwords and reactively generated passwords) can be accepted to authorize the execution of the desired operation.

[0021] Therefore, the disclosed embodiments also provide a security technique for generating passwords for MFA using contactless cards. Using ciphertext generated by contactless cards, the disclosed embodiments can securely verify the identity of the user requesting the execution of the desired operation with minimal risk of fraud. Furthermore, this ensures that a password is generated only when the user has both access to the contactless card and a computing device with a secure application for assisting in encrypted verification with the server. Additionally, by providing a simplified password generation process, the server can handle more requests, thereby improving system performance.

[0022] Generally, with reference to the symbols and terminology used herein, one or more parts of the following detailed description can be presented in the manner of a program process executed on a computer or computer network. These program descriptions and representations are used by those skilled in the art to most effectively communicate the content of their work to others skilled in the art. Here, a program is generally considered to be a self-consistent sequence of operations that leads to a desired result. These operations require physical manipulation of physical quantities. Typically, although not always, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient to sometimes refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc., primarily for reasons of common usage. However, it should be noted that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applicable to these quantities.

[0023] Furthermore, these operations are often referred to by terms such as addition or comparison, and are generally associated with mental operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such an ability of a human operator is not required, or in most cases preferred. Instead, these operations are machine operations.Useful machines for performing the operations of various embodiments include digital computers selectively activated or configured by computer programs stored therein written in accordance with the teachings herein, and / or include means or digital computers specifically constructed for the desired purpose. Various embodiments also relate to means or systems for performing these operations. These means may be specifically constructed for the desired purpose. The required structures of the various machines are apparent from the given description.

[0024] Reference is now made to the accompanying drawings, wherein the same reference numerals are used throughout to refer to the same elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a full understanding thereof. However, it will be apparent, however, that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form for ease of description. It is intended to cover all modifications, equivalents, and substitutions within the scope of the claims.

[0025] FIG1A depicts an exemplary computing architecture 100, also referred to as a system, conforming to the disclosed embodiments. Although the computing architecture 100 shown in Figures 1A-1C has a limited number of elements in a particular topology, it is understood that the computing architecture 100 may include more or fewer elements in alternative topologies depending on the needs of a given implementation.

[0026] The computing architecture 100 includes a computing device 102, a server 104, and a contactless card 136. The contactless card 136 refers to any type of payment card, such as a credit card, debit card, ATM card, gift card, and the like. The contactless card 136 may include one or more communication interfaces 122, such as a radio frequency identification (RFID) chip, which is configured to communicate with the communication interface 122 of the computing device 102 (also referred to herein as a “reader,” “wireless reader,” and / or “wireless communication interface”) via NFC, the EMV standard, or other short-range protocols in wireless communication. Although NFC is used herein as an example communication protocol, this disclosure is equally applicable to other types of wireless communication, such as the EMV standard, Bluetooth, and / or Wi-Fi.

[0027] Computing device 102 represents any number and type of computing devices, such as smartphones, tablets, wearable devices, laptops, portable gaming devices, virtualized computing systems, merchant terminals, point-of-sale systems, servers, desktop computers, and the like. Mobile devices are used as examples of computing device 102 but should not be considered as limiting this disclosure. Server 104 represents any type of computing device, such as servers, workstations, computing clusters, cloud computing platforms, virtual computing systems, etc. While not depicted for clarity, computing device 102, contactless card 136, and server 104 all include one or more processor circuits to execute programs, code, and / or instructions.

[0028] As shown, the memory 106 of the contactless card 136 includes an applet 108, a counter 110, a master key 112, a distribution key 114, and a unique customer identifier (ID) 116. The applet 108 is executable code configured to perform the operations described herein. The counter 110, master key 112, distribution key 114, and customer ID 116 are used to provide security in the system 100 via a password 150, as described in more detail below.

[0029] As shown, the memory 144 of the mobile device 102 includes an instance of an operating system (OS) 138. Example operating systems 138 include Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, OS 138 includes an account application 118 and a web browser 140. The account application 118 allows users to perform various account-related operations, such as activating payment cards, viewing account balances, purchasing items, processing payments, etc. In some embodiments, users may authenticate using authentication credentials to access certain functions of the account application 118. For example, authentication credentials may include a username (or login) and password, biometric credentials (e.g., fingerprint, Face ID, etc.), etc. A web browser 140 is an application that allows device 102 to access information via network 124 (e.g., via the Internet).

[0030] As shown, the memory 128 of server 104 includes an authentication application 123, which includes a password generator 142. Although depicted as an integrated component of server 104, in some embodiments, the authentication application 123 and the password generator 142 may be separate components. Furthermore, the authentication application 123 and / or the password generator 142 may be implemented in hardware, software, and / or a combination of hardware and software.

[0031] In some embodiments, to protect account application 118 and / or associated data, such as user account details in account database 130, system 100 may use contactless card 136 to provide secure password generation. For example, a user can provide authentication credentials to account application 118, such as a username / password verified by account application 118 (e.g., using a local instance of account database 130 and / or transmitting credentials to server 104 for verification). Once verified, account application 118 can instruct the user to swipe contactless card 136 onto computing device 102.

[0032] In the embodiment depicted in FIG1A, the user can swipe contactless card 136 onto computing device 102 (or otherwise place contactless card 136 within communication range of the card reader of device 102). Applet 108 of contactless card 136 can then generate URL 120 pointing to resources such as server 104, authentication application 126, and / or password generator 142.In some embodiments, applet 108 constructs URL 120 according to one or more rules. In some embodiments, contactless card 136 stores multiple URLs 120, and applet 108 selects a URL 120 from the multiple URLs 120 based on one or more rules. In some embodiments, applet 108 can generate URL 120 by selecting URL 120 and adding dynamic data (such as ciphertext 134) as one or more parameters of the URL.

[0033] Ciphertext 134 may be based on customer ID 116 of contactless card 136. Ciphertext 134 may be generated based on any suitable cryptographic technique. In some embodiments, applet 108 may include URL 120, ciphertext 134, and unencrypted identifiers (e.g., customer ID 116, identifier of contactless card 136, and / or any other unique identifier) ​​as a data packet as a specification page 4 / 22 7 CN 121890040 Part A. In at least one embodiment, the data packet is an NDEF file.

[0034] As described above, the computing architecture 100 is configured to implement key distribution to protect data, which may be referred to herein as a key distribution technique. Typically, the server 104 (or another computing device) and the contactless card 136 may be equipped with the same master key 112 (also referred to as the master symmetric key). More specifically, each contactless card 136 is programmed with a different master key 112 that has a corresponding pair in the server 104. For example, when the contactless card 136 is manufactured, a unique master key 112 may be programmed into the memory 106 of the contactless card 136. Similarly, the unique master key 112 may be stored in the customer records associated with the contactless card 136 in the account database 130 of the server 104 (and / or stored in a different secure location, such as a hardware security module (HSM) 132). The master key 112 can be kept confidential from all parties except the contactless card 136 and the server 104, thereby enhancing the security of the system 100. In some embodiments, the applet 108 of the contactless card 136 can use the master key 112 and data as input to a cryptographic algorithm to encrypt and / or decrypt data (e.g., customer ID 116). For example, encrypting the customer ID 116 with the master key 112 can produce ciphertext 134. Similarly, the server 104 can use the corresponding master key 112 to encrypt and / or decrypt data associated with the contactless card 136.

[0035] In other embodiments, the master key 112 of the contactless card 136 and the server 104 can be used in conjunction with a counter 110 to enhance security using key distribution. The counter 110 includes a value that is synchronized between the contactless card 136 and the server 104.Counter 110 may include a number that changes with each data exchange between contactless card 136 and server 104 (and / or contactless card 136 and computing device 102). When data is ready to be sent (e.g., to server 104 and / or device 102), applet 108 of contactless card 136 may increment counter 110. Applet 108 of contactless card 136 may then provide master key 112 and counter 110 as input to a cryptographic algorithm, which produces scatter key 114 as output. The cryptographic algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cryptographic message authentication code (CMAC) algorithms, and the like. Non-limiting examples of cryptographic algorithms may include symmetric cryptographic algorithms such as 3DES or AES107; symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC. Examples of key dispersion techniques are described in more detail in U.S. Patent Application No. 16 / 205,119, filed November 29, 2018. The entire contents of the aforementioned patent application are incorporated herein by reference.

[0036] Continuing with the example of key dispersion, applet 108 may then use dispersion key 114 and data as input to a cryptographic algorithm to encrypt data (e.g., customer ID 116 and / or any other data). For example, encrypting customer ID 116 with dispersion key 114 may produce an encrypted customer ID (e.g., ciphertext 134). In some embodiments, ciphertext 134 is included as a parameter of URL 120. In other embodiments, ciphertext 134 is not a parameter of URL 120, but is transmitted along with URL 120 in a data packet such as an NDEF file. Operating system 138 may then read the data packet including URL 120 and ciphertext 134 via communication interface 122 of computing device 102.

[0037] As described above, ciphertext 134 may be a parameter of URL 120. For example, URL 120 could be “http: / / www.example.com / passcodegenerator?param=ABC123”. In such an example, ciphertext 134 could correspond to the parameter “ABC123”. However, if ciphertext 134 is not a parameter of URL 120, then URL 120 could be “http: / / www.example.com / passcodegenerator”. Regardless of whether URL 120 includes ciphertext 134 as a parameter, URL 120 can be registered with account application 118, which causes operating system 138 to launch account application 118 and provide URL 120 and ciphertext 134 as input to account application 118.

[0038] Account application 118 may then transmit ciphertext 134 along with a request to generate a password to server 104. In embodiments where URL 120 includes ciphertext 134 as a parameter, account application 118 extracts ciphertext 134 from URL 120 and transmits a request with ciphertext 134 to an address associated with password generator 142, such as at least a portion of URL 120. In some embodiments, 118 makes an application programming interface (API) call to password generator 142. Further, account application 118 may include another identifier, such as an unencrypted customer ID 116 provided by applet 108 in the data packet. In some embodiments, the other identifier may be an identifier of contactless card 136, an account identifier, etc. In such embodiments, account application 118 may include instances of one or more portions of account database 130 to determine other identifiers.

[0039] In one embodiment, password 150 may be a remedial password or a pre-set password. A remedial password is a password generated in response to a prompt after a user has specified an expected transaction. An example of a remedial password is a one-time password (OTP). An OTP can be a time-based OTP (TOTP) or a hash-based OTP (HOTP). In contrast to a remedial password, a pre-emptive password is a password generated before the user has specified any such expected transaction. Therefore, this password is generated in advance relative to any such expected transaction specified. The pre-emptive password can then be used to authorize one or more expected transactions without the user having specified the expected transaction when the pre-emptive password is generated. In fact, the user may not even know that these transactions will be expected to be performed at some point in time when the pre-emptive password is generated.

[0040] As used herein, pre-emptive passwords are also referred to as independent passwords, while remedial passwords are also referred to as dependent passwords or non-independent passwords. The term "independent" is intended to indicate that a pre-emptive password can be used at a later point in time without the user actually having the contactless card.

[0041] For example, if a user requests to perform a transaction that requires an MFA, the user will be prompted to provide a password to authorize the transaction. In some embodiments, prompting the user includes instructing the user to swipe a contactless card onto a computing device to allow a password generator to generate a recovery password. The user can then provide the recovery password to an account application, which verifies whether the recovery password provided by the user matches the recovery password received from the password generator. If they match, the account application authorizes the transaction.

[0042] However, the password for authorizing a transaction can be recovery-based or pre-defined. It is assumed that in the previous example, when the user is prompted for a password, the user does not currently possess a contactless card, or the user is unable to be notified of the recovery password once it has been generated.This often occurs when a user is traveling. For example, a user may leave their contactless card at home. Additionally or alternatively, the user's current mobile operator network may be unable to communicate with the server and its associated systems.

[0043] There are also other users whose computing devices cannot run the application, or who simply choose not to run the application on their computing devices. Examples of such computing devices include mobile devices that constitute smartphones, mobile devices that do not constitute smartphones (such as laptops or flip phones), and non-mobile devices such as personal computers. Such users may instead access the organization's web application to run the application.

[0044] In some embodiments, the web application may provide only a subset of the scope of functionality provided by the web application. For example, it is conceivable that even if the application is able to provide the ability to retrieve and view a pre-generated password previously generated for the user (e.g., via the user's different computing devices), the web application may not provide the ability to identify the contactless card by swiping it. However, in other embodiments, as an example, the network application may still provide the function of identifying contactless cards by swiping, provided that the network application determines that the user's computing device includes or is operatively connected to a near-field communication (NFC) device coupled with an antenna capable of communicating via the NFC protocol.

[0045] Thus, regardless of the specific use case, the user's computing device may be unable to receive, for example, short message service (SMS) messages from a computing system associated with a given institution. In one embodiment, the computing device's inability to receive SMS messages may be due to differences in network protocols such as Code Division Multiple Access (CDMA) and Global System for Mobile Communications (GSM). The given institution may be a financial institution that at least partially provides and / or maintains a banking system including user accounts. Additionally or alternatively, the given institution may also issue contactless cards and / or provide and maintain account applications and / or servers. Specification 6 / 22 pages 9 CN 121890040 A

[0046] In one embodiment, the password generation techniques described herein are applied in part or entirely to generating passwords, regardless of whether the password is a remedial password or a pre-defined password. In at least one embodiment, the remedial cipher and the pre-emptive cipher differ from each other only in a set of cipher properties. For example, in a particular embodiment, the remedial cipher is valid for a single use only within five minutes, while the pre-emptive cipher is valid for any number of uses within thirty days. The numbers five minutes and thirty days are given by way of example only and are not intended to limit the scope of the disclosed embodiments. According to embodiments, the remedial cipher may be valid for durations shorter or longer than five minutes. Additionally or alternatively, the pre-emptive cipher may be valid for durations shorter or longer than thirty days.

[0047] In some embodiments, regardless of whether the password 150 is a remedial password or a pre-defined password, the password 150 may be associated with one or more validity criteria 152. In such embodiments, the password 150 is considered valid only if it meets one or more validity criteria 152. As shown, one or more validity criteria 152 include, but are not limited to, a validity period 1521 and a maximum number of uses 1522. The validity period 1521 specifies the time period during which the password 150 is considered valid.

[0048] According to an embodiment, the validity period 1521 may be expressed in the form of an expiration date and / or time (e.g., June 15, 2023, 00:00:00) or in the form of a given time length (e.g., 30 days). If this time period has elapsed, the password 150 is no longer valid. In alternative embodiments, the password 150 does not have any associated validity period. In such embodiments, the password 150 is either not associated with any validity period or is associated with a specific value (e.g., a null value) that is arbitrarily predefined to indicate that the validity period is not applicable. If password 150 is not associated with any expiration period, then password 150 is valid as long as the maximum number of uses 1522 has not been reached.

[0049] The maximum number of uses 1522 specifies the maximum number of times password 150 can be used. Password 150 remains valid as long as the current number of uses of password 150 has not reached the maximum number of uses 1522. In alternative embodiments, password 150 does not have any maximum number of uses. In such embodiments, password 150 is either not associated with any maximum number of uses or is associated with a specific maximum number (e.g., -1) that is arbitrarily predefined to represent unlimited use. If password 150 is not associated with any maximum number of uses, then password 150 is valid as long as the expiration period 1521 has not expired.

[0050] In one embodiment, the maximum number of uses 1522 specifies a single use as the maximum value. If password 150 is a pre-generated password, then password 150 may be referred to as a non-reusable pre-generated password to avoid confusion with OTP, which, unlike a non-reusable pre-generated password, is generated reactively rather than pre-generated.

[0051] Additionally or alternatively, according to one embodiment, the maximum number of uses 1522 may specify a number greater than 1 as the maximum value (e.g., five uses). Such a password may be the same password that can be used to authorize the execution of multiple different operations. If such a password is a pre-set password, it may be referred to as a reusable pre-set password. The maximum number of uses may be customized as needed to suit the requirements of a particular situation.

[0052] In some embodiments, the validity period 1521 and / or the maximum number of uses 1522 may be determined based on institutionally set criteria and / or based on user input.In alternative embodiments, the determination of the validity period 1521 and / or the maximum number of uses 1522 is not based on any input from the user, but is determined solely based on institutionally set criteria.

[0053] Figure 1B depicts an embodiment in which an account application 118 transmits a password request 146 to a server 104, including ciphertext 134 and an unencrypted identifier. Once received, the server 104 may attempt to authenticate the ciphertext 134. For example, the authentication application 126 may attempt to decrypt the ciphertext 134 using a copy of the master key 112 stored by the server 104. In some embodiments, the authentication application 126 may use an unencrypted customer ID 116 (or other identifier) ​​provided by the account application 118 to the server 104 to identify the master key 112 and the counter 110. In some examples, the authentication application 126 may provide the master key 112 and the counter 110 as input to a cryptographic algorithm that produces a scatter key 114 as output. The resulting distributed key 114 may correspond to the distributed key 114 of the contactless card 136, which can be used to decrypt the ciphertext 134. Specification 7 / 22 page 10 CN 121890040 A

[0054] Regardless of the decryption technique used, the authentication application 126 can successfully decrypt the ciphertext 134, thereby verifying or authenticating the ciphertext 134 in the password request 146 (e.g., by comparing the customer ID 116 generated from decrypting the ciphertext 134 with a known customer ID stored in the account database 130, and / or based on an indication of successful decryption using the master key 112 and / or the distributed key 114). Although keys 112 and 114 are described as being stored in memory 128, the keys may be stored elsewhere, such as in a secure element and / or HSM 132. In such embodiments, the secure element and / or HSM 132 can use the master key 112 and / or the distributed key 114, along with a cryptographic function, to decrypt the ciphertext 134. Similarly, the secure element and / or HSM 132 can generate a distributed key 114 based on the master key 112 and counter 110 as described above. If decryption is successful, the authentication application 126 can identify the user's contact information stored in the account database 130, such as email address, phone number, device identifier of the instance registered to the account application 118, device identifier of the computing device 102, etc. The authentication application 126 can identify the contact information based on the unencrypted identifier included in the password request 146. The authentication application 126 can then instruct the password generator 142 to generate a password and transmit the password to the identified contact information.

[0055] However, if the authentication application 126 cannot decrypt the ciphertext 134 to produce the expected result (e.g., the customer ID 116 of the account associated with the contactless card 136), the authentication application 126 does not verify the ciphertext 134.In such examples, authentication application 126 avoids generating a password. Authentication application 126 may transmit an indication of decryption failure to account application 118.

[0056] FIG1C depicts an embodiment in which authentication application 126 transmits decryption result 148 to account application 118. Decryption result 148 typically indicates whether server 104 has decrypted ciphertext 134 or not. In the example depicted in FIG1C, decryption result 148 indicates that server 104 has decrypted ciphertext 134. Account application 118 can use decryption result 148 to determine whether ciphertext 134 has been decrypted. Based on successful decryption, password generator 142 may generate password 150 based on the determined contact information and transmit it to computing device 102. Password 150 may be any alphanumeric string of any length. If the contact information is a telephone number, password generator 142 may transmit password 150 via Short Message Service (SMS) message. If the contact information is an email address, password generator 142 may transmit password 150 via email. If the contact information is a device identifier, the password generator 142 can transmit the password 150 as part of a push notification to the computing device 102.

[0057] The user can then provide the received password as input to the account application 118 via a user interface. The account application 118 can then compare the user-provided input with an instance of the password 150 received from the password generator 142. In another embodiment, the account application 118 can transmit user input to the password generator 142, which performs the comparison. If the password generator 142 performs the comparison, it transmits the comparison result to the account application 118. In some embodiments, the user can provide input to another application, such as a web browser 140 that has loaded a page associated with the password generator 142. The web page can then perform the comparison. If the comparison result matches, multi-factor authentication can be completed, and the user may be able to perform one or more requested actions. For example, the user can view account attributes, perform account-related actions, make payments, transfer funds, view balances, etc.

[0058] Figures 2A-2I are schematic diagrams illustrating various aspects of the subject matter according to some embodiments. Referring to Figure 2A, schematic diagram 200a is shown to illustrate an embodiment in which a contactless card 136 is swiped to a computing device 102. Although the computing device 102 is depicted as the screen outputting the operating system 138 (e.g., the home screen), the computing device 102 can typically be in any state. For example, when the contactless card 136 is swiped to the computing device 102, the user may be using another application, such as a web browser 140.

[0059] As described above, when the contactless card 136 is swiped to the computing device 102, the app 108 can generate ciphertext 134 and URL 120. In some embodiments, ciphertext 134 is a parameter of URL 120. The app 108 may also include identifiers, such as an unencrypted customer ID 116, an identifier of the contactless card 136, etc. If ciphertext 134 is a parameter of URL 120, then an unencrypted identifier can also be a parameter of URL 120. Regardless of whether ciphertext 134 and / or the unencrypted identifier are parameters of URL 120, ciphertext 134, the unencrypted identifier, and URL 120 can be included in data packets (such as NDEF files) read by the computing device 102. As shown, in response to receiving a data packet, the operating system 138 can launch the account application 118 because URL 120 (or a portion thereof) can be registered in the account application 118 within the operating system 138.

[0060] FIG2B illustrates an embodiment in which the account application 118 is opened in response to the operating system 138 reading the URL 120 received from the contactless card 136. As shown, the account application 118 instructs the user to provide a first authentication factor, which may be a biometric credential. The account application 118 may verify the biometric credential and, based on the verification, generate a password request 146 for a password 150 from a password generator 142. In one embodiment, the password 150 may be a remedial password such as an OTP. As described above, the account application 118 may transmit ciphertext 134 and an unencrypted identifier to the password generator 142. In some embodiments, the password request 146 may be an API call.

[0061] The authentication application 126 may then attempt to decrypt the ciphertext 134, as described in more detail above. If decryption is successful, the authentication application 126 may identify contact information for the user account in the account database 130. In some embodiments, the contact information is identified based on an unencrypted identifier (e.g., an unencrypted customer ID 116, device ID, etc.). The authentication application 126 can then instruct the password generator 142 to generate a password 150 and transmit the password 150 to the contact information. The authentication application 126 can also transmit the decryption result 148 to the account application 118.

[0062] FIG2C shows a schematic diagram 200c of an embodiment in which the password 150 is sent as a push notification 202 to the computing device 102. The user can be instructed to enter the password 150 in the input field 204. As previously mentioned, the password 150 can be a recovery password such as an OTP. As shown, the push notification 202 allows the user to select the push notification 202 to automatically fill the password 150 into the field 204.For example, when selected, the autofill service of operating system 138 (not shown) can copy password 150 and fill password 150 into field 204. In another example, password 150 can be copied to the clipboard of operating system 138 (not shown). This allows the user to paste password 150 from the clipboard into field 204.

[0063] As shown, password 150 can be entered as input to field 204. Account application 118 can then verify password 150 entered into field 204, for example, by comparing the input with an instance of password 150 received from password generator 142. In another example, account application 118 provides input to field 204 to password generator 142, password generator 142 performs a comparison and returns the comparison result to account application 118. If the comparison result matches, account application 118 can determine that multi-factor authentication is complete.

[0064] Figure 2D shows a schematic diagram 200d of an embodiment where the input provided in field 204 matches password 150. Based on the matching and decryption of ciphertext 134, a user can log in to their account in account application 118. As shown, account application 118 displays various account attributes, such as account balance. The embodiments are not limited to this, as the MFA using password 150 can be used to authorize any requested operation.

[0065] Figure 2E shows a schematic diagram 200e of an embodiment providing users of computing device 102 with options associated with different password types, including remedial passwords and pre-set passwords. In some embodiments, the options constitute a menu of the account application. Furthermore, this menu can be the main menu of the account application. As shown, computing device 102 presents options to the user, including a first option 206 for generating a remedial password and a second option 208 for generating a pre-set password.

[0066] These options also include a third option 210 for viewing a generated pre-set password. In some embodiments, if a still valid and generated pre-set password does not exist, the third option 210 is omitted from the display or displayed as unselectable. The options also include a fourth option 212 for viewing a user account summary and a fifth option 214 for accessing additional options associated with the user account. These additional options may include requesting the execution of a desired operation, such as initiating a transfer of the desired amount (see page 9 / 22 of the manual, CN 121890040 A), making a bill payment, etc.

[0067] If the computing device 102 receives user input activating the first option 206 to generate a remedial password, then schematic diagrams 200a and 200b of Figures 2A-2B may be applied. If the computing device 102 receives user input activating the second option 208 to generate a pre-set password, then schematic diagram 200f of Figure 2F may be applied.If computing device 102 receives user input activating third option 210 to view the generated pre-existing password, then schematic diagram 200g of FIG2G is applicable.

[0068] If computing device 102 receives user input activating fifth option 214 to access additional options, and receives further input specifying a desired transaction requiring the user to provide a second authentication factor, then schematic diagram 200h of FIG2H is applicable if the pre-existing password has been previously generated and is valid, and schematic diagram 200i of FIG1 is applicable if no valid and generated pre-existing password has been found.

[0069] FIG2F shows schematic diagram 200f of an embodiment where the user has requested the generation of a pre-existing password. As shown, schematic diagram 200f includes a notification 216 instructing the user to swipe contactless card 136 toward computing device 102 to generate a pre-existing password. After the contactless card 136 is swiped, schematic diagram 200g of FIG2G is applicable.

[0070] Figure 2G illustrates a schematic diagram 200g of an embodiment where a user has swiped a contactless card 136 onto computing device 102 to generate a pre-prepared password. As shown, schematic diagram 200g includes a notification 218 informing the user that a pre-prepared password has been generated. Notification 218 may specify the validity period of the pre-prepared password (if any) and / or the maximum number of times the pre-prepared password can be used (if any). Schematic diagram 200g also includes an option 220 for returning to the main menu, such as the menu included in schematic diagram 200e of Figure 2E.

[0071] Figure 2H illustrates a schematic diagram 200h of an embodiment where a user is prompted to provide a second authentication factor so that the expected transaction can be authorized, wherein the user has previously requested the generation of a pre-prepared password. As shown, schematic diagram 200h includes a notification 222 indicating that the user requires the user to provide a second authentication factor for the operation to be performed. Schematic diagram 200h also includes an input field 224 in which the user is prompted to enter a password (such as a remedial password or a pre-prepared password) to authorize the expected operation. Schematic diagram 200h also includes an option 226 for viewing a previously generated pre-prepared password that is still valid. As shown, option 226 also notifies the user that such a pre-set password is indeed available for viewing.

[0072] Figure 2I shows a schematic 200i of an embodiment where the user is prompted to provide a second verification factor in order to expect the transaction to be authorized, wherein the user has not previously requested the generation of a pre-set password. Schematic 200i includes a notification 228 that no pre-set password is available for viewing. Schematic 200i also includes an option 230 to return to the main menu, such as the menu included in schematic 200e of Figure 2E. As shown, option 230 also notifies the user that a contactless card is required to generate a remedial password or a pre-set password. Aspects related to generating and using a remedial password are further described in conjunction with the sequence diagrams of Figures 5A-5C and the flowchart of Figure 6.

[0073] The operation of the disclosed embodiments can be further described with reference to the accompanying drawings.Some diagrams may include logical flows. Although the diagrams presented herein may include specific logical flows, it is understood that the logical flows only provide examples of how the general functions described herein can be implemented. Furthermore, unless otherwise stated, a given logical flow does not necessarily have to be performed in the order presented. Moreover, in some embodiments, not all actions shown in the logical flow are necessary. Furthermore, a given logical flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. Embodiments are not limited thereto.

[0074] FIG3 illustrates an embodiment of a logical flow or routine 300. Routine 300 may represent some or all of the operations performed by one or more embodiments described herein. For example, routine 300 may include some or all of the operations to enable secure generation of passwords using contactless cards. Embodiments are not limited thereto. Although the password is specifically depicted as an OTP in routine 300, such description is for illustrative purposes only. According to embodiments, some or all of the operations of routine 300 may be applicable to both generating remedial passwords (10 / 22 pages, 13 CN 121890040 A) and pre-defined passwords.

[0075] In block 302, routine 300 receives a Uniform Resource Locator (URL) 120 and ciphertext 134 from a contactless card 136 associated with an account by an operating system 138 executing on a processor of computing device 102. In block 304, routine 300 launches an account application 118 associated with the contactless card 136 by the operating system 138 in response to receiving the URL 120. However, in some embodiments, the account application 118 is executed in the foreground of the operating system 138 and does not need to be launched. In such embodiments, a user can request to perform operations such as viewing an account balance, transferring funds, etc.

[0076] In block 306, routine 300 transmits the ciphertext 134 to an authentication server, such as server 104 in one embodiment, by the account application 118. The account application 118 may further include unencrypted identifiers (e.g., customer ID 116 and / or device identifier) ​​to the authentication application 126. In block 308, routine 300 receives a decryption result 148 from server 104 from account application 118, which indicates that the authentication server has decrypted ciphertext 134.

[0077] In block 310, routine 300 transmits a request for a password, including an identifier, to server 104 based on the decryption result from account application 118. The identifier may be an unencrypted customer ID 116, a device identifier, and / or an identifier for contactless card 136. In block 312, routine 300 determines contact information in account database 130 from server 104 based on the identifier. The contact information may include, but is not limited to, telephone number, email address, device identifier, etc.In block 314, routine 300 receives password 150 from password generator 142 at the determined contact information by computing device 102. In block 316, routine 300 receives input value from user by account application 118.

[0078] In block 318, routine 300 compares the input value with a copy of the password received from password generator 142 by account application 118. In block 320, routine 300 determines that the comparison result matches by account application 118. In block 322, routine 300 displays one or more attributes of the account on the device based on decryption result 148 and the determination that the comparison result matches. Additionally and / or alternatively, account application 118 may authorize the execution of user-requested operations based on the determination that the comparison result matches and decryption result 148.

[0079] Figure 4 illustrates an embodiment of the logic flow or routine 400. Routine 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, routine 400 may include some or all of the operations to enable secure generation of a password using a contactless card. The embodiments are not limited thereto. Similar to FIG. 3, although the password is specifically depicted as an OTP in routine 400, such description is for illustrative purposes only. According to embodiments, some or all of the operations of routine 400 may be applicable to generating both remedial and pre-set passwords.

[0080] In block 402, routine 400 receives a Uniform Resource Locator (URL) 120 and ciphertext 134 from a contactless card 136 associated with an account by an operating system 138 executing on a processor of computing device 102. Applet 108 may generate ciphertext 134 as described in more detail herein. Applet 108 may also transmit an unencrypted identifier, such as a customer ID 116, to computing device 102. In block 404, routine 400 initiates an account application 118 associated with the contactless card 136 by operating system 138 in response to receiving URL 120. In block 406, routine 400 transmits ciphertext 134 to an authentication server, such as server 104 in one embodiment, by account application 118. Account application 118 may also transmit an unencrypted identifier to the authentication server.

[0081] In block 408, routine 400 receives a decryption result 148 from the authentication server, which indicates that the authentication server has decrypted ciphertext 134. In block 410, routine 400 transmits a request for a password including the identifier to a URL based on the decryption result 148. The identifier may be an unencrypted customer ID 116, a device identifier, and / or an identifier for a contactless card 136. In block 412, routine 400 determines contact information in account database 130 based on the identifier by server 104. Contact information may include, but is not limited to, telephone numbers, email addresses, device identifiers, etc.In block 414, routine 400 receives password 150 from password generator specification page 11 / 22, CN 121890040 A 142 at URL 120 by computing device 102 at the determined contact information. In block 416, routine 400 receives input value by account application 118. In block 418, routine 400 compares the input value with a copy of password 150 received from password generator 142 by account application 118. In block 420, routine 400 determines that the comparison result matches. In block 422, routine 400 displays one or more attributes of the account on the device based on the determination of the comparison result match and based on the decryption result 148.

[0082] Figures 5A-5C are timing diagrams depicting routines 500, 530, 560, which may represent some or all of the operations performed according to one or more embodiments described herein. For example, routines 500, 530, and 560 may include some or all of the operations to enable authentication operations based on wireless communication with the contactless card. In one embodiment, routines 500, 530, and 560 are executed by one or more of the contactless card, computing device, and server. In a particular embodiment, the contactless card, computing device, and server may be the contactless card 136 of FIG. 1, computing device 1021, and server 104, respectively. However, the embodiments herein are not limited thereto.

[0083] In one embodiment, routine 500 includes the operation of generating a password based on wireless communication with the contactless card, while routines 530 and 560 represent alternative methods of applying a password to authorize the desired operation. In embodiments where the web browser does not support card swiping, the operation of computing device 1021 may be performed by the account application in the cases of FIG. 5A-5C or by the web browser in the cases of FIG. 5B-5C. However, if such card swiping is supported, the operation of computing device 1021 may be performed via a web browser even in the case of FIG. 5A.

[0084] In one embodiment, if a user expects to generate a password based on communication with the contactless card, routine 500 of FIG5A can be executed. As shown, routine 500 begins at block 502, where computing device 1021 submits a login request. In block 504, server 104 approves the login request based on credentials provided with the login request. In block 506, computing device 1021 receives user input specifying the generated password. The password can be a remedial password or a pre-set password. In some embodiments, in the case of a remedial password, block 506 is executed only after the user submits a request to perform the desired operation after logging in and server 104 prompts for a password to authorize the operation.

[0085] In block 508, computing device prompts the user to swipe contactless card 136 towards computing device 1021. In block 510, the user swipes contactless card 136 towards computing device 1021.In block 512, computing device 1021 receives ciphertext from contactless card 136. In block 514, computing device 1021 sends the ciphertext and an unencrypted identifier to server 104.

[0086] In block 516, server 104 generates a password based on the ciphertext and associates the password with the unencrypted identifier. In block 518, computing device 1021 outputs an indication that the password has been generated. According to an embodiment, the indication may include or omit the password itself. If the indication omits the password, the user can then submit a separate request to retrieve the password for display on computing device 1021. After block 518, routine 500 terminates.

[0087] In one embodiment, if a user wishes to apply a password to authorize a desired operation, routine 530 of FIG5B can be executed. As shown, routine 530 begins at block 532, where computing device 1021 submits a login request. In block 534, server 104 approves the login request based on the credentials provided along with the login request. In this respect, server 104 accepts the credential as the user's first authentication factor. In block 536, computing device 1021 receives user input specifying a desired operation related to the user's account.

[0088] In block 538, server 104 determines whether the desired operation requires a second authentication factor for approval. This determination may be based on one or more rules applied by server 104 to evaluate the desired operation. If the desired operation has the characteristic that it does not require a second authentication factor under one or more rules, then server 104 may approve the execution of the desired operation. For example, if the desired operation is to transfer a certain amount (e.g., five hundred US dollars) to a target account, where the amount is below a threshold (e.g., five thousand US dollars), then server 104 may approve the desired operation.

[0089] On the other hand, if the desired operation has the characteristic that it requires a second authentication factor under one or more rules, then server 104 determines whether a pre-generated password has been generated and is still valid. If so, computing device 1021, in block 540 and based on communication with server 104, additionally presents an option to view a pre-set password. Otherwise, computing device 1021, in block 540, only prompts for user input for a specified password (such as a remedial password or a pre-set password).

[0090] In block 542, computing device 1021 may optionally request, based on user input, to retrieve a stored password from server 104. In block 544, the server receives the request, retrieves the stored password, and sends the password to computing device 1021. Computing device 1021 receives and outputs the password to display to the user.

[0091] In some embodiments, the password is received via SMS and output via a messaging application separate from the account application.However, in alternative embodiments, the password is received by the account application using the same protocol (e.g., Secure Hypertext Transfer Protocol (HTTPS)) used to communicate with the server, rather than via SMS through a messaging application. In such embodiments, the password is output to the user via the account application rather than via a messaging application.

[0092] Regardless of whether the operations in blocks 542 and 544 are performed, in block 546, computing device 1021 receives user input specifying a password. For example, the user can specify a password via an input device such as a microphone, touchscreen, touchpad, keyboard, pointing device, etc. In one embodiment, due to the execution of blocks 542 and 544, the user can provide a password based on their viewing of stored passwords. Alternatively, the user can provide a password based on user recollection of previously viewed stored passwords. Computing device 1021 sends the specified password to server 104.

[0093] In block 548, server 104 determines whether the specified password matches a stored password (such as a remedial password or a pre-set password). In the case of a pre-set password, if server 104 determines that a match exists, server 104 accepts the specified password as a second authentication factor for the user and approves the execution of the desired operation; the desired operation is then executed. In this respect, the desired operation is approved without the user having to swipe the contactless card 136 again at computing device 1021. The fact that the contactless card 136 does not need to be swiped again is represented by box 552.

[0094] More specifically, the contactless card 136 does not need to be swiped during or after the time period based on the user input specifying the desired operation (in box 536). In other words, when executed as part of a user's request to generate a pre-set password, the previous swiping of the contactless card 136 is allowed to carry over in time to apply to one or more desired operations. Advantageously, one or more desired operations can still be authorized even if the user does not currently possess a contactless card and / or is not currently connected to a mobile operator network capable of receiving passwords from server 104 or its associated computer.

[0095] On the other hand, in the case of the remedial cipher in block 548, if server 104 determines that a match exists, server 104 accepts the specified cipher as a second authentication factor for the user and approves the execution of the desired operation; the desired operation is then executed. However, unlike a pre-set cipher, in at least some embodiments, using a remedial cipher in block 548 requires the user to swipe a contactless card in or after block 536 to generate a remedial cipher, which is then provided in block 540. If the user does not currently possess a contactless card and / or is not currently connected to a mobile operator network capable of receiving ciphers from server 104 or its associated computer, swiping the contactless card is required to prevent the user from generating and using a remedial cipher to authorize the desired operation.

[0096] Therefore, in situations where the desired operation cannot be authorized without a favorable change in the relevant conditions of the user's usage, an alternative to using a pre-prepared password (provided that the pre-prepared password has been generated in advance at the user's request) can allow the desired operation to be authorized and executed. In other words, the desired operation may be in a situation where success or failure depends on whether the pre-prepared password is supported by a computing environment provided at least in part by an institution to which the user is a customer.

[0097] Examples of favorable changes include the user becoming a holder of the contactless card or a new or replacement contactless card, the user becoming a holder of a computing device operatively connected to a mobile operator's network capable of receiving passwords from server 104 or its associated computing, and so on. In practice, if the user is traveling, the user may need to return from the trip to allow the favorable change described on pages 13 / 22 of the specification, 16 CN 121890040 A, to be implemented. This is especially true when the institution's policy prohibits mailing new or replacement contactless card entities to any temporary mailing address. Additionally or alternatively, for security purposes, the policy may only allow physical mailing to the new permanent address after a specified time delay (e.g., a 30-day waiting period).

[0098] As an alternative to routine 530 of FIG. 5B, if the user expects to apply a password to authorize the desired operation, routine 560 of FIG. 5C can be performed. Unlike routine 530 where the password is specified by the user without a service agent, routine 560 involves the user specifying the password to a service agent (such as a call center agent). Routine 560 is useful to the user, especially when the user does not currently have a computing device capable of running the account application or when the user expects an agent to assist in utilizing specific features of the account application.

[0099] In this regard, the password can be specified to the call center agent by the user verbally stating the password to the call center agent during a voice call. The call center agent hears the verbally stated password and enters it into an application executed on the call center agent's computing device 1022. According to an embodiment, the application may be a customer service application, which is a standalone application operatively connected to a server, or alternatively, the application may be a customer service interface to a server. Furthermore, the application may be a local application, or alternatively, a web browser operatively connected to a web application included in or operatively connected to the server.

[0100] Once a password is entered, the application and / or the server can determine whether the password can be used to authorize the desired operation. If so, the application outputs an indication to the call center agent that the desired operation has been approved, and the call center agent may verbally convey the approval to the user via an audio call.Otherwise, the application outputs an indication to the call center agent that the password is invalid and / or the expected operation is denied, and the call center agent may convey the same information to the user via an audio call.

[0101] As shown, routine 560 begins at block 562, where computing device 1022 sends a request for customer information to server 104 based on the information input by the call center agent to the user provided during the audio call. This information may include customer and / or account information associated with the user. In block 564, server 104 identifies an account belonging to the user and / or stored additional information associated with the account and / or user. Server 104 sends an account indicator and / or additional information to computing device 1022 for output to the call center agent.

[0102] The call center agent then requests the user to verbally narrate the additional information via an audio call as a first authentication factor for the user. In block 568, the call center agent manually verifies whether the narrated additional information matches stored additional information, or inputs the information into computing device 1022 and / or the server to automatically verify whether the narrated additional information matches stored additional information. If a match is determined, the call center agent may request the user to verbally state the desired action to be performed via an audio call. After hearing the user's verbal statement of the desired action, the call center agent may provide input specifying the desired action to computing device 1022. Computing device 1022 then sends the input to server 104.

[0103] In block 570, server 104 determines, based on the input, whether the desired action has the characteristic of requiring the user to provide a second authentication factor to the call center agent based on rules. If no second authentication factor is required, server 104 approves the action to be performed, and server 104 may send the approval instruction to computing device 1022 to output to the call center agent for verbal communication to the user via an audio call.

[0104] Otherwise, the call center agent verbally requests the user to provide a password as a second authentication factor to authorize the desired action to be performed. After the user verbally states the password to the call center agent via an audio call, in one embodiment, computing device 1022 receives input specifying the user-statement password from the call center agent in block 572. The computing device 1022 then sends the password to the server 104 to determine in box 578 whether the stated password is acceptable as a second authentication factor.

[0105] If the stated password is determined to be acceptable as a second authentication factor, the transaction is approved for execution. In the case where the stated password is a pre-set password, the transaction is approved without requiring the user to re-swipe the contact card 136 on the computing device 1021 (not specified on page 14 / 22 of the manual, 17 CN 121890040 A).Specifically, the user does not need to swipe the contactless card 136 when or after verbally describing the desired transaction to the call center agent for input in box 568. The absence of needing to swipe the contactless card 136 is indicated by box 580.

[0106] On the other hand, in the case where the described password is a remedial password, the user needs to swipe the contactless card 136 to the computing device 1022 when or after verbally describing the desired transaction to the call center agent for input in box 568. This means that in the absence of a pre-defined password, if the user does not currently possess the contactless card 136, and / or if the computing device 1021 is not possessed by the user and / or its currently connected carrier network cannot communicate with the server and its associated systems, the operation cannot be approved or executed.

[0107] In an alternative embodiment, the computing device 1022 receives one or more stored passwords recognized as valid by the server 104 from the server 104 in box 572. The one or more stored passwords are output via computing device 1022 to be displayed to a call center agent, who can then manually verify whether the stated password matches one or more of the stored passwords. The call center agent can then provide computing device 1022 with input indicating whether the call center agent manually finds a match or manually determines that no match exists, to be sent to server 104. Server 104 can then approve or deny the operation based on the input in block 578, and the call center agent can verbally convey the approval or denial to the user via an audio call.

[0108] FIG6 illustrates an embodiment of a logic flow or routine 600. Routine 600 may represent some or all of the operations performed according to one or more embodiments described herein. For example, routine 600 may include some or all of the operations to implement an authentication operation based on wireless communication with a contactless card. In one embodiment, routine 600 is performed by a server (e.g., server 104 of FIG1). The embodiments are not limited thereto.

[0109] As shown, the routine begins at block 610, where the server stores a password generated based on ciphertext read from a contactless card. This password is generated in response to the device detecting the contactless card. Furthermore, the password has an associated account and associated validity criteria.

[0110] In block 620, the server receives one or more requests, each request specifying the execution of a corresponding operation associated with an account. Each request also specifies a corresponding password. Each password can be either a remedial password or a pre-defined password. A remedial password is generated after the operation is specified as expected based on user input. In contrast, a pre-defined password is generated before the operation is specified as expected based on user input.

[0111] In block 630, the server enters a loop to process each of one or more requests, such as determining whether to authorize an operation based on a remedial password or a pre-set password. In block 640, the server determines whether the password specified in the request matches a stored password.

[0112] For example, the server determines whether the remedial password specified in the request matches a stored remedial password. Alternatively, the server determines whether the pre-set password specified in the request matches a stored pre-set password. In some embodiments, a password match is accepted only if the password types also match. In such embodiments, a remedial password and a pre-set password are not considered a match even if the associated password values ​​are the same. However, in alternative embodiments, password types do not need to match if the password values ​​are the same.

[0113] If the server determines in block 640 that a match has been found, routine 600 continues to block 650, where the server determines whether one or more validity criteria for the stored password are still met. For example, the server may determine whether an associated expiration date (if any) has passed and / or whether an associated maximum number of uses (if any) has been reached.

[0114] If the server determines in block 650 that one or more validity criteria are still met, routine 600 continues to block 660, where the server authorizes the execution of the requested operation. In the case where the password is a pre-defined password, the operation is authorized, and the user's computing device needs to detect the contactless card when or after the operation is specified by the user as the desired execution.

[0115] In some embodiments, the operation may be authorized independently based on any one of multiple passwords, including remedial and pre-defined passwords. In other words, it may not be necessary for the server to accept only a single password as a valid password to authorize the execution of the operation. However, in alternative embodiments, the server accepts only a single password as a valid password. In such embodiments, each password (whether remedial or pre-defined) is automatically deactivated when a new password (whether remedial or pre-defined) is generated.

[0116] After box 660, or if the determination in box 640 or 650 is negative, routine 600 continues to box 670, where the server refuses to authorize the operation. Therefore, the operation is not performed. After box 660 or 670, routine 600 continues to box 680, where the server determines, as part of a loop, whether any requests remain to be processed. If so, routine 600 returns to box 630 to process the remaining requests. Otherwise, routine 600 terminates.

[0117] Figure 7A illustrates a schematic diagram 700 of an example configuration of a contactless card 136, which may include a payment card (such as a credit card, debit card, or gift card) issued by a service provider (as shown by the service provider mark 702 on the front or back of the contactless card 136). In some examples, the contactless card 136 is not a payment card and may include, but is not limited to, an identity card. In some examples, the transaction card may include a dual-interface contactless payment card and a rewards card, etc. The contactless card 136 may include a substrate 704, and the substrate 308 may include a single layer or one or more laminates composed of plastics, metals, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 136 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may additionally conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 136 according to this disclosure may have different characteristics, and this disclosure does not require the transaction card to be implemented as a payment card.

[0118] The contactless card 136 may also include identification information 706 displayed on the front and / or back of the card, and a contact pad 708. The contact pad 708 may include one or more pads and is configured to establish contact with another client device (such as an ATM, user equipment, smartphone, laptop, desktop, or tablet computer) via the transaction card. The contact pad may be designed according to one or more standards (such as the ISO / IEC 7816 standard) and is capable of communicating according to the EMV protocol. The contactless card 136 may also include processing circuitry, antennas, and other components, as will be further discussed in FIG. 7B. These components may be located behind the contact pad 708 or elsewhere on the substrate 704, for example, within different layers of the substrate 704, and may be electrically and physically coupled to the contact pad 708. The contactless card 136 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card (not shown in FIG. 7A). The contactless card 136 may also include an NFC device coupled to an antenna that is capable of communicating via the NFC protocol. Embodiments are not limited to this approach.

[0119] As shown in FIG1A, the contact pad 708 of the contactless card 136 may include processing circuitry 710 for storing, processing, and communicating information, including a processor 712, a memory 106, and one or more communication interfaces 122. It should be understood that the processing circuitry 710 may include additional components necessary for performing the functions described herein, including a processor, memory, error and parity / CRC checkers, a data encoder, an anti-collision algorithm, a controller, a command decoder, security primitives, and tamper-proof hardware.

[0120] Memory 106 may be a read-only memory, a write-multiple-read memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 136 may include one or more of these memories. Read-only memory may be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read multiple times. Write-multiple-read memory may be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory may be programmed and reprogrammed many times after leaving the factory. Specification 16 / 22 pages 19 CN 121890040 A Read / write memory may also be read multiple times after leaving the factory. In some cases, memory 106 may be an encrypted memory that uses an encryption algorithm executed by processor 712 to encrypt data.

[0121] Memory 106 may be configured to store one or more applets 108, one or more counters 110, customer ID 116 and master key 112, distribution key 120 and URL 120. One or more applets 108 may include one or more software applications configured to execute on one or more contactless cards, such as the Java® Card applet. However, it should be understood that one or more applets 108 are not limited to the Java Card applet, but may be any software application that can operate on a contactless card or other memory-limited device. One or more counters 110 may include a numeric counter sufficient to store integers. Customer ID 116 may include a unique alphanumeric identifier assigned to a user of the contactless card 136, and this identifier may distinguish the user of the contactless card from other contactless card users. In some examples, customer ID 116 may identify a customer and the account assigned to that customer and may further identify the contactless card 136 associated with the customer's account.

[0122] Referring now to FIG. 7B, the processor 712 and memory elements of the foregoing exemplary embodiments are described with reference to contact pad 708, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of contact pad 708, or completely separate from it, or as further elements in addition to the processor 712 and memory 106 elements located within contact pad 708.

[0123] In some examples, the contactless card 136 may include one or more antennas 714. One or more antennas 714 may be placed within the contactless card 136 and surrounding the processing circuitry 710 of the contact pad 708. For example, one or more antennas 714 may be integrated with the processing circuitry 710, and one or more antennas 714 may be used in conjunction with an external reinforcement coil. As another example, one or more antennas 714 may be external to the contact pad 708 and the processing circuitry 710.

[0124] In one embodiment, the coil of the contactless card 136 may act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 136 by cutting off power or by amplitude modulation. The contactless card 136 may use gaps in the power connection of the contactless card 136 to infer data transmitted from the terminal, which may be functionally maintained by one or more capacitors. The contactless card 136 may communicate in reverse by switching loads or load modulation on the coil of the contactless card 136. Load modulation may be detected in the terminal coil by interference. More generally, using one or more antennas 714, processor 712 and / or memory 106, the contactless card 136 provides a communication interface for communication via NFC, Bluetooth and / or Wi-Fi communication.

[0125] As described above, the contactless card 136 may be built on a software platform operable on a smart card or other memory-limited device such as a JavaCard, and may securely execute one or more applications or applets. App 108 can be added to a contactless card to provide a cipher for multi-factor authentication (MFA) in various mobile application-based use cases. App 108 can be configured to respond to one or more requests (such as near-field data exchange requests) from a reader (such as a mobile NFC reader, e.g., a mobile computing device 102 or a point-of-sale terminal) and generate an NDEF message including a cryptographically secure cipher encoded as an NDEF text tag. The NDEF message may include a URL 120, ciphertext 134, and any other data.

[0126] An example of an NDEF cipher is an NDEF short record layout (SR=1). In such examples, one or more app 108 can be configured to encode the cipher as a known type of text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. App 108 can be configured to add one or more static tag records in addition to the cipher record.

[0127] In some examples, one or more app 108 can be configured to simulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, different password data is presented each time the tag is read, which can indicate the authenticity of the contactless card. Based on one or more applets 108, the tag's instruction manual (pages 17 / 22, 20 CN 121890040 A) can be processed for NFC reading, and the data can be transmitted to a server, such as an institution's (e.g., a banking system) server, and the data can be verified at the server.

[0128] In some examples, the contactless card 136 and the server may include specific data so that the card can be correctly identified. The contactless card 136 may include one or more unique identifiers (not shown).Counter 110 can be configured to increment each time a read operation occurs. In some examples, counter 110 is transmitted to a server for verification each time data is read from contactless card 136 (e.g., by a mobile device) to determine whether counter 110 is equal to the server's counter (as part of the verification).

[0129] One or more counters 110 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if counter 110 has been read, used, or otherwise transmitted. If counter 110 has not been used, it can be replayed. In some examples, the incrementing counter on contactless card 136 is different from the counter incremented for a transaction. Since there is no communication between applets 108 on contactless card 136, contactless card 136 cannot determine the application of transaction counter 110. In some examples, contactless card 136 may include a first applet 440-1 (which may be a transaction applet) and a second applet 440-2. Each mini-program 440-1 and 440-2 may include a corresponding counter 110.

[0130] In some examples, counter 110 may become out of sync. In some examples, to address unexpected reads that initiate transactions, such as reads at an angle, counter 110 may be incremented but the application does not process counter 110. In some examples, NFC may be enabled when mobile device 10 is woken up, and device 102 may be configured to read available tags but not to take action in response to the read.

[0131] To keep counter 110 in sync, an application (such as a background application) may be executed, which will be configured to detect when mobile device 102 wakes up and synchronize with the bank system's server, indicating reads that occur due to the detection, and then move counter 110 forward. In other examples, a hashed one-time password may be used to allow a certain window of asynchrony to be accepted. For example, if within a threshold of 10, counter 110 may be configured to move forward. However, if the threshold number is within a different range, such as 10 or 1000, a request to perform resynchronization can be processed, which is a request made by one or more applications to the user to tap, gesture, or otherwise indicate once or multiple times via their device. If the counter 110 increments in an appropriate sequence, it can be known that the user has done so.

[0132] The key distribution technique described herein with reference to the counter 110, the master key, and the distribution key is an example of an encryption and / or decryption key distribution technique. This example key distribution technique should not be considered as a limitation of this disclosure, as this disclosure is equally applicable to other types of key distribution techniques.

[0133] During the creation process of the contactless card 136, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys may include symmetric keys, which can be used for encryption and decryption of data.The Triple DES (3DES) algorithm can be used by EMV and implemented in hardware within the contactless card 136. By using key distribution processing, one or more keys can be derived from the master key based on unique identifiable information for each entity requiring the key.

[0134] In some examples, to overcome the vulnerability of the 3DES algorithm, which may be susceptible to vulnerabilities, session keys (such as unique keys for each session) can be derived instead of using the master key; unique card-derived keys and counters can be used as distribution data. For example, each time the contactless card 136 is used in an operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. This ultimately results in a triple encryption layer. Session keys can be generated by one or more applets and derived using an application transaction counter employing one or more algorithms (as defined in EMV 4.3, Volume 2, A1.3.1, Common Session Key Derivation).

[0135] Furthermore, the increment of each card can be unique and can be assigned through personalization or algorithmically through some identification information. For example, odd-numbered cards can increment by 2, and even-numbered cards can increment by 5. In some examples, the increment can also vary in sequential reading, such that a card can increment in the order of 1, 3, 5, 2, 2... The specific sequence or algorithm sequence can be defined in the personalization time or from one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0136] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record can be encoded in hexadecimal format. In another example, the NDEF record can be encoded in hexadecimal format.

[0137] Figure 8 illustrates an NDEF short record layout (SR=1) data structure 800 according to an example embodiment. One or more mini-programs can be configured to encode passwords as well-known type text tags of NDEF type 4. In some examples, the NDEF message may include one or more records. The mini-program can be configured to add one or more static tag records in addition to the password record. Exemplary tags include, but are not limited to, tag type: well-known type, text, encoded English (en); mini-program ID: D2760000850101; function: read-only access; encoding: the authentication message may be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as a personalized parameter that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record having a well-known index for providing the actual dynamic authentication data.Data structure 800 may include URL 120, ciphertext 134, and any other data provided by applet 108.

[0138] FIG9 illustrates an embodiment of an exemplary computer architecture 900 suitable for implementing the various embodiments described above. In one embodiment, computer architecture 900 may include or be implemented as part of computing architecture 100.

[0139] As used herein, the terms “system” and “component” are intended to refer to computer-related entities: hardware, combinations of hardware and software, software or software in execution, examples of which are provided by the exemplary computing computer architecture 900. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. For example, an application running on a server and the server itself may both be components. One or more components may reside in a process and / or an execution thread, and components may be localized on a single computer and / or distributed across two or more computers. Furthermore, components may be communicatively coupled to each other through various types of communication media to coordinate operations. Coordination may involve one-way or two-way information exchange. For example, components may convey information in the form of signals transmitted via a communication medium. This information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, other embodiments may alternatively employ data messages. Such data messages may be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0140] Computer architecture 900 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, and power supplies, etc. However, these embodiments are not limited to those implemented by computing architecture 100.

[0141] As shown in FIG9, computing architecture 900 includes processor 902, system memory 904, and system bus 906. Processor 902 may be any of a variety of commercial processors.

[0142] System bus 906 provides interfaces for system components, including but not limited to system memory 904 to processor 902. System bus 906 can be any of several types of bus architectures, which can be further interconnected to memory bus (with or without memory controller), peripheral bus, and local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to system bus 906 via a slot architecture.Example slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and similar architectures as described on pages 19 / 22 of this specification, CN 121890040 A.

[0143] Computer architecture 900 may include or implement various articles of manufacture. Articles of manufacture may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, and writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and similar code. Embodiments may also be implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium that can be read and executed by one or more processors to perform the operations described herein.

[0144] System memory 904 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory (such as ferroelectric polymer memory), austenite memory, phase change or ferroelectric memory, silicon oxide silicon oxynitride (SONOS) memory, magnetic cards or optical cards, arrays of devices (such as redundant array of independent disks (RAID) drives), solid-state memory devices (e.g., USB memory), solid-state drives (SSDs), and any other type of storage medium suitable for storing information. In the exemplary embodiment shown in FIG9, system memory 904 may include non-volatile memory 908 and / or volatile memory 910. The Basic Input / Output System (BIOS) can be stored in non-volatile memory 908.

[0145] The computer 912 may include various types of computer-readable storage media in the form of one or more low-speed memory cells, including an internal (or external) hard disk drive 914, a disk drive 916 for reading or writing to a removable disk 918, and an optical disc drive 920 for reading or writing to a removable optical disc 922 (e.g., a CD-ROM or DVD). The hard disk drive 914, disk drive 916, and optical disc drive 920 may be connected to the system bus 906 via an HDD interface 924, an FDD interface 926, and an optical disc drive interface 928, respectively. The HDD interface 924 for an external drive implementation may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0146] The drives and associated computer-readable media provide volatile and / or non-volatile storage devices for data, data structures, and computer-executable instructions, etc. For example, many program modules may be stored in the drive and non-volatile memory 908 and volatile memory 910, including operating system 930, one or more applications 932, other program modules 934 and program data 936. In one embodiment, one or more applications 932, other program modules 934 and program data 936 may include, for example, various applications and / or components of system 100.

[0147] Users may input commands and information to computer 912 through one or more wired / wireless input devices (e.g., keyboard 938 and pointing devices such as mouse 940). Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses and similar input devices. These and other input devices are typically connected to the processor 902 via an input device interface 942 coupled to the system bus 906, but may be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, and IR interfaces.

[0148] A display 944 or other type of display device is also connected to the system bus 906 via an interface such as a video adapter 946. The display 944 may be located inside or outside the computer 912. In addition to the display 944, the computer typically includes other peripheral output devices such as speakers and printers. Specification 20 / 22 pages 23 CN 121890040 A

[0149] The computer 912 may operate in a network environment using logical connections to one or more remote computers (such as one or more remote computers 948) via wired and / or wireless communications.One or more remote computers 948 may be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment devices, peer-to-peer devices, or other public network nodes, and typically include many or all of the elements described relative to computer 912, although for brevity only memory and / or storage devices 950 are shown. The depicted logical connections include wired / wireless connections to local area networks 952 and / or larger networks (e.g., wide area networks 954). Such LAN and WAN networking environments are commonplace in offices and companies and facilitate enterprise-wide computer networks (such as intranets), all of which can be connected to global communication networks (e.g., the Internet).

[0150] When used in a local area network 952 networking environment, computer 912 is connected to local area network 952 via a wired and / or wireless communication network interface or network adapter 956. Network adapter 956 can facilitate wired and / or wireless communication with local area network 952, and local area network 956 may also include a wireless access point thereon for communicating with the wireless capabilities of network adapter 956.

[0151] When used in a networked environment of wide area network 954, computer 912 may include modem 958, or a communication server connected to wide area network 954, or have other means for establishing communication on wide area network 954, such as via the Internet. Modem 958 may be internal or external and may be a wired and / or wireless device connected to system bus 906 via input device interface 942. In a networked environment, program modules or portions thereof depicted relative to computer 912 may be stored in remote memory and / or storage device 950. It should be understood that the network connections shown are exemplary and other means of establishing communication links between computers may be used.

[0152] Computer 912 is operable to communicate with wired and wireless devices or entities using IEEE 802 series standards, such as wireless devices operable in wireless communication (e.g., IEEE 802.11 air modulation technology). This includes at least Wi-Fi (or wireless LAN), WiMax, and Bluetooth™ wireless technologies and others. Thus, the communication can be a predefined structure like a conventional network, or simply self-organizing communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use media and functions associated with IEEE 802.3).

[0153] The various elements of the device previously described with reference to Figures 1A-9 may include various hardware elements, software elements, or a combination of both.Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, and inductors), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, and chipsets. Examples of software elements may include software components, programs, applications, computer programs, applications, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, programs, software interfaces, application interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware elements and / or software elements can vary depending on many factors, such as desired computational speed, power levels, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints required by a given implementation.

[0154] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represents various logic within a processor, causing the machine to manufacture the logic to perform the techniques described herein when the machine reads these instructions. Such representation (referred to as an “IP core”) may be stored on a tangible machine-readable medium, page 21 / 22 of the specification, 24 CN 121890040 A, and provided to various customers or manufacturing facilities for loading into a manufacturing machine that manufactures the logic or processor. For example, some embodiments may be implemented using a machine-readable medium or article that may store instructions or instruction sets that, if executed by a machine, may cause the machine to perform the methods and / or operations according to the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and / or software.Machine-readable media or articles may include, for example, any suitable type of memory cell, memory device, memory article, memory medium, storage device, storage article, storage medium and / or memory cell, such as memory, removable or non-removable medium, erasable or non-erasable medium, writable or rewritable medium, digital or analog medium, hard disk, floppy disk, optical disc read-only memory (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), optical disc, magnetic medium, magneto-optical medium, removable memory card or disk, various types of digital multifunction disk (DVD), magnetic tape, cassette tape or the like. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0155] The above exemplary embodiments are provided for illustrative and descriptive purposes. They are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible according to the disclosure. The intention is that the scope of this disclosure is not limited by this detailed description, but by the claims appended herein. Future applications claiming priority to this application may claim the disclosed subject matter in different ways and may generally include any set of one or more limitations as disclosed herein in various ways or otherwise demonstrated.Instruction manual page 22 / 22, 25 CN 121890040 A, Figure 1A; Instruction manual figure 1 / 23 page 26 CN 121890040 A, Figure 1B; Instruction manual figure 2 / 23 page 27 CN 121890040 A, Figure 1C; Instruction manual figure 3 / 23 page 28 CN 121890040 A, Figure 2A; Instruction manual figure 4 / 23 page 29 CN 121890040 A, Figure 2B; Instruction manual figure 5 / 23 page 30 CN 121890040 A, Figure 2C; Instruction manual figure 6 / 23 page 31 CN 121890040 A, Figure 2D; Instruction manual figure 7 / 23 page 32 CN 121890040 A, Figure 2E; Instruction manual figure 8 / 23 page 33 CN 121890040 A, Figure 2F; Instruction manual figure 9 / 23 page 34 CN 121890040 Figure 2G, Appendix 10 / 23, Page 35, CN 121890040; Figure 2H, Appendix 11 / 23, Page 36, CN 121890040; Figure 2I, Appendix 12 / 23, Page 37, CN 121890040; Figure 3, Appendix 13 / 23, Page 38, CN 121890040; Figure 4, Appendix 14 / 23, Page 39, CN 121890040; Figure 5A, Appendix 15 / 23, Page 40, CN 121890040; Figure 5B, Appendix 16 / 23, Page 41, CN 121890040; Figure 5C, Appendix 17 / 23, Page 42, CN 121890040; Figure 5C (continued), Appendix 18 / 23, Page 43, CN 121890040; Figure 6, Appendix 19 / 23. Page 44 CN 121890040 A Figure 7A Description Drawing 20 / 23 Page 45 CN 121890040 A Figure 7B Description Drawing 21 / 23 Page 46 CN 121890040 A Figure 8 Description Drawing 22 / 23 Page 47 CN 121890040 A Figure 9 Description Drawing 23 / 23 Page 48 CN 121890040 A.

Claims

1. A method, the method comprising: A password generated based on ciphertext read from a contactless card is stored by a server, wherein the password is generated in response to the device detecting the contactless card, and wherein the password is associated with an account and validity criteria; Receive one or more requests, each request specifying to perform a corresponding operation associated with the account, and each request also specifying a corresponding password generated before the corresponding operation was specified; as well as When it is determined that the password specified by the first request in one or more requests matches the password stored by the server and the validity criteria are still met, the operation specified by the first request is authorized, wherein the operation is authorized without the device re-detecting the contactless card.

2. The method according to claim 1, wherein, The validity criteria include a time validity period.

3. The method according to claim 1, wherein, The operation specified by the first request is also based on the authorization of verifying the authentication credentials of the account.

4. The method according to claim 2, wherein, The password is generated in response to a request to pre-generate the password for the validity period, wherein the password is not generated in response to any requested operation associated with the account, and wherein the request to pre-generate the password is in response to the request.

5. The method according to claim 2, further comprising: If it is determined that the password specified in the second request of the one or more requests does not match the password stored on the server and the expiration date has not yet passed, the device is required to (i) provide a matching password or (ii) re-detect the contactless card before authorizing the execution of the operation specified by the second request.

6. The method according to claim 2, further comprising: When it is determined that the password specified in the third request of the one or more requests matches the password stored on the server and the expiration date has passed, the device is required to re-inspect the contactless card before authorizing the execution of the operation specified by the third request.

7. The method according to claim 2, further comprising: When it is determined that the password specified in the fourth request of the one or more requests does not match the password stored on the server and the expiration date has expired, the device is required to re-inspect the contactless card before authorizing the execution of the operation specified by the fourth request.

8. The method according to claim 1, wherein, The password specified by the first request is provided based on input received via an input device selected from a microphone, touchscreen, touchpad, keyboard, and pointing device.

9. The method according to claim 8, wherein, The password specified in the first request is provided via at least one of a call center agent or a web browser application.

10. The method according to claim 8, further comprising: Receive a request to retrieve a password stored by the server; as well as Send a password stored by the server to an application on the device, wherein the application outputs the password, and the password specified by the first request is provided based on the output password.

11. The method according to claim 8, wherein, The input device is operatively connected to (i) a first device including the device or (ii) a second device other than the device.

12. The method according to claim 1, wherein, The one or more requests include multiple requests, and the corresponding operation of each of the multiple requests is based on the same password authorization stored by the server.

13. The method according to claim 1, wherein, The ciphertext and Uniform Resource Locator (URL) are readable from the contactless card via Near Field Communication (NFC).

14. The method according to claim 13, wherein, The server includes an authentication server, which is configured as follows: Receive the ciphertext from the device; The device transmits a decryption result, which indicates that the authentication server has decrypted the ciphertext; Receive a request for the password from the device, the request including an identifier based on at least one of a customer identifier, an account identifier, a device identifier, or a card identifier; The password is generated using a component of the authentication server, the component including a password generator accessible via the URL; and The password is transmitted to the device.

15. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to perform the following operations: The password is generated based on ciphertext read from a contactless card, wherein the password is generated in response to the device detecting the contactless card, and wherein the access code is associated with an account and validity criteria. Receive one or more requests, each request specifying to perform a corresponding action associated with the account, and each request further specifying a corresponding password generated prior to the specified action; and When it is determined that the password specified by the first request of the one or more requests matches the stored password and the validity criteria are still met, the operation specified by the first request is authorized to be performed, wherein the operation is authorized to re-detect the contactless card without the device.

16. The non-transitory computer-readable medium according to claim 15, wherein, The validity criteria include a time validity period.

17. The non-transitory computer-readable medium according to claim 15, wherein, The operation specified by the first request is also based on the authorization of verifying the authentication credentials of the account.

18. A system comprising: processor; and The memory stores instructions that the processor can use to cause the processor to perform the following operations: The password is generated based on ciphertext read from a contactless card, wherein the password is generated in response to the device detecting the contactless card, and wherein the access code is associated with an account and validity criteria. Receive one or more requests, each request specifying to perform a corresponding operation associated with the account, and each request also specifying a corresponding password generated before the corresponding operation was specified; as well as When it is determined that the password specified by the first request of the one or more requests matches the stored password and the validity criteria are still met, the operation specified by the first request is authorized to be performed, wherein the operation is authorized without the device re-detecting the contactless card.

19. The system according to claim 18, wherein, The validity criteria include a time validity period.

20. The system according to claim 18, wherein, The operation specified by the first request is also based on the authorization of verifying the authentication credentials of the account.

Images