FR2980892A1 - Procede et systeme de paiement de consommations repetees dans le temps et application a la location de vehicules. - Google Patents

Abstract

L'invention concerne un procédé de paiement avec un moyen de paiement de consommations répétées dans le temps, comprenant les étapes suivantes : - mémorisation de données relatives audit moyen de paiement, - à chaque consommation, mise à jour d'un montant, dit réel, associé à un utilisateur dudit moyen de paiement, caractérisé en ce qu'il comprend une ou plusieurs itérations des étapes suivantes : - comparaison dudit montant réel à un montant prédéterminé, - demande de paiement avec lesdites données relatives audit moyen de paiement lorsque ledit montant réel est supérieur ou égal audit montant prédéterminé. L'invention concerne également un système (100) 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 de consommations répétées dans le temps et application à la location de véhicules » La présente invention concerne un procédé de paiements de consommations relatives à un service et répétées dans le temps. Elle concerne également un système 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 du paiement de consommations répétées dans le temps avec un moyen de paiement, par exemple une carte bancaire, notamment lors d'achat ou de locations. Plus particulièrement, l'invention concerne le domaine du paiement avec un même moyen de paiement de consommations répétées dans le temps, 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, par exemple tous les mois, correspondant au montant mensuel à payer pour un abonnement, par exemple annuel, mais également des paiements de frais additionnels pouvant se produire lors de chaque consommation du service. - 2 - Dans les procédés et systèmes de l'état de la technique, le montant correspondant à l'abonnement ainsi que les frais additionnels sont prélevés à intervalle de temps régulier, par exemple en fin de mois. Les procédés et systèmes actuels présentent un premier inconvénient qui consiste en ce que l'utilisateur n'a pas de suivi du montant total qu'il aura à payer en fin de mois et peut être confronté à payer une somme importante. Ainsi, il peut se trouver en difficulté de paiement ou même en défaut de paiement. Dans ce cas, l'opérateur fournissant le service ou le bien consommé aura fourni un service ou un bien sans pouvoir être payé.

De plus, l'utilisateur peut perdre le bénéfice du service. 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 paiement permettant à l'opérateur et à l'utilisateur de diminuer les risques d'impayés ou le montant impayé. Encore un autre but de l'invention est de proposer un procédé et un système de paiement permettant d'éviter à un opérateur de fournir un service ou un bien pour lequel il risque de ne pas être payé.

Enfin, un autre but de l'invention est de proposer un procédé et un système de paiement facilitant à l'utilisateur le paiement de consommations répétées dans le temps. Exposé de l'invention L'invention propose d'atteindre au moins l'un des buts précités par un procédé de paiement relatif à un service avec un moyen de paiement, en particulier des paiements pour des consommations répétées dans le temps, par exemple 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/ou - de montants de manière ponctuelle lors de la consommation du bien ou du service ; ledit procédé comprenant les étapes suivantes : - 3 - - mémorisation de données relatives audit moyen de paiement, - à chaque consommation, mise à jour d'un montant, dit réel, associé à un utilisateur dudit moyen de paiement; caractérisé en ce qu'il comprend une ou plusieurs itérations des étapes suivantes : - comparaison dudit montant réel à un montant prédéterminé, - demande de paiement avec lesdites données relatives audit moyen de paiement lorsque ledit montant réel est supérieur ou égal audit montant prédéterminé.

Ainsi, le procédé selon l'invention permet à l'utilisateur réalisant des consommations répétées dans le temps de ne payer chaque fois que lorsque le montant des consommations atteint un montant prédéterminé et non pas uniquement à intervalle de temps régulier. Ce qui permet à l'utilisateur de pouvoir suivre et ainsi de mieux contrôler et réguler sa consommation.

Le procédé selon l'invention permet ainsi d'une part d'éviter à l'utilisateur de se trouver dans une situation dans laquelle il doit payer une somme trop importante, et d'autre part d'éviter à l'opérateur un montant d'impayé trop important qui est potentiellement perdu alors qu'il a déjà fourni le service.

Le procédé selon l'invention peut être appliqué à tous types de paiements, à savoir à des paiements automatisés, de type pré-autorisé, et/ou de type vente-à-distance par exemple, ou à des paiements de type prélèvement avec autorisation préalable de prélèvement, etc.

Le procédé défini ci-dessus est d'application très large puisqu'il convient à tout service dans lequel l'utilisateur possède un abonnement et consomme le service de façon étalée dans le temps, que les dépenses liées à sa consommation soient fixes, dépendantes de la consommation de l'utilisateur ou imprévues, ce qui donne lieu à des paiements répétés. 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 est décrit le procédé ci-après, 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 - 4 - Internet, l'accès à un site de loisirs (club de sport, parc d'attraction, etc.), la location de vidéos à la demande, etc. 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. Alternativement, les données relatives au moyen de paiement peuvent être envoyées par l'utilisateur soit de manière numérique soit de manière postale.

Avantageusement, l'étape de comparaison peut en outre comprendre une étape réalisant un test relatif à au moins un autre critère que le montant, ledit procédé comprenant en outre une demande de paiement en fonction du résultat dudit test. Un tel critère peut être le test d'une durée depuis le dernier paiement.

Ainsi, même si le montant réel est inférieur au montant prédéterminé, mais que la durée réelle depuis le dernier paiement est supérieure à une durée prédéterminée, alors une demande de paiement est également déclenchée. Un tel critère peut être le test d'une date fixe de paiement, par exemple liée à une date de fin de contrat de l'utilisateur avec le service.

Ainsi, même si le montant réel est inférieur au montant prédéterminé, mais que la date réelle du test correspond à un date prédéterminée ou est postérieure à une date prédéterminée, alors une demande de paiement est également déclenchée. Une telle date fixe peut être à une date de périodicité d'un abonnement pour maintenir l'abonnement valide.

Un tel critère peut également comprendre le test d'une date limite associée à une autorisation de débit préalablement obtenue lorsqu'une demande de paiement est réalisée suivant un protocole de type pré-autorisé. Le test supplémentaire peut également porter sur un montant d'un autre compte associé à l'utilisateur. On pourrait en effet envisager que deux comptes distincts (par exemple, un pour les consommations courantes, un pour les consommations totales depuis le début de l'abonnement ou de la périodicité de l'abonnement) lui soient associés. - 5 - Pour comptabiliser les consommations de l'utilisateur et mettre à jour le montant réel, ainsi que les autres critères pris en compte lors de l'étape de comparaison ou de test, le procédé selon l'invention peut en outre comprendre une étape d'identification de l'utilisateur avant chaque consommation. Une telle étape d'identification pourrait éventuellement être réalisée avec le moyen de paiement. Une telle étape d'identification peut également être réalisée avec un identifiant préalablement associé à l'utilisateur tel que par exemple un code 10 d'identification, une carte d'identification RFID ou encore une donnée d'identification biométrique. Dans ce cas, le procédé selon l'invention peut en outre comprendre une étape d'attribution d'une donnée d'identification au porteur du moyen de paiement, les données relatives au moyen de paiement étant mémorisées 15 en association avec ledit identifiant. Ainsi, avant chaque étape de consommation, par exemple d'achat ou de location, l'utilisateur s'identifie au préalable avec son identifiant et le montant de sa consommation est comptabilisé en association avec son identifiant par exemple dans un compte client qui lui est attribué. 20 Selon l'invention, l'étape de comparaison peut être réalisée à une fréquence prédéterminée, par exemple tous les jours. Ainsi, le procédé selon l'invention permet de tester le critère relatif au montant de la consommation et éventuellement un ou plusieurs autres critères tous les jours, et s'il y a 25 lieu, déclencher une demande de paiement. Avantageusement, au moins une demande de paiement peut être réalisée selon un premier protocole nécessitant la présence physique du moyen de paiement dans un terminal de paiement, tel que par exemple un 30 protocole de paiement pré-autorisé. 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, - 6 - par exemple en demandant la saisie d'un code PIN ou un code de sécurité secret associé à la carte. Lorsqu'au moins demande de paiement est réalisée selon le premier protocole de paiement, la demande de paiement comprend : - une étape de demande de pré-autorisation pour un montant prédéterminé, et - lorsque la pré-autorisation a été obtenue, une étape d'émission d'une demande de paiement comprenant une donnée de pré- autorisation de la pré-autorisation, l'étape de comparaison étant réalisée suite à l'étape de demande de pré-autorisation, l'étape de demande de paiement étant déclenchée si le montant du compte de l'utilisateur est supérieur au montant de la pré-autorisation.

Comme indiqué auparavant, la pré-autorisation peut également être émise pour une durée prédéterminée, une étape de demande de paiement pouvant également être déclenchée suite à une étape de test portant sur la durée prédéterminée.

Avantageusement, au moins une demande de paiement peut être réalisée selon un deuxième 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 ou un protocole de paiement par prélèvement avec autorisation de prélèvement.

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. Un tel paiement peut notamment être un paiement de type vente à distance ou un paiement à l'aide d'une autorisation de prélèvement.

Selon un mode de réalisation préféré, le procédé selon l'invention comprend une pluralité de demandes de paiement, ladite pluralité de de demandes de paiement comprenant : - 7 - - une demande de paiement, dite initiale, selon le premier protocole de paiement ; et - au moins une demande de paiement, dite ultérieure, selon le deuxième protocole de paiement.

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 débit ultérieures peuvent être effectuées sans que l'utilisateur n'ait à présenter à nouveau son moyen de paiement (présenté dans le but d'émettre la première demande 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 est flexible car l'utilisateur n'a pas à présenter le moyen de paiement à chaque demande de paiement. Le procédé selon l'invention peut avantageusement comprendre en outre des étapes réalisant : - une mémorisation d'une adresse numérique associée à l'utilisateur porteur du moyen de paiement, et - pour au moins une demande de pré-autorisation ou de paiement, une émission, à ladite adresse numérique, de données, dites de compte-rendu, relatives à l'issue de ladite demande de paiement. Ainsi, le procédé selon l'invention permet d'envoyer de manière numérique des comptes-rendus pour les paiements réellement et effectivement réalisés sur son compte. Ce mode de réalisation est particulièrement utile lorsque le paiement est de type pré-autorisé et que le montant effectivement prélevé est susceptible d'être différent du montant pré-autorisé. L'utilisateur peut alors recevoir un compte-rendu (ou ticket virtuel) à la fois lors de la pré-autorisation et lors du paiement effectif. Par ailleurs, le procédé selon l'invention permet de communiquer à l'utilisateur les données relatives au prélèvement réel effectué sur son - 8 - 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é.

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 débit, 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 imprimées 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 pré-autorisation ou paiement. 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 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 au travers d'un réseau de type GPRS, et/ou - 9 - - toute autre coordonnée numérique telle que par exemple un numéro de télécopie une adresse de réseau social, 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 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 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 et extraite depuis la base de données distante, 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. L'adresse numérique peut également ou à la place comprendre une adresse renseignée dans le moyen de paiement. Dans ce cas, le procédé selon l'invention peut comprendre une étape de lecture des données dans le moyen de paiement par exemple par un terminal de lecture. L'étape de lecture des données relatives au moyen de paiement comprend en outre une étape d'extraction de ladite adresse numérique depuis le moyen de paiement.

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 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 paiement a été émise. - 10 - 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 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 de l'invention, le procédé comprend une étape de paramétrage spécifique à l'utilisateur du montant prédéterminé, et de préférence de la durée prédéterminée, préalable à l'étape de comparaison. Ces données sont de préférence mémorisées et utilisées lors de 25 chaque étape de comparaison. Ce paramétrage peut être demandé par l'utilisateur, voire effectué directement par l'utilisateur. Il peut également être décidé par les opérateurs du service en fonction d'informations relatives à l'utilisateur. Les données utilisées pour l'étape de comparaison (montant, durée, 30 etc.) peuvent notamment être associées à un type d'abonnement choisi par l'utilisateur. Le montant prédéterminé peut par exemple être plus élevé, par exemple lorsque l'utilisateur possède un abonnement de type « entreprise » ou « VIP ». De fait, quand le service est proposé à une pluralité - 11 - d'utilisateurs, le montant prédéterminé et les autres données peuvent ne pas avoir les mêmes valeurs pour chacun des utilisateurs. 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. 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. - 12 - Selon un autre aspect de l'invention, il est proposé un système de paiement avec un moyen de paiement de consommations relatives à un service et répétées dans le temps, 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/ou - de montants de manière ponctuelle lors de la consommation du bien ou du service ; ledit système comprenant : - des moyens de mémorisation de données relatives audit moyen de paiement, et - des moyens de mise à jour, à chaque consommation, d'un montant, dit réel, associé à un utilisateur dudit moyen de paiement. Le système selon l'invention est caractérisé en ce qu'il comprend en outre : - des moyens de comparaison dudit montant réel à un montant prédéterminé, et - des moyens de demande de paiement avec lesdites données relatives audit moyen de paiement lorsque ledit montant réel est supérieur ou égal audit montant prédéterminé. Les moyens de mise à jour du montant réel, et éventuellement d'autres critères, peuvent être combinés ou intégrés dans les moyens de demande de paiement. Par exemple, les moyens de mise à jour peuvent comprendre des moyens logiciels ou des moyens de calcul intégrés dans un serveur de demande de paiement, ou un serveur intervenant dans la demande de 30 paiement. Le système selon l'invention peut en outre comprendre : -13- - des moyens de mémorisation d'une adresse numérique, éventuellement en association avec un identifiant de l'utilisateur, et - des moyens (118), dits de communication, agencés pour réaliser, pour chaque demande de paiement, une émission, à ladite adresse numérique, de données, dites de compte-rendu, relatives à l'issu de ladite demande de paiement. 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. Le système selon l'invention peut en comprendre 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. 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 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, - mettre à jour le montant réel, et éventuellement stocker d'autres données utilisées lors de la comparaison ; - un deuxième serveur, dit monétique, comprenant des moyens agencé pour : - mémoriser ledit alias du moyen de paiement avec les données relatives audit moyen de paiement, - émettre des demandes de paiement ; les moyens de comparaison comprenant un module, dit de comparaison, agencé dans le premier serveur ou dans le deuxième serveur. - 14 - Le premier serveur est en particulier un serveur de gestion, notamment lié au service. 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, les moyens de demande de paiement comprennent : - un serveur, dit de paiement, comprenant des moyens pour : - mémoriser les données relatives au moyen de paiement en association avec l'identifiant de l'utilisateur, - mettre à jour le montant réel, et éventuellement stocker d'autres données utilisées lors de la comparaison, et - émettre des demandes de paiement ; les moyens de comparaison comprenant un module, dit de comparaison, agencé dans ledit serveur. Ce mode de réalisation permet de diminuer les échanges d'information entre les organes du système selon l'invention, et d'éviter d'alourdir les étapes de demandes de paiement.

Ce mode de réalisation permet également de diminuer les coûts d'un tel système de paiement. 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éhicules 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.

Dans un mode de réalisation particulièrement avantageux, les moyens de demande de paiement du système de paiement peuvent être disposés au niveau du site de gestion central ainsi que les moyens de comparaison et les moyens de mémorisation. - 15 - 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 sous la forme d'un diagramme des étapes d'un premier mode de réalisation d'un procédé selon l'invention appliqué à la location de véhicules ; - la FIGURE 3 est une représentation sous la forme d'un diagramme des étapes de déclenchement des demandes de paiements selon l'invention; - la FIGURE 4 est une représentation schématique d'une installation de location de véhicule mettant en oeuvre un système selon l'invention ; et - la FIGURE 5 est une représentation schématique d'un deuxième mode de réalisation d'un procédé 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 ». - 16 - 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. 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 comprend en outre un module 122 de test ou de comparaison agencé pour réaliser notamment : - une comparaison d'un montant réel de consommation à un montant seuil prédéterminé, - une durée depuis le dernier paiement à une durée seuil prédéterminée, -17- - la date réelle à une date prédéterminée de paiement pour des paiements réguliers qui doivent être réalisés. 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. 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 - 18 - 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 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 débit initiée par le module de test 122 : -19- - PP1 : le module de test 122 teste les critères portant sur le montant, et éventuellement des critères supplémentaires portant sur la durée depuis le dernier paiement, la durée restante pour émettre une demande de paiement avec la donnée d'autorisation préalablement obtenue, etc. Si au moins un des critères testés lors de cette étape renvoie un résultat allant dans le sens d'une demande de paiement, les étapes suivantes sont réalisées : - PP2 : requête de paiement envoyée au premier serveur intermédiaire 114 en utilisant l'identifiant de pré- autorisation et l'alias UID, - PP3 : 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 débit, - PP4 : la réponse reçue est relayée par le serveur monétique 108 au premier serveur intermédiaire 114, et - PP5 : la réponse est relayée par le premier serveur intermédiaire 114 au serveur de gestion 106, - PP6 : 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, - PP7 : le serveur monétique 108 transmet le ticket virtuel généré et l'adresse numérique au module de communication 118, et - PP8 : le module de communication 118 envoie le ticket virtuel à l'adresse numérique au travers du réseau de communication 120. - 20 - 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 module de test 122 : - VD1 : le module de test 122 teste les critères portant sur le montant, et éventuellement des critères supplémentaires portant sur la durée depuis le dernier paiement, sur une date de paiement fixe, etc. Si au moins un des critères testés lors de cette étape renvoie un résultat allant dans le sens d'une demande de paiement les étapes suivantes sont réalisées : - VD2 : requête de paiement envoyée par le serveur de gestion 106 sur le deuxième serveur intermédiaire 116 (UID et montant), - VD3 : la requête est envoyée au serveur monétique 108, qui génère une demande de paiement ultérieur 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, - VD4 : la réponse de la banque est transmise par le serveur monétique 108 au deuxième serveur intermédiaire 116, et - VD5 : la réponse est relayée par le deuxième serveur intermédiaire 116 au serveur de gestion 106, - VD6 :1 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, - VD7 : le serveur monétique 108 transmet le ticket virtuel généré et l'adresse numérique au module de communication 118 ; et -21- - VD8 : 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 la 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. En outre, le système représenté en figure 1 peut ne pas comprendre un terminal de lecture, les données bancaires et l'adresse électronique pouvant être communiquées par l'utilisateur d'une autre manière, par exemple par une autorisation de prélèvement accompagné d'un RIB. Dans ce cas, les demandes de prélèvement seront obligatoirement réalisées selon le protocole de vente à distance ou un protocole de prélèvement.

Le système représenté en figure 1 peut ne pas comprendre de module de communication, auquel cas les étapes relatives à l'envoi de données de compte-rendu ou ticket virtuel ne sont pas réalisées. - 22 - Dans un mode de réalisation très simplifié, le système selon l'invention comprend uniquement un serveur de paiement réalisant les demandes de paiement auprès de la banque de l'utilisateur, muni d'un moyen de mémorisation, et d'un module de test réalisant les tests en vue déclencher les demandes de paiement. 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. 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 à - 23 - 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 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 - 24 - 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 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 25 é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. 30 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. - 25 - 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 paiement. Puis, le module de test teste à une fréquence donnée si le compte de l'utilisateur doit être débité ou non lors d'une étape 241 selon un ou plusieurs critères. Lorsqu'au moins un des critères renvoie un résultat nécessitant le déclenchement d'une demande de paiement les étapes suivantes sont réalisées. Il s'agit de la phase 240 de première demande de paiement, ou demande de paiement initiale.

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 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 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. - 26 - 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. Chaque phase de paiement 250 est déclenchée par une étape 251 pendant laquelle le module de test teste si le compte de l'utilisateur doit être débité ou non selon un ou plusieurs critères. Ce test est effectué à une fréquence donnée. Lorsqu'au moins un des critères renvoie un résultat nécessitant le déclenchement d'une demande de paiement est réalisé selon les étapes suivantes constituant une phase de paiement selon le protocole vente-à-distance. 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. Bien entendu, dans un autre mode de réalisation, le procédé 200 peut comprendre seulement des demandes de paiement selon le protocole de vente à distance. Dans ce cas, on n'insère pas de carte bancaire dans le terminal et les données sont saisies directement par l'utilisateur. On n'envoie pas alors de demande de pré-autorisation ou de demande de paiement initiale. Après l'étape de mémorisation des données bancaires, la - 27 - phase 250 est directement effectuée, cette étape étant réitérée à plusieurs reprises dès que l'étape de test 251 envoie un résultat de déclenchement d'une demande de paiement.

Dans encore 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 250 n'est pas réalisée et les étapes 222 à 248 sont réitérées à plusieurs reprises.

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 : - des données d'acceptation ou de refus d'une demande d'autorisation de débit d'un montant majorée, ou - des données d'acceptation ou de refus d'une demande de transaction réelle, c'est-à-dire une demande de débit, pour un montant réellement débité sur compte du client. 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. Par ailleurs, les serveurs de gestion et monétique peuvent être remplacés par un serveur unique, dit de paiement. 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. Le procédé 200 peut également ne pas comprendre toutes les étapes relatives à la génération et à l'émission d'un ticket virtuel. Enfin, les données relatives au moyen de paiement peuvent être fournies autrement que par lecture par un terminal de paiement, par exemple par envoi des données par voie électronique ou postale. - 28 - La FIGURE 3 est une représentation schématique des étapes de déclenchement des demandes de paiement dans le cadre du procédé représenté en figure 2.

Dans la figure 3 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. Le procédé de paiement dans lequel sont réalisées les étapes représentées sur la figure 3 comprend une première demande de paiement selon un protocole de paiement avec pré-autorisation et au moins une deuxième demande de paiement selon un protocole de paiement de type paiement à distance. Une première étape 302 permet de déterminer si une demande de paiement initiale (avec pré-autorisation) a été générée. Si non, une étape de test 304 est réitérée tous les soirs. Lors de cette étape 304 le serveur de gestion vérifie les critères suivants : - si le montant associé à l'utilisateur, et plus particulièrement le montant associé à un compte courant utilisateur (comptabilisant les consommations courantes de l'utilisateur, à savoir les consommations depuis le dernier paiement) dépasse un montant seuil prédéterminé, et/ou - si la durée depuis la dernière demande paiement dépasse une durée seuil prédéterminée, et/ou - si éventuellement, si l'abonnement demandé par l'utilisateur ou la périodicité de cet abonnement a expiré (la notion de périodicité est utilisée lorsque l'utilisateur choisit un abonnement annuel et doit payer un montant prédéterminé de façon périodique. La périodicité est alors d'un mois), et/ou - si la durée de validité de l'autorisation est sur le point d'expirer (dans moins de 24 heures), et/ou - si le montant d'un compte total de l'utilisateur, associé au total des consommations de l'utilisateur depuis l'abonnement dépasse le montant maximal autorisé par l'autorisation. Si ces tests renvoient une réponse négative, aucune demande de débit n'est générée et l'étape est réitérée le lendemain soir. - 29 - 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 306. 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 obtenu, 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 308, 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 310. 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 312, 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. Une fois le paiement effectué, on modifie bien entendu le montant du compte courant de l'utilisateur en fonction du montant prélevé.

Si après l'étape 302, une première demande de débit est déjà réalisée, le serveur de gestion de location vérifie également journalièrement les critères suivants à l'étape 314 : -30- - si le montant associé à l'utilisateur, et plus particulièrement le montant associé à un compte courant utilisateur dépasse un montant seuil prédéterminé, - si la durée depuis la dernière demande paiement dépasse une durée seuil prédéterminée, et - éventuellement, si l'abonnement demandé par l'utilisateur ou la périodicité de cet abonnement n'a pas expiré (la notion de périodicité est utilisée lorsque l'utilisateur choisit un abonnement annuel et doit payer un montant prédéterminé de façon périodique. La périodicité est alors d'un mois). Si ces tests renvoient une réponse négative, aucune requête de paiement n'est générée et l'étape 314 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 316, 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 - 31 - bancaire à l'étape 318. 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 320 : 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 322, un accusé de réception au serveur monétique qui le transmet au serveur de gestion de location.

Un ticket virtuel comprenant le résultat de la transaction est envoyé à l'utilisateur à l'étape 324. 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 326, 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 330 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érieure - 32 - 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. 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. La FIGURE 4 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 400 représentée sur la figure 1 comprend un site central 402 (également appelé organe central dans la suite de la description) connecté à plusieurs sites - ou stations - 4041-404n, dits de location au travers d'un réseau de communication 406 sans fil, par exemple GPRS, ou d'un réseau filaire, par exemple de type DSL. De préférence, chaque site 404 est relié au site central 402 par l'intermédiaire des deux réseaux distincts, ce qui permet une connexion en continu même si l'un des réseaux est défaillant. - 33 - Chaque site de location 404 comprend une borne d'abonnement 102 pour l'enregistrement d'un nouvel abonné, une borne de location 410 pour la location d'un véhicule et plusieurs bornes de charge 412-416, chaque borne de charge étant prévue pour charger un véhicule muni d'une batterie électrique à un emplacement de stationnement. Le site central 402 peut être connecté directement à chacune des bornes d'un site de location 404 au travers du réseau 406 ou seulement à la borne d'abonnement et/ou à la borne de location et/ou aux bornes de charge 412-416. Au moins deux bornes d'un site de location 404 sont connectées entre elles au travers d'une connexion filaire (non représentée).

Le site central 402 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 et le module de test 122. Certains sites de location 404 comprennent une borne d'abonnement qui comprend 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. La FIGURE 5 est une représentation schématique d'un mode de réalisation 500 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 5 comprend un unique serveur, dit de paiement, des moyens de mémorisation et un module de comparaison. Tous les autres organes décrits - 34 - 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é 500 comprend une phase d'initialisation 502 comprenant les étapes suivantes : - étape 504 : envoi par l'utilisateur des données bancaires au serveur de paiement ; - une étape 506 : mémorisation par le serveur de paiement des données bancaires. Le procédé 500 comprend ensuite une ou plusieurs phases 510 de demande 10 de paiement. Chaque phase de demande de paiement est déclenchée par une étape 508 de test des critères de déclenchement décrits plus haut. Si au moins un des critères testés renvoie une réponse nécessitant une demande de paiement, une phase de demande de paiement est déclenchée. Dans le procédé 500, une telle phase 510 de demande de 15 paiement comprend les étapes suivantes : - une étape 512 : émission par le serveur de paiement d'une demande de paiement avec les données bancaires ; - une étape 514 : réception de la réponse de la banque de l'utilisateur avec un accusé de réception. 20 Ainsi, le procédé 500 comprend uniquement une ou plusieurs phases de demande de paiement selon un protocole de vente à distance ou un protocole de prélèvement et ne comprend pas de demande de paiement selon un protocole de type pré-autorisation. 25 Bien entendu, les critères testés peuvent être différents pour plusieurs utilisateurs. Ces critères peuvent être enregistrés dans un dossier associé à l'utilisateur ou un compte client associé à l'utilisateur. Plus particulièrement les critères testés et les valeurs de seuil, à savoir le montant seuil de consommation et la durée seuil depuis le dernier 30 paiement, peuvent dépendre du profil de l'utilisateur et/ou du service dont il bénéficie, et/ou de l'abonnement qu'il a souscrit. Le tableau ci-dessous donne un exemple nullement limitatif de critères testés ainsi que les valeurs seuil associées à ces critères dans le cadre de trois différentes formules d'abonnements : - 35 - D'autres données peuvent également être prises en compte pour déterminer le montant seuil et/ou la durée seuil, par exemple si l'utilisateur est un particulier ou un professionnel, ou si un véhicule est actuellement en cours de location. Au contraire, certaines données, telles que la périodicité, ne sont pas forcément prises en compte lors de l'étape de test. Dans le cas où le procédé comprend un paiement à l'aide d'un paiement pré-autorisé, le montant demandé pour la pré-autorisation peut également varier en fonction du type d'abonnement. Avantageusement, l'utilisateur peut également choisir ces valeurs seuil au moment de son abonnement.

Bien entendu l'invention n'est pas limitée aux exemples qui viennent d'être décrits. Périodicité 1 mois Mem Montant Seuil pour déclenchement de paiement Durée seuil entre 2 paiements pour déclencher un paiement 50E 50E 50E 2j 2j 7j

Claims (15)

1. REVENDICATIONS1. Procédé (200 ; 500) de paiement avec un moyen de paiement de consommations répétées dans le temps et associées à un service, 5 comprenant les étapes suivantes : - lecture par un terminal de paiement de données relatives audit moyen de paiement, - mémorisation (226 ; 506) de données relatives audit moyen de paiement dans un serveur distant du terminal de paiement, 10 - à chaque consommation, mise à jour d'un montant, dit réel, associé à un utilisateur dudit moyen de paiement ; caractérisé en ce qu'il comprend une ou plusieurs itérations des étapes suivantes : - comparaison (247, 257 ; 508) dudit montant réel à un montant 15 prédéterminé, - émission d'une demande (228, 256 ; 510) de paiement vers un serveur bancaire avec lesdites données relatives audit moyen de paiement lorsque ledit montant réel est supérieur ou égal audit montant prédéterminé. 20
2. 2. Procédé selon la revendication 1, caractérisé en que l'étape de comparaison (247, 257 ; 508) comprend en outre une étape réalisant un test relatif à au moins un autre critère que le montant, ledit procédé comprenant en outre une demande de paiement en fonction du résultat 25 dudit test, le test déterminant notamment si la durée depuis la dernière demande de paiement est supérieure à une durée prédéterminée.
3. 3. Procédé (200) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape (206) d'attribution 30 d'une donnée d'identification au porteur du moyen de paiement, les données relatives au moyen de paiement étant mémorisées en association avec ledit identifiant.- 37 -
4. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape de comparaison (247, 257 ; 508) est réalisée à une fréquence prédéterminée.
5. 5. Procédé (200) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une demande de paiement (228) est réalisée selon un premier protocole nécessitant la présence physique du moyen de paiement dans un terminal de paiement (104).
6. 6. Procédé (200) selon la revendication 5, caractérisé en ce qu'au moins une demande de paiement comprend : - une étape (236) de demande de pré-autorisation pour un montant prédéterminé, et - lorsque la pré-autorisation a été obtenue, une étape (250) d'émission d'une demande de paiement comprenant une donnée de pré-autorisation de la pré-autorisation, l'étape de comparaison (247) étant réalisée suite à l'étape (236) de demande de pré-autorisation, l'étape (250) de demande de paiement étant déclenchée si le montant du compte de l'utilisateur est supérieur au montant de la pré-autorisation.
7. 7. Procédé (200, 500) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une demande de paiement (256 ; 510) est réalisée selon un protocole de paiement ne nécessitant pas 25 la présence physique du moyen de paiement dans un terminal de paiement.
8. 8. Procédé (200) selon les revendications 5 ou 6 et la revendication 7, caractérisé en ce qu'il comprend une pluralité de demandes de paiement, ladite pluralité de demandes de paiement comprenant : 30 une demande de paiement (228), dite initiale, selon le premier protocole de paiement ; et au moins une demande de paiement (256), dite ultérieure, selon le deuxième protocole de paiement.- 38 -
9. 9. Procédé (200) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre : une mémorisation (206) d'une adresse numérique associée à l'utilisateur porteur du moyen de paiement, et pour au moins une demande de pré-autorisation ou de paiement (228, 256), émission (246, 254, 264), à ladite adresse numérique, de données, dites de compte-rendu, relatives à l'issue de ladite demande de paiement (228, 256), telles qu'un ticket virtuel.
10. 10. Procédé (200) 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 d'utilisation du service, l'utilisation du service étant autorisée ou non en fonction de ladite donnée de statut de paiement.
11. 11. Procédé (200) selon l'une quelconque des revendications précédentes, comprenant une étape de paramétrage spécifique à l'utilisateur du montant 20 prédéterminé, et de préférence de la durée prédéterminée, préalable à l'étape de comparaison.
12. 12. Application du procédé selon l'une quelconque des revendications précédentes dans une installation (400) de location de véhicules proposés à 25 la location sur au moins un site de location (404).
13. 13. Système (100) de paiement avec un moyen de paiement de consommations répétées dans le temps relatives à un service, ledit système comprenant : 30 - un terminal de lecture de données relatives audit moyen de paiement, - des moyens de mémorisation (110, 112) de données relatives audit moyen de paiement au niveau d'un serveur distant,- 39 - - des moyens (106) de mise à jour, à chaque consommation, d'un montant, dit réel, associé à un utilisateur dudit moyen de paiement, caractérisé en ce qu'il comprend en outre - des moyens (122) de comparaison dudit montant réel à un montant prédéterminé, - des moyens (106, 108) d'émission d'une demande de paiement avec lesdites données relatives audit moyen de paiement lorsque ledit montant réel est supérieur ou égal audit montant prédéterminé.
14. 14. Système (100) selon la revendication 13, caractérisé en ce qu'il comprend en outre : - des moyens (110, 112) de mémorisation d'une adresse numérique, et - des moyens (118), dits de communication, agencés pour réaliser, pour chaque demande de paiement, une émission, à ladite adresse numérique, de données, dites de compte-rendu, relatives à l'issu de ladite demande de paiement.
15. 15. Installation (400) de location de véhicule comprenant : - un site (402) de gestion, dit central, - au moins un site (404) de location de véhicules 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 13 et 14.