WO1998052152A2 - Communication between interface device and ic card - Google Patents

Communication between interface device and ic card Download PDF

Info

Publication number
WO1998052152A2
WO1998052152A2 PCT/GB1998/001401 GB9801401W WO9852152A2 WO 1998052152 A2 WO1998052152 A2 WO 1998052152A2 GB 9801401 W GB9801401 W GB 9801401W WO 9852152 A2 WO9852152 A2 WO 9852152A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
data
command
integrated circuit
circuit card
Prior art date
Application number
PCT/GB1998/001401
Other languages
French (fr)
Other versions
WO1998052152A3 (en
Inventor
Timothy Philip Richards
David Anthony Peacham
Original Assignee
Mondex International Limited
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 Mondex International Limited filed Critical Mondex International Limited
Priority to AU77771/98A priority Critical patent/AU7777198A/en
Publication of WO1998052152A2 publication Critical patent/WO1998052152A2/en
Publication of WO1998052152A3 publication Critical patent/WO1998052152A3/en

Links

Classifications

    • 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/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/0719—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips at least one of the integrated circuit chips comprising an arrangement for application selection, e.g. an acceleration sensor or a set of radio buttons
    • 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
    • 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/355—Personalisation of cards for use
    • 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/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • 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/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G06Q20/35765—Access rights to memory zones
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • 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

Definitions

  • IC cards are becoming increasingly used for many different purposes in the world today, principally because they are ideal tools for
  • An IC card also called a "smart card,” is a card typically the size of a conventional credit
  • the computer chip on the IC card typically includes a microprocessor, read-only-memory (ROM), electrically
  • EEPROM erasable programmable read-only-memory
  • RAM random access memory
  • I/O input/output
  • the computer chip can execute one or more applications stored on the card. Examples of applications that IC cards are being used to store and execute include credit/debit, electronic money/purse, telephone calling card, and loyalty reward applications.
  • ISO 7816-3 is a standard that covers the low-level details of the transmission link between an IC card and an interface device, such as the signal rates, voltage levels, and transmission protocols.
  • ISO 7816-4 covers the format of commands and responses transmitted between an IC card and an interface device.
  • commands always originate from an IC card interface device. Once an IC card receives a command, it processes the command and sends back a response. This set of communication between an IC card and interface device is referred to as a "command-response pair.” In a command-response pair, the command and/or response may contain associated data,
  • operating system present on the IC card may route the command to an application stored on the IC card for processing.
  • an application stored on the IC card for processing.
  • the IC card application should not be required to concern itself
  • an application is required to know the case of the command i.e., an application is required to know whether the command has any data associated with it or whether it is required to return data. Because of the way certain standards are promulgated, however, it may not be
  • a method of responding to a command from an interface device by an integrated circuit card comprises a microprocessor and a memory coupled to the microprocessor.
  • the method includes the steps of
  • An example of an expected case is one of the four cases defined under ISO 7816-4.
  • the present invention may be used where the command is transmitted from the interface device to the integrated circuit card under a transmission protocol requiring the integrated circuit card to have prior information related to the data, if any, to be transferred.
  • the method of the present invention may be used with the
  • T 0 protocol defined by ISO 7816-3.
  • the method of the present invention may also be used when the interface device and the integrated circuit card support a plurality of transmission protocols.
  • the integrated circuit card comprises an application stored
  • the selecting and processing steps are performed by the application. Moreover, before the selecting step, the method of the present
  • the integrated circuit card comprises an
  • the method of the present invention may also include the step of calling by the application a function of the operating
  • the application may then receive a return value from the function indicative of whether the expected case is applicable to the command.
  • the memory of the integrated circuit card comprises a publicly available memory space and a stack.
  • the method of the present invention may then include the steps of communicating between the operating system and the application using the publicly available memory space or the stack.
  • the application and the operating system may communicate with each other through a register in the integrated circuit card.
  • the method of the preferred embodiment of the present invention may also include the step of determining by the function called by the application whether data is to be received from the interface device. If data is to be received, the method may also include the step of receiving such data.
  • the response data is to be transmitted by the integrated circuit card to the interface
  • an integrated circuit card for use with an interface device.
  • the integrated circuit card includes a microprocessor, a memory coupled to the microprocessor, means for selecting an expected case for a command transmitted by the interface device, where the expected case represents whether data is to be transferred between the interface device and the integrated circuit card, means for determining whether the expected case is applicable to the command, and means for processing the command if the expected case is applicable to the command.
  • Fig. 1 is a schematic representation of an IC card in accordance with a preferred embodiment of the present invention
  • Fig. 2 is a perspective view of an IC card and terminal in accordance
  • Fig. 3 is a functional block diagram of an IC card in accordance with a preferred embodiment of the present invention
  • Fig. 4 is a block diagram illustrating an exemplary code space, data
  • Figs. 5 is a diagram illustrating the cases of commands defined by
  • Fig. 8 is a flowchart illustrating the steps for processing a command received from an interface device by an IC card in accordance with a preferred embodiment of the present invention;
  • Fig. 9 is a flowchart illustrating the steps for a routine for checking
  • Fig. 11 is a flowchart illustrating the steps for a routine for checking
  • Fig. 15 is a flowchart illustrating the steps for a routine for checking
  • Fig. 16 is a flowchart illustrating the steps for a routine for initializing communications information and for processing the GET RESPONSE
  • Fig. 19 is a flowchart illustrating the steps for a routine for transmitting response data and procedure bytes to an interface device in accordance with a preferred embodiment of the present invention
  • Fig. 20 is a flowchart illustrating the steps for a routine for
  • Fig. 1 provides a schematic representation of a typical IC card 10 that can be used with the presently claimed invention.
  • the IC card 10 includes an integrated circuit 12 having one or more electrical contacts 14 connected to the integrated circuit 12.
  • Fig. 2 shows an example of a device with which the IC card 10 communicates.
  • a typical terminal 20, as shown in Fig. 2, includes a card reader 22, a keypad 24, and a display 26.
  • the keypad 24 and the display 26 allow a user of the IC card 10 to interact with the terminal.
  • the keypad 24 allows the user to select a transaction, to enter a personal identification number
  • the display 26 allows the user to enter transactional information.
  • the display 26 allows the user to enter transactional information.
  • terminals may include IC card-compatible ATM machines and telephones.
  • Fig. 3 provides a functional block diagram of the integrated circuit 12.
  • the integrated circuit 12 includes a processing unit 100 and a
  • the integrated circuit 12 also includes control logic 150, a timer 160, security circuitry 170, input/output ports 180, and a co-processor 190.
  • the control logic 150 provides, in conjunction with the processing unit 100, the control necessary to handle communications between the memory unit 110 and
  • the timer 160 provides a timing reference signal for the processing unit 100 and the control logic 150.
  • the security circuitry 170 preferably provides fusible links that connect the input/output ports 180 to internal circuitry for testing during manufacturing. The fusible links are burned after completion of testing to limit later access to sensitive circuit areas.
  • the co-processor 190 provides the ability to perform complex computations in real time, such as those required by cryptographic algorithms.
  • the memory unit 110 may include different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. For example, as shown in Fig. 3, the memory unit 110 may include read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • RAM random-access memory
  • the memory unit 110 stores IC card data such as secret cryptographic keys and a user PIN.
  • the secret cryptographic keys may be any type
  • the secret cryptographic keys are stored in a secure area of ROM or EEPROM that is either not accessible or has very limited accessibility from outside
  • the memory unit 110 also stores the operating system of the IC card.
  • the operating system loads and executes IC card applications and provides file management and other basic card services to the IC card applications.
  • IC card applications Preferably,
  • the operating system is stored in ROM.
  • the memory unit 110 may also include one or more IC card applications.
  • IC card applications For example, if the IC card is to be used as an electronic cash card, an application called MONDEXTM PURSE (from Mondex International Limited) might be included on the IC card, which loads an electronic value of a certain currency from a user's account in a financial institution onto the IC card.
  • the operating system of the IC card 10 supports multiple applications, such as the MULTOSTM operating system from Mondex International Limited.
  • An IC card application may include both program and data files, which are typically stored in EEPROM. The application program may be written either in the native programming code of the processing unit 100 or it may be
  • MEL MULTOSTM Executable Language
  • an application program is capable of running
  • an IC card may also have primitives stored in ROM, which are subroutines that perform frequently used functions or procedures, such as mathematical functions.
  • the primitives are usually
  • the operating system of the IC card 10 imposes a layer of abstraction between an application and the underlying hardware of the IC card 10.
  • This abstraction layer permits the application to be hardware independent and to run on multiple IC cards. From the standpoint of the application, it is executing on an "abstract machine" defined by the operating system.
  • Fig. 4 illustrates an exemplary architecture of an operating system
  • the abstract machine contains a memory space for each of the program code and data of an application, referred to as the code space 200 and the data space 300, respectively.
  • An exemplary size for each of the code and data spaces is 64K bytes.
  • the program code in the code space 200 is stored in non-volatile memory such as EEPROM and is addressed by the Code Pointer (CP) register 202
  • the data space 300 is divided into three segments: the static segment
  • the static segment 302 contains the application's non-volatile data.
  • Static data includes cardholder data, such as a card user's name, address, account number, and PIN. Static data also includes variable transactional data, such as the electronic value of a purse or the available credit limit of a credit/debit application.
  • the dynamic segment 306 contains the application's volatile or temporary data.
  • Dynamic data includes data which is temporarily used during the execution of an application such as intermediate values used in calculations or working variables.
  • a purse application may temporarily store the value of a transaction in order to reduce the amount of the value in the purse.
  • the dynamic segment is used in much the same way as a conventional computer program uses RAM to perform its assigned operations.
  • the dynamic segment preferably is divided into two parts, the session data portion and the stack data portion.
  • the size of the session data portion is a constant for each application and is determined when the application is loaded.
  • the data in the session data portion retains its value for the duration of a session in which the application is involved.
  • a typical use for the session data portion is to support the use of a session PIN.
  • the stack data portion holds variable data which is unique to the particular
  • the stack data portion stores data in a last-in-first-out
  • the stack is initially empty, but expands and contracts during execution of
  • the data in the dynamic segment is private to an application and cannot be read by other applications.
  • the public segment is used to store commands and response data
  • the data space 300 is preferably addressed using seven address registers: Static Base (SB) 308, Static Top (ST) 310, Public Base (PB) 312, Public
  • PT Dynamic Base
  • DB Dynamic Base
  • LB Local Base
  • Each of these registers is preferably a sixteen-bit register. These registers define the boundaries of the static, dynamic, and public segments of the data space 300. Each base register contains the address of the first byte in each segment, and each top register contains the address of the byte immediately after
  • the LB register 318 acts as a stack pointer for the stack data portion of the dynamic segment.
  • the address registers can contain physical memory addresses but preferably contain offset addresses in order to be hardware independent.
  • the abstract machine architecture also contains a Condition Code Register (CCR) 400, which contains bits that are set or cleared based on the result of an operating system or primitive instruction call.
  • CCR Condition Code Register
  • An exemplary eight-bit CCR is defined in Table 2.
  • Table 2 Exemplary Code Condition Register
  • the low-level communications handler of the operating system may use the public segment 304 to communicate with an application.
  • Table 3 shows an exemplary mapping of the communications buffer of the low-level communication handler onto the public segment.
  • the communication information mapped onto the public segment in Table 3 is consistent with ISO standards 7816-3 and 7816-4 and will be better understood in light of the following discussion.
  • IC cards typically follow conventional, industry-wide standards, such as ISO 7816-3 and 7816-4.
  • ISO 7816-3 conventional, industry-wide standards, such as ISO 7816-3 and 7816-4.
  • ISO 7816-4 defines the low-level details of the transmission link between an IC card and an interface device, such as the transmission protocol.
  • ISO 7816-4 defines the format of commands exchanged between interface devices and IC cards. Beginning with the ISO 7816-4 standard, the ISO 7816-4 standard
  • PI and P2 parameter bytes provide qualifying information for a command. If no qualification is necessary, then PI and P2 are set to zero.
  • the structure of the command is illustrated in Figs. 5A to 5D.
  • L c represents the length of the data associated with the command
  • L e represents the maximum length of the data expected to be returned with the
  • L c and L e may be either one, two, or three bytes. When L c and L c are one byte, the cases are referred to as "short.” In short cases, L c may be a number between 1 and 255 (zero is not permitted), and L e may be a number between 1 and 256 (zero is interpreted as 256). When L c and L e are more than one byte, the cases are referred to as "extended.” In extended cases, L c is coded on three bytes, with
  • L c may take on a value from 1 to 65,535.
  • L e is also coded on three bytes with the first byte being zero.
  • L e is coded on only 2 bytes. In both an extended case 2 and an extended case 4, L e may take on a
  • Table 5 shows the decoding of the case of a received command using the length of the command body (L), the value of the first byte of the command body (B,), and the value of the second and third bytes of the command body (B 23 ).
  • an interface device initiates the processing
  • CLA, INS, PI, P2, and P3 correspond to the similarly-named command header bytes defined in ISO 7816-4.
  • P3 is defined as shown in Table 6.
  • B 3 refers to the third byte of the command body.
  • the interface device waits for a procedure byte from the IC card.
  • the IC card may respond with three types of procedure bytes: an ACK byte, a NULL byte, or a SW1 byte.
  • An ACK byte permits the subsequent exchange of data to or from the IC
  • a NULL byte resets the waiting time of the interface device.
  • the NULL byte is used when the IC card needs more time to process a command.
  • the interface device is required to send one or more subsequent GET RESPONSE commands with P3 equal to the number of bytes to receive (256 or less).
  • the protocol defines a block having mandatory prologue and epilogue fields and an optional information field.
  • the prologue field contains three bytes: a node address (NAD) byte, a protocol control byte (PCB), and a length (LEN) byte.
  • NAD node address
  • PCB protocol control byte
  • LN length
  • the NAD byte is used to identify the source and destination of the block.
  • the PCB is used to convey control
  • the LEN byte indicates the number of bytes in the information (INF) field, which may be 0 to 254 bytes.
  • the presence of the INF field is optional. When present, it conveys either application-related or status information.
  • the epilogue field contains an error detection code (EDC), which may be either LRC (longitudinal redundancy check) or CRC (cyclical redundancy
  • Chaining refers to the segmentation of data and the transmission of the segmented
  • Chaining is used when the data to be transmitted is
  • M-bit “More Data bit”
  • the M-bit is set when chained data follows in subsequent blocks and is cleared to indicate the last (or only) block in a chain.
  • the complete command header and command body of a command defined under ISO 7816-4 are transmitted in the INF field of a block.
  • an operating system may determine the case of the command using the decoding rules in Table 5.
  • Such intervention typically requires the application to delve into the details of the transmission protocol. Such intervention is undesirable, however, because it destroys the independence of the transmission and application layers. Such layer independence is advantageous because it saves programming effort on
  • an application may guess a case. In either instance, the application calls the Check_Case function or primitive, which determines whether the command is consistent with the case the application has
  • the CheckjCase function or primitive returns a "true” or “false” value to the application, depending on its determination.
  • an application may PUSH the expected case onto the top of the
  • the CheckjCase function or primitive may return an answer through the
  • CheckjCase function or primitive The operating system is only required to determine whether the expected case is consistent with the format of the command received. Thus, the CheckjCase function or primitive accomplishes true
  • Fig. 18 shows an exchange involving an INTERNAL AUTHENTICATE command.
  • An INTERNAL AUTHENTICATE command sends challenge data to an IC card, which receives the data, encrypts it using a secret key, and returns the encrypted data to the interface device.
  • an application is involved in processing the INTERNAL AUTHENTICATE command.
  • the communications handler stores these bytes in a communications buffer, called commjbuffer, and
  • the Receive Command TO subroutine initializes communications
  • the Receive JCommandJTO subroutine first checks in step 1610 the variable public. protocol lags. expecting gr to determine whether a GET RESPONSE command is expected by the IC card. If the public.protocoljlags.expectingjgr variable is "false," which will be the case when a command header is first received, the Receive Command JTO subroutine initializes the public segment according to the values shown in step 1630.
  • the variables and processes GET RESPONSE commands under the T 0 protocol.
  • step 1630 correspond to those shown in Table 3.
  • step 1630 the Receive jCommandJTO subroutine exits.
  • the currently selected application is notified of the received command header in step 807 by the use of any conventional means, such as by the use of an interrupt or by setting a bit in the public segment or a
  • step 809 the application checks the bytes public.cla, public. ins, public.pl, and public.p2 in the public segment. Although other protocol-specific information is available in the public segment, such as public. p , an application
  • step 809 if the application recognizes the command defined by
  • the application would expect a case 4, since it expects to receive and send data.
  • the application pushes this expected case onto the stack portion of the dynamic segment, and in step 813, calls CheckjCase.
  • step 815 CheckjCase checks the consistency of the command header received from the interface device against the expected case provided by the application. Depending on whether the expected case is consistent with the command header, CheckjCase sets the status variable check_case_response. status equal to "success" or "failed.” In step 817, if the expected case is 3 or 4 (command
  • Check Case calls the Cmd Data Rxed subroutine, which handles receiving the command data.
  • step 1710 whether the flag public.protocoljlags.cmd datajxd is "false.” If it is not
  • step 1720 the subroutine transmits an ACK byte to the interface device, which signals the interface device to send command data.
  • the subroutine receives the command data from the interface device and sets the command data in the data field of the public segment, public.datajield.
  • Cmd Data Rxed subroutine sets the flag public.protocolJlags.cmd data xd to "true,” to indicate that the command data has been received.
  • the Cmd_Data_Rxed subroutine transmits the ACK byte 1820, which consists of the INS byte of the command
  • step 821 sets or clears the Z-bit of the CCR register based on the value of check_case_response. status. Control is then returned to the application, which checks the Z-bit of the CCR register to determine whether
  • step 823 if Check Case
  • step 825 if the case of the command is either 2 or 4 (data is to be sent to the interface device), the application sets the data and the length of the data
  • step 827 the operating system calls the Transmit _Response subroutine, which transmits the appropriate procedure bytes to the interface device, depending on the status of the protocol flags set in the public segment.
  • Transmit ⁇ Response subroutine also sets the flag public.protocol lags. expecting gr to "true” under appropriate circumstances. For example, in a case 4 command, as in the INTERNAL AUTHENTICATE example above, a GET RESPONSE
  • the Transmit Response subroutine would set the flag public.protocoljlags. expecting gr to "true.”
  • Fig. 19 is a flowchart illustrating the steps of the Transmit _Response subroutine.
  • the subroutine checks whether public.la is equal to zero,
  • step 1920 the response Jpdu is set simply to the
  • step 1930 it is checked whether public.la is greater than zero. If public.la is greater than zero, in step 1930, it is checked whether
  • step 1940 the response is set to hexadecimal value "6F00,” indicating a fatal error.
  • step 1950 it is checked whether public.protocoljlags. le ialid is
  • step 1960 the first procedure byte of the response is set Xo public.get_response.swl, indicating that the IC card has data available for the interface device.
  • the second procedure byte is set to the length of the data available, either public.la if public.la is less than 256 bytes or hexadecimal "00" if public.la is equal to or greater than 256 bytes.
  • step 1970 public.protocoljlags. expectingjgr is set to "true,” since it is expected the interface device will send a GET RESPONSE command to the IC card in response to the procedure bytes indicating that data is available. If the expected length of the response data is known and is less than the actual length of the response data, in step 1980, it is checked whether public.le is greater than zero. If public.le is greater than zero, in step 1990, the variable
  • step 1995 the response is set to: (1) an ACK
  • procedure byte public.ins
  • response data either null or the data in the data field of the public segment
  • procedure bytes public, swl and public. sw2 (which will normally indicate the
  • the Transmit Response subroutine transmits the procedure bytes SWl and SW2 with hexadecimal values of "61" and "04,” respectively.
  • the hexadecimal value "61" for SWl informs the
  • step 1970 of Fig. 19 public.protocolJlags.expecting_gr is set
  • the interface device when the interface device receives the SWl and SW2 procedure bytes 1840 from the IC card, the interface device sends a GET RESPONSE command 1850 with L e (P3) equal to the number of bytes to be transferred (in this case, four).
  • the Receive JCommandJTO subroutine again checks the status of the flag public.protocoljlag.expecting_gr. Since
  • step 1620 the Receive JCommandJTO subroutine first determines if
  • the Receive Command JTO then processes the GET RESPONSE command, which involves transmitting the
  • Receive jCommandJTO transmits response 1860, which consists of an ACK byte (set to the INS of the GET RESPONSE
  • T l protocol the operating system may determine the case of a command without any intervention by an application. Nonetheless, to maintain a consistent interface and layer independence, all protocols must be supported by CheckjCase.
  • the low-level communications handler also checks the error detection code (EDC) to ensure that a communications error has not occurred. If the PCB indicates that chained blocks follow, the low-level communications handler
  • EDC error detection code
  • the low-level communications handler chains the data in the blocks. After the last block is received, the low-level communications handler calls the Receive Command T1
  • Fig. 20 is a flowchart illustrating the steps for the Receive Command JT1 subroutine.
  • the subroutine checks whether public.protocoljlags.expectingjgr is "true," indicating the operating system is expecting a GET RESPONSE command from the interface device. If the flag is set
  • step 2020 the GET
  • RESPONSE command is processed. If i e public.protocolJlags.expecting_gr is "false," in step 2030, various communications variables are initialized. In step 2040, the communications variables public.protocoljlags.le yalid,
  • public.le are set according to body of the command received by the low- level
  • Figs. 9 to 15 are flowcharts setting forth exemplary, detailed steps of the CheckjCase function or primitive. In Fig. 9, steps 910 and 930, CheckjCase
  • Fig. 10 illustrates an exemplary embodiment of the CheckjCase JTO
  • step 1010 a default value of "success" is assigned to check_case_response. status.
  • step 1020 CheckjCase TO checks whether the flags public.protocoljlags.pi jyalid, public.protocoljlags. lc yalid, and public.protocoljlags. Ie yalid are in the initialized states set by
  • step 1030 to 1060 CheckjCase JTO checks whether the application expects case 1, 2, 3, or 4. In step 1070, if the application has passed an expected case that is not 1 to 4,
  • step 1080 if the
  • public.protocolJlags.p3 yalid is set to "false” (indicating that CheckjCase has checked the command header) and public.protocoljlags. Icj'alid is set to "true” (since, CheckjCase will set the correct public.le).
  • Fig. 11 is a flowchart illustrating the steps for the case 1 logic of the CheckjCase JTO subroutine.
  • Fig. 12 is a flowchart illustrating the steps for the case 2 logic of the CheckjCase JTO subroutine.
  • step 1210 if L c is valid and greater than zero, CheckjCase fails (because case 2 does not expect command data).
  • step 1220 if
  • step 1230 public.le is set to zero (indicating no command data is present).
  • steps 1240 and 1250 if P3 is valid and greater than zero, the flag public.protocoljlags. le jyalid is set to "true" and public.le is set to public. p3 (see
  • public.le jyalid is not set to "true” (it remains “false”).
  • the state of the public.le jyalid variable is used in the Transmit _Response subroutine to determine the proper procedural bytes to send (see step 1950 of Fig. 19).
  • Fig. 13 is a flowchart illustrating the steps for the case 3 logic of the
  • step 1310 if P3 is valid and greater than zero (which is required for case 3), public.le is set to public.p3 (see Table 6). Otherwise, in step 1320, other conditions inconsistent with case 3 are checked. In step 1330, the flag public.protocoljlags.le jyalid is set to "true" and public.le is set
  • step 1340 the
  • Fig. 14 is a flowchart illustrating the steps for the case 4 logic of the
  • step 1410 if P3 is valid and greater than zero
  • step 1420 the Cmd Data Rxed subroutine, previously described with reference to Figs. 8 and 17, is called, to receive command data from the interface device.
  • Fig. 15 is a flowchart illustrating the steps for the CheckjCase T1
  • step 1510 a default value of "success" is assigned to check_case_response. status.
  • steps 1520, 1540, 1560, and 1580 CheckjCase T1 determines whether the expected case is 1, 2, 3, or 4, respectively. If the expected
  • step 1595 a value of "failed" is assigned to
  • CheckjCase JT1 checks for conditions that are inconsistent with the cases 1, 2, 3, and 4, respectively, using the communications variables set by the
  • IC cards are becoming increasingly used for many different purposes in the world today.
  • An IC card also called a smart card
  • An IC card typically is the size of a conventional credit card which contains a computer chip including a microprocessor, read-only-memory (ROM), electrically erasable programmable read-only-memory (EEPROM), a random access memory (RAM), an Input/Output (I/O) mechanism and other circuitry to support the microprocessor in its operations.
  • ROM read-only-memory
  • EEPROM electrically erasable programmable read-only-memory
  • RAM random access memory
  • I/O Input/Output
  • An IC card may contain a single application or may contain multiple independent applications in its memory.
  • MULTOSTM is a multiple application operating system which runs on IC cards, among other platforms, and allows multiple applications to be executed on the card itself.
  • the multiple application operating system present on the IC card allows a card user to run many programs stored in the card (for example, credit/debit, electronic money/purse and/or loyalty applications) irrespective of the type of terminal (i.e., ATM, telephone and/or POS) in which the card is inserted for use.
  • programs stored in the card for example, credit/debit, electronic money/purse and/or loyalty applications
  • type of terminal i.e., ATM, telephone and/or POS
  • a conventional single application IC card such as a telephone card or an electronic cash card, is loaded with a single application card and only executes that one application when inserted into a terminal.
  • a telephone card could only be used to charge a telephone call and could not be used as a credit/debit card.
  • a card user desires a variety of application functions to be performed by single application IC cards issued to him or her, such as both an electronic purse and a credit/debit function, the card user would be required to carry multiple physical cards on his or her person, which would be quite cumbersome and inconvenient.
  • a card user may have both a purse application and a credit/debit application on the same card so that the user could select which type of payment (by electronic cash or credit card) to use to make a purchase.
  • Multiple applications could be provided to an IC card if sufficient memory exists and an operating system capable of supporting multiple applications is present on the card.
  • the present invention provides for a multiple application architecture for an IC card called an application abstract machine (AAM) and a method for implementing that architecture.
  • the processing of multiple applications is accomplished by generating for at least one application (the "first application") a data memory space including at least two segments, a volatile memory segment and a non- volatile memory segment, commencing the execution of the first application's instructions; delegating or switching execution from the first application to the delegated application and in so doing, saving any data generated by the first application in the logical data memory space associated with the first application; executing the second application's instructions; retrieving the saved data and completing with this data the execution of the first application's instructions.
  • the first application a data memory space including at least two segments, a volatile memory segment and a non- volatile memory segment, commencing the execution of the first application's instructions; delegating or switching execution from the first application to the delegated application and in so doing, saving any data generated by the first application in the logical data memory space associated with the first application; executing the second
  • Additional delegation commands can be issued by the second application or other subsequent applications.
  • the command delegated is inte ⁇ reted by a delegated application in the same manner as a selection command being issued directly by a terminal and therefore each application performs the security functions at the same level as if a terminal is issuing the command.
  • the volatile memory segment can further be separated into public ("Public") and dynamic (“Dynamic”) portions. Data can be exchanged between a plurality of applications and/or a terminal when stored in the Public region of the data memory.
  • the Dynamic memory region can be used solely as temporary work space for the specific application being executed.
  • Fig. 1 is block diagram illustrating the data memory space segment and associated registers for an IC card application using the AAM organization
  • Fig. 2 is a block diagram illustrating the code memory and the data memory spaces for an IC card application using the AAM architecture
  • Fig. 3 is a flow diagram illustrating the steps of performing a request for a delegation function by one application to another;
  • Fig. 4 is a flow diagram illustrating the steps of performing a return ! ⁇ a TO THE DESCRIPTION delegation control function for a delegate application to a delegator application;
  • Fig. 5 is a flow diagram illustrating the steps of performing an inquire delegator ID request of a delegation function
  • Fig. 6 is a block diagram of an IC card chip which can be used as a platform in accordance with the invention.
  • FIGS 7A, 7B and 7C illustrate multiple delegation calls made between three applications.
  • the present invention provides for a method and apparatus for processing multiple application programs with associated data stored on an IC card which can be accessed and executed.
  • An application stored on the card can be selected by a terminal, or other interface device, or another application.
  • Each application program which is stored on the IC card when executed is allocated a memory space organized by the program's software code (instructions which are executed by a processor located on the IC card) and the associated data which the application stores and uses during execution of the program.
  • a multi-application card may store a purse application, or an electronic money application, and a specific loyalty application such as a frequent flyer awards application.
  • Each application has software code and associated data to support the execution of that software code.
  • Each application is allocated a memory space when executed.
  • the purse application need not be aware of the specific loyalty program stored on the card, but instead may contain an instruction to communicate with any loyalty program stored on the card.
  • the loyalty program will require input data representative of the amount of a particular electronic value so that it can update its own stored data of current frequent flyer miles for the user of the card.
  • AAM Application Abstract Machine
  • An application abstract machine (AAM), a term for the memory allocation and organization for the data stored and used by each application, is created for each application stored on the IC card which is executed by the processor on the card.
  • AAM application abstract machine
  • Each application has v ( . TO TH£ DESCRIPTION a data memory space which is virtually allocated and mapped onto the physical memory addresses available in the IC card memories. Data is then passed between two or more applications within a specified memory location and in a manner consistent with transferring data to an external terminal or device with which the IC card is securely interacting.
  • each AAM space created for each application being executed includes two separate address spaces, one for the program code itself and one for the program data which is stored and/or used by the application.
  • the program data address space is effectively divided into three segments: a Static segment, a Dynamic segment and a Public segment which are described in more detail in conjunction with Figure 1.
  • the Static, Dynamic and Public segments are logically mapped to the physical memory; they are virtual memory segments as opposed to physical memory segments.
  • the AAM data address space is preferably addressed and processed using seven different address registers and two control registers.
  • Figure 1 shows an illustrative diagram of a logical data space allocation 101 created for an application used in conjunction with the present invention.
  • the AAM data portion 101 includes a Static data space 103, a Public data space 105 and a Dynamic data space 107. Also shown are a series of address registers: the Static base address register 109, the Static top address register 111, the Public base address register 113, the Public top address register 115, the
  • Dynamic base address register 117 the Dynamic top address register 121 and local base address register 119 which serves as a local stack frame pointer in the Dynamic data space when the application is being executed.
  • the address registers can contain physical memory addresses but preferably contain offset ad ⁇ res ⁇ u fur the various data address spaces in order to be hardware independent.
  • An example of the overall address space is 64K bytes, although the size varies with the applicable platform and the available memory size.
  • the registers can also be considered pointers or can be any other conventional addressing mechanism.
  • the Static portion of the memory is non-volatile which is not erased after power is removed from the IC card (such as EEPROM), the Dynamic space is volatile (such as RAM) which may be erased after power is removed from the card and the Public space is also volatile (such as RAM).
  • An IC card can receive power from a terminal after it is interfaced into the terminal. Although an IC card may contain a battery to maintain some power for memory and circuitry, volatile memory will typically be erased after the IC card is removed from its power source.
  • the defined AAM data space has bytes in each segment which are contiguous, so that applications can perform pointer and offset arithmetic. For example, if the segment addresses "1515" and "1516,” or any other pair of sequential numbers, are both valid and are present within the same segment, then they address adjacent bytes. This allows offset values stored in registers to determine the location of a desired memory address.
  • the segment address of the first byte of the Static segment is zero, so that the segment address of a given location within the Static region is equal to its offset.
  • Pointers to other specific regions of the Static data area can be stored in the Static data because the Static region is non- volatile.
  • the Static memory of a credit/debit application the application will know the card user's name will always be stored in the 5 th memory location above the starting point for the Static portion of memory.
  • the location can be noted as SB[5] or the 5 th byte above the Static Bottom. Since the Static memory is non-volatile, it will not be erased after each transaction and the application will always know of its location relative to the Static segments' address registers.
  • the segment address of any location in the Dynamic or Public segments is not always equal to a particular offset from the beginning of the respective segment because the contents of those segments change for each operation.
  • the fourth location in the Dynamic segment will be different for each operation performed by the application.
  • the address of a memory location of Dynamic or Public segment is fixed preferably only for the duration of one command-response pair operation. Because segment addresses in Dynamic or Public are not fixed, MULTOS Executable Language (MEL)TM instructions (or any other program instructions) cannot refer to data using only segment addresses.
  • MEL MULTOS Executable Language
  • a tagged address preferably is used to identify data which is to be retrieved, manipulated, transferred and/or stored with the IC card system.
  • a tagged address is a nineteen bit value consisting of a three bit tag (address register number) and a sixteen bit offset.
  • Each of the seven address registers for the AAM data space contain a segment physical address. For instance, the address registers SB 109 and ST 111 point to the boundaries of the Static, the address registers PB 113 and PT 115 point to the boundaries of the Public and the address registers DB 117 and DT 121 point to the boundaries of the Dynamic.
  • the top register points to the byte mme ate y a er the last va byte.
  • the last valid byte of the Static is ST[-1].
  • Register LB functions as a stack frame pointer. It points to a location in the Dynamic segment to indicate a specific byte of local data for the currently executing application.
  • the allocated Static segment 103 contains the application's non-volatile data. Static data includes data which is associated with each application for every transaction such as the card user's name, account number, PIN value and address. Static data also includes variable data which is stored for use in future transactions using the application.
  • the electronic value data would be read from the Static segment and later saved in the Static segment at the end of the transaction. Additionally, transaction information data or available credit limits in the case of a credit/debit application would be stored in Static data.
  • the Static data is addressed using register SB (Static Base) and the register ST (Static Top) as offset registers. These registers contain the offset value from a physical address in a memory on the IC card. The individual memory location is then further offset from these starting points such as SB[3] or ST[-5]. SB is defined as zero and ST is equal to the size of the application's Static data which is set when the application is loaded onto the IC card.
  • the multiple application operating system ensures that no other application can read or write the data stored in the Static segment of a particular application. Using current technology, the Static segment is preferably mapped onto an EEPROM (Electrically Erasable Programmable Read-Only Memory) which is non-volatile. 2152
  • the Dynamic segment 107 contains me appli au * vu u « ⁇ temporary data.
  • Dynamic data includes data which is temporarily used during the execution of an application such as intermediate values used in calculations or working variables.
  • a purse application may temporarily store the value of a transaction in order to reduce the amount of the value in the purse.
  • the temporary data is used much like conventional computer programs use RAM to perform their assigned operations.
  • the Dynamic segment preferably is divided into
  • the size of the session data is a constant for each application and is determined when the application is loaded.
  • the stack holds variable data which is unique to the particular transaction being executed.
  • the stack data portion stores data in a last-in- f i rst-out manner. The stack is initially empty, but expands and contracts during
  • the Dynamic data is addressed from the register DB 117 to register
  • Register LB 119 serves as a local stack frame pointer to particular memory locations in the Dynamic segment for delegate commands or function calls. Register LB 119 is used to address the topmost frame, that of the currently executing function's session data. Register DT 121 serves as an address offset for the stack pointer. A one byte data item at the top of the stack is addressed as DT[-
  • a push operation increments the relative value of DT for each item on the stack and a pop operation decrements the relative value of DT for each item on the stack. For example, a data element located at DT[-5] will be located at DT[-6] after an additional data ⁇ appetizer «aku M « M O 98/52152
  • JUKI A TO THE DESCRIPTION item is placed on the stack.
  • the multiple application operating 5 system ensures that no other application can read or write the data stored in the Dynamic segment of a particular application.
  • the session data is set to zero upon the start of the execution of the application.
  • Stack data will be saved in the stack if the application delegates a task or operation to another application.
  • a delegation function occurs when one application selects another 10 application to process a command instead of processing the command itself.
  • An example of a delegation function occurs when a delegator application receives a command that it does not recognize or is not programmed to process. The selected application should not reject the command and provide an error response to the interface device (IFD), but instead should pass the command to the appropriate 15 receiver, or delegated application.
  • the delegator calls the Delegate primitive.
  • the Delegate primitive is a subroutine recognized by the multiple application operating system which is executed when the operating system interprets the Delegate instruction. Primitives can be stored as part of the operating system itself, loaded as a separate routine when the operating system is 20 installed.
  • Primitives are preferably written in machine executable language so that they can be executed quickly although they could be written in a higher level language.
  • execution of the delegating application is suspended, and the delegated application is executed instead.
  • the HEX ' TO THE DESCRIPTION delegated application then generates its own data memory space according to the AAM architecture.
  • the data stored in the Public memory space of the first application (stored in RAM) is sent to the Public memory space of the second application (which could be physically the same memory but is allocated separately for each application) so that data can be passed between the applications.
  • the Dynamic memory space is also shared although data is saved in a stack for the delegator and the other portions initialized before the delegated application is executed because the Dynamic data is secret.
  • the delegated application processes the command exactly as though the command has arrived directly from an interface device.
  • the delegated application has finished processing the command, and has written a response into the allocated Public memory segment, it exits as normal.
  • the delegator then resumes execution at the instruction address following the executed instruction which called the Delegate primitive.
  • the response generated by the delegated application is retrieved or accessed from the allocated Public memory space.
  • the delegator application may simply exit in turn, thus sending the response to the IFD, or may carry out further processing before exiting.
  • Another example of a delegation operation occurs when two applications need to share data. If an application A always returns a data item N when processing a command B, then another application which also returns data item N in response to a command can delegate the function B to application A in order to reduce the need for duplicate codes stored on the IC card. For example, if a PIN needs to be checked before an application is executed, an application stored ⁇ A ⁇ OT-EMIPTIi on the card can delegate the "retrieve PIN function" to a PIN application which returns a stored universal PIN for the card.
  • a new session begins whenever the IFD, e.g. a terminal, successfully selects an application, even if the application has been previously selected during the transaction. For example, if a card user goes to a terminal and transfers twenty dollars of electronic cash using a purse application, charges thirty dollars using a credit/debit application and then transfers ten dollars using the purse application again, three separate sessions will have occurred even though only two applications were used during the entire transaction. Each time an application delegates a task or function to another application, the delegated application treats the delegate function as if the IFD devices had selected the application to perform the task or function. However, performing a delegation function as described below has a different effect on session data.
  • session data is initialized (i.e., erased) versus when it is saved to be used in further operations.
  • application A may delegate all three commands to application B. For example, delegations may occur in response to delegation commands in the program code.
  • Both applications A and B will have their session and stack data in their respective Dynamic segments initialized (set to zero) when they receive command X, but the stack will not be initialized when they receive the subsequent commands Y and Z.
  • application A is selected, and receives -ill ( ?0 THE DESCRIPTION commands X, Y and Z from the terminal.
  • Application A processes X itself, but delegates Y and Z to application B.
  • Application A will have its session and stack data initialized when it receives X, but not when it receives the subsequent commands Y and Z.
  • Application B will have its session and stack data initialized when it receives Y, but not Z.
  • session data is to support the use of a session Personal Identification Number (PIN).
  • the application could reserve one byte of session data to support the PIN-receiving flag.
  • the selected delegated application could update the flag as follows: if the PIN command is received and the inputted PIN is equal to the stored pin, then it will set the session data DB[0] to 1. If not, the application will check if the PIN flag is already set by checking the value in DB[0]. In either of the above cases, the application will process the rest of the commands in the session because the PIN has been verified. If neither of the cases is true, then the application will not process the command because the PIN is not proper.
  • the PIN checking function could be a delegated function from the selected application to a PIN checking application.
  • the Public segment 105 is used for command and response data being passed between an IFD and an application.
  • the Public segment contains the data passed between two applications, the delegator (the application initiating the delegation) and the delegated application (the application which performs the delegated function).
  • An application may also use the Public segment as a further temporary working storage space if required.
  • Public data is addressed using offsets stored in register PB 113 as a starting address, to register PT 115 as an ending address.
  • Register PB 113 and Register PT 115 are fixed for the duration of a command-response pair being initiated by the IFD or delegator.
  • Public data can include data inputted into or supplied by a terminal such as a transaction amount, vendor identification data, terminal information, transmission format or other data required or used by an application resident on the IC card.
  • Public data can also include data which is to be transmitted to an IFD device or other application such as an electronic dollar value, card user information transmission format or other data required or used by the terminal or other delegated application.
  • the multiple application operating system ensures that the data stored in the Public segment remains private to the application until the application exits or delegates.
  • the data in the Public segment is then made available to other entities as follows: (1) if the application delegates, the whole of the Public segment becomes available to the delegated application; (2) if the application exits, and is itself delegated by another, the whole of the Public segment becomes available to the delegator; or (3) if the application exits, and is not itself delegated, then a portion of the Public segment containing the I/O response parameters and data are made available to the IFD.
  • An application may write secret data into the Public memory segment during execution of the application, but the application must make sure it overwrites the secret portion of the Public segment before delegating or exiting.
  • the operating system on the IC card A TO THE DESCRIPTION preferably overwrites all of the data in the Public segment automatically so that no unwanted entities can have access to the secret data. If the MULTOS carrier device (MCD) is reset, the operating system overwrites data in the Public segment automatically, so that no secret data is revealed.
  • a portion of the Public memory segment is also used as a communications buffer.
  • the I/O protocol data and parameters are preferably stored at the top of the Public memory space. In another prefe ⁇ ed embodiment, the top seventeen bytes are reserved for the communications protocol between the IFD device and the IC card application. However, additional or less bytes can also be used depending upon the particular application and operating system being utilized.
  • Data memory space 201 includes the three segments Static, Public and Dynamic as previously described.
  • Code memory space 203 contains the program instructions for an application stored on the IC card.
  • the application instructions are preferably stored in an executable form which can be inte ⁇ reted by the resident operating system but can also be stored in machine executable form.
  • Instruction 205 is stored at one location in the code memory space 203. Additional instructions are stored in other locations of memory space 203. Two additional registers 207 and 209 are used in the AAM architecture.
  • a code pointer (CP) register 207 M H ft TO THE DISCRIPTION indicates the particular code instruction to be next executed.
  • the register indicates, e.g., through an offset or pointer means, that instruction 205 is the next to be executed.
  • Condition Control Register 209 contains eight bits, four of which are for use by the individual application and four of which are set or cleared depending upon the results of the execution of an instruction. These condition codes can be used by conditional instructions such as Branch, Call or Jump.
  • the condition codes can include a carry bit, an overflow bit, a negative bit and a zero bit.
  • All address and control registers are set to defined values prior to executing the selected or delegated application. The values are set either when the application is first loaded onto the card and the size of the code and non- volatile data can be ascertained or at the moment when the application passes control to the application.
  • SB is set to zero and ST is equal to the number of bytes in the application's Static database.
  • the other address registers are initialized when the application is given control.
  • CP 207 is set to zero and all eight bits in CCR 209 are cleared at the start of executing the application.
  • a communications interface mechanism is present between the IFD and an application which includes the use of the Public data segment as a communications buffer for command-response parameters.
  • a command-response parameter means an application is given a command to perform and returns a response to the entity issuing the command.
  • Applications interact with an IFD by receiving commands, processing them and returning responses across the IFD- Application Interface.
  • a ⁇ flllOTPJK the application will place the response into the Public segment starting at PB[0] which can be read by the IFD device and will set the proper interface parameters in the reserved Public space relative to PT[0].
  • an application can be called directly from an IFD and return a response directly to an IFD, it can also delegate a request to another application where appropriate. The subsequently-called application will then process the request on behalf of the first application.
  • the delegation can be directly in response to a received command in which the delegator acts as a controller for delegating commands or subcommands to other appropriate applications.
  • the delegated command can be embedded in an application's code which delegates control of the processor when the first application needs to interact with another application during its execution, such as updating frequent flyer miles or verifying a PIN.
  • FIG. 3 shows a flow chart of the steps which are performed when a delegate request is executed.
  • Step 301 sets the parameter named delegator_application_id (delegator ID) to be equal to the selected_file.application_id (selected ID).
  • the selected ID indicates the current application which is selected and which is currently being executed.
  • the delegator ID indicates the application which delegates a function to another delegated application stored on the IC card.
  • Step 303 then pushes (stores) the delegator ID onto the top of the delegate_id_stack (delegate stack). The data referenced in the Dynamic portion of allocated memory is saved so that the current application can complete its execution after the delegated function is complete.
  • the delegate stack is preferably stored outside of an application's AAM memory space and keeps track of which applications have delegated functions. Each application is suspended when it delegates a function so the delegate stack can act in a Last-In-First-Out (LIFO) manner so that if a number of applications are suspended due to delegation requests, the proper application is started in the right order.
  • the delegate stack thus keeps track of which application was the last delegator when multiple layered delegation functions are performed.
  • the delegate stack preferably operates in a LIFO manner although different stack schemes could be used as appropriate.
  • Step 305 sets the selected ID to the delegate_request.delegate_ application_id (delegate ID) value.
  • This step selects the application which will be called to perform the delegated function or functions.
  • the identities of the delegated application can be specifically called by the delegator application or a particular function can be matched up with an application in a look up table. For example, a PIN match operation may be delegated to different applications depending upon which applications are present on the card.
  • Step 307 sets the application_command parameter to the value stored in the delegate_request.application_command parameter. This step specifies the command to be delegated to the delegate application.
  • Applications typically have the ability to process many different commands. Alternatively, the entire application could be executed to perform one or more functions.
  • Step 309 then sends the NNEK A TO THE DESCRIPTION application_command to the AAM operating system for execution by the delegatee application.
  • the delegator application is then suspended (or interrupted). Any data that is required to pass between the applications is transferred via the Public memory space.
  • Figure 4 is a flow chart of the steps for performing a "return delegation control" command by the delegatee application. This command is executed by the operating system when a delegated application has completed its delegated function.
  • Step 401 gets application_responses from the Public memory space of the delegated AAM. The response data is passed in the Public memory segment of the delegatee AAM.
  • Step 403 sets the delegate_response.status variable to a success condition. This means that a delegation operation has been successfully completed.
  • Step 405 sets the delegate_ response.application esponses parameter to the application_responses values which were stored in the Public segment of the delegatee application.
  • Step 407 sets the delegate_response.delegate_application_id parameter to selected_file.application_id (the delegatee application ID).
  • Step 409 pops the top (i.e., reads the last data stored in the stack) delegate_application_id from the delegate_id_stack. This information indicates the identity of the delegator application for the command which was just delegated and completed by the delegated application.
  • Step 411 sets the select_file.application_id value to the delegator_application_id value. This selects the delegator application which was identified from the delegate ID stack as the current application which will resume running.
  • the Dynamic data for the delegator application will be retrieved for the EX ft TOIDE; delegator application from its stored location so that the application will continue to execute where it left off with all data intact but will also have the response information from the delegated function.
  • the delegate ⁇ response data is sent to the current application for further processing.
  • the response data is passed through the Public data space which could be the same physical RAM memory location because all applications share the physical volatile memory space.
  • Figure 5 shows a flow chart of the steps involved for inquiring about a delegator ID when a delegate command is received by a delegated application.
  • the delegated application may need to know the identity of the delegator because it may perform operations differently for different delegator applications. For example, an airline loyalty program may need to know if awarded frequent flyers will be based on actual dollars processed or a lump sum award for some other activity such as performing a bill payment operation. This information could be passed to the delegated application as a variable or could be ascertained using an inquiry.
  • the delegator inquiry operation could be implemented as a primitive as previously described.
  • Step 501 receives the delegator_id_enq_request from the AAM operating system.
  • the request is used to identify the identity of the delegator.
  • Step 503 checks if the delegate_id_stack is empty. If the stack is empty, then no delegation operations have occurred and no applications have been suspended. Thus step 511 sets the delegator_id_enq_response.status parameter to a failure indicator. Step 513 then sets the value of delegator_is_enq_request.error_cause to a value indicating "no delegator application.” There is no delegator application.
  • the 152 sets the value of delegator_is_enq_request.error_cause to a value indicating "no delegator application.” There is no delegator application.
  • the 152 sets the value of delegator_is_enq_request.error_cause to a value indicating "no delegator application.” There is no delegator application.
  • step 505 sets the delegator_id_enq_response.status
  • Step 507 sets the delegator d q_response.delegator_ application d parameter to the value stored in delegate_id_stack.delegator_ application ⁇ . This sets the inquiry response to indicate the delegator application ID at the top of the stack. As explained above, the stored data at the top of the stack indicates the last delegator application to call a delegate function. Step 509 then sends the delegator_id_enq_ response back to the AAM operator system which delivers the information to the application or IFD
  • Figure 6 shows an example of a block diagram of an integrated circuit
  • the integrated circuit chip located on an IC card chip which can be used in conjunction with the invention.
  • the integrated circuit chip is located on a chip on the card.
  • the IC chip preferably includes a central processing unit 601, a RAM 603, a EEPROM 605, a ROM 607, a timer 609, control logic 611, I/O ports 613 and security circuitry 615, which are connected together by a conventional data bus 617 or other conventional
  • Control logic 611 in the smart card provides sufficient sequencing
  • CPU 601 in conjunction with control logic 611 can perform many different functions including performing calculations, accessing memory locations, modifying memory contents, and managing input/output ports. Some IC cards also include a coprocessor for handling complex computations like cryptographic algorithms. Input/output ports 613 are used for communication between the card and an IFD which transfers information to and from the card. Timer 609 (which generates and/or provides a clock pulse) drives the control logic 611, CPU 601 and other components requiring a clock signal through the sequence of steps that accomplish functions including memory access, memory reading and/or writing, processing, and data communication.
  • Security circuitry 615 (which is optional) preferably includes fusible links that connect the input/output lines to internal circuitry as required for testing during manufacture, but which are destroyed upon completion of testing to prevent later access.
  • the Static memory space is preferably mapped to memory locations in EEPROM 605 which is nonvolatile.
  • the Dynamic memory space is preferably mapped to RAM 603 which is volatile memory which has quick access.
  • the Public memory space is also preferably mapped to RAM 603 which is volatile memory.
  • the Dynamic data and Public data will be stored in different portions of RAM 603, while RAM is identified as a preferred non-volatile memory and EEPROM is identified as a preferred volatile memory. Other types of memory could also be used with the same characteristics.
  • Figures 7A, 7B and 7C illustrate an example of a delegation function being performed in order to process multiple applications on an IC card.
  • Figure 7A shows a first application being executed as denoted with a double ringed circle 701.
  • a delegation function 702 is called to delegate an operation to the second application which is indicated I A Tfll' by circle 703. Also shown in Figure 7A is an empty delegator ID stack 705. Since the stack is empty, there is no data associated with it and it is shown only for illustrative pu ⁇ oses.
  • the multiple application operating system receives the delegate command and interrupts the execution of the first application 701 and gives control of the integrated circuit to application 703 as shown in Figure 7B.
  • the execution of the second application 703 is illustrated with a double ringed circle.
  • the term "gives control" means that the microprocessor and other circuitry on the card will process the instructions and allocate memory space for the application which is delegated.
  • the delegator ID 707 is placed on top of the stack 705.
  • the delegator ID stack is operated in a LIFO manner.
  • a third application 709 resident on the card. At some point during the execution of the second application, a delegate function 711 is called to delegate the operation to the third application.
  • the multiple application operating system receives the delegate command 711 shown in Figure 7B interrupts the execution of the second application 703 and gives control of the integrated circuit to the third application 709 as shown in Figure 7C.
  • the delegator ID 713 of the second application is pushed onto the delegator ID stack 705.
  • the delegator ID 707 of the first application whose execution is still interrupted is pushed down in the stack consistent with a LIFO stack management.
  • the delegator ID at the top of the stack is popped to indicate that execution of the second application should be resumed first.
  • the delegator ID 707 from the first application will then be at the top of the stack so that when the second application is finished executing, the first application will resume its execution.
  • Additional applications can be managed by the delegator ID stack in a similar manner. By interrupting the execution of the applications when a delegate command is processed and keeping track of the order of delegations, the security and integrity of the data for each individual application can be maintained which is important because IC cards will store data for applications which is private to the card user such as account numbers, social security number, address and other personal information.
  • An integrated circuit card comprising: a microprocessor; a volatile memory coupled to said
  • microprocessor a non-volatile memory coupled to said microprocessor; and a plurality of applications stored in said non-volatile memory, wherein upon execution of each said application, said microprocessor allocates for each said executing application an associated data memory space comprising at least a volatile memory segment for referencing temporary data and a non-volatile memory segment for referenc i ng static data; and further comprising means for delegating the performance of a function from a first executing application to a second executing application.
  • memory segment is divided into at least two regions, including a public region and
  • HEX A TO I DESCRIPTION 5 The integrated circuit card of claim 1, further comprising at least one register coupled to said microprocessor which is used to determine the starting locations of each of said segments.
  • each said application comprise a plurality of program instructions and wherein at least one of said program instructions when executed causes said memory referenced by said volatile memory segment to be accessed.
  • a method for processing a plurality of applications stored in a memory of an integrated circuit selecting a first application for execution; 2152
  • non-volatile memory segment is divided into at least two regions, including a public region and a dynamic reg i on. 2152
  • region is utilized during the execution of said first application.
  • said second data space's segments comprise a volatile memory segment for referencing temporary data and a non-
  • volatile memory segment for referencing static data.
  • volatile segment is divided into at least two regions, including a public region and a
  • a third data space for said third application is allocated which includes a volatile memory segment for referencing temporary data and non-volatile memory segment for referencing static data, wherein said third application's volatile segment includes a public and dynamic portion.
  • An apparatus for processing a plurality of applications stored in a memory of a single integrated circuit card comprising: means for allocating a data space comprising at least a non- volatile memory segment for referencing static data and a volatile memory segment for referencing temporary data; means for executing a first application; means for interrupting execution of said first application, means for saving data from at least a portion of said volatile memory segment; and means for executing a second application; means for retrieving said saved data; and means for completing said execution of said first application.
  • volatile memory segment is divided into at least two regions, including a public
  • a third data space for said third application is allocated which includes a volatile memory segment for referencing temporary data and non-volatile memory segment for referencing temporary data, wherein said third application's volatile memory segment includes a public and
  • a non-volatile memory coupled to a databus; a volatile memory coupled to said d .a.mtabaus; A " roira ⁇ —i ⁇ xN a first and second application program stored in said non-volatile memory, wherein each application has an associated identifier; a data stack accessible by said databus for storing said applications' identifier if said application is interrupted during its execution; processor means for executing instructions from said application programs wherein said processor means allocates a data memory space for said application which is being executed and said data memory space is mapped to at least one address in said non- volatile memory and at least one address in said volatile memory; and wherein said processor means interrupts said first application at least once during its execution to execute said second application.
  • data memory space comprises at least a volatile memory segment for referencing temporary data stored in said volatile memory and a non-volatile memory segment for referencing static data stored in said non- volatile memory.
  • the system of claim 37 further including means for allocating a second data space including at least two segments for said second application.
  • said second data space comprises at least a volatile memory segment for referencing temporary data and a non-volatile memory segment for referencing static data.
  • a third data space for said third application is allocated which includes a volatile memory segment for referencing temporary data and non-volatile memory segment for referencing temporary data, wherein said third application's volatile memory segment includes a public and dynamic portion.
  • An integrated circuit card comprising: a plurality of applications and a microprocessor for controlling execution of said applications wherein execution of at least one first application is interrupted and execution is transferred to another second application, further comprising means for sharing data by said first and second applications and means for resuming execution of said first application at the appropriate location at least after completion of execution of said second application.
  • the integrated circuit card of claim 51 further comprising means for
  • allocating a data memory space comprises at least a volatile memory segment for referencing temporary data stored in said volatile memory and a non-volatile memory segment for referencing static data stored in said non-volatile memory.
  • the integrated circuit card of claim 51 further including means for
  • the integrated circuit card of claim 53 further including means for
  • the integrated circuit card of claim 52 further including means for allocating a second data space including at least two segments for said second application.
  • said second data space comprises at least a volatile memory segment for referencing temporary data and a non-volatile memory segment for referencing static data.
  • the integrated circuit card of claim 51 further including means for delegating use of said processor means from said second application to a third application stored on said IC card.
  • a multi-application IC card which processes two or more applications using an Application Abstract Machine architecture.
  • the AAM architecture only allows one application to be executed at a time and allows for shared processing by performing a delegation function to a second application.
  • a data space for each application is allocated when the application is selected to be executed.
  • the data space includes a volatile and non-volatile region.
  • the delegation function temporarily interrupts the execution of the first application, saves the temporary data of the first application, shares any data needed with the second application and the second application is executed until the delegated task is competed.
  • the first application then retrieves the saved data and completes its execution.
  • a delegator stack is used to keep track of the delegator's identity when multiple delegations occur.
  • the AAM model allows for a high level of security while transferring data between applications.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Stored Programmes (AREA)
  • Credit Cards Or The Like (AREA)

Abstract

A multi-application IC card which processes two or more applications using an Application Abstract Machine architecture. The AAM architecture only allows one application to be executed at a time and allows for shared processing by performing a delegation function to a second application. A data space for each application is allocated when the application is selected to be executed. The data space includes a volatile and non-volatile region. The delegation function temporarily interrupts the execution of the first application, saves the temporary data of the first application, shares any data needed with the second application and the second application is executed until the delegated task is completed. The first application then retrieves the saved data and completes its execution. A delegator stack is used to keep track of the delegator's identity when multiple delegations occur. The AAM model allows for a high level of security while transferring data between applications.

Description

COMMUNICATION BETWEEN INTERFACE DEVICE AND IC CARD
BACKGROUND OF INVENTION Integrated circuit (IC) cards are becoming increasingly used for many different purposes in the world today, principally because they are ideal tools for
the delivery of distributed, secure information processing at a low cost. An IC card, also called a "smart card," is a card typically the size of a conventional credit
card, but which contains a computer chip on the card. The computer chip on the IC card typically includes a microprocessor, read-only-memory (ROM), electrically
erasable programmable read-only-memory (EEPROM), a random access memory (RAM), an input/output (I/O) mechanism, and other circuitry to support the microprocessor in its operations. The computer chip can execute one or more applications stored on the card. Examples of applications that IC cards are being used to store and execute include credit/debit, electronic money/purse, telephone calling card, and loyalty reward applications.
To enable the inter-operability of various IC cards and IC card interface devices, the International Organization for Standardization (ISO) has promulgated a series of standards pertaining to IC cards. For example, ISO 7816-3 is a standard that covers the low-level details of the transmission link between an IC card and an interface device, such as the signal rates, voltage levels, and transmission protocols. At a higher level of detail, the ISO 7816-4 standard covers the format of commands and responses transmitted between an IC card and an interface device.
As defined by ISO 7816-4, commands always originate from an IC card interface device. Once an IC card receives a command, it processes the command and sends back a response. This set of communication between an IC card and interface device is referred to as a "command-response pair." In a command-response pair, the command and/or response may contain associated data,
thus producing four possible cases of command-response pairs. These four cases
are summarized in Table 1.
Table 1 : Command-Response Pair Cases
Figure imgf000005_0001
When an IC card receives a command from an interface device, the
operating system present on the IC card may route the command to an application stored on the IC card for processing. Preferably, when a command is sent to an IC card application for processing as part of the regular data exchange specified in the application program, the IC card application should not be required to concern itself
with the underlying details and protocol of the transmission link it would be
desirable for the application to be concerned only with processing the commands it
receives. This independence of layers between the transmission layer and the application layer saves programming effort required for the development of an application and enhances the portability of the application between hardware
platforms that use different transmission protocols.
To properly process a command it receives, an application is required to know the case of the command i.e., an application is required to know whether the command has any data associated with it or whether it is required to return data. Because of the way certain standards are promulgated, however, it may not be
possible to know the case of a command without knowing the details of the underlying transmission protocol. For example, under the T=0 transmission protocol promulgated under ISO 7816-3, it is explicitly assumed that the IC card knows the direction of a data transfer. Such information is usually dependent on
the application being executed and the state of the application's program code. Therefore, under the T=0 protocol, it is not usually possible for an IC card operating system to handle all of the low-level details of the transmission layer and shield the application from such details.
It would advantageous if independence of the transmission and application layers could be maintained, even when a transmission protocol requires some intervention by an application.
The foregoing technical problems are addressed by embodiments of the invention providing technical solutions. SUMMARY OF THE INVENTION
According to a preferred embodiment of the present invention, there is provided a method of responding to a command from an interface device by an integrated circuit card. The integrated circuit card comprises a microprocessor and a memory coupled to the microprocessor. The method includes the steps of
selecting an expected case for the command representing whether data is to be transferred between the interface device and the integrated circuit card, determining
whether the expected case is applicable to the command, and processing the command if the expected case is applicable to the command. An example of an expected case is one of the four cases defined under ISO 7816-4.
The method in accordance with the preferred embodiment of the
present invention may be used where the command is transmitted from the interface device to the integrated circuit card under a transmission protocol requiring the integrated circuit card to have prior information related to the data, if any, to be transferred. For example, the method of the present invention may be used with the
T=0 protocol defined by ISO 7816-3. The method of the present invention may also be used when the interface device and the integrated circuit card support a plurality of transmission protocols.
Preferably, the integrated circuit card comprises an application stored
in the memory, and the selecting and processing steps are performed by the application. Moreover, before the selecting step, the method of the present
invention preferably further includes the step of determining whether the command is recognized by the application. It is also preferred that the integrated circuit card comprises an
operating system stored in the memory and that the determining step is performed by a function of the operating system. Before the step of determining whether the expected case is applicable to the command, the method of the present invention may also include the step of calling by the application a function of the operating
system with the expected case. The application may then receive a return value from the function indicative of whether the expected case is applicable to the command.
Preferably, the memory of the integrated circuit card comprises a publicly available memory space and a stack. The method of the present invention may then include the steps of communicating between the operating system and the application using the publicly available memory space or the stack. In addition, the application and the operating system may communicate with each other through a register in the integrated circuit card. The method of the preferred embodiment of the present invention may also include the step of determining by the function called by the application whether data is to be received from the interface device. If data is to be received, the method may also include the step of receiving such data.
After the application has called the operating system function, the
method of the present invention may also include the step of responding by the operating system to subsequent commands by the interface device related to the initial command without interaction between the operating system and the application. For example, if the T=0 protocol defined under ISO 7816-3 is used, the operating system may respond to GET RESPONSE commands without interaction with the application, after the application has called the appropriate operating system function with the expected case of the command.
The method of the preferred embodiment of the present invention may also include the step of communicating response data by the application to the
operating system if the return value from the called function is positive. The response data is to be transmitted by the integrated circuit card to the interface
device.
In accordance with another aspect of the present invention, there is provided an integrated circuit card for use with an interface device. The integrated circuit card includes a microprocessor, a memory coupled to the microprocessor, means for selecting an expected case for a command transmitted by the interface device, where the expected case represents whether data is to be transferred between the interface device and the integrated circuit card, means for determining whether the expected case is applicable to the command, and means for processing the command if the expected case is applicable to the command.
BRIEF DESCRIPTION OF THE DRAWINGS Embodiments in accordance with the invention will now be
described, by way of example only, with reference to the accompanying drawings, in which:
Fig. 1 is a schematic representation of an IC card in accordance with a preferred embodiment of the present invention; Fig. 2 is a perspective view of an IC card and terminal in accordance
with a preferred embodiment of the present invention;
Fig. 3 is a functional block diagram of an IC card in accordance with a preferred embodiment of the present invention; Fig. 4 is a block diagram illustrating an exemplary code space, data
space, address registers, and control registers for an abstract machine architecture that may be used in accordance with a preferred embodiment of the present invention;
Figs. 5 is a diagram illustrating the cases of commands defined by
ISO 7816-4;
Fig. 6 is a diagram illustrating the structure of a message under the T=l protocol defined by ISO 7816-3;
Fig. 7 is a diagram illustrating the chaining function of the T=l protocol defined by ISO 7816-3; Fig. 8 is a flowchart illustrating the steps for processing a command received from an interface device by an IC card in accordance with a preferred embodiment of the present invention;
Fig. 9 is a flowchart illustrating the steps for a routine for checking
the case of a command in accordance with a preferred embodiment of the present invention;
Fig. 10 is a flowchart illustrating the steps for a routine for checking the case of a command under the T=0 protocol in accordance with a preferred
embodiment of the present invention; Fig. 11 is a flowchart illustrating the steps for a routine for checking
whether a command is consistent with a case 1 command under the T=0 protocol in accordance with a preferred embodiment of the present invention;
Fig. 12 is a flowchart illustrating the steps for a routine for checking whether a command is consistent with a case 2 command under the T=0 protocol in
accordance with a preferred embodiment of the present invention;
Fig. 13 is a flowchart illustrating the steps for a routine for checking whether a command is consistent with a case 3 command under the T=0 protocol in accordance with a preferred embodiment of the present invention; Fig. 14 is a flowchart illustrating the steps for a routine for checking whether a command is consistent with a case 4 command under the T=0 protocol in accordance with a preferred embodiment of the present invention;
Fig. 15 is a flowchart illustrating the steps for a routine for checking
the case of a command under the T=l protocol in accordance with a preferred embodiment of the present invention;
Fig. 16 is a flowchart illustrating the steps for a routine for initializing communications information and for processing the GET RESPONSE
command under the T=0 protocol in accordance with a preferred embodiment of the present invention;
Fig. 17 is a flowchart illustrating the steps for a routine for receiving data from an interface device under the T=0 protocol in accordance with a preferred embodiment of the present invention;
Fig. 18 is a diagram illustrating an exemplary communication between an interface device and an IC card under the T=0 protocol;
Fig. 19 is a flowchart illustrating the steps for a routine for transmitting response data and procedure bytes to an interface device in accordance with a preferred embodiment of the present invention; and Fig. 20 is a flowchart illustrating the steps for a routine for
initializing communications information and for processing the GET RESPONSE command under the T=l protocol in accordance with a preferred embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
Fig. 1 provides a schematic representation of a typical IC card 10 that can be used with the presently claimed invention. The IC card 10 includes an integrated circuit 12 having one or more electrical contacts 14 connected to the integrated circuit 12. Fig. 2 shows an example of a device with which the IC card 10 communicates. As used in this specification and the appended claims, the terms "interface device" and "terminal" shall be used to generically describe devices with
which an IC card may communicate. A typical terminal 20, as shown in Fig. 2, includes a card reader 22, a keypad 24, and a display 26. The keypad 24 and the display 26 allow a user of the IC card 10 to interact with the terminal. The keypad 24 allows the user to select a transaction, to enter a personal identification number
("PIN"), and to enter transactional information. The display 26 allows the user to
receive informational messages and prompts for data entry. Other types of terminals may include IC card-compatible ATM machines and telephones.
Fig. 3 provides a functional block diagram of the integrated circuit 12. At a minimum, the integrated circuit 12 includes a processing unit 100 and a
memory unit 110. Preferably, the integrated circuit 12 also includes control logic 150, a timer 160, security circuitry 170, input/output ports 180, and a co-processor 190. The control logic 150 provides, in conjunction with the processing unit 100, the control necessary to handle communications between the memory unit 110 and
input/output ports 180. The timer 160 provides a timing reference signal for the processing unit 100 and the control logic 150. The security circuitry 170 preferably provides fusible links that connect the input/output ports 180 to internal circuitry for testing during manufacturing. The fusible links are burned after completion of testing to limit later access to sensitive circuit areas. The co-processor 190 provides the ability to perform complex computations in real time, such as those required by cryptographic algorithms. The memory unit 110 may include different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. For example, as shown in Fig. 3, the memory unit 110 may include read-only memory
(ROM), electrically erasable programmable read-only memory (EEPROM), and random-access memory (RAM).
The memory unit 110 stores IC card data such as secret cryptographic keys and a user PIN. The secret cryptographic keys may be any type
of well-known cryptographic keys, such as the private keys of public-key pairs. Preferably, the secret cryptographic keys are stored in a secure area of ROM or EEPROM that is either not accessible or has very limited accessibility from outside
the IC card.
The memory unit 110 also stores the operating system of the IC card.
The operating system loads and executes IC card applications and provides file management and other basic card services to the IC card applications. Preferably,
the operating system is stored in ROM.
In addition to the basic services provided by the operating system,
the memory unit 110 may also include one or more IC card applications. For example, if the IC card is to be used as an electronic cash card, an application called MONDEX™ PURSE (from Mondex International Limited) might be included on the IC card, which loads an electronic value of a certain currency from a user's account in a financial institution onto the IC card. Preferably, the operating system of the IC card 10 supports multiple applications, such as the MULTOS™ operating system from Mondex International Limited. An IC card application may include both program and data files, which are typically stored in EEPROM. The application program may be written either in the native programming code of the processing unit 100 or it may be
written in a higher level language that must be translated before it is executed on the processing unit 100. An example of such a higher level language for use on IC cards is the MULTOS™ Executable Language (MEL). Advantageously, by using a
higher level language such as MEL, an application program is capable of running
on multiple hardware platforms without any need for re-writing.
Because IC cards typically have limited memory capacity due to the size and cost restraints of placing memory on the IC cards, an IC card may also have primitives stored in ROM, which are subroutines that perform frequently used functions or procedures, such as mathematical functions. The primitives are usually
written in the native language of the processing unit 100 so that they can be executed very quickly.
Preferably, the operating system of the IC card 10 imposes a layer of abstraction between an application and the underlying hardware of the IC card 10.
This abstraction layer permits the application to be hardware independent and to run on multiple IC cards. From the standpoint of the application, it is executing on an "abstract machine" defined by the operating system.
Fig. 4 illustrates an exemplary architecture of an operating system
"abstract machine." The abstract machine contains a memory space for each of the program code and data of an application, referred to as the code space 200 and the data space 300, respectively. An exemplary size for each of the code and data spaces is 64K bytes.
The program code in the code space 200 is stored in non-volatile memory such as EEPROM and is addressed by the Code Pointer (CP) register 202
which must be at least sixteen (16) bits to address the entire 64K bytes of the code space.
The data space 300 is divided into three segments: the static segment
302, the dynamic segment 304, and the public segment 306. The static segment
302 contains non- volatile data, which can be stored in EEPROM, while the dynamic segment 304 and the public segment 306 contain volatile data, which can be stored in RAM. As shown in Fig. 4, there may be gaps between the segments, so that not
all of the 64K of data space is used.
The static segment 302 contains the application's non-volatile data.
Static data includes cardholder data, such as a card user's name, address, account number, and PIN. Static data also includes variable transactional data, such as the electronic value of a purse or the available credit limit of a credit/debit application.
The dynamic segment 306 contains the application's volatile or temporary data. Dynamic data includes data which is temporarily used during the execution of an application such as intermediate values used in calculations or working variables. For example, a purse application may temporarily store the value of a transaction in order to reduce the amount of the value in the purse. The
dynamic segment is used in much the same way as a conventional computer program uses RAM to perform its assigned operations. The dynamic segment preferably is divided into two parts, the session data portion and the stack data portion. The size of the session data portion is a constant for each application and is determined when the application is loaded. The data in the session data portion retains its value for the duration of a session in which the application is involved. A typical use for the session data portion is to support the use of a session PIN. The stack data portion holds variable data which is unique to the particular
transaction being executed. The stack data portion stores data in a last-in-first-out
manner. The stack is initially empty, but expands and contracts during execution of
the application. The data in the dynamic segment is private to an application and cannot be read by other applications. The public segment is used to store commands and response data
passed between an interface device and an application. Applications may also use the public segment for temporary working storage of data, but any data written into the public segment may be available to the interface device. The data space 300 is preferably addressed using seven address registers: Static Base (SB) 308, Static Top (ST) 310, Public Base (PB) 312, Public
Top (PT) 314, Dynamic Base (DB) 316, Local Base (LB) 318, and Dynamic Top
(DT) 320. Each of these registers is preferably a sixteen-bit register. These registers define the boundaries of the static, dynamic, and public segments of the data space 300. Each base register contains the address of the first byte in each segment, and each top register contains the address of the byte immediately after
the last byte in each segment. The LB register 318 acts as a stack pointer for the stack data portion of the dynamic segment. The address registers can contain physical memory addresses but preferably contain offset addresses in order to be hardware independent.
The abstract machine architecture also contains a Condition Code Register (CCR) 400, which contains bits that are set or cleared based on the result of an operating system or primitive instruction call. An exemplary eight-bit CCR is defined in Table 2. Table 2: Exemplary Code Condition Register
Figure imgf000018_0001
A more complete description of an implementation of an abstract machine architecture for an IC card operating system is set forth in the U.S. patent application entitled "Multi- Application IC Card with Delegation Feature" of Everett et al., filed April 23, 1998, which is incorporated herein by reference to Annex A attached hereto.
The low-level communications handler of the operating system may use the public segment 304 to communicate with an application. Table 3 shows an exemplary mapping of the communications buffer of the low-level communication handler onto the public segment. The communication information mapped onto the public segment in Table 3 is consistent with ISO standards 7816-3 and 7816-4 and will be better understood in light of the following discussion. Table 3: Public Communications Map
Figure imgf000019_0001
To enable the inter-operability of IC cards, IC cards typically follow conventional, industry-wide standards, such as ISO 7816-3 and 7816-4. ISO 7816-3
defines the low-level details of the transmission link between an IC card and an interface device, such as the transmission protocol. ISO 7816-4 defines the format of commands exchanged between interface devices and IC cards. Beginning with the ISO 7816-4 standard, the ISO 7816-4 standard
defines a command having a mandatory header of four (4) bytes and an optional body of variable length. Table 4 sets forth the definition of the command header under ISO 7816-4. The CLA class byte of the command header specifies the extent to which the command and response comply with ISO 7816-4. The INS instruction
byte specifies the command function. For example, ISO 7816-4 defines a hexadecimal value of "A4" for INS as a SELECT FILE command. The PI and P2 parameter bytes provide qualifying information for a command. If no qualification is necessary, then PI and P2 are set to zero.
Table 4: ISO 7816-4 Command Header
Figure imgf000020_0001
e comman o y s con ona an epen s on w e er ere s any data associated with the command or expected with the response. For each case of a command, the structure of the command is illustrated in Figs. 5A to 5D. In the figures, Lc represents the length of the data associated with the command, and Le represents the maximum length of the data expected to be returned with the
response. Lc and Le may be either one, two, or three bytes. When Lc and Lc are one byte, the cases are referred to as "short." In short cases, Lc may be a number between 1 and 255 (zero is not permitted), and Le may be a number between 1 and 256 (zero is interpreted as 256). When Lc and Le are more than one byte, the cases are referred to as "extended." In extended cases, Lc is coded on three bytes, with
the first byte being zero and the subsequent two bytes being non-zero. Thus, Lc may take on a value from 1 to 65,535. For an extended case 2, Le is also coded on three bytes with the first byte being zero. For an extended case 4, Le is coded on only 2 bytes. In both an extended case 2 and an extended case 4, Le may take on a
value from 1 to 65,536 (a zero value representing the number 65,536). Table 5 shows the decoding of the case of a received command using the length of the command body (L), the value of the first byte of the command body (B,), and the value of the second and third bytes of the command body (B23).
Table 5: Decoding of Command Cases
Figure imgf000022_0001
Turning now to the ISO 7816-3 standard, ISO 7816-3 defines two transmission protocols, referred to as the "T=0" and "T=l" protocols. The T=0 is
-20-
LE 2 an asynchronous, half-duplex, character-oriented protocol, while the T=l protocol is an asynchronous, half-duplex, block-oriented protocol.
Under the T=0 protocol, an interface device initiates the processing
of a command by transmitting 5 bytes, designated CLA, INS, PI, P2, and P3. CLA, INS, PI, and P2 correspond to the similarly-named command header bytes defined in ISO 7816-4. P3 is defined as shown in Table 6. In Table 6, B3 refers to the third byte of the command body.
Table 6: Definition of P3 for T=0 Protocol
Figure imgf000023_0001
Under the T=0 protocol, after transmission of the five (5) bytes, the interface device waits for a procedure byte from the IC card. The IC card may respond with three types of procedure bytes: an ACK byte, a NULL byte, or a SW1 byte. An ACK byte permits the subsequent exchange of data to or from the IC
card. A NULL byte resets the waiting time of the interface device. The NULL byte is used when the IC card needs more time to process a command. A SW1
byte instructs the interface device to wait for an SW2 byte from the IC card. Together, the SW1 and SW2 bytes provide the interface device with status
information. The particular coding of these procedure bytes is not relevant for the purposes of this specification. As shown in Table 6, when the case of a command is an extended case 2 (with Le greater than 256) or case 4 (either short or extended), Le is either
partially or completely missing from the five-byte header sent from the interface device to the IC card. In these cases, to receive the appropriate amount of data, the interface device is required to send one or more subsequent GET RESPONSE commands with P3 equal to the number of bytes to receive (256 or less).
Fig. 6 shows the structure of messages transmitted between an interface device and an IC card using the T=l protocol. The protocol defines a block having mandatory prologue and epilogue fields and an optional information field. The prologue field contains three bytes: a node address (NAD) byte, a protocol control byte (PCB), and a length (LEN) byte. The NAD byte is used to identify the source and destination of the block. The PCB is used to convey control
information regarding the block. The LEN byte indicates the number of bytes in the information (INF) field, which may be 0 to 254 bytes. The presence of the INF field is optional. When present, it conveys either application-related or status information. The epilogue field contains an error detection code (EDC), which may be either LRC (longitudinal redundancy check) or CRC (cyclical redundancy
check). As illustrated in Fig. 7, the T=l protocol supports chaining of blocks.
Chaining refers to the segmentation of data and the transmission of the segmented
data over several blocks. Chaining is used when the data to be transmitted is
greater than 254 bytes, which is the maximum number of bytes supported by the INF field. Chaining is supported through the PCB, which includes a "More Data bit" (or M-bit). The M-bit is set when chained data follows in subsequent blocks and is cleared to indicate the last (or only) block in a chain.
When the T=l protocol is used, the complete command header and command body of a command defined under ISO 7816-4 are transmitted in the INF field of a block. Thus, without knowing anything about the function of a command, an operating system may determine the case of the command using the decoding rules in Table 5.
Under the T=0 protocol, however, an IC card cannot decode the case of a command simply from the five-byte header sent from the interface device to the IC card because the entire command and data may not be transferred in those
initial five bytes. Because of the truncation of information under the T=0 protocol,
the same five bytes may be transmitted for different cases. For example, for any
given command, an interface device will transmit exactly the same five CLA, INS, PI, P2, and P3 bytes for a short case 2 with Le=256 and an extended case 2 with Le>256. (In both cases, P3=0.) Moreover, an IC card cannot distinguish between a case 3 and a case 4 command from the five-byte header sent from an interface device because Le is not part of that five-byte header.
Indeed, under the T=0 protocol, ISO 7816-3 explicitly assumes that the IC card and the interface device have information, prior to the transmission of a command, regarding the direction of data, to distinguish between instructions for
data transfers into and out of the IC card. It is also implicitly assumed that the IC card has information regarding the number of bytes of data to be transferred.
Such information is, of course, application dependent. The operating system cannot itself know this information. Thus, to properly process a command under the T=0 protocol, the intervention of the currently selected application is
necessary. Such intervention typically requires the application to delve into the details of the transmission protocol. Such intervention is undesirable, however, because it destroys the independence of the transmission and application layers. Such layer independence is advantageous because it saves programming effort on
the part of an application developer and does not require an application to be updated each time a protocol is changed or a new protocol is promulgated.
According to preferred embodiments of the present invention, however, an application need not delve into the details of the transmission protocol
to determine the case of a command. Instead, the operating system passes to the
application the CLA, INS, PI, and P2 bytes when they are received, and the
application merely checks these bytes to determine whether the command is one that the application recognizes and supports. The application then calls an operating system function or primitive, referred to as Check_Case, with the expected case of
the command.
It is expected that because most applications on IC cards are written in conjunction with corresponding applications on interface devices, the applications will know which case of a command to expect. For example, in an electronic purse application, the application would probably know that after it has been selected, it
will be required to transfer the value in the purse. Otherwise, if an application does not expect any particular case for a command, an application may guess a case. In either instance, the application calls the Check_Case function or primitive, which determines whether the command is consistent with the case the application has
passed to it. The CheckjCase function or primitive returns a "true" or "false" value to the application, depending on its determination.
Specifically, with regard to the abstract machine architecture discussed above, an application may PUSH the expected case onto the top of the
stack data portion of the dynamic segment, and CALL the Check Case function or
primitive. The CheckjCase function or primitive may return an answer through the
Z bit of the CCR register.
Advantageously, the use of a Check Case function or primitive permits layer independence between the transmission protocol layer and the
application layer. By using the CheckjCase command, the application is not
required to know which protocol is being used by the IC card or the details of that protocol. Therefore, as new protocols are defined, the application need not be re- written to function with those protocols. In addition, the operating system is not
required to know the context in which the command is sent to perform the
CheckjCase function or primitive. The operating system is only required to determine whether the expected case is consistent with the format of the command received. Thus, the CheckjCase function or primitive accomplishes true
independence of transmission and application layers even when the transmission protocol does not explicitly support such independence.
Fig. 8 is an exemplary flowchart illustrating the steps for processing a command received under the transmission protocol T=0 and using the CheckjCase function or primitive. For purposes of illustration, reference will be made to the communication exchange shown in Fig. 18, which shows an exchange involving an INTERNAL AUTHENTICATE command. An INTERNAL AUTHENTICATE command sends challenge data to an IC card, which receives the data, encrypts it using a secret key, and returns the encrypted data to the interface device. For the purposes of this illustration, it is assumed that an application is involved in processing the INTERNAL AUTHENTICATE command.
As shown in Fig. 18, an interface device (IFD) initiates the communication exchange by sending the command header 1810, consisting of the five hexadecimal bytes 00, 88, 00, 00, and 03. These bytes correspond to the CLA, INS, PI, P2, and P3 bytes defined by the T=0 protocol. In this case the value of
P3 signifies that Lc=3 i.e., there are three bytes of challenge data that the interface device desires to transmit to the IC card. With reference to Fig. 8, the low-level communications handler of the operating system of the IC card receives the T=0 command header from the interface device (IFD) in step 801. In steps 803 and 805, the communications handler stores these bytes in a communications buffer, called commjbuffer, and
calls the subroutine Receive jCommandJTO.
The Receive Command TO subroutine initializes communications
variables and processes GET RESPONSE commands under the T=0 protocol. With reference to Fig. 16, the Receive JCommandJTO subroutine first checks in step 1610 the variable public. protocol lags. expecting gr to determine whether a GET RESPONSE command is expected by the IC card. If the public.protocoljlags.expectingjgr variable is "false," which will be the case when a command header is first received, the Receive Command JTO subroutine initializes the public segment according to the values shown in step 1630. The variables
initialized in step 1630 correspond to those shown in Table 3. Once the variables
in step 1630 are initialized, the Receive jCommandJTO subroutine exits.
With reference to Fig. 8, once the Receive jCommandJTO subroutine has initialized the public segment, the currently selected application is notified of the received command header in step 807 by the use of any conventional means, such as by the use of an interrupt or by setting a bit in the public segment or a
control register that the application can poll.
In step 809, the application checks the bytes public.cla, public. ins, public.pl, and public.p2 in the public segment. Although other protocol-specific information is available in the public segment, such as public. p , an application
need not and, indeed, should not check this information in order to maintain layer independence.
In step 809, if the application recognizes the command defined by
the bytes public, cla, public, ins, public.pl, and public.pl, the application determines
the expected case of the command. Using the INTERNAL AUTHENTICATE command as an example, the application would expect a case 4, since it expects to receive and send data. The application pushes this expected case onto the stack portion of the dynamic segment, and in step 813, calls CheckjCase.
In step 815, CheckjCase checks the consistency of the command header received from the interface device against the expected case provided by the application. Depending on whether the expected case is consistent with the command header, CheckjCase sets the status variable check_case_response. status equal to "success" or "failed." In step 817, if the expected case is 3 or 4 (command
data is expected to be received), Check Case calls the Cmd Data Rxed subroutine, which handles receiving the command data.
With reference to Fig. 17, the Cmd_Data_Rxed subroutine checks in
step 1710 whether the flag public.protocoljlags.cmd datajxd is "false." If it is
not "false," indicating data has already been received, the subroutine exits. If it is
"false," in step 1720, the subroutine transmits an ACK byte to the interface device, which signals the interface device to send command data. In steps 1730 and 1740, the subroutine receives the command data from the interface device and sets the command data in the data field of the public segment, public.datajield. The
Cmd Data Rxed subroutine then sets the flag public.protocolJlags.cmd data xd to "true," to indicate that the command data has been received.
Returning to the example of Fig. 18, the Cmd_Data_Rxed subroutine transmits the ACK byte 1820, which consists of the INS byte of the command
header, hexadecimal value 88. Three bytes of data 1830 are then transmitted by the interface device and received by the IC card, for storage in the public segment by the Cmd_Data_Rxed subroutine.
Returning once more to Fig. 8, once the Cmd_Data_Rxed subroutine is finished receiving data and returns control to the operating system, the operating system of the IC card in step 821 sets or clears the Z-bit of the CCR register based on the value of check_case_response. status. Control is then returned to the application, which checks the Z-bit of the CCR register to determine whether
CheckjCase successfully verified its expected case. In step 823, if Check Case
successfully verified the expected case of the command, the command is processed. Otherwise, an error routine is called.
In step 825, if the case of the command is either 2 or 4 (data is to be sent to the interface device), the application sets the data and the length of the data
in the public segment, in public.datajield and public. la, respectively. The application then returns control to the operating system by a system call.
In step 827, the operating system calls the Transmit _Response subroutine, which transmits the appropriate procedure bytes to the interface device, depending on the status of the protocol flags set in the public segment. The
Transmit ^ Response subroutine also sets the flag public.protocol lags. expecting gr to "true" under appropriate circumstances. For example, in a case 4 command, as in the INTERNAL AUTHENTICATE example above, a GET RESPONSE
command is expected from the interface device. Thus, the Transmit Response subroutine would set the flag public.protocoljlags. expecting gr to "true."
Fig. 19 is a flowchart illustrating the steps of the Transmit _Response subroutine. In step 1910, the subroutine checks whether public.la is equal to zero,
indicating that there is no data to be transmitted from the IC card to the interface device. If public.la is zero, in step 1920, the response Jpdu is set simply to the
procedure bytes public, swl and public. sw2.
If public.la is greater than zero, in step 1930, it is checked whether
public.la is greater than the size of the public segment less the size of the communications parameters stored in the public segment. If this is the case, then
public.la is greater than the data field size. Accordingly, in step 1940, the response is set to hexadecimal value "6F00," indicating a fatal error.
If public.la is within the bounds of the size of the data field in the
public segment, in step 1950, it is checked whether public.protocoljlags. le ialid is
"false," indicating that the expected length of the response data is not yet known. It
is also checked whether public.le is greater than public.la, indicating that the interface device requested more data than is actually available from the currently
selected application. If either of these conditions is met, in step 1960, the first procedure byte of the response is set Xo public.get_response.swl, indicating that the IC card has data available for the interface device. The second procedure byte is set to the length of the data available, either public.la if public.la is less than 256 bytes or hexadecimal "00" if public.la is equal to or greater than 256 bytes. In the
case that public.la is equal to or greater than 256 bytes, more than one data transmission from the IC card to the interface device will be needed. In step 1970, public.protocoljlags. expectingjgr is set to "true," since it is expected the interface device will send a GET RESPONSE command to the IC card in response to the procedure bytes indicating that data is available. If the expected length of the response data is known and is less than the actual length of the response data, in step 1980, it is checked whether public.le is greater than zero. If public.le is greater than zero, in step 1990, the variable
data, which is initialized to null by the operating system, is set to the data in the data field of the public segment. In step 1995, the response is set to: (1) an ACK
procedure byte (public.ins), indicating that data may follow; (2) the response data (either null or the data in the data field of the public segment); and (3) the procedure bytes public, swl and public. sw2 (which will normally indicate the
completion of the command).
With reference to the example of Fig. 18, the Transmit Response subroutine transmits the procedure bytes SWl and SW2 with hexadecimal values of "61" and "04," respectively. The hexadecimal value "61" for SWl informs the
interface device that the IC card has data to transfer, and the hexadecimal value "04" for SW2 informs the interface device of the number of bytes to be transferred (in this case, four). These bytes are transferred in step 1960 of Fig. 19 because it is not known what the expected length of the data is (since Le is not transmitted with
the T=0 header). In step 1970 of Fig. 19, public.protocolJlags.expecting_gr is set
to "true."
With reference to Fig. 18, when the interface device receives the SWl and SW2 procedure bytes 1840 from the IC card, the interface device sends a GET RESPONSE command 1850 with Le (P3) equal to the number of bytes to be transferred (in this case, four).
Returning to Fig. 8, the low-level communications handler once again receives a T=0 command header in step 801. Again, in steps 803 and 805, the communications handler stores the header in the comm bu fer and calls the
Receive Command JTO subroutine.
Referring once more to Fig. 16, the Receive JCommandJTO subroutine again checks the status of the flag public.protocoljlag.expecting_gr. Since
Transmit Response has set the flag to "true," Receive Command JTO proceeds to
step 1620. In step 1620, the Receive JCommandJTO subroutine first determines if
P3 is equal to zero. If it is, then public.le is set to 256. (Since GET RESPONSE is defined as a case 2 command by ISO 7816-4, then P3=Le as set forth in Table 6.
Moreover, if Le=0, 256 bytes of data are expected.) The Receive Command JTO then processes the GET RESPONSE command, which involves transmitting the
data in the data field of the public segment, public.datajield, followed by the appropriate procedure bytes.
With reference to Fig. 18, Receive jCommandJTO transmits response 1860, which consists of an ACK byte (set to the INS of the GET RESPONSE
command), the data to be transferred to the interface device, and procedure bytes SWl and SW2 (set to Hex "9000," indicating the completion of the command). The processing of a command received under the T=l protocol is similar to the processing shown in Fig. 8 with regard to the T=0 protocol. It is noted that CheckjCase is used for processing the command, even though under the
T=l protocol the operating system may determine the case of a command without any intervention by an application. Nonetheless, to maintain a consistent interface and layer independence, all protocols must be supported by CheckjCase.
Under the T=l protocol, when the low-level communications handler of the operating system receives a T=l block, the low-level communications handler
extracts the information contained in the INF field using the control information in the PCB byte. The low-level communications handler also checks the error detection code (EDC) to ensure that a communications error has not occurred. If the PCB indicates that chained blocks follow, the low-level communications handler
waits for the chained blocks. As it receives the blocks, the low-level communications handler chains the data in the blocks. After the last block is received, the low-level communications handler calls the Receive Command T1
subroutine, which is the T=l counterpart of the Receive Command JTO subroutine.
Fig. 20 is a flowchart illustrating the steps for the Receive Command JT1 subroutine. In step 2010, the subroutine checks whether public.protocoljlags.expectingjgr is "true," indicating the operating system is expecting a GET RESPONSE command from the interface device. If the flag is set
to "true" and the command is a GET RESPONSE command, in step 2020, the GET
RESPONSE command is processed. If i e public.protocolJlags.expecting_gr is "false," in step 2030, various communications variables are initialized. In step 2040, the communications variables public.protocoljlags.le yalid,
public.protocoljlags. lc yalid, public.protocoljlags. cmd_data rxd, public.le, and
public.le are set according to body of the command received by the low- level
communications handler and stored in commJyuffer. Tl Jody, using the decoding rules set forth in Table 5.
When the Receive jCommandJ l has completed its processing, the
processing of the received command proceeds in the same way as described with regard to Fig. 8 for a T=0 command after step 805. Figs. 9 to 15 are flowcharts setting forth exemplary, detailed steps of the CheckjCase function or primitive. In Fig. 9, steps 910 and 930, CheckjCase
checks if the protocol type is T=0 or T=l. If the protocol type is one of these
protocols, the appropriate subroutine, CheckjCase JTO or CheckjCase JT1, is called in either of steps 920 and 940. If the protocol type is unrecognized by Check Case, then in step 950, check_case esponse. status is set to "failed."
Fig. 10 illustrates an exemplary embodiment of the CheckjCase JTO
subroutine. In step 1010, a default value of "success" is assigned to check_case_response. status. In step 1020, CheckjCase TO checks whether the flags public.protocoljlags.pi jyalid, public.protocoljlags. lc yalid, and public.protocoljlags. Ie yalid are in the initialized states set by
Receive JCommandJTO. If they are not, check_case_response. status is set to
"failed." If the flags contain proper values, in steps 1030 to 1060, CheckjCase JTO checks whether the application expects case 1, 2, 3, or 4. In step 1070, if the application has passed an expected case that is not 1 to 4,
check casej-esponse. status is set to "failed." In the last step, step 1080, if the
subroutine has been successful, public.protocolJlags.p3 yalid is set to "false" (indicating that CheckjCase has checked the command header) and public.protocoljlags. Icj'alid is set to "true" (since, CheckjCase will set the correct public.le).
Fig. 11 is a flowchart illustrating the steps for the case 1 logic of the CheckjCase JTO subroutine. In step 1110, if the T=0 protocol byte P3 is valid and greater than zero, then the command is inconsistent with case 1 (see Table 6). Thus, check_case_response. status is set to "failed." In steps 1120 and 1130, if
either of the Lc or Le bytes are valid and greater than zero, then the command
header is inconsistent with case 1 (which requires no command or response data). Thus, check_case_response. status is set to "failed." Otherwise, public.le and public.le are set to zero and the public.protocoljlags. le valid is set to "true." (The
flag public.protocoljlags.lc jyalid is set by default in step 1080 of Fig. 10.)
Fig. 12 is a flowchart illustrating the steps for the case 2 logic of the CheckjCase JTO subroutine. In step 1210, if Lc is valid and greater than zero, CheckjCase fails (because case 2 does not expect command data). In step 1220, if
Le is valid and equal to zero, CheckjCase fails (because case 2 expects response
data). In step 1230, public.le is set to zero (indicating no command data is present). In steps 1240 and 1250, if P3 is valid and greater than zero, the flag public.protocoljlags. le jyalid is set to "true" and public.le is set to public. p3 (see
Table 6). If P3=0, the expected length of the response data is not known (because
P3=0 is consistent with an expected data length of equal to or greater than 256 bytes). Thus, public.le jyalid is not set to "true" (it remains "false"). The state of the public.le jyalid variable is used in the Transmit _Response subroutine to determine the proper procedural bytes to send (see step 1950 of Fig. 19).
Fig. 13 is a flowchart illustrating the steps for the case 3 logic of the
CheckjCase JTO subroutine. In step 1310, if P3 is valid and greater than zero (which is required for case 3), public.le is set to public.p3 (see Table 6). Otherwise, in step 1320, other conditions inconsistent with case 3 are checked. In step 1330, the flag public.protocoljlags.le jyalid is set to "true" and public.le is set
to zero (because no response data is to be sent for case 3). In step 1340, the
Cmd Data Rxed subroutine, previously described with reference to Figs. 8 and 17, is called, to receive the command data from the interface device. Fig. 14 is a flowchart illustrating the steps for the case 4 logic of the
CheckjCase JTO subroutine. In step 1410, if P3 is valid and greater than zero
(which is required for case 4), public.le is set to public.p3 (see Table 6). Otherwise, in step 1420, other conditions inconsistent with case 4 are checked. In step 1430, the Cmd Data Rxed subroutine, previously described with reference to Figs. 8 and 17, is called, to receive command data from the interface device.
Fig. 15 is a flowchart illustrating the steps for the CheckjCase T1
subroutine. It is noted again that, under the T=l protocol, the operating system does not require the intervention of an application to determine the case of a command. Nonetheless, to maintain a consistent interface and layer independence, all protocols must be supported by CheckjCase.
In step 1510, a default value of "success" is assigned to check_case_response. status. In steps 1520, 1540, 1560, and 1580, CheckjCase T1 determines whether the expected case is 1, 2, 3, or 4, respectively. If the expected
case is not one of these cases, in step 1595, a value of "failed" is assigned to
check casejresponse. status. In each of steps 1530, 1550, 1570, and 1590, CheckjCase JT1 checks for conditions that are inconsistent with the cases 1, 2, 3, and 4, respectively, using the communications variables set by the
Receive Command Tl subroutine. If inconsistent conditions are found, the value of
"failed" is assigned to check casejresponse. status. Otherwise, CheckjCase JT1
exits (with the default value of "success" assigned to check case response, status). 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. The scope of the present disclosure includes any novel feature or combination of features disclosed therein either explicitly or implicitly or any generalisation thereof irrespective of whether or not it relates to the claimed invention or mitigates any or all of the problems addressed by the present invention. The application hereby gives notice that new claims may be formulated to such features during the prosecution of this application or of any such further application derived therefrom. In particular, with reference to the appended claims, features from dependant claims may be combined with those of the independent claims in any appropriate manner and not merely in the specific combinations enumerated in the claims.
ANNEX A TϋϊKSCf II
ANNEX A
MULTI-APPLICATION IC CARD WITH DELEGATION FEATURE
ANNEX (. ro rø io-
BACKGROUND OF INVENTION
Integrated circuit ("IC") cards are becoming increasingly used for many different purposes in the world today. An IC card (also called a smart card) typically is the size of a conventional credit card which contains a computer chip including a microprocessor, read-only-memory (ROM), electrically erasable programmable read-only-memory (EEPROM), a random access memory (RAM), an Input/Output (I/O) mechanism and other circuitry to support the microprocessor in its operations. An IC card may contain a single application or may contain multiple independent applications in its memory. MULTOS™ is a multiple application operating system which runs on IC cards, among other platforms, and allows multiple applications to be executed on the card itself. The multiple application operating system present on the IC card allows a card user to run many programs stored in the card (for example, credit/debit, electronic money/purse and/or loyalty applications) irrespective of the type of terminal (i.e., ATM, telephone and/or POS) in which the card is inserted for use.
A conventional single application IC card, such as a telephone card or an electronic cash card, is loaded with a single application card and only executes that one application when inserted into a terminal. For example, a telephone card could only be used to charge a telephone call and could not be used as a credit/debit card. If a card user desires a variety of application functions to be performed by single application IC cards issued to him or her, such as both an electronic purse and a credit/debit function, the card user would be required to carry
Figure imgf000043_0001
multiple physical cards on his or her person, which would be quite cumbersome and inconvenient. If an application developer or card user desired two different applications to interact or exchange data with each other, such as a purse application interacting with a frequent flyer loyalty application, the card user would be forced to swap multiple cards in and out of the card-receiving terminal during the transaction, making the transaction difficult, lengthy and inconvenient.
Therefore, it is beneficial to store multiple applications on the same IC card. For example, a card user may have both a purse application and a credit/debit application on the same card so that the user could select which type of payment (by electronic cash or credit card) to use to make a purchase. Multiple applications could be provided to an IC card if sufficient memory exists and an operating system capable of supporting multiple applications is present on the card.
The increased flexibility and power of storing multiple applications on a single card create new challenges to be overcome concerning the integrity and security of the information (including application code and associated data) exchanged between the individual card and the application provider as well as within the entire system when communicating information between applications.
For instance, the existence of multiple applications on the same card allows for the exchange of data between two applications, while one of the applications is being executed. As stated above, a frequent flyer loyalty program may need to be accessed during the execution of an electronic purse application. If data is passed between applications in an insecure manner, it may be possible for a third party monitoring the transaction to determine the contents of the transferred
Figure imgf000044_0001
data or even other private data associated w t one or ot o t e app ications. Thus, it would be beneficial to provide an application architecture and memory organization which protects an application's data from being discovered by a third party when it is exchanged with other applications present on the IC card. Accordingly, it is an object of the invention to provide an application architecture and memory organization which provides for a secure data interaction between applications and allows multiple applications to be accessed while performing a desired task or function.
SUMMARY OF THE INVENTION
The present invention provides for a multiple application architecture for an IC card called an application abstract machine (AAM) and a method for implementing that architecture. The processing of multiple applications is accomplished by generating for at least one application (the "first application") a data memory space including at least two segments, a volatile memory segment and a non- volatile memory segment, commencing the execution of the first application's instructions; delegating or switching execution from the first application to the delegated application and in so doing, saving any data generated by the first application in the logical data memory space associated with the first application; executing the second application's instructions; retrieving the saved data and completing with this data the execution of the first application's instructions.
-42-
SUBST1TUTE SHEET (RULE 26) ft
Additional delegation commands can be issued by the second application or other subsequent applications. The command delegated is inteφreted by a delegated application in the same manner as a selection command being issued directly by a terminal and therefore each application performs the security functions at the same level as if a terminal is issuing the command.
The volatile memory segment can further be separated into public ("Public") and dynamic ("Dynamic") portions. Data can be exchanged between a plurality of applications and/or a terminal when stored in the Public region of the data memory. The Dynamic memory region can be used solely as temporary work space for the specific application being executed.
BRIEF DESCRIPTION OF THE DRAWINGS
Further objects, features and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying figures showing illustrative embodiments of the invention, in which
Fig. 1 is block diagram illustrating the data memory space segment and associated registers for an IC card application using the AAM organization; Fig. 2 is a block diagram illustrating the code memory and the data memory spaces for an IC card application using the AAM architecture;
Fig. 3 is a flow diagram illustrating the steps of performing a request for a delegation function by one application to another;
Fig. 4 is a flow diagram illustrating the steps of performing a return !ϋ a TO THE DESCRIPTION delegation control function for a delegate application to a delegator application;
Fig. 5 is a flow diagram illustrating the steps of performing an inquire delegator ID request of a delegation function;
Fig. 6 is a block diagram of an IC card chip which can be used as a platform in accordance with the invention; and
Figures 7A, 7B and 7C illustrate multiple delegation calls made between three applications.
Throughout the figures, the same reference numerals and characters, unless otherwise stated, are used to denote like features, elements, components or portions of the illustrated embodiments. Moreover, while the subject invention will now be described in detail with reference to the figures, it is done so in connection with the illustrative embodiments. It is intended that changes and modifications can be made to the described embodiments without departing from the true scope and spirit of the subject invention as defined by the appended claims.
-44-
SUBST1TUTE SHEET (RULE 26) fl TO THE DESCRIPTION
DETAILED DESCRIPTION OF THE INVENTION
The present invention provides for a method and apparatus for processing multiple application programs with associated data stored on an IC card which can be accessed and executed. An application stored on the card can be selected by a terminal, or other interface device, or another application. Each application program which is stored on the IC card when executed is allocated a memory space organized by the program's software code (instructions which are executed by a processor located on the IC card) and the associated data which the application stores and uses during execution of the program.
For example, a multi-application card may store a purse application, or an electronic money application, and a specific loyalty application such as a frequent flyer awards application. Each application has software code and associated data to support the execution of that software code. Each application is allocated a memory space when executed. In this example, there is interaction between the two applications stored on the card. For each dollar electronically spent to make a purchase, the user may be entitled to one frequent flyer mile which is stored and processed by the frequent flyer program. The purse application need not be aware of the specific loyalty program stored on the card, but instead may contain an instruction to communicate with any loyalty program stored on the card. The loyalty program will require input data representative of the amount of a particular electronic value so that it can update its own stored data of current frequent flyer miles for the user of the card. When two applications need to fl fl TO THE DESCRIPTION communicate during the same transaction, a system architecture is required to process both applications in an efficient and secure manner. One approach could be a windows type model where both applications could be running at the same time. Presently, however, IC card platforms are not powerful enough to simultaneously operate multiple programs efficiently. Also, transferred data may be exposed to unwanted third party access. The solution to this problem, provided by the current invention, which is described in greater detail below, is to selectively interrupt the execution of applications in a secure manner. This allows the integrity of the applications' data to be maintained and allows the best utilization of the available memory space in the IC card.
An efficient architecture for processing multi applications in an IC card is termed an Application Abstract Machine (AAM) architecture and is described herein. The AAM Architecture applies to any platform independent of its hardware and enables developers to write applications to store on the IC cards which are portable across many different types of platforms (e.g., IC cards built by different manufacturers with different processor configurations) without the need for knowledge about the specific hardware of the platform.
An application abstract machine (AAM), a term for the memory allocation and organization for the data stored and used by each application, is created for each application stored on the IC card which is executed by the processor on the card. In order to ensure data integrity and security when data is transferred between applications which are executed on the IC card, only one application on the IC card is allowed to be executed at a time. Each application has v (. TO TH£ DESCRIPTION a data memory space which is virtually allocated and mapped onto the physical memory addresses available in the IC card memories. Data is then passed between two or more applications within a specified memory location and in a manner consistent with transferring data to an external terminal or device with which the IC card is securely interacting. At a general level, each AAM space created for each application being executed includes two separate address spaces, one for the program code itself and one for the program data which is stored and/or used by the application. The program data address space is effectively divided into three segments: a Static segment, a Dynamic segment and a Public segment which are described in more detail in conjunction with Figure 1. As stated above, the Static, Dynamic and Public segments are logically mapped to the physical memory; they are virtual memory segments as opposed to physical memory segments. The AAM data address space is preferably addressed and processed using seven different address registers and two control registers. Figure 1 shows an illustrative diagram of a logical data space allocation 101 created for an application used in conjunction with the present invention. The AAM data portion 101 includes a Static data space 103, a Public data space 105 and a Dynamic data space 107. Also shown are a series of address registers: the Static base address register 109, the Static top address register 111, the Public base address register 113, the Public top address register 115, the
Dynamic base address register 117, the Dynamic top address register 121 and local base address register 119 which serves as a local stack frame pointer in the Dynamic data space when the application is being executed. The address registers can contain physical memory addresses but preferably contain offset adαresϋ u fur the various data address spaces in order to be hardware independent. An example of the overall address space is 64K bytes, although the size varies with the applicable platform and the available memory size. The registers can also be considered pointers or can be any other conventional addressing mechanism.
Within the allocated AAM data space 101, the Static portion of the memory is non-volatile which is not erased after power is removed from the IC card (such as EEPROM), the Dynamic space is volatile (such as RAM) which may be erased after power is removed from the card and the Public space is also volatile (such as RAM). An IC card can receive power from a terminal after it is interfaced into the terminal. Although an IC card may contain a battery to maintain some power for memory and circuitry, volatile memory will typically be erased after the IC card is removed from its power source.
The defined AAM data space has bytes in each segment which are contiguous, so that applications can perform pointer and offset arithmetic. For example, if the segment addresses "1515" and "1516," or any other pair of sequential numbers, are both valid and are present within the same segment, then they address adjacent bytes. This allows offset values stored in registers to determine the location of a desired memory address. The segment address of the first byte of the Static segment is zero, so that the segment address of a given location within the Static region is equal to its offset.
Pointers to other specific regions of the Static data area can be stored in the Static data because the Static region is non- volatile. For example, if the card m A TO H user's name is stored in the Static memory of a credit/debit application, the application will know the card user's name will always be stored in the 5th memory location above the starting point for the Static portion of memory. The location can be noted as SB[5] or the 5th byte above the Static Bottom. Since the Static memory is non-volatile, it will not be erased after each transaction and the application will always know of its location relative to the Static segments' address registers. On the other hand, the segment address of any location in the Dynamic or Public segments is not always equal to a particular offset from the beginning of the respective segment because the contents of those segments change for each operation. The fourth location in the Dynamic segment will be different for each operation performed by the application. The address of a memory location of Dynamic or Public segment is fixed preferably only for the duration of one command-response pair operation. Because segment addresses in Dynamic or Public are not fixed, MULTOS Executable Language (MEL)™ instructions (or any other program instructions) cannot refer to data using only segment addresses.
Instead, a tagged address preferably is used to identify data which is to be retrieved, manipulated, transferred and/or stored with the IC card system.
A tagged address is a nineteen bit value consisting of a three bit tag (address register number) and a sixteen bit offset. Each of the seven address registers for the AAM data space contain a segment physical address. For instance, the address registers SB 109 and ST 111 point to the boundaries of the Static, the address registers PB 113 and PT 115 point to the boundaries of the Public and the address registers DB 117 and DT 121 point to the boundaries of the Dynamic. For
-49-
EET RULE 26)
Figure imgf000052_0001
each segment, the top register points to the byte mme ate y a er the last va byte. For example, the last valid byte of the Static is ST[-1]. Register LB functions as a stack frame pointer. It points to a location in the Dynamic segment to indicate a specific byte of local data for the currently executing application. Referring to Figure 1, the allocated Static segment 103 contains the application's non-volatile data. Static data includes data which is associated with each application for every transaction such as the card user's name, account number, PIN value and address. Static data also includes variable data which is stored for use in future transactions using the application. For example, in a purse transaction, the electronic value data would be read from the Static segment and later saved in the Static segment at the end of the transaction. Additionally, transaction information data or available credit limits in the case of a credit/debit application would be stored in Static data.
The Static data is addressed using register SB (Static Base) and the register ST (Static Top) as offset registers. These registers contain the offset value from a physical address in a memory on the IC card. The individual memory location is then further offset from these starting points such as SB[3] or ST[-5]. SB is defined as zero and ST is equal to the size of the application's Static data which is set when the application is loaded onto the IC card. The multiple application operating system ensures that no other application can read or write the data stored in the Static segment of a particular application. Using current technology, the Static segment is preferably mapped onto an EEPROM (Electrically Erasable Programmable Read-Only Memory) which is non-volatile. 2152
, iif f) TOMSESCWON
The Dynamic segment 107 contains me appli au * vu u «ι temporary data. Dynamic data includes data which is temporarily used during the execution of an application such as intermediate values used in calculations or working variables. For example, a purse application may temporarily store the value of a transaction in order to reduce the amount of the value in the purse. The temporary data is used much like conventional computer programs use RAM to perform their assigned operations. The Dynamic segment preferably is divided into
two parts, the session data portion and the stack data portion. The size of the session data is a constant for each application and is determined when the application is loaded. The stack holds variable data which is unique to the particular transaction being executed. The stack data portion stores data in a last-in- first-out manner. The stack is initially empty, but expands and contracts during
execution of the application.
The Dynamic data is addressed from the register DB 117 to register
DT 121. Register LB 119 serves as a local stack frame pointer to particular memory locations in the Dynamic segment for delegate commands or function calls. Register LB 119 is used to address the topmost frame, that of the currently executing function's session data. Register DT 121 serves as an address offset for the stack pointer. A one byte data item at the top of the stack is addressed as DT[-
1], the next byte below is addressed by DT[-2], and so on. A push operation increments the relative value of DT for each item on the stack and a pop operation decrements the relative value of DT for each item on the stack. For example, a data element located at DT[-5] will be located at DT[-6] after an additional data ~ „«„M« M O 98/52152
JUKI A TO THE DESCRIPTION item is placed on the stack.
When an application is being executed, the Dynamic segment created
for that application also contains the application's session data which is used in performing the assigned task(s) or operation(s). The multiple application operating 5 system ensures that no other application can read or write the data stored in the Dynamic segment of a particular application. The session data is set to zero upon the start of the execution of the application. Stack data will be saved in the stack if the application delegates a task or operation to another application.
A delegation function occurs when one application selects another 10 application to process a command instead of processing the command itself. An example of a delegation function occurs when a delegator application receives a command that it does not recognize or is not programmed to process. The selected application should not reject the command and provide an error response to the interface device (IFD), but instead should pass the command to the appropriate 15 receiver, or delegated application. In order to perform a delegation, the delegator calls the Delegate primitive. The Delegate primitive is a subroutine recognized by the multiple application operating system which is executed when the operating system interprets the Delegate instruction. Primitives can be stored as part of the operating system itself, loaded as a separate routine when the operating system is 20 installed. Primitives are preferably written in machine executable language so that they can be executed quickly although they could be written in a higher level language. When a Delegate command is executed, execution of the delegating application is suspended, and the delegated application is executed instead. The HEX ' TO THE DESCRIPTION delegated application then generates its own data memory space according to the AAM architecture. The data stored in the Public memory space of the first application (stored in RAM) is sent to the Public memory space of the second application (which could be physically the same memory but is allocated separately for each application) so that data can be passed between the applications. The Dynamic memory space is also shared although data is saved in a stack for the delegator and the other portions initialized before the delegated application is executed because the Dynamic data is secret.
In most cases, the delegated application processes the command exactly as though the command has arrived directly from an interface device. When the delegated application has finished processing the command, and has written a response into the allocated Public memory segment, it exits as normal. The delegator then resumes execution at the instruction address following the executed instruction which called the Delegate primitive. The response generated by the delegated application is retrieved or accessed from the allocated Public memory space. The delegator application may simply exit in turn, thus sending the response to the IFD, or may carry out further processing before exiting.
Another example of a delegation operation occurs when two applications need to share data. If an application A always returns a data item N when processing a command B, then another application which also returns data item N in response to a command can delegate the function B to application A in order to reduce the need for duplicate codes stored on the IC card. For example, if a PIN needs to be checked before an application is executed, an application stored β A ΪOT-EMIPTIi on the card can delegate the "retrieve PIN function" to a PIN application which returns a stored universal PIN for the card.
Preferably, a new session begins whenever the IFD, e.g. a terminal, successfully selects an application, even if the application has been previously selected during the transaction. For example, if a card user goes to a terminal and transfers twenty dollars of electronic cash using a purse application, charges thirty dollars using a credit/debit application and then transfers ten dollars using the purse application again, three separate sessions will have occurred even though only two applications were used during the entire transaction. Each time an application delegates a task or function to another application, the delegated application treats the delegate function as if the IFD devices had selected the application to perform the task or function. However, performing a delegation function as described below has a different effect on session data.
The following examples will help explain when the session data is initialized (i.e., erased) versus when it is saved to be used in further operations. If application A is selected by an IFD device, and receives commands X, Y and Z from the terminal, application A may delegate all three commands to application B. For example, delegations may occur in response to delegation commands in the program code. Both applications A and B will have their session and stack data in their respective Dynamic segments initialized (set to zero) when they receive command X, but the stack will not be initialized when they receive the subsequent commands Y and Z.
In a second example, application A is selected, and receives -ill ( ?0 THE DESCRIPTION commands X, Y and Z from the terminal. Application A processes X itself, but delegates Y and Z to application B. Application A will have its session and stack data initialized when it receives X, but not when it receives the subsequent commands Y and Z. Application B will have its session and stack data initialized when it receives Y, but not Z.
One example of a use of session data is to support the use of a session Personal Identification Number (PIN). The application could reserve one byte of session data to support the PIN-receiving flag. On receiving the PIN check command, the selected delegated application could update the flag as follows: if the PIN command is received and the inputted PIN is equal to the stored pin, then it will set the session data DB[0] to 1. If not, the application will check if the PIN flag is already set by checking the value in DB[0]. In either of the above cases, the application will process the rest of the commands in the session because the PIN has been verified. If neither of the cases is true, then the application will not process the command because the PIN is not proper. The PIN checking function could be a delegated function from the selected application to a PIN checking application.
The Public segment 105 is used for command and response data being passed between an IFD and an application. During a delegate command, the Public segment contains the data passed between two applications, the delegator (the application initiating the delegation) and the delegated application (the application which performs the delegated function). An application may also use the Public segment as a further temporary working storage space if required. The
Figure imgf000058_0001
Public data is addressed using offsets stored in register PB 113 as a starting address, to register PT 115 as an ending address. Register PB 113 and Register PT 115 are fixed for the duration of a command-response pair being initiated by the IFD or delegator. Public data can include data inputted into or supplied by a terminal such as a transaction amount, vendor identification data, terminal information, transmission format or other data required or used by an application resident on the IC card. Public data can also include data which is to be transmitted to an IFD device or other application such as an electronic dollar value, card user information transmission format or other data required or used by the terminal or other delegated application.
The multiple application operating system ensures that the data stored in the Public segment remains private to the application until the application exits or delegates. Preferably, the data in the Public segment is then made available to other entities as follows: (1) if the application delegates, the whole of the Public segment becomes available to the delegated application; (2) if the application exits, and is itself delegated by another, the whole of the Public segment becomes available to the delegator; or (3) if the application exits, and is not itself delegated, then a portion of the Public segment containing the I/O response parameters and data are made available to the IFD. An application may write secret data into the Public memory segment during execution of the application, but the application must make sure it overwrites the secret portion of the Public segment before delegating or exiting. If the application abnormally ends (abends), then the operating system on the IC card A TO THE DESCRIPTION preferably overwrites all of the data in the Public segment automatically so that no unwanted entities can have access to the secret data. If the MULTOS carrier device (MCD) is reset, the operating system overwrites data in the Public segment automatically, so that no secret data is revealed. A portion of the Public memory segment is also used as a communications buffer. The I/O protocol data and parameters are preferably stored at the top of the Public memory space. In another prefeπed embodiment, the top seventeen bytes are reserved for the communications protocol between the IFD device and the IC card application. However, additional or less bytes can also be used depending upon the particular application and operating system being utilized.
The spaces shown between the memory segments in Figure 1 will vary depending upon the specific application and commands being processed. There could be no memory space between the memory segments so that the memory segments are contiguous. Figure 2 shows an extended illustration of the AAM implemented architecture. Data memory space 201 includes the three segments Static, Public and Dynamic as previously described. Code memory space 203 contains the program instructions for an application stored on the IC card. The application instructions are preferably stored in an executable form which can be inteφreted by the resident operating system but can also be stored in machine executable form. Instruction 205 is stored at one location in the code memory space 203. Additional instructions are stored in other locations of memory space 203. Two additional registers 207 and 209 are used in the AAM architecture. A code pointer (CP) register 207 M H ft TO THE DISCRIPTION indicates the particular code instruction to be next executed. In the figure, the register indicates, e.g., through an offset or pointer means, that instruction 205 is the next to be executed. Condition Control Register 209 contains eight bits, four of which are for use by the individual application and four of which are set or cleared depending upon the results of the execution of an instruction. These condition codes can be used by conditional instructions such as Branch, Call or Jump. The condition codes can include a carry bit, an overflow bit, a negative bit and a zero bit.
All address and control registers are set to defined values prior to executing the selected or delegated application. The values are set either when the application is first loaded onto the card and the size of the code and non- volatile data can be ascertained or at the moment when the application passes control to the application. When the application is loaded, SB is set to zero and ST is equal to the number of bytes in the application's Static database. The other address registers are initialized when the application is given control. CP 207 is set to zero and all eight bits in CCR 209 are cleared at the start of executing the application. A communications interface mechanism is present between the IFD and an application which includes the use of the Public data segment as a communications buffer for command-response parameters. A command-response parameter means an application is given a command to perform and returns a response to the entity issuing the command. Applications interact with an IFD by receiving commands, processing them and returning responses across the IFD- Application Interface. When an application has completed executing a command, .« A ϊflllOTPJK the application will place the response into the Public segment starting at PB[0] which can be read by the IFD device and will set the proper interface parameters in the reserved Public space relative to PT[0].
While an application can be called directly from an IFD and return a response directly to an IFD, it can also delegate a request to another application where appropriate. The subsequently-called application will then process the request on behalf of the first application. The delegation can be directly in response to a received command in which the delegator acts as a controller for delegating commands or subcommands to other appropriate applications. Alternatively, the delegated command can be embedded in an application's code which delegates control of the processor when the first application needs to interact with another application during its execution, such as updating frequent flyer miles or verifying a PIN.
Figure 3 shows a flow chart of the steps which are performed when a delegate request is executed. Step 301 sets the parameter named delegator_application_id (delegator ID) to be equal to the selected_file.application_id (selected ID). The selected ID indicates the current application which is selected and which is currently being executed. The delegator ID indicates the application which delegates a function to another delegated application stored on the IC card. Step 303 then pushes (stores) the delegator ID onto the top of the delegate_id_stack (delegate stack). The data referenced in the Dynamic portion of allocated memory is saved so that the current application can complete its execution after the delegated function is complete. Data which is to be 1 A TOTHE DESCRIPTION shared with the delegated application is referenced in the Public portion of allocated memory. The delegate stack is preferably stored outside of an application's AAM memory space and keeps track of which applications have delegated functions. Each application is suspended when it delegates a function so the delegate stack can act in a Last-In-First-Out (LIFO) manner so that if a number of applications are suspended due to delegation requests, the proper application is started in the right order. The delegate stack thus keeps track of which application was the last delegator when multiple layered delegation functions are performed. The delegate stack preferably operates in a LIFO manner although different stack schemes could be used as appropriate.
Step 305 then sets the selected ID to the delegate_request.delegate_ application_id (delegate ID) value. This step selects the application which will be called to perform the delegated function or functions. The identities of the delegated application can be specifically called by the delegator application or a particular function can be matched up with an application in a look up table. For example, a PIN match operation may be delegated to different applications depending upon which applications are present on the card. Step 307 then sets the application_command parameter to the value stored in the delegate_request.application_command parameter. This step specifies the command to be delegated to the delegate application. Applications typically have the ability to process many different commands. Alternatively, the entire application could be executed to perform one or more functions. The delegator application can choose which command it is delegating to another application. Step 309 then sends the NNEK A TO THE DESCRIPTION application_command to the AAM operating system for execution by the delegatee application. The delegator application is then suspended (or interrupted). Any data that is required to pass between the applications is transferred via the Public memory space. Figure 4 is a flow chart of the steps for performing a "return delegation control" command by the delegatee application. This command is executed by the operating system when a delegated application has completed its delegated function. Step 401 gets application_responses from the Public memory space of the delegated AAM. The response data is passed in the Public memory segment of the delegatee AAM. Step 403 then sets the delegate_response.status variable to a success condition. This means that a delegation operation has been successfully completed. Step 405 sets the delegate_ response.application esponses parameter to the application_responses values which were stored in the Public segment of the delegatee application. Step 407 sets the delegate_response.delegate_application_id parameter to selected_file.application_id (the delegatee application ID). Step 409 pops the top (i.e., reads the last data stored in the stack) delegate_application_id from the delegate_id_stack. This information indicates the identity of the delegator application for the command which was just delegated and completed by the delegated application. Step 411 sets the select_file.application_id value to the delegator_application_id value. This selects the delegator application which was identified from the delegate ID stack as the current application which will resume running. The Dynamic data for the delegator application will be retrieved for the EX ft TOIDE; delegator application from its stored location so that the application will continue to execute where it left off with all data intact but will also have the response information from the delegated function. In step 413, the delegate ^response data is sent to the current application for further processing. The response data is passed through the Public data space which could be the same physical RAM memory location because all applications share the physical volatile memory space.
Figure 5 shows a flow chart of the steps involved for inquiring about a delegator ID when a delegate command is received by a delegated application. The delegated application may need to know the identity of the delegator because it may perform operations differently for different delegator applications. For example, an airline loyalty program may need to know if awarded frequent flyers will be based on actual dollars processed or a lump sum award for some other activity such as performing a bill payment operation. This information could be passed to the delegated application as a variable or could be ascertained using an inquiry. The delegator inquiry operation could be implemented as a primitive as previously described.
Step 501 receives the delegator_id_enq_request from the AAM operating system. The request is used to identify the identity of the delegator. Step 503 checks if the delegate_id_stack is empty. If the stack is empty, then no delegation operations have occurred and no applications have been suspended. Thus step 511 sets the delegator_id_enq_response.status parameter to a failure indicator. Step 513 then sets the value of delegator_is_enq_request.error_cause to a value indicating "no delegator application." There is no delegator application. The 152
Figure imgf000065_0001
process then continues with step 509.
If the delegate_id_stack is not empty, than one or more delegations have occurred. In that case, step 505 sets the delegator_id_enq_response.status
parameter to a value indicating "success". Step 507 then sets the delegator d q_response.delegator_ application d parameter to the value stored in delegate_id_stack.delegator_ application^. This sets the inquiry response to indicate the delegator application ID at the top of the stack. As explained above, the stored data at the top of the stack indicates the last delegator application to call a delegate function. Step 509 then sends the delegator_id_enq_ response back to the AAM operator system which delivers the information to the application or IFD
entity requesting the information.
Figure 6 shows an example of a block diagram of an integrated
circuit located on an IC card chip which can be used in conjunction with the invention. The integrated circuit chip is located on a chip on the card. The IC chip preferably includes a central processing unit 601, a RAM 603, a EEPROM 605, a ROM 607, a timer 609, control logic 611, I/O ports 613 and security circuitry 615, which are connected together by a conventional data bus 617 or other conventional
means.
Control logic 611 in the smart card provides sufficient sequencing
and switching to handle read-write access to the card's memory through the input/output ports 612. CPU 601 in conjunction with control logic 611 can perform many different functions including performing calculations, accessing memory locations, modifying memory contents, and managing input/output ports. Some IC
Figure imgf000066_0001
cards also include a coprocessor for handling complex computations like cryptographic algorithms. Input/output ports 613 are used for communication between the card and an IFD which transfers information to and from the card. Timer 609 (which generates and/or provides a clock pulse) drives the control logic 611, CPU 601 and other components requiring a clock signal through the sequence of steps that accomplish functions including memory access, memory reading and/or writing, processing, and data communication. Security circuitry 615 (which is optional) preferably includes fusible links that connect the input/output lines to internal circuitry as required for testing during manufacture, but which are destroyed upon completion of testing to prevent later access. The Static memory space is preferably mapped to memory locations in EEPROM 605 which is nonvolatile. The Dynamic memory space is preferably mapped to RAM 603 which is volatile memory which has quick access. The Public memory space is also preferably mapped to RAM 603 which is volatile memory. The Dynamic data and Public data will be stored in different portions of RAM 603, while RAM is identified as a preferred non-volatile memory and EEPROM is identified as a preferred volatile memory. Other types of memory could also be used with the same characteristics.
Figures 7A, 7B and 7C illustrate an example of a delegation function being performed in order to process multiple applications on an IC card. Figure 7A shows a first application being executed as denoted with a double ringed circle 701.
At some point during the execution of the first application, a delegation function 702 is called to delegate an operation to the second application which is indicated I A Tfll' by circle 703. Also shown in Figure 7A is an empty delegator ID stack 705. Since the stack is empty, there is no data associated with it and it is shown only for illustrative puφoses.
The multiple application operating system receives the delegate command and interrupts the execution of the first application 701 and gives control of the integrated circuit to application 703 as shown in Figure 7B. The execution of the second application 703 is illustrated with a double ringed circle. The term "gives control" means that the microprocessor and other circuitry on the card will process the instructions and allocate memory space for the application which is delegated. When the delegate command is processed, the delegator ID 707 is placed on top of the stack 705. The delegator ID stack is operated in a LIFO manner. Also shown in Figure 7B is a third application 709 resident on the card. At some point during the execution of the second application, a delegate function 711 is called to delegate the operation to the third application. The multiple application operating system receives the delegate command 711 shown in Figure 7B interrupts the execution of the second application 703 and gives control of the integrated circuit to the third application 709 as shown in Figure 7C. When the delegate command is processed, the delegator ID 713 of the second application is pushed onto the delegator ID stack 705. The delegator ID 707 of the first application whose execution is still interrupted is pushed down in the stack consistent with a LIFO stack management. Thus when the third application has finished its execution, the delegator ID at the top of the stack is popped to indicate that execution of the second application
Figure imgf000068_0001
should be resumed first. The delegator ID 707 from the first application will then be at the top of the stack so that when the second application is finished executing, the first application will resume its execution.
Additional applications can be managed by the delegator ID stack in a similar manner. By interrupting the execution of the applications when a delegate command is processed and keeping track of the order of delegations, the security and integrity of the data for each individual application can be maintained which is important because IC cards will store data for applications which is private to the card user such as account numbers, social security number, address and other personal information.
The foregoing merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise numerous apparatus, systems and methods which, although not explicitly shown or described herein, embody the principles of the invention and are thus within the spirit and scope of the invention.
2152
ilEϋ A TO I DESCRIPTION
WE CLAIM:
1. An integrated circuit card comprising: a microprocessor; a volatile memory coupled to said
microprocessor; a non-volatile memory coupled to said microprocessor; and a plurality of applications stored in said non-volatile memory, wherein upon execution of each said application, said microprocessor allocates for each said executing application an associated data memory space comprising at least a volatile memory segment for referencing temporary data and a non-volatile memory segment for referencing static data; and further comprising means for delegating the performance of a function from a first executing application to a second executing application.
2. The integrated circuit card of claim 1 , wherein said non-volatile
memory segment is divided into at least two regions, including a public region and
a dynamic region.
3. The integrated circuit card of claim 2, wherein said public region is
used to share data between said first and second applications.
1 4. The integrated circuit card of claim 2, wherein said dynamic region
2 is used to reference temporary data utilized during an application's execution. HEX A TO I DESCRIPTION 5. The integrated circuit card of claim 1, further comprising at least one register coupled to said microprocessor which is used to determine the starting locations of each of said segments.
6. The integrated circuit card of claim 5, further comprising at least one register coupled to said microprocessor which is used to determine the top locations of each of said segments.
7. The integrated circuit card of claim 6, further comprising at least one register coupled to said microprocessor which is used as a local dynamic pointer.
8. The integrated circuit card system of claim 1, wherein each said application comprise a plurality of program instructions and wherein at least one of said program instructions when executed causes said memory referenced by said volatile memory segment to be accessed.
9. The integrated circuit card of claim 1 , wherein said volatile memory segment references RAM and said non-volatile memory segment references EEPROM.
10. A method for processing a plurality of applications stored in a memory of an integrated circuit: selecting a first application for execution; 2152
ANNEX A TO THE DESCRIPTION allocating a data space for said first application including at
least two memory segments comprising a volatile memory segment for referencing temporary data and a non-volatile memory segment for referencing static data; executing said first application, interrupting execution of said
first application and saving data referenced by said volatile memory segment; executing a second application; utilizing said saved data from said volatile memory segment
for execution of said first application; and completing said execution of said first application.
11. The method of claim 10, wherein said first application's identity is
stored in a data stack during said delegation step.
12. The method of claim 11, wherein said data stack is accessed
following said completion of said second application.
13. The method of claim 12, further including the step of inquiring said
first application's identity by accessing said delegator stack.
14. The method of claim 10, wherein said non-volatile memory segment is divided into at least two regions, including a public region and a dynamic region. 2152
ANNEX A !flTrø8!PTI0N 15. The method of claim 14, wherein said public region is used to share
data between said first application and said second application.
16. The method of claim 14, wherein data referenced by said dynamic
region is utilized during the execution of said first application.
17. The method of claim 10, further including the step of allocating a
second data space including at least two memory segments for said second
application.
18. The method of claim 17, wherein said second data space's segments comprise a volatile memory segment for referencing temporary data and a non-
volatile memory segment for referencing static data.
19. The method of claim 18, wherein said second application's non-
volatile segment is divided into at least two regions, including a public region and a
dynamic region.
20. The method of claim 19, wherein said second application's public
region is used to share data between said first and second applications. EX A TO THE DESCRIPT 21. The method of claim 19, wherein said data referenced by second application's dynamic region is utilized during said execution of said second application.
22. The method of claim 10, further including the step of delegating use of said microprocessor from said second application to a third application stored on said IC card.
23. The method of claim 22, wherein a third data space for said third application is allocated which includes a volatile memory segment for referencing temporary data and non-volatile memory segment for referencing static data, wherein said third application's volatile segment includes a public and dynamic portion.
24 An apparatus for processing a plurality of applications stored in a memory of a single integrated circuit card comprising: means for allocating a data space comprising at least a non- volatile memory segment for referencing static data and a volatile memory segment for referencing temporary data; means for executing a first application; means for interrupting execution of said first application, means for saving data from at least a portion of said volatile memory segment; and means for executing a second application; means for retrieving said saved data; and means for completing said execution of said first application. 8/52152
EX ft ID IS If
! 25. The apparatus of claim 24, further including means for storing said
2 first application's identity on a data stack.
of claim 25, further including means for inquiring of
1 26. The apparatus
2 said first application's identity
! 27. The apparatus of claim 24, wherein said first application's non-
2 volatile memory segment is divided into at least two regions, including a public
3 region and a dynamic region.
of claim 27, wherein said public region references
1 28. The apparatus
2 random access memory.
of claim 27, wherein said dynamic region references
1 29. The apparatus
2 random access memory.
1 30. The apparatus of claim 24, further including means for allocating a
2 second data space including at least two segments for said second application.
! 31. The apparatus of claim 30, wherein said second data space includes a
2 volatile memory segment for referencing temporary data and a non-volatile memory
3 segment for referencing static data. 2152
M A TO THE DESCRIPTION 32. The apparatus of claim 31 , wherein said second data space's non- volatile segment is divided into at least two regions, including a public region and a
dynamic region.
33. The apparatus of claim 32, wherein said public region references
random access memory.
34. The apparatus of claim 32, wherein said dynamic region references
random access memory.
35. The apparatus of claim 24, further including means for delegating operation of said IC card from said second application to a third application stored
on said IC card.
36. The apparatus of claim 35, wherein a third data space for said third application is allocated which includes a volatile memory segment for referencing temporary data and non-volatile memory segment for referencing temporary data, wherein said third application's volatile memory segment includes a public and
dynamic portion.
37. A system for processing a plurality of applications stored on an IC
card comprising: a non-volatile memory coupled to a databus; a volatile memory coupled to said d .a.mtabaus; A " roira ~ —iπxN a first and second application program stored in said non-volatile memory, wherein each application has an associated identifier; a data stack accessible by said databus for storing said applications' identifier if said application is interrupted during its execution; processor means for executing instructions from said application programs wherein said processor means allocates a data memory space for said application which is being executed and said data memory space is mapped to at least one address in said non- volatile memory and at least one address in said volatile memory; and wherein said processor means interrupts said first application at least once during its execution to execute said second application.
38. The system of claim 37, wherein data memory space comprises at least a volatile memory segment for referencing temporary data stored in said volatile memory and a non-volatile memory segment for referencing static data stored in said non- volatile memory.
39. The system of claim 37, further including means for storing said first application's identity on a data stack.
40. The system of claim 39, further including means for inquiring of said first application's identity.
Figure imgf000077_0001
41. The system of claim 38, wherein said first app icat on's non- vola le memory segment is divided into at least two regions, including a public region and a dynamic region.
42. The system of claim 41, wherein said public region references random access memory.
43. The system of claim 41, wherein said dynamic region references random access memory.
44. The system of claim 37, further including means for allocating a second data space including at least two segments for said second application.
45. The system of claim 44, wherein said second data space comprises at least a volatile memory segment for referencing temporary data and a non-volatile memory segment for referencing static data.
46. The system of claim 45, wherein said second data space's non- volatile segment is divided into at least two regions, including a public region and a dynamic region.
47. The system of claim 46, wherein said public region references random access memory. A 48. The system of claim 46, wherein said dynamic region references random access memory.
49. The system of claim 37, further including means for delegating use of said processor means from said second application to a third application stored on said IC card.
50. The system of claim 49, wherein a third data space for said third application is allocated which includes a volatile memory segment for referencing temporary data and non-volatile memory segment for referencing temporary data, wherein said third application's volatile memory segment includes a public and dynamic portion.
51. An integrated circuit card comprising: a plurality of applications and a microprocessor for controlling execution of said applications wherein execution of at least one first application is interrupted and execution is transferred to another second application, further comprising means for sharing data by said first and second applications and means for resuming execution of said first application at the appropriate location at least after completion of execution of said second application.
-76-
LE 26 2152
Figure imgf000079_0001
ft iDKKxvra 52. The integrated circuit card of claim 51 , further comprising means for
allocating a data memory space comprises at least a volatile memory segment for referencing temporary data stored in said volatile memory and a non-volatile memory segment for referencing static data stored in said non-volatile memory.
53. The integrated circuit card of claim 51, further including means for
storing said first application's identity on a data stack.
54. The integrated circuit card of claim 53 further including means for
inquiring of said first application's identity.
55. The integrated circuit card of claim 52, wherein said first application's non-volatile memory segment is divided into at least two regions,
including a public region and a dynamic region.
56. The integrated circuit card of claim 55, wherein said public region
references random access memory.
57. The integrated circuit card of claim 55, wherein said dynamic region
references random access memory.
Figure imgf000080_0001
58. The integrated circuit card of claim 52, further including means for allocating a second data space including at least two segments for said second application.
59. The integrated circuit card of claim 58, wherein said second data space comprises at least a volatile memory segment for referencing temporary data and a non-volatile memory segment for referencing static data.
60. The integrated circuit card of claim 58, wherein said second data space's non- volatile segment is divided into at least two regions, including a public region and a dynamic region.
61. The integrated circuit card of claim 58, wherein said public region references random access memory.
62. The integrated circuit card of claim 60, wherein said dynamic region references random access memory.
63. The integrated circuit card of claim 51, further including means for delegating use of said processor means from said second application to a third application stored on said IC card.
Figure imgf000081_0001
ABSTRACT OF THE
A multi-application IC card which processes two or more applications using an Application Abstract Machine architecture. The AAM architecture only allows one application to be executed at a time and allows for shared processing by performing a delegation function to a second application. A data space for each application is allocated when the application is selected to be executed. The data space includes a volatile and non-volatile region. The delegation function temporarily interrupts the execution of the first application, saves the temporary data of the first application, shares any data needed with the second application and the second application is executed until the delegated task is competed. The first application then retrieves the saved data and completes its execution. A delegator stack is used to keep track of the delegator's identity when multiple delegations occur. The AAM model allows for a high level of security while transferring data between applications.

Claims

I CLAIM:
L A method of responding to a command from an interface device by an integrated circuit card, said integrated circuit card comprising a
microprocessor and a memory coupled to said microprocessor, said method comprising the steps of: selecting an expected case for said command representing whether data is to be transferred between said interface device and said integrated circuit card; determining whether said expected case is applicable to said command; and processing said command if said expected case is applicable to said command.
2. The method of claim 1, wherein said command is transmitted from said interface device to said integrated circuit card under a transmission protocol requiring said integrated circuit card to have prior information related to the data, if any, to be transfeπed.
3. The method of claim 2, wherein said prior information is
related to the direction of the data to be transferred.
4. The method of any of claims 1 to 3, wherein said interface
device and said integrated circuit card support a plurality of transmission protocols.
5. The method of any of claims 1 to 4, wherein said integrated circuit card comprises an application stored in said memory, and wherein said
selecting step is performed by said application.
6. The method of any of claims 1 to 5, wherein said integrated circuit card comprises an application stored in said memory, and wherein said processing step is performed by said application.
7. The method of any of claims 1 to 6, wherein said integrated circuit card comprises an application stored in said memory, and further comprising the step of determining whether said command is recognized by said application before the selecting step.
8. The method of any of claims 1 to 7, wherein said integrated circuit card comprises an operating system stored in said memory, and wherein said determining step is performed by a function of said operating system.
9. The method of any of claims 1 to 8, wherein said integrated
circuit card comprises an operating system and an application stored in said memory, and further comprising the step of calling by said application a function of said operating system with said expected case before said determining step.
10. The method of claim 9, further comprising the step of receiving by said application a return value from said function of said operating system indicative of whether said expected case is applicable to said command.
11. The method of claim 9 or claim 10, wherein said memory comprises a publicly available memory space, and further comprising the step of communicating between said operating system and said application using said publicly available memory space.
12. The method of any of claims 9 to 11, wherein said integrated circuit card comprises a register, and further comprising the step of communicating between said operating system and said application using said register.
13. The method of any of claims 9 to 12, wherein said memory
comprises a stack, and further comprising the step of communicating between said operating system and said application using said stack.
14. The method of any of claims 9 to 13, further comprising the
step of determining by said function of said operating system whether data is to be received from said interface device.
15. The method of claim 14, further comprising the step of
receiving data from said interface device if said step of determining whether data is to be received from said interface device is positive.
16. The method of any of claims 9 to 15, further comprising the
step of responding by said operating system to subsequent commands by said interface device related to said command without interaction with said application
after the step of calling said function by said application.
17. The method of claim 10, further comprising the step of communicating response data by said application to said operating system if said return value is positive, said response data being data to be transmitted by said integrated circuit card to said interface device.
18. An integrated circuit card for use with an interface device, comprising: a microprocessor; a memory coupled to said microprocessor;
means for selecting an expected case for a command transmitted by said interface device, said expected case representing whether data is to be transferred between said interface device and said integrated circuit card; means for determining whether said expected case is applicable to said command; and means for processing said command if said expected case is
applicable to said command.
19. The integrated circuit card of claim 18, further comprising means for receiving said command from said interface device under a transmission
protocol requiring said integrated circuit card to have prior information related to the data, if any, to be transferred with or in response to said command.
20. The integrated circuit card of claim 19, wherein said prior
information is related to the direction of the data to be transferred.
21. The integrated circuit card of any of claims 18 to 20, wherein said integrated circuit card supports a plurality of transmission protocols.
22. The integrated circuit card of any of claims 18 to 21, further
comprising an application stored in said memory, said application comprising said means for selecting an expected case.
23. The integrated circuit card of any of claims 18 to 22, further comprising an application stored in said memory, said application comprising said means for processing said command.
24. The integrated circuit card of any of claims 18 to 23, further comprising an application stored in said memory, said application comprising means for determining whether said command is recognized by said application.
25. The integrated circuit card of any of claims 18 to 24, further comprising an operating system stored in said memory, said operating system comprising said means for determining whether said expected case is applicable to said command.
26. The integrated circuit card of any of claims 18 to 25, further comprising:
an operating system stored in said memory; an application stored in said memory; and
means for calling by said application a function of said operating system with said expected case.
27. The integrated circuit card of claim 26, further comprising means for receiving by said application a return value from said function of said operating system indicative of whether said expected case is applicable to said
command.
28. The integrated circuit card of claim 26 or claim 27, wherein said memory comprises a publicly available memory space, and further comprising means for communicating between said operating system and said application using said publicly available memory space.
29. The integrated circuit card of any of claims 26 to 28, further comprising a register and means for communicating between said operating system and said application using said register.
30. The integrated circuit card of any of claims 26 to 29, wherein said memory comprises a stack, and further comprising means for communicating between said operating system and said application using said stack.
31. The integrated circuit card of any of claims 26 to 30, further comprising means for determining by said function of said operating system whether data is to be received from said interface device.
32. The integrated circuit card of claim 31 , further comprising means for receiving data from said interface device responsive to said means for determining whether data is to be received from said interface device.
33. The integrated circuit card of any of claims 26 to 32, further comprising means for responding by said operating system to subsequent commands by said interface device related to said command without interaction with said application.
34. The integrated circuit card of claim 27 or any claim dependent thereon, further comprising means for communicating response data by said application to said operating system if said return value is positive, said response data being data to be transmitted by said integrated circuit card to said interface device.
PCT/GB1998/001401 1997-05-15 1998-05-14 Communication between interface device and ic card WO1998052152A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU77771/98A AU7777198A (en) 1997-05-15 1998-05-14 Communication between interface device and ic card

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US4651497P 1997-05-15 1997-05-15
US4654397P 1997-05-15 1997-05-15
US60/046,514 1997-05-15
US60/046,543 1998-04-23
US7805198A 1998-05-13 1998-05-13
US09/078,051 1998-05-13

Publications (2)

Publication Number Publication Date
WO1998052152A2 true WO1998052152A2 (en) 1998-11-19
WO1998052152A3 WO1998052152A3 (en) 1999-06-17

Family

ID=27366922

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1998/001401 WO1998052152A2 (en) 1997-05-15 1998-05-14 Communication between interface device and ic card

Country Status (2)

Country Link
AU (1) AU7777198A (en)
WO (1) WO1998052152A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1239411A1 (en) * 1999-11-30 2002-09-11 Kabushiki Kaisha Toshiba Ic card and method for managing volatile memory of the ic card
EP1384197A1 (en) * 2001-05-02 2004-01-28 Keycorp Limited Method of manufacturing smart cards
FR2892259A1 (en) * 2005-10-18 2007-04-20 Viaccess Sa Conditional access system for use in television multimedia service access field, has segmenting module segmenting entitlement management message into sequence, and concatenation module concatenating segments for reconstituting message

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9925227D0 (en) 1999-10-25 1999-12-22 Internet Limited Data storage retrieval and access system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5161231A (en) * 1986-09-27 1992-11-03 Kabushiki Kaisha Toshiba Processing system which transmits a predetermined error code upon detection of an incorrect transmission code
EP0559205A1 (en) * 1992-03-06 1993-09-08 Kabushiki Kaisha Toshiba Data processing system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5161231A (en) * 1986-09-27 1992-11-03 Kabushiki Kaisha Toshiba Processing system which transmits a predetermined error code upon detection of an incorrect transmission code
EP0559205A1 (en) * 1992-03-06 1993-09-08 Kabushiki Kaisha Toshiba Data processing system

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1239411A1 (en) * 1999-11-30 2002-09-11 Kabushiki Kaisha Toshiba Ic card and method for managing volatile memory of the ic card
EP1239411A4 (en) * 1999-11-30 2004-05-12 Toshiba Kk Ic card and method for managing volatile memory of the ic card
US6886069B2 (en) 1999-11-30 2005-04-26 Kabushiki Kaisha Toshiba IC card and management method of nonvolatile memory in IC card
EP1384197A1 (en) * 2001-05-02 2004-01-28 Keycorp Limited Method of manufacturing smart cards
EP1384197A4 (en) * 2001-05-02 2007-03-28 Keycorp Ltd Method of manufacturing smart cards
FR2892259A1 (en) * 2005-10-18 2007-04-20 Viaccess Sa Conditional access system for use in television multimedia service access field, has segmenting module segmenting entitlement management message into sequence, and concatenation module concatenating segments for reconstituting message

Also Published As

Publication number Publication date
WO1998052152A3 (en) 1999-06-17
AU7777198A (en) 1998-12-08

Similar Documents

Publication Publication Date Title
EP0985202B1 (en) Multi-application ic card with delegation feature
EP0981805A1 (en) Ic card with shell feature
US6742715B2 (en) System and method for flexibly loading an IC card
US7689826B2 (en) Flexibly loading a tamper resistant module
US5754762A (en) Secure multiple application IC card using interrupt instruction issued by operating system or application program to control operation flag that determines the operational mode of bi-modal CPU
JP3900536B2 (en) Smart IC card system
US5682027A (en) System and method for performing transactions and a portable intelligent device therefore
US6687800B1 (en) Chip card comprising means and method for managing a virtual memory and associated communication method
US6761319B2 (en) Configuration of IC card
US5687398A (en) Device having automatic process for upgrading the performance of mobile systems
EP1053535B1 (en) Configuration of ic card
JPH09510813A (en) Method and apparatus for handling long messages in a chip card
EP1053536B1 (en) System and method for controlling access to computer code in an ic card
US6082615A (en) Reader for smart IC card
TW451163B (en) Simplified use of smart cards
WO1998052152A2 (en) Communication between interface device and ic card
US6736325B1 (en) Codelets
EP1050028A1 (en) Codelets
US6866192B2 (en) IC card terminal
EP1384197B1 (en) Method of manufacturing smart cards
GB2350703A (en) Smart devices
JP7501808B2 (en) IC chip
JP3789994B2 (en) IC card
EP1188153A1 (en) System and process for conducting a financial transaction
JPH0219990A (en) Ic card

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SZ 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 ML MR NE SN TD TG

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

Kind code of ref document: A3

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

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SZ 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 ML MR NE SN TD TG

NENP Non-entry into the national phase in:

Ref country code: JP

Ref document number: 1998548942

Format of ref document f/p: F

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: CA