CA2573795A1 - Collision detection and avoidance scheme for contactless card payment systems - Google Patents
Collision detection and avoidance scheme for contactless card payment systems Download PDFInfo
- Publication number
- CA2573795A1 CA2573795A1 CA002573795A CA2573795A CA2573795A1 CA 2573795 A1 CA2573795 A1 CA 2573795A1 CA 002573795 A CA002573795 A CA 002573795A CA 2573795 A CA2573795 A CA 2573795A CA 2573795 A1 CA2573795 A1 CA 2573795A1
- Authority
- CA
- Canada
- Prior art keywords
- card
- type
- cards
- card reader
- collision detection
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 57
- 238000000034 method Methods 0.000 claims abstract description 67
- 230000008569 process Effects 0.000 claims abstract description 49
- 230000004044 response Effects 0.000 claims abstract description 39
- 238000012545 processing Methods 0.000 claims description 26
- 238000004891 communication Methods 0.000 claims description 21
- 238000010845 search algorithm Methods 0.000 claims description 2
- 230000003213 activating effect Effects 0.000 claims 1
- 230000005540 biological transmission Effects 0.000 description 23
- 238000012360 testing method Methods 0.000 description 12
- 238000005516 engineering process Methods 0.000 description 11
- 230000008878 coupling Effects 0.000 description 6
- 238000010168 coupling process Methods 0.000 description 6
- 238000005859 coupling reaction Methods 0.000 description 6
- 230000004913 activation Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 2
- 230000005672 electromagnetic field Effects 0.000 description 2
- 230000002708 enhancing effect Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 239000000523 sample Substances 0.000 description 2
- 238000010998 test method Methods 0.000 description 2
- 230000002747 voluntary effect Effects 0.000 description 2
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000001939 inductive effect Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/302—Contactless testing
- G01R31/308—Contactless testing using non-ionising electromagnetic radiation, e.g. optical radiation
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/302—Contactless testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K17/00—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/0008—General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/0095—Testing the sensing arrangement, e.g. testing if a magnetic card reader, bar code reader, RFID interrogator or smart card reader functions properly
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10019—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves resolving collision on the communication channels between simultaneously or concurrently interrogated record carriers.
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10316—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves using at least one antenna particularly designed for interrogating the wireless record carriers
- G06K7/10336—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves using at least one antenna particularly designed for interrogating the wireless record carriers the antenna being of the near field type, inductive coil
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10366—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves the interrogation device being adapted for miscellaneous applications
- G06K7/10465—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves the interrogation device being adapted for miscellaneous applications the interrogation device being capable of self-diagnosis, e.g. in addition to or as part of the actual interrogation process
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/0806—Details of the card
- G07F7/0833—Card having specific functional components
- G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- H04B5/48—
Abstract
An electronic payment system for conducting transactions by presenting a contactless payment card to a card reader. The card reader is configured to process transactions when only one card is present in its operating field, The card reader uses collision detection and avoidance algorithms (302-309) to detect and report (309) instances where multiple cards are present in the operating field. In response to a reported collision, the collision may be cleared by manual intervention, i.e., by physically removing excess cards from the reader's operating field.
Description
COLLISION DETECTION AND AVOIDANCE SCHEME FOR
CONTACTLESS CARD PAYMENT SYSTEMS
SPECIFICATION
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of United States provisional patent application No. 60/588,270 filed on July 15, 2004. This application is also related to United States patent applications S/N , and S/N , S/N , and S/N
, co-filed on even date, all of which claim the benefit of the aforementioned patent application No. 60/588,270. All of the aforementioned patent applications are hereby incorporated by reference herein in their entireties BACKGROUND OF THE INVENTION
Radio Frequency Identification (RFID) tags are small integrated circuits (ICs) connected to an antenna, which can respond to an interrogating RF
signal with simple identifying information, or with more complex signals depending on the size of the IC. RFID technology does not require contact or line of sight for communication. Radio Frequency Identification (RFID) technology is now economically viable and is deployed in more and more commercial and industrial applications. For example, RFID technology is now widely used for tags on items in warehouses, shops, ID or access cards, etc. In addition, RFID technology has been introduced in the payment card industry (e.g., by MasterCard, American Express and Visa) in the form of "contactless" payment or credit cards embedded with RFID
tags.
These contactless payment cards can be used to make electronic payment transactions via radio communication with an RFID-enabled payment terminal. The contactless payment cards can provide consumers with simple, fast and convenient ways to pay for goods and services, for example, in retail establishments, stores or supermarkets.
Several RFID technologies are available for use in contactless payment cards and card readers/terminals. The basic components of a contactless system are the contactless reader (or Proximity Coupling Device (PCD)) and a transponder.
The contactless reader is an antenna connected to an electronic circuit. A
transponder consists of an inductive antenna and an integrated circuit connected to the ends of this antenna. The combination reader-transponder behaves as a transformer. An alternating current passes through a primary coil (reader antenna) that creates an electromagnetic field, which induces a current in the secondary coil (transponder antenna). The transponder converts the electromagnetic field (or RF field) transmitted by the contactless reader (PCD) into a DC voltage by means of a diode rectifier. This DC voltage powers up the transponder's internal circuits. The configuration and tuning of both antennas determines the coupling efficiency from one device to the other. The transponders may be the contactless payment cards.
For contactless payment card systems to be economically viable and to gain commercial acceptance, the contactless payment cards must be interoperable at all or most RFID-enabled payment terminals, even when the cards and terminals have technological features that are proprietary to specific card providers/issuers, vendors or terminal manufacturers. Industry-wide interoperability is desirable.
Towards this end, industry standards organizations and groups (e.g., International Organization for Standards (ISO) and International Electro Technical Committee (IEC)) have formulated voluntary industry standards for implementation of contactless payment technologies. Three such exemplary standards which have been defined by ISO/IEC
are the ISO/IEC 10536, ISO/IEC 14443, and ISO/IEC 15693 standards applicable to Close Coupling, Proximity and Vicinity cards, respectively.
The ISO/IEC 14443 proximity card standards (ISO 14443) have been used for several contactless card deployments worldwide. The targeted range of operations for ISO 14443 proximity cards is up to 10 cms, although this range varies depending on power requirements, memory size, CPU, and co-processor.
The ISO 14443 standards document has four distinct parts:
= Part 1: Physical Characteristics, defines the physical dimensions for a Proximity Integrated Circuit Card (PICC). The card is the ID-1 size (85.6 mm x 54.0 mm x.76 mm). This is the same size as a bank credit card.
= Part 2: Radio Frequency Power and Signal Interface, defines key technical characteristics of the contactless IC chips, including items such as frequency, data rate, modulation, and bit coding procedures. Two variations are detailed in Part 2, the Type A interface and the Type B interface. Both operate at the same frequency and use the same data rate, but they differ from one another in the areas of modulation and bit coding.
CONTACTLESS CARD PAYMENT SYSTEMS
SPECIFICATION
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of United States provisional patent application No. 60/588,270 filed on July 15, 2004. This application is also related to United States patent applications S/N , and S/N , S/N , and S/N
, co-filed on even date, all of which claim the benefit of the aforementioned patent application No. 60/588,270. All of the aforementioned patent applications are hereby incorporated by reference herein in their entireties BACKGROUND OF THE INVENTION
Radio Frequency Identification (RFID) tags are small integrated circuits (ICs) connected to an antenna, which can respond to an interrogating RF
signal with simple identifying information, or with more complex signals depending on the size of the IC. RFID technology does not require contact or line of sight for communication. Radio Frequency Identification (RFID) technology is now economically viable and is deployed in more and more commercial and industrial applications. For example, RFID technology is now widely used for tags on items in warehouses, shops, ID or access cards, etc. In addition, RFID technology has been introduced in the payment card industry (e.g., by MasterCard, American Express and Visa) in the form of "contactless" payment or credit cards embedded with RFID
tags.
These contactless payment cards can be used to make electronic payment transactions via radio communication with an RFID-enabled payment terminal. The contactless payment cards can provide consumers with simple, fast and convenient ways to pay for goods and services, for example, in retail establishments, stores or supermarkets.
Several RFID technologies are available for use in contactless payment cards and card readers/terminals. The basic components of a contactless system are the contactless reader (or Proximity Coupling Device (PCD)) and a transponder.
The contactless reader is an antenna connected to an electronic circuit. A
transponder consists of an inductive antenna and an integrated circuit connected to the ends of this antenna. The combination reader-transponder behaves as a transformer. An alternating current passes through a primary coil (reader antenna) that creates an electromagnetic field, which induces a current in the secondary coil (transponder antenna). The transponder converts the electromagnetic field (or RF field) transmitted by the contactless reader (PCD) into a DC voltage by means of a diode rectifier. This DC voltage powers up the transponder's internal circuits. The configuration and tuning of both antennas determines the coupling efficiency from one device to the other. The transponders may be the contactless payment cards.
For contactless payment card systems to be economically viable and to gain commercial acceptance, the contactless payment cards must be interoperable at all or most RFID-enabled payment terminals, even when the cards and terminals have technological features that are proprietary to specific card providers/issuers, vendors or terminal manufacturers. Industry-wide interoperability is desirable.
Towards this end, industry standards organizations and groups (e.g., International Organization for Standards (ISO) and International Electro Technical Committee (IEC)) have formulated voluntary industry standards for implementation of contactless payment technologies. Three such exemplary standards which have been defined by ISO/IEC
are the ISO/IEC 10536, ISO/IEC 14443, and ISO/IEC 15693 standards applicable to Close Coupling, Proximity and Vicinity cards, respectively.
The ISO/IEC 14443 proximity card standards (ISO 14443) have been used for several contactless card deployments worldwide. The targeted range of operations for ISO 14443 proximity cards is up to 10 cms, although this range varies depending on power requirements, memory size, CPU, and co-processor.
The ISO 14443 standards document has four distinct parts:
= Part 1: Physical Characteristics, defines the physical dimensions for a Proximity Integrated Circuit Card (PICC). The card is the ID-1 size (85.6 mm x 54.0 mm x.76 mm). This is the same size as a bank credit card.
= Part 2: Radio Frequency Power and Signal Interface, defines key technical characteristics of the contactless IC chips, including items such as frequency, data rate, modulation, and bit coding procedures. Two variations are detailed in Part 2, the Type A interface and the Type B interface. Both operate at the same frequency and use the same data rate, but they differ from one another in the areas of modulation and bit coding.
= Part 3: Initialization and Anticollision. Initialization describes the requirements for proximity coupling device (PCD) (i.e., the reader) and the card to establish communication when the card is brought into the reader's radio frequency (RF) field. Anticollision defines what happens when multiple cards enter the magnetic field at the same time, identifying how the system determines which card to use in the transaction and ensuring that all cards presented are inventoried and processed.
= Part 4: Transmission Protocols, defines the data format and data elements that enable communication during a transaction.
For a system of contactless payment cards and card readers to be compliant with ISO 14443, they must meet the requirements of at least some of parts of the voluntary standard. In addition to contactless technologies that are standardized under ISO 14443, a number of proprietary contactless interfaces are also used in the industry (e.g., Cubic's GO-Card and Sony's FeliCa card). With existing card technology deployments, interoperability can be an issue. Card readers deployed by vendors in the marketplace should preferably accommodate several different card types. For example, a desirable card reader would support ISO 14443 Type A and Type B cards, ISO 15693 cards and any additional proprietary card types.
Interoperability issues can arise even with card deployments that are presumably compliant with a single ISO standard (e.g., ISO 14443). In the ISO
14443 standard, all requirements or specifications related to RF Power and signal interfaces in the contactless card and reader system (i.e., the physical layer in an Open System Interconnection (OSI) model view of the system) are defined using separate standardized tests for cards and for readers. The ISO/TEC 10373 Standard Part 6 (ISO
10373-6) deals with test methods, which are specific to contactless integrated circuit card technology (proximity card). Compliance of contactless cards and readers to ISO 14443 is verified using reference devices. According to ISO 10373-6, a set of "reference" cards (i.e., Reference PICC), which represent the characteristics of contactless cards, is used for measuring specification compliance of a contactless reader. For example, the Reference PICC is used to test the magnetic field produced or transmitted by a PCD, and to test the ability of the PCD to power a PICC.
Similarly, a "reference" reader (i.e., a Test or Reference PCD), which may represent the characteristics of a typical contactless reader, is used for measuring specification compliance of contactless cards. For example, the Reference PCD in conjunction with a pair of external sense coils is used to test the load modulation that is generated by cards during testing.
While the separate card and reader compliance test procedures under ISO 10373-6 may ensure that deployed product devices individually have characteristics that fall in either the designated specification range for cards or readers, the procedures do not ensure interoperability in the field. Cards and/or readers verified as compliant may be only marginally so (e.g., by having a characteristic value at the end or edge of a designated specification range).
This manner of standards compliance can lead to operational failure in the field.
For example, a marginally compliant card may be unreadable or difficult to read using a card reader that is also only marginally compliant.
Further, with respect to verifying important data transmission and reception functions of contactless devices, ISO 10373-6 makes provisions for only indirect measurements of the load modulated data signals generated by cards. A
PCD
Test Assembly prescribed by ISO 10373-6 for testing product cards has a pair of sense coils that are external to the reference PCD reader. These external sense coils are utilized to measure the load modulated data signal generated and transmitted by card under test. However, there is no direct or obvious relation between the load modulated signal measured by the sense coils and the signal that is physically received by the reference PCD antenna. Therefore, testing of data transmission functions of a product card using the external sense coils does provide direct assurance that a putatively ISO compliant product card's modulation of data signals is sufficient or compatible with a product reader's ability to receive or process the modulated data signals properly.
U.S. patent applications S/N , S/N , S/N , and S/N disclose solutions for enhancing device interoperability based on improvements in specification definitions, compliance testing, and in test equipment related to the RF power and signal interface between interacting card and reader devices.
Consideration is now being given to further ways of enhancing interoperability of the electronic payment devices and also to making the operation the contactless electronic payment systems robust and failure proof. Attention is now directed to aspects of electronic payment systems related to the physical characteristics of payment devices, and to initialization and anticollision schemes.
SUMMARY OF THE INVENTION
The present invention provides a collision detection and avoidance scheme for processing transactions involving interacting contactless payment cards and card readers in an electronic payment system. The collision detection and avoidance scheme is based on a rule that a transaction is to be processed if and only if one payment card is present in the operating field of the card reader. If more than one card is present in the operating field of the card reader, transaction processing is halted. The scheme requires external intervention to remove excess cards, selection and resubmission of only one card before transaction processing can resume.
In the electronic payment system, the card reader is configured to process transactions when only one card is present in its operating field. The card reader uses collision detection and avoidance algorithms to detect and report instances where multiple cards are present in the operating field.
A collision detection and avoidance algorithm involves investigating the presence of multiple payment cards in the operating field of the card reader and halting processing of the transaction when more than one payment card is present. In the collision detection and avoidance algorithm, a card polling sequence initiated by the reader polls and awaits responses from cards that may be present in the operating field of the card reader. If more than one type of cards are supported by the reader, the polling sequence includes wake-up commands for all supported types of cards.
For example, the polling sequence may include alternating wake-up commands for the ISO 14443 Type A and Type B cards. When only one card is found to be present in the operating field of the card reader, the collision detection and avoidance algorithm identifies the type of the card. The reader may then activate a communication session with the subject card using activation commands appropriate to the identified type of the card. After a transaction with the identified card has been processed, the card is deactivated and removed.
The collision detection and avoidance algorithm uses a binary search technique to detect collisions of ISO 14443 Type A contactless payment cards.
The collision detection and avoidance algorithm employs a Slotted Aloha technique to detect collisions of ISO 14443 Type B contactless payment cards. After one card of a particular type (e.g., Type A or Type B) has been identified as present in the card reader's operating field, polling is conducted for presence of other types of card to check that only one card of any type is present.
Further features of the invention, its nature and various advantages will be more apparent from the accompanying drawings and Appendix and the following detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS AND APPENDIX
FIG. 1 is flow chart illustrating the steps in an exemplary terminal process loop for collision detection and avoidance, in accordance with the principles of the present invention.
FIG. 2 is flow chart illustrating the steps in a generic polling and collision detection process run in a PCD, in accordance with the principles of the present invention.
FIG. 3 is flow chart illustrating the steps in an exemplary detection algorithm 300, which may be used to investigate Type A card collisions in accordance with the principles of the present invention.
Appendix A contains descriptions of a set of commands and responses available to a PCD for polling and collision detection processes and for the activation of a Type A PICC. The set of commands are used in an exemplary implementation of proximity payment card technologies by the assignee MasterCard. The commands and responses described in Appendix A are referred to in FIGS. 2 and 3 and in the following description. The commands available to a PCD for polling and collision detection processes and for activation of a Type B card are similar. For brevity, a description of commands and response for Type B card are not included herein.
DETAILED DESCRIPTION OF THE INVENTION
A collision detection and avoidance scheme for initiating and conducting electronic transactions using a payment card and a card reader is provided.
Initialization describes the requirements for the reader and the card to establish communication when the card is brought into the reader's radio frequency (RF) field.
Collision refers to situations where multiple cards enter the operating volume or field of the reader at the same time, for example, when several store customers in a rush present their cards simultaneously to the reader, or when a customer inadvertently presents a wallet holding several cards to the reader. The reader processes include collision detection processes and alarm generation processes. The alarm generation processes may lead to manual intervention to clear the collision or to user identification of a single card for continued electronic transaction processing. The collision detection and avoidance scheme may be implemented in readers, which support more than one type of cards (e.g., both Type A and Type B cards).
The collision detection and avoidance scheme of the present invention overcomes known drawbacks of conventional anticollision schemes that are used in or recommended for electronic payment systems. The various proximity card standards, which have been used for several contactless card deployments worldwide, generally recommend anticollision processes to deal with the presence of multiple cards in a reader's operating volume or field. For example, ISO 14443 Part 3 recommends anticollision algorithms (loops) to detect and communicate with one particular card when several cards are presented to the same reader. Under ISO 14443 Part 3, the reader first polls and inventories all cards entering its field using polling commands such as Request (REQ) and Answer To Request (ATQ) commands. Then, an anticollision algorithm or loop is used to prepare for dialogue between the reader and one or more selected cards out of the total number of cards responding to a request command. For Type A cards, a binary search algorithm based on the unique identifier (UID) of each card is prescribed. For Type B cards, a Slotted Aloha algorithm with special slot markers is prescribed. The ISO 14443 initialization and anticollision scheme is designed to permit the construction of readers capable of conununication with several cards of the same type, which are powered simultaneously. Both card Types A and B wait silently in the field for a polling command. A multi-protocol reader using the ISO 14443 initialization and anticollision scheme would poll one type (e.g., Type A), complete any transactions with all cards responding, and then poll for the other type (e.g., Type B), and transact with them.
The ISO 14443 anticollision schemes have known drawbacks. For example, the anticollision algorithms can become corrupted if cards enter and/or leave the reader field after they have been inventoried or tallied. Further, concurrent reader communication with a number of cards distributes available power, which is limited, between the cards. Low power availability may affect card functionality. These drawbacks are overcome by the collision detection and avoidance scheme of the present invention.
Recently, assignee MasterCard International Incorporated ("MasterCard") has developed proprietary specifications MasterCard PayPassTM
ISO/IEC 14443 Implementation Specification ("PayPass") for implementation of proximity payment card technologies (e.g., by issuers, vendors or manufacturers of cards and card readers). The inventive anticollision scheme the present invention is described for purposes of illustration in the context of the exemplary PayPass implementation. It will be understood that the selection of the PayPass implementation for purposes of illustration herein is only exemplary, and that the principles of the present invention can be more generally applied to any electronic payment system involving interacting cards and card readers.
The collision detection and avoidance scheme is described with reference to transactions conducted when cards are presented, for example, to a terminal device at a point of transaction (e.g., at a store checkout stand).
The terminal device includes a card reader (PCD) and may include other electronics, transaction processing applications, user interfaces (e.g., display screens) and communication interfaces (e.g., to a host computer). The inventive collision detection and avoidance scheme is based on the rule that only one PICC or card must be detected or sensed in the operating field of the card reader before the card reader or terminal is allowed to initiate or continue any transaction processing. If more than one card is sensed or detected, the scheme requires manual intervention to remove excess cards, selection and resubmission of only one card for processing.
FIG. 1 shows an exemplary terminal process loop 100 for collision detection and avoidance. The terminal process loop may be implemented in the terminal making use of the functionalities located in the card reader device.
In process loop 100, at step 1, the terminal and PCD initiate a polling sequence to detect both Type A and Type B cards that may be present in the PCD operating field.
For this purpose, the PCD may send repeated Type A and Type B wake-up commands to receive acknowledgements from any activated cards present.
At step 3, terminal process 100 assesses the number of cards present.
If only one card is polled, at next step 4 terminal processes 100 identifies the type of the card present, namely Type A or Type B. Then, according to the card type identified A or B, the PCD activates the card at steps 5 or step 8. The terminal then may use suitable terminal applications to process the card transaction (steps 6 or step 9). After the card transaction is completed, the terminal may instruct the PCD
to deactivate the processed card. The processed card is removed from the operating field (steps 7 and 10), allowing terminal process 100 to return to its starting state 0 for a next collision detection and polling sequence.
If step 1 polling results show at step 3 that no cards are present, terminal process 100 returns to its starting state 0 to initiate the next collision detection and polling sequence. If step 1 polling results show that two or more cards are present (i.e., the PCD receives a response from more than one card) then at step 2, the PCD reports a collision to the terminal and resets the cards (i.e. no carrier for a time tRESET). In this case, terminal process 100 does not proceed to process a transaction, but returns to its starting state 0 for the next polling sequence. Step 2 may involve generating alarms or messages alerting operators and/or users to the presence of multiple cards.
The PCD device included in the terminal is configured so that its functions are suitable for implementing the collision detection and avoidance scheme (e.g., terminal process 100). Table I is a list of the exemplary functional requirements for a PCD device, which is configured for implementing terminal process 100.
Table I
1. The PCD shall have only one communication signal interface active during a communication session, i.e. the PCD can communicate via either Type A or Type B interfaces. The PCD shall not mingle the two interfaces except under limited circumstances.
2. The PCD can change from one communication signal interface to another (i.e. Type A to Type B, or vice versa):
During the polling sequence (terminal process 100, step 1) By deactivating the active communication signal interface action using a provided deselection command.
Upon removal of the PICC.
Subsequent sessions may then proceed with either Type A to Type B
modulation method.
3. The PCD shall alternate between modulation methods when idling before detecting the presence of a PICC of Type A or Type B.
4. Once only a single PICC is detected during the polling and collision detection process (i.e., terminal process 100, step 1), the PCD shall activate the detected PICC to initiate the transaction process (i.e., terminal process 100, steps 5 or 8).
5. During the transaction process (i.e., terminal process 100, steps 5-10), the PCD shall not initiate any communication with another PICC.
In terminal process 100, the PCD polls for cards of both Type A and Type B to ensure that there is only one card present in its operating field.
To detect multiple PICCs within the field, the PICC and PCD are required to implement a protocol that detects the condition that more than one PICC are active. Under this protocol, the PCD is the initiating device which initiates PICC communication activity by issuing wake-up commands (WUPA and WUPB, for Type A and Type B
cards, respectively) to prompt the PICCs to respond. When more than one PICC
responds, the terminal will not initiate or proceeds a transaction (see e.g., terminal process 100, step 2).
The collision detection mechanism used by the PCD varies with card type. Type A PICCs use Manchester coding and answer synchronously to wakeup commands. These features allow the PCD to detect a collision at bit level for Type A
PICCs (i.e. a situation where at least two Type A PICCs simultaneously transmit bit patterns with complementary values for one or more bit positions). In this case, the bit patterns merge and the carrier is modulated with the subcarrier for all of the (100%) bit duration. A collision detection algorithm for Type A cards may be based on binary search techniques.
In contrast to the Type A PICCs' synchronous response, Type B PICCs respond asynchronously to wake-up commands. To detect whether more than one Type B PICC is present in the Operating Field, the PCD performs a WUPB command that is set to require all Type B PICCs to respond in the first time slot (N=1).
Responses by more than one Type B PICCs in the first time slot cause a transmission error, which is recognized as an indication of a collision of Type B PICCs.
FIG. 2 shows a PCD process 200 for collision avoidance and polling, which is generic (i.e. applicable to both Type A and Type B cards). PCD
process 200 may be made available to terminal process 100 and may be used, for example, in terminal process 100 steps 1- 3.
In process 200, the PCD probes it operating field by alternately issuing wake-up commands (e.g., WUPA for Type A cards and WUPB for Type B cards), to prompt cards to respond (e.g. steps 10, 70, 110 and 150). The PCD waits a defined time period tp before issuing each alternate WUPA and WUPB command (e.g., steps 60, 90, 100, 140, 170, and 180). At steps 20, 40, 80, 120 and 160, process 200 evaluates responses received to the preceding issued WUPA or WLTPB command. If no response is received to a particular type wake-up command (e.g. WUPB step 70, WUPA step 150), process 200 recognizes that there are either no cards of the particular type in the operating field or that only cards of the other type may be present.
In process 200, if a transmission error is received in response to a WUPA command issued, for example, at step 10, then the PCD assumes there is more than one Type A PICC (i.e. a collision) in the operating field and resorts to exception processing (transmission error). If the PCD receives a valid acknowledgement command (ATQA) from a Type A PICC, the PCD assumes that there is at least one Type A PICC in the operating field and stores the ATQA information before proceeding at step 30 with a Type A collision detection algorithm (e.g., collision detection algorithm 300 FIG. 3). The results of the Type A collision detection algorithm are evaluated at step 40. If the Type A collision detection algorithm 300 detects that more than one Type A PICC is present in the operating field (i.e.
a collision), then the PCD resorts to exception processing (transmission error).
Alternatively, if only one Type A PICC is detected, then the PCD at step 50 issues a command (HALTA) to place the one identified Type A PICC in a halt state.
Similarly in process 200, if a transmission error is received in response to a WUPB command issued, for example, at step 110, then the PCD assumes there is more than one Type B PICC (i.e. a collision) in the operating field and resorts to exception processing (transmission error). If the PCD receives a valid acknowledgement command (ATQB) from a Type B PICC then the PCD assumes there is only one Type B PICC in the operating field and issues a command (HALTB) to place the one identified Type B PICC in a halt state.
After the one identified PICC of either type has been placed in a halt state (e.g., at step 50 or step 130), the PCD issues a wakeup commands at steps 70 and 150 as appropriate for the opposite type of card to foreclose the possibility of collision between two cards of opposite type (i.e. the presence of one Type A PICC and one Type B PICC card) in the operating field. The responses to either of the wake-up commands are evaluated at steps 80 or 160. If the responses are positive, collision is indicated.
FIG. 3 shows an exemplary collison detection algorithm 300, which may be used to investigate Type A card collisions after an ATQA
acknowledgement without bit collision has been received in response to a WUPA command (e.g., at step 30, process 200). For investigating Type A collision, the PCD retrieves the UID from Type A PICC card. If the PCD is able to retrieve the UID of the Type A PICC
card without any bit collision error, then the PCD may conclude that there is only one Type A PICC present in its operating field (e.g., at step 40, process 200).
Collision detection algorithm 300 is utilized to retrieve the UID from the PICC.
At step 310, the PCD starts detection algorithm 300 by sending an ANTICOLLISION command with SEL ='93' (See e.g., Appendix A) to retrieve the complete UID of the Type A PICC and to detect whether more than one PICC of Type A is present in the operating field. If at step 302 the PCD receives a transmission error in the response to the ANTICOLLISION command, then collision is indicated and the PCD resorts exception processing (transmission error). If at step 303, the ATQA shows a single size UID, the complete UID (= UID CLI: uid0 uidl uid2 uid3 BCC) has been retrieved from the PICC. Accordingly, only one Type A
card is present and no collision with other Type A cards in indicated. Then at step 307, the PCD proceeds to put the PICC in the ACTIVE state by sending a SELECT
command with SEL ='93' and UID CL1. At step 308, the PCD stores or memorizes the complete UID
If at step 303, the ATQA shows a double or triple size UID, the PCD
proceeds cascade level-by-cascade level. First at step 304, the PCD selects cascade level 1 by sending a SELECT command with SEL='93' and UID CL I. Then at step 305, the PCD stores or memorizes the UID CL1 before proceeding to cascade level 2.
At step 306, the PCD continues with cascade level 2 by sending an ANTICOLLISION command with SEL ='95'.
Like step 302, if at step 309 the PCD receives a transmission error in the response to the ANTICOLLISION command then collision is indicated, in response to which the PCD resorts exception processing (transmission error).
Similarly, if at step 310 the received ATQA shows a double size UID, the complete UID (=UID CL1: uid0 uidl uid2 BCC; UID CL1: uid3 uid4 uid5 uid6 BCC) has been retrieved from the PICC. Accordingly, only one Type A card is present and no collision with other Type A cards in the operating volume of the reader indicated.
Then at steps 314 and 315, like at steps 307 and 308, the PCD proceeds to put the identified PICC in the ACTIVE state by sending a SELECT command with SEL =
'93' and UID CL 1, and to store or memorize the complete UID.
If at step 310, the ATQA shows a triple size UID, the PCD at step 311 selects cascade level 2 by sending a SELECT command with SEL='95' and UID
CL2. Then at step 312, the PCD stores or memorizes the UID CL2. At step 313, the PCD continues with cascade level 3 by sending an ANTICOLLISION command with SEL ='97'. If at step 316 the PCD detects a transmission error in the response to this ANTICOLLISION command, collision is indicated and the PCD resorts to exception processing (transmission error). If no transmission error-free ATQA command is received from the PICC, the complete UID (= UID CL1: CT uid0 uidl uid2 BCC;
UID CL2: CT uid3 uid4 uid5 BCC; UID CL3: uid6 uid7 uid8 uid9 BCC) has been retrieved from the PICC. Accordingly, only one Type A card is present and no collision with other Type A cards in indicated. Then at steps 317 and 318, like at steps 307 and 308, the PCD proceeds to put the identified PICC in the ACTIVE
state by sending a SELECT command with SEL ='97' and UID CL3, and to store or memorize the complete UID.
After only one card has been identified as being present in the operating field of the reader (e.g., Type B in terminal process 200 step 130, or Type A
in algorithm 300 steps 307 or 314, etc.), the card is activated. The PCD/terminal proceeds to communicate with the activated card and completed the desired transaction. After the desired transaction is completed, the subject card is deactivated.
During terminal process 200 or algorithm 300, when collision is indicated, the PCD resorts to exception processing. No transactions are conducted until the exception is satisfactorily cleared. During the polling and collision detection sequence upon detection of a transmission error indicating collision, the PCD
reports the collision detection to the terminal arid resets the PICC the PCD for a time period tRESET. During this time period tRESET, no carrier signal is transmitted to the PICCs. The PCD returns to the polling and collision detection sequence. The PCD's report of the collision detection to the terminal, can lead to user intervention to clear the multiple cards present in the operating field.
While the present invention has been particularly described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various modifications and alterations may be made without departing from the spirit and scope of the invention. Accordingly, the disclosed embodiments of the invention are considered merely illustrative, and the invention is limited in scope only as specified in the appended claims.
5.1 Type A - Command Set Table 5.1 lists the commands that are available to the PCD for communication with a PICC of Type A. For every command, the corresponding response from the PICC is indicated.
Table 5.1-Type A - Command Set PCD Command PICC Response WUPA ATQA
HLTA -RATS ATS
This chapter details the format of these commands and their responses from the PICC.
5.2 Type A - CRC-A
Some of the commands defined in Table 5.1 include a CRC for error checking.
The CRC_A is defined as a function of k data bits, which consist of all the bits in the command excluding the CRC_A itself. Since all commands using a CRC_A are encoded in bytes, the number of bits k is a multiple of 8.
Figure 5.1 shows how a command with a CRC_A is included within a standard frame. CRC_A1 is the least significant byte and CRC A2 is the most significant byte.
Figure 5.1-Position of CRC-A within a Standard Frame Command + CRC A
Byte I Byte 2 Byte n CRC A 1 CRC A2 I S bl b2 ... b8 P bl b2 ... b8 P bl ... b8 P CRC A1 P CRC A2 P E
Requirements 5.1-CRC A
PCD and PICC
5.2.1.1 If a CRC_A is included in the standard frame, then it shall be inserted in the fiame between the last parity bit of the data bits and the End of Communication (E). Each CRC_A
byte shall be followed by a parity bit. A short frame shall not have a CRC A.
5.2.1.2 The CRC_A is as defmed in [ISO/IEC 132391, but the initial register content shall be '6363' and the register content shall not be inverted after calculation.
5.3 WUPA
The WUPA command is sent by the PCD to probe the field for PICCs of Type A.
5.3.1 WUPA Command The WUPA command is transmitted within a short frame and its coding is specified in Table 5.2.
Table 5.2-Coding of WUPA within a Short Frame b7 b6 b5 b4 b3 b2 b1 Meaning 1 0 1 0 0 1 0 '52' = WUPA
5.3.2 WUPA Response (ATQA) In response to a WUPA command from the PCD, a PICC of Type A, depending on its state (see chapter 7) will return an ATQA with a length of two bytes. The ATQA is transmitted within a standard frame without the CRC_A bytes and coded as specified in Table 5.3 and Table 5.4.
Table 5.3-Byte I of ATQA
b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 UID size: single (4 bytes) 0 1 UID size: double (7 bytes) 1 0 UID size: triple (10 bytes) 1 1 Not allowed 1 0 0 0 0 Bit frame anticollision 0 1 0 0 0 Bit frame anticollision 0 0 1 0 0 Bit frame anticollision 0 0 0 1 0 Bit frame anticollision 0 0 0 0 1 Bit frame anticollision All other values Not allowed 5.6.2 HLTA Response The PICC does not respond to a HLTA command. The PCD always assumes that the HLTA
command has been 'acknowledged' by the PICC.
Requirements 5.8-HLTA Response PCD PICC
5.6.2.1 The PCD shall always consider the 5.6.2.2 The PICC shall not respond to a HLTA
HLTA command as "acknowledged". command.
5.7 Request for Answer to Select (RATS) The RATS command is used by the PCD during the protocol activation sequence to negotiate with the PICC the maximum frame size and the bit rate divisor (D).
5.7.1 RATS Command The RATS command is transmitted within a standard frame including the CRC_A
bytes. Its coding is specified in Table 5.12.
Table 5.12-Coding of RATS Command Byte 1 Byte 2 Byte 3- 4 'EO' PARAM CRC A
PARAM, the parameter byte, consists of two parts (see Table 5.13).
Table 5.13-Format of RATS Parameter Byte (PARAM) b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x FSDI
x x x x CID
The most significant nibble b8 to b5 is called FSDI (Frame Size for proximity coupling Device Integer) and codes FSD (Frame Size for proximity coupling Device). Refer to section 4.3.1 for the definition of FSD. The coding of FSD in terms of FSDI is given in Table 5.14.
Table 5.14-FSDI to FSD Conversion FSDI 10' 11) '2' '3' '4' 151 '61 '71 W '9'-'F' FSD (bytes) 16 24 32 40 48 64 96 128 256 RFU
Requirements 5.9-FSDIMIN
PCD
5.7.1.1 The PCD shall set FSDI equal to FSDIMIN. Refer to Annex A for the value of FSDIMIN.
Requirements 5.10-PICC Handling of RFU values of FSDI
PICC
5.7.1.2 A received value of FSDI ='9'-'F' shall be treated by the PICC as FSDI
='8'.
The least significant nibble b4 to bl is named CID and it defines the logical number of the addressed PICC in the range from 0 to 14. The CID is set to zero as the PCD
only addresses a single PICC at a time.
Requirements 5.11-Support of CID
PCD PICC
5.7.1.3 The PCD shall not use Card Identifier 5.7.1.4 The PICC shall accept a PCD sending a (CID), indicated by setting bl-b4 to RATS command with PARAM CID bits (0000)b. set to (0000)b.
The PICC may support a CID different from (000a)b.
Requirements 5.12-PICC Error Handling of RATS Command PICC
5.7.1.5 The PICC shall consider any RATS command transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
5.7.2 RATS Response (Answer To Select) The Answer To Select (ATS) is transmitted by the PICC in response to the RATS
command. The ATS is transmitted within a standard frame including the CRC_A bytes. This section defines the ATS with all its available fields (see Table 5.15).
Table 5.15-Structure of the ATS
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 - 6+k-1 Byte 6+k - 6+k+1 TL TO TA(l) TB(1) TC(1) T1 ... Tk CRC A
The length byte TL is followed by a variable number of bytes in the following order:
= format byte TO, = interface bytes TA(1), TB(1), TC(1) and = historical bytes TI to Tk.
= Length byte The length byte TL is mandatory and specifies the length of the transmitted ATS including itself. The two CRC bytes are not included in TL.
Requirements 5.13-Length Byte TL of the ATS
PCD PICC
5.7.2.1 The first byte of the ATS (TL) shall specify the length of the ATS
including TL itself. The two CRC
bytes shall not be included in TL.
5.7.2.2 The PCD shall be capable of 5.7.2.3 TL shall not indicate a length greater supporting a PICC returning an ATS than 20 bytes (maximum 15 historical with TL specifying a length less than bytes are allowed as TA(1), TB(1) and or equal to 20 bytes. TC(l) must always be present).
The PCD may support a P1CC returning an ATS
with TL indicating a length greater than 20 bytes.
= Format Byte TO
The format byte TO is coded as specified in Table 5.16.
Table 5.16-Coding of Format Byte TO
b8 b7 b6 b5 b4 b3 b2 b1 Meaning x TC(1) is transmitted, if bit is set to 1 x TB(1) is transmitted, if bit is set to I
x TA(l) is transmitted, if bit is set to I
x x x x FSCI
The least significatit nibble b4 to bl is called FSCI (Frame Size for proximity Card Integer) and codes FSC (Frame Size for proximity Card). Refer to section 4.3.2 for the definition of FSC. The coding of FSC in terms of FSCI is specified in Table 5.17. The default value of FSCI is 2 and leads to a FSC of 32 bytes..
Table 5.17--FSCI to FSC Conversion FSCI 10' 11) '2' '3' '4' 45) W '7$ '8' 49'-'F' FSC (bytes) 16 24 32 40 48 64 96 128 256 RFU
Requirements 5.14-FSCIM,N
PICC
5.7.2.4 The PICC shall set FSCI greater than or equal to FSCIMIN with a maximum value of 8.
Refer to Annex A for the value of FSCIMIN.
Requirements 5.15-PCD Handling of RFU values of FSCI
PCD
5.7.2.5 A received value of FSCI ='9'-'F' shall be treated by the PCD as FSCI
='8'.
Requirements 5.16-Format Byte TO of the ATS
PCD PICC
5.7.2.6 The PCD shall be capable of supporting 5.7.2.7 TA(l), TB(l) and TC(l) shall be a PICC returning an ATS including TO, present in the ATS and the presence TA(l), TB(l) and TC(l). If one or shall be indicated in TO.
more of the fields TO, TA(1), TB(l) and TC(l) are missing, then the PCD shall use the default values as specified in this section.
= Interface Byte TA(1) The interface byte TA(1) conveys information to define the bit rate capabilities of the PICC.
The interface byte TA(1) is coded as specified in Table 5.18. The bits b7 to b5 code the bit rate capability of the PICC for the direction from PICC to PCD (Dplcc->PCD)=
The default value for the bits b7 to b5 is (000)b. The bits b3 to b l code the bit rate capability of the PICC for the direction from PCD to PICC (DPCD-1,PICC). The default value for the bits b3 to b 1 is (000)b.
Table 5.18-Coding of Interface Byte TA(1) b8 b7 b6 b5 b4 b3 b2 b1 Meaning x If b8 =(1)b, then only the same bit rate divisor for both directions is supported (Dp1cc-+rcD=DPcwPjcc)=
If bS =(0)b, then a different bit rate divisor for each direction is supported.
x DeIcc-~PCD = 8 supported, if bit is set to (1)b.
x Dr1cc--WcD =4 supported, if bit is set to (1)b.
x DPlcc-,acD =2 supported, if bit is set to (1)b.
x DPCn-+Picc =8 supported, if bit is set to (1)b.
x Drcn-.rIcc =4 supported, if bit is set to (1)b.
x DPCD-aP-cc =2 supported, if bit is set to (1)b.
Requirements 5.17-Format Byte TA(1) of the ATS
PCD PICC
The PCD may support higher bit rates. 5.7.2.8 The PICC shall set TA(l) equal to '80', indicating that it supports only a bit rate of 106 kbits/s in both directions.
= Interface Byte TB(1) The interface byte TB(1) conveys infonnation to define the Frame Waiting Time (FWT) and the Start-up Frame Guard Time (SFGT). The interface byte TB(1) is coded as specified in Table 5.19.
Table 5.19-Coding of Interface Byte TB(1) b8 b7 b6 b5 b4 0 b2 b1 Meaning x x x x FWI
x x x x SFGI
- The most significant nibble b8 to b5 is called FWI (Frame Waiting time Integer) and codes FWT. Refer to section 4.2.3 for the definition of FWT. The default value of FWI is 4 and leads to a FWT of 512 etu.
- The least significant nibble b4 to bl codes SFGI (Start-up Frame Guard time Integer) and shall be used by the PICC to code a multiplier value used to define the SFGT.
Refer to section 4.2.2 for the definition of SFGT. The default value of SFGI is 0.
Requirements 5.18-Interface Byte TB(1) of the ATS
PCD PICC
5.7.2.9 The PICC shall set FWI less than or equal to FWIMAx. Refer to Annex A
for the value of FWIMroc.
5.7.2.10 The PCD shall be capable of 5.7.2.11 The PICC shall set SFGI less than or supporting a PICC returning an ATS equal to SFGImAx. Refer to Annex A
with TB(l) indicating an SFGI less for the value of SFGImAx.
than or equal to SFGImAx.
The PCD may support a PICC with an SFGI
greater than SFGImAx.
= Interface Byte TC(1) The interface byte TC(1) indicates whether Node Addressing (NAD) and Card Identifier (CID) are supported by the PICC. The interface byte TC(1) is coded as specified in Table 5.20.
Table 5.20-Coding of Interface Byte TC(1) b8 b7 b6 b5 b4 b3 b2 bi Meaning x CID supported, if bit is set to (1)b x NAD supported, if bit is set to (1)b The bits b2 and bl shall be used by the PICC to define which optional fields in the prologue field it supports. Bit b 1 set to 1 indicates NAD supported; b2 set to 1 indicates CID supported.
Refer to section 10.2 for the specification of the prologue field.
Requirements 5.19-Interface Byte TC(1) of the ATS
PCD PICC
5.7.2.12 The PCD shall not use Card Identifier The PICC may support Card Identifier (CID) (CID) or Node Addressing (NAD) and and/or Node Addressing (NAD).
shall disregard any value returned by the PICC in b1-b2 ofTC(1).
= Historical Bytes The historical bytes T1 to Tk are optional and shall be used by the PICC to designate general information. The maximum length of the ATS gives the maximum possible number of historical bytes.
Requirements 5.20-Historical Bytes of the ATS
PCD PICC
5.7.2.13 The PCD shall allow the PICC to send 5.7.2.14 The PICC shall send no more than 15 at least 15 historical bytes. historical bytes. The number of the A PCD may support an A TS with more than 15 historical bytes shall be in line with the length byte TL and the presence of historical bytes. TA(1), TB(1) and TC(1).
Table 5.6-Coding of SEL
b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 0 0 1 0 0 1 1 '93': ANTICOLLISION CL1 1 0 0 1 0 1 0 1 '95': ANTICOLLISION CL2 1 0 0 1 0 1 1 1 '97': ANTICOLLISION CL3 1 0 0 1 other values except those Not allowed here above With the SEL byte the Cascade Level (CL) of the UID requested by the ANTICOLLISION
command is defined.
5.4.2 ANTICOLLISION Response (UID CLn) In response to the ANTICOLLISION command all PICCs in the Operating Field transmit the requested cascade level of their UID (UID CLn, with n=1, 2 or 3). The UID of a Type A PICC
consists of 4, 7 or 10 bytes. The length of the response is always 5 bytes.
The coding of the response is depending on the value of the SEL byte and the length of the UID.
The ANTICOLLISION response is transmitted within a standard frame without the CRC_A bytes. Its coding is specified in Table 5.7.
Table 5.7-UID CLn SEL UID Size Response (UID CLn) '93' 4 UID CL1: uido uid, uid2 uid3 BCC
'93' > 4 UID CL 1: CT uida uid, uid2 BCC
'95' 7 UID CL2: uid3 uid4 uid5 uid6 BCC
'95' > 7 UID CL2: CT uid3 uid4 uid5 BCC
'97' 10 UID CL3: uid6 uid7 uid8 uid9 BCC
Where:
= CT is the cascade tag with a value of '88'. The purpose of the cascade tag is to force a collision with PICCs that have a smaller UID size. Therefore, uido of a single size UID and uid3 of a double size UID must not have the value '88'.
= BCC is the UID CLn check byte. BCC is calculated as exclusive-or over the 4 previous bytes.
= uidõ is the n'h byte of the complete UID with uido the most significant byte.
Requirements 5.4-PCD Handling of BCC
PCD
5.4.2.1 The PCD shall verify the BCC included in the UID CLn. The PCD shall consider an incorrect BCC as a transmission error.
5.4.2.2 The PCD shall consider any UID CLn transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
Table 5.4---Byte 2 of ATQA
b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x Any value Requirements 5.2-PCD Handling of ATQA
PCD
5.3.2.1 The PCD shall disregard any value returned by the PICC in the least significant nibble b4 to bl of byte 2 of the ATQA.
5.3.2.2 The PCD shall consider any ATQA transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
Requirements 5.3-UID Length PCD PICC
5.3.2.3 The PCD shall be capable of success- 5.3.2.4 The PICC shall have a fixed UID of 4, 7 fully recovering a UID of 4, 7 or 10 or 10 bytes.
bytes.
5.4 ANTICOLLISION
The ANTICOLLISION command is used to obtain the complete UID of a Type A PICC
and to detect whether more than one PICC of Type A is in the Operating Field of the PCD (see section 9.2.3 for more details).
5.4.1 ANTICOLLISION Command The ANTICOLLISION command is transmitted within a standard frame without the CRC_A
bytes. Its coding is specified in Table 5.5.
Table 5.5--Coding of ANTICOLLISION Command Byte I Byte 2 SEL '20' The SEL byte is coded as shown in Table 5.6.
5.5 SELECT
The SELECT command is used to select the Type A PICC using its UID.
5.5.1 SELECT Command The SELECT command is transmitted within a standard frame including the CRC_A
bytes. Its coding is specified in Table 5.8.
Table 5.8-Coding of SELECT Command Byte I Byte 2 Bytes 3 - 7 Bytes 8 - 9 SEL '70' UID CLn CRC-A
The SEL byte is coded as is shown in Table 5.9.
Table 5.9-Coding of SEL
b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 0 0 1 0 0 1 1 '93': SELECT CL I
1 0 0 1 0 1 0 1 '95': SELECT CL2 1 0 0 1 0 1 1 1 '97': SELECT CL3 1 0 0 1 Other values except those Not allowed here above The coding of UID CLn is depending on the value of the SEL byte and the size of the UID. The coding is the same as for the ANTICOLLISION response and specified in Table 5.7.
Requirements 5.5-PICC Error Handling of SELECT Command PICC
5.5.1.1 The PICC shall consider any SELECT command transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
5.5.2 Response - Select Acknowledge - SAK
The SAK is transmitted by the PICC in response to a SELECT command when all the data bits match with the UID CLn of the PICC. The length of the SAK is one byte and transmitted to the PCD within a standard frame including the CRC_A bytes. The SAK is coded as specified in Table 5.10.
Table 5.10-Coding of SAK
b8 b7 b6 b5 b4 b3 b2 b1 Meaning x PICC compliant with ISO/IEC 14443-4 if bit is set to (1)b x Cascade bit: UID not complete if bit is set to (1)b Requirements 5.6-Type A PICC compliance with ISO/IEC 14443-4 PCD PICC
5.5.2.1 The PCD shall support a PICC indicating 5.5.2.2 The PICC shall be conformity to ISO/IEC 14443-4. compliant. This means that the PICC
The PCD may support a P1CC not indicating shall indicate conformity to ISO/IEC
conformity to ISO 14443-4. 14443-4 to the PCD by setting b6 of the SAK to (1)b:
Requirements 5.7-PCD Error Handling of SAK Response PCD
5.5.2.3 The PCD shall consider any SAK transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
5.6 H LTA
The HLTA command is used to put the PICC in the HALT state (see chapter 7).
5.6.1 HLTA Command The HLTA command consists of two bytes and is transmitted within a standard frame including the CRC_A bytes. Table 5.11 specifies the coding of the HLTA command.
Table 5.11-Coding of HLTA Command Byte 1 Byte 2 Byte 3- 4 650' '00' CRC A
= Part 4: Transmission Protocols, defines the data format and data elements that enable communication during a transaction.
For a system of contactless payment cards and card readers to be compliant with ISO 14443, they must meet the requirements of at least some of parts of the voluntary standard. In addition to contactless technologies that are standardized under ISO 14443, a number of proprietary contactless interfaces are also used in the industry (e.g., Cubic's GO-Card and Sony's FeliCa card). With existing card technology deployments, interoperability can be an issue. Card readers deployed by vendors in the marketplace should preferably accommodate several different card types. For example, a desirable card reader would support ISO 14443 Type A and Type B cards, ISO 15693 cards and any additional proprietary card types.
Interoperability issues can arise even with card deployments that are presumably compliant with a single ISO standard (e.g., ISO 14443). In the ISO
14443 standard, all requirements or specifications related to RF Power and signal interfaces in the contactless card and reader system (i.e., the physical layer in an Open System Interconnection (OSI) model view of the system) are defined using separate standardized tests for cards and for readers. The ISO/TEC 10373 Standard Part 6 (ISO
10373-6) deals with test methods, which are specific to contactless integrated circuit card technology (proximity card). Compliance of contactless cards and readers to ISO 14443 is verified using reference devices. According to ISO 10373-6, a set of "reference" cards (i.e., Reference PICC), which represent the characteristics of contactless cards, is used for measuring specification compliance of a contactless reader. For example, the Reference PICC is used to test the magnetic field produced or transmitted by a PCD, and to test the ability of the PCD to power a PICC.
Similarly, a "reference" reader (i.e., a Test or Reference PCD), which may represent the characteristics of a typical contactless reader, is used for measuring specification compliance of contactless cards. For example, the Reference PCD in conjunction with a pair of external sense coils is used to test the load modulation that is generated by cards during testing.
While the separate card and reader compliance test procedures under ISO 10373-6 may ensure that deployed product devices individually have characteristics that fall in either the designated specification range for cards or readers, the procedures do not ensure interoperability in the field. Cards and/or readers verified as compliant may be only marginally so (e.g., by having a characteristic value at the end or edge of a designated specification range).
This manner of standards compliance can lead to operational failure in the field.
For example, a marginally compliant card may be unreadable or difficult to read using a card reader that is also only marginally compliant.
Further, with respect to verifying important data transmission and reception functions of contactless devices, ISO 10373-6 makes provisions for only indirect measurements of the load modulated data signals generated by cards. A
PCD
Test Assembly prescribed by ISO 10373-6 for testing product cards has a pair of sense coils that are external to the reference PCD reader. These external sense coils are utilized to measure the load modulated data signal generated and transmitted by card under test. However, there is no direct or obvious relation between the load modulated signal measured by the sense coils and the signal that is physically received by the reference PCD antenna. Therefore, testing of data transmission functions of a product card using the external sense coils does provide direct assurance that a putatively ISO compliant product card's modulation of data signals is sufficient or compatible with a product reader's ability to receive or process the modulated data signals properly.
U.S. patent applications S/N , S/N , S/N , and S/N disclose solutions for enhancing device interoperability based on improvements in specification definitions, compliance testing, and in test equipment related to the RF power and signal interface between interacting card and reader devices.
Consideration is now being given to further ways of enhancing interoperability of the electronic payment devices and also to making the operation the contactless electronic payment systems robust and failure proof. Attention is now directed to aspects of electronic payment systems related to the physical characteristics of payment devices, and to initialization and anticollision schemes.
SUMMARY OF THE INVENTION
The present invention provides a collision detection and avoidance scheme for processing transactions involving interacting contactless payment cards and card readers in an electronic payment system. The collision detection and avoidance scheme is based on a rule that a transaction is to be processed if and only if one payment card is present in the operating field of the card reader. If more than one card is present in the operating field of the card reader, transaction processing is halted. The scheme requires external intervention to remove excess cards, selection and resubmission of only one card before transaction processing can resume.
In the electronic payment system, the card reader is configured to process transactions when only one card is present in its operating field. The card reader uses collision detection and avoidance algorithms to detect and report instances where multiple cards are present in the operating field.
A collision detection and avoidance algorithm involves investigating the presence of multiple payment cards in the operating field of the card reader and halting processing of the transaction when more than one payment card is present. In the collision detection and avoidance algorithm, a card polling sequence initiated by the reader polls and awaits responses from cards that may be present in the operating field of the card reader. If more than one type of cards are supported by the reader, the polling sequence includes wake-up commands for all supported types of cards.
For example, the polling sequence may include alternating wake-up commands for the ISO 14443 Type A and Type B cards. When only one card is found to be present in the operating field of the card reader, the collision detection and avoidance algorithm identifies the type of the card. The reader may then activate a communication session with the subject card using activation commands appropriate to the identified type of the card. After a transaction with the identified card has been processed, the card is deactivated and removed.
The collision detection and avoidance algorithm uses a binary search technique to detect collisions of ISO 14443 Type A contactless payment cards.
The collision detection and avoidance algorithm employs a Slotted Aloha technique to detect collisions of ISO 14443 Type B contactless payment cards. After one card of a particular type (e.g., Type A or Type B) has been identified as present in the card reader's operating field, polling is conducted for presence of other types of card to check that only one card of any type is present.
Further features of the invention, its nature and various advantages will be more apparent from the accompanying drawings and Appendix and the following detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS AND APPENDIX
FIG. 1 is flow chart illustrating the steps in an exemplary terminal process loop for collision detection and avoidance, in accordance with the principles of the present invention.
FIG. 2 is flow chart illustrating the steps in a generic polling and collision detection process run in a PCD, in accordance with the principles of the present invention.
FIG. 3 is flow chart illustrating the steps in an exemplary detection algorithm 300, which may be used to investigate Type A card collisions in accordance with the principles of the present invention.
Appendix A contains descriptions of a set of commands and responses available to a PCD for polling and collision detection processes and for the activation of a Type A PICC. The set of commands are used in an exemplary implementation of proximity payment card technologies by the assignee MasterCard. The commands and responses described in Appendix A are referred to in FIGS. 2 and 3 and in the following description. The commands available to a PCD for polling and collision detection processes and for activation of a Type B card are similar. For brevity, a description of commands and response for Type B card are not included herein.
DETAILED DESCRIPTION OF THE INVENTION
A collision detection and avoidance scheme for initiating and conducting electronic transactions using a payment card and a card reader is provided.
Initialization describes the requirements for the reader and the card to establish communication when the card is brought into the reader's radio frequency (RF) field.
Collision refers to situations where multiple cards enter the operating volume or field of the reader at the same time, for example, when several store customers in a rush present their cards simultaneously to the reader, or when a customer inadvertently presents a wallet holding several cards to the reader. The reader processes include collision detection processes and alarm generation processes. The alarm generation processes may lead to manual intervention to clear the collision or to user identification of a single card for continued electronic transaction processing. The collision detection and avoidance scheme may be implemented in readers, which support more than one type of cards (e.g., both Type A and Type B cards).
The collision detection and avoidance scheme of the present invention overcomes known drawbacks of conventional anticollision schemes that are used in or recommended for electronic payment systems. The various proximity card standards, which have been used for several contactless card deployments worldwide, generally recommend anticollision processes to deal with the presence of multiple cards in a reader's operating volume or field. For example, ISO 14443 Part 3 recommends anticollision algorithms (loops) to detect and communicate with one particular card when several cards are presented to the same reader. Under ISO 14443 Part 3, the reader first polls and inventories all cards entering its field using polling commands such as Request (REQ) and Answer To Request (ATQ) commands. Then, an anticollision algorithm or loop is used to prepare for dialogue between the reader and one or more selected cards out of the total number of cards responding to a request command. For Type A cards, a binary search algorithm based on the unique identifier (UID) of each card is prescribed. For Type B cards, a Slotted Aloha algorithm with special slot markers is prescribed. The ISO 14443 initialization and anticollision scheme is designed to permit the construction of readers capable of conununication with several cards of the same type, which are powered simultaneously. Both card Types A and B wait silently in the field for a polling command. A multi-protocol reader using the ISO 14443 initialization and anticollision scheme would poll one type (e.g., Type A), complete any transactions with all cards responding, and then poll for the other type (e.g., Type B), and transact with them.
The ISO 14443 anticollision schemes have known drawbacks. For example, the anticollision algorithms can become corrupted if cards enter and/or leave the reader field after they have been inventoried or tallied. Further, concurrent reader communication with a number of cards distributes available power, which is limited, between the cards. Low power availability may affect card functionality. These drawbacks are overcome by the collision detection and avoidance scheme of the present invention.
Recently, assignee MasterCard International Incorporated ("MasterCard") has developed proprietary specifications MasterCard PayPassTM
ISO/IEC 14443 Implementation Specification ("PayPass") for implementation of proximity payment card technologies (e.g., by issuers, vendors or manufacturers of cards and card readers). The inventive anticollision scheme the present invention is described for purposes of illustration in the context of the exemplary PayPass implementation. It will be understood that the selection of the PayPass implementation for purposes of illustration herein is only exemplary, and that the principles of the present invention can be more generally applied to any electronic payment system involving interacting cards and card readers.
The collision detection and avoidance scheme is described with reference to transactions conducted when cards are presented, for example, to a terminal device at a point of transaction (e.g., at a store checkout stand).
The terminal device includes a card reader (PCD) and may include other electronics, transaction processing applications, user interfaces (e.g., display screens) and communication interfaces (e.g., to a host computer). The inventive collision detection and avoidance scheme is based on the rule that only one PICC or card must be detected or sensed in the operating field of the card reader before the card reader or terminal is allowed to initiate or continue any transaction processing. If more than one card is sensed or detected, the scheme requires manual intervention to remove excess cards, selection and resubmission of only one card for processing.
FIG. 1 shows an exemplary terminal process loop 100 for collision detection and avoidance. The terminal process loop may be implemented in the terminal making use of the functionalities located in the card reader device.
In process loop 100, at step 1, the terminal and PCD initiate a polling sequence to detect both Type A and Type B cards that may be present in the PCD operating field.
For this purpose, the PCD may send repeated Type A and Type B wake-up commands to receive acknowledgements from any activated cards present.
At step 3, terminal process 100 assesses the number of cards present.
If only one card is polled, at next step 4 terminal processes 100 identifies the type of the card present, namely Type A or Type B. Then, according to the card type identified A or B, the PCD activates the card at steps 5 or step 8. The terminal then may use suitable terminal applications to process the card transaction (steps 6 or step 9). After the card transaction is completed, the terminal may instruct the PCD
to deactivate the processed card. The processed card is removed from the operating field (steps 7 and 10), allowing terminal process 100 to return to its starting state 0 for a next collision detection and polling sequence.
If step 1 polling results show at step 3 that no cards are present, terminal process 100 returns to its starting state 0 to initiate the next collision detection and polling sequence. If step 1 polling results show that two or more cards are present (i.e., the PCD receives a response from more than one card) then at step 2, the PCD reports a collision to the terminal and resets the cards (i.e. no carrier for a time tRESET). In this case, terminal process 100 does not proceed to process a transaction, but returns to its starting state 0 for the next polling sequence. Step 2 may involve generating alarms or messages alerting operators and/or users to the presence of multiple cards.
The PCD device included in the terminal is configured so that its functions are suitable for implementing the collision detection and avoidance scheme (e.g., terminal process 100). Table I is a list of the exemplary functional requirements for a PCD device, which is configured for implementing terminal process 100.
Table I
1. The PCD shall have only one communication signal interface active during a communication session, i.e. the PCD can communicate via either Type A or Type B interfaces. The PCD shall not mingle the two interfaces except under limited circumstances.
2. The PCD can change from one communication signal interface to another (i.e. Type A to Type B, or vice versa):
During the polling sequence (terminal process 100, step 1) By deactivating the active communication signal interface action using a provided deselection command.
Upon removal of the PICC.
Subsequent sessions may then proceed with either Type A to Type B
modulation method.
3. The PCD shall alternate between modulation methods when idling before detecting the presence of a PICC of Type A or Type B.
4. Once only a single PICC is detected during the polling and collision detection process (i.e., terminal process 100, step 1), the PCD shall activate the detected PICC to initiate the transaction process (i.e., terminal process 100, steps 5 or 8).
5. During the transaction process (i.e., terminal process 100, steps 5-10), the PCD shall not initiate any communication with another PICC.
In terminal process 100, the PCD polls for cards of both Type A and Type B to ensure that there is only one card present in its operating field.
To detect multiple PICCs within the field, the PICC and PCD are required to implement a protocol that detects the condition that more than one PICC are active. Under this protocol, the PCD is the initiating device which initiates PICC communication activity by issuing wake-up commands (WUPA and WUPB, for Type A and Type B
cards, respectively) to prompt the PICCs to respond. When more than one PICC
responds, the terminal will not initiate or proceeds a transaction (see e.g., terminal process 100, step 2).
The collision detection mechanism used by the PCD varies with card type. Type A PICCs use Manchester coding and answer synchronously to wakeup commands. These features allow the PCD to detect a collision at bit level for Type A
PICCs (i.e. a situation where at least two Type A PICCs simultaneously transmit bit patterns with complementary values for one or more bit positions). In this case, the bit patterns merge and the carrier is modulated with the subcarrier for all of the (100%) bit duration. A collision detection algorithm for Type A cards may be based on binary search techniques.
In contrast to the Type A PICCs' synchronous response, Type B PICCs respond asynchronously to wake-up commands. To detect whether more than one Type B PICC is present in the Operating Field, the PCD performs a WUPB command that is set to require all Type B PICCs to respond in the first time slot (N=1).
Responses by more than one Type B PICCs in the first time slot cause a transmission error, which is recognized as an indication of a collision of Type B PICCs.
FIG. 2 shows a PCD process 200 for collision avoidance and polling, which is generic (i.e. applicable to both Type A and Type B cards). PCD
process 200 may be made available to terminal process 100 and may be used, for example, in terminal process 100 steps 1- 3.
In process 200, the PCD probes it operating field by alternately issuing wake-up commands (e.g., WUPA for Type A cards and WUPB for Type B cards), to prompt cards to respond (e.g. steps 10, 70, 110 and 150). The PCD waits a defined time period tp before issuing each alternate WUPA and WUPB command (e.g., steps 60, 90, 100, 140, 170, and 180). At steps 20, 40, 80, 120 and 160, process 200 evaluates responses received to the preceding issued WUPA or WLTPB command. If no response is received to a particular type wake-up command (e.g. WUPB step 70, WUPA step 150), process 200 recognizes that there are either no cards of the particular type in the operating field or that only cards of the other type may be present.
In process 200, if a transmission error is received in response to a WUPA command issued, for example, at step 10, then the PCD assumes there is more than one Type A PICC (i.e. a collision) in the operating field and resorts to exception processing (transmission error). If the PCD receives a valid acknowledgement command (ATQA) from a Type A PICC, the PCD assumes that there is at least one Type A PICC in the operating field and stores the ATQA information before proceeding at step 30 with a Type A collision detection algorithm (e.g., collision detection algorithm 300 FIG. 3). The results of the Type A collision detection algorithm are evaluated at step 40. If the Type A collision detection algorithm 300 detects that more than one Type A PICC is present in the operating field (i.e.
a collision), then the PCD resorts to exception processing (transmission error).
Alternatively, if only one Type A PICC is detected, then the PCD at step 50 issues a command (HALTA) to place the one identified Type A PICC in a halt state.
Similarly in process 200, if a transmission error is received in response to a WUPB command issued, for example, at step 110, then the PCD assumes there is more than one Type B PICC (i.e. a collision) in the operating field and resorts to exception processing (transmission error). If the PCD receives a valid acknowledgement command (ATQB) from a Type B PICC then the PCD assumes there is only one Type B PICC in the operating field and issues a command (HALTB) to place the one identified Type B PICC in a halt state.
After the one identified PICC of either type has been placed in a halt state (e.g., at step 50 or step 130), the PCD issues a wakeup commands at steps 70 and 150 as appropriate for the opposite type of card to foreclose the possibility of collision between two cards of opposite type (i.e. the presence of one Type A PICC and one Type B PICC card) in the operating field. The responses to either of the wake-up commands are evaluated at steps 80 or 160. If the responses are positive, collision is indicated.
FIG. 3 shows an exemplary collison detection algorithm 300, which may be used to investigate Type A card collisions after an ATQA
acknowledgement without bit collision has been received in response to a WUPA command (e.g., at step 30, process 200). For investigating Type A collision, the PCD retrieves the UID from Type A PICC card. If the PCD is able to retrieve the UID of the Type A PICC
card without any bit collision error, then the PCD may conclude that there is only one Type A PICC present in its operating field (e.g., at step 40, process 200).
Collision detection algorithm 300 is utilized to retrieve the UID from the PICC.
At step 310, the PCD starts detection algorithm 300 by sending an ANTICOLLISION command with SEL ='93' (See e.g., Appendix A) to retrieve the complete UID of the Type A PICC and to detect whether more than one PICC of Type A is present in the operating field. If at step 302 the PCD receives a transmission error in the response to the ANTICOLLISION command, then collision is indicated and the PCD resorts exception processing (transmission error). If at step 303, the ATQA shows a single size UID, the complete UID (= UID CLI: uid0 uidl uid2 uid3 BCC) has been retrieved from the PICC. Accordingly, only one Type A
card is present and no collision with other Type A cards in indicated. Then at step 307, the PCD proceeds to put the PICC in the ACTIVE state by sending a SELECT
command with SEL ='93' and UID CL1. At step 308, the PCD stores or memorizes the complete UID
If at step 303, the ATQA shows a double or triple size UID, the PCD
proceeds cascade level-by-cascade level. First at step 304, the PCD selects cascade level 1 by sending a SELECT command with SEL='93' and UID CL I. Then at step 305, the PCD stores or memorizes the UID CL1 before proceeding to cascade level 2.
At step 306, the PCD continues with cascade level 2 by sending an ANTICOLLISION command with SEL ='95'.
Like step 302, if at step 309 the PCD receives a transmission error in the response to the ANTICOLLISION command then collision is indicated, in response to which the PCD resorts exception processing (transmission error).
Similarly, if at step 310 the received ATQA shows a double size UID, the complete UID (=UID CL1: uid0 uidl uid2 BCC; UID CL1: uid3 uid4 uid5 uid6 BCC) has been retrieved from the PICC. Accordingly, only one Type A card is present and no collision with other Type A cards in the operating volume of the reader indicated.
Then at steps 314 and 315, like at steps 307 and 308, the PCD proceeds to put the identified PICC in the ACTIVE state by sending a SELECT command with SEL =
'93' and UID CL 1, and to store or memorize the complete UID.
If at step 310, the ATQA shows a triple size UID, the PCD at step 311 selects cascade level 2 by sending a SELECT command with SEL='95' and UID
CL2. Then at step 312, the PCD stores or memorizes the UID CL2. At step 313, the PCD continues with cascade level 3 by sending an ANTICOLLISION command with SEL ='97'. If at step 316 the PCD detects a transmission error in the response to this ANTICOLLISION command, collision is indicated and the PCD resorts to exception processing (transmission error). If no transmission error-free ATQA command is received from the PICC, the complete UID (= UID CL1: CT uid0 uidl uid2 BCC;
UID CL2: CT uid3 uid4 uid5 BCC; UID CL3: uid6 uid7 uid8 uid9 BCC) has been retrieved from the PICC. Accordingly, only one Type A card is present and no collision with other Type A cards in indicated. Then at steps 317 and 318, like at steps 307 and 308, the PCD proceeds to put the identified PICC in the ACTIVE
state by sending a SELECT command with SEL ='97' and UID CL3, and to store or memorize the complete UID.
After only one card has been identified as being present in the operating field of the reader (e.g., Type B in terminal process 200 step 130, or Type A
in algorithm 300 steps 307 or 314, etc.), the card is activated. The PCD/terminal proceeds to communicate with the activated card and completed the desired transaction. After the desired transaction is completed, the subject card is deactivated.
During terminal process 200 or algorithm 300, when collision is indicated, the PCD resorts to exception processing. No transactions are conducted until the exception is satisfactorily cleared. During the polling and collision detection sequence upon detection of a transmission error indicating collision, the PCD
reports the collision detection to the terminal arid resets the PICC the PCD for a time period tRESET. During this time period tRESET, no carrier signal is transmitted to the PICCs. The PCD returns to the polling and collision detection sequence. The PCD's report of the collision detection to the terminal, can lead to user intervention to clear the multiple cards present in the operating field.
While the present invention has been particularly described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various modifications and alterations may be made without departing from the spirit and scope of the invention. Accordingly, the disclosed embodiments of the invention are considered merely illustrative, and the invention is limited in scope only as specified in the appended claims.
5.1 Type A - Command Set Table 5.1 lists the commands that are available to the PCD for communication with a PICC of Type A. For every command, the corresponding response from the PICC is indicated.
Table 5.1-Type A - Command Set PCD Command PICC Response WUPA ATQA
HLTA -RATS ATS
This chapter details the format of these commands and their responses from the PICC.
5.2 Type A - CRC-A
Some of the commands defined in Table 5.1 include a CRC for error checking.
The CRC_A is defined as a function of k data bits, which consist of all the bits in the command excluding the CRC_A itself. Since all commands using a CRC_A are encoded in bytes, the number of bits k is a multiple of 8.
Figure 5.1 shows how a command with a CRC_A is included within a standard frame. CRC_A1 is the least significant byte and CRC A2 is the most significant byte.
Figure 5.1-Position of CRC-A within a Standard Frame Command + CRC A
Byte I Byte 2 Byte n CRC A 1 CRC A2 I S bl b2 ... b8 P bl b2 ... b8 P bl ... b8 P CRC A1 P CRC A2 P E
Requirements 5.1-CRC A
PCD and PICC
5.2.1.1 If a CRC_A is included in the standard frame, then it shall be inserted in the fiame between the last parity bit of the data bits and the End of Communication (E). Each CRC_A
byte shall be followed by a parity bit. A short frame shall not have a CRC A.
5.2.1.2 The CRC_A is as defmed in [ISO/IEC 132391, but the initial register content shall be '6363' and the register content shall not be inverted after calculation.
5.3 WUPA
The WUPA command is sent by the PCD to probe the field for PICCs of Type A.
5.3.1 WUPA Command The WUPA command is transmitted within a short frame and its coding is specified in Table 5.2.
Table 5.2-Coding of WUPA within a Short Frame b7 b6 b5 b4 b3 b2 b1 Meaning 1 0 1 0 0 1 0 '52' = WUPA
5.3.2 WUPA Response (ATQA) In response to a WUPA command from the PCD, a PICC of Type A, depending on its state (see chapter 7) will return an ATQA with a length of two bytes. The ATQA is transmitted within a standard frame without the CRC_A bytes and coded as specified in Table 5.3 and Table 5.4.
Table 5.3-Byte I of ATQA
b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 UID size: single (4 bytes) 0 1 UID size: double (7 bytes) 1 0 UID size: triple (10 bytes) 1 1 Not allowed 1 0 0 0 0 Bit frame anticollision 0 1 0 0 0 Bit frame anticollision 0 0 1 0 0 Bit frame anticollision 0 0 0 1 0 Bit frame anticollision 0 0 0 0 1 Bit frame anticollision All other values Not allowed 5.6.2 HLTA Response The PICC does not respond to a HLTA command. The PCD always assumes that the HLTA
command has been 'acknowledged' by the PICC.
Requirements 5.8-HLTA Response PCD PICC
5.6.2.1 The PCD shall always consider the 5.6.2.2 The PICC shall not respond to a HLTA
HLTA command as "acknowledged". command.
5.7 Request for Answer to Select (RATS) The RATS command is used by the PCD during the protocol activation sequence to negotiate with the PICC the maximum frame size and the bit rate divisor (D).
5.7.1 RATS Command The RATS command is transmitted within a standard frame including the CRC_A
bytes. Its coding is specified in Table 5.12.
Table 5.12-Coding of RATS Command Byte 1 Byte 2 Byte 3- 4 'EO' PARAM CRC A
PARAM, the parameter byte, consists of two parts (see Table 5.13).
Table 5.13-Format of RATS Parameter Byte (PARAM) b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x FSDI
x x x x CID
The most significant nibble b8 to b5 is called FSDI (Frame Size for proximity coupling Device Integer) and codes FSD (Frame Size for proximity coupling Device). Refer to section 4.3.1 for the definition of FSD. The coding of FSD in terms of FSDI is given in Table 5.14.
Table 5.14-FSDI to FSD Conversion FSDI 10' 11) '2' '3' '4' 151 '61 '71 W '9'-'F' FSD (bytes) 16 24 32 40 48 64 96 128 256 RFU
Requirements 5.9-FSDIMIN
PCD
5.7.1.1 The PCD shall set FSDI equal to FSDIMIN. Refer to Annex A for the value of FSDIMIN.
Requirements 5.10-PICC Handling of RFU values of FSDI
PICC
5.7.1.2 A received value of FSDI ='9'-'F' shall be treated by the PICC as FSDI
='8'.
The least significant nibble b4 to bl is named CID and it defines the logical number of the addressed PICC in the range from 0 to 14. The CID is set to zero as the PCD
only addresses a single PICC at a time.
Requirements 5.11-Support of CID
PCD PICC
5.7.1.3 The PCD shall not use Card Identifier 5.7.1.4 The PICC shall accept a PCD sending a (CID), indicated by setting bl-b4 to RATS command with PARAM CID bits (0000)b. set to (0000)b.
The PICC may support a CID different from (000a)b.
Requirements 5.12-PICC Error Handling of RATS Command PICC
5.7.1.5 The PICC shall consider any RATS command transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
5.7.2 RATS Response (Answer To Select) The Answer To Select (ATS) is transmitted by the PICC in response to the RATS
command. The ATS is transmitted within a standard frame including the CRC_A bytes. This section defines the ATS with all its available fields (see Table 5.15).
Table 5.15-Structure of the ATS
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 - 6+k-1 Byte 6+k - 6+k+1 TL TO TA(l) TB(1) TC(1) T1 ... Tk CRC A
The length byte TL is followed by a variable number of bytes in the following order:
= format byte TO, = interface bytes TA(1), TB(1), TC(1) and = historical bytes TI to Tk.
= Length byte The length byte TL is mandatory and specifies the length of the transmitted ATS including itself. The two CRC bytes are not included in TL.
Requirements 5.13-Length Byte TL of the ATS
PCD PICC
5.7.2.1 The first byte of the ATS (TL) shall specify the length of the ATS
including TL itself. The two CRC
bytes shall not be included in TL.
5.7.2.2 The PCD shall be capable of 5.7.2.3 TL shall not indicate a length greater supporting a PICC returning an ATS than 20 bytes (maximum 15 historical with TL specifying a length less than bytes are allowed as TA(1), TB(1) and or equal to 20 bytes. TC(l) must always be present).
The PCD may support a P1CC returning an ATS
with TL indicating a length greater than 20 bytes.
= Format Byte TO
The format byte TO is coded as specified in Table 5.16.
Table 5.16-Coding of Format Byte TO
b8 b7 b6 b5 b4 b3 b2 b1 Meaning x TC(1) is transmitted, if bit is set to 1 x TB(1) is transmitted, if bit is set to I
x TA(l) is transmitted, if bit is set to I
x x x x FSCI
The least significatit nibble b4 to bl is called FSCI (Frame Size for proximity Card Integer) and codes FSC (Frame Size for proximity Card). Refer to section 4.3.2 for the definition of FSC. The coding of FSC in terms of FSCI is specified in Table 5.17. The default value of FSCI is 2 and leads to a FSC of 32 bytes..
Table 5.17--FSCI to FSC Conversion FSCI 10' 11) '2' '3' '4' 45) W '7$ '8' 49'-'F' FSC (bytes) 16 24 32 40 48 64 96 128 256 RFU
Requirements 5.14-FSCIM,N
PICC
5.7.2.4 The PICC shall set FSCI greater than or equal to FSCIMIN with a maximum value of 8.
Refer to Annex A for the value of FSCIMIN.
Requirements 5.15-PCD Handling of RFU values of FSCI
PCD
5.7.2.5 A received value of FSCI ='9'-'F' shall be treated by the PCD as FSCI
='8'.
Requirements 5.16-Format Byte TO of the ATS
PCD PICC
5.7.2.6 The PCD shall be capable of supporting 5.7.2.7 TA(l), TB(l) and TC(l) shall be a PICC returning an ATS including TO, present in the ATS and the presence TA(l), TB(l) and TC(l). If one or shall be indicated in TO.
more of the fields TO, TA(1), TB(l) and TC(l) are missing, then the PCD shall use the default values as specified in this section.
= Interface Byte TA(1) The interface byte TA(1) conveys information to define the bit rate capabilities of the PICC.
The interface byte TA(1) is coded as specified in Table 5.18. The bits b7 to b5 code the bit rate capability of the PICC for the direction from PICC to PCD (Dplcc->PCD)=
The default value for the bits b7 to b5 is (000)b. The bits b3 to b l code the bit rate capability of the PICC for the direction from PCD to PICC (DPCD-1,PICC). The default value for the bits b3 to b 1 is (000)b.
Table 5.18-Coding of Interface Byte TA(1) b8 b7 b6 b5 b4 b3 b2 b1 Meaning x If b8 =(1)b, then only the same bit rate divisor for both directions is supported (Dp1cc-+rcD=DPcwPjcc)=
If bS =(0)b, then a different bit rate divisor for each direction is supported.
x DeIcc-~PCD = 8 supported, if bit is set to (1)b.
x Dr1cc--WcD =4 supported, if bit is set to (1)b.
x DPlcc-,acD =2 supported, if bit is set to (1)b.
x DPCn-+Picc =8 supported, if bit is set to (1)b.
x Drcn-.rIcc =4 supported, if bit is set to (1)b.
x DPCD-aP-cc =2 supported, if bit is set to (1)b.
Requirements 5.17-Format Byte TA(1) of the ATS
PCD PICC
The PCD may support higher bit rates. 5.7.2.8 The PICC shall set TA(l) equal to '80', indicating that it supports only a bit rate of 106 kbits/s in both directions.
= Interface Byte TB(1) The interface byte TB(1) conveys infonnation to define the Frame Waiting Time (FWT) and the Start-up Frame Guard Time (SFGT). The interface byte TB(1) is coded as specified in Table 5.19.
Table 5.19-Coding of Interface Byte TB(1) b8 b7 b6 b5 b4 0 b2 b1 Meaning x x x x FWI
x x x x SFGI
- The most significant nibble b8 to b5 is called FWI (Frame Waiting time Integer) and codes FWT. Refer to section 4.2.3 for the definition of FWT. The default value of FWI is 4 and leads to a FWT of 512 etu.
- The least significant nibble b4 to bl codes SFGI (Start-up Frame Guard time Integer) and shall be used by the PICC to code a multiplier value used to define the SFGT.
Refer to section 4.2.2 for the definition of SFGT. The default value of SFGI is 0.
Requirements 5.18-Interface Byte TB(1) of the ATS
PCD PICC
5.7.2.9 The PICC shall set FWI less than or equal to FWIMAx. Refer to Annex A
for the value of FWIMroc.
5.7.2.10 The PCD shall be capable of 5.7.2.11 The PICC shall set SFGI less than or supporting a PICC returning an ATS equal to SFGImAx. Refer to Annex A
with TB(l) indicating an SFGI less for the value of SFGImAx.
than or equal to SFGImAx.
The PCD may support a PICC with an SFGI
greater than SFGImAx.
= Interface Byte TC(1) The interface byte TC(1) indicates whether Node Addressing (NAD) and Card Identifier (CID) are supported by the PICC. The interface byte TC(1) is coded as specified in Table 5.20.
Table 5.20-Coding of Interface Byte TC(1) b8 b7 b6 b5 b4 b3 b2 bi Meaning x CID supported, if bit is set to (1)b x NAD supported, if bit is set to (1)b The bits b2 and bl shall be used by the PICC to define which optional fields in the prologue field it supports. Bit b 1 set to 1 indicates NAD supported; b2 set to 1 indicates CID supported.
Refer to section 10.2 for the specification of the prologue field.
Requirements 5.19-Interface Byte TC(1) of the ATS
PCD PICC
5.7.2.12 The PCD shall not use Card Identifier The PICC may support Card Identifier (CID) (CID) or Node Addressing (NAD) and and/or Node Addressing (NAD).
shall disregard any value returned by the PICC in b1-b2 ofTC(1).
= Historical Bytes The historical bytes T1 to Tk are optional and shall be used by the PICC to designate general information. The maximum length of the ATS gives the maximum possible number of historical bytes.
Requirements 5.20-Historical Bytes of the ATS
PCD PICC
5.7.2.13 The PCD shall allow the PICC to send 5.7.2.14 The PICC shall send no more than 15 at least 15 historical bytes. historical bytes. The number of the A PCD may support an A TS with more than 15 historical bytes shall be in line with the length byte TL and the presence of historical bytes. TA(1), TB(1) and TC(1).
Table 5.6-Coding of SEL
b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 0 0 1 0 0 1 1 '93': ANTICOLLISION CL1 1 0 0 1 0 1 0 1 '95': ANTICOLLISION CL2 1 0 0 1 0 1 1 1 '97': ANTICOLLISION CL3 1 0 0 1 other values except those Not allowed here above With the SEL byte the Cascade Level (CL) of the UID requested by the ANTICOLLISION
command is defined.
5.4.2 ANTICOLLISION Response (UID CLn) In response to the ANTICOLLISION command all PICCs in the Operating Field transmit the requested cascade level of their UID (UID CLn, with n=1, 2 or 3). The UID of a Type A PICC
consists of 4, 7 or 10 bytes. The length of the response is always 5 bytes.
The coding of the response is depending on the value of the SEL byte and the length of the UID.
The ANTICOLLISION response is transmitted within a standard frame without the CRC_A bytes. Its coding is specified in Table 5.7.
Table 5.7-UID CLn SEL UID Size Response (UID CLn) '93' 4 UID CL1: uido uid, uid2 uid3 BCC
'93' > 4 UID CL 1: CT uida uid, uid2 BCC
'95' 7 UID CL2: uid3 uid4 uid5 uid6 BCC
'95' > 7 UID CL2: CT uid3 uid4 uid5 BCC
'97' 10 UID CL3: uid6 uid7 uid8 uid9 BCC
Where:
= CT is the cascade tag with a value of '88'. The purpose of the cascade tag is to force a collision with PICCs that have a smaller UID size. Therefore, uido of a single size UID and uid3 of a double size UID must not have the value '88'.
= BCC is the UID CLn check byte. BCC is calculated as exclusive-or over the 4 previous bytes.
= uidõ is the n'h byte of the complete UID with uido the most significant byte.
Requirements 5.4-PCD Handling of BCC
PCD
5.4.2.1 The PCD shall verify the BCC included in the UID CLn. The PCD shall consider an incorrect BCC as a transmission error.
5.4.2.2 The PCD shall consider any UID CLn transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
Table 5.4---Byte 2 of ATQA
b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x Any value Requirements 5.2-PCD Handling of ATQA
PCD
5.3.2.1 The PCD shall disregard any value returned by the PICC in the least significant nibble b4 to bl of byte 2 of the ATQA.
5.3.2.2 The PCD shall consider any ATQA transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
Requirements 5.3-UID Length PCD PICC
5.3.2.3 The PCD shall be capable of success- 5.3.2.4 The PICC shall have a fixed UID of 4, 7 fully recovering a UID of 4, 7 or 10 or 10 bytes.
bytes.
5.4 ANTICOLLISION
The ANTICOLLISION command is used to obtain the complete UID of a Type A PICC
and to detect whether more than one PICC of Type A is in the Operating Field of the PCD (see section 9.2.3 for more details).
5.4.1 ANTICOLLISION Command The ANTICOLLISION command is transmitted within a standard frame without the CRC_A
bytes. Its coding is specified in Table 5.5.
Table 5.5--Coding of ANTICOLLISION Command Byte I Byte 2 SEL '20' The SEL byte is coded as shown in Table 5.6.
5.5 SELECT
The SELECT command is used to select the Type A PICC using its UID.
5.5.1 SELECT Command The SELECT command is transmitted within a standard frame including the CRC_A
bytes. Its coding is specified in Table 5.8.
Table 5.8-Coding of SELECT Command Byte I Byte 2 Bytes 3 - 7 Bytes 8 - 9 SEL '70' UID CLn CRC-A
The SEL byte is coded as is shown in Table 5.9.
Table 5.9-Coding of SEL
b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 0 0 1 0 0 1 1 '93': SELECT CL I
1 0 0 1 0 1 0 1 '95': SELECT CL2 1 0 0 1 0 1 1 1 '97': SELECT CL3 1 0 0 1 Other values except those Not allowed here above The coding of UID CLn is depending on the value of the SEL byte and the size of the UID. The coding is the same as for the ANTICOLLISION response and specified in Table 5.7.
Requirements 5.5-PICC Error Handling of SELECT Command PICC
5.5.1.1 The PICC shall consider any SELECT command transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
5.5.2 Response - Select Acknowledge - SAK
The SAK is transmitted by the PICC in response to a SELECT command when all the data bits match with the UID CLn of the PICC. The length of the SAK is one byte and transmitted to the PCD within a standard frame including the CRC_A bytes. The SAK is coded as specified in Table 5.10.
Table 5.10-Coding of SAK
b8 b7 b6 b5 b4 b3 b2 b1 Meaning x PICC compliant with ISO/IEC 14443-4 if bit is set to (1)b x Cascade bit: UID not complete if bit is set to (1)b Requirements 5.6-Type A PICC compliance with ISO/IEC 14443-4 PCD PICC
5.5.2.1 The PCD shall support a PICC indicating 5.5.2.2 The PICC shall be conformity to ISO/IEC 14443-4. compliant. This means that the PICC
The PCD may support a P1CC not indicating shall indicate conformity to ISO/IEC
conformity to ISO 14443-4. 14443-4 to the PCD by setting b6 of the SAK to (1)b:
Requirements 5.7-PCD Error Handling of SAK Response PCD
5.5.2.3 The PCD shall consider any SAK transmitted in a valid frame (no transmission error) but having a coding not compliant with this specification as a protocol error.
5.6 H LTA
The HLTA command is used to put the PICC in the HALT state (see chapter 7).
5.6.1 HLTA Command The HLTA command consists of two bytes and is transmitted within a standard frame including the CRC_A bytes. Table 5.11 specifies the coding of the HLTA command.
Table 5.11-Coding of HLTA Command Byte 1 Byte 2 Byte 3- 4 650' '00' CRC A
Claims (20)
1. An electronic payment system for processing a contactless payment card transaction, the electronic payment system comprising a card reader which is configured to process the transaction when only one card is present in the card reader's operating field, wherein the card reader deploys collision detection algorithms to detect and report a collision instance in which multiple cards are present in the card reader's operating field, and wherein the card reader halts processing the transaction in the instance a collision is detected.
2. The electronic payment system of claim 1 further comprising a terminal to which the card reader is coupled, the terminal comprising transaction-processing applications.
3. The electronic payment system of claim 1 wherein the collision detection algorithm includes the steps of detecting collisions of a first type of cards and detecting collisions of the first type of cards and a second type of cards.
4. The electronic payment system of claim 1 wherein the card reader is configured to alternately poll a first type of cards and a second type of cards.
5. The electronic payment system of claim 4 wherein the card reader is configured to identify the type of the only one card present in the card reader's operating field, and accordingly activate the card for a communication session.
6. The electronic payment system of claim 1 wherein the card reader has a plurality of communication signal interfaces corresponding to different card types, and wherein the card reader is configured to have only a communication signal interface corresponding to a single card type active during a communication session.
7. The electronic payment system of claim 1 wherein the card reader is configured to deactivate the only one card present in the card reader's operating field upon processing the transaction.
8. The electronic payment system of claim 1 wherein the card reader deploys a collision detection algorithm comprising a binary search routine to detect collisions of ISO 14443 Type A contactless payment cards.
9. The electronic payment system of claim 1 wherein the card reader wherein the card reader deploys a collision detection algorithm comprising a Slotted Aloha routine to detect collisions of ISO 14443 Type B contactless payment cards.
10. The electronic payment system of claim 1 wherein the card reader deploys a collision detection algorithm by which after one card of a type has been identified as present in the card reader's operating field, the card reader polls for the presence of another type of card.
11. A collision detection and avoidance method for processing a transaction involving a contactless payment card and a card reader in a system of interacting contactless payment cards and card readers, the method comprising the steps of:
(a) investigating the presence of payment cards in an operating field of the card reader;
(b) in response to step (a), processing the transaction involving the contactless payment card and the card reader if and only if the contactless payment card is the only card present in the operating field of the card reader; and (c) halting processing of the transaction when more than one payment card is present in the operating field of the card reader.
(a) investigating the presence of payment cards in an operating field of the card reader;
(b) in response to step (a), processing the transaction involving the contactless payment card and the card reader if and only if the contactless payment card is the only card present in the operating field of the card reader; and (c) halting processing of the transaction when more than one payment card is present in the operating field of the card reader.
12. The collision detection and avoidance method of claim 11 wherein the interacting contactless payment cards comprise a first type of card and a second type of cards, and wherein step (a) comprises using a polling sequence to detect the presence of both types of cards.
13. The collision detection and avoidance method of claim 12 wherein polling sequence comprises alternating wake-up commands for the first Type And the second type of cards.
14. The collision detection and avoidance method of claim 12 wherein step (a) comprises identifying the type of card present, when only one card is found to be present in the operating field of the card reader.
15. The collision detection and avoidance method of claim 14 wherein step (b) comprises activating a communication session between the identified only one card and the card reader according to the type of the card to initiate processing of a transaction..
16. The collision detection and avoidance method of claim 15, wherein the card reader is coupled to terminal which is configured with transaction processing applications, wherein steps (a)-(c) are directed by a terminal process, and wherein step (b) comprises using a terminal transaction processing application to process the transaction.
17. The collision detection and avoidance method of claim 15, further comprising deactivating the card after processing the transaction.
18. The collision detection and avoidance method of claim 11 wherein step (a) comprises using a binary search algorithm to detect collisions of ISO 14443 Type A
contactless payment cards.
contactless payment cards.
19. The collision detection and avoidance method of claim 11 wherein step (a) comprises using a Slotted Aloha algorithm to detect collisions of ISO 14443 Type B
contactless payment cards.
contactless payment cards.
20. The collision detection and avoidance method of claim 11 wherein step (a) comprises, after one card of a type has been identified as present in the card reader's operating field, polling for the presence of another type of card.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US58827004P | 2004-07-15 | 2004-07-15 | |
US60/588,270 | 2004-07-15 | ||
PCT/US2005/025317 WO2006020144A2 (en) | 2004-07-15 | 2005-07-15 | Collision detection and avoidance scheme for contactless card payment systems |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2573795A1 true CA2573795A1 (en) | 2006-02-23 |
Family
ID=35907917
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002573805A Abandoned CA2573805A1 (en) | 2004-07-15 | 2005-07-15 | Payment card signal characterization methods and circuits |
CA002573799A Abandoned CA2573799A1 (en) | 2004-07-15 | 2005-07-15 | Contactless payment card reader with a frusto-conical operating volume |
CA002573814A Abandoned CA2573814A1 (en) | 2004-07-15 | 2005-07-15 | Method and system for conducting contactless payment card transactions |
CA002573773A Abandoned CA2573773A1 (en) | 2004-07-15 | 2005-07-15 | Reference equipment for testing contactless payment devices |
CA002573795A Abandoned CA2573795A1 (en) | 2004-07-15 | 2005-07-15 | Collision detection and avoidance scheme for contactless card payment systems |
Family Applications Before (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002573805A Abandoned CA2573805A1 (en) | 2004-07-15 | 2005-07-15 | Payment card signal characterization methods and circuits |
CA002573799A Abandoned CA2573799A1 (en) | 2004-07-15 | 2005-07-15 | Contactless payment card reader with a frusto-conical operating volume |
CA002573814A Abandoned CA2573814A1 (en) | 2004-07-15 | 2005-07-15 | Method and system for conducting contactless payment card transactions |
CA002573773A Abandoned CA2573773A1 (en) | 2004-07-15 | 2005-07-15 | Reference equipment for testing contactless payment devices |
Country Status (12)
Country | Link |
---|---|
US (6) | US7717346B2 (en) |
EP (5) | EP1782332A2 (en) |
JP (5) | JP2008507044A (en) |
KR (5) | KR20070039143A (en) |
CN (5) | CN101052961A (en) |
AU (5) | AU2005275058A1 (en) |
BR (5) | BRPI0513357A (en) |
CA (5) | CA2573805A1 (en) |
IL (5) | IL180700A0 (en) |
MX (5) | MX2007000538A (en) |
WO (5) | WO2006020144A2 (en) |
ZA (4) | ZA200701124B (en) |
Families Citing this family (196)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9020854B2 (en) | 2004-03-08 | 2015-04-28 | Proxense, Llc | Linked account system using personal digital key (PDK-LAS) |
BRPI0513357A (en) * | 2004-07-15 | 2008-05-06 | Mastercard International Inc | contactless payment device system and method for increasing the interoperability of a payment transmission device |
CA2591751A1 (en) | 2004-12-20 | 2006-06-29 | Proxense, Llc | Biometric personal data key (pdk) authentication |
KR101059872B1 (en) * | 2005-01-03 | 2011-08-29 | 삼성전자주식회사 | Communication collision prevention protocol using unique identifier |
US7506813B2 (en) * | 2005-01-06 | 2009-03-24 | Quad/Graphics, Inc. | Resonator use in the print field |
FR2881007B1 (en) * | 2005-01-19 | 2007-02-23 | Gemplus Sa | ESTABLISHING COMMUNICATION BETWEEN NON-CONTACT DEVICES |
US7581678B2 (en) * | 2005-02-22 | 2009-09-01 | Tyfone, Inc. | Electronic transaction card |
WO2007038743A2 (en) * | 2005-09-28 | 2007-04-05 | Visa International Service Association | Device, system and method for reducing an interaction time for a contactless transaction |
US8219129B2 (en) | 2006-01-06 | 2012-07-10 | Proxense, Llc | Dynamic real-time tiered client access |
US11206664B2 (en) | 2006-01-06 | 2021-12-21 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network |
US8985436B2 (en) * | 2006-01-18 | 2015-03-24 | Symbol Technologies, Inc. | Peer-to-peer radio frequency communications for management of RFID readers |
US7904718B2 (en) | 2006-05-05 | 2011-03-08 | Proxense, Llc | Personal digital key differentiation for secure transactions |
WO2007143740A2 (en) * | 2006-06-08 | 2007-12-13 | Mastercard International Incorporated | All-in-one proximity payment device with local authentication |
US7958291B2 (en) * | 2006-10-10 | 2011-06-07 | Atmel Rousset S.A.S. | Supplemental communication interface |
ATE534968T1 (en) * | 2006-10-12 | 2011-12-15 | Nxp Bv | DEVICE, SYSTEM AND METHOD FOR COMPENSATING SIGNAL DELAYS IN AN RFID COMMUNICATIONS SYSTEM |
US9269221B2 (en) | 2006-11-13 | 2016-02-23 | John J. Gobbi | Configuration of interfaces for a location detection system and application |
US8281990B2 (en) | 2006-12-07 | 2012-10-09 | Smart Systems Innovations, Llc | Public transit system fare processor for transfers |
US8763902B2 (en) | 2006-12-07 | 2014-07-01 | Smart Systems Innovations, Llc | Mass transit fare processing system |
US7991158B2 (en) * | 2006-12-13 | 2011-08-02 | Tyfone, Inc. | Secure messaging |
CN101617330A (en) * | 2006-12-19 | 2009-12-30 | 运城有限公司 | The transaction system of in authorising cashless transactions, using |
US8052055B2 (en) * | 2007-01-31 | 2011-11-08 | Hewlett-Packard Development Company, L.P. | Method and system for perturbing multi-radio-frequency-identification-tag-reader networks to increase interrogation efficiency |
US20080244208A1 (en) * | 2007-03-30 | 2008-10-02 | Narendra Siva G | Memory card hidden command protocol |
US7845568B2 (en) * | 2007-05-09 | 2010-12-07 | Atmel Rousset S.A.S. | Managing power and timing in a smart card device |
US9038914B2 (en) * | 2007-07-05 | 2015-05-26 | Mastercard International Corporation | Method and system for simulating a proximity-based transaction device |
WO2009006635A1 (en) * | 2007-07-05 | 2009-01-08 | Mastercard International Incorporated | Method and system for detecting a signal generated by a proximity-based transaction device |
JP4977543B2 (en) * | 2007-07-20 | 2012-07-18 | 日本電気通信システム株式会社 | Control device, control system, control method, and control program |
JP5260908B2 (en) | 2007-07-20 | 2013-08-14 | 日本電気通信システム株式会社 | Control device, communication device, control system, control method, and control program |
US20090070691A1 (en) * | 2007-09-12 | 2009-03-12 | Devicefidelity, Inc. | Presenting web pages through mobile host devices |
US8659427B2 (en) | 2007-11-09 | 2014-02-25 | Proxense, Llc | Proximity-sensor supporting multiple application services |
JP4420296B2 (en) * | 2007-11-19 | 2010-02-24 | フェリカネットワークス株式会社 | Information processing apparatus, information processing method, and program |
US8171528B1 (en) | 2007-12-06 | 2012-05-01 | Proxense, Llc | Hybrid device having a personal digital key and receiver-decoder circuit and methods of use |
US9741027B2 (en) * | 2007-12-14 | 2017-08-22 | Tyfone, Inc. | Memory card based contactless devices |
US9251332B2 (en) | 2007-12-19 | 2016-02-02 | Proxense, Llc | Security system and method for controlling access to computing resources |
US8381980B2 (en) * | 2008-01-09 | 2013-02-26 | Nxp B.V. | Evaluating an electromagnetic field strength of an electromagnetic gate apparatus |
US8508336B2 (en) * | 2008-02-14 | 2013-08-13 | Proxense, Llc | Proximity-based healthcare management system with automatic access to private information |
WO2009113827A2 (en) | 2008-03-12 | 2009-09-17 | 한국전자통신연구원 | Rfid interrogator retransmitting command depending on collision situation and control method thereof |
KR20090097784A (en) * | 2008-03-12 | 2009-09-16 | 한국전자통신연구원 | Rfid interrogator with a collision diagnostics function and method for controlling of the same |
US11120449B2 (en) | 2008-04-08 | 2021-09-14 | Proxense, Llc | Automated service-based order processing |
EP2131313A1 (en) | 2008-06-02 | 2009-12-09 | Gemplus | Method for selecting an application in a mobile wireless communication device in an NFC system and corresponding mobile wireless communication device |
US8451122B2 (en) | 2008-08-08 | 2013-05-28 | Tyfone, Inc. | Smartcard performance enhancement circuits and systems |
US7961101B2 (en) * | 2008-08-08 | 2011-06-14 | Tyfone, Inc. | Small RFID card with integrated inductive element |
KR101039449B1 (en) * | 2008-11-25 | 2011-06-07 | 엘지엔시스(주) | Method for testing PBPR using a damaged type of financial contract information |
CN101739583B (en) * | 2008-11-26 | 2013-04-10 | 国民技术股份有限公司 | Radio frequency SIM card, radio frequency card reader and magnetic induction control method for radio frequency communication |
US8630584B2 (en) | 2008-11-26 | 2014-01-14 | Nationz Technologies Inc. | RF SIM card, card reader, and communication method |
DE102009009846A1 (en) | 2009-02-20 | 2010-09-02 | Bundesdruckerei Gmbh | Improved card reader for contactless readable cards and method of operating such a card reader |
US8231061B2 (en) * | 2009-02-24 | 2012-07-31 | Tyfone, Inc | Contactless device with miniaturized antenna |
CN101833817B (en) * | 2009-03-11 | 2014-08-13 | 中兴通讯股份有限公司 | Method and terminal for realizing application selection in non-contact electronic payment |
JP5169937B2 (en) * | 2009-03-25 | 2013-03-27 | 株式会社デンソー | Portable machine |
US8485436B2 (en) * | 2009-04-06 | 2013-07-16 | Mastercard International Incorporated | Simulated contactless identification card reader |
US8135354B2 (en) * | 2009-06-02 | 2012-03-13 | Symbol Technologies, Inc. | Method and system for chopped antenna impedance measurements with an RFID radio |
US20110007843A1 (en) * | 2009-07-07 | 2011-01-13 | Broadcom Corporation | Low power fm transmitter |
CN102004892B (en) * | 2009-08-31 | 2014-03-26 | 鸿富锦精密工业(深圳)有限公司 | Multi-function card reader testing device and method |
SK288555B6 (en) * | 2009-11-14 | 2018-05-02 | Smk Corporation | Method and system of data transmission from the transponder to the reader, especially in payment solutions with a mobile communication device |
CN101742469B (en) * | 2009-11-24 | 2012-05-30 | 候万春 | System and method for controlling mobile phone RFID non-contact transaction attribution |
JP5304615B2 (en) * | 2009-11-26 | 2013-10-02 | 株式会社デンソーウェーブ | Non-contact communication device |
US9418205B2 (en) | 2010-03-15 | 2016-08-16 | Proxense, Llc | Proximity-based system for automatic application or data access and item tracking |
CN102215050B (en) | 2010-04-02 | 2014-03-19 | 国民技术股份有限公司 | Detection method for radio-frequency SIM (Subscriber Identity Module) card collision with low-frequency magnetic communication |
US9322974B1 (en) | 2010-07-15 | 2016-04-26 | Proxense, Llc. | Proximity-based system for object tracking |
CN102468988A (en) * | 2010-11-11 | 2012-05-23 | 上海华虹集成电路有限责任公司 | Device for automatically detecting signal protocol type in international standardization organization/international electrotechnical commission (ISO/IEC) 14443 protocol |
CN102479308B (en) * | 2010-11-23 | 2014-10-08 | 上海华虹宏力半导体制造有限公司 | Radio frequency identification anti-collision circuit and realizing method thereof |
FR2968804B1 (en) * | 2010-12-13 | 2013-01-04 | St Microelectronics Rousset | METHOD FOR MANAGING THE DIALOGUE BETWEEN EQUIPMENT AND AT LEAST ONE MULTI-APPLICATION OBJECT SUCH AS A CONTACTLESS CHIP CARD AND CORRESPONDING OBJECT |
US8857716B1 (en) | 2011-02-21 | 2014-10-14 | Proxense, Llc | Implementation of a proximity-based system for object tracking and automatic application initialization |
DE102011103740A1 (en) * | 2011-05-31 | 2012-12-06 | Smartrac Ip B.V. | A method and arrangement for providing and managing information associated with RFID media in a network |
CN102982294B (en) * | 2011-09-05 | 2015-12-02 | 国民技术股份有限公司 | A kind of collision detection method utilizing magnetic two-way communication |
US9020427B2 (en) | 2012-02-29 | 2015-04-28 | Verifone, Inc. | Point of sale device and method for operating same |
CN102622565A (en) * | 2012-03-06 | 2012-08-01 | 无锡儒安科技有限公司 | Processing method and device for detecting and preventing electronic tag collision |
US8690412B2 (en) * | 2012-03-15 | 2014-04-08 | Apple Inc. | Backlight structures and backlight assemblies for electronic device displays |
KR101363566B1 (en) * | 2012-09-14 | 2014-02-17 | 주식회사 터치웍스 | Apparatus and method for generating unique identity of radio frequency |
US9852419B2 (en) * | 2012-09-17 | 2017-12-26 | Capital One Financial Corporation | Systems and methods for providing near field communications |
DE102014000934B4 (en) | 2013-01-21 | 2022-12-01 | Giesecke+Devrient Mobile Security Gmbh | Flexible chip card holder |
US9405898B2 (en) | 2013-05-10 | 2016-08-02 | Proxense, Llc | Secure element as a digital pocket |
US9323964B2 (en) * | 2013-08-20 | 2016-04-26 | Cubic Corporation | Card detection and selection |
US9014323B2 (en) * | 2013-08-30 | 2015-04-21 | Nxp B.V. | Clock synchronizer for aligning remote devices |
CN104636771A (en) * | 2013-11-12 | 2015-05-20 | 上海华虹集成电路有限责任公司 | Non-contact module testing circuit and method |
EP3071281B1 (en) * | 2013-11-21 | 2019-07-03 | Jet Medical, Inc. | System for facilitating intranasal guidance |
CN103761492A (en) * | 2013-12-10 | 2014-04-30 | 上海动联信息技术股份有限公司 | Method of non-contact device for carrying out operation on multiple cards on the basis of 13.56 MHz working frequency |
US10503939B2 (en) * | 2014-12-24 | 2019-12-10 | Intel Corporation | Method and apparatus for energy harvest from a proximity coupling device |
CN104484636A (en) * | 2014-12-31 | 2015-04-01 | 深圳市科漫达智能管理科技有限公司 | Data reading method and device |
US20160300087A1 (en) | 2015-04-13 | 2016-10-13 | Phitek Systems Limited | Communications system for aircraft |
CN105608480B (en) * | 2015-08-04 | 2019-05-07 | 电子科技大学 | Ultrahigh frequency RFID signal scanner |
US11295293B2 (en) * | 2016-01-07 | 2022-04-05 | Worldpay, Llc | Point of interaction device emulation for payment transaction simulation |
US11188893B2 (en) * | 2016-01-15 | 2021-11-30 | Mastercard International Incorporated | Access control bypass on mobile for mass transit |
US11734669B2 (en) * | 2016-01-15 | 2023-08-22 | Mastercard International Incorporated | Access control bypass on mobile for mass transit |
CN106934310B (en) * | 2017-02-24 | 2019-09-13 | 飞天诚信科技股份有限公司 | A kind of method and card reader of testing smart card |
CN107403118A (en) * | 2017-07-06 | 2017-11-28 | 上海动联信息技术股份有限公司 | The test suite and method of a kind of card reader |
EP3493097B1 (en) * | 2017-11-29 | 2021-03-24 | ams AG | Method for supplying energy wirelessly by means of radio frequency identification, rfid, and rfid system |
CN108021957B (en) * | 2017-12-05 | 2021-07-23 | 深圳市艾特智能科技有限公司 | Anti-collision method and system, readable storage medium and card reading device |
CN108038397B (en) * | 2017-12-15 | 2021-01-01 | 神思电子技术股份有限公司 | Test device and method for read-write timing of RFID reader-writer |
CN108288008B (en) * | 2018-02-08 | 2021-12-28 | 飞天诚信科技股份有限公司 | Card activation method and device |
US10546444B2 (en) | 2018-06-21 | 2020-01-28 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
CN109033906A (en) * | 2018-07-27 | 2018-12-18 | 天津科畅慧通信息技术有限公司 | A kind of device and method for testing RFID sensitivity |
US10511443B1 (en) | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072575A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072474A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
SG11202102798TA (en) | 2018-10-02 | 2021-04-29 | Capital One Services Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072550A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10949520B2 (en) | 2018-10-02 | 2021-03-16 | Capital One Services, Llc | Systems and methods for cross coupling risk analytics and one-time-passcodes |
US10607214B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10505738B1 (en) | 2018-10-02 | 2019-12-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10542036B1 (en) | 2018-10-02 | 2020-01-21 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072537A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
CA3115084A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
AU2019354421A1 (en) | 2018-10-02 | 2021-04-29 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
SG11202102543WA (en) | 2018-10-02 | 2021-04-29 | Capital One Services Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072687A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10783519B2 (en) | 2018-10-02 | 2020-09-22 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10554411B1 (en) | 2018-10-02 | 2020-02-04 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
KR20210068391A (en) | 2018-10-02 | 2021-06-09 | 캐피탈 원 서비시즈, 엘엘씨 | System and method for cryptographic authentication of contactless card |
US11210664B2 (en) | 2018-10-02 | 2021-12-28 | Capital One Services, Llc | Systems and methods for amplifying the strength of cryptographic algorithms |
US10579998B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771253B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
CA3115064A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
US10592710B1 (en) | 2018-10-02 | 2020-03-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072552A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10565587B1 (en) | 2018-10-02 | 2020-02-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10581611B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10733645B2 (en) | 2018-10-02 | 2020-08-04 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US10909527B2 (en) | 2018-10-02 | 2021-02-02 | Capital One Services, Llc | Systems and methods for performing a reissue of a contactless card |
KR102638750B1 (en) | 2018-11-22 | 2024-02-22 | 삼성전자주식회사 | Operating method of electronic device performing near field communication functions |
US20200226581A1 (en) | 2019-01-11 | 2020-07-16 | Capital One Services, Llc | Systems and methods for touch screen interface interaction using a card overlay |
US11037136B2 (en) | 2019-01-24 | 2021-06-15 | Capital One Services, Llc | Tap to autofill card data |
US11120453B2 (en) | 2019-02-01 | 2021-09-14 | Capital One Services, Llc | Tap card to securely generate card data to copy to clipboard |
US10467622B1 (en) | 2019-02-01 | 2019-11-05 | Capital One Services, Llc | Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms |
US10510074B1 (en) | 2019-02-01 | 2019-12-17 | Capital One Services, Llc | One-tap payment using a contactless card |
US10425129B1 (en) | 2019-02-27 | 2019-09-24 | Capital One Services, Llc | Techniques to reduce power consumption in near field communication systems |
US10523708B1 (en) | 2019-03-18 | 2019-12-31 | Capital One Services, Llc | System and method for second factor authentication of customer support calls |
US10438437B1 (en) | 2019-03-20 | 2019-10-08 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
US10535062B1 (en) | 2019-03-20 | 2020-01-14 | Capital One Services, Llc | Using a contactless card to securely share personal data stored in a blockchain |
US10643420B1 (en) | 2019-03-20 | 2020-05-05 | Capital One Services, Llc | Contextual tapping engine |
US10984416B2 (en) | 2019-03-20 | 2021-04-20 | Capital One Services, Llc | NFC mobile currency transfer |
US10970712B2 (en) | 2019-03-21 | 2021-04-06 | Capital One Services, Llc | Delegated administration of permissions using a contactless card |
US10467445B1 (en) | 2019-03-28 | 2019-11-05 | Capital One Services, Llc | Devices and methods for contactless card alignment with a foldable mobile device |
US11521262B2 (en) | 2019-05-28 | 2022-12-06 | Capital One Services, Llc | NFC enhanced augmented reality information overlays |
CN110245533B (en) * | 2019-06-11 | 2022-08-23 | 北京聚利科技有限公司 | Cascade type card reader, card reading method, system and storage medium |
US10516447B1 (en) | 2019-06-17 | 2019-12-24 | Capital One Services, Llc | Dynamic power levels in NFC card communications |
US11694187B2 (en) | 2019-07-03 | 2023-07-04 | Capital One Services, Llc | Constraining transactional capabilities for contactless cards |
US10871958B1 (en) | 2019-07-03 | 2020-12-22 | Capital One Services, Llc | Techniques to perform applet programming |
US11392933B2 (en) | 2019-07-03 | 2022-07-19 | Capital One Services, Llc | Systems and methods for providing online and hybridcard interactions |
US10713649B1 (en) | 2019-07-09 | 2020-07-14 | Capital One Services, Llc | System and method enabling mobile near-field communication to update display on a payment card |
US10885514B1 (en) | 2019-07-15 | 2021-01-05 | Capital One Services, Llc | System and method for using image data to trigger contactless card transactions |
US10498401B1 (en) | 2019-07-15 | 2019-12-03 | Capital One Services, Llc | System and method for guiding card positioning using phone sensors |
US10733601B1 (en) | 2019-07-17 | 2020-08-04 | Capital One Services, Llc | Body area network facilitated authentication or payment authorization |
US10832271B1 (en) | 2019-07-17 | 2020-11-10 | Capital One Services, Llc | Verified reviews using a contactless card |
US11182771B2 (en) | 2019-07-17 | 2021-11-23 | Capital One Services, Llc | System for value loading onto in-vehicle device |
US11521213B2 (en) | 2019-07-18 | 2022-12-06 | Capital One Services, Llc | Continuous authentication for digital services based on contactless card positioning |
US10506426B1 (en) | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
US10541995B1 (en) | 2019-07-23 | 2020-01-21 | Capital One Services, Llc | First factor contactless card authentication system and method |
JP2023503795A (en) | 2019-10-02 | 2023-02-01 | キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー | Client Device Authentication Using Contactless Legacy Magnetic Stripe Data |
US10885410B1 (en) | 2019-12-23 | 2021-01-05 | Capital One Services, Llc | Generating barcodes utilizing cryptographic techniques |
US11651361B2 (en) | 2019-12-23 | 2023-05-16 | Capital One Services, Llc | Secure authentication based on passport data stored in a contactless card |
US10733283B1 (en) | 2019-12-23 | 2020-08-04 | Capital One Services, Llc | Secure password generation and management using NFC and contactless smart cards |
US11615395B2 (en) | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
US11113685B2 (en) | 2019-12-23 | 2021-09-07 | Capital One Services, Llc | Card issuing with restricted virtual numbers |
FR3105663B1 (en) | 2019-12-23 | 2022-09-09 | St Microelectronics Rousset | Setting up a transaction in a contactless electronic device |
FR3105662B1 (en) | 2019-12-23 | 2021-11-26 | St Microelectronics Rousset | Setting up a transaction in an electronic contactless device |
US10657754B1 (en) | 2019-12-23 | 2020-05-19 | Capital One Services, Llc | Contactless card and personal identification system |
US10862540B1 (en) | 2019-12-23 | 2020-12-08 | Capital One Services, Llc | Method for mapping NFC field strength and location on mobile devices |
US10664941B1 (en) | 2019-12-24 | 2020-05-26 | Capital One Services, Llc | Steganographic image encoding of biometric template information on a card |
US11200563B2 (en) | 2019-12-24 | 2021-12-14 | Capital One Services, Llc | Account registration using a contactless card |
US10853795B1 (en) | 2019-12-24 | 2020-12-01 | Capital One Services, Llc | Secure authentication based on identity data stored in a contactless card |
US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
US10757574B1 (en) | 2019-12-26 | 2020-08-25 | Capital One Services, Llc | Multi-factor authentication providing a credential via a contactless card for secure messaging |
US11038688B1 (en) | 2019-12-30 | 2021-06-15 | Capital One Services, Llc | Techniques to control applets for contactless cards |
US10860914B1 (en) | 2019-12-31 | 2020-12-08 | Capital One Services, Llc | Contactless card and method of assembly |
US11455620B2 (en) | 2019-12-31 | 2022-09-27 | Capital One Services, Llc | Tapping a contactless card to a computing device to provision a virtual number |
US11210656B2 (en) | 2020-04-13 | 2021-12-28 | Capital One Services, Llc | Determining specific terms for contactless card activation |
US10861006B1 (en) | 2020-04-30 | 2020-12-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US10915888B1 (en) | 2020-04-30 | 2021-02-09 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US11222342B2 (en) | 2020-04-30 | 2022-01-11 | Capital One Services, Llc | Accurate images in graphical user interfaces to enable data transfer |
US11030339B1 (en) | 2020-04-30 | 2021-06-08 | Capital One Services, Llc | Systems and methods for data access control of personal user data using a short-range transceiver |
US11823175B2 (en) | 2020-04-30 | 2023-11-21 | Capital One Services, Llc | Intelligent card unlock |
US10963865B1 (en) | 2020-05-12 | 2021-03-30 | Capital One Services, Llc | Augmented reality card activation experience |
US11063979B1 (en) | 2020-05-18 | 2021-07-13 | Capital One Services, Llc | Enabling communications between applications in a mobile operating system |
US11100511B1 (en) | 2020-05-18 | 2021-08-24 | Capital One Services, Llc | Application-based point of sale system in mobile operating systems |
US11062098B1 (en) | 2020-08-11 | 2021-07-13 | Capital One Services, Llc | Augmented reality information display and interaction via NFC based authentication |
US11482312B2 (en) | 2020-10-30 | 2022-10-25 | Capital One Services, Llc | Secure verification of medical status using a contactless card |
US11165586B1 (en) | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11373169B2 (en) | 2020-11-03 | 2022-06-28 | Capital One Services, Llc | Web-based activation of contactless cards |
WO2022108583A1 (en) * | 2020-11-18 | 2022-05-27 | Intercard, Inc. | Systems and methods for a dual-read single card scanner |
KR102561434B1 (en) * | 2020-11-30 | 2023-08-02 | 선문대학교 산학협력단 | Card Recognition Sterilizing Apparatus |
US11216799B1 (en) | 2021-01-04 | 2022-01-04 | Capital One Services, Llc | Secure generation of one-time passcodes using a contactless card |
US11682012B2 (en) | 2021-01-27 | 2023-06-20 | Capital One Services, Llc | Contactless delivery systems and methods |
US11792001B2 (en) | 2021-01-28 | 2023-10-17 | Capital One Services, Llc | Systems and methods for secure reprovisioning |
US11562358B2 (en) | 2021-01-28 | 2023-01-24 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
US11687930B2 (en) | 2021-01-28 | 2023-06-27 | Capital One Services, Llc | Systems and methods for authentication of access tokens |
US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
US11777933B2 (en) | 2021-02-03 | 2023-10-03 | Capital One Services, Llc | URL-based authentication for payment cards |
US11637826B2 (en) | 2021-02-24 | 2023-04-25 | Capital One Services, Llc | Establishing authentication persistence |
US11245438B1 (en) | 2021-03-26 | 2022-02-08 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11935035B2 (en) | 2021-04-20 | 2024-03-19 | Capital One Services, Llc | Techniques to utilize resource locators by a contactless card to perform a sequence of operations |
US11902442B2 (en) | 2021-04-22 | 2024-02-13 | Capital One Services, Llc | Secure management of accounts on display devices using a contactless card |
US11354555B1 (en) | 2021-05-04 | 2022-06-07 | Capital One Services, Llc | Methods, mediums, and systems for applying a display to a transaction card |
CN113872643B (en) * | 2021-12-03 | 2022-03-29 | 广州搏创信息科技有限公司 | Anti-collision command processing and responding device |
Family Cites Families (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4066873A (en) | 1976-01-26 | 1978-01-03 | The First National Bank Of Chicago | Identification and access card with associated optical decoding means |
JPS61201390A (en) | 1985-03-04 | 1986-09-06 | Casio Comput Co Ltd | Ic card |
FR2586428B1 (en) * | 1985-08-26 | 1988-11-25 | Pasteur Institut | POLYPEPTIDES AND ANTIBODIES, CHARACTERISTICS OF PAPILLOMAVIRUS AND THEIR APPLICATIONS TO IN VITRO DIAGNOSIS, PREVENTION AND / OR CONTROL OF PAPILLOMAVIRUS INFECTIONS |
US5880452A (en) * | 1990-11-15 | 1999-03-09 | Geo Labs, Inc. | Laser based PCMCIA data collection system with automatic triggering for portable applications and method of use |
US5225977A (en) | 1991-03-18 | 1993-07-06 | Hooper John B | Card payment system for service dispensing devices |
GB9105851D0 (en) | 1991-03-20 | 1991-05-08 | Security Systems Consortium Th | Securing financial transactions |
US5466919A (en) | 1993-04-02 | 1995-11-14 | Hovakimian; Henry | Credit/charge card system enabling purchasers to contribute to selected charities |
US5511111A (en) * | 1993-11-01 | 1996-04-23 | Engineering And Business Systems, Inc. | Caller name and identification communication system with caller screening option |
US5623552A (en) | 1994-01-21 | 1997-04-22 | Cardguard International, Inc. | Self-authenticating identification card with fingerprint identification |
US5511114A (en) | 1994-06-06 | 1996-04-23 | Call Processing, Inc. | Telephone pre-paid calling card system and method |
US5602744A (en) | 1994-09-29 | 1997-02-11 | Meek; Jean L. | Universal send/receive utility usage data gathering system |
JPH08123919A (en) * | 1994-10-28 | 1996-05-17 | Mitsubishi Electric Corp | Noncontact ic card system and communication method thereof |
US5748737A (en) * | 1994-11-14 | 1998-05-05 | Daggar; Robert N. | Multimedia electronic wallet with generic card |
US5625628A (en) * | 1995-03-15 | 1997-04-29 | Hughes Electronics | Aloha optimization |
US6010074A (en) * | 1996-04-01 | 2000-01-04 | Cubic Corporation | Contactless proximity automated data collection system and method with collision resolution |
US6466131B1 (en) * | 1996-07-30 | 2002-10-15 | Micron Technology, Inc. | Radio frequency data communications device with adjustable receiver sensitivity and method |
DE19635311A1 (en) * | 1996-09-02 | 1998-03-12 | Angewandte Digital Elektronik | Adaptive identification of contactless chip cards |
US6150955A (en) * | 1996-10-28 | 2000-11-21 | Tracy Corporation Ii | Apparatus and method for transmitting data via a digital control channel of a digital wireless network |
GB2319698B (en) * | 1996-11-21 | 2001-08-08 | Motorola Inc | Method for communicating with a plurality of contactless data carriers and contactless data carrier for use therein |
US6119940A (en) | 1997-02-18 | 2000-09-19 | Unisys Corporation | Identification methods |
US6112981A (en) * | 1997-02-25 | 2000-09-05 | Dresser Industries, Inc. | Bar code reader for a fuel dispenser |
GB9719583D0 (en) | 1997-09-16 | 1997-11-19 | Ncr Int Inc | A method of authenticating a magnetic card |
US6810304B1 (en) | 1997-09-26 | 2004-10-26 | Gilbarco Inc. | Multistage ordering system for a fueling and retail environment |
US6134309A (en) * | 1997-09-30 | 2000-10-17 | Creative Games International, Inc. | Pre-paid phone card system with promotional link |
US6061344A (en) * | 1998-02-19 | 2000-05-09 | Micron Technology, Inc. | Method of addressing messages and communications system |
US6072801A (en) * | 1998-02-19 | 2000-06-06 | Micron Technology, Inc. | Method of addressing messages, method of establishing wireless communications, and communications system |
US6315195B1 (en) | 1998-04-17 | 2001-11-13 | Diebold, Incorporated | Transaction apparatus and method |
US6710701B2 (en) | 1998-04-22 | 2004-03-23 | Gilbarco Inc. | Rfid tag location using tag or host interaction record |
DE19830526A1 (en) * | 1998-07-08 | 2000-01-13 | Orga Kartensysteme Gmbh | Method and device for controlling communication between a terminal and a number of chip cards |
US6297789B2 (en) | 1998-07-09 | 2001-10-02 | Tyco Electronics Corporation | Integrated circuit card with liquid crystal display for viewing at least a portion of the information stored in the card |
US6404643B1 (en) | 1998-10-15 | 2002-06-11 | Amerasia International Technology, Inc. | Article having an embedded electronic device, and method of making same |
US6577229B1 (en) | 1999-06-10 | 2003-06-10 | Cubic Corporation | Multiple protocol smart card communication device |
JP3824451B2 (en) * | 1999-07-29 | 2006-09-20 | 富士通株式会社 | Non-contact IC card presence / absence detection circuit |
WO2001013338A1 (en) * | 1999-08-11 | 2001-02-22 | Mark Iv Industries Limited | Method and means for rf toll collection |
JP2001076117A (en) | 1999-08-31 | 2001-03-23 | Toppan Forms Co Ltd | Advantageous card |
US6145742A (en) | 1999-09-03 | 2000-11-14 | Drexler Technology Corporation | Method and system for laser writing microscopic data spots on cards and labels readable with a CCD array |
US7889052B2 (en) * | 2001-07-10 | 2011-02-15 | Xatra Fund Mx, Llc | Authorizing payment subsequent to RF transactions |
US6394346B1 (en) * | 1999-10-07 | 2002-05-28 | Cubic Corporation | Contactless smart card high production encoding machine |
WO2001031555A1 (en) | 1999-10-28 | 2001-05-03 | Gould David B | Prepaid cash equivalent card and system |
DE10055602A1 (en) * | 1999-12-30 | 2001-07-12 | Ibm | Exit control system for supermarket or department store, produces receipt based on contactlessly received information and updates payment status |
FR2809251B1 (en) * | 2000-05-17 | 2003-08-15 | St Microelectronics Sa | DEVICE FOR PRODUCING AN ELECTROMAGNETIC FIELD FOR A TRANSPONDER |
KR100486754B1 (en) * | 2000-08-31 | 2005-05-03 | 매그나칩 반도체 유한회사 | Radio Frequency Identification Tag System for preventing collision and collision preventing method thereof |
US20020046116A1 (en) | 2000-09-08 | 2002-04-18 | William Hohle | System and method for loyalty program distribution and settlement |
FR2815490B1 (en) * | 2000-10-16 | 2006-07-07 | Inside Technologies | CONTACTLESS INTEGRATED CIRCUIT READER |
US7253717B2 (en) * | 2000-11-29 | 2007-08-07 | Mobile Technics Llc | Method and system for communicating with and tracking RFID transponders |
JP2002351685A (en) * | 2001-05-22 | 2002-12-06 | Sankyo Seiki Mfg Co Ltd | Data updating method and controller for nonvolatile memory |
US6666982B2 (en) * | 2001-10-22 | 2003-12-23 | Tokyo Electron Limited | Protection of dielectric window in inductively coupled plasma generation |
JP2003162755A (en) | 2001-11-27 | 2003-06-06 | Great Information Kk | Prepaid card information issuing system, call tariff settling system, and value settling system |
US7011250B2 (en) * | 2001-12-20 | 2006-03-14 | Matsushita Electric Industrial Co., Ltd. | IC card reader/writer, identification method and program |
US7792759B2 (en) * | 2002-07-29 | 2010-09-07 | Emv Co. Llc | Methods for performing transactions in a wireless environment |
KR100560770B1 (en) * | 2003-09-15 | 2006-03-13 | 삼성전자주식회사 | Contactless integrated circuit card with real-time protocol switching function and card system including the same |
US20050222961A1 (en) * | 2004-04-05 | 2005-10-06 | Philippe Staib | System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device |
BRPI0513357A (en) * | 2004-07-15 | 2008-05-06 | Mastercard International Inc | contactless payment device system and method for increasing the interoperability of a payment transmission device |
US7817014B2 (en) * | 2004-07-30 | 2010-10-19 | Reva Systems Corporation | Scheduling in an RFID system having a coordinated RFID tag reader array |
KR101059872B1 (en) * | 2005-01-03 | 2011-08-29 | 삼성전자주식회사 | Communication collision prevention protocol using unique identifier |
US7274284B2 (en) * | 2005-02-04 | 2007-09-25 | Atmel Corporation | Method for RF card detection in a contactless system |
US20060273176A1 (en) * | 2005-06-03 | 2006-12-07 | Actividentity, Inc. | Blocking contactless personal security device |
JP4584082B2 (en) * | 2005-09-05 | 2010-11-17 | ソニー・エリクソン・モバイルコミュニケーションズ株式会社 | Reader / writer and communication method |
-
2005
- 2005-07-15 BR BRPI0513357-2A patent/BRPI0513357A/en not_active IP Right Cessation
- 2005-07-15 MX MX2007000538A patent/MX2007000538A/en not_active Application Discontinuation
- 2005-07-15 JP JP2007521665A patent/JP2008507044A/en not_active Abandoned
- 2005-07-15 CA CA002573805A patent/CA2573805A1/en not_active Abandoned
- 2005-07-15 AU AU2005275058A patent/AU2005275058A1/en not_active Abandoned
- 2005-07-15 US US11/182,355 patent/US7717346B2/en active Active
- 2005-07-15 MX MX2007000541A patent/MX2007000541A/en not_active Application Discontinuation
- 2005-07-15 US US11/182,354 patent/US7424977B2/en not_active Expired - Fee Related
- 2005-07-15 KR KR1020077003736A patent/KR20070039143A/en not_active Application Discontinuation
- 2005-07-15 CN CNA2005800285096A patent/CN101052961A/en active Pending
- 2005-07-15 EP EP05772297A patent/EP1782332A2/en not_active Withdrawn
- 2005-07-15 AU AU2005275051A patent/AU2005275051B2/en not_active Ceased
- 2005-07-15 US US11/182,358 patent/US7422157B2/en not_active Expired - Fee Related
- 2005-07-15 CN CNA2005800285081A patent/CN101080729A/en active Pending
- 2005-07-15 US US11/182,357 patent/US7431217B2/en not_active Expired - Fee Related
- 2005-07-15 AU AU2005274851A patent/AU2005274851A1/en not_active Abandoned
- 2005-07-15 JP JP2007521702A patent/JP2008507047A/en not_active Abandoned
- 2005-07-15 JP JP2007521661A patent/JP2008507042A/en not_active Abandoned
- 2005-07-15 WO PCT/US2005/025317 patent/WO2006020144A2/en active Application Filing
- 2005-07-15 JP JP2007521695A patent/JP2008507046A/en not_active Abandoned
- 2005-07-15 CN CNA2005800284731A patent/CN101023434A/en active Pending
- 2005-07-15 BR BRPI0513356-4A patent/BRPI0513356A/en not_active IP Right Cessation
- 2005-07-15 CA CA002573799A patent/CA2573799A1/en not_active Abandoned
- 2005-07-15 MX MX2007000544A patent/MX2007000544A/en not_active Application Discontinuation
- 2005-07-15 WO PCT/US2005/025220 patent/WO2006020072A2/en active Application Filing
- 2005-07-15 JP JP2007521662A patent/JP2008507043A/en not_active Abandoned
- 2005-07-15 EP EP05773435A patent/EP1784760A2/en not_active Withdrawn
- 2005-07-15 EP EP05771603A patent/EP1810213A2/en not_active Withdrawn
- 2005-07-15 BR BRPI0513354-8A patent/BRPI0513354A/en not_active IP Right Cessation
- 2005-07-15 EP EP05772281A patent/EP2113104A2/en not_active Withdrawn
- 2005-07-15 WO PCT/US2005/025110 patent/WO2006019990A2/en active Application Filing
- 2005-07-15 CN CNA2005800285895A patent/CN101014968A/en active Pending
- 2005-07-15 KR KR1020077003734A patent/KR20070039142A/en not_active Application Discontinuation
- 2005-07-15 WO PCT/US2005/025119 patent/WO2006019997A2/en active Application Filing
- 2005-07-15 MX MX2007000546A patent/MX2007000546A/en not_active Application Discontinuation
- 2005-07-15 AU AU2005275050A patent/AU2005275050A1/en not_active Abandoned
- 2005-07-15 KR KR1020077003735A patent/KR20070044016A/en not_active Application Discontinuation
- 2005-07-15 CA CA002573814A patent/CA2573814A1/en not_active Abandoned
- 2005-07-15 BR BRPI0513349-1A patent/BRPI0513349A/en not_active IP Right Cessation
- 2005-07-15 WO PCT/US2005/025107 patent/WO2006019989A2/en active Application Filing
- 2005-07-15 CA CA002573773A patent/CA2573773A1/en not_active Abandoned
- 2005-07-15 AU AU2005274949A patent/AU2005274949A1/en not_active Abandoned
- 2005-07-15 KR KR1020077003733A patent/KR20070044453A/en not_active Application Discontinuation
- 2005-07-15 CN CNA2005800285861A patent/CN101305381A/en active Pending
- 2005-07-15 BR BRPI0513358-0A patent/BRPI0513358A/en not_active IP Right Cessation
- 2005-07-15 EP EP05773431A patent/EP1807789A2/en not_active Withdrawn
- 2005-07-15 US US11/182,356 patent/US7520435B2/en not_active Expired - Fee Related
- 2005-07-15 KR KR1020077003737A patent/KR20070039144A/en not_active Application Discontinuation
- 2005-07-15 MX MX2007000542A patent/MX2007000542A/en not_active Application Discontinuation
- 2005-07-15 CA CA002573795A patent/CA2573795A1/en not_active Abandoned
-
2007
- 2007-01-14 IL IL180700A patent/IL180700A0/en unknown
- 2007-01-14 IL IL180696A patent/IL180696A0/en unknown
- 2007-01-14 IL IL180699A patent/IL180699A0/en unknown
- 2007-01-14 IL IL180697A patent/IL180697A0/en unknown
- 2007-01-14 IL IL180695A patent/IL180695A0/en unknown
- 2007-02-07 ZA ZA200701124A patent/ZA200701124B/en unknown
- 2007-02-07 ZA ZA200701122A patent/ZA200701122B/en unknown
- 2007-02-07 ZA ZA200701125A patent/ZA200701125B/en unknown
- 2007-02-07 ZA ZA200701121A patent/ZA200701121B/en unknown
-
2008
- 2008-04-08 US US12/099,460 patent/US7775445B2/en active Active
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7717346B2 (en) | Collision detection and avoidance scheme for contactless card payment systems | |
US6732923B2 (en) | Radio frequency identification system and method | |
US20140061306A1 (en) | Pairing method for wireless scanner via rfid | |
US9762291B2 (en) | Methods and apparatus for consumer testing of an NFC device | |
CN103198337A (en) | Encoded information reading terminal with item locate functionality | |
US20060283940A1 (en) | Multifunctional card reader | |
US11250406B2 (en) | Split transaction physical payment instrument | |
KR100809941B1 (en) | System and Method for Processing Information, Devices for Processing Information and Program Recording Medium | |
MX2007009643A (en) | Techniques to reduce false alarms, invalid security deactivation, and internal theft |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FZDE | Discontinued |