EP1439498A1

EP1439498A1 - Electronic ticket, device for issuing electronic tickets, and devices for using and performing operations on electronic tickets

Info

Publication number: EP1439498A1
Application number: EP03001027A
Authority: EP
Inventors: Carmen Santa Cruz Roldan
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2003-01-17
Filing date: 2003-01-17
Publication date: 2004-07-21

Abstract

A device (105, 106) for requesting the use of an electronic ticket (300) is adapted to transmit via broadcasting means (801) or point to point sending means (804) a product tag (721) or other identifier describing at least one ticket type supported by the device. The device (105, 106) may further include generation means (808) for generating a request (M601) for using an electronic ticket (300), the request (M601) including a refresh value (NONCE'') for a second identifier (704) of said electronic ticket (300). A mobile device (102) comprises receiving means (263) adapted to receive a product tag (721) or other identifier describing ticket types especially available in the neighborhood of the service access point, the product tag (721) being broadcasted by a device (105, 106) requesting the use of an electronic ticket, especially an inspection system (106) or a ticket printer (105).

Description

Field of the invention

The invention relates generally to electronic tickets or documents, and, more specifically, to generating, transferring, and presenting such tickets or documents.

Background of the invention

Digital or electronic tickets have been under a growing interest among the general public. Therefore, various players in the industry have designed different approaches which are to enable a flexible and fast usage of tickets without any compromising of the security.
Because of the obvious advantages obtained by using a standardised methodology, the development work has lead to the establishment of several standardisation bodies. An example of such a standardisation body is the Mobile electronic Transactions MeT. The MeT concentrates on various aspects relating to electronic transactions and currently (January 7, 2003) has a website www.mobiletransaction.org.
The technology used for the administration and usage of tickets needs to be defined in order for electronic tickets to reach a commercial success. The MeT has so far published a Discussion Document MeT Ticketing Framework, Version 1.0 (February 21, 2001) which at the moment may (January 7, 2003) be downloaded from
http://www.mobiletransaction.org/pdf/R11/MeT-Ticketing-Framework-R11.pdf.
Several other documents, such as Coupon ticketing, Version B (November 20, 2001), at the time of writing available at http://www.mobiletransaction.org/pdf/R11/MeT-Coupon-Ticketing-R11.pdf, and MeT Ticketing Wallet Server, Version B, (July 09, 2001), at the time of writing available at http://www.mobiletransaction.org/pdf/R11/MeT-Ticketing-Wallet-Server-R11.pdf), have also been presented.
Figure 1A illustrates a system in which electronic tickets may be used. A ticket is issued by a ticket issuing system 101 which is connected to a communications network, such as the Internet 100B usually via its front end 1011. Most ticket issuing systems 101 include also a back end 1012 which performs the ticketing and stores a copy of issued tickets to a data storage 1013. When a ticket has been generated in the ticket issuing system 101, it is usually sent to a personal computer 104 via the Internet 100B, or to some mobile device 102 or 103 which may be connected to the Internet 100B either directly through a PC or via a mobile network 100A, such as a GSM, GPRS, or UMTS network.
Tickets may be ordered directly from the personal computer 104, or from the mobile devices 102, 103. Some ticket models are push-type, wherein the ticket issuing system pushes the ticket to the device of the end-user, whereas some ticket models are pull-type which involve a request from the end-user device before the ticket is generated. Further, a ticket may be ordered by a first mobile device 102 and used by the user of a second mobile device 103.
Further, usually the system contains an inspection system 106 which is intented to check the tickets. After checking the tickets a person presenting the ticket is allowed a service, such as entering an airplane or through a gate. Because electronic tickets can be used within a communications network, such as the Internet 100B, also for paying services available in, from, or via the network, the nature of the inspection system 106 is not limited to these but may involve also other tasks.
In some cases the system also includes a ticket printer 105. This kind of approach has proved to be particularly valuable when the service provider in question is willing to enable the use of traditional tickets as well. The conventional paper-form tickets are fast to check by a human inspector. Thus it may be beneficiary to print a paper ticket of an electronic ticket with which the user is then allowed the service. Therefore the ticket printer 105 which may also be connected to the Internet 100B obtains instructions from the ticket issuing system 101 relating to what kinds of tickets to accept. Ticket printer 105 may include similar functionalities to the inspection system 106.
Until now, in order to use a digital ticket the user need to brose the ticket database to find the adequate ticket to be presented to the inspector. If the user has several tickets stored and presents a wrong ticket which is then marked as used, the system need to have a recovery mechanism for such a ticket. However, this is extremely difficult to implement.

Summary of the invention

This and other objectives of the invention can be achieved with a method and a system according to any one of the independent patent claims.
A device for requesting the use of an electronic ticket is adapted to transmit via broadcasting means or point to point sending means a product tag or other identifier describing at least one ticket type supported by the device. This speeds up the using of the ticket which is very crucial especially when the number of ticket users is very high.
According to one aspect of the present invention, a device for requesting the use of an electronic ticket may further include generation means for generating a request for using an electronic ticket, the request including a refresh value for a second identifier of said electronic ticket. The device can further include point to point sending means for transmitting said request to a mobile device. Further, in such a manner the ticket presentation messange exchange can be more automatised, and privacy of communications can be ensured.
Further, said generation means and/or point to point sending means can be responsive to proximity discrimination means so that a mobile device is to be detected prior to generating and/or sending the request to the mobile device. In this way, the air interface can be saved because in response to the proximity detection, the sending of request in vain can be avoided, similarly the possible generation of new identifiers can be avoided.
According to another aspect of the present invention, the proximity range (ΔR₁, ΔR₂) of the broadcasting means can be asymmetric. The asymmetry has been obtained by using shielding means. This helps in using multiple devices for requesting the use of an electronic ticket close to each other, say, when the space available is limited and density of users willing to use different services is relatively high, like at a football stadium or at an airport.
A mobile device comprises: receiving means adapted to receive a product tag or other identifier describing ticket types especially available in the neighborhood of the service access point, the product tag being broadcasted by a device requesting the use of an electronic ticket, especially an inspection system or a ticket printer. In this manner, the process of using electronic tickets can be further automatised and the system can be made more user-friendlier. It also enables a good proportion of code reuse, because similar programming blocks can be used for ticket transfer between a ticket issuing system and the mobile device, or between different mobile devices.
The mobile device or, especially a ticket application included therein, can further be adapted to search an electronic ticket corresponding to said product tag among tickets to access a given service. In this manner the system can be made more user-friendlier because the user can ge given the freedom of choice while still retaining the certainty that only valid tickets are going to be presented and so saving the difficult implementation of recovery mechanisms.
A ticket issuing system or a device for issuing an electronic ticket, includes generation means adapted to generate an electronic ticket including a product tag. In this manner, the process of using electronic tickets can be further automatised and the implementation of costly and technically very difficult recovery mechanisms in the ticket inspection system can be avoided.

Brief description of the drawings

In the following, the invention and its preferred embodiments are described more closely referring to the examples shown in Figures 1B to 7 in the appended drawings, wherein:

Figure 1A: illustrates a system for providing and using electronic tickets;
Figure 1B: is a schematic block diagram of inspection system 106;
Figure 1C: shows a user with a mobile device 102 approaching the inspection system 106;
Figure 2A: is a block diagram of a mobile device 102 adapted to carry out the present invention;
Figure 2B: shows contents of registry 722 before a registration;
Figure 2C: shows contents of a registry 722 after a registration;
Figures 3A, 3B, and 3C: illustrate a preferable format for the electronic ticket 300;
Figure 4: shows a preferred embodiment of a process for issuing a ticket;
Figure 5: shows a preferred embodiment of a process for validating a ticket;
Figures 6A and 6B: show a preferred embodiment for a process for using a ticket; and
Figure 7: shows a preferred embodiment for process of splitting and transferring a ticket.

Like reference signs refer to corresponding parts and elements throughout Figures 1-7.

Detailed description of the invention

Figure 1B is a block diagram of an inspection system 106. Its operation is described below in more detail together with some further aspects of the present invention. The inspection system 106 includes transport means 805, proximity detection means 802, proximity discrimination means 803, storage 807, and ticketing means 814.
As the reader may know, proximity detection means 802 are usually based on optical or magnetic sensors that detect which device is the closest in any given moment. As an alternative, proximity discrimination means 803 can correspond to detecting a new BLUETOOTH address, or comparing an addresses detected with at least one predetermined address, for example.
The transport means 805 include point to point sending means 804 for sending user-specific messages, broadcasting means 801, and receiving means 806. The ticketing means 814 include generation means 808, comparison means 809, verification means 810, and parsing means 811; the main purpose of the ticketing means 814 is to broadcast product tag 721 supported by the inspection system 106, to generate user-specific ticket presentation requests, and to verify the integrity and origin of the tickets presented by any mobile device 102, 103.
Broadcasting means 801 act in the proximity of the inspection system 106, and transport messages including the value of a product tag 721 of a given ticket class. The product tag 721, as will be explained below, identifies the required ticket to be presented to the inspection system 106 in order to access a given service.
Receiving means 806 are used to receive ticket elements related to the ticket use.
Generation means 808 are used to generate new nonces 704. Parsing means 811 are used for extracting a nonce 704 of the private part 300PR in ticket data 706. Comparison means 809 are used to compare the nonce 704 of the ticket with the nonces stored in the storage 807. Verification means 810 are used to verify that the ticket data object 303 has not been tampered with, and for comparing the trusted agent signature 709 with the ticket data 706.
Some purposes of the proximity detection means 802 are: i) to discover the users that are within a given distance range of the inspection system 106, ii) to discriminate among such users either by detecting the closest one, or on the basis of their individual device addresses, and iii) that only users sufficiently close to the inspection system 106 are presented with an individual ticket presentation request REQ4 containing a product tag 721 and a unique nonce 704. The ticket presentation request REQ4 is presented to the mobile device 102 by using any suitable point-to-point sending means 804 available.
Storage 807 is used for employed to storing the generated nonce values that later are compared with those transported on an electronic ticket 300.
Figure 1C shows a user with a mobile device 102 approaching the inspection system 106. The proximity range ΔR₁ of the proximity detection means 802 corresponding to current technology is about 10 m if the proximity detection means include a transmitter with 4 W power and the mobile device 102 includes a passive component, such as an RF tag. Of course any other proximity detection method can be used instead or in combination with an RF tag. The proximity range may be adapted to show non-uniform directional characteristics, say that ΔR₁ << ΔR₂ in order to ensure proper functioning, for example in the vicinity of a gate at the airport. In order to obtain these non-uniform directional characteristics, proper shielding means 199 can be used. Such shielding means 199 can be simply opaque plastics or metal (aluminum, steel, lead), depending on the broadcasting means 801. If the broadcasting means 801 include communication by using visible or infra-red light, then shielding can be obtained by selecting a proper distribution of opaque and transparent material around the broadcasting means 801. For RF signals, however, a heavier shielding is necessary.
The inspection system 106 broadcasts product tag 721 which is then detected by the mobile device 102. This is discussed in more detail below together with Figures 6A and 6B.
Figure 2A is a block diagram of a mobile device 102. In principle, the mobile device 102 can be any portable device, such as a Personal Digital Assistant PDA, a laptop computer, a Portable Digital Wallet, or a Personal Trusted Device PTD. In the following it is for simplicity assumed that the mobile device 102 is a mobile terminal, such as a mobile phone, having capabilities to be in connection via remote transportation means such as the mobile network 100A and the Internet 100B, as well as via local transportation means such as BLUETOOTH and IrDA, with the ticket issuing system 101 and with the ticket inspection system 106.
The mobile device 102 includes input/output I/O means 260 which include receiving means 263, sending means 262, and a display 261. The receiving means 263 include means with which the mobile device 102 can receive any data from a mobile network 100A, from another mobile device 103, from the user of the mobile device 102, from inspection system 106, ticket issuing system 101, and so on. The receiving means 263 can comprise a keyboard, wireless communication means, touch screen, joystick, speech recognition system adapted to work with a microphone, and so on.
Further, the mobile device 102 may also include a loudspeaker 264 and a Radio Frequency RF tag 265. The RF tag is usually a contactless smart card. On the market there are also some models known as hybrid smart cards comprising both an electrical interface, preferably to the SIM card, and an RF interface.
The mobile device 102 includes also security means 250. The security means 250 include simple ticket security means 224 for providing simple ticket security services, such as simple copy protection, preferably by (a) own ticket application 200 implemetantion and/or (b) by the usage of weak symmetric encryption by any given algorithm.
The security means 250 can further include means for providing high-level security services to the mobile device. These means can include a specific tamper-proof (or tamper-resistant) security component called security element security element 252 corresponding to secure storing means.
The security element 252 is preferably located inside the mobile device 102, and either integrated into it, or provided as a detachable part.
The high-level security services provided by the security element 252 to the mobile device 102, includes means for generation of random numbers, strong symmetric cryptography, and Public Key Infrastructure PKI cryptography. Regarding PKI, the security element 252 can also provide other services related to it, such as handling of certificates (e.g root certificate storage, certificate path discovering and validation), storing of key pairs, digitally signing documents, and authentising of digital signatures. When the mobile device 102 is a mobile phone and the security means 250 further comprise a security element 252 such as the one described above, the mobile phone is then called a personal trusted device or PTD.
A current example of a security element 252 adjusted to the prior definition is a Wireless Identity Module WIM defined in the Wireless Application Protocol WAP standard. The WIM provides cryptographic services, such as PKI encryption, and handling and generation of digital signatures for different mobile based applications.
The security element 252 may further include a trusted agent 254 whose purpose is to provide specific copy protection services involving the use of strong cryptography to different applications, and in particular the ticket application 200, and thus interact through the latter with the ticket issuing system 101, inspection system 106 and, further, even with a ticket application system 723' of a second mobile device 103.
The copy protection services provided by the trusted agent 254 may involve the use of PKI cryptography. In this case, the trusted agent 254 uses one or more dedicated key pairs which are initially solely employed for copy protection services. In addition, the trusted agent 254 has an access to a registry 722, preferably inside the security element 252.
A ticket application system 723 comprises ticket application 200 preferably stored in the mobile device 102, simple ticket security means 224, trusted agent 254 (preferably stored in a security element 252), and dedicated registry 722 preferably stored in a security element 252. The structure and use of the registry 722 is explained in more detail with Figures 2B and 2C.
In the following description of the preferred embodiment of ticket application system 723 it is assumed that the security element 252 is a smart card offering PKI services to the ticket application 200 through the trusted agent 254 and that by using such services the ticket application 200 achieves a high-level ticket security.
An electronic ticket 300 received from the ticket issuing system 101 is stored into ticket storage 230 which may be a database or memory including a register. The ticket storage 230 includes tickets 729 and serves them to the ticket application 200. The ticket storage 230 includes also processed nonces 730 generated by the trusted agent 254.
The User Interface U/I part 201 of the ticket application 200 performs various functions. Firstly, with the help of the U/I part 201 the user may subscribe tickets from the ticket issuing system 101. Secondly, the U/I part 201 notifies the user whenever an electronic ticket 300 is received. The user may then have an opportunity to confirm the storing of an electronic ticket 300 or to reject it. Thirdly, when the user is willing to use the electronic ticket 300, he/she may select it to be presented by selecting it from a menu in the U/I part 201.
The ticket application 200 which preferably is located in the mobile device 102 further comprises parsing means 202, comparison means 204, generation means 206, and validating means 280.
When an electronic ticket 300, i.e. any one of the tickets 729 stored in the ticket storage 230, is to be used, the parsing means 202 read the contents of the electronic ticket 300. Because several components of the electronic ticket 300 are implemented using an extensible Markup Language XML frame, the parsing means 202 can be adapted to detect a predefined keyword inside the electronic ticket 300. This predefined keyword is preferably contained within the element PTD information 703. The point of the keyword indicates the presence and location of a referenced ticket data object 303 or the presence of an embedded ticket data object 303 inside the PTD information 703. The parsing means 202 go thus through the parseable part of the ticket and produce a parsing result. This is described in more detail below with Figures 3A to 3C.
In the comparison means 204 the parsing result is checked. If the parsing result indicates that the keyword was detected, i.e. that the presence and location of the referred ticket object 303 (or that the presence of an embedded ticket object) was found, in the generation means 206 a presenting request is generated. In the opposite case no presenting request will be generated. The selection of the presenting means 260B may be constrained or indicated explicitly by the issuer; then the presenting means 260B are specified preferably within the ticket presentation information 705 by using a predefined identifier which either the ticket application 200 or the presenting means 260B have been adapted to recognise.
The presenting request is passed to the presenting means 260B comprising of a plurality of presenting means 260B, such as display 261, sending means 262, loudspeaker 264, and RF tag 265, depending on the ticket type. The presenting means 260B present the ticket object 303. Depending of the presenting means 260B selected, the presenting of the ticket object 303 takes place by displaying it on the display 261 (for a barcode or an image), by playing it through a the loudspeaker 264 thus producing an aurally recognisable tone, by beaconing the ticket object 303 i.e. storing the ticket object 303 as a whole or only an ID refererring to the object into an RF tag 265 which then beacons (such as sends as a Radio Frequency signal) the ticket object 303 when brough close enough to a check point, or in some other suitable way.
One possibility for presenting the ticket data object is to present it using sending means 262. Possibilities for the sending means 262 include normal mobile communication means, i.e. for sending the object via a mobile network communication channel, such as per short message SMS, EMS, or MMS message, or in a data packet. Also other possibilities exist, such as presenting the ticket data object by using a low-power RF chip such as the BLUETOOTH, or by presenting it using infra-red such as IrDA means, and so forth. If some of the mobile network communication channels or BLUETOOTH is to be used, the presentation of the object is then preferably addressed to a predefined address in order for the recipient of the presentation, i.e. the inspection system 106 or the ticket printer 105 or 106 receives the presentation.
Figures 2B and 2C show contents of registry 722 before and after registration, respectively. In the exemplary registry there are three registers 724A, 724B, and 724C. Each of registers 724A-C include TUID field 725 and nonce field 726.
As can be seen in Figure 2B, before registration the nonce field 726A of the register 724A includes nonce 727A, the nonce field 726B of the register 724B includes nonce 727B, and so forth, but the TUID fields 725 in all registers 724A-C are empty. The nonces 727A-727B correspond to random number which have been generated by the trusted agent 254 responsive to a request M411 from the ticket application 200. After generating the nonces 727A-727C the trusted agent 254 passes them to the ticket storage 230 and stores them in ist own registry 722. This is discussed in more detail with reference to Figure 4 below. The nonces 727A-727B can also be a URI generated by the trusted agent 254, or any other suitable identifier.
As can be seen in Figure 2C, after registration the different registers 724A-C in the registry 722 include also values in corresponding TUID fields 725A-C, respectively.
When an electronic ticket 300 having ticket unique identifier 702A has been ordered, the ticket application 200 has sent a processed nonce 727A' to the ticket issuing system 101, in this case nonce 727A together with ist signature. When the ticket issuing system then returns the electronic ticket 300, the message including the ticket includes not only nonce 727A in ticket field 704 but also ticket unique identifier 702A. When the electronic ticket 300 is then registered, i.e. validated, the value of TUID 702A is stored into TUID field 724A corresponding to nonce field 726 Including nonce 727A.
In a similar manner, for another electronic ticket 300 which has another TUID 702B and nonce 727B, the by validating it is meant that the TUID field 725B in the register 724B of the registry 722 is updated, and so forth. Then the status of the registry shows whether or not there are any nonces available in different registers. It is clear that the number of registers is not limited to three, but depends only on the amount of memory available.
The nonces can be used by the ticket application 200 to request an electronic ticket 300. Alternatively, a nonce can be passed to another mobile device 103, the another mobile device 103 having a corresponding ticket application 200', for the another mobile device 103 to request an electronic ticket 300 on behalf of the trusted agent 254 of the first mobile device 102.
When a signed nonce is either used to request a ticket 300, or transferred to another mobile device 103 through any of the available sending means 262 of the mobile device 102, the ticket application 200 marks the particular signed nonce used.
Figures 3A, 3B, and 3C illustrate a possible structure of an electronic ticket 300 and its different parts. The electronic ticket 300 includes user information 301 and ticket application information 302.
Figure 3A shows different elements of an electronic ticket 300. User information 301 is information to the user on the services, terms, and conditions of use of the electronic ticket. Ticket application information 302 presents two interfaces, one for each of two of the preferable components of the ticket application system 723, namely; (a) the ticket application 200 preferably stored in the mobile device 102, and (b) the trusted agent 254 that is preferably stored in security element 252, and where the latter might either be an integrated or detachable component to the mobile device 102. Thus, the corresponding interfaces inside the ticket application information 302 are the PTD information 703, and the security element information 701.
The PTD information 703 further comprises at least some of the following: product tag 721, presentation information 705, security information 707, and ticket object 303.
Product tag 721 indicates the type of ticket to the ticket application 200. The purpose of this tag is to allow a fast search in the ticket storage 230 for a given ticket product marked with product tag 721. In the case that there are several tickets among the tickets 729 matching the searching criteria, the user will be requested to choose which one should be presented to the inspection system 106.
Presentation information 705 indicates to the ticket application 200 which presenting means 260B of the mobile device 102 is preferably to be used for presenting the ticket data object 303.
Security information 707 indicates the security requirements to the ticket application 200 in regard of the ticket data object 303. These requirements need not be performed by the security element 252, and thus can be implemented by the simple ticket security means 224.
Ticket object 303 is presented by the ticketing applicaton 200 to the inspection system 106 in order to gain access to a given service. Consequently, it is also the object that needs to be protected. To achieve a high level of copy protection, the ticket object 303 has to include a ticket unique identifier TUID 702. Further, the ticket unique identifier 702 should be identical to that stored in the security element information 701.
With further regards to the ticket object 303, it can be protected against modification of its content by adequate means provided before hand by the issuing system 101. This means can be encryption, issuer signature 708 by using the issuing system PKI signature, and/or complex or even obscure coding. Some of this means can also be used for achieving obfuscation of the ticket object 303.
A trusted agent 254 can be used to protect the ticket object 303 against illegal duplication and double expending. This provides a high level of security, especially when the trusted agent 254 is located inside the security element 252. The security element information 701 includes information necessary for the trusted agent 254. The security element information 701 can further include any of the following subelements: i) ticket unique identifier 702 , ii) nonce 704, iii) N of uses 711, especially a field value indicating multiple use in case of a multiple use ticket, and/or iv) signature element 731.
The ticket unique identifier 702 is preferably common to the ticket object 303. Nonce 704 corresponds to a version control identifier. The signature element 731 contains the issuer signature 708' of the security element information 701 (excluding the signature itself) for an electronic ticket 300 in sealed state. When the electronic ticket 300 is registered with the trusted agent and the ticket is in so-called validated state, the signature element contains the trusted agent signature 709 of the security element information 701 (excluding the signature itself).
Ticket value data 720 is the "ticket value" information within the ticket object 303, and it is necessary for accessing a service offered. It is not the price tag but can nevertheless correspond to monetary information, such as describing the price or value of the electronic ticket 300. This is particularly useful when the value of the service for which the electronic ticket 300 is spent changes or has changed between the issuing of the ticket and the consuming of the service. The user can be requested to pay more, the amount of payment then depending on the price change, or in the opposite case the user can be credited for the price difference.
In the preferred embodiment of the invention, the ticket object 303 can be in any given format and content as defined by the issuer, the other parts of the electronic ticket 300 are a part of an XML document, except for the security element information 701. This latter information, likewise the ticket object 303 itself, can be referred to or otherwise embedded in the XML document part, such as in the ticket application information 302. Consequently, the security element information 701 can have format that is more easily handled by current smart card technology.
In order to achieve a high level of security for the copy protection of the ticket object 303, by the means of the security element information 701, the latter can implicitly be linked to a given trusted agent 254, located in a particular security element 252. Furthermore, both items, ticket object 303 and security element information 701, are preferably presented during ticket use to the inspection system 106.
In view of the above, the elements of an electronic ticket 300 can be considered to belong to two different classes as shown in Figure 3A, namely to public part 300PU and to private part 300PR. In the public part 300PU, if an authentication of any part of the data is needed, this will be preferably achieved by means of the verification of the issuer signature 708, i.e. a digital signature of the issuing system 101. In the private part 300PR there are two cases; when the electronic ticket 300 is in a sealed state, and when it is in a registered state.
Figure 3B illustrates some differences between the electronic ticket 300 in a sealed or in a registered state in more detail:
If the electronic ticket 300 is in the sealed state, the authentication of the corresponding data (i.e. security element information 701) performed by the trusted agent 254 is achieved by means of the verifying the issuer signature 708' of the issuing system 101. If the electronic ticket 300 is in the validated state, the authentication of the correspoing data (i.e. security element information 701) is performed by either the trusted agent 254, or the inspection system 106, and it involves the verification of the trusted agent signature 709.
The description of the preferred embodiment for the ticketing processes of (1) request, (2) issuing & delivery, (3) registration, (4) use and (5) transfer refers to the security element information 701 as private part 300PR, and to the rest of ticket elements as public part 300PU.
Figure 3C illustrates the state change of an electronic ticket 300. The state of the electronic ticket 300 is changed from a sealed to a validated state primarily by effecting the change of the 300PR sealed to a 300PR validated field.
Figure 4 illustrates in dashed box 41 how nonces are generated and in dashed box 43 how the issuing of an elecronic ticket can be requested.
Before a ticket is requested, at least one nonce 704 has been generated. This is illustrated in more detail in dashed box 41. The nonces are generated by trusted agent 254 responsive to message M401 which is generated in preparation step L10 by the ticket application 200.
Responsive to the receiving of message 401, to trusted agent 254 initiates processes described in step L11 for generating nonces. In step L11 the trusted agent 254 performs substeps L112-L116.
In step L112 a processed nonce 727' is generated, preferably by using a random number generator located in the security element 252. Nonces 727 can also be understood to correspond to unique identifiers (such as URI), and they need not be generated by a random number generator but may also obtain sequential values.
In step L113 each of a nonce 727 is stored in nonce field 726 of register 724 of the registry 722. This has already been described in more detail with reference to Figures 2B and 2C. A copy of nonce 727 is processed and stored together with other similarly processed nonces to form processed nonces table 730.
In step L114 a copy of each nonce 727 contained in the registry 722 is processed. Consequently, each nonce is by processing implicitly linked to the trusted agent 254. This can be done by signing each nonce 704 with the trusted agent signature 709 to obtain processed nonce 727'.
In step L115 processed nonces 727' are sent to the ticket storage 230 in message M403 and stored into processed nonces table 730.
In step L116 the trusted agent 254 sends a confirmation message M405 to the ticket application 200 in order to indicate that the execution of process L11 has been finished. The step L10 is terminated upon receiving confirmation message M405.
Dashed box 43 shows how the issuing of an elecronic ticket can be requested. In step L12 a request M411 is generated and finally sent to the ticket issuing system 101. The ticket application 200 accesses the area of the ticket storage 230 where the processed nonces 727' are stored into processed nonces table 730 by sending a message M407 to ticket storage 230, and gets as response message M409 list a processed nonce 727'. The processed nonce 727' is written into the request M411 as well the PKI certificate of the trusted agend 254. Then the ticket application 200 uses available sending means 262 for sending request M411 to the ticket issuing system 101. M411 can also include information on the desired ticket but it does not need to include such information, because the address of the ticket issuing system 101 can do that, such as when the kind of the ticket is designed by a MSISDN number to which the message M411 is sent as an SMS.
The ticket issuing system 101 recognises that the incoming message M411 is a ticket request and in step K1 the substeps K11 to K13 are performed. In step K11 the ticket issuing system 101 verifies the signature of the processed nonce 704 included in message M411 by using the public key of the trusted agent 254 included in the trusted agent 254 certificate. The certificate need not be there, because instead of transferring a certificate in message M411, a Universal Resource Indicator URI referring to an address location where the certificate is stored. Using the URI the ticket issuing system 101 can find the correct certificate in the Internet 100B or elsewhere.
In step K12 the ticket issuing system 101 generates an electronic ticket 300. A ticket product tag 721 is included inside the element PTD information 703. This is done in order to facilitate the fast searching of tickets during ticket use; this is in more detail described with reference to Figure 6A.
Further, the ticket issuing system 101 also embeds or sets a reference in the element PTD information 703 to the ticket object 303. The ticket object 303 may include, in any way acceptable by parsing means 811 of the ticket inspection system 106, TUID 702. In practice, the TUID 702 should be the same as the TUID 702' inside ticket data 706.
Further, in step K12 the processed nonce 727' stored among processed nonces table 730 that was provided by the ticket application 200 in M411 is verified by the ticket issuing system 101. Then the copy of nonce 727 is written inside the ticket data 706 i.e. into the field nonce 704 as shown in Figure 3B.
In step K13 the ticket issuing system 101 seals the electronic ticket 300. This was illustrated in more detail in Figure 3B by defining public part 300PU and private part 300PR for the electronic ticket 300.
Further, in step K13 the ticket issuing system 101 signs the private part 300PR with issuer signature 708 and encrypts the ticket data 706 with the public key of the trusted agent 254, thus generating the ticket data 706.
The ticket issuing system 101 can embed the private part 300PR inside the ticket application information 302 of the electronic ticket 300, or it can insert a link into ticket application inofmation 302 pointing or referring to a separate object.
After performing steps K11 to K13, the ticket issuing system 101 sends the sealed ticket in message M413 to be available for the ticket application 200, i.e. to the mobile device 102. The mobile device 102 using its receiving means 263 passes the message M413 to the ticket application 200, for example, by notifying a suitable port daemon.
The ticket application 200 receives message M413 including an electronic ticket 300 in sealed state. The message M413 comprises at least some of the following: product tag 721, ticket unique identifier 702, and a value for nonce 704. After receiving the message M413, the ticket application 200 indicates the reception of the electronic ticket 300 to the user by the use of input/output means 260. The user can then choose whether to accept or discard the electronic ticket 300. If the user accepts the ticket, the ticket application 200 in step L13 stores the electronic ticket 300 in sealed form ticket by sending the message M415 to the ticket storage 230.
Figure 5 shows the registration of the electronic ticket 300 which is in sealed state. At any given time after the phase of delivery, the user can choose to register the electronic ticket 300 with the trusted agent 254. According to the present invention, a delayed validation of the electronic ticket 300 can thus be achieved. The process of registering a ticket includes can be carried out as follows.
In step L14 an electronic ticket 300 is selected. In order to facilitate the selection, the user can employ the U/I part 201 of the ticket application 200 or the mobile device 102 in order to access the ticket storage 230 and select an electronic ticket 300 which is in sealed state. The ticket application send message M501 to ticket storage 230 which returns returns the electronic ticket 300 in sealed state in message M503.
Next the ticket application 200 proceeds to step L15A where a ticket validation request M505 is generated. In the ticket validation request M505 the ticket application 200 sends the electronic ticket 300 in sealed form together with the issuer certificate to the trusted agent 254. In response to receiving the ticket validation request M505 the trusted agent performs in step L15B substeps L151 to L156. In step L151 the trusted agent 254 decrypts ticket data 706' using its dedicated private key, and thus obtains the ticket data 706. Further, in step L152 the trusted agent 254 compares the issuer signature 708' with the ticket data 706. If the comparison result shows that the issuer signature 708' does not match with the ticket data 706, an error message is generated and no further steps are performed in the trusted agent.
In the opposite case, if the comparison result of the step L152 was successful, in step L153 the trusted agent 254 compares the nonce 704 inside the ticket data 706, with the available nonces inside the registry 722 as already shown in Figure 2B. If the comparison result shows that a matching nonce is found, the registering of the ticket is allowed.
In step L154 the trusted agent 254 copies the TUID 702' into the inside of the TUID field 725 corresponding to the nonce field 726 containing the matching value of nonce 704.
In step L155 the trusted agent 254 signs ticket data 706 with its own trusted agent signature 709. In the signing it may then use its dedicated private key.
In step L156 the trusted agent 254 returns the private part 300PR to the ticket application 200 by sending it in the message M507.
In response to receiving the message M507, the ticket application 200 sends the electronic ticket 300 in validated state to the ticket storage 230.
Figures 6A and 6B illustrate one aspect of the present invention. It is assumed that the inspection system corresponds to that of Figures 1B and 1C as described above. The proximity detection means 802 and proximity discrimination means 803 are used in the case of a local presentation of the electronic ticket 300.
In step K4 the ticket inspection system 106 sends a message M601 to the ticket application 200. The message M601 includes product tag 721 for the service that is being offered through the ticket inspection system 106, and a new value NONCE'' for the nonce 704. The ticket inspection system 106 stores a copy of the new value NONCE'' for the nonce 704 in storage 807 so that the private part 300PR in validated state defined by this new value NONCE'' for the nonce 704 can be verified during the ticket verification phase in steps K15-K20 of Figure 6B.
The ticket application information 302 or ticket data 706 may include a user-friendly name identifier to identify the ticket product to the user, for example, a football match Spain-Brazil. However, the product tag 721 includes an additional identifier, such as an alphanumeric identifier of given length. The goal of the product tag 721 is to tag the ticket as pertaining to a given ticket product.
In the case the ticket is implemented using XML format, the product tag 721 comprises a label or tag which preferably will be invisible to the user but is used by the ticket application 200 in order to perform a fast search of adequate tickets to access a given service. This means that even when the XML based ticket is stored encrypted in the ticket storage 230 for saving storage area in the device, the product tag 721 will be made available to the ticket application 230.
The ticket inspection system then works accordingly with this approach to improve usability and speed of use. In message M601, i.e. ticket presentation request, in the neighborhood of the service access point. Any mobile device in the neighborhood of the service access point is able to capture the message M601 and pass it to its ticket application 200. The ticket application 200 performs, preferably automatically, in step L16 a search (e.g. by sending message M603 and receiving message M605 to the ticket storage 230) on the available product tags 721 in the ticket storage 230. The selected electronic ticket 300 are then in step L17 presented to the user which can select one having certainty that the ) electronic ticket 300 to be selected and presented (step L18 and onward) is the correct one.
The new value NONCE'' for the nonce 704 is preferably unique for each ticket use request M601. The preferred method to generate this new value NONCE'' for the nonce 704 is to use a random number generator for generating random digits, consisting of 64 or 128 bits, for example.
It is also assumed that the ticket inspection system 106 is able to discriminate between mobile devices 102, with the help of its proximity detection means 802, and/or its proximity discrimination means 803.
The ticket application 200 receives the message M601 via receiving means 263. In response to receiving the message M601, after processing the message, the ticket application 200 searches in step L16 through the ticket storage 230 for tickets matching the product tag 721 included in the message M601 by sending a message M603. More precisely, the searching is performed in the field product tag 721 of the tickets 300 as described in Figure 3A. If among the tickets 729 there are any or some ticket electronic ticket 300 corresponding to the field product tag 721 contained in message M601, the ticket storage 230 returns the TUID of them in message M605.
In step L17, the ticket application 200 displays the results of the search on the display 261.
In step L18 in the case that there were several tickets matching the product tag supplied by the inspection system 106, the user is allowed to select one to be used. The ticket application 200 communicates the selection by sending message M607 to the ticket storage 230 which in message M609 returns the TUID and NONCE' of the electronic ticket 300 which is in validated state, i.e. it has been registered with the trusted agent 254 earlier.
In step L19A message M611 is first generated in the ticket application and then sent to the trusted agent 254. The message M611 includes the new value NONCE'' of the nonce 704 and the private part 300PR of the selected electronic ticket 300 in validated state. In response to receiving message M611, several substeps L191 to L195 are performed at the trusted agent 254 in step L19B.
In step L191 the trusted agent 254 compares its own trusted agent signature 709 with the ticket data 706 included in message M611. In step L192 the trusted agent searches in the registry 722 the individual registers 724 until it finds one such register 724 for which ist TUID field 725 includes a matching value for the TUID 702 in the ticket data 706.
When an adequate register 724 is found, the trusted agent 254 compares the values of the nonce field 726 with the nonce 704 to verify that they match. This is done in order to verify that the version of the private part 300PR of the electronic ticket 300 in validated state presented to the trusted agent 254 is the latest one.
In step L193, if steps L191 and L192 were successfully performed, and assuming that N of uses 711 shows that the ticket has a number of uses left different from zero, the trusted agent 254 updates the N of uses 711 to correspond to number of uses left. This can be done by changing the N of uses 711 in ticket data 706 by subtracting a predefined value from it, such as N is changed to a value N-1 if the predefined value is 1.
In step L194 the trusted agent 254 updates with the new nonce provided by the inspection system 106 the values of the nonce fields of: i) in the ticket data 706, the nonce 704; and ii) in the corresponding register 724 the corresponding nonce 727 in nonce field 726. This is the corresponding register 724 to the TUID field 725 containing a matching value to the value contained in the TUID 702' of the ticket data 706.
If the N of uses 711 matches with a predefined criteria, such as when the current number of uses left for the ticket after step L193 would be zero, the trusted agent 254 removes from the registry 722 the register 724 the TUID field 725 of which contains a value matching with the TUID 702' in the ticket data 706.
In step L195 the trusted agent 254 signs the newly modified private part 300PR validated, and returns it to the ticket application 200 in message M613.
At the last part of step L19A, the ticket application 200 stores the new version of the electronic ticket 300 in the ticket storage 230 in message M615.
In step L20 the ticket application 200 creates message M617 including the corresponding ticket object 303, of the PTD information 703 of the electronic ticket 300, and the new version of the private part 300PR of the electronic ticket in validated state. Then the message M617 is sent to the inspection system 106.
Figure 6B illustrates a scenario of using an electronic ticket 300, or how an electronic ticket 300 is verified in step K5.
In response to receiving a message M619 the ticket object 303 and the new version of the validated private part 300PR via receiving means 806, the ticket inspection system 106 verifies in step K15 that the ticket object 303 has not been tampered with.
If the selected verification method is that the ticket object 303 has been digitally signed with the issuer signature 708, the execution of step K15 requires that the inspection system 106 performs the verification of the issuer signature 708 over the ticket object 303. Hence, the inspection system 106 needs to have prior access to the ticket issuing system 101 PKI certificate. It is assumed that the inspection system 106 already has this information, and thus the mobile device 102 does not need to provide it. Preferably, the inspection system 106 extracts from the ticket object 303 the value of TUID 702.
In step K16 the inspection system 106 verifies the trusted agent signature 709 by comparing it with the ticket data 706. For this purpose it uses the trusted agent 254 certificate which has been preferably delivered in step L20.
In step K17, if the verification result of step K6 shows that the trusted agent signature 709 matches with ticket data 706, i.e. that the step K16 was successful, the inspection system 106 compares the nonce 704 of the private part 300PR in ticket data 706 with the copy of the new nonce NONCE'' sent to the ticket application 200 in step K14. This step can be perormed in a number of ways, for instance, by making a search for the nonce 704, in storage 807 of the inspection system 106.
In step K18, if the result of step K17 shows that step K17 was successful, i.e. if the nonce 704 of the ticket data 706 matches with the copy of the new nonce sent to the ticket application 200, the inspection system 106 compares the TUID 702 of the ticket object 303 with TUID 702' of the private part 300PR in order to verify that they are related.
In step K19 the inspection system 106 grants the user access to a given service. This can be performed by opening a gate, by changing a state of a system flag in a computer memory, by sending a message, or by showing a positive acknowledgement signal to a human inspector, for example.
In step K20 the inspection system 106 generates a confirmation message M621 to be sent to the ticket application 200. This confirmation message M621 preferably contains a time stamp and an ticket product tag. Then the confirmation message M621 is sent from the ticket inspection system 106 to the ticket application 200.
In step L21, in response to receiving of the confirmation message M621, the ticket application 200 indicates the receiving of the confirmation message M621 to the user using suitable presenting means 260B using the U/I part 201. The user can then by using receiving means 263, such as by giving his/her input via the keyboard, a joystick or by using a voice command decide to store the confirmation message M621 in the ticket storage 230. The confirmation message M621 can be used as a receipt, i.e. it serves in proving that the user had access to the service in a correct manner. If the message M621 is to be stored as a confirmation message, the ticket application 200 saves it into the ticket storage 230.
Figure 7 shows a scenario of transferring an electronic ticket 300, the transferring including also steps for ticket verification. A user with a mobile device 102B requests the user with a mobile device 102 to transfer a given number of ticket units of a given multiple use ticket to the device 102B. For the sake of clarity, in the nomenclature similar references are used in such a manner that the blocks in the device requesting the ticket units is denoted with adding a capital letter B to the end of each reference.
A transfer action of this kind is up to a high extent analogical to transfer a single unit ticket completely to the other device.
In step L22 the ticket application 200B requests processed nonces 730 that are available by sending a message M701 to ticket storage 230B. In response to message M701, at least one non-used processed nonce 727' having a value NONCE'' is received from the ticket storage 230B in message M703. The signed nonce 727' is sent in a message M705 to another mobile device 102 which routes the message M705 to the ticket application 200. Preferably, the message M705 also contains the trusted agent 254B PKI certificate.
The ticket application 200B in step L22 marks the nonce 704 in the ticket storage 230B used.
In step L23 the ticket application 200 stores the signed nonce 727' obtained in the message M705 into the ticket storage 230 as well as the trusted agent 254B PKI certificate. Preferably, the ticket application 200 allows via the U/I part 201 the user to give a user-defined label to signed nonce 727' to indicate its origin and/or future use (e.g. "Ticket4Lorena"). In addition, signed nonce values from other devices can be stored in a particular area of the ticket storage 230 in order to achieve a better user experience. Furthermore, the ticket application 200 establishes a reference link between this signed nonce 704 and the trusted agent 254B PKI certificate in order to facilitate later processes.
Later, in step L24A, the user decides to split the electronic ticket 300, so he or she uses the U/I part 201 of the ticket application 200 to initiate a split process. This process starts by allowing the user to select i) the processed nonce 727' which is easy to recognise because of the user-defined label, and ii) the electronic ticket 300 to be split. Also, the user can use the U/I part 201 for determining how many units are to be split. The items to be selected are requested by sending message M709 to ticket storage 230 which then in messages M711 to M715 responds to the message M709. Message M711 includes processed nonces 727', message M713 includes electronic tickets 300 in validated form, including TUID and NONCE', whereas message M715 includes the trusted agent 254B PKI certificate.
Consequently, values retrieved in messages M711 to M715 are passed to the trusted agent 254 in message M717 together with the number of units value selected by the user.
In response to the receiving of message M717, in step L24B several substeps L241 to L248 are performed in the trusted agent 254. In step L241 the trusted agent 254 verifies the NONCE'' signature in processed nonce 727' using the trusted agent 254B public key contained in the trusted agent 254B PKI certificate.
In step L242 the trusted agent 254 verifies its own trusted agent signature 709 over the ticket data 706. In step L243, if the results of steps L241 and L242 have been successful, the trusted agent 254 searches in the registry 722 through the individual registers 724 until it finds the one the TUID field 725 of which contains a matching value for the TUID 702' in the ticket data 706.
When an adequate register 724 is found, the trusted agent 254 compares the values of the nonce field 726 with nonce 704 to verify that they are identical. This is done in order to verify that the version of the validated private part 300PR presented to the trusted agent 254 is the latest one.
In step L244 the trusted agent 254 generates ticket data 706B by: i) creating fields TUID 702B', nonce 704B, and N of uses 711B, ii) copying TUID 702' of ticket data 706 into TUID 702B' of ticket data 706B , iii) copying NONCE'' to the nonce 704B in the ticket data 706B, and iv) copying the value of number of units to split to the N of uses 711B.
In step L245 the trusted agent 254 updates the N of uses 711 with the new value in ticket data 706, such as "N-n of units to split".
In step L246 the trusted agent 254 updates the values of the nonce 704 and of the nonce field 726.
To summarize: In the case that the number of units left (N-n of units split) is different from zero, the trusted agent 254 generates a new nonce value and inserts it as the value of the nonce 704 in the private part 300PR in ticket data 706 and the corresponding nonce field 726 in the registry 722.
In the case that the number of units left (N-n of units split), is equal to zero corresponding to the case that all units have been transferred to the other ticket, the trusted agent 254 removes from the registry 722 the corresponding register 724 whose TUID field 725 contains a matching value for the TUID 702' in the ticket data 706.
In step L247 the trusted agent 254 seals private part 300PRB by signing it with its own trusted agent signature 709" and encrypts the private part 300PRB in ticket data 706B with the trusted agent 254B public key, thus generating ticket data 706'B.
In step L248 the trusted agent 254 signs the validated private part 300PR with its own trusted agent signature 709.
Finally, the trusted agent 254 returns in message M719 the private part 300PRB in sealed state and private part 300PR in validated state to the ticket application 200 which stores the tickets in the corresponding compartments in the ticket storage 230 by sending message M721.
In addition, the ticket application 200 stores the private part 300PRB with the same user-defined label. For enhanced usability, the storage area in the ticket storage 230 for these split tickets from/to other devices can be tailored device-specifically. A duplicate of the original public part of electronic ticket 300PU can be stored with the private part of electronic ticket 300PRB.. Alternatively, a link to it can be provided. In the latter case, the duplication of the public part of electronic ticket 300PU is performed during the transfer.
In step L25, at some given time, the user decides to send the sealed electronic ticket 300B (300B = 300PUB + 300PRB) to the other mobile device 102B. Thus, he or she uses the U/I part 201 for selecting a sealed ticket, requesting it from the ticket storage 230 by sending message M723 and receiving it in message M725. Then the electronic ticket 300B in sealed state is sent to the other mobile device 102B in message M727.
In step L26 the ticket application 200B receives the ticket in message M727 via receiving means 263B. With its input/output means 260B, in response to receiving to the ticket, the ticket application 200 indicates to the user the reception of a digital ticket. The user can choose to accept or discard the electronic ticket 300B received. If the he or she accepts the ticket, the ticket application 200B stores the sealed ticket in the ticket storage 230B by sending message M729.
The different steps of Figures 4 to 7 can be implemented as primitives of a smart card or a secure element which enables then a high level of code reuse.
The type of services offered by digital tickets can also be different from the typical services directly offered to users, such as transportation tickets. Alternative services can include the execution of content stored in the inspection system 106 or elsewhere, for the benefit of the user or some other entity.
Although in the examples it is assumed that the presentation environment of the ticket object to the inspector in the preferred embodiment would be either remote (e.g. at the Internet 100B) or local (e.g. at a transportation service access point by local transportation means such as BLUETOOTH or IrDA), with special emphasis in the local enviroment, the present invention does not exclude the personal presentation environment that is around the mobile device 102 itself. This personal presentation environment can be an element permanently integrated by software, hardware, or both in the mobile device 102 and/or located in a detachable separate hardware component.
Usually, copy protection is relevant only on the context of double spending of the same ticket object 303. In the present invention the copy protection is achieved by rendering useless copies of the ticket object 303 that are not validated by a trusted agent 254 through a reliable and protected interface, i.e. copies of private part of electronic ticket 300PR.
The present invention is mainly but not exclusively meant for electronic tickets. There are other types of data objects benefitting from such a high-level security copy-protection offered by the present invention, requring only little or even none modification. To such types of data objects belong medical prescriptions, legal documents, and even executable content. In particular, in the last aforementioned case the presentation enviroment of the object can be either remote, local, or personal, as already discussed.
Although the invention was described above with reference to the examples shown in the appended drawings, it is obvious that the invention is not limited to these but may be modified by those skilled in the art without difference from the scope and the spirit of the invention.

List of used references

41: nonce generation
43: ticket issuing request
100A: mobile network
100B: the Internet
101: ticket issuing system
1011: front end of ticket issuing system
1012: back end of ticket issuing system
1013: data storage of ticket issuing system
102, 103: mobile devices
104: personal computer
105: ticket printer
106: inspection system
199: shielding means
200: ticket application
201: user interface part of the ticket application 200
202: parsing means
204: comparison means
206: generation means
224: simple ticket security means
230: ticket storage
250: security means
252: security element
254: trusted agent
260: input/output means
260B: presenting means
261: display
262: sending means
263: receiving means
264: loudspeaker
265: radio frequency tag
280: validating means
300: electronic ticket
300PU: public part of electronic ticket
300PR: private part of electronic ticket
301: user information
302: ticket application information
303: ticket object
701: security element information
702: ticket unique identifier TUID
703: PTD information
704: nonce
705: presentation information
706: ticket data
707: security information
708: issuer signature
709: trusted agent signature
711: N of uses
720: ticket value data
721: product tag
722: registry
723: ticket application system
724A,B,C: register 1,2,3
725A,B,C: TUID field
726A,B,C: nonce field
727: nonce
727': processed nonce = 727 + 709 calculated for 727
729: tickets
730: processed nonces table
731: signature element
801: broadcasting means
802: proximity detection means
803: proximity discrimination means
804: point to point sending means
805: transport means
806: receiving means
807: storage
808: generation means
809: comparison means
810: verification means
811: parsing means
814: ticketing means
ΔR₁, ΔR₂: proximity range of inspection system 106

Claims

A device (105, 106) for requesting the use of an electronic ticket (300) wherein the improvement comprises: the device is adapted to transmit via broadcasting means (801) or point to point sending means (804) a product tag (721) or other identifier describing at least one ticket type supported by the device.
A device according to claim 1, wherein: the device further includes generation means (808) for generating a request (M601) for using an electronic ticket (300), the request (M601) including a refresh value (NONCE'') for a second identifier (704) of said electronic ticket (300).
A device according to claim 2, wherein: the device further includes point to point sending means (804) for transmitting said request (M601) to a mobile device (102).
A device according to claim 2, wherein: said generation means (808) and/or point to point sending means (804) are responsive to proximity discrimination means (803) so that a mobile device (102) is to be detected prior to generating and/or sending the request (M601) to the mobile device (102).
A device according to any one of claims 1 to 4, wherein: the proximity range (ΔR₁, ΔR₂) of the broadcasting means is asymmetric.
A device according to claim 5, wherein: the asymmetry has been obtained by using shielding means (199).
A mobile device (102) wherein the improvement comprises: receiving means (263) adapted to receive a product tag (721) or other identifier describing ticket types, especially describing services available in the neighborhood of a service access point, the product tag (721) being broadcasted by a device (105, 106) requesting the use of an electronic ticket, especially an inspection system (106) or a ticket printer (105).
A mobile device according to claim 7, wherein: the mobile device (102), or especially a ticket application (200) included therein, is adapted to search an electronic ticket (300) corresponding to said product tag (721) among tickets (729) to access a given service.
A mobile device (102) according to claim 7 or 8, further including:

parsing means (202) for extracting an identifier (721) received;

comparison means (204) for comparing said identifier (721) with identifiers stored in a ticket storage (230); and

presenting means (260B) responsive to said comparison means (204), adapted to present ticket data (706) to a user, for instance, for presenting a ticket type supported by the ticket inspection system (106) and contained among tickets (729).
A mobile device (102) according to claim 7, 8, or 9, wherein: the device (102) includes receiving means (263) for the user to select which ticket (300) to be presented, especially if there are more than one ticket (729) in the ticket storage (230).
A mobile device (102) according to any one of the preceding claims, characterised in that it includes:

receiving means (263) for receiving an electronic ticket (300), the electronic ticket (300) including a first identifier (TUID) and a second identifier (NONCE');

a ticket storage (230) for storing the electronic ticket (300);

secure storing means (252) for storing the first identifier (TUID1); and

validating means (280) adapted to store the first identifier (TUID1) to the secure storing means (252) when the electronic ticket (300) is validated.
A mobile device (102) according to claim 11, wherein: the validating means (280) are adapted to store the first identifier (TUID1) to the secure storing means (252) responsive to any predefined user input received after receiving a product tag (704) when an electronic ticket (300) is being validated.
A mobile device (102) according to any one of claims 7 to 12, wherein: the ticket application (200) or the mobile device (102) comprises software code programmed in a symbolic language, especially using any JAVA compiler.
A mobile device according to claim 13, wherein: the software code shares object classes between functionalities for ticket transferring and ticket issuing request, especially JAVA classes.
A system wherein a device (102) for validating an electronic ticket (300), a ticket issuing system (101) and/or a device for issuing an electronic ticket (300), and a device (105, 106) for requesting the use of an electronic ticket (300) is used.
A ticket issuing system (101) or a device for issuing an electronic ticket (300), wherein the improvement comprises: the system (101) or the device includes generation means (1012) adapted to generate an electronic ticket (300) including a product tag (721).
A ticket issuing system (101) or a device for issuing an electronic ticket (300) according to claim 16, wherein: the generation means (1012) are further adapted to generate the electronic ticket (300) responsive to a request (M411) including a first identifier (NONCE') or an identifier derived therefrom, and a second identifier (TUID1); and where the electronic ticket (300) includes a first identifier (NONCE') or an identifier derived therefrom, and a second identifier (TUID1).
A system or device according to claim 17, wherein: the system or device includes means (1012) for sealing the ticket (300)
An electronic ticket (300) having a product tag (721) or other identifier describing ticket types available especially in the neighborhood of a service access point preferably connectable to a device (105, 106) for requesting the use of an electronic ticket (300).
An electronic ticket (300) according to claim 19 wherein: the electronic ticket (300) further may have a sealed state and a validated state, the state of the electronic ticket (300) being defined by a public part (300PU) or a private part (300PR) of the electronic ticket (300), in such a manner that whenever the private part (300PR) corresponds to a valid value, the ticket is in the validated state.
An electronic ticket (300) as defined in claim 20, wherein: the valid value for private part (300PR) corresponds to an identifier (704) stored in security means (250) of a mobile device.
A method for requesting the use of an electronic ticket (300) wherein: the improvement of the method comprises performing the step of: transmitting a product tag (721) or other identifier describing at least one ticket type supported by a device (105, 106) for requesting the use of an electronic ticket (300).
A method according to claim 22, the method further comprising the step of: generating a request (M601) for using an electronic ticket (300), the request (M601) including a refresh value (NONCE'') for a second identifier (704) of said electronic ticket (300).
A method for receiving a request (M601) for using an electronic ticket (300) comprising the step of: receiving a product tag (721) or other identifier describing services especially available in the neighborhood of the service access point, the product tag (721) being broadcasted by a device (105, 106) requesting the use of an electronic ticket, especially an inspection system (106) or a ticket printer (105).
A method for issuing an electronic ticket (300) comprising the step of: generating an electronic ticket (300) including a product tag (721).
A method for issuing an electronic ticket (300) according to claim 25 further wherein: the electronic ticket (300) is generated responsive to receiving of a request (M411) including a first identifier (NONCE') or an identifier derived therefrom; and where the electronic ticket (300) includes a first identifier (NONCE') or an identifier derived therefrom, and a second identifier (TUID) .