FR 2980891 A1 20130405 FR 1158806 A 20110930 - 1 - « Procédé et système de signalisation de paiement, application à la location automatisée de véhicules » La présente invention concerne un procédé de signalisation à l'utilisateur de paiements. Elle concerne également un système de signalisation de paiements mettant en oeuvre un tel procédé de paiement. L'invention concerne également une application d'un tel procédé et d'un tel système à la location de véhicules. Le domaine de l'invention est le domaine des paiements répétés dans le temps avec un moyen de paiement, par exemple une carte bancaire, lors d'achat ou de locations de biens ou de services. Plus particulièrement, l'invention concerne le domaine de la signalisation de paiements répétés avec un même moyen de paiement, en particulier des paiements répétés réalisés dans le cadre d'une relation commerciale nécessitant : - le paiement d'un montant majoré pour un bien ou un service pour une durée prédéterminée, par exemple pour un abonnement, et - le paiement de montants additionnels de manière ponctuelle lors de la consommation du bien ou du service. L'invention concerne en particulier, et de manière non limitative, le domaine de la location automatisée de véhicules proposés à la location dans un ou plusieurs sites de locations. Etat de la technique La location automatisée de véhicule est un domaine en pleine croissance. Les agglomérations désirant diminuer le nombre de véhicules présents sur leur territoire mettent en place des systèmes de location automatisés de véhicule. Ces systèmes nécessitent des paiements répétés dans le temps à chaque location de véhicule sous la forme de paiements réguliers pour acquitter des montants relatifs à un abonnement souscrit auprès de l'opérateur fournissant le service de location mais également des paiements de frais additionnels pouvant se produire lors de chaque location. - 2 - Dans les procédés et systèmes de l'état de la technique, il se pose donc la question du compte rendu des paiements effectués par l'utilisateur, notamment lors de ces achats/locations répétés dans le temps. Dans l'état de la technique, lorsqu'on paye à l'aide d'une carte de paiement, on insère la carte dans un terminal de paiement, qui, après un certain nombre d'échanges avec un serveur bancaire, autorise la transaction et imprime un ticket de paiement physique rendant compte de la transaction et comprenant un certain nombre de mentions légales, notamment le montant autorisé à débiter. Ce ticket rappelle la transaction et sa possession permet au porteur de la carte bancaire de contester le paiement dans certains cas. Le ticket de paiement ainsi imprimé comprend toutes les informations relatives à la transaction. Toutefois, au vu du nombre moyen important de transactions effectuées par un utilisateur, il se pose un réel problème d'archivage des tickets de paiement. De nombreux tickets ne sont donc pas conservés ou perdus, ce qui ne permet pas aux utilisateurs de détecter efficacement les éventuelles erreurs dans les mouvements d'argent sur leur compte. En outre, dans le cas de certains systèmes, notamment les systèmes de location de véhicules, dans lequel l'utilisateur autorise le prélèvement d'un montant majoré à l'avance et ne présente pas à nouveau sa carte une fois qu'il a rendu le véhicule, le montant prélevé peut être différent du montant autorisé et on ne connaît pas à l'avance le montant prélevé. Or, le ticket de paiement indique le montant qu'on a autorisé à prélever, et non le montant réellement prélevé. Cela peut être source de confusion pour l'utilisateur et l'empêcher de vérifier correctement les transactions qu'il a effectuées. Un but de la présente invention est de remédier aux inconvénients précités. Un autre but de l'invention est de proposer un procédé et un système de signalisation de paiement, notamment pour des paiements répétés dans le temps, permettant à un utilisateur un suivi simple et clair pour les paiements réalisés sur son compte. - 3 - Encore un autre but de l'invention est de proposer un procédé et un système de signalisation de paiements réalisés permettant à un utilisateur de repérer les paiements réellement effectués sur son compte. Enfin, un autre but de l'invention est de proposer un procédé et un système de signalisation de paiement permettant à un utilisateur de garder les preuves de paiements réellement effectués sur son compte. Exposé de l'invention L'invention propose d'atteindre au moins l'un des buts précités par un procédé de signalisation de paiements réalisés avec un moyen de paiement d'un utilisateur, ledit procédé comprenant les étapes suivantes : - lecture de données relatives audit moyen de paiement depuis ledit moyen de paiement, - émission vers un serveur bancaire d'une demande de règlement, à l'aide des données relatives audit moyen de paiement, ledit procédé étant caractérisé en ce qu'il comprend une émission, à une adresse numérique obtenue préalablement, de données, dites de compte-rendu, relatives à l'issue de ladite demande de règlement. Les données de compte-rendu peuvent également appelées « ticket virtuel » dans la présente demande. Par « lecture de données depuis le moyen de paiement », on entend qu'un terminal de paiement est directement en contact avec le moyen de paiement et lit directement les informations dans ce moyen de paiement, sans saisie de ces données par l'utilisateur. Une telle étape de lecture est par exemple la lecture d'une puce ou d'une bande magnétique du moyen de paiement. Ainsi, le procédé selon l'invention permet d'envoyer de manière numérique des comptes-rendus pour les paiements effectivement réalisés sur son compte. Le procédé selon l'invention ne se limite pas notamment à indiquer à l'utilisateur le montant majoré qu'il a autorisé à prélever sur son compte qui est généralement différent du montant réel qu'il doit payer. Ainsi, le procédé selon l'invention permet de communiquer à l'utilisateur les données relatives au prélèvement réel effectué sur son - 4 - compte lui permettant de pouvoir contester le prélèvement si des anomalies existent. Le procédé selon l'invention permet également de suivre de manière simple et claire les prélèvements réalisés sur son compte au fur et à mesure des opérations d'achats ou de location. Le procédé selon l'invention permet également à l'utilisateur de se rendre compte d'actes de vols ou d'erreurs réalisés relativement à une autorisation de prélèvement qu'il aurait accordé et pour laquelle il n'aurait pas encore consommé. Un tel procédé facilite également l'archivage des tickets de carte bancaire pour l'utilisateur, et la recherche d'un tel ticket en cas de conflit. On notera que le procédé est décrit par la suite en relation avec un service de location de véhicules mais qu'il peut être appliqué à tout type de paiement à l'aide d'un moyen de paiement physique, tel qu'une carte bancaire, et ce peu importe la nature du bien ou service que l'utilisateur souhaite acquérir et régler à l'aide de l'opération de paiement. Les données relatives au moyen de paiement peuvent être lues par un terminal de lecture, plus particulièrement un terminal de paiement, dans lequel est inséré le moyen de paiement. Avantageusement, les demandes de règlement décrites ci-dessous sont réalisées selon un premier protocole nécessitant la présence physique du moyen de paiement dans un terminal de paiement (dans le cas où il y a une demande de pré-autorisation puis une demande de paiement effectif, au moins pour la demande de pré-autorisation). Un tel protocole de paiement permet de garantir de manière sécurisée le paiement car il permet d'obtenir une donnée d'autorisation de débit. Par ailleurs, un tel protocole de paiement permet de s'assurer que le moyen de paiement est bien utilisé par le porteur du moyen de paiement, par exemple en demandant la saisie d'un code PIN ou un code de sécurité secret associé à la carte. - 5 - Le procédé comprend également une étape de réception d'une réponse du serveur bancaire à la demande de règlement, les données de compte-rendu étant générées en fonction de la demande de règlement et/ou de la réponse. Dans un mode de réalisation particulièrement avantageux, le procédé comprend les étapes suivantes : - émission vers le serveur bancaire d'une demande de pré-autorisation, à l'aide des données relatives audit moyen de paiement, puis - si la pré-autorisation a été obtenue, émission vers le serveur bancaire d'une demande de paiement effectif, à l'aide des données relatives audit moyen de paiement et d'une donnée de pré-autorisation caractéristique de la pré-autorisation, la demande de règlement étant constituée par l'une et/ou l'autre des demandes de pré-autorisation et de paiement effectif. Le procédé peut comprendre une étape d'émission d'un compte-rendu après chacune des étapes de demande de pré-autorisation et de paiement effectif ou uniquement après la demande de pré-autorisation par exemple. En variante, les demandes de pré-autorisation et de paiement effectif étant émises chacune pour un montant prédéterminé, il comprend une étape de comparaison du montant de ces demandes, l'étape d'émission d'un compte-rendu étant effectuée : - pour la demande de pré-autorisation, - en supplément, pour la demande de paiement effectif si et seulement si les montants des deux demandes sont différents. Ainsi, en plus des avantages cités plus haut, le procédé selon l'invention permet dans ce cas d'éviter à l'utilisateur la confusion que peut créer une situation dans laquelle il est renseigné uniquement du montant majoré qu'il a autorisé à prélever sur son compte et non du montant réellement prélevé. Les procédés et systèmes de l'état de la technique ne renseignent pas en effet du montant réellement prélevé. - 6 - On peut également envisager qu'en plus de la demande de paiement effectif, dite initiale, qui est effectuée selon un premier protocole de paiement et détaillée plus haut, le procédé comprend l'émission d'au moins une autre demande de paiement effectif, dite ultérieure, selon un deuxième protocole de paiement, notamment indépendant de la demande de pré- autorisation. Cette demande de paiement ultérieure peut être réalisée selon un protocole de paiement ne nécessitant pas la présence physique du moyen de paiement dans un terminal de paiement, tel que par exemple un protocole de paiement de type vente à distance. Un tel protocole de paiement présent l'avantage d'être flexible car il permet de réaliser un paiement sans la présence physique du moyen de paiement dans un terminal de paiement par exemple. De préférence, le procédé selon l'invention comprend également une étape d'identification de l'utilisateur et de mémorisation des données relatives au moyen de paiement en association avec au moins une donnée de l'utilisateur. De cette façon, les demandes de paiement ultérieures peuvent être effectuées sans que l'utilisateur n'ait à présenter à nouveau son moyen de paiement. Une telle combinaison de demande de paiement selon deux protocoles différents permet de réaliser une pluralité de demande de paiement sécurisé à la fois pour le porteur du moyen de paiement et pour l'opérateur fournissant le bien ou le service, et flexible car l'utilisateur n'a pas à présenter le moyen de paiement à chaque demande de paiement. Avantageusement, une étape d'émission de données de compte-rendu est également effectuée suite à la demande de paiement ultérieure. L'utilisateur est ainsi averti de toutes les transactions effectuées sur son compte même dans le cas où il n'a pas besoin de présenter son moyen de paiement. Lorsque le procédé est mis en oeuvre dans le cas de paiements répétés, une demande de règlement, notamment de paiement effectif, peut être déclenchée dans l'un ou plusieurs des cas suivants : - 7 - - lors de chaque utilisation du service réalisée par l'utilisateur, et/ou - lorsqu'un compte client, associé à l'utilisateur et incrémenté à chaque utilisation du service, atteint un montant maximum prédéterminé, ledit procédé comprenant en outre une étape de consultation d'un montant associé audit compte à chaque nouvelle opération d'achat ou de location ou à une fréquence donnée, et/ou - lorsque la précédente demande de paiement pour ledit utilisateur a été effectuée depuis une durée maximale prédéterminée, ledit procédé comprenant en outre une consultation de la date de ladite dernière demande de paiement à chaque nouvelle opération d'achat ou de location ou à une fréquence donnée, et/ou - lorsqu'une date prédéterminée, liée à une date de fin de contrat de service par exemple, est atteinte, ledit procédé comprenant en outre une consultation de ladite date à chaque nouvelle opération d'achat ou de location ou à une fréquence donnée, ledit utilisateur s'identifiant lors de chaque utilisation grâce à son identifiant. Le premier cas présente l'avantage de détecter une situation de défaut de paiement rapidement et d'éviter le défaut de paiement d'un montant important et de limiter les pertes de l'opérateur. Les deuxième et troisième cas présentent l'avantage de diminuer le nombre de demandes de paiement et donc les transactions bancaires réalisées. Avantageusement, les données de compte-rendu peuvent comprendre des données relatives : - au type demande de paiement, et/ou - au moyen de paiement, et/ou - au destinataire de la transaction, et/ou - au montant, et/ou - à la date ou l'heure de la transaction, et/ou - à l'issue de la demande de paiement, - 8 - les données de compte-rendu pouvant notamment être présentées sous forme d'un ticket virtuel comprenant la plupart notamment toutes les informations visibles sur un ticket émis par un terminal de paiement suite à une demande de pré-autorisation ou de paiement par ce terminal. Les données peuvent également, en supplément ou en remplacement, être relatives à une adresse Internet, notamment un lien, à consulter pour obtenir un compte-rendu de l'issue de la demande de règlement. Un tel ticket virtuel peut alors être disponible à l'adresse indiquée dans le message. L'adresse numérique associée à l'utilisateur peut comprendre : - une adresse de courriel, les données de compte rendu étant alors émises notamment au travers d'un réseau de type Internet, et/ou - un numéro de téléphone mobile, les données de compte-rendu étant alors émises notamment au travers d'un réseau de type GPRS, et/ou - toute autre coordonnée numérique telle que par exemple un numéro de télécopie une adresse de réseau sociale, etc. Une telle adresse numérique peut être modifiée, supprimée ou ajoutée à distance ou auprès d'un site de l'opérateur à tout moment au travers d'une interface utilisateur. Avantageusement, l'adresse numérique peut comprendre une adresse renseignée par l'utilisateur avant la première étape de demande de paiement, par exemple lors d'une étape d'abonnement à un service de location ou à un service de vente. L'adresse peut être renseignée au moment de ou juste avant l'étape de lecture du moyen de paiement et être à usage unique. L'adresse numérique peut également être mémorisée dans une base de données (distante ou non) et extraite depuis la base de données, par exemple une base de données d'un serveur de gestion du service. Elle est alors renseignée une fois par l'utilisateur et extraite à chaque nouvelle transaction. - 9 - L'adresse numérique peut également ou à la place comprendre une adresse renseignée dans un moyen d'identification, le procédé comprenant en outre une étape d'extraction de ladite adresse numérique depuis le moyen d'identification. Cette étape peut être effectuée concomitamment à l'étape de lecture des données de moyen de paiement, le moyen d'identification étant par exemple présenté au moment de ou juste avant la présentation du moyen de paiement. On peut également envisager dans ce cas que le moyen de paiement constitue le moyen d'identification. Ainsi, par une seule étape de lecture, le procédé permet la lecture à la fois de l'adresse numérique et des données relatives au moyen de paiement. Selon une version avantageuse, le procédé selon l'invention peut en outre comprendre une étape de consultation d'une donnée, dite de statut de paiement, avant le déclenchement d'une nouvelle demande d'utilisation du service, notamment suite à l'identification de l'utilisateur, l'utilisation du service étant autorisée ou non en fonction de ladite donnée de statut de paiement. Cette étape est notamment effectuée une fois que la première demande de règlement a été émise. Une telle donnée de statut permet au procédé selon l'invention de déclencher une demande de paiement qui va probablement être refusée ou d'accepter une demande d'achat ou de location pour lequel l'opérateur ne sera probablement pas payé. La donnée de statut de paiement peut être mise à jour : - à chaque requête de consultation de la donnée de statut, à savoir avant chaque nouvelle utilisation du service, - après chaque demande de paiement en fonction de l'issue de la demande de paiement, et/ou - régulièrement à une fréquence déterminée. Dans ce cas, le procédé selon l'invention peut en outre comprendre une étape de consultation de la banque porteur du moyen de paiement, de manière régulière pour déterminer les capacités de paiement du porteur du moyen de paiement, des données relatives au moyen de paiement telle que la date de validité, et/ou la situation du - 10 - moyen de paiement par exemple s'il existe ou non une opposition contre le moyen de paiement. La donnée de statut de paiement est mise à jour en fonction du résultat de ladite consultation. Dans un mode de réalisation particulier, le procédé comprend en outre une étape de génération d'un alias du moyen de paiement, de préférence avant l'étape de lecture des données relatives au moyen de paiement. Il peut alors également comprendre : - une étape d'identification de l'utilisateur, - une étape de mémorisation dudit alias en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur, dans un serveur de gestion, notamment lié au service proposé ; et - une étape de mémorisation dudit alias en association avec les données relatives au moyen de paiement, dans un serveur monétique distinct du serveur de gestion ; dans ce cas, pour chaque paiement, les étapes suivantes : - détermination par le serveur de gestion de l'alias du moyen de paiement associé à l'utilisateur en fonction dudit identifiant de l'utilisateur, - détermination par le serveur monétique des données relatives au moyen de paiement associé audit alias, et - émission, par le serveur monétique, d'une demande de paiement effectif avec lesdites données relatives audit moyen de paiement. L'étape de mémorisation de l'alias peut notamment être effectuée juste avant l'étape de demande de la pré-autorisation par le serveur monétique. Un tel mode de réalisation permet de sécuriser le procédé car les données de carte ne sont pas stockées en association avec les données concernant le service. Lorsque le procédé est mis en oeuvre dans une telle architecture, le procédé peut comprendre les étapes suivantes : le serveur monétique - 11 - obtient les données de compte-rendu de la demande de règlement, les transfère au serveur de gestion, le serveur de gestion mettant en oeuvre l'étape d'émission à destination de l'adresse numérique de l'utilisateur. En variante ou en supplément, le serveur de gestion mémorise dans une base de données l'adresse numérique de l'utilisateur et la transfère au serveur monétique, qui met en oeuvre l'étape d'émission à destination de l'adresse numérique de l'utilisateur. Le procédé selon l'invention peut avantageusement être utilisé dans une installation de location de véhicules proposés à la location sur au moins un site de location pour réaliser la signalisation des paiements effectués. Selon un autre aspect de l'invention, il est proposé un système de signalisation de paiements réalisés avec un moyen de paiement d'un utilisateur, ledit système comprenant : - des moyens de lecture de données relatives audit moyen de paiement depuis ledit moyen de paiement, - des moyens d'émission vers un serveur bancaire d'une demande de règlement, à l'aide des données relatives audit moyen de paiement. 20 Le système comprend en outre des moyens, dits de communication, agencés pour réaliser, pour au moins une demande de règlement, de préférence pour chaque demande, une émission, à une adresse numérique obtenue préalablement, de données, dites de compte-rendu, relatives à l'issue de ladite demande de règlement. 25 Le système selon l'invention comprend un terminal de lecture, et plus particulièrement un terminal de paiement, dans lequel est inséré le moyen de paiement et agencé pour lire les données relatives au moyen de paiement. 30 L'adresse numérique peut être obtenue à l'aide de moyens de saisie, à l'aide de moyens de lecture d'un moyen d'identification ou de moyens de consultation d'une base de données dans laquelle elle est stockée. - 12 - Selon un premier mode du système selon l'invention les moyens de demande de paiement peuvent comprendre : - un premier serveur comprenant des moyens pour : - générer un alias du moyen de paiement, - mémoriser ledit alias avec un identifiant de l'utilisateur, - un deuxième serveur, dit monétique, comprenant des moyens pour : - mémoriser ledit alias du moyen de paiement avec les données relatives audit moyen de paiement, - émettre des demandes de règlement ; les moyens de communication comprenant en outre un module, dit de communication, agencé dans le premier serveur ou dans le deuxième serveur ou encore dans un serveur d'une banque porteur du moyen de paiement. Ainsi, les données relatives au moyen de paiement et l'identifiant de l'utilisateur ne sont pas enregistrés sur un même serveur, ce qui permet de protéger ces données contre une utilisation frauduleuse. Selon un deuxième mode de réalisation du système selon l'invention, 20 les moyens de demande de paiement comprennent : - un serveur, comprenant des moyens pour : - mémoriser les données relatives au moyen de paiement en association avec l'identifiant de l'utilisateur, et - émettre des demandes de règlement ; 25 les moyens de communication comprenant en outre un module, dit de communication, agencé dans ledit serveur ou dans un serveur d'une banque porteur du moyen de paiement. Ce mode de réalisation permet de diminuer les échanges d'information entre les organes du système selon l'invention, et d'éviter 30 d'alourdir les étapes de demandes de paiement et de compte-rendu. Ce mode de réalisation permet également de diminuer les coûts d'un tel système de signalisation. - 13 - Avantageusement, le module de communication peut comprendre une carte SIM pour réaliser une connexion à un réseau GPRS, un modem de connexion au réseau Internet de manière filaire, par Bluetooth® ou par Wifi, et/ou un moyen de connexion au réseau téléphonique filaire. Avantageusement, le terminal de lecture peut être en communication directe, par l'intermédiaire d'un autre organe, avec les moyens de mémorisation et/ou les moyens de demande de paiement. Selon encore un autre aspect de l'invention il est proposé une installation de location de véhicules comprenant : - un site de gestion, dit central, - au moins un site de location de véhicule comprenant au moins un véhicule proposé à la location, ledit site de location étant connecté audit site central, et - un système de signalisation selon l'invention. Dans un mode de réalisation particulièrement avantageux, les moyens de demande de paiement du système de signalisation peuvent disposés au niveau du site de gestion central ainsi que les moyens de communication et les moyens de mémorisation. Dans ce mode de réalisation préféré, le système peut en outre comprendre un terminal de lecture disposé au niveau de chaque site de location. D'autres avantages et caractéristiques apparaîtront à l'examen de la description détaillée de modes de réalisation nullement limitatifs, et des dessins annexés sur lesquels : - la FIGURE 1 est une représentation schématique d'un système selon l'invention et des échanges entre les différents éléments du système ; - la FIGURE 2 est une représentation schématique des étapes d'une première version d'un procédé selon l'invention appliqué à la location de véhicules ; - 14 - - la FIGURE 3 est une représentation schématique d'un deuxième mode de réalisation d'un procédé selon l'invention ; - la FIGURE 4 est une représentation sous la forme d'un diagramme des étapes de déclenchement des demandes de paiements selon l'invention; et - la FIGURE 5 est une représentation schématique d'une installation de location de véhicules mettant en oeuvre un système selon l'invention. Sur les figures et dans la suite de la description, les éléments communs à plusieurs figures conservent la même référence. Dans les exemples décrits ci-dessous le moyen de paiement est avantageusement, mais non limitativement, une carte bancaire. On notera que, dans la suite, les termes « autorisation » et « pré- autorisation » peuvent être utilisés indifféremment, ainsi que les termes « demande de débit » et « demande de paiement » », ou « adresse numérique » et « adresse électronique ». La FIGURE 1 est une représentation schématique d'un système selon l'invention. Le système 100 représenté sur la figure 1 comprend une borne 102, dite d'abonnement, comprenant des moyens d'identification, par exemple un lecteur de carte RFID. La borne d'abonnement peut comprendre d'autres moyens d'identification, notamment des moyens de saisie d'un code personnel. Le système 100 comprend en outre un terminal de paiement 104 pour lire les données relatives à un moyen de paiement, tel qu'un lecteur de carte bancaire. Le système 100 comprend également un serveur de gestion 106, un serveur monétique 108. Le serveur de gestion 106 comprend des moyens de mémorisation d'une base de données 110, et le serveur monétique comprend également une base de données 112 mémorisée localement dans des moyens de mémorisation. - 15 - Le serveur monétique 108 est en communication avec le terminal de paiement par l'intermédiaire d'un premier serveur intermédiaire 114 gérant le terminal de paiement. Le serveur de gestion 106 est en communication avec le serveur monétique 108 par l'intermédiaire d'un deuxième serveur intermédiaire 116, dit « cashpooler » dans le mode de réalisation ici décrit. Le système 100 comprend en outre un module de communication 118 comprenant une carte SIM de connexion au réseau GPRS et agencé pour envoyer des données de compte-rendu ou un ticket virtuel relatifs à l'issue de chaque demande de paiement. Ce module de communication 118 est directement relié au serveur monétique 108. On notera que, dans d'autres modes de réalisation, ce serveur pourrait être relié au serveur de gestion. On décrira un tel mode de réalisation plus loin. Le système 100 est agencé et programmé pour réaliser une demande de paiement (employé par la suite pour paiement effectif) initiale selon un protocole de paiement de pré-autorisation et des demandes de paiement ultérieures selon un protocole de paiement de type vente à distance. On considère que les deux demandes de paiement sont effectuées selon des protocoles distincts car elles ne comprennent pas exactement les mêmes informations et/ou que les informations ne sont pas présentées de la même façon. Les échanges d'informations entre les différents organes du système en vue de réaliser la demande de paiement initiale sont indiqués ci-dessous et sont représentés sur la figure 1 avec des flèches pleines, chaque flèche indiquant le sens de l'échange d'information. La procédure de paiement à l'aide de la demande initiale est initiée par le serveur de gestion 106 sous l'égide d'un téléconseiller, lors par exemple d'une procédure d'abonnement au service de location de véhicule. Elle comprend les étapes suivantes : - PA1 : Emission d'une requête de pré-autorisation avec montant et un alias de carte utilisateur (UID) de 12 caractères alphanumériques du serveur central 106 à la borne d'abonnement 102, - 16 - - PA2 : Transmission de la requête au terminal de paiement 104 avec éventuel ajout des paramètres nécessaires. L'UID est ajouté et aligné, - PA3 : Transmission de la requête au premier serveur intermédiaire 114, - PA4 : Transmission de la requête au serveur monétique 108. L'UID est transmis au format ISO 8583. Le serveur monétique émet la demande de pré-autorisation de paiement vers la banque du porteur du moyen de paiement et reçoit la réponse de la banque suite à la demande de pré- autorisation. Eventuellement le serveur monétique 108 génère un ticket virtuel relatif à la demande d'autorisation de paiement à envoyer à l'utilisateur, - PA5 : Réponse au premier serveur intermédiaire 114 du serveur monétique 108 en ce qui concerne la requête, - PA6 : Transmission, par le premier serveur intermédiaire 114, de la réponse au terminal de paiement 104. Le dossier se voit assigner par ce serveur un identifiant unique sur 12 caractères. Il s'agit là d'une donnée de pré-autorisation ou une donnée d'erreur ou de refus. Lors de cette étape le résultat de la demande d'autorisation peut également être affiché sur un écran d'affichage au niveau du terminal de paiement 104, - PA7 : La donnée est transmise à la borne de location 102, - PA8 : La donnée est transmise au serveur de gestion 106 (retour d'erreur, ou identifiant (ID) de pré-autorisation). Eventuellement, lorsqu'un ticket virtuel est généré par le serveur monétique 108 suite à la réception de la réponse de la banque porteur, les étapes suivantes peuvent être réalisées : - PA9 : le serveur de gestion 106 envoie au serveur monétique l'adresse virtuelle de l'utilisateur, soit directement tel que représenté sur la figure 1, soit par l'intermédiaire du serveur intermédiaire 114, - 17 - - PA10 : le serveur monétique transfère le ticket virtuel et l'adresse monétique de l'utilisateur au module de communication, - PA11 : le ticket virtuel est envoyé par le module de communication 118 à l'utilisateur, par exemple sous la forme d'un message texte, au travers d'un réseau de communication 120, par exemple de type GPRS. La donnée de pré-autorisation est ensuite utilisée pour réaliser une demande de paiement, dite initiale, initiée par le serveur de gestion au moment voulu, selon les opérations suivantes : - PP1 : Requête de paiement envoyée au premier serveur intermédiaire 114 en utilisant l'identifiant de pré-autorisation et l'alias UID, - PP2 : La requête est relayée au serveur monétique 108. Le serveur monétique 108 génère et envoie la demande de paiement à la banque du porteur du moyen de paiement et reçoit une réponse en retour. Cette demande comprend, suite à l'intervention du serveur monétique, les données relatives au moyen de paiement. Le serveur monétique 108 génère alors un ticket virtuel récapitulant le résultat de la demande de paiement, - PP3 : La réponse reçue est relayée par le serveur monétique 108 au premier serveur intermédiaire 114, et - PP4 : La réponse est relayée par le premier serveur intermédiaire 114 au serveur de gestion 106, - PP5 : Le serveur de gestion 106 transmet une adresse électronique de l'utilisateur au serveur monétique 108, soit directement telle que représenté sur la figure 1, soit par l'intermédiaire du premier serveur intermédiaire 114, - PP6 : le serveur monétique 108 transmet le ticket virtuel généré et l'adresse numérique au module de communication 118, et - 18 - - PP7 : Le module de communication 118 envoie le ticket virtuel à l'adresse numérique au travers du réseau de communication 120. Les échanges d'informations entre les différents organes du système en vue de réaliser la demande de paiement ultérieure sont indiqués ci-dessous et sont représentés sur la figure 1 avec des flèches en pointillés, chaque flèche indiquant le sens de l'échange d'information. La procédure de paiement à l'aide d'une demande ultérieure est initiée par le serveur de gestion 106 en fonction de critères de test prédéterminés qui seront décrits plus loin et comprend les étapes suivantes : - VD1 : Requête de paiement envoyée par le serveur de gestion 106 sur le deuxième serveur intermédiaire 116 (UID et montant) ; - VD2 : la requête est envoyée au serveur monétique 108, qui génère une demande de paiement ultérieure comprenant les données du moyen de paiement. Le serveur monétique reçoit la réponse de la banque concernant la demande d'autorisation de débit. Le serveur monétique 108 génère un ticket virtuel à envoyer à l'utilisateur ; - VD3 : la réponse de la banque est transmise par le serveur monétique 108 au deuxième serveur intermédiaire 116, et - VD4 : la réponse est relayée par le deuxième serveur intermédiaire 116 au serveur de gestion 106 ; - VD5 : le serveur de gestion 106 transmet une adresse électronique de l'utilisateur au serveur monétique 108, soit directement tel que représenté sur la figure 1, soit par l'intermédiaire du deuxième serveur intermédiaire 116 ; - VD6 : le serveur monétique 108 transmet le ticket virtuel généré et l'adresse numérique au module de communication 118 ; et - VD7 : le module de communication 118 envoie le ticket virtuel à l'adresse numérique au travers du réseau de communication 120. - 19 - Les étapes de transfert d'argent entre les banques ne sont pas décrites ici. Dans ce mode de réalisation, il existe un serveur intermédiaire entre le terminal de paiement et le serveur monétique et un autre serveur intermédiaire, appelé « Cashpooler », entre le serveur de gestion et le serveur monétique. Ces serveurs sont représentés dans le schéma par exemples car les services de paiement sont effectués par différents prestataires. Toutefois, le serveur monétique pourrait être directement relié au terminal de paiement et au serveur de gestion de location sans présence de ces serveurs intermédiaire, ou en présence d'un unique serveur intermédiaire. Par ailleurs, dans un autre mode de réalisation le serveur monétique et le serveur de gestion peuvent être intégrés dans un serveur unique, auquel cas les échanges d'informations entre ces serveurs ne sont pas réalisés. Ce mode de réalisation nécessite toutefois une sécurisation lourde du serveur de gestion, peu pratique. Dans un mode de réalisation très simplifié, le système selon l'invention comprend uniquement un terminal de paiement muni de moyens de lecture, un serveur de paiement réalisant les demandes de paiement auprès de la banque de l'utilisateur, un moyen de mémorisation, et un module de communication agencé pour envoyer les tickets virtuels. Tous les autres organes décrits plus haut en référence à la figure 1 sont optionnels et peuvent être ajoutés individuellement à un tel système simplifié. La FIGURE 2 est une représentation sous la forme d'un diagramme d'un premier mode de réalisation d'un procédé selon l'invention, mis en oeuvre dans un système dans lequel il n'y a pas de serveurs intermédiaires. Dans ce procédé, contrairement à ce qui a été indiqué dans l'architecture représentée à la figure 1, c'est le serveur de gestion 106 qui - 20 - est l'émetteur du ticket virtuel. Le module de communication 118 est donc relié à ce serveur 106 et non au serveur monétique 108. Le procédé 200 représenté sur la figure 2 comprend tout d'abord une phase d'initialisation 202. La phase d'initialisation 202 comprend une étape 204 pendant laquelle l'utilisateur indique son identité et des informations personnelles, par exemple en scannant un papier d'identité qui peut par exemple être son permis de conduire. Pendant cette étape l'utilisateur indique également une adresse électronique à laquelle doivent être envoyées les données de compte-rendu ou le ticket virtuel. Cette étape 204 est réalisée au niveau d'une borne d'abonnement à un service donné, tel qu'un service de location de véhicules, ou encore une caisse quelconque. Cette borne est bien évidemment reliée au serveur de gestion par l'intermédiaire d'un réseau, par exemple un réseau de type Internet. A l'étape 206 ces données sont transmises à un serveur de gestion, par exemple le serveur de gestion 106 de la figure 1. Une fois ces formalités effectuées, le serveur de gestion mémorise un identifiant associé à l'utilisateur à l'étape 208 et mémorise également l'adresse électronique, et éventuellement les données d'identité fournies à l'étape 204. L'identifiant relatif à l'utilisateur peut être généré au niveau du serveur de gestion ou de la borne d'abonnement. A l'étape 210, un moyen d'identification est fourni à l'utilisateur par la borne, tel que par exemple une carte RFID. On notera que le moyen d'identification reçu par l'utilisateur peut être d'un autre type que celui décrit (un code personnel, un code barre, une carte magnétique, etc.). Lorsque l'utilisateur dispose déjà d'un identifiant et à déjà préalablement renseigné une adresse électronique, les étapes 202 à 210 ne sont pas réalisées et sont remplacées par une étape (non représentée) de lecture de l'identifiant de l'utilisateur. Dans ce mode de réalisation, les étapes 202 à 210 constituent en tout cas les étapes d'identification de l'utilisateur. - 21 - A l'étape 212, l'utilisateur choisit un abonnement auquel qu'il désire souscrire. Le choix de l'abonnement est transmis au serveur de gestion à l'étape 214. Le serveur de gestion génère alors un alias de moyen de paiement et l'enregistre en association avec l'identifiant à l'étape 216. A l'étape 218, le serveur transmet l'alias à la borne, en association avec d'autres données de paiement, comprenant notamment le montant à prélever. A l'étape 220, l'alias et les données liées au paiement sont transmis au terminal. Celui-ci dispose alors de tous les éléments pour initier la transaction. A l'étape 222, l'utilisateur insère un moyen de paiement dans le terminal. Les données relatives au moyen de paiement sont lues de façon classique, l'utilisateur saisit son code confidentiel pour vérifier qu'il est un porteur autorisé de la carte (code PIN). Les interactions de l'utilisateur avec le terminal de paiement sont des interactions classiques. Si le code PIN est erroné, la carte est bloquée et la transaction est refusée et l'utilisateur en est informé. Si le code PIN est correct, le terminal de paiement extrait les données de la carte permettant d'effectuer le paiement (identifiant de la carte et date d'expiration notamment). Ces données peuvent éventuellement comprendre une adresse électronique enregistrée dans le moyen de paiement. Dans ce cas, il n'est pas nécessaire pour l'utilisateur de renseigner une adresse électronique lors de l'étape 202, cette adresse étant extraite des données lues depuis le moyen de paiement, envoyée au serveur de gestion et enregistrée au niveau au niveau de ce serveur. L'alias et les données relatives au moyen de paiement sont alors transmis au serveur monétique lors de l'étape 224. A l'étape 226, le serveur monétique enregistre l'alias en association avec les données relatives au moyen de paiement. A l'étape 228, le serveur monétique émet une demande d'autorisation de paiement auprès de la banque de l'utilisateur, à l'aide des données du - 22 - moyen de paiement et des autres données liées au paiement transmises par le terminal et obtient la réponse de la banque. Suite à la réception de la réponse, le serveur monétique génère un accusé de réception et un ticket virtuel. L'accusé de réception peut comprendre soit une donnée d'acceptation, sous la forme d'une donnée de pré-autorisation, soit un refus. Le ticket virtuel est généré en fonction du contenu de la réponse de la banque de l'utilisateur. L'accusé de réception est transmis avec l'alias du moyen de paiement 10 et le ticket virtuel au terminal de paiement à l'étape 230, qui peut éventuellement renseigner visuellement l'utilisateur sur l'issue de la demande de paiement. A l'étape 232, le terminal de paiement transmet l'accusé de réception, l'alias du moyen de paiement et le ticket virtuel au serveur de gestion par 15 l'intermédiaire de la borne de paiement. Le serveur de gestion mémorise l'accusé de réception à l'étape 234 en association avec l'identifiant de l'utilisateur. A l'étape 236, le serveur de gestion extrait l'adresse électronique de l'utilisateur de sa base de données. 20 Le serveur de gestion transmet le ticket virtuel à l'utilisateur à l'étape 238, éventuellement à l'aide d'un module de communication. Les étapes 202 à 238 constituent la phase d'initialisation 202 du procédé 200. Suite à cette phase d'initialisation, qui ne dure que quelques dizaines de secondes, l'utilisateur peut retirer sa carte du terminal de 25 paiement. Puis, le serveur de gestion teste à une fréquence donnée si le compte de l'utilisateur doit être débité ou non (tel qu'il sera décrit plus loin). Dès que le serveur détermine que le compte de l'utilisateur doit 30 réellement être débité et le montant qui doit être débité, les étapes suivantes sont réalisées. Il s'agit de la phase 240 de première demande de paiement, à la demande de paiement initiale. - 23 - Le serveur de gestion envoie au serveur monétique la donnée de pré-autorisation et l'alias à l'étape 242. A l'étape 244, le serveur monétique émet une demande de paiement auprès de la banque de l'utilisateur à l'aide de la donnée de pré-autorisation et des données de moyen de paiement extraites de sa base de données et obtenues grâce à l'alias transmis par le serveur de gestion, et obtient la réponse de la banque. Suite à la réception de la réponse, le serveur monétique génère un accusé de réception et un ticket virtuel. La réponse à ce niveau ne peut être que positive puisque l'autorisation de débit a déjà été obtenue. A l'étape 246, le serveur monétique transmet l'accusé de réception et le ticket virtuel au serveur de gestion qui le mémorise. Comme décrit auparavant, le serveur de gestion transmet le ticket virtuel à l'utilisateur à l'étape 248, éventuellement à l'aide d'un module de communication, en indiquant le montant exact du débit, qui peut être différent du montant pour lequel une autorisation de débit avait été obtenue. La phase 240 de demande de paiement initiale selon un premier protocole de paiement de type pré-autorisation est alors terminée. Le procédé 200 comprend alors une ou plusieurs phases 250 de demande de paiement ultérieure selon un deuxième protocole de paiement de type vente à distance. Dans ce cas, le serveur de gestion teste à une fréquence donnée si une demande de paiement doit être effectuée tel que nous verrons plus loin. Dès qu'une demande de paiement est à effectuer les étapes suivantes sont réalisées. Le serveur de gestion envoie au serveur monétique les informations relatives au paiement, à savoir par exemple le montant à débiter, l'alias du moyen de paiement, à l'étape 252. A l'étape 254, le serveur monétique émet une demande de paiement auprès de la banque de l'utilisateur, à l'aide des données de moyen de paiement extraites de sa base de données et obtenues grâce à l'alias transmis par le serveur de gestion. La demande de paiement ultérieure ne - 24 - comprend pas la donnée de pré-autorisation puisqu'elle n'est pas effectuée en rapport avec une telle pré-autorisation. En fonction de la réponse obtenue, le serveur monétique génère un accusé de réception et un ticket virtuel. La réponse à ce niveau peut être positive ou négative. A l'étape 256, le serveur monétique transmet l'accusé de réception et le ticket virtuel au serveur de gestion qui le mémorise. Le serveur de gestion transmet le ticket virtuel à l'utilisateur à l'étape 258, éventuellement à l'aide d'un module de communication. La phase 250 de demande de paiement ultérieure selon un deuxième protocole de type vente à distance est alors terminée. Dans un autre mode de réalisation, le procédé 200 peut comprendre seulement des demandes de paiement selon le protocole de pré-autorisation. Dans ce cas, la phase 256 n'est pas réalisée et la phase 228 peut être réitérée à plusieurs reprises. Dans encore un autre mode de réalisation, un unique serveur est utilisé en tant que serveur monétique et serveur de gestion. Dans ce cas, il n'y a pas lieu de réaliser toutes les étapes décrites plus haut consistant à la génération d'un alias et à la transmission de données, directement ou indirectement, entre le serveur de gestion et le serveur monétique. Dans le cas où l'architecture comprend un serveur de gestion, un serveur monétique et éventuellement au moins un serveur intermédiaire, on notera bien que le ticket virtuel peut être émis par le serveur monétique ou par un serveur intermédiaire, notamment celui associé au terminal de paiement. Tous les modes de réalisation peuvent être combinés entre eux de manière non limitative. Ainsi, le ticket virtuel envoyé à l'utilisateur comprend a minima des données relatives au résultat de la demande d'autorisation de débit ou la demande de paiement, à savoir : -25- - des données d'acceptation ou de refus d'une demande d'autorisation de débit d'un montant majoré, ou - des données d'acceptation ou de refus d'une demande de transaction réelle, c'est-à-dire une demande de paiement, pour un montant réellement débité sur compte du client. Il peut également comprendre des données relatives : - au type de demande de paiement, et/ou - au moyen de paiement (numéro masqué de la carte bancaire notamment), et/ou - au destinataire de la transaction (enseigne du destinataire, numéro de SIRET du destinataire, etc.), et/ou - au montant (exprimé en chiffres et/ou en lettres), et/ou - à la date ou l'heure de la transaction, et/ou - à l'issue de la demande de paiement. Il peut également comprendre un numéro de dossier et/ou un numéro de transaction ou encore d'autres informations. On notera que le serveur peut générer deux versions du ticket virtuel en fonction du type de l'adresse numérique choisie par l'utilisateur. L'adresse numérique peut ne pas être fournie par l'utilisateur mais par la banque de l'utilisateur lors de la demande de paiement émise par le serveur monétique. L'adresse numérique peut notamment être : - un numéro de téléphone, auquel cas le ticket virtuel est envoyé par SMS à travers un réseau GPRS, et de préférence sous forme condensée, - une adresse de courrier électronique, auquel cas le ticket virtuel est envoyé par courriel à travers un réseau de type Internet, et de préférence sous forme complète. L'émetteur du message contenant le ticket virtuel est de préférence toujours le même pour en faciliter l'archivage par l'utilisateur. - 26 - On va maintenant décrire, en référence à la FIGURE 3, un mode de réalisation 300 très simplifié d'un procédé selon l'invention. Le système mettant en oeuvre le procédé décrit en référence à la figure 3 comprend un unique serveur, dit de paiement, muni de moyens de mémorisation et d'un module de communication, et un terminal de paiement comprenant des moyens de lecture d'un moyen de paiement tel qu'une carte bancaire. Tous les autres organes décrits plus haut en référence à la figure 1 sont optionnels et peuvent être ajoutés individuellement à un tel système simplifié. Le procédé 300 comprend les étapes suivantes : - étape 302 : l'utilisateur saisit au niveau du terminal de paiement une adresse numérique à laquelle il souhaite recevoir un ticket virtuel ; - étape 303 : l'utilisateur insère dans le terminal de paiement sa carte bancaire. Il saisit éventuellement un code PIN permettant de vérifier qu'il est le porteur de la carte. On notera que les étapes 302 et 303 peuvent être inversées. L'adresse virtuelle pourrait également déjà être mémorisée dans le serveur de paiement ou extraite de la carte bancaire. - étape 304 : envoi par le terminal de paiement des données bancaires au serveur de paiement, et de l'adresse numérique ; - une étape 306 : mémorisation par le serveur de paiement des données bancaires en association avec l'adresse numérique et éventuellement avec d'autres données ; - une étape 308 : émission par le serveur d'une demande de paiement effectif comprenant les données bancaires ; - une étape 310 : réception de la réponse de la banque de l'utilisateur avec un accusé de réception et mémorisation de l'accusé de réception. ; et - une étape 312 : génération du ticket virtuel à partir de l'accusé de réception. On pourrait également envisager que le ticket virtuel soit l'accusé de réception ; - 27 - - une étape 314 : émission à l'utilisateur (par le biais de son adresse numérique) d'un ticket virtuel comprenant les données de compte-rendu de la demande de paiement ; - une étape 316 optionnelle, dans laquelle on transfère également l'accusé de réception (voire le ticket virtuel) en direction du terminal de paiement, de sorte que le destinataire de la transaction puisse lui aussi obtenir les données relatives à celle-ci. La FIGURE 4 est une représentation schématique sous la forme d'un organigramme des étapes de déclenchement des demandes de paiement. Dans la figure 4 le sigle SG désigne le serveur de gestion 106 et le sigle SM désigne le serveur monétique 108 de la figure 1. Dans le mode de réalisation décrit en référence à la figure 4, le 15 procédé émet une première demande de paiement selon un protocole de paiement pré-autorisation et au moins une deuxième demande de paiement selon un protocole de paiement de type vente à distance. Une première étape 402 permet de déterminer si une demande de paiement initiale a été générée. 20 Si non, une étape de test 404 est réitérée tous les soirs. Lors de cette étape 304 le serveur de gestion vérifie les critères suivants : - que la durée de validité de l'autorisation est sur le point d'expirer (dans moins de 24 heures) : cette information sur la durée de validité est obtenue grâce à une donnée de validité de la pré- 25 autorisation ; - que le montant de compte dédié à l'utilisateur dépasse le montant maximal autorisé par l'autorisation ; cette information sur le montant maximum est obtenue grâce à une donnée de montant de la pré-autorisation. 30 Si ces tests renvoient une réponse négative, aucune demande de paiement initiale n'est générée. En revanche, si un ou plusieurs des tests renvoient une réponse positive, le serveur génère une première requête de paiement à l'étape 406. - 28 - Pour cela, il envoie au serveur monétique, éventuellement à l'aide d'un serveur intermédiaire, de préférence également relié au terminal de paiement, un fichier contenant notamment l'identifiant de pré-autorisation préalablement obtenue, l'alias et l'adresse numérique. Le fichier comprend également le montant demandé, ce montant étant forcément inférieur ou égal au montant maximum indiqué dans l'autorisation. Le serveur monétique génère ensuite, lors de l'étape 408, une demande de paiement, dite initiale, comprenant l'identifiant de pré-autorisation et des données relatives au moyen de paiement extraites de sa base de données à partir de l'alias et l'envoie à un serveur de la banque du porteur de la carte bancaire. Elle est envoyée au serveur de la banque du porteur de la carte bancaire dans un premier format prédéterminé. Le serveur de la banque du porteur de la carte bancaire renvoie ensuite un accusé de réception au serveur monétique, qui le transmet au serveur de gestion à l'étape 410. Le serveur de la banque du porteur commande le transfert du montant correspondant depuis le compte bancaire de l'utilisateur associé à la carte jusqu'au compte bancaire associé au service de location. Un compte-rendu est également envoyé au serveur de gestion par l'intermédiaire du serveur monétique. A l'étape 412, le serveur monétique envoie un ticket virtuel à l'utilisateur. Suite à la première demande de paiement, le serveur de gestion efface l'identifiant d'autorisation ou indique qu'il n'est plus valide. Il conserve en revanche l'alias de carte. Si après l'étape 402, une première demande de paiement est déjà réalisée, le serveur de gestion de location vérifie également journalièrement les critères suivants à l'étape 414 : - durée depuis le dernier paiement supérieure à une durée prédéterminée ? - montant du compte dédié à l'utilisateur supérieur à un montant prédéterminé ? - 29 - Si ces tests renvoient une réponse négative, aucune requête de paiement n'est générée et l'étape 414 est réitérée journalièrement jusqu'à ce qu'au moins un de ces critères renvoie une réponse positive. Si un ou plusieurs des tests renvoient une réponse positive, le serveur génère une seconde requête à l'étape 416. On notera qu'une seconde requête est également générée quasi-simultanément à la première lorsque le montant du compte dédié à l'utilisateur dépasse le montant maximal autorisé dans l'autorisation et qu'aucun paiement n'a été effectué auparavant. Dans ce cas, la première demande de paiement générée par le serveur monétique est à hauteur du montant maximum autorisé par la pré-autorisation de débit et la deuxième demande de paiement est effectuée pour le montant restant du compte, qui n'aura pas été payé par la première demande de paiement. Pour générer la seconde requête, le serveur de gestion envoie, à l'étape 416, au serveur monétique, éventuellement à l'aide d'un serveur intermédiaire, qui peut être différent du serveur intermédiaire déjà évoqué en relation avec la première requête, un fichier contenant notamment l'alias de carte. Le fichier comprend également le montant demandé, mais ne comprend pas l'identifiant d'autorisation puisque ce dernier a été effacé après la première demande de paiement. Le serveur monétique génère une demande de paiement à partir des données associées à l'alias extraites de sa base de données et envoie la demande de paiement à un serveur de la banque du porteur de la carte bancaire à l'étape 418. La demande de paiement est envoyée au serveur de la banque du porteur de la carte bancaire dans un deuxième format prédéterminé, généralement distinct du premier format. Le serveur de la banque du porteur de carte vérifie alors certaines données relatives à la carte à l'étape 420 : son existence, sa validité - date d'expiration postérieure, pas d'opposition -. Si la transaction est acceptée, le serveur de la banque du porteur renvoie ensuite, à l'étape 422, un accusé de réception au serveur monétique qui le transmet au serveur de gestion de location. - 30 - Un ticket virtuel comprenant le résultat de la transaction est envoyé à l'utilisateur à l'étape 424. Le serveur de la banque du porteur commande en outre le transfert du montant correspondant depuis le compte bancaire de l'utilisateur associé à la carte vers le compte bancaire associé au service de location. Un compte-rendu est également envoyé au serveur de gestion par l'intermédiaire du serveur monétique. Si ce transfert n'est pas possible, par exemple car le porteur n'a pas assez d'argent sur son compte ou car la carte de paiement est considérée comme non valable, le transfert est annulé, et le serveur monétique en est informé, à l'étape 426, ainsi que le serveur de gestion par son intermédiaire. Dans ce cas, le serveur de la banque renvoie au serveur monétique, qui transmet au serveur de gestion un message d'erreur. A réception d'un tel message d'erreur, le serveur de gestion peut modifier, lors d'une étape 428, une donnée relative à l'utilisateur, notamment à l'alias de carte, par exemple une donnée de statut de paiement, indiquant que l'utilisateur n'est plus en mesure de payer avec sa carte. Un ticket virtuel est également envoyé à l'utilisateur à l'étape 430 indiquant le résultat de la transaction. La donnée de statut de paiement, ainsi par exemple qu'une donnée d'expiration de la carte, transmise du serveur monétique au serveur de gestion peut être vérifiée avant toute demande de location/achat ultérieur de l'utilisateur. Ainsi, on peut empêcher l'utilisateur de louer un véhicule sans qu'il ait honoré tous ses paiements précédents. Lorsque l'utilisateur remet une carte de paiement dans le terminal de paiement pour effectuer à nouveau la séquence d'initialisation, un nouvel alias de carte peut être généré qui remplace l'autre. - 31 - On notera que de nombreuses étapes sont optionnelles à savoir par exemple toutes les étapes relatives à la génération d'un alias et à l'émission d'un ticket virtuel. Il est également possible que les différents fichiers transmis par le serveur de gestion soient du même format. Mais les informations contenues dans ces fichiers ne seront pas les mêmes et elles ne déclencheront pas les mêmes opérations au niveau des échanges entre le serveur monétique et le serveur de la banque du porteur de la carte de paiement. C'est pour cela qu'on considère que les demandes de paiement ne sont pas effectuées à l'aide du même protocole. Il est également possible que les serveurs monétique et de gestion soient confondus, l'existence de l'alias de carte n'étant alors pas nécessaire. Le déclenchement de l'émission des demandes de paiement peut également être effectué de façon différente de ce qui a été déterminé (par exemple à une date précise du mois, tous les mois). En variante, à chaque identification de l'utilisateur, on émet une demande de paiement, en ayant préférablement vérifié si le montant du compte de l'utilisateur était supérieur à un montant prédéterminé (0E). La FIGURE 5 est une représentation schématique d'une installation de location automatisée de véhicules électriques mettant en oeuvre un système selon l'invention. L'installation 500 représenté sur la figure 1 comprend un site central 502 (également appelé organe central dans la suite de la description) connecté à plusieurs sites - ou stations - 5041-504n, dits de location au travers d'un réseau de communication 506 sans fil, par exemple GPRS, ou d'un réseau filaire, par exemple de type DSL. De préférence, chaque site 504 est relié au site central 502 par l'intermédiaire de deux réseaux distincts, ce qui permet une connexion en continu même si l'un des réseaux est défaillant. - 32 - Chaque site de location 504 comprend une borne d'abonnement 102 pour l'enregistrement d'un nouvel abonné, une borne de location 510 pour la location d'un véhicule et plusieurs bornes de charge 512-516, chaque borne de charge étant prévue pour charger un véhicule muni d'une batterie électrique à un emplacement de stationnement. Le site central 502 peut être connecté directement à chacune des bornes d'un site de location 504 au travers du réseau 506 ou seulement à la borne d'abonnement et/ou à la borne de location et/ou aux bornes de charge 512-516. Au moins deux bornes d'un site de location 504 sont connectées entre elles au travers d'une connexion filaire (non représentée). Le site central 502 comprend le serveur de gestion 106, le serveur monétique 108 ainsi que les moyens de mémorisation 110 et 112 dans lesquels sont mémorisées les différentes données décrites plus haut en référence à la figure 1. Le site central comprend en outre le module communication 118. Certains sites de location 504 comprennent une borne d'abonnement équipée d'un terminal de paiement 104. Chaque borne d'abonnement comprend des moyens (non représentés) pour lire un identifiant d'un utilisateur ainsi que des moyens (non représentés) pour recevoir et transmettre au site central des données d'identité d'un utilisateur. Sur cette figure les serveurs intermédiaires ne sont pas représentés, ces serveurs intermédiaires étant optionnels. Bien entendu l'invention n'est pas limitée aux exemples qui viennent d'être décrits. REVENDICATIONS1. Procédé (200 ; 500) de signalisation de paiements réalisés avec un moyen de paiement d'un utilisateur, ledit procédé comprenant les étapes suivantes : lecture, par un terminal de paiement, de données relatives audit moyen de paiement depuis ledit moyen de paiement, - émission vers un serveur bancaire d'une demande de règlement, à l'aide des données relatives audit moyen de paiement ; ledit procédé comprenant en outre, préalablement à ladite étape d'émission de la demande de règlement, une étape de mémorisation de ladite adresse numérique dans un serveur distant du terminal de paiement ; ledit procédé étant caractérisé en ce qu'il comprend une émission (246, 254, 15 264 ; 520), à une adresse numérique obtenue préalablement, de données, dites de compte-rendu, relatives à l'issue de ladite demande de règlement, telles qu'un ticket virtuel. 2. Procédé selon la revendication 1, comprenant les étapes suivantes : 20 - émission vers le serveur bancaire d'une demande de pré- autorisation, à l'aide des données relatives audit moyen de paiement, puis - si la pré-autorisation a été obtenue, émission vers le serveur bancaire d'une demande de paiement effectif, à l'aide des données 25 relatives audit moyen de paiement et d'une donnée de pré- autorisation caractéristique de la pré-autorisation, la demande de règlement étant constituée par l'une et/ou l'autre des demandes de pré-autorisation et de paiement effectif. 30 3. Procédé (200) selon la revendication 2, caractérisé en ce que la demande de paiement effectif (228), dite initiale, est effectuée selon un premier protocole de paiement, le procédé comprenant en outre l'émission d'au moins une autre demande de paiement effectif (256), dite ultérieure, selon- 34 - un deuxième protocole de paiement, notamment indépendant de la demande de pré-autorisation. 4. Procédé selon la revendication 3, dans lequel une étape d'émission de 5 données de compte-rendu est également effectuée suite à la demande de paiement ultérieure. 5. Procédé selon l'une des revendications 3 et 4, mis en oeuvre dans le cas de paiements répétés, caractérisé en ce qu'une demande de règlement, 10 notamment de paiement effectif, est déclenchée : - lors de chaque utilisation du service réalisée par l'utilisateur, et/ou - lorsqu'un compte client, associé à l'utilisateur et incrémenté à chaque utilisation du service, atteint un montant maximum 15 prédéterminé, ledit procédé comprenant en outre une étape de consultation d'un montant associé à audit compte à chaque nouvelle opération d'achat ou de location ou à une fréquence donnée, et/ou - lorsque la précédente demande de paiement pour ledit 20 utilisateur a été effectuée depuis une durée maximale prédéterminée, ledit procédé comprenant en outre une consultation de la date de ladite dernière demande de paiement à chaque nouvelle opération d'achat ou de location ou à une fréquence donnée ; 25 ledit utilisateur s'identifiant lors de chaque utilisation grâce à son identifiant. 6. Procédé selon (200 ; 500) l'une quelconque des revendications précédentes, caractérisé en ce que les données de compte-rendu comprennent des données relatives : 30 - au type de demande de paiement, et/ou - au moyen de paiement, et/ou - au destinataire de la transaction, et/ou au montant, et/ou- 35 - - à la date ou l'heure de la transaction, et/ou à l'issue de la demande de paiement, - à une adresse Internet, notamment un lien, à consulter pour obtenir un compte-rendu de l'issue de la demande de règlement. 5 7. Procédé (200,500) selon l'une quelconque des revendications précédentes, caractérisé en ce que l'adresse numérique comprend : - une adresse de courriel, les données de compte rendu étant alors émises au travers d'un réseau de type Internet, ét/ou 10 - un numéro de téléphone mobile, les données de compte-rendu étant alors émises au travers d'un réseau de type GPRS. 8. Procédé (200 ; 500) selon l'une quelconque des revendications précédentes, caractérisé en ce que l'adresse numérique comprend une 15 adresse renseignée par l'utilisateur avant l'étape de demande de paiement. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'adresse numérique comprend une adresse renseignée dans un moyen d'identification, le procédé comprenant en outre une étape 20 d'extraction de ladite adresse numérique depuis le moyen d'identification. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape (332) de consultation d'une donnée, dite de statut de paiement, avant une nouvelle demande 25 d'utilisation du service, l'utilisation du service étant autorisée ou non en fonction de ladite donnée de statut de paiement. 11. Procédé (200 ; 500) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre : 30 une étape d'identification de l'utilisateur, des étapes de génération d'un alias puis de mémorisation dudit alias en association avec au moins une donnée relative à l'utilisateur,- 36 - notamment un identifiant de l'utilisateur, dans un serveur de gestion, notamment lié au service proposé ; et une étape de mémorisation dudit alias en association avec les données relatives au moyen de paiement, dans un serveur monétique distinct du serveur de gestion. 12. Procédé (200 ; 500) selon la revendication 11, caractérisé en ce qu'il comprend, pour chaque paiement, les étapes suivantes : détermination par le serveur de gestion de l'alias du moyen de paiement associé à l'utilisateur en fonction dudit identifiant de l'utilisateur, détermination par le serveur monétique des données relatives au moyen de paiement associé audit alias, et émission, par le serveur monétique, d'une demande de paiement effectif avec lesdites données relatives audit moyen de paiement. 13. Procédé selon l'une quelconque des revendications 11 et 12, dans lequel le serveur monétique obtient les données de compte-rendu de la demande de règlement, les transfère au serveur de gestion, le serveur de gestion mettant en oeuvre l'étape d'émission à destination de l'adresse numérique de l'utilisateur. 14. Procédé selon l'une quelconque des revendications 11 et 12, dans lequel le serveur de gestion mémorise dans une base de données l'adresse numérique de l'utilisateur et la transfère au serveur monétique, qui met en oeuvre l'étape d'émission à destination de l'adresse numérique de l'utilisateur. 15. Application du procédé selon l'une quelconque des revendications 30 précédentes dans une installation (400) de location de véhicules proposés à la location sur au moins un site de location (404).- 37 - 16. Système (100) de signalisation de paiements réalisés avec un moyen de paiement d'un utilisateur, ledit système comprenant : des moyens de lecture de données relatives audit moyen de paiement depuis ledit moyen de paiement, lesdits moyens de lecture comprenant un terminal de paiement, des moyens de mémorisation d'une adresse numérique dans un serveur distant dudit terminal de paiement, - des moyens d'émission vers un serveur bancaire d'une demande de règlement, à l'aide des données relatives audit moyen de paiement, 10 ledit système (100) étant caractérisé en ce qu'il comprend en outre des moyens (118), dits de communication, agencés pour réaliser, pour au moins une demande de règlement, de préférence pour chaque demande une émission, à une adresse numérique obtenue préalablement, de données, dites de compte-rendu, relatives à l'issue de ladite demande de règlement. 15 17. Système (100) de paiement selon la revendication 16, caractérisé en ce que les moyens de demande de règlement comprennent : un premier serveur (106), comprenant les moyens pour : - générer un alias du moyen de paiement, 20 mémoriser ledit alias avec un identifiant de l'utilisateur, - un deuxième serveur (108), dit monétique, comprenant les moyens pour : - mémoriser ledit alias du moyen de paiement avec les données relatives audit moyen de paiement, 25 - émettre des demandes de règlement ; les moyens de communication comprenant un module (118), dit de communication, agencé dans le premier serveur (106) ou dans le deuxième serveur (108) ou encore dans un serveur d'une banque porteur du moyen de paiement. 30 18. Installation (400) de location de véhicule comprenant : - un site (402) de gestion, dit central,- 38 - au moins un site (404) de location de véhicule comprenant au moins un véhicule proposé à la location, ledit site (404) de location étant connecté audit site (402) central, et un système (100) de signalisation selon l'une quelconque des revendications 16 ou 17.