Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
7194768
Kisliakov
March 20, 2007
Title
Access control for a microprocessor card
Abstract
A method and apparatus for executing messages using a plurality of applications resident in a memory means (276) of an electronic card (100), is disclosed. The electronic card (100) is adapted for coupling to a reader device (300) to facilitate reading of the memory means (276). The reading device (300) is configured for communication with a remote apparatus (computer 700) having a further application executing thereon. The one or more card resident applications are required to process one or more messages received from the further application. Depending on the determination, the one or more messages are executed using a first of the card resident applications if one or more predetermined criteria are met. Alternatively, the one or more messages are executed using a second of the card resident applications if one or more further criteria are met. The one or more further criteria are determined via an array containing the one or more further criteria.
Inventors:
Kisliakov; Andrew
(Burwood,
AU
)
Assignee:
Canon Information Systems Research Australia Pty Ltd.
(North Ryde,
AU
)
Appl. No.:
10/323,802
Filed:
December 20, 2002
PCT Pub Date:
March 21, 2007
Foreign Application Priority Data
Dec 20, 2001 [AU] PR9660
Aug 16, 2002 [AU] 2002950930
Current U.S. Class:
726/20
726/9
713/189
726/19
Current International Class:
H04L 9/32 (20060101) H04K 1/00 (20060101)
U.S. Patent Documents
20010017616
August 2001
Kobayashi
20030212896
November 2003
Kisliakov
5002062
March 1991
Suzuki
5353016
October 1994
Kurita et al.
5601489
February 1997
Komaki
5729717
March 1998
Tamada et al.
5949492
September 1999
Mankovitz
5973475
October 1999
Combaluzier
6014593
January 2000
Grufman
6229694
May 2001
Kono
6606707
August 2003
Hirota et al.
6721891
April 2004
Borza
6742117
May 2004
Hikita et al.
7046810
May 2006
Takada et al.
Foreign Patent Documents
0 469 581
Feb., 1992
EP
04-88547
Mar., 1992
JP
28896/95
Feb., 1996
AU
3637684
May., 1987
DE
59-123986
Jul., 1984
JP
95/35534
Dec., 1995
WO
U03-71329
Jun., 2000
JP
Primary Examiner:
Revak; Christopher
Attorney, Agent or Firm:
Fitzpatrick, Cella, Harper & Scinto
Claims
The invention claimed is:
1. A method of processing a message using a first software application and a second software application, wherein each of said first and second software applications are resident in a memory means of an electronic card and are configured to be executed on said electronic card, wherein said electronic card is constructed for coupling to a reading device to facilitate reading of said memory means said reading device is configured for receiving said message from a third software application executing on a remote apparatus, and wherein said message comprises a code identifying said first application or said second application, said method comprising the steps of: using said first software application to determine which of said first and second software applications is identified in said message; and if said first software application is identified in said message, determining whether a first set of conditions is satisfied and processing said message using said first software application if said first set of conditions is satisfied, or if said second software application is identified in said message, determining whether a second set of conditions is satisfied and using said first software application to pass said message to said second software application if said second set of conditions is satisfied, wherein said second set of conditions are secure access conditions.
2. The method according to claim 1, wherein said secure access conditions include whether a user of said electronic card has been verified by a personal identification number.
3. The method according to claim 1, wherein said secure access conditions include whether a secure communications link has been established between said third application and one of said first and second software applications.
4. The method according to claim 1, wherein said secure access conditions include a general denial of processing.
5. The method according to claim 1, wherein said secure access conditions include a general allowance of processing.
6. The method according to claim 1, wherein said electronic card has one or more user interface elements formed on a surface thereof.
7. The method according to claim 6, wherein said first application is configured to process reading signals generated from a user selection of one or more of said user interface elements.
8. The method according to claim 1, further comprising the step of sending a response from said first software application or said second software application to said third software application.
9. The method according to claim 8, further comprising the step of applying a signature to said response.
10. The method according to claim 8, further comprising the step of encrypting said response.
11. The method according to claim 10, wherein said encryption is performed using a first security key stored in said memory means.
12. An electronic card for processing a message using a first software application and a second software application, wherein each of said first and second software applications are resident in a memory means of said electronic card and are configured to be executed on said electronic card, wherein said electronic card is constructed for coupling to a reading device to facilitate reading of said memory means and said reading device is configured for receiving said message from a third application executing on a remote apparatus, and wherein said message comprises a code identifying said first application or said second application, said electronic card comprising: processor means for using said first software application to determine which of said first and second software applications is identified in said message, and if said first software application is identified in said message, determining whether a first set of conditions is satisfied and processing said message using said first software application if said first set of conditions is satisfied, or if said second software application is identified in said message, determining whether a second set of conditions is satisfied and using said first software application to pass said message to said second software application if said second set of conditions is satisfied, wherein said second set of conditions are secure access conditions.
13. A first software application resident in an electronic card and configured for processing a message, wherein said first software application and a second software application are resident in a memory means of said electronic card and are configured to be executed on said electronic card, wherein said electronic card is adapted for coupling to a reading device to facilitate reading of said memory means and said reading device is configured for communication for receiving said message from a third application executing on a remote apparatus, and wherein said message comprises a code identifying said first application or said second application, said first software application comprising: code for using said first software application to determine which of said first and second software applications is identified in said message; and if said first software application is identified in said message, determining whether a first set of conditions is satisfied and processing said message using said first software application if said first set of conditions is satisfied, or if said second software application is identified in said message, determining whether a second set of conditions is satisfied and using said first software application to pass said message to said second software application if said second set of conditions is satisfied, wherein said second set of conditions are secure access conditions.
Description
TECHNICAL FIELD OF THE INVENTION
The present invention relates generally to a control card or smart card for use with a reader device and, in particular, to access control for a microprocessor or central processing unit (CPU) smart card defining a custom user interface. The invention also relates to a computer program product including a computer readable medium having recorded thereon a computer program for implementing access control on a microprocessor card or CPU smart card defining a custom user interface.
BACKGROUND ART
Control cards, such as smart cards, as known in the relevant art are often used for security purposes such as user authentication. Most conventional control cards include some form of readable storage means such as a magnetic strip, an optical code (e.g. a bar code) or an on-board memory chip, for storing data (e.g. a personal identification number) associated with the card. Such control cards can be generically referred to as memory cards. However, control cards including a storage means in the form of an on-board memory chip are generally referred to as `smart cards`. The data stored in the storage means is generally read by some form of terminal device, which includes a magnetic read head, for example.
One known method for authenticating a user and allowing the user access to amenities and/or services is by requesting that the user present a memory card at a point of access and then enter a personal identification number into an input device. The input device compares the entered personal identification number with data stored in the memory of the memory card to determine the validity of the entered personal identification number. Such a method suffers from the disadvantage that the input device is made aware of the configuration of the personal identification number and may be used to copy and/or reuse the personal identification number. Since users often utilise the same personal identification number to gain access to a variety of unrelated amenities and/or services, the security of these amenities and/or services can be compromised in one action through the use of an insecure input device. Thus, the input device used for reading a smart card must be secure so as not to allow a user's personal identification number to be exposed or otherwise used without the consent of the user.
Some smart cards include a microprocessor integrally formed within the smart card. These smart cards are generally referred to as microprocessor or central processing unit (CPU) cards and some of these CPU cards are configured to address the problem of non-secure input and terminal devices by incorporating an input device onto the smart card in the form of a touch sensitive keypad on at least one surface of the card.
There are several existing smart card systems, which utilise CPU smart cards including a keypad. One of these existing smart card systems utilises a self-contained smart card including a keypad, a display, a memory and means to enter and verify a personal identification number. In order to gain access to amenities and/or services, a user presents the CPU card at a point of entry and then enters a personal identification number using the built-in keypad. The personal identification number is verified by a verification means associated with the point of access and the user is allowed or denied access to the amenity and/or service depending on the result of the verification process.
Another of these existing smart card systems includes a self-contained smart card having a power source, a keypad, a display, a memory and a means to enter identification information. Still another existing smart card system utilises a self-contained CPU card including a multi-functional and programmable keypad and display, which are used to enter information. These other smart card systems work in a similar manner to the smart card system described above.
Still another existing CPU smart card system allows a personal identification number to be entered into a CPU card, which includes a touch sensitive keypad, when the card is inserted into a smart card reader. The reader includes an overlay which can be positioned over the surface of the smart card to provide user interface elements related to the keypad. The overlay is configured to allow a user to transfer pressure onto the surface of the CPU card, adjacent to one or more of the user interface elements, in order to select a function.
However, the above mentioned keypad CPU cards require specialised integrated circuit hardware in order to detect pressure on certain points which rules out the use of most conventional CPU smart cards with systems using these keypad CPU cards. Further, CPU cards including an integrally formed keypad generally require discrete user interface elements in discrete positions on the card which limits the function of such cards. Still further, the manufacture of such an integrated circuit card, and in particular the integrated circuit hardware associated with the card, is relatively difficult and involves a very high cost relative to most conventional smart cards. These limitations of keypad CPU cards generally render the cards unsuitable for wide spread usage.
One existing CPU card with a user interface printed on at least one surface of the card includes a data structure describing the interface, where the data structure is stored in a memory integrally formed within the CPU card. The reader device used with this existing CPU card, includes a transparent touch panel positioned above the CPU card so that user interface elements printed on a surface of the smart card are visible underneath the transparent touch panel. The reader device is configured to determine the position of a touch on the transparent panel and then read data structure information stored within a memory of the card to determine which user interface elements have been pressed. The reader device then sends a data string associated with the selected user interface elements to a remote application. However, this reader device suffers from similar disadvantages to those discussed above, in that data stored in the memory of the card is read by the reader and so is not kept confidential. Therefore, the card cannot be used with an untrusted reader.
Most conventional CPU cards are used, for example, in authentication, encryption and credit/banking transaction applications. However, the CPU card described above having a user interface printed on at least one surface thereof, is typically unable to be used in such applications, since the associated reader has a limited set of commands that can be sent to the card. Thus, a need clearly exists for a CPU card having a user interface printed thereon, which can be used in authentication, encryption and credit/banking transaction applications.
Secure smartcard systems that allow remote devices to communicate with a smart card over a secure connection are known. For example, one known smart card system utilises a method for establishing a secure connection between a card and a remote program. Access to certain smart card commands of this known system can be restricted. However, such restriction is typically at the discretion of the card operating system, or an off card entity, such as a remote server. For the user interface CPU card described above, neither the card operating system nor any intermediate part of the smart card system is necessarily aware of the access or other requirements for a specific application. Accordingly, enforcing access control on the above described user interface CPU card system is not appropriate and may even be impossible to implement when using third party operating systems. Thus, a need also exists for a smart card system which allows easy implementation of access control in relation to certain applications executing on the system.
SUMMARY OF THE INVENTION
It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.
According to one aspect of the present invention there is provided a method of executing messages using a plurality of applications resident in a memory means of an electronic card, said electronic card being adapted for coupling to a reader device to facilitate reading of said memory means, said reading device being configured for communication with a remote apparatus having a further application executing thereon, said method comprising the steps of:
determining which of the one or more card resident applications are required to process one or more messages received from said further application; and
depending on said determination: executing said one or more messages using a first of said card resident applications if one or more predetermined criteria are met, or executing said one or more messages using a second of said card resident applications if one or more further criteria are met, wherein said one or more further criteria are determined via an array containing said one or more further criteria.
According to another aspect of the present invention there is provided an apparatus for executing messages using a plurality of applications resident in a memory means of an electronic card, said electronic card being adapted for coupling to a reader device to facilitate reading of said memory means, said reading device being configured for communication with a remote apparatus having a further application executing thereon, said apparatus comprising:
processor means for determining which of the one or more card resident applications are required to process one or more messages received from said further application, and
depending on said determination: executing said one or more messages using a first of said card resident applications if one or more predetermined criteria are met, or executing said one or more messages using a second of said card resident applications if one or more further criteria are met, wherein said one or more further criteria are determined via an array containing said one or more further criteria.
According to still another aspect of the present invention there is provided a program resident in an apparatus, said program being configured for executing messages using a plurality of applications resident in a memory means of an electronic card, said electronic card being adapted for coupling to a reader device to facilitate reading of said memory means, said reading device being configured for communication with a remote apparatus having a further application executing thereon, said program comprising:
code for determining which of the one or more card resident applications are required to process one or more messages received from said further application; and
depending on said determination: executing said one or more messages using a first of said card resident applications if one or more predetermined criteria are met, or executing said one or more messages using a second of said card resident applications if one or more further criteria are met, wherein said one or more further criteria are determined via an array containing said one or more further criteria.
According to still another aspect of the present invention there is provided a method of utilising an electronic card to access a service provided by an apparatus, said electronic card comprising a card portion having a memory means attached thereto, said memory means being adapted for coupling to a reader device to facilitate reading of said electronic card and having at least a data string retained therein, said data string being related to said electronic card, said method comprising the steps of:
verifying a user of said electronic card utilising said data string;
executing an application on said remote apparatus in response to said verification of said user, said application being related to said service;
issuing challenge data to said electronic card using said application;
responding to said challenge data with response data generated by said electronic card;
verifying said response data using said application; and
allowing access to said service in response to said verification of said response data.
According to still another aspect of the present invention there is provided a system for utilising an electronic card to access a service provided by a remote apparatus, said electronic card comprising a card portion having one or more user interface elements formed on a surface thereof and at least a memory means attached thereto, said memory means being adapted for coupling to a reader device to facilitate reading of said electronic card and having at least a data string retained therein, said data string being related to said electronic card, said system comprising the steps of:
comparator means for comparing reading signals generated from a user selection of at least one of said user interface elements with said data string;
processor means for executing an application on said remote apparatus in response to said comparison, said application being related to said service;
challenge means issuing challenge data to said electronic card using said application;
response means for responding to said challenge data with response data generated by said electronic card;
verification means for verifying said response data using said application; and
allowing access to said service in response to said verification.
Other aspects of the invention are also disclosed.
BRIEF DESCRIPTION OF THE DRAWINGS
One or more embodiments of the present invention will now be described with reference to the drawings, in which:
FIG. 1(a) is a perspective view of a smart card;
FIG. 1(b) is a perspective view of another smart card;
FIG. 2(a) is a longitudinal cross-sectional view taken along the line II(a)--II(a) of the card shown in FIG. 1(a);
FIG. 2(b) is a longitudinal cross-sectional view taken along the line II(b)--II(b);
FIG. 3 is a perspective view of a reader device configured for use with the smart cards of FIGS. 1(a) and 1(b) of the card shown in FIG. 1(b);
FIG. 4 shows a user inserting a smart card into the reader of FIG. 3;
FIG. 5 shows a user operating the reader of FIG. 3 after the smart card has been fully inserted;
FIG. 6(a) shows a hardware architecture for a smart card interface system;
FIG. 6(b) shows another hardware architecture for a smart card interface system;
FIG. 7 is a schematic block diagram of the general-purpose computer of FIGS. 6(a) and 6(b) in more detail;
FIG. 8 is schematic block diagram showing the set top box of FIG. 6(b) in more detail;
FIG. 9 is a schematic block diagram representation of a smart card interface system software architecture;
FIG. 10 is a schematic block diagram showing the internal configuration of the reader of FIG. 3;
FIG. 11 shows the data structure of a card header as stored in the smart cards of FIG. 1(a) and FIG. 1(b);
FIG. 12 shows one or more object structures following the card header of FIG. 11;
FIG. 13 is a data flow diagram showing the flow of messages within the system of FIGS. 6(a) and 6(b);
FIG. 14(a) is a perspective view of still another smart card;
FIG. 14(b) shows user interface element objects associated with the smart card of FIG. 14(a);
FIG. 15(a) is a perspective view of still another smart card;
FIG. 15(b) shows user interface element objects associated with the smart card of FIG. 15(a);
FIG. 16 is a flow diagram showing steps performed by a user in order to retrieve on-line music, over the smart card interface system of FIG. 6(b);
FIGS. 17(a) to 17(e) show a number of examples of display output available from the system of FIG. 6(b);
FIG. 18 is a flow diagram showing a method of checking the smart cards of FIGS. 14(a) and 15(a), performed during the user process of FIG. 16;
FIG. 19 is a flow diagram showing a method of scanning the touch panel of the reader of FIG. 3, performed during the user process of FIG. 16;
FIG. 20 is a flow diagram showing an overview of events of the system of FIG. 6(a) during the user process of FIG. 16;
FIG. 21 is a flow diagram showing processes performed by the event manager during the process of FIG. 20;
FIG. 22 is a flow diagram showing an overview of a method performed by the launcher during the process of FIG. 20;
FIG. 23 is a flow diagram showing a method of operating the smart card of FIG. 1(b) using the reader of FIG. 3;
FIG. 24 is a flow diagram showing a process executed when a command is issued to a user interface card resident application executing on the smart card of FIG. 1(a);
FIG. 25 is a flow diagram showing an initialisation process;
FIG. 26 is a flow diagram showing a proprietary instruction process;
FIG. 27 is a flow diagram showing an International Standards Organisation (ISO) instruction process;
FIG. 28 is a flow diagram showing a process coordinate process;
FIG. 29 is a flow diagram showing a user interface element handler process;
FIG. 30 is a flow diagram showing a buffer input user interface element handler process;
FIG. 31 is a flow diagram showing a buffer OK process;
FIG. 32 is a flow diagram showing a pass-code checker process;
FIG. 33 is a flow diagram showing a buffer cancel process;
FIG. 34 is a flow diagram showing a buffer backspace process;
FIG. 35 is a flow diagram showing a buffer append process;
FIG. 36 is a flow diagram showing a standard user interface element process;
FIG. 37 is a flow diagram showing a buffered user interface element process;
FIG. 38 is a flow diagram showing a delegator user interface element process;
FIG. 39 is a flow diagram showing an output object data process executed when the card of FIG. 1(b) outputs data to the reader of FIG. 3;
FIG. 40 is a flow diagram showing a save state process;
FIG. 41 is a flow diagram showing a restore state process;
FIG. 42 is a flow diagram showing a select file process;
FIG. 43 is a flow diagram showing a read binary process;
FIG. 44 is a flow diagram showing a write binary process;
FIG. 45 is a flow diagram showing an erase binary process;
FIG. 46 is a flow diagram showing a get challenge process;
FIG. 47 is a flow diagram showing an external authenticate process;
FIG. 48 shows a smart card depicting an image of a human face;
FIG. 49(a) shows an example buffer descriptor;
FIG. 49(b) is a perspective view of another smart card;
FIG. 50 is a flow diagram showing an unwrap envelope process;
FIG. 51 is a flow diagram showing an internal authenticate process;
FIG. 52 is a flow diagram showing a create channel process;
FIG. 53 is a flow diagram showing a generate session key process; and
FIG. 54 is a flow diagram showing a process for encrypting a character string.
DETAILED DESCRIPTION INCLUDING BEST MODE
Where reference is made in any one or more of the accompanying drawings to sub-steps and/or features, which have the same reference numerals, those sub-steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.
Excepting where explicitly distinguished, in the following description, the term "data string" means `a sequence of bits (i.e. `1` or `0`)` and can include American Standard Code for Information Interchange (ASCII) data, floating point data, and binary representations of integer values, for example.
The embodiments disclosed herein have been developed primarily for use with automatic tellers, remote control and network access systems, and will be described hereinafter with reference to these and other applications. The embodiments disclosed herein can be used to access services such as home shopping, home-banking, video-on-demand, interactive applications such as games and interactive trading cards, and information access such as city guides, television program guides and educational material. However, it will be appreciated that the invention is not limited to these fields of use.
For ease of explanation the following description has been divided into Sections 1.0 to 2.6, each section having associated subsections.
1.0 Smart Card Interface System Overview
1.1 Smart Cards
FIG. 1(a) shows a smart card 100A including a planar substrate 112 with various user interface elements 114 (i.e. predetermined areas, or iconic representations) printed or otherwise formed on an upper face 116 thereof, for example using an adhesive label. For the smart card 100A, the user interface elements 114 are in the form of a four way directional controller 120, a "jump button" 122, a "kick button" 124, a "start button" 128 and an "end button" 130 printed on a front face 116
thereof. Other forms of user interface elements, such as promotional or instructional material, can be printed alongside the user interface elements 114. For example, advertising material 126 can be printed on the front face 116 of the smart card 100A or on a reverse face (not shown) of the smart card 100A. In still other forms of the memory card 100A, the memory chip 219 can be replaced by a storage means such as a magnetic strip (not shown) formed on one surface of the memory card 100A.
As seen in FIG. 2(a), the front face 116 of the smart card 100A may be formed by an adhesive label 260 upon which is printed the user interface in the form of the user interface elements 114, in this case corresponding to the "End Button" and the Right arrow "button" of the directional controller 120. The label 260 is affixed to the planar substrate 112. A home user can print a suitable label for use with a particular smart card 101A by using a printer. Alternatively, the user interface elements 114 can be printed directly onto the planar substrate 112 or separate adhesive labels can be used for each of the user interface elements 114.
As also seen in FIG. 2(a), the smart card 100A includes storage means in the form of an on-board memory chip 219 for storing data associated with the user interface elements 114. The smart card 100A having a memory chip 219 as described above is generally referred to as a "memory card". Thus, the smart card 100A will hereinafter be referred to as the memory card 100A. The memory card 100A also includes electrical data contacts 218 connected to the memory chip 219 and via which reading of the memory chip 219 and writing to the memory chip 219 may be performed.
Alternatively, in other forms of the memory card 100A, the memory chip 219 can be replaced by storage means in the form of machine-readable indicia such as an optical code (e.g. a barcode) printed on a reverse face (not shown) of the memory card
100A.
Memory cards such as the memory card 100A can be utilised in applications where strong security of the smart card 100A and data stored in the chip 219 of the smart card 100A, is not required. The memory card 100A can also be used in applications where it is desired to maintain the cost of manufacturing the smart card 100A to a minimum. Such smart cards can be used for example, where the memory card 100A is given away to promote a service and/or to provide access to the service. The memory card
100A can also be used as a membership card, which provides access to a specific service.
FIG. 1(b) shows another smart card 100B again including a planar substrate 152 with various user interface elements 154 printed on a front face 156 thereof. In the smart card 100B the user interface elements 154 are in the form of a numerical keypad 160, an "OK button" 162, a "cancel button" 164, a "clear button" 166 and a "backspace button" 168 printed on the front face 156 thereof. Again, other forms of user interface elements, such as promotional or instructional material, can be printed alongside the user interface elements 154 such as advertising material 158.
As seen in FIG. 2(b), the front face 156 of the smart card 100B is formed by an adhesive label 270 affixed to the planar substrate 152 in a similar manner to the memory card 100A. Again, a user interface in the form of user interface elements
154, in this case corresponding to the "number 3", "number 6" and "number 9" buttons of the numerical keypad 160 and the "backspace button" 168, is printed on the adhesive label 270.
As also seen in FIG. 2(b), the smart card 100B includes a microprocessor 259 having an integrally formed central processing unit (CPU) 275 and storage means 276. The storage means 276 generally includes volatile random access memory (RAM) (not shown) and non-volatile flash (ROM) memory (not shown), and can be used to store data associated with the user interface elements 154, application software code associated with the smart card 100B and/or information (e.g. a personal identification number) associated with the user and/or manufacturer of the smart card 100B. The smart card 100B will hereinafter be referred to as the CPU card 100B. The CPU card 100B also includes electrical data contacts 278 connected to the microprocessor 259 and which perform a similar role to the contacts 218 of FIG. 2(a). In particular, the electrical data contacts 278 can be used to send instructions to the microprocessor 259 and to receive data resulting from the execution of those instructions on the microprocessor 259.
CPU cards such as the CPU card 100B can be utilised in applications where enhanced user authentication and/or higher levels of security of the CPU card 100B and data stored in the storage means 276, is required.
It will be appreciated by a person skilled in the relevant art, that the user interfaces in the form of the user interface elements 114 and 154 can be interchanged for the smart cards 100A and 100B. Further, the user interfaces able to be printed by a user and/or manufacturer for the smart cards 100A and 100B can take many forms. Memory cards such as the memory card 100A and CPU cards such as the CPU card 100B, having a user interface formed on one surface of the card can be referred to as `User Interface Cards. However, excepting where explicitly distinguished, in the following description, the memory card 100A and the CPU card 100B will be generically referred to as the smart card 100.
1.2 Smart Card Reader
FIG. 3 shows a smart card reader 300 configured for use with both the memory card 100A and the CPU card 100B. The configuration of the electrical data contacts 218 and 278 of the memory card 100A and the CPU card 100B, respectively, correspond to exposed contacts 307 of the smart card reader 300, as shown in FIG. 3. The reader 300 is formed of a housing 301 incorporating a receptacle 304 into which the smart card 100 may be inserted, a viewing area 306 and an access opening 310 configured to accept a smart card 100. An upper boundary of the viewing area 306 is defined by sensor means in the form of a substantially transparent pressure sensitive membrane 308 or simply "touch panel" spaced above the exposed contacts 307 so as to form the receptacle 304. It will be appreciated by a person skilled in the relevant art that alternative technology can be used as the touch panel 308. For example, the touch panel 308 can be resistive or temperature sensitive.
In use, a smart card 100 is inserted by a user into the smart card receptacle 304, through the access opening 310, as shown in FIG. 4. When the smart card 100 is fully inserted into the reader 300, the touch panel 308 fully covers the upper face
116, 156 of the smart card 100. The viewing area 306 preferably has substantially the same dimensions as the upper face 116, 156 of the smart card 100 such that the upper face 116, 156 is, for all intents and purposes, fully visible within the viewing area 306 through the touch panel 308. In this position, the data contacts 218, 278 of the card 100 engage the exposed contacts 307 so that circuitry (not shown) within the reader 300 can communicate with the memory chip 219 or microprocessor 259 of the card 100.
When the card 100 is fully inserted into the reader 300, a user can press areas of the touch panel 308, as shown in FIG. 5, overlying the user interface elements 114, 154. For the memory card 100A, the reader 300 deduces which of the user interface elements 114 the user has selected by sensing the pressure on the touch panel 308 and referring to the data stored in the memory chip 219. For example, if the user places pressure on the touch panel 308 adjacent the "kick button" 124, the reader 300 is configured to assess the position at which the pressure was applied, refer to the stored data, and determine that the "kick button" 124 was selected.
In contrast, for the CPU card 100B, the CPU 275 determines which of the user interface elements 154 the user has selected by processing coordinates received from the reader 300 upon the reader 300 sensing pressure on the touch panel 308, and then the CPU 275 referring to the data stored in the storage means 276 of the microprocessor 259. In this case, it is not necessary for the reader 300 to be able to read and to be made aware of the data stored in the storage means 276 of the microprocessor
259. The operation of the CPU card 100B in relation to the reader 300 will be explained in more detail in Sections 2.0 to 2.6 below.
Information resulting from a user selecting one of the user interface elements 114, 154 can be used to control an external device, for example, an associated automatic teller machine (of conventional construction and not shown). It will be appreciated from above that the user interface elements 114, 154 are not, in fact buttons. Rather, the user interface elements 114 are user selectable features which, by virtue of their corresponding association with the data stored in the memory chip
219 or storage means 276, and the function of the touch panel 308, operate to emulate buttons traditionally associated with remote control devices.
In one advantageous implementation, the reader 300 includes a transmitter (of conventional type and not shown), such as an infra-red (IR) transmitter or radio frequency (RF) transmitter, for transmitting information in relation to user interface elements 114, 154 selected by the user. In this case, upon selection of one of the user interface elements 114, 154, the reader 300 causes information related to the selection to be transmitted to a remote console (not shown in FIG. 5) where a corresponding infra-red or radio frequency remote module can detect and decode the information for use in controlling some function, such as a banking application executing on the automatic teller machine discussed above.
Any suitable transmission method can be used to communicate information from the reader 300 to a remote module, including direct hard wiring. Moreover, the remote module itself can incorporate a transmitter, and the reader 300 a receiver for communication in an opposite direction to that already described. The communication from the remote module to the reader 300 can include, for example, handshaking data, setup information, or any other form of information desired to be transferred from the remote module to the reader 300.
FIG. 10 is a schematic block diagram showing the internal configuration of the reader 300 in more detail. The reader 300 includes a microcontroller 1044 for controlling the reader 300, for coordinating communications between the reader 300 and a remote module, and for storing mapping information and firmware, for example. The microcontroller 1044 includes random access memory (RAM) 1047 and flash (ROM) memory 1046. The microcontroller 1044 also includes a central processor unit (CPU) 1045. The microcontroller 1044 is connected to a clock source 1048 and a clock controller 1043 for coordinating the timing of events within the microcontroller 1044. The CPU 1045 is supplied with electrical power from a battery 1053, the operation of the former being controlled by a power controller 1050. Alternatively, in one implementation, the CPU 1045 can be supplied with power via a universal serial bus cable (not shown) connected to a reader associated with the power coming from a personal computer or similar device. The microcontroller 1044 is also connected to a beeper 1051 for giving audible feedback about card entry status.
Infra-red (IR) communications, as discussed above, can be implemented using two circuits connected to the microcontroller 1044, an infra-red transmitter (TX) 1049 for infra-red transmission and an infra-red remote module (RX) 1040 for infra-red reception. The touch panel 308 of the reader 300 communicates with the microcontroller 1044 via a touch panel interface 1041 and the electrical contacts 307.
An in-system-programming interface 1052 can also be connected to the microcontroller 1044, to enable programming of the microcontroller 1044 with firmware by way of the microprocessor flash memory 1046.
1.3 Hardware Architecture
FIG. 6(a) shows a hardware architecture of a card interface system 600A. In the system 600A, the reader 300 is hard wired to a personal computer system 700 via a communications cable 603. Alternatively, instead of being hardwired, a radio frequency or infrared transceiver 654 formed in the personal computer system 700 can be used to communicate with the reader 300. The personal computer system 700 includes a display device 701, a computer module 702, a keyboard 704 and mouse 703, and will be explained in more detail below with reference to FIG. 7.
The system 600A includes the smart card 100 which is programmable and can be created or customised by a third party, who may be a party other than the manufacturer of the smart card 100 and/or the card reader 300. The third party can be the ultimate user of the smart card 100 itself, or may be an intermediary between the manufacturer and user. In the system 600A of FIG. 6(a), the smart card 100 can be programmed and customised for one touch operation to communicate with the computer 700
and obtain a service over a computer network 720, such as the Internet, coupled to the computer 700. The computer 700 operates to interpret signals sent via the communications cable 603 from the reader 300, according to a specific protocol, which will be described below. The computer 700 performs the selected function according to touched user interface elements 114, 154 and can be configured to communicate data over the network 720. In this manner, the computer 700 can permit access to applications and/or data stored on remote server computers 650, 652 and appropriate reproduction on the display device 701, by way of user manipulation of the reader 300 and card 100.
FIG. 6(b) shows a hardware architecture of a card interface system 600B. In the system 600B, the reader 300 can be programmed for obtaining a service locally at a set top box 601, that couples to an output interface, which in this example takes the form of an audio-visual output device 616, such as a digital television set. The set-top box 601 operates to interpret signals 612 received from the reader 300, which may be electrical, radio frequency, or infra-red (IR), and according to a specific protocol which will be described below. The set top box 601 can be configured to perform the selected function according to touched user interface elements 114, 154 and permit appropriate reproduction on the output device 616. Alternatively, the set top box 601 can be configured to convert the signals 612 to a form suitable for communication and cause appropriate transmission to the computer 700 via the network 720. The computer 700 can then perform the selected function according to the user interface elements 114, 154, and provide data to the set-top box 601 to permit appropriate reproduction on the output device 616. The set top box 601 will be explained in more detail below with reference to FIG. 8.
In one application of the system 600B, the smart card 100 can be programmed for obtaining a service either remotely or locally. For instance, the smart card 100 can be programmed to retrieve an application and/or data stored on remote server computers 650, 652, via the network 720, and to load the application or data on to the set top box 601. The latter smart card can be alternatively programmed to obtain a service from the loaded application on the set top box 601.
Excepting where explicitly distinguished, the systems 600A and 600B of FIG. 6(a) and 6(b) will be hereinafter generically referred to as the system 600.
FIG. 7 shows the general-purpose computer system 700 of the system 600, which can be used to run the card interface system and to run software applications for programming the smart card 100. The computer system 700 includes the computer module
702, input devices such as the keyboard 704 and mouse 703, output devices including a printer (not shown) and the display device 701. A Modulator-Demodulator (Modem) transceiver device 716 is used by the computer module 702 for communicating to and from the communications network 720, for example connectable via a telephone line 721 or other functional medium. The modem 716 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN).
The computer module 702 typically includes at least one central processing unit (CPU) 705, a memory unit 706, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (I/O) interfaces including a video interface 707, and an I/O interface 713 for the keyboard 704 and mouse 703, a write device 715, and an interface 208 for the modem 216. The I/O interface 713 also includes the IR transceiver 654 connected to the I/O interface 713 for communicating directly with the reader 300. A storage device 709 is provided and typically includes a hard disk drive 710 and a floppy disk drive 711. A magnetic tape drive (not illustrated) is also able to be used. A CD-ROM drive 712 is typically provided as a non-volatile source of data. The components 705 to 713 of the computer module 702, typically communicate via an interconnected bus 704 and in a manner, which results in a conventional mode of operation of the computer system 702 known to those in the relevant art. Examples of computers on which the arrangement described herein can be practised include IBM-computers and compatibles, Sun Sparcstations or alike computer system evolved therefrom.
Typically, the software programs such as applications of the system 600 are resident on the hard disk drive 710 and read and controlled in their execution by the CPU 705. Intermediate storage of the software application programs and any data fetched from the network 720 may be accomplished using the semiconductor memory 706, possibly in concert with the hard disk drive 710. In some instances, the application programs can be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 712 or 711, or alternatively may be read by the user from the network 720 via the modem device 716. Still further, the software can also be loaded into the computer system 702 from other computer readable medium including magnetic tape, ROM or integrated circuits, a magneto-optical disk, a radio or infra-red transmission channel between the computer module 702 and another device, a computer readable card such as a smart card, a computer PCMCIA card, and the Internet and Intranets including email transmissions and information recorded on Websites and the like. The foregoing is merely exemplary of relevant computer readable media. Other computer readable media are able to be practised without departing from the scope of the invention defined by the appended claims.
FIG. 8 shows the set top box 601 of the system 600, which can be used to interpret the signals 612 received from the reader 300. The set top box 601 in some implementations essentially is a scaled version of the computer module 702. The set top box 601 typically includes at least one CPU unit 805, a memory unit 806, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), and input/output (I/O) interfaces including at least an I/O interface 813 for the digital television 616, an I/O interface 815 having an IR transceiver 808 for receiving and transmitting the signals 612, and an interface 817 for coupling to the network 720. The components 805, 806, 813, 815 and 817 of the set top box 601, typically communicate via an interconnected bus 804 and in a manner which results in a conventional mode of operation. Intermediate storage of any data received from the reader 300 or network 720 may be accomplished using the semiconductor memory 806. Alternatively, the set top box can include a storage device (not shown) similar to the storage device 709.
1.4 Programming the Smart Card
As described above, the smart card 100 is programmable and can be created or customised by a third party. For example, with the system 600, the smart card 100 can be programmed and customised for one touch operation to communicate with the set-top box 601 and/or computer 700 and obtain a service over the network 720. The smart card 100 can be programmed by means of the write device 715 coupled to the I/O interface 713 of the computer module 702. The write device 715 has the capability of writing data to the memory chip 219 on the memory card 100A or the storage means 276 of the microprocessor 259 for the CPU card 100B. Preferably, data is not able to be written to the storage means 276 unless a value, calculated in accordance with a predetermined electronic key, is first presented to the microprocessor 259. Depending upon the specific implementation the write device 715 may also be configured to print graphics on to the front surface 116, 156 of the smart card 100 using image production software application programs. The write device 715 may also have a function for reading data from the smart card 100.
The write device can be configured such that the user can insert the smart card 100 into the write device 715 and then enter the required data. A software application can then write the data entered by the user to the memory of the smart card
100 via the write device 715. If the stored data is encoded for optical decoding such as in the case of a barcode memory card, the write device 715 can print the encoded data onto the memory card 100A.
For the CPU card 100B, the microprocessor 259 can be constructed so that once programmed in the manner described, the contents cannot thereafter be casually read.
1.5 Software Architecture Layout
FIG. 9 shows a software architecture 900 for the hardware architecture depicted by the system 600. The architecture 900 can be divided into several distinct process components and one class of process. The distinct processes include an I/O interface 920, which may be colloquially called an "I/O daemon" 920, an event manager 901, a display manager 906, an (application) launcher 903 and a directory service 911. The class of process is formed by one or more applications 904. In the architecture 900 described herein, there exists one I/O daemon 920, one event manager 901, one display manager 906 and one launcher 903 for every smart card remote connection, usually formed by the set-top box 601. Where processes responsible for multiple remote connections are running on a single computer (e.g. the computers 700, 650 or 652) which provides support for a number of set-top boxes 601, a master launcher 908 (shown in FIG. 9 in phantom lines) can be used. The master launcher 908
communicates directly with the event manager 901 and starts a launcher 903 for every set-top box 601 which connects to master launcher 908. The architecture 900 also includes at least one directory service 911. The directory service 911, is queried by the launcher 903 to translate data into a Resource Locater (eg. URL) that indicates a name or location of a service or the location or name of an application 904 to be used for the service.
In this form, the architecture 900 can be physically separated into six distinct parts 601, 701, 907, 909, 912 and 913 as shown by the dashed lines in FIG. 9, each of which can be run on physically separate computing devices. Alternatively, the display 701 can be a device with little or no computing capacity. Communication between each of the parts of the system 900 can be executed using Transport Control Protocol/Internet Protocol (TCP/IP) streams. Alternatively, each of the parts 601, 701,
907, 909, 912 and 913 can be run on the same machine.
In the system 600A of FIG. 6(a), all of the process components 901, 903, 904, 906 and 920 can be run on the computer 700. The event manager 901, the launcher 903 and display manager 906 are preferably integrated into one executable program which is stored in the hard disk 709 of the computer 700 and can be read and controlled in its execution by the CPU 705. The directory service 911 may run on the same computer 700 or on a different computer (e.g. server 650) connected to the computer 700 via the network 720.
In the system 600B of FIG. 6(b), all of components 901, 903, 904, 906 and 920 can run from the set-top-box 601. In this instance, the components 901, 903, 904, 906 and 920 can be stored in the memory 806 of the set top box 601 and can be read and controlled in their execution by the CPU 805. The directory service 911 can run on one of the computers 650, 652 or 700 and can be stored in the hard disk drive 710 of the computer 700, for example, and be read and controlled in its execution by the CPU 705. Alternatively, the directory service 911 can be run on the set top box 601 or its function executed by the launcher 903.
In a further alternative arrangement, if the set-top-box 601 is not powerful enough to run the system 600 locally, only the I/O daemon 920 need run on the set-top-box 601 and the remainder of the architecture 900 (i.e. process components 901,
903, 904, 906 and 911) can be run remotely on the other servers (650, 652) which can be accessed via the network 720. In this instance, the I/O daemon 920 can be stored in the memory 806 of the set top box 601 and can be read and controlled in its execution by the CPU 805. Again, the functional parts of such a system can be divided as shown in FIG. 9. In this instance, the display 701 corresponds to an audio-visual output device (e.g. a television set).
The I/O daemon 920 is a process component that converts datagrams received from the reader 300 into a TCP/IP stream that can be sent to the event manager 901 and vice versa (e.g. when using a two-way protocol). The event manager 901 is configured to gather all events that are generated by the reader 300 and relayed by the I/O daemon 920. These events are then redistributed to the various process components 903, 904, 906 and 908 and running applications. The event manager 901 is also configured to check that an event has a valid header and correct data length. An "event", in this regard represents a single data transaction from the I/O daemon 920 or the launcher 903 or applications 904. The master launcher 908 can be used to start the launcher 903 corresponding to each of the event managers 901 if more than one event manager is running on the system 600. The launcher 903 is an application that starts other applications for a specific event manager 901. The launcher 903 starts and ends applications and can also start and end sessions. The launcher 903 also informs the event manager 901 when applications are starting and ending, and informs the applications 904 when they are gaining or losing focus, or when they need to exit. The display manager 906 selects which smart card application 904 is currently able to display output on the display device 701 (i.e. the "front" application).
The directory service 911 is configured to translate service identifiers that are stored on smart cards 100, into resource locators (e.g. a URL) that indicate the location of the services or the location of an application associated with a service. The directory service 911 is also configured to translate optional service data. The directory service 911 allows the launcher 903 associated with a particular card 100 to decide what to do with a resource locator, for example, download and run the associated application 904 or load the resource locator into a browser application.
The applications 904 associated with a particular smart card 100 can be started by the launcher 903 associated with that smart card 100 in response to a selection of one of the user interface elements 114, 154 of a corresponding smart card 100. Each application 904 can be a member of one or more application service groups. An application service group is comprised of a number of smart card applications 904 that act co-operatively, as opposed to merely simultaneously, to provide a particular set of functions. An application 904 can be specified to not be part of any service group in which case the application will never be run with other applications. An application can become part of a service group once the application is running and can remove itself from a service group when the application is the currently front application.
In a still further alternative arrangement, the process components 901 to 906 and 908 described above can be implemented in dedicated hardware (e.g. the set top box 601) as one or more integrated circuits performing the described functions or sub-functions. Such dedicated hardware may include graphic CPUs, digital signal CPUs, or one or more micro-CPUs and associated memories.
Typically, applications 904 are resident on the hard disk drive 710 and read and controlled in their execution by the CPU 705. Intermediate storage of programs and any data fetched from the network 720 can be accomplished using the semiconductor memory 706, possibly in concert with the hard disk drive 710. In some instances, the applications 904 will be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 711 or 712, or alternatively may be read from the network 720 via the modem device 716. Other mechanisms for loading the applications 904 into the computer system 700 from other computer readable medium include magnetic tape, a ROM or integrated circuit, a magneto-optical disk, a radio or infra-red transmission channel between the computer module 702 and another device, a computer readable card such as a smart card (not shown), a computer `Personal Computer Memory Card International Association (PCMCIA) card` (not shown), and the Internet and/or Intranets including email transmissions and information recorded on Websites and the like. The foregoing is merely exemplary of relevant computer readable media. Other computer readable media are also possible including combinations of those described above.
1.6 Smart Card Data Format
The smart card 100 generally stores a data structure in memory 219, 276 that describes various card properties and any user interface elements 114, 154 printed on the smart card 100. The smart card 100 can also include global properties that specify attributes such as information about the smart card 100, vendor and a service. Further, user-interface objects, as will be explained in detail below, can specify data to be associated with the user interface elements 114, 154 printed on the surface of a corresponding smart card 100.
For the memory card 100A, data conforming to the format to be described can be copied directly into the memory chip 219 of the smart card 100. For the CPU card 100B, data conforming to the format to be described can be stored in the storage means 276 as a file being one file of a file system implemented on the CPU card 100B. Such a file system will be described in detail below. In either case, to ensure that the cost of the smart card 100 can be kept to a minimum, the amount of data stored on the smart card 100 is kept to a minimum. For example, where the smart card 100 is being used as a music sampler and associated on-line service, the memory 219, 276 of the smart card 100 does not contain the music itself. The smart card 100
only contains data associated with the user interface in the form of the user interface elements 114, 154 and certain identifiers, which will be described in detail below. If the smart card 100 has limited storage capacity (e.g. in the case where the smart card 100 utilises a barcode), the smart code 100 may only include a card identifier as will be explained in detail below.
The user-interface objects referred to above can represent mapping data, which relate the user interface elements 114, 154 imprinted directly on a surface of the smart card 100, to commands or addresses (eg: Uniform Resource Locators (URLs)). The mapping data includes (X,Y) coordinates that typically define the size and location of user interface elements 114, 154 on the smart card 100. The user-interface objects are preferably stored in the memory 219, 276 of the smart card 100. Alternatively, the user-interface objects can be stored not on the smart card 100 itself, but in the system 600. For example, the smart card 100 can store, via the memory 219, 276 a barcode or a magnetic strip, a unique identifier, which is unique to smart cards 100 having substantially similar user interface elements 114, 154 and layout. The unique identifier together with the coordinates determined from the touch panel 308, as a result of a user press, can be transmitted by the reader 100 to the computer 700 or to the set top box 601, of the system 600.
The system 600 can have the user-interface objects stored on the computer 700, set top box 601 or server 650, which may thus be arranged to perform the mapping from the determined coordinates to a corresponding command, address or data relevant to a service associated with the smart card 100 and a user selection of one of the user interface elements 114, 154, in order to provide a desired function represented by the selected user interface elements. In this instance, the data related to the user selected user interface elements 114, 154 as described above takes the form of coordinates determined by the microcontroller 1044 of the reader 300 as a result of a user applying pressure to a portion of the touch panel 308 which overlays the desired user interface elements 114, 154.
Data stored in the smart card 100 includes a card header followed by zero or more objects as described in the following sections.
1.6.1 Card Header
FIG. 11 shows the data structure of a card header 1100 as stored in the smart card 100. The header 1100 includes a number of rows 1101, each of which represent four bytes of data. The data is preferably in `big endian` format. The complete header is 19 bytes long and includes the following fields (described in more detail in Table 1 below): (i) magic number field 1102, which includes a constant specifying a smart card as being a valid memory card 100A or CPU card 100B. For example, the magic number field 1102 can be used to check or verify that a propriety card belonging to a particular manufacture is being used; (ii) versions field 1103, which includes each version increment that specifies a change in the smart card layout that cannot be read by a reader 300 which is compatible with lower versions of the layout; (iii) reserved field 1104, this field is reserved for future use; (iv) flags field 1105, which includes flags for a smart card (see Table 2 below); (v) card identifier field
1110, which includes two fields--a service 1106 and a service specific field 1107. The service field 1106 identifies the service of a corresponding smart card 100 and the service specific field 1107 optionally contains a service-specific value; (vi) a number of objects field 1108, which includes a number value representing how many objects follow the header 1100. This field can be set to zero; and (vii) a checksum field 1109, which includes a card checksum of all data on a corresponding smart card
100 excluding the checksum itself.
Table 1 below provides a description of the content of the various (number) fields described with reference to FIG. 11.
TABLE-US-00001 TABLE 1 Field Number Description (Card Header) Magic Number Two byte magic number. A constant that specifies this as being a valid card. Currently defined as the ASCII value for `i` followed by the ASCII value for `C`. Version One byte version number. Each version increment specifies a change in the card layout that can not be read by a reader that is compatible with lower versions of the layout. This document describes version 1(0x01) of the card format. Reserved This data is reserved for future use. Its value must be set to zero. Flags Four bytes of flags for this card. (See Table 2). All non- assigned bits must be zero. Card Identifier Eight byte card identifier. Card identifiers include two fields - service identifier and service-specific identifier. The service identifier is five bytes and identifies the ser- vice associated with the card. The service-specific identifier is three bytes of service specific value. Number of One byte. The number of objects following this header. Objects Can be zero. Checksum Card checksum, 2 bytes. The card checksum is sixteen bit, unsigned integer sum of all data bytes on the card excluding the checksum.
The card identifier field 1110 comprises an eight-byte card identifier. The card identifier includes two portions (i.e. unit pieces of data), namely, a service identifier and a service-specific identifier. Preferably, the card identifier is arranged so that the service identifier occupies five bytes and the service-specific identifier occupies three bytes of the total card identifier value.
The service identifier contained in the field 1106 may be used to distinguish one service from another or distinguishes one vendor from another. That is, for example, a service can be associated with an application that provides the service to the user of a smart card 100 as distinct from a vendor who can provide multiple services to the user by providing multiple applications. The service identifier can be an identifier to identify the application to be used or application location (e.g. URL).
The card identifier can be used to configure generic smart cards for the system 600. Generic smart cards are smart cards 100 having a special service identifier that can be used to provide input to a current application already running. The special value for the service identifier, referred to as "the generic service identifier", is 0x0000000001, where `0x` represents hexadecimal notation (i.e. every two characters of the generic service identifier represent the value of a single byte). A generic smart card can be used to send data to a front application already running on the system 600. For example, a smart card 100 having a keypad user interface that can be used to send text input to an application which has focus or a smart card 100
with personal details that can also be used to submit the personal information stored on the smart card 100 to any application.
A smart card 100 identification authority can assign service identifiers to a vendor when the vendor registers a particular service.
The service-specific identifier contained in the field 1107, as described above, can be optionally used by the vendor of a particular service to provide predetermined functions associated with that particular service. The use of the service-specific identifier is substantially dependent upon an application 904 being executed on the system 600. For example, the service identifier together with the service-specific identifier can be used as a unique identifier for a card 100. This unique identifier can be used by an application 904 to gain or deny access to a specific feature associated with a particular service, to reproduce a specific-service identifier in a log file in order to confirm or verify that a particular smart card 100
having that value was used to access a service, and to provide a unique identifier that can be matched up with a corresponding value in a database in order to retrieve information about the user of the service (eg: name, address, credit card number etc).
Another example of a use for the service-specific identifier can include providing information about a mechanism or mode of distribution of the smart cards 100 (e.g. by mail, bus terminal kiosks, handed out on a train etc). Further, the service-specific identifier, can identify what data is to be loaded into the system 600 when a service is accessed.
The foregoing is not intended to be an exhaustive list of possible uses or applications of the service-specific identifier but a small sample of possible applications and there are many other applications of the service-specific identifier of field 1107.
1.6.2 Card Flags
The flags field 1105 of the header 1100 of FIG. 11 can include three flags.
For the memory card 100A and the CPU card 100B, the flags of the flags field 1105 are as follows: (i) Background beep; (ii) Move; and (iii) Don't Report Background Coordinates.
Table 2 below provides a description of each of the above flags (i) to (iii). The above flags (i) to (iii) affect the functions that the smart card 100 can perform in a reader 300, as is defined by the description of each flag.
TABLE-US-00002 TABLE 2 Name Description Value (hex) Background Causes the reader to provide audio feedback 0x0000 0001 Beep whenever the background is touched. Move Causes the reader to send all move events 0x0000 0002 from when the touch panel was pressed until the touch panel is released. Don't Report Causes the reader to suppress reporting of 0x0000 0004 Background the co-ordinates of all presses and releases Co-ordinates of the touch panel, when they correspond to the background, reporting them instead as (0xFF, 0xFF).
1.6.3 Objects
As shown in FIG. 12, immediately following the card header 1100 of FIG. 11 can be zero or more object structures 1213 defining the objects of a particular smart card 100 and forming part of the data stored on the smart card 100. Each object structure 1213 comprises four fields as follows: (i) a type field 1201; (ii) an object flags field 1203; (iii) a length field 1205; and (iv) a data field 1207.
The structure of the data field 1207 depends on the object type as will be described below.
Table 3 below shows a description of each of the fields 1201, 1203, 1205 and 1207 of the object structure 1213.
TABLE-US-00003 TABLE 3 Name Description (Object Structure) Length Type The type of object (see Table 5). 1 byte Object Flags The general object flags that are associated 1 byte with this object (see Table 4). Note: Additional flags specific to an object type are specified within the data field of the object. Length The length of the data following this object. 2 bytes This value can be zero. Data The data associated with this object. The Variable structure of this data is dependent on the type of object.
The flags field 1203 of the object structure 1213, preferably includes an inactive flag. Table 4 below shows a description of the inactive flag.
TABLE-US-00004 TABLE 4 Name Description (Pre-Object Flag Values) Value (hex) Inactive Indicates to the reader that the object is 0x01 valid but is to be ignored regardless of it's type.
For the smart card 100, there are preferably eight object types provided, as follows: (i) User Interface Element: Text; (ii) User Interface Element: Delegator; (iii) User Interface Element: Buffer (iv) Card Data; (v) Fixed Length Data; (vi) Reader Insert; (vii) No operation; and (viii) No operation (single byte). Table 5 shows a description of each of the above object types (i) to (viii).
TABLE-US-00005 TABLE 5 Name Description) Value (hex) No A single byte object that doesn't have a 0x00 operation standard object header. Used to fill spaces on (single the card that are too small for a normal object byte) header. No An object that is used to fill blocks of empty 0x01 Operation space on the card. User A user interface element with raw data. (inline) 0x10 Interface (file) 0x11 Element: Text User A user interface element which initiates (inline) 0x12 Interface buffered input mode. (CPU card only). (file) 0x13 Element: Buffer User A user interface element containing a command (inline 0x14 Interface to be invoked on another card resident (file) 0x15 Element: application (CPU card only). Delegator Card Contains data that relates specifically to this 0x20 Data card. Card data would normally be read by the reader and sent as part of the INSERT message on card insertion. Fixed An object that can be used to store fixed length 0x30 length blocks of data on the card. Data Reader An object that can be used to give instructions 0x40 Insert to the reader when the card is inserted.
1.6.3.1 User Interface Element Objects
Each of the user interface element objects of Table 5 define a rectangular area on a smart card 100 and some quantity of associated data that is used to generate an output when the user touches an area of the touch panel 308 over the corresponding rectangular area of the smart card 100. The origin for the coordinate mapping system is the top left of the smart card 100 in accordance with an International Organisation for Standardisation (ISO) standard smart card held in a portrait view with the chip contacts 218, 278 facing away from the viewer and towards the bottom of the smart card 100. For any reader 300 that does not use this card orientation, the values of corner points on the smart card 100 must be adjusted by the reader
300 for the memory card 100A or by the CPU 275 for the CPU card 100B, so as to report a correct "button" press.
The user interface element objects structure preferably has six fields as follows: (i) a flags field; (ii) an X1 field; (iii) an Y1 field; (iv) an X2 field; (v) a Y2 field; and (vi) a data field which typically includes data associated with the user interface element for example, a URL, a command, a character or name.
Table 6 shows a description of each of the above fields for the described user interface element object structure. A press on the touch panel 308 is defined to be inside an area defined by a particular user interface element corresponding to a user interface element object structure if: (i) the X value of the press location is greater than or equal to the X1 value of the associated user interface element object and is strictly less than the X2 value for that particular user interface element object; and (ii) the Y value for the press location is greater than or equal to the Y1 value of the particular user interface element object and strictly less than the Y2 value.
TABLE-US-00006 TABLE 6 Field Description (User Interface Object Structure) Size Flags Flags specific to this user interface element on the 1 byte card. X1 X value of the top-left hand corner co-ordinate of this 1 byte object's rectangle. Y1 Y value of the top-left hand corner co-ordinate of this 1 byte object's rectangle. X2 X value of the bottom-right hand corner co-ordinates 1 byte of this object's rectangle. Y2 Y value of the bottom-right hand corner co-ordinate of 1 byte this object's rectangle. Data Zero or more bytes of data associated with this object. Variable In memory cards, the actual data is always stored within this field. For CPU cards, this field may contain a file identifier which points to a file where the data is actually stored. The size of this field is determined by the object data size minus the combined size of the above fields.
Overlapping user interface elements are allowed. In this case, if a press is within the bounds of more than one user interface element then the object resulting from the press is determined by a Z order. The order of the user interface elements
114, 154 on the smart card 100 defines the Z ordering for all of the user interface elements on that particular smart card 100. The top user interface element is the first user interface element for a particular smart card 100. The bottom user interface element is the last user interface element for that particular smart card 100. This allows for non-rectangular areas to be defined. For example, to define an "L" shaped user interface element, a first user interface element object would be defined with zero bytes in the data field, and a second user interface element object would be defined to the left and below the first user interface element object but overlapping the first user interface element object. The second user interface element would contain the data that is to be associated with the "L" shaped user interface element.
The location of a press is reported in "fingels", which represent finger elements (analogous to "pixels" which represent picture elements). The height of a fingel is defined to be 1/256th of the length of an International Organisation for Standardisation (ISO) memory smart card and the width is defined to be 1/128th of the width of an International Standards Organisation memory smart card.
The behaviour associated with each user interface element 114, 154 may be modified using one or more flags. For both the memory card 100A and the CPU card 100B, each user interface element 154 preferably has seven associated flags as follows: (i) Beep; (ii) Move; (iii) Don't report coordinates; (iv) Auto repeat; (v) Do Not Send Data on Press; (vi) Do Not Send Data on Release; and (vii) Encrypt Out-going data. Table 7 shows a description for each of the user interface element flags (i) to (vii).
TABLE-US-00007 TABLE 7 Name Description Value Beep This flag causes the reader to beep when the user 0x01 interface element is pressed. Don't Report This flag instructs the reader to suppress reporting 0x04 Co-ordinates of the co-ordinates of the associated press or release, reporting them instead as (0xFF, 0xFF). Auto-repeat This element automatically repeats when the press 0x08 is held on the element. Don't Send This causes the associated user interface element 0x10 Data on not to send the data associated with this user Press interface element in the press event. The default is to send the data associated with the user interface element in the press event. Don't Send This causes this user interface element not to send 0x20 Data on the data associated with this user interface element Release in the release event. The default is to send the data associated with the user interface element in the release event. Encrypt This causes the data associated with the user 0x40 Outgoing interface element to be encrypted using a Data previously agreed upon session key. If no session key is present, no data is sent. (CPU cards only).
Data associated with a user interface element 114, 154 on the smart card 100 can be referenced as `Inline Data` which is stored directly in the data field of a user interface element. However, for the CPU card 100B, data associated with a user interface element can also be referenced as `File Data`. File data is stored in a separate elementary file in the storage means 276 of the microprocessor 259 and the structure of data field associated with such an elementary file is shown in Table 8.
TABLE-US-00008 TABLE 8 Name Length Description File_id 2 bytes The 16-bit ISO identifier corresponding to the required file Header variable A variable length header, which is prepended to the file contents in order to identify the user interface element. This may be empty.
1.6.3.2 Card Data
The card data object is used to store data, which is specific to a particular card 100. The data layout for this object has no fixed form. The contents of the card data object are sent from the reader 300 as part of an INSERT message when the smart card 100 is inserted into the reader 300.
1.6.3.4 Fixed Length Data
The fixed length data object is used to define a fixed length block on the smart card 100 that can be written to by the computer 700, for example.
1.6.3.5 Reader Insert
The reader insert object is used to store instructions for the reader 300 when a particular smart card 100 is inserted. This can be used, for example, to instruct the reader 300 to use a specific configuration of infra-red commands to allow communication with a specific set top box (e.g. 601) or TV.
1.6.3.6 No Operation
The No Operation object is used to fill in unused sections between other objects on a particular smart card 100. Any data stored in the no operation object is ignored by the reader 300. Any unused space at the end of the smart card 100 does not need to be filled in with a no operation object.
1.6.3.7 No Operation (One Byte)
The No Operation (One Byte) object is used to fill gaps between objects that are too small for a full object structure. These objects are only one byte long in total.
1.7 Reader Protocol
The reader 300 uses a datagram protocol that supports both uni-directional and bi-directional communication between the reader 300 and the set top box 601 or computer 700, for example. The format used for messages from the reader 300 as a result of user interactions with the smart card 100 are of a different format than those that are sent to the reader 300.
1.7.1 Incoming Message Types
There are at least seven message event types that can be sent by the reader 300. These message events are as follows: (i) INSERT: When a smart card 100 is inserted into the reader 300, and the smart card 100 is validated, an INSERT event is generated by the reader 300 and an associated message is transmitted. This message announces the smart card 100 to a remote module (e.g. the set top box 601). The INSERT message preferably can include the particular card identifier and allow applications to be started or fetched immediately upon the smart card 100 insertion rather than waiting until the first interaction takes place. The INSERT message preferably includes the contents of the card data object from the smart card 100 inserted into the reader 300 if an object of this type is present on the smart card 100. (ii) REMOVE: When a smart card 100 is removed from the reader 300, a corresponding REMOVE event is generated and a REMOVE message is sent to the particular remote module associated with the reader 300. Like the INSERT message, the associated card identifier can be transmitted along with the message. As the card identifier cannot be read from the now removed smart card 100, the card identifier is stored in the memory
1047 of the reader 300. This is a useful optimisation as the card identifier is required for all other messages and reading the card identifier from the smart card 100 each time the card identifier is required can be too slow. INSERT and REMOVE messages are not relied upon by the system 600 to control processing. The system 600 is configured to infer missing messages if a message is received and is not immediately expected. For example, if an application detects two INSERT messages in a row, then an application can assume that it has missed the REMOVE message associated with the smart card 100 of the first INSERT message, as typically two smart cards 100 are not inserted into the reader 300 at one time. The application can then take whatever action is required prior to processing the second INSERT message.
Another example of where a missing message can occur is where a hand-held, infrared connected reader 300 as shown in FIG. 6(b), as compared with a wired reader 300 as shown in FIG. 6(a), is being used. Often a user does not point the reader 300
directly at a remote module when inserting or removing cards. This problem can be corrected by the system 600 inferring the INSERT or REMOVE operations based on differing card identifiers in consecutive PRESS and RELEASE pairs. (iii) BAD CARD: If an invalid smart card 100 is inserted, then the reader 300 is preferably configured to generate a BAD CARD event and to send a BAD CARD message. This message allows an associated remote module to take some action to alert the user to the invalid smart card
100. (iv) PRESS: When a touch is detected by the reader 300, a PRESS event is generated and a PRESS message is sent to an associated remote module. The PRESS message can contain details of an associated memory card, the position of the press and the data associated with the user-interface element at that particular position. If there is no user interface element defined for that position (including if there is no user interface element defined on the smart card 100 at all) a PRESS message is sent containing details of the associated smart card 100 and the position of the press. If there is no card present in the reader 300 when a PRESS event is generated then a PRESS message is sent containing the special "NO_CARD" identifier (i.e. eight bytes of zero--0x00) and the position of the press. (v) RELEASE: A RELEASE event complements the PRESS event and a RELEASE message can be sent in order to inform an application program of the system 600 that a PRESS has been lifted. Every PRESS event preferably has a corresponding RELEASE event. Readers can allow multiple presses to be registered or provide other events that may occur between PRESS and RELEASE messages. (vi) MOVE: If, after processing a PRESS event, the touch position changes by a certain amount then the finger (or whatever is being used to touch the smart card 100) is assumed to be moving. MOVE EVENTS are generated and MOVE messages are sent until the touch is lifted. MOVE events auto-repeat by re-sending the last MOVE messages when the touch position remains stationary. The repeated sending finishes when the touch is lifted and a corresponding RELEASE message is sent. Unlike PRESS and RELEASE events there is no user-interface object involved with MOVE events. (vii) LOW BATT: A LOW BATT event is generated and a LOW BATT message is sent when the battery 1053 in the reader 300 is getting low. This message is sent after user interactions to increase the chance that the message will be received by the rest of the system
600. The sending of the LOW BATT message does not prevent the reader 300 from entering a low power state.
As described above, the card identifier is included in every INSERT, REMOVE, PRESS, RELEASE and MOVE message sent from the reader 300 to the computer 100 or set-top box 601. As an alternative, the card identifier can be sent in connection with an INSERT message only. In this instance, upon insertion of a new smart card 100, the reader 300 generates a session identifier. The session identifier is configured to identify a current session of a card insertion. The session identifier, for example, can be a pseudo-random number represented with two bytes of data or the session identifier can be a number that is incremented each time a smart card 100 is inserted and reset to zero when a predetermined value is reached. In this case, the reader 300 sends an INSERT message to the computer 700 or the set-top box 601, which includes a card identifier as previously described above and a session identifier which is generated for each new smart card 100 insertion. All subsequent PRESS, RELEASE and MOVE messages need not include the card identifier but will include the session identifier and user interface element object data or press coordinates previously described.
When using a session identifier, the system 600 operates as described above with reference to FIGS. 6(a) and 6(b), except that the event manager 901, upon receiving an INSERT message from the reader 300, stores the session identifier as the current session identifier and a card identifier as the current card identifier. When the event manager 901 receives a PRESS, RELEASE or MOVE message, the event manager 901 checks that the session identifier is equal to the current session identifier. If so, the event manager 901 sets a card identifier used in all messages to the current card identifier. Otherwise, if the session identifier is not equal to the current session identifier, the event manager 901 informs the user, via the display manager
306, and the display device 101, that a message has been received without a corresponding INSERT message. The user, for example, is then requested to remove and reinsert the card 100.
1.7.2 Outgoing Message Types
There are at least two message types that can be sent to the reader 300 from a remote module such as the set top box 601, for example. In both cases, the reader 300 is expected to send a reply to the message. These message types are as follows: (i) STATUS: detailed information regarding the status of the reader 300 can be requested by the event manager 901 by sending a STATUS message; and (ii) EXCHANGE application protocol data unit: this message sends part of an application protocol data unit to a CPU card (e.g. the card 100B). An entire application protocol data unit EXCHANGE request is preferably split up into multiple sequential messages. The length of these messages (including a header and footer) preferably does not exceed the buffer capacity of the reader 300., This buffer capacity can be determined using the STATUS message. 1.7.3 Data Formats
The data format of the reader 300 protocol used in the system 600 is a fixed size header followed by a variable length data field. The variable length data field can be zero bytes or more in length, followed by an eight bit check-sum and complement.
1.7.4 Incoming Message Header
The incoming message header is preferably of a fixed length and is prepended to (i.e. appended to, but in front of) all messages sent from the reader 300 to a set top box 601, for example. It is necessary to keep the incoming message header as small as possible due to any bandwidth restrictions that may be imposed. Table 9 below shows the format of the incoming message header that is sent from a reader 300 to a remote module such as the set top-box 601. The service and service-specific identifier are the same for a given smart card 100. A service specific identifier is preferably set by a vendor for use with a particular application. The reader identifier (ID) of Table 9 is also in the header of each message. The reader identifier can be used by an application 304 to distinguish different users, for example, in a multi-player game application.
TABLE-US-00009 TABLE 9 Field Description (Incoming Message Header Format) Bytes Preamble Preamble to the message. Value is always 0xAA 2 0x55 (bit sequence 10101010 01010101). This is to make it easier for the event manager 901 to find the beginning of a message. Version The version of a user interface card infrared 1 message protocol this messages uses. This version of the protocol is version 1(0x01 in the version field) Type Type of message. This is one of the values given in 1 Table
10. Reader ID The 16 bit ID of the reader that sent the message. 2 This number is a pseudo-random generated number that is changed when the battery is replaced in the reader. This is needed to distinguish readers when multiple readers are being used with applications. Service Service identifier as stored on the card. 5 Service- Service-specific identifier as stored on the card. 3 specific
Table 10 shows a table listing the message event types that have been described above.
TABLE-US-00010 TABLE 10 Name Description (Message Type Codes) Code INSERT A card has been inserted into the reader. `I` REMOVE The card has been removed from the reader. `E` PRESS The touch panel has been pressed. `P` RELEASE The press on the touch panel has been released. `R` MOVE The press position has moved but the press has `M` not been released. BADCARD A card has been inserted however it has not `B` passed validation. LOW_BATT The battery in the reader is getting flat. `L`
1.7.3.1 Simple Messages
A number of message types are considered simple in that they consist solely of the incoming message header described above, followed by the message checksum byte and its complement. For example, a BADCARD message, a LOW_BATT message and a REMOVE message are considered to be simple messages. Table 11 shows the format of a simple message.
TABLE-US-00011 TABLE 11 Field Description (Simple Message Format) Bytes Header Incoming message header as defined in Table 9. 14 Checksum Message checksum. This is the sum of all the bytes 1 in the message. Checksum' The 1's complement of the checksum. 1
1.7.3.2 MOVE Messages
MOVE messages are formed of the incoming message header described above followed by two fields defining the coordinates of the touch position on the touch panel 308 of the reader 300. Table 12 shows the format of a MOVE message.
TABLE-US-00012 TABLE 12 Field Description (Move Message Format) Bytes Header Incoming message header as defined in Table 9. 14 X The X co-ordinate of the touch position. 1 Y The Y co-ordinate of the touch position. 1 Checksum Message checksum. This is the sum of all the bytes 1 in the message. Checksum' The 1's complement of the checksum. 1
1.7.3.3 PRESS and RELEASE Messages
Table 13, below, shows the format of PRESS and RELEASE messages. PRESS and RELEASE messages, like MOVE messages contain the incoming message header and touch coordinates. In addition, PRESS and RELEASE messages send data associated with a user-interface element 114, 154 if the touch position matches a user-interface element object defined on the smart card 100. This data is of variable length, the actual size being defined by a corresponding smart card 100. If the touched position does not match a user-interface element object defined on the smart card 100 (including if no user-interface elements are defined on the smart card 100), zero bytes of data associated with user interface elements are sent. If there is no smart card 100 in the reader 300 then the service identifiers are all set to zero (ie 0x00) and zero bytes of data associated with the user-interface elements are transmitted to the remote module (e.g. the set top box 601). The data associated with the user interface element normally corresponds to the data associated with the user interface element defined on the smart card 100 but may be modified or generated by processing on the smart card 100 or reader 300.
TABLE-US-00013 TABLE 13 Field Description (Press and Release Message Format) Bytes Header Incoming message header as defined by Table 9. 14 X The X co-ordinate of the touch position. 1 Y The Y co-ordinate of the touch position. 1 Length The number of bytes of data. Can be zero. 2 Data The data associated with the user interface Length element. Checksum Message checksum. This is the sum of all the 1 bytes in the message. Checksum' The 1's complement of the checksum. 1
1.7.4 Outgoing Message Header
The outgoing message header is preferably of a fixed length and is prepended to (i.e. appended to, but in front of) all messages sent to the reader 300 from a set top box 601, for example. The outgoing message header is preferably configured as small as possible due to any bandwidth restrictions that may be imposed. Table 11, below, shows the format of the outgoing message header that is sent to a reader 300 from a remote module such as the set top-box 601. The reader identifier (ID) of Table
14 is also in the outgoing header of each message, and matches the reader identifier of the reader 300 that a corresponding message is intended for.
TABLE-US-00014 TABLE 14 Field Description (Outgoing message header Format) Bytes Preamble Preamble to the message. Value is always 0xAA 2 0x55 (bit sequence 10101010 01010101). This is to make it easier for the event manager 901 to find the beginning of a message. Version The version of the user interface card infrared 1 message protocol this messages uses. This version of the protocol is version 1(0x01 in the version field) Type Type of message. This is one of the values given in 1
Table 10. Reader ID The 16 bit id of the reader that is to receive the 2 message
Table 15, below, lists the message event types that have been described above. The codes for incoming replies (i.e., replies from a remote module such as the set top box 601) are equivalent to the codes for their corresponding outgoing requests (i.e., requests sent from the reader 300 to a remote module), but in lower case.
TABLE-US-00015 TABLE 15 Name Description Code Status Information is requested about the current `S` (`s`) status of the reader. Exchange CPU card only: the reader is instructed to `A` (`a`) Application forward Application Protocol Data Unit data Protocol Data to the card and return the Unit response when done.
Substantially all incoming messages follow the incoming message hearder format.
1.7.5 INSERT Messages
INSERT messages are formed of the message header (i.e., the incoming message header described above) and the contents of the card data object from an inserted smart card 100. Table 16 below shows the format of an INSERT message.
TABLE-US-00016 TABLE 16 Field Description (INSERT Message Format) Bytes Header Message header as defined in Table 9. 14 Length The number of bytes of data. Can be zero. 2 Data The data from a Card Data object on the card. Length Checksum Message checksum. This is the sum of all the 1 bytes in a message. Checksum' The 1's complement of the checksum. 1
FIG. 13 is a data flow diagram showing the flow of the above-described messages within the system 600 for a smart card 100. As seen in FIG. 27, the card header 1100 and object structure 1213 are read by the CPU 1045 of the reader 300 which sends a corresponding INSERT, REMOVE, PRESS, RELEASE, MOVE, BADCARD or LOW BAT message to the event manager 901 via the I/O daemon 920. The event manager 901 can have up to twenty-one core messages, which are sent to and received from the master launcher 902, launcher 903 and applications 904.
1.7.6 STATUS Messages
STATUS request messages are formed of the message header described above and the contents of the card data object from an inserted smart card 100.
Information requested by a STATUS request message is indicated by a bit field within the message body. The bit field is preferably at least one byte long. The structure of a STATUS request message body is shown in Table 17, as follows:
TABLE-US-00017 TABLE 17 Field Description Bytes Count The number of bytes in the following bitfield. 1 Bitfield Encodes the parameters to be returned (see Table 1 or more 10) Checksum Message checksum. This is the sum of all the 1 bytes in the message. Checksum The 1's complement of the checksum 1
A reply message body essentially contains a sequence of the structure shown in Table 18, as follows:
TABLE-US-00018 TABLE 18 Field Description Bytes Length The length of the current data element 2 Data Requested data Length
The sequence of elements of Table 18 contains requested data in order, from the first requested field (i.e., most significant `1` of the first byte) to the last requested field (i.e., least significant `1` of the last byte). A 2 byte length field precedes each data element.
The reply is followed by the message checksum and the 1's complement of the message checksum.
The first request parameter byte contains flags, as shown in Table 19, below:
TABLE-US-00019 TABLE 19 Value Name Description 0x80 Firmware Requests the firmware version of the reader version 0x40 Reader Requests the size of the reader's message input buffer buffer 0x20 Initial Requests the sequence number currently expected sequence by the reader for other outgoing commands. number 0x10 Card Requests the type of card (if present). 1 byte type response: 0x00 = no card 0x08 = I2C (S = 8) memory card 0x09 = 3-wire bus (S = 9) memory card 0x0a = 2-wire bus (S = A) memory card 0x10 = T = 0 protocol CPU card 0x11 = T = 1 protocol CPU card 0xff = bad card 0x80 Card Requests the answer-to-reset of the card. With ATR some combinations of readers and cards, this field (Answer- might be impossible to return. In this instance, no to-Reset) data is returned for this field. 0x04 Card Requests the manufacturer data associated with Manu- the currently inserted card. With some facturer combinations of readers and cards, this field might data be impossible to return. In this instance, no data is returned for this field. 0x02 User Requests the number of bytes contained within the Interface User Interface Card image on the currently (UI) card inserted card. If a card is not present or bad, or this image information is otherwise not available, no data is size returned. Otherwise, the length of the response is always 2 bytes, in big-endian (network) byte order. 0x01 User Requests the entire header of the currently inserted Interface card, if present. If a card is not present or bad, no Card data is returned. header
1.7.7 Exchange Application Protocol Data Unit Message
An application protocol data unit exchange request is preferably split up into multiple sequential messages. The length of such messages (including header and footer) preferably does not exceed the buffer capacity of the reader 300. This buffer capacity can be determined using the STATUS command.
The structure of the exchange request message body is shown in Table 20, as follows:
TABLE-US-00020 TABLE 20 Field Description Bytes Sequence The sequence number of this message 1 number Card ID Card ID as stored on the card. Variable Data length The length of the following field Variable Application Part of the application protocol data unit to be Data Protocol sent to the application. This field is coded length Data Unit according to the structure defined in sections data 5.3 of "ISO/IEC 7816-4 Standards, Part 4: Electronic Signals and Transmission Protocol" [hereinafter referred to as the `ISO 7816-4 standards`]. Checksum Message Checksum. This is the sum of all the 1 bytes in the message. Checksum' The 1's complement of the checksum 1
The reply message body has the following structure as shown in Table 21, below:
TABLE-US-00021 TABLE 21 Field Description Bytes Status Code 0 on successful completion. 1 Length Card ID as stored on the card. Variable Response The length of the following field Length Checksum Part of the application protocol data 1 unit to be sent to the application. This field is coded according to the structure defined in section 5.3 of ISO 7816-4. Checksum' Message Checksum. This is the sum 1 of all the bytes in the message.
If the status code field of the exchange request message body indicates that more command data is required, a subsequent message is expected containing the next block of command data.
Essentially, the exchange request message provides a mechanism whereby a remote application executing on a remote module such as the server 652, can directly issue commands to the card 100B. Alternatively, a remote application running on a computer 700 or set top box 601 can directly issue commands to the card 100B. Such a remote application can communicate with either the user interface card resident application (i.e., the application program executing on the CPU card 100B that provides the user interface functions of the CPU card 100B) or other applications stored on the card 100B, in order, for example, to perform financial transactions.
In order for a remote application to communicate with another card-resident application, a channel to the card-resident application is established through the user interface card resident application. Such a channel is established by the remote application sending a CREATE CHANNEL command and sending subsequent application protocol data units with an associated class byte set to indicate channel 1. The CREATE CHANNEL command will be described in detail below.
1.8 Example
The operation of the system 600 will now be further explained with reference to the following example. The system 600 is customisable by virtue of a user being able to utilise a number of different smart cards 100 to perform corresponding different operations. For example, with particular reference to the system 600B, FIG. 14(a) shows a memory card 100C which according to the user interface elements 1414 printed thereon is configured for the retrieval of on-line music associated with an Internet site entitled "Blues Guitar Masters". The on-line music can be accessed over the system 600B using the memory card 100C and then purchased using a CPU card 100D configured for use with an electronic banking application, as will be explained below with reference to FIGS. 15(a) and 15(b).
Alternatively, other functions may be performed on the system 600B, using different smart cards 100, such as home shopping, ordering home delivery fast food such a pizzas, and the like. In each instance, insertion of an appropriate smart card
100 into the reader 300 causes a corresponding computer application to commence operation, either within the set-top box 601 or the computer system 700, in order to service user commands entered via the reader 300 and to return appropriate information for audio-visual feedback to the user.
For the memory card 100C, on-line music is provided as data to the set-top box 601 which permits reproduction of audio and any related visual images on the output device 616 or the display 701 of the computer system 700. The user interface elements 1414 of the memory card 100C are in the form of a "play button" 1401, a "rewind button" 1403, a "fast forward button" 1405, a "stop button" 1407, a "select button" 1409, a "record button" 1411 and a two-way directional controller 1413, printed on a front face 1416 of the memory card 100C.
FIG. 14(b) is a table showing user interface element objects (e.g. 1431) associated with each of the user interface elements 1401 to 1417. The user interface element objects (e.g. 1431) are stored in a memory (not shown) formed within the memory card 100C similar to the memory 219 of the memory card 100A. As described above with reference to Table 6 and as shown in FIG. 14(b), each of the user interface element objects (e.g. 1431) has six fields being a flags field 1420, an X1 field 1421, a Y1
field 1422, an X2 field 1423, a Y2 field 1424 and a data field 1425, describing the position of and data associated with a corresponding user interface element. For example, the flags field 1420 for the select button 1409 is a one byte field set to a hexadecimal value of `0x020` (0x representing hexadecimal notation), indicating that data associated with the select button 1409 is not to be sent in a release event, as described above with reference to Table 7. The X1 field 1421 associated with the select button 1409 is a one byte field set to a value of `0007` indicating the coordinate value of the bottom left hand point 1431 of the user interface element 1409 with respect to the top left point 1433 of the memory card 100C, as described above with reference to Table 6. The data field 1425 is a variable size field which in the case of the select button 1409 is a value corresponding to an `Enter` and/or `Carriage Return` function.
The memory card 100C also includes a card data object as described above with reference to Table 5. The card data object contains data that relates specifically to a particular smart card 100 and is normally sent as part of an INSERT message, upon the smart card 100 being inserted into the reader 300. In the case of the memory card 100C, the card data object indicates a URL, `www.bluesguitarmasters.com`, corresponding to the address of the `Blues Guitar Masters` Internet site. A person skilled in the relevant art would appreciate that the URL is stored in the memory of the memory card 100C in a digital format corresponding to the American Standard Code for Information Interchange (ASCII) values of the characters making up the URL. Alternatively, a card identifier can be stored in the memory of the memory card 100C and can be mapped to the URL by the directory service 911.
The memory card 100C also includes a card identifier, as described with reference to Table 1, stored in the memory of the memory card 100C. The card identifier includes a service identifier which in the case of the memory card 100C can be mapped to the URL, `www.bluesguitarmasters.com`, corresponding to the address of the `Blues Guitar Masters` Internet site by the directory service 911. The card identifier also includes a service-specific identifier which in this case is a three-byte vendor identifier related to the vendor of the Blues Guitar Masters Internet site. The service-specific identifier can be assigned by the provider of the service (e.g. the vendor of the Blues Guitar Masters Internet site), and can be equal to any particular three-byte value. Each card 100 associated with the `Blues Guitar Masters` Internet site, for example, can have a different service-specific identifier.
For the CPU card 100D, the user interface elements 1514 are in the form of a numerical keypad 1560, an "OK button" 1562, a "cancel button" 1564, a "clear button" 1566, a "backspace button" 1568, and a four way directional controller 1570 printed on the front face 1556 thereof.
Similar to the memory card 100C, each of the user interface elements 1514 of the CPU card 100D has at least one associated user interface element object (e.g. 1531) stored in a storage means (not shown) formed within the CPU card 100D similar to the storage means 276 of the CPU card 100B. Again, as described above with reference to Table 6 and as shown in FIG. 15(b), each of the user interface element objects (e.g. 1531) has six fields being a flags field 1520, an X1 field 1521, a Y1 field
1522, an X2 field 1523, a Y2 field 1524 and a data field 1525, describing the position of and data associated with a corresponding user interface element. For example, the X1 field 1521 associated with the "number 2 button" 1540 of the numerical keypad
1560, is a one byte field set to a value of "0005" indicating the coordinate value of the bottom left hand point 1541 of the user interface element 1540 with respect to the top left point 1533 of the CPU card 100D. The data field 1525 of the "number 2
button" 1540 is a variable size field which in the case of the CPU card 100D value corresponds to a hexadecimal representation corresponding to the ASCII value of the character `2`.
The CPU card 100D also includes a card data object, as described above with reference to Table 5. In the case of the CPU card 100D, the card data object indicates a URL (e.g. www.anz.com), corresponding to the address of an electronic banking Internet page. A person skilled in the relevant art would appreciate that the URL is stored in the storage means of the CPU card 100D in a digital format corresponding to the ASCII values of the characters making up the URL.
Similar to the memory card 100C, the CPU card 100D also includes a card identifier, as described with reference to a Table 1 stored in the storage means of the CPU card 100D. The card identifier includes a service identifier, which in the case of the CPU card 100D can be mapped to the URL corresponding to the electronic banking application (e.g. www.anz.com). The card identifier also includes a service-specific identifier, which in this case is a three-byte vendor identifier. The service-specific identifier can be related to the vendor of the electronic banking package (e.g. the Australia New Zealand Banking Group Limited). Again, each CPU card 100B associated with the electronic banking package, for example, can have a different service-specific identifier.
FIG. 16 is a flow diagram showing the steps 1600 performed by a user in order to retrieve on-line music associated with the Blues Guitar Masters Internet site, over the card interface system 600B. At the initial step 1601, the user inserts the memory card 100C into the reader 300. As will be explained in further detail later in this document, having inserted the memory card 100C into the reader 300, an application associated with the Blues Guitar Masters Internet page commences, for example on the server computer 650, and returns to the set-top box 601 for display on the output device 616 a first menu screen 1720, as seen in FIG. 17(a), relating to a function to be performed, in this case a selection of Blues Guitar Masters. Then at the next step 1603, using the reader 300 to select the two-way directional controller 1413, the user scrolls through the various offerings to make a desired selection, in this case for an artist called Young Dead Guy. In response to the user's selection, a further menu screen 1722, as seen in FIG. 17(b), is then displayed on the output device 616 advising the user of the possible selections that may be made. At the next step 1605, the user scrolls the menu screen 1722 by selecting the two-way directional controller 1413, and makes a further desired selection. In response to the user's selection at step 1605, a further menu screen 1724 is then displayed on the output device 616 as seen in FIG. 17(c) advising the user of the further possible selections that may be made.
In accordance with this example, the user can access a free sample video clip or a full concert music video corresponding to the selection at step 1605, depending on the `Quality of Service` that the user