WO2009141614A1

WO2009141614A1 - Electronic ticketing

Info

Publication number: WO2009141614A1
Application number: PCT/GB2009/001276
Authority: WO
Inventors: Alexander Terrell
Original assignee: YOURRAIL Ltd
Current assignee: YOURRAIL Ltd
Priority date: 2008-05-20
Filing date: 2009-05-20
Publication date: 2009-11-26
Anticipated expiration: 2010-11-20
Also published as: GB0809151D0; GB2460240B; GB2460240A

Abstract

A method of electronic ticketing in which an image is displayed by a mobile device (102) that is eye-readable for inspection purposes. The method comprises receiving ticket specific data (701) at a mobile device (102). The ticket specific data defines graphical information comprising textual information (702) and graphics to be animated. The data also comprises a machine-readable code (1201) defining at least a unique ticket number and a means of authentication. The method also comprises executing an application on the mobile device (102), such that the application displays textual information and animates graphics on the screen of the mobile device for visual inspection. In addition, execution of the application results in machine-readable code being presented by the mobile device to allow authentication of the textual information.

Description

Electronic Ticketing

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority from United Kingdom Patent Application No. 08 09 151.4, filed 20 May 2008, the whole contents of which are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method of electronic ticketing, an apparatus for electronic ticketing, a mobile device for displaying an electronic ticket

2. Description of the Related Art

It is known for tickets for events and travel or vouchers that can be redeemed for goods or services to be sent to mobile phones. Some such tickets are known to comprise of a barcode displayed on a mobile phone's screen, so that the barcode can be scanned for validation. Such tickets and vouchers are typically transmitted using the short messaging service (SMS) or multimedia messaging service (MMS) message formats. Both of these formats can be copied. Methods exist using Digital Rights Management Software to restrict copying of MMS messages, but such methods can be overcome. It is also known for a database of used tickets or vouchers to be maintained to prevent ticket or voucher copying. A problem with this method is that there can at times be problems accessing and updating the database, particularly when ticket or voucher checks occur over a wide area, or just after a ticket or voucher has been issued. For travel markets, this has typically resulted in mobile phone tickets using SMS or MMS media being limited to advanced purchase tickets.

A further problem with such prior art tickets comprising a barcode is that it is often not possible to scan all barcodes when required. In particular, bar codes sent using SMS are limited in image quality and may be difficult to scan on some mobile phones or in the presence of sunlight.

BRIEF SUMMARY OF THE INVENTION The invention described herein relates to tickets which may be tickets for travel or for events or vouchers for the purchase of goods or services.

According to a first aspect of the present invention, there is provided a method of electronic ticketing in which an image is displayed by a mobile device that is eye-readable for inspection purposes, comprising the steps of: receiving ticket specific data at a mobile device, said data defining graphical information comprising textual information and graphics to be animated, and a machine-readable code defining at least a unique ticket number and a means of authentication; and executing an application on said mobile device, in which said mobile device includes a screen, such that said application is configured (i) to display said textual information and animate said graphics on said screen for visual inspection, and (ii) to present said machine readable code to allow authentication of said textual information.

According to a second aspect of the present invention, there is provided an apparatus for electronic ticketing, comprising a wireless application server and a database, wherein said wireless application server is configured to: retrieve booking information from said database to facilitate the booking of an event; write details of an event to said database in response to a purchase made by a customer using a mobile device having a viewable screen; and supply ticket specific data defining a ticket to said mobile device including a ticket expiry time, such that at said mobile device: said mobile device (i) displays graphical information comprising textual information and animated graphics on said viewable screen for visual inspection, and (ύ) present a machine-readable code to allow authentication of said textual information.

According to a third aspect of the present invention, there is provided mobile device for displaying an electronic ticket, in which said mobile device comprises a screen, and an executable application, such that when executed by said mobile device, said application: receives ticket specific data defining a valid time interval during which a ticket is valid; displays graphical information comprising textual information and animated graphics on said viewable screen for visual inspection; and presents a machine-readable code to allow authentication of said textual information.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Figure 1 shows a system in which tickets are provided by a wireless application server 101 to mobile devices 102, 103 and 104; Figure 2 shows a flowchart including several procedures performed by a mobile device;

Figure 3 shows further detail of the step 201 of installing the application; Figure 4 shows details of the registration procedure 304; Figure 5 shows an example of the user details received at step 401 and the subsequent packaging of data at steps 403 to 406;

Figure 6 shows details of the ticket purchase procedure 203 of Figure 2; Figure 7 shows the ticket data 701 received from the server at step 604; Figure 8 shows details of the step 205 of displaying a chosen ticket; Figure 9 shows details of the step 803 of displaying a ticket; Figure 10 shows details of the step 902 of displaying graphical information;

Figure 11 shows the mobile device 102 displaying on its screen 1101 an example of graphical information included in a ticket;

Figure 12 shows the mobile device 102 displaying the barcode 1201 on its screen 1101 ;

Figure 13 shows a simplified flowchart of some of the functions performed by the server 101;

Figure 14 shows details of the step 1304 of responding to a received acceptance of offer for sale; Figure 15 shows details of the step 1405 of creating a ticket; Figure 16 shows an example of a non-validated ticket 1601 displayed on mobile device 102.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Figure 1 A system in which tickets are provided by a wireless application server

101 to mobile devices (such as mobile phones 102, 103 and 104) is shown in Figure 1.

It is anticipated that a user, such as user 105 of mobile device 102 will wish to purchase a ticket (such as a ticket for travel or an event or a voucher for goods or services). Having bought such a ticket, it will often be necessary for the ticket to be shown to another person 106 for inspection. For example, the ticket in the case of a rail ticket will need to be shown to a guard 106 at a station or on a train. In another example, where the ticket is a bus ticket, it will be necessary for the ticket to be shown to the bus driver, and possibly a ticket inspector who boards the bus for the purpose of checking and validating tickets. For the purposes of speed and economy, at times it may be preferable for such a ticket inspection to be merely done by the inspector's eyes. However, the tickets of the present invention include both a visually readable component that may be inspected by eye and also a machine-readable code that is readable by electronic reading apparatus. As will be described below, in the present embodiment the ticket comprises a graphical code in the form of a barcode that may be read by a barcode reader, such as reader 107.

The server 101 receives data from service/goods providers 108A, 108B, etc. and maintains a retail product database 109 containing the received data. For example, the provider 108A may be a rail service provider which provides details of rail journeys, their times, their prices, etc.

The server 101 is also in communication with a payment gateway 110 through which payments from mobile devices 102, 103, 104 may be paid for the services and/or goods of the service/goods providers 108A, 108B. The server 101 may also have access to a verification database 111. The tickets supplied by the server 101 to the mobile devices such as device 102 each comprise a unique ticket number, along with other details, as will be described below. Details of the tickets sold, including the unique ticket number, are stored in the verification database. Consequently, when a ticket is read, for example by reader 107, the unique ticket number may be supplied to the server 101 along with details of where and when the ticket was read, and such information may be stored on the verification database.

In the present embodiment, the server also has access to a registration details database 112 in which details provided from mobile devices (such as 102, 103, 104) are provided in a registration procedure, to be described below.

Figure 2

A flowchart including several procedures performed by a mobile device, such as mobile device 102, are shown in Figure 2. Initially, at step 201, an application is installed on the mobile device. Details of this installation procedure will be described below with respect to Figure 3.

After installation of the application, the application generates a graphical user interface on the mobile device allowing the user 105 to provide an input indicating that they want to purchase a ticket or view a previously purchased ticket. Thus, in the flow chart of Figure 2, after installation of the application, the user is provided with a choice to purchase a ticket at step 202. If the user chooses to purchase a ticket, then a ticket purchase procedure 203 is performed, otherwise a question is asked at step 204 as to whether the user wishes to view a previously purchased ticket. If this question is answered yes then a procedure is performed at step 205 resulting in a chosen ticket being displayed. After display of the ticket at step 205, or in the event that the question at step 204 is answered negatively, the process returns to step 202.

Figure 3

The step 201 of installing the application is shown in further detail in Figure 3. Firstly, at step 301 a request for the application is sent from the mobile device 102 to the server 101. Typically, this is achieved by selecting a hyperlink attached to a SMS message (short message service message) previously received by the mobile, possibly in response to an SMS message previously sent from the mobile to the ticket service provider. Thus, by selecting the hyperlink a request is made for the application and in response the server identifies the correct version of the application for the mobile devices, and sends the application to the mobile device. Consequently, at step 302 the mobile device 102 receives the application, along with a public encryption key that is for subsequent asymmetric encryption. Following receipt of the application at the mobile device, the application is executed at step 303 to provide the mobile device with the functionality for a registration procedure at step 304 and the previously described steps 202 to 205 in respect of ticket purchases and displaying tickets.

Unlike prior art methods of obtaining tickets on mobile device, the present invention involves executing an application on the mobile device, so that the mobile device is able to communicate with the server 101 via the Internet, and thereby download data defining a ticket. In the present embodiment, such communication is performed by exchanging XML data packets using HTTP, and the application executed on the mobile device is a Java script.

Figure 4

The registration procedure 304 is shown in greater detail in Figure 4. Firstly, the process generates forms for display on the mobile device to allow the user 105 to enter details required by the registration procedure. At step 402, a symmetric (private) data encryption key is generated for use in later communications where data is encrypted and decrypted using the symmetric key.

In the present embodiment, the symmetric key is randomly generated, but embodiments are envisaged in which IMEI (International Mobile Equipment Identity) number of the mobile device is used as part of the symmetric key. Following steps 401 and 402, a first set of the user's details received at step 401 , along with the symmetric key generated at step 402, are encrypted at step 403 using the public encryption key received at step 302.

Consequently, a first encrypted part of a data package is produced at step 403.

Following step 403, the first encrypted part produced at step 403 is sent to the server 101, along with a user identifier, as a first (registration) package.

A second set of user details received at step 401, are then encrypted using the public key received at step 302. Thus, a second encrypted part, for inclusion in a second package, is generated at step 405.

The second encrypted part from step 405 is then stored along with the user identifier within the memory of the mobile device as a second package at step 406. This second package is used in subsequent ticket purchase procedures.

Figure s

An example of the user details received at step 401 and the subsequent packaging of data at steps 403 to 406 is illustrated in Figure 5.

Within the registration procedure 304, user details are entered at step 401 including the details of the payment card, i.e. credit or debit card, that the user intends to use for subsequent ticket purchases. Thus, the application receives all the information required by the payment gateway 110 to authorise a payment, including: the name on the credit card; the credit card type (e.g. Visa, Master Card, etc); the credit card number; the start date; expiry date; and CW (Card Verification Value) number. The user is also required to include their address.

In the present embodiment, the user identifier, which is included in both the first package 502 and the second package 503 is in the form of the !MEI number of the mobile device. As shown in Figure 5, each of the packets also includes the last four digits of the credit card number and the public key number. It should also be noted that the IMEI number, the last four digits of the card number and the public key number are included in the packages without encryption, so that the packages may be identified without decryption.

The first encrypted part 505 of first package 502 includes: the card expiry date; card start date; the name on the credit card; the country, postcode, and house number of the user's address; and the symmetric key.

The second encrypted part 505 of the second package 503 includes the card type; the first four digits of the card number; the middle eight digits of the card number; and the CW number of the card. Thus, only the card's start and expiry dates and name on the card are sent to the server in the registration process 304. Furthermore, these details remain stored in encrypted form, so that the details are provided with a degree of security.

The greater part of the card details are incorporated within the second encrypted part, which is stored at the mobile device. Consequently, after the registration procedure, if a third party attempted to illegally obtain the details of the credit card they would have to break into both the mobile device and the server's storage device (comprising database 112), as well as decrypt the first and second encrypted parts.

Figure 6

The ticket purchase procedure 203 of Figure 2 is shown in further detail in Figure 6. Firstly, at step 601 offers available from the service/goods provider

108 are displayed. In one example of the present embodiment, the service/goods providers 108A, 108B are rail service providers and their names are provided to the mobile device as part of the application download at step

302. Consequently at step 601, the user 105 is able to select a particular one of the service providers and download and display details of rail journeys, journey times and dates, ticket prices, etc.

At step 602 inputs are received from the user indicating which of the offers has been chosen by the user. In the present embodiment, payment is authorised at step 602 by the user re-entering the CW number into the mobile device. However, other embodiments are envisaged in which a separate password or PIN number (personal identification number) is provided by the user during the registration process and the correct, same password must be re-entered to authorise payment at step 602. In one embodiment, the password or PIN number forms part of asymmetric key that is used to encrypt the data on the mobile device.

Having received authorisation at step 602, the second package 503 is sent to the server 101 at step 603. In return, ticket data is received at the mobile device from the server at step 604.

As will be described below, a part of the ticket data received from the server at step 604 is encrypted using the symmetric key that was included in the first encrypted part of the first (registration) package 502, sent to the server in the registration procedure 304. Consequently, that encrypted part of the ticket is decrypted at step 605 using the symmetric key. At step 606 the ticket data is stored in a wallet (folder) for later display of the ticket.

Figure 7

The ticket data 701 received from the server at step 604 is illustrated in Figure 7. The tickets data comprises a graphical information part 702 and a machine-readable part, which in the present embodiment is a barcode part 703. The graphical information part comprises data that is to be presented as human-readable information on the mobile device display. In the present example, the graphical information part includes data defining a unique ticket number (as stored in the verification database 111), a date relating to the event for which the ticket was bought, a code for the day, a "valid to" time (an expiry time for the validation of the ticket), ticket details (for example, details of a railway journey) and other non-textual graphical information (such as a company logo). As previously mentioned, the data in the graphical information part of the ticket data is encrypted using the symmetric data encryption key that was first generated by the mobile device itself.

The barcode part of the ticket data includes data relating to some or all of the same information as the graphical information part of the ticket data. In the present example it includes a unique ticket number, the date, the code for the day, the "valid to" time and other ticket details. As Illustrated in Figure 7, with the exception of the unique ticket number, the data in the barcode part of the ticket is digitally signed using a private authentication key of an asymmetric (public) key pair.

Figure 8

The step 205 of displaying a chosen ticket is shown in further detail in Figure 8. Initially within step 205, the application on the mobile device displays a list of tickets currently stored in the wallet in the mobile device, at step 801. It is then determined at step 802 whether or not the user has provided an input identifying one of the listed tickets. If such an input has been received, the chosen ticket is displayed at step 803. If no such input has been received at step 802, or after displaying the ticket at step 803, a question is asked at step 804 as to whether an input has been received indicating that the ticket display function is to be exited. If no such input has been received the process returns to step 801. However, if such an input has been received at step 804 then step 205 is completed.

Figure 9

The step 803 of displaying a ticket is further detailed in Figure 9. Initially, the graphical information part of the ticket data 702 that was decrypted at step

605 is retrieved at step 901. Although the graphical information part of the ticket data determines what is to be displayed, the application itself determines how the graphical information is to be displayed. Thus, at step 802 the graphical information defined by the graphical information part of the ticket data is displayed in accordance with the requirements of the application. Specifically, the application requires at feast one graphic element to be animated. That is, at least one graphic element must have a change in appearance, such as by movement, change in form, change in colour, change in size, etc. It may be noted that in the present embodiment the graphical information includes an animated graphical element in the form of a decrementing timer and two interchanging logos that move across the top of the screen.

After displaying the graphical information at step 902, or while such graphical information is still being displayed, it is determined at step 903 as to whether or not a request to exit the ticket has been received. If such a request has been received then step 803 is complete. However, if no such request is received at step 903, then it is determined at step 904 whether a request has been received for display of machine-readable code, in the present case a barcode. If no such request has been received then the process returns to step 901. However, if a request for barcode display has been received then at step 905 a barcode is rendered using the barcode part 703 of the ticket data 701. It should be noted that the barcode part 703 of the ticket data is rendered without any decryption. Thus, the barcode includes an unencrypted unique ticket number but also a digitally signed component

The barcode generated at step 905 is displayed at step 906 and then it is determined whether or not an input has been received indicating that the textual display is required again, at step 907. If no such request is received the barcode continues to be displayed at step 906, but if such a request is received at step 907 the process returns to step 901.

Figure 10

The step 902 of displaying graphical information is shown in further detail in Figure 10.

As is currently the case with mobile telephones, the mobile device 102 includes a real-time clock. Thus, initially within step 902, at step 1001 , the application obtains the current time provided from the real-time clock of the mobile device.

The time provided by the real-time clock is then subtracted from the "valid to" time provided in the graphical information part 702 and the ticket data 701. Thus, a "valid for" time is generated at step 1002. The text, and any other graphics, defined by the graphical information part of the ticket data is then displayed at step 1003 along with the "valid for" time. It will be understood that as the graphical information is displayed at step

902 the steps 1001 and 1002 are repeatedly performed resulting in the "valid for" time being a decrementing timer.

In an alternative embodiment, a fixed period of time for which the ticket is valid is indicated in the ticket data, in this embodiment, whatever time is given on the real-time clock of the mobile phone, it is only used as a timer to count down the time from the defined fixed period. For example, a bus ticket received at the mobile phone may be valid for a fixed period of two hours, and the application merely uses the clock to count down time starting from two hours.

Figure 11

The mobile device 102 is shown in Figure 11. The mobile device 102 in this example is a mobile phone, but it will be understood that other mobile devices capable of communicating over the Internet in a mobile cellular telephone network may be used.

The mobile device 102 is shown in Figure 11 displaying on its screen 1101 an example of graphical information included in a ticket. Thus, the graphical information includes the "valid to" time (or expiry time) 1102 and date

1103 by which time and date the ticket must be used. In addition, the information includes the "valid for" time 1104, indicating the remaining time for which the ticket is valid. Consequently, the user of the phone can simply read the "valid for" time and know for how much longer the ticket is valid. In this example, two hours thirteen minutes and nine seconds left before the ticket, can no longer be used. This "valid for" time, is considered to be most useful on public transport such as buses where the duration of the ticket is short.

The displayed ticket example in Figure 11 is a rail ticket and it includes details of the journey such as "STD-OFF-RTN" indicating that the ticket is a standard, off-peak return. In an embodiment of the invention, the user of the device 102 is able to select text such as "STD-OFF-RTN" and having selected it obtain a further screen for display providing an explanation of the abbreviation.

In a further embodiment, the user is able to select text indicating the departure or arrival location. On receipt of such a selection, the application calls up live travel information, such as train departures and arrivals, from a third party web service, or third party application.

The ticket information also includes the unique ticket number 1106 and a code for the day (a day specific code) 1107. Each ticket issued by the server 101 is provided with such a code for the day, the code for the day being a code that is unique to the date 1103 of the journey. Thus, if a person attempted to fraudulently create such a ticket on their mobile phone they would first of all need to know what the correct code for the day is for their intended day of travel. As mentioned previously the "valid for" time 1104 is a decrementing timer and this too is considered to be an item that is easily inspected but difficult to fraudulently reproduce.

Thus, a person such as a railway guard, a bus driver or ticket inspector can easily, by viewing the code for the day 1107 and/or the decrementing timer 1104 observe that the ticket appears to be a valid ticket.

In addition, the ticket also includes a non-text graphic 1108, which may be a logo of the service provider. Such a graphic may also be animated, providing further complexity to the ticket, to prevent fraudulent copying.

The mobile device 102 also displays two buttons 1109 and 1110. The first button 1110 is a "back" button allowing the user to exit the ticket display as described above in respect of step 903.

The button 1109 allows a user to request that the barcode part of the ticket be displayed, as described above with respect to step 904.

Figure 12 The mobile device 102 is shown again in Figure 12 after the button 1109 has been selected. Thus, Figure 12 shows the mobile device 102 displaying the barcode 1201 on its screen 1101. The barcode 1201 is a two- dimensional barcode, and in the present embodiment it is a forty-five by forty- five (45 x 45) Aztec barcode rendered to a size appropriate for scanning. As mentioned previously, the barcode defines the unique ticket number

(for example 1106 of Figure 11) in a non-encoded form. Therefore, the barcode may be simply read to obtain the unique ticket number which may then be compared with the unique ticket number 1106 of Figure 11, thus providing a very simple check of the ticket's authenticity. Where a database of the unique ticket numbers is available, this ticket number can also be checked against such a database to ensure that it is valid. Furthermore, as mentioned previously, such an inspection of the unique ticket number may also be logged on the verification database 111 by the server 101. Thus if two separate uses of the ticket are logged, this may be identified by the server 101 and the ticket's further use may be blocked. Alternatively, the purchaser of the ticket could be blocked from further use of the system or pursued in respect of their potential fraud.

As also mentioned above, the barcode defines a digitally signed part that may be decrypted using the correct public key. Thus, an inspector of the ticket may read the barcode and by successfully decoding the digitally signed part, authenticate the ticket.

As scanning the barcode and decrypting the digitally signed part generates similar information to that on the visually readable screen as shown in Figure 11 , it becomes possible for an inspector of the ticket to compare the two sets of information and determine whether or not the ticket has been tampered with.

In some circumstances, it is intended that scanning will not be done on every ticket. For example, where tickets are of low value, such as used on a bus, they will only be scanned when a revenue inspector boards the bus. However, the revenue inspector would be expected to scan every ticket, and if two tickets were found to have the same unique ticket number, the scanner would be configured to provide an alert for the inspector. In addition, all barcode scan records may be centrally collated and analysed to identify potential fraudulent use.

Although the barcode is useful in authenticating the ticket, it is anticipated that it may also be used at an automatic gate where access is provided by displaying the barcode to a barcode reader associated with the gate.

As well as the barcode 1201, it may be noted that the screen 1101 includes a "back" button allowing the user of the mobile device 102 to return to the screen shown in Figure 11. Thus, the button 1202 allows the user to make a request in accordance with step 907.

In the present embodiment, the textual information part of the ticket and the machine-readable part of the ticket are displayed at different times to allow the barcode to be rendered as relatively a large image. Consequently, the text and the barcode are relatively easily read. However, where trie mobile devices' screen resolutions and dimensions permit, it is envisaged that the whole of the ticket may be presented simultaneously on a single screen.

Figure 13

Some of the functions performed by the server 101 are shown in a simplified flow chart in Figure 13.

Where the server 101 receives a request for information by a mobile device at step 1301 information is retrieved from the retail product database 109 and sent to the requesting device. Depending upon the complexity of the ticket sale procedure, the information sent to the requesting device will include an offer of sale for the service or goods to which the information relates. For example, in the example of rail tickets, a mobile device may request information relating to a particular rail service and the server returns information of the rail stations from where and to where journeys are provided. Having selected the two stations relating to a journey, a mobile device may request further details of the journey, in which case the request received at step 1301 may result in the server providing ticket choices, such as single, return, off-peak etc and the corresponding prices.

Where the server receives an acceptance of an offer from a mobile device at step 1303, the server responds to the mobile device at step 1304 and updates the validation database 111 at step 1305. Thus, at step 1304 the mobile device accepting the offer of sale of a ticket is provided with a ticket having a unique ticket number, and the details of the ticket, along with the unique identification number are logged at step 1305.

Figure 14 The step 1304 of responding to a received acceptance of offer for sale is shown in further detail in Figure 14.

As described above, when a mobile device buys a ticket, i.e. accepts an offer for sale, it sends the second package 503, which incorporates the second encrypted part, produced during the registration process 304. Thus, initially within step 1304, at step 1401 , the second encrypted part of the second package is decrypted using the private key corresponding to the public key identified in the second package.

The corresponding first package is then retrieved from the registration details database at step 1402. The encrypted part 504 of the first package 502 is then decrypted at step 1403. Using the private key corresponding to the public key identified in the first package. (It maybe noted that this is also the same public key as in the second package.)

Having decrypted the first and second encrypted parts of the packages

502 and 503 the credit card details and payment details are transmitted to the payment gateway 110 to obtain payment authorisation at step 1404. Having obtained payment authorisation a ticket is created at step 1405 and the ticket is sent to the purchasing mobile device at step 1406.

As an alternative to decrypting the first and second encrypted parts of the packages at the server 101, it is envisaged in an alternative embodiment that the encrypted parts be transmitted to the payment gateway for decryption at the payment gateway. In this embodiment, the private key is kept secret at the payment gateway and is not known to the server 101. In this embodiment, the public key number (or numbers) that are supplied to the mobile devices in the registration procedure are provided by the payment gateway.

Figure 15

The step 1405 of creating a ticket is shown in further detail in Figure 15. At step 1501 data to be included in the ticket is retrieved at step 1501, and the data to be included in the graphical information part (702) of the ticket data is encrypted using the symmetric private key obtained from the mobile device in the first package at steps 1402 and 1403. The fact that the graphical information part of the ticket data is encrypted means that if the ticket data becomes intercepted during its transmission, it cannot be used to create a copy of the ticket unless the person intercepting has knowledge of the symmetric key. As previously mentioned, in one embodiment a part of the symmetric key comprises a selected part of the IMEI number of the requesting mobile device. In this embodiment, when the ticket is received back at the requesting mobile device, the application resident on the receiving mobile device ensures that the selected part of its IMEI number is present in the symmetric key. If it is not present then the decryption of the graphical information part of the ticket data is blocked. Thus, this feature ensures that the IMEI number of the receiving mobile device matches the IMEI number of the requesting mobile device, and if not then decryption using the symmetric key is prohibited.

At step 1503, the data to be included in the digitally signed part of the barcode part (703) of the ticket data is encrypted using a private signature key of an asymmetric (public) key pair. In an alternative embodiment, a symmetric authentication key is used to encrypt the digitally signed part of the barcode data. However, as the private signature key is also used for subsequent authentication of the barcode, this method is only practical where the readers of the barcode can maintain the secrecy of the key. After step 1503, the barcode part (703) of the ticket data is produced at step 1504 from the digitally signed barcode data generated at step 1503 and the unique ticket number.

The complete ticket data is then assembled by concatenating the barcode part 703 and the graphical information part 702 at step 1505.

Figure 16

In the above-described embodiment, it is envisaged that validated tickets will always be supplied to the mobile devices. However, in an alternative embodiment the ticket is provided to the mobile device in a non-validated form, and is validated in a separate transaction initiated by the user. This embodiment is used for the case where the ticket is not for immediate travel. For example, a rail journey ticket may be valid for thirty days from purchase and this ticket will be provided in a non-validated form to the mobile device. When the user wants to use the ticket (for example, just before boarding the train). The user validates the ticket. As another example, the user may purchase a set of tickets (often called a camet). The user receives all of the tickets in a non-validated form and validates them individually one by one, as required.

An example of a non-validated ticket 1601 is shown displayed on mobile device 102 in Figure 16. The graphical information part of the ticket, shown in Figure 16 is similar to that of a valid ticket but does not show the "valid to" time 1102 (as shown in Figure 11). Instead, the words "not validated" are displayed. Also, as the "valid to" time was not included in the ticket data the displayed graphical information also does not show a decrementing "valid for" time. Furthermore, the ticket does not include a date or corresponding "code for the day".

In addition, in place of the button 1109 (shown in Figure 11) the non- validated ticket of Figure 16 has a validation button 1602 allowing the user of the mobile device to request, from the server 101, the validation of a ticket having a specified unique ticket number. Upon receiving the request the server responds by assembling the required data, including date, code for the day,

"valid to" time, and generating the corresponding barcode data, as previously described. The assembled data and the barcode data are then transmitted to the requesting mobile device, so that the application can update the pre- validation ticket to a validated ticket (such as that shown in Figures 11 and 12.

In an alternative embodiment, normally reserved for blocks of lower value tickets, the validation process is performed by the mobile device, without communication with the server. In this case all tickets within the block have the same barcode and the same code of the day, but the mobile device issues a new sequence number for each ticket from the block, and this sequence number is displayed on the ticket. The application on the mobile device ensures that only a set number of tickets can be created and controls the sequence numbering of the ticket. In this embodiment, the mobile device displays the time the ticket was created, the time the ticket expires, and the time remaining ti\\ expiry. This embodiment is susceptible to the application on the phone being compromised and is therefore proposed for lower value tickets.

As mentioned above, in the present embodiment the tickets displayed by the mobile device include a machine-readable code in the form of a barcode. However, other machine-readable codes that are presented by the mobile device as a part of a ticket are envisaged. For example, in one embodiment the mobile devices are equipped with a near field communications (NFC) device, and the machine-readable code presented by the mobile device for inspection comprises data transmitted by the near field communications device in a near field communications information exchange.

In this embodiment, the near field communication capabilities of the mobile device are initialised by a user input requesting display of the visual (graphical information) part of the ticket. Once initialised, the mobile device's near field communications device responds to near field communications requests by presenting the machine-readable code part of the ticket, as a NFC data push.

Claims

1. A method of electronic ticketing in which an image is displayed by a mobile device that is eye-readable for inspection purposes, comprising the steps of: receiving ticket specific data at a mobile device, said data defining graphical information comprising textual information and graphics to be animated, and a machine-readable code defining at least a unique ticket number and a means of authentication; and executing an application on said mobile device, in which said mobile device includes a screen, such that said application is configured (i) to display said textual information and animate said graphics on said screen for visual inspection, and (ii) to present said machine readable code to allow authentication of said textual information.

2. The method of claim 1, wherein said method comprises: receiving ticket specific data defining a valid time interval during which a ticket is valid; receiving a real-time clock signal from a real-time clock within the mobile device; and incorporating a time-related element into said animated graphics that is maintained during said valid time interval.

3. The method of claim 2, wherein said time related element includes a decrementing timer.

4. The method of any one of claims 1 to 3, wherein said application sends details of a journey defined by said ticket specific data to a web service or third party application providing real-time travel information, to request realtime travel information directly relating to said journey.

5. The method of any one of claims 1 to 4, wherein said ticket specific data is received in a non-validated form such that a non-validated ticket is displayed, and wherein validation of said ticket is executed in a second step in which said application requests validation and additional information required to provide validation is received from a server external to said mobile device.

6. The method of any one of claims 1 to 4, wherein said ticket specific data is delivered in a non-validated form, and validation of said ticket specific data is executed in a second step initiated by a user of the mobile device, in which additional information required to provide validation is generated by said application without reference to any system external to said mobile device.

7. The method of any one of claims 1 to 6, wherein said machine- readable code comprises a barcode.

8. The method of any one of claims 1 to 7, wherein said graphical information includes a date and a day specific code, said day specific code being unique to said date.

9. The method of any one of claims 1 to 8, wherein said mobile device is used to order said ticket prior to receiving said ticket specific data.

10. The method of claim 9, wherein customer banking details are divided into a first part and a second part, wherein said first part is registered with a supplier and said second part is supplied after placing said order and prior to receiving the ticket specific data.

11. The method of claim 9, wherein: customer banking details are divided into a first part and a second part during a registration procedure in which said first part is registered with a supplier; and said second part is encrypted to produce an encrypted second part which is stored at said mobile device and supplied to said supplier after placing said order and prior to receiving the ticket specific data.

12. The method of any one of claims 1 to .11, wherein said data defining graphical information is encrypted.

13. The method of any one of claims 1 to 12, wherein said means of authentication comprises data within said graphical code that is digitally signed using a private asymmetric key.

14. An apparatus for electronic ticketing, comprising a wireless application server and a database, wherein said wireless application server is configured to: retrieve booking information from said database to facilitate the booking of an event; write details of an event to said database in response to a purchase made by a customer using a mobile device having a viewable screen; and supply ticket specific data defining a ticket to said mobile device including a ticket expiry time, such that at said mobile device: said mobile device (i) displays graphical information comprising textual information and animated graphics on said viewable screen for visual inspection, and Qi) present a machine-readable code to allow authentication of said textual information.

15. A mobile device for displaying an electronic ticket, in which said mobile device comprises a screen, and an executable application, such that when executed by said mobile device, said application: receives ticket specific data defining a valid time interval during which a ticket is valid; displays graphical information comprising textual information and animated graphics on said viewable screen for visual inspection; and presents a machine-readable code to allow authentication of said textual information.

16. The mobile device of claim 15, wherein said mobile device comprises a real-time clock, and graphical information includes a time related element by receiving an input from said real-time clock.

17. The mobile device of claim 16, wherein said time related element includes a decrementing timer.

18. The mobile device of claim 15, wherein said mobile device is a mobile cellular telephone.

19. The mobile devfce of any one of. claims 15 to 18, wherein said application is configured to divide customer banking details into a first part and a second part, wherein said first part is registered with a supplier and said second part is stored in an encrypted form at said mobile device for later supply after placing an order and prior to receiving the ticket specific data.

20. The mobile device of any one of claims 15 to 19, wherein said machine-readable code comprises a barcode.