WO2004095352A1

WO2004095352A1 - Modular smart card upgrade for existing magnetic stripe card terminals

Info

Publication number: WO2004095352A1
Application number: PCT/US2004/012503
Authority: WO
Inventors: Chris S. Nelson; Simon J. Hurry; Forough Kashef
Original assignee: Visa International Service Association
Priority date: 2003-04-22
Filing date: 2004-04-22
Publication date: 2004-11-04

Abstract

Upgrading an existing magnetic stripe only card terminal to accept and process smart cards. Terminal hardware includes a magnetic stripe card reader, a smart card reader, and a computer having an operating system designed for magnetic stripe card transactions but not smart card transactions. To this terminal is added a smart card module able to receive a payment communication from a device application module and to process a smart card transaction. The smart card module operates independently from other terminal devices and programs; various application programming interfaces are installed to facilitate this versatility. The smart card module implements EMV functionality, is pre-approved by an industry body such as EMVCo, and may include source files written in Java or C++ computer code, with embedded device platforms of STIP, GlobalPlatform, EFT and/or POS being used.

Description

MODULAR SMART CARD UPGRADE FOR EXISTING MAGNETIC STRIPE CARD TERMINALS

TECHNICAL FIELD [0001] The present invention relates generally to electronic financial transactions, and more specifically to terminals and systems for conducting financial transactions involving credit cards, debit cards, magnetic stripe cards, smart cards and the like.

BACKGROUND [0002] Many banks, financial institutions and other businesses often issue cards to consumers for use in conducting financial and other business transactions, with the use of such cards often facilitating the tracking and recording of purchases and other transactions. Such cards can include, for example, identification cards, membership cards, debit cards, credit cards, check cards, and cards for "loyalty" programs that reward customers for frequent purchases or other uses, such as frequent flyer mileage programs, frequent guest programs at hotels and the like. Such systems and programs may make use of a relatively simple plastic card with an embossed customer number to help keep track of transactions for a given user. Some utilize a standard magnetic stripe card that can magnetically store information such as customer name and code or identification number, number of purchases, points awarded, and other pertinent items. Still other systems and programs have been implemented using "smart" cards that can similarly store information such as customer name and identification number, number of purchases, points awarded, and other pertinent items. Major developers and administrators for such cards and card systems include the likes of, for example, Visa, MasterCard, Europay, American Express, Discover, Diners Club and others. [0003] In essence, a smart or integrated circuit card ("ICC") is a plastic card having an embedded microchip adapted for data storage and/or micro processing, as well as one or more contacts and/or antennae for communication with smart card accepting devices. Also termed chip cards, memory cards or processor cards, an ICC or smart card is typically a credit card-sized plastic card that includes one or more semiconductor integrated circuits. A smart card can interface with a point-of-sale • ("POS") terminal, an automated teller machine ("ATM"), or with a card reader integrated with a computer, telephone, vending machine, or a variety of other devices. A smart card may also be programmed with various types of data and functionalities, such as cardholder information, a stored-value, credit or debit application, a loyalty application, and the like. Although a plastic card is currently the medium of choice for smart cards, it is contemplated that a smart card may also be implemented in a smaller form factor, such as, for example, an attachment to a key chain or a small chip module. A smart card may also be implemented as part of a personal digital assistant ("PDA"), telephone (such as a subscriber identification module), or take a different form. These and other variations and types of smart cards are all applicable for use in conjunction with the present invention.

[0004] A smart card may include a microprocessor, random access memory ("RAM"), read-only memory ("ROM"), non-volatile memory, an encryption module (or arithmetic unit), and a card reader (or terminal) interface. Other features may be present such as optical storage, flash EEPROM, FRAM, a clock, a random number generator, interrupt control, control logic, a charge pump, power connections, and interface contacts that allow the card to communicate with the outside world. Of course, a smart card may be implemented in many ways, and need not necessarily include a microprocessor or other features. Various mechanical and electrical characteristics of a smart card and aspects of its interaction with a card reader device are described in Smart Card Handbook, W. Rankl and W. Effing, John Wiley & Sons, Ltd., 1997, and are defined by the following specifications, all of which are incorporated herein by reference: Visa Integrated Circuit Card Specification, Visa International Service Association, 1996; EMV Integrated Circuit Card Specification for Payment Systems, EMV Integrated Circuit Card Terminal Specification for Payment Systems, EMV Integrated Circuit Card Application Specification for Payment Systems, Visa International, MasterCard, Europay, 1996; and International Standard; Identification Cards - Integrated Circuit(s) Cards with Contacts, Parts 1-6, International Organization for Standardization, 1987-1995.

[0005] As is well known in the industry, smart cards tend to be significantly more advanced and sophisticated in comparison with common magnetic stripe only cards. Of course, cards that have both a magnetic stripe and a chip have been developed and are in use, but for the purposes of the present discussion it will be understood that a magnetic stripe card or system refers to those that only contain and utilize magnetic stripes, while a smart card or smart card system refers to any such card or system involving a microchip on the card itself. Such "smart cards" may thus include chip only cards, as well as combination chip and magnetic stripe cards. In comparing attributes, not only are the data storage capacities, fraud prevention and general security capabilities greater for a smart card as opposed to a standard magnetic stripe only card, but a smart card is also able to perform various processing functions that are simply not possible on the typical magnetic stripe card. Other added benefits that can be realized through the use of smart cards include the ability of such cards to run or to hold data from numerous applications on the same card, with such applications including, for example, credit and debit applications, loyalty programs, identification programs, stored value, e-purses, transit applications, and data mining, among others. [0006] Due to such significant advantages over magnetic stripe only cards, it is commonly thought that smart cards and systems represent the future for the payment card industry. In fact, many European nations have made significant strides in the use and implementation of such cards and systems. Unfortunately, many other nations and localities, and notably the United States, have not progressed much to date in this regard. While smart cards and systems do indeed deliver significant benefits over their magnetic stripe only counterparts, many vendors and merchants have been slow to adopt such smart cards and systems due to high implementation costs, technical complexity and long lead times. Other factors contributing to the resistance to adopt such cards and systems are the relatively low level of magnetic stripe card fraud within the United States and the general perception that the purposes for which these financial cards are used are served well enough by magnetic stripe only cards and systems, such that change is not perceived as necessary. Such reasons are not without merit, as the cost to purchase and locally install a single smart card system and one or more compatible terminals can run on the order of a quarter million dollars or more, which can be a significant sum for a single card accepting merchant. [0007] Further, many card accepting merchants can face issues involving long implementation lead times, with added complications due to incompatible systems or components in many cases. In the past, card and terminal developers, manufacturers and suppliers have usually received a functional specification for a new smart card based application independently. Typically, the cards and terminals are designed, tested, and produced in parallel. In particular, the production of a smart card includes creating the card application (i.e., computer code) that is to be loaded onto the smart card. Further, the production of a terminal includes the manufacture of the back-end system for handling terminal data, as well as the terminal application that runs on the terminal. As an aside, it is worth noting that for purposes of the present discussion, a terminal includes any upper or middle tier hardware used at a POS, such as the device or devices used in conjunction with a smart card at the POS to perform a financial transaction. A terminal may take any of a variety of physical forms and may be a stand alone unit, integrated with a computer, attached to the keyboard of a computer, a PCMCIA card, or may even be built in to a floppy disk-sized unit capable of being read from a disk drive of a computer, among others. Furthermore, a terminal may also be embodied in any portable device such as a laptop computer, a cellular telephone, or any PDA variety. In this regard, a terminal may incorporate one or more interface devices, as well as other components and interfaces, such as host communications. Together, the back-end system, terminal application and card application implement the overall application.

[0008] Because a considerable amount of latitude can exist in the interpretation of a given functional specification, however, suppliers working independently tend to create card and terminal application programs that are incompatible or have serious interoperability problems. As a result, additional development and testing time can be required to resolve the discrepancies, with the situation being further aggravated by the complexity of programming chip cards and their low-level interface to the terminal. Demand for smart card based applications can thus place considerable pressure on a scarce pool of qualified people, generally resulting in an extended time- to-market period. It is not surprising then to note the lack of cost-effective smart card products and systems for acquirers and merchants in the current marketplace. In particular, there are few products to enable retail merchants in the middle and upper tiers to integrate smart card payment capability into their existing card systems. [0009] In addressing many of the issues relating to incompatible systems and components, a number of industry bodies have developed various sets of standards and protocols in order to achieve some level of interoperability and uniformity across smart card products, terminals and platforms. One example is EMVCo, which has developed a set of standards and specifications that are specifically intended to address and alleviate some of the problems inherent to developing smart card systems and platforms. By way of reference, EMVCo, LLC, was formed in 1999 by Europay International, MasterCard International and Visa International to manage, maintain and enhance its set of "EMV Integrated Circuit Card Specifications for Payment Systems" as technology advances and chip card programs become more prevalent. The formation of EMVCo was designed to ensure that single terminal and card approval processes are developed at a level that will allow cross payment system interoperability through compliance with EMV specifications. To this end, Europay, MasterCard and Visa ("EMV") have worked jointly in recent years to develop specifications that define a set of requirements to ensure interoperability between chip cards and terminals on a global basis, regardless of manufacturer, financial institution, or where a card is used. The latest version of these specifications, EMV 2000 version 4.0, was published in December 2000. Additional information on this organization, its objectives and standards can be found online at http://www.emvco.com. [0010] Although helpful in many ways in reducing or eliminating initial levels of incompatibility between independently developed smart cards, terminals, platforms and systems, efforts by developers and manufacturers to adhere to EMV standards, apply for EMV review of a pending product, and receive an official EMV approval and certification for that product still involve significant amounts of time and money. As an illustrative example, EMV specifications require RSA public key cryptography, the implementation of which on an individual case-by-case basis can be costly and time consuming. While the existence of EMVCo and other like industry bodies is seen overall as positive, the end result to developers, manufacturers, and ultimately merchant users of card systems is still the same: a substantial investment of time and capital is required to adopt a system that accepts and processes smart cards. For many merchants, the costs and inconveniences associated with adopting such systems can seem to be too large a burden when their existing magnetic stripe card systems are perceived to function at adequate levels, especially when there does not appear to be any industry player leading a migration to the more attractive smart card systems. [0011] Accordingly, there exists a need for low cost systems and methods for implementing smart card systems, and in particular for such systems and methods to enable merchants with existing magnetic stripe card only systems to be able to adopt such smart card systems in a cost and time efficient manner.

SUMMARY [0012] The present invention provides an apparatus and method for enabling merchants with existing magnetic stripe only card systems to be able to adopt smart card systems in a cost and time efficient manner. One embodiment of the present invention involves upgrading an existing magnetic stripe card only terminal and system to be able to accept and process smart cards. This upgrading is accomplished by installing a pre-approved or certified smart card module and various supporting items and programs onto an existing magnetic stripe only card terminal. [0013] In response to the foregoing perceived market and regional needs, the present invention provides a solution that greatly reduces both the cost and time to market for terminal deployment by providing a pre-approved software module. This pre-approved smart card module provides software having public key cryptography features and other elements required for pre-approval or certification, such that a merchant or terminal provider adopting this module need not go through the time and expense of developing a new module or system, and also need not experience the full rigorous and time consuming process of having a new or modified terminal or series of terminals separately tested and approved. In this manner, the smart card module provides a low-cost solution for those merchants and terminal providers who wish to upgrade existing magnetic stripe card terminals. The inventive solutions disclosed herein provide merchants and vendors with a software module that is ready to "plug and play" in any POS device, with an estimated time savings ranging from 8 to 12 months, and a cost savings of thousands of dollars per terminal. [0014] In one specific embodiment, the smart card module is designed for an EMV terminal, has been pre-approved by EMVCo, and provides EMV Level 2 software. Accordingly, this particular smart card module has the appropriate RSA public key cryptography as required by EMVCo. This specific embodiment can be given the name "Visa Smart POS," "Smart POS," or any other similarly suitable brand name. Of course, other specific embodiments are also possible, and the smart card module in such other embodiments can similarly be pre-approved for the same or other terminal types by any other suitable industry body. In other embodiments, review or pre-approval by a standards or industry body is not undertaken. [0015] The inventive smart card module disclosed herein is designed so that it is not dependent on any particular environment, including any hardware, operating system or resident platform or modules on an existing terminal, such that the smart card module is easily implemented into virtually any new or existing POS system. This is accomplished in part through the use of various other modules and an application programming interface ("API") between the smart card module and another terminal component, such as the resident operating system on the terminal. In many embodiments, a number of APIs will be installed onto the terminal to facilitate communications between the smart card module and various other terminal components. In one specific embodiment, the smart card module and one or more of its associated APIs are developed according to VIS 1.4 and EMV 2000 specifications, and "pre-approvals," certifications or assurances are provided to that effect. Of course, other embodiments embracing alternative or no specifications may also be used. Various other software modules that enable system independence can include an access manager used for accessing all other services, a control program to manage control of the Point-of-Sale Module Control, a read program to read terminal and application configuration data, and a system cryptography program. [0016] In one embodiment, a full terminal upgrade can be developed, made, distributed, sold, installed and used as a complete unit that is already pre-approved by EMVCo or another like industry body, such that true "plug-and play" capabilities can be realized. In another embodiment, the smart card module and various associated modules and APIs can come as an incomplete unit, needing only custom final programming or tie-ins from the terminal developer, vendor, merchant or other end user. In such situations where some open source code is used, it may be necessary to provide a closed code kernel within the smart card module, such that this unalterable kernel may be able to receive and retain pre-approval from an industry body. In this manner, any final coding or custom implementation using an open source code will not permit a rewrite or other material alteration of the pre-approved kernel. Various methods for distributing and supporting the smart card module and its associated modules and APIs are available, and such methods can include downloading from a host web site, as well as obtaining copies from a compact disk, floppy disk, hard drive or other suitable storage medium. Base copies and updates may be made available through one or more of these methods, and live support may be provided as well. [0017] In particular embodiments, system drivers are written for a Windows 2000 operating system, with the actual smart card module being written in either of the industry standard C++ or Java programming languages. Depending upon the language used, installed platforms can include one or more of the commonly known GlobalPlatform Device ("GPD"), Small Terminal Interoperability Platform ("STIP"), Electronic Funds Transfer ("EFT") or POS platforms. As in the case of many potential platforms, the GPD/STIP API enables the development of portable applications across devices, and defines an open set of cooperating APIs for the acceptance of multi-application smart cards through a wide range of devices such as POS terminals, kiosks, mobile phones, ATMs, and PDAs, among others. Further details are provided for each of these environments due primarily to the predominant prevalence of these operating systems and languages in products in the current marketplace. Of course, other embodiments utilizing other operating systems, programming languages and platforms are also possible.

[0018] In general, the present invention contemplates a method of upgrading an existing magnetic stripe only card terminal to be capable of processing smart card transactions. This method involves selecting an existing card terminal that is able to facilitate the processing of magnetic stripe card transactions for a merchant. This card terminal includes at least a magnetic stripe card reading device and a computing device having an operating system originally designed to operate in conjunction with magnetic stripe card transactions but not smart card transactions. A number of software programs are installed onto this existing terminal, including a smart card module and at least one API. The smart card module is adapted to facilitate the processing of a smart card transaction, preferably implements EMV functionality, and is designed to operate independently from any hardware device, operating system or other resident component on the existing terminal. At least one API is adapted to facilitate communication between the smart card module and operating system. [0019] The method may also involve installing a smart card reading device onto the existing terminal, and may also include the pre-approval or certification of the smart card module by an industry standards organization, such as EMVCo. In addition, steps may be added for installing additional APIs, as well as for installing an environment services access module adapted to enable the operating system to select and activate one or more hardware devices. The method may also involve providing a portion of open source code to enable a user to customize the product for a particular environment, terminal or series of terminals.

[0020] Other apparatuses, methods, features and advantages of the invention will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional apparatuses, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS [0021] The included drawings are for illustrative purposes and serve to provide examples of possible structures for the disclosed inventive apparatuses, systems and methods. As such, these drawings in no way limit any changes in form and detail that may be made to the invention by one skilled in the art without departing from the spirit and scope of the invention.

[0022] FIGS. 1A and IB illustrate block diagrams of a generic computer system suitable for implementation in various embodiments of the present invention. [0023] FIG. 2 illustrates a block diagram of a physical implementation of an exemplary magnetic stripe only card terminal and system. [0024] FIG. 3 illustrates a block diagram of a physical implementation of an exemplary card terminal and system as shown in FIG. 2 upgraded to accept and process smart cards according to one embodiment of the present invention.

[0025] FIGS. 4A and 4B show block diagrams of terminal software architecture for a terminal upgraded according to one embodiment of the present invention.

[0026] FIG. 5 illustrates an extended tree diagram of a functional overview for an upgraded terminal according to one embodiment of the present invention.

[0027] FIG. 6 illustrates a combination block and flow diagram for one potential implementation and set of developmental roles for a Java based smart card module according to one embodiment of the present invention.

[0028] FIG. 7 illustrates a block diagram of one possible embodiment for a resulting Java based terminal having an installed smart card module.

[0029] FIG. 8 illustrates a combination block and flow diagram for one potential implementation and set of developmental roles for a C++ based smart card module according to one embodiment of the present invention.

[0030] FIG. 9 illustrates a block diagram of one possible embodiment for a resulting C++ based terminal having an installed smart card module.

[0031] FIG. 10 illustrates a block diagram of a system for remotely verifying a

PIN entry according to one embodiment of the present invention.

[0032] FIG. 11 illustrates a step-by-step time line of an exemplary process flow for remotely verifying a PIN entry according to one embodiment of the present invention.

DETAILED DESCRIPTION [0033] An example application of an apparatus and method according to the present invention is described in this section. This example is being provided to add context and aid in the understanding of the invention. It will thus be apparent to one skilled in the art that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the present invention. Although these embodiments are described in sufficient detail to enable one skilled in the art to practice the invention, it is understood that these examples are not limiting; such that other embodiments may be used, and changes may be made without departing from the spirit and scope of the invention. [0034] One advantage of the present invention is the provision of smart card apparatuses and systems for relatively low costs and lead times. Another advantage of the present invention is the ability to modify an existing magnetic stripe card terminal and system such that it is able to accept smart cards and process smart card transactions. Yet another advantage is the provision of a core smart card module that is pre-approved by an industry standards organization, such that the benefits of being pre-approved can be realized, while the costly and lengthy approval process can be largely or entirely avoided for a given user. Other advantages provided by the present invention include the ability to resolve interoperability problems by promoting and using a common kernel, and the ability to avoid having to develop a full slate of proprietary programs from scratch. These and other advantages will become readily apparent upon review of the following figures and detailed description.

COMPUTER SYSTEM AND TERMINAL HARDWARE [0035] Turning first to FIGS. 1 A and IB, a generic computer system suitable for implementation in various embodiments of the present invention is illustrated in block diagram format. FIG. 1 A shows one possible physical form of the computer system. Of course, the computer system may have many physical forms ranging from an integrated circuit, a printed circuit board and a small handheld device up to a huge supercomputer. Computer system or server 10 includes a monitor 12, a display 14, a housing 16, a disk drive 18, a keyboard 20 and a mouse 22. Disk 24 is a computer- readable medium used to transfer data to and from computer system 10. Other suitable data transfer mediums may also be used, as detailed below. FIG. IB shows another block diagram for computer system 10. Attached to a system bus 10 are a wide variety of subsystems. One or more processors, preferably including at least one central processing unit ("CPU") 32 are coupled to storage devices including memory 34, which can be in the form of RAM, ROM, flash RAM or any of a number of other memory types. As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU and RAM is used typically to transfer data and instructions in a bi-directional manner. Both of these types of memories may include any suitable of the computer-readable media described below. A fixed disk 36 such as a resident hard disk is also coupled bi-directionally to CPU 32; it provides additional data storage capacity and may also include any of the computer-readable media described below. Fixed disk 36 may be used to store programs, data and the like and is typically a secondary storage medium that is slower than primary storage. It will be appreciated that the information retained within fixed disk 36, may be incorporated in standard fashion as virtual memory in memory 34. Removable disk 24 may take the form of any of the computer-readable media described below. [0036] CPU 32 is also coupled to a variety of input/output devices such as display 14, keyboard 20, mouse 22 and speakers 40. In general, an input/output device may be of any suitable type, including, but not limited to, video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, or other computers. CPU 32 optionally may be coupled to a terminal system, another computer or a telecommunications network using network interface 50. With such a network interface, it is contemplated that the CPU might receive information from a terminal or network, and might output information to a terminal or network in the course of performing one or more process steps. In addition, embodiments of the present invention further relate to computer storage products with a computer- readable medium that have computer code thereon for performing various computer- implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits, programmable logic devices and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher level code that are executed by a computer using an inteφreter. Of course, other suitable devices and computer components may also be used in conjunction with the present invention, as will be readily appreciated. [0037] Referring next to FIG. 2, a physical implementation of an exemplary magnetic stripe only card terminal and system is similarly illustrated in block diagram format. Computer system or server 10 functions as a central unit for a single terminal 90 at a merchant or other end user. Terminal 90 may be any of a wide variety of terminals suitable for use with the present invention. By way of example, terminal types such as retail POS terminals and stand-alone credit/debit card authorization terminals work well, and specific commercially available terminal models such as an IBM 4690 using a Magtek Magstripe Card Reader, an NCR 74xx series POS connected to a VeriFone Everest Plus, a Hypercom T7, and a VeriFone Tranz 330, among others, may be used. Various card readers and other system devices can all connect directly to this central unit, or along a common bus or other similar shared communication arrangement.

[0038] As shown, each card reading device is preferably adapted to be able to read a magnetic stripe card 60, with exemplary card reading devices including a basic mag stripe card reader 70, a combination card reader and numerical key entry pad unit 71 and a complete ATM 73. Additional items can include a cash register 72 or other similar retail device, which may be linked to a card reader directly and may also be linked to computer system or server 10 directly. Of course, other types of card readers may be used, and not every type of card reader shown must be present in any given terminal or system. In addition, multiple units of one or more types may also be present within a given system. As will be readily appreciated by those skilled in the art, this local terminal comprising computer system 10 and its associated card readers or other units is preferably connected to a financial network via a network switching fabric 80, with at least one associated bank 81 or other financial institution similarly connected to the network.

[0039] Continuing on to FIG. 3, a physical implementation of an exemplary card terminal and system as shown in FIG. 2 upgraded to accept and process smart cards according to one embodiment of the present invention is shown. Computer system or server 10 still functions as a central unit for a single upgraded terminal 100 at a merchant or other end user. As before, various card readers and other system devices, such as cash register 72, can all connect directly to this central unit, or along a common bus or other similar shared communication arrangement. In addition to various magnetic stripe card reading devices, one or more smart card reading devices have been installed onto terminal 100. Each smart card reading device is preferably adapted to be able to read a smart card 160, with exemplary smart card reading devices including a basic smart card reader 170, a combination magnetic stripe card reader, smart card reader and numerical key entry pad unit 171 and a complete ATM 173 similarly adapted to read both magnetic stripe cards and smart cards. A variety of commercially available smart card readers may be used, including, for example, an NCR Real POS workstation using a Cherry keyboard G80-8117, an IBM Sure POS connected to a Magtek IntelliPIN SPT, a VeriFone Omni 3350, a Cybernet Jade, and an Intellect Presto 21 Op, among others. Devices adapted to read both magnetic stripe cards and smart cards are well known in the art, as are cards that have both a magnetic stripe and an embedded chip. It is specifically contemplated that all such devices and cards may be used in conjunction with the present invention. As before, other types of card readers may be used, not every type of card reader shown must be present in any given terminal or system, and multiple units of one or more types may also be present within a given system.

[0040] It will also be appreciated that many elements of the existing magnetic stripe only card terminal of FIG. 2 are carried over and used in the upgraded terminal as shown in FIG. 3 in the same or a substantially similar form. One element that is substantially similar from a physical or hardware perspective is computer system or server 10. However, substantial additions in the form of software modules and interfaces have been made to this computer system to arrive at an embodiment of the present invention, as will be described in greater detail below. As noted above, these upgrades are preferably made in conformance with standards or guidelines of an industry body, such as EMVCo, to ensure system portability and interoperability. Other similar industry bodies such as, for example, ANSI, CCITT, IEEE, ISO, and UL, among others, might also provide a suitable set of standards and certification similar to that which is described herein. Exemplary details of such standards for EMV in particular will now be provided.

DEVICE STANDARDIZATION FOR EMV [0041] When device developers or manufacturers wish to develop or produce an EMV application for any terminal product, it is typically required that these parties submit their devices for testing to an EMV approved laboratory. These laboratories will, for a fee, perform the necessary tests for a particular EMV implementation. Typically, each proposed product must go through its own separate testing process, and approved products generally receive a clean report with type approval appearing on the EMVCo web site at http://www.emvco.com. Further details on the EMV certification process and the EMV specifications for devices are available on the EMV web site. Key requirements for EMV certification or approval include the proper use of appropriate RSA public key cryptography and routines, as well as proper data management routines. Additional requirements are similarly available in further detail on the EMV web site.

[0042] It is a particular objective of the present invention to provide a smart card module upgrade that is already pre-approved by an industry body such as EMVCo, such that this pre-approved module can be inserted into an existing system or terminal without any further approval from EMVCo being required. In this regard, authorized EMV labs are supplied with a proposed product having appropriate checksums and validation routines that will verify whether proper driver versions have been used. If the test conditions are met, the checksum will add up properly and the challenge responses seen through the test sequence will match, as will be readily understood by those skilled in the art. Data elements resident in the terminal and accessed during EMV transactions can be derived from different sources, such as from a registry where the data is stored under terminal specific key, configuration files, OS command values, and the like. It is the task of a configuration control program to provide a unified interface to get a data item based on its name and regardless where it is stored on the particular terminal. Exemplary data elements that can be used in EMV-related transactions and stored on a terminal are listed in Table 1 below.

Table 1 : Terminal Data Elements

TERMINAL SOFTWARE ARCHITECTURE [0043] The present invention enables a smart card module to be written that can be installed and run on any terminal or operating environment. This is accomplished through the implementation of a particularly useful terminal software architecture. A similar architecture is described in commonly assigned U.S. Patent Application No. 09/369,502, by Kashef et al., filed August 5, 1999, which reference is incoφorated by reference herein in its entirety and for all puφoses. Turning now to FIG. 4A, a terminal software architecture overview for a terminal upgraded according to one embodiment of the present invention is illustrated in block diagram format. As shown, the provided terminal software architecture 200 comprises three primary layers: a business logic layer 210, a core logic layer 220 and an environment layer 230. While the business logic layer 210 and environment layer 230 generally represent those devices and programs that can be found in the pre-existing magnetic stripe only card terminal, the core logic layer 220 generally represents those modules and programs added to the terminal to permit the acceptance of smart cards and processing of smart card transactions by the terminal. Of course, exceptions to these generalizations can exist, with one obvious example being the implementation of a new smart card reading device, which would fall into the environment layer 230, with its accompanying device application falling under the business logic layer 210. [0044] Listing various pertinent attributes of each general layer, business logic layer 210 comprises the terminal layer that may have one or more of the following characteristics: 1) provides initial screens and options through the user interface; 2) provides the means to enter and/or modify payment applications and terminal configuration data; 3) provides the means to select the POS application controlling a transaction; 4) initializes one or more smart card module and/or API libraries at start up; 5) calls smart card module API functions to conduct smart card processing according to EMV2000 and VIS 1.4.0 specifications; 6) controls an overall execution flow; and 7) can be implemented on the terminal as an executable element (e.g., a resident program, NT service). Conversely, the core logic layer 220 comprises the terminal layer that may have one or more of the following characteristics: 1) initializes internal objects with configuration data stored at the terminal; 2) executes a corresponding core module, such as a payment application, in response to a request from the POS application; 3) provides a set of utility functions, such as data conversion, TLV conversion, and EMV functions; 4) returns a status result to the POS application, allowing it to continue execution of the program; 5) prepares all messages for transaction to the card by formatting them in Basic Encoding Rules - Tag Length Value ("BER-TLV") format; 6) parses data received from the card by extracting it from BER-TLV format; 7) uses standard interfaces or APIs to communicate with all device drivers, as well as with a crypto library, file system, issuer (for online authentication), and specific payment applications; and 8) can be implemented on the terminal as a dynamic link library ("DLL"). [0045] Finally, environment layer 230 comprises the terminal layer that may have one or more of the following characteristics: 1) provides standard interfaces to read/ write data from/to peripheral devices; 2) provides one or more standard interfaces to operating system commands; 3) provides standard interface to cryptographic services; 4) provides standard interface to the host communication services (e.g., to connect to an issuer for online authentication); 5) and can be implemented on the terminal as a dynamic library or set of APIs. While the environment layer 230 generally comprises hardware, an operating system and other resident terminal elements, such that various APIs can be thought to belong to this layer, many or all APIs may also be thought to belong to the core logic or business logic layers. In reality, many or all APIs are truly conduits between layers or layer elements, such that each may be associated with any layer to which it connects, as will be readily appreciated by those skilled in the art. [0046] Continuing on to FIG. 4B, a block diagram illustrating a more detailed terminal software architecture according to one embodiment of the present invention is provided. As shown in this detailed figure, the architecture permits the modular addition of software to a terminal to enable the added smart card module to be written so that it is platform independent. The terminal architecture illustrated in FIG. 4B includes multiple layers, with each layer using the layers below it. It is important to note that terminal 200 includes an environment component that is separate from the portion that is platform independent. The environment component is platform dependent and includes the hardware 232 produced by the terminal manufacturer and the operating system 234. The operating system is unique to the type of terminal and therefore dependent on the terminal hardware, and also provides a hospitable environment for the execution of terminal applications. More particularly, the operating system 234 is responsible for a wide variety of functions including memory management, scheduling and dispatching processor tasks, supporting file systems, and managing the physical devices that constitute the terminal (e.g., display, keyboard, telecommunication adapter and modem, printer, etc.). In addition, various utility programs, such as software download utilities, are sometimes included as operating system components.

[0047] It is important to note that the terminal architecture of the present invention does not require modifications to the hardware 232 or operating system 234. The terminal environment also includes one or more POS or device applications 212, which provide functions unique to a specific terminal installation and are responsible for implementing the business policies of the entity placing the terminal. Examples of specific terminal installations include a gasoline pump, pay telephone, or vending machine, among others, and examples of the types of business policies that are implemented are those relating to the user interface such as providing a menu for application selection and priorities for selecting an application. Other examples of the types of business policies that are implemented include the types of payment instruments accepted, refund policies, and whether split tenders are permitted. [0048] In addition to the foregoing general environment elements, several other elements are added to the terminal or are substantially modified in order to facilitate the addition of the environment independent smart card module 222. As can be seen in FIG. 4B, these added or modified elements are shaded, while the pre-existing magnetic stripe only card terminal elements are not. In addition to smart card module 222, an environment services layer or "Platform API" 224 is added. Environment services may include, but are not limited to, accessing peripherals such as a printer and user interface. Thus, the terminal application may access the environment services necessary to run on any terminal. Further, in order to enable the smart card module 222 to communicate with various environment programs and devices, two additional standard APIs are provided. One standard API 228 is provided to enable the POS or device application layer to use the services provided by the smart card module 222, while another standard API 226 is provided to enable the smart card module to communicate with the environment services layer 224. In this manner, the smart card module is portable within different terminals. Standard APIs 226, 228 preferably make the function and/or procedure names along with their parameter names and types visible to the layer accessing them, such that the core portable smart card module 222 can be written independently of the terminal environment. [0049] Finally, portable smart card module 222 is provided within this upgraded terminal architecture, with this module representing the environment and platform independent component of a terminal application that will run on the terminal and interact with the card application. As a result, services and functions supported by the smart card module 222 are limited to those that are insensitive to a particular operating environment. For example, the smart card module does not necessarily implement a user interface specifically directed to a local language. As another example, the smart card module does not support a data communication protocol employed by external transaction authorizers and acquirers. Instead, the smart card module 222 calls upon services provided by the environment services layer 224 to accomplish tasks that are unique to its installation environment. Accordingly, this smart card module is completely portable, since it has no hardware dependencies.

FUNCTIONAL OVERVIEW AND IMPLEMENTATION CONSIDERATIONS [0050] Turning now to FIG. 5, a functional overview for an upgraded terminal according to one embodiment of the present invention is illustrated in extended tree format. As shown, the sum of the various installed and/or modified software elements 220 can be divided up according to functional modules 240 and their called upon API libraries 250. The portable core element smart card module 222 comprises two basic modules: a directory service module 222 A, which is adapted to call upon an EMV application select library 251, and a payment application module 222B, which is adapted to call upon an EMV 2000 & VIS 1.4.0 transaction library set 252. Of course, the actual libraries used can vary according to the particular embodiment, and it will be readily appreciated that many other libraries according to different standards or protocols may be used in place of the specific examples provided herein. In fact, this will be true in the instance of many or all of the exemplary libraries provided in this illustrative example, such that a developer or programmer may have the freedom to choose from many potential existing and future libraries in constructing such an installed system of functional modules and API libraries.

[0051] Continuing on, a set of utilities modules 223 is also included, with such utilities modules potentially including one or more API modules or elements. At a minimum, utilities 223 preferably includes an EMV module 223 A, which is adapted to call upon a variety of API libraries, such as those from a set or series of EMV specific utility functions 253, those from a set or series of general EMV functions 257 and a data conversion library 259. Exemplary EMV specific utility function libraries may include an APDU conversion library 254, a BER-TLV conversion library 255 and other EMV specific utilities 256. Various general EMV functional libraries 258 are generally depicted as a generic grouping. Further, a runtime support environment element 224 or "Platform API" includes at least a service module 224A, which can call upon a number of terminal services and API libraries. Such services and libraries may include, for example, a cardholder verification ("CHV") processing or personal identification number ("PIN") 260, a user interface 261, various storage elements 262, a host communication or acquirer interface 263, a smart card reader 264, a magnetic stripe card reader 265, various base system utilities 266 and one or more cryptography functions and libraries 267. [0052] Although any of a wide variety of programming languages, operating systems and platforms may be used for each of the foregoing elements, the smart card module itself, and the card terminal in general, several specific embodiments of the present invention disclosed herein contemplate use within a terminal having either a Windows operating system or a Java Virtual Machine with appropriate support for the STIP and GPD APIs. This is primarily due to the overwhelming presence of such terminals and terminal systems in the current marketplace. It will be readily appreciated, however, that the inventive systems and methods disclosed herein can be used for any operating system. For such terminals, two specific examples of smart card modules and accompanying APIs and other elements are provided herein. The first specific example is a Java computer code version of the inventive smart card module, which is built to interface with devices supporting GlobalPlatform Device and STIP technologies. The second specific example of a smart card module is a C++ computer code version, which interfaces with a device offering a STIP-like API. In both cases, the smart card module is a portable implementation of core EMV logic that can be used across a multitude of card acceptance devices where interoperability is facilitated using STIP and GlobalPlatform Device technologies. Again, the Java and C++ programming languages have been selected for specific examples primarily due to the prevalence and compatibility of these languages in the vast majority of devices, platforms and APIs in the current marketplace. It will be readily appreciated that other programming languages may also be used in other embodiments or implementations developed according to the systems and methods disclosed herein. [0053] Furthermore, in many of the embodiments and specific detailed examples disclosed herein, the provided smart card module only represents the core logic of a required EMV application, and as such may not be a true plug-and-play application module. This is primarily due to the wide variances in specifics inherent to the many terminals, card reading devices and other hardware components in the current marketplace, such that an accounting for every such system, device and component in one comprehensive plug-and-play unit is not practical or cost-effective. Thus, any device-specific and EMV permissible functionality that is not present in an exemplary smart card module as provided will need to be added by the device manufacturer or end user. Such additions can be relatively simple for a given manufacturer or user, however, with provisions for a partial open source code and closed pre-approved smart card module kernel aiding in this regard. In any event, several integration steps need to be performed before a smart card module can be used in a device supporting the STIP/GlobalPlatform Device technology or a similar technology, as will be readily appreciated by those skilled in the art.

JAVA IMPLEMENTED EMBODIMENT [0054] Before disclosing various features and details of a specific Java computer code embodiment for the provided smart card modular upgrade, some background into the specifically relevant Small Terminal Interoperability Platform ("STIP") and GlobalPlatform Device ("GPD") Platform APIs may prove to be useful. In general, as the growth of EMV as a standard for chip based payment took hold over time, the need materialized to develop products that supported EMV applications. Several industry participants realized that instead of each manufacturer reinventing the wheel for each new application, it would be more prudent to develop standards that would enable the development of applications that are interoperable and portable across many devices. One of these initiatives was STIP, an offshoot of the Java-based efforts to produce devices based on the Java 2 Micro Edition ("J2ME") technology of Sun Microsystems. A separate broader consortium known as GlobalPlatform worked in parallel to produce standards for the development, issuance, acceptance and ongoing management of multi-application chip cards. The work of STIP and GlobalPlatform eventually merged in the device area, with the work of STIP acting as a common core for the GlobalPlatform device work. STIP has also parlayed its standards into industry specific areas, such as the financial payments arena with FINREAD, and emergent work with the mobile industry with the Mobile Payment Forum. As a testament to the broad acceptance that STEP technology standards have gained, and the recognized need to promote these standards to a larger, cross-industry audience, STEP is planning to merge with GlobalPlatform. Accordingly, it is virtually required that any smart card module implemented using the Java programming language be designed and adapted for use with a STEP/GlobalPlatform API. [0055] Various business objectives of STEP include provisions for: 1) secure transactions for both magnetic stripe and smart card devices; 2) a broad range of terminals, with a virtually industry-agnostic terminal coverage; 3) supplier independence, with interoperability across numerous supplier device offerings; 4) a decreased time to market with respect to the development and deployment of terminal applications; 5) minimized terminal application development costs; 6) support for devices with multiple applications; 7) ongoing maintenance or servicing; 8) a reduced certification effort; and 9) an effort to preserve relationships between operating entities. Further, various exemplary functional requirements of STEP include those for: 1) Peripherals and services - define support for smart card readers, magnetic stripe readers, cardholder verification, heterogeneous displays, keypads, printers and other modes of communications, persistent storage, cryptography and networking, among others; 2) Common platform definition - minimal platform requirements to achieve interoperability; 3) Common API and high level programming language - provide a minimum set of APIs to achieve interoperability, and the usage of a single, common programming language for the API to accelerate application development time; 4) Idle state management - support the idle state in a multi-application environment; 5) Application selection mechanism, firewall and lifecycle management - provide a means to facilitate application selection in a multi-application environment, to protect the confidentiality and integrity of each application from neighboring applications on the same device, and to manage deployed applications on a terminal; 6) Compliance test suites -provide a compliance test suite for both applications and platforms to provide a means for acquirer certification and to ensure interoperability; and 7) Reference implementation - provide a reference implementation to enable the validation of application compliance with STIP specifications. Of course, it will be readily appreciated that the forgoing lists comprise a selection of offerings from STEP, with comprehensive lists of business objectives and requirements being provided in the STEP 2.1 Specification Overview document available at the http://www.stip.org web site.

[0056] A basic device architecture envisioned by the STIP specifications is one where a standard API service suite and standardized access to device services is used to isolate a device implementation from the application running on that device. The architecture generally consists of a set of Java interfaces, including a core subset of Java, and is designed to operate in an event-driven manner where services can be accessed asynchronously. This synchronous, event-oriented approach for all device platform resources ensures efficiency and safety, interoperability, and the ability to handle remote services. In particular, STEP is composed of the STEP Core Framework Technology ("SCFT"), which defines the mechanisms and Java interfaces utilized by the STEP API, and a standard API consisting of common or fundamental services and industry or market specific services. The combination of the SCFT, the standard API, and a set of industry or market specific services is known as a "STEP Profile." A set of standard APIs designed to handle payment applications, for example, is provided in the STEP specifications as a sample EFT-POS STIP Profile. [0057] In a particular STEP implementation, the SCFT can be comprised of an Access Manager interface, service control interfaces, and various core Java elements. The core Java elements used can be subsets of the packages java.lang, java.util, and java.io, as defined by the CLDC configuration of J2ME. Remaining interfaces defined in the SCFT may be stip. access, stip. control, stip.util and stip. stiplet. The Access Manager is used to manage the services available on a platform, and the application residing on a STEP enabled device, the stiplet, uses the Access Manager to request access to service controls. Service controls provide a standardized means of accessing platform services, and thus help to ensure the interoperability of applications written for STEP enabled devices. Each service control preferably offers standard open() and close() methods and can be asynchronous event driven. Service controls are preferably implemented in a way such that the underlying platform services are never directly accessed. It is important to note that service control types must typically be Java interfaces and not concrete classes.

[0058] GlobalPlatform Device APIs effectively represent an additional layer on top of a STEP API. This additional layer is used to achieve a higher level of interoperability than can be obtained with a stiplet. The development of the stiplet requires a more detailed knowledge of the capabilities and features of some of the services required, notably those for user interface elements, host interfaces, and printer peripherals. Thus, it is conceivable that a particular stiplet for a particular device platform may require some reworking if different services or a different device platform are deployed. In contrast, GlobalPlatform defines the concept of a Core Logic Component ("CLC"), which is effectively a subset of a stiplet. It attempts to consolidate all application specific logic within itself. Before the CLC can be implemented on a STEP enabled device, the CLC must be encapsulated with basic STEP APIs, and service abstraction APIs must be created to communicate with the service controls of the device. Hence, in order to use a CLC, a system integrator or platform provider must develop this stiplet to CLC encapsulation software and the abstract service implementations. By specifying the interfaces for the abstract service implementations, GPD APIs represent a level above a typical STEP profile. [0059] Specifically, GPD interfaces extend into the stiplet. The GPD API generally comprises a core and a set of standard extensions, mirroring the SCFT and fundamental services framework of STEP. The GPD core consists of the SCFT core Java and STEP components, minus the stip. stiplet interface. It also includes a stip.devicecontrol.smartcardslot interface and a org.globalplatform.modulecontrol.clc program. Since GPD is concerned about smart card acceptance, it is assumed that all GlobalPlatform devices will have smart card capabilities. Additional details of the STEP Core Technology Framework and the GlobalPlatform Device API, as well as testers and other useful items can be obtained from the http://www.stip.org and http://www.globalplatform.org web sites respectively.

[0060] In general, the specific Java coded embodiment of the inventive smart card module disclosed herein is built to be incoφorated into a STEP enabled device, with the relevant stiplet being the combination of a core application logic, an Access Manager, and assorted service abstractions that enable the core application logic to be more completely portable. An included GlobalPlatform Device API may facilitate this increased portability. As noted previously, however, the Java based smart card module is not a true plug-and-play package, such that a provider or user will need to create the core interfaces of the relevant STEP SCTF and the fundamental services required by the smart card module. The device can then implement these fundamental services to interface with integrated or independent peripherals or services as required. [0061] Referring to FIG. 6, a combination block and flow diagram illustrates one potential implementation and set of developmental roles for a Java based smart card module according to one embodiment of the present invention. As shown, a full Java implementation 300 onto a terminal can involve a Java Stiplet Implementation process 310 to arrive at a Complete STEP Platform API 320 for the terminal, with one potential method for performing this process being provided in method steps S301 through S306. Various phases of Java Stiplet Implementation include a Stiplet to CLC or smart card module Encapsulation Software production phase 311 , a Smart Card Module Implementation phase 312, and an Abstract Services Implementation phase 313. Once each of these phases has been completed, a complete STIP Platform API 320 can be achieved, with this complete API preferably having at least a partial STEP API component 321 that is visible from the CLC or smart card module. [0062] Following one potential method for such a Java implementation, a start step S301 leads to a first process step S302, where a system integrator is the party responsible for encapsulating the smart card module or CLC to a Java stiplet. At a next step S303, the smart card module developer provides at least a partial open source code for the smart card module, such that the systems integrator can then perform the next process step. Of course, it will be readily appreciated that step S303 may take place before or after the actual performance of step S302, with little or no material affect to the process or product as a result. At a following process step S304, the systems integrator then develops vaπous abstract service implementations that are required yet not supported by the STEP API, which is a significant reason for the provision of at least a partial level of open source code on the part of the smart card module developer and provider. At a next process step S305, a platform provider provides a STEP API implementation, after which the method is complete and ends at an end step S306. Again, the actual placement of process step S305 does not need to come last in all cases, and may in fact occur before one or more of the other steps. [0063] Continuing on to FIG. 7, one possible embodiment for a resulting Java based terminal having a smart card module installed is shown in block diagram format. Java terminal 350 comprises a specific terminal application 360, termed "PCApplication.java," which is preferably adapted to operate atop and communicate with a Windows Java environment 370 built atop a standard Windows PC operating system 372, termed "PCTerminal.java." The Windows Java environment 370 comprises a complete STEP Platform API 371, termed "PCShell.java," which contains various submodules or drivers 373, such as those for a smart card slot, cryptography library access or function, file accessing function, date or clock program, and/or CHV program, among others. Within the terminal application 360 is the portable smart card module 363 and associated API elements such as an access manager 361, a directory service 362, and various standard API elements or submodules 364 inteφosed between the smart card module and the Windows Java environment. Such standard API elements or submodules 364 may include, for example, a host driver, a UI driver and a printer driver, among others.

C++ IMPLEMENTED EMBODIMENT [0064] Because there is no C-type API that conforms to STEP specifications at the present time, details regarding the implementation of a Platform API for a C++ smart card module embodiment are emulated after those of a STEP -based environment for puφoses of the present invention. Unless an until a STEP-based Platform API can be used in a C++ implementation, it will be assumed that such a C++ version uses a non- standard STEP layer and assumes a synchronous terminal architecture. At a basic level, however, a C++ based smart card module implementation is fundamentally the same as the Java based implementation disclosed above. Both implementations include a portable EMV Level 2 software module, require a standard API on the device (i.e., a STEP layer), and require a level of software integration to enable the EMV module to function coπectly on the target device. In the C++ version, the core logic of the smart card module can similarly be provided as production ready code, designed to be used in different environments and completed by a terminal provider or end user. Since the runtime implementation is designed for a PC environment, however, and hence, it may become necessary to modify the runtime implementation on non-PC platforms.

[0065] This requirement is essentially the same as in the Java version though, in that the software provided for the C++ version preferably includes a PC-based implementation of STEP for a PC-based card acceptance device emulator that needs to be changed depending on the target platform for the EMV software. Finally, from an architecture perspective, the primary difference of note in the software architecture between the C++ and Java versions of the portable smart card module is that the former operates with the assumption that all services operate on a synchronous basis. Thus, it is not possible to engage another service until the existing outstanding request is processed. One byproduct of this design is that the C++ version requires no listeners to accept event messages from the service controls. With respect to all other primary characteristics and features though, the two versions are substantially similar enough, such that one of reasonable skill in the art will be able to produce an operable STEP-like Platform API for use in a C++ terminal environment. [0066] Turning now to FIG. 8, a combination block and flow diagram illustrates one potential implementation and set of developmental roles for a C++ based smart card module according to one embodiment of the present invention. As shown, a full C++ implementation 400 onto a terminal can involve a C++ module implementation process 410 to arrive at a full platform implementation 420 for the terminal, with one potential method for performing this process being provided in method steps S401 through S406. Various phases of C++ module implementation include a smart card module implementation phase 411, an access manager implementation phase 412, and a client-side services implementation phase 413. Once each of these phases has been completed, a full platform implementation can be achieved, with this full C++ based platform likely having various server-side service implementations 421. [0067] Following one potential method for such a C++ module implementation, a start step S401 leads to a first process step S402, where a smart card module developer or provider provides or implements a smart card module. At a next step S403, a systems integrator develops an access manager for the smart card module, such that the systems integrator can then perform the next process step. At a following process step S404, the systems integrator then develops various client-side service implementations that are required yet not supported by the system, which again is a significant reason for the provision of at least a partial level of open source code on the part of the smart card module developer and provider. At a next process step S405, a platform provider provides server-side service controls similar to those of a STEP API implementation, after which the method is complete and ends at an end step S406. As in the foregoing embodiment above, the actual succession or placement of one or more process steps is not set in stone, and in fact one or more steps may occur before or in parallel with one or more of the other steps. [0068] Proceeding now to FIG. 9, one possible embodiment for a resulting C++ language based terminal having a smart card module installed is shown in block diagram format. C++ terminal 450 comprises a specific terminal application 460, which may include some elements in Visual Basic or other similar suitable languages, and which is preferably adapted to operate atop and communicate with a Windows C++ environment 470 built atop a standard Windows PC operating system 371, which may in turn be implemented via DLLs. The Windows C++ environment 470 preferably comprises a full platform API that may be substantially similar to a complete STEP Platform API, and which contains various submodules or drivers 472, such as those for configuration control, cryptography control, host control, PIN control, POS control, reference control, SCR control, system control, UI control, smart card module control and/or application selection control, among others. Within the terminal application 460 is the portable smart card module 464 and associated API elements such as an access manager 461, a smart card module control program 462, and an application control program 463. In addition, various standard API elements or submodules 465 are preferably inteφosed between the smart card module and corresponding elements or submodules 472 within the Windows C++ environment, as will be readily appreciated.

OPEN SOURCE CODE [0069] As will also be readily appreciated, there exists some concern over the security considerations with allowing the general public to view and work with even a part of the EMV level 2 driver source code. To combat claims that variations to the pre-approved driver could be given un-tested approval, it is preferably that EMV level 2 pre-approval only be granted to applications that use the original version of the provided driver and test driver. Such drivers may be made available either as a download from a web site, through hard copy means such as a magnetic type disk or optical type disk, or via any other suitable method. To validate the use of the proper driver, a checksum style validation is preferably built into an EMV Level 2 test driver application. Then when an application is in front of EMV for approval based on the use of the EMV level 2 driver, the test checksums and prompts can be run to confirm that the driver is valid. Depending on the perceived threat of fraud, the sophistication of such checksums can be varied as desired. In order to gain approval, it is preferable that the application developer be required to compile the terminal unique application with the EMV Level 2 test driver and submit it to an EMV lab for approval testing. Although a bit inconvenient, this option is thought to be much more appealing than being required to go through a full development and approval process from scratch.

REMOTE VERIFICATION OF USER PEN [0070] As a final item, it is worth recalling for at least one particular feature that the use of smart cards and smart card based systems provides improved capabilities, as well as a range of new capabilities not present in many magnetic stripe card systems. For example, the use of a PIN or other validation feature can involve new methods or entire approaches, since a smart card does contain a processor and various encrypted communication possibilities. In many card-based systems, the typical practice is to encrypt a PIN before it is exported from an associated PIN pad. Such a restriction severely limits what may be done with a PIN pad used in conjunction with a smart card system, however, since it is not possible or practical under cuπent methods and technologies to have three locations for cryptography keys in a single transaction. Since one key must reside across a network at an issuer or other financial institution, that only leaves one key for the terminal and smart card combined. [0071] As a result, the use of a remote PIN pad in a smart card transaction likely results in an undesirable situation where an unencrypted PEN string is sent from the PIN pad to the terminal. In fact, most all card applications involve either sending an encrypted PEN from an associated PIN pad or the use of a PIN pad that is integrated with another terminal hardware device, such as a host computer or server. This situation is unfortunate, in that it would be desirable to achieve remote verification of PEN entries without compromising the security of the PEN data string through an unencrypted transmission.

[0072] Turning now to FIG. 10, a system for remotely verifying a PIN entry is illustrated in block diagram format. While remote verification system 500 may include the same network 80, financial institution 81 and computing system or server 10 that have been previously disclosed and described, elements such as a particular smart card 560, a particular integrated smart card reader and PIN pad 571, and a particular cash register 572 or other suitable terminal device are preferably adapted so as to be compatible with the remote verification system and method provided. To some extent, this may also involve the addition of more modules or software elements to the computing system or server 10, although it may not be necessary to add hardware to this computer itself.

[0073] In essence, the remote verification system 500 is adapted such that the chip logic component of smart card 560 obtains an unencrypted data string for the entered PEN, such that the card itself can receive and analyze whether the entered PEN is correct. This is likely considered acceptable due to the integrated nature of the card reader and PIN pad, such that the chance for data interception along a communication line is minimized or eliminated in many instances. Preferably, the PEN is not sent to the computer 10 and smart card module residing thereon, but is directly transferred only to the smart card itself. After analyzing the entered PIN, the smart card 560 can then provide an unencrypted "approved" or "not approved" signal to the computer system or server 10, or another appropriate terminal hardware devices, such as cash register 572. Such devices are preferably adapted to accept and act upon such a signal from the smart card itself, with appropriate encrypted communications then taking place as usual between financial institution 81 along network 80. [0074] Referring lastly to FIG. 11, a process flow diagram for remotely verifying a PIN entry is illustrated in step and time line format. As shown, remote PEN verification process 600 involves various terminal elements, such as a smart card module kernel, CHV control program, device application, PIN pad and smart card reader. These various terminal elements experience events and issue commands or results in a particular process flow, the various steps, prompts and results for which can be readily seen and appreciated. Of course, other process flows with differing sets of terminal elements, process steps, prompts and results may also be adequate for puφoses of remotely verifying a proper PEN through a plain text data transfer, and all such suitable process flows are also contemplated for use in the present invention. [0075] Specific hardware and implementation details for such a remote PIN pad verification system, as well as further details, tables, configurations, library types and contents and other informational items on STEP , GPD, RSA cryptography and specific embodiments for both Java and C++ smart card module applications can be found in a variety of documents, including: Visa SmartP OS EMV Integration Guide, version 1.1, Visa International Service Association, March 30, 2004; SmartPOS - EMV Level 2 Terminal Software Functional Specification, Smart Card Solutions for Visa International Service Association, December 30, 2002; Visa SmartPOS RSA Module, version 1.1, Visa International Service Association, November 2002; and Visa SmartPOS Business Requirements, version 1.1, Visa International Service Association, March 21, 2002. Each of the foregoing listed documents is incoφorated herein by reference in its entirety and for all puφoses.

[0076] Although the foregoing invention has been described in detail by way of illustration and example for puφoses of clarity and understanding, it will be recognized that the above described invention may be embodied in numerous other specific variations and embodiments without departing from the spirit or essential characteristics of the invention. Certain changes and modifications may be practiced, and it is understood that the invention is not to be limited by the foregoing details, but rather is to be defined by the scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A card terminal adapted to facilitate the processing of both magnetic stripe card and smart card transactions for a merchant, the card terminal comprising: a specific environment of at least one magnetic stripe card reading device, at least one smart card reading device, and at least one computing device, said computing device having an operating system originally designed to operate in conjunction with magnetic stripe card transactions but not smart card transactions; a device application module adapted to operate within said specific environment, said device application module being adapted to issue a payment communication when a payment portion of a smart card transaction occurs; a smart card module adapted to receive said payment communication from said device application module and to facilitate the processing of said smart card transaction, said smart card module being operable independently from any particular device in said specific environment; and a first application programming interface adapted to facilitate communication between said device application module and said smart card module.

2. The card terminal of claim 1, wherein said smart card module implements EMV functionality.

3. The card terminal of claim 2, wherein said smart card module comprises source files written in Java computer code.

4. The card terminal of claim 3, wherein said Java source files are integrated into an embedded device platform.

5. The card terminal of claim 4, wherein said embedded device platform comprises GlobalPlatform or STEP.

6. The card terminal of claim 2, wherein said smart card module comprises source files written in C++ computer code.

7. The card terminal of claim 6, wherein said C++ source files are integrated into an embedded device platform.

8. The card terminal of claim 7, wherein said embedded device platform comprises EFT or POS.

9. The card terminal of claim 1, wherein said smart card module is certified by an industry standards organization.

10. The card terminal of claim 9, wherein said industry standards organization is EMVCo.

11. The card terminal of claim 10, further comprising: an environment services access module adapted to enable said operating system to select and activate one or more devices of said environment.

12. The card terminal of claim 11, wherein said operating system is adapted to utilize said environment services access module when a smart card is inserted into said card terminal.

13. The card terminal of claim 11 , further comprising: a second application programming interface adapted to facilitate communication between said environment services access module and said operating system.

14. A method of upgrading an existing magnetic stripe only card terminal to be capable of also processing smart card transactions, the method comprising: selecting a card terminal adapted to facilitate the processing of magnetic stripe card transactions for a merchant, said card terminal including a magnetic stripe card reading device and a computing device having an operating system originally designed to operate in conjunction with magnetic stripe card transactions but not smart card transactions; installing onto said terminal a smart card module adapted to facilitate the processing of a smart card transaction, said smart card module being adapted to operate independently from any particular hardware device on said terminal; and installing onto said terminal at least one application programming interface, wherein said at least one application programming interface is adapted to facilitate communication between said smart card module and said operating system.

15. The method of claim 14, further comprising the step of: installing onto said terminal a smart card reading device.

16. The method of claim 14, wherein said smart card module implements EMV functionality.

17. The method of claim 14, wherein said smart card module comprises source files written in Java computer code.

18. The method of claim 17, wherein said Java source files are integrated into an embedded device platform that comprises GlobalPlatform or STEP.

19. The method of claim 14, wherein said smart card module comprises source files written in C++ computer code.

20. The method of claim 19, wherein said C++ source files are integrated into an embedded device platform that comprises EFT or POS.

21. The method of claim 14, further comprising the step of: certifying said smart card module by an industry standards organization.

22. The method of claim 21 , wherein said industry standards organization is EMVCo.

23. The method of claim 14, further comprising the step of: installing onto said terminal an environment services access module adapted to enable said operating system to select and activate one or more devices of said environment.