Systems and methods for processing using a device with reduced usage time

Abstract

The present invention provides methods and systems for facilitating transactions. Transactions involving an integrated circuit user device in contact with an access device are processed in less time, allowing the user device to be removed earlier. In one embodiment, the access device provides an estimated value to the user device, allowing a password to be generated without waiting for a final value. Furthermore, the access device can store the user device data and then complete the transaction with the user device before authorizing the transaction, allowing the user device to be removed without waiting for an authorization response.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2016 / 069460, international application date December 30, 2016, application number 201680084186.0 entering the Chinese national phase, and titled “System and method for device processing with reduced usage time”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is an international patent application of and claims the benefit of the filing date of U.S. Patent Application No. 15 / 171,982, filed on June 2, 2016, which claims priority to U.S. Provisional Application No. 62 / 317,450, filed on April 1, 2016, the entire contents of which are incorporated herein by reference for all purposes. Background Art

[0004] Smart cards store user account data on an integrated circuit rather than a magnetic stripe. Smart cards are contact cards that are physically inserted (or "dipped") into a card reader (e.g., a terminal). Smart card transactions offer increased security against fraud compared to magnetic stripe transactions. However, smart card transactions typically take longer to process at the card reader than traditional magnetic stripe transactions, where users can simply swipe the card and place it back in their pocket without waiting for the transaction to complete. This can lead to frustration on the part of the user, who may be reluctant to wait for the smart card transaction to complete before removing the smart card.

[0005] In an average smart card transaction, a user may have to wait eight to twelve seconds before being allowed to remove the smart card from the access device. Some smart card insertions may take more than 20 seconds before the user can remove the smart card.

[0006] In addition to the actual increase in time, the user may perceive an even greater amount of time. The user may be accustomed to the card swiping process, which can feel instantaneous because the card may never leave the user's hand and the user can immediately put the card back in their pocket. Therefore, the amount of time the user must wait before putting the card away may seem extended, longer than it actually is.

[0007] Long processing times for smart card transactions can also lead to forgotten smart cards. For example, the processing time may be long enough for the user to forget the smart card and leave it behind when the transaction is complete. Alternatively, the user may accidentally remove the smart card before it is ready. This can disrupt the transaction, requiring it to be restarted.

[0008] Embodiments of the present invention address these and other problems individually and collectively. Summary of the Invention

[0009] One embodiment of the present invention relates to a method. The method includes physically contacting a user device with an access device. The method also includes: receiving credentials for a transaction from the user device; and storing the credentials. The method also includes allowing the user device to be removed from the access device before receiving an authorization response message for the transaction from an authorization entity computer. The method also includes: generating an authorization request message for the transaction; and transmitting the authorization request message to the authorization entity computer. The method also includes receiving an authorization response message for the transaction from the authorization entity computer. The authorization response message is received when the user device is physically separated from the access device.

[0010] Another embodiment of the present invention relates to an access device configured to perform the above-described method.

[0011] Additional details regarding embodiments of the invention can be found in the detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A block diagram of a system according to an embodiment of the present invention is shown.

[0013] Figure 2 A block diagram of an exemplary user equipment according to an embodiment of the present invention is shown.

[0014] Figure 3 A block diagram of an exemplary access device according to an embodiment of the present invention is shown.

[0015] Figure 4 A flow chart illustrating a first method for processing a transaction according to an embodiment of the present invention is shown.

[0016] Figure 5 A flow chart illustrating a second method for processing a transaction according to an embodiment of the present invention is shown.

[0017] Figure 6 A flow diagram illustrating transaction processing communications between a user device and an access device is shown. DETAILED DESCRIPTION

[0018] Embodiments of the present invention relate to systems and methods for reducing the processing time of transactions using smart user devices (e.g., contactless chip cards) to optimize the user experience. For years, consumers have swiped their magnetic stripe cards at access devices and then put them back in their pockets without waiting for the transaction to complete. The embodiments described herein allow for similarly fast and convenient transaction processing during smart user device transactions. This faster transaction processing can be achieved by making one or more of the following changes to conventional transaction processing.

[0019] In an embodiment of the present invention, a user device can be removed from an access device before a transaction is completed. For example, the access device can notify the user device that a transaction is complete or canceled (e.g., by requesting a second password), even if the transaction is still pending. The user device can then complete its processing of the current transaction, return to default settings, and prepare to be removed from the access device. As a result, the user device can be removed from the access device before receiving an authorization request message from the authorization entity.

[0020] In some embodiments, the access device can store the user device information, thereby allowing the user device to be removed even earlier (e.g., before sending the authorization request message). Rather than collecting the user device information directly from the user device when generating the authorization request message, the stored information can be used for the authorization request message. Thus, once the user device information is received at the user device, the information can be stored at the access device and the user device can be removed. For example, upon receiving and storing the user device information, the access device can complete communication with the user device (e.g., by notifying the user device that online processing is not possible and requesting a password).

[0021] In some embodiments, the access device can provide an estimated or preset transaction amount to the user device. The user device can use the estimated transaction amount when generating a password for the transaction. As a result, the user device may not need to wait for the final transaction amount to be determined before generating the password. In fact, the user device can provide the credentials to the access device in parallel with the purchase items being scanned and the transaction amount being calculated. Therefore, the user device can immediately provide the credentials to the access device, allowing communication between the user device and the access device to be completed without any delay, and the user device can then be removed. An authorization request message can then be sent, including the estimated and final amounts, so that the authorization entity can verify the password and authorize the actual amount.

[0022] Embodiments of the present invention allow user device insertion times to be reduced to two seconds or less. Thus, compared to the current average insertion time of eight to twelve seconds, embodiments allow for an average reduction of six to seven seconds (75%-83%), and compared to the current possible insertion time of twenty seconds or more, a potential reduction of eighteen seconds or more (90% or more). For transactions where the user device is inserted before the final transaction amount is known (e.g., for grocery store transactions), the user device insertion time can further reduce the time required for a clerk to scan all items (e.g., potentially several minutes, depending on the number of items).

[0023] Furthermore, the embodiments described herein do not require any changes to existing access device systems. Current systems can simply receive a software download to accommodate the embodiments described herein. No changes are required to standard transaction processing (e.g., EMV or Europay, MasterCard and Visa processing) or the user devices themselves, and no additional testing or certification may be required. Furthermore, there may be no impact on routing, merchant banks, payment networks, or card issuers.

[0024] Embodiments of the present invention can be applied to any form of user device transaction. For example, any transaction involving a contact card and an access device can use these methods to reduce device insertion time. For example, embodiments can be used for payment transactions (e.g., paying with a smart credit card, debit card, or prepaid card at a merchant's POS terminal), access transactions (e.g., gaining access to a restricted area with a smart access token), or any other suitable type of transaction.

[0025] Before discussing specific embodiments of the present invention, some terms may be described in detail.

[0026] "User device" may include any suitable device associated with a user. A user device may include a substrate such as a paper or plastic card, and information printed, embossed, encoded, or otherwise contained on or near the surface of an object. A user device may include a circuit having, for example, a permanent voltage value to store information. Suitable user devices may be handheld and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket size). The user device may operate at least in contact mode. As an example, a user device may include a smart card. In some embodiments, a smart card may be used as a payment card, a security card, an access card, or any other suitable type of card. If the user device is in the form of a debit card, a credit card, or a smart card, the user device may also optionally have features such as a magnetic stripe. In some embodiments, a user device may be used to perform financial transactions. Such a user device may be referred to as a "payment device." For example, a user device may be associated with a value such as a monetary value, a discount, or store credit, and the user device may be associated with an entity such as a bank, a merchant, a payment processing network, or an individual.

[0027] A "credential" may include any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters that can be presented or incorporated into any object or document that can serve as a confirmation. Examples of credentials include payment credentials, passwords, access credentials, and any other suitable type of credential.

[0028] "Payment credentials" may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account or may be derived from information associated with the account. Examples of payment credentials may include a PAN (primary account number or "account number"), a user's name, an expiration date, and a verification value such as a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, and the like. An example of a PAN is a 16-digit number, such as "4147 0900 0000 1234". In some embodiments, a payment credential may include additional information that may be used to authorize a transaction. For example, a payment credential may include a password associated with the transaction.

[0029] An "encryption key" may include any data value or other information suitable for encrypting data using a cryptographic key. A "decryption key" may include any data value or other information suitable for decrypting encrypted data. In some cases, the encryption key and decryption key may be the same (i.e., a "symmetric key").

[0030] A "password" may include encrypted information. For example, a password may be a set of text encrypted with an encryption key.

[0031] "Access device" can be any suitable device that provides access to a remote system. The access device can also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device can generally be located at any suitable location, for example, at the merchant's location. The access device can have any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, and access systems. The access device can use any suitable contact or contactless operating mode to send or receive data to or from a user device or to associate with a user device. In some embodiments in which the access device can include a POS terminal, any suitable POS terminal can be used, and it can include a reader, a processor, and a computer-readable medium. The reader can include any suitable contact or contactless operating mode. For example, an exemplary card reader can include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with the user device. In some embodiments, a cell phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or "mPOS" terminal.

[0032] An "authorization request message" may be an electronic message requesting authorization for a transaction. In some embodiments, the authorization request message is sent to a transaction processing computer and / or the issuer of a payment card to request authorization of the transaction. The authorization request message according to some embodiments may conform to ISO 8583, a standard for systems for exchanging electronic transaction information associated with payments made by users using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or "account number"), a payment token, a user's name, an expiration date, and the like. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, acquiring bank identification number (BIN), card acceptor ID, information identifying the item being purchased, and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0033] An "authorization response message" may be a message in response to an authorization request. In some cases, the authorization response message may be an electronic message reply to the authorization request message generated by the issuing financial institution or a transaction processing computer. The authorization response message may include (by way of example only) one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or through the transaction processing computer) indicating that the transaction is approved. The code may be used as evidence of authorization. As noted above, in some embodiments, the transaction processing computer may generate or forward the authorization response message to the merchant.

[0034] A "server computer" may include a powerful computer or computer cluster. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers operating as a unit. In one example, a server computer may be a database server coupled to a network server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination thereof for servicing requests from one or more client computers.

[0035] Figure 1 A system 100 comprising several components is shown. System 100 includes a user device 115 operated by a user 110. System 100 also includes a resource provider computer 130, a transfer computer 140, a transaction processing computer 150, and an authorization entity computer 160, each of which may be embodied by one or more computers. User device 115 may be connected to and / or communicate with an access device 125, which in turn may communicate with resource provider computer 130. Furthermore, resource provider computer 130, transfer computer 140, transaction processing computer 150, and authorization entity computer 160 may all be in operable communication with one another via any suitable communication channel or network. Suitable communication networks may include any one and / or a combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), Operational Mission as a Node in the Internet (OMNI), a secure custom connection, a wide area network (WAN), a wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP) or I-mode), and the like.

[0036] Messages between computers, networks, and devices may be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Hypertext Transfer Protocol Secure (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), and the like.

[0037] An example of a user device 115 according to some embodiments of the present invention is Figure 2 As shown, in some embodiments, the user device 115 can take the form of a card including a plastic substrate 115(s). In some embodiments, the user device 115 can include a contact element 115(c) that is present on or embedded within the plastic substrate 115(s). The contact element 115(c) can include a microprocessor and / or memory (e.g., a memory chip in which user data is stored). The contact element 115(c) can enable the user device 115 to interface and communicate with the access device 125. In some embodiments, a contactless element 115(o) for interfacing with the access device can also be present on or embedded within the plastic substrate 115(s). A magnetic stripe 115(n) can also be present on the plastic substrate 115(s). Identification information 115(p) can be printed or embossed on the card. The identification information can include, for example, a card number, an expiration date, and / or a user's name.

[0038] User 110 can use user device 115 to conduct transactions with a resource provider associated with resource provider computer 130. User device 115 can store information associated with user 110 and / or an account (e.g., at contact element 115(c)). For example, user device 115 can be a smart payment card, and contact element 115(c) can store payment credentials as well as personal information such as name, address, email address, phone number, or any other suitable identifying information 115(p). Contact element 115(c) can provide this information to access device 125 during a transaction. User device 115 can be assigned to user 110 by an authorized entity, such as an issuing bank.

[0039] Refer again Figure 1 The resource provider computer 130 may be associated with a resource provider, which may be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, access devices, secure data access points, and the like. A merchant may generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0040] Resource providers can accept a variety of payment methods (e.g., user devices 115) and can use a variety of tools to perform different types of transactions. For example, a resource provider can operate a physical store and use access devices 125 for in-person transactions. A resource provider can also sell goods and / or services via a website and accept payments over the Internet.

[0041] Figure 3 An example of an access device 125 according to some embodiments of the present invention is shown in FIG. Access device 125 may include: a processor 125(c) operably coupled to a computer-readable medium 125(d) (e.g., one or more memory chips, etc.); input elements 125(b) such as buttons; one or more card readers 125(a) (e.g., contact chip reader, contactless reader, magnetic stripe reader, etc.); an output device 125(e) (e.g., a display, speaker, etc.); and a network interface 125(f). A housing may house one or more of these components.

[0042] The computer-readable medium 125(d) may include instructions or code that are executable by a processor. The instructions may include instructions for sending commands to the user device 115 upon contact with the device, and instructions for communicating with the user device 115 to obtain credentials and otherwise process transactions. The computer-readable medium 125(d) may also include instructions for requesting authorization for a transaction with the authorization entity computer 160, as well as instructions for any other suitable functionality as described herein.

[0043] Reference again Figure 1 The transmission computer 140 may be associated with an acquirer, which may be a commercial entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may include such a single-entity issuer-acquirer. The transmission computer 140 may be more specifically referred to as an acquirer computer.

[0044] The transaction processing computer 150 may be located between the transmission computer 140 and the authorization entity computer 160. The transaction processing computer 150 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception document services, and clearing and settlement services. For example, the transaction processing computer 150 may include a server coupled to a network interface (e.g., via an external communication interface) and an information database. The transaction processing computer 150 may represent a transaction processing network. Exemplary transaction processing networks may include VisaNet TM Such as VisaNet TMVisaNet's transaction processing network handles credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, it includes the VIP system (Visa Integrated Payment System) for processing authorization requests and the Base II system for performing clearing and settlement services. The transaction processing computer 150 can use any suitable wired or wireless network, including the Internet.

[0045] The authorization entity computer 160 may be associated with an authorization entity, which may be an entity that authorizes the request. An example of an authorization entity may be an issuer, which may generally refer to a business entity (e.g., a bank) that maintains a user account. The issuer may also issue and manage a payment account associated with the user device 115.

[0046] The transaction processing computer 150, the transmission computer 140, and the authorization entity computer 160 may execute appropriate routing tables to route authorization request messages and / or authorization response messages using payment credentials, merchant identifiers, or other account identifiers.

[0047] You can refer to Figure 4 4 to describe a method 400 according to an embodiment of the present invention. Reference will also be made to some elements of other figures.

[0048] In embodiments of the present invention, the steps shown in method 400 and in the Figure 5-Figure 6 In some embodiments, one or more of the steps may be optional.

[0049] The various messages described below and about Figure 5-Figure 6 The message of description can use the communication of any suitable form.In some embodiments, request or response can have electronic message format, such as, email, short message service (SMS) message, multimedia message service (MMS) message, hypertext transfer protocol (HTTP) request message, transmission control protocol (TCP) grouping, web form submission.Request or response can point to any suitable location, such as, email address, telephone number, internet protocol (IP) address, or uniform resource locator (URL).In some embodiments, request or response can comprise the mixing of different message types, such as, email message and SMS message.

[0050] Method 400 provides for faster communication exchanges between user device 115 and access device 125 during transactions. As mentioned above, this method can be used for any suitable type of transaction, such as a payment transaction, an access transaction, an authentication transaction, etc., and the transaction can involve any suitable type of value, such as a monetary amount, an identity credential, a password, a data value, etc. However, for purposes of explanation, a payment transaction for an authorized monetary amount is described below.

[0051] At step S410, a transaction may begin. For example, user 110 may approach access device 125 at a resource provider location to purchase one or more goods and / or services. Access device 125 may begin receiving information about the items being purchased and summing the amount of each item (e.g., in an "ECR or Electronic Cash Register Reimbursement" process).

[0052] At step S415, access device 125 may request user 110 to provide user device 115. User 110 may then provide user device 115 to access device 125. For example, user device 115 may be inserted into access device 125 or otherwise physically connected to access device 125. A contact interface (e.g., a chip board) on user device 115 may come into direct contact with a second contact interface at access device 125. As a result, access device 125 is able to communicate with user device 115 for transaction processing.

[0053] In some embodiments, the total transaction amount may not be fully calculated when the user device 115 is initially plugged in. For example, a transaction may occur at a grocery store, where the user 110 may plug in the user device 115 before all items have been entered into the access device 125 by a store clerk.

[0054] Additionally, in some embodiments, the user device 115 may generate and provide a password for the transaction, and the password may be based on the transaction amount. Thus, the user device 115 may wait until the transaction amount is received from the access device 125 before generating the password.

[0055] At step S420, access device 125 may generate or identify a preset or estimated amount that can be used before determining the actual transaction amount. Access device 125 can provide this estimated amount to user device 115, allowing user device 115 to generate a password using the estimated amount. As a result, transaction processing can continue immediately without waiting for all items to be scanned. This can allow communication between access device 125 and user device 115 to complete more quickly, allowing user 110 to remove user device 115 from access device 125 earlier.

[0056] The estimated amount can be determined based on the resource provider, the merchant category classification (MCC), the type of transaction, the median transaction amount for the resource provider, or any other suitable considerations. For example, if transactions at the resource provider are typically in the range of $30-$35, the estimated amount can be set to $31.11 (e.g., the average amount). In some embodiments, using an estimated amount within a normal range (e.g., an amount within $30-$35 for the example above) can be used to authenticate the authorization request at the issuer (e.g., because the issuer may know the normal transaction amount range for the resource provider).

[0057] In some embodiments, the estimated amount can be preset to a random number or any other applicable number. In addition, in some embodiments, the estimated amount can be identical to each transaction, or can periodically vary (for example, to each transaction or once a day).

[0058] At step S425, the access device 125 may perform transaction processing communications with the user device 115. For example, the access device 125 may provide an estimated amount to the user device 115 and may request credentials for the transaction (e.g., payment credentials, password, etc.) from the user device 115. The user device 115 may provide the credentials to the access device 125, and the credentials may include a password such as an Authorization Request Password (ARQC), a Transaction Certificate (TC), or an Application Authentication Password (AAC). Detailed examples of the interaction between the access device 125 and the user device 115 at step S425 will be described below with respect to Figure 6 Further description.

[0059] At step S430, access device 125 may determine whether user device 115 provided a password (e.g., ARQC) for online transaction processing. For example, user device 115 may have provided a password, but the password may be ARQC, TC, or AAC. If user device 115 provided ARQC, access device 125 can perform online authorization and may proceed to step S440. The password may be based on at least the estimated transaction amount, the access device ID, and any other suitable information.

[0060] At step S435, if the access device 125 does not receive an ARQC from the user device 115, the access device 125 may terminate (e.g., cancel) the transaction. For example, the access device 125 may have received an AAC, which may indicate that the user device 115 has declined the transaction. In some embodiments, the access device 125 may not proceed to step S440, but may continue with an alternative process. For example, the access device 125 may continue to process the online transaction, but may not release the user device 115 until authorization is received from the issuer. Alternatively, the access device 125 may perform an offline authorization.

[0061] At step S440, access device 125 may store the information received from user device 115 (e.g., if ARQC was received at step S430). For example, access device 125 may temporarily retain payment credentials, transaction passwords, and any other suitable information received from user device 115. The information may be stored so that after user device 115 is removed, access device 125 may still use the information in the authorization request message. This may allow user device 115 to be removed before the authorization request message is generated or sent.

[0062] At steps S445-S455, access device 125 may allow user device 115 to be removed. Access device 125 may have received the information needed to process the transaction, so user device 115 may no longer be needed.

[0063] In some embodiments, access device 125 can allow user device 115 to be removed by completing the transaction communication between access device 125 and user device 115. Completing the transaction communication with user device 115 can reset user device 115 to default settings, leaving user device 115 in a clean state and ready for another later transaction.

[0064] In some embodiments, to complete the transaction with the user device 115, the access device 125 may request a second password from the user device 115. When requesting the second password, the access device 125 may notify the user device 115 that online authorization was not possible (e.g., due to a poor connection), that online authorization was successful, or that authorization was denied.

[0065] As an example, at step S445, access device 125 may notify user device 115 that the online connection is unavailable, meaning that authorization cannot be completed online and the transaction should be rejected or authorization may be postponed. For example, the authorization response code may be set to indicate that the online connection is unavailable. Then, at step S450, user device 115 may return a second code (e.g., AAC) indicating that the transaction is rejected or authorization may be postponed. Receipt of the second code may indicate that the transaction communication between access device 125 and user device 115 is complete. Therefore, at this point, user device 115 can be safely removed.

[0066] At step S455, user 110 may remove user device 115 from access device 125. For example, access device 125 may prompt user 110 to remove user device 115. A visual display may be presented, an audible sound may be played, a store clerk may notify user 110, or any other method may be used to notify user 110 that user device 115 may be removed.

[0067] Thus, after a short time in access device 125, user device 115 can be removed. User 110 does not have to wait for the full transaction amount to be calculated or for an authorization response message to be received. In fact, user device 115 data can be stored, and user device 115 can be released even before the authorization request message is sent. As a result, user device 115 can be removed within two seconds of contact with access device 125. This can reduce contact time by more than eighteen seconds (90%), compared to the existing possible insertion time of twenty seconds or more.

[0068] Furthermore, even if removed earlier than usual, user device 115 can still be removed in a clean state by requesting the second password earlier than usual (e.g., before receiving the authorization response message). In reality, access device 125 may actually have an online connection, and access device 125 may not have received the authorization response message. However, access device 125 can essentially provide false information to user device 115, allowing user device 115 to complete its transaction process and be removed earlier than usual.

[0069] As mentioned above, the information received from the user device 115 at step S425 can be retained, allowing transaction processing to continue even if the user device 115 is removed. Even though the access device 125 may receive an AAC, the access device may not reject the transaction and may, in fact, continue to process the transaction as normal. For example, the access device 125 may continue to update the total transaction amount as new items are entered, and ultimately, the access device 125 may submit an authorization request message for the transaction.

[0070] At step S460, the access device 125 may have received information about all purchased items. For example, a store clerk may have completed scanning each item. As a result, the final transaction amount may be determined and the ECR reimbursement process may be completed.

[0071] At step S465, once the total transaction amount has been determined, user 110 may confirm the actual transaction amount. For example, access device 125 may display the total amount, and user 110 may indicate acceptance (e.g., by pressing a key on a PIN pad or providing a signature). The actual transaction amount may differ from the preset or estimated amount.

[0072] At step S470, the access device 125 (or the resource provider computer 130) may generate and send an authorization request message for the transaction. The authorization request message may include the actual transaction amount, an estimated or preset amount, user device 115 credentials (e.g., payment credentials, ARQC, etc.), and any other suitable information.

[0073] In some embodiments, the authorization request message can be generated earlier in the process and the authorization request message can be modified to include the actual amount after it is known. In some embodiments, the actual amount can be included as data in the supplemental or actual data field in the authorization request message.

[0074] The authorization request message may be sent to the transmission computer 140, which may forward it to the transaction processing computer 150, which in turn may forward it to the authorization entity computer 160. The authorization entity computer 160 may determine whether to authorize the transaction. For example, the authorization entity computer 160 may verify a password (e.g., ARQC), check that the user's account has sufficient funds, perform a risk analysis, and complete any other steps to determine whether to authorize the transaction. The authorization entity computer 160 may then send an authorization response message back to the access device 125 (e.g., via the transaction processing computer 150, the transmission computer 140, and / or the resource provider computer 130) indicating successful authorization.

[0075] At step S475, access device 125 may receive an authorization response message indicating that the transaction is approved or denied from authorization entity computer 160. Access device 125 may display an appropriate message to user 110 and / or store clerk, and the resource provider may release the purchased goods and / or services to user 110.

[0076] At some point in time, a clearing and settlement process may occur between the transmission computer 140 , the transaction processing computer 150 , and the authorization entity computer 160 .

[0077] Since user device 115 is no longer connected to access device 125 upon receiving the authorization response message, user device 115 may not receive any information from authorization entity computer 160. For example, user device 115 may not receive or authenticate the authorization response password (ARPC) from the authorization entity computer, user device 115 may not receive the issuer script, and user device 115 may not receive updated counters (e.g., offline transaction counters). However, all of this data is only usable in offline transaction scenarios and may not provide any useful functionality where transactions are performed online. As a result, even though this information may be lost, user device 115 is still useful.

[0078] As described above, by using an estimated amount and initiating the transaction with that amount (e.g., in the "Authorized Amount" field when communicating with the user device 115), the amount of time the user device needs to be plugged into the access device is minimized. This is because the communication between the user device and the access device can be completed without waiting for the actual transaction amount to be calculated.

[0079] In addition, the access device 125 can notify the user device 115 that authorization was denied (e.g., due to a wireless connection) so that the user device 115 can be returned to a clean state and subsequently removed. The user device 115 data can be stored for final processing when determining the final transaction amount. Thus, insertion time can be further reduced because the user device 115 can be removed before the authorization request message is sent and before the authorization response message is received.

[0080] Additionally, in some embodiments, signature capture may be delayed (e.g., such that the user device 115 may be removed before the signature is captured). In some embodiments, if the final amount is less than the payment limit, signature capture may not be required. On the other hand, if the final amount is greater than the payment limit, the user's signature may be captured after the transaction is approved.

[0081] In some embodiments, implementation of this method does not require changes to standard transaction processing routines, associated hardware, or user devices. A minor software update to the access device 125 communication program can implement this method, which reduces user device insertion time. Furthermore, the changes made to implement this method do not result in any reduction in security. Cryptographic strength and overall transaction security can be maintained, and online authorization can still be performed in the same secure manner.

[0082] In some embodiments, the total transaction amount may be determined and known before the user 110 provides the user device 115 to the access device 125. For example, in a restaurant, after receiving the food and service, payment may be made, and the user 110 may make the payment after the transaction amount has been calculated. Thus, in some embodiments, a transaction may be processed without an estimated amount. Figure 5 A method 500 for performing such a transaction according to an embodiment of the present invention is described.

[0083] At step S510, a transaction may begin. For example, user 110 may approach access device 125 at a resource provider location to purchase one or more goods and / or services. In some embodiments, the final transaction amount may be known or determined at this time. For example, the user's items may have already been scanned at access device 125, user 110 may simply purchase an item that is quickly scanned at access device 125, or user 110 may provide payment for already acquired goods or services (e.g., food at a restaurant). In some embodiments, the ECR reimbursement process may end when the final transaction amount is known (e.g., because all items have been scanned and the amount is finalized at access device 125).

[0084] At step S515, access device 125 may request user 110 to provide user device 115. For example, access device 125 may prompt user 110 to provide user device 115 upon completion of the ECR reimbursement process. User 110 may then provide user device 115 to access device 125. For example, user device 115 may be inserted into access device 125 or otherwise physically connected to access device 125. A contact interface (e.g., a chip board) on user device 115 may come into direct contact with a second contact interface at access device 125. As a result, access device 125 is able to communicate with user device 115 for transaction processing.

[0085] At step S520, user 110 may confirm the amount of the transaction. For example, access device 125 may display the total amount, and user 110 may indicate acceptance (e.g., by pressing a key on a PIN pad or providing a signature). In some embodiments, user 110 may confirm the amount before providing user device 115, when inserting user device 115, after removing user device 115, or at any other suitable point in the process.

[0086] At step S525, the access device 125 may perform transaction processing communications with the user device 115. For example, the access device 125 may provide the transaction amount to the user device 115 and may request credentials for the transaction (e.g., payment credentials, password, etc.) from the user device 115. The user device 115 may provide the credentials to the access device 125, which may include a password (e.g., ARQC, TC, or AAC). A detailed example of the interaction between the access device 125 and the user device 115 at step S525 will be described below with respect to Figure 6 Further description.

[0087] At step S530, access device 125 may determine whether user device 115 has provided a password (e.g., ARQC) for online transaction processing. For example, user device 115 may have provided a password, but the password may be ARQC, TC, or AAC. If user device 115 has provided ARQC, access device 125 can perform online authorization and may proceed to step S540. The password may be based on at least the final transaction amount, the access device ID, and any other suitable information.

[0088] At step S535, if the access device 125 does not receive an ARQC from the user device 115, the access device 125 may terminate (e.g., cancel) the transaction. For example, the access device 125 may have received an AAC, which may indicate that the user device 115 has declined the transaction. In some embodiments, the access device 125 may not proceed to step S440, but may continue with an alternative process. For example, the access device 125 may continue to process the online transaction, but may not release the user device 115 until authorization is received from the issuer. Alternatively, the access device 125 may perform an offline authorization.

[0089] At step S540, access device 125 may store the information received from user device 115 (e.g., if ARQC was received at step S430). For example, access device 125 may temporarily retain payment credentials, passwords, and any other suitable information received from user device 115. The information may be stored so that after user device 115 is removed, access device 125 may still use the information in the authorization request message. This may allow user device 115 to be removed before the authorization request message is generated or sent.

[0090] At steps S545-S555, access device 125 may allow user device 115 to be removed. Access device 125 may have received the information needed to process the transaction, so user device 115 may no longer be needed.

[0091] In some embodiments, access device 125 can allow user device 115 to be removed by completing transaction communications between access device 125 and user device 115. Completing transaction communications with user device 115 can cause user device 115 to be reset to default settings and / or a dormant state, leaving user device 115 in a clean state and ready for another later transaction.

[0092] In some embodiments, to complete the transaction with the user device 115, the access device 125 may request a second password from the user device 115. When requesting the second password, the access device 125 may notify the user device 115 that online authorization was not possible (e.g., due to a poor connection), that online authorization was successful, or that authorization was denied.

[0093] As an example, at step S545, access device 125 may notify user device 115 that the online connection is unavailable, meaning that authorization cannot be completed online and the transaction should be rejected or authorization may be postponed. For example, the authorization response code may be set to indicate that the online connection is unavailable. Then, at step S550, user device 115 may return a second code (e.g., AAC) indicating that the transaction is rejected or authorization may be postponed. Receipt of the second code may indicate that the transaction communication between access device 125 and user device 115 is complete. Therefore, at this point, user device 115 can be safely removed.

[0094] At step S555, user 110 may remove user device 115 from access device 125. For example, access device 125 may prompt user 110 to remove user device 115. A visual display may be presented, an audible sound may be played, a store clerk may notify user 110, or any other method may be used to notify user 110 that user device 115 may be removed.

[0095] Thus, after a short time in access device 125, user device 115 can be removed. User 110 does not have to wait to receive an authorization response message. In fact, user device 115 data can be stored, and user device 115 can be released even before the authorization request message is sent. As a result, user device 115 can be removed within two seconds of contact with access device 125. This can reduce contact time by more than eighteen seconds (90%), compared to the existing possible insertion time of twenty seconds or more.

[0096] Furthermore, even if removed earlier than normal, user device 115 can still be removed in a clean state and / or dormant state by requesting the second password earlier than normal (e.g., before receiving the authorization response message). In reality, access device 125 may actually have an online connection, and access device 125 may not have received the authorization response message. However, access device 125 can essentially provide false information to user device 115, allowing user device 115 to complete its transaction process and be removed earlier than normal.

[0097] As mentioned above, the information received from the user device 115 at step S525 can be retained, and transaction processing can continue even if the user device 115 is removed. Even though the access device 125 may receive an AAC, the access device may not reject the transaction and may, in fact, continue to process the transaction as usual. For example, the access device 125 may submit an authorization request message for the transaction.

[0098] At step S560, the access device 125 (or resource provider computer 130) may generate and send an authorization request message for the transaction. The authorization request message may include the transaction amount, user device 115 credentials (eg, payment credentials, ARQC, etc.), and any other suitable information.

[0099] In some embodiments, when the authorization request message is sent, the user device 115 may still be connected to the access device 125. For example, the authorization request message may be generated and sent quickly so that the message is sent before the user 110 removes the user device 115.

[0100] The authorization request message may be sent to the transmission computer 140, which may forward it to the transaction processing computer 150, which in turn may forward it to the authorization entity computer 160. The authorization entity computer 160 may determine whether to authorize the transaction. For example, the authorization entity computer 160 may verify a password (e.g., ARQC), check that the user's account has sufficient funds, perform a risk analysis, and complete any other steps to determine whether to authorize the transaction. The authorization entity computer 160 may then send an authorization response message back to the access device 125 (e.g., via the transaction processing computer 150, the transmission computer 140, and / or the resource provider computer 130) indicating successful authorization.

[0101] At step S565, access device 125 may receive an authorization response message indicating that the transaction is approved or denied from authorization entity computer 160. Access device 125 may display an appropriate message to user 110 and / or store clerk, and the resource provider may release the purchased goods and / or services to user 110.

[0102] At some point in time, a clearing and settlement process may occur between the transmission computer 140 , the transaction processing computer 150 , and the authorization entity computer 160 .

[0103] Because user device 115 may no longer be connected to access device 125 upon receiving the authorization response message, user device 115 may not receive information from authorization entity computer 160. For example, user device 115 may not receive or authenticate the authorization response password (ARPC) from the authorization entity computer, user device 115 may not receive the issuer script, and user device 115 may not receive updated counters (e.g., offline transaction counters). However, all of this data is only useful in offline transaction scenarios and may not provide any useful functionality where transactions are performed online. As a result, the loss of this information may not result in any loss of functionality for user device 115.

[0104] As described above, in some embodiments, the transaction amount can be known immediately before or after the user device 115 is inserted into the access device 125. Thus, the user device 115 can immediately receive the transaction amount and then generate a password based on the transaction amount. As a result, communication between the user device 115 and the access device 125 can be completed quickly after the user device 115 is inserted.

[0105] In some embodiments, the user device 115 can be removed immediately after being inserted into the access device 125. In addition, the access device 125 can notify the user device 115 that authorization was denied (e.g., due to the lack of an online connection) so that the user device 115 can be returned to a clean and / or dormant state and then removed. The user device 115 data can be stored for use in the authorization process after the user device 115 is removed. Thus, insertion time can be reduced because the user device 115 can be removed without waiting for an authorization response and any subsequent processing.

[0106] Additionally, signature capture can be delayed (e.g., so that the user device 115 can be removed before the signature is captured). In some embodiments, if the final amount is less than the payment limit, signature capture may not be required. On the other hand, if the final amount is greater than the payment limit, the user signature may be captured after the transaction is approved.

[0107] In some embodiments, implementation of this method does not require changes to standard transaction processing routines, associated hardware, or user devices. A minor software update to the access device 125 communication program can implement this method, which reduces user device insertion time. Furthermore, the changes made to implement this method do not result in any reduction in security. Cryptographic strength and overall transaction security can be maintained, and online authorization can still be performed in the same secure manner.

[0108] Embodiments of the present invention may involve many communications between the user device 115 and the access device 125. For example, in step S425 of method 400 and step S525 of method 500, several messages may be exchanged to process the transaction and obtain information from the user device 115. An example flow 600 of these communications is shown in FIG. Figure 6 middle.

[0109] When the user device 115 contacts the access device 125, the user device 115 and the access device 125 are able to communicate. Several processing steps may be performed to identify and prepare data for transmission to the access device 125 for the transaction. In some embodiments, application protocol data unit (APDU) messages may be exchanged between the user device 115 and the access device 125. The messages may be in the form of APDU commands sent from the access device 125 to the user device 115, and APDU responses sent from the user device 115 to the access device 125. However, it should be understood that other messages, messaging protocols, or formats may be used to exchange relevant information for performing transactions.

[0110] At step S610, access device 125 may perform application selection. For example, access device 125 may determine which applications are supported by both user device 115 and access device 125. In some embodiments, when access device 125 detects the presence of user device 115, access device 125 may send an available applications request to user device 115, requesting information about which payment applications (e.g., a list of AIDs) are available at user device 115. In some embodiments, the available applications request may be in the form of a select command.

[0111] The user device 115 may respond by sending an available applications response back to the access device 125. The available applications response may include a list of available AIDs. In some embodiments, the available applications response may be in the form of a select response.

[0112] The access device 125 may then select an appropriate application from the list of applications received in the available application response (e.g., by selecting an AID from the available AIDs). For example, the access device 125 may select a payment application (e.g., the highest priority application) that is supported by both the access device 125 and the user device 115. In some embodiments, the access device 125 may display the commonly supported applications and allow the user 110 to select the application to use for the transaction.

[0113] The access device 125 may also send an application selection message with the selected AID to the user device 115. In some embodiments, the application selection may be in the form of a read record command or a select AID (or ADF) command.

[0114] The user device 115 may then send a request to the access device 125 for transaction data that may be needed to perform a transaction using the selected application / AID. In some embodiments, the request may be in the form of a read record response or a select AID (or ADF) response. The request may include a list of transaction data identifiers, and the list may be in the form of a processing option data object list (PDOL). The requested transaction data may include a terminal transaction qualifier (TTQ), an authorized amount, other amounts, a terminal country code, a terminal verification result, a transaction currency code, transaction data, a transaction type, and / or an unpredictable number.

[0115] At step S620, the access device 125 may initiate application processing. For example, the access device 125 may request data (e.g., a list of files containing data) used by the user device 115 to indicate the selected application and supported functions. In some embodiments, the access device 125 may send a Get Processing Options (GPO) command. The access device 125 may also provide transaction information to the user device 115 (e.g., via a GPO command). For example, the access device 125 may provide the transaction data requested by the user device 115 via a Processing Options Data Object List (PDOL). The provided transaction data may include a transaction amount, such as a final transaction amount or an estimated transaction amount (e.g., if the final transaction amount is not yet known).

[0116] The user device 115 may then use at least some of the received terminal transaction data to generate dynamic transaction processing information and send a set of transaction processing information to the access device 125. In some embodiments, the transaction processing information may be sent in the form of a GPO response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that can be used by the access device 125 as file addresses to read account data stored on the user device 115.

[0117] At step S630, access device 125 may read the application data. For example, access device 125 may send an account data request to user device 115 to read the account data stored at user device 115. In some embodiments, the account data request may be in the form of a read record command and may include an application file locator (AFL) indicating the location of the account data.

[0118] The user device 115 may then send the account data to the access device 125. In some embodiments, the account data may be sent in the form of a read record response. The account data may include, for example, track 2 equivalent data (e.g., payment credentials) and the cardholder's name, and / or other account-related data accessible at the AFL location.

[0119] One or more authentication and verification steps may be performed to verify that the transaction can proceed. For example, steps S640-S680 provide various authentication processes. In some embodiments, one or more of these steps may be skipped because online authentication and / or authorization may be sufficient alternatives.

[0120] At step S640, the access device 125 may determine whether offline authentication should be performed on the user device 115. This determination may be made based on whether the user device 115 supports offline authentication. In some embodiments, one or more types of offline authentication may be performed, such as static data authentication (SDA) or dynamic data authentication (DDA).

[0121] At step S650, the access device 125 may check the processing restrictions. For example, the access device 125 may determine whether the transaction should be allowed to proceed based on the user device expiration date, the user device validity date, the matching of applications between the user device 115 and the access device 125, usage restrictions (e.g., restrictions on international purchases or cashback services), and any other suitable restrictions.

[0122] At step S660, access device 125 may perform cardholder verification. For example, user 110 may be verified as the legitimate user of user device 115 and not a fraudster. One or more card verification methods (CVMs) may be used. For example, user 110 may be prompted to provide a PIN (e.g., verified online by an authorized entity or offline by user device 115), a signature, or any other suitable authentication method.

[0123] At step S670, the access device 125 may perform terminal risk management. For example, the access device 125 may perform a speed check, determine whether the transaction exceeds the merchant reserve price limit, check whether the amount is marked as declined, determine whether a limit on consecutive transactions has been exceeded, and / or check for any other suitable fraud indicators.

[0124] At step S680, the access device 125 may perform a terminal action analysis. For example, the access device may determine whether the transaction should be approved offline, sent online for authorization, or rejected offline. This determination may be based on one or more of the above authentication and risk analysis steps (e.g., steps S640-S670). As mentioned above, in some embodiments, all transactions may be authorized online. Therefore, the access device 125 may automatically continue the online authorization process.

[0125] Access device 125 may then request a password from user device 115 (e.g., via a Generate Application Password command). Access device 125 may specifically request an Authorization Request Password (ARQC), a Transaction Certificate (TC), or an Application Authentication Password (AAC). In some embodiments, an ARQC may be requested for online authorization, a TC may be requested for offline authorization (e.g., already approved offline), and an AAC may be requested for transaction rejection or authorization deferral.

[0126] The user device 115 may then determine which type of password to provide to the access device. For example, the user device 115 may provide an ARQC to continue online authorization. Alternatively, the user device 115 may determine that the transaction should be rejected and may return an AAC.

[0127] In some embodiments, the ARQC can be generated based on transaction-specific information. For example, the transaction amount received from the access device 125 (e.g., in step S620), the transaction ID, the merchant identifier, and any other suitable transaction-related information can be used as input to the ARQC generation algorithm. Any other suitable information can also be used as input, such as a random number, a transaction count, etc. The ARQC can be generated using an authorization entity key stored in the user device 115 and known at the authorization entity computer 160. Therefore, upon receiving the ARQC with the authorization request message, the authorization entity computer 160 can authenticate the ARQC.

[0128] In some embodiments, once the user device 115 sends the password to the access device 125, the communication between the user device 115 and the access device 125 may have achieved its primary purpose (e.g., providing credentials to the access device 125 for use in a transaction). Thus, steps S610-S680 may include the processing mentioned in step S425 of method 400 and step S525 of method 500.

[0129] Method 600 continues with additional steps to concisely complete the communication exchange between access device 125 and user device 115, remove user device 115, and authorize the transaction. These steps are similar to those already described with respect to Figure 4-5The steps described overlap (e.g., steps S430-S475 in method 400 and steps S630-S565 in method 500).

[0130] At step S710, access device 125 may receive the password from user device 115 and determine whether to authorize the transaction online. For example, similar to steps S430 and S530, access device 125 may determine whether the password is an ARQC. In some embodiments, if an ARQC is received, access device 125 may continue the online authorization process.

[0131] The access device 125 may store the user device 115 information (e.g., account credentials, password, etc.) for later processing (e.g., as mentioned in steps S440 and S540). For example, the final transaction amount may not yet be known, so the access device 125 may retain the user device 115 information until authorization can be completed.

[0132] Once the necessary user device 115 information (e.g., account credentials, password, etc.) is received and stored, the user device 115 may no longer be required at the access device 125. Thus, communication between the access device 125 and the user device 115 may be completed, and the user device 115 may be removed at an earlier time (as mentioned in steps S445-S455 and S545-S555). For example, the user device 115 may be removed before calculating the final transaction amount, before sending the authorization response message, and before receiving the authorization response message.

[0133] At step S720, access device 125 can complete the transaction communication (e.g., as mentioned in relation to steps S455 and S550) with user device 115 online. For example, access device 125 can request a second password from user device 115, and after providing the second password, user device 115 can return to the default settings.

[0134] Access device 125 may request a second password using a second Generate Application Password command. In some embodiments, access device 125 may request an AAC indicating that the transaction should be declined or postponed because authorization cannot be performed online (e.g., as mentioned with respect to steps S445 and S545). However, in reality, authorization can be performed online (and may not even have been attempted yet), and this command may be used only to complete communication with user device 115. False information regarding the decline or postponement of a transaction may have no impact on the actual transaction or any negative impact on user device 115.

[0135] In some embodiments, the access device 125 may instead indicate that the transaction was successfully authorized (even though authorization has not yet occurred) and request a TC.

[0136] The user device 115 may then respond with a Generate Application Password Response including the AAC. The user device 115 may then complete its internal processing, returning to a clean, default, and / or dormant setting, thereby preparing to be removed from the access device 125.

[0137] Once the access device 125 receives the second password from the user device 115 , the access device 125 may prompt the user 110 to remove the user device 115 from the access device 125 (eg, as mentioned with respect to steps S455 and S555 ).

[0138] Thus, after a continuous flow of communication with access device 125, user device 115 can be removed. Communication delays due to calculating transaction amounts or obtaining online authorization can be eliminated. In fact, information can be obtained from user device 115 in a short period of time, the user device can be removed, and access device 125 can continue processing transactions without being connected to user device 115.

[0139] At step S730, once the final transaction amount is known, the access device 125 can process the transaction online. For example, the access device 125 can generate an authorization request message and send the authorization request message to the authorization entity computer 160 for authorization (such as described in steps S470-S475 and steps S560-S565).

[0140] Embodiments of the present invention have many advantages. For example, in embodiments of the present invention, transaction processing communications between a user device (e.g., a smart card or integrated chip card) and an access device can be performed quickly and efficiently. All communications between the user device and the access device can be performed in an immediate, streamlined process without any delay. For example, the access device can immediately provide a transaction value (e.g., a final value or an estimated value) upon contact with the user device. As a result, the user device can immediately generate a password based on the value (and other information). In addition, once the access device receives credentials (e.g., account information and password) from the user device, the access device can complete the transaction communication and the user device can be removed. The user can remove the user device without waiting for an authorization response message or post-authorization processing.

[0141] Embodiments of the present invention can advantageously reduce the contact time between a user device and an access device to two seconds or less. Thus, compared to the current average insertion time of eight to twelve seconds, embodiments allow for an average reduction of six to seven seconds (75%-83%), and compared to the current possible insertion time of twenty seconds or more, a reduction of eighteen seconds or more (90% or more). In addition to the actual reduction in contact time, the user can perceive an even greater reduction in contact time.

[0142] Embodiments of the present invention can also advantageously reduce total transaction time. For example, embodiments allow for post-authorization processing, such as issuer-card script processing and issuer authentication at the user device to be eliminated. Removing these steps not only reduces the amount of time it takes for the user device to be inserted into the access device, but also reduces the amount of time the user waits at the access device (e.g., before goods and services are distributed and the user can leave). In an embodiment, the user device may not receive issuer response information (e.g., data received in an authorization response message). However, this data may be unnecessary for online transactions. Therefore, reducing contact time as described in the present invention may not have any disadvantages (e.g., no reduction in security, no loss of useful information).

[0143] Embodiments of the present invention advantageously allow the user device to have a clean state at the conclusion of a transaction, even if the user device is removed earlier than normal. For example, the access device may request the second passcode earlier than normal (e.g., by falsely indicating a failed online connection) so that the user device can complete its transaction and then be removed.

[0144] Embodiments of the present invention can be advantageously implemented without requiring changes to hardware, without requiring changes to the EMV transaction processing standard, and without requiring changes to user devices. In fact, a software update on the access device can implement the new steps and communications described in the present invention.

[0145] A computer system that can be used to implement any entity or component described herein will now be described. The subsystems in the computer system are interconnected via a system bus. Additional subsystems include a printer, a keyboard, a fixed disk, and a monitor, which can be connected to a display adapter. Peripheral devices and input / output (I / O) devices can be coupled to an I / O controller and can be connected to the computer system by any number of means known in the art (e.g., serial ports). For example, a serial port or external interface can be used to connect a computer device to a wide area network such as the Internet, a mouse input device, or a scanner. Interconnection via the system bus allows a central processing unit to communicate with each subsystem and control the execution of instructions from a system memory or fixed disk and the exchange of information between subsystems. System memory and / or fixed disk can embody computer-readable media.

[0146] As described above, the services of the present invention may involve implementing one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, operations, or method steps may be implemented by executing an instruction set or software code by a suitably programmed computing device, microprocessor, data processor, etc. The instruction set or software code may be stored in a memory or other form of data storage element accessible by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware, a dedicated processor, an integrated circuit, etc.

[0147] Any software component or function described in this application can be implemented as a software code executed by a processor using any appropriate computer language (such as, for example, Java, C++ or Perl) using, for example, traditional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium can reside on or inside a single computing device and can exist on or inside different computing devices within a system or network.

[0148] While certain exemplary embodiments have been described in detail and shown in the drawings, it is to be understood that such embodiments are merely illustrative of the invention and not restrictive, and that the invention is not limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those skilled in the art.

[0149] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A method comprising: providing, by an access device, a preset amount to a user device for a transaction, wherein the user device generates a password based on the preset amount, wherein the preset amount is provided to enable the user device to generate the password before an actual amount of the transaction is determined; Receiving, by the access device, payment credentials and the password from the user device; The access device completes communication with the user equipment, wherein completing communication with the user equipment includes sending a message to the user equipment, wherein the message: (a) notifying the user device that the transaction is complete, even if an authorization response message has not yet been received at the access device; or (b) notifying the user device that transaction authorization will be deferred or denied due to unavailability of online authorization, where the online authorization is in fact available; After completing the communication with the user device, the access device determines the actual amount of the transaction, wherein the actual amount is different from the preset amount; generating, by the access device, an authorization request message for the transaction, the authorization request message including the payment credential, the password, the preset amount, and the actual amount; as well as The authorization request message is transmitted by the access device to an authorization entity computer, wherein the authorization entity computer uses the preset amount included in the authorization request message to verify the password included in the authorization request message, wherein the preset amount is not used to authorize the transaction, and wherein the authorization entity computer uses the payment credentials included in the authorization request message and the actual amount included in the authorization request message to authorize the transaction.

2. The method of claim 1, further comprising: Prompting the user, by the access device, to present the user device to the access device; initiating the communication with the user equipment; requesting the password from the user device by the access device; storing the payment credentials and the password by the access device; receiving, by the access device, the authorization response message for the transaction from the authorization entity computer; as well as After receiving the authorization response message, an indication is displayed by the access device that the transaction is authorized, wherein the user device does not receive information associated with the transaction from the authorization entity computer.

3. The method of claim 1 , wherein determining the actual amount comprises summing a plurality of item amounts associated with a plurality of items being purchased, and further comprising: The access device prompts the user to confirm the actual amount. The method according to claim 1 , wherein the predetermined amount is a random number. The method of claim 1 , wherein the predetermined amount is an estimated amount. The method of claim 1 , wherein the predetermined amount is the same for each of the plurality of transactions.

7. The method of claim 1, wherein the predetermined amount is different for each of a plurality of transactions. The method of claim 1 , wherein the predetermined amount is a dollar amount.

9. The method of claim 1, wherein the preset amount is included in a first data field of the authorization request message, and the actual amount is included in a second data field of the authorization request message.

10. The method of claim 1, wherein the preset amount or the actual amount is included in a supplement to the authorization request message.

11. The method of claim 1 , wherein the password is a first password, and wherein, Completing communication with the user device also includes: A second password is received by the access device from the user device, wherein the user device is returned to a default setting or clean state such that the user device is ready for subsequent transactions after sending the second password.

12. The method of claim 1, wherein the user device is a card or a mobile phone.

13. The method of claim 1, wherein the password is an authorization request password.

14. The method of claim 1, wherein after completing the communication with the user device, the user device returns to a default setting or clean state such that the user device is ready for subsequent transactions.

15. An access device, comprising: processor; as well as A computer-readable medium comprising code executable by the processor for implementing the method of any one of claims 1 to 14.

16. The access device of claim 15, further comprising: A contactless reader, wherein the communication with the user device is performed using the contactless reader.

17. The access device of claim 15, further comprising: A contact chip reader, wherein the communication with the user device is performed using the contact chip reader.

18. A method comprising: Receiving, by the user device, a predetermined amount from the access device for the transaction; generating, by the user device, a password based on the preset amount, wherein the preset amount is provided to enable the user device to generate the password before an actual amount of the transaction is determined; as well as transmitting the payment credentials and the password from the user device to the access device; as well as completing communication with the user equipment, including sending a message to the user equipment, wherein: (a) notifying the user device that the transaction is complete, even if an authorization response message has not yet been received at the access device; or (b) notifying the user device that transaction authorization will be deferred or denied due to unavailability of online authorization, where the online authorization is in fact available, wherein after completing the communication with the access device, the access device determines the actual amount of the transaction that is different from the preset amount, generates an authorization request message for the transaction, the authorization request message includes the payment credential, the password, the preset amount and the actual amount, and transmits the authorization request message to an authorization entity computer, wherein the authorization entity computer uses the preset amount included in the authorization request message to verify the password included in the authorization request message, wherein the preset amount is not used to authorize the transaction, and wherein the authorization entity computer uses the payment credential included in the authorization request message and the actual amount included in the authorization request message to authorize the transaction.

19. The method of claim 18, wherein the user device is a card or a mobile phone, and further comprising: receiving, by the user device, a request for the password from the access device, wherein generating the password is performed before determining the actual amount and the preset amount is not used to authorize the transaction; wherein the user device does not receive information associated with the transaction from the authorizing entity computer; as well as After completing the communication with the access device, the user device is returned to a default setting or clean state so that the user device is ready for subsequent transactions.

20. A user equipment, comprising: processor; as well as A computer-readable medium comprising code executable by the processor for implementing the method of any one of claims 18 to 19.

21. A method comprising: Physical access to the device by the user device; transmitting, by the user device to the access device, credentials for a transaction, wherein the access device stores the credentials; Prior to receiving at the access device an authorization response message for the transaction from an authorization entity computer, a message is received by the user device from the access device, the message: (a) notifying the user device that the transaction is complete, even if the authorization response message has not yet been received at the access device, or (b) notifying the user device that authorization of the transaction will be deferred or denied because online authorization is unavailable, even if online authorization is available; In response to receiving the message, before receiving the authorization response message for the transaction at the access device from the authorization entity computer, completing, by the user device, communication with the access device, comprising: generating a password by the user device; and transmitting the password to the access device by the user device; In response to completing the communication with the access device, returning the user device to a default setting or clean state such that the user device is ready for subsequent transactions; and and detaching from the access device after completing communication with the access device, wherein the access device allows the user device to detach from the access device after completing communication with the access device and before receiving the authorization response message for the transaction from the authorization entity computer at the access device.

22. The method of claim 21, wherein the user device is a card.

23. A method as claimed in claim 21, wherein the user device is an integrated chip card having a chip board, wherein the access device includes a contact chip reader, wherein physically contacting the access device includes directly contacting the chip board with the contact chip reader so that the user device can communicate with the access device, and wherein separating from the access device includes disconnecting the chip board from the contact chip reader so that the user device cannot communicate with the access device.

24. The method of claim 21, wherein the user device does not contact the access device again for the same transaction.

25. The method of claim 21, wherein the message from the access device notifies the user device that the transaction is complete even if authorization has not actually occurred, and wherein the password is a transaction credential.

26. The method of claim 21, wherein the message from the access device informs the user device that transaction authorization will be deferred or denied because online authorization is unavailable, even though online authorization is actually available, and wherein the password is an application authentication password.

27. The method of claim 21, wherein the message from the access device includes a request for the password.

28. The method of claim 21, wherein the password is a second password, and wherein the method further comprises: generating a first password by the user device, Wherein the credentials include the first password, and wherein transmitting the credentials to the access device for use in the transaction includes transmitting the first password to the access device.

29. The method of claim 28, wherein the first password is an authorization request password.

30. The method of claim 28, further comprising: An estimated value or a preset value is received by the user device from the access device, wherein the first password is generated based on the estimated value, wherein the access device prompts the user to confirm a final value, and wherein the access device generates an authorization request message for the transaction, the authorization request message including the credential, the estimated value, and the final value.

31. The method of claim 28, wherein the access device prompts a user to confirm the final value, and further comprising: The final value is received by the user device from the access device, wherein the first password is generated based on the final value, and wherein the access device generates an authorization request message for the transaction, the authorization request message including the final value.

32. A method as described in any one of claims 21 to 24, wherein the access device generates an authorization request message for the transaction, transmits the authorization request message to the authorization entity computer, and receives the authorization response message for the transaction from the authorization entity computer when the user device is physically separated from the access device.

33. A method as claimed in claim 32, wherein the user device is separated from the access device before the access device transmits the authorization request message to the authorization entity computer, or before the access device generates the authorization request message, or before the user provides a signature for the transaction.

34. The method of any one of claims 21 to 24, wherein the user device does not receive information associated with the transaction from the authorising entity computer.

35. The method of any one of claims 21 to 24, wherein the access device prompts a user to remove the user device.

36. A method as claimed in any one of claims 21 to 24, wherein the user equipment is a mobile phone.

37. The method of any one of claims 21 to 24, wherein the message received from the access device includes false information for completing the communication with the user device and has no effect on the actual transaction result.

Images