Patent Description:
Work of the presently named inventors, to the extent it is described in the background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present invention.

In recent years, terminal devices such as smartphones, tablet computers and the like have become more capable at performing a wide range of data processing tasks. These include allowing a large variety of different types of information to be transmitted between users of such devices (such as voice calls, textual messages, videos and images) as well as allowing such terminal devices to be used for performing further data processing functions which would normally (in the past) have required a separate device and/or process.

One such example of such new functionality of terminal devices is the electronic storage of items which, traditionally, would have required to be present as a physical hard copy (such as a paper copy). Such items include electronic tickets, coupons or the like. In particular, it is now possible for terminal devices to store digital data representative of transport tickets (such as railway tickets, bus tickets and the like), event tickets (such as cinema or theatre tickets) or any other similar data which, in the past, would have required a user to carry a separate hard copy of a ticket.

A paper by Fan Kai et. entitled "NFC Secure Payment and Verification Scheme for Mobile Payment" describes an NFC mobile electronic ticket secure payment and verification scheme. The proposed scheme uses a CS E-Ticket and offline session key generation and distribution technology to prevent major attacks and increase the security of NFC. Another paper by Feng Bao et. entitled "Design of portable mobile devices based e-payment system and e-ticketing system with digital signature" describes the application of digital signature in e-payment and e-ticketing systems where distributed verification is required. <CIT> describes systems and methods for facilitating use of physical tokens in a transit system.

A problem, however, is how to ensure the authenticity (that is, that the tickets are genuine) and integrity (that is, that the tickets have not been altered by an unauthorised party) of such electronic tickets. In particular, it is desirable to prevent fake or forged electronic tickets to be stored on terminal devices and used in order to grant a user of such a terminal device unauthorised access to a ticketed transport network, event or the like. There is therefore a need to alleviate these problems.

Data processing apparatus <NUM> comprises a communication interface <NUM>, a controller <NUM>, an electronic display <NUM> (such as a liquid crystal display (LCD) or the like) and a user interface <NUM>. Each of these components may be implemented using appropriate circuitry, for example. The communication interface <NUM>, display <NUM> and user interface <NUM> are controlled by the controller <NUM>. In particular, the controller <NUM> comprises processing circuitry configured to process instructions for controlling the operation of each of the communication interface <NUM>, display <NUM> and user interface <NUM>. In an embodiment, the data processing apparatus <NUM> is a point of sale (POS) device for allowing a user to purchase an electronic ticket.

The data processing apparatus <NUM> comprises a communication interface <NUM>, a controller <NUM>, a storage medium <NUM>, an electronic display <NUM> (such as an LCD or the like) and a user interface <NUM>. Each of these components may be implemented using appropriate circuitry, for example. Each of the communication interface <NUM>, storage medium <NUM>, display <NUM> and user interface <NUM> is controlled by the controller <NUM>. In particular, the controller <NUM> comprises processing circuitry configured to process instructions for controlling the operation of each of the communication interface <NUM>, storage medium <NUM>, display <NUM> and user interface <NUM>. In an embodiment, the data processing apparatus <NUM> is a terminal device such as a smart phone or tablet computer belonging to a user who wishes to purchase an electronic ticket for storage in the storage medium <NUM> of the terminal device <NUM>.

The data processing apparatus <NUM> comprises a communication interface <NUM>, a controller <NUM>, an electronic display <NUM> (such as an LCD display or the like) and data output circuitry <NUM>. Each of these elements may be implemented using appropriate circuitry, for example. Each of the communication interface <NUM>, display <NUM> and data output circuitry <NUM> are controlled by the controller <NUM>. In particular, the controller comprises processing circuitry configured to process instructions for controlling an operation of each of the communication interface <NUM>, display <NUM> and data output circuitry <NUM>. In an embodiment, the data processing apparatus <NUM> is for checking the authenticity and/or the validity of an electronic ticket stored in the storage medium <NUM> of a terminal device <NUM> of a user wishing to gain access to a ticketed service such as a transport network or event.

In the following embodiments, the data processing device <NUM> is assumed to be a POS device, the data processing apparatus <NUM> is assumed to be a terminal device and the data processing apparatus <NUM> is assumed to be a ticket checking device. However, it will be appreciated that the principles described may be applied to any data processing apparatus which is configured to implement the functions of the described components of each of the POS device <NUM>, terminal device <NUM> and ticket checking device <NUM>. The present technique is therefore not limited for use with the specific device types as described.

In an embodiment of the terminal device <NUM>, the communication interface <NUM> is configured to transmit data to or receive data from the POS device <NUM> using electromagnetic induction when the terminal device <NUM> is brought into proximity to the POS device <NUM> (in particular, when the communication interface <NUM> of the terminal device <NUM> is brought into proximity to the communication interface <NUM> of the POS device <NUM>). The communication interfaces <NUM> and <NUM> may implement Near Field Communication (NFC) technology, for example. NFC technology enables data to be transmitted between two NFC interfaces when those interfaces are brought to within a proximity of each other of the order of a few centimetres (in particular, less than <NUM>). The controller <NUM> is configured to control the communication interface <NUM> to transmit first data indicative of a user of the terminal device <NUM> to the POS device <NUM>. The first data is data for identifying specifically the user of the terminal device <NUM> and according to the invention, is an electronic payment card number indicative of an electronic payment card of the user of the terminal device <NUM>. The electronic payment card may be a credit card, debit card or charge card, for example, and the electronic payment card number may be a primary account number (PAN). The controller <NUM> is configured to control the communication interface <NUM> to transmit second data to or receive second data from the POS device <NUM>, the transmission or reception of the second data occurring in response to the completion of a predetermined data processing event. In an embodiment, the predetermined data processing event is an electronic payment card payment made by the user of the terminal device <NUM> to a user (e.g. ticket vendor, such as a transport organisation, theatre or cinema) of the POS device <NUM>. The controller <NUM> is configured to control the communication interface <NUM> to receive third data from the POS device <NUM>. The third data is received in response to the completion of the predetermined data processing event (e.g. payment for a ticket) and is digitally signed by the POS device <NUM>. The digital signature of the third data is generated using the first data and the third data. In the example in which the POS device <NUM> is a POS device of a ticket vendor, the third data comprises an electronic ticket for allowing the user of the terminal device <NUM> to use a predetermined service which requires the user to have a ticket in order for the service to be delivered. As previously mentioned, an electronic ticket is a ticket in electronic form. It comprises digital data representative of an ticket which grants a user access to use a particular ticketed service. An electronic ticket may be used instead of a paper ticket, for example. The controller <NUM> stores the received third data (e.g. the electronic ticket data) in the storage medium <NUM>. It is noted that, more generally, the third data need not represent electronic ticket data but may represent, more generally, electronic content provided to the user of the terminal device <NUM> in response to the completion of the electronic payment card payment. The electronic content may be any content for which there is a benefit in being able to authenticate the source of the electronic content using a digital signature. Although the below-mentioned embodiments discuss the specific use of electronic tickets, it will be appreciated that these same embodiments may be applied for use with electronic content more generally (and are therefore not limited to use only with electronic tickets).

In an embodiment of the POS device <NUM>, the communication interface <NUM> is configured to transmit data to or receive data from the terminal device <NUM> using electromagnetic induction when the terminal device <NUM> is brought into proximity to the POS device <NUM>. For example, the communication interface <NUM> may be an NFC interface (in which case, again, the terminal device <NUM> is brought into proximity to the POS device <NUM> when brought within a distance of the order of a few centimetres of the POS device <NUM>, in particular less than <NUM>). The controller <NUM> is configured to control the communication interface <NUM> to receive first data indicative of a user of the terminal device <NUM> from the terminal device <NUM>. As previously described, according to the invention, the first data is an electronic payment card number of an electronic payment card of the user of the terminal device <NUM>. The controller <NUM> is configured to control the communication interface <NUM> to transmit second data to or receive second data from the terminal device <NUM>, the transmission or reception of the second data occurring in response to the completion of a predetermined data processing event (e.g. the completion of an electronic payment card payment made by the user of the terminal device <NUM> to a vendor operating the POS device <NUM>). In response to the completion of the predetermined data processing event, the controller <NUM> is configured to generate third data (e.g. electronic ticket data) and to digitally sign the third data using the first data and third data. The controller <NUM> then controls the communication interface <NUM> to transmit the digitally signed third data to the terminal device <NUM>.

In an embodiment of the ticket checker <NUM>, the communication interface <NUM> is configured to receive first data from the terminal device <NUM>, the first data being indicative of a user of the terminal device <NUM> (e.g. the first data comprising an electronic payment card number of an electronic payment card of the user of the terminal device <NUM>). This is the same first data that was previously transmitted to the POS device <NUM>. The communication interface <NUM> is configured to receive second data from the terminal device <NUM>, the second data having been previously received by the terminal device <NUM> in response to the completion of a predetermined data processing event and being digitally signed using the first data and second data. Thus, in this case, the second data may comprise electronic ticket data which has been generated and signed by the POS device <NUM>, stored in the storage medium <NUM> of the terminal device <NUM> and transmitted from the terminal device <NUM> to the ticket checking device <NUM> together with a digital signature generated using the electronic ticket data and the first data (e.g. electronic payment card number). The controller <NUM> is then configured to perform a verification process of the digital signature of the second data. In response to a successful verification of the digital signature of the second data, the controller <NUM> is configured to output a signal indicating that the digital signature of the second data has been verified. On the other hand, in response to an unsuccessful verification of the digital signature of the second data, the controller <NUM> is configured to output a signal indicating that the digital signature of the second data has not been verified.

In the example in which the second data is representative of an electronic ticket, in response to a successful verification of the digital signature of the electronic ticket, the controller <NUM> may output a signal to control the display <NUM> to indicate that the electronic ticket has been successfully verified and/or to output a signal to control the data output circuity <NUM> to output a signal to another device such as a ticket barrier (not shown) to open electronically controlled gates of the ticket barrier in order to allow the user of the terminal device <NUM> access to the ticketed service associated with the electronic ticket.

It is noted that the communication interface <NUM> may receive the first and second data from the terminal device <NUM> using electromagnetic induction when the terminal device <NUM> and ticket checking device <NUM> are brought into proximity to each other (e.g. if the terminal device <NUM> is brought into proximity of a reader device comprising the communication interface <NUM> of the ticket checking device <NUM> at the entrance to a transport network or event). The communication interface <NUM> may operate using NFC, for example (in which case, again, the terminal device <NUM> is brought into proximity to the checking device <NUM> when brought within a distance of the order of a few centimetres of the checking device <NUM>, in particular less than <NUM>). Alternatively, the first and second data received by the checking device <NUM> may be received via any other suitable method for transmitting data from one device to another device. For example, the first and second data received by the checking device <NUM> may be received as a radio signal transmitted by the terminal device <NUM> (more specifically, the first data (e.g. electronic payment card number) and second data (e.g. electronic ticket data with digital signature) is comprised within a radio signal transmitted from the communication interface <NUM> of the terminal device <NUM> to the communication interface <NUM> of the checking device <NUM>). Such a radio signal may be a Wi-Fi signal or Bluetooth signal, for example.

Thus, with the present technique electronic data representative of an electronic ticket may be obtained by a user of a terminal device <NUM> and stored in a storage medium <NUM> of the terminal device following a purchase of that electronic ticket by the user at a POS device <NUM>. In an embodiment, the purchase is carried out by the user of the terminal device <NUM> using a suitable NFC payment service such as Contactless EMV ® (see https://www. com/emv-technologies/contactless/ for access to the Contactless EMV ® specifications).

Following a successful transaction, the digital data representative of the electronic ticket is transferred to the terminal device <NUM> over the same communication interfaces <NUM> and <NUM> used for completing the electronic payment. The data received by the terminal device <NUM> is provided with a digital signature generated using the digital ticket data and the first data (e.g. electronic payment card number) indicative of the user of the terminal device <NUM> previously transmitted to the POS device <NUM>. The digital signature may be created by, for example, combining the data representative of the electronic ticket with data indicative of the user of the terminal device <NUM> (such as the number of the electronic payment card used to pay for the ticket) and applying a hash to the combined data. The hash is then encrypted using a private key known only to the POS device <NUM>. The encrypted hash (which is the digital signature is then provided with the ticket data transmitted from the POS device <NUM> to the terminal device <NUM>). It is noted that the generation of the digital signature is carried out by the controller <NUM>.

When the user of the terminal device <NUM> then tries to gain access to a ticketed service using the electronic ticket data, the terminal device <NUM> must transmit the electronic ticket data, digital signature and user data (e.g. payment card number) to the checking device <NUM>, which performs a verification process on the digital signature. The verification process comprises, for example, hashing the received electronic ticket data and user data (using the same hashing algorithm as used by the POS device <NUM>) and decrypting the digital signature using a public key complementing the private key used by the POS device <NUM> to perform the encryption. The digital signature will be verified if the hash generated by the hashing algorithm on the ticket data and user data and the hash generated as a result of the decryption process are the same (that is, they match). Such an arrangement ensures both that the electronic ticket data is authentic (that is, has been generated by a POS device <NUM> authorised to generate electronic ticket data) and has not been tampered with. This is because the generated hashes will only match if the electronic ticket data has not been changed and if the private key (known only to authorised POS devices <NUM>) is used to encrypt the hash generated at the POS device in order to generate the digital signature. It is noted that, in the above-mentioned embodiments, the first data indicative of the user of a terminal device <NUM> (e.g. payment card number) is stored in the storage medium <NUM> of the terminal device <NUM> in advance. For example, if the first data indicative of the user of the terminal device <NUM> is an electronic payment card number of an electronic payment card held by the user of the terminal device <NUM>, then the user will have entered this information prior to initiating the transaction between the POS device <NUM> and terminal device <NUM>. According to the invention, this stored user data is then transmitted to the POS device <NUM> (in order to generate the digital signature) and checking device <NUM> (in order to check the digital signature).

An embodiment of the present technique is described in more detail with reference to <FIG>. This shows an example scenario in which an electronic train ticket is purchased and stored on the terminal device <NUM>. The electronic ticket is then checked by a checking device <NUM> and the authenticity and integrity of the electronic ticket may be confirmed based on the digital signature provided with the ticket.

<FIG> shows a first step in a process in which the user of a terminal device <NUM> purchases an electronic railway ticket at a POS device <NUM>. The POS device <NUM> comprises an NFC reader <NUM> comprising the communication interface <NUM>. The display <NUM> of the POS device <NUM> displays an image <NUM> in which information is displayed to the user so as to allow them to select an appropriate ticket. In this case, the display <NUM> is a touchscreen display and therefore also comprises the user interface <NUM>. That is, both the display and user interface together form a single element, which will be referred to as a touchscreen display. In the image <NUM>, it can be seen that the starting location <NUM> (in this case "Southampton Central") and destination location <NUM> (in this case, "London Waterloo") are displayed. The starting and destination locations will be selected by a user by typing in appropriate information using an onscreen keyboard (not shown) or by using a dropdown menu (not shown) or the like. Virtual buttons 204A and 204B allow the user to select whether a single (one way) ticket is desired (selectable by selecting the button 204A) or whether a return ticket (selectable by selecting the button 204B) is desired. In this case, the user has selected a "return" ticket by selecting the button 204B. The button 204B therefore appears in a different colour to the button 204A in order to indicate that a return ticket (rather than a single ticket) has been selected. The price <NUM> of the selected ticket is also shown on the display <NUM>. Once the user is happy with the selection of the details of the ticket, they select the confirm button <NUM>. The virtual buttons 204A, 204B and <NUM> are selected by the user touching the touchscreen display <NUM> at the position at which the desired button is displayed on the display <NUM>.

The process then proceeds to the next step, shown in <FIG>. Here, the image <NUM> shown on the display <NUM> presents a message <NUM> to the user instructing them to present a terminal device <NUM> to the card reader <NUM>. The user then brings the terminal device <NUM> into sufficient proximity to the reader <NUM> in order for data to be transmitted between the communication device <NUM> (comprised within the reader <NUM>) and the communication interface <NUM> (comprised within the terminal device <NUM>) via NFC. In response to the terminal device <NUM> being brought into sufficient proximity to the reader <NUM>, the communication interface <NUM> of the terminal device <NUM> receives an NFC signal from the reader <NUM> which instructs the controller <NUM> to open a predetermined software application for carrying mobile NFC payments. An image <NUM> is displayed on the display <NUM> of the terminal device <NUM>, the image <NUM> showing a graphical user interface (GUI) of the NFC mobile payments application (this may be referred to as a "payments "app). The GUI of the payments app shows a name <NUM> of the app and also displays a symbol <NUM> indicating that the NFC payments process is currently being completed. The NFC payments process typically takes a time of the order of a few seconds. During the NFC payments process, payment information is exchanged between the POS device <NUM> and the terminal device <NUM> in order for an electronic payment card payment for the purchased ticket to be completed. As previously mentioned, an example of such a mobile NFC payment scheme is that provided by EMV ® Contactless. The details of EMV ® Contactless are known in the art (e.g. in the publicly available EMV ® Contactless specifications mentioned above) and a detailed description of EMV ® is beyond the information necessary for the skilled person to understand the principles of the present technique. For the sake of brevity, the details of EMV ® Contactless are therefore not included in this description. In addition to the exchange of payment information, once the payment process has been completed, data representing the electronic ticket and digital signature is transmitted from the POS device <NUM> to the terminal device <NUM> via NFC. Once both the payment has been completed successfully and the electronic ticket (with digital signature) has been successfully received by the terminal device <NUM>, the process proceeds to the next step illustrated in <FIG>.

In <FIG>, a message <NUM> indicating that the transaction has been successful and the terminal device <NUM> may therefore be removed from the proximity of the EMV ® reader is shown in the image <NUM> displayed by the display <NUM> of the POS device <NUM>. Furthermore, the image <NUM> displayed on the display <NUM> of the terminal device <NUM> has changed to display a check mark <NUM> indicating that the transaction has been successful and to display a virtual button <NUM> which the user may select in order view the electronic ticket that they have just purchased (more specifically, to view an image generated on the basis of the data representative of the purchased electronic ticket). Again, in this case, the user interface <NUM> of the terminal device <NUM> is a touchscreen user interface implemented as part of the display <NUM>. The display <NUM> and user interface <NUM> of the terminal device <NUM> therefore form a single unit which may be referred to as a touchscreen display.

<FIG> shows in more detail an example of the signals transmitted via NFC between the POS device <NUM> and terminal device <NUM> during the step of <FIG>. At a first step <NUM>, the user of the terminal <NUM> is requested by the POS device <NUM> to present the terminal device <NUM> to the reader <NUM> of the POS device <NUM>. At step <NUM>, the user presents the terminal device <NUM> to the NFC reader <NUM> (that is, the user brings the terminal device <NUM> into sufficient proximity to the reader <NUM> so as to enable signals to be exchanged between the communication interface <NUM> of the terminal device and the communication interface <NUM> of the NFC reader <NUM> via NFC). Once the NFC reader <NUM> of the POS device <NUM> and terminal device <NUM> are brought into sufficiently close proximity, payment information is exchanged between the POS device and terminal device at step <NUM>. The payment information exchanged comprises all information which must be exchanged between the POS device <NUM> and the terminal device <NUM> in order to enable an electronic payment card payment (using the details of an electronic payment card held by the user of the terminal device <NUM> which are stored as data in the storage medium <NUM> of the terminal device <NUM>) to be made to the operator of the POS device <NUM>. The payment information exchanged therefore includes, for example, data indicative of the value of the payment (in this case, £<NUM>), the details of the electronic payment card stored in the storage medium <NUM> of the terminal device <NUM> and any other data so as to enable the electronic card payment to be made using an electronic payments network including an acquirer, an electronic payment card scheme (such as a MasterCard ® electronic payment card scheme) and an issuer of the payment card (such as terminal device user's bank). The exact details of the content of the electronic messages exchanged between the POS device <NUM> and the terminal device <NUM> are defined, for example, in the EMV ® Contactless specifications described above. For the sake of brevity, this information is not repeated here.

At step <NUM>, a payment approval message is transmitted from the terminal device <NUM> to the POS device <NUM>. Such a payment approval message <NUM> is the final instance of payment information that must be exchanged between the POS device <NUM> and terminal device <NUM> in order for the electronic card payment to be completed successfully. When the electronic payment is completed using EMV ® Contactless, the payment approval message step <NUM> comprises a transaction certificate (TC) application cryptogram transmitted from the terminal device <NUM> to the POS device <NUM> in response to a "generate application cryptogram" (Gen AC) command transmitted from the POS device <NUM> to the terminal device <NUM>. The transaction certificate approving the electronic payment card payment is only transmitted from the terminal device <NUM> to the POS device <NUM> in the case that sufficient card holder verification is completed at the terminal device <NUM>. Such card holder verification may include, for example, the user entering a passcode into the terminal device <NUM>, or may utilise biometric verification such as fingerprint recognition (in which case, the terminal device <NUM> comprises a fingerprint scanner, not shown) or facial recognition (in which case, the terminal device <NUM> comprises a camera and suitable software and/or hardware for recognising the facial features of the user of the terminal device <NUM>, not shown). In embodiments, when online approval of the payment is required by the issuer of the electronic payment card used by the terminal device <NUM> for instructing the payment, the payment approval message transmitted at step <NUM> is transmitted only in response to a second Gen AC command transmitted from the POS device <NUM> to the terminal device <NUM> in response to approval of the transaction of the issuer of the electronic payment card.

Following the receipt of the payment approval message, the data representative of the electronic ticket is transmitted from the POS device <NUM> to the terminal device <NUM> at step <NUM>. As previously mentioned, the ticket data is provided along with an electronic signature generated on the basis of the electronic payment card number (e.g. PAN number) of the electronic payment card used during the payment procedure of step <NUM> and the ticket data itself. The POS device <NUM> knows the electronic payment card number of the electronic payment card used for payment because this is received from the terminal device <NUM> during the exchange of payment information at step <NUM>. The digital signature provided with the ticket data can therefore only be verified if the ticket data and data indicative of the user of the terminal device <NUM> (in this case, the electronic payment card number) remain unchanged. This prevents a user of the terminal device <NUM> from editing the ticket data in order to allow unauthorised access to a ticketed service for which they have not purchased a ticket via official means. Furthermore, a user of a first terminal device cannot transfer legitimately obtained ticket data to another terminal device used by another user, since the user of the other terminal device must use a different electronic payment card for NFC mobile payments and therefore the combination of the ticket data and electronic payment card number used for generation of the digital signature will be different when the ticket data is transmitted from one terminal device to another (thus resulting in the digital signature of the ticket data not being verifiable when read from a terminal device other than the terminal device to which the ticket data was originally issued). In addition, the digital signature ensures the authenticity of the ticket data (that is, that the ticket data was created by a POS device <NUM> of an official ticket vender with access to the private key for encrypting the hash of the combination of the ticket data and electronic payment card number in order to generate the digital signature, as previously discussed).

In an embodiment, the ticket data and digital signature are stored in the storage medium <NUM> of the terminal device <NUM> as part of a predetermined record. The ticket data and digital signature are comprised within an update record command transmitted from the POS device <NUM> to the terminal device <NUM> during step <NUM> shown in <FIG>. According to Contactless EMV ®, various types of data necessary for completing a mobile payment transaction using a terminal device <NUM> are stored within records stored in the storage medium <NUM>. Data stored within a particular record may be changed via an update record command transmitted from an EMV ® Contactless reader to the terminal device. By storing the ticket data and digital signature as part of a predetermined one of these records, it is possible for electronic tickets be transmitted to and stored by terminal devices <NUM> using existing EMV ® Contactless readers and existing EMV ® architecture comprised within terminal devices <NUM> such as smartphones and tablet computers. The present technique therefore provides improved functionality to existing POS and terminal devices by allowing electronic tickets to be quickly and conveniently acquired by and stored within existing terminal devices whilst helping to ensure the authenticity and integrity of those electronic tickets.

When the ticket data and digital signature are transmitted to the terminal device <NUM> as part of an update record command, it is noted that existing EMV ® architecture may require a message authentication code (MAC) to be included in the update record command. The MAC is for ensuring the authenticity and integrity of the content of the update record command. The use of MACs is known in the art and will therefore not be discussed in detail. However, with the present technique, as previously discussed, the update record command already comprises the digital signature of the ticket data. The authenticity and integrity of the ticket data can therefore already be confirmed based on verification of the digital signature. The inclusion of a MAC in the update record command used for transmitting the ticket data and digital signature from the POS device <NUM> to the terminal device <NUM> is therefore not required. The MAC may therefore be omitted from the update record command used to transmit the ticket data and digital signature. This reduces the amount of data which must be transmitted and processed when the update record command is transmitted from the POS device <NUM> to the terminal device <NUM>. Alternatively, if the EMV ® architecture of the POS device <NUM> and/or terminal device <NUM> requires data to be included in a portion of the structure of the update record command which usually comprises the MAC, then any combination of bits may be included within this portion of the update record command (in place of a MAC). The authenticity and integrity of the ticket data comprised within the update record command may therefore still be confirmed by verification of the digital signature. At the same time, the data structure of the update record command is maintained, thus ensuring continued compatibility of the present technique with EMV ® architectures which require update record commands to include data in the potion of the update record command structure in which a MAC is usually comprised.

It will be appreciated that, even though the ticket data may be authenticated and the integrity of the ticket data confirmed based on a verification of the digital signature, it may still nonetheless be beneficial to include a MAC in the update record command comprising the ticket data and digital signature. In particular, a MAC may be different for each update record command transmitted (e.g. by using a different session key shared between the POS device <NUM> and terminal device <NUM> for each update record command), meaning that old ticket data comprising an old MAC cannot be rewritten in the storage medium <NUM> once the MAC has changed (because the old MAC included in the update record command will not verify). This provides a convenient method for ensuring that old electronic ticket data cannot be reused. Furthermore, this is achieved using a type of data (i.e. the MAC) which already exists in update record commands transmitted using existing EMV ® architecture.

Instead of or in addition to including a MAC in the update record command comprising the ticket data and digital signature, the ticket data itself may comprise information indicative of the temporal validity of the ticket data. For example, the ticket data may comprise an expiry date and/or time of the ticket data, after which the ticket data will be deemed valid and will not be accepted by the checking device <NUM>. Due to the digital signature verification, it will not be possible for a user to change the validity data of the ticket data (since to do so would result in the ticket data being changed which would, in turn, result in it not being possible to successfully verify the digital signature).

<FIG> shows the image <NUM> after the virtual button <NUM> (shown in <FIG>) is selected by the user of the terminal device <NUM>. The image <NUM> shows a GUI of a digital wallet software application which shows a plurality of images 401A-401C each representative of a respective electronic ticket purchased by the user in accordance with the previously described embodiments. The railway ticket purchased according to the embodiment described with respect to <FIG> and <FIG> is shown at the front of the plurality of images, thus allowing the user of the terminal device <NUM> to see all of the details of the railway ticket. Each of the images 401A-401C provides visual information in order to allow the user to determine details of the electronic ticket to which that image relates. The image relating to each saved instance of electronic content data comprises visual information which allows the user to distinguish each ticket stored in the storage medium <NUM> and to determine any other relevant information such as the validity of that ticket. For example, as shown in <FIG>, the electronic railway ticket purchased according to the embodiment discussed with reference to <FIG> and <FIG> indicates that the electronic ticket is a train tciket, that the ticket is a "return" ticket rather than a "single" (that is, one way) ticket, the start and end locations for which the electronic ticket is valid and the temporal validity of the electronic ticket (in this case, the ticket is valid for the current day only, and therefore the image 401A indicates that the ticket is valid "today"). It will be appreciated that, in addition to electronic tickets, images relating to other types of electronic content purchased using the principles of the present technique may be displayed using a GUI similar to that shown in <FIG>.

In the arrangement of <FIG>, the user is able to conveniently store a plurality of electronic tickets (e.g. railway tickets, bus tickets, cinema tickets, theatre tickets, airline boarding passes and the like) in the storage medium <NUM> of the terminal device <NUM> and to review the digital content items which are stored in the storage medium <NUM> via the GUI of a digital wallet software application which displays an image 401A-401C representative of each electronic ticket stored in the storage medium <NUM>. In the embodiment of <FIG>, each of the images 401A-401C are shown to be virtually stacked on top of each other so that a currently selected image (in this case, image 401A) appears at the top of the stack. In this embodiment, the user interface <NUM> is a touch sensitive interface comprised as part of the display <NUM> (the display <NUM> is therefore a touch screen display). When the user touches the surface of the display <NUM> with their finger and moves their finger up or down in the direction of the arrows <NUM>, the image shown at the top of the image stack is changed so as to enable the user to view the details associated with different ones of the electronic tickets stored in the storage medium <NUM>. For example, if the user touches the surface of the display and moves their finger in the direction of the downwards facing arrow, the image displayed at the top of the stack will change from the image 401A to the image 401B. If the user then moves their finger in the direction of the downwards facing arrow by a further amount, then the image shown at the top of the stack will change from the image 401B to the image 401C. Alternatively, instead of moving their finger down, if the user were to move their finger in the direction of the upwards facing arrow, then the image at the top of the stack would change from the image 401A to the image 401C. If the user were to then move their finger in the direction of the upwards facing arrow by a further amount, then the image at the top of the stack would change from the image 401C to the image 401B. The user is thus able to easily select the details of a particular electronic ticket to view. It will be appreciated that the arrangement of <FIG> is only an example, and that any other suitable method of displaying data associated with different respective electronic tickets (or, more generally, different respective items of electronic content) stored in the storage medium <NUM> of the terminal device <NUM> may be used.

<FIG> shows an example arrangement in which the authenticity, integrity and validity of an electronic ticket stored in the storage medium <NUM> of the terminal device <NUM> is checked by a checking device <NUM>.

It can be seen that the terminal device <NUM> and the image <NUM> displayed on the display <NUM> of the terminal device <NUM> (including images representative of different respective electronic tickets) is the same as described with reference to <FIG>. <FIG>, in addition, shows a ticket checker <NUM> comprising a display <NUM> which displays an image <NUM>. In this example, the checking device <NUM> is also a terminal device such as a smartphone or tablet computer in which the functionality of the device is implemented by a software application installed on the terminal device.

As previously described, the checking device <NUM> is able to determine whether or not an electronic ticket (or, more generally, electronic content) stored on the terminal device <NUM> is authentic (that is, genuine) and has maintained its integrity (that is, has not been altered) by verifying the digital signature provided with the electronic ticket. As previously mentioned, the digital signature is checked by the checking device receiving the ticket data and data indicative of the user of the terminal device <NUM> (such as the payment card number of an electronic payment card used by the user of a terminal device <NUM> to purchase the electronic ticket), hashing the combination of the ticket data and user data using a predetermined hashing algorithm and comparing the hash generated from the predetermined hashing algorithm with a hash generated by decrypting the digital signature provided with the ticket data using a public key which complements the private key used for encrypting the hash of the ticket data and user data by the POS device <NUM> in order to generate the digital signature.

As shown in <FIG>, there are two possible outcomes resulting from the operation of a checking device <NUM>.

In a first outcome indicated by arrow <NUM>, the electronic ticket is deemed to be genuine and unaltered (due to successful verification of the digital signature) and valid (due to the ticket being valid for the service with which the checking device <NUM> is associated and being temporally valid). In this case, an image <NUM> shown on the display <NUM> of the ticket checker <NUM> shows a symbol <NUM> (in this case, a check mark) indicating that the electronic ticket is genuine, unaltered and valid.

On the other hand, a second outcome, indicated by arrow <NUM>, occurs when the electronic ticket is not genuine, has been altered and/or is not valid. The electronic ticket is determined to not be genuine or to have been altered when the digital signature fails to verify (that is, when the hash of the combination of the ticket data and user data does not match the hash generated from the decryption of the digital signature). The ticket will not be valid if it is not valid for the service associated with the checking device <NUM> (e.g. if the user of the terminal device <NUM> travels on a different train to that to which they are entitled according to the terms and conditions of their electronic train ticket) or if the ticket is not temporally valid (that is, it has expired or is not valid for use until a certain point in the future). In this case, the image <NUM> displayed on the display <NUM> of the checking device <NUM> comprises a symbol <NUM> (in this case, a cross mark) indicating that the electronic ticket data cannot be accepted. In addition, a message <NUM> is displayed as part of the image <NUM> to indicate whether the ticket has been rejected because the digital signature failed to verify (as is the case here) or because the ticket is not valid. In this case, the digital signature has failed to verify (indicating that the ticket is not genuine and/or has been altered) and therefore the ticket is indicated by the message <NUM> as not being verified. However, it will be appreciated that, in another scenario, the ticket may be genuine and unaltered (thus allowing the digital signature to be verified) but may not be valid (for example, the ticket may have expired, may not yet be temporally valid or may not be appropriate for the service associated with the checking device <NUM>). In this case, the message <NUM> would indicate that the ticket is not valid. In an embodiment, the verification of the ticket is carried out first. The validity of the ticket is then checked only upon successful verification of the ticket, since the validity of a ticket is irrelevant if it cannot be verified. This reduces the amount of processing required in checking tickets which cannot be verified.

An example of the scenario shown in <FIG> may occur, for example, for railway tickets. In this case, if electronic ticket data has been genuinely generated by a POS device <NUM> associated with the railway operator and has not been altered (e.g. by the user of the terminal device <NUM> attempting to change the ticket data), then the digital signature provided with the electronic ticket data will be verified. Furthermore, if the electronic ticket is appropriate for the train being used by the user (to use the example of the railway ticket shown in <FIG>, <FIG> and <FIG>, if the user is on a train between Southampton central and London Waterloo and is travelling on the same day on which the ticket has been purchased), then the scenario indicated by arrow <NUM> will occur. On the other hand, if the ticket is not genuine (for example, if the ticket data has simply been copied from another device associated with a different user), has been altered (for example, if the user has amended the ticket data to change the destination or validity) or is not valid (for example, if the user is travelling on a train on a route other than a route between Southampton Central and London Waterloo or if the user is travelling on a day after the day on which the ticket was purchased), then the scenario indicated by arrow <NUM> will occur. As previously mentioned, the ticket data, user data (e.g. payment card number) and digital signature may be transmitted from the communication interface <NUM> of the terminal device <NUM> to the communication interface <NUM> of the checking device <NUM> via any suitable data transmission method, including via electromagnetic induction (as enabled by NFC technology, for example) or via a radio signal (as enabled by Bluetooth or Wi-Fi technology, for example).

Thus, in embodiments of the present technique, electronic ticket data (or data indicative of other electronic content whose authenticity must be checked) and data indicative of a user (that is, data such as an electronic payment card number of an electronic payment card held by the user which may be used to identify the user) is used by the POS device <NUM> to generate a digital signature which is then provided with the electronic ticket data to the terminal device <NUM> for storage in the storage medium <NUM> of the terminal device <NUM>. The user data (such as the electronic payment card number) is transmitted to the POS device <NUM> from the terminal device <NUM> in order to allow the digital signature to be generated. When the electronic ticket data is later checked by a checking device <NUM>, the ticket data and user data (such as the electronic payment card number) used to generate the digital signature is transmitted to the checking device <NUM> together with the digital signature. This allows the checking device <NUM> to verify the digital signature in order to confirm the authenticity and integrity of the electronic ticket data. The checking device <NUM> may then also check data indicative of the validity of the ticket data (such as whether the ticket is appropriate for the service with which the checking device <NUM> is associated and whether the electronic ticket data is temporally valid) in order to determine whether or not to accept the ticket.

In the embodiment of <FIG>, in the scenario <NUM> in which the electronic ticket is accepted (a ticket being accepted when it is both verified and valid), the controller <NUM> may control the data output circuitry <NUM> to output a signal to another device (such as an automated ticket barrier, not shown) indicating that the electronic ticket has been accepted and therefore that a first predetermined process (in addition to or instead of the display <NUM> being controlled to indicate that the electronic ticket has been accepted) should be performed. For example, in the case that such a further device is an electronic ticket barrier (in which case, the checking device <NUM> may be comprised as part of the electronic ticket barrier, for example), then the signal output by the data output circuitry <NUM> may be a signal indicating to the automated ticket barrier to allow a user through the automated ticket barrier (automated ticket barriers, not shown, typically comprise electronically controlled gates which serve to prevent a user from entering a predetermined location (such as a railway platform or event premises) unless they have a valid ticket). On the other hand, in the scenario indicated by arrow <NUM>, the data output circuitry <NUM> may be controlled to output a signal to another device indicating that the electronic ticket has been rejected (a rejected ticket being not verified and/or not valid) and therefore that a second predetermined process (in addition to or instead of the display <NUM> being controlled to indicate that the electronic ticket has been rejected) should be performed. For example, a signal may be output to an automated ticket barrier indicating that the user of the terminal device <NUM> should not be allowed access. In this case, the electronically control gates of the automated ticket barrier will remain closed, thus preventing a user without a genuine, unaltered and/or valid electronic ticket access to the ticketed service. It is noted that, in embodiments, the term "altered" should be understood to mean any alteration of the ticket data, whether this alteration is intentional (e.g. caused by a user attempting to change details of the electronic ticket) or accidental (e.g. caused by corruption of the ticket data during transmission between devices). The verification process of the present technique ensures that any alteration to the ticket data, whether intentional or accidental, may be detected (because the digital signature provided with the ticket will fail to verify).

It will be appreciated that, although the above-described embodiments relate to an electronic ticket (in particular, an electronic railway ticket), the present technique may be applied to any data which is stored in a storage medium <NUM> of a terminal device <NUM> and whose authenticity and integrity must be checked. For example, other types of electronic ticket data (for example, cinema tickets, theatre tickets or music event tickets) may be verified according to the present technique, as may other types of electronic content such as media content (for example, image, video, audio, game or textual files). More generally, it will be appreciated that the present technique may be used for authenticating any type of electronic content obtained by a terminal device <NUM> from a POS device <NUM> via electromagnetically inductive interaction between the terminal device <NUM> and POS device <NUM>.

It is noted that an electronic ticket with a digital signature which is successfully verified may be referred to as a verified electronic ticket. A verified electronic ticket is known to be both authentic (that is, genuine) and to have maintained its integrity (that is, the data representing the electronic content has not been altered). An electronic ticket that is not verified is either not authentic or has comprised integrity. In addition, an electronic ticket which, based on the data representative of the ticket (including the ticket's temporal validity and information indicative of the ticketed service for which the ticket is valid), is valid for a ticketed service that the user of the terminal device <NUM> attempts to access, may be referred to as a valid electronic ticket. On the other hand, an electronic ticket which, based on the data representative of the ticket (including the ticket's temporal validity and information indicative of the ticketed service for which the ticket is valid), is not valid for a ticketed service that the user of the terminal device <NUM> attempts to access, may be referred to as an invalid electronic ticket. A ticket will be accepted by the checking device <NUM> when both verified and valid (in which case the controller <NUM> of the checking device <NUM> outputs a signal to the display <NUM> and/or data output circuitry <NUM> indicating that the ticket is both verified and valid). This is exemplified by scenario <NUM> of <FIG>. On the other hand, a ticket will not be accepted by the checking device <NUM> if it is not verified and/or not valid (in which case the controller <NUM> of the checking device <NUM> outputs a signal to the display <NUM> and/or data output circuitry <NUM> indicating that the ticket is not verified and/or not valid). This is exemplified by scenario <NUM> in <FIG>.

<FIG> shows a method of controlling the terminal device <NUM> according to an embodiment. This method is implemented by the controller <NUM>, for example. The method starts at step <NUM>. At step <NUM>, when the terminal device <NUM> is brought into proximity to the POS device <NUM>, the communication interface <NUM> is controlled to transmit first data indicative of a user of the terminal device <NUM> (e.g. an electronic payment card number) to the POS device <NUM>. At step <NUM>, the communication interface <NUM> is controlled to transmit second data to or receive second data from the POS device <NUM>, the transmission or reception of the second data occurring in response to the completion of a predetermined data processing event (e.g. completion of an electronic payment card payment). At step <NUM>, the communication interface <NUM> is controlled to receive third data (e.g. an electronic ticket) from the POS device <NUM>, the third data being received in response to the completion of the predetermined data processing event and being digitally signed by the POS device <NUM>, wherein the digital signature of the third data is generated using the first data and the third data. At step <NUM>, the third data is stored in the storage medium <NUM>. The method then ends at step <NUM>.

<FIG> shows a method of controlling the POS device <NUM> according to an embodiment. This method is implemented by the controller <NUM>, for example. The method starts at step <NUM>. At step <NUM>, the communication interface <NUM> is controlled to receive first data indicative of a user of the terminal device <NUM> (e.g. an electronic payment card number) from the terminal device <NUM>. At step <NUM>, the communication interface <NUM> is controlled to transmit second data to or receive second data from the terminal device <NUM>, the transmission or reception of the second data occurring in response to the completion of a predetermined data processing event (e.g. completion of an electronic payment card payment). At step <NUM>, in response to the completion of the predetermined data processing event, third data (e.g. an electronic ticket) is generated. At step <NUM>, the third data is digitally signed using the first data and third data. At step <NUM>, the communication interface <NUM> is controlled to transmit the digitally signed third data to the terminal device <NUM>. The method then ends at step <NUM>.

<FIG> shows a method of controlling the checking device <NUM> according to an embodiment. This method is implemented by the controller <NUM>, for example. The method starts at step <NUM>. At step <NUM>, the communication interface <NUM> is controlled to receive first data from the terminal device <NUM>, the first data (e.g. an electronic payment card number) being indicative of a user of the terminal device <NUM>, and to receive second data (e.g. an electronic ticket) from the terminal device, the second data being previously received by the terminal device <NUM> in response to the completion of a predetermined data processing event (e.g. completion of an electronic payment card payment). The second data is digitally signed using the first data and second data. At step <NUM>, a verification process of the digital signature of the second data is performed. At step <NUM>, it is determined whether the digital signature was successfully verified. In response to a successful verification of the digital signature of the second data, the process proceeds to step <NUM> in which, based on information indicative of a validity of the second data comprised within the second data, a validity checking process is carried out on the second data. At step <NUM>, it is determined whether the second data was found to be valid. In response to determining that the second data is valid, the process proceeds to step <NUM>, in which a signal indicating that the second data is accepted (that is, both verified and valid) is output (e.g. to the display <NUM> and/or data output circuitry <NUM> for a signal indicating that the second data is acceptable to be output to an external device). The process then ends at step <NUM>. On the other hand, in response to determining that the second data is not valid, the process proceeds to step <NUM> in which a signal indicating that the second data is not valid is output (e.g. to the display <NUM> and/or to the data output circuitry <NUM> so as to allow a signal indicating that the second data is not valid to be output to an external device). The process then ends at step <NUM>. Alternatively, in response to an unsuccessful verification of the digital signature of the second data at step <NUM>, the process proceeds to step <NUM>, in which a signal indicating that the digital signature of the second data has not been verified is output (e.g. to the display <NUM> and/or to the data output circuitry <NUM> so as to allow a signal indicating that the second data has not been verified to be output to an external device). The process then ends at step <NUM>.

Claim 1:
A first data processing apparatus (<NUM>) comprising:
communication circuitry (<NUM>) configured to transmit data to or receive data from a second data processing apparatus (<NUM>) using electromagnetic induction when the first data processing apparatus is brought into proximity to the second data processing apparatus (<NUM>);
a storage medium (<NUM>); and
processing circuitry (<NUM>) configured:
to control the communication circuitry to transmit first data indicative of a user of the first data processing apparatus (<NUM>) to the second data processing apparatus (<NUM>), wherein the first data is an electronic payment card number indicative of an electronic payment card of the user of the first data processing apparatus (<NUM>);
to control the communication circuitry to transmit second data to or receive second data from the second data processing apparatus (<NUM>), the transmission or reception of the second data occurring in response to the completion of a predetermined data processing event, wherein the predetermined data processing event is an electronic payment card payment made by the user of the first data processing apparatus (<NUM>) to a user of the second data processing apparatus (<NUM>) using the payment card number, wherein the payment is carried out between the first and second data processing apparatuses (<NUM>, <NUM>) for the purpose of obtaining an electronic ticket, and wherein the second data comprises a payment approval message transmitted from the first data processing apparatus (<NUM>) to the second data processing apparatus (<NUM>);
to control the communication circuitry to receive third data from the second data processing apparatus (<NUM>), the third data being received in response to the completion of the predetermined data processing event and following receipt of the payment approval message by the second data processing apparatus (<NUM>), and the third data comprising electronic ticket data and a digital signature generated by the second data processing apparatus (<NUM>), wherein the digital signature of the third data is generated using the first data and the electronic ticket data; and
to store the received third data in the storage medium for subsequent transmission to a third data processing apparatus (<NUM>) for use in performing a verification process on the digital signature;
wherein the received third data is comprised within a command to store the third data in the storage medium as part of a predetermined record.