EP1439495A1 - Electronic ticket, system and method for issuing electronic tickets, and devices and methods for using and performing operations on electronic tickets - Google Patents
Electronic ticket, system and method for issuing electronic tickets, and devices and methods for using and performing operations on electronic tickets Download PDFInfo
- Publication number
- EP1439495A1 EP1439495A1 EP03001026A EP03001026A EP1439495A1 EP 1439495 A1 EP1439495 A1 EP 1439495A1 EP 03001026 A EP03001026 A EP 03001026A EP 03001026 A EP03001026 A EP 03001026A EP 1439495 A1 EP1439495 A1 EP 1439495A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- ticket
- electronic ticket
- identifier
- nonce
- electronic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00896—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys specially adapted for particular uses
Definitions
- the invention relates generally to electronic tickets or documents, and, more specifically, to generating, transferring, and presenting such tickets or documents.
- FIG. 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.
- 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.
- 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.
- 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.
- the system also includes a ticket printer 105.
- 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.
- the tickets are explictly and permantely linked to a given secure element after validation, then it remains a problem how the ticket can be transferred to be used in another device with another secure element (e.g. by another user).
- the on-line access to the secure element during the ticket request and delivery prohibits the possibility of asynchronous delivery modes, such as the Multimedia Messaging Service MMS, or using different delivery means, especially the Internet.
- Siemens suggested that a real-time clock could be used to achieve delayed validation. This, however, has turned out to be technologically too complicated, as a secure real time clock located in the user device is at the moment too expensive to construct. So, it still remains as a problem how to delayed the validation of a given ticket with the secure element while keeping a high security level of copy protection of the ticket.
- a device for validating an electronic ticket includes i) receiving means for receiving an electronic ticket, the electronic ticket including a first identifier and a second identifier, ii) a ticket storage for storing the electronic ticket, iii) secure storing means for storing the first identifier, and iv) validating means adapted to store the first identifier to the secure storing means when the electronic ticket is validated.
- the device for validating an electronic ticket may further include security means for verifying the origin of the electronic ticket, preferably by decrypting at least a part of ticket containing said first and second identifiers, especially using a private key assigned to a trusted agent.
- security means for verifying the origin of the electronic ticket preferably by decrypting at least a part of ticket containing said first and second identifiers, especially using a private key assigned to a trusted agent.
- a device for presenting an electronic ticket includes presenting means for presenting the first identifier and the second identifier in order to use said electronic ticket.
- the electronic ticket can be presented in a convenient manner, and copy protection can also be obtained.
- the ticket application and/or security means are safe, then it can also be ensured that the electronic ticket cannot be presented multiple times if that is not allowed.
- the device for presenting an electronic ticket can further include means for verifying the identity of an entity to which the electronic ticket is going to be presented.
- Such an arrangement brings about an enhanced security.
- the ticket inspetion system or ticket printer can now be authenticed, which makes the ticket application and ticket application system more harder to crack by malicious parties.
- a device for validating and/or presenting an electronic ticket can further include i) generation means adapted to generate at least one third identifier; and whereby the secure storing means are adapted to store the third identifier and/or the ticket storage is adapted to store the third identifier.
- a device for validating and/or presenting an electronic ticket can further include i) generation means adapted to generate a second identifier, ii) generation means adapted to generate a ticket issuing request including the second identifier generated and iii) sending means for sending the ticket issuing request to a ticket issuing system. If a request is generated in this manner, based on the identifier, the ticket issuing system can ensure that the electronic tickets oredered really are what the user or the device has been subscribing.
- a device for validating and/or presenting an electronic ticket can further includes means for changing the third identifier in the ticket storage and/or in the secure storing means in response to a change request, especially relating to said using or transfer of the electronic ticket, or in response to using the ticket, such as received from an entity to which the electronic ticket is presented.
- serial tickets can be shared between users, one user can transfer his/her tickets to another user, and a user can ask another user to subscribe a copy-protected ticket on behalf of him/herself.
- a ticket issuing system or a device for issuing an electronic ticket includes includes generation means adapted to generate an electronic ticket responsive to a request including a first identifier and a second identifier, especially when the request has been generated by a device for validating an electronic ticket, and where the ticket includes a first identifier or an identifier derived therefrom.
- generation means adapted to generate an electronic ticket responsive to a request including a first identifier and a second identifier, especially when the request has been generated by a device for validating an electronic ticket, and where the ticket includes a first identifier or an identifier derived therefrom.
- a ticket issuing system or a device for issuing an electronic ticket can further include means for sealing the electronic ticket. This enhances the security of the electronic ticket, because the issuer can now ensure that only a trusted user is able to validate the ticket.
- a device for requesting the use of an electronic ticket includes generation means for generating a request for using an electronic ticket, the request including a refresh value for a second identifier of an electronic ticket. Such a device enables the use of copy-protected electronic tickets that have been validated not in real-time.
- a device for requesting the use of an electronic ticket may further include broadcasting means for broadcasting a product tag or other identifier describing ticket types supported by the device. So the ticket application can be advised to select only such tickets that are currently usable. In this manner, costly and extremely difficult implementation of recovery mechanisms for invalidly used tickets can be avoided.
- a mobile device may further include receiving means for the user to select which ticket to be presented, especially if there are more than one ticket in the ticket storage. 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.
- An electronic ticket has a sealed state and a validated state, wherein the state of the electronic ticket is defined by the public part or private part of the electronic ticket, in such a manner that whenever the private part corresponds to a valid value, the ticket is in the validated state.
- Such an electronic ticket enables the delayed validation for a copy protected ticket.
- the valid value for private part corresponds to an identifier stored in security means of a mobile device.
- the ticket inspection system or the ticket issuing system can make sure that it is only a trusted client that is going to validate and/or to use the electronic ticket.
- FIG. 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.
- proximity detection means 802 are usually based on optical or magnetic sensors that detect which device is the closest in any given moment.
- 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 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 1 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.
- a passive component such as an RF tag.
- the proximity range may be adapted to show non-uniform directional characteristics, say that ⁇ R 1 ⁇ ⁇ R 2 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.
- FIG. 2A is a block diagram of a mobile device 102.
- 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.
- PDA Personal Digital Assistant
- laptop computer a laptop computer
- Portable Digital Wallet a Portable Digital Wallet
- PTD Personal Trusted Device
- 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.
- remote transportation means such as the mobile network 100A and the Internet 100B
- local transportation means such as BLUETOOTH and IrDA
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- the trusted agent 254 uses one or more dedicated key pairs which are initially solely employed for copy protection services.
- 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.
- 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.
- the parsing means 202 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.
- 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.
- 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.
- the ticket object 303 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.
- beacons such as sends as a Radio Frequency signal
- 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.
- the exemplary registry there are three registers 724A, 724B, and 724C.
- Each of registers 724A-C include TUID field 725 and nonce field 726.
- 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 numbers which have been generated by the trusted agent 254 responsive to a request M411 from the ticket application 200.
- the trusted agent 254 After generating the nonces 727A-727C the trusted agent 254 passes them as processed nonces 727A'-727C' to the ticket storage 230 and stores them unprocessed in its own registry 722 into registers 724A-724C and corresponding NONCE fields 726A-726C. 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.
- the different registers 724A-C in the registry 722 include also values in corresponding TUID fields 725A-C, respectively.
- processed nonce 727A' is the nonce 727A together with its digital signature.
- the ticket issuing system then returns the electronic ticket 300, the message including the ticket includes not only nonce 727A but also ticket unique identifier 702A.
- 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.
- the validating means 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.
- 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.
- the ticket application 200 marks the particular signed nonce used.
- FIGS 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.
- FIG 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.
- 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.
- 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.
- 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 a format that is more easily handled by current smart card technology.
- the security element information 701 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.
- 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.
- 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.
- issuer signature 708 i.e. a digital signature of the issuing system 101.
- 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:
- 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.
- 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.
- trusted agent 254 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.
- a 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.
- each nonce 727 is stored in a nonce field 726 of registers 724 of the registry 722. This has already been described in more detail with reference to Figures 2B and 2C.
- the copy of processed nonce 727 is processed to processed nonce 727' and stored together with other similarly processed nonces to form the processed nonces table 730.
- 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 727 with the trusted agent signature 709 to obtain a processed nonce 727'.
- step L115 processed nonces 727 are sent to the ticket storage 230 in message M403 and stored into processed nonces table 730.
- 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.
- 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 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.
- the ticket issuing system 101 verifies the signature of the processed nonce 727' 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.
- 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.
- 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.
- the TUID 702 should be the same as the TUID 702' inside ticket data 706.
- step K12 the processed nonce 727' is 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.
- 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.
- 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.
- the ticket issuing system 101 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 the nonce 704.
- 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.
- the user can choose to register the electronic ticket 300 with the trusted agent 254.
- 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.
- step L14 an electronic ticket 300 is selected.
- 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.
- step L15A a ticket validation request M505 is generated.
- the ticket application 200 sends the electronic ticket 300 in sealed form together with the issuer certificate to the trusted agent 254.
- the trusted agent performs in step L15B substeps L151 to L156.
- the trusted agent 254 decrypts ticket data 706' using its dedicated private key, and thus obtains the ticket data 706.
- 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.
- 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.
- 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.
- 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.
- step L156 the trusted agent 254 returns the private part 300PR to the ticket application 200 by sending it in the message M507.
- the ticket application 200 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.
- 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 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.
- 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.
- 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.
- step L17 the ticket application 200 displays the results of the search on the display 261.
- 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.
- 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.
- several substeps L191 to L195 are performed at the trusted agent 254 in step L19B.
- step L191 the trusted agent 254 compares its own trusted agent signature 709 with the ticket data 706 included in message M611.
- 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.
- 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.
- 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 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.
- 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.
- 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.
- 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.
- the ticket application 200 stores the new version of the electronic ticket 300 in the ticket storage 230 in message M615.
- 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.
- the ticket inspection system 106 verifies in step K15 that the ticket object 303 has not been tampered with.
- step K15 requires that the inspection system 106 performs the verification of the issuer signature 708 over the ticket object 303.
- 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.
- the inspection system 106 extracts from the ticket object 303 the value of TUID 702.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- step L22 the ticket application 200B requests processed nonces 727' stored in processed nonces table 730 that are available by sending a message M701 to ticket storage 230B.
- 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 processed nonce 727' is sent in a message M705 to another mobile device 102 which routes the message M705 to the ticket application 200.
- 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.
- the ticket application 200 stores the processed nonce 727' obtained in message M705 into the ticket storage 230 as well as the trusted agent 254B PKI certificate.
- the ticket application 200 allows via the U/I part 201 the user to give a user-defined label to processed nonce 727' to indicate its origin and/or future use (e.g. "Ticket4Lorena").
- 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.
- 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.
- 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' including values NONCE
- message M713 includes electronic tickets 300 in validated form, including TUID and NONCE'
- message M715 includes the trusted agent 254B PKI certificate.
- 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.
- step L24B In response to the receiving of message M717, in step L24B several substeps L241 to L248 are performed in the trusted agent 254.
- 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.
- step L242 the trusted agent 254 verifies its own trusted agent signature 709 over the ticket data 706.
- 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.
- 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.
- 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.
- 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".
- step L246 the trusted agent 254 updates the values of the nonce 704 and of the nonce field 726.
- the trusted agent 254 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.
- 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.
- 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.
- step L248 the trusted agent 254 signs the validated private part 300PR with its own trusted agent signature 709.
- 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.
- the ticket application 200 stores the private part 300PRB with the same user-defined label.
- 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, or 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 of the electronic ticket 300B.
- the user 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.
- the electronic ticket 300B in sealed state is sent to the other mobile device 102B in message M727.
- 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 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.
- 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.
- copy protection is relevant only on the context of double spending of the same ticket object 303.
- the copy protection is achieved by rendering useless copies of the ticket object 303 that are not validated by a trusted agent through a reliable and protected interface, such as by using private part of electronic ticket 300PR.
- the present invention is mainly but not exclusively meant for electronic tickets.
- data objects benefitting from such a high-level security copy-protection offered by the present invention, requring only little or even none modification.
- data objects belong medical prescriptions, legal documents, and even executable content.
- the presentation enviroment of the object can be either remote, local, or personal, as already discussed.
Abstract
Description
- The invention relates generally to electronic tickets or documents, and, more specifically, to generating, transferring, and presenting such tickets or documents.
- 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 itsfront end 1011. Mostticket issuing systems 101 include also aback end 1012 which performs the ticketing and stores a copy of issued tickets to adata storage 1013. When a ticket has been generated in the ticket issuingsystem 101, it is usually sent to apersonal computer 104 via the Internet 100B, or to somemobile device mobile network 100A, such as a GSM, GPRS, or UMTS network. - Tickets may be ordered directly from the
personal computer 104, or from themobile devices mobile device 102 and used by the user of a secondmobile 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 theinspection 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 theticket printer 105 which may also be connected to the Internet 100B obtains instructions from the ticket issuingsystem 101 relating to what kinds of tickets to accept.Ticket printer 105 may include similar functionalities to theinspection system 106. - Evidently, there is not yet any agreement about the future format of an electronic ticket. The solutions used by current vendors and already being available in the market seem not to be satisfactory in all aspects. Thus there still exists a need for a flexible and general ticket concept which provides the ticket issuers and users of the tickets with a high enough security level, and which is technically efficient to use whatever the final form of the electronic appearance of the electronic ticket will be.
- Especially the issuing of an electronic ticket has preferably to be fast, reliable and it should not consume too much air interface nor introduce too much disturbances into the air interface. An essential issue related to the issuing of such electronic tickets is that they need be validated. Problematic, in both technical and therefore also in economical terms, has turned out to be the structure of those means, preferably in the user device, which should take care of performing the validating procedure, for cardboard tickets is also known as stamping.
- All prior solutions except one proposed by Siemens require that there is an on-line connection between the ticket issuer and the secure element in the mobile device of the ticket user. The main reason for this is to establish an immediate link (or validation) between the secure element and the ticket, with a procedure that starts prior ticket delivery and usually concludes once the ticket is received in the device. On one hand, this kind of approach is very rigid because it relies on the availability of the secure element during the whole process of ticket request and delivery. Consequently, if the secure element is not available at a given moment of this process, the ticket will become useless since the validation of the ticket would not be completed. On the other hand, if the tickets are explictly and permantely linked to a given secure element after validation, then it remains a problem how the ticket can be transferred to be used in another device with another secure element (e.g. by another user). Finally, the on-line access to the secure element during the ticket request and delivery prohibits the possibility of asynchronous delivery modes, such as the Multimedia Messaging Service MMS, or using different delivery means, especially the Internet.
- The contribution by Siemens suggested that a real-time clock could be used to achieve delayed validation. This, however, has turned out to be technologically too complicated, as a secure real time clock located in the user device is at the moment too expensive to construct. So, it still remains as a problem how to delayed the validation of a given ticket with the secure element while keeping a high security level of copy protection of the ticket.
- It is an object of the invention to bring about a solution by means of which it is possible to obtain a reliable, efficient and flexible ticketing platform, electronic ticket, and/or device for using electronic tickets, and/or device for inspecting electronic tickets, in such a manner that the ticket validation, when high level of copy protection is required, can be implemented without too complex and difficult mechanism. Another objects are to provide solutions by means of which it is possible to transfer electronic tickets. Still another object of the invention is to bring about a novel electronic ticket model.
- 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 validating an electronic ticket includes i) receiving means for receiving an electronic ticket, the electronic ticket including a first identifier and a second identifier, ii) a ticket storage for storing the electronic ticket, iii) secure storing means for storing the first identifier, and iv) validating means adapted to store the first identifier to the secure storing means when the electronic ticket is validated. By using such a device a non-real-time validation of electronic tickets is enabled without an expensive and technically complicated real time clock. Further, during the validation procedure no continuous connection between the ticket issuing system and the device is needed.
- According to one aspect of the present invention, the device for validating an electronic ticket may further include security means for verifying the origin of the electronic ticket, preferably by decrypting at least a part of ticket containing said first and second identifiers, especially using a private key assigned to a trusted agent. Such an arrangement brings about an enhanced security. The issuer can now be authenticed, which makes the ticket application and ticket application system more harder to crack by malicious parties.
- According to one further aspect of the present invention, a device for presenting an electronic ticket includes presenting means for presenting the first identifier and the second identifier in order to use said electronic ticket. In such a manner the electronic ticket can be presented in a convenient manner, and copy protection can also be obtained. When the ticket application and/or security means are safe, then it can also be ensured that the electronic ticket cannot be presented multiple times if that is not allowed.
- According to a further aspect of the present invention the device for presenting an electronic ticket can further include means for verifying the identity of an entity to which the electronic ticket is going to be presented. Such an arrangement brings about an enhanced security. The ticket inspetion system or ticket printer can now be authenticed, which makes the ticket application and ticket application system more harder to crack by malicious parties.
- According to a further aspect of the present invention, a device for validating and/or presenting an electronic ticket can further include i) generation means adapted to generate at least one third identifier; and whereby the secure storing means are adapted to store the third identifier and/or the ticket storage is adapted to store the third identifier. Such an arrangement enables the use of multi-use tickets and serial tickets.
- A device for validating and/or presenting an electronic ticket can further include i) generation means adapted to generate a second identifier, ii) generation means adapted to generate a ticket issuing request including the second identifier generated and iii) sending means for sending the ticket issuing request to a ticket issuing system. If a request is generated in this manner, based on the identifier, the ticket issuing system can ensure that the electronic tickets oredered really are what the user or the device has been subscribing.
- A device for validating and/or presenting an electronic ticket can further includes means for changing the third identifier in the ticket storage and/or in the secure storing means in response to a change request, especially relating to said using or transfer of the electronic ticket, or in response to using the ticket, such as received from an entity to which the electronic ticket is presented. In such a manner serial tickets can be shared between users, one user can transfer his/her tickets to another user, and a user can ask another user to subscribe a copy-protected ticket on behalf of him/herself.
- A ticket issuing system or a device for issuing an electronic ticket includes includes generation means adapted to generate an electronic ticket responsive to a request including a first identifier and a second identifier, especially when the request has been generated by a device for validating an electronic ticket, and where the ticket includes a first identifier or an identifier derived therefrom. Such a ticket issuing system or device enables the operation of a ticket validation device, and by using such a system or device a delayed validation of copy-protected tickets can be obtained.
- A ticket issuing system or a device for issuing an electronic ticket can further include means for sealing the electronic ticket. This enhances the security of the electronic ticket, because the issuer can now ensure that only a trusted user is able to validate the ticket.
- A device for requesting the use of an electronic ticket includes generation means for generating a request for using an electronic ticket, the request including a refresh value for a second identifier of an electronic ticket. Such a device enables the use of copy-protected electronic tickets that have been validated not in real-time.
- A device for requesting the use of an electronic ticket may further include broadcasting means for broadcasting a product tag or other identifier describing ticket types supported by the device. So the ticket application can be advised to select only such tickets that are currently usable. In this manner, costly and extremely difficult implementation of recovery mechanisms for invalidly used tickets can be avoided.
- A mobile device may further include receiving means for the user to select which ticket to be presented, especially if there are more than one ticket in the ticket storage. 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.
- An electronic ticket has a sealed state and a validated state, wherein the state of the electronic ticket is defined by the public part or private part of the electronic ticket, in such a manner that whenever the private part corresponds to a valid value, the ticket is in the validated state. Such an electronic ticket enables the delayed validation for a copy protected ticket.
- The valid value for private part corresponds to an identifier stored in security means of a mobile device. In this way also the ticket inspection system or the ticket issuing system can make sure that it is only a trusted client that is going to validate and/or to use the electronic ticket.
- 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 theinspection 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.
- 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. Theinspection 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 theinspection system 106, to generate user-specific ticket presentation requests, and to verify the integrity and origin of the tickets presented by anymobile device - Broadcasting means 801 act in the proximity of the
inspection system 106, and transport messages including the value of aproduct tag 721 of a given ticket class. Theproduct tag 721, as will be explained below, identifies the required ticket to be presented to theinspection 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 anonce 704 of the private part 300PR inticket data 706. Comparison means 809 are used to compare thenonce 704 of the ticket with the nonces stored in thestorage 807. Verification means 810 are used to verify that the ticket data object 303 has not been tampered with, and for comparing the trustedagent signature 709 with theticket 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 theinspection system 106 are presented with an individual ticket presentation request REQ4 containing aproduct tag 721 and aunique nonce 704. The ticket presentation request REQ4 is presented to themobile 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 anelectronic ticket 300. - Figure 1C shows a user with a
mobile device 102 approaching theinspection system 106. The proximity range ΔR1 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 themobile 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 ΔR1 << ΔR2 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 106broadcasts product tag 721 which is then detected by themobile 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, themobile 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 themobile network 100A and theInternet 100B, as well as via local transportation means such as BLUETOOTH and IrDA, with theticket issuing system 101 and with theticket inspection system 106. - The
mobile device 102 includes input/output I/O means 260 which include receiving means 263, sending means 262, and adisplay 261. The receiving means 263 include means with which themobile device 102 can receive any data from amobile network 100A, from anothermobile device 103, from the user of themobile device 102, frominspection 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 aloudspeaker 264 and a RadioFrequency 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 themobile 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 themobile device 102, includes means for generation of random numbers, strong symmetric cryptography, and Public Key Infrastructure PKI cryptography. Regarding PKI, thesecurity 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 themobile device 102 is a mobile phone and the security means 250 further comprise asecurity 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 atrusted agent 254 whose purpose is to provide specific copy protection services involving the use of strong cryptography to different applications, and in particular theticket application 200, and thus interact through the latter with theticket issuing system 101,inspection system 106 and, further, even with a ticket application system 723' of a secondmobile device 103. - The copy protection services provided by the trusted
agent 254 may involve the use of PKI cryptography. In this case, the trustedagent 254 uses one or more dedicated key pairs which are initially solely employed for copy protection services. In addition, the trustedagent 254 has an access to aregistry 722, preferably inside thesecurity element 252. - A
ticket application system 723 comprisesticket application 200 preferably stored in themobile device 102, simple ticket security means 224, trusted agent 254 (preferably stored in a security element 252), anddedicated registry 722 preferably stored in asecurity element 252. The structure and use of theregistry 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 thesecurity element 252 is a smart card offering PKI services to theticket application 200 through the trustedagent 254 and that by using such services theticket application 200 achieves a high-level ticket security. - An
electronic ticket 300 received from theticket issuing system 101 is stored intoticket storage 230 which may be a database or memory including a register. Theticket storage 230 includestickets 729 and serves them to theticket application 200. Theticket storage 230 includes also processednonces 730 generated by the trustedagent 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 theticket issuing system 101. Secondly, the U/I part 201 notifies the user whenever anelectronic ticket 300 is received. The user may then have an opportunity to confirm the storing of anelectronic ticket 300 or to reject it. Thirdly, when the user is willing to use theelectronic 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 themobile device 102 further comprises parsing means 202, comparison means 204, generation means 206, and validatingmeans 280. - When an
electronic ticket 300, i.e. any one of thetickets 729 stored in theticket storage 230, is to be used, the parsing means 202 read the contents of theelectronic ticket 300. Because several components of theelectronic ticket 300 are implemented using an extensible Markup Language XML frame, the parsing means 202 can be adapted to detect a predefined keyword inside theelectronic ticket 300. This predefined keyword is preferably contained within theelement 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 thePTD 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 theticket 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, andRF tag 265, depending on the ticket type. The presenting means 260B present theticket object 303. Depending of the presenting means 260B selected, the presenting of theticket object 303 takes place by displaying it on the display 261 (for a barcode or an image), by playing it through a theloudspeaker 264 thus producing an aurally recognisable tone, by beaconing theticket object 303 i.e. storing theticket object 303 as a whole or only an ID refererring to the object into anRF tag 265 which then beacons (such as sends as a Radio Frequency signal) theticket object 303 when brough close enough to a check point, or in some other suitable way. - One possibility for presenting the
ticket object 303 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. theinspection system 106 or theticket printer - 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 includeTUID field 725 andnonce 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 numbers which have been generated by the trusted
agent 254 responsive to a request M411 from theticket application 200. After generating the nonces 727A-727C the trustedagent 254 passes them as processed nonces 727A'-727C' to theticket storage 230 and stores them unprocessed in itsown registry 722 into registers 724A-724C and corresponding NONCE fields 726A-726C. This is discussed in more detail with reference to Figure 4 below. The nonces 727A-727B can also be a URI generated by the trustedagent 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, theticket application 200 has sent a processed nonce 727A' to theticket issuing system 101, in this case processed nonce 727A' is the nonce 727A together with its digital signature. When the ticket issuing system then returns theelectronic ticket 300, the message including the ticket includes not only nonce 727A but also ticket unique identifier 702A. When theelectronic ticket 300 is then registered, i.e. validated, the value of TUID 702A is stored into TUID field 724A corresponding tononce field 726. - In a similar manner, for another
electronic ticket 300 which has another TUID 702B and nonce 727B, the validating means that the TUID field 725B in the register 724B of theregistry 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 anelectronic ticket 300. Alternatively, a nonce can be passed to anothermobile device 103, the anothermobile device 103 having a corresponding ticket application 200', for the anothermobile device 103 to request anelectronic ticket 300 on behalf of the trustedagent 254 of the firstmobile device 102. - When a signed nonce is either used to request a
ticket 300, or transferred to anothermobile device 103 through any of the available sending means 262 of themobile device 102, theticket 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. Theelectronic ticket 300 includesuser information 301 andticket 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 theticket application system 723, namely; (a) theticket application 200 preferably stored in themobile device 102, and (b) the trustedagent 254 that is preferably stored insecurity element 252, and where the latter might either be an integrated or detachable component to themobile device 102. Thus, the corresponding interfaces inside theticket application information 302 are thePTD information 703, and thesecurity element information 701. - The
PTD information 703 further comprises at least some of the following:product tag 721,presentation information 705,security information 707, andticket object 303. -
Product tag 721 indicates the type of ticket to theticket application 200. The purpose of this tag is to allow a fast search in theticket storage 230 for a given ticket product marked withproduct tag 721. In the case that there are several tickets among thetickets 729 matching the searching criteria, the user will be requested to choose which one should be presented to theinspection system 106. -
Presentation information 705 indicates to theticket application 200 which presenting means 260B of themobile device 102 is preferably to be used for presenting theticket data object 303. -
Security information 707 indicates the security requirements to theticket application 200 in regard of theticket data object 303. These requirements need not be performed by thesecurity element 252, and thus can be implemented by the simple ticket security means 224. -
Ticket object 303 is presented by theticketing applicaton 200 to theinspection 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, theticket object 303 has to include a ticketunique identifier TUID 702. Further, the ticketunique identifier 702 should be identical to that stored in thesecurity 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 theissuing 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 theticket object 303. - A trusted
agent 254 can be used to protect theticket object 303 against illegal duplication and double expending. This provides a high level of security, especially when the trustedagent 254 is located inside thesecurity element 252. Thesecurity element information 701 includes information necessary for the trustedagent 254. Thesecurity element information 701 can further include any of the following subelements: i) ticketunique identifier 702 , ii)nonce 704, iii) N ofuses 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 theticket object 303.Nonce 704 corresponds to a version control identifier. Thesignature element 731 contains the issuer signature 708' of the security element information 701 (excluding the signature itself) for anelectronic ticket 300 in sealed state. When theelectronic ticket 300 is registered with the trusted agent and the ticket is in so-called validated state, the signature element contains the trustedagent signature 709 of the security element information 701 (excluding the signature itself). -
Ticket value data 720 is the "ticket value" information within theticket 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 theelectronic ticket 300. This is particularly useful when the value of the service for which theelectronic 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 theelectronic ticket 300 are a part of an XML document, except for thesecurity element information 701. This latter information, likewise theticket object 303 itself, can be referred to or otherwise embedded in the XML document part, such as in theticket application information 302. Consequently, thesecurity element information 701 can have a 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 thesecurity element information 701, the latter can implicitly be linked to a giventrusted agent 254, located in aparticular security element 252. Furthermore, both items,ticket object 303 andsecurity element information 701, are preferably presented during ticket use to theinspection 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 theissuer signature 708, i.e. a digital signature of theissuing system 101. In the private part 300PR there are two cases; when theelectronic 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 trustedagent 254 is achieved by means of the verifying the issuer signature 708' of theissuing system 101. If theelectronic ticket 300 is in the validated state, the authentication of the correspoing data (i.e. security element information 701) is performed by either the trustedagent 254, or theinspection system 106, and it involves the verification of the trustedagent 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 theelectronic 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 bytrusted agent 254 responsive to message M401 which is generated in preparation step L10 by theticket application 200. - Responsive to the receiving of
message 401, to trustedagent 254 initiates processes described in step L11 for generating nonces. In step L11 the trustedagent 254 performs substeps L112-L116. - In step L112 a 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 nonce 727 is stored in a
nonce field 726 ofregisters 724 of theregistry 722. This has already been described in more detail with reference to Figures 2B and 2C. The copy of processednonce 727 is processed to processed nonce 727' and stored together with other similarly processed nonces to form the 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 trustedagent 254. This can be done by signing each nonce 727 with the trustedagent signature 709 to obtain a processed nonce 727'. - In step L115 processed
nonces 727 are sent to theticket 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 theticket 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 theticket issuing system 101. Theticket application 200 accesses the area of theticket storage 230 where the processed nonces 727' are stored by sending a message M407 toticket 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 trustedagend 254. Then theticket application 200 uses available sending means 262 for sending request M411 to theticket 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 theticket 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 theticket issuing system 101 verifies the signature of the processed nonce 727' included in message M411 by using the public key of the trustedagent 254 included in the trustedagent 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 theticket issuing system 101 can find the correct certificate in theInternet 100B or elsewhere. - In step K12 the
ticket issuing system 101 generates anelectronic ticket 300. Aticket product tag 721 is included inside theelement 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 theelement PTD information 703 to theticket object 303. Theticket object 303 may include, in any way acceptable by parsing means 811 of theticket inspection system 106,TUID 702. In practice, theTUID 702 should be the same as the TUID 702' insideticket data 706. - Further, in step K12 the processed nonce 727' is stored among processed nonces table 730 that was provided by the
ticket application 200 in M411 is verified by theticket issuing system 101. Then the copy ofnonce 727 is written inside theticket data 706 i.e. into thefield nonce 704 as shown in Figure 3B. - In step K13 the
ticket issuing system 101 seals theelectronic ticket 300. This was illustrated in more detail in Figure 3B by defining public part 300PU and private part 300PR for theelectronic ticket 300. - Further, in step K13 the
ticket issuing system 101 signs the private part 300PR withissuer signature 708 and encrypts theticket data 706 with the public key of the trustedagent 254, thus generating theticket data 706. - The
ticket issuing system 101 can embed the private part 300PR inside theticket application information 302 of theelectronic ticket 300, or it can insert a link intoticket 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 theticket application 200, i.e. to themobile device 102. Themobile device 102 using its receiving means 263 passes the message M413 to theticket application 200, for example, by notifying a suitable port daemon. - The
ticket application 200 receives message M413 including anelectronic ticket 300 in sealed state. The message M413 comprises at least some of the following:product tag 721, ticketunique identifier 702, and a value for thenonce 704. After receiving the message M413, theticket application 200 indicates the reception of theelectronic ticket 300 to the user by the use of input/output means 260. The user can then choose whether to accept or discard theelectronic ticket 300. If the user accepts the ticket, theticket application 200 in step L13 stores theelectronic ticket 300 in sealed form ticket by sending the message M415 to theticket 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 theelectronic ticket 300 with the trustedagent 254. According to the present invention, a delayed validation of theelectronic 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 theticket application 200 or themobile device 102 in order to access theticket storage 230 and select anelectronic ticket 300 which is in sealed state. The ticket application send message M501 toticket storage 230 which returns returns theelectronic 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 theticket application 200 sends theelectronic ticket 300 in sealed form together with the issuer certificate to the trustedagent 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 trustedagent 254 decrypts ticket data 706' using its dedicated private key, and thus obtains theticket data 706. Further, in step L152 the trustedagent 254 compares the issuer signature 708' with theticket data 706. If the comparison result shows that the issuer signature 708' does not match with theticket 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 theticket data 706, with the available nonces inside theregistry 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 theTUID field 725 corresponding to thenonce field 726 containing the matching value ofnonce 704. - In step L155 the trusted
agent 254signs ticket data 706 with its owntrusted 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 theticket application 200 by sending it in the message M507. - In response to receiving the message M507, the
ticket application 200 sends theelectronic ticket 300 in validated state to theticket 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 theticket application 200. The message M601 includesproduct tag 721 for the service that is being offered through theticket inspection system 106, and a new value NONCE'' for thenonce 704. Theticket inspection system 106 stores a copy of the new value NONCE'' for the nonce 704 instorage 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 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 betweenmobile 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, theticket application 200 searches in step L16 through theticket storage 230 for tickets matching theproduct tag 721 included in the message M601 by sending a message M603. More precisely, the searching is performed in thefield product tag 721 of thetickets 300 as described in Figure 3A. If among thetickets 729 there are any or some ticketelectronic ticket 300 corresponding to thefield product tag 721 contained in message M601, theticket storage 230 returns the TUID of them in message M605. - In step L17, the
ticket application 200 displays the results of the search on thedisplay 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. Theticket application 200 communicates the selection by sending message M607 to theticket storage 230 which in message M609 returns the TUID and NONCE' of theelectronic ticket 300 which is in validated state, i.e. it has been registered with the trustedagent 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 selectedelectronic ticket 300 in validated state. In response to receiving message M611, several substeps L191 to L195 are performed at the trustedagent 254 in step L19B. - In step L191 the trusted
agent 254 compares its owntrusted agent signature 709 with theticket data 706 included in message M611. In step L192 the trusted agent searches in theregistry 722 theindividual registers 724 until it finds onesuch register 724 for whichist TUID field 725 includes a matching value for theTUID 702 in theticket data 706. - When an
adequate register 724 is found, the trustedagent 254 compares the values of thenonce 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 theelectronic ticket 300 in validated state presented to the trustedagent 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 trustedagent 254 updates the N ofuses 711 to correspond to number of uses left. This can be done by changing theticket 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 theinspection system 106 the values of the nonce fields of: i) in theticket data 706, thenonce 704; and ii) in thecorresponding register 724 thecorresponding nonce 727 innonce field 726. This is thecorresponding register 724 to theTUID field 725 containing a matching value to the value contained in the TUID 702' of theticket 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 trustedagent 254 removes from theregistry 722 theregister 724 theTUID field 725 of which contains a value matching with the TUID 702' in theticket data 706. - In step L195 the trusted
agent 254 signs the newly modified private part 300PR validated, and returns it to theticket application 200 in message M613. - At the last part of step L19A, the
ticket application 200 stores the new version of theelectronic ticket 300 in theticket storage 230 in message M615. - In step L20 the
ticket application 200 creates message M617 including thecorresponding ticket object 303, of thePTD information 703 of theelectronic 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 theinspection system 106. - Figure 6B illustrates a scenario of using an
electronic ticket 300, or how anelectronic 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, theticket inspection system 106 verifies in step K15 that theticket object 303 has not been tampered with. - If the selected verification method is that the
ticket object 303 has been digitally signed with theissuer signature 708, the execution of step K15 requires that theinspection system 106 performs the verification of theissuer signature 708 over theticket object 303. Hence, theinspection system 106 needs to have prior access to theticket issuing system 101 PKI certificate. It is assumed that theinspection system 106 already has this information, and thus themobile device 102 does not need to provide it. Preferably, theinspection system 106 extracts from theticket object 303 the value ofTUID 702. - In step K16 the
inspection system 106 verifies the trustedagent signature 709 by comparing it with theticket data 706. For this purpose it uses the trustedagent 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 withticket data 706, i.e. that the step K16 was successful, theinspection system 106 compares thenonce 704 of the private part 300PR inticket data 706 with the copy of the new nonce NONCE'' sent to theticket 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, instorage 807 of theinspection system 106. - In step K18, if the result of step K17 shows that step K17 was successful, i.e. if the
nonce 704 of theticket data 706 matches with the copy of the new nonce sent to theticket application 200, theinspection system 106 compares theTUID 702 of theticket 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 theticket application 200. This confirmation message M621 preferably contains a time stamp and an ticket product tag. Then the confirmation message M621 is sent from theticket inspection system 106 to theticket 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 theticket 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, theticket application 200 saves it into theticket storage 230. - Figure 7 shows a scenario of transferring an
electronic ticket 300, the transferring including also steps for ticket verification. A user with amobile device 102B requests the user with amobile device 102 to transfer a given number of ticket units of a given multiple use ticket to thedevice 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 727' stored in processed nonces table 730 that are available by sending a message M701 toticket storage 230B. In response to message M701, at least one non-used processed nonce 727' having a value NONCE'' is received from theticket storage 230B in message M703. The processed nonce 727' is sent in a message M705 to anothermobile device 102 which routes the message M705 to theticket 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 theticket storage 230B used. - In step L23 the
ticket application 200 stores the processed nonce 727' obtained in message M705 into theticket storage 230 as well as the trusted agent 254B PKI certificate. Preferably, theticket application 200 allows via the U/I part 201 the user to give a user-defined label to processed 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 theticket storage 230 in order to achieve a better user experience. Furthermore, theticket application 200 establishes a reference link between this signednonce 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 theticket 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) theelectronic 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 toticket storage 230 which then in messages M711 to M715 responds to the message M709. Message M711 includes processed nonces 727' including values NONCE", message M713 includeselectronic 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 trustedagent 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 owntrusted agent signature 709 over theticket data 706. In step L243, if the results of steps L241 and L242 have been successful, the trustedagent 254 searches in theregistry 722 through theindividual registers 724 until it finds the one theTUID field 725 of which contains a matching value for the TUID 702' in theticket data 706. - When an
adequate register 724 is found, the trustedagent 254 compares the values of thenonce field 726 withnonce 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 trustedagent 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' ofticket 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 ofuses 711 with the new value inticket 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 thenonce 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 inticket data 706 and the correspondingnonce field 726 in theregistry 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 theregistry 722 thecorresponding register 724 whoseTUID field 725 contains a matching value for the TUID 702' in theticket data 706. - In step L247 the trusted
agent 254 seals private part 300PRB by signing it with its owntrusted 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 owntrusted 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 theticket application 200 which stores the tickets in the corresponding compartments in theticket 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 theticket 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, or 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 of the electronic ticket 300B. - 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 theticket storage 230 by sending message M723 and receiving it in message M725. Then the electronic ticket 300B in sealed state is sent to the othermobile 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, theticket 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, theticket application 200B stores the sealed ticket in theticket 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 themobile device 102 itself. This personal presentation environment can be an element permanently integrated by software, hardware, or both in themobile 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 theticket object 303 that are not validated by a trusted agent through a reliable and protected interface, such as by using 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.
-
- 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
- ΔR1, ΔR2
- proximity range of
inspection system 106
Claims (27)
- A device for validating an electronic ticket, 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 the second identifier (NONCE'); andvalidating means (280) adapted to store the first identifier (TUID1) to the secure storing means (252) when the electronic ticket (300) is validated.
- A device according to claim 1, characterised in that it further includes security means (250) for verifying the origin of the electronic ticket (300), preferably by verifying a digital signature in at least a part of ticket (300PR) including said first and second identifiers (TUID1, NONCE'), especially using a private key assigned to a trusted agent (254).
- A device according to claim 2, wherein: the security means (250) are adapted to decrypt a ticket part (303) containing said first and second identifiers (TUID, NONCE).
- A device for presenting an electronic ticket (300), especially a device according to any one of claims 1, 2, or 3, characterised in that it includes: presenting means (260B) for presenting the first identifier (TUID1), the second identifier (NONCE'), and a ticket object (303) in order to use said electronic ticket (300).
- A device according to claim 4, characterised in that: the device includes means (204) for verifying the identity of an entity (106, 105) to which the electronic ticket is going to be presented.
- A device according to any one of the preceding claims, characterised in that the device further includes: means (254) for changing a third identifier (711) in the ticket data (706) in response to a change request (M601), especially relating to said using or transfer of the electronic ticket, or in response to using the ticket, such as received from an entity (105, 106) to which the electronic ticket (300) is presented.
- A device according to any one of the preceding claims, characterised in that the device further includes:generation means (206) adapted to generate a second identifier (727);generation means (206) adapted to generate a ticket issuing request (M411) including the processed second identifier (727') generated; andsending means (262) for sending the ticket issuing request (M411) to a ticket issuing system (101).
- A device according to claim 7, wherein: the ticket issuing request (M411) further includes an agent certificate (709).
- A device according to any one of claims 6 to 8, wherein: the ticket storage (230) and/or the secure storing means (252) are adapted to store a new second identifier (NONCE') received from an entity (105, 106) to which the electronic ticket (300) is presented.
- A device according to claim any one of the preceding claims, wherein: the device includes security means (252) adapted to sign the second identifier (NONCE') with an agent private key (709) prior to sending the electronic ticket issuing request by the sending means (262).
- A device according to any one of claims 1-10, wherein: the second identifier (NONCE', NONCE'') is stored in the secure storing means (252), and the processed second identifier (727') is stored in the ticket storage (230).
- 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) responsive to a request (M411), the request (M411) including a first identifier (TUID1) and a second identifier (NONCE'), especially when the request (M411) has been generated by a device (102) according to any one of the previous claims; and where the electronic ticket (300) includes a first identifier (NONCE') or an identifier derived therefrom.
- A system or device according to claim 12, wherein: the system or device includes means (1012) for sealing the ticket (300).
- A device (105, 106) for requesting the use of an electronic ticket (300), wherein the improvement comprises: the device 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 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 method for validating an electronic ticket, characterised in that it includes the steps of:receiving an electronic ticket (300), the electronic ticket (300) including a first identifier (TUID) and a second identifier (NONCE');storing the electronic ticket (300);storing the first identifier (TUID1); andstoring the first identifier (TUID1) to secure storing means (252) when the electronic ticket (300) is validated.
- A method for presenting an electronic ticket (300), especially in connection with the method of claim 19, characterised in that it includes the step of: presenting the first identifier (TUID1) and the second identifier (NONCE') in order to use said electronic ticket (300).
- A method for issuing an electronic ticket (300), comprising the step of: generating an electronic ticket (300) responsive to a request (M411) including a first identifier (TUID1) and a second identifier (NONCE'), especially when the request (M411) has been generated using a method according to any one of the previous claims; and where the electronic ticket (300) includes a first identifier (NONCE') or an identifier derived therefrom.
- A method for requesting the use of an electronic ticket (300), comprising the step if: generating a request (M601) for using an electronic ticket (300), the request (M601) including a refresh value (NONCE'') for a second identifier (727) of said electronic ticket (300).
- A method according to claim 19, further comprising the step of: presenting a product tag (704) as a response of detecting a mobile device by the proximity detection means (802).
- A method according to claim 19 or 20, further comprising the step of: in response to detecting a mobile device by the proximity detection means (802), presenting a request (M601) for using an electronic ticket (300).
- A mobile device, especially a mobile phone, wherein: a device or method according to any one of the preceding claims is used.
- A mobile device according to claim 22, wherein: the mobile device includes a ticket application (200) or ticketing means (814).
- A mobile device according to claim 23, wherein: the ticket application (200) or ticketing means (814) comprises software code programmed in a symbolic language, especially using any JAVA compiler.
- A mobile device according to claim 24, wherein: the software code shares object classes between functionalities for ticket transferring and ticket issuing request, especially JAVA classes.
- An electronic ticket (300) having a sealed state and a validated state, wherein the state of the electronic ticket (300) is defined by the public part (300PU) or 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 26, wherein: the valid value for private part (300PR) corresponds to an identifier (704) stored in security means (250) of a mobile device.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP03001026.8A EP1439495B1 (en) | 2003-01-17 | 2003-01-17 | Device for ordering and validating an electronic ticket |
PCT/EP2004/000350 WO2004066218A1 (en) | 2003-01-17 | 2004-01-19 | A device for ordering and validating an electronic ticket, a ticket issuing system, and an electronic ticket |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP03001026.8A EP1439495B1 (en) | 2003-01-17 | 2003-01-17 | Device for ordering and validating an electronic ticket |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1439495A1 true EP1439495A1 (en) | 2004-07-21 |
EP1439495B1 EP1439495B1 (en) | 2019-04-17 |
Family
ID=32524153
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP03001026.8A Expired - Lifetime EP1439495B1 (en) | 2003-01-17 | 2003-01-17 | Device for ordering and validating an electronic ticket |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP1439495B1 (en) |
WO (1) | WO2004066218A1 (en) |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6986040B1 (en) * | 2000-11-03 | 2006-01-10 | Citrix Systems, Inc. | System and method of exploiting the security of a secure communication channel to secure a non-secure communication channel |
EP1752928A1 (en) * | 2005-07-28 | 2007-02-14 | Inventio Ag | Access control method for an area accessible to persons, in particular for a room closed off by means of a door |
JP2007087370A (en) * | 2005-07-28 | 2007-04-05 | Inventio Ag | Method of controlling access to area accessible to person, particularly to space closed by door |
WO2007132056A1 (en) * | 2006-05-15 | 2007-11-22 | Teliasonera Finland Oyj | Method and system for loading value to a smartcard |
EP2118856A1 (en) * | 2007-02-09 | 2009-11-18 | Ytv Pääkaupunkiseudun Yhteistyövaltuuskunta | Method, ticket handling apparatus, computer program product and product platform for a security mechanism of an electronic ticket |
US8102799B2 (en) | 2006-10-16 | 2012-01-24 | Assa Abloy Hospitality, Inc. | Centralized wireless network for multi-room large properties |
DE102012101420A1 (en) * | 2012-02-22 | 2013-08-22 | Capinvision AG | System for automatically sending message to mobile radio unit through cellular network, has detection device to detect passage of input by user of mobile radio unit and to transmit trigger signal |
WO2013124499A1 (en) * | 2012-02-22 | 2013-08-29 | UNIVERSlTAT ROVIRA I VIRGILI | Method for carrying out transactions with digital banknotes |
US8543813B2 (en) | 2009-09-29 | 2013-09-24 | International Business Machines Corporation | Method and apparatus to implement valid mobile ticket transfer |
FR3037754A1 (en) * | 2015-06-22 | 2016-12-23 | Orange | SECURE MANAGEMENT OF ELECTRONIC TOKENS IN A MOBILE TELEPHONE |
EP3174014A1 (en) * | 2015-11-30 | 2017-05-31 | NCR Corporation | Location-based ticket-redemption |
EP3189485A1 (en) * | 2014-09-02 | 2017-07-12 | Orange | Electronic ticket management |
US9792604B2 (en) | 2014-12-19 | 2017-10-17 | moovel North Americ, LLC | Method and system for dynamically interactive visually validated mobile ticketing |
US9881433B2 (en) | 2011-03-11 | 2018-01-30 | Bytemark, Inc. | Systems and methods for electronic ticket validation using proximity detection |
US9881260B2 (en) | 2012-10-03 | 2018-01-30 | Moovel North America, Llc | Mobile ticketing |
US10001791B2 (en) | 2012-07-27 | 2018-06-19 | Assa Abloy Ab | Setback controls based on out-of-room presence information obtained from mobile devices |
US10050948B2 (en) | 2012-07-27 | 2018-08-14 | Assa Abloy Ab | Presence-based credential updating |
US10089606B2 (en) | 2011-02-11 | 2018-10-02 | Bytemark, Inc. | System and method for trusted mobile device payment |
US10346764B2 (en) | 2011-03-11 | 2019-07-09 | Bytemark, Inc. | Method and system for distributing electronic tickets with visual display for verification |
US10360567B2 (en) | 2011-03-11 | 2019-07-23 | Bytemark, Inc. | Method and system for distributing electronic tickets with data integrity checking |
US10375573B2 (en) | 2015-08-17 | 2019-08-06 | Bytemark, Inc. | Short range wireless translation methods and systems for hands-free fare validation |
US10453067B2 (en) | 2011-03-11 | 2019-10-22 | Bytemark, Inc. | Short range wireless translation methods and systems for hands-free fare validation |
US10937251B2 (en) | 2016-05-18 | 2021-03-02 | Tixserve Limited | Electronic ticketing system |
EP3704610A4 (en) * | 2017-03-23 | 2021-07-21 | Moovel North America, LLC | Systems and methods of providing and validating digital tickets |
US11556863B2 (en) | 2011-05-18 | 2023-01-17 | Bytemark, Inc. | Method and system for distributing electronic tickets with visual display for verification |
US11803784B2 (en) | 2015-08-17 | 2023-10-31 | Siemens Mobility, Inc. | Sensor fusion for transit applications |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5569897A (en) * | 1994-01-26 | 1996-10-29 | Nippon Shinpan Co., Ltd. | Credit card system and method of issuing credit card using such a system |
EP0823694A1 (en) * | 1996-08-09 | 1998-02-11 | Koninklijke KPN N.V. | Tickets stored in smart cards |
GB2317790A (en) * | 1996-09-26 | 1998-04-01 | Richard Billingsley | Electronic money transactions |
EP0980052A2 (en) * | 1998-08-12 | 2000-02-16 | Nippon Telegraph and Telephone Corporation | Recording medium with electronic ticket definitions recorded thereon and electronic ticket processing methods and apparatuses |
EP1065637A2 (en) * | 1999-06-28 | 2001-01-03 | Hitachi, Ltd. | Ticket transfer program, method, system, and program medium |
EP1150228A1 (en) * | 2000-04-28 | 2001-10-31 | Fournir Limited | A method of distributing redeemeable vouchers to targeted customers |
US6493550B1 (en) * | 1998-11-20 | 2002-12-10 | Ericsson Inc. | System proximity detection by mobile stations |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7114178B2 (en) * | 2001-05-22 | 2006-09-26 | Ericsson Inc. | Security system |
-
2003
- 2003-01-17 EP EP03001026.8A patent/EP1439495B1/en not_active Expired - Lifetime
-
2004
- 2004-01-19 WO PCT/EP2004/000350 patent/WO2004066218A1/en active Application Filing
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5569897A (en) * | 1994-01-26 | 1996-10-29 | Nippon Shinpan Co., Ltd. | Credit card system and method of issuing credit card using such a system |
EP0823694A1 (en) * | 1996-08-09 | 1998-02-11 | Koninklijke KPN N.V. | Tickets stored in smart cards |
GB2317790A (en) * | 1996-09-26 | 1998-04-01 | Richard Billingsley | Electronic money transactions |
EP0980052A2 (en) * | 1998-08-12 | 2000-02-16 | Nippon Telegraph and Telephone Corporation | Recording medium with electronic ticket definitions recorded thereon and electronic ticket processing methods and apparatuses |
US6493550B1 (en) * | 1998-11-20 | 2002-12-10 | Ericsson Inc. | System proximity detection by mobile stations |
EP1065637A2 (en) * | 1999-06-28 | 2001-01-03 | Hitachi, Ltd. | Ticket transfer program, method, system, and program medium |
EP1150228A1 (en) * | 2000-04-28 | 2001-10-31 | Fournir Limited | A method of distributing redeemeable vouchers to targeted customers |
Cited By (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6986040B1 (en) * | 2000-11-03 | 2006-01-10 | Citrix Systems, Inc. | System and method of exploiting the security of a secure communication channel to secure a non-secure communication channel |
EP1752928A1 (en) * | 2005-07-28 | 2007-02-14 | Inventio Ag | Access control method for an area accessible to persons, in particular for a room closed off by means of a door |
JP2007087370A (en) * | 2005-07-28 | 2007-04-05 | Inventio Ag | Method of controlling access to area accessible to person, particularly to space closed by door |
US7796012B2 (en) | 2005-07-28 | 2010-09-14 | Inventio Ag | Method of controlling access to an area accessible by persons, particularly to a space closed by a door |
WO2007132056A1 (en) * | 2006-05-15 | 2007-11-22 | Teliasonera Finland Oyj | Method and system for loading value to a smartcard |
US8102799B2 (en) | 2006-10-16 | 2012-01-24 | Assa Abloy Hospitality, Inc. | Centralized wireless network for multi-room large properties |
EP2118856A1 (en) * | 2007-02-09 | 2009-11-18 | Ytv Pääkaupunkiseudun Yhteistyövaltuuskunta | Method, ticket handling apparatus, computer program product and product platform for a security mechanism of an electronic ticket |
EP2118856A4 (en) * | 2007-02-09 | 2011-03-02 | Hsl Helsingin Seudun Liikenne | Method, ticket handling apparatus, computer program product and product platform for a security mechanism of an electronic ticket |
US8543813B2 (en) | 2009-09-29 | 2013-09-24 | International Business Machines Corporation | Method and apparatus to implement valid mobile ticket transfer |
US10089606B2 (en) | 2011-02-11 | 2018-10-02 | Bytemark, Inc. | System and method for trusted mobile device payment |
US10453067B2 (en) | 2011-03-11 | 2019-10-22 | Bytemark, Inc. | Short range wireless translation methods and systems for hands-free fare validation |
US10346764B2 (en) | 2011-03-11 | 2019-07-09 | Bytemark, Inc. | Method and system for distributing electronic tickets with visual display for verification |
US10360567B2 (en) | 2011-03-11 | 2019-07-23 | Bytemark, Inc. | Method and system for distributing electronic tickets with data integrity checking |
US9881433B2 (en) | 2011-03-11 | 2018-01-30 | Bytemark, Inc. | Systems and methods for electronic ticket validation using proximity detection |
US11556863B2 (en) | 2011-05-18 | 2023-01-17 | Bytemark, Inc. | Method and system for distributing electronic tickets with visual display for verification |
DE102012101420A1 (en) * | 2012-02-22 | 2013-08-22 | Capinvision AG | System for automatically sending message to mobile radio unit through cellular network, has detection device to detect passage of input by user of mobile radio unit and to transmit trigger signal |
WO2013124499A1 (en) * | 2012-02-22 | 2013-08-29 | UNIVERSlTAT ROVIRA I VIRGILI | Method for carrying out transactions with digital banknotes |
US10606290B2 (en) | 2012-07-27 | 2020-03-31 | Assa Abloy Ab | Controlling an operating condition of a thermostat |
US10001791B2 (en) | 2012-07-27 | 2018-06-19 | Assa Abloy Ab | Setback controls based on out-of-room presence information obtained from mobile devices |
US10050948B2 (en) | 2012-07-27 | 2018-08-14 | Assa Abloy Ab | Presence-based credential updating |
US9881260B2 (en) | 2012-10-03 | 2018-01-30 | Moovel North America, Llc | Mobile ticketing |
US10762733B2 (en) | 2013-09-26 | 2020-09-01 | Bytemark, Inc. | Method and system for electronic ticket validation using proximity detection |
EP3189485A1 (en) * | 2014-09-02 | 2017-07-12 | Orange | Electronic ticket management |
US9792604B2 (en) | 2014-12-19 | 2017-10-17 | moovel North Americ, LLC | Method and system for dynamically interactive visually validated mobile ticketing |
WO2016207715A1 (en) * | 2015-06-22 | 2016-12-29 | Orange | Secure management of electronic tokens in a cell phone |
FR3037754A1 (en) * | 2015-06-22 | 2016-12-23 | Orange | SECURE MANAGEMENT OF ELECTRONIC TOKENS IN A MOBILE TELEPHONE |
US10375573B2 (en) | 2015-08-17 | 2019-08-06 | Bytemark, Inc. | Short range wireless translation methods and systems for hands-free fare validation |
US11323881B2 (en) | 2015-08-17 | 2022-05-03 | Bytemark Inc. | Short range wireless translation methods and systems for hands-free fare validation |
US11803784B2 (en) | 2015-08-17 | 2023-10-31 | Siemens Mobility, Inc. | Sensor fusion for transit applications |
EP3174014A1 (en) * | 2015-11-30 | 2017-05-31 | NCR Corporation | Location-based ticket-redemption |
US10990905B2 (en) | 2015-11-30 | 2021-04-27 | Ncr Corporation | Location-based ticket redemption |
US10937251B2 (en) | 2016-05-18 | 2021-03-02 | Tixserve Limited | Electronic ticketing system |
EP3704610A4 (en) * | 2017-03-23 | 2021-07-21 | Moovel North America, LLC | Systems and methods of providing and validating digital tickets |
Also Published As
Publication number | Publication date |
---|---|
EP1439495B1 (en) | 2019-04-17 |
WO2004066218A1 (en) | 2004-08-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1439495B1 (en) | Device for ordering and validating an electronic ticket | |
JP6768960B2 (en) | 2D barcode processing methods, devices, and systems | |
CN103155513B (en) | Accelerate the method and apparatus of certification | |
US10402784B2 (en) | Dynamic notary system | |
US8213614B2 (en) | Distribution and printing of travel documents | |
US20140351596A1 (en) | Method, system and apparatus for authenticating user identity | |
US20160043867A1 (en) | A qualified electronic signature system, method and mobile processing terminal for qualified electronic signature | |
US20070094152A1 (en) | Secure electronic transaction authentication enhanced with RFID | |
CN106452756A (en) | Construction verification method and device capable of verifying security two-dimensional code offline | |
US8186586B2 (en) | System, method, and apparatus for smart card pin management via an unconnected reader | |
US20130126619A1 (en) | Method and system for certifying contact information | |
EP2587421A1 (en) | Securely delivering and verifying a mobile boarding pass | |
WO2007012085A2 (en) | Mobile electronic transaction system | |
JP2004258738A (en) | Method of controlling file for settlement, server therefor, and settling program for personal digital assistant | |
US20100308110A1 (en) | Smart card pin management via an unconnected reader | |
JP4588529B2 (en) | Service system and optimum service providing method | |
US20140074578A1 (en) | Method and system for activating and validating coupons | |
JP4540454B2 (en) | Application setting device, IC chip and program | |
CN110942301B (en) | Data processing method and device based on block chain, computer and storage medium | |
CN107403319B (en) | Secure exchange of sensitive data over a network based on bar codes and tokens | |
EP1439498A1 (en) | Electronic ticket, device for issuing electronic tickets, and devices for using and performing operations on electronic tickets | |
JP2010238257A (en) | Purchase management server device and program thereof, purchase management system, and purchase management method | |
CN110728386A (en) | Information verification method and device and computer equipment | |
CN109544131A (en) | A kind of game merchandise control method and device | |
WO2022224780A1 (en) | Information processing device, information processing system, and method, and program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20040202 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO |
|
AKX | Designation fees paid |
Designated state(s): AT BE BG |
|
RBV | Designated contracting states (corrected) |
Designated state(s): DE FR GB |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: 8566 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: BENQ MOBILE GMBH & CO. OHG |
|
19U | Interruption of proceedings before grant |
Effective date: 20070101 |
|
19W | Proceedings resumed before grant after interruption of proceedings |
Effective date: 20070702 |
|
19W | Proceedings resumed before grant after interruption of proceedings |
Effective date: 20100201 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: PALM, INC. |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. |
|
17Q | First examination report despatched |
Effective date: 20110928 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: QUALCOMM INCORPORATED |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
INTG | Intention to grant announced |
Effective date: 20181119 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G07B 15/00 20110101AFI20030731BHEP Ipc: G07C 9/00 20060101ALI20030731BHEP |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): DE FR GB |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 60351949 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 60351949 Country of ref document: DE |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
26N | No opposition filed |
Effective date: 20200120 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20201231 Year of fee payment: 19 Ref country code: FR Payment date: 20201223 Year of fee payment: 19 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20201218 Year of fee payment: 19 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R119 Ref document number: 60351949 Country of ref document: DE |
|
GBPC | Gb: european patent ceased through non-payment of renewal fee |
Effective date: 20220117 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GB Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20220117 Ref country code: DE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20220802 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20220131 |