FR2980890A1 - Procede et systeme de paiement, application a la location automatisee de vehicules. - Google Patents

Abstract

L'invention concerne un procédé pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à un utilisateur, ledit procédé comprenant : - une première phase, dite d'initialisation, comprenant les étapes suivantes : - identification d'un utilisateur, - lecture, par un terminal de paiement, de données relatives audit moyen de paiement depuis ledit moyen de paiement, et - mémorisation desdites données relatives au moyen de paiement, en association avec au moins une donnée relative à l'utilisateur; et - une phase, dite de paiement, comprenant les étapes suivantes : - émission d'une demande de paiement, dite initiale, selon un premier protocole de paiement, et - émission d'au moins une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement différent du premier protocole de paiement. L'invention concerne également un système mettant en oeuvre un tel procédé et une application d'un tel procédé et d'un tel système à la location automatisée de véhicules.

Description

- 1 - « Procédé et système de paiement, application à la location automatisée de véhicules » La présente invention concerne un procédé de paiements répétés 5 dans le temps, avec un même moyen de paiement, pour le paiement d'un service, notamment d'achats ou de locations de biens. Elle concerne également un système de paiement mettant en oeuvre un tel procédé de paiement. L'invention concerne également une application d'un tel procédé à la location de véhicules et une installation de location de véhicule mettant en 10 oeuvre un tel système Le domaine de l'invention est le domaine des paiements répétés dans le temps avec un même moyen de paiement, par exemple une carte bancaire, lors d'achat ou de locations de biens ou de services. L'invention 15 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 20 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. 25 L'un des objectifs d'un service de location automatisé de véhicules est la fourniture d'un moyen de locomotion de manière sûre et flexible. Le paiement d'un tel service doit alors être également flexible et sûr à la fois pour l'utilisateur et pour l'opérateur. 30 On connaît dans l'état de l'art, notamment du brevet FR 2 863 089, un système de location de cycles dans lequel l'utilisateur met sa carte bancaire dans un automate et compose son code. Ses données bancaires sont ensuite transmises de façon sécurisée à un serveur monétique. Une fois les données transmises, le serveur monétique retourne à la borne de - 2 - location une autorisation de débit et un identifiant d'autorisation associé à cette autorisation et stocké par le système. Grâce à cet identifiant d'autorisation, il est possible de louer un cycle sans utiliser sa carte bancaire durant la durée de validité de l'autorisation. En effet, lorsque l'utilisateur s'identifie pour les locations ultérieures, on vérifie l'identifiant d'autorisation et sa validité et on incrémente le compte de location de l'utilisateur. Quelques heures avant la fin d'autorisation de débit, le montant du compte de location est débité depuis la carte de l'utilisateur.

Or, un tel système de paiement n'est pas suffisamment flexible, ni pour l'utilisateur ni pour l'opérateur fournissant le service. En effet, les autorisations de débit ne sont valables qu'une durée prédéterminée, qui actuellement est de 30 jours au maximum. Or, si l'utilisateur dispose d'un abonnement d'un an, ce système de paiement ne peut pas être utilisé sur toute la durée de l'abonnement sans que l'utilisateur soit obligé de représenter sa carte bancaire régulièrement. Par ailleurs, les autorisations de débit ne sont valables que pour un montant maximum autorisé. Or, si l'utilisateur désire réaliser un achat ou une location dont le montant est supérieur au montant maximum autorisé, ce système de paiement ne peut pas être utilisé. En conséquence, soit l'utilisateur est obligé de représenter sa carte bancaire à chaque transaction dépassant le montant maximum autorisé, soit on est obligé de choisir un montant maximal élevé de l'autorisation, ce qui peut être générateur de problèmes pour l'utilisateur si celui-ci atteint le plafond de sa carte bancaire.

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 paiements répétés dans le temps, avec un même moyen de paiement plus flexible. Encore un autre but de l'invention est de proposer un procédé et un système de paiements répétés dans le temps, avec un même moyen de paiement, plus sûr à la fois pour l'opérateur fournissant le service/bien et pour l'utilisateur. - 3 - Enfin, un autre but de l'invention est de proposer un procédé et un système de paiements répétés dans le temps, avec un même moyen de paiement, utilisables dans des installations de paiement nouvelles ou existantes, à la fois pour l'achat et la location de biens et/ou de services.

Exposé de l'invention L'invention propose d'atteindre au moins l'un des buts précités par un procédé pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à un utilisateur, ledit procédé comprenant : - une première phase, dite d'initialisation, comprenant les étapes suivantes : - identification de l'utilisateur, - lecture, par un terminal de paiement, de données relatives audit moyen de paiement depuis ledit moyen de paiement, et - mémorisation desdites données relatives au moyen de paiement, en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur ; et - une phase, dite de paiement, comprenant les étapes suivantes : - émission d'une demande de paiement, dite initiale, selon un premier protocole de paiement, et - émission d'au moins une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement différent du premier protocole de paiement. On considère que les deux demandes de paiement sont effectuées selon des protocoles distincts lorsqu'elles ne comprennent pas exactement les mêmes données et/ou que les données ne sont pas présentées de la même façon.

Le procédé selon l'invention permet ainsi de réaliser des paiements répétés dans le temps avec un même moyen de paiement de manière flexible et plus sûr à la fois pour l'utilisateur et pour l'opérateur proposant le service (notamment un service d'achat ou de location). En effet, avec le procédé selon l'invention il est possible de choisir un premier protocole de - 4 - paiement rigoureux qui permet de garantir d'une part que le moyen de paiement utilisé est sûr et valide et qu'il est bien utilisé par le porteur du moyen de paiement, et d'autre part que le paiement initial est réalisé avec la plus grande sécurité à la fois pour l'utilisateur et pour l'opérateur. Il est ensuite possible, d'utiliser un deuxième protocole de paiement moins rigoureux et plus flexible lors des demandes de paiement ultérieures, de façon à mieux s'adapter aux consommations de l'utilisateur. Autrement dit, le procédé selon l'invention permet de réaliser une demande de paiement initiale rigoureuse avec un premier protocole rigoureux afin de vérifier des règles de sécurité en vue de garantir et sécuriser les paiements, pour ensuite utiliser un protocole de paiement simplifié afin de réaliser des paiements ultérieurs plus flexibles à la fois pour l'utilisateur et pour l'opérateur. De façon préférentielle, l'utilisateur s'identifie à chaque fois qu'il souhaite utiliser le service, l'utilisation de ce service étant facturée sur un compte associé à au moins une donnée de l'utilisateur, notamment un identifiant de celui-ci, les demandes de paiement étant chacune effectuée en fonction du montant du compte de l'utilisateur, notamment pour un montant du compte de l'utilisateur.

Lors de la phase de paiement, on peut aussi émettre une ou plusieurs demandes de paiement ultérieures selon le deuxième protocole et éventuellement encore une ou plusieurs autres demandes de paiement, selon un troisième, un quatrième, etc. protocoles de paiement différents du premier et du deuxième. La demande de paiement dite initiale peut être effectuée dans le cadre d'une transaction de type par paiement de proximité ou de type par paiement sur automate, tandis que chacune des demandes de paiement dite ultérieure est effectuée dans le cadre d'une transaction de type par vente à distance ou de type par paiement récurrent par vente à distance. On notera que les demandes de paiement ultérieures permettent de demander le paiement de montants non connus à l'avance, soit de prestations de location et de factures complémentaires - facture émises - 5 - lorsqu'un imprévu survient, par exemple paiement de franchise du fait d'un accident de l'utilisateur - et non seulement le paiement de prélèvements fixes et récurrents, tels que des prélèvements d'abonnement. Les demandes de paiement ultérieures permettent également de demander le paiement d'une concaténation de montants relatifs à plusieurs types de prestations différentes parmi les trois cités ci-après (prestations de location, prestations fixes récurrentes et factures complémentaires). Le procédé défini ci-dessus est d'application très large puisqu'il convient à tout service dans lequel plusieurs paiements peuvent être générés, que ces paiements soient fixes, dépendants de la consommation de l'utilisateur ou imprévus. Des exemples de services pour lesquels peut être mis en oeuvre le procédé selon l'invention sont, outre la location de véhicules en relation avec laquelle il est décrit, l'hôtellerie dite sans contact, la restauration, les télécommunications, par exemple la téléphonie ou l'accès à un réseau Internet, l'accès à un site de loisirs (club de sport, parc d'attraction, etc.), la location de vidéos à la demande, etc. Avantageusement, le premier protocole de paiement peut être un protocole de paiement nécessitant la présence physique du moyen de paiement dans le terminal de paiement. Un tel protocole de paiement peut être un protocole de paiement, de type pré-autorisé. Avantageusement, un tel protocole de paiement peut en particulier comprendre la demande d'un code de sécurité ou un code secret associé au moyen de paiement. Ce premier protocole de paiement permet de garantir la présence physique d'une part du moyen de paiement, d'autre part du porteur du moyen de paiement. Un tel protocole de paiement n'est certes pas flexible mais il permet de garantir le paiement et de sécuriser le paiement à la fois pour l'utilisateur et pour l'opérateur. En outre, il constitue une sécurité pour les paiements ultérieurs puisqu'on est au moins assuré que le service a été demandé par le porteur de carte. - 6 - Selon l'invention, lors de la phase d'initialisation, on obtient une pré-autorisation de débit comprenant au moins une donnée de pré-autorisation, la demande de paiement initiale comprenant la donnée de pré-autorisation. Une telle pré-autorisation permet de garantir le paiement, même lorsque la situation financière de l'utilisateur a changé entre l'émission de la pré- autorisation et la demande de paiement et d'assurer de fait un certain confort à l'opérateur du service puisqu'au moins les premières consommations de l'utilisateur seront payées de façon certaine. Suite à la réception de la pré-autorisation, on stocke dans un serveur 10 du système : - une donnée de montant, définissant un montant maximal de validité de la pré-autorisation, et/ou - une donnée de validité, définissant une durée de validité ou une date d'expiration de la pré-autorisation, et/ou 15 - une donnée de fin de contrat, relative à une date de fin de contrat de service, la demande de paiement initiale étant émise dans l'un ou l'autre des cas suivants : - lorsque l'on détermine, à l'aide de la donnée de validité, que la 20 durée restante jusqu'à la date d'expiration de la pré-autorisation est inférieure à une durée prédéterminée, et/ou - lorsque l'on détermine, à l'aide de la donnée de montant, que la différence entre le montant maximal et le montant du compte de l'utilisateur est inférieure à un montant prédéterminé, et/ou 25 - lorsque l'on détermine, à l'aide de la donnée de fin de contrat que la durée restante jusqu'à la date de fin de contrat est inférieure à une durée prédéterminée. Les données de montant et de validité sont notamment extraites de la pré-autorisation. 30 Avantageusement, le deuxième protocole de paiement peut être un protocole de paiement ne nécessitant pas la présence physique du moyen de paiement dans un terminal de paiement, la demande de paiement ultérieure - 7 - étant réalisée à l'aide des seules données relatives au moyen de paiement mémorisées. Un tel protocole de paiement peut par exemple être un protocole de paiement de type vente à distance. Il ne nécessite pas l'émission d'une pré- autorisation et la demande de paiement ultérieure ne comprend donc pas de donnée de pré-autorisation. Un tel protocole de paiement présente l'avantage d'être très flexible pour l'utilisateur qui n'a pas à présenter le moyen de paiement à chaque paiement ultérieur, tout en réalisant un paiement directement depuis un compte associé au moyen de paiement, et sans avoir à alimenter un compte intermédiaire géré par l'opérateur. On notera que le procédé selon l'invention permet de n'utiliser que les données issues du moyen de paiement, soit les données de la carte, sans saisie additionnelle par l'utilisateur d'un cryptogramme visible au dos de la carte. Cela n'est d'habitude pas autorisé dans un espace public tel qu'un espace dans lequel pourra être installé une installation de location à laquelle est appliquée l'invention. Toutefois, dans le cas présent, cela est notamment possible sans mettre en jeu la sécurité du paiement, car la première demande de paiement est effectuée à l'aide d'un protocole sécurisé qui permet de s'assurer que le porteur de la carte est légitime. Les vérifications d'usage effectuées dans le cadre de la première demande de paiement remplacent donc l'opération de saisie additionnelle et permettent de se passer d'une intervention de l'utilisateur lors des demandes de paiement ultérieures.

Dans un mode de réalisation particulièrement avantageux, le procédé selon l'invention peut en outre comprendre 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.

Un alias est un identifiant permettant d'identifier le moyen de paiement. Il peut notamment être un nombre généré aléatoirement. Un tel alias permet de sécuriser les demandes de paiements ultérieures car il permet d'éviter le plus possible de manipuler les données - 8 - relatives au moyen de paiement, ce qui permet de limiter le risque qu'elles soient dérobées et utilisées à des fins frauduleuses. Le procédé selon l'invention peut avantageusement comprendre : - une étape de mémorisation dudit alias en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur, par exemple dans un premier serveur, dit de gestion, notamment relatif au service, ce serveur de gestion pouvant être un serveur distant du terminal de paiement ; et - une étape de mémorisation dudit alias en association avec les données relatives au moyen de paiement, avantageusement dans un deuxième serveur, dit monétique, ce serveur monétique étant distinct du serveur de gestion et pouvant être distant du terminal de paiement.

Ainsi, les données relatives au moyen de paiement, l'identifiant du porteur et l'alias du moyen de paiement sont enregistrés sur des serveurs différents. Le serveur de gestion, lié au service et qui, de par sa nature, a de nombreuses interactions avec des éléments externes, n'échange pas de données relatives au moyen de paiement. Ainsi, si ce serveur est piraté, le pirate ne disposera pas des données de moyen de paiement. De même, il peut effectuer toutes les communications vers l'extérieur sans que la sécurité de ces communications soit considérablement renforcée. Au contraire, le serveur monétique, étant le seul muni des données relatives au moyen de paiement et servant uniquement pour le paiement, peut être configuré pour être moins accessible depuis l'extérieur et sécurisé de façon adaptée pour mettre en échec toute tentative de piratage. Cela permet de sécuriser les données de paiement sans que cela ne ralentisse le service dédié à l'utilisateur.

Le procédé selon l'invention peut comprendre pour chaque paiement réalisé pour le compte d'un utilisateur auquel est associé un identifiant, les étapes suivantes : - 9 - - détermination, notamment par le serveur de gestion, de l'alias du moyen de paiement associé à l'utilisateur en fonction dudit identifiant de l'utilisateur, - détermination, notamment par le serveur monétique, des données relatives au moyen de paiement associé audit alias, et - émission, notamment par le serveur monétique, d'une demande de paiement ou de pré-autorisation avec lesdites données relatives audit moyen de paiement Avantageusement, le procédé selon l'invention peut comprendre après au moins une demande de pré-autorisation ou une demande de paiement, notamment après chaque demande de paiement (initiale ou ultérieure), une émission de données d'avertissement de paiement vers un appareil de communication dudit utilisateur au travers d'un réseau de communication.

Ainsi, l'utilisateur est averti du paiement réalisé. Les données d'avertissement sont notamment présentées sous la forme d'un ticket virtuel, qui comprend toutes les informations habituellement visibles sur un ticket imprimé par un terminal de paiement suite à une transaction de type paiement de proximité ou par automate.

Selon un premier mode de réalisation, une demande de paiement ultérieure peut être émise à chaque nouvelle consommation, notamment chaque nouvelle identification, par l'utilisateur. Il y aura ainsi autant de demandes de paiement ultérieures que d'opérations d'achat ou de location de biens ou de service Dans un autre mode de réalisation particulièrement avantageux, une demande de paiement ultérieure peut être émise lorsque : - un compte client associé à l'utilisateur atteint un montant maximum prédéterminé, ledit procédé comprenant une étape de consultation dudit compte à chaque nouvelle consommation, notamment identification, ou à une fréquence donnée, et/ou - la précédente demande de paiement a été effectuée depuis une durée maximale prédéterminée, ledit procédé comprenant en - 10 - outre une consultation de la date de ladite dernière demande de paiement, une telle demande de paiement précédente pouvant être la demande de paiement initiale ou une précédente demande de paiement ultérieure.

Ainsi, le procédé selon l'invention permet de limiter le nombre de demandes de paiement et ainsi de diminuer le nombre de transactions bancaires. Le procédé selon l'invention permet également de sécuriser les transactions en diminuant les occasions de fraude. Dans ce cas, le procédé selon l'invention permet d'incrémenter un compte associé à un utilisateur au fur et à mesure que l'utilisateur réalise des achats/locations, jusqu'à atteindre le montant maximal prédéterminé ou la durée maximale prédéterminée. A chaque demande de paiement ultérieur, le compte client de l'utilisateur est remis à zéro.

Avantageusement, le procédé selon l'invention peut en outre comprendre une étape de consultation d'une donnée, dite de statut de paiement, avant une nouvelle demande d'utilisation du service, notamment identification, l'utilisation du service étant autorisée ou non en fonction de ladite donnée de statut de paiement.

De préférence, l'étape de consultation est effectuée uniquement après que la demande de paiement initiale ait eu lieu. Le procédé selon l'invention peut notamment comprendre une mise à jour de la donnée de statut de paiement : - par consultation des données relatives au moyen de paiement, par exemple la date de validité du moyen de paiement ; et/ou - par consultation des caractéristiques d'un compte bancaire associé au moyen de paiement. Une telle mise à jour peut être réalisée de façon régulière, par exemple tous les jours ou sur requête d'une consultation de la donnée de statut, à savoir avant chaque nouvelle utilisation du service. Le procédé selon l'invention peut également comprendre une mise à jour de la donnée de statut de paiement, après une demande de paiement, - 11 - la donnée de statut de paiement étant modifiée ou non en fonction de l'issue de ladite demande de paiement. Le procédé selon l'invention permet, grâce à une telle donnée de statut de paiement, d'éviter d'autoriser l'accès de l'utilisateur au service lorsque le statut de paiement de l'utilisateur porteur du moyen de paiement ne le permet pas, par exemple parce que le moyen de paiement n'est plus valide, ou que la dernière demande de paiement a été refusée, que le moyen de paiement fait l'objet d'une opposition, que le compte associé au moyen de paiement est bloqué, ou encore parce que l'utilisateur n'a pas assez d'argent sur son compte de telle sorte qu'une nouvelle demande de paiement serait refusée.

Selon l'invention, le format de données utilisé lors de la demande de paiement initiale peut être différent du format de données utilisé pour réaliser une demande de paiement ultérieure. Le format de données utilisé dans une demande de paiement ultérieure comprendre des données différentes du format de données utilisé lors de la demande de paiement initiale. Une telle demande de paiement ultérieure ne comprend par exemple pas de donnée de pré-autorisation. Le procédé selon l'invention peut être avantageusement utilisé pour le paiement de services de locations, avec ou sans abonnement, de véhicules et plus particulièrement de véhicules électriques proposés à la location sur un ou plusieurs sites de location, chaque site de location étant relié à un site central de gestion coordonnant les différentes étapes du procédé.

Selon un autre aspect de l'invention, il est proposé un système de paiement pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à l'utilisateur, ledit système comprenant : - des moyens d'identification d'un utilisateur -12- - un terminal de lecture de données relatives audit moyen de paiement depuis ledit moyen de paiement, et - des moyens de mémorisation desdites données relatives au moyen de paiement, pour stocker ces données en association avec au moins une donnée de l'utilisateur ; ledit système comprenant en outre des moyens, dits de paiement, agencés pour émettre : - une demande de paiement, dite initiale, selon un premier protocole de paiement, et - une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement différent du premier protocole de paiement. Les moyens d'identification peuvent avantageusement comprendre un lecteur RFID pour lire une carte d'identification RFID, un lecteur optique pour lire un identifiant à code barre, un lecteur d'un moyen d'identification biométrique ou autre. Ces moyens d'identification sont agencés pour lire un identifiant associé à un utilisateur depuis un moyen d'identification, de type RFID par exemple, lors de d'achats/locations initiales ou ultérieurs. Le terminal de lecture de données relatives au moyen de paiement peut être un terminal de paiement. Selon un mode de réalisation préféré mais nullement limitatif du système selon l'invention, les moyens de paiement peuvent comprendre : - un premier serveur, dit de gestion, notamment lié au service, 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, -13- - émettre des demandes de paiement en fonction desdites données relatives audit moyen de paiement, la demande de paiement initiale comprenant en outre au moins une donnée de pré-autorisation.

Les différents serveurs peuvent être en communication avec le terminal de paiement et entre eux pour échanger des données. Le système selon l'invention peut en outre comprendre des moyens de codage et de décodage des données échangées entre les différents organes du système de sorte à sécuriser ces données.

La communication entre les différents organes peut être partiellement ou totalement filaire ou sans fil, au travers d'un réseau de communication de type Internet ou GPRS.

Selon un autre mode de réalisation, tous les serveurs peuvent être remplacés pour un serveur unique agencé pour réaliser les demandes de paiement initiales et ultérieures. Selon encore un autre aspect de l'invention il est proposé une installation de location de véhicule 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 paiement selon l'invention. Le terminal de lecture peut être disposé sur le site de location. Avantageusement, chaque site de location peut en outre comporter un moyen d'identification et un terminal de lecture.

Les moyens de paiement peuvent être disposés au niveau du site de gestion central. - 14 - Dans le cas où, les moyens de paiement comprennent un serveur de gestion et un serveur monétique, le serveur de gestion peut être disposé au niveau du site de gestion central et le serveur monétique peut être disposé au niveau d'une banque de l'opérateur du service de location ou encore au niveau d'un autre site, dit monétique. 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 ; - la FIGURE 3 est une représentation schématique d'une version simplifiée 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 paiement ; et - la FIGURE 5 est une représentation schématique d'une installation de location de véhicule 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 ». - 15 - 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 et 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. 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 relatives à 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 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. - 16 - 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, - 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 débit à 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 - 17 - 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 ; - 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, - 18 - 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 débit ; - 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 - 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 demande de paiement 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 - 19 - 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. 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 exemple 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édiaires, 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 - 20 - réalisés. Ce mode de réalisation nécessite toutefois une sécurisation lourde du serveur de gestion, peu pratique. En outre, le système 100 comprend un module de communication pour émettre des tickets virtuels. Cependant, dans la présente invention ce module de communication est optionnel. Dans un mode de réalisation très simplifié, le système 100 comprend le terminal de lecture 104 relié à un serveur unique, qui peut être appelé, serveur de paiement, et un moyen de mémorisation. 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. Le procédé 200 représenté à la figure 2 montre une première demande de paiement (dite initiale) selon un protocole de paiement de proximité de type pré-autorisation, et une deuxième demande de paiement (dite ultérieure) de type vente-à-distance. 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. - 21 - 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 a 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.

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 - 22 - 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 débit auprès de la banque de l'utilisateur, à l'aide des données du 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 et le ticket virtuel au terminal de paiement à l'étape 230, qui peut 30 éventuellement renseigner visuellement l'utilisateur sur l'issue de la demande de débit. 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 l'intermédiaire de la borne de paiement. - 23 - 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.

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 10 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 15 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, au demande de paiement initiale. Le serveur de gestion envoie au serveur monétique la donnée de pré- 20 autorisation et l'alias à l'étape 242. A l'étape 244, le serveur monétique émet une demande de débit 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 25 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 30 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 - 24 - 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 le 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 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. Le ticket virtuel envoyé à l'utilisateur comprend des données relatives au résultat de la demande d'autorisation de débit ou la demande de débit, à 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 débit, pour un montant réellement débité sur compte du client. Dans un mode de réalisation simplifié, le procédé 200 peut ne pas comprendre l'envoi de tickets virtuels, dans ce cas les étapes relatives à l'adresse numérique et à l'envoi d'un tel ticket ne sont pas réalisées. De plus, un unique serveur peut être utilisé en tant que serveur monétique et serveur de gestion. Dans ce cas, le procédé 200 ne comprend pas 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.

La FIGURE 3 est une représentation schématique sous la forme d'un diagramme d'une version simplifiée d'un procédé selon l'invention. Dans ce mode de réalisation le système comprend un terminal de 20 paiement, un unique serveur, dit de paiement et des moyens de mémorisation. Le procédé 300 comprend une phase d'initialisation 302 comprenant les étapes suivantes : - étape 304 : insertion moyen de paiement dans le terminal de 25 lecture ; - étape 306 : lecture et transmission au serveur de paiement des données relatives au moyen de paiement ; On pourrait envisager que l'insertion du moyen de paiement et la lecture de ces données constituent une étape d'identification de l'utilisateur. 30 Toutefois, il est également possible que le procédé comprenne une étape préalable d'identification supplémentaire. En effet, les données de la carte peuvent être suffisantes pour identifier un utilisateur mais elles ont leur limite puisqu'elles ne sont valables que durant un période prédéterminée. - 26 - - étape 308 : mémorisation des données relatives au moyen de paiement au niveau du serveur de paiement. - étape 310 : une émission d'une demande de pré-autorisation de débit vers un serveur de la banque de l'utilisateur avec les données relatives au moyen de paiement ; - étape 312 : réception d'une donnée de pré-autorisation de débit valable pour un montant maximum et pour une durée maximum et mémorisation de cette donnée.

Puis, le serveur de paiement 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 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 314 de première demande de paiement, ou demande de paiement initiale, comprenant les étapes suivantes : - étape 316 : émission, vers la banque de l'utilisateur, d'une demande de paiement avec la donnée d'autorisation de débit et les informations de paiement, à savoir par exemple le montant exact du débit : - étape 318 : réception d'un accusé de réception émis par la banque de l'utilisateur et mémorisation de l'accusé de réception. La phase 314 de première demande de paiement est alors terminée.

Le serveur de paiement 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 réellement être débité et le montant qui doit être débité, les étapes suivantes sont réalisées. Le procédé 300 comprend ensuite une ou plusieurs phases 320 de demande de paiement réalisées selon un protocole de paiement de type vente à distance et comprenant les étapes suivantes : -27- - étape 322 : émission, vers la banque de l'utilisateur, d'une demande de paiement avec les données relatives au moyen de paiement et les informations de paiement, telle que par exemple le montant exact du débit ; - étape 324 : réception accusé de réception émis par la banque de l'utilisateur et mémorisation. La FIGURE 4 est une représentation schématique sous la forme d'un 10 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 procédé émet une première demande de paiement selon un protocole de 15 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. Si non, une étape de test 404 est réitérée tous les soirs. Lors de cette 20 é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é-autorisation ; 25 - 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. Pour cela, il envoie au serveur monétique, éventuellement à l'aide d'un - 28 - 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 316. On notera qu'une seconde requête est également générée quasi-simultanément à la première requête, permettant l'obtention du paiement initial 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 débit. 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étiques 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 débit 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 station 504 est reliée 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 station 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'une station 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'une station 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.

Claims (16)

1. REVENDICATIONS1. Procédé (200 ; 300) pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à un utilisateur, ledit procédé comprenant : une première phase (202 ; 302), dite d'initialisation, comprenant les étapes suivantes : identification d'un utilisateur par un lecteur, - lecture (224 ; 306), par un terminal de paiement (104), de données relatives audit moyen de paiement depuis ledit moyen de paiement, et - mémorisation (226 ; 308) desdites données relatives au moyen de paiement en association avec au moins une donnée relative à l'utilisateur, notamment un identifiant de l'utilisateur, dans un serveur distant du lecteur; et - une phase, dite de paiement, comprenant les étapes suivantes : émission (240 ; 314) d'une demande de paiement, dite initiale, selon un premier protocole de paiement nécessitant la présence dudit moyen de paiement dans le terminal de paiement, et émission (250 ; 320) d'au moins une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement, différent dudit premier protocole de paiement, et ne nécessitant pas la présence dudit moyen de paiement dans un terminal de paiement ; chacune desdites étapes d'émission comprenant une émission de données relatives audit moyen de paiement vers un serveur bancaire distant.
2. 2. Procédé (200,300) selon la revendication 1, caractérisé en ce que l'utilisateur s'identifie à chaque fois qu'il souhaite utiliser le service, l'utilisation de ce service étant facturée sur un compte associé à au moins une donnée de l'utilisateur, les demandes de paiement étant chacune effectuées en fonction du montant du compte de l'utilisateur.- 34 -
3. 3. Procédé (200 ; 300) selon l'une quelconque des revendications précédentes, caractérisé en ce que la phase d'initialisation comprend l'obtention d'une pré-autorisation de débit comprenant au moins une donnée de pré-autorisation, la demande de paiement initiale comprenant la donnée de pré-autorisation.
4. 4. Procédé (200,300) selon la revendication 3, dans lequel suite à la réception de la pré-autorisation, on stocke : une donnée de montant, définissant un montant maximal de validité de la pré-autorisation, et/ou une donnée de validité, définissant une durée de validité ou une date d'expiration de la pré-autorisation, et/ou une donnée de fin de contrat, relative à une date de fin de contrat de service, la demande de paiement initiale étant émise dans l'un où l'autre des cas suivants lorsque l'on détermine, à l'aide de la donnée de validité, que la durée restante jusqu'à la date d'expiration de la pré-autorisation est inférieure à une durée prédéterminée, et/ou lorsque l'on détermine, à l'aide de la donnée de montant, que la différence entre le montant maximal et le montant du compte de l'utilisateur est inférieure à un montant prédéterminé, et/ou lorsque l'on détermine, à l'aide de la donnée de fin de contrat, que la durée restante jusqu'à la date de fin de contrat est inférieure à une durée prédéterminée.
5. 5. Procédé (200 ; 300) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape (216) de génération d'un alias du moyen de paiement, de préférence avant l'étape de 30 lecture des données relatives au moyen de paiement.
6. 6. Procédé (200 ; 300) selon la revendication 5, caractérisé en ce qu'il comprend en outre :- 35 - une étape (216) 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 (226) 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,.
7. 7. Procédé (200 ; 300) selon la revendication 6, caractérisé en ce qu'il 10 comprend, pour chaque demande paiement pour un utilisateur auquel est associé un identifiant, 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, 15 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 avec lesdites données relatives audit moyen de paiement. 20
8. 8. Procédé (200) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, après au moins une demande de pré-autorisation ou une demande de paiement, une émission (238, 248, 258) de données d'avertissement de paiement, par exemple d'un ticket virtuel, vers un appareil de communication dudit utilisateur au travers d'un réseau de 25 communication.
9. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une demande de paiement ultérieure est émise à chaque nouvelle consommation par l'utilisateur, notamment à chaque 30 nouvelle identification de l'utilisateur.
10. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une demande de paiement ultérieure est émise lorsque :-35- - un compte associé à l'utilisateur atteint un montant maximum prédéterminé, ledit procédé comprenant en outre une étape de consultation dudit compte à chaque nouvelle consommation, notamment identification, ou à une fréquence donnée, et/ou - la précédente demande de paiement 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. 10
11. 11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape de consultation d'une donnée, dite de statut de paiement, avant une nouvelle demande d'utilisation du service, l'utilisation du service étant autorisée ou non en fonction de ladite donnée de statut de paiement. 15
12. 12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le format de données utilisé lors de la demande de paiement initiale est différent du format de données utilisé pour réaliser une demande de paiement ultérieure. 20
13. 13. Application du procédé selon l'une quelconque des revendications précédentes à un service consistant en la location avec ou sans abonnement de véhicules proposés à la location sur un ou plusieurs sites de location (404), chaque site de location (404) étant relié à un site central de gestion 25 (402).
14. 14. Système (100) de paiement pour réaliser des paiements répétés dans le temps avec un même moyen de paiement, les paiements étant relatifs à un service proposé à l'utilisateur ledit système comprenant : 30 - des moyens d'identification d'un utilisateur - un terminal (104) de lecture de donnes relatives audit moyen de paiement depuis ledit moyen de paiement, et- 37 - - un serveur comprenant des moyens de mémorisation (112) desdites données relatives au moyen de paiement, en association avec au moins une donnée de l'utilisateur ; et ledit système (100) comprenant en outre des moyens (106,108), dits de paiement, agencés pour émettre vers un serveur bancaire distant : une demande de paiement, dite initiale, selon un premier protocole de paiement nécessitant la présence physique dudit moyen de paiement dans ledit terminal de paiement, et - une demande de paiement, dite ultérieure, selon un deuxième protocole de paiement, différent du premier protocole de paiement, ne nécessitant pas la présence physique dudit moyen de paiement dans un terminal de paiement.
15. 15. Système (100) de paiement selon la revendication 14, caractérisé en ce que les moyens de paiement comprennent : - un premier serveur (106), dit de gestion, 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 (108), 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 paiement en fonction desdites données relatives audit moyen de paiement, la demande de paiement initiale comprenant en outre au moins une donnée de pré-autorisation.
16. 16. Installation (400) de location de véhicule comprenant : - un site (402) de gestion, dit central, 5- 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 de paiement selon l'une quelconque des revendications 14 ou 15.