GB2350703A

GB2350703A - Smart devices

Info

Publication number: GB2350703A
Application number: GB9912695A
Authority: GB
Inventors: Michael George Coutts
Original assignee: NCR International Inc
Current assignee: NCR International Inc
Priority date: 1999-06-02
Filing date: 1999-06-02
Publication date: 2000-12-06
Also published as: GB9912695D0

Abstract

A Smart device (100) for hosting a plurality of applications comprises processing means (102) and storage means (104), and also includes a directory for storing file information (base file number, file name, data type and file length) relating to hosted applications and a device application for supplying the file information to a device reader. A file allocation table (FAT) maps file numbers to physical addresses, each entry in the table having file number, file size and physical address.

Description

2350703 8418 SMART DEVICES The present invention relates to Smart devices.

In particular, the invention relates to Smart devices for hosting a plurality of applications.

Smart devices are portable, hardware items comprising a microprocessor and associated storage. Smart devices typically provide secure, tamperresistant, information storage and processing. One type of Smart device is a Smart ring, another type is a Smart button, yet another type is a Smart card.

Conventionally, a Smart card comprises a microprocessor and associated memory embedded in a thin plastics card. Smart cards store information in the form of files, and the cardholder uses the Smart card for accessing services provided by a Smart card terminal. A Smart card terminal has at least one client application and a Smart card reader for enabling a client application to send commands to and receive responses from a Smart card. A client application running on a Smart card terminal communicates with the card reader which implements a standard protocol (typically the ISO 7816 protocol) for communicating with a Smart card.

Typical terminals which communicate with Smart cards include self-service terminals such as automated teller machines (ATMs), telephone kiosks, ticket issuing terminals, and such like; other terminals which communicate with Smart cards include GSM digital cellular telephones, television set-top boxes, and such like.

Each service provider (for example, a financial institution operating an ATM, a communications company operating a telephone kiosk) may store files on a Smart card in a format unique to that service provider.

A Smart card does not have an advanced operating system: it references each file with a file number, where each file number comprises four ASCII digits. A file allocation table is used to map a file number to the associated physical memory address. It is not possible for a client application to interrogate a Smart card to locate files (that is, to obtain the file numbers of files) which may be relevant to that client application. Therefore, a client application must know the location (file number) and format of those files which are stored on a Smart card and associated with that client application; any Smart card which does not have files in the correct format and at the correct predetermined location will be rejected as invalid by a client application.

Advanced Smart cards also allow an executable file to be downloaded from a client application and stored on the Smart card as a card application. At a later time, a client application can instruct the Smart card to execute the card application. A Smart card executing a card application received from a client application is referred to herein as a Smart card hosting an application. This feature may be used to increase security because the card application can protect access to files that are stored on the card, such as the cardholder's account number.

To avoid a user having to carry multiple Smart cards (one for use with each client application) it is desirable to use a single Smart card for hosting a plurality of different applications from different service providers. For example, a single Smart card may host a loyalty card application for a supermarket, a credit card application for a credit authority, and a bank account application for a bank. A block diagram of a prior art advanced Smart card for hosting two different applications is shown in Fig 1.

Fig 1 (prior art) shows an advanced Smart card 10 having a processor 12 and an associated non-volatile memory 14. On power-up, the processor executes an application in memory 14 that is referenced by a default pointer in memory 14. For some Smart cards, the default application is referenced by file number '3F001 16. Memory 14 comprises a large number of memory locations (for example eight thousand), eight blocks of these locations are shown in Fig 1.

Two additional applications (card applications) are also stored in memory 14, but these applications can only be executed if the default application passes control to them.

The first card application is a loyalty card application and is resident in a 100 byte block of memory locations 18 where the block is referenced by file number '10001. This loyalty card application has two associated data files, each file occupying 100 bytes of memory. The data files occupy blocks of memory 20, 22 referenced by file numbers '10011 and '10021 respectively.

The second card application is a bank account application and is resident in a 100 byte block of memory locations 24 referenced by file number '20001. The bank account application also has two associated data files, each file occupying a 100 byte block of memory 26,28, but these files are referenced by file numbers '20011 and -20021 respectively.

m emory 14 includes a file allocation table (FAT) 30 having an entry for each file in memory 14. Each entry contains a file number, a file length, and a physical memory address at which the file is located.

The default application provides a subset of the ISO 7816 standard and allows the Smart card file system (that is, all of the storage locations that are referenced by file numbers, such as '10001, '10011, ^20001, and such like) to be exposed to client applications. Client applications use the default application to read files from the Smart card 10, write files to the Smart card 10, and execute card application files (card applications) resident on the Smart card 10.

Card applications are executed by the client application sending the file number of the card application together with an execute command.

When a user inserts the Smart card 10 into a loyalty card terminal having a client application associatdd with the loyalty card application resident at location '10001, then the client application instructs the Smart card 10 to execute the card application located at file number - looo,. it will be appreciated that the terminal is preprogrammed to expect the Smart card 10 to have a loyalty card application at file number -10001. If the loyalty card application is not located at '10001 then an invalid card error is generated by the terminal.

one disadvantage of using a single card for hosting multiple applications is that each client application must know the file number of a relevant file on a Smart card prior to the card being used because it is not currently possible for a client application to view the type and location of files on a Smart card to identify files suitable for use with the client application.

Another disadvantage is that there is limited storage available in a Smart card, so it is not practical to allow each card application to have a different set of predetermined file numbers; that is, it is not practical to assign a unique set of file numbers to each card application and associated data files (for example '10001, '10011, '10021 in Fig 1) so that a card application is always located at the same storage location on every Smart card.

It is an object of an embodiment of the invention to obviate or mitigate one or more of the above disadvantages.

According to a first aspect of the present invention there is provided a Smart device for hosting a plurality of applications, the device comprising processing means and storage means, characterised in that the device includes a directory for storing file information relating to hosted applications and a device application for supplying the file information to a device reader.

By virtue of the invention, a Smart device is operable to provide a device reader (such as a card reader) with the location and format of files stored on the device so that a client application is able to identify any relevant files on the device. one advantage of this is that a client application does not require any prior knowledge of the files stored on a Smart device because the Smart device provides the client application with this information. Thus, knowledge of the contents of a Smart device is stored in a directory on the device itself. This also means that a Smart device may store files using any convenient file number, rather than being constrained to predetermined file numbers.

Another advantage in avoiding predetermined file numbers is that there is no possibility of two different client applications requiring identical predetermined file numbers. If two client applications required to store applications using identical file numbers then this would ensure that both client applications could not use the same Smart device.

Preferably, the device application is operable to supply file information in response to a query from a client application.

Preferably, the device application is operable to supply the number and the identity of the applications that are resident on and executable by the Smart device.

Preferably, the Smart device is a Smart card.

Preferably, the directory is stored in a predetermined location in the storage means. Conveniently, the directory is stored as a look-up table. Alternatively, the directory may be stored using a predetermined file number.

According to a second aspect of the invention there is provided a method of hosting a plurality of applications on a Smart device, where the applications are stored at non-predetermined file numbers, characterised by the steps of storing file information relating to the hosted applications, supplying the file information to a device reader so that the device reader can identify any relevant files on the device, and executing any application called by the device reader.

Preferably, the file information is supplied in response to a request from the device reader.

According to a third aspect of the invention there is provided a Smart device system characterised by the Smart device of the first aspect of the invention and a Smart device terminal incorporating a Smart device reader.

According to a fourth aspect of the invention there is provided a Smart device terminal for instructing execution of an application stored on a Smart device and referenced by a non-predetermined file number, where the terminal includes a client application operable to interrogate a Smart device for obtaining information about the location and type of any files stored on that Smart device.

It should be appreciated that the words 'nonpredetermined file number' are used to indicate that the application may be referenced by any convenient file number.

Fig 1 shows a block diagram of a prior art advanced Smart card for hosting two different applications.

Embodiments of the present invention will now be described, by way of example, with reference to the rest of the accompanying drawings, in which:

Fig 2 is a block diagram of a Smart device in accordance with an embodiment of the invention; Fig 3 is a block diagram of the contents of the memory of the Smart device of Fig 2, when the device is loaded with two card applications; Fig 4 is a block diagram of a Smart device system according to another embodiment of the invention, where the system includes the Smart device of Fig 2; Fig 5 is a flowchart indicating the steps involved in installing a card application on the Smart device of Fig 2; Fig 6 is a table illustrating the structure of part of the memory of the Smart device of Fig 2; and Fig 7 is a flowchart indicating the steps involved in a Smart device hosting an application; Fig 8 is JAVA source code for the device application used in the Smart device of Fig 2; Fig 9 is JAVA source code for one of the card applications used in the Smart device of Fig 2; and Fig 10 is JAVA source code for the other card application used in the Smart device of Fig 2.

Referring to Figs 2 and 3, a personal Smart device 100 in the form of a Smart card has processing means 102 in the form of an 8-bit processor and associated storage means 104 in the form of non-volatile EEPROM. The Smart card 100 also has ROM 106 and RAM 108.

In this embodiment, the Smart card 100 is a Cyberflex (trade mark) 2.0 Multi 8K JAVA (trade mark) card which is available from 'Schlumberger Smart Cards and Systems', 1601 Schlumberger Drive, Moorestown, NJ 08057, U.S.A.

As is known to those of skill in the art, a Cyberflex (trade mark) card has three software layers.

The first layer is a general purpose operating system (GPOS) which implements the ISO 7816 standard and is stored partly in ROM 106 and partly in memory 104.

The operating system also provides message management, file management, security management, and utility tools for the Smart card 100.

The second layer is a JAVA virtual machine (JVM) interpreter, which is also stored in ROM 106.

The third layer is configurable by the user and may comprise one or more applications in the JAVA programming language and/or one or more data files: the one or more applications and/or one or more data files are stored in the non-volatile memory 104. The JVM translates JAVA bytecodes from JAVA applications (part of the third layer) into instructions the processor 102 can understand and process.

Memory 104 has eight thousand locations, each location being able to store one byte of data.

Initially, card 100 has a device application 110 (Fig 3) which is stored in a block of memory 112 referenced by file number '3FOO' (Fig 2). Memory 104 also has a file allocation table (FAT) 113 for mapping file numbers to addresses in the physical memory 104. Each entry in the FAT 113 has a file number, the size of the file, and the physical address of the file.

The device application 110 performs a number of functions. Application 110 implements the ISO 7816 standard to enable the card 100 to communicate with a card reader. Application 110 also performs an application management function whereby it allocates file numbers to files and it maintains a record (directory) 114 of the type and the size of file stored at each file number location.

It will be appreciated that a file number refers to a file rather than to a pre-set amount of memory. For example, one file number may relate to a 100byte long file; whereas, another file number may relate to a 10byte long file.

The application 110 stores the record 114 of the type and size of files in an area of memory 104 that it reserves for this purpose. This reserved area of memory is referred to herein as the directory area 116 (Fig 2). The directory area 116 may be located at any convenient physical memory location, for example, the first hundred memory locations in memory 104, but directory area 116 has a predetermined file number, for example 'OFOO'.

To enable the card 100 to host a new application, the cardholder takes the card 100 to a terminal offering enrolment for a service of interest to the cardholder. For example, if the cardholder desires to join a loyalty card scheme operated by supermarket XYZ, then the cardholder would take his/her card to an enrolment terminal providing membership of the loyalty card scheme for supermarket XYZ.

Fig 4 is a simplified block diagram of a Smart device system 118 comprising a self-service enrolment terminal 120 in communication with a Smart card 100. The terminal 120 offers enrolment for two different services, each service having an associated client application installer 122, 124. The first client application installer 122 is for installing the loyalty card scheme for supermarket XYZ (hereinafter referred to as the loyalty installer); the second client application installer 124 is for operating a bank account for bank CDE (hereinafter referred to as the bank account installer).

Terminal 120 also has a card reader interface 126 and a card reader 128. It will be appreciated that terminal 120 has other standard features of a selfservice terminal, such as a display, keypad (which may be encrypting), terminal controller, and such like modules and features, which are well known in the art and which are not shown here in the interest of clarity.

The card reader interface 126 enables applications resident on the terminal 120 to communicate with card reader 128. Card reader 128 is operable to communicate with a Smart card 100 in accordance with the ISO 7816 standard. Suitable card reader interfaces 126 and card readers 128 are well known and are available commercially, for example from Microsoft (trade mark).

Card reader 128 may be a contact or a contact-less card reader, depending on whether a contact or noncontact Smart card is used. In this embodiment, a Cyberflex card is used, which requires physical coupling between a contact on one side of the card 100 and the card reader 128.

1 here are three types of application resident on the terminal. The first type of application is a terminal control application 130 for controlling the operation of the terminal itself, for example the display, the keypad, the card reader 128, and such like. This type of appltation is well known in the art and will not be described herein. The second type of application is a client application installer 122,124, and is able to install a card application onto a Smart card. The third type of application is a service application 132, 134. Service applications 132, 134 can instruct card applications to execute and can provide card applications with information necessary for them to execute. However, service applications 132, 134 require a suitable card application to have been installed on a Smart card, they are not able to install a card application (that is, they are not able or not authorised to enrol a new user).

In some embodiments, a single application may be used to provide the functions of the second type (client application installer) 122,124 and the third type (service application) 132, 134 of application. Combining the two types of application minimises the number of applications stored on a terminal and reduces unnecessary code duplication. However, depending on the particular service provided, it may be desirable to limit the number of terminals that are able to enrol new cardholders, so there may be, for example, ten terminals having a service application 132, 134 for every terminal having a client application installer 122, 124.

To enrol for the loyalty card scheme, the cardholder inserts his/her card 100 into reader 128, and selects the option of enrolling for the loyalty card scheme via the keypad (not shown) on the terminal 120. In response to this selection, the terminal controller (not shown) instructs the loyalty installer 122 to install a card application on the inserted card 100.

Installation of a card application involves the following process, as illustrated by the flowchart in Fig 5. The loyalty installer 122 requests the device application 110 (Fig 3) for the necessary storage space on the card 100 (step 150). This request includes the total number of files required and the storage space required for each file. For the loyalty card scheme, three files are required: one file for the loyalty card application 170 (Fig 3), and two files 172, 174 for storing data for use by the card application 170. As the storage allocation is fixed at this stage, the loyalty installer 122 requests more space for data files 172, 174 than is initially needed to allow more data to be added over time.

The installer 122 requests three files, the first being 200 bytes long and for the loyalty card application 170, each of the other two being 100 bytes long and for use as data files 172, 174. Thus, 400 bytes of sequential storage space are required.

The device application 110 (in particular, the management function of this application) accesses the FAT 113 (Fig 2) to determine whether the space (400 bytes) is available in the card 100 (step 152).

If the space is not available then the application 110 sends an 'insufficient space, message to the card -12 reader 128 (step 154).

If sufficient space is available, then the device application 110 allocates the requested space (400 bytes) to the three files to be supplied by the loyalty installer 122 (step 156). The application 110 allocates space by providing the loyalty installer with a base file number, in this embodiment '20001.

The device application 110 updates (step 158) the FAT 113 (Fig 2) by entering the base file number ('20001), the physical address in memory 104 corresponding to this file number, and the length of the file (200bytes).

The loyalty installer 122 writes (step 160) the card application to the base file number. The base file number is also the file number from which associated data files are referenced.

When the loyalty installer 122 writes the card application at the base file number, the installer 122 provides the device application 110 with a name ('LOYALTY_X=) for the card application (step 162).

The device application 110 records the name of the card application ('LOYALTY - XYZI) in the directory 114 stored at directory area 116 (Fig 2) together with the base file number ('20001) for the application (step 164). The device application 110 also stores the data file type information in the directory 114. This is illustrated in Fig 6, which shows the structure of the directory 114.

Directory 114 has four columns for each file: the first column 200 indicating the file number for that file, the second column 202 indicating the file name, the third column 204 the data type, the fourth column 206 the file length.

The entry for the loyalty card application 170 is shown in row 208 (Fig 6), and the entries for the data files 172 and 174 are shown in rows 210 and 212 -13respectively.

The device application 110 then executes the card application 170 (Fig 3) written to the base file number (step 166). This is done so that the card application 170 (Fig 3) can create the data files it requires (step 168). These date files are created and stored at locations relative to the base file number (-20001). The number of data files and the storage space available to the data files is limited to that which was originally allocated by the device application 110 in step 156 (Fig 6).

In this embodiment, the loyalty card application 170 creates two data files 172, 174 each being 100 bytes long. The first data file 172 is used to store data for identifying the cardholder and also the cardholder's loyalty account details. The second data file 174 is used to store the actual account details, that is, how many loyalty points the cardholder has, when and where these points were accrued, and such like information.

once the card application 170 has executed and the data files 172, 174 have beehcreated, the cardholder may then remove the card 100. The Smart card 100 memory, as shown in Fig 2, now has a directory 114 at directory area 116, and three files occupying memory locations referenced by file numbers '20001 to '20021, shown by block 220.

When the cardholder wishes to use the loyalty card scheme, for example to add loyalty points to the Smart card 100, then the cardholder takes the card to an appropriate terminal; that is, a terminal providing loyalty card services for supermarket XYZ, for example, terminal 120. Once at the terminal, the cardholder inserts the card 100 into the card reader. The sequence of steps performed is illustrated in Fig 7. When the card is inserted (step 300), a loyalty service application 132 uses the ISO 7816 standard to request the Smart card 100 to provide directory information (step 302).

The device application 110 on Smart card 100 responds by supplying the service application 132 with the information contained in the directory 114 (that is, the information contained in row 208).

The service application 132 analyses this information (step 304) to determine if there is a card application with the name -LOYALTY - XYZ' (step 30G). When the service application 132 discovers the card application called -LOYALTY - XYZI it records (step 308) the file number for this card application (-20001).

If no card application called -LOYALTY-XYZI was resident on the card 100, then the service application 132 would inform the cardholder that the loyalty service was not available because the loyalty card application is not installed on the card 100 (step 310). If the terminal 120 has a client application installer 122 then the terminal 120 may ask the cardholder if he/she wishes to enrol for the loyalty card service.

Once the 'LOYALTY XYZ' file is discovered, the service application 132 instructs the Smart card 100 to execute the loyalty card application 170 (Fig 3) located at file number '20001 (step 312) using an extension of the ISO 7816 standard.

on receiving a command to execute a card application at a certain file number (e.g. '20001), the device application 110 sets a default pointer (step 314) in memory 104 to point to the memory location referenced by that file number (i.e. '20001). The device application 110 then resets (step 31G) the Smart card 100. when the Smart card 100 powers up it executes the card application referenced by the new default pointer (i.e. the card application referenced by file number '20001).

The application referenced by the new default pointer resets (step 320) the default pointer to the original value (i.e. -3F001) so that if the Smart card 100 is unexpectedly removed from the card reader 128, the device application 110 is executed on power-up rather than a card application.

Card application 170 continues executing (ste 322) and interacts with the loyalty service application 132 as necessary to provide features and functions relating to the loyalty card scheme. Card application 170 may perform some processing on behalf of the service application 132: for example, card application 170 may store and operate on all secure data and provide service application 132 with the results of the operation.

Before the loyalty service application 132 can access any information within data files 172,174, the service application 132 must supply the card application 170 with a correct authorisation mandate.

An authorisation mandate is a security feature that is embedded in the loyalty card application 170. The security feature may be a password such as an eight digit ASCII key. Any client application that attempts to instruct the loyalty card application 170 must provide the application 170 with the correct authorisation mandate, otherwise the card application 170 will ignore the instructions. As only the card application 170 can access (to read from, write to, or delete) the associated data files 172,174, this prohibits access to any client application that cannot provide the correct authorisation mandate.

When the card application 170 is executing, the instructions conveyed between the service application 132 and the card application 170 must conform to the ISO 7816 transfer protocol, but the instructions conveyed may be different to those used in the ISO 7816 standard. This is because card application 170 is controlling the Smart card 100, and not device application 110.

When the cardholder has finished adding or redeeming loyalty points, then he/she removes the Smart card 100 from the terminal 170. When Smart card 100 is next powered up, the default application will be the device application 110 because the default pointer was reset by the card application 170.

If the cardholder wishes to add another card application (for example, a bank account card application for bank CDE) to the Smart card 100, then he/she inserts the card 100 into a terminal 120 having a client installer application 124 for bank CDE, and the steps described with reference to Fig 5 are repeated.

The bank account installer 124 requests space on the Smart card (step 150) for four files: the first being the application file 180 (Fig 3), which is 200 bytes long; the next being a directory file 182, which is 100 bytes long; and the other two 184,186 being data files, each of which is 100 bytes long. Directory file 182 stores directory data for use by the bank account card application 180 and is not the same as the directory 114 which stores information relating to the entire Smart card 100.

The device application 110 determines that there is 500 bytes ofsecluential storage space available (step 152), and allocates 500 bytes starting at file number '30001 (step 156).

The bank account installer 124 updates the FAT 113 (step 158) and writes (step 160) a bank account card application 180 (Fig 3) to the block of memory referenced by file number '30001. The installer 124 also supplies the name ('BANK_CDEI) for the card application 180 (step 162).

The device application 110 records (step 164) the name of the card application ('BANK - CDEI) as an entry 230 in the directory 114 together with the base file number 30001, the file type, and the file size, as shown in Fig 6.

-17 Similar entries are made for the directory file 182, and data files 184 and 186; these entries are labelled 232, 234, and 236 respectively in Fig 6.

The bank account installer application 124 then instructs the device application 110 to execute the newly-loaded bank account card application 180 (step 166). When the card application 180 executes, it creates the directory file 182 and the two data files 184, 186. The cardholder may then remove the card 100.

The memory 104 now has a block of files 240 (Fig 2) staiting at file number '30001 which relate to operating a bank account and a block of files 220 starting at file number '20001 which relate to a loyalty card scheme.

It will be appreciated that the cardholder may load as many card applications on the card 100 as the memory 104 will hold. If a cardholder wishes to delete a card application (for example, 170), then the cardholder must insert the card in a terminal that has a client install application (122) for that card application (170). This is because a mandate authorisation is required before any files on the Smart card (100) can be deleted.

Figs 8 to 10 show the source code in the JAVA (trade mark) programming language for the device application 110 (Fig 3), the loyalty card application 170, and the bank account application 180 respectively. The source code shown in Figs 8 to 10 is brief, and the function of the code will be apparent to those of skill in the art.

Fig 8 illustrates code 400 for importing publicly available JAVA (trade mark) classes for use with the Cyberflex (trade mark) card.

To conform to the ISO 7816 transfer protocol, the service application 132 (Fig 4) sends command messages to the Smart card 100 which have a predefined structure, referred to as an application protocol data unit (APDU). In this embodiment a minimum of five bytes are required for each APDU: one byte is used for the class byte ('OX, for ISO-based instructions), one byte for the instruction, two bytes for parameters associated with the instruction (which may be an address in the form of a file number), and one byte for the response length.

Initialisation code 404 is used to initialise'the cardby allocating an 18byte receive buffer and an 18byte transmit buffer in the card memory. Initialisation code 404 also allocates lbyte for an acknowledge command, lbyte to store the card application number, lbyte to store the number of card applications, 18bytes to store the name of a card application, and Sbytes to store a reply. Initialisation code 404 also resets the card and reads the number of card applications stored on the card.

Command receipt code 406 awaits receipt of five bytes. when five bytes have been received, the code 406 loads the first byte (the command) into the lbyte of memory allocated for the acknowledge command. Code 406 loads the second byte into the lbyte of memory allocated for the card application number, and loads the first two bytes.,-.of the transmit buffer with a 'command successful' response.

One of code blocks 408, 410, and 412 will be implemented depending on the command issued by the service application.

Code block 408 is implemented if the command issued is a request for the number of card applications resident on the Smart card 100.

Code block 410 is implemented if the command issued is a request for the name of a card application.

Code block 412 is implemented if the command issued requests a card application to be added to the directory 116 (Fig 2). The code 412 writes the name of the new card application into memory, and also increments the number of card applications stored on the Smart card 100 and writes this new number into memory.

If the command issued is not recognised then the transmit buffer is loaded with a message indicating that the command was not recognised, as shown by command unknown code 414.

Transmit code 416 transmits the contents of the transmit buffer to the card reader.

Fig 10 illustrates how an authorisation mandate can be embedded in the code for a card application. A I pinstatus' register is set when the correct personal identification number (PIN) has been entered by a user. only when the 'pinstatus' register has been set to a certain value will the user be able to access account information or enter transactions. This provides a layer of security for preventing third parties from conducting transactions or viewing sensitive information unless they enter the correct identifier (in this embodiment, a PIN).

It will now be appreciated that above embodiments of the invention have the advantage of providing a management and directory service for loading, initialising, and deleting card applications which are resident on a Smart device, such as a Smart card. These embodiments of the invention also provide a means for allowing a client application to identify one or more card applications that are associated with the client application.

In other embodiments, the device application may be referenced by a file number other than '3FOO1. In other embodiments, terminal 120 may offer enrolment for only one service, or for more than two services. In other embodiments, the name used for a card application may be the reverse of the Internet domain name of the company providing the service. In other embodiments, the Smart device may be a Smart button, ring, or other personal hardware item. -In other embodiments, the data files stored in memory 104 may be protected at the operating system level in addition to the use of a mandate -20authorisation.

In other embodiments, the file numbers for a card application and its associated data files may not be sequential, for example, a 200 byte card application may be'stored at file number 3500, an associated 100 byte data file at file number 4200, and a second associated 100 byte data file at 4400. Thus, the files may be stored at non-contiguous file numbers. When files are to be stored at non-sequential file numbers, the installer loads the card application to a first file number and either creates the remaining two files according to a commonly known (between the installer and the card application) number or offset; or the installer informs the card application of the file numbers to be used when creating the associated data files.

Claims

1. A Smart device (100) for hosting a plurality of applications, the device (100) comprising processing means (102) and storage means (104), characterised in that the device includes a directory (114) for' storing file information relating to hosted applications (170,180) and a device application (110) for supplying the file information to a device reader (128).

2. A device according to claim 1, wherein, the device application (110) is operable to supply file information in response to a query from a client application.

3. A device according to claim 1 or claim 2, wherein the device application (110) is operable to supply the number and the identity of the applications (170, 180) that are resident on and executable by the Smart device (100).

4. A device according to any of claims 1 to 3, wherein the Smart device (100) is a Smart card.

5. A device according to any preceding claim, wherein the directory (114) is referenced by a predetermined file number.

6. A method of hosting a plurality of applications on a Smart device, where the applications (170, 180) are stored at non-predetermined file numbers, characterised by the steps of storing file information relating to the hosted applications, supplying the file information to a device reader so that the device reader can identify any relevant files on the device, and executing any application called by the device reader.

7. A method according to claim 6, wherein the file information is supplied in response to a request from the device reader.

8. A Smart device system (118) characterised by the Smart device of claim 1 and a Smart device terminal (120) incorporating a Smart device reader (128).

9. A Smart device terminal (120) for instructing execution of an application stored at an non predetermined file number on a Smart device (100), where the terminal (120) includes a client application (122,124, 132,134) operable to interrogate a Smart device (100) for obtaining information about the location and type of any files stored on that Smart device (100).

10. A Smart device terminal (120) for instructing execution of an application stored on a Smart device (100) and referenced by a nonpredetermined file number, where the terminal (120) includes a client application operable to interrogate a Smart device (100) for obtaining information about the location and type of any files stored on that Smart device (100).