Authentication system and method

Abstract

Tap to authenticate technology enables merchants to reduce fraud and errors for applications such as account funding and payment transactions, by enabling a consumer to tap their own card on their own mobile device to transmit encrypted card data to an acquirer for card authentication and transactions. The technology provided merchants with greater access to reduced fraud and error, making transactions more secure and error-free.

Description

AUTHENTICATION SYSTEM AND METHODREFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims the benefit of and incorporates by reference the following U.S. Provisional Applications: U.S. Prov. Ser. No. 63 / 535,221 filed August 29, 2023, and U.S. Prov. Ser. No. 63 / 606,588 filed December 5, 2023.FIELD

[0002] This patent specification relates to authentication systems and methods. More particularly, this patent specification relates to systems and methods for authenticating an ultimate user such as a customer that is believed to be both simpler and more effective than known authentication approaches for reducing fraud and error, especially in on-line transactions.BACKGROUND AND SUMMARY OF THE DISCLOSURE

[0003] Authentication or verification of cards such as credit and debit cards is susceptible to both fraud and error. The risk of fraud and error associated with the use of such cards increases in environments in which the providers of goods and / or services and purported cardholder are not physically present in in the same location, such as in on-line environments. In known authentication system, the user and / or a provider of goods or services must input one or more authentication factors, sometimes using multiple communication channels such as phone messaging and emails. In some cases, a specific short time relationship between transmission of a user identification and a response from a second communication channel and active / inactive status of an authentication function are relied upon. Such security measures tend to increase complexity, are prone to human error, and I or are susceptible to fraud.

[0004] According to some embodiments single tap authentication system for fraud and error reduction in on-line transactions using a tap of a consumer’s card on the consumer’s mobile device and a unique secure token comprises: a near field communication (NFC) enabled mobile device of a consumer storing a merchantapplication and configured to respond to a tap with an NFC enabled credit, debit, prepaid, or stored value card of the consumer on the consumer’s mobile device to extract and output encrypted card data; an acquirer processor of an acquirer configured to receive the output encrypted card data from mobile device, store the received output encrypted card data or a processed version thereof, and generate therefrom a unique secure token related to the output encrypted card data from the consumer’s card; wherein said token has an expiration time enabling selective use of the token in a current transaction and / or in a future transaction of the consumer with the merchant and / or an issuer of the card; wherein said acquirer processor is further configured to transmit the token generated thereby to a merchant backend; and wherein the mobile device is configured to store the token received thereby and utilize the token in authentication of a current transaction between the consumer and the merchant or an issuer of the card and / or in a future such transaction.

[0005] The system can further include one or more of the following: (a) the mobile device is configured to use the token stored therein in a transaction with an issuer of the card; (b) the acquirer processor is configured to generate and transmit a verification request in response to a card network in response to the encrypted card data and to transmit to the merchant backend processor a verification result; and (c) the mobile device is configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.

[0006] According to some embodiments, a single tap authentication system comprises: a customer’s mobile device equipped with an internal near field communication (NFC) device and storing a merchant application, and a card equipped with an internal near field communication (NFC) device, wherein the mobile device is configured to respond to a tap with the card to extract from the card and transmit encrypted card data; an acquirer server configured to receive and decrypt the transmitted encrypted card data, store the decrypted card data, generate and store a unique secure token related to the card data, and obtain card verification status; and a merchant server configured to interact with the customer’s mobile device without a need to store the card data; wherein the acquirer server is further configured totransmit the secure token and card verification status to the customer’s mobile device and the merchant server is configured to receive the secure token and verification status from the acquirer server or from the customer’s mobile device and proceed with a card-paid transaction based thereon.

[0007] According to some embodiments, the system described in the immediately preceding paragraph can further include one or more of the following: (a) the system can further include a card network, wherein the acquirer server is further configured to transmit a request for an authorization related to the tapped card and the card network is configured to receive and evaluate the request for authorization and transmit to the acquirer server a response indicative of whether a transaction with the tapped card is authorized; (b) the system can further include a card issuer, wherein the card network is configured to respond to the request for authorization from the acquirer server by transmitting a verification request to the card issuer, the card issuer is configured to respond to the verification request by transmitting verification status to the acquirer server and the acquirer server is configured to include data regarding the verification status in the verification result transmitted thereby to the customer’s mobile device; (c) the merchant server is further configured to transmit a request for additional verification to the acquirer server and the acquirer server is further configured to obtain verification data that is in addition to the card data and transmit to the merchant server a response based on the additional verification data; (d) the acquirer server is configured to transmit the secure token to the merchant server instead of or in addition to transmitting the secure token to the consumer’s mobile device; (e) the acquirer server is further configured to generate an authentication time limit data indicative of a future time up to which the secure token remains valid, and to transmit the time limit data directly or indirectly to at least one of the merchant server and the consumer’s mobile device, wherein additional or future transaction with the card would not require tapping the consumer’s card on the consumer’s mobile device to effectuate a paying transaction with the card through the consumer’s mobile device; and (f) the mobile device is configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.

[0008] According to some embodiments, an authentication system comprises: a near field communication (NFC) enabled mobile device of a consumer storing a merchant application and configured to respond to a tap with an NFC enabled card of the consumer to extract and transmit encrypted card data derived from the card; an acquirer processor of an acquirer configured to receive and decrypt the encrypted card data, store a decrypted version of the card data, and generate from the card data a unique secure token related to the card data; wherein said token has an expiration time enabling selective use of the token in a current transaction and / or in a future transaction of the consumer with the merchant or an issuer of the card without requiring an additional tap; wherein said acquirer processor is further configured to transmit a request for verification to a payment or card network and to transmit the token generated thereby and a response to the verification request to at least one of the merchant backend and the consumer’s mobile device as; and wherein the mobile device is configured to store the token received thereby and utilize the token in authentication of a current transaction between the consumer and the merchant or an issuer of the card and / or in a future such transaction.

[0009] According to some embodiments, the system described in the immediately preceding paragraph can further include the mobile device configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.

[0010] According to some embodiments, an authentication system comprises: a mobile device equipped with an internal near field communication (NFC) device and storing a merchant application, and a card equipped with an internal near field communication (NFC) device, wherein the mobile device is configured to respond to a tap with the card to extract card data from the card and transmit encrypted card data; a merchant server and an acquirer server, wherein the acquirer server is configured to receive the encrypted data directly from the mobile device and / or through the merchant server and to generate in response a unique secure token and to transmit a request for verification to a payment or card issuer network and transmit back to the mobile device and / or the merchant server the token and a result of the verification; and the mobile device and the merchant server are configured to process the tokenand verification results and to authenticate a transaction based thereon and on an age of the token.

[0011] According to some embodiments, the system described in the immediately preceding paragraph can further include the mobile device configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] To further clarify the above and other advantages and features of the subject matter of this patent specification, specific examples of embodiments thereof are illustrated in the appended drawings. It should be appreciated that these drawings depict only illustrative embodiments and are therefore not to be considered limiting of the scope of this patent specification or the appended claims. The subject matter hereof will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0013] FIGs. 1A and 1 B are diagrams illustrating an example of a consumer cardholder loading funds into an account / wallet using a merchant-provided application on a consumer’s mobile device according to some embodiments;

[0014] FIGs. 2A and 2B are diagrams showing further detail of decryption of the encrypted card data, according to some embodiments;

[0015] FIG. 2C is a diagram illustrating further details relating to additional verification measure, according to some embodiments;

[0016] FIGs. 3 and 4 are diagrams illustrating creation, storage and use of an account ID token, according to some embodiments;

[0017] FIG. 5 is a diagram showing further detail of a transaction being carried out using an earlier performed tap-to-pay authentication, according to some embodiments;

[0018] FIG. 6 is a diagram showing further aspects of a tap-to-authenticate process being carried out in an online environment, according to some embodiments;

[0019] FIG. 7 is a diagram illustrating further aspects of a consumer initiating a transaction some time after a tap-to-authenticate process has been carried out, according to some embodiments;

[0020] FIG. 8 is a diagram showing aspects of some additional verification features, according to some embodiments; and

[0021] FIG. 9 is a diagram illustrating further aspects of creation, storage and use of an account ID token, according to some embodiments.DETAILED DESCRIPTION

[0022] A detailed description of examples of preferred embodiments is provided below. While several embodiments are described, it should be understood that the new subject matter described in this provisional patent specification is not limited to any one embodiment or combination of embodiments described herein, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding, some embodiments can be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the new subject matter described herein. It should be clear that individual features of one or several of the specific embodiments described herein can be used in combination with features or other described embodiments. Further, like reference numbers and designations in the various drawings indicate like elements.

[0023] According to some embodiments, a tap-to-authenticate system will be described in further detail. The tap-to-authenticate system is a specific improvement to known authentication systems to increase security and to more reliably prevent unauthorized access by third parties. It is easily implemented and can advantageously be carried out with mobile devices of relatively low complexity that don’t require additional hardware for inputting or outputting data. Instead of requiring a user and / or a provider of goods or services to input multiple authentication factors using multiple communication channels with the customer / consumer such as phone and email channels, or relying primarily on a short time relationship between transmission of a user identification and a response from a second communication channel and active / inactive status of an authentication function, as in known authenticationsystems, the tap-to-authenticate system involves a novel token that is unique to a transaction and / or a customer-provider relationship. The tap-to-authenticate system focuses on a tap of a card of an ultimate user such as a consumer or customer on the ultimate user mobile device for secure interaction with a provider of goods of services such as a merchant and an “acquirer” serving as a resource for both the ultimate user and the provider and, if and as needed, for a card network. Unique encryption of the token and other features further enhance security. The system dispenses with a need for the ultimate user and / or the provider to manually ensure authentication or manually process authentication data. The tap-to-authenticate system thus enhances security with low complexity of user and provider equipment. An ordered combination of process steps proceeds with minimal manual input from involved parties.

[0024] An example of the tap-to-authenticate system is described below in which the ultimate user is a customer or consumer, the provider is a merchant, and the acquirer is an entity servicing both. Merchants who may find the described systems and techniques valuable include those that rely on their customers to use a card to make payments, fund an account, and / or receive disbursements. This includes businesses that accept credit card payments through traditional payments, in-store, online, and over the phone. Businesses that have higher risks of fraud may also find the described systems and techniques valuable include financial technology companies (FinTechs) that support or enable banking and financial services for industries such as digital banking, early wage access, lending, gaming, personal finance, investing, remittances, blockchain & crypto, cash load, ISOs, on-demand wages, payroll, digital tipping, real estate, accounts payable and receivable. Although the term ‘merchant’ is often used herein, the described embodiments apply to many types of entities.

[0025] A tap-to-authenticate system further enables merchants to reduce fraud for account funding transactions, by enabling a consumer to tap their own card on their mobile device to transmit encrypted card data to an acquirer for card authentication and authenticated transactions. Using the described solution, merchants have greater access to reduced fraud and to making transactions more secure, when compared to other known solutions. The tap-to-authenticate system uses unique tokens,encryption, range of relative timing of authentication and execution of transactions and other techniques to improve computer and network systems and to reduce fraud and errors. It reduces fraud risks and difficulties associated with known prior approaches that rely on a merchant’s transmission and verification devices and / or two-step and two-way verification requiring manual entries of authentication parameters that can be hacked or can introduce errors.

[0026] According to some embodiments, tap-to-authenticate technology involves implementation by an acquirer. As used herein, the term "acquirer," which in some embodiments can be called "acquiring bank," "merchant acquirer," and "merchant bank," refer to a processing system operated by or providing services to an entity such as a bank or a financial institution that processes credit or debit card payments on behalf of a merchant, a merchant, and / or a card user. The acquirer allows merchants to accept credit and / or debit card payments from the card-issuing banks within a card network or card association, such as Visa, MasterCard, Discover, China UnionPay, American Express, Accel, Star, NYCE, and Pulse. An acquirer provides merchants with the ability to reduce fraud and errors for account funding transactions, by enabling a consumer to use their own card and own mobile device to transmit encrypted card data to an acquirer for card authentication and transactions.

[0027] FIGs. 1 A and 1 B are diagrams illustrating an example of a consumer cardholder loading funds into an account / wallet using a merchant-provided application on a consumer’s mobile device according to some embodiments. In this example, merchant 130 provides an application, such as a mobile app 112, to allow a consumer cardholder 120 to load funds into an account / wallet. Merchant 130 is provided with increased protection against fraudulent activity through several security checks initiated by only a tap of the customer’s card on the customer’s mobile device. In FIG. 1A, consumer 120 has installed the merchant app 112 on consumer's own device 110 (depicted by dashed arrow 132), which in this example is a mobile phone of consumer 120. In this example, consumer’s mobile phone 110 includes NFC module or device 150. Included in merchant’s app 112 is an SDK (Software Development Kit) 114. According to some embodiments, the SDK 114 can be provided by the acquirer 140 shown in FIG. 1 B.

[0028] In this example, merchant 130 wishes to authenticate the consumer’s card 103 to increase confidence that the consumer 120, who is making a purchase, is verified and is the real authorized cardholder for a valid card 103. With some common prior techniques, merchants may require a consumer to enter information such as the card number, card security code (e.g. CW, CSC, CVC, CAV, CID, CVD, EVE, CVN, CPC), and expiration date in an online form. Authentication using this form of card information has a substantial risk of fraud, since the merchant is not ordinarily physically present with the customer presenting the card information. The card information could have been obtained illegally or stolen from the real cardholder.

[0029] According to some embodiments, the tap-to-authenticate technology described herein is used wherein the consumer 120 takes their physical debit / credit card 103 and taps it on their own mobile device (e.g. NFC enabled mobile phone) 110, as shown in FIGs. 1A and 1 B. In FIG. 1A, arrow 101 shows the mobile app 112, supplied by merchant 130, prompting the consumer 120 to tap the consumer's card 103 on the consumer's own device 110. In this example, a prompting message 152 is displayed on consumer’s phone 110, although many other notification methods can be used instead or in combination. Currently, many cards are equipped with near-field communication (NFC) payment technology that enables them to interact with payment terminals. According to some embodiments, the tap-to-authenticate technology makes use of the NFC technology in the card to thereby effectively use consumer's own device, such as the consumer's mobile phone, as the "payment terminal." In this example, the consumer's mobile phone 110 and the consumer's card 103 are both equipped with NFC technology. NFC module 105 is shown on card 103 in FIG. 1 B and the NFC module 150 in device 110 is shown in FIG.s 1A and 1 B. Information such as: the card number, cardholder details and other card data information can come from the EMV chip 107 contained on the card 103. An EMV chip 107 is a chip conforming to the Europay, Mastercard and Visa standard. In some cases, EMV chip 107 includes NFC functionality and can also serve as NFC module 105. According to some embodiments, this process is enabled by a merchant using a software development kit (SDK) 114 that puts together the logic and flow needed for a merchant to use the tap-to-authenticate process. The SDK 114 includes a softwaremodule that interacts with the device's NFC hardware. When card 103 is near the field of NFC module 150, a connection is established, and the card data is read. The card 103 contains an Application Identifier, or AID, which matches EM s specifications. EMVCo’s specifications define how to read the data off the card. The software module 112 parses raw data from the card and maps the raw card data into a readable format. FIG. 1 B shows consumer’s card 103 being tapped on consumer’s mobile phone 110. The merchant application 112 using SDK 114 in this process acts as the receiver of the information of the card 103 through using NFC module 105 on mobile phone 110 to receive data 108 from card 103. According to some embodiments data 108 can include data in the form of or derived from one or more EMV tags which are formatted according the EMVCo’s specifications. A list of EMV tags for information that can be included in data 108 can be currently accessed at which is incorporated herein by reference. Althoughthere is a wide range of EMV tag information, examples of types that are suitable for authentication purposes in some applications include: 9F26 Application Cryptogram; 5A Application Primary Account (PAN); 5F20 Cardholder Name; 5F28 Issuer Country Code; 9F1 F Track 1 Discretionary Data; and 9F20 Track 2 Discretionary Data. According to some embodiments, the application 112 encrypts data 108 prior to storage and / or transmission. According to some embodiments, data 108 may be already encrypted and further encryption is not undertaken. Although payment card 103 is described in examples herein as a credit or debit card, in general card 103 can include other types of physical cards such as prepaid cards and stored value cards.

[0030] Further details of developing a suitable SDK 114 will now be provided, according to some embodiments. SDK 114 should be designed to enable several primary functions, including the following: (1 ) when consumers tap a payment card on their mobile device, communication is established with the card using the NFC module of device 110; (2) initiation of data extraction of authentication useful data; and (3) transmission of payment credentials that include the extracted data to the merchant to the acquirer on behalf of the merchant, where the payment credentials to be used for authentication processing in an online environment. When the SDK 114 is initialized within the mobile application 112, it activates the device 110’s NFC hardware to listenfor NFC connections. Upon presenting an NFC payment card, the SDK connects to the card, retrieves data, and identifies the Application Identifier (AID), which indicates the card's network, such as Visa, Mastercard, or other card brands. The SDK matches the AID against a pre-defined list of stored AIDs, determining the correct data format for interpreting the card's information. The extracted data elements are then mapped to the corresponding EMV Tag specifications, such as Track 1 and Track 2 discretionary data, and compiled into a EMV tag data dictionary representing the card data.

[0031] Once such data processing is complete, the SDK 114 may be further designed to collect additional data 109 that may be deemed useful for authentication in some cases, for example using mobile application 112. The additional data 109 can also be obtained directly from the user using input screens, such as address and other verification details. After gathering the processed card data 108 and any additional data 109, the SDK encrypts the processed card data 108 and additional data 109 as needed or desired. After encryption the SDK 114 is designed to transmit the encrypted data directly to the acquirer or export it to the application 112 for transmission.Following transmission, the SDK manages responses from the acquirer 140, which may include displaying error messages to the user, confirming successful authentication and returning an account ID token, indicating the card has been added to the user’s account. The SDK can also be designed to support "step-up" authentication, according to which in some cases only confirmation of successful authentication is requested for a previously authenticated card, and therefore no account ID token need be provided.

[0032] According to some embodiments, upon receiving and encrypting card data 108 by SDK 114 in the merchant's application 112 on consumer's mobile phone 110, additional information 109 is generated to aid in verification of the card 103 and the cardholder 120. Examples of the types of additional information include: card PIN; card holder ZIP Code (or post code); and device location at time of transaction.

[0033] Referring to FIG. 1 B, arrow 104 shows the encrypted data 108 from card 103 being transmitted to acquirer 140. In particular, the merchant application 112 uses the acquirer-provided SDK 114 to transmit the encrypted card data 108 andverification data 109 to the back end of acquirer 140. According to some embodiments, transmission 104 occurs over an API (Application Programming Interface) directly to the acquirer. According to some other embodiments, transmission 104 occurs over an API to the servers 134 of merchant 130, and then the merchant server 134 sends the information to the back end of acquirer 140.

[0034] According to some embodiments, once the card information is sent to acquirer's servers, the acquirer performs several steps to check the authenticity of the card data provided. FIGs. 2A and 2B are diagrams showing further detail of decryption of the encrypted card data, according to some embodiments. The decryption can happen, for example, after the encrypted card data is received from the merchant application or server (shown in FIG. 1 B, arrows 104 and / or 104’). FIG. 2A shows the case where decryption is performed by the acquirer 140. Block 209 shows merchant app 112 (including acquirer SDK 114) obtaining, encrypting and transmitting data to acquirer 140. The data is card data 108 and optionally additional data 109, as shown and described supra. Block 211 shows card data 108 and additional data 109 (if included) received and decrypted by acquirer 140 with acquirer's own hosted keys. When the acquirer 140 needs to verify a card's details, it uses the card network’s communication system 250 to send information to the card network and / or the card issuer 290. In block 212, the acquirer 140 initiates a query using the decrypted card information. According to some embodiments, an information request API is used which is sometimes referred herein as a ‘query card API.’ In this example, the information request API is used to check the status of the card for address verification. The card network 250 and / or issuer 290 then responds to the acquirer request through the card network communication system. In block 220 the API constructs a $0 authorization transaction to card network 250 (arrow 205). In block 222, card network 250 receives and evaluates the authorization request. In block 224, card network 250 sends a request to the card issuer 290. In block 230 the issuer 290 does the address validation and in block 232 returns the status of the verification to card network 250.According to some embodiments, the verification can be in the form of a code that indicates the degree degree to which the provided or stored items of information match. In one example, the code can reflect the following: “match,” “partial match” or“no match.” As described, infra, in block 232 the issuer 290 sends a response to the card network 250. In block 234, the card network 250 sends a corresponding authorization response (for $0) (arrow 206) to the acquirer 140 which includes the match code or status of verification. According to some embodiments, the card network can also be used to validate the card cryptogram that was obtained from card 103. According to one example, the card cryptogram is transmitted along with the $0 authorization transaction to the card network and the card network can provide an additional status of verification. In block 225 the acquirer 140 receives the response. In block 226, the acquirer 140 stores the received status of verification in the acquirer database (database 320 shown in FIG. 4) under an identifier known as AVS ID. In block 227, the acquirer generates and stores an account ID token 310, which is described in further detail infra. In block 228, the acquirer 140 then sends a response to the merchant with the match code, AVS ID and token 310. In block 229, the app 112 on consumers mobile device 110, receives the match code / verification status, AVS and token 310. The response from the card issuer may in some cases include a PAR number (arrow 206), which is essentially a card network equivalent of the acquirer’s account token ID. Although the terms AVSID and AVS ID are used in some examples, other forms of address verification services or codes could be used., i.e., the PAR number is a reference for the original card information but at a network level. In block 231 , the merchant 130 receives response, verification status and token 310 using access it has to its supplied app 112.

[0035] In general, information request APIs can be designed by an acquirer for various types of information requests, for example: (1 ) checking eligibility of source or destination accounts at a particular bank or financial institution for types of transactions, such a push and / or pull; (2) verifying one or more addresses, (as shown in FIG. 2A with arrows 205 and 206), or a card network and / or card issuer; (3) confirm security card code (CSC) or CW2 by an acquirer, card network and / or card issuer; and (4) verify cardholder names with services provided by an acquirer, card network and / or card issuer. Some examples using information request APIs are shown in FIGs. 2A, 2B, 6 and 9.

[0036] FIG. 2B shows the case where encryption was performed by an entity other than the acquirer, such as by the card network. The decryption is done by decrypting the card data through a payment or card network 250’s hosted keys (shown in FIG. 2B). In particular, at block 211 acquirer 140 sends the encrypted package to card network 250, represented by arrow 201 . In block 242, card network 250 decrypts the package using its hosted key. In block 244, card network 250 returns the decrypted package to acquirer 140 (arrow 203). As in the case of FIG. 2A, once the card data is decrypted, the acquirer validates the card using the card’s EMV information through an information request API (e.g. card query). In block 212, the acquirer initiates an information request API (e.g., Query Card API) using decrypted EMV card data and in block 220 the acquirer constructs a $0 authorization transaction to card network 250 (arrow 205). In block 222, card network 250 receives and evaluates the authorization request and, if desired in some cases, generates a PAR number. In block 224, card network 250 sends a request to the issuer 290. In block 230 the issuer does the card validation (this could be any or a combination of the validation methods mentioned above) and this validation returns match codes (match, partial match or no match) for the information provided. In block 232 the issuer 290 sends a response to the card network 250. In block 234, the card network 250 sends a corresponding authorization response (e.g. for $0) to the acquirer 140 which includes the match codes. In block 225 the acquirer 140 receives the response. In block 226, the acquirer 140 stores this the received status of verification in the acquirer database (database 320 shown in FIG. 4) under an identifier known as AVS ID. In block 227, the acquirer generates and stores an account ID token 310, which is described in further detail infra. In block 228, the acquirer 140 then sends a response to merchant’s app 112 running on consumer’s mobile device 110, with the match code, AVS ID and token 310. Although not shown in FIG. 2B, the merchant 130 receives the match code / verification status and the AVS ID. Alternative terms can be substituted for AVS and AVD ID, such as address verification code.

[0037] According to some embodiments, additional verification procedures or steps can be carried out to further enhance fraud prevention and provide increased security. Such additional verification features (AVFs) often rely at least in part onaccess to the decrypted EMV card data. FIG. 2C is a diagram illustrating further details relating to additional verification measure, according to some embodiments. In this example, merchant 130 requests one or more AVFs in block 260 by sending request 262 to acquirer 140. In block 264, acquirer 140 receive the request. In block 266 the acquirer initiates information request API. In block 270 the API evaluates the AVF request by comparing information from sources such as: (1 ) information received along with the AVF request; (2) decrypted EMV card data; (3) data logged or otherwise retained by the acquirer; (4) data received from merchant 130; and / or (5) device data obtained or available to the application 112. Some of these data sources 280 are depicted in FIG. 2C. In block 272 the API generates and sends a response 274 to the AVF request which is then received by merchant 130 in block 276.

[0038] As described, AVFs can also rely on device and / or merchant data. Additional verification features can take many forms, some examples are described in further detail herein. Some AVFs can be based on address and / or location, and some examples are sometimes referred to herein as an address validation service(s) (AVS). Note that the AVFs can be carried out before, during or after the authorization request, depending on when it is useful and when and where additional information with which the EMV card data is being compared to is obtained. Further detail of examples of additional security checks based on cardholder name, funding location country, and funding location postal code are given below and are also depicted in FIG. 8.

[0039] Cardholder Name. The acquirer 140 can verify the cardholder name using the card data and on-file information from the merchant. For example, the acquirer can compare the cardholder’s name on file from the merchant with the cardholder’s name present from the EMV card data.

[0040] Funding Location Country. The acquirer can verify the country where funding is taking place using a country code (for example logged by SDK 114 shown in FIGs. 1 A and 1 B) and the location of the consumers device. For example, acquirer 140 can compare the terminal country location that is in the terminal of app 112 to the user’s physical location from the user’s device 110. During a later transaction that relies on an authentication carried out by acquirer 140 authentication, for example anaccount funding step, the mobile application 112 can ask the user for location data. The merchant app 112 can supply that location data to application and transmit it to acquirer 140 during the tap-to-authenticate process. In general, this AVF can be carried out during tap-to-authenticate process, or it can be carried out during a later funding step. Acquirer 140 compares funding location information from the consumer, with the terminal country code from the terminal kernel and I or with the EMV card data chip. This process checks if the user is in the right country when loading the funds.

[0041] Funding Location ZIP Code. The consumer 120 can be asked to enter their ZIP Code (or post code), and the merchant 130 can then transmit that ZIP Code to the acquirer 140. The merchant 130 transmits consumer 120’s location at the time of tap-to-authenticate process. Note that in some cases devices allow an app, such as app 112, to be configured to request the mobile app user's location. The mobile app 112 can be configured to receive GPS location for the device (and / or consumer). A technique such as reverse geocoding can to translate the GPS data and determine the associated zipcode. The acquirer 140 can calculate a distance between the app 112 supplied location and the consumer 120’s entered ZIP Code. This AVF can be used to check if the consumer 120 is transacting from their own zipcode, a nearby zipcode or some other zipcode. The calculated distance can be used for assessing fraud and security risk, at least in part, based on merchant or the acquirer configurations. Note that this is an example of an AVF that does not rely on EMV data but is available because the consumer's own device 110 will often have the capability of obtaining other information (in this case the user's location) which can be used to facilitate an AVF. The AVF relies on the consumer 120 using their own device 110, and the AVFs improve the operation of computer systems and or computer networks since when the AVF is implemented there is less need for anti-fraud processes that can consume a significant amount of processing and or networking bandwidth.According to some embodiments, the process for comparing the ZIP code can be linked to terminal country code as well, if desirable depending on the application.

[0042] According to some embodiments, merchants can use the technology described herein to allow for ‘step up’ authorization or re-authorization. While manyexamples described herein are for a case where a merchant 130 is using a tap-to- authenticate solution in cases where a user, consumer 120, is trying to add a new card, many or all of the described techniques can also be later used when the merchant 130 wishes to perform a subsequent re-check, or step up authentication. Examples of when a merchant may desire to increase protection by requesting that the consumer re-authenticate a previously authorized card include when merchant 130 wishes to confirm that the consumer 120 still has possession of the card 103. The step-up authorization or re-check may be desirable, for example when transaction limit are reached, or some suspicious behavior is observed, such as frequency of transactions; or certain time limits have occurred. According to some embodiments, the merchant can use the same tap-to-authenticate procedures and systems to perform the desired step-up authentication. The step-up re-check session can be initiated through the app 112 and SDK 114. This system offers flexibility, allowing the merchant to decide when additional levels of authentication are necessary. The step- up authentication can be implemented at the acquirer or merchant's discretion so as to accommodate particular needs of each merchant.

[0043] A merchant may want to check if the consumer still has access to the card prior to making a payment. This could prevent bad actors from initiating a payment in an account takeover scenario. If the bad actor was required to tap a card already on file, in the event the bad actor did not have the card, they would not pass the authentication. According to some embodiments, the SDK 114 is configurable to allow these step-up or re-check procedures to be initiated by the merchant.

[0044] Another scenario making use of the systems and techniques described herein involves enabling consumers to add and authenticate cards on a different device when they are in a location that is remote from their mobile phone and connect them to the same session. This “remote add” card and authenticate process can be used then the consumer or user is interacting on internet-enabled devices that lack their own NFC or merchant app / SDK capabilities. Examples include a browser on a laptop and while using an app on a smart TV. For instance, if a consumer desires to add their card while using a device lacking NFC and / or merchant app / SDK capabilities, that device can display a QR code as a linking mechanism. Theconsumer can then scan the QR code and open an app or browser session on their device using the tap-to-authenticate SDK. The session will prompt the consumer to tap their card onto the device, and once they do, the tap-to-authenticate process will authenticate the card and transfer the payment credential. An acquirer token is generated and linked to the merchant. The other device's session will confirm that the card has been added, allowing the consumer to proceed with the transaction as usual.

[0045] FIGs. 3 and 4 are diagrams illustrating creation, storage and use of an important feature of the tap-to-authenticate system, namely, a unique account ID token, according to some embodiments. In block 301 (shown in FIG. 3), acquirer 140 creates an account ID token 310 (shown in FIG. 4) for the cardholder 120 and card 103. In block 303 acquirer 140 stores the account ID token 310 in a database 320 (FIG. 4). The account ID token 310 is a unique identifier that can be shared with other parties and allows the acquirer 140 to access card information 322 relating to card 103 that is securely stored on acquirer 140's database 320. According to some embodiments, card information 322 includes card data 108 shown in FIG. 1 B.According to some embodiments, card information 322 also may additionally include some or all of additional data 109. This mapping or referencing from the unique account ID Token 310 to card information 322 stored on database 320 is shown with dashed arrow 303 in FIG. 4 and dashed arrow 924 in FIG. 9. Examples of card information 322 include one or more of the following: card number, cvv, and exp date. Acquirer 140, through its SDK 114 for example, receives card information 322. Information 322 can be transmitted via an API. Upon receiving the information 322 the acquirer 140 can generate and securely store Account ID Token 310 to reference the card information 322. Note that card information 322 originates from the physical tapping of a card 103 on a consumer’s device 110 (namely data 108) and in some embodiments includes some or all of additional information 109. According to some embodiments, card information 322 is stored on acquirer database 320, is not shared with merchant 130, and merchant 130 does not have to store sensitive card information for future transactions. The token 310 can be as simple as a numerical value that when in the hands of the acquirer 140 is able to look up the encrypted data322. According to some embodiments, the token 310 can also contain other information, such as the expiry date and time.

[0046] In block 305 (FIG. 3) acquirer 140 includes token 130 in responding to an information request received from application 112. According to some embodiments, the Account ID token 310 has a built-in expiration timeline. Such expiration timeline can provide the dual benefits of enabling new kinds of transactions that allow for time delay between authentication of transaction execution and reducing clutter and storage requirements by discarding tokens 310 that have expired. Examples of expiry period range from very short time such as up to a few hours (e.g. in the case of there is some urgency, such as on-line or in casino gaming, to days, weeks or months for other use settings. In general, the expiry period will be set at the acquirer or merchant's discretion so as to accommodate particular needs of each merchant. According to some embodiments, the expiry period is set to at least one day (24 hours). According to some embodiments, the expiry period is set to at least one week. According to some embodiments, the expiry period is set to at least one month.According to some embodiments the expiry period is set to at least 6 months.According to some embodiments, the expiry period is set to expire when the card 103 expires. According to some embodiments, the expiry period is managed and held by the acquirer 140. In such cases the merchant 130 might also keep track of the expiry time and date for its own use without having to request it from the acquirer. According to other embodiments the expiry time and date can be included on the token itself.

[0047] According to some embodiments, the tap-to-authenticate systems and methods described herein can be used for in-person casino gaming. In some settings, a consumer / customer 120 is present in a casino gaming facility and uses an electronic wallet or account to use while gaming. In such settings, it may be desirable for the customer to tap-to-authenticate their payment card using their phone, to authenticate their payment card in advance of a gaming session. While the customer is gaming and wishes to transfer funds from the authenticated card into their account or electronic wallet, the customer can remain at the location of gaming machine rather than having to physically walk to a kiosk, or even access their phone or card toreauthorize it. In this case even though the customer is physically present within the gaming facility, they are considered not at the ‘point of sale,’ in that perspective.

[0048] Arrow 302 in FIG. 3 (and FIG. 9) shows the acquirer 140 returning a response to app 112 running on device 110. Note that the response can include AVS ID (or AVF ID), along with token 310 and may, if desired in a specific implementation, include PAR. In block 330, the application 112 on device 110 receives the response from acquirer 140. In block 410 the app 112 notifies consumer 120. In the case where the response indicates a successful authentication, the notification 401 can include a confirmation that the consumer's card has been successfully authenticated. The notification can also include a request that the consumer 120 follow through with an action such as adding the card 103 to their account. In block 412, consumer 120 receives the notification. In block 414, customer makes a decision. In the example of authorizing card 103 to be added to an account, the decision may be whether or not to follow through with adding card 103 to the account. Block 416 shows an affirmative response from the consumer. App 112 then adds the new card as an authorized card and displays a notification of the same. In the case where the consumer fails to confirm adding the card 103, the app may delete the card account along with other related material, such as the account ID token 310. The added card can be used for one or more purposes (e.g. online payment, online transaction, or funding an account of consumer 120). According to some embodiments, in cases where consumer 120 does not complete the add card process, merchant 130 can delete an account (if any) that merchant 130 had created, and also delete the Account ID Token 310. Arrow 401 (FIG. 4) shows the notification 452 being displayed to the consumer 120. In this case, the authorization was confirmed by the acquirer 140. Shown in FIG. 4 is an example 'notification 452 that the card was authenticated and the Consumer is being asked to add the card to their account. Consumer 120 responds with either ‘yes’ or ‘no’ via the device 110. Arrow 401 shows the notification sent to the consumer 120. Arrow 402 represents 402 is the consumer’s answer (affirmative or negative). By allowing the cardholders to authenticate their own cards, the merchant can increase security of future transaction payment processes made online for those cardholders.

[0049] In some cases, for example when the merchant 130 initiates an information request, acquirer 140 sends account ID token 310 to the merchant 130, as shown by arrow 302’ (FIG. 4). Then merchant 130 receives the acquirer response and it chooses how to store this response and account ID token 310. For example, the information can be stored on the merchant application 112, or in a merchant database that maps back to the cardholder who originally tapped their card.

[0050] According to some embodiments, the account ID token 310 that is generated by the acquirer has a built-in expiration timeline. This ensures that a new token 310 must be generated at some time in the future as well as helps maintain security of the card information. Arrow 401 in FIG. 9 shows the consumer 120 receiving a response from the merchant via app 112 on consumer's device 110.

[0051] Following the tap-to-authenticate process as described above, the merchant can use the stored token at some later time for payment use cases, such as account funding, or facilitating online purchases. Note that the time delay between the authentication step and payment / transfer step contrasts with cases where NFC and EMV technology are used in a face-to-face transaction. In known face-to-face cases (e.g. customer's card and merchant's NFC enabled mobile phone) no such time delay is available because the steps of card verification and payment / fund transfer are performed together, at the same time and at the same location.

[0052] In on-line, non-face-to-face cases, the card verification can be performed some time prior to the payment / transfer process. For the payment / transfer process, performed later, the merchant 130 sends: (1 ) earlier provided Account ID (token) 310 and (2) the earlier received acquirer’s AVSID. The acquirer 140 then retrieves the card information for that consumer 120 by performing a comparison with the Account ID (token) 310. The acquirer 140 then packages the information resulting from the comparison along with the AVSID and submits an authorization request to a card network 250, for example.

[0053] FIG. 5 is a diagram showing further detail of a transaction being carried out using an earlier performed tap-to-pay authentication. The consumer 120 uses their device 110 (arrow 701 ) to initiate a transaction with merchant 130 (arrow 702), using merchants app 112 running on consumer's device 110. Merchant 130 requeststransaction authorization, for example, by invoking a "create transaction API" as shown in arrows 703. Merchant's request 703 includes the acquirer’s account ID token 310 which is described in further detail supra. The request 703 can also include the AVSID received from acquirer 140 during the tap-to-authenticate process. Arrow 704 shows acquirer 140 initiating an authorization with card network 250. Arrow 707 shows the acquirer 140 receiving a response from payment or card network 250. Note that although arrows 703 and 708 are shown as originating from and directing to merchant 130, in practice the merchant may act through its supplied app 112 installed on consumer’s mobile device 110.

[0054] According to some embodiments, some decrypted information from card 103 can be omitted in cases when the acquirer 140 understands it is unrelated to the authorization request and if included could increase costs to the merchant. For example, in cases where the acquirer 140 knows that all the transactions being authorized between a particular card / customer 120 and merchant 130 are to take place within the United States, the acquirer can omit the Issuer Country Code (ICC) from the transaction message. In some cases, including the ICC in the transaction message increases costs by triggering a checking process by a payment or card network 250.

[0055] In response to the acquirer's authorization request, the card network 250 sends the authorization request on to the issuing bank for the card 103. The issuing bank then either approves or declines the authorization request. The card network 250 relays authorization result to the acquirer 140, and the acquirer 140 then sends the result to the merchant 130. The merchant 130 sends the result to the application 112 running on the cardholder's device 110 which notifies the cardholder 120 of the transaction status.

[0056] FIG. 6 is a diagram showing further aspects of a tap-to-authenticate process being carried out in an online environment, according to some embodiments. Arrow 601 : consumer 120 taps their own card 103 onto their own device 110 through merchant app 112. This step takes place using NFC technology contained on both the consumers card 103 and consumers device 110. Arrow 602: merchant app 112 sends encrypted card data from the card chip 105 to backend servers 106 of merchant130. Arrow 603: merchant backend servers 106 send encrypted card data to acquirer 140. According to some embodiments, the card data is sent by the acquirer 1 0 to the payment or card network 250. Acquirer 140 stores the card data 322 and generates a secure token 310 at module 610. Arrow 604: acquirer 140 sends the secure token 310 back to the backend servers 106 of Merchant 130. Arrow 605: merchant backend servers 106 of merchant 130 store the secure token 310 so that a transaction (see FIG. 7) can be later authorized. The token 310 has a timeframe before it expires.

[0057] FIG. 7 is a diagram illustrating further aspects of a consumer initiating a transaction some time after a tap-to-authenticate process has been carried out, according to some embodiments. Arrow 701 : consumer 120 initiates payment on merchant app 112. Arrow 702: merchant app 112 sends secure token 310 to merchant backend 106. Arrow 703: merchant backend 106 sends stored token 310 to processor 820 of acquirer 140. Arrow 704: acquirer processor 820 compares the incoming token 310 with the authenticated token credentials (e.g. card data 322 shown in FIG. 3) from the tap-to-authenticate process of FIG. 6, and sends an authorization request to card network 250. Arrow 705: card network 250 sends the authorization request to the card's issuing bank 730. Arrows 706, 707: Issuing bank 730 approves or declines the authorization request. Card network 250 relays authorization response to acquirer processor 820. Arrow 708 shows acquirer processor 820 relaying the authorization response to backend 106 of acquirer client / merchant 130. Arrow 709: backend 106 of acquirer client / merchant 130 informs their end customer 130 of the result of the transaction through app 112 on the mobile device 110.

[0058] FIG. 8 is a diagram showing aspects of some additional verification features, according to some embodiments. Portions of FIG. 8 are similar to FIGs. 1 A and 1 B. In addition to passing card data 108 and additional data 109 to acquirer 140 a request for additional verification features (AVF) 801 can be transmitted from app 112 on device 100. If the request for AVFs comes from merchant 130 the request can be made directly from merchant 130 to acquirer 140 as shown by arrow 262 (also shown FIG. 2C). Data used by acquirer (or acquirer’s API) can come from a number of sources including from app 114 on device 110 (data 810); from merchant 130directly (data 812) or from other sources (data 814). According to some embodiments, data can also come from acquirer 1 0 itself. For example, data used in the AVF can be card information 322 stored on acquirer’s database 320. Also shown in FIG. 8 is processing system 820 Further aspects relating to online card authentication will now be provided, according to some embodiments.

[0059] Use of EMV chip in online: the use of EMV chip technology in an online environment is not currently well utilized. Currently a consumer can tap a card at a physical location of a merchant, either with a physical point of sale (PCS) system or a POS on the merchant’s physical mobile device, but not in an online environment.

[0060] Lack of guaranteed access to physical card in online environment: In the remote environment today, no guaranteed way is known of determining physical access to a card that a consumer uses. In the case of an EMV chip, it securely and singularly points to physical access to the card by the consumer.

[0061] Acquirer Software in a Remote Chip Reader: Merchant's Application (e.g. 112 in FIG. 1 ) includes special software from the acquirer that enables the consumer device to become a chip reader for the purposes of tap-to-authenticate.

[0062] Reduces Reliance on Complex Anti-Fraud Software: Without using the described technology, companies currently use known sophisticated fraud systems and algorithms to detect fraud. Tap-to-authenticate is more efficient and eliminates the need for complex fraud detection software. This has a beneficial impact on the operation of computer networks and computer equipment by reducing the networking, processing, and storage loads since there is less reliance on such known fraud systems and algorithms and a unique secure token 310 is generated and used in a unique way.

[0063] My Card / Mv Device: In a transaction that the consumer initiates in an online environment, the physical card and the device go hand in hand - they are used together in a transaction.

[0064] Strong Authentication in a Payment Transaction: At the end of a tap-to- authenticate sequence, the merchant's app receives a secure token (e.g. token 310) that expires after a certain time period. Using this token, the merchant can initiate payments securely to the acquirer. The acquirer compares the incoming token (310)with the authenticated token credentials (e.g. 322) and proceeds to process the payment.

[0065] Chip Reader to Authenticate Online: In known current technology, chip readers to read chip information from a card are used in the context of face-to-face events or in the presence of a merchant or at a physical merchant location. This patent specification presents technology for use in an online environment and helps eliminate fraud while doing so.

[0066] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the body of work described herein is not to be limited to the details given herein, which may be modified within the scope and equivalents of the appended claims.

Claims

CLAIMS1 . A single tap authentication system for fraud and error reduction in on-line transactions using a tap of a consumer’s card on the consumer’s mobile device and a unique secure token, comprising: a near field communication (NFC) enabled mobile device 110 of a consumer 120 storing a merchant application 112 and configured to respond to a tap with an NFC enabled credit, debit, prepaid, or stored value card 103 of the consumer on the consumer’s mobile device to extract and output encrypted card data 108; an acquirer processor 610, 820 of an acquirer 140 configured to receive the output encrypted card data from mobile device 110, store the received output encrypted card data or a processed version thereof, and generate therefrom a unique secure token 310 related to the output encrypted card data from the consumer’s card; wherein said token has an expiration time enabling selective use of the token in a current transaction and / or in a future transaction of the consumer with the merchant and / or an issuer of the card; wherein said acquirer processor is further configured to transmit the token generated thereby to a merchant backend; and wherein the mobile device is configured to store the token received thereby and utilize the token in authentication of a current transaction between the consumer and the merchant or an issuer of the card and / or in a future such transaction.

2. The system of claim 1 , in which the mobile device is configured to use the token stored therein in a transaction with an issuer of the card.

3. The system of claim 1 , in which the acquirer processor is configured to generate and transmit a verification request in response to a card network inresponse to the encrypted card data and to transmit to the merchant backend processor a verification result.

4. The system of claim 1 , in which in which said mobile device is further configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.

5. A single tap authentication system comprising: a customer’s mobile device 110 equipped with an internal near field communication (NFC) device 150 and storing a merchant application 112, and a card 103 equipped with an internal near field communication (NFC) device 105, wherein the mobile device is configured to respond to a tap with the card to extract from the card and transmit encrypted card data 108; an acquirer server 140 configured to receive and decrypt the transmitted encrypted card data, store the decrypted card data, generate and store a unique secure token 310 related to the card data, and obtain card verification status; and a merchant server 134 configured to interact with the customer’s mobile device without a need to store the card data; wherein the acquirer server is further configured to transmit the secure token and card verification status to the customer’s mobile device and the merchant server is configured to receive the secure token and verification status from the acquirer server or from the customer’s mobile device and proceed with a card-paid transaction based thereon.

6. The single tap authentication system as in claim 5, further including a card network 250, wherein the acquirer server is further configured to transmit a request for an authorization related to the tapped card and the card network is configured to receive and evaluate the request for authorization and transmit tothe acquirer server a response indicative of whether a transaction with the tapped card is authorized.

7. The single tap authentication system of claim 6, further including a card issuer 290, wherein the card network is configured to respond to the request for authorization from the acquirer server by transmitting a verification request to the card issuer, the card issuer is configured to respond to the verification request by transmitting verification status to the acquirer server and the acquirer server is configured to include data regarding the verification status in the verification result transmitted thereby to the customer’s mobile device.

8. The single tap authentication system of claim 5, in which the merchant server is further configured to transmit a request for additional verification to the acquirer server and the acquirer server is further configured to obtain verification data 109 that is in addition to the card data 108 and transmit to the merchant server a response based on the additional verification data.

9. The single tap authentication system of claim 5, in which the acquirer server is configured to transmit the secure token to the merchant server instead of or in addition to transmitting the secure token to the consumer’s mobile device.

10. The single tap authentication system of claim 5, in which the acquirer server is further configured to generate an authentication time limit data indicative of a future time up to which the secure token remains valid, and to transmit the time limit data directly or indirectly to at least one of the merchant server and the consumer’s mobile device, wherein additional or future transaction with the card would not require tapping the consumer’s card on the consumer’s mobile device to effectuate a paying transaction with the card through the consumer’s mobile device.11 . The single tap authentication system of claim 5, in which in which said mobile device is further configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.

12. An authentication system comprising: a near field communication (NFC) enabled mobile device 110 of a consumer 120 storing a merchant application 112 and configured to respond to a tap with an NFC enabled card 103 of the consumer to extract and transmit encrypted card data 322 (108) derived from the card; an acquirer processor 610, 820 of an acquirer 140 configured to receive and decrypt the encrypted card data, store a decrypted version of the card data, and generate from the card data a unique secure token 310 related to the card data; wherein said token has an expiration time enabling selective use of the token in a current transaction and / or in a future transaction of the consumer with the merchant or an issuer of the card without requiring an additional tap; wherein said acquirer processor is further configured to transmit a request for verification to a payment or card network and to transmit the token generated thereby and a response to the verification request to at least one of the merchant backend and the consumer’s mobile device as; and wherein the mobile device is configured to store the token received thereby and utilize the token in authentication of a current transaction between the consumer and the merchant or an issuer of the card and / or in a future such transaction.

13. The authentication system of claim 12, in which in which said mobile device is further configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.

14. An authentication system comprising:a mobile device 110 equipped with an internal near field communication (NFC) device 150 and storing a merchant application 112, and a card 103 equipped with an internal near field communication (NFC) device 105, wherein the mobile device is configured to respond to a tap with the card to extract card data from the card and transmit encrypted card data 108; a merchant server 134 and an acquirer server 140, wherein the acquirer server is configured to receive the encrypted data directly from the mobile device and / or through the merchant server and to generate in response a unique secure token 310 and to transmit a request for verification to a payment or card issuer network and transmit back to the mobile device and / or the merchant server the token and a result of the verification; and the mobile device and the merchant server are configured to process the token and verification results and to authenticate a transaction based thereon and on an age of the token.

15. The authentication system of claim 14, in which in which said mobile device is further configured to first extract non-encrypted card data from the card and to produce the encrypted card data therefrom.

Images