EP1439495B1 - Dispositif de commande et de validation d'un ticket électronique - Google Patents

Dispositif de commande et de validation d'un ticket électronique Download PDF

Info

Publication number
EP1439495B1
EP1439495B1 EP03001026.8A EP03001026A EP1439495B1 EP 1439495 B1 EP1439495 B1 EP 1439495B1 EP 03001026 A EP03001026 A EP 03001026A EP 1439495 B1 EP1439495 B1 EP 1439495B1
Authority
EP
European Patent Office
Prior art keywords
ticket
electronic
trusted agent
application
nonce
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.)
Expired - Lifetime
Application number
EP03001026.8A
Other languages
German (de)
English (en)
Other versions
EP1439495A1 (fr
Inventor
Carmen Santa Cruz Roldan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Priority to EP03001026.8A priority Critical patent/EP1439495B1/fr
Priority to PCT/EP2004/000350 priority patent/WO2004066218A1/fr
Publication of EP1439495A1 publication Critical patent/EP1439495A1/fr
Application granted granted Critical
Publication of EP1439495B1 publication Critical patent/EP1439495B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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.
  • EP 0 980 052 A2 discloses recording medium with electronic ticket definitions recorded thereon and electronic ticket processing methods and apparatuses.
  • An electronic ticket comprises a ticket ID, an issuer ID, right information of the electronic ticket, and issue, transfer and redeem conditions, the entire block of these pieces of information being attached with an issuer's signature.
  • ticket schema ID's which specify the types of tickets that the ticket sender and receiver are required to possess, and in each phase of the issue, transfer and redeem transactions it is verified whether these conditions are satisfied.
  • GB 2317790A discusses methods and apparatus for effecting transfers using an electronic representation of a commodity, such as money.
  • the commodity is represented by a value note issued by a bank or other authority, and which includes: first information representative of public key information for a bearer; second information representative of a commodity represented by the value note; and third information representative of an issuer's signature which is verifiable from information including the first information, the second information and public key information for the issuer.
  • Digital endorsement signatures are used to redeem one value note for one or more others, and to authenticate information in the value notes to prevent alteration.
  • Coupon ticketing Version B (November 20, 2001), at the time of writing available at http://www.mobiletransaction.org/pdf/R11/MeT-Coupon- Ticketing-Rll.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-Rll.pdf), have also been presented.
  • 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 intended 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 explicitly and permanently 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 first objective of the invention is to bring out a device for ordering and validating an electronic ticket. This can be achieved as in any one of claims 1 to 7.
  • 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.
  • the mobile device 102 is a mobile terminal, such as a mobile phone, having capabilities to be in connection via remote transportation means such as the mobile network 100A and the Internet 100B, as well as via local transportation means such as BLUETOOTH and IrDA, with the ticket issuing system 101 and with the ticket inspection system 106.
  • the mobile device 102 includes input/output I/O means 260 which include receiving means 263, sending means 262, and a display 261.
  • the receiving means 263 include means with which the mobile device 102 can receive any data from a mobile network 100A, from another mobile device 103, from the user of the mobile device 102, from inspection system 106, ticket issuing system 101, and so on.
  • the receiving means 263 can comprise a keyboard, wireless communication means, touch screen, joystick, speech recognition system adapted to work with a microphone, and so on.
  • 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 implementation 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 includes 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 brought 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 M401 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.
  • the private part 300PR there are two cases; when the electronic ticket 300 is in a sealed state, and when it is in a registered state.
  • Figure 3B illustrates some differences between the electronic ticket 300 in a sealed or in a registered state in more detail: If the electronic ticket 300 is in the sealed state, the authentication of the corresponding data (i.e. security element information 701) performed by the trusted agent 254 is achieved by means of the verifying the issuer signature 708' of the issuing system 101. If the electronic ticket 300 is in the validated state, the authentication of the corresponding 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 authentication of the corresponding data i.e. security element information 701
  • 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 electronic 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.
  • the trusted agent 254 Responsive to the receiving of message 401, the trusted agent 254 initiates processes described in step L11 for generating nonces. In step L11 the trusted agent 254 performs sub-steps 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.
  • step L113 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 .
  • step L114 a copy of each nonce 727 contained in the registry 722 is processed.
  • 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. 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 sub-steps 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' 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 information 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 sub-steps 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.
  • 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 environment, 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, requiring only little or even none modification.
  • data objects belong medical prescriptions, legal documents, and even executable content.
  • the presentation environment of the object can be either remote, local, or personal, as already discussed.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)

Claims (7)

  1. Un dispositif (102) de commande et de validation d'un billet électronique (300), le dispositif (102) comprenant : une application de gestion de billets (200), un élément de sécurité (252) comprenant un agent de confiance (254), une base de registres (722), un espace mémoire de billets (230) et un moyen d'envoi et de réception (262, 263), où la base de registres comprend au moins un registre possédant un champ d'identifiant unique de billet (725) et un identifiant aléatoire correspondant (727), et le billet électronique (300) comprend un identifiant unique de billet, caractérisé en ce que :
    l'agent de confiance (254) est adapté de façon à générer un identifiant aléatoire (727) en réponse à une demande provenant de l'application de gestion de billets, à transmettre l'identifiant aléatoire sous la forme d'un identifiant aléatoire traité à l'espace mémoire de billets, à conserver en mémoire ledit identifiant aléatoire (727) dans la base de registres (722) et sous la forme d'un identifiant aléatoire traité (727') dans l'espace mémoire de billets (230), où le traitement de l'identifiant aléatoire (727) s'effectue par la signature de l'identifiant aléatoire avec la signature de l'agent de confiance,
    - l'application de gestion de billets (200) est adaptée de façon à : générer une demande (M411) relative à un billet électronique (300), la demande (M411) comprenant ledit identifiant aléatoire traité (727') et la signature numérique de l'identifiant aléatoire traité, et à envoyer ladite demande (M411) de l'application de gestion de billets à un système d'émission de billets (101) au moyen du moyen d'envoi (262),
    - l'agent de confiance (254) est adapté de façon à vérifier la signature du système d'émission d'un billet électronique (300) reçu dans un état scellé par le moyen de réception (263) à partir du système d'émission de billets (101) par la comparaison de la signature de l'émetteur (708') aux données de billet (706), où le billet électronique comprend des éléments appartenant à une partie publique (300PR) et des éléments appartenant à une partie privée (300PR), où la partie privée est dans un état scellé,
    - l'application de gestion de billets (200) est adaptée de façon à comparer un identifiant (704) dans le billet électronique (300) aux identifiants aléatoires (727) conservés en mémoire dans la base de registres (722) si le résultat de la vérification de signature est positif,
    - l'agent de confiance (254) est adapté de façon à : copier un identifiant unique de billet (702') dans le champ d'identifiant unique de billet (725) correspondant à l'identifiant aléatoire (727) dans la base de registres (722) si un identifiant aléatoire (727) correspondant à l'identifiant (704) est trouvé, et signer des données de billet (706) du billet électronique (300), modifiant ainsi le billet électronique (300) d'un état scellé vers un état validé par la modification de l'état de la partie privée d'un état scellé vers un état validé,
    - l'agent de confiance (254) est adapté en outre de façon à : envoyer le billet à l'application de gestion de billets (200), et
    - l'application de gestion de billets (200) est adaptée en outre de façon à : envoyer le billet électronique (300) dans l'état validé vers l'espace mémoire de billets (230).
  2. Un dispositif (102) selon la Revendication 1, caractérisé en outre en ce que : l'agent de confiance (254) est adapté de façon à :
    - déchiffrer les données de billet (706') au moyen de sa clé privée dédiée avant la vérification de la signature du système d'émission.
  3. Un dispositif (102) selon la Revendication 1 ou 2, où : ledit identifiant aléatoire (727) est un nombre aléatoire.
  4. Un dispositif (102) selon l'une quelconque des Revendications 1 à 3, où l'application de gestion de billets (200) est adaptée en outre de façon à présenter le billet validé.
  5. Un dispositif (102) selon la Revendication 4, où l'application de gestion de billets (200) est adaptée en outre de façon à présenter le billet validé par l'affichage de celui sur un dispositif d'affichage (261).
  6. Un dispositif (102) selon la Revendication 4, où l'application de gestion de billets (200) est adaptée en outre de façon à présenter le billet validé par le balisage de celui-ci au moyen d'une étiquette RF.
  7. Un dispositif (102) selon la Revendication 4, où l'application de gestion de billets (200) est adaptée en outre de façon à présenter le billet validé par l'envoi de celui-ci par l'intermédiaire d'un canal de communication de réseau mobile, d'une puce RF à faible puissance ou par infrarouge.
EP03001026.8A 2003-01-17 2003-01-17 Dispositif de commande et de validation d'un ticket électronique Expired - Lifetime EP1439495B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP03001026.8A EP1439495B1 (fr) 2003-01-17 2003-01-17 Dispositif de commande et de validation d'un ticket électronique
PCT/EP2004/000350 WO2004066218A1 (fr) 2003-01-17 2004-01-19 Dispositif de commande et de validation d'un ticket electronique, systeme d'edition d'un ticket et ticket electronique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP03001026.8A EP1439495B1 (fr) 2003-01-17 2003-01-17 Dispositif de commande et de validation d'un ticket électronique

Publications (2)

Publication Number Publication Date
EP1439495A1 EP1439495A1 (fr) 2004-07-21
EP1439495B1 true EP1439495B1 (fr) 2019-04-17

Family

ID=32524153

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03001026.8A Expired - Lifetime EP1439495B1 (fr) 2003-01-17 2003-01-17 Dispositif de commande et de validation d'un ticket électronique

Country Status (2)

Country Link
EP (1) EP1439495B1 (fr)
WO (1) WO2004066218A1 (fr)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
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 (fr) * 2005-07-28 2007-02-14 Inventio Ag Procédé destiné au contrôle d'entrée d'une zone accessible à des personnes, en particulier pour une pièce fermée par une porte
JP2007087370A (ja) * 2005-07-28 2007-04-05 Inventio Ag 人が出入りできる区域への、特に扉によって閉ざされた空間への出入りを規制する方法
FI121196B (fi) * 2006-05-15 2010-08-13 Teliasonera Finland Oyj Menetelmä ja järjestelmä älykortin arvon lataamiseen
ES2496593T3 (es) 2006-10-16 2014-09-19 Assa Abloy Hospitality, Inc. Red inalámbrica centralizada para propiedades de gran tamaño con múltiples habitaciones
FI121323B (fi) * 2007-02-09 2010-09-30 Hsl Helsingin Seudun Liikenne Menetelmä, lipunkäsittelylaite, tietokoneohjelmatuote ja tuotealusta sähköisen lipun turvamekanismille
CN102034177A (zh) 2009-09-29 2011-04-27 国际商业机器公司 用于实现有效的移动票券转让的方法和装置
US20120296826A1 (en) 2011-05-18 2012-11-22 Bytemark, Inc. Method and system for distributing electronic tickets with visual display
US10089606B2 (en) 2011-02-11 2018-10-02 Bytemark, Inc. System and method for trusted mobile device payment
US8494967B2 (en) 2011-03-11 2013-07-23 Bytemark, Inc. Method and system for distributing electronic tickets with visual display
US10360567B2 (en) 2011-03-11 2019-07-23 Bytemark, Inc. Method and system for distributing electronic tickets with data integrity checking
US10453067B2 (en) 2011-03-11 2019-10-22 Bytemark, Inc. Short range wireless translation methods and systems for hands-free fare validation
US10762733B2 (en) 2013-09-26 2020-09-01 Bytemark, Inc. Method and system for electronic ticket validation using proximity detection
ES2425618B1 (es) * 2012-02-22 2014-08-05 Universitat Rovira I Virgili Método para realizar transacciones con billetes digitales
DE102012101420A1 (de) * 2012-02-22 2013-08-22 Capinvision AG System und Verfahren zum automatischen Senden von Nachrichten an ein Mobilfunkgerät
EP2878114B1 (fr) 2012-07-27 2020-06-03 Assa Abloy Ab Mise à jour d'authentifiants basée sur la présence
US10001791B2 (en) 2012-07-27 2018-06-19 Assa Abloy Ab Setback controls based on out-of-room presence information obtained from mobile devices
US9881260B2 (en) 2012-10-03 2018-01-30 Moovel North America, Llc Mobile ticketing
FR3025377A1 (fr) * 2014-09-02 2016-03-04 Orange Gestion de tickets electroniques
US9792604B2 (en) 2014-12-19 2017-10-17 moovel North Americ, LLC Method and system for dynamically interactive visually validated mobile ticketing
FR3037754B1 (fr) * 2015-06-22 2017-07-28 Orange Gestion securisee de jetons electroniques dans un telephone mobile
US11803784B2 (en) 2015-08-17 2023-10-31 Siemens Mobility, Inc. Sensor fusion for transit applications
WO2017030799A1 (fr) 2015-08-17 2017-02-23 Bytemark, Inc. Procédés de traduction sans fil à courte portée et systèmes pour validation de tarif de transport mains libres
US10990905B2 (en) 2015-11-30 2021-04-27 Ncr Corporation Location-based ticket redemption
GB201608749D0 (en) 2016-05-18 2016-06-29 Tixserve Ltd An electronic ticketing system
US11212100B2 (en) * 2017-03-23 2021-12-28 Moovel North America, Llc Systems and methods of providing and electronically validating tickets and tokens

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020178385A1 (en) * 2001-05-22 2002-11-28 Dent Paul W. Security system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2783971B2 (ja) * 1994-01-26 1998-08-06 日本信販株式会社 クレジットカードの発行方法
EP0823694A1 (fr) * 1996-08-09 1998-02-11 Koninklijke KPN N.V. Tickets enregistrés dans des cartes à circuit intégré
GB2317790B (en) * 1996-09-26 1998-08-26 Richard Billingsley Improvements relating to electronic transactions
DE69932294T8 (de) * 1998-08-12 2007-10-25 Nippon Telegraph And Telephone Corp. Aufzeichnungsmedium mit darauf aufgezeichneten elektronischen Ticketdefinitionen und Verfahren und Vorrichtungen zum Verarbeiten elektronischer Tickets
US6493550B1 (en) * 1998-11-20 2002-12-10 Ericsson Inc. System proximity detection by mobile stations
JP2001014409A (ja) * 1999-06-28 2001-01-19 Hitachi Ltd チケット販売情報管理方法
EP1150228A1 (fr) * 2000-04-28 2001-10-31 Fournir Limited Procédé de distribution de coupons remboursables à des clients choisis

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020178385A1 (en) * 2001-05-22 2002-11-28 Dent Paul W. Security system

Also Published As

Publication number Publication date
EP1439495A1 (fr) 2004-07-21
WO2004066218A1 (fr) 2004-08-05

Similar Documents

Publication Publication Date Title
EP1439495B1 (fr) Dispositif de commande et de validation d'un ticket électronique
US8213614B2 (en) Distribution and printing of travel documents
EP2779564A1 (fr) Procédé et système destinés à authentifier l'identité d'un utilisateur et équipement utilisé lors de cette authentification
US20180225631A1 (en) Dynamic notary system
US20070094152A1 (en) Secure electronic transaction authentication enhanced with RFID
US8186586B2 (en) System, method, and apparatus for smart card pin management via an unconnected reader
WO2007012085A2 (fr) Systeme de transactions electroniques mobiles, dispositif et procede s'y rapportant
JP2002512711A (ja) 携帯可能な身分証明要素でのトランザクション方法
US20130333055A1 (en) System and method for transference of rights to digital media via physical tokens
JP2007226810A (ja) 通信ネットワーク上での取引を容易にするシステム及び方法
MX2008011999A (es) Metodo y sistema para la eleccion arbitraria en el campo de datos sensibles.
WO2007139348A1 (fr) Procédé et appareil destinés à transmettre/ recevoir un code d'image
EP2587421A1 (fr) Distribution sécurisée et vérification d'une carte d'embarquement mobile
JP2002351833A (ja) 電子取引方法
US20210209594A1 (en) System and methods for using limit-use encrypted code to transfer values securely among users
CN103890706B (zh) 用于渲染内容的渲染许可
US20140074578A1 (en) Method and system for activating and validating coupons
JP4540454B2 (ja) アプリケーション設定装置、ｉｃチップ及びプログラム
JP2013073272A (ja) ユーザ及び端末装置の認証方法、認証システム、認証申請用プログラム
EP1439498A1 (fr) Ticket électronique, dispositif permettant d'émettre des tickets électroniques, dispositifs pour utiliser et réaliser des opérations sur des tickets électroniques
US20100312694A1 (en) Mobile Electronic Transaction System, Device and Method Therefor
JP2010238257A (ja) 購入管理サーバ装置、そのプログラム、購入管理システム、購入管理方法
JP2007272813A (ja) 認証システム、認証サーバ、認証方法及びコンピュータ読み取り可能な認証制御プログラム
KR20070056029A (ko) 전자 인증 이미지(또는 전자 인증 정보) 생성 기능이구비된 무선통신장치
JP2002183634A (ja) 電子許可方法、およびそれに用いられるユーザ装置ならびに電子許可手段実効化システム

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