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.