WO2000070567A1

WO2000070567A1 - System and process for conducting a financial transaction

Info

Publication number: WO2000070567A1
Application number: PCT/US2000/013831
Authority: WO
Inventors: John Roussochatzakis; Christopher N. Caruk
Original assignee: Mastercard International Incorporated
Priority date: 1999-05-19
Filing date: 2000-05-19
Publication date: 2000-11-23
Also published as: JP2002544633A; AU775497B2; HK1045393A1; ZA200109474B; AU5032100A; EP1188153A1; CA2373233A1

Abstract

A system and process capable of conducting a transaction which utilizes a terminal and a first transaction card (e.g., a credit card). The terminal (e.g., a payment or credit card terminal) can perform at least one transaction-related service. A second card (e.g., a control card such as a smart/chip card) is provided to communicate with the terminal. The terminal can be controlled using data (e.g., an executable application) stored on the second card to provide the transaction-related service for the transaction.

Description

SYSTEM AND PROCESS FOR CONDUCTING A FINANCIAL TRANSACTION

SPECIFICATION

This application claims priority of U.S. Patent Application No. 60/134,798, filed on May 19, 1999, the entire disclosure of which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

The present invention relates to a system and process for conducting a financial transaction with a terminal that is controlled by a separate card device. In particular, the system and process use information and/or instructions stored in a control card device, and called by the terminal, to control the facilities and/or services typically provided by the terminal.

With the advancement of the computer industry, the use of payment cards, such as debit cards, credit cards, and smart cards, has become the preferred method of transacting business. For example, by using such payment cards it has become easier for consumers to purchase goods and/or services without the necessity of using hard currency for such transactions. Facilitating the use of these payment cards are electronic payment or card accepting terminals, such as credit card reading terminals. Typically, the conventional payment terminal displays information on a preassigned display device (which is generally an attached display device), and prints the record of the transaction on a preassigned printer device (which also is most likely an attached printer device). This conventional payment terminal does not reroute the display or print-out requests to devices other than the preassigned devices because the destination to which these requests is transmitted is generally preset in the payment terminal, and it is difficult to modify the routing of such requests. As is well known, it is the payment terminal, acting as the central device, which drives a particular transaction and initiates the authorization process. In practice, the payment terminal dictates each command, retrieves the account information from the payment card, contacts the acquirer bank or a financial card company, and initiates the authorization request for an eventual authorization from a payment card issuing agency. The payment terminal also typically directs and controls the facilities and/or services (related to the transaction) provided at the preassigned locations/devices such as connected printers and screen displays.

Presently, the requirements for an acceptance of a payment card at a payment terminal are controlled by the card issuing agencies who issue the payment cards and/or by the financial card company or associations. Since the conventional payment terminals are "stand-alone terminals" (i.e., they are not linked to other payment terminals), each such terminal has substantially static requirements, functions and procedures for accepting information stored on the payment cards. This is a disadvantage, particularly in those cases where the terminal protocols need to be updated, changed or modified, or where the issuing agencies, acquirer banks and retailers want to add features to the payment terminal.

Significantly, the implementation of such additional functions is restricted by the ability of the payment terminals (and other equipment at the point of sale) to support these new facilities and the standards associated therewith.

Accordingly, there is a need to allow the acquirer bank or the payment card issuing agency or the financial card company to provide an increased level of control over and/or an increase ability to change the functionality of the payment terminals in a more flexible manner. By examining the limitations of the current point of sale (POS) payment accepting solutions and analyzing the likely future demands, it is preferable to provide a more flexible and controllable interaction between the payment card (e.g., a magnetic card or a chip card), the payment terminal (e.g., a card reading/payment authorization requesting device), external devices (e.g., printing devices, display devices or other attached systems), and payment supporting entities (e.g., the payment card issuing agency, the acquirer bank and/or the financial company). Indeed, there is a need to allow the payment supporting entities to control the payment terminals, and possibly the external payment devices, by having the ability to add, remove and/or modify the functionality of and services provided by these devices automatically, thereby limiting the need to manually modify the devices. There is also a need to control the functionality of the payment terminal via an externally-provided application.

SUMMARY OF THE INVENTION

A system and process for conducting a financial transaction with a terminal that is controlled by a separate card device is provided to address at least some the above-discussed needs. As shall be discussed in further detail below, this system and process use information and/or instructions stored in the control card device and called by the terminal to control the facilities and/or services typically provided by the terminal. In particular, the system and process according to the present invention are capable of conducting a transaction which involves a terminal and a first transaction card (e.g., a credit card). The terminal (e.g., a payment or credit card terminal) can perform at least one transaction-related service, such as printing out a receipt, either at the terminal or at the remote location, or displaying the data concerning the transaction also at the terminal or at the remote location from the terminal. A second card (e.g., a control card such as a smart/chip card) is made available for communicating with the terminal. The terminal is then controlled by data (e.g., an executable application) stored on the second card to provide at least one of the transaction-related services.

In one preferred embodiment of the present invention, the data stored on the second card (and specifically the executable application for providing the transaction-related service) comprises or is a part of at least one rules file which is created by a control card issuing entity that can be a financial card company, an acquirer bank or a payment card issuing agency.

According to another embodiment of the present intention, it is possible to interface the rules file with a terminal interface layer (TIL) application stored on the second card. This interface application may be executed for interfacing with the rules file to control the transaction-related service of the terminal. Using the rule files and/or the interface application stored on a storage arrangement of the second card, it is possible to control (e.g., add, remove and/or modify) the facilities or transaction-related services of a terminal, thereby enabling the control card issuing entity to control the terminal without any manual modification thereof by such entity. In another exemplary embodiment of the present invention, the facilities required by the second card and the facilities or transaction-related services which are available at the terminal are compared. If none of the facilities or transaction-related services required by the second card are available at the terminal, the terminal may be disabled.

According to yet another exemplary embodiment of the present invention, the second card may include a processor which accesses at least one rules file on its storage arrangement during the transaction using the terminal interface layer (TIL) application which is also stored on the storage arrangement. The processor then directs the terminal to perform the transaction-related service as required by the rules file.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings in which: Figure 1 shows a diagram of an exemplary embodiment of a system for conducting a financial transaction according to the present invention.

Figure 2 shows an exemplary flow diagram of an embodiment of a process for conducting the financial transaction according to the present invention.

Figure 3 shows an exemplary illustration of the cooperation of exemplary message classes using a terminal interface layer according to the present invention.

Figure 4 shows an exemplary T=l protocol.

Figure 5 shows another exemplary T=l protocol utilized by the terminal interface layer according to the present invention. Figure 6 shows an exemplary embodiment of a control card according to the present invention which can be used with the system shown in Figure 1.

Figure 7 shows an exemplary embodiment of an initialization process of a terminal according to the present invention.

DETAILED DESCRIPTION

Exemplary embodiments will now be explained in the context of a communication of a merchant control card with a payment terminal. It will be understood, however, that it is possible for the control card described herein below to communicate with other transaction terminals, such as automated teller machines (ATMs) or other card accepting devices. It should also be understood that instead of utilizing the control card to communicate with the terminals, it is also possible to control these terminals from a remote location using a control arrangement described below via a global communication network (e.g., the Internet) or via a wireless communications network. An exemplary embodiment of a financial transaction system according to the present invention is illustrated in Figure 1. A control card issuing entity (which may include or be a part of a control arrangement 100) generates and issues a control card 140 (e.g., a merchant card) to a merchant for accessing and controlling the operation of the terminal 110 (e.g., the payment terminal). The control card issuing entity issues the control card 140 to implement its business rules compliance (via rules files stored on the card) at the particular terminal 110, and to control the operation of the terminal 110. This control card issuing entity can store at least one rules file on the control card 140. The control card 140 may be a chip card (or a smart card) which includes a storage arrangement such as a random access memory (RAM) or a read only memory (ROM). The rules file may include one or more executable applications which can utilize a terminal interface layer (TIL) application to communicate with the terminal 110. The control card issuing agency may be a financial card company such as MasterCard International Incorporated, the acquirer bank and/or the payment card issuing agency. Figure 2 shows an exemplary flow diagram of the process according to the present invention. During an initialization portion of the terminal 110, i.e., either when the terminal 110 is activated or powered on, or when the control card 140 is inserted into or swiped at the terminal 110 in step 200, an application which may be a TIL-compliant executable program, and which is resident and running on the terminal 110 calls an TIL-compliant application (e.g., a TIL component) residing on the storage arrangement of the control card 140 (step 210). The TIL-compliant application residing on the control card 140 accesses at least one rules file also residing on the storage arrangement of the control card 140 (step 220). Using such rules file, the TIL-compliant application running on the terminal 110 or the TIL- compliant application residing on the control card 140 customizes the operation, functions, facilities and transaction-related services of the terminal 110 (step 230). It is also conceivable that the terminal 110 may access and utilize the rules file provided on the control card 140 via a network arrangement, e.g., via the Internet. Indeed, it is possible that the control card 140 may be inserted at a further terminal 150 which is provided at a remote location from the terminal 110. The further terminal 150 may be a device (e.g., a card reader) which enables an access to the control card 140 when it is inserted therein. Thus, the data and/or application stored on the control card 140 can be made available to the terminal 110 remotely. Thereafter, to complete a transaction, the information provided on the payment card 130 is transmitted to the terminal 110 coupled to or part of the point-of- sale device 120 (step 240). Then, the terminal 110 may access one or more rules files in the storage arrangement of the control card 140 to check the facilities or transaction-related services authorized by the control card 140. As an alternative, the terminal 110 may check its memory to determine which facilities or transaction- related services were authorized by the rules file of the control card 140 (step 250). Then, in step 260, the terminal 1 10 transmits the information to the control arrangement 100 based on the authorized facilities or transaction-related services. It is also possible for the terminal 110 to transmit the payment request to another location or device based on the authorized/customized facilities or transaction-related services of the terminal 110 (as defined by the rules file that are resident on the storage arrangement of the control card 140).

Thereafter, the terminal 110 may receive a reply to an authorization request from the control arrangement (step 270). This authorization may be provided by the payment card issuing agency in response to the request for the authorization forwarded by the acquirer bank and/or the financial card company. This information regarding the reply may be displayed by the terminal 110 at a display portion of the terminal 110, printed at a printer portion of the terminal 110, displayed at a display device 170 which is provided remotely from the terminal 110 and/or printed at a printing device 160 which is also remote from the terminal 110. In accordance with this embodiment of the invention, these actions may be performed by the terminal 110 based on the configuration thereof by one or more rules files that are resident on the storage device of the control card 140.

In another embodiment of the present invention, before the terminal 110 performs a particular action (e.g., forwarding the information received from the payment card 130 to the control arrangement 100, printing a copy of the receipt, displaying the information received from the control device 100, etc.), the terminal 110 may access the control card 140 and/or transfer the control of operation to such control card 140. Indeed, the application running on the terminal 110 may call the TIL-compliant component which is executable on the control card 140, which in turn executes a TIL-compliant facilities configuration application provided in at least one rules file. The configuration application then transmits a command to the terminal 110 via TIL to perform particular transaction-related services based on the services required by the TIL-compliant application stored in the rules file of the control card 140. In this manner, the control card 130 and/or the information residing thereon would be used to control the facilities, functions and/or transaction-related services of the terminal 110 through the protocols defined by TIL (which shall be described in further detail below).

It should be understood that it is possible to utilize more than one terminal for the functions, facilities and/or transaction-related services provided by the terminal 110 as described above. That is, multiple pieces of hardware and/or software may be implemented to perform and use these functions, facilities and/or transaction- related services. For example, the terminal 110 may include a personal computer having a monitor, a printer and a card reader attached thereto. It is also possible for the terminal 110 to consist of a plurality of computers coupled together, e.g., via a network, and/or printing devices provided at the same or different remote location and connected to the computers via the same or different network. Accordingly, all of the facilities and/or transaction-related services provided by the terminal 110 do not have to be resident on the same piece of equipment. Indeed, as discussed previously, the terminal 110 may send a request for a printout of a record of the particular transaction to the printing device 160 provided by a print server connected to, e.g., the network in one country, and transmit a command for displaying the record to a display device 170 which is, e.g., connected to another network in a different country. In addition, any software used to implement the facilities provided by the terminal 110 may distributed across one or more networks.

The control card issuing entity generally controls the issuance of the control cards 140, and this control card 140 is then used to control the implementation of the control card issuing entity's business rules (via at least one rules file stored in the storage arrangement of the control card 140) on the terminal 110 of the merchant. In an exemplary application of the payment arrangement according to the present invention, the control card issuing entity (e.g., MasterCard International Incorporated) may want to brand each credit card transaction with a particular phrase or a logo, e.g., for marketing purposes. As such, the control card issuing entity would prefer to control a printing process during the transaction that is performed on the terminal 110. Thus, when the consumer inserts his or her payment card 130 into a card reader of the terminal 110, the application being executed on the terminal 1 10 may determine that at least one of the rules files residing on the storage arrangement of the control card 140 applies to the current transaction and/or to the particular consumer's payment card 130 that was inserted into the card reader. Then, the control of the transaction may be transferred to the control card 140 which would implement the business rules (corresponding to at least one rules file stored thereon) to control the facilities, functions and/or transaction-related services available on the terminal 110. Thus, the control card 140 may direct the terminal 110 to print the particular phrase or logo on a credit receipt for the transaction which was initiated by the particular consumer via his or her payment card 130.

An exemplary embodiment of the terminal interface layer (TIL) 290 utilized by the control card 140 for communicating with the terminal 110 is discussed below with reference to Figure 3. Using TIL 290, the transaction terminal environment system and process according to the present invention may provide a controlled interaction and exchange of messages between all participants of this system. In particular, TIL 290 operates using a set of inter-related message class handlers. The class may be provided for each primary function of the TIL environment. Indeed, these message classes provide the facilities, functionality and/or transaction-related services for the terminal 110. All classes may be inter-related and inter-connected using TIL 290. The exemplary classes are provided follows:

MESSAGE CLASS DESCRIPTION

Display Sends defined messages and commands to the display devices.

EMV Performs the requirements of an EMV (Europay

International S.A., MasterCard International

Incorporated, and Visa International Service

Association) transaction (in accordance with the EMV

'96 Integrated Circuit Card, Terminal and Application

Specifications, June 30, 1996 Version 3.0, incorporated herein by reference and referred to herein as the "EMV

Specs").

Encryption Provides encryption and decryption facilities. File Provides file access and storage facilities.

Keyboard Obtains an input from the keyboard device(s). Magnetic Card Obtains input from the card reader(s). Printer Sends defined output and commands to printing device(s). Smart Card Provides read and write facilities to/from smart card devices. Sound Provides an audible feedback.

System Provides control for Classes and TIL environment. User Provides a functional extensibility.

Wallet Provides a high level transaction support.

It should be appreciated that other message classes corresponding to past, present or future facilities and/or transaction-related services provided by the terminal 110 may be utilized by TIL 290. In addition, in accordance with the present invention, it is possible to configure the transaction terminal environment system to utilize more or less of the message classes supported by TIL 290.

In operation, all messages passed to or from one class to another are preferably transmitted under the control of TIL 290, which can perform multitask/multi-application operations. According to one embodiment of the present invention, TIL 290 can be configured to determine whether certain facilities are available, and then control the corresponding events for the respective classes accordingly. For example, if a particular device (e.g., the terminal 110) requests a particular block of data to be decrypted, TIL 290 transmits this information to the "Encryption" class. After the decryption is completed (using the information of the "Encryption" class), a message is transmitted via TIL 290 to the requesting device indicating that the decryption has been completed.

Using TIL 290 according to the present invention, it is possible to implement the same system and process for numerous card accepting terminals which have different facilities and/or transaction-related services available to them. Indeed, TIL 290 would be able to determine whether the facility and/or transaction-related services is available for the particular terminal and/or how the control card issuing entity would prefer to control the available facilities of such terminals (e.g., using the control cards). In this manner, it is possible to easily implement TIL 290 across a large number of card accepting terminals without the necessity of manually customizing the facilities and/or transaction-related services of each terminal. It is also possible to add new message classes or additional events (or functions) to the existing classes, and thus TIL 290 can be expanded to address any enhanced requirements and further modifications of the existing applications. Because the basic structure of TIL 290 and the class relationship remains substantially the same, the existing applications would generally not be affected by such modifications.

In order for TIL 290 to provide an effective communication, it is preferable to use a predetermined protocol scheme. This predetermined scheme would allow TIL 290 to provide data transmitted by a sender (e.g., from a terminal at a source address) to a receiver (e.g., a printing device at a remote destination address). For instance, using the transmission protocols disclosed in the EMV Specs, which define two types of protocols, character protocol (T=O) and block protocol (T=l), Figure 4 shows a T=l protocol for a message 410 transmitted via TIL 290. As previously utilized, the message illustrated in Figure 4 contains source and destination addresses which are provided in the Node Address field (NAD). In particular, the fields of the message conforming to this protocol are as follows:

FIELD DESCRIPTION

NAD Node addressing.

PCB Protocol control block.

LEN Length of INF BLK.

INF BLK Information block.

LCR Block checksum.

CLASS Instruction class (see message classes described above).

ΓNSTR Instruction.

PARMl Parameter 1.

PARM2 Parameter 2.

DATA Data (optional).

The system and process according to the present invention preferably utilizes a modified T=l protocol for interchanging messages via the TIL 290. As shown in Figure 5, rather than identifying the source and destination addresses in the NAD field, TIL identifies the NAD field and sets NAD=00. Thus, when TIL 290 encounters records having an NAD field it sets the field to zero and, based on the data stored in the other fields and the rules files, forwards the message to the appropriate service responsible for processing the respective message class and/or instruction request.

One of the benefits of utilizing TIL 290 according to the present invention is that the sender which requests a particular message class and/or instruction does not know, and does not need to know, about the facility which may be used to fulfil this request. The data can be transmitted via a serial or parallel port, or via any other installed protocol transport to carry the data to its destination. TIL 290 is the only portion of the system which is aware of how the data transport is achieved.

Other benefits of utilizing this protocol along with TIL 290 are as follows. Once the message class and/or instruction handler is developed, it does not need to be changed. The terminals which are intended to have only a low level of functionality (or a small number of facilities) are capable of handling a subset of all the facilities supported by TIL 290. In addition, the computationally intensive work can be directed towards more powerful nodes in a terminal network.

As discussed above, the control card 140 is preferably used to provide and make available or utilize at least one rules file stored on its storage arrangement to the terminal 110. Figure 6 shows an exemplary embodiment of the control card 140 according to the present invention (which is operable with TIL), along with the storage arrangement 500 which stores the rules files 450 and implements an executable TIL component 300 thereon. Preferably, the control card 140 is issued by the control card issuing entity (e.g., the financial card company such as MasterCard International Incorporated, the acquirer bank and/or the payment card issuing agency) to the merchant for use with the terminal 140. The control card 140 has an executable application (i.e., the TIL component 300) stored in its storage arrangement 500. This executable application is TIL compliant and supports the use of the TIL functions. The rules files 450 are stored by the control card issuing entity on the control card 140, preferably using TIL commands. These rules files determine the customization and the transaction operation of the terminal 110 for requiring the terminal 110 to perform the transaction-related services such as performing security checks of the transactions, setting particular transaction verification methods on the terminal 110, transmitting a printed copy of the transaction to the printing device which is situated at a remote location from the terminal 110, etc.

A detailed description of the exemplary interaction between the control card 140 and the terminal is provided below. In particular, during the initialization process(e.g., at power-on or when the control card 140 is inserted into the card reader associated with the terminal 110), the rules files 450 and the terminal 110 dynamically interact with one another to customize the terminal 110 by comparing features and functions (i.e., the facilities and/or transaction-related services) available on the terminal 110 via TIL with the facilities required by the rules files 450. If the terminal 110 supports the facilities and/or transaction-related services requested by the rules files 450, the terminal 110 is configured to support only those features and/or transaction-related services authorized by the control card 140 (in a manner required by the control card 140) via its resident rules files 450.

According to another exemplary embodiment of the present invention, one or more of the rules files 450 resident on the control card 140 can be a separate executable application. Such executable applications can be invoked by the TIL component 300 of the control card 140 to customize the terminal 110, while the TIL component 300 may be invoked by the application running on the terminal 1 10. Once the TIL component 300 of the control card 140 is initiated, the rules files 450 communicate with the TIL component 300 preferably by sending unwrapped (e.g., non-compressed) TIL packets to the TIL component 300. The TIL component 300 then wraps (e.g., compresses) these packets to be provided to the terminal 1 10. On the other hand, when the terminal 110 contacts the TIL component 300 of the control card 140, it transmits wrapped packets to the TIL component 300. Then, the TIL component 300 unwraps the wrapped packets received from the terminal 110, and transmits the unwrapped packets to the rules files 450. Thus, most if not all of the technical details (e.g., repetitive calls) of the TIL communications process are handled by the TIL component 300 so that the executable applications provided in the rules files 450 are only required to perform the most important (and generally non- repetitive) operations for customizing the facilities and/or transaction-related services of the terminal 110. Accordingly, the duplication of many programming functions performed by the TIL component 300 is avoided by the rules files 450 and executed on the control card 140; its storage arrangement, therefore, is efficiently utilized by the control card 140.

An exemplary embodiment of the initialization process of the terminal 110 with control card 140 and the additional functionality of the transaction system according to the present invention are described below with reference to Figure 7. As described above, the terminal 110 recognizes that the control card 140 has been inserted into an appropriate slot of a card reading device associated with the terminal 110. This is done either when the control card 140 is inserted into the terminal 110 during its idle state or, if the control card 140 is already inserted into the card reading device, when the terminal 110 performs its power-up sequence (step 600).

Then, the terminal 110 (via its TIL-compatible executable application) determines if at least one rules file 450 is present on the storage arrangement of the control card 140 (step 610). If no rules files are present, the terminal 110 can either be disabled or can be configured to use the preassigned facilities or transaction-related services provided for that terminal 110 (step 620). The initialization process with the control card 140 is then aborted. Otherwise, the initialization process according to the present invention determines if there are more than one rules files resident on the storage arrangement of the control card 140 (step 630).

If there is only one rules file 450 resident on the control card 140, the terminal 110 requests the details from the control card 140 regarding which TIL message classes and functions, e.g., the facilities or transaction-related services of the terminal 110, are required for operating the particular terminal 110 (step 640). When this information is delivered to the terminal 110, the TIL-compatible executable application executing on the terminal 110 compares the requested facilities received from the control card 140 to the available TIL classes and functions (i.e., the available facilities and/or transaction-related services) that are available for the particular terminal 140 (step 650). Alternatively, the control card 140 may receive information regarding the terminal's available facilities and make the comparison itself using the TIL component 300.

If the facilities requested by the control card 140, and specifically the rules file 450 are available, then the TIL application running on the terminal 110 (or the TIL component 300) configures the terminal 110 to forward the commands for the enablement of the particular facilities and/or transaction-related services of the terminal 110 to the TIL component 300 of the control card (step 660). The system is then enabled for performing the transactions, and the initialization process is terminated.

If the requested facilities are not available at the terminal 1 10, then the application provided by the rules file 450 is terminated, and the terminal 110 is disabled (step 620). Instead of disabling the terminal 110, it is also possible to configure the terminal 110 to use the preassigned facilities provided for that terminal 110.

If there are more than one rules file 450 provided in the storage arrangement of the control card 140, the terminal 110 makes a requests from each rules file 450 to obtain the details of the TIL facilities or transaction-related services which are required or preferable for the terminal 110 to operate the particular application for such terminal 110 (step 670). In step 680, all rules files 450 which require particular facilities or services that are supported by the terminal 110 are marked as "active". Then, the exemplary initialization process according to the present invention is completed.

Thereafter, after the payment card 130 is inserted into the card reading device associated with the control card 140 (i.e., at the time of the transaction), the TIL application running on the terminal 110 preferably determines, based on data associated with the payment card 130 and the transaction, which of the capabilities of the active rules files 450 could or should be performed. If the facilities or transaction- related services necessary for the particular transaction are provided in more than one rules file 450, it is also possible to activate the facilities or transaction-related services associated with the payment card by sequentially executing the respective active rules files.

According to another embodiment of the present invention, the terminal 110 can also utilize the TIL layer scheme described above to communicate with other devices, such as EPOS 120 or a PC-based transaction system, for supporting card handling functions and any functions which may relate to the enablement of the facilities or transaction-related services requested by the control card 140. To allow such devices to communicate with the functionality offered by the terminal 110 using TIL 290, another embodiment of the present invention provides that the device accepts TIL-compliant messages and configures its functionality and/or facilities in the same manner as configured for the terminal 1 10. For example, the terminal 110 may transmit the TIL-compliant message (which may originate from the control card 140) via its communication interface to EPOS 120 to allow EPOS 120 to perform transactions of monetary amounts that are less than a preselected amount. In another embodiment of the present invention, the terminal 110 has both the TIL-compliant application and an application which is not TIL-compliant (and that does not utilize the rules files 450). For example, it is possible to have an application which tracks the number of uses of a particular payment card 130 used at the terminal 110 (e.g., the application which may not be TIL-compliant). At the same time, it is possible to execute the TIL-compliant application which forwards the requests for information relating to particular facilities or transaction-related services to the control card 140. Thus, both TIL- and non TIL-compliant applications may coexist and run on the same terminal 110.

It should be appreciated that those skilled in the art will be able to devise numerous systems and processes which, although not explicitly shown or described herein, embody the principles of the invention, and are thus within the spirit and scope of the present invention.

Claims

1. A process for conducting a transaction which involves a terminal and a first transaction card, the terminal being capable of providing at least one transaction- related service, the process comprising the steps of: providing a second card to be in communication with the terminal; and controlling the terminal with the second card to provide the at least one transaction-related service.

2. The process according to claim 1, wherein each of the first and second cards includes a chip thereon, wherein the controlling step is performed during the transaction, and wherein the providing step comprises: inserting the second card into the terminal.

3. The process according to claim 1, wherein the second card includes a storage arrangement which stores at least one rules file, and further comprising the step of: executing an application on the terminal to access the at least one rules file, wherein the at least one transaction-related service is controlled as a function of the at least one rules file.

4. The process according to claim 1 , wherein the second card includes a storage arrangement which stores at least one rules file and a first application thereon.

5. The process according to claim 4, further comprising the steps of: prior to the controlling step, transmitting a request from a second application running on the terminal to the second card; and executing the first application on the second card in response to the transmitted request, the first application accessing the at least one rules file for controlling the at least one transaction-related service during the transaction.

6. The process according to claim 4, wherein the controlling step comprises: executing the first application to access the at least one rule file; and customizing the transaction-related service of the terminal using the at least one rules file.

7. The process according to claim 6, wherein the at least one rules file includes a program, and further comprising the step of: executing the program on the second card when the first application accesses the at least one rules file.

8. The process according to claim 4, wherein the at least one rules file provides data corresponding to at least one predetermined service to be performed by the terminal, and wherein the controlling step comprises: comparing the at least one predetermined service to the at least one transaction-related service to determine if the terminal is capable of performing the at least one predetermined service.

9. The process according to claim 8, wherein the controlling step further comprises: if the terminal is not capable of performing the at least one predetermined service, preventing the terminal from providing any transaction-related service.

10. The process according to claim 8, wherein the controlling step further comprises: if the terminal is not capable of performing the at least one predetermined service, assigning at least one predefined facility to be the at least one transaction-related service to be performed by the terminal.

11. The process according to claim 1 , wherein the second card includes a storage arrangement which stores at least one rules file thereon, and wherein the controlling step comprises: during the transaction, accessing the at least one rules file; and directing the terminal to perform the at least one transaction-related service using the at least one rules file.

12. The process according to claim 1 , wherein the second card includes a storage arrangement which stores at least one rules file thereon, and wherein the controlling step comprises: during the transaction, accessing the at least one rules file using a terminal interface layer (TIL) compliant program which is executed on the second card; and receiving instructions, by the TIL compliant program, from the at least one rules file to perform the at least one transaction-related service.

13. The process according to claim 1, wherein the controlling step comprises: directing a particular service of at least one transaction-related service to be performed based on the transaction.

14. A system for conducting a transaction with a first card, comprising: a terminal capable of providing at least one transaction-related service; and a second card being in communication with the terminal, the second card controlling the terminal to provide the at least one transaction-related service.

15. The system according to claim 14, wherein the second card includes a chip and controls the terminal during the transaction, and wherein the second card is inserted into the terminal to control the terminal.

16. The system according to claim 14, wherein the second card includes a processor and a storage arrangement which stores an application thereon, the processor executing the application to control the at least one transaction-related service of the terminal.

17. The system according to claim 16, wherein application accesses the at least one rules file and controls the at least one transaction-related service as a function of the at least one rules file.

18. The system according to claim 14, wherein the second card includes a storage arrangement storing an application and at least one rules file thereon.

19. The system according to claim 18, wherein the terminal includes a further storage device which stores a further application, the further application being executed on the terminal and transmitting a request to the second card, wherein the second card includes a processor, and wherein, in response to the transmitted request, the processor executes the application stored on the storage arrangement of the second card for accessing the at least one rules file, the second card controlling the at least one transaction-related service as a function of the at least one rules file during the transaction.

20. The system according to claim 19, wherein the second card includes a processor, the processor executing the application stored on the storage arrangement of the second card to access the at least one rule file and customizing the transaction- related service of the terminal using the at least one rules file.

21. The system according to claim 20, wherein the at least one rules file includes a program, and wherein the second card includes a processor which executes the program when the first application accesses the at least one rules file to control the at least one transaction-related service.

22. The system according to claim 18, wherein the at least one rules file provides data corresponding to at least one predetermined service to be performed by the terminal, and wherein the second card includes a processor which compares the at least one predetermined service to the at least one transaction-related service for determining if the terminal is capable of performing the at least one predetermined service.

23. The system according to claim 22, wherein the processor determines if the terminal is not capable of performing the at least one predetermined service to prevent the terminal from providing any transaction-related service.

24. The system according to claim 22, wherein the processor determines if the terminal is not capable of performing the at least one predetermined service to assign at least one predefined facility to be the at least one transaction-related service performed by the terminal.

25. The system according to claim 14, wherein the second card includes a storage arrangement storing at least one rules file thereon, and wherein the second card includes a processor which accesses the at least one rules file during the transaction and directs the terminal to perform the at least one transaction-related service using the at least one rules file.

26. The system according to claim 14, wherein the second card includes a storage arrangement storing at least one rules file thereon, and wherein the second card includes a processor which executes a terminal interface layer (TIL) compliant program to access the at least one rules file during the transaction, and wherein the

TIL compliant program receives instructions from the at least one rules file to perform the at least one transaction-related service.

27. The system according to claim 14, wherein the second card includes a processor which directs a particular service of at least one transaction-related service to be performed by the terminal based on the transaction.