The applicant has previously proposed a mobile commerce system known as"Pocket Bargainfinder" ; see"Pocket Bargainfinder : A Handheld Device for Augmented Commerce", Proceedings of the International Symposium on Handheld and Ubiquitous Computing" (HUC 1999), Adam B.

Brodie & Edward J. Gottsman (also available on the Internet as http ://www. ac. com/services/cstar/Publications/PocketBargainFinder- HUC99. PDF).

The Pocket Bargainfinder system includes a portable unit comprising a bar code scanner; a wireless communications device; and a small computing device. The bar code scanner is used to scan a product identification code (for example the ISBN of a book) and the computing device then uses the communications device to access a server via the Internet.

A cgi script is executed on the server which searches the Internet for sites where the book is on sale, and returns the corresponding prices as an HTML page for viewing on the computing device. One of the prices can be selected to allow the book to be purchased.

The applicant has also developed the information link (or Ilink) project, described in U. S. application 09/258,687 filed on 26 February 1999,

and described on the Internet at http ://www. ac. com/services/tech/tech_infolink. html.

The Information Link system permits newspapers to include bar codes next to advertisements. A portable Information Link unit comprises a bar code scanner, a computing device and a communications device, as with the Pocket Bargainfinder system. When the bar code next to an advertisement is scanned with the information link device, the computing device contacts a server using the communications device, and the server returns an HTML page for viewing on the computing device, containing information on the product and allowing the product to be purchased.

These systems allow the Internet to be used to make purchases wherever a user may be. Accordingly, they greatly increase the user's freedom to make impulse purchases when reading magazines or browsing in a store. However, the mobile terminals currently used include relatively sophisticated computing devices such as the Palm Pilot with associated wireless modem.

It is an object of the present invention to provide mobile commerce apparatus, methods and systems enabling transactions to be performed from a smaller terminal device such as a mobile telephone. Aspects of the invention, with corresponding advantages, are recited in the claims appended hereto.

The invention will now be illustrated, by way of example only, with reference to the accompanying drawings in which:

Figure 1 is a block diagram showing the elements of a mobile commerce system according to a first embodiment of the invention; Figure 2 is a flow diagram showing the operation of a first embodiment; Figure 3a is a first screen display produced in the first embodiment; Figure 3b is a second screen display produced in the first embodiment; Figure. 3c is a third screen display produced in the first embodiment; Figure 3d is a fourth screen display produced in the first embodiment; Figure 4 is a block diagram showing the elements of a mobile commerce system according to a second embodiment of the invention; Figure 5 is a flow diagram showing the operation of the second embodiment; Figure 6a is a first screen display produced in the second embodiment; Figure 6b is a second screen display produced in the second embodiment ; Figure 6c is a third screen display produced in the second embodiment; Figure 7 is a block diagram showing the structure of a mobile commerce system according to a third embodiment of the invention; Figure 8 is a block diagram showing a mobile commerce system according to a fourth embodiment of the invention;

Figure 9 is a block diagram of a mobile commerce system according to a fifth embodiment of the invention combining features of the first to third embodiments.

FIRST EMBODIMENT In this embodiment, a mobile telephone capable of operating Wireless Applications Protocol (WAP) forms the mobile commerce terminal.

Referring to Figure 1, the system comprises a printed article (for example a newspaper) 10 carrying a bar code 11, in association with an advert for a product (for example). A mobile terminal comprises a WAP-enabled mobile phone 20 such as the Nokia 6210 or 7110, with a portable bar code scanner 21 plugged onto the data port thereof.

The phone 20 is in communication with a mobile phone network (PLMN) 30, such as a GSM network, interconnected with the public switched telephone network (PSTN) 40. Connected to the PSTN 40 is a remote access server 50, connected to a WAP gateway server 60 which in turn is connected to the Internet 70.

The mobile phone network 30 and PSTN 40 comprise pre-existing components of a mobile and fixed telephony network.

Also connected to the Internet 70 is an application server 80, connected to a database portal server 90 arranged to interrogate a database 100. The database 100 may be an Oracle 8i database held on a disk drive of

the server 90, and the servers 80,90 may be Sun E450 servers, as may the WAP gateway server 60 (which may operate the Nokia WAP server program).

The process performed by this embodiment will now be described with reference to Figure 2. In a step 1002, to start a data call, the user dials the remote access server 50 (for example by pressing a speed dial key). The remote access server 50 routes the call to the WAP gateway server 60. As is well known (and defined in, for example, the wireless application-protocol architecture specification), the gateway server 60 provides encoding and decoding to carry WAP data in a compressed format to the phone 20. A session is thereby set up between the phone 20 and the gateway server 60.

In step 1004, the gateway server 60 connects via the Internet 70 to the application server 80.

In step 1006, the user moves the scanner 21 over the bar code 11 and the scanner 21 supplies the scanned numeric code to the data port of the phone 20, which is forwarded to the application server 80 via the gateway server 60 (step 1008).

In step 1010, the application server connects to the database portal server 90 and supplies it with the bar code number. The database portal server 90 interrogates the database 100, and retrieves product information from it (step 1008). The product information contains, for example, the price, as shown in Figure 3a.

The product information is sent to and displayed on the phone (step 1014). Together with the information page of Figure 3a is a optional menu, selectable by the user depressing button 22 on the phone 20. On the options menu shown in Figure 3b, four numbered options are selectable by the user using the numeric keypad (as is the practice for WAP applications). The first option allows the user to buy the product, the second allows the user to receive more, product information; the third allows the user to receive information on the company; and the fourth allows the user to receive information on related products.

The selected option number is sent to the server 80 (step 1008) which returns a further page containing the required additional product or company information for display on the phone 20, again including the option to receiving additional information or to purchase.

If the second, third or fourth options are selected (step 1016) corresponding data is retrieved from the database and displayed as above.

If (step 1016) the user selects the purchase option, a screen (shown in Figure 3c) is sent to and displayed by the phone, requesting the user to enter their PIN number. This is sent to the application server 80.

In step 1017, the record for the calling number (passed as part of the WAP data from the phone 20, or established using Calling Line Identity (CLID) network services, is used to retrieve the record held for the user in a database of all users. Each record contains the user dial number, and unique

to the user; billing data (for example, credit card details) and delivery data (for example the user's street address). The entered PIN code is compared with the stored one for that user.

If the incorrect PIN number is entered, the transaction is terminated (step 1018). If the correct PIN is entered (step 1018), the phone 20 displays a confirmation screen shown in Figure 3d, re-displaying the product price information and asking the user to confirm (by actuating key 22) that he wishes to proceed, in step 1020.

If the user does not confirm, the purchase process is terminated. If the user does confirm the purchase (step 1002), the application server 80 causes the database portal server 90 to retrieve data from the database 100 indicating the details of the order processing system of the retailer of the product (for example the IP address of the order processing system), and receives details from the database 100 from the server 90 (in step 1024).

In step 1026, the application server 80 formats the product information, user delivery address and user payment information into an order and transmits (step 1028) the order to the retailer or the routing system (not shown). The purchase process then ends.

At each stage, where a screen is displayed, on the phone 20, the user is able to navigate back to the preceding screen by depressing a button 23.

Thus, in this embodiment, the details identifying the product to be ordered are scanned by a bar code scanner (or alternatively may manually be

entered as a string of digits printed under the bar code, using the phone keypad) thus minimising the work performed by the user to place the order.

SECOND EMBODIMENT This embodiment is suitable for use with mobile phones which lack the facility to operate Wireless Application Protocol (WAP) as described in the first embodiment above. However, many such phone will be capable of operating Short Message Service (SMS), as defined in the European GSM standard. In particular, most mobile telephones in Europe and other GSM countries support the so called"SIM application toolkit"defined in draft GSM technical specification 11.14, version 5.6.0 of December 1997 and its successors. Other relevant SIM recommendation and/or technical specifications are 02.17 ("Subscriber identity modules") and 11.11. All of these are incorporated herein by reference.

The SIM application toolkit permits the microprocessor of a subscriber identity module (SIM) to perform a program, including steps of automatically dialling, sending and receiving short messages, and generating menu and other displays, by passing commands and data to and from the mobile phone within which the SIM is resident.

Accordingly, in this embodiment, the mobile phone 20 comprises a SIM 25 including a microprocessor 26 and memory 27 (not shown), the memory containing an application program which uses the SIM toolkit to perform the functions described below. A suitable SIM can be developed

using the SIM Toolkit development systems available from De La Rue card systems, GEMplus, Siemens, Schlumberger, Giesecke & Devrient, or others.

Referring to Figure 4, in this embodiment components corresponding to those in Figure 1 are denominated by the same reference numerals and will not be discussed further.

In this embodiment, the remote access server, WAP gateway server and web server of the previous embodiment are absent. In their place are provided a phone terminal 110, SMS gateway server 120 and Windows NT server 130. The GSM phone terminal 110 is connectable to the mobile phone network 30 to send and receive SMS messages. It is also connected to the SMS gateway server 120, which is connected to the NT server 130, which in turn is connected to the database portal server 90.

Referring to Figure 5, in step 1102, the user actuates the scanner 21 which scans the bar code 11. The scanner then signals to the phone 20 to initiate a GSM short message, which comprises the dial number of the GSM phone terminal 110, followed by the bar code.

In step 1104, the phone 20 sends the short message via the mobile phone network 30 to the phone terminal 110. As is well known, short messages are sent in a"connectionless"fashion; that is to say, it is sent without the mobile phone setting up a dial up circuit connection-via a signalling channel.

The short message is passed from the phone terminal 110 to the SMS gateway server 120, where it sits on a message queue. At the NT server 130, a visual basic program module is run every minute, to read and deal with all messages sitting in the queue. Accordingly, in step 1105, the server 130 passes the bar code to the database portal server 90 which interrogates the database 100 (step 1106).

The database 100 returns to the database portal 90 a product description text which is passed back to the NT server 130, where it is formatted into a short message addressed to the dial number of the calling phone (identified from the message in the message queue). The short message is sent to the SMS gateway server 120 which transmits it in step 1107 via the phone terminal 110 to the phone 20.

In step 1108, the message is displayed on the screen as shown in Figure 6a ; the message may be marked as being directed to the SIM application on the SIM card, which will correspondingly cause it to be displayed.

As shown in Figure 6a, the display includes a product description and the price. Additional information on other related products may also be supplied in the same message.

Each such option is presented on a different screen to the user. At each screen, the user can either move to a different screen (i. e. moving

forwards and backwards through the screens) or select the option to buy the item shown in the screen. These options are selected using the keys 22,23.

Where the option to buy is selected (step 1110), then as shown in Figure 6b, a new short message is generated in reply, addressed to the dial number of the phone terminal 110. The short message includes the word "buy"followed by the item number of the article to be purchased (e. g. 1, 2 or 3, where there are three, screens of products), the word"password". The user then types in their password (e. g. four digit PIN). This is sent in step 1112.

As described above, the short message is transmitted via the mobile phone network 30 and phone terminal 110 to the SMS gateway server 120, from which it is read by the NT server 130. The NT server 130 then performs a security check (step 1114), by text-searching the message for a four digit number (the PIN), extracting the phone number of the phone 20 from the message (the calling number performs part of each message), searching the list of registered users for a user with that number; and comparing the received information number to the stored PIN for that user.

If there is a mis-match, the purchasing process terminates (e. g. by sending a failure message back for display at the phone). If the identity matches, then, as in the first embodiment, the server 130 uses the payment details and delivery address from the user from the users record, and the product details previously received from the database 100, and formats them into an order in step 1116.

In step 1118, the order for the product, including the payment and delivery details, is transmitted to the ordering system of the advertiser (the details of which were retrieved from the database 100).

In step 1120, the server 130 formulates a confirmation message confirming the purchase of the item requested into a short message which is sent via the SMS server 120 through the terminal 110 and the mobile phone network 30 to the phone 20, where dut is displayed as shown in Figure 6c in step 1122. The process then finishes.

Various modifications to this embodiment will be apparent to the skilled person. Firstly, it is not necessary that the scanner should automatically generate the short message in step 1102; this could be initiated instead by the user starting a new message to the dial number of the phone terminal 110, which may be stored in his address book for easy reference.

The user may then enter the digit string written under, and corresponding to, the bar code.

The identity check could be performed at the phone 20, by the SIM.

The payment and delivery details could be held on the SIM and forwarded in an SIM generated short message, rather than being held at the server.

THIRD EMBODIMENT Some types of mobile phone may be unable to provide short message services or WAP functionality. Accordingly, in this embodiment, phones

which cannot support either WAP or SMS are supported using voice technology. Referring to Figure 7, components which are substantially the same as in the first or second embodiments are given the same numerals and will not be discussed further.

As compared with the first embodiment, a VoxML server 160 substitutes for the WAP gateway server, and a database portal server 190 capable of returning results in VoxML format rather than in WML format is employed in place of the server 90.

VoxML is a mark up language designed for browsing the Internet by voice, full details of which are available from Motorola, Inc. of Schaumberg, Illinois, USA; or on the Internet at http://www. voxml. com/voxml. html It is closely based on XML (extendible mark up language).

The process performed in this embodiment follows that of the first and reference should therefore be made to Figure 2, modified as described below.

In this embodiment, as in the first a session is initiated by the user dialling the remote access server 50 which connects to the VoxML server 160 which in turn connects to the application server 80. The call in this embodiment is a voice mode call, rather than a data mode call as in the first embodiment.

The bar code scanner 21 scans the bar code 11, and the bar code is displayed on the screen of the phone 20 to enable the user to read it out or enter the digits via the keypad.

At the VoxML server 160, the DTMF corresponding to the dialled digits is recognised, (or using speaker independence speech recognition the spoken digits are recognised). The VoxML server 160 operates a VoxML browser program, which transmits a request for information on the recognised bar code via the Internet 70 to the application server 80, the operation of which is substantially as described in the first or second embodiments. The application server signals to the database portal server 190 to interrogate the database 100, returning a file of information on the product which is formatted into VoxML and returned to the application server 180 and thence via the Internet 70 to the VoxML server 160.

At the VoxML server 160, it is text-to-speech converted, and synthesised speech output is generated and transmitted through the PSTN 40 and mobile phone network 30 to the phone 20. The same product details as were displayed in the first embodiment are here read out to the user, who then has the choice of requesting more information (e. g. by saying"more") or buying (e. g. by saying"buy"). The user's response is recognised by the VoxML server and transmitted back to the application server 80 where, as in the preceding embodiments, an order is generated.

The security in this embodiment may be as described above with the entry of a PIN number, spoken or entered on a keypad via the user.

Additionally, it would be possible to provider speaker recognition for additional security.

Various modifications to this embodiment will be apparent. For example, where the digits corresponding to the bar code are reproduced in the advertisement, the user may dispense with the bar code scanner and simply read these digits out or type them in via the keypad.

FOURTH EMBODIMENT Referring to Figure 8, details of this embodiment are similar to those of the third except as discussed below.

An interactive voice recognition (IUR) server 260 is provided in the place of the VML server. The IVR server 260 is connected to the application server 80, which is connected to a database portal server 290.

In this embodiment, the interactive voice response server 260 is arranged to recognise dialled DTMF digits or spoken numerals and words such as"yes","no","more"and"back"from the PSTN 40 and to send corresponding text on to the application server 80. It is also arranged to receive documents in extendible mark up language (XML) and to perform text-to-speech conversion on these to read out the contents of the documents.

In use, in this embodiment, the user calls the IVR server 260, and receives a voice menu inviting him to enter the bar code. The bar code may be scanned, and displayed for the user to enter manually via the keypad, or if the corresponding digit string is also printed may be entered directly by the user without the need for the bar code scanner 21.

The bar code is decoded and sent as a data message in a suitable format to the application server 80. The application server 80 passes the bar code to the database portal server 290 which retrieves a corresponding file of data from the database 100, and formats the data file into an XML page which is then transmitted back to the IVR server. The IVR server converts the XML page to speech, and reads out the product details and menu options, selectable by the user through use of the numeric keypad of the phone 20.

On selection of the"buy"option, as in the above embodiments, the application server retrieves the users payment and delivery details, and the advertiser's order system details, and constructs an order, sending a confirmation message to the IVR server 260 which is read out to the user confirming the purchase. The voice call is then terminated.

Various modifications to this embodiment will be apparent. For example, where the phone supports an application program capability (e. g. via a SIM card), the scanned bar code can then be used to automatically generate the key presses to transmit the bar code to the IVR server. As in earlier embodiments, in such cases, the payment and delivery details may be held on , the phone, and PIN checking may be performed at the phone.

It will be seen that this embodiment differs from the preceding embodiment in that some menu generation may be performed at the IVR server 260, and in that data is transmitted between the IVR server, the application server and the database portal in any convenient format (such as

XML) via a proprietary link, rather than in VoxML via the Internet as in the preceding embodiment.

The IVR technology required is reliable and widely available, and used at present in relation to call centres, for example.

FIFTH EMBODIMENT A fifth embodiment of the invention, illustrated in Figure 9, brings together the above described embodiments, to provide a system which can accept orders from any type of mobile phone (or fixed phone). A single product database 100 is accessed via either a WAP gateway server 60 (as in the first embodiment) or by a standard computer 61, via a firewall computer 71 for security, or via a gateway server 360 operating programs to implement both of the SMS gateway of the second embodiment and the VoxML server of the third.

SUMMARY It will be seen that the above described embodiments provide a mobile commerce solution supporting different access modes usable by mobile phones. Building on the applicant's earlier developments, the invention will create a enhanced advertising and purchasing experience whereby advertisements on the printed media can be used to provide interactive purchasing.

It will be understood that in the above embodiments, users will register to use the system in a registration process in which they supply the payment, PIN and delivery data required.

OTHER MODIFICATIONS AND EMBODIMENTS Many other variants are possible. For example, the printed document 10 may carry the telephone number to dial, associated with the advert. This could for example be separately printed as a digit string, or it could form part of the bar code itself. In fact, a different dial number could be associated with each bar code (although this is a less efficient use of number space).

Whilst product purchases have been described, it will be apparent that the invention could also be used for the purchase of downloaded products ; for example, by terminating the process with a data download to terminal equipment connected to the phone 20 (such as a file of music for playing on a MP3 device). It could also be used to order services rather than products (such as a car wash, for example). Finally, it could be used for the supply of information, without a purchase taking place.

Other variants and modifications will be apparent to the skilled person; any and all such variants are intended to be within the scope of protection.

For the avoidance of doubt protection is hereby sought for each and every new feature of combinations of features disclosed herein.