EP2397981B1 - Borne et procédé de distribution de tickets électroniques - Google Patents

Borne et procédé de distribution de tickets électroniques Download PDF

Info

Publication number
EP2397981B1
EP2397981B1 EP11169421.2A EP11169421A EP2397981B1 EP 2397981 B1 EP2397981 B1 EP 2397981B1 EP 11169421 A EP11169421 A EP 11169421A EP 2397981 B1 EP2397981 B1 EP 2397981B1
Authority
EP
European Patent Office
Prior art keywords
terminal
electronic ticket
identifier
medium
term1
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.)
Active
Application number
EP11169421.2A
Other languages
German (de)
English (en)
Other versions
EP2397981A1 (fr
Inventor
Yann-Loïc Aubin
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.)
Idemia France SAS
Original Assignee
Idemia France SAS
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 Idemia France SAS filed Critical Idemia France SAS
Publication of EP2397981A1 publication Critical patent/EP2397981A1/fr
Application granted granted Critical
Publication of EP2397981B1 publication Critical patent/EP2397981B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07BTICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points

Definitions

  • the present invention is in the field of the distribution of electronic tickets.
  • It can in particular be used in a transport network.
  • this system when a motorist wants to park his vehicle, he goes to a parking meter with which he pays a certain amount of money by means of a payment method, in exchange for a parking fee for a vehicle. determined duration, this parking fee being encoded in a transponder delivered in the form of a ticket by the time stamp and intended to be placed behind the windshield of the vehicle to allow its verification by an authorized agent.
  • this system has a major disadvantage in that it requires a relatively long time for the user between the payment of the parking space to the ticket machine and the distribution of the associated electronic ticket.
  • the documents JP 2004 287997 and WO 2009/087494 each have a system for managing and distributing electronic tickets.
  • the invention proposes a terminal which does not have the drawbacks of the time stamp of the prior art.
  • the invention relates to an electronic ticket dispensing system as defined in claim 1.
  • the invention also relates to a method of electronic ticket distribution as defined in claim 8.
  • the invention applies in particular, but in a non-limiting manner to the distribution of electronic transport tickets.
  • the system and the electronic ticket dispensing method according to the invention make it possible to record, in a list, a plurality of electronic tickets, the electronic ticket supplied or delivered to an electronic ticket support. given being selected in the list from an identifier of the medium.
  • the invention thus makes it possible to reduce the interactions between the user and the terminal.
  • the list of electronic tickets waiting to decorrelate the payment of an electronic ticket of its distribution so that the waiting time at the time of obtaining the electronic ticket is excessively reduced.
  • the electronic ticket is generated from the identifier of the support, the terminal and the distribution method according to the invention being able to search the list of electronic tickets, the ticket or tickets generated from the support identifier included in the request issued by a support.
  • the electronic ticket holders are transponders able to communicate without contact with the terminal for obtaining an electronic transport ticket.
  • These transponders may be passive type transponders using inductive coupling to receive or transmit data in accordance with the contactless technologies described in the ISO14443 or ISO15593 standards.
  • the electronic ticket holders can be constituted by plastic cards ID1 format of the ISO7816 standard (54 mm x 85 mm).
  • the electronic ticket support comprises means for authenticating the electronic tickets that are issued to it from authentication data generated from the identifier of this medium.
  • the electronic ticket holder can memorize the history of the electronic tickets that have been provided to it. As a variant, only the last electronic ticket is stored in the medium, the others being erased.
  • the electronic ticket distribution terminal is able to read and receive an electronic ticket stored in a medium and to allow access to a service, for example to a transport network, after verification of the validity of this ticket.
  • the database can for example be managed by a server accessible by a website from which the user provides information, including the identifier of its electronic ticket support.
  • the data structure may include the MSISDN identifier ("Mobile Station ISDN Number", the number of the user known to the public) or IMSI ("International Mobile Suscriber Identity") of a card. subscription to a telephone network (SIM card). Therefore, when the user calls a number corresponding to a terminal, using a mobile phone incorporating the SIM card, this call is processed by the system server according to the invention; it then obtains, from the database, the identifier of the electronic ticket holder of the user, generates the electronic ticket from this identifier, and makes it available to the user, in the list of the terminal corresponding to the called number.
  • MSISDN identifier Mobile Station ISDN Number
  • IMSI International Mobile Suscriber Identity
  • the IMSI identifier is stored in the SIM card, the telephone network making the correspondence between the IMSI identifier and the MSISDN identifier communicated to the recipient.
  • the user can thus request the generation of an electronic ticket for a terminal, without being close to the terminal, since it is sufficient that he knows the telephone number associated with this terminal.
  • the server sends, at a given moment, for example at the beginning of the month, the data structure to the distribution terminal, so that it makes available the electronic ticket in its list, the terminal being specified by the user in his profile registered in the website.
  • it may also be the last terminal used following a phone call as described above.
  • the server of the system according to the invention is able to cut the communication with the terminal, as soon as it has obtained the identifier of this terminal and the identifier of the terminal, early enough to avoid billing of this communication, for example before the terminal accepts communication, during the ring phase.
  • the server of the system according to the invention comprises means for sending a message to the terminal of the user to indicate that the electronic ticket is available from this terminal.
  • the sending or not of this message for example of SMS type, can be configured with the aforementioned website.
  • the user can thus be informed of the availability of the ticket.
  • the terminal according to the invention sends the server a message when it has actually delivered the electronic ticket to a user.
  • the server can then by means of an identifier of a means of payment of the user pay the ticket payment and send a payment confirmation message to the terminal of the user.
  • the various steps of the electronic ticket dispensing method are determined by computer program instructions.
  • the present application also describes a computer program on an information medium, this program being capable of being implemented by a computer, this program comprising instructions adapted to the implementation of the steps of the method of distribution of electronic transport tickets as mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the present application also describes a computer-readable information carrier, and including instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a diskette (floppy disc) or a disk hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the figure 1 represents a transport system 10 according to the invention.
  • This system comprises two terminals TERM1, TERM2 transport according to the invention, each of these terminals having a reader RD adapted to communicate with a support PT electronic ticket transport.
  • this support PT is constituted by a contactless smart card.
  • Each of these terminals TERM1, TERM2 is associated with a telephone number respectively N-TERM1, N-TERM2, the telephone number of a terminal being displayed on the terminal itself.
  • the electronic transport ticket holder PT comprises a non-volatile memory storing an ID-PT identifier of this medium.
  • a terminal MP of the holder of the electronic ticket transport medium PT is also represented, namely, in this example, a mobile telephone.
  • the server SRV is able to implement a computer program PG-SRV whose main steps C10 to C100 are represented at the figure 3 .
  • the SRV server comprises a recording medium, namely a memory, on which this PG-SRV program is recorded.
  • this terminal may in particular be constituted by a mobile phone MP or a personal computer not shown.
  • the PG-BD program implemented by this server SRV2 comprises, in this example, the steps A10 and A20 shown in FIG. figure 3 .
  • Step A10 makes it possible to create the account of the user and to record the information relating to this user, in other words his profile in the database BD.
  • the creation and / or update of the user's profile can be carried out by the user, or by a third party, for example the administrator of the database BD.
  • the user can, after providing his password PWD, modify the information of his profile.
  • This number can be a toll free number.
  • This call establishes, during a step C10, a communication COM1 with the server SRV, for example via a mobile telephone network.
  • This communication can be established in circuit mode or according to the http protocol for example.
  • the protocol or signaling implemented for the establishment of the communication allows the SRV server to identify the calling mobile phone MP; the ID-MP identifier of this mobile phone can for example be constituted by a telephone number or by an IP address (Internet Protocol).
  • the SRV server Upon receipt of the call, the SRV server records, during a step C20, the ID-MP identifier of the mobile phone MP in a memory not shown. In the embodiment described here, the SRV server also records the N-TERM1 telephone number of the terminal TERM1.
  • the mobile terminal MP releases the communication on its side, during a step B20.
  • the server SRV sends to the server SRV2, a request including the ID-MP identifier of the mobile phone MP (communication COM2).
  • This request is received by the server SRV2 during a step A20.
  • the server SRV2 searches the database BD, a data structure SD, including the identifier ID-MP, and returns this data structure SD to the server SRV.
  • the server SRV sends (communication COM3) to the terminal identified by the terminal identifier N-TERM1 received from the telephone call COM1 previously established with the mobile telephone MP at least some information included in the structure SD data, and in particular the ID-PT identifier of the electronic transport ticket holder of the user.
  • the TERM1 terminal During a step D20, the TERM1 terminal generates an electronic transport ticket CP and saves it in an LC list.
  • the terminal SRV generates authentication data of the electronic ticket CP, these data being verifiable by the support PT.
  • This authentication data may for example be constituted by a cryptographic signature of the electronic ticket calculated with a diversified key obtained from a master key and the ID-PT identifier of the medium.
  • Terminal TERM1 then sends a confirmation message of this record to the SRV server which receives it during a step C60.
  • the server SRV On receipt of this message, the server SRV sends, during a step C70, a short SMS message to the mobile phone MP, this SMS being received by the mobile phone MP during a step B30 (communication COM4).
  • the TERM1 terminal comprises, in its LC list, a plurality of electronic transport tickets, each of which has been generated from the ID-PT identifier of an electronic ticket holder.
  • the user approaches, during a step D30, its support PT electron transport tickets RD drive terminal TERM1.
  • This COM5 communication can be secured by cryptographic means; for example, the ID-PT identifier of the electronic transport ticket holder may include a signature, the latter being verified by the terminal TERM1 before issuing a ticket.
  • the support PT transmits, during a step E10, its identifier ID-PT to the terminal TERM1, which receives it during a step D30.
  • the terminal TERM1 searches, in its LC list, an electronic ticket CP generated from the identifier ID-PT of this support.
  • the terminal TERM1 communicates this electronic ticket CP to the support PT; it stores it in its memory during a step E20.
  • the electronic ticket CP comprises authentication data, (ie for example a cryptographic signature) verifiable by the support PT, the electronic ticket CP being stored in the memory only in case of success authentication.
  • authentication data ie for example a cryptographic signature
  • the terminal TERM1 sends, in a communication message COM6, a message to the server SRV2 to confirm that the electronic transport ticket CP has been delivered to the support PT (step D60).
  • This message is received by the SRV server during a step C80.
  • the SRV server communicates, during a COM7 communication, with the bank server SRV-BK to debit the account of the user. It uses for this purpose the ID-CB identifier of the bank card of this user.
  • the server SRV1 sends a short message SMS, during a step C100 during a COM8 communication to the mobile phone MP to confirm this payment.
  • the payment can also be made before the establishment of COM5 communication: the user can prepay the electronic ticket with SRV2 using his mobile phone MP or another terminal.
  • This SMS is received by the mobile phone MP during a step B40.
  • the user can now use his electronic transport ticket to access the transport network.
  • terminal TERM2 allows access to this transport network.
  • step E30 When the user approaches his support PT electronic transport ticket (step E30), in front of the reader RD of this terminal, contactless COM9 communication is established.
  • This COM9 communication is a short-range communication (of the order of a few centimeters) for example in accordance with the NFC standard. It can also be a contact communication.
  • the terminal can communicate with wireless communication means or without contact with a mobile phone controller MP, the controller being connected to the support PT by a connector.
  • the TERM2 terminal then allows the user access to the transport network, after checking the validity of the ticket.
  • the validity check may consist of verifying the validity of an access date or specific areas covered by the network.
  • the invention can also be applied for example to the distribution of electronic tickets for shows or access tickets to a building.

Description

    Arrière-plan de l'invention
  • La présente invention se situe dans le domaine de la distribution de tickets électroniques.
  • Elle peut notamment être utilisée dans un réseau de transport.
  • Elle vise en particulier une borne de distribution de tickets électroniques et un système de transport comportant une telle borne.
  • Dans le domaine de la distribution de tickets électroniques, on connaît notamment le document WO 2004/055736 décrivant un procédé pour gérer des places de stationnement payants utilisant des titres de stationnement électroniques.
  • Dans ce système, lorsqu'un automobiliste veut stationner son véhicule, il se dirige vers un horodateur auprès duquel il acquitte une certaine somme d'argent à l'aide d'un moyen de paiement, pour obtenir en contrepartie un droit de stationnement pour une durée déterminée, ce droit de stationnement étant encodé dans un transpondeur délivré sous la forme d'un ticket par l'horodateur et destiné à être placé derrière le pare-brise du véhicule pour permettre sa vérification par un agent autorisé.
  • Malheureusement, bien que particulièrement avantageux, ce système présente un inconvénient majeur en ce qu'il requiert un temps relativement long pour l'utilisateur entre le paiement de la place de stationnement à l'horodateur et la distribution du ticket électronique associé.
  • Les documents JP 2004 287997 et WO 2009/087494 présentent chacun un système de gestion et de distribution de tickets électroniques.
  • Objet et résumé de l'invention
  • L'invention propose une borne qui ne présente pas les inconvénients de l'horodateur de l'art antérieur.
  • Plus précisément, l'invention concerne un système de distribution de tickets électroniques tel que défini dans la revendication 1.
  • Corrélativement, l'invention vise aussi un procédé de distribution de tickets électroniques tel que défini dans la revendication 8.
  • L'invention s'applique en particulier, mais de façon non limitative à la distribution de tickets de transport électroniques.
  • Ainsi, d'une façon très avantageuse, le système et le procédé de distribution de tickets électroniques selon l'invention permettent d'enregistrer, dans une liste, une pluralité de tickets électroniques, le ticket électronique fourni ou délivré à un support de tickets électroniques donné étant sélectionné dans la liste à partir d'un identifiant du support.
  • L'invention permet ainsi de réduire les interactions entre l'utilisateur et la borne.
  • En effet, très avantageusement, la liste de tickets électroniques en attente permet de décorréler le paiement d'un ticket électronique de sa distribution, si bien que le temps d'attente au moment de l'obtention du ticket électronique est excessivement réduit.
  • Dans un mode particulier de réalisation, le ticket électronique est généré à partir de l'identifiant du support, la borne et le procédé de distribution selon l'invention étant aptes à rechercher dans la liste de tickets électroniques, le ou les tickets générés à partir de l'identifiant de support compris dans la requête émise par un support.
  • Dans un mode particulier de réalisation de l'invention, les supports de tickets électroniques sont des transpondeurs aptes à communiquer sans contact avec la borne pour l'obtention d'un ticket de transport électronique. Ces transpondeurs peuvent être des transpondeurs de type passif utilisant le couplage inductif pour recevoir ou transmettre des données conformément aux technologies sans contact décrites dans les normes ISO14443 ou ISO15593.
  • Les supports de tickets électroniques peuvent être constitués par des cartes plastifiées au format ID1 de la norme ISO7816 (54 mm x 85 mm).
  • Dans un mode particulier de réalisation du système selon l'invention, le support de ticket électronique comporte des moyens pour authentifier les tickets électroniques qui lui sont délivrés à partir de données d'authentification générées à partir de l'identifiant de ce support.
  • Le support de ticket électronique peut mémoriser l'historique des tickets électroniques qui lui ont été fournis. En variante, seul le dernier ticket électronique est mémorisé dans le support, les autres étant effacés.
  • Dans un mode particulier de réalisation, la borne de distribution de tickets électroniques selon l'invention est apte à lire et recevoir un ticket électronique mémorisé dans un support et à permettre l'accès à un service, par exemple à un réseau de transport, après vérification de la validité de ce ticket.
  • L'invention vise un système comportant au moins :
    • une borne de distribution de tickets électroniques telle que mentionnée ci-dessus ;
    • un support de tickets électroniques ; et
    • un serveur apte à obtenir la structure de données précitée à partir d'une base de données d'utilisateurs du système et à fournir cette structure de données à la borne.
  • La base de données peut par exemple être gérée par un serveur accessible par un site Web auprès duquel l'utilisateur fournit des informations, notamment l'identifiant de son support de tickets électroniques.
  • Selon l'invention, ce serveur comporte :
    • des premiers moyens de communication aptes à recevoir un message en provenance d'un terminal d'un utilisateur du système, ce message comportant un identifiant de ce terminal et un identifiant d'une borne selon l'invention ;
    • des deuxièmes moyens de communication aptes à obtenir la structure de données précitée à partir de l'identifiant de terminal ;
    le serveur fournissant la structure de données à la borne identifiée par l'identifiant de borne compris dans le message.
  • Par exemple, dans ce mode de réalisation, la structure de données peut comporter l'identifiant MSISDN (« Mobile Station ISDN Number », numéro de l'usager connu du public) ou IMSI (« International Mobile Suscriber Identity ») d'une carte de souscription à un réseau téléphonique (carte SIM). Dès lors, lorsque l'utilisateur appelle un numéro correspondant à une borne, en utilisant un téléphone mobile incorporant cette carte SIM, cet appel est traité par le serveur du système selon l'invention ; celui-ci obtient alors, à partir de la base de données, l'identifiant du support de tickets électroniques de l'utilisateur, génère le ticket électronique à partir de cet identifiant, et le met à disposition de l'utilisateur, dans la liste de la borne correspondant au numéro appelé.
  • On rappelle que l'identifiant IMSI est mémorisé dans la carte SIM, le réseau téléphonique faisant la correspondance entre cet identifiant IMSI et l'identifiant MSISDN communiqué au destinataire.
  • Très avantageusement, l'utilisateur peut ainsi demander la génération d'un ticket électronique pour une borne, sans être à proximité de la borne, puisqu'il suffit qu'il connaisse le numéro de téléphone associé à cette borne.
  • Bien entendu, cette phase d'appel n'est pas nécessaire pour la mise en oeuvre de l'invention. Dans un autre mode de réalisation, le serveur envoie, à un instant déterminé, par exemple en début de mois, la structure de données à la borne de distribution, pour qu'elle mette à disposition le ticket électronique dans sa liste, la borne étant spécifiée choisie par l'utilisateur dans son profil enregistré dans le site Web.
  • En variante, il peut aussi s'agir de la dernière borne utilisée suite à un appel téléphonique comme décrit précédemment.
  • Préférentiellement, le serveur du système selon l'invention est apte à couper la communication avec le terminal, dès qu'il a obtenu l'identifiant de ce terminal et l'identifiant de la borne, suffisamment tôt pour éviter une facturation de cette communication, par exemple avant que le terminal n'accepte la communication, pendant la phase de sonnerie.
  • Dans un mode particulier de réalisation de l'invention, le serveur du système selon l'invention comporte des moyens pour envoyer un message au terminal de l'utilisateur pour lui indiquer que le ticket électronique est disponible auprès de cette borne. L'envoi ou non de ce message, par exemple de type SMS, peut être configuré auprès du site Web précité.
  • L'utilisateur peut ainsi être prévenu de la disponibilité du ticket.
  • Dans un mode particulier de réalisation de l'invention, la borne selon l'invention envoie au serveur, un message lorsqu'elle a effectivement délivrée le ticket électronique à un utilisateur.
  • Le serveur peut alors au moyen d'un identifiant d'un moyen de paiement de l'utilisateur acquitter le paiement du ticket et envoyer un message de confirmation de paiement au terminal de l'utilisateur.
  • A cet effet, la structure de données enregistrée auprès du site Web peut comporter une pluralité d'éléments à savoir, en plus de l'identifiant de support indispensable, des informations parmi lesquelles :
    • un identifiant de moyen de paiement, par exemple de carte bancaire,
    • un identifiant de terminal par exemple de téléphone mobile ;
    • un mot de passe pour la gestion de son compte ;
    • les paramètres du service pour lequel il souhaite être facturé ; et
    • une durée de validité de ce service (mois, quinzaine, ...).
  • Dans un mode particulier de réalisation, les différentes étapes du procédé de distribution de tickets électroniques sont déterminées par des instructions de programmes d'ordinateurs.
  • En conséquence, la présente demande décrit aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé de distribution de tickets de transport électroniques tel que mentionné ci-dessus.
  • Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
  • La présente demande décrit aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
  • Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur.
  • D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
  • Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
  • Brève description des dessins
  • D'autres caractéristique est avantages de la présente invention ressortiront de la description faite ci-dessous en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif.
  • Sur les figures :
    • la figure 1 représente un système conforme à un mode particulier de réalisation de l'invention ;
    • la figure 2 représente une structure de données pouvant être utilisée dans le système de la figure 1 ; et
    • la figure 3 représente sous forme d'organigramme les principales étapes d'un procédé de distribution de tickets électroniques conforme à un mode particulier de réalisation de l'invention.
    Description détaillée de l'invention
  • L'invention est présentée ici dans le contexte d'une application de transport.
  • La figure 1 représente un système 10 de transport conforme à l'invention.
  • Ce système comporte deux bornes TERM1, TERM2 de transport conforme à l'invention, chacune de ces bornes comportant un lecteur RD apte à communiquer avec un support PT de tickets électroniques de transport.
  • Dans l'exemple de réalisation décrit ici, ce support PT est constitué par une carte à puce sans contact.
  • Chacune de ces bornes TERM1, TERM2 est associé à un numéro de téléphone respectivement N-TERM1, N-TERM2, le numéro de téléphone d'une borne étant affichée sur la borne elle-même.
  • Le support PT de tickets de transport électroniques comporte une mémoire non volatile mémorisant un identifiant ID-PT de ce support.
  • Les bornes TERM1, TERM2 sont reliées à un réseau de télécommunications auxquels sont également reliés :
    • un premier serveur SRV1 ;
    • un deuxième serveur SRV2 hébergeant un site Web comportant, dans une base de données BD, le profil des utilisateurs du système 10 ; et
    • un serveur bancaire SRV-BK.
  • Sur la figure 1, on a également représenté un terminal MP du détenteur du support de transport de tickets électroniques PT, à savoir, dans cet exemple, un téléphone mobile.
  • Le serveur SRV est apte à mettre en oeuvre un programme d'ordinateur PG-SRV dont les principales étapes C10 à C100 sont représentées à la figure 3 . Dans l'exemple de réalisation décrit ici, le serveur SRV comporte un support d'enregistrement, à savoir une mémoire, sur lequel est enregistré ce programme PG-SRV.
  • Nous allons maintenant décrire, en référence à la figure 3, un exemple de fonctionnement du système 10 de la figure 1.
  • Nous supposerons tout d'abord que l'utilisateur détenteur du support de ticket de transport électronique crée son profil auprès du serveur SRV2 en utilisant un terminal apte à communiquer avec le serveur SRV2 via le réseau Internet, ce terminal pouvant notamment être constitué par un téléphone mobile MP ou par un ordinateur personnel non représenté.
  • Le programme PG-BD mis en oeuvre par ce serveur SRV2 comporte, dans cet exemple, les étapes A10 et A20 représentées à la figure 3.
  • L'étape A10 permet de créer le compte de l'utilisateur et d'enregistrer les informations relatives à cet utilisateur autrement dit son profil dans la base de données BD.
  • On notera que la création et/ou la mise à jour du profil de l'utilisateur peut être effectuée par l'utilisateur, ou par un tiers, par exemple l'administrateur de la base de donnée BD.
  • Dans l'exemple de réalisation décrit ici, ces informations sont structurées selon une structure de données SD représentée à la figure 2 . Elle comporte :
    • l'identifiant ID-PT du support de tickets électroniques PT ;
    • un identifiant ID-MP du téléphone mobile MP de cet utilisateur ;
    • une définition DZ des zones de transport dans lequel circule cet utilisateur ;
    • une durée de validité d'un ticket de transport électronique devant être délivré à cet utilisateur ;
    • un identifiant ID-CV d'une carte bancaire de cet utilisateur enregistrée auprès du serveur bancaire SRV-BK ; et
    • un mot de passe PWD permettant à l'utilisateur de s'authentifier auprès du site Web.
  • Bien sûr, à tout moment, l'utilisateur peut, après avoir fourni son mot de passe PWD, modifier les informations de son profil.
  • A la figure 3 :
    • les étapes B10 à B40 sont les étapes d'un programme d'ordinateur PG-MP mis en oeuvre par le téléphone mobile MP ;
    • les étapes D10 à D70 sont les étapes d'un programme d'ordinateur PG-TERM mis en oeuvre par chacune des bornes TERM1, TERM2 ; et
    • les étapes E10 à E30 sont les étapes d'un programme d'ordinateur PG-PT mis en oeuvre par un microprocesseur embarqué dans le support de tickets de transport électroniques PT.
  • Nous supposerons dans cet exemple, que l'utilisateur appelle, au cours d'une étape B10, avec son téléphone mobile MP, le numéro de téléphone N-TERM1 associé à la borne TERM1.
  • Ce numéro peut être un numéro gratuit.
  • Bien entendu, il n'est pas nécessaire que l'utilisateur soit à proximité de cette borne au moment de cet appel.
  • Cet appel établit, au cours d'une étape C10, une communication COM1 avec le serveur SRV, par exemple via un réseau de téléphonie mobile. Cette communication peut être établie en mode circuit ou selon le protocole http par exemple.
  • De façon connue, le protocole ou la signalisation mise en oeuvre pour l'établissement de la communication permet au serveur SRV d'identifier le téléphone mobile MP appelant ; l'identifiant ID-MP de ce téléphone mobile peut par exemple être constitué par un numéro de téléphone ou par une adresse IP (Internet Protocole).
  • Sur réception de l'appel, le serveur SRV enregistre, au cours d'une étape C20, l'identifiant ID-MP du téléphone mobile MP dans une mémoire non représentée. Dans le mode de réalisation décrit ici, le serveur SRV enregistre également le numéro N-TERM1 de téléphone de la borne TERM1.
  • Puis, il coupe la communication téléphonique, au cours d'une étape C30, la communication avec le téléphone mobile MP avant que celle-ci ne soit facturée, par exemple pendant l'étape de sonnerie.
  • Le terminal mobile MP relâche la communication de son côté, au cours d'une étape B20.
  • Puis, au cours d'une étape C40, le serveur SRV envoie au serveur SRV2, une requête comportant l'identifiant ID-MP du téléphone mobile MP (communication COM2). Cette requête est reçue par le serveur SRV2 au cours d'une étape A20. Sur réception de cette requête, le serveur SRV2 recherche dans la base de données BD, une structure de données SD, comportant l'identifiant ID-MP, et renvoie cette structure de données SD au serveur SRV.
  • Au cours d'une étape C50, le serveur SRV envoie (communication COM3) à la borne identifiée par l'identifiant de bornes N-TERM1 reçue de la communication téléphonique COM1 établie précédemment avec le téléphone mobile MP au moins certaines informations comprises dans la structure de données SD, et en particulier l'identifiant ID-PT du support de tickets de transport électroniques de l'utilisateur.
  • Ces données sont reçues par la borne TERM1 au cours d'une étape D10.
  • Au cours d'une étape D20, la borne TERM1 génère un ticket de transport électronique CP et l'enregistre dans une liste LC.
  • Dans le mode de réalisation décrit ici, la borne SRV génère des données d'authentification du ticket électronique CP, ces données étant vérifiables par le support PT. Ces données d'authentification peuvent par exemple être constituées par une signature cryptographique du ticket électronique calculée avec une clef diversifiée obtenue à partir d'une clef maître et de l'identifiant ID-PT du support.
  • La borne TERM1 envoie ensuite un message de confirmation de cet enregistrement au serveur SRV qui le reçoit au cours d'une étape C60.
  • Sur réception de ce message, le serveur SRV envoie, au cours d'une étape C70, un message court SMS au téléphone mobile MP, cet SMS étant reçu par le téléphone mobile MP au cours d'une étape B30 (communication COM4).
  • A cet instant, la borne TERM1 conforme à l'invention comporte, dans sa liste LC, une pluralité de tickets de transport électroniques, chacun ayant été généré à partir de l'identifiant ID-PT d'un support de tickets électroniques.
  • Nous allons maintenant supposer que l'utilisateur détenteur du support de tickets de transport électroniques PT se rapproche physiquement de la borne TERM1 pour se faire délivrer son propre ticket de transport électronique.
  • A cet effet, l'utilisateur approche, au cours d'une étape D30, son support PT de tickets de transport électroniques du lecteur RD de la borne TERM1.
  • Il s'établit alors une communication sans contact COM5 entre ces deux entités.
  • Cette communication COM5 peut être sécurisée par des moyens cryptographiques ; à titre d'exemple, l'identifiant ID-PT du support de tickets de transport électroniques peut comporter une signature, celle-ci étant vérifiée par la borne TERM1 avant de délivrer un ticket.
  • Au cours de cette communication COM5, le support PT transmet, au cours d'une étape E10, son identifiant ID-PT à la borne TERM1, qui le reçoit au cours d'une étape D30.
  • Puis, au cours d'une étape D40, la borne TERM1 recherche, dans sa liste LC, un ticket électronique CP généré à partir de l'identifiant ID-PT de ce support.
  • Au cours d'une étape D50, la borne TERM1 communique ce ticket électronique CP au support PT ; celui-ci l'enregistre dans sa mémoire au cours d'une étape E20.
  • Dans ce mode particulier de réalisation, le ticket électronique CP comporte des données d'authentification, (à savoir par exemple une signature cryptographique) vérifiables par le support PT, le ticket électronique CP n'étant enregistré dans la mémoire qu'en cas de succès de l'authentification.
  • Dans l'exemple de réalisation décrit ici, la borne TERM1 envoie, dans un message de communication COM6, un message au serveur SRV2 pour lui confirmer que le ticket de transport électronique CP a bien été délivré au support PT (étape D60).
  • Ce message est reçu par le serveur SRV au cours d'une étape C80.
  • Au cours d'une étape C90, le serveur SRV communique, au cours d'une communication COM7, avec le serveur bancaire SRV-BK pour débiter le compte de l'utilisateur. Il utilise à cet effet l'identifiant ID-CB de la carte bancaire de cet utilisateur.
  • Dans l'exemple de réalisation décrit ici, le serveur SRV1 envoie un message court SMS, au cours d'une étape C100, au cours d'une communication COM8, au téléphone mobile MP pour lui confirmer ce paiement.
  • En variante le paiement peut aussi être réalisé avant l'établissement de la communication COM5 : l'utilisateur peut prépayer le ticket électronique auprès de SRV2 en utilisant son téléphone mobile MP ou un autre terminal.
  • Ce SMS est reçu par le téléphone mobile MP au cours d'une étape B40.
  • L'utilisateur peut maintenant utiliser son ticket électronique de transport pour accéder au réseau de transport.
  • Nous supposons dans cet exemple que la borne TERM2 permet l'accès à ce réseau de transport.
  • Lorsque l'utilisateur approche son support PT de ticket de transport électronique (étape E30), devant le lecteur RD de cette borne, une communication COM9 sans contact s'établie.
  • Cette communication COM9 est une communication de courte portée (de l'ordre de quelques centimètres) par exemple conforme à la norme NFC. Il peut aussi s'agir d'une communication avec contact.
  • En variante, la borne peut communiquer avec des moyens de communication sans fil ou sans contact avec un contrôleur du téléphone mobile MP, ce contrôleur étant relié au support PT par un connecteur.
  • La borne TERM2 permet alors l'accès de l'utilisateur au réseau de transport, après vérification de la validité du ticket.
  • Dans la cas d'une application de transport, la vérification de la validité peut consister à vérifier la validité d'une date d'accès ou à des zones déterminées couvertes par le réseau.
  • L'invention peut aussi s'appliquer par exemple à la distribution de tickets électroniques de spectacles ou de tickets d'accès à un bâtiment.

Claims (12)

  1. Système (10) comportant au moins :
    - un support (PT) de tickets électroniques d'un utilisateur dudit système (10) ;
    - un serveur (SRV) comportant :
    - des premiers moyens de communication configurés pour recevoir un message en provenance d'un terminal (MP) de l'utilisateur dudit système (10), ce message comportant un identifiant (ID-MP) de ce terminal et un identifiant (N-TERM1) d'une borne (TERM1) de distribution de tickets électroniques ; et
    - des deuxièmes moyens de communication configurés pour obtenir une structure de données (SD) à partir d'une base de données d'utilisateurs dudit système et dudit identifiant (ID-MP) du terminal reçu par les premiers moyens de communication, ladite structure de données (SD) comportant un identifiant (ID-PT) dudit support de ticket électronique (PT) ;
    ledit serveur (SRV) étant configuré pour fournir ladite structure de données (SD) à la borne (TERM1) identifiée par ledit identifiant de borne (N-TERM1) ;
    - ladite borne (TERM1) comportant :
    - un module de génération des tickets électroniques, ce module comportant :
    - des moyens d'obtention de ladite structure de données (SD) comportant ledit identifiant (ID-PT) du support de ticket électronique (PT) ; et
    - des moyens de génération d'un ticket électronique (CP) à partir dudit identifiant (ID-PT) ;
    ladite borne comportant également :
    - des moyens d'enregistrement configurés pour enregistrer, dans une liste (LC), le ou les tickets électroniques (CP) générés, la liste associant chaque ticket (CP) à un identifiant (ID-PT) du support (PT) de tickets électroniques (CP) ; et
    - un module de distribution de tickets électroniques comportant :
    - des moyens de communication configurés pour recevoir, en provenance dudit support (PT) de tickets électroniques, une requête pour obtenir un ticket électronique (CP), cette requête comportant ledit identifiant (ID-PT) dudit support (PT); et
    - des moyens de recherche configurés pour rechercher, dans ladite liste (LC), un ticket électronique (CP) généré à partir de l'identifiant (ID-PT) de support compris dans ladite requête ;
    - lesdits moyens de communication étant configurés pour délivrer ledit ticket électronique (CP) audit support.
  2. Système (10) selon la revendication 1, caractérisé en ce que lesdits moyens de communication du module de distribution de tickets électroniques sont des moyens de communication sans contact compatibles avec des moyens de communication sans contact dudit support (PT).
  3. Système (10) selon la revendication 1 ou 2, caractérisé en ce que lesdits moyens de communication du module de distribution de tickets électroniques sont aptes à recevoir un ticket électronique (CP) en provenance dudit support et à permettre l'accès à un service après vérification de la validité dudit ticket.
  4. Système (10) selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit serveur (SRV) comporte des moyens pour couper la communication avant que ledit terminal (MP) n'accepte l'appel pour éviter une facturation de ladite communication.
  5. Système (10) selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit serveur (SRV) comporte des moyens pour envoyer un message audit terminal pour lui indiquer que ledit ticket électronique (CP) est disponible auprès de ladite borne (TERM1).
  6. Système (10) selon l'une quelconque des revendications 1 à 5, caractérisé en ce que :
    - ladite borne (TERM1) comporte des moyens pour envoyer un message audit serveur (SRV) pour lui indiquer qu'elle a effectivement délivré ledit ticket électronique (CP) audit support ; et en ce que
    - ledit serveur (SRV) est apte à obtenir un identifiant (ID-CB) d'un moyen de paiement d'un utilisateur dudit support et à acquitter le paiement dudit ticket électronique (CP) en utilisant cet identifiant et à envoyer un message de confirmation dudit paiement à un terminal dudit utilisateur.
  7. Système (10) selon la revendication 6 dans lequel ledit support (PT) comporte des moyens pour authentifier ledit ticket électronique (PY) à partir de données d'authentification générées à partir dudit identifiant.
  8. Procédé de distribution de tickets électroniques (CP) comportant succesivement :
    - une étape (C10) de réception, par un serveur, en provenance d'un terminal (MP) d'un utilisateur, d'un message de demande de génération d'un ticket électronique comportant l'identifiant (ID-MP) de ce terminal (MP) et l'identifiant (N-TERM1) d'une borne (TERM1) de distribution de tickets électroniques ;
    - une étape (C40) d'obtention, par le serveur (SRV), d'une structure de données (SD) à partir d'une base de données d'utilisateurs et dudit identifiant (ID-MP) de terminal, ladite structure de données (SD) comportant l'identifiant (ID-PT) d'un support de ticket électronique de l'utilisateur ; ;
    - une étape (C50) d'envoi, par le serveur (SRV), à ladite borne (TERM1) de distribution de tickets électroniques, de la structure de données (SD);
    - une étape (D20) de génération, par ladite borne (TERM1), d'un ticket électronique (CP) à partir dudit identifiant (ID-PT) de support ;
    - une étape (D20) d'enregistrement, dans une liste (LC), par ladite borne (TERM1) dudit ticket électronique (CP) associé à l'identifiant (ID-PT) du support de tickets électroniques (PT);
    - une étape (D30) de réception, par ladite borne (TERM1) en provenance d'un support (PT) apte à recevoir un ticket électronique, d'une requête pour obtenir un ticket électronique (CP), cette requête comportant un identifiant (ID-PT) dudit support (PT);
    - une étape (D40) de recherche, par ladite borne (TERM1) dans ladite liste (LC), d'un ticket électronique (CP) généré à partir de l'identifiant (ID-PT) compris dans ladite requête ; et
    - une étape (D50) de fourniture, par ladite borne (TERM1), dudit ticket électronique (CP) audit support.
  9. Procédé de distribution selon la revendication 8, caractérisé en ce que l'obtention (D30) du ticket électronique (CP) par ladite borne est effectuée par des moyens de communication sans contact.
  10. Procédé selon la revendication 9, caractérisé en ce que les moyens de communication utilisent une technologie sans contact conformément à la norme ISO 14443 ou à la norme ISO 15593.
  11. Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce que ledit serveur (SRV) communique avec ledit terminal (MP) pour recevoir ledit message via un réseau de téléphone mobile.
  12. Procédé selon l'une quelconque des revendications 8 à 11, caractérisé en ce que ledit identifiant (ID-MP) de terminal est constitué par un numéro de téléphone ou par une adresse IP.
EP11169421.2A 2010-06-15 2011-06-10 Borne et procédé de distribution de tickets électroniques Active EP2397981B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1054713A FR2961332B1 (fr) 2010-06-15 2010-06-15 Borne et procede de distribution de tickets electroniques

Publications (2)

Publication Number Publication Date
EP2397981A1 EP2397981A1 (fr) 2011-12-21
EP2397981B1 true EP2397981B1 (fr) 2019-08-21

Family

ID=43431049

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11169421.2A Active EP2397981B1 (fr) 2010-06-15 2011-06-10 Borne et procédé de distribution de tickets électroniques

Country Status (2)

Country Link
EP (1) EP2397981B1 (fr)
FR (1) FR2961332B1 (fr)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BE1013294A5 (fr) * 2000-02-23 2001-11-06 Matuz Bruno Louis Version electronique du titre-repas belge.
CN1659566B (zh) * 2002-06-10 2010-10-20 坂村健 具有非接触型ic卡接口的电子货币传送装置
FR2848705B1 (fr) 2002-12-12 2005-04-01 Schlumberger Systems & Service Procede pour gerer des places de stationnement payant utilisant des titres de stationnement electroniques
JP2004287997A (ja) * 2003-03-24 2004-10-14 Dental Supply:Kk 電子券配信システム
JP2007041672A (ja) * 2005-08-01 2007-02-15 Pia Corp 電子チケット発行システムとそれを実現するためのコンピュータプログラムとその方法
BRPI0722327A2 (pt) * 2007-12-28 2014-04-08 Mobilysim Distribuição de tíquetes eletrônicos por radiofrequência
WO2009087494A1 (fr) * 2008-01-08 2009-07-16 Forwarding Software Limited Format numérique mobile

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
EP2397981A1 (fr) 2011-12-21
FR2961332A1 (fr) 2011-12-16
FR2961332B1 (fr) 2012-07-20

Similar Documents

Publication Publication Date Title
EP1610510B1 (fr) Contrôle d'accès sans fil à des services télématiques et vocaux
EP1240634B1 (fr) Procede et dispositif pour la surveillance de personnes, d'animaux ou d'objets
EP2016564B1 (fr) Systeme de location automatise
EP1690240A1 (fr) Procede et systeme de location automatique de bicyclettes
EP3085133B1 (fr) Système et procédé pour fournir un service a l'utilisateur d'un terminal mobile
WO2000069191A1 (fr) Terminal radiotelephonique avec une carte a puce dotee d'un navigateur
WO2001088861A1 (fr) Procede d'approvisionnement d'un compte prepaye
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
WO2009027607A2 (fr) Procede et systeme de fourniture de services
FR2837953A1 (fr) Systeme d'echange de donnees
FR2821222A1 (fr) Procede d'etablissement de communication anonyme
FR2999324A1 (fr) Gestion securisee d'une transaction de prestation de service
EP2793197A1 (fr) Procédé et système automatique de contrôle d'accès
CA2635924A1 (fr) Procede de transaction electronique par messagerie mobile
EP2397981B1 (fr) Borne et procédé de distribution de tickets électroniques
WO2008104704A1 (fr) Systeme de paiement electronique comportant un terminal mobile incorporant un porte-monnaie electronique et un serveur
FR2927453A1 (fr) Procede et systeme de distribution de billets de banque a partir d'un distributeur de billets
WO2017001757A1 (fr) Serveur et procede de verification de code de securite
EP2073521A1 (fr) Procédé d'acheminement de communications téléphoniques
EP1065866A1 (fr) Méthode et dispositif de contrôle d'accès à des services disponibles depuis un terminal de télécommunications
EP2093989A1 (fr) Procede de communication d'information pour abonnes de services prepayes
FR2884014A1 (fr) Acces a un bien ou a un service delivre par un automate au moyen d'un dispositif portable
FR3136623A1 (fr) Procédé de communication entre un objet communicant et un dispositif de communication
FR2995711A1 (fr) Procede et systeme de paiement adapte a un equipement communicant de type horodateur ou distributeur automatique
FR2902270A1 (fr) Procede de localisation spatiale d'un moyen de communication mobile dans un reseau de communication, ainsi qu'un systeme de communication de donnees de mise en oeuvre

Legal Events

Date Code Title Description
17P Request for examination filed

Effective date: 20110610

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

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

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170626

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: IDEMIA FRANCE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20190402

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602011061383

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1170603

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190915

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20190821

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191121

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191121

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191221

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191122

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1170603

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190821

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200224

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602011061383

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

PG2D Information on lapse in contracting state deleted

Ref country code: IS

26N No opposition filed

Effective date: 20200603

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602011061383

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200610

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20200630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200630

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200610

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200630

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210101

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190821

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230428

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20230523

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20230523

Year of fee payment: 13