WO2000039684A1 - Method and system for testing an integrated circuit card terminal - Google Patents

Method and system for testing an integrated circuit card terminal Download PDF

Info

Publication number
WO2000039684A1
WO2000039684A1 PCT/US1999/031131 US9931131W WO0039684A1 WO 2000039684 A1 WO2000039684 A1 WO 2000039684A1 US 9931131 W US9931131 W US 9931131W WO 0039684 A1 WO0039684 A1 WO 0039684A1
Authority
WO
WIPO (PCT)
Prior art keywords
integrated circuit
circuit card
card terminal
terminal
testing
Prior art date
Application number
PCT/US1999/031131
Other languages
French (fr)
Inventor
Bruno Beyls
Arnaud Du Chene
Original Assignee
Europay International S.A.
Mastercard International Incorporated
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Europay International S.A., Mastercard International Incorporated filed Critical Europay International S.A.
Priority to AU22199/00A priority Critical patent/AU2219900A/en
Publication of WO2000039684A1 publication Critical patent/WO2000039684A1/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms 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/10Mechanisms 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/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment 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/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms 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/0806Details of the card
    • G07F7/0833Card having specific functional components
    • G07F7/084Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis

Definitions

  • IC card and other bank card terminals have been tested by executing an actual terminal application program on a terminal and interfacing the terminal under test with a test device, which provides response messages to the terminal.
  • the terminal has traditionally been tested as a whole.
  • a disadvantage to the traditional method for testing an IC card terminal is that each time a terminal application is updated or each time a different terminal application is installed, the terminal must be retested with the new terminal application. Moreover, if a terminal application only supports or uses a subset of a communications protocol, the terminal cannot be tested for compliance with the entire communications protocol set.
  • a method for testing an integrated circuit card terminal that includes: identifying the interface module of the integrated circuit card terminal; and executing a test program in the integrated circuit card terminal which loops back, through the interface module, messages received by the integrated circuit card terminal.
  • the present invention may be used for the type approval process of an IC card terminal.
  • a “type approval process” refers to the process or processes followed to test a product for compliance with certain specifications.
  • Fig. 1 is a functional block diagram of a test system according to a preferred embodiment of the present invention.
  • Fig. 2 is a flow chart of a test method according to a preferred embodiment of the present invention.
  • Fig. 3 is a flow chart of a test program for a lower tester according to a preferred embodiment of the present invention.
  • Fig. 1 is a functional block diagram of a test system according to a preferred embodiment of the present invention.
  • the system of Fig. 1 includes an upper tester 10, an implementation under test (IUT) 20, and a lower tester 30.
  • IUT implementation under test
  • the upper tester 10 is a test program that executes on a terminal.
  • terminal refers to any device that is able to communicate with IC cards.
  • the IUT 20 is the interface module of a terminal.
  • the interface module includes the hardware and software of a terminal that handles the interfacing and communications with IC cards, including implementation of the communications protocol used to communicate with the IC cards.
  • the lower tester 30 is any commercially available test device or system that can interface with an IC card terminal.
  • the portion of the terminal that comprises the interface module must be identified.
  • the identification is preferably performed by the manufacturer of the terminal. Once identified, it is possible for the test program to communicate with the interface module by writing to and reading from appropriate memory addresses, I/O ports, and/or hardware registers.
  • Fig. 2 is a flow chart of a test method according to a preferred embodiment of the present invention.
  • the method of Fig. 2 assumes the testing of a terminal compliant with the EMV '96 Integrated Circuit Card Terminal Specification for Payment Systems, Version 3.1.1, May 1998, (hereinafter the "EMV Terminal Specification"), available at www.emvco.org, which is incorporated by reference herein in its entirety.
  • EMV Terminal Specification EMV Terminal Specification
  • the EMV '96 Integrated Circuit Card Application Specification for Payment Systems, Version 3 J ⁇ , May 1998 also available at www.emvco.org, may also be consulted.
  • These specifications are also incorporated herein by reference in their entireties.
  • step 100 of Fig. 2 after the terminal is powered on and initialized, the test program waits for the terminal to detect that an IC card has been inserted. Once an IC card has been detected, the test program waits 10 seconds in step 110.
  • the EMV Power-Up (activation) sequence is then executed in step 120.
  • step 130 it is determined whether the terminal successfully completed the EMV Power-Up sequence (i.e., whether the IC card conforms to the EMV specifications). If the EMV Power-Up sequence was not successfully completed, the EMV Power-Down (de- activation) sequence is executed in step 140.
  • the test program sends a predefined or default command message to the IC card through the interface module.
  • a command message is referred to as a Command Application Protocol Data Unit (C-ADPU).
  • the default C-ADPU is a SELECT Payment System Environment ADPU, which (as defined in the EMV specifications) comprises "00A404000E” + «1PAY.SYS.DDF01» + "00" (where the values in quotation marks are in hexadecimal notation).
  • the test program waits for a response message to be received by the terminal.
  • a response message is referred to as a Response Application Protocol Data Unit (R-ADPU).
  • step 180 it is determined whether an incorrect or no response was received. If an incorrect or no response was received, the test program returns to step 160 and resends the default C- ADPU. If an appropriate response was received, it is then determined in step 190 whether the R-ADPU is less than six bytes in length. If the R-ADPU is less than six bytes in length, it cannot be used (in conformance with the EMV specifications) as a command message. Accordingly, the test program returns to step 160 and resends the default C-ADPU. If the R-ADPU is at least six bytes in length, in step 200 it is determined whether the second byte (the instruction or "INS" byte in EMV terminology) has the value "70".
  • the second byte the instruction or "INS" byte in EMV terminology
  • the EMV Power-Down sequence is executed in step 140. If the INS byte does not have a value of "70”, then the status word of the R-ADPU is stripped and the remaining bytes of the R-ADPU are sent as the next C-ADPU.
  • test program If the test program encounters an error and powers down in step 140, the test program then waits for the IC card to be withdrawn in step 150. Once the IC card is withdrawn, the test program returns to step 100.
  • the test program of Fig. 2 loops back the response message through the interface module as the next command message.
  • This loop-back enables the interface module to be tested independently of any particular application program which is run on the terminal.
  • the loop-back method allows the interface module to be tested more exhaustively than if a terminal were tested as a whole with a particular application running thereon.
  • the lower tester 30 is used to receive the command messages from the IC card terminal and to provide the response messages to the IC card terminal.
  • the lower tester 30 may be any commercially available test device or system that can interface with an IC card terminal.
  • Fig. 3 shows an exemplary embodiment of a test application that may be executed on the lower tester 30, for use with the test method of Fig. 2.
  • step 300 a set of predefined responses is stored in the lower tester 30.
  • the number of predefined responses is stored in the variable number _responses and the variable current response is set to the value "1".
  • the test application waits for a command message from the IC card terminal.
  • step 330 when a command is received, the response in the set corresponding to the value of the variable current response is sent to the IC card terminal. For example, if current _response is "1", then the first response in the set is sent. The variable current response is then incremented by one in step 340. In step 350, if current response is greater than number _responses, current _response is reset to "1". Essentially, the test application cycles through the set of responses, one response after the other.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Tests Of Electronic Circuits (AREA)

Abstract

There is provided a method for testing an integrated circuit card terminal, including identifying the interface module of the integrated circuit card terminal, and executing a test program in the integrated circuit card terminal which loops back, through the interface module, messages received by the integrated circuit card terminal.

Description

METHOD AND SYSTEM FOR TESTING AN INTEGRATED CIRCUIT
CARD TERMINAL
SPECIFICATION
BACKGROUND OF THE INVENTION This invention relates to a method and system for testing an integrated circuit
("IC") card terminal.
Traditionally, IC card and other bank card terminals have been tested by executing an actual terminal application program on a terminal and interfacing the terminal under test with a test device, which provides response messages to the terminal. Thus, the terminal has traditionally been tested as a whole.
A disadvantage to the traditional method for testing an IC card terminal is that each time a terminal application is updated or each time a different terminal application is installed, the terminal must be retested with the new terminal application. Moreover, if a terminal application only supports or uses a subset of a communications protocol, the terminal cannot be tested for compliance with the entire communications protocol set.
Accordingly, there exists a need for a method of testing an IC card terminal which allows an IC card terminal to be tested independently of any particular terminal application running thereon. Moreover, it would be desirable to have a method of testing an IC card terminal that would allow more exhaustive testing for compliance with a communications protocol set than the traditional testing method.
SUMMARY OF INVENTION The present invention satisfies the above-mentioned needs. In one embodiment of the present invention, there is provided a method for testing an integrated circuit card terminal that includes: identifying the interface module of the integrated circuit card terminal; and executing a test program in the integrated circuit card terminal which loops back, through the interface module, messages received by the integrated circuit card terminal.
Advantageously, the present invention may be used for the type approval process of an IC card terminal. As used in this specification and the appended claims, a "type approval process" refers to the process or processes followed to test a product for compliance with certain specifications.
BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings in which:
Fig. 1 is a functional block diagram of a test system according to a preferred embodiment of the present invention;
Fig. 2 is a flow chart of a test method according to a preferred embodiment of the present invention; and
Fig. 3 is a flow chart of a test program for a lower tester according to a preferred embodiment of the present invention.
DETAILED DESCRIPTION
Fig. 1 is a functional block diagram of a test system according to a preferred embodiment of the present invention. The system of Fig. 1 includes an upper tester 10, an implementation under test (IUT) 20, and a lower tester 30.
The upper tester 10 is a test program that executes on a terminal. As used in this specification and the appended claims, the term "terminal" refers to any device that is able to communicate with IC cards. The IUT 20 is the interface module of a terminal. The interface module includes the hardware and software of a terminal that handles the interfacing and communications with IC cards, including implementation of the communications protocol used to communicate with the IC cards. The lower tester 30 is any commercially available test device or system that can interface with an IC card terminal.
Before the interface module can be tested, the portion of the terminal that comprises the interface module must be identified. The identification is preferably performed by the manufacturer of the terminal. Once identified, it is possible for the test program to communicate with the interface module by writing to and reading from appropriate memory addresses, I/O ports, and/or hardware registers.
Fig. 2 is a flow chart of a test method according to a preferred embodiment of the present invention. The method of Fig. 2 assumes the testing of a terminal compliant with the EMV '96 Integrated Circuit Card Terminal Specification for Payment Systems, Version 3.1.1, May 1998, (hereinafter the "EMV Terminal Specification"), available at www.emvco.org, which is incorporated by reference herein in its entirety. For background purposes, the EMV '96 Integrated Circuit Card Specification for Payment Systems, Version 3JJ, May 1998, and the EMV '96 Integrated Circuit Card Application Specification for Payment Systems, Version 3 J Λ , May 1998, also available at www.emvco.org, may also be consulted. These specifications are also incorporated herein by reference in their entireties. The present invention, however, is not limited to terminals compliant with the EMV specifications. In step 100 of Fig. 2, after the terminal is powered on and initialized, the test program waits for the terminal to detect that an IC card has been inserted. Once an IC card has been detected, the test program waits 10 seconds in step 110. The EMV Power-Up (activation) sequence is then executed in step 120. In step 130, it is determined whether the terminal successfully completed the EMV Power-Up sequence (i.e., whether the IC card conforms to the EMV specifications). If the EMV Power-Up sequence was not successfully completed, the EMV Power-Down (de- activation) sequence is executed in step 140. If the EMV Power-Up sequence is successfully completed, the test program sends a predefined or default command message to the IC card through the interface module. In the terminology of the EMV specifications, a command message is referred to as a Command Application Protocol Data Unit (C-ADPU). The default C-ADPU is a SELECT Payment System Environment ADPU, which (as defined in the EMV specifications) comprises "00A404000E" + «1PAY.SYS.DDF01» + "00" (where the values in quotation marks are in hexadecimal notation). In step 170, the test program waits for a response message to be received by the terminal. In the terminology of the EMV specifications, a response message is referred to as a Response Application Protocol Data Unit (R-ADPU). In step 180, it is determined whether an incorrect or no response was received. If an incorrect or no response was received, the test program returns to step 160 and resends the default C- ADPU. If an appropriate response was received, it is then determined in step 190 whether the R-ADPU is less than six bytes in length. If the R-ADPU is less than six bytes in length, it cannot be used (in conformance with the EMV specifications) as a command message. Accordingly, the test program returns to step 160 and resends the default C-ADPU. If the R-ADPU is at least six bytes in length, in step 200 it is determined whether the second byte (the instruction or "INS" byte in EMV terminology) has the value "70". If the INS byte has a value of "70", then the EMV Power-Down sequence is executed in step 140. If the INS byte does not have a value of "70", then the status word of the R-ADPU is stripped and the remaining bytes of the R-ADPU are sent as the next C-ADPU.
If the test program encounters an error and powers down in step 140, the test program then waits for the IC card to be withdrawn in step 150. Once the IC card is withdrawn, the test program returns to step 100.
In sum, the test program of Fig. 2 loops back the response message through the interface module as the next command message. This loop-back enables the interface module to be tested independently of any particular application program which is run on the terminal. In addition, the loop-back method allows the interface module to be tested more exhaustively than if a terminal were tested as a whole with a particular application running thereon.
The lower tester 30 is used to receive the command messages from the IC card terminal and to provide the response messages to the IC card terminal. As stated previously, the lower tester 30 may be any commercially available test device or system that can interface with an IC card terminal. Fig. 3 shows an exemplary embodiment of a test application that may be executed on the lower tester 30, for use with the test method of Fig. 2. In step 300, a set of predefined responses is stored in the lower tester 30. In step 310, the number of predefined responses is stored in the variable number _responses and the variable current response is set to the value "1". In step 320, the test application waits for a command message from the IC card terminal. In step 330, when a command is received, the response in the set corresponding to the value of the variable current response is sent to the IC card terminal. For example, if current _response is "1", then the first response in the set is sent. The variable current response is then incremented by one in step 340. In step 350, if current response is greater than number _responses, current _response is reset to "1". Essentially, the test application cycles through the set of responses, one response after the other.
Although the present invention has been described with reference to certain preferred embodiments, various modifications, alterations, and substitutions will be known or obvious to those skilled in the art without departing from the spirit and scope of the invention, as defined by the appended claims.

Claims

1. A method for testing an integrated circuit card terminal, comprising: identifying the interface module of the integrated circuit card terminal; and executing a test program in the integrated circuit card terminal which loops back, through the interface module, messages received by the integrated circuit card terminal.
2. The method of claim 1, wherein each message received by the integrated circuit card terminal includes a response message and a status word, and the step of executing the test program includes stripping the status word and transmitting the response message as a command message.
3. A system for testing an integrated circuit card terminal, comprising: an integrated circuit card terminal, including an interface module therein; a test program means in the integrated circuit card terminal for looping back, through the interface module, messages received by the integrated circuit card terminal; and testing means coupled to the integrated circuit card terminal for receiving messages from the terminal and sending messages to the terminal.
4. The system of claim 3, wherein each message received by the integrated circuit card terminal includes a response message and a status word, and the test program means includes means for stripping the status word and means for transmitting the response message as a command message.
5. The system of claim 4, wherein the testing means includes a set of response messages stored therein and program means for cycling through the set of response messages responsive to command messages.
PCT/US1999/031131 1998-12-29 1999-12-29 Method and system for testing an integrated circuit card terminal WO2000039684A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU22199/00A AU2219900A (en) 1998-12-29 1999-12-29 Method and system for testing an integrated circuit card terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11411198P 1998-12-29 1998-12-29
US60/114,111 1998-12-29

Publications (1)

Publication Number Publication Date
WO2000039684A1 true WO2000039684A1 (en) 2000-07-06

Family

ID=22353411

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/031131 WO2000039684A1 (en) 1998-12-29 1999-12-29 Method and system for testing an integrated circuit card terminal

Country Status (2)

Country Link
AU (1) AU2219900A (en)
WO (1) WO2000039684A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005076132A3 (en) * 2004-02-06 2006-09-14 Acquirer Systems Res Ltd A test system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4939353A (en) * 1987-01-22 1990-07-03 Kabushiki Kaisha Toshiba Processing system for enabling data communication with a self-diagnose device
EP0624851A1 (en) * 1993-05-13 1994-11-17 Angewandte Digital Elektronik GmbH Coupler between the applications on the card level and the applications on the system level

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4939353A (en) * 1987-01-22 1990-07-03 Kabushiki Kaisha Toshiba Processing system for enabling data communication with a self-diagnose device
EP0624851A1 (en) * 1993-05-13 1994-11-17 Angewandte Digital Elektronik GmbH Coupler between the applications on the card level and the applications on the system level

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005076132A3 (en) * 2004-02-06 2006-09-14 Acquirer Systems Res Ltd A test system
US7237718B2 (en) 2004-02-06 2007-07-03 Acquirer Systems Research Limited Test system

Also Published As

Publication number Publication date
AU2219900A (en) 2000-07-31

Similar Documents

Publication Publication Date Title
EP0403117B1 (en) Feature board with automatic adjustment to slot position
US6496790B1 (en) Management of sensors in computer systems
EP0433818B1 (en) Method for configuring a computer bus adapter circuit board without the use of jumpers or switches
SE517286C2 (en) Methods and apparatus for upgrading cellular mobile phones
JPH0812651B2 (en) Data processing system and method of operating data processing system
EP0710376A1 (en) Method for configuring multiple adapter cards on a bus
US6748515B1 (en) Programmable vendor identification circuitry and associated method
EP1109129B1 (en) IC card with self-diagnostic function
US6266725B1 (en) Communications protocol for asynchronous memory card
US8015448B2 (en) System and method for conducting BIST operations
EP0998703A1 (en) Method and system for automatic detection for isdn switch time in north america
US5612961A (en) Method and system for verification of the baud rate for an asynchronous serial device residing within a data processing system
US7478303B2 (en) System and method for testing nodes in a network
CN117076214A (en) Method, system, terminal and medium for detecting dial fool-proof of hard disk backboard of server
CN112015119A (en) Debug control circuit and debug control method
WO2000039684A1 (en) Method and system for testing an integrated circuit card terminal
US7009380B2 (en) Interface device for product testing
US20030159102A1 (en) Method for testing a universal serial bus host controller
US6598176B1 (en) Apparatus for estimating microcontroller and method thereof
CN111176164B (en) Method, device and medium for expanding multiple remote input and output modules
US20030056027A1 (en) Apparatus and method for improvement of communication between an emulator unit and a host device
JP4463658B2 (en) Subordinate apparatus of information processing system, operation control program for subordinate apparatus, and operation control method for subordinate apparatus
US20240004769A1 (en) Saturation of multiple pcie slots in a server by multiple ports in a single test card
JPH09179947A (en) Ic card
CN109787753B (en) Card releasing method and card reading device for Internet of things card

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase