Card for service access

An interface card comprising a substrate with indicia formed thereon. The card is configured for insertion into a read device. The read device has a substantially transparent touch sensitive membrane arranged to overlay the interface card so as to present the indicia to a user of the read device through the membrane. The read device also comprises a memory for storing a service identifier for identifying a service to be received from an external device according to indicia selected by the user and data stored in the memory and associated with the indicia.

 

1. An interface card comprising:

a substrate with a plurality of indicia formed thereon, said card being configured for insertion into a receptacle of a card read device; and

a memory for storing first data identifying one of said indicia, said first data being transmitted to a service providing apparatus upon selection of said one indicia, wherein second data identifying said interface card is transmitted to said service providing apparatus multiple times between an insertion and a subsequent removal of said interface card from said receptacle of said card read device, said service providing apparatus being configured to provide a service based on said first data and said second data.

2. An interface card according to claim 1, wherein said second data is transmitted to said service providing apparatus upon selection of said one indicia.

3. An interface card according to claim 1, wherein said second data is transmitted to said service providing apparatus upon said selection of said indicia being released.

4. An interface card according to claim 1, wherein said second data is transmitted to said service providing apparatus upon said interface card being inserted into said card read device.

5. An interface card according to claim 1, wherein said second data is transmitted to said service providing apparatus upon said interface card being removed from said card read device.

6. An interface card according to claim 1, wherein said second data is transmitted to said service providing apparatus upon a position of said indicia selection moving.

7. An interface card according to claim 6, wherein said second data is a service identifier.

8. An interface card according to claim 7, wherein said service identifier is set by a vendor for us by an application.

9. An interface card according to claim 8, wherein said service identifier is assigned to said vendor by a central authority.

10. An interface card according to claim 1, wherein said second data is a pseudo-random number.

11. An interface card according to claim 1, wherein said second data is incremented each time said control template is inserted into said receptacle.

12. An interface card according to claim 1, wherein said service providing apparatus is a personal computer.

13. A control template configured for insertion into a receptacle of a card read device, said template comprising:

an electronic card formed of a substrate having associated therewith a memory device;

a plurality of indicia arbitrarily formed on said substrate; and

first data stored within said memory device, said first data identifying one of said indicia and being transmitted to a service providing apparatus upon selection of said one indicia, wherein second data identifying said control template is transmitted to said service providing apparatus multiple times between an insertion and a subsequent removal of said control template from said receptacle of said card read device, said service providing apparatus being configured to provide a service based on said first data and said second data.

14. A control template according to claim 13, wherein said second data is transmitted to said service providing apparatus upon selection of said one indicia.

15. A control template according to claim 13, wherein said second data is transmitted to said service providing apparatus upon said selection of said indicia being released.

16. A control template according to claim 13, wherein said second data is transmitted to said service providing apparatus upon said electronic card being inserted into said card read device.

17. A control template according to claim 13, wherein said second data is stored in said memory device of said control template.

18. A control template according to claim 13, wherein said service providing apparatus is a set-top-box.

19. A method of providing a service, to be received from a service providing apparatus, using an interface card, said interface card comprising a substrate with a plurality of indicia formed thereof and being configured for insertion into a receptacle of a card read device, said method comprising the steps of:

transmitting first data identifying one of said indicia to said service providing apparatus upon selection of said one indicia, and

transmitting second data identifying the interface card to said service providing apparatus multiple times between an insertion and a subsequent removal of said interface card from said receptacle of said card read device, wherein said service is provided by said service providing apparatus based on said first data and said second data.

20. A method according to claim 19, wherein said second data is transmitted to said service providing apparatus upon selection of said one indicia.

21. A method according to claim 19, wherein said second data is transmitted to said service providing apparatus upon said selection of said indicia being released.

22. A method according to claim 19, wherein said second data is transmitted to said service providing apparatus upon said interface card being inserted into said card read device.

23. A method according to claim 19, wherein said second data is transmitted to said service providing apparatus upon said interface card being removed from said card read device.

24. A method according to claim 19, wherein said second data is transmitted to said service providing apparatus upon a position of said indicia selection moving.

25. A method according to claim 19, wherein said second data is a service identifier.

26. A method according to claim 25, wherein said service identifier is set by a vendor for use by an application.

27. A program that when executed by a computer performs a method for providing a service, to received from a service providing apparatus, using an interface card, said interface card comprising a substrate a plurality of indicia formed thereon and being configured for insertion into a receptacle of a card read device, said program comprising the steps of:

transmitting first data identifying one of said indicia to said service providing apparatus upon selection of said one indicia; and

transmitting second data identifying the interface card to said service providing apparatus multiple times between an insertion and a subsequent removal of said interface card from said receptacle of said card read device, said service being provided by said service providing apparatus based on said first data and said second data.

28. A program according to claim 27, wherein said second data is transmitted to said service providing apparatus upon selection of said one indicia.

29. A program according to claim 27, wherein said second data is transmitted to said service providing apparatus upon said selection of said indicia being released.

30. A program according to claim 27, wherein said second data is transmitted to said service providing apparatus upon said interface card being inserted into said card read device.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a control template or smart card for use with a remote reader device and, in particular, to a card interface system for providing a service. The invention also relates to a computer program product including a computer readable medium having recorded thereon a computer program for a card interface system.

BACKGROUND ART

Control pads of various types are known and used across a relatively wide variety of fields. Typically, such pads include one or more keys, buttons or pressure responsive areas which, upon application of suitable pressure by a user, generate a signal which is supplied to associated control circuitry.

Unfortunately, prior art control pads are somewhat limited, in that they only allow for a single arrangement of keys, buttons or pressure sensitive areas. Standard layouts rarely exist in a given field, and so a user is frequently compelled to learn a new layout with each control pad they use. For example many automatic teller machines ("ATMs") and electronic funds transfer at point of sale ("EFTPOS") devices use different layouts, notwithstanding their relatively similar data entry requirements. This can be potentially confusing for a user who must determine, for each control pad, the location of buttons required to be depressed. The problem is exacerbated by the fact that such control pads frequently offer more options than the user is interested in, or even able to use.

Overlay templates for computer keyboards and the like are known. However these are relatively inflexible in terms of design and require a user to correctly configure a system with which the keyboard is associated, each time the overlay is to be used.

One known system involves a smart card reading device intended for the remote control of equipment. Such, for example, allows a television manufacturer, to manufacture a card and supply same together with a remote control housing and a television receiver. A customer is then able to utilise the housing, in conjunction with the card, as a remote control device for the television receiver. In this way the television manufacturer or the radio manufacturer need not manufacture a specific remote control device for their product, but can utilise the remote control housing in conjunction with their specific card. However, the above described concept suffers from the disadvantage in that control data (e.g. PLAY, RECORD, REWIND commands etc.,) stored upon the card, and to be used for controlling an associated apparatus, comes from the manufacturer of the apparatus and is thus limited in its application.

Another known system involves an operating card reading device known as a 'remote commander' used for remote-controlling a video device, audio device etc. The operating card of this known system includes a card identification mechanism for identifying which mode the remote commander is operating in and as such what control data is to be transmitted from the remote commander. The operating card identification mechanism can be in the form of either electrodes/notches formed on side surfaces of the cards or identification information stored within the operating cards. The operating card identification mechanism can be configured in order to enable the remote commander to send commands for either a video tape recorder or for a television receiver, depending on the configuration of the identification mechanism. Again, this known system suffers from the disadvantage in that control data (e.g. PLAY, RECORD, REWIND commands etc.,) to be used for controlling the video tape recorder or television, comes from the manufacturer of the apparatus and is thus limited in its application. Further, the operating card identification mechanism must be configured each time the user wishes to change the apparatus to be controlled and is restricted to the operating card such that the identification mechanism can not be used to interact with the video device, audio device etc., to be controlled.

Still another known smart card system includes optics for receiving information from a television channel and a modem for providing real-time two way communication with an application running on a remote service provider. This known smart card system is used for remote service transactions such as an existing home shopping application. In accordance with this known system, information including home shopping program information, an item name, an item description, an item price and item commercial and programming re-run times, can be down-loaded to a smart card. The smart card can then use the access information along with the modem of the smart card to automatically dial a home shopping program automated service computer to place an order. However, again this system is limited in its application since the access information must be down-loaded to the smart card each time the smart card is to be used to purchase an item and can only be used to purchase the item specified by the item name and description.

The above-described systems all lack flexibility and are all limited in their respective applications. These systems are all used with pre-running applications and there is no interaction with the application other than that specified by the manufacturer.

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 an interface card comprising:

a substrate with indicia formed thereon, said card being configured for insertion into a read device, said read device having a substantially transparent touch sensitive membrane arranged to overlay said interface card so as to present said indicia to a user of said read device through said membrane; and

a memory for storing a service identifier for identifying a service to be received from an external device according to indicia selected by the user and data stored in said memory and associated with the indicia.

According to another aspect of the present invention there is provided a control template configured for insertion into a read device, said template comprising:

an electronic card formed of a substrate having associated therewith a memory device;

a plurality of indicia arbitrarily on said substrate; and

data stored within said memory device, said data defining at least a mapped position of each of said indicium relative to the substrate, and a service identifier, said service identifier being for identifying a service to be provided by a peripheral device upon receipt of further data from said read device according to at least one of said indicia selected by said user.

According to still another aspect of the present invention there is provided an interface card comprising:

a substrate with indicia formed thereon, said card being configured for insertion into a read device having a substantially transparent touch sensitive membrane arranged to overlay said interface card upon said card being received therein, whereby at least card said indicia can be viewed through said touch sensitive membrane; and

a memory for storing at least a service identifier for identifying a service to be provided by an external device, said service being associated with indicia selected by the user and further said data stored in said memory.

According to still another aspect of the present invention there is provided detachable interface card having a substrate and an indicia formed on said substrate, said card being configured for insertion into a read device, said card comprising:

a memory for storing a service identifier for identifying a service to be received from an external device according to a user selected indicia and data associated with indicia which is used to access said external device.

According to still another aspect of the present invention there is provided detachable interface card being configured for insertion into a read device, said card comprising:

a memory for storing a information that affects function that said card performs in said read device, wherein said read device performs the functions based on said information.

According to still another aspect of the present invention there is provided method of providing a service to be received from an external device using an interface card, said interface card comprising a substrate with indicia formed thereon and being configured for insertion into a read device, said method comprising at least the step of:

accessing a memory storing a service identifier for identifying a service to be received from an external device according to a user selected indicia and data associated with said selected indicia, said data being used to access said external device.

According to one aspect of the present invention there is provided a program for providing a service to be received from an external device using an interface card, said interface card comprising a substrate with indicia formed thereon and being configured for insertion into a read device, said program comprising at least:

code for accessing a memory storing a service identifier for identifying a service to be received from an external device according to a user selected indicia and data associated with said selected indicia, said data being used to access said external device.

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 is a perspective view of a read device and an associated card;

FIG. 2 is a perspective view of an opposite side of the card shown in FIG. 1;

FIG. 3 is a longitudinal cross-sectional view of the card shown in FIG. 1 taken along the line III—III;

FIGS. 4 and 5 are perspective views of the rear face of alternative arrangements of cards to the card shown in FIG. 1;

FIG. 6(a) shows a hardware architecture of a card interface system;

FIG. 6(b) shows another hardware architecture of a card interface system;

FIG. 7 is a schematic block diagram of the general-purpose computer of FIGS. 6(a) and 6(b);

FIG. 8 is a schematic block diagram representation of a card interface system architecture;

FIG. 9 is a schematic block diagram representation of a card interface system;

FIG. 10 is a schematic block diagram showing the internal configuration of the reader of FIG. 1;

FIG. 11 shows the data structure of a card header as stored in the card of FIG. 1;

FIG. 12 shows a description of each of the fields of the header of FIG. 11;

FIG. 13 shows a description of each of the flags contained in the header of FIG. 11;

FIG. 14 shows a description of each of the fields of the object structure for the card of FIG. 1;

FIG. 15 shows a description of the flag for the object structure of FIG. 14;

FIG. 16 shows a description of each of the object types for the object structure of FIG. 14;

FIG. 17 shows a description of each of the fields for a user Interface Object Structure according to the object structure of FIG. 14;

FIG. 18 shows a description for each of the user Interface object flags according to the object structure of FIG. 14;

FIG. 19 shows the format of a message header that is sent from the reader of FIG. 1;

FIG. 20 shows a table listing message event types for the header of FIG. 19;

FIG. 21 shows the format of a simple message;

FIG. 21(a) shows the format of an INSERT message;

FIG. 22 shows the format of a MOVE message;

FIG. 23 shows the format of PRESS and RELEASE messages;

FIG. 24 is a data flow diagram showing the flow of messages within the system of FIG. 6;

FIG. 25 is a flow diagram showing a read method performed by the reader of FIG. 1;

FIG. 26 is a flow diagram showing a method of initialising the system of FIG. 6, performed during the method of FIG. 25;

FIG. 27 is a flow diagram showing a method of checking the card of FIG. 1, performed during the method of FIG. 25;

FIG. 28 is a flow diagram showing a method of scanning the touch panel of the reader of FIG. 1, performed during the method of FIG. 25;

FIG. 29 is a flow diagram showing a wait 10 ms method, performed during the method of FIG. 25;

FIG. 30 is a flow diagram showing an overview of events of the system of FIG. 6;

FIG. 31 is a flow diagram showing processes performed by the event manager during the process of FIG. 30;

FIG. 32 is a flow diagram showing a method for starting a new application, performed during the process of FIG. 30;

FIG. 33 is a flow diagram showing a method of ending an application performed during the process of FIG. 30;

FIG. 34 is a flow diagram showing a method of closing a current session for a persistent application;

FIG. 35 is a flow diagram showing a method for performing a focus change;

FIG. 36 is a flow diagram showing an overview of a method performed by the launcher;

FIG. 37 is a flow diagram showing a method of changing an application, performed during the method of FIG. 36;

FIG. 38 is a flow diagram showing a method of registering a new application, performed during the method of FIG. 36;

FIG. 39 is a flow diagram showing a method performed by an application when receiving events from the launcher;

FIG. 40 is a flow diagram showing a method performed by the browser controller application when receiving events from the launcher;

FIG. 41 is a flow diagram showing a browser application method;

FIG. 42 is schematic block diagram showing the set top box of the system 600 in more detail;

FIG. 43 is a perspective view of a "bottom-entry" reader;

FIG. 44 is a plan view of the reader of FIG. 43;

FIG. 45 shows a user inserting a card into the reader of FIG. 43;

FIG. 46 shows a user operating the reader of FIG. 43 after a card has been fully inserted;

FIG. 47(a) is a longitudinal cross-sectional view along the line V—V of FIG. 44;

FIG. 47(b) is a view similar to FIG. 47(a), with a card partially inserted into the receptacle of the reader;

FIG. 47(c) is a view similar to FIG. 47(a), with a card fully inserted into the template receptacle of the reader.

FIG. 48 is a schematic block diagram representation of a further card interface system architecture;

FIG. 49 is a schematic block diagram representation showing the relationships between cards and applications;

FIG. 50 illustrates the relationships between applications and service groups;

FIGS. 51A to 51C illustrates different types of card orderings within the architecture of FIG. 48;

FIG. 52 illustrates the control template data stored in the smart card for the architecture of FIG. 48;

FIGS. 53A to 53E illustrate an example of a multi-card application structure;

FIG. 54 shows an alternative approach to achieve the end of FIGS. 53A to 53E;

FIG. 55 shows a directed graph representation of a multi-application method;

FIG. 56 shows a method of starting an application;

FIG. 57 shows one or more object structures following the card header of FIG. 11; and

FIG. 58 is a flow diagram, showing an overview of the process performed by the directory service of FIG. 8.

DETAILED DESCRIPTION INCLUDING BEST MODE

Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

The embodiments disclosed herein have been developed primarily for use with remote control systems, automatic tellers, video game controllers and network access, and will be described hereinafter with reference to these and other applications. 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 13.0, each section having associated subsections.

1.0 Card Interface System Overview

FIG. 1 shows a remote reader 1, having a housing 2, which defines a card receptacle 4 and a viewing area 6. Data reading means are provided in the form of exposed electrical contacts 7 and associated control circuitry (not shown). The remote reader 1 also includes sensor means in the form of a substantially transparent pressure sensitive membrane forming a touch panel 8 covering the viewing area 6. The remote reader 1 disclosed herein has been described with a substantially transparent pressure sensitive membrane forming the touch panel 8, however it will be appreciated by one skilled in the art that alternative technology can be used as a substantially transparent touch panel. For example, the touch panel can be resistive or temperature sensitive. The remote reader 1 is configured for use with a user interface card, which, in the cards shown in FIGS. 1 to 3, takes the form of an electronic smart card 10A. The smart card 10A includes a laminar substrate 12 with various control indicia 14 in the form of a four way directional controller 20, a "jump button" 22, a "kick button" 24, a "start button" and an "end button" printed on an upper face 16 thereof. Other non-control indicia, such as promotional or instructional material, can be printed alongside the control indicia. For example, advertising material 26 can be printed on the front face of the smart card 10A or on a reverse face 27 of the card 10A, as seen in FIG. 2.

As seen in FIG. 3, the smart card 10A includes storage means in the form of an on-board memory chip 19 for data associated with the control indicia. The smart card 10A also includes electrical data contacts 18 connected to the on-board memory chip 19 corresponding with the exposed contacts 7 on the remote reader 1.

As seen in FIG. 3, the upper face 16 may be formed by an adhesive label 60 upon which are printed control indicia 14, in this case corresponding to the "End Button" and the Right arrow "button" of the directional controller 20. The label 60 is affixed to the laminar substrate 12. A home user can print a suitable label for use with a particular smart card 10A by using a printer, such as a colour BUBBLEJET™ printer manufactured by Canon, Inc. Alternatively, the control indicia 14 can be printed directly onto the laminar substrate or separate adhesive labels can be used for each of the control indicia.

In use, the smart card 10A is inserted into the card receptacle 4, such that the pressure sensitive touch panel 8 covers the upper face 16 of the smart card 10A. In this position, the control indicia are visible within the viewing area 6 through the transparent pressure sensitive touch panel 8.

The exposed contacts 7 and associated circuitry of the reader 1 are configured to read the stored data associated with the control indicia 14 from the memory chip 19, either automatically upon insertion of the smart card 10A into the control template receptacle 4, or selectively in response to a signal from the remote reader 1. The signal can, for example, be transmitted to the smart card 10A via the exposed contacts 7 and data contacts 18.

Once the data associated with the control indicia 14 has been read, a user can press areas of the pressure sensitive touch panel 8 on or over the underlying control indicia 14. By sensing the pressure on the pressure sensitive touch panel 8 and referring to the stored data, the remote reader 1 can deduce which of the control indicia 14 the user has selected. For example, if the user places pressure on the pressure sensitive touch panel 8 adjacent the "kick button" 24, the remote reader 1 is configured to assess the position at which the pressure was applied, refer to the stored data, and determine that the "kick" button 24 was selected. This information can then be used to control an external device, for example, an associated video game console (of conventional construction and not shown). It will be appreciated from above that the control indicia 14 are not, in fact buttons. Rather, the control indicia 14 are user selectable features which, by virtue of their corresponding association with the mapping data and the function of the touch panel 8, operate to emulate buttons traditionally associated with remote control devices.

In one advantageous implementation, the remote reader 1 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 indicia selected by the user. As seen in FIG. 1, the remote reader 1 incorporates an IR transmitter having an IR light emitting diode (LED) 25. Upon selection of one of the control indicia 14, the remote reader 1 causes information related to the selection to be transmitted to a remote console (not shown in FIG. 1) where a corresponding IR or RF receiver can detect and decode the information for use in controlling some function, such as a game being played by a user of the reader 1.

Any suitable transmission method can be used to communicate information from the remote reader 1 to the remote console, including direct hard wiring. Moreover, the remote console itself can incorporate a transmitter, and the remote reader 1 a receiver, for communication in an opposite direction to that already described. The communication from the remote console to the remote reader 1 can include, for example, handshaking data, setup information, or any other form of information desired to be transferred from the remote console to the remote reader 1.

Turning to FIG. 4, there is shown a control card 10B. The control card 10B includes a laminar substrate 12, which bears control indicia (not illustrated). In the control card 10B the storage means takes the form of a magnetic strip 29 formed along an edge 28 of the reverse face 27 of the control card 10B. The stored data associated with the control indicia may be stored on the magnetic strip 29 in a conventional manner. A corresponding reader (not shown) for this arrangement includes a magnetic read head positioned at or adjacent an entrance to the corresponding control template receptacle. As the control card 10B is slid into the card receptacle, the stored data is automatically read from the magnetic strip 29 by the magnetic read head. The reader 1 may then be operated in a manner corresponding to the card 10A of FIG. 1.

FIG. 5 shows another card in the form of a control card 10C, in which the storage means takes the form of machine-readable indicia. In the card 10C of FIG. 5, the machine readable indicia takes the form of a barcode 36 formed along an edge 38 of the reverse face 27 of the card 10C. The stored data is suitably encoded, and then printed in the position shown. A corresponding controller (not shown) for the card 10C of FIG. 5 includes an optical read head positioned at or adjacent an entrance to the associated control template receptacle. As the card 10C is slid into the control receptacle, the stored data is automatically read from the barcode 36 by the optical read head. Alternatively, the barcode can be scanned using a barcode reader associated with the reader immediately prior to inserting the card 10C, or scanned by an internal barcode reader scanner once the card 10C has completely been inserted. The card 10C may then be operated in a manner again corresponding to the card 10A of FIG. 1. It will be appreciated that the position, orientation and encoding of the barcode can be altered to suit a particular application. Moreover, any other form of machine readable indicia can be used, including embossed machine-readable figures, printed alpha-numeric characters, punched or otherwise formed cut outs, optical or magneto optical indicia, two dimensional bar codes. Further, the storage means can be situated on the same side of the card 10A or 10B or 10C as the control indicia.

FIG. 6(a) shows a hardware architecture of a card interface system 600A. In the system 600A, the remote reader 1 is hard wired to a personal computer system 100 via a communications cable 3. Alternatively, instead of being hardwired, a radio frequency or IR transceiver 106 can be used to communicate with the remote reader 1. The personal computer system 100 includes a screen 101 and a computer module 102. The computer system 100 will be explained in more detail below with reference to FIG. 7. A keyboard 104 and mouse 203 are also provided.

The system 600A includes a smart card 10D which is of similar configuration to the smart card 10A described above. The smart card 10D is programmable and can be created or customised by a third party, which in this case can be a party other than the manufacturer of the card 10D and/or card reader 1. The third party can be the ultimate user of the smart card 10D itself, or may be an intermediary between the manufacturer and user. In accordance with the system 600A of FIG. 6(a), the smart card 10D can be programmed and customised for one touch operation to communicate with the computer 100 and obtain a service over a network 220, such as the Internet. The computer 100 operates to interpret signals sent via the communications cable 3 from the remote reader 1, according to a specific protocol, which will be described in detail below. The computer 100 performs the selected function according to touched control indicia, and can be configured to communicate data over the network 220. In this manner the computer 100 can permit access to applications and/or data stored on remote server computers 150, 152 and appropriate reproduction on the display device 101.

FIG. 6(b) shows a hardware architecture of a card interface system 600B. In the system 600B, the remote reader 1 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 116, such as a digital television set. The set-top box 601 operates to interpret signals 112 received from the remote reader 1, which may be electrical, radio frequency, or infra-red (IR), and according to a specific protocol which will be described in detail below. The set top box 601 can be configured to perform the selected function according to touched control indicia and permit appropriate reproduction on the output device 116. Alternatively, the set top box 601 can be configured to convert the signals 112 to a form suitable for communication and cause appropriate transmission to the computer 100. The computer 100 can then perform the selected function according to the control indicia, and provide data to the set-top box 601 to permit appropriate reproduction on the output device 116. The set top box 601 will be explained in more detail below with reference to FIG. 42.

In one application of the system 600B, the smart card 10D can be programmed for obtaining a service both remotely and locally. For instance, the smart card 10D can be programmed to retrieve an application and/or data stored on remote server computers 150, 152, via the network 220, and to load the application or data on to the set top box 601. The latter card can be alternatively programmed to obtain a service from the loaded application on the set top box 601.

Unless referred to specifically, the systems 600A and 600B will be hereinafter generically referred to as the system 600. Further, unless referred to specifically, the smart cards 10A, 10B, 10C and 10D will be hereinafter generically referred to as the smart card 10.

FIG. 7 shows the general-purpose computer system 100 of the system 600, which can be used to run the card interface system and to run software applications for programming the smart card 10. The computer system 100 includes a computer module 102, input devices such as a keyboard 104 and mouse 203, output devices including the printer (not shown) and the display device 101. A Modulator-Demodulator (Modem) transceiver device 216 is used by the computer module 102 for communicating to and from the communications network 220, for example connectable via a telephone line 221 or other functional medium. The modem 216 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 102 typically includes at least one central processing unit (CPU) 205, a memory unit 206, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (I/O) interfaces including a video interface 207, and an I/O interface 213 for the keyboard 104 and mouse 203, a write device 215, and an interface 208 for the modem 216. A storage device 209 is provided and typically includes a hard disk drive 210 and a floppy disk drive 211. A magnetic tape drive (not illustrated) is also able to be used. A CD-ROM drive 212 is typically provided as a non-volatile source of data. The components 205 to 213 of the computer module 201, typically communicate via an interconnected bus 204 and in a manner, which results in a conventional mode of operation of the computer system 102 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 of the system 600 are resident on the hard disk drive 210 and read and controlled in their execution by the CPU 205. Intermediate storage of the software application programs and any data fetched from the network 220 may be accomplished using the semiconductor memory 206, possibly in concert with the hard disk drive 210. 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 212 or 211, or alternatively may be read by the user from the network 220 via the modem device 216. Still further, the software can also be loaded into the computer system 102 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 102 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.

The smart card 10 can be programmed by means of a write device 215 coupled to the I/O interface 213 of the computer module 102. The write device 215 can have the capability of writing data to the memory on the smart card 10. Preferably, the write device 215 also has the capability of printing graphics on the top surface of the smart card 10. The write device 215 can also have a function reading data from the memory on the smart card 10. Initially, the user inserts the smart card 10 into the write device 215. The user then enters the required data via the keyboard 104 of the general purpose computer 102 and a software application writes this data to the smart card memory via the write device 215. If the stored data is encoded for optical decoding such as using a barcode, the write device can print the encoded data onto the smart card 10.

FIG. 42 shows the set top box 601 of the system 600, which can be used to interpret signals 112 received from the remote reader 1. The set top box 601 in some implementations essentially is a scaled version of the computer module 102. The set top box 601 typically includes at least one CPU unit 4305, a memory unit 4306, 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 4313 for the digital television 116, an I/O interface 4315 having an IR transceiver 4308 for receiving and transmitting the signals 112, and an interface 4317 for coupling to the network 220. The components 4305, 4306, 4313, 4315 and 4317 of the set top box 601, typically communicate via an interconnected bus 4304 and in a manner which results in a conventional mode of operation. Intermediate storage of any data received from the remote reader 1 or network 220 may be accomplished using the semiconductor memory 4306. Alternatively, the set top box can include a storage device (not shown) similar to the storage device 209.

The card interface system 600 will now be explained in more detail in the following paragraphs.

2.0 Card Interface System Software Architecture

2.1 Software Architecture Layout

A software architecture 200 for the hardware architectures depicted by the system 600, is generally illustrated in FIG. 8. The architecture 200 can be divided into several distinct process components and one class of process. The distinct processes include an I/O interface 300, which may be colloquially called an "I/O daemon" 300, an event manager 301, a display manager 306, an (application) launcher 303 and a directory service 311. The class of process is formed by one or more applications 304. In the architecture 200 described herein, there exists one I/O daemon 300, one event manager 301, one display manager 306 and one launcher 303 for every smart card remote connection, usually formed by the set-top box 601, and one master launcher (not shown) for each computer 100 (e.g. the server computers 150, 152) that is running the launchers 303, and at least one directory service 311 for all systems. The Directory service 311, is queried by the launcher 303 to translate service data into a Resource Locater (eg. URL) that indicates a name or location of a service or the location or name of an application 304 to be used for the service.

In this form, the architecture 200 can be physically separated into six distinct parts 101, 307, 309, 312, 313 and 601 as shown by the dashed lines in FIG. 8, each of which can be run on physically separate computing devices. Communication between each of the parts of the system 600 is performed using Transport Control Protocol/Internet Protocol (TCP/IP) streams. Alternatively, each of the parts 101, 307, 309, 312, 313 and 601 can be run on the same machine.

In the system 600A of FIG. 6(a), all of the process components 300, 301, 303, 304 and 306 can be run on the computer 100. The event manager 301, the launcher 303 and display manager 306 are preferably all integrated into one executable program which is stored in the hard disk 209 of the computer 100 and can be read and controlled in its execution by the CPU 205. The directory service 311 runs on the same computer 100 or on a different computer (e.g. server 150) connected to the computer 100 via the network 220.

In the system 600B of FIG. 6(b), all of components 300 to 304 and 306 can run from the set-top-box 601. In this instance, the components 300 to 304 and 306 can be stored in the memory 4306 of the set top box 601 and can be read and controlled in their execution by the CPU 4305. The directory service 311 can run on the computer 100 and can be stored in the memory 206 of the computer 100 and be read and controlled in its execution by the CPU 205. Alternatively, the directory service 311 can be run on the set top box 601 or its function performed by the launcher 303.

Alternatively, if the set-top-box 601 is not powerful enough to run the system 600 locally, only the I/O daemon 300 need run on the set-top-box 601 and the remainder of the architecture 200 (i.e. process components 301, 303, 304, 306 and 311) can run remotely on the other servers (150, 152) which can be accessed via the network 220. In this instance, the I/O daemon 300 can be stored in the memory 4306 of the set top box 601 and can be read and controlled in its execution by the CPU 4305. Again, the functional parts of such a system can be divided as shown in FIG. 8.

2.1.1 I/O Daemon

The I/O daemon 300 is a process component that converts datagrams received from the remote reader 1 into a TCP/IP stream that can be sent to the event manager 301 and vice versa (e.g. when using a two-way protocol). Any suitable data format can used by the remote reader 1. The I/O daemon 300 is preferably independent of any changes to the remote reader 1 data format, and can work with multiple arrangements of the remote reader 1. In one advantageous implementation of the system 600, the I/O daemon 300 is integrated into the event manager 301.

In the system 600A, the I/O daemon 300 is started when a user starts the smart card system 600 by powering up the computer 100 and the event manager 301 has been started. Alternatively, the I/O daemon 300 is started when a user starts the system 600 by turning on the set-top box 601.

The I/O daemon 300 will be explained in more detail below with reference to section 9.0.

2.1.2 Event Manager

The event manager 301 forms a central part of the architecture 200 in that all communications are routed through the event manager 301. The event manager 301 is configured to gather all events that are generated by the remote reader 1 and relayed by the I/O daemon 300. These events are then redistributed to the various process components 300 to 304, and 306 and running applications. The event manager 301 is also configured to check that an event has a valid header, correct data length, but is typically not configured to check that an event is in the correct format. An "event" in this regard represents a single data transaction from the I/O daemon 300 or the launcher 303 or applications 304.

Any changes in protocol between different systems can be dealt with by the event manager 301. Where possible, events can be rewritten to conform to the data format understood by any presently running application 304. If such is not possible, then the event manager 301 reports an error to the originating application 304. When different data formats are being used, for example with a system running multiple smart cards, the event manager 301 preferably ensures that the smallest disruption possible occurs.

The event manager 301 does not have any presence on the display screen or other output device 116. However, the event manager 301 can be configured to instruct the display manager 306 as to which application is presently required (i.e. the "front" application) and should currently be displayed on the display 101. The event manager 301 infers this information from messages passed to the applications 304 from the launcher 303 as will be explained in more detail below with reference to section 10.0.

The event manager 301 can be configured to always listen for incoming I/O daemon connections or alternatively, can start the system 600. The method used is dependent on the overall configuration of the system 600. In this connection, the event manager 301 can start the system 600 or the set top box 601 can use the incoming connection of the I/O daemon 300 to start the system 600. The event manager 301 will be described in more detail below with reference to section 7.0.

2.1.3 Master Launcher

Where a thin client computer is being utilised and multiple launchers 303 are running with each launcher 303 being responsible for one set top box, a master launcher (not shown) which communicates directly with the event manager 301 can be used. The master launcher is used to start the launcher 303 corresponding to each of the event managers 301 if more than one event manager is running on the system 600. Initially, when the I/O daemon 300 connects to the event manager 301, the event manager 301 requests that the master launcher start a first process for the event manager 301. This first process is generally the launcher 303 for any smart card application 304. The master launcher can also be configured to shut down the launcher 303 of an application 304 when the event manager 301 so requests, and for informing the event manager 301 that the launcher 303 has exited.

There is preferably one master launcher running for each physically separate server (e.g. 150, 152) that is running an associated smart card application 304. This one master launcher handles the requests for all event managers that request launchers on a particular server. When run on a computer 100, as seen in FIG. 7, the master launcher commences operation either before or no later than at the same time as the rest of the system 600. In this instance, the master launcher is started first.

The master launcher can be integrated into the event manager 301, for example, when an associated launcher is running on the same computer as the event manager 301.

2.1.4 Launcher/First Application

In one advantageous implementation of the system 600, the first process started by the insertion of a smart card 10 into the remote reader 1 is the launcher 303. In specific systems, specific applications may be commenced, for example an automatic teller machine can start a banking application. Another example includes the use of restricted launchers that only start a specified sub-set of applications. The launcher 303 is an application that starts other applications for a specific event manager 301. The launcher 303 starts and ends applications and can also start and end sessions. The launcher 303 also informs the event manager 301 when applications are starting and ending, and tells the applications 304 when they are receiving or losing focus, or when they need to exit. In this regard, where a number of applications 304 are operating simultaneously, the application 304 that is currently on-screen is the application having focus, also known as the "front application". When another application is about to take precedence, the launcher 303 tells the front application that it is losing focus, thereby enabling the current application to complete its immediate tasks. The launcher 303 also tells the new application 304 that it is gaining focus, and that the new application 304 shall soon be changing state. The launcher 303 is also configured to force an application to exit.

The launcher 303 may receive certain events such as "no-card", "low battery" and "bad card" events generated by the remote reader 1. The launcher 303 also receives events that are intended for applications that are not currently the front application, and the launcher 303 operates to correctly interpret these events.

The launcher 303 is preferably only started when a request is generated by the event manager 301 to request the launcher 303 to be started. The launcher 303 can also be told to exit and forced to exit by the event manager 301.

The launcher 303 is preferably the only process component that needs to communicate with the directory service 311. When the launcher 303 is required to start a new application 304, the launcher 303 queries the directory service 311 with service data, and the directory service 311 returns a location of the application 304 and service data associated with the new application 304. The service data is sent to the new application 304 as initialisation data in an event, referred to herein as the EM_GAINING_FOCUS event. The application location specifies the location of the application 304 to be run. This may be local, for implementations with a local computer, or networked. If the application location is empty, then the launcher 303 has to decide which application to start based on the service data.

The launcher 303 can also be configured to start any applications, for example browser controllers that will generally always be running while the system 600 is operating. Such applications are referred to as persistent applications. Applications can also be started by the launcher 303 either as a response to the first user selection on a corresponding smart card 10, or at the request of another one of the applications 304.

The launcher 303 can be integrated into the event manager 301 in some implementations of the system 600.

The launcher 303 will be explained in more detail below with reference to section 10.0.

2.1.5 Display Manager

The display manager 306 selects which smart card application 304 is currently able to display output on the display screen 101. The display manager 306 is told which application 304 can be displayed by an EM_GAINING_FOCUS event originating from the launcher 303. This event can be sent to the display manager 306 directly, or the event manager 301 can send copies of the event to the display manager 306 and the intended recipient.

Generally, the only application 304 that should be attempting to display output should be the front application. The display manager 306 can provide consistent output during the transfer between applications having control of the display. The display manager 306 may need to use extrapolated data during changeovers of applications as the front application.

The architecture 200 can be configured such that the display manager 306 is not needed or the role of the display manager 306 may be assumed by the other parts 301 or 303, of the architecture 200.

2.1.6 Directory Service

The directory service 311 is configured to translate service identifiers that are stored on smart cards 10, 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 311 is also configured to translate optional service data. The directory service 311 allows the launcher 303 associated with a particular card 10 to decide what to do with a resource locator, for example, download and run the associated application 304 or load the resource locator into a browser application. The translation by the directory service can be performed using a distributed lookup system.

2.1.7 Applications

The applications 304 associated with a particular smart card 10 can be started by the launcher 303 associated with that smart card 10 in a response to a first button press on a corresponding card. Each application 304 can be a member of one or more service groups, described in detail later in this specification. An application 304 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.

Some applications can be started when the system 600 is started and these applications, for example a browser control application or a media playing application can be always running. These persistent applications can be system specific or more generally applicable.

FIG. 9 is a schematic block diagram representation of a card interface system, including the process components 301 to 306 described above. In the system of FIG. 9, the remote reader 1 communicates with a computer 100 via an IR link in conjunction with an I/O daemon 300 for controlling the IR link. Further, the computer 100 is configured for communicating to and from a communications network in this case represented by the Internet 400 to a Web server 410. In this instance, some of the applications 304 accessible utilising the smart cards 10 and remote reader 1 can be Web pages 406 associated with different smart cards 10. The Web libraries 407 contain functions (e.g. JavaScript functions) and classes (e.g. Java classes) that can be included with web pages for use with the smart card 10. The Web pages 406 can be accessed with a running application called the Web browser 403. In the system of FIG. 9, the event manager 301 is configured to receive an event from the remote reader 1. The event is then sent to the launcher 303, which can be configured to send a message to the browser controller 402, which controls the Web browser 403. The process for starting an application or browser session will be explained in more detail below. The launcher 303 can also be configured to download applications 408 as well as running applications from a file server 411 which is also connected to the computer 100 via the Internet 400.

3.0 Reader

The remote reader 1 is preferably a hand-held, battery-powered unit that interfaces with a smart card 10 to provide a customisable user interface. As described above, the remote reader 1 is intended for use with a digital television, a set top box, computer, or cable television equipment to provide a simple, intuitive interface to on-line consumer services in the home environment.

FIGS. 43 and 44 show a reader 4401 similar to the reader 1 described above. The reader 4401 is configured for the reading of the card 10. The reader 4401 is formed of a housing 4402 incorporating a card receptacle 4404 and a viewing area 4406. The receptacle 4404 includes an access opening 4410 through which a smart card 10, seen in FIG. 1, is insertable.

An upper boundary of the viewing area 4406 is defined by sensor means in the form of a substantially transparent pressure sensitive membrane 4408 similar to the membrane 8 described above. Arranged beneath the membrane 4408 is data reading means provided in the form of an arrangement of exposed electrical contacts 4407 configured to contact complementary contacts of the smart card 10.

The card 10 is inserted into the reader 4401 via the access opening 4410 as shown in FIG. 45. The configuration of the reader 4401 allows a user to hold the reader 4401 in one hand and easily insert the smart card 10 into the reader 4401 with the user's other hand. When the smart card 10 is fully inserted into the reader 4401, the pressure sensitive membrane 4408 fully covers the upper face 16 of the smart card 10. The viewing area 4406 preferably has substantially the same dimensions as the upper face 16 of the card 10 such that the upper face 16 is, for all intents and purposes, fully visible within the viewing area 4406 through the transparent pressure sensitive membrane 4408.

FIG. 46 shows a user operating the reader 4401 after a card has been fully inserted.

Referring to FIGS. 47(a) to 47(c), the housing 4402 is formed of a substantially two part outer shell defined by a top section 4827 that surrounds the membrane 4408, and a base section 4805 which extends from a connection 4829 with the top section 4827 to a location 4811 below and proximate the transverse centre of the membrane 4408. The base section 4805 incorporates a facing end 4815 formed from infrared (IR) transparent material thereby permitting IR communications being emitted by the reader 4401.

The location 4811 defines a point of connection between the base section 4805 a card support surface 4807 which extends through a plane in which the contacts 4407 lie to an interior join 4835 that sandwiches the membrane 4408 between the surface 4807 and the top section 4827. The access opening 4410 is substantially defined by the space between the location 4811 and a periphery 4836 of the housing 4402, seen in FIG. 47(a).

The contacts 4407 extend from a connector block 4837 mounted upon a printed circuit board (PCB) 4801, the PCB 4801 being positioned between the base section 4805 and the support surface 4807 by way of the two mountings 4817 and 4819. Arranged on an opposite side of the PCB 4801 to the connector block 4837 is electronic circuitry (not shown), electrically connected to the connectors 4407 and the touch sensitive membrane 4408 and configured for reading data from the card 10 according to depression of the membrane 4408. Also mounted from the PCB 4801 is an infrared light emitting diode (LED) 4800 positioned adjacent the end 4815 which acts as an IR window for communications with a device (e.g. the set top box 601) to be controlled.

FIG. 47(b) shows a similar view to FIG. 47(a), with the smart card 10 partially inserted through the access opening 4410 into the receptacle 4404. As can be seen in FIG. 47(b), the support surface 4807 has an integrally formed curve contour 4840 that leads downward from the plane of the contacts 4407 towards the join 4811. This configuration allows the reader 4401 to receive the smart card 10 such that the smart card 10 may be initially angled to the plane of the receptacle 4404, as seen in FIG. 47(b). The configuration of the curve contour portion 4840 of the support surface 4807 guides the smart card 10 into a fully inserted position under the force of the user's hand. Specifically, as the card 10 is further inserted, the curvature of the support surface 4807 guides the card 10 into the plane of the contacts 4407 and receptacle 4404.

FIG. 47(c) shows a similar view to FIG. 47(a), with the smart card 10 fully inserted into the receptacle 4404. In this position, the card 10 lies in the plane of the receptacle 4404 and the contacts 4407 which touch an associated one of the data contacts (not seen) of the smart card 10, and the smart card 10 is covered by the pressure sensitive membrane 4408. Further, the contacts 4407 are preferably spring contacts that act to provide a force against the card 10 and associated with the membrane 4408, sufficient for the card 10 to be held within the receptacle by a neat interference fit.

In the following description references to the reader 1 can be construed as references to a reader implemented as the reader 1 of FIG. 1 or the reader 4401 of FIGS. 43 to 47(c).

FIG. 10 is a schematic block diagram showing the internal configuration of the remote reader 1 in more detail. The remote reader 1 includes a microcontroller 44 for controlling the remote reader 1, coordinating communications between the remote reader 1 and a set top box 601, for example, and for storing mapping information. The microcontroller 44 includes random access memory (RAM) 47 and flash (ROM) memory 46. The microcontroller 44 also includes a central processing unit (CPU) 45. The microcontroller 44 is connected to a clock source 48 and a clock controller 43 for coordinating the timing of events within the microcontroller 44. The CPU 45 is supplied with electrical power from a 5 volt battery 53, the operation of the former being controlled by a power controller 50. The microcontroller 44 is also connected to a beeper 51 for giving audible feedback about card entry status and for "button" presses.

Infra-red (IR) communications are preferably implemented using two circuits connected to the microcontroller 44, an IR transmitter (transmitter) 49 for IR transmission and an IR receiver (receiver) 40 for IR reception.

The pressure sensitive touch panel 8 of the remote reader 1 communicates with the microcontroller 44 via a touch panel interface 41. A smart card interface 42 connects to the electrical contacts 7.

An in-system programming interface 52 is also connected to the microcontroller 44, to enable programming of the microcontroller 44 by way of the microcontroller FLASH memory 46 with firmware. The firmware will be explained in further detail later in this document with reference to section 6.0.

The internal configuration of the remote reader 1 will now be described in further detail.

3.1 Low Power Mode Lifetime

The power controller 50 is operable to provide two power modes, one being a low-power "sleep" mode, and another being an active mode. The low power mode lifetime is the lifetime of the battery 53 expressed in years. When the remote reader 1 is not functioning and is in the low power mode, the lifetime can be between greater than 2 years.

If the reader 1 is in sleep mode and a user presses the touch panel 8, the remote reader 1 then comes out of sleep mode, and the CPU 45 calculates the touch co-ordinates and sends a serial message by infra-red transmission. The battery 53 should preferably remain serviceable for the current supply requirements of more than 100,000 button presses.

3.2 Service Life

The service life is defined as the period of time that the remote reader 1 can be expected to remain serviceable, not including battery replacement. The service life is related to the Mean Time Between Failures (MTBF) figure and is usually derived statistically using accelerated life testing. The service life of the remote reader 1 can thus be greater than 5 years.

3.3 Microcontroller

The microcontroller 44 of the remote reader 1 has an 8 bit central CPU with 4096 bytes of FLASH memory 46 and 128 bytes of random access memory 47. The microcontroller 44 preferably operates on a supply voltage from 3 to 5 Volts and has flexible on-board timers, interrupt sources, 8 bit analog to digital converters (ADC), clock watchdog and low voltage reset circuits. Preferably, the microcontroller 44 also has high current output pins and can be programmed in circuit with only a few external connections.

3.4 Clock Source

The main clock source 48 for the remote reader 1 is preferably a 3 pin 4.91 MHz ceramic resonator with integral balance capacitors. The frequency tolerance is 0.3%. While such tolerance is not as good as a crystal, such is however adequate for serial communications and is much smaller and cheaper than a crystal.

3.5 Beeper

The beeper 51 is included with the remote reader 1 to give audible feedback about card entry status and for button presses. The beeper 51 is preferably a piezo-ceramic disk type.

3.6 Infra-red Communications

As described above, infra-red (IR) communications are preferably implemented using two circuits, an IR transmitter 49 for IR transmission and an IR receiver 40 for IR reception. The two circuits 40 and 49 are preferably combined on a printed circuit board (e.g the PCB 4801 of FIG. 47) within