REMOTE TERMINAL UPDATING
Technical Field of the Invention
The present invention relates generally to data transfer with terminals and in particular to the transfer of data between at least one host computer and one or more remote terminals. More particularly the present invention has application to, but is not limited to, communications with remote funds transaction terminals, self- service transaction terminals as well as hardwired and wireless Electronic Funds Transfer Point of Sale (EFTPOS) terminals.
Background Art
Convenient access to various products and/or services at any time of the day is becoming a general consumer requirement. Such access is generally provided by terminals situated in convenient locations and located remote from a host location. For example, EFTPOS terminals and automated bank teller machines are remote terminals now being located in shopping centres and the like to fulfil our out-of-bank banking needs. Similarly, other self-service transaction terminals, such as ticket purchasing machines using smart cards, may be configured as such. Figure 1 is an illustration of a known EFTPOS system, and shows a plurality of terminals 20 connected through a communication channel 30 to a single host computer 10. As indicated above, the terminals 20 are often located in shops and other remote locations, while the host computer 10 is located at a central data collection point, such as at the service provider's main computer facility. The functions of this host computer include management of encryption systems, authorisation of transactions and management of communications with remote terminals 20.
Due to the high cost of dedicated communication channels, the communication channel 30 of choice is typically one where a connection is established on a needs basis. For example, the remote terminal 20 would normally establish a connection with the host computer via a telephone line whenever the remote terminal 20 is required to perform an on-line transaction by a
user. Alternatively, the host computer 10 may establish the connection with one of the remote terminals 20.
In use, a customer's card, such as a bank card or smart card 21 is read by the card reader 203 of the remote terminal 20 to obtain appropriate data, such as the user's bank details. The customer would then be required to enter transaction information, such as account type, transaction amount and/or ticket information in the keypad 202. A personal identification number (PIN) may also be required before the information is sent to the host computer 10 for authorisation. The information may be encrypted for data security. Periodically each of these remote terminals 20 require data to be transferred to them, such as update data. Traditionally this may require a technician to visit each of the remote terminals 20 and by connecting another device (not illustrated) to the remote terminal 20 the required data would be downloaded to the remote terminal 20. Logistically this solution is very undesirable.
Alternatively, the host computer 10 may, in succession, establish a connection with each of the remote terminals 20 in order to download the update data to each of the remote terminals 20. A disadvantage of this method is that the remote terminal 20 is unavailable to users during this download time. A further disadvantage is that additional telecommunication costs may also incurred, both for establishing and maintaining the connection 30.
Disclosure of the Invention
It is an object of the present invention to transfer data, such as update data to remote terminals from a host computer without establishing a connection for this purpose.
According to a first aspect of the invention, there is provided a method of transferring additional data between a remote terminal and a host during an established communication, the additional data being incidental to the communication, including the step of transferring the additional data between the remote terminal and the host terminal during a period of communication inactivity such as "dead time".
According to another aspect of the invention, there is provided a method of operating an electronic funds transfer terminal to receive update data from a host, said method including the sequential steps of: establishing a communication with said host over a communications channel; requesting an authorisation of a transaction by said host over said communications channel; receiving said update data from said host over said communications channel; updating a memory means of said electronic funds transfer terminal with said update data; and transferring funds upon receipt of a positive authorisation from said host.
According to a further aspect of the invention, there is provided apparatus for implementing the aforementioned methods.
Advantageously, the present invention provides a method and system wherein a communications channel between a remote terminal and a host computer is used to transfer additional data during times when the communications channel would otherwise be inactive during a communication session, without establishing a communication session for the purpose of transferring the additional data to the remote terminal.
It is to be appreciated that the "additional data" may take various forms, for example including update data for the remote terminal and/or a data card entered into the terminal and data relating to advertisements to be displayed on the display device of the remote terminal. Where the additional data relates to data required by the remote terminal and /or data card entered into the terminal for their every day operation, this data may relate specifically to the particular terminal or card or may be general data being sent to all or a selected number of, remote terminals and/or all data cards using the terminals.
Brief Description of the Drawings
Fig. 1 shows a schematic block diagram of a prior art Electronic Funds Transfer Point Of Sale (EFTPOS) system.
A number of preferred embodiments of the present invention will now be described with reference to the drawings, in which:
Figs 2A and 2B are more detailed schematic block diagrams of a remote
terminal, such as an electronic funds transfer point of sale (EFTPOS) terminal and host computer of the system illustrated in Fig. 1 upon which the preferred embodiments of the present invention may be practiced; and
Figs 3A to 3C are flow diagrams for communication used in the preferred embodiments of the present invention.
Detailed Description
The preferred embodiments of the invention are preferably practiced using remote terminals 20 and host computer 10, such as that shown in Figs 2A and 2B respectively. In particular, the preferred embodiments are effected by instructions in software that are carried out by the host computer 10 and remote terminals 20.
It is to be appreciated that the remote terminal may take various configurations, including a hard-wired EFTPOS terminal, an automatic teller machine (ATM), a mobile EFTPOS machine, as used by mobile service providers, such as taxi drivers, and mobile telephones and other mobile telecommunications devices, preferably with WAP (Wireless Access Protocol) capabilities.
Referring to Fig. 2A, the remote terminal 20 may include a computer module 201 , input devices such as a keypad 202 and card reader 203, and output devices including a receipt printer 215 and a display device 214. Especially when the remote terminal 20 is a hard-wired terminal, it may share the printer 215 with a cash register (not illustrated) and is used for providing a report 22 on a transaction that has occurred or other information relating to the transaction. The card reader 203 reads a user's card 21 in order to obtain data from the user's card. In Figure 2A, the card information is read via a magnetic strip, but this is not essential to the invention. In this regard it will be appreciated that the present invention may be applied not only to magnetic stripe cards, but also to alternative systems such as smartcard systems, stored value loading arrangements, and the like.
The keypad 202 allows the user to enter transaction particulars while the display device displays messages or instructions to the user. As a further option, the user may also be required to enter a PIN.
A Modulator-Demodulator (Modem) transceiver device 216 is used by the remote terminal for communication to and from the host computer 10 via communication channel 30. This channel is preferably a dedicated communication channel, such as telephone line, although it may be any other communication means, including a radio channel and a permanent web connection.
Each computer module 201 typically includes at least one processor unit 205, a memory unit 206, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (I/O) interfaces including a display interface 207, and an I/O interface 209 for the keypad 202, receipt printer 215 and card reader 203, and an interface 208 for the modem 216. The interface 207 may be any display means including a video interface or a Liquid Crystal Display (LCD). The components 205 to 209 of the computer module 201 , typically communicate via an interconnected bus 204. The components, however, may communicate via any other communication means, including via wireless communications.
The computer module may further include an on-line printer and storage device such as a hard disk drive and/or magnetic tape drives.
The host computer may take a variety of configurations, with the main requirements being the ability to communicate with remote terminals. An example host computer 10 is shown in Fig. 2B, which includes a Modulator-Demodulator
(Modem) transceiver device 116 for communication to and from the remote terminals 20 via dedicated communication channel 30.
Typically, the application program of the preferred embodiment is resident on the memory units 106, 206 of the host computer and remote terminals, and controlled in its execution by the processors 105 and 205 respectively.
In Fig. 3A a flow diagram is shown of a first embodiment of the present invention. In use, the remote terminal's computer module 201 , and in particular the processor 205, is activated by a customer's card 21 , in this embodiment, a smart card, which is read by the card reader 103 to obtain the customer's details. After this initial reading by the card reader, the customer may also be required to enter a personal identification number (PIN), as well as select an account type
and/or specify a transaction. The remote terminal 20 establishes communication with the host computer 10, such as by dialing a predetermined telephone number, which may be pre-programmed in memory 106. However, communication may be established via any means. Any or all communication to and from the host computer 10 may also be encrypted. For example, if the customer is required to enter a PIN, it is possible to only encrypt the PIN.
The remote terminal 20 sends the necessary information to the host computer 10, such as card details and possibly any information entered by the customer, in an Authorisation Request message 301 for authorisation of the transaction by the host computer 10.
In this embodiment, a report printer is also incorporated into the configuration, although this is not an essential element. When the printer is incorporated, the printer 215 is preferably controlled by the computer module 201 of the remote terminal, which sends a print message 302 from the remote terminal to the printer 215 to start printing the transaction report 22.
On receipt of the Authorisation request 301 from the remote terminal 20, the host computer 10 performs a review of the customer's account status, either within its own network, or commonly by communicating with the card issuer's system. Appropriate accounting entries are made in the card issuer's system, and an Authorisation Response message 303 (which may be positive or negative) is transmitted via host computer 10 to the remote terminal. This aspect operates in a manner conventional for Point of Sale systems.
In prior art arrangements, the remote terminal pauses while waiting for an Authorisation Response message 303 from the host computer 10. This period, herein called "dead time", is variable, and may be several seconds in duration. However, in accordance with the present invention, additional data, such as in the form of loyalty information, is transferred 304 from the host computer 10 to the remote terminal 20 after the Authorisation request 301 is received by the host computer 10. On successful receipt of the loyalty information 304, the remote terminal
20 transfers the received loyalty information 304 to the smart card 21 in a loyalty
information transfer 305. The smart card 21 responds with a response message 306, which the remote terminal forwards to the host computer 10 as response message 307.
It is also to be appreciated that the messages passed between the host computer/remote terminal and the remote terminal/smart-card (for example at steps 304, 305 respectively), need not be the same. For instance, the information sent at step 304 might include message display information as well as data for the smart-card, but step 305 only includes the smart-card data.
Once the remote terminal 20 receives the Authorisation response message 303, the remote terminal 20 may complete the transaction by forwarding the authorisation response to the smart-card.
Further, in the embodiment with the report printer, the remote terminal would complete the printing of the receipt 22 by also sending a print message 308 to the printer 115 and then perhaps by sending yet another print message 309 to the printer, this time regarding the loyalty information.
In addition, there are various possible approaches to coordinating the additional information sent to the remote terminal with the authorisation response. For example, referring to Figure 3A, it would appear that the host computer does not forward the authorisation response 303 until the smart-card/remote terminal combination have sent a response (306/307) regarding the loyalty information, being the additional information sent during the usual "down time". However, this need not always be the case, as various other configurations are possible. For example, the host computer could send the authorisation response independently of the reply from the smart card/remote terminal about the additional loyalty information. With this configuration, should the remote terminal/smart-card not have finalised the loyalty information update, by the time the authorisation response is received, the update could be aborted and continued on the next transaction.
Fig. 3B shows a timing diagram of a further embodiment of the invention. Once again, the card reader 103 to obtain the customer's details reads a customer's card 21. The remote terminal 20 establishes communication with the
host computer 10 and sends the customer's details etc to the host computer 10 in the Authorisation Request message 301 for authorisation of the transaction by the host computer 10.
In this embodiment of the invention, the update data, which is transferred from the host computer 10 to the remote terminal 20 after the Authorisation request 301 is received by the host computer 10, is an advertisement message 310.
The actual form of transmission of this advertisement may take various forms. For example, the whole advertisement(s) may be downloaded from the host computer or the advertisements may have been previously loaded into the remote terminal, so that the data downloaded to the remote terminal via 310 simply specifies which advertisement(s) to display. As a further alternative, where the transaction is a wireless transaction, such as an EFTPOS transaction on a mobile EFTPOS unit, or even a mobile phone, the information displayed on the mobile unit could be from a particular web site accessed via WAP (Wireless Application Protocol).
On successful receipt by the remote terminal 20 of the advertisement data 310, the advertisement is displayed in step 311 on display 214 of the remote terminal 20. If the advertisement has been newly downloaded from the host computer, it may also be stored 312 in the memory 206 for later retrieval.
Once the host computer 10 has processed the authorisation request 301 , it sends an Authorisation response message 303 to the remote terminal 20 to complete the transaction.
As a further alternative in this embodiment of the invention, the remote terminal 20 may also continue to display 311 the advertisement on display 214 until the next customer card 21 is entered to start a new transaction.
A timing diagram of yet a further embodiment of the invention is shown in
Fig. 3C. The remote terminal 20 in this embodiment stores a "blacklist". A blacklist, for example may be a list of existing customers to whom service has been disallowed or at least minimised. The remote terminal may display the blacklist stored in its memory on display 214, while it is not visible to the public.
In order to start a new transaction, the customer's card 21 is read 313 by the card reader 103 to obtain the customer's details. Only after the remote terminal 20, and in particular the processor 205 has verified that the entered card is not listed on the current blacklist 314, is communication established with the host computer 10 in the form of an authorisation request 301.
A blacklist data message 315 is transferred from the host computer 10 to the remote terminal 20 after the Authorisation request 301 is received by the host computer 10. The blacklist data message 315 may download a new blacklist or alternatively only send an update of the current blacklist to the remote terminal 20. On successful receipt of the blacklist data message 315 by the remote terminal 20, the current blacklist is updated or replaced with the downloaded data and stored in the memory 206 in step 316 for later retrieval.
Once the host computer has processed the authorisation request, it sends an Authorisation response message 303 to the remote terminal 20 to complete the transaction.
As an alternative to this embodiment, the remote terminal need not automatically check the details of the customer's card against the blacklist before seeking an authorisation request. This validation of the customer may instead be undertaken by the host, with the copy of the blacklist on the remote terminal simply for reference by the operator of the remote terminal, such as the merchant.
In a further embodiment of the present invention, instead of additional data being sent to the remote terminal/data card by the host computer during the
"dead time", additional data may instead be sent to the host from the smart card and/or the remote terminal. For example, the smart card/remote terminal could send the host computer statistics or data history during the "dead time".
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, in the embodiments of Figure 3B and 3C the remote terminal may have printing capabilities.
In addition, it is not necessary that there be only one host computer. In this regard, it is still within the inventive concept for more than one host to provide instructions to the remote terminals. For example, two host terminals may communicate with each remote terminal, such that a first host performs the required authorisation steps, while another host performs data updating tasks.
It will be appreciated that variations and additions are possible within the general inventive concept disclosed.