Data carrying device and systems for use therewith

[0002] This application is a continuation of U.S. patent application Ser. No. 09/462,026 filed on Dec. 30, 1999 now U.S. Pat. No. 6,449,684, as a national phase filing of PCT/AU98/01009 filed Dec. 4, 1998.

[0003] The present invention relates to a data carrying device and systems for use therewith.

[0004] The invention has been developed primarily for use as a smart-card system and will be described hereinafter with reference to this application. However, it will be appreciated that the invention is not limited to this particular field of use.

[0005] Known smart-cards are generally configured differently depending upon the particular functions they are to perform. Typically, the memory space of prior art smart-cards contain various segments of fixed size, each of which are dedicated to the storage of a particular kind of data relating to a specific application/program. Such utilization of the limited resources generally available in a smart-card results in limited overall functionality. For example, in the prior art, a 1K card typically supports 1, 2 or 3 predetermined and fixed applications/programs.

[0006] It is know to format data on smart-cards such that each application resides in a separate directory, for example, in accordance with International standard ISO 7816.

[0007] In practice, however, it has been appreciated by the applicant that these formats are not suited for devices such as smart-cards if they are configured to support large numbers of applications and programs because the amount of resources required to support the resulting elaborate application and directory structure is excessive.

[0008] Additionally, the differing formats adopted by different card providers for different applications or programs seriously limits the inter-operability of present day smart-card systems. In other words, a smart-card supplied by a given card provider or card issuer for a particular program and configured to fulfill a particular function, will generally not be compatible with the hardware and operating systems of different card providers, or hardware and operating systems designed to fulfill a different function, or the potential limitless number of different programs or functions required by the many different card providers, card issuers or users of the different functions and programs.

[0009] Known smart-card systems are typically custom made to support a small number of specific applications running under fixed constraints. Changes to the system usually require revision of the software and possibly the associated hardware, involving long lead times and substantial expense. The low number of applications/programs supported by each card and the lack of flexibility inherent in the current approach has seriously limited the functionality and interoperability of present day smart-card technology.

[0010] It is an object of the present invention to overcome or ameliorate one or more of the disadvantages of the prior art, or at least to provide a useful alternative.

[0011] According to one aspect of the invention, there is provided a data carrying device having a memory space for storing data at a plurality of locations, said memory space including:

[0012] a static area residing at a fixed location;

[0013] an index area residing at a first dynamically allocatable location; and

[0014] an application area residing at a second dynamically allocatable location, said static area being configured to hold data pointing to the location of said index area and said index area being configured to hold data indicative of applications or programs residing within said application area, said static area being configurable as either random access memory or read-only memory in accordance with a variable setting of an access control block.

[0015] Preferably, the index area is configured to hold data indicative of programs residing within the application area.

[0016] According to a second aspect of the invention, there is provided a data carrying device having a memory space for storing data at a plurality of locations, said memory space including an application area divided into a plurality of units, each being configurable to store data associated with part or all of a program, the location of any unit, or units corresponding to any program being dynamically allocatable.

[0017] Preferably, the size of said unit is small compared to the size of the segments utilized in the prior art.

[0018] As used in this document, the term “data carrying device” includes, for example, contact or contactless smart-cards, magnetic striped cards, chip bearing devices such as watches, key rings, keys, phones, small pocket devices, electronic wallets and the like.

[0019] According to another aspect of the invention, there is provided a system for manipulating data on a plurality of data carrying devices, said system including at least one host and one or a plurality of terminals, each terminal being adapted to interact with said data carrying devices, the terminals and the host being adapted to communicate parameter files therebetween, each of said terminals further including software being activatable and configurable in response to said parameter files so as to initiate and/or update data on said data carrying devices. Preferably, the software in each terminal is substantially functionally identical. Alternatively, the software may reside in the host rather than the terminals. In this embodiment, the software is separate from the host software.

[0020] Preferably, the data carrying devices referred to in the system of the invention are in accordance with that of the first and/or second aspect of the invention.

[0021] As used in this document, the term “software” includes functional equivalents such as hardware configured to give the same, or a similar, result, for example, EPROM, firmware, etc.

[0022] The system of the present invention allows each of the applications to be implemented many times over. For example, any one data carrying device may, at any time, hold numerous different tickets for various unrelated services. Each implementation of an application, for example, each individual ticket, requires data to be stored in at least one unit of the application area. Each implementation of an application is referred to in this document as a “program”. The ability of the present invention to support numerous programs relating to numerous different applications compares favorably to prior art smart-card systems which typically offer only a small fraction of such functionality for cards having identical resources.

[0023] A preferred embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

[0024] FIG. 1 is a schematic view of a memory space according to the invention;

[0025] FIG. 2 is another schematic representation of a memory space according to the invention showing a preferred relationship between the index area and the application area;

[0026] FIG. 3 is a schematic diagram of a system according to the present invention; and

[0027] FIG. 4 is a schematic diagram of software included in each of the terminals.

[0028] Referring to the drawings, the data carrying device (not shown) has a memory space 1 for storing data at a plurality of locations, said memory space including:

[0029] a static area 2 residing at a fixed location;

[0030] an index area 3 residing at a first dynamically allocatable location; and

[0031] an application area 4 residing at a second dynamically allocatable location.

[0032] The first and second dynamically allocatable locations allow the index area and application area to be defined within any portion of the memory space. Advantageously, this provides a security safeguard because memory spaces on different devices can be formatted differently such that a location corresponding to a given type of information on a first memory space will not necessarily correspond to a location of similar data in a second memory space. Additionally, the flexibility inherent in providing dynamically allocatable locations enables different data carrying devices, having different amounts, configurations and available regions of memory space, to operate efficiently within the one system. For example, the present invention allows for memory space to be reserved in a standard format on the majority of the popular, presently available smart-cards, despite differing memory capacities and memory location formats. In particular, the present invention can co-exist on and with numerous pre-existing third-party smart-card systems and pre-existing payment systems, such as Visa Cash, Mondex, Chipper, debit, credit and cash, provided sufficient spare memory space is available on a smart-card. In other words, any device formatted in the above described manner can be used in any of the terminals of the present invention (unless such use is specifically prohibited by a rule defined by a parameter file).

[0033] As shown in FIG. 2, the application area 4 is divided into a plurality of units 5, each being configurable to store data associated with part, or all of, a program. The location of any unit, or units corresponding to any program is dynamically allocatable. The size of a unit 5 is small compared to the size of the segments utilized in the prior art. For example, a prior art segment (which holds data corresponding to one application/program only) may have a pre-defined size, of, say, 500 bytes. However, if the actual memory space used by the application/program is less than this fixed amount, say, 100 bytes, this arrangement results in significant wasted resources, in this example 400 bytes.

[0034] In contrast, the size of the units used in the preferred embodiment of the present invention is 16 bytes. Once a program (i.e., the data relating to an application) has been written to the minimum number of units required, the next blank unit is then available for the writing of another program because the location of any unit corresponding to any program is dynamically allocatable. Hence, the amount of wasted resources lying between consecutive program data can be arranged to never exceed 15 bytes. Therefore, the present invention allows multiple programs to be written to the application area in a far more memory space efficient manner by minimizing wasted resources between programs.

[0035] Additionally, because the programs all reside within the application area of the present invention, the wasted resources associated with creating a separate directory for each application/program are avoided.

[0036] The present invention advantageously allows the application area 4 to be utilized by the system of the present invention on an “as required” basis. For example, if only one application is being run on a particular data carrying device, for example, ticketing, then substantially the whole of the application area is available for storage of data relating to ticketing programs. This compares favorably to the prior art where predefined segments of memory space, having a fixed size, are provided for each application supported by the prior art system. Hence, memory space is allocated regardless of whether it is required by a particular data carrying device.

[0037] The static area 2 is configured to include data indicative of any of the following:

[0038] an entity responsible for issuing the data carrying device;

[0039] an issuing country;

[0040] a card group;

[0041] a unique device identification number;

[0042] whether the device is personalized;

[0043] a date and time at which the device was initialized;

[0044] the location of said application area;

[0045] a size of said application area;

[0046] a device model; and/or

[0047] an entity responsible for initializing the data carrying device.

[0048] The data indicative of whether the device is personalized may be used, for example, in smart-cards to indicate whether the name of the card holder is embossed thereon.

[0049] The static area 2 is configurable as either random access memory, or read only memory, by means of setting an access control block (not shown). In the preferred embodiment, the static area 2 is configured as random access memory prior to an initialization process whereby the above data is written to the static area. After the initialization process, the static area is configured as read only memory so as to prevent inadvertent or unauthorized changes to the data.

[0050] The provision of the data in the static area 2 enables the allocation of memory space 1 on a data carrying device to be individually tailored for each device at the time of initialization. This enables far greater flexibility than the prior art systems which require allocation of space to be fixed for the effective lifetime of the system. Hence, the present invention allows the values in the static area 2 to be changed for each newly initialized device so as to readily allow for the development of new products having different space requirements and yet still operating within the same system.

[0051] The location of the static area 2 is fixed as it effectively controls access to all other areas on the data carrying device. In the preferred embodiment, the static area is placed in the first available memory location of the device.

[0052] The index area 3 is configured to hold a plurality of index entries 6 representing numbers, each of which uniquely correlate with applications residing within the application area 4 according to a predetermined correlation scheme. In the scheme of the preferred embodiment, the number may range between 0 and 65535. For example, 00100 corresponds to an application holding device variables. Numbers in the range of 10,000 to 19,999 are reserved for loyalty program applications. The range 20,000 to 29,999 is reserved for pass applications such as membership, access control and tickets. 30,000 to 39,999 is reserved for electronic purse applications and 40,000 to 49,999 for account applications.

[0053] As will be appreciated by those skilled in the art, the correlation scheme can be tailored so as to uniquely match any number with a specific application. In some embodiments, an order of location of the index entry numbers 6 corresponds respectively with an order of location of the applications.

[0054] In the preferred embodiment, the application area is segmented into units 5 and the index area 3 is configured to hold a plurality of index entries 6 representing numbers, each of which uniquely correlate with the programs written onto the units according to the predetermined correlation scheme. In this embodiment, an order of location of said numbers corresponds respectively with an order of location of said units 5. This relationship is shown in FIG. 2 whereby index area entry n defines the contents of the application and program in the corresponding application unit n.

[0055] Each index entry is initially set to zero during the initialization process so as to indicate that no programs have yet been stored in the application area. As programs are subsequently written to the application area, the index entries are correspondingly updated.

[0056] If necessary, some of the programs may expire once predetermined expiry criteria are fulfilled. For example, a program may expire once a certain date is reached or once a certain number of transactions have been completed. The units 5 occupied by an expired program are available for the writing of a replacement program. Similarly, the index entries 6 corresponding to said expired units 5 are available for the writing of replacement index entries 6 corresponding to said replacement program. In a preferred embodiment, the units 5 occupied by an expired program are only available for the writing of the replacement program if all index entries 6 indicative of the programs in the units 5 are non-zero. This ensures that all free units 5 are utilized before data in an expired unit is over-written.

[0057] An application specifically tailored to store device variables useful for the efficient running of a smart-card system may include data indicative of any one of the following:

[0058] a data carrying device status;

[0059] counters;

[0060] various dates and times;

[0061] security data records and other operating variables.

[0062] As shown in FIG. 3, the preferred embodiment of the system 30 for manipulating data on, a plurality of data carrying devices 31, preferably smart-cards 32, includes at least one host 33 and one or a plurality of terminals 34, each being adapted to interact with said data carrying devices 31. In particular, the terminals 34 are adapted to read from the static area 2, index area 3 and application area 4 of each data carrying device 31 and to write to the index areas 3 and the application areas 4.

[0063] The terminals 34 and the host 33 are adapted to communicate parameter (not shown) files therebetween. Such communication may be by means of an on-line connection between the host 33 and each of the terminals 34. Some alternative embodiments of the invention accomplish communication between the host 33 and the terminals 34 by means of a portable data carrying device (not shown). The latter form of communication is especially suited for terminals 34 located in remote areas where on-line connection may not be feasible, or for example, in an automated vending machine for which the establishment of an on-line connection would not be financially viable. In another preferred embodiment (not illustrated) the terminal is, in effect, the same computer as the host and the communication occurs between the different software in the same computer. In this preferred embodiment, the host has “terminal software” which is separate from the “host software”.

[0064] Each of the terminals 34 further include functionally identical software 40 (labeled “Application Support Logic” in FIG. 4) being activatable and configurable in response to said parameter files so as to initiate and/or update data on said data carrying devices 31. In this document, the scope of the term “functionally identical” includes software comprising or formed from differing source codes but achieving similar or preferably identical overall functionality.

[0065] The use in terminals 34 of software being activatable and configurable in response to parameter files sent from a host 33 enables the system 30 of the present invention to offer a far greater range of functions than has hitherto been available in smart-card systems. Depending upon the number of applications and programs supported by the system, and the number of ways in which each application can be implemented to form a program, the system can be configured to run thousands of programs relating to large numbers of applications. For example, the preferred embodiment can be configured to support from less than 5 to 50 or more different applications, each of which can result in a large number of different programs, the exact details of which will vary depending upon the contents of the parameter files communicated between the terminals and the host. Hence, the system of the present invention provides for a huge range of options. For example, the preferred embodiment provides capability for over 36 different concurrent programs running on one data carrying device having a memory storage capacity of 1K. Additionally, over 65,000 different concurrent programs-can be supported by one host.

[0066] The amount of data communicated in the parameter files is comparatively small in relation to the size of the software 40 required to provide the various applications and programs implemented by smart-cards. Hence, limiting communication predominantly to parameter files helps to minimize the time, resources and expense associated with communications between the terminals 34 and the host 33.

[0067] The host 33 is configured to receive and store the data sent from all terminals 34 so that a central record of all interactions between all terminals 34 and data carrying devices 31 may be maintained. If terminals 34 send batch data to the host 33 on a daily basis, then the records kept on the host should be current for all transactions carried out up to, and including, the preceding day.

[0068] The system 30 of the present invention is designed to work in conjunction with many of the pre-existing -card and terminal systems. Hence, the system 30 must run on many different terminals 34, often having different operating systems 41. For this reason, the software 40 in each of the terminals 34 includes at least one of the aforesaid many possible operating systems 41, an application module 40 common to all terminals 34 in the system 30 and a hardware abstraction layer 42 being adapted to integrate said operating system 41 and said application module 40. This structure is shown schematically in FIG. 4. In this manner, the core application module 40 can be copied in a substantially identical form to all terminals 34, each of which also include a hardware abstraction layer 42 specifically tailored to integrate the application module 40 with the particular operating system 41 of the terminal 34. This arrangement advantageously allows the software 40 to be readily implemented upon many differing types of pre-existing terminals 34 in an efficient manner.

[0069] The application module 40 common to all terminals 34 includes the full variety of applications supported by the system. Some or all of the applications are dormant until such time as a parameter file is received by the terminal 34 from the host 33 so as to initiate and subsequently modify applications and/or programs as desired. As presently contemplated, the preferred embodiment includes the following applications:

[0070] Terminal Management 43;

[0071] Device Management 44;

[0072] Electronic Purse and other payment systems 45;

[0073] Loyalty and Incentive Programs 46;

[0074] Electronic Tickets 47;

[0075] Memberships 48; and

[0076] Access Control and Authentication 49.

[0077] The terminal management application 43 provides a means whereby field service technicians can manipulate various operating parameters, for example:

[0078] a merchant identification number;

[0079] a terminal identification number;

[0080] a host phone number and associated parameters. The terminal management application 43 also provides for data storage means adapted to record details of all interactions between the terminal 34 and the data carrying devices 31, said details being stored in a current transaction log file. The terminals 34 further include means for batch communication of data stored in the data storage means to said host 33. The use of batch communication is preferable to communicating with the host 33 during every interaction between a terminal 34 and a data carrying device 31 because the interactions can thereby proceed far more swiftly. Additionally, the use of batch processing reduces the overall communication costs. In the preferred embodiment, the terminals 34 communicate with the host 33 on a daily basis in a process referred to as “settlement”. The settling process involves the terminal dialing a preset phone number and entering into a communications dialogue with the host. Once authenticated, the terminal uploads its current transaction log file and downloads a new parameter file, if necessary. The terminal management application 43 will preferably provide means whereby the settlement process is automatically initiated by the terminal 34 at a predetermined time each day.

[0081] The card management application 44 checks every card that is presented to a terminal and will activate other applications or programs only when the card management application 44 determines that the data carrying device 31 presented to the terminal 34 contains a legitimate file structure, that is, a file structure having a static area 2, index area 3 and application area 4 as described above. The card management application 44 will determine a card group into which the data carrying device 31 falls. The card groups may be differentiated based upon criteria such as: country code; issuer ID; physical appearance, target market for the device and device group. The card group can be used to determine the rules of transaction between the terminal 34 and the device 31. The preferred embodiment of the present invention can advantageously interact with devices 31 falling within different card groups and terminal groups. Additionally, the rules which define the transactions between the terminal 34 and a given card group can be readily altered by exchanging parameter files between the host 33 and the terminal 34. In some embodiments, the rules of transaction relating to a given card group or a given program are written within programs stored on the data carrying device 31.

[0082] The card management application 44 also controls the expiry and renewal of the data carrying device 31 based upon parameters received from the host 33 on a card group basis. Another parameter received from the host 33 defines a reminder period for renewals, for example, one month. In this case, device renewal may occur only during the reminder period, being the calendar month leading up to the expiry date. During the reminder period, the device holder is notified of impending device expiry by messages that are included at the bottom of transaction receipts. The card management application 44 keeps track of a status of the device 31, for example, either “initialized”, “issued” or “blocked”. The host 33 maintains a list of blocked devices 31 that it sends to terminals 34, by means of parameter files, on a regular basis. When a terminal 34 encounters a device 31 that is included on the blocked list, the terminal 34 changes the status of the device 31 to “blocked”.

[0083] The electronic purse application 45 is responsible for reading and writing electronic representations of money to and from the data carrying devices 31 during transactions.

[0084] The loyalty program application 46 is responsible for reading and writing loyalty points to and from the data carrying device 31. This application implements rules whereby loyalty points accumulate on the basis of predefined activities, such as purchase amounts, purchase frequencies, data carrying device renewal, etc. Such points can be implemented in schemes by merchants whereby accumulation of points beyond a predetermined threshold results in some reward for the device holder.

[0085] The electronic ticket application 47 allows the data carrying devices 31 to support ticket functionality. For example, tickets to use a bus service could be purchased from a terminal owned by a retail merchant, with the necessary ticket data being written to the data carrying device 31. Terminals 34 are provided at entry or exit points to the bus service and the ticket data on the device 31 is updated as necessary as the device 31 passes through the terminals 34.

[0086] The membership application 48 and access control application 49 are functionally similar to the electronic ticket application 47.

[0087] Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that the invention may be embodied in many other forms.