PROGRAMMING INTERFACE FOR A SMART CARD KIOSK
This application is a continuation-in-part of U . S . application serial number 08/414,495, filed on March 31 , 1995, which is incorporated by reference herein This application is also related in subject matter to commonly assigned copending application serial no. 08/ , entitled "Stored Value Transaction
System and Method Using Anonymous Account Numbers", filed on the same date herewith.
BACKGROUND OF THE INVENTION 1 Technical Field
This invention relates generally to computer terminals in systems which use smart cards (i.e. , cards having an embedded microprocessor) for various purposes More particularly, the invention provides a kiosk having a set of software services which allows vendors to interact with smaπ cards inserted into the kiosk in order to perform vanous functions
2. Related Information
The use of smart cards to perform vanous types of transactions in systems is well known. For example, some systems provide a way for a cardholder to install a fixed amount of cash equivalent value onto a smart card and to spend the value on Lhe card by inserting the card into any ot various types of devices, such as vending machines. After the value on a card is exhausted, the cardholder may "revalue" the card by inserting it into a machine and then inserting cash, a debit card, or a credit card to transfer additional funds to the smart card.
Providmg computer terminals in various types of systems which allow services to be purchased using smart cards is also well known. However, conventional computer terminals in such systems use proprietary designs which make it difficult, if not impossible, for third party vendors (or "application service providers") to gam access to smart cards inseπed into the terminals. Pan of this problem may stem from the fact that operators of such systems assume that all services will be provided directly by the system operator The system
operator in effect has a monopoly on determining what services will be provided, how they will be provided, and the details of interfaces to the smaπ cards. Thus, a third paπy vendor who wishes to provide a service to cardholders in the system has no easy way to "plug into" the computer terminal to provide such services. Additionally, system operators may use proprietary data storage techniques to install various types of applications and data on smaπ cards which are to be used in the computer terminal, thus making it difficult for third paπy application service providers to gain access to specific infoπnation on the cards. Even assuming that third paπy providers were given access to the cards, there is no way to ensure that each vendor's data could be protected from access or modification by another vendor's application or by the system operator. Thus, vendors might be discouraged from providing their applications in the computer terminal in the absence of security provisions to prevent tampering with their applications or data on the smaπ cards pertaining to their applications. Finally , providing a plurality of different applications for use with a single smaπ card creates a configuration management problem when changes are made to the applications. For example, if a single smaπ card is configured to suppoπ an access control application, a library book check-out application, a cafeteria meal plan application, and a stored value "spend" function which can be used in vending machines and the like, changes to any one of these applications would require that Lhe smaπ card be returned to a common location and the card reconfigured to suppoπ the change. Requiring that a cardholder return to a central location to install the changes causes an inconvenience and lessens the utility of the card. The term "kiosk" will be used herein to refer to a computer-based transaction terminal which provides services to smaπ card users.
SUMMARY OF THE INVENTION
The present invention solves the aforementioned problems by providing a kiosk which provides a variety of application-level services for smaπ card- related applications. In paπicular, the invention provides an interface for vendors to install applications in a kiosk in order to conduct transactions with smaπ card users. The interface includes, in various embodiments and combinations, an operator interface including display and data entry functions, card data access services which can be used independently of the type of smaπ card or file structures used on the cards, stored value functions which can be used independently of the type of smaπ card or file structures used on the cards, and various security and PIN pad functions.
In accordance with the principles of the invention disclosed in parent application serial number 08/414,495, incorporated herein by reference, the smaπ card kiosk can accept different types of smaπ cards and hide those differences from applications which interact with the smaπ cards.
Additionally, the invention provides a kiosk which allows applications and corresponding data structures on a smaπ card to be automatically updated, without the cardholder's knowledge, when the card is inseπed into Lhe kiosk. Such an automatic update function can be used to correct defective applications previously installed on the smaπ card, to add new applications, or to change parameters associated with existing applications. It can also be used to paπially disable certain functions or applications without forcing the cardholder to entirely give up possession of Lhe card.
Finally, the invention provides a kiosk in which various counters and other information maintained on each smaπ card can be automatically extracted and uploaded to a system server each time the smaπ card is used in the kiosk. This automated collection process facilitates statistical analysis in the system server.
The system may be employed on a college campus or at a company-wide location with devices coupled through a local area network or wide area network as suited to the paπicular geography. Various other objects and advantages of the present invention will become apparent through the following detailed description, figures, and the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows a kiosk hardware configuration in accordance with various embodiments of the invention.
FIG. 2 shows one possible software arrangement for providing application-level services in a kiosk in accordance with various principles of the invention.
FIG. 3 shows a series of steps which may be performed to control the operation of applications at a kiosk.
FIG. 4 shows some of the applications which are contemplated as being provided on a kiosk in accordance with the invention.
FIG. 5 shows how personal information may be provided to a cardholder.
FIG. 6 shows a series of steps which may be carried out to revalue a stored value card at a kiosk.
FIG. 7 shows how a merchant ordering application may be provided at a kiosk.
FIG. 8 A and 8B show various pre-specified screen templates which may be used to create information displays at a kiosk. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
FIG. 1 shows a hardware configuration for a kiosk in accordance with various embodiments of the invention. Kiosk 100 may be coupled to a system server 101 over a network 113 such as a LAN or WAN using client-server protocols such as a DCE/Encina protocol for communication between the kiosk 100 and system server 101. System server 101 may in turn be coupled to one or more financial networks 110 to perform financial transactions such as on-line
debits, credit transactions, and funds transfers. Additional kiosks 111 and 112 may also be coupled to system server 101 over network 113, it being understood that the hardware and software descriptions pertaining to kiosk 100 also apply to these other kiosks. A vendor computer 114 may be coupled to system server 101 through any of various means, such as computer networks, modems or the like.
The interaction between these various components is described in more detail herein.
Kiosk 100 includes a computer and memory 102 coupled to various peripheral devices including CD-ROM unit 104, LAN interface 103, a secure access module (SAM) 105, encrypted PIN pad 106, a card reader 107 which may comprise a hybrid card reader able to read smaπ cards which have a magnetic stripe, display unit 108 which may comprise a touch panel display, and a printer 109 which may be used for printing receipts of transactions. The arrangement shown in FIG. 1 is exemplary and is not intended to be limiting. In various embodiments, computer 102 may comprise an Intel-based microprocessor running the Windows™ operating system.
In general, a cardholder inserts a smart card into card reader 107, views various options on display 108 for performing transactions, makes selections based on the displayed information, and obtains a receipt from printer 109. The kiosk may be arranged to perform certain functions without inseπing a smaπ card. For example, informational services may be provided to users without the use of smaπ cards.
The kiosk 100 in FIG. 1 is illustrated as being equipped with peripherals which are suitable for a "stand-alone" configuration, such as might be placed in a shopping mall, a public place on a college campus, or a similar setting.
However, a variation of kiosk 100 is also contemplated for a "private" setting such as for use in a person's home. This variation, while still generally configured as shown in FIG. 1, is preferably configured to operate on a PC-type home computer and may omit certain peripherals such as PIN pad 106, and may
use a regular CRT type display instead of a touch panel display.
Each kiosk may be configured with applications which allow users (including smaπ card holders) to conveniently retrieve information, and to order and pay for goods and services. For example, for a college campus setting, the kiosk may provide an application which displays the daily or weekly menu for cafeterias on the campus. As another example, the kiosk may provide an application which allows a card holding student to design and order copies of a resume which are then printed at a print shop for later delivery or pick-up. The latter could be done from the convenience of the student's PC configured as a kiosk in accordance with the principles of the invention. Other applications and features are described in more detail herein.
FIG. 2 shows one possible software arrangement for providing application-level services in a kiosk in accordance with various principles of the invention. It is contemplated that the software features and structure shown in FIG. 2 is installed and operating on kiosk 100 shown in FIG. 1. As shown in
FIG. 2, a set of kiosk applications 200 is provided on top of a plurality of application level kiosk services 201 through 207. These application level services may include, in various embodiments, an operator interface 201, kiosk server 202, card data access functions 203, stored value functions 204, security functions 205, PIN pad functions 206, and automatic update functions 207.
Operator interface 201 preferably provides a set of windowing functions, an "attract" screen which operates when the kiosk is idle, a set of standard templates which can be used by vendors to design an operator interface suitable for a paπicular application, and an order selection and accumulation function for compiling order information for applications which sell goods or services.
Operator interface 201 preferably hides implementation details of display 209, such that vendors developing kiosk applications need only make function calls to services in operator interface 201. The encapsulation and abstractions provided by operator interface 201 thus simplify and standardize the task of creating
vendor applications which operate harmoniously on kiosk 100.
Kiosk server 202 includes, in various embodiments, internal message routing functions for transmitting data among applications, and a kiosk control function for scheduling applications based on menu selections made by a user/cardholder.
Card data access functions 203 includes a set of functions which may be used to retrieve, modify and store data contained on a smaπ card which has been inseπed into smaπ card reader 210. Stored value functions 204 preferably include a group of functions which allow stored value on a smaπ card to be decremented or incremented as pan of a devalue or revalue transaction.
Additionally, a smaπ card application programming interface (SCRAPI) 208 preferably provides a means of isolating differences among different types of smaπ cards from kiosk applications, as disclosed in parent application serial number 08/414,495. For example, one type of smaπ card may directly provide purse manipulation functions, while another vendor's smaπ card may not. One feature of SCRAPI 208 is thus to hide such differences from kiosk applications 200 so that each vendor need not be aware of the various types of smaπ cards used in the kiosk.
A group of security functions 205 is preferably included to allow various kiosk applications to perform authentication, encryption/decryption, and other related functions in conjunction with smaπ cards used in the kiosk. In various embodiments, such functions may be provided by a secure access module (SAM) 211 which may be implemented in hardware or software. Security functions 205 preferably isolate kiosk applications 200 from specific implementation details of SAM 211. In general, where a stored value card is used, a kiosk-to-card authentication process occurs using security functions 205. The authentication of a smaπ card using derived keys is well known and thus not explained in detail here.
A group of PIN pad functions 206 is included in various embodiments to allow kiosk applications to interface with an encrypted pin pad 212.
Finally, a set of automatic update functions 207 is included in various embodiments to automatically collect information from smart cards inserted into the kiosk, to automatically enable or disable functions on smart cards used in the kiosk, and to automatically update code and data in the kiosk.
FIG. 3 shows a series of steps which may be performed in kiosk 100 in accordance with the software shown in FIG. 2. Beginning in step 301 , an "attract" screen is displayed on display 209 during an idle state. This screen may comprise a "screen saver" type of image which moves across display 209 and serves to entice passersby to use the kiosk. For a college campus setting, the "attract" screen may include a campus logo or other type of image tailored to the particular campus. For a company-wide location, the image may comprise a company logo or a safety reminder, for example. In step 302, a test is made to determine whether any users are present, as might be determined by the pressing of a button or a touch-screen display, by detecting that a user has inseπed a card, or by the output of a motion detector. If no users are present, then in step 303 a test is made to determine whether any remote updates from system server 101 need to be made. Examples of such updates include changing the daily menu for a campus cafeteria, installing new applications, or downloading other information used by various applications on Lhe kiosk. One of ordinary skill in the an will recognize that rather than "polling" the server to determine whether any such updates are available, such updates may be automatically initiated by system server 101. The updates may preferably be made in two stages: a first stage in which files are downloaded from the server, and a second stage in which the downloaded infoπnation is installed as the operative configuration in the kiosk. In various embodiments, a Remote Code Update (RCU) software utility available from Tivoli, Inc. may be used to install code and data changes.
Although the data download stage may be performed concurrently with the execution of various applications at the kiosk, the installation stage is preferably performed while the kiosk is disabled to prevent users from attempting to use the kiosk. Accordingly, after data and/or code is downloaded from server 101 , in step 304 the display is preferably locked out (assuming that it is not currently in use) to prevent users from accessing the applications. In step 305, the changes to code and/υr data are installed in the kiosk, then in step 306 the display is unlocked to allow users to again use the kiosk.
In step 307, assuming that a user is present and no updates are currently in progress, a main menu is displayed on display 108 preferably under the control of kiosk server 202. The customer makes a selection from Lhe menu, which may comprise any of various applications such as those shown in FIG. 4.
Applications on kiosk 100 may be generally classified into one of two types: free applications for which no payment is necessary and no card is required, and payment applications, for which the user must provide payment in the form of a stored value debit, an on-line bank debit, or a credit card transaction. Assuming that the customer has selected an application for which payment is necessary, then in step 308 the customer is prompted to inseπ his smaπ card, which may comprise a GEMPLUS MPCOS™ card for example. In step 309, kiosk 100 automatically extracts counters from the inseπed card under the control of automatic update functions 207 and transmits them to server 101 for statistical purposes. Examples of counters which may be extracted from the inseπed card include the following:
- number of transactions for which the card has been used - number, time, location, etc. of access control readers, such as parking garages or door locks in which the card has been used
- number of library transactions for which the card has been used
- number of meal plan transactions for which the card has been used
In step 310, a check is made based on information received from server 101 as to whether any updates need to be made to the card. Such updates can include the installation of new applications (for example, adding a meal plan to the card, or adding library privileges), modification of existing applications (for example, changing the meal plan a student is entitled to use), or deletion/disabling of existing applications (for example, revoking library or parking privileges). As another example, if a cardholder loses his card and repoπs its loss, system server 101 can disable the card the first time it is inserted into a kiosk durinς an attempted use by a finder of the card. In step 311 , if any such changes are needed, the changes can be installed directly on the card without the cardholder's intervention. As one example, a student's parking privileges may be revoked, and the student directly notified on the kiosk display, without disabling the entire smart card. In some situations, it may of course be desirable to confirm with the cardholder that an update is to be made before it occurs. In any event, updates made to the smaπ card 311 are preferably controlled from central server 101 such that the server maintains an inventory of the services and features which are available to the cardholder. Updates may be made by deleting a file on the card or setting a flag contained in a file on the card. Various variations are of course possible, and the invention is not intended to be limiting in this respect.
In step 310, if no card updates are pending, then in step 312 the application selected by Lhe user is executed. The selected application may comprise any of those shown in FIG. 4, or others as suitable for the particular kiosk. Also, after changes are installed on the card in step 311, the selected application is executed in step 312 (assuming that the particular application has not been disabled). After the cardholder finishes using any desired application, his card is ejected and the kiosk returns to an idle state in which the attract screen is displayed (step 301). The card may remain in the kiosk while the cardholder uses multiple applications.
FIG. 4 illustrates some of the many applications which are contemplated as being provided on kiosk 100. General information applications 401 may be provided at kiosk 100 without the need to insert a card into card reader 107. General information applications include maps of a campus or company location, menus for a cafeteria or restaurant updated daily or weekly, schedules of various events such as sporting events and library hours, advertisements for various types of products or services, or club information. In various embodiments, the information needed to display the information depicted may be stored in computer memory 102 (which may include RAM, ROM, and/or disk) or CD- ROM unit 104 (see FIG. 1). Changes to the information provided by these applications may be made via automatic update functions 207 (see FIG. 2). Generally speaking, general information applications display information selected by a user from touch screen display 108. One of ordinary skill in the an will recognize how to construct such information displays using information stored within kiosk 100. In various embodiments, the information may be provided through a set of window functions such as are provided by the Microsoft Windows™ operating system. Additional functions may be provided to augment basic windowing functions provided by the operating system, and templates (see below) may be used to provide a limited set of "standard" display formats. Personal information applications 402 allow a cardholder to access personal information stored on a smaπ card or maintained in system server 101. It is generally contemplated that a cardholder needs to supply a PIN in order to access information such as the cardholder's name/address and other information, the status of various functions active on the card (such as displaying the meal plan currently active), grades, or the status of various financial accounts maintained in system server 101 or other computers.
FIG. 5 shows how personal information may be provided to a cardholder. Beginning in step 501, the user is prompted to enter his PIN which was previously assigned. In step 502, the user's PIN is verified, preferably using a
PIN checking function on the card through the use of security functions 205 (see FIG. 2). Assuming that the PIN was correctly entered, in step 503 a determination is made as to whether the information is of a type stored on the smaπ card. If not, then in step 504 a request is made to server 101 to supply the requested information. If the information is stored on the card (such as a list of card functions and their status), then in step 505 the information is extracted from the smaπ card, preferably using card data access functions 203 (FIG. 2). In step 506, the information obtained either from the card or from server 101 is displayed to the user on display 108. It will be recognized that certain applications, such as the display of a student's grades, may be limited to a
"private" kiosk on a student's home PC rather than at a public kiosk where sensitive information might be inadveπently displayed for others to see.
Revalue card applications 403 provide a cardholder with the ability to add stored value to an inserted smart card using either an on-line bank debit transaction, an on-line credit card transaction, or inseπing cash. FIG. 6 shows a series of steps which may be carried out to revalue a stored value card at kiosk 100. Beginning in step 601, the user selects a payment type (i.e. , debit, credit, or cash). In step 602, if it is determined that a debit payment is to be conducted, then in step 603 the user is prompted for his personal bank PIN (not to be confused with PINs used to authenticate the user with respect to the stored value card itself), and in step 604 an on-line bank debit transaction is initiated from system server 101 and the user's private bank account through financial network 110. This step may include steps of extracting the user's bank account information from a magnetic stripe on the stored value card, combining it with the user's PIN (which may be provided in encrypted form via PIN pad 106 and extracted via PIN pad functions 206), and forwarding the request to system server 101 to initiate the bank transfer operation. Alternatively, the kiosk may be provided with a separate magnetic card reader which accepts the user's bank debit card to supply this information. Bank transfers may be carried out through
any of various banking services, such as those provided by Gensar, a company which provides such services in certain regions of the country
If, in step 605 it is determined that credit payment is desired, then in step 606 a bank credit transaction is initiated, preferably using credit card account information obtained either from a magnetic stripe on the user's stored value card, or from a separate credit card inseπed by the user into a magnetic stripe reader (it will be appreciated that the same hybrid reader can be used for both card types). In either event, a credit transaction is initiated from system server 101 through financial network 110 or other bank-to-bank protocols to obtain a credit authorization.
Finally, if neither debit nor credit payment has been selected, in step 607 cash may be used to revalue the card. This step involves the user's inseπion of bills into a bill acceptor (not shown) to accept the money
In step 608, the value on the stored value card is updated to reflect the payment made by the user. In various embodiments, this transaction is conducted on-line with system server 101 using an anonymous account number which cannot be traced to the pamcular cardholder (see copending application serial number 08/ ). Finally, m step 609, a receipt is generated using printer 109 (see FIG. 1). Referring again to FIG. 4, card balance and transactions application 404 will be described. Upon inseπion of a stored value card, a cardholder may immediately view the card's balance on display 108. This feature preferably includes the step of using stored value functions 204 (see FIG. 2) to retrieve the card's balance while hiding details of the stored value function implementation on the pamcular card. Additionally, the cardholder may view the last 10 or so transactions stored on the card upon entry of a PIN which is verified locally with the stored value card, preferably through the use of security functions 205 (see FIG. 2).
Merchant ordering applications 405 may include any of various types of applications which require payment by a user. For example, a user may order food such as pizzas, order goods from one or more catalogs the contents of which are accessible at kiosk 100, order books, or order items such as clothing from advertisements or other displayable images on kiosk 100.
In various embodiments, merchants may be provided with software services such as these shown in FIG. 2 in order to design applications which arc executed on kiosk 100. For example, as described in more detail below, a set of standard templates may be used to create pre-defined images for presenting options to the user, making item selections, and for accumulating order totals and the like. Providing a limited set of such standard templates enhances commonality among applications provided at the kiosk and simplifies the task of developing kiosk-based applications.
FIG. 7 shows how a generic merchant ordering application may be provided at kiosk 100. In step 701 , the user inserts his stored value card (or bank debit card, or credit card) into card reader 107. In step 702, a merchant menu display is provided under the control of kiosk server 202; the menu contains items defined by the particular merchant. For example, a pizza merchant might provide a display of different pizza sizes and toppings, while a catalog merchant might provide an opening display of a catalog page with options for paging through the catalog or performing a keyword search in the catalog. In step 703, the customer selects the particular product or service from the display. In step 704, if the customer's payment is to be from the stored value card itself, then in step 705 the value on the card is decremented according to the order total. In step 706, a record of the stored value transaction is stored in kiosk 100 in a memory area, and in step 707 the specific merchant's merchandise is authorized (for example, an order can be placed in vendor computer 114 from system server 101). Payment to the vendor may be effected during a settlement process as described more fully in copending application serial number
08/ .
On the other hand, if the customer chooses to use a debit transaction as payment (step 708), then in step 709 the customer is prompted to enter his bank PIN, and in step 710 an on-line bank debit operation is performed in a manner similar to that shown and described with reference to FIG. 6. After the debit transaction is successfully performed, in step 707 the merchant's order for goods or services is authorized, again preferably by communicating with vendor computer 114. It will be appreciated that many different vendor computers may be provided in communication with system server 101. If in step 711 it is determined that payment will be made using a credit transaction, then in step 712 an on-line credit transaction is performed using steps similar to those described with reference to FIG. 6. Finally, in step 707 the specific merchant's transaction is authorized.
Referring again to FIG. 4, a group of content delivery applications 406 may also be provided on kiosk 100. In general, these may comprise the sale of information using payment mechanisms shown in FIG. 7 with reference to merchant ordering applications. Content delivery applications may include ordering excerpts from various books (including the payment of applicable copyright royalty clearance fees) or performing on-line research using databases which require payment for searches.
Finally, on-demand printing applications 407 may be provided at kiosk 100. These services can include the formatting and content generation for resumes, papers (such as a thesis or book), or business cards. The payment mechanisms for these applications may be effected in the same manner as merchant ordering applications discussed above. However, for these applications the user may be required to provide substantially more infoπnation. For example, a draft copy of a resume in word processor format may be required. For resumes and business cards and the like, the user may be prompted to select from a variety of styles and print quantities. In effect, these services are
analogous to an on-line print shop. However, they can be provided cheaply and effectively from a smart card kiosk either at a public location or at a private kiosk in a student's home computer.
FIGs. 8A and 8B show various pre-specified screen templates which may be used to create information displays at kiosk 100. Screen template 800, for example, may be used for displaying a simple image, while screen template 802 may be used for displaying a "rich text file" next to an image on the same screen. These predefined screen templates may be provided as part of operator interface 201 to allow various merchants and application developers to gain provide applications at kiosk 100.
In various embodiments, it may be desirable to use separate encryption decryption keys for accessing data stored on each smart card. For example, a first key may be used for performing card value/devalue operations; a second key may be used for a second application, a third key may be used for a third application, and so forth. In this manner, data accessed on each card can be maintained with a higher degree of security, in that the compromise of a single key affecting a single application would not necessarily compromise other applications on the card.
What has been described is a kiosk including a set of application level services which provides a convenient way of paying for and ordering various types of goods and services, and for obtaining information relevant to a particular kiosk location. The kiosk may automatically extract usage information from cards used in the kiosk and provide this information to a system server for statistical analysis. Additionally, code and data in the kiosk may be updated from the system server, and functions and data on each cardholder's smaπ card may be updated automatically without the user's intervention when the card is inseπed into a kiosk.
It is apparent that many modifications and variations of the present invention are possible, and references to specific values or product are by way
of example only. The method steps of the invention may be practiced in a different ordered sequence from that illustrated without departing from the scope of the invention. It is, therefore, to be understood that within the scope of the appended claims the invention may be practiced otherwise than as specifically described.