SELF-SERVICE TERMINAL

Abstract: A self-service terminal (10) that includes a graphical user interface is described. The terminal (10) has a link to a remote server (12) that stores user data for a plurality of authorised users. For each user, the server also stores associated screen configuration data. The terminal (10) is operable to identify a user, to receive from the server the screen configuration data associated with the identified user, and to operate on the screen configuration data to generate one or more screens for displaying to the user. This enables the terminal (10) to display a user-specific screen to each authorised user. A self-service terminal system, and a method of providing a self-service terminal with a user-defined screen or screens, are also described.

Description: SELF-SERVICE TERMINAL The present invention relates to a self-service terminal- (SST) . In particular, the invention relates to an SST, such as an automated teller machine (ATM) , It is becoming increasingly common for ATMs to provide a variety of different services to users. These services include conventional transactions such as withdrawal of cash and printing a statement, but they also include paying utility bills, cashing cheques, buying money orders, transferring funds between accounts, and such like. As the number of services offered by an ATM increases, the number of screens through which a user must navigate to obtain the desired service also increases. Increasing the number of screens used increases the possibility of the user becoming confused or making an incorrect entry during a transaction. The term "screen" is used herein to denote the graphics, text, controls (such as menu options) , and such like, that are displayed on an SST monitor; the term "screen" as used herein does not refer to the hardware (that is, the monitor) that displays the graphics, text, controls, and such like. It is an object of an embodiment of the present invention to obviate or mitigate one or more of the above disadvantages or other disadvantages associated with conventional SSTs. According to a first aspect of the invention there is provided a self-service terminal including a graphical user interface, characterised in that the terminal has a link to a remote server storing user data and associated screen configuration data for each of a plurality of authorised users; whereby, the terminal is operable to identify a user, to receive from the server the screen configuration data associated with the identified user, and to operate on the screen configuration data to generate one or more screens for displaying to the user. By virtue of this aspect of the invention, a user is able to customise the appearance of the screens that are presented to him/her when using a terminal. Thus, each user of an SST may have their own personal user-defined screens that present the user's most commonly used transactions in a format pleasing to the user. Preferably, the link to a remote server is also adapted for connecting to a public access network such as the Internet . The screen configuration data may include details of additional services that may be displayed on the screen. For example, the screen may include an area for displaying the exchange rate from pound sterling to US dollar, the weather forecast in Edinburgh, or such like. The additional services may be provided by one or more third parties, and may be retrieved from a Web page. Preferably, the terminal is adapted to receive at least some of the user data and the screen configuration data. This has the advantage that the terminal can display account information for the user. Preferably, the terminal is also adapted to receive formatting data, so that the terminal is able to use the formatting data to extract information from the user data and the screen configuration data, and to present the extracted data in a consistent format. Where the SST is an ATM, the user data may include financial details, such as account information and transaction history. The server may include PIN information for authorising a transaction. The screen configuration data may include pre-defined transactions, such as withdraw ten pounds, pay a utility bill, print a statement or such like. The screen configuration data may include details of the user's name and how the user is to be addressed (for example, "Mr Smith", "John", or such like) by the terminal, so that the SST can display the user's name on the first screen seen by the user, and/or on any subsequent screen. The screen configuration data may also include information relating to financial details, such as a user- defined name for each of the different bank accounts held by the user, so that an account may be displayed as, for example, "John's Savings account", or "Mary's Current account", and the balance of the account (retrieved from the user data) displayed next to the user-defined name. The screen configuration data may include details of the screen appearance, for example, the background colour, the shape of any buttons used on the screen, whether the screen is to be accessed by a right-handed or left-handed user, the number and type of services to be displayed on the first screen, and such like. The screen configuration data can be updated by the user as frequently as desired. According to a second aspect of the invention there is provided a method of providing a self-service terminal with a user-defined screen or screens, the method being characterised by the steps of: accessing an enrolment process providing a plurality of user configurable options for selection by a user, storing options selected by the user in a computer database, storing formatting information, and, in response to the terminal identifying the user, providing a terminal with the options selected by the user and the formatting information for use by the terminal in generating a user-defined screen. The step of accessing an enrolment process may be performed at a self-service terminal or remote from a self- service terminal, for example, at a home PC, via a cellular radiotelephone, or such like. According to a third aspect of the invention there is provided a self-service terminal having a graphical interface, characterised in that the terminal is adapted to retrieve user-specific screen configuration data from a remote server, to operate on the configuration data to generate a user-specific screen, and to display the user- specific screen to a user. According to a fourth aspect of the invention there is provided a server for supplying a self-service terminal with screen configuration data specific to a user, where the server comprises a database for storing user data and associated screen configuration data for each of a plurality of authorised users, a network connection for receiving user details from a remote terminal, and a controller; where, in use, the controller is operable to access the database to retrieve user data and screen configuration data corresponding to the user details, and to transmit the retrieved data to the remote terminal . By virtue of this aspect of the invention, a server is provided that stores customised screen information relating to each user, and transmits this information to a SST on receipt of a request from the SST. Preferably, the controller is also operable to access a network, such as the Internet, an Extranet, or an Intranet, for retrieving publicly available information and/or information from a third party, for incorporating into a user's screen. In a preferred embodiment , the server includes an XML converter for receiving data from the database and converting the data into one or more XML (extensible Markup Language) files; and for receiving Web pages (which may be in HTML format) and converting them into XML files. Preferably, the server includes one or more XSL (extensible Stylesheet Language) files for extracting and formatting data from the XML files. Preferably, the server conveys the XML files and the XSL files to the terminal, where the terminal includes an XSL processor for using the XSL files to operate on the XML files to generate HTML for displaying as a screen. Preferably, the terminal includes a Web browser or a browser component, for receiving XSL files and XML files and generating HTML files therefrom. According to a fifth aspect of the invention there is provided a self-service terminal system, characterised in that the system comprises a server interconnected to a plurality of self-service terminals, where the server is operable to receive enrolment data from a user relating to a customised screen, to associate the enrolment data with user data, and to store the enrolment data and associated data in a database; whereby, when the user uses one of the terminals, the terminal transmits user details to the server; the server accesses the stored data corresponding to the user details, and transmits the accessed data to the terminal; and the terminal operates on the transmitted data to generate and display a customised screen. These and other aspects of the invention will be apparent from the following specific description, given by way of example, with reference to the accompanying drawings, in which: Fig 1 is a block diagram of a server system according to one embodiment of the present invention; Fig 2 is a block diagram of the server of Fig 1 ; Fig 3 is a block diagram of one of the terminals of Fig 1; Fig 4 is a pictorial view of an enrolment screen showing one interface style; Fig 5 is a pictorial view of an enrolment screen showing a second interface style; Fig 6 is a pictorial view of one customised screen as seen by a user operating the terminal of Fig 1; Fig 7 is a pictorial view of another customised screen as seen by a user operating the terminal of Fig 1; Fig 8 is a pictorial view of yet another customised screen as seen by a user operating the terminal of Fig 1; Fig 9 illustrates XML code relating to three previous transactions by a user; and Fig 10 illustrates XSL code relating to formatting data for the code of Fig 9. Referring to Fig 1, there is shown a self-service terminal system 10 according to one embodiment of the present invention. The system 10 is owned and operated by a financial institution, and comprises a server 12 interconnected to a plurality of terminals 14 by a network 16. The terminals 14 are in the form of ATMs (only two of which are shown) and the network 16 is in the form of a private Intranet . The Intranet 16 is connected to a public access network 18 in the form of the Internet by a gateway 20. As is known to those of skill in the art, the gateway 20 includes various security features, such as firewalls, to restrict access to the Intranet 16. Both the Intranet 16 and the Internet 20 are TCP/IP-based networks. As is well known in the art, numerous electronic devices, such as personal computers (PCs) , cellular telephones, personal digital assistants (PDAs) , and such like, may connect to the Internet 18; one such device, PC 22, is shown in Fig 1. Referring to Figs 1 and 2, the server 12 comprises a controller 30, a datastore 32, and a network connection 34. A system bus (or buses) 40 connects the network connection 34 to the controller 30 and datastore 32. The controller 30 further comprises a BIOS 42 stored in non-volatile memory, a microprocessor 44, associated main memory 46, and storage space 48 in the form of a magnetic disk drive. For, clarity, the datastore 32 is shown including five databases (32a to 32e) , but the actual arrangement of data and the number of databases used is not critical. Database 32a is used for storing user information for each authorised user. The user information includes an interface style reference for referencing database 32b; in this embodiment three different interface styles are available (as illustrated in Figs 6, 7, and 8) , so that a user can select one of these three styles. Database 32a also includes user preferences for buttons to be displayed on a screen, as will be described in more detail below. Database 32b is used for storing the fonts, colours, text, button shapes, and such like, for each possible user interface style. Database 32c is used for storing account details for each user, such as PIN, balance in each account, recent transaction history, and such like information. Database 32d is used for storing formatting data; in this embodiment, XSL files. The XSL files are independent of any user selections, and contain processing instructions for extracting and formatting user information, interface style data, account data, and third party service data from XML files; and to generate HTML using the extracted data. The XSL files are controlled by the financial institution, and the same XSL files are used for every user. Database 32e is used for storing an enrolment application program. The enrolment program assists users in customising their ATM screens . The magnetic drive 48 stores a server operating system, an XML conversion application, and a Web server application. In use, the main memory 46 is loaded with the server operating system kernel 50, the XML converter 52, and the Web server application 54. In this embodiment the Web server 54 includes a database application programming interface (API) 56 for providing SQL access to the datastore 32. Referring to Fig 3 , which shows one of the ATMs 14a in more detail, a system bus (or a plurality of system buses) 60 interconnects a user interface 62, a network connection 64, and an ATM controller 66, to facilitate mutual intercommunication. The user interface 62 comprises the following user interface elements (peripheral devices) : a card reader 70, a monitor 72 , a touchscreen module 74 mounted onto the monitor 72, a printer 76, and a cash dispenser 78. The controller 66 comprises modules for driving the user interface elements 70 to 78, namely: card reader controller 80, monitor controller 82, touchscreen controller 84, printer controller 86, and dispenser controller 88. These user interface elements (70 to 78) and associated controllers (80 to 88) are standard modules that are used on conventional ATMs and will not be described in detail herein. The controller 66 also comprises a BIOS 90 stored in non-volatile memory, a microprocessor 92, associated main memory 94, and storage space 96 in the form of a magnetic disk drive. When the ATM is booted up, the controller 66 loads an operating system kernel 100 and an ATM application 102 into memory 94. The ATM application 102 is used to operate the ATM and includes a browser 104 for displaying Web pages on monitor 72. The browser 104 is an Internet Explorer 5 (trade mark) browser from Microsoft Corporation (trade mark) . The IE5 browser 104 includes an XSL processor for receiving XSL and XML files and processing the XML files using the instructions contained in the XSL files to generate HTML. Referring to Figs 1 to 3 , if a user wishes to customise the screen displayed during an ATM transaction, then the user accesses the enrolment application program stored in database 32e using PC 22. The enrolment application program is provided on a Web page operated by the Web server 12 , so the user enters the appropriate URL on a Web browser executing on PC 22 to access the enrolment application. As illustrated in Figs 4 and 5 , the enrolment application allows a user to configure the screen layout he will be presented with when using any ATM 14 in system 10. The user can choose a particular pre-defined interface style for his customised screen by selecting an option from interface selection area 110 (shown as a dotted line) . Three interface style options are shown in Figs 4 and 5. The selected style is shown in preview area 112. In Fig 4 the interface style selected is the "Trekie" style; whereas, in Fig 5, the interface style selected is the "Jade" style. The interface styles are chosen by the financial institution to provide a template for use by each user. The financial institution stores full details of each interface style (for example, background colour, button size, button shape, font size, and such like) in database 32b. The user can indicate whether he is left or right- handed by selecting one of two buttons from area 114. If the user is left-handed then, on the customised screen, any selection buttons are located to the left side; whereas, any selection buttons are located to the right side if the user is right-handed. Button programming area 116 enables the user to select how many buttons will be presented on the customised screen, what function each button will perform, and what label is applied to each button. Programming area 116 presents the different transaction options available on the ATMs 14 in the system 10. The user selects a transaction option, for example withdraw cash; the user is then shown another enrolment screen (not shown) for specifying the amount to be withdrawn, for example ten pounds; the user is then shown another enrolment screen (not shown) for specifying a label to be attached to the button, for example, "usual". The effect of this selection is that in the customised screen a button is presented that is labelled "usual"; when the button is selected the transaction is authorised and ten pounds are dispensed. In the enrolment process, the user selects all the transactions that he wishes to be presented on his customised screen. These transactions may include transferring funds, printing a statement, paying a bill, or such like. When the user has finished entering interface details, the user can select another tab from tab area 118. If the user selects the personal details tab 120, he can enter the name (if any) to be displayed on the customised screen, for example, John Smith, Mr Smith, Dr Smith, or such like. The user can also select the language to be used on the screen, for example, English, French, German, or such like. When the user has finished entering personal details, he can select a financial details tab 122 to enter details relating to the accounts the user has, such as labels to be applied to the accounts, for example, "Spending Money", "Savings Account", or such like. When the user has finished entering financial details, the user can select a services tab 124 for selecting additional services provided by third parties and available via the Internet, such as the exchange rate between one pound sterling and the US dollar. Typically, the user enters the URL for the Web page to be accessed, and any identifier required to indicate the data that is to be extracted from that Web page. When the user has finished setting up the customised screen, the user selects a finish tab 130 from navigation tab area 132. The enrolment data is then transmitted to the server 12 via the Internet 18, gateway 20 and Intranet 16. The server 12 stores the enrolment data in the user information database 32a in a record indexed by identification data stored on the user's magnetic stripe card, in this embodiment the card number. The next time the user uses an ATM 14, the ATM requests the user to insert his card using a generic (non-customised) screen. The ATM then sends the identification data stored on the user's card to the server 12. The server 12 accesses the databases 32a to 32d to retrieve user data (such as account information stored in database 32c) , screen configuration data (such as the user information stored in database 32a and the interface styles information stored in database 32b) , and formatting data (the XSL files stored in database 32d) . The data retrieved from databases 32a, 32b, and 32c is converted into XML files by XML converter 52 (Fig 2) ; the data retrieved from database 32d is transmitted as an XSL file. The server 12 also accesses the Internet 18 to retrieve any data required from a third party (for example, the pound to dollar exchange rate) . The server 12 receives this in HTML format and converts it into an XML file using XML converter 52. The server 12 then transmits the XML and XSL files to the ATM 14 via Intranet 16. The ATM 14 operates on the files by using the XSL files to extract information from the XML files and to generate HTML files for displaying on the monitor 72 (Fig 3) . The user is then presented with a customised display that reflects the options selected during the enrolment process. Figs 6, 7, and 8 show three different customised screens as displayed on an ATM 14. For comparison, the screens each have the same transaction options and the same account details, but the interface style chosen for each is different. Each screen has a service area 140 for displaying third party services. However, as the third party service is obtained from the Internet 18 rather than the Intranet 16, if the service data is not obtained within a predefined time, the service is not displayed (as in Figs 6, 7, and 8) . This ensures that the user does not have to wait too long before he can execute a transaction. The server 12 may send the available data first, to allow the user to initiate a transaction, and then send the third party service data at some later time (when it arrives from the Internet 18) , so that the ATM 14 may display the third party service data during the transaction. Fig 9 illustrates XML code relating to three previous transactions by a user. This code is generated by the XML converter 52 (Fig 2) from data stored in database 32c. Fig 10 illustrates XSL code relating to formatting information for the data contained in the XML file of Fig 9. The XSL code creates HTML in the style of the user ' s interface (e.g. the "Trekie" style) , extracts the data from the XML code of Fig 9, inserts the extracted code into the newly created HTML, and displays the HTML. It will be appreciated that this embodiment has the advantage that each user can personalise an ATM screen, so that the screen displays the services and information that the user wishes to see on each visit to an ATM. Various modifications may be made to the above described embodiment within the scope of the invention, for example, in other embodiments, the SST may be an information kiosk. In other embodiments more or fewer than three interface styles may be used. In other embodiments, the server 12 may receive information in a format other than HTML format and convert it into an XML file using an XML converter; the server 12 may receive information in XML format from an external source. In other embodiments, the enrolment process may be performed using a cellular radiotelephone, a personal digital assistance (PDA) , a dedicated Internet access device, an interactive television, or such like.

Claims: Claims 1. A self-service terminal including a graphical user interface, characterised in that the terminal has a link to a remote server storing user data and associated screen configuration data for each of a plurality of authorised users,- whereby, the terminal is operable to identify a user, to receive from the server the screen configuration data associated with the identified user, and to operate on the screen configuration data to generate one or more screens for displaying to the user. 2. A terminal according to claim 1 , wherein the screen configuration data may include details of data that is to be retrieved from a Web page. This feature enables users to include information provided by third parties (for example, weather forecasts, stock prices, or such like) on their screens . 3. A terminal according to claim 1, wherein the terminal is adapted to receive the user data, the screen configuration data, and formatting data, so that the terminal is able to use the formatting data to extract information from the user data and the screen configuration data. 4. A terminal according to any preceding claim, wherein the terminal is an ATM and the user data includes account information. 5. A terminal according to any preceding claim, wherein the screen configuration data includes details of additional services that may be displayed on the screen. 6. A method of providing a self-service terminal with a user-defined screen or screens, the method being characterised by the steps of: accessing an enrolment process providing a plurality of user configurable options for selection by a user, storing options selected by the user in a computer database, storing formatting information, and, in response to the terminal identifying the user, providing a terminal with the options selected by the user and the formatting information for use by the terminal in generating a user-defined screen. 7. A self-service terminal having a graphical interface, characterised in that the terminal is adapted to retrieve user-specific screen configuration data from a remote server, to operate on the configuration data to generate a user-specific screen, and to display the user- specific screen to a user. 8. A server for supplying a self-service terminal with screen configuration data specific to a user, where the server comprises a database for storing user data and associated screen configuration data for each of a plurality of authorised users, a network connection for receiving user details from a remote terminal, and a controller; where, in use, the controller is operable to access the database to retrieve user data and screen configuration data corresponding to the user details, and to transmit the retrieved data to the remote terminal . 9. A self-service terminal system, characterised in that the system comprises a server interconnected to a plurality of self-service terminals, where the server is operable to receive enrolment data from a user relating to a customised screen, to associate the enrolment data with user data, and to store the enrolment data and associated data in a database; whereby, when the user uses one of the terminals, the terminal transmits user details to the server; the server accesses the stored data corresponding to the user details, and transmits the accessed data to the terminal; and the terminal operates on the transmitted data to generate and display a customised screen.

Inventors: DICKIE SHARON, GROSSI MARK MICHAEL, ROSSMANN WOLF DIETER, DICKIE, SHARON, GROSSI, MARK, MICHAEL, ROSSMANN, WOLF, DIETER
Applicants: DICKIE SHARON, GROSSI MARK MICHAEL, NCR INT INC, ROSSMANN WOLF DIETER, DICKIE, SHARON, GROSSI, MARK, MICHAEL, NCR INTERNATIONAL. INC., ROSSMANN, WOLF, DIETER
Application year: 2000
Main classification: G07F7
IPC codes: G06Q20, G07F19