Brevet FR2916070A1 — publié le 20081114

PROCEDE DE DELIVRANCE DE BILLETS La présente invention concerne un procédé de délivrance de billets sous forme numérique. Un billet s'entend comme un moyen permettant d'attester à son titulaire le droit d'accéder à un évènement (spectacle, concert, exposition, évènement sportif, etc.) ou encore d'utiliser un service (par exemple un moyen de transport). Un billet se présente classiquement sous la forme 110 d'un imprimé, portant généralement les informations suivantes : le titre de l'évènement, la date de l'évènement, la catégorie de place, le tarif, ainsi qu'un code barres constituant une représentation graphique d'un numéro d'ordre unique du billet ]5 permettant de faciliter la gestion automatique de l'ensemble des billets diffusés pour l'évènement. Ces informations sont données à titre indicatif et ne sont pas limitatives. La délivrance d'un billet nécessite généralement 20 que l'utilisateur se déplace dans un espace de vente approprié où il peut acheter le billet et le retirer manuellement. Toutefois, ce mode de distribution de billets imprimés est lourd à gérer pour les organisateurs d'évènements en même temps que peu 25 pratique pour l'utilisateur. Outre ces systèmes de billetterie manuelle, on connaît des systèmes de billetterie dématérialisée, qui ont connu un essor important ces dernières années. Le principe est le suivant. L'utilisateur se connecte via le réseau Internet depuis un terminal équipé d'un navigateur Internet à un serveur Web proposant la vente de billets pour certains évènements (il peut également s'agir de vente de titres de transport). Après avoir fait son choix, l'utilisateur effectue le paiement en ligne correspondant à l'achat du billet. Puis, une fois la transaction enregistrée, le serveur transmet, par exemple via un système de messagerie électronique, le billet au terminal utilisateur sous la forme d'un fichier électronique au format JPEG ou PDF par exemple. A la suite de quoi, l'utilisateur peut imprimer lui-même son billet à l'aide d'une imprimante connectée à son terminal. Si cette solution de billetterie dématérialisée apporte une certaine souplesse d'utilisation pour les utilisateurs, elle n'est cependant pas complètement satisfaisante. En effet, si au moment d'accéder à l'évènement, l'utilisateur se rend compte qu'il a oublié ou perdu son billet imprimé, il n'a plus aucun moyen d'attester de sa réservation au niveau du contrôle d'accès et son entrée sera refusée. En outre, cette solution n'est pas adaptée pour des besoins de dernières minutes notamment lorsque l'utilisateur décide d'émettre de façon impulsive et de n'importe quel endroit une commande de billet pour un évènement, puisqu'il doit disposer d'un équipement informatique connecté à une imprimante. La présente invention a pour but de remédier à ces inconvénients en proposant un procédé et un système de délivrance de billets électroniques améliorés. Avec cet objectif en vue, l'invention a pour objet un procédé de délivrance d'un billet électronique pour l'accès à un évènement ou à un service, depuis un serveur vers un terminal mobile doté de capacités d'affichage, comprenant les étapes de : - stockage, dans une base de données côté serveur, de données relatives à une commande de billet émise depuis le terminal mobile connecté au serveur et identifié auprès de celui-ci, les données stockées comprenant au moins un code d'identification unique associé au billet, émission, du serveur vers le terminal mobile, d'un message de confirmation comprenant un moyen de connexion au serveur, activable à la demande depuis le terminal mobile, -activation, côté terminal mobile, du moyen de connexion contenu dans le message de confirmation reçu pour émettre vers le serveur une requête en téléchargement du billet, - génération à la volée, côté serveur, commandée par ladite activation, d'un fichier image du billet, à partir des données relatives à la commande émise stockée dans la base de données côté serveur, - émission du fichier image du serveur vers le terminal mobile et stockage du fichier image sur celui-ci pour son affichage. De préférence, la génération du fichier image du billet comprend la génération d'un code barres constituant une représentation graphique du code d'identification unique et son affichage dans l'image. De préférence, la génération du fichier image du billet comprend l'affichage dans l'image de données textuelles choisies parmi au moins le nom et le prénom de l'émetteur de la commande, la date, le prix, le nom de l'évènement. Selon un mode de réalisation, le message de confirmation émis est un message de type WAP push , contenant un lien WAP en tant que moyen de connexion vers le serveur. De préférence, la requête en téléchargement émise comprend une référence du terminal mobile, à partir de laquelle le serveur est adaptée à retrouver une description des capacités d'affichage dudit terminal. Avantageusement, le procédé comprend une étape de formatage des données du fichier image généré côté serveur, de manière à l'adapter aux capacités d'affichage du terminal. De préférence, le fichier image est un fichier au format GIF. Avantageusement, le fichier image généré comprend des moyens de protection, de manière à empêcher la copie du fichier image reçu vers un autre terminal. Selon un mode de réalisation, le terminal mobile est un téléphone mobile s'identifiant auprès du serveur via son numéro de téléphone mobile. L'invention. concerne également un dispositif de délivrance de billets électroniques pour l'accès à des évènements ou à des services, comprenant . - des moyens de connexion à un réseau de communication, - une première base de données mémorisant une liste des évènements et services accessibles, et une seconde base de données mémorisant pour toute commande de billet reçue, des données relatives à la commande comprenant au moins un code d'identification unique, - des moyens aptes à recevoir une requête de commande de billet depuis un terminal mobile, - des moyens aptes à émettre vers le terminal mobile un message de confirmation comprenant un moyen de connexion audit dispositif, activable à la demande depuis le terminal mobile pour commander l'émission d'une requête en téléchargement du billet, - des moyens aptes à recevoir ladite requête en téléchargement du billet, - des moyens aptes à générer à la volée, suite à la réception de ladite requête en téléchargement du billet, un fichier image du billet, à partir des données relatives à la commande reçue stockée dans ladite seconde base de données, - des moyens aptes à émettre ledit fichier image vers le terminal mobile. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles : - la figure 1 illustre une architecture fonctionnelle sur laquelle repose le système de délivrance de billets selon l'invention ; -la figure 2 illustre sous la forme d'un organigramme, les différentes étapes du procédé selon un mode de réalisation de l'invention, mises en oeuvre par le système de délivrance de billets montré sur la figure 1. En référence à la figure 1, le système selon l'invention comprend un terminal utilisateur 10 adapté pour se connecter, via une passerelle 20, à un réseau de communication 40, typiquement le réseau Internet, pour accéder à un service de délivrance de billets électroniques hébergé par un serveur Web 30 connecté au réseau. Le serveur Web héberge une base de données évènements 32, stockant l'ensemble des évènements (noms, lieux, dates, tarifs, etc.) pour lesquels l'utilisateur peut acquérir un billet électronique via son terminal selon des principes qui seront expliqués plus loin. Par ailleurs, le serveur 30 héberge également une base de données billets 34, prévue pour mémoriser toute l'information relative à l'ensemble des billets émis pour les différents évènements proposés pour l'ensemble des utilisateurs. L'information mémorisée dans la base de données pour chaque billet émis pour un utilisateur comprend nécessairement un numéro d'identification unique de billet, composé d'une suite de caractères numériques ou alphanumériques, l'identité (nom et prénom) du titulaire du billet, son numéro de téléphone mobile, le nombre de personnes compris sur le billet, la catégorie de tarif, etc. Le terminal 10 est donc un terminal permettant à son utilisateur d'avoir accès à Internet. Il s'agit par exemple d'un téléphone mobile, ou tout autre terminal portatif sans fil, compatible au protocole WAP ( Wireless Application Protocol ) et équipé d'un navigateur WAP, le protocole WAP étant une adaptation du protocole TCP-IP au domaine de la technologie sans fil. C'est donc dans le cadre de ce système que vont être décrites en référence à la figure 2 les étapes du procédé selon un mode de réalisation de l'invention. Selon ce mode de réalisation, à la première étape 41, le terminal mobile 10 se connecte à la passerelle WAP 20 par exemple via un réseau mobile de type GPRS. Une fois la connexion établie à l'étape 42, le terminal 10 soumet à l'étape 43 une demande d'adresse URL à la passerelle 20 pour accéder via son navigateur au serveur 30 hébergeant le service de délivrance de billets en ligne. Le terminal utilise pour cela des protocoles WAP spécifiques. La passerelle WAP demande alors à l'étape 44 l'adresse URL en question via des protocoles Internet standard (HTTP). Une fois le contenu demandé renvoyé à la passerelle WAP par le serveur à l'étape 45, celle-ci effectue classiquement diverses opérations d'optimisation ou de conversion de protocole à l'étape 46, de manière à acheminer le contenu sous un format exploitable par le terminal utilisateur. Une fois les données reçues sur le terminal 10, le navigateur WAP du terminal permet d'afficher le contenu destiné à l'utilisateur sur l'écran du terminal à l'étape 47. L'utilisateur a ainsi accès au serveur 30 de délivrance de billets électroniques. Avant de pouvoir générer une commande d'achat de billet via son navigateur, l'utilisateur doit créer un compte, lui permettant de s'identifier auprès du serveur 30 et lui ouvrant ainsi un droit d'accès personnalisé au serveur. Pour ce faire, un identifiant, typiquement son numéro de téléphone mobile, et un mot de passe sont attribués à l'utilisateur. A l'étape 48, le terminal via le navigateur génère donc une commande d'achat de billet en ligne, transmise 10 à l'étape 49 par la passerelle WAP vers le serveur 30. L'utilisateur peut effectuer son règlement directement depuis le terminal, les données de paiement échangées entre le navigateur et le serveur Web étant classiquement protégées par la mise en oeuvre d'un 15 protocole de type SSL lors du paiement. La commande de billet est alors traitée par le serveur à l'étape 50. Ainsi, une fois le paiement validé par l'utilisateur, un code d'identification unique est généré au niveau du serveur et associé au 20 billet vendu. Lors de cette étape, l'ensemble de l'information relative au billet commandé est alors stocké dans la base de données billets 34, à savoir, au moins le numéro de téléphone mobile de l'utilisateur, l'identité de l'utilisateur (nom et prénom), le nom de 25 l'évènement, la date, le tarif, le nombre de places, ainsi que le numéro d'identification unique du billet. A ce stade, le billet, c'est-à-dire un fichier au format image, particulièrement consommateur en ressource mémoire, n'est pas créé et n'existe donc pas 30 encore. Par contre, toute l'information relative au billet et nécessaire à sa génération est mémorisée dans la base de données billet 34 du serveur, associée au compte utilisateur correspondant à partir duquel la commande de billet a été émise. Comme on le verra par la suite, seule une action ultérieure de l'utilisateur commande la génération effective du billet dans un format image à partir de l'information mémorisée. Ce mode de traitement permet donc avantageusement d'optimiser les capacités de stockage de l'information au niveau du serveur 30. A l'étape 51, un message de confirmation de la commande est émis par le serveur. Selon un mode de réalisation préféré de l'invention, ce message est émis selon la technologie WAP push , permettant l'envoi de messages personnalisés interactifs. Ainsi, ce message de confirmation de la commande est transmis vers la passerelle, servant de plate forme d'envoi de messages WAP push, qui achemine dans une étape 52 le message WAP push de confirmation vers le terminal utilisateur 10. Ce message transmis vers le terminal 10 se présente donc sous la forme d'un message court de service de type SMS, comprenant un lien WAP prévu pour indiquer au navigateur du terminal une URL particulière, lui permettant d'établir une connexion avec une page personnalisée du serveur 30 correspondant à la commande passée via le compte utilisateur associé au terminal 10. Le message WAP push est réceptionné et stocké sur le terminal utilisateur 10. Une étape 53 de téléchargement du billet à partir du terminal 10 peut alors être mise en oeuvre à n'importe quel moment choisi par l'utilisateur, sur intervention de celui-ci. Plus précisément, la simple activation du lien contenu dans le message SMS reçu permet de requérir au serveur le téléchargement du billet commandé. Pour ce faire, l'activation du lien à l'étape 53 commande l'établissement de la connexion vers le serveur, via la passerelle intervenant à l'étape 54 pour acheminer ladite connexion. A la réception de la requête émise par le terminal, le serveur vérifie dans une étape 55 si le billet existe déjà ou non. Dans la négative, une étape 56 de génération du billet correspondant à la commande émise est immédiatement et automatiquement mise en oeuvre au niveau du serveur à partir des informations relatives au billet préalablement stockées dans la base de données billets du serveur. Cette génération du billet à la volée sur le serveur 30 commandée par l'activation du lien côté terminal, consiste donc à générer un fichier image dont le contenu correspond aux données du billet stockées. Le fichier image du billet généré est par exemple au format GIF, particulièrement avantageux dans le cadre de la présente application mobile en train d'être décrite, qui fait l'objet du mode de réalisation préféré de l'invention. Pour la création du fichier image du billet, un code barres est généré, constituant une représentation graphique du code d'identification unique associé au billet et est affiché dans l'image. Le contenu du fichier image généré comprend également une représentation des données textuelles du billet, à savoir notamment, le nom et prénom de l'utilisateur, le tarif, le nom de l'évènement, la date, le prix, l'accès, etc. Le fichier image ainsi généré est alors stocké dans la base de données billets et est émis dans une étape 57 vers le navigateur du terminal, à travers la passerelle qui achemine le fichier vers le terminal dans une étape 58. Le terminal reçoit donc dans une étape 59 un simple fichier image du billet au format GIF, qui est stocké dans une mémoire du terminal. Ce format permet avantageusement de préserver les capacités de stockage du terminal, pu=isque le fichier reçu occupe très peu de place dans la mémoire du terminal en comparaison par exemple des messages multimédia de type MMS, classiquement utilisés pour transmettre un contenu numérique tel qu'une image sur un téléphone mobile. Avantageusement, la requête de téléchargement du billet émise depuis le terminal vers le serveur grâce à l'activation du lien WAP, comprend une description des capacités d'affichage du terminal (taille de l'écran, résolution supportée, etc.). En variante, la requête émise comprend simplement la référence du terminal 10 et le serveur 30 comprend alors une base de données spécifique stockant pour chaque référence de terminal compatible avec le système, ses capacités d'affichage. Ainsi, l'étape de génération du fichier image du billet mené à l'étape 56 comprend un formatage des données de l'image générée selon la description ou la référence reçue, de manière à l'adapter aux capacités d'affichage du terminal. On évite de cette manière d'éventuels problèmes liés à un affichage défectueux du billet sur l'écran du terminal. En outre, le fichier image du billet généré et transmis par le serveur comprend des mesures techniques de protection type DRM ( Digital Right management ), permettant d'empêcher la copie du fichier image reçu vers un autre terminal. Il peut s'agir par exemple d'une mesure connu sous le nom de Forward Lock , permettant un usage illimité du contenu téléchargé, mais empêchant la transmission de celui-ci. Un autre avantage du procédé de délivrance de billet qui vient d'être décrit est que le billet peut être téléchargé à nouveau et plusieurs fois, dans l'hypothèse par exemple où le fichier reçu aurait été perdu ou supprimé par erreur, par simple activation du lien WAP contenu dans le message SMS reçu à l'étape 53 par le terminal. Enfin le procédé de délivrance de billet selon l'invention demeure également compatible avec un mode plus usuel d'achat et de délivrance des billets, consistant à imprimer le billet commandé depuis un terminal connecté à une imprimante. Selon cet autre mode de réalisation, l'utilisateur peut ainsi se connecter au serveur 30 via le réseau Internet depuis n'importe quel terminal équipé d'un navigateur Internet et accéder à son compte via son identifiant et son mot de passe, où il pourra retrouver toutes ses commandes de billet. Dans ce mode de réalisation, la suite d'étapes consécutives à l'étape 50 de traitement de la commande de billet, propre à un mode de délivrance mobile, est remplacée par des étapes dans lesquelles le terminal utilisateur connecté au serveur requiert la délivrance du billet sous la forme d'un fichier électronique au format JPEG ou PDF. Le fichier à imprimer comprend de la même manière que décrite précédemment, le code barre, généré uniquement suite à la requête de l'utilisateur, et l'ensemble des données textuelles du billet. A la suite de quoi, l'utilisateur peut imprimer lui-même son billet à l'aide d'une imprimante connectée à son terminal. IO REVENDICATIONS 1. Procédé de délivrance d'un billet électronique pour l'accès à un évènement ou à un service, depuis un serveur (30) vers un terminal mobile (10) doté de capacités d'affichage, comprenant les étapes de : - stockage (50), dans une base de données (34) côté serveur, de données relatives à une commande de billet émise depuis le terminal mobile connecté au serveur et identifié auprès de celui-ci, les données stockées comprenant au moins un code d'identification unique associé au billet, émission (51), du serveur vers le terminal mobile, d'un message de confirmation comprenant un moyen de connexion au serveur, activable à la demande depuis le terminal mobile, - activation (53), côté terminal mobile, du moyen de connexion contenu dans le message de confirmation reçu pour émettre vers le serveur une requête en téléchargement du billet, - génération à la volée (56), côté serveur, commandée par ladite activation, d'un fichier image du billet, à partir des données relatives à la commande émise stockée dans la base de données côté serveur, - émission (57) du fichier image du serveur vers le terminal mobile et stockage (59) du fichier image sur celui-ci pour son affichage. 2. Procédé selon la revendication 1, caractérisé en ce que la génération du fichier image du billet comprend la génération d'un code barres constituant une représentation graphique du code d'identification unique et son affichage dans l'image. 3. procédé selon la revendication 1 ou 2, caractérisé en ce que la génération du fichier image du billet comprend l'affichage dans l'image de données 10 textuelles choisies parmi au moins le nom et le prénom de l'émetteur de la commande, la date, le prix, le nom de l'évènement. 4. procédé selon l'une quelconque des 15 revendications 1 à 3, caractérisé en ce que le message de confirmation émis est un message de type WAP push , contenant un lien WAP en tant que moyen de connexion vers le serveur. 20 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la requête en téléchargement émise comprend une référence du terminal mobile, à partir de laquelle le serveur est adaptée à retrouver une description des capacités 25 d'affichage dudit terminal. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape de formatage des données du fichier 30 image généré côté serveur, de manière à l'adapter aux capacités d'affichage du terminal. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le fichier image est un fichier au format GIF. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le fichier image généré comprend des moyens de protection, de manière à empêcher la copie du fichier image reçu vers un autre terminal. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le terminal mobile est un téléphone mobile s'identifiant auprès du serveur via son numéro de téléphone mobile. 15 10. Dispositif (30) de délivrance de billets électroniques pour l'accès à des évènements ou à des services, comprenant . - des moyens de connexion à un réseau de 20 communication (40), - une première base de données (32) mémorisant une liste des évènements et services accessibles, et une seconde base de données (34) mémorisant pour toute commande de billet reçue, des données relatives à la 25 commande comprenant au moins un code d'identification unique, - des moyens aptes à recevoir une requête de commande de billet depuis un terminal mobile (10), - des moyens aptes à émettre vers le terminal 30 mobile un message de confirmation comprenant un moyen de connexion audit dispositif, activable à la demande 10depuis le terminal mobile pour commander l'émission d'une requête en téléchargement du billet, - des moyens aptes à recevoir ladite requête en téléchargement du billet, - des moyens aptes à générer à la volée, suite à la réception de ladite requête en téléchargement du billet, un fichier image du billet, à partir des données relatives à la commande reçue stockée dans ladite seconde base de données, - des moyens aptes à émettre ledit fichier image vers le terminal mobile.