MX2008004209A - Device, system and method for reducing an interaction time for a contactless transaction - Google Patents

Abstract

A method. The method comprises, at a reader, performing at least one transaction-based risk management process prior to energizing a contactless interface, initiating communication with a card utilized for the contactless transaction, receiving information associated with the card, and terminating communication with the card prior to authorizing the contactless transaction.

Description

DEVICE, SYSTEM AND METHOD TO REDUCE AN INTERACTION TIME FOR A NON-CONTACT TRANSACTION CROSS REFERENCE TO RELATED REQUESTS This application claims the priority benefit of the provisional patent application of the US. Serial Number 60/721, 454, filed September 28, 2005, and from the US patent application. Serial Number 60 / 807,775, filed July 19, 2006. BACKGROUND This application describes an invention that relates in general and in various ways, to a device, system and method to reduce an interaction time for a non-contact transaction. Wireless and contactless communication technologies have spread more in recent years. In the payment industry, contactless payments have a number of advantages over both traditional magnetic tape technologies and contact-based chip payment protocols. For example, contact cards for traditional payments are known to operate relatively slowly, and magnetic strip or magnetic strip cards are known to be not sufficiently secure. Each of these technologies also requires a slot in a terminal reader that must be maintained by a merchant. Contactless payment does not require a slot where the card is inserted, the consumer retains control over the card and only places the card near the terminal reader whenever necessary. The traditional specifications adopted by the contact payment chip payment industry generally require that the consumer locate the card near the terminal reader at different times and / or for extended periods of time, in order to complete a transaction. With both merchants and consumers wanting faster transaction times, contactless transactions executed according to traditional specifications fail to meet market requirements. Merchants and consumers also demand that contactless transactions be more secure, although more recently non-contact magnetic strip cards have emerged that can be more secure than traditional magnetic strip cards, these contactless magnetic strip cards are typically designed only for online transactions. For non-contact offline transactions executed in accordance with traditional specifications, transactions may be susceptible to various types of off-line attacks of "intermediary" generally preferred such as manga attacks, Trojan horse attack, etc. In a type of attack with a sleeve or sleeve, a device intercepts data wirelessly transmitted from a card reader that is intended for a contactless card. The device alters the data and subsequently transmits the altered data to the card. Instead of receiving the data transmitted by the card reader, the card receives the altered data transmitted by the device. The card subsequently processes the altered data and transmits a message related to the altered data to the card reader. Card reader subsequently gives approval of the transaction based on the information present in the message transmitted by the card. In another type of cuff attack, a device intercepts data transmitted wirelessly from the card intended for the card reader. The device alters the data and subsequently transmits the altered data to the card reader. Instead of receiving the data transmitted by the card, the card reader receives the altered data transmitted by the device. The card reader subsequently processes the altered data and grants approval of the transaction, based on information present in the altered data transmitted by the device. In other types of attacks with sleeve or sleeve, the device can cause a denial of service by not sending the intercepted data to the card or the card reader. In a type of Trojan horse attack, malicious software embedded in the card alters valid data before information is sent to the card reader. The card reader finally grants approval of the transaction based on the altered data. In another type of Trojan horse attack, malicious software embedded in the card reader alters valid data before the authorization process. The card reader finally grants approval to the transaction, based on the altered data. For a given off-line transaction, an attack of "intermediary" can be used to reduce the amount of transaction as finally recognized by the card and the card reader. For example, for a particular off-line transaction involving the purchase of products from a merchant, the card reader can wirelessly transmit data intended for the card indicating that the value of the transaction is equal to $ 15. However, before the data is received by the card, the device intercepts the data and alters the data in such a way that the altered data indicates that the value of the transaction is equal to only $ 1. Once the card subsequently receives the altered data and transmits the message related to the altered data to the card reader, the card reader subsequently grants approval of a transaction equal to only $ 1. Upon receiving approval, the merchant sends the items with the belief that the amount of the approved transaction was equal to $ 15. The difference between the current transaction amount and the reduced transaction amount may affect the amount finally received by the merchant of the card issuer. BRIEF DIGEST OF THE INVENTION In a general aspect, this application describes a reader. According to various modalities, the reader comprises a non-contact interface and a transaction module. The transaction module is coupled to the non-contact interface and is structured and arranged to process a contactless transaction in less than half a second of interaction time between a card and the reader. In another general aspect, this application describes a card. According to various modalities, the card comprises a structured transaction module and arranged for wireless communication, the card is structured and arranged to operate in a chip mode and in magnetic tape data mode. In another general aspect, this application describes a system. According to various modalities, the system comprises a reader and a card. The reader comprises a non-contact interface and a transaction module. The card is structured and arranged to communicate with the reader through the non-contact interface. The transaction module couples to the non-contact interface and is structured and arranged to process a non-contact transaction with less than half a second of interaction time between the card and the reader. In another general aspect, this application describes a method for reducing an interaction time for a contactless transaction. According to various modalities, the method comprises, in a reader, performing at least one transaction-based risk management process before energizing a non-contact interface, initiating communication with a card used for the non-contact transaction, receiving information associated with the card and terminate communication with the card before authorizing the transaction without contact. In another general aspect, this application describes a method for preventing an intermediary attack in a contactless transaction. According to various embodiments, the method comprises receiving a dynamic signature comprising an application transaction counter, an unpredictable terminal number, a transaction quantity, a transaction currency code and an unpredictable card number. The method also comprises receiving an unpredictable card number, recalculating the dynamic signature using the unpredictable card number and authorizing the transaction without offline contact if the dynamic signature is validated. Aspects of the invention can be implemented by a computing device and / or a computer program stored in a computer. half readable by computer. The computer readable medium may comprise a disk unit, a device and / or a propagated signal. DESCRIPTION OF THE DRAWINGS Various embodiments of the invention are described here by way of example in conjunction with the following figures. Figure 1 illustrates various modalities of a reader to reduce an interaction time for a non-contact transaction; Figure 2 illustrates various modalities of a system for reducing an interaction time for a non-contact transaction; Figure 3 illustrates various embodiments of a method for reducing an interaction time for a non-contact transaction; Figure 4 is a simplified flow chart illustrating various embodiments of a preliminary transaction processing stage of the method of Figure 3; Figure 5 is a simplified flow chart illustrating various embodiments of an application selection step of the method of Figure 3; Figure 6 is a simplified flow chart illustrating various embodiments of an authorization step of the method of Figure 3; and Figure 7 illustrates various embodiments of a method for reducing an interaction time for a second non-contact transaction. DETAILED DESCRIPTION OF THE INVENTION It will be understood that at least some of the Figures and descriptions of the invention have been simplified to focus on elements that are relevant to a clear understanding of the invention, while eliminating, for purposes of clarity, other elements that those of ordinary skill in the art will appreciate may also comprise a portion of the invention. However, because these elements are well known in the art and because they do not necessarily facilitate a better understanding of the invention, a description of these elements is not provided here. Figure 1 illustrates various modalities of a reader 10 to reduce an interaction time for a non-contact transaction. The reader 10 can be any type of device that is structured and arranged to communicate with another device through a non-contact interface. According to various embodiments, the reader 10 may be a merchant device that is integrated into a point-of-sale device, or a merchant device that is separate from, but in communication with, a point-of-sale device. sale. As used herein, the phrase "interaction time" refers to the time of interaction between the reader 10 and another device and does not include the time required to go online for authorization or for the reader to validate a static or dynamic signature for a Offline data authentication. Reader 10 can be used with an existing payment system infrastructure for markets that require faster transaction times than those associated with traditional payment protocols. According to various modalities, the reader 10 can be used to reduce the interaction time to less than about 500 milliseconds. The reader 10 comprises a non-contact interface 12, and a transaction module 14 coupled to the non-contact phase. The transaction module 14 is structured and arranged to process a non-contact transaction in less than half a second of interaction time between the reader 10 and another device. The transaction module 14 can also be structured and arranged to perform static data authentication and / or dynamic data authentication, as described in more detail below. According to various embodiments, the reader 10 further comprises a security module 16 coupled to the transaction module 14. The security module 16 is structured and arranged to prevent an "intermediary" attack in a non-contact transaction. Each of the modules 14, 16 can be implemented in physical equipment or in micro-code or embedded software. According to various modalities, the modules 14, 16 can be implemented as software applications, computer programs, etc., using any convenient computer language (for example C, C ++, Delphi, Java, JavaScript, Perl, Visual Basic, VBScript, etc.) and can be incorporated permanently or temporarily in any type of machine, component, physical or virtual equipment, storage medium or propagated signal capable of supplying instructions to a device. The software code may be stored as a series of instructions or commands on a computer-readable medium such that when a processor reads the medium, the functions described herein are performed. As used herein, the term "computer-readable medium" may include, for example, optical and magnetic memory devices such as floppy disks, compact disks or both read-only and write-only varieties, optical disk drives and drives. of hard drives. A computer-readable medium can also include memory storage that can be physical, virtual, permanent, temporary, semi-permanent or semi-temporary. A computer readable medium may also include one or more propagated signals, and these propagated signals may or may not be transmitted on one or more carrier waves. Although the modules 14, 16 are illustrated in Figure 1 as two separate modules, a person skilled in the art will appreciate that the functionality of the modules can be combined into a single module. Figure 2 illustrates various embodiments of a system 20 for reducing an interaction time for a non-contact transaction. The system comprises the reader 10 and a card 22. As used herein the term "card" refers to any type of device that can communicate with the reader 10 on the non-contact interface 12. According to various embodiments, the card 22 can be a smart card, a mobile phone, a personal digital assistant, etc. The card 22 is structured and arranged to communicate with the reader 10 through the non-contact interface 12. According to various embodiments, the card 22 comprises a transaction module 24 structured and arranged to cooperate with the reader 10 to execute the transaction without contact . The card 22 may further comprise a security module 26 structured and arranged to cooperate with the reader 10, to avoid an "intermediary" attack in the non-contact transaction. The modules 24, 26 can be similar to the modules 14, 16 of the reader 10. According to various modalities, the card 22 can be a dual-mode card, which is structured and arranged to operate in either a chip mode or in data mode on magnetic tape (using data equivalent to track 2). The mode of operation used by the card 22 can be determined by the card 22 based on the capabilities of the reader 10. The system 20 can further comprise a network 28 coupled to the reader 10 and an emitter 30. The network 28 can be any convenient type network as is known in the art, can be coupled to the reader 28 in any convenient manner known in the art, and can be coupled to the emitter 30 in any convenient manner known in the art. The network 28 may include any type of delivery system including but not limited to a local area network (e.g. Ethernet), a wide area network (e.g., Internet and / or the World Wide Web), a telephone network (eg. example, analog, digital, wired, wireless, PSTN, ISDN, GSM, GPRS, and / or xDSL), a packet switched network, a radio network, a television network, a cable network, a satellite network and / or any other wired or wireless communication network, configured to carry data. The network 28 may include elements such as for example intermediate nodes, substitute servers, routers, switches and adapters configured to direct and / or send data. Figure 3 illustrates various embodiments of a method 40 for reducing an interaction time for a non-contact transaction. Method 40 can be implemented by system 20 of Figure 2. Method 40 comprises the general steps of preliminary transaction processing 42, discovery processing 44, application selection 46, application processing 48 and transaction authorization 50. To reduce to the minimum the interaction time between the card 22 and the reader 10 for a given transaction, the processing stage The preliminary transaction 42 is performed by the reader 10 before requesting the card 22 to be presented. During the preliminary transaction processing stage 42, the reader 10 performs certain transaction-based risk management processes. For example, according to various modalities, the reader 10 can obtain the transaction amount and compare the transaction amount with the limit of a transaction, a floor limit, a limit for the cardholder or card holder or cardholder verification method. , etc. Once the preliminary transaction processing stage 42 is completed, the reader 10 can signal a cardholder to present the card 22. Based on the preliminary transaction processing, the reader can request that the transaction be completed, processed online or offline. A simplified flow chart illustrating various embodiments of the preliminary transaction processing stage 42 is illustrated in Figure 4. The discovery processing step 44 follows the preliminary transaction processing stage 42. Once the card 22 is presented and is within the range of the reader 10, the reader 10 energizes the contactless interface 12 and establishes communication with the card 22 through the contactless interface 12 during the discovery processing step 44. If the reader 10 detects multiple contactless cards 22 within its range, the reader 10 may indicate this condition to a cardholder or cardholder and may request that only one card 22 be presented for the transaction. In addition, a reader 10 can abort a transaction during the discovery processing step 44 and de-energize the contactless interface 12 before a merchant command or after a period of time. pre-defined disconnection time. The application selection step 46 follows the discovery processing step 44. During the application selection step 46, the reader 10 transmits a first command message (eg SELECT PPSE) to the card 22. The first command message it can serve as a request for a list of application identifiers, application labels and application priority indicators, for applications supported by the card 22 and accessible through the non-contact interface 12. In response to the first command message the card 22 constructs this list and transmits the list to the reader 10. According to various modalities, the list can be provided within file control information (FCI = File Control Information) transmitted to the reader 10. The reader 10 then uses the list transmitted by the card 22 to build a list of applications common to reader 10 and card 22. After building the list of common applications In this case, the reader 10 transmits a second command message (for example SELECT AID) to the card. The second command message can serve as a request to perform the transaction using a specific application from the list of common applications. According to various modalities, the specific application may be the common application having the highest priority as indicated by the application priority indicators previously transmitted by card 22. In response to the second command message, card 22 transmits a request to the reader 10 to provide various details regarding the reader's capabilities 10 and specific transaction requirements of the reader 10. According to various modalities, the details requested may be provided in a list of terminal data objects (eg PDOL) associated with the reader 10. If the list of terminal data objects includes a particular data element (eg, terminal transaction qualifiers), the process proceeds to the application processing step 48. Otherwise, the reader 10 may terminate the transaction or attempt to process the transaction in another interface. A simplified flow chart illustrating various modalities of the selection step 46 is illustrated in Figure 5. During the application processing step 48, the reader 10 transmits a third command message (eg GPO) to the card 22, in response to the request of the card for details regarding reader capabilities 10 and specific transaction requirements of the reader 10. The third command message is structured in such a way that it can be used instead of three separate commands required by specifications previous By reducing the number of commands and responses required to complete the contactless transaction, the required interaction time between card 22 and reader 10 is minimized further. The third command message may comprise values for any number of data elements requested by the card 22. Various values of data elements indicate the type of transactions supported by the reader 10, whether offline processing and / or online is support or require by the reader 10, these cardholder verification methods are supported or required by the reader 10, etc. The data elements may comprise terminal transaction qualifiers, the transaction quantity, an unpredictable terminal number, a transaction currency code and any other data requested by the card 22 in its response to the second command message. Based on the type of transactions held by the reader 10, the card 22 then performs a number of risk management processes associated with a particular transaction type. According to various modalities, risk management processes may include verifying an internal card indicator to protect against transaction tearing, compare a value of an application currency code to a value of a transaction currency code, compare the number of entries of the personal identification number to a predetermined limit, determine whether a cardholder verification method is required, compare the transaction amount with a low value limit associated with the card 22, comparing the transaction amount with a cumulative total transaction amount associated with the card 22, comparing a value of a consecutive transaction counter with a consecutive transaction limit value , etc.

In performing the risk management processes described in this point in the transaction, as opposed to being performed at a later point according to traditional specifications, the interaction time between the card 22 and the reader 10 is further reduced to a minimum. Based on the risk management process, the card 22 can request that the transaction be completed, processed online or processed offline. Following the completion of the risk management processes, the card 22 constructs the appropriate response to the third command message and transmits the response to the reader 10. The information included in the response may vary depending on whether the card 22 wants the transaction is authorized online, authorized offline or completed. For example, when card 22 wants the transaction to be authorized online, the response may include an application transaction counter (ATC = Application Transaction Counter) indicating the number of transactions processed by the card, an application cryptogram generated by the card 22 using the application transaction counter and the terminal data (for example the unpredictable terminal number and the transaction quantity), including the third command message, an application exchange profile (AIP = Application Interchange Profile) ), which indicates support for risk management features, issuer application data and equivalent data from Track 2 and various other data elements. When the card 22 wants the transaction to be authorized offline, the response to the third command message may include an application transaction counter (ATC) indicating the number of transactions processed by the card. The response may also include a dynamic signature generated by the card 22 using the application transaction counter, terminal data (for example the unpredictable number of the terminal, the amount of the transaction and the currencies in which the transaction is carried out). ) included in the third command message and an unpredictable number of cards. The response may further include an application cryptogram generated by the card 22 using the application transaction counter and terminal data (e.g., unpredictable terminal number and transaction amount) included in the third command message. In addition, the response may include a pager Application file (AFL) that indicates the location of files and records related to application, an application exchange profile (AIP) that indicates support for risk management features, issuer application data, and various other data elements. According to various modalities, the card 22 can increase the application transaction counter before its calculation of the application cryptogram and the dynamic signature. If the size of the dynamic signature exceeds a predetermined threshold, the dynamic signature may be returned in the authorization stage 50 in response to a fourth command message described below. According to various modalities, the application cryptogram generated by the card 22 comprises fewer data elements than the application cryptogram used by previous specifications. By using less data elements to generate the application cryptogram, the total processing time is reduced and the interaction time between the card 22 and the reader 10 is further reduced. The authorization step 50 follows the processing step of application 48. After the reader 10 receives the response to the third command message from the card 22, the card 22 can be removed from the range or range of the reader 10 when the transaction is going to be authorized online. Therefore, card 22 is not required to remain within the range of the reactor as long as the authorization is requested online. By being able to remove card 22 in the transaction process, the interaction time between card 22 and reader 10 is further reduced to a minimum. The reader 10 can then send the application cryptogram, which is provided by the card 22 in response to the third command message, in line with the transmitter 30. With Based on a response that is subsequently received from the sender 30, the reader 10 approves or declines the transaction. When the transaction is to be authorized offline, the reader 10 transmits a fourth command message (for example READ RECORD) to the card 22, after receiving the response to the third command message from the card 22. The fourth message of The command can serve as a request for the records indicated in the application file locator (AFL) that is provided by the card 22, in response to the third command message. In response to the fourth command message, the card 22 transmits the appropriate registers to the reader 10. When the last record is received by the reader 10, the card 22 can be removed from the range of the reader 10. Therefore, the card 22 is not it requires that it remain within the range of reader 10 while it is offline authorization is made. By being able to remove card 22 at this point in the transaction process, the interaction time between card 22 and reader 10 is further reduced to a minimum. The reader 10 can then verify if the card 22 expired. If the reader 10 determines that the card 22 did not expire, the reader 10 can perform offline data authentication. The type of offline data authentication performed, static data authentication (SDA = Static Data Authentication) or dynamic data authentication (DDA = Data Authentication), is determined based on the application exchange profile (AIP = Application Interchange). Profile) that is provided by the card in response to the third command message. For static data authentication, reader 10 attempts to validate the static signature that is provided by card 22, in response to the third command message. Static data authentication involves validating important application data to ensure that the data has not been altered fraudulently. If the static signature is validated, the transaction is approved offline. Otherwise, the transaction can be sent online or terminated. For dynamic data authentication, the reader 10 attempts to validate the dynamic signature that is provided by the card 22, in response to the third command message. Dynamic data authentication involves validating important application data to ensure that the data has not been tampered with fraudulently and that the card 22 is genuine. According to various embodiments, dynamic signature validation may comprise employing the application transaction counter (ATC) and unpredictable terminal number, which is provided by the card 22 in response to the third command message to recalculate the dynamic signature. According to other modalities, the validation of the dynamic signature may comprise employing an unpredictable number of card received from the card to recalculate the dynamic signature. If the dynamic signature is validated, the reader 10 generates a release message that includes the cryptogram that is provided by the card 22, in response to the third command message and other related data. Otherwise, the transaction can be sent online or terminated. According to various modalities, if the dynamic signature is not validated, the reader 10 can send the transaction offline using the cryptogram previously received from the card 22. In this way, the reader 10 can generate an online request with a Offline cryptogram. A simplified flow chart illustrating various embodiments of the authorization stage 50 is illustrated in Figure 6.

As previously described, method 40 can be used to minimize the interaction time between card 22 and reader 10 for a non-contact transaction, less than about 500 milliseconds. To avoid an off-line sleeve or sleeve attack in the contactless transaction, various modalities of the method 40 may use a novel type of dynamic data authentication. For offline transactions, the card 22 can use the application transaction counter (ATC) and the unpredictable card number together with the unpredictable terminal number, the transaction amount and the currency code in which the application is made included in the third message of command (for example GPO) to create the dynamic signature. The application file locator (AFL) which is subsequently sent with the dynamic signature to the reader 10 in response to the third command message, points to or directs to records containing the RSA certificates and data related to dynamic data authentication. Therefore, during the authentication step 50, the reader 10 can read an issuer certificate, a contactless card certificate and data related to dynamic data authentication. According to various modalities, the reader 10 can use the application transaction counter (ATC), the unpredictable card number, the unpredictable terminal number, the transaction amount and the currency code in which the transaction is carried out. received from card 22, in response to the fourth command message to recalculate the dynamic signature for validation purpose. In cases where the contactless transaction has undergone a manga attack, the calculation again will not correspond to the dynamic signature previously received from card 22.

For these cases, reader 10 may decline or terminate the transaction without contact. Figure 7 illustrates various embodiments of a method 60 for reducing an interaction time for a second contactless transaction that occurs after the request for online authorization in step 50 of method 40. In accordance with various embodiments, method 60 may comprising a portion of the method 40. The method 60 can be implemented by the system 20 of Figure 2. The method 60 can be used to minimize the interaction time between the card 22 and the reader 10 for the second non-contact transaction to less than approximately 500 milliseconds. According to various modalities, method 60 comprises the general steps of second transaction request 62, application selection 64, request processing 66, and transaction approval 68. The second non-contact transaction is not a financial transaction. Since the second non-contact transaction comprises card 22 that is presented within the range of reader 10 for the second time, the process can be referred to as a card return process. Before the start of the process, during the first transaction previously described, both the reader 10 and the card 22 can indicate each other that they support card return processing. For example, reader 10 and card 22 can indicate their card return processing support during the application selection stage 46 of the first transaction. After the request for online authorization in steps 50 of method 40, either reader 10 by card 22 (by means of the cardholder) can request the second transaction without contact during the second stage of transaction request 62. According to various modalities, reader 10 can request the second transaction without contact during the second stage of transaction request 62 when an issuer responds to the Online authorization request comprises a message to be sent to card 22. This message can be used to provide updating or resetting of counter to card 22, or to block the account. For example, in an online authorization response, the sender 30 may include a script message in the response requesting the card 22 to be presented a second time. In this way, the sender 30 may be able to subsequently block the account, replenish offline spending capacity, increase the out-of-line spending limit, etc., even if the card 22 has not requested that these actions be taken. To advise the cardholder to present the card 22 a second time, the reader 10 may display a message indicating that additional card processing time is required, a message requesting that you please present the card again, etc. According to other modalities, the card 22 may request the second transaction in order to receive a recharge when the off-line spending capacity of the card becomes low. For example, when off-line card spending capacity is low, card 22 by the cardholder can request a top-up when requesting an online authorization and provide the amount of expense currently available. To ensure that the card 22 presented is the same card 22 that will be presented for the first transaction, the card 22 can be authenticated during the second transaction request step 62. The application selection step 64 follows the second transaction request step 62. The application selection step 64 of method 60 may be similar to the application selection step 46 of method 40 described previously. During the application selection stage 64, reader 10 transmits a command message (e.g., SELECT VSDC AID) to card 22. The command message can serve as the request to perform a second transaction using a specific application from the list of common applications previously constructed by the reader 10. In response to the command message, the card 22 transmits a PDOL to the reader 10. The PDOL may be similar to PDOL transmitted to the reader 10 during the application selection step 46 of the method 40 previously described. If PDOL includes a particular data element (for example terminal transaction qualifiers), the process proceeds to the request processing stage 66. The request processing step 66 follows the application selection step 64. The processing step of application 66 may be similar to the application processing step 48 of method 40 described previously, but it is different since financial transaction processing is not involved. During the application processing step 66, the reader 10 transmits another command message (eg GPO) to the card 22. Upon receipt of the command message, the card 22 constructs an appropriate response and transmits the response to the reader 10. transaction approval stage 68 follows the application processing stage 66. According to various modalities, if the sender 60 (30) decides to reload the offline spending capability associated with card 22, sender 30 can transmit a response cryptogram and approve the transaction or include a scripted message with a message authentication code (MAC = Message Authentication Code). The cryptogram or the MAC can serve to ensure that the updates, meter re-count, etc., are only made to cards 22 associated with the sender 30. As previously described, the method 60 could be used to change card risk parameters, card counters and card status, etc. For example, with respect to changing card risk parameters, method 60 can be used to increase the limit of offline spending, increase the simple transaction limit, allow the card to perform transactions in two or more currencies, change the rate of currency conversion used, etc. With respect to changing card counters, method 60 may be used for example to reset the amount of available offline expense, etc. With respect to changing the card state, the method 60 is used to block or unlock a particular application. A person skilled in the art will appreciate that the method 60 can be used to change its parameters, counters, etc. While various embodiments of the invention have been described herein by way of example, those skilled in the art will appreciate that various modifications and alterations to the described embodiments can be achieved without departing from the spirit and the case of the invention defined by the appended claims. For example, according to various modalities, the reader 10, system 20 and / or method 40 described previously they can be modified to avoid analogous types of "manga attacks" on micro cordless phones, USB fobs, and other devices, which use wireless transmission of information. Additionally, various modalities of the method 60 can be used to process transactions related to currency conversion, loyalty programs, etc.

Claims (29)

1. CLAIMS 1. A reader, characterized in that it comprises: a non-contact interface; and a transaction module coupled to the non-contact interface, wherein the transaction module is structured and arranged to process contactless transaction with less than half a second of interaction time between a card and the reader. The reader according to claim 1, characterized in that the transaction module is structured and arranged to perform static data authentication. The reader according to claim 1, characterized in that the transaction module is structured and arranged to perform dynamic data authentication. The reader according to claim 1, characterized in that the reader further comprises a security module coupled to the transaction module, wherein the security module is structured and arranged to prevent an intermediary attack on the transaction without contact. 5. A card, characterized in that it comprises: a structured transaction module arranged for wireless communication, wherein the card is structured and arranged to operate in a chip mode and a magnetic tape data mode. 6. The card according to claim 5, characterized in that the transaction module is further structured and arranged to cooperate with a reader to execute the transaction without contact, with less than half a second of interaction time between the card and the reader. 7. The card according to claim 6, characterized because the card further comprises a security module structured and arranged to cooperate with the reader, to avoid an intermediary attack in a non-contact transaction. 8. A system, characterized in that it comprises: a reader, comprising: a non-contact interface; and a transaction module coupled to the contactless interface; and a structured card arranged to communicate with the reader through the non-contact interface, wherein the transaction module is structured and arranged to process a non-contact transaction with less than half a second of interaction time between the card and the reader. The system according to claim 8, characterized in that the reader further comprises a security module coupled to the transaction module, wherein the security module is structured and arranged to avoid an intermediate attack in the transaction without contact. The system according to claim 8, characterized in that the card comprises a structured transaction module and arranged to cooperate with the reader, to execute the transaction without contact. The system according to claim 10, characterized in that the card further comprises a security module structured and arranged to cooperate with the reader to avoid an intermediary attack in a non-contact transaction. The system according to claim 8, characterized in that it also comprises a network coupled to the reader. 13. The system according to claim 12, characterized in that the network is also coupled to an emitter. 14. A method for reducing an interaction time for non-contact transaction, the method is characterized in that it comprises: in a reader, performing at least one transaction-based risk management process, before energizing a non-contact interface; initiate communication with a card used for the transaction without contact; receive information associated with the card; and end communication with the card before authorizing the transaction without contact. 15. The method according to claim 14, characterized in that the interaction time is between the card and the reader. 16. The method according to claim 14, characterized by performing the transaction-based risk process comprises comparing a transaction quantity with a predetermined value. 17. The method according to claim 14, characterized by receiving information associated with the card comprises receiving information associated with at least one application supported by the card. 18. The method according to claim 14, characterized by receiving information associated with the card comprises receiving at least one of the following: a cryptogram; and a dynamic signature. The method according to claim 14, characterized in that terminating communication with the card comprises terminating communication with the card before making an online authorization. 20. The method according to claim 14, characterized in that terminating communication with the card comprises terminating communication with the card before performing an off-line authorization. The method according to claim 14, characterized in that it also comprises completing the transaction without contact with less than half a second of interaction between the card and the reader. 22. The method according to claim 19, characterized in that it further comprises: receiving a request for a second transaction without contact; reestablish communication with the card; and completing the second transaction without contact with less than half a second of interaction between the card and the reader. 23. The method according to claim 22, characterized in that receiving the request comprises receiving a request for a non-financial transaction. 24. The method according to claim 22, characterized in that completing the second transaction comprises transmitting a message that changes at least one card risk parameter. 25. The method according to claim 22, characterized in that completing the second transaction comprises transmitting a message that changes at least one card counter. 26. The method according to claim 22, characterized in that completing the second transaction comprises transmitting a message that changes at least one card state. 27. A method to avoid an intermediary attack on a Non-contact transaction, the method is characterized in that it comprises: receiving a dynamic signature comprising an application transaction counter, an unpredictable number of terminal, a transaction quantity, a transaction currency code and an unpredictable card number; receive an unpredictable card number; recalculate the dynamic signature using the unpredictable card number; and authorize the transaction without contact offline if the dynamic signature is validated. 28. The method according to claim 27, characterized in that it further comprises: receiving a cryptogram comprising an application transaction counter, a transaction quantity and an unpredictable number of terminal; and request that the transaction be processed in line with the cryptogram, if the dynamic signature is not validated. 29. The method according to claim 27, characterized in that it also comprises completing the transaction without contact in less than a second of interaction between the card and the reader.