RU2774798C2 - Method applying time-reduced processing of an apparatus - Google Patents

Abstract

FIELD: computing technology.

SUBSTANCE: method for performing a transaction includes ensuring physical contact of the user apparatus with the access apparatus; transmitting transaction authentication data by the user apparatus to the access apparatus; receiving a message by the user apparatus from the access apparatus, informing the user apparatus of the transaction being completed, the authorisation of the transaction being denied, or the authorisation of the transaction being delayed due to the unavailability of online authorisation even if online authorisation is available; completing data exchange with the access apparatus by the user apparatus, wherein the completion of data exchange with the access apparatus includes: transferring a cryptogram by the user apparatus to the access apparatus and returning the user apparatus to the default setting or a clean state after sending said cryptogram; separating from the access apparatus, wherein the access apparatus allows the user apparatus to be separated from the access apparatus after completing data exchange with the access apparatus and before receiving said transaction authorisation response message from said computer of the subject of authorisation.

EFFECT: reduced transaction processing time.

17 cl, 6 dwg

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is an international patent application that claims priority of the filing date of U.S. Patent Application No. 15/171982, filed June 2, 2016, which claims priority of U.S. Provisional Application No. 62/317450, filed April 1 2016, which is incorporated herein by reference in its entirety for all purposes.

BACKGROUND OF THE INVENTION

[0002] Smart cards store user account information on integrated circuits rather than on magnetic stripes. They may be contact cards that are physically inserted (or "switched") into a reader (eg, terminal). Transactions made with smart cards provide more fraud protection than transactions made with magnetic stripe cards. However, smart card transactions traditionally take longer to process at the reader than traditional magnetic stripe transactions where the user, after initially swiping the card, can simply put the card back in their pocket without waiting for the transaction to complete. This may cause irritation on the part of the user, as he may be unhappy that he must wait for the completion of the transaction performed using the smart card before picking up the card.

[0003] During a typical smart card transaction, the user may need to wait eight to twelve seconds before being allowed to remove the smart card from the access device. Sometimes smart cards must remain inserted for more than 20 seconds before the user can remove the smart card.

[0004] In addition to the actual increase in time, it may seem to the user that it takes even more time. The user may be accustomed to the swiping process, which may seem instantaneous, since the card may never leave the user's hand and the user may immediately put the card back into their pocket. Accordingly, any amount of time the user releases the card and has to wait before picking it up may appear to be longer than the actual time.

[0005] Longer processing times for smart card transactions can also result in smart cards being forgotten. For example, the processing time may be long enough that the user forgets about the smart card and leaves it after the transaction is completed. In addition, the user may accidentally pick up the smart card before it is possible. This may abort the transaction, so the transaction may need to be restarted.

[0006] Embodiments of the present invention address these and other disadvantages individually and collectively.

SUMMARY OF THE INVENTION

[0007] One embodiment of the present invention relates to a method. The method includes making the access device physically contact the user's device. The method also includes receiving credential data from the user's device for the transaction and storing the credential data. The method further includes allowing the user's device to be removed from the access device before the authorization response message for the transaction is received from the authorization subject's computer. The method also includes generating an authorization request message for the transaction and transmitting the authorization request message to the computer of the authorization subject. The method further includes receiving an authorization response message for the transaction from the computer of the authorization subject. An authorization response message is received when the user's device is physically separated from the access device.

[0008] Another embodiment of the present invention relates to an access device for performing the above described method.

[0009] Additional details relating to embodiments of the present invention can be found in the detailed description and description sections of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 shows a block diagram of a system according to one embodiment of the present invention.

[0011] FIG. 2 is a block diagram of an exemplary user device according to one embodiment of the present invention.

[0012] FIG. 3 is a block diagram of an exemplary access device according to one embodiment of the present invention.

[0013] FIG. 4 is a flowchart illustrating a first transaction processing method according to embodiments of the present invention.

[0014] FIG. 5 is a flowchart illustrating a second transaction processing method according to embodiments of the present invention.

[0015] FIG. 6 is a flowchart showing communication in transaction processing between a user device and an access device.

DETAILED DESCRIPTION OF THE INVENTION

[0016] Embodiments of the present invention relate to systems and methods for reducing processing time for transactions based on smart user devices (eg, a contact chip card) to improve the user experience. For years, consumers swiped their magnetic stripe cards across the access device and hid them back in their wallet without waiting for the transaction to complete. The embodiments described herein enable the same fast and simple transaction processing to be performed during transactions performed by smart user devices. Faster transaction processing can be achieved through one or more of the following changes to normal transaction processing.

[0017] In embodiments of the present invention, the user's device may be removed from the access device before the transaction is completed. For example, the access device may inform the user device that the transaction has been completed or canceled (eg, by requesting a second cryptogram), even though the transaction is actually still pending. The user's device may then complete its processing for the current transaction, return to the default setting, and thereby be ready to be retrieved from the access device. As a result, the user's device can be retrieved from the access device before the authorization request message is received from the authorization subject.

[0018] In some embodiments, the access device may store information about the user's device, thereby allowing the user's device to be retrieved even earlier (eg, before an authorization request message is sent). Instead of collecting information about the user's device directly from the user's device when generating the authorization request message, stored information can be used for the authorization request message. Thus, once information about the user's device is received on the user's device, the information can be stored on the access device and the user's device can be retrieved. For example, the access device may end a communication session with the user device (eg, informing the user device that online processing is not possible and requesting a cryptogram) immediately after receiving and storing information about the user device.

[0019] In some embodiments, the access device may provide an estimated or preset transaction amount to the user device. The user's device may be able to use the estimated amount of the transaction when generating the cryptogram for the transaction. As a result, the user's device may not need to wait for the final amount of the transaction to be determined before generating the cryptogram. Instead, the user's device may provide credential information to the access device in parallel with scanning for purchased items and calculating the transaction amount. Accordingly, the user device can immediately provide credential data to the access device, so that communication between the user device and the access device can be completed without any delay, and then the user device can be removed. An authorization request message can then be sent that contains both the estimated amount and the final amount so that the authorization subject can verify the cryptogram as well as authorize the actual amount.

[0020] Embodiments of the present invention reduce the user device insertion time to two seconds or less. Thus, the embodiments provide an average reduction of six to ten seconds (75% - 83%) compared to the current average insertion time of eight to twelve seconds, as well as a potential reduction in time of eighteen seconds or more (90% or more ) compared to the current possible insertion time of twenty seconds or more. For a transaction in which the user's device is inserted before the final amount of the transaction is known (eg, for a grocery store transaction), the insertion time of the user's device can be further reduced by the time it takes an employee to scan all items (eg, potentially minutes, per depending on the number of items).

[0021] In addition, the embodiments described herein may not require changes to current access device systems. Current systems may only accept a software installation file to comply with the embodiments described herein. No changes to standard transaction processing (such as EMV or Europay, MasterCard and Visa processing) or the user device itself may be required, and no additional testing or certification may be required. Also, there may be no impact on routing, merchant banks, payment network, or card issuer.

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

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

[0024] A "user device" may include any suitable device associated with a user. The user's device may include a substrate, such as a paper or plastic card, and information that is printed, embossed, encoded, or otherwise incorporated into or near the surface of an object. The user device may include circuitry, for example with constant voltage values, for storing information. Suitable user devices can be handheld and compact so that they can fit in a user's wallet and/or pocket (eg, they can be pocket-sized). The user's device may operate at least in contact mode. As an example, the user's device may include a smart card. In some embodiments, the smart card may serve as a payment card, pass card, access card, or any other suitable type of card. If the user's device is in the form of a debit card, credit card, or smart card, the user's device may also optionally have features such as magnetic stripes. In some embodiments, a user's device may be used to conduct a financial transaction. Such a user device may be referred to as a "payment device". For example, a user's device may be associated with a value, such as a currency, discount, or store credit, and a user's device may be associated with an entity, such as a bank, merchant, payment processing network, or person.

[0025] "Credential data" may include any suitable information that serves as a reliable proof of value, ownership, identity, or authority. The credential data may be a string of numbers, letters, or any other suitable characters that may be present or contained in any object or document that may serve as an attestation. Examples of credentials include payment credentials, cryptograms, access credentials, and any other suitable type of credential.

[0026] "Payment Credentials" may include any suitable information associated with an account (eg, a checking account and/or a payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of payment credentials may include PAN (primary account number or "account number"), username, expiration date, and verification codes such as CVV (card verification value), dCVV (dynamic card verification value), CVV2 (2 verification card parameter), CVC3 card test parameters, etc. An example of a PAN is a 16 digit number such as "4147 0900 0000 1234". In some embodiments, payment credentials may include additional information that may be used to authorize a transaction. For example, payment credentials may include a cryptogram associated with the transaction.

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

[0028] A "cryptogram" may include encrypted information. For example, a cryptogram may be a set of textual data encrypted with an encryption key.

[0029] An "access device" can be any suitable device that provides access to a remote system. The access device may also be used to communicate with a merchant's computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device may generally be located at any suitable location, such as the location of a merchant. The access device may be in any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, personal digital assistants, personal computers (PCs), tablet computers, dedicated hand-held readers, set-top boxes, electronic cash registers (ECRs). ), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc. The access device may use any suitable contact or non-contact mode of operation to send or receive data from or associated data with the user's device. In some embodiments in which the access device may include a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium. The reader may have any suitable contact or non-contact mode of operation. For example, to interact with a user's device, exemplary card readers may include radio frequency (RF) antennas, optical scanners, barcode readers, or magnetic stripe readers. 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 terminal or "mPOS".

[0030] An "Authorization Request Message" may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to the transaction processing computer and/or the payment card issuer to request authorization for the transaction. An authorization request message according to some embodiments may conform to ISO8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user with a payment device or checking account. The authorization request message may contain an issuer account identifier, which may be associated with a payment device or settlement account. The authorization request message may also contain additional data elements corresponding to "identification information" including, by way of example only: service code, CVV (Card Verification Value), dCVV (Dynamic Card Verification Value), PAN (Primary Account Number or account"), payment token, username, expiration date, etc. The authorization request message may also contain "transaction information", such as any information associated with the current transaction, such as transaction amount, merchant ID, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying purchased merchandise positions, etc., as well as any other information that can be used in determining whether a transaction should be identified and / or authorized.

[0031] An "Authorization Response Message" may be a message that responds to an authorization request. In some cases, it may be an electronic response to an authorization request message generated by the issuing financial institution or the transaction processing computer. The authorization response message may contain, by way of example only, one or more of the following status indicators: "approval" - the transaction has been approved; "rejection" - the transaction was not approved; or "call center", a response that requires more information, with the seller having to call a toll-free phone number for authorization. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or via a transaction processing computer) to a merchant's access device (e.g., POS equipment), which indicates the approval of the transaction. The code can serve as confirmation of authorization. As noted above, in some embodiments, the transaction processing computer may generate or forward an authorization response message to the merchant.

[0032] A "server computer" may include a powerful computer or a cluster of computers. For example, a server computer may be a large mainframe computer, a cluster of minicomputers, or a group of servers that function as one unit. In one example, the server computer may be a database server connected to a web server. The server computer may be connected to the database and may contain any hardware, software, other logic or combination of the previous to serve requests from one or more client computers.

[0033] FIG. 1 shows a system 100 containing a number of components. System 100 includes a user device 115 controlled by user 110. System 100 further includes resource provider computer 130, transport computer 140, transaction processing computer 150, and authorization subject computer 160, each of which may be implemented as one or more computers. User device 115 may be connected to and/or communicate with access device 125, which may in turn communicate with resource provider computer 130. In addition, resource provider computer 130, transport computer 140, transaction processing computer 150, and authorization subject computer 160 may all be operatively connected to each other over any suitable communication channel or communication network. Suitable communication networks may be any and/or combination of the following: direct connection; Internet; local area network (LAN); city computer network (MAN); operational missions and nodes on the Internet (OMNI); secure regular connection; wide area network (WAN); a wireless network (eg, employing, but not limited to, protocols such as WAP, I-mode, and/or the like); and/or the like.

[0034] 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 (eg, ISO 8583), and/or the like.

[0035] An example of a user device 115 according to some embodiments of the present invention is shown in FIG. 2. As shown, in some embodiments, the user device 115 may take the form of a card containing a plastic base 115(s). In some embodiments, the user device 115 may include a contact element 115(c) that is present on or embedded in the plastic base 115(s). Contact element 115(c) may include a microprocessor and/or memory (eg, memory chips with user data stored therein). The contact element 115(c) may allow the user device 115 to interact and communicate with the access device 125. In some embodiments, the contactless element 115(o) for interacting with the access device may also be provided on or embedded in the plastic base 115(s). The plastic base 115(s) may also have a magnetic stripe 115(n). The identification information 115(p) may be printed or embossed on the card. The identification information may include, for example, an account number, an expiration date, and/or a username.

[0036] The user 110 may be able to use the user's device 115 to conduct transactions with a resource provider associated with the resource provider's computer 130. User device 115 may store information associated with user 110 and/or account (eg, on contact element 115(c)). For example, user device 115 may be a payment smart card and contact element 115(c) may store payment credentials as well as personal information such as name, address, email address, telephone number, or any other suitable identification information 115 (p). Contact element 115(c) may be able to provide this information to access device 125 during a transaction. The user device 115 may be assigned to the user 110 by an authorization entity, such as an issuing bank.

[0037] Referring again to FIG. 1, resource provider computer 130 may be associated with a resource provider, which may be an entity that may provide a resource such as goods, services, information, and/or access. Examples of a resource provider include vendors, access devices, secure data access points, and so on. A merchant can typically be an entity that is involved in transactions and can sell goods or services or provide access to goods or services.

[0038] The resource provider may accept various forms of payments (eg, user device 115) and may use various means to conduct different types of transactions. For example, a resource provider may operate a physical store and use the access device 125 for in-person transactions. The resource provider may also sell goods and/or services through the website and may accept payments over the Internet.

[0039] An example of an access device 125 according to some embodiments of the present invention is shown in FIG. 3. The 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 keys, or the like. etc., one or more readers 125(a) (e.g., contact chip reader, contactless reader, magnetic stripe reader, etc.), output device 125(e) (e.g., display, speaker, etc.). etc.) and network interface 125(f). One or more of these components may be located in the housing.

[0040] The computer-readable medium 125(d) may contain instructions or code executable by a processor. The commands may include commands to send a command to the user's device 115 when contacting that device, and commands to communicate with the user's device 115 to obtain credentials and otherwise process the transaction. The computer-readable medium 125(d) may also contain instructions for requesting authorization of a transaction by the computer 160 of the authorization subject and instructions for any other suitable function, as described herein.

[0041] Referring again to FIG. 1, transport computer 140 may be associated with an acquirer, which may typically be a business entity (eg, a commercial bank) that has a commercial relationship with a particular merchant or other entity. Some entities may act as both an issuer and an acquirer. Some embodiments may cover such single acquirer-issuer entities. Transport computer 140 may be more specifically referred to as an acquirer computer.

[0042] The transaction processing computer 150 may be located between the transport computer 140 and the computer 160 of the authorization subject. Transaction processing computer 150 may include subsystems, networks, and processing operations used to support and deliver authorization services, stop list services, and clearing and settlement services. For example, transaction processing computer 150 may include a server connected to a network interface (eg, an external communications interface) and information databases. The transaction processing computer 150 may be typical of a transaction processing network. An example of a transaction processing network is VisaNet™. Transaction processing networks such as VisaNet™ can process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™ specifically includes a VIP system (Visa Integrated Payment System) that processes authorization requests and a Base II system that performs clearing and settlement services. Transaction processing computer 150 may use any suitable wired or wireless network, including the Internet.

[0043] Authorization subject computer 160 may be associated with an authorization subject, which may be the subject that authorizes the request. An example of an authorization entity would be an issuer, which may typically refer to a business entity (eg, a bank) that maintains an account for the user. The issuer may also open and manage a checking account associated with the user's device 115.

[0044] Transaction processing computer 150, transport computer 140, and authorization subject computer 160 may use appropriate routing tables to route authorization request messages and/or authorization response messages using payment credentials, merchant identifiers, or other account identifiers.

[0045] A method 400 according to embodiments of the present invention may be described with reference to FIG. 4. References are also made to some of the elements shown in other figures.

[0046] The steps presented in the method 400, as well as the steps shown in FIG. 5-6 may be performed sequentially or in any suitable order in embodiments of the present invention. In some embodiments, one or more steps may be optional.

[0047] The various messages described below, as well as the messages described with reference to FIG. 5-6 may use any suitable form of communication. In some embodiments, the request or response may be in an electronic message format, such as an email message, a short message service (SMS) message, a multimedia messaging service (MMS) message, a Hypertext Transfer Protocol (HTTP) request message, a transmission control protocol packet ( TCP), transfer from a web form. The request or response may be directed to any suitable location, such as an email address, telephone number, Internet Protocol (IP) address, or Uniform Resource Locator (URL). In some embodiments, the request or response may contain a combination of different types of messages, such as both email messages and short message services.

[0048] Method 400 enables faster communication between user device 115 and access device 125 during a transaction. As mentioned above, this method can be used for a transaction of any suitable type, such as a payment transaction, an access transaction, an authentication transaction, etc., and a transaction can include a value of any suitable type, such as an amount of funds, an identity, a cryptogram, data value, etc. However, for the purpose of explanation, the payment transaction for authorizing the amount of funds is described below.

[0049] At step S410, a transaction may begin. For example, user 110 may approach access device 125 at a resource provider's location to purchase one or more goods and/or services. The access device 125 may begin receiving information about the items being purchased and adding up the prices of each of the items (eg, during an "electronic cash register bid, or ECR" process).

[0050] In step S415, access device 125 may request user 110 to provide user device 115. The user 110 may then grant the user device 115 to the 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 (eg, a chip board) on the user device 115 may come into direct contact with a second contact interface on the access device 125 . As a result, access device 125 may be able to communicate with user device 115 to process a transaction.

[0051] In some embodiments, the total amount of the transaction may not be fully calculated upon initial insertion of the user device 115. For example, the transaction may occur at a grocery store and the user 110 may insert the user's device 115 before all items are entered into the access device 125 by the store clerk.

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

[0053] In step S420, the access device 125 may generate or identify a preset or estimated amount that can be used prior to determining the actual amount of the transaction. The access device 125 may be able to provide this estimated amount to the user device 115 so that the user device 115 can generate a cryptogram with the estimated amount. As a result, transaction processing can continue immediately without waiting for all items to be scanned. This may allow faster completion of the communication between the access device 125 and the user device 115 and thereby allow the user 110 to remove the user device 115 from the access device 125 earlier.

[0054] The estimated amount may be determined based on the resource provider, merchant category classification (MCC), transaction type, median transaction value for the resource provider, or any other suitable aspects. For example, if transactions at a resource provider typically range from $30 to $35, the estimated amount could be set to $31.11 (for example, the average amount). In some embodiments, the use of an estimated amount that is in the usual range (e.g., an amount that is in the range of $30 to $35 for the example above) may serve to authenticate an authorization request from the issuer (e.g., since the issuer may know the usual range of the transaction amount for the resource provider).

[0055] In some embodiments, the estimated amount may be pre-set as a random number or any other suitable number. Additionally, in some embodiments, the estimated amount may be the same for each transaction or may change periodically (eg, for each transaction or once a day).

[0056] At step S425, the access device 125 may exchange data for transaction processing with the user device 115. For example, access device 125 may provide an estimated amount to user device 115 and may request credentials (eg, payment credentials, cryptogram, etc.) for a transaction from user device 115. The user device 115 may provide credential data to the access device 125, and the credential data may include a cryptogram such as an Authorization Request Cryptogram (ARQC), a Transaction Certificate (TC), or an Application Authentication Cryptogram (AAC). A detailed example of interactions between the access device 125 and the user device 115 in step S425 is further described below with reference to FIG. 6.

[0057] In step S430, the access device 125 may determine whether the user device 115 has provided a cryptogram for online transaction processing (eg, ARQC). For example, user device 115 could provide a cryptogram, but the cryptogram could be ARQC, TC, or AAC. If the user device 115 has granted ARQC, the access device 125 may be able to perform online authorization and may proceed to step S440. The cryptogram may be based on at least the estimated amount of the transaction, the access device ID, and any other pertinent information.

[0058] In step S435, if the access device 125 has not received the ARQC from the user device 115, the access device 125 may end (eg, cancel) the transaction. For example, the access device 125 may have received an AAC, which may indicate that the user device 115 has rejected the transaction. In some embodiments, access device 125 may not proceed to step S440, but may proceed to an alternate process. For example, access device 125 may proceed to process an online transaction, but may not release user device 115 until issuer authorization has been accepted. Alternatively, access device 125 may perform offline authorization.

[0059] In step S440, access device 125 may store information received from user device 115 (eg, if ARQC was received in step S430). For example, access device 125 may temporarily store payment credentials, a transaction cryptogram, and any other pertinent information received from user device 115. The information may be stored such that the access device 125 may still use the information in the authorization request message after the user device 115 is removed. This may allow the user's device 115 to be removed before an authorization request message is generated or sent.

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

[0061] In some embodiments, the access device 125 may allow the user device 115 to be retrieved by completing the exchange of transaction data between the access device 125 and the user device 115. Completing the transaction data exchange with the user device 115 may reset the user device 115 to default settings such that the user device 115 has a clean state and is ready for another subsequent transaction.

[0062] In some embodiments, to complete a transaction with user device 115, access device 125 may request a second cryptogram from user device 115. When requesting the second cryptogram, access device 125 may inform user device 115 that online authorization was not possible (eg, due to a bad connection), that online authorization was successful, or that authorization was denied.

[0063] As an example, in step S445, the access device 125 may inform the user device 115 that an online connection is not available, which means that the authorization cannot be completed online and the transaction should be rejected or the authorization is pending. For example, the authorization response code may be set to indicate that an online connection is not available. Then, in step S450, the user device 115 may return a second cryptogram (eg, AAC) indicating that the transaction has been rejected or authorization may be delayed. Reception of the second cryptogram may indicate the completion of the exchange of transaction data between the access device 125 and the user device 115 . Accordingly, the user device 115 can be safely removed at this point.

[0064] In step S455, the user 110 may remove the user device 115 from the access device 125 . For example, access device 125 may request user 110 to remove user device 115. A visual display may be presented, an audible sound may be played, a store clerk may inform the user 110, or any other method may be used to inform the user 110 that the user's device 115 can be removed.

[0065] Thus, the user device 115 can be retrieved after a small amount of residence time in the access device 125. The user 110 may not have to wait for the full amount of the transaction to be calculated or for the receipt of an authorization response message. Instead, the data of the user device 115 may be stored and the user device 115 may be released even before an authorization request message is sent. As a result, the user device 115 can be removed within two seconds of being in contact with the access device 125. This can reduce contact time by more than eighteen seconds (90%) from the current possible insertion time of twenty seconds or more.

[0066] Additionally, despite being retrieved earlier than usual, the user device 115 can still be retrieved in a clean state by requesting a second cryptogram earlier than usual (eg, before an Authorization Response message is received). In reality, the access device 125 may actually have an online connection, and the access device 125 may not yet have received the authorization response message. However, the access device 125 may substantially provide false information to the user device 115 so that the user device 115 can complete its transaction process and be retrieved earlier than usual.

[0067] As mentioned above, the information received from the user device 115 in step S425 can be stored and transaction processing can continue despite the fact that the user device 115 is removed. While the access device 125 may receive the AAC, the access device may not reject the transaction, but may instead continue to process the transaction normally. For example, access device 125 may continue to update the transaction total as new items are added, and eventually access device 125 may send an authorization request message for the transaction.

[0068] At step S460, the access device 125 could receive information about all purchased items. For example, a store clerk might finish scanning each of the items. As a result, the final transaction amount can be determined and the ECR application process can be completed.

[0069] In step S465, immediately after determining the total amount of the transaction, the user 110 may confirm the actual amount for the transaction. For example, access device 125 may display the total amount, and user 110 may indicate consent (eg, by pressing a button on the device to enter a pin or provide a signature). The actual amount for a transaction may likely differ from the predetermined or estimated amount.

[0070] In step S470, 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 contain the actual transaction amount, an estimated or preset amount, user device 115 credentials (eg, payment credentials, ARQC, etc.), and any other pertinent information.

[0071] In some embodiments, the authorization request message may be generated earlier in the process, and the authorization request message may be modified to contain the actual amount when known. In some embodiments, the actual amount may be included as data in an additional or actual data field in the authorization request message.

[0072] An authorization request message may be sent to transport computer 140, which may route it to transaction processing computer 150, which may in turn route it to authorization subject computer 160. Authorization subject computer 160 can determine whether the transaction should be authorized. For example, the authorization subject's computer 160 may authenticate the cryptogram (eg, ARQC), verify that there are sufficient funds in the user's account, perform a risk analysis, and perform any other steps to determine whether a transaction should be authorized. Authorization subject computer 160 may then send an authorization response message indicating successful authorization back to access device 125 (eg, via transaction processing computer 150, transport computer 140, and/or resource provider computer 130).

[0073] In step S475, the access device 125 may receive an authorization response message from the authorization subject computer 160 indicating that the transaction has been approved or denied. The access device 125 may display an appropriate message to the user 110 and/or the store clerk, and the resource provider may release the purchased goods and/or services to the user 110.

[0074] At some point in time between the transport computer 140, the transaction processing computer 150 and the computer 160 of the authorization subject, a clearing and settlement process can be performed.

[0075] Because the user device 115 is no longer connected to the access device 125 at the time of receiving the authorization response message, the user device 115 cannot receive information from the computer 160 of the authorization subject. For example, user device 115 cannot receive or authenticate an Authorization Response Cryptogram (ARPC) from an authorization subject, user device 115 cannot receive issuer command files, and user device 115 cannot receive an updated counter (e.g., an offline transaction counter). However, all this data can only be useful in offline transaction scenarios, and cannot provide any useful function in areas where transactions are conducted online. As a result, the user device 115 is still useful, even though it may lack this information.

[0076] As described above, by using an estimated amount and starting a transaction with that amount (e.g., for an "allowed amount" field when communicating with the user device 115), the amount of time that the user device must be inserted into the access device. This is because the communication between the user's device and the access device can be completed without waiting for the actual transaction amount to be calculated.

[0077] Additionally, access device 125 may inform user device 115 that authorization has been denied (eg, due to no online connection) so that user device 115 may return to a clean state and then be retrieved. The data of the user device 115 may be stored for final processing when the final amount of the transaction is determined. Thus, the insertion time can be further reduced because the user device 115 can be removed before an authorization request message is sent and before an authorization response message is received.

[0078] Additionally, in some embodiments, the receipt of the signature may be delayed (eg, so that the user's device 115 can be removed until the signature is received). In some embodiments, if the final amount is less than the payment limit, then a signature may not be required. On the other hand, if the final amount exceeds the payment limit, then the user's signature can be obtained after the transaction is approved.

[0079] In some embodiments, the implementation of this method does not require changes to standard transaction processing procedures, associated hardware, or user device. This method of providing less user device insertion time can be implemented with minimal software updates to access device 125 communication procedures. Additionally, the changes made to implement this method do not cause any reduction in security. The strength of the cryptogram and the overall security of the transaction can be maintained and online authorization can still take place in the same secure manner.

[0080] In some embodiments, the total amount of the transaction may be determined and known before the user 110 provides the user's device 115 to the access device 125. For example, in a restaurant, payment may be provided upon receipt of goods and services, and the user 110 may provide payment after the transaction amount has been calculated. Accordingly, in some embodiments, the transaction may be processed without an estimated amount. A method 500 for conducting such a transaction according to embodiments of the present invention may be described with reference to FIG. 5.

[0081] At step S510, a transaction may begin. For example, user 110 may approach access device 125 at a resource provider's location to purchase one or more goods and/or services. In some embodiments, the final amount of the transaction may be known or determined at this point. For example, the user's items may have already been scanned on the access device 125, the user 110 may only purchase one item, which is quickly scanned on the access device 125, or the user 110 may provide payment for goods or services already received (eg, a meal at a restaurant). In some embodiments, the ECR claim process may end when the final amount of the transaction is known (eg, since all items could be scanned and the amount finally determined on access device 125).

[0082] In step S515, access device 125 may request user 110 to provide user device 115. For example, access device 125 may prompt user 110 for user device 115 immediately after the end of the ECR application process. The user 110 may then grant the user device 115 to the 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 (eg, a chip board) on the user device 115 may come into direct contact with a second contact interface on the access device 125 . As a result, access device 125 may be able to communicate with user device 115 to process a transaction.

[0083] In step S520, the user 110 may confirm the amount for the transaction. For example, access device 125 may display the total amount, and user 110 may indicate consent (eg, by pressing a button on the device to enter a pin or provide a signature). In some embodiments, the user 110 may confirm the amount before the user device 115 is presented, while the user device 115 is inserted, after the user device 115 is removed, or at any other appropriate time in the process.

[0084] In step S525, the access device 125 may exchange data for transaction processing with the user device 115. For example, access device 125 may provide a transaction amount to user device 115 and may request credentials (eg, payment credentials, cryptogram, etc.) for a transaction from user device 115. User device 115 may provide credential data to access device 125, and credential data may include a cryptogram (eg, ARQC, TC, or AAC). A detailed example of interactions between the access device 125 and the user device 115 in step S525 is further described below with reference to FIG. 6.

[0085] In step S530, the access device 125 may determine whether the user device 115 has provided a cryptogram for online transaction processing (eg, ARQC). For example, user device 115 could provide a cryptogram, but the cryptogram could be ARQC, TC, or AAC. If the user device 115 has granted ARQC, the access device 125 may be able to perform online authorization and may proceed to step S540. The cryptogram may be based on at least the final amount of the transaction, the access device ID, and any other pertinent information.

[0086] In step S535, if the access device 125 has not received the ARQC from the user device 115, the access device 125 may complete (eg, cancel) the transaction. For example, the access device 125 may have received an AAC, which may indicate that the user device 115 has rejected the transaction. In some embodiments, access device 125 may not proceed to step S440, but may proceed to an alternate process. For example, access device 125 may proceed to process an online transaction, but may not release user device 115 until issuer authorization has been accepted. Alternatively, access device 125 may perform offline authorization.

[0087] In step S540, access device 125 may store information received from user device 115 (eg, if ARQC was received in step S430). For example, access device 125 may temporarily store payment credentials, a cryptogram, and any other pertinent information received from user device 115. The information may be stored such that the access device 125 may still use the information in the authorization request message after the user device 115 is removed. This may allow the user's device 115 to be removed before an authorization request message is generated or sent.

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

[0089] In some embodiments, the access device 125 may allow the user device 115 to be retrieved by completing the exchange of transaction data between the access device 125 and the user device 115. Completing the transaction data exchange with the user device 115 may reset the user device 115 to default settings and/or an idle state such that the user device 115 has a clean state and is ready for another subsequent transaction.

[0090] In some embodiments, to complete a transaction with user device 115, access device 125 may request a second cryptogram from user device 115. When requesting the second cryptogram, access device 125 may inform user device 115 that online authorization was not possible (eg, due to a bad connection), that online authorization was successful, or that authorization was denied.

[0091] As an example, in step S545, the access device 125 may inform the user device 115 that an online connection is not available, which means that the authorization cannot be completed online and the transaction should be rejected or the authorization is pending. For example, the authorization response code may be set to indicate that an online connection is not available. Then, in step S550, the user device 115 may return a second cryptogram (eg, AAC) indicating that the transaction has been rejected or authorization may be delayed. Reception of the second cryptogram may indicate the completion of the exchange of transaction data between the access device 125 and the user device 115 . Accordingly, the user device 115 can be safely removed at this point.

[0092] In step S555, the user 110 may remove the user device 115 from the access device 125 . For example, access device 125 may request user 110 to remove user device 115. A visual display may be presented, an audible sound may be played, a store clerk may inform the user 110, or any other method may be used to inform the user 110 that the user's device 115 can be removed.

[0093] Thus, the user device 115 can be retrieved after a small amount of residence time in the access device 125. The user 110 may not have to wait for an authorization response message to be received. Instead, the data of the user device 115 may be stored and the user device 115 may be released even before an authorization request message is sent. As a result, the user device 115 can be removed within two seconds of being in contact with the access device 125. This can reduce contact time by more than eighteen seconds (90%) from the current possible insertion time of twenty seconds or more.

[0094] Additionally, despite being retrieved earlier than usual, user device 115 can still be retrieved in a clean and/or idle state by requesting a second cryptogram earlier than usual (eg, before an Authorization Response message is received). In reality, the access device 125 may actually have an online connection, and the access device 125 may not yet have received the authorization response message. However, the access device 125 may substantially provide false information to the user device 115 so that the user device 115 can complete its transaction process and be retrieved earlier than usual.

[0095] As mentioned above, the information received from the user device 115 in step S525 can be stored and transaction processing can continue even though the user device 115 is removed. While the access device 125 may receive the AAC, the access device may not reject the transaction, but may instead continue to process the transaction normally. For example, access device 125 may send an authorization request message for a transaction.

[0096] In 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 contain the transaction amount, user device 115 credentials (eg, payment credentials, ARQC, etc.), and any other suitable information.

[0097] In some embodiments, the user device 115 may still be connected to the access device 125 at the time the authorization request message is sent. For example, an authorization request message can be generated and sent quickly, such that the message is sent before the user 110 removes the user's device 115.

[0098] An authorization request message may be sent to transport computer 140, which may route it to transaction processing computer 150, which may in turn route it to authorization subject computer 160. Authorization subject computer 160 can determine whether the transaction should be authorized. For example, the authorization subject's computer 160 may authenticate the cryptogram (eg, ARQC), verify that there are sufficient funds in the user's account, perform a risk analysis, and perform any other steps to determine whether a transaction should be authorized. Authorization subject computer 160 may then send an authorization response message indicating successful authorization back to access device 125 (eg, via transaction processing computer 150, transport computer 140, and/or resource provider computer 130).

[0099] In step S565, the access device 125 may receive an authorization response message from the authorization subject computer 160 indicating that the transaction has been approved or denied. The access device 125 may display an appropriate message to the user 110 and/or the store clerk, and the resource provider may release the purchased goods and/or services to the user 110.

[0100] At some point in time between the transport computer 140, the transaction processing computer 150 and the computer 160 of the authorization subject, a clearing and settlement process can be performed.

[0101] Since the user device 115 may no longer be connected to the access device 125 at the time of receiving the authorization response message, the user device 115 may not receive information from the computer 160 of the authorization subject. For example, user device 115 cannot receive or authenticate an Authorization Response Cryptogram (ARPC) from an authorization subject, user device 115 cannot receive issuer command files, and user device 115 cannot receive an updated counter (e.g., an offline transaction counter). However, all this data can only be useful in offline transaction scenarios, and cannot provide any useful function in areas where transactions are conducted online. As a result, there may be no loss of functionality by the user device 115 in the absence of this information.

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

[0103] In some embodiments, the user device 115 may be removed shortly after it is inserted into the access device 125. Access device 125 may inform user device 115 that authorization has been denied (eg, due to no online connection) so that user device 115 may return to a clean and/or idle state and then be retrieved. The data of the user device 115 may be stored for authorization processing after the user device 115 is removed. Thus, the insertion time can be reduced because the user device 115 can be removed without waiting for an authorization response and any further processing.

[0104] Additionally, the receipt of the signature may be delayed (eg, so that the user's device 115 can be removed until the signature is received). In some embodiments, if the final amount is less than the payment limit, then a signature may not be required. On the other hand, if the final amount exceeds the payment limit, then the user's signature can be obtained after the transaction is approved.

[0105] In some embodiments, the implementation of this method may not require changes to standard transaction processing procedures, associated hardware, or user device. This method of providing less user device insertion time can be implemented with minimal software updates to access device 125 communication procedures. Additionally, changes made to implement this method may not cause any reduction in security. The strength of the cryptogram and the overall security of the transaction can be maintained and online authorization can still take place in the same secure manner.

[0106] Embodiments of the present invention may include a number of data exchanges between user device 115 and access device 125. For example, multiple messages may be exchanged during step S425 in method 400 and step S525 in method 500 to process a transaction and receive information from user device 115. An example flow 600 of these data exchanges is shown in FIG. 6.

[0107] When the user device 115 comes into contact with the access device 125, the user device 115 and the access device 125 can communicate with each other. Several processing steps may occur to identify and prepare data for transmission to access device 125 for a transaction. In some embodiments, application protocol data unit (APDU) messages may be exchanged between user device 115 and access device 125. The messages may take the form of APDU commands sent from access device 125 to user device 115 and APDU responses sent from user device 115 to access device 125. However, it should be understood that other messages, messaging protocols, or formats may be used to exchange the relevant information for the purpose of conducting a transaction.

[0108] In step S610, the 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 to request information about which payment applications (eg, an AID list) may be available on user device 115. . In some embodiments, the request for available applications may be in the form of a selection command.

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

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

[0111] 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 take the form of a read record command or an AID (or ADF) select command.

[0112] The user device 115 may then send a request for transaction data to the access device 125 as may be necessary to complete the transaction using the selected application/AID. In some embodiments, the request may be in the form of a read record response or an AID (or ADF) select response. The request may contain a list of transaction data identifiers, and the list may be in the form of a processing parameter data object list (PDOL). The requested transaction data may include terminal-side transaction qualifiers (TTQ), allowed amount, other amount, terminal country code, terminal validation results, transaction currency code, transaction data, transaction type, and/or unpredictable number.

[0113] In step S620, the access device 125 may initiate application processing. For example, access device 125 may request that user device 115 specify data (eg, a list of files containing data) to be used for the selected application and supported features. In some embodiments, access device 125 may send a Get Processing Parameters (GPO) command. Access device 125 may also provide transaction information to user device 115 (eg, via a GPO command). For example, the access device 125 may provide transaction data requested by the user device 115 via a processing parameter data object list (PDOL). The transaction data provided may include the amount of the transaction, such as the final amount of the transaction or an estimated amount of the transaction (eg, if the final amount of the transaction is not yet known).

[0114] The user device 115 can then generate dynamic transaction processing information using at least some of the received transaction data from the terminal, 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 comprise one or more application file locators (AFLs) that may be used as file addresses by access device 125 to read account data stored on user device 115.

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

[0116] The user device 115 can then send the account data to the access device 125 . In some embodiments, account data may be sent in the form of a read record response. The account data may include, for example, data equivalent to that contained in track 2 (eg, payment credential data) and the name of the cardholder and/or other data associated with the account that is available at the location according to the AFL.

[0117] One or more stages of authentication and verification may be performed to confirm that the transaction can continue. For example, steps S640-S680 provide various authentication processes. In some embodiments, one or more of these steps may be omitted because online authentication and/or authorization may be a sufficient alternative.

[0118] In step S640, the access device 125 may determine whether it should authenticate the user device 115 offline. The determination may be made based on whether the user's device 115 supports offline authentication. In some embodiments, one or more types of offline authentication may occur, such as static data authentication (SDA) or dynamic data authentication (DDA).

[0119] In step S650, the access device 125 may check the processing restrictions. For example, the access device 125 may determine whether to allow the transaction to proceed based on the expiration date of the user device, the date the user device was put into service, the application match between the user device 115 and the access device 125, usage restrictions (e.g., restrictions on international purchases or refund services) and any other applicable restrictions.

[0120] In step S660, the access device 125 may perform cardholder verification. For example, user 110 can be confirmed to be a legitimate user of user device 115 rather than a fraudster. One or more card verification methods (CVM) may be used. For example, the user 110 may be prompted to provide a PIN (eg, verified online by the authorization entity or offline by the user's device 115), a signature, or any other suitable method of authentication.

[0121] In step S670, the access device 125 may perform risk management on the terminal side. For example, access device 125 may perform a turnover rate check, determine if a transaction exceeds a merchant's threshold limit, check if an account number is flagged for rejection, determine if a consecutive transaction limit has been exceeded, and/or check for any other suitable fraud indicators.

[0122] In step S680, the access device 125 may perform terminal activity analysis. For example, the access device may determine whether to approve the transaction offline, submit it online for authorization, or reject it offline. This determination may be based on one or more of the authentication and risk analysis steps described above (eg, steps S640-S670). As mentioned above, in some embodiments, all transactions may be authorized online. Accordingly, the access device 125 can automatically proceed to the online authorization process.

[0123] The access device 125 may then request the cryptogram from the user device 115 (eg, via an application cryptogram generation command). Access device 125 may specifically request an Authorization Request Cryptogram (ARQC), a Transaction Certificate (TC), or an Application Authentication Cryptogram (AAC). In some embodiments, ARQC may be requested for online authorization, TC may be requested for offline authorization (eg, already approved offline), and AAC may be requested to deny a transaction or delay authorization.

[0124] The user device 115 can then determine what type of cryptogram to provide to the access device. For example, user device 115 may provide ARQC to navigate to online authorization. Alternatively, user device 115 may determine that the transaction should be rejected and may return an AAC.

[0125] In some embodiments, an ARQC may be generated based on transaction-specific information. For example, the transaction amount received from the access device 125 (eg, in step S620), transaction ID, merchant ID, and any other suitable transaction related information can be used as input to an algorithm generating ARQC. Any other suitable information can also be used as input, such as a random number, transaction count, etc. The ARQC may be generated using an authorization subject key that is stored on the user device 115 and known on the authorization subject computer 160 . Accordingly, the authorization subject computer 160 can authenticate the ARQC when it is received with an authorization request message.

[0126] In some embodiments, immediately after the user device 115 sends the cryptogram to the access device 125, the communication between the user device 115 and the access device 125 may achieve its primary purposes (e.g., provide credential data to the access device 125 for a transaction). Accordingly, steps S610-S680 may cover the processing mentioned in step S425 in method 400 and step S525 in method 500.

[0127] Method 600 proceeds to additional steps to gracefully complete communication between access device 125 and user device 115, retrieve user device 115, and authorize the transaction. These steps are the same as those already described with reference to FIG. 4-5. (eg, steps S430-S475 in method 400 and steps S630-S565 in method 500).

[0128] In step S710, the access device 125 may receive the cryptogram from the 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 cryptogram is ARQC. In some embodiments, if ARQC is received, access device 125 may proceed to an online authorization process.

[0129] Access device 125 may store user device 115 information (eg, account credentials, cryptogram, etc.) for later processing (eg, as mentioned in steps S440 and S540). For example, the final amount of the transaction may not yet be known, so that the access device 125 may store the information of the user device 115 until authorization can be completed.

[0130] Once the necessary user device 115 information (eg, account credentials, cryptograms, etc.) is received and stored, the user device 115 may no longer be needed on the access device 125. Accordingly, the communication between the access device 125 and the user device 115 may be completed and the user device 115 removed earlier (eg, as mentioned in steps S445-S455 and S545-S555). For example, the user device 115 may be retrieved before the final transaction amount is calculated, before the authorization response message is sent, and before the authorization response message is received.

[0131] In step S720, the access device 125 may complete the exchange of transaction data with the online user device 115 (eg, as mentioned with reference to steps S455 and S550). For example, access device 125 may request a second cryptogram from user device 115 because user device 115 may revert to a default setting after the second cryptogram is provided.

[0132] Access device 125 may use a second application cryptogram generation command to request a second cryptogram. In some embodiments, access device 125 may request an AAC indicating that the transaction should be rejected or delayed because authorization cannot be completed online (eg, as mentioned with reference to steps S445 and S545). Although the authorization may actually take place online (and may not even have been attempted yet), this command may be used simply to complete communication with the user's device 115. False information about the rejection or delay of the transaction may not have an impact on the actual transaction or any negative impact on the device 115 of the user.

[0133] In some embodiments, the access device 125 may alternatively indicate that the transaction has been successfully authorized (despite the fact that the authorization has not yet taken place) and request a TC.

[0134] The user device 115 may then respond with an application cryptogram generation response that contains the AAC. The user device 115 may then complete its internal processing, revert to clean settings, default settings, and/or idle settings, and thereby be ready to be retrieved from the access device 125.

[0135] Once access device 125 receives the second cryptogram from user device 115, access device 125 may request user 110 to remove user device 115 from access device 125 (eg, as mentioned with reference to steps S455 and S555).

[0136] Thus, the user device 115 can be retrieved after one continuous communication flow with the access device 125. There may be no delays in data exchange due to the calculation of the transaction amount or the receipt of online authorization. Instead, the information can be retrieved from the user device 115 in less time, the user device 125 can be retrieved, and the access device 125 can continue processing the transaction without the user device 115 connected to it.

[0137] In step S730, immediately after the final amount of the transaction is known, the access device 125 may process the transaction online. For example, access device 125 may generate an authorization request message and send an authorization request message to authorization subject computer 160 for authorization (eg, as described in steps S470-S475 and steps S560-S565).

[0138] Embodiments of the present invention have a number of advantages. For example, in embodiments of the present invention, communication for processing a transaction between a user's device (eg, a smart card or an integrated circuit card) and an access device can occur quickly and efficiently. All communication between the user device and the access device can occur in one immediate and accelerated sequence of operations without any delay. For example, upon contact with the user's device, the access device may immediately provide a transaction value (eg, a final value or an estimated value). As a result, the user device can immediately generate a cryptogram based on the value (and other information). Additionally, immediately after the access device receives credential data (eg, account information and cryptograms) from the user's device, the access device may complete the exchange of transaction data and the user device may be removed. The user may be able to remove the user's device without waiting for an authorization response message or post-authorization processing.

[0139] 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, the embodiments provide an average reduction of six to ten seconds (75% - 83%) compared to the current average insertion time of eight to twelve seconds, as well as a potential reduction in time of eighteen seconds or more (90% or more ) compared to the current possible insertion time of twenty seconds or more. In addition to the reduction in actual contact time, the user may experience an even greater reduction in contact time.

[0140] Embodiments of the present invention may further advantageously reduce overall transaction time. For example, embodiments provide for the elimination of post-authorization processing such as card issuer batch file processing and issuer authentication on the user's device. Eliminating these steps not only reduces the amount of time the user's device is inserted into the access device, but also reduces the amount of time the user waits at the access device (eg, until goods and services are dispensed and the user can leave). In embodiments, the user device cannot receive information about the issuer's response (eg, the data received in the authorization response message). However, this data may not be necessary for online transactions. Accordingly, reducing the contact time as described herein may not have any disadvantages (eg, no reduction in security and no loss of useful information).

[0141] Embodiments of the present invention advantageously allow the user device to have a clean state at the end of a transaction, despite the user device being retrieved earlier than usual. For example, the access device may request a second cryptogram earlier than usual (eg, by falsely indicating a failed online connection), so that the user device may complete its transaction processing and then be retrieved.

[0142] Embodiments of the present invention can advantageously be implemented without hardware changes, changes to EMV transaction processing standards, or changes to the user's device. Instead, a software update on the access device may provide the new steps and communications described herein.

[0143] A computer system that can be used to implement any of the entities or components described herein will now be described. Subsystems in a computer system are interconnected via a system bus. Additional subsystems include a printer, keyboard, fixed disk, and a monitor that can be connected to a display adapter. Peripherals and input/output (I/O) devices that can be connected to the I/O controller can be connected to the computer system using any number of means known in the art, such as a serial port. For example, a serial port or external interface may be used to connect the computing device to a wide area network such as the Internet, a mouse input device, or a scanner. System bus interconnection allows the CPU to communicate with each subsystem and manage the execution of commands from system memory or a fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may be a computer readable medium.

[0144] As described, an innovative service may include the implementation of one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, steps, or method steps may result from the execution of a set of instructions or program code by an appropriately programmed computing device, microprocessor, data processing device, or the like. The instruction set or program code may be stored in a memory or other form of data storage element that is accessed by a computing device, microprocessor, or the like. In other embodiments, the functions, processes, operations, or steps of a method may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0145] Any of the software components or functions described herein may be implemented as program code to be executed by a processor using any suitable computer language such as, for example, Java, C++, or Perl, using, for example, traditional or object-oriented approaches. The program code may be stored as a series of instructions or instructions in a computer readable medium such as random access memory (RAM), read only memory (ROM), magnetic media such as a hard disk or floppy disk, or optical media such as a CD-ROM. . Any such computer-readable medium may be on or in a single computing device and may be present on or in different computing devices within a system or network.

[0146] Although certain exemplary embodiments have been described in detail and depicted in the accompanying drawings, it is to be understood that such embodiments are illustrative only and are not intended to limit the broad invention, and that the invention should not be limited to the specific representations and descriptions. circuits and designs, as various other modifications may be apparent to those skilled in the art.

[0147] In the context of this document, the use of the singular form means "at least one", unless otherwise indicated separately.

Claims (29)

1. The method of conducting a transaction, including: providing physical contact of the user's device with the access device; transmitting by the user's device to the access device credential data for the transaction, wherein the access device stores the credential data; before the authorization response message for the transaction is received at the access device from the computer of the authorization subject, the user device receives from the access device a message informing the user device that the transaction is completed, even if the authorization response message has not yet been received at the device access that transaction authorization is denied or that transaction authorization will be delayed because online authorization is not available even though online authorization is available; before the message with the authorization response for the transaction is received on the access device from the computer of the authorization subject, the user's device completes the data exchange with the access device, wherein the completion of the data exchange with the access device comprises: transmission by the user device of the cryptogram to the access device; and returning the user's device to a default or clean state after sending said cryptogram, wherein returning to the default or clean state makes the user's device ready for a subsequent transaction; and after completion of the communication with the access device, a separation from the access device is performed, wherein the access device allows the user device to be separated from the access device after the communication with the access device is completed and before said authorization response message for the transaction is received from said subject computer authorization. 2. The method of claim 1, wherein the user's device is a card. 3. The method according to claim 1, in which the user device is a card with an integrated circuit having a chip board, while the access device includes a contact chip reader, while providing physical contact with the access device includes providing direct contact of the chip board with the device contact chip reader such that the user device can communicate with the access device, and wherein separation 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. 4. The method of claim. 1, in which the completion of the exchange of data with the access device includes: generating said cryptogram by the user's device. 5. The method of claim 4, wherein the message from the access device is a message informing the user device that the transaction has been completed, and wherein the cryptogram is the transaction certificate. 6. The method of claim 4, wherein the message from the access device is a message informing the user device that transaction authorization will be delayed or denied because online authorization is not available, and wherein the cryptogram is an application authentication cryptogram. 7. The method of claim 4, wherein the message from the access device includes a request for a cryptogram. 8. The method of claim 4, wherein the cryptogram is the second cryptogram, and the method further comprises: generation by the user's device of the first cryptogram, wherein the credential data includes a first cryptogram, and wherein the transmission of the credential data to the access device for the transaction includes the transmission of the first cryptogram to the access device. 9. The method of claim 8, wherein the first cryptogram is an authorization request cryptogram. 10. The method of claim 8, further comprising: receiving by the user device from the access device of the estimated value, wherein the first cryptogram is generated based on the estimated value, wherein the access device asks the user for confirmation of the final value, and wherein the access device generates an authorization request message for the transaction, which includes the estimated value and final size. 11. The method of claim 8, wherein the access device asks the user for confirmation of the final value, the method further comprising: receiving by the user device from the access device the final value, wherein the first cryptogram is generated based on the final value, and wherein the access device generates an authorization request message for the transaction, which includes the final value. 12. The method of claim 1, wherein the access device generates an authorization request message for the transaction, transmits the authorization request message to the computer of the authorization subject, and receives an authorization response message for the transaction from the computer of the authorization subject while the user device is physically separated from the access device. 13. The method of claim 12, wherein the user device is separated from the access device before the access device sends an authorization request message to the computer of the authorization subject. 14. The method of claim 12, wherein the user device is separated from the access device before the access device generates an authorization request message. 15. The method of claim 1, wherein for the same transaction, the user device is not contacted by the access device again. 16. The method of claim. 1, in which the user's device does not receive information associated with the transaction from the computer of the subject of authorization. 17. The method of claim 1, wherein the access device prompts the user to remove the user's device.

Images