User input device

A user input device (300) configured with a communication protocol for communicating transmission data with predetermined apparatus (700, 601) is disclosed. The device (300) comprises a receiving means for receiving protocol data and an associated format function. The protocol data and the format function in combination describe a further communication protocol for communicating with the predetermined apparatus (700, 601). The device (300) also comprises a central processing unit (805) for selecting the received protocol data and the format function and for configuring the device (300) to communicate with the predetermined apparatus (700, 601). The protocol data defines properties of the further communication protocol and the format function is adapted to configure at least a portion of the transmission data for communication with the apparatus (700, 601) according to the further communications protocol.

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to the field of signal processing and, in particular, to a user input device.

BACKGROUND

Infrared (IR) remote control devices (or remote controls) are known, and can be used to control electronic appliances such as televisions, video recorders, stereo systems, set-top boxes, personal computers etc. For example, wireless keyboards and wireless mice can be used to operate a personal computer.

Infrared data transmission in such remote control devices is typically achieved by alternating an Infrared Light Emitting Diode (LED) between two states (i.e., an OFF state and an ON state). In the OFF state, the LED is kept powered down and in the ON state, the LED is rapidly powered on and off at a predetermined frequency. This predetermined frequency is known as the ‘carrier frequency’.

Several methods can be used to encode data based on the above-mentioned ON and OFF states. One such method is referred to as ‘pulse code modulation’, where each bit of a data transmission is encoded by a fixed length duration in one of the two states. Typically, the OFF state represents a ‘1’ bit, and the ON state represents a ‘0’ bit. Another method of encoding data is referred to as ‘pulse frequency modulation’ where each symbol consists of an ON pulse followed by an OFF pulse. The length of the ON pulse is static while the length of the OFF pulse varies depending on the value of the symbol. Still another method of encoding data based on the above-mentioned two states is referred to as ‘pulse position modulation’ where each symbol is encoded by the position of an ON pulse within a longer, fixed length, OFF period. One variation of the pulse position modulation is referred to as ‘four pulse position modulation, where the ON pulse can occur in one of four positions, thus encoding two bits per data symbol.

Most protocols for infrared transmission utilize a carrier frequency within the range of 32 to 56 kHz. Such protocols also vary in message format, according to the presence and size of data bits, device identifier bits, parity and check bits, sequence bits and start/stop conditions. Remote controlled appliances are typically designed to operate using one particular protocol, and are generally supplied with a remote control device designed to work specifically with that appliance. As a result, many households have several remote control devices to operate individual devices within the same room.

One known method for alleviating the need for different remote control devices for each particular appliance is to combine the functionality of all such remote control devices into one “universal” remote control device. The simplest type of universal remote control device is nothing more than a single remote control device capable of controlling more than one type of appliance. However, such a remote control device adds the demand that all appliances controlled by the remote control device must use the protocol used by the remote control device. In many cases, various appliances are purchased from different manufacturers and vendors. Thus, a particular universal remote control device will generally be unable to control all such appliances.

A reconfigurable remote control device is an advanced version of a universal remote control device, where the functionality of at least some input keys of the remote control device can be reconfigured after the remote control device has been purchased. One such reconfigurable remote control device transmits data using only one protocol. However, the input keys of the remote control device can be reconfigured with different codes as required. Other reconfigurable remote control devices can be configured to transmit data using one of several known protocols.

Most conventional universal remote control devices utilize a keyboard method of input data entry. Some additionally use liquid crystal displays (LCD) in order to provide feedback to the user, such as indicating the current function of certain keys.

Some universal remote control devices provide a touch-sensitive LCD to replace at least some portion of a keyboard configured on the remote control device. However, most retain at least several “hard” keys. The LCD provides the opportunity for a user or manufacturer to customize not only the functions provided by the remote control device, but also the method of interfacing used by the remotely controlled appliance or device itself.

While some reconfigurable remote control devices can only be reconfigured using a limited range of protocols and codes known by each particular remote control device, there are several known methods that can be employed to load additional protocols onto such remote control devices. One such method is commonly referred to as ‘learning’. One universal remote control device, which utilizes the learning method, is equipped with a receiver, configured to detect transmissions by other remote control devices. In order to program a code onto this universal remote control device, the user must select “learning mode” on the remote control device (i.e., the learning remote control device), and then use another remote control device which already knows the particular code to transmit the required code to the learning remote control device. The learning universal remote control device then stores a representation of the received code in an on-board memory device, ready to be played back at a later stage.

The main disadvantage of the above ‘learning’ method is that programming the remote control device using the method is tedious and time consuming since a lot of keys need to be pressed. Additionally, a user must also have another pre-configured remote control device available in order to provide all of the codes to program onto the learning remote control device. If a new universal remote control device is purchased at a later date, the learning process has to be repeated again. Further, if the codes to be learned contain data that varies from message to message, such as sequence bits or numbers, then a remote control device using the learning method is not always able to recognise such sequence bits. Thus, these bits are not able to be reproduced in the correct manner, by the remote control device, when re-transmitting the codes.

Another known method of reconfiguring a remote control device provides the remote control device with the ability to read data from a removable storage medium, such as a control card or smart card. The card has sets of code data and programming stored thereon. The code data is configured to allow the remote control device to operate various appliances (e.g. a television, VCR, cable box, Internet access device or other electronic device). The remote control device is provided or sold to a user essentially “empty” of such code data. The card allows a one-time transfer of a single device code (i.e., code data needed to remotely operate a particular electronic device) from the card into on-board, non-volatile memory of the remote control device. However, such a remote control device is limited as to the number of device codes that can be stored in the non-volatile memory. Further, these stored device codes cannot be easily changed or replaced once the device codes have been loaded into the non-volatile memory. Still further, the user interface of such a remote control device is fixed and cannot be readily changed according to the circumstances of use. In the reconfiguring methods described above, several disadvantages are evident. Firstly, a lot of data is required to program a universal remote control device with a particular range of functions that is required to operate a number of appliances remotely. Such data is required since each button of a universal remote control device typically describes an entire transmission sequence for the particular button at a low level, leading to a lot of data repetition and redundancy. The data repetition and redundancy raises the cost of manufacturing and purchasing such a remote control device since faster processors, more memory and more powerful batteries must be used to power such remote control devices. Secondly, the user interface of a keypad based universal remote control device is fixed, and cannot be readily changed according to the circumstances of use. Thirdly, software code stored on universal remote control devices cannot be easily changed.

Some reconfigurable remote control devices are pre-configured to have existing functions or protocols activated infrequently. For example, a function may be activated on such a remote control device upon purchase of the remote control device. One such remote control device utilizes a bar code displayed on an appliance in a location that is accessible to the remote control device. The remote control device is equipped with a bar code reader and upon reading a bar code from the appliance corresponding to a known configuration, the remote control device is reconfigured to enable remote operation of that appliance. The bar code label contains a data pattern, which identifies the type of appliance and the remote control encoding format to which the appliance responds. If the remote control unit detects a recognizable bar code pattern during the period that the bar code reader is enabled, then the remote control unit proceeds to analyze the identification data. If the appliance type and infrared format are supported by the remote control device, then the remote control reconfigures its programming to match the new appliance. If the device or equipment is not supported by the remote control device, then the remote control device simply remains unchanged in its previous configuration.

Another known remote control device uses a method where prior to receiving a first remote “power on” command, a remotely controlled appliance periodically emits an infra-red “squawk” signal, which encodes information used to identify the appliance. When a “power on” button is pressed on the associated remote control device, the remote control device briefly listens for such a squawk signal before sending the currently configured power on code. If such a squawk signal is detected, the remote control device reconfigures itself to enable operation of the appliance and then sends the correct power on signal to the appliance, prompting the appliance to stop sending further “squawk” signals.

However, the appliance barcode remote control device and the ‘squawk’ signal remote control device both require that an associated remote control device have prior knowledge of all appliances that can be supported by the remote control device. Any reprogramming of the associated remote control device needs to be performed using one of the methods described above. Additionally, such remote control devices may not be able to be used with existing appliances that are not suitable configured.

Another known method for activating a remote control device to operate with a particular protocol works by configuring the remote control device in order to enter a mode where a single command is transmitted using all known protocols, one at a time. When the user of such a remote control device detects the correct response by the controlled appliance, the remote control device is instructed by a further user selection to stop probing and to send all subsequent commands using the protocol, which instigated the correct response. Such a remote control device is simple to implement, but requires the user to go through an unintuitive protocol selection process, which can also interfere with other appliances.

Still another known remote control device comprises a transparent touch sensitive surface. A control card with a printed user interface on its upper surface can be placed underneath the transparent touch sensitive surface. The remote control device switches to a different operating mode based on a physical property (e.g., a notch) of the card. While providing added versatility, this remote control device is limited to a fixed set of cards. Further, the remote control device is limited to a fixed set of protocols, which are pre-installed on the remote control device. Still further, this remote control device is limited to a predetermined fixed set of functions.

Some appliances or devices are configured to accept data from multiple remote control devices simultaneously. For example, in a multi-player game, each player can hold a remote control device, sending the same set of inputs to a single receiving appliance. The remote control devices generally distinguish themselves from each other by means of a user identifier, which is included as part of each message that is transmitted from the remote control device to the receiving device. User identifiers on such remote control devices are typically changed by means of a switch located somewhere on the surface of the remote control device. The switch is capable of being set to one of two or more settings.

An infrared remote control device must store enough characteristics of an infrared protocol to be able to faithfully reproduce the protocol at some later time. The required information may be stored on an individual button-by-button basis, or as part of a global structure referenced by individual buttons. In the case of a global protocol structure, each button has some associated information to be used in conjunction with the global information in order to produce a unique code. One known method of representing protocol information utilizes a series of instructions, either executed directly or interpreted by a program being executed on a microprocessor. Another known method of representing protocol information counts the number of pulses during each ON period, and records the number of pulses together with the duration of each OFF period. These periods are then grouped into categories having similar sizes, and stored as a sequence of category identifiers.

In each of the infrared remote control devices described above, the amount of data required to be stored on the remote control device for every possible protocol can be large. Some remote control devices are configured to compress the data, for example, by forming categories during a learning process. However, inaccuracies can result during this process which can prevent a protocol from being faithfully reproduced later.

One known remote control device maintains a range of protocols, which are represented by means of a set of properties. Some properties, specifically bit patterns and data formats, are expressed as pointers to one of a finite set of data structures that define these values. While such a remote control device generally provides a compressed format for storing the protocol data, a finite number of bit pattern types and data formats are supported. Thus, a new protocol depends on a compatible format being found.

Control cards, which can be used with remote control devices, as discussed above, often 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 set of electrical contacts, for example.

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.

There are several existing smart card systems, which utilize CPU smart cards including a user interface. One of these existing smart card systems utilizes a reader device including 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 screen. The reader device is configured to determine the position of a touch on the transparent panel and use 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.

In one such existing smart card system, the reader device contains an infrared transmitter, which is used to transmit information received from the card to a set-top box connected to a service provider. Due to the large variety of infrared set-top boxes available, which do not necessarily use the same data transmission protocol, each card reader device must be pre-configured to match a certain set-top box. Once such a reader has been configured for one particular set top box, the software code (i.e.,firmware) resident on the reader cannot be easily changed.

In addition, in order to fully utilize the functionality of a particular smart card, software applications must be created or modified in order to recognize the format of messages sent by a reader device associated with the particular card. The message format is typically implemented above the infra-red protocol layer. None of the existing smart card systems include a mechanism which is able to emulate conventional input devices such as a keyboard or mice, and which would enable a smart card used with such a system to work with existing applications without significant modification to the application.

The reader device of the existing smart card system discussed above, while containing an infrared transmitter, is unable to control the multitude of other appliances that use infrared remote control devices. Thus, the smart card reader device is merely another remote control device to be added to the pile of conventional remote control devices which now exists in most households. This is despite the growing trend towards universal remote control devices as described above.

Finally, the reader device described above, while having the potential to operate in a variety of different modes, with different settings, does not provide a mechanism for operating modes and settings to be reconfigured as necessary by a user of the existing smart card system.

Accordingly, the reader device discussed above is generally limited in application to a predetermined number of pre-installed data transmission protocols. These data transmission protocols cannot be easily changed and additional protocols cannot be easily added. Further, the functionality of the reader device discussed above cannot be easily changed. Thus, a need clearly exists for a reader device, which is capable of transmitting data using one of several protocols, where the protocols can be easily changed and additional protocols can be easily added. Further, a need clearly exists for a reader device, the functionality of which can be easily changed in order to allow the control of many different electronic appliances.

SUMMARY OF THE INVENTION

According to one aspect of the present invention there is provided a remote control device configured with a first communication protocol for communicating transmission data with at least one of a plurality of predetermined apparatus, said remote control device comprising:

a receiving means for receiving protocol data and an associated format function, said protocol data and said format function in combination describing a second communication protocol for communicating with one or more of said plurality of predetermined apparatus; and

a central processing unit for selecting said received protocol data and said format function and for configuring the remote control device to communicate with said one or more of said plurality of predetermined apparatus, wherein said protocol data defines properties of said second communication protocol and said format function is adapted to configure at least a portion of said transmission data for communication with said at least one apparatus according to said second communications protocol.

According to another aspect of the present invention there is provided a device for communicating transmission data with at least one of a plurality of predetermined apparatus, said device comprising:

a memory having one or more portions of protocol data stored therein, each said portion having an associated format function, said protocol data and said format function of each portion, in combination, at least describing a communications protocol for communicating with one or more of said plurality of predetermined apparatus; and

a central processing unit for selecting at least one of said portions of protocol data, and said associated format function, describing at least one of said protocols and for configuring the remote control device to communicate with said one or more of said plurality of predetermined apparatus, wherein said protocol data of said selected portion defines properties of said at least one protocol and said format function of said selected portion is adapted to configure at least a portion of said transmission data for communication to said at least one apparatus according to said at least one protocol.

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

a memory having one or more portions of protocol data stored therein, each said portion having an associated format function, said protocol data and said format function of each portion, in combination, at least describing a communications protocols for communicating with one or more of a plurality of predetermined apparatus; and

a central processing unit for selecting at least one of said portions of said protocol data, and said format function, describing at least one of said protocols in order to configure the remote control device to communicate with said one or more of said plurality of apparatus, and for communicating a message to said at least one of said apparatus, according to said at least one protocol, upon receiving specific data related to a selection of at least one of said indicia.

According to still another aspect of the present invention there is provided a method of configuring a remote control device device, said remote control device being configured with a first communications protocol for communicating with at least one of a plurality of predetermined apparatus, said method comprising the steps of:

selecting protocol data and an associated format function stored in a memory operatively associated with said remote control device, said protocol data and said format function in combination describing a second communication protocol for communicating transmission data to at least one other of said plurality of predetermined apparatus; and

configuring said read device to communicate with said at least one other apparatus according to said second communications protocol, said protocol data defining properties of said second communication protocol and said format function being adapted to configure at least a portion of said transmission data for communication with said at least one other apparatus according to said second communications protocol.

According to still another aspect of the present invention there is provided a method of configuring a read device for communicating transmission data with at least one of a plurality of external devices, said read device being adapted to accept an interface card, said card having indicia formed thereon and a memory configured adjacent said indicia, said memory having one or more portions of protocol data stored therein, each said portion having an associated format function, said protocol data and said format function of each portion, in combination, describing at least one of a plurality of communications protocol for communicating with at least one of said plurality of predetermined external devices, said method comprising the steps of:

determining specific data related to a selection of at least one of said indicia;

selecting protocol data and an associated format function representing a particular one of said plurality of communications protocols depending on said specific data; and

configuring said read device to communicate with at least one other of said external devices according to said selected portion, wherein said protocol data of said selected portion defines properties of said particular protocol and said format function of said selected portion is adapted to configure at least a portion of said transmission data for communication to said one or more of said external devices according to said particular protocol.

According to still another aspect of the present invention there is provided a method of configuring a remote control device configured with a first communications protocol for communicating transmission data with at least one of a plurality of predetermined apparatus, said read device being adapted to accept an interface card, said card having indicia formed thereon and a memory configured adjacent said indicia, said memory having protocol data and a format function stored therein at least defining a second communications protocol for communicating said transmission data with one or more of said apparatus, said method comprising the steps of:

providing said card to a user for insertion into said read device, wherein a processor of said read device is configured to perform the following steps:

determine specific data related to a selection of at least one of said indicia;

select said protocol data and said format function depending on said specific data; and

configure said read device to communicate with said one or more of said apparatus according to said second communications protocol, wherein said protocol data defines properties of said second communications protocol and said format function of said portion is adapted to configure at least a portion of said transmission data for communication with said at least one apparatus according to said second communications protocol.

According to still another aspect of the present invention there is provided a card reader for reading an electronic card receivable therein, said card reader being adapted for communicating with data controlled equipment, said card having indicia formed thereon and a memory having data stored therein, said data at least describing configuration properties of said card reader, said card reader comprising:

a central processing unit for selecting a portion of said data stored in said memory of said card upon receiving specific data related to a selection of at least one of said indicia following said card being inserted into said card reader, and for reconfiguring said card reader according to said selected portion of said data.

According to still another aspect of the present invention there is provided a card reader for reading an electronic card receivable therein, said card having indicia formed thereon and a memory having data and one or more format functions stored therein, said data and said format functions at least describing a plurality of communications protocols for communicating with predetermined data controlled equipment, said card reader comprising:

a central processing unit for selecting a portion of said data and an associated one of said format functions stored in said memory of said card upon receiving specific data related to a selection of at least one of said indicia following said card insertion, and for reconfiguring said card reader for communication with data controlled equipment according to said selected portion of said data.

According to still another aspect of the present invention there is provided a card reader for reading an electronic card received therein, said card reader being adapted for communicating with data controlled equipment, said card having indicia formed thereon and an electronic memory having data stored therein, said data at least describing configuration properties of said card reader, said card reader comprising:

a touch sensitive substantially transparent membrane having an upper surface configured to be depressible in order to enable selection of one or more of said indicia; and

a central processing unit for reading at least a portion of said data from said memory according to said indicia selection, and for processing at least a portion of said data stored in said memory to reconfigure said card reader according to said selected portion of said data.

According to still another aspect of the present invention there is provided a method of configuring a card reader, said card reader being configured for reading an electronic card and for communicating with data controlled equipment, said electronic card having indicia formed thereon and an electronic memory having data stored therein, said data at least describing configuration properties of said card reader, said method comprising the steps of:

selecting at least a portion of said data stored on said card upon receiving specific data related to a selection of at least one of said indicia following said insertion; and

reconfiguring said card reader according to said selected portion of said data.

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.

It is to be noted that the discussions contained in the “Background” section and that above relating to prior art arrangements relate to discussions of documents or devices which form public knowledge through their respective publication and/or use. Such should not be interpreted as a representation by the present inventor(s) or patent applicant that such documents or devices in any way form part of the common general knowledge in the art.

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 arrangements disclosed herein have been developed primarily for use with remote control appliances, automatic tellers and network access systems, and will be described hereinafter with reference to these and other applications. The arrangements described herein can be used for accessing 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. The arrangements disclosed herein can also be used for controlling appliances remotely. However, it will be appreciated that the invention is not limited to any of the above mentioned fields of use.

For ease of explanation the following description has been divided into Sections 1.0 to 8.7, each section having associated subsections.

1.0 Smart Card Interface System Overview

1.1 Smart Cards

FIG. 1(a) shows a smart card100A including a planar substrate112with various user interface elements114(i.e. predetermined areas, or iconic representations) printed or otherwise formed on an upper face116thereof, for example using an adhesive label. For the smart card100A, the user interface elements114are in the form of a four way directional controller120, a “jump button”122, a “kick button”124, a “start button”128and an “end button”130printed on a front face116thereof. Other forms of user interface elements, such as promotional or instructional material, can be printed alongside the user interface elements114. For example, advertising material126can be printed on the front face116of the smart card100A or on a reverse face (not shown) of the smart card100A. In still other forms of the smart card100A, the memory chip219can be replaced by a storage means such as a magnetic strip (not shown) formed on one surface of the smart card100A.

As seen inFIG. 2(a), the front face116of the smart card100A may be formed by an adhesive label260upon which is printed the user interface in the form of the user interface elements114, in this case corresponding to the “End Button” and the Right arrow “button” of the directional controller120. The label260is affixed to the planar substrate112. A home user can print a suitable label for use with a particular smart card100A by using a printer. Alternatively, the user interface elements114can be printed directly onto the planar substrate112or separate adhesive labels can be used for each of the user interface elements114.

As also seen inFIG. 2(a), the smart card100A includes storage means in the form of an on-board memory chip219for storing data associated with the user interface elements114. The smart card100A having a memory chip219as described above is generally referred to as a “memory card”. Thus, the smart card100A will hereinafter be referred to as the memory card100A. The memory card100A also includes electrical data contacts218connected to the memory chip219and via which reading of the memory chip219and writing to the memory chip219may be performed.

Alternatively, in other forms of the memory card100A, the memory chip219can 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 card100A.

Memory cards such as the memory card100A can be utilized in applications where strong security of the memory card100A and data stored in the chip219of the memory card100A, is not required. The memory card100A can also be used in applications where it is desired to maintain the cost of manufacturing the memory card100A to a minimum. Such smart cards can be used for example, where the memory card100A is given away to promote a service and/or to provide access to the service. The memory card100A can also be used as a membership card, which provides access to a specific service.

FIG. 1(b) shows another smart card100B again including a planar substrate152with various user interface elements154printed on a front face156thereof. In the smart card100B the user interface elements154are in the form of a numerical keypad160, an “OK button”162, a “cancel button”164, a “clear button”166and a “backspace button”168printed on the front face156thereof. Again, other forms of user interface elements, such as promotional or instructional material, can be printed alongside the user interface elements154such as advertising material158.

As seen inFIG. 2(b), the front face156of the smart card100B is formed by an adhesive label270affixed to the planar substrate152in a similar manner to the memory card100A. Again, a user interface in the form of user interface elements154, in this case corresponding to the “number 3”, “number 6” and “number 9” buttons of the numerical keypad160and the “backspace button”168, is printed on the adhesive label270.

As also seen inFIG. 2(b), the smart card100B includes a microprocessor259having an integrally formed central processing unit (CPU)275and storage means276. The storage means276generally 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 elements154, application software code associated with the smart card100B and/or information (e.g. a personal identification number) associated with the user and/or manufacturer of the smart card100B. The smart card100B will hereinafter be referred to as the CPU card100B. The CPU card100B also includes electrical data contacts278connected to the microprocessor259and which perform a similar role to the contacts218ofFIG. 2(a). In particular, the electrical data contacts278can be used to send instructions to the microprocessor259and to receive data resulting from the execution of those instructions on the microprocessor259.

CPU cards such as the CPU card100B can be utilized in applications where enhanced user authentication and/or higher levels of security of the CPU card100B and data stored in the storage means276, 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 elements114and154can be interchanged for the smart cards100A and100B. Further, the user interfaces able to be printed by a user and/or manufacturer for the smart cards100A and100B can take many forms. Memory cards such as the memory card100A and CPU cards such as the CPU card100B, 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 card100A and the CPU card100B will be generically referred to as the smart card100.

1.2 Smart Card Reader

FIG. 3shows a smart card reader300configured for use with both the memory card100A and the CPU card100B. The configuration of the electrical data contacts218and278of the memory card100A and the CPU card100B, respectively, correspond to exposed contacts307of the smart card reader300, as shown inFIG. 3. The reader300is formed of a housing301incorporating a receptacle304into which the smart card100may be inserted, a viewing area306and an access opening310configured to accept a smart card100. An upper boundary of the viewing area306is defined by sensor means in the form of a substantially transparent pressure sensitive membrane308or simply “touch panel” spaced above the exposed contacts307so as to form the receptacle304. It will be appreciated by a person skilled in the relevant art that alternative technology can be used as the touch panel308. For example, the touch panel308can be resistive or temperature sensitive.

In use, a smart card100is inserted by a user into the smart card receptacle304, through the access opening310, as shown inFIG. 4. When the smart card100is fully inserted into the reader300, the touch panel308fully covers the upper face116,156of the smart card100. The viewing area306preferably has substantially the same dimensions as the upper face116,156of the smart card100such that the upper face116,156is, for all intents and purposes, fully visible within the viewing area306through the touch panel308. In this position, the data contacts218,278of the card100engage the exposed contacts307so that circuitry (not shown) within the reader300can communicate with the memory chip219or microprocessor259of the card100.

When the card100is fully inserted into the reader300, a user can press areas of the touch panel308, as shown inFIG. 5, overlying the user interface elements114,154. For the memory card100A, the reader300deduces which of the user interface elements114the user has selected by sensing the pressure on the touch panel308and referring to the data stored in the memory chip219. For example, if the user places pressure on the touch panel308adjacent the “kick button”124, the reader300is configured to assess the position at which the pressure was applied, refer to the stored data, and determine that the “kick button”124was selected.

In contrast, for the CPU card100B, the CPU275determines which of the user interface elements154the user has selected by processing coordinates received from the reader300upon the reader300sensing pressure on the touch panel308, and then the CPU275referring to the data stored in the storage means276of the microprocessor259. In this case, it is not necessary for the reader300to be able to read and to be made aware of the data stored in the storage means276of the microprocessor259. The operation of the CPU card100B in relation to the reader300will be explained in more detail in Sections 2.0 to 8.6 below.

Information resulting from a user selecting one of the user interface elements114,154can 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 elements114,154are not, in fact buttons. Rather, the user interface elements114are user selectable features which, by virtue of their corresponding association with the data stored in the memory chip219or storage means276, and the function of the touch panel308, operate to emulate buttons traditionally associated with remote control devices.

The reader300includes an infrared (IR) transmitter (not shown inFIG. 3), for transmitting information in relation to user interface elements114,154selected by the user. Thus, the reader300is generally referred to as an ‘infra-red’ reader. Alternatively, the reader300can any include any other form of transmitter such as a radio frequency (RF) transmitter. Upon selection of one of the user interface elements114,154, the reader300causes information related to the selection to be transmitted to a remote console (not shown inFIG. 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 reader300to a remote module, including direct hard wiring. Moreover, the remote module itself can incorporate a transmitter, and the reader300a receiver for communication in an opposite direction to that already described. The communication from the remote module to the reader300can include, for example, handshaking data, setup information, or any other form of information desired to be transferred from the remote module to the reader300.

FIG. 10is a schematic block diagram showing the internal configuration of the reader300in more detail. The reader300includes a microcontroller1044for controlling the reader300, for coordinating communications between the reader300and a remote module, and for storing mapping information and firmware, for example. The microcontroller1044includes random access memory (RAM)1047and flash (ROM) memory1046. The microcontroller1044also includes a core processor unit (CPU)1045. The microcontroller1044is connected to a clock source1048and a clock controller1043for coordinating the timing of events within the microcontroller1044. The CPU1045is supplied with electrical power from a battery1053, the operation of the former being controlled by a power controller1050. Alternatively, in one implementation, the CPU1045can 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 microcontroller1044is also connected to a beeper1051for giving audible feedback about card entry status.

Infra-red (IR) communications, as discussed above, can be implemented using two circuits connected to the microcontroller1044, an infra-red transmitter (TX)1049for infra-red transmission and an infra-red remote module (RX)1040for infra-red reception. The touch panel308of the reader300communicates with the microcontroller1044via a touch panel interface1041and the electrical contacts307.

An in-system-programming interface1052can also be connected to the microcontroller1044, to enable programming of the microcontroller1044with firmware by way of the microprocessor flash1046.

The microcontroller1044of the reader300preferably includes an associated ‘timer interface module (TIM)’1060contained within the microcontroller1044. The timer interface module1060preferably contains a counter, which can be programmed to overflow when the value of the counter reaches a specified value. Additionally, the timer interface module1060can be configured to change the value on an infrared transmission pin (not shown) associated with the microcontroller1044when the counter reaches the overflow value and another value, specified between zero and the overflow value. Thus, the timer interface module1060can be configured to generate a square wave controlling an infrared light emitting diode (not shown) associated with the infrared transmitter1049, operating at a specified frequency and duty cycle.

The clock source1048of the microcontroller1044can be configured as a crystal, for example, having an associated clock frequency (e.g., 4.92 MHz). The operating frequency of the clock source1048largely dictates the infrared data transmission rate of the reader300. Higher clock frequencies (e.g., 7.37 MHz) can be used to support faster infrared data transmission rates, which can be required by certain infrared data transmission protocols.

1.3 Hardware Architecture

FIG. 6(a) shows a hardware architecture of a card interface system600A. In the system600A, the reader300is hard wired to a personal computer system700via a communications cable603. Thus, for the configuration of system600A, the reader300does not require the infra-red transmitter (TX)1049for infra-red transmission or the infra-red remote module (RX)1040for infra-red reception. Such a reader will be specifically referred to hereinafter as a ‘hard wired’ reader. Alternatively, instead of being hardwired, the reader300including the infrared transmitter (TX)1049and the infrared remote module (RX)1040can be used with the system600A. In this case, an infrared transceiver654formed in the personal computer system700can be used to communicate with the reader300. The personal computer system700includes a display device701, a computer module702, a keyboard704and mouse703, and will be explained in more detail below with reference toFIG. 7.

The system600A includes the smart card100which is programmable and can be created or customized by a third party, who may be a party other than the manufacturer of the smart card100and/or the card reader300. The third party can be the ultimate user of the smart card100itself, or may be an intermediary between the manufacturer and user. In the system600A ofFIG. 6(a), the smart card100can be programmed and customized for one touch operation to communicate with the computer700and obtain a service over a computer network720, such as the Internet, coupled to the computer700. The computer700operates to interpret signals transmitted via the communications cable603from the reader300, according to a specific protocol, which will be discussed below. The computer700performs the selected function according to touched user interface elements114,154and can be configured to communicate data over the network720. In this manner, the computer700can permit access to applications and/or data stored on remote server computers650,652and appropriate reproduction on the display device701, by way of user manipulation of the reader300and card100.

FIG. 6(b) shows a hardware architecture of a card interface system600B. In the system600B, the reader300can be programmed for obtaining a service locally at a set top box601, that couples to an output interface, which in this example takes the form of an audio-visual output device616, such as a digital television set. The set-top box601operates to interpret signals612received from the reader300according to a specific protocol, which will be described below. The signals transmitted from the reader300are preferably infrared but may be electrical or radio frequency. The set top box601can be configured to perform the selected function according to touched user interface elements114,154and permit appropriate reproduction on the output device616. Alternatively, the set top box601can be configured to convert the signals612to a form suitable for communication and cause appropriate transmission to the computer700via the network720. The computer700can then perform the selected function according to the user interface elements114,154, and provide data to the set-top box601to permit appropriate reproduction on the output device616. The set top box601will be explained in more detail below with reference toFIG. 8.

In one application of the system600B, the smart card100can be programmed for obtaining a service either remotely or locally. For instance, the smart card100can be programmed to retrieve an application and/or data stored on remote server computers650,652, via the network720, and to load the application or data on to the set top box601. The latter smart card can be alternatively programmed to obtain a service from the loaded application on the set top box601.

Excepting where explicitly distinguished, the systems600A and600B ofFIGS. 6(a) and6(b) will be hereinafter generically referred to as the system600.

FIG. 7shows the general-purpose computer system700of the system600, which can be used to run the card interface system and to run software applications for programming the smart card100. The computer system700includes the computer module702, input devices such as the keyboard704and mouse703, output devices including a printer (not shown) and the display device701. A Modulator-Demodulator (Modem) transceiver device716is used by the computer module702for communicating to and from the communications network720, for example connectable via a telephone line721or other functional medium. The modem716can 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 module702typically includes at least one central processing unit (CPU)705, a memory unit706, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (I/O) interfaces including a video interface707, and an I/O interface713for the keyboard704and mouse703, a write device715, and an interface208for the modem216. The I/O interface713also includes the IR transceiver654connected to the I/O interface713for communicating directly with the reader300. A storage device709is provided and typically includes a hard disk drive710and a floppy disk drive711. A magnetic tape drive (not illustrated) is also able to be used. A CD-ROM drive712is typically provided as a non-volatile source of data. The components705to713of the computer module702, typically communicate via an interconnected bus704and in a manner, which results in a conventional mode of operation of the computer system702known to those in the relevant art. Examples of computers on which the arrangement described herein can be practiced include IBM-computers and compatibles, Sun SPARCstation or alike computer system evolved therefrom.

Typically, the software programs such as applications of the system600are resident on the hard disk drive710and read and controlled in their execution by the CPU705. Intermediate storage of the software application programs and any data fetched from the network720may be accomplished using the semiconductor memory706, possibly in concert with the hard disk drive710. 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 drive712or711, or alternatively may be read by the user from the network720via the modem device716. Still further, the software can also be loaded into the computer system702from 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 module702and 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 practiced without departing from the scope of the invention defined by the appended claims.

FIG. 8shows the set top box601of the system600, which can be used to interpret the signals612received from the reader300. The set top box601in some implementations essentially is a scaled version of the computer module702. The set top box601typically includes at least one CPU unit805, a memory unit806, 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 interface813for the digital television616, an I/O interface815having an IR transceiver808for receiving and transmitting the signals612, and an interface817for coupling to the network720. The components805,806,813,815and817of the set top box601, typically communicate via an interconnected bus804and in a manner which results in a conventional mode of operation. Intermediate storage of any data received from the reader300or network720may be accomplished using the semiconductor memory806. Alternatively, the set top box can include a storage device (not shown) similar to the storage device709.

1.4 Programming the Smart Card

As described above, the smart card100is programmable and can be created or customized by a third party. For example, with the system600, the smart card100can be programmed and customized for one touch operation to communicate with the set-top box601and/or computer700and obtain a service over the network720. The smart card100can be programmed by means of the write device715coupled to the I/O interface713of the computer module702. The write device715has the capability of writing data to the memory chip219on the memory card100A or the storage means276of the microprocessor259for the CPU card100B. Preferably, data is not able to be written to the storage means276unless a predetermined electronic key is first presented to the microprocessor259. Depending upon the specific implementation, the write device715may also be configured to print graphics on to the front surface116,156of the smart card100using image production software application programs. The write device715may also have a function for reading data from the smart card100.

The write device can be configured such that the user can insert the smart card100into the write device715and then enter the required data. A software application can then write the data entered by the user to the memory of the smart card100via the write device715. If the stored data is encoded for optical decoding such as in the case of a barcode memory card, the write device715can print the encoded data onto the memory card100A.

For the CPU card100B, the microprocessor259can be constructed so that once programmed in the manner described, the contents cannot thereafter be casually read.

1.5 Smart Card Data Format

The smart card100generally stores a data structure in memory219,276that describes various card properties and any user interface elements114,154printed on the smart card100. The smart card100can also include global properties that specify attributes such as information about the smart card100, 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 elements114,154printed on the surface of a corresponding smart card100.

For the memory card100A, data conforming to the format to be described can be copied directly into the memory chip219of the smart card100. For the CPU card100B, data conforming to the format to be described can be stored in the storage means276as a file being one file of a file system implemented on the CPU card100B. Such a file system will be described in detail below. In either case, to ensure that the cost of the smart card100can be kept to a minimum, the amount of data stored on the smart card100is kept to a minimum. For example, where the smart card100is being used as a music sampler and associated on-line service, the memory219,276of the smart card100does not contain the music itself. The smart card100only contains data associated with the user interface in the form of the user interface elements114,154and certain identifiers, which will be described in detail below. If the smart card100has limited storage capacity (e.g. in the case where the smart card100utilizes a barcode), the smart code100may 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 elements114,154imprinted directly on a surface of the smart card100, to commands or addresses (e.g.: Uniform Resource Locators (URLs)). The mapping data includes (X,Y) coordinates that typically define the size and location of user interface elements114,154on the smart card100. The user-interface objects are preferably stored in the memory219,276of the smart card100. Alternatively, the user-interface objects can be stored not on the smart card100itself, but in the system600. For example, the smart card100can store, via the memory219,276a barcode or a magnetic strip, a unique identifier, which is unique to smart cards100having substantially similar user interface elements114,154and layout. The unique identifier together with the coordinates determined from the touch panel308, as a result of a user press, can be transmitted by the reader100to the computer700or to the set top box601, of the system600.

The system600can have the user-interface objects stored on the computer700, set top box601or server650, 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 card100and a user selection of one of the user interface elements114,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 elements114,154as described above takes the form of coordinates determined by the microcontroller1044of the reader300as a result of a user applying pressure to a portion of the touch panel308which overlays the desired user interface elements114,154.

Data stored in the smart card100includes a card header followed by zero or more objects as described in the following sections.

1.5.1 Card Header

FIG. 11shows the data structure of a card header1100as stored in the smart card100. The header1100includes a number of rows1101, 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 field1102, which includes a constant specifying a smart card as being a valid memory card100A or CPU card100B. For example, the magic number field1102can be used to check or verify that a proprietary card belonging to a particular manufacture is being used;(ii) versions field1103, which includes each version increment that specifies a change in the smart card layout that cannot be read by a reader300which is compatible with lower versions of the layout;(iii) reserved field1104, this field is reserved for future use;(iv) flags field1105, which includes flags for a smart card (see Table 2 below);(v) card identifier field1110, which includes two fields—a service field1106and a service specific field1107. The service field1106identifies the service of a corresponding smart card100and the service specific field1107optionally contains a service-specific value;(vi) a number of objects field1108, which includes a number value representing how many objects follow the header1100. This field can be set to zero; and(vii) a checksum field1109, which includes a card checksum of all data on a corresponding smart card100excluding the checksum itself.

Table 1 below provides a description of the content of the various (number) fields described with reference toFIG. 11.

TABLE 1FieldNumberDescription (Card Header)MagicTwo byte magic number. A constant that specifies this asNumberbeing a valid card. Currently defined as the ASCII valuefor ‘i’ followed by the ASCII value for ‘C’.VersionOne byte version number. Each version increment specifies achange in the card layout that can not be read by a reader thatis compatible with lower versions of the layout. Thisdocument describes version 1(0x01) of the card format.ReservedThis data is reserved for future use. Its value must beset to zero.FlagsFour bytes of flags for this card. (See Table 2). All non-assigned bits must be zero.CardEight byte card identifier. Card identifiers include twoIdentifierfields - service identifier and service-specific identifier. Theservice identifier is five bytes and identifies the serviceassociated with the card. The service-specific identifier isthree bytes of service specific value.NumberOne byte. The number of objects following this header.ofCan be zero.ObjectsChecksumCard checksum, 2 bytes. The card checksum is sixteen bit,unsigned integer sum of all data bytes on the card excludingthe checksum.

The card identifier field1110comprises 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 field1106may 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 card100as 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 system600. Generic smart cards are smart cards100having 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 system600. For example, a smart card100having a keypad user interface that can be used to send text input to an application which has focus or a smart card100with personal details that can also be used to submit the personal information stored on the smart card100to any application.

A smart card100identification authority can assign service identifiers to a vendor when the vendor registers a particular service.

The service-specific identifier contained in the field1107, 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 being executed on the system600. For example, the service identifier together with the service-specific identifier can be used as a unique identifier for a card100. This unique identifier can be used by an application 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 card100having 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 (e.g.: 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 cards100(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 system600when 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 field1107.

1.5.2 Card Flags

The flags field1105of the header1100ofFIG. 11can include three flags.

For the memory card100A and the CPU card100B, the flags of the flags field1105are as follows:

(ii) Background Move; and

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 card100can perform in a reader300, as is defined by the description of each flag.

TABLE 2NameDescriptionValue (hex)BackgroundCauses the reader to provide audio feedback0x0000 0001Beepwhenever the background is touched.BackgroundCauses the reader to send all move events0x0000 0002Movefrom when the touch panel was pressed onthe background until the touch panel isreleased.Don't ReportCauses the reader to suppress reporting of0x0000 0004Backgroundthe co-ordinates of all presses and releases ofCo-ordinatesthe touch panel, when they correspond tothe background, reporting them insteadas (0xFF, 0xFF).
1.5.3 Objects

As shown inFIG. 12, immediately following the card header1100ofFIG. 11can be zero or more object structures1213defining the objects of a particular smart card100and forming part of the data stored on the smart card100. Each object structure1213comprises four fields as follows:(i) a type field1201;(ii) an object flags field1203;(iii) a length field1205; and(iv) a data field1207.

The structure of the data field1207depends on the object type as will be described below.

Table 3 below shows a description of each of the fields1201,1203,1205and1207of the object structure1213.

TABLE 3NameDescription (Object Structure)LengthTypeThe type of object (see Table 5).1 byteObject FlagsThe general object flags that are associated1 bytewith this object (see Table 4). Note: Additionalflags specific to an object type are specifiedwithin the data field of the object.LengthThe length of the data following this object.2 bytesThis value can be zero.DataThe data associated with this object. TheVariablestructure of this data is dependent on the typeof object.

The flags field1203of the object structure1213, preferably includes an inactive flag and an extended data format flag. Table 4 below shows a description of the inactive flag and the extended data format flag.

TABLE 4NameDescription (Pre-Object Flag Values)Value (hex)InactiveIndicates to the reader that the object is valid0x01but is to be ignored regardless of object type.ExtendedSee section 1.6.3.2.1 below.0x02DataFormat

For the smart card100, there are preferably six object types provided, as follows:(i) User Interface Element;(ii) Card Data;(iii) Fixed Length Data;(iv) Reader Insert;(v) No operation; and(vi) No operation (single byte).

Table 5 shows a description of each of the above object types (i) to (vii).

TABLE 5ValueNameDescription)(hex)No operationA single byte object that doesn't have a0x00(single byte)standard object header. Used to fill spaces onthe card, which are too small for a normalobject header.No OperationAn object that is used to fill blocks of empty0x01space on the card.User InterfaceA user interface element.(inline)Element0x10Card DataContains data that relates specifically to this0x20card. Card data would normally be read by thereader and transmitted as part of the INSERTmessage on card insertion.Fixed lengthAn object that can be used to store fixed length0x30Datablocks of data on the card.Reader InsertAn object that can be used to give instructions0x40to the reader when the card is inserted.
1.5.3.1 User Interface Element Objects

Each of the user interface element objects of Table 5 define a rectangular area on a smart card100and some quantity of associated data that is used to generate an output when the user touches an area of the touch panel308over the corresponding rectangular area of the smart card100. The origin for the coordinate mapping system is the top left of the smart card100in accordance with an International Standards Organization standard smart card held in a portrait view with the chip contacts218,278facing away from the viewer and towards the bottom of the smart card100. For any reader300that does not use this card orientation, the values of corner points on the smart card100must be adjusted by the reader300for the memory card100A or by the CPU275for the CPU card100B, 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 X1field;(iii) an Y1field;(iv) an X2field;(v) a Y2field; 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 as well as optional commands reconfiguring some aspects of the reader300.

Table 6 shows a description of each of the above fields for the described user interface element object structure. A press on the touch panel308is 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 X1value of the associated user interface element object and is strictly less than the X2value for that particular user interface element object; and(ii) the Y value for the press location is greater than or equal to the Y1value of the particular user interface element object and strictly less than the Y2value.

TABLE 6FieldDescription (User Interface Object Structure)SizeFlagsFlags specific to this user interface element on the1 bytecard.X1X value of the top-left hand corner co-ordinate of this1 byteobject's rectangle.Y1Y value of the top-left hand corner co-ordinate of this1 byteobject's rectangle.X2X value of the bottom-right hand corner co-ordinates1 byteof this object's rectangle.Y2Y value of the bottom-right hand corner co-ordinate of1 bytethis object's rectangle.DataZero or more bytes of data associated with this object.VariableIn memory cards, the actual data is always storedwithin this field. The size of this field is determined bythe object data size minus the combined size of theabove 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 elements114,154on the smart card100defines the Z ordering for all of the user interface elements on that particular smart card100. The top user interface element is the first user interface element for a particular smart card100. The bottom user interface element is the last user interface element for that particular smart card100. 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 Standards Organization memory smart card and the width is defined to be 1/128th of the width of an International Standards Organization memory smart card.

The behavior associated with each user interface element114,154may be modified using one or more flags. For both the memory card100A and the CPU card100B, each user interface element154preferably 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 7NameDescriptionValueBeepThis flag causes the reader to beep when the user0x01interface element is pressed.MoveThis flag instructs the reader to send all0x02subsequent move events until the touch screen isreleased.Don't ReportThis flag instructs the reader to suppress reporting0x04Co-ordinatesof the co-ordinates of the associated press orrelease, reporting them instead as (0xFF, 0xFF).Auto-repeatThis element automatically repeats when the press0x08is held on the element.Don't SendThis causes the associated user interface element0x10Datanot to send the data associated with this useron Pressinterface element in the press event. The defaultis to send the data associated with the userinterface element in the press event.Don't SendThis causes this user interface element not to send0x20Datathe data associated with this user interface elementon Releasein the release event. The default is to send thedata associated with the user interface element inthe release event.
1.5.3.2 Card Data

The card data object is used to store data which is specific to a particular card100. The data layout for this object has no fixed form. The contents of the card data object are transmitted from the reader300as part of an INSERT message when the smart card100is inserted into the reader300.

1.5.3.3 Extended Data Format

User interface element data stored in user interface element and card data objects may come in two formats: standard data format and extended data format. In standard data format, all data is transmitted by the reader300. In extended data format, the data itself is broken up into a sequence of “sub-objects”, most of which contain information that instructs the reader300to change some aspect of the reader300operation (i.e. operational characteristics). The format of the sub-objects, with the exception of the Output Data sub-object, is shown in Table 8 below.

TABLE 8NameDescriptionSizeTagA tag identifying the type of object1 byteLengthThe length of the data associated with the object1 byteValueThe data associated with the objectLengthBytes

The structure of the tag portion of a sub-object depends on the value of the most significant bit, and is structured in one of the formats2301and2302shown inFIGS. 23(a) and (b), respectively. For both of the tags2301and2302, the bits labelled X indicate the type of sub-object associated with the tag.

If the tag2301has a most significant bit2303which is set, as seen inFIG. 23(a), a non-global change is effected in the reader300upon the processor1045reading the tag2301. In this instance, if the second least significant bit2305is set to zero then the associated non-global change is designated to be card specific, meaning that the effect of the change will be lost when the corresponding card100is removed from the reader300, or when the effect is modified by another sub-object of the same type. In addition, the least significant bit2307indicates whether a new setting is to override a current global setting (i.e., indicated by the bit2305being set to zero) or for the reader300to toggle between the new setting and the global setting (i.e., indicated by the bit2305being set to one). Alternatively, if the second least significant bit2305is set to one then a temporary change is invoked, where the value of the least significant bit2307indicates whether or not the effect of the temporary change is to extend through to a following user interface element114,154selection by a user.

A most significant bit2307which is not set, as seen for the tag2302ofFIG. 23(b), indicates that a global change will be effected in the reader300upon the processor1045detecting the tag2302. In this instance, the change is not dependent on the presence of the card100in the reader300or on a certain time period elapsing.

For the smart card100, there are preferably ten sub-object types defined, as follows:(i) Output Data;(ii) Change user identifier;(iii) Change global reader application message protocol;(iv) Change global mouse protocol;(v) Change global keyboard protocol;(vi) Change global remote control protocol;(vii) Download Custom protocol module;(viii) Delete protocol modules;(ix) Change temporary transmission protocol; and(x) Change modifier flags.

An instance of object data1207can include any one or more of the above sub-objects types (i) to (x). Table 9 shows a description of the above sub-object types (i) to (viii). A tag (e.g., the tag2800) associated with each of the sub-objects (i) to (viii) has a most significant bit which is set to zero.

TABLE 9NameDescriptionType ValueOutput dataThis sub-object represents the actual output data0x00associated with the object, and omits the lengthfield to conserve space. The length of the outputdata is calculated by subtracting the length of allother sub-objects together with the output data tagfrom the length of the entire object. Thus, this sub-object spans the entire area from the tag to the endof the object that encloses the sub-object.Change userTwo bytes are reserved in memory 1047 for a user0x01identifieridentifier. This user identifier may be inserted by aprotocol module format function, which will bedescribed in section 4.0 below, into any messagesthat are sent. This sub-object sets the useridentifier to the data stored in the first byte of thevalue field of the sub-object.Change globalThe transmission protocol specified by this object0x04reader applicationshould be used as a global reader applicationmessage protocolmessage protocol for a particular transmissionmode. The data in this sub-object contains onebyte identifying the protocol, possibly followed byother bytes specifying other parameters specific to theprotocol being selected.Change globalThe transmission protocol specified by this object0x05mouse protocolshould be used as a global mouse protocol for aparticular transmission mode. The data in thissub-object contains one byte identifying theprotocol, possibly followed by other bytesspecifying other parameters specific to theprotocol being selected.Change globalThe transmission protocol specified by this object0x06keyboardshould be used as a global keyboard protocol for aprotocolparticular transmission mode. The data in thissub-object contains one byte identifying theprotocol, possibly followed by other bytesspecifying other parameters specific to theprotocol being selected.Change globalThe transmission protocol specified by this object0x07remote controlshould be used as the global remote controlprotocolprotocol for a particular transmission mode. Thedata in this sub-object contains one byteidentifying the protocol, possibly followed byother bytes specifying other parameters specific tothe protocol being selected.DownloadAn infrared protocol module is stored in the value0x08customfield of this sub-object, and should be loaded intoProtocol modulethe reader. The newly loaded protocol is activatedin any way - an additional sub-object is isrequired.Delete infra-redThe list of protocol modules is searched for0x09protocols modulemodules with identifiers that match any of thoseprovided in the data bytes of this sub-object. Alldiscovered matching modules are deleted.

Table 10 shows a description of the above sub-object types (ix) and (x). A tag (e.g., the tag2800) associated with each of the sub-objects (ix) to (x) has a most significant bit which is set to one.

TABLE 10TypeNameDescriptionValueChangeThe infrared protocol identifier by this object0x1temporaryshould be used. The data in this sub-objecttransmissioncontains one byte identifying the protocol,protocolpossibly followed by other bytes specifying otherparameters specific to the protocol being selected.ChangeA special reader buffer contains a set of flags,0x2modifierwhich toggle certain modifier bits, which can beflagsapplied to outgoing messages. For example, in akeyboard protocol, pressing a SHIFT key mightcause the following character to be transmittedwith a bit that indicates that a SHIFT key is beingheld down.

Typically only the “object data” sub-object should be processed on release events, as described above.

Table 11 shows a description of the functions that each of the above flags (i) to (xvi) represent in order to emulate a mouse, keyboard or remote control protocol using a card such as the smart card100.

TABLE 11NameDescriptionValueLShiftThe left shift key is currently being held down0x8000RShiftThe right shift key is currently being held down0x4000LCtrlThe left control key is currently being held down0x2000RCtrlThe right control key is currently being held down0x1000LaltThe left alt key is currently being held down0x0800RaltThe right alt key is currently being held down0x0400LwinThe left windows key is currently being held0x0200downRwinThe right windows key is currently being held0x0100downMenuThe menu key is being held down0x0080FnThe function key is being held down0x0040CapsLockThe Caps Lock function is currently active0x0020NumLockThe Num Lock function is currently active0x0010ScrollLockThe Scroll Lock function is currently active0x0008LbuttonThe left mouse button is being held down0x0004ScrollLockThe Scroll Lock function is currently active0x0008MbuttonThe middle mouse button is being held down0x0002RbuttonThe right mouse button is being held down0x0001

Typically, when processing of a sub-object is performed successfully, the reader300sounds a high-pitched BEEP. Conversely, if a failure condition occurs, a low-pitched beep, referred to herein as a ‘BOOP’ occurs to notify the user of a problem. If a temporary change is effected by a sub-object (e.g. a temporary protocol change or modifier flag change), no beep occurs on successful completion, but a low-pitched BEEP (i.e., a BOOP) is still sounded if a problem occurred during the change.

1.5.3.4 Fixed Length Data

The fixed length data object is used to define a fixed length block on the smart card100that can be written to by the computer700, for example.

1.5.3.5 Reader Insert

The reader insert object is used to store instructions for the reader300when a particular smart card100is inserted. This can be used, for example, to instruct the reader300to use a specific configuration of infra-red commands to allow communication with a specific set top box (e.g.601) or TV.

1.5.3.6 No Operation

The No Operation object is used to fill in unused sections between other objects on a particular smart card100. Any data stored in the no operation object is ignored by the reader300. Any unused space at the end of the smart card100does not need to be filled in with a no operation object.

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.6 Reader Application Protocol

When not operating in keyboard, remote control or mouse emulation mode, the reader300uses a high-level datagram protocol that supports both uni-directional and bi-directional communication between the reader300and the set top box601or computer700, for example, referred to as the reader application protocol. The format used for messages from the reader300as a result of user interactions with the smart card100are of a different format than those that are transmitted to the reader300. The messages defined by the reader application protocol can be broken up into fragments at a lower level, depending on the low-level transmission protocol that is currently in use.

1.6.1 Message Types

There are at least seven message event types that can be transmitted by the reader300. These message events are as follows:

(i) INSERT: When a smart card100is inserted into the reader300, and the smart card100is validated, an INSERT event is generated by the reader300and an associated message is transmitted. This message announces the smart card100to a remote module (e.g. the set top box601). The INSERT message preferably can include the particular card identifier and allow applications to be started or fetched immediately upon the smart card100insertion rather than waiting until the first interaction takes place. The INSERT message preferably includes the contents of the card data object from the smart card100inserted into the reader300if an object of this type is present on the smart card100.

(ii) REMOVE: When a smart card100is removed from the reader300, a corresponding REMOVE event is generated and a REMOVE message is transmitted to the particular remote module associated with the reader300. 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 card100, the card identifier is stored in the memory1047of the reader300. This is a useful optimization as the card identifier is required for all other messages and reading the card identifier from the smart card100each time the card identifier is required can be too slow. INSERT and REMOVE messages are not relied upon by the system600to control processing. The system600is 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 card100of the first INSERT message, as typically two smart cards100are not inserted into the reader300at 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 reader300as shown inFIG. 6(b), as compared with a wired reader300as shown inFIG. 6(a), is being used. Often a user does not point the reader300directly at a remote module when inserting or removing cards. This problem can be corrected by the system600inferring the INSERT or REMOVE operations based on differing card identifiers in consecutive PRESS and RELEASE pairs.

(iii) BAD CARD: If an invalid smart card100is inserted, then the reader300is 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 card100.

(iv) PRESS: When a touch is detected by the reader300, a PRESS event is generated and a PRESS message is transmitted 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 card100at all) a PRESS message is transmitted containing details of the associated smart card100and the position of the press. If there is no card present in the reader300when a PRESS event is generated then a PRESS message is transmitted 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 transmitted in order to inform an application program of the system600that 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 card100) is assumed to be moving. MOVE events are generated and MOVE messages are transmitted 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 transmitted when the battery1053in the reader300is getting low. This message is transmitted after user interactions to increase the chance that the message will be received by the rest of the system600. The sending of the LOW BATT message does not prevent the reader300from entering a low power state.

As described above, the card identifier is included in every INSERT, REMOVE, PRESS, RELEASE and MOVE message transmitted from the reader300to the computer100or set-top box601. As an alternative, the card identifier can be transmitted in connection with an INSERT message only. In this instance, upon insertion of a new smart card100, the reader300generates 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 card100is inserted and reset to zero when a predetermined value is reached. In this case, the reader300sends an INSERT message to the computer700or the set-top box601, which includes a card identifier as previously described above and a session identifier which is generated for each new smart card100insertion. 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 system600operates as described above with reference toFIGS. 6(a) and6(b), except that the set-top box601or similar, upon receiving an INSERT message from the reader300, stores the session identifier as the current session identifier and a card identifier as the current card identifier. When the set top box601receives a PRESS, RELEASE or MOVE message, the CPU805checks that the session identifier is equal to the current session identifier. If so, the CPU805sets 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 CPU805informs the user, via the audio-visual output device616, that a message has been received without a corresponding INSERT message. The user, for example, is then requested to remove and reinsert the card100.

1.6.2 Data Formats

The data format of the reader300protocol used in the system600is a fixed size header followed by a variable length data field which can be zero bytes or more in length, followed by an eight bit check-sum and complement.

1.6.3 Message Header

The message header is preferably of a fixed length and is prepended to (i.e. appended to, but in front of) all messages transmitted from the reader300to a set top box601for example. It is necessary to keep the message header as small as possible due to any bandwidth restrictions that may be imposed. Table 12 below shows the format of the message header that is transmitted from a reader300to a remote module such as the set top-box601for example. The service and service-specific identifier are the same for a given smart card100. A service specific identifier is preferably set by a vendor for use with their application. The reader identifier (ID) of Table 12 is also in the header of each message. The reader identifier can be used by an application executing on a server (e.g. the servers650,652) to distinguish different users, for example, in a multi-player game application.

TABLE 12FieldDescription (Message Header Format)BytesPreamblePreamble to the message. Value is always 0xAA20x55 (bit sequence 10101010 01010101). This is tomake it easier for a receiving device (e.g., the settopbox 601) find the beginning of a message.VersionThe version of the user interface card infrared1message protocol this messages uses. This versionof the protocol is version 1(0x01 in the versionfield)TypeType of message. This is one of the values given in1Table 10.ReaderThe 16 bit id of the reader that transmitted the2Identifiermessage. This number is a pseudorandomgenerated number that is changed when the batteryis replaced in the reader. This is needed todistinguish readers when multiple readers are beingused with applications.ServiceService identifier as stored on the card.5IdentifierService-Service-specific identifier as stored on the card.3specificIdentifier

Table 13 shows a table listing the message event types that have been described above.

TABLE 13NameDescription (Message Type Codes)CodeINSERTA card has been inserted into the reader.‘I’REMOVEThe card has been removed from the reader.‘E’PRESSThe touch panel has been pressed.‘P’RELEASEThe press on the touch panel has been released.‘R’MOVEThe press position has moved but the press has‘M’not been released.BADCARDA card has been inserted however it has not‘B’passed validation.LOW_BATTThe battery in the reader is getting flat.‘L’
1.6.3.1 Simple Messages

A number of message types are considered simple in that they consist solely of the 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 simple messages. Table 14 shows the format of a simple message.

TABLE 14FieldDescription (Simple Message Format)BytesHeaderMessage header as defined in Table 11.14ChecksumMessage checksum. This is the sum of all the bytes1in the message.Checksum'The 1's complement of the checksum.1
1.6.3.2 Move Messages

MOVE messages are formed of the message header described above followed by two fields defining the coordinates of the touch position on the touch panel8of the reader300. Table 15 shows the format of a MOVE message.

TABLE 15FieldDescription (Move Message Format)BytesHeaderMessage header as defined in Table 11.14XThe X co-ordinate of the touch position.1YThe Y co-ordinate of the touch position.1ChecksumMessage checksum. This is the sum of all the bytes1in the message.Checksum'The 1's complement of the checksum.1
1.6.3.3 Press and Release Messages

Table 16 below shows the format of PRESS and RELEASE messages. PRESS and RELEASE messages, like MOVE messages contain the message header and touch coordinates. In addition, PRESS and RELEASE messages send data associated with a user-interface element if the touch position matches a user-interface element object defined on the smart card100. This data is of variable length, the actual size being defined by a corresponding smart card100. If the touched position does not match a user-interface element object defined on the smart card100(including if no user-interface elements are defined on the smart card100), zero bytes of data associated with user interface elements are sent. If there is no smart card100in the reader300then the service identifiers are all set to zero (i.e. 0x00) and zero bytes of data associated with the user-interface elements are transmitted to the remote module. The data associated with the user interface element normally corresponds to the data associated with the user interface element defined on the smart card100but may be modified or generated by processing on the smart card100or reader300.

TABLE 16FieldDescription (Press and Release Message Format)BytesHeaderMessage header as defined by Table 11.14XThe X co-ordinate of the touch position.1YThe Y co-ordinate of the touch position.1LengthThe number of bytes of data. Can be zero.2DataThe data associated with the user interfaceLengthelement.ChecksumMessage checksum. This is the sum of all the1bytes in the message.Checksum'The 1's complement of the checksum.1
1.6.7 Insert Messages

INSERT messages are formed of the message header described above and the contents of the card data object from an inserted smart card100. Table 17 below shows the format of an INSERT message.

TABLE 17FieldDescription (INSERT Message Format)BytesHeaderMessage header as defined in Table 11.14LengthThe number of bytes of data. Can be zero.2DataThe data from a Card Data object on the card.LengthChecksumMessage checksum. This is the sum of all the1bytes in the message.Checksum'The 1's complement of the checksum.1

FIG. 13is a data flow diagram showing the flow of the above-described messages within the system600for a smart card100. The card header1100and object structure1213are read by the CPU1045of the reader300which sends a corresponding INSERT, REMOVE, PRESS, RELEASE, MOVE, BADCARD or LOW BAT message to the set top box601, for example. The reader300can also send remote control data, keyboard data and mouse data to the set top box601.

The operation of the system600will now be further explained with reference to the following example. The system600is customizable by virtue of a user being able to utilize a number of different smart cards100to perform corresponding different operations. For example, with particular reference to the system600B,FIG. 14(a) shows a memory card100C which according to the user interface elements1414printed 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 system600B using the memory card100C and then purchased using a CPU card100D configured for use with an electronic banking application, as will be explained below with reference toFIGS. 15(a) and15(b). A person skilled in the art would appreciate that the CPU card100D could be replaced by a memory card similar to the card100A. Other functions may be performed on the system600B, using different smart cards100, such as home shopping, ordering home delivery fast food such a pizzas, and the like. In each instance, insertion of an appropriate smart card100into the reader300causes a corresponding computer application to commence operation, either within the set-top box601or the computer system700, in order to service user commands entered via the reader300and to return appropriate information for audio-visual feedback to the user.

For the memory card100C, on-line music is provided as data to the set-top box601which permits reproduction of audio and any related visual images on the output device616or the display701of the computer system700. The user interface elements1414of the memory card100C 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”1411and a two-way directional controller1413, printed on a front face1416of the memory card100C.

FIG. 14(b) is a table showing user interface element objects (e.g.1431) associated with each of the user interface elements1401to1417. The user interface element objects (e.g.1431) are stored in a memory (not shown) formed within the memory card100C similar to the memory219of the memory card100A. As described above with reference to Table 6 and as shown inFIG. 14(b), each of the user interface element objects (e.g.1431) has six fields being a flags field1420, an X1field1421, a Y1field1422, an X2field1423, a Y2field1424and a data field1425, describing the position of and data associated with a corresponding user interface element. For example, the flags field1420for the select button1409is a one byte field set to a hexadecimal value of ‘0x020’ (0x representing hexadecimal notation), indicating that data associated with the select button1409is not to be transmitted in a release event, as described above with reference to Table 7. The X1field1421associated with the select button1409is a one byte field set to a value of ‘0007’ indicating the coordinate value of the bottom left hand point1431of the user interface element1409with respect to the top left point1433of the memory card100C, as described above with reference to Table 6. The data field1425is a variable size field which in the case of the select button1409is a value corresponding to an ‘Enter’ and/or ‘Carriage Return’ function.

The memory card100C 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 card100and is normally transmitted as part of an INSERT message, upon the smart card100being inserted into the reader300. In the case of the memory card100C, 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 card100C in a digital format corresponding to the ASCII values of the characters making up the URL. Alternatively, a card identifier can be stored in the memory of the memory card100C and can be mapped to the URL.

The memory card100C also includes a card identifier, as described with reference to Table 1, stored in the memory of the memory card100C. The card identifier includes a service identifier which in the case of the memory card100C can be mapped to the URL, ‘www.bluesguitarmasters.com’, corresponding to the address of the ‘Blues Guitar Masters’ Internet site. 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 card100associated with the ‘Blues Guitar Masters’ Internet site, for example, can have a different service-specific identifier.

For the CPU card100D, the user interface elements1514are in the form of a numerical keypad1560, an “OK button”1562, a “cancel button”1564, a “clear button”1566, a “backspace button”1568, and a four way directional controller1570printed on the front face1556thereof.

Similar to the memory card100C, each of the user interface elements1514of the CPU card100D has at least one associated user interface element object (e.g.1531) stored in a storage means (not shown) formed within the CPU card100D similar to the storage means276of the CPU card100B. Again, as described above with reference to Table 6 and as shown inFIG. 15(b), each of the user interface element objects (e.g.1531) has six fields being a flags field1520, an X1field1521, a Y1field1522, an X2field1523, a Y2field1524and a data field1525, describing the position of and data associated with a corresponding user interface element. For example, the X1field1521associated with the “number 2 button”1540of the numerical keypad1560, is a one byte field set to a value of “0005” indicating the coordinate value of the bottom left hand point1541of the user interface element1540with respect to the top left point1533of the CPU card100D. The data field1525of the “number 2 button”1540is a variable size field which in the case of the CPU card100D value corresponds to a hexadecimal representation corresponding to the ASCII value of the character ‘2’.

The CPU card100D also includes a card data object, as described above with reference to Table 5. In the case of the CPU card100D, 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 card100D in a digital format corresponding to the ASCII values of the characters making up the URL.

Similar to the memory card100C, the CPU card100D also includes a card identifier, as described with reference to a Table 1 stored in the storage means of the CPU card100D. The card identifier includes a service identifier, which in the case of the CPU card100D 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 card100B associated with the electronic banking package, for example, can have a different service-specific identifier.

FIG. 16is a flow diagram showing the steps1600performed by a user in order to retrieve on-line music associated with the Blues Guitar Masters Internet site, over the card interface system600B. At the initial step1601, the user inserts the memory card100C into the reader300. As will be explained in further detail later in this document, having inserted the memory card100C into the reader300, an application associated with the Blues Guitar Masters Internet page commences, for example on the server computer650, and returns to the set-top box601for display on the output device616a first menu screen1720, as seen inFIG. 17(a), relating to a function to be performed, in this case a selection of Blues Guitar Masters. Then at the next step1603, using the reader300to select the two-way directional controller1413, 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 screen1722, as seen inFIG. 17(b), is then displayed on the output device616advising the user of the possible selections that may be made. At the next step1605, the user scrolls the menu screen1722by selecting the two-way directional controller1413, and makes a further desired selection. In response to the user's selection at step1605, a further menu screen1724is then displayed on the output device616as seen inFIG. 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 step1605, depending on the ‘Quality of Service’ that the user wishes to access from the Blues Guitar Masters Internet site. For example, if the user only wishes to access a one-minute free sample of the video clip corresponding to the selection at step1605, then the user can select the ‘Free Sample’ item1726on the menu screen1724. Otherwise, the user can select the ‘Full Concert Video’ item1728which will require the user to pay some associated fee for service. At the next step1607, the user selects the ‘Full Concert Video’ item1728. In response to the user's selection at step1607, a further screen1730is then displayed on the output device616as seen inFIG. 17(d) advising the user to insert a payment card (e.g. the CPU card100D) into the reader300. The screen1730also advises the user of the fee amount and of a ‘Biller Code’ associated with the vendor of the Blues Guitar Masters Internet site. At the next step1609, the user removes the memory card100C and inserts the CPU card100D into the reader300. In accordance with the present example, at the next step1611, the user presses one or more user interface elements154representing a personal identification number (PIN) by applying pressure to the touch panel308on or adjacent to each of the associated user interface elements154. As will be explained in further detail later in this document, in response to the user entering the personal identification number, the CPU card100D can buffer the personal identification number in an input buffer and compare the buffered personal identification number to a personal identification number stored in a storage means (not shown) of the CPU card100D. If the CPU card100D determines that the entered personal identification number is identical to the stored personal identification number then an application associated with the banking application Internet site commences, for example on the server computer652, and returns to the set-top box601for display on the output device616a conventional banking application menu screen relating to a function to be performed, in this case a selection enabling the payment of the specified amount to the vendor identified by the displayed biller code. At the next step1613, the user utilizes the user interface elements1514of the CPU card100D to operate the banking application in order to complete payment for the full concert music video of the young dead guy. Once payment is completed, the Blues Guitar Masters application then retrieves the selection (i.e. the full concert music video of the Young Dead Guy), which is then streamed to the set-top box616for appropriate output as seen inFIG. 17(e). Since the music video is, in effect, a series of “live” images, as compared to the substantially static images of the menu screens1720,17221724and1730, the music video may advantageously be obtained and/or streamed from another location on the computer network720not associated with the generation of the menu screens1720,1722,1724and1730.

2.0 Reader Infra-Red Data Transmission Architecture

As described above, the reader300is a hand-held, battery powered remote control device that interfaces a substantially transparent touch panel308with a smart card100to provide a customizable user interface. The reader300can be used with audio-visual output device616/set top box601equipment to provide a simple, intuitive interface to consumer services in a home environment.

Any suitable transmission method can be used to communicate information from the reader300to a remote appliance module, including direct hard wiring, as described above. When the reader300is directly hard-wired to a device (e.g. the computer module702), for example, as shown in the system600A ofFIG. 6(a), the reader300is configured primarily to act as a user input device for personal computers (e.g. the computer system700).

Alternatively, when the reader300is configured for infra-red data transmission, for example, as shown in the system600B ofFIG. 6(b), the reader300can be programmed for obtaining a service locally at a set top box601, that couples to an output interface, which in this example takes the form of an audio-visual output device616, such as a digital television set. The reader300can also be used to control any appliances that are fitted with an infra-red receiver, and which have been conventionally been controlled using an infra-red remote control device, keyboard, pointing device, or some combination of the three. Unfortunately, for various reasons, there is no standard protocol used by various infrared devices.

One advantage of the reader300, as described herein, is that the reader300does not operate exclusively using one infrared protocol so that the reader300is not restricted to a particular group of set-top boxes, or a single vendor of receiving equipment at the expense of others.

The reader300infrared data transmission architecture as will be described herein, firstly, allows the transmission of data using a wide variety of different infrared protocols that are already in use today. Secondly, the architecture provides a framework allowing easy porting of a range of different protocols to a user of the reader300by providing common firmware functions which rely on properties specified by an author, rather than requiring the author to rewrite much of the firmware code. Thirdly, the architecture provides a framework that allows custom protocols to be independently loaded easily into the reader300after the reader300has been deployed without affecting other protocols already installed in the reader300. Fourthly, the architecture allows a smart card100to determine the infrared protocol to be used while the card100is inserted. Fifthly, the architecture allows a single user interface element to change a currently active protocol for a period of time. Such a period may range from a momentary change valid only while the current user interface element is active, through a change valid while a particular card100is present in the reader300, to a persistent change that is valid until another persistent change is requested. Such a persistent change remains effective for any subsequent cards that are inserted, unless the persistent change is overridden by the same or a different card100.

The reader300can use many infrared protocols for data transmission. Although, the protocols differ in some aspects, there are several common attributes that are shared by a majority of the protocols, as will be discussed below.

2.1.1 Device Modes

As described above, with reference to Tables 9 and 10, the reader300can be effected in any one of four different device modes. Three of these device modes represent other existing devices (i.e., remote control, keyboard and mouse). The other device mode represents the reader application protocol. Remote control and keyboard messages are transmitted by the CPU1045of the reader300only during PRESS and RELEASE events, as described above. Raw data for these device modes can differ from protocol to protocol. For example, in one protocol the ‘A’ key is represented by the code 0x12, while in another protocol the ‘A’ key is represented by the code 0x1e.

Further, mouse messages are only transmitted during MOVE events. Raw data for mouse messages can differ from protocol to protocol. For example, one type of mouse device might report absolute coordinates, while another type of mouse device reports co-ordinates relative to the last position.

2.1.2 User Interface Card Messages

The user interface card reader device mode is used exclusively for messages sent according to the reader application protocol. As described above, at the application level, each message transmitted from the reader300to the set top box601or computer system700consists of a sequence of bytes, having a fixed length header1100, a variable length body comprising zero or more object structures1213. The length of the message is determined by values transmitted within the message header1213and the number of objects transmitted. In order to be transported by a particular protocol, a card message must typically be broken up into several fixed size packets.

On the other hand, when the reader300is sending remote control, keyboard or mouse messages, which typically transmit one or two bytes of data, each individual packet contains all of the message data for a particular message.

2.1.3 Packet Format

The structure of a message can vary from protocol to protocol. At the highest level, each message can be split up into one or more packets separated by an inter-packet gap2411. Preferably, a single packet is utilized per message. The inter-packet gap2411is preferably of a set period during which the device does not transmit any data. Such a gap2411is used to ensure that repeated messages do not transmit more than necessary, which would increase the rate of battery drainage. As particularly seen inFIG. 24, a packet2401of a message2410can consist of one or more frames2402,2403and2404, each of which consists of data2405enclosed by start2406and stop2407bits and optional parity bits2408.

While some of the data2405can be used to encode command data, other portions of the data2405can be used to encode object information such as a device identifier, a user identifier or error detection/correction codes.

As described in the Background section, the rate at which an LED is flashed ON and OFF is referred to as the “carrier frequency”, and may vary with different protocols. Carrier frequencies employed by most protocols lie within the range of 36 kHz to 56 kHz.

When encoding data, some protocols encode one or more bits at a time into a single atomic unit that is transmitted. These units are referred to as symbols. While most protocols encode only one bit per symbol, there are several which encode more, such as those that use four pulse position modulation. In order to transmit a data string, each symbol of the data string must be encoded to form a combination of OFF and ON states in such a way that (a) each symbol can be easily distinguished from any other possible symbols and (b) the boundaries of each symbol are unambiguous

3.0 Reader Infra-Red Data Transmission System

The infrared transmitter1049of the reader300is preferably an infrared light emitting diode (LED). Such a light emitting diode is typical of infrared light emitting diodes used in home/commercial remote control equipment.

The infrared receiver1040of the reader300is preferably an infrared photo detector module which integrates an infrared filter, a PIN diode (as known to those in the relevant art), amplifier circuitry and discriminator circuitry into a single device.

Infrared data transmission from the reader300is preferably implemented using software resident in the memory1046and controlled in its execution by the CPU1045. As described above, such software is generally referred to as ‘firmware’. The firmware of the reader300will be describe in detail in section 7.0 below.

Two distinct infrared transmission architectures are described in the following sections.FIG. 25is a schematic block diagram showing a first firmware architecture2500, which is referred to herein as ‘centrally controlled infra-red transmission’.FIG. 26is a schematic block diagram showing a second firmware architecture2600, which is referred to herein as ‘delegated control infra-red transmission’. The architectures2500and2600both comprise an infra-red transmission software module2501and2601, respectively, which operate in conjunction with one of a set of protocol modules2503and2603, each of which comprise code and data defining a particular protocol. The two architectures2500and2600differ in the distribution of the functionality between the different modules of the architectures. The modules2501,2503,2601and2603are preferably resident in the memory1046and controlled in their execution by the CPU1045of the reader300. As will be explained in more detail below, selection of the appropriate architecture2500or2600to use for a particular application of the reader300is performed on the basis of individual protocols.

The infrared transmission module2501provides two entry points for data transmitted to the reader300by the smart card100, via other processing software modules2517, as follows:

Entry point (1): for receiving a single byte of data from the card100; and

Entry point (2): for completing a packet transmission by flushing an output buffer2505(seen inFIG. 25).

When more than one protocol module2503is present within the system, the transmission module2501interacts with the protocol that is currently active.

Entry point (1) is used whenever any byte is to be transmitted by the reader300, for example, to the set top box601. A buffer handler2507within the infra-red transmission module2501, firstly, processes the byte and adds the byte to the output buffer2505configured within memory1047. The output buffer2505stores all bytes that have been submitted for transmission by the reader300, but have not yet been sent. The buffer2505facilitates the use of infrared protocols that send more than one byte of data at a time. The buffer handler2507looks up the currently active protocol module2505, firstly, to perform keyboard or remote control code remapping (if required), and secondly, to determine the size of the output buffer2505in order to subsequently determine whether the buffer2505is full according to a current protocol as defined by the protocol module2550. If the buffer is found to be full, the CPU1045passes control to the “Buffer Transform” stage2509.

The buffer transform stage2509determines whether a format function is present within a currently active protocol module2503. If so, the format function is invoked by the CPU1045to read the data from the output buffer2505and to combine the data with other information as required by the protocol defined by the module2503, and transforming the data into a stream of symbols which are stored in a symbol buffer2511. A format function2513defined in the protocol module2503returns a value which indicates a number of frames to be transmitted by the reader300in a current packet (e.g. the packet2401). After the format function2513is completed, the CPU1045returns control to the buffer transform stage2509of the infra-red transmission module2501, which then enters an “Infrared Signal Generation” stage2515.

If a format function2513is not present in the current protocol module2503, then the CPU1045preferably performs a default action in order to copy the contents of the output buffer2505directly into the symbol buffer2511. The CPU1045then schedules for transmission of enough frames to include all raw data required to be transmitted by the reader300.

The infrared signal generation stage2515begins by programming the timer interface module1060of the microcontroller1044, as discussed above, to overflow in one period of the carrier signal. The timer interface module1060is preferably also programmed to toggle an infrared output pin of the microcontroller1044when half of the carrier signal period has expired, and again when the full period has expired, which effectively generates a signal with a 50% duty cycle. Using the data provided in the protocol module2503, the positions of start (e.g.2406), stop (e.g.2407) and parity symbols (e.g.2405) are determined for the current packet to be transmitted by the reader300. Data is retrieved from the symbol buffer2511for transmission, one symbol at a time. All symbols are transmitted by the reader300according to associated symbol definitions, which are also read from the protocol module2503, and comprise a data string where a zero bit represents the OFF state, and a one bit represents the ON state.

States are changed by switching control of the infra-red transmitter1049, shown as a light emitting diode inFIG. 25, between the microcontroller1044, which emits a steady voltage to keep the light emitting diode powered off, and the timer interface module1060, which has been configured as described above to emit a wave at the required carrier frequency.

Entry point (2) is generally invoked by the CPU1045after checksum characters have been transmitted by the reader300with a transmitted packet. For entry point (2) of the architecture2500, the buffer handler stage2507is bypassed, since there are no characters provided when entry point (2) is invoked. The purpose of the CPU1045invoking entry point (2) is to ensure that the end of a message is transmitted by the reader300even if the output buffer2505of the reader300is not full. Otherwise, the last few characters of a message packet can end up being transmitted only when a subsequent message is transmitted by the reader300.

In some implementations of the reader300, the output buffer2505can be merged with the symbol buffer2511in order to conserve memory1047.

The other software modules2517as mentioned above, include modules for processing coordinates supplied by the touch panel308, for initializing the card100and for processing commands which do not conform to standard interfaces, but are specific to an application resident on the card100, for example.

The delegated control infrared transmission architecture2600is variation of the centrally controlled infrared transmission architecture2500described above. The architecture2600comprises a buffer handler2607, an output buffer2605, a buffer transform2609and a format function2613, and operates in a similar manner to that described above for the architecture2500. However, the architecture2600can be used to implement different kinds of protocols, which cannot be generated by the infrared signal generation stage2515of the architecture2500. The format function2613controls the infrared transmitter1049, so that the protocol module2603is responsible for all aspects of transmission other than the initial buffering stage. The architecture2600will be further described in the following sections.

4.0 Protocol Modules

As described above, a protocol module (e.g. the module2503) is a set of bytes containing data and a format function, which defines an infrared protocol. A protocol module can be stored in the memory1046of the reader300, or on a portable storage medium, such as the memory chip219or the storage means276of the cards100A and100B, respectively. Alternatively, the protocol module can be transmitted directly by a device, such as the computer700or set top box601, to the reader300using a communications link such as an infrared receiver1040.

FIG. 27shows the structure of a protocol module2700. The protocol module2700comprises a portion2701defining the properties of a protocol, such as a protocol identifier, carrier period and the number of symbols per frame, for example. The protocol module2700also comprises a portion2703defining symbol definitions for each distinct symbol used by a protocol defined by the protocol module2700. A key map table2705can also be included in the protocol module2700for converting a generic key code intended for use with any keyboard or remote control into a key code that complies with the protocol that the transmission is currently using. Finally, the protocol module2700also includes a format functions portion2707defining a format function for converting a bit stream into a suitable format for transmission by the remote reader300according to the protocol identified by the protocol identifier. The protocol properties portion2701, the symbol definitions portion2703, the key map table portion2705and the format functions portion2707, will be described in more detail below.

4.1 Protocol Properties

The protocol properties portion of the protocol module2700is formatted in a structure, which contains the elements shown in Table 18, below.

TABLE 18NameDescriptionLengthModule syntaxA version number which indicates the structure1 byteversionof subsequent data. This specification describesversion 1.ProtocolThe protocol identifier assigned by a central1 byteIdentifierauthority to refer to the current protocol.Values of 0, 0xfe and 0xff are reserved.FlagsA bitfield representing some protocol1 byteproperties.Output bufferThe number of raw data bytes to be transmitted1 bytelengthat a time when using a generic protocol (notkeyboard, Mouse or RC)Carrier periodThe period of a carrier pulse, in microseconds.1 byteChip lengthThe length of a single chip, in microseconds.2 bytesA chip is defined to be an atomic time unit -all timings used in the protocol should bemultiples of this basic chip length.Symbols perThe number of symbols present in a1 byteframesingle frameBits perThe number of data bits represented by each1 bytesymbolsymbol.Gap lengthThe length of the gap (e.g., 2411) between two2 bytessuccessive packets, in millisecondsStandardA pointer to the function called to format1 byteFormatapplication protocol data into the correct bitfunctionstream.RC FormatA pointer to the function called to format1 bytefunctionremote control data into the correct bit stream.KeyboardA pointer to the function called to format1 byteFormatkeyboard data into the correct bit stream.functionMouse FormatA pointer to the function called to format1 bytefunctionmouse data into the correct bit stream.Keymap TableA pointer to an lookup table used by the1 byteprotocol when in keyboard or remote controlmode, to translate standard key codes toprotocol-specific ones. If this value is NULL,codes are transmitted unchanged.Start definitionA pointer to the structure that defines1 bytethe way a start symbol should be transmittedStop definitionA pointer to the structure that defines1 bytethe way a stop symbol should be transmitted‘0’ definitionA pointer to the structure that defines1 bytethe way a ‘0’ symbol should be transmitted‘1’ definitionA pointer to the structure that defines the1 byteway a ‘1’symbol should be transmitted

Additional symbol definition pointers may be present in the protocol properties portion2701, as required. The pointers described in Table 18 are interpreted as offsets from the beginning of the protocol properties portion2701, eliminating any need for absolute addresses and allowing the same structure to be defined outside the firmware of the reader300, as well as conserving space in the memory1047.

The flags shown in Table 19, below, are defined for the “flags” field in the protocol properties portion2701:

TABLE 19NameDescriptionValueBit orderIf bit order bit is set, each frame is transmitted0x80most significant bit first. If not, the leastsignificant bit is transmitted first.Even parityIf the even parity bit is set, an even parity0x40symbol is inserted at the end of each frame.Odd parityIf the odd parity bit is set, an odd parity symbol is0x20inserted at the end of each frame.
4.2 Symbol Definitions

A symbol definition is required for each distinct symbol used by a protocol. The number of value symbols defined in each protocol module2700is equal to two to the power of the number of bits per symbol. In addition, start and stop symbols have associated symbol definitions. If two symbols are identical (e.g. in many protocols, a start symbol is simply a ‘0’ symbol and a stop symbol is a ‘1’ symbol), the pointers associated with each of the two symbols may refer to the same symbol definition structure in order to conserve memory1047.

Symbol definitions have a structure as shown in Table 20.

TABLE 20NameDescriptionLengthNumberThe number of chips of predefined length that make1 byteofup this symbolchipsChipFor each bit, a 0 indicates that the infrared0 or morepatterntransmitter (i.e., the LED) should be in the OFFbytesstate, and a 1 indicates that the LED should be inthe ON state. The first bit to be transmitted is theleast significant bit of the first byte. Subsequent bitsare retrieved by moving left within the byte, andmoving on to the next byte in the sequence after abyte is exhausted. There should be enough bytes inthis sequence to accommodate all the bits requiredby the previous field.
4.3 Format Functions

The number of bits generated by a format function is equal to the frames per packet multiplied by the symbols per frame multiplied by bits per symbol. The latter two values (i.e. symbols per frame and bits per symbol) are defined in the protocol properties portion2701of the protocol module2700. The number of frames in a current packet to be transmitted by the reader300is determined by the format function of the protocol module2700, and returned by the format function portion2707to a caller module (e.g. the module the buffer transform2509) of the format function.

Data to be output by the reader300is positioned so that the first eight bits to be transmitted are stored in the first element of an array configured within the transform buffer2509, the next eight bits in the second element, and so on. The bit ordering within these bytes is controlled by a bit order flag in the protocol properties portion2701of the protocol module2700.

Start, stop and parity bits are not inserted into the symbol buffer2501, as start, stop and parity bits are automatically inserted by the infrared signal generation stage2515at frame boundaries of a message (e.g. the message2410) to be transmitted.

The format function portion2707of the protocol module2700returns a value that indicates the number of frames to be transmitted by the reader300.

Each protocol module2700of the reader300can implement up to four different format functions, with each format function corresponding to one of the four defined device modes (i.e., the remote control, keyboard, mouse and user interface card reader). The same format function can be used for two or more device modes, by ensuring that each of the applicable format function pointers refers to the same address.

The keymap table2705of the protocol module2700is used to convert a generic key code intended for use with any keyboard or remote control into a code that complies with the transmission protocol currently being used by the reader300. A keymap table, associated in the keymap table portion2705, comprises an array of bytes, indexed by a generic key code, and contains protocol-specific codes used by each key.

Values are translated using the keymap table if the reader300is currently transmitting in keyboard or remote control mode.

Some protocols transmit data too quickly to be able to be handled by a common transmission function. Other protocols use techniques such as frequency modulation, which cannot be easily implemented using such a structure. Such protocols typically require specialized software code to handle every aspect of transmission, which can be provided within the format function, as specified in the delegated control transmission architecture2600described above. Further, in the architecture2600the format function portion2707of the protocol module2700indicates that the central infra-red signal generation stage2515of the architecture2500is not to be entered in the architecture2600by setting the number of frames per packet to zero.

4.6 Protocol Module Placement

The firmware maintains, within the memory1046(i.e., Flash Memory1046) of the reader300, a list of protocol modules (e.g. the module2700), which are also stored in memory1046. In some firmware implementations for the reader300, a page size is defined, wherein no two protocol modules2700can share a page. Such a page size is defined since FLASH memory must be typically erased at a minimum of one page at a time. Thus, the length of each protocol module2700must be rounded up to the next multiple of the basic page size, minus one, since one byte is reserved to store the page length itself. For example, the page size of a typical microcontroller is 64 bytes.

An example of a protocol module list2800is shown inFIG. 28. Each protocol module (e.g. the module2801) is introduced by a single byte2805indicating the length of the module2801, followed by the module2801itself. The length of a particular protocol module (e.g. the module2801) is represented by the difference between the length of the particular module2801, and the minimum allowable length of a protocol module as defined by the page size of memory1046. Thus, for example, for the microcontroller1044, if the minimum module length is 63 bytes. A 63 byte module (e.g. the module2801) would thus be represented by the value 0x0, a 127 byte module (e.g. the module2802) by the value 0x40, and so on. Using this structure, a protocol module may exceed 256 bytes in length even though the length field of the protocol module is one byte long

The module list2800is searched by the CPU1045whenever a different protocol is activated by the reader300, or whenever a new module2700is added or an old module2700is removed from the list2800. In order to locate a module2700, the firmware being executed by the CPU1045of the reader300searches the list2800from the beginning, skipping over any non-matching modules. Such a search is terminated by the CPU1045when a length of 0xff is encountered, indicating the lack of a module2700, or when the limits of the area for storing protocol modules in memory1046are exceeded.

When deleting a protocol, any protocols existing beyond the deleted protocol in the list2800stored in memory1046, are relocated to begin in the newly erased area of the list2800.

4.7 Storage and Transfer of Protocol Modules

If a protocol is required that is not supported within the firmware of the reader300, a new protocol module2700can be loaded into the firmware using a card100that contains a download protocol module object. The data on the card100is formatted according to the extended data format, as described above in section 1.6.3.2.1.

An extended data sub-object having a tag of 0x08 contains a custom protocol module definition. When such a sub-object is activated (e.g. either on insert of the card100into the reader300or on press of a user interface element114), the data of the sub-object is loaded into the firmware of the reader300. The data of the sub-object contains a protocol module2700as described above.

Software code for the protocol module2700is checked before being downloaded into the memory1046of the reader300, in order to ensure that the protocol module will not access any data structures or jump to any locations that are deemed to be dangerous or forbidden, as will be described below.

A custom protocol can be given a protocol identifier, which can be used to reference the protocol module directly by any subsequently inserted cards100. Special protocol identifiers of 0xf0 to 0xfe are reserved to denote temporary custom protocols, which are overwritten when a new custom protocol with the same identifier is loaded.

If there is not enough space in the memory1046present to load a given custom protocol, another protocol is automatically selected by the CPU1045for eviction. Protocols currently defined as global protocols, as described in Table 10 above should not be deleted.

5.0 Protocol Selection and Use

The reader300has one or more protocols stored within memory1046as corresponding protocol modules2700. Two factors determine which protocol is to be used for any particular message to be transmitted by the reader300. Firstly, the current state of the reader300and secondly, instructions provided by a currently inserted card100to change protocols.

The protocol module2700currently in use based on these two factors is referred to as the currently active protocol. The process of modifying the currently active protocol will be described in detail below.

5.1 Device Modes

Device modes have been described herein in order to enable the reader300to emulate other devices. These modes are referred to as a user interface card reader mode, remote control mode, keyboard mode and mouse mode, and will be described in detail below. These device modes are defined rather than relying on software installed in the set-top box601, for example, to perform the emulation of the above devices on receiving messages conforming to a particular protocol (e.g. a user interface card application layer), or to allow the reader300to control devices that do not recognise the reader application protocol, such as existing televisions, VCRs etc.

Some specific protocol parameter flags, which will be described in section 5.8 below, indicate to the CPU1045that the reader300is to behave as a different device on certain events. The flags can effect the way that data is encoded before being transmitted by the reader300. Each protocol mode is associated with a particular format function. If the author of a protocol module2700wishes to use the same format function for more than one protocol mode, then all applicable format function pointers in the protocol properties portion2701of the protocol module2700can be configured to reference the same code entry point.

When operating in a device mode other than the user interface card reader device mode, user interface card message headers (e.g. the header1100) and trailers can be omitted. A “send button output data only” flag, as will be described below, can also be used when the user interface reader device modeis selected for a given message type.

5.1.1 Remote Control and Keyboard Modes

The reader300can be configured to be in a remote control mode or a keyboard mode. When in remote control mode or keyboard mode, reader INSERT, PRESS and RELEASE events, as described above, can result in transmissions so as to emulate a wireless remote control or keyboard protocol as known to those in the relevant art.

Many remote control and keyboard protocols use non-standard encodings as key codes. Protocol modules (e.g. the module2700) that handle such keyboards can translate standard key mappings in one of two ways. Firstly, a protocol module2700can use a lookup table stored in memory1046, which is referenced by the protocol properties portion2701of the module2700. Such a lookup table contains mappings for every possible key code for the particular remote control or keyboard. Secondly, the protocol module2700can use a smaller lookup table or another mapping function, handled by custom software code within an associated format function of the module2700. Additionally, modifier flags configured within memory1046can be set independently to affect the properties of any keyboard or remote control transmission from the reader300. Modifier flags generally represent states that instruct the reader300to emulate the condition of keyboard keys such as shift (Shift) or control (Ctrl), or mouse buttons. The format function2700for a particular keyboard or remote control protocol converts these flags which are maintained by the firmware of the reader300into specific codes used by a particular protocol where necessary.

When in remote control or keyboard mode, two raw data bytes are processed per packet to be transmitted by the reader300.

5.1.2 Mouse Mode

When in mouse mode, reader MOVE events result in reader transmissions that emulate mouse movements. In this instance, the format function of a currently active protocol module2700converts absolute co-ordinates typically transmitted using a generic card reader300protocol into relative co-ordinates used by most mouse protocols.

When in mouse mode, two raw data bytes are processed per packet. One of these bytes represent an absolute or relative X co-ordinate, while the other represents an absolute or relative Y co-ordinate.

5.2 Factory Default Protocols

The firmware of the reader300is preferably configured to recognize a factory default protocol for each of the device modes (i.e., card reader, remote control, keyboard, mouse). Besides an assigned protocol identifier, factory default protocols can be referenced by using a special protocol identifier of 0xff, for example.

5.3 Global Protocols

The firmware of the reader300is also configured to recognize several global protocols, which are to be used in the following situations:

When no card100is present in the reader300;

When a bad card is present in the reader300; and

When a valid card100is present, but no alternative non-global protocol is active in the reader300.

A global protocol is implicitly selected by the CPU1045of the reader300with no knowledge of what the details of the global protocol actually are. Separate global protocols can exist, depending on whether the reader300is operating in reader, remote control, keyboard or mouse emulation mode.

The global protocols typically do not change as long as the reader300is being used in a similar set-top box601environment.

The reader300is configured such that the global protocols are the protocols used by a target set-top box (e.g. the set top box601). If the set-top box to be used with a particular reader300is changed, a global protocol for the reader300must be changed by either:Reprogramming the firmware of the reader300;Using a special “protocol selector” card100or user interface element114, which contains a “set global protocol” sub-object.

A global protocol can be referenced by using a special protocol identifier of zero.

5.4 Card Specific Protocols

A card specific protocol is a protocol that is active until the card100that is currently inserted into the reader300is removed. If a different protocol is selected, during a PRESS event, as the card specific protocol, the new protocol may simply completely override the existing card specific protocol. Alternatively, the new protocol may override the card specific protocol until the card specific protocol is selected once again by the processor705, which will cause the reader300to revert to the original card specific protocol.

A temporary protocol is a protocol, which is active for a certain number of PRESS events. Following the RELEASE event corresponding to the last PRESS event, a currently active protocol reverts to a card specific protocol, or, if such is not present, the global protocol for a system600. The period of effectiveness of a temporary protocol can be chosen to be one of the following:

The duration of a current PRESS event and te corresponding RELEASE event; and

The total duration of the current PRESS event, the corresponding RELEASE event, and the following PRESS event and corresponding RELEASE event.

The period of effectiveness of a temporary protocol is specified by the least significant bit2307of the tag of a sub-object used to select the temporary protocol.

5.6 Changing the Protocol

A temporary or global protocol can be changed by configuring an object on the card100to encode information about the protocol. The object data must be formatted according to the extended data format, described above with reference to section 1.6.3.2.1. Suitable objects include user interface element objects, for protocols which are to be activated by pressing a user interface element (e.g. the user interface elements2914), or card data objects, for protocols which are to be activated on insertion of the card100into the reader300.

An extended data sub-object with a sub-object type of 0x01 changes the temporary protocol of a reader300, according to the lower two bits of the tag corresponding to the sub-object, where the tag describes whether the protocol is a card specific or temporary protocol, and the period of effectiveness of the change in the case of the latter. A sub-object with a tag of 0x4, 0x5, 0x6 to 0x7 changes the global protocol associated with standard, remote control, keyboard and mouse modes respectively.

The data stored in the above-described sub-objects includes a protocol identifier, optionally followed by protocol parameter bytes. If not explicitly stated, a protocol parameter byte is taken to equal zero. Each protocol has a protocol identifier preferably assigned to the protocol by a central authority. If the reader300does not recognize a particular protocol because the protocol module associated with the protocol is not present in the memory1046of the reader300, a currently active protocol is not changed and the reader300generates a BOOP to alert a user of the reader300.

When a global protocol is selected using the special protocol identifier of zero, the remote control, keyboard and mouse mode flags configured within memory1047determine which global protocols are to be used during PRESS, RELEASE and MOVE events. Thus, if both keyboard and mouse flags are set, the keyboard protocol is used for PRESS and RELEASE events, and the mouse protocol is used for MOVE events, until the setting expires. If both keyboard and remote control flags are set simultaneously, the processor705of the reader300assumes that the reader300is in keyboard mode and not in remote control mode.

FIG. 30is a state diagram showing the manner in which a currently active protocol of the reader300can change between global, card specific and temporary states. For example, if the reader300is using a temporary protocol, as represented by the state3001, and a currently inserted card100is removed from the reader300, as represented by the arrow3003, then the reader300is reconfigured to use a global transmission protocol as represented by the state3002. As another example, if the reader300is using the global protocol and a user selects a card-specific protocol, as represented by the arrow3005, by using a special “protocol selector” card, as will be described below for example, then the reader300will be reconfigured to use the card specific protocol.

The following Table 21 displays the special protocol identifiers recognized by the user interface card reader with their meanings:

TABLE 21NameDescriptionValueGlobalThis protocol identifier indicates that the0current global protocol shouldbe used.RegisteredThe values of this protocol identifier0x01–0xEFrepresent a single known protocol whichhas been registered with a central protocolregistration authority.CustomProtocols with these identifiers are not0xF0Unregisteredregistered with the central authority and doto 0xFDnot have a unique identifier. Thus, each ofthese values may be shared with othercompletely different protocols.FactoryThis protocol identifier points to the factory0xFEdefaultdefault protocol defined when the firmwarewas loaded. The factory default protocolcannot be changed.No ProtocolThe value of this protocol identifier0xFFrepresents the absence of a protocol and thereader 300 would transmit no signal.

All other values can be assigned by a central protocol registration authority.

5.8 Protocol Parameters

Some aspects of transmission using a currently active protocol rely on additional parameters, which are specified at the time that the protocol is selected. The first parameter byte is always a flag byte, which has the following possible values as shown in Table 22 below:

TABLE 22NameDescriptionValueSend outputThe header, checksum and any other non-object0x80data onlydata such as co-ordinates or lengths are nottransmitted while this protocol is active in userinterface card reader mode - only the messagepayload is sent.RC modeThe reader should behave as a remote control0x40device. Depending on the protocol, insert, press andrelease messages might be handled differently toother messages.KeyboardThe reader should behave as a keyboard device.0x20modeDepending on the protocol, insert, press and releasemessages can be handled differently to othermessages.Mouse modeThe reader should behave as a mouse device.0x10Depending on the protocol, move messages mightbe handled differently to other messages.

Any additional protocol parameter bytes can be used to encode settings specific to the protocol being used, and are handled directly by a protocol format function associated with a protocol module. Typically, the additional protocol parameter bytes encode information such as device identifiers.

The firmware resident on the reader300will now be described in further below in sections 7.1 to 7.23.

7.1 Main Loop

FIG. 31is a flow diagram showing a read process3100performed by the remote reader300. The process3100is preferably implemented as software resident in the memory1046and controlled in its execution by the CPU1045. The process3100begins after a reset of the reader300has been occurred such as after the reader300has been powered down. The process3100ofFIG. 31is configured in a “paced loop” manner. That is, the process3100is paced by a routine, which generates a 10 millisecond delay. This delay gives adequate service to the necessary routines while providing good latency for the handling of interrupts.

At the first step3101, an initialization process is performed by the CPU1045. The initialization process is performed in order to initialize configuration registers and will be explained below with reference toFIG. 32. At the next step3103, a computer operating properly (COP) register configured within memory1046is cleared indicating that the firmware executing on the reader300is not stuck in any recurring loops. The process3100continues at the next step3105, where a check card process is performed, by the CPU1045, to check for any changes in the presence and validity of a particular smart card100. The check card process will be explained in more detail below with reference toFIG. 33. At the next step3107, a scan touch panel process is performed by the CPU1045to check for any touches on the touch panel308by a user. The scan touch panel process will be explained in further detail below with reference toFIG. 36. At the next step3109, a wait 10 millisecond process is performed by the CPU1045, and the process3100then returns to step3103. The wait 10 millisecond process consumes CPU1045cycles and will be described in more detail below with reference toFIG. 51.

7.2 The Initialization Process

After a reset of the reader300, all configuration registers configured within the microcontroller1044require correct initialization. If a low voltage inhibit (LVI) reset was received by the CPU1045then a “possibly depleted battery” flag configured within memory1047is set. A low voltage inhibit reset is initiated when a circuit (not shown) within the microcontroller1044detects that the supply voltage has fallen below 2.4 Volts. When this kind of reset occurs, a flag is set in a Reset Status Register (RSR) and the initialization process of step3101can deduce that the battery1053is becoming depleted. For example, when infrared data is being transmitted, the infrared transmitter1049consumes high current as the transmitter1049is being pulsed. If the battery1053is depleted, the supply voltage can dip under the 2.4 Volt threshold during transmission causing a low voltage inhibit reset. After reset, the battery1053voltage recovers and the low voltage inhibit reset does not occur until the next high current drain. This gives the remote reader300a chance to flag the failing of the battery1053to an associated set-top box (e.g. the set-top box601) or remote equipment (e.g. the computer700) so that the user can be prompted to replace the battery1053.

FIG. 32is a flow diagram showing the initialization process performed at step3101, by the CPU1045, after a reset has been detected by the CPU1045. The process of step3101is preferably implemented as software resident in the memory1046. The process of step3101begins at step3201where all registers configured within memory1046are initialized to a predetermined default state. At the next step3203, a check is performed by the CPU1045to determine if the reset was a low voltage inhibit (LVI) reset. If the reset was not a low voltage inhibit reset at step3203, then the process of step3101concludes. Otherwise the process of step3101proceeds to step3205where the possibly depleted battery flag is set and then the process of step3101concludes.

7.3 Check Card Process

FIG. 33is a flow diagram showing a check card process as performed at step3105. As described above, the process of step3105checks for changes in the presence and validity of a smart card100in the remote reader300and responds accordingly. The process of step3105is preferably implemented as software resident in the memory1046. The process of step3105is performed by the CPU1045and begins at step3301where if a smart card100is inserted in the remote reader300, then the process proceeds to step3302. Otherwise the process proceeds to step3307. At step3302, if the card100is a new card, that is, the previous state of the reader300was such that there was no card100in the reader300, then the process of step3105proceeds to step3311. Otherwise, the process of step3105concludes. At step3311, the CPU1045executes a check card type process to determine the type and validity of a newly inserted smart card100. The check card type process will be described in more detail below with reference toFIG. 34. At the next step3312, the processor705determines whether te previous process3311indicated a valid card. If so, the process of step3105proceeds to step3313. Otherwise, the process of step3105proceeds to step3315where a “BOOP” is sounded and the process of step3105proceeds to step3319. At step3319, a BAD CARD message is transmitted to the set top box601, for example, and the BAD CARD message is processed by the CPU805.

At step3313, a message type variable configured within memory1047is set to “INSERT”. At the next step3314a “BEEP” is sounded by the reader300and the process of step3105proceeds to step3316. If the card100inserted in the reader300has an associated card data object, at step3316, then the process of step3105proceeds to step3317. Otherwise the process proceeds to step3318where the CPU1045transmits a message with no object data and the process concludes. At step3317, a process object data process is performed by the CPU1045using the card data object. The process of step3317will be described below in detail with reference toFIG. 38

If a smart card100is not inserted in the remote reader300at step3301, then the process of step3105proceeds to step3307. At step3307, if this is the first operation of the reader300after the reset, then the process concludes. Otherwise, the process proceeds to step3308where “Background beep”, “Background MOVE” and “No Background Event Co-ordinates” flags configured within memory1046are cleared and the card identifier of the header1100for the card100is set to “NO_CARD”. At the next step3309, a REMOVE message is transmitted to the set top box601, for example, and the REMOVE message is processed by the CPU805. The process of step3305continues at the next step3310, where the active protocol pointer is set to point to the global protocol with user interface card reader device type and the reader300reverts all card specific settings to a default state, before the process of step3305concludes.

7.4 The Check Card Type Process

FIG. 34is a flow diagram showing a check card type process as performed at step3311. The process of step3311is preferably implemented as software resident in the memory1046and controlled in its execution by the CPU1045. The process of step3311begins at step3401, where a check memory card process is performed by the CPU1045in order to determine whether a valid memory card, as described above, is present in the reader300. The check memory card process will be described in detail below with reference toFIG. 35. At the next step3403, if the card100inserted in the reader300is a valid memory card, as described above, then the process of step3311proceeds to step3407. Otherwise, the process proceeds step3413.

At step3407, the card identifier of the card identifier field1110for the inserted card100and flags (see Table 2) are set to represent a valid memory card and the process of step3311concludes.

At step3413, the card identifier of the card identifier field1110and flags are set to represent an invalid card and the process of step3311proceeds to step3417. At step3417, the card100is deactivated by setting the card contacts (e.g. the contacts218,278) and the process concludes.

7.5 Check Memory Card Process

FIG. 35is a flow diagram showing a check memory card process as performed at step3401. The process of step3401is preferably implemented as software resident in the memory1046and being controlled in its execution by the CPU1045. The process of step3401checks whether a valid memory card100is inserted in the reader300. If a card100is present and contains a directory area, as known in the relevant art, configured within memory (e.g. the memory219) of the card100, then the directory area is searched by the CPU1045for an entry containing a value identifying a region of the card100as a user interface card image (i.e., a structure conforming to the user interface card data format). If no directory area is configured within the memory of the card100, then the beginning of the card100is assumed to contain the beginning of the user interface card image. The “magic number” and “checksum” are read from the card header1100stored in the memory of the card100in order to determine the validity of the card100, as described above.

The process of step3401begins at step3501where the CPU1045applies a synchronous reset signal (i.e., as defined in the International Standards Organisation (ISO) Smart Card Standards, “Synchronous Cards, ISO 7816-10 (1999)”),to the card100and receives an Answer to Reset (ATR) (i.e., as defined in the ISO 7816-10 (1999) standards) from the card100. At the next step3503if the card100returns four bytes to the CPU1045then the process of step3401proceeds to step3505. Otherwise, the process proceeds to step3517. At step3505if the four bytes form an ATR then the process of step3401proceeds to step3507. Otherwise, the process proceeds directly to step3515where a ‘Card Data Incorrect error’ is returned to the calling process3311by the CPU1045. At step3507, a protocol for the card is set according to the ATR. The process of step3401continues at the next step3509where the CPU1045searches the directory area configured within the memory of the card100in order to detect an application identifier (i.e., conforming to the standard, “Registration System for Application Identifiers, Amendment 1 (1996): Registration of Identifiers”, ISO 7816-5), identifying data associated with the card100as being user interface card data. At the next3511, if an identifier is found then the process of step3401proceeds to step3513. Otherwise, the process proceeds directly to step3515, as described above. At step3513, the CPU1045locates the card header1100from the directory area and the process proceeds to step3523.

If the card100did not return four bytes to the CPU1045, at step3517, then the process of step3401proceeds to step3517, where the CPU1045attempts to read four bytes from the card100according to the12C protocol for communicating with smart cards. At the next step3519if the card100did not return any data then the process of step3401proceeds directly to step3529where a ‘Card Not Responsive’ error is returned to the calling process3311by the CPU1045. Otherwise, the process proceeds to step3521, where if the first two bytes of the data returned by the card100represent the characters ‘iC’, as described above in Table 1, then the process proceeds to step3523. Otherwise, the process of step3401returns to step3505. At step3523the CPU1045reads the header1100of the card100. At the next step3525, if the header1100is valid then that the process proceeds to step3527where a success return code is generated by the CPU1045. Otherwise, the process of step3401proceeds to step3515, as described above.

7.6 Scan Touch Panel Routine

FIG. 36is a flow diagram showing a process for scanning the touch panel308of the reader300, as performed at step3107. The process of step3107checks for touch panel308touches that equate with user interface element114selections and the CPU1045responds accordingly. The process of step3107is preferably implemented as software resident in memory1046. The process of step3107is executed by the CPU1045and begins at step3601where if the panel308is being touched, then the process proceeds to step3602. Otherwise, the process of step3107proceeds to step3612, where if the panel308has been touched previously then the process proceeds to step3614. Otherwise, the process of step3107concludes.

At step3614, the message type is set to RELEASE and the process of step3107proceeds to step3605. The process continues at the next step3602, where if this is the first time that the touch has been noticed since there was no touch, then the process proceeds to step3603. At the next step3603, the CPU1045determines if an invalid card (i.e., Bad Card) has been inserted into the reader300by checking the result of step3312. In the case that a bad card has been inserted into the reader300, the process of step3107proceeds to step3615. At step3615, a BAD CARD message is transmitted, by the reader300, to the set top box601, for example, and the process concludes. If the CPU1045determines at step3603that the card100was valid, by checking the result of step3312, or that no card was inserted into the reader300, by the checking the result of step3301, then the process of step3107proceeds to step3604. At step3604, the type of message is set to PRESS in the message header1100. At the next step3605, the CPU1045determines the touch coordinates (i.e. X, Y coordinates of user press location) via the touch panel interface1041. Then at the next step3606, the offset and scale functions are applied to the coordinates. The offset and scale functions map the coordinate space of the touch panel308to the coordinate space of the card100. The process of step3107continues at the next step3607, where if the CPU1045determines that the touch detected at step3601was a MOVE and/or no card was inserted into the reader300, by checking the result of step3301, then the process proceeds directly to step3609. Otherwise, the process of step3107proceeds to step3608where the CPU1045executes a process co-ordinates process, which will be explained in further detail below with reference toFIG. 37. At the step3609, a current message is transmitted along with any data, by the reader300, to the set top box601, for example, and the CPU805in the set top box601processes the message. The process of step3107continues at the next step3611, where a BEEP sound is sounded indicating success if a Beep flag (see Table 7) is set either for the currently active user interface element, or for the background (i.e., if no user interface element is active), and the process concludes.

If this is not the first time that a touch has been noticed since there was no touch, at step3602, then the process of step3107proceeds to step3616. At step3616, if a Move flag (see Table 7) associated with the currently active user interface element is set, or if an associated Backgorund Move flag is set, then the process proceeds to step3617. Otherwise the process of step3107concludes. At step3617, the message type is set to MOVE and the process proceeds to step3605. If it was determined at step3607that the message was a MOVE, at step3609, then the CPU1045sends a MOVE message to the set top box601. The CPU805processes X, Y coordinates as cursor information and moves a cursor that is displayed on the television616. In this case, the next RELEASE message can be interpreted as a command to select the displayed object at the cursor position (e.g. to execute a program, select an item or load a URL). Further, if NO Event Coordinates have been set in the card100, then the reader300may send the data associated with a user interface object to the set top box601, for example, without sending the X, Y coordinates of the touch position.

In addition, if the application has a user interface object structure such as that shown in Table 6, and a matching function such as that performed in the process of step3608, then the reader300may send X, Y coordinates of a touch position to the application. As a result, the CPU805executes the same matching function in order to read data associated with the user interface object and provides the card user, a service (e.g. a game) identified by a service identifier1106associated with the read data.

Therefore, if a card user uses the reader300as a mouse (i.e., the reader300is in mouse mode) by moving his or her finger on the touch panel308, then the user can select one of the set top box601services on a set top box menu displayed on the display of the television616. Also, if the card user uses the reader300with an inserted card100and selects some indicia114(i.e., the reader300is in user interface card reader mode), then the user can receive a service (e.g. a game) from the set top box601.

7.7 Process Coordinates Process

FIG. 37is a flow diagram showing a process coordinates process for matching a pair of coordinates with a user interface object stored on the card100, as performed at step3608. The process of step3608is preferably implemented as software resident in memory1046and being executed by the CPU1045. The process begins at step3701, where the memory of the card100is searched by the CPU1045to determine a user interface object, and associated data, matching the coordinates received from the reader300. At the next step3703, if a user interface card object was found in memory1046, by matching the coordinates received from the reader300, then the process of step3608proceeds to step3705. Otherwise, the process proceeds to step3711. At step3705, the CPU1045reads the data associated with the matched user interface object from the memory of the card100. The process of step3608continues at the next step3707where the CPU1045executes a process object data process as performed at step3317. The process object data process will be described in detail below with reference toFIG. 38. At the next step3709, if the CPU1045detects a RELEASE event, then the process proceeds to step3713. Otherwise, the process of step3608concludes. At step3713, temporary settings counters (as described above to control temporary protocols and modifier flags) configured within the memory1047are decremented. Then at the step3715, the CPU1045reverts those settings having expired counters to the values previously stored for these settings and the process of step3608concludes.

At step3711a transmit message header process is executed by the CPU1045. The transmit message header process transmits a reader application message header and any other information that is not read from the card100, for a current message. The transmit message header process will be described below with reference toFIG. 9. The process of step3608concludes after the next step3717where a message checksum is transmitted by the reader300.

7.8 Process Object Data Process

FIG. 38is a flow diagram showing a process object data process for processing data associated with a user interface object stored in the memory of the card100, as performed at steps3317and3707. If the extended data flag (see Table 4) of the object, detected by the CPU1045at step3316or3703(i.e., the matched object) is set then the CPU1045processes the extended data structure of the object at the beginning of the data associated with the object, before the reader300reverts to standard data format mode, by clearing the extended data flag, upon reaching a tag of zero.

The process of step3317is preferably implemented as software resident in memory1046and being executed by the CPU1045. The process begins at step3801, where the CPU1045determines whether there are any more bytes of the user interface object, detected by the CPU1045at step3316, to process. If their are more bytes to process, at step3801, then the process of step3317proceeds to step3803. Otherwise, the process proceeds directly to step3825where a transmit message checksum process is executed by the CPU1045and the process concludes. The transmit message checksum process is executed by the CPU1045in order to transmit the checksum following a message body and will be described in detail below with reference toFIG. 48. At step3803, if the extended data format flag (see Table 4) of the matched object is set, then the process of step3317proceeds to step3805. Otherwise, the process proceeds to step3821. At step3805the CPU1045reads the next data byte as a tag, as described above with reference toFIGS. 23(a) and23(b). If the tag is equal to zero, then the process of step3317proceeds to step3811. Otherwise, the process proceeds to step3809where the next data byte is read by the CPU1045and is interpreted by the processor705as the length of the sub-object data. At the next step3813, if a RELEASE event is detected by the CPU1045then the process of step3317proceeds to step3817where the remaining sub-object data bytes associated with the matched object are skipped and the process returns to step3801. Otherwise, the process proceeds to step3815where a process sub-object data process is executed by the CPU1045. The process sub-object data process will be described in more detail with reference toFIG. 39. After step3815the process of step3317returns to step3801. At step3811, the extended data flag of the matched object is cleared and the process of step3317returns to step3801.

At step3821, the CPU1045reads the next data byte associated with the matched object. At the next step3823, a transmit message character process is executed by the CPU1045and the process of step3317returns to step3801. The transmit message character process is called by the CPU1045to transmit a single character forming part of a current message body and will be described in detail below with reference toFIG. 47.

7.9 Process Sub-Object Data Process

FIG. 39is a flow diagram showing a process sub-object data process for checking the tag associated with a current sub-object of a user interface object, as performed at steps3815. Tag values are represented in hexadecimal format. The process of step3815updates the state of the reader300according to the retrieved sub-object value. The process of step3815is preferably implemented as software resident in memory1046and is executed by the CPU1045. The process begins at step3901, where if the most significant bit of the tag of the next data byte, read by the CPU1045at step3805, is equal to one, indicating that a non-global change is to be effected in the reader300, then the process of step3815proceeds to step3902. Otherwise, the process of step3815proceeds to step3917. At step3902, if the value of the tag of the next data byte, read by the CPU1045at step3805, is equal to one, indicating that the data byte comprises part of an update reader identifier sub-object, then the process of step3815proceeds to step3903. At step3903, an update reader identifier process is executed by the CPU1045and the process then proceeds to step3925. Otherwise, the process proceeds to step3905. As described above, with reference toFIGS. 23(a) and (b), the value of a tag is indicated by the bits labeled X in the tags2301and2302and the value of the tags indicates the type of sub-object associated with the tag. The update reader identifier process processes the data contained in an update reader identifier sub-object and will be described in more detail below with reference toFIG. 41.

At step3905, if the value of the tag is in the range of [4, 8), indicating that the next sub-object is an update global protocol pointer sub-object, then the process of step3815proceeds to step3907where an update global protocol pointer process is executed by the CPU1045. Otherwise, the process proceeds to step3909. The update global protocol pointer process processes the data contained in an update global protocol pointer sub-object and will be described in more detail below with reference toFIG. 40. Separate global protocol pointers are maintained for the user interface card, remote-control, keyboard and mouse modes of the reader300, as described above with reference to Tables 9 and 10. The value of the least significant two bits of the tag determines which mode the reader300is to be set to.

At step3909, if the value of the tag is equal to eight, indicating that the next sub-object is a protocol module sub-object, then the process of step3815proceeds to step3911where a download new protocol module process is executed by the CPU1045. Otherwise, the process proceeds to step3913. The download new protocol module process processes data in a protocol module sub-object and will be described in more detail below with reference toFIG. 42. If a protocol already in memory1046exists with the same identifier as the protocol to be loaded, then the existing protocol is initially removed.

At step3913, if the value of the tag is equal to nine, indicating that the next sub-object is a delete protocol module sub-object, then the process of step3815proceeds to step3915where a delete protocol modules process is executed by the CPU1045. Otherwise, the process proceeds to step3925. The delete protocol modules process processes data contained in a delete protocol module sub-object and will be described in more detail below with reference toFIG. 43. The success of each module deletion requested within the sub-object is indicated by a BEEP sounded by the reader300.

At step3917, if the value of the type field of the tag is equal to one, indicating that the next sub-object is a temporary protocol sub-object, then the process of step3815proceeds to step3919where a set temporary protocol process is executed by the CPU1045. Otherwise, the process proceeds to step3921. The set temporary protocol process will be described in more detail below with reference toFIG. 45.

At step3921, if the value of the type field of the tag is equal to one, indicating that the next sub-object is a set modifier flags sub-object, then the process of step3815proceeds to step3923where a set modifier flags process is executed by the CPU1045. Otherwise, the process proceeds to step3925. The set modifier flags process is configured to process the data contained in a set modifier flags sub-object and will be described in more detail below with reference toFIG. 46.

At step3925, the CPU1045skips the remaining sub-object data bytes of the sub-object detected by the CPU1045at step3316and the process of step3815concludes.

7.10 Update Global Protocol Pointer Process

Separate global protocol pointers, configured within memory1046of the reader300, are maintained for the user interface card, remote-control, keyboard and mouse modes of the reader300. The value of the least significant two bits of the tag for the current sub-object determines which mode the reader300is to be set to.

FIG. 40is a flow diagram showing the update global protocol pointer process, as performed at step3907. The process of step3907is preferably implemented as software resident in memory1046and being executed by the CPU1045. The process begins at step4001, where if a protocol module is found within the protocol module list in memory1046, having a property structure which contains a protocol identifier equal to the data byte, then the process of step3907proceeds to step4003. The value of the first byte of the sub-object identifies the global protocol being used by the system600. At the next step4003, the global protocol pointer configured within memory1047is set according to the desired device mode (i.e., user interface card reader, mouse, keyboard or remote control), to the protocol pointer identified by the first byte. The process of step3907concludes at the next step4005where a BEEP is sounded by the reader300indicating the success of the process.

If a matching property structure was not found at step4001, then the process of step3907proceeds to step4007where a BOOP is sounded by the reader300indicating such.

7.11 Update Reader Identifier Process

FIG. 41is a flow diagram showing an update reader identifier process for processing the data contained in an update reader identifier sub-object, as performed at steps3903. The process is preferably implemented as software resident in memory1047. The process of step3903is executed by the CPU1045and begins at step4101, where the reader identifier configured within memory1046is set to be value of the first and second bytes of the sub-object data field of the object. The process of step3903concludes at step4103where a BEEP is sounded by the reader300.

7.12 Download New Protocol Module Process

FIG. 42is a per flow diagram showing the download new protocol module process, as performed at step3911. As described above, the download new protocol module process processes data in a protocol module sub-object and will be described in more detail below with reference toFIG. 42. If a protocol already exists in memory1046with the same identifier as the protocol to be loaded, then the existing protocol is initially removed from memory1046. The process of step3911is implemented as software resident in memory1046and is executed by the CPU1045. The process begins at step4201, where if the value of the first data byte of the current sub-object is equal to one then the process proceeds to step4203. Otherwise, the process proceeds to step4213where a BOOP is sounded by the reader300and the process concludes. At step4203, if a protocol module already exists in memory1046with the same identifier as the protocol to be loaded into memory1046then the process of step3911proceeds to step4205where the conflicting protocol module is deleted from memory1046. As described above with reference toFIG. 27, the identifier for a protocol is stored in the protocol properties portion2701of the associated protocol module2700. The conflicting protocol is deleted from memory1046using a delete protocol module process, which will be described below with reference toFIG. 44. The delete protocol module process deletes a single protocol module from memory1046. At the next step4207, if there is enough unused space in memory1046at the end of a protocol module chain containing the deleted protocol module stored within the memory1046, then the process of step3911proceeds to step4209. Otherwise, the process proceeds to step4213where a BOOP is sounded by the reader300. At step4209, object data associated with the current sub-object is written to the beginning of the free area of memory1046. The process of step3911concludes at step4211where a BEEP is sounded by the reader300.

7.13 Delete Protocol Modules Process

FIG. 43is a flow diagram showing the delete protocol modules process, as performed at step3915. The process of step3915is preferably implemented as software resident in memory1046and being executed by the CPU1045. The process begins at step4301, where if there are any bytes of the current sub-object remaining to be processed then the process proceeds to step4302. Otherwise, the process of step3915concludes. At step4302, if a protocol module already exists in memory1046with the same identifier as the protocol to be deleted from memory1046then the process of step3915proceeds to step4303. Otherwise, the process proceeds to step4305where a BOOP is sounded by the reader300. As described above with reference toFIG. 27, the identifier for a protocol is stored in the protocol properties portion2701of the associated protocol module2700. At step4303, the protocol module is deleted from memory1046using the delete protocol module process, which will described in detail below with reference toFIG. 44. As described above, the delete protocol module process deletes a single protocol module from memory1046. The process of step3915concludes at the next step4307where a BEEP is sounded by the reader300. If there is no protocol module existing in memory1046with the same identifier as the protocol to be loaded into memory1046, at step4302, then the process proceeds to step4305where a BOOP is sounded by the reader300concludes.

7.14 Delete Protocol Module Process

FIG. 44is a flow diagram showing the delete protocol module process, as performed at steps4205and4303. The delete protocol module process erases the flash memory1046containing a protocol module to be erased and also compacts the associated protocol module list2800, stored in memory1046, each time a protocol module is erased. The process of step4205is executed by the CPU1045and begins at step4401, where all memory1046occupied by the protocol module to be erased is cleared by the CPU1045. At the next step4403, if there are one or more protocol modules after the erased protocol module in the associated protocol module list2800, then the process of step4205and4303proceeds to step4405. Otherwise, the process concludes. At step4405all subsequent protocol modules of the protocol module list2800are moved forward in memory1046to begin at the newly vacated area of the memory1046.

7.15 Set Temporary Protocol Process

FIG. 45is a flow diagram showing the set temporary protocol module process, as performed at step3919. The set temporary protocol module process is executed by the CPU1045and begins at step4501, where if the tag of the current temporary protocol sub-object indicates a card specific change, then the process proceeds to step4501. Otherwise, the process proceeds to step4523, where the state of a current protocol pointer, configured within memory1047, and parameters for the current protocol are saved in memory1047. At the next step4525, a temporary protocol counter is set to the value of the least significant bit of the tag for the temporary protocol sub-object, plus one, and the process proceeds to step4501.

At step4501, if the value of the first data byte of the temporary protocol sub-object is equal to zero, then the process proceeds to step4505. Otherwise, the process proceeds to step4503. At step4505, a temporary protocol pointer configured within memory1047is set to the value of a global protocol pointer according to a specific device mode (i.e., as indicated by the second byte of the temporary protocol sub-object) and the process of step3919proceeds to step4507.

At step4503, if there is a protocol module existing in memory1046having the same identifier as the protocol module for the protocol specified by the temporary protocol sub-object, then the process of step3919proceeds to step4515. Otherwise, the process proceeds to step4517. At step4515, the temporary protocol pointer configured within memory1047is set to the address of the existing protocol module stored in memory1046and the process proceeds to step4507.

At step4507, protocol parameter flags (see Table 19) configured within memory1046are set according to the second data byte of the temporary protocol sub-object and the process proceeds to step4509. At step4509, if the tag of the temporary protocol sub-object indicates that the CPU1045is to execute a toggle between the temporary proctocol and the current protocol, then the process proceeds to step4511. Otherwise, the process proceeds to step4513.

The process of step3919continues at the next step4513, where the current protocol pointer configured in memory1046is set to the point to the protocol module corresponding to the temporary protocol, and the parameter flags are set to the values for the temporary protocol module.

At step4517the current protocol pointer configured within memory1047is set to the global protocol pointer configured within memory1046. The process of step3919concludes at the next step4519where a BOOP is sounded by the reader300.

7.16 Set Modifier Flags Process

FIG. 46is a flow diagram showing the set modifier flags process, as performed at step3923. As described above, the set modifier flags process processes the data contained in a set modifier flags sub-object. See Table 10 above for a description of the set modifier flags sub-object. The set modifier flags process is executed by the CPU1045and begins at step4601, where the CPU1045determines whether the tag of the current sub-object indicates a card specific change. If so, the process of step3923proceeds to step4604. Otherwise, the process proceeds to step4602where the current state of all modifier flags is saved in memory1047. At the next step4603, a modifier flag counter configured within memory1046is set to the value of the lowest significant bit of the tag of the current sub-object, plus one. The process of step3923continues at the next step4604, where the CPU1045executes an exclusive OR operation on the first data byte of the current sub-object and the first modifier flags byte configured within memory1046. At the next step4605, the CPU1045executes an exclusive OR operation on the second data byte of the current sub object and the second modifier flags byte configured within memory1047. The process of step3923then concludes.

7.17 Transmit Message Character Process

FIG. 47is a flow diagram showing the transmit message character process, as performed at step3823. The transmit message character process is preferably implemented as software resident in memory1046and being executed by the CPU1045, in order for the reader300to transmit a single character forming part of a current message body. If the message header1100for a current message has not been transmitted by the reader300then the message header1100is transmitted before the single character. The transmit message character process begins at step4701, where if the CPU1045determines that a message header1100for the current message has not been transmitted then the process of step3823proceeds directly to step4707. Otherwise, the CPU1045clears the message checksum at the next step4703. Then at step4705, the CPU1045executes a transmit message header process. The transmit message header process will described in more detail with reference toFIG. 9. The process of step3823concludes at the next step4707where the CPU1045executes a transmit single character process. The transmit single character process will be described in further detail below with reference toFIG. 49

7.18 Transmit Checksum Routine

FIG. 48is a flow diagram showing the transmit message checksum process, as performed at step3825. The transmit message checksum process is preferably implemented as software resident in memory1046and being executed by the CPU1045, in order for the reader300to transmit the checksum following a message body. If the message header1100for the current message has not been transmitted by the reader300then the message header1100is transmitted before the message checksum. The transmit message checksum process begins at step4801, where if the CPU1045determines that the message header1100of the current message has been transmitted by the reader300then the process of step3825proceeds directly to step4807. Otherwise the process proceeds to step4803where the message checksum is cleared. At the next step4805the transmit message header process ofFIG. 9is executed by the CPU1045. Then, at step4807the CPU1045loads the checksum of the current message into memory1047. The process of step3825continues at the next step4809where the CPU1045executes the transmit single character process, which will be described below with reference toFIG. 49. At the next step4811, the checksum loaded into memory1047at step4807is inverted by the CPU1045. The process of step3825continues at the next step4813, where the transmit single character process is again executed by the CPU1045. The process concludes at step4815where the CPU1045executes a flush transmit buffer process in order to send all of the data present in a transmission buffer configured within memory1046before clearing the buffer. The flush transmission buffer process will be described in detail below with reference toFIG. 50.

7.19 Transmit Single Character Process

FIG. 49is a flow diagram showing the transmit single character process, as performed at steps4707,4809and4813. The transmit single character process is executed by the CPU1045and begins at step4901, where a next character of the current message is appended to the transmission buffer. At the next step4903, the character is added to the message checksum by the CPU1045. Then at step4905, the length of the packet formed by the single character and the message checksum is checked against the output buffer length element of the protocol properties portion2701for the current protocol. The process of step4707continues at the next step4907where if the transmission buffer is full then the process concludes. Otherwise, the process of step4707proceeds to step4909where a flush transmission buffer process is executed by the CPU1045, as at step4815.

7.20 Flush Transmit Buffer Process

FIG. 50is a flow diagram showing the flush transmission buffer process, as performed at steps4815and4909. The flush transmission buffer process is preferably implemented as software being resident in memory1046and being executed by the CPU1045. The process begins at step5001, where the CPU1045waits until a transmission gap timer, configured within the timer interface module1060, has expired. Then at step5003the CPU1045prepares the timer module1060of the microcontroller1044for transmission using the carrier period for the current protocol as defined by the current protocol module. At the next step5005, the CPU1045invokes the format function from the protocol module (e.g. the module2700) for the current protocol from memory1046. If there are any more frames left in the current message at the next step5007then the process of step4815proceeds to step5009. Otherwise, the process proceeds to step5017. At step5009the CPU1045executes a transmit symbol process to transmit a first symbol for a current frame of the current message. The transmit symbol process will be explained in more detail below with reference toFIG. 18.

The process of step4815continues at the next step5011, where the parity symbol for the current frame is cleared. At the next step5011, if there are no more symbols of the current frame left to be transmitted then the process proceeds to step5019. Otherwise the process proceeds to step5015where the CPU1045executes the transmit symbol process to transmit a next symbol for the current frame. Then at step5016, the current symbol is added to the parity symbol for the current frame and the process of step4815returns to step5013.

At step5019, if the CPU1045determines that a parity symbol needs to be transmitted for the current frame then the process proceeds to step5021. Otherwise, the process proceeds directly to step5023. At step5021, the transmit symbol process is executed by the CPU1045to transmit the parity symbol. Then at step5023, the transmit symbol process is executed by the CPU1045to transmit the stop symbol of the current frame and the process of step4815returns to step5007.

At step5017, the CPU1045configures the gap timer to expire after the protocol transmission gap between frames for the current message, and the process of step4815concludes.

FIG. 51is a flow diagram showing the wait 10 ms process, as performed at step3109of the initialization process ofFIG. 31. The wait 10 millisecond process is executed by the CPU1045to loop in order to consume processor cycles until 10 milliseconds has elapsed. The process of step3109begins at step5101where a wait counter configured within memory1047is cleared. At the next step5103if one minute of user inactivity has elapsed then the process proceeds to step5105. Otherwise the process proceeds to step5107where the reader300enters low-power mode in accordance with an enter low-power mode process which will be described below with reference toFIG. 52, and the process of step3109concludes. The enter low power mode process is executed by the CPU1045to prepare the reader300and the card100to enter low power mode. At step5105the wait counter configured within memory1047is incremented. If 10 milliseconds of waiting time has not elapsed at the next step5109then the process returns to step5103. Otherwise, the process of step3109concludes.

7.22 Enter Low Power Mode

As well as preparing the reader300and the card100to enter low power mode process, as described above, this process also controls wait mode timer wake-ups when the card100is inserted into the reader300.FIG. 52is a flow diagram showing the enter low power mode process, as performed at step5107, of the wait 10 millisecond process ofFIG. 51. The process of step5107begins at step5201where the CPU1045sets up the output ports of the microcontroller1044to minimise current consumption during low power mode. The process concludes at the next step where the reader300is suspended to stop mode.

7.23 Timer Overflow Interrupt Service Routine

FIG. 53is a flow diagram showing a timer overflow interrupt service process5300, which is executed by the CPU1045when an overflow of a 16-bit free-running counter configured within the timer interface counter1060, occurs. An initial timer interrupt following any transmission by the reader300indicates the expiry of the transmission gap time set by a currently active protocol module for the reader300. Subsequent interrupts are triggered at the maximum period supported by the timer interface module1060in order to count idle time required before the reader300enters low power mode. The timer interface module1060generates an interrupt, which vectors to the process5300. The timer overflow interrupt service process calculates how long the reader300has been idle (i.e., no user input). The process5300is preferably implemented as software resident in memory1046. The process5300begins at step5301, where the CPU1045increments a counter configured within memory1047. At the next step5303the process5300sets a maximum period for the timer, indicating also that the transmission gap has expired, and the process5300concludes.

7.24 Transmit Message Header Process

FIG. 9is a flow diagram showing the transmit message header process, as performed at steps3711,4705and4805. The transmit message header process is preferably implemented as software resident in memory1046and being executed by the CPU1045. As described above, the transmit message header process transmits a reader application message header and any other information that is not read from the card100, for the current message.

The process of step3711begins at step901, where the CPU1045transmits three constant bytes of the message, which includes a two byte preamble and a one byte protocol version number. At the next903, the CPU1045transmits the next byte of the current message, which specifies the type of message. The process continues to the next step905, where the next two bytes of the current message, representing the identifier for the reader300, are transmitted by the CPU1045. At the next step907, the CPU1045transmits eight bytes representing the service identifier and the service specific identifier for the card100. Then at step909, if the message type is a “MOVE”, “PRESS” or “RELEASE” type message then the process proceeds directly to step911. Otherwise, the process proceeds to step913.

At the next step911, the CPU1045transmits the next two bytes of the current message, representing the coordinates of the move, press or release event. Then at step913, if the message type is an “INSERT”, “PRESS” or “RELEASE” type message then the process proceeds to step915. Otherwise the process of step3711concludes. At step915, the CPU1045transmits the final two bytes of the current message header, indicating the length of data to follow in the variable length part of the message and the process concludes.

7.25 Transmit Symbol Process

FIG. 18is a flow diagram showing the transmit symbol process, as performed at steps5009,5015and5021. The transmit symbol process is preferably implemented as software resident in memory1046and being executed by the CPU1045. As described above, the transmit symbol process transmits a symbol of a current frame for the current message.

The process of step5009begins at step1801, where the CPU1045loads a chip pattern (see Table 19) for a next symbol according to the symbol definition for the next symbol. Then at step1803, if there are no more chips left to be processed for the current symbol, then the process of step5009concludes. Otherwise, the process proceeds to step1805where the CPU1045sets the output pin for the next chip according to the protocol properties for the current protocol. Then at step1807, the CPU1045waits for a period of time corresponding to the chip length (see table 19) according to the protocol properties of the current protocol. After step1807, the process of step5009returns to step1803.

The aforementioned methods comprise a particular control flow. There are many other variants of the preferred methods, which use different control flows without departing the spirit or scope of the invention. Furthermore one or more of the sub-steps of the preferred method(s) may be executed in parallel rather sequential.

8.0 FURTHER EXAMPLES

The arrangements described above will be further described by way of several examples with particular reference to the system600B ofFIG. 6(b).

A typical cable television operator has many subscribers using set-top boxes (e.g. the set top box601). The set top boxes are typically supplied to subscribers from different manufacturers and each set top box typically employs a different set of communication protocols to receive keyboard, mouse and remote control input. In order to deploy readers similar to the reader300, which will work with these varying set top boxes, without conflicting with other devices (e.g., VCRs, remote controlled doors, air conditioners etc), different infrared protocols must be used and installed as part of the firmware on the readers.

Most cable television operators would prefer to have a single model of reader, such as the reader300, with the same firmware stored thereon. Such a reader300can be transported to the subscriber, on subscription to the network, together with a card100F, as shown inFIG. 54. The card100F is configured for selecting a transmission protocol to be used by the reader300for a particular set top box601as owned by the subscriber. For the card100F, user interface elements5414printed on the card100F are in the form of buttons, which are labelled with model numbers of set top boxes (e.g. L-620, U-300, etc).

Each of the user interface elements5414has an associated user interface object, stored in a memory (not shown) of the card100F, containing protocol configuration data. The protocol configuration data specifies which protocols a particular set top box uses for each of the four device modes (i.e., keyboard, mouse, user interface card reader and remote control) of the reader. The memory of the card100F also has a number of protocol modules (e.g. the module2700), defining the specified protocols (i.e., L-620, L-630, U-300etc) stored therein.

The reader300has firmware stored in memory1046such that when the card100F is inserted into the reader300, the user can select one of the user interface elements5414according to which model of set-top box601the user owns. In response to such a selection, the reader300will be automatically configured to operate using the same protocol(s) as the particular set-top box.

FIG. 20is a flow diagram showing a process2000for configuring a reader300to communicate with a set top box601, in one implementation. The process begins at step2001, where the model number of the set top box is determined. The model number can be determined according to an identifier label printed on the back of the set top box601. Instructions on how to determine the, model number can be printed on the card100F, as shown inFIG. 54. At the next step2003, one of the user interface elements5414can be selected depending on which model the set top box601is determined to be. If, for example, the value of the identifier is “Vx-1001”, then card100F can be inserted into the reader300and the user interface element5415labelled Vx-1001 can be selected. Then at step2005, the reader300compares the coordinates of the selected user interface element (i.e., user interface element5415) against data stored in the memory of the card100F, according to the process3608, and determines that the coordinates correspond to a user interface object containing protocol configuration data. In this example, the protocol configuration data specifies that for a Vx-1001 model reader, user interface card messages should be transmitted by the reader300to the set top box601using the RC-MM protocol (as known to those in the relevant art), remote control messages should be transmitted using the RC5 protocol (as known to those in the relevant art), and that keyboard and mouse messages should be transmitted using a proprietary protocol created by the manufacturer of the Vx-1001 model set top box601.

The user interface object stored in a memory of the card100F and being associated with the user interface element5415thus contains the following sub-objects:(i) Download Protocol Module (RC-MM);(ii) Download Protocol Module (RC5);(iii) Download Protocol Module (Vx-1001);(iv) Set Global Reader Application Protocol (RC-MM);(v) Set Global Keyboard Protocol (Vx-1001);(vi) Set Global Mouse Protocol (Vx-1001); and(vii) Set Global Remote Control Protocol (RC5).

The process2000continues at the next step2007, where the reader300down-loads protocol modules (e.g.,2700) defining the specified protocols (i.e., RC-MM, RC5 and the Vx1001 proprietary protocol) from the memory of the card100F and stores the specified protocols in memory1046. The specified protocols are downloaded by the reader300in accordance with the process3911. At the next step2009, the CPU1045of the reader300executes the firmware stored on the reader300such that the reader300is configured to use the specified protocols by default when the reader300is sending messages of the designated types by setting each global protocol pointer to refer to one of the newly downloaded protocols.

FIG. 29shows an example of another card100E, similar to the card100F described above. However, the card100E is configured for selecting a transmission protocol to be used by the reader300in the system600and in particular in the system600B. User interface elements2914of the card100E are in the form of a “SET GLOBAL” button2901, a “LOAD” button2903, a “TEST” button2905and a “DELETE” button2907, printed on a front face2916of the card100E, for each of four particular protocols (i.e., RC5, Control-S, NEC and R-MAP as known to those in the relevant art) of a reader300or system600. The labels on each of the user interface elements suggest the function of each of the elements114and will not be described in detail.

In this example, similar to Example 1 above, a user is provided with the card100E ofFIG. 29. The card100E includes protocol modules for each of a set of protocols (i.e., RC5, Control-S, NEC and R-MAP as known to those in the relevant art) stored in a memory of the card100E. The user is then instructed by the supplier of the card100E and the associated reader300, to load and test each of the protocols listed on the card100E until a positive response is observed on a target set top box.

FIG. 60is a flow diagram showing a process6000for determining a communication protocol for the reader300, in one implementation. The process begins at step2101, where with the card100E inserted in the reader300, a first protocol module corresponding to a first protocol (e.g., ‘RC5’) is down-loaded by the reader300into memory1047(i.e., RAM), upon selection of one of the user interface elements2914(i.e., element2903in the case of protocol RC5). The first protocol is down-loaded by the reader300in accordance with the process3911.

At the next step2103, the CPU1045of the reader300transmits a message to the set top box601upon selection of one of the user interface elements labelled as ‘test’ (i.e. element2905in the case of protocol RC5). Then at step2105, if a positive response is observed in response to the transmission then the process6000proceeds to step2107. Otherwise, the process6000returns to step2101where a next protocol module (e.g. Control-S) is down-loaded by the reader300. The first protocol module (i.e., RC5) can be deleted from the memory1046according to the process4205if there is not enough available space in memory1046to accept the next protocol module. The positive response can take the form, for example, of an indicator LED (not shown) on the set top box flashing or a function being performed by the audio visual output device616such as a menu being displayed.

The process6000concludes at the next step2107, where the reader300is configured to use the protocol producing the positive response (i.e., RC5), by default, as the global protocol for the system600B, upon a user interface element labelled “SETGLOBAL” (i.e., element2901in the case of the protocol RC5) being selected. In this instance, and a global protocol pointer configured within memory1046is set to point to the RC5 protocol module in memory1046.

In another example, an operator wishes to upgrade the set top boxes owned by subscribers, some of whom already own a reader300, to a new type of set-top box (e.g. a new and improved Vx-2000 series set top box). A technician can be assigned to each of the subscriber's homes or offices to install the new set top boxes. Unfortunately, the new type of set top boxes use a different set of infrared communication protocols to the current set top boxes. Preferably, those subscribers who own a reader300would not be required to be issued with a different reader capable of communicating with the new set top box. Therefore, the technician carries a special card100G, as seen inFIG. 55, which is configured to enable reconfiguration of the reader300to use the different set of infrared communications protocols as soon as the card100G is inserted in the reader300.

The card100G is similar to the cards100E and100F, described above, and is configured for selecting the transmission protocol to be used by the reader300. However, in the case of the card100G, only the new set of protocols specified by the operator are stored in a memory of the card100G. The new set of protocols are stored using a card data object, which contains the following sub-objects:(i) Download Protocol Module (Vx-2000);(ii) Set Global Reader Application Protocol (Vx-2000);(iii) Set Global Keyboard Protocol (Vx-2000);(iv) Set Global Mouse Protocol (Vx-2000); and(v) Set Global Remote Control Protocol (Vx-2000).

The card100G also includes user interface elements5514in the form of buttons5501,5503,5505and5507, which are labeled ‘Standard’, Remote Ctrl’, ‘Keyboard’ and ‘Mouse’ according to the device modes of the reader300. Each of the user interface elements5514of the card100G preferably has an associated Change Non-Global Protocol sub-object, as described above, which is effective for only one user interface element5514selection of the associated user interface element. The Change Non-Global Protocol sub-object contains the Vx-2000 protocol identifier followed by flags to indicate the device mode being by the associated user interface element5514. An Output Data sub-object would contain data which will be recognised by the the set-top box601as a particular known command. Additionally, the user interface element5507marked as Mouse requires that a Move flag associated with the element5507is set, in order to allow movement messages to be sent.

Once the reader300has been configured to use the different set of infrared communications protocols, the technician can test the operation of the reader300for each of the supported device modes, by selecting the elements5501to5507. Thus, the card100G allows a technician to ensure that the new protocols have been successfully stored in the firmware of the reader300.

FIG. 22is a flow diagram showing a process2200for reconfiguring the reader300according to a new set of communications protocols. The process begins at step2201, where upon insertion of the card100G into the reader300, protocol modules stored in a memory of the card100G, and corresponding to the protocols for the new set top boxes, are down-loaded by the reader300into memory1047(i.e., RAM). The protocols are down-loaded by the reader300in accordance with the process3911.

The process2200continues at the next step2203, where the CPU1045of the reader300transmits a message to the set top box601upon selection of the user interface element5501labelled as ‘Standard’. The message is transmitted in accordance with a protocol module stored in memory1046, which is specified as the user interface card reader mode protocol by the card100G. Then at step2205, if a positive response is observed in response to the transmission then the process2200proceeds to step2207. Otherwise, the process2200concludes and can be repeated with another card100and/or reader300.

The process2200continues at step2207, where the CPU1045of the reader300transmits a message to the set top box601upon selection of the user interface element5505labelled as ‘Remote Ctrl’. The message is transmitted in accordance with a protocol module stored in memory1046, which is specified as the remote control mode protocol by the card100G. Then at step2209, if a positive response is observed in response to the transmission then the process2200proceeds to step2211. Otherwise, the process2200concludes and can be repeated with another card100and/or reader300.

The process2200continues at step2211, where the CPU1045of the reader300transmits a message to the set top box601upon selection of the user interface element5503labelled as ‘Keyboard’. The message is transmitted in accordance with a protocol module stored in memory1046, which is specified as the keyboard protocol by the card100G. Then at step2213, if a positive response is observed in response to the transmission then the process2200proceeds to step2215. Otherwise, the process2200concludes and can be repeated with another card100and/or reader300.

The process2200continues at step2215, where the CPU1045of the reader300transmits a message to the set top box601upon selection of the user interface element5503labelled as ‘Mouse’. The message is transmitted in accordance with a protocol module stored in memory1046, which is specified as the mouse protocol by the card100G. Then at step2217, if a positive response is observed in response to the transmission then the reader300can be certified as ‘reconfigured OK’ by the technician, at the next step2219, and the process2200concludes. Otherwise, the process2200concludes and can be repeated with another card100and/or reader300.

8.4 Use of Existing Input Methods

In another example, the system600B including the set-top box601may have several possible applications. One of these applications is an e-mail software program, which is designed to accept input from a standard wireless keyboard as known to those in the relevant art. In order to accept user interface card specific input from the reader300, such an e-mail application would need to be modified, which would require the application to go through the normal process of design, implementation and testing. However, the reader300is capable of sending existing keyboard codes already supported by the set top box601, using a card such as the card100H as shown inFIG. 56, and can circumvent such a design, implementation and testing process.

The card100H is configured for sending keyboard codes to the set top box601. A card data object stored in a memory of the card100H contains a card-specific Change Non-Global Protocol sub-object, which indicates that a default protocol is to be used in keyboard mode. The card100H includes user interface elements5614, which are labeled with alphabetic characters, numbers and functions emulating a typical alpha/numeric keyboard. Each of the user interface elements5614of the card100H includes one or more user interface objects stored in a memory of the card100H. Each of the user interface objects stored on the card100H includes data corresponding to an existing keyboard code. For example, the user interface element5601of the card100H has a user interface object stored in the memory of the card100H. The user interface object includes the coordinates of the user interface element5601and a generic code representing the letter ‘a’. A code representing the letter ‘a’ can be transmitted by the reader300to the set top box601if the user interface element5601is selected by a user. As another example, the card100H can include a user interface element5603, labeled as ‘shift’. A code representing a shift function can be transmitted by the reader300to the set top box601, upon the user interface element5603being selected by a user, in order to shift a cursor (not shown) on the screen of the television616, for example. Similarly, the other user interface elements5614have associated user interface element objects, stored in memory of the card100H and can contain a communications code (e.g. ASCII) for the letters or symbols printed on the user interface element.

In this example, if a protocol currently defined as the global keyboard protocol for the system600B, specifies non-generic key codes for one or more user interface elements5614, then a mapping table can be defined within the protocol module for the particular global keyboard protocol. Such a mapping table can be used by the protocol module to map from a generic code to a protocol-specific code corresponding to the global keyboard protocol. For example, upon selection of the user interface element5601, the CPU1045can match the generic code representing the letter ‘a’, using the mapping table, to determine a correct code corresponding to the particular global keyboard protocol. The protocol-specific key code, representing the letter ‘a’ can then be transmitted in place of the generic code.

Using a mapping table described above, a generic keyboard card, such as the card100H, can be used with many different keyboard protocols, even though many of these protocols may use different values to represent the same key (e.g. the letter ‘a’ user interface element5601).

8.5 A Combined Television and Set Top Box/Video Cassette Recorder (VCR) Controller

Set top boxes and VCRs are typically sold independently of an associated television (e.g. the audio visual output device616) that the set top box and VCR are used in conjunction with. As described in the Background section of this specification, set top boxes, VCRs and TVs are typically sold with individual remote control devices. A typical session using a set top box or VCR would require use of each of these remote control devices.

The following sequence shows a typical session for using a TV and VCR:

(vi) TV: Switch to another channel while VCR is recording;

(vii) TV: Switch to VCR mode when show being recorded is finished;

Each of the above functions (i) to (ix) requires a user to make a selection on the remote control device for the TV or the VCR, which may require the user to continually juggle such remote control devices to make the selections.

FIG. 57shows a card1001configured for supporting the most frequently used commands used by both a TV and a VCR. The card1001is similar to the cards described above and includes user interface elements5714, which are labeled with alphabetic characters, numbers and symbols emulating the keys of a typical TV and VCR remote control device. Each of the user interface elements5714of the card100I includes a user interface object stored in a memory of the card1001. Each of the user interface objects stored on the card1001includes data corresponding to an existing code representing the alphabetic characters, numbers and functions of a typical VCR and TV. Once a reader300has been configured to use the protocols of the TV and VCR, for example, using the card100E described above, the card1001can be used with the reader300to prevent the need for switching conventional remote control devices constantly to perform these and similar tasks.

Certain keys, such as the number keys5715, may be recognised in different ways by both a TV and a VCR. In order to enable such keys5715to be used easily for either appliance, a user interface element5716labeled as “TV/VCR” can be configured to toggle the default protocol for the reader300between the protocol used by the particular TV and VCR. Such toggling can be implemented by storing a Change Non-Global Protocol sub-object on the card100H and associating the sub-object with the user interface element5716. The change non-global protocol sub-object can be configured to toggle the card specific protocol of the card100H.

In contrast, the user interface elements of the card100H which are configured as appliance specific keys (e.g. the user interface elements5717configured as volume keys) can be configured to always use the protocol of the television. The elements5717can be associated with a Change Non-Global Protocol sub-object stored on the card100H, where the sub-object is configured with ‘one button only’ effectiveness.

In a multi-player gaming example, two or more card readers (not shown) similar to the reader300can be used simultaneously. Each reader must be able to uniquely identify itself to a computer (e.g., the computer700) of a system such as the system600A so that no transmission interference occurs between the readers whilst playing a game on the computer700. In this example, the user of each reader is able to select their own identifier by choosing a color.

FIG. 19shows a card100J which is configured to play a popular computer/arcade game called ‘Tetris’. The card100J includes user interface elements1914. Five of the user interface elements (e.g. the user interface element1903) are labeled with symbols representing functions performed during the game (e.g. rotating a graphical object clockwise in the case of the element1903). Further, four of the user interface elements (e.g. the element1901) are labeled with colors. Each of the color user interface elements have associated user interface element objects stored on the card100J including data representing one of the colors blue, red, yellow and green. Therefore, a user of the card100J can select one of the colors as identifying the particular user. For example, if a user selects the user interface element1901using the reader300, then the CPU1045of the reader300matches the coordinates of the element1901with a corresponding object stored on the card100J. In this example, the corresponding object includes a Change User Identifier sub-object which contains a value corresponding to the colour blue. The value for the colour blue can be subsequently used as the reader identifier included in the headers (e.g. the header1100) of all outgoing reader application protocol messages. Such an identifer can also be used within designated areas of lower-level packets sent by a protocol module. For each subsequent transmission of a message from the reader300to the computer700, the data corresponding to the matched object and representing the color blue, is included in a sub-object transmitted with the message. The processor705of the computer601reads the transmitted sub-object and recognizes the message as originating from the card100J. Any function data also transmitted with the message is read by the processor1005and a corresponding function can result in the Tetris game application executing on the computer700, performing a function for the particular user.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. For example, the user interface elements114,154can be positioned otherwise than on the smart card100. The user interface elements114,154may, for example, be displayed on a display device (e.g.616). Further, the embodiments described above, and in particular the cards100of the example section, have largely been described with reference to memory cards such as the card100A. However, a person skilled in the relevant art would appreciate that the cards100(including the cards100F,100G,100H,100I and100J) can be implemented using a CPU card similar to the CPU card100B ofFIG. 2(b). User identifiers can represent any features that distinguish one user from another, such as numbers, colours, characters, teams, vechicles etc.

8.7 Set-Top Box Unable to Process Reader Application Protocol Messages

The system600B as described in the example of section 1.7 above, can be modified in order to avoid sending reader application protocol messages (e.g. INSERT, REMOVE, BAD CARD, PRESS, RELEASE, MOVE, LOW BATT) when the set-top box601is not configured to process such messages. In this instance, each of the user interface elements1414of the card100C can be mapped to a single keyboard key-stroke, which the CPU805of the set-top box601can be configured to recognise and interpret as the relevant command corresponding to a particular reader application protocol message. For example, the two-way directional controller user interface elements1413can be mapped to “up” and “down” cursor keys available on a keyboard such as the keyboard704.

Those user interface elements of the card100C that do not have an equivalent keyboard key (and associated code) can be mapped to a key unused in any other context by a particular application, for example, executing on the computer700. As an example of such mapping, the “stop” button1407can be mapped to the “S” key of the keyboard704.

In order to implement the mapping described above, the card100C can contain a card data object stored thereon. In this instance, the card data object includes a Change Non-Global Protocol sub-object instructing the reader300to use the global keyboard protocol, where the user interface elements would contain generic key codes as defined by a provider of the card100C.

The above example shows that, by emulating key codes, the reader300can be used with an unrelated set-top box that is not necessarily configured to recognise the reader300. Further, such a card100C and reader300can also be used to control other software applications that normally rely on keyboard input to scroll through menus and make certain selections.

In the context of this specification, the word “comprising” means “including principally but not necessarily solely” or “having” or “including” and not “consisting only of”. Variations of the word comprising, such as “comprise” and “comprises” have corresponding meanings.