This patent application claims the benefit of U.S. provisional patent application No. 60/699,015 entitled "Ticketing Extended contact patent Device" filed on 13/7/2005. The disclosure of the aforementioned provisional patent application No. 60/699,015, including the complete appendix thereof, is expressly incorporated herein by reference in its entirety.
Detailed Description
Attention is now directed to FIG. 1, which depicts an exemplary embodiment of a system 100 along with various possible components of the system. System 100 may implement the inventive techniques and may include one or more different types of portable payment devices. For example, one such device may be a contact device, such as card 102. Card 102 may include an Integrated Circuit (IC) chip 104 having a processor portion 106 and a memory portion 108. A plurality of electrical contacts 110 may be provided for communication purposes. System 100 may also be designed to work with contactless devices, such as card 112, in addition to or in place of card 102. Card 112 may include an IC chip 114 having a processor portion 116 and a memory portion 118. An antenna 120 may be provided for contactless communication, for example using Radio Frequency (RF) electromagnetic waves. Oscillator(s) and/or additional appropriate circuitry for one or more of modulation, demodulation, down conversion, etc. may be provided. Note that cards 102, 112 illustrate a variety of devices that may be employed with the present technology. In one or more embodiments of the present disclosure, a dual interface device 1302 is employed. The device 1302 is shown larger than the devices 102, 112 for ease of illustration, although the device 1302 may have a similar form factor. Apparatus 1302 includes an IC chip 1304 having a processor portion 1306 and a memory portion 1308. A plurality of electrical contacts 1310, similar to contacts 110, and an antenna 1320, similar to antenna 120, may be provided, along with oscillator(s) and/or additional appropriate circuitry for one or more of modulation, demodulation, down conversion, etc. (as described with respect to device 112). Appropriate firmware to manage the two available interfaces may be provided, which otherwise operates similarly to the devices 102, 112. All descriptions of devices, elements or components 102, 104, 106, 108, 110, 112, 114, 116, 118, 120 in this document apply equally to the respective items 1302, 1304, 1306, 1308, 1310, 1320. The memories 108, 118, 148 (discussed below) and 1308 may be further divided into non-volatile memories and volatile memories.
The ICs 104, 114 may contain processing units 106, 116 and memory units 108, 118. Preferably, the ICs 104, 114 may also include one or more of control logic, timers, and input/output ports. Such elements are well known in the IC art and are not separately illustrated. One or both of the ICs 104, 114 may also include a coprocessor, which is also well known and not separately illustrated. The control logic may provide the control necessary to handle communications between the memory units 108, 118 and the input/output ports in conjunction with the processing units 106, 116. The timer may provide a timing reference signal based on the processing units 106, 116 and the control logic. The coprocessor may provide the ability to perform complex computations, such as those required by cryptographic algorithms, in real time.
The memory portions or units 108, 118 may comprise different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. The memory unit may store transaction card data, such as a user's primary account number ("PAN"). The memory portions or units 108, 118 may store the operating system of the cards 102, 112. The operating system loads and executes applications and provides file management or other basic card services to the applications. In some embodiments, one or more applications may be "sitting" directly on the hardware, such as may be outside the scope of the operating system. One operating system that may be used to implement the present invention is licensed by StepNexus corporationAnd (4) operating the system. Alternatively, a JAVA-based CARD may be employedTMTechnical in JAVA CARDTMA basic operating system (licensed by Sun Microsystems, 4150network circle, Santa Clara, CA 95054 USA) or proprietary operating systems available from many vendors. The operating system is preferably stored in read only memory ("ROM") within the memory portions 108, 118. In alternative embodiments, flash memory or other non-volatile and/or volatile types of memory may also be used in memory units 108, 118.
In addition to the basic services provided by the operating system, the memory portions 108, 118 may also include one or more applications as described herein. Currently, one preferred standard to which such applications may adhere is the EMV payment standard set forth by EMVCo, LLC (http://www.emvco.com). It will be appreciated that, strictly speaking, the EMV standard defines the behaviour of a terminal; however, the card may be configured to comply with such EMV compliant terminal behaviors, and in this sense, is itself EMV compliant. It will also be appreciated that applications in accordance with the present invention may be configured in a number of different ways.
As mentioned, cards 102, 112 are examples of the variety of payment devices that may be employed with the present technology. The primary function of the payment devices may not be payment, for example, they may be cellular telephone handsets or access cards for public transportation systems that implement the techniques of the present invention. Such devices may include cards having a conventional form factor, larger or smaller cards, cards having different shapes, small terminals (key fob) like key rings, Personal Digital Assistants (PDAs), suitably configured cell phone handsets, or even any device having processing and memory capabilities that implement the present techniques. The card or other payment device may include a memory 108, 118 and a processor 106, 116 coupled to the memory. Optionally, a body portion (e.g., a laminated plastic layer of a payment card, a housing or chassis of a PDA, a chip package, etc.) is associated with the memory 108, 118 and the processor 106, 116. The memory 108, 118 may contain applications as described herein. The processor 106, 116 is operable to perform one or more method steps that will be described herein. For example, the application may be an Application Identifier (AID) linked to software code in the form of firmware plus data in a card memory such as an Electrically Erasable Programmable Read Only Memory (EEPROM).
Many different types of terminals may be employed with system 100. Such terminals may include a contact terminal 122 configured to interface with the contact-type device 102, a wireless terminal 124 configured to interface with the wireless device 112, or a combination terminal 126. Note that "contactless" and "wireless" are used interchangeably herein, and the skilled artisan is familiar with the meaning of such terms. The combination terminal 126 is designed to interface with either type of device 102, 112. The terminal may be a contact terminal with a contactless reader inserted. The combination terminal 126 can include a memory 128, a processor portion 130, and a reader module 132. It is noted that the principles of construction of the terminal 126 are applicable to other types of terminals and are described in detail for illustrative purposes. The reader module 132 may be configured for contact communication with the card or device 102 or contactless communication with the card or device 112, or both (different types of readers may be provided to interact with different types of cards (e.g., contact or contactless)). The terminals 122, 124, 126 may be connected to a processing center 140 via a computer network 138. For example, the network 138 may include the Internet or a proprietary network. For example, processing center 140 may include a host computer of an issuer of a payment device. One or more distinct networks may be employed. As discussed below, the inventive terminal may have a payment module coupled to an electronic merchandise module; the modules may be implemented in software, firmware, and/or hardware. In one or more embodiments, the modules may be software modules running on the same processor.
The individual terminals 134 represent terminals that are not connected to the computer network (either not connected at a particular time, or not connected at all times, depending on the design), and are otherwise generally similar to the other terminals described.
A suitably configured cellular telephone handset 142 may also be employed in the system 100. The handset 142 is depicted in semi-schematic form in FIG. 1, and the handset 142 may include one or more IC chips, such as a chip 144 that includes a processing unit 146 and a memory unit 148. Wireless communication with the terminal may be provided via antenna 150 or with a second antenna 180 similar to antenna 120 described above (i.e., the handset may have a second antenna for payment applications). Note that antenna 180 is depicted schematically, but may be, for example, a coil antenna as used in typical "smart" cards. The handsets 142 may each be equipped with a suitable display 156. In addition, a suitable power source 162 may also be provided. Such a power source may include, for example, a battery and appropriate circuitry. The display and the power supply may be interconnected with the processor portion. Different types of portable payment devices may combine or "mix and match" one or more features depicted on the exemplary device in fig. 1.
In one aspect of the invention, an electronic payment device (which may be portable) is provided to facilitate a user's transaction with a terminal (e.g., 122, 124, 126, 134) of a system, such as system 100. The device may include a processor, such as the processing units 106, 116, 146 discussed above. The device may also include a memory, such as memory portions 108, 118, 148 discussed above, coupled to the processor. Further, the device may optionally include a communications module coupled to the processor and configured to interface with a terminal, such as one of terminals 122, 124, 126, 134. For example, the communications module may include contacts 110 or antennas 120, 150, 180 along with appropriate circuitry (such as the aforementioned oscillator(s) and related circuitry) that permits interfacing with the terminal via contact or wireless communications. The processor of the apparatus may be operable to perform one or more steps of the methods and techniques described herein. The processor may perform such operations via hardware techniques and/or under the influence of program instructions stored in one of the memory units. The portable device may include a body portion. This may be, for example, a laminated plastic body in the case of a "smart" card 102, 112 (as discussed above), or a handset chassis and body in the case of a handset 142.
It will be appreciated that terminals 122, 124, 126, 134 are examples of terminal equipment for interacting with a portable payment device in accordance with one or more exemplary embodiments of the present disclosure. The apparatus may include the aforementioned payment and electronic merchandise modules, implemented, for example, via a processor, such as processor 130, a memory, such as memory 128, coupled to the processor, and a communication module, such as 132, coupled to the processor and configured to interface with the portable apparatus 102, 112, 142. Processor 130 is operable to communicate with a user's portable payment device via communication module 132. The terminal device may function via hardware techniques in the processor 130 or by program instructions stored in the memory 128. Such logic may optionally be provided from a central location, such as processing center 140, via network 138.
The above-mentioned devices 102, 112 are preferably ISO 7816 compliant contact cards or devices or NFC (near field communication) or ISO 14443 compliant proximity cards or devices. In operation, card 112 may be tapped or tapped on terminals 124 or 128, which terminals 124 or 128 then transmit electronic data in a contactless manner to a proximate IC chip in card 112 or other wireless device.
FIG. 2 shows an exemplary application of the present techniques to a controlled access system, according to one aspect of the present invention. For example, the system 200 may be a transit vehicle, a complete transit infrastructure including one or more train stations or bus terminals, an amusement park, a museum, and the like. The system 200 may have an entry point 202 and an exit point 204. First terminal end 206 may be located adjacent to entry point 202 and second terminal end 208 may be located adjacent to exit point 204. It will be appreciated that there may be multiple entry and exit points, and each may be provided with an appropriate termination. A terminal, such as terminal 206, may be configured for integrated payment and electronic merchandise transfer via a payment infrastructure, in conjunction with an electronic merchandise infrastructure and in conjunction with an electronic payment device, such as device 210, configured according to the payment infrastructure. For example, the device 210 may be a contact card, contactless card, cell phone, or other device as described above.
The terminal 206 may include a payment module 212 configured according to a payment infrastructure and also configured to query the electronic payment device 210 to obtain financial data. Further, the terminal 206 may include an electronic merchandise module 214 configured according to an electronic merchandise infrastructure and coupled to the payment module 212. The electronic merchandise module 214 may be configured to facilitate processing of e-merchandise related information (e.g., ticketing information). The payment module 212 may be further configured to facilitate transfer of the e-merchandise related information to the electronic payment device 210 in a transaction conducted in accordance with the financial data and the payment infrastructure. Note that the payment module may include an antenna 216 for contactless communication (which may also include appropriate modulation and conversion circuitry, which is well known in the art and similar to that discussed above). Further, the payment module may include a reader 218 for a contact card. Note that the reader 218 and antenna 216 may be separate entities or may be integrated with the terminal 206 (e.g., its payment module 212) as desired. The payment module 212 and the electronic merchandise module 214 may have network connections 220, 222. It will be appreciated that a single network connection may be provided, if desired. The connection may reach any type of network described above with respect to fig. 1, and different modules may be connected to the same or different networks as desired. The elements 224, 226, 228, 230, 232, 236 of the terminal 208 may function similarly to the corresponding elements 212, 214, 216, 218, 220, 222 of the terminal 206.
In one or more embodiments, the payment module 212 itself need not be connected to a network, and network communication can be accomplished via the merchandise module 214. Additionally, in one or more embodiments, communications with the card or other payment device may be processed by the payment module 212, and any data that needs to be passed between the card and the merchandise module 214 is processed by the payment module 212 (for both contact and contactless cards).
By way of example, to aid the understanding of a skilled artisan, one example of a payment infrastructure is an EMV infrastructure (i.e., a payment system containing EMVs) operated by, for example, MasterCard International corporation in conjunction with an issuer, an acquirer, and a merchant. Additionally, one example of a payment infrastructure is an automatic charging (AFC) system.
Optionally, the payment module 212 may be further configured to interrogate the electronic payment device 210 to obtain profile data relating to a holder of the electronic payment device. In this case, the electronic merchandise module 214 of the first terminal 206 may be configured to process the e-merchandise related information based on the profile data. The processing of the e-merchandise related information may include generating, reading, and/or updating the e-merchandise related information. It will be appreciated that different types of e-merchandise modules 214 are possible. For example, there may be some modules that produce only e-merchandise, such as ticket vending machines; there may be some modules that read only e-merchandise, such as portable devices of train crews or other ticket checking personnel; and there may be some modules that update only e-merchandise, such as ticket validators. Additionally, there may be combination modules that perform some or all of the foregoing operations in any combination. It should be emphasized that many aspects of the present invention are illustrated with respect to a ticketing system (e.g., for transportation) by way of example. However, this is purely exemplary, and the techniques of the present invention may be used in many applications where integration of payment and e-merchandise infrastructure would be beneficial, such as controlling access to amusement parks, museums, and the like.
The described modules 212, 214, 224, 226 may include, for example, two physically separate devices, a single device containing two discrete sub-devices, a single device containing two discrete virtual devices (i.e., software modules), and a single fully integrated device that does both.
Attention is now directed to fig. 3, which presents a flowchart 300 of exemplary method steps in accordance with an aspect of the present invention. The method, which may be computer-implemented, may be used for integrated payment and electronic merchandise transfer via a payment infrastructure in conjunction with an electronic merchandise infrastructure. The e-merchandise may be of the kind described above. After beginning at block 302, block 304 includes facilitating querying, by the first terminal, the electronic payment device for financial data. For example, the financial data may be an account number of the electronic payment device. The electronic payment device may be configured according to a payment infrastructure, and the first terminal may have a payment module and an electronic merchandise module as described above with respect to fig. 2. The interrogation of the electronic payment device may be performed by the first terminal payment module. Optionally, in facilitating the inquiry step 304, profile data relating to the holder of the electronic payment device may be obtained. As used herein, "facilitating" an action includes performing the action, making the action easier, helping to perform the action, or causing the action to be performed. Thus, by way of example, and not limitation, instructions executing on one processor may facilitate actions carried out by instructions executing on a remote processor by sending appropriate data or commands to cause or assist in the performance of the actions.
As mentioned, the financial data may be, for example, an account number associated with the payment device. By way of example and not limitation, profile data may include information such as the fact that someone is a student or an elderly person who has the right to have a lower fare. Additionally, two or more categories of profile data may be provided. For example, one category may include ticketing profile data, such as the identity of an elderly person or student. Additionally, card member profile data may also be provided; such data may not be needed for the transaction. This may include, for example, when and where the card member joined, personal information such as garment size, etc. In the case of obtaining profile data, the e-merchandise related information may be generated by the first terminal electronic merchandise module based on the profile data.
Optional step 306 will be discussed below. Step 308 may include facilitating generation of e-merchandise related information by the first terminal electronic merchandise module. Such information may include, for example, ticketing information. Optional steps 310 through 316 will be discussed below. Step 318 may include facilitating transfer of the e-merchandise related information to the electronic payment device via the first terminal payment module within a transaction conducted in accordance with the financial data and the payment infrastructure. In one or more embodiments, the transaction may be a payment transaction. However, it should be appreciated that the transaction may be for a value of zero, and/or may be only a subset of the total payment transaction flow.
As mentioned, the profile data that may optionally be obtained in step 304 may include information identifying the holder of the electronic payment device as a member of a class having one or more of a plurality of rights classifications associated with class membership. The rights classification may relate to the electronic article; for example, such classifications may include rights to discounts or offers. As mentioned, in one exemplary embodiment, the entitlement category may comprise a traffic charge category and the e-merchandise related information may comprise traffic ticket information.
As mentioned, the present techniques may be used to control entry into and/or exit from a controlled access system. In some cases, only access to the system may be involved. This may be appropriate, for example, when a single flat fee is charged for access (e.g., to a museum or casino) or in a mass transit system (e.g., a new york subway system) where a single fee is charged for passage between any two stations. However, in other applications, it may also be desirable to control egress and/or link ticket or fee information to both entry and egress points. This may correspond to a system such as a london subway or a washington, dc, subway, for example. Thus, the steps described may be performed in connection with the entrance of the bearer into the controlled access system, and in this case, the e-merchandise related information in steps 308 and 318 may include initial entry point information. Thus, a first terminal (e.g., terminal 206 in fig. 2) may be considered an ingress terminal in this case. In this case, additional steps may include step 320, facilitating interrogation of the electronic payment device by the exit terminal when the bearer leaves the system to obtain system entry point information (the exit terminal has in fact "known" its own location, i.e., the system exit location). The egress terminal may be, for example, terminal 208 of fig. 2. Step 322 may include facilitating, via the egress terminal payment module, one or more of the following based on the controlled access system entry point information and the controlled access system egress point information (e.g., location of the egress terminal): providing tickets to the holder and charging the holder. It will be appreciated that the ticket provided in step 322 (or elsewhere herein) may be an electronic ticket, a physical ticket, an optical ticket, or the like.
In one or more embodiments, the inlet and outlet terminals 206, 208 may be different. For example, in a transit system (e.g., a subway system), the first or entrance terminal 206 may be located at a station where people have boarded a train, while the second or exit terminal 208 may be located at a station where people have departed the train. However, it is possible that the entry and exit terminals are actually the same terminal. This may occur, for example, on buses where the charge is dependent on the distance traveled. The egress terminal, which will be the same as the ingress terminal, may obtain information about the distance traveled through, for example, Global Positioning System (GPS) or other suitable techniques. The electronic payment device employed with the method depicted in fig. 3 may be, for example, a contactless Radio Frequency (RF) proximity card, a contact card, or a dual interface card having both contactless Radio Frequency (RF) and contact interfaces. Further, the device may have a non-card form factor, such as a cellular phone, PDA, small terminal like a key fob, etc.; all that is required is that there be an appropriate capability to interface with the terminals.
It will be appreciated that in one or more exemplary embodiments, it may be desirable to provide appropriate security features to minimize the likelihood of fraudulent or improper use. Specific examples will now be provided in the context of ticketing applications. When using open data storage for tickets, the card or other device may not provide any data storage related security services to the ticketing application. In this case, the ticketing application would need to address attacks such as skimming (i.e., copying the ticket onto another card) or replay. However, in other embodiments, the card or other device may provide appropriate security support. One way would be to employ a transaction counter (e.g., Application Transaction Counter (ATC)) in place data operations in conjunction with the place data (PutData) command to prevent the attack. Note that the examples are provided in the context of the aforementioned EMV specification. Those skilled in the art with access to the teachings presented in this application will be readily able to adapt the examples to other types of systems and standards.
More specifically, the reader (or reader portion of the terminal) may require an ATC and a main account number (PAN). The ticketing module may include the ATC and PAN in its calculated Message Authentication Code (MAC) and may use a put data command to return this to the card or other device. The put data command will refuse to accept storage of the data unless the PAN and ATC match their current values. This will prevent playback by the cardholder onto a legitimate card. Furthermore, using a PAN in conjunction with the Combined Data Authentication (CDA) feature present in EMVs may reduce or eliminate the possibility of "skimming" (i.e., someone attempting to read valid ticket data from another card and copy it onto its own card). Since the MAC includes a PAN, and the PAN is signed by the CDA, the payment module may detect the spoofing attempt and deny the transaction.
Referring to fig. 3, where it is desired to implement security techniques, optional step 306 may include facilitating interrogation of the electronic payment device by the first terminal to obtain a transaction counter and account number, such as the aforementioned ATC and PAN. Step 310 may include facilitating the calculation of an authentication code using a transaction counter and an account number; the code may be, for example, a MAC. Step 312 may include facilitating a determination of whether the transaction counter and account number obtained from the electronic payment device match the transaction counter and account number included in the authentication code. If they do not match (as indicated by the "no" branch of block 312), then a denial of storage of the authentication code by the electronic payment device may be facilitated, as shown at block 316. This rejection is in response to a determination step revealing that the transaction counter and account number obtained from the electronic payment device do not match the transaction counter and account number included in the authentication code. Implementing these steps may reduce the likelihood of replay spoofing. If the match is acceptable (as indicated by the "YES" branch of block 312), skimming detection may optionally be facilitated at decision block 314 based on an account number and unique data authentication signature (e.g., referred to as a combined DDA/AC generated EMV signature method, which is more commonly referred to as "CDA") associated with the transaction. Thus, the possibility of replay (attempting to copy the previous legitimate ticket gate data back onto the original card) and skimming (attempting to copy the legitimate ticket gate data onto another trusted or fraudulent card) can be significantly reduced or eliminated. It will be appreciated that the replay and skimming prevention steps may be performed in any order, and need not be performed together; one or both may be performed, or neither may be performed. In fact, in general, the steps depicted in fig. 3 may be performed in any suitable order, and not all steps need be performed in any particular case. Once a rejection has been generated in block 316, processing proceeds to continue block 324.
In another approach, illustrating a number of possible approaches to security enhancement, the steps may include facilitating interrogation of the electronic payment device by the first terminal to obtain a transaction counter (e.g., ATC), an electronic payment device identifier (e.g., card ID), and a random number generated by the electronic payment device (e.g., RND), and facilitating calculation of an authentication code (e.g., MAC) based on the e-merchandise related information, the transaction counter, the electronic payment device identifier, and the random number generated by the electronic payment device. These steps permit facilitation of detection of replay fraud via transaction counters and payment device generated random numbers, as well as facilitation of skimming detection based on linking e-merchandise related information with electronic payment device identifiers. More details will be provided below with respect to fig. 7 and 8.
Retrospectively, one or more embodiments of the present disclosure may provide techniques for combining payment and e-merchandise infrastructure and/or transactions while allowing each to focus on their primary functions and with little or no need for one to know about or include the other. Accordingly, in one or more aspects, the present invention may provide techniques for incorporating data processing operations into transactions, such as payment transactions. In one particular exemplary implementation, the payment transaction employs the aforementioned EMV standard.
Thus, the present technology permits processing of non-payment data within a transaction, such as a payment transaction. In one or more exemplary embodiments, data processing may be performed within such transactions. As discussed with respect to fig. 2, the terminal may include an e-merchandise and payment module; these modules may be implemented as separate hardware modules or as separate software modules. In one or more embodiments, two separate applications are provided, one for e-merchandise such as ticketing and one for payment. The device (e.g., card) need only "know" how to interface with the payment portion. The e-merchandise data (e.g., ticketing) may be communicated to the card or other device through a payment application or other type of payment module. Appropriate ticketing or other e-merchandise data may be stored on the card or other device (but using the payment infrastructure pre-existing on the card). In one or more embodiments, the existing payment infrastructure may be in accordance with the aforementioned EMV specification. Standard EMV commands may be used for mobile non-payment data, such as e-merchandise data. However, the card or other payment device may be made downward compatible so that it can be readily used for ordinary purchase transactions. A further specific example showing the application of the present techniques within the framework of an EMV will now be presented with respect to fig. 4-6.
In the following discussion of fig. 4-8, a "reader" includes elements such as payment module 212 with elements 216 and/or 218, while a "terminal" includes elements such as e-merchandise module 214. Fig. 4 shows exemplary method steps in a transaction flow at an entrance to a controlled access system where payment is to be made. The steps are described in the context of the aforementioned EMV standard, with appropriate modifications to implement the present techniques. The techniques are applicable to both contactless and contact applications. As shown in step 402 of flowchart 400, an activation request may be sent from the ticketing application to the payment application. An appropriate card polling and activation sequence may be carried out at step 404. If there is an invalid card or cards (as determined at step 406), a card deactivation sequence may be run at step 408, and a "NAK" symbol may be sent from the reader to the terminal at block 410 (corresponding to the reader informing the terminal that some error occurred).
Only if there is a single card, the reader selects an embodiment application and selects the appropriate application on the card at block 412. The data is then read from the card, as at block 414. Such data may include profile information such as a ticket profile and a balance. When multiple cards are present (as in the "no" leg), the reader will initiate a removal sequence, as at 408.
In step 416, the appropriate application is initiated. In step 418, the reader may read all data from the card or other device, but may simply retrieve the PAN from the response message, leaving the other data for later use. In the example shown in FIG. 4, the application data and ONESMARTApplications (also known as PAYPASS)Promulgated by MasterCard International Incorporated). However, this is purely for purposes of example, and other suitable specifications may be adhered to or adopted. In parallel, at step 420, the reader machine may send the ticket profile and balance as part of the activate entry response due to two successful get data (GetData) commands. At step 422, the reader may receive the debit entry command and the analyzed data from the terminal in preparation for future performance of the first generate AC command. In parallel, in step 418, the appropriate data is Read from the card or other device via a Read Record (Read Record) command. Typically, in an optimization procedure, the terminal will send a Debit Entry (Debit Entry) command before the reader is ready to send the first generate ac (generateac) command. In block 424, the reader requests a Transaction Certificate (TC). In block 426, the reader sends a debit entry response to the terminal, including the clearing record.
In block 428, a determination is made as to whether the card or other device has generated an application authentication password (AAC) or an authorization request password (ARQC). If so, the reader rejects the transaction without further processing, as shown at block 410. Conversely, following the NO branch at block 428, a determination is made as to whether combined DDA/AC generation is requested. Note that "DDA" represents dynamic data authentication, "AC" represents an application password, and the two are combined into a "CDA" representing a "combined DDA/AC". If such generation is requested, at block 434, the reader retrieves the public key of the electronic payment device (e.g., Integrated Circuit Card (ICC)) and verifies the Signed Dynamic Application Data (SDAD). At block 436, if the SDAD is correct, processing flows to block 438, and if the SDAD is incorrect, the reader rejects the transaction, as per block 410. In the "no" branch of block 430, static data authentication is performed by the reader at block 432. If the static data discrimination fails, the reader will set the appropriate bit in the TVR. Note that "TVR" represents the terminal verification result, which is a set of flags generated by the terminal that contain the result of the terminal risk management decision. It passes this to the card in "generate AC". In blocks 438 and 440, the reader performs appropriate processing constraints and terminal risk management. Likewise, if one or more tests fail, the appropriate bit in the TVR is set.
In block 442, the reader performs a terminal action analysis. If the result is a TC request (as determined in block 444), then the reader accepts the transaction; conversely, at the "no" branch of block 444, the transaction is denied, as at block 410. In block 448, the reader sends a debit entry response to the terminal, including the clearing record. The reader may send a debit entry response to the terminal containing an output from the first generated AC response; in the event that the card or other device does not respond to the generation of an AC command, appropriate exception handling may be implemented by the reader. It will be appreciated that blocks 406, 418, 424, 428, 430, 436, 438, 440, 442, and 446 may correspond to actions taken at the application level. Additionally, blocks 402, 410, 420, 422, and 448 may correspond to actions taken at the transfer or e-merchandise level. The steps in fig. 4 may be carried out in connection with a terminal-reader interaction.
Generally, in a normal EMV transaction flow, the correct application is selected on the card or other device, data is read from the card or other device, a terminal risk analysis and a terminal action analysis are performed, the card is queried for a password of the type determined by the above analysis, and the card then performs its risk analysis and responds to the terminal in an appropriate manner. In the modified transaction flow set forth herein, when data is read from the card, ticket or e-merchandise related data may also be read and supplied to the ticket or other e-merchandise terminal as appropriate. Such data may be read by a normal EMV read record command or by one or more get data commands. When the card or other device is queried for a password, the card is told of the particular data item in the format requested by the card. The card request will typically include a ticket label so that if a ticket is present, it is passed to the card when a password is requested (simply pass a zero to the card if the ticket is not to be reviewed). The card records the data in an extension to the normal transaction log. It is also possible to write to the data store before or after the password request, as appropriate. This may be done with a put data command, but in a variation on a normal EMV, it may be done without any security, just as an open data store would work. Two options have been discussed above. If an entry is to be recorded only in an area, as the case may be, then no password request is required after the data is placed.
When an appropriate application is selected, the terminal may execute a get process select (getprocessoptions) command. This command tells the terminal some basic facts about the card and transaction, and also provides parameters for determining which terminal file records need to be read (in one or more embodiments, such parameters may be, for example, an application file locator or "AFL" parameter from the EMV specification). The latter record is a list of data items to be read for a given transaction. The record may then be read using a read record command. Other data items, such as an offline balance, may be read with the get data command.
Typically, the put data command is processed as part of a "script," i.e., a sequence of encrypted secure commands with a MAC. Both this type of placement data and types of placement data without a MAC may be supported in one or more card applications configured in accordance with the present technology. A number of data stores for storing tickets may be defined. Half of these data stores may be open and half may be secure (i.e., free reading, writing is script limited). Again, these details are exemplary in nature and other variations are possible.
One of the data items read in the terminal file record is referred to as CDOL 1. This data item tells the terminal the list of labels, items such as numbers, currency, etc., to be supplied in the password request. An additional label for the ticket or other e-merchandise may be added to this so that the terminal provides the ticket or other e-merchandise in the password request. The basic rule according to the EMV standard is to fill in zeros if the tag is not understood. This feature may be employed to ensure that non-ticketing or non-e-merchandise terminals will not reject cards or other devices employing the inventive techniques.
The password may be requested by means of a "generate AC" command. This password is typically understood only by the issuer, but the card or other device may use RSA to digitally sign it. RAS is a well-known algorithm for public key encryption, which can also be used for digital signatures. The terminal can check this when obtaining the key it needs from the terminal file record.
Attention is now directed to FIG. 5, which depicts an exemplary reader transaction flow for storing tickets or other e-merchandise. At block 502, the reader receives a get CARD id (get CARD id) command and begins polling the CARD in the field (in the case of a contactless CARD), as at block 504. At block 506, if a single card is present in the field, the reader moves the application selection at block 512. If there are multiple cards, the reader initiates a removal sequence, as at blocks 508 and 510. At block 516, the reader reads the first record from the terminal file record. This record contains the PAN, application expiration date, and (optionally) PAN serial number. Although the described configuration may provide speed advantages, the PAN may be located in any other recording as desired. The skilled person is familiar with the EMV specifications for variants mentioned throughout. At block 518, the reader analyzes the record one and retrieves the PAN, application expiration date, and PAN serial number. If the PAN serial number is not included in the record, then the reader uses a value of "00".
At block 520, the reader sends the PAN, PAN serial number, and application expiration date as an acquire card ID response. At block 522, the reader receives the store ticket command and analyzes the data as a preparation for the put data command. A placement data command for a ticket or other e-merchandise is shown in block 524. The reader sends a ticket or other e-merchandise to the card with a put data command (without using secure messaging). At block 526, a card deactivation sequence occurs, while at block 528, the reader informs the terminal that everything is proceeding properly. Block 510 "send NAK" corresponds to the reader informing the terminal that some error has occurred.
It will be appreciated that blocks 506, 516, 518, and 524 may correspond to activities at the application level. Blocks 504 and 526 may correspond to activities at the transport level. Blocks 502, 510, 520, 522, and 528 may correspond to terminal-reader interactions.
Fig. 6 shows a flow chart 600 of exemplary method steps in a transaction flow at an egress of a controlled system, such as a transportation system, for making a payment at the egress. At block 602, the reader receives an ACTIVATE EXIT (ACTIVATE EXIT) command and begins polling the card in the field, as at block 604. If an activate away command has not been received, monitoring continues as indicated at the "No" branch of block 602. A card polling and activation sequence is depicted at block 604. At block 606, a determination is made whether a single card exists in the field; if so, the reader moves the application selection, as at block 612. Conversely, if there are multiple cards, the reader initiates a removal sequence, as at block 608, and performs a "send NAK" block 610; the reader sends a debit response to the terminal containing the status byte from the first generated AC response, as further described herein. Following application selection at block 612, the ticket, ticket profile, and balance may be read at block 614, and the appropriate application initiated at block 616. At block 618, the reader reads record one of SFI 2 to retrieve the PAN, PAN serial number, and application expiration date. At block 624, the reader reads the other records to retrieve all the required application data. In parallel, as shown at block 620, the reader sends the ticket, ticket profile, balance, PAN serial number, and application expiration date as part of an activate away response. At the same time, the reader is reading other card data via a read record command, as at block 624.
At block 622, the reader receives a Debit Exit (Debit Exit) command and analyzes the data as preparation for the first future generate AC command. Also, in parallel, as at block 624, the reader maintains read card data via a read record command. Typically, the terminal has sent the debit leave command before the reader will send the first generate AC command. The data analyzed in block 622 may include the number and transaction date and/or time stamp. In block 626, the reader sends a put data (PutData) command to remove the ticket from the card, and in block 628, the reader requests a transaction certificate. A card deactivation sequence occurs in block 630. In block 632, it is determined whether the card produces AAC or ARQC; if so (e.g., at the "yes" branch), the reader rejects the transaction without further processing. If not (as at the "no" branch), then a determination is made in block 634 whether combined DDA/AC generation is requested. If so, the reader retrieves the ICC public key and verifies the signed dynamic application data at block 636. If the signed dynamic application data is not correct (as determined at block 638), the transaction is denied, while if the SDAD is correct, processing continues at block 642. If the decision in block 634 is negative, then static data authentication is performed by the reader at block 640. If the static data discrimination fails, the reader will set the appropriate bit in the TVR. In blocks 642 and 644, the reader performs processing limits and terminal risk management to set the appropriate bit in the TVR if one or more tests fail. In block 646, the reader performs a terminal action analysis. If the result is a TC request (as determined in block 648), then the reader accepts the transaction according to the YES branch. In the case of the "no" answer, the transaction is denied. In block 650, for the clearing record, the reader should use the TVR sent to the card instead of the TVR used to collect the terminal risk management results. In block 652, the reader sends a debit departure response to the terminal, including the clearing record.
It will be appreciated that the method depicted in fig. 6 is a modification of the standard EMV program, with the addition of, for example, steps 620 and 622. It will be further appreciated that blocks 606, 614, 618, 624, 626, 628, 632, 634, 638, 640, 642, 644, 646 and 650 may correspond to actions at the application level. Additionally, blocks 604, 608, and 630 may correspond to actions at the transport level. Finally, blocks 602, 610, 620, 622, and 652 may correspond to terminal-reader interactions.
Fig. 7 shows how e-merchandise is written to a payment device (referred to as a "card") as part of a payment transaction. With reference to fig. 7 and 8, the skilled artisan will appreciate the importance of the deformable forms from the context, and will also appreciate that different deformable form names may be selected. The terminal, reader and card go through the following steps. In step 701, the terminal generates a random number UN*. Terminal using one-way function (OWF) according to random number UN*Computational challenge H*. At this stage, only the terminal knows the UN*And if H is known*If so, it is difficult to calculate UN*. At 702, the terminal sends an ACTIVATE (ACTIVATE) command to the reader to initiate an application. The terminal comprises a tag of the data element that the reader should return in the activation response message. This includes (for example)) RND tag, ATC tag, card ID tag, and customer profile tag. The terminal also comprises an H indicating to the reader that the interaction with the card must be completed with a COMMIT (COMMIT) command*。
In step 703, the reader begins polling the card. If a card is found, the reader activates the card. In step 704, the reader selects the appropriate application and initiates the application. In step 705, the reader sends H to the card*And receives the RND and the ATC. Card will RND and H*Stored in volatile memory for later use during DEBIT (DEBIT) and COMMIT (COMMIT) commands. H*Indicates to the card that the non-volatile memory must be updated with a commit command. In step 706, the reader retrieves the customer profile and card ID from the card.
In step 707, the reader sends the data object requested in step 702 to the terminal in an activation response message. This includes the RND, ATC, card ID and customer profile. At step 708, the terminal determines a number based on the customer profile; and at step 709, MAC is calculated through data of goods, RND, ATC and card ID. The goods are linked to the card ID in this way and therefore cannot be used for another (real) card. It cannot be replayed to the same card, since it also includes the RND and the ATC. The terminal stores the goods in a goods (MERCHANDISE) envelope and populates the RND and ATC with the hexadecimal number "F". In step 710, the terminal generates a receipt.
At step 711, the terminal sends the goods envelope to the reader along with the payment related data and receipt as part of a debit write (debitrotate) command. At step 712, the reader sends the merchandise envelope to the card along with the payment related data and receipt as part of the debit command. At step 713, the card performs its card risk management and generates proof of payment. The card keeps any updates (including merchandise and receipts) in volatile memory until the UN is presented*As part of the submit command. At step 714, the reader sends the UN to the card*As part of the commit command. Upon receipt of the submit command, the card verification proceeds in block 715To obtain a challenge*(GET CHALLENGE*) A portion of received H*Whether or not to interact with OWF (UN)*) The same is true. If so, the card updates its non-volatile memory. It stores the goods in the goods container along with the RND and ATC and stores the receipt in the receipt container. The card also updates payment related parameters in the non-volatile memory.
In block 716, the reader authenticates the card. The card authentication guarantees to the reader that the card linked to the card ID is a genuine card. In block 717, the reader communicates the proof of payment to the terminal.
FIG. 8 shows how an e-good is read, checked for integrity and authenticity, and then replaced with an update for the good. If the original item is a multi-note pack (e.g., london subway customs clearance), the updated item will contain one less note than the original item. If the original item is a single ticket, the update invalidates the ticket. The terminal goes through the following steps. At step 801, the terminal sends an activate command to the reader to initiate an application. The terminal comprises a tag of the data element that the reader has to return in the activation response message. The terminal does not send H to the reader*. This indicates to the reader that the transaction does not have to be completed with a submit command.
At block 802, the reader begins polling the card. If a card is found, the reader activates the card. In step 803, the reader selects the appropriate application. And initiating the application. In step 804, the reader sends an acquisition challenge*A command, and receives the RND and the ATC. The card stores the RND in volatile memory for later use during debit commands. The card does not receive H from the reader*. This indicates to the card that a commit command will not be sent and that the non-volatile memory must be updated with a debit command.
In step 805, the reader retrieves the envelope of the item currently stored in the card. The goods envelope contains goods ', RND ' and ATC '. In step 806, the reader retrieves the card ID from the card. In step 807, the reader sends the card ID, RND, ATC, and the goods envelope to the terminal in an activation response message. In block 808, the terminal checks if goods ' have been calculated by RND ' and ATC ' for a particular card ID. If so, then in block 809 the terminal calculates a new good with the same card ID, but uses the new RND and ATC. The terminal stores the goods in the goods envelope and populates the RND and ATC with the hexadecimal number "F". In block 810, the terminal generates a receipt.
In step 811, the terminal sends the new envelope of merchandise to the reader along with the receipt as part of the debit write command. The debit write command may be directed to a zero number so that there is no financial impact on the card. In step 812, the reader sends a new envelope of merchandise to the card along with a receipt as part of the debit command. In block 813, the card stores the goods in a goods container along with the RND and ATC and stores a receipt in a receipt container.
In steps 814, 815 and 816, the reader authenticates the card (card authentication ensures to the reader that the card linked to the card ID is a real card) and the reader passes the proof of payment (for zero number) to the terminal.
It will be appreciated that prior art systems, in general, rely on paymentRear endThe goods are delivered. Enabling payment to occur by one or more inventive techniquesFront sideData storage trust models for delivery goods. Within this data storage concept, the availability of goods is free, but the use ("consumption") is limited. Unlike physical goods, the "manufacturing" bits and bytes do not cost any cost. The risk of providing e-merchandise is taken as long as it is ensured that payment is received before the e-merchandise is consumed. Thus, the data storage trust model is believed to be particularly suitable for e-merchandise. A merchant may use this trust model if, for example, it may rely on additional card functionality (e.g., trust the issuer); the card application should provide protection against cloning and reuse of goods. Thus, integrating payment with on-card data storage (e.g., ticketing or other e-merchandise) enables a new trust model, and one or more inventive techniques may use quick and simple transactionsEasy flow to implement on-card data storage.
Recall that in the traditional card payment trust model, the merchant trusts an acquirer for the payment. The merchant provides the goods to the customer after receiving a simple "OK" from the acquirer. The merchant knows that the acquirer will honor this "OK" and pay the merchant as part of the settlement process. In the extended model, merchants also rely on additional functionality in the terminal and card to control the distribution and use of e-merchandise. Thus, the merchant needs to trust both the acquirer and the issuer to manage the goods.
Fig. 9 illustrates a conventional trust model. In this model, there is a clear separation of responsibilities:
the merchant is responsible for the vending machine 902.
The acquirer is responsible (pays) for the terminal 904.
Merchants and acquirers have a trust-based (business) relationship: if the acquirer confirms (via the terminal) that the transaction is successful to the merchant (i.e., to the vending machine), the goods are delivered 908. The acquiring bank protects the merchant from the complexity of the card interaction; there is no direct relationship between the merchant and the issuer of card 906.
The extended trust model works well when the goods are in electronic format. In this case, the e-merchandise grants access to services (traffic, music, etc.), otherwise referred to as "usage". It is typically the case that a customer purchases a ticket (e-merchandise) at a vending machine and then places the ticket into a swing door to open the door (use). If an e-ticket is involved, a data carrier is required to hold the data. One option for such data carriers is a payment card for purchasing tickets. Because the card is the carrier of the ticket, the card will be involved in use. This additional involvement of the card requires that extensions to the trust model include both acquirers and issuers. FIG. 10 illustrates a proposed trust model for purchasing e-tickets at a vending machine; fig. 11 illustrates a proposed trust model at a door.
Unlike fig. 9, the vending machine 1002 in fig. 10 provides goods (e-merchandise) 1008 to the terminal 1004 before payment confirmation. This requires an additional level of trust from the merchant. Merchants rely on acquirers to implement transaction flows that prevent access to merchandise without payment. This additional level of trust from the merchant is acceptable because it relates to e-merchandise (binary data). e-merchandise has no value other than the service it is permitted to access. Without payment, the merchant will not incur any financial loss as long as the customer cannot use the goods. The issuer of card 1006 is as depicted in figure 9.
As seen in fig. 11, when a customer exchanges services such as rail transport 1112 with e-merchandise 1108, door 1110 "talks" directly to card 1106. The acquirer and the terminal are not in the loop because there is no payment to settle. Merchants rely on additional card functionality as a safeguard against counterfeit goods. Therefore, a trust relationship must exist between the merchant and the issuer.
Counterfeit goods include:
1. data created from counterfeit similar to or identical to real goods
2. Cloning of authentic goods
3. And (4) replaying real goods.
Merchants have had a way to detect counterfeit goods at doors. Which relies on card functionality to prevent cloning and playback. Thus, within the extended trust model, merchants rely on issuers to control the use of e-merchandise and provide countermeasures against cloning and replay.
In general, in order for the extended trust model to work, the data storage should prevent:
1. using unpaid goods (extended responsibility for acquiring bank)
2. Cloning goods (extended responsibility of issuer)
3. Repeatedly used goods (extended responsibility of card issuer)
It remains the responsibility of the merchant to prevent counterfeit goods.
The utility of having ordinary data storage functionality on cards and terminals will now be described in the context of an extended trust model. In one or more inventive embodiments, the protection mechanisms just described may be implemented in the following manner
Via a generic (payment) terminal
Via a generic (payment) card
Not requesting a merchant-controlled key in the card or terminal
The use of common means allows:
the issuer provides such a payment card
Omicron can be used for ticket checking, loyalty and the like
O need not be prearranged between issuer and merchant
There is no need to know the specific requirements of the merchant.
An acquirer bank provides such a terminal
Omicron can be used for ticket checking, loyalty and the like
There is no need to know the specific requirements of the merchant.
Merchant uses a common payment card and terminal
As a carrier for its specific data storage applications
There is no need to know the payment application.
More details will now be given regarding the functionality provided by the generic data store. To achieve full benefit, the data storage function in the card (and terminal) should fulfill all merchant-specific requirements. In one or more embodiments, the expected range of functionality may be as set forth in the following table:
| functionality | Means of |
| 1. Retrieving different customer profiles | From the merchant's perspective, the customer profile contains information about the customer. The merchant may use the customer profile for-allowing access to a particular service-determining the number of transactions since the customer profile is merchant specific, a single customer may have different profiles for different merchants in the same card. |
| 2. Managing single tickets, booklets ("customs clearance cards"), and subscriptions. | The single ticket provides a single access to the service. After use, the merchant disables the ticket so that the customer cannot use the ticket again. A booklet is a collection of single notes. Booklets are therefore a particular type of item that is used step by step (e.g., one ticket at a time). Subscriptions provide longer access to services. The expiration date of the reservation is defined by the merchant (one day, one week, one month, etc.). |
| 3. A receipt is managed. | The receipt is a proof provided to the customer when using the goods exchange service. Which allows the customer to prove that he/she is entitled to use the service (e.g. sitting in a train). Note that: a receipt may not be necessary for the reservation. |
The present invention may employ hardware and/or software aspects. Software includes, but is not limited to, firmware, resident software, microcode, etc. For example, software may be employed in connection with terminals 122, 124, 126, 134, 206, 208. For example, firmware may be employed in connection with payment devices such as cards 102, 112, 1302. FIG. 9 is a block diagram of a system 900 that may implement a portion or all of one or more aspects or processes of the present disclosure. As shown in fig. 12, the memory 1230 configures the processor 1220 (which may correspond to, for example, the processor portions 106, 116) to implement one or more aspects of the methods, steps, and functions disclosed herein (shown generally as process 1280 in fig. 12). The memory 1230 may be distributed or local and the processor 1220 may be distributed or singular. The memory 1230 may be implemented as electronic, magnetic, or optical memory, or any combination of these or other types of storage devices, including the memory portions described above with respect to the cards 102, 112. It should be noted that if distributed processors are employed, each distributed processor that makes up processor 1220 typically contains its own addressable memory space. It should also be noted that some or all of computer system 1200 may be incorporated into an application-specific or general-purpose integrated circuit. For example, one or more method steps may be implemented in hardware rather than using firmware in an ASIC. Display 1240 represents a variety of possible input/output devices.
System and article details
As known in the art, a portion or all of one or more aspects of the methods and apparatus discussed herein may be allocated as an article of manufacture that itself comprises a computer-readable medium having computer-readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, EEPROMs, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic medium or height variations on the surface of a compact disc.
The computer systems and servers described herein each contain a memory that will configure the associated processor to implement the methods, steps, and functions disclosed herein. Such methods, steps, and functions may be carried out, for example, by processing capabilities on elements 102, 112, 142, 122, 124, 126, 134, 140, 206, 208, or by any combination of the foregoing. The memories may be distributed or local and the processors may be distributed or singular. The memories may be implemented as electronic, magnetic or optical memory, or any combination of these or other types of storage devices. Furthermore, the term "memory" should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. By this definition, information on a network is still within memory because the associated processor may retrieve the information from the network.
Thus, elements of one or more embodiments of the present invention (e.g., the aforementioned terminals 122, 124, 126, 134, 206, 208 or payment devices such as cards 102, 112, 1302) may utilize computer technology and appropriate instructions to implement the method steps described herein. By way of another example, terminal equipment 122, 124, 126, 134, 206, 208 may include a communication module, an antenna coupled to the communication module, a memory, and at least one processor coupled to the memory and the communication module and operable to interrogate a contactless payment device (instead of the antenna and communication module, appropriate contacts and other elements may be provided to interrogate a contact payment device such as a contact card).
It will thus be appreciated that one or more embodiments of the invention may comprise a computer program comprising computer program code means adapted to perform one or all of the steps of any method or claim set out herein when such program is run on a computer, and such program may be embodied on a computer readable medium. Additionally, one or more embodiments of the present invention can include a computer including code adapted to cause the computer to carry out one or more steps of a method or claim set forth herein, as well as one or more apparatus elements or features as depicted and described herein.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope or spirit of the invention.